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@ast.cam.ac.uk) said:
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.
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.
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.
Bill
On Tue, 31 May 2005 09:42:34 -0400, Bill Nottingham wrote:
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
Am Dienstag, den 31.05.2005, 09:42 -0400 schrieb Bill Nottingham:
Jeremy Sanders (jss@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.
There was one in extras, it was removed after a short discussion:
https://www.redhat.com/archives/fedora-devel-list/2005-February/msg00655.htm...
I was the maintainer. The last version is here afaik:
http://ftp-stud.fht-esslingen.de/pub/Mirrors/fedora/fedora/fedora/1/i386/SRP...
On Tue, 31 May 2005, Jeremy Sanders wrote:
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
On Tue, 2005-05-31 at 12:23 +0100, Jeremy Sanders wrote:
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.
With the pcm.!dsp target alsa-oss is obsolete.
2005/6/1, Ignacio Vazquez-Abrams ivazquez@ivazquez.net:
With the pcm.!dsp target alsa-oss is obsolete.
please explain more. There is no pcm.!dsp in default configuration, how to add it? //thx.
On Wed, 2005-06-01 at 10:09 +0800, Yuan Yijun wrote:
2005/6/1, Ignacio Vazquez-Abrams ivazquez@ivazquez.net:
With the pcm.!dsp target alsa-oss is obsolete.
please explain more. There is no pcm.!dsp in default configuration, how to add it?
In your asoundrc file add the following:
pcm.!dsp { type plug slave.pcm <dmix slave without "pcm."> }
If for instance your dmix slave is pcm.dmixer then you would put "dmixer" where the angle brackets are:
pcm.!dsp { type plug slave.pcm "dmixer" }
This will allow apps that use the obsolescent OSS interface to use software mixing.
Ignacio Vazquez-Abrams wrote:
On Wed, 2005-06-01 at 10:09 +0800, Yuan Yijun wrote:
2005/6/1, Ignacio Vazquez-Abrams ivazquez@ivazquez.net:
With the pcm.!dsp target alsa-oss is obsolete.
please explain more. There is no pcm.!dsp in default configuration, how to add it?
In your asoundrc file add the following:
pcm.!dsp { type plug slave.pcm <dmix slave without "pcm."> }
If for instance your dmix slave is pcm.dmixer then you would put "dmixer" where the angle brackets are:
pcm.!dsp { type plug slave.pcm "dmixer" }
This will allow apps that use the obsolescent OSS interface to use software mixing.
Is there any drawback to doing this by default?
Warren Togami wtogami@redhat.com
Hi.
Warren Togami warren@togami.com wrote:
Is there any drawback to doing this by default?
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.
2005/6/1, Ignacio Vazquez-Abrams ivazquez@ivazquez.net:
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 :)
On Wed, 2005-06-01 at 12:43 +0800, Yuan Yijun wrote:
2005/6/1, Ignacio Vazquez-Abrams ivazquez@ivazquez.net:
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.
On Wed, 01 Jun 2005 01:09:16 -0400, Ignacio Vazquez-Abrams wrote:
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
-
Bill Nottingham -
Ignacio Vazquez-Abrams -
Jeremy Sanders -
Mike Hearn -
Ralf Ertzinger -
Thorsten Leemhuis -
Warren Togami -
Yuan Yijun