-
Notifications
You must be signed in to change notification settings - Fork 344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed BufferSize not functioning as expected #495
Comments
Tested this on osx and it functions as it would be expected. On my Arch system, I'm using ALSA. |
Can confirm, I also noticed this recently on ALSA (on NixOS). |
@mitchmindtree can you point me in the direction of the problem? I'm happy to dig into if you can give me an idea where to start. |
I think I would start by checking how the I would then maybe look for documentation and example demonstrations of specifying the buffer size in ALSA and see if there's anything we are missing or doing incorrectly. Support for buffer sizes was only introduced recently in #401. Hope this helps a little bit! |
Thank you. That helps a lot - I'll take a look. The first buffer seems to be requested correctly, but then the following buffers are of seemingly random sizes. |
I believe there are multiple (possible) factors at work here:
|
Right now, the way the ALSA worker threads in cpal work is as follows:
This means, in general, that every call to the callback will receive a differently sized buffer, the size of which will depend on exactly when the worker thread queries the available buffer space. It should average to close to the In my opinion, a better approach would be to allocate a buffer sized to I have a rewrite of the ALSA worker threads that incorporates this change, among other changes that fix some various bugs I've been experiencing with the current implementation, that I plan to submit as a pull request after #520 is merged. |
This all sounds great. After it's merged, I think I'd be able to transition WereSoCool from portaudio to cpal. Thank you for taking the time to work on it. |
Hi @alexmoon, #582 (which is a rebase of #520) has been merged. That should unblock your plan for a rewrite of the ALSA worker threads. In fact, I've taken your branch master...alexmoon:alsa-worker and rebased it on cpal master: master...strohel:alsa-worker The last extra commit is my attempt to make user-visible behaviour consistent with other backends, but may be off. With it applied, I get buffer sizes exactly as requested. If you want to drive that effort that would be cool. If not, I can submit that as a PR myself once I familiarize myself with the code. |
What can be done to help making this progress? |
Can confirm the problem with Pipewire and the Alsa drop-in replacement ... the blocksize isn't as random as in the original post, but the buffer size changes from the first to the next block. |
For those who are still struggling with this, if you are using Pipewire, there's a way to force buffer size and sample rate through terminal.
I don't know how this could be implemented in cpal, but after playing a bit with For further reading, this thread contains a lot of useful information. |
I'd like to switch to cpal from rust-portaudio, but I'm unable to reproduce the same behavior.
When using the
beep.rs
example. When I set the buffer size via the config like this:and then inspect the size of the output buffer length, these are the lengths I see.
Is there a way for me to guarantee a fixed buffer size?
I am on Arch Linux.
Thank you!
Danny
The text was updated successfully, but these errors were encountered: