When using this audio driver on a system with pulseaudio and realtime-scheduling = yes in /etc/pulse/daemon.conf (the default on many distros), it is necessary to increase the rlimit-rttime value from its default of 200000 microseconds, presumably because of some calls to driver code taking much longer than in other audio drivers.
Not doing so causes pulseaudio to get killed by the kernel due to exceeding the amount of time it's allowed to spend scheduled with realtime priority without yielding. (This is likely to be experienced by the user as pulseaudio repeatedly restarting, since systemd will probably restart it immediately.)
I tested the same laptop with a variety of USB audio devices, with an otherwise identical pulseaudio config, and was able to use the default of 200000 microseconds with all of these without issues.
A configuration that works for me involves adding this line to /etc/pulse/daemon.conf:
rlimit-rttime = 3200000
This value (3.2 seconds) was found by repeatedly doubling until the issue no longer happened. It is excessively high and it would be good to find out why this driver blocks for so long where other drivers don't.
When using this audio driver on a system with pulseaudio and
realtime-scheduling = yesin/etc/pulse/daemon.conf(the default on many distros), it is necessary to increase therlimit-rttimevalue from its default of 200000 microseconds, presumably because of some calls to driver code taking much longer than in other audio drivers.Not doing so causes pulseaudio to get killed by the kernel due to exceeding the amount of time it's allowed to spend scheduled with realtime priority without yielding. (This is likely to be experienced by the user as pulseaudio repeatedly restarting, since systemd will probably restart it immediately.)
I tested the same laptop with a variety of USB audio devices, with an otherwise identical pulseaudio config, and was able to use the default of 200000 microseconds with all of these without issues.
A configuration that works for me involves adding this line to
/etc/pulse/daemon.conf:This value (3.2 seconds) was found by repeatedly doubling until the issue no longer happened. It is excessively high and it would be good to find out why this driver blocks for so long where other drivers don't.