Sound lags when using bluetooth headphones.

[SimpleCold]

When I was on Lollipop on my Xperia Z5, there were no problems with my Sony DR-BT50 headphones, and using them in PPSSPP, but after upgrade to Marshmallow, the game sounds are like a slideshow, but the FPS is stable, and without using headphones sound seems not to lag. (Tested on BlazBlue Continuum Shift, Bleach: Heat the Soul 7). When using the BT50 for other things, like listening music, answering calls, etc., there are no problems, so I think the trouble is on the PPSSPP side.

[MrColdbird]

I can confirm this issue.

[unknownbrackets]

Do other realtime (read: not video player or just audio) apps/games play sound effects smoothly and immediately?

The trouble with bluetooth headsets is sometimes they can have latency. If the app is a video player, latency is easy to solve. If the audio is taking 1 second of latency to play, simply play the video 1 second late. Bam, everything's in sync.

It's not so simple with a game, and especially not simple with emulation. If the video and audio gets played 1 second late, that also means your input is (whoops) also delayed by at least 1 second.

There are other problems, including the sizes of buffers - PSP games use small audio buffers, which doesn't really fit with how bluetooth headsets want to receive sound. A PSP game ported to Android would probably generate its audio and music data differently to play better with Android devices.

It's also possible we're missing some fast path with bluetooth devices, possibly due to the buffer size.

-[Unknown]

[MrColdbird]

On another hand, yes, other real-time applications seem to work. Tried with Skype, Discord and Hangouts, although Hangouts might be a bad example as it falls back to the default audio path if a low latency one isn't available.

Non the less, PPSSPP should have a fallback option for this kind of scenario. One option to go here would be to accumulate samples until the whole OS buffer is filled. This would introduce desynchronization between the video and audio output though, but for those affected by this issue it would still be a viable solution to trade the stuttering audio output for slight desynchronization.

[unknownbrackets]

Accumulating a buffer is exactly what we do. You might try messing with these settings:

https://github.com/hrydgard/ppsspp/blob/eaeddc6c23cf86514f45199659ecc7396c91a3c0/Core/HW/StereoResampler.h#L33

-[Unknown]

[MrColdbird]

It might make sense to expose this setting to the settings GUI then given that different devices have different sample buffer sizes.

[unknownbrackets]

What I meant is, you can try changing those to validate the theory it's even buffer size related.

I'd rather not ask the user to configure a buffer size - just like I don't want an elevator to ask me how many meters or what speed it should move when I want to change floors. If there's a happy medium we can probably auto-configure it, or present a much more sane option if necessary.

But it may not even help, or it may make for a differently unacceptable experience which is I think why @hrydgard configured the values the way they are.

-[Unknown]

[MrColdbird]

I am currently building a custom build to confirm the theory, should it turn out to be correct though then I really highly suggest making this a user configurable option.

While your analogy for the elevator might be correct and not everyone should be messing with this setting, it would be great to at least be able to choose from, lets say, one of three predefined values for this.

I will report back once I've confirmed the theory.

[MrColdbird]

And fixed it.

Change the following two lines in StereoResample.h and Bluetooth will work.

define MAX_SAMPLES (4(1024 * 2)) // 4 \ 64ms - had to increase this by a huge chunk to make Bluetooth work properly

define LOW_WATERMARK 3360 // 80 ms

Should I do a pull request with those two line changes or will you guys just merge it in as a quickfix yourself?

Here's a prebuilt apk with the change included, so you guys can confirm that the Bluetooth bug is gone now: https://mega.nz/#!GQ03wK7Y!uDXDKPPJtmU2-v_5qbyNcIWtwYL_dUDFPmwy5EyMTsM

[unknownbrackets]

@hrydgard what do you think? Seems to me the low watermark is the one we most need to configure, but I'm not sure.

Perhaps we can just configure them based on the optimal buffer size provided by Android?

-[Unknown]

[MrColdbird]

@unknownbrackets Using the default of Android totally depends on whether audio latency is a big deal for the emulator or not I guess.

The default values provided by Android are rather large and are meant to be stable rather than fast (essentially the same my quickfix up there does I guess).

But non the less, yesterday was a great day, being the first day where I could play games properly with my Bluetooth headset, so from a user perspective of things I can tell you that I clearly prefer stable audio over super-low latency audio, as the delay in output caused by this change is hardly noticeable at best.

I've also tested a bit more, swapping between the default buffer size you guys provide, and the one I've set, and found that, even on wired audio and built-in speakers, the buffer value you guys use is still a tiny bit too small (tested on a OnePlus 3), causing a rare but noticeable crackling sound in the audio output (again tested on Wild Arms XF).

This is a hint that the buffer you guys are using might still be too small for fluent audio output and that playback via Bluetooth headsets just made an existing issue more obvious by stacking things on top of each other.

Given that the INDEX_MASK value is based on binary and logic, that makes the values I've given the smallest increase possible at the moment (without altering all the INDEX_MASK logic in the code).

Also, the Android documentation clearly states that audio buffers should be a multiple of the minimum regular buffer sizes, which means that there isn't really a smaller increase we could go for (if the previous comment about the NVidia Shield and it's buffer size is correct).

If all that I said turns out to be true, then the proper solution would be to just merge the change I've provided in and call it a day, or, as first suggested, make the buffer size a config value so that people can finetune their audio output on a per-device basis, with the increased values of mine as a default value.

[MrColdbird]

Has a decision been made about how to proceed yet?

I've been extensively using my custom build with the mentioned changes over the last few days and still have to notice any significant negative side effects.

From my side no complaints so far.

[MrColdbird]

Opened a pull request for the fix now, hope it gets more attention this way. https://github.com/hrydgard/ppsspp/pull/8846

[SamueldeSena]

this problem has already been corrected in the new version of ppsspp v1.5.4 this topic can already be closed

[IrfanH495]

even at U level aptx is still slow what version should i use, to make it better

[IrfanH495]

I think the latest version is good for Bluetooth headset sound, I didn't try it on Samsung level u because it won't turn on. try it on Samsung M20 & Sony MDR-XB50BS headset headset bluetooth+gamepad = feels so great.