We have a report of the Linux client PulseAudio crashes with: pulseaudio[E]: pulseaudio: pcm.c:3050: snd_pcm_area_copy: Assertion 'src < dst || src >= dst + bytes' failed pcm.c is from alsa-utils rather than PulseAudio. This problem is discussed here: http://mailman.alsa-project.org/pipermail/alsa-devel/2016-June/108915.html From http://mailman.alsa-project.org/pipermail/alsa-devel/2016-June/109749.html: "Now I reread the code again, and I guess it's really the racy accesses. Basically you can't call alsa-lib functions concurrently. For example, calling snd_pcm_avail_update() from multiple threads concurrently may lead to such an error. Internally it copies / converts the content (e.g. for softvol plugin), and this would conflict when called in parallel." Thus, even though the assert is in ALSA, it could be that the problem is in PulseAudio, which we ship.
Found this report: https://bugs.freedesktop.org/show_bug.cgi?id=64299 They seem to think that this is a problem in ALSA after all, and refers to: http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=f2d39afe6139ab16aa2aeea0f51f32db79ab1262 This fix is in alsa-libs v1.0.27.2 and later.
Customer claims to be using alsa-libs 1.1.3-1.
I tested ALSA on my Fedora 28 workstation (alsa-lib 1.1.6) without issues. What I did was: * remove /etc/alsa/conf.d/99-pulseaudio-default.conf * run: pasuspender tlclient * configure the client to use ALSA Audio played without issues, and no errors in the log. So it doesn't seem to be a general ALSA issue.
We've seen this before in bug 6966, but couldn't reproduce it then either.
Another upstream fix for ALSA: https://www.alsa-project.org/pipermail/alsa-devel/2017-February/118007.html And Fedora did a patch for an issue like this: https://bugzilla.redhat.com/show_bug.cgi?id=953352 Ubuntu also has a report, that seems to have been automatically closed because of no more reports: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1690031
Could reliably reproduce this on our eLux RP machine just now: Client OS: eLux RP 5.7.300 Client ALSA version: 1.1.0.4 ThinLinc client: 4.11.0rc1 (build 6323) However, after seeing this problem we downgraded the ThinLinc client to 4.8 to see if it was a regression. After this point we could no longer reproduce the issue again, even upgrading back to 4.11.0rc1. It seems like this is caused by something more subtle. Perhaps it has something to do with how the OS is installed. In the state where we could see the bug eLux RP was just upgraded from 5.6 to 5.7. Looking at bug 6966 I would guess that the initial report in there was also made just after having upgraded eLux RP.
