Re: [pulseaudio-discuss] Very crackly audio and crashing from cpu overload
On Friday 09 January 2009 00:23:32 Chris wrote: 2009/1/8 Renke Brausse rbrau...@gmx.net: sorry, off topic - but I can't resist... Am Freitag, den 09.01.2009, 00:50 +0100 schrieb Lennart Poettering: and of course because software I write doesn't have any bugs! do you need a new job? just contact me :) [:p] If you need a programmer who can produce obscure bugs out of thin air, I'm your man, otherwise go for Lennart! Anyway, I tried the nv driver in case it was the nvidia taint messing up things but no change in behaviour. Looking at Lennart's options, I doubt that the sound card driver is bad. The ICE1712 chip has been around for at least 6 years in my experience. My employer makes embedded Linux devices and we've used various M-Audio devices, all using the ICE1712 since RedHat 7.3! Doesn't make it impossible but quite unlikely. Whilst I don't know much about the driver in detail, and I guess it hasn't been touched for a long time, I was under the impression it was a well documented and supported device. So I'm still thinking that the problem is related to my XOrg CPU usage and some kind of interrupt issue. When I was using the nvidia driver, CPU usage by Xorg was around 30-40%! Now I'm on the OSS nv driver and it's about 15-20% (think that's for 1 core only). Doesn't seem that much but maybe it's a timing issue related to interrupts. I'll have a play with latencytop in the next few days. Thanks again for the help. I'm getting closer to sorting this out and if I do I'll try to post it web-wide so googlers can find it. Just a thought, do you have any VIA chipsets on your motherboard? If you do, throw it away and buy another one. It'll save you hours of fruitlessly trying to find a software problem that doesn't exist. Don't ask me how I know this unless you want a rant... ;) Mark Cheers, Chris. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Very crackly audio and crashing from cpu overload
2009/1/9 Mark Greenwood extreme...@ntlworld.com: Just a thought, do you have any VIA chipsets on your motherboard? If you do, throw it away and buy another one. It'll save you hours of fruitlessly trying to find a software problem that doesn't exist. Don't ask me how I know this unless you want a rant... ;) Mark Thankfully not. It's an ALi (or ULi - same company I think) chipset. Although it could still be the problem. I'll probably tinker some more tonight. Thanks for the idea though! Chris. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Very crackly audio and crashing from cpu overload
Hi, I've been having lots of problems with audio in Fedora 10. At first I was having problems playing sound in youtube via firefox. I found a tutorial which suggested I change a line in default.pa from: load-module module-hal-detect to load-module module-hal-detect tsched=0 That did seem to improve things. However amarok is really not happy. I can play mp3s for a minute or two but it is very crackly. Then eventually the audio stops and amarok locks up. /var/log/messages shows messages like this: Jan 8 21:26:46 localhost pulseaudio[3188]: main.c: High-priority scheduling enabled in configuration but not allowed by policy. Jan 8 21:26:46 localhost pulseaudio[3188]: core-util.c: setpriority(): Permission denied Jan 8 21:26:46 localhost pulseaudio[3191]: alsa-util.c: Device hw:0 doesn't support 2 channels, changed to 10. Jan 8 21:26:46 localhost pulseaudio[3191]: alsa-util.c: Device hw:0 doesn't support sample format s16le, changed to s32le. Jan 8 21:26:46 localhost pulseaudio[3191]: alsa-util.c: Cannot find fallback mixer control PCM. Jan 8 21:26:46 localhost pulseaudio[3191]: alsa-util.c: Device hw:0 doesn't support 2 channels, changed to 12. Jan 8 21:26:46 localhost pulseaudio[3191]: alsa-util.c: Device hw:0 doesn't support sample format s16le, changed to s32le. Jan 8 21:26:46 localhost pulseaudio[3191]: alsa-util.c: Cannot find fallback mixer control Mic. Jan 8 21:33:29 localhost pulseaudio[3191]: cpulimit.c: Recevied request to terminate due to CPU overload. I've running an AMD Athlon 64 x2 (can't remember the exact model) although it's 32 bit Fedora 10. The soundcard is an M-Audio Audiophile 2496 (ICE1712 chip I believe). I never got pulseaudio working with this setup in Fedora 9 and had to remove all pulse packages. Now it's almost working but there are clearly still issues. Any ideas? (This is my home PC so I can only investigate in the evenings, UK time, so bear with me! ) Thanks, Chris. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Very crackly audio and crashing from cpu overload
Chris wrote: Hi, I've been having lots of problems with audio in Fedora 10. At first I was having problems playing sound in youtube via firefox. I found a tutorial which suggested I change a line in default.pa from: load-module module-hal-detect to load-module module-hal-detect tsched=0 That did seem to improve things. However amarok is really not happy. I can play mp3s for a minute or two but it is very crackly. Then eventually the audio stops and amarok locks up. /var/log/messages shows messages like this: Jan 8 21:26:46 localhost pulseaudio[3188]: main.c: High-priority scheduling enabled in configuration but not allowed by policy. Jan 8 21:26:46 localhost pulseaudio[3188]: core-util.c: setpriority(): Permission denied Jan 8 21:26:46 localhost pulseaudio[3191]: alsa-util.c: Device hw:0 doesn't support 2 channels, changed to 10. Jan 8 21:26:46 localhost pulseaudio[3191]: alsa-util.c: Device hw:0 doesn't support sample format s16le, changed to s32le. Jan 8 21:26:46 localhost pulseaudio[3191]: alsa-util.c: Cannot find fallback mixer control PCM. Jan 8 21:26:46 localhost pulseaudio[3191]: alsa-util.c: Device hw:0 doesn't support 2 channels, changed to 12. Jan 8 21:26:46 localhost pulseaudio[3191]: alsa-util.c: Device hw:0 doesn't support sample format s16le, changed to s32le. Jan 8 21:26:46 localhost pulseaudio[3191]: alsa-util.c: Cannot find fallback mixer control Mic. Jan 8 21:33:29 localhost pulseaudio[3191]: cpulimit.c: Recevied request to terminate due to CPU overload. I've running an AMD Athlon 64 x2 (can't remember the exact model) although it's 32 bit Fedora 10. The soundcard is an M-Audio Audiophile 2496 (ICE1712 chip I believe). I never got pulseaudio working with this setup in Fedora 9 and had to remove all pulse packages. Now it's almost working but there are clearly still issues. Any ideas? (This is my home PC so I can only investigate in the evenings, UK time, so bear with me! ) Thanks, Chris. I suggest you to try pulseaudio 0.9.10 (or wait Lennart to release a new one :)) to see if the problems occurs or not. We're using 0.9.10 and it's really flawless. -- Ozan Çağlayan ozan_at_pardus.org.tr ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Very crackly audio and crashing from cpu overload
On Thu, 08.01.09 21:40, Chris (chris1.nore...@googlemail.com) wrote: Hi, I've been having lots of problems with audio in Fedora 10. At first I was having problems playing sound in youtube via firefox. I found a tutorial which suggested I change a line in default.pa from: Which ALSA sound driver is used? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Very crackly audio and crashing from cpu overload
2009/1/8 Lennart Poettering lenn...@poettering.net: The fragment stuff is not used when tsched is enabled. So playing around with the frag stuff is pointless when tsched=1. At least I'm not going mad. I didn't think it was doing anything but it's somewhat subjective. Any thoughts on the wakeup watermark though? It seems that whenever there is a glitch, the watermark is increased, and whenever the watermark is increased, the frequency of glitching increases until it hits the limit - in my case 71.27ms. Is there anyway to force this wakeup watermark setting? Everything works better for me, although still not perfect, when it is a low number. Chris. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Very crackly audio and crashing from cpu overload
On Thu, 08.01.09 23:03, Chris (chris1.nore...@googlemail.com) wrote: 2009/1/8 Chris chris1.nore...@googlemail.com: 2009/1/8 Lennart Poettering lenn...@poettering.net: I've been playing with the default-fragments and default-fragment-size-msec settings but they don't seem to be having any effect. I'm just getting occasional skipping now - maybe one skip of a fraction of a second every 3 to 5 seconds. The bad crackling went when I set tsched=1. Think I've figured out something interesting... when I first start playing music, it works reasonably well, but after a while, maybe 30 seconds, there is a glitch. At soon as there is a glitch, a message appears in /var/log/messages about increasing the wakeup watermark. Then the next glitch occurs after about 15 seconds and the watermark is increased. Basically, the glitches become more and more frequent as the watermark is increased. Here's the log output... Jan 8 22:58:20 localhost pulseaudio[2772]: module-alsa-sink.c: Increasing wakeup watermark to 5.99 ms Jan 8 22:58:45 localhost pulseaudio[2772]: module-alsa-sink.c: Increasing wakeup watermark to 11.97 ms Jan 8 22:59:15 localhost pulseaudio[2772]: module-alsa-sink.c: Increasing wakeup watermark to 23.95 ms Jan 8 22:59:17 localhost pulseaudio[2772]: module-alsa-sink.c: Increasing wakeup watermark to 47.89 ms Jan 8 22:59:24 localhost pulseaudio[2772]: module-alsa-sink.c: Increasing wakeup watermark to 71.27 ms It never goes above that 71.27ms point but the glitches are frequent from that point on until I restart pulse. When PA detects an underrun it thinks: ah, so we didn't wake up in time to fill the playback buffer again, so next time lets wake up a bit earlier to increase the chance that we can fill up the playback buffer in time. That means the wakeup watermark (i.e. the time PA estimnates it needs to fill up the buffer again before the buffer might run empty) is doubled on each drop out. However we don't increase the wakeup boundary without limits -- instead we make sure we will still sleep for at least half the buffer size. That's why the watermark doubles on each drop-out until an upper limit is reached. Now the question is of course why you get those drop outs in the first place. There might be three reasons for that: 1) The driver is broken and lies about the timing parameters (i.e. the playback position of the hardware). PA relies on correct timing information from the driver to estimate when to wake up next. This would need to be fixed in the ALSA driver. 2) The estimnation logic in PA is broken. i.e. although we got correct timing information from the driver we miscalculate the wakeup time because the retard who wrote that code (read: me) made a mistake when he coded it because that stuff is a bit complex and he is not. This would need fixing in PA itself. 3) We estimate everything correctly and set up our timers correctly, but the kernel doesn't obey and doesn't wake us up in time. Bad bad kernel. There might be a lot of reasons for that. Usually this has todo with drivers that block the CPU for too long and thus bar userspace from getting scheduled in time. Particularly bad at this are closed-source drivers (ndis, nvidia). The tool latencytop may be used to figure out what is going on. I am tempted to blame #1 an #3 for most incarnations of this bug, because it is only triggered by very specific hardware setups -- and of course because software I write doesn't have any bugs! I hope this helps a bit. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Very crackly audio and crashing from cpu overload
2009/1/8 Lennart Poettering lenn...@poettering.net: On Thu, 08.01.09 23:03, Chris (chris1.nore...@googlemail.com) wrote: 2009/1/8 Chris chris1.nore...@googlemail.com: 2009/1/8 Lennart Poettering lenn...@poettering.net: I've been playing with the default-fragments and default-fragment-size-msec settings but they don't seem to be having any effect. I'm just getting occasional skipping now - maybe one skip of a fraction of a second every 3 to 5 seconds. The bad crackling went when I set tsched=1. Think I've figured out something interesting... when I first start playing music, it works reasonably well, but after a while, maybe 30 seconds, there is a glitch. At soon as there is a glitch, a message appears in /var/log/messages about increasing the wakeup watermark. Then the next glitch occurs after about 15 seconds and the watermark is increased. Basically, the glitches become more and more frequent as the watermark is increased. Here's the log output... Jan 8 22:58:20 localhost pulseaudio[2772]: module-alsa-sink.c: Increasing wakeup watermark to 5.99 ms Jan 8 22:58:45 localhost pulseaudio[2772]: module-alsa-sink.c: Increasing wakeup watermark to 11.97 ms Jan 8 22:59:15 localhost pulseaudio[2772]: module-alsa-sink.c: Increasing wakeup watermark to 23.95 ms Jan 8 22:59:17 localhost pulseaudio[2772]: module-alsa-sink.c: Increasing wakeup watermark to 47.89 ms Jan 8 22:59:24 localhost pulseaudio[2772]: module-alsa-sink.c: Increasing wakeup watermark to 71.27 ms It never goes above that 71.27ms point but the glitches are frequent from that point on until I restart pulse. When PA detects an underrun it thinks: ah, so we didn't wake up in time to fill the playback buffer again, so next time lets wake up a bit earlier to increase the chance that we can fill up the playback buffer in time. That means the wakeup watermark (i.e. the time PA estimnates it needs to fill up the buffer again before the buffer might run empty) is doubled on each drop out. However we don't increase the wakeup boundary without limits -- instead we make sure we will still sleep for at least half the buffer size. That's why the watermark doubles on each drop-out until an upper limit is reached. Now the question is of course why you get those drop outs in the first place. There might be three reasons for that: 1) The driver is broken and lies about the timing parameters (i.e. the playback position of the hardware). PA relies on correct timing information from the driver to estimate when to wake up next. This would need to be fixed in the ALSA driver. 2) The estimnation logic in PA is broken. i.e. although we got correct timing information from the driver we miscalculate the wakeup time because the retard who wrote that code (read: me) made a mistake when he coded it because that stuff is a bit complex and he is not. This would need fixing in PA itself. 3) We estimate everything correctly and set up our timers correctly, but the kernel doesn't obey and doesn't wake us up in time. Bad bad kernel. There might be a lot of reasons for that. Usually this has todo with drivers that block the CPU for too long and thus bar userspace from getting scheduled in time. Particularly bad at this are closed-source drivers (ndis, nvidia). The tool latencytop may be used to figure out what is going on. I am tempted to blame #1 an #3 for most incarnations of this bug, because it is only triggered by very specific hardware setups -- and of course because software I write doesn't have any bugs! I hope this helps a bit. Very useful info, thanks. I'm probably gonna call it a night now but I'll do my best to investigate each of those options in the next few days. For me, #3 sounds most probable since I'm running the dreaded nvidia blob. I wanted compiz eye-candy although I've not managed to get it working yet and Xorg still seems to be using a lot of CPU so it's probably the nvidia driver to blame. I'll be sure to let you know how it pans out because you've been very helpful. Keep up the good work! Cheers, Chris. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Very crackly audio and crashing from cpu overload
2009/1/8 Renke Brausse rbrau...@gmx.net: sorry, off topic - but I can't resist... Am Freitag, den 09.01.2009, 00:50 +0100 schrieb Lennart Poettering: and of course because software I write doesn't have any bugs! do you need a new job? just contact me :) [:p] If you need a programmer who can produce obscure bugs out of thin air, I'm your man, otherwise go for Lennart! Anyway, I tried the nv driver in case it was the nvidia taint messing up things but no change in behaviour. Looking at Lennart's options, I doubt that the sound card driver is bad. The ICE1712 chip has been around for at least 6 years in my experience. My employer makes embedded Linux devices and we've used various M-Audio devices, all using the ICE1712 since RedHat 7.3! Doesn't make it impossible but quite unlikely. Whilst I don't know much about the driver in detail, and I guess it hasn't been touched for a long time, I was under the impression it was a well documented and supported device. So I'm still thinking that the problem is related to my XOrg CPU usage and some kind of interrupt issue. When I was using the nvidia driver, CPU usage by Xorg was around 30-40%! Now I'm on the OSS nv driver and it's about 15-20% (think that's for 1 core only). Doesn't seem that much but maybe it's a timing issue related to interrupts. I'll have a play with latencytop in the next few days. Thanks again for the help. I'm getting closer to sorting this out and if I do I'll try to post it web-wide so googlers can find it. Cheers, Chris. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
