Re: [LAU] Sample rate vs. SNR

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@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-user
>

-- 
Len Ovens
www.OvenWerks.net
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user