Replies: 10 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. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Ah yes I just saw that! cool! I'm going to see if I can connect the dots over the next few days |
Beta Was this translation helpful? Give feedback.
-
I'm currently working on updating Rodio to |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions