Is there any reason why the alsa-oss package isn't part of fedora? This is
quite useful if you want to use the dmix alsa mixer and get oss apps to
mix their output too.
I've managed to hack together an updated version of the alsa-oss spec file
(from livna) which appears to work.
Jeremy
--
Jeremy Sanders <jss(a)ast.cam.ac.uk&gt; http://www-xray.ast.cam.ac.uk/~jss/
X-Ray Group, Institute of Astronomy, University of Cambridge, UK.
Public Key Server PGP Key ID: E1AAE053

Honestly, IMO it seemed like quite a hack for Core use, especially
since it would require per-app setup anyway. For Core I think the
best thing to do is to make sure all apps are using ALSA natively.

Hack it is, but large numbers of apps still don't support ALSA properly.
We need backwards compatibility with OSS in a way that doesn't avoid dmix,
and alsa-oss provides that.
As to whether it should be in Core or Extras, well, it's not a large
program and it's the sort of thing that could end up being quite
frequently used. Especially as nearly every commercial game for Linux uses
OSS and not ALSA. But the criteria for core vs extras is a bit vague, I'm
not sure where it should be ... but alsa-oss feels like operating system
level software to me, as opposed to some app.
thanks -mike

Jeremy Sanders (jss(a)ast.cam.ac.uk) said:
> I've managed to hack together an updated version of the alsa-oss spec file
> (from livna) which appears to work.
If you've got a working version, it would be great for Extras.

I've managed to hack together an updated version of the alsa-oss
spec file
(from livna) which appears to work.

Sorry for the lack of threading here, but I stupidly must have chosen
plain text instead of MIME for my digests.
I've included the alsa-oss spec file (which is just a slightly modified
copy of the livna one). It appears to work with alsa-oss-1.0.9.
I think it's pretty useful to have, because so many apps want to use OSS,
especially non-free stuff. These apps include the flash plugin, games,
skype and realplayer (does helix do alsa now?).
Jeremy
--
Jeremy Sanders <jss(a)ast.cam.ac.uk&gt; http://www-xray.ast.cam.ac.uk/~jss/
X-Ray Group, Institute of Astronomy, University of Cambridge, UK.
Public Key Server PGP Key ID: E1AAE053

Well, I can't get it to work. I can still play sound using the oss
interface, but only one stream at a time, no matter what I put in
~/.asoundrc. All other attempts fail with "resource busy" or a
variant thereof.

pcm.!dsp {
type plug
slave.pcm "dmixer"
}
This will allow apps that use the obsolescent OSS interface to use
software mixing.

Does it mean that any access to /dev/dsp and /dev/dsp0 will be
redirected to alsa dmixer? How would that happen if /dev/dsp is
handled by kernel driver and dmixer is just a userland library? I'm
sorry if I missed something :)
--
bbbush ^_^
I don't care about realplay since I use mplayer and xine

2005/6/1, Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net&gt;:
> pcm.!dsp {
> type plug
> slave.pcm "dmixer"
> }
>
> This will allow apps that use the obsolescent OSS interface to use
> software mixing.
>
Does it mean that any access to /dev/dsp and /dev/dsp0 will be
redirected to alsa dmixer? How would that happen if /dev/dsp is
handled by kernel driver and dmixer is just a userland library? I'm
sorry if I missed something :)

Um, the same way ALSA deals with /dev/snd/* being handled by kernel
drivers? IOW, transparently.

That's not a good enough explanation, sorry. The ALSA guys have spoken in
the past about maybe having the OSS emulation redirect back up into
userspace to be received by a special daemon that then sends the audio
into dmix and then back into kernel space, so you have a kind of W shape,
but I never heard of any implementation. And any such thing would be very
slow, perhaps slower than alsa-oss.
How *exactly* does this work, given that dmix mixes in userspace but the
OSS emulation (unless you use alsa-oss) takes place in the kernel?
thanks -mike