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

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


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.
This task depends upon

Closed by  Mikael Magnusson (mikaelh)
Thursday, 30 July 2009, 17:52 GMT
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, 11:56 GMT
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, 14:29 GMT
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.