[pulseaudio-discuss] PulseAudio native protocol

[Maarten Bosmans]

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
>