16:57:29 RRSAgent has joined #mediawg 16:57:33 logging to https://www.w3.org/2025/02/19-mediawg-irc 16:57:33 Zakim has joined #mediawg 17:05:34 Meeting: Media WG 17:05:39 Chair: Chris 17:06:05 Present: Chris_Needham, Alastor_Wu, Youenn_Fablet, Tommy_Steimel 17:06:17 Topic: Audio Session preferredSinkId 17:06:56 Youenn: There's a preference in general to have this kind of API. Aligns with iOS. Hard there to have two media elements each going to a different speaker 17:07:16 ... So having a more global way to send audio to a selected speaker makes sense on iOS. Are there similar principles on Android? 17:07:48 ... There's a question of which WG would develop this API 17:09:40 Sunggook: We have feedback from partners who want to control audio outputs across all frames, cross-origin 17:09:49 ... Media can play in cross-origin iframes 17:10:17 ... Cross-origin iframes play to the default device, which is the system default 17:10:36 ... There's a mismatch, so they want to control via a single API 17:10:54 ... Each frame could set its own output via AudioContext setSinkId 17:11:18 ... So we provided a new API for the whole app, so as long as they set the default, it affects the align and individual frames 17:12:01 Tommy: Do both proposals accomplish that, or is there some aspect that differs? 17:12:26 Sunggook: Not clear with AudioSession how it handles the cross-origin case, and how frames interact with each other 17:12:38 Youenn: I don't think we went into that details, so it's open to discussion 17:12:59 ... It's syntactic sugar where you put it, in AudioSession or on MediaDevices 17:13:08 ... The 3P iframes use case makes sense to me 17:13:23 ... Good idea to use the heirarchy of iframes to restrain where the audio goes, based on the heirarchy 17:13:28 ... That's independent of API shape 17:13:45 ... I'd like to fuse the two proposals into one, and discuss which WG works on it 17:13:55 ... I think it's tackling the same issues, and have one solution 17:14:10 Tommy: Does AudioSession include cross-origin iframes as part of the same session? 17:14:33 Youenn: Not currently. You have mutually exclusive sessions, so if one is playing, others are suspended 17:14:47 ... If you don't set explicitly, you might not have the same heirarchy 17:15:01 ... For existing pages, use of AudioSession shouldn't be disruptive 17:15:29 ... So if you're not using AudioSession, two iframes shouldn't be disrupted. But setting the audio session type is where things kick in 17:15:47 ... If you have an iframe using an AudioContext, under the hood it would be similar to the ambient audio session 17:16:24 Tommy: If we're saying that the website sets its audio output device on the top level audio session, then it should say any iframes should go through he same audio session 17:16:47 ... Would it make sense if the user creates more than one audiosession? 17:17:32 Youenn: You create one top level, or refer to the top level. There's one AudioSession per document 17:17:49 Tommy: And is it easy for the top frame to set the output device for the cross origin iframes? 17:18:13 Youenn: It's difficult. 3P iframes would have different ids as they'd be partitioned 17:18:40 ... If you have a cross-origin iframe that's a cousin, but not a child? We'd need to define 17:18:54 ... You could find the top-level document, have a property there, or something like that 17:19:16 Sunggook: If there's a nested iframe, it could call setSinkId and it affects all, as current behaviour 17:19:32 ... Interaction with the existing setSinkId on AudioSession and media elements? 17:20:03 Youenn: AudioSession would be the default. Check the media element sinkId, then go to the AudioSession in the document, then go through the heirarchy, just like for media devices 17:20:07 ... That's a potential algorithm 17:20:22 Sunggook: So with nested iframes you'd have to check the parent's parent etc 17:20:25 Youenn: Yes 17:21:03 Alastor: We can have multple AudioSession per iframe. But only one should be active. If we have multiple, each has its own id set, we'll only make one activated 17:21:28 ... So in this case we'll encounter that setting sinkId on the AudioSession makes it more complicated, IIUC? 17:21:56 Youenn: If you' don't set the audiosession type, it won't interrupt. You can have multiple active. It's only when you set the type to "playback" it'll suspend the others 17:22:06 ... Only this particular iframe will be able to play audio 17:22:44 Alastor: So if I have an embedded iframe that sets the sink id to a specific output, the output will be routed, but if the main page sets it's own id, that woud override it? 17:23:13 Youenn: Depends. If it interrupts, then the iframe might be paused. If not, the sinkid will go to the top level 17:23:23 Alastor: So only one should be playing audio 17:23:40 Youenn: If two are both set to ambient, they don't interrupt each other 17:24:22 ... if iframe A sets idA, and iframe B sets idB, then iframe A and all its children go through idA, and iframe B and all its children go through idB. Top level page goes through the default 17:24:36 ... We can define these results regardless of where we put the API 17:25:15 ... Need to decide which is more natural for web developers. And in future, if you create multiple audio sessions programmatically, is it good to be able to set an id there or not? 17:25:26 ... I'd like to concentrate on these questions, to help decide where the API lives 17:25:42 Tommy: If you have a top frame and iframe and each has an audiosession, the iframe can interrupt the top level? 17:25:48 Youenn: If set to playback, yes 17:26:11 Tommy: There isn't a parent-child relationship in general? 17:26:16 Youenn: Not today, no 17:26:57 ... If I were to specify it, i'd have a slot in AudioSession, then the algo would go thorugh the heirarchy chain, when it finds one not null, use it 17:27:13 ... (or on MediaDevice) 17:27:38 ... Not sure we're ready for that yet, it's for the future 17:28:21 ... Could be a surprise for developers to put AudioSession. In the spec it has a list of all the audio producers it's tied to 17:28:43 ... It's handy for saying that this group of producers goes to that speaker itselft 17:29:00 Chris: This is an argument for putting it into MediaDevice 17:29:28 ... MediaDevice allows enumeration, and getUserMedia, and getDisplayMedia 17:30:00 Sunggook: In terms of iframe relationships, I'd think of setPreferredSinkId as a simple global API. 17:30:18 ... It's an extension of the exisitng setSinkId, but affecting the whole application 17:30:47 ... If we put into AudioSession, the sinkiD may be confused with using setSinkId 17:31:40 Alastor: We have a dedicated setSinkId on mediaelement. We could put onto MediaDevice first, then when we have more experience, revisit AudioSession, as an idea 17:31:53 Youenn: In that world, you'd setSinkId on AudioSession as well? 17:32:14 Alastor: Yes. The AudioSession let's you set the type, so should be able to set the output device there too 17:32:39 ... If setSinkId is more fit for mediaDevice, could have a different label for the override, and different granularity 17:32:58 Youenn: That could work. If we have two, then we could further simplify setPreferredSinkId 17:33:26 ... If you have a top-level page and two iframes and children, set the preferred id in iframe A and B, do you need the heirarchy rules, or have it as just global 17:33:35 Sunggook: In our proposal it's a global, no heirarchy 17:34:04 Tommy: So an iframe could set it and it affects the top-level frame? 17:34:20 Sunggook: Yes. But the iframe could continue to use setSinkId 17:34:48 Youenn: There's a speaker-selection feature policy. 3P iframes could be allowed this global switch 17:35:26 ... I'm wondering how it's working. If one iframe selects speaker A, another B, how to know which to use? 17:35:44 Sunggook: The frames can override the default by calling setSinkId 17:36:42 ... if they call setPreferredSinkId, it affects the top level frame 17:37:02 Alastor: I'm concerned an iframe might misuse the API by altering the main frame's behaviour 17:37:28 Sunggook: The top frame would set the permission for the iframe, and the iframes need to be same-origin with the top level 17:37:54 ... Use the speaker-selection feature policy, we don't propose creating a new one 17:38:13 Tommy: Any reason not to make it heirarchical, so it affects you + children? 17:38:37 Sungook: We haven't thought about that, as our partners want a global, and it comes from one of their own iframes 17:39:07 Tommy: I assume a heirarchical one should solve their problem too 17:39:41 Sunngook: Heiararchical may be harder for developers to understand, and to debug. Hence why we propose a simple global 17:40:09 Youenn: The concern is two iframes fighting by setting the preferred id 17:40:27 ... How do they know which sinkId is currently preferred or in use? 17:40:54 Sunggook: It's up to the developer how they'll provide their interface to the user 17:41:31 Youenn: Not sure if it's easier to debug for web developers. In one case it's time sensitive, in other case there's a heirarchy. Heiarchical might be easier 17:42:13 Sunggook: But would it be clear from the user perspective? They don't know the relationship between frames 17:43:01 Tommy: As a developer I think I'd be confused if not heirarchical, and also if it affects siblings. it should be the top-level frame's decision to set for itself and child iframes 17:43:29 Youenn: Can we restrict this API to only the top-level document? Not sure we have other APIs that do that 17:43:49 Sunggook: We could restrict the API, so only the top level can call the API 17:44:28 ... Not sure about other APIs. Same origin APIs can do the same as top-level, which is why we proposed to allow 17:48:09 Chris: Not sure we're ready to conclude today. Suggest thinking about whether the heirarchical aproach satisfies the use cases? 17:48:55 Youenn: Also find an example of an API that allows interaction with page-global state 17:49:14 Suggook: I'd like to avoid heirarchical if we can. We could limit to top-level frame only 17:49:36 Youenn: Could be a good start, as it's constrained 17:50:11 Chris: Suggest we think in this more, and come back to it 17:51:00 ... And what about MediaDevices as home for this? 17:53:18 Sunggook: We feel MediaDevice might be right 17:53:31 Chris: I feel like we need to discuss the processing model in general as well 17:54:57 Topic: Horizontal reviews 17:55:13 Chris: I'm thinking early review from Accessibility may be beneficial 17:57:10 Youenn: We need to do the privacy and security self reviews 17:58:18 ... I can write the privacy and security sections, then do the reviews 17:58:34 Chris: And I can start the accessibility self review 18:00:43 [adjourned] 18:00:48 rrsagent, draft minutes 18:00:49 I have made the request to generate https://www.w3.org/2025/02/19-mediawg-minutes.html cpn 18:01:00 rrsagent, make log public 18:09:05 present+ Sunggook Chue, Jasper_Hugo 18:09:19 Regrets: Francois_Daoust, Marcos_Caceres 18:09:22 rrsagent, draft minutes 18:09:24 I have made the request to generate https://www.w3.org/2025/02/19-mediawg-minutes.html cpn 20:16:38 Zakim has left #mediawg