Missing Audacious OSS Plugin

[sonoran]

Continuing to build my minimal F15 system from the beta RC2, I installed OSSv4 from their website and Audacious via yum and was surprised to find that the Audacious packaged by fedora does not include the OSS output plugin. Old news, I guess, because I checked my F13 & F14 and they don't have it either. (I don't spend enough time in them to listen to music - I was hoping to actually use F15)

No big deal to compile Audacious-plugins from source and get it working with OSSv4, but still, it shouldn't be necessary. Does anyone know why fedora goes out of its way to exclude the OSS plugin from Audacious, even the rpmfusion audacious-plugins-freeworld?

[tox]

doesnt look like a FOSS project to me? even though they state its Opensource http://www.oss3d.com/download.html

[sonoran]

I understand why OSSv4 is not included in fedora, but the plugin that allows you to use Audacious with it is GPL.

[tox]

thats something i dont really know, but my guess it has something to do with PulseAudio an the OSS plugin

[sonoran]

The minimal F15 install doesn't include pulseaudio, so I thought I would try OSS which is what I use on Arch - I really like the ossxmix graphical utility, it gives me better control over my sound system than pulse. And the Arch Audacious includes output plugins for both pulseaudio and OSS (I mean, they don't start brawling if they're in the same directory).

"Free your desktop with Fedora" ...well, sort of.

I'm really hoping it was some sort of configuration problem due to the minimal netinstall. I kind of like F15 and systemd.

[PabloTwo]

Yep! If you "want it your way", then compile yourself. I build mine into rpm packages.
BASH:~/-> rpm -q --provides audacious-plugins | grep -e O -e pulse -e audac
OSS.so
pulse_audio.so
audacious-plugins = 2.5-beta1.fc12
audacious-plugins(x86-32) = 2.5-beta1.fc12

[sonoran]

Another voice in the wilderness! :)

I installed rpmbuild, but for the life of me I couldn't get the .flac input plugin to compile from the 2.4.4 sources. So I just added the OSS output plugin to the fedora Audacious, and it works.

Freedom is worth fighting for!

[mschwendt]

The OSS4 plugin in Audacious is disabled by default. So, no surprise there. ;)

And what about old OSS? Fedora uses ALSA for a very long time. Not OSS. Also see /etc/modprobe.d/dist-oss.conf - OSS devices are not even available by default. The plugin has not been built since several releases of the dist. Without anyone asking for it. For the user, that's one less possibly confusing option to choose from. Keeping the ALSA output plugin (and later Pulse Audio) working hasn't been trivial, so as I see it there are no free resources to support it at all.

[sonoran]

GNOME 3 will not run on my hardware (apparently I'm not sufficiently easily distracted),
so I did a minimal install of F15. I really do prefer OSSv4 to PulseAudio - my freedom of
choice, right? So I installed my preferred sound system.

As I have said before on the Forum, your work on Audacious is very much appreciated by
those of us who use it. However, if I can compile the OSS plugin and drop it into
your Audacious package without any problem, I suspect the reason it is not included in
audacious-plugins-freeworld at rpmfusion is other than technical, or legal for that matter.

Perhaps I just don't understand Fedora packaging - it might well be their practice to
arbitrarily hack out functionality from upstream and wait to see if anyone complains.
In that case, though, I would think Fedora would be a lot smaller.

Obviously Fedora and I just don't have the same concept of freedom.

Also see /etc/modprobe.d/dist-oss.conf - OSS devices are not even available by default.

I'm not a default kind of user. But once installed, OSSv4 somehow overcomes the Fedora defaults and runs fine.

[mschwendt]

so I did a minimal install of F15. I really do prefer OSSv4 to PulseAudio
OSS in the Linux kernel is legacy. ALSA is current. Pulse Audio is another optional layer on top of ALSA.

OSSv4 is something else and competes with both ALSA (in some of the hardware it tries to offer drivers for) and PulseAudio (in some of the features). It's not available in Fedora.

- my freedom of choice, right? So I installed my preferred sound system.
Sure. Still, ALSA is the Fedora default. With legacy OSS kernel modules not being loaded anymore, and devices like /dev/dsp not being available by default. ALSA run-time lib provides a bit of compatibility of old OSS programs, however.

However, if I can compile the OSS plugin and drop it into
your Audacious package without any problem, I suspect the reason it is not included in
audacious-plugins-freeworld at rpmfusion is other than technical, or legal for that matter.
If at all, the base audacious-plugins package at Fedora would be the one to include the oss output plugin. I fail to see what rpmfusion have to do with this.

Perhaps I just don't understand Fedora packaging - it might well be their practice to
arbitrarily hack out functionality from upstream and wait to see if anyone complains.
The Open Sound System v4 (oss4) output driver is disabled by default. Upstream default.

The legacy OSS output driver would be built by default, but is disabled in the Fedora package (since Fedora 11?), because Fedora defaults to ALSA. I'm aware of Fedora users, who erase/disable PulseAudio in order to use plain ALSA, but I haven't heard of anyone who reactivates legacy OSS.

Typically, when building legacy components, hardly maintained or unmaintained source code, occasionally a bug is discovered only years later, because only very few users of that stuff are left. Then it is found out that the code has stopped working ages ago already, and building it just for fun has been a mistake. It has happened before that upstream takes such an opportunity to drop the code from a project. Often upstream developers are happy to serve as many potential users as possible, but as often they are also happy to get rid of cruft and reduce some of the burden that comes with maintaining all the code. An "oss" output driver in Fedora would just be another confusing option that doesn't work and opens an error dialog.

[sonoran]

I haven't heard of anyone who reactivates legacy OSS.

:)

Actually, I suppose instead of ranting here I should consider myself lucky that Fedora
still supports OSS to the extent it does. I was reading the OSS Forum and found this:
Canonical/Ubuntu has chosen to disable OSS support in their kernels and ignore
any bugs filed against OSS4 packages. If you're considering using OSS4, you should probably
use another Linux distro like Arch Linux. This page remains for historical/reference reasons.
https://help.ubuntu.com/community/OpenSound

Often upstream developers are happy to serve as many potential users as possible,
but as often they are also happy to get rid of cruft and reduce some of the burden that
comes with maintaining all the code. An "oss" output driver in Fedora would just be another
confusing option that doesn't work and opens an error dialog.

One man's cruft is another man's meat, I suppose.

As I said above, I was working from a minimal install of Fedora 15. OSSv4 installed itself and
tested fine. It wasn't until I installed Audacious and Plugins from the Fedora repos that I hit
a snag - the missing OSS plugin.

I tried the Alsa output plugin but received an error popup "No suitable mixer element found."

Fortunately the OSS and OSSv4 plugins from the source at the Audacious site drop into your
Fedora Audacious package with no modification required. When that does eventually break
I guess I can try fixing the Fedora source configure script, or follow PabloTwo and compile
Audacious from the upstream sources.

Thanks.

[mschwendt]

As I said above, I was working from a minimal install of Fedora 15.
A minimal install of Fedora 15 includes the ALSA kernel driver modules and disables the OSS modules.

$ rpm -qf /etc/modprobe.d/dist-alsa.conf /etc/modprobe.d/dist-oss.conf
module-init-tools-3.12-5.fc15.x86_64
module-init-tools-3.12-5.fc15.x86_64

Doesn't ALSA support your audio hardware? ossxmix isn't available in Fedora either.

It wasn't until I installed Audacious and Plugins from the Fedora repos that I hit
a snag - the missing OSS plugin.
As soon as you installed Audacious and its mandatory Plugins, you pulled in the ALSA userspace library, aka "libasound". Enough to get going even on a minimal system. Absolutely no need to install Pulse Audio on top of that.

$ rpm -qR audacious-plugins|grep aso
libasound.so.2()(64bit)
libasound.so.2(ALSA_0.9)(64bit)
libasound.so.2(ALSA_0.9.0rc4)(64bit)


The OSS and OSSv4 plugins from the source at the Audacious site drop into your
Fedora Audacious package with no modification required. When that does eventually break
I guess I can try fixing the Fedora source configure script, or follow PabloTwo and compile
Audacious from the upstream sources.

For a distribution derived from Fedora it isn't hard to create a 3rd party audacious-plugins-oss package with a proper audacious(plugin-api) dependency. Even better would be for either of you to sign up as a Fedora Packager and become a co-maintainer of audacious-plugins. Else the "oss" output plugin would be completely untested. On the contrary, Fedora Audacious users of plain ALSA (those who disable Pulse Audio) have submitted several problem reports during past releases, and Audacious' ALSA output plugin is actively maintained.

[sonoran]

I think OSSv4 uses all its own kernel modules, if that is relevant. In Arch Linux one
needs to blacklist the Alsa modules (!soundcore) when using OSSv4 to prevent a
conflict. In both Arch and my F15 with OSSv4 installed lsmod gives the same result:
oss_usb
oss_ich
osscore

In F15 Audacious also installs pulseaudio-libs, though not pulseaudio itself. That's
okay with me, I'm not a fanatic. PulseAudio works very well in my F13 & F14.

This is why I like ossxmix, which is part of the OSSv4 package:
http://img846.imageshack.us/img846/9466/ossxmix.th.jpg (http://img846.imageshack.us/i/ossxmix.jpg/)
(There are a couple more vu meters and controls offscreen to the right)

For a distribution derived from Fedora it isn't hard to create a 3rd party audacious-plugins-oss package with a proper audacious(plugin-api) dependency. Even better would be for either of you to sign up as a Fedora Packager and become a co-maintainer of audacious-plugins. Else the "oss" output plugin would be completely untested.
I'll see if I can compile the F15 Audacious-plugins (newly-updated, I notice) with OSS plugin enabled.

[mschwendt]

If you use OSSv4 at the kernel level, you want to build the OSSv4 plugin for Audacious, not the OSS plugin.

In F15 Audacious also installs pulseaudio-libs, though not pulseaudio itself.
Which is expected for a distribution that defaults to Pulse Audio. And Audacious' Pulse Audio plugin has the highest probe priority value.

[sonoran]

In the audacious-plugins SPEC file I changed "--disable-oss" to "--enable-oss",
ran rpmbuild, and Audacious worked fine with the new oss output plugin.

I added the line "--enable-oss4" to the SPEC file, ran rpmbuild again, and although
the oss4 plugin is there, Audacious doesn't seem to recognize it. It isn't offered as
a choice in the output preferences list. The oss plugin still works.

Until I ran the latest updates. Now Audacious fails to start.
$ audacious -V
main.c:461 [main]: Loading configuration.
main.c:465 [main]: Initializing signal handlers.
main.c:468 [main]: Handling commandline options, part #1.
main.c:479 [main]: Initializing plugin subsystems.
ALL OUTPUT PLUGINS FAILED TO INITIALIZE.
main.c:486 [main]: Handling commandline options, part #2.
main.c:489 [main]: Registering interface hooks.
interface.c:62 [interface_get_default]: Searching for an interface.
No interface plugin found.

Fortunately I cache everything during alpha-beta, so a downgrade fixed it.

[mschwendt]

Until I ran the latest updates. Now Audacious fails to start.
$ audacious -V
main.c:461 [main]: Loading configuration.
main.c:465 [main]: Initializing signal handlers.
main.c:468 [main]: Handling commandline options, part #1.
main.c:479 [main]: Initializing plugin subsystems.
ALL OUTPUT PLUGINS FAILED TO INITIALIZE.
main.c:486 [main]: Handling commandline options, part #2.
main.c:489 [main]: Registering interface hooks.
interface.c:62 [interface_get_default]: Searching for an interface.
No interface plugin found.

Fortunately I cache everything during alpha-beta, so a downgrade fixed it.
PEBKAC?

I can no longer assume that you know what you're doing. The last Plugin ABI/API change in F-15 and F-14 has been in early Dec 2010 (to v17). In Rawhide (F-16 development), there have been several API changes, but the 2.5.x branch supports a range of plugin API versions (from v18 to v20).

[vsaua]

I also have to play Audacious through OSS-plugin, because have buggy ALSA driver for my soundcard and OSS loads cpu less than PulseAudio. In my FC13 I use audacious rpms from ATrpms repo. Try it.

[sonoran]

Thanks vsaua, I hadn't thought of that. I try to stick with the Fedora repos
whenever possible. If Fedora continues to try to make my life difficult, the
ATrpm is a possibility.

It's actually not very hard to enable the oss output plugin in the Fedora
sources, even if you don't know what you are doing. :rolleyes:

