Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

Christoph Kuhr
Hi list,

i want to write a jack2 network backend, like netjack2, for my bachelor
thesis.

There is a new network standard comming up specialized for audio and
video transmission, called AVB (Audio Video Bridging -> IEEE 802.1AS,
802.1Qat, 802.1Qav,...).

I want do integrate this standard into jack2.
I want to choose AVB (not ALSA or NET) from the driver dropdown box.

does anyone know where i can find this implementation in the source code?








_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

Florian Faber-2
Christoph,

> does anyone know where i can find this implementation in the source code?

The implementation for what exactly?

And you are aware that you cannot do AVB without proper hardware support?


Flo
--
Machines can do the work, so people have time to think.
public key B3B9226C          x-hkp://wwwkeys.eu.pgp.net
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

Arnold Krille-3
In reply to this post by Christoph Kuhr
On Friday 25 February 2011 11:02:43 Christoph Kuhr wrote:
> i want to write a jack2 network backend, like netjack2, for my bachelor
> thesis.
>
> There is a new network standard comming up specialized for audio and
> video transmission, called AVB (Audio Video Bridging -> IEEE 802.1AS,
> 802.1Qat, 802.1Qav,...).
>
> I want do integrate this standard into jack2.

Congrats, I am trying the same (with one evening every two weeks to spend on
this currently).

I started with making normal clients for sending and receiving rtp. Extension
to the other standards and extension into a backend follows later.

> I want to choose AVB (not ALSA or NET) from the driver dropdown box.
> does anyone know where i can find this implementation in the source code?

You mean the drop-box in qjackctl? That is not in jack itself, but in jackctl.
And a very last step once your backend is working. Until then you really
should learn how to use the commandline and how to start jack from the
commandline (once you have a backend to test).

Have fun,

Arnold

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

Stéphane Letz
In reply to this post by Christoph Kuhr

Le 25 févr. 2011 à 11:02, Christoph Kuhr a écrit :

> Hi list,
>
> i want to write a jack2 network backend, like netjack2, for my bachelor thesis.
>
> There is a new network standard comming up specialized for audio and video transmission, called AVB (Audio Video Bridging -> IEEE 802.1AS, 802.1Qat, 802.1Qav,...).
>
> I want do integrate this standard into jack2.
> I want to choose AVB (not ALSA or NET) from the driver dropdown box.
>
> does anyone know where i can find this implementation in the source code?
>


For concrete implementation in jack2 as a backend, have a look at JackNetDriver or JackNetOneDriver classes (subclasses of JackAudioDriver base class)

Stéphane
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

Chris Caudle
In reply to this post by Christoph Kuhr
Seems like interest and events are coming together all around.
Using standard networking hardware to connect audio devices has been
something
I have wanted for quite a while, but most solutions were proprietary and
because
of that didn't play well in the Linux ecosystem.  NetJack was a notable
exception, but I just couldn't convince myself that running a jack server
on my
ADC was the right way to do it.

Sorry for the length of this, I'm just catching up on several digests.

On Fri, February 25, Christoph Kuhr wrote:
 Message-ID: <[hidden email]
> There is a new network standard comming up specialized for audio and
> video transmission, called AVB (Audio Video Bridging -> IEEE 802.1AS,
> 802.1Qat, 802.1Qav,...).

I have been looking into that over the past couple of weeks, and it seems
that
AVB handles network infrastructure requirements, but does not specify higher
layer protocol.  So the AVB specification handles clock synchronization,
stream
bandwidth reservation, and VLAN setup, and as far as I can tell so far,
that is
all.  You still have to have session control to discover end points, discover
how many channels are offered by the end point, set up connections, define
the
arrangement of audio samples within the packets, etc.

The proprietary methods cover all those other aspects.  The ones which
seem to
lend themselves most readily to software implementation (i.e. should not
require
custom hardware on the computer end) seem to be Dante from Audinate and
Livewire from Axia.  Both are proprietary and not publicly documented.
Ravenna seems that it will become the best choice given the statements
that it
will be published as an open (and I think freely available) standard, but it
does not seem to be finished yet.  The Ravenna web site contains no
documentation so far.

> I want do integrate this standard into jack2.
> I want to choose AVB (not ALSA or NET) from the driver dropdown box.

Is there a particular reason you want to make it native in JACK and not
incorporate it into the ALSA drivers?  I have been considering the same
question, whether it is better to have a driver native in JACK, or whether it
would be better to have it independent of JACK so that it could hopefully
attract developers from the non-JACK audio world as well.  Having an
interface
compatible with ALSA would be attractive from that standpoint, because any
other
Linux application should be able to use it, and JACK should still be able
to use
it through the ALSA backend.

Florian Faber wrote:
> And you are aware that you cannot do AVB without proper hardware support?

Do you mean because of the IEEE-1588 based clock synchronization?
There are software implementations of 1588, are they not accurate enough to
meet AVB requirements?

Arnold Krille wrote:
> I started with making normal clients for sending and receiving rtp.

Have you only sent data, or also handled querying for number of channels
offered, other things required to get general clients connected?  Or just
simple test applications which always have fixed channels?

