00:00:29 | | Join funman_ [0] (n=fun@65.167.72-86.rev.gaoland.net) |
00:01:07 | | Quit froggyman (Read error: 104 (Connection reset by peer)) |
00:01:30 | | Quit evilnick ("http://www.mibbit.com ajax IRC Client") |
00:01:33 | | Quit faemir ("Leaving") |
00:02:10 | mt | saratoga : Sure. I have that on mind. |
00:02:29 | mt | And share the same bitstream files with wma ? |
00:02:59 | saratoga | well for now you can just change cook_mdct_backwards to mdct_backwards I think |
00:03:13 | saratoga | it looks like you've already included the codec library's imdct, you just don't call it :) |
00:03:39 | markun | mt: and can you measure the speedup? |
00:03:57 | markun | saratoga: it's tremor's imdct, right? |
00:04:17 | saratoga | markun: yes but with assembly optimizations |
00:05:57 | saratoga | do i have to enable building cook somewhere? |
00:06:41 | mt | saratoga : Alright will do. I'm just gathering some ideas, can't code now actually. :) |
00:07:24 | saratoga | sure |
00:07:35 | saratoga | what do I have to do to make cook compile? |
00:08:04 | mt | markun : Haven't tried it before really, but will surely try. |
00:08:19 | mt | saratoga : the test program you mean ? |
00:08:40 | saratoga | i thought you had it working in the sim? |
00:09:12 | mt | Yes but I haven't uploaded any patches for that yet. |
00:09:22 | saratoga | ah ok |
00:10:37 | mt | Something weird is happening with metadata tags, when that's is fixed I could post a patch. |
00:11:44 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
00:11:59 | linuxstb | mt: Or you could post a patch and maybe someone else will spot the bugs. |
00:12:34 | | Quit TheSphinX^ (Remote closed the connection) |
00:13:20 | kugel | we definitely have too much open bug reports :/ |
00:15:15 | | Quit funman (Read error: 113 (No route to host)) |
00:15:40 | | Join webguest18 [0] (n=562d5469@gateway/web/cgi-irc/labb.contactor.se/x-ae7145017c57be48) |
00:15:49 | mt | linuxstb : I don't know if it's really a bug, or if my computer is suddenly thinking for itself :/ .. I'm trying to find what my conversation with domonoky about it in the logs. |
00:16:03 | mt | -what |
00:17:47 | kugel | bertrik: what happened to http://www.rockbox.org/tracker/task/9824 ? |
00:19:10 | linuxstb | mt: I'm just looking at that now (5th June, 17.41.45 onwards) |
00:19:35 | linuxstb | mt: Your pastebin has expired though... |
00:19:45 | * | kugel thinks we should close a few with out-of-date and ask for re-opening |
00:20:15 | | Quit Juice^ ("- nbs-irc 2.0 - www.nbs-irc.net -") |
00:20:34 | mt | linuxstb : 1 min. I'll check and rewrite the expired ones. |
00:21:06 | | Quit bertrik (Read error: 113 (No route to host)) |
00:21:12 | linuxstb | mt: It's OK - http://pastebin.com/md6287c2 seems the important one, and that's fine. |
00:22:05 | mt | OK. |
00:23:34 | | Join funman [0] (n=fun@rockbox/developer/funman) |
00:23:42 | | Quit funman_ (Read error: 104 (Connection reset by peer)) |
00:23:48 | | Join faemir [0] (n=faemir@88-106-135-73.dynamic.dsl.as9105.com) |
00:23:59 | linuxstb | mt: Does the code compile without warnings? |
00:24:44 | mt | for the parser and the codec, yes. (some warnings in libcook/bitstream though, but I don't think they're relevant ? ) |
00:28:59 | mt | for some reason,I can't get anything in this day's log beyond 16:49. (5th of june) |
00:30:09 | linuxstb | mt: I always use the raw logs - http://www.rockbox.org/irc/rockbox-20090605.txt |
00:30:31 | | Quit mt (Read error: 113 (No route to host)) |
00:30:56 | | Quit faemir (Read error: 104 (Connection reset by peer)) |
00:31:06 | | Join mt [0] (n=MTee@rockbox/developer/mt) |
00:33:19 | pixelma | looks like another breakage on an URL (the line below in the raw logs has one with some weird characters, don't mention it here again) |
00:33:40 | CIA-38 | New commit by bluebrother (r21227): Remove never used code −− libmtp is not used on Windows. |
00:34:54 | | Quit webguest18 ("CGI:IRC (EOF)") |
00:38:10 | | Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.10/2009042316]") |
00:38:19 | *** | Saving seen data "./dancer.seen" |
00:39:17 | | Join faemir [0] (n=faemir@88-106-135-73.dynamic.dsl.as9105.com) |
00:39:24 | | Join PaulJam_ [0] (i=Paule@vpn-3005.gwdg.de) |
00:39:24 | | Quit PaulJam (Nick collision from services.) |
00:39:31 | | Nick PaulJam_ is now known as PaulJam (i=Paule@vpn-3005.gwdg.de) |
00:39:47 | | Quit flydutch ("/* empty */") |
00:46:31 | | Quit mt ("ChatZilla 0.9.84 [Firefox 3.0.10/2009042316]") |
00:51:00 | kugel | funman: how can I put some vars into the uncached iram? |
00:51:21 | kugel | i.e. I want to test if the blue bars disappear if I put it into non-cached |
00:52:28 | funman | use UNCACHED_ADDR(address) |
00:52:57 | kugel | yea, but that only works for a pointer to that vars |
00:53:20 | kugel | I would like to put the lcd framebuffer into uncached, using the config-*.h define |
00:53:32 | | Join bubsy [0] (n=Bubsy@94.139.72.137) |
00:53:53 | funman | that's not supported atm : we would need to modify app.lds like sandisk/app.lds does |
00:54:16 | stripwax | could you not rename the lcd framebuffer, and export the uncached pointer? |
00:54:17 | funman | well you could do the same than in ata |
00:54:28 | kugel | I guess the effect is the same though, when I access the framebuffer with that macro? |
00:54:29 | funman | i.e. what stripwax just said |
00:54:39 | stripwax | oh! :) |
00:55:25 | | Quit ender` (" Top reason why compilers are like women: Miss a period and they go crazy") |
00:55:25 | funman | why I named this file ata-XX while it doesn't have anything to do with ata is still a mystery >> |
00:55:31 | kugel | hm |
00:55:49 | kugel | the framebuffer is declared in lcd-16bit.c |
00:56:10 | linuxstb | Why is it called uncached iram? Is there some cached iram? |
00:56:12 | kugel | fb_data lcd_framebuffer[LCD_FBHEIGHT][LCD_FBWIDTH] IRAM_LCDFRAMEBUFFER CACHEALIGN_AT_LEAST_ATTR(16); |
00:56:19 | funman | linuxstb: yes |
00:56:38 | kugel | IRAM_LCDFRAMEBUFFER is a config-*.h define |
00:56:53 | stripwax | Any reason why sim build doesn't generate a .map file? or maybe, where's the switch in the regular build that tells it to generate a .map file? (I couldn't find -Map option in makefile but maybe was looking in wrong place?) |
00:57:07 | kugel | though, I notice cachealign_at_least_attr(16) might give us problems |
00:57:16 | stripwax | linuxstb - I think iram accessed through the cacheable address range gets cached, and (the same) iram accessed through the alternative address range doesn't |
00:57:18 | | Quit barrywardell () |
00:57:20 | funman | kugel: why ? |
00:57:33 | kugel | we need 32 on our targets? |
00:57:47 | funman | stripwax: i think because the memory map is different between devices and real operating systems |
00:58:02 | * | linuxstb thought iram was generally single-cycle, and hence didn't need caching, but admits to not know much about RAM... |
00:58:04 | funman | kugel: i don't know why the lcd framebuffer must be aligned |
00:58:11 | kugel | also, IIUC codecs and plugins are shared libs in the sims |
00:58:27 | kugel | why not? |
00:58:37 | kugel | it's big enough to cross cache line boundaries |
00:59:00 | funman | that's not a problem |
00:59:07 | kugel | though, I don't understand all of the caching business |
00:59:38 | kugel | what's the reason to cache align? |
00:59:40 | funman | you must care about the caches when you are using DMA (the memory and the caches must be in sync because the DMA controller don't know about the caches) |
00:59:52 | stripwax | linuxstb - good point though; maybe it isn't single cycle; or maybe we just don't need to cache iram |
01:00 |
01:00:05 | funman | or also when you execute self-modifying code (loading a plugin into ram is self-modifying code) |
01:00:32 | funman | because the data in instruction cache might not be up to date with what you wrote to memory |
01:00:42 | | Quit tessarakt ("Client exiting") |
01:00:45 | | Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") |
01:01:13 | funman | linuxstb: i don't know anything about memory, i think the as3525 datasheet details what kind of memory is used for iram |
01:01:50 | kugel | T1 RAM IIUC |
01:01:52 | kugel | IIRC* |
01:02:51 | saratoga | yeah its actually DRAM |
01:05:40 | CIA-38 | New commit by funman (r21228): FS #10048 : enable MMU and data cache on Sansa AMS to give a major speed up ... |
01:05:51 | saratoga | nice! |
01:05:55 | kugel | \0/ |
01:06:06 | kugel | FlynDice & funman: Really good work on that one |
01:06:24 | funman | big up to FlynDice! |
01:07:06 | kugel | huh |
01:08:06 | notlistening | Bigup!!! to the max |
01:08:36 | notlistening | should i test? |
01:09:12 | funman | sure |
01:09:22 | notlistening | I am on it |
01:09:25 | | Quit martian67 (Connection timed out) |
01:11:43 | notlistening | building....remind me of C&C |
01:13:55 | | Quit Thundercloud (Remote closed the connection) |
01:14:54 | * | kugel would also like if funman commits smaller patches |
01:15:03 | kugel | i.e. in more parts |
01:15:06 | funman | incremental? |
01:15:21 | kugel | yes |
01:15:29 | notlistening | one fix per patch |
01:15:54 | notlistening | humm i am bad for that one don't do any thing at a time ;) |
01:17:50 | funman | kugel: i could have separated the use of caches and the change of memory map this time, sorry :/ |
01:17:58 | | Quit faemir (Read error: 104 (Connection reset by peer)) |
01:18:51 | | Quit amiconn (Nick collision from services.) |
01:18:53 | | Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) |
01:19:00 | | Quit pixelma (Nick collision from services.) |
01:19:00 | | Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) |
01:19:12 | | Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) |
01:19:18 | | Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) |
01:19:19 | | Join faemir [0] (n=faemir@88-106-135-73.dynamic.dsl.as9105.com) |
01:21:51 | | Quit funman (Read error: 113 (No route to host)) |
01:24:09 | | Quit kachna|lappy (Remote closed the connection) |
01:24:30 | | Join kachna|lappy [0] (n=kachna@r4ax178.net.upc.cz) |
01:24:30 | | Quit JdGordon| ("http://www.mibbit.com ajax IRC Client") |
01:26:59 | | Quit robin0800 (Read error: 110 (Connection timed out)) |
01:27:40 | | Join kugel_ [0] (n=kugel@e178088093.adsl.alicedsl.de) |
01:28:11 | | Quit kugel (Nick collision from services.) |
01:28:16 | | Nick kugel_ is now known as kugel (n=kugel@e178088093.adsl.alicedsl.de) |
01:34:28 | | Quit timc (Remote closed the connection) |
01:35:03 | stripwax | funman - mm, good point. I'm (rather pointlessly, perhaps) trying to make a working sim build with profiling support |
01:37:35 | notlistening | well that patch rocks so to say |
01:37:52 | saratoga | i'm getting 44MHz to decode a 128k vorbis file, which is way more then it should be |
01:38:05 | notlistening | or should i say commit for the Sansa |
01:38:14 | kugel | stripwax: that's probably really pointless |
01:38:24 | | Join funman [0] (n=fun@rockbox/developer/funman) |
01:38:28 | stripwax | yeah |
01:38:38 | notlistening | stuck at 62mhz |
01:39:16 | notlistening | saratoga, should we still be getting random scroll wheel flashes? |
01:39:28 | funman | yes |
01:40:11 | notlistening | cool well just get it going with the beat and i will be impressed :D jk |
01:40:24 | stripwax | originally it was just so I could test out some changes to profiling code rather than actually use it to profile anything - thought I'd see if it could also be used to profile anything but not really. Maybe sim built with profiling should do the regular gcc -pg thing |
01:43:27 | notlistening | and a bit more info on the FM issue i am having, the OF tunes to local radio stations but does not give me any sound? RB just hangs. It was a non radio version for europe |
01:46:11 | saratoga | can I force codecs to be entirely in IRAM on the e200v2 like for the clip? i want to test something |
01:46:38 | kugel | yea, #define CODEC_IRAM 0 or so |
01:47:12 | kugel | but you also need to change config.h and CODEC_BUFFER_SIZE accordingly |
01:47:25 | funman | define AMS_LOWMEM in as3525.h (only step required, thanks to FlynDice) |
01:47:46 | | Quit faemir (Read error: 110 (Connection timed out)) |
01:47:53 | funman | or is it you kugel ? (r21000) |
01:47:56 | kugel | funman: that's my work, but ok :) |
01:48:10 | | Quit n1s ("Lämnar") |
01:49:00 | kugel | funman: config.h isn't trimmed on that though (let me change that) |
01:50:20 | saratoga | i'm pleasantly surprised libfaad links with that defined |
01:50:28 | tmzt | is fuze broken again? it seems it was something with radio last time I tried |
01:50:32 | tmzt | I just svn updated |
01:50:38 | tmzt | and configured |
01:50:59 | funman | tmzt: some people needed to update their bootloader |
01:51:14 | tmzt | it won't even build for me, can't see how that would be the issue |
01:51:30 | saratoga | delete your build directory, start over |
01:51:51 | tmzt | mkdir again? |
01:51:56 | saratoga | in the future, if you see that the build system can build a target, its best to assume its a problem at your end :) |
01:52:06 | tmzt | ah, ok |
01:52:17 | tmzt | if it's not red you mean? |
01:52:41 | saratoga | ha make clean reveals that it cannot link |
01:53:01 | kugel | saratoga: iram will not change with only that define I guess, better double check the codec.map |
01:53:11 | saratoga | kugel: yeah its giving me a lot of errors |
01:53:24 | saratoga | "codec_crt0.c:(.text+0x70): undefined reference to `iramstart'" |
01:53:29 | saratoga | any ideas what else i missed? |
01:53:32 | kugel | should be better after my commit |
01:53:36 | saratoga | ah ok |
01:54:09 | stripwax | saratoga - recent vorbis profiling on ipod5g - floor1_inverse2 seems surprisinig. http://pastebin.com/d7bafe2de |
01:54:57 | saratoga | i need to work on getting mdct_backwards faster |
01:55:05 | CIA-38 | New commit by kugel (r21229): Use the AMS_LOWMEM define to indicate memory size as the .lds files do in config.h too. |
01:55:37 | stripwax | non-inlining render_line (and splitting mdct_backward into the individual steps) gives this http://pastebin.com/d5141a2ba |
01:56:10 | saratoga | wow thats a tiny little file |
01:56:14 | saratoga | function |
01:56:39 | kugel | I take total_ticks indicate speed? |
01:56:45 | stripwax | you can speed up the mdct_bitreverse (a bit) by observing that you only need to compute the bitrev12 every other time (so bitrev12(bits) once, then just add 1<<(12-shift) or something like that, I forget the actual detail) |
01:56:54 | stripwax | But I observed only a tiny improvement |
01:57:14 | stripwax | kugel - not speed, just the running time of the test I ran |
01:57:23 | kugel | ah ok |
01:57:49 | stripwax | I'm wondering if there's so much overhead in profiling that render_line shows up as so much time. it really does very little, but (as you can see) gets called a huge number of times |
01:58:45 | saratoga | stripwax: what bitrate file? |
01:59:28 | stripwax | I made a few local changes to render_line (trying to encourage gcc to use registers for all vars and a bit of unrolling and reordering in the hope that gcc spits out ldmia/stmia) but didn't seem to improve anything much |
01:59:53 | stripwax | saratoga - hm, somewhere between 128 and 192 I think. Either q4 or q5, i forget |
02:00 |
02:02:54 | saratoga | ok just added that to my imdct notes |
02:03:12 | saratoga | render_line looks like it could probably be improved, but it'd help to know what its doing |
02:03:14 | saratoga | any ideas? |
02:03:40 | kugel | omg |
02:04:06 | saratoga | vorbis_apply_window can be made much faster too, but it looks like it uses too little CPU to make much difference |
02:04:13 | kugel | my interrupt patch is much faster than bertriks patch |
02:04:20 | kugel | 65fps vs 90 |
02:04:22 | stripwax | render_line is tremor only not imdct. it's building the piecewise linear spectral floor i.e. given coordinates x0,x1,y0,y1 [and n] plot the line (to min(x1,n)) |
02:04:32 | kugel | but both do 100fps when boosted, and both show blue bars :S |
02:04:51 | stripwax | vorbis_apply_window - uses vect_mult_bw and vect_mult_fw on arm? |
02:05:49 | saratoga | it does |
02:05:53 | stripwax | render_line has to "match the spec" which (I think) means it needs to do a crusty divide and not just a generic bresenham. btw this page could be REALLY useful:http://www.nothings.org/stb_vorbis/ |
02:06:02 | saratoga | but the algorithm its using for windowing is inefficient |
02:06:14 | stripwax | saratoga - oh! in what way? |
02:06:25 | stripwax | (I only recently changed it.. a bit anyway..) |
02:06:26 | saratoga | it could probably be rewritten to not have that if inside the loop though |
02:06:52 | saratoga | it doesn't take advantage of the fact that the mdct coefficients have "middle half" symmetry |
02:07:03 | saratoga | so it does 2x as many loads and multiplies as needed |
02:07:06 | stripwax | which if inside which loop? sorry if I'm being thick |
02:07:42 | saratoga | in render_line i bet if(err>=adx){ could be done better |
02:07:55 | kugel | funman: your UNCACHED_ADDR macro only works for char*, right? |
02:08:12 | stripwax | saratoga - oh, thought you were referring to vorbis_apply_window. right. |
02:08:28 | stripwax | saratoga - that seems to compile nicely to a few conditional instructions without any branch on arm |
02:08:44 | saratoga | eventually i'm going to rewrite the IMDCT to exploit that symmetry, and when I do i'll fold in the vorbis windowing functions |
02:08:45 | stripwax | saratoga - you can preload err with -adx and then just if(err>=0) |
02:08:52 | Unhelpful | stripwax: you can adjust the rounding in bresenham to make it do pretty much whatever you want. if you want the first and last step half as long, it can be done, it's just a bit trickier as you have to mess about with the starting value of the error. |
02:08:52 | saratoga | but expect a very small speed up, but perhaps a lot of saved IRAM |
02:08:55 | | Join itcheg [0] (i=62db4c46@gateway/web/ajax/mibbit.com/x-1b709978b4fcb0ce) |
02:09:21 | stripwax | saratoga - is that just the same optimisation as the LOWMEM branch of Tremor uses? (which is also the basis for Tremolo, but not rockbox or trunk tremor) |
02:09:40 | saratoga | i didn't look at lowmem |
02:09:48 | funman | kugel: hum right |
02:09:54 | stripwax | I think that link I gave also did the same optimsation |
02:10:00 | saratoga | i was thinking compute which value of x gives err<adx and remove the branch entirely |
02:10:54 | kugel | funman: that needs some typeof magic, or complicated casting :( |
02:11:09 | funman | just looking at it |
02:11:15 | | Quit PaulJam (".") |
02:11:20 | stripwax | saratoga - (unless you use a div) that might be slower than just doing the conditional instruction |
02:11:27 | tmzt | saratoga: well, stuck on bootloader screen now |
02:11:29 | stripwax | (even if you use a div) |
02:11:50 | saratoga | what div? |
02:12:17 | kugel | funman: it would probably be better to use a inline function for that |
02:12:34 | stripwax | i.e. adx/ady |
02:12:38 | kugel | like gigabeat's virt_addr_to_phys(or whatever that's called) |
02:12:47 | | Join swolchok [0] (n=scott@d-111-206.eecs.umich.edu) |
02:13:00 | saratoga | dy/adx? |
02:13:37 | funman | kugel: i am not sure |
02:13:58 | stripwax | maybe I'm confused .. how do you propose getting rid of the if(err>=adx) test |
02:14:03 | funman | compiler can store the uncached address in the data segment if the cached address isn't used |
02:14:10 | funman | else converting only costs one instruction |
02:14:39 | stripwax | we still need the value of y at each x coord |
02:15:10 | saratoga | stripwax: maybe I misread it but it looks like all the initial runs take TRUE, then eventually they all switch to FALSE |
02:15:18 | saratoga | i meant to precompute which index is which, and split that into two loops with no branch |
02:15:27 | kugel | funman: uncached address is a bit slower for the lcd too |
02:15:33 | stripwax | nope, because we subtract adx from err, and then start incrementing err again |
02:15:55 | funman | kugel: you lose the advantage of data cache |
02:16:04 | stripwax | the line has a fixed gradient, but non-integer |
02:16:11 | stripwax | ^not necessarily integer |
02:16:59 | saratoga | ady and adx are constants though |
02:17:00 | stripwax | one easy optimisation though: if ady>adx then the test will always be true |
02:17:56 | kugel | funman: ok, my patch is fast enough to still reach 100fps when boosted |
02:17:59 | kugel | still blue bars |
02:18:00 | saratoga | so error is incremented by adx-ady each iteration |
02:18:12 | saratoga | opps decremented byt hat amount |
02:18:18 | * | kugel has no idea how to handle those |
02:18:19 | stripwax | saratoga - right, they are. we step y by (base) if we don't breach our err margin, and we step y by (base+1) if we do breach our err margin (and in this case reset our err calculation) |
02:18:33 | swolchok | hey, I'm a grad student and I would like a customizable MTP device for research. any idea how much work it would be to implement MTP in rockbox? I saw it as a suggested google SoC project... |
02:19:09 | stripwax | saratoga - say adx = 100 and ady = 1 .. every 100 steps, err resets from 100 to 0 |
02:19:26 | stripwax | saratoga - http://en.wikipedia.org/wiki/Bresenham's_line_algorithm |
02:19:41 | funman | kugel: did you try lowering dbop freq? |
02:20:07 | kugel | doing that now |
02:20:14 | stripwax | (not exactly identical but same idea) |
02:20:23 | kugel | that means we're maxed to 50fps IIUC though |
02:20:25 | saratoga | ok I don't know the algorithm so so if you're sure it won't work then never mind |
02:20:33 | funman | swolchok: you could look at already existing usb code (for mass storage, serial, and HID) |
02:20:54 | swolchok | funman: good idea |
02:20:57 | saratoga | also ask gevaerts about it |
02:21:02 | saratoga | he wrote much of the USB code |
02:21:14 | notlistening | swolchok, you need something with network hardware on it for that right? |
02:21:27 | stripwax | saratoga - I may have misunderstood your idea :) but it sounds like you would generate two line segments with two different gradients - not same result |
02:21:30 | swolchok | notlistening: no, it's USB |
02:21:41 | notlistening | oh :P |
02:21:44 | swolchok | er, it's transport-agnostic; can be over USB or IP |
02:21:58 | saratoga | oh i guess ady can be negative? |
02:22:03 | kugel | funman: interesting. with half dbop, I even get blue bars at unboosted |
02:22:21 | kugel | and yes, both are at 50fps |
02:22:33 | kugel | (both boosted and unboosted I mean) |
02:22:33 | saratoga | well i guess the best approach would be to come up with a better algorithm for that line |
02:22:40 | saratoga | i suppose it can't be precomputed and cached? |
02:22:55 | stripwax | saratoga - sure, ady can be negative, and abs(ady) can be < or > than abs(adx) |
02:23:12 | stripwax | Anyway .. point is I'm surprised that really as much time is spent doing that as profiling suggests it is .. |
02:23:20 | gevaerts | swolchok: as far as I know, everything that MTP needs from the underlying stack is there. There's no MTP code at all however, and I don't really know how much work it is. Also, I've never managed to find GPL-compatible device-side MTP code anywhere, so everything needs to be written |
02:23:28 | stripwax | as you say, it's a really small function, and the generated asm doesn't look actually very bad at all |
02:24:10 | swolchok | gevaerts: AFAIK, GPL is not an obstacle for never-released research code :) |
02:24:30 | kugel | I just noticed I masked pop error instead of fifo full :/ |
02:25:03 | gevaerts | swolchok: well, (a) I've never seen non-GPL MTP code either, and (b) I'm not writing research code :) |
02:25:06 | kugel | no, I was looking at the wrong table now |
02:25:37 | saratoga | stripwax: well its a loop with a really big number of iterations that does a branch every iteration |
02:25:52 | stripwax | not on arm.. |
02:26:42 | saratoga | ? |
02:27:46 | stripwax | : http://pastebin.com/d2681e0e5 |
02:28:04 | Unhelpful | saratoga: arm has many instructions which offer conditional versions. i believe that up to three instructions after a test may be flagged as storing results only on <condition> |
02:28:25 | saratoga | sure but you still have to evaluate the branch, even if the adds are conditional |
02:28:53 | stripwax | saratoga - the subtract is conditional too :) |
02:28:57 | kugel | Unhelpful: it's limited to 3 instructions? |
02:29:00 | funman | Unhelpful: there is no limit |
02:29:04 | stripwax | sure you need the branch to go back to the start of the loop but that's it |
02:29:14 | Unhelpful | funman: i could swear i recalled there being some limit :) |
02:29:21 | kugel | I thought it's unlimited (i.e. upto the instruction which touches the flag in question again= |
02:29:23 | swolchok | the arm arch reference manual says nothing about a limit |
02:29:32 | swolchok | page A3-5 |
02:29:42 | kugel | ok, Unhelpful has been told :P |
02:29:44 | Unhelpful | that's even better then ;) |
02:30:15 | swolchok | also a branch is not the same thing as a test... |
02:30:38 | stripwax | other than unrolling and using some ldmia/stmia to do the update, I didn't have any good ideas on how to improve on gcc :( |
02:30:42 | swolchok | oh, I think I misparsed |
02:30:54 | swolchok | is that pastebin the generated assembly in question? |
02:32:01 | | Join cool_walking_ [0] (i=cb3b81c3@gateway/web/ajax/mibbit.com/x-926ce3747a5391f0) |
02:32:34 | stripwax | yep. actually the arm build will have slightly different assembly right now, I have a minor tweak or two in there, but nothing substantial |
02:32:59 | swolchok | i see nothing wrong with the use of predicated execution in there, but what do I know |
02:33:00 | | Join JdGordon| [0] (i=43a02c5a@rockbox/developer/JdGordon) |
02:35:18 | saratoga | i don't understand what the vorbis inverse quantization code is doing |
02:35:30 | saratoga | i like WMAs so much better |
02:36:30 | | Join r0b- [0] (n=nnscript@76.236.182.214) |
02:37:10 | funman | kugel: the macro in arm/system-target.h is fine (replacing | by +) but fails in sd code because typeof() returns char[] not char* |
02:38:23 | *** | Saving seen data "./dancer.seen" |
02:38:23 | stripwax | I reckon if you could take out the division (i.e. do something better than int base=dy/adx) that would be an improvement. base = dy/adx ; ady -= abs(base*adx) is uggggly |
02:38:29 | kugel | funman: really? |
02:38:38 | | Join calman_ [0] (n=caleb@dhcp-064-247-086-012.eg1.ohiou.edu) |
02:38:50 | | Quit funman (Read error: 104 (Connection reset by peer)) |
02:39:13 | stripwax | saratoga - which bit of inverse are you looking at? |
02:39:22 | saratoga | i don't understand the quatization exactly |
02:39:31 | saratoga | so its basically sending a waveform sampled at just a few points, and then you compute the projection of what on to it? |
02:39:54 | stripwax | um. |
02:40:38 | stripwax | so, as I understand it (and I may not be talking about the same thing you are), vorbis encodes a spectral floor and then a residue (= spectrum less the floor) |
02:40:48 | swolchok | stripwax: isn't that equivalent to ady -= (dy - (dy % adx))? |
02:41:03 | kugel | funman: try *(typeof(*a)) maybe |
02:41:06 | stripwax | both floor and residue are quantized in some way (floor quantized discretely as piecewise linear, residue ... not sure...) |
02:41:50 | | Join funman [0] (n=fun@rockbox/developer/funman) |
02:42:12 | stripwax | swolchok - something like that (is mod faster than div?) |
02:42:14 | saratoga | kugel: i updated my SVN but I still get errrors with that define |
02:42:18 | saratoga | did it work for you? |
02:42:27 | | Quit calman_ (Client Quit) |
02:42:27 | kugel | I didn't try actually |
02:43:07 | kugel | as I said, you still need to change CODEC_BUFFER_SIZE, that's not dependant on AMS_LOWMEM since it's a config-*.h define (but probably could be) |
02:43:37 | kugel | funman: http://tigcc.ticalc.org/doc/gnuexts.html#SEC69 doesn't indicate that it's not working for pointers |
02:43:41 | | Quit daurn| (Read error: 110 (Connection timed out)) |
02:43:57 | kugel | typeof (int*) gives a pointer to int |
02:43:58 | swolchok | stripwax: haven't the slightest. with a constant modulus, you can of course do it with shifts |
02:44:14 | | Join daurn| [0] (n=daurnima@ppp118-208-140-126.lns10.mel4.internode.on.net) |
02:44:20 | funman | kugel: not typeof(int[]) |
02:44:57 | funman | if my laptop doesn't crash i'll commit a better macro |
02:45:12 | swolchok | stripwax: does arm even HAVE a div instruction? |
02:45:24 | swolchok | IIRC it's implemented by the C library |
02:45:33 | saratoga | it does not |
02:45:40 | funman | it has divide by powers of 2 |
02:45:42 | stripwax | swolchok - not sure; but you should check out the awesome asm gcc produces. some bit twiddling followed by a mult iirc |
02:46:49 | stripwax | oh.. if it's in the C lib then that may well be the cause of much arm slowness... |
02:46:53 | saratoga | reducing the codec buffer size doesn't seem to help, it still gives this: http://mibbit.com/pb/Rbxsil |
02:47:08 | swolchok | funman: well of course :) |
02:47:25 | swolchok | _rt_udiv or _rt_div would be my guess at the function name |
02:47:44 | funman | it's not exactly in the c library but in gcc itself |
02:48:06 | swolchok | oh yes of course |
02:48:18 | kugel | http://www.tofla.iconbar.com/tofla/arm/arm02/index.htm |
02:48:42 | | Part toffe82 |
02:49:07 | tmzt | anyone can help with ams bootloader? |
02:49:15 | saratoga | the values of adx are possibly constrained so there may be some optimization possible |
02:49:15 | stripwax | heh - this looks very much like the same problem ;-) http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka11483.html |
02:49:20 | swolchok | I would expect mod to be faster than div |
02:49:30 | swolchok | but I haven't a good reason |
02:49:39 | funman | tmzt: not if you don't tell your problem |
02:50:06 | tmzt | funman: I mean how you use it now that it's moved to rbutil directory |
02:50:13 | stripwax | swolchok - yeah, me too, and also not sure why I think that. |
02:50:19 | tmzt | funman: haven't done that since january |
02:50:31 | saratoga | you mean install it? |
02:50:36 | tmzt | yes |
02:50:46 | saratoga | SansaAMS wiki page |
02:50:50 | tmzt | okay |
02:51:39 | CIA-38 | New commit by funman (r21230): Sansa AMS: make the UNCACHED_ADDR macro work for any type of pointer, and only use pointers with it, not arrays |
02:53:34 | stripwax | saratoga - well.. x0<=0<=x1<=4095 I think . maybe 8192 |
02:53:49 | stripwax | max window size |
02:54:08 | saratoga | max window size is 2048 in practice |
02:54:22 | saratoga | and n is half that |
02:54:23 | saratoga | so 1024 |
02:54:36 | saratoga | but the values seem randomly distributed between 3 and about 100 |
02:54:37 | stripwax | and 0<=y<=255 so -255<=dy<=255 |
02:54:44 | saratoga | err 200 |
02:54:48 | swolchok | make sure we write the code so it crashes if anything unexpected happens ;) |
02:55:19 | stripwax | (hence my suspicion that the arm infocenter link points to something very very handy here...) |
02:55:49 | stripwax | saratoga - which values are distributed like that? (the x's or the y's?) |
02:55:49 | | Quit sbhsu ("leaving") |
02:56:03 | saratoga | adx |
02:57:00 | tmzt | does this look right: ../rbutil/mkamsboot/mkamsboot ~/Desktop/fuzeA.bin bootloader-fuze.sansa fuzea.bin |
02:57:19 | kugel | funman: hmm, apparently there's no push or pop error |
02:57:26 | stripwax | hm, that just means that the floor has been decomposed into shorter segments |
02:57:44 | stripwax | ok so we want an algo that has fast 8/8 performance and not-bad 16/8 performance. |
02:57:46 | funman | tmzt: it looks like the example, so i think it's right |
02:57:53 | stripwax | (or 12/8 performance) |
02:57:59 | saratoga | wait |
02:58:04 | tmzt | I didn't see the example on the wiki page |
02:58:05 | saratoga | adx is almost always > dy |
02:58:20 | saratoga | add a check for adx > dy and set it to 0 |
02:58:22 | stripwax | likely - x range is much larger than y range |
02:58:25 | * | kugel forgot VIC_INT_ENABLE |
02:58:30 | stripwax | heh!! nice |
02:58:51 | funman | kugel: i need to test the patch to actually see what these blue bars are :) - but now i have to sleep a bit .. see you ! |
02:59:04 | kugel | see you too |
02:59:13 | saratoga | base is also very very small |
02:59:25 | saratoga | you could probabyl compute it iteratively very quickly just by subtracting |
02:59:26 | stripwax | hm, would need to flip sign though |
02:59:30 | funman | tmzt: http://www.rockbox.org/twiki/bin/view/Main/SansaAMS#Bootloader_Installation : * Usage (example for clip): ./mkamsboot m300a.bin bootloader-clip.sansa output.bin |
02:59:41 | | Quit funman ("leaving") |
02:59:51 | saratoga | tmzt: maybe you should wait for a release |
03:00 |
03:00:05 | stripwax | ^ er, no, disregard that |
03:00:19 | notlistening | lol @ saratoga |
03:00:35 | saratoga | check if adx > dy, if true set to zero |
03:00:48 | tmzt | I just haven't had to update the bootloader since I first installed it |
03:00:48 | stripwax | ^ actually disregard the disregard. we need base = (abs(dy)<abs(adx))?0:dy/adx |
03:00:51 | saratoga | else subtract adx from dy until it is |
03:01:05 | saratoga | you don't even need the divide |
03:01:27 | notlistening | I'm cooked night all |
03:01:29 | saratoga | the largest value of base in my test file is +/- 3 |
03:01:35 | stripwax | yep. don't need abs(adx), as x1 constrained to be > x0 anyway |
03:01:48 | | Quit notlistening ("Leaving") |
03:02:29 | saratoga | you want to write this or should i |
03:04:15 | stripwax | I really gotta go sleep .. but if base is always small it should go on the right hand side of the mul for arm speed |
03:05:17 | stripwax | basically something like: int base = 0; while(ady>adx){ ady-=adx;base++ }; ady=abs(dy); if(dy<0) base = -base; ? |
03:07:07 | stripwax | could even unroll three times if base is +/- 3. ady-=adx; if(ady>0){base++;ady-=adx); if(ady>0){ base++; ady-=adx); if(ady>0){base++;ady-=adx}; then a while loop; ..? |
03:09:11 | stripwax | Could degrade badly for low bitrates maybe - 16 iterations worst case? |
03:09:27 | stripwax | depends how bad gcc div is |
03:11:19 | saratoga | stripwax: |
03:11:21 | saratoga | works great |
03:11:25 | stripwax | :) |
03:11:30 | saratoga | didn't unroll though |
03:11:31 | stripwax | mine's still building. sigh. |
03:11:38 | stripwax | speedup? |
03:11:45 | saratoga | just tried sim |
03:11:52 | stripwax | ah, cool |
03:12:16 | saratoga | give me 40 seconds |
03:12:28 | stripwax | coldfire has div, right? so we'd maybe still want to use div there? |
03:12:57 | saratoga | i doubt it |
03:13:18 | saratoga | stripwax: how hard would it be to give wma the same treatment |
03:13:26 | saratoga | profiling that is |
03:14:04 | stripwax | oh, thought you implied I knew anything about wma :) not hard, but can't do that tonight. |
03:14:21 | stripwax | profiling coldfire or arm? or both? or don't care? :) |
03:14:27 | saratoga | ARM |
03:15:12 | saratoga | 252.9% real time on the e200v1 |
03:15:18 | saratoga | 31.6MHz |
03:15:31 | stripwax | sure. setting up a profile build is not hard, I'll get to it tomorrow if I have time. so wma only slightly worse than tremor? |
03:15:42 | saratoga | its actually faster |
03:15:54 | saratoga | i put a lot more time into WMA |
03:15:54 | stripwax | mm, I get 29Mhz vorbis |
03:16:04 | saratoga | 192k? |
03:16:09 | saratoga | let me run without |
03:16:54 | stripwax | 29Mhz 128 (ish), 32Mhz 192 (ish), I think |
03:17:23 | saratoga | well the entire function only uses 6 mhz or so |
03:17:31 | saratoga | so if we saved 2 thats pretty goodf or such a simple trick |
03:18:16 | stripwax | oh, wait, now I'm super confused. Is your 31.6Mhz number your WMA speed or your tremor-with-this-change speed? |
03:18:23 | saratoga | tremor |
03:19:29 | stripwax | riiiiight. Ok fine. My last svn timings are on FS #9882 |
03:20:08 | stripwax | 31.25Mhz 192 apparently |
03:20:17 | saratoga | without the change i get 253% anyway |
03:20:20 | saratoga | i wonder if I did something wrong |
03:21:04 | stripwax | I wonder if the profile was lying |
03:21:05 | saratoga | arg didn't revert my change correctly |
03:21:09 | stripwax | :) |
03:21:29 | stripwax | ok I really gotta go sleep - I'll be around later |
03:21:56 | saratoga | ok check the logs |
03:23:05 | | Join alupa [0] (n=1824bf02@gateway/web/cgi-irc/labb.contactor.se/x-81f034e483c2efc9) |
03:24:23 | | Quit kugel (Read error: 110 (Connection timed out)) |
03:24:44 | | Quit stripwax ("http://miranda-im.org") |
03:27:56 | saratoga | oh hmm this function doesn't get called that often |
03:31:20 | saratoga | ha after all that its not really any faster |
03:34:21 | | Quit J-23 (Read error: 54 (Connection reset by peer)) |
03:34:23 | | Join J-23_ [0] (n=zelazko@unix.net.pl) |
03:38:58 | saratoga | stripwax: i think the function is called way too infrequently for the divisions to matter much |
03:39:08 | saratoga | it looks to me like its probably only called a dozen times or so per block |
03:39:23 | saratoga | should have checked that first |
03:39:47 | saratoga | but we can still use the fact that base is adx>ady almost all the time to improve the loop |
03:40:12 | saratoga | break it out into the base = 0 case (which is simple and common) and the base !=0 case which is slower but very rare |
03:40:50 | saratoga | assuming your profile results are right i bet that'll make a bigger difference |
03:42:05 | | Quit alupa ("CGI:IRC (EOF)") |
03:43:33 | | Join alupa [0] (n=1824bf02@gateway/web/cgi-irc/labb.contactor.se/x-a8525f82e16cd917) |
03:44:27 | CIA-38 | New commit by kugel (r21231): Alright, revert r21229 for now. Stupid me forgetting about the inclusion sequence :( |
03:47:47 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
03:54:49 | alupa | Hi folks. So I started using Rockbox recently and noticed the clock displayed in the "System > Time & Date" menu is a little left of center when in 24h format. No biggy unless you're anal like I am. I found the problem in the code and would like to share a fix but I don't know anything about submitting patches or using the bug tracker. Anybody here willing to commit the change? |
03:56:32 | alupa | The issue is on line 179 of apps/menus/time_menu.c |
03:57:15 | saratoga | http://www.rockbox.org/twiki/bin/view/Main/WorkingWithPatches#Creating_A_Patch |
03:57:31 | saratoga | if you've used SVN to check out you can just use svn diff > file.patch and post that |
03:57:54 | saratoga | this would be a better link: http://www.rockbox.org/twiki/bin/view/Main/WorkingWithPatches#Submitting_A_Patch |
03:57:56 | Unhelpful | saratoga: do we have a macro for ARM versions? in particular, there's a MULTIPLY16 macro in the jpeg decoder. on beast this is lovely, it has the 16x16->32 multiply instruction, and it seems that the compiler would prefer that to a shift/add sequence. on ipod it uses shift/add either way, but does an lsl #16, asl#16 first if the multiply is specified as short * short. :/ |
03:58:33 | | Part swolchok |
04:00 |
04:02:08 | | Quit alupa ("CGI:IRC (EOF)") |
04:02:21 | | Quit efyx_ (Client Quit) |
04:05:48 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
04:07:03 | | Join martian67 [0] (n=martian6@about/linux/regular/martian67) |
04:20:53 | | Join SeaWeed [0] (n=SeaWeed@c-67-187-7-172.hsd1.va.comcast.net) |
04:38:24 | *** | Saving seen data "./dancer.seen" |
04:38:39 | | Quit fyrestorm (Read error: 104 (Connection reset by peer)) |
04:41:44 | | Join daurn [0] (n=daurnima@unaffiliated/daurnimator) |
04:45:39 | | Join chandoo [0] (n=chandoo@ool-4353b978.dyn.optonline.net) |
04:53:01 | | Join jordan`` [0] (i=gromit@78.235.252.137) |
04:53:19 | | Join ademille [0] (n=ademille@c-24-10-232-214.hsd1.ut.comcast.net) |
04:53:54 | | Quit jordan` (Read error: 113 (No route to host)) |
04:57:00 | | Quit daurn| (Read error: 110 (Connection timed out)) |
05:00 |
05:02:07 | | Join kperri [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-9fadb74d8613d4a4) |
05:03:39 | | Quit kperri (Client Quit) |
05:15:15 | | Join gartral [0] (n=Gartral@adsl-75-33-78-34.dsl.bcvloh.sbcglobal.net) |
05:17:49 | gartral | hello all, Rockpaint will not close if the toolbar is shown (ei, starting state) and I can't find mention of this behavior in FS |
05:22:25 | | Quit gartral ("The Internet is for three things; Communication, Adults*, and SPAM! EOL") |
05:37:16 | SeaWeed | hello yall |
05:38:05 | evilnick_home | hello SeaWeed |
05:38:56 | SeaWeed | i have a old ipod video 30 gig i installed rockbox on about a year ago now i think the Hard Drive is going bad is there a app i can run in ( linux or windows ) to try and fix drive it hangs every so often then it frees up and continue to play |
05:39:05 | SeaWeed | hello <evilnick_home> |
05:39:28 | evilnick_home | Are you using EQ? |
05:39:39 | evilnick_home | And what bitrate are the files? |
05:40:47 | evilnick_home | It's often/sometimes the case that people try to get the iPod to do too much, and that leads to it having to pause to decode the new part of the song: therefore it sounds like it's pausing every-so-often |
05:41:43 | evilnick_home | If it's not that, and it really is the HDD then chkdsk or fsck ought to work |
05:42:19 | SeaWeed | sorry had to grab a drink |
05:42:40 | SeaWeed | it not just in Rock box it also hangs in ipod os |
05:42:55 | SeaWeed | this is why i beleave it to be a Hard drive issue |
05:43:33 | SeaWeed | i have even ( zero'ed ) the Drive via linux with ( dd ) command |
05:44:06 | SeaWeed | reinstalled every thing and still doing it so was not shure if there was some thing else i could try |
05:48:08 | SeaWeed | Was thinking of just upgradeing the hd to a 80 gig and new cover for it but hell i can get new ipod for that but not shure have not kept up so not shure if newer ipod can install rock box on |
05:48:23 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
05:50:30 | | Quit Horscht ("Verlassend") |
05:52:55 | | Join KRB [0] (n=robocop1@S0106001b112586a1.wp.shawcable.net) |
05:57:20 | evilnick_home | The iPod Video are the most recent iPod that Rockbox works on |
05:58:07 | KRB | hi anyone know if the rockbox wakeup timer works while conected to usb on ipod nano? |
06:00 |
06:04:51 | SeaWeed | <evilnick_home> t/y for responce i said it was a video but it is a classic i beleave it is rather old now but when hard drive dont stick it plays good |
06:05:05 | SeaWeed | welp guess ill say good nite and t/y for info |
06:05:29 | | Quit SeaWeed (Remote closed the connection) |
06:15:48 | | Join goffa_ [0] (n=goffa@216.220.23.105) |
06:15:49 | | Quit JdGordon| ("http://www.mibbit.com ajax IRC Client") |
06:15:56 | | Join goffa__ [0] (n=goffa@216.220.23.105) |
06:15:56 | *** | Alert Mode level 1 |
06:15:56 | DBUG | Enqueued KICK goffa___ |
06:15:56 | DBUG | Enqueued KICK goffa |
06:15:56 | *** | Alert Mode level 2 |
06:15:56 | DBUG | Enqueued KICK goffa_ |
06:15:56 | DBUG | Enqueued KICK goffa__ |
06:15:56 | *** | Alert Mode level 3 |
06:18:27 | | Part ademille |
06:24:08 | | Join TheDawg [0] (n=thedawg@adsl-75-10-113-75.dsl.frs2ca.sbcglobal.net) |
06:25:57 | *** | Alert Mode OFF |
06:26:14 | | Quit goffa___ (Read error: 110 (Connection timed out)) |
06:26:16 | | Quit goffa (Read error: 110 (Connection timed out)) |
06:30:18 | | Join LinusN [0] (n=linus@rockbox/developer/LinusN) |
06:30:25 | | Quit TheDawg ("DSOrganize IRC") |
06:32:29 | | Join VytenisS [0] (n=bxcracer@78-56-8-132.static.zebra.lt) |
06:38:25 | *** | Saving seen data "./dancer.seen" |
06:55:40 | | Join jfc^3 [0] (n=john@dpc691978010.direcpc.com) |
06:59:29 | | Join fml [0] (n=4fd3c62c@gateway/web/cgi-irc/labb.contactor.se/x-017f5b9e997b5c76) |
07:00 |
07:00:13 | | Quit chandoo ("Leaving") |
07:00:28 | fml | In some files I see expressions like "1<<n" (e.g. in lcd-fuze.c) Isn't the macro BIT_N the right way now? |
07:02:18 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
07:02:40 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
07:04:22 | | Quit jfc^3 (Read error: 104 (Connection reset by peer)) |
07:04:45 | | Join jfc^3 [0] (n=john@dpc691978010.direcpc.com) |
07:12:12 | | Quit jfc^2 (Read error: 110 (Connection timed out)) |
07:12:30 | | Quit Llorean (Read error: 104 (Connection reset by peer)) |
07:12:51 | | Join Llorean [0] (n=DarkkOne@adsl-99-182-52-92.dsl.hstntx.sbcglobal.net) |
07:15:30 | | Join stoffel [0] (n=quassel@p57B4E302.dip.t-dialin.net) |
07:26:58 | | Quit fml ("CGI:IRC (EOF)") |
07:27:15 | | Nick J-23_ is now known as J-23 (n=zelazko@unix.net.pl) |
07:29:35 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
07:33:03 | | Join thammuz [0] (n=4c7da48f@gateway/web/cgi-irc/labb.contactor.se/x-48d92efb05885eb2) |
07:34:33 | | Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-d7ad19d02fb3cc31) |
07:37:47 | | Quit thammuz (Client Quit) |
07:49:16 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
07:52:17 | CIA-38 | New commit by learman (r21232): Fix Gigabeat key for Swedish. |
07:54:02 | | Join evilnick_home1 [0] (n=evilnick@pool-96-246-56-43.nycmny.east.verizon.net) |
07:56:29 | | Quit Llorean (Read error: 110 (Connection timed out)) |
07:59:47 | | Join cweiske [0] (n=cweiske@proxy.lpz.netresearch.de) |
08:00 |
08:01:02 | cweiske | Good morning. I bought an "Archos 2" in the hope it would be the supported Archos Recorder v2, but it wasn't. |
08:01:21 | cweiske | I know that currently there are no plans to port rockbox to it, but how can I help to do that? |
08:02:34 | cweiske | other question: the faq says that there will never be an ogg decoder on archos players. is that valid for the v2, too? |
08:07:40 | | Quit evilnick_home (Read error: 110 (Connection timed out)) |
08:07:54 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
08:10:06 | | Quit bubsy ("Panic.") |
08:12:21 | | Join bubsy [0] (n=Bubsy@94.139.72.137) |
08:16:42 | | Join pondlife [50] (n=Steve@rockbox/developer/pondlife) |
08:19:45 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
08:20:21 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
08:20:38 | | Join Rob2223 [0] (n=Miranda@p4FDCDB25.dip.t-dialin.net) |
08:24:01 | | Quit stoffel (Read error: 113 (No route to host)) |
08:25:57 | | Join Zagor [242] (n=bjorn@rockbox/developer/Zagor) |
08:29:36 | | Quit dmb (Read error: 113 (No route to host)) |
08:33:25 | | Join dmb [0] (n=dmb@unaffiliated/dmb) |
08:37:21 | | Quit safetydan ("Leaving.") |
08:37:24 | pondlife | cweiske: The v2 recorder is MP3 (and WAV, IIRC) only. This is very unlikely to change. I know nothing about the "Archos 2" though |
08:38:22 | | Quit Rob2222 (Read error: 110 (Connection timed out)) |
08:38:28 | *** | Saving seen data "./dancer.seen" |
08:38:33 | pondlife | cweiske: You should probably start by opening it up and working out what's inside - take some high-res photos of the board etc while you're in there ;) |
08:39:34 | pondlife | And have a look at http://www.rockbox.org/wiki/NewPort |
08:40:03 | Ctcp | Ignored 4 channel CTCP requests in 0 seconds at the last flood |
08:40:03 | * | pondlife lols at "may require various degrees of violence." |
08:40:16 | GodEater | its true though |
08:40:26 | GodEater | ipods are a sod to open |
08:40:40 | pondlife | I know - I really mangled a Nano once |
08:40:43 | GodEater | I've nearly taken lumps out of my fingers getting mine open |
08:41:24 | pondlife | Yes, but I only had one Nano and you have several fingers |
08:41:31 | | Quit matsl (Read error: 60 (Operation timed out)) |
08:42:14 | pondlife | More on-topic, when does the freeze end/branch occur? |
08:42:37 | cweiske | so chances are good that I won't be able to use the player after opening? |
08:42:53 | pondlife | cweiske: No idea, some players open easily, some do not. |
08:43:20 | | Quit bertrik (Read error: 113 (No route to host)) |
08:43:25 | pondlife | But I am generally clumsy and not suited for hardware work - you will probably be more adept ;) |
08:43:40 | GodEater | pondlife: dates are on the dev list ;) |
08:43:59 | GodEater | cweiske: some players are very easy to open |
08:44:14 | GodEater | it's why we put the disclaimer there, "may require *varying* degrees of violence" |
08:44:27 | pondlife | The H300 is easy to open, no force, just screws to undo. |
08:44:29 | GodEater | the ipods are bad because there are no screws, you have to pry them open, and there's not much purchase |
08:45:21 | cweiske | archos 2 has no screws |
08:45:34 | GodEater | that you can see :) |
08:45:46 | GodEater | they might be hidden under rubber feet or something |
08:45:48 | cweiske | but if it helps, I'll gonna sacrifice the player |
08:46:09 | pondlife | cweiske: That's entirely up to you - also read the rest of that wiki page... |
08:46:28 | GodEater | cweiske: please bear in mind that currently you're the ONLY person interested in this device |
08:46:35 | pondlife | Unless you have plenty of spare time, or can find more devs, you may not wish to wreck your DAP. |
08:46:35 | cweiske | i fail at the electronics, embedded and assembler part :) |
08:46:44 | GodEater | just taking pictures of it's inards isn't going to magically make people want to do a port for it |
08:46:49 | cweiske | i know |
08:47:24 | pondlife | Of course, it may be using the same innards as Sansa do or something... |
08:47:28 | GodEater | in that case I advise not dismantling it |
08:47:45 | pondlife | Sound advice there. |
08:47:49 | GodEater | I'd rather go and find other users and get the interested |
08:47:51 | GodEater | *them |
08:47:56 | pondlife | I'd rather buy a new DAP |
08:48:01 | GodEater | :D |
08:48:14 | cweiske | buy a new one after dismantling? :) |
08:48:16 | GodEater | or, more accurately, a "used one that runs Rockbox already" :) |
08:48:20 | pondlife | Indeed |
08:48:46 | GodEater | cweiske: is this your device ? http://www.engadget.com/2009/04/05/archos-2-and-archos-4-flash-players-leak-out/ |
08:48:55 | cweiske | yep |
08:48:58 | cweiske | the black one on the top |
08:49:06 | GodEater | WAAAAAY too new to run Rockbox :D |
08:49:14 | cweiske | oh |
08:49:28 | cweiske | why is that? |
08:49:36 | GodEater | it takes about a year to do a port, and that's WITH good documentation and an expert developer |
08:49:54 | GodEater | a lot of ports take longer, because there is no documentation on the parts |
08:50:01 | pondlife | Sadly no tech details on http://www.archos.com/products/mp3_players/archos_2/index.html?country=gb&lang=en ;) |
08:50:13 | GodEater | what a surprise. not. |
08:50:16 | cweiske | most tech spec pages suck |
08:50:44 | pondlife | There would be some poetry in a new Archos device being supported.... but I'm no poet. |
08:50:45 | GodEater | I can't find a teardown of it either |
08:50:49 | Dhraakellian | does Rockbox receive much of any support from device manufacturers? |
08:50:57 | GodEater | Dhraakellian: virtually none at all |
08:51:19 | Dhraakellian | some e200v1s from SanDisk back in the day and nothing else? |
08:51:31 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
08:51:39 | | Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-4dd740f82b3c80a9) |
08:51:40 | GodEater | it wasn't even a v1, it was a prototype I think |
08:51:44 | GodEater | and we got no docs with it |
08:51:45 | Dhraakellian | ah |
08:51:57 | GodEater | http://daniel.haxx.se/rockbox-sandisk-connection.html <−− bagder wrote about it |
08:52:46 | | Join flydutch [0] (n=flydutch@host46-210-dynamic.15-87-r.retail.telecomitalia.it) |
08:52:55 | GodEater | seems I remember not quite accurately |
08:53:04 | GodEater | there was a dev board, but it came later |
08:53:19 | | Join ender [0] (i=krneki@foo.eternallybored.org) |
08:54:35 | Zagor | pixelma: I looked at the usb id of my c200 yesterday, and the ums id is correct. however my battery seems to have broken, so I couldn't change into mtp mode and see the id for that. I'll bring it to devcon. |
08:54:59 | * | Dhraakellian does, of course, think that SanDisk should just pretty up Rockbox's main menu and use it as their official firmware |
08:55:26 | | Quit dmb (Remote closed the connection) |
08:59:55 | | Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) |
09:00 |
09:00:54 | cweiske | archos2 is basically http://yifangdigital.com/Product/EM185.htm |
09:00:54 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
09:01:09 | cweiske | even if my player says "EM184RB" on it |
09:02:09 | | Join dmb [0] (n=dmb@unaffiliated/dmb) |
09:02:49 | GodEater | doesn't really tell us a lot |
09:02:54 | cweiske | yeah |
09:03:21 | cweiske | is asking the manufacturer for information going to get results? |
09:03:29 | GodEater | it never hurts :) |
09:03:33 | GodEater | but don't hold your breath |
09:03:54 | GodEater | we're still waiting for Apple to even acknowledge we asked them anything, and that's for ports that are over five years old now :D |
09:03:56 | cweiske | did it happen at least one time here? |
09:04:22 | cweiske | s/happen/work/ |
09:04:23 | GodEater | we've had *some* luck with it |
09:04:26 | linuxstb | cweiske: You mainly want information not owned by the actual device manufacturer - datasheets for the chips used. So you should find out what chips are used, and look for datasheets for them. |
09:04:30 | GodEater | but it's a rare event |
09:04:45 | pixelma | Zagor: is correct as in what's now on the wiki page or what you put in there before? |
09:05:50 | GodEater | unless Archos suddenly became a semi-conductor manufacturer and are making their own chips now |
09:06:03 | jordan`` | i remember samsung korea uploading the whole gcc etc toolchain for their calmrisc chip for the gmini project |
09:06:48 | | Quit ender` (Read error: 110 (Connection timed out)) |
09:07:20 | Zagor | pixelma: well, both :-) since I could only test ums I only got the 7451 id, which is undisputed. it was 7450 that I first wrote was ums on c250, and is now changed to c200 mtp. |
09:08:24 | pixelma | but you had it as c240 UMS ;) |
09:08:57 | pixelma | anyway, thanks for testing :) |
09:10:39 | | Join stoffel [0] (n=quassel@p57B4E302.dip.t-dialin.net) |
09:11:42 | | Quit VytenisS ("Quit") |
09:13:40 | | Quit stoffel (Remote closed the connection) |
09:13:42 | cweiske | where - except on ebay - does on get used/broken players to tear apart? |
09:14:15 | _Auron_ | pawn shops? |
09:16:39 | * | LinusN tried PictureFlow for the first time yesterday |
09:17:03 | LinusN | took me quite some time to find it - why on earth is it listed under Demos? |
09:17:30 | pixelma | because until recently you coul only look at your art |
09:17:49 | LinusN | aha, perhaps we should move it then |
09:17:54 | amiconn | Where? |
09:18:00 | amiconn | It's not a game, and it's not an app either, imho |
09:18:12 | pixelma | (and it still is this way on some targets ;) ) |
09:18:21 | LinusN | if it browses your AA and lets you play music, i would certainly call it an app |
09:19:52 | GodEater | me too |
09:20:49 | _Auron_ | I don't see how its not an app |
09:20:51 | tmzt | is PF supposed to go further than the progress bar? |
09:21:06 | n1s | well, it being a plugins is only supposed to be temporary anyway, right? |
09:21:13 | GodEater | tmzt: of course |
09:21:27 | GodEater | n1s: really ? |
09:21:32 | GodEater | where else would you have it ? |
09:21:44 | | Quit dmb (Read error: 104 (Connection reset by peer)) |
09:21:45 | n1s | GodEater: in the core from what i understood |
09:21:46 | tmzt | I have 1500 songs in database, very few with AA |
09:21:56 | GodEater | wow - that's news |
09:22:11 | GodEater | when was it decided it was going into core ? |
09:22:11 | n1s | i may of course have totally misunderstood :) |
09:22:13 | linuxstb | n1s: I would expect it to still be a plugin, just not one launched manually by the user. |
09:22:22 | n1s | linuxstb: ah |
09:22:25 | tmzt | it takes a long time in progress bar the exits to plugin list |
09:22:38 | GodEater | tmzt, that's crashing then |
09:23:00 | GodEater | you should only see the progressbar the first time you run it |
09:23:38 | GodEater | linuxstb: so how is it going to be launched then ? |
09:23:54 | tmzt | this is on fuze, current svn as of yesterday |
09:23:57 | linuxstb | GodEater: There was talk of it being launched from the DB viewer |
09:24:04 | GodEater | fuze is unsupported tmzt |
09:24:12 | tmzt | ah ok |
09:24:12 | GodEater | linuxstb: nifty :D |
09:24:28 | linuxstb | GodEater: kugel posted a patch to do that - it's on Flyspray somewhere. |
09:24:42 | GodEater | waste of time me looking at it |
09:24:45 | GodEater | I never use the DB |
09:24:52 | tmzt | just reporting, didn't realize target was important for this |
09:24:53 | | Join petur [50] (n=petur@rockbox/developer/petur) |
09:25:03 | GodEater | tmzt: target is always important :D |
09:25:17 | GodEater | esp. if it's an incomplete port |
09:25:26 | linuxstb | With a buggy disk driver (IIUC) |
09:25:40 | tmzt | it works on e200 then? |
09:25:48 | | Join lucent [0] (i=lucent@unaffiliated/shadows) |
09:25:55 | GodEater | it works on all our supported targets I believe |
09:26:04 | GodEater | with varying degrees of functionality |
09:26:19 | GodEater | I'm curious to see it on an archos |
09:26:43 | tmzt | isn't that a little underpowered? |
09:27:07 | GodEater | I've seen people talking about it running on them though |
09:27:41 | tmzt | anyway, if it's unsupported as of now I just keep trying it and observing the progress |
09:28:50 | lucent | CUE-In-FLAC support... how do I give names to each cuepoint? |
09:28:57 | lucent | Is that in the manual? I couldn't find it |
09:29:16 | GodEater | ah, another feature I don't use |
09:30:26 | pixelma | lucent: have you actually searched the manual for cuesheet support? |
09:30:35 | lucent | pixelma: I lied |
09:30:56 | GodEater | and people wonder why we're grumpy at our users |
09:31:02 | | Join funman [0] (n=fun@rockbox/developer/funman) |
09:31:10 | lucent | :/ |
09:31:29 | linuxstb | lucent: Rockbox doesn't support "cue-in-FLAC", only external .cue files. |
09:31:31 | lucent | funman: FYI the recent (as of now in SVN) changes work great on 8gb fuze |
09:31:35 | funman | Unhelpful: see ARM_ARCH in export/config.h (4, 5 or 6) |
09:32:09 | lucent | linuxstb: interesting. I was not aware of that, so I should be looking to add metadata to the cue file instead I suppose |
09:32:19 | funman | lucent: cool! did you have to update the bootloader? |
09:32:25 | lucent | funman: yes, affirmative |
09:32:34 | pixelma | hmm... the paragraph in the manual is a bit lacking :\ |
09:32:40 | lucent | it also fixed a glitch I had with my 8gb uSD card and resuming playback |
09:32:44 | | Join dmb [0] (n=dmb@unaffiliated/dmb) |
09:33:07 | lucent | now I am praying for charge-while-playing support for fuze and rockbox ;P |
09:33:21 | lucent | that way I could use it in my car all the time and not need OF |
09:35:06 | pixelma | gevaerts: already freed some space on your build server? |
09:35:19 | tmzt | funman: you have 8g fuze? |
09:36:02 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
09:36:47 | funman | lucent: usb_detect() would need to be correctly implemented (i.e. detect only USB connection and not chargers) |
09:36:51 | funman | tmzt: 4GB |
09:37:11 | FrankTM | i would like usb connection without charge aswell |
09:37:15 | FrankTM | not quite sure if that is possible |
09:37:33 | lucent | usb connection without charge? |
09:37:50 | tmzt | okay, I have 8g, after upgrading OF and restoring 8gb fat rockbox works with new bootloader |
09:37:51 | FrankTM | yea |
09:37:51 | GodEater | why on earth would you want that ? |
09:37:53 | lucent | are you sure about that? I don't understand if that's a language mistake |
09:37:56 | Mikachu | laptop? |
09:38:03 | FrankTM | i think it's better for the battery |
09:38:10 | FrankTM | to not charge it untill it's empty |
09:38:21 | Mikachu | that doesn't matter for lithium batteries |
09:38:41 | GodEater | FrankTM: yeah, sorry, you're wrong there |
09:38:42 | lucent | for LiPo batteries you will damage them by discharging them fully |
09:39:01 | GodEater | it's better to keep them charging |
09:39:04 | FrankTM | i stand corrected :) |
09:39:36 | | Join IuDeX [0] (n=52a0f8f7@gateway/web/cgi-irc/labb.contactor.se/x-29fe843c349d52bd) |
09:39:40 | funman | gevaerts: why is HAVE_USBSTACK required for rebooting to OF when usb is plugged (with !defined(USE_ROCKBOX_USB) ? |
09:40:18 | IuDeX | hey, How can i compile Bootloader? Need I any additions? I compiled sucessfully RB. |
09:41:04 | funman | by the way DeviceChart wiki page would need addition of sansa ams |
09:41:05 | GodEater | bootloader for what ? |
09:41:19 | IuDeX | Clip. |
09:41:22 | IuDeX | v1 |
09:41:25 | funman | IuDeX: http://www.rockbox.org/twiki/bin/view/Main/SansaAMS#Bootloader_Installation |
09:41:32 | n1s | IuDeX: usually the same way as you compile rockbox, just select bootloader in the configure |
09:41:51 | lucent | IuDeX: the link funman posted is best to read |
09:41:58 | IuDeX | Thanks :) |
09:42:49 | lucent | funman: does charging work on Fuze anyways, USB detection aside? |
09:43:18 | FrankTM | i do get a "plug" logo when usb is connected |
09:43:36 | funman | lucent: yes |
09:44:45 | lucent | funman: thank you for your work on the Fuze overall, it is very pleasing to use Rockbox and I would only do so because of the recent month's work on supporting Fuze |
09:45:01 | | Quit IuDeX ("CGI:IRC (EOF)") |
09:45:15 | | Join mib_tv97lamw [0] (i=792c1403@gateway/web/ajax/mibbit.com/x-0a94e4d75a69e314) |
09:45:28 | lucent | I can wait patiently for someone to crack open the usb detect problem and solve :) |
09:46:04 | FrankTM | i wish i could do that :p |
09:46:20 | lucent | though I kind of wish there was a manual way to tell rockbox that I want to only charge when USB is plugged in and not stop the music, is that "Car adapter mode" something different? |
09:46:39 | mib_tv97lamw | Ok, its me again from yesterday , the guy with the broken Gigabeat X30 |
09:46:57 | linuxstb | funman: Why did you remove the link to the released mkamsboot from the SansaAMS page? Do you want to undo the release? |
09:47:18 | mib_tv97lamw | My friend (who had one) said there was an easy fix for my problem, but is gonna make me pay $10 for him to tell me |
09:47:28 | mib_tv97lamw | I was hoping you guys could help me out |
09:47:38 | n1s | lucent: on most players you can press a button while connecting to do that |
09:48:02 | mib_tv97lamw | My gigabeat boots partway (i accidentally deleted some files from the GBSystem folder) |
09:48:06 | funman | linuxstb: accidentally this release will not refuse untested OFs, so I prefer to not let users use it |
09:48:19 | mib_tv97lamw | Which I then rstored rockbox to it |
09:48:29 | lucent | n1s: a button while Rockbox is going? I'm not familiar with this or which button to try |
09:48:34 | linuxstb | funman: Then perhaps it should be deleted from the download servers. |
09:48:45 | | Join IuDeX [0] (n=marek@78-131-211-178.tktelekom.pl) |
09:48:50 | mib_tv97lamw | Then I turned it off, realised my mistake and tried to restore the gigabeat firmware |
09:48:56 | IuDeX | whoops! I see The compiler you must use (arm-elf-gcc) is not in your path!" |
09:49:06 | funman | linuxstb: right, i wanted to quickly work on another version but didn't do it |
09:49:39 | mib_tv97lamw | unfortunately, after many restores, I opened the thing, followed the rockbox guide, but this didn't solve my problem either. |
09:49:43 | GodEater | lucent: the buttons varies from target to target, and given you're using an incomplete port, there's likely no documentation to tell you which button (if any) it is yet |
09:49:55 | IuDeX | ANyone can help me?:) |
09:50:01 | mib_tv97lamw | It says "No system found on hdd" (Error code 0010070) |
09:50:03 | funman | lucent: try to press the center button while connecting usb |
09:50:11 | linuxstb | funman: Maybe LinusN can delete it (mkamsboot on the download servers). The problem is that I don't know if the mirrors are correctly deleting files... |
09:50:35 | | Nick daurn is now known as daurnimator (n=daurnima@unaffiliated/daurnimator) |
09:50:57 | lucent | funman: brilliant! |
09:51:20 | lucent | and thank you GodEater for the advice. I'm a happy panda lucent knowing this. |
09:51:45 | IuDeX | Where I have to export arm-elf-gcc? |
09:51:52 | funman | lucent: now you could add this information to the fuze manual ;) |
09:52:24 | markun | mib_tv97lamw: and you tried with the dummy files + the rockbox bootloader? |
09:52:36 | funman | IuDeX: http://www.rockbox.org/twiki/bin/view/Main/CrossCompiler |
09:52:51 | lucent | I'm preparing a long car drive to travel and go camping, when I return from my trip ... hope that there are no new bugs for me to find? :) |
09:53:06 | IuDeX | export PATH=$PATH:/usr/local/arm-elf/bin:/usr/local/m68k-elf/bin:/usr/local/sh-elf/bin |
09:53:10 | IuDeX | oops xD |
09:53:15 | mib_tv97lamw | I couldn't find the dummy files, but someone said that they were included in the utility? |
09:53:33 | markun | mib_tv97lamw: no, they can be downloaded. Wait, I'll show you. |
09:53:43 | mib_tv97lamw | ah ok thank you |
09:54:10 | GodEater | mib_tv97lamw: tell this "friend" of yours to take a hike by the way. $10 indeed. |
09:54:19 | funman | LinusN: Bagder could you delete mkamsboot-1.0 from the download server ? (and also the mirrors?) - a potentially harmful bug went into this release |
09:54:25 | markun | mib_tv97lamw: http://www.rockbox.org/twiki/bin/view/Main/GigabeatFXPort#Improved_Boot_Time_Optional |
09:54:32 | | Quit Thundercloud (Remote closed the connection) |
09:54:42 | mib_tv97lamw | thanks |
09:55:09 | mib_tv97lamw | He's apparently not going to help me because I won't give him a discount selling him stuff |
09:55:21 | mib_tv97lamw | the diff is I'm selling stuff, he's being a douche |
09:55:30 | | Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) |
09:55:32 | markun | mib_tv97lamw: so, you need to extract that zip file, and also download FWMIMG02.DAT and place it in the same GBSYSTEM folder |
09:55:40 | mib_tv97lamw | thank you |
09:55:42 | markun | FWIMG01.DAT even :) |
09:55:42 | mib_tv97lamw | wait? |
09:55:49 | mib_tv97lamw | I have the original CD |
09:55:53 | mib_tv97lamw | with the firmware on it |
09:56:13 | markun | maybe you can find the files there as well |
09:56:19 | | Quit IuDeX ("Leaving") |
09:56:27 | mib_tv97lamw | kk |
09:56:39 | markun | with these dummy files you can only run rockbox |
09:56:49 | markun | the original firmware will not longer work |
09:56:52 | mib_tv97lamw | thats fine, thanks |
09:59:05 | | Quit bmbl (Connection timed out) |
09:59:22 | markun | mib_tv97lamw: if everything fails, you can wait for LambdaCalculus or toffe to come online, I think they both have Gigabeat X |
10:00 |
10:00:30 | | Join IuDeX [0] (n=marek@78-131-211-178.tktelekom.pl) |
10:00:40 | mib_tv97lamw | Ok |
10:00:57 | IuDeX | HAve someone OF With Bootloader? ;/ I cant compile. |
10:01:05 | | Quit funman ("leaving") |
10:01:14 | mib_tv97lamw | markun: I had a FWIMG01.DAT.orig, but not FWIMG01.DAT |
10:01:21 | mib_tv97lamw | Maybe that was my problem? |
10:01:28 | linuxstb | IuDeX: You said you successfully compiled Rockbox? What's the problem with the bootloader? |
10:01:50 | IuDeX | linuxstb: RB compiled successfully, but BOotloader says ERROR 1 |
10:02:02 | IuDeX | /home/marek/rockbox/firmware/drivers/fat.c:2480: warning: pointer targets in passing argument 1 of ‘strlen’ differ in signedness |
10:02:14 | mib_tv97lamw | I swear, after this, I'm going to make a guide for opening the X30 and submit it to the Rockbox site so other people have an easier time |
10:02:14 | IuDeX | lots of errorS ;O |
10:02:24 | markun | mib_tv97lamw: the .orig file can be copied back to FWIMG01.DAT |
10:02:50 | markun | and good idea to contribute to the wiki :) |
10:03:59 | IuDeX | linuxstb: Do you know what is it? |
10:06:33 | cweiske | I got an answer from archos support - i told them my comlete music collection does not work on it. they told me they don't support it, and can't tell wether future firmwares will support it. but they told their development unit. |
10:07:49 | mib_tv97lamw | :D |
10:08:09 | mib_tv97lamw | Oh, I had another thing, my bootloader usb never works :D |
10:08:25 | mib_tv97lamw | dunno why, and it works sometimes in rockbox, but not always |
10:08:40 | mib_tv97lamw | it worked 100% from the gigabeat firmware though |
10:08:53 | mib_tv97lamw | the pre firmware thing when it was broken* |
10:08:57 | mib_tv97lamw | anyway |
10:08:59 | mib_tv97lamw | thank you |
10:09:06 | | Part mib_tv97lamw |
10:09:43 | IuDeX | ;/ |
10:11:47 | cweiske | the archos2 is listed by lsusb as " 071b:0184 Domain Technologies, Inc.". that company seems to sell usb development hardware. does that mean the manufacturer forgot to change the usb ids? |
10:13:08 | | Quit IuDeX ("Leaving") |
10:30:31 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
10:35:49 | | Quit kachna|lappy (Read error: 113 (No route to host)) |
10:38:30 | *** | Saving seen data "./dancer.seen" |
10:38:51 | n1s | cweiske: or they decided no to |
10:38:58 | n1s | not* |
10:44:40 | | Quit cool_walking_ ("http://www.mibbit.com ajax IRC Client") |
10:55:24 | | Join haohmaru [0] (n=MAJIC@141-70-69-139.user.wh-stuttgart.de) |
11:00 |
11:00:58 | | Join merbzt3 [0] (n=benlar@193.13.246.198) |
11:00:59 | | Quit anigav (Read error: 60 (Operation timed out)) |
11:03:06 | | Join pyro_maniac1 [0] (i=foobar@p57BBA008.dip0.t-ipconnect.de) |
11:03:09 | | Join anigav [0] (n=MAJIC@vpn-s-8d3a301a.campus.uni-stuttgart.de) |
11:08:25 | | Quit haohmaru (Read error: 60 (Operation timed out)) |
11:34:59 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
11:52:27 | | Join timc [0] (n=aoeu@119.109.100.148) |
11:57:16 | | Join kachna|lappy [0] (n=kachna@213.220.198.248) |
12:00 |
12:03:47 | | Quit martian67 (simmons.freenode.net irc.freenode.net) |
12:03:47 | NSplit | simmons.freenode.net irc.freenode.net |
12:03:47 | | Quit pyro_maniac1 (simmons.freenode.net irc.freenode.net) |
12:03:47 | | Quit goffa__ (simmons.freenode.net irc.freenode.net) |
12:08:09 | NHeal | simmons.freenode.net irc.freenode.net |
12:08:09 | NJoin | pyro_maniac1 [0] (i=foobar@p57BBA008.dip0.t-ipconnect.de) |
12:08:09 | NJoin | goffa__ [0] (n=goffa@216.220.23.105) |
12:08:09 | NJoin | martian67 [0] (n=martian6@about/linux/regular/martian67) |
12:08:19 | | Join goffa [0] (n=goffa@216.220.23.105) |
12:08:59 | | Quit goffa__ (Remote closed the connection) |
12:15:30 | * | kugel believes to have a fix for http://www.rockbox.org/tracker/task/10101 |
12:18:29 | FrankTM | hehe. binary task id |
12:20:29 | kugel | haha |
12:20:30 | kugel | indeed |
12:21:07 | n1s | and a palindrome too |
12:21:14 | FrankTM | true that :p |
12:21:35 | Torne | kugel: ooh, that would be nice |
12:21:56 | Torne | i seem to find it stops buffering a lot, i've not worked out precisely what conditions cause it but that's certainly one of them :) |
12:23:21 | kugel | the biggest problem is that if the bug occurs, boosting also doesn't stop |
12:23:52 | kugel | maybe storage doesn't spindown too |
12:24:10 | FrankTM | so down with battery life? |
12:24:48 | kugel | Torne: I'd be happy if you (unsuccessfully) try to reproduce it with that fix: http://pastie.org/505544 |
12:24:53 | kugel | FrankTM: exactly |
12:25:17 | Torne | ah, yes, i had also noticed that it doesn't stop boosting |
12:25:42 | * | kugel wonders if that fixes another possibly related task too |
12:25:55 | Torne | kugel: i'll do a build with that later on |
12:26:01 | FrankTM | wouldnt you be able to tell which track is next (even with skipping), and buffer after all |
12:26:06 | CIA-38 | New commit by rmenes (r21233): I misspelled Vytenis Sabelka's name earlier. |
12:26:55 | Torne | i have also had cause to suspect that certain cases of inserting stuff into the playlist causes the same thing.. i haven't tried very hard to reproduce it under specific circumstances, mind |
12:27:12 | Torne | but at least there is a similar issue: it's very easy to get the next: display on WPS to be wrong by inserting tracks |
12:27:24 | Torne | not sure if buffering also has gone wrong at that point or not |
12:27:47 | Torne | i'll have a fiddle later without and with your patch and see what i can establish |
12:28:22 | pixelma | the next track info will "correct" itself on next update (track change) |
12:28:34 | Torne | pixelma: yes, I know |
12:28:38 | pixelma | not nice, but I don't think buffering goes wrong |
12:28:44 | Torne | but what i'm wondering is has it buffered the right thing in the meantime |
12:28:55 | Torne | or does it get to the end of the track and go "crap i need to read a different track" |
12:29:02 | kugel | track info will update on rebuffering too |
12:29:17 | kugel | which is supposed to happen on inserting a track which is to be played next |
12:29:31 | Torne | in which case i'm *reasonably* sure there are conditions under which that doesn't happen ;) |
12:29:36 | pixelma | well in my tries it plays the right track as listed in the "view playlist" |
12:29:44 | Torne | yes, it always *plays* the right track |
12:30:23 | kugel | you mean insert next, don't you? |
12:30:30 | Torne | yes |
12:30:32 | Torne | or other cases |
12:30:37 | Torne | i do insert shuffled on entire albums a lot ;) |
12:30:46 | Torne | which pretty much totally screws any buffered data ;) |
12:30:55 | kugel | works here |
12:31:05 | Torne | what do you mean by works though |
12:31:23 | kugel | hm |
12:31:31 | Torne | it always plays the tracks in the order they are in the playlist just fine, but quite often (possibly always?) it doesn't update the Next: display |
12:31:36 | kugel | something is is borked after inserting an album |
12:31:39 | Torne | and presumably given the above, also isn't re-buffering |
12:31:52 | Torne | so that although it plays the right thing it doesn't get around to rebufferign until the current track ends |
12:32:05 | Torne | i could be wrong here, i've not sat down and tested this in controlled conditions |
12:32:18 | Torne | it's just something i've noticed while using it normally |
12:32:36 | pixelma | use a WPS which shows "disk" activitaty and you can see if it pretends to rebuffer |
12:32:56 | kugel | I think it rebuffers only if the already buffered tracks are invalid |
12:33:02 | pixelma | (or have a target with a real LED showing this) |
12:33:10 | Torne | what makes them invalid? (i don't know how buffering works) :) |
12:33:50 | kugel | Torne: I think I reproduced here. play an album. Insert next a track and the next track info is fine, then insert an album and the next track info is behind the inserted album |
12:34:11 | kugel | for some reason, it shouldn't even move, since the album is inserted behind the track that was inserted befoer |
12:34:23 | Torne | hm, not sure if that's the same thing |
12:34:28 | Torne | anyway i'll give it a test tonight if i have time |
12:34:39 | Torne | and will see if the behaviour changes for better/worse with your patch ;) |
12:34:58 | kugel | my patch only tries to fix fs#10101 |
12:35:17 | Torne | yah. i have that problem too, though |
12:35:20 | Torne | so i'll see ;) |
12:35:49 | | Part cweiske ("Verlassend") |
12:38:31 | *** | Saving seen data "./dancer.seen" |
12:46:04 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
12:48:19 | | Join gregzx [0] (n=chatzill@aarr221.neoplus.adsl.tpnet.pl) |
12:55:26 | | Join TheSphinX^ [0] (n=cold@p54A5CB3B.dip.t-dialin.net) |
12:57:48 | | Join barrywardell [0] (n=barry@barry-workstation.ucd.ie) |
13:00 |
13:02:41 | | Join perfectdrug [0] (n=marko@p5B0EC28F.dip.t-dialin.net) |
13:02:49 | kugel | pondlife: ping |
13:02:55 | pondlife | pong |
13:03:38 | kugel | did you suffer from FS #10101 or could you reproduce it, or did you just stated your opinion? I believe to have a fix (I uploaded a patch) |
13:04:03 | pondlife | I don't think I've seen it myself, but can't remember for sure ;) |
13:04:05 | kugel | also, I need to try the timestrech patch on the fuze now that it is finally fast enough |
13:04:30 | | Join kugel_ [0] (n=kugel@e178073164.adsl.alicedsl.de) |
13:06:15 | | Quit kugel (Nick collision from services.) |
13:06:19 | | Nick kugel_ is now known as kugel (n=kugel@e178073164.adsl.alicedsl.de) |
13:08:22 | | Quit kachna|lappy (Read error: 110 (Connection timed out)) |
13:14:44 | | Join fyrestorm [0] (n=nnscript@cpe-24-90-81-178.nyc.res.rr.com) |
13:15:00 | | Quit Zarggg (Read error: 110 (Connection timed out)) |
13:16:13 | | Quit fyrestorm (Client Quit) |
13:16:43 | | Join fyrestorm [0] (n=nnscript@cpe-24-90-81-178.nyc.res.rr.com) |
13:17:41 | | Join wark [0] (n=wark@fctnnbsc15w-142166056194.pppoe-dynamic.nb.aliant.net) |
13:21:29 | pondlife | kugel: Thanks, let me know how you get on with #8894 |
13:22:13 | | Quit timc (Read error: 110 (Connection timed out)) |
13:22:34 | kugel | pondlife: my script fails if you don't write fs before :( |
13:22:42 | pondlife | heh |
13:22:46 | pondlife | FS #8894 |
13:22:51 | pondlife | Is that better? ;) |
13:23:28 | CIA-38 | New commit by learman (r21234): Correct the includes; the old way broke parallel builds. |
13:23:57 | pondlife | kugel: Do you have a Clip? |
13:24:04 | kugel | pondlife: much better :D |
13:24:29 | kugel | yea |
13:24:46 | pondlife | Cool - maybe you could see if there's a keymap possible for timestretch? |
13:24:49 | | Join timc [0] (n=aoeu@116.3.199.84) |
13:25:10 | pondlife | (See ACTION_PS_SLOWER and ACTION_PS_FASTER in keymap-clip.c..) |
13:25:48 | kugel | will do |
13:26:21 | kugel | pondlife: I wouldn't worry about the clip's keymap though |
13:26:32 | kugel | it needs refinement all over the place anyway |
13:27:10 | pondlife | OK, it's just the only SWCODEC target that timestretch can't be fully used on, purely as there's no spare keys (I think). |
13:27:37 | pondlife | Would be nice to fix it as we go, but I won't worry unduly. |
13:28:03 | kugel | I think the clip has as many buttons as the c200 |
13:28:42 | pondlife | Does it have up/down/left/right? |
13:29:02 | kugel | yes, and it has also dedicated volume buttons on the side |
13:29:20 | pondlife | Hmm, weird existing pitchscreen keymap then? |
13:29:41 | kugel | That's what I said :P |
13:33:10 | pondlife | Hmm, no mode button on c200 either |
13:33:47 | kugel | the clip's keymap is originally heavily based on the c200's, and wasn't optimized much since then |
13:34:27 | pondlife | Is there a picture of the c200 showing the keys on the wiki? |
13:34:33 | pondlife | Nothing on http://www.rockbox.org/twiki/bin/view/Main/SansaC200Port |
13:34:44 | | Nick J-23 is now known as J-23_ (n=zelazko@unix.net.pl) |
13:34:46 | | Nick J-23_ is now known as Moarc (n=zelazko@unix.net.pl) |
13:35:07 | | Nick Moarc is now known as J-23 (n=zelazko@unix.net.pl) |
13:35:22 | * | pixelma recommends the fine manual |
13:35:42 | * | pondlife will look |
13:36:48 | kugel | pondlife: was the manual issue solved? |
13:37:00 | pixelma | there was none |
13:37:18 | pondlife | I just needed to make clean, I think. |
13:37:18 | kugel | well, it only worked after make clean or so, didn't it? |
13:37:38 | kugel | did you build it in the build folder or in a seperate manual folder? |
13:38:25 | pixelma | that shouldn't matter any more since you have to use "make manual" now |
13:38:26 | pondlife | A seperate folder |
13:39:00 | pondlife | Why does configure still offer (M) for Manual? |
13:39:22 | pixelma | and I build in seperate folders too and didn't have the problem |
13:39:55 | kugel | pondlife: works so far on the fuze, no dataabort at changing speed |
13:40:03 | pondlife | c200 pitchscreen - which button should be exit and which button should change mode? |
13:40:15 | pondlife | kugel: Can you actually get into the timestretch mode?? |
13:40:22 | kugel | yea |
13:40:37 | | Quit gevaerts (Nick collision from services.) |
13:40:46 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
13:41:20 | pixelma | pondlife: is the Select button already used for something else? |
13:41:20 | | Part perfectdrug |
13:41:31 | pondlife | Yes, Select is reset |
13:42:01 | | Join funman [0] (n=fun@rockbox/developer/funman) |
13:42:02 | pondlife | kugel: Which button switches modes in your build? I've confused myself |
13:42:07 | pondlife | REC? |
13:42:23 | | Join kugel_ [0] (n=kugel@e178106236.adsl.alicedsl.de) |
13:42:57 | | Nick J-23 is now known as DeSnajpa_VIII (n=zelazko@unix.net.pl) |
13:43:01 | | Quit DeSnajpa_VIII (Nick collision from services.) |
13:43:07 | | Join J-23 [0] (n=zelazko@unix.net.pl) |
13:43:17 | kugel_ | the fuze can do it almost without boosting. Running pf while music is playing fast is fun too :P |
13:43:20 | | Quit kugel (Nick collision from services.) |
13:43:24 | | Nick J-23 is now known as DeSnajpa_VIII (n=zelazko@unix.net.pl) |
13:43:29 | | Nick kugel_ is now known as kugel (n=kugel@e178106236.adsl.alicedsl.de) |
13:43:34 | | Quit DeSnajpa_VIII (Nick collision from services.) |
13:43:45 | | Join J-23 [0] (n=zelazko@unix.net.pl) |
13:43:53 | | Quit linuxstb (Read error: 113 (No route to host)) |
13:44:07 | kugel | I found that some specific speed factors are quite accaptable for music too |
13:44:09 | pondlife | kugel: I think you missed my question... which button sets pitchscreen mode on c200 |
13:44:10 | pondlife | ? |
13:44:20 | pixelma | Rec could be a possibility for switching modes - or make a short Select switching the modes and a long Select resetting things? |
13:44:34 | | Quit r0b- (Read error: 104 (Connection reset by peer)) |
13:44:36 | kugel | the keymap file can tell you. I would have to look it up myself (I'm not owning a c200) |
13:44:43 | pondlife | Ah, ok |
13:44:51 | | Join r0b- [0] (n=nnscript@adsl-76-236-182-214.dsl.klmzmi.sbcglobal.net) |
13:44:59 | kugel | rec sounds reasonable though |
13:45:20 | pondlife | And HOME on Clip, right? |
13:45:41 | kugel | sounds good, that's what the fuze is doing |
13:45:52 | pondlife | Great, minor update coming up. |
13:46:17 | pixelma | is that in the manual part of the patch too? |
13:47:14 | kugel | we should shrink the pc buffer for the fuze |
13:47:40 | kugel | even at 250% timestrech with crossfeed and replaygain, it hardly empties |
13:48:18 | pondlife | pixelma: No, I'm really not sure about the manual and keymap stuff. |
13:48:39 | funman | kugel: do you mean pcm ? |
13:48:46 | kugel | yea |
13:48:47 | | Join spiral [0] (n=marko@p5B0EC28F.dip.t-dialin.net) |
13:48:50 | pondlife | I'd rather have the keymaps tried on target first... |
13:48:51 | kugel | pcm* |
13:49:17 | kugel | 150K seems to be perfectly sufficient |
13:49:19 | funman | have you looked at .ape files (the levels impossible to decode real time) |
13:49:28 | kugel | on all targets |
13:50:03 | kugel | I think only the beast can decode the 2nd level at realtime, all others hardly the first |
13:52:25 | kugel | funman: the key is how fast the pcm buffer can be refilled while boosted at heavy load, and it's *very* fast on the AMSes |
13:53:55 | funman | i just wanted to put pressure on the heavy load : ape codec seems heavy enough to prooftest how fast the pcm buffer is refilled |
13:54:40 | | Nick parafin is now known as parafin|sleep (i=parafin@paraf.in) |
13:54:49 | | Nick parafin|sleep is now known as parafin (i=parafin@paraf.in) |
13:56:19 | | Join kugel_ [0] (n=kugel@e178120000.adsl.alicedsl.de) |
13:56:41 | | Quit kugel (Nick collision from services.) |
13:56:47 | | Nick kugel_ is now known as kugel (n=kugel@e178120000.adsl.alicedsl.de) |
13:57:38 | kugel | funman: there are codecs which some targets just can't decode with a *resonable* pcmbuffer, ape is one of them for almost all targets |
13:58:02 | | Nick spiral is now known as perfectdrug (n=marko@p5B0EC28F.dip.t-dialin.net) |
14:00 |
14:07:09 | | Quit perfectdrug (Remote closed the connection) |
14:08:45 | | Join LambdaCalculus37 [0] (i=44a0430d@rockbox/staff/LambdaCalculus37) |
14:19:25 | | Join perfectdrug [0] (n=marko@p5B0EC28F.dip.t-dialin.net) |
14:20:04 | | Quit perfectdrug (Remote closed the connection) |
14:20:26 | | Join perfectdrug [0] (n=marko@p5B0EC28F.dip.t-dialin.net) |
14:28:08 | | Join __lifeless [0] (n=lifeless@188.16.67.178) |
14:31:23 | kugel | funman: the buttonlight is weird :/ |
14:36:50 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
14:38:33 | *** | Saving seen data "./dancer.seen" |
14:39:23 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
14:42:22 | | Quit _lifeless (Read error: 110 (Connection timed out)) |
14:43:40 | | Quit KRB () |
14:45:39 | funman | kugel: perhaps GPIOD_DIR &= ~(1<<7); will prevent SD I/O from lighting it ? |
14:50:08 | kugel | I've tried various things |
14:50:36 | kugel | we're probably missing some bits in the SD_MCI register |
14:51:35 | kugel | the OF toggles SD_MCI_POWER bit 7 (rod) in the buttonlight function, but maybe it does more with SD_MCI_POWER in its storage driver for buttonlight to work properly |
14:53:12 | kugel | funman: what did you find in the dbop disassembly, btw? |
14:53:29 | funman | i still didn't look |
14:54:35 | | Join Rondom [0] (n=Rondom@dslb-084-057-174-093.pools.arcor-ip.net) |
15:00 |
15:01:40 | | Quit Zagor ("Don't panic") |
15:19:46 | | Join kushalone [0] (n=kushal@12.169.180.134) |
15:23:46 | | Join Framstag [0] (n=framstag@diaspora.rus.uni-stuttgart.de) |
15:24:25 | Framstag | huhu |
15:24:52 | Framstag | I have just read about this channel on the FAQ, so I thought to join :-) |
15:25:20 | FrankTM | hi :P |
15:26:01 | Framstag | and I have question not covered by the FAQ (or at least: I have not found ot): |
15:26:29 | FrankTM | feel free to ask |
15:26:43 | Framstag | is it possible to redefine keys (with a new/other function)? |
15:26:59 | FrankTM | yes |
15:27:07 | Framstag | great! :-) |
15:27:22 | FrankTM | but. you will need to dive into the sources :p |
15:27:25 | kugel | download the source, edit it, and compile your own build. That's the only way |
15:27:31 | Framstag | urkss :-) |
15:27:49 | Framstag | ok, better than nothing :-) |
15:28:59 | FrankTM | also. if the default controls seem awefully odd, feel free to submit a bug/patch |
15:29:11 | Framstag | I need a "no need for looking at the display" mp3/radio switch |
15:30:04 | Framstag | because grabbing and looking on the player while bicycling is not that good idea |
15:30:46 | Framstag | my old iRiver CD-player has a one-key function for switching |
15:31:17 | n1s | Framstag: that will take a little coding too then |
15:32:05 | Framstag | on all newer mp3/radio player I know of , one has to hassle with softkeys or scrollable menus |
15:33:35 | Framstag | this is not positive to traffic security :-} |
15:35:27 | Framstag | in any case, I have to wait for support of the Sansa Clip |
15:39:06 | | Quit timc ("Leaving") |
15:46:52 | funman | my fuze keeps reporting "data timeout" in SD driver |
15:48:25 | | Join AndyI [0] (i=AndyI@212.14.205.32) |
15:48:42 | Torne | hm. is tehre some way to make my plugin wait for lcd updates to finish? |
15:49:05 | funman | lcd_update(); |
15:49:14 | funman | or rather rb->lcd_update() |
15:49:19 | Torne | i must be doing it wrong |
15:49:31 | Torne | atm i'm being lazy and calling lcd_update after each time i touch the screen |
15:49:42 | Torne | the plugin then does a splash and exits |
15:49:47 | Torne | and i don't see the last few updates |
15:50:00 | Torne | the right answer is to wait for a button press before exiting but i haven't gotten that far yet :) |
15:50:02 | | Quit Framstag ("Leaving") |
15:50:15 | linuxstb | Torne: Which target? Some may not finish the update before returning (IIUC) |
15:50:20 | Torne | ipodvideo |
15:51:09 | linuxstb | Then yes, I think that's one such target. |
15:51:13 | Torne | ah ok |
15:51:19 | Torne | i shall put up with it then |
15:51:32 | Torne | when it's done it won't exit immediately |
15:51:50 | Torne | i can run a "Hello world!" z-machnie program, anyway :) |
15:51:59 | | Part LinusN |
15:52:06 | Torne | the screen output code is horrible and doesn't know how to scroll yet. that would be next. :) |
15:53:54 | | Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) |
15:58:51 | Torne | this would be much easier if ZSCII actually matched unicode |
15:59:04 | Torne | alas it was designed in 1979 |
16:00 |
16:11:09 | kugel | Torne: would be nice if you could take a look at FS #10101 now if you have time |
16:11:26 | Torne | kugel: at work, i'm afraid |
16:11:38 | kugel | i thought you were coding right now |
16:11:55 | Torne | well yes |
16:12:00 | Torne | that's because i'm a slacker |
16:12:04 | Torne | but i have a meeting in a few |
16:13:49 | | Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
16:15:06 | | Quit perfectdrug () |
16:17:12 | | Join toffe82 [0] (n=chatzill@74.0.180.178) |
16:19:05 | funman | the internal SD card of my Clipv2 (I think the CSD is identical for my Fuzev1) says that we can expect a data timeout after 3 nanoseconds. That is 0.186 clock cycles. |
16:19:46 | funman | I'm gonna use the maximal 100ms delay for reads, not the lower of 100ms and computed-from-CSD 3ns |
16:24:44 | funman | my bad, it's the lower of 100ms and 100*3ns |
16:28:07 | funman | fat driver already uses gcc's division routines so I think I can use division as well in ams sd code |
16:30:31 | | Join _lifeless [0] (n=lifeless@188.16.105.3) |
16:31:12 | | Join faemir [0] (n=daniel@88-106-135-73.dynamic.dsl.as9105.com) |
16:31:53 | | Quit __lifeless (Read error: 60 (Operation timed out)) |
16:34:30 | | Join kugel_ [0] (n=kugel@e178091019.adsl.alicedsl.de) |
16:37:10 | | Quit kugel (Nick collision from services.) |
16:37:17 | | Nick kugel_ is now known as kugel (n=kugel@e178091019.adsl.alicedsl.de) |
16:38:10 | | Quit faemir ("Lost terminal") |
16:38:36 | *** | Saving seen data "./dancer.seen" |
16:45:05 | | Join chandoo [0] (n=chandoo@ool-4353b978.dyn.optonline.net) |
16:45:57 | | Join perfectdrug [0] (n=marko@91.14.194.143) |
16:48:43 | funman | struct tCardInfo is declared in hotswap.h and struct tSDCardInfo in arm/ata-sd-target.h : I wonder why this duplication exists |
16:49:22 | funman | I would say that some information isn't used by the drivers for arm (only PP and as3525 ?) so they wanted to reduce the struct size |
16:50:29 | funman | some members only exist in arm/ata-sd-target.h : current_bank, and some components of total size |
16:51:58 | funman | i'm gonna remove tSDCardInfo since all the extra members are unused |
16:53:09 | funman | and also the conversion from tSDCardInfo to tCardInfo |
16:53:45 | | Join kugel_ [0] (n=kugel@e178121186.adsl.alicedsl.de) |
16:53:55 | | Quit kugel (Nick collision from services.) |
16:54:03 | | Nick kugel_ is now known as kugel (n=kugel@e178121186.adsl.alicedsl.de) |
16:54:03 | funman | this will add some calculations only made in card_get_info_target() into PP's sd_init_device() however |
16:55:13 | pixelma | isn't that something that would affect other targets too (at least the other Sansas)? |
16:55:38 | | Quit _Auron_ ("Infinity repeatedly denies rumours of plotting with zero to bring down the Universe.") |
16:55:44 | funman | e200 c200 and philips sa9200 |
16:55:56 | funman | i will respect the freeze though |
17:00 |
17:09:40 | LambdaCalculus37 | A new language going in doesn't go against the freeze, does it? |
17:12:52 | funman | that's a new feature no ? |
17:15:09 | funman | LambdaCalculus37: are you thinking about another scripting language, after lua just get implemented? |
17:15:36 | pixelma | I thought he meant a translation |
17:16:33 | funman | oh sorry for being a geek :/ sure a new language will only make things better so i don't think it's against the freeze |
17:20:20 | | Join jgarvey [0] (n=jgarvey@98.26.65.13) |
17:23:31 | LambdaCalculus37 | pixelma: Yes, in regards to me committing the Lithuaniun translation. |
17:28:12 | saratoga | might as well it can't break anything that worked before |
17:40:31 | | Join BryanJacobs [0] (n=braujac@dhcp-urwireless-128-151-180-172.wireless.rochester.edu) |
17:40:53 | | Join __lifeless [0] (n=lifeless@188.16.119.220) |
17:43:51 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
17:48:01 | | Join BlackCow89 [0] (n=57a95004@gateway/web/cgi-irc/labb.contactor.se/x-3a8c3d2105fb5153) |
17:48:44 | BlackCow89 | hello @ all :) |
17:48:56 | BlackCow89 | i have a problem... |
17:49:20 | | Quit r0b- (Read error: 110 (Connection timed out)) |
17:50:17 | BlackCow89 | ...my ipod isn't charging when plugged into my laptop. I found this patch: http://www.rockbox.org/tracker/task/8802 but it just introduces a new function, so it needs to be defined in the language file (I think) |
17:50:38 | BlackCow89 | could someone help me to do that? I don't know which files i have to modify |
17:51:03 | | Quit linuxstb (Read error: 113 (No route to host)) |
17:53:28 | | Quit TheSphinX^ (Read error: 54 (Connection reset by peer)) |
17:54:24 | | Quit _lifeless (Read error: 110 (Connection timed out)) |
17:54:46 | saratoga | BlackCow89: http://www.rockbox.org/twiki/bin/view/Main/WorkingWithPatches |
17:55:28 | | Join evilnick [0] (i=0c140464@gateway/web/ajax/mibbit.com/x-a8025d76f9333bb6) |
17:56:07 | BlackCow89 | i know how to apply a patch, thats not the problem |
17:56:21 | BlackCow89 | the problem is, that the patch isn't "complete" |
17:56:45 | | Join TheSphinX^ [0] (n=cold@p54A5CB3B.dip.t-dialin.net) |
17:57:26 | evilnick | Which patch is this? |
17:57:33 | BlackCow89 | i need to modify some files (and i don't know which ones and in which way), in order to geht the 'settings' entry |
17:57:41 | BlackCow89 | http://www.rockbox.org/tracker/task/8802 |
17:58:16 | BlackCow89 | I'll be back in a sec. :) |
18:00 |
18:08:36 | evilnick | BlackCow89: I *think* that you'd need to add that to the EXTRA_DEFINES line in your makefile, but I'm not a coder so am only guessing - maybe someone who knows for sure will confirm |
18:09:11 | BlackCow89 | back |
18:09:45 | evilnick | It wouldn't hurt to try |
18:09:56 | BlackCow89 | I'll try |
18:10:16 | BlackCow89 | but what do I need to add? |
18:11:05 | BlackCow89 | is the makefile responsible for the options? |
18:11:24 | evilnick | It looks like you'd need to add: "HAVE_USB_CHARGING_ENABLE" (from my reading of the patch and dreamlayers comment on 18th Feb) |
18:11:40 | evilnick | BlackCow89: That's well beyond my knowledge I'm afraid :( |
18:11:52 | BlackCow89 | ok I'll try :D Thx so far :) |
18:12:18 | evilnick | I do know that one used to have to do that for testing the PP USB stack, so I'm kinda assuming that it *might* work the same way. |
18:12:37 | evilnick | If not then you'd be best off waiting for a more authorative answer ;) |
18:12:49 | BlackCow89 | I'm compiling with cygwin and it takes ages :D:D |
18:13:03 | BlackCow89 | but it can't harm to try :) |
18:13:24 | | Part pondlife |
18:18:32 | Torne | lcd_clear_display keeps the backdrop? not what i expected :) |
18:18:42 | * | Torne guesses "draw a white rectangle over the screen" time? |
18:21:03 | | Part pyro_maniac1 ("Leaving.") |
18:22:10 | funman | what does "tsac" means in MMC ? in the SD specification it's tAac but has the same meaning (data access timeout in nanoseconds) |
18:24:08 | | Join xnyhps [0] (n=xnyhps@2001:470:1f14:da:219:e3ff:fed7:c57c) |
18:28:27 | mcuelenaere | Torne: lcd_set_backdrop(NULL); |
18:29:01 | Torne | do i have to restore it then? |
18:29:04 | | Quit BryanJacobs (Read error: 110 (Connection timed out)) |
18:29:06 | Torne | this is in a plugin |
18:29:36 | mcuelenaere | yes, I think so |
18:29:40 | Torne | hm |
18:29:41 | mcuelenaere | rb->lcd_set_backdrop() |
18:29:50 | mcuelenaere | I'm not sure whether lcd_get_backdrop() is available for plugins.. |
18:29:53 | Torne | the white rectangle approach might be easier then :) |
18:30:02 | kugel | LambdaCalculus37: I think there's no problem with new languages |
18:30:05 | Torne | especially sicne it's supposed to be an arbitrary region erase. |
18:30:35 | Torne | hm. except it doesn't seem to ahve worked :( |
18:30:39 | mcuelenaere | or, (I think), you could try setting up a viewport filling the whole screen with a white background |
18:30:44 | Torne | i expect my math is bad |
18:31:34 | kugel | IMO the old backdrop should be set no matter of what the plugin in did |
18:32:28 | kugel | so, if the plugin wants unicolor background, a call to lcd_set_backdrop(NULL) and lcd_set_background(LCD_WHITE) would be sufficient, the plugin loader handles reverting this |
18:32:58 | kugel | btw, the lcd_* functions aren't remote screen friendly at all |
18:33:38 | Torne | aha |
18:33:43 | | Quit petur ("work->sports") |
18:33:45 | Torne | lcd_drawrect != lcd_fillrect :) |
18:34:05 | Torne | that would be why it doesn't work :) |
18:34:23 | kugel | yea, the one draws a rectangle, the other fills a rectangle |
18:34:44 | | Join PaulJam [0] (i=Paule@vpn-3112.gwdg.de) |
18:34:49 | kugel | you need to set the foreground if you want to override the backdrop though, and then you can't draw anything above that anymore |
18:35:05 | kugel | you basically *need* the remove the backdrop |
18:35:09 | Torne | hrm? |
18:35:12 | Torne | ok, i don't get that |
18:35:17 | Torne | i may be misunderstanding the drawing model here |
18:35:53 | kugel | you can have background color OR a backdrop |
18:35:54 | mcuelenaere | kugel: does lcd_set_background(LCD_WHITE) work? |
18:36:04 | mcuelenaere | ah never mind, read that as lcd_set_backdrop :) |
18:36:06 | kugel | mcuelenaere: it should |
18:36:41 | kugel | you can't have both. but you can draw something above that using foreground |
18:37:06 | kugel | and of course you cannot draw something above the foreground. there's just 2 drawing levels |
18:37:38 | Torne | yah, i'm only trying to draw black text on a white background |
18:37:46 | kugel | Torne: just do lcd_set_backdrop(NULL). The plugin loader already handles reseting the core backdrop |
18:38:37 | *** | Saving seen data "./dancer.seen" |
18:38:42 | kugel | also, a nice way to learn is always to look what other plugins do |
18:38:47 | Torne | yah, i've been looking |
18:38:54 | Torne | but it's not entirely obvious to me :) |
18:39:08 | Torne | the last time i did any graphics code was about 1989 |
18:39:44 | Torne | what does DRMODE_SOLID do? |
18:39:51 | Torne | as opposed to FG or BG |
18:40:32 | kugel | the drawmode only applies to the foreground AFAIK |
18:40:44 | Torne | yah, but i mean in general |
18:40:48 | kugel | solid means you'll simply drawing above the backdrop/background |
18:41:00 | kugel | other draw modes allow mixing the foreground with the background |
18:41:02 | Torne | so what's the difference between that and DRMODE_FG then? |
18:41:55 | kugel | I can't tell what every drawmode does, those aren't really my business :) |
18:42:00 | Torne | heh. |
18:42:02 | Torne | s'ok |
18:42:07 | Torne | i'm looking ni the code as well |
18:42:10 | kugel | amiconn or Unhelpful may know it |
18:42:52 | Torne | ohh, i see |
18:42:56 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
18:43:00 | Torne | the viewport has a background and foreground pattern |
18:43:14 | Torne | :q |
18:43:16 | Torne | oops |
18:43:24 | | Join Lear [0] (i=chatzill@rockbox/developer/lear) |
18:43:56 | Torne | ..no, i don't see |
18:45:10 | BlackCow89 | evilnick: didn't work... doesn't change anything |
18:45:53 | evilnick | BlackCow89: I'm all out of ideas then. |
18:46:04 | | Join kugel_ [0] (n=kugel@e178077089.adsl.alicedsl.de) |
18:46:22 | BlackCow89 | ok |
18:46:29 | BlackCow89 | doesn't matter |
18:46:43 | BlackCow89 | somone is going to fix it anyway at some point |
18:46:47 | BlackCow89 | :) |
18:47:51 | evilnick | BlackCow89: Hmmm, apparently you could add that define to make.conf - but unless it's really important, maybe it's safer to leave it! |
18:48:54 | BlackCow89 | I'll leave it :D |
18:49:09 | BlackCow89 | doesn't matter to me that much |
18:49:39 | kugel_ | Slasheri: ping |
18:49:45 | BlackCow89 | thx again! |
18:50:20 | evilnick | no problem! |
18:55:10 | | Quit kugel (Nick collision from services.) |
18:55:17 | | Nick kugel_ is now known as kugel (n=kugel@e178077089.adsl.alicedsl.de) |
18:55:25 | Torne | that's.. interesting |
18:55:29 | | Join JdGordon| [0] (i=836b0070@rockbox/developer/JdGordon) |
18:55:44 | Torne | lcd_fillrect doesn't do anything if you use DRMODE_BG without DRMODE_INVERSEVID |
18:56:26 | | Quit BlackCow89 ("CGI:IRC") |
18:56:35 | Torne | (with a 16-bit lcd, anyway. it seems to be different on others) |
18:56:38 | Torne | is that.. right? |
18:57:39 | Torne | looks like a bug, comparing it to other drawing functions |
18:59:19 | | Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") |
19:00 |
19:01:47 | Torne | ah, no, i just totally misunderstand how this is supposed to work ;) |
19:02:14 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
19:07:59 | pixelma | Torne: did you see the GraphicsAPI page in the wiki? |
19:08:07 | Torne | no. :) |
19:08:12 | Torne | that would probably help |
19:08:13 | Torne | thanks :) |
19:09:55 | Torne | yes, that helps a lot. |
19:12:03 | | Quit Lear (Read error: 104 (Connection reset by peer)) |
19:14:26 | funman | is there any difference between long and int on arm ? |
19:14:35 | Torne | no |
19:15:34 | funman | so i have int x = 1500000; int y = 0; (not builtin constants though), and int z = (x * 62000000)/1000000000; gives me 1 while it should give 93000 |
19:15:59 | funman | the code doesn't use gcc divide function though |
19:16:11 | funman | hm .. |
19:16:11 | Torne | you're overflowing |
19:16:17 | funman | of course |
19:16:21 | Torne | x * 62000000 is more than 2^32 |
19:16:35 | Torne | you need to rearrange the expression :) |
19:16:52 | funman | x / 1000000000 will underflow no ? |
19:16:59 | Torne | yup |
19:17:02 | Torne | you can't do either first |
19:17:08 | Torne | you need to rearrange it more creatively than that ;) |
19:17:35 | funman | but (62000000/1000000000) will underflow as well, or will gcc understand what i want ? |
19:17:48 | Torne | gcc will do that at compile time |
19:18:34 | funman | well but i would arrange inside each parenthesis without looking at what's outside (so, give 0) |
19:19:39 | funman | since 62000000 is a define i don't want to do *62/1000 |
19:19:47 | CIA-38 | New commit by mcuelenaere (r21235): Properly implement backlighting on Onda VX7x7 (using PWM). |
19:20:44 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
19:20:47 | Torne | the problem is it's all integer math |
19:20:51 | funman | another solution is using int64_t |
19:20:57 | Torne | 62000000/1000000000 == 0 |
19:21:07 | Torne | so if you write that you won't get the answer you were intending :) |
19:21:18 | Torne | you need to do the math and work out a reduced range expression for it |
19:21:33 | funman | not for x * X / 1000000000 |
19:21:35 | | Quit kushalone (Read error: 60 (Operation timed out)) |
19:22:07 | Torne | funman: it's got to do *something* first, is the point |
19:22:21 | Torne | all trivial combinations of those operands are going to immediately overflow or underflow in the first operation |
19:22:27 | | Quit perfectdrug () |
19:22:39 | Torne | for some expressions it's possible to restructure them such that they do not go out of bounds |
19:22:46 | funman | unless i use 2 registers to use an integer > 2^32 |
19:22:57 | Torne | yah, but it's nicer not to do 64-bit math if you can help it |
19:23:09 | Torne | i need to leave for now i'm afraid or i'd see if i can work it out for you |
19:23:13 | Torne | back in a while ;) |
19:23:16 | funman | thanks :) |
19:23:25 | mcuelenaere | anyone experienced with the TEA5767 around? I need to find out whether my I²C implementation actually works :) |
19:25:23 | funman | Torne: i'm just going to reduce to *62/1000 .. easiest way |
19:26:12 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
19:26:33 | | Join LambdaCalculus37 [0] (i=44a0430d@rockbox/staff/LambdaCalculus37) |
19:30:55 | | Nick at0m is now known as at0m|c (n=at0m@94-225-90-23.access.telenet.be) |
19:32:46 | domonoky | mcuelenaere: what do you need to know about tea5767 ? To test if it works, you could try to readout a register. see tea5767_dbg_info() |
19:33:23 | mcuelenaere | domonoky: I can read the register (it shows up in the debug menu), but it looks like it never changes |
19:33:45 | mcuelenaere | which makes me wonder whether this isn't just some garbage |
19:34:09 | | Quit kugel (Read error: 110 (Connection timed out)) |
19:34:11 | mcuelenaere | it reads A8 23 00 80 A0 |
19:36:51 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
19:38:27 | domonoky | hm, on my it changes contents when i have radio on. if radio isnt on, it stays at some value.. (everytime different) |
19:38:48 | | Join kugel_ [0] (n=kugel@e178092087.adsl.alicedsl.de) |
19:38:52 | | Join Llorean [0] (n=DarkkOne@adsl-99-182-52-92.dsl.hstntx.sbcglobal.net) |
19:40:39 | domonoky | so its no good indicator. but it hints to a working i2c and radio for you :-) |
19:41:01 | | Quit flydutch ("/* empty */") |
19:41:08 | mcuelenaere | hmm the schematic seems to indicate it is always powered on, but this sounds like it isn't.. |
19:42:08 | funman | hum I tried to give meaningful values to MCI_DATA_TIMER but it only makes things worse |
19:42:25 | funman | I'll see if the OF uses the card data to compute timeouts |
19:42:26 | domonoky | what is missing for you so you can hear if fm works ? |
19:47:12 | * | amiconn points kugel to http://www.rockbox.org/twiki/bin/view/Main/SoundCodecMonkeysAudio |
19:48:31 | amiconn | All swcodec targets can play -c1000, all but PP can play -c2000 and -c3000 (but coldfire struggles at -c3000). The beast handles -c4000 without problems, and *almost* handles -c5000 when clocking it at 528MHz |
19:49:36 | | Join rw [0] (n=wark@fctnnbsc15w-142166069060.pppoe-dynamic.nb.aliant.net) |
19:49:36 | amiconn | PP could handle -c2000 by going dual core for APE - that's one of my ideas to work on for the hacking weekend (aka devcon) |
19:50:36 | | Join solexx [0] (n=jrschulz@e176111072.adsl.alicedsl.de) |
19:51:05 | * | funman would like to see sansa ams benchmarks |
19:51:24 | * | LambdaCalculus37 too |
19:51:28 | mcuelenaere | domonoky: I *think* I can hear FM, as I can hear the same audio garbage when turning line in on and pressing the touch screen :/ But I can't tune to any channel :) |
19:51:35 | amiconn | funman: You could do some... |
19:51:52 | LambdaCalculus37 | amiconn: How well does -c5000 APE perform on the beast when clocked at 528MHz? |
19:51:55 | | Join _lifeless [0] (n=lifeless@188.16.119.220) |
19:52:22 | amiconn | It's 105% realtime in test_codec. It mostly plays, but skips occasionally in wps |
19:52:44 | LambdaCalculus37 | amiconn: How about when also scaling a huge JPEG album art? ;) |
19:53:03 | * | amiconn still didn't try jpeg album art on any target |
19:53:45 | amiconn | Also, for me it won't scale album art in parallel, as I don't use WPS'es with aa |
19:53:52 | funman | amiconn: is there any ape encoder for linux? |
19:54:03 | amiconn | I have no idea |
19:54:18 | funman | could you provide me with samples for each level? |
19:54:35 | LambdaCalculus37 | funman: There's this: http://jmac.sourceforge.net/ |
19:55:04 | funman | java :( |
19:55:19 | LambdaCalculus37 | Sorry, dude. :( |
19:55:45 | | Quit kugel (Read error: 110 (Connection timed out)) |
19:57:03 | | Join kugel__ [0] (n=kugel@e178075103.adsl.alicedsl.de) |
19:58:11 | funman | there is some source at http://aniki.free.fr/puits/xmms_plugin/mac-3.99-u4-b5.tar.gz |
19:59:42 | | Part kugel__ ("return(0);") |
20:00 |
20:02:40 | | Quit PaulJam (Nick collision from services.) |
20:02:41 | | Join PaulJam_ [0] (i=Paule@vpn-3039.gwdg.de) |
20:02:45 | | Nick PaulJam_ is now known as PaulJam (i=Paule@vpn-3039.gwdg.de) |
20:02:58 | | Quit wark (Read error: 110 (Connection timed out)) |
20:04:00 | | Quit chandoo ("Leaving") |
20:05:45 | | Quit kugel_ (Read error: 110 (Connection timed out)) |
20:06:57 | | Quit solexx_ (Read error: 110 (Connection timed out)) |
20:07:23 | | Quit __lifeless (Read error: 113 (No route to host)) |
20:08:36 | bertrik | funman, do you still see problems on the fuze? |
20:09:34 | bertrik | if so, do you think there is a relation to my change to using A7 in the fuze display driver? |
20:09:51 | | Quit funman (Read error: 60 (Operation timed out)) |
20:10:38 | | Quit rw (Read error: 110 (Connection timed out)) |
20:10:55 | | Join funman [0] (n=fun@rockbox/developer/funman) |
20:11:21 | | Join rw [0] (n=wark@fctnnbsc15w-142166071215.pppoe-dynamic.nb.aliant.net) |
20:11:50 | | Quit rw (Client Quit) |
20:15:40 | funman | tested on Clip with a 4seconds file : c1000 668% realtime, c2000 446%, c3k 275%, c4k 97%, c5k 9% |
20:15:56 | | Quit barrywardell (Remote closed the connection) |
20:16:17 | funman | pretty much like gigabeatf, but i don't know if further optimisations have been made since r19250 |
20:19:37 | | Join froggyman [0] (n=Froggyma@pool-71-186-6-182.chi01.dsl-w.verizon.net) |
20:23:10 | FlynDice | FS #10308 offers a workaround for e200v2 radio if anyone is interested, but I'm not here... |
20:24:40 | | Join kachna [0] (n=kachna@r4ax178.net.upc.cz) |
20:24:53 | funman | FlynDice: i'm not sure if it's really wanted .. |
20:25:14 | funman | i find clock-target.h already big and tweakable enough |
20:26:39 | | Quit bubsy ("Mrrrrreow!") |
20:29:48 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
20:35:16 | kugel | funman: nice messurements |
20:36:04 | kugel | but the clip has a little pcm buff compared to the highmems, hence I'm asking if we can make them the same (i.e. shrink the high mem's one) |
20:36:14 | funman | kugel: yep ^^ i'd like to see if gigabeatf decoding speed changed to compare with the 300MHz CPU |
20:36:49 | funman | kugel: i don't know |
20:38:28 | funman | i didn't look if pcmbuf approached 0 when decoding -c3000 |
20:38:40 | *** | Saving seen data "./dancer.seen" |
20:38:48 | funman | do you expect a gain in battery life due to more audio buffer? |
20:38:57 | kugel | sure |
20:39:09 | kugel | the pcm buff is mostly wasted right now as it seems to me |
20:39:24 | kugel | especially since the watermark is quite high (see pcmbuf.c) |
20:40:11 | | Quit ender (" Do not believe any statistic you didn't falsify yourself.") |
20:40:21 | | Join kugel_ [0] (n=kugel@e178099147.adsl.alicedsl.de) |
20:40:33 | | Quit kugel (Nick collision from services.) |
20:40:37 | | Nick kugel_ is now known as kugel (n=kugel@e178099147.adsl.alicedsl.de) |
20:41:11 | funman | kugel: i don't see any problem with it, but then i don't know if some codecs require excessively more processing for certain frames |
20:41:43 | kugel | have you seen MrSomeonesTodoList? |
20:42:13 | kugel | 1 point is to optimize pcmbuf for the targets, as most targets aren't sizing it really good |
20:43:37 | funman | sansa clip OF seems to ignore NSAC from the SD CSD (it's set to 0 anyway), but i don't know how fuze/e200v2 handle µSD's NSAC |
20:44:00 | | Quit kugel (Nick collision from services.) |
20:44:06 | | Join kugel [0] (n=kugel@e178119248.adsl.alicedsl.de) |
20:48:07 | kugel | FlynDice: will you be doing tests at 248/62 and 31/31? |
20:50:17 | funman | well i'm not sure how it is handled actually .. |
20:51:38 | kugel | funman: I was trying to get push or pop errors for the blue bars |
20:51:52 | kugel | there were no errors, the isr wasn't executed |
20:51:55 | funman | seems that it starts setting a timeout at 1/16 second, but then it's modified in several places, including the isr |
20:52:05 | funman | kugel: i didn't try your patch yet :/ |
20:52:54 | * | bertrik is confused by the fuze OF |
20:53:41 | bertrik | in the display initialisation code it really does set pin A7 (also used by fm radio) and it does stuff with A3 (used for USB detect) |
20:54:02 | funman | bertrik: send a patch to SanDisk :) |
20:54:22 | bertrik | yeah, sometimes I wonder if some things are bugs too! |
20:54:23 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
20:57:52 | funman | well OF completely ignore data access times and used its own timeout |
20:57:57 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
21:00 |
21:01:02 | | Join raquatrac [0] (n=raquatra@ANice-152-1-71-70.w86-194.abo.wanadoo.fr) |
21:04:58 | | Quit ze (Remote closed the connection) |
21:05:38 | | Join pyro_maniac [0] (n=pyro@91-64-227-210-dynip.superkabel.de) |
21:05:39 | kugel | bertrik: your patch gives me blue lines too :( |
21:06:38 | bertrik | hm, pity |
21:07:13 | bertrik | I think funman determined that DBOP ran at 31 MHz in the OF, so we may be overclocking it now |
21:07:16 | kugel | mcuelenaere: why did you choose BACKLIGHT_FADING_SW_HW_REG? |
21:07:22 | kugel | we are not |
21:07:30 | mcuelenaere | kugel: I'm not sure what else to pick? |
21:07:31 | bertrik | unfortunately we cannot easily scale it |
21:07:32 | kugel | I get blue lines with 31MHz too |
21:07:37 | kugel | sure we can |
21:08:22 | raquatrac | Hi, submitting a translation on the page http://rasher.dk/rockbox/translate/ produces a diff file. Where can I find guidelines to do something useful with it? |
21:08:31 | kugel | mcuelenaere: well, isn't your fading entirely done in onda_vx747/backlight-onda_vx7X7.c without incorparating the backlight thread? |
21:09:04 | funman | FS #10309 - Sansa AMS : correctly sets timeout for data access => my Fuze works better with this, now let's see if other people are seeing problems with disk access |
21:09:32 | kugel | mcuelenaere: BACKLIGHT_FADING_TARGET is approiate for that |
21:09:51 | mcuelenaere | kugel: what do you mean 'without incorporating the backlight thread'? |
21:10:03 | mcuelenaere | I thought the backlight thread calls the target-specific functions and that's it? |
21:10:11 | bertrik | kugel, we can scale down by a factor of two AFAIK, and more accurate for even lower frequencites |
21:10:15 | kugel | mcuelenaere: not exactly |
21:10:16 | mcuelenaere | what do you mean with* |
21:10:39 | kugel | fading isn't target specific in the backlight thread |
21:11:10 | kugel | bertrik: yes, and 62/2 is 31 |
21:11:31 | kugel | unsurprisingly it gives 50fps max, but still with blue bars |
21:11:50 | kugel | I don't quite understand what you mean with overclocking. the dbop is specified for upto 65MHz |
21:11:52 | | Quit KBH ("ZNC") |
21:11:54 | funman | bertrik: OF runs dbop at 32MHz (pclk is 64MHz) |
21:12:06 | mcuelenaere | kugel: you mean fading is target-independant in the backlight thread? that's what I expected it to be |
21:12:06 | | Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
21:12:20 | kugel | yes |
21:12:21 | funman | kugel: i think bertrik meant overflow with respect to the values of DBOP_TIMPOL_* registers |
21:12:42 | bertrik | I mean that if the OF runs it at 32 MHz and we run it at 62 MHz, it could be too fast for the display |
21:13:01 | kugel | mcuelenaere: you're doing your own fading in after _backlight_off() |
21:14:03 | mcuelenaere | kugel: you mean I'm supposed to do my own fading or .. ? (because I'm currently not) |
21:14:03 | kugel | that's what the beast is doing too, for that type we have BACKLIGHT_FADING_TARGET |
21:14:18 | kugel | no you aren't, but it looks like it does |
21:14:45 | mcuelenaere | set_backlight_off() just does what it function is named after: turning the backlight off :) |
21:14:46 | | Quit PaulJam (Nick collision from services.) |
21:14:47 | | Join PaulJam_ [0] (i=Paule@vpn-3011.gwdg.de) |
21:14:52 | | Nick PaulJam_ is now known as PaulJam (i=Paule@vpn-3011.gwdg.de) |
21:15:05 | mcuelenaere | all this driver does is, turning the backlight on/off and setting it to a specific brightness level |
21:15:13 | kugel | ah ok then |
21:15:23 | kugel | there's so much PWM in it |
21:15:31 | mcuelenaere | I know :/ |
21:15:41 | * | mcuelenaere had a lot of trouble with that |
21:15:52 | kugel | SW fading is done through setting the brightness in small intervalls though, not exactly what I call PWM fading :) |
21:16:03 | mcuelenaere | I initially tried using BACKLIGHT_FADING_PWM, but amiconn told me that was for software PWM |
21:16:26 | mcuelenaere | (or software emulated PWM) |
21:16:44 | mcuelenaere | this is implemented as 'hardware PWM' i.e. a timer running as a PWM |
21:17:22 | * | kugel is confused |
21:17:49 | kugel | but there's still no fading in your driver? |
21:18:36 | CIA-38 | New commit by mcuelenaere (r21236): Correct some comments (no functional changes) |
21:18:58 | mcuelenaere | kugel: nope, I'm counting on the backlight thread for that |
21:19:06 | kugel | ok then |
21:19:06 | mcuelenaere | (or backlight driver) |
21:19:15 | kugel | I just was confused then :) |
21:19:28 | bertrik | kugel, the blue bars occur only when using the FIFO? |
21:19:31 | kugel | does it work nicely? |
21:19:42 | bertrik | could we be overfilling it maybe |
21:19:48 | kugel | bertrik: I don't understand? |
21:19:56 | mcuelenaere | kugel: was that directed to me? |
21:19:56 | kugel | I don't think it's overfilling |
21:20:05 | kugel | I also tried stopping at almost full |
21:20:17 | kugel | mcuelenaere: "does it work nicely?" this yes |
21:20:29 | bertrik | yeah, overfilling would cause left/right shifts I think and we're not seeing that |
21:20:43 | mcuelenaere | kugel: sort of, it's a bit jerky but it's much better than the OF |
21:21:22 | mcuelenaere | I think I saw Rockbox's iPod Video's backlight fading once and remembered it much more smoothly then this |
21:21:47 | kugel | well, I certainly didn't have targets with 200 brightness levels in my mind when doing the SW fading :) |
21:21:53 | * | mcuelenaere thinks it should be done in much smaller increments |
21:22:16 | mcuelenaere | yeah, clearly :) When I tried using 300 brightness levels, the fading was very slow :) |
21:23:19 | kugel | are the 200 levels so noticeably different? They might reduced. You can also try reducing the fade step delay (backlight-sw-fading.h) |
21:23:24 | amiconn | On ipod video rockbox uses software pwm fading, which has 100 levels |
21:23:40 | mcuelenaere | The beauty of using hardware PWM is that I can virtually construct every level of brightness possible |
21:23:45 | kugel | it *much* smaller steps too |
21:24:08 | kugel | I'm not entirely sure why you can't use PWM fading then |
21:24:12 | amiconn | Software pwm employs the user timer, and switches backlight via gpio in the isr |
21:24:33 | mcuelenaere | amiconn: does the backlight setting offer 100 brightness choices to the user? |
21:24:49 | amiconn | No, since software pwm runs during fade *only* |
21:25:06 | mcuelenaere | kugel: because that's intended for software PWM? I haven't looked into adapting it to my situation though |
21:25:10 | amiconn | The 100 steps are between whatever brightness level the user has set, and zero |
21:25:17 | mcuelenaere | ah ok |
21:25:41 | amiconn | Running software pwm permanently would be quite a waste |
21:25:46 | | Quit rvvs89 (Remote closed the connection) |
21:25:50 | mcuelenaere | amiconn: then how does the brightness get set? (if software pwm only runs during fading) |
21:25:51 | | Join rvvs89 [0] (n=ivo@robotnik.ucc.gu.uwa.edu.au) |
21:25:53 | bertrik | funman, could it be that the CSD of the AMS Sansa's can't really be trusted at all? |
21:26:06 | amiconn | (especially on coldfire since it requires to stay boosted while doing the pwm fade) |
21:26:20 | bertrik | I remember seeing incorrect sizes in the CSDs |
21:26:36 | amiconn | mcuelenaere: The ipod video and nano are the only targets having both software pwm fading and hardware brightness control |
21:26:45 | mcuelenaere | ahh ok |
21:26:55 | amiconn | The hardware brightness circuit (probably also using pwm) has 32 levels |
21:26:57 | funman | bertrik: it wouldn't bother me, but it also seems to ignore NSAC & TAAC from µSD CSD |
21:27:18 | | Join BryanJacobs [0] (n=braujac@dhcp-urwireless-128-151-180-73.wireless.rochester.edu) |
21:27:28 | kugel | mcuelenaere: you basically need to provide a "_backlight_[on|off)_isr()" |
21:27:36 | bertrik | funman, does the OF use anything from the csd? |
21:27:42 | amiconn | The two PWMs don't interfere because the software pwm runs at a way lower frequency (200Hz) than the hardware pwm (probably running at >20kHz) |
21:27:46 | mcuelenaere | kugel: yes, but none of my code gets run as an ISR |
21:28:14 | funman | bertrik: not much, at least the number of blocks |
21:28:16 | kugel | your code isn't the actual ISR |
21:28:25 | mcuelenaere | amiconn: is the backlight still visible at 20kHz? |
21:28:39 | kugel | on the ipod the *_isr just sets a GPIO |
21:28:42 | funman | there is a function which extracts all fields from the CSD, and then only 2 fields are used |
21:29:14 | amiconn | Hmm? |
21:29:22 | Mikachu | if you shake the ipod quickly while it's fading (only recommended for nano ;), you can usually move it a whole screen's width in the time the software pwm switches on and off once |
21:29:46 | kugel | mcuelenaere: the actual ISR is backlight_isr() in backlight.c, that calls the target specific brightness setting function |
21:30:10 | mcuelenaere | amiconn: I read that the backlight isn't visible anymore to the human eye at >1kHz |
21:30:15 | amiconn | You can do that with a video as well, as long as it's not buffering (or cf modded) |
21:30:37 | Mikachu | sure, i just don't want to recommend it :) |
21:30:48 | * | amiconn wonders where mcuelenaere read that |
21:31:08 | Mikachu | eyes have super low refresh rate |
21:31:14 | Mikachu | or rather, they're super motion blurred |
21:31:31 | mcuelenaere | amiconn: http://www.pacificdisplay.com/lcd_backlights.htm (search for 'The pulse repetition frequency..' |
21:33:18 | amiconn | "The pulse repetition frequency should be greater than 100Hz so the flickering is |
21:33:18 | amiconn | not perceptible to the eye but not greater than about 1kHz. |
21:33:41 | amiconn | It can very well be higher without any problems... |
21:33:51 | funman | bertrik: I modified the bootloader for fs#10285 - can the very frequent button reading draw more current from the battery ? |
21:33:59 | kugel | funman: good that you mixed changes again, I can't figure out what you did in that patch |
21:34:03 | Mikachu | maybe airplanes will start crashing into your house above that freq :) |
21:34:06 | amiconn | It's just that *really* high frequencies would increase losses due to switching |
21:34:22 | | Join ze [0] (i=ze@76.91.72.105) |
21:34:26 | mcuelenaere | kugel: hmm isn't that for software PWM? (I don't need to switch the backlight on/off manually, the hardware timer does that) |
21:34:31 | funman | kugel: i experimented with something needing these changes, but then went for a simpler solution |
21:35:15 | kugel | mcuelenaere: yes (I was trying to tell you how you could use the software PWM, since that seems more appropriate for your target) |
21:35:45 | mcuelenaere | kugel: it looks a bit unnecessary (and waste) to use software PWM when you have a hardware PWM available.. |
21:35:50 | bertrik | funman, I don't know, maybe. The button read function takes only a small amount of cycles (and no more burned cycles) |
21:35:53 | | Join tessarakt [0] (n=jens@e180075178.adsl.alicedsl.de) |
21:36:05 | mcuelenaere | it looks ... to me* |
21:36:10 | kugel | mcuelenaere: what you do isn't hardware PWM either |
21:36:28 | mcuelenaere | kugel: how do you mean? |
21:36:50 | kugel | I mean, the software still emulates the fading. Hardware fading would be to have it done all by the hardware |
21:37:02 | amiconn | It *is* hardware pwm |
21:37:34 | funman | bertrik: i mean it could use more current by reading from GPIO more often, not by more cycles |
21:37:37 | mcuelenaere | kugel: the software still emulates the fading, yes. But the hardware does the actual turning on/off of the backlight, so it is hardware PWM |
21:37:44 | amiconn | The software just controls the brightness setting (== pwm duty cycle) |
21:38:15 | kugel | I know...I was a bit unclear |
21:38:51 | bertrik | funman, I think it won't draw more current, but I can't really prove it |
21:39:26 | bertrik | the buttons are probably read out very often anyway |
21:40:01 | funman | kugel: i updated the patch (8 lines changed in 1 file this time) |
21:40:22 | funman | bertrik: you can prove it with 2 battery benches :) |
21:40:27 | kugel | mcuelenaere: you can try changing FADE_DELAY to make it more smooth, so that the backlight thread would run each tick |
21:41:03 | mcuelenaere | kugel: that's one possibility, but offering the user 300 backlight brightness options seems a bit overkill to me :) |
21:41:21 | kugel | that too |
21:41:40 | kugel | alternatively you can run your own tick task in your backlight driver, choosing the fading steps dynamically |
21:42:10 | kugel | like, always 50 no matter of the actual backlight brightness |
21:42:12 | * | amiconn still prefers the sw pwm way of fading, where the user selects fade-in and fade-out times |
21:42:36 | * | mcuelenaere prefers fade-in & fade-out times too |
21:42:51 | * | kugel finds them overkill and prevers sane defaults |
21:42:57 | kugel | but we had this discussion already |
21:43:06 | kugel | prefers* |
21:43:09 | amiconn | The sw pwm is called twice per 5ms cycle. At each cycle it checks whether the duty cycle needs changing. |
21:43:15 | mcuelenaere | wow, having 300 brightness levels really smoothens fading :) |
21:43:42 | kugel | you only have 200? |
21:44:15 | amiconn | The shortest possible fade using all 100 levels is therefore 500ms, but shorther fades are possible by skipping levels. |
21:44:16 | kugel | from 100-300 (reading config-ondavx747.h |
21:44:31 | amiconn | Calculation is done by a bresenham-like algorithm |
21:45:20 | mcuelenaere | kugel: 300-1 so 299 actually |
21:45:45 | mcuelenaere | kugel: did you svn up? ;) |
21:46:03 | funman | bertrik: i'll receive a c200v2 within ~2 weeks, i hope i can make lcd work |
21:46:05 | kugel | oh |
21:46:13 | kugel | I didn'T see that change before |
21:46:19 | bertrik | funman, what would be a good test? just letting it idle in the menu with auto-poweroff disabled? |
21:46:24 | bertrik | funman, oh nice! |
21:47:02 | funman | bertrik: i think it doesn't matter as long as you do the same thing in both runs |
21:47:06 | bertrik | funman, I have hope we can reuse much of the current c200v1 driver |
21:47:50 | funman | bertrik: oh by the way button_read_device() is called every tick |
21:48:15 | * | mcuelenaere will probably either tweak the existing driver a bit or implement the do-your-own fading |
21:48:18 | funman | so your patch could actually draw less power (3 times less GPIO readings) |
21:48:32 | kugel | mcuelenaere: but you could also setup a timer interrupt changing the brightness more quickly than each tick |
21:48:38 | funman | bertrik: but then, you could actually handle row switching in button_read_device() .. |
21:48:39 | kugel | so many possibilities :) |
21:48:52 | mcuelenaere | kugel: that's CPU waste again.. |
21:49:04 | bertrik | funman, hm yes, we wouldn't need the kernel tick_task |
21:49:35 | mcuelenaere | kugel: I would just prefer setting the hardware PWM with different settings then doing sw emulated PWM fading |
21:49:36 | funman | kugel: do you still need fuze parts ? |
21:49:37 | kugel | does reading GPIO really cost power? |
21:49:54 | kugel | funman: I need a LCD :) |
21:49:58 | saratoga | probably not |
21:49:58 | kugel | and a mainboard ... |
21:50:08 | kugel | no, I think the other fuze isn't recoverable |
21:50:34 | funman | kugel: contact ej0rge on the forums, he bought several broken fuzes |
21:50:41 | funman | ah ok |
21:50:54 | kugel | mcuelenaere: you can't do that with SW fading. But you can still have your own tick task for that |
21:51:23 | kugel | IIRC there's already 1 or 2 target that use a tick task for backlight |
21:51:24 | mcuelenaere | kugel: do what? |
21:51:40 | bertrik | funman, indeed button_read_device is called from the button_tick task, I'll see if I can simplify the patch |
21:53:00 | | Quit togetic (Read error: 104 (Connection reset by peer)) |
21:53:36 | kugel | bertrik: how do you think it was read if not in a tick task? |
21:54:49 | kugel | mcuelenaere: setup a tick task, do the software fading there, but choose fading steps yourself (isn't that what your wanted?) |
21:55:03 | bertrik | I didn't think about that |
21:55:54 | mcuelenaere | kugel: hmm yes, but I would use a timer if possible |
21:56:08 | * | mcuelenaere is going to stick to how it's now atm |
21:56:44 | kugel | hehe |
21:57:17 | kugel | funman: noticed my buttonlight patch? |
21:57:46 | bertrik | the bootloader calls button_read_device directly to determine if text should be shown during boot, but with my patch it can take three ticks before it returns the actual button status |
21:57:58 | funman | kugel: nope >_< |
21:58:15 | kugel | I'm just posting it in the forum |
21:59:26 | | Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") |
22:00 |
22:00:28 | * | kugel thinks we don't even need all buttons in the bootloader |
22:00:50 | kugel | 1 or 2 are sufficient, so reading only 1 row would be accaptable imo |
22:01:28 | kugel | JdGordon|: Have you seen my fix for FS #10101 |
22:01:30 | kugel | ? |
22:05:09 | | Join Ubuntuxer [0] (n=johannes@dslb-094-221-095-176.pools.arcor-ip.net) |
22:05:29 | JdGordon| | kugel: no? |
22:05:57 | kugel | it's on the tracker |
22:06:37 | JdGordon| | remind me this arvo... |
22:06:56 | * | JdGordon| didnt see the email update for that task, except the one without an attachment |
22:10:58 | funman | kugel: i think removing lines instead of commenting is better to read in fs#10306 |
22:11:17 | | Quit Lss (Read error: 110 (Connection timed out)) |
22:12:49 | | Part raquatrac |
22:16:45 | | Join _Auron_ [0] (n=DarkAuro@99.48.97.163) |
22:17:54 | funman | kugel: seems to work fine here, thanks :) |
22:18:33 | kugel | funman: oh, I uploaded the wrong patch it seems |
22:19:04 | kugel | I mean, no difference except the commenting out |
22:21:18 | kugel | patch updated |
22:27:21 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
22:34:35 | | Quit kugel (Remote closed the connection) |
22:35:01 | | Join chandoo [0] (n=chandoo@ool-4353b978.dyn.optonline.net) |
22:36:28 | | Join mirak [0] (n=mirak@85-169-201-135.rev.numericable.fr) |
22:38:44 | *** | Saving seen data "./dancer.seen" |
22:39:30 | | Join kugel [0] (i=kugel@rockbox/developer/kugel) |
22:40:51 | | Quit mirak (Client Quit) |
22:42:33 | evilnick | gevaerts: I mentioned a while ago that the HID aspect of RockboxUSB |
22:43:14 | evilnick | 's USB stack caused my windows PC to "see" the SD card and the main memory as two separate devices (in the Safely Remove Hardware system tray icon)... |
22:43:31 | gevaerts | ah, yes |
22:43:34 | evilnick | Well that can be safely ignored as it's working as normal on my work PC |
22:43:41 | evilnick | Nothing to see here |
22:43:42 | gevaerts | good :) |
22:44:59 | | Quit bertrik (Remote closed the connection) |
22:46:28 | | Part BryanJacobs ("Leaving.") |
22:47:01 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
22:49:54 | | Quit pyro_maniac ("Leaving.") |
22:50:35 | * | bertrik fails to see the relation between DBOP frequency and fm radio working or not on ams sansas |
22:52:59 | bertrik | some ams sansas at least. It seems I can't break fm radio on my clip. |
22:55:51 | | Quit chandoo ("Leaving") |
22:57:33 | | Join |mr [0] (n=lymeca@amherst597.amherstma.gov) |
23:00 |
23:00:52 | stripwax | saratoga - shame :) (re irc last night). i'll see if it does anything to profiling anyway. I have a question on libwma makefile −− what is preprocess and c2obj ? |
23:01:50 | | Quit kugel ("exit(0);") |
23:02:03 | | Join kugel [0] (i=kugel@rockbox/developer/kugel) |
23:02:11 | | Quit kugel (Read error: 104 (Connection reset by peer)) |
23:02:15 | | Join kugel [0] (i=kugel@rockbox/developer/kugel) |
23:02:19 | funman | stripwax: look in tools/functions.make |
23:02:48 | * | pixelma wonders about the Clip's red in the last build round |
23:03:30 | funman | perhaps mcuelenaere didn't test his onda modifications on the clip, or the build server has some problem |
23:03:46 | Mikachu | the commit was just a comment change |
23:03:56 | funman | must be the 2nd option then ^^ |
23:04:07 | Mikachu | undefined reference to setjmp in vorbis.o, seems like an odd thing to happen |
23:04:54 | Bagder | yes, especially when the change was in an onda-related file only |
23:06:45 | | Quit kugel (Client Quit) |
23:06:53 | | Join kugel [0] (i=kugel@rockbox/developer/kugel) |
23:07:29 | Bagder | i can't find any obvious clues on the server either |
23:13:09 | | Quit anigav (Read error: 60 (Operation timed out)) |
23:13:28 | stripwax | funman - hm, do you know why libwma uses that, but libtremor also has the other stuff explicitly to compile $(ROOTDIR)/apps/codecs/libtremor/%.c ? |
23:14:22 | funman | stripwax: no idea, have a look at svn blame output (if revision logs mention something) |
23:15:28 | stripwax | funman - actually I'm trying to work out how libwma gets built at all (I find the libwma.make file confusing due to its emptiness) |
23:16:12 | stripwax | I guess some of the other codecs are similar. hm, I'm sure I'll figure i tout |
23:17:35 | | Join kugel_ [0] (i=kugel@e178081033.adsl.alicedsl.de) |
23:17:39 | | Quit kugel_ (Read error: 104 (Connection reset by peer)) |
23:17:49 | | Join kugel__ [0] (i=kugel@e178081033.adsl.alicedsl.de) |
23:18:25 | | Quit kugel__ (Client Quit) |
23:18:31 | | Join kugel__ [0] (i=kugel@e178081033.adsl.alicedsl.de) |
23:19:16 | funman | stripwax: there is also apps/codecs/codecs.make |
23:20:17 | stripwax | yeah, I guess the default rule in there applies if nothing in the codec-specific makefile. makes sense! |
23:21:25 | | Quit Ubuntuxer ("Leaving.") |
23:21:43 | stripwax | although libtremor.make is still pretty confusing - is the second definition of $(CODECDIR)/libtremor/%.o ignored in preference to the first? |
23:22:03 | | Quit kugel__ (Client Quit) |
23:22:10 | | Join kugel__ [0] (i=kugel@e178081033.adsl.alicedsl.de) |
23:26:04 | | Part kugel__ ("return(0);") |
23:33:28 | | Quit TheSphinX^ ("XChat@Linux") |
23:33:39 | JdGordon| | so.... did anyone come to a descision about disabling the debug menu in the release builds? |
23:34:52 | Llorean | I'm still in favour of disabling it. |
23:35:13 | * | amiconn isn't |
23:35:19 | * | gevaerts is undecided |
23:35:19 | Llorean | amiconn: Why not? |
23:35:20 | funman | people wanting to give information could easily update to a daily build, so i'm in favour as well |
23:35:29 | Llorean | funman: People should never use daily builds. |
23:35:30 | | Quit kugel (Read error: 110 (Connection timed out)) |
23:35:34 | Mikachu | you could have a hidden option in the cfg? |
23:35:37 | Llorean | Unless there's something wrong with the current build. |
23:35:47 | gevaerts | It has some information that should actually be in the main system menu |
23:35:49 | * | bertrik has no opinion on this |
23:35:52 | funman | Llorean: that's one reason for wanting to enter the debug menu (something wrong) |
23:35:56 | Llorean | gevaerts: That should be resolved. |
23:35:57 | amiconn | Llorean: Screendump and archos flashing (needs tom dump) |
23:36:07 | amiconn | typo++ :( |
23:36:08 | JdGordon| | amiconn: this might swing you.... removing the menu should give a nice delta for release builds... |
23:36:18 | gevaerts | :) |
23:36:24 | Llorean | funman: Yes, but if it's still wrong with the current build, the current build will have a debug menu |
23:36:42 | Llorean | amiconn: If things are needed for normal use, they shouldn't be in the debug menu |
23:36:45 | | Join kugel [0] (i=kugel@rockbox/developer/kugel) |
23:37:25 | Mikachu | Llorean: i think when funman said daily build he meant current build, as opposed to a release version build (or maybe i missed something) |
23:37:30 | n1s | Maybe we should move some of the info in the debug menu to the system info or something |
23:37:40 | Llorean | Mikachu: Well, they're very different things. |
23:38:03 | Mikachu | isn't the daily build just the last 'current' build of the day? |
23:38:20 | Llorean | Yes, exactly. So when we ask people to try on the latest build, we want them on the *current* not the daily |
23:38:39 | Llorean | Which means there needs to be clear separation between the two. That's also why daily builds aren't linked in the left menu bar. |
23:38:45 | Mikachu | okay |
23:38:46 | funman | Llorean: ah sorry i meant current build |
23:38:51 | JdGordon| | we really should stop doing dailies then... |
23:38:52 | gevaerts | Mikachu: no. They get built separately |
23:39:11 | amiconn | ROM dump should imho be part of firmware_flash, with ROM contents detection (offering backup only if it finds the original archos content) |
23:39:12 | Llorean | JdGordon|: They're useful as archived builds for people to roll back to, or for us to use to quickly track down what day a bad change happened on without having to roll builds. |
23:39:12 | | Quit kugel (Read error: 104 (Connection reset by peer)) |
23:39:41 | n1s | JdGordon: yeah, we could just as easily archive the first build for each day or something |
23:39:47 | obo | are dailies still the only builds available with .map files? |
23:39:51 | | Join safetydan [0] (n=deverton@rockbox/developer/safetydan) |
23:39:55 | gevaerts | maybe we should discuss this at devcon. See what needs to be put in a proper place so you don't need the debug menu for anything but debugging |
23:40:21 | * | Llorean thinks the debug menu should stay available in every build except the Release builds, and that as soon as feasible it should be removed from future release builds. |
23:40:24 | Bagder | obo: yes, we don't collect them for the commit builds |
23:40:35 | JdGordon| | n1s: yeah, and have the links more hidden from users |
23:41:22 | n1s | JdGordon: well, just call them archived builds like i think we do now, not terribly confusing |
23:41:27 | * | JdGordon| wonders if someone can get Zagor to have a look at the makfile changes in 10278? |
23:46:10 | CIA-38 | New commit by bluebrother (r21237): Make labels in generated TTS / Encoder setting dialogs translatable. ... |
23:48:18 | JdGordon| | why are all the HID options in the top level debug menu? |
23:48:23 | JdGordon| | ... or there at all? |
23:49:36 | CIA-38 | New commit by bluebrother (r21238): Set svn:eol-style on several files missing it and dos2unix them. |
23:50:09 | Llorean | JdGordon|: They aren't really "options" |
23:50:35 | JdGordon| | sure, but no need to add more clutter there... they could have gone in a seperate "HID debug" menu |
23:50:42 | Llorean | Yeah, this is true. |
23:51:37 | JdGordon| | and screenshot should be moved out... the rest is mostly useless for users other than a nice curiosity thing |
23:51:40 | gevaerts | actually, they can probably just go |
23:51:50 | | Quit |mr (Read error: 110 (Connection timed out)) |
23:51:53 | Llorean | gevaerts: I take it they were there during an earlier stage of testing? |
23:51:59 | gevaerts | yes |
23:58:05 | | Quit bmbl ("Woah!") |
23:58:21 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |