-
-
Notifications
You must be signed in to change notification settings - Fork 580
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
[Problem]: sync errors when JACK running != 44100 Hz #1926
Comments
Also tried various buffer sizes for the JACK server, from 16 (works for 44k1) up to 512. |
Thanks for the post. Not sure what might be happening here -- maybe some It's probably worth checking how busy the computer gets -- something like |
Here's a 8s sample of CPU usage Screen.Recording.2024-10-31.at.07.39.41.mov |
Thanks. Am I right in thinking that this system is also running PulseAudio? |
That's correct. PulseAudio has its output configured to JACK instead of ALSA. The "owner" of the sound device on the Pi is JACK. PulseAudio is there for serving Bluetooth clients only.
|
Thanks. Does Shairport Sync work if |
Just double checked, no audio for both sample rates. The buffer size was 256. The log shows the same sync errors, however at a much slower rate compared to 192Khz. So the higher the sample rate is (> 44100), the more frequent the sync errors show up in the log. |
Thanks -- that might be useful! |
So, I think I may have found an error: the latency was being reported back to Shairport Sync in terms of the number of frames at the Jack Audio server's rate (e.g. 192k) rather than Shairport Sync's own rate (i.e. 44.1k). I think I've fixed this and pushed an update into the Consequently, I'd be grateful if you would try it out and report back... |
Thanks, just tried b221e13. Still no audio, but now only two sync errors pop up immediately upon playing play on the sender, no matter what's the sample rate. Then log is clean. Looks like an improvement. 48000
88200
192000
|
Wait... it works! but I had to reboot the Pi before trying 192000, weird. So far I've been restarting JACK, recompiling shairport-sync, starting with --verbose and stopping with Ctrl+C. Then repeating the cycle. |
I repeated the test with master branch and a reboot in the middle to double check, and audio is broken. So yes this definitely fixes the problem. Wondering what the reboot is doing... JACK is started via D-Bus so there might be something there. SoX resampling quality is set to very high and the Pi still shows < 10% CPU load. Awesome. Thanks a lot! |
Yikes, that's all a bit weird, but it's good to see that it's working. I'm not any kind of expert on Jack Audio, I'm afraid, so I don't know if a D-Bus restart is completely "clean". Is it too soon to declare victory, I wonder? 🙂 |
Oops... just realized the test cycle was flawed, shaiport-sync doesn't automatically connect to the JACK output ports on startup, that has to be done manually. That is achieved on the Pi by a startup script -- explains why the reboot. So the observations about output being silent were wrong. When there are multiple sync errors, audio stutters but it is not silent. Auto connection of ports would be a nice addition, some JACK apps do it. The lonely sync errors three comments ago were caused by So now everything is under control, I will test this more (aka listen to music for an extended period) and report back. Thanks. |
Flawless, this issue report can be closed. |
Great -- thanks for improving Shairport Sync! |
What happened?
jack_simple_client
-> test tone audiblesoxr_resample_quality = "quick"
and startshairport_sync
Notes:
soxr_resample_quality
values with same resultaudio_backend_buffer_desired_length_in_seconds
andresync_threshold_in_seconds
(had them tuned for the working 44k1 setup).Possibly related to #1917 ?
Relevant log output
System Information.
Configuration Information.
PulseAudio or PipeWire installed?
How did you install Shairport Sync?
Built from source
Check previous issues
The text was updated successfully, but these errors were encountered: