Fallback audio system no longer checks ALSA

[Sasquatch]

In previous versions, ALSA was checked as possible sound system (I think). Now, when the selected sound system doesn't work, it goes to OSS and reverts to NULL if that doesn't work. It used to be possible to select Pulse as sound system while using ALSA instead and have libpulse0 installed.

I don't know when exactly it stopped working, but on 3.0.6 it was certainly broken and there is no change on 3.0.8. The log is attached.

I'm not really sure if older versions did the same, but I was able to have audio with ALSA and libpulse0 by selecting Pulse. Because I 'share' my VMs between PC (with PulseAudio) and my laptop (without), it's a bit of a hassle to keep changing the settings (ALSA on PulseAudio isn't working all that spotless either, not a VB thing though).

[Sasquatch]

This problem is still present in 3.1.0. This should be fixed in case users remove PulseAudio and forget to change the audio system, or share VM settings between different Hosts with different audio systems (e.g. a computer with Pulse and a laptop with ALSA).

[Frank Mehnert]

Hmm, I'm not sure if we changed anythink. The audio subsystem tries to open the selected audio backend at first, PulseAudio in your case. If that fails, it goes through all available drivers. In your case, the OSS driver can be opened successfully and therefore OSS is used and ALSA is not even tested.

[Sasquatch]

That's just the problem, OSS doesn't work by default. It never has and never will. When I encounter an OSS application, I have to start it with the OSS wrapper of the sound system I'm using (aoss for alsa, padsp for Pulse), else I get the same error (no sound). This part is the most importent IMO:

664 00:00:04.609 Audio: Trying driver 'pulse'.
665 00:00:04.716 Pulse: Failed to initialize context (state 5)
666 00:00:04.717 Audio: Initialization of driver 'pulse' failed, trying 'oss'.
667 00:00:04.717 Audio: set_record_source ars=0 als=0 (not implemented)
668 00:00:04.717 OSS: Successfully opened /dev/dsp for ADC
669 00:00:04.718 OSS: Failed to open /dev/dsp for DAC (Device or resource busy)
670 00:00:04.718 OSS: Failed to open /dev/dsp for DAC (Device or resource busy)
671 00:00:04.719 AC97: WARNING: Unable to open PCM OUT[[BR]] 672 00:00:04.719 VM: Raising runtime error 'HostAudioNotResponding' (fFlags=0x0)
673 00:00:04.719 Console: VM runtime error: fatal=false, errorID=HostAudioNotResponding message="Some audio devices (PCM_out) could not be opened. Guest applications generating audio output or depending on audio input may hang. Make sure your host audio device is working properly. Check the logfile for error messages of the audio subsystem"

It clearly states that it can't open audio, so why use it? You can always open /dev/dsp, that's the compatibility device made by the sound server, but it doesn't even exist when you check /dev. It only exists if you actually have OSS installed, after which makes no sense to use ALSA or Pulse. The sound system check should be in the order of Pulse, ALSA and then OSS. Most applications already check in this order.

[Frank Mehnert]

It uses the OSS backend because the initialization didn't fail, actually the OSS initialization can never fail. This is probably a bug but this mechanism was never changed. So this is definitely not a regression.

[Sasquatch]

Then it's not a regression, but still something that can be changed. Please try to get it into the next release. My VMs are awfully silent, the Pulse VMs don't produce audio on my ALSA laptop, and the ALSA VMs are silent on my Pulse PC. ALSA output on Pulse system is broken too I noticed. I can hear sound when I use mplayer to output it to ALSA. When I check the Pulse volume manager, I see the ALSA stream flicker, which means the connection with Pulse is constantly reset until VB is done playing the audio. Native Pulse works flawlessly.

So, double check the audio system calls, something isn't right.

[Sasquatch]

Any progress on this? Possible fix for 3.1.4? Maybe make it a setting like on mplayer media player, where you can set more than one sound system to use, if the first one fails, use the second etc. User defined, instead of hard coded.

[Frank Mehnert]

Well, defining such a user-defined chain requires a bigger change. What we can do is an early check if OSS is available. If not, the next audio backend is automatically selected -- ALSA in this case. How to check if the OSS sound system is available? Check if we are allowed to open /dev/dsp for writing?

[Sasquatch]

Well, since you have my log with the errors of failing things, you can check for the second option. The log says /dev/dsp successful for ADC, but DAC fails. If DAC doesn't fail, OSS works.

Besides, most if not all Linux systems have ALSA, it's part of the kernel. Or at least the basic set of packages.

[Frank Mehnert]

To clarify: Opening /dev/dsp for writing is opening in DAC mode.

[Sasquatch]

Then why does it fail? If opening /dev/dsp for writing is the same as DAC mode, it should not fail, yet it does. It's not logical, writing to it succeeds, but DAC mode fails.

But as I stated before, Linux kernel 2.6 and newer has ALSA by default. /dev/dsp only exists for compatibility but unless an app is specifically started with the OSS compatibility wrapper, it will fail.

[Frank Mehnert]

I've just changed the audio detection order to PulseAudio => ALSA => OSS. I hope this is sufficient.