Linux + SDL + Alsa. [Solved(?)]

phibxr · Post by **phibxr** » Thu Aug 12, 2004 2:34 pm

There seems to be some very serious issues with ZSNES and (probably) SDL+Alsa under Linux (all distributions I've come across).

It seems to be related to the auto-framerate, because the sound seems to change its framerate multiple times every second, resulting in very strange (although subtle) tempo-changes distorting the whole experience of using ZSNES.

Post by **grinvader** » Thu Aug 12, 2004 2:47 pm

Please post your zsnes configuration, at least the Config -> Options and Config -> Sound menus.

Disabling autoframerate or setting a max frameskip of 0 can have this effect.
I'm running the SDL version using ALSA sound and don't have unstable sound like this.

TKF · Post by **TKF** » Tue Aug 17, 2004 2:16 am

I'm having what I believe is the same problem, I am using SDL(1.2.7), Alsa(1.0.5a), in Red Hat 9 with an upgraded 2.4.26 kernel.
My sound chip is the onboard VIA 8233 (which I think may be the cause of these problems).

Disabling Stereo sound and switching sampling rate to 44100hz helped a GREAT deal.

Also I'm getting this message every time I start ZSNES, but don't know if it is related. Buffer size request varies with sampling rate, but it never seems to get what it wants.

InitSound: 44100hz, requesting 2756 sized buffer, getting 2048.

I hope this is helpful in diagnosing what's wrong, and if I can help, please let me know.

phibxr · Post by **phibxr** » Sat Aug 21, 2004 7:25 pm

I get InitSound: 44100hz, requesting 1378 sized buffer, getting 2048.

It seems to be related.

---

After reading the code i changed my mind. Here's the code, in linux/sdllink.c:

Code: Select all

printf("InitSound: %dhz, requesting %d sized buffer, " , freqtab[SoundQuality], wanted.samples);
	
if (wanted.samples < 256) { wanted.samples = 256; } 
else if(wanted.samples < 512) { wanted.samples = 512; }
else if(wanted.samples < 1024) { wanted.samples = 1024; }
else { wanted.samples = 2048; } // never exceed this.

printf("getting %d.\n",wanted.samples);

As you (probably) can see, you will almost never get the exact value requested. But I still think this problem has something to do with SDL+ALSA.

Post by **pagefault** » Mon Aug 23, 2004 8:41 pm

Is the bug fixed with this code?

phibxr · Post by **phibxr** » Thu Aug 26, 2004 12:42 am

pagefault wrote:Is the bug fixed with this code?

No. That is the actual code from sdllink.c. I just pasted it to show why you (practically) never get the exact amount of requested buffer size.

TKF · Post by **TKF** » Thu Aug 26, 2004 6:35 pm

phibxr : What sound card are you using?
I think this could be related to the fact that the VIA 82xx driver can only take 48000Hz samples, at least for my chip. There is an option you can pass to the kernel module to change this, but doing so breaks all sound on my system.

phibxr · Post by **phibxr** » Fri Aug 27, 2004 6:51 pm

I'm using a SB128PCI (es1371).

Somehow the problem seems to be related to the frameskip-code; because it seems like the 'framerate' of the sound is always changing.

deathpudding · Post by **deathpudding** » Mon Oct 04, 2004 11:56 pm

I'm having the same problem with the CVS version, but I didn't have it with 1.36 (which will no longer compile) a day ago, so it seems to me that this has been introduced by changes made to ZSNES since 1.36.

deathpudding · Post by **deathpudding** » Tue Oct 05, 2004 12:31 am

And, in fact, the bug does seem to be in sdllink.c because replacing it with 1.36's sdllink.c alleviates the problem. Of course, this is no solution.

phibxr · Post by **phibxr** » Fri Oct 08, 2004 12:21 am

I wish I was able to test this, but the CVS-version won't compile when i replace the file. I'll have a look at both versions of the sdllink.c.

deathpudding · Post by **deathpudding** » Fri Oct 08, 2004 9:20 pm

phibxr, I've made a patch that reverts only the sound code to the 1.36 version:
http://deathpudding.empyrealism.net/mis ... 52004.diff

It should be applied in the same directory as sdllink.c. You can get the zsnes version I made it for by using the 'cvs co -D 2004-10-05' option.

phibxr · Post by **phibxr** » Sat Oct 09, 2004 1:40 am

Ah. I'd like to try that, but utfortunately i don't know how to install via CVS. I've just been using the sources provided by the WIP-project. :/

deathpudding · Post by **deathpudding** » Sat Oct 09, 2004 2:54 am

heh :) I assumed since you said CVS version you used CVS to get it. Here's a patched source package:
http://deathpudding.empyrealism.net/mis ... ck.tar.bz2

zidanax · Post by **zidanax** » Sat Oct 09, 2004 9:28 pm

TKF wrote:phibxr : What sound card are you using?
I think this could be related to the fact that the VIA 82xx driver can only take 48000Hz samples, at least for my chip. There is an option you can pass to the kernel module to change this, but doing so breaks all sound on my system.

Hmm, that's interesting, because i've been experiencing "skippy" sound in Linux too, and I have a Soundbalster Live! Value, which I've heard always resamples output to 48kHZ, like the chip you mention. Has anybody else with a Soundblaster Live! experienced sound problems under Linux?

phibxr · Post by **phibxr** » Sun Oct 10, 2004 2:15 pm

deathpudding wrote:heh :) I assumed since you said CVS version you used CVS to get it. Here's a patched source package:
http://deathpudding.empyrealism.net/mis ... ck.tar.bz2

That's great. I'm compiling it now. I hope the developers do know about this bug.

Edit: I just tried it, and it makes the sound better - but it doesn't fix it completely. It still sounds as if the sounds "framerate" is constantly changing - so one sample might begin playing some ms before or after it should.

Edit 2: The improvement is still enormous, and the remaining choppyness in the sound is really subtle - so it might be just imagination.

I still wonder if the developers are aware that many of their Linux-fans are unable to play just because of this bug now that there is another major release ahead of us. They should give it a look at least.

Mikachu · Post by **Mikachu** » Sun Nov 21, 2004 9:57 pm

this fixes the issue for me against latest cvs, basically reverts commit 1.135 in sdllink.c

===================================================================
RCS file: /cvsroot/zsnes/zsnes/src/linux/sdllink.c,v
retrieving revision 1.134
retrieving revision 1.135
diff -u -r1.134 -r1.135
--- zsnes/zsnes/src/linux/sdllink.c 2003/03/02 22:44:08 1.134
+++ zsnes/zsnes/src/linux/sdllink.c 2003/05/19 01:43:18 1.135
@@ -507,7 +507,7 @@
int InitSound(void)
{
SDL_AudioSpec wanted;
- const int samptab[7] = { 1, 1, 2, 4, 2, 4, 4 };
+
const int freqtab[7] = { 8000, 11025, 22050, 44100, 16000, 32000, 48000 };

SDL_CloseAudio();
@@ -538,7 +538,16 @@
wanted.channels = 1;
}

- wanted.samples = samptab[SoundQuality] * 128 * wanted.channels;
+ wanted.samples = (freqtab[SoundQuality] * wanted.channels)/32;
+
+ //printf("InitSound: %dhz, requesting %d sized buffer, " , freqtab[SoundQuality], wanted.samples);
+
+ if (wanted.samples < 256) { wanted.samples = 256; }
+ else if(wanted.samples < 512) { wanted.samples = 512; }
+ else if(wanted.samples < 1024) { wanted.samples = 1024; }
+ else { wanted.samples = 2048; } // never exceed this.
+
+ //printf("getting %d.\n",wanted.samples);
wanted.format = AUDIO_S16LSB;
wanted.userdata = NULL;
wanted.callback = UpdateSound;
@@ -553,9 +562,9 @@
}
SDL_PauseAudio(0);

- Buffer_len = (audiospec.size * 2);
- Buffer_len = (Buffer_len + 255) & ~255; /* Align to SPCSize */
- Buffer = malloc(Buffer_len);
+ Buffer_len = (audiospec.size * 3);
+ Buffer_len = (Buffer_len + 255) & ~255; /* Align to SPCSize */;
+ Buffer = malloc(Buffer_len+1);

return TRUE;
}

deathpudding · Post by **deathpudding** » Sun Nov 21, 2004 10:58 pm

Works perfectly for me too (and thanks to whoever fixed the 100% cpu usage).
But, the above patch needs to be applied in reverse and failed to patch current cvs, so here's one against revision 1.146:

http://deathpudding.empyrealism.net/mis ... 1.146.diff

Mikachu · Post by **Mikachu** » Mon Nov 22, 2004 12:43 am

ah sorry, pasted the cvs commit instead of the actual patch :) the only difference is the commented printfs in the middle hunk.

Poprocks · Post by **Poprocks** » Sun Nov 28, 2004 8:19 am

As with the parent poster, the patch resulted in a huge improvement for me, but the sound still isn't perfect... it sounds a little choppy still. I have a VIA 8233, same as the parent.

EDIT: I tried the prepatched tarball --- and that one works perfectly for me!

phibxr · Post by **phibxr** » Tue Dec 07, 2004 5:29 pm

This bug is still present in the RC. Now that we know in which file it's buried; couldn't someone fix it and submit a patch to the developers? I would if I could, but sadly, I can't. ;(

Post by **Nach** » Tue Dec 07, 2004 5:44 pm

Okay, if someone can explain to me the problem, give me a patch, and explain the pros and cons of the old and new methods, I'll happily commit the patch.

phibxr · Post by **phibxr** » Tue Dec 07, 2004 5:58 pm

A diff has been posted, and that is the closest to a patch I can give you. Hopefully, the one who patched the old version knows more about what he did to it, if he's still around.

The problem is that the sound just seems out of sync, with slight changes in the tempo, giving everything a very strange and "loose" sound (most noticeable in the music).

My first thought was that it might be related to the autoframerate, so that the speed of the sound changes with the framerate; but as I haven't read the actual code I don't know where the problem lies.

If that didn't make much sense, I'll try to illustrate the problem. I'll make an illustration of a short piece of imagined music in a game, only containing a steady drumbeat, represented by a #.

This is how it should sound:

Code: Select all

#---#---#---#---#---#---#---#---#---#

And this is how it sounds:

Code: Select all

#-#---#--#------#-#---##--#----#

This is a very annoying bug, but is mostly fixed in the patched version - so it can be done. There still is something that isn't right, but it may aswell exist in the other versions of ZSNES too.

Post by **Nach** » Tue Dec 07, 2004 6:07 pm

From what I understand the patch is undoing more recent code, are you sure that the changes weren't intentional? Because I'm having better sound now than I had in a while.

phibxr · Post by **phibxr** » Tue Dec 07, 2004 6:13 pm

Are you using ALSA and SDL together? It seems to work just fine with OSS, so those using OSS won't ever notice.