I’ve just had the volume on my Sansa Fuze (firmware 01.01.22) shoot up to maximum whilst I had inner ear phones in - this appears to be the bug mentioned in other threads on here caused by the volume going to maximum on track change when wheel is accidentally turned too (just slightly).
This is the second time - the first time I thought it was a bad ogg, and desperately tried to lower the volume to find it didn’t work - 3-4 seconds of maximum volume with Philips inner earphones.
I’m putting a call into Sansa support to get this fixed as a matter of urgency, especially as my right ear feels like it has cotton wool in and still have discomfort (2 hours later now). If it’s still like this tomorrow I’m going to the doctor’s to get it checked out - I’ll see where this goes then.
To the OP. Give them a call. I know how you feel. My Fuze doesnt do this but having been a musician for 8 years now, I have had my fair share of blasts from IEMs. Tonight if it still bothers you try to sleep on that ear, It might not help you but it helps me. Also Soo many have reported it at this point that I do believe it will be at least attempted in the future, maybe not the next Firmware (Due out by the end of the month) but in the one after that.
I sent them an email yesterday evening and even offered my telephone number but have not yet had a response. It’s shocking (quite literally) that something like this got through QA - you’d think it would default if there was a error to 0-10% volume as a catch-all, even worse is ignoring the volume controls and that something like this issue hasn’t already been addressed (given that it leaves Sansa open to legal issues).
My ear feels somewhat better this morning but I can’t really tell if I can hear worse since I guess it will be lower volumes that will be affected.
Hopefully and ideally I’ll get a response or call today with an apology and some sort of quick fix
The thing is that while people come on here and report this, the occourances are rare. For some prople it happens when certain buttons are pressed. For others (and this sounds like what happened to you) it is a random occourance. Its hard if not impossible to replecate that in QA.
I really don’t have an idea of what can cause this problem but I was one of the first people who reported this annoying bug or issue few months ago, now I’m just posting to tell you that I’m currently running the latest firmware version and this volume issue repeated again few days ago.
I hope this info will help to know fix the issue since is really annoying, especially when you don’t know when it will happen.
Details:
This volume issue used to happen more often before the latest firmware update, somehow now I not experiencing it that often as before. I encountered this problem in two different situation; while changing from song to song or when I turn my device on and as soon as I hit play there you go.
The file was a 256Kbit Ogg encoded with freerip - I had been playing another 256Kbit ogg and was attempting to skip to the next track.
To be more precise, I was in the process of playing the song, but pressed right to skip the current playing song, at the same time my finger slipped down to the right (i.e. clockwise) on the wheel by about a maximum of 30° from the horizontal. The distance the wheel covered should have boosted the sound only very slightly, instead it went to maximum volume, from around 45% volume (i.e. the volume it would be on if I had at that point done three whole revolutions of the wheel).
I may be able to replicate this and will try when I get back from work (without ear phones in obviously) and can upload a video if you have problems replicating?
The file was a 256Kbit Ogg encoded with freerip - I had been playing another 256Kbit ogg and was attempting to skip to the next track.
To be more precise, I was in the process of playing the song, but pressed right to skip the current playing song, at the same time my finger slipped down to the right (i.e. clockwise) on the wheel by about a maximum of 30° from the horizontal. The distance the wheel covered should have boosted the sound only very slightly, instead it went to maximum volume, from around 45% volume (i.e. the volume it would be on if I had at that point done three whole revolutions of the wheel).
I may be able to replicate this and will try when I get back from work (without ear phones in obviously) and can upload a video if you have problems replicating?
This is EXACTLY what happened to the others and YEAH this is a bug. Im not sure a Firmware will fix it but we will see.
The file was a 256Kbit Ogg encoded with freerip - I had been playing another 256Kbit ogg and was attempting to skip to the next track.
To be more precise, I was in the process of playing the song, but pressed right to skip the current playing song, at the same time my finger slipped down to the right (i.e. clockwise) on the wheel by about a maximum of 30° from the horizontal. The distance the wheel covered should have boosted the sound only very slightly, instead it went to maximum volume, from around 45% volume (i.e. the volume it would be on if I had at that point done three whole revolutions of the wheel).
I may be able to replicate this and will try when I get back from work (without ear phones in obviously) and can upload a video if you have problems replicating?
This is EXACTLY what happened to the others and YEAH this is a bug. Im not sure a Firmware will fix it but we will see.
I’m just going to throw this into the ring…
I would like to see if this ‘bug’ occurs if you use another encoder other than freerip. I played with the program for a bit, and I have confirmed that it (freerip) doesn’t rip FLAC files correctly. The same may hold true with ogg vorbis files. Since ogg vorbis is an open codec, the people at freerip may have tweaked the codec somewhat.
I’m not saying this is the case, I’m just curious if the situation happens with encoders supported by the vorbis website. I use ogg almost exclusively and have never had this happen with 2 fuzes. I always encode using the program in my sig or with WinAmp.
I don’t know that much about encoder program stuff but I don’t think the issue is related with the encoder or the file format. I use regular MP3 files download from a sharing program such as Ares or Limewire, I experienced this volume problem from the beginning when the FLAC format wasn’t available for Fuze yet. I hope this could be a useful information, I really would like a firmware update that fix this issue.
I can’t replicate the bug on demand (so far) - what I remember is that the wheel seemed to be unresponsive for a few seconds after the volume went up - with no volume bar shown on screen. Being too startled I yanked the earphones out and switched the device off to stop it - perhaps code around any wheel interrupt handling is an area to start looking at and working backwards?
From an educated guess as a (C++) developer who has not seen any source I think this is a race condition (which is why it is rare and hard to replicate):
Interrupt -> Track skip initiated
Status -> Last track currently playing
Interrupt -> Volume control activated (but not yet displayed)
Status -> Loading new track, **display being updated with this info instead**
Status -> Set volume from volume control (which is actually not being shown, and thus set). This is performed either at start of play or by an interrupt handler.
Status -> Set default or errored volume (ERROR)
Status -> Volume control not shown (ERROR) but MARKED as showing
Status -> Volume control not receiving input (as it is not actually shown).
Timer interupt -> Volume control not interrupted in X seconds (no user response), reset last known good volume (taken from other users’ experience here - I switched the power off), go back to showing track info.
Status -> Volume now normal again X seconds later (the time taken for a volume control to disappear) - ERROR RESOLVED.
Specifically I’d look into the possibility of a temporary local scope variable value going out of scope or not initialised correctly due to the volume control being shown, but being used to set the actual system volume variable somewhere (i.e. a wild pointer assignment), i.e. the (essentially seperate thread) interrupt handler reads the bad temporary volume value and sets the master volume on volume control startup.
Some combination of the above I guess may also cause it on device startup?
[EDIT] - This would also explain why the volume control is unresponsive, since it thinks it is currently being shown, and refuses to actually show.
[EDIT 2] - In light of not being able to replicate it consistently (yet), a volume failsafe such as making sure the volume can’t be set during track skip/device startup - i.e. the actual value can’t be set (not hiding the volume control). This should be the easiest way to solve the problem?
The only volume issue I had so far, I was with playing video… I found if I paused the video then turned the volume wheel up or down the volume would in fact change with out any indication of it being adjusted… So ya i could be hit with high volume levels… This is repeatable and is probably not the same bug others are describing… I though maybe this info would still be useful. Being I know this about the Fuze I can avoid issues with the sound level changes… This was with a Fuze I got that still had the older firmware v01.01.11a in it " and still does"… I have not loaded video in my other units with firmware v01.01.22a yet so I don’t know if this still exists in the newer firmware… George
Well it seems as though sansa have a left hand not knowing what right hand is doing problem.
I’ve finally got a response from sansa support in their private message area on the sansa site stating that my hand had probably slipped and turn the volume up (how I turn a wheel up three whole revolutions in 200ms I don’t know)…
I like your earlier ideas posted. As for the revolutions versus time issue, as a programmer, you should be familiar with keyboard / input interrupts. A program can halt, accept the interrupt, resume- in a loop, making for a very rapid input stream, as inputs continue.
In casual use, I’ve noted that the Fuze does not always recognize a scroll wheel revolution. Playing with it, sometimes a half-turn is required to trigger a volume change.
The big problem is that there are many more Fuzes in the field, and users, than possible at SanDisk. The buildings are of a finite size, of course. The glitch happens very sporadically, so the feedback from the forums is most helpful in tracking down this elusive gremlin. I’ve spent many hours listening to “fractured music” as I drove my Fuze crazy trying to replicate the issue.
If my scroll wheel were an aircraft part, MTBF would be my concern, as I’ve cranked that wee beastie quite a few revolutions, and rocked it about. I’m sure that the solution will involve a judicious application of delay times, or a command inhibit. Sounds like they are actively working on it.
I’ve just had a final response from Sansa with a separate paragraph saying that Sansa has taken into consideration my solution suggestion for the next firmware. My developer colleague next to me has just basically said that that was some elite debugging lol!
As for my hearing, well I’m using external head phones until the next firmware with the patch - I don’t really want to chance it again no matter how rare the issue. I’m hoping my Fuze will last a long time an otherwise excellent little device that it is (off topic the sound distortion bug mentioned on other posts isn’t too bad, and not very noticable if on the equaliser you lower all frequencies making them negative and just put those you want increaing in the positive area - i.e. instead of boosting the frequencies you want you lower the frequencies you don’t want)
