Le 08/08/2012 23:48, David C. Rankin a écrit :
On 08/08/2012 04:26 PM, Francois Andriot wrote:
Le 08/08/2012 22:53, Slávek Banko a écrit :
On Wednesday 08 of August 2012 22:41:00 David C. Rankin wrote:
All, Slavek,
In 3.5.13-sru, the artsd process is continually taking between 8 and 11percent of the CPU. That is high compared to my other installs of 14.0. Is anybody else seeing this? The sound is working though, so I'm pleased there. (that has always been hit or miss) What to check to see why artsd is so greedy?
David,
I have artsd at 0% CPU, continually :) I use Amarok and it plays directly to alsa. However, through arts go all other sounds from TDE.
Slavek
Hello, my artsd is always at ~0% even when playing sound.
But I have a different problem: all the TDE sounds are delayed from about ~2sec, which is very very noticeable. Sounds play smoothly (no stutter), but they start playing long after the corresponding action has been done. Any clue on this ?
Francois
Yes,
I see this all the time in my Arch installs, it is due to pulseaudio on my box. I have seen some improvement by moving all of the pulseaudio* files out of /etc/xdg/autostart. This is not a complete solution. OpenSuSE has done a good job integrating atrtd with pulseaudio. I do not notice near the delay on suse that I do on Arch. I think Ilya (or somebody) must patch the pulseaudio-kde file to work better with kde3. I suspect the native pulseaudio-kde file is for kde4 only.
I have noticed much better sound performance from 3.5.13-sru on my virtualbox installs. On that install Arch Linux guest in virtualbox, sound is perfect. There is only
libpulse 2.1-1 alsa-lib 1.0.25
That is the way to run. You can check if pulse is running with 'ps ax | grep pulse' On most installs, I see:
16:41 providence:~> ps ax | grep pulse 1874 ? S<l 0:00 /usr/bin/pulseaudio --start --log-target=syslog 1886 ? S 0:00 /usr/lib/pulse/gconf-helper
On those installs, I see exactly what you describe. Sound works, but is delayed by a second or two, but otherwise plays. However, if you try to play 2 sound files close together (shade-up/shade-down) then then second sound file does not play. It was explained to me that both arts and pulse are attempting to control the same hardware and end up in conflict that causes the delay.
This needs to be fixed by some smart person because if you have gnome + tde installed you are going to have pulseaudio on the system. We need to figure out how to work with it rather than just saying 'uninstall pulse'. suse does it. I have pulseaudio running on my laptop with kde3 and sound is much less delayed than on Arch. Maybe suse lowers a timeout threshold or something like that.
If you just have tde installed, then I think the correct answer is to remove pulse. If you have other desktops that need pulse, then I think we need to figure out how to configure pulse so it works well with arts.
There is useful info on the Arch wiki about pulse and its config:
https://wiki.archlinux.org/index.php/PulseAudio
I have worked through it, but there is a LOT of information on pulse referenced from external sites that also needs to be digested to understand how pulse works.
Thank you, configuring arts as described in the Arch wiki (using ESD compatibility from pulseaudio) has reduced the lag a lot ! It is still not perfect, but much better !
Francois