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
