[Jack-Devel] AVB Backend

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

[Jack-Devel] AVB Backend

Christoph Kuhr
Hi *,

I wanted to start a discussion of what kind of AVB connectivity makes the most sense for jack.
But please keep in mind what AVB is and isn't.

a) Fully functional Backend
b) Media Clock Backend with AVB jack clients

pro a)
- the AVDECC connection management could be done seamlessly in a jack way
- out of the box avb functionality

con a)
- only one talker/listener, single audio interface
- huge programming effort
- no dynamic audio mapping


pro b)
- multiple talkers/listeners with multiple audio interface using alsa api
- avoiding huge code addition to the backend, thus much easier to maintain
- AVDECC handling per client for dynamic audio mapping

con b)
- cpu load... price for multiple talkers/listeners


I'm excited to hear your opinions!

Best,
Ck
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
_______________________________________________
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: AVB Backend

Christoph Kuhr
pro b)
- A discovery factory can spawn avb listener jack clients for each talker on the network

Am 11. April 2019 22:44:06 MESZ schrieb Christoph Kuhr <[hidden email]>:
Hi *,

I wanted to start a discussion of what kind of AVB connectivity makes the most sense for jack.
But please keep in mind what AVB is and isn't.

a) Fully functional Backend
b) Media Clock Backend with AVB jack clients

pro a)
- the AVDECC connection management could be done seamlessly in a jack way
- out of the box avb functionality

con a)
- only one talker/listener, single audio interface
- huge programming effort
- no dynamic audio mapping


pro b)
- multiple talkers/listeners with multiple audio interface using alsa api
- avoiding huge code addition to the backend, thus much easier to maintain
- AVDECC handling per client for dynamic audio mapping

con b)
- cpu load... price for multiple talkers/listeners


I'm excited to hear your opinions!

Best,
Ck

--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
_______________________________________________
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: AVB Backend

Thomas Brand
In reply to this post by Christoph Kuhr
On 2019-04-11 22:44, Christoph Kuhr wrote:
> Hi *,
>
> I wanted to start a discussion of what kind of AVB connectivity makes
> the most sense for jack.
> But please keep in mind what AVB is and isn't.
>
> a) Fully functional Backend
> b) Media Clock Backend with AVB jack clients

>
> I'm excited to hear your opinions!
>

Hi Chris,

first of all thanks for starting an AVB backend for jack!

My experience with AVB is unfortunately zero.

I understand how both a) and b) can be useful. Thinking in building
blocks, variant c) could be added to make jack the media clock talker (~
clock master on the network). IIUC b) and c) would cooperate nicely,
without the need for much "fatter" full avb stack a). C would clock Bs
or similar, in an AVB compliant way. The b) variant seems already useful
however I've no way to verify this.

Let's wait for others to join the discussion but keep in mind that not
everybody has the same level of insights which you gained by the work
done in the field. AVB was a topic in the past so chances are good there
are opinions :)

Greetings
Thomas
_______________________________________________
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: AVB Backend

Chris Caudle
In reply to this post by Christoph Kuhr
On Thu, April 11, 2019 3:44 pm, Christoph Kuhr wrote:
> I wanted to start a discussion of what kind of AVB connectivity makes the
> most sense for jack.
> But please keep in mind what AVB is and isn't.
>
> a) Fully functional Backend
> b) Media Clock Backend with AVB jack clients
...
> con a)
> - only one talker/listener, single audio interface
...
> pro b)
> - multiple talkers/listeners with multiple audio interface using alsa api

I did not see many replies to this, but if I understand the limitations
correctly I believe b would be the more useful.

Is the limit described for a implying that if you had for example two or
three of the MOTU AVB interfaces, you could only connect to one at a time?

If so then definitely b would be the preference, since one of the
advantages of network audio protocols is that you can have a distributed
recording and playback system, and if your input needs grow you do not
have to trade out a small interface for a larger interface, you can just
add an additional small interface, with the added benefit that the
interfaces can be in two different rooms.
If you are limited to one interface at a time then the only benefit over
USB is a longer cable.

