We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

We have the same problem with Wesnoth @ 64-bit Gentoo. Both me and Ivanovic use the emu10k1 driver. I've managed to reproduce this problem with vanilla SDL (no SDL_mixer) with a simple test program.

I'm currently testing it with a simplistic pure SDL player. Having a manually compiled latest version of the 1.2 branch actually solves the problem. Now it's time to find the reason of crackling with the system lib.

I've added a timer display to the audio callback in my test app. It displays the number of milliseconds that have passed since the callback has been previously invoked. On a healthy run with manually built SDL:

25
23
23
23
23

System-wide SDL with crackling (reproducible by ctrl+z suspending the process and resuming it):

0
46
0
47
0
46
0
47

Ouch. Looks like it now takes twice as long for it to get called, which probably causes buffer underruns. On the other hand, zeroes indicates that the callback gets called right after it has returned, but in that case it won't have much to write...

I've narrowed down the differences between system build of SDL and my own. The reason why my build worked is because I haven't disabled OSS (with --disable-oss). The "good" timings in my previous comment are produced with SDL_AUDIODRIVER=dsp. The bad ones with SDL_AUDIODRIVER=alsa.

Note that I only have OSS emulation in ALSA, no "real" OSS in my kernel.

I'm back where I started, but at least I have a work-around.

There's a bunch of Gentoo users, including myself, who have been experiencing this. I've seen it with xrick and dxx-rebirth with the -nosdlmixer option. Check out the forum thread.

http://forums.gentoo.org/viewtopic.php?p=5952048

Tagging this bug with "target-1.2.14" so we can try to resolve it for SDL 1.2.14.

Please note that we may choose to resolve it as WONTFIX. This tag is largely so we have a comprehensive wishlist of bugs to examine for 1.2.14 (and so we can close bugs that we'll never fix, rather than have them live forever in Bugzilla).

--ryan.

The SDL audio code may have this problem fixed, can you retest?
http://www.libsdl.org/tmp/SDL-1.2.zip

Tested with the attached sources, the problem is still there. 
Make sure to export SDL_AUDIO_DRIVER=alsa in case you have SDL compiled with both ALSA and OSS as the latter has not been affected.

How much do you want to bet that these are systems that are converting between non-power-of-two sample rates?

--ryan.

No bet.  Suggestions? :)

Thought I should try it too. No change here.

We don't have enough information to track this down yet.

Can you try configuring SDL with --disable-assembly and completely rebuild and reinstall and see if that fixes it?

Are any of you available for an IRC chat to help track this down?

Thanks!

Aaah, Karol Nowak confused me for a bit there, I thought it was working now but it's SDL_AUDIODRIVER, not SDL_AUDIO_DRIVER. Tried --disable-assembly but that didn't help, I'm afraid. I'm a bit busy now but I'll try and get on IRC later.

Can you guys try the very latest SDL snapshot?  There have been a couple tweaks to the ALSA code that may fix this:
http://www.libsdl.org/tmp/SDL-1.2.zip

It's still there in my case. :(

And me.

Hey Ryan, do you happen to have one of these sound cards sitting in a system you can test with?

Hey guys, can you comment with exactly your sound card, distribution, kernel version, ALSA package version, test program, and anything else you think might help?

I definitely want to see if we can track this down before release.

Thanks!

Sound Blaster Audigy Platinum (emu10k1)
Gentoo Linux (recently updated)
2.6.30-gentoo-r6 (have experienced it on earlier kernels)
alsa-lib-1.0.21a (have experienced it on earlier versions)

I always test with xrick. Much smaller than those games mentioned in the first post and it doesn't support SDL_mixer like some games. I'm on IRC right now if you need.

2.6.29-gentoo-r5 #8 SMP x86_64 AMD Phenom(tm) II X3 710 Processor AuthenticAMD GNU/Linux (Experienced with earlier versions as well)

ALSA: 1.0.20-r1 (Experienced with earlier versions as well)

Test program: anything that uses ALSA? Battle for Wesnoth for instance.

Other than that, an ugly test program that uses SDL only is here: http://nopaste.com/p/aneeb1mmJ

Testing with a file with following specs: audiodump.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 44100 Hz

2.6.29-gentoo-r5 #8 SMP x86_64 AMD Phenom(tm) II X3 710 Processor AuthenticAMD GNU/Linux (Experienced with earlier versions as well)

ALSA: 1.0.20-r1 (Experienced with earlier versions as well)

03:07.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 08)
        Subsystem: Creative Labs CT4832 SBLive! Value
        Flags: bus master, medium devsel, latency 32, IRQ 21
        I/O ports at cf00 [size=32]
        Capabilities: [dc] Power Management version 1
        Kernel driver in use: EMU10K1_Audigy

Test program: anything that uses ALSA? Battle for Wesnoth for instance.

Other than that, an ugly test program that uses SDL only is here: http://nopaste.com/p/aneeb1mmJ

Testing with a file with following specs: audiodump.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 44100 Hz

I should add that I'm running a 64-bit system with an Intel Core 2 Quad.

I was googling and found this:
"I found the problem: I had all alsamixer settings set to 100% I went back and 
changed them all to about 75% and it sounds perfect."

I also found this:
http://www.nabble.com/-BUG---audio-cracking-with-SBLive,-ALSA,-and-SDL-td23380082.html

Okay, I found a SBLive card sitting in my closet, and I'm hooking it up to my old 1800+ AMD system and going to try to install Gentoo. :)

Note that my friend reported the very same problem on a 32-bit Debian system.

