| 00:00:39 | | Quit benedikt93 (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 00:00:47 | | Join benedikt93 [0] (~quassel@unaffiliated/benedikt93) |
| 00:20:55 | | Quit Rower (Quit: Hmmm...) |
| 00:31:14 | | Quit Strife89 (Ping timeout: 244 seconds) |
| 01:00 |
| 01:01:38 | | Quit englishm (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 01:06:19 | | Quit this_is_a_nick (Remote host closed the connection) |
| 01:21:40 | | Part ender` |
| 01:58:32 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:30:38 | | Join flashpoint [0] (~flashpoin@unaffiliated/flashpoint) |
| 03:30:46 | flashpoint | is the ibasso dx90 person here? |
| 03:30:50 | flashpoint | person or people? |
| 03:41:34 | | Quit ZincAlloy (Quit: Leaving.) |
| 03:58:33 | *** | Saving seen data "./dancer.seen" |
| 03:59:45 | | Join Saratoga [0] (47e99464@gateway/web/freenode/ip.71.233.148.100) |
| 04:00 |
| 04:01:35 | Saratoga | flashpoint: probably not, but just ask if you have a question |
| 04:04:39 | flashpoint | it's based on android apparently? |
| 04:05:27 | flashpoint | damnit I'll sort it myself, I have never once got any kind of answer that helped in any way from this channel |
| 04:10:39 | | Quit Saratoga (Ping timeout: 252 seconds) |
| 04:48:25 | _Bilgus | then maybe you should be the person helping someone instead of being all pissy |
| 04:49:40 | _Bilgus | https://www.rockbox.org/wiki/IBassoDXPort |
| 04:50:02 | _Bilgus | says it needs the android ndk so yes based on android |
| 04:50:20 | _Bilgus | @flashpoint |
| 05:00 |
| 05:02:50 | flashpoint | this is the most response literally ever |
| 05:09:10 | _Bilgus | well you do realize we are all volunteers and have other things to do? |
| 05:58:35 | *** | Saving seen data "./dancer.seen" |
| 06:00 |
| 06:20:43 | | Join Drills4Hands [0] (~flashpoin@unaffiliated/flashpoint) |
| 06:22:05 | | Quit flashpoint (Ping timeout: 244 seconds) |
| 06:24:35 | | Nick Drills4Hands is now known as flashpoint (~flashpoin@unaffiliated/flashpoint) |
| 06:38:27 | | Quit Ruhan (Quit: Connection closed for inactivity) |
| 06:54:41 | | Quit TheSeven (Ping timeout: 265 seconds) |
| 06:54:53 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
| 07:00 |
| 07:07:30 | | Quit flashpoint (Ping timeout: 268 seconds) |
| 07:07:34 | | Quit alce (Read error: Connection reset by peer) |
| 07:13:14 | | Join alce [0] (~taz@mobile-access-b0485f-180.dhcp.inet.fi) |
| 07:38:28 | | Join flashpoint [0] (~flashpoin@unaffiliated/flashpoint) |
| 07:38:58 | | Quit flashpoint (Client Quit) |
| 07:58:37 | *** | Saving seen data "./dancer.seen" |
| 08:00 |
| 08:23:35 | | Quit alce (Read error: Connection reset by peer) |
| 09:00 |
| 09:58:39 | *** | Saving seen data "./dancer.seen" |
| 10:00 |
| 10:06:13 | | Quit mikroflops (Ping timeout: 256 seconds) |
| 10:08:07 | | Join mikroflops [0] (~yogurt@c83-255-27-121.bredband.comhem.se) |
| 10:24:02 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 10:33:41 | | Quit Jinx (Ping timeout: 260 seconds) |
| 10:45:03 | | Join Jinx [0] (Dojo@unaffiliated/jinx) |
| 11:00 |
| 11:48:01 | | Join ZincAlloy [0] (~Adium@2a02:8108:9440:1870:f994:917c:d812:da0c) |
| 11:58:40 | *** | Saving seen data "./dancer.seen" |
| 12:00 |
| 12:38:48 | | Quit ZincAlloy (Quit: Leaving.) |
| 12:50:08 | | Join ZincAlloy [0] (~Adium@2a02:8108:9440:1870:f994:917c:d812:da0c) |
| 12:57:54 | | Quit ZincAlloy (Quit: Leaving.) |
| 12:59:29 | | Quit Acou_Bass (Quit: byeeeeeeeeeeeeeee) |
| 13:00 |
| 13:00:18 | | Join Acou_Bass [0] (~Acou_Bass@cpc97736-bolt17-2-0-cust152.10-3.cable.virginm.net) |
| 13:02:00 | | Join Ruhan [0] (uid76353@gateway/web/irccloud.com/x-sfcwtxtcppmynagn) |
| 13:22:03 | | Join ZincAlloy [0] (~Adium@2a02:8108:9440:1870:f994:917c:d812:da0c) |
| 13:32:39 | fs-bluebot | Build Server message: New build round started. Revision 6f0320a, 275 builds, 12 clients. |
| 13:35:05 | | Join massiveH [0] (~massiveH@ool-18e4e27c.dyn.optonline.net) |
| 13:53:04 | fs-bluebot | Build Server message: Build round completed after 1226 seconds. |
| 13:53:05 | fs-bluebot | Build Server message: Revision 6f0320a result: 26 errors 14 warnings |
| 13:58:43 | *** | Saving seen data "./dancer.seen" |
| 13:59:15 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 14:00 |
| 14:06:22 | | Quit massiveH (Quit: Leaving) |
| 14:09:47 | | Quit krabador (Remote host closed the connection) |
| 14:57:03 | fs-bluebot | Build Server message: New build round started. Revision 568b812, 275 builds, 12 clients. |
| 14:57:07 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 15:00 |
| 15:15:14 | fs-bluebot | Build Server message: Build round completed after 1091 seconds. |
| 15:15:15 | fs-bluebot | Build Server message: Revision 568b812 result: 0 errors 2 warnings |
| 15:37:28 | fs-bluebot | Build Server message: New build round started. Revision 8fb1740, 275 builds, 12 clients. |
| 15:55:21 | leachim6 | _Bilgus: it works fine on my usb3 hub |
| 15:56:10 | leachim6 | is the AGPTek rocker my best bed if I want a new player? |
| 15:56:20 | fs-bluebot | Build Server message: Build round completed after 1132 seconds. |
| 15:56:21 | fs-bluebot | Build Server message: Revision 8fb1740 result: All green |
| 15:56:21 | _Bilgus | cool apples to oranges but glad it works :) |
| 15:58:44 | *** | Saving seen data "./dancer.seen" |
| 15:58:59 | leachim6 | the buying guide seems quite out of date :/ |
| 16:00 |
| 16:02:18 | _Bilgus | indeed |
| 16:08:29 | | Quit jhMikeS (Ping timeout: 244 seconds) |
| 16:10:25 | | Join jhMikeS [0] (~jethead71@24.192.177.173) |
| 16:10:50 | | Join Bilgus [0] (~Bilgus@unaffiliated/bilgus) |
| 16:12:38 | | Quit _Bilgus (Ping timeout: 256 seconds) |
| 16:13:53 | | Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) |
| 16:14:41 | | Quit jhMikeS (Ping timeout: 244 seconds) |
| 16:14:58 | leachim6 | so what do you recommend ? |
| 16:15:51 | leachim6 | I got a fuze+ that's running rockbox real nice |
| 16:16:03 | leachim6 | however, the battery is going to die one day and the rocker has bluetooth and other cool stuff |
| 16:19:58 | | Join kingDi [0] (~androirc@45.247.214.226) |
| 16:19:59 | | Join alce [0] (~taz@mobile-access-b0485f-180.dhcp.inet.fi) |
| 16:25:34 | | Quit prof_wolfff (Ping timeout: 240 seconds) |
| 16:33:16 | Bilgus | I think the rocker has terrible battery life but for the price why not I'm partial to the sansa clips but a used one is likely as much as the rocker |
| 16:43:41 | | Quit michaelni (Ping timeout: 256 seconds) |
| 16:49:43 | | Join saratoga [0] (47e99464@gateway/web/freenode/ip.71.233.148.100) |
| 16:50:02 | saratoga | i definitely think the voltage at low clock on the fuzev2 is too low, which causes ata errors for some people |
| 16:50:19 | saratoga | not sure what the value should be, might just raise it to a safe value even if it hurts battery life a little |
| 16:52:04 | | Join johnb2 [0] (~johnb2@p5B3AFF81.dip0.t-ipconnect.de) |
| 16:52:05 | | Quit alce (Read error: Connection reset by peer) |
| 16:54:08 | johnb2 | Bilgus : with all your recent AMS related commits, if you also commit the "boot from SD" I can use the HEAD development build again ;-) |
| 16:54:13 | johnb2 | Great work! |
| 16:54:21 | | Join _Bilgus [0] (~Bilgus@unaffiliated/bilgus) |
| 16:55:28 | | Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) |
| 16:56:38 | | Quit Bilgus (Ping timeout: 260 seconds) |
| 16:56:41 | fs-bluebot | Build Server message: New build round started. Revision 3e91ad5, 275 builds, 12 clients. |
| 16:57:43 | | Join alce [0] (~taz@mobile-access-b0485f-180.dhcp.inet.fi) |
| 16:57:49 | | Quit scorche (Disconnected by services) |
| 16:57:52 | | Join scorche` [0] (~scorche@rockbox/administrator/scorche) |
| 17:00 |
| 17:03:18 | | Quit johnb2 (Quit: Nettalk6 - www.ntalk.de) |
| 17:11:11 | saratoga | hmm build system didn't pick up that last commit |
| 17:11:34 | saratoga | i raised the fuzev2 voltage slightly |
| 17:15:26 | _Bilgus | saratoga I just pushed the powersave menu commit It raises them all at default |
| 17:16:57 | fs-bluebot | Build Server message: Build round completed after 1216 seconds. |
| 17:16:58 | fs-bluebot | Build Server message: Revision 3e91ad5 result: 10 errors 1 warnings |
| 17:16:59 | fs-bluebot | Build Server message: New build round started. Revision c75aac8, 275 builds, 12 clients. |
| 17:17:37 | saratoga | _Bilgus: what does it do? |
| 17:18:45 | _Bilgus | It raises the minimum voltage |
| 17:19:16 | saratoga | i'm looking at that now |
| 17:19:25 | saratoga | you shouldn't define HAVE_ADJUSTABLE_CPU_VOLTAGE on the v1 devices |
| 17:19:55 | _Bilgus | johnb and I tested it and it worked any clue why not? |
| 17:20:36 | saratoga | i don |
| 17:20:47 | saratoga | t think voltage/frequency scaling was ever completed on those devices |
| 17:22:29 | _Bilgus | hmm I mean I can re-disable it or we just wait n see |
| 17:22:40 | saratoga | i also don't think you should be putting things like hardware voltages in the settings |
| 17:23:24 | saratoga | putting them in the debug menu is sort of reasonable for testing, but users should not be able to adjust those things normally |
| 17:24:09 | _Bilgus | well its eith leave them at the max or give the option |
| 17:24:39 | _Bilgus | Its getting pretty obvious that leaving them at the min is crashing players |
| 17:25:03 | saratoga | we put a lot of work into figuring out what the minimum voltages are |
| 17:25:18 | saratoga | at this point I think it is only the fuzev2 where there is some question because its a rare device |
| 17:25:29 | saratoga | and not many people have tested it |
| 17:25:37 | _Bilgus | and those minimum voltages are in the power save menu otherwise it leaves them safely higher |
| 17:25:55 | saratoga | traditionally we did not allow people to change hardware settings |
| 17:26:04 | saratoga | i don't see a rationale for changing that now |
| 17:26:15 | saratoga | we should simply raise voltages we are unsure of |
| 17:26:38 | _Bilgus | I'm not sure how you can argue against higher voltages rather than than having lower voltages as default |
| 17:27:01 | saratoga | I'm saying each voltage should be put to a safe value and kept there |
| 17:27:13 | saratoga | so skimming this patch, I have a lot of problems with it |
| 17:27:37 | saratoga | first, you're doing an awful lot in one commit, such as enabling voltage scaling, debug menu, new features, etc |
| 17:27:52 | saratoga | each of these should be an individual commit, and they should be introduced gradually so there is time to test |
| 17:27:52 | | Quit alce (Read error: Connection reset by peer) |
| 17:28:04 | _Bilgus | they are individual commits |
| 17:28:39 | saratoga | https://git.rockbox.org/?p=rockbox.git;a=commitdiff;h=6f0320a |
| 17:28:52 | _Bilgus | debug menu went a day or two ago but how about we leave the higher default and remove the menu then you can manually set power save |
| 17:28:59 | saratoga | that should be a lot of separate commits |
| 17:29:35 | _Bilgus | http://gerrit.rockbox.org/r/#/c/1732/9//COMMIT_MSG |
| 17:32:47 | | Join johnb7 [0] (~johnb2@p5B3AFF81.dip0.t-ipconnect.de) |
| 17:33:29 | | Join alce [0] (~taz@mobile-access-b0485f-180.dhcp.inet.fi) |
| 17:34:02 | fs-bluebot | Build Server message: Build round completed after 1024 seconds. |
| 17:34:03 | fs-bluebot | Build Server message: Revision c75aac8 result: 10 errors 1 warnings |
| 17:34:32 | fs-bluebot | Build Server message: New build round started. Revision 16f10e2, 275 builds, 11 clients. |
| 17:35:50 | saratoga | maybe i don't understand how git works? |
| 17:35:58 | saratoga | i'm just looking at the front page commit log |
| 17:36:34 | johnb7 | saratoga : I did a lot of testing with Bilgus, with various AMS v1/v2 devices I own. I personally am fond of the idea of having safe defaults, but giving the possibility of lowering them for non-susceptible devices. |
| 17:36:34 | _Bilgus | I reverted it but I'm feeling like lower battery life is worth not breaking players |
| 17:37:35 | _Bilgus | I'm going to push the higher volatge against all the players for now and I'll work on splitting this up when I have more time to screw with it |
| 17:37:53 | saratoga | what higher voltages??? |
| 17:39:06 | _Bilgus | (AS314_CP_DCDC3_SETTING | CVDD_1_15)) |
| 17:39:20 | _Bilgus | ascodec_write_pmu(0x17, 1, 0x80 | 26); |
| 17:39:43 | _Bilgus | currently it is: |
| 17:39:45 | _Bilgus | ascodec_write(AS3514_CVDD_DCDC3, (AS314_CP_DCDC3_SETTING | CVDD_1_10)); |
| 17:39:50 | | Quit alce (Read error: Connection reset by peer) |
| 17:40:19 | saratoga | do you have a patch I can look at? |
| 17:40:40 | saratoga | fwiw, i did not realize people were still working on the amsv1 power, were the problems I had with SD fixed? |
| 17:41:43 | _Bilgus | I'm confused the patch to look at is what was pushed? |
| 17:41:52 | _Bilgus | (and now reverted) |
| 17:42:40 | _Bilgus | the problems with sd on which player and what were the symptoms the only probalem I remember was with display on clipzip and I raised that frequency |
| 17:43:32 | johnb7 | Fuze v1 for instance. |
| 17:43:43 | _Bilgus | this has been sitting for 9 months so I'm not sure what other problems you might have had but I question why you didn't raise them in gerrit.. |
| 17:44:23 | saratoga | i thought this patch added a debug menu |
| 17:44:41 | _Bilgus | this patch added a power save menu |
| 17:44:53 | johnb7 | I mean months ago (I assume that is what saratoga is referring to). It was never completely stable back then. |
| 17:45:05 | _Bilgus | it allows people to choose the lower voltages (currently the defaults) |
| 17:45:17 | saratoga | i would have told you not to commit that |
| 17:45:40 | saratoga | i'm not sure what has changed with AMSv1, but the patch I saw last fall broke SD cards on my device |
| 17:45:48 | | Join alce [0] (~taz@mobile-access-b0485f-180.dhcp.inet.fi) |
| 17:45:50 | saratoga | i'm pretty sure thats been a problem since at least 2012 |
| 17:45:57 | saratoga | was it fixed? |
| 17:47:02 | _Bilgus | the sd card issue only occurs on high speed cards so it would work fine at default and could break high-speed cards if you activated power saving but you'd just disable the power saving and it would work again |
| 17:47:39 | saratoga | ok i think i was confused about voltages above, you mean just for AMSv1? |
| 17:48:04 | _Bilgus | no it raises voltages by default for V@ as well |
| 17:48:08 | _Bilgus | V2 |
| 17:49:00 | fs-bluebot | Build Server message: Build round completed after 868 seconds. |
| 17:49:01 | fs-bluebot | Build Server message: Revision 16f10e2 result: 39 errors 14 warnings |
| 17:49:03 | fs-bluebot | Build Server message: New build round started. Revision d8bd356, 275 builds, 11 clients. |
| 17:49:19 | _Bilgus | there are two voltages that are affected here we have the DCDC3 and CVDD2 |
| 17:49:57 | _Bilgus | on v1 devices they have the CVVD1 set at max always they don't like lower volatges |
| 17:51:35 | _Bilgus | OTOH DCDC is 1.17v currently and the patch raises the default to 1.20 with the option for 1.17 |
| 17:51:52 | saratoga | i don't remember much about the v1 so i'll defer on voltage changes there |
| 17:51:52 | | Quit alce (Read error: Connection reset by peer) |
| 17:52:11 | saratoga | which build do i test on my fuzev1? |
| 17:52:14 | _Bilgus | V@ is doing the same |
| 17:52:44 | saratoga | i'm moving at the moment, but I was able to find where i packed my devices |
| 17:53:15 | _Bilgus | V2 damn sticky shift key I just destroyed the builds that would be spit out give me a minute and I can rebuild and upload |
| 17:53:26 | saratoga | but in general, please do not commit large changes like this all at once with discussion and individual testing |
| 17:53:45 | saratoga | do not change v1 and v2 devices at once, do not add new features and change hardware settings at once, etc |
| 17:53:54 | saratoga | its a nightmare to track down problems this way |
| 17:55:54 | _Bilgus | plenty of testing went into it but ok i'll split them up further |
| 17:57:07 | | Join alce [0] (~taz@mobile-access-b0485f-180.dhcp.inet.fi) |
| 17:58:46 | *** | Saving seen data "./dancer.seen" |
| 18:00 |
| 18:03:17 | saratoga | testing on the fuzev1, the voltage scaling patch doesn't break my sd card anymore, so thats a good step |
| 18:04:32 | _Bilgus | oh I was building one did you build your own then? |
| 18:04:49 | saratoga | yeah i just built now from source |
| 18:05:28 | saratoga | testing c75aac8 |
| 18:05:35 | _Bilgus | oh ok well anyways I'll screw with it later I'm going to put all the back end in and we can add the options one at a time |
| 18:06:17 | _Bilgus | #ifndef BOOTLOADER |
| 18:06:17 | _Bilgus | #define CONFIG_POWER_SAVING (POWERSV_CPU | POWERSV_I2C | POWERSV_DISK) |
| 18:06:17 | _Bilgus | #endif |
| 18:06:44 | _Bilgus | we can just add each flag one at a time per player (or player group) and it will spread out the builds |
| 18:07:11 | fs-bluebot | Build Server message: Build round completed after 1090 seconds. |
| 18:07:12 | fs-bluebot | Build Server message: Revision d8bd356 result: 14 errors 0 warnings |
| 18:07:30 | saratoga | i don't really like the idea of the power savings menu, this has been discussed and rejected at various points in the past |
| 18:08:07 | saratoga | historically we always said that reasonable defaults should be chosen, rather than forcing users to guess |
| 18:08:08 | | Quit alce (Read error: Connection reset by peer) |
| 18:08:33 | saratoga | what are the advantages of the I2C and DISK power savings and why can't they just be on by default? |
| 18:08:44 | _Bilgus | they make it SLOW |
| 18:09:00 | johnb7 | when copying to SD |
| 18:09:28 | saratoga | how much power do they save? |
| 18:09:28 | _Bilgus | if I'm playing music sure thats fine but if I'm copying files or building a database or playing games |
| 18:09:30 | johnb7 | or internal |
| 18:09:59 | _Bilgus | IIRC 20-40% |
| 18:11:23 | _Bilgus | together** I've not got enough info on each individually to give you a per option breakdown |
| 18:13:31 | | Join alce [0] (~taz@mobile-access-b0485f-180.dhcp.inet.fi) |
| 18:14:14 | _Bilgus | I took a clip+ and hooked it up to an uammmeter and tested each but it needs run with battery bench to really get a good baseline and data for each to really be empirical evidence |
| 18:14:53 | saratoga | 20-40% for SD and i2C both? |
| 18:14:58 | johnb7 | the I2C made a significant difference for Fuze v1. |
| 18:15:17 | saratoga | sorry, i mean on amsv2? |
| 18:15:26 | saratoga | power management on amsv1 is all screwed up |
| 18:15:36 | _Bilgus | I'm ok with removing the menu leaving the back end and make it so you have to manually add entries to the config.cfg file to enable it |
| 18:16:46 | saratoga | on the e200v2, previously i couldn't mount SD with the voltage scaling patches, now I can mount with CPU power savings set to on, but sometimes folders are empty and it freezes after a while |
| 18:17:23 | _Bilgus | well then that device isn't going to work properly with HEAD |
| 18:18:11 | _Bilgus | so if it works with CPU power saving OFF then it still has voltage scaling |
| 18:18:31 | _Bilgus | but higher than the current defaults if that makes sense |
| 18:19:15 | saratoga | i'll let it loop for a bit and see what happens |
| 18:19:22 | saratoga | amsv1 is all screwed up though |
| 18:19:35 | _Bilgus | the other thing you should try is Disk power savings since it halves the sd clock it should (in theory) use less power |
| 18:19:39 | saratoga | the cpu is really slow for some reason and power consumption is very high relative to the Sandisk firmware |
| 18:19:43 | saratoga | so something is set very wrong |
| 18:20:08 | saratoga | why does cutting the SD clock make a difference? isn't the SD clock gated when the storage isn't being used? |
| 18:20:09 | _Bilgus | I fixed a lot in the disk driver for the V1 |
| 18:20:21 | _Bilgus | It wasn't before.. |
| 18:20:27 | saratoga | haha |
| 18:20:56 | _Bilgus | see here http://gerrit.rockbox.org/r/#/c/1737/22/firmware/target/arm/as3525/sd-as3525.c |
| 18:20:59 | saratoga | has any of this been investigated on amsv2? |
| 18:21:34 | saratoga | we went through the clocks quite carefully and i thought all were quite close to optimal |
| 18:21:55 | saratoga | Mihale tested everything and worked out how many mA were used for each thing |
| 18:22:02 | saratoga | mihail |
| 18:22:59 | _Bilgus | there wasn't a whole lot on the V2 its much closer to optimal than v1 but the margins for safety are too close |
| 18:24:17 | saratoga | as far as i know, the only recent v2 device with problems is the fuzev2, which makes sense since very few of those devices are out there and we couldn't test much |
| 18:24:29 | johnb7 | saratoga : I have all of this active on 2 clip+, 2 Fuze V2, 2 Fuze V1. I have not had any issues on the AMS v2. V1 sometimes freezes when copying data over from the PC, but not any worse than HEAD. |
| 18:24:32 | saratoga | so i've raised its voltage, which fixes the reported issue |
| 18:25:22 | saratoga | in general if there is some savings by lowering the SD clock or similar, i think the better approach is to just dynamically set the SD clock higher when in USB mode, and lower it when not needed |
| 18:25:34 | saratoga | or better yet idle the SD card entirely (if the hardware allows it) when not used |
| 18:25:38 | _Bilgus | I'm pretty sure these low voltages exacerbate the storage failure especially when they crash |
| 18:26:12 | _Bilgus | v1 allows sd throttling v2 doesn't |
| 18:26:18 | saratoga | yes quite possibly, we tried not to lower the sd card voltages, but apparently there is some connection between the CVDD1 voltage and SD on at least the fuzev2 |
| 18:28:05 | saratoga | anyway, the fact that the lower cpu voltage on the e200v1 makes the sd card crash isn't comforting |
| 18:28:05 | | Quit alce (Read error: Connection reset by peer) |
| 18:28:29 | _Bilgus | I think the only sane thing to do is raise ALL the voltages and screw battery life and maybe give a debug option to lower them |
| 18:28:44 | _Bilgus | which is what this powersave menu was all about |
| 18:28:57 | saratoga | i don't want a menu option for this |
| 18:29:02 | saratoga | just pick reasonable defaults |
| 18:29:26 | _Bilgus | reasonable defaults are the highest setting |
| 18:29:31 | saratoga | the reason mihail spent all this time testing devices on the forums was to figure out what the minimum was, then we did a few levels higher |
| 18:29:37 | saratoga | thats not reasonable |
| 18:29:55 | _Bilgus | and that doesn't have enough safety factor |
| 18:30:02 | _Bilgus | it kills players |
| 18:30:08 | saratoga | if you want to be as safe as possible, whatever the hardware sets itself to on boot |
| 18:30:11 | _Bilgus | not every player |
| 18:30:14 | saratoga | which is probably no where near maximum |
| 18:30:36 | saratoga | but of course, if you start doing dynamic frequency, then the voltage can be lowered below defaults, at least some |
| 18:30:45 | saratoga | we spent like a year testing this before committing it |
| 18:31:13 | saratoga | i think everything is ok on the clip+ and zip since those are what most people have, but we could think about going a little higher if there is concern |
| 18:31:28 | saratoga | i'm tempted to just put the fuzev2 a lot higher since its not well tested |
| 18:31:30 | _Bilgus | I'll bbl the users are the testers now and they speak volumes more just look all over the forum for evidence |
| 18:31:52 | saratoga | thats why we spent so long testing this before commiting |
| 18:32:38 | _Bilgus | I'd be tempted to say that voltage lowering has had more problems than just about anything else across the Sansa line We should revert it |
| 18:32:47 | _Bilgus | but its been there for too long |
| 18:33:08 | saratoga | i don't think there are many problems at this point, they're ironed out by last year |
| 18:33:31 | _Bilgus | there just aren't many players left to complain about it |
| 18:33:32 | saratoga | i didn't like mihail's approach of pushing the voltage very low, but he was willing to do a lot of testing, so i didn't argue with him too much |
| 18:33:51 | _Bilgus | theyve lost their players to failed flash |
| 18:33:59 | | Join alce [0] (~taz@mobile-access-b0485f-180.dhcp.inet.fi) |
| 18:34:22 | saratoga | by this point we've had a lot of people test on the more common devices and we don't seem to have any problems |
| 18:36:17 | _Bilgus | so what does it hurt to have an option for these low voltages and higher defaults |
| 18:36:43 | _Bilgus | you are arguing about how we tested them and its ok but you have an issue with higher? |
| 18:37:18 | _Bilgus | or is the issue with the menu and you would be ok with a manual edit of the .cfg file to set up lower settigns? |
| 18:37:45 | _Bilgus | anyways I gtg Ill discuss this later |
| 18:39:16 | saratoga | forcing users to guess if they can adjust the voltages does not make sense, we should just figure it out and implement properly |
| 18:39:48 | saratoga | plus given the range of other bugs we can run into, having each user running different voltagese makes it very hard to know if a bug is real or just too little voltage |
| 18:39:52 | | Quit alce (Read error: Connection reset by peer) |
| 18:40:08 | saratoga | from a support perspective, having everyone run the same hardware configuration is really, really helpful |
| 18:41:07 | saratoga | as for most of these settings, things like CVDD2 have an impact on runtime, but if we really think 2.75v isn't as safe for the sd card as the original default (2.8v) we should just give up a few minutes runtime and run at 2.8 |
| 18:41:50 | saratoga | i doubt the cpu voltage changes the sd card (since it runs at a higher voltage than the CPU), although it may cause the sd interface to fail if the cpu is undervolted too much |
| 18:42:40 | saratoga | i'm skeptical most of these changes even matter, at least on amsv2 |
| 18:43:13 | saratoga | or at least they should be well tested before implementing them to see if they actually matter |
| 18:45:17 | | Join alce [0] (~taz@mobile-access-b0485f-180.dhcp.inet.fi) |
| 19:00 |
| 19:06:01 | | Quit saratoga (Quit: Page closed) |
| 19:30:03 | | Quit quaz0r (Ping timeout: 260 seconds) |
| 19:42:30 | | Join quaz0r [0] (~quaz@c-73-83-233-219.hsd1.wa.comcast.net) |
| 19:44:27 | | Quit advcomp2019_ (Ping timeout: 256 seconds) |
| 19:46:53 | | Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) |
| 19:57:29 | | Quit johnb7 (Ping timeout: 256 seconds) |
| 19:58:49 | *** | Saving seen data "./dancer.seen" |
| 20:00 |
| 20:24:41 | | Quit thomasjfox (Quit: Konversation terminated!) |
| 20:34:48 | | Quit GeekShadow (Ping timeout: 260 seconds) |
| 20:52:21 | kingDi | So nothing new about wm1a kas cipher or format ? |
| 20:52:22 | | Quit alce (Read error: Connection reset by peer) |
| 20:57:39 | | Join alce [0] (~taz@mobile-access-b0485f-180.dhcp.inet.fi) |
| 21:00 |
| 21:07:57 | | Quit alce (Read error: Connection reset by peer) |
| 21:13:02 | | Join alce [0] (~taz@mobile-access-b0485f-180.dhcp.inet.fi) |
| 21:18:15 | | Quit Moarc (Quit: i znowu NADMUCHAŁ BALONA) |
| 21:23:37 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 21:26:13 | | Quit ZincAlloy (Quit: Leaving.) |
| 21:58:52 | *** | Saving seen data "./dancer.seen" |
| 22:00 |
| 22:02:16 | | Quit krabador (Ping timeout: 268 seconds) |
| 22:20:57 | | Join tomf [0] (~tomflint@unaffiliated/tomflint) |
| 22:21:52 | tomf | would rockbox on an ipod 5.5 have issues with a 4gb FLAC (16/44)? |
| 22:26:06 | tomf | oh, I think its related to 'sample/frame number mismatch in adjacent frame' |
| 22:26:34 | devponies[m] | i don't think it would |
| 22:27:00 | devponies[m] | though the filesystem probably can't fit it |
| 22:27:33 | tomf | yeah, I think the file size is ok. This is a mix I made for party using Audition. I think there's something with the mixdown that caused this error. I'm using an iflash quad. The file is just under 4gb |
| 22:27:44 | devponies[m] | fat32 has a max size of 4GiB-1B per file |
| 22:28:27 | devponies[m] | depends on if your flac is over or under that |
| 22:28:30 | | Join ZincAlloy [0] (~Adium@2a02:8108:9440:1870:f994:917c:d812:da0c) |
| 22:28:56 | devponies[m] | you'll have to get it under that somehow if it's over that |
| 22:29:04 | tomf | yeah, its actually closer to 3gb it seems −− so thats a breeze |
| 22:29:11 | tomf | that error is from ffmpeg |
| 22:30:42 | devponies[m] | tomf: but why do you need a 1-2[2-3 if mono] hour long flac? |
| 22:30:56 | tomf | its nearly seven hours :) |
| 22:31:08 | tomf | its all mixed and beatmatched |
| 22:31:37 | tomf | foobar plays it perfectly −− but its a curious error |
| 22:39:04 | tomf | oh well, its not important. Just trying to sort out the cause of the issue. It looks like its the actual export that caused it |
| 23:00 |
| 23:33:19 | | Quit Jinx (Quit: reboot) |
| 23:58:55 | *** | Saving seen data "./dancer.seen" |
icon identifies that the person is a core developer (has commit access).