It depends on what the other threads are doing. If this is a small test bed for just sounds so the main thread is not actually doing much, then the (low) overhead of the threads will appear as a significant fraction of the time.
I'm running a reasonably sized application/game so we can safely assume that the main thread IS doing quite a bit of work with game logic processing and rendering per frame.
Thread switching take 2 ms for all the sound threads.
We are only talking about 1 native mixer Thread here that is initialized by the Java sound API.
The other sound playback threads are all wait()ing on an object so they aren't doing anything and aren't in the equation actually.
Main thread yields once a frame.
In a testbed we are running 100 fps.
I would expect the sound threads to be activated every 10ms. They take 2ms, giving 20% on a profile.
So that's lousy isn't it?! That's 20% of your processor time doing nothing but context switching...
Remember - there are 2 seperate Threads of execution here, 1 native mixer thread and the main thread. So the percentage we're talking about (in order for it to make sense and that JProfiler is showing) is in terms of CPU slice time... Correct?
Then again, if the percentage in JProfiler is talking in terms of CPU slices, and if Thread.sleep() isn't supposed to be taking up processor cycles while sleeping, why is it showing that it's taking up a good 14% in the profiler?
Damn it's late and I'm getting a little confused...
In actuality, I'm more interested in the other 7% of CPU time that the native mixer thread is using up doing something naughty when it's not sleeping and no sound playback is happening. Looks like a waste of precious CPU cycles to me.
Some feedback and suggestions would be very appreciated. Thanks :-/