Re: [LAD] [LAU] FOSS Ethernet Soundcard

It's late, but I can't sleep, so... Refining my protocol thoughts, which I originally posted on LAU. There is one master, which would probably be the computer, but I can envisage a situation where there could be more than one computer and only one of them would be the master, the other would be a slave like everything else. When each slave starts it sends a simple 'hello' message, say once every 50mS until it gets a query back. This way it doesn't matter which order the master and slaves are started. At this stage it only listens for a default channel which would only be sent by the master. When the master gets a 'hello' it sends a message requesting the following: textual name of the device bit depths the slave can handle sample rates number of input channels number of output channels It then assigns virtual channel IDs that the slave is to use from now on based on what else is connected etc. Once it has this information it can tell the slave to do any of the following: perform general initialisation and set all defaults (panic!) change textual name to '?????' set bit depth -> 8, 16, 24, ? (default 16) set sample rate -> 44.1, 48, 96, ? (default 48) set unit as clock reference or not (default not) enable/disable CH 'n' listen to broadcast CH 'x' (default master) enable/disable CH'n' input (default disable) enable/disable CH'n' output (default disable) set CH'n' gain/output (default silence) Audio data transmission is initiated by the master polling for each active virtual input channel to send its data (obviously ignoring output ones). Also bearing in mind that the master will itself be generating and sending out processed audio data on multiple channels. Changing name (which should ideally be stored permanently) enables you to define a unit as say, 'front 4 mics' or 'control room monitors'. In future the master could automatically link this name to previously defined channel IDs. Enabling the listening channels should work in parallel, in that a unit will always listen to the master channel, but could also listen to any number of other channels and route them accordingly. This gives a very flexible multicast in that you can have all streams currently being transmitted routed selectively directly to monitors, headphones etc. Disabling a channel is not the same as setting it's level to silence, as at silence it would still generate output to be fed into the network. It would make sense to stop any meaningless data transfers. With a switched binary volume control 7 bits would give you 127dB range (LSB=1dB) so the 8th bit could be used to simply ground that channel. I'm not even sure you need to go as tight as 1dB. Fine control would be done within the DAW anyway. If anyone can see any obvious holes in this or simplifications please say so. I'll be listening on all channels :) -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.