Christoph Kuhr wrote:
> since there is the PTPv2 sw implementation
> (http://www.bartky.net/products.htm), the endpoint requirements of avb
> are met by most computer hardware

Have you looked at the PTP implementation with BSD style license?
http://ptpd.sourceforge.net/

Adrian Knoth wrote:
> To my knowledge, there are only thee NICs available which make sense to
> be used with PTP

You can use a software time stamping implementation, but with less accuracy
and much higher jitter.   So depending on the requirements you may need a
specialized NIC or you may not.  There will be more available soon, I think
Broadcom and Marvell are working on some.

Arnold Krille wrote:
> I have to admit that I haven't looked at the avb-standard-definition yet.
> But so far I was under the impression that avb is aimed at
> home-entertainment and the likes

It started out aimed at home entertainment, but expanded to also include
professional audio and automotive networking.

> and thus neither needs special switches
> nor special nics.

You need switches which understand VLAN tagging and bandwidth reservation
for quality-of-service.  I don't think the synchronization adds any
requirements
to the switches, just the endpoints, but I'm not positive on that yet.

> Ravenna on the other hand...

Ravenna is just using AVB, as far as I can see from the limited documentation
that Ravenna has released so far, Ravenna has no requirements beyond AVB.


Florian Faber wrote:
> If you want to provide physical inputs or outputs for Ravenna on your
> machine, there's nothing you can do without special hardware - for the
> moment.

Has any documentation on the Ravenna protocol been released publicly yet?

> You have to produce a phase synchronous clock, synced via PtP,
> and provide a means to timestamp incoming samples and output samples at
> the correct point in time.

What is the requirement for time stamping incoming samples?

This is the view point from which I ask the question:  I see the
interesting use
of networked audio as an inexpensive way to get multiple channels of remote
audio into or out of a standard PC without a rather expensive card capable of
MADI or multiple AES3 channels, and in that case the master clock should
be in
the ADC or DAC, so the PC only has to send the incoming packets to hard
drive,
or send outgoing packets at close enough to the correct time that the DAC
buffer
does not have an over or under run.

Does that use case still require hardware timestamp capability on the PC, or
would a software implementation of 1588/802AS meet the requirements?

Arnold Krille <[hidden email]
> I don't want to be fixed exclusively on the network-peers, I want to use
> my internal sounddevices to play that sound too.

That should definitely be a separate use case.  Use of independent clock
domains
is always a pain, and requires SRC to reconcile all the audio to a single
clock
domain at some point.  Single clock domain should definitely be handled
first,
and then separate domains can be added as a special case later.

What might be useful is a way to force JACK to use multiple output devices if
you know that they are all on the same clock domain, e.g. you have two
different
devices which are synchronized with word clock or AES11.  I don't think JACK
currently allows to use two different devices as output, does it?  You
have to
use some ALSA trickery to make a composite device?

torbenh wrote:
> so for the case where you want to slave jack to some avb devices,
> you need to write a backend.
> this use-case is particularly interesting, because it will work with
> normal hardware. (it probably doesnt even need a software ptp
> implementation)

Torben, can you elaborate on that a bit?  We've gone from Florian saying that
we need PTP capable hardware, to you saying that we don't even need software
PTP.
For that to be the case, would you not need some type of feedback signal from
an output sink (e.g. DAC) to let you know when the output buffers were too
low
or too full? Some network equivalent of the interrupt you get from a PCI
card,
and the values in the status register that let you know that it needs more
buffers to DMA.

> but to just output a stream.... no special hardware is needed.

How to you make sure that the DAC buffers do not underrun, or that you do
not send too much data too closely together and cause overrun?  I'll
ignore ADC
for the moment, that seems the easy case as long as your PC is fast
enough to keep up with the amount of data that the ADC is sending.

Florian Faber wrote:
> You mean in the case where jack would only operate on AVB streams and
> not use any local sound interface?

That is the case I find interesting.  A network attached ADC/DAC, either a
single device, or possible separate devices which may have an external clock
synchronization, or which both have hardware PTP capability and synchronize
their internal clocks that way.  Then a standard PC or server (which all have
Gb capable network interfaces, often more than one) can be connected to that
device for audio I/O without requiring to spend an additional $1500 on a MADI
card.  Something just seems odd about spending $1000 on the computer and
$1500
on the audio interface card.  I don't mind spending money on good ADC and
DAC,
but it doesn't seem right to spend so much money for (relatively) low bit
rate
data transfer between the PC and the data source/sink.

> I was thinking of the case where jack operates on a local backend and
> does SRC on AVB ports, if neccessary.

That seems to unnecessarily complicate the problem before the first steps are
even taken.

> It is not I who wants it, it is the spec that demand a phase synchronous
> clock that matches AES criteria, and bit transparency, amongst other
> things.

Is the spec available yet?  I only discovered Ravenna very recently, and
currently on the web site it says that "RAVENNA will be an open technology
standard without a proprietary licensing policy."  Future tense "will be,"
not
current tense "is" an open standard.

>> but to just output a stream.... no special hardware is needed.
>
> If you just produce sound (and do not care about synchronization with
> other sound sources) or want to store the data, yes.

So take the case which is probably pretty common on this list: Ardour running
on a PC with JACK, connected to one device which has some number of ADC and
DAC used to record and play audio.  What would be needed in that case?  PTP
hardware?  PTP software?  Neither?

> In any other case you need a means of hardware synchronization.

Could you describe the cases which would definitely require hardware synch?
Are those cases effectively the equivalent of having multiple sound cards in
one computer, which require an external clock to synchronize the audio clocks
on the cards?  E.g. outputting to two separate network DAC would require
synchronization.  Would the PC definitely require hardware
synchronization, or
would it suffice to have the two audio devices synchronized?

--
Chris Caudle


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

Florian Faber-2
Chris,

first maybe we should differentiate between AVB and Ravenna. AVB is
targeting consumers and has pretty relaxed requirements. Ravenna is
targeting the broadcast sector; it uses some of the basic techniques
from AVB, but adds proper clocks, device discovery etc. Think of
connecting a mic to a speaker and all the problems involved. Or changing
the one defective microphone in a setup with 80 mics. Without the "one
cable, one signal" paradigm things tend to become ridiculously complicated.

I personally have no interest in AVB.

> Seems like interest and events are coming together all around.

The topic comes up from time to time. It will become more interesting
with the availability of cheap AVB compliant network hardware. So far it
is quite expensive, as you probably know - after all, PtP was invented
at HP. For the price of just one switch with PtP support you can already
buy a MADI interface.

> I have been looking into that over the past couple of weeks, and it seems that
> AVB handles network infrastructure requirements, but does not specify higher
> layer protocol.  So the AVB specification handles clock synchronization,
> stream bandwidth reservation, and VLAN setup, and as far as I can tell so far,
> that is all.

What should be more to it? It creates an environment where you have a
synchronous media clock and a means to transport data. That's all you
need to reliably transport any realtime data that might come. Think of
AVB as a protocol suite, not a protocol itself.

> You still have to have session control to discover end points, discover
> how many channels are offered by the end point, set up connections, define
> the arrangement of audio samples within the packets, etc.

All this is handled by other already existing protocols.

> Ravenna seems that it will become the best choice given the statements
> that it will be published as an open (and I think freely available) standard,
> but it does not seem to be finished yet.  The Ravenna web site contains no
> documentation so far.

There are early-adopter partners to provide a full signal chain from
microphone to speaker, including infrastructure and DAW. You can already
buy Ravenna equipment if you want to start and play with it.

The protocol specs will be released to the public, don't worry. It was
just presented on last year's IBC, give the guys a little time.

> Is there a particular reason you want to make it native in JACK and not
> incorporate it into the ALSA drivers?  I have been considering the same
> question, whether it is better to have a driver native in JACK, or whether it
> would be better to have it independent of JACK so that it could hopefully
> attract developers from the non-JACK audio world as well.  Having an
> interface
> compatible with ALSA would be attractive from that standpoint, because any
> other
> Linux application should be able to use it, and JACK should still be able
> to use it through the ALSA backend.

Sound cards don't tend to change their number of channels all the time,
as do network devices. ALSA is not very good at coping with variable
channel numbers, as any RME user knows. Limiting it to the "I just want
to connect one device!!1" case is not useful.

>> And you are aware that you cannot do AVB without proper hardware support?
> Do you mean because of the IEEE-1588 based clock synchronization?

Yes.

> There are software implementations of 1588, are they not accurate enough to
> meet AVB requirements?

It depends what you want to achieve. If you just want to push out data
and be done, you're ready to go.

> You need switches which understand VLAN tagging and bandwidth reservation
> for quality-of-service.  I don't think the synchronization adds any
> requirements
> to the switches, just the endpoints, but I'm not positive on that yet.

The switches have to support PtP as well, they have to compensate their
processing and transport latencies as well.

>> Ravenna on the other hand...
> Ravenna is just using AVB, as far as I can see from the limited documentation
> that Ravenna has released so far, Ravenna has no requirements beyond AVB.

Ravenna is 'just' another protocol suite that supersets AVB, and has
much stricter requirements, e.g. the phase synchronous media clock and
the timestamping. If you somehow manage to implement this in software on
a general purpose computer, well..

> What is the requirement for time stamping incoming samples?

Very brief: You have to accurately timestamp the moment t_s those
samples are taken (think of an AES word clock). In a Ravenna clock
domain, you specify a system latency t_l, so that you have this time
frame to process and transport your data. Any samples are then output at
t_s+t_l exactly.

> Does that use case still require hardware timestamp capability on the PC, or
> would a software implementation of 1588/802AS meet the requirements?

If you just want to throw data to one device (or receive the data), you
can do it in software alone, sure. In that case all the timestamping
etc. is done in the hardware. Use the PtP clock to derive your media
clock and manage the buffers. For AVB, it is even simpler, as there are
already means for flow control.

> Single clock domain should definitely be handled
> first, and then separate domains can be added as a special case later.

Ravenna requires bit transparency. IOT: No SRC :)

