On Wed, January 23, 2013 11:53 pm, Florian Faber wrote: > On 01/23/2013 11:10 PM, Len Ovens wrote: >> [..] >> I would suggest that any PCI(e) card that has ADC/DACs on the card is >> less >> than a great quality card, even dealing with sample clock (or power) on >> the card seems less than optimal. For audio quality, it seems FW, USB >> and >> ethernet _could_ give better results if designed right. > > You seem to forget that the main problem is not transporting the audio > data, but interact with other equipment. And there are only so many > protocols to do that. Also you have a lot of real world problems like > clock distribution or simply broken implementations (it really doesn't > work pointing fingers at the broken end of a signal chain if 'other > devices *do* work'). In a studio or broadcast environment, reliability > is the main concern. The interfaces you have listed are ancient (MADI is > 25 years old!) and there simply was nothing the like available at that > time. MADI (or ADAT) are as you say, audio transport protocols. For that purpose they are fine, and it seems come for free... or if they don't come for free, the ADC/DAC does. (There seem to be a number of FW/USB Audio IFs that have not only have 8 channels of audio in and out of the computer, but also ADAT i/o... all for the same price as a PCI(e) ADAT only card) Both MADI and ADAT make sense if they are used as a transport medium. I think however, when they are used as a computer interface method they stop making sense. There is a digital snake available (Black Mamba) that uses cat5 cable to join the ends and the ethernet protocol to transfer data. It sends sync over the same cable just the same as other digital audio transports. Because it is layered on top of the net, things are a bit easier to see. It is very hard to get stable sync out the second end and takes a lot of CPU time to do so. Someone has used it in this manner (look up jack mamba with google) and was able to build a jack backend that would talk with it. It used a lot of CPU and it was hard to get a low jitter sync, but in case of the use transport was a major part of the need and so the cpu load was considered acceptable. I think if one computer was dedicated to act as an end of the transport and deal with just the sync and data, the cpu load would be less... or not really matter (it wouldn't matter because it would be constant load as audio lines don't change in load for transport) A second Ethernet connection could go from that box to the computer that was generating signal or recording it. That second link does not have to have sample sync as it just sends 32 or 64 sample packets that are reasonably in time and so the cpu load would be less. Also, the general running of the computer would have less impact on the audio. What I am trying to say, is that transport protocols are not the best thing for computer interface use. I think sync should be totally external to the computer box (though it may/will have it's own dedicated computer). I am not sure that ethernet is the best thing either, but, it is available, cheap, and easy to hack. Netjack does give a usable interface protocol that spans OSs and (so far) I have found it to be stable. I think though the future is in USB3 (unless something else shows up real quick) as it effectively brings the PCIe bus outside of the computer case. The problem in the past with the PCI bus has been it's flexibility. Each audio card was interfaced to the PCI bus in a different manner and so each had a different driver. AC97 and HDA are attempts standardize the audio interface, but really USB1.1 and USB2.0 audio standards are a bigger step in the right direction than they appear (from looking at Linux support for these devices). It might be interesting to use USB3 with the HDA chipset and a good set of ADC/DACs on top of that. I don't know how much intelligence would be needed in such a box.... Or if it would just work with the HDA driver. Just a note on external sync/clock. The TV stations have been doing it for years, Master sync with failover to hot backup goes to every video source in the building (Our sync was colour black). Cable lengths (includes the length from the video source to the switcher as well) were all the same (or had delays to look that way) to make things line up. The problems with jitter from long cables don't go away from adding sync to the computer interface, they just get worse. Learning to deal with external sync is the answer. > > Tell you what: Assemble a system that is able to distribute 64ch audio > data transparently and an AES conforming word clock via ethernet between > two nodes using open standards and today's equipment, and we'll see if > it is cheaper than a MADI setup. You get bonus points if it runs on Linux. > > I am not trying to defend MADI, but trying to put things a bit into > perspective. The price argument will change things rapidly in the near > future. But I'm not sure it does today. > > > Flo > -- > Machines can do the work, so people have time to think. > public key 8D073185 x-hkp://subkeys.pgp.net > _______________________________________________ > Linux-audio-user mailing list > Linux-audio-user@xxxxxxxxxxxxxxxxxxxx > http://lists.linuxaudio.org/listinfo/linux-audio-user > -- Len Ovens www.OvenWerks.net _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
