All, Slavek,
In 3.5.13-sru, the artsd process is continually taking between 8 and 11 percent 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?
On 08/08/2012 03:41 PM, David C. Rankin wrote:
All, Slavek,
In 3.5.13-sru, the artsd process is continually taking between 8 and 11 percent 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?
This may be normal, but when any sound event is triggered, I get the following in my ~/.xsession-errors file:
OggS-SEEK: at 0 want 89080 got 85568 (diff-requested 89080) OggS-SEEK: at 88640 want 520 got 0 (diff-requested -88120)
Does that make any sense?? After a few minutes, artsd does drop off to about 0.3% cpu which is what I normally expect to see, but I don't understand why it hovers around 10% after the sound finishes playing.
Let me know if you can think of anything, otherwise, I'll just keep an eye on it.
On 08/08/2012 03:49 PM, David C. Rankin wrote:
On 08/08/2012 03:41 PM, David C. Rankin wrote:
All, Slavek,
In 3.5.13-sru, the artsd process is continually taking between 8 and 11 percent 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?
This may be normal, but when any sound event is triggered, I get the following in my ~/.xsession-errors file:
OggS-SEEK: at 0 want 89080 got 85568 (diff-requested 89080) OggS-SEEK: at 88640 want 520 got 0 (diff-requested -88120)
Does that make any sense?? After a few minutes, artsd does drop off to about 0.3% cpu which is what I normally expect to see, but I don't understand why it hovers around 10% after the sound finishes playing.
Let me know if you can think of anything, otherwise, I'll just keep an eye on it.
I just timed how long artsd stays at 10% CPU after the last sound event. It is right at 60 sec. So arts is triggered, and for some reason it stays resident doing its job and doesn't unload for 60 secs or so.
Check your box with top running. Trigger a sound event. My artsd immediately jumps to 10% and stays for the timeout period, then drops back off to 0%. We have to be able to fix that. It should do its job and then drop off immediately rather than taking a minute to release the cpu. You have to have sound-events configured. I just use shade-up/shade-down with the middle-mouse. The cpu use is 100% repeatable on my install. No pulseaudio. What to check? Can I crank up logging somewhere to see what is going on?
On 08/08/2012 03:49 PM, David C. Rankin wrote:
On 08/08/2012 03:41 PM, David C. Rankin wrote:
All, Slavek,
In 3.5.13-sru, the artsd process is continually taking between 8 and 11 percent 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?
This may be normal, but when any sound event is triggered, I get the following in my ~/.xsession-errors file:
OggS-SEEK: at 0 want 89080 got 85568 (diff-requested 89080) OggS-SEEK: at 88640 want 520 got 0 (diff-requested -88120)
Does that make any sense?? After a few minutes, artsd does drop off to about 0.3% cpu which is what I normally expect to see, but I don't understand why it hovers around 10% after the sound finishes playing.
Let me know if you can think of anything, otherwise, I'll just keep an eye on it.
I just timed how long artsd stays at 10% CPU after the last sound event. It is right at 60 sec. So arts is triggered, and for some reason it stays resident doing its job and doesn't unload for 60 secs or so.
Check your box with top running. Trigger a sound event. My artsd immediately jumps to 10% and stays for the timeout period, then drops back off to 0%. We have to be able to fix that. It should do its job and then drop off immediately rather than taking a minute to release the cpu. You have to have sound-events configured. I just use shade-up/shade-down with the middle-mouse. The cpu use is 100% repeatable on my install. No pulseaudio. What to check? Can I crank up logging somewhere to see what is going on?
-- David C. Rankin, J.D.,P.E.
Arts actually stays loaded on purpose, to minimize startup-related latency on the next sound event. There is a configuration option in kcontrol to set the unload delay IIRC.
Tim
On 08/08/2012 04:56 PM, Timothy Pearson wrote:
Arts actually stays loaded on purpose, to minimize startup-related latency on the next sound event. There is a configuration option in kcontrol to set the unload delay IIRC.
Tim
Thanks Tim,
I'll check. I'm just glad to be able to play 2 sound events without the second getting lost... I'll report back.
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 11 percent 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 --
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 11 percent 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
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 11 percent 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
Do you have PulseAudio installed?
Tim
Le 08/08/2012 23:29, Timothy Pearson a écrit :
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 and11 percent 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
Do you have PulseAudio installed?
Tim
Right, by disabling pulseaudio, arts is much more responsive :-) Alas, I need pulseaudio so I cannot leave it disabled.
BTW, I think that this lag is very huge ! I can understand that having several chained sound servers may cause a little delay, but here, we're talking about 2 seconds !
Francois
Le 08/08/2012 23:29, Timothy Pearson a écrit :
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 8and 11 percent 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
Do you have PulseAudio installed?
Tim
Right, by disabling pulseaudio, arts is much more responsive :-) Alas, I need pulseaudio so I cannot leave it disabled.
BTW, I think that this lag is very huge ! I can understand that having several chained sound servers may cause a little delay, but here, we're talking about 2 seconds !
Francois
This is a known PulseAudio problem not caused by TDE or aRts; as far as I know it affects people randomly based on the exact hardware and client software in use.
Tim
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 11 percent 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.
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
-
David C. Rankin -
Francois Andriot -
François ANDRIOT
-
Slávek Banko -
Timothy Pearson