Hi Dave,
I always use blocking mode and "hw" direct hardware device, each IO in own thread. Non-blocking mode will never be as fast as blocking mode if the IO thread is always blocked in its duty.
Take a look here:
It took me a while to get this code perfect to my purpose (with a reasonable low latency of 1024 frames).
Btw, turn off the HDMI audio, so you get only the sbitx sound card (unless you use it, of course).
- Rafael
toggle quoted message
Show quoted text
On 1/2/24 16:54, Dave, N1AI wrote:
On Tue, Jan 2, 2024 at 11:41 AM, Rafael Diniz wrote:
I made some work on ALSA in my branch, to genlock it to the
loopback, and also reduce the under/overruns. The secret is the
period size and nr of periods you use. Also, using mmap'ed IO
improves a little bit. Also, dont use also plugins, as we can not
control what they do. So better, if possible, always keep with the
direct hardware "hw" devices.
I will explore the changes in your branch but I *think* the test program shows that (a) using non-blocking mode is a win overall, it avoids under-runs and works because we are governed by the speed of the codec, but (b) to use non-blocking mode you do need to use the plughw device to re-buffer the stream.? I could be convinced otherwise.
I presume we see under-runs and hear the crackling noises because the thread writing to the codec gets stalled.? There may be other ways to fix that issue by having better parallelism. That would allow us to go back to blocking mode if using plughw is problematic.? As I wrote I'm just now getting more familiar with the code, getting to know its run-time dynamics will come later for me.? For now, using blocking mode and plughw seems to me to be a step forward.
--
Regards,
Dave, N1AI
