The resampling part makes complete sense. Palm are using a polyphase fixed-ratio filter; this will be more optimized than the variable-rate interpolation provided by libspeexdsp (no need to be variable-rate for file playback, only needed when devices are not clocked off of the same reference). The footprint of additional tables is negligible in light of the MIPS savings. Looks like there's a 4-band EQ implemented with biquads applied just before writing the data to ALSA buffers. Not sure if this is the right thing to do if PA rewinds and remixes, they would need to keep the filter state. Not sure either why they released the filter coefficients and algorithm, usually this is the secret sauce you never provide to anyone. The bad thing is that we now have at least four independent audio policy modules in various PulseAudio implementations, each requiring apps to use a specific interface. Sockets, DBUS, callbacks, you name it, life just became more difficult for application development. Cheers Pierre On Fri, Jun 19, 2009 at 7:43 AM, Lennart Poettering<lennart at poettering.net> wrote: > On Fri, 19.06.09 09:31, Colin Guthrie (gmane at colin.guthr.ie) wrote: > >> Joking aside, it's good to see this patch. Am I right in saying that >> they didn't actually need to share it due to the LGPL side of things? If >> so good on them for releasing it all the same :) > > LGPL is not BSD. Of course they had to release their patches. What > they didn't have to release is stuff they dynamically link into > PA. But all changes on PA's sources themselves they had to release. > > Lennart > > -- > Lennart Poettering ? ? ? ? ? ? ? ? ? ? ? ?Red Hat, Inc. > lennart [at] poettering [dot] net > http://0pointer.net/lennart/ ? ? ? ? ? GnuPG 0x1A015CC4 > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss at mail.0pointer.de > https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss >
