Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#10375 - Adds lookahead/attack buffer for DSP functions

Attached to Project: Rockbox
Opened by Jeffrey Goode (Blue_Dude) - Tuesday, 23 June 2009, 19:21 GMT+2
Last edited by Mikael Magnusson (mikaelh) - Thursday, 30 July 2009, 19:52 GMT+2
Task Type Patches
Category Music playback
Status Closed
Assigned To No-one
Player Type All players
Severity Low
Priority Normal
Reported Version Version 3.3
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Private No

Details

This patch adds a lookahead, or attack, buffer for DSP functions. It is transparent to normal operation, as it just passes through samples being processed. But it provides the ability for a DSP process to look ahead at future samples before processing current ones. Currently the buffer size is set to 512 samples, or 4 KiB, which is sufficient for a little over 11ms of attack time. The size of the buffer is set with a #define in dsp.h.

This patch has a little too much white space in dsp.c, where I pulled out some unrelated code. Also included is a minor fix to a logf statement in pcmbuf.c. It only avoids a compiler warning.
   attack.patch (15.1 KiB) 
 apps/pcmbuf.c                          |   22 ++
 apps/plugins/mpegplayer/audio_thread.c |    2 
 apps/dsp.c                             |  257 +++++++++++++++++++++++++++++----
 apps/dsp.h                             |   13 +
 4 files changed, 266 insertions(+), 28 deletions(-)

This task depends upon

Closed by  Mikael Magnusson (mikaelh)
Thursday, 30 July 2009, 19:52 GMT+2
Reason for closing:  Duplicate
Additional comments about closing:  closed by jeffrey's request, this code is incorporated in #10199 now.
Comment by Thom Johansen (preglow) - Wednesday, 24 June 2009, 13:56 GMT+2
This seems like an odd thing to implement to me. Do you have anything in mind for which this will be used? I guess the time stretcher can be re-coded to use this, but apart from that, I can't think of many effects that need large look-aheads.
And BTW, I see you convert some "while {}" loops to "do {} while" loops. Are you certain the number of samples is always non-zero? I distinctly remember this wasn't always the case in the past when using the resampler.
Comment by Jeffrey Goode (Blue_Dude) - Wednesday, 24 June 2009, 16:29 GMT+2
Yes, I have something specific in mind.  FS#10199  is a limiter that needs to look ahead a few milliseconds to gradually reduce peaks instead of crushing them as they appear. This greatly reduces distortion. Instead of implementing a private buffer, I created a more general solution in case someone else wants to use it. The 4 KiB memory cost is the same either way.

I think you have the loop change backwards. I actually converted the "do {} while" loops to "while {}" loops. Just as you say, I'm not 100% sure that no zero sample chunks could get through, so I put in a defense. I don't think any of my changes would cause any zero sample chunks to get through, but you never know if another process might.

Loading...