So why most applications apparently try to use OSS if /dev/dsp is present on a system where more advanced audio servers (ALSA or PulseAudio) are also available?

I experience this after installing oss-compat on Debian Wheezy. Apparently for example the following apps seem to start using OSS no matter what else is available:

  • MPlayer
  • SDL (anything using the SDL library, such as Battle for Wesnoth)
  • mpg321
  • ogg123
  • (third party) Firefox's (third party) Flash plugin

The reason for trying this is not quite relevant for the question, however check here if interested.

For me it would seem the more logical if applications (which are capable to use those) probed for the more advanced audio solutions first, and only tried to access OSS (/dev/dsp) when none is found.

  • If the problem is just pulseaudio compatibility, have a look at, e.g., mpg123 --list-modules, and the -o switch in man mpg123. I think some of this is poor incorporation of pulseaudio by debian, but that is just a hunch. – goldilocks Dec 8 '14 at 20:25
  • @goldilocks Yep, I already patched this around since long with startup scipts to force stuff explicitly to use ALSA for which it was appropriate, memorizing commands where necessary, or for others, to use aoss etc., so things work fine as now, it seems, my current take is still the most pleasant solution considering my need for some OSS only apps which even break with PulseAudio's padsp (I don't have PulseAudio installed in this setup). – Jubatian Dec 8 '14 at 20:30
  • Keep in mind if you don't have pulse, you can't multiplex sound, so if something tries to make a noise while something else is using sound, it will be disappointed. ALSA and OSS are only one thing at a time. – goldilocks Dec 8 '14 at 20:32
  • @goldilocks There is no true OSS, just oss-compat. Truly I shouldn't even need that, as aoss is supposed to work without it, but I can't figure out to save my soul, how. ALSA can multiplex, OSS stuff, as long as started through aoss will also happily cooperate (I am listening music even right now, and sure at least one Flash advert is here somewhere :) ). – Jubatian Dec 8 '14 at 20:37
  • Hmmm, maybe this is what's up: olicomber.co.uk/blog/b/… Anyway, you have a good question in here somewhere, lol -- probably plural. You have to go at this in terms of the individual applications. – goldilocks Dec 8 '14 at 20:45

it would seem the more logical if applications probed for the more advanced audio solutions first

I would guess there's actually a big advantage to this, having done a little with the ALSA API. Here's where you start, in order to just play a prepped PCM stream.

Now I'll cite wikipedia on the OSS API:

The API is designed to use the traditional Unix framework of open(), read(), write(), and ioctl(), via special devices. For instance, the default device for sound input and output is /dev/dsp. Examples using the shell:

   cat /dev/urandom > /dev/dsp # plays white noise through the speaker
   cat /dev/dsp > a.a # reads data from the microphone and copies it to file a.a

Which one do you want to start with -- the more advanced and complicated one, or the simple and foolproof one? I imagine it depends what you want to do, but presuming most applications just want to stream some pcm out, writing to /dev/dsp should be fine.

[I'm also presuming plain PCM can be fed directly to /dev/dsp (if not then what?), but I can't test it because smarty-pants that I am, all my machines here have custom kernels with no OSS support! I might just change my tune on that in the future.]

  • I can understand this standpoint for an OSS only application: the author gone down the easiest path. What I don't understand are those for example I mentioned: they are all capable to use at least ALSA (and typically more), yet they still fall in for a /dev/dsp as soon as they see one (which becomes annoying fast when actually having ALSA, but needing oss-compat for a few OSS only things). – Jubatian Dec 8 '14 at 19:38
  • Okay, but: Note what I said about how my systems don't have OSS support. That means for greatest portability you would need to provide both OSS-only and non-OSS ALSA. I.e., you need to implement both. Then if what you need to do can be done with OSS, it probably has marginally lower overhead, so you might as well start with that. Why use a more complex tool when a simpler one will suffice if available? – goldilocks Dec 8 '14 at 19:50
  • Uh. I was asking this from an user's viewpoint, who wishes to use applications which already do support both OSS and ALSA, not from a developer's viewpoint, who is just about to decide which path he should take first. That is, that why (most?) applications which already support both (or even more) will still use OSS if they happen to find a /dev/dsp (I don't know, maybe this is even rather specific to Debian, that they compile / set up things this way for the distro). – Jubatian Dec 8 '14 at 20:02
  • If the developer wants to give the user a choice, s/he's free to do that. However, nobody writes software such that every decision point is user configurable. In this case it's hard to see why this would matter to the user -- if the app is supposed to play sound and it does, and on a variety of systems, most people could care less what mechanism was used. BTW, you haven't actually said how you've made this observation. If you don't have any counter examples (exceptions which use ALSA and not /dev/dsp), I would be dubious of the methodology. – goldilocks Dec 8 '14 at 20:14
  • I installed oss-compat on my ALSA based system to get an OSS app working, and suddenly a hell of complaints for /dev/dsp being busy... (usually Firefox reserving it for itself for some stupid Flash ad, then I can't start a music player, or test an SDL app I am developing - these all use ALSA when no /dev/dsp is present, and work happily, simultaneously). So far I didn't find any counter-examples on my system, so seems systematic. I don't understand why. Is there a standard on this then, or what? – Jubatian Dec 8 '14 at 20:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.