Closed mutexlox-signal closed 2 months ago
This is expected, the latency parameter is pretty much a hint only. PulseAudio also tends to show the widest variance of the backends we support.
FWIW, it's good practice to use Context::min_latency()
rather than hard code latency values.
Good to know, thank you!
Using cubeb-rs with cubeb-pulse-rs as a backend, I have written some code (excerpted below) that requests a recording sample rate of 48k Hz with a latency of 480 frames (so, the data callback should be invoked at 10ms intervals, with 480 frames each time). The underlying library I'm using, webrtc in chromium, is inflexible about this, and will trip debug assertions if given data at a different frequency than precisely 480 samples in each API call (when given a sample rate of 48,000).
On windows and mac, this more or less works fine with a bit of finagling (for example, on windows, a latency less than 22ms is not well-supported so I have to request a higher latency initially and then batch), but cubeb-pulse-rs shows weirder behavior.
Specifically, each invocation of the data callback happens at roughly 5ms intervals, with roughly (but not exactly) half of the number of samples I would expect. In practice I see anywhere from 142 to 288 samples in one invocation.
Is it expected that the latency requested will not always match the actual number of frames provided to the data callback / the latency at which the callback is invoked?
Code snippet:
Log excerpt from the log line shown in that code snippet: