this post is so long I solved my problem by the time I finished writing it

[shodan]

Hi,

first some information on my systems

system A is
AMD AthlonXP 1800+ CPU w/256MB DDR
Biostar M7VIG 400 Pro Via KT400-based board
using onboard sound (Via vt8235 with C-Media Electronics (id83) chip) using compiled-in alsa snd-via82xx driver
usb keyboard mouse and controller and a Logitech WingMan RumblePad
video card is Hercules GF2 TI 64mb agp , running on the tv out
the os is a well maintained gentoo linux
the X server is xfree86-4.3.0.1 running nvidia drivers version 1.0.6111
kernel 2.6.9

system B is
AMD AthlonXP 1800+ overclocked to 1916mhz (fsb 333 instead of 266 , I made
sure it is stable enough to root out the possibility of this being the cause of the problems)
Biostar M7NCG nForce2-based board
onboard sound is nForce2 (Realtek ALC650E chip) using compiled-in alsa snd-intel8x0 driver
the video is onboard GF4MX (NV18) using 64mb of dedicated system memory
same os same kernel same X server but nvidia drivers 1.0.6629

both system have mupen64 installed the same way
I have mupen64 0.3 compiled from source with the following plugins (I'm not sure I compiled JttL's SDL pluggin nor the uhle audio plugin)

TR64 opengl 0.7.4
TR64 opengl 0.7.8
TR64 opengl 0.8.7-pre1
glN64 0.4.1
Glide64 0.7 ME SP1

mupen stock audio plugin (0.1)
mupen64-alsasnd 0.4
uhle audio plugin 0.1a
JttL's SDL audio plugin 1.2
dummy audio

mupen stock input plugin
Blight's SDL plugin 0.0.8b

hacktarux hle rsp 0.2
hacktarux/azimer hle rsp 0.2

the "best" I managed so far is using
Glide64 0.7 + mupen alsa2 + Blight's SDL input plugin 0.0.8b + Hacktarux/Azimer HLE RSP Plugin 0.2

the video is fine centering at about 30 fps , I remember a while ago I played a couple hours at
super mario 64 and some scenes the fps would go below that , usually it stays within 2 fps of 30 fps
but some scene it could go as low as 20 , still not too distracting but if I remember correctly (I
will try to confirm this later tonight) when the fps went lower than 30 , the sound problem was worse

the problem is the sound
I recorded a sample (from the system B , whose output is going to the in of my big workstation then
to the sound system so it was easy to record)
http://www.domn.net/mupen64-output-sample.ogg
you can hear some cracking in the sound
I'm not 100% sure about this but I thing the crackling happens most at the beginning and end of the
ingame samples and computer generated voice , (like mario's voice , if it's really generated vs being
a recorded sample)

I tried other plugins
first the dummy audio plugin , the framerate was much higher , but the game speed was also higher , the
fps changed wildly often over 100fps sometimes back to 30, the game was probably going at 150% speed

the mupen64 stock audio plugin 0.1 , the sound was similar to the alsa plugin , but image freeze for about
100ms every half-second , it has the same crackling sound problem as the alsa plugin
the freezing is a lot less of a problem in game , I don't know if it's because it's harder to notice or
because the problem is happening less , in menus it's very obvious but that may be just because I have a good
reference (the hand cursor I control with the gamepad)

with the uhle plugin I have the crackling but the game is accelerated and the sound pitch is down , also in
the console I notice it says "Setting frequency 32006hz" , the game is much faster than with the dummy plugin
maybe 4x the normal game speed , the frame rate is almost always above 80fps ,while trying this pluggin I
started star fox 64 the pitch down makes the voice "acting" slightly more tolerable

when pressing play with JttL's SDL plugin I get
[blight's SDL input plugin]: version 0.0.8-b initialized.
(II) Initializing SDL video subsystem...
(II) Getting video info...
(II) Setting video mode 640x480...
(EE) Cannot open config file.
(II) JttL's sound plugin version 1.2
(II) Initializing SDL audio subsystem...
ALSA lib pcm_hw.c:1172snd_pcm_hw_open) open /dev/snd/pcmC0D0p failed: Device or resource busy
ALSA lib pcm_hw.c:1172snd_pcm_hw_open) open /dev/snd/pcmC0D0p failed: Device or resource busy
(EE) Couldn't open audio: No available audio device
Xlib: unexpected async reply (sequence 0x36586e)!

