[Tfug] Audio client

[Bexley Hall]

Hi Zack,

> > If I chose to implement this using a broadcast technology,
> > then this wouldn't be as problematic.  The data for *every*
> > client would appear on the wire at (roughly) the same time.
> > (i.e., let each client filter out that portion of each
> > packet that it is interested in -- e.g., "Left Front" vs.
> > "center", etc.)
> 
> That's what I'd do - make each packet contain a slice of
> data for each channel.

The problem with this approach is that you end up having
to route all the data to *every* device.  I.e., every port on
your switch has to be active.

It also limits the number of "channels" that you can have, 
practically.  Or, forces you to move some signal processing
into the clients (my goal has been to keep everything server side).

If, instead, you send a stream per channel per device, you can
tailor the contents of that stream for that "destination" (device).

> BTW, I'd try using an existing encapsulation method for the
> data if possible.
> 
> Also, as it's not likely you're going to need to route the
> audio, you could do away with the IP level and run on straight
> ethernet, similar to how  Gibson's MaGIC protocol works:
> http://www.gibson.net/en-us/Divisions/Audio/MaGIC/

For a home, that's correct.  But, if someone wants to play with
this in a grander scheme, removing the IP layer just means *they*
have to add it back in.

I have a couple of stripped down stacks that I have written that
I can probably pare down to a realistic implementation (pull out
some of the things that make them more robust -- since I can
*claim* you have to deploy in a non-hostile environment) and still
support most "regular" stack features.  I don't want the
API to look too weird or people will be intimidated from using
it (as it is, there will be those who will complain that it
isn't a full "desktop" OS -- "Where's the telnet client?").

<shrug>  Of course, if no one *ever* uses it, that's fine too!  :>