In Game Voice Chat

[Tiggy]

They can't even code to switch audio channels when you plug in a headset, voicechat would be much harder to do.

That would be a windows/OS function not a game function. So it's not on them. Also, windows 7 and 8 do this as described if you set the windows audio settings properly.

Lastly, many people don't like that functionality by default. I'm one of them.

[OldGeezer]

That would be a windows/OS function not a game function. So it's not on them. Also, windows 7 and 8 do this as described if you set the windows audio settings properly.

Lastly, many people don't like that functionality by default. I'm one of them.

This is not an OS issue, all my other PC games come with this function automatically. FFXIV does not. If they can't provide simple features like this then voicechat is beyond them.

[Sove92]

This is not an OS issue, all my other PC games come with this function automatically. FFXIV does not. If they can't provide simple features like this then voicechat is beyond them.

I have no issues like this, I can switch audio devices without any issues. This is not a XIV problem.

[OldGeezer]

I have no issues like this, I can switch audio devices without any issues. This is not a XIV problem.

Of course it is. FFXIV is the only game-let alone MMO- where I have to log out of the game so I can plug in a headset and listen on headphones. All other MMOs WoW, Rift, EVE, Guild Wars 2, SWTOR, and ESO switch audio the moment I plug in the headset in game. All these other developers make a seemless transition for a simple task such as plugging in a headset, but SE can not. If SE can't get even a simple task like this right which should be standard, voicechat will be beyond them.

[Sove92]

Of course it is. FFXIV is the only game-let alone MMO- where I have to log out of the game so I can plug in a headset and listen on headphones. All other MMOs WoW, Rift, EVE, Guild Wars 2, SWTOR, and ESO switch audio the moment I plug in the headset in game. All these other developers make a seemless transition for a simple task such as plugging in a headset, but SE can not. If SE can't get even a simple task like this right which should be standard, voicechat will be beyond them.

Then why I never need to do that? We all have the same client.

[OldGeezer]

Then why I never need to do that? We all have the same client.

No idea. Have no idea how your audio is configured. I just know that the problem still persists 1 year after launch and my FC friends have to log off and log back on so we can use our headsets and talk. Don't have this issue with any of my other games, so it's no an OS issue. It's an issue with the coding of FFXIV that other developers have found solutions for.

[HiranaiVashai]

All these other developers make a seemless transition for a simple task such as plugging in a headset, but SE can not. If SE can't get even a simple task like this right which should be standard, voicechat will be beyond them.

I had the issue with other programs including chrome, it's been an OS issue. If the headphones are plugged into a different 'audio device' and made the new 'default playback device', Windows won't channel active audio towards that device until stopped and reinitialized by the software.There is a work around SE could implement which other devs might have applied themselves. Basically, it's like the wireless controller issues we used to have where they didn't work on reconnection unless you relogged.

All they need to do is add a check to the loop to see if the default playback device has changed, and once it has, they have to force stop the sound engine and reinitialize on the new device. Another option would be to allow setting a custom playback device. Just check /systemconfig to see what I mean, Display and Gamepad Settings both have a dropdown box to select what gamepad/monitor to use where the Sound settings lack such options. The reason is because it refers to the default playback device and Windows won't stop the stream towards a device until told otherwise.

Coding wise, it doesn't even come close to a matter if they can or can not implement voice chat.

[Squa11_Leonhart]

That would be a windows/OS function not a game function. So it's not on them. Also, windows 7 and 8 do this as described if you set the windows audio settings properly.

Lastly, many people don't like that functionality by default. I'm one of them.

I have no issues like this, I can switch audio devices without any issues. This is not a XIV problem.

Both of you are wrong I'm afraid.

The game requires Device Events to be handled via IMMNotificationClient interface for newly connected or removed audio devices to switch over correctly when using Xinput, currently it does not do this so upon removal of a usb headset sound is permanently lost requiring a client restart.

[Sove92]

Both of you are wrong I'm afraid.

The game requires Device Events to be handled for newly connected or removed audio devices to switch over correctly when using Xinput, currently it does not do this so upon removal of a usb headset sound is permanently lost requiring a client restart.

Why I never lose sound then?

[Squa11_Leonhart]

Why I never lose sound then?

Because you are plugging into an existing jack that lacks jack status (hd spec disconnected/connected state) or simply changing the default audio device in the windows Sound Properties/

The issue is specific to sound devices that become present, or non-present when unplugged (usb device headphones or HD Audio jack with device detection.)

You can reproduce this without owning a usb headset by simply stopping the Windows Audio Service, this will close all audio endpoints and all sound devices will vanish from Sound Properties until the service is restarted - Audio will no longer work in the game client after doing this and will require restarting the client.

Games that support Device Events will recover from the sound service being stopped and started just fine.

As a side note, this only seems to be required by applications that use XAudio, DirectSound (re)aquires the devices just fine.


I may be wrong about the issue being present with hd spec jacks, im not sure if their endpoint becomes fully removed when the status is disconnected, but I know the issue exists with Usb headsets and when the sound service is stopped as I have tested this and because there have been many other reports involving usb headsets for some time.

The endpoint devices that are reported by the operating system faithfully track dynamic changes in the configuration of audio hardware that has jack-presence detection. While an endpoint device remains plugged in, the system enumerates that device. When the user unplugs an endpoint device, the system ceases to enumerate it.

Ok, that seems to be saying that jack-presence would also cause an end point change.