Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#56616 - [vlc] Audio sounds terribly wrong, upstream say it's downstream issue

Attached to Project: Arch Linux
Opened by Nikita Yerenkov-Scott (TechnicalTotoro) - Thursday, 07 December 2017, 00:29 GMT
Last edited by Eli Schwartz (eschwartz) - Tuesday, 16 January 2018, 18:16 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Levente Polyak (anthraxx)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


Even after reinstalling VLC Media Player I have found that something is terribly wrong with the audio when listening to tracks that have multiple layers of the sound. For example when the voice is meant to be on top of the background music, I find it is actually the other way round, and they either sound merged, or the music cuts through the voice like it certainly shouldn't. There is also the wrong emphasis on many things such as echoes and it just sounds wrong and I find that I kind enjoy listening to my music any more so much with it, whether it be from YouTube, an mp4 file, or even a disc.

I have found that even though my Walkman has worse quality in some ways, it is actually now more enjoyable to listen through that rather than VLC.

All other players seem to work fine, but it's just VLC player which is playing up.

If you compare listening to this on YouTube: For instance, with listening to it through VLC Media Player, you will notice that the echoes are in some way too long and there is almost the wrong emphasis in VLC. Or with this one where the music and the voice are almost competing:

I am running the latest up-to-date version of Arch Linux, VLC 2.2.7-1, with GNOME 3.26.3, Wayland and the latest version of linux-hardened. And here is the log I provided when I reported this to VLC upstream:

And the upstream bug report is here: Which sort of provides more information. Or the most I really can about this issue. It also shows upstream saying that this is a downstream issue and shouldn't be happening. And that it is probably caused by packaging and is probably either a plug-in failure or build issue.

Reinstalling VLC, it should be noted, actually made the problem worse and slightly changed some of what I am noticing with the echoes to make them actually now louder than the voice and too long. With also some very slight voice echoes which are not really actually meant to be heard properly, are heard quite loudly, and over everything else.
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Tuesday, 16 January 2018, 18:16 GMT
Reason for closing:  Fixed
Additional comments about closing:  cannot be reproduced with the latest vlc package
Comment by patrick (potomac) - Sunday, 10 December 2017, 02:30 GMT
you can try to change some audio settings in VLC, because the default settings in VLC can be not optimal, especially if you are an audiophile user,

for example the audio resampling option, there are several resampling methods in VLC options : automatic, src, speex,

my advice : use speex method resampling, see this old thread :

it can be also a bug related to "vlc-cache-gen", when the file /usr/lib/vlc/plugins/plugins.dat is rebuilt, on some configurations this step can fail,

check also if the bug is triggered by an alsa configuration, or a bad pulseaudio configuration
Comment by Nikita Yerenkov-Scott (TechnicalTotoro) - Sunday, 10 December 2017, 20:36 GMT
Patrick, this started after a VLC update, upstream say they didn't change anything like this in the default configuration and the configuration which both they and I haven't changed is what I've been happy with this whole time so I don't think that it is that.

I have tried using other audio resampling methods and that doesn't seem to make much of a difference. In fact I'm not sure that there is any real noticible improvement or difference at all.

Given that log I provided upstream has the following lines in it:

[00000aae493473d8] core libvlc debug: searching plug-in modules
[00000aae493473d8] core libvlc debug: loading plugins cache file /usr/lib/vlc/plugins/plugins.dat
[00000aae493473d8] core libvlc debug: recursively browsing `/usr/lib/vlc/plugins'
[00000aae493473d8] core libvlc warning: cannot load module `/usr/lib/vlc/plugins/visualization/' ( cannot open shared object file: No such file or directory)
[00000aae493473d8] core libvlc warning: cannot load module `/usr/lib/vlc/plugins/visualization/' ( cannot open shared object file: No such file or directory)
[00000aae493473d8] core libvlc warning: cannot load module `/usr/lib/vlc/plugins/control/' ( cannot open shared object file: No such file or directory)
[00000aae493473d8] core libvlc warning: cannot load module `/usr/lib/vlc/plugins/codec/' ( cannot open shared object file: No such file or directory)
[00000aae493473d8] core libvlc warning: cannot load module `/usr/lib/vlc/plugins/access/' ( cannot open shared object file: No such file or directory)
[00000aae493473d8] core libvlc debug: saving plugins cache /usr/lib/vlc/plugins/plugins.dat
[00000aae493473d8] core libvlc debug: plug-ins loaded: 454 modules

I think the vlc-cache-gen thing you mentioned is probably the more likely. There is also this:

[0000628af4009638] core stream error: cannot pre fill buffer [0000628af4001078] core access debug: removing module "cdda"

But I of course don't know if that specific entry has anything to do with it.
Comment by Levente Polyak (anthraxx) - Friday, 12 January 2018, 13:08 GMT
can't reproduce this, is it still the case with 2.2.8-2?
Comment by Nikita Yerenkov-Scott (TechnicalTotoro) - Saturday, 13 January 2018, 21:57 GMT
Sorry for not getting back to you sooner, I've been busy and with bug in me instead of just the software!

It appears as though the rebuild in the new updates or updated cache or whatever it is has fixed the problem. So we can now close this bug report. But it would be nice, if this sort of thing can happen in the packaging process downstream, for us to run some proper checks on it before release. And rebuilding if necessary. Because it's a real nuisance to have to wait until there's a new update. Unless this is what 2.2.8-2 was there to address?
Comment by Eli Schwartz (eschwartz) - Tuesday, 16 January 2018, 18:16 GMT
Doubtful, that was just a libx264 rebuild. Maybe the upstream update fixed it.