11 Apr
2019
11 Apr
'19
3:44 p.m.
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.
11 Apr
11 Apr
4:07 p.m.
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 <christoph.kuhr(a)web.de>de>:
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.
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
12 Apr
12 Apr
1:12 p.m.
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
19 Jun
19 Jun
3:03 p.m.
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
3:13 p.m.
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.
3:31 p.m.
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
20 Jun
20 Jun
10:48 a.m.
New subject: [Jack-Devel] AVB Backend and MIDI question
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.
23 Jun
23 Jun
2:56 a.m.
New subject: [Jack-Devel] AVB Backend and MIDI question
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:
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
On 4/11/19 1:44 PM, Christoph Kuhr wrote:
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:
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? 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)... 
24 Jun
24 Jun
6:46 a.m.
New subject: [Jack-Devel] AVB Backend and MIDI question
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
9:13 a.m.
New subject: [Jack-Devel] AVB Backend and MIDI question
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
26 Jun
26 Jun
1:38 a.m.
New subject: [Jack-Devel] AVB Backend and MIDI question
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 <chris(a)chriscaudle.org>rg>:
On Mon, June 24, 2019 6:46 am, Christoph Kuhr wrote:
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
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
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
1:39 a.m.
New subject: [Jack-Devel] AVB Backend and MIDI question
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 <chris(a)chriscaudle.org>rg>:
On Mon, June 24, 2019 6:46 am, Christoph Kuhr wrote:
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
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
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org 
20 Jun
20 Jun
1:06 p.m.
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.
2324
days inactive
2399
days old
jackaudio@lists.linuxaudio.org
12 comments
5 participants
participants (5)
-
Chris Caudle -
Christoph Kuhr -
Ethan Funk -
Fernando Lopez-Lezcano -
Thomas Brand