Lennart Poettering (lennart at poettering.net) wrote:
...
> > 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!
I imagine it wouldn't be anywhere near trivial. I was inquiring to see
where in the spectrum of: already done, in someone's TODO list, or just
seeing if the pulseaudio core folks find it interesting or repulsive.
I'll contemplate a bit more before truly volunteering myself to do it.
FWIW, I would have imagined that the tunnel case to and from anything
but pulseaudio proper would be treated as a "hard" (I.e. fixed format)
source/sink.
> 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.
Interesting... what is the compression ratio? If it isn't very high,
it would probably be useful primarily for the WAN case (WAN bandwidth
is Precious, LAN bandwidth much less so and usually mild compression
ends up slowing you down more than anything else).
...
> 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.
I understand your point. It sounds like a decent compromise.
>From a functionality perspective I can always have the source players
decode AC3 or DTS in software to 6-channel (throwing away some of the
extra acronyms "-EX", etc. since I think the open-source software
decoders don't support the optional extensions) if I need to perform
any mixing.
--
Erich Stefan Boleyn <erich at uruk.org> http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"
