[Solved] Problems with libpulse without pulseaudio installed

Lone_Wolf · 2011-06-19 18:02:53

Recently i had sound problems, and found lines like :

pulseaudio : connection to server refused
pulseaudio : device not responding

Since Alsa works fine for me (and has done that on multiple systems for years) i do not have pulseaudio installed.

further investigation lead to the conclusion that phonon and /or fluidsynth were causing the problem.

Both are compiled on arch with pulseaudio support, and have libpulse as dependency.
I looked into their configuration options , and only found compiletime options to disable / enable which sound devices they support.
No runtime configuration options were available for that.

I used abs to build my own version where pulseaudio support is removed, but that means i now have to maintain those 2 packages myself.

If arch linux were to remove libpulse as dependency for phonon/ fluidsynth it will likely cause problems for people that DO use pulse audio.

Suggestions how to proceed so we all benefit ?

Last edited by Lone_Wolf (2011-06-23 23:54:33)

ngoonee · 2011-06-19 23:45:12

The libpulse dependency is not the problem, it (pulseaudio package) was specifically split to allow people the option of using non-pulse systems without having to have two copies of the major audio-producing apps/systems. Phonon can select backends, no idea about fluidsynth.

You should search the mailing list concerning libpulse, it was all explained there.

Lone_Wolf · 2011-06-20 00:24:20

Ngonee, it seems i have not been clear enough.

The archlinux phonon package builds phonon WITH pulseaudio support , and this has nothing to do with the backend selection.
In the advanced device list of phonon, there are pulse devices even though pulseaudio is NOT installed.

I will the search the mailing list when i have time, but atm this is the situation :
phonon requires libpulse
fluidsynth is a depency for vlc , and also requires libpulse

On my system the presence of libpulse and the attempted activation of non-existing devices belonging to pulse audio leads to errors.
it may very well be that this is not caused by libpulse, but by phonon and/or fluidsynth.
Since i have several applications that require kde parts, i can not remove phonon.

sand_man · 2011-06-20 00:48:08

Can you rebuild phonon without libpulse?

ngoonee · 2011-06-20 02:16:03

Lone_Wolf wrote:

Ngonee, it seems i have not been clear enough.
The archlinux phonon package builds phonon WITH pulseaudio support , and this has nothing to do with the backend selection.
In the advanced device list of phonon, there are pulse devices even though pulseaudio is NOT installed.
I will the search the mailing list when i have time, but atm this is the situation :
phonon requires libpulse
fluidsynth is a depency for vlc , and also requires libpulse
On my system the presence of libpulse and the attempted activation of non-existing devices belonging to pulse audio leads to errors.
it may very well be that this is not caused by libpulse, but by phonon and/or fluidsynth.
Since i have several applications that require kde parts, i can not remove phonon.

I myself do not use KDE, hence this was/is based merely on what I remember from the ML discussion. If phonon does not work on non-pulse systems then that's a bug and should go to the bug-tracker. Similarly for fluidsynth.

In this case, however, 'work' simply means that audio outputs fine to ALSA or whatever backend. If there are error messages even though things work fine then its just problematic upstream code. Similarly, if your concern is just that pulse devices appear (and things work fine otherwise) then its a pretty minor sacrifice IMO.

Lone_Wolf · 2011-06-20 10:05:43

I have checked the mailing list discussion, and it lookes like nobody else noticed the errors/ problems i get.

@sand_man : i have build both fluidsynth and phononh without pulse audio support, and the error messages + problems are now gone completely.
The KDE4 control module for phononh (kcm_phonon.so) however stopped working because of the missing libpulse files.
kcm_phonon.so is part of kdebase-runtime, which depends on kdelibs which depends on phonon .
Basically that means i have to rebuild both kdebase-runtime & kdelibs without pulse audio support .
If after that i find there are more kde packages that need to be rebuilded, it will get close to me building a custom KDE version.
That's not the path i want to take.

This problem makes me feel it will end up like this :

1. i create a bug report in flyspray
2. response will be something like : abs is your friend, build your own / upstream bug .
3. i register a bug with upstream, and get told that the solution is simple : convince my distro to build the package without pulse audio support
bugs closed, user stuck between Scylla and Charibdys .

Before i register anything, i need to be very sure where this error originates. Given that sound is used by many porgrams, it is possible that the error is not in phonon or fluidsynth, but in an app that uses their functionality.

There are several reasons why i started this thread :
- To inform others of the issue
- troubleshooting is in essence a trial and error procedure, but many people are bad at selecting the best steps to narrow down the problem.
I seem to be better at this then the majority, hopefully others will learn something from following this thread.

