[pulseaudio-discuss] Suggested improvements for the raop module

[Colin Guthrie]

'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/]