Streaming Audio with run_avtp_pipeline.sh with a MOTU 624

[nguyensp]

Hello, I am attempting to stream audio from my linux machine running Ubuntu 18.04LTS to a MOTU 624. The goal is hear audio with headphones just as you would when the MOTU is connected to a Mac Pro. I have an Intel I210 NIC connected directly to the MOTU 624 (https://s3.amazonaws.com/motu-www-data/manuals/avb/624_User_Guide.pdf) using an ethernet cable (cat6). All of the daemons are installed and running in the background (gptp, maap, mrpd, shaper) and the igb_avb module has been inserted. As you can see with the following screenshots, I am able to run the avtp_pipeline example with "sudo./run_avtp_pipeline.sh enp5s0" and OPENAVB Talker does initialize and stream audio data . Using wireshark, I am able to verify this, but what concerns me is that that destination address is set to 00:00:00_00:00:00. My hypothesis is that this may be the reason why I do not hear audio from the MOTU and may need to configure the settings before it can work. Is there a way to specifically configure the run_avtp_pipeline settings? When I look at the ID setting on the MOTU it provides me with UID:1f2fffe00868a and IP:169.254.35.227.

Thanks

[pinealservo]

I think you stand a reasonable chance of getting this to work, although there's an issue regarding talker timestamps that could cause audio glitches once things are going. But first, you're probably right about the destination address causing problems.

When things are working right, the MAAP daemon is used by the talker to grab a range of MAC addresses to use as stream DAs. Once a range is acquired, it should use one of those addresses when it configures its interaction with the SRP daemon to advertise its stream.

It's been quite a while since I've looked at any of these interactions, so my memory of exactly where to look is fuzzy. But you're going to want to first check to see if there's any interaction with MAAP going on and whether it's got a range reserved to draw addresses from. You should see some probes in Wireshark at least if the MAAP daemon is functional, and there should be some sort of logs generated by the MAAP daemon.

You might also check to see if there's a destination address set in the SRP Talker Advertise declaration in Wireshark. If there's one set there but not in the AVTP stream itself, then there may be some sort of problem getting it communicated to the talker component. Again, check logs and config files and maybe try to increase the verbosity of output.

Once you get the DA problem resolved, you'll probably hear at least some sound, but there could be quality/synchronization issues. These are due to the fact that there's not a great way to get 1588-referenced timestamps from ALSA to determine when the samples were taken and so the media presentation time timestamps are essentially made up based on some heuristics around scheduling of the first packet and a configurable rate ratio parameter. This makes them reasonable to recover a clock from remotely, but it's pretty much guaranteed without a bunch of tweaking to not accurately reflect the physical clock that's sampling the talker's audio data. This may manifest as sample slips, buffer Xruns, stream teardowns, etc.

I don't have any experience with the Listener you're using, but it's possible that it might have a very lenient fallback mode that will adjust its media clock to keep a stable FIFO level if it finds the recovered clock to be bogus. You may end up reasonably happy with the results in this case, but it's definitely not ideal and not fully AVB compliant.

There are a lot of configuration knobs to tweak and hooks in the framework to plug in better methods of timestamping that are yet to be written, but unfortunately there's nothing that'll magically make AVB just work from a generic Linux box right now. It's more a demonstration of how the pieces fit together as a starting point for a project that would involve both hardware and software development.

Good luck!

[nguyensp]

Thank you so much for your thoughtful and generous response; it helped deepen my understanding to the point where I was able to get it to work. I needed to uncomment "dest_addr = 91:e0:f0:00:fe:00" in the example_talker.ini file. I will go to lunch happy.

[chuanqima]

Hi,Nguyun I am really lucky to find that you have encountered a similar problem. Have you finally solved it? What is the effect of successful operation? I also tried sudo./run_avtp_pipeline.sh enp4s0 on my two PCS, but it didn't seem to work. I'll post the log, can you help me look at it? Also, if I change dest_addr, where do I get the value of dest_addr from? Looking forward to your recovery. PC1： PC2:

and follow is wireshark on PC2: If you have successfully run the script,and you happen to be willing to share some of the points of attention and modification (specifically to files) with me in more detail , I would be grateful. tnk,

[nguyensp]

Hi @chuanqima , Here's the process I followed: Required Materials: MOTU 624 Ethernet Cable (Cat 5e/6) Intel I210 Network Interface Card

Optional Materials (Highly Recommended for Debugging): USB-3 Cable MOTU Pro Audio Software for either MAC or Windows MAC or Windows Machine Network Tap (DATACOM 10/100/1000 TAP used here) Wireshark Software (3.0.2)

Obtaining Files: Clone the OpenAvnu github repository(https://github.com/AVnu/OpenAvnu) in a desired location. In the terminal, use

“git clone https://github.com/AVnu/OpenAvnu.git”.

Once this is accomplished, move into /OpenAvnu/daemons/ and clone the necessary gptp github repository(https://github.com/AVnu/gptp). In the terminal, use

“git clone https://github.com/AVnu/gptp.git”.

Next, move into /OpenAvnu/lib/ and clone the igb_avb github respository(https://github.com/AVnu/igb_avb). In the terminal, use

“git clone https://github.com/AVnu/igb_avb.git”.

Install igb_avb: With the igb_avb repository acquired move into /OpenAvnu/lib/igb_avb/kmod and “make”. This will generate “igb_avb.ko” which needs to be installed after the current igb driver is removed. To see which what drivers are installed, use: “lsmod | grep igb” Remove the present igb module with: “sudo rmmod igb” And insert the igb_avb module with: “sudo insmod ./igb_avb.ko”

Build gptp:

Move to /OpenAvnu/daemons/gptp/linux/build/ and use “make”.

Install avtp_pipeline dependencies: (https://github.com/AVnu/OpenAvnu/tree/master/lib/avtp_pipeline)

In terminal use: “ sudo apt-get install build-essential sudo apt-get install libpcap-dev sudo apt-get install libpci-dev sudo apt-get install libsndfile1-dev sudo apt-get install libjack-dev sudo apt-get install linux-headers-generic sudo apt-get install libglib2.0-dev sudo apt-get install libasound2-dev sudo apt-get install libgstreamer1.0-dev sudo apt-get install libgstreamer-plugins-base1.0-dev sudo apt-get install gstreamer1.0-plugins-bad “ Note that the github page recommends “sudo apt-get install libgstreamer0.10-dev” and “sudo apt-get install libgstreamer-plugins-base0.10-dev” This in my experience does not work. Please use sudo apt-get install libgstreamer-plugins-base1.0-dev sudo apt-get install gstreamer1.0-plugins-bad

as mentioned above instead.

Logic Corrections: https://github.com/AVnu/OpenAvnu/issues/382 Go to /OpenAvnu/lib/avtp_pipeline/openavb_common/mrp_client.c and change line 618 from

“return domain_a_valid && domain_b_valid ? 0 : -1”;

to

“return domain_a_valid || domain_b_valid ? 0 : -1;”.

Build avtp_pipeline: Move to /OpenAvnu/ and “make all”.

Move to /OpenAvnu/lib/avtp_pipeline/build/bin/ and uncomment “dest_addr = 91:e0:f0:00:fe:00”.

Move to /OpenAvnu/lib/avtp_pipeline/build/bin/endpoint.ini and change “ifname=”

Running the OpenAvnu AVTP Pipeline: Use “lspci” to discover your .

Configuring the MOTU 624: The MOTU 624 needs be configured for a successful run. Use the MOTU 624 user guide for software installation guidance (https://s3.amazonaws.com/motu-www-data/manuals/avb/624_User_Guide.pdf) if necessary. Addition information can also be found on their website: http://motu.com. Once installed, make sure that the Sample Rate: 48000, Clock Mode: Internal, and Host Buffer Size: 128.

Select the ‘Routing’ tab. Under ‘AVB CONFIGURATION’ choose your desired number of input and output streams.

When the AVTP Pipeline is running successfully. ‘ACME Audio Processor’ should appear under ‘DEVICES’. Under ‘INPUT CONNECTIONS’, the option to choose ‘ACME Audio Processor’ should be selected. Make sure that ACME Audio Processor Input is connected to ‘Phones’ on the grid.

To run the AVTP Pipeline, first initialize the daemons with “sudo ./run_daemons.sh ”.

We should now be able to run the AVTP Pipeline example with “sudo ./run_avtp_pipeline.sh ”.

Hope that helps.

Hey @pinealservo, I greatly appreciate your help earlier. I have a new question at this point. You mentioned: ”I don't have any experience with the Listener you're using, but it's possible that it might have a very lenient fallback mode that will adjust its media clock to keep a stable FIFO level if it finds the recovered clock to be bogus. You may end up reasonably happy with the results in this case, but it's definitely not ideal and not fully AVB compliant. There are a lot of configuration knobs to tweak and hooks in the framework to plug in better methods of timestamping that are yet to be written, but unfortunately there's nothing that'll magically make AVB just work from a generic Linux box right now. It's more a demonstration of how the pieces fit together as a starting point for a project that would involve both hardware and software development.”

At this point, How would I know if this build is fully AVB compliant? (What tests do I need to run to know if this build is fully AVB compliant?) And if not - what needs to happen for it be fully AVB compliant?

[chuanqima]

Hi,Nguyun I am very happy that you can reply to my question so quickly. And your reply is very useful to me, thank you, but when I do this according to these steps, there is still a doubt, in the run_daemon.sh "daemons/maap/linux/build/maap_daemon -i $nic - d /dev/null" The command to start the maap daemon needs to be modified to "daemons/maap/linux/build/maap_daemon -c -d /dev/null" on the listener side? How is this client and server divided? Have you studied this? Tks.

[nguyensp]

Hey @chuanqima , I have not attempted to run the pipeline between two PC's and am unable to speak with authority about that process. The process I outlined is with a direct Linux to MOTU 624 connection via an ethernet cable. It does appear to me however, that some people have managed to successfully run the pipeline between two computers and a switch in the issue log. Perhaps you can find what you need there. Best, Paul

[chuanqima]

hi,@Paul Ok, thank you very much for the detailed steps.I'll look at other people's experiments,thank you.

[ilyas0v]

Hi @nguyensp, @pinealservo thanks for the detailed info above, but I still have issue while building the avtp_pipeline.

make avtp_pipeline

What I got is:

In file included from avb_atl.c:19:
avb_atl.h:4:10: fatal error: atl.h: No such file or directory
    4 | #include <atl.h>
      |          ^~~~~~~
compilation terminated.

There’s no info on internet what the atl.h is for.

Would be appreciated if you can help with this.