There are several combinations of fluidsynth & phonon that need to be tested :

00. fluidsynth without libpulse + phonon without libpulse

01 . fluidsynth without libpulse + phonon with libpulse

10 fluidsynth with libpulse + phonon without libpulse

11 fluidsynth with libpulse + phonon with libpulse

sofar combo 00 is known to give no problems, while 11 DOES.
This confirms that libpulse is part of the problem.

Next steps :
test combo 01 and combo 10.

Last edited by Lone_Wolf (2011-06-20 10:11:52)

Lone_Wolf · 2011-06-20 16:56:43

Update

Both combo 01 and 10 gave the problems and error messages, so i went to back to combo 11 : phonon and fluidsynth with libpulse.

What do phonon and fluidsynth have in common ?

there is a chain relation between them like this : Phonon >> phonon-backend = phonon-vlc >> vlc >> fluidsynth .
I tested VLC adio output settings, and found this :
if default and libpulse present : pulseaudio is default
libpulse not present : default seems to be Alsa

I set VLC to use alsa as standard output, and the audio stuttter was gone entirely.
I still got errors about pulseaudio : connection refused though.

I checked another application that i knew used phonon for audio output, and that also generated pulseaudio errors.

Next suspect : phonon-vlc
I could not find configuration options for phonon-vlc, so looked at the source-code.
I did notice that there was a test for pulsesupport, and if it was present at compiletime settings for pulseaudio were enabled.
Finally i had an explanation how those pulse devices ended in in the phonon configuration : the backend told phonon they existed !

I build phonon-vlc without pulseaudio support, this did get rid of the error messages and pulse devices.
Vlc apparently has it's own pulse audio detection, because it still wanted to use pulse audio by default.

While i do like VLC, my preferred phonon-backend has always been phonon-xine.

I switched to phonon-vlc for 2 reasons :
phonon-xine was deprecated
phonon-gstreamer had lots of gnome dependencies

I checked phonon-gstreamer, and found to my surprise the gnome-specific dependencies had been removed.
phonon-gstreamer is now installed, and i have no more pulse devices in my phonon configuration.

It looks like during troubleshooting this i have found an upstream bug in Vlc and phonon-vlc
Both check for the presence of libpulse to decide whether pulse audio support should be enabled.
This basically means they check for the client instead of the server.

This troubleshooting has cost me several hours, but the endresult is that i have found the cause of the problems and it can be solved with the archlinux standard packages.

ngoonee · 2011-06-21 02:44:49

Lone_Wolf wrote:

This troubleshooting has cost me several hours, but the endresult is that i have found the cause of the problems and it can be solved with the archlinux standard packages.

Bravo, job well done. A true demonstration of Arch DIY-ness

Have you tried other backends for phonon than vlc? I recall there were a few (xine, I think?). I personally use pulseaudio to keep things complicated *heh*, the amount of control you get is much more than with alsa.

Lone_Wolf · 2011-06-21 12:54:29

i'm now using the gstreamer backend.

I dislike the way pulseaudio's client - server model works :

add a virtual device to alsa that routes all audio to pulse server
clients call alsa pulse device
pulse server processes the output and sends it to alsa
alsa sends the audio to the physical device.
This complicates the flow and is prone to error, in my opinion pulseaudio is flawed by design.

Last edited by Lone_Wolf (2011-06-21 12:56:06)

triplesquarednine · 2011-06-21 17:19:49

Lone_Wolf wrote:

i'm now using the gstreamer backend.
I dislike the way pulseaudio's client - server model works :
add a virtual device to alsa that routes all audio to pulse server
clients call alsa pulse device
pulse server processes the output and sends it to alsa
alsa sends the audio to the physical device.
This complicates the flow and is prone to error, in my opinion pulseaudio is flawed by design.

that pretty much sums up how i feel about PA too. That is also why Wine-developers refused to add support upstream for PA (unless something has changed recently). They said on the wine-list that basically, PA is broken, it's not an audio driver, it's not a low-latency driver and therefore they won't support it directly.