> What might be useful is a way to force JACK to use multiple output devices if
> you know that they are all on the same clock domain, e.g. you have two
> different
> devices which are synchronized with word clock or AES11.  I don't think JACK
> currently allows to use two different devices as output, does it?  You
> have to use some ALSA trickery to make a composite device?

You don't have to. All you need is a simple jack client that speaks RTP
and that transparently bridges Ravenna ports to jack ports and vice
versa: Connect a console and magically all the ports pop up in ardour.

> Torben, can you elaborate on that a bit?  We've gone from Florian saying that
> we need PTP capable hardware, to you saying that we don't even need software
> PTP.

You mix up AVB and Ravenna, and cases where you just input/output data
to/from one device, have a sound interface in your computer or talk to
multiple devices. Make up your mind :)

>> I was thinking of the case where jack operates on a local backend and
>> does SRC on AVB ports, if neccessary.
> That seems to unnecessarily complicate the problem before the first steps are
> even taken.

This would basically be a modified netjack client.

>> If you just produce sound (and do not care about synchronization with
>> other sound sources) or want to store the data, yes.
> So take the case which is probably pretty common on this list: Ardour running
> on a PC with JACK, connected to one device which has some number of ADC and
> DAC used to record and play audio.  What would be needed in that case?  PTP
> hardware?  PTP software?  Neither?

If all input and output is performed on the external device and it has
its own grand master clock, you can do it in software. But this is,
contrary to your premise, a special use case (in the Ravenna context).

You don't need dedicated ADCs/DACs in the long term, just connect the
mic to the network. Same for speakers, consoles, ... In the mean time,
bridges from/to MADI, ADAT, AES will make the migration step easier.

> Are those cases effectively the equivalent of having multiple sound cards in
> one computer, which require an external clock to synchronize the audio clocks
> on the cards?  E.g. outputting to two separate network DAC would require
> synchronization. Would the PC definitely require hardware
> synchronization, or would it suffice to have the two audio devices synchronized?

Any client that generates audio has to timestamp it, and any client that
outputs audio has to do it at the t_s+t_l point in time. The
timestamping has to by synchronous to the grand master clock within the
AES11 specs.

How you do it, is up to you.

And when you did it, let me break it with a VariSpeed setup :)


Flo
--
Machines can do the work, so people have time to think.
public key B3B9226C          x-hkp://wwwkeys.eu.pgp.net
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

torbenh
In reply to this post by Chris Caudle
On Sun, Feb 27, 2011 at 10:17:54PM -0600, Chris Caudle wrote:

> Seems like interest and events are coming together all around.
> Using standard networking hardware to connect audio devices has been
> something
> I have wanted for quite a while, but most solutions were proprietary and
> because
> of that didn't play well in the Linux ecosystem.  NetJack was a notable
> exception, but I just couldn't convince myself that running a jack server
> on my
> ADC was the right way to do it.
>
> Sorry for the length of this, I'm just catching up on several digests.

digests are pretty ugly.
they break the whole mail conversation.

>
> On Fri, February 25, Christoph Kuhr wrote:
> > I want do integrate this standard into jack2.
> > I want to choose AVB (not ALSA or NET) from the driver dropdown box.
>
> Is there a particular reason you want to make it native in JACK and not
> incorporate it into the ALSA drivers?  I have been considering the same
> question, whether it is better to have a driver native in JACK, or whether it
> would be better to have it independent of JACK so that it could hopefully
> attract developers from the non-JACK audio world as well.  Having an
> interface
> compatible with ALSA would be attractive from that standpoint, because any
> other
> Linux application should be able to use it, and JACK should still be able
> to use
> it through the ALSA backend.

