Retrieve (recording) device guid

Hi there, additionally to using FMOD, we’re using PlayFab for voice chat in our game and it supports the ability to choose the in/output devices. PlayFab expects a device context identifier which is based on the guid of the device. This should correspond to the guid as provided by WASAPI. From my understanding when using getDriverInfo or getRecordDriverInfo FMOD will return a guid for the device. However, I cannot seem to match this guid to any of the guids when going over the device details in device manager.

For example. FMOD returns the device guid + name: b468da79-a55f-b39e-7fed-0a826fb287c6 | Microphone (Arctis Nova Pro Wireless) Where according to Windows Device Manager the guid is actually: {9f6ed24c-3d58-46be-8dfe-67f47539806e}.

Is there any API available through FMOD so we can get the device guids as defined by WASAPI? Or would we have to implement WASAPI ourselves?

Hi,

Thank you for sharing the information!

The GUIDs returns from System::getDriverInfo and System::getRecordDriverInfo are identifiers used by FMOD to represent devices for the current output mode, and are not guaranteed to match the GUIDs defined by WASAPI or shown in Windows Device Manager.

In older versions, the GUID returned by getDriverInfo / getRecordDriverInfo could match the WASAPI device identifier. However, in newer versions (2.03) FMOD generates its own device GUID instead, so it’s no longer expected to match.

Hi, thanks for your reply.

I’ve just verified with one of our older games, where we use the same API to retrieve device guids. And there the device guid returned by FMOD matches the device guid as done by WASAPI.

So with FMOD 2.00.21 getRecordDriverInfo returns the device guid as done by WASAPI. (As desired). But with FMOD 2.03.07 getRecordDriverInfo returns an internal guid defined by FMOD.

I understand these versions are quite far apart, but this was the easiest setup I could test without having to up/downgrade FMOD. Either way, somewhere along the line FMOD started returning different guids. Would it be possible to revert this, or change the API so it can output the guid as defined by WASAPI?

1 Like

Just did a test with FMOD 2.02.19, and there the guids returned are the same as done by WASPI.

1 Like

Thank you for your detailed testing across different FMOD versions, and apologies for any confusion earlier.

What you are observing is correct. This behaviour has changed in newer versions of FMOD.

Historically, FMOD parsed the WASAPI device identifier to generate the GUID returned by getDriverInfo and getRecordDriverInfo, which is why it appeared to match in older versions.

However, Microsoft recommends treating the WASAPI endpoint ID as an opaque string and not parsing it. As a result, FMOD now generates its own device GUID instead.

Because of this, the GUID returned by FMOD in newer versions is no longer expected to match the WASAPI device identifier. These GUIDs are intended to be unique and stable within FMOD, rather than mapping directly to system device IDs.

I have checked internally with the team, and this change was made intentionally. Based on this, it’s unlikely that this behaviour will revert in newer versions.

That’s unfortunate. I didn’t see anything about this change in the detailed change logs. Do you happen to recall which version this change was applied to? As this would definitely have prevented us from updating. Would like to know if a downgrade is still feasible for us at this point.

Ironically, PlayFab (which is owned by Microsoft) does expect you to use the guids as reported by WASAPI. But I can understand why you’ve implemented the change from the FMOD side.

I did a quick check on my end as well.

In 2.02.33, getDriverInfo / getRecordDriverInfo still appear to return the device GUID matching the WASAPI identifier, while from 2.03.00 onward this is no longer the case.

This lines up with what I’ve confirmed internally, that the behaviour change was introduced in 2.03.00.

Hope this helps!