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 ryniker@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.000000 Low Output Latency: 0.010667 High Input Latency: -1.000000 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,000000 High Input Latency: 0,042667 High Output Latency: -1,000000 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,000000 Low Output Latency: 0,011610 High Input Latency: -1,000000 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 michal 20 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
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...
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 :)
2011/1/19 cornel panceac cpanceac@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...
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.
2011/1/19 Rahul Sundaram metherid@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
On 01/20/2011 01:05 AM, Michał Piotrowski wrote:
2011/1/19 Rahul Sundaram metherid@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
W dniu 19 stycznia 2011 18:44 użytkownik Michał Piotrowski mkkp4x4@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.
2011/1/22 Michał Piotrowski mkkp4x4@gmail.com
W dniu 19 stycznia 2011 18:44 użytkownik Michał Piotrowski mkkp4x4@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.
W dniu 22 stycznia 2011 17:42 użytkownik cornel panceac cpanceac@gmail.com napisał:
2011/1/22 Michał Piotrowski mkkp4x4@gmail.com
W dniu 19 stycznia 2011 18:44 użytkownik Michał Piotrowski mkkp4x4@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,
Might be related
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
-
cornel panceac -
Michał Piotrowski -
Rahul Sundaram