Sure they do. The CPU load of resampling causes the XRUNs you are complaining about, I have experienced that many times.
Instead of Ubuntu, try Lubuntu, they pulled Pulse audio out. There's a version called Lubuntu lxle that they have based on the LTS release of Ubuntu. The base Lubuntu is quite basic, but lxle is nicely featured and quite complete from a desktop application perspective. Using LXDE vs Gnome(or Unity or whatever they are calling it) improves performance on older machines....
I tried Lubuntu, Kubuntu, Xubuntu, Studio, Mint, Fedora, Arch, Gentoo .....
.... to realize, that the best bet -- for my purposes -- is a basic Ubuntu along with some rather minor modifications.
What counts first of all is size in terms of market share and related to size community support.
Derivates usually fall short on support, features and show integration
issues. You'll end up spending more time on hacking then using the
system.
I have Saucy installed now and I'm quite happy.
I'm getting used to Rythmbox with the all its plugins - the cover art browser in particular. It's not perfect, but it works.
I'm running speex-5 now with pulseaudio.
I can even run Windows apps like DBpoweramp and Office with Wine1.6 nowadays.
SMPlayer is my video player of choice btw.
I use ARCH-Arm on my RPi network player btw.
Cheers
Yep. You said it.
Where do you put the LD_PRELOAD entry to have it applied at system start ??
I did not, just tested running pulseaudio from command line. I guess it will be on each distribution different. Just search where pulseaudio server is called on your machine - either at startup scripts for system-wide or autostart when user-based. On my home mate mint it was I think in pulseaudio-kde script.
I am talking to Rob, the author of libsoxr, about the clicks. He is very helpful.
I am talking to Rob, the author of libsoxr, about the clicks. He is very helpful.
I'm trying for a while to figure out how this pulseaudio gets started.
Not any Wiki seems to be up2date.
Autostart:
/etc/xdg/autostart/pulseaudio-kde.desktop or
/etc/xdg/autostart/pulseaudio.desktop
These files call
/usr/bin/start-pulseaudio-[kde||X11]
which just seem to load some PA modules.
However. By running pactl PA seems to be started automatically.
That might explain why taking PA out of "autostart" won't stop it from autostart at boot.
Then there are SysVinit AND Upstart PA startscripts at /etc/init.d and /etc/init.
But these seem to sit idle. And will only by used if PA is uses as system wide daemon.
Currently the daemon will be started on per user basis, with the particular user ID and permission.
That's why PAM needs to be set up properly for your user to allow realtime prio and nice adjustments.
It's still not working in my case.
??? I'm kind of lost.
Last edited:
Just figured that pulseaudio respawns several times during boot/login.
And every time it restarts it uses a different daemon.conf and client.conf config file.
I figured that out by defining a different logfile in each of the config files.
Interesting to see is that timidity's starting up PA twice.
What a jungle.
I then removed Timidity.
Guess what:
Now the lightdm login manager starts a session first, probably to be able to issue the login sound. Weired.
And every time it restarts it uses a different daemon.conf and client.conf config file.
I figured that out by defining a different logfile in each of the config files.
Interesting to see is that timidity's starting up PA twice.
What a jungle.
I then removed Timidity.
Guess what:
Code:
-rw------- 1 lightdm lightdm 71262 Sep 25 17:16 pa-client-etc.log
-rw------- 1 klaus klaus 63239 Sep 25 17:16 pa-client-home.log
-rw------- 1 lightdm lightdm 0 Sep 25 17:15 pa-daemon-etc.log
-rw------- 1 klaus klaus 0 Sep 25 17:16 pa-daemon-home.logNow the lightdm login manager starts a session first, probably to be able to issue the login sound. Weired.
Last edited:
Weired. Maybe not!?!?
Let's try to get the logic right:
There are certain system related sounds or services that require a PA instance running -- before a user logs in.
First it was Timidity, now it's lightdm, since Timidity was removed.
These services are using the generic config files under /etc/pulse and apply their own user id and permissions.
As soon as the user logs in PA needs to be restarted to load the user specific parameters and modules.
At this point PA is issuing pactl commands to load the X11 related PA modules. These pactl commands are executed by the startup script "start-pulseaudio-x11" which gets triggered from "Startup-Applications. pactl restarts automatically the daemon. Restart, because some user specific parameters have to be changed.
At this point user specfic settings will be applyied.
Another finding is that the client.conf overrules the daemon.conf settings.
Hmmh. That's exhausting. That's Linux.
Let's try to get the logic right:
There are certain system related sounds or services that require a PA instance running -- before a user logs in.
First it was Timidity, now it's lightdm, since Timidity was removed.
These services are using the generic config files under /etc/pulse and apply their own user id and permissions.
As soon as the user logs in PA needs to be restarted to load the user specific parameters and modules.
At this point PA is issuing pactl commands to load the X11 related PA modules. These pactl commands are executed by the startup script "start-pulseaudio-x11" which gets triggered from "Startup-Applications. pactl restarts automatically the daemon. Restart, because some user specific parameters have to be changed.
At this point user specfic settings will be applyied.
Another finding is that the client.conf overrules the daemon.conf settings.
Hmmh. That's exhausting. That's Linux.
Last edited:
Been there done that.
IMO the best way to get rid of PA is to avoid it. Otherwise you might end up with a broken system. "Avoid IT" means, better to look for a system that avoids PA.
That's why I use ARCH on my audio only machine.
If you go roughly 4-5 years back on this thread you should find comments confirming your findings related to PA and Alsa.
48khz. Yes that's what I said some posts ago. That's why I wanted to go higher. Many of the soundcards resample to 192khz anyhow. My idea was to go that high to avoid data getting resampled twice.
But even at a redicolous rate of 96khz -- with the high quality resampling codec in place -- the system stalled respectively, shows a pretty high load.
Run a HD movie and you'll go through the roof.
Since most of the audio data around is 44.1khz, IMO the best setting would be to go for 44.1khz. As far as I can see PA avoids resampling, if the in/out samplerates are matching. That's what I figured, when looking at the CPU load while playing 96khz material and the PA resampler set to 96khz.
Pavel came up with the suggestion to use libsoxr, a highly efficient sox library for resampling. libsoxr is also used with squeezelite btw.
Now the question is how to get PA started, with that library linked in.
I tried a wrapper script yesterday. That's what phofman also suggested later on.
It didn't work. PA figured that out and wouldn't allow it.
I also tried to add
Code:
; autospawn = yes
daemon-binary = LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libsoxr-lsr.so.0 /usr/bin/pulseaudio
; daemon-binary = /usr/bin/pulseaudio
extra-arguments = --log-target=file:/tmp/pa-client-home.log --log-level=4to ~/.config/pulse/client.conf
That didn't seem to make any difference.
Cheers
Last edited:
phofman
I tried to run the LD_PRELOAD tweak manually @ 96khz best-sinc resampling:
Have a look at my top output:
and that is the result after the tweak
It doesn't seem to work on my machine.
I tried to run the LD_PRELOAD tweak manually @ 96khz best-sinc resampling:
Have a look at my top output:
Code:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4772 klaus 8 -12 339m 137m 134m S 38,4 1,7 1:56.24 pulseaudio
3477 klaus 20 0 3058m 229m 42m S 6,4 2,9 1:06.47 rhythmbox
4479 klaus 20 0 616m 19m 12m S 6,4 0,2 0:01.86 gnome-terminal
1 root 20 0 27336 3076 1424 S 0,0 0,0 0:00.72 init
2 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kthreaddand that is the result after the tweak
Code:
k@1:~$ pulseaudio -k
k@1:~$ pp
k@1:~$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libsoxr-lsr.so.0 /usr/bin/pulseaudio -D
k@1:~$ pp
klaus 5052 2731 1 12:03 ? 00:00:00 /usr/bin/pulseaudio --start --log-target=file:/tmp/pa-client-home.log --log-level=4It doesn't seem to work on my machine.
Hm, works fine for me. See updated Pulseaudio with LD_PRELOADing libsoxr-lsr | Blog IVITERA a.s.
It does not work since the daemon-binary path is not invoked via shell but directly by execv pulseaudio/pulseaudio - PulseAudio Sound Server
Pavel.
You made it.
You should talk to the pulseaudio folks. With libsoxr and best-sinc it's less load then the speex resampler.
There is no impact to the Window mananger at all anymore. That's a serious performance and quality
improvement on pulseaudio.
Great stuff.
I can't try 384khz.
PA seems to be limited to 192khz.
THX a lot.
You made it.
Code:
k@1:/usr/bin$ pulseaudio --dump-conf
### Read from configuration file: /home/klaus/.config/pulse//daemon.conf ###
...
...
resample-method = src-sinc-best-quality
enable-remixing = yes
enable-lfe-remixing = no
default-sample-format = s32le
default-sample-rate = 192000
....
Code:
k@1:/usr/bin$ cat /proc/asound/card0/stream0
TEAC Corporation TEAC UD-501 at usb-0000:00:1a.0-1.3, high speed : USB Audio
Playback:
Status: Running
Interface = 1
Altset = 1
Packet Size = 247
Momentary freq = 192002 Hz (0x18.0010)
Feedback Format = 16.16
Interface 1
Code:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1721 klaus 8 -12 363m 136m 133m S 3,0 1,7 0:12.53 pulseaudio
2105 klaus 20 0 2940m 210m 42m S 2,0 2,7 0:30.48 rhythmboxYou should talk to the pulseaudio folks. With libsoxr and best-sinc it's less load then the speex resampler.
There is no impact to the Window mananger at all anymore. That's a serious performance and quality
improvement on pulseaudio.
Great stuff.
I can't try 384khz.
PA seems to be limited to 192khz.THX a lot.
Last edited:
Klaus, I am glad you like it. I think it will be a big step forward, for both pulseaudio and alsa rate plugin (i.e. dmix).
Rob of libsoxr is diagnosing the problem with initial clicks. After it is cleared out, we can talk to alsa and pulseaudio guys.
I did not discover how pulseaudio is started in x-session either. There is probably some hard-coded config in /usr/... The actual principle is not that complicated, it is started by xsession, just the actual place where pulseaudio gets called is not easy to find by searching /etc nor /usr/share. Unfortunately this is the trend of last years towards more "dumb user friendly" desktop. The same will happen with init scripts when distributions move over to systemd.
Rob of libsoxr is diagnosing the problem with initial clicks. After it is cleared out, we can talk to alsa and pulseaudio guys.
I did not discover how pulseaudio is started in x-session either. There is probably some hard-coded config in /usr/... The actual principle is not that complicated, it is started by xsession, just the actual place where pulseaudio gets called is not easy to find by searching /etc nor /usr/share. Unfortunately this is the trend of last years towards more "dumb user friendly" desktop. The same will happen with init scripts when distributions move over to systemd.
I read that "pactl" (called inside the X11 start script) automatically starts a PA instance. That instance gets tight to the actual user calling it.
That's why it uses the user specific config files and not the global config files. That'll happen as soon as you login.
BTW.
I just turned off debug level logging of PA. That brings PA CPU load down to 1.3% @ 192khz instead of 3.0 as mentioned in last post.
That's why it uses the user specific config files and not the global config files. That'll happen as soon as you login.
BTW.
I just turned off debug level logging of PA. That brings PA CPU load down to 1.3% @ 192khz instead of 3.0 as mentioned in last post.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.