On Thu, Jul 30, 2009 at 12:00 PM, Doug Ledford<dledford(a)redhat.com> wrote:
Agree 1000%. As another kernel engineer that's done sound hardware amongst
other things, if you want to duplicate hardware mixing in my CPU I'm going
to toss you out on your ear. The amount of CPU PA wastes already drives me
nuts. My CPU is intended for important things, like kernel compiles, not to
be wasted unnecessarily on down mixing or up mixing an audio stream.
So you personally own such hardware?
It
gets worse when you have a primary log in as yourself, and a secondary login
for separate mail processing, and you want paplay to play a sound on certain
emails, because it has to route the sound through pa means that if it even
plays at all it plays rough and choppy
Sound is hard; as I understand it this could be driver bugs,
scheduling problems, etc. Lennart's done a lot of work on safely
making the pulse process real-time, which you may or may not have yet.
can't tell you how many times emails got delayed 12+ hours
because they were
waiting on paplay to finish playing a simple beep when they didn't own the
console.
Hmm...I'm confused about the setup here (why a secondary login for
mail processing?) but that aside, probably paplay should have a
--force option to avoid the delay. The reason pulse delays here is
for things like music players where the target behavior is when you
fast user switch, the music player app stops playing.