What I had in mind for ethernet transport is this:
Raw EN packets are very simple:
dest-MAC,send-MAC,type,data
There is more, but that is part of the HW driver and the linux raw EN
interface just requires those sets of data. If I could be sure the HW
would support promiscuous mode, I would tend to use a MAC of 1 and 2, but
I think some hw will not allow that (is this true?). However, EN like IP
has broadcast addresses that can be used to discover the MAC at both ends.
Each MAC is 6 bytes (octets in netspeak), The type is two bytes and is
either the data size if 1500 or less or a type if more. Having size is
kind of nice, but probably not needed as the hw level keeps track anyway.
Anyway, in the end we are left with a data packet from 46 to 1500 bytes.
At 100mbit we will not be using 1500 :) 1000 is about it for 4 samples of
48k audio ... 8 samples at 96k and 16 samples at 192k ... So the minimum
latency does not change with sample rate in this case. As happens the
minimum packet of 46 bytes is enough for 46/4/4=2.975 Channels. This gives
us some extra space to send MIDI bytes (9 in fact) if we keep the MIDI
info in the place where the audio data would be. These channels would be
marked as valid but non-audio. This assumes a MADI like encoding where
each sample is stored in sequence as if it was aes 3. That is 32 bits per
sample.
Unlike MADI, empty channels would not be filled with null data, but rather
just not sent. In MADI, 64 channels are always sent even for a payload of
1. In this case we should send multiples of two. There is no reason that
the channel count should not change from frame to frame, but of course the
receiving sw would have to have time (non-real time) to reset itself and
audio sw that doesn't know how to deal with more channels all the sudden
might need restarting too :) In Jack's case, if the first two were set up
as the sound card, the rest could be added as jack clients. On the AI end
they would all be jack clients anyway and jack would see the whole
complement of codecs all the time. I feel it is worth while having jack in
the AI because this would allow routing. There would be no having the
outputs be channels 9 and 10 because that happens to be how s/pdif appears
because those could look to the host like 1 and 2.
I don't know if there is any (psuedo)standard for midi commands for
routing. I also do not know if 128 channels is enough. That is probably
not a problem though as there are 16 channels, so 16 x 128 is lots.
Something like noteoff value where note is the input and value is the
output... hmm, would that be a toggle or two commands, one to connect and
one to release.
MIDI channels: obviously I have set aside one midi channel for device
control. No matter what standard I set up, it is open and changable. Midi
channels can be set up at the user's whim basically. If there are any
physical Midi ports on the AI, they would be available. But if there is a
software synth of some sort on the AI, there could be another line for
that. This is where Jack starts to look really nice as the host end of
things, but ALSA would lend universalness to things. The nice thing about
this project is that problems can be fixed from both ends, The host driver
and the AI driver.
Still a very rough sketch, I know. It probably needs to be written up with
things defined properly etc. However, making sure things work first would
be a good idea.
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-dev mailing list
[email protected]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
