Bug Airplay init race condition
#1
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
Reply
#2
Mhhh thx for finding this out - will think about it ...
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#3
Does this fix the problem? (might even deadlock - not so familiar with our player):

http://pastebin.com/RxQPwq8a
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#4
As an alternative:

http://pastebin.com/BErpP79E
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#5
First patch causes the UI to freeze up. Second patch works beautifully.

I do wonder, though, if discarding the buffer is the correct behavior for the audio_flush callback... The "unofficial spec" (http://nto.github.io/AirPlay.html#audio-rtsprequests, scroll down to FLUSH) implies that the server is supposed to pause the stream, not discard any data
Reply
#6
Ha - nice catch. I never thought about what else it could mean - i just like a reflex flushed the pipe there. Will ask the upstream dev if he thinks we even need to implement anything in there and change accordingly ...
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#7
https://github.com/xbmc/xbmc/pull/5214
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply

Logout Mark Read Team Forum Stats Members Help
Airplay init race condition0