[pulseaudio-discuss] Reroute audio from /dev/dsp to another sink

[Sean McNamara]

Applications that want to write to "/dev/dsp" are really saying that
they only speak the OSS API -- that's Open Sound System. If you looked
high and low in the app configuration and didn't find anything
mentioning PulseAudio or ALSA, then this app indeed only supports OSS.

What specific app is it, though? I'm just curious. There might be a
simple fix, especially if it's a common open source app. Some open
source apps support only OSS in the default configuration, but there
are additional compile-time options to enable ALSA or PulseAudio
support.

If you do want to proceed trying to use the OSS API, you have a few
options (these are mutually exclusive so don't try to do them all at
the same time):

1. Use Linux kernel 2.6.31 or later with CUSE support enabled, then
install OSS Proxy from
http://www.kernel.org/pub/linux/kernel/people/tj/ossp/
2. Use padsp, a program that ships with PulseAudio (on most distros,
at least!) by tacking it on at the beginning of the command line; for
example: padsp fooprogram argument1 argument2
3. Use aoss, which is pretty much the same as padsp except that it
reroutes to ALSA instead of PulseAudio.
4. Use the in-kernel ALSA OSS emulation.

The advantage of (1) is that it works with a large variety of
OSS-using apps, and reroutes the audio to PulseAudio, so you do see it
in your pulseaudio GUI tools as a proper playback application. The
disadvantage of (1) is that can be painful to compile all the things
needed to enable it; I am not aware of any distributions that ship OSS
Proxy by default. That said, on Ubuntu 9.10 and Fedora 12, you'll
already have the 2.6.31 kernel with CUSE enabled, so you won't have to
recompile your kernel for that. The CUSE code is also pretty new, so
there's a chance you might get a kernel oops -- I have hit one or two
of them during normal use of OSS Proxy.

The advantage of (2) and (3) is that they probably already exist on
your system, and they won't disrupt other audio-using apps. The
disadvantage of these is that they only work with a subset of
OSS-using apps.

The advantage of (4) is that it works with a large variety of
OSS-using apps, and it probably already exists on your system, unless
you're using recent Fedora. The disadvantage of (4) is that it
completely blocks the ability for any other application to use the
sound card while you are using it. It also prevents PulseAudio-using
apps from being able to play sound at the same time.

Can you see now that supporting OSS is ugly, error-prone and
troublesome? There _are_ ways to support it, but none of them are
painless. Your best solution, by far, would be to look for a way to
get your application to play back sound using the PulseAudio or ALSA
APIs. Heck, even something like OpenAL, or SDL would be more preferred
than OSS.


-Sean

On Sat, Nov 14, 2009 at 6:34 AM, Chris Joelly <chris-m-lists at joelly.net> wrote:
> Hello,
>
> i am lokking for a possibility to reroute audio which is sent from an
> application to /dev/dsp to another sink, but i can not find the sending
> application within the tool pavucontrol.
>
> thanks,
>
> Chris
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>