Annoying distortion: Sansa Clip+ w/ Rockbox, Audible but not easily measurable Options

[googlebot]

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.

This post has been edited by googlebot: Jan 22 2011, 14:53

[odigg]

I think people experienced with RMAA measurements know that certain things (e.g. hiss) are easier to detect with high sensitivity headphones than with measurements. Have you tried to run the test with the Clip+ loaded with your headphones to see if that helps you detect the noise? I don't ever recall reading any thread (on many different forums) of somebody demanding an RMAA for hiss or electronic noise, so it's not always RMAA or STFU.

I have a Clip+ and have heard the noises you talked about. What's really interesting is that it seems to change between Rockbox firmware revisions. I've loaded firmware revisions where the noises are very present and irritating. The firmware I have now (which is probably 6 months old at this point) seems to basically be noise free.

Hopefully Saratoga will chime in since he's the expert.

Strangely enough, there seems to be a rather large hole between the Clip+ and the iPod. Sony has some players with buttons that are reviewed well but I don't know much about them.

This post has been edited by odigg: Jan 22 2011, 15:56

[Soap]

I believe the charge against the use of RMAA numbers is an improper one based on faulty practices:

A properly done RMAA test is performed by recording the loaded output of the player. You did not describe loading the output during your recording attempt therefore I assume you didn't.

Your recording attempt was the same as an unloaded RMAA test, a test which would be dismissed by most objectivists as being suggestive but not telling.

Use a splitter to plug in headphones to the player while at the same time feeding your sound card's line-in.

Bet you dollars to donuts you successfully capture the noise (not distortion) then.

This post has been edited by Soap: Jan 22 2011, 16:18

[googlebot]

Bet you dollars to donuts you successfully capture the noise (not distortion) then.

While loading reveals LF roll-offs and the like, which is related to output impedance, I'm not so certain that loading must reveal sensitivity related issues.

I have all necessary equipment but a spare 3,5 mm socket at hand right now. So I cannot setup a loaded test without cutting my headphone cable. A splitter might accomplish the same without soldering. But are they always just connected in parallel without additional circuitry?

PS Since the signal is highly correlated to the encoded signal, it's not necessarily false to speak of distortion instead of noise.

This post has been edited by googlebot: Jan 22 2011, 16:34

[Peter]

Just for reference: I believe I'm having a similar problem with my unit: Clip+ 8GB, Rockbox 3.7. Symptoms are pretty much what you describe, though I haven't really done any in-depth research on this. Using rather sensitive earphones too (Sennheiser CX200).

[odigg]

I have all necessary equipment but a spare 3,5 mm socket at hand right now. So I cannot setup a loaded test without cutting my headphone cable. A splitter might accomplish the same without soldering. But are they always just connected in parallel without additional circuitry?

Indeed, a splitter just splits the signal into two (parallel load). There is no additional circuitry.

[bryant]

There is a mention on this Rockbox page about annoying noise that can be heard at low volume on the Clipv2 (which seems to use the same CPU as the Clip+). Since you have sensitive headphones, I assume you are using a fairly low volume setting? Does the volume of the noise/distortion move with the volume setting, or does it seem constant?

I don’t remember off-hand whether the volume control on Rockbox is implemented digitally (before the DAC) or in the analog domain (headphone amp gain). If it’s digital, and you are using only the lower range of the volume control, you could conceivably create a custom build that had a lower headphone amp gain and then compensate with a higher volume setting. The OF may simply get around this issue by implementing the volume in the analog domain.

edit: after re-reading odigg's post I see that you might be able to find a particular revision of the firmware that does not have the problem. Of course, you would not have your SD fix then...

This post has been edited by bryant: Jan 22 2011, 20:39

[Arnold B. Kruege...]

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.

It's obviously a problem with the Rockbox software. These kind of noises are the sort of thing that programmers who pay attenation to details isolate and fix. There's nohting faulty about the Clup+ CPU - it is yet another ARM processor, a processor that is used in zillions of products with well-written software that produces no extraneous noises. Rockbox seems to be a voluteer product, and that means that they fix what they want to fix, and don't fix whatever is too much trouble for them to fix.

[probedb]

You could post on the rockbox forums, plus also raise a bug?

[odigg]

I installed the latest version of Rockbox on my Clip+ and tested it. The only consistent noise I can get is when I stop/play a song. I If If I pause and seek front/back when the song is paused the Clip+ is quiet.

Otherwise I can occasionally hear something (e.g. when I power off the Clip+) but that's about it. It's far from bothersome (for me). I am using an IEM that has, in the past, found some versions of Rockbox to be quite noisy.

Interestingly enough, I think the sounds show up in the volume meters that are there in the "DFKT Minimum Clip" theme. I can't tell for sure because starting/stopping a song happens quickly.

This post has been edited by odigg: Jan 24 2011, 21:31

[greynol]

I hope this gets fixed or Sansa implements gapless playback, otherwise no Clip+ for me. Does this happen with the non-plus version of a Rockboxed Fuze?

[2Bdecided]

Sansa implements gapless playback

I fear they think that what they've done in the Clip+ is good enough. They kept telling everyone that it was gapless. Sure enough, the big gaps are gone, but it's still not right for mp3s. Some people report that it works for FLAC. I haven't tested myself. I don't trust other people's reports!

Cheers,
David.

[Northpack]

