Wex record audio from soundcard in KLV-Airedale

[fredx181]

Wex record audio from soundcard in KLV-Airedale

Default audio recording is from microphone AFAIK, but I wanted to record the screencast with "What you hear" audio from soundcard, here's how I did:
Default at bottom of configuration window:

Screenshot(2).png (12.68 KiB) Viewed 28110 times

Found the "monitor" output (from pipewire as used in KLV-Airedale and on some other KL distros too) by typing in terminal pactl list short sources and got number 50

Screenshot(4).png (18.22 KiB) Viewed 28110 times

Then changed at the configuration screen to "pulse" and "50" and it works !

Screenshot(3).png (12.37 KiB) Viewed 28110 times

[rockedge]

@fredx181 this is excellent information!

[fredx181]

@fredx181 this is excellent information!

Thanks. To add: instead of '50' it works for me also to make it alsa_output.pci-0000_00_0e.0.analog-stereo.monitor
Just exploring the possibilities. Perhaps easier, as you don't have to run pactl list short sources first then, but I'm not sure if that works for everyone.

[wiak]

That's amazing. I've lost track of all that kind of stuff.

[mikewalsh]

@fredx181 :-

Hmm. In-ter-esting...

Is this with WeX as it was originally built some years back, Fred, or has it since been re-factored to work with Kennel Linux? I'm just wondering if the portables will work with newer Pups and Pulse/Pipewire, using this trick, because they were built around the AppImage you constructed back then with the built-in 'static' ffmpeg from John van Sickle...

I've definitely developed my favourites for screen-captures, and that's either RecordMyDesktop or WeX (where the former won't run under newer Pups, because they no longer use Python2).

Just curious, TBH!

Mike.

[rockedge]

@mikewalsh WeX main code is not modified. Because KLV-Airedale and KLV-Spectr has GTK2 and python2 components alongside GTK3 and python3 which we specifically included at the time, to be able to run applications directly borrowed from Puppy Linux variants, without much code modifications.

Most of the time just switching which gtkdialog to use. Either gtk2dialog or gtk3dialog which are both included.

It has been awhile since I looked at WeX code closely since it's been working since KLV-Airedale and KLV-Spectr has been offered to the public.

@fredx181 has figured out how to configure WeX to work well with the pipewire audio KLV-Airedale and KLV-Spectr are equipped with.

[fredx181]

@fredx181 :-

Hmm. In-ter-esting...

Is this with WeX as it was originally built some years back, Fred, or has it since been re-factored to work with Kennel Linux? I'm just wondering if the portables will work with newer Pups and Pulse/Pipewire, using this trick, because they were built around the AppImage you constructed back then with the built-in 'static' ffmpeg from John van Sickle...

Mike.

No, the WeX in KLV-Airedale is version 0.8.21 and made by wiak to work with GTK3 gtkdialog.
The portable (I tested just now) doesn't work with the trick that I described in the first post.
Could be that the John van Sickle ffmpeg doesn't support pipewire, don't know

I will do some more investigating in the next days for how to make wex work in e.g. Bookworm (running with pipewire)

[rockedge]

I wonder if updating the static FFMPEG in the WeX portable would be a factor?

[fredx181]

I wonder if updating the static FFMPEG in the WeX portable would be a factor?

Tried with the newest static from John van Sickle, same error:
(probably I will make a new wex-portable with the latest wex, but then without ffmpeg included, pity.)

Screenshot(2).png (102.46 KiB) Viewed 27848 times

[Clarity]

Since ffmpeg seemingly is ubiquitous across the Linux distro community, maybe moving to a non-static might be a reasonable step for both now and in the future for WEX.

[wiak]

Since ffmpeg seemingly is ubiquitous across the Linux distro community, maybe moving to a non-static might be a reasonable step for both now and in the future for WEX.

I'm not sure if wex is in current KLV-Airedale, but I think it used to be, and was in various WDL (pre-KL) Arch-based distros I made. In these distros it always simply used non-static normal ffmpeg install; that works fine as long as the ffmeg is not really ancient... I've always myself used wex in that way. Was a time in the past, however, when Puppy Linux had very old versions of ffmpeg that were no good for modern screencast/video encoding protocols; for that reason mikewalsh created a portable involving a static ffmpeg fredx181 had located somewhere, but I've never had a need for that. Wex itself is just a gtkdialog/bash relatively small script, whereas a portable variant is relatively large since has to include static ffmpeg and dependencies.

As for the future, unfortunately wex has no future as it currently stands since the screencapture is for distros using X and not Wayland; some very major work would be required on it if I hoped to make it work with Wayland too; for example, it uses scrotx (my fork of scrot) to find coordinates of the X display to define desktop area the user wants to capture - something similar would have to replace that for Wayland. For the moment though - with current non-wayland XFCE distros, for example, wex continues to provide a low resource audio/video/screencast capability. Actually, for a long time I've wanted to re-write parts of Wex such that it uses yad somehow instead of gtkdialog - most of the internal functions wouldn't need altered for that - just the GUI coding. If I ever do that I suppose I should check to see which functions currently rely on an X display and see if some Wayland-based equivalent could be easily/alternatively slotted in. All things are possible in coding of course, and the core capture code, which is the bulk of the program, certainly would not need to be changed.

It is not only wex that needs to be revised for wayland in this forum utility app world - all Take A Shot or screencapturing-type utilities need similar revision if to be useful with Wayland-based distros.