These two are using a lot of cpu time, is this normal and unavoidable?
My buffer size is 1024.
CPU Time Module Function (Full)
juce::DSoundAudioIODevice::run 35.1% Radon.exe juce::DSoundAudioIODevice::run(void)
juce::DSoundInternalOutChannel::service 13.8% Radon.exe juce::DSoundInternalOutChannel::service(void)
The next most active DSP-related stuff is only 13%.
For reference, the DSound routines total 14% of my total quad-core CPU util. Something’s awry surely?
Sounds fine to me. Not sure what you mean about your DSP code - if you’re doing a lot of work on the audio thread, then surely it’s no surprise that that thread is using a lot of CPU?
The dsp stuff takes about a third as much time as that spent spinning in those sleep calls, and clearly it can’t be doing DSP number crunching while the same thread is sleeping.
My concern is that all this sleeping is contributing far too much to the cpu usage of my synthesizer voice. My knowledge of c++ threads is slim, but why are the sleep calls necessary? Can’t the OS schedule things well enough?
eh? sleep doesn’t contribute to the cpu load. That’s the whole point. While it’s sleeping, the scheduler shouldn’t be counting that time as cpu time. Your profiler will of course tell you that it’s ‘busy’ inside the sleep call, but in reality it’s not tying up any cpu resources, that’s why it’s there…
Well, it’s Win32 horror going on here.
Sleep(1) in windows is not doing “Sleep 1 ms” like you expect. It calls tell the windows’s kernel to sleep your current thread, and resume it, at least 1ms from now.
And since, there is a usually a lot of thread waiting to run at any given time, you’ll likely wait much more than the specified 1ms duration.
So, as Jules said, this is perfectly correct, since you are giving back your remaining thread timeslice to the system, so the CPU can be used for another, more important, thread.
Jules, you could consider using SwitchToThread whenever possible, for the reason explained below, instead of the old fashionned Sleep() call (or even better, use a WaitForSingleObject on a the soundcard’s async IO, so you actually never “sleep”)
The issue is that since Vista is out, the kernel is doing a lot of statistics on the thread API usage (yes that sound crazy), and when you’re doing a lot of Sleep() calls, you’ll rank lower in the scheduler queue.
Over the running time, our realtime streaming client started to behave way way slower on Vista, and this was due to our sched_yield()/Sleep() calls. When we rewrote the application to use events whenever possible, the performance resumed.
Thanks for the input. I’ve actually read that article at some point a couple of years ago.
It’s clear that sleeping isn’t the same as waiting for a lock (I suppose I should have chosen another word than ‘spinning’), but it will act exactly like one if processing is trying to happen on the same thread. I want the DSP routines (i.e. the render callbacks) to be able to use 99.5% of the cpu if necessary… but how can that happen if the DSound routines on that thread are relinquishing it’s cpu time?
Beside which, a significant amount of the time in those two DSound routines is NOT idle (about 30%); I really don’t know where those cycles are going …yet. (I’ve been profiling other parts of my app but I’ll return to this soon enough)
I’m struggling to see your point… Doing some sleeping in that thread is absolutely essential to prevent the system from locking up - it’s a high (or even realtime?) priority thread, so it can’t sit there spinning. But I don’t understand why you think the sleep calls are somehow cheating you out of getting any cpu action? DSound is crap for low-latency audio anyway, so your buffer size will be have to be at least 10ms - if it sleeps for 1ms of that time, your callback can still hammer the cpu for 90% of its capacity, which is all you could reasonably expect to get.