not-fl3
Reduce latency on Alsa
This is good for games where there are many sounds in quick succession. Otherwise the sounds in quick succession will be played at the same time.
All I did was uncomment the code checking how many frames can be delivered, and then create a slice with that size using std::slice::from_raw_parts_mut.
However, there was a comment for the commented code that said it randomly panics sometimes. I haven't encountered any panics with this, but I am wondering if they are just really rare? Or if this implementation just did not have any panics?
If want to use quad-snd under described circumstances, this is one way to use this patch:
[dependencies]
macroquad = { version = "0.4.14", features = ["audio"] }
radian = "0.1.3"
[patch.crates-io]
quad-snd = { git = "https://github.com/InZan17/quad-snd", branch = "Reduce-alsa-latency" }
Mmh I think unfortunately this does not work well for me in release builds. I don't see any output in terminal, but audio quickly dies. :( Situation in debug builds is much better.
There was a comment talking about random panics but I was never able to get them myself. I would be interested in trying to fix it though.
Could you give me a code example where this issue happens?
@InZan17 Yes. I'd be super glad to pair on it. I know very few about concurrency in rust and alsa. Are you in the discord channel? The panic would happen in sys::snd_pcm_wait in alsa_snd.rs . The return code indicates there is a EPIPE issue, which would hint at under- or overflow. I dont manage to recover from that with snd_pcm_recover.
It can happen during the first sample played, or later at any time. My hunch is that the more println statements I put in the threads loop, the less it happens (which would point at a concurrency issue).
@fwolfst Yeah I'm in the discord, my tag is @inzan17. I've tried to recreate the issue you're having but I haven't been able to. You say the more print statements you put the less it happens, does it also happen less if you try sleeping the thread for a little bit?