Re: [Jack-Devel] Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

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] 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]
>> 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]
>> 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?
>

1298944777.8229_0.ltw:2,a <4D6C52E5.20909 at catraeus dot com>