Maybe we don't need an internal buffer for the ALSA backend? #806
Replies: 2 comments 71 replies
-
What do you mean "worth the trouble"? This is the usual way to use alsa but you want to ignore that because this seems to work in the environment you have? If it ain't broke... mess with it until it is? I say leave it alone. |
Beta Was this translation helpful? Give feedback.
-
Alsa caters to a huge palette of sound cards each with their own idiosyncrasies. I think that the current start threshold is something that's quite common in the wild, for what that's worth. In the initial implementation at 64081a1 @sniperrifle2004 said:
So I don't know but which PCMs would be sensitive to this? |
Beta Was this translation helpful? Give feedback.
-
I was playing with maybe implementing a proper ring buffer as the internal buffer in the
alsa
backend (maybe https://docs.rs/rtrb/0.1.4/rtrb as @roderickvd suggested a while ago) and as a sanity check I removed the oldvec
internal buffer and just changedswp.set_start_threshold
to be the size of the entire buffer and dumped bytes directly to the PCM. And well it seems to work just fine. The original logic behind the internal buffer was to save CPU cycles and prevent underruns. I notice no CPU usage difference even on a PiZero and I think changingswp.set_start_threshold
takes care of underruns for us by not starting until the buffer is full (the buffer fills much, much faster than realtime. It does not take 0.5 sec to buffer 0.5 sec of audio) and putting us on the tail end of it if you like as far as filling it. From what I understand of the rest of the internals tracks are already buffered to disk or memory anyway. I don't really think another internal buffer is worth the trouble. I could very well be wrong I look forward to any thoughts.Here is a branch I created to test out if anyone would like?
Beta Was this translation helpful? Give feedback.
All reactions