| 00:01:57 | | Join herrwaldo [0] (n=waldo@ip-81-11-202-191.dsl.scarlet.be) |
| 00:02:18 | | Quit Nibbler (Read error: 148 (No route to host)) |
| 00:02:28 | | Join t0mas [0] (n=tomas@rockbox/developer/t0mas) |
| 00:03:08 | | Join jhulst_ [0] (n=jhulst@unaffiliated/jhulst) |
| 00:04:16 | | Quit jhulst (Read error: 60 (Operation timed out)) |
| 00:06:08 | | Quit ender` (" It's bad luck to be superstititious. -- Law of Superstition") |
| 00:07:42 | | Nick jhulst_ is now known as jhulst (n=jhulst@unaffiliated/jhulst) |
| 00:13:22 | | Join Nibbler [0] (n=Nibbler@e181121173.adsl.alicedsl.de) |
| 00:13:59 | | Quit bertrik (Remote closed the connection) |
| 00:17:56 | | Join tvelocity [0] (n=tony@adsl18-206.her.forthnet.gr) |
| 00:18:01 | | Quit Nibbler (Client Quit) |
| 00:18:08 | | Quit jhulst (Remote closed the connection) |
| 00:18:15 | | Quit t0mas ("Leaving") |
| 00:20:38 | | Join BigBambi [0] (n=alex@72.198.66-86.rev.gaoland.net) |
| 00:20:58 | | Quit BigBambi (Remote closed the connection) |
| 00:21:13 | | Join BigBambi [0] (n=Alex@rockbox/staff/BigBambi) |
| 00:21:21 | | Quit BigBambi__ ("Leaving") |
| 00:22:49 | | Quit domonoky (Read error: 54 (Connection reset by peer)) |
| 00:24:48 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 00:24:48 | | Quit bluebrother ("leaving") |
| 00:25:13 | | Quit lasser ("ChatZilla 0.9.84 [Iceweasel 3.0.4/2008112309]") |
| 00:26:27 | hobbs | For the tracks on just one album that I have, %in is displaying "5/17" etc. instead of just a single number. 1) what tag is it pulling that info from, and 2) is there any way I can make it not happen? |
| 00:27:14 | krazykit | hobbs, change that tag on your file |
| 00:27:26 | hobbs | like I just asked, what tag? |
| 00:27:29 | hobbs | the track tag is set to 5. |
| 00:27:32 | hobbs | (or whatever) |
| 00:27:33 | | Join |mr [0] (n=lymeca@dsl-74-220-76-75.cruzio.com) |
| 00:28:21 | Hillshum | the id3 tag |
| 00:28:49 | | Join n1s [0] (n=nils@rockbox/developer/n1s) |
| 00:29:01 | hobbs | please tell me you're just _pretending_ to be clueless. |
| 00:29:23 | krazykit | hobbs, what file type? you may have two different tag types on the file (that is, both id3 and ape, or something like that) |
| 00:29:45 | hobbs | krazykit: MP3; ID3v2 is the only tag I'm aware of. |
| 00:30:58 | hobbs | but now that I look at it, the tags are responsible, it's just that the "id3v2" util was hiding the info from me |
| 00:31:17 | | Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) |
| 00:31:35 | | Quit massiveH (Client Quit) |
| 00:35:18 | | Quit Aurix_Lexico (Remote closed the connection) |
| 00:36:28 | | Join Aurix_Lexico [0] (n=comrade@c-68-56-205-239.hsd1.fl.comcast.net) |
| 00:37:22 | | Join mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere) |
| 00:37:39 | mcuelenaere | Aurix_Lexico: the PIC code is in the EXT0 block |
| 00:38:12 | mcuelenaere | I think IDA is able to disassemble it (I tried it several times, but as I didn't understand the PIC architecture nor it's instructions it didn't really make sense to me) |
| 00:38:50 | mcuelenaere | but it did look like legitimate code |
| 00:40:05 | | Quit lymeca (Read error: 110 (Connection timed out)) |
| 00:41:05 | *** | Saving seen data "./dancer.seen" |
| 00:41:45 | | Quit n1s (Remote closed the connection) |
| 00:42:20 | Aurix_Lexico | yeah, I was able to extract it, and disassemble it with IDA |
| 00:42:54 | | Join lymeca [0] (n=lymeca@dsl-74-220-76-61.cruzio.com) |
| 00:43:23 | Aurix_Lexico | I found a some college's course notes on PIC assembly, and have the PIC datasheet |
| 00:43:55 | Aurix_Lexico | it still looks pretty confusing though :/ |
| 00:45:57 | mcuelenaere | yeah I think the PIC datasheet isn't hard to find |
| 00:46:19 | mcuelenaere | but still, it's way more embedded then the ARM processor |
| 00:46:57 | | Quit DataGhost (Read error: 104 (Connection reset by peer)) |
| 00:46:59 | Zagor | ha, with proper watermarks even a 67KB buffer is not too small |
| 00:47:24 | mcuelenaere | will the scroll thread do its own lcd_update() or is this the responsibility of the main thread? |
| 00:48:03 | | Quit Hillshum ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") |
| 00:49:02 | | Join mud-rb [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) |
| 00:49:04 | Zagor | wav is rather busy with such a small buffer though... |
| 00:49:47 | gevaerts | Now go for a 67B buffer :) |
| 00:50:37 | | Quit jhulst (Read error: 113 (No route to host)) |
| 00:51:00 | Zagor | gevaerts: :) |
| 00:51:17 | MarcGuay | Hmm utf8.def not found building the manual.. |
| 00:51:37 | | Quit |mr (Read error: 110 (Connection timed out)) |
| 00:52:29 | mcuelenaere | hmm seems like it does do its own lcd_update()'s.. |
| 00:54:01 | mcuelenaere | when I have a scrolling line and the main LCD thread only does lcd_update() every sleep(50); I see that the scrolling line also updates about every 50 ticks. is this normal behaviour? |
| 00:55:11 | | Part toffe82 |
| 00:55:56 | | Quit Zagor ("Leaving") |
| 00:56:09 | mcuelenaere | hmm never mind, it seems like the lcd driver doesn't support partial lcd drawing |
| 00:56:15 | | Join admin1lbo [0] (n=admin1lb@pool-72-88-166-100.nwrknj.east.verizon.net) |
| 00:56:21 | | Nick admin1lbo is now known as QUICKSTART (n=admin1lb@pool-72-88-166-100.nwrknj.east.verizon.net) |
| 01:00 |
| 01:00:16 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 01:00:32 | | Join Bensawsome [0] (n=Bensawso@unaffiliated/bensawsome) |
| 01:01:58 | Unhelpful | mcuelenaere: thanks, i didn't know we *had* dependencies in FS |
| 01:02:18 | mcuelenaere | np :) |
| 01:02:19 | Unhelpful | also, i have another nail in the vc-dither's coffin. we can make bayer a *lot* cheaper than it is now. |
| 01:03:17 | Unhelpful | it's currently a lookup in a 16x16 table. we can replace that with lookups in two 16-byte tables, and an xor, or even one table, if we throw in a shift-by-one and another bitwise logical op. |
| 01:04:42 | | Join lasser [0] (n=chatzill@W8610.w.pppool.de) |
| 01:04:52 | | Quit DerDome ("Leaving.") |
| 01:04:57 | | Quit lymeca (Read error: 110 (Connection timed out)) |
| 01:07:56 | Unhelpful | ...actually, i can get rid of the shift. the whole thing can be done with one table lookup and one bitwise and per row, and one table lookup and one bitwise xor per pixel |
| 01:08:01 | | Join lymeca [0] (n=lymeca@dsl-74-220-76-75.cruzio.com) |
| 01:15:42 | | Quit jhMikeS (Nick collision from services.) |
| 01:15:48 | | Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) |
| 01:17:57 | MarcGuay | Looks like utf8.def has been renamed utf8x.def in the new Latex package. |
| 01:19:47 | MarcGuay | it snowboards with umlauts |
| 01:25:05 | | Quit lymeca (Connection timed out) |
| 01:27:40 | | Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") |
| 01:28:07 | | Join hd [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) |
| 01:28:37 | | Quit HellDragon (Read error: 104 (Connection reset by peer)) |
| 01:28:37 | | Quit hd (Read error: 104 (Connection reset by peer)) |
| 01:28:45 | | Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) |
| 01:38:58 | Unhelpful | it works, with one bitwise and, one 1D array lookup and one bitwise xor in the inside loop. should that be of comparable speed to two bitwise and + a 2D array lookup? |
| 01:40:18 | Unhelpful | binsize diff is -216B on arm |
| 01:45:09 | | Quit HellDragon (Connection reset by peer) |
| 01:46:33 | | Quit wpyh (Read error: 110 (Connection timed out)) |
| 01:47:42 | Unhelpful | that's on ipod4g... m5/x5 will probably improve slightly less as they have one more place that looks up dither values |
| 01:48:56 | | Join midkay [0] (n=midkay@rockbox/developer/midkay) |
| 01:49:22 | amiconn | Unhelpful: I didn't read up everything yet, but regarding to your last question I think it should be even faster |
| 01:49:36 | amiconn | 1D array lookup requires less address calculation |
| 01:50:30 | Unhelpful | it also saves ~200B, give or take a bit depending on arch whether or not there's a remote |
| 01:52:13 | | Quit _Auron_ (Read error: 104 (Connection reset by peer)) |
| 01:52:18 | Unhelpful | i was thinking of committing my current batch of scaler improvements, if there are no objections. should be binsize and speed improvements everywhere but greyscale, but those get a HQ scaler to replace the nearest-neighbor one, so it's not too bad a deal, i'd say |
| 01:52:19 | | Join _Auron_ [0] (n=DarkAuro@ppp-70-244-161-118.dsl.rcsntx.swbell.net) |
| 01:53:44 | | Quit lasser (Remote closed the connection) |
| 01:57:08 | | Join wpyh [0] (n=william@125.163.88.253) |
| 02:00 |
| 02:01:56 | | Quit Schmogel (Read error: 104 (Connection reset by peer)) |
| 02:04:09 | | Quit QUICKSTART (Remote closed the connection) |
| 02:06:52 | | Join lymeca [0] (n=lymeca@dsl-74-220-76-61.cruzio.com) |
| 02:10:03 | | Quit aneqrs () |
| 02:17:09 | | Join Makuseru [0] (n=max@163.106.40.24.aeneasdsl.com) |
| 02:24:12 | | Join grndslm [0] (n=grndslm@24-116-87-97.cpe.cableone.net) |
| 02:25:32 | | Quit grndslm (SendQ exceeded) |
| 02:26:27 | | Join grndslm [0] (n=grndslm@24-116-87-97.cpe.cableone.net) |
| 02:32:48 | | Join RockRabbit [0] (n=3aac9a01@gateway/web/cgi-irc/labb.contactor.se/x-4a91097042010cb5) |
| 02:32:50 | | Quit lymeca (Read error: 110 (Connection timed out)) |
| 02:33:18 | RockRabbit | Can anyone tell me what DBOP stands for and what it means? |
| 02:34:03 | hobbs | it's like DCOP only it's got that swing? |
| 02:34:28 | RockRabbit | As in DBOP-A-LULA? |
| 02:35:07 | hobbs | and a wham-bam-boom. |
| 02:35:58 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 02:36:30 | RockRabbit | Actually I first thought it was a song by Cyndi Lauper. |
| 02:36:40 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 02:37:04 | krazykit | please try to stay on topic |
| 02:39:12 | hobbs | please try to recognize the topic. |
| 02:39:56 | RockRabbit | Still no takers on DBOP? |
| 02:40:19 | RockRabbit | Its not in the rockbox glossary but its used often in conversations. |
| 02:40:47 | krazykit | according to the logs, it stands for "DBOP stands for "Data Block *Output* Port"" |
| 02:41:03 | hobbs | RockRabbit: it's the name of a bit of the AS3525 that does some I/O. No clue what it stands for though :) |
| 02:41:06 | Unhelpful | <saratoga> [15:30:22] -bertrik: DBOP is a highspeed output port designed for driving LCDs |
| 02:41:09 | *** | Saving seen data "./dancer.seen" |
| 02:41:25 | | Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) |
| 02:41:37 | RockRabbit | Looks like I need the as3525 datasheet more than ever. |
| 02:42:05 | | Quit Makuseru (Read error: 104 (Connection reset by peer)) |
| 02:42:19 | krazykit | RockRabbit, http://www.rockbox.org/irc/rockbox-20081128.txt - at around 17:55, there's some discussion about it that may help |
| 02:42:35 | RockRabbit | thanks |
| 02:44:56 | RockRabbit | ANyone know how I can get hold of an as3525 datasheet? |
| 02:45:34 | krazykit | RockRabbit, talk to Bagder |
| 02:50:04 | | Quit HellDragon (Client Quit) |
| 02:53:36 | pixelma | note that Bagder is in Europe and it's almost 3 AM here |
| 02:55:59 | | Part grndslm ("Leaving") |
| 02:56:52 | | Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-53799ce3f402ff5b) |
| 02:58:07 | | Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) |
| 03:00 |
| 03:00:29 | | Quit mcuelenaere () |
| 03:13:43 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
| 03:14:10 | kugel | RockRabbit: hi |
| 03:14:34 | | Join lymeca [0] (n=lymeca@dsl-74-220-76-75.cruzio.com) |
| 03:14:50 | | Join Lss [0] (n=Lss@cm203.delta90.maxonline.com.sg) |
| 03:17:53 | | Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") |
| 03:19:39 | kugel | RockRabbit: I wonder if you have noticed http://www.rockbox.org/tracker/task/9679 |
| 03:27:33 | | Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.4/2008111318]") |
| 03:27:47 | | Quit jhulst (Remote closed the connection) |
| 03:27:56 | | Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) |
| 03:28:35 | | Quit massiveH (Client Quit) |
| 03:32:21 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 03:35:06 | | Quit faemir (Remote closed the connection) |
| 03:36:05 | | Quit herrwaldo ("Konversation terminated!") |
| 03:38:43 | | Quit lymeca (Read error: 110 (Connection timed out)) |
| 03:47:39 | | Join lee321987 [0] (n=chatzill@node103.32.251.72.1dial.com) |
| 03:49:23 | lee321987 | anyone here who's done work in the Sansa c200's USB "bytes inserted" bug? |
| 03:50:15 | saratoga | lee321987: probably the wrong time of night for any of those people |
| 03:50:59 | RockRabbit | hi kugel - yes i got your forum post - sorry i have been afk for a while |
| 03:51:11 | lee321987 | Well maybe some one else can answer this question −−−− I was just wondering if there is some information that some company won't give us that might make it easy to fix the bug...? |
| 03:51:46 | saratoga | lee321987: maybe. its thought to be a bug in the PP hardware, so maybe they know how to correct it |
| 03:51:57 | krazykit | lee321987, not so much "won't give" as "can't legally give" in many cases, as the licensing agreements forbid them from doing so |
| 03:52:34 | saratoga | lee321987: wait are you talking about the USB or SD bugs? |
| 03:52:50 | lee321987 | is the PP still being used in _new_ hardware? |
| 03:53:25 | midgey | saratoga: i've been looking at wma recently, trying to fix some of the tracker issues |
| 03:53:37 | saratoga | midgey: yes thank you |
| 03:53:41 | saratoga | i've already commited your fixes |
| 03:53:44 | lee321987 | the bug that inserts 2 bytes (randomly −− I think) during USB data transfers through RB. |
| 03:53:53 | saratoga | i was very much hoping to get those fixed for 3.1 |
| 03:54:14 | saratoga | lee321987: thats not a USB bug, see FS #8663 |
| 03:54:23 | RockRabbit | krazykit - i sent a pm to bagder - but got no reply so far |
| 03:54:26 | | Quit jhulst (Read error: 60 (Operation timed out)) |
| 03:54:46 | lee321987 | sorry for the wrong terms. |
| 03:54:51 | midgey | i had some other changes i was wondering about |
| 03:55:05 | Unhelpful | RockRabbit: as noted before, he's in europe, and is probably asleep at this hour. |
| 03:55:08 | krazykit | RockRabbit, well, seeing as he's probably asleep, you'll have to wait til (european) morning |
| 03:55:49 | RockRabbit | i sent him a private message two days ago |
| 03:55:58 | lee321987 | what do you call it? An SD bug? |
| 03:56:06 | saratoga | midgey: what did you have in mind? |
| 03:57:08 | midgey | Why is M_PI_F defined as 0x3243f? Isn't 0x3243d more accurate |
| 03:57:15 | midgey | same with TWO_M_PI_F |
| 03:57:39 | lee321987 | Does the SD driver not get used if you have no SD card in the player? |
| 03:58:06 | saratoga | the device has a built in SD card, so theres always one in the player |
| 03:58:26 | lee321987 | ahhhhh |
| 03:59:07 | RockRabbit | how can i tell how much ram memory each rockbox supported player has? |
| 04:00 |
| 04:00:24 | saratoga | midgey: I don't believe so |
| 04:00:29 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 04:00:45 | midgey | ah, nope. i divided wrong |
| 04:00:49 | midgey | damn you fixed point |
| 04:00:52 | rasher | saratoga: why didn't you commit your fixes to the 3.1 branch? |
| 04:01:22 | midgey | also exponents[-1] doesn't really make sense (very high freq MDCT calc) |
| 04:01:40 | saratoga | rasher: I did |
| 04:01:45 | midgey | i suppose I should just pastbin my diff, one sec |
| 04:02:04 | lee321987 | you'd think that companies would be more forthcoming with RB devs. (Are they worried that other companies will steal their technology?) I _know_ my next DAP will be one that RB works on. |
| 04:02:20 | rasher | saratoga: Ah. Didn't see the latest commit |
| 04:03:20 | Unhelpful | lee321987: companies that make DAPs often license much of the compenents, and library code for them, from other companies, which don't really care about how any one device based on their IP sells, and which license said IP under NDA. |
| 04:05:06 | lee321987 | your name doesn't fit you. |
| 04:06:29 | scorche | RockRabbit: DeviceChart |
| 04:07:48 | midgey | saratoga: http://www.pastebin.ca/1289984 |
| 04:08:02 | midgey | includes some changes you've already committed |
| 04:08:40 | RockRabbit | scorche: thanks - just what i wanted |
| 04:09:03 | saratoga | midgey: looking through it now |
| 04:09:08 | midgey | also includes some random debugf and spelling corrections :) |
| 04:09:11 | saratoga | does it fix any known problem samples? |
| 04:09:31 | | Quit lee321987 ("ChatZilla 0.9.84 [Firefox 3.0.4/2008102920]") |
| 04:11:25 | midgey | not really that i know of. some of the problem samples sound a bit better (glitches seem less noticeable) |
| 04:11:39 | midgey | could be the placebo effect. i'd like to think i'm fixing things |
| 04:12:10 | midgey | i'll revert to svn and check |
| 04:12:11 | saratoga | midgey: some of that looks a bit odd |
| 04:12:30 | saratoga | i recommend dumping the output to PCM and comparing it quantitatively using matlab or whatever |
| 04:12:53 | saratoga | i've long since learned to never trust my ears :) |
| 04:13:03 | midgey | i'll do that |
| 04:13:17 | midgey | im relatively certian while(len > 0) is wrong |
| 04:13:56 | saratoga | yes I think ffmpeg changed that recently |
| 04:14:14 | saratoga | i looked at it briefly but couldn't find any samples where it made a difference so i sat on the fix |
| 04:14:25 | midgey | otherwise the next block of code is useless |
| 04:14:28 | saratoga | though maybe it should be fixed even if we can't test it |
| 04:17:01 | midgey | seems to make sense logically |
| 04:17:05 | saratoga | the block below @@ -1253,11 +1254,11 @@ seems to do the same thing but less accurately I think? |
| 04:18:02 | midgey | well e2 is a fixed32 and n is an int |
| 04:18:37 | midgey | if you just divide fixed32/int will you get a fixed32 back? |
| 04:19:07 | saratoga | midgey: yes |
| 04:19:28 | midgey | well then, scratch that, i thought you'd get an int casted to a fixed32 |
| 04:19:29 | saratoga | an int is just a fixed variable with a PRECISION of 0 |
| 04:21:32 | midgey | can you cast a fixed32 to a fixed64? |
| 04:22:19 | | Quit Nico_P (Remote closed the connection) |
| 04:22:46 | Unhelpful | midgey: i think you'll get the wrong half of it, if you do that... you want to >>32 it, i would expect, and possibly add shift if they fixed32/fixed64 you're using have different precision |
| 04:23:06 | Unhelpful | the, not they. |
| 04:23:41 | midgey | the wma codec casts here and there and i didn't know if that caused any endian issues |
| 04:23:53 | saratoga | midgey: @@ -1307,21 +1307,23 @@ reverts some of r14134 |
| 04:24:18 | saratoga | in general anytime you see shifts by anything other then 16 its because they absolutely have to be that value to avoid overflowing |
| 04:25:01 | saratoga | in these cases one can only rearrnage the algebra with great caution |
| 04:25:13 | midgey | ah |
| 04:25:20 | midgey | see this is helpful :) |
| 04:26:02 | saratoga | basically i wrote this by using 16 everywhere and then incrementing shifts until problem samples decoded right |
| 04:26:15 | midgey | very scientific |
| 04:26:20 | Unhelpful | saratoga: does rockbox code as it stands generally assume a truly fixed precision? i've seen and written code before where the precision "floats" as appropriate at each stage |
| 04:27:07 | saratoga | Unhelpful: variables have to be rescaled from time to time |
| 04:27:25 | saratoga | fixed just means that the programmer is in charge of normalization, not the hardware |
| 04:27:53 | | Join blkhawk- [0] (n=blkhawk@g226129030.adsl.alicedsl.de) |
| 04:28:51 | saratoga | in reality the codec is just doing cosine transforms, and those transforms have no native scale, so the definition of the number one is arbitrary anyway |
| 04:28:59 | saratoga | we reassign it as needed |
| 04:29:43 | | Quit RockRabbit ("CGI:IRC (EOF)") |
| 04:31:14 | midgey | i've found another problematic sample if you're interested |
| 04:31:24 | midgey | http://wymette.home.att.net/files/wmatest.htm |
| 04:31:44 | midgey | just sounds like a high pitched whine in rockbox |
| 04:32:24 | Unhelpful | shouldn't be hard, i'd suppose, to kludge up a plugin that loads a greyscale pixmap, and displays it with greylib? |
| 04:32:49 | midgey | by the sound of it, most of my changes aren't correct and can probably be ignored |
| 04:33:08 | | Quit linuxstb (Read error: 110 (Connection timed out)) |
| 04:33:23 | saratoga | midgey: yes that certainly fails quite badly |
| 04:33:38 | midgey | i was quite surprised when i first listened |
| 04:34:06 | | Join RockRabbit [0] (n=3aac9a01@gateway/web/cgi-irc/labb.contactor.se/x-60517774b98d073c) |
| 04:34:38 | saratoga | it reports an ASF parser error so that may have something to do with it |
| 04:34:44 | saratoga | though those seem quite common |
| 04:34:53 | saratoga | even on samples that decode more or less correctly |
| 04:35:07 | midgey | i also have another track that gets a -5 return on wma_decode_block |
| 04:35:21 | midgey | so the one on the tracker is not alone |
| 04:35:34 | midgey | this track decodes correctly however |
| 04:36:17 | RockRabbit | if i detect a button press via an input pin on a GPIO port (in this case Sansa with AMS as3525 soc), how do I clear or reset the pin to detect the next button press? At present the button is continually being detected after being pressed only once. |
| 04:37:16 | saratoga | midgey: I've seen -5 errors before |
| 04:37:31 | saratoga | often they don't decode in ffmpeg either, so testing them there is a good first step |
| 04:37:51 | midgey | i'll have to tell the track it's not as special as i thought |
| 04:38:07 | saratoga | the ffmpeg decoder is evidently still incomplete |
| 04:38:30 | midgey | are they actively working on it? |
| 04:38:51 | saratoga | I don't believe so |
| 04:39:07 | midgey | well damn |
| 04:39:39 | midgey | are there other types of WMA that we don't handle other than lossless? |
| 04:39:45 | saratoga | yes, PRo and Voice |
| 04:39:52 | saratoga | we simply reject those |
| 04:40:17 | midgey | is pro the same as wma v10? |
| 04:40:45 | * | midgey wanders off the wikipedia |
| 04:41:07 | midgey | apparently to learn english as well.... |
| 04:41:13 | *** | Saving seen data "./dancer.seen" |
| 04:42:46 | saratoga | i think the naming is inconsistent, I've heard v10 refer to both v2 files produced by the WMP10 encoder, and to other formats as well |
| 04:43:25 | midgey | yep, seems that way |
| 04:43:29 | saratoga | WMAV2 is well standardized, but the Pro format seems more fluid with various versions and occasional research papers |
| 04:43:32 | Unhelpful | also, multichannel, lossless, and i think voice were introduced as part of the same "version", but are all essentially different codecs |
| 04:43:44 | | Quit blkhawk (Connection timed out) |
| 04:43:51 | | Nick blkhawk- is now known as blkhawk (n=blkhawk@g226129030.adsl.alicedsl.de) |
| 04:44:02 | saratoga | we just skip everything not tagged as V1 or V2 in the header |
| 04:44:57 | midgey | the other variants seem like completely different beasts |
| 04:46:45 | | Join lymeca [0] (n=lymeca@dsl-74-220-76-75.cruzio.com) |
| 04:47:01 | saratoga | midgey: that file you linked plays better in ffmpeg, but i wouldn't say it plays well :) |
| 04:47:47 | midgey | yeah, i just tried it on vlc. it seems to jump and stutter |
| 04:49:01 | mud-rb | is there a doc somewhere that explains the drawing modes? can't seem to find it (ex. DRMODE_SOLID vs DRMODE_FG, etc.) |
| 04:49:13 | saratoga | midgey: why the sudden interest in wma? |
| 04:51:12 | midgey | to be honest, i was just looking to fix some bugs before 3.1 |
| 04:51:23 | midgey | and wma happened to be the most recent one |
| 04:51:27 | saratoga | ah ok |
| 04:51:41 | midgey | and i'm working at microsoft next summer so that might have contributed |
| 04:52:22 | saratoga | well i've got a long list of codec chores if you're bored |
| 04:52:44 | midgey | for wma specifically or all across the board? |
| 04:52:55 | saratoga | all across the board |
| 04:52:57 | saratoga | take your pick |
| 04:53:23 | saratoga | though I think you could commit that fix from ffmpeg that i couldn't find a problem sample for |
| 04:53:44 | midgey | always have to worry about the commit count ;) |
| 04:54:20 | midgey | did anything else in the pastebin look promising? |
| 04:56:54 | saratoga | the exponents[-1] thing is certainly wrong |
| 04:57:04 | saratoga | though i'm puzzeled how it doesn't seem to matter |
| 04:57:15 | saratoga | i'd expect it to cause more problems by now |
| 04:57:50 | midgey | just getting lucky |
| 04:57:50 | saratoga | sorry I mean the SVN code is wrong, not your fix |
| 04:57:57 | midgey | right |
| 04:58:30 | | Quit miepchen^schla (Read error: 110 (Connection timed out)) |
| 04:59:09 | midgey | i'm not sure the fix is right, that's what ffmpeg has at least |
| 04:59:39 | saratoga | i'm not even sure what it does |
| 05:00 |
| 05:00:23 | saratoga | i guess esize is bigger then bsize and it ends up being a small number? |
| 05:00:50 | midgey | that's all i can come up with |
| 05:03:17 | saratoga | hmm no its often zero |
| 05:03:33 | midgey | do you think the casts in wmadeci are fine or should they be changed? |
| 05:04:25 | | Quit lymeca (Connection timed out) |
| 05:06:24 | midgey | actually, i have no idea how it works |
| 05:06:36 | midgey | -1 will be 0xFFFF etc correct? |
| 05:06:50 | midgey | then shifted left with have low bits of 0 |
| 05:07:06 | midgey | if esize>size, you'll get -1 back? |
| 05:07:13 | | Quit HellDragon (Client Quit) |
| 05:07:38 | | Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) |
| 05:08:45 | saratoga | midgey: at least in the file i looked at the two were always equal, meaning its always -1 |
| 05:08:57 | saratoga | regarding the casts, I don't think they change anything |
| 05:09:12 | midgey | i'm surprised that works |
| 05:09:20 | saratoga | the one macro is just a cast, and the other macro zeros and then casts |
| 05:09:47 | saratoga | the macros were put in there by marsdaddy in his first codec, but i didn't use them much |
| 05:11:30 | midgey | which macros? |
| 05:11:51 | saratoga | Fixed32From64, etc |
| 05:11:57 | saratoga | though iguess some are really functions |
| 05:12:05 | midgey | ah, yes sorry |
| 05:12:28 | midgey | aren't you still indexing an array with a negative index? |
| 05:12:37 | saratoga | yeah, but we do that a lot :) |
| 05:12:57 | * | midgey 's mind is blown |
| 05:13:51 | saratoga | you probably shouldn't look at wmadata.h then |
| 05:14:01 | Unhelpful | midgey: an array is a pointer. a[-1] is the same as *(a-1) |
| 05:14:21 | midgey | i knew thta, i thought exponents was const |
| 05:14:25 | saratoga | hmm though i'm not sure if its correct here |
| 05:15:35 | midgey | have you looked at how ffmpeg handles the exponents array |
| 05:17:58 | | Quit jhulst (Remote closed the connection) |
| 05:18:28 | saratoga | unless i'm missing something i think they also allow negative 1 |
| 05:18:28 | | Quit RockRabbit ("CGI:IRC (EOF)") |
| 05:19:20 | midgey | they do, they increment the array throughout wma_decode_block |
| 05:19:25 | midgey | increment the pointer |
| 05:23:29 | saratoga | midgey: printing pointers makes me think we're probably grabbing exponents_bsize[1] as exponents[0][-1] |
| 05:23:40 | saratoga | i'll see about compiling ffmpeg to see what they're actually using |
| 05:23:51 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 05:26:44 | | Join lymeca [0] (n=lymeca@dsl-74-220-76-56.cruzio.com) |
| 05:26:55 | | Quit lymeca (Remote closed the connection) |
| 05:27:06 | | Join lymeca [0] (n=lymeca@dsl-74-220-76-56.cruzio.com) |
| 05:28:05 | | Quit Lss (Read error: 110 (Connection timed out)) |
| 05:30:34 | | Quit MarcGuay ("ChatZilla 0.9.84 [Firefox 3.0.4/2008102920]") |
| 05:40:04 | saratoga | i think i'm losing my mind |
| 05:40:09 | saratoga | but ffmpeg looks broken too |
| 05:40:45 | midgey | ffmpeg is always fun to look through... |
| 05:42:49 | saratoga | no wait we're just really wrong here |
| 05:44:47 | | Quit jhulst (Read error: 60 (Operation timed out)) |
| 05:45:11 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 05:45:38 | saratoga | it seems i never properly implemented ffmpeg r8627 which fixed this issue |
| 05:45:54 | saratoga | which is why the esize/bsize logic makes no sense in rockbox |
| 05:48:08 | midgey | that's what i was refering to with how they handle exponents |
| 05:48:49 | saratoga | it looks like i half implemented it |
| 05:48:53 | saratoga | but left out some lines |
| 05:48:57 | saratoga | amazing that it worked at all |
| 05:49:26 | midgey | i was syncing up their changes from about 8143 yesterday and i saw they handled it a bit differently |
| 05:50:08 | midgey | unfortunately i kept segfaulting in bitstream.h and i gave up for the time being |
| 05:50:57 | midgey | the get_bit1 change in r9999 made sense as well |
| 05:51:18 | midgey | r10004 seems correct as well |
| 06:00 |
| 06:00:48 | | Quit jhulst (Read error: 60 (Operation timed out)) |
| 06:01:14 | | Join pixelma_ [0] (n=pixelma@rockbox/staff/pixelma) |
| 06:01:20 | | Quit lymeca (Read error: 113 (No route to host)) |
| 06:01:47 | Unhelpful | urgh... messy declaration issues :/ |
| 06:01:57 | | Quit amiconn (Nick collision from services.) |
| 06:01:59 | | Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) |
| 06:02:32 | | Quit pixelma (Read error: 110 (Connection timed out)) |
| 06:03:10 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 06:03:14 | Unhelpful | resize.h has declarations that need things from bmp.h, and vice versa... and i'm a bit stuck figuring out where to declare the needed structs and functions to make it happy :/ |
| 06:06:21 | Unhelpful | there we go, a forward declaration for struct rowset and all is well |
| 06:08:15 | saratoga | midgey: alright properly synced it |
| 06:08:27 | saratoga | not noticing any changes with my files but i don't know which ones to test |
| 06:08:57 | midgey | i've been stealing test files from random sites around the internet |
| 06:09:05 | midgey | most seem to work in rockbox though |
| 06:11:44 | midgey | saratoga: http://samples.mplayerhq.hu/A-codecs/WMA/wma-broken.asf is broken in rockbox as well |
| 06:12:10 | midgey | vlc 0.9.8a handles it better than us, but not well |
| 06:12:43 | midgey | i dont have the ffmpeg source on my computer so i've been testing in vlc |
| 06:14:40 | | Join psycho_maniac [0] (i=psycho_m@ppp461.hk.centurytel.net) |
| 06:15:12 | saratoga | that asf doesn't even play in foobar |
| 06:15:29 | midgey | flip4mac does fine |
| 06:21:03 | | Quit jhulst (Read error: 131 (Connection reset by peer)) |
| 06:25:47 | | Quit Aurix_Lexico (Remote closed the connection) |
| 06:26:24 | saratoga | i'm going to commit these changes to SVN, and if no one complains I may add them to 3.1 |
| 06:27:44 | midgey | i think unless they fix a noticeable bug, the changes don't need to go into 3.1 |
| 06:28:00 | midgey | i mean the code in svn is clearly wrong |
| 06:28:07 | midgey | so maybe it does make sense |
| 06:28:43 | saratoga | i think the bug only affects a few frequency bands, so its probably not too noticable |
| 06:29:16 | saratoga | midgey: you mentioned some other ffmpeg svn numbers, are there other things you think we didn't sync right? |
| 06:30:35 | midgey | well the get_bits1 change won't cause any functional differences |
| 06:30:53 | saratoga | are there more of those i didn't sync? |
| 06:31:13 | midgey | r10004 might have slightly different behavior get_bits -> skip_bits |
| 06:31:55 | midgey | r14171 and r15004 have changes we don't have |
| 06:32:11 | midgey | supposedly fixes some WMV audio stutter |
| 06:32:18 | midgey | have found a test case to confirm |
| 06:32:22 | midgey | haven't* |
| 06:32:35 | saratoga | i put a lot of time into the get_bits1 thing |
| 06:32:40 | saratoga | i thought it was all commited |
| 06:32:52 | saratoga | i remember it not seeming to change anything |
| 06:33:51 | saratoga | i think in the long term i have to figure out how huffman coding is really implemented in our codecs and try to improve it |
| 06:34:04 | saratoga | i'm sure its much slower then it should be |
| 06:35:15 | midgey | i highly doubt the get_bits1 change would make any difference, see r9999 |
| 06:36:50 | | Quit HellDragon (Read error: 104 (Connection reset by peer)) |
| 06:37:05 | Unhelpful | i'd be amazed if googling "optimized huffman decoder" did not find an OSS project with a compatible license from which you could borrow one, saratoga |
| 06:37:20 | | Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) |
| 06:38:40 | saratoga | Unhelpful: I'm sure thats true |
| 06:38:53 | saratoga | but merging them is non-trivial without a good understanding of what they do |
| 06:39:54 | | Quit HellDragon (Read error: 54 (Connection reset by peer)) |
| 06:40:07 | | Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) |
| 06:40:44 | saratoga | i have been trying to merge in some Vorbis bitstream optimizations I found in one of the tremor brances with little success, and thats the same decoder but different brances |
| 06:41:14 | *** | Saving seen data "./dancer.seen" |
| 06:47:58 | | Join [1]psycho_maniac [0] (i=psycho_m@96.14.220.33) |
| 06:49:48 | mud-rb | so, is it preferable to do some really ugly hacks to get things to work on more targets, or to be cleaner and more bug free but work on fewer targets? |
| 06:49:59 | mud-rb | (for a plugin) |
| 06:51:24 | Unhelpful | there are plugins that go either way |
| 06:51:53 | Unhelpful | for example, no pictureflow on greyscale targets, but jpeg viewer even on mono targets |
| 06:52:30 | mud-rb | my main concern is RAM...on the high ram targets everything will be easy, but i'm going to need some kind of insane caching scheme if i go to the 2 MB targets... |
| 06:53:23 | ameyer | what's the plugin do? |
| 06:53:48 | * | ameyer wonders if there are any 2MB targets with non-tiny screens |
| 06:55:16 | mud-rb | ameyer: viewer for game records for go/weiqi/baduk. i'm rewriting it. basically i have to keep a tree structure in memory to traverse, and if i do it on the 2 MB targets, there's not enough RAM to keep the whole thing in even if i steal the audio buffer |
| 06:55:28 | | Quit [1]psycho_maniac (Remote closed the connection) |
| 06:55:51 | mud-rb | i thought up an algorithm to do it even on little memory, but it's going to be ugly and error prone |
| 06:55:58 | | Quit psycho_maniac (Read error: 113 (No route to host)) |
| 06:57:34 | Unhelpful | yay, pluggable scaler output is "working", in that i have the framework for it in place, and regular bitmap loading without an output plugin works |
| 06:57:53 | Unhelpful | time to code a test case :/ |
| 06:59:56 | mud-rb | oh well, the 2 MB targets all look like the screen is too small for much anyway. i'll just make it work for them but make it die if you try to load a file that's too large... |
| 07:00 |
| 07:01:32 | Unhelpful | saratoga: i was going to say that if we had one nice huffman decoder in core, corejpeg and codecs could all use it, but that's probably not feasible unless other codecs use the same methods for inserting markers in the huffman bitstream :/ |
| 07:02:15 | | Join Minthe [0] (n=Minthe@gw13.ecc.u-tokyo.ac.jp) |
| 07:06:44 | saratoga | Unhelpful: i have no idea how huffman coding is actually implemented, is it generalizable between different codecs? |
| 07:09:25 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 07:10:25 | | Join ball [0] (n=ball@adsl-99-152-241-9.dsl.emhril.sbcglobal.net) |
| 07:12:21 | ball | I'm listening to music on my iPod Mini, courtesy of RockBox |
| 07:12:27 | ball | ...so thanks for that. |
| 07:19:34 | midgey | saratoga: it might be my ears, but i think the first wma in FS #7488 sounds better now |
| 07:20:51 | midgey | baroque loop sounds good as well, but there's still a slight glitch in the middle of the song |
| 07:23:54 | saratoga | midgey: i diffed the two and theres 6 spots in the first file that are improved |
| 07:23:58 | saratoga | so i guess it does help |
| 07:25:01 | midgey | i have some songs acting funny on track changes (slight audio glitch) so there still might be some things that aren't reset between tracks |
| 07:26:10 | saratoga | midgey: if you can reproduce them its usually not too hard to figure out what causes them |
| 07:26:28 | midgey | i'll look into on the plane tomorrow |
| 07:26:41 | Unhelpful | saratoga: there's really only one "way", as far as i know, and all that differs is tables and how codecs store them if they don't use a fixed table... as far as huffman coding itself goes. :/ |
| 07:26:44 | saratoga | i started by zeroing the entire struct like you did, then did a binary search zeroing half as much each time |
| 07:27:12 | saratoga | Unhelpful: so it might be feasible to write an optimized one in assembly and have different codecs use it? |
| 07:27:14 | midgey | wma_broken is handled a bit better now as well |
| 07:27:28 | Unhelpful | however, jpeg can insert marker codes into the huffman stream, and you have to catch that... and i'm sure there will be other codecs that do similar, but use different methods |
| 07:27:47 | midgey | it goes negative time remaining from time to time... |
| 07:27:57 | Unhelpful | maybe, if the buffer is preprocessed by a codec function that removes and handles anything that's not huffman code data? |
| 07:28:24 | saratoga | why does jpeg do that? |
| 07:28:58 | | Part ball ("bye!") |
| 07:30:51 | Unhelpful | error resilience, i believe. the codes can mark that you're in a new macroblock, etc, and the decoder can bail on the current one, and go about getting things back into a known state |
| 07:31:31 | Unhelpful | in any case, in jpeg the magic is a byte-aligned FF followed by a non-zero byte. an actual byte-aligned FF in the huffman codestream is just followed by a 00 |
| 07:31:40 | saratoga | codeclib stuff isn't available to the core anyway, so even if we had seperate ones for jpeg and codecs that wouldn't be a huge deal |
| 07:31:51 | | Quit XavierGr () |
| 07:31:53 | Unhelpful | so a preprocesser could easily strip out that 0, and move everything over one |
| 07:32:42 | saratoga | Unhelpful: are you interested in jpeg? |
| 07:33:10 | Unhelpful | right, but if we have one nice generic decoder, assuming that such a thing can be done, it could live in core and be used by jpeg and codecs |
| 07:33:39 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 07:34:05 | Unhelpful | it's something i'd like to see working. i'm not entirely sure i can tackle making an acceptable core jpeg decoder. i looked at the jpeg_decoder.o file from the plugin, and that's 13KB... i doubt that would get in. |
| 07:40:47 | Unhelpful | hrm, so if i want to just display an image until i get a button press, in a plugin, it looks from ppmviewer.c like i can just do rb->button_get(true), then return? |
| 07:45:35 | saratoga | Unhelpful: theres certainly targets were 13KB would be tolerable, and I'm sure it can be made smaller |
| 07:48:33 | Unhelpful | i'd actually expect it to end up going the other direction, if it's to interface with the scaler as it is now. :/ |
| 07:50:17 | Unhelpful | the *easiest* way to go would be to buffer the entire image in RGB, then feed it to the scaler exactly as BMP does. that would make it *much* heavier than BMP, which feeds the scaler in small pieces |
| 07:51:35 | saratoga | Unhelpful: jpeg blocks are stored in order right? |
| 07:52:26 | Unhelpful | saratoga: yes, but i believe it's the whole Y plane, then the whole U plane, then the whole V plane. so, we could track a seek offset that we read from in each plane, in that case, and decode 1-2 MB rows at a time |
| 07:52:39 | Unhelpful | but, again, that's getting toward larger, not smaller code |
| 07:53:52 | Unhelpful | hrm, a "for greylib" output plugin for the scaler should probably live in grey_draw.c? |
| 07:56:59 | saratoga | Unhelpful: doing one plane at a time is probably better, since you could resize each one and then accumulate the resized images |
| 07:57:06 | | Quit jhulst (Remote closed the connection) |
| 07:58:04 | Unhelpful | yes, and no. the color-target scaler takes RGB pixels, the grey-target one takes greyscale pixels. |
| 07:58:48 | saratoga | Unhelpful: do 3 grayscale resizes then? |
| 07:59:24 | Unhelpful | ...there is no greyscale resizer on targets with a color screen. they're the same functions, with some #ifdefs that change key parts. |
| 08:00 |
| 08:00:07 | saratoga | yes i know, but its probably cheaper to have both resizers then to buffer the decoded image |
| 08:01:57 | Unhelpful | no, no, i definitely don't want to buffer the whole image... but i think that finding a way to decode chunks in finished RGB will cost less code than building greyscale scalers on color targets would. they smooth scalers cost ~1.5KB on greyscale targets |
| 08:02:03 | Unhelpful | s/they/the/ |
| 08:03:17 | saratoga | i wonder if theres any other projects or libraries we could look at to see what they do |
| 08:03:50 | Unhelpful | hard to say, if they're designed for a PC, i doubt they'll have the same design constraints as us :/ |
| 08:06:37 | | Quit saratoga ("CGI:IRC (EOF)") |
| 08:09:57 | | Quit bertrik (Remote closed the connection) |
| 08:11:16 | | Join Rob2223 [0] (n=Miranda@p4FDCEE5B.dip.t-dialin.net) |
| 08:12:07 | | Join lucent [0] (n=eshattow@75-174-180-52.chyn.qwest.net) |
| 08:15:47 | Minthe | Is there any hope to get png viewer? |
| 08:16:08 | lucent | decoder code needs to be written |
| 08:16:25 | lucent | I don't know of any technical reason it can't be done by a motivated coder |
| 08:17:04 | lucent | it just hasn't been done yet AFAIK |
| 08:17:16 | Minthe | Is there any memory issues? |
| 08:17:17 | | Quit mud-rb (Read error: 54 (Connection reset by peer)) |
| 08:17:43 | lucent | png relies on zlib, I think |
| 08:17:53 | lucent | I'm not much of a coder myself so I don't know the details |
| 08:19:46 | Unhelpful | Minthe: memory issues are very much something that can be dealt with. on targets where you get enough of it, you can use the plugin buffer. on others, you'll have to borrow it from the audio buffer. |
| 08:28:40 | | Quit Rob2222 (Read error: 110 (Connection timed out)) |
| 08:36:06 | | Quit midgey () |
| 08:39:15 | | Join midgey [0] (n=tjross@c-71-205-31-207.hsd1.mi.comcast.net) |
| 08:41:18 | *** | Saving seen data "./dancer.seen" |
| 08:57:25 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 09:00 |
| 09:01:07 | | Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) |
| 09:04:01 | amiconn | midgey: Are all those wma fixes going into the 3.1 branch as well? |
| 09:05:44 | midgey | r19503 doesn't really have any fixes |
| 09:06:10 | midgey | saratoga already committed up to r19498 |
| 09:06:27 | midgey | r19000 and r19502 can probably go in |
| 09:06:41 | | Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) |
| 09:08:41 | Unhelpful | amiconn: would you be able to give me a hand with a test plugin for 8-bit greyscale bitmaps loads? as far as i know, the loading works, but i seem to be stuck a little bit with greylib itself... |
| 09:12:15 | * | midgey sleeps |
| 09:12:18 | | Quit midgey () |
| 09:12:59 | lucent | ls |
| 09:13:02 | * | lucent fails |
| 09:21:30 | Unhelpful | nevermind... got it :D |
| 09:21:45 | | Join Nibbler [0] (n=Nibbler@e181121173.adsl.alicedsl.de) |
| 09:24:02 | amiconn | Unhelpful: What was the problem? Perhaps the greylib and/or its documentation can be improved a bit? |
| 09:24:45 | Unhelpful | amiconn: trouble was my not understanding the buffered/unbuffered modes, and the business of different draw functions for each... unless i misunderstand how i fixed it. |
| 09:27:16 | amiconn | ah |
| 09:27:48 | | Quit BHSPitLappy (Remote closed the connection) |
| 09:28:32 | amiconn | The 2 modes might need a bit more documentation. Basically unbuffered mode exists in order to save some ram if you only need bitmap drawing |
| 09:28:38 | Unhelpful | in any case, i added a scaler output plugin for greylib, and a test viewer plugin that loads and displays a bitmap scaled+centered |
| 09:29:46 | Unhelpful | i'll pop it onto FS in a minute, and try to ping some people with grayscale hardware, i suppose... but it does pretty much everything we'd talked about, i think :D |
| 09:29:57 | amiconn | It's also a bit faster since it avoid the extra copy |
| 09:30:09 | amiconn | *avoids |
| 09:31:38 | Unhelpful | amiconn: maybe we should have the buffered functions call the unbuffered ones if the buffer is NULL? |
| 09:32:55 | amiconn | That'd mean more of the code is linked to the plugin |
| 09:36:10 | Unhelpful | hrm, good point. probably no better way to do it than what we've got now, then. |
| 09:36:47 | amiconn | Imo there's no need, since a plugin will either use buffered mode or unbuffered mode, never both. What could be done though in order to help debugging is checking for NULL and printing a helpful DEBUGF() message if it is. Only in the sim of course |
| 09:37:33 | Unhelpful | hrm, yes, that would be good. do we have a doc for greylib, besides the sources? |
| 09:39:47 | amiconn | Source only atm; there are longish comments for most public functions. GraphicsAPI wiki page also applies, of course |
| 09:41:19 | | Quit jhulst (Remote closed the connection) |
| 09:42:28 | Unhelpful | hrm, do i have to create a task before i can add dependencies on other tasks? |
| 09:42:52 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 09:46:51 | | Quit jhulst (Read error: 60 (Operation timed out)) |
| 09:50:25 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 09:56:42 | Unhelpful | up as FS #9683, if somebody with greyscale targets wants to test it |
| 10:00 |
| 10:04:20 | | Join n1s [0] (n=nils@rockbox/developer/n1s) |
| 10:22:48 | n1s | jhMikeS: about to test the beast charging patch, anything in particular to look for? |
| 10:24:25 | | Quit jhulst (Read error: 131 (Connection reset by peer)) |
| 10:25:14 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 10:36:34 | | Join planetbeing [0] (n=planetbe@c-71-235-96-172.hsd1.ct.comcast.net) |
| 10:41:20 | *** | Saving seen data "./dancer.seen" |
| 10:44:00 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 10:45:58 | | Join fredddy [0] (n=freddy@p3E9E3319.dip0.t-ipconnect.de) |
| 10:47:01 | | Join EspeonEefi [0] (i=eefi@SAFFRONCITY.MIT.EDU) |
| 10:47:34 | | Quit bmbl (Client Quit) |
| 10:51:30 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 10:58:36 | | Quit maddler ("Lost terminal") |
| 11:00 |
| 11:01:28 | | Join _lifeless [0] (n=lifeless@90.151.222.100) |
| 11:03:40 | | Quit Minthe ("Leaving...") |
| 11:07:01 | | Join Acksaw [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com) |
| 11:11:20 | jhMikeS | n1s: I put instructions in the FS task . :) |
| 11:15:16 | n1s | ok, already started charging with AC |
| 11:18:11 | | Quit __lifeless (Read error: 110 (Connection timed out)) |
| 11:23:34 | | Join {phoenix} [0] (n=dirk@p54B45D4C.dip.t-dialin.net) |
| 11:33:30 | | Join miepchen^schlaf [0] (n=miepel@p579EC669.dip.t-dialin.net) |
| 11:34:20 | | Join PaulJam [0] (n=pauljam@p54BED510.dip.t-dialin.net) |
| 11:34:25 | | Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) |
| 11:39:30 | | Join gregzx [0] (n=chatzill@dsk227.neoplus.adsl.tpnet.pl) |
| 11:41:04 | | Quit alexbobp (Read error: 104 (Connection reset by peer)) |
| 11:45:32 | | Quit JdGordon (Remote closed the connection) |
| 11:45:52 | | Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) |
| 11:58:00 | | Quit JdGordon (Remote closed the connection) |
| 11:58:14 | | Join stoffel_ [0] (n=sfr@p57B4E146.dip.t-dialin.net) |
| 11:58:21 | | Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) |
| 11:58:57 | | Join Schmogel [0] (n=Miranda@p3EE21D48.dip0.t-ipconnect.de) |
| 12:00 |
| 12:01:25 | Unhelpful | amiconn: about buffered vs unbuffered greylib... is there any practical difference between using buffered mode, drawing, and calling update, and rendering into a greyscale bitmap buffer in the plugin, then using grey_ub_gray_bitmap to draw that to the screen? |
| 12:02:00 | Unhelpful | the practical difference, i'd think, would be mainly in availability of the other drawing functions for buffered updates? |
| 12:03:39 | | Join Acky [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com) |
| 12:03:46 | | Join faemir [0] (n=faemir@88-106-244-173.dynamic.dsl.as9105.com) |
| 12:04:10 | Unhelpful | trying to figure out how best to do greylib pictureflow :/ |
| 12:09:29 | | Join Minthe [0] (n=Minthe@KD124214153219.ppp-bb.dion.ne.jp) |
| 12:11:58 | amiconn | If you need a fullscreen buffer anyway there shouldn't be a significant difference |
| 12:12:00 | | Quit PaulJam (".") |
| 12:13:51 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
| 12:14:02 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
| 12:14:25 | amiconn | There are some situations where using the unbuffered version is better, e.g. when just a partial buffer is used (mandelbrot) it saves ram |
| 12:14:51 | amiconn | mandelbrot wouldn't be possible in buffered mode on archos, at least not without stopping playback |
| 12:15:43 | amiconn | Unbuffered mode needs 14KB of buffers on archos (+some), buffered mode needs 21KB. The whole plugin buffer is 32KB, so go figure... |
| 12:16:19 | | Quit Acksaw (Connection timed out) |
| 12:17:51 | | Quit JdGordon (Remote closed the connection) |
| 12:17:54 | Unhelpful | ok, issues i see here is that it writes directly to an offscreen buffer to draw the covers, but uses the API functions to write text. greylib supports using only part of the screen, right? |
| 12:18:12 | | Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) |
| 12:19:13 | Unhelpful | maybe best bet would be LCD drawing functions for text, offscreen buffer of its own for the PF rendering, and grey_ub_gray_bitmap to render that into the greylib buffer? |
| 12:19:18 | amiconn | yes, although the choice of bondaries is restricted |
| 12:19:42 | Unhelpful | hrm... how, specifically? |
| 12:19:49 | amiconn | It can only split at pixel packing boundaries |
| 12:20:02 | amiconn | (the lib rounds automatically) |
| 12:20:32 | | Quit Minthe ("Leaving...") |
| 12:20:47 | Unhelpful | so, from 1px to 8px alignment vertically, depending on target, and from 1px to 4px alignment horizontally? |
| 12:20:47 | amiconn | Why does picureflow render to an offscreen buffer, btw? |
| 12:20:59 | amiconn | Imo it would be better to render directly to the framebuffer |
| 12:21:09 | | Join Minthe [0] (n=Minthe@KD124214153219.ppp-bb.dion.ne.jp) |
| 12:22:25 | Unhelpful | ...i'm digging a bit further. its buffer is rb->lcd_framebuffer, actually |
| 12:23:32 | Unhelpful | is that an in-memory buffer for the data currently on-screen, or an offscreen buffer that's copied onscreen by lcd_update? |
| 12:24:51 | amiconn | The latter. |
| 12:25:59 | amiconn | The currently displayed image is stored in the lcd controller's internal memory, which isn't memory mapped hence can't be written directly |
| 12:26:23 | amiconn | This applies to any target I know |
| 12:26:52 | | Quit Acky (Read error: 104 (Connection reset by peer)) |
| 12:27:13 | | Join Acksaw [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com) |
| 12:30:49 | | Join moos [0] (i=Mustapha@rockbox/staff/moos) |
| 12:33:48 | Unhelpful | it doesn't seem too easy to draw via direct writes to greylib's buffer, unless i'm misreading? i'm still thinking that grey_ub_gray_bitmap draws from an offscreen buffer where we do the rendering are probably the way to go for PF, along with setting aside some lines at the bottom for the album text, and switching to normal LCD mode for the menu and tracklist |
| 12:34:36 | | Join Jaykay [0] (n=chatzill@p579E7EB7.dip.t-dialin.net) |
| 12:34:46 | | Quit stoffel_ (Read error: 113 (No route to host)) |
| 12:36:57 | Jaykay | because nobody of those evil developers cared about my nice reminder, ill suggest committing of http://www.rockbox.org/tracker/2533 here in irc |
| 12:38:35 | amiconn | That would work of course. Just take care to avoid all lcd functions which directly access the lcd while the greylib overlay is running. This includes lcd_update() - so in order to print the album text, you need to use grey_deferred_lcd_update() instead |
| 12:40:37 | Unhelpful | no problem. probably not going to get anywhere on this today, so for now the only thing using the new greylib scaling support is a crummy bmp viewer test app |
| 12:40:41 | amiconn | The horizontal alignment for 2bpp horizontally-packed lcds is 8px, btw. This is because those lcds use 16 bit transfers |
| 12:41:01 | Unhelpful | which, with the *third* patch, is actually there |
| 12:41:21 | *** | Saving seen data "./dancer.seen" |
| 12:43:45 | | Join mud-rb [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) |
| 12:44:50 | | Quit tvelocity (Remote closed the connection) |
| 12:45:02 | Unhelpful | i'm not worried about horizontal res, the pictureflow effect is edge-to-edge, and i'll just restrict album titles to a designated area at the screen bottom, and make it N*8px |
| 12:46:04 | amiconn | Rather make the upper (greylib) area N*8px |
| 12:47:22 | Unhelpful | that's fine too. i'm packing up for now, but if anything occurs to you that might be a good idea on how to handle some part of this, i'll check the logs whenever i get back. |
| 12:47:34 | amiconn | There are 2 targets where the lcd height isn't a multiple of 8. It wouldn't matter for those (mini G1 and G2 -> horizontal pixel packing), but I think it's better to stay safe |
| 12:53:07 | | Join Darksair [0] (n=user@117.89.121.31) |
| 12:56:25 | | Quit jhulst (Read error: 60 (Operation timed out)) |
| 12:59:07 | | Join alexbobp [0] (n=alex@69.149.25.200) |
| 12:59:57 | | Quit Nibbler ("Ex-Chat") |
| 13:00 |
| 13:10:49 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 13:16:34 | | Join Rudy77 [0] (n=Rudy77@adsl-69-221-120-99.dsl.akrnoh.ameritech.net) |
| 13:18:17 | | Join Lss [0] (n=Lss@cm203.delta90.maxonline.com.sg) |
| 13:19:14 | n1s | jhMikeS: AC chargign worked nicely, stopped at 4.205V and had a peak temperature of 35C |
| 13:19:42 | n1s | with a standard battery AFAIK |
| 13:20:01 | | Join ito [0] (n=ito@adsl-68-248-72-20.dsl.sfldmi.ameritech.net) |
| 13:21:16 | | Quit ito ("Ex-Chat") |
| 13:23:25 | | Join AndyIL [0] (i=AndyI@212.14.205.32) |
| 13:24:17 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 13:29:11 | | Join herrwaldo [0] (n=waldo@ip-81-11-228-79.dsl.scarlet.be) |
| 13:33:00 | | Quit FOAD (Read error: 145 (Connection timed out)) |
| 13:33:00 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 13:34:43 | | Quit AndyI (Read error: 110 (Connection timed out)) |
| 13:36:34 | | Part Rudy77 |
| 13:39:08 | | Join B4gder [241] (n=daniel@rockbox/developer/bagder) |
| 13:46:32 | | Join gartral [0] (n=Gareth@75.33.70.77) |
| 13:46:46 | gartral | i have a bug... |
| 13:47:18 | * | scorche looks over at the bug tracker |
| 13:48:04 | scorche | go ahead and say what you have experienced, but i may just tell you to submit it tot he tracker =) |
| 13:48:20 | * | domonoky detects that the wheel on e200v2 really looks like it needs some enable pin set. (i can measure changing voltage at the output pin with the OF, but not with rockbox. ) |
| 13:49:23 | gartral | well, i did some searching there, but i thought ide confirm it here, before going through all that, when you try to set a rating for any song, a single popup appears wit "<No info>" and disapears , returning you to the WPS screen |
| 13:49:48 | scorche | ah...i dont think many of us here use ratings... |
| 13:50:30 | gartral | and for those of us that do? |
| 13:51:27 | scorche | if it isnt in the tracker, i would fiel a report if it isnt already in there...otherwise, i will fade into the background for someone else to speak up |
| 13:53:12 | scorche | it does the same for me, but as i have never used that feature, i have no idea if that is an intended function because there is something to do, etc |
| 13:54:55 | gartral | would that be user interface, or WPS? |
| 13:56:43 | scorche | i would put it under Database |
| 13:59:57 | gartral | oops |
| 14:00 |
| 14:00:19 | gartral | how do i edit it? |
| 14:01:50 | | Join BigBambi_ [0] (n=alex@72.198.66-86.rev.gaoland.net) |
| 14:02:05 | moos | gatral: done! |
| 14:02:25 | | Quit BigBambi ("Please insert girder") |
| 14:03:11 | gartral | thank you for repairing my itchy trigger fingers mistake |
| 14:04:28 | moos | don't worries; no problems |
| 14:05:48 | | Quit jhMikeS (Nick collision from services.) |
| 14:05:54 | | Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) |
| 14:06:17 | gartral | and i see a typo now, i put "on" instead of "only" |
| 14:08:02 | * | scorche fixed 3 typos ;) |
| 14:08:39 | gartral | thanks scorche, im sorry to have to create o much work for yoo |
| 14:08:43 | gartral | you* |
| 14:09:01 | n1s | gartral: is your bug different to http://www.rockbox.org/tracker/task/9654 ? |
| 14:09:22 | scorche | n1s: looks the same to me |
| 14:09:42 | gartral | nope, tat workaround doesnt work for me |
| 14:09:56 | gartral | that* (smegging keyboard) |
| 14:10:13 | gartral | other than that, no difference |
| 14:10:20 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
| 14:10:33 | n1s | ok, and you have enabled "Gather runtime data" and initialized the database? |
| 14:10:37 | scorche | however, the "bug" is the same...perhaps a comment would be better saying that you ahve the same bug, but the workaround does not work |
| 14:10:57 | scorche | n1s: the option isnt even there if you have not enabled gather runtime data |
| 14:11:03 | n1s | oh |
| 14:11:15 | gartral | and also, i just tryed setting the rateing with winamp. that resulted in the player freezeing on that particular track |
| 14:11:52 | gartral | er, after reloading it too the player, that is :) |
| 14:12:55 | | Quit alexbobp (Read error: 104 (Connection reset by peer)) |
| 14:12:57 | domonoky | /me detects that with rockbox i can also measure voltage changeing on the wheel of e200v2, but its only 0V - 0.5V, while the OF has 0-3V ... |
| 14:13:03 | n1s | gartral: that sounds like a separate bug, please file it and attach the file if it's reproducible |
| 14:13:25 | scorche | i dont think our implementation of rating is consistent with the tags, but i am not too sure.. |
| 14:13:41 | n1s | gartral: i get the same behaviour like you with setting song ratign if i have not initialized the database, have you initalized yours? |
| 14:14:10 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 14:14:11 | n1s | scorche: afaik we never save/read rating from the actual file |
| 14:14:20 | gartral | yes, and its set to auto update |
| 14:14:30 | * | scorche nods at n1s |
| 14:15:04 | gartral | then why would it freeze after winamps rating tag was applied to it? |
| 14:15:16 | n1s | bugs? |
| 14:17:07 | gartral | humm, i cant find any indication that the database initilises at boot, even when set to auto update |
| 14:17:24 | scorche | it only needs t be initialized once |
| 14:17:27 | gartral | [i know, speeling is horrible today] |
| 14:17:51 | * | domonoky measures more: the OF also has 0-0.5V if the Display is off (same as rockbox). With display on, i get 0-3V in the OF and 0-1V in rockbox. |
| 14:18:25 | | Quit B4gder ("It is time to say moo") |
| 14:19:38 | | Quit BigBambi_ (Remote closed the connection) |
| 14:20:08 | n1s | gartral: can you browse the database on the player? |
| 14:21:09 | Lss | i have some file titles that only show up partially both from database and filesystem |
| 14:21:13 | Lss | how can i fix it |
| 14:21:45 | gartral | n1s: yea, its a tad jumbled, but thats par for my player |
| 14:21:53 | | Join stoffel_ [0] (n=sfr@p57B4E146.dip.t-dialin.net) |
| 14:22:02 | J-23 | who's Display? :P |
| 14:22:38 | n1s | gartral: if you can browse it, it must have initialized at some point so, your bug is different from another minor one i found regarding the rating... |
| 14:23:31 | n1s | Lss: what do you mean by "file titles"? the only thing that will show up in the filebrowser is the file name. |
| 14:23:38 | gartral | n1s: hmm, i wonder whats causeing this |
| 14:24:36 | n1s | gartral: is rockbox consistently freezing when you try to play the file modified by winamp? |
| 14:25:05 | gartral | it did it twice, then i deleted it |
| 14:25:25 | n1s | that doesn't help in fixing the bug... |
| 14:25:35 | gartral | want me to try again? |
| 14:25:40 | n1s | please do |
| 14:25:50 | gartral | lol, one step ahead |
| 14:26:07 | gartral | oddly enough, this it plays |
| 14:26:15 | gartral | this time* |
| 14:26:24 | Lss | the tags are obtained from the filename |
| 14:26:35 | jhMikeS | n1s: was that reading after the charger stopped? |
| 14:26:40 | gartral | and audiocis coheriant |
| 14:27:04 | n1s | jhMikeS: i wasn't looking at the time but the highest value in the graph was 4.205V |
| 14:27:15 | | Quit Schmogel (Read error: 104 (Connection reset by peer)) |
| 14:27:15 | gartral | [please excuse my poor typing today] |
| 14:28:11 | | Join alexbobp [0] (n=alex@69.149.25.200) |
| 14:28:29 | jhMikeS | n1s: then that would be with charger on which is expected. |
| 14:28:37 | | Join BigBambi [0] (n=alex@72.198.66-86.rev.gaoland.net) |
| 14:30:56 | gartral | just as a side note: would it be possible to add something to control the length of time the fade in/out function lasts? or is this here and im just blind and stupid? |
| 14:31:09 | Lss | huh i thought its there |
| 14:31:21 | n1s | gartral: which fade? |
| 14:31:37 | n1s | jhMikeS: ok, will you commit soon then? :) |
| 14:31:52 | gartral | backlight fadeing, on E250 V1, most recent build |
| 14:32:42 | n1s | gartral: it's fixed duration because of the low number of possible levels so longer duration would flicker |
| 14:33:11 | gartral | ahh hah, is this in the NO DO, or can I possibly add that one? |
| 14:33:37 | jhMikeS | n1s: soon, yes. I'm just looking it over some more to make sure. |
| 14:34:06 | BigBambi | gartral: You can add it for yourself, but I would guess it is unlikely to get in |
| 14:34:08 | n1s | sounds good, looks like we can call it "supported" soon then :) |
| 14:35:27 | * | jhMikeS is just wondering if some minor concessions in powermgmt.c violate feature feeziness |
| 14:36:07 | * | moos thnks we can change the topic, freeze is overv :) |
| 14:36:13 | moos | -v |
| 14:36:14 | gartral | BigBambi: ok, logical question would be: is the limited number of "levels" a mendable problem, or is it a hardware restriction? |
| 14:37:32 | BigBambi | often hardware |
| 14:37:39 | BigBambi | but I think it depends on target |
| 14:38:43 | gartral | hmm, wouldnt be too easy to determin that, would it? |
| 14:38:56 | moos | BgBambi: could you change the #rockbox topic, freeze is over...; hi btw |
| 14:39:11 | * | moos canot type neither today |
| 14:39:22 | BigBambi | moos: I can't, no |
| 14:39:33 | BigBambi | moos: but scorche can :) |
| 14:39:48 | Mode | "#rockbox +o scorche " by ChanServ (ChanServ@services.) |
| 14:39:50 | | Quit stoffel_ ("Lost terminal") |
| 14:39:57 | moos | ok :) |
| 14:40:04 | Topic | "Please read before speaking: http://www.rockbox.org/wiki/IrcGuidelines | Please direct offtopic/social chat to #rockbox-community | 3.1 is branched!" by scorche (i=Blah@rockbox/administrator/scorche) |
| 14:40:11 | Mode | "#rockbox -o scorche " by ChanServ (ChanServ@services.) |
| 14:40:26 | BigBambi | gartral: You could have a look at the code to see I'd imagine |
| 14:40:28 | * | jhMikeS generally logs in automatically and so rarely sees the IRC topic...ever |
| 14:40:43 | gartral | i would if i could understand it... |
| 14:40:45 | scorche | /topic ! ;) |
| 14:40:55 | BigBambi | gartral: hehe :) |
| 14:41:14 | * | jhMikeS should probably do /topic at least once a day |
| 14:41:22 | *** | Saving seen data "./dancer.seen" |
| 14:41:46 | gartral | plus my comp over heat if i try and compile anything more comples then and oga|mp3 file |
| 14:42:06 | gartral | heats* |
| 14:42:18 | gartral | complex* >.< |
| 14:42:56 | * | jhMikeS also knew about /topic btw :) simple laziness |
| 14:44:07 | moos | scorche: thanks, last freeze/release was indicated on rockbox.org, not this time |
| 14:44:26 | | Nick gartral is now known as Gartral (n=Gareth@75.33.70.77) |
| 14:47:15 | | Quit BigBambi (Remote closed the connection) |
| 14:48:28 | | Join BigBambi [0] (n=alex@72.198.66-86.rev.gaoland.net) |
| 14:51:23 | | Join Schmogel [0] (n=Miranda@p3EE21D48.dip0.t-ipconnect.de) |
| 14:51:38 | | Join Horschti [0] (n=Horscht@p4FD4C8CF.dip.t-dialin.net) |
| 14:51:52 | n1s | hmm, the "Anti skip buffer" description in the manual is both very long and confusing... |
| 14:51:54 | | Quit Horscht (Nick collision from services.) |
| 14:54:37 | | Quit fredddy (Read error: 110 (Connection timed out)) |
| 14:54:51 | | Join fredddy [0] (n=freddy@p3E9E3008.dip0.t-ipconnect.de) |
| 14:58:17 | | Quit miepchen^schlaf (Read error: 104 (Connection reset by peer)) |
| 14:58:58 | Gartral | where in the smegging source can i find the call to fade the backlight? |
| 14:59:49 | fdinel | Domonoky: I sent you the disassembly :) |
| 14:59:55 | n1s | any opinions on replacing the current description with this http://pastebin.com/m6463db38 ? |
| 15:00 |
| 15:00:09 | domonoky | fdinel: thanks.. |
| 15:00:50 | | Join miepchen^schlaf [0] (n=miepel@p579EC669.dip.t-dialin.net) |
| 15:00:53 | BigBambi | n1s: Sounds fine |
| 15:01:18 | n1s | BigBambi: cool :) |
| 15:01:42 | BigBambi | Perhaps add a bit about keeping it as low as possible? |
| 15:02:35 | BigBambi | "However a high value increases how often the buffer has to be refilled, and thus reduces battery life somewhat. It is therefore desirable to keep this setting as low as possible without skips occuring."? |
| 15:02:45 | BigBambi | maybe something like that |
| 15:02:45 | domonoky | fdinel: and it would be very nice, if you could take a look at where the wheel is read. I hope to find some time to work on this over the next days. |
| 15:04:38 | Gartral | nvm, im totally efing retarded |
| 15:06:34 | BigBambi | n1s: I take it you either didn't see or didn't agree with my last comment? :) |
| 15:07:37 | n1s | BigBambi: ah, missed it, there is a note about the battery life but maybe your way is better... |
| 15:07:47 | BigBambi | I'm not sure |
| 15:07:54 | BigBambi | Let me have a look at what is there now |
| 15:09:10 | BigBambi | n1s: Ah no, what is there is fine I think |
| 15:09:20 | BigBambi | n1s: I just missed the note first time round |
| 15:09:48 | n1s | ok, will commit to the branch too then, thanks for looking :) |
| 15:10:59 | Gartral | i cant even find the part where the backlight is defined... |
| 15:12:19 | | Quit n1s () |
| 15:13:37 | Gartral | i see where its mentioned, and called, but not where its defined |
| 15:19:11 | domonoky | Gartral: you mean the actual functions to disable/enable the backligt ? take a look a the target tree.. |
| 15:23:03 | Gartral | hmm, i cant see a way to modify thecode to make a coherient fade timer, though i suspect it would be possible if you found a way to freeze the backlight switch as it steps down |
| 15:27:34 | Gartral | im not gonna bother butchering the code, especially when i cant compile it myself |
| 15:30:00 | | Quit faemir (Remote closed the connection) |
| 15:31:50 | Minthe | Umm, there are still some craps in wma files, so I have to talk with saratoga... |
| 15:34:34 | | Quit Minthe ("Leaving...") |
| 15:34:47 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 15:36:34 | domonoky | Gartral: if you dont want to "butcher" (what ever that is) the code, why are telling it to us ? And compiling isnt difficult... there are various Howtos in the wiki. |
| 15:39:13 | Gartral | its not that, its that by the time im done, it wouldnt work, anyway, and the compileing issue is not that its difficut, its that my comp overheats when it trys to compile anything |
| 15:44:58 | | Quit courtc (Read error: 60 (Operation timed out)) |
| 15:45:01 | | Join courtc [0] (n=court@unaffiliated/courtc) |
| 15:57:16 | | Join frinkazoid [0] (n=waldo@ip-81-11-230-38.dsl.scarlet.be) |
| 15:57:20 | | Join lasser [0] (n=chatzill@Wb869.w.pppool.de) |
| 16:00 |
| 16:02:20 | | Join Aurix_Lexico [0] (n=comrade@c-68-56-205-239.hsd1.fl.comcast.net) |
| 16:08:18 | soap | that's an underlying issue which should be addressed independently of any desire to work with Rockbox |
| 16:11:18 | | Quit herrwaldo (Connection timed out) |
| 16:11:40 | | Quit Jaykay ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") |
| 16:14:42 | | Part Gartral |
| 16:23:07 | | Quit mud-rb (Read error: 113 (No route to host)) |
| 16:39:13 | | Quit Darksair ("Do you hear that? This is the sound of inevitability. This is the sound of your death, Mr. Anderson.") |
| 16:39:47 | J-23 | hm, does Rockbox use anything like swapfile on targets with small RAM? |
| 16:41:26 | *** | Saving seen data "./dancer.seen" |
| 16:41:50 | soap | swapping what? |
| 16:43:20 | | Quit Llorean (Read error: 104 (Connection reset by peer)) |
| 16:44:04 | BigBambi | J-23: We want to buffer audio in memory so that the disk doesn't have to be spun up - swapping to disk would defeat the point |
| 16:45:12 | | Join saratoga [0] (n=41becb3b@gateway/web/cgi-irc/labb.contactor.se/x-05ae7e7a3b055ce4) |
| 16:45:49 | soap | example: Load encoded (MP3, etc) file into ram, decode PCM to disk, remove encoded file from RAM, load decoded PCM to RAM, lots of disk. Better to just work with smaller pieces of audio. |
| 16:46:20 | | Join Llorean [0] (n=DarkkOne@adsl-65-68-72-166.dsl.hstntx.swbell.net) |
| 16:46:27 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
| 16:47:09 | | Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) |
| 16:48:51 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
| 16:49:40 | | Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") |
| 16:53:42 | | Quit vitja (Read error: 104 (Connection reset by peer)) |
| 16:57:51 | | Join thresh [0] (n=popa3d@videolan/developer/thresh) |
| 16:58:00 | | Part thresh |
| 17:00 |
| 17:05:08 | | Join tvelocity [0] (n=tony@athedsl-413299.home.otenet.gr) |
| 17:23:22 | | Nick JdGordon is now known as JdGordon|zzz (n=jonno@rockbox/developer/JdGordon) |
| 17:30:58 | | Join n1s [0] (n=nils@rockbox/developer/n1s) |
| 17:39:30 | bluebrother | XavierGr: interested in updating the greek rbutil translation? Would be nice to have it updated before creating new binaries |
| 17:39:54 | XavierGr | sure, when are you going to build the binaries? |
| 17:41:33 | bluebrother | most likely this evening −− not sure if I have access to my windows build box the next couple of days |
| 17:41:57 | XavierGr | ok let me remember how to do it and will do it asap |
| 17:41:59 | bluebrother | considered putting the machine on a usb stick but forgot that FAT32 can't handle 5GiB files :( |
| 17:42:08 | XavierGr | do you know how many missing strings are there? |
| 17:42:19 | | Part XavierGr |
| 17:42:24 | bluebrother | just use linguist from the Qt installation ;-) |
| 17:42:42 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
| 17:42:53 | XavierGr | ok will do |
| 17:43:11 | moos | XavierGr: http://www.rockbox.org/twiki/bin/view/Main/RockboxUtilityDevelopment#Translation_status_updated_2008 |
| 17:43:32 | XavierGr | thanks |
| 17:43:33 | bluebrother | according to the stats on RockboxUtilityDevelopment currently 102. But it might be possible to reuse old strings −− you should keep an eye on the "suggestions" pane on the bottom in linguist |
| 17:44:40 | | Quit killan ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") |
| 17:47:04 | | Join kushal_12_27_200 [0] (n=kushal@c-71-230-163-208.hsd1.pa.comcast.net) |
| 17:49:47 | | Quit n1s () |
| 17:57:32 | | Join ZincAlloy [0] (n=d9eec502@gateway/web/cgi-irc/labb.contactor.se/x-f2583d1bb8b191de) |
| 17:57:33 | kugel | fdinel: hi :) |
| 17:58:59 | fdinel | hey kugel |
| 18:00 |
| 18:00:37 | kugel | fdinel: thanks again for your disasm, I'm still in the process of understanding the code, but I got most ;) |
| 18:01:23 | kugel | fdinel: What I'd find interesting would be if this func is called in an isr or in a tick task. I found only 1 reference to that function in objdump's disasm |
| 18:02:19 | fdinel | kugel: yeah well it's called in the "user interface" task (thread), which makes sense ;) |
| 18:02:27 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 18:02:40 | kugel | fdinel: so in in an isr? |
| 18:02:45 | fdinel | (well not directly but still) |
| 18:02:57 | kugel | I mean it can be both together |
| 18:03:10 | fdinel | not an ISR no, but a thread which is called once every x time |
| 18:03:20 | | Join Acky [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com) |
| 18:03:26 | kugel | that's a tick task ;) |
| 18:04:01 | fdinel | yep :P |
| 18:07:11 | kugel | fdinel: the BOP_CTRL_REG- DBOP_CTRL_REG stuff is quite confusing |
| 18:07:34 | kugel | I mean those "#(DBOP_CTRL_REG - DBOP_CTRL_REG)]" |
| 18:07:37 | XavierGr | bluebrother: what's the string "progresswindow" under ProgressLoggerFrm? Am I supposed to conatenate these 2 words? |
| 18:08:22 | kugel | I'd think that equals to #0, but it doesn't. the objdump disasm is clearer here |
| 18:10:25 | | Join toffe82 [0] (n=chatzill@75.12.168.247) |
| 18:11:51 | | Quit Acksaw (Read error: 145 (Connection timed out)) |
| 18:11:52 | bluebrother | XavierGr: that's from an accessibility description. I think this needs to get cleaned up −− it isn't shown anywhere so you could simply ignore it |
| 18:12:47 | domonoky | bluebrother: it isnt shown, but it gets voiced :-) |
| 18:14:03 | | Join killan [0] (n=nnscript@c-415472d5.06-397-67626721.cust.bredbandsbolaget.se) |
| 18:16:08 | XavierGr | so should I keep it together or as saperate words? |
| 18:16:13 | XavierGr | or ignore it? |
| 18:16:57 | kugel | fdinel: bpl is branched if bit 31 is, right? |
| 18:17:07 | kugel | bit 31 is 0 i mean |
| 18:17:57 | kugel | well, if the N flag isn't set, so yes, 0 |
| 18:18:31 | | Quit killan (Client Quit) |
| 18:18:43 | | Join killan [0] (n=nnscript@c-415472d5.06-397-67626721.cust.bredbandsbolaget.se) |
| 18:24:02 | | Join karashata [0] (n=karashat@69.41.192.215) |
| 18:24:16 | | Quit {phoenix} (Remote closed the connection) |
| 18:32:27 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 18:33:10 | | Quit beta2k_ (Read error: 110 (Connection timed out)) |
| 18:38:02 | | Quit saratoga ("CGI:IRC (EOF)") |
| 18:41:30 | *** | Saving seen data "./dancer.seen" |
| 18:42:20 | | Quit Schmogel (Read error: 110 (Connection timed out)) |
| 18:51:33 | | Quit ZincAlloy ("CGI:IRC (Ping timeout)") |
| 18:56:21 | | Quit karashata ("G'bye everyone!") |
| 19:00 |
| 19:13:09 | | Join karashata [0] (n=karashat@69.41.192.215) |
| 19:14:32 | | Join PaulJam [0] (n=pauljam@p54BED00D.dip.t-dialin.net) |
| 19:21:19 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 19:21:23 | | Quit tvelocity (Remote closed the connection) |
| 19:23:10 | XavierGr | bluebrother: how much time do I still have? I need to finish 22 strings. |
| 19:37:56 | | Join Schmogel [0] (n=Miranda@p3EE21C0D.dip0.t-ipconnect.de) |
| 19:40:53 | | Quit jhMikeS (Nick collision from services.) |
| 19:40:59 | | Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) |
| 19:41:53 | | Quit karashata ("G'bye everyone!") |
| 19:44:23 | | Join karashata [0] (n=karashat@69.41.192.215) |
| 19:47:06 | kugel | SUCCESS!!!!!!! |
| 19:48:25 | domonoky | kugel: buttons with dbop ? |
| 19:48:25 | kugel | domonoky: ping |
| 19:48:30 | kugel | heh |
| 19:48:31 | kugel | yes |
| 19:48:37 | | Quit gromit` (Read error: 60 (Operation timed out)) |
| 19:48:49 | domonoky | congratulations ! :-) |
| 19:49:06 | kugel | http://pastebin.ca/1290294 |
| 19:49:44 | | Quit kushal_12_27_200 ("Leaving") |
| 19:49:46 | kugel | purely based on disassembly |
| 19:51:34 | kugel | now I need to find which bit is which button |
| 19:56:30 | | Join gromit` [0] (n=gromit@ALagny-154-1-67-253.w86-203.abo.wanadoo.fr) |
| 19:58:33 | | Quit PaulJam (".") |
| 19:58:54 | domonoky | kugel: with this code i can only detect power and down again. Can you read all buttons on fuze with this ? |
| 20:00 |
| 20:00:07 | bluebrother | XavierGr: no hurry ... I guess I won't start building the next 3 hours. Maybe I can get it done tomorrow morning instead, need to check my timetable |
| 20:00:32 | kugel | domonoky: I haven't yet looked at the return too much, but I can surely say hold button can be detected too |
| 20:00:48 | | Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) |
| 20:04:22 | | Join Acksaw [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com) |
| 20:07:07 | | Join Strife89 [0] (n=michael@204.116.245.152) |
| 20:08:46 | * | lucent raises an eyebrow with interest |
| 20:10:40 | | Quit Acky (Read error: 60 (Operation timed out)) |
| 20:10:46 | | Join Acky [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com) |
| 20:15:53 | | Quit Strife89 ("Bye people.") |
| 20:15:59 | XavierGr | bluebrother: FS #9688, didn't manage to compile rbutil to be sure that it works though. I just run linguist and updated the missing strings. Will try again later this night |
| 20:16:07 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
| 20:19:49 | | Join {phoenix} [0] (n=dirk@p54B45D4C.dip.t-dialin.net) |
| 20:21:49 | domonoky | kugel: at least on e200v2, i can only detect power and down. no other button seems to work :-/ |
| 20:21:59 | kugel | domonoky: uhmm, I cannot seem to get only those 3 too |
| 20:22:45 | | Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-25c7af85b4685f94) |
| 20:23:30 | | Quit Acksaw (Connection timed out) |
| 20:23:51 | kugel | maybe we need to reset the input before |
| 20:25:42 | bluebrother | XavierGr: if linguist thinks the file is ok then there shouldn't be any issue. |
| 20:29:32 | | Join stoffel_ [0] (n=sfr@p57B4F801.dip.t-dialin.net) |
| 20:30:38 | | Quit {phoenix} (Remote closed the connection) |
| 20:31:41 | | Quit toffe82 (Read error: 110 (Connection timed out)) |
| 20:31:56 | | Part XavierGr |
| 20:32:02 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
| 20:40:22 | bluebrother | XavierGr: accepted and committed. Thanks for the fast update :) |
| 20:41:33 | *** | Saving seen data "./dancer.seen" |
| 20:46:31 | XavierGr | bluebrother: I should thank you, you are welcome too :) |
| 21:00 |
| 21:07:55 | | Join alexbobp_ [0] (n=alex@69.149.25.200) |
| 21:08:45 | | Join mc2739 [0] (n=mc2739@cpe-67-10-238-175.satx.res.rr.com) |
| 21:10:37 | | Join Kitti [0] (n=himka_co@195.5.125.25) |
| 21:10:57 | | Quit BHSPitLappy (Read error: 104 (Connection reset by peer)) |
| 21:13:40 | | Quit gevaerts (Nick collision from services.) |
| 21:13:49 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
| 21:18:38 | kugel | fdinel: hey, bad news |
| 21:21:26 | | Part Kitti |
| 21:24:08 | | Quit alexbobp (Connection timed out) |
| 21:30:10 | domonoky | bluebrother: when do you want to tag the new rbutil release ? (i can build the mac-binary either today, or tomorrow morning. After that, it gets difficult.) |
| 21:36:17 | | Join Zagor [242] (n=bjst@rockbox/developer/Zagor) |
| 21:43:39 | kugel | domonoky: it's a bit weird isn't it? we should get at least the buttons we get reading directly |
| 21:45:59 | | Quit karashata ("G'bye everyone!") |
| 21:53:56 | | Join {phoenix} [0] (n=dirk@p54B45D4C.dip.t-dialin.net) |
| 21:55:01 | | Join ZincAlloy [0] (n=d9eec502@gateway/web/cgi-irc/labb.contactor.se/x-95cf6fd063dc2513) |
| 21:57:49 | | Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) |
| 22:00 |
| 22:05:34 | | Join Martyn [0] (n=martinb@adsl-70-231-242-168.dsl.snfc21.sbcglobal.net) |
| 22:08:11 | | Join aneqrs [0] (n=andreas@c83-253-104-206.bredband.comhem.se) |
| 22:14:55 | bluebrother | domonoky: soonish, at least until midnight. |
| 22:15:13 | bluebrother | too bad the french translation hasn't been updated yet. |
| 22:15:31 | kugel | domonoky: do you get int_btn == 0 regulary? |
| 22:15:43 | kugel | I do, which shouldn't happen |
| 22:16:19 | domonoky | kugel: no, its always set to 843 if i dont press anything. |
| 22:16:54 | kugel | same for me, but completely 0 every 5th read or so |
| 22:20:05 | | Quit stoffel_ ("leaving") |
| 22:21:29 | | Part Martyn |
| 22:23:19 | | Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) |
| 22:29:57 | kugel | domonoky: any idea why we cannot read the buttons we get with direct gpio reading? maybe lcd is set up wrongly? |
| 22:34:44 | domonoky | kugel: no idea at moment.. |
| 22:39:13 | | Join MethoS- [0] (n=clemens@host-091-096-214-033.ewe-ip-backbone.de) |
| 22:40:05 | Unhelpful | amiconn: actually, i need to change my plan, the album art text *can* render over the images... it *looks* like the buffer for buffered greylib is still just W*H uint8, so i can probably draw to that, and then use greylib's puts, and then call grey_update()... this will also make pretty much everything the same as the color case, except for passing a plugin to the bitmap loader, the data type of the buffer, etc |
| 22:41:35 | *** | Saving seen data "./dancer.seen" |
| 22:47:49 | kugel | domonoky: have you put some delay between button_read_device? maybe it's just too fast so you don't se it returning 0 |
| 22:54:07 | Zagor | can someone tell me what the difference is between the watermarks in buffering.c and plaback.c? |
| 22:54:14 | | Quit Bensawsome (Nick collision from services.) |
| 22:55:39 | | Join mcuelenaere [0] (i=mcuelena@rockbox/developer/mcuelenaere) |
| 22:55:43 | | Quit BHSPitLappy (Remote closed the connection) |
| 22:56:50 | | Join Bensawsoj [0] (n=Bensawso@server.lethaltechnology.net) |
| 22:58:04 | | Quit Zagor ("Leaving") |
| 23:00 |
| 23:00:00 | | Quit Horschti ("I am root. If you see me laughing, you better have a backup") |
| 23:06:47 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
| 23:24:37 | | Quit fredddy (Read error: 110 (Connection timed out)) |
| 23:25:26 | | Join fredddy [0] (n=freddy@p3E9E2148.dip0.t-ipconnect.de) |
| 23:32:04 | * | bluebrother prepares releasing rbutil |
| 23:32:33 | bluebrother | or rather creating binaries to be released with Rockbox 3.1 |
| 23:32:52 | gevaerts | Great :) |
| 23:35:19 | | Join freddy__ [0] (n=freddy@p3E9E1FCE.dip0.t-ipconnect.de) |
| 23:38:50 | | Join hillshum [0] (n=hillshum@75-165-241-153.slkc.qwest.net) |
| 23:39:35 | Bagder | http://www.muppethouse.com/rockbox-i-hated-it-now-i-like-it/ |
| 23:39:49 | Bagder | a random friendly blog post |
| 23:45:16 | _Auron_ | I can't wait until v2s are supported.. everytime I unplug my sansa it spends about 3-4 minutes 'refreshing' |
| 23:45:20 | _Auron_ | even if I didn't change anything |
| 23:45:31 | | Nick alexbobp_ is now known as alexbobp (n=alex@69.149.25.200) |
| 23:45:57 | _Auron_ | that 10 seconds of boot time is nothing compared to that |
| 23:49:19 | | Join QUICKSTART [0] (n=QUICKSTA@pool-72-88-166-100.nwrknj.east.verizon.net) |
| 23:49:57 | | Quit fredddy (Read error: 110 (Connection timed out)) |
| 23:50:23 | | Quit EspeonEefi ("ăăăȘă") |
| 23:53:06 | | Nick Bensawsoj is now known as Bensawsome (n=Bensawso@server.lethaltechnology.net) |
| 23:55:26 | Unhelpful | hrm, is calling grey_show() slow at all if the state is not changing? |
| 23:55:30 | amiconn | Unhelpful: I can think of several possible solutions for this. First, we can declare the greylib's internal buffer to be publicly accessible. There's a potential caveat though - the overlay width and height are aligned (as explained earlier) and hence are not necessary equivalent to what was passed to the lib |
| 23:56:45 | amiconn | Second, it would also be possible to write some more unbuffered drawing functions. So far there just was no need though, and these functions would be somewhat more complex than the buffered ones |
| 23:56:46 | Unhelpful | so the internal buffer *is* uint8, but the width and height may have been rounded from the requested ones |
| 23:56:57 | amiconn | yes |
| 23:57:10 | Unhelpful | ok, i can work with that. |
| 23:57:25 | amiconn | Third (easiest), you could just use buffered mode, and live with the extra copying |
| 23:58:20 | Unhelpful | i think first is actually easiest, in this case, since once i fix up the rounded width/height, the greylib buffer in buffered "works" the same way as lcd_buffer |
icon identifies that the person is a core developer (has commit access).