2014-10-17, 10:26
After using airplay audio for a bit longer I've rediscovered an annoying problem with XBMC's implementation that I had forgotten about - it seems to be VERY sensitive to packet loss.
My AP is down in the living room and the Mac Mini running XBMC and iPad are upstairs in the bedroom - almost without fail if airplay audio is sending from the iPad as soon as I pick it up and grasp it in landscape with two hands the audio will stutter/break up quite badly for a second or two then recover, although sometimes it will continue to sporadically stutter while held.
Obviously it's a less than ideal wireless signal and it's easy to blame that except for these two points:
1) I had the same issue in another house in the same room as the AP, although it was less severe.
2) I have one of the old b/g (power plug) model Airport Express's which was my stalwart for years for airplay audio and it NEVER stutters under any conditions. The audio is always rock solid and glitch free as long as there is any wireless signal at all.
As a test I plugged it in beside the Mac mini - both it and the Mac Mini are connected by Wifi to the downstairs AP wirelessly. Streaming audio from the iPad in the exact same conditions holding the iPad in the exact same location is completely glitch free. I can pick it up, put it down, move it around any way I like without any dropouts, where the same movements cause severe dropouts in XBMC.
I was looking at the bonjour announcements and suddenly realised what the difference probably is - the Airport Express annouces tp=TCP,UDP while XBMC only announces tp=UDP.
I confirmed with wireshark that the stream to xbmc is indeed UDP, I don't have any easy way to monitor the stream to the airport express (at least not with the current network layout in the house) but I can only assume that it's using a TCP stream hence it's not sensitive to small amounts of sporadic packet loss like the UDP stream is.
I tried changing the announcement to advertise TCP support as well but it still used UDP, so I assume there is no "plumbing" in place to actually support a TCP connection in the airtunes code...
Is it much work to enable or add support for TCP streams ? Is there any particular reason why it is not already supported ?
I can understand that latency might be a reason UDP is preferred, however there is still about 2 seconds of latency anyway which is about the same latency as an airport express. For me, the reason I use airplay audio is to play music, and for that purpose glitch free (ideally bit perfect) playback is what I want - I don't care if there is slightly more latency if it means I don't get random dropouts in the audio just because I'm moving my iPad around slightly...
My AP is down in the living room and the Mac Mini running XBMC and iPad are upstairs in the bedroom - almost without fail if airplay audio is sending from the iPad as soon as I pick it up and grasp it in landscape with two hands the audio will stutter/break up quite badly for a second or two then recover, although sometimes it will continue to sporadically stutter while held.
Obviously it's a less than ideal wireless signal and it's easy to blame that except for these two points:
1) I had the same issue in another house in the same room as the AP, although it was less severe.
2) I have one of the old b/g (power plug) model Airport Express's which was my stalwart for years for airplay audio and it NEVER stutters under any conditions. The audio is always rock solid and glitch free as long as there is any wireless signal at all.
As a test I plugged it in beside the Mac mini - both it and the Mac Mini are connected by Wifi to the downstairs AP wirelessly. Streaming audio from the iPad in the exact same conditions holding the iPad in the exact same location is completely glitch free. I can pick it up, put it down, move it around any way I like without any dropouts, where the same movements cause severe dropouts in XBMC.
I was looking at the bonjour announcements and suddenly realised what the difference probably is - the Airport Express annouces tp=TCP,UDP while XBMC only announces tp=UDP.
I confirmed with wireshark that the stream to xbmc is indeed UDP, I don't have any easy way to monitor the stream to the airport express (at least not with the current network layout in the house) but I can only assume that it's using a TCP stream hence it's not sensitive to small amounts of sporadic packet loss like the UDP stream is.
I tried changing the announcement to advertise TCP support as well but it still used UDP, so I assume there is no "plumbing" in place to actually support a TCP connection in the airtunes code...
Is it much work to enable or add support for TCP streams ? Is there any particular reason why it is not already supported ?
I can understand that latency might be a reason UDP is preferred, however there is still about 2 seconds of latency anyway which is about the same latency as an airport express. For me, the reason I use airplay audio is to play music, and for that purpose glitch free (ideally bit perfect) playback is what I want - I don't care if there is slightly more latency if it means I don't get random dropouts in the audio just because I'm moving my iPad around slightly...
