PDA

View Full Version : Audio Latency



Maxxist
05-12-2016, 12:25 AM
I was wondering what the latency is on the Teensy 3.2 from the ADC input to the DAC output running through the Audio Shield.
I know there may be addtional latency introduced due the programing I may use - but for now
lets say the I will be inputing signal with a mic and the sending it right back out Audio jack.
Would there be significant changes if I used different sample blocks sizes (i.e. 32, 64, 128).
Thanks
Mark

PaulStoffregen
05-12-2016, 01:12 AM
Good question. Here's a quick test to find out. I connected a function generator with a triangle ramp signal and ran File > Examples > Audio > HardwareTesting > PassThroughStereo. I used the left line-in and left line-out pins, since they're easiest to access with oscilloscope probes.

7147

So there's the answer, 6.48 ms latency with a real signal from input to output.

While this was the line-in, I'd expect the mic input should be the same... but not nearly as easy to test with a function generator and scope!




Would there be significant changes if I used different sample blocks sizes (i.e. 32, 64, 128).


Yes, it should. Approx 5.8 ms is almost certainly from two block delays. The remaining 0.68 ms is probably delay in the ADC and DAC within the SGTL5000 chip.

Many part of the library will automatically adapt to smaller block size. But some areas, like playing files from the SD card have assumptions about the 128 sample block size.

adrian
05-12-2016, 03:05 AM
i'm a latency nutcase, so I am very interested in this...

If line in to line out doesn't adapt to a smaller block size, what areas of the libary do???

6.48ms is pretty good round trip latency, by the way. Quite acceptable to many people for real-time audio (accepting there will be another ms or two for actual processing)... at least one of the oldschool rack digital guitar processors i used to use was prolly about 6ms, and i didn't mind that at all, really. Its like standing an extra 6 feet from your guitar speakers or something ...totally doable. I felt comfortable with even a bit more latency in the studio environment.

But is there any way to get down to 64 samples reliably? below 5ms round trip latency would be, well, pretty amazing ... thats in the OMG league for realtime processing, even with a bit more overhead for actual processing.

Was there any reason to choose 128 samples for the buffer?

B.Jacquot
05-12-2016, 03:25 AM
Was there any reason to choose 128 samples for the buffer?

A total guess: 128 16-bit samples * 2 for stereo == 512 bytes == one sector on an SD card.

PaulStoffregen
05-12-2016, 03:39 AM
If line in to line out doesn't adapt to a smaller block size, what areas of the libary do???


Those very likely do adapt properly. All the input & output objects probably do.

FFT and SD card access are the ones likely to have trouble. But very little testing has been done at other block sizes. Who knows, maybe the SD stuff works. I haven't tested...



Was there any reason to choose 128 samples for the buffer?

Yes, efficiency. There's overhead to be suffered for each block processed. Doing all that work once every 128 sample is much more efficient than doing it twice or four times as often (64 or 32 sample blocks). Doing it even every 256 or 512 samples would be more efficient, but 128 was chosen as a compromise between efficiency and latency.

If you want to try another compromise, just edit AudioStream.h and recompile. If you can confirm something doesn't scale properly, open an issue on github about it. Or if you're able to fix it, send a pull request.

The good news is quite a lot of the library probably works at any power-of-2 size down to 16, maybe even 8 samples. Most of the synthesis and effects ought to work. It's things that have to interface with other externally defined data sizes that are likely to have trouble.

adrian
05-13-2016, 02:56 AM
That is very interesting .... I remember, from a wee while ago, that the FFT code was predicated on 128 block size, so that would be one area that would need a bit of a rewrite (I did actually have a go at rewriting it to include imaginary values in the output data array (for convolution), so 'thinking backwards' I may be able to have a go at making the hardcoded block size smaller .... a block size of 32 would, I suppose, put considerable strain on things on the basis of 'too frequent' fft calculations .... Hmm I will have to get back into this ....but first I want to play with Karplus-Strong ... so many things so little time. And I *just* got a new purple teensy from OSH to play with (along with my pcb order ...) ... happy days.

block size down to 32 would be 'amazing'.

LeolaLario
05-17-2016, 05:34 PM
Hi..i am new to this forum and by profession i am an engineer. As per my knowledge 6.48ms is pretty good round trip latency. Quite acceptable to many people for real-time audio.At least one of the oldschool rack digital guitar processors i used to use was prolly about 6ms, and i didn't mind that at all, really. Its like standing an extra 6 feet from your guitar speakers or something.

pcb assembly (http://www.7pcbassembly.com/)

adrian
05-17-2016, 09:41 PM
Hi..i am new to this forum and by profession i am an engineer. As per my knowledge 6.48ms is pretty good round trip latency. Quite acceptable to many people for real-time audio.At least one of the oldschool rack digital guitar processors i used to use was prolly about 6ms, and i didn't mind that at all, really. Its like standing an extra 6 feet from your guitar speakers or something.


Hmm ... I am not an engineer and I think exactly the same as you @LeolaLario ... are you a robot?