Black or green audio adapter? RPi / bit rate?

Hello.
1. I've found several distributors with reasonably-priced Teensy merchandise in Europe, but I see that some have black and some have green audio adapter boards. I just want to be sure before I order. I found a post on these forums from 2014 with a photo of a black one, so I'm guessing the green one is version 2?

2. I have an RPi and I see that the ALSA system-on-chip driver has a module for SGTL5000. The PJRC Teensy Audio Adapter page mentions adding 44.1 kHz 16-bit audio to your Teensy projects; I assume that's a limitation of the Teensy or the audio library, right? The SGTL5000 datasheet mentions 24 bits and much higher sampling rates. I expect I'll be able to use them with RPi, no? If not, it's not the end of the world - I really just need some sound before I lose my mind!


Thanks!

-Chuckk

Yes, the black boards are the first version. Some first version boards were green, so just because a board is green doesn't necessarily mean it's the second version.

Unless you're going to connect two of them (for quad channel), there's really no difference. The first version is the same, except the options to mod for use as a 2nd board.

The SGTL5000 does support other sample rates and word sizes. But it's SNR isn't much better than 96 dB, so there's little point to using more that 16 bits. Well, unless you just find the notion of 8 more bit comforting, even if they are always just random noise... Which is pretty much the case for all consumer audio sold as 24 bits. Likewise, higher than 48 kHz is pointless, but the chip can do it if you want.

Whether it can really work with a Raspberry Pi is a good question. The MCLK signal is likely to be an issue.

From what I've seen, it can't be much more of an issue than what people run into with any other audio card and RPi. Well, any other card with ADC and DAC. I've placed an order from Hobbytronics UK, untracked, so I don't know when, but I'll see how it goes one of these days! Seriously, I saw so many other boards lauded and hyped, but when I read deeper, they either had the same problems, or they used all of the Pi pins, or they had no ADC, or they had analog voltage supply directly from digital voltage supply, or they never actually worked on RPi. I'm always prepared for a challenge, but I have the feeling the Teensy Audio Adapter is one of the simpler choices even for Raspberry Pi.
I also bought a TI PCM1781 without much thought, being super cheap, but it has the same MCLK deal and it's not in a circuit, and I need to feed the cat sometimes, so I don't think I have time to make it work.
-Chuckk

Ok.

If you do run into a situation where the RPi can't create MCLK, you might need to also buy a crystal oscillator. You'd get 12.288 MHz if you want 48 or 96 kHz audio sample rate. Look for an oscillator, not just the raw crystal, and get one that runs on 3.3V power.

I was planning to use a crystal oscillator. But it's not clear to me how the data and clock transfer works. If I use the SGTL5000 in slave mode, I send the MCLK only to it, and it sends the LR and bit clocks to the MCU, which sends back the data? And in slave mode, all of the clocks and data come to the SGTL5000 from one or another source, and it only outputs analog?

Thanks a bunch. I just got word that my Audio Adapter was shipped...

-Chuckk

I've only ever used it in slave mode, where Teensy is the master. Teensy sends all 3 clocks and the TX data. The SGTL5000 sends the RX data, aligned to the clocks Teensy sends.

Documentation is on these pages of the audio design tool.

http://www.pjrc.com/teensy/gui/?info=AudioInputI2S
http://www.pjrc.com/teensy/gui/?info=AudioOutputI2S

Look at the right side panel, and scroll down to "Hardware" for the signal details.

SGTL5000 has a master mode. I've never used it. I'm curious to hear anything you learn about this mode, if you use it.

One minor but important point other people have encountered when using the audio shield on non-Teensy boards is the need for MCLK. The chip does not initialize without MCLK. It will not respond at all on SDA & SCL without a stable clock signal at MCLK. See figure 4 on page 10 in the datasheet.

Thanks for the tips.
Just for the first tests, I'm using a GPIO clock from RPi3 to clock it, and if I set that clock to 9.6 MHz, it shows up on I2C, but that's as far as I can get. (9.6 as in half of the main 19.2 MHz oscillator, and within the range of external clocks that the SGTL accepts. I will likely switch to a crystal, but I want to see if I can use the card first.)

I tried reading and writing the SGTL's registers through I2C from wiringpi on Python, but it's telling me very strange things that can't possibly be right. I edited the ALSA soc driver for the SGTL5000's registers to reflect my setup, i.e. the clock rates, the PLL power, and putting it in master mode. Alas, it's still invisible to ALSA.

So, it might work yet, and if it does I'll write up how I got it to work.
-Chuckk

Chuckkh said:

I tried reading and writing the SGTL's registers through I2C from wiringpi on Python, but it's telling me very strange things that can't possibly be right.

Click to expand...

Maybe you can mine this code for some hints?

https://github.com/PaulStoffregen/Audio/blob/master/control_sgtl5000.cpp#L500

I edited the ALSA soc driver for the SGTL5000's registers to reflect my setup, i.e. the clock rates, the PLL power, and putting it in master mode. Alas, it's still invisible to ALSA.

Click to expand...

I really have no idea about configuring ALSA. But one thing I can tell you is the SGTL5000 has 16 bit registers. Many other chips have 8 bit registers. So if you're using generic code that tries to access hardware registers within an I2C chip, make sure it's trying to access them as 16 bits.

Thank you. Your driver code is very clear. I've lost myself in ALSA and not made much progress. There is a SGTL5000 driver, actually published by Freescale, but that's not enough for the ALSA people. You need a driver for the SoC, a driver for the codec, and *another* driver to communicate between those two drivers, before the device will even be detected.
I'm leaning towards the low-level method, but the I2C anomalies I mentioned before are still there. I dump the registers of the device through I2C and it shows me register 0x0000 as 11a0, which would seem to make sense for revision 17, although it's like the lower byte first ??? All of the other registers show as 0, which the datasheet seems to indicate shouldn't happen. It tells me the levels are muted on reset or powerup. Anyway, any time I attempt to read any register values, aside from the dump, they start changing. Different values every time, but they change every time. They remain the same, viewed as a dump, until the moment I try to read an address, and from then on the value of register 0x0000 changes. What I've read seems to indicate this could happen if a driver is accessing the device, but Linux doesn't know there's something there!

I know I shouldn't be in over my head, but I might just be.
-Chuckk

Paul, does this sound feasible, from what you know?
The I2C interface of the Teensy Audio Adapter is controlled by one board, be it Arduino or Teensy; and the I2S data comes from Raspberry Pi, using its various bizarre simple dummy card setups (that supposedly work for just sending I2S without ALSA needing to know what is attached)?
-Chuckk