Rockbox

Tasklist

FS#7286 - correct DC-bias for output signals (dsp, test_codec)

Attached to Project: Rockbox
Opened by Andree Buschmann (Buschel) - Sunday, 10 June 2007, 16:49 GMT
Last edited by Thom Johansen (preglow) - Wednesday, 29 August 2007, 14:33 GMT
Task Type Patches
Category Music playback
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

This patch corrects the DC-bias of the PCM-signal ouput. I came around this issue when working on accuracy comparison between rockbox and reference decoder for musepack.
In trunk all signals will have DC-bias of -1/65536 which is cause by truncation of samples with more than 16 significant bits. Solution is to add 1<<(scale-1) before doing the >>scale shift.
The patch is available for apps/plugins/test_codec.c and apps/dsp.c. For this reason the patch is not available for coldfire targets as these use assembler code and not the changed c-code.
   dc_bias_dsp.patch (1.4 KiB)
   dc_bias_testcodec.patch (1.8 KiB)
This task depends upon

Closed by  Thom Johansen (preglow)
Wednesday, 29 August 2007, 14:33 GMT
Reason for closing:  Accepted
Comment by Michael Sevakis (MikeS) - Wednesday, 13 June 2007, 23:01 GMT
Actually I did have coldfire in emac signed integer rounding mode at the final output stage (it uses emac to scale and perform clipping at once) but really don't think this tiny DC bias is much of a concern for playback so I just used signed int mode. All that's needed it to set the rounding flag back again and I guess it's for free anyway. Also, I was getting a head for implementing a lot of ARM dsp in assembly to see if it helps things which with careful attention to avoid memory stalls, it should.
Comment by Andree Buschmann (Buschel) - Thursday, 14 June 2007, 06:10 GMT
When comparing a reference decoded signal with the rockbox-output (unpatched), you will see, that there are two issues
a) DC-offset by small amount
b) white quantization noise at about -93dB average.

When using the DC-offset (which is nothing but rounding instead of truncating), the DC-offset has gone and the quantization
noise compared to reference decoder is about -107dB in average.

As all audio outputs are influenced, and if we're talking of high precision audio output, we should correct this last stage.
Comment by Michael Sevakis (MikeS) - Thursday, 14 June 2007, 07:34 GMT
On coldfire, it's multiplying by 2^(16-scale) to cause anything > 0x7fff or < -0x8000 to get saturated by hardware and then taking the most significant 16 bits for the output sample. As a result hardware rounding won't help for it (I just realized). But, it's just a matter of initializing the accumulators with 2^15 to have it perform essentially (2^(16-scale) * decoder_sample + 2^15) / (2^16) = output_sample. I think I reasoned that out correctly but I'm tired. :P
Comment by Andree Buschmann (Buschel) - Thursday, 14 June 2007, 15:55 GMT
As far as I understand the Coldfire solution, initializing accumulators with 2^15 is exactly what we need here.
Can you add such solution to this patch?
Comment by Michael Sevakis (MikeS) - Friday, 15 June 2007, 02:00 GMT
This adds the solution to the Colfire assembly in the output routines. No runtime comparisons performed however.
   dc_bias_dsp2.patch (8.3 KiB)
Comment by Andree Buschmann (Buschel) - Tuesday, 19 June 2007, 18:52 GMT
Merged all patches and diff'ed against current trunk (rev xyz). Now the final output stage (either dsp or test_codec) use same and correct rounding instead of simple truncation for all targets. This will give another few dB's in accuray and lower the quantization noise.
No runtime comparisons performed, nevertheless any effect in runtime should at least be irrelevant (for stereo, 44.1kHz -> additional 88200 adds/sec).
   dc_bias_v1.patch (10.1 KiB)
Comment by Andree Buschmann (Buschel) - Thursday, 02 August 2007, 18:22 GMT
Sync'ed against 14147
Comment by Andree Buschmann (Buschel) - Thursday, 02 August 2007, 18:23 GMT
Oops, now with patch file. Sync'ed against 14147
   dc_bias_v2.patch (10.1 KiB)
Comment by Matt M (Chesteta) - Wednesday, 08 August 2007, 05:56 GMT
I still recieve an error saying

$ patch -p0 < dc_bias_v2.patch
patching file apps/dsp_cf.S
patching file apps/plugins/test_codec.c
patching file apps/dsp.c
patch unexpectedly ends in middle of line

IDK what to do about this...
Comment by Andree Buschmann (Buschel) - Thursday, 09 August 2007, 19:21 GMT
Corrected. New line was missing at the end of file.
   dc_bias_v3.patch (10.1 KiB)
Comment by Thom Johansen (preglow) - Friday, 24 August 2007, 10:37 GMT
Looks to me like the dithering routine already has bias applied, and now gets it applied twice. Or do you see some issue here I don't see? I'll commit this soon.
Comment by Michael Sevakis (MikeS) - Saturday, 25 August 2007, 04:06 GMT
Dithering routines remove bias because they spead the quantization errors across samples, correct? I think I agree that the dither output shouldn't have additional rounding.
Comment by Andree Buschmann (Buschel) - Saturday, 25 August 2007, 10:02 GMT
Reviewed the changes again. Now I am also not too sure about the correctness of adding the dc_bias while dithering. The error-feedback is calculated from "output &= ~mask" (which is "(output>>scale)<<scale"). The additional dc_bias would therefor lead to false error-feedback.
Should have taken a deeper look into it before submitting this patch...
Comment by Thom Johansen (preglow) - Tuesday, 28 August 2007, 20:59 GMT
Any new thoughts on the correctness of the dithering routine? If not, I'll just remove the extra bias in dithering and commit.
Comment by Andree Buschmann (Buschel) - Wednesday, 29 August 2007, 07:13 GMT
There are no new thoughts. So, commit without extra bias in dithering.

Loading...