24 bit audio boards
- Thread starter whollender
- Start date
Robin
Administrator
Here's what I have so far
whollender
Well-known member
I've been reformatting the bill of materials into our standard format and I have a couple of questions. I'm having Erin soldering up a board as I type.
- Are the FB parts inductors? (FB301, FB302, FB401, FB501, FB601, FB701 & FB801, FB802)
- are Conn_3, and Conn_2 header pins? Are they single row headers?
- What is part BAT4XAA - U801?
Hi Robin,
The FB parts are all surface mount ferrite beads. There should only be two different parts for these reference designators (I think there are two 0805 parts, and 6 0603s).
All the 'Conn' parts, and the battery are all 0.1" pitch headers.
PaulStoffregen
Well-known member
Erin is soldering one of the Super Audio Boards right now!
whollender
Well-known member
whollender
Well-known member
Paul, Have you had a chance to take a look at the board yet?
I just got the board working with Raspberry Pi (Hackaday project log).
My next task was going to be setting up an audio lib object with the codec set up in 16 bit mode so that it would work with the audio library as is.
I just got the board working with Raspberry Pi (Hackaday project log).
My next task was going to be setting up an audio lib object with the codec set up in 16 bit mode so that it would work with the audio library as is.
A quick work around, at least this is sufficient for me, is to dma the 24 bit to say 32 bit, and extract 16 bit for processing. The necessary shift (digital gain) is specified programmatically. This way I can use all the 16 bit dsp functions I already had. On output is the opposite.
neat, so in this case the MCLK isn't connected?
CyborgEars
Active member
@WMXZ, whollender: we're another group running a teensy 24 bit audio (project description: see here) and very interested in anything you can cook up in that direction.
@WMXZ: do you have sample code for this available?
My impression was that "just copying 16 bits" was not enough and e.g. at least some dithering and a conversion step was required, which is why we ditched most of the audio library and directly hooked up our I2S audio source to the teensy audio shield and focused on getting the "DSP" functions of the SGTL5000 chip to work via the control_sgtl5000.cpp ..
@WMXZ: do you have sample code for this available?
My impression was that "just copying 16 bits" was not enough and e.g. at least some dithering and a conversion step was required, which is why we ditched most of the audio library and directly hooked up our I2S audio source to the teensy audio shield and focused on getting the "DSP" functions of the SGTL5000 chip to work via the control_sgtl5000.cpp ..
OK, I'm not using directly the audio library but build on it.
Now, the dma (24 bit audio to 32 bit memory) brings you all available data into memory. As I wanted to use the highly optimized 16-bit FFT and 96 dB dynamic range is good enough for me, I first shift the 32 bit to right and then copy the lower 16 bits
As you ask for a code, here it is:
Code:
FASTRUN void doExtract(short *yyi, const int *xxi, int nn, int shift)
{ int ii;
ii=nn/8;
while(ii)
{ *yyi++ = (*(xxi++)>>shift);
*yyi++ = (*(xxi++)>>shift);
*yyi++ = (*(xxi++)>>shift);
*yyi++ = (*(xxi++)>>shift);
*yyi++ = (*(xxi++)>>shift);
*yyi++ = (*(xxi++)>>shift);
*yyi++ = (*(xxi++)>>shift);
*yyi++ = (*(xxi++)>>shift);
ii--;
}
}nothing really special, I cannot see any need for fancy processing.
The only issue is that you have to consider digital gain (or better attenuation) settings (shifts).
Also, I do not want to enter the discussion why one would need more than 96 dB dynamic range, but then you may be bettor of with dsp with optimized 32bit instructions.
whollender
Well-known member
@WMXZ, that's pretty much what I had in mind to allow the codec to work with the rest of the audio library. I haven't thought to much about the actual implementation, but I think I'd have to extend the existing I2S objects to do full 32 bit transfers and the truncation back to 16 bits before passing the data in.
@cyborg ears, the codec has a dither capability built in to allow truncating to 16 bits with minimal signal degradation.
@mxxx, yeah, the mclk signal is just left open with the raspberry pi's interface working in slave mode.
@cyborg ears, the codec has a dither capability built in to allow truncating to 16 bits with minimal signal degradation.
@mxxx, yeah, the mclk signal is just left open with the raspberry pi's interface working in slave mode.
CyborgEars
Active member
@whollender: I guess that with codec you mean the PCM CODEC you are using on the "big" audio board?
@WMXZ: the code looks simple, but I'm not sure how well it will work in our microphone-dependent application. We need a lot of digital amplification on the SGTL5000 to get their audio volume to usable levels, and if I understand bit depth correctly, simply cropping away the lower bits has a higher impact on an audio signal with a very low audio level (most data in the lower bits), as we get it from the I2S microphones.
(Those have no gain settings and IMHO use 24bit mostly to get away with that, without clipping / loss of precision at sounds below 'normal' conversation volume)
As mentioned elsewhere, the SGTL5000 DSP is very limited, so getting 24/32 bit frames into the teensy for stays an interesting feature overall.
@WMXZ: the code looks simple, but I'm not sure how well it will work in our microphone-dependent application. We need a lot of digital amplification on the SGTL5000 to get their audio volume to usable levels, and if I understand bit depth correctly, simply cropping away the lower bits has a higher impact on an audio signal with a very low audio level (most data in the lower bits), as we get it from the I2S microphones.
(Those have no gain settings and IMHO use 24bit mostly to get away with that, without clipping / loss of precision at sounds below 'normal' conversation volume)
As mentioned elsewhere, the SGTL5000 DSP is very limited, so getting 24/32 bit frames into the teensy for stays an interesting feature overall.
Last edited:
PaulStoffregen
Well-known member
whollender
Well-known member
RS had a better shippingcost, still same as two of the chips though.
The crystal is also diffcult, Farnell tells me that I have to buy 1000 (tape) of them, and that they come from us, so superexpensive shipping..
The crystal is said to have 50ppm, and 20pf load capacitanse, but on the schematic it's used 39pf?, does that mean that I just as well can choose 18pf? (which seems to be easier to find)
Sorry for swamping the forum with these questions, maybe I should just bite it and order from digikey/mouser after all..
The crystal is also diffcult, Farnell tells me that I have to buy 1000 (tape) of them, and that they come from us, so superexpensive shipping..
The crystal is said to have 50ppm, and 20pf load capacitanse, but on the schematic it's used 39pf?, does that mean that I just as well can choose 18pf? (which seems to be easier to find)
Sorry for swamping the forum with these questions, maybe I should just bite it and order from digikey/mouser after all..
whollender
Well-known member
The actual capacitors need to be slightly less than double the crystal's spec'd load capacitance (ideally 40pF, but we use 39pF to take into account the board's parasitic capacitance). You can use any crystal in the same footprint that has a 20pF load capacitance.
Getting 24/32 bit frames into teensy is trivial (need to change i2s/dma). OK, Paul did not do it in the audio library, but it can be done, especially if you do not want to use Paul's audio library with fast DSP support
Concerning Bit range, what is your measured dynamic range of the pre-amp? The dynamic range of the (cheap) SGTL5000 is not so great either (I don't recall the exact value, maybe someone could measure it?). So, within the 24 bit after the SGTL5000 you have a lot of electronic noise.
If your data are mostly in the lower 16 bits (low pre-amp gain) then you loose nothing when you copy only the lower 16 bit. If you know the ADC electronic noise level and have the audio signal above this electronic noise, you can always shift the data by the amount of electronic noise as you will not loose audio signals.
If you are worried about high dynamic range quality (simultaneously loud and quiet sound) you have to abandon SGTL5000 and go for a Cirrus chip (e.g. whollander's audio card) and a dsp that is optimized for 32 bit arithmetic and not teensy that does fast 16-bit dsp operations.
PaulStoffregen
Well-known member
Switching from 16 to 32 bit frame format (with the lower 16 bits always zero) is on a long list of stuff I'd like to do in the audio library. This and *many* other non-critical features were set aside to get the 1.0 release out. Even then, the audio library took nearly 1 year and seriously delayed work on Teensy-LC and other projects. Compromises had to be made, or else we probably never would have stabilized the API and made a 1.0 stable release.
If anyone wants to work on this, and make sure it's well tested with SGTL5000, I'd be happy to merge a pull request.
Several other chips require the 32 bit frame format, even if they only have 16 usable bits. Hopefully this will open up a lot more compatibility with other DACs, ADCs and Codecs.
It's probably also a necessary step to good support for Whollander's board, so I'm very likely to do this soonish anyway.
Since the earliest days developing the audio library, even before anything worked, there's always been a steady stream of 24 bit (and often high sample rate) requests. I used to always ask why. Almost all answers ranged from playback of pre-recorded files to "just want it".
The Cortex-M4 DSP extensions and 32 bit bus allow processing 16 bit samples about 1.5X to 2X faster. The net speedup depends on a lot of complex factors, which is why ARM's marketing very carefully uses phases like "up to" twice the performance. There might be some extreme cases where the speedup is slightly over 2X due to differences in register allocation for intermediate calculations (fewer registers available), but generally 2X is about the best case speedup.
So at worst, using 32 bit sample results in about half the speed. Often you could expect 32 bit DSP to run at about 75% the speed of 16 bits. That's a pretty big loss for a feature that adds little real value. But still, for those "audiophile enthusiasts" who really want 24 or 32 bits, maybe less DSP speed is acceptable? And really, what does the DSP speed matter, if all they want to do is play WAV or FLAC files?
Despite my somewhat cynical tone, I am still in the process of deciding how much of the library will (eventually) gain 32 bit support.... at least by my hand. Currently, the only certain areas are WAV playing, mixing, and I2S input & output. I'll probably make high fidelity sine wave synth using Taylor series. If anyone reading this has a real application for more-than-16 processing that isn't simply playback of pre-recorded sounds, please do speak up. But be prepared to truly explain what you're doing and *why* 24 or 32 bits matters. Don't write tell me you just want it, or you're concerned about some theoretical accumulation of round-off errors, and especially don't tell me you think you can hear the difference between 16 and 24 bits with popular pre-precorded music. I've heard all that many, many times over the last couple years, and frankly it achieves pretty much the opposite of motivating me to really work on 32 bit support.
CyborgEars
Active member
@whollender, @Paul:
I'll try to go a bit more into detail about my reasons, as there seems to be some misunderstandings.
I'm not an audio expert by trade, so some of my understanding of issues along the way may be flawed or rely too much on "the engineers knew why they were doing it". If you have a deeper understanding, please feel free to correct me.
This is not about going from "high" to "highest" in terms of audio quality, as Paul has suggested (and criticized, for various reasons, which are understandable), but a matter of getting a whole line of audio elements to work that are otherwise plainly unusable with the teensy platform.
Let me introduce some functional concepts about the I2S microphones I've been referring to:
I2S microphones are tiny SMD parts which are meant to sit somewhere on the pcb of a multimedia / audio device and, if enabled, continuously record audio samples with their internal ADC and shove the resulting data stream to a MCU or CODEC. The microphone designers decided it would be wise to use a very streamlined set of data lines and do only include I2S and NO other means of controlling any sample settings beyond the primitive ENABLE and LEFT/RIGHT pins and the sampling frequency, which is controllable via I2S clocks.
One therefore has no control over any gain or sample depth setting of the ADC stage of an I2S microphone. This fact might have also led to - but I'm not confident about this fact - the follow-up decision by the audio designers to use fixed 24bit depth for the I2S data transfer. This is the crucial point why I've decided that cutting bits most definitely has some repercussions along the way.
I'ld be happy if this assumption is wrong, because then things get a lot easier on all fronts
Even after a lot of reading on this subject, I'm not exactly sure if 24 bits are really necessary, and if so, why.
The I2S mic in question* has 91dB "digital range" between its noisefloor and +120dB SPL, which is it's full scale digital output. That is obviously below the theroretical 96dB that 16bit gives us.
For me, there could be several reasons:
There is the big aspect of "postproduction": like with "raw" format for digital photos, depths of 20 and 24 bits for audio allow manipulation of the data without the necessity to "clip" especially high/low values. While displays and audio systems aren't able to use the additional depth in the final reproductions, signal degradation can be avoided in between.
In my opinion, that may be a partial answer in itself to Paul why >16bit would be useful for the DSP system on the teensy, but someone with more DSP / audio design experience is necessary to answer that question.
A negative aspect of 24bit I2S in practice:
Because 24 bit I2S data is riding in a 32bit subframe instead of 16bits in a 16 bit subframe, the overall clocks have to be increased noticably, which makes routing and layouts harder (BLCK / MCLK).
Again: I guess someone thought it's worth the effort, I just don't know if he was right
(The same applies for the necessary bandwidth, if no compression / conversion is done)
Can you think of additional reasons why the audio designers went with 24 bit?
*(ICS-43432 by InvenSense, who bought AnalogDevices' MEMS microphone branch in 2013)
I'll try to go a bit more into detail about my reasons, as there seems to be some misunderstandings.
I'm not an audio expert by trade, so some of my understanding of issues along the way may be flawed or rely too much on "the engineers knew why they were doing it". If you have a deeper understanding, please feel free to correct me.
This is not about going from "high" to "highest" in terms of audio quality, as Paul has suggested (and criticized, for various reasons, which are understandable), but a matter of getting a whole line of audio elements to work that are otherwise plainly unusable with the teensy platform.
Let me introduce some functional concepts about the I2S microphones I've been referring to:
I2S microphones are tiny SMD parts which are meant to sit somewhere on the pcb of a multimedia / audio device and, if enabled, continuously record audio samples with their internal ADC and shove the resulting data stream to a MCU or CODEC. The microphone designers decided it would be wise to use a very streamlined set of data lines and do only include I2S and NO other means of controlling any sample settings beyond the primitive ENABLE and LEFT/RIGHT pins and the sampling frequency, which is controllable via I2S clocks.
One therefore has no control over any gain or sample depth setting of the ADC stage of an I2S microphone. This fact might have also led to - but I'm not confident about this fact - the follow-up decision by the audio designers to use fixed 24bit depth for the I2S data transfer. This is the crucial point why I've decided that cutting bits most definitely has some repercussions along the way.
I'ld be happy if this assumption is wrong, because then things get a lot easier on all fronts
Even after a lot of reading on this subject, I'm not exactly sure if 24 bits are really necessary, and if so, why.
The I2S mic in question* has 91dB "digital range" between its noisefloor and +120dB SPL, which is it's full scale digital output. That is obviously below the theroretical 96dB that 16bit gives us.
For me, there could be several reasons:
- 96dB is only valid for a perfect ADC systems, which in reality might have e.g. worse quantization errors, so going for 24 bit saves quality in the end
- because of the small gap 91dB <> 96dB, the designers decided to move to 24bit now instead of later when it's absolutely necessary. (There are already microphones on the market with +130dB SPL full scale input value, which brings us to 99dB digital range from noisefloor to max. range point, and consequently one would decrease the SNR in that application by using 16 bits!)
- ? is it useful to set the digital "no input level" below the real noisefloor of the device?
- something other, financially motivated / marketing idea ("look, 24 bit! High quality!")
There is the big aspect of "postproduction": like with "raw" format for digital photos, depths of 20 and 24 bits for audio allow manipulation of the data without the necessity to "clip" especially high/low values. While displays and audio systems aren't able to use the additional depth in the final reproductions, signal degradation can be avoided in between.
In my opinion, that may be a partial answer in itself to Paul why >16bit would be useful for the DSP system on the teensy, but someone with more DSP / audio design experience is necessary to answer that question.
A negative aspect of 24bit I2S in practice:
Because 24 bit I2S data is riding in a 32bit subframe instead of 16bits in a 16 bit subframe, the overall clocks have to be increased noticably, which makes routing and layouts harder (BLCK / MCLK).
Again: I guess someone thought it's worth the effort, I just don't know if he was right
(The same applies for the necessary bandwidth, if no compression / conversion is done)
Can you think of additional reasons why the audio designers went with 24 bit?
*(ICS-43432 by InvenSense, who bought AnalogDevices' MEMS microphone branch in 2013)
Last edited:
OK, I'll throw my hat into the ring. I'm interested in developing a mic preamp/fx unit for professional recording. Whollender's board appeals to me for 2 reasons:
1. Noise floor. Some pro-audio mics are extremely low output that require large amounts of gain, and recording engineers have little tolerance for noise.
2. Signal isolation. I'm using a Teensy + Audio board right now for various projects and I'm very happy with it on the whole. I am, however, struggling with what I suspect is switching noise from the voltage regulator that I'm using. I'm optimistic that I'll be able to reduce this to a minimum, and that will be good enough for some applications, but there will always be some ground loop noise as long as the signal isn't isolated.
That being said, I'm not so concerned about the audio library conversion. I'm only using the I2S inputs/outputs and the mixer. For any other processing, I've been using my own objects. If I wanted to use a filter, I'd be happy to modify that code to 32 bits and contribute.
What I really want to know is: Are pre-assembled boards are going to be available for purchase at some point in the near future? I'd be happy to pitch in to get a batch into production.
1. Noise floor. Some pro-audio mics are extremely low output that require large amounts of gain, and recording engineers have little tolerance for noise.
2. Signal isolation. I'm using a Teensy + Audio board right now for various projects and I'm very happy with it on the whole. I am, however, struggling with what I suspect is switching noise from the voltage regulator that I'm using. I'm optimistic that I'll be able to reduce this to a minimum, and that will be good enough for some applications, but there will always be some ground loop noise as long as the signal isn't isolated.
That being said, I'm not so concerned about the audio library conversion. I'm only using the I2S inputs/outputs and the mixer. For any other processing, I've been using my own objects. If I wanted to use a filter, I'd be happy to modify that code to 32 bits and contribute.
What I really want to know is: Are pre-assembled boards are going to be available for purchase at some point in the near future? I'd be happy to pitch in to get a batch into production.
xxxajk
Well-known member
Try adding on a ferrite or a common mode choke on the supply output close as possible to where you feed the voltage into the teensy. This should filter out a lot of the noise. Another thing that can help as well is a 0.1uF ceramic capacitor and/or ferrite from digital ground to frame ground (earth). This has solved a lot of issues for me when I have had these problems crop up.
Another source of noise could be any digital lines that are in use. Use a ferrite to smooth the edges of the signal a little, and a pull up or pull down resistor can't hurt either.
whollender
Well-known member
I do want to sell populated boards at some point. The up front costs of getting a manufacturing run together are pretty high (especially for this board), so I was investigating a kickstarter or similar crowdfunding type deal for people that were interested.
As far as a timing goes, right now I'm pretty busy trying to get stuff ready for the first hackaday prize deadline on Aug 17th. Any work towards getting a manufacturing run together (with or without a crowdfunding campaign) wouldn't start until after that, so it would be at least a few months before anything would start showing up.
Thanks, a common mode choke helped quite a bit. I also found a few other (somewhat surprising) culprits:
- Ironically, the sgtl5000's high-pass filter was introducing a lot of high-end noise, so running adcHighPassFilterDisable() helped (and it seems that you do have to run it explicitly – it appears to be on by default).
- There was still some chirping going on in the low-mids while using line in/line out. This turned out to be what I assume is cross-talk from the sgtl5000's headphone amplifier. Oddly, I found the only way to truly disable it and eliminate the chirps was to change one of the writes to the board in control_sgtl5000.cpp. Changing "write(CHIP_ANA_POWER, 0x40FF)" to "write(CHIP_ANA_POWER, 0x40EF)" did the trick. Neither volume(0.0) nor muteHeadphone() were as effective.