In about 5 minutes after installing latest -current update, I started to hate this new PulseAudio thing: my scripts for ACPI toggle-mute/volume-up/volume-down events (based on simple commands like "amixer set Master toggle" for muting/unmuting, and alike) aren't working any more, alsamixer seems completely unreliable now (sometimes it executes volume level change, sometimes it doesn't), then I really hate that Pulse spits .esd-* and pulse-* directories all over my /tmp directory, etc. Moreover, the documentation available on the net is very confusing, it seems like that users are expected to learn every single detail about sound server architecture in order to be able to do anything with this thing... So, is it possible to somehow disable it completely? If I understood properly what I was able to parse from the docs, it seems like it acts as a layer between apps and ALSA, so I hope that it's possible to disable it somehow. I tried with changing "autospawn=yes" to "autospawn=no" in the /etc/pulse/client.conf but that doesn't work, any other suggestions?

Thanks.

I'd assume you'd need to remove the lines in /etc/asound.conf that redirect audio sent to ALSA to Pulseaudio.

That was quick, many thanks! Indeed it seems that removing /etc/asound.conf, and then adding following two lines to /etc/pulse/client.conf:
would do in order to disable the damn thing.

9 members found this post helpful.

Fn+F8 and Fn+F9 doesn't work anymore to increase or decrease the sound volume (xfce).

I tried to rewrite /etc/asound.conf with alsa instead of pulse but clearly this does not work.

have you /etc/rc.d/rc.pulseaudio executable?

Also don't forget -Current is still in Beta status, and Pulse is new to the mix.

1 members found this post helpful.

In my blog article about -current and pulseaudio I pointed to this Arch Wiki article which shows how you can keep ALSA as the boss and allow pulse-enabled apps to fire up a pulseaudio server "on-demand" to pipe sound into ALSA:
https://wiki.archlinux.org/index.php...b_pipe_to_ALSA

6 members found this post helpful.

What's the point of this post, what makes you think that anyone here needs your reminders about such obvious facts?

Thanks Eric. You mention in your blog post that several other packages get recompiled against PulseAudio, but neither your blog post nor -current change log explicitly lists those packages. I guess one can find them by looking at binaries linked with PulseAudio libraries, but my questions here is: are there some packages that now use PulseAudio API directly and exclusively, instead of going through backwards-compatible ALSA API -> PulseAudio -> ALSA driver route?

First off turn down your tone a bit because clearly you're the one who failed to see an obvious fact. So pot meet kettle.

Not liking something that is in the testing stages is more or less a piss poor argument to make over an included package. You knew full well using -Current means things are going to not work correctly on any level and there's going to be issues until everything is finalized.

If you have problems with Pulse, ask about how you can fix it, tweak it, tune it, or disable it to use another service, but expect replies like mine when you use -Current because 5 minutes in isn't really saying much to hold water.

Above all else you can be respectful, even if you do not agree with what is said.

1 members found this post helpful.

Hopefully, all packages have been recompiled that optionally can be built against libpulse or where Slackware had to explicitly disable pulseaudio in the past to make the software compile. The intention is that all packages in Slackware use PulseAudio directly. If any package was overlooked, it's just that - overlooked - and should be reported to Pat.

Instead of configuring ALSA to use PulseAudio, I configured the opposite --
to make PulseAudio using ALSA/dmix instead of grabbing ALSA hardware device,
as it described on Archwiki:

• remove/disable asound.conf

• configured /etc/pulse/deafult.pa
  as:

Both, ALSA and PulseAudio applications work fine for me.

2 members found this post helpful.

Yes, that was what I also told a few posts back... only I posted the URL and not part of its contents. Good to have the module-alsa example lines here though, because that makes the LQ search find this thread in future.

I am wondering, if Pulse Audio is still nowadays resampling all audio data to a preferred output resolution?
That was one of my original issues with Pulse Audio, when I had to add it about two years ago. In the recent article on opensource.com, Chris Hermansen, still advises to get a second sound card just to bypass Pulse Audio via sending music directly to ALSA controlled card #2.

The KODI WIki has a section on resampling and PulseAudio and what your options are: http://kodi.wiki/view/PulseAudio#Audiophile_Pulse_User

4 members found this post helpful.