i think the correct point would be an alsa plugin.
developing this stuff in userspace, makes it easier to debug.

>
> Florian Faber wrote:
> > And you are aware that you cannot do AVB without proper hardware support?
>
> Do you mean because of the IEEE-1588 based clock synchronization?
> There are software implementations of 1588, are they not accurate enough to
> meet AVB requirements?

there are already ptp patches for linux floating around.
not sure about the status. but i think they are almost ready for
mainline.

> torbenh wrote:
> > so for the case where you want to slave jack to some avb devices,
> > you need to write a backend.
> > this use-case is particularly interesting, because it will work with
> > normal hardware. (it probably doesnt even need a software ptp
> > implementation)
>
> Torben, can you elaborate on that a bit?  We've gone from Florian saying that
> we need PTP capable hardware, to you saying that we don't even need software
> PTP.
> For that to be the case, would you not need some type of feedback signal from
> an output sink (e.g. DAC) to let you know when the output buffers were too
> low
> or too full? Some network equivalent of the interrupt you get from a PCI
> card,
> and the values in the status register that let you know that it needs more
> buffers to DMA.

if the endpoint is a soundcard.
it would be sending an rtp stream from its ADC.
from this stream we could extract the clock.
this is pretty much what netjack does.

that said, if the device only has DACs and cant be made to send an empty
stream. we would need a software ptp.

i was thinking, that there was some facility in rtcp which published
jitter buffer fill level.
this information can be used to adjust the rate at which we are
outputting packets.
but i didnt find it. maybe i confused it with another protocoll.



>
> > but to just output a stream.... no special hardware is needed.
>
> How to you make sure that the DAC buffers do not underrun, or that you do
> not send too much data too closely together and cause overrun?  I'll
> ignore ADC
> for the moment, that seems the easy case as long as your PC is fast
> enough to keep up with the amount of data that the ADC is sending.
>
> Florian Faber wrote:
> > You mean in the case where jack would only operate on AVB streams and
> > not use any local sound interface?
>
> That is the case I find interesting.  A network attached ADC/DAC, either a
> single device, or possible separate devices which may have an external clock
> synchronization, or which both have hardware PTP capability and synchronize
> their internal clocks that way.  Then a standard PC or server (which all have
> Gb capable network interfaces, often more than one) can be connected to that
> device for audio I/O without requiring to spend an additional $1500 on a MADI
> card.  Something just seems odd about spending $1000 on the computer and
> $1500
> on the audio interface card.  I don't mind spending money on good ADC and
> DAC,
> but it doesn't seem right to spend so much money for (relatively) low bit
> rate
> data transfer between the PC and the data source/sink.

yes. this is the most interesting case.

>
> > I was thinking of the case where jack operates on a local backend and
> > does SRC on AVB ports, if neccessary.
>
> That seems to unnecessarily complicate the problem before the first steps are
> even taken.

it not bittransparent either.
and burns cpu.
very uncompelling.


--
torben Hohn
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

Chris Caudle
In reply to this post by Christoph Kuhr
On Mon, February 28, Florian Faber wrote:
> after all, PtP was invented at HP.

I think those guys were already split to Agilent at that point.

> For the price of just one switch with PtP support
> you can already buy a MADI interface.
...
> The switches have to support PtP as well, they have
> to compensate their processing and transport latencies as well.

I was reading the Q-Lan white paper from QSC recently, and they seem to be
using switches with tagged priority support to make the clock packets
traverse the switch as quickly as possible, without relying on switches
which have specific 1588 "transparent clock" ability.  They require 1Gb/s
switches for Q-Lan, which may help with latency.  If you have
quality-of-service support in the switch, couldn't you just have the clock
packets tagged with priority 7, and then use end to end latency
measurement rather than peer to peer?

Perhaps that would work for some protocols, but not meet the tight
requirements of Ravenna.  I'll have to look to see if anyone has made
accuracy and jitter measurements of systems without transparent clock
support in the switch.

>> AVB handles...infrastructure requirements, but does
>> not specify higher layer protocol.

> What should be more to it?

I was speaking in the context of the original message, which proposed
creating an AVB back end for Jack2.  Is it accurate to call that an AVB
backend, or would you also have to specify which higher layer protocols
are implemented?  It seems that you could have a backend for Dante, for
Q-Lan, for Lightwire, for Ravenna, and all those would be AVB compatible.
That was all I meant, that the original question posed was not really
complete without also specifying some additional requirements in addition
to AVB compliant.

> Sound cards don't tend to change their number of channels all
> the time, as do network devices.

OK, I can see that as a good argument for making native network device to
JACK port bridges.

Is the task (of writing a new network interface bridge for JACK) of a size
that only a few people working on it will be able to keep it maintained?
Netjack is one thing, it only has to work with other jack instances, but
one or two people could not keep up with the number of drivers in ALSA.  I
hope that with more standardization, the network driver support will have
much less difference between different vendors implementation than all the
different ALSA drivers.  That was my primary concern with a JACK-only
implementation vs. making it ALSA compatible, since only limited
applications support JACK currently, likely there would be fewer
developers willing to work on a JACK only implementation compared to
something which will work more generally.

> You don't have to. All you need is a simple jack client that
> speaks  RTP and that transparently bridges Ravenna ports to
> jack ports and vice versa: Connect a console and magically
> all the ports pop up in ardour.

Yes, that sounds like the ideal case.  Is there a way to quantify "simple"
client?  How much work would that entail, and what kernel or userspace
support is assumed?

> You mix up AVB and Ravenna, and cases where you just
> input/output data to/from one device, have a sound interface
> in your computer or talk to multiple devices. Make up your mind :)

Partly I was mixing up AVB and Ravenna, but partly the problem is because
three different people were writing, and I think each of us has different
ideas about what is required as a minimum, and what is desired beyond that
minimum.

> If all input and output is performed on the external device
> and it has its own grand master clock, you can do it in software.

OK, that is a starting point then.

> But this is, contrary to your premise, a special use case
> (in the Ravenna context).

Yes, I understand, but hopefully Ravenna can scale down to this type of
small configuration gracefully.

--
Chris Caudle






_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

