FS#11907 - Annoying flash memory access noise with Sansa Clip+

Attached to Project: Rockbox
Opened by Gugel Bod (googlebot) - Wednesday, 26 January 2011, 21:17 GMT
Last edited by MichaelGiacomelli (saratoga) - Sunday, 07 August 2011, 19:46 GMT
Task Type Bugs
Category Drivers
Status New
Assigned To No-one
Operating System Sansa AMSv2
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


Problem found in versions r29044-110113 to r29143-110126. I could not test 3.7.1, because it did not recognize my 16 GB Transcend flash card (fixed in above versions).

At the beginning of tracks and during rebuffering of longer tracks there is a short humming sound (like a bumblebee) mixed with a fast sequence of random high frequency tones. The sound differs as a function of data format and content. It is very homogeneous with WAV tracks (only humming) and different with lossy and lossless codecs. The same file encoded with FLAC and AAC leads to different short distortions. It is only audible for tracks with initial silence or very dynamic content, for example classical music with quiet passages or audio books. With sensitive headphones, this can be quite annoying.

The original firmware does not show this behavior!

It only happens while reading from the SD card, not from the internal storage.

Initially I thought this might be a CPU throttling issue. But now I think it might also be related to the controller driver.

There is a thread on Hydrogenaudio with independent confirmations of the issue:

If I can provide any additional information to help, please let me know.
This task depends upon

Comment by sideral (sideral) - Monday, 31 January 2011, 20:45 GMT
This issue is related to FS#11915, ClipV2 background noise, but differs in that the other problem also occurs when there is no SD activity.

BTW, I think that the theory someone had in the forum thread posted above that this could be fixed with proper pre/post-DAC volume settings is quite unlikely in case the noise persists when audio is muted. Playing with the various volume settings certainly did not help with FS#11915.
Comment by sideral (sideral) - Monday, 31 January 2011, 20:45 GMT
BTW, could you please dump your audio settings using the patch posted in FS#11915? Thanks.
Comment by James Duley (jdc) - Monday, 31 January 2011, 21:58 GMT
could this be related to squeak I and others hear while pausing/unpausing and  FS#11812  (ignore the stuff about damaging headphones, It could only happen if you were swapping from high to low impeadance headphones while paused). Also another thing I noticed is that rockbox randomly skips songs (don't know if it's related though), others have noticed it too
Comment by sideral (sideral) - Tuesday, 01 February 2011, 07:57 GMT
jdc writes:
> could this be related to squeak I and others hear while
> pausing/unpausing and  FS#11812  [...]

Possibly, but I doubt it.

> Also another thing I noticed is that rockbox randomly skips songs
> (don't know if it's related though), others have noticed it too [...]

This likely is an unrelated problem that's tracked as  FS#11501 .
Comment by Gugel Bod (googlebot) - Saturday, 05 February 2011, 17:12 GMT
I have built the latest snapshot with the patch posted in FS#11915. There is an additional Debug entry now, but it does not write a log file. Do I have to touch a file before it gets written?
Comment by Gugel Bod (googlebot) - Saturday, 05 February 2011, 18:41 GMT
I have found it out myself. For reference: To enable logging choose "(A)dvanced" -> "(L)ogf" in the ./configure dialog.

Here is the requested information:

AS3514[0] = 39
AS3514[1] = 39
AS3514[2] = A
AS3514[3] = 4A
AS3514[4] = 0
AS3514[5] = 0
AS3514[6] = 0
AS3514[7] = 80
AS3514[8] = 0
AS3514[9] = 0
AS3514[A] = 5B
AS3514[B] = 1B
AS3514[C] = 0
AS3514[D] = 0
AS3514[E] = 1B
AS3514[F] = 3B
AS3514[10] = 0
AS3514[11] = 0
AS3514[12] = 0
AS3514[13] = 0
AS3514[14] = 60
AS3514[15] = 0
AS3514[16] = 1
Comment by Gugel Bod (googlebot) - Saturday, 05 February 2011, 18:47 GMT
Additional information: Different volume settings do not have any effect on the error. In fact, turning the volume down to zero and then skipping through a playlist is the best method to definitely hear it.
Comment by Gugel Bod (googlebot) - Saturday, 05 February 2011, 19:04 GMT
Regarding reads from internal storage: There is also a noise of comparable character, but not identical, and MUCH quieter at track starts and during rebuffering. It is below what I consider annoying and also not related to the volume setting. The noise during reads from the SD card is much louder and contains additional "chopped" sequences of tones.

The original firmware is free from both types of errors.
Comment by sideral (sideral) - Monday, 07 February 2011, 14:04 GMT
googlebot, Thanks for dumping your audio settings! I've looked through them and did not find anything suspicious in them. Also, the registers do not differ from the settings on the ClipV2, meaning that the difference in faulty behavior (background noise during playback when _not_ rebuffering) cannot be attributed to the audio registers.

My current theory for the ClipV2 noise is that it is cause by a power-management misconfiguration. As soon as I find some time, I'll post to FS#11915 an updated debug patch that will also dump the power-management settings. Could you do me a favor and subscribe to ("watch") that other item as well and rerun the debug test when that patch becomes available?
Comment by Gugel Bod (googlebot) - Monday, 07 February 2011, 22:54 GMT

