FS#56616 - [vlc] Audio sounds terribly wrong, upstream say it's downstream issue
Attached to Project:
Arch Linux
Opened by Deactivated account (TechnicalTotoro) - Thursday, 07 December 2017, 00:29 GMT
Last edited by Eli Schwartz (eschwartz) - Tuesday, 16 January 2018, 18:16 GMT
Opened by Deactivated account (TechnicalTotoro) - Thursday, 07 December 2017, 00:29 GMT
Last edited by Eli Schwartz (eschwartz) - Tuesday, 16 January 2018, 18:16 GMT
|
Details
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: https://www.youtube.com/watch?v=MDVePv8OvJA 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: https://www.youtube.com/watch?v=HhR7Znn3Ki4 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: https://trac.videolan.org/vlc/attachment/ticket/19239/VLC.log And the upstream bug report is here: https://trac.videolan.org/vlc/ticket/19239 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
Tuesday, 16 January 2018, 18:16 GMT
Reason for closing: Fixed
Additional comments about closing: cannot be reproduced with the latest vlc package
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 :
https://bbs.archlinux.org/viewtopic.php?id=184955
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
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/libprojectm_plugin.so' (libprojectM.so.2: cannot open shared object file: No such file or directory)
[00000aae493473d8] core libvlc warning: cannot load module `/usr/lib/vlc/plugins/visualization/libgoom_plugin.so' (libgoom2.so.0: cannot open shared object file: No such file or directory)
[00000aae493473d8] core libvlc warning: cannot load module `/usr/lib/vlc/plugins/control/liblirc_plugin.so' (liblirc_client.so.0: cannot open shared object file: No such file or directory)
[00000aae493473d8] core libvlc warning: cannot load module `/usr/lib/vlc/plugins/codec/libtwolame_plugin.so' (libtwolame.so.0: cannot open shared object file: No such file or directory)
[00000aae493473d8] core libvlc warning: cannot load module `/usr/lib/vlc/plugins/access/libvcdx_plugin.so' (libvcdinfo.so.0: 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.
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?