Skip to content

Conversation

mdydek
Copy link
Contributor

@mdydek mdydek commented Jun 9, 2025

Closes #

Introduced changes

  • proposition of slight changes in settings types

Checklist

  • Linked relevant issue
  • Updated relevant documentation
  • Added/Conducted relevant tests
  • Performed self-review of the code
  • Updated Web Audio API coverage
  • Added support for web

export interface AudioOptions extends BaseAudioOptions {
androidAcceptsDelayedFocusGain?: boolean;
androidAudioAttributes?: AudioAttributeType;
androidFocusGain?: focusGainType;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can't comment on the original type: we should have only one case-type when it comes to setting options, currently:

  • ios settings are camel case
  • android settings are snake case
  • permission status (which is kind of related) is upper-case

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also i'm wondering if we should include spatialization behaviour currently, it seems it is either auto or off. I think we could stick with whatever is default for now.

Especially some-day we will have our on spatialization implementation thus we would like to have this off by defULT

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we talked a bit today about this: could you add short JSDoc-like descriptions to the values (aka what is their meaning). Could be a great start for documenting the api on code-level :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

with case-type I wanted to stick with original system values, therefore it is different for ios and android, but it can be narrowed to one easily

@mdydek mdydek requested a review from michalsek June 17, 2025 13:35
* interruptions and emit events accordingly (true by default).
* @param options - Additional audio options to configure the audio session.
*/
setAudioOptions(observeAudioInterruption = true, options?: AudioOptions) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we have to call observe interruption every play invocation on Android so merging AudioSession settings into one method its not the best option in my opinion

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so am I correct, if the audio interruption event will be fired, it won't be invoked 2nd time and we have to re-observe it?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants