Changing Sampling Rate doesn't affect outgoing SDP about aes67-linux-daemon HOT 7 CLOSED

Thanks for your message. I am working on this project for fun during my spare time. I am currently adding mDNS support via Avahi to be able to browse RTSP announced sources too and I will release this soon.

Returning to your problem I cannot reproduce it. If I change the sample rate in the daemon config on the WebUI and, after applying the modification, I check the sources in the Source tab the associated SDP file is updated to the new sample rate. Same happens to the sources announced via SAP.
If instead you mean the sample rate reported in a sink SDP, this needs to be updated manually or you can re-fetch it by deselecting the Use SDP flag and re-using the Source URL.
At present the sink SDP is collected at creation time and it's not automatically updated. The reason for this is that the sink SDP usually belongs to a non local source.

Finally please consider that the sample rate can be also dinamically changed by the driver.
So for example if you request a playback at 44.1Khz on the RAVENNA ALSA device and you have the daemon configured at 48Khz all the sources get updated to 44.1Khz to reflect this change but not the sinks SDP.

from aes67-linux-daemon.

Well, I tried to debug this. Couldn't reproduce it with the debugger. Adding print statements made the problem unreproducible as well. Even without the print statements, sometimes it takes many runs to hit it. Other times it happens every time. The bug seems to be related to timing, like a race condition. The one big change I made to the configuration which may be necessary to reproduce it is a sap interval of 10secs. I built this on 18.05 x86_64. I'll try and nail down a configuration that seems to be reliable, for me at least.
I understand if you don't want to waste time on this one as it might be a big time suck for little gain.
Other observations are that I have experienced stability issues (crashing etc. so obviously the driver) and I've had trouble getting a multichannel loopback (8ch in/out) to work. The output seems to just go away. I get SEQID,SAC receive errors. The source is solid (Lawo). It might be my switch as I'm at home and working with a cheap switch instead of an Arista at work. BTW Is there a reason you didn't support 125us packet time? This just happens to be very important for the broadcast industry as its used for all channel counts above 8 (SMPTE ST 2110-30).

from aes67-linux-daemon.

1. About the instability and the sample rate change problems
   According to the description you provided (driver instability plus sample rate change at runtime) I suspect you have troubles related to the PulseAudio usage. PulseAudio indeed tries to take control over all the audio devices keeping them busy. It is currently included in almost all Ubuntu distributions I tested so far and you need to disable it before using the aes67-daemon.
   To check if PulseAudio is running on your system run the following command:
   > ps ax | grep pulseaudio
   In case it’s running considering one of these two solutions and reboot the system afterwards:
   • Uninstall it completely with:
   > sudo apt-get remove pulseaudio
   • Disable it by renaming the executable with:
   > sudo mv /usr/bin/pulseaudio /usr/bin/_pulseaudio
   According to my experience other graceful methods to disable PulseAudio may fail and just killing it is not enough since it gets immediately re-spawned.

2. About testing with 8 channels loopback setup
   I have tested an 8 channels setup on both x86 and ARMv7 platform and it works for me (1 source and 1 sink both configured with 8 channels).
   I have pushed a new branch named 8_channels_demo with a demo for this configuration.
   See https://github.com/bondagit/aes67-linux-daemon#demo for information about how to run the demo.
   Please let me know if this loopback configuration works for you.

3. 125us packet time is supported by the driver and I added with commit 71c0cc7 the support to the WebUI.

from aes67-linux-daemon.

Thanks for tip on Pulse audio. I missed that during installation. That fixed the general stability issues. I haven't seen any crashing since uninstalling it. I did see the source SDP still incorrect at 44.1kHz once so I don't think that issue is related to Pulse. It doesn't seem to happen that often now for some reason. Thanks for creating the 8ch branch. I was able to get the loop-back working on my setup by reconfiguring my network. I'm working from home on consumer Netgear switches and struggling for packet capacity. I'll try testing with 125us and more channels but I'll need a better switch.

from aes67-linux-daemon.

OK, thanks for the update. Should you perform additional tests I am interested to hear the results.
Returning to the sample rate change issue PulseAudio can actually be the source of the problem because when it tries to open the ALSA device it also causes the driver to change the sample rate.

from aes67-linux-daemon.

any update on this specific issue ? I cannot reproduce the problem and I'd like to close it.

from aes67-linux-daemon.

This problem occurs occasionally for me but it does not happen sufficiently frequently that it is a problem. I don't want to invest the time it would take to debug it on my system so I recommend this is closed until it goes away or becomes more frequent.

from aes67-linux-daemon.