Rockbox Technical Forums
Support and General Use => Hardware => Topic started by: flickspot on March 22, 2016, 01:16:57 PM
-
Edit: See my second post for the actual issue
-
Here is a slightly older test build:
http://web.mit.edu/mgg6/www/rockbox-clipzip-d0d66f3.7z
Does it work?
Edit: Also, do you have a microsd card in the player?
-
Wow, thanks for the quick reply. Turns out I was hasty in my diagnosis. The actual problem is the following (and yes I have a microSD):
I recently updated my Zip to the latest Dev build, and shortly afterwards I put some 320kbps 44.1khz tracks on the microSD. There was nothing indicating a copy error, and the songs play fine in Windows, but my player keeps crashing while playing them. The playback stops, and there's sometimes a white screen with an error message about failing to copy or something like that. Building the database the first time after adding the new tracks also crashed. What to do here?
-
I'm assuming then that the internal storage works fine?
What happens if you try the build I posted above?
Edit: Also, which build are you running?
Edit2: Hard to know exactly what you should try without knowing your present build, but try this one: http://web.mit.edu/mgg6/www/rockbox-clipzip-d0d66f3.7z
It has the USB changes but not the SD driver changes.
-
I was running the March build. Internal storage did seem to work, oddly enough. I switched to the build you posted and the microSD seems to work fine, but I'm now getting a lot of hiss, both during playback and at idle.
Edit: Just saw your edit with the USB changes build, will try that one too
-
I was running the March build.
Which of the builds from March are you running? It's hard for me to suggest things to test if I don't know what you are doing.
-
Ah of course, I assumed from the "Major Changes" list that the build prior to my one was just from January. I was running fe9a3ce-160318. Both the builds you posted worked for me by the way - the earlier one had noticeable hiss, but d0d66f3-160322 doesn't have hiss or the crashes. Thanks for the help :)
-
Sorry to double post, but presumably you saw my first reply. Well, those tracks are now playing, but halfway through the album, some of the tracks started playing over each other. I also tried some other albums on my microSD, and they're also not playing. Again, I made sure these tracks are all working in Windows.
-
So to summarize:
Internal storage works.
External storage does not.
External used to work in 3.13, but at some point in the last 3 years (and before the last few weeks), it broke?
-
Yes. I didn't touch any dev builds until the fe9a3ce-160318 I downloaded today, so I don't know when it would have broken.
Edit: Just tried 3.13 again and it does work.
-
Here is one more build from a few days before we added CPU frequency scaling:
http://web.mit.edu/mgg6/www/rockbox-clipzip-1015088.7z
-
Ok, so this build has that hiss issue again that isn't present on 3.13 or the March builds, but I listened to the tracks and the album on the microSD and they all worked fine.
-
Ok, so this build has that hiss issue again that isn't present on 3.13 or the March builds, but I listened to the tracks and the album on the microSD and they all worked fine.
I'm not sure that the hiss is related to the build, or at least no one else has reported it. Can you let the player loop music off the SD card for a long time to make sure it doesn't crash? Then I'll provide another test build.
-
Right, well I swear I'm not going crazy, but I turned my player on and it no longer seems to have any hiss. It was really loud and unmistakeable. I wiggled my headphone jack to see if it might be wonky, and that wasn't it. Perhaps it was somehow related to being the first boot after a firmware update... or something.
Anyway, I'll report back in 40 minutes unless the player glitches/crashes before then.
-
http://web.mit.edu/mgg6/www/rockbox-clipzip-3f54101.7z
This is the first build with frequency scaling enabled.
-
Ok, 1015088 had no issue playing through 45 minutes. The last link, 3f54101, does have the microSD problems.
Also, I think the hiss may be a result of updating firmware, unplugging the device, and following the prompt to restart. Or maybe it happens after resuming playback straight after unplugging the device from USB. In any case, it disappears upon rebooting the device a second time.
-
That would make sense. If you boot the new build without rebooting a lot of hardware isn't reset. Usually its fine for moving to new builds, but it doesn't always work if you try to run older builds.
-
Ah right, fair enough then.
Will there be a dev build with the frequency scaling removed, but the "Improved stability and error handling for USB and SD" intact? I'm really interested in that particular feature.
-
Will there be a dev build with the frequency scaling removed, but the "Improved stability and error handling for USB and SD" intact? I'm really interested in that particular feature.
No :) But you can help to fix it.
saratoga: Can you provide build with previous CVDD2=0xF4 ?
-
Sure, happy to do it
-
http://web.mit.edu/mgg6/www/rockbox-clipzip-CVDD2=F4.7z
-
Will there be a dev build with the frequency scaling removed, but the "Improved stability and error handling for USB and SD" intact? I'm really interested in that particular feature.
No :) But you can help to fix it.
saratoga: Can you provide build with previous CVDD2=0xF4 ?
If this fixes it do you want to go all the way back to 2.8v in SVN, or try 2.7 or 2.75? Is there much savings?
-
This works without issue
-
Here is a slightly lower voltage:
http://web.mit.edu/mgg6/www/rockbox-clipzip-CVDD2=2.75v.7z
Does that also work ok? Could you test for a long period of time (maybe run overnight hooked to a charger) to be sure?
-
Yeah, I can do that. It's working well so far.
Out of curiosity, how many voltage steps are going to be tried if this keeps working? What were the values in the build that wasn't working, and what's the default?
Also, no big deal, but is there a way to disconnect the device from Windows without physically removing it?
-
I don't think we'd go below 2.75V. Previously the value was 2.65V, and in older builds it used to be 2.8V.
I'm not sure about Windows, but in rockbox you'd have to physically disconnect the USB cable before it will leave MSC mode.
-
Alright, I'll report back in the morning.
By the way, I'm a novice in this area, but is it possible that a voltage tested on my device could be insufficient for another device? I'm thinking about this like you'd think about a CPU overclock. Could it become insufficient over time as the electronics in these devices degrade?
Edit: In fact, due to the above concerns, and also apparently because devices without microSDs need less voltage, would the dev team consider putting in a user-controlled undervolting feature in the firmware? This has kind of reminded me of how phones are getting these kinds of tools these days in the form of third-party apps for enthusiast users.
-
I don't think we'd go below 2.75V. Previously the value was 2.65V, and in older builds it used to be 2.8V.
If 2.75V will be ok, I think we should also try 2.7V. We should have CVDD2 low as possible as it has a great influence on battery time, especially on clip+.
By the way, I'm a novice in this area, but is it possible that a voltage tested on my device could be insufficient for another device? I'm thinking about this like you'd think about a CPU overclock.
We want find and set by default safe value for all users.
Could it become insufficient over time as the electronics in these devices degrade?
I don't think so. I use overclocked/underclocked devices for many years with same settings. If it become unstable - this is hardware issue and reverting to default setting not help much.
Edit: In fact, due to the above concerns, and also apparently because devices without microSDs need less voltage, would the dev team consider putting in a user-controlled undervolting feature in the firmware? This has kind of reminded me of how phones are getting these kinds of tools these days in the form of third-party apps for enthusiast users.
It is possible later when we are sure that everything is stable, I will try compare fine tuned voltage settings for individual player to settings by default and to understand is it makes sense.
If it have sense, we can switch voltage automatically when sd card inserted.
But now I think better spend time for software (codec/dsp) optimization: it improve battery time on all targets and can be quite considerable.
-
Well, it's been ~11 hours, and everything seems stable. I'll test the 2.7V build when you upload it.
Regarding degradation, I think it's commonly accepted that electronics can become less efficient over many years due to degradation. Intel has acknowledged that higher voltages degrade electronics more quickly, implying there is some form of degradation over time even with a lower voltage. I don't know whether this manifests in less efficiency or something else, but the CPU overclocking community seems to think the former is the case.
-
You right, degradation electronics component can be more quickly if it used with higher voltage/current/frequency than recommended in datasheet. But as I mention before - if we have notable degradation in some electronics component reverting to default settings not option. If hardware broken it should be replaced/repaired.
-
For some reason I thought CVDD2 didn't make a huge difference. If it does, its probably worth testing more carefully
http://web.mit.edu/mgg6/www/rockbox--clipzip-CVDD2=2.70v.7z
Could you test this one for a while and let me know if its ok? If it works, I'll set the voltage in the main build to 2.70 or maybe 2.75 if we want to be safe.
-
All good after 6.5 hours :)
-
Good. I think we can commit 2.7v and rise it later if we would have another report about same problem.
-
Committed:
http://git.rockbox.org/?p=rockbox.git;a=commit;h=ece9303
-
FYI: I still had the dev build prior to the voltage increase on my fuze v2 (fe9a3ce-160318).
Today I had copied a new album (MPC Q6) onto my Sandisk 128GB SDcard. The first track in the album made a screeching noise after 6s and skipped to the second track. This did not happen when this track was inserted in the middle of a playlist.
This problem is gone with ece9303 !