Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sound crackles with the ALSA driver #53

Closed
SDLBugzilla opened this issue Feb 11, 2021 · 0 comments
Closed

Sound crackles with the ALSA driver #53

SDLBugzilla opened this issue Feb 11, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

SDLBugzilla commented Feb 11, 2021

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2008-11-29 16:29:12 +0000, Julius Schwartzenberg wrote:

When I play games using SDL with the ALSA driver, the sound effects crackle. I need to use the OSS driver in combination with aoss to get proper sound.

I have this problem on four systems with several different versions of Ubuntu including Gutsy and Hardy. Online I see others reporting a similar experience with other distros.

This is the corresponding bug:
https://bugs.launchpad.net/ubuntu/+source/sdl-mixer1.2/+bug/66483

The version of libsdl in Ubuntu Hardy is: 1.2.13-1ubuntu1

On 2008-12-14 04:23:56 +0000, laberer wrote:

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."

On 2008-12-16 13:42:11 +0000, Julius Schwartzenberg wrote:

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.

On 2008-12-16 16:18:40 +0000, Julius Schwartzenberg wrote:

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.

On 2008-12-23 15:37:47 +0000, Julius Schwartzenberg wrote:

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

On 2008-12-23 16:14:54 +0000, Julius Schwartzenberg wrote:

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/

On 2008-12-25 06:45:30 +0000, laberer wrote:

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 .

On 2009-07-06 13:52:13 +0000, Karol Nowak wrote:

"--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.

On 2009-07-06 14:51:30 +0000, Julius Schwartzenberg wrote:

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)?

On 2009-07-07 10:01:16 +0000, Karol Nowak wrote:

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

On 2009-07-07 12:43:32 +0000, Julius Schwartzenberg wrote:

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 :)

On 2009-09-15 13:35:11 +0000, Julius Schwartzenberg wrote:

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.

On 2009-09-15 14:36:22 +0000, Karol Nowak wrote:

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.

On 2009-09-15 15:01:32 +0000, Julius Schwartzenberg wrote:

(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.

On 2009-10-03 02:25:41 +0000, Sam Lantinga wrote:

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

On 2009-10-12 02:03:48 +0000, Ryan C. Gordon wrote:

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.

On 2009-10-20 11:53:56 +0000, Julius Schwartzenberg wrote:

(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.

On 2009-10-20 12:06:49 +0000, Sam Lantinga wrote:

Great, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant