[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



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 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]