[pulseaudio-discuss] Pulseaudio Mixing & DSP Mixing

[Jason Newton]

On 12/22/2009 10:04 PM, tieg 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.
>   
I've not had the pleasure of working with one of these embedded tiny
full featured platforms but I believe the dsp processor is used as a
coprocessor/vpu ... in this sense couldn't you just just replace the
pulseaudio simd asm with the relevant dsp commands (+relevant msg
dispatch/synchronization)?  True the vector sizes from sse are much less
than what the dsp processor is used to but you should be able to change
adjust things in the hopefully few critical areas.  This isn't like the
hardware mixers that come (came?) with soundcards afaik, which are the
kind Lennart is against (and is very understandable given how easy/cheap
audio is to process on a modern _desktop_ vs dealing with general
soundcard  mixers), because of how easy it is to actually jump into the
dsp core wrt to programming and so you might supplement pulse in
sensitive areas to take advantage of the awesome vpu to gain the best of
both worlds.  The areas offhand I'd most look into speeding up is volume
adjustment (lots of mults) and obviously mixing of streams (straight
addition?) of entire memchunks* at a time or as large as the processor
can do in a single iteration until it completes a memchunk. OTOH,
depending on your application, perhaps you do not need the advanced
features pulse offers.  If I was looking to make a standalone device and
not a general purpose computer/media center/handset... I think I'd avoid
pulse all together for simplicity if the device was to only do one thing
and do it well.  This allows you to control the environment much more
which is important for absolute minimal latency and arguably exposes you
to less bugs if your software stack becomes small enough in a subsystems
and sloc sense given how many things pulse depends on and how flakey
they sometimes are, but as I said before, it depends on your application...

*memchunk's are pulse's message payload type of audio data

HTH
-Jason