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 attachment 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 attachment 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 ;-)
