On Sun, 31 Aug 2014, Moshe Werner wrote: all the recent talk about less audio interfaces being supported for Linux This is not the first time for this idea. There are one or two people working on it. The idea that seems to be the best is an ethernet connected AI because this seems to be the digital interface that stays around and is best supported. The idea is to use an arm based board with a netjack master and built in audio IF. The only project I know of is to at first provide stereo i/o as a proof of concept.

I imagine a modular approach with options to customize and add different A few comments about ADAT, while the format of the messages is well known, it is not open. Licencing may be a problem. True MADI uses obsolete HW. There are a number of audio over ethernet protocols with various openness or not.

Just a quick note about DIY HW. It is not generally cheaper than buying the same capability made by someone else. There are premade solutions out there, but they are not in the range of a lot of linux musicians.

We could even implement a DSP chip with LV2 effects to lessen the CPU Almost any arm based board would be able to add some DSP capabilities. It may also be possible to use a DSP board instead of an arm board, but the learning curve for programing it may be higher... like having a running up to date linux kernel and jackd running on it for example. Maybe this is just wishful thinking, but it would solve one of the The biggest limit to audio interfaces in basement studio is getting over the fact that a good audio interface is going to cost more than the computer it works with. This is first of all a psycological problem not technical.

Most of us are looking for those ~$500 solutions. That is, we expect to get 4 to 8 i/os with mic pres for $500 or so. That is why ADAT looks good to us. The Audio Science 8 i/o PCIe card is just over $1k but just has line in (my D66 is line level too BTW) so then you need mic pres. Most of us have supplied these with a mixer of some sort. Really, an audio interface is two parts, The adc/dac, and the preamps. It is easy enough to do the line level input, even balanced.

Going one step up, there are a lot of mic preamps around that provide a lot more control than a mixer or 8 input audio IF. Most of them have s/pdif or aes3 out. So maybe an audio interface that provides that makes more sense. However, the reason the generic mic pres work for most people is that they are using a set of dynamic mics with a few condeser mics (probably low end like mine) and the pre doesn't matter as much as it might with a ribbon mic for example. So the problem is less technical than it might seem. (on the technical end, using netjack as an audio interface does use more CPU than the same alsa card used locally) To make such a project worth while it needs to have a wide appeal, this means cheap... I can't think of any other way to put it. The goal ends up being 8 i/os with 8 mic pre for around $500. Having something more stable and lower latency than USB2 might give you another $200 (maybe more) to play with, but writing OSx/win drivers would give a lot more room (netjack does this OOTB).

http://lists.linuxaudio.org/pipermail/linux-audio-user/ 2011-October/081520.html is the start I think... Though it may have surfaced since then too. It seems to me that at some point the same project came back in either LAU or LAD but the topic got changed. Wow thanks Len!

I met with a good group of people at LAC 2012 who are working on AVB support under linux.

On Sun, 31 Aug 2014, Moshe Werner wrote: Here is another thread: http://lists.linuxaudio.org/pipermail/linux-audio-user/2009-November/064520… It moves here: http://lists.linuxaudio.org/pipermail/linux-audio-dev/2009-November/024713.…

On Sun, 31 Aug 2014, Jonathan E Brickman wrote: Just some quick thoughts, perhaps not as complete as they could 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 -- 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 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(a)lists.linuxaudio.org 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. I just remembered that we had a discussion about Ravenna here before, I think the conclusion was that it's not that simple...

So my idea is that: - in time with the word clock a stream of data is sent over the ethernet. - it is less than the length of one word clock pulse - The data includes: x channels of audio formatted as consecutive AES3 (like MADI) An end of audio tag

a data tag that tells how much data is within the frame regular data packets perhaps encapsulated in some form. - both ends look to the OS like both an audio device and an ethernet port - One end is responsible for breaking network data packets apart - the other end puts them back together.

Really? Coax, optical or both? I used MADI routers in my work but that was more about sharing multi-channel audio across sites miles apart than low-latency monitoring... (I also have to sadly admit the MADI system is one of the ones I new the least about by the time I left that job :( )

Sounds like CobraNet at it's lowest latency setting (1.33ms per direction, plus a little propagation delay.)

I assume people have heard and read up on AES67? I admit I haven't beyond skimming it and can't say I'm sure whether it's its own specification or more about getting the various existing solutions to communicate together. Probably worth reading though... http://www.aes.org/publications/standards/search.cfm?docID=96

I assume people have heard and read up on AES67? I admit I haven't beyond skimming it and can't say I'm sure whether it's its own specification or more about getting the various existing solutions to communicate together. Probably worth reading though...

If I was going to use any existing project at all, it would be netjack. Coming up with a level 2 variant would probably make it what I want.