iOS9 stuttering

[XDjackieXD]

I use shairport-sync with the Pi Musicbox and I get weird stuttering with a friend's iPhone 5 running iOS9

Shairport output:

new RTSP connection.
Play connection from "AirPlay/241.33".
Connection from IPv6: fd86:2e8d:82a5:0:10ae:9814:565:595:50211
volume: 38%   repeat: off   random: off   single: off   consume: off
Control Port -- Unknown RTP packet of type 0xD6 length 956.
Control Port -- Unknown RTP packet of type 0xD6 length 1016.
Control Port -- Unknown RTP packet of type 0xD6 length 1032.
Control Port -- Unknown RTP packet of type 0xD6 length 856.
Control Port -- Unknown RTP packet of type 0xD6 length 812.
Control Port -- Unknown RTP packet of type 0xD6 length 1156.
Control Port -- Unknown RTP packet of type 0xD6 length 956.
Control Port -- Unknown RTP packet of type 0xD6 length 1016.
Control Port -- Unknown RTP packet of type 0xD6 length 1032.
Control Port -- Unknown RTP packet of type 0xD6 length 956.
Control Port -- Unknown RTP packet of type 0xD6 length 856.
Control Port -- Unknown RTP packet of type 0xD6 length 812.
Control Port -- Unknown RTP packet of type 0xD6 length 1016.
Control Port -- Unknown RTP packet of type 0xD6 length 1032.
Control Port -- Unknown RTP packet of type 0xD6 length 956.
Control Port -- Unknown RTP packet of type 0xD6 length 1156.
Control Port -- Unknown RTP packet of type 0xD6 length 956.
Control Port -- Unknown RTP packet of type 0xD6 length 1016.
Control Port -- Unknown RTP packet of type 0xD6 length 1032.
Control Port -- Unknown RTP packet of type 0xD6 length 1016.
Control Port -- Unknown RTP packet of type 0xD6 length 1032.
Control Port -- Unknown RTP packet of type 0xD6 length 856.
Control Port -- Unknown RTP packet of type 0xD6 length 812.
Control Port -- Unknown RTP packet of type 0xD6 length 1156.
Control Port -- Unknown RTP packet of type 0xD6 length 856.
Control Port -- Unknown RTP packet of type 0xD6 length 812.
Control Port -- Unknown RTP packet of type 0xD6 length 856.
Control Port -- Unknown RTP packet of type 0xD6 length 812.
Control Port -- Unknown RTP packet of type 0xD6 length 1156.
Control Port -- Unknown RTP packet of type 0xD6 length 1156.
Control Port -- Unknown RTP packet of type 0xD6 length 1044.
Control Port -- Unknown RTP packet of type 0xD6 length 1044.
Control Port -- Unknown RTP packet of type 0xD6 length 1044.
Control Port -- Unknown RTP packet of type 0xD6 length 1044.
Control Port -- Unknown RTP packet of type 0xD6 length 1044.
RTSP shutdown requested.
closing RTSP connection.
Audio receiver -- Server RTP thread interrupted. terminating.
Control RTP thread interrupted. terminating.
Timing RTP thread interrupted. terminating.
rtp_timing_sender thread interrupted. terminating.
Closed and terminated timer requester thread.
Timing RTP thread terminated.

If I can provide you with any additional info just ask :3

[mikebrady]

Can you tell what version of Shairport Sync (do shairport-sync -V)?

[XDjackieXD]

Sorry that I forgot to add it... Version is "2.1.15-openssl-Avahi-ALSA" (latest version that comes with Pi Musicbox)

[mikebrady]

Hi there. Thanks for the report. How hard would it be to update it to the latest – 2.4? Trying to think back, I think this was a problem we fixed. What is your friend using to originate the stream – is it Whaale, by any chance?

[XDjackieXD]

My friend tried an iPhone5 with iOS9 and the standard music player. I can try to upgrade to 2.4. Are there prebuilt binaries for the Pi (with openssl, Avahi and ALSA) or do I have to build it myself? Also I can only test it tomorrow as I'm already at home and we have the musicbox in our classroom for music during the breaks ^,^ (I have a second Pi at home but I don't have an iOS device with iOS9. only an old iPod touch 4 with iOS 5 and it is working perfectly fine with shairport-sync...)

[mikebrady]

Thanks for the information. AFAIK, there are no prebuilt binaries for Shairport-Sync. The "General" instructions in the README.md are good for Raspbian though... It's good to hear that it works well with iOS 5. I'll try to dig up the history to see where that problem seemed to surface, but it'll be after work today before I can get to it...

[XDjackieXD]

I will set up a musicbox with my second Pi then to build it :) Another thing that might be related: I had the same stuttering a few musicbox versions back but only with the soundcard I use with the Pi. any other soundcard worked fine (but everthing else except shairport-sync worked too) but this doesn't seem to be the problem now as AllConnect (previously called strembels) on Android works fine.

