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

Rockbox mail archive

Subject: Re: Rockbox software volume control

Re: Rockbox software volume control

From: Jeff Goode <>
Date: Mon, 25 Jan 2010 22:33:20 -0500

On 1/25/2010 18:05, Maurus Cuelenaere wrote:
> Hi,
> I currently don't have a lot of Rockbox time (exams), but decreasing
> the delay when changing volume on the Onda VX747/VX777 has been a much
> asked feature (+ I'm personally annoyed by it).
> The Ingenic Jz4740 doesn't have hardware volume control in the audio
> chip, hence the need for a software-based one. I have currently
> implemented this by adding another parameter in the DSP (grep
> HAVE_SW_VOLUME_CONTROL apps/dsp.c), but this results in a (pretty
> long) delay when changing volume.
> AFAICS this can be resolved by decreasing the DSP buffer size, but I'm
> guessing that isn't a proper solution. Perhaps this can be solved in
> an other way that I missed, any ideas?
> Thanks,
> Maurus Cuelenaere
Hi Maurus,

You *can* do this in DSP but it isn't going to be very responsive.
Currently the only way to decrease response time is to set the PCM
buffer to low latency. This is what allows quicker response time in the
sound settings menus and whatnot. The drawback is that usually low
latency is set upon entering the menu(which gives the buffer a chance to
empty out), not when changing a particular setting, so you won't get the
benefit of low latency response if you just change the volume in the WPS
screen. You *would* get the benefit if you changed the volume in the
menu. Changing to low latency just for each incremental volume change
in the WPS wouldn't help since low latency adjusts how much data is
allowed to enter the buffer and when, not its size. So it would still
have to eat all the data currently in the buffer before getting to the
volume change, which is the same behavior you'd get if you didn't bother
with low latency at all.

If you want something close to instantaneous volume changes you probably
ought change the hardware driver of the affected targets to simulate
hardware behavior by adjusting volume of the PCM samples themselves on
the fly as they're fed to the DMA. That's after the PCM buffer serves
the data to the driver but just before the data is pointed out for DMA
playback. That would hold response time down to the length of the DMA
packet itself, which is as close to instantaneous as you're going to get.

Received on 2010-01-26

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy