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.
recent updates to Slackware-current merged-in pulseaudio ecosystem.
I can understand rationales mentioned in Changelog, but ALSA did worked well for me (incl. HDMI output) and refuse to configure & run pulseaudio server as another layer on top of it, just for the sake of read & control mixer settings like volume level or simple playing of a sound file.
Current build of alsa-utils package refuses to work without pulseaudio server running, like alsamixer or aplay utilities. Is the package just misconfigured or is it not possible compile it with pulseaudio as an optional (runtime) plugin only and keep previous functionality ?
Current build of alsa-utils package refuses to work without pulseaudio server running, like alsamixer or aplay utilities.
You must be doing something wrong. alsa-mixer works without pulseaudio running. Either move /etc/asound.conf out of the way (assuming it is redirecting to pulseaudio), or explicitly pick your card - eg 'alsamixer --card=0'
Changing the type to hw is not a good idea as you'll bypass the alsa 'dmix' and you'll be back to only playing one thing at once. Just comment out the asound.conf, and let alsa use its defaults.
Changing type from pulse to hw and adding card <index> in /etc/asound.conf did the job.
Just hate to fix things that reliably have worked for a decade, after any update.
EDIT: Mere removal of /etc/asound.conf is not a good idea, as any other upgrade will put it back.
Good point about moving /etc/asound.conf. However, if you had no asound.conf before you should be able just to touch an empty one with nothing in it.
Your only problem is if a particular program you want to use doesn't allow you to pick the audio output and it chooses pulseaudio by itself. skype is one example, but that requires pulseaudio anyway, and does not work with just alsa. Apart from these, it is up to you whether you set asound.conf to redirect from libasound to pulseaudio.
Changing the type to hw is not a good idea as you'll bypass the alsa 'dmix' and you'll be back to only playing one thing at once. Just comment out the asound.conf, and let alsa use its defaults.
Right. This was a quickfix to get some sound without pulseaudio started.
I could set type to plug and slave.pcm to dmix or left blank/commented out as you suggest.
Good point about moving /etc/asound.conf. However, if you had no asound.conf before you should be able just to touch an empty one with nothing in it.
Your only problem is if a particular program you want to use doesn't allow you to pick the audio output and it chooses pulseaudio by itself. skype is one example, but that requires pulseaudio anyway, and does not work with just alsa. Apart from these, it is up to you whether you set asound.conf to redirect from libasound to pulseaudio.
I'm aware of that and hopefully don't need use such software. So far.
As this is a breaking change, there should be a mention about that in 14.2 release info and possibly also a comment in /etc/asound.conf how revert to previous behavior.
Or, as someone already pointed out, continue using ALSA directly by default without configuration/maintenance changes and spawn Pulse server on-demand for apps with hardcoded pulseaudio backend (Bluez, Skype, KDE?). Solution described on ArchWiki find more sane and working. Is there some issue at doing it this, less obtrusive way ?
As this is a breaking change, there should be a mention about that in 14.2 release info and possibly also a comment in /etc/asound.conf how revert to previous behavior.
Or, as someone already pointed out, continue using ALSA directly by default without configuration/maintenance changes and spawn Pulse server on-demand for apps with hardcoded pulseaudio backend (Bluez, Skype, KDE?). Solution described on ArchWiki find more sane and working. Is there some issue at doing it this, less obtrusive way ?
I don't think it is a breaking change. If you have a special reason to use only alsa then you should know how to set up your asound.conf file: asound.conf is not for the faint hearted or casual user, irrespective of whether you are using pulseaudio or not - you need to know what you are doing if you are going to play with it. I do forward to pulseaudio with some applications such as mplayer, just not (by default) with all. For most people, pulseaudio is fine, and indeed better for those who don't know or are not interested in how to set up their audio and who just want it to work.
I don't think it is a breaking change. If you have a special reason to use only alsa then you should know how to set up your asound.conf file: asound.conf is not for the faint hearted or casual user, irrespective of whether you are using pulseaudio or not - you need to know what you are doing if you are going to play with it. I do forward to pulseaudio with some applications such as mplayer, just not (by default) with all. For most people, pulseaudio is fine, and indeed better for those who don't know or are not interested in how to set up their audio and who just want it to work.
This is a breaking change, as noted by several users here on the forum. Everywhere alsa-util binaries are used, like changing sound volume with amixer, playing system sounds with aplay, use of alsamixer GUI etc. stopped work, unless anew, pulseaudio server gets started. Appropriate rc script has no executable flags on by default so it won't "magically" start working, besides the change.
Not everybody uses fat desktop environments, where audio is handled with API calls.
Btw. it is also quite confusing and ridiculous at the same time, alsa-utils Advanced Linux Sound Architecture utilities can't work directly with core Advanced Linux Sound Architecture by default, but suddenly need some extra higher layer infrastructure called Pulseaudio.
This is breaking change, as noted by several users here on the forum. Everywhere alsa-util binaries are used, like changing sound volume with amixer, playing system sounds with aplay, use of alsamixer GUI etc. stopped work, unless anew, pulseaudio server gets started. Appropriate rc script has no executable flags on by default so it won't "magically" start working, besides the change.
Not everybody uses fat desktop environments, where audio is handled with API calls.
Btw. it is also quite confusing and ridiculous at the same time, alsa-utils Advanced Linux Sound Architecture utilities can't work directly with core Advanced Linux Sound Architecture by default, but suddenly need some extra higher layer infrastructure called Pulseaudio.
Sorry, you are just misinformed. Your original point was that many of the alsa-utils binaries would not work without the pulseaudio server running, which was wrong. Furthermore, if you are not redirecting to pulseaudio in asound.conf then it is irrelevant whether or not pulseaudio is running or not running with respect to alsa-utils, as alsa-utils would indeed "work directly with core Advanced Linux Sound Architecture" as you put it.
And you can use alsamixer or aplay even if you are redirecting to pulseaudio. You are wrong about that.
If your reference to a "rc script" is to rc.pulseaudio, you are wrong about that too, and this is explained in the rc.pulseaudio script. In almost all cases it should be left non-executable so that pulseaudio runs as a user process. It will start automatically as a user process when needed if you leave the default settings.
Leaving aside the hot air, what do you claim actually used to work before and now no longer does work? We don't need any more second rate rants about pulseaudio,
Sorry, you are just misinformed. Your original point was that many of the alsa-utils binaries would not work without the pulseaudio server running, which was wrong. Furthermore, if you are not redirecting to pulseaudio in asound.conf then it is irrelevant whether or not pulseaudio is running or not running with respect to alsa-utils, as alsa-utils would indeed "work directly with core Advanced Linux Sound Architecture" as you put it.
And you can use alsamixer or aplay even if you are redirecting to pulseaudio. You are wrong about that.
Don't misinterpret what has been said, it leads nowhere.
Also don't try make yourself smarter, then you really are …
I have said alsa-utils binaries won't run by default without pulseaudio server running. Ie. with newly introduced configuration settings presented by /etc/asound.conf (#9). As you may read in this thread, I'm already aware how to revert to original behavior. Nothing about it wouldn't work at all.
The point is, for users who rely on alsa-utils, like mixer settings without GUI for window managers (i3, fvwm) without full-fledged DE, it suddenly stopped working. Entry in changelog didn't helped what has to be done to keep existing behavior.
Quote:
Originally Posted by chrisVV
If your reference to a "rc script" is to rc.pulseaudio, you are wrong about that too, and this is explained in the rc.pulseaudio script. In almost all cases it should be left non-executable so that pulseaudio runs as a user process. It will start automatically as a user process when needed if you leave the default settings.
Leaving aside the hot air, what do you claim actually used to work before and now no longer does work? We don't need any more second rate rants about pulseaudio,
This is just a humble opinion or a belief ?
In the latest up-to-date Slackware64-current, /etc/asound.conf contains following options:
Code:
pcm.!default {
type pulse
hint.description "Default Audio Device"
}
ctl.!default {
type pulse
}
Installed related packages like pulseaudio-7.1-x86_64-1, alsa-lib-1.1.0-x86_64-2, alsa-oss-1.0.28-x86_64-1, alsa-plugins-1.1.0-x86_64-1, alsa-utils-1.1.0-x86_64-2.
D-Bus is running:
Code:
/etc/rc.d/rc.messagebus status
System dbus-daemon is running.
Now, any attempt use binaries from alsa-utils package fails:
How can you explain this behavior ? There was no user process of pulseaudio server automatically launched. Even adding user to pulseaudio group doesn't help. Only manual start of pulseaudio server or alter configuration to a different backend like hw or plug.
How can you explain this behavior ? There was no user process of pulseaudio server automatically launched. Even adding user to pulseaudio group doesn't help. Only manual start of pulseaudio server or alter configuration to a different backend like hw or plug.
I can't explain that behavior. All of those things work fine here with rc.pulseaudio non-executable.
All of your system setup and examples look correct. Any unhandled .new files hanging around in /etc? Also, is this a mostly unmodified version of -current? No system packages replaced from other repos, etc.
One thing you never do is set pulse audio as default in the latest pulse audio unless your going to set a default device in you /etc/pulse/default.pa
things have really changed since 5.0. if you do not want pulse audio the uninstall it and recompile kmix and install it. your back to what we had before.
after you do the delete your .config/pulse and .config/pavucontrol.ini
now that is the only difference.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.