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 >