(In reply to comment #16)
> Hey Ryan, do you happen to have one of these sound cards sitting in a system
> you can test with?

I'm on an Audigy 2 (emu10k1 chip, like several other users here).

--ryan.

And I assume you're not seeing any issues?

Here's a recording which might give you a clue. If you listen carefully, you can hear a little sound from the game. What may be interesting is that the last few seconds should be silent (nothing is happening in the game) but there is still noise.

http://www.aura-online.co.uk/~chewi/xrick.flac

Here's what it sounds like in my case: http://www.speedyshare.com/421977151.html

Clearly mine is a lot worse but there's definitely a problem with yours too. I wonder if these are even the same issue.

I just tried Karol's test program and that works fine with any sounds I try it with. How annoying!

cat /proc/cpuinfo | fgrep "model name" 
model name	: AMD Athlon(tm) XP 1800+

uname -a
Linux mint 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux

ALSA: 1.0.18-1ubuntu11

lspci -v
00:09.1 Input device controller: Creative Labs SB Live! Game Port (rev 05)
        Subsystem: Creative Labs Device 0020
        Flags: bus master, medium devsel, latency 32
        I/O ports at a400 [size=8]
        Capabilities: [dc] Power Management version 1
        Kernel driver in use: Emu10k1_gameport
        Kernel modules: emu10k1-gp

Tested loopwave and xrick with the alsa SDL audio driver...

Result: No audio issues

It works better if I show the correct device:

00:09.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 05)
        Subsystem: Creative Labs Device 0021
        Flags: bus master, medium devsel, latency 32, IRQ 10
        I/O ports at a000 [size=32]
        Capabilities: [dc] Power Management version 1
        Kernel driver in use: EMU10K1_Audigy
        Kernel modules: snd-emu10k1

I just found out how you change the audio device using AUDIODEV. I have a 5.1 surround card and speakers. If I use "default" (which I guess is hw:0,0) then I get noise. I also get noise if I use "hw:0,0" or "front". It works if I use "plug:dmix" and it works with slightly slower sounds if I use "surround50". I get no sound if I use "surround51" but that's probably normal.

Forgot to give my device info.

4:06.0 Multimedia audio controller: Creative Labs SB Audigy (rev 03)
	Subsystem: Creative Labs SB0090 Audigy Player
	Flags: bus master, medium devsel, latency 32, IRQ 16
	I/O ports at cf00 [size=32]
	Capabilities: [dc] Power Management version 2
	Kernel driver in use: EMU10K1_Audigy
	Kernel modules: snd-emu10k1

I have a possible fix in svn revision #5068.

Can people try the latest in the SDL-1.2 branch and see if it fixes the problem?

--ryan.

Looks like you've cracked it, Ryan. The latest 1.2.14 works for me. Having said that, the patch you mentioned applied against 1.2.13 makes no difference. Either another very recent patch actually fixed it instead or your change alone isn't sufficient. Strange. I suppose it doesn't matter now.

If you drop the SDL_alsa_audio.* from SDL 1.2.13 in SDL-1.2.14/src/audio/alsa and rebuild and reinstall, does the problem come back?

Thanks!

Yes and I also tried the converse situation by dropping the new ALSA code into the old SDL. That works so whatever fixed it is contained within that directory.

Okay, thanks!  Can others confirm that their ALSA crackling issues are fixed?

Revision: 5074

It's become much more "interesting" in my case: http://www.speedyshare.com/485329694.html

(In reply to comment #41)
> It's become much more "interesting" in my case:
> http://www.speedyshare.com/485329694.html

What is that from? The test program? Can you try loopwave?

--ryan.

Okay, I've put in a bunch of changes to the ALSA driver, as well as made the PulseAudio driver the default.

Can you all try the latest snapshot?
http://www.libsdl.org/tmp/SDL-1.2.zip

Remember to set the SDL_AUDIODRIVER environment variable to "alsa" or "pulse" or "dsp", depending on what driver you want to test.

Thanks!

Just tried that. All good with ALSA here.

ryan: it is from Battle for Wesnoth (so effectively: SDL_mixer).

Oh dear! Because I've been so busy with work, I didn't bother trying any other games. It seems like all SDL_mixer games now sound quite bad. Sorry for not realising this sooner.

Do they all sound bad with the latest snapshot, or was that a general statement about the currently released code?

I mean SVN. xrick is the only non SDL_mixer game on my system that I can think of. With the latest code from SVN, that's still working fine, but other games that use SDL_mixer like Neverball, D1X-Rebirth, Hedgewars and Frets On Fire all sound terrible.

Sorry, still need to clarify that, I think. The SDL_mixer games worked fine for me before. It was only xrick that was causing a problem. The "fix" has broken the others.

Can you edit src/audio/alsa/SDL_alsa_audio.c and uncomment the two PERIOD defines at the top and retest?

Thanks!

Is anyone available to sit on IRC and work through this with me tonight?

See ya!

Okay, I found someone on the ioquake3 channel that was having issues, and I think we have them resolved:
http://www.libsdl.org/tmp/SDL-1.2.zip (or just update from subversion)

Can you all try this version and see if it works for you?

If it doesn't, can you edit src/audio/alsa/SDL_alsa_audio.c and enable the DEBUG define at the top, and post that here?

Then, enable the SET_PERIOD_SIZE define and see if that improves things, and also post the debug output for that as well.

Thanks!

That's sorted it for all the games I mentioned. You certainly got some interesting feedback on the ALSA list. Shows that it can still be something of a black art even for someone as experienced as yourself.

Fixed both of my test cases (SDL_mixer and plain SDL) with SDL_AUDIODRIVER=alsa. Good job!

Great!  Thank you guys very much! :)

Hey guys, I made one last pass on ALSA sound support. Can you grab SDL from http://www.libsdl.org/tmp/download-1.2.php and try it out with SDL_AUDIODRIVER=alsa SDL_AUDIO_ALSA_DEBUG=1 and let me know if it works?
Thanks!

Yep, all good here.

Great, thanks!