Modular multi channel DIY AD/DA Box

GroupDIY Audio Forum

Help Support GroupDIY Audio Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Hi guys,
finally some more interest in the interface discussion, nice!
For all people interested into adat, as said before there already is a solution available with Mikkels board.
So there is no obstacle for you if you want to keep your system like it is and add the hardware.
Up to 48khz. Awsome enough one could immediately start building without any fear there would be no interface available ;-) .

Next, AES definitely has it's advantage of the low jitter level that can be achieved.
Obviously preferable for tracking or mastering (low channel count, high quality). Seems no way around dedicated hardware computer interface (e.g. lynx) and, well, much cabeling.

IEEE1394 aka firewire is a nice thing IF it works (e.g. using a lightbridge is really cool once all is up and running and unbeatable in price/value).
Took me quite some time on some machines. Worked right o-o-b with others...issues with pc latform due to ms can be resolved (RME had some very useful instructions on their site. Complicated for developers really, limited cable length etc are drawbacks really.

If you already have a cool running high channel count system, well, a new interfacing method might not be for you. Nevertheless, the option to try an ethernet based one (computer interface cost = 0, hehe, liked that one) really cannot be wrong....

Short status report
from my work on this (WDM PC ethernet audio driver)...
Made a concept paper/todo list for myself to not loose the focus in all those sdk's, DDK's, WDK's...
During research and programming, I read on the dev forums 'bout a guy who already did it to stream audio from win to linux (closed source/commercial), similar model used by motorola to stream to BT headsets, etc, so I guess I am on the right trail now.
I found all the bits and pieces that are needed, but things have to be knitted together now.
Yes, driver development is absolutely no piece of cake, in no way.
I don't know much about the mac and vhdl hardware side of things but i assume things are worse in win driver world.
(learning curve is very steep. highly proprietary and abstract stuff even for people who do or did programming for a living)
Porting to mac might not be much easier than driving mac stuff from scratch.
ASIO: From experience I know asio4all is quite mature in the meantime, I used it once to integrate/'merge' 2 different cards (wdm drivers) and was able to use both at the same time under ONE asio driver. Cool stuff. Very usable under Win....
don't know about asio driver stuff on mac platform...

Unfortunately mac and vhdl hardware developers, excuse me if it sounds odd, may be a bit more on the commercially oriented side of things...(i.e. they know the cost of a man-hour.)
Raphael is right about the hardware side of things, i see no commitments so far reg. fpga development....definitely a show stopper.

Kind regards,
Martin
 
I think this is a good discussion. ADAT blows. It's limited to 48kHz. We don't run at 48kHz anymore. Yes, 48kHz is good fidelity. But it's still limited. I have been researching firewire for 3-4 years now. Only recently has it come to light that some of the firewire solutions have high CPU overhead. This is bad. Streaming audio via ethernet is a very attractive option. I have been following this one too. I am not a software engineer but I work closely with three of them everyday. Windows drivers are a pain-in-the-ass. Writing any driver (win, linux, mac) can be 6 months minimum. I don't have the money or the skills to do that. So I wait for the industry to develop. Anyways, let's keep this going. DANA.
 
smallbutfine said:
Unfortunately mac and vhdl hardware developers, excuse me if it sounds odd, may be a bit more on the commercially oriented side of things...(i.e. they know the cost of a man-hour.)
Raphael is right about the hardware side of things, i see no commitments so far reg. fpga development....definitely a show stopper.

I do FPGAs for a living ...

What's needed is a reasonable definition of the scope of work! then I can tell you how long it'll take.

-a
 
smallbutfine said:
Hi guys,
finally some more interest in the interface discussion, nice!
For all people interested into adat, as said before there already is a solution available with Mikkels board.
So there is no obstacle for you if you want to keep your system like it is and add the hardware.
Up to 48khz. Awsome enough one could immediately start building without any fear there would be no interface available ;-) .
Tubemooley said:
I think this is a good discussion. ADAT blows. It's limited to 48kHz. We don't run at 48kHz anymore. Yes, 48kHz is good fidelity. But it's still limited. I have been researching firewire for 3-4 years now. Only recently has it come to light that some of the firewire solutions have high CPU overhead. This is bad. Streaming audio via ethernet is a very attractive option. I have been following this one too. I am not a software engineer but I work closely with three of them everyday. Windows drivers are a pain-in-the-ass. Writing any driver (win, linux, mac) can be 6 months minimum. I don't have the money or the skills to do that. So I wait for the industry to develop. Anyways, let's keep this going. DANA.

When I was advocating ADAT, I meant SMUX (96 kHz). I too would have little to no interest in a 48 limited ADAT. 96, on the other hand, should IMO be fully satisfactory (and totally plug and play - no drivers required) for the foreseeable future.

