Can a sink write data directly to an another ALSA device

[vvv-ca]

Hi,

I'm trying to stream directly to my USB DAC using Ravenna source and sink. Is there any way to configure the Ravenna sink to write the data directly to another ALSA device (the USB DAC)? It looks like the IO parameter could exist for that reason?

Thanks!

[nicolassturmel]

Hi, Looks like you want to link two devices (the USB Alsa driver and the AES67 driver), alsaloop may be useful for this: http://manpages.ubuntu.com/manpages/trusty/man1/alsaloop.1.html

N.

[vvv-ca]

I tried alsaloop, The problem is that it stops when there is no input and you have to restart it on every rate change. And it introduces additional buffers and thus delay in the chain. So I will have to write another program to monitor the aes67 sink, detect start/stop/rate/format/etc info and then start/stop/restart alsaloop and monitor it for crashes. I also looked into jackd - that seems to be able to handle more out of the box but it seems overkill for a basic data copy between buffers. Maybe I would need to write a custom app to do this. Thanks!

[philhartung]

Hi, The goal of this AES67 alsa driver is certainly not to monitor a AES67 stream directly. If you want minimum latency, you should play back the AES67 stream directly to the USB soundcard. You can do this with gstreamer for example:

gst-launch-1.0 udpsrc address=239.69.161.58 port=5004 multicast-iface=eth0 !\
    application/x-rtp, clock-rate=48000, channels=2 !\
    rtpjitterbuffer latency=48 !\
    rtpL24depay !\
    audio/x-raw, format=S24BE, channels=2, rate=48000 !\
    alsasink sync=false

As far as I know dedicated open source software to monitor AES67 streams doesn't yet exists (The only commercial solution I know of is the LAWO AoIP Stream Monitor and it's windows only). Though with gstreamer and some python coding, this could easily be achieved.

[nicolassturmel]

You have that too, but I have not yet tested https://github.com/martim01/pam

[bondagit]

Hi @vvv-ca , I also suggest you to use alsaloop. I have been testing with it for a while and I can keep a stable stream running for hours. The advantage of using the AES67 daemon Sources and Sinks is that the driver handles properly the synchronization with the PTP master clock. Despite this alsaloop of course will add some configurable latency. One thing you have to consider when using alsaloop is the clock drift between the capture and playback device and how to keep them in sync. Fortunately it looks like alsaloop has also an option to handle this (see option -S) . So for example, I am receiving an audio stream from a Dante device via a daemon Sink and playing it on my local sound card with:

alsaloop -C plughw:RAVENNA -P hw:0,0 -c 2 -r 48000 -v -f S32_LE -d -S 3

This is running stable for hours in my setup and the latency seems acceptable.

What do you mean with detecting start/stop ? Even in the event the RTP stream is not active at all the driver continues to work properly injecting samples with silence in the capture device. So I don't need to detect such events. Rate and sample format changes instead require a Source reconfiguration and these events are under control and they usually require in any case a Sync reconfiguration (SDP file gets updated) and a capture restart.

Finally regarding jackd I think this is a valid option that is worth to investigate. Especially now that the driver implements direct PCM transfer mode and jackd should also work properly.

[bondagit]

So returning to your original question the answer is no ;-) Use alsaloop or Jack to bridge the audio from/to the Ravenna virtual device to another audio device.

[vvv-ca]

Thanks for the replies! What I am looking for is to essentially have a remote AES67 ALSA source drive an audio card/DAC and play any supported format. The infrastructure seems to be there and I need to test if the Ravenna Butler has implemented it. The basic flow is: a process starts writing audio data to a daemon source. The source signals the daemon that there is a rate/format/etc change. The daemon re-configures the SDP with the new data and (potentially) signals (or the sinks monitor the stream state) all the associated sinks to start playback. The remote sinks notify the associated hardware about the rate/format/etc change and start playback. When the remote process stops playback, the daemon source would notify the daemon to take the necessary steps to stop the associated sinks. I see that the Ravenna driver has calls for all of the above in the manager.h and if you look in the audio_driver.c you would notice some left overs for NADAC controls which I suspect handle the sink to device communication I'm looking for.