Re: [LAU] Sample rate vs. SNR

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Florian Faber <faber@...>
Cc: <linux-audio-user@...>
Date: Thursday, January 24, 2013 - 9:52 pm

On Wed, January 23, 2013 11:53 pm, Florian Faber wrote:

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.

>

--
Len Ovens
www.OvenWerks.net

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAU] Sample rate vs. SNR, Len Ovens, (Wed Jan 23, 2:52 pm)
Re: [LAU] Sample rate vs. SNR, Ralf Mardorf, (Wed Jan 23, 4:43 pm)
Re: [LAU] Sample rate vs. SNR, Joe Hartley, (Wed Jan 23, 8:20 pm)
Re: [LAU] Sample rate vs. SNR, Len Ovens, (Wed Jan 23, 10:10 pm)
Re: [LAU] Sample rate vs. SNR, Florian Faber, (Thu Jan 24, 7:53 am)
Re: [LAU] Sample rate vs. SNR, Len Ovens, (Thu Jan 24, 9:52 pm)
Re: [LAU] Sample rate vs. SNR, Fons Adriaensen, (Fri Jan 25, 1:43 am)
Re: [LAU] Sample rate vs. SNR, Len Ovens, (Fri Jan 25, 2:45 pm)
Re: [LAU] Sample rate vs. SNR, Fons Adriaensen, (Fri Jan 25, 3:21 pm)
Re: [LAU] Sync and digital audio transport, Len Ovens, (Fri Feb 1, 2:38 pm)
Re: [LAU] Sample rate vs. SNR, Ralf Mardorf, (Fri Jan 25, 7:15 pm)
Re: [LAU] Sample rate vs. SNR, Len Ovens, (Sat Jan 26, 2:04 am)
Re: [LAU] Sample rate vs. SNR, Ralf Mardorf, (Sat Jan 26, 9:42 am)
Re: [LAU] Sample rate vs. SNR, Len Ovens, (Sat Jan 26, 3:18 pm)
Re: [LAU] Sample rate vs. SNR, Ralf Mardorf, (Sat Jan 26, 3:26 pm)
Re: [LAU] Sample rate vs. SNR, Len Ovens, (Sat Jan 26, 5:21 pm)
Re: [LAU] Sample rate vs. SNR, Ralf Mardorf, (Fri Jan 25, 2:53 pm)
Re: [LAU] Sample rate vs. SNR, Paul Davis, (Wed Jan 23, 11:13 pm)
Re: [LAU] Sample rate vs. SNR, Charles Z Henry, (Thu Jan 24, 1:14 am)
Re: [LAU] Sample rate vs. SNR, Paul Davis, (Thu Jan 24, 2:31 am)
Re: [LAU] Sample rate vs. SNR, Len Ovens, (Thu Jan 24, 3:48 am)
Re: [LAU] Sample rate vs. SNR, Ralf Mardorf, (Thu Jan 24, 1:32 am)
Re: [LAU] Sample rate vs. SNR, Charles Z Henry, (Wed Jan 23, 10:50 pm)
Re: [LAU] Sample rate vs. SNR, Fons Adriaensen, (Wed Jan 23, 4:17 pm)
Re: [LAU] Sample rate vs. SNR, Len Ovens, (Thu Jan 24, 4:26 am)