Xvidcap: audio recording wants /dev/dsp? How do we change this to work properly with ALSA?

[mikewalsh]

Evening, gang.

Now then; Uncle Mike would like some advice/assistance/suggestions with this one.....if it's at all possible.

I want to use my Logitech webcam as the audio recording device in Xvidcap, the long-established, rather 'quirky' screen capture app. One would think this would be relatively simple, but no; Xvidcap expects audio input via /dev/dsp. Although this exists in most Puppies, it's apparently a left-over from many moons ago, when OSS was being used by Sun SPARC workstations.....and is basically redundant nowadays.

Research suggests that alsa-oss needs installing but it must be installed already, since /dev/dsp won't show up without it. On top of this, I would like to set my webcam microphone card for default recording, while at the same time keeping the built-audio for default playback.....and I would like to do this using ALSA only. I don't want PulseAudio anyway near my Puppies, and no, I'm not interested in using JACK, either!

So; to summarise:-

• 1) How do we 'translate' /dev/dsp into its modern equivalent, in such a way that ALSA can make use of it?

• 2) How do I set different default cards for recording & playback? This is an issue with desktops, because unlike laptops, they don't have built-in mics that automatically get used as the default; you have to specify an input device, then you have to make it accessible, followed by then setting it as the default audio input device?

Can this be done.....or as I asking the impossible? ALSA is NOT one of my stronger points, especially when we start getting into construction of the various .conf files. Any & all input & sensible suggestions/advice would be appreciated, as always.

If I'm pissing in the wind I'd sooner find out first as last..!

TIA.

Mike.

[mikeslr]

Not an answer, but maybe a clue that might suggest an answer to someone who understands what it says: https://bbs.archlinux.org/viewtopic.php?id=99234. I'm just a kid who plays with blocks and sometimes looks up when adults mix familiar words with gibberish.

[fredx181]

audio recording wants /dev/dsp? How do we change this to work properly

Not sure if it helps, but there's also package "oss-compat" (anyway, on Debian), description:

Open Sound System (OSS) compatibility package

This package ensures that Open Sound System support is provided in
some way. On Linux, it enables the ALSA compatibility modules. On
other kernels where OSS is the default interface, no action is
taken.

The purpose of this package is for applications that only support OSS
to depend on it, hence preventing common "/dev/dsp not found" errors
that would confuse unexperienced users.

On Linux platforms a better approach nowadays is to use osspd, which
emulates OSS devices using ALSA or PulseAudio.

EDIT: Perhaps it works for you (it does for me) changing /dev/dsp to e.g. /dev/audio in xvidcap preferences

[mikewalsh]

Thanks for the replies, guys.

@mikeslr :-

That's one of several posts I unearthed on the Arch forum. Like the others, a lot of the stuff I'm interested in is mentioned, but from there on it was ALL "downhill"; I couldn't make head nor tail of those .conf readouts..!

@fredx181 :-

Mm. Actually, Fred, you may be onto something there.

If I look in /dev, I've got

• /dev/audio

• /dev/audio2, and

• /dev/audio3

I have a total of four audio devices on this rig. There's

• 1) The built-in Intel HDA

• 2) The Nvidia GPU's dual HDMI outputs (which I don't use, and which by all accounts are a complete PITA to set up anyway.....requiring certain kernel modules to be re-compiled against supplied Nvidia code. Not worth the hassle, TBH...)

• 3) My wireless full-cup headphones; the dongle's permanently plugged-in, and it contains its own sound card

• 4) The Logitech c920 webcam.

Now, technically, it's items 1-3 that are shown in the Multiple Sound Card Wizard.....because those three have playback capabilities. The webcam ONLY has sound input, i.e., stereo microphones. I'm guessing that's why it doesn't show up in MSCW, because it's NOT a playback device.....only a recording device.

Code: Select all

aplay -l

.....gives four items:-

Code: Select all

root# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC671 Analog [ALC671 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: WIRELESS [SOMIC STINCOO GS401 WIRELESS], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
root#

.....the built-in; TWO channels from the GPU, and the headphones.

Code: Select all

arecord -l

.....on the other hand, gives three items:-

Code: Select all

root# arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC671 Analog [ALC671 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 2: ALC671 Alt Analog [ALC671 Alt Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: WIRELESS [SOMIC STINCOO GS401 WIRELESS], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 3: C920 [HD Pro Webcam C920], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
root#

.....the built-in Intel HDA; the headphones (these have a plug-in boom mike, which you just connect when you want to use it), and.....the c920 webcam.

So; extrapolating this a bit further, I'm guessing that /dev/audio, /dev/audio2 and /dev/audio3 refer to the built-in, the GPU and the headphones respectively, yes? Taking this to the next logical step - bear with me, I'm thinking out loud here! - I back-tracked one level up, and had a look under /dev/input. There's a whole bunch of 'event##' files, three or four 'mouse##' files (I have three normal mouse dongles, plus a 'pen mouse' dongle - this latter for graphics - plugged-in all the time), and two directories; 'by-path', and 'by-id'. In /dev/input/by-id, the webcam is mentioned:-

Code: Select all

usb-046d_HD_Pro_Webcam_C920_CA9F729F-event-if00

.....and hovering over it, gives me a symlink to /dev/input/event28!

Question is, though, is this the audio input.....or the video input? I would imagine it to be the former, since I know the c920 always comes up as /dev/video0.....and although the c920 also gets a mention under /dev/snd, this appears to all be the control channels via the PCM module. There's only one mention here, which makes sense, since there's only a single mic level control in alsamixer. How's that for detective work, huh?

I'll give /dev/input/event28 a try for now, and see what happens.....although I'm guessing this will change from one boot to another, depending on the order in which devices get detected by the kernel when it fires up. I seriously doubt this will stay the same.

We'll see. I'll report back with my findings.

Mike.

[mikewalsh]

O-kay. Well, some positive results.

/dev/input/event28 doesn't do squat.

/dev/audio3, on the other hand, works beautifully; using the headphones' plug-in boom mike, it records sweet as a nut.

Couple of observations here, though! I think the webcam's mike isn't responding for the simple reason that I don't think you CAN activate the microphones independently of the camera. I suspect these two are wired-up to work in tandem; you use the one, you automatically get the other.

No biggie. It's the way it's designed to be used, after all.

.....and this leads me into the other "moan". The fact that the wireless headset's mike is working is great; trouble is, I can only get 5 minutes of recording out of it before the headset auto-powers off! (It only seems to detect activity through the ear-pieces; the microphone, apparently, doesn't count.....)

Bugger!

That's okay. I can use the older Logi H340 headset I previously used prior to purchasing these wireless ones (good thing I decided to hang onto these). It, too, has its own built-in audio card but, because it's wired, power is there all the time. No 'power-saving' gizmos built-in to spoil the fun!

I think we can call this one solved. Fred.....you're a star, buddy. Thanks for that suggestion.

Cheers!

Mike.

[Grey]

Research suggests that alsa-oss needs installing

It is not enough to just install alsa-oss. You also need to "poke a nose into it" of the program that should be launched.
For example, this is how I launch my favorite turn-based RPG strategy Gorky 18:

Code: Select all

LD_PRELOAD=/root/my-applications/lib/libaoss.so ./gorky18

or

Code: Select all

aoss ./gorky18

a. The path is like this, because I have a separate 32-bit version, so your path will be shorter.
b. This is for playback, but I don't know what about the recording.
c. Gorky 18 Men's Work is a version of the game for Russia with a different storyline. In the world, the names are different - Gorky 17 and Odium.
For me, this is the best game from Poland, better than The Witcher.