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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
