[Openal] Problems with ALSA and the Sample implementation

Jason Daly jdaly at ist.ucf.edu
Fri Jul 27 08:01:30 PDT 2007


Troy Yee wrote:
> I'm working on a Linux app where I want to use OpenAL with
> ALSA.  I'm having some problems with the sample implementation
> from SVN (taken 2007/07/24).
>
> Firstly, I'm assuming that I need the SVN version if I want
> support for AL_SEC_OFFSET.  Please let me know if this is not
> the case.

That is correct.  The offset functions were only implemented recently.


>
> My first issue came when trying to make (after autoconf.sh and
> configure). I'm building 32-bit apps on a x86_64 version of Red
> Hat Enterprise Linux 4, Update 4.  I encountered an error with
> an undefined symbol (PTHREAD_MUTEX_RECURSIVE) in al_mutexlib.c. 
> This symbol should come from <pthread.h> but apparently only
> if the symbol __USE_UNIX98 is defined.  I'm not sure how that
> symbol is meant to get defined... presumably by setting some
> other symbol or by including the appropriate file prior to
> <pthread.h>.  Anyway, my 'fix' was to change the symbol in
> al_mutexlib.h to include _NP at the end (which is the value it
> gets assigned in <pthread.h>).  Everything successfully
> compiles and I was able to run an application but determined
> that it was using OSS rather than ALSA.
>
> My second problem came when attempting to configure with ALSA
> explicitly enabled.  The log resulting from executing configure
> indicated that it failed to find ALSA.  The reason for the
> failure was a failed compilation because a type in
> <alsa/asoundlib.h> was 'incompletely defined'.  I think this
> is because the <time.h> file is not included prior to the
> definition.  I modified the configure script to include
> <time.h> prior to <asoundlib.h> and the configure script
> then succeeded (with respect to ALSA support).  RHEL4 ships with
> alsa-lib-devel-1.0.6-5.RHEL4.  Is something broken with
> autogen.sh, configure, or RHEL4 ALSA here?

I vaguely remember this when we were using RHEL4, but I thought it was 
resolved over time.  Another thing you can do to fix this is to define  
__need_timespec explicitly.  The problem doesn't seem to occur with 
FC6/RHEL5.  Which is what I've been testing with lately.


>
> At this point it seems that the library has successfully
> compiled.  Now when I try to run my application it fails to open
> the sound device.  alcOpenDevice(NULL) fails.  If I have no
> .openalrc file, I get no informational messages.  If I have
> .openalrc with (define devices '(alsa)) and (define alsa-out-
> device "plug:dmix") I get the following from ALSA
>    ALSA lib pcm_dmix.c:868:(snd_pcm_dmix_open) unable to open slave.

Can you run cat /proc/asound/cards and let me know what you get?

Also, what happens if you just use (define alsa-out-device "default")?

-- 

--"J"

"I'm a castaway stranded in a desolate land,
 I can see the footprints in the virtual sand."
	--Neil Peart



More information about the Openal mailing list