glava
glava copied to clipboard
jarcode-foss
UPS is very low or zero with A2DP Bluetooth earbuds, GLava might freeze when audio not playing sometimes
Setting PULSE_LATENCY_MSEC to something like 10 increases UPS to ~50, so this might be a Pulse issue
This is definitely a PulseAudio issue, but I may be able to fix it in GLava since there's no reason why monitor input latency should be relevant, given it is threaded.
On another note, you can work around this by setting up a default (null) software sink for your sound and having GLava get input from that. It will not have latency issues then, but you will be limited to software mixing.
The latency is caused by reading PCM data from high latency devices.
I may have to stop using the pa_simple API and use pa_stream_connect_record's pa_stream_flags_t flags argument to specify PA_STREAM_ADJUST_LATENCY.
See from the documentation:
If PA_STREAM_ADJUST_LATENCY is set, then the tlength/fragsize parameters will be interpreted slightly differently than described above when passed to pa_stream_connect_record() and pa_stream_connect_playback(): the overall latency that is comprised of both the server side playback buffer length, the hardware playback buffer length and additional latencies will be adjusted in a way that it matches tlength resp. fragsize. Set PA_STREAM_ADJUST_LATENCY if you want to control the overall playback latency for your stream. Unset it if you want to control only the latency induced by the server-side, rewritable playback buffer. The server will try to fulfill the clients latency requests as good as possible. However if the underlying hardware cannot change the hardware buffer length or only in a limited range, the actually resulting latency might be different from what the client requested.
What is likely happening with your hardware is that the default fragsize when reading from the hardware (in the PulseAudio server) is overrunning the buffer defined by maxlength, causing fragments subsequently sent to be truncated, and thus reduced reads (UPS).
@Alex-gnzl The mentioned commit should fix this, however, latency may be very high without explicitly specifying PULSE_LATENCY_MSEC, resulting in a visual lag in GLava from the audio. I will keep this issue open so I can fix that related problem some other time.
Pulse audio is a steaming pile of garbage You can set pa steam adjust latency in Pauvcontrol and spoiler alert it does nothing half the time, the other half the time it slows down audio (and only shows down)
Edit: misjudged stream adjust to be the latency bar in pavucontrol
But I just had this idea, do you think we can make the gl window update async and read the audio buffer as it’s being updated, clearing the buffer and then setting in the values when we start copying them over from the actual buffer (did that make sense?)
But I just had this idea, do you think we can make the gl window update async and read the audio buffer as it’s being updated, clearing the buffer and then setting in the values when we start copying them over from the actual buffer (did that make sense?)
You may want to read the source more closely, as this is exactly what it does in practice (and more). Audio updates are handled in a separate thread and are written to a briefly locked set of buffers that the main thread can later use. Interpolation also leverages this to calculate frames in between audio updates.
Pulse audio is a steaming pile of garbage
This is a bit of an unwarranted generalization. I question why options like PA_STREAM_ADJUST_LATENCY are not default in the server, but that was probably a design choice made long ago.
Adjusting default-fragments (to 5) and default-fragments-size-msec (to 25) improved it from 30 (compiled after your commit) to 50 UPS.
@Alex-gnzl yeah, looks like I will need to set PA_STREAM_ADJUST_LATENCY and confirm the values from the server, which will make your settings to default-fragments and default-fragments-size-msec irrelevant. This is generally a better option anyway, since you can tell PulseAudio to determine the maximum audio buffer size to use itself, instead of guessing, and default-fragments-size-msec will match the frequency of requested buffers from GLava.