If you see this:

vendetta: pcm.c:5959: snd_pcm_mmap_commit: Assertion `frames <= snd_pcm_mmap_avail(pcm)' failed.
*** glibc detected *** double free or corruption: 0x082cfcf8 ***
Segmentation fault

it is ALSA dying and taking Vendetta with it and displaying a cute error message which seems to blame us for its explosion (pcm.c is inside the ALSA library, not vendetta).

So, if you're getting this, please switch to the OSS drivers or update your ALSA libs.

Alternatively, if you're familiar with ALSA development and can suggest a workaround (maybe disable mmap() in /etc/asound.conf? we don't use it..), please do so.

I have this problem. Switching to OSS doesn't seemto help. Neither does disabling audio all together.

Any other ideas?

What ALSA are you running? 0.6.x, 0.9.x or 1.0.x?

1.0.6-8

thx

I am running suse 9.2 x86_64, with MSI platinum neo2 mainboard using onboard sound, Nvidia sound chipset, if that helps...kinda a linux newb :)

Everything works great on a 32bit P4 box running the same distro.

Is the ALSA compiled to use the 32-bit glibc or the 64-bit glibc?

first let me say it's realtek ac97 audio chip...my mistake.

To answer your question, i see a plain alsa package with no bits specified then a second one with alsa 32bit.

I thought to disable the 32bit one, but it would break a bunch of dependencies... =/

as far as which glibc was used, how can i tell? i used yast and it handles those things.

thx for considering the issue

EDIT: I see there are a few glibc, like the alsa, there is one that does not specify bit and one that says glibc-32bit.

Versions glibc - 2.3.3-118, glibc-32bit - 9.2-200410061205, glibc-devel 2.3.3-118, glibc-devel-32bit - 9.2-200410061204

End EDIT

While im not positive, this looks more like a glibc error. To check your current version of glibc just type /lib/libc.so.6, if you would paste the results of that here.

Got the same problem here with SuSE. Any way to disable sound output in vendetta? (just to check whether it is up to alsa or glibc)

One way to disable sound is to tie up the sound device so Vendetta can't use it. Another is to delete ~/.vendetta/drivers/gkalsa.so and osssound.so, then run ~/.vendetta/vendetta (don't use the updater as it will replace those files).

Are you actually seeing the "Assertion failed" message?

Yes, every time I try running it on my AMD64 with SuSE 9.2 64-bit version. My other computer is running ALSA on P4 just fine, no crashes at all. I'll try this workaround next week and post results...

Do you have the 32-bit compatibility versions of glibc and alsa installed?

Yup...

Ok, just deleted gkalsa.so and osssound.so, run the game from .vendetta directory, and guess what? It works like a charm! :)
No sound, though. I find it very disturbing indeed.

Upgraded ALSA to 1.0.8, but there's another error now:

ALSA lib pcm.c:1941:(snd_pcm_open_conf) Cannot open shared library /usr/lib/alsa-lib/libasound_module_pcm_softvol.so

alsa-lib package installed too?
Looks like it can'T find a plugin.

Never had such library. On my Intel box game runs fine without that library. Not to mention that I do not have /usr/lib/alsa-lib/ directory... :)

Heh, there's something extremely borked about your ALSA install, then. I'm not the one who is poking around in /usr/lib/alsa-lib/.

I have RPM-ed new ALSA from Packman's site. SuSE for AMD64 ships with 1.0.6. However, other software runs nicely with new RPM.
Is it possible that vendeta has some hardcoded paths?

After the latest update, the OSS drivers kicked in. Until this update they wouldn't work, but from now on, the sound is sound! :)

Note that I didn't change anything :)

Bizarre. The last update had something or other intended to fix the case where there was no sound. I dunno.

There aren't any hardcoded paths in Vendetta, other than /dev/dsp (heh, and /dev/dsp_gf1 for the totally ancient "perex GUS driver") for the OSS driver device. The ALSA sound drivers just have a library dependency on 'libasound.so.2' (along with libpthread, libc, and libm).

It has to be a glibc issue or some kind of 64/32 bit issue which I'm not too familiar with.

Interestingly, my libasound.so has a reference to /usr/lib/alsa-lib in it also (this can be seen using strings /usr/lib/libasound.so | grep lib), and I have no such directory. Doing the same strings command on ~/.vendetta/drivers/gkalsa.so produces no such path.