Using Teensy 3.1 with 24 Bit I2S Audio Codec

[chensx2012]

The official audio library by Paul is 16 bit. I would like to use Teensy 3.1 with 24 Bit I2S Audio Codec (CS4272). What I need is to stream 24 bit data between Teensy and the codec via I2S (Teensy as master), no further processing is necessary. Any suggestions? Thanks.

 

[WMXZ]

The official audio library by Paul is 16 bit. I would like to use Teensy 3.1 with 24 Bit I2S Audio Codec (CS4272). What I need is to stream 24 bit data between Teensy and the codec via I2S (Teensy as master), no further processing is necessary. Any suggestions? Thanks.

Either you wait for whollender to finish his project https://forum.pjrc.com/threads/27215-24-bit-audio-boards and have him or the forum adapted the existing software to 24 bit, or you adapt yourself existing I2S and DMA drivers to 24 bit. If I had a 24bit hardware, I would opt for the second solution. I will get my custom CS5366 boards only in a month or so. After all, that is what Teensy/Arduino is all about, DIY or learn how to do it. The forum will help you.

 

[chensx2012]

Thanks for the tips. I found that the 24-bit audio from CS4271 (pin compatible with CS4272) has been implemented in Arduino Due here: https://github.com/delsauce/ArduinoDueHiFi/blob/master/examples/Passthrough/Passthrough.ino, but I don't know whether it is possible to revised the code to use with Teensy 3.1.

 

[WMXZ]

Thanks for the tips. I found that the 24-bit audio from CS4271 (pin compatible with CS4272) has been implemented in Arduino Due here: https://github.com/delsauce/ArduinoDueHiFi/blob/master/examples/Passthrough/Passthrough.ino, but I don't know whether it is possible to revised the code to use with Teensy 3.1.

You most likely have to port the HIFI class from Arduino Due to Teensy. Even if both are ARM Cortex (M3 and M4 respectively), a quick glance into HIFI.cpp reveals that at least the nomenclature is different to the one used in Paul's I2SInput/Output class.

Also Passthrough is not an exciting application. Later on you may process the data and then the heavy interrupt-driven approach is too slow.

I recall a comment from Paul indicating that the Audio library is optimized for 16-bit processing, so 32 bit processing may not be easy, but sooner or later some one will port the library to 32 bit.

 

[PaulStoffregen]

Right now, all my dev time is going into Teensy-LC. Soon I'm going to look at Audio on Teensy-LC, but my goal is going to be merely getting one or maybe 2 of the I/O objects working, and the huge amount of stuff that depends on Cortex-M4 DSP extensions to at least automatically disable itself when compiling for Teensy-LC.

Later this year, after Teensy-LC is released, and after a number of other long-neglected features on my TO-DO list are published, I'm going to work on the audio library again. Features like wavetable synthesis, seeking & variable speed playing, and usability improvments in the design tool will be my main focus.

If Whollender has makes his 24 bit board by then, and only if the isolation barrier part works, I'll probably put some serious work into supporting it.

More than 16 bits will be supported by using a pair of 16 bit streams. So in the web design tool, a 24 bit stereo DAC output object would have 4 input stream. Two would be the normal 16 bit streams for left and right, which would become bits 31 to 16, and the other 2 would be for the lower bits, which would become bits 15 to 0.

If this ever happens, I'll probably make a few other objects with pairs of ports. A WAV file layer that recognizes 24 bit data, and a 32 bit mixer might be the only such objects. Well, I'll probably also make a 32 bit high purity sine generator, maybe using Taylor series, not because any will really need it, but because it seems wrong on a technical level to go to the trouble of enabling 32 bits without at least one synthesis object that creates a ridiculously pure 32 bit sine wave. Maybe over time, other objects will also get 32 bit versions, but that seems unlikely to happen anytime soon (like in 2015).

This all hinges of Whollender making that 24 bit board. Or someone else could make it, but I'll only touch it if the design is similar to Whollender's, especially the isolation barrier.

Or if some else does all the software work, in the way I've outlined here (and in several other messages when 24/32 bit topics have come up), I'd probably merge such a pull request. If anyone seriously does start work on that, please let me know, so it can progress in a manner I can accept into the library.

 

[PaulStoffregen]

I'd also like to ask what is meant by this statement, particularly the words "no further processing is necessary"?

