-
Notifications
You must be signed in to change notification settings - Fork 654
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
JACK backend must run at 44.1khz #316
Comments
Interesting. There are rust sample rate conversions in both the Rodio crate (linear) and the I expect using either of those would be work pretty well. I have an example of using cpal and the sample crate locally, as a librespot backend... it's a bit buggy. I'll point it out once I'm home and perhaps have a closer look at the Jack backend. |
So after a bit of looking through both, if Rodio could output to a JACK server, that would definitely be best. It uses cpal for audio output, which on Linux, goes thru ALSA and not JACK. When did you try sinc interpolation on the It's looking like the better options would either be to add JACK support to cpal or add the |
Here's my branch using the I'd be tempted to say that the JACK backend for librespot is broken because it doesn't re-sample, and that a PR using Perhaps the jack crate ought to be able to perform re-sampling? |
If the route you're interested in taking is to add resampling to CPAL, that should be taken downstream as Rodio uses CPAL as well. Not sure where it would fit but adding a CPAL and Rodio backend feels wrong. I agree that the JACK backend is broken since it doesn't do resampling. There seems to be a desire to move audio transport code out of librespot and to other separately maintained crates. My personal preference would be to add a JACK backend to Rodio and remove JACK from librespot entirely. |
Sorry I wasn't very clear there. The options I see are these (in order of tidyness):
My branch is experimenting with explicit re-sampling in librespot to allow us to use CPAL directly without Rodio. Hopefully it never needs to be used and any issues we have with Rodio can be resolved upstream. |
Hi, do you have any update on this issue? I am new to the rust audio world but would be motivated to look into this issue as I am experiencing the missing resampling with the jack backend. As I understand, the way to go is to add a jack backend to CPAL? |
Yes! A JACK audio backend to CPAL was recently merged, which makes this a great candidate to work on: CPAL is the backend for Rodio, which librespot supports. I think that's the way forward. |
Ah yes I just saw that! cool! I'm going to see if I can connect the dots over the next few days |
I'm currently working on updating Rodio to |
Ok I included the jack host into the rodio backend using your PR branch @willstott101 and it seems to work :) I can use jack as a rodio output device without resampling issues. When the PR gets merged I can open a new one to add the feature edit: I've opened a PR draft here, it runs without issues, it just needs some more proper integration with the rodio-backend |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
I'm using the JACK Audio Connection Kit backend for librespot, as I find it extremely capable and stable. However, using the JACK backend for librespot, I have to run the entire server at 44100hz or the audio is completely off pitch. This is clearly due to a lack of sample rate conversion. After checking a few JACK playback programs, it seems the common solution is to use libsamplerate (Secret Rabbit Code) to do the rate conversion to the sample rate the JACK server advertises - ie, sample rate conversion is not built into JACK clients by default.
I found basically untested libsamplerate bindings for Rust, but as before stated the less audio code the better so this may not be the best solution.
The text was updated successfully, but these errors were encountered: