> It should have essentially zero overhead when properly configured, and > when its not doing anything fancy. I don't think these performance > problems are fundamental.
Don't think, benchmark :) There are a ton of non-obvious reasons one approach might seem just fine but really suck. (cache alignments, tlb misses, ctx switch overhead) > > > > >For power and performance reasons on a cell phone, I think anything a > >sound server does would be much better done in the kernel-level ALSA > >drivers. The only downside I can see to this approach whether the > >in-kernel bluetooth audio drivers are any good. > > > > Kernel-level software resampling should be just as expensive as > userspace resampling... Pulseaudio does seem to do some soft-realtime > stuff and adds a bit of device transparency. > > >Last I tried bluetooth-audio on my laptop I had to run a userspace > >daemon. > > I have no idea what would happen with Alsa if you tried to transfer a > call between the speaker and the bluetooth set. I think pulseaudio can > handle this sort of thing correctly. All my whining aside, seamless speaker->bluetooth handoff seems to be a 'must-have' feature. Although I would like to hear a good reason why the kernel shouldn't be in charge of that. > > > >Speaking of which.. do we have any way to measure the power consumption > >of playing a reference .ogg file without special hardware? Are the > >built-in battery charge management counters good enough? > > > > Good question. :) Also, pulseaudio may be preventing the sound card and > cpu from falling asleep, even when no sounds are being played. From > what I can tell, it's been configured to never go idle.