--
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: AVB Backend

Ethan Funk
I vote for B as well. I am working on porting a Mac OS X radio automation system I wrote to Linux/FreeBSD using Jack2. AVB is certainly on my radar for use! However, I was under the impression, without having dug to deep into the protocol, that the AVB's precision network time management allows all devices to share a sample clock. That sure would make it easy from a JACK perspective. No asynchronous re-sampling would be required (if I am correct about network time). Since I have no AVB equipment, I am not clear how one goes about setting up which device on the network is the clock master, but it must be configurable somehow.

Ethan...


On Wed, 2019-06-19 at 15:03 -0500, Chris Caudle wrote:
On Thu, April 11, 2019 3:44 pm, Christoph Kuhr wrote:
I wanted to start a discussion of what kind of AVB connectivity makes the
most sense for jack.
But please keep in mind what AVB is and isn't.

a) Fully functional Backend
b) Media Clock Backend with AVB jack clients
...
con a), 
- only one talker/listener, single audio interface
...
pro b)
- multiple talkers/listeners with multiple audio interface using alsa api

I did not see many replies to this, but if I understand the limitations
correctly I believe b would be the more useful.

Is the limit described for a implying that if you had for example two or
three of the MOTU AVB interfaces, you could only connect to one at a time?

If so then definitely b would be the preference, since one of the
advantages of network audio protocols is that you can have a distributed
recording and playback system, and if your input needs grow you do not
have to trade out a small interface for a larger interface, you can just
add an additional small interface, with the added benefit that the
interfaces can be in two different rooms.
If you are limited to one interface at a time then the only benefit over
USB is a longer cable.


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

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

Re: AVB Backend

Chris Caudle
On Wed, June 19, 2019 3:12 pm, Ethan Funk wrote:
> I was under the impression...that the AVB's
> precision network time management allows all devices to share a sample
> clock.

That is correct for AVB as well as for the other RTP/IP (layer 3) based
transports such as Dante, Livewire, Ravenna, etc.

> No asynchronous re-sampling would be required

Correct

> I am not clear how one goes about setting up which
> device on the network is the clock master

If you have access to IEEE specs see IEEE 1588-2008 and IEEE 802.1AS.
802.1AS is a profile of 1588-2008, there is what is known as "best master
clock algorithm" to select the best clock.  If multiple devices are
advertising equivalent quality ranking there is a tie breaker, I think
based on MAC address, but don't  quote that, I am going from memory and
have not looked at the details in quite a while.

--
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: AVB Backend and MIDI question

Ethan Funk
Very good on the AVB clocking. I can't get the IEEE pubs legally, since I have not been an IEEE member, or employed by a company large enough to be an IEEE member, since the 1990's.

As a side question regarding Jack2 and midi: I would like to use jack's midi mechanism to pass control information between components in my automation system. So far I have been able to twist existing midi packets suck as time-code, and such to control player components and keep my mixer appraised as to source play positions and such. However, I have no easy way to pass meta data, such as song tags, through midi, with out the complexity of using sysex messages and base64 encoding the 8 bit meta-data fto be passed as midi data. Can I ignore midi's underlying byte format and just pass 8 bit buffers to jack and expect jack to deliver the buffers with out jack inspecting the buffers for validity according to midi? I only intend to use the midi ports within my applications various player and encoder components. I do not expect any of this data to actually be send to a device or program that is expecting real midi data.

Ethan...

On Wed, 2019-06-19 at 15:31 -0500, Chris Caudle wrote:
On Wed, June 19, 2019 3:12 pm, Ethan Funk wrote:
I was under the impression...that the AVB's
precision network time management allows all devices to share a sample
clock.

That is correct for AVB as well as for the other RTP/IP (layer 3) based
transports such as Dante, Livewire, Ravenna, etc.

No asynchronous re-sampling would be required

Correct

