On Wed, 23.12.09 14:04, tieg (tie.ge at access-company.com) wrote: > Recently, I am considering to port pulseaudio to TI OMAP 3430. However, > pulseaudio framework does not take DSP solution into consideration. It > is trouble for me to decide mixing with DSP or pulseaudio. If with DSP, > pulseaudio seems nonsense. If with pulseaudio, the DSP potential can not > be fully used, and there will be performance issue. > > Does any one encounter the same situation as me? Any suggestion or idea > is welcome! PA does more than simple audio mixing. If that was all it is about then it would not offer any benefits over dmix. Please note that PA is actually designed in a way that allows hw mixing except that there is currently no backend that makes use of this. If you look at the various backend drivers in PA you see that the actual PCM data to play back is gathered via a call pa_sink_render() (or a related call). That function converts and mixes the audio data coming in from all streams and then simply returns the result. However, that function call is simply a default implementation of a mixer, it is a tool if you so will for those backends which do not support mixing in hw. Since no backend supports hw mixing right now it is used by all backends. Now, if you want to do the mixing in hw you can do what pa_sink_render() internally does and go to each stream directly and ask for their data and then pass that off to your hw in a way you want. You can even choose whether you query the data before or after the conversion step. So in summary: yes, right now we only do sw mixing. But the code has been designed in a away to allow backends to easily implement hw mixing, too. (If at all the changes to the core to make that work are minimal) That said, I am quite sure that hw mixing is not particularly useful on desktops. It has some validity however in embedded environments. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
