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

PrevNext  Index
DateMon, 28 Feb 2011 11:42:42 +0100
From torbenh <[hidden] at gmx dot de>
ToChris Caudle <[hidden] at chriscaudle dot org>
Cc[hidden] at lists dot jackaudio dot org
In-Reply-ToChris Caudle Re: [Jack-Devel] Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2
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
PrevNext  Index

1298889781.11712_0.ltw:2,a <20110228104242.GD2977 at siel dot b>