Latency and the SGTL500, is there any?

Status
Not open for further replies.

Sharpie

Member
Hello Everyone,

I'm completely new to this forum and Arm processors so please forgive any transgressions.

I'm looking at building a drum machine using a microcontroller and an audio DAC. So far I've used a Microchip 16 bit PIC and a VS1053 board which all works fine except for the fact that there is audible latency between the trigger and the sample being played. I finally tracked this down to the VS1053 itself.

After a fair bit of research I've come to the conclusion that an Arm chip such as the one in the Teensy 3.5 would be a much better option and there is already an audio board available. So, finally, my question. Before I spend 15 or so of my hard earned pounds on the Audio Shield could anyone tell me if there is any latency associated with the SGTL5000 chip itself? The datasheet doesn't suggest any but then, neither did the VS1053 datasheet.

Any help would be greatly appreciated.

Regards,

Sharpie
 
Yes, latency is typically between 6 to 10 ms. I do not believe any human can perceive this latency, but it can be an issue for some types of projects.

Most of that is due to the 128 sample block size. Lower latency can usually be achieved by editing AudioStream.h for smaller blocks. But smaller blocks have higher CPU overhead. A few features don't work at other block sizes, but most things do.

About 0.8 ms of latency is DAC filters in the SGTL5000 hardware, which you can't change.
 
Hi Paul, Thanks for the very quick reply. I'm told that 20ms is the point at which latency is detectable so 6 to 10 would be fine. I've already got a Teensy 3.5 which I chose because of its high clock rate and its large amount of ram. Based on what you've said I'lve ordered an Audio Shield. The idea is to read the sample off uSD and buffer the sample in ram as the samples will be very small. Do you foresee any problems there? I'm a pascal programmer so I'm still wrapping my head around C so any pointers would be very much appreciated.
Many thanks, Sharpie.
 
Do the simplest thing first. Just play files right off the SD card. Unless you have a terrible card, it will probably be perfectly fine.

There's a special optimization in SD_t3.h. It makes the entire SD lib read-only (a limitation to be removed at some point in the future) but greatly optimizes reading the card. Try that next.

If you *really* want to buffer in RAM, perhaps read into arrays and add a 4 byte header to work with the memory player object. But do this last, after trying those other 2 ways!
 
Do the simplest thing first. Just play files right off the SD card. Unless you have a terrible card, it will probably be perfectly fine.

There's a special optimization in SD_t3.h. It makes the entire SD lib read-only (a limitation to be removed at some point in the future) but greatly optimizes reading the card. Try that next.

If you *really* want to buffer in RAM, perhaps read into arrays and add a 4 byte header to work with the memory player object. But do this last, after trying those other 2 ways!

Thanks Paul, I will try those in order stopping when I have a suitable result. I like simple. For some reason it comes to me quite naturally.

Sharpie
 
Status
Not open for further replies.
Back
Top