Duncan Gray-2
In reply to this post by Chris Caudle
I sat on the IEEE1788 standards committee when we were working on the
timing portion of the spec and the beginning of the zeroconf-like
discovery protocols.

To implement AVB, the intention (as far as Jack would be concerned)
would be to get a NIC card that will most definitely implement the
timing protocol. A consumer app that only does streaming is the "killer
app"; and that was the only concern of Broadcom and Marvell -- who were
major participants. This does not concern itself with latency, but
rather with delivery. These apps stream with virtual timing from disk.
Then the reproduce to iPods that will recover timing as cheaply as
possible to achieve robust buffering with fairly low jitter playback.

The anticipated audio app (consumer or pro) is that a VERY SPECIAL Audio
NIC would be created that would buffer the stream and present it to the
hardware with a strict-timed interrupt and look like an audio card. That
card has an analog Phase-Locked-Loop controlled by the AVB (which is a
derivative of IEEE 1588) and the timing information in the stream
control of IEEE 1788.

Such NICs will become available on a very long schedule, and a company
called Lab-X can point you to vendors leading the way. Perhaps someone
from the Jack core crew should speak to Lee Minich at Lab-X about a push
to open some for driver work. There is also an industry alliance for
AVB, AVnu (Akin to the dreaded Firewire industry alliance.)

Lee is [hidden email] and is open to such contact,
especially given the traction that Jack has.

AVnu is at www.avnu.com


ALSA is NOT up to the control of these ports IMHO.

Regards

Duncan Gray


On 02/27/2011 10:17 PM, Chris Caudle wrote:

