iRiver 120 & Sansa Fuze+ - cracking sound in quiet parts

[monoid]

My problem is that clicking and disturbances/noise can be heard in quiet patrs of songs . Is that known issue? If yes, is it possible to avoid somehow? It came to my mind it may be atributed to display handling (I have "scroll text if long" enabled).

I first noticed it in Sansa Fuze+ and thought it is because of not so good DAC. Later on I RockBoxer iRiver 120 and it is also there (but the sound from iRiver is fine if I use digital optical output) and it did not occured in iRiver's OF.

So, the problem is not in mp3 file, it is not in decoding and digital processing (digital output is clean without disturbances). The problem must come in D/A conversion in iRiver/Sansa...

Thanks a lot.

[saratoga]

Which version are you running?

[monoid]

In iRiver H120 the last stable 3.12, bootloader 7pre4. I have SSD 120 GB 50 pin ATA.

In Sansa Fuze+ 06aa7e8-120821, bootloader 1.0. It is 16 GB with Kingston 32 GB uSDHC card.

[Julian67]

I've experienced the same problem on my two iRivers (H140 and H340) and on my Sansas (currently Clip+, previously Fuze v2), which is really noticeable on quiet passages or in choral music where anything other than a human voice stands out.

The Sansa players can have a noise problem even in original firmware and it's quite well known.  In Rockbox it can become more obvious if you enabled the database which involves a lot of extra CPU load and disk access depending on how you configure and use it.  If you have a noisy Sansa you can't entirely eliminate the noise but you can mitigate it by not using the database.

With the iRivers it's different:  I've been using Rockbox on iRiver since it became stable on the H100 series and the crackles during playback are a relatively new phenomenon so I tried older stable firmwares until I arrived at a version which doesn't exhibit the problem on my players.  That version is 3.5.1.

Some observations/notes:

My H340 in original firmware (1.29k) very rarely (almost never) makes a crackle.  The same was true in older Rockbox.  In Rockbox 3.6 and newer it crackles and it's annoying, and the H140 is much the same.  With database enabled it crackled a lot when database updated, to the extent that the H340's FM radio was unusable due to extreme interference at this time.  This suggests to me that the problem is nothing to do with decoding but is associated with CPU load and/or disk access and/or RAM access.

The H340 running 3.5.1 without database doesn't crackle, or at least it's unusual enough that I don't notice, much like the original firmware.

The H140 works beautifully with 3.5.1.  I don't need the original firmware so installed Rockbox to EEPROM using rombox http://www.rockbox.org/wiki/IriverFlashing so it runs from the flash memory chip.  Even while the database is updating there is zero unwanted noise and the FM radio works without interference.  Occasionally I've heard an unwanted crackle and on checking it has turned out to be either a noise actually present in the original recording i.e. a manufacturing defect, a damaged disc, a production error etc. or a noise arising from me....anyone with hairy ears and IEMs will know this can happen...

