dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Volume handling: steps and radio

Volume handling: steps and radio

From: Amaury Pouly <>
Date: Fri, 19 Jul 2013 11:35:37 +0200

Hi all,
I would like to bring back some thought on the volume handling and the

1) Handling of steps
With the recent rework of jhMikes, the internal representation of the
volume changed: now the hardware drivers also work in tenth dB
representation and this has the nasty side effect that not all values are
valid. Consider the following example (Fuze+):

AUDIOHW_SETTING(VOLUME, "dB", 1, 5,-580, 120, -250)

It means the volume ranges from -58.0 dB to 12.0 dB, with default at -25.0
dB, one digit precision and 0.5dB steps. Now consider this code in WPS
(similarly in list and radio):

    global_settings.volume ++;

This is clearly wrong: it should be incremented of 5 because the audio
settings says the hardware works with steps of 5. More precisely it should

    global_settings.volume += sound_steps(SOUND_VOLUME);

I opened a patch to fix this issue but it incomplete: it only handles the
output volume and I'm pretty sure this issue exists for recording volumes
as well. If you feel like checking all places where this could be wrong,
please help me !

2) Handling of radio volume

This is nothing new but very annoying: some targets have limited amplifying
range when routing from radio. It appears that for some chips like SI4700,
the default volume of the chip is very high and thus the SoC amplifier
cannot attenuate the volume sufficiently, resulting in the overall volume
to be very high. Example (value might be wrong): SI4700 configured with
20dB amp, imx233 amp configured at -58dB result in max attenuation of -30dB

I think the proper way to do this is to enhance the radio interface with a
volume setting. Indeed most radio tuners have a volume setting. We could
basically need to following attributes:
- volume (set/get)
- volume steps (get) [not sure it's needed]
- min/max (get)

My guess is then that each codec would have to use this interface to change
the radio volume if needed, to reach the target volume required by the
target. I'm not sure it would be possible to change this volume directly
from radio.c in a generic way. Let me know what you think ! I'm willing to
implement this but I need your feedback to avoid writing code no one agrees

Amaury Pouly
Received on 2013-07-19

Page was last modified "Mon Nov 16 10:57:21 2020" The Rockbox Crew -- Privacy Policy