[bug] Commit 36a111a is interfearing with and crashing steam games with native Dualsense support

[tamodolo]

The commit is interfearing with games that have native support for the Sony's Dualsense controller.

On Arch after this update games cannot send haptics properly to the controller over USB and crash after some time or at launch.

In my case, Final Fantasy XIV Online became unplayable after this update because it is crashing at launch. When it works haptics don't.

The problems does not happen when the profile is deleted from the system. Solution found by this reddit user

[perexg]

@cristicc : Any comments from the author of this commit?

It seems that we have a resource clash and the sound server should probably create a haptics data channel without resampling in the path. Games should use this stream instead direct USB (or ALSA PCM device) access.

I think that pipewire developers should be involved (thus create similar issue in pipewire bug tracker - https://gitlab.freedesktop.org/pipewire/pipewire/-/issues . UCM may just identify which channels in stream are haptic.

You can eventually suspend pipewire (or pulseaudio) PCM devices using pasuspender or configure pipewire to ignore the Dualsense ALSA card until a better solution is found.

[cristicc]

@perexg I have already provided a potential fix cristicc@48af6ea for which I requested some feedback before opening a MR:
ValveSoftware/Proton#5900 (comment)

This seems to work fine so far, but there's something I'd like to improve: would it be possible to mix FR & FL channels into a mono channel, while still using separate RL & RR channels for the haptics feedback? This is only needed when using the controller's builtin mono speaker instead of the headphones output.

My failed experiments were based on the following approach:

	{
		SplitPCM {
			Name "dualsense_mono_haptic_out"
			Direction Playback
			Channels 3
			HWChannels 4
			HWChannelPos0 MONO
			HWChannelPos1 MONO
			HWChannelPos2 RL
			HWChannelPos3 RR
		}
	}

...

SectionDevice."SpeakerHaptic" {
       Comment "Internal Mono Speaker + Haptic Feedback"

...

        Macro.pcm_split.SplitPCMDevice {
                Name "dualsense_mono_haptic_out"
                Direction Playback
                HWChannels 4
                Channels 3
                Channel0 1
                Channel1 2
                Channel2 3
                ChannelPos0 MONO
                ChannelPos1 RL
                ChannelPos2 RR
        }
}

[perexg]

I think that cristicc@48af6ea is not correct. The haptic feedback should be defined as separate "stereo" device. We should also add "Haptic" or "AuxData" name to https://github.com/alsa-project/alsa-lib/blob/master/include/use-case.h#L132 . Also, the channel positions may not be FL and RL. What is exact purpose for those samples (streams) ? Vibration, up-down, left-right ?

[tamodolo]

This seems to be taking a while to be figured out. In the meantime Dualsense can't be left broken as this controller is quite popular. This update is starting to reach gaming distros like Bazzite and I'm starting to see people pulling hair out of their heads. That said the commit must be reversed. @cristicc please do that.

For anyone landing here because of this problem, this is the workaround (for Arch based):

Open the terminal and run the following commands:

sudo rm /usr/share/alsa/ucm2/USB-Audio/Sony/DualSense-PS5.conf
sudo rm /usr/share/alsa/ucm2/USB-Audio/Sony/DualSense-PS5-HiFi.conf

Next open the file /usr/share/alsa/ucm2/USB-Audio/USB-Audio.conf with a text editor like kate and remove the following lines:

If.sony-dualsense-ps5 {
Condition {
Type RegexMatch
String "${CardComponents}"
# 054c:0ce6 Sony Corp. DualSense wireless controller (PS5)
# 054c:0df2 Sony Corp. DualSense Edge wireless controller (PS5)
Regex "USB054c:0((ce6)|(df2))"
}
True.Define.ProfileName "Sony/DualSense-PS5"

After this you can connect your dualsense again and it'll work as intended.

[perexg]

Open the terminal and run the following commands:

sudo rm /usr/share/alsa/ucm2/USB-Audio/Sony/DualSense-PS5.conf
sudo rm /usr/share/alsa/ucm2/USB-Audio/Sony/DualSense-PS5-HiFi.conf

Next open the file /usr/share/alsa/ucm2/USB-Audio/USB-Audio.conf with a text editor like kate and remove the following lines:

...

After this you can connect your dualsense again and it'll work as intended.

Or simply add this line to /usr/share/alsa/ucm2/USB-Audio/Sony/DualSense-PS5.conf:

diff --git a/ucm2/USB-Audio/Sony/DualSense-PS5.conf b/ucm2/USB-Audio/Sony/DualSense-PS5.conf
index 42d525b..1064210 100644
--- a/ucm2/USB-Audio/Sony/DualSense-PS5.conf
+++ b/ucm2/USB-Audio/Sony/DualSense-PS5.conf
@@ -4,3 +4,5 @@ SectionUseCase."HiFi" {
        Comment "Default"
        File "/USB-Audio/Sony/DualSense-PS5-HiFi.conf"
 }
+
+Error "UCM support temporary disabled for ${CardLongName}"

[cristicc]

The haptic feedback should be defined as separate "stereo" device.

That won't work since the games making direct use of the controller (i.e. not through an emulation layer like Steam) expect a 4-channel stream to be available - that's actually the root cause of the problem.

What is exact purpose for those samples (streams)?

The additional channels are used to provide haptic feedback (L & R vibration).

Marking them as unknown/aux might confuse some games, e.g. generating unexpected vibration during normal audio playback and/or no haptic when actually expected, hence I think we should keep them as RL & RR for now.

[perexg]

I don't follow the whole picture. Pipewire is using UCM for this moment, so games are using pipewire or the direct device access? Then the channels can be routed correctly.

Also, those streams seem not to be for audio, so we should describe them correctly IMHO.

I also don't think that it's good to mix the rear-left/right positioning with the haptic left/right positioning (functionality).

So ideally, we should introduce SNDRV_CHMAP_HAPTIC_LEFT, SNDRV_CHMAP_HAPTIC_RIGHT (see include/uapi/sound/asound.h) and set this positioning in the driver (and eventually in UCM). It will mean to add this to all layers (driver, alsa-lib, pipewire). With this, games can detect and identify the haptic output correctly even for the "stereo" stream.

How the current games detects PS5 controller?

[xzn]

I've been working on (along with others) getting DualSense haptic working through games running under Proton wine, it works like this:

Detection:

• Games check name + container id of audio devices
• Names are provided by wine by checking vid/pid of usb path of audio devices, and overridden with correct value (instead of the one provided by systemd udev config)
• Container ids are provided by querying sysfs.path from pipewire/pulseaudio by wine

The above aren't affect by the changes in ucm.

Usage:

• Games open the desired audio device selected above in quad channel surround.
• Games send audio to FL/FR channels to play sound on DualSense speaker/headphone.
• • Speaker plays FR channel, FL is dropped. Headphones play both channel in stereo.
• Games send haptic to RL/RR

The games do all of above. All wine does is expose the device as it is to the game, so it looks somewhat like what happens on Windows. (Where DualSense audio is also a quad channel surround device).

In short from the point of view of games running under proton, they want a plain surround device exposed as it is.

My personal option is that any additional functionalities should be done by user config (at users' discretion) on pipewire/pulsewire. If ucm should make any changes to the layout of the device audio channels, wine will have to be updated to be aware of those, and somehow fake a quad surround and map to those changed layout. i.e. if ucm should add any layout config for DualSense audio devices, it should be made optional.

[perexg]

@xzn: So wine uses the USB audio device exclusively without pipewire/pulseaudio (suspending streams)? If PW/PA is used, which sink/source is expected to be available ? The enumeration and detection seems clumsy without any abstraction here. UCM defines profiles in PW/PA, so the sinks/sources can be different from the legacy sinks/sources for ALSA sound cards.

[xzn]

Sorry to clarify,

Wine has working haptic for games only with pipewire/pulseaudio. Wine will query vid, pid, and sysfs.path of audio devices from pw/pa. And generate name and container id so games can select the right device.

Wine also has an alsa backend but it doesn't implement the things needed for haptic.

The games use the surround device directly in the sense that if channels layout are rearranged, games won't be able to send haptic to the right channels. (Sorry I didn't convey it clearly)

Edit: to put it a different way, Windows games running under proton do not have ways of dealing with abstractions provided by ucm. So wine would have to undo those abstraction for games.

[perexg]

It sounds like that PW/PA and the ALSA driver is not used at all except detection and the PS5 Controller USB device is detached from the ALSA driver when wine application asks to use it, right ? So, USB device is removed from the system on demand.

[xzn]

Games send audio data to wine using Windows APIs, wine translate them to calls to pipewire/pulseaudio which then uses alsa. So they are all used.

So alsa exposes the device as surround, that gets relayed to game though pipewire/pulseaudio then wine. Neither wine or pipewire/pa currently alters the surround channels layout.

[perexg]

Okay, makes sense and it's more clear now. Pipewire does channel split using routes, so the hardware device is available even when UCM is used. So it's just about selecting the correct output (sink) in pipewire. I cannot comment pulseaudio.

Does wine have native pipewire client or pulseaudio API (client) is used ?

With the pipewire protocol, there are also available original ALSA device ports (channel streams), because split is handled using routes. So it may resolve the problems and keep out the haptic channels outside audio world. It will mean that the requirement for 4 channel sinks would be gone.

[xzn]

Wine uses pulseaudio not pipewire. With pipewire it'd be pipewire-pulse.

The problem isn't wine selecting the correct routes. Games expect a surround device and send audio to RL/RR for haptic. Either we keep that or wine has to do manual mapping, which isn't preferred since it's more work.