Take a Cast !

[fredx181]

Update: 2025-03-22, version 2.0 now, attachment below, see info: viewtopic.php?p=145228#p145228

Another Screencaster app.
Take a Cast ! is modified from "Take a Gif !" viewtopic.php?t=6914, which in turn is modified from "Take a Shot" by JakeSFR .
(it's a rather simple program, e.g. container will be mkv (so output is e.g. Screencast.mkv) and a few quality options (Low, Medium, High) for video processing)

Requirement: ffmpeg installed.

For recording the audio, the program detects if plain ALSA is used by the system (e.g. on FossaPup), then the GUI looks like this (has option to select soundcard number):
(if recording from 'Soundcard' is selected (rather than 'Microphone'), this will make use of created ~/.asoundrc as presented by @jamesbond here: viewtopic.php?p=59099#p59099
edit; if recording audio from microphone, enable 'Capture' and set the volume for that and for Microphone in alsamixer .

2025-03-14_17-08-50.png (90.89 KiB) Viewed 1455 times

If pulseaudio or pipewire is detected to be used by the system (e.g. on BookwormPup), then the GUI will look like this:

2025-03-14_17-11-25.png (67.63 KiB) Viewed 1455 times

Installation;
EDIT: 2025-03-22, Updated to version 2.0, see changes info: viewtopic.php?p=145228#p145228

• takeacast2.0-portable_noarch.tar.xz , extract on a Linux formatted filesystem (not FAT or NTFS), can be used as a 'roxapp' or go inside takeacast2.0 directory and run 'AppRun' or 'LAUNCH'.
  edit: this setup should work on 32-bit and on 64-bit

  takeacast2.0-portable_noarch.tar.xz

  Extract in a 'Linux' filesystem (not FAT32 or NTFS)

  (117.55 KiB) Downloaded 8 times

- tkacast-portable.gz, a portable appimage (64-bit), remove fake .gz extension and make executable
edit: removed the appimage, only the above portable from folder available now.

edit: see here: viewtopic.php?p=145228#p145228 for a pet package (64-bit) EDIT: version 2.0 now with a bug fix and other changes.

Must say that I just tested on my laptop, with only one soundcard available, so feedback highly appreciated if it doesn't work as expected .
edit: now more tested on Desktop computer by @mikewalsh

[bugnaw333]

Works on EasyOS...

[Jasper]

Works great using FossaPup64-95

Made a PET file for the application. Found a royalty free icon which I was going to substitute with your existing one.

Contents.png (52.61 KiB) Viewed 1280 times

So, can you tell me why this will not work?

[fredx181]

Works great using FossaPup64-95

Made a PET file for the application.

The pet is wrong constructed, won't work as expected, please remove attachment, it should be "AppRun" (not included in the pet, btw) that the .desktop launcher points to.
(so must keep the "portable" construction)

[Jasper]

@fredx181

My pet file does work and is tested on my OS.

Can you explain to me why it should not work?

[fredx181]

@fredx181

My pet file does work and is tested on my OS.

Can you explain to me why it should not work?

I tested on BookwormPup64 and found that selecting "Region" didn't work, perhaps you didn't try that option yet ? (depends on working scrox64, see below)
About the construction, in fact the only thing 'wrong' was usr/lib64 in your pet (I noticed that "scrox64" couldn't find the dependent lib "libgiblib.so.1" if in usr/lib64).
Also... libgiblib.so.1 wasn't a symlink in your package (just a file) and scrox64 was not set as executable (perhaps something went wrong for you when copying these files )
In the portable setup that I made (takeacast.tar.gz), the script AppRun has the LD_LIBRARY_PATH set and the PATH too (made to work on 32-bit and 64-bit).
Here's pet package (for 64-bit) similar as yours that should work (contains usr/lib rather than usr/lib64 and fixed what I mentioned above).

EDIT: 2025-03-22, version 2.0, see for changes info and new pet package here: viewtopic.php?p=145228#p145228

@mikewalsh Thanks! Just some criticism though, sorry.
Just a minor thing perhaps, you called it "noarch" but it isn't because the tkacast-portable appimage is 64-bit.
Other thing, on itself setting HOME to HERE is nice, but when recording with option "Soundcard" on a system with plain ALSA , audio recording won't work.
That's because on your setup the custom made .asoundrc will be created (temporary) in the HERE directory and Alsa doesn't read it, only reads from ~/.asoundrc (/root/.asoundrc).

[Jasper]

@fredx181

I did make the scrox64 file executable, as I noticed this when I tried to run the application initially from the portable.

I record my desktop and it worked fine for me.

Thank you for the explanation

Your updated file, does indeed include the 'region' option which is now visible with a thin white border.

**NB

Just realised that my sound (ALSA) is altered and cannot hear audio outside of the application. Uninstalling the application returns ALSA to normal.

[fredx181]

@fredx181
...
Your updated file, does indeed include the 'region' option which is now visible with a thin white border.

I'd call it a 'stippled border' if "Show Region" is checked.

2025-03-15_16-38-34.png (343.34 KiB) Viewed 1201 times

There may be a dark side-effect when a compositor is enabled, so to just disable compositing then will fix it.

2025-03-15_16-36-44.png (69.13 KiB) Viewed 1201 times

[mikewalsh]

@fredx181 :-

Yah, all valid points, Fred. I don't know how I missed the 'portable's' arch; I usually check stuff like that. Oh, I know what I must have done; I'd downloaded both portable AND tarball, spotted the 32-bit & 64-bit stuff and assumed both were built the same way. We ALL know what they say about "assuming", don't we?

I fired-up the portable, realised it was one of your home-grown AppImages, went "Yay!", threw the ROX-app together and published it. I'd only tested it in 'no-audio' mode, too....

I doubt it would have recorded audio anyway. Not for me...

=====================================

D'you remember back to the Alsa Cap GUI app you created? This thread spawned it, I believe:-

viewtopic.php?t=6083

.....started by @number77 .You got involved; Bill got involved; Jamesbond got involved, indirectly....several Puppians got interested in the 'issue'. I mentioned during the thread that I also had the same issue; basically, in my case, the 'loopback' function on this HP desktop rig's sound card is REALLY peculiar.....it'll say it's working, but it isn't. Even under Windows, I found out, HP had had to write some special script to handle it which fires-up at boot.

The kernel 'snd-aloop' module was employed; some very clever scripting was produced, and at the end of it, I could finally record internal audio. Basically, I have a permanent 'asoundrc' file in /root these days. If 'Take a Cast' is creating one, it would muck my own up, so.....not good.

====================================

I'll withdraw the portable, Fred. No point publishing summat that don't work......and I have no wish to detract from the excellence of your own efforts. At the end of the day, I really ought to know better than to "gatecrash" somebody else's thread....

Sorry about that.

Mike.

EDIT:- My previous post has now been deleted, since it was hasty and ill-considered. Apologies all round.

[fredx181]

@mikewalsh

...
I doubt it would have recorded audio anyway. Not for me...

=====================================

D'you remember back to the Alsa Cap GUI app you created? This thread spawned it, I believe:-

viewtopic.php?t=6083

.....started by @number77 .You got involved; Bill got involved; Jamesbond got involved, indirectly....several Puppians got interested in the 'issue'. I mentioned during the thread that I also had the same issue; basically, in my case, the 'loopback' function on this HP desktop rig's sound card is REALLY peculiar.....it'll say it's working, but it isn't. Even under Windows, I found out, HP had had to write some special script to handle it which fires-up at boot.

The kernel 'snd-aloop' module was employed; some very clever scripting was produced, and at the end of it, I could finally record internal audio. Basically, I have a permanent 'asoundrc' file in /root these days. If 'Take a Cast' is creating one, it would muck my own up, so.....not good.

Note that 'Take a Cast' will create a ~/.asoundrc only temporary (while recording), it will reset to the original (if exist) after recording stopped. (for alsa-capture goes the same, btw).
But that 'resetting' can go wrong in some circumstance perhaps, if so, I will look into that.
(advantage of pulse/pipewire is that it works without the need to mess with a config file such as ~/.asoundrc)

edit: In case that internal audio recording doesn't work for you, I would like to know why so I can possibly fix it. Can you try and tell me what happens?

[mikewalsh]

@fredx181 :-

Hi, Fred.

Right; let me clarify things a bit - if I can.

Firstly; so far as Take A Cast is concerned, for me the internal sound card is completely irrelevant. Let me explain.

When I do screen-captures, if I employ audio, I only want a voice-over. I don't want background music, or owt like that.....just the spoken word. Now; I don't have a single microphone ANYWHERE that plugs into the internal card's audio jacks. Every one of MY 'capture' devices - that has a microphone - is a USB device. And every one of these has its own, built-in sound card, which makes selection and set-up a doddle.

The cards are all pretty spartan as far as controls go; just a slider for output, and one for input. That's it. Basic as hell, ultra-simple, and dead reliable. To paraphrase, they "just work". To use a head-set, say, I plug it in; wait a few seconds to allow the kernel to detect & configure it.....then I fire up Take A Cast. I'm ALSA all the way here, so I select the card to use, choose Microphone for input, and set the ball rolling. And.....it just works, Fred. As it should. Brilliant!

I guess that for those who use laptops all the time, where audio/video is all integrated (built-in webcam, built-in microphone, built-in speakers, etc), it takes a bit of head-scratching to understand why those of us with desktops seem to have more issues with this kind of stuff. But you think about it:-

~ If I want sound on a desktop rig, I have buy speakers and add them myself ~
~ If I want a webcam on a desktop rig, I have to buy one and add it myself ~
~ If I want a microphone on a desktop rig - for audio input - I have to buy one and add it myself ~

...etc, etc. See where I'm coming from?

Yah, it makes the system more versatile - you can add precisely what you want, and you're not stuck with what the manufacturer has chosen to install - but it DOES introduce the opportunity for a lot of misconfiguration if you're not savvy about this stuff.

As TAC comes, OOTB, it's almost perfect. Almost...

=============================

My webcam is a Logitech c920, and this thing comes with stereo mikes. Input quality is very good, so I sometimes prefer to use the webcam for input rather than a headset. This is where the issue arises. Although ALSA detects it - and configures/sets it up accordingly - for whatever reason, Puppy simply doesn't "see" it. Never has done, TBH.

TAC's drop-down gives me:-

- The internal sound card
- The motherboard 'beep' speaker
- Any headset I have plugged in

Apart from the mobo speaker, everything else is input AND output. The webcam, however, is input only. I had a scan through the script, and saw you'd used "aplay -l" for detection. That's for playback devices. So I changed that to "arecord -l" to see if that would make a difference. It didn't......which didn't really surprise me.

- The internal card is card 0.
- The mobo speaker is card 2.
- Any headset I connect will show as card 3.

These are the only ones shown in the drop-down box.

The webcam is always card 5. In between the webcam and the headset, I have the snd-aloop module's output (all 16 channels of it!) showing at card 4. I'm wondering if all those virtual loopback channels are interfering with detection of the webcam's sound card. What d'you think? Because this leads me to another question....

In the alsa-capture script Bill developed, it 'modprobes' for snd-aloop. This being the case, do I really need to have 'snd-aloop' permanently loaded? Can I unload it.....and if I do, will the alsa-capture script still work?

======================================

Really, for MY use-case, all I need is a way to manually add the webcam's card5 as a selection. I already do this with several other Puppy/mainstream apps, and it always works perfectly......but the drop-down box you've used here won't ALLOW manual addition. (Does gtk-dialog HAVE different types of combobox?) Aside from this, you can feel pleased with yourself, Fred.....'cos this thing works very well indeed. Thanks!

Can ya follow all that? If you need further clarification, just ask.

Mike.

[fredx181]

@mikewalsh
Thanks Mike for the explanation.
I understand most of what you're saying and I'm limited in being able to test TAC with different hardware (e.g. similar as yours) now I only tested on my laptop.
So only if I could test TAC myself on such a setup (using Desktop computer) I could possibly try to improve things.

The webcam is always card 5. In between the webcam and the headset, I have the snd-aloop module's output (all 16 channels of it!) showing at card 4. I'm wondering if all those virtual loopback channels are interfering with detection of the webcam's sound card. What d'you think? Because this leads me to another question....

In the alsa-capture script Bill developed, it 'modprobes' for snd-aloop. This being the case, do I really need to have 'snd-aloop' permanently loaded? Can I unload it.....and if I do, will the alsa-capture script still work?

You can unload it with modprobe -r snd-aloop it doesn't need to be constantly loaded, only when you start recording with alsa-capture, snd-aloop will be 'modprobed' again (done from the alsa-capture script. edit: same with TAC, btw).
edit: about interfering, can't be sure, but I don't think so.

[mikewalsh]

@fredx181 :-

Nah, no worries Fred. I'll probably use the headset most of the time for doing tutorials, etc, I think.....and that DOES work fine with TAC. I'm good with the .mkv container, 'cos that's high on Google's list of acceptable formats for YT.

Thanks for the info about modprobe snd-aloop. I'll unload it via the boot manager, then test the portable I built around Bill's script. Like you, I'm guessing it should still work, since the script modprobes for snd-aloop anyway. We'll see.

It's a lovely piece of work, Fred. Well done.....and thank you. Oh, and BTW; re your comment about how the .asoundrc file should be in /root? Believe it or not, using XDG to set it to the portable's "$HERE", it STILL seems to work. Surprised me, too!

EDIT:- Later...

OK, that's fair enough. I unloaded snd-aloop via the Boot Manager, and re-booted. All those virtual loopback channels are gone, and the output of arecord -l is now a LOT tidier.

SimpleAudioRecorder - utilising my slightly modified version of Bill's alsa-capture script - still records perfectly, because the script modprobes for 'snd-aloop' before running the recording command. I suspected it would still work OK.

Still no sign of the webcam in the drop-down, but that's pretty much as expected... (*shrug...*) Can't have everything!

Mike.

[fredx181]

@mikewalsh

Oh, and BTW; re your comment about how the .asoundrc file should be in /root? Believe it or not, using XDG to set it to the portable's "$HERE", it STILL seems to work. Surprised me, too!

Ok, that's nice, then your alternate portable setup could be ok, I guess, how you used XDG then ? And was there no existing .asoundrc in /root for you ?
edit: and you recorded 'internal' audio (what-u-hear) ?

[mikewalsh]

@fredx181 :-

@mikewalsh

Oh, and BTW; re your comment about how the .asoundrc file should be in /root? Believe it or not, using XDG to set it to the portable's "$HERE", it STILL seems to work. Surprised me, too!

Ok, that's nice, then your alternate portable setup could be ok, I guess, how you used XDG then ? And was there no existing .asoundrc in /root for you ?
edit: and you recorded 'internal' audio (what-u-hear) ?

Ah. Okay. I think I'm getting hold of the wrong end of the stick here, Fred.

So; the 'Soundcard' option is JUST for the internal card.....yes? In that case, no; I haven't......because I never record from the internal card. Whatever I record with, it's always a USB device of some kind.

I DO have an .asoundrc file in /root, yes. It's put there by Vokoscreen. Not because I use PulseAudio - I don't! - but I think it's because Vokoscreen is set-up to use PA by default. It's popular with many users of mainstream distros.....and they've all been using PA by default for a LONG time.

There's not much to it:-

Code: Select all

# create by vokoscreen 1.9.0

pcm.pulse {
  type pulse
}

ctl.pulse {
  type pulse
}

Bill's alsa-capture has a modified copy of .asoundrc in the package, which is temporarily copied into place while it "does its thing".....and the old one is then put back when you shut it down.

It's quite possible you're right about it then. I won't argue the point, since it sounds like I haven't actually used it as intended.

=====================================

Another bit of news for you. I've fixed the main script so's it will finally let me use my webcam. (Yay!!)

In the main tkacast script, lines 300-316 (the audio card detection stuff, yes?)

I did a bit of research earlier on today, and ended up reading zigbert's gtk-dialog documentation over at Github. Following this - and cross-referencing it with some stuff on YAD, 'cos a lot of things look to be 'shared' between them? - I made a small change in the above-mentioned section.

Your original looks like this:-

Code: Select all

CARDL=""
while read C; do CARDL=$CARDL"<item>$C</item>"
done <<< "$(aplay -l | grep "^card" | grep "device 0" | grep -v "Loopback")"
if [ "$(aplay -l | grep -Fo "$CARD")" ]; then CARDL="<item>"$CARD"</item>"$CARDL; fi

#PPULSE=yes
if [ "$PPULSE" = "" ]; then # plain alsa, option to select sound card
DEVICE='<text space-expand="true" space-fill="true" visible="true"><label>"Detected plain ALSA as soundsystem"</label></text>
<frame Set Audio Capture device:>
	<hbox>
     <comboboxtext width-request="510">
       <variable>CARD</variable>
       '$CARDL'
     </comboboxtext>
      </hbox>
  </frame>

while my small modification looks like this:-

Code: Select all

CARDL=""
while read C; do CARDL=$CARDL"<item>$C</item>"
done <<< "$(aplay -l | grep "^card" | grep "device 0" | grep -v "Loopback")"
if [ "$(aplay -l | grep -Fo "$CARD")" ]; then CARDL="<item>"$CARD"</item>"$CARDL; fi

#PPULSE=yes
if [ "$PPULSE" = "" ]; then # plain alsa, option to select sound card
DEVICE='<text space-expand="true" space-fill="true" visible="true"><label>"Detected plain ALSA as soundsystem"</label></text>
<frame Set Audio Capture device:>
	<hbox>
     <comboboxentry width-request="510">
       <variable>CARD</variable>
       '$CARDL'
     </comboboxentry>
      </hbox>
  </frame>

HINT:- Look at the "combobox" tags. See it?

What 'comboboxentry' gives me is this (using Take A Gif! to demonstrate Take A Cast! ):-

[Click to enlarge:-]

You still get the drop-down.....but you also initially get a blank field where you can type/paste your own entry. Okay, it's not how I would LIKE for it to work, but it does allow me to put the webcam's card in (which Puppy appears to ignore).

And it works nicely. Having done that, I then re-packed "tkacast-portable" using your scripts (and the AppRun from the original package). Runs beautifully.

Mike.

[fredx181]

@mikewalsh

Another bit of news for you. I've fixed the main script so's it will finally let me use my webcam. (Yay!!)
....
You still get the drop-down.....but you also initially get a blank field where you can type/paste your own entry. Okay, it's not how I would LIKE for it to work, but it does allow me to put the webcam's card in (which Puppy appears to ignore).

And it works nicely. Having done that, I then re-packed "tkacast-portable" using your scripts (and the AppRun from the original package). Runs beautifully.

Now... how about that for a workaround! Very creative. I didn't know btw that you can paste something in a combobox blank field .

Yes, the custom $HOME/.asoundrc is only created (temporary) with option Soundcard AFAIK.

[mikewalsh]

@fredx181 / all :-

Okay; here we are again. The 'portable', 'no-arch' package of Take A Cast! is now using the ROX-app as opposed to the tkacast-portable binary AppImage. Fred was quite right about the AppImage being 64-bit, since it was clearly built with the '64-bit' scripts under a 64-bit OS......and rt-clk -> Properties says 'ELF 64-bit LSB executable'!

The ROX-app, on the other hand, includes both 32- and 64-bit binaries for scrox and 32- and 64-bit libs, with the AppRun script set to auto-detect which are required. So, that makes this the better choice for a 'no-arch' package....

Config stuff is created within the directory via the XDG protocol. If an existing .asoundrc file is found in /root, it's moved into /tmp, and the 'internal' .asoundrc is linked into /root for the duration. At close of the app, the original is reinstated into /root again.

Tested this afternoon under both 32- AND 64-bit Puppies. Works perfectly in both scenarios.

If anybody's interested in this, I've attached it to the bottom of this post. EDIT - temporarily withdrawn, pending "improvements".

As always with these portables:-

• Download

• Unzip

• Move it anywhere you want; preferably outside the 'save', of course, and

• .....because it's a ROX-app, a click on the directory is all that's needed to launch it!

The usual MenuAdd/MenuRemove scripts are included as always, should a Menu entry be desired.

Hope it's useful for some of you. Enjoy Fred's amazing work in a 'portable' format. DON'T FORGET.....ffmpeg needs to be 'on the system' for this to work.

Mike.

[mikeslr]

Thanks, Mike. Seems to work fine once I figured out how to both record and listen to sound on my system. Annoying systerm. My microphone is connected via USB and for some reason my system thinks that it's the default for recording and listening . Decided to record a Youtube of Blood, Sweat & Tears. Accessed via firefox. So I had to start the Youtube and change firefox's sound preferences to 'Built-in Audio'. Then, even though "Sound Card" had been selected in the TAC's GUI, I had to again configure Pulse-Audio via the Recording Tab to 'Built-in Audio'. Lastly, to actually hear what's recorded I had to again select 'Built-in Audio' in the Playback Section for MPV.

And along the way remember that the little box at the Top Left of my screen was how to stop recording. To quote Danny Glover, "I'm getting too old for this".

But at least it circumvents Google's insistence that you can't record Youtubes.

And thanks again, fred, for doing most of the necessary coding.

[fredx181]

@mikewalsh Does recording internal audio (with "Soundcard" option) work for you with your new portable setup ?
It does not work for me with a bare ALSA soundsystem (without pulse or pipewire).
(I think such a setup (by moving .asoundrc) as you did in LAUNCH won't work, perhaps it's possible when done similar from the tkacast script itself but will be complex, I guess)

edit: to explain a bit: the .asoundrc with the "Loopback" config will be created just after clicking 'Take a Cast!' button in the GUI, your setup expects that it's already there before running tkacast.

[fredx181]

Thanks, Mike. Seems to work fine once I figured out how to both record and listen to sound on my system. Annoying systerm. My microphone is connected via USB and for some reason my system thinks that it's the default for recording and listening . Decided to record a Youtube of Blood, Sweat & Tears. Accessed via firefox. So I had to start the Youtube and change firefox's sound preferences to 'Built-in Audio'. Then, even though "Sound Card" had been selected in the TAC's GUI, I had to again configure Pulse-Audio via the Recording Tab to 'Built-in Audio'. Lastly, to actually hear what's recorded I had to again select 'Built-in Audio' in the Playback Section for MPV.

And along the way remember that the little box at the Top Left of my screen was how to stop recording. To quote Danny Glover, "I'm getting too old for this".

But at least it circumvents Google's insistence that you can't record Youtubes.

And thanks again, fred, for doing most of the necessary coding.

I wonder why you had this trouble with the "Sound Card" option, can you post the output of pactl list short sources ?
edit: and, which puppy you use ?

[mikewalsh]

@fredx181 :-

Mm. Right, right; makes sense. I haven't recorded anything from the internal card myself; as I said, I don't even have any kind of microphone that would plug into the audio jacks anyway, so that bit I CAN'T test. Remember; this is NOT a laptop, so nothing is actually "builtin" as it is with those.

So; what I need then is a way to be able to keep the .take_a_cast.rc file within the portable (if you don't then it's not really 'portable', is it?)......but allow .asoundrc to be created as & when in /root. Sounds like a candidate for the older "symlinking gymnastics" (as MochiMoppel called it), which I wanted to get away from. But if that's the best way for this particular set-up, that's what I'll have to do, I guess.

Does the 'tkacast' script move any existing .asoundrc file out of the way first, and then replace it again afterwards? I just wonder if I should leave that bit in place.....

Thoughts?

EDIT - Have withdrawn the above package until we've got it right. Check your inbox....

Mike.

[fredx181]

Mike and I are contemplating about a new portable version May take some time.
Meanwhile I found a bug;
In case plain ALSA used and the "Soundcard" option selected, resetting /root/.asoundrc doesn't always work, (i.e. when closing the GUI by clicking [X] it will go wrong) (it goes fine when clicking the button "Take a Cast!" though).
So... work in progress, will get back with a fixed version later.

[fredx181]

Take a Cast version 2.0

Changes:

• bug fixed for 'resetting' ~/.asoundrc after recording from 'Soundcard' with plain ALSA soundsystem (see more info at above post)
• truly portable (config file in 'LAUNCHDIR')
• info message just before actually start recording is more clear
• possibly will detect more soundcards (e.g. webcam etc..), if there are in reality (in case running with plain ALSA soundsystem)

The 'portable' is now a combination of my first (v1.0) initial setup and Mike's portable setup style , and thanks to @mikewalsh for helping !

Download v2.0 attachment, takeacast2.0-portable_noarch.tar.xz at FirstPost

New v2.0 .pet package for 64-bit, attachment (not portable, config will be in /root):

tkacast-2.0-amd64.pet

Updated .pet package to v2.0

(43.77 KiB) Downloaded 18 times

[mikewalsh]

@fredx181 :-

Lovely piece of work, Fred, as always. We eventually figured out a way to get my webcam showing as an audio input; the ridiculous thing was that we had to first send the arecord -l output to a /tmp file, THEN read it into the command. Piping the output direct, it simply didn't "see" it...

We got there in the end. Hopefully, as Fred says, the same trick that's worked for me should work for anybody else that wants to make use of a USB webcam's microphone. If it's there, you should be able to use it like you would any other microphone; and ALSA will certainly "see" it, even if Puppy (for whatever reason) - doesn't.

Thoroughly recommended. Has Mike's "seal of approval". Nice one!

Mike.

[greengeek]

I am trialling the .pet version on my Fossa64 9.5 setup but cannot get sound to record.

Should this soundcard selection field be adjustable?

TAK_SoundcardChoice.jpg (8.15 KiB) Viewed 265 times

.
It offers no selections other than what is shown, and does not allow me to change from card 0 to card 1.

I had a look at .take_a_cast.rc but there did not seem to be any entry there for me to change.

Also - I tried using the Alsa sound wizard to select card 1 device 0 and that selects correctly as the new default - but it still did not allow TAK to record sound.

Any thoughts for things I can try?

Code: Select all

root# arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: MID [HDA Intel MID], device 0: ALC268 Analog [ALC268 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 1: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
root# 

[fredx181]

I am trialling the .pet version on my Fossa64 9.5 setup but cannot get sound to record.

Should this soundcard selection field be adjustable?
TAK_SoundcardChoice.jpg
.
It offers no selections other than what is shown, and does not allow me to change from card 0 to card 1.

I had a look at .take_a_cast.rc but there did not seem to be any entry there for me to change.

Also - I tried using the Alsa sound wizard to select card 1 device 0 and that selects correctly as the new default - but it still did not allow TAK to record sound.

Are you trying to record audio from Micropone or from Soundcard (what-you-hear) ?
If you select Microphone, you may need to enable "Capture" first (and set the volume level) in alsamixer (or retrovol, see pic) and probably also set the volume level for Mic (or called perhaps 'internal'.

It offers no selections other than what is shown, and does not allow me to change from card 0 to card 1

.
It looks like that you only have one "real" soundcard (card 0). Loopback is filtered out on purpose (so for you it should be card 0 to record from).
The "Loopback" is created by "modprobe snd-aloop" (from the script), it's only for when using "Soundcard" to be able to hear the sound that you record.
edit: For adjusting volume for Mic, to show VU meter (after settings in alsamixer or retrovol made): arecord -V stereo -f S16_LE >/dev/null

Screenshot(6).png (29.83 KiB) Viewed 221 times

[mikewalsh]

@greengeek :-

Ian, what's your output from

Code: Select all

arecord -l

...please? This'll let us see what cards you DO have on the system.

BTW: What should "card 1" be on your system? What would you expect it to be showing as..?

Mike.

[fredx181]

@greengeek :-

Ian, what's your output from

Code: Select all

arecord -l

Ian showed that already in his post .

[mikewalsh]

@fredx181 :-

@greengeek :-

Ian, what's your output from

Code: Select all

arecord -l

Ian showed that already in his post .

Whoops. My bad...

Quite right, quite right; so he did. So far as I'm aware, you can't actually "set" loopback as an input, can you? AFAIK, it can only be "called" - or used - from a script of some kind, so yes; in Ian's case, there would only be the one card showing.

In my case, I have three. There's the main internal card. There's the headset's 'boom' microphone......and there's also the stereo mikes built-in to the c920. For all intents & purposes, these latter count as a single input.

Mike.

[greengeek]

Are you trying to record audio from Micropone or from Soundcard (what-you-hear) ?

I am selecting Soundcard. My intention is twofold:
1) Record what I am watching/hearing in my browser
2) Record what I can hear through the speakers when I am playing a CD

It looks like that you only have one "real" soundcard (card 0). Loopback is filtered out on purpose (so for you it should be card 0 to record from).
The "Loopback" is created by "modprobe snd-aloop" (from the script), it's only for when using "Soundcard" to be able to hear the sound that you record.

For some reason the Alsa sound card wizard sees the following (Loopback only visible after loading your pet):

AlsaDefaultWizard.png (22.71 KiB) Viewed 150 times

.
I am wondering if my problem is caused by me not correctly understanding this coaching:

SoundcardMethod.png (14.26 KiB) Viewed 150 times

.
Obviously the order of events is significant. Should the application be running first?
eg:
- Application running before loading pet?
- Load pet, then start application?
- Load pet, start application, start recording, then restart application??

Maybe my application cannot see the new asound.conf because TAK has not loaded it yet?

I feel as if I am getting the timing wrong.