Audio-over-ethernet and digital clocking

[nb[_2_]]

Say, does anyone such as the esteemed Mr. Dorsey have any insight into
how things are clocked when you send audio over ethernet in real time?
We're just now starting to see software replacements for multiple
audio (and MIDI) interfaces on slave computers, and I'm curious how
this works. VSL's Vienna Ensemble 3 and upcoming VE Pro, as well as
Audio Impressions Audioport are the two examples of this I know about;
Apple has had it AU Netsend/Receive (I think that's what it's called)
built into the Mac OS for a while, but it doesn't work very well. The
other two work really well.

Am I right that ethernet uses packets and that the receiving
computer's audio interface is going to do the clocking?

The truth is that even if this turns out to be suboptimal from an
audiophile point of view, it's trumped by the convenience - at least
in my composers' world of using slave computers to play back samples.

TIA

[Scott Dorsey]

nb > wrote:
>Say, does anyone such as the esteemed Mr. Dorsey have any insight into
>how things are clocked when you send audio over ethernet in real time?

They ain't clocked at all. The ethernet is completely asychronous. You
have multiple things sending bits across the line. The latency across the
pipe is nondeterministic and not readily calculable. What makes it work
is that you have huge amounts of bandwidth and you only use a little.

>We're just now starting to see software replacements for multiple
>audio (and MIDI) interfaces on slave computers, and I'm curious how
>this works. VSL's Vienna Ensemble 3 and upcoming VE Pro, as well as
>Audio Impressions Audioport are the two examples of this I know about;
>Apple has had it AU Netsend/Receive (I think that's what it's called)
>built into the Mac OS for a while, but it doesn't work very well. The
>other two work really well.
>
>Am I right that ethernet uses packets and that the receiving
>computer's audio interface is going to do the clocking?

Right... it's all completely asynch except at the beginning and the end
of the connection.

>The truth is that even if this turns out to be suboptimal from an
>audiophile point of view, it's trumped by the convenience - at least
>in my composers' world of using slave computers to play back samples.

It's a very inelegant way of sending realtime data, but it's just so damn
cheap, and most of the time it has no problem meeting realtime deadlines.

Because the problems with clocks on A/D and D/A systems were pretty well
solved a decade ago, you don't have any sound quality problems to worry
about as long as the ethernet is fast enough to keep the receive buffers
full. And when it can't keep the receive buffers full, you get dropouts.

So it's a good idea to dedicate an ethernet link to JUST digital audio and
keep everything else off of it.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Les Cargill]

nb wrote:
> Say, does anyone such as the esteemed Mr. Dorsey have any insight into
> how things are clocked when you send audio over ethernet in real time?
> We're just now starting to see software replacements for multiple
> audio (and MIDI) interfaces on slave computers, and I'm curious how
> this works. VSL's Vienna Ensemble 3 and upcoming VE Pro, as well as
> Audio Impressions Audioport are the two examples of this I know about;
> Apple has had it AU Netsend/Receive (I think that's what it's called)
> built into the Mac OS for a while, but it doesn't work very well. The
> other two work really well.
>
> Am I right that ethernet uses packets and that the receiving
> computer's audio interface is going to do the clocking?
>

Yes. The data are buffered. Why not just pull data over
a network file system?

> The truth is that even if this turns out to be suboptimal from an
> audiophile point of view, it's trumped by the convenience - at least
> in my composers' world of using slave computers to play back samples.
>
> TIA

Mind the delay.

--
Les Cargill

[Mike Rivers]

Scott Dorsey wrote:

> It's a very inelegant way of sending realtime data, but it's just so damn
> cheap, and most of the time it has no problem meeting realtime deadlines.

Is Finagle's Law (or whoever it is who said something like "Content will
grow
to exceed the available bandwidth") going to affect this?


--
If you e-mail me and it bounces, use your secret decoder ring and reach
me here:
double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers
)

[Scott Dorsey]

Mike Rivers > wrote:
>Scott Dorsey wrote:
>
>> It's a very inelegant way of sending realtime data, but it's just so damn
>> cheap, and most of the time it has no problem meeting realtime deadlines.
>
>Is Finagle's Law (or whoever it is who said something like "Content will
>grow
>to exceed the available bandwidth") going to affect this?

