| |||||||||||||
Open source identity: PulseAudio creator Lennart Poettering (CIO)Open source identity: PulseAudio creator Lennart Poettering (CIO)Posted Oct 13, 2009 6:17 UTC (Tue) by alankila (subscriber, #47141)In reply to: Open source identity: PulseAudio creator Lennart Poettering (CIO) by xorbe Parent article: Open source identity: PulseAudio creator Lennart Poettering (CIO)
There is no one setting that is OK for everyone. The most important thing to consider is that hi-fi audio processing can take a lot of time, and the only real improvements available for, say, convolutions are SSE/SSE2 processing that can operate 4 or 2 floats at a time.
Unfortunately for kernel, it can't do floating point mathematics. That limits kernel's operations to integer-only stuff, which is unable to do it well enough. 32-bit integers aren't wide enough for running 96 dB SNR convolutions, so no serious audio freak would accept such a compromise.
So, to summarize: you can't solve this problem from kernel in fashion that is acceptable for everyone.
(Log in to post comments)
Open source identity: PulseAudio creator Lennart Poettering (CIO) Posted Oct 14, 2009 2:13 UTC (Wed) by paulj (subscriber, #341) [Link] Unfortunately for kernel, it can't do floating point mathematics. That's not true though. While there may be very good reasons for not prohibiting the kernel from using FP generally, there's no reason that specific sub- systems of the kernel could not use FP or SSE if they're careful. E.g. see the use of MMX and SSE by the RAID-5/6 modules.
Open source identity: PulseAudio creator Lennart Poettering (CIO) Posted Oct 14, 2009 2:50 UTC (Wed) by alankila (subscriber, #47141) [Link]
Hey, good point. It is already being done. Looks like floating point processing runs with pre-emption disabled. It could still be harmful for latency/realtime work, unless done in small chunks or something. (Source: asm/i387.h, kernel_fpu_begin().)
|
|||||||||||||