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

Reply via email to