WICG / audio-focus

Other
21 stars 11 forks source link

Use within a PWA context / Service Worker to replicate native audio apps? #27

Open voxpelli opened 4 years ago

voxpelli commented 4 years ago

I'm opening this issue as a follow up to an issue I opened in the Media Session API repo, asking about how that spec would play part in a PWA-replication of a native audio app like Spotify or a podcast app: https://github.com/w3c/mediasession/issues/232

As I somewhat suspected I got pointed here.

Related, there is also an open issue about making the Web Audio API available to Workers: WebAudio/web-audio-api#1098

There's also an issue added to Project Fugu: https://bugs.chromium.org/p/chromium/issues/detail?id=997514

What I basically want to be working towards is being able to create a Progressive Web App podcast/audio player/radio app which can function as seamlessly as a native such player (and which doesn't need to be a Single Page Application).

This would entail having the Service Worker own the audio playback and it interacting with the audio focus, the Media Session API and the Web Audio API to ensure that when eg. one downloaded podcast has been played, the next will start playing + being able to skip etc + deal with audio focus like a user would expect.

To have such playback work from a background thread, I'm imagining that one would also have to be asking the user for some permission, so that not every site out there start playing sound in the background independently of the web page itself.

How would that relate to this specification and is this specification still worked upon to some degree?

NavyCoat commented 3 years ago

I think I'm also looking for this, to be able to play two audio streams simultaneously, like for example, Spotify and my podcast PWA.

voxpelli commented 3 years ago

For future reference, I answered you here @NavyCoat: https://github.com/w3c/mediasession/issues/232#issuecomment-748458132