Beta Mupen64Plus


DaveC said:
IzzehO said:
Pushing the overclock like we are on the N900. Got a lot of people running at 1.1GHz, I'm at 950MHz. As for PSX... thats awesome.. can't wait to steal it :p The current dev for N900 has gotten married and moved to Spain.. so we've run out of developers :p

Anyhow, on topic... has much progressed been made with getting sound to work reasonable? Is this planned? I ask only if you guys actually have decent sound (we don't).
No, the sound on the Pandora is very stuttery. That is something that I hope can be improved with the Pandora hardware limits. The stuttering really detracts from games and playing with no sound is even worse.

From what I've read here the frameskip code is improved in the next version, this might tie in with better sound. (I wonder if 1 is still 0 and 2=1?)

I think I'd rather the sound played slightly slower (ie it slowed down with the game) than it stuttering.

Is there a new PND of this, or are we still waiting? I've not kept up enough in the last few days due to millions of other Pandora tasks!
 
Last edited by a moderator:
craigix said:
(I wonder if 1 is still 0 and 2=1?)

1 = render ever 1st frame. (every frame)
2 = render every second frame.
3 = render every third frame.

I don't understand why you think this is messed up.

craigix said:
Is there a new PND of this, or are we still waiting? I've not kept up enough in the last few days due to millions of other Pandora tasks!

The most recent PND is the one that added configurable controls and Ari64's dynarec fixes. I believe that the frameskip changes were made after that.

-God Ginrai
 
Last edited by a moderator:
craigix said:
I think I'd rather the sound played slightly slower (ie it slowed down with the game) than it stuttering.

It probably isn't possible for N64 emulation, at least not with how it's currently being done, except to continually resample the output at a varying rate. However, that would result in completely pitch shifted output, not "slower" audio like you're imagining, and the resampling would probably sound uneven like playing a record that's gone all wobbly.

WARNING: confusing explanation ahead

When you see the slow down happening in other emulators it's because they're emulating the audio in real time and everything else in emulated time. This requires completely decoupling the emulation of the audio from the emulation of everything else. In other words, the two things are now asynchronous instead of synchronous, and are connected by a FIFO.

So let's say there's some period of time, the "synchronization period." It could be one frame (50Hz, 60Hz, whatever), or it could be when the audio's buffer runs out.

During this period the emulator will emulate X machine cycles where X is a completely fixed number. Like, if the period is 10ms and the machine is 100MHz it might be emulating 1 million cycles. Whatever the number is, however accurate or inaccurate, it'll be constant regardless of how fast or slow the emulation is; if it took you 5ms to emulate that then the emulator will then throttle and wait for 10ms to pass so it looks like it's running at the right speed. But if it took 20ms then the emulator will just feel half as fast as it should be and there's no way around this.

The audio, on the other hand, will emulate a number of of output samples based on how much real time has passed since the last time audio was emulated. This is usually based on the audio output rate. So if you're outputting at 44.1KHz you're going to be generating 441 samples every time 10ms has passed on the machine you're emulating. This will happen regardless of whether or not you were able to emulate all your machine cycles during this time.

(the actual synchronization of the machine and audio emulation might not line up, ie it might synchronize machine emulation every frame and audio emulation every buffer period, but the aggregate synchronization over longer periods of time will match what I'm saying)

So you end up having too few emulated cycles for the audio cycles.

How this affects you depends on what the audio chip's role in generating music is, vs what the CPU's role is.

For platforms like NES and SNES the CPU's role is usually to tell the audio chip to start playing an instrument at some pitch, then stop playing it. The audio chip then takes care of playing it with the right waveform, pitch, and in this case even effects like looping, envelope, sweep, reverb, etc.

What this means is that if you aren't emulating the CPU fast enough you'll still end up with notes that play at the correct pitch and have the correct timbre, but they'll start and stop at slowed down intervals. So the overall tempo will sound slower.

On platforms like N64 and GBA the CPU's role is much more low level; it generates audio sample by sample by writing to a buffer. In N64 this might be abstracted by HLE, but from what I understand not in a way that really allows proper decoupling, since the games still need to be able to stream audio. Zilmar has said that a synchronous approach is necessary, and given that even emulators like N64 had synchronous audio I tend to believe it.

Usually the asynchronous audio emulators just capture the audio state at the beginning of the emulation interval, so it's not even really a FIFO between machine emulation and audio emulation. For platforms like NES/SNES this usually (not always) sounds OK, because the fidelity of when instruments key on and off isn't that important. But if you're streaming audio it's very important, and this will completely wreck the output. You can actually buffer every audio state change instead, then linearly spread them throughout the audio emulation period. You can even cycle timestamp the audio state changes then scale their emulation proportionately to when they should happen during the interval.

The end result with that is that you'll have pitch shifted audio, although it'll sound really bad if you don't filter it. The thing is, buffering every sample write like this (especially timestamping them) usually has much more overhead than emulating synchronously directly out of audio buffers. You also have to pay additional overhead for interpolating the events and filtering the result. Furthermore, if the audio generation occurs by writing to plain old system memory (that is then, say, DMA'd out to audio buffers internally) you won't be able to capture audio events very easily because you won't know when the game is writing to an audio buffer, at least not without adding a lot of additional overhead to the emulation.

You can also resample the audio AFTER it's emulated to match the amount of time that it's passed, basically stretching out the samples you emulate. That way you end up with it filling the entire time instead of filling a bit then stopping, hence the stuttering.

The problem with either of these interpolation approaches is that if things aren't fullspeed you probably won't have a constant framerate (unless you force one, but since that'll tend to make things much slower you don't really want this), so you won't have a constant resample rate, hence wobbly record effect.

Since the goal of an emulator is usually fullspeed emulation considerations that improve quality of sub-realtime emulation aren't usually considered, especially if they end up making the emulation even slower. Just not something people often want to invest time in, but for emulators where not tolerating slow speeds is practically a mission statement you sometimes see it (cough, desmume has this option)
 
Last edited by a moderator:
God Ginrai said:
craigix said:
(I wonder if 1 is still 0 and 2=1?)

1 = render ever 1st frame. (every frame)
2 = render every second frame.
3 = render every third frame.

I don't understand why you think this is messed up.

craigix said:
Is there a new PND of this, or are we still waiting? I've not kept up enough in the last few days due to millions of other Pandora tasks!

The most recent PND is the one that added configurable controls and Ari64's dynarec fixes. I believe that the frameskip changes were made after that.

-God Ginrai
It is confusing because to me FS0 means exactly that, it skips 0 frames. FS 1 means that it skips 1frame meaning it renders every other frame (skip 1, render next, skip 1, render next, FS 2 = skip 2, render next, skip 2, render next..). After all it is called frame SKIP, not frame render which is what you describe.
 
Last edited by a moderator:
DaveC said:
God Ginrai said:
craigix said:
(I wonder if 1 is still 0 and 2=1?)

1 = render ever 1st frame. (every frame)
2 = render every second frame.
3 = render every third frame.

I don't understand why you think this is messed up.

craigix said:
Is there a new PND of this, or are we still waiting? I've not kept up enough in the last few days due to millions of other Pandora tasks!

The most recent PND is the one that added configurable controls and Ari64's dynarec fixes. I believe that the frameskip changes were made after that.

-God Ginrai
It is confusing because to me FS0 means exactly that, it skips 0 frames. FS 1 means that it skips 1frame meaning it renders every other frame (skip 1, render next, skip 1, render next, FS 2 = skip 2, render next, skip 2, render next..). After all it is called frame SKIP, not frame render which is what you describe.

I agree, as the first Emulator I used (VisualboyAdvance) uses this config, although I also see the logic behing the other system. It would be nice if you could somehow tell just from the text in the menu, but if the worst comes to worst just look at the lowest value, and that will be for no frameskip - and just work from there.
 
Last edited by a moderator:
Sure there is a logic behind it. But the systems should use the correct config value to not be confused.

It's normally as DaveC explained:

FS (FrameSKIP) means how many frames will be SKIPPED. So 1 = one frame will be drawn, one skipped, one drawn, one skipped.
FrameRENDER means, what frames will be rendered. As explained, 1 = EVERY frame. 2 = every SECOND frame, etc.

So basically, everything is fine, we just need to take care to not confuse those two :)
 
