[openal] Make OpenAL use ALSA PLUG:DMIX

Roger rogerx.oss at gmail.com
Mon Apr 21 16:43:31 EDT 2014

> On Mon, Apr 21, 2014 at 12:59:51AM -0700, Chris Robinson wrote:
>On 04/20/2014 11:08 PM, rogerx.oss at gmail.com wrote:
>> Gentoo
>> =media-libs/openal-1.15.1-r2
>> I'm trying to get FlightGear to work around my custom .asoundrc file for which
>> intentionally prevents dmix from being used.  FlightGear alongside it's now
>> internal FGCom, tends to assume ALSA is using DMix from the start.  If a user
>> has a custom ALSA $HOME/.soundrc file, FlightGear's internal FGCom may not work
>> at all if the default ALSA dmix is being bypassed, as the sound device is
>> already being used by FlightGear.  And with little error output I may mention!
>> So, I have tried the following without success:
>> $HOME/.alsoftrc
>> drivers = alsa
>> [alsa]
>> device = dmix
>> device-prefix = plug:
>> (Prior versions seem to allow "device = plug:dmix", until device-prefix was
>> implemented?  Many on the mailing lists seem to have used this plug:dmix in the
>> past with success.)
>Setting "device = plug:dmix" should still work as it always has. The 
>device-prefix option only affects discovered devices (i.e. the hw:x,y 
>devices; it allows for replacing the 'hw:' portion of the device 
>string). ALSA Default still uses the device config option as-is.
>> Using the above, and performing the following I can see openal picking up the
>> dmix device, but openal/FlightGear does not use the device and still insists on
>> using the hardware devices only! (ie. aplay -l)
>> AL lib: (II) probe_devices: Got device "Xonar STX, Multichannel (CARD=STX,DEV=0)", "plug:CARD=STX,DEV=0"
>> AL lib: (II) GetConfigValue: Key alsa:device-prefix-STX-1 not found
>> AL lib: (II) probe_devices: Got device "Xonar STX, Digital (CARD=STX,DEV=1)", "plug:CARD=STX,DEV=1"
>> AL lib: (II) GetConfigValue: Found alsa:device = "dmix"
>> AL lib: (II) GetConfigValue: Found alsa:device-prefix = "plug:"
>> AL lib: (II) alcOpenDevice: Created device 0xc989280, "ALSA Default"
>According to this, it's opening the "ALSA Default" device which 
>corresponds to the 'device = dmix' config option, so it is using dmix. 
>The  AL lib: (II) probe_devices: Got device ...  lines are merely 
>logging the extra devices it found for enumeration, but aren't opening them.
>Note that dmix itself will open a hardware device (anything that 
>ultimately plays audio must have a hardware device open somewhere), so 
>when an app opens dmix, aplay -l will show a hardware device as being in 
>use. However, other apps that also try to open dmix will still work 
>since dmix will share the device and do software mixing.

OK. Got it. OpenAL is using plug:dmix when specified, but is grabbing the 
hardware device per aplay -l as normal.  (Just no active DEBUG messages saying 
so.)  So likely, I'm going to have to read some of the FlightGear code and will 
maybe find FGCom not using OpenAL or something similar then.  That would 
explain why FGCom isn't working, as it's still maybe using the .asoundrc 
omitting plug:dmix.  Good thing I contacted this list, as I was going to take 
time to setup a @func within asoundrc.  Time more well spent tracing the FGCom 
at this point I think.

I think I'll also double checking plug:dmix is actively being used, with 
removing my asoundrc file after starting FlightGear might help here to.  (See 
below FYI!)

>Do you have PulseAudio installed? Normally when it's installed, ALSA's 

No.  Double checked just in case (or triple or quadruple check) and Pulse Audio 
isn't installed here.

>> Another funny thing, specifying "frequency = 44100", openal still insists on
>> using 48000 even though this S/PDIF bus do 44100.  Likely this is indicative
>> FlightGear is hard-coding some values?
>An application shouldn't be able to override what you have set (it can 
>provide its own hint, but the config option overrides it). If you 
>specify 44100 and ALSA is opening it with 48000, then ALSA can't open 
>the device with 44100hz and gets 48000hz instead for some reason.

Yes.  I'm familiar with ALSA opening the capable sampling frequency when the 
one specified isn't available on the S/PDIF output.  But my S/PDIF bus is 
capable stereo @16bit/44100.  (ie. CD audio quality)

Sounds like I need to perform more testing to make sure what has been said is 
truly occurring, such as removing the asoundrc file after it's read by 
FlightGear or after FlightGear has started, along with tracing 
FlightGear/FGCom's code to see exactly why they're not working as assumed.

It maybe, FlightGear is using OpenAL, but FGCom is still using the sound bus 
directly.  But that wouldn't also explain why OpenAL is picking up the Capture 
card as well, as FlightGear only uses it for FGCom recording.  Shrugs.

FYI: I just tested FlightGear again and I see OpenAL finding plug:dmix within 
alsoftrc, removed the asoundrc file (ie. "mv .asoundrc .asoundrc.orig") and 
played something else with aplay successfully.  (So safe to assume FlightGear 
is using plug:dmix as specified within alsoftrc!)  Then went back into 
FlightGear and tried using FGCom and FGCom continued to fail to playback or 
capture audio.  I think FGCom is reading the asoundrc separate of what OpenAL & 
FlightGear are doing at some point!  Not only this, but I just further verified 
this hypothesis by removing plug:dmix from asoftrc, defaulting to my asoundrc 
preventing dmix, and I now get the following when trying to play something else 
alongside FlightGear:

$ aplay Sounds/notify.wav
aplay: main:722: audio open error: Device or resource busy

Definite evidence OpenAL alsoftrc is using plug:dmix previously when specified!  
I just don't think I see anything within DEBUG should plug:dmix is actively 
being used, aside from that it's "Found".  In other words, 'Found 
general:frequency = "44100"' as well, but further states an 
"UpdateDeviceParams: Pre-reset: *Stereo, *Signed Short, *44100hz, 1024 update 
size x4", and than a fail message.  So maybe when specifying an asoundrc 
filter, an "UpdateDeviceParams: Using plug:dmix" notice should maybe be made?  
Maybe just haven't coded yet, and similar to other sound driver plugins, as 
upon notice of failure is the only mention within DEBUG was assumed sufficient 
at the time.

I will likely open a separate thread on the sample frequency 44100/48000hz 
issue later.

Sincerely, thanks for your time!


More information about the openal mailing list