stm->queuebuf_len is the length in bytes of one buffer of the queue. It's the latency parameter in cubeb_stream_init. We were dividing a sample-rate in Hz by a number of bytes. Somehow it didn't break when using int16_t, typical values for stereo, 44100Hz, 100ms latency parameter (4410 frames):
and this breaks, only having a single buffer in the queue doesn't work. I don't think we need to increase the buffer size anyway, for duplex, since it worked well with a number of buffers of 2 (and this is what others are doing as well).
This was completely incorrect:
stm->queuebuf_lenis the length in bytes of one buffer of the queue. It's the latency parameter incubeb_stream_init. We were dividing a sample-rate in Hz by a number of bytes. Somehow it didn't break when usingint16_t, typical values for stereo, 44100Hz, 100ms latency parameter (4410 frames):I'm switching to using f32 audio, so it was:
and this breaks, only having a single buffer in the queue doesn't work. I don't think we need to increase the buffer size anyway, for duplex, since it worked well with a number of buffers of 2 (and this is what others are doing as well).