[pulseaudio-discuss] PulseAudio native protocol

[Emil Ohlsson]

Hi!

I'm currently developing a amplifier with Ethernet interface and I would like to be able to use this amplifier as a shared sound card using PulseAudio.

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.

Thanks
Emil Ohlsson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110630/5244b7a0/attachment.htm>

[Colin Guthrie]

Hi!

I?m currently developing a amplifier with Ethernet interface and I would
like to be able to use this amplifier as a shared sound card using
PulseAudio.

Awesome!!!!!

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?

1) Does your amp run Linux?

the rest of the questions kinda assume "yes" to the above, but not fully...

2) Would there be a way to use ALSA output from an app running on the amp?
3) Could you run PA itself on your amp?
4) Could your amp accept RTP streams?
5) Could your amp run avahi.


That's probably enough to start with :)

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

[Emil Ohlsson]

Hi!

Post by Colin Guthrie

I?m currently developing a amplifier with Ethernet interface and I
would like to be able to use this amplifier as a shared sound card
using PulseAudio.

Awesome!!!!!

Thanks :)

Post by Colin Guthrie

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?

Post by Colin Guthrie
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.

Post by Colin Guthrie
the rest of the questions kinda assume "yes" to the above, but not fully...
2) Would there be a way to use ALSA output from an app running on the amp?
3) Could you run PA itself on your amp?
4) Could your amp accept RTP streams?
5) Could your amp run avahi.
That's probably enough to start with :)
Col

Thanks a lot :)



/Emil

Post by Colin Guthrie
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110701/26e0db18/attachment.html>

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

Post by Colin Guthrie

Post by Emil Ohlsson
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?

Post by Colin Guthrie
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/]

[Maarten Bosmans]

Post by Colin Guthrie

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)

Post by Colin Guthrie
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!

Post by Colin Guthrie
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.

Post by Colin Guthrie
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

Post by Colin Guthrie
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
?Tribalogic Limited [http://www.tribalogic.net/]
?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

[Emil Ohlsson]

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

Post by Colin Guthrie

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)

Post by Colin Guthrie
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!

Post by Colin Guthrie
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.

Post by Colin Guthrie
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

Post by Colin Guthrie
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
?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

[Bart Cerneels]

Post by Emil Ohlsson
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).

Post by Emil Ohlsson
-----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

Post by Colin Guthrie

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)

Post by Colin Guthrie
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!

Post by Colin Guthrie
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.

Post by Colin Guthrie
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

Post by Colin Guthrie
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
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

[Emil Ohlsson]

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

Post by Emil Ohlsson
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).

Post by Emil Ohlsson
-----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

Post by Colin Guthrie

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)

Post by Colin Guthrie
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!

Post by Colin Guthrie
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.

Post by Colin Guthrie
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

Post by Colin Guthrie
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
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

[Colin Guthrie]

Post by Emil Ohlsson
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?

I would stick to some kind of RTP variant for your "native" protocol.
Library re-use being a potential win and relatively easy support in
other systems (like PA) should also be made possible by this approach.

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