Die, SPDIF ! Design of the Ethernet DAC

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
If the debate is about raw data over USB vs. raw data over ethernet, the former may not be that much harder to implement than the latter: use a FTDI chip for the USB interfacing, they provide a free to use driver along with a clean library, and it's well thought-out and hassle-free. You'll probably get lower latencies, on average, than with regular ethernet via a socket (UDP or TCP). Of course, you can write your own optimized ethernet protocol, but then that would be a much harder work in my opinion.

As for isolation, you may isolate at the I2S level instead of at the USB level - or between the USB controller and the microcontroller if you use a dedicated chip like FTDI's ones.

The only problem I see with USB is that, whereas using full-speed (12 Mbps) is rather straightforward (there are several "almost ready to use" solutions), if you need more throughput (like high-speed USB 2.0), there is virtually no simple solution apart from the Cypress microcontrollers (FX2), but you would have to write the USB driver yourself (not trivial if you want good throughput), and you would most likely need an additional microcontroller for I2S output, or an FPGA. A pain, but doable.

Note that if you want more than 10 Mbps ethernet, you're in for a rough ride as well...

I have not decided on an interface myself yet. Almost looks like we would need to devise a brand new one...

At one point, I had thought about some kind of isolated RS-485, but that would probably mean a dedicated PCI card, a special driver on the computer... a lot of work.

I am now thinking about not using a computer at all. Interfacing between modules could indeed be some kind of RS-485 or LVDS (cheap, fast and reliable).
 
The “only” coding difference between USB and Ethernet with respect to audio is the layer that actually transmits the bits. Once you have that layer, the rest (layers above) is the same. For Ethernet/IP you often have this layer (consisting of a number of layers on its own) implemented when you purchase the hardware. For USB you often have to implement it. This is why people perceive USB more difficult to code than Ethernet. Needing to implement the whole Ethernet/IP/UDP stack you would say that USB is simpler, but then you usually don’t have to.

I don’t know whether my USB DAC uses galvanic isolation or not. But I cannot hear any difference in silence at full volume level whether the box is physically connected to a PC or not. If there were any noise coming from PC when not playing anything then I would hear it. It is also difficult to see why this noise would appear only when actually playing something (and therefore be masked by the music). Then again, who knows, maybe there are PCs and PCs as well as DACs and DACs.
 
Yeah, modern computers have this problem : they are super powerful, but there is no easily accessible data I/O for tweakers. Serial and parallel ports are obsolete (and always sucked) ; this leaves USB, FireWire and Ethernet basically. Using a mobo slot is dangerous : Ethernet will outlive PCI, PCI-X, and the next few generations, because it's a lot easier to change a mobo and boards than to rewire a building. I would bet USB will still be there in 20 years, too.

AudioWizard said:
If the debate is about raw data over USB vs. raw data over ethernet, the former may not be that much harder to implement than the latter [...] The only problem I see with USB is that, whereas using full-speed (12 Mbps) is rather straightforward (there are several "almost ready to use" solutions), if you need more throughput (like high-speed USB 2.0), there is virtually no simple solution apart from the Cypress microcontrollers (FX2), but you would have to write the USB driver yourself (not trivial if you want good throughput).


Yes, you see what I mean ? I went through all this, I also considered a lot of USB chips, but high-speed USB is not very DIY friendly. Also, a friend of mine who professionally writes USB2 drivers told me to stay the hell away from it.

Note that if you want more than 10 Mbps ethernet, you're in for a rough ride as well...

Eh ? I have 100 Mbps running on the Suzaku, no problem at all, and I'm quite confident I can do the same with the NGW100 ; the choice I'm facing now is, can I do it with Linux (I'd like to keep Linux) or will I have to go stand-alone ?

The reason I'm ditching the Suzaku isn't that it can't handle the throughput, it's the damn 48 KB of BRAM ; I can't put an extra line of code and I still need more features.

I have not decided on an interface myself yet. Almost looks like we would need to devise a brand new one...

At one point, I had thought about some kind of isolated RS-485, but that would probably mean a dedicated PCI card, a special driver on the computer... a lot of work.

A lot of work, would it get finished ? I prefer OEM modules...

and you would most likely need an additional microcontroller for I2S output, or an FPGA. A pain, but doable.

I thought FPGAs were hard, then tried ; it took me av evening to write a multichannel configurable parallel to I2S encoder...
 
audiosteve said:
Have you looked at the CobraNet chips from Cirrus??
CS181xx and CS496xx families of parts.
Also worth a look would be the CO2 boards at http://www.atterotech.com

Hi Steve,

I have just stumbled over this thread in this forum, when I was looking into different means to transfer audio over ethernet...

I have a specific question regarding your CobraNet-stuff, but I'm so far unable to write emails on this forum (since I joined brand-new ;-), so I'd be glad if you could contact me instead...

Best regards,
Tobias
 
Ethernet AV

There is a new Ethernet standard emerging in the networking world. It will require switches equipped with special newer generation chips, but it will be able to handle low latency multichannel audio and video over standard (edit) CAT5e or CAT6. The higlights are:
2ms latency over up to 7 switch hops,
low jitter, central clocking,
easy user configuration.
It's called Ethernet AV and the underlying hardware is already in production. The new generation of switches and devices equipped with the Ethernet AV chips should emerge this year.

Here is a link to a pdf slide show that highlights the important points of the technology.
http://ieee802.org/1/files/public/docs2006/avb-mjt-EthernetAV-summary-060425.pdf
 
Can you please tell us names and model numbers of underlying hardware in now in production for Ethernet AV? I would be surprised if this is true as the AVB and AVBTP IEEE committees are still very much still hashing these new standards out. If they have made more progress than this I would be very interested to know. The whole thing that I don't like about these emerging standards are the requirements for specialized switches and MACs. This would be much more attractive (IMHO) if it worked using standard infrastructure.
 
XMOS has an AVB ref design and I think you can get boards from DigiKey.
Cirrus logic also has the CobraNet chips and AtteroTech has modules available for that. And Audinate has their Dante technolgy with modules available for that. For DIY CobraNet or the XMOS ref design ar probably the way to go. If you are looking to transport audio over ethernet in real time, rather than use SPDIF, then technology already exists that also operates as a scalable network, not just a spdif replacement. There is no need to re-invent the wheel on this. BTW, that Broadcom part linked to above is a MAC/PHY with a PCI I/F, not an AVB controller; although it natively supports some of the AVB bits like 1588 and Qav.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.