I'm running into this pretty weird issue with the audio VDEVs on Linux, where the data callback in build_output_stream() is never called, because the stream worker thread spawned by this blocks on the following line in src/host/alsa/mod.rs in CPAL:
let res = alsa::poll::poll(descriptors, *poll_timeout)?;
This seems to only happen in the VDEV though. On platforms with this issue, running examples/beep.rs for example works perfectly fine. So I'm suspecting this maybe has something to do with running in dynamically loaded code, though I really have no idea what that something could be exactly at the moment.
CPAL on FreeBSD doesn't exhibit this issues whatsoever.
This leads to the question: should we just use cubeb instead? Super cross-platform, mature, and had Rust bindings too anyways.
I'm running into this pretty weird issue with the audio VDEVs on Linux, where the data callback in
build_output_stream()is never called, because the stream worker thread spawned by this blocks on the following line insrc/host/alsa/mod.rsin CPAL:This seems to only happen in the VDEV though. On platforms with this issue, running
examples/beep.rsfor example works perfectly fine. So I'm suspecting this maybe has something to do with running in dynamically loaded code, though I really have no idea what that something could be exactly at the moment.CPAL on FreeBSD doesn't exhibit this issues whatsoever.
This leads to the question: should we just use cubeb instead? Super cross-platform, mature, and had Rust bindings too anyways.