It's also one of the reasons i am annoyed by some design choices in Gnome 3 - they made PA a static-dependency, meanwhile to me anyway, it hasn't proven itself to be worthwhile at all. - the only time i found it useful, was when i was experimenting with using jackd + skype (which when using PA, you can accomplish, but it's a dirty little hack! lol) I've seen so many people install gnome-shell and not even have sound - almost every time, it turns out to be PA that is screwing things up. Newbie's will then think gnu/linux sucks because their 'sound doesn't even work', meanwhile PA is the problem almost every time...

for me it also sucks, because i have to work around pulseaudio on a fresh install. -> good thing we use a rolling-release i disable it, change my configs to use alsa instead, have to remove it from auto-start (gnome-session-properties), then stop PA from auto-spawning, then i rename and/or delete /usr/bin/pulseaudio, and then add 'NoUpgrade' with /usr/bin/pulseaudio to pacman.conf (and also any other configs a PA update may try to change)..

i understand some of the technical reasons for developing it (limitations in ALSA), but maybe it should have been done under the 'ALSA-umbrella', as to not add confusion for the end-user and potential new developers for the platform... i

cheerz

ngoonee · 2011-06-21 22:49:45

Lone_Wolf wrote:

i'm now using the gstreamer backend.
I dislike the way pulseaudio's client - server model works :

Meat for one man poison for another, you know?

Lone_Wolf wrote:

add a virtual device to alsa that routes all audio to pulse server
clients call alsa pulse device
pulse server processes the output and sends it to alsa
alsa sends the audio to the physical device.
This complicates the flow and is prone to error, in my opinion pulseaudio is flawed by design.

The first 2 lines are for compatibility reasons. Much better than "none of your alsa apps will work anymore". Every audio system needs compatibility layers with others (see aoss for example). On my system I try to have as many apps as possible outputting to pulseaudio natively. This makes additional features (like tagging by role) possible.

And the basic confusion here is that alsa is not ONE system. There's kernel-space ALSA (soundcard drivers and all) and userspace ALSA, which communicates with the applications. If your app outputs directly to pulse, it replaces userspace ALSA, and latencies are low enough for most gaming even if using the alsa compatibility layer. For lower latency, see JACK.

And wine does have a pulse output patch, the wine devs won't add it in not because 'pulseaudio sucks' but because they're not planning to support it. I use wine-pulse with no problems.

triplesquarednine · 2011-06-22 03:21:18

ngoonee wrote:

And wine does have a pulse output patch, the wine devs won't add it in not because 'pulseaudio sucks' but because they're not planning to support it. I use wine-pulse with no problems.

if you are referring to my comment...?

i didn't say Wine-devs won't support it because 'pulseaudio sucks' - i said because PA is not a driver, nor does it provide low latency - so they will not support it 'directly'... (by directly, i implied NOT by upstream wine). but ya the patch is trivial to apply - i believe there is a PKGBUILD in AUR, right?

As far as low-latency goes, jackd is a low-latency driver (i'm a pro-audio person Mac/Linux and use jackd everyday in both OSes), but OSS and ALSA are in fact - 'lower' latency than PA... One of the key points in PA's design, aside from it's improved mixing capabilities, proxy, being cross-platform, and some other modern features (that ALSA user-space lacks)- is that it was to provide glitch-free audio, which translates into larger frame size, more time to buffer. (which makes sense).

when you factor in all of the compatibility layers with PA vs. ALSA... - PA will end up with frames being dropped left, right and center, under the same stress that ALSA handles, exceptably well... ALSA on the other hand, depending on hardware and configuration - can have a very small frame/buffer size. - much lower than PA can produce, as in - i don't see PA being able to go as low as 32 or 64 frames, which depending on hardware, system and your configuration ALSA can handle fine.

for reasons like this, Wine-Devs won't implement PA...

the trade off, of course, is that ALSA (user-space) doesn't provide some of the more advanced proxy/mixing stuff.

ngoonee · 2011-06-22 05:33:05

triplesquarednine wrote:

ngoonee wrote:
And wine does have a pulse output patch, the wine devs won't add it in not because 'pulseaudio sucks' but because they're not planning to support it. I use wine-pulse with no problems.
if you are referring to my comment...?
i didn't say Wine-devs won't support it because 'pulseaudio sucks' - i said because PA is not a driver, nor does it provide low latency - so they will not support it 'directly'... (by directly, i implied NOT by upstream wine). but ya the patch is trivial to apply - i believe there is a PKGBUILD in AUR, right?
As far as low-latency goes, jackd is a low-latency driver (i'm a pro-audio person Mac/Linux and use jackd everyday in both OSes), but OSS and ALSA are in fact - 'lower' latency than PA... One of the key points in PA's design, aside from it's improved mixing capabilities, proxy, being cross-platform, and some other modern features (that ALSA user-space lacks)- is that it was to provide glitch-free audio, which translates into larger frame size, more time to buffer. (which makes sense).
when you factor in all of the compatibility layers with PA vs. ALSA... - PA will end up with frames being dropped left, right and center, under the same stress that ALSA handles, exceptably well... ALSA on the other hand, depending on hardware and configuration - can have a very small frame/buffer size. - much lower than PA can produce, as in - i don't see PA being able to go as low as 32 or 64 frames, which depending on hardware, system and your configuration ALSA can handle fine.
for reasons like this, Wine-Devs won't implement PA...
the trade off, of course, is that ALSA (user-space) doesn't provide some of the more advanced proxy/mixing stuff.

The rest is basically okay, but the bolded sentence is just wrong. Jackd is not a driver, JACK is a sound server just like pulseaudio is, both use kernel-space ALSA to access the audio hardware. The difference is that JACK is specifically coded to be low-latency, while pulseaudio is not. Since wine comes with JACK output the argument that it won't add Pulseaudio output because its 'not a driver' doesn't make sense.

Also, it is possible to set PA to very low buffers, at the cost of CPU cycles and battery life. The primary reason PA defaults to large buffers is to save battery, as its also used on mobile phones for example (this also helps on laptops).

triplesquarednine · 2011-06-22 20:41:00

ngoonee wrote:

The rest is basically okay, but the bolded sentence is just wrong. Jackd is not a driver, JACK is a sound server just like pulseaudio is, both use kernel-space ALSA to access the audio hardware. The difference is that JACK is specifically coded to be low-latency, while pulseaudio is not. Since wine comes with JACK output the argument that it won't add Pulseaudio output because its 'not a driver' doesn't make sense.
Also, it is possible to set PA to very low buffers, at the cost of CPU cycles and battery life. The primary reason PA defaults to large buffers is to save battery, as its also used on mobile phones for example (this also helps on laptops).

yes, correct - i shouldn't have put driver behind Jackd, yes it is a sound server...

as for the 'not a driver' part (for PA) - that is what one of the wine developers said. maybe that was just a frazzled remark or something - but i got the impression of how he felt about PA, it goes something like 'not yet another Linux sound API to support, bah!'.... it was a discussion on the wine-list maybe a year to 2 years ago. Jackd is handy for Wine because it can be used as a drop in replacement for ASIO (wineASIO/fst).But, I actually haven't really found any real use for it other than that...

PA still cracks under the pressure of being run at lower latencies, quicker than ALSA seems to. I was playing around with this recently, when gnome 3 came through as an update, and all of a sudden i had a PA system running ..PA also has from my own experiences seems to suck up a fair bit of resources too. I would bet at those lower latencies it uses much more CPU than ALSA, being as low-latency isn't really apart of the design...I think it is definitely useful for some people, but i prefer to not have it running...

thanks ngoonee, for the correction and insightful info.

Last edited by triplesquarednine (2011-06-22 22:57:20)

ngoonee · 2011-06-22 23:02:24

PA will never use less resources than ALSA (neither will JACK, for that matter). You can reduce the resource usage by selecting a more efficient resampler, but if you have good ears you would probably be able to tell the difference (assuming you're using good headphones/buds/speakers). But seeing as you're not using it, then not an issue in any case. I've been following its development with interest since Ubuntu released it, and it really has the potential to take over all sound on Linux (sorry to other Unixes though).

OP - you should probably mark this thread as [solved]

Arch Linux

#1 2011-06-19 18:02:53

[Solved] Problems with libpulse without pulseaudio installed

#2 2011-06-19 23:45:12

Re: [Solved] Problems with libpulse without pulseaudio installed

#3 2011-06-20 00:24:20

Re: [Solved] Problems with libpulse without pulseaudio installed

#4 2011-06-20 00:48:08

Re: [Solved] Problems with libpulse without pulseaudio installed

#5 2011-06-20 02:16:03

Re: [Solved] Problems with libpulse without pulseaudio installed

#6 2011-06-20 10:05:43

Re: [Solved] Problems with libpulse without pulseaudio installed

#7 2011-06-20 16:56:43

Re: [Solved] Problems with libpulse without pulseaudio installed

#8 2011-06-21 02:44:49

Re: [Solved] Problems with libpulse without pulseaudio installed

#9 2011-06-21 12:54:29

Re: [Solved] Problems with libpulse without pulseaudio installed

#10 2011-06-21 17:19:49

Re: [Solved] Problems with libpulse without pulseaudio installed

#11 2011-06-21 22:49:45

Re: [Solved] Problems with libpulse without pulseaudio installed

#12 2011-06-22 03:21:18

Re: [Solved] Problems with libpulse without pulseaudio installed

#13 2011-06-22 05:33:05

Re: [Solved] Problems with libpulse without pulseaudio installed

#14 2011-06-22 20:41:00

Re: [Solved] Problems with libpulse without pulseaudio installed

#15 2011-06-22 23:02:24

Re: [Solved] Problems with libpulse without pulseaudio installed

Board footer