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

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user