Sound Hiccups in all Games

[GoogleCodeExporter]

Describe your system:
 - Operating System (be specific): Ubuntu 10.04.2 LTS 2.6.32-30-generic
 - Machine type (32-bit or 64-bit): 64-bit
 - Mupen64Plus version: 1.99.4
 - Plugins used: Rice/Glide for video, Mupen SDL for audio and input, Hacktarux/Azimer for RSP

Describe the problem:
When playing (as far as I can tell any) games, the sound frequently "hiccups".  
It doesn't lose time or go out of sync with the game, it just mutes for a split 
second (a fraction of a beat in most cases).  

Please provide any additional information below.
I'm using an early 2008 macbook witha gma945 intel graphic chipset.  I'm using 
Advanced Linux Sound Architecture Driver Version 1.0.21.  I've tried lowering 
the sampling rate quite drastically as well as moderately increasing it, and 
have also increased the size of the various buffers that are configurable. 

Original issue reported on code.google.com by vash...@gmail.com on 12 Jun 2011 at 9:51

[GoogleCodeExporter]

From the description it sounds like I've got this same problem on 1.5. It 
*used* to work for me without a problem about 18-24 months back on slower 
hardware than I have now, so maybe a newer GCC/glibc/kernel/whatever broke it? 
I'm using an au8830 sound card if that's significant, nothing else gives me 
sound problems though.

No combination of audio plugin settings helps, I've tried changing the system 
clocksource from tsc to hpet, turned off cpufreq, set the process affinity to a 
single core, even tried changing the CFLAGS to something more conservative.

Original comment by flussence on 4 Jul 2011 at 9:53

[GoogleCodeExporter]

Just a thought: could this be caused by the glibc memcpy problem? 
(https://bugzilla.redhat.com/638477)

Original comment by flussence on 18 Jul 2011 at 8:45

[GoogleCodeExporter]

I would doubt that it is this problem - at least not in mupen64plus. But I 
could easily be wrong. You can test it by using memcheck from valgrind and 
search for the failure as explained in 
http://valgrind.org/docs/manual/mc-manual.html#mc-manual.overlap

You should enable debug symbols and disable strip when you build mupen64plus:
$ ./m64p_get.sh
$ ./m64p_build.sh DEBUG=1
$ cd test
$ valgrind --tool=memcheck ./mupen64plus /PATH/TO/TEST/ROM

Original comment by s...@narfation.org on 19 Jul 2011 at 7:10

[GoogleCodeExporter]

You could also test to enable performance governor and to pin m64p to a core:

$ sudo sh -c "echo performance > 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor"
$ numactl -C 0  -- ./mupen64plus /PATH/TO/TEST/ROM

Original comment by s...@narfation.org on 19 Jul 2011 at 7:20

[GoogleCodeExporter]

valgrind doesn't find any problems in sound code. Complains about things inside 
GTK and SDL-input/gfx, but that's all.

Setting cpufreq to performance does make the emulator run a lot better, but 
like I mentioned already it doesn't make a difference with this specific 
problem.

It's almost like the emulated CPU is having these sound dropouts, because they 
sync up with how busy the screen is...

Original comment by flussence on 19 Jul 2011 at 9:26

[GoogleCodeExporter]

Can you try to remove the new_vi delay and try again (be aware that some stuff 
will now ran faster then expected)?

Original comment by s...@narfation.org on 30 Jul 2011 at 11:24

Attachments:

• 0001-Test-audio-core-desynchronisation.patch

[GoogleCodeExporter]

No difference there either :(

Original comment by flussence on 30 Jul 2011 at 12:24

[GoogleCodeExporter]

Issue 433 has been merged into this issue.

Original comment by s...@narfation.org on 9 Sep 2011 at 11:20

[GoogleCodeExporter]

Please try again with the code from 
https://bitbucket.org/ecsv/mupen64plus-audio-sdl  (don't forget to build 
against libsamplerate) and change the RESAMPLE setting to "src-sinc-fastest"

Original comment by s...@narfation.org on 24 Oct 2012 at 6:24