> Seems like interest and events are coming together all around.
> Using standard networking hardware to connect audio devices has been
> something
> I have wanted for quite a while, but most solutions were proprietary and
> because
> of that didn't play well in the Linux ecosystem.  NetJack was a notable
> exception, but I just couldn't convince myself that running a jack server
> on my
> ADC was the right way to do it.
>
> Sorry for the length of this, I'm just catching up on several digests.
>
> On Fri, February 25, Christoph Kuhr wrote:
>   Message-ID:<[hidden email]
>> There is a new network standard comming up specialized for audio and
>> video transmission, called AVB (Audio Video Bridging ->  IEEE 802.1AS,
>> 802.1Qat, 802.1Qav,...).
> I have been looking into that over the past couple of weeks, and it seems
> that
> AVB handles network infrastructure requirements, but does not specify higher
> layer protocol.  So the AVB specification handles clock synchronization,
> stream
> bandwidth reservation, and VLAN setup, and as far as I can tell so far,
> that is
> all.  You still have to have session control to discover end points, discover
> how many channels are offered by the end point, set up connections, define
> the
> arrangement of audio samples within the packets, etc.
>
> The proprietary methods cover all those other aspects.  The ones which
> seem to
> lend themselves most readily to software implementation (i.e. should not
> require
> custom hardware on the computer end) seem to be Dante from Audinate and
> Livewire from Axia.  Both are proprietary and not publicly documented.
> Ravenna seems that it will become the best choice given the statements
> that it
> will be published as an open (and I think freely available) standard, but it
> does not seem to be finished yet.  The Ravenna web site contains no
> documentation so far.
>
>> I want do integrate this standard into jack2.
>> I want to choose AVB (not ALSA or NET) from the driver dropdown box.
> Is there a particular reason you want to make it native in JACK and not
> incorporate it into the ALSA drivers?  I have been considering the same
> question, whether it is better to have a driver native in JACK, or whether it
> would be better to have it independent of JACK so that it could hopefully
> attract developers from the non-JACK audio world as well.  Having an
> interface
> compatible with ALSA would be attractive from that standpoint, because any
> other
> Linux application should be able to use it, and JACK should still be able
> to use
> it through the ALSA backend.
>
> Florian Faber wrote:
>> And you are aware that you cannot do AVB without proper hardware support?
> Do you mean because of the IEEE-1588 based clock synchronization?
> There are software implementations of 1588, are they not accurate enough to
> meet AVB requirements?
>
> Arnold Krille wrote:
>> I started with making normal clients for sending and receiving rtp.
> Have you only sent data, or also handled querying for number of channels
> offered, other things required to get general clients connected?  Or just
> simple test applications which always have fixed channels?
>
> Christoph Kuhr wrote:
>> since there is the PTPv2 sw implementation
>> (http://www.bartky.net/products.htm), the endpoint requirements of avb
>> are met by most computer hardware
> Have you looked at the PTP implementation with BSD style license?
> http://ptpd.sourceforge.net/
>
> Adrian Knoth wrote:
>> To my knowledge, there are only thee NICs available which make sense to
>> be used with PTP
> You can use a software time stamping implementation, but with less accuracy
> and much higher jitter.   So depending on the requirements you may need a
> specialized NIC or you may not.  There will be more available soon, I think
> Broadcom and Marvell are working on some.
>
> Arnold Krille wrote:
>> I have to admit that I haven't looked at the avb-standard-definition yet.
>> But so far I was under the impression that avb is aimed at
>> home-entertainment and the likes
> It started out aimed at home entertainment, but expanded to also include
> professional audio and automotive networking.
>
>> and thus neither needs special switches
>> nor special nics.
> You need switches which understand VLAN tagging and bandwidth reservation
> for quality-of-service.  I don't think the synchronization adds any
> requirements
> to the switches, just the endpoints, but I'm not positive on that yet.
>
>> Ravenna on the other hand...
> Ravenna is just using AVB, as far as I can see from the limited documentation
> that Ravenna has released so far, Ravenna has no requirements beyond AVB.
>
>
> Florian Faber wrote:
>> If you want to provide physical inputs or outputs for Ravenna on your
>> machine, there's nothing you can do without special hardware - for the
>> moment.
> Has any documentation on the Ravenna protocol been released publicly yet?
>
>> You have to produce a phase synchronous clock, synced via PtP,
>> and provide a means to timestamp incoming samples and output samples at
>> the correct point in time.
> What is the requirement for time stamping incoming samples?
>
> This is the view point from which I ask the question:  I see the
> interesting use
> of networked audio as an inexpensive way to get multiple channels of remote
> audio into or out of a standard PC without a rather expensive card capable of
> MADI or multiple AES3 channels, and in that case the master clock should
> be in
> the ADC or DAC, so the PC only has to send the incoming packets to hard
> drive,
> or send outgoing packets at close enough to the correct time that the DAC
> buffer
> does not have an over or under run.
>
> Does that use case still require hardware timestamp capability on the PC, or
> would a software implementation of 1588/802AS meet the requirements?
>
> Arnold Krille<[hidden email]
>> I don't want to be fixed exclusively on the network-peers, I want to use
>> my internal sounddevices to play that sound too.
> That should definitely be a separate use case.  Use of independent clock
> domains
> is always a pain, and requires SRC to reconcile all the audio to a single
> clock
> domain at some point.  Single clock domain should definitely be handled
> first,
> and then separate domains can be added as a special case later.
>
> What might be useful is a way to force JACK to use multiple output devices if
> you know that they are all on the same clock domain, e.g. you have two
> different
> devices which are synchronized with word clock or AES11.  I don't think JACK
> currently allows to use two different devices as output, does it?  You
> have to
> use some ALSA trickery to make a composite device?
>
> torbenh wrote:
>> so for the case where you want to slave jack to some avb devices,
>> you need to write a backend.
>> this use-case is particularly interesting, because it will work with
>> normal hardware. (it probably doesnt even need a software ptp
>> implementation)
> Torben, can you elaborate on that a bit?  We've gone from Florian saying that
> we need PTP capable hardware, to you saying that we don't even need software
> PTP.
> For that to be the case, would you not need some type of feedback signal from
> an output sink (e.g. DAC) to let you know when the output buffers were too
> low
> or too full? Some network equivalent of the interrupt you get from a PCI
> card,
> and the values in the status register that let you know that it needs more
> buffers to DMA.
>
>> but to just output a stream.... no special hardware is needed.
> How to you make sure that the DAC buffers do not underrun, or that you do
> not send too much data too closely together and cause overrun?  I'll
> ignore ADC
> for the moment, that seems the easy case as long as your PC is fast
> enough to keep up with the amount of data that the ADC is sending.
>
> Florian Faber wrote:
>> You mean in the case where jack would only operate on AVB streams and
>> not use any local sound interface?
> That is the case I find interesting.  A network attached ADC/DAC, either a
> single device, or possible separate devices which may have an external clock
> synchronization, or which both have hardware PTP capability and synchronize
> their internal clocks that way.  Then a standard PC or server (which all have
> Gb capable network interfaces, often more than one) can be connected to that
> device for audio I/O without requiring to spend an additional $1500 on a MADI
> card.  Something just seems odd about spending $1000 on the computer and
> $1500
> on the audio interface card.  I don't mind spending money on good ADC and
> DAC,
> but it doesn't seem right to spend so much money for (relatively) low bit
> rate
> data transfer between the PC and the data source/sink.
>
>> I was thinking of the case where jack operates on a local backend and
>> does SRC on AVB ports, if neccessary.
> That seems to unnecessarily complicate the problem before the first steps are
> even taken.
>
>> It is not I who wants it, it is the spec that demand a phase synchronous
>> clock that matches AES criteria, and bit transparency, amongst other
>> things.
> Is the spec available yet?  I only discovered Ravenna very recently, and
> currently on the web site it says that "RAVENNA will be an open technology
> standard without a proprietary licensing policy."  Future tense "will be,"
> not
> current tense "is" an open standard.
>
>>> but to just output a stream.... no special hardware is needed.
>> If you just produce sound (and do not care about synchronization with
>> other sound sources) or want to store the data, yes.
> So take the case which is probably pretty common on this list: Ardour running
> on a PC with JACK, connected to one device which has some number of ADC and
> DAC used to record and play audio.  What would be needed in that case?  PTP
> hardware?  PTP software?  Neither?
>
>> In any other case you need a means of hardware synchronization.
> Could you describe the cases which would definitely require hardware synch?
> Are those cases effectively the equivalent of having multiple sound cards in
> one computer, which require an external clock to synchronize the audio clocks
> on the cards?  E.g. outputting to two separate network DAC would require
> synchronization.  Would the PC definitely require hardware
> synchronization, or
> would it suffice to have the two audio devices synchronized?
>
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

Paul Davis
On Mon, Feb 28, 2011 at 8:59 PM, Duncan Gray <[hidden email]> wrote:

  [ ... good stuff ... ]


> ALSA is NOT up to the control of these ports IMHO.

for various reasons, i ended up implementing an ALSA userspace driver
("PCM Plugin") in january as part of a short term contract job. i can
assure you that ALSA is entirely capable of doing this, and it can all
be done in user space assuming there is working stack to build on.
this seems to me to be the main source of concern, because the
situation with (e.g.) firewire for audio has, from my rather remote
perspective, been nothing but a nightmare for all concerned.  i can
see reasons to believe that AVB/Ravenna could be different, but can
also imagine it turning in much the same way: multiple implementations
for the kernel side, with all the faffing around that this then
triggers higher up the stack.

--p
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

torbenh
In reply to this post by Duncan Gray-2
On Mon, Feb 28, 2011 at 07:59:01PM -0600, Duncan Gray wrote:

> I sat on the IEEE1788 standards committee when we were working on
> the timing portion of the spec and the beginning of the
> zeroconf-like discovery protocols.
>
> To implement AVB, the intention (as far as Jack would be concerned)
> would be to get a NIC card that will most definitely implement the
> timing protocol. A consumer app that only does streaming is the
> "killer app"; and that was the only concern of Broadcom and Marvell
> -- who were major participants. This does not concern itself with
> latency, but rather with delivery. These apps stream with virtual
> timing from disk. Then the reproduce to iPods that will recover
> timing as cheaply as possible to achieve robust buffering with
> fairly low jitter playback.

i dont really understand this.
you mean streaming from harddisk to multiple endpoints,
all playing phase synced ?

with soundcards that generate their own clocks, and dont allow for rate
control ?

if one allows 3ms of diff, we can do this with netjack for quite some
time. 3ms is not relevant for comsumer applications imo.

if the soundcard allow software to gradually adjust the clock, we could
do this without resampling.
the problems start when there is packet loss and high jitter.
(such as an internet connection over the atlantic or somthing, here it
gets interesting.)


>
> The anticipated audio app (consumer or pro) is that a VERY SPECIAL
> Audio NIC would be created that would buffer the stream and present
> it to the hardware with a strict-timed interrupt and look like an
> audio card. That card has an analog Phase-Locked-Loop controlled by
> the AVB (which is a derivative of IEEE 1588) and the timing
> information in the stream control of IEEE 1788.

you mean an audio nic in a computer ?
or in the embedded audio soundcard ?

>
> Such NICs will become available on a very long schedule, and a
> company called Lab-X can point you to vendors leading the way.
> Perhaps someone from the Jack core crew should speak to Lee Minich
> at Lab-X about a push to open some for driver work. There is also an
> industry alliance for AVB, AVnu (Akin to the dreaded Firewire
> industry alliance.)

well... there seems to be some silicon out there....
ptp patches seem to be ready for mainlining. and will probably hit the
tip tree soon.
http://www.spinics.net/lists/arm-kernel/msg116310.html

with a reasonably good ptp timer in the kernel.
this is all easy stuff.


--
torben Hohn
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

Adrian Knoth
On Tue, Mar 01, 2011 at 04:45:48AM +0100, torbenh wrote:

Hi!

> the problems start when there is packet loss and high jitter.
> (such as an internet connection over the atlantic or somthing, here it
> gets interesting.)

Don't get me wrong, but may I, for once, question this assumption?
I know there are some remote jamming tools available, but I don't know a
single musician using them.

Given the inherent latency on the WAN, there's no real "together"
anyway, so the whole thing degrades to simple asynchronous streaming.
(read: icecast or whatsoever)

If you know a sane use case where one needs a distributed synchronous
transatlantic setup, then I'll stand corrected, but within this
AVB/Ravenna discussion, let's talk LAN and only LAN.



Cheers

--
mail: [hidden email]   http://adi.thur.de        PGP/GPG: key via keyserver
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

torbenh
On Tue, Mar 01, 2011 at 10:24:07AM +0100, Adrian Knoth wrote:

> On Tue, Mar 01, 2011 at 04:45:48AM +0100, torbenh wrote:
>
> Hi!
>
> > the problems start when there is packet loss and high jitter.
> > (such as an internet connection over the atlantic or somthing, here it
> > gets interesting.)
>
> Don't get me wrong, but may I, for once, question this assumption?
> I know there are some remote jamming tools available, but I don't know a
> single musician using them.
>
> Given the inherent latency on the WAN, there's no real "together"
> anyway, so the whole thing degrades to simple asynchronous streaming.
> (read: icecast or whatsoever)

thanks for a demotivating me.

>
> If you know a sane use case where one needs a distributed synchronous
> transatlantic setup, then I'll stand corrected, but within this
> AVB/Ravenna discussion, let's talk LAN and only LAN.

you deleted the part about LAN.
tip:core/timers is already carrying code for in kernel ptp clocks.

there are patches for IXP46x, National Semiconductor PHYTER and MPC85xx
that build up on this.

as i see it... we could make a 10lines patch to the dummy device,
and have jack synced to a ptp clock.

then you just need a non-resampling rtp streamer.


--
torben Hohn
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

Adrian Knoth
On 03/01/11 13:35, torbenh wrote:

> as i see it... we could make a 10lines patch to the dummy device,
> and have jack synced to a ptp clock.
>
> then you just need a non-resampling rtp streamer.

And that's exactly how I've sketched the whole thing last night. Go for
it. ;)


