minimum reasonable buffer size on ESP32?

[haklein]

Are there any lower limits in terms of what a resonable buffer size is for low latency applications on an ESP32? My goal is to instantly have audio feedback when a key is pressed, with the least possible latency and an envelope to avoid clicks (ADSR). Application is a sine wave sidetone for a morse/cw trainer, and goal is to avoid resp. minimize any delay between pressing the key and hearing the sidetone. So it's pretty much a simple on and off for a sine.
I'm using config.buffer_size=16 for the I2Sconfig and also have set a copy size of 16 for the stream copier (copier = new StreamCopy(*volume, *effects,16);). For ADSRGain I'm currently using ADSRGain(0.05,1.0, 1.0 , 0.008). Is there any drawback from using such a relatively small buffer? The copier is running in a separate task, pinned to core 1 with configMAX_PRIORITIES - 1 prio. I didn't see any negative effects from that but I'm very new to the audio tools and hence reaching out to feedback from more experienced users.
Are there any other options to minimize ADSR keyOn/keyOff latencies or does anybody have better recommendation for the ADSR parameters?

thanks in advance, Hari

[pschatzmann]

If my calculation is right: for mono 16 bit at 44100 samples per second, a 1024 bytes buffer leads to a delay of 11 ms.

Studies have shown that sound reflections in an acoustic space must be delayed by 20 to 30 ms before your brain will perceive them as separate.

So a buffer size of 16 does not really make any sense and most likely will not render a clean tone because of the involved overhead. I would start with 1024 bytes and half the values until you get some acceptable result.

Did you measure the effective delay ? I am surprised that you even consider this as an issue....

ps. ADSR is trying to simulate some "instrument". If you are interrested just to output a sine tone, I would recommend to use Fade functionality instead.

[haklein]

Hi Phil, I did use the default buffer size at first and my code sending was quite impacted by the latency. And I'm far no expert, I was using paddles (holding one of the two keys automatically generates dits resp dahs until you let off the key) at 18 words per minute. Some folks have more than twice my speed. While the brain tried to anticipate the introduced delay, I was often releasing the key too late generating additional dits or dahs. It just didn't feel right. I don't know where the threshold is, will see if I can find a study or paper on that.
At a size of 32 the tone does sound good, and no noticeable delay. I was using it for about an hour. I guess I'll hook up a scope to the key and the audio channel and measure the true delay these days. What minimum size would you esteem to be reasonable from the code overhead perspective?
Thanks for the hint with the fade. Yeah, I'll just want to output a sine that sounds "nice" (with ramp in/out and without any clicks in the speaker). I'll have a look at that.
br Hari

[pschatzmann]

Not sure what you mean with 18 words per minute.
You should not go below a sample rate of 8000 samples per second!

[haklein]

Here is an example at 50 words per minute (which is surely on the very extreme side): https://www.youtube.com/watch?v=q_ZEwZzuqW0

[pschatzmann]

Ah, you talk about 50 words in morse code!

ps. in order to figure out if ADSR makes any sense, just look at the sound of a single tone e.g. in Audacity. If it looks like this, you have a case.

If it is just a constant tone you should not use ADSR.

[haklein]

While I didn't find some scientific paper or something similar after a quick google search, there was a recent sidetone latency issue discussion with a shortwave radio:
I think the complaint was that when you squeeze the paddle, you really want to hear the sidetone with very low latency. It doesn't matter as much how long it takes for the RF to start. I think in the case of QMX there is both a too-long delay from key closure to sidetone ramp-up being started, AND it is a relatively slow ramp (10%-90% approx 5ms, in total 8.5ms) so it makes it seem even longer until you start hearing it. I worked on both these problems, I made the ramp 10x faster, and reduced the latency until it starts.
So a latency of multiple ms is noticeable and will interfere with they keying of the telegraphist.

[haklein]

ps. in order to figure out if ADSR makes any sense, just look at the sound of a single tone e.g. in Audacity. If it looks like this, you have a case.

It would look like that but without the decay, so just attack to full level, sustain until key off then release, like this (from https://spinorlab.wordpress.com/2016/05/28/clickless-cw-sidetone-2/ ):

[pschatzmann]

If you select the copy size to contains always (a multiple of) full sine waves, you should be able to get away with the need to do any Fade/ADSR.

Another option would be to use the PoppingSoundRemover converter class which removes the audio before and/or after the first or last 0 transition.

[haklein]

ok that's a good point, I will give this a try for sure. So with a sample rate of 44100 16 bit one channel and assuming 700Hz for the sidetone I would call copier.resize(63 * 2) for this specific frequency?

[haklein]

@pschatzmann I think I cannot get a nice sound without a ramp even when just changing during zero crossings, this is an audible example of a "bad" (without ramp, 0ms rise/fall time) and a "good" (5-6ms rise/fall) sidetone: https://soundcloud.com/chaseology/hi-per-mite-cw-bandpass-filter
Just for the records: I'm quite happy with how it sounds with the current ADSR settings (0.05,1.0, 1.0 , 0.008). So I guess my approach will be to use a Fade instead of an ADSR (as I do not need the "decay" part) and measure latency for different I2Sconfig buffer sizes to find a reasonably low latency at a high enough buffer size.
Thanks for all your great advice, I have a lot of items on the todo list now for further tests.

[haklein]

I'm quite happy with that waveform (recorded with audacity, generated with 44.1/16b/2ch and 32byte buffer, ADSR(0.005,1.0, 1.0 , 0.003)). For the Fade effect I didn't really see how I would define ramp durations. So I'll likely will stick with the A(D)SR also because the keyOn/keyOff is convenient. Didn't measure latency yet, but larger buffers quickly give a sluggish feeling. Will follow up with some real measurements.