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