[LAD] Open Source Audio Interface

[Len Ovens]

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