Please test it with this version http://koji.fedoraproject.org/koji/buildinfo?buildID=140254

I'm in the process of doing that, but just as a heads up you didn't bump the release number and the git hash ended up being lower so it doesn't show as an update. I can test it, but you'll need to rebuild it for a real update.

openal-soft-1.9.563-2.c1b161b44bbf60420de2e1ba886e957d9fcd495egit.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/openal-soft-1.9.563-2.c1b161b44bbf60420de2e1ba886e957d9fcd495egit.fc12

Fixed the version problem.

I started testing with the original fixed version and it is having some problems.
When using drivers = pulse in /etc/openal/alsoft.conf glest fails.
bash-4.0$ glest
Assertion 'm->n_waiting_for_accept > 0' failed at pulse/thread-mainloop.c:221, function pa_threaded_mainloop_accept(). Aborting.
Aborted
And warzone2100 has extremely crackly sound.

With drivers = pulse commented out glest sound is clean, but the volume controls in glest don't work.
And warzone2100 segfaults just after displaying some graphical output.

have you an log from warzone too please?
I will contact then upstream.

For warzone I just got the word "segfault" in the case where it crashed.

I'll try repeating the tests on another machine as well. Lately there have been some issues related to vector instructions (mmx) and sound, so I should try it on a different x86 type machine.

I suspect there is some mmx or ss2 related stuff going on here.
I tried warzone on the other machine and the volume controls seemed to work reasonably regardless of whether drivers = pulse was commented out.
Unfortunately glest won't run on the other machine currently and I don't want to install the proprietary driver on that machine at this time.
I'll have access to an x86_64 machine for doing brief tests on Monday.
I am going to look through build logs to see if I can find any of warzone2100, glest ot openal-soft doing any vector optimization.
pulseaudio has a bug with mmx right now, and that may explain the crackling I heard in warzone2100. I haven't see that affect volume controls though, so I don't think that explains all that I seeing.

I tested warzone both before and after on my old xeon and the update you made gets drivers = pulse to work. The volume control for warzone2100 seems to work in either case for the case where drivers = pulse is commented out. So the changes did help get the pulse driver plugin for openal-soft to work.
I fudged the 3d check for glest to get the game to fire up. For the new package. In the the drivers = pulse case I got the same message as on my athlon MP system. When that was commented out the game segfaulted. With the older package the game started up but ran too slow do do anything. There was no sound, but that may have been related to the game running too slow.

Does the assertion message sound like something that could be caused by glest not using the api correctly? I took over glest relatively recently and haven't taken an in depth look at the code. If there is fault on the glest side, I would need to fix that.

For warzone, I was just looking for another openal-soft user to compare behavior against glest's.

I have talked with with the openal-soft team on the irc and they have me said that they are working on better pulseaudio support but the said too that pulseaudio have bugs too and the fedora pulse manitainer know that i think.
I will take an look on the next git changes on openal-soft and update openal-soft when i see that the have changes that are related to pulseaudio.

OK. I'll retest when I see either new openal-soft or pulseaudio packages arrive and provide feedback. Thanks.

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

i have that problem with my SecondLife client, 2... :-)

and with "openal-info:
AL lib: pulseaudio.c:478: tlength (19836) is not a multiple of minreq (4096)!
Available playback devices:
    PulseAudio Software
[...]

-arne

My output from openal-info is:

[LinuxDonald@localhost ~]$ openal-info
Available playback devices:
    ALSA Software on default
    ALSA Software on HDA Intel [STAC92xx Analog] (hw:0,0)
    ALSA Software on HDA Intel [STAC92xx Digital] (hw:0,1)
    ALSA Software on HDA Intel [NVIDIA HDMI] (hw:0,3)
    OSS Software
    PulseAudio Software
Available capture devices:
    ALSA Capture on default
    ALSA Capture on HDA Intel [STAC92xx Analog] (hw:0,0)
    OSS Capture
    PulseAudio Capture
Default device: ALSA Software
Default capture device: ALSA Capture on default
ALC version: 1.1
ALC extensions:
    ALC_ENUMERATE_ALL_EXT, ALC_ENUMERATION_EXT, ALC_EXT_CAPTURE, 
    ALC_EXT_disconnect, ALC_EXT_EFX, ALC_EXTX_thread_local_context
OpenAL vendor string: OpenAL Community
OpenAL renderer string: OpenAL Soft
OpenAL version string: 1.1 ALSOFT 1.10.622
OpenAL extensions:
    AL_EXTX_buffer_sub_data, AL_EXT_EXPONENT_DISTANCE, AL_EXT_FLOAT32, 
    AL_EXT_IMA4, AL_EXT_LINEAR_DISTANCE, AL_EXT_MCFORMATS, AL_EXT_OFFSET, 
    AL_EXTX_sample_buffer_object, AL_EXTX_source_distance_model, 
    AL_LOKI_quadriphonic
EFX version: 1.0
Max auxiliary sends: 2
Available filters:
    Low-pass
Available effects:
    EAX Reverb
    Reverb
    Echo
[LinuxDonald@localhost ~]$

hm - u use alsa as default, while i use pulseaudio as default...

when i use the pulse-alsa-plugin, it doesnt work...

-arne

Where do you use this "pulse-alsa-plugin"??

And i use as default pulseaudio it is the standard audio system under fedora.

what version of openal-soft are you using?

u use it, i guess: "ALSA Software on default"
i mean: alsa-plugins-pulseaudio
at least my box uses it, when i use the default drivers settings for openal...
btw: in a test with 1.9 for SLVoice and 1.10 for SLclient and that alsa-plugins-pulseaudio i heard someone for 2 seconds or so and then i couldnt hear him anymore, although there were green lines above his head (they show that voice data is arriving)...

i tried 1.8, 1.9 and 1.10 in various combinations for the original 32bit SLVoice and the home-brew 64bit SLclient (they both run at the same time and both need access to the sound system)...

i opened this Bug #539508, 2, because it seems like the older pulseaudio version was nicer than the new one... -arne

openal-soft-1.10.622-3.3793919892e6d61e5fec3abeaaeebc3f2332be13git.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/openal-soft-1.10.622-3.3793919892e6d61e5fec3abeaaeebc3f2332be13git.fc12

I'll be testing this update shortly.
Did you really mean to go directly to updates, and not updates-testing, with that build?

linuxdonald - 2009-12-26 14:57:03

This update has been submitted for testing

This version does fix the pulse assertion failure problem on my rawhide
machine.
I can't test the fix on my home f12 machines since glest won't run on them due
to the video card. However the new build didn't seem to break anything (in
particular warzone2100) on either F13 or F12.

I still am seeing a volume control issue with glest, but that's probably going
to be my job to figure out.

Now that it is in testing I'll also give some karma.

that bug with pulse assertion failure is fixed in pulseaudio 0.9.22 ....

And thx for testing :)

hm - for me (i686 --> x86_64) the openal-soft update doesn't solve the problem with SLVoice... -arne

that can be an SLVoice problem i think?

but it worked fine in fc11...
the openal-soft guys think, it is an error in the pa-lib.i686 to pa-lib.x86_64 communication...
-arne

Then it is an pulseaudio bug.
I hope it is fixed in 0.9.22 but i don´t know when 0.9.22 comes out.
I will close that bug report here. For other that have problems with SLVoice here is the bug ticket:

https://bugzilla.redhat.com/show_bug.cgi?id=539508

openal-soft-1.10.622-3.3793919892e6d61e5fec3abeaaeebc3f2332be13git.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.