Closed joerg-krause closed 9 years ago
Hi Jörg. This looks like a WiFi problem to me:
Error sendto-ing to timing socket: Network is unreachable
indicate that the system is offline for some reason.If you search the internet for the phrase cfg80211: Calling CRDA to update world regulatory domain
, you'll get lots of hits – and BTW these messages are are definitely not coming from Avahi; they seem to be generated by the WiFi driver. Similarly, a search for the phrase brcmfmac: brcmf_cfg80211_del_key: invalid key index
might be rewarding – there's lots of stuff out there.
So, I'd be looking to see what is causing the cfg80211: Calling CRDA to update world regulatory domain
messages in the first place. Could it be bad or incompatible WiFi drivers or devices, as seems to be the consensus on the web (though there is more heat than light out there, TBH)? Another, more remote, possibility is the WiFi and/or the USB systems are going into a standby or power-down mode (see one of the closed issues here – https://github.com/mikebrady/shairport-sync/issues/29 – for a conversation about this possibility, but in a different context). Another possibility is a sudden external event, like a microwave oven being used in the vicinity. But it really looks to me like shairport-sync is not the cause of the problem. Let me know what you think.
Hi Mike,
many thanks for your feedback!
I found the reason for the collapse. I've a second audio device with same hostname and same MAC address. It's a test device which repeatedly turns on and off.
If this second device connects to the network router, the router drops the connection for the running audio device and sends the UDP packets to the second device. The device running shairport reconnects, but connection is dropped almost immediately by the network router. That's why the cfg80211
messages. At some point the wifi driver is dying which produces the Error sendto-ing to timing socket: Network is unreachable
.
So, in this case it's not a problem caused by shairport. But what I would like to see is that shairport stops playing to the alsa device so that the alsa device stops running and producing the underrun interrupts. What do you think?
That is good news indeed. Regarding your last point, if I remember correctly, once underrun has occurred once, shairport sync stops playing to the ALSA device until it gets more packets. So, if the link had broken "cleanly" with no further packets, you'd see just one underrun message. AFAIK, from the device's point of view, underrun is harmless. If shairport-sync was modified to stop playing permanently after an underrun, I think it would cause major problems.
I'm not sure if I understand you correctly.
What I can see from the debug log above is that shairport-sync is receiving an audio stream and starts to send the audio packets to the alsa device.At some point later the connection trouble begins. What I've seen from the kernel log is that the shairport device gets connected to the network router, but authentification is refused (because of the second device with the same name and MAC) and the connection is disconnected. The cfg80211
message is caused by wpa_supplicant
(this I learned for now) and has something to do with authentification. The wiireless driver kernel stacktrace is a warning and has also something to do with authentification. So far, so good.
My question is why shairport does not stop to write data to the alsa device? For my it looks like shairport does not stop reading data from the audio buffer and as a consequence the alsa device permantly underruns. If the audio buffer pointer returned by buffer_get_frame
is null
then nothing will happens. But it seems it is not. Looking at buffer_get_frame()
shows that curframe
is not initialized with null
(or 0). Maybe that's causing the trouble here?
buffer_get_frame
will sleep on the pthread_cond_wait
if no packet frame is available. It will only return a frame to its caller if a frame becomes available, or if a silent frame should be provided. It will only supply a silent frame if there are some non-empty frames later on. If there are no new frames, it will not supply any frames at all. So, the thing is, shairport-sync actually does stop sending data to the alsa device if there is no incoming data. If there is at least some incoming data, it will try to continue by supplying silent frames to make up for missing ones. In the case you have described, it seems that at least some frames are getting through, making shairport-sync continue to try to stream the very-broken-up audio stream.
Okay to close this?
It's okay! I was a little bit busy... Thanks for clarification!
Thanks.
Hi Mike,
I've an ARM-based wireless audio device running shairport-sync 2.1.11. Mostly, it plays very solid. However, I've investigated a problem which occurs rarely, but is very annoying. I stream the music from my iPhone to the wireless audio device. This runs for a while and suddenly playback stops. I've restarted the device and the iPhone can see the audio device, but after selecting it as playback device it disappears.
I've logged the output from
shairport-sync -vvv -t 0
. It's a lot of output and I've cut after the kernel dump. Thebrcmfmac
is the wifi driver:brcmfmac
is the wifi driver,cfg80211
is the wifi API driver. The messages:are caused by avahi.
Any idea what's going on here?