[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 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 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 change that. It's obsolete technology. CPUs these days come with extensions
   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 the way to the future, both on the desktop and on embedded envs as well. The "obsolete technology" -- who made this decision? Is it your private
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 redhat com>


InfiniBand Specific RPMS

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]