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

[Lennart Poettering]

On Fri, 08.02.08 12:42, Erich Boleyn (erich at uruk.org) wrote:

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

Hmm, this actually makes some sense. However this is far from trivial
to implement, especially for the tunnel case (RTP is much
easier). Also, you'd need to find a sensible schme scheme to find the
LCM of all sample specs of all connected streams to a sink. 

Patches welcome!

On my todo list is adding transparent compression via Jean-Marc
Valin's CELT compression algorithm. This should allow us to cut down
on the generated traffic while still allowing low latencies.

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

Recompression for patented CODECs doesn't really sound good in my
ears. We cannot really ship that in the distributions. Somewhere down
on my list is adding support for pass-thru streams like
AC3. AC3 streams would be exclusive to each other, i.e. mixing would
be disabled as long as an AC3 stream is flowing. 

But yeah, although it ison my todo list , it's way down on my
list. 

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4