audio interruptions in VLC after PulseAudio is used.

[beta-tester]

hi,

after PulseAudio is used as top layer for audio devices, VLC media player plays audio (and video) files with interruptions. each audio file (or video) in the playlist will start with up to four short interruptions (there are always at least two).

see here Pulseaudio and VLC?

the update that was published today (2020-12-07) pulseaudio (12.2-4+deb10u1+rpi2) did not fix that issue.

how to reproduce that issue:

1. full-upgrade your RPi.
2. open VLC media player
3. drag'n'drop the attached test-tone files to the playlist
4. o do not need to fill up the playlist with more files, i enabled the "loop all" or "loop one" option (on the bottom right toggle button group, the middle buttom of the group)

5. ---

6. start the playlist [>] - button (you will hear the test tone will stutter two or more times)
7. jump to the next or previous audio file [>>|] or [|<<] - button (you will hear the test tone will stutter two or more times)
8. switch between audio modes in VLC: Audio | Stereo Mode | Left, Right, Mono, Stereo (you will hear the test tone will stutter two or more times at each switch)

9. ---

10. mute the audio in VLC and un-mute (you will not hear stuttering)
11. pause and continue audio in VLC (you will not hear stuttering)

test-tone-1000Hz-and-1200Hz.zip

the same happens with video files in VLC media player. its audio is interrupted as well in the same way as audio files.

i tested on RPi4B (4GByte) and RPi3. i tested full-upgrade (2020-12-04 and 2020-12-07) an previous RPi OS version (2020-08-20) and the current RPi OS version (2020-12-02) all installations show up that issue. the RPi's are connected to a TV by using HDMI cable.

[beta-tester]

is there any progress here?

[spl237]

Have you heard of the concept of Christmas holidays, by any chance?

[spl237]

In the file /etc/pulse/daemon.conf, find the line

; default-fragment-size-msec = 25

Change this to

default-fragment-size-msec = 15

So remove the semicolon and space at the start, and change 25 to 15. This fixes the glitches you describe in VLC on my Pi4, but it is entirely possible that it will not have the same effect on all Pis, and might cause problems elsewhere, so if you could do some testing to confirm it is a valid fix, that would be helpful.

If you find that it doesn't fix the problem, try changing the value of this line to other values in the same sort of range. It might also be worth trying changing the default-fragments value in the line above if you continue to have problems. https://wiki.archlinux.org/index.php/PulseAudio/Troubleshooting#Glitches,_skips_or_crackling has some useful advice. There is also some technical info at https://forums.linuxmint.com/viewtopic.php?t=44862

[beta-tester]

hi Simon, thank you very much. yes, this parameter fix the issue in VLC. i tested this parameter default-fragment-size-msec = 15 in /etc/pulse/daemon.conf on RPi4B (4GB) and RPi3B. on both systems the issue is fixed.

and thank you for the links with the technical background.

now i can enjoy my christmas gift - listening my new audiobooks.

[spl237]

Great - thanks for testing; I'll try to get this change added to the default configuration for the next release of pulse in that case.

[beta-tester]

sorry, maybe it is not the perfect solution.

the glitch at the beginning of the audio files is gone with the parameter. but after hours listening audio files of playlists in VLC, i could hear some glitches in the middle of audio files randomly of about 3...7seconds. i could not see any big CPU load or bigger disk io at that time the glitches happened. i can seek back and play the audio file again, but then the glitch does not happen again (or at least not at the same position).

i will reboot the system and play a playlist again... i will inform you, when i see that behavior again.

[spl237]

Try reducing the fragment size a bit more. The theoretical value according to the calculation on the webpage above should be 2 ms, but that is far too small. 5 is too small and causes distortion, but 8 to 10 sounds ok on my system.

Try 10ms and see if it makes a difference. If not, drop it to 8ms.

[spl237]

Actually, thinking about it overnight, the calculations on the link above are wrong; they assume the buffer sizes are quoted in bits, which seems unlikely. If they are quoted in bytes, as seems more likely, then 15 is pretty much exactly the correct value to use for the fragment size.

A glitch of several seconds which only occurs infrequently sounds more likely to be an HDMI handshake occuring randomly; these happen on my Sony TV from time to time when it updates the EPG, and at this point, all audio in my system drops out for a few seconds. Unfortunately, such problems are difficult to repeat, and hence hard to diagnose and fix.

[beta-tester]

thank you for still being present...

maybe it was only a "hickup" yesterday... after rebooting my system and run the playlist again, that glitch did not happen again (up to now, ~4h without glitches). i am still on value 15 of that parameter. i will continue with playing and listening playlists.

with the HDMI handshake, is there a log file that shows these kind of issues? is there an option i can enable to do verbose logging to see when of if it happened?

[spl237]

The HDMI handshake issue is in the output device - your monitor or TV - rather than in the Pi, so the Pi won't log it. I'm not aware of a way of reliably checking that that is what has happened, but the symptom you describe - very intermittent dropout lasting 3-5 seconds over an HDMI connection - is exactly the effect of an HDMI renegotiation; the fact that you haven't been able to repeat it makes me strongly suspect that is what it is. If there was something fundamentally glitchy in Pulse, I'd expect it to show up in a 4 hour test. If nothing else, it sounds as if the 15 msec fragment size is right, so I'll push that in the next update.

[beta-tester]

ok, thank you for your help.

[RaNo99]

Hey guys, thanks for this discussion and for providing the solution for the VLC issue. It worked in my case, too (Pi 3A+). Shouldn't this change be somehow promoted to the default VLC configuration for Pi, if 15 ms is really the recommended calculated value?

[spl237]

It's being pushed out in an apt update to the default Pulseaudio configuration this week.

[RaNo99]

Great!

[beta-tester]

around the 2021-01-07 / 08 the fix arrived via apt update / upgrade. thank you very much.