Re: [gentoo-user] aRts sound server on KDE 3.5.2?
Hi Michael,I give oss-emulation backend a try in arts configuration and it really works for me (now I can run noatun again), but you said u're using xine-backend as amarok engine without arts. Well, I did tried to use gstreammer with amarok but there's a problem with the gst mad library (a friend using ubuntu has the same problem) so I give a try to xine but anytime when I try to choose xine as the engine amarok give me the follow message: xine was unable to initialize any audio-drivers. Could you please give me a advice about this setup? I can't wait to get back using amarok :)tks,On 4/19/06, Michael Schreckenbauer [EMAIL PROTECTED] wrote:Am Mittwoch, 19. April 2006 22:12 schrieb Michael B. Trausch: I am wondering if anybody here has run into a problem using aRts 3.5.2 with KDE 3.5.2 on ~x86.I know that ~x86 is technically unsupported, so I'm just looking to see if anybody else might be experencing problems with this setup or would know how to go about attempting to troubleshoot it.It dies claiming CPU overload after anywhere from fifteen seconds to thirty minutes of trying to grab all of the CPU's attention, and does not output any sound.I have this and similar issues with arts every now and then. Some versionswork quite well for me using the alsa-backend, other versions only work, whenI use the oss backend via the oss-emulation of alsa. So I would try the different backends, maybe that helps. I don't use arts anymore, amarok worksfine with the xine-backend and xine works pretty good with alsa. Thanks in advance for any help, Mike Regards,Michael--gentoo-user@gentoo.org mailing list-- Claudinei Matos [EMAIL PROTECTED]55-21-81980605
[gentoo-user] aRts sound server on KDE 3.5.2?
I am wondering if anybody here has run into a problem using aRts 3.5.2 with KDE 3.5.2 on ~x86. I know that ~x86 is technically unsupported, so I'm just looking to see if anybody else might be experencing problems with this setup or would know how to go about attempting to troubleshoot it. It dies claiming CPU overload after anywhere from fifteen seconds to thirty minutes of trying to grab all of the CPU's attention, and does not output any sound. Unlike information I've found from Google wherein it would only affect a single particular user account or non-privileged users, this affects all users on the system, including root, and the problem persists across reboots. This has me believing that it is a problem somewhere in the configuration, as I've re-emerged both arts and kdemultimedia-arts, to no avail. And I know next to nothing about aRts, so I can't determine how to track the bug down to file a report. The only thing I do know is that it has something to do with a broken pipe. strace shows this, over and over again (about 20-30 times per second, until artsd dies): ioctl(9, 0x4140, 0) = 0 ioctl(9, 0x4142, 0) = -1 EPIPE (Broken pipe) The best I can do is know that this is trying to work with file descriptor 9 and the IOCTL for 0x4142, whatever that is, is failing. But I'm not sure how to map that open fd to a filename so that I can try to determine if it is something I introduced as an error in my configuration, or if there is a problem with the program somewhere, wherein a bug needs to be reported. Thanks in advance for any help, Mike -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] aRts sound server on KDE 3.5.2?
On Thursday 20 April 2006 8:12 am, Michael B. Trausch wrote: I got this all the time with ac97 chipset with older versions of arts. Maybee you are running a similar chipset? or an old driver or something? what kernel version do you run? From google with search on 'arts cpu overload' http://www.arts-project.org/doc/handbook/faq.html#id2805932 13.3 What is wrong in the driver if I get the cpu overload problem? Usually, artsd uses select() to find out when to write new data. Then, it uses an ioctl(...GETOSPACE...) to find out how much data to write. Finally, it writes this data. A problem occurs if artsd is woken up either always or if there are minimal amounts of data to write. The OSS documentation specifies that select() only wakes up a process if there is at least one fragment to write. However, if artsd is woken up if there isn't data to write, or very little, for instance one sample, then it will keep writing little pieces of audio data, which can be very costly, and eventually overload the cpu. To fix this, the driver should wake up artsd only if there is a full fragment to write. That page is a little old but it sould give you an idea of where to start. -- It's not easy, being green. -- Kermit the Frog pgp4JpS7T6QdN.pgp Description: PGP signature
