[GH-ISSUE #316] JACK backend must run at 44.1khz

kerem commented

2026-02-27 19:29:25 +03:00

Owner

Originally created by @markubiak on GitHub (Mar 21, 2019).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/316

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.

Originally created by @markubiak on GitHub (Mar 21, 2019). Original GitHub issue: https://github.com/librespot-org/librespot/issues/316 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](https://github.com/Prior99/rust-samplerate), but as before stated the less audio code the better so this may not be the best solution.

kerem

2026-02-27 19:29:25 +03:00

closed this issue
added the
audio
label

kerem commented

2026-02-27 19:29:26 +03:00

Author

Owner

@willstott101 commented on GitHub (Mar 21, 2019):

Interesting. There are rust sample rate conversions in both the Rodio crate (linear) and the sample crate (step, linear & sinc, though I couldn't get sinc to sound OK).

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.

@willstott101 commented on GitHub (Mar 21, 2019): Interesting. There are rust sample rate conversions in both the Rodio crate (linear) and the `sample` crate (step, linear & sinc, though I couldn't get sinc to sound OK). 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.

kerem commented

2026-02-27 19:29:26 +03:00

Author

Owner

@markubiak commented on GitHub (Mar 21, 2019):

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 sample crate? It seems there is a resolved bug where sinc(0) = 0 (should be 1) which would have definitely caused issues.

It's looking like the better options would either be to add JACK support to cpal or add the sample crate to this project. Given the stated desire to minimize audio interface code in this project, the former might be better.

@markubiak commented on GitHub (Mar 21, 2019): 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 `sample` crate? It seems there is a resolved bug where sinc(0) = 0 (should be 1) which would have definitely caused issues. It's looking like the better options would either be to add JACK support to cpal or add the `sample` crate to this project. Given the stated desire to minimize audio interface code in this project, the former might be better.

kerem commented

2026-02-27 19:29:26 +03:00

Author

Owner

@willstott101 commented on GitHub (Mar 22, 2019):

Here's my branch using the sample crate. CPAL doesn't perform any re-sampling itself so a Jack backend based on the jack may well be suitable. However I'm not sure what CPAL's stance is on having multiple backend options for a single platform.

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 sample would be reasonable. Looks like it's pretty similar to my branch in structure.

Perhaps the jack crate ought to be able to perform re-sampling?

@willstott101 commented on GitHub (Mar 22, 2019): [Here's my branch using the `sample` crate.](https://github.com/willstott101/librespot/commit/87745dbf596c0508f40d88185e441e9095518818#diff-8ec2fc01f26a7d53ecc2f058166ff10eR186) CPAL doesn't perform any re-sampling itself so a Jack backend based on the [`jack`](https://github.com/RustAudio/rust-jack) may well be suitable. However I'm not sure what CPAL's stance is on having multiple backend options for a single platform. 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 `sample` would be reasonable. Looks like it's pretty similar to my branch in structure. Perhaps the jack crate ought to be able to perform re-sampling?

kerem commented

2026-02-27 19:29:26 +03:00

Author

Owner

@markubiak commented on GitHub (Mar 22, 2019):

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.

@markubiak commented on GitHub (Mar 22, 2019): 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.

kerem commented

2026-02-27 19:29:26 +03:00

Author

Owner

@willstott101 commented on GitHub (Mar 22, 2019):

Sorry I wasn't very clear there. The options I see are these (in order of tidyness):

Add a Jack backend to CPAL, and use via Rodio in librespot (I agree that this is the best option, for librespot and the Rust audio community).
Add re-sampling to the Jack backend in librespot (probably the easiest option).
Add re-sampling to the jack crate.
Add re-sampling to a different crate which depends on jack, and use that in librespot.

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.

@willstott101 commented on GitHub (Mar 22, 2019): Sorry I wasn't very clear there. The options I see are these (in order of tidyness): - Add a Jack backend to CPAL, and use via Rodio in librespot (I agree that this is the best option, for librespot and the Rust audio community). - Add re-sampling to the Jack backend in librespot (probably the easiest option). - Add re-sampling to the jack crate. - Add re-sampling to a different crate which depends on jack, and use that in librespot. 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.

kerem commented

2026-02-27 19:29:26 +03:00

Author

Owner

@Lcchy commented on GitHub (Nov 30, 2020):

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?

@Lcchy commented on GitHub (Nov 30, 2020): 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?

kerem commented

2026-02-27 19:29:26 +03:00

Author

Owner

@markubiak commented on GitHub (Nov 30, 2020):

Yes! A JACK audio backend to CPAL was recently merged, which makes this a great candidate to work on:
https://github.com/RustAudio/cpal/pull/389

CPAL is the backend for Rodio, which librespot supports. I think that's the way forward.

@markubiak commented on GitHub (Nov 30, 2020): Yes! A JACK audio backend to CPAL was recently merged, which makes this a great candidate to work on: https://github.com/RustAudio/cpal/pull/389 CPAL is the backend for Rodio, which librespot supports. I think that's the way forward.

kerem commented

2026-02-27 19:29:26 +03:00

Author

Owner

@Lcchy commented on GitHub (Nov 30, 2020):

Ah yes I just saw that! cool! I'm going to see if I can connect the dots over the next few days

@Lcchy commented on GitHub (Nov 30, 2020): Ah yes I just saw that! cool! I'm going to see if I can connect the dots over the next few days

kerem commented

2026-02-27 19:29:26 +03:00

Author

Owner

@willstott101 commented on GitHub (Dec 1, 2020):

I'm currently working on updating Rodio to 0.13 which will bring us to latest cpal too. From there it might not be too fiddly to use cpal for Jack: https://github.com/librespot-org/librespot/pull/543

@willstott101 commented on GitHub (Dec 1, 2020): I'm currently working on updating Rodio to `0.13` which will bring us to latest cpal too. From there it might not be too fiddly to use cpal for Jack: https://github.com/librespot-org/librespot/pull/543

kerem commented

2026-02-27 19:29:26 +03:00

Author

Owner

@Lcchy commented on GitHub (Dec 13, 2020):

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: or should I PR on your PR, is that a thing?)

edit: I've opened a PR draft here, it runs without issues, it just needs some more proper integration with the rodio-backend

@Lcchy commented on GitHub (Dec 13, 2020): 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: or should I PR on your PR, is that a thing?) edit: I've opened a PR draft [here](https://github.com/librespot-org/librespot/pull/548), it runs without issues, it just needs some more proper integration with the rodio-backend

kerem referenced this issue

2026-02-27 20:00:12 +03:00

[PR #254] [CLOSED] Fix #209 - clean up zombies of 'onevent' programs #850

kerem referenced this issue

2026-02-27 20:00:12 +03:00

[PR #255] [MERGED] reap the exit statuses from 'onevent' child processes using futures #852

Rows
Columns

[GH-ISSUE #316] JACK backend must run at 44.1khz #209