[pulseaudio-discuss] Making Pulseaudio the perfect digital-everywhere sound transport

[Erich Boleyn]

Greetings all,

[I'm not a member of this list right now, so please copy me on
 all replies!]

This is kind of long so hope everyone can bear with me, and hope it isn't
all FAQ material that I just didn't RTFM closely enough.  ;-)

I'm trying to use Pulseaudio as a network digital audio transmission
mechanism for my home.  I had previously done research into the mechanisms
on this kind of topic out of curiousity, but when getting more serious
about it recently found the nice work done in Pulseaudio already and
figured it's better to use/contribute to something out there rather than
try to re-invent the wheel.

My long-term interests include having a software KVM-like solution using
Pulseaudio-compatible transport for the audio.

Where I am today:

   I have Pulseaudio 0.9.7 set up and running on a network with multicast
   support (9 computers, 5 of them with speakers or amplifiers hooked up),
   and use the RTP transmission scheme to get it throughout my home using
   the default channel configuration today.

   It works pretty well so far with some scripts to inject/remove modules
   and reconfigure the audio streaming on demand from remotes for the whole
   home.

   My setup isn't 100% there yet, with clean support for all local clients
   playing back while network audio is working still not figured out yet,
   and waffling between the default channel config vs. 6-channel audio
   for now.

There are some limitations to what I seem to be able to achieve with
Pulseaudio as it exists today, and I wanted to understand if they are
just due to my igorance, currently missing implementation, or inherent
in the Architecture of Pulseaudio and if so what willingness there would
be to add support for it (I would perhaps volunteer, if it isn't one of
those cases of me just not understanding it's not doable for some
reason ;-)


So, limitations to what I see as the ideal case:

  --  Issue:  Multichannel and/or high-rate/depth audio vs. simple audio
      overhead.

      Example:  My home theatre/music setup in my front room can do up to
      7.1 channel 192khz/24-bit audio.  That's about 4.5MB/sec, which
      while not saturating my multicast-aware gigabit network, gets to
      be something of a processing burden if not necessary.  Most of the
      sound sources are standard 2-channel 44.1KHz

    --  Potential solution:  Dynamic source/sink or transport typing support

        I could not find any mention of dynamic source/sink or transport
        typing support in Pulseaudio.  Maybe I just missed it.

        By this I mean being able to support multiple formats in a single
        source/sink and have the connections dynamically support when the
        format changes.

        Another way of looking at it is that there are "hard" sources and
        sinks in Pulseaudio, corresponding to real hardware, and "soft"
        sources and sinks, which correspond to logical routing or
        interconnects (such as the RTP send module).  The "soft" sources
        could in principle support multiple formats based on the input
        audio rather than always converting to some fixed format.

  --  Issue:  Digital compressed stream transport.

      Example:  Dolby 5.1, DTS, etc.

    --  Potential solution:  Sent it compressed unless it needs mixing, then
        blow out to uncompressed.  Recompress at digital output.

        I saw a passing comment in the last month's email archives that
        the compressed audio did not have defined latency characteristics
        so would probably not work well.  I don't understand the Dolby/DTS
        formats well at all, so it could be I'm just confused on this front
        in thinking it's easy.

        Being able to recompress also brings up where to get the
        recompression code from (and which sub-format of the myriad
        Dolby 5.1/DTS extensions to support).  That's probably a whole
        discussion in and of itself.  I saw one comment saying there
        was support in one of the open-source libs for it, but none
        about what the overhead or latency issues involved would be.


Thanks for everyone's time.

--
    Erich Stefan Boleyn     <erich at uruk.org>     http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"