Add algorithms that describe how type/state are assigned/updated, and how they influence audio sessions and audio focus. #33
Conversation
… how they influence audio sessions and audio focus.
|
This PR is a bit bigger and introduces the algorithms themselves. It requires careful review. |
index.bs
Outdated
| To <dfn>inactivate</dfn> an {{AudioSession}} named |audioSession|, the user agent MUST run the following steps: | ||
| 1. If |audioSession|.[=AudioSession/[[state]]=] is {{AudioSessionState/inactive}}, abort these steps. | ||
| 1. Run the following steps [=in parallel=]: | ||
| 1. [=Change the state=] of |audioSession|'s [=audio session=] to {{AudioSessionState/inactive}}. |
There was a problem hiding this comment.
When I click Change the state, it directs me to 5.2. Update AudioSession’s state. If so, for the consistency, should we say Update the state instead?
There was a problem hiding this comment.
I am trying to distinguish two things:
- web page does something and UA updates the audio session state based on it (inactivating or activating it).
- the audio session stage changes outside of web page activity, and UA updates the AudioSession state.
I used update the state for AudioSession and change the state for audio session.
Any idea how to make that clearer?
There was a problem hiding this comment.
Clicking on change the state should point to the change state definition.
It is true it is close to the update the state.
There was a problem hiding this comment.
TBF simply reading the spec, it's hard to distinguish those two things.
When an audio session element is starting or stopping, the user agent will run steps that change the state of an audio session.
This paragraph doesn't even mention the state change is caused by outside of web page activity. If it's important to let readers understand the differences, maybe we could add your explanation into the spec as well?
There was a problem hiding this comment.
I'll change to set the state and notify the state's change wording, hoping this is clearer.
| 1. Its [=audio session/type=] is an [=exclusive type=]. | ||
| 1. If |activeAudioSessions| is empty, abort these steps. | ||
| 1. If there is only one [=audio session=] in |activeAudioSessions|, set the [=selected audio session=] to this [=audio session=] and abort these steps. | ||
| 1. Assert that for any {{AudioSession}} object [=tied to=] an [=audio session=] in |activeAudioSessions|'s named |audioSession|, |audioSession|.[=AudioSession/[[type]]=] is {{AudioSessionType/auto}}. |
There was a problem hiding this comment.
Could you explain why we need to assert the type being auto? Why can't those audio sessions be other types?
There was a problem hiding this comment.
The idea is that there can be at most only one active audio session with a type that is explicitly set to an exclusive type, since they interrupt each other.
But auto audio sessions do not interrupt each other (that would not be web compatible).
So, if we have more than one session in |activeAudioSessions|, it means that they should all be auto.
There was a problem hiding this comment.
I think it's worth to add your explanation as a note section in the spec. (<div class="note">)
There was a problem hiding this comment.
@tidoust, do you know how to fix this?
The goal would be to render <div class=note> with a big green NOTE.
There was a problem hiding this comment.
What should happen if the assertion fails?
|
@alastor0325, thanks for the review, I addressed some points and will do a change in the other PR. |
|
@youennf I apologize for the late reply. I’ve added a few comments, mostly minor suggestions, but overall it looks great to me. Thank you! |
|
Thanks @alastor0325, I updated the PR according your comments. PTAL. |
|
Gentle ping |
| 1. Its [=audio session/type=] is an [=exclusive type=]. | ||
| 1. If |activeAudioSessions| is empty, abort these steps. | ||
| 1. If there is only one [=audio session=] in |activeAudioSessions|, set the [=selected audio session=] to this [=audio session=] and abort these steps. | ||
| 1. Assert that for any {{AudioSession}} object [=tied to=] an [=audio session=] in |activeAudioSessions|'s named |audioSession|, |audioSession|.[=AudioSession/[[type]]=] is {{AudioSessionType/auto}}. |
There was a problem hiding this comment.
What should happen if the assertion fails?
| 1. The user agent MAY apply specific heuristics to reorder |activeAudioSessions|. | ||
| 1. Set the [=selected audio session=] to the first [=audio session=] in |activeAudioSessions|. | ||
|
|
||
| ## Other algorithms ## {#audio-session-other-algorithms} |
There was a problem hiding this comment.
A minor suggestion, we could have a section per algorithm, rather than grouping them under "other"?
There was a problem hiding this comment.
The assertion failure means that the UA implementation (or the spec) is wrong and should be fixed.
There was a problem hiding this comment.
As of splitting the other section, let's do that in a follow-up.
Co-authored-by: Chris Needham <[email protected]>
Co-authored-by: Chris Needham <[email protected]>
Preview | Diff