AudioDeviceSelectorComponent + open and close = huge latency


I’ve tried this with every soundcard on my system: If I open the dialog and close it without making any changes, the latency (microphone -> soundcard -> juce filter-> soundcard -> speakers) increases by a factor of 3 or 4x (haven’t measured it exactly). Yet if I tweak the buffer size while the dialog is open, the latency is fine after closing. This increased latency happens as soon as the dialog opens, but not necessarily every time.

Note how it’s a multiple of the current latency. I.e. if it’s really small to begin with, you don’t necessarily notice anything went wrong, whereas if it’s big to start with, it gets really big.

My PC is an old Pentium 4 with hyper threading. This doesn’t happen on another development system we have, which is an intel Quad-core.



Stephen Evans

… snip

AudioDeviceManager *deviceManager = m_pAudioMIDI ? m_pAudioMIDI->getAudioDeviceManager() : 0;

if( !deviceManager )

AudioDeviceSelectorComponent * audioSettingsComp = new AudioDeviceSelectorComponent( *deviceManager,
                                                0, 2, 0, 2,
                                                false, false, true, false );

audioSettingsComp->setSize (500, 450);
DialogWindow::showModalDialog (T("Audio Settings"), audioSettingsComp,
                               this, Colours::azure, true);

XmlElement* const audioState = deviceManager->createStateXml();
theApplicationSettings->setValue( cfgAudioDeviceState, audioState );

delete audioState;
delete audioSettingsComp;

… snip

Weird… Must be something blocking the audio thread for long enough to let one of the streams go out of sync (presumably this is DSound you’re using, not WASPI or ASIO?)

That sounds feasible. Yes, dsound. What can block the audio thread?

Or could it be that my audio filter is not behaving correctly?

At first I thought it was my other threads causing the problem, but I’ve locked them out and the problem remains.

What’s also strange is that any calls my other threads make back into juce are wrapped with MessageManagerLocks – is that enough? If I do let them run with the Selector Component running, the computer fully locks up (no mouse movement) when I change the buffer size. I don’t get it because those other threads only call into juce paint functions (on messagemanagerlocks), and sending MIDI, also on locks. Am I missing something? – but one thing at a time, if I lock these threads completely, the original problem remains.



I’d expect this to happen if you’re blocking the audio callback for a length of time. Maybe your audio code isn’t being very careful with its locking?

Ok, so nothing is locking in my processBlock function, and for that matter, before opening the dialog I call:

deviceManager->removeAudioCallback( &io_player );

Still the problem persists. Is there anywhere besides processBlock that I could be screwing things up?

Many thanks!

Can’t really think of anything else offhand, would have to do some more digging.

BTW I’m not trying to make an excuse here, but if you’re attempting to do any kind of synced recording with DSound, my advice is “forget it”. Or at least warn your users that the results are going to be terrible. And if they’re running on vista, I’d suggest taking DSound off the menu and forcing them to use WASAPI.