* Re: User-space OSS emulation?
2007-11-08 22:58 ` Lee Revell
@ 2007-11-09 5:19 ` Sean McNamara
0 siblings, 0 replies; 5+ messages in thread
From: Sean McNamara @ 2007-11-09 5:19 UTC (permalink / raw)
To: alsa-devel
Lee Revell wrote:
> On Nov 8, 2007 5:38 PM, Timur Tabi <timur@freescale.com> wrote:
>
>> Lee Revell wrote:
>>
>>
>>> Basically it uses LD_PRELOAD to redirect OSS API calls (ioctls) to the
>>> alsa-lib equivalents. man aoss for details on usage.
>>>
>> I don't have it installed, that's why I'm asking about it. I can't seem to find
>> the "aoss" web page, if there is one.
>>
>
> Google "aoss alsa".
>
> http://alsa.opensrc.org/Aoss
>
> Lee
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
>
Hi,
The Linspire/Freespire team has been working on a different approach to
this problem. They have a kernel module called "forward-oss" (and
accompanying userspace daemon, "forward") which is, in certain ways,
less hackish (and in certain ways _more_ hackish ;)) than aoss.
1. It doesn't use LD_PRELOAD. Many apps are incompatible with LD_PRELOAD
if, for example, they already use it themselves, or they're setuid.
2. It's an alternative to aoss. If aoss doesn't work with an app,
forward-oss may be worth a try.
3. forward-oss was written in 2006/early-to-mid 07. But last I tried,
forward-oss still compiles on very recent Debian kernels - 2.6.22 and
2.6.23 - including non-Linspire kernels. No idea about vanilla or other
distro-specific kernels.
4. It exposes a "real" /dev/dsp device for each ALSA soundcard, e.g.
/dev/dsp1, /dev/dsp2, etc. No syscall interception is necessary.
5. The userspace daemon calls back into your alsa-lib stack, using the
plugin layer for mixing or multiple channels or whatever you want. So in
that sense, it has the same advantage as aoss, while both forward-oss
and aoss differ from the standard ALSA in-kernel OSS emulation in this
regard (snd_pcm_oss). snd_pcm_oss interfaces directly with the kernel
stack, rather than looping back through the user's plugin chain (AFAIK,
this is impossible without using a daemon like Linspire has done). So,
if you have no hardware mixing, snd_pcm_oss either hogs the soundcard or
fails to function while other apps are using ALSA.
6. For compatibility's sake with as many different environments as
possible, it seems forward-oss has an advantage over LD_PRELOAD methods
(i.e. it doesn't need to use LD_PRELOAD at all).
7. It's asking a lot more of the user to have a working kernel build
environment, and proper privileges, to install forward-oss. So
installation is less flexible than aoss, in a sense.
8. More stuff in the kernel = higher probability of
conflicts/panics/oopses... you know the drill.
Also, if you've ever used any sound servers, almost all of them come
with their own ugly duckling LD_PRELOAD hack: padsp for PulseAudio,
esddsp (?) for eSounD, artsdsp for aRts, etc. All of them basically work
with about 20% of all OSS applications ;) YMMV.
Just thought I'd share some other ways I've found to bridge the
OSS<->ALSA gap, besides aoss and snd_pcm_oss...
-Sean
^ permalink raw reply [flat|nested] 5+ messages in thread