What's new

New version of SDL audio plugin

JttL

New member
Well I'm still alive, though it's been a while since I last posted here. That is mainly because I was in the Finnish defence forces for one year as conscript. But now I'm back and when I few weeks ago downloaded 0.4 mupen and started playing Zelda OOT: MQ I found out that my very own sdl audio plugin has still a lot of work to do. For example config file is more trouble than use and still no config dialog.

Well after that I reopened the project and stated hacking. Now I have much better config -file handling, automatic buffer adjustments, config -dialog! and some performance improvements. I have also been testing other audio libraries for output and results are promising.

Now I ask from you is there anything in the audio you would like to have? or be able to do before I release next version? Any bugs found from the old one?
 

Kethinov

New member
Welcome back! My biggest request would be an option to silence the audio, but continue to use the plugin to regulate the VI/S, so I can play games whilst XMMS is playing music. :)
 

txOjO

MDKEiToR
Hey jttl! welcome again :bouncy: . Your plugin runs very fine for me, not found any changes with mupen0.4 only the same as you in masterquest
good job!
 

aminalshmu

linux gaming enthusiast
hello jttl,

i am trying to achieve perfect (or at least, decent) n64 emulation with mupen 64 on gentoo linux. however, my biggest problem has been the audio plugins. the only one i can get to produce any sound at all is the plugin that comes with the emulator, and the sound is very choppy (i think many people have this problem). when i try using your plugin, i get this:

(II) JttL's sound plugin version 1.2
(II) Initializing SDL audio subsystem...
Signal number 17 caught:
errno = 0 (Success)

actually, nevermind. recompiling libsdl and then your plugin fixed it.

wow, it actually works almost perfectly. awesome. I'm glad i can finally play ocarina of time and mario 64 without any real problems. i will look forward to a new release! :bouncy:

thanks,
jordan
 

juwb

New member
JttL said:
Well after that I reopened the project and stated hacking. Now I have much better config -file handling, automatic buffer adjustments, config -dialog! and some performance improvements. I have also been testing other audio libraries for output and results are promising.

Looking forward to the release :bounce:
 
OP
J

JttL

New member
I have been lately working hard to finnish new version and I'm very near a public beta. But before that I would like to have a bit more closed alpha testing stage. If your interested in to get early peak what is coming send your email to me as private message.
 

dtm

New member
Please note that I just solved the problem as is described below. I'll leave it for future reference. The solution was that SDL was trying to use esd which doesn't work for some reason. So I did this ...

export SDL_AUDIODRIVER=dsp ./mupen64

And it uses the OSS driver which does function.

aminalshmu said:
(II) JttL's sound plugin version 1.2
(II) Initializing SDL audio subsystem...
Signal number 17 caught:
errno = 0 (Success)

actually, nevermind. recompiling libsdl and then your plugin fixed it.

Hello, and thanks to JttL for his fine work. I'm having the same problem. I have a 1300 MHz Duron, a GeForce 4 440mx 64MB AGP 4x, and CentOS 4.2. I have SDL 1.2.7. I get that error whenever I have JttL's SDL audio enabled, the moment that a ROM is started. I ran an 'strace' on it and it says the following:

[blight's SDL input plugin]: version 0.0.10 initialized.
[glN64]: (II) Initializing SDL video subsystem...
[glN64]: (II) Getting video info...
[glN64]: (II) Setting video mode 640x480...
(II) JttL's sound plugin version 1.3
(II) Initializing SDL audio subsystem...
[{fd=3, events=POLLIN, revents=POLLIN}, {fd=5, events=POLLIN}], 2, -1) = 1
futex(0x60e820, FUTEX_WAIT, 2, NULLSignal number 17 caught:
errno = 0 (Success)
) = -1 EINTR (Interrupted system call)

You see that it gets a Signal 17 which is a SIGCHLD, meaning that a child died. I guess it's referring to the child spawned for the emulator window. This happens regardless of any other configuration such as video plugin. It happens whether I'm using the binary mupen64 distro from the web site or whether I built the source. I rebuilt my SDL as well, to no avail. Is this a problem with SDL or with mupen64's SDL plugin?

You can see the whole 'strace -f mupen64' here: http://smuckola.org/etc/mupen64_strace_log.text

I appreciate any suggestions, comments, or workarounds! I'm so close! Once I get this working and once I get all the Adaptoid's buttons working, I'll be all set! I've been working on this for so many days that I've taken to attempting UltraHLE under Wine with a glide-to-opengl wrapper!! :}

Thanks.
 
Last edited:

dtm

New member
My next problem is that using either the JttL SDL audio plugin or the built in mupen64 audio plugin, my audio is slightly choppy and hence the whole virtual machine slows for an instant at a time. The graphics are great in any case, and I can go to 1024x768 with virtually identical results. Only at 320x240 does it make any difference and it's only barely less choppy. This is the case in all of my commercial game ROMs. CPU usage never goes above 93%, usually hovers at 80-86%, with mupen64 set to 'nice -10' and no other processes active.

Overall behavior is identical using either audio plugin until I edited jttl_audio.conf.

I set these:
PRIMARY_BUFFER_SIZE 1048576
LOW_BUFFER_LOAD_LEVEL 65536
HIGH_BUFFER_LOAD_LEVEL 1048576
SECONDARY_BUFFER_SIZE 8192

Now I get different results in different games or, I suppose in different parts of games. In Zelda64's title sequence and gameplay, I get audio dropouts very infrequently; I now get one big one lasting a few seconds while the video continues, and the audio and video are no longer in synch. The durations involved are proportionate to the size of the LOW_BUFFER_LOAD_LEVEL. In Mario64's title sequence I still get dropouts but in gameplay, I get no more dropouts ever so far, but all audio is continuously latent by about a second.

I'm using Alsa 1.0.6 with AC97 hardware. The SDL plugin's output won't work directly on Alsa, as is set by "export SDL_AUDIODRIVER=alsa" so I set it to "export SDL_AUDIODRIVER=dsp" to use OSS emulation. An Alsa howto suggested this for latency, to be put in your ~/.asoundrc:

period_size 1024
buffer_size 4096

That does me no good. Any suggestions?
 
Last edited:

dtm

New member
JttL, I'd like to invite you and everyone else to #mupen64 on efnet (irc.prison.net). There's me (dtm) and one other person, GoGi, who are Linux users who'd like to help test your plugin or do whatever else we can do.

Thanks!
 
Last edited:

Top