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.

Same problem here (Debian Lenny) with snd_intel8x0 module, i need to downgrade to an very old sdl version:

"There are old libsdl1.2 Debian packages available at http://snapshot.debian.net/package/libsdl1.2. By using dpkg to downgrade the libsdl1.2debian-alsa package, I quickly managed to locate the last known-good version, which is "1.2.7+1.2.8cvs20041007-5" (trailing "5"). The version right after this one, "1.2.7+1.2.8cvs20041007-5.1" (trailing "5.1"), has the problem."

The issue seems to be much more complicated than it just being dependent on a certain version of the package.
While the Debian packages provided there already stop working at 1.2.7+1.2.8cvs20041007-5.1, when I compile the original sources myself the first version that give the problem is 1.2.10.
Rebuilding the 1.2.9-0 deb provided on that page using Ubuntu Hardy, gave me a deb which does *not* have the problem. This rebuilded deb can be found here:
http://haar.student.utwente.nl/~julius/libsdl1.2debian-alsa_1.2.9-0.0_i386.deb

Since that 5.1 and 5 are also based on pretty much the same source, I guess it's safe to assume that this difference was also created by differences in the environment used to compile it. (I guess all versions up to 1.2.9 can be made to work well with a recompile.)

Maybe there are multiple problems going on with these versions, but at least I'm certain that 1.2.10 has a problem that 1.2.9 doesn't have yet.

The changes that happened between 1.2.9 and 1.2.10 are quite large (according to the changelog), but I guess it would still be interesting to find out in which SVN revision the problem started.

It seems I'm having some trouble with Subversion.
When I compile this version:
svn checkout -r 2250 http://svn.libsdl.org/branches/SDL-1.2
I get the problem while I don't get it with the 1.2.9 release.
I would expect those to be the same though.

It seems this problem is related to the environment SDL was built in. I discovered that on my system the problem starts to appear between revision 1945 and 1953. (The correct revision for 1.2.9 turned out to be 1652.) The revisions in between those two are not trivially compileable.

In these revisions there haven't really been code changes, just ifdefs have been changed which specify when to use assembly code or not. This made me suspect that all good versions were actually compiled without the assembler code and all bad versions with the assembler (sound) code.

So I tried to compile the latest release, 1.2.13, with the "--disable-assembly" configure option and this indeed gave me a good version!

This seems to explain the weird occurrences of the problem. I suspect that it will not be trivial to find the cause. Maybe the problem has always been in the assembly code, but it just hadn't surfaced before.

I built a package for Ubuntu Hardy for people 

It seems this problem is related to the environment SDL was built in. I discovered that on my system the problem starts to appear between revision 1945 and 1953. (The correct revision for 1.2.9 turned out to be 1652.) The revisions in between those two are not trivially compileable.

In these revisions there haven't really been code changes, just ifdefs have been changed which specify when to use assembly code or not. This made me suspect that all good versions were actually compiled without the assembler code and all bad versions with the assembler (sound) code.

So I tried to compile the latest release, 1.2.13, with the "--disable-assembly" configure option and this indeed gave me a good version!

This seems to explain the weird occurrences of the problem. I suspect that it will not be trivial to find the cause. Maybe the problem has always been in the assembly code, but it just hadn't surfaced before.

I built a package for Ubuntu Hardy for people to test. It can be downloaded from here:
http://haar.student.utwente.nl/~julius/debs/hardy/libsdl/

I just wanted confirm that compiling sdl with the "--disable-assembly" option is working and stops the sound crackling with alsa. 

Source package used here is debian-Lenny version 1.2.13-2 .

"--disable-assembly" doesn't fix the crackling for me on a 64-bit Gentoo/Linux system. Actually, another developer of Wesnoth (Ivanovic) has the same problem.

This problem was originally only experienced on 32-bit systems. I suspect the cracking you're experiencing has a different cause than the crackling fixed by --disable-assembly parameter for 32-bits users.

Maybe you could test the 32-bit version too and see what happens then (with & without the parameter)?

It's also happening on a 32-bit Debian system. However, all 3 systems that I have the reports of crackling from use the emu10k1 driver. On one of them switching to the on-board sound card fixed the issue. I guess the bug we want to look at is: http://bugzilla.libsdl.org/show_bug.cgi?id=650

Yes, it's indeed likely a different problem. This bug mainly occurs with chips using these drivers: ens1371, via82xx, intel8x0 and other AC'97 based chips (there is more info in the Ubuntu bug).

Thanks for putting your notes here, it seems I indeed had to add some more specific details to this bug, but it seems all the info is here now :)

Some more information. The hda-intel module is also affected on Linux.

After mailing with Ivo Danihelka, the main developer of Fish Fillets NG, I got more information on the problem. He works around the problem by using a sound frequency of 44100 in version 0.9.1 of Fish Fillets. These same crackles are solved for 0.9.0 with SDL compiled with the --disable-assembly option.

In addition to this, he told me a user also experienced the problem on "Windows XP pro, DirectX 2009/03, integrated sound card Realtek HD audio with driver WDM R2.25". This is quite new as before the problem only occurred on Linux with just the ALSA driver. Both recompiling SDL.dll for MS Windows with --disable-assembly or using a sound frequency of 44100 remove the crackles, so we are fairly sure this is the same problem.

I suspect the assembly code is having problems when a device cannot play back lower sample rates directly and sample rate conversion is necessary.

I'm afraid we've been using 44.1kHz all the time - the problem is still there. The --disable-assembly solution seems to solve a different bug as it didn't work in my case.

(In reply to comment #12)
> I'm afraid we've been using 44.1kHz all the time - the problem is still there.
> The --disable-assembly solution seems to solve a different bug as it didn't
> work in my case.

Sorry. I was not talking about your bug. Your bug is indeed another one. All the info I wrote is about this bug.

Ryan, here is the bug that talks about disabling assembly.

I disabled SDL's MMX-based mixer code in svn revision #5071. My expectation is that this will fix this issue (in which case, this was an SDL bug, not an SDL_mixer issue, as it was SDL_mixer's use of SDL_MixAudio() in SDL).

Please note that we have a second, unrelated crackling issue with the ALSA target, which we're tracking (and hopefully just fixed, too) in Bug #650.

If you have a game that only crackles when its in-game volume control (not the desktop's volume control1) is set to 100%, this will probably fix your problem.

Please test if you can!

--ryan.

(In reply to comment #15)
> I disabled SDL's MMX-based mixer code in svn revision #5071. My expectation is
> that this will fix this issue (in which case, this was an SDL bug, not an
> SDL_mixer issue, as it was SDL_mixer's use of SDL_MixAudio() in SDL).

This solves the issue for me.

Great, thanks!