didn't Strnmmn make his Audio asynchronous so he could use second processor on the psp to work on the sound and the main cpu to emulate everything else? wouldn't it speed things up if we did it this way?
 
milkshake said:
didn't Strnmmn make his Audio asynchronous so he could use second processor on the psp to work on the sound and the main cpu to emulate everything else? wouldn't it speed things up if we did it this way?

This isn't the same thing as what I'm talking about.

You're probably talking about using the DSP on the Pandora and there's no point discussing that further until some method of accessing it becomes standard.
 
Last edited by a moderator:
Exophase said:
craigix said:
I think I'd rather the sound played slightly slower (ie it slowed down with the game) than it stuttering.

It probably isn't possible for N64 emulation, at least not with how it's currently being done, except to continually resample the output at a varying rate. However, that would result in completely pitch shifted output, not "slower" audio like you're imagining, and the resampling would probably sound uneven like playing a record that's gone all wobbly.
Yeah psx4pandora does that and I can't stand it! That varying sound pitch is as annoying as ghosting on display to me.
 
Last edited by a moderator:
notaz said:
Exophase said:
craigix said:
I think I'd rather the sound played slightly slower (ie it slowed down with the game) than it stuttering.

It probably isn't possible for N64 emulation, at least not with how it's currently being done, except to continually resample the output at a varying rate. However, that would result in completely pitch shifted output, not "slower" audio like you're imagining, and the resampling would probably sound uneven like playing a record that's gone all wobbly.
Yeah psx4pandora does that and I can't stand it! That varying sound pitch is as annoying as ghosting on display to me.
The stuttering is pretty bad too. I think that is about the worst aside from no sound at all.
 
