2

Before I fell back to ALSA, I had severe problems with PulseAudio deadlocks for years on my Debian system on which I am using some OSS only (requiring /dev/dsp) applications. I would like to see whether it is possible to fix it, and how.

I am using Debian Wheezy, and don't want to upgrade to Jessie until it becomes stable, so I would prefer a solution for Wheezy (for example osspd which might be one solution, does not yet exist on Wheezy).

An application I am using and it is strictly OSS only is for example sidplay2.

So far I could only solve the problem with having oss-compat installed, which provides /dev/dsp for OSS applications which need it.

However with /dev/dsp present, apparently just about everything (applications like MPlayer, ogg123, mpg321, everything SDL based such as Battle for Wesnoth, a third party Flash plugin) tries to use it instead of anything more advanced (such as Alsa or PulseAudio).

Without oss-compat, not even aoss works, so it seems like I can't use OSS only applications without it right now. I read it's man page, and some documentations, but neither creating an .asoundrc seems to make aoss doing what it should do (with oss-compat installed, it works).

With this system, however, PulseAudio is very unstable, and would occasionally deadlock when starting a new application wanting to use OSS (which is just about everything) when one is already running. The only "solution" this case is -SIGKILLing the deadlocked application, and killing PulseAudio.

My current "solution" to the problem is reverting to Alsa (removing PulseAudio), have oss-compat installed, and patching up stuff to either use aoss or to explicitly use Alsa, so things potentially producing audio output can operate simultaneously and stable.

However I would like to have it the "right way", with PulseAudio not removed, without needing oss-compat installed.

(True this relates to my previous question here, however when I asked that I hadn't got the slighest clue on what is going on, without the help of Derobert, I would still be as good as dead on understanding this)

1

You should start OSS applications using padsp. This would seem to be the obvious thing to do, but you don’t mention it.

  • I'm long-term linux user, but it's totally not obvious to me to start anythign that might want to do something with audio with padsp. This is actually the first time I've heard of this. I'm with Jubatian, I see no advantage in pulseaudio and also just deinstall it. I don't see why I suddenly have to start commands in a different way just to satisfy pulseaudio. – wurtel Dec 3 '14 at 12:12
  • I was completely unaware of this application, and searches neither revealed it. For example for oss-compat only Jessie starts suggesting to use a different application (packages.debian.org/jessie/oss-compat, osspd), for Wheezy, that suggestion is not even there. Anyway, I will try this (will take a while: reinstall PulseAudio, undo all the patchwork I did, examine, experience, see if it is stable etc., and I won't be at computer at weekend). If it works as it is supposed to, I will accept this. – Jubatian Dec 3 '14 at 16:42
  • 1
    @wurtel: As far as I experienced, if you want multiple apps using OSS run simultaneously, you need to wrap them up. PulseAudio seemed to try to solve this "automagically", but was unstable at it. Without PulseAudio (ALSA only), I had to patch OSS only stuff up with aoss. – Jubatian Dec 3 '14 at 16:52
  • @wurtel: If you run one sound system natively, you should expect to be required to run applications written for a different sound system in a compatibility wrapper. For PulseAudio and OSS applications, padsp is that compatibility wrapper. This has nothing to do with whether you “see any value in pulseaudio”. – Teddy Dec 7 '14 at 20:54
  • Did some tests with mixed results. Well, I can't say PulseAudio is unstable after ditching oss-compat. With paman I was monitoring clients, threw stuff at it, and it took the abuse without complaining. However for one, anything going through padsp lags about a second, and I don't see where or why (the ALSA + oss-compat + aoss workaround does not lag). Moreover, sidplay2 is broken (produces some noise barely resembling the sid it is supposed to be playing), so for that particular application so far this is a no-solution. – Jubatian Dec 8 '14 at 17:10

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.