Fallback to only one channel on reconfiguration or daemon restarts

[flycam]

First of all, I really appreciate this project.
I have noticed a strange fallback to only one channel (the first alsa channel on the system) transmitting or receiving audio after streams are reconfigured, the daemon is restarted or the network cable was unplugged and an audio application restarted. Most of the time I was able to fix it by stopping everything and reloading the kernel module. Observed both on bondagit-1.2 and 1.3 on:

• x86 (debian sid)
• banana pro (armbian focal)
• rpi 4 (raspbian minimal)

PTP GM and Streaming partner is a Lawo A__digital8.

The test ran fine on those systems, but since it loads the kernel module fresh, it doesn't catch this condition.

Only audio on the first channel of the system i/o (alsa) is played/transmitted. Mapping other channels leads to silence.
I can later do some more tests with more verbose logging - I just want to get the conversation started.

[bondagit]

it seems like you can reproduce the problem systematically in different conditions and this is good.
Can you please describe the steps required to reproduce the problem, at least for one use case ?

[flycam]

I've tried to force it using the test, but failed int the simple setups so far.
While trying to reproduce it in a clean install (and new pi) using speaker-test, I found out my alsa config is part of the problem. As I need to resample audio (rest of the setup is 48kHz), I use a dmix to set the ravenna sample rate to 48kHz and also provide more than one stereo output for software.
The easiest war for me to reproduce is on my raspotify-player:

load kernel module
start aes67-daemon
(re-)start raspotify (or speaker-test) outputing to the plugdevice (plug:aes67_1)
start audio playback
stop aes67-daemon
start aes67 daemon
restart raspotify & playback (as it hangs) (or speaker-test)
audio only on first channel.

/etc/asound.conf
`pcm.aes67_1 {
type dmix
ipc_key 0x11111
slave {
pcm "hw:CARD=RAVENNA"
channels 8
rate 48000
format S24_3LE
}
bindings { 0 0 1 1 }
hint.description "AES67_1"
}

pcm.aes67_2 {
type dmix
ipc_key 0x11111
slave {
pcm "hw:CARD=RAVENNA"
channels 8
rate 48000
format S24_3LE
}
bindings { 0 2 1 3 }
hint.description "AES67_2"
}`

I've also tried a different version from https://wiki.ubuntuusers.de/.asoundrc/ (last example, replaced usb-name with RAVENNA), same result.

It's also reproducible with speaker-test and the above asound.conf.
speaker-test -c 2 -F S24_3LE -l 0 -D plug:aes67_1

if I then tried speaker-test with the device hw:RAVENNA, output was the same for both channels (left and right).
I was also sometimes able to get it into a working state again by changing the alsa config (ex. remove channel count, restart player, add channel count back in) and restarting the player.

[bondagit]

I can reproduce the issue but the problem doesn't show up if you stop the player before restarting the daemon.
Also, In your/etc/asound.conf add buffer_size 4096 to the two entries.

[bondagit]

Good news. The issue was in the driver and it was fixed in branch aes67-daemon-issue-55
To test it got to the driver folder, recompile and reinstall the module:

cd 3rdparty/ravenna-alsa-lkm
git pull origin aes67-daemon-issue-55
cd driver
make
sudo rmmod MergingRavennaALSA
sudo insmod ./MergingRavennaALSA.ko

Please let me know if this works for you and I will merge it back to master with driver 1.4

[flycam]

Tested on ARMv71 and x86, sounds good, with stereo and 8 ch streams.

deamon restarts while playing - player might misbehave, but fine after restart.
stream reconfiguration (modifyng active, adding new) - no problem/changes
Network cable disconnect - comes back fine after some wait.

(Your obeservation of the problem ocurring only when the player is running explains what I saw)

Thank you for the very fast fix, this eases experimentation a lot.

Thanks for the buffer size suggestion.

[bondagit]

I found the same issue for the capture device too and fixed it in the same branch.
Regarding the buffer_size set to 4096 this is just a suggestion you can probably configure a smaller one by checking if you have underruns.
I will merge these fixes into the end_to_end_latency branch (see #53 ) and release the driver 1.4 when ready.

[bondagit]

changes to the Ravenna driver merged to driver aes67-daemon branch