[ANNOUNCE] New Mixer Handling in PA 0.9.16/F12

Doug Ledford dledford at redhat.com
Wed Aug 12 00:50:15 UTC 2009


Apologies for my late reply, I was gone for a week.

On Aug 1, 2009, at 1:44 PM, Matthew Garrett wrote:
> On Sat, Aug 01, 2009 at 08:16:50AM -0500, Doug Ledford wrote:
>> CD in is nothing more than an analog input. PA ignores all the analog
>> inputs other than as a digital PCM source. Treating all the analog
>> inputs as digital sources and not allowing the hardware to mix them  
>> to
>> output has various drawbacks. I've just been covering some of them.
>
> You're continuing to conflate two issues - hardware mixing of multiple
> PCM streams (which some hardware supports but PA doesn't make use of)

Actually, I never referred to multiple PCM streams, just PCM +  
multiple analog mixing.

> and having control over the levels of analog inputs that are mixed
> straight into the analog output stream. PA exposes some of these, but
> not all of them -

I must have missed it.  Where is it possible in PA to send *any*  
analog input directly to analog output?

> however, you can still use an alternative mixer app if
> you want to configure this for your specific niche use case.

Which is what I currently do.  However, my entry into this foray was  
caused by the current maintainer of gst-mixer stating that he would  
support it being removed from the default install image and comps.   
 From there it's a short step to it never getting compiled against  
current libs and eventually falling away entirely.  For PA to suit my  
needs, and for this not to be a problem for me, I simply need support  
for sending analog inputs to analog outputs.  Nothing more.

The CD-In case is simply one instance of that capability and one I  
don't really care about.  However, from a coding perspective, once you  
support CD-In or Aux or Line-In being sent directly to analog output,  
all of the others are done too, you just change the input channel and  
everything else is the same.  So, from my perspective, saying that you  
don't need to support CD-In because it's a dead and deprecated usage  
of the hardware, and therefore you don't need to support *any* analog  
input to analog output control is a logically fallacious argument  
(specifically, generalization from one to the whole).  Whether CD-In  
usage is dead or not, the other uses aren't.  So, for all I care, we  
can skip CD-In support entirely, but Line-In and Aux should work.   
And, of course, going back to what I just said, once either of those  
two works, you already have the back end necessary to support CD-In  
for free.  So he's worried about unconnected CD drives causing bug  
reports.  Fine, don't enable CD-In, but that's not a valid excuse to  
leave the other ports dysfunctional.

> When
> Lennart says "PulseAudio does not support hardware mixing" he is *not*
> talking about the case you're describing.


Well, it *doesn't* support the case I'm describing, whether that's  
what he means when he says so or not.

--

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/20090811/90d12658/attachment.sig>


More information about the fedora-devel-list mailing list