Site navigation

How to get the default output device

General JUCE discussion
#1

hi,

I’m getting trouble in playing an audio file, because my device Manager don’t get the output device. I’m doing it like this:

but I always get the mic input (I know this by calling “getCurrentAudioDeviceName()”)… I specify 0 input channel and 2 output channel, so how is it possible? Thanx for your help.

Leskimo[/code]

#2

Well what happens in the jucedemo audio page? Does that get the right device?

#3

nope, it gets the mic input. I just want to know if there is a way to get automatically the default output, without asking the user to choose a device from a device Selector or something. Thanx

Leskimo

#4

By the way, I’m working on an iMac G5 Intel Core Duo, I don’t know, maybe that’s the problem…

Leskimo

#5

Hmm. It just uses the first audio device in the list as the default - normally on macs that’s the duplex built-in audio device. Sounds like on your machine the input and output are split into two separate devices?

The nasty bit here is that you don’t know whether a device has got any output channels until you’ve opened it, so there’s not even a neat bit of logic that could be added to the audiodevicemanager… What I’ll look into doing is adding something to get the default device from CoreAudio itself…

#6

Same computer system, same problem here.

#7

Ok, try this (totally untested, not even compiled) idea…

Add this method to juce_mac_CoreAudio.cpp

[code]const String AudioIODevice::getDefaultDevice (const bool forOutput)
{
StringArray names;
Array ids;
getAudioDeviceList (names, ids);

String result (names[0]);

AudioDeviceID deviceID;
UInt32 size = sizeof (deviceID);

if (AudioHardwareGetProperty (forOutput ? kAudioHardwarePropertyDefaultOutputDevice
                                        : kAudioHardwarePropertyDefaultInputDevice, 
                              &size, &deviceID) == noErr)
{
    for (int i = ids.size(); --i >= 0;)
        if (ids[i] == deviceID)
            result = names[i];
}

return result;

}

[/code]

In the juce_AudioIODevice.h file, add the declaration:

    static const String getDefaultDevice (const bool forOutput);

And tweak this method in juce_AudioDeviceManager.h:

[code]
const String AudioDeviceManager::initialise (const int numInputChannelsNeeded,
const int numOutputChannelsNeeded,
const XmlElement* const e)
{
numInputChansNeeded = numInputChannelsNeeded;
numOutputChansNeeded = numOutputChannelsNeeded;

if (e != 0 && e->hasTagName (T("DEVICESETUP")))
{
    BitArray ins, outs;
    ins.parseString (e->getStringAttribute (T("audioDeviceInChans"), T("11")), 2);
    outs.parseString (e->getStringAttribute (T("audioDeviceOutChans"), T("11")), 2);

    String error (setAudioDevice (e->getStringAttribute (T("audioDeviceName")),
                                  e->getIntAttribute (T("audioDeviceBufferSize")),
                                  e->getDoubleAttribute (T("audioDeviceRate"))));

    XmlElement* c = e->getFirstChildElement();

    while (c != 0)
    {
        if (c->hasTagName (T("MIDIINPUT")))
            setMidiInputEnabled (c->getStringAttribute (T("name")), true);

        c = c->getNextElement();
    }

    return error;
}
else
{
    const String defaultDevice (AudioIODevice::getDefaultDevice (numOutputChannelsNeeded > 0));

    return setAudioDevice (defaultDevice, 0, 0);
}

}[/code]

#8

ok, you’re really good. It works great! Thank you very much

Leskimo

#9

Hi,

I am using the JUCE AudioDemo and don´t want the user to allow setting the BufferSize. Instead the user should only be allowed to select anything else (like Audio-Device) when the Dialog for AudioDeviceSelectorComponent appears.

How to do this?

If I should do this with setAudioDevice():
How to let the user choose Audiodevices? (Restricting on Buffersize is okey.)

#10

There’s already an option in there to tell it to use a simplified view of the settings - i.e. just the list of devices.

#11

Do you mean in AudioDeviceSelectorComponent ? Unfortunately there is nothing in the JUCE Doc mentioned about a simplified view.

Did I miss anything?

#12

Search for hideAdvancedOptionsWithButton

#13

I don´t find it.

Neither in JUCE Doc, nor in juce_amalgamated.cpp.
:?:

#14

Try the SVN tip. The docs on the website don’t have all the latest changes in them.

#15

hm… Ok…thx

What exactly do I need to use within SVN? I´ve never used a “SVN” before.

EDIT:
For those, who didn´t know where to find SVN tip, like me, check this out: http://juce.svn.sourceforge.net/viewvc/juce/

#16

Unfortunately, this is not what I was asking for.

I want to disallow changing the buffer size by the user!

By the way, where is setAudioDevice() gone, since I´ve instaled the JUCE SVN 1.47 ? :shock:

#17

I rearranged some stuff in the audio device manager class. You can still change whatever you need, but it’s done with a structure now.

Can I ask why you’d possibly want to stop people changing the buffer size? If they have a device that doesn’t work correctly at the default size, they’d be screwed!

#18

Of course you can!

I do some timestretching and pitchshifting.

The processing is done via a method of another SDK, which needs a (fixed) outputBufferSize, and depending on this, it demands a fixed inputBufferSize.

I use my own AudioSource-Class (a modified AudioFormatReaderSource)

  1. In getNextAudioBlock I read this amount of neededSamples via AudioFormatReader and
  2. copy the samples from AudioSampleBuffer into my own Buffer ppInputData (Array of Float-Pointer).
  3. These were processed. It returns an Array of Float-Pointer ppOutputData with this fixed outputBufferSize.
  4. Then I copy the result sample from ppOutputData to info.buffer.
  5. Here, the device Callback will read with the settings of Device-Buffer-Size. If the user changes this, my Processing-Method would not handle is properly.

This is a good reason, to restrict ton e.g 512 Sampls, isn´t it?
Thanks for help!

#19

I´m totally confused. How to creat an AudioDeviceSetup object? Can´t access the members like bufferSize and so on…

#20

No.

Hope you’ve not wasted too much time because of that assumption.

When any audio settings change, your audio device will be stopped and restarted, and so will any audio sources that it’s playing. So in your prepareToPlay methods you’ll be able to reinitialise any fixed structures with the new buffer size before it starts running again. Since any audio source is required to be able to stop and start like that, the fact that it’s a user changing the sample rate is irrelevant.

(Unless of course you try to do something hacky like hard-coding everything for a particular buffer size. In which case, good luck with that!)