Bugzilla Bug 193147

Summary
=======
No sound from OpenAL apps when using the ALSA backend on an Intel HDA soundchip
until sampling rate is explicitly set to 44.1 kHz in both .asoundrc (or
/etc/asound.conf) AND .openalrc.

Description
===========
There is no error message, apps using OpenAL simply remain silent. I did test
this with UT2004 (using the systems libopenal.so instead of the one shipped
with UT2004) and FlightGear. But I am pretty sure that the problem is at the
OpenAL layer and affects all apps using OpenAL.

Sound works fine otherwise (ALSA and ALSA OSS emulation in mplayer, xine,
amarok ... everywhere but in OpenAL apps). And using OpenAL with the "native"
backend (/dev/sound/dsp provided by ALSA OSS emulation) works with 48kHz, too
(but grabs the soundcard exclusively, so no dmix possible, and has some (minor)
audible artifacts).

System
======
- IBM/Lenovo Thinkpad Z61m, 2 MB RAM
- Kernel: Linux spock 2.6.22-gentoo-r5 #5 SMP PREEMPT Tue Sep 18 20:48:14 CEST
2007 x86_64 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux
- Intel HDA (AD1981)
- ALSA modules from kernel ("Advanced Linux Sound Architecture Driver Version
1.0.14 (Thu May 31 09:03:25 2007 UTC")

I will post my "emerge --info" output on request, but do not think it is
relevant for the bug at hand.

Workaround
==========
After explicitly forcing the sampling rate to 44.1 kHz (by adding "rate 44100"
to /etc/asound.conf and "(define sampling-rate 44100)" to ~/.openalrc) sound
from OpenAL apps works perfectly fine (without "crackles" or glitches).

I also told the ALSA module my exact model name by adding "options
snd-hda-intel model=thinkpad" to /etc/modules.d/alsa. But I'm not sure whether
this is necessary.

Expected behaviour
==================
I want to be able to run OpenAL -> ALSA at the "natural" sampling rate of my
Intel HDA sound card (= 48kHz) to avoid sampling rate conversion (both for
perfomance and quality reasons).

Additional info
===============

Working /etc/asound.conf
------------------------
pcm.!default {
        type plug
        slave.pcm "dmixer"
}

pcm.dmixer {
        type dmix
        ipc_key 1024
        slave {
                pcm "hw:0,0"
                channels 2
                period_time 0
                period_size 2048
                buffer_size 4096
                rate 44100
        }

        bindings {
                0 0
                1 1
        }
}

ctl.dmixer {
        type hw
        card 0
}

Working ~/.openalrc
-------------------
(define devices '(alsa null))
(define alsa-device "default")
(define speaker-num 2)
(define sampling-rate 44100)

I am pretty sure that this an OpenAL bug that has to be fixed upstream, but it
took me quite some time to figure this out and finally get ("dmix"ed) sound
from OpenAL. Possibly Gentoo can come up with a patch (maybe something like
already proposed at
http://thread.gmane.org/gmane.comp.lib.openal.devel/2034/focus=2034).

Feel free to close this bug if you think it is nothing that Gentoo should care
about. But even then the report may still serve as a solution for others having
the same problem ;-)

Created an attachment (id=131357) [details]
For Intel HDA. Provides full-duplex and forces 44.1 kHz sampling rate.

Note: With the asound.conf from the bug report UT2004 complains about dmix
having no capture support (but it works still fine, anyway). The asound.conf
file attached in comment #1 fixes this by adding dsnoop to the mix to provide
full-duplex.

And remember to run "/etc/init.d/alsasound restart" as root after changing your
ALSA config. I had a very confusing and frustrating time before doing so,
because sometimes changes seem to be not picked up correctly otherwise ;-)

This comment is not relevant for the bug itself (= unable to use 48kHz sampling
rate with OpenAL) but may help if you want to try the workaround yourself.

OK.  I added a modified version of the upstream patch since it applies to the
SVN code.  Let me know if you're still having problems.

Created an attachment (id=131558) [details]
Results for ALSA / OpenAL sample rate compatibility

Since things became more and more confusing to me, I decided to bite the bullet
and test the results of all possible ALSA / OpenAL / OSS sampling rate
combinations. The result is attached as textfile in comment #4, to prevent my
"ASCII art" tables from being munched by bugzilla ;-)

TAKE A LOOK AT THE ATTACHED TEXTFILE! Well, the variety of results was kind of
a surprise to me. Now I understand why the question "No sound with game XYZ?"
is so difficult to be answered in a "now works for everyone" way.

I suggest to remove the 005_all_alsa_default_freq.patch again, since the odds
to get perfect OpenAL 44.1kHz sound are slightly better without it, and the
less patches the better. Sorry for suggesting that basically useless patch :-(

After enjoying the OpenAL sources from subversion trunk and diffing the "debug
maximus" (sounds like something developed by Harry Potter ;-) messages from
working and non-working runs it seems that the sampling rate conversion stuff
in OpenAl-Sample (the Linux implementation) is still seriously broken even in
current OpenAL. Different sample rates on input (sound) and output (backend)
are simply a no-go ATM.

Conclusion:
- Since games use 44.1kHz sounds (does anyone know one with 48kHz sounds and
  using OpenAL?),
- and since OpenAL is mostly used with games (the only exception I know of is
  the 3D-Modeller Blender),
- and since using OSS disables DMIX capability,
the only viable options for gamers are #6 and #7 (from the table without
005_all_alsa_default_freq.patch, see attached file).

So, if you want sound from OpenAL with games (44.1kHz), and

... your soundcard defaults to 48kHz, you 
-----------------------------------------
- *HAVE TO* provide an /etc/asound.conf forcing the card to 44.1kHz sampling
  rate (see attachment from comment #1 for an example).
- *HAVE TO* provide an /etc/openal forcing ALSA default device usage (instead
of
  using OSS):
        (define devices '(alsa))
        (define alsa-device "default")
- *MAY* explicitly define the sampling rate in /etc/openal with the additional
  line:
        (define sampling-rate 44100) 

... your soundcard defaults to 44.1kHz, you
-------------------------------------------
- *MAY* provide an /etc/asound.conf leaving the card at 44.1kHz sampling rate
  (see attachment from comment #1 for an example).
- *HAVE TO* provide an /etc/openal forcing ALSA default device usage (instead
of
  using OSS):
        (define devices '(alsa))
        (define alsa-device "default")
- *MAY* explicitly define the sampling rate in /etc/openal with the additional
  line:
        (define sampling-rate 44100) 

... your soundcard defaults to 48kHz and does not work with 44.1kHz, you
------------------------------------------------------------------------
- *MAY* provide an /etc/asound.conf (but you can not do anything about your
  sample rate) (see attachment from comment #1 for an example).
- *MUST NOT* have an /etc/openal at all, or one that explicitly selects OSS
via:
        (define devices '(native))
- *HAVE TO* accept that you can not currently play OpenAL games and have DMIX
at
  the same time, as you must use the OSS emulation ;-)

As on how to proceed, I suggest adding an ewarn and / or README to the openal
ebuild that explains the issue / points to this bug, and close this bug as
resolved. Additionally I will put a pointer to this bug on the openal mailing
list. The developers seem to be more focused on the Windows version these days,
but IMHO we should give it try anyway.

I had to increase the buffer size on my system or mplayer audio (using alsa)
was glitchy (crackling) but besides that I made no changes from the other notes
in here thus far.

Matthew,
glad it worked for you. Yes, configuring ALSA on your system may of course
involve changing parameters like buffer/period sizes, number of periods, module
parameters etc. That's a topic on itself. But even after you have a perfectly
working ALSA, you still have to watch out for some nasty pitfalls to get
*OpenAL* running on top of it. And that's what this bug is about ;-)