What I need is to stream 24 bit data between Teensy and the codec via I2S (Teensy as master), no further processing is necessary.

What will the data actually be? Just zeros or some constant repeated over and over?

My point is even merely playing a WAV file requires code to read the file from media like a SD card, sustaining the speed necessary for uninterrupted streaming.

If you look at the Due Hifi library, its only 2 examples are passthrough, and playing a fixed frequency, fixed amplitude sine wave. That library runs an interrupt 48000 times per second, to receive input and generate the next output. While that leads to simple code, it's very much like painting yourself into a corner.

Reading sectors from a SD card takes time and buffering. Audio synthesis, filter and effects algorithms are also very inefficient if done 1 sample at a time.

A tremendous amount of work went into the Teensy Audio Library, to create an architecture that's genuinely useful. Data is processed in 128 sample blocks, which are approx 2.9 milliseconds. That works well for accessing media. It allows algorithms to do all sorts of interesting things. It allows for a flexible routing of audio between components, using shared copy-on-write buffer management, where the overhead is low because it happens only once every 128 samples.

The reality is pretty much all realistic audio projects do require some sort of "further processing", even if that's merely reading data from media and streaming it out to the DAC.

 

[daperl]

Is support for a USB audio interface device still near the top of your audio library priority list? Begging is not beneath me.

 

[Frank B]

I could support 24bit with my teensy mp3/aac decoders, but i think we need a bit more power & ram (the next "high end" tensy?) for this.

 

[PaulStoffregen]

Is support for a USB audio interface device still near the top of your audio library priority list?

Yes, I absolutely do intend to add bidirectional streaming USB audio which integrates nicely with the audio library. It will almost certainly be designed for 16 bit samples, not 24 or 32.

 

[chensx2012]

Right now, all my dev time is going into Teensy-LC. Soon I'm going to look at Audio on Teensy-LC, but my goal is going to be merely getting one or maybe 2 of the I/O objects working, and the huge amount of stuff that depends on Cortex-M4 DSP extensions to at least automatically disable itself when compiling for Teensy-LC.

Later this year, after Teensy-LC is released, and after a number of other long-neglected features on my TO-DO list are published, I'm going to work on the audio library again. Features like wavetable synthesis, seeking & variable speed playing, and usability improvments in the design tool will be my main focus.

If Whollender has makes his 24 bit board by then, and only if the isolation barrier part works, I'll probably put some serious work into supporting it.

More than 16 bits will be supported by using a pair of 16 bit streams. So in the web design tool, a 24 bit stereo DAC output object would have 4 input stream. Two would be the normal 16 bit streams for left and right, which would become bits 31 to 16, and the other 2 would be for the lower bits, which would become bits 15 to 0.

If this ever happens, I'll probably make a few other objects with pairs of ports. A WAV file layer that recognizes 24 bit data, and a 32 bit mixer might be the only such objects. Well, I'll probably also make a 32 bit high purity sine generator, maybe using Taylor series, not because any will really need it, but because it seems wrong on a technical level to go to the trouble of enabling 32 bits without at least one synthesis object that creates a ridiculously pure 32 bit sine wave. Maybe over time, other objects will also get 32 bit versions, but that seems unlikely to happen anytime soon (like in 2015).

This all hinges of Whollender making that 24 bit board. Or someone else could make it, but I'll only touch it if the design is similar to Whollender's, especially the isolation barrier.

Or if some else does all the software work, in the way I've outlined here (and in several other messages when 24/32 bit topics have come up), I'd probably merge such a pull request. If anyone seriously does start work on that, please let me know, so it can progress in a manner I can accept into the library.

Paul, do you think you will design a more powerful teensy in the future, in addition to the teensy-LC? The cost is not my concern.

 

[PaulStoffregen]

Paul, do you think you will design a more powerful teensy in the future

Yes, mostly certainly I'll be making more powerful boards in the future, there's no question about that. How far in the future would be a better question.

I certainly do have my eye on Cortex-M7. Realistically, that may not really mature until sometime in 2016.

The cost is not my concern.

Well, it's easy to say you don't care about cost. But I certainly do. You probably do too.

The reality of the hobbyist market today is a lot of powerful Linux-based products at approx $50, and underpowered ones starting to push downwards towards the price of Teensy. I know some people, like Arduino, are coming out with more expensive boards. I don't think that'll work for PJRC.