It's obviously a problem with the Rockbox software. These kind of noises are the sort of thing that programmers who pay attenation to details isolate and fix. There's nohting faulty about the Clup+ CPU - it is yet another ARM processor, a processor that is used in zillions of products with well-written software that produces no extraneous noises. Rockbox seems to be a voluteer product, and that means that they fix what they want to fix, and don't fix whatever is too much trouble for them to fix.

I think that's not a fair assessment of the rockbox software. Indeed it is usually much better that the often buggy or feature-lacking stock firmwares it replaces. Sandisk didn't manage it so far to implement properly working gapless playback or id3v2 support. Its MP3 decoder is so inefficient that it wastes 1/3 of battery life compared to rockbox. It still has a pitch error. I wouldn't call that paying attention to the details. I guess they are rather paying attention to the economics...

This post has been edited by Northpack: Jan 25 2011, 11:17

[botface]

@googlebot

I have a Fuze v1 and have no problems at all. It's a different variant of the ARM chip to the Clip+ so that could be a factor. Also I'm still using v3.6 of Rockbox. Maybe you could try an older version if there are any that work with the Clip+

[odigg]

I hope this gets fixed or Sansa implements gapless playback, otherwise no Clip+ for me. Does this happen with the non-plus version of a Rockboxed Fuze?

I'd recommend you find some way to demo a Rockboxed Clip+ before making any conclusions about how the noises will bother you. There are plenty of people who are happy with this setup, including me. The only possible way these noises could bother me if I was starting/stopping, powering off, and doing all this stuff every 10 seconds.

Some people may be more sensitive to this than others, so I'm not saying that people shouldn't complain about it or switch to a different setup because of it.

[googlebot]

I'm pretty sure that the noise cannot be heard with most music. It's far below the average loudness of a regular music track. Sadly it's also far enough above the noise level of silence to be annoying in my major mobile use cases, classical music and audio books. My commute is quite long, I'd be really lost without it.

Besides missing gapless, id3v2, and aac support, the stock firmware also fails miserably with the audio book, I'm listening to right now: War and Peace. It cannot skip tracks on the playback screen with that many tracks. So Rockbox is my only option. I cannot go back to a later version, either, because the SD card driver was fixed after 3.7.1. I'm going to post a bug report soon. It is nice, that I can reference this thread now, for additional confirmations.

This post has been edited by googlebot: Jan 25 2011, 20:25

[Northpack]

I can hear that noise too but as long as I am not concentrating on it I hardly ever notice it. It's like my tinnitus - most time I don't notice it at all, but the more I focus on it the more annoying it becomes. Thus the most important therapy of tinnitus is psychological: learn not to concentrate on it. You could try that. Or maybe get some less sensitive phones (the EP-630 are crappy anyway, especially for classical music). The noise is much quiter with my Phonak phones when driven at the same subjective volume level as the EP-630. Plus they sound ten times better.

This post has been edited by Northpack: Jan 25 2011, 22:37

[eevan]

I can confirm that there is high noise level on Fuze v2 using CX-300 headphones. But it is a constant noise, different from what OP described. The noise is there as soon as Rockbox boots, and is pretty annoying when listening to classical music. I cannot hear it from OF.

[saratoga]

googlebot just pointed me to this thread.

I am completely unable to reproduce any noise at all on the Clip+ using EP-630s, in a quiet room, and my "silence.wav" that I used when trying to figure out where the noise on the Clipv2 comes from. I also tried normal music with the gain digitally adjusted down 30 dB. If its really so obvious for some people using these exact headphones and real music, then I suspect my player is somehow different. Sandisk has released different hardware revisions where they change minor things, and my player is the oldest revision. I'm guessing people who hear noise have bought their players more recently (IIRC the last revision showed up in July or so). Maybe they've changed something else.

[googlebot]

Which version of Rockbox are you using?

[saratoga]

r29342. But the Clip+ has been my preferred player almost since the start of the port. Its never had noise like the ClipV2 does.

[googlebot]

Very interesting! Do you have a Rockbox build environment at hand? And could you please also try a mp3 with (for you) inaudible content (like a 17 kHz tone) or something comparable? The error seems to be related to processing overhead during decoding, which is pretty flat for empty WAVs.

This post has been edited by googlebot: Mar 4 2011, 02:17

[odigg]

I'm guessing people who hear noise have bought their players more recently (IIRC the last revision showed up in July or so). Maybe they've changed something else.

I purchased my Clip+ in May 2010 from amazon. I assume amazon cycles through old/new stock pretty quickly, so it was probably manufactured not long before May. Mine has those noises as well, but not to the degree googlebot is talking about. My IEMs are slightly more sensitive (107 db/mw) than the EP-630.



This post has been edited by odigg: Mar 4 2011, 16:59

[Northpack]

For me the noise is related to SD access. It's clearly audible while the database is beeing loaded. As to be expected, it is more frequent with lossless files than with MP3. And yes, I have a more recent revision of the device. My Clip+ broke and I got a replacement last summer, which seemed a bit different. I didn't notice the noise with my original Clip+, so this supports saratoga's theory (maybe Sandisk changed the SD controller?).

This post has been edited by Northpack: Mar 4 2011, 17:50

[odigg]

For me the noise is related to SD access ... (maybe Sandisk changed the SD controller?).

I do not use an SD card in my Clip+ and still have the noises.

However, it's very possible that in the Clip+, the internal storage is accessed by the SD controller. So basically the internal memory acts as an SD card as well. This would then support your theory.

This post has been edited by odigg: Mar 4 2011, 18:39