Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request]: Configurable audio delay for Bluetooth audio peripherals #5600

Open
3 tasks done
geominorai opened this issue Aug 25, 2024 · 3 comments
Open
3 tasks done
Labels
E: new feature enhancement New feature or request

Comments

@geominorai
Copy link

geominorai commented Aug 25, 2024

Guidelines

  • I have searched the issue tracker for open and closed issues that are similar to the feature request I want to file, without success.
  • I have searched the documentation for information that matches the description of the feature request I want to file, without success.
  • This issue contains only one feature request.

Problem Description

This is a rehash of a previous (prematurely closed) feature request from issue #576 from 2020 for reconsideration in the Bluetooth audio peripherals landscape of 2024 where it has gained significant popularity and become much more affordable and commonplace.

Unfortunately, latency issues for Bluetooth audio devices have not significantly improved in the last four years without issues with hardware support or codec licensing (i.e. Qualcomm only open-sourcing aptX and aptX HD with latencies ~200-300ms but not the lower latency aptX Adaptive at ~70-150ms) and not all devices support aptX. Some manufacturers opt to use their own proprietary codec like Sony's LDAC, also ~200ms, which Windows's Bluetooth stack does not support (although Windows 11 eventually did get basic aptX). This means, for compatibility, many Bluetooth headphones may fall back to SBC codec with ~220 latency. Whichever the case, today, almost all Bluetooth audio peripherals connected to a PC will have significant audio latency that cannot be ignored. This is the case for headphones, earbuds, and wireless speakers using Bluetooth.

For mobile devices, many video player apps (including Netflix and YouTube) support delaying the video to automatically compensate for this audio delay. Unfortunately, this is not the case for PC. Video players on PC do not handle this automatically and, at most, it has to be configured manually by the user. FreeTube, unfortunately, does not currently support this feature.

Previously in #576, the workaround suggested opening the video with an external player (which may delegate the task entirely to another library the user has to maintain and keep updated manually, such as yt-dlp), on top of the actual player. This is not only slow, tedious, and error-prone but also does not support FreeTube's many features, such as SponsorBlock, captions, quality selection, and privacy options.

Video and audio having separate streams also seems to be the norm now with DASH formats.

Proposed Solution

I propose adding a button under the video player that pops open a slider allowing the user the change the audio delay (displayed in milliseconds) and observe its effect by changing the playing video and audio streams in real-time, which allows the user to figure out the delay for their device experimentally. Audio sync test videos are available on YouTube to help with this (example). Setting it to 0ms would disable the feature (no delay). The button itself may be optional and only show when toggled in the settings page (disabled by default, for users without Bluetooth audio peripherals).

For ease of toggle (since users may take off their headphones and switch back to speakers), I also propose adding a checkbox next to the pop up slider to quickly toggle the delay feature on or off.

The slider value and on/off toggle would be saved to settings and applied across all videos.

Optionally, but useful: Automatically toggle the delay on when a Bluetooth peripheral is set as PC's current audio playback device and off otherwise.

Alternatives Considered

Just adding an audio delay slider to the settings page under Player Settings may be the simplest UI change, outside of the underlying work needed to get audio delay working. But this would be quite inconvenient compared to the proposed solution.

Issue Labels

new feature

Additional Information

See this video for an audible sample of different audio latencies up to 300ms.

In the worst case, Bluetooth can delay up to 300 ms, and as can be heard, it is quite awful.

@geominorai geominorai added the enhancement New feature or request label Aug 25, 2024
@absidue
Copy link
Member

absidue commented Aug 27, 2024

This is a rehash of a previous (prematurely closed) feature request from issue #576 from 2020 for reconsideration in the Bluetooth audio peripherals landscape of 2024 where it has gained significant popularity and become much more affordable and commonplace.

It's probably just as difficult to implement as it was when the previous issue was opened, if not even harder because the player code has received more functionality and bug fixes since then and is a lot more complicated than it was back then.

Nonetheless I'll leave this open as it's a valid feature request and who knows maybe someone will have a great idea for how to implement it that doesn't involve creating lots of messy code.

@absidue
Copy link
Member

absidue commented Sep 14, 2024

We can get an estimation of the audio output latency with https://developer.mozilla.org/en-US/docs/Web/API/AudioContext/outputLatency, I don't know if it is accurate but that would avoid the user having to configure it manually. The hardest part about this feature request is figuring out how to delay the video and if someone does find a way, they would also have to make sure it is efficient enough that it doesn't turn into a laggy mess. It would probably involve doing a sort of screen recording of the video player and then passing the video data with a delay to a second video player.

@geominorai
Copy link
Author

There was a related feature request at shaka-project/shaka-player#2119 that was closed as completed, but it was not clear as to how it was resolved

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E: new feature enhancement New feature or request
Projects
Status: To assign
Development

No branches or pull requests

3 participants
@geominorai @absidue and others