Site navigation

Can't start DSound and ASIO devices

General JUCE discussion
#1

I face a strange problem with my audio devices in Juce. Juce and other apps detect, that I have two DSound devices (named “Primary sound driver” and “Realtek HD Audio output” in the list) and a single ASIO device. But while other audio apps succesfully play through all the three devices, Juce can play only throuhg the first one - “Primary sound driver” and completely mutes any audio when I choose the second DSound device or the ASIO device.

I base on standard Juce components for audio management - AudioDeviceManager and AudioIODeviceCallback. I also checked Juce Demo app and Plugin Host app and found exactly the same behavior there. During debugging I see, that when I choose nonplaying device, the currentAudioDevice has numOutputBuffers set to zero and numUsed in outChans array is also set to zero, although I always initialize the manager with two output channels. After the bad device is set, the callback is called with totalNumOutputChannels == 0 and NULL in outputChannelData array. There’re some manipulations with bits and arrays happen on device creation and opening, which I can’t understand and therefore don’t see where to dig now. Probably something simple is going on here, right?

#2

It’s not surprising that those channel numbers would be set to 0 if the device failed to open. It really just sounds to me like the driver’s not opening for some reason - maybe you could step through the audio device code and see how far it gets in trying to open it?

#3

I’d be happy to do that, if only I’d use normal Juce sources, but I use amalgamated sources, where VC Express debugger doesn’t work with lines below 65535 (damn it). Are you sure that the driver is not opening? It doesn’t return any error string on open and then calls ->start method due to that.

I also checked in Tracktion and found that the second DSound device was initially set to “Disabled” there, but after I enabled it, it worked fine. Quite strange that juce demo and pluginhost apps are unable to work with it, though.

Looks like the only way is to debug all this stuff with nonamalgamated Juce sources or could here be any other trick to figure out the problem?

#4

I’m now debugging the usual Juce sources and looks like I found which commands sequence leads to audio muting, but I still completely misunderstand the root cause of the problem.

As I said, the faulty device start succesfully and without any errors, but with output channels set to zero. This is quite confusing, but the reason they are set to zero is nonzero index of the device in devices list. First look at what the DSoundAudioIODevice::open function does:

...
            if (outputChannels[0])
                outs.setBit (2 * deviceIndex);

            if (outputChannels[1])
                outs.setBit (2 * deviceIndex + 1);
...

It sets two channels bits shifted according to the deviceIndex. And then DSoundAudioIODevice::openDevice() function does the following:

...
    enabledOutputs = outputChannels;
    enabledOutputs.setRange (outChannels.size(), enabledOutputs.getHighestBit() + 1 - outChannels.size(), false);
...

This code sequence erases the two previously set bits if they start not from zero (deviceIndex > 0) and leave them as is if they start from zero. That’s why the output channels are not initialized then and no devices are working except the very first one. WTF? Jules, can you please comment this?

#5

Erm… is this a very old version of juce that you’re using? None of the code you posted seems to exist in my version.

#6

I was using 1.46 version. Just tried 1.50 and yeah, looks like those manipulations with bits shifting in DSoundAudioIODevice::open are removed and everything is fine now. I’ve fixed my 1.46 source in the same way - just by removing those manipulations. :slight_smile:

#7