[pulseaudio-discuss] PulseAudio native protocol

Fri Jul 1 05:46:41 PDT 2011

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

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