Rockbox

  • Status Closed
  • Percent Complete
    0%
  • Task Type Patches
  • Category Music playback
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Version 3.3
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Blue_Dude - 2009-06-23
Last edited by mikaelh - 2009-07-30

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

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.

Closed by  mikaelh
2009-07-30 17:52
Reason for closing:  Duplicate
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

closed by jeffrey's request, this code is incorporated in #10199 now.

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.

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...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing