AES67 Linux Daemon with WebUI

692 views
Skip to first unread message

Andrea Bondavalli

unread,
Jan 29, 2020, 4:38:26 PM1/29/20
to Audio over IP
Dear all,

I have recently published on GitHub an AES67 Linux Daemon and the associated configuration WebUI both licensed under the GPLv3.
The daemon uses the Merging Technologies ALSA RAVENNA/AES67 Driver and implements a number of functionalities including:
- communication and configuration with the driver via netlink
- session handling and SDP parsing and creation
- HTTP REST API for control and configuration
- SAP discovery protocol implementation
- IGMP handling for SAP and RTP sessions

You can find the daemon and the WebUI source code at:
https://github.com/bondagit/aes67-linux-daemon

In the repo you will find also scripts to build and to run a simple demo on recent Ubuntu distros (18.04 and 19.10) and the daemon REST API documentation under the "daemon" folder.

* Please note that since I don't have any AES67 device I didn't run any interoperability tests but loopback tests only. *

Your comments, suggestions and contributions are welcome.

Kind regards,
Andrea Bondavalli

Andrea Bondavalli

unread,
Feb 6, 2020, 7:30:43 AM2/6/20
to Audio over IP
Dear all,

as follow up my previous e-mail,  I' m happy to inform you that I have recently added patches to the ALSA RAVENNA/AES67 Driver to compile and run properly on ARMv7 processor family.
I could successfully run the demo and the daemon regression tests on the BeagleBone® Black board with ARM Cortex-A8 32-Bit processor using the Ubuntu 18.04 on BeagleBone® Black distribution (see https://elinux.org/BeagleBoardUbuntu)

In addition to this I could successfully complete interoperability tests using the Hasseb Audio over Ethernet receiver (see http://hasseb.fi/shop2/index.php?route=product/product&product_id=62) .
For such purpose I configured the daemon to operate at 48Khz, I created a source with codec L24 and I entered the SDP file manually into the Hasseb device interface.

You can find the daemon and the WebUI source code at:

Kind regards,
Andrea Bondavalli

Edgars Mucenieks

unread,
Feb 17, 2020, 4:32:35 AM2/17/20
to Audio over IP
Confirmed working using x86 Ubuntu 18.04.2 LTS kernel version 4.15.0-76-generic and Music Player Daemon (MPD) as source and Raspberry Pi3 Raspbian GNU/Linux 10 (buster) kernel version 4.19.97-v7+  plus USB sound card as sink. Dumb FastEthernet switch without heavy load. Don't even try using it over shared media like WiFi or Ethernet over powerline (I tried both - no go for WiFi, better for  Powerline Eth but still cracks and pops in sound)

Andrea Bondavalli

unread,
Feb 17, 2020, 11:57:07 AM2/17/20
to Edgars Mucenieks, Audio over IP
Hi Edgars,

thanks for your message and for testing the daemon.
AES67 is meant to be used on Ethernet so it's not surprising me that
it's not performing well on WiFi / Powerline.
You can try incrementing the playout delay on the sink, maybe this
helps in case you receive many late RTP packets.
Nothing to do instead in case you are actually loosing RTP packets.
In the WebUI I limited the delay you can set to 960 samples
(20ms@48KHz) because this is usually enough when testing over an
Ethernet.
You can try to further increase this delay to 1840, 3680 or even more
samples, just edit the status.json file manually, change the sink
"delay" parameter when the daemon is not running and restarting it.
To understand the problem you may try to capture the packets with
tcpdump and analyze them with Wireshark. This indeed has a nice
function that allows to perform RTP stream analysis.

Kind regards,
Andrea

Il giorno lun 17 feb 2020 alle ore 10:32 Edgars Mucenieks
<muc...@gmail.com> ha scritto:
>
> Confirmed working using x86 Ubuntu 18.04.2 LTS kernel version 4.15.0-76-generic and Music Player Daemon (MPD) as source and Raspberry Pi3 Raspbian GNU/Linux 10 (buster) kernel version 4.19.97-v7+ plus USB sound card as sink. Dumb FastEthernet switch without heavy load. Don't even try using it over shared media like WiFi or Ethernet over powerline (I tried both - no go for WiFi, better for Powerline Eth but still cracks and pops in sound)
>
> --
> You received this message because you are subscribed to the Google Groups "Audio over IP" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to audio-over-i...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/audio-over-ip/6a5681a5-3c06-4db0-b371-e992f26f80fb%40googlegroups.com.

Edgars Mucenieks

unread,
Feb 17, 2020, 3:49:40 PM2/17/20
to Audio over IP


Hi Andrea,
no worries, me, already knowing purposes and needs of Dante and AES67 and without having real devices on hands, finally got chance to play with. I am totally satisfied with the results  ;)  However, and it might be worth separate post, for home usage I found different project (unicast UDP transport, lossless CD-quality (PCM 16-bit, 44100 stereo) using RTP and Forward Erasure Correction loss recovery) - https://roc-project.github.io/  Works fine through WiFi...

Andrea Bondavalli

unread,
Feb 18, 2020, 11:40:07 AM2/18/20
to Edgars Mucenieks, Audio over IP
Hi Edgars,

I have been thinking to the problems you have on WiFi and Powerline
and there is a daemon configuration that can maybe help.
By using the fact that the sinks are synchronized using the same GM
clock you can try using two sources and two sinks all configured to
use the ALSA channels.
For example you configure two sources both using ALSA output 1, 2
(assuming stereo audio) and two sinks both using the ALSA input 1, 2.
This way without additional effort you generate two separated and
redundant RTP flows that are resynchronized at the sync. Apart from
this you can run your test as usual (a single playback and a single
recording on ALSA channels 1,2).
Now depending how the packets loss is hitting the communication
channels this strategy can lead to some useful results or not.
The best of course would be to use RTP packets interleaving to
disperse burst losses into a series of shorter losses, but this is not
supported.

Kind regards,
Andrea

Il giorno lun 17 feb 2020 alle ore 21:49 Edgars Mucenieks
<muc...@gmail.com> ha scritto:
>
>
>
> Hi Andrea,
> no worries, me, already knowing purposes and needs of Dante and AES67 and without having real devices on hands, finally got chance to play with. I am totally satisfied with the results ;) However, and it might be worth separate post, for home usage I found different project (unicast UDP transport, lossless CD-quality (PCM 16-bit, 44100 stereo) using RTP and Forward Erasure Correction loss recovery) - https://roc-project.github.io/ Works fine through WiFi...
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "Audio over IP" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/audio-over-ip/Jsua2t5QxXI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to audio-over-i...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/audio-over-ip/4cc31015-c338-44a5-9771-1a0574ee7853%40googlegroups.com.

Guido Caliandro

unread,
Apr 1, 2020, 7:49:20 PM4/1/20
to Audio over IP
Hi Andrea,
first of all thank you for your work on it, it's long time I was looking for something similar.
I would like to share with you my tests:
My tests are on CRUX distribution, the parent of arch-linux, with Kernel 5.5.13
I successfully compiled and run the packages from git version of March, 6th, but for version March, 31st, this is what happens when I try to run the daemon:

[2020-04-01 12:23:14.305577] [0x00007f0dc5139580] [info]    driver_manager:: cmd Hello done data len 0
[2020-04-01 12:23:14.305641] [0x00007f0dc5139580] [info]    driver_manager:: cmd Start done data len 0
[2020-04-01 12:23:14.305684] [0x00007f0dc5139580] [info]    driver_manager:: cmd Reset done data len 0
[2020-04-01 12:23:14.305696] [0x00007f0dc5139580] [info]    driver_manager:: setting interface eth0
[2020-04-01 12:23:14.305730] [0x00007f0dc5139580] [info]    driver_manager:: cmd SetInterfaceName done data len 0
[2020-04-01 12:23:14.305751] [0x00007f0dc5139580] [info]    driver_manager:: setting PTP Domain 0 DSCP 48
[2020-04-01 12:23:14.305791] [0x00007f0dc5139580] [info]    driver_manager:: cmd SetPTPConfig done data len 0
[2020-04-01 12:23:14.305835] [0x00007f0dc5139580] [info]    driver_manager:: cmd SetTICFrameSizeAt1FS done data len 0
[2020-04-01 12:23:14.305876] [0x00007f0dc5139580] [info]    driver_manager:: cmd SetPlayoutDelay done data len 0
[2020-04-01 12:23:14.305917] [0x00007f0dc5139580] [info]    driver_manager:: cmd SetMaxTICFrameSize done data len 0
[2020-04-01 12:23:14.306155] [0x00007f0dc4931700] [info]    igmp:: joined multicast group 224.0.1.129 on 192.168.1.178
[2020-04-01 12:23:14.306225] [0x00007f0dc4931700] [info]    driver_manager:: cmd GetPTPConfig done data len 2
[2020-04-01 12:23:14.306272] [0x00007f0dc4931700] [info]    driver_manager:: cmd GetPTPStatus done data len 16
[2020-04-01 12:23:14.306295] [0x00007f0dc4931700] [info]    session_manager:: new PTP clock status unlocked
[2020-04-01 12:23:14.307125] [0x00007f0dc5139580] [fatal]   avahi_client:: failed to create service browser: Bad state
[2020-04-01 12:23:15.306461] [0x00007f0dc4931700] [info]    igmp:: left multicast group 224.0.1.129 on 192.168.1.178
[2020-04-01 12:23:15.306829] [0x00007f0dc5139580] [fatal]   main:: fatal exception error: Browser:: init failed
[2020-04-01 12:23:15.306858] [0x00007f0dc5139580] [info]    main:: end 
daemon exiting with code: 1

