The AudioHapticUpdate function communicates with hardware drivers (Bluetooth)

[rafaelvaloto]

🚨 Experimental Feature Notice
This feature is marked as experimental due to the implementation's location.

All processing (resampling, conversion) and sending (AudioHapticUpdate) is currently performed directly on the engine's real-time Audio Thread.

The AudioHapticUpdate function communicates with hardware drivers (Bluetooth), which are not guaranteed to be real-time safe.

In a worst-case scenario, if the Bluetooth driver or OS hangs for even a few milliseconds, it could block the Audio Thread, resulting in audible stutters, pops, or glitches in the main game audio.

PR: #72

[Deooed]

Hey, do you consider the controller audio endpoint implementation?

[rafaelvaloto]

Thank you so much for the suggestion, that's a truly great idea.

To be honest, the main reason I published the PR early, even with the known issue of consuming audio directly from the audio thread, was precisely to gather feedback like this on the correct way to handle it. I also wanted to let people start testing and making their own suggestions.

Your tip regarding the implementation is very helpful. Thank you!

[rafaelvaloto]

By the way, I just pushed an update that lets you test the vibration variations directly.

I haven't been able to fully map out what these values represent, but they seem to vary the vibration's intensity and texture. You can test it directly from the Unreal console command line.

Usage: ds.SetAudioLR (each 0-255)

I've tested a few values, but I'm still not sure how to best parameterize them:

ds.SetAudioLR 180 30 180 30 255
ds.SetAudioLR 50 50 50 50 80
ds.SetAudioLR 15 15 120 120 40
ds.SetAudioLR 15 0 0 0 40
ds.SetAudioLR 0 15 0 0 40
If anyone wants to test it out and share their findings on what these values control, it would be a huge help!

https://github.com/rafaelvaloto/WindowsDualsenseUnreal/tree/Haptics-Bluetooth