OSS playback not working properly with vlc v2.1.5
Greetings,
I recently compiled VLC v2.1(was using v2.0 so far), for Linux systems (got several such systems, the main ones being Core-i5 and Core2 Quad PCs) using OSS v4.2.
VLC v2.0 worked beautifully with OSS, but with v2.1 I went into serious troubles.
The worst one (a clear show stopper) is that as soon as the CPU gets loaded close to 100%, vlc fails to feed the sound stream in time to OSS and the audio gets choppy, as well as the video, making it impossible to watch a TV stream, for example.
A less serious (but still annoying) issue, is that VLC v2.1 seems to be adjusting its audio volume via the OSS PCM channel it got allocated by the OSS mixer. This would be fine, if only VLC was resetting the volume of that PCM channel to 100% before exiting, because failing to do so will get the next program getting that same channel allocated to find its volume very much reduced (most programs - in fact all the ones I used so far - never touch the volume level of the OSS PCM mixer channel and expect it to be at 100% always, when they are at all aware of that setting...).
Finally, to build VLC itself with OSS support, I had to resort to a hack, by creating a soft link to the OSS soundcard.h file (which normally resides inside /usr/lib/oss/include/sys) inside the /usr/include directory (else, it's the Linux kernel's /usr/include/sys/soundcard.h file that gets included, and the OSS-specific code of VLC v2.1 fails to compile).
I had to revert to VLC v2.0.9 since the chopped up audio/video at high CPU loads is clearly a show stopper, rendering VLC unusable.
Activity
Err... Where is VLC v2.2 ??? The current release is v2.1.5, and it doesn't work !
I checked the the Videolan website and FTP site, and there's no trace whatsoever of v2.2.
Also, your ticket classification changes are invalid: for a start the OSS playback is part of the core audio (like I specified), and not of the plugins.
Reopening, till the release version of VLC gets fixed...
removed Status::invalid label
added Status::works for me label
removed Status::works for me label
Added attachment:
Well, you guys would be well inspired to add a direct link to the nighties source tarballs repository to the download page, because having to waste 10 minutes browsing the whole site to find them is a real pain in the ... and that wasted time is as much time not spent finding solutions and contributing to your project...
Anyway... I finally found the tarballs and attempted to build vlc 2.2.0 (today's nighty) on my system, but the requirements are just too much for a system that is only 2 years old (Rosa 2012 Marathon, with support that will be provided till 2017... not really an old neither an outdated system !!!).
Here are the failed requirements: configure: WARNING: Requested 'dbus-1 >= 1.6.0' but version of dbus is 1.4.6. configure: WARNING: No package 'lua5.1' found, trying lua >= 5.1 instead configure: WARNING: Library dvdread > 4.9.0 needed for dvdread was not found configure: WARNING: Library dvdnav > 4.9.0 needed for dvdnav was not found configure: WARNING: Library libbluray >= 0.3.0 needed for bluray was not found configure: WARNING: Library libvncclient >= 0.9.9 needed for vnc was not found configure: WARNING: Library freerdp >= 1.0.1 needed for freerdp was not found configure: WARNING: Library shine >= 3.0.0 needed for shine was not found configure: WARNING: No package 'gstreamer-app-1.0' found. GStreamer modules will not be built. configure: WARNING: Library ogg opus >= 1.0.3 needed for opus was not found configure: WARNING: Library fluidsynth >= 1.1.2 needed for fluidsynth was not found configure: WARNING: Library kate >= 0.3.0 needed for kate was not found configure: WARNING: Library librsvg-2.0 >= 2.9.0 cairo >= 1.13.1 needed for svgdec was not found configure: WARNING: Library libchromaprint >= 0.6.0 needed for chromaprint was not found configure: WARNING: Library libgoom2 needed for goom was not found configure: WARNING: No package 'libvsxu' found. configure: WARNING: Requested 'taglib >= 1.9' but version of TagLib is 1.8.0.
Since I could not build a working version of vlc v2.2.0, I browsed the git for vlc 2.2.0 in search for the OSS-fixes related commits. I found one, that is supposed to fix the show-stopper stuttering of the sound (and video) at high CPU loads, and I produced a patch out of this commit, with another personal small change added: a quick'n dirty compilation fix that allows to build vlc against OSS v4.2 without having to resort to the creation of a bogus soft link to OSS' include file in /usr/include. The patch is attached to this ticket.
Alas, even with that patch, vlc 2.1.5 still keeps stuttering (no actual difference with the non-patched vlc 2.1.5).
So... If vlc 2.2.0 only got that fix implemented, it's insufficient and it's still broken. This won"t either address the building issue (include headers), neither the fact vlc messes up the OSS sound mixer levels and doesn't restore them on exit (see my report in this ticket for these two, still unaddressed problems).
I suggest you roll-back the OSS support code to what is was in vlc v2.0, because it worked just fine in it !
-
Replying to [comment:7 oss117]:
Here are the failed requirements: configure: WARNING: Requested 'dbus-1 >= 1.6.0' but version of dbus is 1.4.6. configure: WARNING: No package 'lua5.1' found, trying lua >= 5.1 instead configure: WARNING: Library dvdread > 4.9.0 needed for dvdread was not found configure: WARNING: Library dvdnav > 4.9.0 needed for dvdnav was not found configure: WARNING: Library libbluray >= 0.3.0 needed for bluray was not found configure: WARNING: Library libvncclient >= 0.9.9 needed for vnc was not found configure: WARNING: Library freerdp >= 1.0.1 needed for freerdp was not found configure: WARNING: Library shine >= 3.0.0 needed for shine was not found configure: WARNING: No package 'gstreamer-app-1.0' found. GStreamer modules will not be built. configure: WARNING: Library ogg opus >= 1.0.3 needed for opus was not found configure: WARNING: Library fluidsynth >= 1.1.2 needed for fluidsynth was not found configure: WARNING: Library kate >= 0.3.0 needed for kate was not found configure: WARNING: Library librsvg-2.0 >= 2.9.0 cairo >= 1.13.1 needed for svgdec was not found configure: WARNING: Library libchromaprint >= 0.6.0 needed for chromaprint was not found configure: WARNING: Library libgoom2 needed for goom was not found configure: WARNING: No package 'libvsxu' found. configure: WARNING: Requested 'taglib >= 1.9' but version of TagLib is 1.8.0.
I fail to see how that prevents testing a new VLC build, and I fail to see what VLC developers can do about your system being old. You are free to compile newer versions from contribs.
Since I could not build a working version of vlc v2.2.0, I browsed the git for vlc 2.2.0 in search for the OSS-fixes related commits. I found one, that is supposed to fix the show-stopper stuttering of the sound (and video) at high CPU loads, and I produced a patch out of this commit, with another personal small change added: a quick'n dirty compilation fix that allows to build vlc against OSS v4.2 without having to resort to the creation of a bogus soft link to OSS' include file in /usr/include.
The OSS plugin compiles fine on its main target, FreeBSD. If your OSS libraries are not in the search path, it's your problem. VLC sources have no business guessing that.
The patch is attached to this ticket.
And that patch is completely wrong and will indeed break FreeBSD ports.
So... If vlc 2.2.0 only got that fix implemented, it's insufficient and it's still broken. This won"t either address the building issue (include headers), neither the fact vlc messes up the OSS sound mixer levels and doesn't restore them on exit (see my report in this ticket for these two, still unaddressed problems).
- There is no build issue as noted earlier.
- VLC does not mess with the mixer levels. To the contrary, VLC fails to preserve its own volume with OSS (bug #10408 (closed)).
- If it is necessary to restore the volume, that is obviously the job of the audio system, if only because applications can always crash or get killed without the chance to perform any explicit clean-up.
- Regardless, any reasonable sound system will support concurrent applications and per-stream and/or per-application volume. Otherwise restoring the volume at exit would anyway break other concurrent applications.
I suggest you roll-back the OSS support code to what is was in vlc v2.0, because it worked just fine in it!
You are free to try for yourself and see that it will not even compile.
Replying to [comment:8 courmisch]:
I fail to see how that prevents testing a new VLC build,
I fail to see what you fail to see...
Cause: VLC 2.2 fails to build on my system due to too high requirements (it's not just about configure warnings, the build does fail).
Effect: I cannot run a VLC 2.2 build on my system.
Pure and simple logic...
and I fail to see what VLC developers can do about your system being old.
When a software requirements get too unreasonable, it becomes impossible to run it on even recent systems. My system is in no way "old" (it was published only two years ago !... If 2 years is "old", then what would you call a system such as Windows XP, Vista, or even 7 ?... LOL !).
To work around such issues, some software (for example: Firefox, or, for video apps Avidemux) include the sources of the critically new libraries in their source tree, and build and statically link them together with their application, instead of relying on the system's libraries...
You are free to compile newer versions from contribs.
The contibs do not provide newer libraries, and re-building all the dependencies that VLC requires from scratch would also involve re-building other libraries that the newer versions of the dependencies depend upon. That's a days-worth work, and I've got other things to do... Not to mention that not everyone got decades of computing and programming experience like I do: do you expect every VLC user to do the same thing ???
Since I could not build a working version of vlc v2.2.0, I browsed the git for vlc 2.2.0 in search for the OSS-fixes related commits. I found one, that is supposed to fix the show-stopper stuttering of the sound (and video) at high CPU loads, and I produced a patch out of this commit, with another personal small change added: a quick'n dirty compilation fix that allows to build vlc against OSS v4.2 without having to resort to the creation of a bogus soft link to OSS' include file in /usr/include.
The OSS plugin compiles fine on its main target, FreeBSD.
Since when VLC is supposed to compile fine only for the (rather confidential/seldom ever used by anyone) FreeBSD target ?
If it builds fine on FreeBSD, then great, but you should also ensure it builds fine for all other supported targets, and if to believe the README file in VLC 2.2 sources: "VLC has been ported to most computing platforms, including GNU/Linux, Windows, Mac OS X, BSD, iOS and Android."
If your OSS libraries are not in the search path, it's your problem.
No, it's the problem of your VLC maintainer for the Linux target. /usr/include/sys/soundcard.h include that gets used when compiling VLC with OSS support under Linux is the wrong file for OSS support (it only holds ALSA related definitions, not OSS ones). Under Linux, OSS comes as a separate module (which sources are available here: http://www.4front-tech.com/developer/sources/stable/ ), which, once installed, got its include files residing in /usr/lib/oss/usr/include. So the configure script shall be able to figure out what soundcard.h file to use under Linux, based whether VLC is configured with OSS support or not.
VLC sources have no business guessing that.
Of course yes !!! That's precisely what the configure script is all about !
The patch is attached to this ticket.
And that patch is completely wrong and will indeed break FreeBSD ports.
Like I wrote: "it's a quick'n dirty compilation fix that allows to build vlc against OSS v4.2", and of course, on my system, i.e. under Linux, not FreeBSD or Windows or any other OS. It's in no way suitable for direct inclusion in VLC sources, but just a way to work around build failures from those broken sources under Linux.
A proper fix would involve redoing the OSS components (here, include files) detection and either add proper #ifdef's in the oss.c file, or proper "-I" pre-processor options to deal with the various cases.
This said, the resulting VLC v2.1.5 binary still suffers from the sound stuttering despite the part of that patch which is a backport of VLC v2.2 so-called "fix" (which obviously doesn't fix anything at all).
So... If vlc 2.2.0 only got that fix implemented, it's insufficient and it's still broken. This won"t either address the building issue (include headers), neither the fact vlc messes up the OSS sound mixer levels and doesn't restore them on exit (see my report in this ticket for these two, still unaddressed problems).
- There is no build issue as noted earlier.
THERE IS. You can deny it, but it's still there. It's like saying that the sun doesn't exist because in your time zone, it's night time and you can't see the sun !
Just try to build VLC under Linux + OSS v4.2 and you will run into the build issue.
- VLC does not mess with the mixer levels. To the contrary, VLC fails to preserve its own volume with OSS (bug #10408 (closed)).
Again, try it before saying it's not the case !!!! This issue does exist as well. Also VLC v2.0 was not suffering from sound volume preservation issues, which would tend to be yet another proof that the new OSS support code is utterly broken and should be reverted to what it was in VLC v2.0 instead.
- If it is necessary to restore the volume, that is obviously the job of the audio system, if only because applications can always crash or get killed without the chance to perform any explicit clean-up.
VLC shall not touch the mixer level in the first place (it's the only application I ever saw doing it !); VLC v2.0 was not touching the mixer levels...
- Regardless, any reasonable sound system will support concurrent applications and per-stream and/or per-application volume. Otherwise restoring the volume at exit would anyway break other concurrent applications.
Please, complain to OSS' authors if you are not happy with OSS' API/features, but if you are going to provide support for their API, then you shall make with whatever (supposed or real) shortcoming it got and make sure your application is not messing up everything for all the other applications (which VLC v2.1+ is currently doing while everything was fine with v2.0).
I suggest you roll-back the OSS support code to what is was in vlc v2.0, because it worked just fine in it!
You are free to try for yourself and see that it will not even compile.
It would of course require a proper backport. But I'm not (neither wishes to become) a VLC developer: I'm a very busy man and I'm already maintaining larger software than VLC, so I have no time to spend on such an issue.
I am merely reporting bugs here (which you should thank me for instead of denying proven and easily reproducible facts).
It's my last comment about this issue. I'm tired to try and convince you to investigate existing bugs and seeing you argue about whether the bugs exist or not instead of just trying out the repro steps I gave you. And I have no time to waste any more (I'd rather uninstall VLC and use another software: there are several good alternatives anyway...).
Have a nice day.
-
Replying to [comment:9 oss117]:
Cause: VLC 2.2 fails to build on my system due to too high requirements (it's not just about configure warnings, the build does fail).
Effect: I cannot run a VLC 2.2 build on my system.
Pure and simple logic...
None of the above mentioned dependencies are mandatory to build VLC, and they are definitely not needed to read, decode and render an audio file. Indeed, it says "WARNING", not "ERROR".
and I fail to see what VLC developers can do about your system being old.
When a software requirements get too unreasonable, it becomes impossible to run it on even recent systems. My system is in no way "old" (it was published only two years ago !...
Of course, you know better than us which libraries we need. Of course, you will spend the time working around bugs and missing features in older library versions, and doing the consequential support. Not.
We are not going to allow old and buggy versions of TagLib because one person refuses to upgrade their system, disable TagLib, or build it from contribs. I note that the other libraries are not even installed; it is not a version problem.
If 2 years is "old", then what would you call a system such as Windows XP, Vista, or even 7 ?... LOL !).
That's what we have contribs for.
To work around such issues, some software (for example: Firefox, or, for video apps Avidemux) include the sources of the critically new libraries in their source tree, and build and statically link them together with their application, instead of relying on the system's libraries...
Contribs. Duh.
You are free to compile newer versions from contribs.
The contibs do not provide newer libraries,
Yes, they do.
and re-building all the dependencies that VLC requires from scratch would also involve re-building other libraries that the newer versions of the dependencies depend upon.
Contribs take care of that too. But that's moot because, as said, none of the warnings you quoted will break the build. They just disable some features.
That's a days-worth work, and I've got other things to do... Not to mention that not everyone got decades of computing and programming experience like I do: do you expect every VLC user to do the same thing ???
So it really boils down to you not bothering. Why would someone else bother then? Besides, you are the only one who's hit the alleged problem. OSSv4 playback worked fine for me when I tried.
The OSS plugin compiles fine on its main target, FreeBSD.
Since when VLC is supposed to compile fine only for the (rather confidential/seldom ever used by anyone) FreeBSD target ?
The main target of the VLC OSS plugin is FreeBSD. That says nothing of VLC as a whole.
OSS is the standard low-level audio interface on FreeBSD, while ALSA is the one on Linux. You know that, do you not?
If it builds fine on FreeBSD, then great, but you should also ensure it builds fine for all other supported targets, and if to believe the README file in VLC 2.2 sources: "VLC has been ported to most computing platforms, including GNU/Linux, Windows, Mac OS X, BSD, iOS and Android."
Tell me that when OSSv4 starts providing a pkg-config file like everybody else does.
If your OSS libraries are not in the search path, it's your problem.
No, it's the problem of your VLC maintainer for the Linux target.
My advise as the "VLC maintainer of the Linux target" is to use ALSA or PulseAudio, or for some special use cases, JACK.
(...)
Under Linux, OSS comes as a separate module (which sources are available here: http://www.4front-tech.com/developer/sources/stable/ ), which, once installed, got its include files residing in /usr/lib/oss/usr/include. So the configure script shall be able to figure out what soundcard.h file to use under Linux, based whether VLC is configured with OSS support or not.
We do not hardcode absolute paths in the build system for obvious reasons (cross-compilation anyone?). If/when OSSv4 provides a proper oss.pc or oss4.pc, we can update configure to use it. In the mean time, you get to configure the include directory via compiler flags like you would have for any library with a non-standard installation path.
VLC sources have no business guessing that.
Of course yes !!! That's precisely what the configure script is all about !
The established work split is that the caller of configure sets the toolchain parameters correctly, otherwise the default toolchain and parameters are used. Search paths are covered by that.
(...)
This said, the resulting VLC v2.1.5 binary still suffers from the sound stuttering despite the part of that patch which is a backport of VLC v2.2 so-called "fix" (which obviously doesn't fix anything at all).
Now you are trolling.
The patch it fixes playback on FreeBSD according to the FreeBSD port maintainer. It was even manually backported there.
(...)
- VLC does not mess with the mixer levels. To the contrary, VLC fails to preserve its own volume with OSS (bug #10408 (closed)).
Again, try it before saying it's not the case !!!! This issue does exist as well.
So 4Front has the insane legacy-style semantics whereby the output device volume controls the master amplification. Gee. We can revert back to the previous method on Linux... But it's going to suck in different ways.
Also VLC v2.0 was not suffering from sound volume preservation issues, which would tend to be yet another proof that the new OSS support code is utterly broken and should be reverted to what it was in VLC v2.0 instead.
VLC 2.0 had software amplification in the application. That was slow and prone to clipping.
- If it is necessary to restore the volume, that is obviously the job of the audio system, if only because applications can always crash or get killed without the chance to perform any explicit clean-up.
VLC shall not touch the mixer level in the first place (it's the only application I ever saw doing it !); VLC v2.0 was not touching the mixer levels...
Frankly, it is appaling that 4Front could not come up with the same and more sensible semantics. You'd expect a recent API as OSSv4 to provide stream volume.
- Regardless, any reasonable sound system will support concurrent applications and per-stream and/or per-application volume. Otherwise restoring the volume at exit would anyway break other concurrent applications.
Please, complain to OSS' authors if you are not happy with OSS' API/features, but if you are going to provide support for their API, then you shall make with whatever (supposed or real) shortcoming it got and make sure your application is not messing up everything for all the other applications (which VLC v2.1+ is currently doing while everything was fine with v2.0).
I would complain if I had to use their software. Luckily, I don't because ALSA has a way better (albeit more poorly documented) programming interface.
commit e5f38003 Author: Rémi Denis-Courmont remi@remlab.net Date: Mon Aug 25 20:06:35 2014 +0300
oss: use software volume on non-FreeBSD targets (refs [#11880](https://code.videolan.org/videolan/vlc/-/issues/11880))Original author: remi@remlab.net
