Perhaps posting a video would be helpful. The quality doesn't have to be anything special, just enough to demonstrate that you are in fact playing the game and we can hear what it sounds like.
Quote:Just imagine a crappy audio player trying to slow down a music track without changing its pitch. Let's just use the term "clicky" sound when the music slows down.
It's impossible to slow down an audio track without changing the pitch so I don't know what you're trying to say here.
Slower = lower pitch
Faster = higher pitch
By "clicky" do you mean skipping? Or crackling perhaps?
Quote:QUICKEDIT: I was using HLE on both. When I tried LLE recompiler, NOW everything's in sync because audio is slow then gamespeed is slow, regardless whether it's set to normal or realtime process. At least I know now why everyone would want LLE. Some effects "sound" right. With HLE, sound of waterfalls is a barely audible "hiss", if you can even call it a hiss.
That's the exact opposite of what should be happening.
(08-20-2012, 07:00 AM)NaturalViolence Wrote: [ -> ]Quote:Just imagine a crappy audio player trying to slow down a music track without changing its pitch. Let's just use the term "clicky" sound when the music slows down.
It's impossible to slow down an audio track without changing the pitch so I don't know what you're trying to say here.
Slower = lower pitch
Faster = higher pitch
Ah, I'm a musician so I KNOW it is actually possible. I used a winamp plugin before that does just that so I can dissect jazz improvs. The problem with that was if you slow it down too much to like 10% of its original playback speed...
Quote:By "clicky" do you mean skipping? Or crackling perhaps?
That's a good word. Yes, crackly!
Quote:QUICKEDIT: I was using HLE on both. When I tried LLE recompiler, NOW everything's in sync because audio is slow then gamespeed is slow, regardless whether it's set to normal or realtime process. At least I know now why everyone would want LLE. Some effects "sound" right. With HLE, sound of waterfalls is a barely audible "hiss", if you can even call it a hiss.
Natural Violence said:
That's the exact opposite of what should be happening.
I'm confused. HLE gives you fastest audio quality, right? So with HLE, it makes a bit of sense to have audio fast, but not necessarily the "video" part, hence my initial problem with 3.0 735 with HLE(default). When I watch the MH3 intro, no slowing down of audio even if FPS and gamespeed are sucky, so the actual video gets left behind the music.
(08-20-2012, 03:08 AM)Shonumi Wrote: [ -> ]Perhaps posting a video would be helpful. The quality doesn't have to be anything special, just enough to demonstrate that you are in fact playing the game and we can hear what it sounds like.
I've never done that before. I'm looking into doing that right now and will get back to you shortly.
Found camstudio.
QEDIT: That didn't work out. Video was too crappy. I also tried Jing, slightly better, but still unacceptable. Can anyone recommend a good desktop recorder? Something light on CPU load but good audio and vid quality.
Quote:Ah, I'm a musician so I KNOW it is actually possible. I used a winamp plugin before that does just that so I can dissect jazz improvs. The problem with that was if you slow it down too much to like 10% of its original playback speed...
What you're referring to is time-stretching which I don't really count since it completely changes the structure of the wave. HLE supports timestretching but it still shouldn't be causing this behavior.
Quote:That's a good word. Yes, crackly!
Crackling in this case is usually the result of microstuttering or microskipping.
Quote:I'm confused. HLE gives you fastest audio quality, right?
Fastest audio quality? What does that mean?
Quote:So with HLE, it makes a bit of sense to have audio fast, but not necessarily the "video" part, hence my initial problem with 3.0 735 with HLE(default). When I watch the MH3 intro, no slowing down of audio even if FPS and gamespeed are sucky, so the actual video gets left behind the music.
This is very odd because the emulated CPU supplies the DSP instructions to the audio frontend/backend which then emulates the GC/Wii DSP to process the instructions. If you're gamespeed has slowed down that means the emulated cpu isn't running at fullspeed and therefore shouldn't be able to supply the audio frontend with DSP instructions fast enough for it to emulate the audio at fullspeed. Perhaps MH3 does some tricky stuff with the DSP.
Quote:QEDIT: That didn't work out. Video was too crappy. I also tried Jing, slightly better, but still unacceptable. Can anyone recommend a good desktop recorder? Something light on CPU load but good audio and vid quality.
fraps
Edit: Took a look at some of the relevant code. I think I know what's going on. HLE is even more hackish than I thought.
(08-20-2012, 01:34 PM)NaturalViolence Wrote: [ -> ]Quote:So with HLE, it makes a bit of sense to have audio fast, but not necessarily the "video" part, hence my initial problem with 3.0 735 with HLE(default). When I watch the MH3 intro, no slowing down of audio even if FPS and gamespeed are sucky, so the actual video gets left behind the music.
This is very odd because the emulated CPU supplies the DSP instructions to the audio frontend/backend which then emulates the GC/Wii DSP to process the instructions. If you're gamespeed has slowed down that means the emulated cpu isn't running at fullspeed and therefore shouldn't be able to supply the audio frontend with DSP instructions fast enough for it to emulate the audio at fullspeed. Perhaps MH3 does some tricky stuff with the DSP.
This is not really how it works. The "DSP instructions" (UCode) is uploaded by the CPU to the DSP during the game init and then almost never changes (some games send a new UCode to the DSP at some points but it's a rare case). The UCode is not "streamed", once it's uploaded no new instructions are sent to the DSP. To control what the DSP does, the CPU sends a chain (linked list) what are called Parameter Blocks (PB) to the DSP through DMA (more precisely, it sends the address of the first PB, then the DSP downloads it from RAM using DMA). When it's done, the DSP then sends data to the Audio Interface (AI).
LLE is "synchronized" to the main CPU speed because it is emulated to run for a precise fraction of the time the main CPU has run (this fraction is basically DSP frequency divided by CPU frequency). Thus when the main CPU is not fast enough the sound will start to skip because the DSP runs at the same relative speed as the CPU.
HLE does not have this "issue" because it is not precise in term of run time: the DSP HLE code is called from the audio thread every N milliseconds completely asynchronously, using its own time base. This is obviously a big hack, but it works "well enough" and is a lot faster.
See this is the kind of stuff you guys (by which I mean the more active developers like you, neobrain, and skid for example) should be writing blogs or documentation about. The code doesn't really make much sense unless you already know stuff like this.
(08-20-2012, 02:23 PM)NaturalViolence Wrote: [ -> ]See this is the kind of stuff you guys (by which I mean the more active developers like you, neobrain, and skid for example) should be writing blogs or documentation about. The code doesn't really make much sense unless you already know stuff like this.
The DSPHLE code doesn't make much more sense when you know that unfortunately.
(08-20-2012, 02:11 PM)delroth Wrote: [ -> ][quote='NaturalViolence' pid='232638' dateline='1345433692']
LLE is "synchronized" to the main CPU speed because it is emulated to run for a precise fraction of the time the main CPU has run (this fraction is basically DSP frequency divided by CPU frequency). Thus when the main CPU is not fast enough the sound will start to skip because the DSP runs at the same relative speed as the CPU.
HLE does not have this "issue" because it is not precise in term of run time: the DSP HLE code is called from the audio thread every N milliseconds completely asynchronously, using its own time base. This is obviously a big hack, but it works "well enough" and is a lot faster.
So I guess what's happening with my experimenting does make sense. Thanks, delroth.
But does it make sense when I get the audio skipping similar to when I use LLE when I'm on HLE and switch to Realtime priority? They almost sound exactly the same, even the rate of audio slowdown. I can't properly time their actual slowdown rate(LLE vs HLE realtime priority) and compare though.
Here's another scenario I got into. While on HLE and in realtime priority, I got to a part of the game where gamespeed dropped considerably. I think there were about 10 or more jaggi and jaggia with a boss on the map. I'm used to the fps drop in these instances. But when I tried it on realtime priority, the audio became almost unrecognizable. Buzzes and what could sound like NANOstuttering like the jaggi were tearing up the audio thread itself to bits. FPS and gamespeed were still the usual.
Quote:I said:
I'm confused. HLE gives you fastest audio quality, right?
Naturalviolence wrote:
Fastest audio quality? What does that mean?
Sorry about that, I confused you. Fastest audio EMULATION was what I meant.
(08-20-2012, 03:13 PM)jeremymd Wrote: [ -> ]But does it make sense when I get the audio skipping similar to when I use LLE when I'm on HLE and switch to Realtime priority? They almost sound exactly the same, even the rate of audio slowdown. I can't properly time their actual slowdown rate(LLE vs HLE realtime priority) and compare though.
Here's another scenario I got into. While on HLE and in realtime priority, I got to a part of the game where gamespeed dropped considerably. I think there were about 10 or more jaggi and jaggia with a boss on the map. I'm used to the fps drop in these instances. But when I tried it on realtime priority, the audio became almost unrecognizable. Buzzes and what could sound like NANOstuttering like the jaggi were tearing up the audio thread itself to bits. FPS and gamespeed were still the usual.
I don't really understand what's happening here either... most likely the realtime priority CPU thread and GPU thread are starving the audio thread by using the 2 cores of your CPU completely. If my guess is right, that shouldn't happen on a quad core CPU because there are still two cores availables for running lighter tasks.
That makes enough sense. Although, that would mean Dolphin "prioritizes" GPU above audio threads. Is that how it was written?
Just to clarify, i'm not complaining at all.
I'm a happy camper. Just curious about a lot of stuff.