But you don't seem to understand, that there is no way that they CAN with this development model, as so much of the system is developed outside of their own internal processes.

To further expound,

PulseAudio is always running on the system, and it is routing audio to and from the various ports on the system, be it the headphone port, audio through bluetooth, etc.

Due to the architecture of the underlying sound drivers (which are written in ALSA), switching between headphones, to speakers, to bluetooth etc would possibly require changes in the output format of the sound, which requires reinitialization of buffers, etc... This is very messy, programmatically....

so instead, PulseAudio controls all audio ports and dynamically mixes everything down to the appropriate targets in real time. This takes CPU time...

Further CPU time is also taken by the codecs and sinks that make up the gstreamer pipeline. Due to architectural constraints in gstreamer, there are many of these conversions (some of them are heavily duplicated) many times a second...this can be made more efficient...this is clerical work that must be done alongside architectural refinement (not an easy task, but not insurmountable either)...

couple this with the fact that there are many processes running at different times (the tracker indexer is a good example of I/O suckage that happens at odd times), and that accesses to hardware drivers often pre-empt the kernel (the kernel in maemo is preemptive, this means that accesses to hardware have the capability to temporarily pre-empt, that is, suspend, kernel code so that they can quickly access the hardware, this can temporarily suspend the scheduler for short periods of time so that processes aren't running...), you have situations where a lot of things need to be optimized...

...this will happen...but it will take those of us who are willing to help out to make it happen...not just for coding, but for reporting bugs, etc...

things that will help this situation:

(1) make pulseaudio be nicer on hardware device accesses
(2) make other processes be nicer on the CPU (particularly in minimizing the I/O access, so that iowait can be brought to a minimum.. I/O in embedded devices is a premium resource which must be carefully rationed)
(3) optimized CODECs...while some of the shipped codecs use DSP calls to the OMAP's TI DSP, some don't, and these need to be rewritten to do so. If you install a community compiled gstreamer plugin, there is a chance it will not use the DSP.
(4) make gstreamer as a whole more efficient when doing things like memory copies (critical for moving data between sinks), and minimize the number of conversions needed between sinks.

those are just a few examples,
again, don't worry, it will get there...just understand that quite a bit of these improvements won't come from Nokia, but from the open source community at large.

-Thom