[pulseaudio-discuss] PulseAudio native protocol

Emil Ohlsson emo at svep.se
Mon Jul 18 02:04:15 PDT 2011 

Depending on the speed of development DLNA and UPnP maybe will be implemented later, but right now the focus is on ZeroConf.

At the moment it is not fully decided how to control the amp to make it play RTP streams, if we find some nice open protocol for this then perhaps we will use that. Meanwhile we'll probably implement some made up protocol for development purpose. Does anyone know of any protocol that would be suitable for this?

/Emil

-----Original Message-----
From: pulseaudio-discuss-bounces+emo=svep.se at lists.freedesktop.org [mailto:pulseaudio-discuss-bounces+emo=svep.se at lists.freedesktop.org] On Behalf Of Bart Cerneels
Sent: den 5 juli 2011 08:59
To: General PulseAudio Discussion
Subject: Re: [pulseaudio-discuss] PulseAudio native protocol

On Friday 01 July 2011 14:46:41 Emil Ohlsson wrote:
> Hi!
> 
> The plan is to have many amps connected via network and synchronized 
> with each other. So it seems like using the SDP/SAP announcement (I 
> was wondering what that was for) to start listening to the RTP 
> multicast would be a pretty easy way to implement on the AMP. Either 
> way the amp need to announce itself via mDNS/DNS-SD because the plan 
> is to make it merge well with other operating systems as well, and 
> it's a nice way to provide a user interface to manage the amps.
> 
> I'll definitely take a closer look on module-zeroconf-discover, it 
> would be very interesting to learn more aboute the inner workings of PulseAudio.
> 
> Thanks for all valuable comments.
> 
> /Emil


Now this is very interesting. I've been planning my own multi-room audio RTP using pulseaudio for a while now. I would be happy to contribute.

I'm partial to using UPnP as the discovery method myself, but I guess it's OK to use DNS-SD since it's so well used in PA already. I do wonder how you will remotely instruct the amp to start playing the RTP multicast stream though. 
For UPnP the standard functions of MediaRenderer can be used for that.

That would basically mean implementing MediaRenderer in your amp or Digital Media Renderer (DMR) as it's called by DLNA. There are a lot of those commercially available (http://www.dlna.org/products/ look for "Play To" 
receiver) however I don't know of any that support *multicast* RTP (unicast RTP only in DLNA 1.5). It's technically perfectly possible, just not in the DLNA requirements (yet).

> 
> 
> -----Original Message-----
> From: pulseaudio-discuss-bounces+emo=svep.se at lists.freedesktop.org
> [mailto:pulseaudio-discuss-bounces+emo=svep.se at lists.freedesktop.org] 
> On Behalf Of Maarten Bosmans Sent: den 1 juli 2011 12:25
> To: General PulseAudio Discussion
> Subject: Re: [pulseaudio-discuss] PulseAudio native protocol
> 
> 2011/7/1 Colin Guthrie <gmane at colin.guthr.ie>:
> > 'Twas brillig, and Emil Ohlsson at 01/07/11 09:39 did gyre and gimble:
> >> 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?
> > 
> > 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.
> 
> Remember that the use case for RTP (at least in pulse's
> implementation) is slightly different than a native-protocol tunnel.
> We only support RTP multicast in module-rtp-send, and from the 
> description of the device Emil gave it sound like a unicast connection 
> would be more appropriate. (unless you're planning to use a lot of 
> these devices in sync over the network) So that leaves you with three 
> options: native protocol (which is a bit harder to implement), using 
> RTP multicast (which causes unnecessary network load), or hack 
> module-rtp-send to be able to send unicast rtp streams. (and probably 
> module-rtp-recv also. We had a bug somewhere that requested that RTP 
> unicast be implemented)
> 
> > 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!
> 
> module-rtp-send already does a multicast announce with an SDP/SAP packet.
> But that is a sender announce of a starting RTP stream for listeners 
> to grab of the network. For this project an announce/discover of 
> ready-to-listen network nodes is required and indeed that is more 
> alike the existing -discover modules. It would be good to research if 
> there any existing protocols for this though.
> 
> Also note that the proposed module-rtp-discover could lead to a *lot* 
> of network traffic. Assume two such networked amp announce their 
> availability and there are five PCs running pulse with 
> module-rtp-discover. They then all load up null-sink and connect 
> module-rtp-send to it (twice). Then regardless of whether there is an 
> application playing music to the null-sink (contrary to 
> module-tunnel-sink, module-rtp-send does not support 
> corking/suspending of audio stream) you have 10 1.4Mbit audio streams 
> running over the network. Even worse, that 14Mbit of traffic is not 
> just between the PCs and the amps, but multicasted over the entire network segment!
> 
> > 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).
> 
> There are two possible scenarios: A, streaming microphone audio over 
> network with multicast RTP, or B, streaming application audio over RTP.
> With each of the solutions one scenario is easy and the other requires 
> an extra bridge. The current situation with modules-rtp-send is 
> modeled on scenario A and for B you need to load a null-sink and hook 
> module-rtp-send up to its monitor. The app then connects to the 
> null-sink. With a new module-rtp-sink B would be default and for A you 
> need module-loopback. I'm not sure we gain anything by turning the status quo around.
> 
> > What do people think (especially Maarten who I know has tweaked RTP 
> > stuff recently)?
> 
> What I did was mostly timing/resampling related to module-rtp-recv.
> Emil, how long are you planning to run continuous audio streams to the 
> amps? If more than about 1 hour or multiple amps feeded by the same 
> music stream are within audible range of eachother you need to take 
> care of syncing the streams to account for drifting clocks. You can 
> see in src/modules/rtp/module-rtp-recv.c how that is done in pulseaudio.
> 
> Maarten
> 
> > 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/]
> > 
> > _______________________________________________
> > pulseaudio-discuss mailing list
> > pulseaudio-discuss at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
> 
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

More information about the pulseaudio-discuss mailing list