I noticed xaudio had disappeared, I have no idea why, I think it's something to do with sdks and directx issues going on the dolphin source code, as I was puzzled it disappeared.
An observation (not sure it's a "problem") is that once you're bouncing on the limiter you've got ~8k samples to play (250ms) so I'm actually surprised that it's been noticed that some sound is a little out. I'm actually tempted to shrink the audio buffer down to 2k samples (~62ms) if the audio frame limiter is enabled (as that's a couple of frames at 30fps)
I guess the problem is that yes, we want the data to buffer but not quite as much as it's giving right now, as the buffer should be there to ride out periods where the system is busy doing a frame or something. However, trying to find all the places that are running a smidge too often for generating the audio needs someone far more familiar with all those places.
I did also wonder if that perhaps the issue is how part of the audio is emulated, as I believe that there is some audio hardware around streaming, where once it's output a number of samples it interrupts the CPU to say I've done this much copying (but it's not clear if it's just disc audio, or is also meant to cover game sound) However, the DMA from main memory to the audio runs on a timer, rather than triggered by need for more data...
I'll have to revisit things this evening, as I maybe mixing up what I found where and with which settings
However hopefully you can at least see the full effect of the resampling being done with that build. From there it might be possible to focus on producing a resampler that does a better job (the trick will be handling the streaming of the data through it)
Why are you even using the audio frame limiter? It's a terrible idea and it does nothing useful.
It does seem like audio frame sync is there to stop the emulator throwing away a few ms of samples because the mixer buffer is full, and once the mixer is full it'll probably stay close to full as it clearly isn't draining quick enough.
The dropping of sound samples causes audible pops (especially on lightly loaded things, eg the system menu)
I suspect that the mixer buffer being full is an indication that samples are coming out of the emulator quicker than they should be, and that somewhere there's a missing feedback loop.
At a guess it's something to do with the AudioInterface updating consumed samples on a timer, and so when it interrupts the CPU to say I've consumed the samples it's a fraction early. It might work better if was actually tied into the Mixer code which actually consumes the samples... However, that might upset the code that "DMAs" the samples to the mixer buffer on a 4khz timer (unless that's also part of what's wrong?)
However, this is all speculation on my part based on what I see happening, and a lack of detailed knowledge of all these areas. Certainly any insight as to am I completely mad to be looking at those areas would be appreciated.
The No Audio backend and the OpenAL backend update the samples on a timer. The other backends are updating the samples based on the mixer (which is on a thread).
It has to be based on the globaltimer because samples are played at a known rate on the real hardware.
Having the samples consumed by the mixer would mean that the audio might play faster or slower than the CPU and the rest of the emulation expects i.e. asynchronous audio. This can lead to the game going into an error state.
Let us know the part of the code which makes the samples get consumed quicker/slower than they should. I suspect it is the mixer's watermark code.
I suspect the issue is that the audio system normally free wheels a little on the real hardware, it runs really close to 48k, but might not be spot on. Hence i think the audio interface includes the sample counter, and an interrupt when it passes a particular point.
While it requests a 48k output reality is that the timing is probably not precisely 48k, it's just really close. (as getting bang on accurate 48k is unlikely to be cheap)
So the backlog probably varies, IE you might get 47990hz, and it backs up 10 samples a second. Some may have one a little quicker, eg 48010 and end up not having enough samples.
If the real hardware works as I suspect, it uses the AI interrupt to trigger a request to the DSP to make new audio, which then ends up in the AI fifo, and that feeds into samples being consumed, which then triggers the next AI interrupt to get more data.
I'll have to do more digging, but my suspicion is the idea of the audio should be that it runs at the speed of the output clock.
I want to do some digging to work out what the AI interrupt actually does in game code, IE is it a trigger to push the next command at the dsp? And what the AI interrupt counter tends to get updated to, is it one frame of samples...
Of course I admit this is perhaps a naive view of the emulation.
Note I'm not saying it should be async to the cpu (as the HLE-zelda shows that async is different mess), just that the engine shouldn't bang out audio even if there's nothing to consume it. It might also be the cause of the audio lag that people have reported (in another thread) as the current mixer buffer is 8k samples (250ms @32khz)
Of course this could be a subtle bug hiding somewhere in the output path, but the buffer does fill up...
Tueidj says in
post 7 that it's really 48043hz.
There's a bit of code in Dolphin that (has been commented out and) is meant to play silence when samples have not been set to the DSP. The code didn't seem to make much of a difference in my testing. You might want to have a look at that.
Certainly if the frequency was 48043 it'd answer why there are more samples then there should be, and they back up. However it'd backup 43 samples a second, 8k samples would need 180 seconds or so.
It says it's documented as 48043. I don't suppose you know if that's Nintendo docs, or someone measured the clock and got 48043 (just a thought that for a console you get a batch of clocks with some variance, but just code for that variance.)
Looking at the code there a few interesting items, eg there's a timing loop for how quickly the AI drains a sample, given it's using the OSGetTime that's bound to be somewhat bogus.
Perhaps the solution is to monitor the backlog and tweak the resampling slightly to try and track the actual consumption rate, as most people probably can't tell if 1% more or less samples come out a second. probably band it to have 3 resamplers. One at normal speed, one at slightly faster, and one slightly slower.
As the buffer passes certain thresholds switch resampling to use a little more or less.
I think I've worked out what happened to Xaudio2. I think it's a build issue, and related to if the directX sdk is available. The move to vs2013 means the wdk 8.1 is used, which changes xaudio around, see this MS article,
http://msdn.microsoft.com/en-US/windows/desktop/ee663275.aspx
I suspect it's something to do with point 8, which talks about using the old sdk header and .lib file for xaudio on win7.
I think 48043Hz is only mentioned (in official GC SDK documentation) with regards to disc streaming (DTK) audio, I'll double check if it's mentioned anywhere in the wii SDK (streaming audio was dropped for wii).
(11-15-2013, 03:37 PM)delroth Wrote: [ -> ]Why are you even using the audio frame limiter? It's a terrible idea and it does nothing useful.
Initially I didn't think it made any difference to the dumped audio what frame limiting setting you used, but it turns out setting it to limit by audio records the music correctly no matter what speed Dolphin is running at (as long as you don't hit Tab) while the other settings will make a recording which includes the glitches from frame rate variations. In the music I've been getting glitches in, I can be sure it's not an issue with my PC being unable to run the game at full speed (which it can anyway) because they still show up in the recording when frame-limited by audio when no other glitches do.
NTSC5994 branch has some code that may affect audio mixer... Maybe it's related?