Bug 472741

I disagree.  We can achieve the same goal but with greater user flexibility with my suggested plan at the beginning of this thread:

1) alsa-plugins-pulseaudio seems to be the key package someone must
remove if they really want to disable pulseaudio on their system.  This
package could ship a /etc/modprobe.d/blacklist-oss file listing
snd-*-oss modules.  This way OSS comes back if pulseaudio is removed.

2) If someone REALLY wants OSS mixed in their pulseaudio desktop, they
can use padsp.  This should be documented loudly in release notes.  This
is no different from F9 and F10.

3) Later make /dev/dsp redirection to pulseaudio permanent without LD
hacks if the proposed FUSD happens.  Not a priority though.

If we use this plan, OSS kernel modules are still disabled by default, yet it remains *possible* for the user to use it if they really want to.  Not all OSS applications work with padsp emulation.

If we go with this plan instead, no changes are needed to kernel.  We only need to modify alsa-plugins-pulseaudio.

(In reply to comment #1)
> I disagree.  We can achieve the same goal but with greater user flexibility
> with my suggested plan at the beginning of this thread:
> 
> 1) alsa-plugins-pulseaudio seems to be the key package someone must
> remove if they really want to disable pulseaudio on their system.  This
> package could ship a /etc/modprobe.d/blacklist-oss file listing
> snd-*-oss modules.  This way OSS comes back if pulseaudio is removed.

OSS emulation breaks software sound mixing and other ALSA apps, whether using PulseAudio or not.

> 2) If someone REALLY wants OSS mixed in their pulseaudio desktop, they
> can use padsp.  This should be documented loudly in release notes.  This
> is no different from F9 and F10.

Yes.

> 3) Later make /dev/dsp redirection to pulseaudio permanent without LD
> hacks if the proposed FUSD happens.  Not a priority though.

And how exactly do you expect that to work? This seems a great deal of work without much gain whatsoever.

> If we use this plan, OSS kernel modules are still disabled by default, yet it
> remains *possible* for the user to use it if they really want to.  Not all OSS
> applications work with padsp emulation.
> 
> If we go with this plan instead, no changes are needed to kernel.  We only need
> to modify alsa-plugins-pulseaudio.

This plan has nothing to do with PulseAudio. OSS is broken by design in Linux.  Opening an OSS device means the device won't be available for ALSA apps anymore, and we're back in the 90's.

I'm just pointing out that my proposal achieves effectively the same goal as your proposal: /dev/dsp no longer exists, so OSS cannot by default cause pulseaudio to fail.

My plan is superior however, because it does not take away the OPTION that some users need to have OSS sound that cannot be emulated with padsp or other OSS wrappers.  It does not hurt you or default users to retain the old behavior should they rip out pulseaudio.

I don't want to take sides in this esteemed discussion, but let me just note, that there is nothing to triage here.

Switching to ASSIGNED so that developers have responsibility to do whatever they want to do with it.

http://lwn.net/Articles/308445/
CUSE: Character devices in user space

The first cuse driver is an OSS proxy to pulseaudio, that provides /dev/dsp, /dev/adsp and /dev/mixer.  The article describes it as likely to be merged in the upstream 2.6.29 kernel.  Let us help this become stable so we can count on it for F11.

Assuming cuse OSS proxy is ready for F11, and it works reasonably well as a complete replacement for ALSA's OSS compat layer, we would do the following:

1) Disable building of the OSS kernel modules.
2) Provide cuse OSS proxy in its own package, that starts the OSS proxy upon user login after the user's pulseaudio daemon is running.
3) Do NOT install it by default, as it is yet another process that runs that few people actually need.  If people want OSS proxy they can install this optional package.

The fallback plan if cuse OSS proxy is not ready for F11...

1) Keep the OSS kernel modules.
2) alsa-plugins-pulseaudio ships /etc/modprobe.d/blacklist-oss-sound, thereby preventing loading of these kernel modules and interfering with pulseaudio daemon.
3) If the user wants to use an OSS sound application they can use padsp manually.
4) Native OSS comes back if the user uninstalls alsa-plugins-pulseaudio, which also makes it so nothing uses pulseaudio for sound output by default.

In both cases the user has to manually do something to use OSS, which is fine by me.

install snd-pcm /sbin/modprobe --ignore-install snd-pcm && /sbin/modprobe snd-pcm-oss && /sbin/modprobe snd-seq-device && /sbin/modprobe snd-seq-oss

Notting pointed out that the blacklist suggestion doesn't work due to this install line in /etc/modprobe.d/modprobe.conf.dist. notting suggested an alternative similar proposal.

1) Keep the OSS kernel modules.
2) Remove the install line from /etc/modprobe.d/modprobe.conf.dist.
3) Precreate /dev/dsp, /dev/mixer and other OSS nodes with udev using /etc/udev/makedev.d or /lib/udev/devices.d.
4) Include the blacklist lines in alsa-plugins-pulseaudio.

Better plan:

1) Keep the OSS kernel modules.
2) Remove all snd-oss* lines from /etc/modprobe.d/modprobe.conf.dist.
3) (We might want to put blacklist snd-oss* lines into alsa-plugins-pulseaudio?  Will this be needed or helpful at all?)
4) Put the lines removed in #2 into a new package called compat-broken-oss-sound.  This package conflicts with alsa-plugins-pulseaudio.  This package exists only for single purpose machines where you don't care if everything else other than a single OSS app is broken.
5) Release notes say OSS is DISABLED BY DEFAULT.  All applications should switch to ALSA or pulseaudio output.  As a backup measure, OSS-only applications can use padsp to emulate an OSS device, which works for most applications.

Sounds like a good idea to me, +1.

Why is the plan in #12 better than the plan in #11?

What is the status on this? Just trying to get sound working on my friends computer for Enemy Territory. On Fedora 10 and before this was needed:

echo "et.x86 0 0 disable" > /proc/asound/card0/pcm0c/oss
echo "et.x86 0 0 direct" > /proc/asound/card0/pcm0p/oss

Now I can't create those files even as root?

If you want OSS back in Fedora 11, look at /etc/modprobe.d/dist-oss.conf
This WILL cause conflicts and strange failures with all other applications on your system however.