Re: [LAD] [LAU] FOSS Ethernet Soundcard

From: Folderol <folderol@email-addr-hidden>
Date: Thu Nov 26 2009 - 03:24:55 EET

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.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Thu Nov 26 04:15:04 2009

This archive was generated by hypermail 2.1.8 : Thu Nov 26 2009 - 04:15:04 EET