The only thing that needs changing is the line in the spec file that reads
"--disable-oss". Make that "--enable-oss" and then use rpmbuild to rebuild
the package.

The most time-consuming part of this is installing all the development
packages for the various libraries. Once you have those in place it's pretty
quick. Also studying man rpmbuild - there are a lot of options to consider.
Fortunately most of them seem to produce a working result.

I also tried adding the line "--enable-oss4" in the spec file, but the oss4 plugin
causes Audacious to freeze up sometimes, either after playing a song or when
it comes to the end of the playlist. I think this plugin is a work in progress,
which is why it is disabled by default in the Audacious source code.

@mschwendt - definitely PEBKAC. I didn't mean to suggest that there was
anything wrong with the update. It just arrived on my system like an innocent
bystander coming upon a grisly crime scene.

My methodology is to keep hacking at a problem until either I fix it or everything
breaks - whichever comes first. In this case I had 3 different versions of Audacious
installed, numerous plugin directories...

I can keep all that straight but apparently yum cannot yet read minds.

I uninstalled and manually cleaned out everything, installed the new Audacious
packages, changed the audacious-plugins spec file to enable oss, ran rpmbuild.

Audacious works great with the oss output plugin. The oss4 plugin does not
work reliably. When it does work, I could see no apparent difference between
it and the oss output plugin.

Thanks for your time on this, and sorry if any feelings were bruised - I'm a
polemicist by nature.

[mschwendt]

And still nobody has requested the missing OSS driver in a bug report. It has not been built for several dist releases.

So, I'd say with ATrpms you've found an area of the Fedora package ecosystem that serves you well by providing a niche market plugin. Be happy about that!

The ATrpms changelog for Audacious makes a funny reading, though. Apparently patches from Fedora are copied randomly, and other times the packagers have jumped to severely broken releases in a short-sighted way, e.g. to 2.0.x and 2.3, not limited to missing plugins. Very strange, considering the bumpy road from 1.5.1 to 2.4, which required lots of patches plus work on bringing back some features. The changelogs of Fedora's audacious-plugins-2.2-38.fc13 and audacious-plugins-2.1-27.fc12 in koji are just the tip of the iceberg. The upstream devs have called the 2.4 release a first stable release branch with good reason, and that release really is tons better than the previous ones.

If Fedora continues to try to make my life difficult,
That's nonsense, unfortunately. To iterate, when I've taken over the packages, I've had lots of breakage to deal with in 1.5.1 already. Due to the player being ahead of several plugins. With Fedora disabling OSS by default, there has not been any time and interest left in dealing with another audio driver. Just look at how often the ALSA driver has been patched and even rewritten (and renamed temporarily), and the Pulse Audio has been removed temporarily due to problems, too. With the difference, that ALSA driver users have submitted several helpful bug reports, and nobody has complained about OSS before.

The most time-consuming part of this is installing all the development
packages for the various libraries.
You can run yum-builddep on the src.rpm, if you don't use mock or a buildsys.

Audacious works great with the oss output plugin.
I've reenabled it in Rawhide. For F-15 and F-14 it can return whenever those will need an update (or the test-upgrade to 2.5.x).

[vsaua]

Hello!

Just upgraded today from FC13 to FC14. Of course the upgrade process overwrite my audacious packages from ATrpm and this time I decided to rebuild the audacious-plugins from the srpm to enable OSS-plugin.

I didn't find this method elegant because:
1) As you mentioned I had to install more than 110 devel packages with 130MB - not very fine to keep them. And they will be always updated during "yum update" steal additional traffic and time.
2) Don't know what is the best way to update audacious - rebuild process cost time and attention. For now I've just add "exclude=audacious-plugins" in my yum.conf (possible "exclude=audacious*" needed).

So next time while playing with audacious I'll add ATrpms repo, put "includepkgs=audacios*" in the repo.conf and give a higher priority to it. Guess it'll be more convenient and not brake anything.

Thanks vsaua, I hadn't thought of that. I try to stick with the Fedora repos
whenever possible. If Fedora continues to try to make my life difficult, the
ATrpm is a possibility.

It's actually not very hard to enable the oss output plugin in the Fedora
sources, even if you don't know what you are doing. :rolleyes:

The only thing that needs changing is the line in the spec file that reads
"--disable-oss". Make that "--enable-oss" and then use rpmbuild to rebuild
the package.

The most time-consuming part of this is installing all the development
packages for the various libraries. Once you have those in place it's pretty
quick. Also studying man rpmbuild - there are a lot of options to consider.
Fortunately most of them seem to produce a working result.

I also tried adding the line "--enable-oss4" in the spec file, but the oss4 plugin
causes Audacious to freeze up sometimes, either after playing a song or when
it comes to the end of the playlist. I think this plugin is a work in progress,
which is why it is disabled by default in the Audacious source code.

[mschwendt]

It's vice versa. :( The ATrpms audacious* packages are quite rude and replace Fedora's Audacious and even RPM Fusion's addon packages. Not just due to using the same package names, but due to extra "Obsoletes" tags that uninstall many separate plugin packages. Of course, any time Fedora ships a higher version, this upgrades ATrpms if they are older.

I don't see any room for cooperation here if the plan is not to extend Fedora with "forbidden stuff" (http://fedoraproject.org/wiki/ForbiddenItems), but to replace Fedora packages and copy patches from Fedora's packages.

[sonoran]

I've reenabled it in Rawhide. For F-15 and F-14 it can return whenever those will need an update (or the test-upgrade to 2.5.x).

Thanks very much. I got into trouble with ATRpms years ago and have never gone back.

I enabled Rawhide and got your new packages and the sdlout plugin worked fine in F15 with OSSv4.

I hesitate to mention this - you've been through enough already - but the recurring Playlist Editor bug has returned in the new version - can't scroll up or down through the list. They do seem to fix this fairly quickly each time it reappears.

Thanks again.

[mschwendt]

I enabled Rawhide and got your new packages
That's impossible, because today's (20110423) Rawhide report has not been announced yet.
and the sdlout plugin worked fine in F15 with OSSv4.
sdlout is a new driver for SDL, we've been talking about the "OSS Output Plugin". The plugin file name is OSS.so ;)
I hesitate to mention this - you've been through enough already - but the recurring Playlist Editor bug has returned in the new version - can't scroll up or down through the list. They do seem to fix this fairly quickly each time it reappears.
First time I hear that. Do you have a link to a bug tracker ticket?

[sonoran]

What I got from Rawhide was audacious-2.5.0-1.fc16.x86_64 and plugins, and the sdlout output plugin works with OSSv4 with no other configuration than selecting it in Audacious Preferences.

The plugin file name is OSS.so

I thought you had maybe renamed it to confuse me.

First time I hear that. Do you have a link to a bug tracker ticket?

This is actually a new form - in the past the problem I've had is that using the interface up or down arrow widgets would move randomly in the playlist instead of previous or next. With 2.5.0-1, nothing happens when the widgets are clicked, no movement at all. This is in the skinned interface.

Never filed a bug about this because the issue was annoying but not fatal - I don't use long playlists and by clicking a few times, eventually the right song would be selected. And, the bug always disappeared in an update or two.

The new form - no movement at all using the widgets, makes playlists less useful. One might as well just use the Add Files dialogue and keep it open.

[mschwendt]

The build in Rawhide is release -2.fc16.

Alternatively, you could downgrade to 2.4.5 from F-14 and F-15, too, and then either wait for the most recent update in bodhi - https://admin.fedoraproject.org/updates/audacious-plugins - or fetch it earlier from koji. For 2.4.x at least MP3'n'stuff is available at rpmfusion.

I thought you had maybe renamed it to confuse me.
:doh: :D

This is actually a new form - in the past the problem I've had is that using the interface up or down arrow widgets would move randomly in the playlist instead of previous or next. With 2.5.0-1, nothing happens when the widgets are clicked, no movement at all. This is in the skinned interface.
Ah, a better problem description. I can reproduce that with the evaluation builds of 2.5.0 (http://repos.fedorapeople.org/repos/mschwendt/audacious-2.5/fedora-audacious-2.5.repo), but not with 2.4.x.

It could be deliberately changed behaviour in 2.5.0. Actually, the next/previous track buttons work just fine during playback. But if playback is stopped, they don't move the current playlist position as 2.4.x does.


Btw, in 2.4.x and older it moves random if the "RAND" button in the skinned interface is enabled.