Replace 'participating media elements' with 'participating audio producers'

[richtr]

This issue is based on the discussion starting at #48 (comment) and the reply comment at #48 (comment):

---

I think it would be better to introduce some concept like "audio producer" and say that media elements and audio contexts both have an audio producer. Maybe eventually audio producer gets defined in terms of web audio, e.g. as an audio worker.

So I will work on replacing 'participating media elements' with a generic like 'participating audio producers'.

The net effect of this would be to isolate the interface points between media session and media elements/audio contexts down to just a single section in the spec, instead of spreading it throughout.

I will then work on defining interaction of media sessions with audio producers in separate algorithms (e.g. 'pause an audio producer', 'unpause an audio producer', 'duck an audio producer', 'unduck an audio producer', etc).

Right now those algorithms will probably treat AudioContext and HTMLMediaElement objects separately (e.g. 'For each AudioContext-based audio producer...suspend() the audio context', 'For each HTMLMediaElement-based audio producer...pause() the media element', etc). We could then eventually replace those algorithms with something based on AudioWorker or whatever our unified 'audio producer' ends up being.

[richtr]

Also see @domenic's feedback @ #48 (comment).

[richtr]

@domenic Commit 875f2a7 replaces 'participating media elements' with 'audio-producing objects' to provide what I think is a good abstraction for future 'audio-producing object' additions (e.g. enabling AudioContext-based media focus pending the outcomes of discussion at #48 & #50).

If there are further issues or, if you really want to instead see this written as per your suggestion at #48 (comment), then please re-open this issue or create a new issue as you feel is appropriate.

Thanks!

[domenic]

I mean, I think that adding switch statements ("If audio-producing object is not a media element") throughout the spec is kind of sad, and will only get sadder as those parts get fleshed out to support AudioContext, and AudioContext becomes more tied in to all this. But I'll leave that kind of factoring decision for you guys.

[foolip]

I agree this kind of type testing is a sign that the layering isn't complete. I'm not sure it would be implemented with a type test and cast though, so perhaps trying to implement this will inform how it should be expressed in the spec.