clapper
clapper copied to clipboard
Rafostar
Audio crackling while adjusting volume during playback
This might earn a not-my-bug label or end up on #35, but in any case I think it is worth recording here.
I am running the latest flatpak builds 0.4.0 from flathub on both x86_64 (Ubuntu 20.04) and on aarch64 (Manjaro 21.08),
and when the volume is adjusted during playback I hear crackling, on aarch64 the cracklings is much worse,
while on x86_64 it's also a bit unpleasant.
So far I was not able to reproduce this cracling with other audio players on any of these setups, but I am open for suggestions.
Well, this issue isn't known as I cannot reproduce it on neither of 3 PCs where I have Clapper installed. Please provide a little more info about which sound server you are using. PulseAudio? Was it (pulseaudio) default config tinkered? Does this happen with different videos and different audio decoders or only one, if only one then which one (decoder name is in audio track selection popover)? Also, could you try temporarily installing one of the recent Flatpak Nightly builds from this github actions page, to check if this wasn't already fixed somewhere?
The x86_64 Ubuntu machine has Pulseaudio 13.99.1
The aarch64 Manjaro has Pulseaudio 15.0.
I personally haven't tinkered with the default config, everything should be as it is in the distro packages.
I mainly noticed, that with the avdec_aac decoder and MPEG 4 AAC audio streams,
and now that you mentioned I tried out a few samples and I realized,
that even if the decoder avdec_aac and the media properties MPEG 4 AAC 44100 Hz 32 bits samping remain the same,
the cracling happens with certain videos, and with others it doesn't.
I have also tested the x86_64 Flatpak Nightly from here: https://github.com/Rafostar/clapper/suites/3940740754/artifacts/98776772 but there was no change.
But I haven't noticed any change.
The difference between my aarch64 and x86_64 is pretty big, on aarch64 actually any video that one can find on youtube would be enough for reproducing (at least on my side), but for x86_64 it's more difficult to find a sample for reproducing it,
but I could try to collect some.
As you mentioned this is probably not my bug, as unlike video rendering, audio is handled elsewhere entirely. I am willing to help with the playback related issues, but I would need a way to reproduce this on my machine first. If you could provide a sample that reproduces this on x64 reliably, that would help.
Since you mentioned that this mainly happens with avdec_aac, please try if this also happens with FDK AAC (fdkaacdec), this way we should be able to tell if this issue is inside decoder or somewhere else at least. It can be enabled in app preferences plugin ranking page. Apply some high rank to it like 300 and restart the player for changes to be applied, confirm which decoder is being used in audio track select popover button.
One sample for x86_64 where I can reliably reproduce with avdec_aac is this one:
https://www.youtube.com/watch?v=K7eu5dBgN3g
Seek to roughly 00:31, hit play and use the graphical slider to quickly change the volume back and forth between 50% and 150%, and keep doing that as the playback goes on to 00:33 and beyond.
This is also noticable with fdkaacdec, at least on my side.
I repeated these tests with a decent pair of AudioTechnica headphones, but also with the cheapest headset from AliExpress, with laptop speakers, directly from the Jack outlet and also via HDMI, and so far the crackling was consistent.
Seek to roughly 00:31, hit play and use the graphical slider to quickly change the volume back and forth between 50% and 150%, and keep doing that as the playback goes on to 00:33
When using speakers test video you provided, while changing volume slider value VERY quickly when continuous "beep" plays, I could hear a slight crackling, yes.
I tried looking at the gstreamer plusesink logs, but it did not report any lost audio buffers. I also tried this sample with few other video players (including VLC, Celluloid) which do not even use gstreamer. I could reproduce the exact same "crackling" issue in ALL of them. This most likely indicates, that PulseAudio has problems/sub-optimal audio rewinding code, in which case this would be an upstream bug you are looking for: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/929
You are right, the sample I provided is pretty useless for demonstrating any difference on x86_64, as compared to other players there is nothing noticable. I only realised that after you pointed it out.
On my first aarch64 test device, I am still under the impression, that compared to, for example lollypop (which is also gstreamer based) the crackling is on a noticably different level.
It is still likely someone else's bug, but I suspect, that lollypop somehow avoids it or works around it.
First I shall compare at least two aarch64 devices on different OSs against each other, and see if I see some correlation,
or if I can narrow the issue down a bit.
Well, since I reproduced it in every video player on x64, I cannot really call it a Clapper (or gstreamer) bug. I know that there are at least few people with PinePhones (its an aarch64 phone device) sometimes hanging around on Clapper matrix channel. Maybe they might have some tips for aarch64 specific issues, you can try asking there if you want.