[Jack-Devel] AVB Backend and MIDI question

Christoph Kuhr christoph.kuhr at web.de
Sun Jun 23 09:56:08 CEST 2019

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

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! ;-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: screenshot.png
Type: image/png
Size: 548916 bytes
Desc: not available
URL: <https://lists.linuxaudio.org/archives/jackaudio/attachments/20190623/940c6536/attachment.png>

More information about the Jackaudio mailing list