Does Mikkel's board allow SMUX?

Also, Tubemooley, the driver writing challenges you mentioned are exactly the reason I think ADAT would be most realistic. Not even a commercial company has released an Ethernet-based unit and they have coders they pay full time for this stuff. If someone's going to volunteer write and support a driver, that would be awesome, but I think it might be a bit over-ambitious and could be setting the project up for failure.
 
Tubemooley said:
I think this is a good discussion. ADAT blows. It's limited to 48kHz. We don't run at 48kHz anymore. Yes, 48kHz is good fidelity. But it's still limited.

I'll have to tell Apogee that my AD-16X blows because it's hooked to my DAW via ADAT protocol.

Yikes! ???

I don't think Apogee ever got their Firewire interface for the AD-16X working properly.

Mark
 
Biasrocks said:
I don't think Apogee ever got their Firewire interface for the AD-16X working properly.
Probably depends of what firewire interface is used at the host. The host card needs a TI chipset, otherwise it will never work at all.
 
Not even a commercial company has released an Ethernet-based unit and they have coders they pay full time for this stuff.


I beg to differ. There are 3 or 4 ethernet-based audio streaming solutions out there. But the drivers are not circulated freely. You have to purchase the equipment. The latest is from Audinate in Australia. They have licensed it to Lab Gruppen (amongst others) for audio streaming in sound reinforcement applications. Another one is from a subsidiary of Telos. It's called Axia or something. I am not saying that these are ideal solutions. In fact, who can tell because they are basically proprietary at this point. But they are a step in the right direction. And ADAT blows because it's a pain-in-the-ass. Yes, it works and it's very solid. I have 3 or 4 ADAT devices. But when you go into S/MUX mode, you lose half of your channels in that connection. I don't care what Apogee thinks. Tell them whatever you want. I know what I like and what I don't like. I was expressing my opinion. You can poop all over my opinion. I don't care. It's still my opinion and I'm not going to think badly of you for disagreeing with me. That's why it's called a forum. DANA.
 
Digigram sells their EtherSound products. Then there's SuperMAC. Sony first developed SuperMAC and HyperMAC which seem to be evolving into AES50. This is a cut-and-paste from www.zpeng.com == "The SuperMAC technology behind AES50 had been developed by Sony Pro-Audio Lab, Oxford, and later acquired by Klark Teknik, who are now making the technologies available on a royalty-free basis. Klark Teknik has selected ZP as an authorized AES50 implementor in 2008. Furthermore, ZP is one of the founding members of the AES50 Trade Association (AES50TA). More information can be found at: http://www.supermac-hypermac.com and http://www.aes50ta.org." == end of quote. Lynx Studio Tech has released their AES16e-50 card recently. ((Good luck contacting ZP. They exist but they don't respond to e-mails. I got them to respond to me once about a year ago.)) DW.
 
Hi guys,
you threw some interesting information and links into the discussion.
Personally I don't think adat sucks for what it is but for sure there are better things possible.
Unfortunately, Mikkels board does not support smux for now, it was developed for apogee converters that were not capable of 96khz.

Right now i am starting to read about aes50 and noticed already at the first pages, that there are some things I did not think of.
E.g. AES50 is bound to 100-base-t networking max. This is due to definition of RJ45 pin assignments, (gigabit networks have diff. pin assignments! Those are compatible, but the additional bandwidth is not usable in AES50 hardware.)

Andy, great you chimed in!
Since I do not have any protocol details right now and there is already a lynx solution avail, I think AES50 documentation might give an impression of the what has to be done for a proper implementation of such a protocol...
Maybe it's even exactly the way to go, because it is already an open industry standard, OTOH there may be some obstacles to implement aes50 'the software way'.
What frightens me most at the moments is the implementation of clocking on the pc side.....
I did not do such stuff before in any way....
Also, Andy could you maybe take a short sneak view into the opencores.com free implementation of adat and comment on how labour intensive it would be to implement s/mux? That would be of great help as well.

Kind regards,
Martin

BTW, half a year of development time for a functional or even stable driver seems to be a realistic value IMHO....but we'll see.

P.S. there are some more things that firewire sucks at. Not only are the TI chips the most reliable by far (found only one PCI card that worked with the lightbridge without a TI chip). There are problems with the hot-plugging, frying the chips. It is even possible to fry the chips due to reverse insertion! Don't laugh. I fried a lightbridge once due to that. This is easily possible due to miserable quality of some cable plugs and jacks! I did not even think of such a possibility. Due to power distribution in the cable you instantly fry the phy chip.
External powering is dangerous as well. This can fry the computer interface phy...
Nevertheless I love the lightbridge.
 
