Re: Jack-Devel Digest, Vol 56, Issue 47

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

Re: Jack-Devel Digest, Vol 56, Issue 47

Christoph Kuhr
Hi,
And you are aware that you cannot do AVB without proper hardware support?
First i want to build a direct (crossover) connected test system.
Ubuntu Studio rt interconnected with Xilinx Spartan 3AN with AVB IP.
therefore i dont need a avb ready switch at the moment.
since there is the PTPv2 sw implementation (http://www.bartky.net/products.htm), the endpoint requirements of avb are met by most computer hardware, but requires extensive network kernel module modification.

I started with making normal clients for sending and receiving rtp. Extension 
to the other standards and extension into a backend follows later.
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).
Yeah, thats the way i want to do it too. but because of the preperation and scheduling for this project, first i want to make the backend, then rtp implementation and then kernel module modification.

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

St?phane

thank you!

_______________________________________________
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: Jack-Devel Digest, Vol 56, Issue 47

Adrian Knoth
On Sat, Feb 26, 2011 at 09:41:52AM +0100, 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, but requires extensive network kernel  
> module modification.

Hmm, not sure if I entirely understand what you mean here, but last time
I had a look at PTP, I found at least three different versions with
different features.

To my knowledge, there are only thee NICs available which make sense to
be used with PTP: some embedded blackfin, gianfar and the Intel 82576
chips. All those support hardware timestamping, and support for it is
already in the kernel (since 2.6.32, iirc)

The ioctl in question is SIOCSHWTSTAMP, see
Documentation/networking/timestamping.txt in the Linux kernel.

IIRC, there is PTPv1 with SIOCSHWTSTAMP support and no PTPv2-HW except
the bartky freescale thing, but that's tailored to a special embedded
device and not using the common ioctl.

Given that there is no clear PTP upstream, one should first start to
merge all these three implementations and mabye forward-port the
SIOCSHWTSTAMP implementation from PTPv1 to PTPv2 or modify bartky's
v2-implementation to SIOCSHWTSTAMP (given that bartky is using a sane
license, haven't checked that)


So to me, I don't see the need for extensive network kernel module
modifcations, because everything is either already there or won't work
at all, because HW-timestamping needs to be supported physically in the
NIC, and there are only three (grep -R for SIOCSHWTSTAMP in
drivers/net).


I'm also touching this field a bit at the moment, so if you like, it
might make sense to coordinate our work, maybe even with Arnold and/or
Florian who has probably the most experience in this area.


I'll hopefully get my Intel NICs in early March, so I can provide you
with a remote login if you want to work with PTPv2 capable hardware.



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: Jack-Devel Digest, Vol 56, Issue 47

Arnold Krille-3
On Saturday 26 February 2011 13:43:41 Adrian Knoth wrote:
> I'm also touching this field a bit at the moment, so if you like, it
> might make sense to coordinate our work, maybe even with Arnold and/or
> Florian who has probably the most experience in this area.

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 and thus neither needs special switches nor special nics.
Ravenna on the other hand...

I would propose to start with rtp-streaming compatible to what avb defines,
keeping the need for hardware-timestamping in mind and just use the available
clocks for timestamping for now. So that we get a working implementation which
can be extended to full avb standard and later on to the full ravenna
standard.
Altough ravenna is aimed at the broadcasting world, the fact that I am not the
only one dreaming about jack doing avb and the likes shows me that if it
works, its also a viable solution for the semi-professional and live-
professional usage...

Anyway, I think we should start this. Maybe with a public repository
somewhere. (I would love to participate in this.)

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: Jack-Devel Digest, Vol 56, Issue 47

Adrian Knoth
On Sat, Feb 26, 2011 at 07:09:15PM +0100, Arnold Krille wrote:

> > I'm also touching this field a bit at the moment, so if you like, it
> > might make sense to coordinate our work, maybe even with Arnold and/or
> > Florian who has probably the most experience in this area.
> I have to admit that I haven't looked at the avb-standard-definition yet.

Me neither, at least not fully. I've seen some slides, but never read
the standard.

> But so far I was under the impression that avb is aimed at
> home-entertainment and the likes and thus neither needs special
> switches nor special nics.

With regard to ptpd, one could still rely on software in-kernel
timestamping, so there's no hard requirement for special NICs.


> Anyway, I think we should start this. Maybe with a public repository
> somewhere. (I would love to participate in this.)

ACK. I guess a branch in Torben's jack git would make sense. (or in
another repo tracking this one)




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: Jack-Devel Digest, Vol 56, Issue 47

Arnold Krille-3
On Saturday 26 February 2011 19:45:25 Adrian Knoth wrote:
> On Sat, Feb 26, 2011 at 07:09:15PM +0100, Arnold Krille wrote:
> > Anyway, I think we should start this. Maybe with a public repository
> > somewhere. (I would love to participate in this.)
> ACK. I guess a branch in Torben's jack git would make sense. (or in
> another repo tracking this one)