I'd suggest backing up your player's current .rockbox directory to PC, then trying the older firmware installed to flash with new, default settings (because current themes and some setings won't work on older versions).  All this is reversible if you follow http://www.rockbox.org/wiki/IriverFlashing and as you already have a suitable bootloader it will be very simple.  If it solves the crackle problem like it did for me and you want a manual for the old version let me know as I couldn't find one anywhere so I built one.  It's quite useful especially because it contains the older theme syntax, and once you have this you can easily adapt current themes to work on older firmware.

[monoid]

Thanks for info.

I was not that much surprised by noise in Sansa Fuze+ and I thought its the flaw in Sansa hardware. But it surprised me in iRiver H120, because a used it for many years with OF and there was never any noise.

So, this led me to conclusion it is not (most probably) hardware specific problem, but instead some problem in RockBox. I use mostly iRiver's optical output and so the sound is without problems even in current firmware. But I might use 3.5.1 in my H140 when I RockBox it.

Hard to say, what causes the problem. Digital output (on H120) is perfect (from current RockBox), so it must be D/A part of RockBox code. I use 120 GB SSD. I do not have database initialized on H120, so it must be also something else. I did not experiment with it, but my candidate is scrolling of long texts (MP3 tags). If scrolling is needed, it must be done periodically and may interfere with other circuitry.

[Julian67]

As the same versions of the decoders apparently work without issues on other Rockbox targets (and also because I don't know) then I'd still be slightly reluctant to ascribe the problem to decoding, though you might be right.  Maybe CPU load spikes might induce a problem in the analogue out that either doesn't affect the optical out, or is handled by the external decoder's error correction?

Anyway that is all speculation and  whatever the cause I can assure you that reverting my H140 to 3.5.1 and running it from EEPROM eliminated the problem entirely.  My recollection is that older firmwares worked fine running from disk as well.  I installed to flash after realising that I hadn't used the iRiver firmware for months or years and when I checked it out again it didn't seem like I had missed anything.  If I were you I would make my own comparison.

[monoid]

Thanks for info. I might try 3.5.1 in H120. To say the truth, the cracking (in H120) does not make me problems, because I use optical output.

I started the thread mainly because it seemed to me, that maybe it is more a general issue of current RockBox than a player type  dependent issue.

I'll try to investigate my scrolling text theory. The cracking has the same/similar "frequency".

[Julian67]

btw out of curiosity I reverted my H140's flash firmware to iRiver, retaining Rockbox 3.5.1 on disk.  Even running from disk (which I guess means slightly more disk access) I get no crackles with 3.5.1, this with Eq and crossfeed in use and even while the database updates.

I can also note that I didn't realise how many CDs have tiny audio imperfections until I started using good quality noise isolating earphones.  There are noises in quite a few recordings that I had never heard, or at least hadn't taken any notice of, in years of listening with speakers or earphones/buds/headphones that don't isolate well.  So comparing digital out>DAC>amp>speakers with direct earphone listening might not be quite as good a comparison as it first appears.

[monoid]

That is right, that it is important what headphones/speakers are used. And if speakers are used, what is the property of room...

But my comparison is with the same recording, same room and audio chain, the same iRiver and the same iRiver settings. The only difference is in using analog versus digital output. (in both cases digital output is set on and volume for analog output is set the same).

So, maybe the digital and D/A chain (in DENON) is able to correct hypotetical digital errors or quirks in iRiver data stream. Or there is some kind of D/A issue in RockBox. Because similar/the same behaviour have both Sansa Fuze+ and iRiver H120.

One guy also pointed out that it makes difference if you plug headphones directly to iRiver or to remote. Remote seems to have more noise according to his experience....

[Julian67]

The iRiver remote controls with display are known to make a noise.  There is a configuration option in Rockbox for H100/300: General Settings>Display>Remote-LCD Settings>Reduce Ticking.  Some players tick with the remote controls and some don't (I think I remember iRiver fixing or exchanging players for free on this issue, so it's probably  a hardware issue not firmware) but anyway it's a different issue.  I have a remote control with display and it doesn't cause a ticking noise on either my H140 or H340.

I'm still thinking that the issue you have on your Fuze is not the same as on the iRivers.

I just tried Rockbox 3.12 on my H340 for the purpose of comparison.  I encoded one choral+organ track (nice tones, easy to notice any extraneous noise appearing) to flac, mp3 (lame -V 4), ogg (-q 6), and wavpack (hybrid and used the lossy file only).  I used default settings and theme except I switched off Replay Gain, and I played each format.  It crackles occasionally regardless of codec.  The crackles are never in the same place, and might appear in either channel.

Reverting to 3.5.1 and again with no Replay Gain or Eq or similar I played the same tracks: no crackles.  My H140 is the same.

Whether it's a decoding bug I don't know.  There are definitely big differences in decoding in newer versions, 3.6 onwards,  with huge efficiency gains.  3.5.1 on iRiver really struggles with aac: only flac and mp3 play back with constant normal load on the cpu; ogg is a little less efficient than them but still good.  With very high bitrate aac the CPU is maxed out all the time and the player can even hang.  In newer firmwares all the codecs I tried are extremely efficient and with ogg, flac or mp3 the CPU never seems to need to go above normal rate and even very high bitrate large (100s of MB) aac (in m4a) load without a problem.  The newest firmware for iRiver is clearly better in every way (more efficient, more codecs, more and features, feature enhancements etc) except in the single most vital aspect: playback without audible artefact.  So I'm sticking with 3.5.1.

On my Clip+ running 3.12 I don't notice any crackles during playback even with Eq and crossfeed enabled and while database updates. While paused there are certainly some ugly noises (by contrast the OF is completely silent on pause) but whether they aren't present in playback or are so quiet that they are masked I'm unsure.  I used to find Clip+ crackled with older Rockbox versions but now in practice it seems OK and I can live with it sniffing, scratching and farting on pause so long as it behaves politely during playback.

See http://www.rockbox.org/wiki/SansaAMS for some of the known issues.  Various people report buzzes, squeaks, humming, crackles and so on.  There is an informative discussion at http://www.hydrogenaudio.org/forums/index.php?showtopic=86306&st=50 and the post http://www.hydrogenaudio.org/forums/index.php?showtopic=86306&view=findpost&p=746934 is especially pertinent, and is possibly also relevant to the iRivers.  I'll quote it here:

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.

Rockbox for Sansa improved a lot since 2010 and I believe some of the problems were fixed by locking the CPU to max instead of letting it switch between idle/normal/max.

The EMI phenomenon would fit perfectly with your experience of noisy analogue out but no problems with optical out.  Maybe EMI is the issue on the iRivers in newer firmware, but I don't know.

[monoid]

I agree. I did not want to put it as that there is a bug or something wrong in RB code. I think the decoding side is OK, the perfect digital output supports this opinion.

My feeling is, that used timing of different tasks and handling various events seems to create unwanted side effects. At least on some brands of players, or even maybe certain production batches of those brands.

I understand it is hard or even impossible to address and solve such "issues" by an universal code done for free in free time.

Thanks for info that 3.5.1 does not suffer this "issue" on iRiver H1x0/H3x0.

[Julian67]

Update:

Recently I tried a daily build to check on a new feature.  Since July 13 I've been running the daily build of July 13 on both my H140 (flashed to ROM) and H340 and both now play audio without any of the crackling problems described in this thread, so I thought I'd mention it here so anyone can see the problem is gone.