• Status New
  • Percent Complete
  • 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 googlebot - 2011-01-26
Last edited by saratoga - 2011-08-07

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

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 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.

BTW, could you please dump your audio settings using the patch posted in FS#11915? Thanks.

jdc commented on 2011-01-31 21:58

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

could this be related to squeak I and others hear
pausing/unpausing and  FS#11812  [...]

Possibly, but I doubt it.

Also another thing I noticed is that rockbox randomly skips
(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 .

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?

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] =
= 1

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.

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.

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?


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?

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.

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”.

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.

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
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.

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.

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.

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.

Rezal commented on 2011-08-20 15:51

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.

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.

ok commented on 2014-09-28 12:45

I have an example record of a track change here (16 sec, track changes at the middle), on the original firmware of my clip+ and Rockbox 3.13 on the same hardware.

Note a high-pitched sound on the Rockbox version about 2-3 seconds before the track changes.

I’ll also include ffplay’s spectrograms for the files and Rockbox config.

ok commented on 2014-09-28 13:56

Here’s the same test with the files played on an µSD card, again, with the same Sansa Clip+.
The constant noise I saw (did not hear, however) was not there anymore, but the “I/O operation -sound” on the Rockbox version was still there, just as loud as before.

I’ll include 16 seconds of sox-synthesised sound with clean 1kHz, 5kHz, 10kHz and 15kHz sine waves and its spectrogram to ease guessing frequencies from the spectrograms.


Available keyboard shortcuts


Task Details

Task Editing