• Status Closed
  • Percent Complete
  • 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.


Available keyboard shortcuts


Task Details

Task Editing