smallbutfine said:
I think AES50 documentation might give an impression of the what has to be done for a proper implementation of such a protocol...

(emphasis mine)

AES50 is great if you want interoperability, which is a good thing seeing how many AES50-compliant products are out there.

AES50 is not so great if you want best throughput, or lowest latency, or something that's very simple to implement in an FPGA, or something that's easy to write a driver for, or an example of a clean protocol.

JD 'design by committee' B.
[AES50 is pretty good if you're studying Business or Organizational Culture and you're writing a thesis on Industry Standards]
 
Haha,
good one, JDB.
You should see my face when I read the AES docs. (Eyes white open most of the time...)
Not an easy task at all for DIY (AES50), but for now, I take it as an example of how it could be done-
I really do not know by now if a proper implementation of the standard is possible to do by software driver+network card or if some changes would make this much easier to realize or even improve practical value.
For me it looks like it's a protocol that allows to sell specialized products to customers with good budgets. (like MADI eh, AES10)...
 
Thanks for that link. I just downloaded those doc's. Don't forget..... Cirrus has their CobraNet product too. That's ethernet-based also but I can't remember if it can co-exist on a regular LAN. I don't think it can. I think it needs a dedicated CAT5. I just linked thru Cirrus to these guys..... www.audioscience.com. They have a product using the Axia Livewire protocol mentioned above. This one can operate on a standard ethernet network. Go look at their ASI6585 product. It has Windows and Linux drivers. DW.
 
The ADAT interface and 44.1 / 48 K are here to stay, and there is much hardware out there in use and not about to be thrown away, so I see no problem supporting them. I know several top notch engineers and producers that have records out that are currently charting, and NONE of them use anything higher that 48k. EVERY production I have / am working on for TV & film are at 48K.
Yes, higher sample rates sound better, and no, kids listening to MP3s do not care.
IMHO, the remarkable efforts represented here should stay focused on meeting current needs, and if they can grow to accommodate future trends, then all the better. Just avoid the trap of dissolving in pursuit of the next best thing......
 
To me, the next best thing is people that have an integrated ethernet card or two and would like to use it to stream audio data to and from a DIY A/D D/A converter. Possibly while they are connected to the internet. I couldn't care less about ADAT, AES or MADI in that respect; they all require them to buy additional cards or other hardware to make a viable recording solution. While you usually get onboard DSP mixing or some other boon, it comes at a price that I hope to eliminate and make multitrack recording more comfortable (computers abound and there's usually a free port on the router) and affordable. Even if you had to buy an additional ethernet card it's WAY cheaper than a, for instance, AES or MADI card..
 
FWIW, this thing here, the USRP2 is a Xilinx Spartan 3 at its heart, using a gigabit ethernet interface to manage it's ADC/DAC data exchange. All schematics and sources are fully available for download. It supports Windows, Linux as well as Mac. Might be worth a look for anybody interested in developping such an interface (or a chat with its designer), unfortunately I know next to nothing about FPGA programming...
 
So, here is a first preview of the AES receiver transmitter board.
Finally I decided to use the DIX4192 because that is the most cost effective solution. The downside is that you need a small microcontroller that sends two or three bytes to the DIX4192 for enabling the receiver port. However, I accept that because you can do that with a small AVR. They only cost 2Eur and everyone can program the internal flash with a PC if the PC offers a RS-232 port (or a USB-to-RS232 converter for 10Eur).
The chips from cirrus turned out to be much more expensive especilly the transmitter.
Tommorrow I'll post the final schematic. Then I'll wait for some days for some remarks on it before I order the first prototype board.

Raphael
 

Attachments

  • DIX4192.png
    DIX4192.png
    138.8 KB · Views: 299
smallbutfine said:
Also, Andy could you maybe take a short sneak view into the opencores.com free implementation of adat and comment on how labour intensive it would be to implement s/mux? That would be of great help as well.

The opencores ADAT project has vanished.

I looked at it awhile ago and didn't think much of it. The protocol itself, based on the ADAT patent docs, is really simple and the transmitter is very easy. The receiver is a bit more complicated because you have to extract the clock from the data.

[quote[P.S. there are some more things that firewire sucks at. Not only are the TI chips the most reliable by far (found only one PCI card that worked with the lightbridge without a TI chip). There are problems with the hot-plugging, frying the chips. It is even possible to fry the chips due to reverse insertion! [/quote]

You have to work VERY hard to plug a FireWire cable in backwards. You'll certainly destroy the jack, and most devices don't protect against the power being applied to the wrong pins because the connector is supposed to prevent that.

-a
 

Latest posts

Back
Top