If only it were that easy... Once the player app pushes the audio to the kernel it enters a buffer in the kernel (capable of storing about 0.8 seconds of audio). So what happens is that a Rio that is already joined to a channel receives a packet and pushes it to the audio driver. This causes it to be placed at the back of the buffer, potentially 0.8 seconds away from being played. Another receiver just joined the group and this is the first packet it receives. It pushes it to it's audio device, which has an empty buffer, and therefore it gets played almost immediately.


hmmmm, so this buffer is for the "raw" audio?

a couple of ideas that might work...
1) Starve the buffer (so it always needs a frame from the wire to play)
2) Broadcast the metronome (current frame) again a flat network, everybody should get this at the same time
3) Bypass the buffer (is this possible?)


I doubt there's a reason that your idea of decompressing at the server and then multicasting the decoded audio wouldn't work, however it seems inefficient to be pumping all that audio data onto the network. I'd be concerned that opening up an FTP session on the local network could interrupt the broadcast. And of course if you're not providing any real buffering at the client side other than the kernel buffer, even a small drop in network performance can cause an audio dropout.


I agree, but I am proposing an isolated network for the rios (this is the setup I have now) so dropouts shouldn't be an issue... this is based on how cobranet does it (I think), they don't reccomend mixing data w/audio

* 1.4 = 9.8Mbps and that's just for the data, not counting protocol overhead. That will never happen. Even 6 streams (8.4Mbps) is unlikely, though it may work on an isolated network without much other activity. Remember 10Mbps ethernet will never actually reach 10Mbps due to collisions, protocol overheads, acks, etc. I don't think I've seen a 10Mbps segment do much better than 8.

I don't think I was clear before, I was actually proposing using layer 2 multicast (ethernet multicast) not TCP/IP or UDP/IP multicast. And I'm also proposing doing this on an isolated network so I think 12 channels (6 stereo groups) should work fine, even with a bit of overhead for a raw broadcast/multicast of start/stop messages, and maybe a "catalog stream" which would contain a list of what's playing in each bundle.

So is the rio a 10mb or 100mb device on it's ethernet side?

As for network contention, this should be minimal, at least in the isolated network side... assuming no client want's to play/pause/stop the bundles, then the only TX device is the server (master) everybody else just listens and picked the bundle they want.