On 2019-04-11 22:44, Christoph Kuhr wrote: 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

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:

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:

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: 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: 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 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! 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 Mon, June 24, 2019 6:46 am, Christoph Kuhr wrote: 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

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