PA - snd_pcm_avail() returned a value that is exceptionally large #68
Comments
perexg
changed the title
|
bug.txt |
|
This started occurring to me as well, on a system (Kubuntu 20.10 on Lenovo ThinkPad T420s) where my configuration of both ALSA and Pulseaudio has been rock solid for years. Does anyone have an idea of how to approach debugging it? |
|
The PA check is not 100%. The real time measurement is missing, so it may be possible, that there's a task scheduling glitch (gap). This suggest also the log in the second comment which clearly identifies that the system is too much busy:
PA disables the stream stop (see stop_threshold) settings in the kernel, thus this situation may occur. Discuss this with PA developers. EDIT: Add @tanuk for the discussion. |
|
Maybe we shouldn't tell users to report these problems to the ALSA developers if they are not actionable, or have those reports ever resulted in any kernel driver fixes? |
|
The problem with those redirections is that there are many false-positive reports (they are here, in kernel bugzilla and ocassionally on the alsa-devel mailing list). If PA does not measure the real time for the ALSA calls, the behaviour is correct when the system is overloaded (no real time processing). I suggest to print the error (or warning) and add the real time measurement (to exclude /or report/ the scheduler problems) when PA runs in the debug mode without the redirection. The drivers are more stable than they were a decade ago. |
|
I created this issue for PulseAudio: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1078 |
|
It has happened to me again even without that I use Audacious a lot and had the buffer at 1000ms, that gave me a very high latency so the solution I had was to put tsched=0 in /etc/pulse/default.pa, I just read that the Intel seem to work better with tsched. I have left it as it comes and in Audacious the buffer at least 100ms now it seems that the latency is correct again I don't know if tsched could be related to the error |
|
My laptop just froze for the second time in a few days. This time I checked the syslog and found the same message, which brought me here. Just to be sure I understand correctly, this is a WONTFIX because the issue reported by this message is caused by some latency issue but is not necessarily an issue in ALSA itself, right? I don't find any other lead in the syslog, so I can't do much more. Should I report this to my distro (Debian)? Is there even a point doing so? |
|
I finally disabled tsched=0 and with the latest kernel and Nvidia updates and removing the Xfwm4 compositor options.
I did not get this error and the laptop keyboard did not start up again. I don't really know how it all relates but with this configuration it has been working fine for months now and in /etc/default/grub |
I hope this is the right place to report this. This occurred in relation to a crash.
http://alsa-project.org/db/?f=52e8505d884682fc06adac4ab8ce92a4ca3e0870
The text was updated successfully, but these errors were encountered: