I am using T3.6 to implement an embedded audio hub. Given how the connections are instantiated into the connection lists and what controls the synchronous timing for mastering the data interchange. Obviously all data interchanges and the block processing for the selected connections has to be completed within one Teensy Audio Frame time. Just looking for some help as to where this might occur within the Teensy Audio and core library.
A question about master timing of the audio connection matrix
- Thread starter Kent.Swan
- Start date
- Status
Theremingenieur
Senior Member+
In the audio library, it's the output objects which consume audio buffers with precise timing which then triggers update requests to refill these buffers backwards through the mixers and effects up to the input objects.
You should look closer at this page to understand the object model: https://www.pjrc.com/teensy/td_libs_AudioNewObjects.html
You should look closer at this page to understand the object model: https://www.pjrc.com/teensy/td_libs_AudioNewObjects.html
Thanks, that reference helps.
I've developed VOIP firmware with 'player' timing and where packet arrival times are variable. Typically this means that it's necessary to prebuffer a couple of input packets to allow for input jitter or framing misalignment. Another email indicated that the entire teensy audio system is operating synchronously with 44.1 Khz sampling rate. It would seem that with multiple output peripherals operating at that rate, that the related inputs would need, at a minimum, double buffering of the input to allow for framing adjustment.
I've developed VOIP firmware with 'player' timing and where packet arrival times are variable. Typically this means that it's necessary to prebuffer a couple of input packets to allow for input jitter or framing misalignment. Another email indicated that the entire teensy audio system is operating synchronously with 44.1 Khz sampling rate. It would seem that with multiple output peripherals operating at that rate, that the related inputs would need, at a minimum, double buffering of the input to allow for framing adjustment.
PaulStoffregen
Well-known member
Whether you need extra buffering really depends on the type of input.
The ADC and I2S in master mode don't need extra buffering, because their input is controlled by Teensy's clock.
If you're receiving packets by Ethernet or some other network interface, then yes, you'll need to buffer. You'll probably use the queue object to put your data into the audio library. It does buffering for you, if you give it data faster than the audio library needs. But if you let it underrun, the audio library will get a 128 sample block of silence if there's no data you've put into the queue when the library runs its update to process the 128 more samples.
To make this work well, you'll probably need some code to track the average rate you're feeding data into the audio library relative to how fast it's consuming. If you're getting more data than the library can consume, you'll probably need to occasionally discard samples (easy but low quality if done too often) or resample (difficult) so your data rate on average matches the audio library.
The alternative is to write your own input object for the library. The audio library has a concept of "update responsibility". One of the input or output objects is responsible for triggering the library to update every 128 samples. To see the code, just look at the source for any of the non-USB input or output objects. They all have a check for update responsibility, and if they are responsible for the update they call a function every 128 samples.
An assumption built into the library is that all other input & output objects will exactly match the rate of whatever object claimed the update responsibility. This works in the normal case where you put any number of master-mode inputs and outputs into your design. It also works when you have only 1 slave-mode, or 2 running on the same hardware (like I2S in & out - both slave mode). But if you mix master mode I/O with any slave mode stuff, they will have slightly different rates but only 1 gets to have update responsibility. All others not in sync with the one driving the updates will suffer glitches or dropouts.
The ADC and I2S in master mode don't need extra buffering, because their input is controlled by Teensy's clock.
If you're receiving packets by Ethernet or some other network interface, then yes, you'll need to buffer. You'll probably use the queue object to put your data into the audio library. It does buffering for you, if you give it data faster than the audio library needs. But if you let it underrun, the audio library will get a 128 sample block of silence if there's no data you've put into the queue when the library runs its update to process the 128 more samples.
To make this work well, you'll probably need some code to track the average rate you're feeding data into the audio library relative to how fast it's consuming. If you're getting more data than the library can consume, you'll probably need to occasionally discard samples (easy but low quality if done too often) or resample (difficult) so your data rate on average matches the audio library.
The alternative is to write your own input object for the library. The audio library has a concept of "update responsibility". One of the input or output objects is responsible for triggering the library to update every 128 samples. To see the code, just look at the source for any of the non-USB input or output objects. They all have a check for update responsibility, and if they are responsible for the update they call a function every 128 samples.
An assumption built into the library is that all other input & output objects will exactly match the rate of whatever object claimed the update responsibility. This works in the normal case where you put any number of master-mode inputs and outputs into your design. It also works when you have only 1 slave-mode, or 2 running on the same hardware (like I2S in & out - both slave mode). But if you mix master mode I/O with any slave mode stuff, they will have slightly different rates but only 1 gets to have update responsibility. All others not in sync with the one driving the updates will suffer glitches or dropouts.
Looking at the code for the channels, the explanation makes sense though I'm having a bit of trouble wrapping my mind around that any object could be the sync master or is there a sub rosa mechanism that selects an object depending on the mix of objects that have been activated and thus have been added to the update list.
Ah... And I just realized that there will be an intrinsic input to output synchronous one buffer latency (eg 128 samples). Assuming a 44.1 Khz sample rate the I2S BCLK representing a L/R frame would be 44100 * 16 * 2 or 1,411,200 Hz. Also at 44.1 Khz sample rate the intrinsic latency will be (1/44,100) * 128 or 2.66 (and change) ms. With the previous discussion, unless I have something thought out wrong, then this interval could be considered the macro frame rate for Teensy Audio.
PaulStoffregen
Well-known member
Yes, the audio library processes data in 128 sample blocks.
BCLK is actually ~2.8 MHz. Long ago it was ~1.4 MHz as you've calculated (and still is for the quad I2S). But 1.4 MHz turned out to be incompatible with I2S MEMS microphones which require BCLK/LRCLK ratio of 64, so BCLK was doubled and the low 16 bit slots are ignored.
BCLK is actually ~2.8 MHz. Long ago it was ~1.4 MHz as you've calculated (and still is for the quad I2S). But 1.4 MHz turned out to be incompatible with I2S MEMS microphones which require BCLK/LRCLK ratio of 64, so BCLK was doubled and the low 16 bit slots are ignored.
- Status