| 00:00:23 | Bagder | and yes I agree it sounds like the AMS mode |
| 00:00:25 | linuxstb | Are you sure that's a v2 for that price? There are a lot of refurbished m2x0s around, and at least the one I bought was a v1. |
| 00:00:41 | linuxstb | But for that price, you could risk it anyway... |
| 00:01:00 | | Join fyre^OS [0] (n=fyre@cpe-68-173-171-53.nyc.res.rr.com) |
| 00:01:18 | toffe82 | BigBambi: it was done via I pod first and via caddy after |
| 00:01:27 | saratoga22 | the V2s apparently came out 18 months ago for the M series, so I doubt theres too many refurb V1s still around |
| 00:02:01 | | Join CyBergRind|w [0] (n=cbr@212.98.160.130) |
| 00:02:23 | linuxstb | Maybe I was just lucky then... (I wanted a v1). |
| 00:02:55 | saratoga22 | hmm the new ones are only $20, so that'd make more sense |
| 00:03:48 | linuxstb | What capacity are the ones for that price? I paid 20GBP (almost $40) for my refurbished m260 (4GB) in the UK. |
| 00:03:57 | saratoga22 | 1 GB |
| 00:04:06 | | Join Synergy6 [0] (n=Synergy6@0-1b-24-4c-ae-79.hb.esol.dur.ac.uk) |
| 00:04:12 | linuxstb | OK, I feel better then ;) |
| 00:04:12 | | Quit Xerion (Read error: 104 (Connection reset by peer)) |
| 00:04:15 | saratoga22 | perfect for bricking |
| 00:04:40 | | Join moos [0] (n=c40cd998@gateway/web/cgi-irc/labb.contactor.se/x-21d8a6a6c86bd0b2) |
| 00:04:46 | | Join Xerion [0] (n=xerion@cp198589-d.landg1.lb.home.nl) |
| 00:05:12 | moos | jhMikeS: ping |
| 00:05:19 | toffe82 | saratoga22: will you bid on the S30 , the one finishing in 2H ? |
| 00:06:23 | | Quit DerDome ("Leaving.") |
| 00:07:44 | saratoga22 | i already did :) |
| 00:07:51 | | Quit bluebrother ("Verlassend") |
| 00:09:26 | toffe82 | ok, just to don't bid on this one ;) |
| 00:10:21 | saratoga22 | were you looking to get another one? |
| 00:14:56 | | Quit barrywardell () |
| 00:16:27 | toffe82 | not really, just for spare parts and who knows, the lcd on this one is perhaps working |
| 00:18:41 | | Quit fyrestorm (Read error: 113 (No route to host)) |
| 00:19:08 | | Quit [CBR]Unspoken|w (Read error: 110 (Connection timed out)) |
| 00:20:07 | saratoga22 | i think probably half the gigabeats on ebay are broken |
| 00:21:01 | | Quit fyre^OS (Read error: 113 (No route to host)) |
| 00:22:44 | | Quit dabujo ("( www.nnscript.com :: NoNameScript 4.2 :: www.regroup-esports.com )") |
| 00:23:29 | | Join mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere) |
| 00:24:23 | | Quit robin0800 (Read error: 104 (Connection reset by peer)) |
| 00:25:47 | mcuelenaere | why does gcc assembly "x &= ~y;" to "LDR R0, =[~y]\nAND x, x, R0" instead of "BIC x,x,#y"? is there an optimisation flag for this? |
| 00:26:05 | | Quit Horscht ("electromagnetic radiation from satellite debris") |
| 00:26:38 | mcuelenaere | assemble* |
| 00:29:50 | linuxstb | Is y a constant? |
| 00:30:42 | linuxstb | I'm sure I've seen gcc use bic in those cases. |
| 00:30:56 | mcuelenaere | yes, y is a constant |
| 00:31:25 | mcuelenaere | if gcc would do this all the time, wouldn't be this a total loss of binary size (and RAM usage)? |
| 00:32:48 | linuxstb | What's the exact statement it's not using bic for? |
| 00:33:38 | mcuelenaere | for example "IO_CLK_MOD1 &= ~(CLK_MOD1_VENC | CLK_MOD1_OSD);" |
| 00:33:46 | mcuelenaere | CLK_MOD1_x are macro's |
| 00:33:49 | amiconn | mcuelenaere: Depends on your y. In order to use bic, y needs to be an allowed arm constant |
| 00:33:58 | | Quit Synergy6 ("Adios") |
| 00:34:08 | mcuelenaere | it should be possible, as the OF uses BIC |
| 00:34:17 | mcuelenaere | and the code is identical |
| 00:34:26 | mcuelenaere | well, maybe not in C; but in ASM it should be |
| 00:36:14 | * | amiconn isn't surprised though that gcc doesn't pick up all possible optimisations |
| 00:36:48 | mcuelenaere | maybe a stronger optimisation has to be set in the Makefile? |
| 00:36:55 | amiconn | nah |
| 00:37:17 | amiconn | If you set higher -O levels, all you achieve most of the time is bigger code which runs slower |
| 00:37:27 | linuxstb | gcc definitely uses bic quite a lot though - to implement &= ~x |
| 00:37:41 | mcuelenaere | mm strange |
| 00:38:01 | amiconn | linuxstb: Yes, but I'm not surprised it doesn't pick up all opportunities to do this |
| 00:38:37 | bertrik | maybe it has something to do with IO_CLK_MOD1 being volatile or not |
| 00:38:41 | amiconn | gcc isn't very good at optimising (perhaps it is on x86 - that's something I don't know at all) |
| 00:39:22 | amiconn | That's why the most time critical code parts in rockbox are often written in asm |
| 00:39:24 | mcuelenaere | this is a pastebin http://pastebin.com/d4e221b30 |
| 00:39:38 | mcuelenaere | above is rockbox, below OF |
| 00:40:26 | linuxstb | bertrik: I've just tried "REG &= ~0x18" (which IIUC is your statement), and gcc used bic... |
| 00:40:37 | linuxstb | This is compiling for the m200 |
| 00:41:01 | mcuelenaere | IO_CLK_MOD1 is a volatile unsigned short*, would that be it? |
| 00:41:27 | linuxstb | In my code regs are longs (but also volatile) |
| 00:41:59 | mcuelenaere | they have to be 16-bit accesses |
| 00:42:10 | | Quit gevaerts ("sleeping") |
| 00:42:39 | linuxstb | Ah, that's the difference - gcc uses bic for longs, but not shorts... |
| 00:42:46 | amiconn | mcuelenaere: That means that gcc cannot use bic without a separate hint |
| 00:43:04 | mcuelenaere | amiconn: and that hint is? |
| 00:43:10 | bertrik | hmm, does it *really* have to be 16-bit? |
| 00:43:22 | mcuelenaere | hmm, as far as I know yes |
| 00:44:26 | amiconn | A short only fills half of a reg, and hence it cannot use bic for &=. You need to experiment a little - maybe some casting will do the trick |
| 00:44:42 | mcuelenaere | datasheet says: "Address 0x0003:xxxx - This area should be accessed by half word (16-bit)" |
| 00:45:12 | amiconn | A somewhat nasty expression that should do the trick though: |
| 00:45:54 | amiconn | IO_CLK_MOD1 = (unsigned int)IO_CLK_MOD1 & ~(CLK_MOD1_VENC | CLK_MOD1_OSD); |
| 00:46:51 | mcuelenaere | and if I would do #define IO_CLK_MOD1 (unsigned int)(*(volatile unsigned short*)(0x***)); would that work too? |
| 00:47:18 | amiconn | perhaps |
| 00:47:45 | amiconn | I wouldn't care too much about this though, unless this code is executed several thousands of times per second |
| 00:48:12 | mcuelenaere | ah ok, thanks |
| 00:48:13 | linuxstb | amiconn: That doesn't seem to work... |
| 00:49:07 | mcuelenaere | and why does GCC insists on doing "LDR R3, =function\nBLX R3" ? I've not seen "BL function " very much |
| 00:49:18 | bertrik | all calls on arm being long (as amiconn explained to me) probably also helps a lot in increasing the binsize |
| 00:49:33 | amiconn | Not all calls are long |
| 00:49:52 | bertrik | ok, I misunderstood then |
| 00:49:59 | amiconn | Calls within the same section are short, and calls to static functions are always short |
| 00:50:39 | amiconn | Calls to iram functions are always long though (because it's a separate section), except on iFP |
| 00:51:21 | mcuelenaere | ah, you're right now I see |
| 00:51:49 | mcuelenaere | I just thought it would always do long calls (which would double binsize for these calls) |
| 00:53:31 | bertrik | I was confused by the -mlong-calls compiler option thinking it forced *all* calls to be long |
| 00:53:43 | amiconn | The only other reason where this bic vs. ldr/and issue matters would be if you're short on memory |
| 00:54:02 | amiconn | Not sure how much ram the zvm has |
| 00:54:08 | mcuelenaere | 64MB :) |
| 00:55:28 | amiconn | ...or for some reason the loadable firmware file size is limited |
| 00:56:15 | | Quit mf0102 (Remote closed the connection) |
| 00:56:15 | mcuelenaere | naah, not that I know of :) |
| 00:56:19 | amiconn | Both reasons apply to the archoses, and the first one applies to the iFP (but that port seems to be almost dead, unfortunately) |
| 00:56:57 | amiconn | (archos isn't arm based of course) |
| 00:58:01 | | Quit faemir (Remote closed the connection) |
| 01:00 |
| 01:04:25 | linuxstb | My two telechips devices (M260 and DAX) only have 2MB RAM... But at least they're flash-based. |
| 01:05:08 | amiconn | Yeah, but nevertheless you should try to keep rockbox' memory footprint low on them |
| 01:05:34 | linuxstb | Of course. |
| 01:05:52 | linuxstb | The hardware's very simple though - and the LCD is just 128x64 mono |
| 01:06:10 | amiconn | There are several cases where more ram gives better experience - higher jpeg size limit |
| 01:06:15 | amiconn | ...for instance |
| 01:06:23 | amiconn | *more free ram |
| 01:07:33 | Nico_P | I'd be curious to see how the buffering code behaves on such targets |
| 01:07:55 | linuxstb | Nico_P: I was meaning to ask if you've tested buffering with a tiny buffer... |
| 01:07:59 | Nico_P | it ought to be fine of course, but still |
| 01:08:02 | Nico_P | linuxstb: no |
| 01:08:19 | | Quit bepe86 (Read error: 104 (Connection reset by peer)) |
| 01:08:20 | | Join Bepe_ [0] (n=Bepe@213.151.130.162) |
| 01:08:38 | Nico_P | but I guess it's the same as a 32 MB buffer and even bigger tracks |
| 01:09:15 | amiconn | linuxstb: Maybe you event want -Os on those targets |
| 01:09:22 | linuxstb | Do we still have that 512KB codec malloc buffer? |
| 01:09:30 | n1s | linuxstb: the voice file for most targets is around 800k so it could get cramped in there... |
| 01:09:35 | n1s | linuxstb: i think so |
| 01:10:08 | Nico_P | isn't vorbis the only codec that really needs it? |
| 01:10:29 | linuxstb | Yes, I think so. But others use it a little as well - just because it's there... |
| 01:10:47 | n1s | maybe it doesn't need to be so frigging huge |
| 01:11:14 | amiconn | And the codec and plugin ram should probably be reduced. Not sure whether 32KB of plugin ram (as on archos) are sufficient though - arm code tends to be bigger than sh1 code |
| 01:11:15 | linuxstb | And I guess I can get away with an almost Archos-sized plugin buffer. |
| 01:11:39 | amiconn | 48KB should definitely do though |
| 01:11:46 | linuxstb | Yes, that's the figure I was thinking. |
| 01:11:52 | amiconn | iFP used 64KB iirc |
| 01:12:03 | amiconn | And that one only has 1MB ram |
| 01:13:11 | | Quit csc` ("If you can't do anything smart, do somethin right ~Serenity") |
| 01:13:40 | | Quit lee-qid (Read error: 110 (Connection timed out)) |
| 01:14:22 | linuxstb | It's not even complete yet, and rockbox.bin is about 390KB for the m200... |
| 01:14:31 | * | amiconn ponders whether he should pick up the iFP port... |
| 01:14:40 | amiconn | Try -Os ... |
| 01:14:48 | linuxstb | Just about to... |
| 01:15:25 | linuxstb | Is changing it in the Makefile in the build directory enough? |
| 01:15:43 | n1s | should be + make clean of course |
| 01:16:16 | | Join petur [50] (n=petur@rockbox/developer/petur) |
| 01:16:24 | linuxstb | Hmm, down to 366064 (was about 392000) |
| 01:16:54 | Nico_P | amiconn: considering the small size of the potential audience, I'd say it's not a top priority port |
| 01:17:16 | Nico_P | but it could be fun of course |
| 01:18:07 | amiconn | It's somewhat challenging |
| 01:18:20 | amiconn | Just 1MB RAM and 60MHz single core arm7tdmi |
| 01:19:21 | amiconn | Not sure which other DAPs exist that use the PNX0101 |
| 01:20:31 | * | linuxstb feels spoilt - 2MB RAM and 120MHz |
| 01:21:27 | amiconn | linuxstb: The size gain sounds reasonable. ARM code is bigger than SH1 code, and swcodec has somewhat more core code than hwcodec |
| 01:21:57 | | Quit styleism (Read error: 110 (Connection timed out)) |
| 01:21:59 | linuxstb | Yes, including speex... |
| 01:22:25 | amiconn | Maybe someone should have a look at thumb again, for non time critical stuff |
| 01:23:14 | amiconn | linuxstb: The spoiling goes one step further - iirc telechips is arm9 |
| 01:24:05 | * | linuxstb promises not to clock it faster that 50MHz ;) |
| 01:24:32 | * | amiconn is curious whether the logikdax will be able to decode ape realtime, and which compression level(s) |
| 01:24:53 | linuxstb | There's a list of PNX0101 players here - http://forum.mp3store.pl/index.php?showtopic=14695&mode=threaded |
| 01:24:59 | linuxstb | Seems quite a few. |
| 01:25:28 | n1s | amiconn: will the ifp be able to? ;) |
| 01:25:47 | amiconn | n1s: Haha, even the PP targets aren't... |
| 01:26:12 | linuxstb | amiconn: IIRC, armv5 has got some DSP instructions which should help with APE, so it should be reasonable. |
| 01:27:26 | * | amiconn wonders why he remembered 60MHz for the PNX0101 |
| 01:29:27 | * | Nico_P is pleased to see users don't seem to be complaining about playback too much ATM |
| 01:29:30 | toffe82 | saratoga22: still winner ? |
| 01:30:46 | amiconn | linuxstb: Did you take a look at that libavcodec range decoder? |
| 01:31:08 | moos | Nico_P: playback seems just fine, just encountered problems with playlist operations |
| 01:31:34 | * | mcuelenaere wonders himself why linux doesn't have a logical target tree like Rockbox.. |
| 01:31:49 | Nico_P | moos: it's not quite as fine as I'd like it to be, but it seems good enough that I can rest for a bit before going back to it :) |
| 01:32:46 | * | amiconn would in fact like to do that just for the challenge, but can't afford to do so atm :/ |
| 01:32:54 | moos | hehe :) |
| 01:32:56 | amiconn | Too many other things on my list already |
| 01:33:03 | linuxstb | amiconn: Only superficially, and I couldn't see how it could replace what APE is using. I also don't think the ffmpeg have done anything with it either. |
| 01:33:37 | linuxstb | But I'm sure there must be room for optimisation there somewhere (or elsewhere in that part of the code). |
| 01:34:55 | amiconn | I think the predictor can be optimised a bit more on coldfire, by carefully checking which register is "reserved" for how long, and then converting some stack vars into register vars |
| 01:35:19 | *** | Saving seen data "./dancer.seen" |
| 01:35:23 | amiconn | But more than half of the decoding time is spent in the range decoder at -c1000 |
| 01:38:10 | amiconn | Optimising the predictor might be enough to make -c3000 usable on coldfire |
| 01:39:05 | | Quit ompaul (Client Quit) |
| 01:42:14 | saratoga22 | toffe82: yes still winning |
| 01:42:46 | saratoga22 | doesn't FAAC use the malloc buffer too? |
| 01:43:19 | linuxstb | The mp4 parser does - for the seektable (a list of frame sizes) |
| 01:43:27 | linuxstb | I'm not sure about FAAD itself |
| 01:43:33 | linuxstb | But I expect so. |
| 01:43:42 | saratoga22 | mp4 frames are variable sized? |
| 01:44:06 | linuxstb | Yes |
| 01:44:23 | saratoga22 | or do you mean AAC frames |
| 01:45:00 | | Quit ender` (" Trying to establish voice contact ... please yell into keyboard.") |
| 01:45:02 | linuxstb | I mean mp4 packets |
| 01:45:31 | linuxstb | IIRC, they can vary both in duration (number of samples) and size in bytes. |
| 01:45:44 | saratoga22 | how annoying |
| 01:46:02 | saratoga22 | how is one supposed to deal with this normally? |
| 01:46:24 | saratoga22 | i can't image the format expects lots of space to buffer seek tables |
| 01:46:37 | | Quit bertrik ("bye") |
| 01:48:34 | * | linuxstb shrugs |
| 01:49:19 | n1s | 4.45 runtime on my S30 with q4 oggs |
| 01:50:37 | n1s | a whooping 38% of the qouted 12.30 runtime for the OF, room for improvement :) |
| 01:52:26 | BigBambi | n1s: hmmm |
| 01:52:34 | n1s | now let's hope batter_bench worked ok |
| 01:52:40 | n1s | battery |
| 01:54:51 | * | linuxstb wonders how the beast would do with insane APE files |
| 01:55:23 | * | n1s has 0 ape files and is not aware of any linux encoders |
| 01:55:43 | Nico_P | n1s: only 4.45? that's really not very good |
| 01:55:46 | linuxstb | The command-line encoder works fine with Wine - do you want it? |
| 01:56:10 | n1s | linuxstb: sure, can't test now though, needs to recharge |
| 01:56:22 | linuxstb | Ah, in fact I have a Linux binary... |
| 01:57:03 | n1s | Nico_P: we don't power down the HD, scale frequency (or adjust core voltage) |
| 01:57:18 | Nico_P | hmm, true |
| 01:58:10 | | Quit mcuelenaere () |
| 01:58:19 | n1s | and maybe some hardware inside the soc as well as outside is left on? |
| 01:59:13 | Nico_P | I have trouble imagining WinCE as very battery efficient though :p |
| 01:59:40 | linuxstb | As shown by it's tendency to keep the hard disk spinning... |
| 02:00 |
| 02:00:08 | Nico_P | indeed. something tells me that's not all |
| 02:01:19 | linuxstb | I guess we'll find out soon enough. |
| 02:01:54 | | Quit petur ("killed by baileys") |
| 02:03:18 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
| 02:03:33 | toffe82 | saratoga22: winner :) |
| 02:05:27 | Nico_P | another beast owner? :) |
| 02:06:27 | BigBambi | Long live the beast hegemony! |
| 02:06:42 | XavierGr | Indeed, I will start using it as my main player |
| 02:07:05 | XavierGr | I need to battery_bench the beast to make sure that it lives to its legend. |
| 02:08:53 | | Quit Nico_P ("bed time") |
| 02:09:07 | | Join linuxstb_ [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 02:09:42 | saratoga22 | i've still got 10 minutes to go! |
| 02:10:05 | saratoga22 | i think theres going to be more beast developers then beast users |
| 02:10:22 | BigBambi | good! |
| 02:11:08 | toffe82 | saratoga22: I thought you were bidding on the broken one , it finished at 15$ |
| 02:11:28 | saratoga22 | no i'm bidding on a working one |
| 02:13:38 | scorche | toffe82: what was broken about it? |
| 02:13:58 | toffe82 | lcd ? they didn't say it |
| 02:14:07 | saratoga22 | the guy didn't say, other then that it wouldn't turn on |
| 02:14:28 | scorche | thats a shame...for $15.. |
| 02:14:49 | saratoga22 | unless people say the screen works, i tend to assume its broken, since half of ebay gigabeats are people selling ones with broken screens |
| 02:15:18 | krazykit | i need an s60 with a broken screen if saratoga22 wins the working one ;) |
| 02:15:43 | | Join webtaz [0] (n=webtaz@p4FD4A064.dip0.t-ipconnect.de) |
| 02:15:48 | saratoga22 | those seem hard to find |
| 02:15:53 | saratoga22 | i looked for a bit |
| 02:15:56 | webtaz | hello |
| 02:16:15 | toffe82 | I misunderstood, I wanted to bid on the broken one :( |
| 02:16:18 | krazykit | i'm not finding a lot of s60s on ebay, unless somehow i just fail at searching. |
| 02:16:52 | saratoga22 | toffe82: sorry, didn't realize there'd be two auctions ending at almost the exact same time |
| 02:17:07 | webtaz | I'm trying to sync a patch, and could need a bit help with the playback_control (or the changes wich viewport did to it) |
| 02:17:19 | toffe82 | that's ok, there are some more ;) |
| 02:19:36 | linuxstb_ | webtaz: What's the problem? (or what's the patch?) |
| 02:19:47 | webtaz | dict2 patch |
| 02:19:48 | | Quit linuxstb (Nick collision from services.) |
| 02:19:51 | | Nick linuxstb_ is now known as linuxstb (n=linuxstb@rockbox/developer/linuxstb) |
| 02:20:42 | webtaz | i managed to fix some changes wich are related to viewports, by taking the changes from a actual build which has this patch build in |
| 02:21:03 | webtaz | but this build uses an old version of the playback_control.h i think |
| 02:21:19 | webtaz | so i cant reuse the term of it |
| 02:21:25 | | Nick JdGordon|zzz is now known as JdGordon (i=jonno@rockbox/developer/JdGordon) |
| 02:21:28 | linuxstb | Have you changed the call to playback_control(rb) to playback_control(rb,NULL) ? |
| 02:21:59 | | Quit XavierGr (Nick collision from services.) |
| 02:22:00 | webtaz | mhh |
| 02:22:10 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
| 02:22:10 | webtaz | no that's it |
| 02:22:21 | webtaz | i just cant see what the arguments have to be |
| 02:22:34 | webtaz | i just saw there has to be one more |
| 02:22:35 | linuxstb | I just looked at all the other plugins that use playback control - they all call it with (rb,NULL). |
| 02:23:08 | webtaz | well i started my player, but i just couldnt find a game that uses this |
| 02:23:09 | webtaz | ^^ |
| 02:23:21 | webtaz | i think i should have tried some others |
| 02:23:26 | linuxstb | 'grep playback_control *.c' (in the plugins directory) |
| 02:23:47 | webtaz | ohh |
| 02:23:55 | webtaz | i'm working with windows |
| 02:24:10 | webtaz | just applying patches and compiling with linux |
| 02:24:19 | saratoga22 | alright won a gigabeast |
| 02:24:35 | BigBambi | \รด/ |
| 02:24:55 | webtaz | beast?^^ |
| 02:25:10 | BigBambi | gigabeat S aka gigabeast aka the beast |
| 02:25:10 | | Quit saratoga22 ("CGI:IRC") |
| 02:25:26 | linuxstb | A typo that stuck... |
| 02:25:31 | BigBambi | as it is monstrously powerful, hence a beast |
| 02:25:31 | webtaz | i got a F |
| 02:25:39 | BigBambi | F is good too |
| 02:25:50 | webtaz | i think S was too expensive when i bought it |
| 02:25:52 | | Join saratoga [0] (n=9803c50e@gateway/web/cgi-irc/labb.contactor.se/x-d2f86ea6012751ba) |
| 02:25:59 | webtaz | also not to get in Europe |
| 02:26:08 | webtaz | or difficult |
| 02:26:39 | webtaz | i was lucky with taxes |
| 02:27:00 | webtaz | customs -> taxes on goods which go over borders? |
| 02:27:25 | BigBambi | yes |
| 02:27:53 | saratoga | or at least the taxmen who check the goods |
| 02:28:08 | BigBambi | customs duty = the tax |
| 02:32:15 | orang1 | In Canada, there is no duty on US computer electronics coming into the country but there is still the provincial tax. |
| 02:33:19 | webtaz | coming into ^^ i just could want sth coming out to me |
| 02:33:20 | webtaz | ^^ |
| 02:33:21 | BigBambi | Same thing really. In Europe you have to pay the VAT of the country you are importing it into. However, this is off topic... |
| 02:34:02 | webtaz | but interresting |
| 02:34:39 | webtaz | -r |
| 02:35:03 | BigBambi | off topic nonetheless |
| 02:36:46 | webtaz | come on, at the moment here is no topic, i think, and if you think wide it is related to rockbox :) |
| 02:37:00 | webtaz | but I'll soon bring on a new topic |
| 02:37:12 | webtaz | when, during compilation, the next error occurs |
| 02:37:49 | BigBambi | webtaz: Please read the topic and the guidelines |
| 02:38:06 | linuxstb | This channel is logged though - and people read the logs to see what developments they missed... |
| 02:38:10 | BigBambi | This is a logged development and support channel for Rockbox only |
| 02:38:34 | webtaz | play |
| 02:38:39 | webtaz | okay |
| 02:39:06 | BigBambi | for off topic ramblings please see #rockbox-community |
| 02:39:24 | webtaz | already found my way in that channel ;) |
| 02:39:36 | jhMikeS | moos: pong |
| 02:42:32 | n1s | jhMikeS: i did a battery_bench and got 4.45 on my S30, will try to make a first stab at a discharge curve tomorrow |
| 02:44:34 | jhMikeS | 4.45? I think we need to start turning unused devices off. :) |
| 02:44:51 | saratoga | or at least spinning down the hard disk |
| 02:45:16 | BigBambi | or both :) |
| 02:45:17 | n1s | saratoga: it spinns down but is not powered down, but i think i know the gpio for that |
| 02:45:23 | saratoga | ah |
| 02:45:27 | saratoga | misread then |
| 02:45:42 | jhMikeS | there's two GPIOs for the HD power |
| 02:46:23 | | Quit Zarggg (Read error: 104 (Connection reset by peer)) |
| 02:46:36 | n1s | then I think I know one of them :) |
| 02:46:42 | | Join Zarggg [0] (n=z@216-15-73-111.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
| 02:47:18 | n1s | if I unset bit 5 in gpio3dr rockbox hangs when trying to access the drive |
| 02:47:50 | n1s | jhMikeS: do you know which ones they are? |
| 02:47:58 | jhMikeS | one is to enable the ata interface and the other is the actual power |
| 02:48:12 | jhMikeS | I'm looking for my notes on that :) |
| 02:49:44 | jhMikeS | I thought maybe MCU2_16 was the ATA interface and MCU3_5 was the HD power (3_5 shut it down) |
| 02:51:47 | jhMikeS | I'll try to confirm on the tracing board for the other |
| 02:52:49 | n1s | ok, it's bedtime for me now :) goodnight |
| 02:52:52 | | Quit n1s () |
| 02:55:59 | | Quit spiorf (Remote closed the connection) |
| 02:56:19 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
| 02:57:34 | | Quit Horscht (Client Quit) |
| 02:57:37 | | Join webguest46 [0] (n=443be67b@gateway/web/cgi-irc/labb.contactor.se/x-535353ff241bad87) |
| 02:57:43 | | Quit webguest46 (Client Quit) |
| 03:00 |
| 03:00:27 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
| 03:14:32 | | Join Monkeytamer [0] (n=chatzill@24-205-228-141.dhcp.snlo.ca.charter.com) |
| 03:21:32 | | Join Hillshum [0] (n=chatzill@75-165-234-225.slkc.qwest.net) |
| 03:32:11 | | Join Monkeytamer_ [0] (n=chatzill@24-205-228-141.dhcp.snlo.ca.charter.com) |
| 03:35:23 | *** | Saving seen data "./dancer.seen" |
| 03:37:24 | | Quit webtaz (Read error: 110 (Connection timed out)) |
| 03:38:45 | JdGordon | anyone have any ideas how the quickscreen should be voiced? |
| 03:40:40 | jhMikeS | audibly? :p |
| 03:41:26 | JdGordon | :) |
| 03:41:36 | JdGordon | just when the option changes? |
| 03:43:10 | jhMikeS | I suppose the only other option is to start voicing the settings upon entry and stop that if a button is pushed and then voice the change |
| 03:48:23 | | Quit Monkeytamer (Read error: 110 (Connection timed out)) |
| 03:50:08 | | Join sdoyon [0] (n=steph@modemcable183.152-83-70.mc.videotron.ca) |
| 03:50:47 | JdGordon | speak of the devil... |
| 03:51:01 | JdGordon | sdoyon: looking forward to a talking quickscreen patch :) |
| 03:51:05 | jhMikeS | JdGordon: pong |
| 03:51:15 | JdGordon | ping? |
| 03:51:26 | sdoyon | JdGordon: huh? |
| 03:51:36 | * | jhMikeS responded to above statement :) |
| 03:51:54 | | Quit tessarakt ("Client exiting") |
| 03:52:11 | JdGordon | sdoyon: the quickscreen has been udpated so it should be voicable... not sure the best way to do it though so I havnt |
| 03:52:31 | jhMikeS | ...about the "devil" thing :p |
| 03:52:32 | sdoyon | Hmm... FS #6171 has been sitting in the tracker forever... |
| 03:52:41 | * | scorche waves at sdoyon |
| 03:52:48 | sdoyon | Hi |
| 03:53:53 | * | Hillshum wants to write in the wiki to help with the v2 port |
| 03:54:21 | JdGordon | sdoyon: ah ok.. so you want it all voiced on eneter then on changes? |
| 03:55:10 | | Join homielowe [0] (n=eric_j_l@66.183.89.40) |
| 03:55:12 | sdoyon | Yes, seems right, since you can interrupt it anytime if you know what you want. |
| 03:55:25 | JdGordon | ok |
| 03:55:44 | sdoyon | Guess I need to catch up on this. Are the options the same? |
| 03:55:51 | JdGordon | yeah |
| 03:56:07 | JdGordon | if I get my way they wont have to be though :) |
| 03:56:20 | sdoyon | Ah. I see. |
| 03:58:08 | sdoyon | I never committed that patch because I got side-tracked speculating on quick access to functions useful for voice users... you probably vaguely remember a thread about that ages ago. Mainly my conclusion is the two really useful things we're missing is speaking the time and battery level, without having to go all the way to the info menu. |
| 03:58:45 | sdoyon | In my copious spare time (cough) I meant to see if we could just hack this in on top of the current quickscreen, triggering on SELECT. |
| 03:59:04 | sdoyon | Outrageous, or conceivable? |
| 03:59:44 | sdoyon | SELECT for time and LONG SELECT for battery. Seem that key is unused for most targets in the quickscreen? |
| 03:59:55 | JdGordon | maybe |
| 04:00 |
| 04:04:16 | Hillshum | can i get wiki write access to help with sansav2? |
| 04:11:33 | JdGordon | sdoyon: done |
| 04:11:40 | JdGordon | not the clock thing though |
| 04:11:56 | JdGordon | Hillshum: HiltonShumway?? |
| 04:12:38 | sdoyon | Oh! OK I'll try it. |
| 04:12:50 | Hillshum | JDgordon: yeah, sorry |
| 04:13:00 | JdGordon | done |
| 04:13:06 | Hillshum | thanx |
| 04:16:50 | saratoga | Hillshum: which sansa do you have? |
| 04:17:00 | Hillshum | e200v2 |
| 04:17:19 | Hillshum | e260 |
| 04:17:29 | Hillshum | to be specific |
| 04:17:59 | saratoga | Hillshum: can you verify that the "special mode" here does not work on the e200? http://daniel.haxx.se/sansa/v2.html |
| 04:18:47 | advcomp2019 | saratoga, i looked at that and that is just msc mode |
| 04:18:56 | Hillshum | yup |
| 04:19:04 | saratoga | is it the same MSC mode as you get in the OF? |
| 04:19:10 | Hillshum | yeah |
| 04:19:25 | Hillshum | but it still could act as recovery mode |
| 04:19:33 | saratoga | so the player boots into the OF normally before connecting? |
| 04:20:07 | advcomp2019 | saratoga, yea.. i have a clip and the folder are the same too |
| 04:20:08 | Hillshum | yeah |
| 04:21:02 | saratoga | what happens when you disconnect? does it need to reboot or does it stay in the OF? |
| 04:21:15 | Hillshum | also, when it Auto-Dectect or the first OF MSC will load if OS does not have MTP |
| 04:21:42 | Hillshum | it refreshes database and stays in of (i think) |
| 04:21:55 | * | Hillshum gets his v2 |
| 04:22:37 | | Quit Monkeytamer_ ("ChatZilla 0.9.81 [Firefox 3.0b5/2008032620]") |
| 04:23:54 | | Quit daurn ("Cyas later...") |
| 04:23:56 | Hillshum | if the flash was written |
| 04:24:12 | Hillshum | both in MSC and MTP |
| 04:24:20 | advcomp2019 | saratoga, it just depends.. if something writes to it, it will do "database refresh" other then that it will boot normal |
| 04:24:44 | saratoga | well if its not rebooting afterwards, its not the AMS UMS mode |
| 04:24:50 | saratoga | so scratch that idea |
| 04:24:50 | Hillshum | it doesnt give the splash screen |
| 04:25:53 | * | Hillshum will try after holding down |<< |
| 04:26:56 | advcomp2019 | s/boot/reboot |
| 04:27:12 | Hillshum | if it will MSC(mebby i need auto detect) |
| 04:27:50 | | Quit Bepe_ (Read error: 104 (Connection reset by peer)) |
| 04:28:06 | | Join bepe86 [0] (n=Bepe@213.151.130.162) |
| 04:29:37 | Hillshum | hmm... 5+ times won't load MSC While |<< is down. Maybe that got scratched in v x.16 |
| 04:29:59 | saratoga | how are you doing it? |
| 04:33:28 | Hillshum | push |<<, plug in, see WMP pop up with MTP |
| 04:34:06 | saratoga | the hold thing doesn't make any difference? |
| 04:37:14 | | Quit homielowe () |
| 04:38:28 | Hillshum | no |
| 04:38:42 | saratoga | i guess that feature isn't on the e series |
| 04:38:46 | saratoga | odd that they would do that |
| 04:38:58 | Hillshum |
icon identifies that the person is a core developer (has commit access).