2014-08-04, 07:06
I've been investigating a sporadic issue I noticed while using the airplay component in xbmc 13.1. One out of every three or four attempts to stream from an airplay client silently fails (I repro'd this on a multi-core x86_64 linux box). I tracked this down to a race condition between the thread running DVDDemuxBXA and the thread receiving callbacks from libshairplay.
In short, DVDDemuxBXA::Open needs to see a valid header at the start of the shairplay pipe but occasionally, shairplay triggers an audio_flush callback before the DVDDemuxBXA thread has a chance to read the header. The audio_flush callback nukes the contents of the pipe buffer so the Open call reads garbage rather than a proper header and the call fails. Since the shairport thread is still running, the client seems to think the stream is healthy even thought xbmc never successfully opened it.
The problem goes away if CAirTunesServer::AudioOutputFunctions::audio_flush is replaced with a no-op. This is admittedly a hack (although I personally didn't notice any side effects)
Do any of you know this code well and could provide some input on this?
thanks,
-Kevin
In short, DVDDemuxBXA::Open needs to see a valid header at the start of the shairplay pipe but occasionally, shairplay triggers an audio_flush callback before the DVDDemuxBXA thread has a chance to read the header. The audio_flush callback nukes the contents of the pipe buffer so the Open call reads garbage rather than a proper header and the call fails. Since the shairport thread is still running, the client seems to think the stream is healthy even thought xbmc never successfully opened it.
The problem goes away if CAirTunesServer::AudioOutputFunctions::audio_flush is replaced with a no-op. This is admittedly a hack (although I personally didn't notice any side effects)
Do any of you know this code well and could provide some input on this?
thanks,
-Kevin