Compatibility with DAW tools about aes67-linux-daemon HOT 34 CLOSED

mr_alsa_audio_pcm_trigger(Start), rate=48000 format=10 channels=128 period_size=48
starting playback I/O
Uninterleaved Playback is not supported

HI Guido,
this is definetly interesting.
It looks like Ardour and Jack attempt to start a playback using S32_LE format but with a not supported access mode
(neither SNDRV_PCM_ACCESS_RW_INTERLEAVED nor SNDRV_PCM_ACCESS_MMAP_INTERLEAVED).
I am pretty sure it's possible to add support for this. I will explore this when possible.

from aes67-linux-daemon.

I will also investigate whether it is possible to specify interleaved access mode. I checked the jackd man page, that did not appear to be an option, but I can double check the code.
Does the driver have a mechanism to query supported modes? If an application attempts to determine whether the driver supports non-interleaved mode is there an ALSA API to return that information?

from aes67-linux-daemon.

From the description of the issue you are experiencing it looks like you didn't compile the WebUI or the attempt to do that failed.
Try with the following commands starting from the root of the aes67-daemon project folder.

cd webui
npm install
npm run build

Also check the guide below and make sure the "http_base_dir" parameter in daemon.conf points to the directory where the WebUI gets built.
https://github.com/bondagit/aes67-linux-daemon/blob/master/DEVICES.md#daemon_setup

from aes67-linux-daemon.

Any update on this?

from aes67-linux-daemon.

Some progress, I corrected the path to the webui, the web interface is now displayed correctly.
The PTP tab indicates the daemon is locked to the device I configured as PTP grandmaster (separate dedicated device, not one of the audio devices).
The Dante controller and RAV2SAP software still do not see any of the announcements from the daemon.
The webui Browser tab does show the SAP announcement from the audio device (Yamaha Tio1608-D Dante stage box).
Because the daemon is not detected by Dante controller I am not able to connect the daemon and the audio device streams.

This is the current conf file in use:

{
"http_port": 8080,
"rtsp_port": 8854,
"http_base_dir": "../webui/build",
"log_severity": 2,
"playout_delay": 0,
"tic_frame_size_at_1fs": 48,
"max_tic_frame_size": 1024,
"sample_rate": 48000,
"rtp_mcast_base": "239.69.0.1",
"rtp_port": 5004,
"ptp_domain": 0,
"ptp_dscp": 46,
"sap_mcast_addr": "239.255.255.255",
"sap_interval": 30,
"syslog_proto": "none",
"syslog_server": "255.255.255.254:1234",
"status_file": "./status.json",
"mdns_enabled": true,
"interface_name": "enp3s4f1",
"node_id": "Chubb AES67 daemon"
}

from aes67-linux-daemon.

Did you create a daemon Source using the WebUI as indicated by:
https://github.com/bondagit/aes67-linux-daemon/blob/master/DEVICES.md#daemon_setup.?
After about 30 secs the Source should show up in the Dante Controller routing dialog.

from aes67-linux-daemon.

Better, I was able to transfer audio. I did create a source, but I noticed that the source can only have up to 15 channels configured. What is the reason for limiting sources to 15 channels? Are sources mapped directly to streams? How should the daemon be configured if you need to use 16 or more outputs?

I noticed that the PTP status had changed to unlocked again. I had previously found a configuration mistake in my PTP GM, which I corrected to the best of my knowledge. I did not see any problems with the PTP configuration, so I killed and restarted the daemon, at which point it locked to the PTP GM again. I had made no change to the PTP GM, so I do not know why the daemon was not able to re-lock to the GM before killing and restarting. I have restarted the daemon with output logged to a file, so will have some record of what occurs if the situation of failing to remain locked to the GM occurs again.
The GM is a BeagleBone Black SBC which gets time through chronyd, then serves system time through ptp4l.
I did use chrt to set the daemon to RT priority, one less than the RT priority of the network driver being used for the audio traffic, so perhaps that will prevent whatever problem caused the daemon to lose lock before.

There was a SEQID.SAC error reported when I attempted to create a sink, so I will research that and work on getting a working sink connection later.

Thank you for the help so far, I have definitely made a lot of progress today.
Are the fields listed in the example conf file the only possible fields?
https://github.com/bondagit/aes67-linux-daemon/blob/master/daemon/daemon.conf
I am going to try to put together notes for all the fields describing which should be left as default, which should be changed, and the possible values which can be used.
Which source files would contain the parsing of those fields to check the allowed value ranges?