Of course, because no matter how many channels you have, somebody will
want more. The good news, though, is that it's so cheap, you might as
well just get a second interface and a second cable...
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Paul P[_3_]]

Mike Rivers wrote:

> Is Finagle's Law (or whoever it is who said something like "Content will
> grow
> to exceed the available bandwidth") going to affect this?

I cringe everytime I see a 'normal' person include videos or a
hundred hi-res photos in an email. There was a time when we worried
about presenting too high a load to the network for the task at
hand. Making the data as small as possible before sending was
just the polite thing to do. People today don't have a clue
about things like that. It's amazing that the Internet doesn't
collapse under the weight of it all.

Paul P

[Paul P[_3_]]

Paul P wrote...

Hmmm. Misread ethernet as internet...

[Nick Brown]

On 23 July, 19:18, nb > wrote:
> Say, does anyone such as the esteemed Mr. Dorsey have any insight into
> how things are clocked when you send audio over ethernet in real time?

I don't have cause to run audio between multiple computers, so I don't
have specific experience of this, but...

In the case of using a slave computer to run software synths playing
back sequences of notes that are already recorded, there is the
posibility for the sequence data to be sent over the network to the
slave computer ahead of time, the slave computer to render the notes
into an audio stream, and the stream be returned to the master
computer early enough to be integrated into the mix without any delay
or other clocking artefacts.

This is essentially cheating, because the fact that the sequence is
pre-recorded means that the computers don't actually have to deal with
it in real time. Under those circumstances, there shouldn't be any
difference between running the synth on the DAW or running it on a
slave computer attached via the network.

Not every audio-via-ethernet system is going to be able to do this,
but I think that the Vienna software does work that way, so long as
it's used in conjuntion with a DAW that supports latency compensation
for software synths.

And of course, once you try to do something genuinely real time, (like
recording a performance from a MIDI keyboard being rendered by a
slaved software synth) then the cheating won't work, and the extra
delays in getting the data back and forth across the network are going
to manifest themselves. How much of a problem that causes in practice
is something that anyone running such a system probably ought to form
their own opinion about, ideally based on actually trying it.

But hey, isn't the concept of recording performers getting to be a
little out-moded these days? ;-)

-Nick

[Anahata]

On Fri, 24 Jul 2009 00:19:59 +0000, Mike Rivers wrote:
>
> Is Finagle's Law (or whoever it is who said something like "Content will
> grow
> to exceed the available bandwidth") going to affect this?

Yes, but if you're on 100MBb ethernet, 1GB ethernet is waiting in the
wings and can use the same cables if you aren't going silly distances.
There's several faster standards too, at a price...

--
Anahata
-+- http://www.treewind.co.uk
Home: 01638 720444 Mob: 07976 263827

[nb[_2_]]

Thanks very much for the replies. The answer I was looking for is what
Scott said: the audio is buffered and therefore the clocking doesn't
matter.

Just to fill you all in, this generally requires gigabit ethernet (or
at least it's recommended), and in the case of VSL's Vienna Ensemble
the latency is 2x the host buffer - pretty much the same as it is
using interfaces. This actually works amazingly well - it's not in the
experimental stage. Audioport is a little more finnicky and it doesn't
have MIDI, but it works well too. So this isn't just theory - I have
it goin' on here every day.

Dedicating an ethernet port to this is possible, but in practice it's
a PITA to set up. PCs and Macs aren't really used to doing that, even
though current Mac Pros have two ethernet ports. It's better just to
stop watching movies online while you're working on music. ;)

Mike, interfaces aren't all that cheap. The least expensive boxes with
at least one lightpipe would be the M-Audio ProFire Lightbridge or the
Presonus box. They have four lightpipes, which may be overkill, and
they're at least $400. If you're using an insane set-up like mine with
four or five slaves, that adds up. Well, Frontier Designs Wavecenter
PCI cards are cheaper, but they're very long in the tooth.

" Why not just pull data over a network file system?"

That's a different application. We're talking about the equivalent to
using slave computers as MIDI modules: MIDI goes in, audio goes out.
Only they run a *lot* of stuff at once. You don't necessarily need a
billion independent outputs going down the ethernet line - 64 would be
enough for most people - but it does have to be reliable.

Thanks again.