[LAU] Open Source Audio Interface (was Successor/replacement for RME HDSP+Multiface?)

[Len Ovens]

On Sun, 31 Aug 2014, Jonathan E Brickman wrote:

>        Just some quick thoughts, perhaps not as complete as they could
>       be. -- Len Ovens
> 
> Doing pretty good I'd say, Len, I have been periodically studying this for
> quite a while.  And now that Firewire is going passé I have to do it again
> :-) 
> 
> There is one hardware approach which I have not seen at all yet: this is
> combination of (say) eight simple stereo USB interfaces, into one box. 
> Shouldn't it be fairly doable, to take eight satisfactory-quality USB
> interfaces, wire their timing chips together, write a custom driver, and
> go?  Or don't bother with the timing chips and the driver and use zita tools
> or multiple Jackd processes, and build this with a Raspberry Pi (or one of
> the more powerful act-alikes) as a jackd-over-tcp/ip audio appliance?

Sounds expensive. The RP is just good enough to deal with one USB device 
it seems. So take one of the 6inch atom based boards... the price is still 
high. Remember, there is an 18 i/o USB2 device already available that 
works quite well for ~$500 all synced already. True, 10 of those ports are 
digital so would require another $180(adat - ADA8000) plus $30 for the 
spdif box (line in only so more for the last two mic pre)

Any USB IF with mic pres I have seen are ~$100 and would require dedicated 
USB ports... this means you might be able to plug two into the MB ports 
and the rest would require adding more USB ports to the MB (PCIe).

> There is the fact, though, that USB2 and before, are monodirectional -- half
> duplex.  They transmit data only one direction at a time.  Yes, they flip
> back and forth very very fast, but no matter what, that's not good for us. 

That would explain the 6+ms latency (that might be round trip) which is 
really not too bad. I think I would be tempted to use the MB audio as one 
input pair and three or four output pairs, but with 18 i/o, why bother.

> But USB3, happily, now gives us a full duplex capability.  Perhaps this will
> mean that once small-studio-priced USB3 multitrack interfaces come out, they
> may be simpler, and therefore potentially less expensive?

Probably not much cheaper. The mic pre is the expensive part. The thing 
is, If I had an audio interface based on an old 10Meg ethernet (not many 
channels), it would still work on a gigabyte ethernet system... Even 
through a switch. So far USB3 still supports USB1, but the physical plug 
is changing, by the time we hit USB5, USB1 and 2 may no longer work. 
Sending cat5 (or whatever) up 20 floors and prewiring a building is 
something no one wants to have to change. There is a lot of servers around 
that use ethernet and good reason to keep the plug the same. But a new 
computer most often comes with new mouse, keyboard and printer (new 
printers are network). Most USB devices are low cost... Audio devices are 
an exception to this but the market share for USB audio is really pretty 
tiny. USB3 seems to be for hard drives and other fast data storage.

I would tend to look at what the profesional people are doing... ethernet 
and PCIe. (broadcast, FOH and major studios). I should perhaps add audio 
over video.. or encoded as part of the video.

The audio interface ends up being a signifcant part of the DAW cost which 
once purchaced we would rather keep through a computer upgrade. Even 
better if we can add more channels to it by adding a second IF or 
inexpensive expansion box.

For an open audio interface with expandability built in, I think I would 
start with the processor board with two ethernet ports. Then I would be 
looking for a standard bus that most codecs/spdif chips support to base 
the modules on. The first one would feature spdif i/o, probably just one 
(two channels). because it is a small computer that would run linux, a 
netjack master would be included.

Why two ethernet ports? Expandability and network passthrough. The idea is 
to write ethernet drivers that will split non-audio packets small enough 
that they do not interfere with the audio and recombine them on the other 
end. It would also allow putting sync on the line because we could delay 
other traffic around the sync on both ends. This also means that the user 
does not have to buy another nic or use wlan if they can't/don't want to. 
On the other hand, if they did have another nic, the second nic on our IF 
could be used for expansion to a second IF if our expansion was already 
used up on the first.

While I would start with a netjack protocol because it would be 
linux/osx/win compatible right off. I might be inclined to come up with 
something lighter in the long run that would show up in ALSA and the 
native OSx/win audio as well. I think this is an area where a well thought 
out standard (open) for the transport and a non-intrusive audio standard 
that is easy to comply with, but still tells the OS everything it needs to 
use generic drivers, would give audio IF manufacturers a path forward with 
no FW. In otherwords, an interface that already works solid with Protools, 
logic, etc. and perhaps just so happens to also work with linux.... and is 
fast enough to work for FOH snake use to boot, might just fly. (if it was 
cheap enough :) )

I'm thinking as I am talking  :) I think for development of the protocol 
for transfer, the best box would be one of the small atom based cards with 
the two nics already installed and just use the audio IF already 
there. I would tend to use something like aes10(madi) to assemble audio 
packets, that is a group of aes3 channels in serial. However, I would 
limit the number of channels based on bandwidth. For example, with a 100m 
ethernet line, I would not try for 64 channels if there was network 
traffic as well. This may mean that the channel count was limited.... But, 
there is no reason a desktop box could not add a second ethernet card for 
expansion. If things are externally synced the alsa driver could take all 
enet audio interfaces and make one alsa device out of it with no multi 
stuff. But before that limit came up, the boxes could be daisy chained 
first. No set up required, unplug the network add in another box and it's 
audio ports are added as part of the first boxes ports. So if two stereo 
boxes are chained the IF looks like a 4i/o IF to the computer. The box 
closer to the computer always has the lower numbered ports. The network 
traffic would stay small packets till the last box in line where they 
would be normal sized on their way out.

Because, these boxen are based on linux, even if the the protocol was not 
jack based, a jack based mixer could be used which was alsa controlable... 
it could also be OSC or MIDI controlable too. This would allow DSP plugins 
to be added... LV2, LADSPA, Linux VST. They could be loaded from the 
computer as some are now, but would be open. (though the user does not 
need to know that)

The interface closest to the network would be able to have network audio 
like netjack or the new zita net connection that would show up as just 
another interface port.

At this point I would add to my jack wish list the ability for jack to 
have names for inputs and outputs from alsa. (look at the names alsamixer 
has - wow someone has fixed my alsa driver so the mic shows as two 
inputs, one inverted instead of right being inverted to left - in my 
netbook) But having the spdif labeled as such in jack would be a help. 
Knowing that input 11&12 are just the monitor mixer would be nice too.

All of the routing in the interface would (like the ice1712) show up in 
alsa, but also (why not) show up as two OSC and/or MIDI ports. This would 
allow all internal functions to be controled by a MIDI control surface. 
The midi control surface could be connected through the DAW or directly to 
the IF (by USB would be best, but if there was a uart on the IF board a 5 
pin din could be there too.

The trick with all this is to make it the internal stuff invisible to the 
user unless they really wanted to see more. The OSx/win/linux user could 
be very happy just using it as an audio IF. The more adverturous user 
might ssh -y in and have a gui menu show up on their DAW gui (or whatever 
the OSx/win equivalent is) where they could control the IF computer more 
closely. The IF could record direct to USB disk for example.

The goal would be a one way measured latency of 1.5ms, though chaining two 
together may make that not possible.

The start as I said, is not hardware really, but software. System side 
software.

Right now it is just a dream (it may never get past that), but it is not 
impossible if done one step at a time. I had thought that which step is 
done first is important, but maybe not so much. There are certain things 
that can be done independantly too. It occures to me there are two alsa 
drivers to write. One for the daw and one for the IF. A jack backend may 
work instead.

--
Len Ovens
www.ovenwerks.net