This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#11915 - Background noise with Sansa ClipV2
Attached to Project:
Rockbox
Opened by sideral (sideral) - Monday, 31 January 2011, 21:37 GMT+2
Last edited by Andree Buschmann (Buschel) - Thursday, 05 May 2011, 08:24 GMT+2
Opened by sideral (sideral) - Monday, 31 January 2011, 21:37 GMT+2
Last edited by Andree Buschmann (Buschel) - Thursday, 05 May 2011, 08:24 GMT+2
|
Details[EDIT: Attached patch for experimenting with AS3543 settings.]
When playing back audio on a Sansa ClipV2 player, there is a regular background noise that's audible with sensitive headphones and that's quite annoying during quite music passages. The background noise is a hissing sound that repeats about 4 times per second. The noise can be heard when there is no disk activity and even at very low volume or when playback is muted. It stops as soon as audio is paused. The noise is not present in the original firmware (OF). This is a long-known issue, but hasn't been formally tracked before. It is related to FS#11907, but different in that the background noise is present when there's no disk (SD) activity. However, I did have the impression that disk activity intensifies the noise. This item serves to collect the various approaches people have tried to eliminate the noise, and ideas for future exploration. I ran a series of experiments on the assumption that the audio hardware is misconfigured is some way. I worked through various settings of the AS3543 component based on its datasheet. Here is what I have tried; but nothing helped to eliminate the noise: * Higher-quality audio settings as proposed in * Disabled DAC gain control (AUDIOSET1_DAC_GAIN_on) * Bypassed mixer and disabled mixer gain control (HPH_OUT_R_HP_OUT_DAC, AUDIOSET2_AGC_off, AUDIOSET2_SUM_off) * Mute SDI data (AUDIOSET1_SDI_MUTE) * Enable and control DAC attenuation (AS3543_DAC_ATTEN_on) * Disable common mode buffer (phantom ground) (AUDIOSET3_HPCM_on) * Disabled various unused mixer components (AUDIOSET3_MICMIX_off, AUDIOSET3_ADCMIX_off, AUDIOSET3_LINMIX_off) * Used external clock source for DAC (AS3543_DAC_EXT_MCLK) * Enable headphone detection (HPH_OUT_L_HP_DET_ON) * Resetting all reserved audio registers to 0 [EDIT: I have attached a patch that allows experimenting with these settings by uncommenting the relevant source lines at compile time or extending the provided debug function to toggle the setting at run time.] Possible next steps (suggested by various people on IRC): * As the noise is not present on the other AMSv2 targets (Clip+, FuzeV2), a dump of the AS3543 settings (as3514_regs[] array) on these targets would be helpful. I have attached a patch that adds a debug-menu function for doing this (needs a logf build). * Someone with a JTAG could read the AS3543 configuration set by the OF. * The issue could be unrelated to the AS3543; it could be a power-management or frequency-scaling issue. Also attached: A dump of as3514_regs[] (logf.txt; all values in hex). [EDIT: I've removed the patch to dump these settings; see a later comment in this task for a more up-to-date patch to do this.] Other ideas? |
This task depends upon
Following up on the power-management theory, I noticed that the AS3543 (like the AS3514 used in AMSv1) supports a DCDC mode known as “current force” or “pulse skip” mode which is less efficient but also less noisy. The AS3514 datasheet advertises this mode for improving the quality during audio or RF playback. I don't know what the DCDC converter is used for in the AMSv2, but if it is used, it may well be the source of the background noise.
Unfortunately, I don't know how to enable current force mode. The datasheet for AS3514 has a specific bit toggle for it, but I couldn't find the equivalent setting for the AS3543.
Also, in the audio-register dump I noticed that the initialization code lacks a call to audiohw_set_monitor(false) (leaving the line-in inputs enabled until monitoring was disabled explicitly after leaving FM radio/microphone monitoring). Unfortunately, this wasn't the cause of the background noise either. I may submit fixes for this and other oddities I encountered during my code review and my experiments separately later.
Following up on the power-management theory, I'll update my patch to also dump the power-management settings as soon as I find the time. Could you please rerun the test once I've made the new debug patch available?
Thanks for trying to fix this, it's really annoying.
I'm also attaching the settings dumped on my Clip v2. I haven't perused them in detail yet; I'll do that when I have someone else's dump for comparison.
Unrelated: I think I have a fix for that skip thing but it requires radical surgery.
The configurations of all AMSv2 platforms are largely equivalent, with one exception: The FuzeV2 systems select current feedback mode in DCDC15 (with an appropriate value in ISINK1), where the Clips have set voltage feedback mode. This setting seems to be related to the backlight / OLED brightness. Unfortunately, switching my ClipV2 to the FuzeV2 mode (current feedback) does not have any effect on the background noise.
I conclude (for now) that the audio and power-management settings of the AS3543 component (that I have documentation for) do not seem to have an effect on the background noise.
On another tangent, I have tried disabling the SD low-power mode, under the theory that SD voltage instability may have an effect on the noise, as the noise is pronounced when the SD is accessed (and, on the Clip+, is audible only in this case; see FS#11907) [1]. This didn't have an effect on the background noise either.
Another theory that was mentioned on IRC was that some clock frequency was misconfigured, possibly the CPU or the I2C clock. I haven't yet looked into this idea with any depth.
Footnote:
[1] I disabled the MCI_CLKENA |= 1<<(16+drive).
> I have noticed that - when playback is paused - scrolling the volume
> up causes some kind of noise, directly correlated with the speed of
> the wheel movement. I don't know if that has any correlation with your
> problem though.
I don't think this problem is related. The clicks when changing the volume are more likely an artifact of another issue, tracked as
FS#11812: The headphone output seems to have a nonzero voltage when paused, and I guess that this voltage changes as you change the volume. (I'll ask for confirmation over inFS#11812.)[EDIT: confirmed.]
Confirmation from anyone?
Still present in latest SVN for me.
A Clip+ does not show this problem - but i guess
that model was never affected by this bug.
Whenever something happens on the screen, there is a corresponding sound.
If a title is too long and starts scrolling.... a new "wrapping" sound appears.
When I press the home button during playback, the sound disappears (of course the intermitting sound from SD access is still there).
Idea: Can someone provide a patch to force the interrupts to be a little bit longer than needed (just add some waits) to see if that produces more sound noise ?
I found it is volume dependent: When playing a quiet music passage at high gain, the noise does not become louder, but is gone.
Probably the audio samples decoded from the mp3 are multiplied (in software) by a gain value for volume control before being sent to the audio DAC.
Does anyone know whether it is a sigma delta DAC? These might require different settings for low volume output.