I am not clear how one goes about setting up which
device on the network is the clock master

If you have access to IEEE specs see IEEE 1588-2008 and IEEE 802.1AS.
802.1AS is a profile of 1588-2008, there is what is known as "best master
clock algorithm" to select the best clock.  If multiple devices are
advertising equivalent quality ranking there is a tie breaker, I think
based on MAC address, but don't  quote that, I am going from memory and
have not looked at the details in quite a while.


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

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

Re: AVB Backend

Fernando Lopez-Lezcano
In reply to this post by Christoph Kuhr
On 4/11/19 1:44 PM, Christoph Kuhr wrote:
> Hi *,
>
> I wanted to start a discussion of what kind of AVB connectivity makes
> the most sense for jack.
> But please keep in mind what AVB is and isn't.

For my use case b) would be the only choice. I have been using Motu
hardware (with all its problems) because of its flexibility in setting
up complex systems[*] - the biggest has 8 AVB connected audio
interfaces. I am actively looking at AVB options as I am currently
restricted to 64 channel max I/O through USB to/from the Linux computers.

One talker/one listener would not be nearly enough. Dynamic stream
management without having to restart jack would be (almost) a requirement.

> a) Fully functional Backend
> b) Media Clock Backend with AVB jack clients
>
> pro a)
> - the AVDECC connection management could be done seamlessly in a jack way
> - out of the box avb functionality
>
> con a)
> - only one talker/listener, single audio interface
> - huge programming effort
> - no dynamic audio mapping
>
>
> pro b)
> - multiple talkers/listeners with multiple audio interface using alsa api

So the AVB stuff would be written in ALSA?

> - avoiding huge code addition to the backend, thus much easier to maintain

Hmmm, sure, but the code has to go somewhere, is that ALSA?

> - AVDECC handling per client for dynamic audio mapping
>
> con b)
> - cpu load... price for multiple talkers/listeners

Not too concerned about this (a single 64 channel USB interface on my
current computers uses up about 12% of a core)...

Best,
-- Fernando

[*] https://ccrma.stanford.edu/~nando/publications/stage_grail_2019.pdf


> I'm excited to hear your opinions!
>
> Best,
> Ck
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

_______________________________________________
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: AVB Backend and MIDI question

Christoph Kuhr
In reply to this post by Ethan Funk
Hi *,

I already started working on solution b. Solution a should just be used
as a media clock stream talker. i.e. The JACK backend as such should
just be working as a media clock backend, either master or slave. You
guys already named the pros/cons...


On 06/20/2019 08:06 PM, Fernando Lopez-Lezcano wrote:

> On 4/11/19 1:44 PM, Christoph Kuhr wrote:
>> Hi *,
>>
>> I wanted to start a discussion of what kind of AVB connectivity makes
>> the most sense for jack.
>> But please keep in mind what AVB is and isn't.
>
> For my use case b) would be the only choice. I have been using Motu
> hardware (with all its problems) because of its flexibility in setting
> up complex systems[*] - the biggest has 8 AVB connected audio
> interfaces. I am actively looking at AVB options as I am currently
> restricted to 64 channel max I/O through USB to/from the Linux computers.
>
> One talker/one listener would not be nearly enough. Dynamic stream
> management without having to restart jack would be (almost) a requirement.
>
>> a) Fully functional Backend
>> b) Media Clock Backend with AVB jack clients
>>
>> pro a)
>> - the AVDECC connection management could be done seamlessly in a jack way
>> - out of the box avb functionality
>>
>> con a)
>> - only one talker/listener, single audio interface
>> - huge programming effort
>> - no dynamic audio mapping
>>
>>
>> pro b)
>> - multiple talkers/listeners with multiple audio interface using alsa api
>
> So the AVB stuff would be written in ALSA?
>
>> - avoiding huge code addition to the backend, thus much easier to
>> maintain
>
> Hmmm, sure, but the code has to go somewhere, is that ALSA?
No, it would be a seperate code base. I already started it.
It has two major dependencies:
JACK and OpenAvnu.
It would be a pain for either project to keep the deps...

