[LAD] Meego pulseaudio "compliance" and "enforcement" (was Re: [Meego-handset] Enabling Speakerphone)

[Stefan Kost]

Am 04.02.2011 02:11, schrieb Niels Mayer:
> On Wed, Feb 2, 2011 at 12:48 PM, Stefan Kost <ensonic at hora-obscura.de
> <mailto:ensonic at hora-obscura.de>> wrote:
> 
>     Sorry for the very late reply. One thing to mention is that the CPU load for
>     pulse is going wown quite a bit when plugin headphones. Otherwise it runs some
>     extra processing needed to accomodate the speakers.
> 
> 
> Since there is a lot of extra audio processing going on, would employing a
> library like "nova-simd", announced below, help out with the situation -- e.g.
> writing the handset speaker-equalization and some of the audio mixing
> functionality using more efficient instructions? What looks interesting is the
> claimed support for both ARM Neon, Altivec, and  Atom: See
> http://tim.klingt.org/code/projects/nova-simd/repository and forwarded
> announcement below.

Interesting. Need to take a closer look. Please note that pulseaudio is written
in C. Orc might be better suitable for PA also.

Stefan

> 
> ....
> 
> Regarding pulseaudio,
> in http://code.google.com/p/ytd-meego/wiki/CitizenJournalismWithYoutubeDirectForMeego#Pulseaudio:_Connecting_Audio_Subsystem,_Microphone_and_Speakers -- Note
> all the "ins and outs" back and forth between kernel and user space.
> 
> Architecturally, the system seems inverted, especially since you have to go back
> out to ALSA for bluetooth. Why not keep it all in kernel space?? 
> 
> Or better yet: employ analog mixing and multiple DAC's -- only one or two
> needing to be "hi-fi" and the others for notifications and telephony can be
> quite cheap low-rate, low-accuracy DAC's and ADC's. Yes analog mixing and
> routing is hard to do in a mixed signal environment; but is the power
> consumption of a few DACs and op-amps even close to that of needing a  fraction
> of the CPU running constantly just to do what a few resistors and an op-amp can
> do? To say nothing about the potential sound quality improvement of not needing
> to resample any of the mixed outputs, nor worry about synchronizing or locking
> rates between different subsystems, and all the other benefits of analog
> summing: http://emusician.com/mag/emusic_sum_tracks/ ...  (hopefully the
> flamewars that will ensue about this controversial topic will cancel out the
> flamewars on pulseaudio  :-) ) .
> 
> What I'm proposing for the low-power/handset world isn't that far off from the
> audio system needed  back when CPU's had computational power that made digital
> mixing for notifications, telephony, or music playback unthinkable: the analog
> mixing built into the http://en.wikipedia.org/wiki/AC'97
> <http://en.wikipedia.org/wiki/AC'97> spec (and associated hardware), but updated
> for the handset world. I'm sure that's not going to happen anytime soon, but I
> can dream?
> 
> ...........
> 
> Anyways, here's the announcement:
> 
>  http://music.columbia.edu/pipermail/andraudio/2011-February/000098.html
> ......................
> [andraudio] nova-simd suite updated for arm neon
> Dan Stowell
> Thu Feb 3 04:48:36 EST 2011
> 
> Hi -
> 
> "nova-simd" is a C++ header-only template library for taking advantage
> of SIMD instructions in the kind of DSP processes used in audio
> processing (i.e. not just basic stuff like vectorised mul+add and loop
> unrolling, but also some more audio-specific things like ramps,
> distortions).
> 
> It's created by Tim Blechmann and it lives here:
> http://tim.klingt.org/code/projects/nova-simd/repository
> 
> It was originally implemented for SSE and SSE2 - we use it in
> SuperCollider and it gives us massive performance improvements on
> intel chips. We've just added NEON (and Altivec) implementations too,
> so we should be able to boost performance on android and ios.
> 
> The ARM NEON support is new and doesn't yet implement all the
> speedups, but should be useful for anyone wanting to implement C++ DSP
> for Android devices with SIMD speedups - especially if you're thinking
> about cross-platform code since the API is implemented for other chips
> too.
> 
> Dan
> .................
> 
> Niels
> http://nielsmayer.com