Last edited by a moderator:
Thought I'd pop in again. Wonderful explanation of sound Exophase, I found I knew a lot of that... but to have it spoken as such helped connect a lot of the dots. Is it a reasonable summation to say that audio is therefore very much dependant on how well graphics (video, gameplay.. whatever the word may be) are handled?

Also was curious as to how you guys are actually working on the GLES plugin at the moment, is a simple matter of selecting a game and working through obvious issues? or is there still different level compatibility fixing being done? Do you see something like Super Smash Bros, Tony Hawks or Mario Tennis working in the near future? (All three seemingly having very independant issues: Collisions crash, textures weird and massive artifacts respectively)

...hell do the desktop versions even have Mario Tennis 100% yet?
 
notaz said:
Yeah psx4pandora does that and I can't stand it! That varying sound pitch is as annoying as ghosting on display to me.
Only with XA audio, though. :p With non-XA stuff (for example, Mega Man 8's background music), it will speed up and slow down with the game, but remain at the correct pitch.
 
Last edited by a moderator:
Would it be possible to do pitch correcting audio speed changes?

They're at least possible in audio editing tools, but I don't know how practical they'd be to do dynamically.
 
Aninhumer said:
Would it be possible to do pitch correcting audio speed changes?

They're at least possible in audio editing tools, but I don't know how practical they'd be to do dynamically.

Exophase said:
Since the goal of an emulator is usually fullspeed emulation considerations that improve quality of sub-realtime emulation aren't usually considered, especially if they end up making the emulation even slower. Just not something people often want to invest time in, but for emulators where not tolerating slow speeds is practically a mission statement you sometimes see it (cough, desmume has this option)

-God Ginrai
 
Last edited by a moderator:
I've noticed SDL audio plugin has a bit of overhead, so I wrote my own that I think is more tuned for pandora:

packaged with the emu
source

select it in config menu. Nothing too exciting, but it skips a bit less for me. Be sure to have HotFix3 applied or it'll glitch like hell.
 
notaz said:
I've noticed SDL audio plugin has a bit of overhead, so I wrote my own that I think is more tuned for pandora:

packaged with the emu
source

select it in config menu. Nothing too exciting, but it skips a bit less for me. Be sure to have HotFix3 applied or it'll glitch like hell.

Cool news. I'll try it out in just a second. Thanks.

EDIT: I seemed to get this speaker popping sound with your plugin. Also, the other plugin's sound sounded more "full" than what yours is producing. Also, for some reason, your packaged version of the emulator seemed laggy with the right settings. :\

-God Ginrai
 
Last edited by a moderator:
God Ginrai said:
EDIT: I seemed to get this speaker popping sound with your plugin. Also, the other plugin's sound sounded more "full" than what yours is producing.
Yeah I guess Dac sounds better at 44kHz even if source sound is resampled from much lower rate.

God Ginrai said:
Also, for some reason, your packaged version of the emulator seemed laggy with the right settings. :\
Which build is considered the latest? I used the one from appstore.
 
Last edited by a moderator:
notaz said:
I've noticed SDL audio plugin has a bit of overhead, so I wrote my own that I think is more tuned for pandora:

packaged with the emu
source

select it in config menu. Nothing too exciting, but it skips a bit less for me. Be sure to have HotFix3 applied or it'll glitch like hell.
This one definitely skips a lot less for me. Games tried: Mario 64 and Bomberman 64 - The Second Attack! My Pandora was one of the ones that had cracky audio before hotfix3 as well~ if that helps.
 
Last edited by a moderator:
First time i try this emulator on my Pandora and when launch the analog pad are disabled, need to use touch screen to select rom. I have no sound
 
Yod4z said:
First time i try this emulator on my Pandora and when launch the analog pad are disabled, need to use touch screen to select rom. I have no sound
Yes it uses the 'default' file selector currently which you need to use the touchscreen to select a rom, sound wise you need to enable the sound plugin in the options.
 
Last edited by a moderator:
Back
Top