| 00:00:34 | *** | Saving seen data "./dancer.seen" |
| 00:02:23 | | Join sustineo [0] (n=42116ef5@giant.haxx.se) |
| 00:02:27 | Vampireking | Hello i have a problem, i have moved some data on my sandisk sansa e260v2 from my microsd to the flash memory that was abortet with a sd transfer error. Now rockbox wont start and the original firmware says "Not enough space for music db please free up 90 mb" but the player wont detect on my pc anymore. I dont know how I can format my player now. I dont know if the recovery mode can help because the memory is full |
| 00:03:06 | funman | Vampireking: plug the e200v2 on USB and format the disk |
| 00:03:32 | Vampireking | hte player wont detect from my pc |
| 00:04:29 | funman | are you using windows ? |
| 00:05:06 | Vampireking | at the moment but i have kubuntu 09.10 installed |
| 00:05:24 | funman | the player doesn't appear in dmesg output ? |
| 00:05:27 | Vampireking | athe moment i using windows |
| 00:05:51 | Vampireking | i have a dmesg log |
| 00:06:03 | sustineo | linux typically detects better, you may want to at least try it in linux |
| 00:06:03 | funman | i don't remember having problems with corrupted filesystems, i could always format the player |
| 00:06:52 | Vampireking | i have tried but the player wont show up in linux |
| 00:06:59 | sustineo | hm |
| 00:07:26 | sustineo | wait, are you connecting to the pc w/ rockbox or default booted up? |
| 00:08:03 | | Quit sustineo ("CGI:IRC") |
| 00:08:04 | Vampireking | rockbox stops at the bootloader screen |
| 00:08:08 | | Join sustineo [0] (n=42116ef5@giant.haxx.se) |
| 00:08:23 | Vampireking | and the OF says Not enough space for music db please free up 90 mb |
| 00:08:36 | mc2739 | Vampireking: try removing your microsd card |
| 00:10:35 | mc2739 | Vampireking: anf then see if Rockbox will boot |
| 00:10:44 | mc2739 | /anf/and/ |
| 00:11:46 | Vampireking | i have tried it rockbox stops |
| 00:11:53 | Vampireking | here a dmesg log http://nopaste.info/e912d96c33.html |
| 00:12:11 | mc2739 | Vampireking: do you have a microsd card in the slot? |
| 00:12:29 | Vampireking | i have it removed |
| 00:12:49 | mc2739 | and Rockbox still will not boot? |
| 00:14:13 | | Quit sustineo ("CGI:IRC") |
| 00:14:48 | Vampireking | yes rockbox stops booting |
| 00:17:26 | Vampireking | here are part 2 of the dmesg log http://nopaste.info/0ec77d752b.html |
| 00:17:42 | mc2739 | Vampireking: The "Not enough space for music db please free up 90 mb" can be caused by a corrupt file system. You might try doing a file system check from your linux system. |
| 00:17:44 | stripwax | saratoga - sorry, back now. (although you seem to be gone now..). still calculating the tremor mul+add numbers |
| 00:17:52 | funman | sudo mkfs.vfat -F 32 /dev/sdb |
| 00:19:48 | pamaury | mkfs is an interesting way to check a filesystem... |
| 00:19:49 | Vampireking | how do I find out what the device under linux is my mp3 player |
| 00:20:41 | | Quit petur ("Zzzzz") |
| 00:22:57 | | Quit pamaury ("exit(*(int *)0 / 0);") |
| 00:23:24 | klapaucjusz | Vampireking: plug it in, then say dmesg | tail. |
| 00:25:21 | Vampireking | ok I try it |
| 00:25:24 | Vampireking | thank you |
| 00:26:46 | | Quit Vampireking ("Nettalk6 - www.ntalk.de") |
| 00:37:12 | | Join saratoga [0] (i=9803c6dd@rockbox/developer/saratoga) |
| 00:37:28 | saratoga | stripwax: i'm working but i'll keep an eye on the channel |
| 00:39:01 | stripwax | I get something like 91008 muls and 131872 adds for tremor 2048-point |
| 00:39:20 | stripwax | can't help thinking I've miscounted. would probably be better to just instrument the code to print out each time.. |
| 00:45:13 | | Quit n17ikh () |
| 00:46:16 | | Join DerPapst1 [0] (n=DerPapst@p4FE8FFA7.dip.t-dialin.net) |
| 00:46:22 | | Quit Omlet ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") |
| 00:47:01 | | Join efyx_ [0] (n=efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 00:47:05 | saratoga | 91,000 muls per second, not per block? |
| 00:47:49 | saratoga | stripwax: ^ |
| 00:50:01 | | Quit DerPapst (Read error: 60 (Operation timed out)) |
| 00:52:38 | stripwax | yeah , per block. must have miscounted. as you say, it's hard to read. I wouldn't be surprised if I'm off by a factor of 4, which would make it pretty similar to the other one |
| 00:54:09 | n1s | Unhelpful: ah, the conditional version is faster, i didn't even try that :) aslo the thing with saturating unsigned subtraction also just hit me, now if can only remember the inline asm syntax :) |
| 00:54:17 | saratoga | stripwax: 91000 would mean something like 50MHz just for decoding |
| 00:54:51 | saratoga | err 50MHz just for the multiplies |
| 00:55:09 | saratoga | since theres roughly 86 blocks per second |
| 01:00 |
| 01:00:28 | | Join Strife89 [0] (n=michael@adsl-146-208-154.mcn.bellsouth.net) |
| 01:08:56 | | Quit voltagex (Remote closed the connection) |
| 01:09:44 | | Join Vampireking [0] (n=quassel@82.113.106.217) |
| 01:14:49 | stripwax | saratoga - for n=2048, with instrumented code to track counts, I report 11136 single muls + 19904 single adds. for n=256, I get 1008 muls + 1696 adds. |
| 01:14:58 | Vampireking | I'm back with my problem |
| 01:14:58 | Vampireking | tail -f /var/log/messages says |
| 01:14:58 | Vampireking | Dec 6 00:52:41 patrick-kubuntu kernel: [ 1040.827331] scsi 12:0:0:0: Direct-Access SanDisk Sansa e260 v03. PQ: 0 ANSI: 0 |
| 01:14:58 | DBUG | Enqueued KICK Vampireking |
| 01:14:58 | Vampireking | Dec 6 00:52:41 patrick-kubuntu kernel: [ 1040.833321] scsi 12:0:0:1: Direct-Access SanDisk Sansa e260 v03. PQ: 0 ANSI: 0 |
| 01:14:58 | Vampireking | Dec 6 00:52:41 patrick-kubuntu kernel: [ 1040.833621] sd 12:0:0:0: Attached scsi generic sg3 type 0 |
| 01:15:01 | Vampireking | Dec 6 00:52:41 patrick-kubuntu kernel: [ 1040.833684] sd 12:0:0:1: Attached scsi generic sg4 type 0 |
| 01:15:04 | Vampireking | Dec 6 00:52:41 patrick-kubuntu kernel: [ 1040.849680] sd 12:0:0:0: [sdc] 7964672 512-byte logical blocks: (4.07 GB/3.79 GiB) |
| 01:15:07 | Vampireking | Dec 6 00:52:41 patrick-kubuntu kernel: [ 1040.855332] sd 12:0:0:1: [sdd] 1989632 512-byte logical blocks: (1.01 GB/971 MiB) |
| 01:15:10 | Vampireking | Dec 6 00:52:41 patrick-kubuntu kernel: [ 1040.861317] sd 12:0:0:0: [sdc] Write Protect is off |
| 01:15:13 | Vampireking | Dec 6 00:52:41 patrick-kubuntu kernel: [ 1040.867313] sd 12:0:0:1: [sdd] Write Protect is off |
| 01:15:15 | Vampireking | but I can't use sudo mkfs.vfat -F 32 /dev/sdc |
| 01:15:16 | saratoga | stop before the bot kicks you |
| 01:15:17 | Vampireking | it says /dev/sdc: No such file or directory |
| 01:15:34 | stripwax | Vampireking - please use something like pastebin in the future for posts/replies like that |
| 01:16:10 | Vampireking | ok sorry |
| 01:18:20 | stripwax | saratoga - (cont'd) - which (assuming 6 clocks for mult) ought to make it much, much slower than the ffmpeg mdct |
| 01:19:49 | saratoga | stripwax: so we save at least 2500 muls per pass with the ffmpeg one, and probably a lot more once its optimized |
| 01:21:03 | stripwax | I don't know about "a lot" (which multiplies are you going to take out?). but there's obviously material amounts of overhead elsewhere otherwise it would already be faster than the tremor one. |
| 01:21:12 | saratoga | i think we can pretty easily drop the mul and add count by another 1500 to 2000 in the ffmpeg one |
| 01:21:30 | saratoga | although some of those tricks would probably work on the tremor one too |
| 01:22:02 | stripwax | tremor already has pretty much all the tricks I can think of in it (other than using a different algo entirely) |
| 01:22:09 | stripwax | which tricks do you have in mind? |
| 01:22:14 | saratoga | stripwax: the rotation math could be done faster |
| 01:22:34 | saratoga | you can factor out the complex multiplies to go from 4 mul, 4 add, to be 3 mul, 3 add and a table lookup |
| 01:23:19 | stripwax | that would apply for all cross-product terms or just the initial/final rotation steps? |
| 01:23:55 | saratoga | stripwax: you can use it anywhere you multiply by a constant, but i don't know if it makes sense everywhere because of the large look up tables needed |
| 01:24:03 | | Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) |
| 01:24:22 | | Quit Vampireking (Remote closed the connection) |
| 01:25:12 | | Join Strife1989 [0] (n=michael@adsl-154-22-241.mcn.bellsouth.net) |
| 01:25:24 | stripwax | yeah, extra lookup could turn out to be quite a large penalty |
| 01:25:48 | saratoga | the helix people do use that trick though, so its probably worthwhile |
| 01:26:15 | stripwax | but if you're going to use an extra lookup table for the pre/post rotation, you might as well use it in the butterflies too, I would have thought. |
| 01:26:30 | stripwax | since it would be the same table |
| 01:26:39 | saratoga | it won't be the same table |
| 01:26:46 | saratoga | the pre/post rotation constants aren't the same |
| 01:27:16 | stripwax | don't they both use sincos_lookup0? |
| 01:27:33 | | Quit Strife1989 (Read error: 104 (Connection reset by peer)) |
| 01:27:46 | saratoga | oh maybe they do in the tremor one, they don't in ffmpeg |
| 01:28:01 | saratoga | heres where i got the idea: http://cnx.org/content/m12021/latest/ |
| 01:28:17 | | Join Strife1989 [0] (n=michael@adsl-220-123-178.mcn.bellsouth.net) |
| 01:29:13 | | Join n17ikh [0] (n=n17ikh@host-69-59-126-212.nctv.com) |
| 01:30:46 | saratoga | its interesting that tremor can get away with just one lookup for rotation and transform, i had thought that wasn't possible without considerable error |
| 01:31:08 | stripwax | saratoga - I'd seen that before, although (for me at least), the "but alernatively" (sic) section is basically unreadable. is it the same as (6) and (7) here? http://mathworld.wolfram.com/ComplexMultiplication.html |
| 01:31:27 | saratoga | look at the pdf version of the page |
| 01:32:03 | saratoga | but yeah thats the idea |
| 01:32:10 | saratoga | you just store ac, bd, etc already multiplied |
| 01:32:24 | saratoga | so your table gets 1.5x bigger, but one of the multiplies is already done for you |
| 01:33:11 | saratoga | it won't help on faster arm so its probably not worthwhile there, but it would be a good compile time switch to have for arm7/9 |
| 01:34:04 | stripwax | wait, you can't store ac, bd already multiplied. a comes from constants but c comes from your data. you mean a+b, a-b ? |
| 01:35:22 | stripwax | Also if only one set of factors is used, could you just replace the table of [as] and [bs] with a table of [a+bs] and [a-bs] for no extra memory usage? |
| 01:36:02 | stripwax | also, on arm, a 64-bit add is a pain if you're not also doing a mul at the same time |
| 01:37:21 | saratoga | just look at the derivation in the link above |
| 01:37:27 | saratoga | it explains how to do it |
| 01:37:47 | stripwax | yep I did, but it doesn't say anything about storing ac, bd in a table - just storing a+b, a-b in a table. |
| 01:37:49 | saratoga | and 32 bit precision should be more then fine, thats all we use now anyway for trig |
| 01:39:03 | saratoga | oh maybe i remembered it wrong |
| 01:39:14 | saratoga | do you only need to store 2 constants and not 3? |
| 01:39:21 | stripwax | that's how I read it |
| 01:39:42 | saratoga | i think you need to store C too |
| 01:39:58 | stripwax | you're right - just spotted that |
| 01:40:09 | Unhelpful | n1s: i think the conditional is faster than that, anyway. sat has a result latency of two, so it's 4 cycles for clz, rsb, sat. the conditional version is 3 cycles if it needs to test explicitly, and 2 if not due to using a calculated input |
| 01:40:26 | saratoga | although maybe you could compute it just as easily |
| 01:40:36 | saratoga | since C = (D+E)<<1 |
| 01:41:00 | | Quit Strife89 (Read error: 110 (Connection timed out)) |
| 01:41:23 | saratoga | actually i think you can compute C easier then storing it |
| 01:41:59 | stripwax | since both C and S have 31 bits of precision, though, doing C+S is going to make things start getting a bit fiddly |
| 01:42:05 | saratoga | can arm shift the input to a mul for free or just the add? |
| 01:42:39 | saratoga | that should be ok, we've got tons of precision |
| 01:43:18 | stripwax | I believe you can shift for most things, but I don't think you can shift the inputs to the 32x32->64 smull/umull stuff. |
| 01:45:38 | saratoga | doing the D+E<<1 step is only going to be marginally faster then just doing an extra mul unless i'm missing something |
| 01:46:17 | Unhelpful | stripwax: i believe all mul instructions take only unshifted inputs. add, sub, rsb, and all bitwise logical instructions allow shifts, or any shifted 8-bit value, as inputs. |
| 01:46:28 | saratoga | although actually it might not matter |
| 01:46:31 | Unhelpful | (for the second operand only) |
| 01:46:55 | saratoga | if you double every number by 2 theres no need to shift then back as long as you remember you've changed your fixed point |
| 01:47:08 | Unhelpful | shifted register operands need to available 1 cycle before they are used, or they incur a stall on armv6 |
| 01:48:30 | saratoga | armv6 has a pipelined mul so this probably wouldn't help anyway |
| 01:48:55 | saratoga | does armv6 have a packed mul16x2 op? |
| 01:50:46 | funman | http://forums.rockbox.org/index.php?topic=23263.0 < c200v2 mkamsboot confirmed several times to not work on every model |
| 01:50:49 | Unhelpful | saratoga: it can multiply the elements of two packed 16x2 vectors and produce a 32-bit sum or difference, optionally accumulating and optionally swapping the components of one vector |
| 01:50:59 | saratoga | yeah i think this is actually faster on arm < 5E, since you trade on fixed point mul (<=6 clocks) for 2 ordinary adds (2 clocks) |
| 01:51:40 | saratoga | with a free shift folded into one of the adds |
| 01:52:22 | Unhelpful | it also can extra the top or bottom 16-bit value from a 32-bit register as a multiply operand - there's an instruction to pick top or bottom of two registers and produce one 32-bit result, and also 32*(16t/b), but the last shifts output right by 16 |
| 01:52:37 | | Quit domonoky1 (Read error: 104 (Connection reset by peer)) |
| 01:52:53 | | Quit BlakeJohnson86 ("Leaving.") |
| 01:52:58 | saratoga | Unhelpful: ok not what i was thinking |
| 01:53:07 | | Quit DerPapst1 ("Leaving.") |
| 01:53:31 | Unhelpful | you want to multiply the components of two 16-bit vectors to produce packed 16-bit results? |
| 01:53:36 | saratoga | so this trick is probably worth using almost everywhere on those targets |
| 01:53:47 | saratoga | Unhelpful: well packed 32 bit results I guess |
| 01:54:12 | saratoga | basically a way to do 32x16,32x16 = 32x32.32x32 |
| 01:54:33 | saratoga | but that'd be asking too much |
| 01:55:35 | n1s | Unhelpful: yeah, i thought there was a "uqsub" instruction but there isn't one |
| 01:56:37 | n1s | btw the conditional version showed only +- 0.01s differences on my beast decoding flac so it's about the same as my slightly less readable code :) |
| 01:58:27 | | Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 01:58:27 | saratoga | well time to go read about waveguide for a couple hours, maybe someday we'll actually get around to writing this thing :) |
| 01:58:51 | stripwax | saratoga - so how much 'free' precision do we have in, say, tremor? I can't see any easy way to use this 3mul,3add rearrangement without losing 2 bits of precision and/or having a load of carry shifting instructions |
| 01:59:10 | saratoga | stripwax: we've got plenty of precision |
| 01:59:44 | saratoga | you could probably throw away 5-10 bits before you'd have even 1 bit difference on 16 bit output |
| 02:00 |
| 02:00:05 | saratoga | for WMA I can't even measure the accuracy because the Windows decoder is less accurate then we are |
| 02:00:11 | stripwax | heh! |
| 02:00:38 | *** | Saving seen data "./dancer.seen" |
| 02:00:45 | saratoga | if you have any ideas about how to trade accuacy for speed, please suggest them |
| 02:00:50 | saratoga | accuracy |
| 02:01:52 | saratoga | i was thinking maybe trying to pick off the mdct coefficients that get multiplied by large trig values and shift them by 8 bits or so, that way they're more likely to save a cycle here and there on arm7 and arm9tdmi |
| 02:02:06 | saratoga | due to early termination in the multiplier |
| 02:02:28 | saratoga | that or maybe see if 32x32 fixed point multiplies can be used anywhere, since those are also faster then the 32x32=64 variety |
| 02:03:01 | saratoga | but thats hard to do without a very good understanding of the algorithm |
| 02:03:15 | | Quit arohtar (Client Quit) |
| 02:03:31 | | Join faemir [0] (n=faemir@78.33.109.163) |
| 02:03:43 | saratoga | although thats my favorite thing about this new fft, its quite easy to understand compared to all the others we've looked at |
| 02:05:02 | | Join Strife89 [0] (n=michael@adsl-220-102-238.mcn.bellsouth.net) |
| 02:05:16 | saratoga | stripwax: did i send you the annotated version of the new fft that has the mul/add counts for each step of the split radix ? |
| 02:05:23 | stripwax | i don't think so |
| 02:06:38 | | Join ansuz [0] (n=kevin@dsl093-172-019.pit1.dsl.speakeasy.net) |
| 02:07:12 | Unhelpful | n1s: qsub/qadd, you mean? those appear to saturate one of their inputs, and then do a sub/add. |
| 02:07:35 | saratoga | stripwax: http://pastebin.com/m40a70235 |
| 02:08:18 | saratoga | stripwax: this doesn't have the optimizations though, so FFT8 and FFT16 use 4 and 8 too many multiplications respectively |
| 02:09:11 | saratoga | since all the TRANSFORM calls with both trig factors equal can be factored into half as many muls |
| 02:09:23 | Unhelpful | saratoga: that'd need two result registers... to my knowledge the only ops on arm using dual result registers are those returning 64-bit results. |
| 02:09:37 | saratoga | Unhelpful: yeah thats what i figured |
| 02:09:38 | n1s | Unhelpful: tey saturate the result but only for signed values, there are no unsigned saturating add/sub |
| 02:10:18 | n1s | (there are however *parallell* unsigned saturating add/sub for 16 and 8 bit packed values... |
| 02:10:41 | saratoga | if anyone can see any other savings in that fft, please let me know! |
| 02:10:50 | | Nick ansuz is now known as ansuz_ (n=kevin@dsl093-172-019.pit1.dsl.speakeasy.net) |
| 02:11:01 | | Nick ansuz_ is now known as ansuz__ (n=kevin@dsl093-172-019.pit1.dsl.speakeasy.net) |
| 02:11:19 | Unhelpful | n1s: well, since the value in question is only 5 bits, that would work fine, but those don't accept op2, only register operands, so you need a mov r, imm. |
| 02:11:27 | | Nick ansuz__ is now known as ansuz_ (n=kevin@dsl093-172-019.pit1.dsl.speakeasy.net) |
| 02:12:29 | | Part ansuz_ ("Konversation terminated!") |
| 02:12:46 | Unhelpful | saratoga: i had an idea about packed SWAR multiplies for *very* small multipliers - i thought it might manage to save vs 3 mask+multiply for blending rgb subpixels independently, but i've not tested it yet. |
| 02:13:27 | Unhelpful | also that's not using any special platform instruction, it's construction a mask value, with some unused low bits that will eventually overflow and clear the mask after they're incremented enough times. |
| 02:13:36 | | Quit Strife1989 (Read error: 113 (No route to host)) |
| 02:14:03 | Unhelpful | the idea was to do a packed (5,6,5) * (2,2,2) multiply-accumulate |
| 02:17:01 | | Quit stripwax ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 02:17:58 | n1s | Unhelpful: clz, rsb, usat is faster than the conditional |
| 02:19:15 | Unhelpful | n1s: on arm6? i guess that makes sense if the conditional must be tested explicitly, and if there are other ops that can be done to fill usat's result latency. |
| 02:19:50 | n1s | Unhelpful: yeah on the beast decoding flac |
| 02:20:03 | | Join ansuz [0] (n=ansuz@dsl093-172-019.pit1.dsl.speakeasy.net) |
| 02:20:56 | n1s | maybe usat can run conditionally even |
| 02:21:28 | JdGordon | n1s: hey.. I think it can |
| 02:23:31 | Unhelpful | n1s: would that gain anything? you'd need to test the input or output of clz to have a flag to condition it with, and then you'll probably be slower than the clzne,rsbne version |
| 02:23:55 | Unhelpful | nothing that saturates or is parallel supports immediates. maddening. :P |
| 02:25:40 | klapaucjusz | What's the status of the arm-eabi build? |
| 02:26:12 | n1s | i was thinking that rsbs can set C and V flags, can't these be used? |
| 02:26:27 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 02:26:27 | * | n1s points out he's a asm newbie |
| 02:27:40 | n1s | and the N and Z flags |
| 02:29:20 | n1s | so clz, rsbs, usatmi |
| 02:30:12 | Unhelpful | i'm not sure that buys us anything, though: "Most instructions execute in one or two cycles. If these instructions fail their condition codes then they take one and two cycles respectively." |
| 02:30:27 | n1s | ah |
| 02:30:37 | Unhelpful | although, sat *executes* in one, with results in 2? |
| 02:31:02 | Unhelpful | i would *try* making the sat conditional and seeing if it matters. |
| 02:32:49 | * | n1s tries |
| 02:34:44 | | Quit funman ("free(random());") |
| 02:35:28 | n1s | nah, no diff |
| 02:35:28 | | Join Omlet [0] (i=omlet05@91.176.181.84) |
| 02:39:38 | | Join sustineo [0] (n=42116ef5@giant.haxx.se) |
| 02:39:59 | sustineo | i need help rockboxing a v1 fuze |
| 02:40:09 | | Join webguest06 [0] (n=4a398403@giant.haxx.se) |
| 02:40:33 | Unhelpful | i was thinking that we could have a bit-scanning generic in the codeclib, with flags for type of result, and 0-input handling. so av_log2 would be someting like bs(x, BS_LOG, BS_ZERO) |
| 02:41:17 | webguest06 | Can I have mod access to the Wiki to add a couple of devices? |
| 02:41:23 | webguest06 | Username is lduperval |
| 02:41:26 | sustineo | when i use the auto-installer, it says [err] original firmware unknown, please try another version. Tested c200 versions are: 3.03.05 (on the bootloader install) |
| 02:41:49 | webguest06 | oops, sorry |
| 02:41:53 | sustineo | *3.02.05 |
| 02:42:21 | sustineo | whats with that? |
| 02:42:34 | Unhelpful | does the installer even support fuze? that's an unsupported port. |
| 02:42:41 | n1s | Unhelpful: i'm not quite sure i understand what you mean, can you elaborate a bit on that? :) |
| 02:42:43 | sustineo | apparently it does |
| 02:42:51 | sustineo | it has it in the list |
| 02:43:05 | sustineo | and says it does on the site |
| 02:43:14 | sustineo | but that error seems strange |
| 02:44:23 | Unhelpful | it says rockbox runs on fuze. i don't see anything saying that the installer supports it, and the front page at least implies that only stable ports are supported by the installer: "Rockbox runs well on these players, has a complete manual and is supported by the installer: " |
| 02:44:33 | | Quit Strife89 (Read error: 110 (Connection timed out)) |
| 02:45:41 | kkurbjun | JdGordon: is there a good place to force the menus to always use the touchscreen option set in settings, and then revert the touchscreen setting to what it was before the menu was entered? |
| 02:45:50 | Unhelpful | n1s: bit-scanning as in scanning from one end or the other for a set bit. BS_LOG indicating that the output should be log2(x), and BS_ZERO indicating that 0 input should produce 0 output |
| 02:46:00 | sustineo | ah |
| 02:46:06 | Unhelpful | BS_DONTCARE might be used by things that pre-test 0 input. |
| 02:46:13 | sustineo | how do i install w/o installer |
| 02:46:39 | n1s | Unhelpful: aha like a macro that expands to a call to the correct function, yes that could be nice |
| 02:46:59 | n1s | here's my asm av_log2 thing if you want to look http://pastebin.com/m3a285382 |
| 02:47:11 | Unhelpful | n1s: it needn't be a macro, if the flag inputs are constant then inlining will specialize it to remove the dead branches |
| 02:47:28 | n1s | true |
| 02:47:38 | JdGordon | kkurbjun: umm... what? when would it swap? |
| 02:48:14 | Unhelpful | a BS_ISPOW2 might also be useful on targets w/o clz, to indicate that inputs needn't be reduced to a power-of-2... assuming we even decide that the best algorithm is one that does that. ;) |
| 02:48:15 | JdGordon | sorry.. i mean why would you go from one to the other without the user wanting it? |
| 02:48:53 | | Quit sustineo ("CGI:IRC") |
| 02:49:54 | JdGordon | kkurbjun: I guess you mean in a game? in that case I would wrap do_menu() with your own function to do that... that is not something that shold happen in the core |
| 02:50:16 | | Join Casainho [0] (n=chatzill@bl15-146-182.dsl.telepac.pt) |
| 02:50:27 | Unhelpful | the benefits of such an algorithm are that 1) 0 as a special case can be handled by the LUT 2)on coldfire, a mul is fairly cheap and the reduction avoids any branches |
| 02:50:43 | kkurbjun | JdGordon: so, with plugins they are always, by default forced to grid mode when you enter them, and that makes sense when you are actually in the game, but the menu's are not currently consistent between the plugins, the plugins that are "aware" of absolute more and make use of it set the menu to the user setting when they go into menu's and then revert to the plugin setting when exiting, but that's currently being done piecemeal, each plug |
| 02:50:56 | kkurbjun | I'm also trying your latest patch |
| 02:51:02 | n1s | Unhelpful: yeah |
| 02:51:04 | | Part froggyman |
| 02:51:14 | kkurbjun | I'm still getting graphic glitches when I enable/disable the custom statusbar |
| 02:51:23 | n1s | should i commit the asm version for armv6? |
| 02:51:30 | JdGordon | AH ok, I didnt realise plugins force to grid mode... |
| 02:52:31 | Unhelpful | n1s: i'd say yes, without the conditional. if i want to generic-ize log2 i can do that after we see what's best on armv4 and coldfire |
| 02:53:25 | JdGordon | kkurbjun: even then, I wonder if that would confuse users... |
| 02:53:35 | Unhelpful | unfortunately, while it's branchless, the rounding is rather lengthy on cf |
| 02:53:56 | JdGordon | but sure, if you want to force it back you could easily set up something like the stack in the patch for the themes |
| 02:54:03 | JdGordon | (kugel hates that stack idea :D ) |
| 02:54:51 | Unhelpful | not only does it lack shifted operands, it appears it can only do shifts in place, so the sequence becomes move; shift; or; :/ |
| 02:54:53 | kkurbjun | JdGordon: it is definitely confusing for menu's currently. I think that changing the mode in game is reasonable since the controls for a touchscreen on most games will be very different |
| 02:55:49 | n1s | Unhelpful: yeah, i think the only place you get free shifts on coldfire is with the mac instructions |
| 02:56:01 | n1s | *emac, even |
| 02:56:05 | kkurbjun | JdGordon: what needs to be done to get pluginss to retain the background in menu too? Does that just need to be fixed on a plugin by plugin basis? |
| 02:56:37 | Unhelpful | n1s: yes, but i'm rather shocked that you can't specify an output operand for lsr :/ |
| 02:56:41 | Unhelpful | register, rather. |
| 02:58:04 | | Quit ansuz ("Konversation terminated!") |
| 02:58:14 | | Join ansuz [0] (n=ansuz@dsl093-172-019.pit1.dsl.speakeasy.net) |
| 03:00 |
| 03:00:13 | kkurbjun | JdGordon: why is a stack needed? |
| 03:00:31 | | Join sustineo [0] (n=42116ef5@giant.haxx.se) |
| 03:00:45 | sustineo | how do you manually install rockbox on a fuze v1? |
| 03:01:25 | sustineo | i need a bootloader, right? |
| 03:01:43 | sustineo | (i tried just unzipping to the sansa) |
| 03:01:50 | sustineo | (.rockbox) |
| 03:03:05 | CIA-6 | New commit by nls (r23868): slightly faster asm av_log2 for armv6 (currently only Gigabeat S) |
| 03:03:58 | sustineo | anyone know? |
| 03:04:08 | sustineo | the rockbox site is being unhelpful |
| 03:05:04 | n1s | i would say "read the manual" but they seem to have gone MIA so maybe a search in the wiki? |
| 03:05:20 | Unhelpful | it looks like 16 ops to do the rounding job on cf, a mul with extension word, and then fetch from LUT. |
| 03:05:33 | Unhelpful | n1s: there's a manual for fuze? |
| 03:05:41 | | Quit Casainho (Read error: 60 (Operation timed out)) |
| 03:06:10 | n1s | Unhelpful: yeah, it's listed on the manual page at least but the link to it and many more manuals give 404 |
| 03:06:22 | n1s | something is fishy |
| 03:08:05 | kkurbjun | n1s: so that recent commit is arm v5+? or is it just v6? |
| 03:09:05 | n1s | kkurbjun: v6 (and up) |
| 03:09:09 | n1s | because of usat |
| 03:09:10 | kkurbjun | is the D2 v5 or v6? |
| 03:09:17 | n1s | i think it's v5 |
| 03:09:54 | n1s | the speed difference between this version and the one with clz and a conditional is very small |
| 03:09:58 | kkurbjun | I was wondering because of the conditional, I ddin't see a >6 |
| 03:11:24 | n1s | >6 would be 7 and up |
| 03:11:31 | sustineo | thank you, google cache. ::) |
| 03:11:50 | kkurbjun | :), oh wow, I'm still foggy aparently |
| 03:13:06 | Unhelpful | which cf do our targets have? ISA_A+ has a ffs instruction, it appears |
| 03:14:39 | Unhelpful | kkurbjun: clz is armv5, usat is armv6. the conditional version, or n1s's earlier version with the shifts, is probably best on armv5 |
| 03:14:45 | | Quit Lss (Read error: 54 (Connection reset by peer)) |
| 03:16:07 | Unhelpful | i'd say use the conditional on armv5, it's always 3 cycles, unless the input is calculated in which case gcc can add an s to the instruction producing the input and save the explicit input test. |
| 03:16:44 | | Quit Omlet ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") |
| 03:17:03 | | Quit klapaucjusz ("leaving") |
| 03:17:08 | saratoga | sustineo: click the fuze link on the front page, the directions are there |
| 03:20:06 | kkurbjun | JdGordon: the new patch does get rid of the graphic glitch when you click resume and there is nothing to resume |
| 03:20:52 | n1s | Unhelpful: our coldfires are ISA_A and don't support the ff1 instruction AFAIK |
| 03:22:15 | Unhelpful | n1s: boo. so we're between using an LUT and using straight binary search. |
| 03:23:51 | | Join Tomis [0] (n=Tomis@70.134.93.64) |
| 03:24:08 | | Quit efyx_ (Remote closed the connection) |
| 03:26:46 | | Join efyx_ [0] (n=efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 03:27:50 | n1s | yeap "Error: invalid instruction for this architecture; needs ColdFire ISA_A+ (521x, 528x, or aliases)" |
| 03:28:22 | | Quit n1s ("Lämnar") |
| 03:29:31 | kkurbjun | n1s: I'm not sure if you saw the red, but the conditional does need to include ARM_ARCH >4 with CPU_ARM or some alternate since it's failing to build with arm targets below 5. |
| 03:29:42 | kkurbjun | oops |
| 03:30:27 | JdGordon | kkurbjun: sorry, was watching tv... stack makes enable/undo really easy :) |
| 03:30:51 | JdGordon | I'm tossing up weather to add the background image drawing to the theme enable stuff which would solve that problem |
| 03:31:07 | | Quit efyx_ (Remote closed the connection) |
| 03:31:23 | kkurbjun | JdGordon: couldn't you just have a local variable that stores the setting in the menu. - you wouldn't need to have a separate stack. |
| 03:32:01 | kkurbjun | Also, I'm logging some notes about the artifacts I am seeing in the main build in FS10824 |
| 03:32:06 | JdGordon | sure that would work... thats the current solution for the bars stuff |
| 03:32:12 | JdGordon | great |
| 03:34:01 | | Join |Kirin| [0] (n=Kirin@modemcable164.145-82-70.mc.videotron.ca) |
| 03:34:44 | JdGordon | is do_menu() the only core function with this plugin touchscreen problem? |
| 03:35:12 | kkurbjun | I believe so |
| 03:35:38 | Unhelpful | n1s: but i thought we weren't even able to use our *actual* target with gcc3? |
| 03:35:39 | | Quit |Kirin| (Client Quit) |
| 03:36:02 | JdGordon | maybe add a wrapper for it and use that instead of do_menu in the plugin api? assuming its just background image and touchscreen which needs forcing |
| 03:37:34 | saratoga | is ARM_ARCH not defined on PP and AMS ? that red looks odd |
| 03:38:26 | kkurbjun | saratoga: CPU_ARM is defined, but there's no function for arm arch's less than 5 defined in the CPU_ARM block |
| 03:39:16 | kkurbjun | the previous conditional forced arms less than 5 to use the C implementation |
| 03:39:17 | saratoga | oh i misread that as "ARM_ARCH == 4" |
| 03:39:30 | kkurbjun | :-D, that's what I was doing |
| 03:39:44 | kkurbjun | it might be more clear to do a >= 5 and a >=6 |
| 03:40:59 | JdGordon | can anyone think of a good reason to not add a lcd driver function which is "dealy update" which just tells the driver to do a full screen update next time any updat is done? |
| 03:41:07 | JdGordon | s/dealy/delay |
| 03:41:18 | kkurbjun | JdGordon: the wrapper is probably the way to go, I was thinking about the touchscreen stack thing and I think it would cause problems when the setting is supposed ot actually be changed in the core |
| 03:41:55 | JdGordon | yeah, its probably overkill for the touchscreen stuff |
| 03:43:38 | kkurbjun | JdGordon: why do you want a wrapper that does that, you can just call the fullscreen update when you want the full update |
| 03:44:51 | | Quit GeekShado_ ("The cake is a lie !") |
| 03:45:50 | kkurbjun | JdGordon: I added the comments with the artifacts that I was seeing |
| 03:53:12 | JdGordon | kkurbjun: 1 and 2 probably wont be fixed... but thanks |
| 03:54:36 | kkurbjun | JdGordon: why won't 1 and 2 be fixed? |
| 03:54:54 | JdGordon | because they are almost never hit... its not a common thing to do |
| 03:55:01 | JdGordon | also that setting is being removed anyway |
| 03:55:11 | JdGordon | not just yet.. but soon |
| 03:55:27 | kkurbjun | you will still be able to enable/disable the statusbar won't you? |
| 03:55:38 | JdGordon | yes |
| 03:55:43 | JdGordon | its load a sbs, or dont |
| 03:56:45 | | Join dmb [0] (n=Dmb@unaffiliated/dmb) |
| 03:57:25 | kkurbjun | JdGordon: I can preoduce similar artifacts when loading different sbs's |
| 03:57:26 | | Quit sustineo ("CGI:IRC (EOF)") |
| 03:57:31 | kkurbjun | produce |
| 03:57:40 | JdGordon | sure, so that should be fixed... |
| 03:58:26 | kkurbjun | :), ok, I'll give directions on how to do the same thing without that menu |
| 04:00 |
| 04:00:19 | JdGordon | I'm more worried about artefacts that dont involve chanign sbs :) |
| 04:00:26 | JdGordon | swtiching between screens and stuff |
| 04:00:30 | * | JdGordon is off for the evening |
| 04:00:42 | *** | Saving seen data "./dancer.seen" |
| 04:01:21 | kkurbjun | JdGordon: that's fair enough, but the interface doesn't look too good when these things happen, and I would still consider them a bug |
| 04:01:24 | kkurbjun | see ya |
| 04:03:58 | kkurbjun | (I added a fifth artifact that is similar to 1 and 2 without the custom statusbar menu when you look at that fs). |
| 04:04:31 | | Quit webguest06 ("CGI:IRC (EOF)") |
| 04:20:08 | | Join Rondom_ [0] (n=quassel@dslb-084-057-140-109.pools.arcor-ip.net) |
| 04:34:09 | | Quit Rondom (Read error: 110 (Connection timed out)) |
| 04:35:42 | | Join kugel [0] (n=kugel@e178107118.adsl.alicedsl.de) |
| 04:54:46 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 04:56:59 | | Join fdinel [0] (n=Miranda@modemcable235.127-131-66.mc.videotron.ca) |
| 04:59:37 | | Quit fdinel (Client Quit) |
| 05:00 |
| 05:07:23 | | Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) |
| 05:31:10 | | Part froggyman |
| 05:43:26 | CIA-6 | New commit by unhelpful (r23869): Fix red: av_log2 undefined for ARM_ARCH <= 4, missing codeclib.h includes. |
| 05:47:48 | | Join Greenhorn [0] (n=Green@CPE001d7e3dde7f-CM0011aec4fcb2.cpe.net.cable.rogers.com) |
| 05:48:36 | Greenhorn | are there mirror links for the manuals? |
| 05:48:44 | Greenhorn | i chose a bad day to start using this |
| 05:50:17 | | Quit ansuz ("A motion to ajourn is always in order.") |
| 05:54:07 | mc2739 | Greenhorn: the manuals are built nighlty. Last night's run must have had problems. |
| 06:00 |
| 06:00:08 | | Quit Greenhorn () |
| 06:00:45 | *** | Saving seen data "./dancer.seen" |
| 06:00:48 | Unhelpful | n1s: av_log2 benches slower on my e200 than the pseudo-debruijn version - maybe because of the larger LUT, 256 entries vs 64 (or 4 cachelines vs 16, and perhaps we ought to cache-align the LUT)? |
| 06:02:18 | Unhelpful | i was thinking, the pseudo-debruijn version could also allow the user to transform the results by some arbitrary function, by defining the LUT in a macro |
| 06:21:49 | | Join kadoban__ [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) |
| 06:35:23 | | Quit kadoban_ (Read error: 110 (Connection timed out)) |
| 06:52:42 | | Join JdGordon| [0] (n=me@rockbox/developer/JdGordon) |
| 06:55:59 | | Quit panni_ (Read error: 104 (Connection reset by peer)) |
| 07:00 |
| 07:04:14 | | Quit bluebrother (Read error: 104 (Connection reset by peer)) |
| 07:04:17 | | Join bluebrother [0] (n=dom@f053152163.adsl.alicedsl.de) |
| 07:07:21 | | Quit JdGordon| (Remote closed the connection) |
| 07:27:04 | FlynDice | Vampireking:(for the logs) I think I have a solution for you. Plug your player into the usb and wait for the Sandisk logo to appear. Now unplug the player before the database refresh starts. Should put you into the menu in the OF and you can format from there. |
| 07:30:03 | | Join Horschti [0] (n=Horscht2@xbmc/user/horscht) |
| 07:31:08 | | Quit Tomis (Read error: 104 (Connection reset by peer)) |
| 07:31:26 | | Join Tomis [0] (n=Tomis@70.134.93.64) |
| 07:37:23 | | Quit Horscht (Read error: 60 (Operation timed out)) |
| 07:56:35 | topik | FlynDice: i haven't had any problems starting my Fuze anymore since your little patch. had a couple of glitches while playing, but have yet to confirm the original files don't have this glitch as well |
| 08:00 |
| 08:00:17 | | Join AndyIL [0] (n=pasha_in@212.14.205.32) |
| 08:00:28 | topik | Unhelpful: rbutil supports the Fuze, but that guy probably ran the latest Fuze firmware for which rbutil (or mkamsboot) has no support. |
| 08:00:49 | *** | Saving seen data "./dancer.seen" |
| 08:08:48 | saratoga | does it give a meaningful error message if you try too new a firmware? |
| 08:09:44 | topik | it gives the mkamsboot error sustineo pasted |
| 08:11:46 | | Quit AndyI (Read error: 110 (Connection timed out)) |
| 08:16:45 | topik | the mkamsboot on the wiki page give a friendlier 'unknown firmware model' message |
| 08:21:30 | saratoga | topik: but he was using a c200v2 right? i don't think rbutil will work at all with those |
| 08:22:31 | | Join stoffel [0] (n=quassel@p57B4DB42.dip.t-dialin.net) |
| 08:23:47 | topik | nope, fuze v1. http://www.rockbox.org/irc/log-20091206#03:00:45 |
| 08:24:06 | | Join robin0800 [0] (n=quassel@general-kt-199.t-mobile.co.uk) |
| 08:24:27 | topik | the mkamsboot in current rbutil does have this error message for the fuze though: Tested c200 versions are : 3.02.05 |
| 08:25:03 | topik | you get that with the 01.02.28 OF |
| 08:25:24 | topik | 01.02.26 works fine |
| 08:25:30 | saratoga | the error message he quoted mentions the c200 though? |
| 08:25:51 | topik | yes, the fuze mkamsboot gives the c200 error |
| 08:26:09 | saratoga | weird |
| 08:26:16 | topik | [ERR] Original firmware unknown, please try an other version. Tested c200 versions are : 3.02.05 |
| 08:26:19 | saratoga | bluebrother should probably be pinged about that |
| 08:26:36 | topik | that's the exact error with rbutilqt-v1.2.3.zip and fuze01.02.28.zip |
| 08:27:07 | topik | replacing the mkamsboot with the one from the wiki, or yours that supports fuze01.02.28.zip would be an option |
| 08:32:43 | CIA-6 | New commit by FlynDice (r23870): Sansa AMS: Move the boost from SD ident to operating frequency to after the cards get switched to HS timings. ... |
| 08:35:27 | | Join Rob2222 [0] (n=Miranda@p4FDCB710.dip.t-dialin.net) |
| 08:40:12 | | Quit CaptainKewl (Remote closed the connection) |
| 08:53:47 | | Quit Rob2223 (Read error: 110 (Connection timed out)) |
| 09:00 |
| 09:18:26 | jae | Morning |
| 09:19:52 | jae | I gather the only way of getting at the DB (and thus, playcount/ratings... I'd like to sync with home, and update ratings while on the road) is via the export mechanism? |
| 09:21:03 | FlynDice | jae: Sorry can't help with the DB but I'm interested in how you're player is working |
| 09:21:14 | jae | FlynDice: that wouldn't, by any chance, fix the SD card problem? (As in I couldn't boot (first time) with the SD inserted) |
| 09:21:35 | jae | FlynDice: mostly fine, except for the just-mentioned problem |
| 09:21:40 | FlynDice | jae: Well I'm really hpoing it does.... |
| 09:21:48 | FlynDice | hoping even |
| 09:22:25 | jae | Strange thing, it hung the very first time; I could boot without the card, and then insert it while running... and it boots nicely since then |
| 09:22:38 | jae | Only I'm not sure the DB picks up the SD contents |
| 09:22:44 | jae | Have to check in more detail |
| 09:23:03 | FlynDice | yes, that's similar to what topik was reporting |
| 09:23:29 | jae | Oh, have to do an update then |
| 09:24:06 | FlynDice | yes please do and give me a holler with the results ;-) |
| 09:24:49 | jae | I also get random gfx glitches, but they are totally (it seems) random, and very transient... and w/o any consequences as to function of the player as a player |
| 09:25:12 | FlynDice | what do you mean gfx glitches? |
| 09:25:45 | jae | Oh, and the automatic manual build seems to be broken (okay, so it's the weekend... so it should possibly be fixes quicker than on weekdays... ;-) |
| 09:25:51 | jae | ... still, that is |
| 09:26:30 | jae | Oh... stuff like a white screen with a black smear of pixels across... which immediately disappears |
| 09:27:05 | saratoga | display corruption is a known issue on some ams targets, theres an FS task with some patches in it |
| 09:27:15 | jae | Or just a couple minutes ago, I got a weirdly "split" page in some setting subcategory... one button press later it corrected itself again |
| 09:27:18 | saratoga | its particularly bad in mpegplayer |
| 09:32:03 | * | jae mounts his Fuze on WinXP... hoboy... ;) |
| 09:34:58 | jae | Whee, let's see if I can update last.fm successfully |
| 09:37:31 | jae | It worked. Nice. |
| 09:37:38 | topik | i've had similar glitches as jae reports, but they are hardly a showstopper |
| 09:37:47 | topik | random menu distortions and such |
| 09:38:22 | | Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) |
| 09:38:25 | jae | Yup... but since there so extremely short-lived... |
| 09:38:44 | topik | same here. all the benefits of rockbox eclipse this glitching |
| 09:39:13 | saratoga | theres a fix it just breaks other stuff |
| 09:39:19 | saratoga | it'll be fixed eventually in svn |
| 09:39:31 | topik | do you know what it breaks? |
| 09:39:51 | jae | topik: *Very* much so... I'm so happy to finally run rb, what's a *nanoscopic* (almost ;-)) thing like that |
| 09:40:36 | FlynDice | "theres a fix it just breaks other stuff" <−−- Now that's a phrase to assign a macro to.. ;-) |
| 09:40:44 | jae | lol |
| 09:42:30 | | Quit phanboy4 (Read error: 54 (Connection reset by peer)) |
| 09:43:14 | topik | FlynDice: what benefits would it be to have my sdhc card run at high-speed timings? |
| 09:43:53 | saratoga | topik: i think the scroll wheel |
| 09:44:42 | topik | i pick screen glitches over scroll wheel glitches any day. but the FS patch might be an indication for the direction of a real fix |
| 09:45:24 | FlynDice | well the card frequency can be run at up to 50 MHz with HS timings instead of the standard 25MHz. |
| 09:46:52 | topik | yeah, but i doubt there's anything the Fuze can playback that needs 50Mbit/s. and without USB, read/write performance should be enough on low-speed timings |
| 09:48:02 | FlynDice | topik: If your card is reporting 25.0 for speed though it's quite likely that it is not a HS card. In that case we're overclocing it now as the cards are both running at 31 MHz. The internals are v1 non HS cards too |
| 09:48:22 | topik | HS is speed class 2? |
| 09:50:24 | FlynDice | I'm not sure on that, I looked at the spec last night and it doesn't specifically say. But my class 6 card definitely takes the switch to HS timing and reports 50.0 MBit/s. |
| 09:52:11 | topik | wikipedia suggests class 2 is 2Mbyte/s and class 6 is 6Mbyte/s |
| 09:52:37 | FlynDice | And the internal cards also do not take the switch. We don't try it now with current code but I tried it before and they reported 25.0 after trying to switch. |
| 09:53:06 | | Join flydutch [0] (n=flydutch@host140-41-dynamic.116-80-r.retail.telecomitalia.it) |
| 09:53:31 | saratoga | topik: thats write |
| 09:53:33 | saratoga | speed |
| 09:53:36 | topik | there doesn't seem to be much reason for the Fuze to be HS i think |
| 09:53:44 | saratoga | we don't care about rated write speed |
| 09:53:59 | | Quit advcomp2019 ("Leaving") |
| 09:54:31 | topik | good point. missed that crucial word |
| 09:56:00 | topik | i understand why you want things to work within specs and at least as good as in the OF |
| 09:56:17 | topik | but for me as a user, it is amazing what you guys did for both my Fuze and Nano 2G |
| 09:57:26 | * | jae is updating his Fuze... |
| 09:59:28 | jae | Stupid noob question: how do you build this thing? I have an SVN checkout, but when trying "make" in the manual dir (since the manual is still not updating online)... only errors. Looks like some env/make vars need to be defined, and I don't know where they are defined. |
| 10:00 |
| 10:00:20 | FlynDice | make a directory called build in the svn dir |
| 10:00:50 | *** | Saving seen data "./dancer.seen" |
| 10:01:16 | FlynDice | well not in the svn dir but inyour source dir |
| 10:01:40 | jae | Then run tools/configure? In the dir, right? |
| 10:01:45 | FlynDice | yes |
| 10:01:52 | FlynDice | ../tools/configure |
| 10:01:55 | * | jae is guessing... oh, he guessed right! :D |
| 10:02:37 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 10:02:43 | FlynDice | then make && make zip |
| 10:02:59 | gevaerts | make manual more likely |
| 10:03:35 | jae | ../rockbox-svn/tools/configure in my case... oops, needs input, so can't run it just as GNU configure |
| 10:04:05 | gevaerts | it's not autoconf, no |
| 10:04:42 | gevaerts | you can use commandline options though |
| 10:05:04 | jae | normal/advanced? What's the diff? |
| 10:05:20 | FlynDice | you want normal |
| 10:06:10 | jae | Is there a wiki page on this? Or is "arcane knowledge"? ;-) |
| 10:06:26 | FlynDice | yes there is but I'm interested in helping you help me.. ;-) |
| 10:06:38 | jae | FlynDice: I realized what I want: I want to read configure (it's not Perl, so it's not that painful ;)) |
| 10:06:44 | gevaerts | http://www.rockbox.org/wiki/DocsIndex#For_Developers |
| 10:08:05 | jae | gevaerts: stupid me, I think I've looked at (this part of) that page before... |
| 10:13:44 | jae | Well... I don't have an arm toolchain, it seems (it can't find arm-elf-gcc and arm-elf-ld) |
| 10:13:52 | jae | Not really surprised |
| 10:15:23 | topik | http://www.rockbox.org/wiki/LinuxSimpleGuideToCompiling answers how to get one |
| 10:15:41 | topik | pretty much running tools/rockboxdev.sh |
| 10:17:41 | jae | There isn't, by any chance, a .deb running around somewhere with a suitable arm gcc? ;) |
| 10:18:19 | jae | And rockboxdev.sh it is (I built gcc manually, some years ago, just out of curiousity, and this just for reference...) |
| 10:19:15 | saratoga | i doubt it |
| 10:19:33 | saratoga | the only advantage of a deb would be that you don't have compile it yourself, but on a modern computer its pretty quick |
| 10:20:13 | jae | Define "modern" ;) |
| 10:21:13 | topik | i just switch from my p3-500Mhz laptop to a virtual machine on a modern pc for compiling rockbox. makes all the difference |
| 10:25:09 | jae | I'll try on my Linux box first... it's definitely faster than a p3-500 :P |
| 10:27:57 | saratoga | multicore system takes probably 5-10 minutes for just one cross compiler |
| 10:28:06 | saratoga | just be sure to use make -j |
| 10:28:48 | topik | my virtualbox vm does a single build in about 4m30s |
| 10:28:58 | topik | hmm, -j for more cores. must try that |
| 10:48:26 | sunrider | i have an e200 that has had its hd completely wiped. what can i do |
| 10:51:44 | topik | sunrider: would this help? http://www.rockbox.org/wiki/SansaE200Unbrick |
| 10:52:21 | | Join Telos [0] (n=Telos@c-65-34-193-169.hsd1.fl.comcast.net) |
| 10:52:44 | sunrider | maybe. ill look into it. thanks |
| 10:53:07 | Telos | Just poppin in to see any work's been started for Rockbox on the Fuze v2. |
| 10:54:52 | topik | nothing yet that is usable at this time |
| 10:59:16 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 11:00 |
| 11:00:41 | | Join n1s [0] (n=n1s@90-230-78-242-no134.tbcn.telia.com) |
| 11:00:51 | | Join fyre^OS [0] (n=nnscript@cpe-69-203-150-85.si.res.rr.com) |
| 11:05:42 | sunrider | does not apprear to be working. |
| 11:05:52 | sunrider | im not finding anything i can mount ;( |
| 11:06:26 | sunrider | i guess it doesnt matter. it was a noisy player |
| 11:06:33 | sunrider | time to upgrade to something |
| 11:07:27 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 11:07:48 | gevaerts | sunrider: what does "had its hd completely wiped" mean exactly? |
| 11:08:10 | sunrider | gevaerts, all partitions were lost |
| 11:08:19 | gevaerts | how? |
| 11:09:16 | sunrider | well., i needed a usb stick. i couldnt find any so i thought i could `dd` an iso onto this thing. i made the backups and then formatted the sansa |
| 11:09:21 | sunrider | havent been able to make it mount since |
| 11:09:47 | jae | FlynDice: SD card, still no dice with 23870, it hangs at the startup logo w/ card, starts up correctly without |
| 11:10:00 | gevaerts | hm, the manufacturer mode recovery with e200tool should work then |
| 11:11:11 | sunrider | just discovered i can capture usb ports with wireshark |
| 11:11:30 | sunrider | heh! |
| 11:11:36 | | Quit kugel (Read error: 60 (Operation timed out)) |
| 11:12:37 | FlynDice | jae: ok, if you pop the card in after rockbox boots will it init ok? |
| 11:15:29 | | Quit Telos () |
| 11:17:46 | sunrider | Bus 002 Device 011: ID 0781:0720 SanDisk Corp. Sansa C200 series in recovery mode |
| 11:17:58 | sunrider | C200? thought it was e200. |
| 11:18:01 | jae | Yup, it does |
| 11:18:32 | sunrider | says `e280` in small print on the back |
| 11:18:34 | | Quit fyrestorm (Read error: 110 (Connection timed out)) |
| 11:19:09 | gevaerts | sunrider: the usb id databases in linux aren't always perfect |
| 11:19:24 | FlynDice | jae: would you try rebooting with card intalled now |
| 11:19:42 | CIA-6 | New commit by bluebrother (r23871): Remove special lib Makefile targets that aren't used anymore. |
| 11:19:46 | CIA-6 | New commit by bluebrother (r23872): Improve detection of system libspeex and fallback earlier. ... |
| 11:21:20 | | Quit FOAD (Read error: 110 (Connection timed out)) |
| 11:21:20 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 11:21:25 | FlynDice | and if that works, would you turn it off and wait awhile (10 mins?) and then try again? Not that you had anything better to do.... |
| 11:23:37 | | Quit robin0800 (Read error: 110 (Connection timed out)) |
| 11:24:53 | * | FlynDice is headed to bed, will read logs in the AM thanks for the help! |
| 11:25:08 | jae | Nopes, still hangs when rebooting |
| 11:25:19 | jae | That actually looks like a regression to me |
| 11:25:27 | n1s | ooops, sorry for the commit-and-run last night :/ |
| 11:25:29 | FlynDice | Rats... |
| 11:25:54 | n1s | Unhelpful: thanks for fixing, maybe i shouldn' |
| 11:25:59 | n1s | t do this at 3 am |
| 11:33:43 | n1s | Unhelpful: that's true about the coldfires and gcc < 4.3 we use mcf5206e instead which has the same isa except for the emac and also different execution timings for muls etc |
| 11:34:54 | | Quit bzed (Remote closed the connection) |
| 11:34:55 | | Join bzed_ [0] (n=bzed@devel.recluse.de) |
| 11:35:09 | | Nick bzed_ is now known as bzed (n=bzed@devel.recluse.de) |
| 11:36:48 | n1s | Unhelpful: the table is in iram, is that cached? |
| 11:40:34 | | Join dfkt_ [0] (n=dfkt@unaffiliated/dfkt) |
| 11:46:07 | | Quit dfkt (Read error: 60 (Operation timed out)) |
| 11:46:38 | jae | *Now* I feel stupid... I just noticed that the version running is 23863 (or so everything tells me), even though rbutil says it installed 23870. |
| 11:46:40 | | Quit Tomis () |
| 11:47:04 | jae | So I do I make it actually *do* the upgrade? Or is just a wrong version number? |
| 11:47:29 | jae | +who |
| 11:47:37 | jae | +how (dagnabbit9 |
| 11:47:45 | jae | *aaaargrggh* |
| 11:47:48 | jae | can't type |
| 11:50:55 | | Join Llorean [0] (n=DarkkOne@adsl-76-202-17-167.dsl.hstntx.sbcglobal.net) |
| 11:54:40 | | Join bzed_ [0] (n=bzed@devel.recluse.de) |
| 11:58:34 | | Quit bzed (Read error: 111 (Connection refused)) |
| 11:58:34 | | Nick bzed_ is now known as bzed (n=bzed@devel.recluse.de) |
| 12:00 |
| 12:00:54 | *** | Saving seen data "./dancer.seen" |
| 12:07:19 | | Join Omlet [0] (i=omlet05@40.10-65-87.adsl-dyn.isp.belgacom.be) |
| 12:30:31 | | Quit BHSPitLappy (Read error: 110 (Connection timed out)) |
| 12:33:25 | | Join advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) |
| 12:35:23 | jae | Whee. I can read the DB! |
| 12:35:49 | | Join DerPapst [0] (n=DerPapst@p4FE8FEF6.dip.t-dialin.net) |
| 12:48:16 | bluebrother | hmm, quite some manuals seem to be broken :( |
| 12:49:29 | jae | I have a feeling it's all the unstable ones... but it's just a hunch, I didn't really make any scientific study |
| 12:50:23 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 12:50:26 | bluebrother | as far as I can see it's related to some tuner thing. Well, the description of it obviously :) |
| 12:50:41 | bluebrother | but we'll see once my batch run finishes |
| 12:55:20 | jae | How does one upload stuff to the wiki? And... what if I want to supersede a file already up there? |
| 13:00 |
| 13:01:47 | jae | Could someone add me to WikiUsersGroup? Can't even edit my very own page... oh, name is "JaE" (natch) |
| 13:02:33 | bluebrother | jae: that's the wrong name ... |
| 13:04:46 | | Quit antil33t (Read error: 104 (Connection reset by peer)) |
| 13:04:53 | | Join antil33t [0] (n=Mudkips@203-184-54-232.callplus.net.nz) |
| 13:05:07 | jae | How's that the wrong name? |
| 13:06:00 | bluebrother | because we have a real name policy, which is mentioned in the signup page. User names are FirstnameLastname, not SomeNickIWantToUse |
| 13:06:30 | jae | http://www.rockbox.org/wiki/JaE exists... |
| 13:06:31 | | Join Anyone [0] (n=52716adc@giant.haxx.se) |
| 13:07:06 | jae | And it's pretty real... just my initials (just like here on IRC) |
| 13:07:06 | Llorean | jae: Yes, it exists until it's deleted during some cleanup. |
| 13:07:11 | bluebrother | hmm, the signup page changed slighly. It was more obvious in the past, as far as I remember ... |
| 13:07:45 | rasher | jae: The rule is enforced manually |
| 13:07:45 | Llorean | The policy is "real names" not "real initials" though. |
| 13:07:55 | | Quit dfkt_ (Read error: 110 (Connection timed out)) |
| 13:09:20 | Llorean | jae: Basically, any account can be created (because it's impossible to automate 'real name' checks) but there's a manual review (this) before an account can edit pages. |
| 13:09:59 | jae | Okay then... I'll have to reevaluate if I want/have to edit the wiki then |
| 13:10:29 | jae | Note that I do give my real name even here on IRC (check /who, that *is* my real name) |
| 13:12:59 | | Quit Anyone ("CGI:IRC (EOF)") |
| 13:15:11 | Unhelpful | n1s: i don't know, is it? i would guess so as the smaller-table version that won is more ops... |
| 13:16:18 | * | bluebrother added a notice to the wiki signup page. |
| 13:16:44 | n1s | Unhelpful: ok, cachealign might be worth trying then i guess |
| 13:16:46 | | Join robin0800 [0] (n=quassel@general-kt-199.t-mobile.co.uk) |
| 13:17:01 | | Join happytodd [0] (n=7cbbaee5@giant.haxx.se) |
| 13:17:46 | happytodd | Hello =] |
| 13:18:48 | | Quit happytodd (Client Quit) |
| 13:19:32 | | Quit n1s ("Lämnar") |
| 13:29:47 | | Join teru [0] (n=teru@KD059133115245.ppp.dion.ne.jp) |
| 13:31:20 | | Join petur [0] (n=51a46563@rockbox/developer/petur) |
| 13:32:39 | | Quit teru (Client Quit) |
| 13:33:14 | | Join teru [0] (n=teru@KD059133115245.ppp.dion.ne.jp) |
| 13:33:43 | gevaerts | jae: I must say that if you don't mask your real name on IRC I don't see why you would object to the wiki real name policy :) Anyway, it's your decision... |
| 13:34:33 | topik | irc whois names don't show up in google |
| 13:37:10 | gevaerts | true |
| 13:37:50 | | Quit faemir (Read error: 54 (Connection reset by peer)) |
| 13:42:07 | | Join faemir [0] (n=faemir@78.33.109.163) |
| 13:45:33 | | Quit faemir (Read error: 104 (Connection reset by peer)) |
| 13:46:00 | | Join faemir [0] (n=faemir@78.33.109.163) |
| 13:49:44 | | Join Jaykay [0] (n=chatzill@p5DDC5A51.dip.t-dialin.net) |
| 13:50:28 | jae | My real name shows up in google (of course it's on the JaE page) |
| 13:51:20 | Jaykay | hi... the manuals are broken (at least i think they are) |
| 13:51:28 | jae | And since I can't really give my real name (as wiki names don't like umlauts or anything non-ascii... right?), I wanted to use my usual short |
| 13:51:30 | Jaykay | they're not shown in the manuals list |
| 13:51:46 | jae | But whatever... |
| 13:52:42 | bluebrother | Jaykay: we know ... ;-) |
| 13:53:00 | Jaykay | ok, sorry :) |
| 13:53:20 | bluebrother | I'm looking into this right now, but haven't figured whats the problem. My manual build setup is outdated :( |
| 13:53:37 | bluebrother | hehe, no problem. Better than nobody noticing it |
| 13:58:50 | Jaykay | bluebrother: were they broken for a longer time? because in daily/manual there are not even older versions |
| 14:00 |
| 14:00:55 | *** | Saving seen data "./dancer.seen" |
| 14:01:30 | bluebrother | Jaykay: no idea, I just figured today. Still wondering why they are broken. |
| 14:03:54 | bluebrother | hmm, that radio feature for the remote tuner on Ipods seems to be at least part of the problem. |
| 14:04:39 | Jaykay | bluebrother: what/where? :) |
| 14:06:10 | bluebrother | the Ipods now have the feature "radio" enabled, but some key action macros are missing. |
| 14:08:07 | Unhelpful | this certainly seems to say iram is not cached: http://daniel.haxx.se/sansa/memory_controller.txt-0 |
| 14:08:28 | Unhelpful | but then why should a smaller LUT with more setup ops be faster? |
| 14:09:37 | rasher | jae: Using the asciified version of your name is perfectly fine |
| 14:10:53 | | Quit Omlet ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") |
| 14:11:02 | | Join Omlet [0] (i=omlet05@40.10-65-87.adsl-dyn.isp.belgacom.be) |
| 14:11:14 | Jaykay | bluebrother: then they would be broken for a really long time :) i cant find such a commit in the last few days |
| 14:12:08 | bluebrother | hmm, seems r23805 broke it. At least it builds again for the Ipod4G if I add keymap stubs |
| 14:12:25 | bluebrother | would be 11 days |
| 14:14:01 | bluebrother | how does the radio screen look on Ipods with FM remote? |
| 14:14:51 | | Join DerPapst1 [0] (n=DerPapst@p4FE8FEF6.dip.t-dialin.net) |
| 14:16:46 | | Quit AndyIL () |
| 14:20:14 | | Quit liar (Read error: 113 (No route to host)) |
| 14:25:04 | | Quit petur ("real life") |
| 14:31:52 | | Quit DerPapst (Read error: 110 (Connection timed out)) |
| 14:32:22 | | Join DerPapst [0] (n=DerPapst@p4FE8FEF6.dip.t-dialin.net) |
| 14:34:12 | CIA-6 | New commit by bluebrother (r23873): Make manuals for Ipods with remote tuner build again. ... |
| 14:38:04 | jae | rasher: not for me, sorry ;) |
| 14:39:53 | | Quit DerPapst1 (Read error: 60 (Operation timed out)) |
| 14:40:36 | Jaykay | bluebrother: i think this didn't fix it |
| 14:40:58 | jae | Anyone know what I did wrong? Player's rockbox says it's r23863, but I did install r23680. And the files in .rockbox are of today, and not yesterday. |
| 14:41:13 | Jaykay | jae: you wanted to get writing access in the rockbox-wiki, right? |
| 14:41:26 | Jaykay | jae: maybe you didnt overwrite the files... |
| 14:41:50 | jae | Jaykay: yes? |
| 14:42:06 | Jaykay | jae: then you should accept the rules of the wiki... |
| 14:42:19 | Jaykay | which are, use your real name as wikiname. |
| 14:42:22 | jae | Jaykay: Doesn't rbutil do that? Didn't do it manually... |
| 14:42:39 | Jaykay | then try it manually |
| 14:42:40 | jae | Jaykay: not the past tense... |
| 14:42:45 | jae | *note |
| 14:42:47 | Unhelpful | hrm, part of it might be that gcc does unsigned x & 0xffff0000 in a rather braindead way... |
| 14:43:19 | jae | Jaykay: well, looking at the .rockbox dir it seems the files *were* overwritten. |
| 14:43:57 | Jaykay | jae: just do it manually again |
| 14:45:39 | Jaykay | should short select in the wps on e200 brng me to the file browser, database or the one which was opened last? |
| 14:45:52 | Jaykay | *bring |
| 14:49:21 | jae | Now it worked (just redid the upgrade with rbutil)... |
| 14:49:24 | jae | Weird |
| 14:49:47 | jae | FlynDice: and it now detects the SD on boot, so the fix *did* work it seems :D |
| 14:49:54 | | Join DerPapst1 [0] (n=DerPapst@p4FE8EB68.dip.t-dialin.net) |
| 14:50:51 | bluebrother | Jaykay: why not? |
| 14:52:30 | CIA-6 | New commit by teru (r23874): Correct checking return value of open in plugins. |
| 14:58:56 | * | bluebrother spots that it's not the 12th today but the 6th |
| 15:00 |
| 15:01:03 | | Quit DerPapst (Read error: 110 (Connection timed out)) |
| 15:02:43 | topik | bluebrother: did you catch the discussion about the mkamsboot message when trying rbutil on the latest fuze firmware? |
| 15:04:19 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 15:05:03 | kugel | teru: I don't think the search.rock change is correct |
| 15:05:58 | kugel | hm, nevermind, I read strchr not strrchr |
| 15:10:07 | | Join dfkt_ [0] (i=dfkt@unaffiliated/dfkt) |
| 15:10:07 | Jaykay | bluebrother: when are the manuals built again? |
| 15:12:08 | | Join Lss [0] (n=Lss@cm91.delta92.maxonline.com.sg) |
| 15:12:13 | bluebrother | topik: yes, spotted the message. Haven't thought about it yet though. |
| 15:13:00 | bluebrother | Jaykay: the manuals are build somewhen in the night. So unless there still is something wrong (spotted a typo in my commit −− urgh) we should get them back tomorrow |
| 15:13:49 | topik | there's probably not a whole lot to think about it :). i assume it needs a new version to fix it, and then you will probably include the version that supports the latest fuze firmware |
| 15:14:24 | Jaykay | bluebrother: so there's no way to check them without building them "manually"? |
| 15:14:43 | bluebrother | Jaykay: just build them all. That's what I'm doing right now :) |
| 15:15:40 | bluebrother | but there's no trigger for building them on the server, or some kind of build system. The swedes could trigger a build on the server. |
| 15:15:55 | | Quit linuxstb ("Leaving") |
| 15:16:39 | Jaykay | bluebrother: there were more manuals broken than the ipod-manuals... so why should the fix fix it? :) |
| 15:18:40 | bluebrother | this doesn't necessarily mean they are broken −− if the build script simply hangs and gets killed a couple of hours later other manuals might be skipped too. LaTeX can hang with a prompt, and if that happens it's kinda problematic when running from a script |
| 15:19:09 | Jaykay | bluebrother: ok, thanks :) |
| 15:20:03 | bluebrother | I'm a bit surprised though that at least my script hangs. LaTeX should run in nonstopmode for the manual, which means it should simply error out instead of waiting for user input. |
| 15:20:23 | | Quit CIA-6 (niven.freenode.net irc.freenode.net) |
| 15:20:23 | NSplit | niven.freenode.net irc.freenode.net |
| 15:20:23 | | Quit FOAD (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit kadoban__ (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit n17ikh (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit solexx (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit Kitr88 (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit B4gder (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit yosafbridge (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit Sajber^ (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit DerPapst1 (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit faemir (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit dmb (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit jae (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit TaZzZ (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit tarbo (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit gevaerts (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit mt (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit FlynDice (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit killan (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit Byan (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit loyx (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit JdGordon (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit preglow_ (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit topik (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit dionoea (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit SIGSEGV (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit Kohlrabi (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit YPSY (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit zu_ (niven.freenode.net irc.freenode.net) |
| 15:20:23 | | Quit jds2001 (niven.freenode.net irc.freenode.net) |
| 15:20:24 | | Quit Utchybann_ (niven.freenode.net irc.freenode.net) |
| 15:20:24 | | Quit rvvs89 (niven.freenode.net irc.freenode.net) |
| 15:20:24 | | Quit Tuplanolla (niven.freenode.net irc.freenode.net) |
| 15:20:24 | | Quit Torne (niven.freenode.net irc.freenode.net) |
| 15:20:24 | | Quit xavieran (niven.freenode.net irc.freenode.net) |
| 15:20:24 | | Quit Kopfgeldjaeger (niven.freenode.net irc.freenode.net) |
| 15:20:24 | | Quit shodanX_ (niven.freenode.net irc.freenode.net) |
| 15:20:24 | | Quit tha (niven.freenode.net irc.freenode.net) |
| 15:20:24 | | Quit Zambezi (niven.freenode.net irc.freenode.net) |
| 15:20:26 | | Join smogzer [0] (n=quassel@213.13.206.196) |
| 15:20:53 | | Quit thegeek_ (niven.freenode.net irc.freenode.net) |
| 15:20:53 | | Quit Topy44 (niven.freenode.net irc.freenode.net) |
| 15:20:53 | | Quit fxb__ (niven.freenode.net irc.freenode.net) |
| 15:20:53 | | Quit Unhelpful (niven.freenode.net irc.freenode.net) |
| 15:20:53 | | Quit crashd (niven.freenode.net irc.freenode.net) |
| 15:20:53 | | Quit scorche (niven.freenode.net irc.freenode.net) |
| 15:20:53 | | Quit markun (niven.freenode.net irc.freenode.net) |
| 15:20:53 | | Quit fish_ (niven.freenode.net irc.freenode.net) |
| 15:20:53 | | Quit rjg (niven.freenode.net irc.freenode.net) |
| 15:22:25 | | Join linuxstb [0] (n=linuxstb@94-193-103-239.zone7.bethere.co.uk) |
| 15:22:25 | NHeal | niven.freenode.net irc.freenode.net |
| 15:22:25 | NJoin | DerPapst1 [0] (n=DerPapst@p4FE8EB68.dip.t-dialin.net) |
| 15:22:25 | NJoin | faemir [0] (n=faemir@78.33.109.163) |
| 15:22:25 | NJoin | FOAD [0] (n=dok@dinah.blub.net) |
| 15:22:25 | NJoin | kadoban__ [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) |
| 15:22:25 | NJoin | dmb [0] (n=Dmb@unaffiliated/dmb) |
| 15:22:25 | NJoin | n17ikh [0] (n=n17ikh@host-69-59-126-212.nctv.com) |
| 15:22:25 | NJoin | jae [0] (n=jae@HSI-KBW-082-212-058-254.hsi.kabelbw.de) |
| 15:22:25 | NJoin | solexx [0] (n=jrschulz@e176098107.adsl.alicedsl.de) |
| 15:22:25 | NJoin | Kitr88 [0] (i=Kitarist@BSN-143-158-207.dial-up.dsl.siol.net) |
| 15:22:25 | NJoin | B4gder [241] (n=daniel@rockbox/developer/bagder) |
| 15:22:25 | NJoin | TaZzZ [0] (i=GamingEx@hidden.botpack.eu) |
| 15:22:25 | NJoin | tarbo [0] (n=me@unaffiliated/tarbo) |
| 15:22:25 | NJoin | yosafbridge [0] (n=yosafbri@li14-39.members.linode.com) |
| 15:22:25 | NJoin | gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
| 15:22:25 | NJoin | mt [0] (n=mtee@rockbox/developer/mt) |
| 15:22:25 | NJoin | FlynDice [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) |
| 15:22:25 | NJoin | Sajber^ [0] (n=Sajber@c-c33271d5.012-155-73746f22.cust.bredbandsbolaget.se) |
| 15:22:25 | NJoin | killan [0] (n=nnscript@c-94fc70d5.06-397-67626721.cust.bredbandsbolaget.se) |
| 15:22:25 | NJoin | Byan [0] (n=notByan@lackey.csl.mtu.edu) |
| 15:22:25 | NJoin | loyx [0] (n=men@ool-43554637.dyn.optonline.net) |
| 15:22:25 | NJoin | JdGordon [0] (n=jonno@rockbox/developer/JdGordon) |
| 15:22:25 | NJoin | jds2001 [0] (n=jds2001@fedora/jds2001) |
| 15:22:25 | NJoin | xavieran [0] (n=xavieran@ppp118-209-112-86.lns20.mel4.internode.on.net) |
| 15:22:25 | NJoin | Kopfgeldjaeger [0] (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de) |
| 15:22:25 | NJoin | shodanX_ [0] (n=shodanX@jazz.informatik.uni-erlangen.de) |
| 15:22:25 | NJoin | tha [0] (i=1038@ccc2.rbg.informatik.tu-darmstadt.de) |
| 15:22:25 | | Join Zambezi [0] (i=Zulu@unaffiliated/zambezi) |
| 15:22:25 | NJoin | Torne [0] (i=torne@rockbox/developer/Torne) |
| 15:22:25 | NJoin | Tuplanolla [0] (n=jani@unaffiliated/tuplanolla) |
| 15:22:25 | NJoin | rvvs89 [0] (n=ivo@pdpc/supporter/base/rvvs89) |
| 15:22:25 | NJoin | Utchybann_ [0] (n=lolo@ede67-1-81-56-102-26.fbx.proxad.net) |
| 15:22:25 | NJoin | CIA-6 [0] (n=CIA@208.69.182.149) |
| 15:22:25 | NJoin | Kohlrabi [0] (n=Kohlrabi@frustrum.nosebud.de) |
| 15:22:25 | NJoin | topik [0] (i=awesome@wtf.grmpf.org) |
| 15:22:25 | NJoin | zu_ [0] (n=zu@bucketheaded.eu) |
| 15:22:25 | NJoin | SIGSEGV [0] (n=user@61.250.113.98) |
| 15:22:25 | NJoin | dionoea [0] (n=dionoea@yop.chewa.net) |
| 15:22:25 | NJoin | preglow_ [0] (i=thomj@tvilling2.pvv.ntnu.no) |
| 15:22:25 | NJoin | YPSY [0] (n=ypsy@geekpadawan.de) |
| 15:22:40 | NJoin | Topy44 [0] (n=quassel@my.fastsh.it) |
| 15:22:40 | NJoin | thegeek_ [0] (n=nnscript@s168c.studby.ntnu.no) |
| 15:22:40 | NJoin | fxb__ [0] (n=felixbru@85.214.97.64) |
| 15:22:40 | NJoin | scorche [50] (n=scorche@rockbox/administrator/scorche) |
| 15:22:40 | NJoin | Unhelpful [0] (n=quassel@rockbox/developer/Unhelpful) |
| 15:22:40 | NJoin | crashd [0] (i=foobar@lostnode.org) |
| 15:22:40 | NJoin | rjg [0] (i=rgordon@odie.tomelliott.net) |
| 15:22:40 | NJoin | fish_ [0] (n=fish@freigeist.org) |
| 15:22:40 | NJoin | markun [50] (n=markun@rockbox/developer/markun) |
| 15:23:31 | CIA-6 | New commit by bluebrother (r23875): Add missing closing bracket. No idea how that got lost, I'll blame the keyboard. |
| 15:24:51 | Jaykay | bluebrother: a stupid question: why didn't you commit FS #5737? |
| 15:25:13 | Jaykay | it saves the scratchpad in sudoku |
| 15:25:35 | bluebrother | ah, that one. I'd need to resync it first. |
| 15:27:41 | Jaykay | ...well...ok :) |
| 15:27:57 | Jaykay | i just noticed FS #7861 might be out of date |
| 15:28:04 | bluebrother | but I should look at it again :) |
| 15:28:32 | | Quit dfkt (Read error: 110 (Connection timed out)) |
| 15:32:52 | | Join patrakov [0] (n=aep@pppoe-0045.urtc.ru) |
| 15:33:47 | patrakov | hi. how do I use cue files (those that are supposed to apply to whole-disk flac files) in rockbox? |
| 15:34:44 | bluebrother | just play the media file that's accompanying the cue |
| 15:35:10 | linuxstb | ... after enabling cue support in Rockbox |
| 15:35:31 | patrakov | where is it enabled? |
| 15:35:36 | kugel | patrakov: the cue sheet needs to have the same base file name (i.e. excluding extension) and you need to explicetely enable cue sheet supprt |
| 15:35:58 | kugel | it might be in playback settings, not sure though |
| 15:36:00 | linuxstb | patrakov: The manual should describe the details. |
| 15:36:37 | patrakov | thanks |
| 15:36:48 | bluebrother | the only problem is that the manuals are currently broken :) |
| 15:37:00 | linuxstb | bluebrother: All of them? |
| 15:37:03 | * | bluebrother might have svn builds online in a couple of minutes |
| 15:37:25 | bluebrother | linuxstb: not all but most. AFAICS the building stopped somewhere in between. |
| 15:38:53 | linuxstb | patrakov: But just browse the menus, I'm sure you'll find it... You then need to turn your DAP off and on again for the setting to take effect. |
| 15:39:54 | patrakov | found it |
| 15:41:01 | patrakov | and it works |
| 15:45:41 | bluebrother | ok, some svn manuals are up until the official ones are rebuilt: http://www.alice-dsl.net/dominik.riebeling/rockbox/ |
| 15:47:25 | | Join robin0800_ [0] (n=quassel@general-kt-199.t-mobile.co.uk) |
| 15:49:06 | | Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) |
| 15:50:26 | | Quit robin0800 (Read error: 60 (Operation timed out)) |
| 15:51:41 | | Quit teru ("Quit") |
| 15:59:49 | | Join efyx_ [0] (n=efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 16:00 |
| 16:00:48 | | Quit mc2739 ("leaving") |
| 16:00:58 | *** | Saving seen data "./dancer.seen" |
| 16:03:20 | | Join Tomis [0] (n=Tomis@70.134.93.64) |
| 16:05:10 | | Join mc2739 [0] (n=mc2739@rockbox/developer/mc2739) |
| 16:10:16 | | Join alex` [0] (n=user@client-86-31-144-85.watf.adsl.virginmedia.com) |
| 16:10:25 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 16:14:08 | | Join merbanan [0] (n=banan@c-94-255-215-42.cust.bredband2.com) |
| 16:21:00 | | Join cluemore [0] (n=bc65b886@giant.haxx.se) |
| 16:22:04 | cluemore | Hello everyone! I just found Rockbox and it seems to rock. One question: Can Rockbox be easily configured to delete the currently playing song? |
| 16:22:22 | | Quit Jaykay (Remote closed the connection) |
| 16:22:40 | | Quit FOAD (Read error: 110 (Connection timed out)) |
| 16:22:40 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 16:23:31 | | Quit patrakov ("Leaving.") |
| 16:24:42 | | Join ansuz [0] (n=ansuz@dsl093-172-019.pit1.dsl.speakeasy.net) |
| 16:24:58 | cluemore | does anybody know? |
| 16:25:10 | | Join Jaykay [0] (n=chatzill@p5DDC5A51.dip.t-dialin.net) |
| 16:26:17 | Jaykay | cluemore: how about context menu of wps (thats long select on e200) and then delete? |
| 16:27:01 | cluemore | thanks Jaykay, wps? |
| 16:27:05 | | Quit stoffel (Remote closed the connection) |
| 16:27:15 | cluemore | I found the emulator .. I |
| 16:27:20 | Jaykay | while playing screen |
| 16:27:22 | cluemore | will try |
| 16:27:57 | cluemore | cool, If that works I will buy a supported player. Any recommendations? (real cheap for jogging) |
| 16:28:30 | cluemore | deleting songs I dont want to hear while jogging is THE killer feature for me |
| 16:28:51 | Jaykay | i don't know many players, but i think the sansa clip is quite cheap |
| 16:28:56 | Jaykay | and nearly supported |
| 16:29:04 | cluemore | nearly :) ? |
| 16:30:14 | | Nick YPSY is now known as Ypsy (n=ypsy@geekpadawan.de) |
| 16:30:16 | Jaykay | cluemore: afaik some features as recording are missing, but it is working |
| 16:30:32 | Jaykay | *like recording |
| 16:31:13 | cluemore | cool thanks so much Jaykay. You guys seem to do an amazing job. Keep up the great work .. I will go play with the emulator now. Cheers |
| 16:33:17 | Jaykay | cluemore: if you have any further questions, just ask here :) |
| 16:34:56 | Jaykay | bluebrother: if you want to close another FS task, FS #8025 is also out of date |
| 16:35:21 | Jaykay | i think the "searching..." is now gone or displayed only very short |
| 16:36:41 | cluemore | thanks Jaykay, I tried the sansa clip emulator and deleting works, but it still ask for Yes and No etc. How complex is changing that behavior. Is it configurable or hardcoded in the source code? |
| 16:37:40 | Jaykay | cluemore: i think thats "hard-coded"... i think double-pressing the select-button is not that hard ;) |
| 16:37:58 | Jaykay | as an alternative you might learn C and create a patch for that :D |
| 16:38:56 | cluemore | hmm :) .. well I have to long press SELECT then scroll down to delete and then double-press .. |
| 16:39:14 | cluemore | while jogging that is kinda cumbersome |
| 16:39:49 | Jaykay | true |
| 16:40:34 | Jaykay | but nobody wants a delete without a yes/no question... the cahnce that you delete a file by accident is too high |
| 16:40:48 | Jaykay | *chance |
| 16:41:18 | robin0800_ | cluemore: you could just use skip? |
| 16:41:24 | cluemore | ack, I know that I have a very special itch to scratch here .. |
| 16:42:32 | Jaykay | robin0800_: he wants to *delete* a song... |
| 16:42:34 | robin0800_ | cluemore: well I always sync mine against a backup on a computer |
| 16:42:34 | cluemore | robin0800, well the idea is to just dump mp3 an my player and listen to them while jogging and delete everything that I don*t like .. so I evolve my perfect running sound |
| 16:44:18 | cluemore | that is actually so important to me that I might dive into the code ;) .. is compling and installing ones own build very complicated? |
| 16:44:40 | robin0800_ | Jaykay: does the database keep a list of skipped songs in its play count? |
| 16:45:18 | Jaykay | cluemore: which OS do you use? (windows/linux/mac/whatever) |
| 16:45:29 | cluemore | robin800_, that would be a clever solution :) |
| 16:45:30 | Jaykay | robin0800_: i don't think so |
| 16:46:05 | cluemore | I run everything .. Kubuntu on the netbook and Debian on the desktop ( I have OSX and Windows too) |
| 16:46:17 | Jaykay | cluemore: no, it wouldn't... because about 2 people would need it :) |
| 16:46:22 | robin0800_ | Jaykay: so you could use that to find ones skipped? |
| 16:46:58 | Jaykay | robin0800_: afaik the database does *not* keep a list of skipped songs... |
| 16:48:03 | Jaykay | cluemore: http://www.rockbox.org/wiki/LinuxSimpleGuideToCompiling |
| 16:48:08 | jae | But last.fm log does |
| 16:48:22 | jae | Sort of... meaning, you could use it for it |
| 16:49:04 | jae | Because "skipped" means "pressed 'go to next' shortly after it went on" |
| 16:49:26 | Jaykay | jae: have fun with writing a program which extracts skipped songs out of a scrobbler-log, then finds them on your mp3-player and delets them |
| 16:49:38 | | Join gentgeen__ [0] (n=kevin@c-98-236-71-64.hsd1.pa.comcast.net) |
| 16:49:54 | jae | Jaykay: that's really just a SMOP |
| 16:50:12 | Jaykay | jae: then do it |
| 16:50:39 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
| 16:51:01 | jae | As last.fm (or the submit tools, don't know where it's done) already filters "skipped"... you have to have listened to at least 50% of the song for it to "scrobble" |
| 16:51:14 | jae | I'd do it if I needed it... maybe I will |
| 16:51:21 | cluemore | One last question, when I enable voice every command selected will be spoken, right? ( That might be really helpful while jogging ) |
| 16:52:36 | domonoky | cluemore: yes, it will speak the menus and files/folders if set up correctly |
| 16:54:26 | jae | Is there a way to check the status of the DB update (since it happens in the background). Or can one pull it to fg, for that matter? |
| 16:54:44 | cluemore | voice does not work in the emulator, right? |
| 16:57:44 | | Join kugel_ [0] (n=kugel@e178107118.adsl.alicedsl.de) |
| 16:58:19 | kugel_ | Jaykay: I don't think FS #8025 is out of date |
| 16:58:20 | | Join klapaucjusz [0] (n=jch@88-121-49-75.rev.libertysurf.net) |
| 16:58:20 | CIA-6 | New commit by mcuelenaere (r23876): Boomshine: ... |
| 16:58:25 | klapaucjusz | Hi. |
| 16:59:01 | klapaucjusz | Anyone willing to review FS #10832 and FS #10833, in a view to committing them? |
| 16:59:12 | klapaucjusz | That's a total of four patches. |
| 16:59:13 | Jaykay | kugel_:why not? |
| 16:59:28 | klapaucjusz | FS #10832 is about supporting correct but unstreamable mp4 files. |
| 16:59:34 | kugel_ | I think it still happens |
| 16:59:46 | klapaucjusz | FS #10833 is about not crashing on a certain class of broken mp4s. |
| 16:59:51 | kugel_ | it's hard to reproduce but I seem to remember experiencing this once in a while still |
| 17:00 |
| 17:00:12 | kugel_ | and I actually think it's the very same bug as the one after leaving some plugins |
| 17:00:30 | Jaykay | kugel_: i know that i got the "searching..." message quite often a few months/a year ago, and now i don't get it... |
| 17:00:31 | klapaucjusz | (Sorry, a total of 5 patches) |
| 17:01:17 | kugel_ | the bug is not the splash messages, but that the scrollwheel doesn't work if you press a button while that splash |
| 17:01:34 | cluemore | ahh fark .. I will just hop on amazon and buy the Sansaclip :) Longpressing SELECT UP UP SELECT SELECT isn't that bad :) |
| 17:01:35 | | Join fdinel [0] (n=Miranda@modemcable235.127-131-66.mc.videotron.ca) |
| 17:02:03 | kugel_ | and I fixed the logic of that splash, it was intended to show up only after the search takes more than half a second |
| 17:02:12 | cluemore | thanks again, you guys rule :) Cya |
| 17:02:21 | kugel_ | it didn't follow that logic but does now |
| 17:03:41 | | Quit robin0800_ ("http://quassel-irc.org - Chat comfortably. Anywhere.") |
| 17:04:00 | | Join robin0800 [0] (n=quassel@general-kt-199.t-mobile.co.uk) |
| 17:05:50 | Jaykay | kugel_: aaaah, now i know.... that also "works" with usb-mode |
| 17:05:58 | | Quit cluemore ("CGI:IRC (EOF)") |
| 17:07:40 | Jaykay | kugel_: wasn't there another task for that? |
| 17:08:11 | | Quit kugel (Read error: 113 (No route to host)) |
| 17:09:49 | * | klapaucjusz is feeling ignored |
| 17:11:24 | kugel_ | I think so yes |
| 17:14:54 | | Quit kugel_ ("exit(0);") |
| 17:15:09 | | Join liar [0] (n=liar@83.175.83.185) |
| 17:25:04 | | Nick fxb__ is now known as fxb (n=felixbru@85.214.97.64) |
| 17:28:40 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 17:30:53 | Jaykay | FS #8025 and FS #7332 are the same so i suggest closing the first of them |
| 17:33:57 | | Join Tomis2 [0] (n=Tomis@70.134.93.50) |
| 17:37:56 | alex` | Should simulator build DEBUGF's go to standard out or are they for target builds only? |
| 17:41:17 | | Quit Tomis (Read error: 110 (Connection timed out)) |
| 17:41:18 | | Nick Tomis2 is now known as Tomis (n=Tomis@70.134.93.50) |
| 17:41:37 | alex` | klapaucjusz: Maybe try the mailing list? |
| 17:42:01 | alex` | klapaucjusz: BTW do you publish your GIT tree? |
| 17:44:45 | n1s | alex`: DEBUGF works for sim |
| 17:46:37 | klapaucjusz | alex`: no, I don't. |
| 17:46:44 | | Join JdGordon1 [0] (n=jonno@c-24-22-210-83.hsd1.wa.comcast.net) |
| 17:46:58 | klapaucjusz | And I'd rather not subscribe to Yet Another Mailing List. |
| 17:47:04 | klapaucjusz | Any chance you could do it for me? |
| 17:48:47 | alex` | klapaucjusz: OK, I'll I'll send and email |
| 17:48:56 | klapaucjusz | By the way, Alex, perhaps you know what's the situation with FAAD. |
| 17:49:09 | klapaucjusz | The latest version is pure GPL, so it should be able to go into RB. |
| 17:49:47 | klapaucjusz | The old version that's in RB has a number of known bugs (ringing at low bitrates). |
| 17:56:13 | alex` | klapaucjusz: I'm afraid my knowledge of FAAD is limited to hacking around with the metadata, most of which was just to work with my other halfs m4a's (I use ogg). |
| 17:56:55 | alex` | klapaucjusz: But I don't see any reason why the latest couldn't be ported in, however I don't know how hacked the original was to fit it into the rockbox codec style |
| 17:57:32 | JdGordon1 | is it gplv2 r v3? |
| 17:57:36 | JdGordon1 | or* |
| 17:58:00 | klapaucjusz | 2 or later |
| 17:58:44 | klapaucjusz | As published in June 1991. |
| 17:58:47 | klapaucjusz | Looks ok to me. |
| 17:58:48 | alex` | Sounds like apps/codecs/libfaad/README.rockbox is out of date then? |
| 17:59:24 | klapaucjusz | Indeed. Hold on, I'll find you a ref. |
| 18:00 |
| 18:00:37 | n1s | alex`: well, it's mostly correct just they changed it back again |
| 18:01:01 | *** | Saving seen data "./dancer.seen" |
| 18:02:14 | n1s | http://www.audiocoding.com/faad2.html mentions gplv2 now |
| 18:02:17 | alex` | klapaucjusz: Most of the compile stuff seems to be in svn r7700 and doesn't look that scary. It may be the best thing to do is do a CVS diff of the libfaad tree between the Rockbox snapshot and now and then seen if that will apply (modulo rockboxisms) |
| 18:04:26 | klapaucjusz | alex`: or use git to do the merge. |
| 18:04:50 | klapaucjusz | I'd really rather use a 3-way merge. |
| 18:12:47 | | Join hannesd [0] (n=hd@HSI-KBW-095-208-052-100.hsi5.kabel-badenwuerttemberg.de) |
| 18:16:03 | | Quit niekie (Remote closed the connection) |
| 18:16:27 | | Join niekie [0] (i=quasselc@CAcert/Assurer/niekie) |
| 18:16:40 | | Quit liar (Read error: 113 (No route to host)) |
| 18:17:30 | | Join Kitar|st [0] (n=Kitarist@BSN-61-87-230.dial-up.dsl.siol.net) |
| 18:27:24 | | Join liar [0] (n=liar@83.175.83.185) |
| 18:35:32 | | Quit Kitr88 (Connection timed out) |
| 18:35:51 | | Join Kitr88 [0] (i=Kitarist@BSN-142-77-103.dial-up.dsl.siol.net) |
| 18:39:05 | | Quit Kitar|st (Connection timed out) |
| 18:40:48 | | Quit saratoga (niven.freenode.net irc.freenode.net) |
| 18:40:48 | NSplit | niven.freenode.net irc.freenode.net |
| 18:42:30 | | Quit hannesd (Read error: 110 (Connection timed out)) |
| 18:42:31 | NHeal | niven.freenode.net irc.freenode.net |
| 18:42:31 | NJoin | saratoga [0] (i=9803c6dd@rockbox/developer/saratoga) |
| 18:43:00 | | Quit tha (Remote closed the connection) |
| 18:43:18 | | Join tha [0] (n=philippk@ccc2.rbg.informatik.tu-darmstadt.de) |
| 18:45:42 | | Quit robin0800 (Remote closed the connection) |
| 18:47:41 | | Quit Jaykay ("ChatZilla 0.9.85 [Firefox 3.5.5/20091102152451]") |
| 18:48:15 | | Quit tha (Remote closed the connection) |
| 18:48:16 | | Quit saratoga (niven.freenode.net irc.freenode.net) |
| 18:49:25 | NJoin | saratoga [0] (i=9803c6dd@rockbox/developer/saratoga) |
| 18:53:01 | | Join shai [0] (n=Shai@l192-117-110-233.cable.actcom.net.il) |
| 18:53:02 | soap | would allow one WPS to work on multiple targerts with the same screen resolution but different volume ranges > 0dB |
| 18:53:33 | Llorean | Don't they already? |
| 18:53:46 | | Join tha [0] (n=philippk@ccc2.rbg.informatik.tu-darmstadt.de) |
| 18:53:52 | Llorean | I thought if the range goes >0db the last part of the conditional is just ignored. |
| 18:53:57 | Llorean | Er *doesn't* go >0db |
| 18:54:04 | JdGordon1 | i belive so |
| 18:54:08 | JdGordon1 | I'd assume so |
| 18:54:20 | JdGordon1 | .me checks |
| 18:54:30 | soap | I believe the claimant's problem in this theoretical case was no resolution > 0dB |
| 18:54:47 | JdGordon1 | there sholdnt be |
| 18:54:57 | Llorean | So if you have <a|b|c|d|e|f>, f only shows up on targets that go greater than 0db, e is always *only* 0db, a is always mute, and b,c,d are divided evenly up for the volume range below 0db |
| 18:55:07 | soap | as in there shouldn't be with the current tag, or there shouldn't be ever, JdGordon ? |
| 18:55:13 | JdGordon1 | I think we shold shut him up with "By design" |
| 18:55:39 | Llorean | soap: How do you propose to add resolution above 0db then? I misunderstood something along the way. |
| 18:56:22 | JdGordon1 | soap: both.. although I'd like to limit all my targets to 0d |
| 18:56:26 | JdGordon1 | dB if i could |
| 18:56:34 | JdGordon1 | >0 is baaad |
| 18:56:58 | n1s | JdGordon1: i think that suggestion has been shut down many times :) |
| 18:56:59 | soap | I was just playing with his idea of an output-power-agnostic 0-100%... and saying that IF you modified his proposal and had the tag return something different for values > 0 dB you would kill two birds with one stone. |
| 18:57:04 | soap | bird one being his desire |
| 18:57:22 | soap | bird two being the fact that the current tag has no resolution at volumes > 0dB IIUC. |
| 18:57:23 | Llorean | soap: Return something different? |
| 18:57:47 | Llorean | I mean it's a conditional tag, so it just looks like ?pv<mute|val1|val2|val3|val4|0db|>0db> |
| 18:57:55 | soap | Llorean, ie the theoretical players I mentioned in the other room. |
| 18:58:06 | n1s | shot down, even |
| 18:58:18 | Llorean | Yeah, but how would you modify that line in a way that it allows multiple images above 0db? |
| 18:58:34 | Llorean | Basically, how do you have two arbitrary length segments in a <|> block? |
| 18:58:37 | n1s | i don't really understand why people are opposed to an optional volume limit though |
| 18:58:43 | JdGordon1 | soap: sure, but I think both birds arnt worth the effort... it means adding a new tag for it.. you cant overload the %pv to do it |
| 18:58:48 | | Quit tha (Remote closed the connection) |
| 18:58:48 | Llorean | Having one is pretty easy since you have a fixed number of values before and after the arbitrary length section |
| 18:58:49 | | Join toffe82 [0] (n=chatzill@75.3.221.27) |
| 18:59:23 | soap | by returning a different value based on the capabilities of the player one WPS could serve two hardwares, one with green bars 0-100 and one with green bars 0-80 and red bars 81-100 (for example of a player which crosses the 0 dB boundary at 80% of range) |
| 18:59:33 | JdGordon1 | n1s: did you figure out your menu question? |
| 18:59:42 | Llorean | soap: What do you mean by "returning"? |
| 18:59:57 | | Join CaptainKewl [0] (n=jason@64-121-176-61.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 19:00 |
| 19:00:04 | Llorean | WPS tags don't have a concept of what the actual volume range is. |
| 19:00:07 | JdGordon1 | soap: OH, you want to only change it for targets without the >0 volume? |
| 19:00:15 | soap | the WPS looks for image X or image Xn if the volume is > 0dB. |
| 19:00:25 | soap | Llorean, |
| 19:00:33 | n1s | JdGordon: yes, i got the menu item to disappear when it shouldn't be shown but it led to a deeper problem that i didn'ẗ solve |
| 19:00:53 | soap | and if Xn isn't available it goes ahead and uses image X |
| 19:01:14 | n1s | also the menu was abit weird, a left press would exit the menu, not just go up a level |
| 19:01:15 | Llorean | soap: WPSes allow arbitrarily named image files. Might even be a bitmap strip. |
| 19:01:25 | soap | so? |
| 19:01:33 | soap | you can still add a prefix. |
| 19:01:43 | soap | regardless of how the file is named, or which strip is used. |
| 19:01:50 | JdGordon1 | n1s: more info if you want help :) |
| 19:02:17 | Unhelpful | n1s: i think now there should be just one modes/flags value. also that BS_0_X is as clear as _DONTCARE and can be default. did we ever figure out if av_log2 can see a 0, and if the result matters? |
| 19:02:19 | Llorean | soap: If the tag is <img-mute|strip|img-full|img-caution> where does the prefix go? |
| 19:02:25 | soap | if the second strip (or image) is there it would use that for > 0dB volumes. |
| 19:02:29 | Llorean | Or if the tag is <img-mute|strip|img-caution>? |
| 19:02:40 | soap | (I should have said suffix) |
| 19:02:46 | Llorean | Well, suffix too |
| 19:02:47 | n1s | JdGordon1: i'll ping you if i decide to look at it again :) |
| 19:03:01 | JdGordon1 | email me if im not around |
| 19:03:25 | soap | Llorean, this would be his 0-100% idea. |
| 19:03:37 | Unhelpful | flac has a lead-zero-count, also, right? i think the only "personalities" i'll worry about for now are BS_LOG2 and BS_CLZ. BS_CTZ could be added if anything needs it |
| 19:03:56 | soap | mute would be the first image (or first strip position) and "full" would be the branch point. |
| 19:04:16 | Llorean | soap: What do you mean by "branch point" in terms of WPS tags? |
| 19:04:24 | Llorean | What would the actual tag for this look like? |
| 19:04:28 | n1s | Unhelpful: no i don't know if it ever gets a 0, that it worked even when 0 gave a value of -1 suggests it is at least uncommon for flac |
| 19:04:35 | | Join GeekShado_ [0] (n=Antoine@104.190.204-77.rev.gaoland.net) |
| 19:04:42 | Llorean | soap: That's what I'm trying to understand - how you would write this in a WPS tag. |
| 19:05:07 | soap | just like the current one. |
| 19:05:29 | JdGordon1 | %?pv<%?"gt0"<caution>|mute|strip...> ? |
| 19:05:37 | soap | except: no mute image, no caution image. |
| 19:05:52 | soap | just the strip or list of arbitrary images. |
| 19:05:56 | n1s | Unhelpful: alac calculates leading zeroes, don't think flac does |
| 19:06:27 | Llorean | soap: So it just divides the images across the whole volume range, and if the volumes are above 0db it uses a secondary automatically selected alternate version of the image (if present)? |
| 19:06:28 | soap | the difference is that when the player is at >= 0 dB the WPS looks for IMGSTRIPx instead of IMGSTRIP |
| 19:06:35 | soap | right |
| 19:07:08 | JdGordon1 | soap: if you want to add resolution >0 the way to do that would be add a token like above and use that for the conditional for the >0 block |
| 19:07:09 | n1s | the alac clz has an optimization that only tests for set bits in the lower 16 though |
| 19:07:17 | Llorean | soap: It seems like that might create some odd effects between targets |
| 19:07:24 | soap | Llorean, example? |
| 19:07:29 | Llorean | soap: One target might have three bars of yellow and two of red, while another has five bars of yellow. |
| 19:07:41 | Llorean | Assuming each bar is 20% volume, for example, and it goes way beyond 0db. |
| 19:07:45 | soap | correct |
| 19:08:21 | soap | and is that not showing the user exactly what is going on w/o resorting to numerical representation? |
| 19:09:11 | JdGordon1 | I dont understand "(10:06:30 AM) soap: the difference is that when the player is at >= 0 dB the WPS looks for IMGSTRIPx instead of IMGSTRIP" at all... remember the conditional values can be anything.. including other conditionals |
| 19:09:14 | Llorean | soap: I'm not really sure |
| 19:09:35 | Llorean | soap: Does it show an alternate image *immediately* upon crossing the 0db mark (possibly swapping img5 with img5x)? |
| 19:10:11 | Llorean | JdGordon1: I can only see it working with strips, since they're handled specially for arbitrary length conditionals right? |
| 19:10:42 | JdGordon1 | the pv doesnt take a strip name.. it takes a "value" for each image you want to display |
| 19:10:56 | Llorean | Ah, I thought it could use a strip name for the part between mute and 0db |
| 19:11:00 | JdGordon1 | no |
| 19:11:03 | Llorean | Ah well |
| 19:11:04 | Llorean | NEver mind then |
| 19:11:25 | JdGordon1 | that would be nice though |
| 19:11:25 | Llorean | JdGordon1: Well his proposed one is a second tag that is *just* an arbitrary length conditional |
| 19:11:29 | Llorean | So it should be able to take a strip name. |
| 19:11:49 | JdGordon1 | strips can only go up to 26 values i think... |
| 19:11:51 | JdGordon1 | or 52 |
| 19:12:39 | soap | JdGordon, being a conditional for other tags (vs loading of images) is not a case I considered. |
| 19:12:39 | JdGordon1 | and there is a very big difference between %?xx<stripname> and %?<a|b|c|d> in the skin handling code |
| 19:13:09 | | Join pamaury [0] (n=pamaury@88-123-149-12.rev.libertysurf.net) |
| 19:13:21 | Llorean | soap: That was part of what I was trying to understand is how the tag would "know" things about the images. |
| 19:13:54 | Unhelpful | n1s: was it alac? :/ |
| 19:14:22 | soap | adding a token to the current tag appears (at first glance) to be problematic. For if you don't know the numerical range of your target, how do you decide how many steps to create from mute to 0 and how many steps do you create from 0 to max? |
| 19:14:27 | n1s | Unhelpful: yeah alac was the first place i used the __builtin_clz |
| 19:14:31 | Llorean | I can see it working if it *requires* a strip. And if a target had a range of ~80 going up to +6 (Clip and similar I think) and a max of 52 images that'd still be 3-4 images for the >0 range adding some degree of extra precision |
| 19:14:36 | Llorean | Still, that's if you use *52* volume images. |
| 19:14:42 | n1s | Unhelpful: why :/ ? |
| 19:14:46 | Llorean | If you use a more reasonable 10-15 there's no benefit on our current tag. |
| 19:14:57 | soap | You're forced to either code for specific targets (not specific resolutions) or live with the two sides of the scale being out of balance. |
| 19:14:59 | Unhelpful | n1s: just my memory going. ;) |
| 19:15:06 | Llorean | soap: What do you mean? |
| 19:15:32 | n1s | faad also calculates leading zeroes too |
| 19:15:40 | n1s | s/also// |
| 19:15:54 | Llorean | soap: Our current tag doesn't require a knowledge of steps. It's basically <mute | (any number of images representing percentages) | 0db | caution> |
| 19:15:59 | soap | Llorean, wasn't JdGordon proposing to add an additional token to the current tag to cover the > 0dB range the same way the <0dB range is covered? |
| 19:16:01 | Unhelpful | you mean wl_min_lzc? if you look at what it actually calculates it's log2 + 1... |
| 19:16:14 | Llorean | soap: I don't think so. |
| 19:16:15 | * | JdGordon1 butts in with technical issues |
| 19:16:37 | soap | <JdGordon1> soap: if you want to add resolution >0 the way to do that would be add a token like above and use that for the conditional for the >0 block |
| 19:16:38 | Unhelpful | and then both callsites do if(result) result−−; |
| 19:16:39 | JdGordon1 | 1) any token needs to be able to go anywhere any other token can go (so as values in conditionals) |
| 19:16:55 | Llorean | soap: Ah, missed that somehow. |
| 19:16:56 | JdGordon1 | 2) an image strip displayer token would need to be added to do what you want |
| 19:17:06 | n1s | Unhelpful: aha |
| 19:17:18 | JdGordon1 | 3) 2 is impossible (right now at least) because one token cant know the value of another token |
| 19:17:26 | JdGordon1 | it doeesnt work that way! |
| 19:17:54 | JdGordon1 | soap: I dont see the problem of having the scales differ... |
| 19:17:59 | Llorean | soap: Still, if you build an image 26 pixels wide for (mute to 0) and 4 pixels wide for (0 to max) you can divide either image across an arbitrary range of db splitting it evently, but you do end up with 1 pixel of yellow != 1 pixel of red. |
| 19:18:04 | JdGordon1 | either way its an arbitrary scale |
| 19:18:44 | * | Llorean still doesn't quite get why you need resolution above 0db without being exposed to the db value, though. |
| 19:18:50 | Unhelpful | if the log2 is 0->0 it can just use log2 and skip the if... although for some reason doing so seems to have *slowed* it.. |
| 19:18:52 | soap | JdGordon, Llorean - correct. The scales on the two sides of 0 won't match if you don't take the specific target into account. |
| 19:18:58 | Llorean | You can *hear* that the volume's changing, and the numbers above 0db don't serve a realistic purpose. |
| 19:19:16 | soap | that argument can be made for that below 0 as well, no? |
| 19:19:21 | JdGordon1 | yes |
| 19:19:29 | Llorean | soap: yes it can, which is why the default WPS uses an image. |
| 19:19:45 | Llorean | Though I personally need to know where -25 (or approximately -25) is, and the image isn't fine grained enough for that generally |
| 19:19:47 | Llorean | Depending on target. |
| 19:19:50 | soap | then why selectively use the argument for the >0 case? |
| 19:20:12 | JdGordon1 | because <0 is important, 0 is important and >0 is important |
| 19:20:49 | JdGordon1 | the fact is that more targets have more vbalues <0 than >0 so its nicer to give them more informtion there |
| 19:21:06 | | Quit GeekShadow (Read error: 110 (Connection timed out)) |
| 19:21:11 | JdGordon1 | we could of course split it down the middle.... <mute|a|b|c|...|0...||d|e|f> |
| 19:21:24 | JdGordon1 | but that would be stupid :p |
| 19:22:12 | Llorean | soap: I guess the image doesn't serve much of a realistic purpose in general other than "if it's more than 3/4 full I probably want to turn it down before putting on my headphones" |
| 19:22:29 | Llorean | As an approximation it's great, but I'm not sure how much fine-grained approximation you ever need that we'd need to add more detail above 0db |
| 19:23:25 | soap | I don't know how many people frequently use the range > 0dB, I was just attempting to toss around an agnostic solution which didn't discriminate based on the 0dB threshold while still respecting it enough to show it. |
| 19:23:46 | linuxstb | klapaucjusz: Looking at FS #10832, do I understand correctly that it's still causing the codec to seek to the end of the file and hence cause a rebuffer? (the main objection to FS #10160 IIUC) |
| 19:23:54 | Llorean | JdGordon1: Could a conditional be made to accept to single images, or two strips? |
| 19:24:06 | JdGordon1 | no |
| 19:24:12 | JdGordon1 | single image yes... strips no |
| 19:24:13 | | Quit pixelma (Nick collision from services.) |
| 19:24:15 | | Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) |
| 19:24:19 | JdGordon1 | read technical butting in above |
| 19:24:27 | | Quit amiconn (Nick collision from services.) |
| 19:24:31 | | Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) |
| 19:24:35 | | Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) |
| 19:24:45 | Llorean | JdGordon1: none of those three points say anything about a tag not accepting two strips |
| 19:24:46 | | Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) |
| 19:24:58 | Llorean | JdGordon1: I'm thinkingg like a vs? tag (volume safe) that's a conditional for Yes and No (<=0db, >0db) |
| 19:25:05 | JdGordon1 | strips are something that would be nice, but technically nodo right now |
| 19:25:16 | Llorean | Don't we already do strips? |
| 19:25:39 | JdGordon1 | not to my knowledge... we do strips but each image needs to be drawn individually |
| 19:25:47 | klapaucjusz | linuxstb: no. |
| 19:25:51 | klapaucjusz | I mean, sometimes. |
| 19:26:01 | Llorean | JdGordon1: Maybe I"m thinking of some patch |
| 19:26:07 | JdGordon1 | probably |
| 19:26:13 | klapaucjusz | (1) for a proper streamable mp4 (the only kind we support right now), we behave just like now. |
| 19:26:43 | klapaucjusz | (2) for an unstreamable mp4 (the kind that has the moov chunk after the mdat chunk), it will cause a seek and possibly a rebuffer. |
| 19:26:58 | Llorean | JdGordon1: I seem to recall a patch that, for certain tags, could just take a strip and divide its sub-images across however many values the conditional has (or if arbitrary, use as many values as there are images in the strip) |
| 19:27:02 | klapaucjusz | So there is no regression −− the only case where we're inefficient, is the case that's not supported at all right now. |
| 19:27:12 | JdGordon1 | once again, we dont want to force token knowlegde on another token.. we dont want to add dependancies between tokens... and one cant find out the value of another |
| 19:28:01 | klapaucjusz | See the code in demux.c around line |
| 19:28:33 | klapaucjusz | Sorry, demux.c around line 767, in the patch called "Support for unstreamable AAC (mp4) files." |
| 19:28:55 | JdGordon1 | Llorean: yeah, I think i remember it also.. but thats something that may be nice, but imho not wanted |
| 19:29:30 | Llorean | JdGordon1: Fair enough |
| 19:29:42 | Llorean | Okay then. |
| 19:29:45 | Llorean | You need two tags. |
| 19:29:53 | JdGordon1 | but adding a token to say if its >0 and by how much would be fine |
| 19:29:59 | klapaucjusz | linuxstb: do you want me to add the above explanation to the ticket? |
| 19:31:00 | Llorean | JdGordon1, soap: How about two tags. A full-range percent volume, and a "is it safe?" volume tag. So for the swapping between alternate images, you use %vs<%percent using yellow images | %percent using red images> |
| 19:31:04 | linuxstb | klapaucjusz: You could do, but that's what I understood anyway (I was just double-checking). So the problem Lear mentioned in his comments to FS #10160 still exists... |
| 19:31:06 | Llorean | So you get soap's "switch upon crossing 0" |
| 19:31:12 | Llorean | but neither tag has to know about the other ones |
| 19:31:54 | soap | Interesting idea - but no need to sell me. ;) I was just kicking the can around trying to envision a mutual solution. |
| 19:32:16 | Llorean | soap: Well, I was just trying to figure out how to address that "need" within existing limitations. |
| 19:32:57 | klapaucjusz | linuxstb: I don't understand. |
| 19:33:08 | klapaucjusz | What lear pointed out was a regression. |
| 19:33:24 | klapaucjusz | There is no regression in this code. |
| 19:33:54 | klapaucjusz | For unstreamable files, there is a single seek (i.e. one forward, one backwards) at the beginning of playback. |
| 19:34:17 | klapaucjusz | The single seek is used to parse the metadata, which is then buffered for the rest of the track. |
| 19:34:30 | klapaucjusz | There is no seeking during playback, just the one initial seek. |
| 19:34:34 | linuxstb | klapaucjusz: No, it may not be a regression, but it's not the way we want it to be implemented. And no, it's not a seek, it's an "advance_buffer", which causes the buffering code to potentially discard what has been loaded. |
| 19:34:35 | JdGordon1 | Llorean: imo.. overkill |
| 19:34:44 | * | JdGordon1 really doesnt see the problem with the current token |
| 19:34:45 | klapaucjusz | Isn't that just the strategy that lear suggests? |
| 19:35:01 | klapaucjusz | Okay, so how do you want it to be implemented? |
| 19:35:06 | | Join Tomis2 [0] (n=Tomis@70.134.97.99) |
| 19:35:44 | linuxstb | klapaucjusz: No. There's a difference between the metadata code reading/seeking (it has direct access to the file descriptor and uses disk I/O) and the codec itself reading/seeking (it uses the audio buffering API). |
| 19:36:32 | linuxstb | klapaucjusz: The idea is that the metadata parser would read the required data from the end of the file, and store that somewhere for the codec to use, so the codec doesn't need to seek again to the end of the file. |
| 19:36:39 | klapaucjusz | I see. |
| 19:36:42 | klapaucjusz | No problem. |
| 19:36:47 | klapaucjusz | Where do I put it? |
| 19:36:54 | linuxstb | klapaucjusz: That's the problem ;) |
| 19:37:13 | n1s | linuxstb: have you seen FS #10690, iirc you originally ported alac? |
| 19:38:02 | klapaucjusz | An alternative would be to allow the codec to do open/lseek/close on the file underlying the buffered stream. |
| 19:38:31 | linuxstb | klapaucjusz: Not really, as that would mean spinning the disk up (on hard disk targets). |
| 19:38:54 | klapaucjusz | I think we'll have to live with that. |
| 19:39:22 | klapaucjusz | Unless we stash the full mp4 metadata permanently with the RockBox metadata, we are going to spin up the disk when reading an unstreamable mp4. |
| 19:39:27 | klapaucjusz | There's just no way around it. |
| 19:40:25 | klapaucjusz | (And we don't want to hold on to the mp4 metadata −− it can be very large.) |
| 19:41:01 | | Join tha [0] (n=philippk@ccc2.rbg.informatik.tu-darmstadt.de) |
| 19:41:50 | | Quit shai (Read error: 60 (Operation timed out)) |
| 19:42:55 | | Join shai [0] (n=Shai@l192-117-110-233.cable.actcom.net.il) |
| 19:45:36 | | Join portwolf [0] (n=portwolf@unaffiliated/portwolf) |
| 19:45:40 | portwolf | hey ppl |
| 19:46:05 | | Quit tha (Remote closed the connection) |
| 19:46:44 | portwolf | ive got an ipod video 30 gig, trying to get down the install manual from your page i saw that the links are dead, how come? and where could i get them? |
| 19:46:50 | linuxstb | klapaucjusz: Disk I/O isn't even in the (playback) codec API. Hopefully Lear will see your patch and comment on it - I'm sure he has ideas about how to do this nicely. |
| 19:46:55 | portwolf | i am using linux (arch) here |
| 19:47:12 | linuxstb | portwolf: What links? The links to the manual? |
| 19:47:17 | alex` | FWIW I don't think its worth leaving one set of m4a's unplayable because there is a theoretical better solution w.r.t. seeking if "normal" m4a's are unaffected |
| 19:47:26 | portwolf | linuxstb: yes |
| 19:47:42 | portwolf | http://www.rockbox.org/manual.shtml <- those links |
| 19:47:59 | portwolf | see for yourself: click on "online" below the ipod video sign |
| 19:48:01 | linuxstb | Yes, we know about that. Try this - http://www.alice-dsl.net/dominik.riebeling/rockbox/rockbox-ipodvideo-r23875-091206.pdf |
| 19:48:28 | portwolf | big thanks! |
| 19:48:30 | linuxstb | (the official versions should be fixed tomorrow) |
| 19:48:38 | portwolf | alright |
| 19:50:26 | Unhelpful | perhaps manual should be part of the build system :) |
| 19:51:11 | | Quit Tomis (Read error: 110 (Connection timed out)) |
| 19:51:11 | | Nick Tomis2 is now known as Tomis (n=Tomis@70.134.97.99) |
| 19:51:24 | n1s | it should, broken manual builds are often undetected for quite some time |
| 19:52:38 | linuxstb | Plus not delete the old one if the new build fails... |
| 19:52:56 | klapaucjusz | linuxstb: while I have your ear, could you please give me write access to the wiki? Username is JuliuszCh. |
| 19:53:13 | * | Unhelpful is very confused by this, and wondering if he's wrong somewhere about what he built and tested |
| 19:54:01 | Llorean | klapaucjusz: You're supposed to use your full name. |
| 19:55:06 | klapaucjusz | And in addition, could you please commit the two patches in FS #10833, which should be uncontroversial. |
| 19:55:25 | klapaucjusz | Llorean: it's rather long. I've already compromised, I usually like to use the username jch. |
| 19:55:58 | Llorean | klapaucjusz: Didn't you think you should ask if you could have an exception before unilaterally deciding to compromise? Usually a compromise is between two people, not a single person and written rules. |
| 19:56:38 | klapaucjusz | Llorean: are you trying to be a free software project, or a bureaucracy? |
| 19:56:48 | JdGordon | no |
| 19:57:08 | klapaucjusz | My personal details are available on my user page, that's the important part, isn't it? |
| 19:57:21 | | Join panni_ [0] (i=hannes@ip-95-222-21-143.unitymediagroup.de) |
| 19:57:24 | Unhelpful | wl_min_lzc and floor_log2 in faad are both based on the same algorithm, which fills in all bits below the highest set bit, and then does a population count. replacing floor_log2 with with the debruijn-ish version provides a small speedup, replacing it with the new av_log2 after a small fix is faster still, but replacing wl_min_lzc slows things down again :/ |
| 19:57:35 | Llorean | klapaucjusz: If you're not afraid of making them available, why didn't you simply use your whole name like it asked? |
| 19:57:46 | Unhelpful | hrm, and now i can't duplicate my "good" benchmark :/ |
| 19:58:59 | klapaucjusz | Llorean: are you actively trying to discourage potential contributors by imposing arbitrary bureaucratic constraints? |
| 19:59:23 | Llorean | klapaucjusz: No offense but it says something when someone's primary objection to do something is simply the fact that someone asked them to. |
| 19:59:41 | kkurbjun | Juliusz, Rockbox just requires that all commits be done with the person's full name, it looks like it is on your website, but it is a bit difficult to track down on the rockbox pages: http://www.pps.jussieu.fr/~jch/ |
| 19:59:48 | n1s | Unhelpful: strange, no dircache weirdness this time? :) |
| 20:00 |
| 20:00:03 | Unhelpful | n1s: that was on beast. i don't actually *use* my e200. ;) |
| 20:00:29 | Llorean | klapaucjusz: The "real names to contribute to the wiki" policy is a long standing one and rather benign. There's always going to be some restriction, so it's *always* going to discourage someone. |
| 20:00:44 | Llorean | There are other people who will be unwilling to register at all. |
| 20:00:52 | JdGordon | can I get more testing on FS #10824 please? I'm more and more confidant that its good to go in today... |
| 20:00:54 | kkurbjun | I don't think it's a written rule that you have to have your full name in the tracker or wiki, but it is needed for a commit and it makes it alot easier to find if it's all in there |
| 20:01:02 | *** | Saving seen data "./dancer.seen" |
| 20:01:03 | Llorean | kkurbjun: It is in fact written for the wiki |
| 20:01:08 | Llorean | It explicitly says not to use initials. |
| 20:01:13 | linuxstb | kkurbjun: It's stated on the registration page. |
| 20:01:36 | kkurbjun | JdGordon, I found some more bugs in the patch, I will post them on FS later today, it is looking really good with the latest update though |
| 20:02:04 | kkurbjun | Llorean, linuxstb, my mistake |
| 20:02:14 | JdGordon | kkurbjun: sweet.. big bugs or niggly ones? |
| 20:02:22 | | Join tha [0] (i=1038@ccc2.rbg.informatik.tu-darmstadt.de) |
| 20:02:44 | JdGordon | bah, splash leaves crap behind |
| 20:02:49 | klapaucjusz | Folks, chill out. |
| 20:03:22 | kkurbjun | they are smaller ones, but plugins are working worse than before, and the album art doesn't display if music is already playing when you switch from none to a theme |
| 20:03:22 | klapaucjusz | In order to try to contribute to Rockbox, I had to (1) register, (2) provide a valid e-mail address, (3) go through the silly e-mail validation rigmarole. |
| 20:03:26 | klapaucjusz | Fair enough. |
| 20:03:40 | klapaucjusz | But once I did all of that, I still have to beg on the IRC channel just to get write access to the wiki? |
| 20:03:49 | Llorean | klapaucjusz: In order to contribute to Rockbox you need to do none of those. |
| 20:03:51 | klapaucjusz | And I'm being told that I didn't choose the right username? |
| 20:04:03 | * | klapaucjusz gives up on gaining write access to the wiki. |
| 20:04:07 | Llorean | In order to edit the wiki you need to do all of those, plus establish you're a human being by asking here *and* sign up with a name that meets the guidelines. |
| 20:04:10 | soap | the registration page is clear on RealNames for the wiki |
| 20:04:22 | Llorean | klapaucjusz: It sounds like you're blaming us because you didn't read it? |
| 20:04:37 | linuxstb | klapaucjusz: I agree it sounds a bit bureaucratic, but every other wiki user has followed that convention, and the wiki admin regularly goes through and cleans up names which are not in FirstnameLastname format. We don't want to make a big deal of it... |
| 20:04:42 | kkurbjun | klapaucjusz: if you make a user name with your full name I can add the write permissions |
| 20:05:05 | Llorean | klapaucjusz: If you'd put in a proper username any one of us would've added it pretty much. |
| 20:05:21 | Unhelpful | it couldn't be a weird flash performance issue, could it? doing a few more make install shouldn't impact read speed of files that aren't touched, i'd think... |
| 20:05:36 | * | JdGordon doesnt know how to fix the splash garbage issue :( |
| 20:05:39 | kkurbjun | JdGordon, yeah, I noticed that spashes are leaivng artifacts now too |
| 20:05:43 | klapaucjusz | linuxstb: how many contributors did you loose because of that? |
| 20:06:08 | linuxstb | klapaucjusz: Some people want to be anonymous, so we lose those. I don't believe anyone has objected for other reasons, until you ;) |
| 20:06:11 | klapaucjusz | I've recently had to spend a good while on IRC convincing a serious contributor to register with the bug tracker of a project I work on. |
| 20:06:23 | Llorean | klapaucjusz: There's no way to quantify that. But it is possible to quantify the work that's had to be done to clean up the wiki in the past causing some of these rules to go into place. |
| 20:06:49 | klapaucjusz | Many people dislike registering, and most of them will give up after they see the amount of pointless activities you need to go through. |
| 20:07:01 | Llorean | klapaucjusz: You judge them pointless. |
| 20:07:09 | klapaucjusz | As I've mentioned, I'm giving up on write access to the wiki, let's please go back to discussing my patches. |
| 20:07:13 | Llorean | A valid email and verification that a human being is behind them serves a point from other perspectives. |
| 20:07:36 | klapaucjusz | Folks, sorry for starting this flamewar. |
| 20:07:42 | klapaucjusz | Let's close it, and go back to discussing code. |
| 20:07:50 | Unhelpful | linuxstb: actually one griped about it a day or so ago. but it doesn't come up very often, i think. |
| 20:08:25 | kkurbjun | klapaucjusz: it's not a flame war, please don't take it personally |
| 20:08:40 | kkurbjun | JdGordon, also, I am not sure about enabling the statusbar when going into plugins, I am getting weird artifacts on the plasma demo on the MR500 target |
| 20:09:02 | kkurbjun | it looks like it is still updating the statusbar in the background |
| 20:09:02 | klapaucjusz | Going back to the code, linuxstb, I see a very unpleasant trade-off. |
| 20:09:17 | JdGordon | i'll check |
| 20:09:45 | klapaucjusz | Given an unstreamable mp4, we either do the seek, or we use up memory in order to keep the metadata around. |
| 20:09:46 | | Part portwolf |
| 20:10:02 | Unhelpful | klapaucjusz: i think we have some precedent for plugins or user tools to "fix" files that can't play correctly... |
| 20:10:08 | Llorean | Are there unstreamable MP4s that can't be made streamable? |
| 20:10:12 | kkurbjun | it doesn't show on the sim, but I think that is because of the hardware 256 color palette blitting |
| 20:10:45 | * | Llorean thinks the best tradeoff is "ignore it gracefully, allow the user to fix it once, and play it efficiently going forward" |
| 20:10:58 | * | klapaucjusz disagrees. |
| 20:11:30 | klapaucjusz | I don't know if my usage of RB is typical, but the main reason for preferring RB to the OF is that it groks any file I wish to throw at it. |
| 20:11:45 | klapaucjusz | If I were willing to go through a conversion process, I'd be using the OF. |
| 20:11:51 | Llorean | klapaucjusz: It's not a conversion process |
| 20:12:04 | Llorean | You shouldn't lose any audio quality, you're just re-positioning parts of the container right? |
| 20:12:15 | JdGordon | I cant see anything in the plugin loader or plasma code which would make me think its updating in the background... |
| 20:12:20 | Unhelpful | Llorean: i think i might see a feasible solution... what if the metadata reader could set a flag to put the last N bytes at the start of the buffer? then the codec can read the data it needs first... |
| 20:12:40 | kkurbjun | JdGordon, you still have the MR500 around right? |
| 20:12:52 | Llorean | Unhelpful: So it loads the file, moving parts of it to the start as it comes across metadata? |
| 20:12:54 | klapaucjusz | It's a conversion process of the container, not of the samples. |
| 20:12:56 | klapaucjusz | Granted. |
| 20:13:06 | Llorean | klapaucjusz: Which means there's no reason not to want to do it other than "I can't be bothered" |
| 20:13:12 | Llorean | There's valid reasons not to transcode files, and many of them. |
| 20:13:21 | kkurbjun | if you start playing a song on it with the cleangreen theme and go into the plasma demo you will see the song title periodically scrolling |
| 20:13:31 | klapaucjusz | Llorean: very well put. |
| 20:13:35 | Unhelpful | Llorean: the metada reader would set a field with the number of end bytes to buffer. on load the buffering thread would seek and read those bytes, then resume buffering from start-of-file. |
| 20:13:45 | klapaucjusz | The reason I use RB is that I can't be bothered with the silly requirements of the OF. |
| 20:14:11 | kkurbjun | I think it may be related to plugins without menu's but I can't say for sure |
| 20:14:53 | Llorean | Unhelpful: Since I don't understand the exact problem, I don't understand what you're referring to there. |
| 20:15:22 | Llorean | Unhelpful: My objection is more on the general principal of "if a file isn't suitable to be played, it probably makes more sense to make the user aware and let them fix it, than harm their battery life silently" |
| 20:15:33 | kkurbjun | I think the reason it is showing in the mr500 is because there are two different lcd update functions that are implemented, one for the 256 color blitting, and another one that uses DMA, it looks like lcd_update is being called outside of the plugin |
| 20:15:41 | Llorean | Since we have no way of knowing if it's a file they'll listen to often (or if it's true of their whole collection) |
| 20:15:46 | Unhelpful | Llorean: the issue as i understand it is that the codec needs some bytes from the end of *some* filesbefore it can start decoding |
| 20:15:48 | JdGordon | kkurbjun: I'll get it charging.. its been siting on the bench for about 3 months without being touched :p |
| 20:16:08 | Llorean | Unhelpful: I wasn't aware it was specifically the end. Somehow I got the impression it could be anywhere in the file with MP4 metadata. |
| 20:16:15 | * | Llorean is ill informed almost certainly |
| 20:16:40 | linuxstb | klapaucjusz: Looking at FS #10833 (and the implementation of NeAACDecDecode in libfaad) - the check for NULL returned by NeAACDecDecode seems required, but should you still call NeAACDecGetErrorMessage in that case? |
| 20:16:40 | Unhelpful | Llorean: that case could still be handled with a similar mechanism if the data in question is contiguous |
| 20:17:04 | Llorean | Unhelpful: True. |
| 20:17:33 | Unhelpful | one extra seek when already spun up shouldn't do much harm, i'd think |
| 20:18:05 | Llorean | Isn't that more or less what we do for ID3v2 anyway? (or was it v1)? |
| 20:18:27 | klapaucjusz | linuxstb: no, I shouldn't. |
| 20:18:40 | Unhelpful | though i'm not sure why this data can't be stashed by the metadata reader, perhaps after reducing it to only the relevant bits? don't we have codecs that do similar things already, and some space in the metadata structure for codec-private data? |
| 20:19:41 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 20:20:11 | klapaucjusz | Unhelpful: yep, that's a solution. |
| 20:20:49 | klapaucjusz | But even if you reduce it to just the needed bits, it's still potentially quite a lot of data (the frame position info). |
| 20:20:56 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 20:21:00 | klapaucjusz | Not reasonable to put it statically −− need to malloc and stuff. |
| 20:21:18 | | Join Xerion_ [0] (i=xerion@82-170-197-160.ip.telfort.nl) |
| 20:21:39 | alex` | There is no malloc in rockbox, this was the problem I came across when I started looking into carrying the data into the codec |
| 20:21:56 | alex` | There was also talk of why Rockbox has 2 different tag readers |
| 20:22:28 | kugel | JdGordon1: how did you fix the flicker? |
| 20:22:33 | klapaucjusz | So what I'm saying is −− in that particular case (unstreamable mp4), let's just take the efficiency hit. |
| 20:23:14 | linuxstb | alex`: The metadata parser should parse the file and extract the metadata. The codec parser should parse the file and extract the audio data to decode. They use different APIs, and do different things. |
| 20:23:27 | JdGordon | kugel: it inly clears if it has to |
| 20:23:32 | JdGordon | i.e it went from off to on |
| 20:23:37 | JdGordon | um.. on to off |
| 20:23:43 | JdGordon | one of them :p |
| 20:24:15 | kugel | I thought we agreed that the refresh event stays because that also removes dead parts from splashes for example? |
| 20:24:27 | alex` | linuxstb: But so much of the code is duplaicated, why isn't there one parser which can either extract the metadata or the audio data on demand? |
| 20:24:44 | alex` | Anyway I feel I may be de-realing the conversation somewhat |
| 20:25:10 | JdGordon | kugel: I'd *really* rather not have that event... but yeah splashes are buggered atm |
| 20:25:22 | JdGordon | but thats not enough reason to put it back in |
| 20:25:26 | kugel | you said it's ok as function call? |
| 20:25:37 | kugel | what's bad about it? |
| 20:25:42 | Llorean | klapaucjusz: Why take the efficiency hit? |
| 20:26:04 | JdGordon | as a function its ok |
| 20:26:14 | kugel | so it fixes bugs but also introduces some... |
| 20:26:27 | kugel | feel free to make it a function call, it's fine |
| 20:26:35 | | Join Tomis2 [0] (n=Tomis@70.134.100.133) |
| 20:28:00 | klapaucjusz | Llorean: what other solution do we have? |
| 20:28:18 | klapaucjusz | Recall that unstreamable mp4s are fairly rare, so we don't want to complicate the code a lot just for that case. |
| 20:28:21 | Llorean | Not support unstreamable files. |
| 20:28:22 | linuxstb | alex`: Because they're using two different APIs (disk I/O and the buffering API). But if you could merge the code, please do! |
| 20:28:31 | Llorean | klapaucjusz: If they're rare, people shouldn't have many that need fixing. |
| 20:28:40 | alex` | Just to point out when we are calling these unstreamable files they are not, they are valid m4a's which Rockbox won't play. |
| 20:28:47 | | Quit parafin ("new kernel") |
| 20:28:57 | klapaucjusz | alex`: exactly. |
| 20:29:14 | klapaucjusz | RB claims to support AAC-LC mp4s. |
| 20:29:15 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 20:29:17 | klapaucjusz | This is a lie. |
| 20:29:26 | klapaucjusz | It only supports a subset of AAC-LC mp4s. |
| 20:29:46 | linuxstb | Llorean: I think I would agree with klapaucjusz - it's better to support inefficiently designed files inefficiently than not to support them at all. But I do think we should try and explore better ways to deal with them. |
| 20:29:51 | alex` | Llorean: They are not that rare, believe me. And besides I think my other halfs iTunes would complain if I start duplicating her m4a's with ones especially for RB |
| 20:30:10 | | Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) |
| 20:30:25 | Llorean | alex`: Why would you duplicate them? fix them once and be done with it, right? |
| 20:30:32 | klapaucjusz | linuxstb: how much data is buffered typically? |
| 20:30:36 | Llorean | is there some reason where unstreamable metadata is required? |
| 20:31:06 | Llorean | klapaucjusz: There is no typically. It depends on the player, how much RAM is used for other features, and in the context of a single file, where that single file lands in the playlist. |
| 20:32:02 | alex` | Llorean: because I have no idea how iTunes would react if the checksums of it's files changed under its feet and I'd rather not get the grief if my other half suddenly can't play her music. |
| 20:32:21 | Llorean | alex`: Checksums? |
| 20:32:47 | | Join MethoS- [0] (n=clemens@134.102.106.250) |
| 20:32:47 | Llorean | alex`: iTunes will play any non-DRM m4a just fine. Any DRM one won't play in Rockbox anyway. |
| 20:32:47 | Unhelpful | does AAC use COP? if not i think using it could get us to realtime for AAC-HE on PP... we're already ~66% |
| 20:33:05 | kkurbjun | klapaucjusz: the total audio buffer is probably about the size of memory the player has minus a couple of megs usually, not sure how metadata fits in there |
| 20:33:07 | | Join Dhraakellian [0] (n=ntryon@cpe-67-253-173-122.rochester.res.rr.com) |
| 20:33:19 | Unhelpful | ahah! i have backlight on while plugged. the fast test was made while unplugged. |
| 20:33:28 | linuxstb | Unhelpful: No, it doesn't. |
| 20:34:00 | Dhraakellian | is it possible to disable the reboot into OF when USB power is connected on the Fuze? |
| 20:34:27 | kkurbjun | on players with larger screens the audio buffer is smaller, on the m:robe 500 I think there is about 4 megs less than the total ram (60 megs out of 64) |
| 20:34:41 | Dhraakellian | holding Select is rather inconvenient when one is turning the ignition while wearing gloves |
| 20:34:42 | alex` | I don't care what iTunes does or doesn't do. However it seems silly to force users to "fix" their m4a's with some unspecified magic which they may not understand if they are not metadata gurus. |
| 20:35:17 | alex` | Should we just submit a Documentation patch saying Rockbox can't play some m4a's and what the fix for them is? |
| 20:35:58 | alex` | What is the magic fix BTW? |
| 20:36:00 | klapaucjusz | kkurbjun: so the buffer is a couple dozen megs, typically? |
| 20:36:18 | klapaucjusz | In that case, for a typical m4a track, the skip will not cause a rebuffer, right? |
| 20:36:33 | stripwax | these are files that don't conform to the spec? |
| 20:36:42 | alex` | One case of m4a's that needs testing is audiobooks BTW |
| 20:36:44 | Llorean | alex`: Depends. Programs have "optimize MP4 layout" or similar options which make the files streamable (which they aren't - note that streamable is not the same as playable) |
| 20:36:46 | | Quit Tomis (Read error: 110 (Connection timed out)) |
| 20:36:58 | | Nick Tomis2 is now known as Tomis (n=Tomis@70.134.100.133) |
| 20:37:12 | alex` | stripwax: which spec? I think they conform to the spec I read. |
| 20:37:13 | klapaucjusz | stripwax: no, they conform perfectly to the spec. The spec allows one-pass reading of files (normal mp4s), and one-pass writing of files (unstreamable mp4s). |
| 20:37:35 | klapaucjusz | I.e. metadata at the beginning (one-pass reading) or metadata at the end (one-pass writing). |
| 20:37:40 | | Quit Xerion (Connection timed out) |
| 20:37:40 | | Nick Xerion_ is now known as Xerion (i=xerion@82-170-197-160.ip.telfort.nl) |
| 20:37:52 | linuxstb | klapaucjusz: I'm not sure about that - you're calling "advance_buffer", which is telling the codec API that the codec is finished using all data up to that point. I don't know if the buffering code will reuse it - it would be within its rights to just start reading more data over the top of it... |
| 20:37:55 | Llorean | alex`: Large audio books suffer their own problems simply due to the size of the file. |
| 20:38:08 | | Quit dfkt_ (Read error: 110 (Connection timed out)) |
| 20:38:21 | klapaucjusz | linuxstb: hold on, I'll try to grok the buffering code. |
| 20:39:04 | | Join parafin [0] (i=parafin@paraf.in) |
| 20:40:29 | klapaucjusz | Ok. bufadvance is just an alias for bufseek. |
| 20:40:42 | alex` | New FS #10834 : Fix off-by-one in playlist.c found by valgrind. |
| 20:40:57 | klapaucjusz | And bufseek does the reasonable thing (it just changes the current position pointer if possible). |
| 20:42:00 | klapaucjusz | And since we're not yielding between the two seeks, the buffering thread doesn't have a chance to discard the data before the current pointer, right? (I'm a little shaky on that.) |
| 20:42:27 | klapaucjusz | So unless I'm missing something, no rebuffering in the typical case. |
| 20:44:46 | | Join domonoky1 [0] (n=Domonoky@g229127107.adsl.alicedsl.de) |
| 20:45:00 | | Join phanboy4 [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net) |
| 20:46:40 | klapaucjusz | Unhelpful: no, not to my knowledge (COP in AAC). But I'm a little surprised by your 60% figure, AAC-HA doesn't play realtime on nano2g, which has a 200MHz chip. |
| 20:47:13 | | Join solexx_ [0] (n=jrschulz@e176103158.adsl.alicedsl.de) |
| 20:47:16 | | Join Tomis2 [0] (n=Tomis@70.134.103.64) |
| 20:47:25 | Llorean | klapaucjusz: How does it perform with test codec? |
| 20:47:26 | * | alex` wonders if snrncpy got deprecated since he last re-based his patch |
| 20:47:34 | klapaucjusz | test codec? |
| 20:47:57 | Llorean | The plugin we use to see what percentage of realtime a codec performs. |
| 20:48:06 | linuxstb | klapaucjusz: The Nano2G seems to have its own speed issues - it's performing much slower than the CPU clock would suggest. |
| 20:48:07 | * | klapaucjusz is all ears. |
| 20:48:08 | | Quit domonoky (Read error: 60 (Operation timed out)) |
| 20:48:17 | klapaucjusz | How do I bench it? |
| 20:48:45 | linuxstb | Add test_codec.c to apps/plugins/SOURCES, rebuild rockbox, then you can open audio files with test_codec (it's a viewer plugin) |
| 20:48:58 | | Quit stripwax ("http://miranda-im.org") |
| 20:49:15 | klapaucjusz | I just add test_codec.c to sources, anywhere in the file, right? |
| 20:49:30 | klapaucjusz | Do I need to make clean? |
| 20:49:44 | linuxstb | Shouldn't need to, no. |
| 20:50:43 | | Quit Tomis (Read error: 60 (Operation timed out)) |
| 20:50:43 | | Nick Tomis2 is now known as Tomis (n=Tomis@70.134.103.64) |
| 20:51:13 | Llorean | linuxstb: Don't you need to reconfigure though if you change sources? |
| 20:52:22 | klapaucjusz | Llorean: it appears to work fine with just a make |
| 20:52:26 | linuxstb | Llorean: No, configure is independent of that. |
| 20:52:38 | Llorean | I thought something was necessary if you changed it. Ah well. |
| 20:52:43 | klapaucjusz | Okay, nano2g, 192kbit Ogg, 356.54%. |
| 20:53:54 | klapaucjusz | After which my nano crashed. |
| 20:54:00 | * | alex` boggles |
| 20:54:04 | klapaucjusz | The flash is gone. |
| 20:54:24 | * | klapaucjusz needs to reinstall the OF. |
| 20:54:59 | klapaucjusz | Is that behaviour typical of iPods? A crash causes the flash to disappear more often than not? |
| 20:55:13 | klapaucjusz | Something as simple as a division by zero forces a reinstall. |
| 20:55:27 | klapaucjusz | Or is there something fishy with the nano2g's exception handler? |
| 20:57:50 | klapaucjusz | dd if=Firmware-19.8.1.3 of=/dev/sda1 |
| 20:58:28 | klapaucjusz | Folks, any other nice development tricks? (Like the test_codec?) |
| 20:59:03 | alex` | klapaucjusz: There is stuff documented on wiki although I do find it a bit hard to search for some reason. |
| 20:59:39 | | Quit solexx (Read error: 110 (Connection timed out)) |
| 20:59:48 | * | alex` wonders if there is a way to test if the current playlist has never been saved but is resuming from svaed state on a reboot? |
| 21:00 |
| 21:00:22 | * | klapaucjusz has just made a mistake while reinstalling his iPod, it now speaks Chech. |
| 21:00:57 | * | klapaucjusz now knows that "Language" in Czech is "Jazyk". |
| 21:01:00 | CIA-6 | New commit by Domonoky (r23877): fix email link in admin view. |
| 21:01:35 | Llorean | alex`: You mean checking if it's a dynamic playlist, and if it's a bootup-resume rather than a standard resume? |
| 21:01:55 | alex` | Llorean: exactly |
| 21:02:02 | Llorean | Why on bootup but not on normal resumes? |
| 21:02:32 | alex` | I thought I'd have one more go at sumbitting FS #9677 but currently it doesn't kick in if the system has been rebooted |
| 21:03:16 | alex` | global_settings.party_mode is false, as is playlist_modified(NULL) |
| 21:03:16 | Llorean | Does that mean it currently fails to give the normal warning if the system has been rebooted? |
| 21:03:32 | Llorean | Is there a bug for that? |
| 21:03:49 | CIA-6 | New commit by Domonoky (r23878): show submitted timestamp in themeslist. |
| 21:03:54 | alex` | Llorean: with FS #9677 (which is an enhanced warning for erasing the playlist) |
| 21:04:10 | Llorean | That's not a bug. |
| 21:04:39 | Llorean | If there's an issue that occurs without that patch, it should be in a bug task so that people not interested in potential features can still spot it easily. |
| 21:05:15 | alex` | It's a bug in my patch, I'm just trying to detect the case so I can offer the warning |
| 21:05:41 | Llorean | alex`: I asked if the *normal* warning doesn't happen, and if there's a bug for it. |
| 21:05:49 | alex` | A playlist shouldn't get wipped if the player has powered down inbetween and someone fat fingers a new playlist |
| 21:05:50 | Llorean | Not the one from your patch. |
| 21:06:12 | Llorean | Does the current in-rockbox dynamic playlist erase warning fail to show up if it's been rebooted? |
| 21:06:37 | alex` | Llorean: I have no idea, I was testing something else. I can check it now if you want. |
| 21:07:11 | | Quit gevaerts (Nick collision from services.) |
| 21:07:19 | Llorean | Well, that's what I meant. If it works in-Rockbox as it stands, then it should give you a path for investigating your issue. If not, it should be bugged and shouldn't affect whether or not your patch is accepted, I would think. |
| 21:07:23 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
| 21:07:50 | alex` | Llorean: True... I shall check |
| 21:09:39 | | Quit shai ("Leaving") |
| 21:17:43 | alex` | curious, the logic is the same, the behaviour different |
| 21:20:05 | | Quit Tomis (Read error: 60 (Operation timed out)) |
| 21:21:08 | | Join Tomis [0] (n=Tomis@70.134.88.217) |
| 21:22:12 | klapaucjusz | Nano2g benchmarks: http://rockbox.pastebin.com/m4b107eea |
| 21:22:42 | | Quit liar (Read error: 113 (No route to host)) |
| 21:23:06 | klapaucjusz | Interestingly, we're really close to having AAC-HE usable. |
| 21:25:54 | alex` | Llorean: Ahh, no the behaviour is the same with and without the patch, as in if you haven't hit "Resume" after a bootup and select a new playlist creating action it will go straight ahead without a prompt |
| 21:26:09 | alex` | I'm not sure if that is undesirable or not |
| 21:26:28 | Llorean | If you're stopped I wouldn't expect it to prevent you. |
| 21:26:40 | Llorean | But that's me. |
| 21:26:52 | Llorean | Does it prevent you if you actually stop playback without rebooting? (not just pausing) |
| 21:27:49 | alex` | What's a stop, long hold on pause on iPod? |
| 21:28:48 | | Join xordos [0] (n=xordos@adsl-99-29-119-167.dsl.hstntx.sbcglobal.net) |
| 21:28:52 | Unhelpful | klapaucjusz: how close? i've a few *small* aac-he-specific tweaks... |
| 21:29:22 | alex` | Llorean: If you stop and start a new playlist it still prompts if you want to erase the current playlist |
| 21:30:01 | alex` | By that behaviour should it do the same on a reboot? |
| 21:30:04 | klapaucjusz | Unhelpful: 102%. |
| 21:30:38 | klapaucjusz | Depending on the bitrate, somewhat less. It stutters on some files, but some play fine. The UI is completely unresponsive, of course. |
| 21:32:06 | Llorean | alex`: Are you actually stopping? |
| 21:32:24 | Llorean | Sorry to ask what seems like an obvious question, but it can be hard to tell if it's stopped or simply paused sometimes |
| 21:33:07 | Unhelpful | odd, test_codec on e200 shows it needing ~133MHz. with 200 you should be fine, but not all arm cores are equal. ;) |
| 21:33:34 | Llorean | Unhelpful: linuxstb said the Nano 2G is underperforming for some reason. |
| 21:33:53 | | Quit GeekShado_ (Read error: 104 (Connection reset by peer)) |
| 21:34:27 | alex` | Llorean: Think so, I get a solid square instead of || in the top left corner of the menu display |
| 21:35:11 | Llorean | alex`: I wonder if it's different intentionally because if someone hasn't set "resume on startup" it's unlikely for them to think "I have a playlist" immediately on boot, and might cause more confusion if it did warn them. |
| 21:35:12 | Llorean | I don't know |
| 21:36:16 | klapaucjusz | I've put a bunch of clarifications in FS #10832. |
| 21:37:16 | klapaucjusz | Unhelpful: it's ARMv4T, in case it matters. |
| 21:37:51 | alex` | Llorean: Doesn't sound like I should raise a bug, and helpfully this doesn't regress FS #9677 |
| 21:38:42 | Llorean | It might be worth raising a bug to find out if this is "as intended" or if it's a bug (after which it might make sense to document it in the 'Warn on erase' entry in the manual) |
| 21:40:40 | Unhelpful | klapaucjusz: e200 is ARMv4 as well. maybe there's a memory issue of some sort? |
| 21:41:43 | klapaucjusz | If you have any ideas, I'll be glad to try out your tweaks. |
| 21:42:31 | | Join burden555 [0] (n=burden55@76.246.196.177) |
| 21:43:10 | burden555 | hello, I want to reformat my Video iPod (30gb) to NTFS file system so I can put larger than 4gb files on it. Will rockbox support it still? |
| 21:43:49 | alex` | Llorean: FS #10835 |
| 21:44:10 | klapaucjusz | burden555: no. |
| 21:44:37 | | Quit phanboy4 (Read error: 54 (Connection reset by peer)) |
| 21:45:19 | alex` | Llorean: Ahh, there may be an answer in FS #9660 |
| 21:45:24 | burden555 | what else can I do so I can put a 14gb file on it? |
| 21:45:39 | | Part smogzer ("http://quassel-irc.org - Chat comfortably. Anywhere.") |
| 21:46:05 | Unhelpful | klapaucjusz: i'd expect what works best on e200 to work best on nano2g if they're both armv4... but there *is* an LUT involved, so if memory access is much slower an LUT-less algorithm might be called for |
| 21:46:24 | Llorean | burden555: Create a second partition not to be used by Rockbox, or split the file with an archiving tool and re-combine it to the system if you need to access it. |
| 21:48:01 | klapaucjusz | Llorean: how do you profile? |
| 21:48:26 | klapaucjusz | The simulator spends most of its time in ps_decorrelate and fft_dif, and a little in sbr_qmf_syntesis_64. |
| 21:48:59 | klapaucjusz | Oh, and just a wee bit in dct4_kernel. |
| 21:49:10 | klapaucjusz | Since all of these are in libfaad, I think it might make sense to first try to upgrade to the latest version. Filing a feature request. |
| 21:49:15 | * | alex` updates #FS9677 with the (hopefully) final update |
| 21:49:25 | Llorean | klapaucjusz: There's no feature requests in the tracker. |
| 21:50:01 | alex` | I would appreciate any comments or review items on #FS9677, even if it's just a "never going to happen" comment. The patch is almost a year old now |
| 21:50:38 | Llorean | alex`: might want to take it to the -dev list. |
| 21:51:12 | Llorean | The problem with IRC is that you have to say it at just the right time for it to end up in front of the right eyes at a time where they feel like thinking about it. On-list it sits in the inbox until they can get back to it. Not guaranteed, but at least it helps odds somewhat |
| 21:52:02 | alex` | Llorean: I have mentioned it on the dev list before, however I shall send one more |
| 21:52:26 | alex` | Llorean: I agree IRC is a bit hit and miss, but it seems to be where most of the action is |
| 21:53:21 | Llorean | alex`: Getting a feature change in as a non-committer can be difficult. You basically need to have it in a state where you can confidently say "I think it's ready" and then manage to catch somebody's attention with it who's willing to take responsibility for it just in case you aren't around after they commit it if something goes wrong. |
| 21:54:00 | burden555 | how can I partition my iPod? |
| 21:57:33 | klapaucjusz | burden555: don't bother. |
| 21:57:35 | klapaucjusz | Just split the file. |
| 21:57:47 | klapaucjusz | (Into 14 chunks of 1GB each.) |
| 21:57:59 | klapaucjusz | Zip, rar, dd, whatever. |
| 21:59:37 | burden555 | Its a concert I recorded and I want to play it on my LED TV which has a USB port so it must stay in the original video format. |
| 21:59:39 | saratoga | klapaucjusz: i've looked at lot speeding up libfaad |
| 21:59:46 | alex` | Llorean: I am aware of this :-) However I think it was ready about 11 months ago. No one reviewed it after I addressed the first review comments. |
| 21:59:50 | saratoga | your best bet is to improve the QMF filterbanks |
| 22:00 |
| 22:00:13 | saratoga | there are already faster versions in rockbox for other codecs (atrac, mp3 and mpc use them as well) |
| 22:00:43 | klapaucjusz | FS #10836 |
| 22:00:54 | saratoga | i've also been bugging stripwax to profile aac-he but i don't think he has had time just yet |
| 22:00:59 | alex` | Llorean: It's certainly an area of soliting casual submissions to Rockbox that could be improved on, however it's up to the core devs if they think it's a problem. |
| 22:01:03 | *** | Saving seen data "./dancer.seen" |
| 22:01:17 | Llorean | alex`: It's not really something that can be readily improved. |
| 22:01:23 | Unhelpful | saratoga: is profiling on target all that difficult really? |
| 22:01:27 | Llorean | There's nowhere to pull "more time for reviewing other peoples' code" from. |
| 22:01:35 | saratoga | please don't file bug reports for things that aren't bugs |
| 22:01:39 | saratoga | its annoying to have to close them |
| 22:02:01 | saratoga | if you want to resync faad, submit a patch, but IIRC last time we looked at it the changes didn't seem all that impressive |
| 22:02:06 | klapaucjusz | saratoga: so what's the proper policy? |
| 22:02:08 | Llorean | klapaucjusz: I thought I told you not to put feature requests in the tracker just a few minutes ago. |
| 22:02:12 | saratoga | libfaad current svn is still slow as heck |
| 22:02:42 | klapaucjusz | So where do I put wishlist-type bugs? |
| 22:02:46 | saratoga | we don't have one |
| 22:02:55 | klapaucjusz | Great. |
| 22:03:00 | Unhelpful | saratoga: i believe somebody mentioned decode errors (ringing) for low-bitrate files w/ the old version, earlier... then again low-bitrate files ring like hell anyway. ;) |
| 22:03:10 | saratoga | yeah but i htink that was my fault |
| 22:03:15 | n1s | klapaucjusz: he had hundreds of FQ's noone ever looked at, not great either |
| 22:03:26 | saratoga | i fixed a bug related to bad optimizations on my part recently in libfaad |
| 22:03:44 | saratoga | that causes ringing due to the wrong window being used sometimes when inverse transforming |
| 22:04:00 | Llorean | klapaucjusz: if there's an actual *bug* that the new faad would fix for us, document the actual bug, give steps for reproducing, and mention the relevant code in newer versions of faad (perhaps the revision that fixed it) |
| 22:04:02 | Llorean | That would be ideal |
| 22:04:05 | Unhelpful | klapaucjusz: all the work is done by volunteers... feature requests aren't really compatible with that. asking volunteers to fix actual bugs is one thing, telling them you want this or that is another. |
| 22:04:21 | saratoga | basically libfaad sucks and I don't see much sense in trying to keep up to date with all the ways its not very good |
| 22:04:31 | klapaucjusz | Unhelpful: I realise it's 100% volunteer work. |
| 22:04:45 | klapaucjusz | I do myself participate in a number of projects that are based on volunteer work. |
| 22:04:55 | * | domonoky1 completed the first step to a userarea on the themepage: FS #10837 :-) |
| 22:04:58 | merbanan | saratoga: how about using opencore for aac ? |
| 22:05:02 | klapaucjusz | It's not completely impossible that you downloaded the files that you're listening to using my software. |
| 22:05:20 | | Quit Res1 (Read error: 60 (Operation timed out)) |
| 22:05:24 | klapaucjusz | Being based on volunteer work does not mean that you have to ignore your users and friendly contributors. |
| 22:05:48 | klapaucjusz | It means that you don't commit to deadlines, and that your feature request tracker has a position that says "reasonable suggestion, nobody can be bothered." |
| 22:06:02 | klapaucjusz | So please, please stop giving me the "if you want it, submit a patch" line. |
| 22:06:19 | Llorean | klapaucjusz: The old feature request tracker wasted a *ton* of time keeping it clean and organized. |
| 22:06:24 | klapaucjusz | If I want it, I submit a feature request, which the developers are welcome to ignore. |
| 22:06:30 | alex` | Llorean: I appreciate the issue with review time, and perhaps Rockbox is more special given the embedded nature of the code. However in my experience Rockbox is one of the hardest projects to make contributions to and it's an open question if that is good or bad for Rockbox. |
| 22:06:34 | rasher | klapaucjusz: We had feature requests. They weren't useful in any way, so we ditched it |
| 22:06:56 | | Join hebz0rl [0] (n=hebz0rl@dslb-088-065-060-031.pools.arcor-ip.net) |
| 22:07:07 | Llorean | klapaucjusz: This is the second time you've assumed that we should work a certain way without taking into consideration that we might have experiences you haven't that have caused us not to. |
| 22:07:30 | klapaucjusz | Yes? |
| 22:07:59 | Unhelpful | alex`: really? i didn't find it difficult, i fixed up a patch on FS to reduce memory footprint and when it looked nice enough somebody said "hey when are you committing that?" :P |
| 22:08:08 | Unhelpful | which was amusing as i did not have commit access |
| 22:08:10 | Llorean | klapaucjusz: So stop telling us we should do things a way that doesn't actually work effectively here. |
| 22:08:59 | gevaerts | Unhelpful: see? It was hard! |
| 22:09:04 | Llorean | klapaucjusz: And more specifically, stop ignoring things just because you don't agree with them if you want to become involved with the project. |
| 22:09:07 | domonoky1 | alex`: to get patches commited, you have to nag us here often :-) if we get annoyed and your patches are good, you get commit access :-) |
| 22:09:40 | alex` | Unhelpful: I'm not saying it's impossible, indeed I have several patches committed myself but I'm just comparing with my experience across other projects. |
| 22:10:23 | alex` | domonoky1: There is a fine line between nagging and winding people up. I've been on the recieving end of flame material on the RB mailing list before. |
| 22:11:05 | alex` | domonoky1: Anyway, go review FS #9677 then ;-) |
| 22:11:24 | * | domonoky1 goes looking.. :-) |
| 22:11:40 | Unhelpful | or if you pick an FS task that will make users nag for a commit any time it has any activity ;) |
| 22:11:53 | CIA-6 | New commit by nls (r23879): FS #10834 by Alex Bennee, fixing off-by-one bug in code calling format_track_path |
| 22:13:06 | Llorean | alex`: The only thing close to flaming of you I see immediately is when I asked you not to post questions like "I listen to a lot of podcasts, why do my database updates take so long?" to the -dev list. |
| 22:15:38 | n1s | the two big problems we have with good patches is that 1) devs have little spare time 2) people who know part x of the code might no longer be around so noone really knows it well enough to do a good review without investing lot's of time |
| 22:16:17 | Llorean | n1s: 3) If it changes how things work rather than simply fixing things, people are often shy about accepting that some people won't like it. |
| 22:16:35 | * | domonoky1 decides that he doesnt know the code this patch touches, and calls others to review this :-) |
| 22:16:42 | n1s | Llorean: yeah |
| 22:17:01 | gevaerts | domonoky1: is that n1s's 1), 2) or 3)? ;) |
| 22:17:22 | domonoky1 | gevaerts: 1) and 2) |
| 22:17:26 | domonoky1 | :-) |
| 22:18:52 | alex` | Llorean: it seemed like a fair question to ask on -dev, seeing as I was seeking ilumination as to the reasons why. However I was jumped on because it's not a place to contact developers. So these days I mainly don't bother unless I've got time to sit in front of IRC asking questions |
| 22:19:18 | alex` | Llorean: It certainly would be the sort of question I'd be happy asking on any other -dev list |
| 22:19:39 | Llorean | alex`: You were talking about emotional responses to it. That you were frustrated. You didn't mention any interest in attempting to fix it. |
| 22:19:56 | Llorean | I'm sure you can see how the phrasing of the question, as well as the question itself, looked like a simple support request. |
| 22:20:02 | Llorean | "This is bad, why is it happening to me?" |
| 22:20:53 | domonoky1 | alex`: does your patch still allow to abort the playlist erasing action ? |
| 22:21:27 | alex` | Llorean: Sure, and I'll be more careful in future. Anyway the point was not to go over any particular incidents just to make the general observation w.r.t to other projects |
| 22:21:53 | alex` | domonoky1: Yes, if you press the back arrow to exit the menu the action aborts |
| 22:22:58 | Llorean | alex`: I'm not sure what "being asked to keep support separate from development" does to make getting something committed harder. |
| 22:23:23 | Llorean | A "cancel" action in the menu might make sense for people who don't assume left will cancel. |
| 22:23:35 | * | domonoky1 thinks the functionname playlist_maybe_save_current() sounds strange.. :-) |
| 22:24:52 | | Quit pamaury ("exit(*(int *)0 / 0);") |
| 22:25:23 | | Join saratoga_lab [0] (i=9803c264@gateway/web/freenode/x-mjgiucziekfprhhy) |
| 22:25:53 | | Quit merbanan (Read error: 110 (Connection timed out)) |
| 22:26:32 | saratoga_lab | merbanan: i didn't even know there was an open core aac decoder |
| 22:26:35 | saratoga_lab | do you have a link? |
| 22:26:45 | saratoga_lab | bah too slow |
| 22:27:43 | domonoky1 | alex`: also you changed a few lang entrys (instead of depriciating and adding new ones), i dont know if that is safe for the translations (and their tools). |
| 22:28:27 | alex` | domonoky1: I'm all ears to alternatives, I kept playlist at the front as it is a playlist_ api function |
| 22:28:52 | alex` | domonoky1: Maybe maybe_save_current_playlist() |
| 22:29:06 | saratoga_lab | is apache licensing GPL compatible? |
| 22:29:20 | domonoky1 | what about playlist_try_save_... but the function name is not really important. |
| 22:29:26 | alex` | domonoky1: Could you add comments to FS #9677 please as I need to go do my chores right now ;-) |
| 22:30:15 | alex` | Sounds like an additional menu item is the important one |
| 22:30:47 | | Quit Tomis (Read error: 60 (Operation timed out)) |
| 22:31:35 | saratoga_lab | Unhelpful: (just now getting caught up on logs) using cop for aac-he is attractive on PP, but the SBR parts take up close to 90-100MHz, so splitting it would be ackward |
| 22:32:25 | saratoga_lab | IMO the best way would be to apply some minor optimizations (either taken from MPC or ATRAC or from one of the other AAC-HE decoders like ffmpeg or apparently google's opencore one) to get sbr performance below 80MHz |
| 22:32:28 | Unhelpful | saratoga: ick... so even splitting SBR vs "the rest" would leave it non-working? |
| 22:32:38 | saratoga_lab | correct |
| 22:33:02 | saratoga_lab | but apparently we're a factor of several slower then good SBR implementations, so it might not be very hard to fix that |
| 22:33:22 | saratoga_lab | for LC I got a large speed up just by deleting the faad mdct and replacing it with an ok one from another codec |
| 22:33:31 | saratoga_lab | i suspect the same will work here for the sbr filterbanks |
| 22:33:57 | saratoga_lab | the nero people implied to me that they are not efficiently implemented |
| 22:34:42 | Unhelpful | saratoga: if the implementation is as bad as some bits i've looked at... |
| 22:34:58 | | Quit rvvs89 (Read error: 110 (Connection timed out)) |
| 22:35:14 | saratoga_lab | i think the best approach would be to look at the analysis or synthesis filterbank, and just throw it out and use a different one |
| 22:35:18 | saratoga_lab | i bet you'd get a large speed up |
| 22:35:36 | saratoga_lab | but filterbanks aren't really my thing |
| 22:35:50 | domonoky1 | alex`: done :-) |
| 22:36:56 | Unhelpful | saratoga: ideally i'd like substitute functions that can be expected to use the same layout for their input and output data... because we're talking about code i don't really understand, here ;) |
| 22:39:49 | saratoga_lab | Unhelpful: well filterbanks should be pretty simple like that |
| 22:39:53 | saratoga_lab | data in, data out sort of thing |
| 22:40:24 | saratoga_lab | its basically just a weird FIR filter IIRC |
| 22:40:47 | linuxstb | saratoga_lab: The Apache license appears to be incompatible with GPLv2 (but not GPLv3) - http://www.gnu.org/licenses/license-list.html#apache2 |
| 22:41:11 | saratoga_lab | hmm annoying |
| 22:41:26 | saratoga_lab | i suppose though this is just like the Helix SBR code, where we can steal their ideas if not their code |
| 22:41:36 | amiconn | saratoga_lab: Are those filters somehow related to what ape does for compression levels > -c1000 ? |
| 22:41:55 | Unhelpful | hrm, so, on arm, debruijn-ish log2 has 10 ops, binsearch+LUT has 9 - both not counting load of the LUT address. gotchas: binsearch has an add dependent on the table load, with one instruction it can slot in between. so 1) what's result latency for ldr from iram? 2) how much do we care about table size (64 vs 256 entries) |
| 22:42:17 | saratoga_lab | amiconn: i really have no idea |
| 22:42:22 | saratoga_lab | (about APE) |
| 22:42:32 | saratoga_lab | but they should be the same as the mpeg and mpc ones IIRC |
| 22:42:57 | | Quit burden555 () |
| 22:43:08 | saratoga_lab | basically just perform a DCT on a vector, then run through multiply-accumulating filter coefficients on each sample out of the dct |
| 22:43:24 | | Part froggyman |
| 22:43:25 | linuxstb | saratoga_lab: opencore also looks like it's C++, although that's probably relatively easy to fix... But it seems a non-starter license wise anyway. |
| 22:43:40 | saratoga_lab | its c++ but the code all looked like c to me |
| 22:44:09 | linuxstb | The first file I looked at wasn't - http://github.com/android/platform_external_opencore/blob/master/codecs_v2/audio/aac/dec/src/decoder_aac.cpp |
| 22:44:19 | linuxstb | (I don't know if that's the right git repo...) |
| 22:44:22 | saratoga_lab | the filterbanks were c at least |
| 22:44:30 | saratoga_lab | the entry points probably aren't |
| 22:44:36 | saratoga_lab | amiconn: check this: http://svn.rockbox.org/viewvc.cgi/trunk/apps/codecs/libatrac/atrac3.c?revision=22341&view=markup |
| 22:44:39 | saratoga_lab | search "static void iqmf" |
| 22:45:10 | saratoga_lab | "loop1" is a 4 point DCT since this is a 4 channel QMF |
| 22:45:21 | | Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) |
| 22:45:30 | saratoga_lab | "loop 2" is a 48 tap filter |
| 22:45:34 | saratoga_lab | and thats the QMF |
| 22:46:32 | saratoga_lab | basically just a really stupid way to implement a time -> frequency conversion, using FIR filters instead of an MDCT |
| 22:48:14 | amiconn | That looks much simpler than the ape filters |
| 22:50:09 | | Quit mt (Read error: 104 (Connection reset by peer)) |
| 22:50:39 | saratoga_lab | google says AAC-HE uses a 64 band QMF instead of a 4 band so that DCT is probably more complicated, but yeah, i think its not too hard |
| 22:50:46 | amiconn | The latter are (iiuc) fir filters as well, but they dynamically adjust their coefficients, and apply mac results conditionally, based on sign and magnitude of the result |
| 22:52:06 | amiconn | The high compression levels also use much longer filters (up to 1280 samples for "insane") and two filter "layers" with different length |
| 22:53:04 | * | amiconn wonders whether someone tried to asm-ize this qmf thing |
| 22:53:47 | saratoga_lab | amiconn: yes we did on ARM |
| 22:54:03 | saratoga_lab | (for ATRAC) |
| 22:54:18 | amiconn | If this function takes a significant part of the total decode time, there should be quite some gain |
| 22:54:20 | saratoga_lab | see: http://svn.rockbox.org/viewvc.cgi/trunk/apps/codecs/libatrac/atrac3_arm.S?revision=22548&view=markup |
| 22:54:39 | saratoga_lab | also for MP3 the filterbank there was rewritten to use EMAC for everything on coldfire |
| 22:54:40 | amiconn | Especially on coldfire, as our current gcc doesn't know anything about coldfire emac |
| 22:55:19 | saratoga_lab | but yeah atrac could use it, i think its not even real time right now since the fitlber bank needs about 200Mhz or something ridiculous |
| 22:55:55 | saratoga_lab | could probably just replace that 48 tap loop with a couple lines of asm and get real time |
| 22:57:02 | | Quit saratoga_lab ("Page closed") |
| 22:58:24 | amiconn | The arm loops aren't optimal for the newer generations (arm9 and up) regarding interlocks |
| 22:59:17 | * | amiconn would probably unroll the whole loop if performance is that critical there |
| 22:59:32 | amiconn | The whole inner loop of course |
| 23:00 |
| 23:00:20 | amiconn | hmhm |
| 23:02:14 | | Quit Omlet ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") |
| 23:02:24 | | Join Omlet [0] (i=omlet05@40.10-65-87.adsl-dyn.isp.belgacom.be) |
| 23:04:15 | | Quit Omlet (Client Quit) |
| 23:04:46 | alex` | domonoky1: I'm back. Are you just refering to the LANG_WARN_ERASEDYNPLAYLIST_MENU id? The others are all new |
| 23:04:46 | alex` | |
| 23:06:00 | domonoky1 | yes, and LANG_WARN_ERASEDYNPLAYLIST_PROMPT |
| 23:06:42 | amiconn | APE -c3000 uses a 64 tap filter and is realtime on coldfire, so it shouldn't be hard to get that 48 tap filter (with simpler structure) realtime as well |
| 23:06:44 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
| 23:08:31 | | Quit n1s ("Lämnar") |
| 23:10:25 | Unhelpful | amiconn: i'd meant to ask something re: font bitmap combining... cf can retrieve unaligned machine words, right? would it be worth using machine words instead of bytes when moving or combining font glyph data? |
| 23:10:25 | Torne | http://groups.google.com/group/pycorn/pendmsg?hl=en |
| 23:10:25 | Torne | oops |
| 23:10:27 | Torne | pardon my mispaste |
| 23:15:18 | amiconn | Coldfire supports unaligned memory accesses, yes. But there is of course a performance penalty |
| 23:17:07 | amiconn | Unaligned longword accesses are split into byte and word accesses, and even more importantly, movem.l doesn't use burst mode if the address is unaligned, even if a whole longword or line is covered |
| 23:17:31 | | Join melat0nin [0] (n=melat0ni@88-109-45-49.dynamic.dsl.as9105.com) |
| 23:17:49 | melat0nin | anybody know when the manuals will be back online? |
| 23:17:51 | amiconn | The memory controller isn't *that* intelligent, at least not on coldfire v2 (I have no idea about coldfire v3 or v4 regarding that - no such rockbox targets exist) |
| 23:18:19 | melat0nin | was reading the Fuze manual 2 days ago but it's gone now, both html and pdf |
| 23:18:43 | B4gder | I think they'll be around once me or zagor figure out why they vanished |
| 23:18:55 | melat0nin | wahey :) |
| 23:18:59 | melat0nin | thanks |
| 23:19:05 | B4gder | in a day or two I hope |
| 23:19:10 | amiconn | So on coldfire it is extremely important to either use iram, or use movem.l with full-line accesses for larger buffers if performance is important |
| 23:19:15 | melat0nin | am using google cache in the meantime, but there are no images :( |
| 23:21:26 | amiconn | There is a reason for that memcpy/memmove monster on cf... |
| 23:22:04 | melat0nin | is there a rockbox mirror w/manuals? |
| 23:22:44 | B4gder | http://download.rockbox.org/manual/ |
| 23:23:04 | B4gder | hm no |
| 23:23:56 | Unhelpful | amiconn: so it might be worth using aligned words when blitting or blending font data, even if they need to be shifted to meet the correct alignment, and even if they might need swapped to get bytes in-order? |
| 23:24:55 | | Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) |
| 23:25:14 | amiconn | It depends on where the buffer resides. If the intermediate buffer is in IRAM, shifting & swapping will probably make things worse |
| 23:25:23 | melat0nin | ach well |
| 23:26:01 | Unhelpful | hrm... ok. the non-blend case could always just call memcpy for each row, too. |
| 23:26:10 | amiconn | That is one reason why I think an intermediate buffer might even speed things up overall |
| 23:26:25 | pixelma | melat0nin: http://forums.rockbox.org/index.php?topic=23338.msg159076#msg159076 |
| 23:27:54 | amiconn | Another reason is that the drawing routines (which need to apply drawmode, background etc) will operate on fewer, larger source bitmaps |
| 23:28:42 | melat0nin | pixelma: thankyou very much! :) |
| 23:28:56 | | Join dfkt_ [0] (n=dfkt@unaffiliated/dfkt) |
| 23:29:27 | * | pixelma deflects the thanks to bluebrother ;) |
| 23:30:47 | melat0nin | :D |
| 23:31:55 | | Quit melat0nin () |
| 23:32:01 | | Join Res1 [0] (n=Res@user-0c6s6gs.cable.mindspring.com) |
| 23:33:12 | | Nick fxb is now known as fxb__ (n=felixbru@85.214.97.64) |
| 23:33:53 | | Join angelwolf71885 [0] (n=chatzill@cpe-173-171-133-36.tampabay.res.rr.com) |
| 23:33:53 | | Nick Ypsy is now known as YPSY (n=ypsy@geekpadawan.de) |
| 23:35:22 | Unhelpful | is it possible on CF to load a byte from a table into the register used to index the table? it would save having to extend the byte (i know it will be clear in the high 24) |
| 23:35:22 | | Quit fxb__ (Read error: 104 (Connection reset by peer)) |
| 23:36:42 | Unhelpful | i can't get gcc to do it, so i'd have to use asm, but i was kind of wondering if that was even going to be legal, or if it might incur a performance penalty and/or trigger a fault or exception of some sort |
| 23:37:10 | | Quit dfkt_ ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") |
| 23:37:47 | | Quit angelwolf71885 (Client Quit) |
| 23:38:06 | | Quit advcomp2019 ("Leaving") |
| 23:38:33 | | Join angelwolf71885 [0] (n=chatzill@cpe-173-171-133-36.tampabay.res.rr.com) |
| 23:38:43 | angelwolf71885 | irc.betaarchive.co.uk |
| 23:39:55 | amiconn | Unhelpful: You mean in scaled index mode? |
| 23:40:35 | amiconn | gcc isn't very clever in general (read: several instruction sequences it produces are braindead) |
| 23:41:28 | amiconn | Maybe it 's different for x86, but for our target architectures I've seen it doing many strange things |
| 23:42:31 | | Join fxb [0] (n=felixbru@h1252615.stratoserver.net) |
| 23:42:52 | Unhelpful | the function in question is av_log2 in codeclib/codeclib.h. to the extent of my coldfire asm knowledge the generated code is optimal, except that *if* the LUT value (from a char array) could be written into the register used to index the load, we could save an ext.b |
| 23:43:05 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 23:43:41 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 23:43:52 | | Nick Rondom_ is now known as Rondom (n=quassel@dslb-084-057-140-109.pools.arcor-ip.net) |
| 23:44:18 | amiconn | Afaik there is no such restriction |
| 23:44:25 | Unhelpful | hah... you know what, actually, gcc answered my question, as it generates "move.b (%a0,%d0.l),%d0; extb.l %d0" |
| 23:45:01 | amiconn | It just doesn't know that the extb.l is superfluous... |
| 23:45:22 | Unhelpful | exactly. that would need it to be a bit more clever than we can probably expect |
| 23:46:25 | alex` | nls: I found another off-by-one for format_track_path which I should have checked for when I submitted the patch, should I raise another Flyspray bug? |
| 23:46:27 | Unhelpful | although it's smart enough to figure do x ? 31 - __builtin_clz(x) : 0 on arm as tst; clzne; rsbne; |
| 23:46:40 | Unhelpful | and to skip the test if the input is calculated |
| 23:47:06 | amiconn | We're using gcc 4.0 on arm, but 3.4 on coldfire |
| 23:47:07 | | Quit dfkt (Read error: 110 (Connection timed out)) |
| 23:47:26 | amiconn | (4.0 on coldfire isn't really an improvement though) |
| 23:48:28 | | Quit dmb ("Leaving") |
| 23:49:44 | Unhelpful | that's true, but gcc only seems to be reasonably clever about zero/nonzero, and sometimes equality tests. value range/size stuff it doesn't figure out so much, half of the gain on armv4 for jpeg idct in asm was forcing optimal order for multiply operands and killing a bunch of superfluous extension instructions created by the mul16 C macro |
| 23:52:04 | | Quit saratoga (Ping timeout: 180 seconds) |
| 23:52:30 | linuxstb | B4gder: Have we deliberately changed to only keeping the previous two daily builds? I thought we kept a month's worth? |
| 23:53:07 | B4gder | I'm not sure, zagor's the one who's fiddled with the scripts |
| 23:53:23 | | Quit bmbl ("Bye!") |
| 23:54:35 | | Part froggyman |
icon identifies that the person is a core developer (has commit access).