SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Trouble with sound. I can hear fine, but the microphone is AWOL. No recent changes, no disk crash, no obvious cause. I try to find what's going on and get this and get a pulse error. So I tried from runlevel 3
I did try pavucontrol. The "Input Devices" tab shows the mic volume set @100% and the 'Silence base,' which is background noise, is up at 85-90% by that scale. Zoom is not running. The recording tab shows nothing atm, but earlier (While I was on zoom) it showed a recording device at 0% and the silence base at 85-90%.If that level of "silence" was coming out, there'd be feedback levels of noise.
Also, alsamixer should run. rc.pulseaudio is not executable, and I don't have systemd. So when I boot to runlevel 3, pulse hasn't been run, and should start I have a 11 year old laptop with current on it, which boots to runlevel 4. But it sees 2 instances of the soundcard and configures the one that doesn't work :-/. I have to drop to a root terminal, and run alsamixer to select the right one from alsamixer and fix that.
[LATER] It seems alsamixer can be run as user on this box. On the laptop, I needed root, iirc. Also something from alsa-lib is linked into pulse, but that relationship ius unclear to me. Every time I go at sound, I come away feeling like Father Dougal (of "Father Ted" fame).
# ALSA system-wide config file
# By default, redirect to PulseAudio:
pcm.default pulse
ctl.default pulse
It's been like that for a long time:
Code:
Tue Feb 23 19:31:59 UTC 2016
l/alsa-lib-1.1.0-x86_64-3.txz: Rebuilt.
Changed the default /etc/asound.conf.new to use a different configuration
for PulseAudio that is less likely to cause issues than the previous one,
especially on machines where the analog output is not recognized as card 0
by the BIOS. Thanks to Ryan P.C. McQuen who went above and beyond on this
bug report by convincing upstream to recommend this on their website in
order to convince me to make the change. :-)
There's a few misunderstandings of pulseaudio in your posts which might help to clear up:
- Pulseaudio is NOT run as a system service at boot. Yes there is a 'rc.pulseaudio' script, but its not how pulseaudio should be used, nor is it set up with that script by default. Doing this would run pulseaudio as root, which is not how its intended to be used. I think you understand this, but I just wanted to re-iterate.
- Pulseaudio is intended to be run "per user"/"as the user", with user privileges. It gets started automatically via a number of routes, primarily through the /etc/asound.conf redirect that Petri mentioned, and also dbus activation. Basically whenever you play audio, access an audio device, or try to talk to the audio server with pactl/pacmd, you will automatically start pulseaudio up. On the virtual console ("init 3"), pulseaudio will also automatically terminate itself after a period of non-use (30 seconds, iirc). If you wait long enough, a pgrep will not report a pulseaudio process. In graphical sessions its kept alive longer.
- Switching to root and trying to use "alsamixer" wont work, since that attempts to autospawn a pulseaudio server "as root" now. Worse still, if you issue an 'su' command and not a proper login shell like 'su -l' or 'su -', then you inherit the users environment and XDG_* variables so connecting to pulse "as root" now tries to access/write to an XDG_RUNTIME_DIR that is not owned by root and more errors are thrown.
If you want to fiddle with pulseaudio on the terminal, stay as your regular user and learn to use 'pactl' and/or 'pacmd'. Otherwise 'pavucontrol' works pretty well in a graphical session. 'alsamixer' is just a basic plugin frontend to pulseaudio and provides simple controls. You might find your mic muted or turned down in there. Any adjustment made in alsamixer is exactly the same as making the adjustment in pavucontrol, though I find switching between audio cards and profiles like hdmi or analog simpler in pavucontrol imo.
Thank you guys for the replies and the pulse lessons which I as usual find distasteful.
I forgot about alsamixer, because as a faultfinding technique I was getting nowhere fast. This isn't m$ windows, so it's not ok for things that haven't been changed to change. So I tried to verify the microphone, and the results of my efforts were "maybe." I loaded my 'for emergency use' install, and the mike worked, then it didn't
So I'm marking this solved, to save people's efforts. If the mike turns out to be faultless, I can always row back on that. But my gut leans the other way. Either way I'll post once I'm definite. I'm physically limited fooling around with stuff now. So I play lazy.
Thank you guys for the replies and the pulse lessons which I as usual find distasteful.
Pulseaudio is designed to be run in a specific way, and usurps things like the alsamixer with its plugin when redirected. If you go outside of its design, it can break. These are facts on how it works. I'm just sharing what I know about it, having played around a fair bit with things like pulse/pipewire/jack/alsa on slackware with my audio hobbies. Dont shoot the messenger ;-)
When used properly, pulse works for most everyday audio use cases. Also many software packages now depend on it and need recompiling to remove it and go back to alsa only. Like it or not, its there by default.
While it mostly works for basic tasks, pulse still does things like mute your mic or audio output, and needs to be checked up on. This could be the case with your zoom program. Perhaps something is turned down, muted, or the input device is switched to something else in pulse. Those can be checked in the alsamixer (as user, since pulseaudio runs as user by default), or pavucontrol, if the session is graphical (really recommend the latter, since you're running zoom anyway). If you run pavucontrol, look at the input devices tab for you mic and its status there. Also will get a "recording tab" when an application is actively recording, and may have controls there. The configuration tab also switches devices you are using so make sure everything is in order there too, e.g. if you use a custom device, check there that its in use. There's not much else to pulse outside of those applications, except futzing with its config files or command line tools. I doubt that would come into play for running zoom, unless you've modified the default configs already.
There could be a number of other things too, depending on type of mic and what else is in the signal chain. Maybe try another mic if you have one to rule that out?
I dont use zoom but it'll probably have its own control panel with choice of devices there too if its anything like teams or discord.
Your hardware seems to be all detected so something in the software seems culpable. Pulse can get finicky with multiple audio devices and is worth a look. Good luck when you get to it!
Distribution: Slackware 64 -current multilib from AlienBob's LiveSlak MATE
Posts: 1,072
Rep:
Quote:
Originally Posted by 0XBF
I dont use zoom but it'll probably have its own control panel with choice of devices there too if its anything like teams or discord.
Zoom indeed has its own control panel for audio (and video). I have occasionally experienced that even if my headset is recognized by my laptop as the active in/output device, choosing "system audio" in zoom doesn't work - I have to specifically choose the particular device.
Well, my hardware experience tells me that 'maybe' = 'not working' in hardware devices. With things like microphones, a comparatively few strands of copper carry the signal. Give the lead a tug, and they may break, but not all at exactly the same place. The maybe effect.
So I bought another mike. It's a usb mike, the signal is weak and it gives zoom the heeby-jeebies in the configuration stuff but when configured, it works. It also had these coloured leds illuminating the thing, cycling through various colours.
My nerves aren't the better of configuring it, but it's working, so rule #1 applies
Code:
If it works, don't fix it!
@OXBF: I thought I was the only one who had pulse intermittently mute me for no good reason at all. Mind you, I've taken to leaving pavucontrol open on on one of the 4 screens in XFCE and I just head over there when the sound is dead.
Far more annoying imho is the habit of my RazPi 4 on a slackware port (Slarm64) where the sound is silent for some 3-5 seconds and then just suddenly comes on. It does it every time I play a video in VLC. I can back up 10 seconds and the sound works then. But how does one find a fault like that?
It's when you think you're clever that these things rise to the occasion and annoy you.
So I bought another mike. It's a usb mike, the signal is weak and it gives zoom the heeby-jeebies in the configuration stuff but when configured, it works. It also had these coloured leds illuminating the thing, cycling through various colours.
My nerves aren't the better of configuring it, but it's working, so rule #1 applies
Code:
If it works, don't fix it!
@OXBF: I thought I was the only one who had pulse intermittently mute me for no good reason at all. Mind you, I've taken to leaving pavucontrol open on on one of the 4 screens in XFCE and I just head over there when the sound is dead.
Far more annoying imho is the habit of my RazPi 4 on a slackware port (Slarm64) where the sound is silent for some 3-5 seconds and then just suddenly comes on. It does it every time I play a video in VLC. I can back up 10 seconds and the sound works then. But how does one find a fault like that?
It's when you think you're clever that these things rise to the occasion and annoy you.
I switched to a usb webcam/mic "clips-on-the-monitor" device a couple years ago which simplified my teams and discord use. I had tried running with the condenser mic/preamp/usb interface gear I already had, but the audio setup with multiple sound devices and streams gets too complex for pulse and it crashes and restarts, or things like teams can mess it up occasionally and find the wrong input device. I also lost audio completely in teams a couple times in middle of teaching a class with that early setup. Things went a lot smoother when I went with the simpler usb cam/mic option for those kinds of things. I still use the other gear with jack and qjackctl when I need it.
The time delayed startup of pulse you describe sounds like its taking a long time to spawn. Usually a display environment will spawn and keep pulseaudio running. If you are on some bare-bones setup, maybe pulse is "despawning" and then respawning once you start your video, leading to a delay in audio as pulse starts? You can run and daemonize pulseaudio manually with the '-D' option to leave it running all the time, if its despawning when you dont want it (or edit its config files). Then try running your video and see if the audio works from the start? This is all just a guess, since I dont know how that device is configured. In a stock display environment like kde or xfce on slackware 15.0, pulse should just be running by default though.
The time delayed startup of pulse you describe sounds like its taking a long time to spawn. Usually a display environment will spawn and keep pulseaudio running. If you are on some bare-bones setup, maybe pulse is "despawning" and then respawning once you start your video, leading to a delay in audio as pulse starts?
That's probably it. On Slackware, pulse is run as needed, so an instance starts every time. Even for a RazPi, though, that's slow. I'll try some other player. The video load may be temporarily peaking cpu load.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
