[ANNOUNCE] New Mixer Handling in PA 0.9.16/F12

[Doug Ledford]

On Jul 30, 2009, at 9:28 AM, Colin Walters wrote:
> On Thu, Jul 30, 2009 at 12:00 PM, Doug Ledford<dledford at 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 at redhat.com>

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

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




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090730/50c0c5c0/attachment.sig>