[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12

On Thu, Jul 30, 2009 at 12:00 PM, Doug Ledford<dledford 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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]