This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#11907 - Annoying flash memory access noise with Sansa Clip+
Attached to Project:
Rockbox
Opened by Gugel Bod (googlebot) - Wednesday, 26 January 2011, 22:17 GMT+2
Last edited by MichaelGiacomelli (saratoga) - Sunday, 07 August 2011, 21:46 GMT+2
Opened by Gugel Bod (googlebot) - Wednesday, 26 January 2011, 22:17 GMT+2
Last edited by MichaelGiacomelli (saratoga) - Sunday, 07 August 2011, 21:46 GMT+2
|
DetailsProblem 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: http://www.hydrogenaudio.org/forums/index.php?showtopic=86306 If I can provide any additional information to help, please let me know. |
This task depends upon
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.
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 http://www.head-fi.org/forum/thread/479437/sansaclip-rockbox-appreciation-society/570#post_7184263> 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.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
The original firmware is free from both types of errors.
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?
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.
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".
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.
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.
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.
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.