[mikebrady]

Okay, thanks. I appreciate the effort you're putting in to resolve this!

[XDjackieXD]

I have to thank you for maintaining such a great project such actively! :D (musicbox image is currently writing to the (painfully slow) sd card ^^)

[mikebrady]

I found where this issue was addressed. The problem is that when asked to resend a missing audio packet, the iOS app "Whaale" was sending it via the control connection as opposed to the audio connection. It was showing up as a 0xD6 packet. It seems that the Music app in iOS 9 is now doing the same thing. Shairport Sync became compatible with this behaviour in a development version – Version 2.3.5 – on June 21, and it's part of the stable version, Version 2.4, now. Might be worth mentioning to the Pi Musicbox crowd...

[XDjackieXD]

OK I will try 2.4 tomorrow and report back.

[XDjackieXD]

Version 2.4 doesn't have any errors in verbose mode and not as much stuttering but still some stutter left (iPhone5 iOS9, default Music APP, connected through 2.4GHz 802.11n). Idk if this is a problem with my setup though (a number of factors could cause this...)

[mikebrady]

Thank for the update. I think your analysis is fair: The reason for those messages in the first place was that Shairport Sync was asking for packets to be retransmitted because they were being lost. (Then, it was not processing them properly, but version 2.4 fixes that.) it is possible that the conditions that caused the need for retransmission are still there, and what's changed is that the retransmitted packets are being used properly.

[XDjackieXD]

Do you have any idea what could cause the retransmissions? data throughput from Pi to iPhone is pretty high (~30MBit/s measured without lost packages). the setup consists of a TL-WR840N running openwrt Barrier Breaker, the Pi connected via LAN and the iPhone connected via wifi (and our school's LAN connected to the WAN port for internet uplink). I haven't checked the system load of the Pi but it usually was at 1-2% CPU and 20% RAM usage when idle so this shouldn't really be a problem...

[mikebrady]

Offhand I can't think of any particular cause – there are so many to choose from :). Is the problem continuous or is it bursty? Do you have any other devices that could interfere, like microwaves or stuff like that? It could take a while to narrow it down...

[XDjackieXD]

it is continuous (at least during the 3min we tried it). There is a microwave in the same cabinet but it was turned off. I can run wireshark on Monday and see if I can find anything useful...

[mikebrady]

Yeah. Just remember that the transport is UDP.

[XDjackieXD]

I swapped the USB soundcard for an other one and suddenly everything is working correctly... The strange thing is that everything except shairport-sync was working correctly...

[mikebrady]

That is weird, but of course interesting. Can you tell me what the sound cards are – the previous one and current one?

[XDjackieXD]

Previous one is a Terratec Aureon 5.1USB, Current one is a Creative Soundblaster Live! 24Bit External. I have no idea why this would be happening...

[mikebrady]

Me neither. I just notice that the Terratec seems to be USB 1.1, so I wonder if it's just too slow. Could it be tying up the processor while it should be receiving UDP packets? http://alsa.opensrc.org/Terratec_Aureon_5.1_USB_MK.2

This might help to tell if it's really USB 1.1: http://serverfault.com/questions/96663/how-to-determine-usb-version-1-1-or-2-0

[XDjackieXD]

ok. the soundcard is usb 1.1. that might be the problem. There are reports that usb1.1 audio interfaces can cause issues with usb2.0 ports of the Pi. They can be forced to USB1.1 though but this would also have a huge impact on network performance...

[mikebrady]

Thanks for the detective work!

I can think of two possibilities: one is that the slow USB transfers cause the WiFi subsystem, or the Ethernet subsystem, to back up, dropping packets. This does seem be be an issue with the Pi.

The other possibility is this: Shairport Sync is very conservative in the way it uses the ALSA system. In particular it uses polling to transfer audio to the ALSA subsystem. I am guessing that, when the output device is USB 1.1, it causes the polling to take much longer than with USB 2.0, causing the processor to miss incoming UPD packets. I guess it could be the combination of both. Anyway, it's good to have some idea of the possible cause.

[XDjackieXD]

I'm pretty sure it's the USB1.1 that causes the problems... (In my case it would be the Ethernet subsystem as wifi is handled by a TP-Link WR-840N running OpenWRT.) Could the soundcard cause the USB hub to fall back to USB1.1 on all ports thus causing bandwidth issues with audio + networking at the same time?

[mikebrady]

I'd be only guessing, to be honest, about falling back to USB 1.1. Maybe some Raspberry Pi expert would have a view.

[XDjackieXD]

Yes. I think the issue is closed though because it's not your code causing the issue ^,^ Thank you very much for helping!