[pulseaudio-discuss] PulseAudio native protocol

[Colin Guthrie]

Hi,

[As a very friendly aside, can you configure your mail client to post
plain text only emails to this list as it makes everyone's life easier
to read standard styles and formats (which is important when reading
100's of emails across numerous mailing lists every day :D]

'Twas brillig, and Emil Ohlsson at 01/07/11 09:39 did gyre and gimble:
>>> Is there some kind of documentation on how the native protocol works?
>>> Or some guide on the structure of the source code. I?ve taken a look
>>> at pulscore/protocol-native.[ch] to try to understand the protocol but
>>> it?s a pretty much information to take in all at once, so any comments
>>> would be very welcome.
> 
> 
>> Well, the native protocol is a little nasty in this regard. I'm not sure
>> I would recommend anyone try and implement it >outside of the PA client
>> library itself.
> 
> 
>> Can you describe some other things about your amp to us so we can maybe
>> see if there are other, easier and more >future proof ways to support it
>> before deciding if supporting the native protocol is the best option?
> 
> 
> The amp is part of my master thesis, I’m doing a study a of Audio over
> Ethernet using embedded systems. The amp is supposed to act as a network
> connected sound card. The best thing would be if the amp would be
> indistinguishable from other sound cards on the computer. That is why I
> was looking at PulseAudio in the first place, could the device support
> native protocol then it would blend in well with most major Linux
> distributions.
> 
> The SNAP will also be able to take an RTP stream and convert it to
> sound. So perhaps it is better to try to tell the amp when to start
> listen for an RTP stream instead, perhaps this could be done using DNS-SD?
> 
>> 1) Does your amp run Linux?
> 
>  
> 
> No, it will be a tiny embedded system. But it is supposed to support
> mDNS/DNS-SD, so it can be detected using avahi.


OK, cool. I by the sounds of it RTP will probably be the way to go.

PulseAudio supports numerous different types of "Sinks" which are
implemented by modules. We already have sink modules for ALSA, OSS, RTP,
RAOP (AirTunes) and PA Native Network Tunnels (and a few others too).

In the Apple AirTunes world, we have module-roap-sink which creates the
actual sink object and module-raop-discover (which listens for the
DNS-SD stuff and loads module-roap-sink when needed).

In your case, if your amp supported PA Native protocol, we would have to
use the PA Native network tunnel sink (module-tunnel-sink). We would
load this module automatically if your device advertised itself via
DNS-SD/avahi (module-zeroconf-discover does the listening and module
loading).

But What I think is more sensible is to use RTP.

In the RTP case we do not have a module-rtp-discover which does the
listening+loading stuff, but it would be really trivial to write and
should take only an hour or so to code if you've not done any PA coding
before (as it'll be very, very similar to module-zeroconf-discover or
module-roap-discover!).


So if you can make your amp work to receive RTP and if you can manually
load module-rtp-send (which piggy backs on to an existing sink's monitor
source) and output sound to your amp, then you can fairly easily go the
extra step and make it all work with auto-discovery with minimal effort.
I'll happily guide you through this process!




As a general question to the other devs here:

module-rtp-send is a little different to the other network modules in
that it listens to another sinks monitor. From memory this allows it to
use the clock of another sink. But should we actually think about
creating a module-rtp-sink module which wraps this up a little and
creates it's own sink?

We could even deprecate module-rtp-send as using module-loopback we
could achieve the same "piggy back on existing sink" setup should people
still need it (but in a much more generic way).

What do people think (especially Maarten who I know has tweaked RTP
stuff recently)?

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