Cheers
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

torbenh
On Tue, Mar 01, 2011 at 01:42:00PM +0100, Adrian Knoth wrote:
> On 03/01/11 13:35, torbenh wrote:
>
> > as i see it... we could make a 10lines patch to the dummy device,
> > and have jack synced to a ptp clock.
> >
> > then you just need a non-resampling rtp streamer.
>
> And that's exactly how I've sketched the whole thing last night. Go for
> it. ;)

you sketched it differently.
iE using SIOCGHWTSTAMP and stuff.

i am currently investigating how to implement a software clock.
not sure how much of this stuff we want inside the kernel.

i didnt find the right tree to apply the 3 ptp drivers on,
i need to sort that first.


>
>
> Cheers
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

--
torben Hohn
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

Fernando Lopez-Lezcano
In reply to this post by Adrian Knoth
On 03/01/2011 01:24 AM, Adrian Knoth wrote:

> On Tue, Mar 01, 2011 at 04:45:48AM +0100, torbenh wrote:
>
> Hi!
>
>> the problems start when there is packet loss and high jitter.
>> (such as an internet connection over the atlantic or somthing, here it
>> gets interesting.)
>
> Don't get me wrong, but may I, for once, question this assumption?
> I know there are some remote jamming tools available, but I don't know a
> single musician using them.

https://ccrma.stanford.edu/groups/soundwire/

https://ccrma.stanford.edu/groups/soundwire/music/

(the music part is not up to date, I think).

Jacktrip is used regularly for remote concerts or jam sessions with two
or more remote locations at the same time. Depending on the remoteness
of the other side of the "studio" jamming can be interesting :-) Of
course in those cases you make music that can be played together without
a fast lockstep beat to it...

> Given the inherent latency on the WAN, there's no real "together"
> anyway, so the whole thing degrades to simple asynchronous streaming.
> (read: icecast or whatsoever)
>
> If you know a sane use case where one needs a distributed synchronous
> transatlantic setup, then I'll stand corrected, but within this
> AVB/Ravenna discussion, let's talk LAN and only LAN.

Hmmm, I guess we are not sane, so we may not count...
:-)
-- Fernando
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

Paul Davis
On Tue, Mar 1, 2011 at 2:23 PM, Fernando Lopez-Lezcano
<[hidden email]> wrote:

> Jacktrip is used regularly for remote concerts or jam sessions with two or
> more remote locations at the same time. Depending on the remoteness of the
> other side of the "studio" jamming can be interesting :-) Of course in those
> cases you make music that can be played together without a fast lockstep
> beat to it...