from aes67-linux-daemon.

aes67-daemon-lost_ptp_lock.log
That is the daemon output when it lost PTP lock, but I could not see anything in the output indicating a particular problem, just the same string of messages indicating getPTPConfig and getPTPStatus, then the message changed to session_manager:: new PTP clock status unlocked

from aes67-linux-daemon.

Better, I was able to transfer audio. I did create a source, but I noticed that the source can only have up to 15 channels configured. What is the reason for limiting sources to 15 channels? Are sources mapped directly to streams? How should the daemon be configured if you need to use 16 or more outputs?

You can create multiple daemon Sources. Each Source use a list of ALSA channels of the Ravenna audio device.
The binding between the source and the ALSA channels is determined by the ALSA channels map.

from aes67-linux-daemon.

Are the fields listed in the example conf file the only possible fields?

Yes. You can find the documentation related to the configuration parameter at:
https://github.com/bondagit/aes67-linux-daemon/tree/master/daemon#configuration-file

from aes67-linux-daemon.

There was a SEQID.SAC error reported when I attempted to create a sink, so I will research that and work on getting a working sink connection later.

Nothing to worry about this might be a temporary status, just try to reload the status and check again.

from aes67-linux-daemon.

aes67-daemon-lost_ptp_lock.log
That is the daemon output when it lost PTP lock, but I could not see anything in the output indicating a particular problem, just the same string of messages indicating getPTPConfig and getPTPStatus, then the message changed to session_manager:: new PTP clock status unlocked

weird. Try to check if you don't have another master clock on the network.
The only way to debug this problem is to perform a network capture of the UDP traffic on ports 319 and 320.

from aes67-linux-daemon.

Hi,