.................
........
CRAP !



as I was writing this msg I'm retrying each plugin and I still try to fix my problem , and now I just did !!
JttL's plugin work if I sudo mupen64
(that's strange , because /dev/snd/pcmC0D0p is owner by root:audio mod 660 and I'm in the audio group)
last time I tried I stopped when I got the error , I tought oh I probably don't have sdl-sound installed that's
probably why (emerge -s sdl was agreeing with me , but sdl-sound is a lib to use sdl , sdl sound is part of the
sdl ebuild so the sound part of sdl was working fine)

so with the JttL plugin it works fine , I'll try out other games to see if I can find any problems , super mario
is probably the most tested game so I guess it's normal it's working fine


btw, since the begining I've been running with the "Interpreter" CPU Core , the pure interpreter works fine too
but it looks a lot slower , and with the pure interpreter the sound problem appear to be back but it's probably
not the exact same problem it sounds a bit different and the game is slowed down according to what's on screen (more
complex scenes are slower and the sound problem gets worse) , I guess this is normal ..

trying both the interpreter and the pure interpreter I notice , using top with 0.5 interval , that the cpu usage
with the interpreter is 20% idle at it's worst about 50-60% idle during the game and 80-90% idle in menus
also I notice that when the cpu usage gets to 20% and lower (like in super mario 64's intro , with mario's head)
the sound start to have some artifacts , it sounds like it's missing notes (barely noticeable), and some very faint
cracking (maybe I'm hearing things now .. I tried to record a sample it's not there anymore , a ghost in the machine I guess)

next I tried the dynamic recompiler , but it crashes
here's the output
-------
shodan@glitch shodan $ sudo mupen64
rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
file found
rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
byteswaping rom...
rom byteswaped
rom loaded succesfully
80 37 12 40
ClockRate=f
Version:1444
CRC: 635a2bff 8b022326
name: SUPER MARIO 64
Manufacturer: Nintendo
Cartridge_ID: 4d53
Country : United States
size: 4096
PC= 80246000
md5 code:20B854B239203BAF6C961B850A4A51A2
init timer!
memory initialized
[blight's SDL input plugin]: version 0.0.8-b initialized.
(II) Initializing SDL video subsystem...
(II) Getting video info...
(II) Setting video mode 640x480...
(EE) Cannot open config file.
(II) JttL's sound plugin version 1.2
(II) Initializing SDL audio subsystem...
(II) Allocating memory for audio buffer: 65536 bytes.
demarrage r4300
recompilation dynamique
Signal number 11 caught:
errno = 0 (Success)
Xlib: unexpected async reply (sequence 0x13a5a)!
(the program is doing nothing at this point but as soon as it gets the focus back ...)
Signal number 11 caught:
errno = 0 (Success)
--------

at this point mupen64 is running smooth , I just started star fox 64 , and one of the
worst scene was the star map , it really bogged down the system now it's fine , it
would go down to 1 fps now it's doing 28fps ....
.... I let it run the star map scene (it's a 3d star system that rotate very slowly ,
there are lots of small objects like a asteroid belt and each asteroid is a different
3d object , not a sprite at least as far as I can tell) at the beginning everything is
fine , but as the camera moves around the starsystem the sound start skipping , the
frame rate drop to 23/27 (23 for the duration of the few milliseconds of skip)

http://www.domn.net/mupen64-output-sample-starmap.ogg

I guess I'm just reaching the limit of this machine , maybe I can setup the other plugin to use less juice ..

btw, is emulation64.com down ? I'm getting Connection refused with both www.emulation64.com and mupen64.emulation64.com

shodan
ve2ehf

[Hacktarux]

yea, emulation64.com is down currently, it'll be back as soon as martin get some free time (that can take a few days as it's christmas and everybody has a lot of better things to do during christmas than fixing a server :p

Your dynamic recompiler problem shouln't occur if you use mupen 0.4, the only problem is to find a place where it can be downloaded if you don't want to wait the server fix...

Edit: the binary verion can be found here: http://www.ngemu.com/n64/mupen64.php...req=emu&id=340