[ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
dledford at redhat.com
Thu Jul 30 12:00:04 UTC 2009
On Jul 29, 2009, at 6:48 AM, Jeff Garzik wrote:
> Karel Zak wrote:
>> On Tue, Jul 28, 2009 at 10:07:32PM +0200, Lennart Poettering wrote:
>>> On Tue, 28.07.09 15:48, Bill Nottingham (notting at redhat.com) wrote:
>>> Yes. You cannot select them as record source, you cannot mute or
>>> unmute them, you cannot change their volume. "CD", "PC Speaker",
>>> "MIDI" and so on are just obsolete.
>> This reminds me your note:
>> PA does not make use of hardware mixing. And I don't plan to
>> that. It's obsolete technology. CPUs these days come with
>> such as MMX or SSE precisely for speeding up DSP tasks such as PCM
>> mixing. This is way more flexible that hw mixing, and definitely
>> way to the future, both on the desktop and on embedded envs as
>> The "obsolete technology" -- who made this decision? Is it your
>> opinion or any suggestion from sound card manufacturers?
>> It seems that HW companies still produce the "obsolete technology".
> Quite agreed [says a former kernel audio driver maintainer], and I
> will go even farther:
> It is completely stupid to waste host CPU on a task that can be
> offloaded in parallel to dedicated audio hardware.
> If the user intentionally purchased expensive audio hardware with
> nice hardware mixing, do not subvert the user's intentions by
> ignoring such nice hardware.
> Any developer who claims "always use software mixing" or "always use
> hardware mixing" is a young, inexperienced fool. There are valid
> situations for both choices.
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. 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 and uses an assload of CPU
time. I 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.
Doug Ledford <dledford at redhat.com>
GPG KeyID: CFBFF194
InfiniBand Specific RPMS
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 203 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090730/30f814ab/attachment.bin
More information about the devel