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"