not only that, but both netjack and soundjack
(http://www.soundjack.eu/) *have* been used across WAN's (though not
the Atlantic) for live distributed performances (with a "fast lockstep
beat" to it). so i think its wrong to claim that:

>> Given the inherent latency on the WAN, there's no real "together"
>> anyway, so the whole thing degrades to simple asynchronous streaming.
>> (read: icecast or whatsoever)

--p
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

Arnold Krille-3
In reply to this post by torbenh
On Tuesday 01 March 2011 04:45:48 torbenh wrote:

> On Mon, Feb 28, 2011 at 07:59:01PM -0600, Duncan Gray wrote:
> > To implement AVB, the intention (as far as Jack would be concerned)
> > would be to get a NIC card that will most definitely implement the
> > timing protocol. A consumer app that only does streaming is the
> > "killer app"; and that was the only concern of Broadcom and Marvell
> > -- who were major participants. This does not concern itself with
> > latency, but rather with delivery. These apps stream with virtual
> > timing from disk. Then the reproduce to iPods that will recover
> > timing as cheaply as possible to achieve robust buffering with
> > fairly low jitter playback.
> i dont really understand this.
> you mean streaming from harddisk to multiple endpoints,
> all playing phase synced ?
Phase synced samples is a requirement for AES and thus Ravenna, not for
general avb.

Have fun,

Arnold

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

Adrian Knoth
In reply to this post by Paul Davis
On Tue, Mar 01, 2011 at 02:34:27PM -0500, Paul Davis wrote:

> > Jacktrip is used regularly for remote concerts or jam sessions with two or
> > more remote locations at the same time. Depending on the remoteness of the
>
> not only that, but both netjack and soundjack
> (http://www.soundjack.eu/) *have* been used across WAN's (though not
> the Atlantic) for live distributed performances (with a "fast lockstep
> beat" to it).

Firstly, I don't see why adding some AVB functionality should replace
any of those tools (netjack/soundjack). To me, these are completely
different use cases with some overlapping cases.

One thing is to stream some audio at high latency of 50ms or whatsoever,
the other thing is to derive media clocks from a global network clock on
a LAN.

For this, just to answer one comment by Torben, it doesn't actually
matter whether the kernel or ptpd is asking for HW timestamping. (just
to avoid the impression I was ever implying jackd, a jack client or the
backend should do PTP itself)

Anyway, I still don't see that any of these remote jam sessions require
*synchronous* operations (as in "one clock domain"). It's multichannel
UDP streaming with fast capture and playback on both ends, some SRC and
that's it. From your comments, netjack seems to serve this use case
well, and that's fine.


I wonder what we're discussing at all? Ah, right, me asking if remote
jam sessions do exist. Obviously. Is it common? I don't think so. Might
change once we all have <30ms RTT home to home, and not just university
to university. I have <2ms to a nearby (~60km) university, and I believe
netjack could make sense in this scenario. Plenty of bandwidth, low
latency, probably not much jitter.


Cheers

--
mail: [hidden email]   http://adi.thur.de        PGP/GPG: key via keyserver
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

Duncan Gray-2
In reply to this post by torbenh


On 02/28/2011 09:45 PM, torbenh wrote:

> On Mon, Feb 28, 2011 at 07:59:01PM -0600, Duncan Gray wrote:
>> I sat on the IEEE1788 standards committee when we were working on
>> the timing portion of the spec and the beginning of the
>> zeroconf-like discovery protocols.
>>
>> To implement AVB, the intention (as far as Jack would be concerned)
>> would be to get a NIC card that will most definitely implement the
>> timing protocol. A consumer app that only does streaming is the
>> "killer app"; and that was the only concern of Broadcom and Marvell
>> -- who were major participants. This does not concern itself with
>> latency, but rather with delivery. These apps stream with virtual
>> timing from disk. Then the reproduce to iPods that will recover
>> timing as cheaply as possible to achieve robust buffering with
>> fairly low jitter playback.
> i dont really understand this.
> you mean streaming from harddisk to multiple endpoints,
> all playing phase synced ?
Yes
> with soundcards that generate their own clocks, and dont allow for rate
> control ?
No. ... SRC would be needed for these
> if one allows 3ms of diff, we can do this with netjack for quite some
> time. 3ms is not relevant for comsumer applications imo.
3 ms of difference is not a rate difference, only time difference. Time
difference grows unbounded for a frequency difference between the source
and the sink. There will be a jitter buffer xrun at a periodic rate for
that situation.
> if the soundcard allow software to gradually adjust the clock, we could
> do this without resampling.
> the problems start when there is packet loss and high jitter.
> (such as an internet connection over the atlantic or somthing, here it
> gets interesting.)
I didn't know that there were sound cards that allow fine-set frequency
control to allow implementation of a good low-jitter PLL.

>
>> The anticipated audio app (consumer or pro) is that a VERY SPECIAL
>> Audio NIC would be created that would buffer the stream and present
>> it to the hardware with a strict-timed interrupt and look like an
>> audio card. That card has an analog Phase-Locked-Loop controlled by
>> the AVB (which is a derivative of IEEE 1588) and the timing
>> information in the stream control of IEEE 1788.
> you mean an audio nic in a computer ?
> or in the embedded audio soundcard ?
>
Can be done either way. The anticipated case would be a NIC that has an
appearance that looks like a sound card. Otherwise, (conceptually, not
designed AFAIK) the timestamped 1788 packets could be sent to a
soundcard to implement PTP's PLL.

>> Such NICs will become available on a very long schedule, and a
>> company called Lab-X can point you to vendors leading the way.
>> Perhaps someone from the Jack core crew should speak to Lee Minich
>> at Lab-X about a push to open some for driver work. There is also an
>> industry alliance for AVB, AVnu (Akin to the dreaded Firewire
>> industry alliance.)
> well... there seems to be some silicon out there....
> ptp patches seem to be ready for mainlining. and will probably hit the
> tip tree soon.
> http://www.spinics.net/lists/arm-kernel/msg116310.html
>
> with a reasonably good ptp timer in the kernel.
> this is all easy stuff.
>
REALLY GLAD to see that the PHYTER has made it into the source tree. I
am amazed that it has gone this quickly.

Kernel PLLs, however, will have lots of jitter. Once again, consumer
will be OK (maybe some surging and low-freq noise like USB externals I
know.) The adaption from a PTP aware PHY to allow paced pay-out of
packets to D/As or to allow a D/A to drive the PTP as a master is
brilliant. Without a PLL-able sound card, though, SRC must be done the
hard way, in software.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
123