[pulseaudio-discuss] [PATCH 0/5] volume: Decrease PA_VOLUME_MAX to be < 2^31

Arun Raghavan arun.raghavan at collabora.co.uk
Sun Oct 10 03:22:24 PDT 2010


On Sun, 2010-10-10 at 10:19 +0200, David Henningsson wrote:
> On 2010-10-09 20:27, Arun Raghavan wrote:
> > Hey folks,
> > Here's a patchset to change PA_VOLUME_MAX to (2^31-1), which is about half its
> > current value. This really should not impact anything significantly, since the
> > maximum gain we can apply decreases from ~289 dB to ~271 dB. Why this change is
> > good is that we can significantly simplify the software volume scaling
> > arithmetic, since the volume can always be treated as a signed number.
> >
> >I am working on rewriting the volume scaling in Orc,
> 
> Could you elaborate on this? Is Orc a programming language? Are you 
> saying that native PulseAudio should only compile on compilers that have 
> "Orc" support?

Ah, sorry, I should've provided more background. Orc is a programming
language which allows you to write simple programs to optimise inner
loops that you might otherwise hand-optimise with MMX/SSE/NEON. The idea
is that you write an Orc program for the inner loop, and the Orc library
will, at runtime, generate assembly for the architecture you're running
on.

More information at http://code.entropywave.com/projects/orc/

I've actually already added some Orc optimisations to the echo
cancellation module (see src/modules/echo-cancel/adrian-aec-orc.orc)

> > and this would make that
> > considerably simpler (and more fruitful, since we'd have to jump through hoops
> > to deal with volumes>= 2^31 while doing signed multiplication). If we choose
> > to retain the old hand-optimised assembly, that should also benefit from this
> > change.
> 
> I'm not exactly sure where and for what PA_VOLUME_MAX is used, but does 
> it correspond to 0 dB in any way? Thinking assembly, could it be that we 
> have some e g fixed-point arithmetic that we must compensate?

Colin covered this already. Only thing I have to add is that the volume
is, in fact, treated as a fixed-point number with the lower 16-bits
being the fractional part.

Cheers,
Arun




More information about the pulseaudio-discuss mailing list