On Sat, Jun 19, 2010 at 9:53 PM, Chris Brannon <cmbrannon@xxxxxxx> wrote: > How will this affect people who don't wish to run PulseAudio? Can they > still have their ALSA OSS emulation, or will they need to run PulseAudio > for applications which still use OSS? Most desktop users would want to blacklist the OSS emulation - it doesn't support software mixing. That means that in the absence of hardware mixing (which is usually the case with onboard audio codecs), if an application is using ALSA's built-in OSS emulation to output sound, no other application can. An alternative are wrappers like aoss and padsp, which preload a library emulating the OSS devices in userspace, outputting sound through ALSA or PulseAudio respectively. An even better alternative is osspd, which uses CUSE to provide the devices. It can redirect to either ALSA or PulseAudio. If disabling the OSS emulation would be made the default, and the modules only loaded if added to MODULES in rc.conf, I would welcome that. Disabling OSS preclaim for everyone by altering the kernel config should be safe to do. It's even in the feature removal schedule: > What: sound-slot/service-* module aliases and related clutters in > sound/sound_core.c > When: August 2010 > Why: OSS sound_core grabs all legacy minors (0-255) of SOUND_MAJOR > (14) and requests modules using custom sound-slot/service-* > module aliases. The only benefit of doing this is allowing > use of custom module aliases which might as well be considered > a bug at this point. This preemptive claiming prevents > alternative OSS implementations. > > Till the feature is removed, the kernel will be requesting > both sound-slot/service-* and the standard char-major-* module > aliases and allow turning off the pre-claiming selectively via > CONFIG_SOUND_OSS_CORE_PRECLAIM and soundcore.preclaim_oss > kernel parameter. > > After the transition phase is complete, both the custom module > aliases and switches to disable it will go away. This removal > will also allow making ALSA OSS emulation independent of > sound_core. The dependency will be broken then too. > Who: Tejun Heo <tj@xxxxxxxxxx> I will be testing the effects of disabling that option tomorrow.
