On Mon, Sep 1, 2014 at 8:20 AM, Len Ovens <len@email-addr-hidden> wrote:
> 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
>
> Wow Len what a brainstorm!
I like your Idea! That would be the ideal modular platform.
But if we're going the ethernet route why not Ravenna? It's open standard I
think.
Wouldn't there be a possibility to implement DSP or even Jack in Ravenna?
Consoles from Lawo are Linux based and use Ravenna.
Just some quick thoughts.
_______________________________________________
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:02 2014
This archive was generated by hypermail 2.1.8 : Mon Sep 01 2014 - 16:15:03 EEST