The Idea is as follows:

- Python websocket server with HTML/JS UI  (see screenshot)
- OpenAvnu / AudioScience libavdecc example controller app (OpenAvnu repo)
- Python bash wrapper, that runs the controller app
- Py websocket server create JACK AVB talker/listener clients:
        -> listener is easy:
                - just launch a JACK client with some libpcap code
        -> talker is harder:
                - You need to find the attached audio hardware
                - create a single talker for a single attached audio
  interface (HARD CONSTRAINT!) in ALSA
                - all talkers AVTP packets need to be scheduled with
                        precise timing for DMA transfer and HW Queue
                        transmission


On 06/20/2019 05:48 PM, Ethan Funk wrote:
> Very good on the AVB clocking. I can't get the IEEE pubs legally, since
> I have not been an IEEE member, or employed by a company large enough to
> be an IEEE member, since the 1990's.

BTW, does someone have the updated standards? I really could use them.

Unsurprisingly, our university does not have an IEEE account.......

- 1722-2016: https://ieeexplore.ieee.org/document/7782716
- 1722.1-2019: https://ieeexplore.ieee.org/document/8666953

>
> As a side question regarding Jack2 and midi: I would like to use jack's
> midi mechanism to pass control information between components in my
> automation system. So far I have been able to twist existing midi
> packets suck as time-code, and such to control player components and
> keep my mixer appraised as to source play positions and such. However, I
> have no easy way to pass meta data, such as song tags, through midi,
> with out the complexity of using sysex messages and base64 encoding the
> 8 bit meta-data fto be passed as midi data. Can I ignore midi's
> underlying byte format and just pass 8 bit buffers to jack and expect
> jack to deliver the buffers with out jack inspecting the buffers for
> validity according to midi? I only intend to use the midi ports within
> my applications various player and encoder components. I do not expect
> any of this data to actually be send to a device or program that is
> expecting real midi data.
>
Well I did not look into MIDI over AVB so far. Have enough to struggle
to get audio and management stuff right...
But if someone feels up to the task, very appreciated!


>> con b)
>> - cpu load... price for multiple talkers/listeners
>
> Not too concerned about this (a single 64 channel USB interface on my
> current computers uses up about 12% of a core)...

Yeah, but your not doing PTP, MRP, MAAP on the CPU in real-time as a
requirement to receive a single sample. And the context switches between
the AVTP receiver/talker threads.....
If you use a MOTU it takes care of this stuff for you. Standard USB has
nothing comparable in place, if just class compliant.


If someone does not like the very very simple interface, you are welcome
  to make it pretty. For me, I hate JS and stuff! ;-)



Best,
Ck

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

screenshot.png (734K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: AVB Backend and MIDI question

Christoph Kuhr
In reply to this post by Ethan Funk
Actually,


> As a side question regarding Jack2 and midi: I would like to use jack's
> midi mechanism to pass control information between components in my
> automation system. So far I have been able to twist existing midi
> packets suck as time-code, and such to control player components and
> keep my mixer appraised as to source play positions and such. However, I
> have no easy way to pass meta data, such as song tags, through midi,
> with out the complexity of using sysex messages and base64 encoding the
> 8 bit meta-data fto be passed as midi data. Can I ignore midi's
> underlying byte format and just pass 8 bit buffers to jack and expect
> jack to deliver the buffers with out jack inspecting the buffers for
> validity according to midi? I only intend to use the midi ports within
> my applications various player and encoder components. I do not expect
> any of this data to actually be send to a device or program that is
> expecting real midi data.

  in the AVB realm, you would use AVDECC AEM for such a purpose instead
of abusing MIDI for it. ;-)

I did not look at JACKs meta data API, but I suppose it could be
integrated with AEM very nicely...

