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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Mon Sep 1 16:15:01 2014
This archive was generated by hypermail 2.1.8 : Mon Sep 01 2014 - 16:15:02 EEST