Bug 296007

Works fine here: Accepting WebKitUserMediaPermissionRequest request https://people.igalia.com/aperez/joplin.html:24:14: CONSOLE LOG getUserMedia success, fetching devices, stream: [object MediaStream] https://people.igalia.com/aperez/joplin.html:32:14: CONSOLE LOG Audio device enumeration started... https://people.igalia.com/aperez/joplin.html:32:14: CONSOLE LOG stopping audio track "934ed5fc-549e-444c-a299-47a02ec0a2ca" (Built-in Audio Analog Stereo) https://people.igalia.com/aperez/joplin.html:32:14: CONSOLE LOG Device "6F63BCAE32663CBF0A043CAFD1B013139CE7534C" skipped, type is "audioinput" https://people.igalia.com/aperez/joplin.html:32:14: CONSOLE LOG Device "default" added: "Default - Built-in Audio Analog Stereo" https://people.igalia.com/aperez/joplin.html:32:14: CONSOLE LOG Device "A94CCA91C199013F31E1F1FA0267CAF86870F53B" added: "Built-in Audio Analog Stereo" Can you share a GST_DEBUG="3,webkit*:6" log please?

I guess you don't have desktop portals on the device, right?

(In reply to Philippe Normand from comment #2) > I guess you don't have desktop portals on the device, right? That's right, the device for which I first implemented device enumeration/setSinkId does not have portals; and not even PipeWire -- it uses ALSA directly. I forgot to mention above in the issue description that the command used to reproduce needs to be used with the Flatpak SDK. When I noticed that using Flatpak would hit the issue then I continued using it to do the bisection faster.

Created attachment 476071 [details] GStreamer log with GST_DEBUG='3,webkit*:6' Here's the log, running with the following command using the Flatpak SDK, with a build done on commit 297517@main: GST_DEBUG_FILE="$(pwd)/gstreamer.log" \ GST_DEBUG='3,webkit*:6' run-minibrowser --wpe -- \ --features='ExposeSpeakers,ExposeSpeakersWithoutMicrophone,PerElementSpeakerSelection,-SpeakerSelectionRequiresUserGesture,LogsPageMessagesToSystemConsole' \ https://people.igalia.com/aperez/joplin.html The console output is: SDK origin: webkit Using default MiniBrowser Mesa: The provided filesystem timestamp for the cache is bogus! Disabling On-disk cache. Accepting WebKitUserMediaPermissionRequest request https://people.igalia.com/aperez/joplin.html:24:14: CONSOLE LOG getUserMedia success, fetching devices, stream: [object MediaStream] https://people.igalia.com/aperez/joplin.html:32:14: CONSOLE LOG Audio device enumeration started... https://people.igalia.com/aperez/joplin.html:32:14: CONSOLE LOG stopping audio track "0f1105c5-d663-435f-9f26-75066da9c890" (Jabra Link 380 Mono) ^C

Checking quickly the log, it seems that at least the capture device manager picks the outputs (the mono devices are inputs, the stereo ones are two outputs that should be enumerated as spekers): 0:00:01.846763888 37 0x5a27678d8290 INFO webkitcapturedevicemanager GStreamerCaptureDeviceManager.cpp:248:addDevice:<pipewiredevice1> Registering non-default device Jabra Link 380 Analog Stereo 0:00:01.846798102 37 0x5a27678d8290 INFO webkitcapturedevicemanager GStreamerCaptureDeviceManager.cpp:248:addDevice:<pipewiredevice2> Registering non-default device Jabra Link 380 Mono 0:00:01.846817389 37 0x5a27678d8290 INFO webkitcapturedevicemanager GStreamerCaptureDeviceManager.cpp:248:addDevice:<pipewiredevice3> Registering non-default device KM_B2 Digital Audio Analog Stereo 0:00:01.846835182 37 0x5a27678d8290 INFO webkitcapturedevicemanager GStreamerCaptureDeviceManager.cpp:248:addDevice:<pipewiredevice4> Registering non-default device KM_B2 Digital Audio Mono The bulk of the log seems to be related to the autoplayed audio element from the test page. I could remove the “autoplay” and get another log with different options if that would be helpful =]

> PipeWireCaptureDeviceManager.cpp:65:computeCaptureDevices: Checking with Camera portal Somehow the DesktopPortal is created and is valid, there's no "Portal not present or has no camera" log message... So portal->accessCamera() is called and hangs there, apparently... I don't understand that you have no portal running, but still the dbus proxy seems created and connected to /org/freedesktop/portal/desktop? Maybe we're mis-using g_dbus_proxy_new_sync()... Can you capture a dbus log with dbus-monitor?

Also it's worth testing with an early return from PipeWireCaptureDeviceManager::computeCaptureDevices() (call `callback()` before returning).

Pull request: https://github.com/WebKit/WebKit/pull/48241

(In reply to Philippe Normand from comment #8) > Pull request: https://github.com/WebKit/WebKit/pull/48241 Indeed, with this applied I get device enumeration working again as expected.

Committed 297669@main (04d2f39a0b79): <https://commits.webkit.org/297669@main> Reviewed commits have been landed. Closing PR #48241 and removing active labels.

<rdar://problem/156295253>