On Mon, Sep 07, 2020 at 05:03:59PM -0700, guest271314 wrote: > > I doubt that will be possible. Pavucontrol makes use of the native > > pulseaudio APIs, which are not exposed to javascript. > > If mpv can be embedded in an HTML document > https://github.com/Kagami/mpv.js it should be possible to embed > pavucontrol or pavucontrol-qt > (https://doc.qt.io/qt-5/qtwebchannel-javascript.html ; > https://medium.com/@petar.koretic/why-you-should-use-qt-qml-for-you-next-cross-platform-application-part-1-desktop-5e6d8856b7b4) > in particular in a browser; for example using WebAssembly; WASI; > Native Messaging; at least the ability to control Recording tab (-t 2) > from JavaScript or an HTML form.
Electron is a whole separate discussion. Electron applications have different levels of access to the system than the vanilla chromium browser. > > After reading through those bug reports and related issue links, it's > > pretty clear that this is not a use case that they are particularly > > interested in supporting. > > The majority of own repositories at github are dedicated to fixing > WontFix; supporting SSML parsing; variable width and height video > capture with ability to merge multiple tracks into a single media > container, or stream media without a container; streaming audio > potentially infinite input streams, that is, a dynamic Internet radio > station; capturing speech synthesis output from Web Speech API, which > is the origin of this use case of capturing system audio output. > > > May I perhaps suggest using a different > > browser? Firefox had no problem with monitor inputs last time I > > checked. > > Interestingly, am completing testing of another workaround where since > Firefox does capture monitor devices, a new, dedicated instance of > Nightly is started prior to launching Chromium, the MediaStreamTrack > and MediaStream therefrom are added to a WebRTC RTCPeerConnection, and > currently using clipboard for signaling which is not ideal though is > one way to exchange text data between different browsers, accessing > the monitor device at Chromium instance generated at Nightly > https://gist.github.com/guest271314/04a539c00926e15905b86d05138c113c. > That approach avoids writing and reading raw PCM to memory. With the amount of work you're seeming to have put into workarounds, maybe you would be better off writing a proper native application? > > No idea, I've never done it myself. The example listed in the online > > docs shows a simple stereo swap, so you could presumably adapt it by > > switching the channels to be non-swapped (and of course substitute your > > specific master source name). > > Not sure precisely how to begin. > > Am still trying to gather the specific commands in code that > pavucontrol uses when setting the stream at the UI. Am not certain > what to pass to pactl move-source-output at what time > https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues/91#note_590795. If you read the documentation (e.g. man pactl), it seems pretty straightforward: > move-source-output ID SOURCE > Move the specified recording stream (identified by its numerical index) > to the specified source (identified by its symbolic name or numerical index). So you need to find the specific source output index (ID) and your new target source (SOURCE). I started an audacity session recording my microphone, and ran the "pactl list source-outputs" command. This gave me the index. I then ran the "pactl list sources" to find my target source name. The switch command (for my setup) then looked like this: > pactl move-source-output 203 pulse_send_nofx.monitor --Sean _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