but if I compile changing cmake -DWITH_AVAHI=ON to OFF in build.sh, it starts correctly.

I can also see my DANTE AVIO USB from the webui.
I also see it inside DANTE CONTROLLER, but I couldn't connect the AVIO to it (a problem about samplerate...)

I will compile it on my Raspberry PI 4 and I will tell you about that.

I'm waiting for a RME DIGIFACE DANTE and I'll check with that too...

For any test you would like I make on my hardware, feel free to ask me

Thanks again for your work on it

Guido Caliandro
> To unsubscribe from this group and all its topics, send an email to audio-...@googlegroups.com.

Tobias Wallin

unread,
Apr 2, 2020, 7:20:36 AM4/2/20
to Audio over IP
This is really good news! I would love to run this on Raspbian. Will there be a package available for us less savvy tinkerers?

Andrea Bondavalli

unread,
Apr 2, 2020, 2:26:28 PM4/2/20
to Guido Caliandro, Audio over IP
Hi Guido,

thanks for your message.
I suspect the problem depends on the not fully correct use of the
Avahi client library in the daemon code but I need you to verify a
couple of things.
I have tested the daemon with Avahi v0.7 on both x86 and ARMv7
platforms and it can be you are using a later version.

Can you check the version of Avahi you are currently using?
> avahi-browse -V

Can you run the following command and send me output:
> avahi-browse -f -r _rtsp._tcp -t

I'd like to understand if Avahi is fully working on your distribution
and if yes I will be working on a fix.

May I ask you to open an issue on GitHub for this problem too ? Thanks
! More persons might be affected by the same issue.

Apart from these I have just released a change that enables the
possibility to enable/disable the mDNS client using the WebUI.
So for the time beeing you can still compile the daemon with the
option "-DWITH_AVAHI=yes" and disable mDNS at runtime.

Thanks and kind regards,
Andrea



Il giorno gio 2 apr 2020 alle ore 01:49 Guido Caliandro
<guido.c...@gmail.com> ha scritto:
> You received this message because you are subscribed to the Google Groups "Audio over IP" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to audio-over-i...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/audio-over-ip/459473bc-51b8-4b86-99c3-dea4980ba526%40googlegroups.com.

Andrea Bondavalli

unread,
Apr 2, 2020, 2:47:28 PM4/2/20
to Tobias Wallin, Audio over IP
Hi Tobias,

thanks for your email.
the AES67 daemon code is still a bit young and I didn't deploy any package yet.
I will be working on an official packge in the future. I'd like to add
mDNS announcements first and improve the stability.
Please consider that the daemon also requires a kernel module and this
has to be compiled with the specifc Linux kernel version included in
your distribution.

Kind regards,
Andrea

Il giorno gio 2 apr 2020 alle ore 13:20 'Tobias Wallin' via Audio over
IP <audio-...@googlegroups.com> ha scritto:
>
> This is really good news! I would love to run this on Raspbian. Will there be a package available for us less savvy tinkerers?
>
> --
> You received this message because you are subscribed to the Google Groups "Audio over IP" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to audio-over-i...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/audio-over-ip/e2bfca20-4f21-4e2e-81aa-a30ac1c0f1bf%40googlegroups.com.

Guido Caliandro

unread,
Apr 3, 2020, 4:15:42 AM4/3/20
to Andrea Bondavalli, Audio over IP
Hi Andrea,