I'm also willing to contribute code, but what kind of SoC is a "20-82-00196-4 : S927-792047 : SA0342-8"? Is there any documentation? And where is even documented that the Clip+ has got an AS3514?
Comment by sideral (sideral) - Tuesday, 08 February 2011, 14:10 GMT
According to the Clip+ (like the ClipV2 and the FuzeV2) has an AS3525v2 SoC, for which litte public information seems to be available.

The audio / power management part of that chip seems to correspond to the AS3543, which is similar enough to the AS3514 that they share a common driver in Rockbox (as3514.c). The datasheet for the AS3543 is not publicly available, but AMS has been nice enough to share it with the Rockbox project. To get access to it, you need to utter the relevant magic incantations on #rockbox.
Comment by sideral (sideral) - Wednesday, 16 February 2011, 23:24 GMT
googlebot, I've updated the register-dump patch in FS#11915, and I'd appreciate if you could dump your settings again with it and post them there.

Also, just for the record: Which variant of the Clip+ do you have? The hardware-info debug screen should report a AMSv2 variant ID under "submodel".
Comment by sideral (sideral) - Monday, 14 March 2011, 13:28 GMT
  • Field changed: Status (Unconfirmed → New)
I've now had the chance of reproducing this bug on a Clip+, and now I understand what you mean by “annoying CPU noise”. It's as if the data was read from an Atari 1050 disk drive. :-)

The noise when accessing the external SD card is much more pronounced than the ClipV2 background noise reported in FS#11915.

googlebot, I have an experimental patch that allows compiling in various AS3543 settings. I have now attached this patch to FS#11915 (for which I originally used it). I actually don't expect the AS3543 configuration to be at fault, but it would be nice if someone could verify this using the various options offered by this patch (see the various commented-out lines in audiohw_preinit). I won't have time in the near future to experiment with the Clip+, but if you'd like to play with it a bit, please go ahead.
Comment by Bertrik Sikken (bertrik) - Saturday, 26 March 2011, 10:37 GMT
sideral, while looking into the problem of certain high-capacity/high-speed uSD cards not getting recognised, I noticed that we always try to put sd cards into high-speed. This is currently of no use, since we don't switch the sd controller into high-speed too. However, enabling the high-speed mode may cause the sd card to use higher current to drive the sd card data lines (driving them harder to meet high-speed timing). I think this can be a cause of more intense audio interference.
Perhaps you can relate the intensity of the interference between different cards by looking in the disk info debug menu: I expect more interference from cards in 50 Mb/s mode than in 25 Mb/s mode.
Comment by sideral (sideral) - Saturday, 09 April 2011, 22:07 GMT
Bertrik, with the recent change to not enable high-speed mode for SD cards, the noise when accessing the external SD card indeed seems to have been reduced dramatically. Unfortunately I can't compare this on the Clip+ I originally used (it was broken and had to be replaced), but on my new Clip+ the noise is barely audible any more.
Comment by Bertrik Sikken (bertrik) - Thursday, 09 June 2011, 18:26 GMT
Attached is a patch as an attempt to further reduce the interference.

The patch removes the sd_enable function in the sd card driver. This function disabled the sd controller when no access is going on. The sd controller already has a mechanism to stop the clock towards the sd card (but this used to contain a bug), so completely disabling the sd controller might not be needed anymore. It is possible that it may have contributed to the interference.
Comment by MichaelGiacomelli (saratoga) - Sunday, 07 August 2011, 20:16 GMT
Someone HA provided recordings of the noise, and its very similar to the SD access noise on the e200v1, and indeed only occurs during disk access. The OF also has the same problem, however it appears to buffer only very small amounts of audio at a time, and so it has more a continuous chirping rather then sudden but infrequent pulses.

The above patch was reported not to help. Judging from the audio recordings, it sounds like the noise isn't an abrupt pulse from enabling the SD controller, but a continuous lower frequency ringing sound (probably harmonically related to the SD clock or transfer rate). This would make sense, since the noise continues as long as the transfer is goes, not just when it begins.

Interestingly, both firmwares have a strong harmonic at about 17.9kHz, which is probably unrelated to the SD noise and unnoticed due to its high frequency. The main difference is just that the Sandisk firmware seems to spread the noise out over a wider band. With this in mind I'm not really sure what we can do about the problem. Its clearly a hardware defect on some subset of players. Optimizing SD transfers might make the noise less noticeable by reducing its duration, and adjusting the SD clock slightly might shift it to a less noticeable part of the spectrum, but I doubt we can make it go away entirely.
Comment by Random Guy (Rezal) - Saturday, 20 August 2011, 15:51 GMT
With an SD card inserted, there is much more noise from internal memory than from the SD card. Without an SD card, noise from internal memory is much lower, about as low as from external memory.
Comment by Tigran Ghardashyan (Brain_Damage) - Tuesday, 18 October 2011, 19:43 GMT
It's strange.... I have 32 and 16 gig 4 and 2 class SanDisk cards. On the first this annoying appears every time when disk access is present. On the second one - no. Is this the sound of voltage when accessing to disk ( it is sounding pretty much like that )? Is there an option to control the voltage? On the original firmware there is no noise.