/me is to dumb for git...

But afaik git has the advantage that one can move whole development branches
including history from one server to the other. So we could also start on
github or something and get it completely included in a more mainline jack-
repository without loosing historic commits like "it works!" or "Initial
commit"...

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: Jack-Devel Digest, Vol 56, Issue 47

Florian Faber-2
On 02/26/2011 09:16 PM, Arnold Krille wrote:

> But afaik git has the advantage that one can move whole development branches
> including history from one server to the other. So we could also start on
> github or something and get it completely included in a more mainline jack-
> repository without loosing historic commits like "it works!" or "Initial
> commit"...

I believe you guys see it with from the wrong perspective. I don't see
AVB support in jack as a backend, but as a simple bridge from AVB ports
to jack ports.  This can be achieved by simple stand-alone tools, much
like netjack.

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. 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.


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: Jack-Devel Digest, Vol 56, Issue 47

Arnold Krille-3
On Saturday 26 February 2011 21:29:55 Florian Faber wrote:

> On 02/26/2011 09:16 PM, Arnold Krille wrote:
> > But afaik git has the advantage that one can move whole development
> > branches including history from one server to the other. So we could
> > also start on github or something and get it completely included in a
> > more mainline jack- repository without loosing historic commits like "it
> > works!" or "Initial commit"...
>
> I believe you guys see it with from the wrong perspective. I don't see
> AVB support in jack as a backend, but as a simple bridge from AVB ports
> to jack ports.  This can be achieved by simple stand-alone tools, much
> like netjack.
No, I still see my vision of backends as "simple yet extended" clients. But
clients are definitely the way to go. I don't want to be fixed exclusively on
the network-peers, I want to use my internal sounddevices to play that sound
too.

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: Jack-Devel Digest, Vol 56, Issue 47

torbenh
In reply to this post by Arnold Krille-3
On Sat, Feb 26, 2011 at 09:16:25PM +0100, Arnold Krille wrote:

> On Saturday 26 February 2011 19:45:25 Adrian Knoth wrote:
> > On Sat, Feb 26, 2011 at 07:09:15PM +0100, Arnold Krille wrote:
> > > Anyway, I think we should start this. Maybe with a public repository
> > > somewhere. (I would love to participate in this.)
> > ACK. I guess a branch in Torben's jack git would make sense. (or in
> > another repo tracking this one)
>
> /me is to dumb for git...
>
> But afaik git has the advantage that one can move whole development branches
> including history from one server to the other. So we could also start on
> github or something and get it completely included in a more mainline jack-
> repository without loosing historic commits like "it works!" or "Initial
> commit"...

yes. please make your own git repo. i am currently having problems with
my server. pushing and merging git repos around is trivial.

however. i will not support merging commits like "it works"
commits should have adequate messages of what they do.
and having the whole history of failures around in the jack1 svn is not
really optimal.

but i will merge stuff quickly into tschack.



--
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: Jack-Devel Digest, Vol 56, Issue 47

torbenh
In reply to this post by Florian Faber-2
On Sat, Feb 26, 2011 at 09:29:55PM +0100, Florian Faber wrote:

> On 02/26/2011 09:16 PM, Arnold Krille wrote:
>
> > But afaik git has the advantage that one can move whole development branches
> > including history from one server to the other. So we could also start on
> > github or something and get it completely included in a more mainline jack-
> > repository without loosing historic commits like "it works!" or "Initial
> > commit"...
>
> I believe you guys see it with from the wrong perspective. I don't see
> AVB support in jack as a backend, but as a simple bridge from AVB ports
> to jack ports.  This can be achieved by simple stand-alone tools, much
> like netjack.

netjack also has a backend.
if you want to slave jack to some external clock, you need to write a
backend.

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)

>
> 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. 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.

this doesnt seem to be true.
sure... if you want different output device clocks to be correlated,
then you need an accurate ptp clock.

but to just output a stream.... no special hardware is needed.
clock extraction out of streams becomes harder with higher jitter.
so with an exact ptp clock, things are dead easy.

netjack1 is pretty good with extracting a clock from a WAN stream.


--
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: Jack-Devel Digest, Vol 56, Issue 47

Florian Faber-2
Torben!

>> I believe you guys see it with from the wrong perspective. I don't see
>> AVB support in jack as a backend, but as a simple bridge from AVB ports
>> to jack ports.  This can be achieved by simple stand-alone tools, much
>> like netjack.
> netjack also has a backend.
> if you want to slave jack to some external clock, you need to write a
> backend.

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

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

>> 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. 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.
> this doesnt seem to be true.
> sure... if you want different output device clocks to be correlated,
> then you need an accurate ptp clock.

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.

> 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. In any other case
you need a means of hardware synchronization.

> clock extraction out of streams becomes harder with higher jitter.
> so with an exact ptp clock, things are dead easy.

Just a bit of housekeeping.


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