XAudio2: GetPerformanceData() time in milliseconds?

Le Bump.

Well I'm going to take a shot in the dark at this. I know you've already taken a look at MSDN probably, but just to keep myself organized I'm going to reference everything I went over.

First I went to check out the definitions of AudioCyclesSinceLastQuery and TotalCyclesSinceLastQuery. One thing I found sort of ambiguous is the note on total cycles, "This only counts cycles on the CPU that XAudio2 is running on." I'm not totally familiar with XAudio2, but I'm pretty sure it employs the use of threading. Possibly the audio processing thread is on another core, thus the cycles being returned are the amount of time spent in asynchrouns function calls to XAudio2. I doubt this, but it is just something to think about.

Next I calculated theorectically how many bytes of your one voice should be consumed in 66.66 milliseconds:
32,000 Hz * 2 bytes * 4 (channels) = 256000 bytes/s * 0.06666 s = 17064.96 bytes processed in 66.66 ms.
Given that value, the audio cycles count doesn't seem too far off assuming that I'm pretty sure it will vary between frames depending on whether XAudio2 is ahead or behind in processing. (In your example above it would appear as though XAudio2 was ahead in processing, thus it took less time that frame to process the amount it needed to.)

As a last note, is the value returned by the registry the same as the value returned by QueryPerformanceFrequency?

Quote:

Original post by Halifax2 Well I'm going to take a shot in the dark at this. I know you've already taken a look at MSDN probably, but just to keep myself organized I'm going to reference everything I went over. First I went to check out the definitions of AudioCyclesSinceLastQuery and TotalCyclesSinceLastQuery. One thing I found sort of ambiguous is the note on total cycles, "This only counts cycles on the CPU that XAudio2 is running on." I'm not totally familiar with XAudio2, but I'm pretty sure it employs the use of threading. Possibly the audio processing thread is on another core, thus the cycles being returned are the amount of time spent in asynchrouns function calls to XAudio2. I doubt this, but it is just something to think about. Next I calculated theorectically how many bytes of your one voice should be consumed in 66.66 milliseconds: 32,000 Hz * 2 bytes * 4 (channels) = 256000 bytes/s * 0.06666 s = 17064.96 bytes processed in 66.66 ms. Given that value, the audio cycles count doesn't seem too far off assuming that I'm pretty sure it will vary between frames depending on whether XAudio2 is ahead or behind in processing. (In your example above it would appear as though XAudio2 was ahead in processing, thus it took less time that frame to process the amount it needed to.) As a last note, is the value returned by the registry the same as the value returned by QueryPerformanceFrequency?

Hi, thanks for the reply.

QueryPerformanceFrequency gives the frequency of the high performance timer, which isn't nessecarily the CPU speed (It gives 40-odd MHz for QPF()).

The cycle count only being for the CPU core that XAudio runs on (It has an audio thread which runs, as you guessed) shouldn't make any difference really, and if AudioCyclesSinceLastQuery is 10639, then processing 17064 bytes in that many clock cycles still seems pretty low, given that XAudio is surely doing more than just copying data from one buffer to another? Maybe not I guess, but the TotalCyclesSinceLastQuery still seems particularly low...

Hi Steve,

Only recently played with XAudio2 and I wanted to give those performance stats a shot at one point.

I set up a simple test (SlimDX) playing one voice, measuring time at a fixed 66 ms tick (artificially using sleep) with QPC, which I know works here. Turns out your approach works correctly on my system, assuming you are using e.g. HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\~MHz.

Comparing TotalCyclesSinceLastQuery and the measured delta time (ratio) gives me about a 2000 MHz "sample frequency", pretty stable each tick, a minor bias of about 1MHz. This value is closely returned by both said registry value (1999 MHz) and QPF (1,999,990,000 Hz).

Sad but true, I can't find anything conclusive in the docs yet what these "CPU" cycles actually mean or how the XAudio2 timing works internally either. Neither can I find a handy GetEngineCycleFrequency() or something. Source code would come in handy, but I can't help in this regard ... :/

Your numbers evaluate to (1685086 samples / 66.6 ms = ) 25 MHz approximately. Does that ring any bells ? Can you find that value somewhere, e.g. system or driver information ?

My emphasis here is on "stable". If it behaves the same way (across systems) then you can at least find out by measuring a couple of frames. Likely not the most accurate solution but at least a start. Then again: From the docs it's not clear to me if this approach is sane.

By the way: Calcing back AudioCyclesSinceLastQuery gives me about 1% or 0.5 ms which sounds not that far off for "the time spent" in an audio layer.

Hope that helps

[Edited by - unbird on December 10, 2010 10:59:32 AM]

For future reference, the values returned apparently aren't CPU cycles at all, they're values from QueryPerformanceCounter() according to the Games For Windows team.

Hooray for documentation :P

Quote:

Original post by Evil Steve For future reference, the values returned apparently aren't CPU cycles at all, they're values from QueryPerformanceCounter() according to the Games For Windows team. Hooray for documentation :P

Honestly I thought that might be the case. In the documentation for QPC they reference the return value as CPU cycles. But you're right, I dislike MSDN's ambiguity sometimes.