Closed mc510 closed 1 year ago
Thanks for the report. Yes, it doesn't look as if the network is a problem, as there seem to be plenty of buffers (each holding 352 frames, about 8 milliseconds of audio). However, the DAC queue does empty, and I don't understand why that should be -- let me have a little think about it.
By any chance, could you temporarily use a USB DAC for output to see if there is also a problem with it?
[Update] Let me suggest that, rather than changing the buffer size, you change the audio_backend_buffer_desired_length_in_seconds
to something like a full second: 1.0
. This will give the system longer to recover before the DAC buffer empties. The downside is that software volume control takes longer to work.
Worth a try, for sure.
Unfortunately I don't have a USB DAC. I did change audio_backend_buffer_desired_length_in_seconds to 1.0 seconds but am still getting the same result.
(Odd thing, and probably useless for troubleshooting, but it seems like at the beginning of an airplay session, these errors are not detectable to my ear but after maybe 20 minutes they've become a very distinct audio dropout.)
Going to be offline for much of the week ahead, but when I'm back I will try upgrading to Armbian/Debian Bookworm. Perhaps its newer kernel and firmware will improve things.
Thanks. Also -- is there any other activity on the device that might periodically result in a burst of I/O?
Well crap, turns out that the latest Armbian (Debian bookworm) release isn't usable on my device.
There's nothing else at all happening on the device; it's dedicated to streaming audio.
However, I just remembered that my USB microphone preamp also has audio output. Hooked it up to the OPi and have been streaming to shairport-sync for ten minutes without any error messages at all. Still hoping that sunxi-codec will get working, but it's good to know that USB audio will work correctly.
Good news: able to get latest Armbian (Debian bookworm) running on my device. Bad news: same issue persists.
Thanks for the update. I see that you've already set the interpolation setting to "basic"
which is a good troubleshooting idea.
Do you have any firewalls going anywhere?
No firewall on the OrangePi. There's a some sort of firewall on the Netgear router, but I wouldn't expect it to be doing anything with the LAN traffic. Who knows with Netgear though. When I get back from vacation I can try swapping in an OpenWRT router, and I'm happy to test out anything that you're curious about ... but given that it works fine with a USB audio device, it seems likely to me that what I'm experiencing is a quirk of the Allwinner SOC/audio codec/firmware/driver.
BTW I tried building with Airplay 2, got the same result.
Thanks. TBH, I'm inclined to agree with your conclusion...
There's actually a couple other error messages that sometimes appear along with (immediately before) the "underrun" messages. No consistency though, sometimes one, sometimes the other, sometimes (as in the example in my original post) neither:
6.465283253 "audio_alsa.c:1769" alsa: SND_PCMSTATE* 3, error -32 ("Broken pipe") writing 352 samples to alsa device. 3.098797002 "player.c:2689" Delay error -32 when checking running latency.
Do these messages shine any light on what's causing the underrun? I'm mostly resigned to abandoning the built-in audio and buying a USB DAC, but thought I'd share these error messages in the interest of completeness.
Solved! I had ignored this asound.conf suggestion from the troubleshooting page, because I'm using onboard audio not a USB audio device. But I went ahead and tried the suggested fix anyways, and two hours of happy listening later I have experienced no dropouts and no error messages. I have no idea what this is doing, but it's working. I just had to change "1" in the example to "0" for my case.
pcm.!default {
type plug
slave.pcm {
type dmix
ipc_key 1024
slave {
pcm "hw:0"
period_time 0
period_size 1920
buffer_size 19200
}
}
}
ctl.!default {
type hw
card 0
}
Well, turns out that I still get a bit of the drop-out thing, so I haven't totally solved it. Quite a bit less though. Except when I was experimenting with streaming from YouTube to shairport-sync ... I was surprised that worked at all, but it was happy to stream only the audio; however, there were a lot of drop outs. I wish I understood what the asound.conf edits actually do, so that I could tinker around and hope to find further improvement ... but I have read that nobody understands alsa and that the only thing that you can do is to try everything and stop when you find something that works! I'm sure that's not exactly true, but it does seem that it might be approximately true 😂.
What happened?
I'm getting a periodic audio dropout of a (noticeable) fraction of a second roughly every minute or so, with with "alsa underrun" and "large negative sync" errors at the same time. (I was also getting a variety of other error messages -- not always with an audio artifact -- with version 4.1, but since I built 4.2 yesterday I've only observed this one symptom so far.) Not sure if #1682 is related; unlike that report I don't see any unusual load on the cpu at any point.
Device is Orange Pi Zero which is renowned for having terrible wifi, but if I'm reading the statistics correctly there doesn't seem to be a network problem? Power management is off.
Audio source is TuneIn streaming radio app on iPhone. Audio device is the built-in sunxi-codec.
I presume that this is more of a "me" problem than a "shairport-sync" problem, but if anyone would help with interpretation of the messages and symptoms I would be grateful.
Relevant log output
Configuration Information.
How did you install Shairport Sync?
Built from source
Check previous issues