'Twas brillig, and Bryan Gleeson at 09/06/11 18:33 did gyre and gimble: > Colin, > >> Awesome, thanks for your analysis. I'm sure this will help smooth >> things out. As it's your work, would you be able to create a >> git-formatted patch such that you get the proper credit? > > Sure - I'll need to familiarize myself with the details but it should > be no problem. > > On the sending buffer size issue it seems common practice, and also > the easiest approach, is not to set any sndbuf size in the socket > application itself. The OS default size (the tcp_wmem sysctl > parameter) will be picked up as a result; also the OS may > automatically adapt this under load conditions and specifying a fixed > value disables this automatic tuning. So providing the default OS > value is large enough, which in general I think to be the case, > simply removing the call to set the buffer size should be adequate, > but I'll look into this a bit more. > > On the receive buffer size (via SDP fmtp param) I'll also do a bit > more testing to see what the behaviour is with different values. Sounds good. Thanks very much for looking at this stuff :) I'm always happy to see people improve on the base I created (it certainly has plenty bits that need improving :D) >> One last point - are the specs for raop v1 and raop v2 published >> anywhere or have these protocols been reverse engineered? > >>> We've been trying to reverse engineer it... > > Yes I now understand that this is to Apple just like another version > of their iphone dock connector spec - a separate (from the App SDK) > licensing arrangement with a number of CE hardware vendors to allow > development of compatible speakers, hi-fi components, etc. Already > Pioneer, Denon, JBL etc have AirPlay compatible devices. As such it > is very unlikely that where will ever be an open publicly available > spec since Apple will want to keep tight control on how AirPlay is > used in any commercial products, particularly on the video streaming > side. Actually I think the video stuff is somewhat simpler... I think the sender side just sets up a http-esque URL and hands it over to the player side and tells it "play from here <timestamp>" and that's it. Whereas the audio side is still very much a push system. Not sure on the logic of that, but I guess it's just a time + long term playback (e.g. > 1 item) thing. But that said, I've not looked too much at the "AirPlay" stuff (I appreciate the term AirPlay encompasses the AirTunes stuff which used to be separate). Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]