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.
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.
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.
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.
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).
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.
There is a mention on this Rockbox page (http://www.rockbox.org/wiki/SansaAMS) 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...
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.
You could post on the rockbox forums, plus also raise a bug?
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.
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?
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.
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...
@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+
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.
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.
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.
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.
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.
Which version of Rockbox are you using?
r29342. But the Clip+ has been my preferred player almost since the start of the port. Its never had noise like the ClipV2 does.
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.
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.
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?).
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.
Yes, I didn't mean the external SD specifically. It doesn't make any difference whether the file is on the internal or external memory.
As I think the OP may already know, I did a full test of the Clip+ on my blog here:
Sansa Clip+ Measured (http://nwavguy.blogspot.com/2011/02/sansa-clip-measured.html)
I noticed slightly greater subjective hiss, at times, with the Rockbox firmware compared with the Sansa firmware. I also noticed a different slight noise when the display is on. I've encountered display noises with other devices as well. Could that be what at least some of you are hearing?
In terms of measurements, the Clip+ measures fairly quiet, but I only ran that test (I think) with the factory firmware. I might re-run it, if I get the chance, with the RB firmware with both the display on and off. I use a dScope audio analyzer with a noise floor below -140 dB so it should pick up *any* audible noise regardless of the type or source.
What others are calling the "CPU Noise" in this thread is likely related largely to the hardware and it's just showing up in different ways with different firmware. Put another way, I strongly doubt there's anything in the RB firmware that's actually creating a noise and sending it to the DAC. Instead, it's what's known as "EMI noise" which tiny digital audio devices are often prone to. The CPU draws spikes of current when it executes, those spikes create an electromagnetic field, and the audio circuits pick up a bit of that field. It's really hard to get rid of when you can't physically get the noisy digital stuff away from the sensitive analog stuff. I bet the tiny Apple Shuffle may have some EMI noise as well because of its size.
Given that Rockbox does a lot more than the original Sansa firmware, it's likely to load the CPU in different ways. I've written commercial embedded firmware and there are lots of different approaches to scheduling tasks, etc. And it's entirely possible the Rockbox firmware is simply hitting the CPU in ways that create a bit more audible noise.
I know one of the developers that worked on the Rockbox port to the Clip+ hangs out on AnythingButiPod so it might be worth posting this question in the appropriate forum there. He seems to know the player inside and out.
And, finally, I don't think it's entirely fair to expect a $29 player (the basic Clip+ hardware in 2 GB form) to be the equal in every way of a multi hundred dollar iPod. My iPod Touch 3G compared to the Clip+ in my review was quieter, had less distortion, etc. But, with balanced armature IEMs (which have wild impedance swings) the Clip+ actually sounds better because the iPod has a much higher output impedance that interacts in ugly ways with many headphones. I also can't clip a Touch 3G to my shirtsleeve at the gym. So they both have their strengths.
In terms of measurements, the Clip+ measures fairly quiet, but I only ran that test (I think) with the factory firmware. I might re-run it, if I get the chance, with the RB firmware with both the display on and off. I use a dScope audio analyzer with a noise floor below -140 dB so it should pick up *any* audible noise regardless of the type or source.
AFAIK the Clip+'s output was extensively tested during rockbox development and it didn't show any issues concerning distortion or noise floor. However, if only more recent hardware revisions are affected it's quite proable that noone tested an affected device.
I know one of the developers that worked on the Rockbox port to the Clip+ hangs out on AnythingButiPod so it might be worth posting this question in the appropriate forum there. He seems to know the player inside and out.
You don't have to go to the ABI forums though, saratoga hangs around here too
And, finally, I don't think it's entirely fair to expect a $29 player (the basic Clip+ hardware in 2 GB form) to be the equal in every way of a multi hundred dollar iPod.
Of course not. When it comes to Apple, I expect design and sturdy build quality. Concerning the sound quality I wouldn't expect much of a difference, as even the ICs avaiable today will always provide good enough quality if the curcuit design isn't messed up.
Btw. your measurements look well done and quite comprehensive.
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.
n 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.
Has this annoying sound ever been recorded and posted for inspection?
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 (http://www.wuala.com/u2br/HA) 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.
Maybe NwAvGuy can repeat the recording with his much better equipment. Then we would have an example.
I'll work on that. Right now I'm working on posting recorded clips of 3 different DACs to hopefully shine a little light on the manufacture's response to my NuForce uDAC-2 review. I can try for a recording and measurement of the Clip+ running the last fully released RB version. If anyone wants to be more specific about exactly
what they want recorded, and
when they want it recorded (i.e. just as the clip starts, etc.), that would be useful?
As for Saratoga, I had him confused with another user (I guess I'm on too many forums to keep everyone straight?). So yeah, there's no need to go to ABI.
I can try for a recording and measurement of the Clip+ running the last fully released RB version. If anyone wants to be more specific about exactly what they want recorded, and when they want it recorded (i.e. just as the clip starts, etc.), that would be useful?
That'd be great! Recorded should be the Clip's sound during re-buffering reads from the SD drive. If you play back the track that I have uploaded, it should happen at some point during playback, bitrate and length are sufficient. A shortcut would be putting the uploaded file several times on a SD card and record the noise during track skipping, which is nearly identical to the latter.
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 (http://www.wuala.com/u2br/HA) 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.
Heres a patched build if someone wants to try it. It tweaks a few settings to the DAC. We tested this ages ago and no one could detect any difference in output at all, but someone suggested to me that they made some difference on his new clip+ so maybe these registers somehow matter on new players:
http://duke.edu/~mgg6/rockbox/rockbox-patched.7z (http://duke.edu/~mgg6/rockbox/rockbox-patched.7z)
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.
As I have repeatedly written, I'm totally fine with the sound quality of the stock firmware, which sadly leaves a lot to be desired with regard to supported codecs (not even AAC) and suitability for large audio book playlists. The short click between track transitions on the original firmware does not bother me, it also does not occur during rebuffering. It is unrelated to the reported issue.
Heres a patched build if someone wants to try it. It tweaks a few settings to the DAC. We tested this ages ago and no one could detect any difference in output at all, but someone suggested to me that they made some difference on his new clip+ so maybe these registers somehow matter on new players:
http://duke.edu/~mgg6/rockbox/rockbox-patched.7z (http://duke.edu/~mgg6/rockbox/rockbox-patched.7z)
Great! I'll give it a try. There is also another debug build attached to my bug report, that is still waiting to be tested. I haven't found the time, yet.
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.
As I have repeatedly written, I'm totally fine with the sound quality of the stock firmware, which sadly leaves a lot to be desired with regard to supported codecs (not even AAC) and suitability for large audio book playlists. The short click between track transitions on the original firmware does not bother me, it also does not occur during rebuffering. It is unrelated to the reported issue.
What then am I supposed to be looking for?
I'm sitting here with some really great recordings of track switching - with a -107 dB noise floor.
And that is pretty interesting all by itself - between tracks the headphone jack of the Clip+ is *that* quiet.
Yes, that's impressive. If you find the time, I'd be interested in the same measurement with the Rockbox (http://www.rockbox.org)firmware.
Yes, that's impressive. If you find the time, I'd be interested in the same measurement with the Rockbox (http://www.rockbox.org)firmware.
I currently have no interest in loading my Clip+ with Rockbox. Not that I have anything against it, just that I'm really pleased with the OEM firmware.
If its not broken...
To me a lack of gapless playback = broken.
The only match, that I have found in my favorite consumer portal for the criteria "no touchscreen", "AAC support", and "user extensible storage", is this this epic design failure, the Colorfly Pocket (http://www.colorfly.eu/index_en.html). I almost spilled my dinner over my monitor.
To me a lack of gapless playback = broken.
I understand but do not share the opinion
On the Clip+/Rockbox there's a possibility to tweak the amplification between +/- 12dB:
Settings->Playback Settings->Replaygain->Pre-amp.
Maybe tweaking this can hide the noise a bit more?
Ole
On the Clip+/Rockbox there's a possibility to tweak the amplification between +/- 12dB:
Settings->Playback Settings->Replaygain->Pre-amp.
Maybe tweaking this can hide the noise a bit more?
That's just a digital volume knob, so I doubt it helps much. And it is only applied when ReplayGain is used on a file.
On the Clip+/Rockbox there's a possibility to tweak the amplification between +/- 12dB:
Settings->Playback Settings->Replaygain->Pre-amp.
Maybe tweaking this can hide the noise a bit more?
That's just a digital volume knob, so I doubt it helps much. And it is only applied when ReplayGain is used on a file.
Right - but then maybe he could use ReplayGain...
(I agree that the noise and the music might have been mixed before that, in which case it doesn't help - I don't know the inner workings of the player+software - but it's quite easy to test)
ReplayGain does DAC wise nothing different than the volume knob. So it won't help.
After looking at the code, I rather suspect it is SD controller related anyway. It is reverse engineered and full of assumptions and hacks.
Ofc that's not the developers' fault. They're doing their best to make it work often completely without any proper documentation.
You're right - just did a quick test, on my (new) Clip+ the noise level is constant (no matter what volume level is chosen) - and mostly related to 'disk' access.
I use Sennheiser CX400.
Heres a patched build if someone wants to try it. It tweaks a few settings to the DAC. We tested this ages ago and no one could detect any difference in output at all, but someone suggested to me that they made some difference on his new clip+ so maybe these registers somehow matter on new players:
http://duke.edu/~mgg6/rockbox/rockbox-patched.7z (http://duke.edu/~mgg6/rockbox/rockbox-patched.7z)
Hi Saratoga.
I finally got RB on my Clip+ thanks to the modified bootloader (my post on www.rockbox.org)
I have now started playing with it, and instantly noticed this noise issue. I have no SD card installed. On track load, and what I assume is re-buffering (playing FLAC at the moment) I get random easily audible hiss/noise.
I tried the latest stable, development and also this version, and all have the same issue. Just for your information as I couldn't see any feedback on this patched version.
Shame, as it makes listening a pain.
I should note that the original firmware ALSO has a noise issue playing. It's a bit quieter, but it's constant, almost like a helicopter in the background, making quiet passages very dirty and noisy.I'd suggest that BOTH firmwares have an issue with noise, but the OEM firmware is probably making small reads almost constantly whilst the RB firmware is reading in much larger chunks., making no noise in the mean time, but more noise when it makes a large read.
I'd imagine a lot of people are simply missing the OEM firmware noise as it's less noticable.
It's very obvious when I turn the volume off on both. The OEM noise still exists, the RB doesn't until a rebuffer.
//EDIT -- Noise also exists in both firmwares for MP3, though on the OEM it sounds different to FLAC (faster helicopter)
BTW, I'm using Jays Q-Jays headphones.
Cheers,
Kristian
PS. This isn't a TOS8 issue I don't feel. The noise is totally noticable and repeatable.
I can try and make recording of both firmwares output if needed, though I'm not sure how good they will sound on my laptop soundcard line in.
Heres a patched build if someone wants to try it. It tweaks a few settings to the DAC. We tested this ages ago and no one could detect any difference in output at all, but someone suggested to me that they made some difference on his new clip+ so maybe these registers somehow matter on new players:
http://duke.edu/~mgg6/rockbox/rockbox-patched.7z (http://duke.edu/~mgg6/rockbox/rockbox-patched.7z)
Hi Saratoga.
I finally got RB on my Clip+ thanks to the modified bootloader (my post on www.rockbox.org)
I have now started playing with it, and instantly noticed this noise issue. I have no SD card installed. On track load, and what I assume is re-buffering (playing FLAC at the moment) I get random easily audible hiss/noise.
I tried the latest stable, development and also this version, and all have the same issue. Just for your information as I couldn't see any feedback on this patched version.
You can also try the patch from googlebot's bug report:
http://www.rockbox.org/tracker/task/11907 (http://www.rockbox.org/tracker/task/11907)
Since no one tested it on a player with SD noise, I have no idea if it'll help. But worth a shot. I compiled a build with it here:
http://duke.edu/~mgg6/rockbox/rockbox-fs11907.7z (http://duke.edu/~mgg6/rockbox/rockbox-fs11907.7z)
Thanks. I have tried that and the issue is still there.
It may not be possible to remove the noise at all, just handle it in different ways?
In 3 or 4 days time, I will pick up a cable and try to display the noise patterns visually between the firmwares. I think that will help explain a lot
If it happens in then Sandisk firmware too, then yeah theres probably no easy fix. That said, it might be possible to work around the issue like we did with the pitch error in the sandisk firmware. I'd be interested to see what recordings of the noise look like.
FWIW on my Clip+ there is a bit of background noise, but I can only really see it on a scope, since at +6dB volume, its only a few mV (and it does scale with volume). It sounds like theres a batch of players out there that are much more susceptible to this background noise. Interestingly when the DAC is powered off it doesn't entirely go away (but gets much, much weaker), so I tend to think its power supply noise being amplified by headphone amp.
Indeed, this noise doesn't really scale with volume, but at lower listening levels (at home, in bed) it's really obvious using my headphones. I find the Sansa firmwares contant noise less intrusive that the Rockbox's blasts of noise, but the silence inbetween the noise on the rockbox is heavenly
I have included a download link. A zip containing 4 flac files (one is over 30 secs but a lot of it is just noise and silence, not copyright material)
http://www.megafileupload.com/en/file/3221...esktop-zip.html (http://www.megafileupload.com/en/file/322152/Desktop-zip.html)
Rockbox One -- A track playing on the RB fw, you can hear the noise that occurs every so often while playing. Then I skip a track (noise), thurn the volume off (popping), and then skip a few tracks. You can again hear the noise on track changes.
Rockbox Two -- Just skipping tracks with the volume off. Same as the end of the first file.
Sansa One -- A FLAC track playing on the Sansa fw. You can't hear the noise, it pop's as you turn it down, then you can hear the constant noise that is always there in the background. This is with a FLAC source on the player. The noise on the next clip is different and is an MP3/
Sansa Two -- An MP3 playing on the Sansa fw. Different noise to the FLAC!
Cheers,
Kristian
Which rockbox version did you test?
the latest development and stable build, and the one you provided. I haven't done a side by side to compare if they are exactly the same but the noise exists on all of them.
Yes, but which version did you test when you recorded those files?
sorry: r30259-110806
The Clip+ I have bought some weeks ago is also affected by this issue. It is not that big of a problem for me, since I can only hear the noise at the beginning of a track when it is pretty quiet. But still, I would prefer not having these noises at all. Did I understand it correctly, that this is a hardware issue likely to be present in a newer revision of the Clip+? And the only actual fix would be getting an older revision Clip+...
Are there any ideas for workarounds in Rockbox to mitigate this issue?
Some additional findings (why can't I edit my last post anymore?):
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. Maybe this will help.
why can't I edit my last post anymore?
Do we need to make the Site Related Discussion subforum more prominent? (http://www.hydrogenaudio.org/forums/index.php?showtopic=72003)
I'm sorry to be bumping an old thread, but I couldn't find any more recent discussions on this issue. Just now I got myself a Clip+ and installed the latest stable RB (3.12) and I'm having the same issues. Basically the original firmware has this constant helicopter-like noise while playing files, and RB is silent except for rather loud noise when accessing either internal storage or external SD card. Has any solution been found yet? I'd be prepared to do some detailed recordings together with spectrograms of all the different noises, if anyone is interested.
I'm sorry to be bumping an old thread, but I couldn't find any more recent discussions on this issue. Just now I got myself a Clip+ and installed the latest stable RB (3.12) and I'm having the same issues. Basically the original firmware has this constant helicopter-like noise while playing files, and RB is silent except for rather loud noise when accessing either internal storage or external SD card. Has any solution been found yet? I'd be prepared to do some detailed recordings together with spectrograms of all the different noises, if anyone is interested.
Its because rockbox loads several MB of audio at once into RAM and then powers down the flash while the sandisk firmware leaves the flash powered up and slowly streams data from it in smaller chunks. So instead of a louder click you get a constant dull sound.
I don't think a solution exactly is possible, since its just a hardware problem with a smallish number of players. Probably the best you could try to do would be to shrink the size of the rockbox audio buffer so that it has to frequently refill like the sandisk firmware does. That said, I have no idea how well that would work (or even if rockbox will run with a small enough audio buffer for that to make a difference).
I don't think a solution exactly is possible, since its just a hardware problem with a smallish number of players. Probably the best you could try to do would be to shrink the size of the rockbox audio buffer so that it has to frequently refill like the sandisk firmware does. That said, I have no idea how well that would work (or even if rockbox will run with a small enough audio buffer for that to make a difference).
How would I go about reducing the Rockbox audio buffer? Also, is anything known about the amount of Clip+'s that have this issue? Any way to avoid this "faulty" hardware in the future when buying a Clip+?
I'm not sure what the best way is. When I've done this I messed with the linker scripts to waste memory. If you're interested in trying to hack this, setup the dev tools, make a build then go ask on the Rockbox irc channel. Someone there will likely have a better idea.
Well, after the clip broke (literally the clip), I gave the player away with a view to buying something else........however I have bought a new Clip+ in the hope it has no noise issue and was a rare hardware fault.
Also bought a 64GB card so I'll have plenty of storage 72GB
Watch this space for an update!
Just to update, the new player doesn't exhibit any noise issue at all! I have only checked with RB, I haven't loaded the standard firmware.
Also, formatting the card to FAT32 allows it to work fine in the clip+. I used a genuine sandisk ultra class 10 card.
72GB of lovely music to listed too, happy chap The gamble paid off.