Richard Goedeken

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

``` Just a thought: could this be caused by the glibc memcpy problem? (https://bugzilla.redhat.com/638477) ``` Reported by `flussence` on 2011-07-18 20:45:02

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

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

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

``` Can you try to remove the new_vi delay and try again (be aware that some stuff will now ran faster then expected)? ``` Reported by `[email protected]` on 2011-07-30 11:24:41...

``` No difference there either :( ``` Reported by `flussence` on 2011-07-30 12:24:01

``` Issue 433 has been merged into this issue. ``` Reported by `[email protected]` on 2011-09-09 11:20:56

``` 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" ``` Reported by `[email protected]` on 2012-10-24 18:24:45

``` As you said, virtually all modern GPUs can force this through their drivers. I have also never seen any quality difference. ``` Reported by `school.player` on 2012-04-18 00:50:26