I'm pretty sure the problem is what you suspect, maybe avahi is not fully working on my distribution, I've never used that before:

avahi-browse -V
avahi-browse 0.8

avahi-browse -f -r _rtsp._tcp -t
(no output)

sure I will open the issue on GitHub asap

kind regards,

Guido

Johnny

unread,
Jun 11, 2020, 4:48:40 PM6/11/20
to Audio over IP
Hello Andrea,

I am trying to run the demo on ARM Cortex A53 64-bit. Every thing builds without any error. However, when trying to load the kernel module I get the following 

insmod: ERROR: could not insert module 3rdparty/ravenna-alsa-lkm/driver/MergingRavennaALSA.ko: Invalid module format

Any idea what went wrong? 

Many thanks,
Johnny 

Andrea Bondavalli

unread,
Jun 12, 2020, 7:47:27 AM6/12/20
to Johnny, Audio over IP
Hi Johnny,

most probably you compiled the module for the wrong kernel version / platform.
Can you send me the output of the following command executed on the module you are trying to install ?
> modinfo ./MergingRavennaALSA.ko

Can you send me the output of the following command executed on your ARM board ?
> uname -a

Thanks,
Andrea

--
You received this message because you are subscribed to a topic in the Google Groups "Audio over IP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/audio-over-ip/Jsua2t5QxXI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to audio-over-i...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/audio-over-ip/b6156f00-babe-4a21-a693-179cc9c0a419o%40googlegroups.com.

Johnny

unread,
Jun 12, 2020, 10:12:04 AM6/12/20
to Audio over IP
Hi Andrea,
Many thanks for the super fast reply.

>> modinfo ./MergingRavennaALSA.ko

filename:       /aes67-linux-daemon/3rdparty/ravenna-alsa-lkm/driver/./MergingRavennaALSA.ko
version:        0.2
description:    Merging Technologies RAVENNA ALSA driver
author:         Merging Technologies 
license:        GPL v2
srcversion:     54B87D92BDA177668D2A8EE
depends:
name:           MergingRavennaALSA
vermagic:       4.14.180-s5p6818 SMP mod_unload aarch64
parm:           index:Index value for Merging RAVENNA soundcard. (int)
parm:           id:ID string for Merging RAVENNA soundcard. (charp)
parm:           enable:Enable Merging RAVENNA soundcard. (bool)
parm:           pcm_devs:PCM devices # (1) for Merging RAVENNA Audio driver. (int)


uname -a
Linux nanopifire3 4.14.180-s5p6818 #4 SMP PREEMPT Sat Jun 6 21:36:30 CEST 2020 aarch64 aarch64 aarch64 GNU/Linux

Johnny

Andrea Bondavalli

unread,
Jun 12, 2020, 10:36:07 AM6/12/20
to Johnny, Audio over IP
Kernel version seems to match so the problem is probably somewhere else.
You should find more information in the kernel messages.
Can you send me the output of the command ?
> dmesg

Thanks

--
You received this message because you are subscribed to a topic in the Google Groups "Audio over IP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/audio-over-ip/Jsua2t5QxXI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to audio-over-i...@googlegroups.com.

Andrea Bondavalli

unread,
Jun 12, 2020, 10:48:23 AM6/12/20
to Johnny, Audio over IP
Hi Johnny,
a thing that I noticed is that you have the PREEMPT flag reported by the Kernel  (Linux nanopifire3 4.14.180-s5p6818 #4 SMP PREEMPT) but no my the module (4.14.180-s5p6818 SMP) .
This means your kernel was compiled with preemption enabled (CONFIG_PREEMPT) but this was not the configuration when you compiled the module. You should have (4.14.180-s5p6818 SMP preempt ) .
I am not sure if this is the problem but it might be.
Andrea

Johnny

unread,
Jun 12, 2020, 11:00:55 AM6/12/20
to Audio over IP
Hi Andrea,

I think this might be the problem; dmesg also indicates this 

 MergingRavennaALSA: version magic '4.14.180-s5p6818 SMP mod_unload aarch64' should be '4.14.180-s5p6818 SMP preempt mod_unload aarch64'

I will try the PREEMPT header and report the result.

Thanks again.
Johnny

Johnny

unread,
Jun 12, 2020, 11:43:38 AM6/12/20
to Audio over IP
After installing the correct header and recompiling, every thing works like a charm.
Thanks again for your great help Andrea.
Johnny
Reply all
Reply to author
Forward
0 new messages