After reading several positive posts around here, I replaced my venerable iPod G5 Video with a little Sansa Clip+ and a 16GB flash card. Missing AAC support was a deal breaker, but Rockbox was reported to run fine.

I must say, compared to the absolutely flawless experience with my last iPod, I'm quite dissatisfied. It started with a bug of Rockbox 3.7.1 that large SD cards are sometimes not initialized properly (and thus don't appear in the menu), which affected my Transcend model. An upgrade to the latest daily build fixed this.

An issue, that I can't fix with whatever build, is annoying CPU noise. 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. The original firmware does not show this behavior. It is probably a throttling issue. Rockbox just reads and decodes the file in a regular loop as fast as the CPU can deliver it. Due to cheap hardware design this leads to audible inference on the output. The original firmware probably works around this by some form of flow control and doesn't read the data any faster than required. But, as I've said, due to missing AAC support the original firmware is not an option.

The phenomenon is only audible with my headphones. The Creative EP-630 have a rather large sensitivity of 106 dB. I tried to record the distortion over a line-input and it is non-existent there. That made me think about the common practice of shutting people up with RMAA results or telling them that what they hear must be placebo. High-impedance, line-level inputs do not necessarily capture the same as what a sensitive headphone outputs.

Can anyone, who also owns sensitive earphones, recommend a comparable player (no video, real buttons) with flawless output? It would be nice if I could re-use the SD-card.

As I have written, my ALC889's line-in is not sensitive enough to capture the noise. I guess the Clip+ drives it with a larger voltage than the IEMs and then its output is fine.

I have uploaded my test file. It is nothing special, you could also just create your own, a mp3 with a forced high bitrate (so that it doesn't get buffered completely), with nothing but a high pitched tone inside. Copy it several times onto the SD card (not the internal storage) and then listen while you skip between tracks. The noise you hear is the same that annoys me during playback, when the SD card is accessed for re-buffering.

Maybe NwAvGuy can repeat the recording with his much better equipment. Then we would have an example.

As I have written, my ALC889's line-in is not sensitive enough to capture the noise. I guess the Clip+ drives it with a larger voltage than the IEMs and then its output is fine.

I have uploaded my test file. It is nothing special, you could also just create your own, a mp3 with a forced high bitrate (so that it doesn't get buffered completely), with nothing but a high pitched tone inside. Copy it several times onto the SD card (not the internal storage) and then listen while you skip between tracks. The noise you hear is the same that annoys me during playback, when the SD card is accessed for re-buffering.

I don't see any need for sensitive measurements as the transients that are generated by my Clip+ with 01.02.15 firmware when I switch between 2 copies of the test file are pretty gross. The signal I record starts at the baseline, dives negative for about 50 milliseconds to an amplitude of about 20% of the test signal, bounces up for about 20 milliseconds, and then the test tone starts and its DC value starts out about 20% high and then bounces down to a nice symmetrical HF wave.

The most improtant characeristic of the test file is that it has a consdierable signal but is at such a high frequency that it can't be heard very easily.

Looks to me like the Clip's output is disconnected from the headphones when its changing files, and then gets hooked back up and there's a transient something like coupling capacitors charging up. That's odd because the performance of the Clip generally suggests that tehre are no output blocking caps. I guess the servo system that eliminates any need for them still simulates some of the odd things they might do with the power supply remoted and then applied to start playing the file.