>>
>>> I am not clear how one goes about setting up which
>>> device on the network is the clock master
>>
>> If you have access to IEEE specs see IEEE 1588-2008 and IEEE 802.1AS.
>> 802.1AS is a profile of 1588-2008, there is what is known as "best master
>> clock algorithm" to select the best clock.  If multiple devices are
>> advertising equivalent quality ranking there is a tie breaker, I think
>> based on MAC address, but don't  quote that, I am going from memory and
>> have not looked at the details in quite a while.

As mentioned BMCA takescare of it. It is a nice feature to be able to
choose the GM, but it practically makes no sense.
What is the need for a specific GM if you AVB switch is down?
Thus, one of the AVB switches involved should be the GM. The "core-most"
switch in particular.

Or  can someone think of a scenario, where this does not make sense?



Best,
Ck
_______________________________________________
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: AVB Backend and MIDI question

Chris Caudle
On Mon, June 24, 2019 6:46 am, Christoph Kuhr wrote:
> What is the need for a specific GM if you AVB switch is down?
> Thus, one of the AVB switches involved should be the GM. The "core-most"
> switch in particular.
>
> Or  can someone think of a scenario, where this does not make sense?

If you have a higher quality device (for example a network master clock
connected to GPS disciplined oscillator for high stability).  In that case
the device should advertise a higher quality and should be selected as
master clock in any case.
One other case which comes to mind is if you want a multi-protocol device
to be master for a mixed system, so a single device providing synchronized
802.1AS for AVB devices, and layer 3 1588 messages for layer 3 devices.
Definitely starts getting into specialized cases, and you should be able
to set the clock quality field on a specialized clock source like that so
that it always wins the best master clock vote.

--
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: AVB Backend and MIDI question

Christoph Kuhr
Of course. GPS sync, forgot about that.
But for multi protocol, you should use a proxy GM for 1588. Meaning the device is synced via 802.1AS and provides l3 sync for other 1588 devices. What do you think?
Aren't we always talking about specialized cases? ;-)

Am 24. Juni 2019 16:13:05 MESZ schrieb Chris Caudle <[hidden email]>:
On Mon, June 24, 2019 6:46 am, Christoph Kuhr wrote:
What is the need for a specific GM if you AVB switch is down?
Thus, one of the AVB switches involved should be the GM. The "core-most"
switch in particular.

Or can someone think of a scenario, where this does not make sense?

If you have a higher quality device (for example a network master clock
connected to GPS disciplined oscillator for high stability). In that case
the device should advertise a higher quality and should be selected as
master clock in any case.
One other case which comes to mind is if you want a multi-protocol device
to be master for a mixed system, so a single device providing synchronized
802.1AS for AVB devices, and layer 3 1588 messages for layer 3 devices.
Definitely starts getting into specialized cases, and you should be able
to set the clock quality field on a specialized clock source like that so
that it always wins the best master clock vote.

--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
_______________________________________________
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: AVB Backend and MIDI question

Christoph Kuhr
In reply to this post by Chris Caudle
ps:
a different clock domain requires a dedicated GM. 1588 and 802.1AS are seperate clock domains.

Am 24. Juni 2019 16:13:05 MESZ schrieb Chris Caudle <[hidden email]>:
On Mon, June 24, 2019 6:46 am, Christoph Kuhr wrote:
What is the need for a specific GM if you AVB switch is down?
Thus, one of the AVB switches involved should be the GM. The "core-most"
switch in particular.

Or can someone think of a scenario, where this does not make sense?

If you have a higher quality device (for example a network master clock
connected to GPS disciplined oscillator for high stability). In that case
the device should advertise a higher quality and should be selected as
master clock in any case.
One other case which comes to mind is if you want a multi-protocol device
to be master for a mixed system, so a single device providing synchronized
802.1AS for AVB devices, and layer 3 1588 messages for layer 3 devices.
Definitely starts getting into specialized cases, and you should be able
to set the clock quality field on a specialized clock source like that so
that it always wins the best master clock vote.

--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org