Rockbox

  • Status New
  • Percent Complete
    0%
  • Task Type Bugs
  • Category Drivers
  • Assigned To No-one
  • Operating System Sansa AMSv2
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by sideral - 2011-01-31
Last edited by Buschel - 2011-05-05

FS#11915 - Background noise with Sansa ClipV2

[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  FS#11304  (AUDIOSET2_HPH_QUALITY_HIGH,
Disabled DAC gain control
Bypassed mixer and disabled mixer gain control (HPH_OUT_R_HP_OUT_DAC, AUDIOSET2_AGC_off,
Mute SDI data
Enable and control DAC attenuation
Disable common mode buffer (phantom ground)
Disabled various unused mixer components (AUDIOSET3_MICMIX_off, AUDIOSET3_ADCMIX_off,
Used external clock source for DAC
Enable headphone detection
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
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?

[EDIT: Fixed first paragraph]

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.

Update: The datasheet remains rather unclear on current force mode, but one possible setting for enabling it are the CVDD{1,2}_fast bits in the DCDC_Cntr register. Unfortunately, playing with these bits did not eliminate the background noise.

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.

MikeS commented on 2011-02-03 08:25

Hot off the Fuze v2 using the above patch.

   logf.txt (0.3 KiB)

MikeS, Thank you for running the test! I’ve looked through the audio settings you dumped and could not find anything suspicious. So it’s probably not a difference in the audio settings that’s causing the ClipV2 to misbehave.

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?

lazka commented on 2011-02-08 18:58

On my clip the noise ‘frequency’ is about the same as scrolling text updates.

Thanks for trying to fix this, it’s really annoying.

As promised, here comes a patch that also dumps the power-management settings (requires a logf build). I’d be grateful if you could report the settings dumped with this patch on a Clip+ and Fuze v2. Thanks!

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.

Attached are the settings of my clip+ (AMSv2 variant 0), SVN 2932.

FuzeV2 r29322 + Rockbox USB. AMSv2 variant 0. 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.

MikeS commented on 2011-02-17 15:47

I’ll get a readout for you ASAP.

Unrelated: I think I have a fix for that skip thing but it requires radical surgery.

MikeS commented on 2011-02-17 23:16

r29321M-110217 as is from boot

Thanks to everyone who provided a readout! Here’s my analysis so far:

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.


I disabled the MCI_CLKENA |= 1«(16+drive).

Luca Leonardo Scorcia
I have noticed that - when playback is paused - scrolling the
up causes some kind of noise, directly correlated with the speed
the wheel movement. I don’t know if that has any correlation with
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 in  FS#11812 .)

[EDIT: confirmed.]

bing commented on 2011-03-02 11:07

After upgrading to Rockbox 3.8 the background noise is
from anyone?

After upgrading to Rockbox 3.8 the background noise is gone.

Still present in latest SVN for me.

ivida commented on 2011-03-04 14:35

Present on my ClipV2 with 3.8.

A Clip+ does not show this problem - but i guess that model was never affected by this bug.

heini commented on 2011-07-16 11:17

Just upgraded ym ClipV2 to 3.9, noise is still present.

Urmel commented on 2011-08-10 11:56

From what I hear, I believe the noise is related to some kind of interrupt, for example the OLED control.
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 ?

There is noise created by scrolling and other screen activity, but the noise discussed here is also present with the screen blanked.

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.

heini commented on 2012-10-16 08:28

It's been a bit quiet here. Is there any news on this issue? Would be really nice to get rid of this annoying background noise.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing