1908258 - The system goes to sleep before the next track music.youtube.com on Windows

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect, P2)

Description

[gooomailer]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0

Steps to reproduce:

In Winsows 11 23H2 Used a new profile and portable version Changed the user agent. When using a Bluetooth headset or speaker, set it to sleep after a minute.

Actual results:

On https://music.youtube.com/watch?v=dP4t_GGl3Es&list=RDAMVMdP4t_GGl3Es when playing music without video, after the end of the track the computer falls asleep.

Expected results:

How, without Bluetooth speakers in both Windows 10 22H2 and Chrome, the computer did not fall asleep between tracks

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

[Alastor Wu [:alwu]]

I will take a look on this later.

Comment 4

[Alastor Wu [:alwu]]

I can reproduce this issue without using any headset, the difference between us and Chrome is that they still requested a driver wakelock after track ended, which prevents the computer going to sleep.

---

When audio is playing, both Firefox and Chrome requests proper wakelocks.

• Chrome

SYSTEM:
[DRIVER] Realtek Audio (INTELAUDIO\FUNC_01&VEN_10EC&DEV_0289&SUBSYS_10280BEB&REV_1000\5&54f1b19&0&0001)
An audio stream is currently in use.

EXECUTION:
[PROCESS] \Device\HarddiskVolume3\Program Files\Google\Chrome\Application\chrome.exe
Playing audio

• Firefox

SYSTEM:
[DRIVER] Realtek Audio (INTELAUDIO\FUNC_01&VEN_10EC&DEV_0289&SUBSYS_10280BEB&REV_1000\5&54f1b19&0&0001)
An audio stream is currently in use.

EXECUTION:
[PROCESS] \Device\HarddiskVolume3\Program Files\Firefox Nightly\firefox.exe
non-display request

---

After audio pauses or ends, Firefox would release BOTH wakelocks immediately, but Chrome would release its Process wakelock first, and then relase Driver wakelock later. As its Driver wakelock overlaps with next audio, Chrome is able to keep wakelock all the time during playing audio from Youtube Music playlist. But Firefox would lose wakelock for a very short period of time during the transition of the song.

However, simply considering the behavior of when a wakelock should be hold. I think Firefox is more precise and correct. The problem for me is how Windows count the time for sleeping. When setting sleep time to 1 min, what I expect is "being completely idle after 1 min". When playing audio shouldn't be considered as completely idle, however, that is not how Windows works.

Touching keyboard or mouse would reset the sleep timer, but keeping playing audio or video doesn't seem affecting the timer. So the timer seems starting counting after the music starts, if no wakelock is being hold at any moment after 1 min, then the system would be going to sleep. That can also explain some weird issues we saw before about complaining the system going to sleep unexpectedly.

Comment 5

[Alastor Wu [:alwu]]

We can slightly delay the wakelock releasing as well, because it doesn't really need to be 100% align with the actual playback.

Comment 6

[Alastor Wu [:alwu]]

Attachment: Bug 1908258 - part1 : delay audio wakelock releasing.

Currently, our audio wakelock is precisely synchronized with audible
sound, meaning no wakelock is held when the audio is muted or silent.

On Windows, once the sleeping timer's threshold is reached, the system
appears to enter sleep mode immediately after the audio wakelock is
released. This timing issue prevents a playlist web application from
playing the next song, as the system falls asleep right after the first
song ends.

To address this, we consider delaying the release of the audio wakelock
slightly. This adjustment would allow the next song in the playlist to
start playing and prevent the system from entering sleep mode during
extended silences, which are common at the end of songs.

Comment 7

[Alastor Wu [:alwu]]

Attachment: Bug 1908258 - part2 : no need to delay wakelock releasing for testing.

Depends on D218356

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

There are some r+ patches which didn't land and no activity in this bug for 2 weeks.
:alwu, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit BugBot documentation.

Comment 9

[Alastor Wu [:alwu]]

We will land those patches after bug 1921288 is fixed.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c191ec72d15b
part1 : delay audio wakelock releasing. r=padenot
https://hg.mozilla.org/integration/autoland/rev/9c68ff88874c
part2 : no need to delay wakelock releasing for testing. r=padenot

Comment 11

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/c191ec72d15b
https://hg.mozilla.org/mozilla-central/rev/9c68ff88874c