J
josephkk
The problem inherently defies a simple partitioning.
E.g., if you want to drive speakers directly, you
partition the streams differently than if you want
to drive a "typical" home theater system (i.e., all
of the interfaces in a single location to connect
to external kit).
Yes, it becomes a matter of tradeoffs. If you set up to optimize for one
or two cases other cases may become intractable. It is not clear of there
is a sufficiently flexible answer to do most cases reasonably well.
The degenerate case -- one channel, one speaker -- is the
obvious building block. But, doesn't lend itself well to
network deployment (esp wired networks).
The CODEC I've designed really only wants to deal with two
audio "channels", at most. (Yes, I could change that)
Consider, the more "channels" you support in the stream,
the more resources you implicitly require on the ends of
that stream.
Eg., if you pack 5.1 into a single stream, then the
client device has to be able to unpack and DECODE
all of those streams in the same "unit time" that it
could otherwise have been responsible for a *single*
(or, perhaps *pair* of) "channel".
I seem to have been unclear again. The 5.1 (SPDIF) stream goes to a home
theater unit that does the rest from just the digital stream.
I.e., you can't just arbitrarily scale up the "width"
of each stream without consequences on the clients
(and the goal is to make the clients *really* simple
and inexpensive)
(sigh) Yes. The problem is trying to be "considerate"
(accommodating?) of future users' needs. I could, instead,
just focus on *my* needs and offer *my* implementations as
"reference designs" and let other folks "roll their own".
IME, this is too high a bar for many people to reach.
It seems far easier for people to repeat someone else's
success and make *minor* changes than to try to "grok"
the underlying truths and extrapolate those to another
implementation. Esp when there are lots of subtleties
in the design that they may not be qualified to understand
or accommodate (in another implementation).
<frown>
Perhaps if you place the design in creative commons or such, you may wish
to place a trio of designs and discuss the tradeoffs for selecting one
basis or another for the other users who wish to adapt it. A lot more
work that way though.
?-)