Skip to content

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

Closed
markubiak opened this issue Mar 21, 2019 · 10 comments
Closed

JACK backend must run at 44.1khz #316

markubiak opened this issue Mar 21, 2019 · 10 comments
Labels

Comments

@markubiak
Copy link

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.

@willstott101
Copy link
Contributor

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.

@markubiak
Copy link
Author

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.

@willstott101
Copy link
Contributor

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?

@markubiak
Copy link
Author

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.

@willstott101
Copy link
Contributor

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.

@Lcchy
Copy link
Contributor

Lcchy commented 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?

@markubiak
Copy link
Author

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

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

@Lcchy
Copy link
Contributor

Lcchy commented 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

@willstott101
Copy link
Contributor

willstott101 commented 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: #543

@Lcchy
Copy link
Contributor

Lcchy commented 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

@librespot-org librespot-org locked and limited conversation to collaborators Feb 22, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
Projects
None yet
Development

No branches or pull requests

5 participants