Shairport-sync on Raspberry Pi, audio corruption after recent updates #1158
Comments
|
Thanks for the post. This is slightly reminiscent of a situation I had with a really very good IQaudIO DigiAmp+ running on a Pi that was updated incrementally. One day, the amplifier stopped working properly and I even contacted one of the developers of the driver used. It seems that the incremental updating omitted or changed a crucial component -- I still don't know which. By erasing the SD card and starting over, my problem disappeared. So, my suggestion it to build a new system, maybe on a separate SD card, and see if the problem disappears with it. |
|
Also having those issues and using a HiFiBerry Amp2. Usually after a reboot, the audio works fine, but there is about 1s delay when streaming to two targets from my Mac Pro. Will try recreating the image (fortunately I already built a custom pi-gen setup). |
|
Good stuff. Just remember that there is an approximately two second delay inherent in Airplay. |
|
I haven't been able to rebuild the system config yet due to the RPi running pi-hole being our DNS & print server so I have to find time to do that out of hours. (Alternately, can I build the OS & software on another RPi4 & swap the SD card without issue?) |
|
I may be having the same/a similar problem. In the last couple of weeks audio started becoming garbled and stuttering when streamed through shairport-sync. This only happens after about a day of uptime and is resolved by a reboot, just restarting shairport-sync does not resolve it. Before this things have been running smoothly for many months. Does this sound similar to your issue? Some technical details: I initially thought this may be related to the firmware change mentioned in this issue: Hexxeh/rpi-firmware#257 However I didn’t see any differences in dma assignment in success or fail cases and since getting the fix my problem hasn’t gone away. Although I have narrowed it down to affecting only shairport-sync as playing audio through other sources (directly with forked-daapd rather than via shairport-sync or directly with aplay) is unaffected. I’m currently doing some more testing and increasing logging to shairport-sync to see if I can get more info. |
|
Reinstalled from a fresh image. So far so good, no distorted audio. Will check back again after the PI has been running for some time. As a side note (I''m aware of the inheret Airplay delay): before the updates Apple Music/iTunes used to sync the Mac Pro and shairport sync and the multiroom experience was great. Now when you walk between rooms they're out of sync… |
That's exactly the same symptoms I'm getting - it's works great after reboot for up to a day, then I get garbled audio (more noticeable with streaming a podcast) or basically no audio (music). You have different hardware to me so that's interesting, but you're on 5.10.x kernel I see... my other RPi4 is running 5.4.x kernel and has no problem whatsoever, though I haven't updated it now for 2-3 months so it could be any of those pending updates. If I knew how to clone the SD card I would do so and update that one to see what happens - will do some research on that! As I mentioned earlier, I get no dropouts using the inbuilt audio out from the Pi using shairport-sync, even after 3-4 days. I've yet to test audio through the DAC using other means... |
|
I'm also on Kernel It should be quite easy to clone a sd-card with balenaEtcher |
Thank you, that's a good idea!
Looking at the issues listed here, I think there's something going on with either the latest kernel versions or RPi firmware: https://www.raspberrypi.org/forums/viewtopic.php?t=288234&start=550 |
|
Well, the clean reinstall did not help. After the night, the audio was garbled again. I'm downgrading the kernel now and will report back again. (According to this, it can easily be done with |
|
Huh, that was quicker than expected. Downgrading did indeed fix the issues of my multiroom not in sync. I'm assuming it also fixes the garbled audio, but only time will tell. Also: I'm not an expert regarding linux/raspbian, so try the kernel downgrade at your own risk! Also, downgrading a kernel this way is certainly not a permanent solution, but rather a temporary workaround. I suspect some changes in the new kernel broke the magic stuff for third party DACs that gives shairport-sync it's name. Unfortunately I'm not deep enough into C and the kernel to debug this further. @mikebrady is there anything I/we can do to help resolve this issue? I'd be happy to try out debug builds and provide further log data. |
|
Thanks for all this information, everyone. It's really puzzling. One idea -- a shot in the dark, really -- is to set the Shairport Sync |
|
I’ve just been gathering some logs, so my system is in a ‘failed’ state and setting use_precision_timing to no and restarting the shairport-sync service solved the problem for me. Thanks @mikebrady Thanks @cleverer for confirming it was a firmware change that broke things. I’m still interested to get to the bottom of what in the firmware has changed things here, maybe we can use rpi-update to narrow it down to a specific change? Or is there more info we can collect here to better report this to the firmware people? |
|
Glad to hear that it did the trick -- I better recheck the software activated by the |
|
Can confirm as well, that was a sniper shot in the dark! 🎉 As a side note, I think the comment here is off (default seems to be auto according to code): Line 256 in 54cb9de |
|
Thanks. According to the config file, the default is “auto”. It wouldn’t have been the first out-of-date comment I’ve ever seen or made! It’ll take a few days to track this down, I’m afraid. |
Yes, config seems to be correct. Just wanted to let you know, but not expecting a change here (after all it is just an internal code comment…) Actually on second thought, I think the comment might even be correct, as an uninitialized variable would be all zeroes… so the variable will default to no. Sorry for the confusion and diverging from the actual subject! |
|
When the issue is occurring, a couple of notable things seem to pop up in the logs, the normally intermittent and benign No SCLK message is spammed constantly and the same messages from shairport repeat for a while as follows: And then the sync error messages appear If more complete logs or any other details would help, let me know. I realised I forget to mention the version of shairport-sync I’m using is the latest from raspbian/dietpi rather than the latest here. |
|
I had this issue a long time ago FYI |
|
Thank you for the "shot in the dark" Mike ! I firstly just restarted shairport-sync while the problem was present, it didn't make any difference. I then set use_precision_timing to "no" in the config and restarted the service and it is working now. I shall have to wait the usual 24+ hours to be sure... If you have time, I would be interested to hear whether you can work out the cause of the problem. I don't know the functionality this setting enables, but given the issue, would it be worth setting the default to "no" for future releases ? |
|
After a bit of faffing when I used a firmware version that wouldn’t boot (whoops) I’ve now got a couple of RPis with DACs one on the old and one on the new kernel/firmware versions. @mikebrady Would tests on different firmware versions using the audio_time tool from alsa-lib be useful? I’ve got it compiled and have been reading https://www.kernel.org/doc/html/latest/sound/designs/timestamping.html although frankly my knowledge level of linux audio is very much closer to dangerous than useful :) |
|
I have two RPis which have been running shairport-sync seamlessly for numerous months. One is running raspian buster with kernel The other RPi is running raspian stretch with kernel |
|
That's useful, thanks. I will look at the problem Real Soon Now. It may well be a bug in Shairport Sync, as I moved the timing code from a fixed-point 64-bit representation a la NTP to a nanosecond-based 64-bit scheme instead. This may have caused, shall we say, an infelicity in the precision timing code. |
|
Thanks for your reply! I had these problems with version 3.3.2, which (I think) pre-dates the timing representation change, as well as with current master. (However, with precision timing enabled and the glitch occurring, my logs are full of |
|
I had been off shairport for a while and recently installed again and found it unusable. The audio is constantly choppy. Once upon a time it would chop for maybe 7 seconds every few days or so streaming from a variety of sources on a variety of networks. I use the iqaudio driver as well |
That’s a wonderful description @mikebrady :) Looking at the release notes did the changes you mention arrive in 3.3.7? https://github.com/mikebrady/shairport-sync/blob/master/RELEASENOTES.md#version-337 Like @ben-willmore I’m seeing these problems on an earlier version, I’m running 3.3.6. |
|
So, just turning to this problem now. Can anyone cause it to happen really quickly? Is so, the receipt would be useful. |
|
I've just now commented out the use_precision_timing = "no" line & restarted but it will not happen immediately I think, working fine right now. When it goes, what info would you like? |
|
Thanks for the quick response. Actually I have found something which I am struggling to explain, but it does look as if the underlying driver has changed its behaviour. Specifically, it looks as if a call to However, I'm not sure which behaviour is correct (maybe both are) -- the alsa documentation is rather opaque. Anyhoo, I've pushed an update in the |
|
With a RaspberryPi that is in a ‘failed state’ (which seems to be one that has been running for over 24 hours and is running the 5.10.17 kernel and firmware) enabling and disabling use_precision_timing and restarting shairport-sync then playing audio seems to be enough to enable or disable the problem. At least that’s what’s working for me (just tested to confirm). Disabling use_precision_timing and restarting shairport-sync OR downgrading the kernel/firmware seem to resolve the issue permanently. Rebooting the Pi resolves the issue temporarily. I’m afraid I don’t have any quicker repro steps than ‘wait for a day’ for a system that has been rebooted. What else can we do to help? |
|
The |
|
Super. Thanks for the update. |
|
I meant to add -- the synchronisation between two Pis in neighbouring rooms is perfect to my ears (though that is also the case with |
|
Thanks, Ben. TBH, I'm not really too sure if the precision timing is any better. A while back, it made a really big difference in the Raspberry Pi's built-in DAC, but that has been fixed since. |
|
Is there anything I should wait for before giving it another shot? What settings should I use with an IQ audio driver dac? Thx |
|
Nothing to wait for — just pull the latest update from the |
|
Alright thx |
|
So, I have an IQaudIO DigiAmp+ and this is the overlay entry in I use the mixer called |
|
I just use the driver for the IQaudio in my project as I have built my own entire system from DAC to speakers. Link.. Thanks |
|
Wow, that looks fantastic. Lovely looking hardware and 300w of clean power per channel is insane! |
|
Thanks Mike |
|
Just FYI, I found another bug in the |
|
This issue has been inactive for 60 days so will be closed 7 days from now. To prevent this, please remove the "stale" label or post a comment. |
- Update from 3.3.7 to 3.3.8
- Update of rootfile not required
- Changelog
Version 3.3.8
**Enhancements**
* Documentation for the MQTT interface. Many thanks to [minix1234](https://github.com/minix1234)!
**Bug Fixes**
* Fix a bug in the `alsa` back end. In the interval between checking that the alsa
device handle was non-`NULL` and actually using it, the handle could be set to
`NULL`. The interval between check and usage is now protected.
* Fix a bug in the `alsa` precision timing code. Thanks to
[durwin99](https://github.com/durwin99),
[Nicolas Da Mutten](https://github.com/cleverer),
[mistakenideas](https://github.com/mistakenideas),
[Ben Willmore](https://github.com/ben-willmore) and
[giggywithit](https://github.com/giggywithit) for the
[report](mikebrady/shairport-sync#1158).
* Fix a bug that caused Shairport Sync to hang, but not actually crash, if an
`on-...` script failed.
* Fix a crash that occurred if metadata support is enabled during compilation but
turned off in the configuration file. Thanks to
[Tim Curtis](https://github.com/moodeaudio) for the report.
* Fix a crash that occurred playing from AirPower on Android. Thanks to
[Ircama](https://github.com/Ircama) for the report.
* Fix the configure.ac file so that `--without-<feature>` configuration options
are not interpreted as `--with-<feature>` options instead! Thanks to
[David Racine](https://github.com/bassdr) for the report.
Signed-off-by: Adolf Belka <[email protected]>
Signed-off-by: Arne Fitzenreiter <[email protected]>
I have an RPi 4 running Raspbian that has been running shairport-sync for something like 9 months without any issues - using Airplay to stream from iPhone 12, audio out through a HiFiBerry DAC+ Pro. Network is Ethernet only. Towards the end of 2020 I installed the then-latest Raspberry Pi OS (2020-08-20-raspios-buster-armhf-lite.img) onto a new SD card, then installed Pi-hole according to the standard process. Once that was up and running, I installed shairport-sync again, following the install process documented here on github (enabling soxr). This ran fine for probably 6-8 weeks, absolutely rock solid.
Then suddenly in early Feb (I think) the process stopped working properly, sometimes the audio would work for a short time, then I would get either silence (with music) or seriously garbled audio (from podcasts etc). Occasionally the airplay device wouldn't show at all - checking with systemctl showed the service was failed/not working (sorry, I didn't grab the exact status). I wrote a cron job to check every minute for the service to be "active (running)" and to restart it if not, and I set the systemd service to auto-restart after 5 seconds if it failed. It seems the service would be fine then if I didn't use it (ie send via airplay) but when I did, the symptoms above re-appeared.
Yesterday I removed all the shairport-sync software, config etc, stopped the cron jobs, rebooted and went through the install again, this time without the soxr support (actual command was "./configure --sysconfdir=/etc --with-alsa --with-avahi --with-ssl=openssl --with-systemd". The only changes I made to the conf file were the airplay name and the Alsa output_device to "hw:1". I'm still getting the same issues.
I suspect this is down to something else in Raspbian being updated (I usually run apt upgrade at the beginning of each month). Looking through the apt history, there were various firmware updates at the end of January, something for systemd in mid-Feb but I can't see any of the libraries that are specified as needed for shairport-sync in the list. I can supply logs as needed...
OS is listed as "Raspbian GNU/Linux 10"
uname -a : "Linux rpi1 5.10.11-v7l+ #1399 SMP Thu Jan 28 12:09:48 GMT 2021 armv7l GNU/Linux"
shairport-sync -V : "3.3.8rc3-OpenSSL-Avahi-ALSA-sysconfdir:/etc"
On a side-note, I have another RPi 4 running a slightly older Raspbian (also "Raspbian GNU/Linux 10" but uname -a shows "Linux rpi2 5.4.83-v7l+ #1379 SMP Mon Dec 14 13:11:54 GMT 2020 armv7l GNU/Linux") also with a HiFiBerry DAC+ Pro, and shairport-sync version "3.3.7-OpenSSL-Avahi-ALSA-soxr-sysconfdir:/etc". This hasn't had any problem at all but I also have not updated the OS (apt upgrade) since discovering the problem on rpi1 as this is my last working combo ! There is no other process running on this RPi currently, though it is destined to probably run Nextcloud
If you have any suggestions how I can troubleshoot this (I've gone through the Troubleshooter here but haven't messed with any latency settings as it has been working fine until now), or any logs I can provide, please let me know. Am I able to down-grade/reinstall an older version of the software ? Sorry, I can't figure out how to get to an older version for the "git clone" command which is I suspect what I need to do (can I copy the folder from my other RPi?)
Thank you!
Jean
The text was updated successfully, but these errors were encountered: