Re: pulseaudio eats almost 100% of cpu resources during hdd i/o stress by other program (Re: audio skipping/pure sound quality)
W dniu 19 stycznia 2011 18:44 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: I doubt that this problem is related to kernel space issue. I'll try to track down it this week. Something strange is happening here. I'm running yum upgrade, amarok, firefox and after a while pulse audio goes mad. iotop shows disc write 1 MB/s. Everything else works fine, only PA eats 100% of CPU (one core). When yum upgrade finished, everything was back to normal. -- Best regards, Michal http://eventhorizon.pl/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: pulseaudio eats almost 100% of cpu resources during hdd i/o stress by other program (Re: audio skipping/pure sound quality)
2011/1/22 Michał Piotrowski mkkp...@gmail.com W dniu 19 stycznia 2011 18:44 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: I doubt that this problem is related to kernel space issue. I'll try to track down it this week. Something strange is happening here. I'm running yum upgrade, amarok, firefox and after a while pulse audio goes mad. iotop shows disc write 1 MB/s. Everything else works fine, only PA eats 100% of CPU (one core). When yum upgrade finished, everything was back to normal. i suppose it's unrelated but, after hearing two strange breaks in my playing music (with mplayer), and after seeing the processor at max, i've lost contact to my keyboard, then, after connecting another keyboard (usb, this time), i've lost contact with my usb mouse, too. at this point the music was strangely still playing. this is my home f14 computer. i hope nobody backported the pulseaudio problem to f14 :) i've enabled the ssh server and i'll report back if anything new shows up. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: pulseaudio eats almost 100% of cpu resources during hdd i/o stress by other program (Re: audio skipping/pure sound quality)
Tomorrow I can take some time to try trace what is the source of this behavior. All suggestions would be appreciated i've once asked a (top) linux developer for assistance on some issues with sound and mc, and generally anything involving i/o and scheduler, in my opinion. he told me to look at /proc/sys/kernel/sched_* for some tweakable numbers. but in his opinion, the problem is the i/o. about i/o issues, there's a thread saying that: Now I think the main problem is having the filesystem block (and do IO) in inode reclaim. The problem is that this doesn't get accounted well and penalizes a random allocator with a big latency spike caused by work generated from elsewhere. I think the best idea would be to avoid this. By design if possible, or by deferring the hard work to an asynchronous context. If the latter, then the fs would probably want to throttle creation of new work with queue size of the deferred work, but let's not get into those details. Anyway, the other obvious thing we looked at is the iprune_mutex which is causing the cascading blocking. We could turn this into an rwsem to improve concurrency. It is unreasonable to totally ban all potentially slow or blocking operations in inode reclaim, so I think this is a cheap way to get a small improvement. This doesn't solve the whole problem of course. The process doing inode reclaim will still take the latency hit, and concurrent processes may end up contending on filesystem locks. So fs developers should keep these problems in mind. http://www.kernel.org/pub/linux/kernel/v2.6/testing/v2.6.32/ChangeLog-2.6.32-rc1 as much as i understand those things, the bigger the filesystem, the bigger the i/o slowdown. and if if you are lucky as i am to have one of those infamous green western digital hard disks on a low end motherboard, the system can crawl very easily. hope this will help, somehow :) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: pulseaudio eats almost 100% of cpu resources during hdd i/o stress by other program (Re: audio skipping/pure sound quality)
2011/1/19 cornel panceac cpanc...@gmail.com: Tomorrow I can take some time to try trace what is the source of this behavior. All suggestions would be appreciated i've once asked a (top) linux developer for assistance on some issues with sound and mc, and generally anything involving i/o and scheduler, in my opinion. he told me to look at /proc/sys/kernel/sched_* for some tweakable numbers. but in his opinion, the problem is the i/o. about i/o issues, there's a thread saying that: Now I think the main problem is having the filesystem block (and do IO) in inode reclaim. The problem is that this doesn't get accounted well and penalizes a random allocator with a big latency spike caused by work generated from elsewhere. I think the best idea would be to avoid this. By design if possible, or by deferring the hard work to an asynchronous context. If the latter, then the fs would probably want to throttle creation of new work with queue size of the deferred work, but let's not get into those details. Anyway, the other obvious thing we looked at is the iprune_mutex which is causing the cascading blocking. We could turn this into an rwsem to improve concurrency. It is unreasonable to totally ban all potentially slow or blocking operations in inode reclaim, so I think this is a cheap way to get a small improvement. This doesn't solve the whole problem of course. The process doing inode reclaim will still take the latency hit, and concurrent processes may end up contending on filesystem locks. So fs developers should keep these problems in mind. http://www.kernel.org/pub/linux/kernel/v2.6/testing/v2.6.32/ChangeLog-2.6.32-rc1 And where the famous 2.6.37 vfs scalability fixes? :) as much as i understand those things, the bigger the filesystem, My /home on laptop has 8 or 16GB (it's only a test system) - I've got larger file systems the bigger the i/o slowdown. and if if you are lucky as i am to have one of those infamous green western digital hard disks I'm lucky and I've got two infamous [1.585384] ata3.00: ATA-8: WDC WD10EADS-00L5B1, 01.01A01, max UDMA/133 [..] [1.602188] ata4.00: ATA-8: WDC WD15EADS-00P8B0, 01.00A01, max UDMA/133 I also have one famous [2.907613] ata6.00: ATA-8: WDC WD1001FALS-00E8B0, 05.00K05, max UDMA/133 on a low end motherboard, on atom 330 board. No problems so far :) the system can crawl very easily. hope this will help, somehow :) Thanks for the pointer. I doubt that this problem is related to kernel space issue. I'll try to track down it this week. -- Best regards, Michal http://eventhorizon.pl/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: pulseaudio eats almost 100% of cpu resources during hdd i/o stress by other program (Re: audio skipping/pure sound quality)
On 01/19/2011 11:14 PM, Michał Piotrowski wrote: And where the famous 2.6.37 vfs scalability fixes? :) Some were merged in 2.6.36 and the rest will be in 2.6.38 and not 2.6.37 Rahul -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: pulseaudio eats almost 100% of cpu resources during hdd i/o stress by other program (Re: audio skipping/pure sound quality)
2011/1/19 Rahul Sundaram methe...@gmail.com: On 01/19/2011 11:14 PM, Michał Piotrowski wrote: And where the famous 2.6.37 vfs scalability fixes? :) Some were merged in 2.6.36 and the rest will be in 2.6.38 and not 2.6.37 git log --format=oneline --abbrev-commit v2.6.36..v2.6.37 fs/ | grep fs: shows some stuff the entire list may also reveal some patches git log --format=oneline --abbrev-commit v2.6.36..v2.6.37 fs/ Rahul -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test -- Best regards, Michal http://eventhorizon.pl/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: pulseaudio eats almost 100% of cpu resources during hdd i/o stress by other program (Re: audio skipping/pure sound quality)
On 01/20/2011 01:05 AM, Michał Piotrowski wrote: 2011/1/19 Rahul Sundaram methe...@gmail.com: On 01/19/2011 11:14 PM, Michał Piotrowski wrote: And where the famous 2.6.37 vfs scalability fixes? :) Some were merged in 2.6.36 and the rest will be in 2.6.38 and not 2.6.37 git log --format=oneline --abbrev-commit v2.6.36..v2.6.37 fs/ | grep fs: shows some stuff the entire list may also reveal some patches git log --format=oneline --abbrev-commit v2.6.36..v2.6.37 fs/ The main improvement, RCU based name lookup is in 2.6.38 rc1. I assumed you were talking about that instead of minor fixes. Rahul -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: audio skipping/pure sound quality
I have experienced effects like those you described when Pulseaudio (or perhaps something else in the audio-processing chain) must do sample-rate conversion, such as from 44.1 KHz to 48KHz, to drive my USB speakers. Sox has been an effective solution for me. Try play (a link to sox that denotes output to sound hardware instead of a file) to learn whether sox may offer superior sample-rate conversion that avoids the problems you hear. There are probably a handful of tools that will display information about sound devices. Audacity has a convenient one: Help - Audio Device Info that displays supported sample rates. For example, I see: Default capture device number: 13 Default playback device number: 13 == Device ID: 0 Device name: ALSA: Bose USB Audio: USB Audio (hw:0,0) Input channels: 0 Output channels: 6 Low Input Latency: -1.00 Low Output Latency: 0.010667 High Input Latency: -1.00 High Output Latency: 0.042667 Supported Rates: 48000 == Output like this may display a needed sample rate for your USB sound device (48000 in my case). If you use sox to convert a file to the target rate before you play it, and it then sounds good, this confirms the problem involves resampling. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
pulseaudio eats almost 100% of cpu resources during hdd i/o stress by other program (Re: audio skipping/pure sound quality)
Hi, 2011/1/18 Richard Ryniker ryni...@alum.mit.edu: I have experienced effects like those you described when Pulseaudio (or perhaps something else in the audio-processing chain) must do sample-rate conversion, such as from 44.1 KHz to 48KHz, to drive my USB speakers. Sox has been an effective solution for me. Try play (a link to sox that denotes output to sound hardware instead of a file) to learn whether sox may offer superior sample-rate conversion that avoids the problems you hear. There are probably a handful of tools that will display information about sound devices. Audacity has a convenient one: Help - Audio Device Info that displays supported sample rates. For example, I see: Default capture device number: 13 Default playback device number: 13 == Device ID: 0 Device name: ALSA: Bose USB Audio: USB Audio (hw:0,0) Input channels: 0 Output channels: 6 Low Input Latency: -1.00 Low Output Latency: 0.010667 High Input Latency: -1.00 High Output Latency: 0.042667 Supported Rates: 48000 == Hmmm... == Device ID: 1 Device name: ALSA: SB Audigy 2 NX: USB Audio (hw:1,0) Input channels: 2 Output channels: 0 Low Input Latency: 0,010667 Low Output Latency: -1,00 High Input Latency: 0,042667 High Output Latency: -1,00 Supported Rates: == What an interesting coincidence with high/low i/o latency numbers :) Apparently my card doesn't support rates, but there is a == Device ID: 4 Device name: ALSA: surround51 Input channels: 0 Output channels: 2 Low Input Latency: -1,00 Low Output Latency: 0,011610 High Input Latency: -1,00 High Output Latency: 0,046440 Supported Rates: 8000 11025 16000 22050 32000 44100 48000 == I think that problem is somehow related to disk i/o in my case. I'm doing yum upgrade on one console and on second console I did dd if=/dev/zero of=plik.dat bs=128M count=32 and pulse audio eats almost 100% of cpu resources 1308 michal20 0 669m 54m 36m S 99.9 2.7 5:36.03 pulseaudio I use amarok for playing music - I'm not sure if it has any relevance. Tomorrow I can take some time to try trace what is the source of this behavior. All suggestions would be appreciated Output like this may display a needed sample rate for your USB sound device (48000 in my case). If you use sox to convert a file to the target rate before you play it, and it then sounds good, this confirms the problem involves resampling. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test -- Best regards, Michal http://eventhorizon.pl/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
audio skipping/pure sound quality
Hi, Recently I bought the USB Sound Blaster Audigy 2 NX card and 5.1 speaker system for my laptop. I'm really happy with the sound quality on Windows. Unfortunately, the sound quality on Linux is not so good - I hear various clicks and skips. I'm guessing that it may be caused by that the sound is not delivered on time to some buffer or something like that. I changed default-sample-rate in /etc/pulse/daemon.conf but it did not solve the problem. Is there something else then I can try to use to improve sound quality? Pulseaudio uses a lot of resources 1270 michal20 0 650m 14m 11m R 14.6 0.7 6:28.79 pulseaudio BTW. A matter of fact, I was surprised that this card works under Linux out of box. There were problems with the card under Windows - drivers are installed automatically, but card does not work until I installed the drivers from the manufacturer. -- Best regards, Michal http://eventhorizon.pl/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
