[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 Jul 30, 2009, at 9:28 AM, Colin Walters wrote:
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?

Not hardware up mix/down mixing, but hardware mixing. And as my other post points out, I make use of it and have no intent of ever not using it. Right now I simply use gst-mixer to enable the mixing behind PA's back. I consider the fact that PA can't/won't do it to be a serious design flaw.

 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.

It worked fine prior to PA. I can't say what specifically is causing it, other than the paplay command will often start to play, get a little out, then just never complete. I used to use this to alert me to specific emails that I needed to respond to immediately, instead I now redirect them to a different folder and have my mail client (which runs as the primary user) alert me instead.

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.


Because I fetchmail all my different email accounts to a single box, and depending on mail client, some want different actual IMAP accounts in order to support multiple outgoing identities. My primary account has an IMAP login that maps to one email address and the secondary account maps to another.

--

Doug Ledford <dledford redhat com>

GPG KeyID: CFBFF194
http://people.redhat.com/dledford

InfiniBand Specific RPMS
http://people.redhat.com/dledford/Infiniband




Attachment: PGP.sig
Description: This is a digitally signed message part


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