Ambiera Forum

Discussions, Help and Support.

Ambiera Forum > irrKlang
createIrrKlangDevice() picking default device when deviceID specified

Registered User
2014-11-19 12:36:41


I'm working on a piece of software that runs on a system with multiple sound cards. Each sound card is used and represents something, so it is important that sounds we play to SoundCardA play to - and only to - that particular sound card. If it is unhooked or disabled the sounds should not play at all. Sounds meant for SoundCardA should never play to SoundCardB.

We've implemented this by passing a specific GUID as the deviceID parameter when calling irrklang::createIrrKlangDevice(...).

Our expectation was that if createIrrKlangDevice() fails to find a device with the GUID we told it to use, it would fail. Probably by returning a nullptr, since the documentation says:

Returns pointer to the created irrKlang device or null if the device could not be created.

But, instead, it just silently picks the default playback device.

There doesn't seem to be a way to detect that this has happened either.

createIrrKlangDevice() returns a valid ISoundEngine pointer. ISoundEngine itself has a getDriverName() method, but no getDeviceID() method or anything that could be used to identify it. The only solution I can think of is mucking around with SInternalAudioInterface... but I'd really rather not have to resort to that.

Am I just missing something obvious? Is there a way to force createIrrKlangDevice() to honour the deviceID parameter? Or to detect that it has picked a different device?

2014-11-19 15:00:08

If you specify ESOD_AUTO_DETECT as parameter for creating the irrKlang device, then it will try again a few times until it found something where it can actually play back sound. Try specifying ESOD_DIRECT_SOUND_8 instead, then it should stop after the first failed try.

And just to understand: You aren't storing the GUIDs somewhere, are you? Only supply the GUIDs you get back from irrklang when enumerating the device just before creating it.

Registered User
2014-11-19 16:07:16

Thanks for the swift reply as always, Niko!

I just tried specifying ESOD_DIRECT_SOUND_8 and it has the same behaviour - still picking the default device when the specific one isn't plugged in.

The second parameter is set to ESEO_DEFAULT_OPTIONS, in case it matters.


We are actually storing the GUIDs in a config file, which is created by a small setup/config app that is run when the system is installed and any time hardware is replaced. The config app uses irrklang::createSoundDeviceList() to retrieve the GUIDs.

If I understand correctly, the GUIDs will not change so long as the sound cards aren't replaced or (depending on drivers) moved to different USB ports... or is there something else that could cause them to change?

I know storing GUIDs is not recommended for typical desktop applications, but in our case all the hardware and software is embedded in a larger product. The end-users won't have access to the sound cards or system settings, so it would only be our technicians that would ever change anything significant.

2014-11-19 17:29:20

Ah, ok then. If my suggestion below won't help, I might add an additional flag for this then:

I think a problem might be that your are supplying a GUID of a sound card which won't appear in the enumerated list of devices. So irrKlang is confused then. When you know what GUID you want to use, do this: Get the lost of device ids from irrklang, and if your GUID doesn't appear in that list, then don't create an irrKlang device at all (or a null device, whatever you prefer). This should solve your issue, if I understood correctly.

Registered User
2014-11-19 18:00:51

That's really simple and will work fine, thank you!

Hadn't even occurred to me, since we have a list of GUIDs ready to go already.


This particular case aside, I think it's worth considering changing createIrrKlangDevice() to return null if a deviceID is supplied but doesn't exist. The way it is right now is a bit counter-intuitive.

After all, when you call createIrrKlangDevice(..., ..., THIS_DEVICE_GUID); you're telling irrKlang:

Hey, irrKlang! Give me an ISoundEngine that plays to THIS device!

And irrKlang turns around, hands you an ISoundEngine, and goes:

OK! Here you go!

... but the ISoundEngine it just handed you doesn't play to THIS device. It plays to THAT device instead. And it's not even labelled, so you think you have the right one.

Even if you call createSoundDeviceList() just before, you could imagine a scenario where the device gets disconnected or becomes invalid just after that call and just before the createIrrKlangDevice() call. It's very unlikely, assuming you do one right after the other, but it can happen.

There should be a way to make sure you have the right device, no?

Anyway, just a suggestion for future versions. Your idea will work fine for our purposes.

Thanks again!

2014-11-19 18:15:23

It works that way because irrKlang is supposed to try to be able to play sound, because that has most priority for games. But you are right, the behavior you wanted would also make sense. That's why I meant a flag for this behavior would be nice.

Create reply:

Posted by: (you are not logged in)

Enter the missing letter in: "Internat?onal" (you are not logged in)




Possible Codes

Feature Code
Link [url] [/url]
Bold [b]bold text[/b]
Image [img][/img]
Quote [quote]quoted text[/quote]
Code [code]source code[/code]



Copyright© 2020 Ambiera e.U. all rights reserved.
Privacy Policy | Terms and Conditions | Imprint | Contact