I wonder, is the code below correct from your point of view. The point is that this code hangs my computer by using 100% of CPU time. But when I use the default AudioManager settings (just create it and use) it seems everything goes OK. The strange thing is the code works fine sometimes in XP but never in Vista. Are anyone able to explain what’s wrong with the following code:
Maybe I’m wrong… Might be I should use another way to get the functionality I want. I want to initialize all available sound cards at start up time and use each one independently for separate audio tracks. I want one track to play to one sound card and another track to play to another sound card simultaneously. Any help?
Well, I can’t see any obvious problems with it, though maybe the OS is struggling because all these audio managers are trying to open multiple instances of the same devices? Where exactly is it hanging?
In a situation like this, it might be better to forget the device manager, and just use the devices directly. The manager provides an easy way of switching between devices, but if you’re choosing the device manually, it’ll only add a layer of beurocracy.
The “hang” happens after some number of calls to addInputSource to add sources to a mixer:
…the application still continues to run as if everything’s OK, but two threads consumes (two sound cards… see the interdependence) 100% of CPU time like a hungry beast devours a hot fresh flesh and an instance back, it tries to understand the moment could be avoided if the universe and all other stuff would be arranged the way people consider it perfect (sorry, I’m still drunk ;)).
Thank you, Julian. I’ll try to use device classes outside AudioDeviceManager. I’ll tell you what it’s run out to…
…about AudioDeviceManger and its bureaucracy you’ve mentioned, yes, you’re right. It feels like shooting sparrows from a bazooka
Well, Julian, I’ve discovered the root of all evil at last
The void DSoundAudioIODevice::resync() function is the culprit that causes my computer (only mine?) to consume 100% of its CPU time.
The way is that: Sometimes (especially on first run), Windows spends more time to open a DirectSound device with some untypical (unprepared) params (e.g. 48000 Hz instead of 44100 or something) or if the OS is busy enough to accomplish the task in time you expect it to do (your latencyMs variable). In this case, in your thread void DSoundAudioIODevice::run() function, your code mistakenly presumes a quasi desynchronization even if no actual sound manipulations were performed… So… take a deep breath, Julian :)… at that point you call resync() function that closes all opened output channels (opened milliseconds ago) and tries to open them again but it fails with the error “No driver” (according to your getDSErrorMessage function) on creating a primary buffer (!). As a side effect, this function somehow removes all channels from the outChans array and cotinues to run inside the main thread loop in vain consuming 100% of a CPU time.
I’ve found 3 ways to solve the problem, but I liked the last one. The idea was to simplify the resync function itself. So, the code is:
void resync()
{
if (! threadShouldExit())
{
sleep (5);
int i(0);
for (; i < outChans.size(); ++i)
outChans.getUnchecked(i)->synchronisePosition();
for (i = 0; i < inChans.size(); ++i)
inChans.getUnchecked(i)->synchronisePosition();
}
}
I removed dangerous and senseless code like SetThreadPriority (GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL); and SetPriorityClass (GetCurrentProcess(), REALTIME_PRIORITY_CLASS);. Why dangerous? Because, in Windows, the task scheduler becomes irresponsible causing the whole system to hang. Why senseless? Because, in Windows, it’s much more costly to switch thread priority for too short tasks than let the code flow without that switch. That’s the reality.
…now, everything works like a charm for… 2 testing hours.
I think, Julian, you should do something about it.
Right - thanks for the helpful info there. I added those priority changes fairly recently in an attempt to get a more reliable sync-up between input and output devices. It helped to do that to some extent, but if it’s causing serious problems like this then I’ll certainly get rid of it. Thanks!
I wouldlike to know, if its possible to set or initialise the devices samplerate (depending on that of my audiofile). (Please don´t ask for the reason ) I can´t / don´t want to use the 3rd param of AudioTransportSource.setSource.
Ok, and one additional thing. if I´d allow the user to change his device, I will first getAudioDeviceSetup(), set sampleRate in struct AudioDeviceSetup and finally setAudioDeviceSetup(). I will do this in one of the callbacks AudioDeviceAboutToStart() or prepareToPlay().
I appreciate your warnings, this helps me to learn better. But this way is mandotory by using the SDK, as I mentioned before. For its algorithm it is required.
So you’re going to change the sample rate in the callback which is called by the audio device when it has finished initialising its sample rate. Brilliant. Good luck with that.
For the last time, I don’t want to hear any more of this bollocks about audio devices.
Why aren’t you asking us how to make the output of your SDK match the rate that your AudioSource is being asked to produce? Or how to convert the fixed-size blocks from your SDK into the actual sizes that you need? Those are the real problems you’re trying to solve, and neither are very hard.
Audio devices are irrelevant to what happens inside an AudioSource. Forget them. Do not ask me about them ever again!
