After poking around for the entire day/night looking for
some pattern/reason for the CPU usage reports we've been seeing,
I finally came up with this:
commit dccdfce721ffe730de2f55a67ecd1acfcb19bb0a
Author: Eric Wong <[EMAIL PROTECTED]>
Date: Mon Sep 8 04:30:30 2008 -0700
alsa: use blocking instead of non-blocking write
The way we used non-blocking mode was HORRIBLE.
It was non-blocking to ALSA, but we end up blocking in a busy
loop that does absolutely NOTHING but retry. We don't check
for playback cancellation (like we do in decoders) or anything.
This is seriously broken and I can imagine it affects people on
fast CPUs more because we do asynchronous output buffering and
our ALSA device will always have data ready.
I'll test it on my fast machine tomorrow, but it seems to mainly affect
people with faster hardware.
Note: the long term fix will probably be to use a thread for each output
and just do blocking writes in each thread. The
mixing/resampling/encoding/streaming that goes on in all the output
plugins is too unpredictable and potentially CPU bound to be worth doing
with events/non-blocking I/O.
--
Eric Wong
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
