Version: (using KDE KDE 3.2.0) Installed from: Slackware Packages OS: Linux This bug appears to have been reported in earlier versions of KDE, but the bug reports were all closed. I just downloaded 3.2.0 and its still there so I am reporting it again. When playing mp3's in either juK or (to a much lesser extent) Noatun, the sound will skip. Sometimes the pauses are several seconds long, which is extremely anoying. The skips are accompanied by hard disk activity. It appears that there is insufficient buffering of the .mp3 files. I have never had this problem on the 2.2.x or 3.1.x versions of KDE. I am using a Toshiba 5005-S504 Laptop which has 512Mb of RAM and a 1.1Ghz PIII Processor.
Noatun and JuK don't do any buffering or decoding -- that's all in aRts.
> I have never had this problem on the 2.2.x or 3.1.x versions of KDE. I don't believe you at all. Even if one increases artsd buffering to the max and uses realtime priority long hdd trashing can drain the buffer. So far I haven't found a single app that does not exhibit this behaviour (yes, xmms can do the same) on linux so I'd call this as unfixable.
I'm not talking about long hdd thrashing caused by other programs. I'm talking about leaving the machine with only the music player running. Without even touching the computer, skips will occur. The hdd activity seems to be a symptom, not a cause. Skipping of this nature _never_ has occured with any other music player including xmms. I've been conducting some tests. This info may help: Player Other activity mp3 Bit Rate Result JuK none 128k no skip JuK none 320k skips Noatun none 320k no skip Noatun none 128k no skip JuK open directory in Konq.* 128k skips Noatun "" "" "" "" 128k skips xmms "" "" "" "" 320k no skip *Opening a previously unopened directory with lots of files So, under a normal load neither Noatun no Juk perform satisfactorily. Perhaps the sound system was tested on machines with fast hard disks and so this problem was never noticed?
Same irritation here. Now that XMMS doesn't support aRts output anymore, I'm trying alternatives. However both noatun and JuK suffer from skipping, and other playlist managers (madman for example) use XMMS for playback. Here's my practical experience with skipping in these three programs: * XMMS with aRts output : none (theoretically possible, of course, but never noticed). * Noatun: rare (a few skips per song) * JuK: less rare (several skip per song, as soon as there's CPU activity) The skips are all very short (a tenth of a second, maybe), but sufficiently noticeable to be irritating. They are clearly related to CPU load (or maybe interrupt load, let's just say machine activity). Things that are sure to cause skips: open-in-a-new-tab in Mozilla, switching applications with alt+tab (most windows are full screen), fast-typing text in Mozilla, receiving ten-or-so emails in KMail. The machine is a PII at 275MHz with 192 MB of RAM, a good enough hard drive (UDMA 33, 15 MB/sec or so), an ISA sound card (SB AWE 64), and a sometimes loaded PCI bus (USB modem on an USB PCI card, wireless card that generates lots of interrupts - but skips occur even when it is off). It runs the latest slackware-current (with the latest KDE 3.2.0 packages) and a 2.4.24 kernel with the Con Kolivas patch (low latency scheduling and co.).
Solution for very short skips: With realtime priority turned on in artsd and artswrapper being setuid root this does not happen as long as you have sane audio drivers. Solution for long skips caused by extensive hdd access: bump up the buffer in kdemultimedia/mpeglib/ sources (ask me in pm if you want to know where), I wish I knew how to make this configurable or even find a good size for it. Btw, xmms can suffer from extensive hdd access too, it just has to be long enough. It looks a lot like the input buffer used in mpeglib is just way too small.
The solution for very short skips seems to solve the problem indeed (I also bumped the number of audio fragments from 10 to 20). Thank you for helping so fast!
*** Bug 76452 has been marked as a duplicate of this bug. ***
It's a little bit sad, that this skips still occur. I really like juk, but with these skips (in my case up to half a second on a 1,8 GHz P4, happening about once in a minute) listening to music is no fun and I resort to the - in my opinion inferior - xmms. Is there no possibility to implement a readahead of at least one second in file decoding, so that hdd activity doesn't interrupt music playback?
*** This bug has been confirmed by popular vote. ***
This readahead buffering is implemented and supposed to happen on kernel-level in Linux. Try to run "hdparm" on your drive (you have to be root) and check the settings. On typical modern machine using_dma, unmaskirq, IO_support should be 1. There is also a readahead entry, which on my system defaults to 256 (that is about 128kb). Although even if I disable it, I still dont get any skips in juk/noatun as long as artsd is set to realtime priority.
I'm tempted to close this bugreport because most people don't seem to try out the hints I have given before. Almost anybody who followed all these hints (and I explained that stuff to quite a lot of people) got a working configuration so far, I really don't see why this bug has to be kept open.
Well I testet it with and without the hints given here, and it sound skips. (although suid, artswrapper rectifies this under normal loads, it still happens when cpu and/or disk usage is very high.) The thing why this is reported here (and voted so often) is that xmms (for example) works fine in any case (with and without hdparm, without need to suid anything, and without realtime priority.), even under heavy load (compiling kde, copying large file, etc.). An uneducated guess (which I deduce from the behaviour when xmms is playing from a cd-rom) is that xmms loads the whole track into the memory if not too big. Another point is that this realy is a showstopper bug. Skips in music (or audio in general) are an absolute no-no. An audio app can be the absolute killer app, but when the sound skips, no one is gonna use it.
Then you might be out of luck, no developer seems to have such problems (me neither). And for the skips caused by longer hdd access: not even xmms can handle that gracefully (if the inbuffer is empty then it's empty).
Thats obvious. As I said most of the skips disappeared when I set artswrapper suid (which I don't particularly like to do, since unskipping audio playback should be doable without). Now only the skips under heavy load remain. But in xmms I've never seen this happen, weras in juk I did. Probably the xmms buffer is large enough for most situations, and juk's (arts?) just isn't.
I'll post a patch later on that will drastically increase buffer size for mpeglib. Please recompile mpeglib and mpeglib_artsplug then, make sure to restart artsd and then compare before and after the patch.
Thanks. I'll check this as soon as I can, but thats after tuesday, sorry.
Created attachment 6014 [details] patch to increase buffer size in mpeglib
Created attachment 6015 [details] patch to increase buffer size in mpeglib_artsplug as well
> (which I don't particularly like to do, since unskipping audio playback > should be doable without) Not if you're artsd that can mix multiple audiostreams at once, apply effects to them and route between different sound streams. Not that this is done most of the time but you just cannot easily bypass all the queues needed for all the features. It's just that artsd is more cpu-intensive and sensitive than xmms because it can do and sometimes even does more than xmms (that one just has one stream to handle at a time and only contains code to handle one stream).
Btw, another good test is using an internet stream. if that does not skip (I never got streams to skip on this machine, not even with heavy swapping) then it's probably the hdd being the limited factor. A larger input buffer indeed would help there.
note: arts-xmms is working again (may be called xmms-arts) (its working on my kde3.2.2 with arts output plugin 0.7.1 and xmms 1.2.10 some distros have turned off suidroot artswrapper There is a related bug: bug 76253 where the realtime priority box is checkable, even when artswrapper is not suid root. also, please note that INCREASING the buffer size in the sound panel helps... I origionally thought that spending more cpu == better sound... but that surely isn't the case... I doubt that anybody here had that problem. in gentoo there is a useflag for setting artswrapper suid root (get ufed, the useflag editor)
Additional Feedback. On my out-of-the box Suse 9.1 pro hadparm says: "/dev/hda3: multcount = 16 (on) IO_support = 0 (default 16-bit) (I now know that should be "on" but it is not set out-of-the-box via yast...) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) (that seems good, but i still get skips)" All my 700 .ogg songs skip at first 2-3 seconds in juk. Arts is at maximum prio.
I have this problem. Its exacerbated for me because I am playing mp3s from a remote machine over NFS. I copied one of the ones that gives most problems to a local tmpfs mount, and it no longer does it as badly. Note: there are _still_ some audible glitches even with this. However, XMMS has no problems whatsoever with playing files in this way (over NFS). Noatun/juk both have problems. artsd is setuid, with max. buffers. I AM using xmms WITH artsd, so its not arts that is at fault here. I'm using 2.6.6, with ALSA. I have tried nforce2 onboard sound, and a Creative Audigy2 - both have the exact same issue. Not sure if this is a recent problem or not - it was only recently I started investigating juk/noatun. I *think* it might have been ok in KDE 3.2, but can't be sure (I'm using 3.2.2 now). Juk looks a really good program if it didn't have this issue (and played .m4as)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Somebody who has this problem should test the patch I attached here ! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
On Monday 31 May 2004 13:27, Andrew de Quincey wrote: > However, XMMS has no problems whatsoever with playing files in this way > (over NFS). Noatun/juk both have problems. artsd is setuid, with max. > buffers. I AM using xmms WITH artsd, so its not arts that is at fault here. It still IS an arts problem since arts does the reading and encoding of the files except for noatun which sends an encoded audiostream to arts. So it seems to me as a mpeglib-issue because mpeglib does the encoding for ogg and mp3... Arnold
I tried the patch but it didn't stop the skipping. Is it possible that something else than the buffer size causes the problem?
I really doubt all the people who responded here have the same problem. Sound works perfectly here, with realtime priority, bigger mpeglib buffers and an average artsd buffer.
I recently upgraded arts to 1.2.3 from 1.2.2. Under 1.2.3, Juk started skipping very frequently when playing mp3s and oggs. Increasing/Decreasing the sound buffer didn't seem to help. I was running with realtime priority and with artswrapper setuid to root. Downgrading to 1.2.2 fixed the problem. It appears that something broke in the new version.
I've just upgraded to 3.3.3 beta 2 (gentoo, compiled on my machine) - the skipping seems to be gone now. Excellent, byebye xmms!
I would recommend people who have this problem to try KDE 3.3. The new akodelib decoder has been reported to produce a lot less skipping. Hopefully we can close this bug with sufficient positive feedback.
Yeah! I've tested it with Juk while decompressing a really big .tar.bz2 file, compiling a new release of KDE 3.3 and switching desktops like crazy without a single skip (this would have skipped like crazy before) on all my tests. For me you can close the bug, good job guys this was my #1 hated bug in KDE!
BTW same (perfect) behaviour with Amarok (just tested.)
Tested with a SuSE-8.2 (Kernel 2.4.20 and ReiserFS) with KDE3.3.1: The skips are gone! I'm happy!
Moving this over to mpeglib, akode works perfectly with artsd so it never has been the primary cause.
No one works actively on mpeglib, upgrade to akode from KDE 3.3