PTP track hound (https://www.ptptrackhound.com) is also a good tool for PTP debug.

from aes67-linux-daemon.

check if you don't have another master clock on the network

I have only the one PTPv2 GM on that VLAN. If asked before I would have replied that I only have one GM on the network, but I realized that the Dante audio interface is the only Dante compliant device on that VLAN, so it probably became a PTPv1 GM to act as the Dante clock master.

I started PTP Track Hound and it shows my GM as expected, and the Dante interface shown as a BC.
One oddity is that the GM Clock Quality from the GM is shown as changing between P1 128 and P1 64. I have my GM configured to send P1 as 64 so that it will always be selected by BMCA, so I am not sure yet why Track Hound is detecting P1 128 sometimes.

I do see v1 and v2 messages in Track Hound. I will have to work more on Monday to capture the traffic with Track Hound near the time that the daemon loses lock.

from aes67-linux-daemon.

Update on the problem staying locked to the PTP clock leader:
I noticed that the linuxptp GM was running a quite old version of linuxptp, so I disabled that ptp4l instance and allowed the Dante device (Yamaha stage box with a Brooklyn-II Dante interface) to become the clock leader. When I made that change the daemon did not discover the new clock leader, I had to kill and restart the daemon at which point it locked to the Dante clock.
The daemon lost lock again, but I realized it had not been started in RT, so I started the daemon with an appropriate RT priority, and it has stayed locked for over 1 hour so far. I will let it run overnight to see if it loses lock again.

I notice that the kernel ALSA driver does not display a distinct process ID, so I cannot change the RT priority of the driver. Other kernel drivers display in the output of ps -eo and so can have the RT priority set or adjusted. Is there no way to make sure the ALSA Ravenna driver is set to an appropriate RT priority?

I am also curious how others are using this driver. While experimenting I realized that the driver (which I understand is developed originally by Merging, not here by Bondavalli) does not contain any additional buffering, so when using in AES67 mode the user space applications have to use a buffer size of 48 samples to match the network packet size.
The two primary audio production applications, jackd audio server and Ardour DAW, use only power-of-2 size buffers, so a 48 sample buffer size requires running jackd at 32 sample buffer size. I have not been able to get even simple test tone generator applications to run on my machine at a buffer size of 32 samples.
I was hoping that this driver and user space daemon combination could be used as a virtual soundcard to allow using Dante devices in AES67 mode as an audio interface for a DAW. Do you have to use a true Ravenna device for that use case so that you can choose larger buffer sizes?

from aes67-linux-daemon.

I notice that the kernel ALSA driver does not display a distinct process ID, so I cannot change the RT priority of the driver. Other kernel drivers display in the output of ps -eo and so can have the RT priority set or adjusted. Is there no way to make sure the ALSA Ravenna driver is set to an appropriate RT priority?

The driver does not use a kernel thread, so no kernel processes associated with driver are displayed and you don't need to set any priority.

At each tick of the PTP timer (kernel high resolution timer whose base period is defined by the daemon parameter "tic_frame_size_at_1fs") a kernel tasklet gets scheduled for execution. The default value of this timer is set to 48 samples (1ms @ 48Khz) .
This tasklet is responsible for processing the incoming packets and for preparing and sending the outgoing RTP packets at the configured period.
With a period of 48 samples I am able to use various Dante devices in AES67 mode for both receiving and transmitting RTP streams with a 2 ms jitter.
See: https://github.com/bondagit/aes67-linux-daemon/blob/master/DEVICES.md

from aes67-linux-daemon.

"I am able to use various Dante devices in AES67 mode for both receiving and transmitting RTP streams"

Yes, and following the examples I was able to transmit audio from my workstation to my Yamaha stage box using aplay.
But aplay and arecord are not usually part of the normal workflow when producing music with a 16 channel interface, and I hit a wall when trying to use the most popular DAW tools, they are not usable at all. That is what I meant with my question about how others are using this driver (driver/daemon combination). Surely not everyone is only using aplay and arecord are they? Is anyone using this driver in AES67 mode with a DAW? I thought that this could be used something like the use cases Merging describes for connecting their Ravenna interfaces to their Pyramix DAW, but I do not see a way to make that work reliably in AES67 mode.

from aes67-linux-daemon.

I don't have direct experience with these DAW tools.
The driver supports the Linux standard ALSA interface so I would be surprised if you cannot manage to find a solution.
Is there possibility to test with these tools you are using or with a similar open source package ?

from aes67-linux-daemon.

Hi,
I usually use the daemon to run MPD flows to Dante devices, but after reading this thread, I was curious to test some daw applications, here is my results:

• Ardour: No way to listen from Dante
• Bitwig studio: successfully listen to my multiple tracks from Dante devices, but with almost 2 seconds delay
• jack: No way to listen from Dante

Trying to understand what happens, I grabbed some lines from kernel log, and I would like to share with you:

when I start aplay, I read the following:

entering mr_alsa_audio_pcm_open (substream name=subdevice #0 #0) ...

Current PTPFrame Size = 48
mr_alsa_audio_pcm_hw_params (enter): rate=48000 format=32 channels=8 period_size=48, nb_periods=512
, buffer_bytes=589824
mr_alsa_audio_pcm_hw_params (playback): wrong nbPeriods (512 instead of 1024)...
mr_alsa_audio_pcm_hw_params done: rate=48000 format=32 channels=8 period_size=48, nb_periods=512
, buffer_bytes=589824
entering mr_alsa_audio_pcm_prepare (substream name=subdevice #0 #0) ...
mr_alsa_audio_pcm_prepare: rate=48000 format=32 channels=8 period_size=48, nb periods=512
mr_alsa_audio_pcm_prepare for playback stream
Leaving mr_alsa_audio_pcm_prepare..
entering mr_alsa_audio_pcm_trigger (substream name=subdevice #0 #0) ...
mr_alsa_audio_pcm_trigger(Start), rate=48000 format=32 channels=8 period_size=48
starting playback I/O
entering mr_alsa_audio_pcm_trigger (substream name=subdevice #0 #0) ...
mr_alsa_audio_pcm_trigger(Stop), rate=48000 format=32 channels=8 period_size=48
stopping playback I/O
entering mr_alsa_audio_pcm_hw_free (substream name=subdevice #0 #0) ...
entering mr_alsa_audio_pcm_close (substream name=subdevice #0 #0) ...
�

when I start Ardour :

entering mr_alsa_audio_pcm_open (substream name=subdevice #0 #0) ...

Current PTPFrame Size = 48
entering mr_alsa_audio_pcm_open (substream name=subdevice #0 #0) ...

Current PTPFrame Size = 48
mr_alsa_audio_pcm_hw_params (enter): rate=48000 format=10 channels=128 period_size=48, nb_periods=32
, buffer_bytes=786432
mr_alsa_audio_pcm_hw_params (capture): wrong nbPeriods (32 instead of 1024)...
mr_alsa_audio_pcm_hw_params done: rate=48000 format=10 channels=128 period_size=48, nb_periods=32
, buffer_bytes=786432
entering mr_alsa_audio_pcm_prepare (substream name=subdevice #0 #0) ...
mr_alsa_audio_pcm_prepare: rate=48000 format=10 channels=128 period_size=48, nb periods=32
mr_alsa_audio_pcm_prepare for capture stream
Leaving mr_alsa_audio_pcm_prepare..
mr_alsa_audio_pcm_hw_params (enter): rate=48000 format=10 channels=128 period_size=48, nb_periods=32
, buffer_bytes=786432
mr_alsa_audio_pcm_hw_params (playback): wrong nbPeriods (32 instead of 1024)...
mr_alsa_audio_pcm_hw_params done: rate=48000 format=10 channels=128 period_size=48, nb_periods=32
, buffer_bytes=786432
entering mr_alsa_audio_pcm_prepare (substream name=subdevice #0 #0) ...
mr_alsa_audio_pcm_prepare: rate=48000 format=10 channels=128 period_size=48, nb periods=32
mr_alsa_audio_pcm_prepare for playback stream
Leaving mr_alsa_audio_pcm_prepare..
entering mr_alsa_audio_pcm_trigger (substream name=subdevice #0 #0) ...
mr_alsa_audio_pcm_trigger(Start), rate=48000 format=10 channels=128 period_size=48
starting capture I/O
entering mr_alsa_audio_pcm_trigger (substream name=subdevice #0 #0) ...
mr_alsa_audio_pcm_trigger(Start), rate=48000 format=10 channels=128 period_size=48
starting playback I/O
Uninterleaved Playback is not supported
Uninterleaved Playback is not supported
Uninterleaved Playback is not supported
Uninterleaved Playback is not supported

and so on until I close it....

When I start Bitwig Studio:

entering mr_alsa_audio_pcm_open (substream name=subdevice #0 #0) ...

Current PTPFrame Size = 48
entering mr_alsa_audio_pcm_close (substream name=subdevice #0 #0) ...
entering mr_alsa_audio_pcm_open (substream name=subdevice #0 #0) ...

Current PTPFrame Size = 48
entering mr_alsa_audio_pcm_close (substream name=subdevice #0 #0) ...
entering mr_alsa_audio_pcm_open (substream name=subdevice #0 #0) ...

Current PTPFrame Size = 48
mr_alsa_audio_pcm_hw_params (enter): rate=48000 format=10 channels=128 period_size=48, nb_periods=1024
, buffer_bytes=25165824
mr_alsa_audio_pcm_hw_params done: rate=48000 format=10 channels=128 period_size=48, nb_periods=1024
, buffer_bytes=25165824
entering mr_alsa_audio_pcm_prepare (substream name=subdevice #0 #0) ...
mr_alsa_audio_pcm_prepare: rate=48000 format=10 channels=128 period_size=48, nb periods=1024
mr_alsa_audio_pcm_prepare for capture stream
Leaving mr_alsa_audio_pcm_prepare..
entering mr_alsa_audio_pcm_open (substream name=subdevice #0 #0) ...

when I start jack (jackd -d alsa -d hw:RAVENNA -p 48 -n 1024 -o 2 -P):

entering mr_alsa_audio_pcm_open (substream name=subdevice #0 #0) ...

Current PTPFrame Size = 48
mr_alsa_audio_pcm_hw_params (enter): rate=48000 format=10 channels=2 period_size=48, nb_periods=1024
, buffer_bytes=393216
mr_alsa_audio_pcm_hw_params done: rate=48000 format=10 channels=2 period_size=48, nb_periods=1024
, buffer_bytes=393216
entering mr_alsa_audio_pcm_prepare (substream name=subdevice #0 #0) ...
mr_alsa_audio_pcm_prepare: rate=48000 format=10 channels=2 period_size=48, nb periods=1024
mr_alsa_audio_pcm_prepare for playback stream
Leaving mr_alsa_audio_pcm_prepare..
entering mr_alsa_audio_pcm_prepare (substream name=subdevice #0 #0) ...
mr_alsa_audio_pcm_prepare: rate=48000 format=10 channels=2 period_size=48, nb periods=1024
mr_alsa_audio_pcm_prepare for playback stream
Leaving mr_alsa_audio_pcm_prepare..
entering mr_alsa_audio_pcm_trigger (substream name=subdevice #0 #0) ...
mr_alsa_audio_pcm_trigger(Start), rate=48000 format=10 channels=2 period_size=48
starting playback I/O
Uninterleaved Playback is not supported
Uninterleaved Playback is not supported
Uninterleaved Playback is not supported
�

like Ardour this line until I close it....

Hope this could be useful...

cheers
Guido

from aes67-linux-daemon.

Hi guys,
I think that if you can make the daemon compatible with Jack, you open the world to any DAW to Dante/AES67 on Linux! :-)
here another test: Reaper.
kernel log:
entering mr_alsa_audio_pcm_open (substream name=subdevice #0 #0) ...
Current PTPFrame Size = 48
entering mr_alsa_audio_pcm_close (substream name=subdevice #0 #0) ...

But Reaper stops with attached error:

What do you think about that?

Have a nice weekend

Guido

from aes67-linux-daemon.

"you open the world to any DAW to Dante/AES67 on Linux! "

Indeed, which is what prompted my earlier question about how others are using this driver now. Obviously not for music production, which is how the Merging Ravenna driver is typically used on Windows (for example with the Merging Hapi or Horus converters). The original version of the driver did not even support memory mapped mode, I don't think it was being used for anything except maybe audio player appliances which run embedded linux and play files to the Merging NDAC. Obviously not with a DAW.

"What do you think about [Reaper error]"

I think Reaper is trying to set a particular period size and is not able to. That settings window shows a block size of 64, but in AES67 mode the driver will be running at a block size of 48. Does Reaper allow setting a block size of 48?

from aes67-linux-daemon.

Does Reaper allow setting a block size of 48?

Unfortunately not, only 16,32,64,128.....

from aes67-linux-daemon.

Does the driver have a mechanism to query supported modes? If an application attempts to determine whether the driver supports non-interleaved mode is there an ALSA API to return that information?

The unsupported access mode issue may occur because the driver improperly advertises the access mode
SNDRV_PCM_INFO_NONINTERLEAVED that is actually unsupported.
Can you apply the following patch and retry the test with jackd ?

--- a/driver/audio_driver.c
+++ b/driver/audio_driver.c
@@ -1061,7 +1061,7 @@ static struct snd_pcm_hardware mr_alsa_audio_pcm_hardware_playback =
 {
     .info =     (   SNDRV_PCM_INFO_MMAP | /* hardware supports mmap */
                     SNDRV_PCM_INFO_INTERLEAVED |
-                    SNDRV_PCM_INFO_NONINTERLEAVED | /* channels are not interleaved */
+                    /*SNDRV_PCM_INFO_NONINTERLEAVED |  channels are not interleaved */
                     SNDRV_PCM_INFO_BLOCK_TRANSFER | /* hardware transfer block of samples */
                     SNDRV_PCM_INFO_JOINT_DUPLEX |
                     SNDRV_PCM_INFO_PAUSE | /* pause ioctl is supported */

from aes67-linux-daemon.

Does Reaper allow setting a block size of 48?

Unfortunately not, only 16,32,64,128.....

The driver only supports periods that are a multiple of the base period size. This base period is configurable and in your configuration (and in the default configuration) is set to 48 samples (1ms @ 48Khz).
Just try to change the parameter tic_frame_size_at_1fs in the daemon.conf to 64 and afterwards you should be able to use a period of 64 as block size of the Repeater.
In any case I don't recomment setting periods shorter than 48.

from aes67-linux-daemon.

I assumed that tic_frame_size_at_1fs is the number of samples per network packet, but how is max_tic_frame_size defined? Is that the largest number of samples per packet which may be configured? I could not find the acronym "TIC" defined anywhere in the Ravenna Operating Principles document or AES67-2018.

I will try the patch that removes advertising non-interleaved mode later today. The software should support interleaved, but it needs accurate information that interleaved mode is required, it will attempt to use non-interleaved mode first.
The latest Ardour git head includes support for forcing interleaved mode, and also for non-power-of-2 buffer sizes, so I will check that as well.

"you should be able to use a period of 64 as block size"

Yes, but if connecting to a Dante device in AES67 mode I believe that only 48 sample block size is supported. The documentation from Audinate instructs to set the size to 48 samples and does not mention other sizes supported in AES67 mode (although a wide range of block sizes are supported in native Dante mode). A native Ravenna device should also support a wide range of block sizes, but those are less common than Dante devices, at least on the west side of the Atlantic.
I would be happy to test with a Merging Hapi if someone wants to gift or long term loan a device to me. :)

from aes67-linux-daemon.

I assumed that tic_frame_size_at_1fs is the number of samples per network packet

No, this global setting is used to determine the driver base timer period as explained previously. At each tick the driver processes PTP sync, all incoming RTP packets and schedule the outgoing RTP packets.

The number of samples per network packet is defined for each configured Source by the parameter "Max samples per packet" "max_samples_per_packet" of a source.

Please consider that the WebUI is not able to visualize a tic_frame_size_at_1fs of 64 in the Config tab, still this is a working configuration and you can also define Sources with 1ms packet duration.

from aes67-linux-daemon.

Hi Andrea,
After patching and recompiled the driver, I successfully opened jackd and played with bitwig studio and Ardour!
There was lot of latency, but reducing the -n parameter in jackd it was completely removed!
I listened the flow with another computer with a Daemon, but tomorrow at the office I will try to listen to with an MRX-7D Yamaha...
Thanks a lot for your great work!

from aes67-linux-daemon.

Hi Guido,
thanks for testing and for all the debugging info!
Obviously with a tic_frame_size_at_1fs set to 64 we have a slightly higher latency (about 1.3ms @ 48Khz) but we are still compatible with Dante devices and we also get compatibility with JACK.
I will push the changes to the repos soon including also adding support for more tic_frame_size to the WebUI.

from aes67-linux-daemon.

See 35f7772 and bondagit/ravenna-alsa-lkm@3359098

from aes67-linux-daemon.

The README.md file in the Merging directory (top of 3rdparty/ravenna-alsa-lkm) has this note:

ALSA Features

• 1FS to 8FS support
• PCM up to 384kHz
• Native DSD support (64/128/256) in playback only (DOP not supported)
• Interleaved and non-interleaved** 16/24/32 bit integer formats

Is that note not correct? Are we sure that non-interleaved mode is actually not supported, or does it just have errors?

from aes67-linux-daemon.

As far as I can see the driver playback and capture copy functions do not implement the transfer for the non interleaved mode.
In addition to this we don't actually need it but the driver capabilities have to be declared correctly.

from aes67-linux-daemon.

Please consider that the WebUI is not able to visualize a tic_frame_size_at_1fs of 64 in
the Config tab, still this is a working configuration and you can also define Sources with
1ms packet duration.

I find that the Sources tab does not allow setting a source with 64 samples per packet even when the TIC frame size is configured as 64. I configured a source with 48 samples per packet so that I could see the correct format in status.json, stopped the daemon, edited the status.json file to use 64 as the samples per packet for the previously configured source, then restarted the daemon. When the daemon was restarted the previously configured source was not used, the configuration was back to no source or sink defined.

After patching and recompiled the driver, I successfully opened jackd and played with bitwig studio and Ardour!

keegee, was that only with the patch which removed advertising non-interleaved mode, or did you also set the frame size to 64 instead of 48? How did you configure the source for 64, and did your Yamaha processor have any problem using that?

from aes67-linux-daemon.

Hi all,
I made many tests with different systems and kernels, some realtime patched some not, with Yamaha Dante devices and between daemons, with different DAW...
Results are different, but I made the tests in spare time at work so very confusing....
Hope to make a decent spreadsheet with results in near future and share with you....
Cheers
Guido

from aes67-linux-daemon.

I find that the Sources tab does not allow setting a source with 64 samples per packet even when the TIC frame size is configured as 64

You don't need to set the Source to 64 samples per packet. This setting is not supported by most of the devices and not even recommended by AES67.
You have to patch the driver to disable non-interlvaed mode, set the TIC frame size to 64 in oder for JACK to be able to use 64 period size and use a Source with 48 samples per packets.
And yes, I have tested these setting with a Dante device I have here and that wrorks as well.

from aes67-linux-daemon.