--- Log for 30.10.107 Server: calvino.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 28 days and 20 hours ago 00.03.41 Quit bluebrother ("leaving") 00.05.58 Quit linuxstb_ ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") 00.12.32 Quit davina (Remote closed the connection) 00.13.41 Quit bertrik ("bye") 00.14.21 # preglow: Hmm? clip_sample() is #if 0'd... 00.16.26 # amiconn: but used verbatim (plus bugs i removed...) in sample_output_dithered 00.16.51 # anyway, it doesn't work if range >= 2^31 - 1 00.17.00 # which is the case for wma.c, which outputs with 30 frac bits 00.17.09 # can you see a way around that? 00.17.20 # sure... range is an int32, and can't assume larger values 00.17.36 # little question, is there with current build a problem with flac files? it just stops playing after or while rebuffering, no hard crash. could it be a problem with the file being larger than the buffer? 00.17.36 # it doesn't handle the case of max integer value either 00.17.39 # 2^31 - 1, that is 00.17.41 # You would need to use an uint32 to start with 00.18.10 # In fact range can assume that value, but it's its max value 00.18.17 # And why do you need to clip at all then?? 00.18.35 *** Saving seen data "./dancer.seen" 00.18.50 # * amiconn is puzzled by the bcm :/ 00.19.46 # amiconn: it's just plain broken for such large numbers, i'm just wondering if you know of another scheme that works for that case 00.19.55 # if not, i'm going to just replace it with a naive clip 00.20.08 Join donutman25 [0] (n=chatzill@65.75.87.48) 00.20.25 # Why do you need to clip if you use the full range anyway? That's what I don't get... 00.21.12 # * amiconn can't help if he doesn't understand the problem 00.21.13 # i don't use the full range, i only use -2^30 to 2^30 - 1 00.21.29 # the range value is max - min, which is 2^31 - 1 00.22.04 # so there's still range enough to clip, but this particular scheme doesn't work because of the big values 00.22.09 Join J3TC- [0] (n=jetc123@pool-72-76-179-145.nwrknj.east.verizon.net) 00.23.03 Join iamben [0] (n=ben@dpc67142179038.direcpc.com) 00.23.41 Join midgey [0] (n=tjross@westquad-188-67.reshall.umich.edu) 00.23.50 Quit FOAD (Remote closed the connection) 00.25.20 # Hmm, I'm not sure I understand how clip_sample is even supposed to work 00.25.49 # I'm sure that because I wrote it :P 00.26.05 # Is 'min' the actual minimum, or the negative of it? 00.26.06 # jhMikeS: wonderful! then you fix it! :P 00.26.11 # amiconn: the actual 00.26.25 # amiconn: -2^x - 1 00.26.25 # you're saying something is using the full int32 range? 00.26.27 Join FOAD [0] (n=dok@dinah.blub.net) 00.26.40 # amiconn: ehh, -2^x 00.26.50 # jhMikeS: clipping from -2^30 to 2^30 - 1 messes up badly, overflows on positive clips 00.27.25 # jhMikeS: so basically, it seems to bug out when frac_bits >= 30 00.27.54 # it makes efficient asm when compiled though 00.28.00 Join jdgordy [0] (n=jdgordy@c210-49-113-143.smelb1.vic.optusnet.com.au) 00.28.08 # preglow: I guess just the part within the if() {} is messed 00.28.18 Part toffe82 00.28.27 # I 'd write that differently 00.29.09 Join hcs [0] (n=agashlin@rockbox/contributor/hcs) 00.29.42 # i'm open for suggestions from the both of you 00.30.10 # what uses 30 bits anyway? 00.30.18 Join louisj [0] (n=tom@c-76-116-33-246.hsd1.nj.comcast.net) 00.30.51 # http://www.rockbox.org/wiki/IrcGuidelines 00.30.59 # jdgordy: I am working on the FS#8008, so leave it alone please. :) 00.31.03 # jhMikeS: wma 00.31.10 Part louisj 00.31.26 # jhMikeS: i'm going to adjust that downwards, but that still doesn't make that clipping function work right 00.31.30 # that's the dither thing with WMA? 00.31.35 # jhMikeS: aye 00.31.35 # roolku Ok : 00.31.45 # if ((uint32_t)(sample - min) > (uint32_t)range) { c = min; if (sample > min) c += range; sample = c } 00.32.30 # The "c > 0" is probably what doesn't work in the current version 00.32.54 Quit jdgordy ("DSOrganize IRC") 00.33.13 # amiconn: that is correct 00.33.17 # it does work but I guess excess range messes it up? 00.34.37 # which means it doesn't work :P 00.34.46 # that's where the bug happened anyway 00.35.27 Join JdGordon [0] (n=jonno@c210-49-113-143.smelb1.vic.optusnet.com.au) 00.35.29 # true, the contract isn't totally fullfilled :) 00.35.37 Join Spiritsoulx [0] (n=eyes_of_@24.86.181.152) 00.35.55 # * pixelma wonders if her one wma that has audible glitches in rb suffers from the same... 00.35.56 Quit Spiritsoulx (Client Quit) 00.35.57 # range should be unsigned anyway 00.36.19 # roolku: do you tihnk it would make sense to add the option to allow the int values to work? 00.36.28 # amiconn: sounds good 00.36.32 # Well, if the clip should be always symmetrical, it could be simplified further 00.36.37 # pixelma: is it really clipped? 00.36.45 # it's clipping that's for sure and I sent it to saratoga a while ago - he wanted to look into it but had no time since then 00.37.04 # amiconn: as it's used right now: yes, the usual [-2^x, 2^x - 1] type clip 00.37.45 # pixelma: a file that clips really badly and has overflow distortion? 00.37.48 # pixelma: if so, this'll fix it 00.37.51 # well, it was meant for arbitrary, not symmetrical or 2^something 00.37.55 # pixelma: that is, if you have dithering enabled :) 00.38.03 # preglow: it was better in the better in the beginning of the wma codec. It had an audible glitch but wasn't that obvious 00.38.08 # jhMikeS: sure, but we don't need arbitrary, do we ? 00.38.12 # and to minimize the overhead for the majority of things that don't clip 00.38.18 # pixelma: then that's probably not what's going on 00.38.24 # pixelma: i'll have that file if you can be bothered 00.38.40 # I think I haven't enabled dithering, if it's not default... 00.38.45 # preglow: I didn't know the answer to that at the time so didn't assume that. 00.39.03 # jhMikeS: sure, just wondering if we're doing it currently, or might want to 00.39.10 # jhMikeS: can't think of a reason for it right now 00.39.19 # preglow: you want the file? 00.39.26 # pixelma: sure 00.39.51 # preglow: There used to be an arbitrary range the codec would set but those DSP messages were removed. 00.39.54 # linuxstb: Around? 00.40.06 # jhMikeS: yeah, that's right 00.40.53 # Seems the bcm doesn't care about any of the parameters in lcd_bcm_setup_rect() except the actual rectangle coordinates 00.40.59 # I guess if ((uint32_t)sample > (1u << bits)) would be better or something 00.41.29 # does that work? can't tell right now. just ate dinner. 00.41.30 # jhMikeS: i'm just gonna leave it as amiconn wrote it for now 00.41.30 # That would have to be >= 00.41.39 # right 00.41.49 # i don't think we're missing many cycles here 00.42.06 # can't be bothered to bug test more, i like this ratm track :) 00.42.20 # clipped though it may be 00.43.15 # did anyone notice that playback stops in the middle of a file if it is bigger than the buffer? i have seen this with mp3 and flac files. 00.44.29 # PaulJam: you need pondlife or Nico_P 00.44.32 # well, that sounds nice... 00.44.32 # * jhMikeS hasn't listened to any such tracks yet so would have missed out on the fun 00.47.05 Quit kkurbjun (Read error: 113 (No route to host)) 00.47.25 # ok, a 15:10 beethoven flac should do it 00.49.00 # PaulJam: does it cut it off and continue or playback just stops entirely? 00.49.21 # * petur spots serious musical differences... beethoven <-> ratm :) 00.50.00 # * jhMikeS has that too 00.50.02 # playback just stops, but it stays in the WPS and isn't frozen, playback status is still play. 00.50.21 # JdGordon: the only potentially useful tag I can see would be year and personally I can't see the benefit. 00.51.37 Join Spiritsoulx|hw [0] (n=eyes_of_@24.86.181.152) 00.51.43 # can you update tagnavi.config for the extra options? I was going to but realised i didnt know how it worked :p 00.51.47 # Does anything have the link to the Rockbox Installer? 00.52.37 # www.rockbox.org? 00.52.40 # hmmm...must be waiting for rebuffer that never happens or something 00.52.54 # No, there's an installation program. 00.53.04 # So you don't have to download the .zip file. 00.53.35 # JdGordon: do we really need them all in? maybe #title#, but the rest seems of limited use and more suitable for the custom_config 00.53.50 # I dunno 00.54.30 # JdGordon: we don't have ordinary searches for all the tags either 00.54.36 # ok 00.54.59 # Spiritsoulx|hw: http://www.rockbox.org/twiki/bin/view/Main/RockboxUtilityQt 00.55.29 # * jhMikeS restarts with a 105MB flac 00.55.41 Join barrywardell [0] (n=barrywar@194.46.162.79) 00.55.42 # jhMikeS: i maybe have found a pattern when it stops. it looks like the remaining data form the song that doesn't get played is a whole multiple of the total amount of buffer. 00.55.48 # Perhaps an "Installer [beta]" link is in order soon? 00.55.59 # Spiritsoulx|hw: and also http://download.rockbox.org/rbutil/ 00.56.15 # rasher: yes 00.56.18 Quit Spiritsoulx|hw (Client Quit) 00.56.31 # oh nice, thank you too 00.57.07 Join karashata [0] (n=Kimi@pool1-181.adsl.user.start.ca) 00.57.42 Quit animeloe (Read error: 113 (No route to host)) 00.57.54 Quit jumijoze (Read error: 104 (Connection reset by peer)) 00.58.53 # PaulJam: would be interesting. is that confirmed? it doesn't seem too likely to work out like that. 01.00.10 Join animeloe [0] (n=animeloe@ool-44c2be34.dyn.optonline.net) 01.00.19 # well, it could be a coincidence, but i confimed it with 4 files. it almost looks as if the song "ends" at the correct position in the buffer, but just one ore more rebuffers too early. 01.01.51 # preglow: what's the point of NATIVE_DEPTH anyway? 01.02.58 Join jumijoze [0] (n=jumijoze@unaffiliated/mike-zed) 01.04.44 # preglow: The version in the #if0 block misses a semicolon... 01.04.48 # rasher: what do you mean with the installer link? 01.05.01 # amiconn: woops, i completely forgot about it 01.05.05 # pixelma: in the menu on www.rockbox.org 01.05.11 # Not that it matters... 01.06.13 # rasher: ah, I see. At least it is already linked and described in the manual... 01.06.22 # jhMikeS: point? not having a constant? *shrug* 01.06.37 # jhMikeS: i guess we envisioned using multiple depths by now :P 01.06.42 # pixelma: ideally a regular user wouldnt have to look at the manual before he hits trouble 01.06.48 # not that NATIVE_DEPTH would have helped us in that... 01.06.55 # * preglow needs sleep, he thinks 01.07.41 # preglow: we use multiple depths? wow! :P 01.08.12 # * amiconn could need someone with a plain G5 (hw rev <= 0xb0009) who could do a number of experiments 01.08.21 # jhMikeS: but i don't really get what you mean, what's wrong with NATIVE_DEPTH? 01.08.39 # amiconn: doesn't linuxstb have one of those guys? 01.08.48 # yes 01.09.10 # Hence my trigger ~30 minutes ago 01.09.56 # preglow: I guess we scale up for <= NATIVE_DEPTH but not for >. So what's the point in upscaling? Fractional stuf later? 01.10.43 Quit Zagor ("Client exiting") 01.10.55 Join mrmacky [0] (n=chatzill@mke-66-97-114-76.milwpc.com) 01.11.11 # I suppose it keeps precision higher during the processing of low-depth audio. 01.11.34 # it does 01.11.53 # there'd be no point in not shifting it up anyway 01.12.13 # since we have to put the samples in 32 bit arrays 01.12.57 # less crud in dsp.c ? Since it's not really crud I guess ... ignore me :) 01.13.27 Join mrmacky_ [0] (n=chatzill@mke-66-97-114-76.milwpc.com) 01.13.27 Quit mrmacky (Read error: 104 (Connection reset by peer)) 01.13.31 Nick mrmacky_ is now known as mrmacky (n=chatzill@mke-66-97-114-76.milwpc.com) 01.13.53 # i wouldn't really call it crud, no :P 01.14.04 Quit Isolinear (Read error: 113 (No route to host)) 01.14.11 # btw, think of a fancy way to fix the overflowing in eq_filter() for me ... 01.19.46 # it is overflowing afterall? 01.21.30 # I guess for ARM5 and above use the builtin clipping. :) For the puny one, I never could do it in fewer than four instructions. 01.23.14 # jhMikeS: the fixed point format fixup (left shift) is clipping 01.23.29 # jhMikeS: arm5 doesn't have builtin clipping 01.24.03 Quit kugel ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") 01.24.11 # it does have a saturating add, but i can't shift with that :> 01.24.19 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 01.24.45 # ah yes, that's exactly why I used emac for shifts on cf but needs int mode 01.24.49 # arm6 does have a saturating shift :/ 01.25.14 # jhMikeS: int mode mac shifts can only do one shift left, doesn't help me 01.25.27 # i've used that once for free shift, though, in speex 01.25.36 # nono. multiply by 2^shift 01.26.05 # hmm 01.26.09 # why wouldn't that work in frac mode? 01.26.23 # Because frac mode multiplies by <= 1? 01.26.38 # it's up to you to interpret what format your data is 01.26.42 Quit petur ("Zzzzz") 01.27.10 # hrhmmmno, it wouldn't help me far, i still need to save my filter history as 32 bit ints 01.27.12 # It wont work because frac mode will never produce more bits. 01.27.23 # and then those would overflow 01.28.08 # shit, i'm just inclined to have people enjoy that overflow noise 01.28.11 # the result will stay saturated to 32-bits anyway 01.28.31 # it'll sound only marginally worse than the incredibly bad clipping they'd been hearing for the last 12 decibels 01.29.13 Join toffe82 [0] (n=chatzill@adsl-70-137-198-176.dsl.frs2ca.sbcglobal.net) 01.29.14 # wraparound is horribly noisy..even by 1 01.29.44 # yep 01.29.51 # arm6 has exactly what i need :/ 01.30.36 # I suppose an ARM_ARCH #define is in order. Isn't something ARM6 coming in the fold? 01.31.34 # i doubt it 01.31.43 # arm6 is really high up the ladder 01.37.30 # hmmm...something just occured to be about the shift. use rotate, see if r2 asr r12 == r10 01.38.40 # maybe rol isn't even needed...hmmm 01.39.08 # * preglow waits patiently :V 01.39.34 Join SirFunk [0] (n=Sir@206-159-155-246.netsync.net) 01.40.47 # mov r2, r2, r10, asl r12. cmp r10, r2, asr r12, beq . sound right? 01.41.20 # r10 = r11 :p 01.41.57 # ..and delete an r2 from that mov there. oy... 01.42.02 # yes... :) 01.42.29 Quit lee-qid (Read error: 110 (Connection timed out)) 01.42.36 # that would work 01.42.39 # yes,yes it woudl 01.42.45 # and it would also work for coldfire, but slow shit down 01.43.25 # mvnne r2, r10, asr #31 for clamp 01.43.40 # no, that's unsigned...argh 01.44.16 Quit donutman25 ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") 01.44.21 # hrmph, asl.l on coldfire never touches overflow, would have been extra cool if it set overflow if it shifted out any 1 bits 01.44.24 Quit midgey () 01.44.29 # geh, that would break for negative numbers 01.44.43 Join midgey [0] (n=tjross@westquad-188-67.reshall.umich.edu) 01.44.52 # if it set overflow when shifting out any bit not corresponding to the first bit it saw :P 01.45.03 # yeah, right :) 01.45.08 Quit midgey (Client Quit) 01.46.01 # there's little fancy thing to actually do the clamp...I'd actually need to code it in place to see it clearly 01.47.08 # go ahead 01.47.18 # i already have code in there i don't use in normal builds 01.49.54 Join bluehaze [0] (i=bluehaze@lin-dsl-static-209-50-25-005.inetnebr.com) 01.49.58 Part pixelma 01.53.26 # http://www.pastebin.ca/754470 <= probably a slightly more elegant way exists but the beq is likely faster than conditional execution 01.54.46 Join TotallyInfected [0] (n=ebola@pool-151-197-41-145.phil.east.verizon.net) 01.55.28 # it has to be optimized for non-clippe samples anyway 01.56.27 # that'll add, what, 4 cycles extra overhead for non-clipped samples? 01.56.55 Join Bam2550 [0] (i=the@c-69-249-243-110.hsd1.pa.comcast.net) 01.59.44 # not much I'd think. we want to clamp to the 32-bit range right? or something else? 02.01.15 # to the 32 bit range, yeah 02.01.21 # the compare and branch takes 4 cycles? 02.01.37 # but what about when you use the history later? 02.01.41 # compare takes two, branch takes 1 + branch overhead 02.01.54 # history has to be clipped 02.02.18 # so it's probably closer to 5-6 cycles extra per non-clipped sample 02.02.22 # about the same for clipped 02.02.43 # clipped is 6, yeah 02.03.07 # but it'll be slower, has to fetch clip limits from memory 02.04.22 Quit Toxicity999 ("Leaving") 02.05.02 # from memory? 02.05.08 Quit PaulJam (".") 02.05.51 # well, yeah, we don't have enough regs to store them there 02.05.57 # eq_filter is really, really tight on regs for arm 02.06.26 # It should only need to fetch if clipping is required which shouldn't be often I'd hope 02.06.36 # yeah, sure, was what i meant 02.06.57 # i'm more concerned that so many cycles are wasted for non-clipped samples 02.07.05 # but anyway, it's arm, a single smlal can easily take 4-5 cycles 02.07.16 # so i guess this isn't anything 02.07.18 Quit J3TC- (".•«UPP»•.") 02.07.31 # jhMikeS: feel free to stuff this shit in eq_arm.S if you get it working, just don't enable it quite yet 02.07.39 # i need to go sleep now 02.07.44 # nighty 02.07.46 # nighty 02.08.07 Join aliask_ [0] (i=3a6d61d2@gateway/web/cgi-irc/labb.contactor.se/x-73dde7fea5fc1c2d) 02.10.07 Join Toxicity999 [0] (n=bryan@cpe-76-179-68-20.maine.res.rr.com) 02.10.09 # i have a 4G ipod, and only a firewire cable. Is it possible to mount the Fat32 filesystem with it? 02.12.58 # * bluehaze kicks himself for giving away his usb cable 02.14.05 # XP here mounts FAT-32 on my 3G through a firewire card 02.14.46 # i'm on OSX 02.15.30 # Well, I'm saying it's possible. I don't know if it's supported everywhere. 02.17.00 Quit cooz () 02.18.36 *** Saving seen data "./dancer.seen" 02.20.40 Join J3TC- [0] (n=jetc123@pool-72-76-179-145.nwrknj.east.verizon.net) 02.27.48 # bluehaze, firewire is just the transport, it should have no impact on the os reading the file system 02.28.49 # ok. i was worried i'd run dd, and then wouldn't be able to mount the file system once it was done 02.30.25 Quit Bam2550 () 02.35.16 Quit Thundercloud (Remote closed the connection) 02.35.40 # JdGordon: okay, I have added the patch to FS#8008 - seems to work fine in sim, but haven't tested on target and need to sleep now. Feel free to commit if you are happy with it, otherwise I'll do it in the mmorning 02.36.14 Join z35 [0] (n=z@149.123.33.65.cfl.res.rr.com) 02.36.44 # ok 02.36.53 # is that to allow multple dynamic tags in a search? 02.37.41 # yes, amongst other things mentioned 02.37.46 # cool 02.38.14 # good night 02.38.22 Quit roolku () 02.41.55 Join alienbiker99 [0] (n=alienbik@ool-44c126d4.dyn.optonline.net) 02.42.31 Part toffe82 02.43.22 # bagh, where's Nico_P... I don't understand the mechanism that releases old tracks (which _appears_ to be the problem with audio stopping for no good reason) 02.44.09 Quit bluehaze ("thanks!") 02.45.33 Join lukaswayne9 [0] (n=lukas@c-68-84-69-12.hsd1.nj.comcast.net) 02.48.52 # Hrmm 02.49.41 # Is there any chance that jpg/png album art from tag will be supported or will it just be similar with the current album art patch now? 02.49.51 # there is always a chance 02.50.17 # True but how likely is that chance ;x 02.57.27 Quit barrywardell () 02.58.49 # more likely if you wrote the code J3TC- 02.59.50 # Lol, nah...I'm not that great with coding. 03.00.04 # less likely then 03.00.24 # Sadly, my major doesn't go much into detail with hardware programming :3 03.03.30 Join RoC_MasterMind [0] (n=Free@c-66-177-39-225.hsd1.fl.comcast.net) 03.04.15 Join webguest06 [0] (i=dcf56b6c@gateway/web/cgi-irc/labb.contactor.se/x-716baecd2e5503bd) 03.04.47 Nick webguest06 is now known as goldy (i=dcf56b6c@gateway/web/cgi-irc/labb.contactor.se/x-716baecd2e5503bd) 03.04.57 # J3TC-, all programming involves hardware at some point. Rockbox is just C and the majority of it isn't hardware specific. 03.04.59 # hello 03.05.43 Quit HellDragon (Client Quit) 03.06.16 # does anybody know if rockbox works on ashroti mp3-mp4 players (ipod nano copies)??? 03.06.19 Join HellDragon [0] (n=Nocebo@unaffiliated/helldragon) 03.06.36 # goldy, what's supported is listed on the front page. If it's not there, then no. 03.06.48 # no probs, thanks 03.06.53 Join JdGordon|DS [0] (n=jdgordon@c210-49-113-143.smelb1.vic.optusnet.com.au) 03.07.46 Quit JdGordon|DS (Client Quit) 03.08.46 Quit aliask_ ("CGI:IRC") 03.09.23 Quit spiorf (Remote closed the connection) 03.11.41 Join JdGordon|DS [0] (n=jdgordon@c210-49-113-143.smelb1.vic.optusnet.com.au) 03.13.48 Part JdGordon ("Konversation terminated!") 03.14.14 Join Llorean [0] (n=llorean@cpe-70-113-103-34.austin.res.rr.com) 03.16.22 # Nico_P: (for when you return, if you read logs) I think that any bufopen or bufalloc should take an argument of a callback to say to whomever buffered this item that it is being freed and that if the caller needs the resource again they need to rebuffer it. 03.17.16 # Nico_P: I'm trying to get a logfdump of it happening on target but I _think_ that what's happening when playback stops is that the buffer_low_callback is somehow not being treated when the buffer is low but fully allocated. 03.18.27 Join webguest82 [0] (i=4ca81f01@gateway/web/cgi-irc/labb.contactor.se/x-d5f8e307321c4ad4) 03.18.34 # ppl help me!!!!!!!!!!!!!! 03.18.59 # plezz!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 03.20.32 # webguest82: It helps a lot if you read the channel guidelines, people are more likely to help someone who's willing to take a few seconds to do things right. 03.20.42 # webguest82: first of all, you might get a little more response if you use proper english and don't abuse the !, second of all, no one can help you unless you tell us what your problem is 03.20.48 # and what Llorean said 03.24.00 Join psycho_maniac [0] (i=psycho_m@ppp428.hk.centurytel.net) 03.24.37 # uhm im a newb. i have rockbox and ipod linux on my ipod. evrything was fine until i used ipod wizard. i actually used ipod wizard before i put the rockbox and ipod linux on there. but anyways i downloaded a theme from the ipod wizard.com and uploaded it to my ipod using the wizard. once i ejected it it rebooted like it should have but the pics and evrything wasnt there. so i used ipod wizard again to load my 03.25.40 # Well, 1) Messages too long get cut off, and 2) This is #Rockbox, we don't provide support for iPod Wizard 03.26.44 # Darnit. ok. but if i use the itunes restore, can i still put rockbox back onto my ipod? 03.26.53 # Yeah 03.27.02 Join Isolinear [0] (n=A@c-76-105-254-119.hsd1.or.comcast.net) 03.27.20 # If your iPod is working well enough to boot the original firmware fine, you should always be able to install Rockbox from that state 03.28.02 # Yes! Thank you Llorean im going to do it right now. 03.28.46 # oh but it says its a ipod software update. thats still ok? sorry for all these questions. 03.29.51 # As I said, as long as the iPod can boot the Apple OS, you should then be able to go from there to Rockbox. :) 03.31.29 Quit JdGordon|DS (Read error: 110 (Connection timed out)) 03.31.32 # ok thank you 03.33.01 Join Calcipher [0] (n=Calciphe@ool-18bab657.dyn.optonline.net) 03.40.32 # its working...i love you Llorean. ^_^ thanks again. 03.40.55 # another convert to the religion of Llorean 03.41.08 # * karashata chuckles a little 03.41.37 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 03.46.41 Join Roan [0] (n=JustJohn@pool-141-157-19-12.balt.east.verizon.net) 03.47.09 # hmm, I'm getting some issues playing back a FLAC file... 03.47.44 # it's stopping playback quite frequently and the only way to get it to continue is to fully stop it and resume playback again 03.47.58 Part Roan 03.51.33 # and apparently that's not even working very well 03.52.50 # karashata: interesting, is the file larger than the buffer? 03.53.19 # I don't know, it could be 03.53.25 # lemme check a second 03.54.08 # um... 03.54.18 # there isn't a way to check file sizes in RB is there? 03.54.27 # file size? 03.54.41 # karashata: Click and hold the select button on a file, and choose Properties I believe 03.54.47 # i think. go to the song hold select and click proprities. 03.55.12 # ahh, from the file browser, okay 03.55.22 # nothing in the WPS context menu showed it 03.55.33 # nope. wish it did though. :) 03.55.34 # the file's 17 MB 03.55.38 Quit mrmacky ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") 03.55.45 # what's the buffer size? 03.55.59 # 29 or so 03.56.07 # hmm... 03.56.08 # Unless you're on an X5, M5, or Archos. 03.56.18 # nope, H10 20 GB 03.57.35 # karashata: ahhh, that actually explains the bug I'm seeing too. I thought that it was a problem with the allocated buffer space being full and therefor not being able to fill, but it's actually a problem that if the compressed filebuffer ever runs low enough that the codec can't satisfy a request then it stops. 03.57.48 # Nico_P: new theory above. 03.58.07 # heh 03.58.14 # that's not good 03.58.43 # karashata: normally it's not a problem because the buffer should start filling at the watermark, not when the codec is actually out of data to chew on 03.58.51 # the file's playing back after shutting the player down and rebooting 03.58.54 # karashata: but on flacs or occasionally when it starts a buffer fill run it will 03.58.55 # lostlogic: Ah, yeah high bitrate flacs used to starve the compressed buffer long enough for the PCM buffer to empty even pre-MOB 03.58.58 # Though playback wouldn't stop 03.59.05 # Llorean: yeah. 03.59.43 # As a temporary solution, the anti-skip buffer can be increased a little bit. 03.59.56 # Though ideally one shouldn't have to adjust that based on the bitrate of their files. 04.00.03 # I wonder if I can decrease it and ensure that I trigger this bug more frequently 04.00.11 Join rotator [0] (n=e@rockbox/developer/rotator) 04.00.19 # Llorean: yeah, it should be (IMO) based on the bitrate of the playing file 04.00.21 # * karashata keeps it at 5 seconds normally, or whatever the lowest setting is 04.00.26 # lostlogic: Absolutely agree. 04.00.50 # If I recall, amiconn wants the anti-skip buffer banished anyway, and I think I agree with him. It really *shouldn't* be necessary if everything is working right. 04.01.00 # * karashata agrees 04.01.28 # * psycho_maniac also agrees 04.01.35 # heh... 04.01.49 # the files are playing fine now, nicely 04.01.55 # Llorean: I disagree -- it still applies that if you are shaking the player it won't be able to buffer during the shaking and that buffer is roughly how long it can be shaken for continuously during a buffer fill attempt without skipping 04.02.05 # karashata: did you increase the buffer? 04.02.11 # nope 04.02.16 # *frownie face* 04.02.27 # it just seems to be working now 04.02.57 # lostlogic: Wouldn't conditions where shaking the player is bad enough to actually slow buffering to a rate slower than playback be actually pretty harmful to the drive anyway? 04.03.03 # though, I finally got to see that small issue of the next track info showing up if it's playing the last track in the buffer 04.03.31 # Llorean: not really no -- you can cause the heads to get more crc failures just from being active with the player in a jacket pocket (trust me on this ;)) 04.03.34 # Anyway, at the very least, anti-skip should have a "0" option, and never be necessary under "player sitting on a table in a tectonically stable region" 04.03.34 # ..and as soon as I turn the backlight on, I discover that it refilled the buffer and I got my next track info 04.03.41 # but now the music stopped again 04.04.11 # Llorean: yes, a zero setting and then the buffering API just having an internal watermark to buffer from that allows for drive spin up would be nice. 04.05.15 # lostlogic: Isn't the PCM buffer already something like 3 seconds of audio? 04.05.39 # How long do the spinups take? 04.05.53 # * Llorean is really a little uncertain what the PCM buffer is for right now. 04.05.54 Join ramon8 [0] (i=DontFuCk@adsl-71-146-171-171.dsl.pltn13.sbcglobal.net) 04.05.59 Quit Toxicity999 (Remote closed the connection) 04.06.21 # We have the PC buffer, the low watermark for the compressed buffer, AND the anti-skip "buffer" and I'm a little unsure the unique jobs of each. 04.06.25 # PCM 04.06.47 # * karashata skips out of the FLAC files for now 04.07.12 # Llorean: the pcmbuffer holds roughly 1-3 seconds of audio, full spin up time can be up-to 2 seconds and it's never good to starve the pcm buffer, it's there for a reason (to allow for decreased decoding speed during any kind of UI operations) 04.08.13 Join midgey [0] (n=tjross@westquad-188-67.reshall.umich.edu) 04.09.48 Join Toxicity999 [0] (n=bryan@unaffiliated/Toxicity999) 04.11.29 # Alright 04.11.45 # so short versions: PCM buffer is to allow for CPU slowness (for any reason, but mostly caused by disk activity or UI activity). There are two watermarks on the compressed buffer, the low watermark is the same as the anti-skip buffer and is dual purpose, it is to allow for jostling during buffer fill and also for disk spin time. The other (only on high mem targets) is a high watermark which is the level below which the buffering code con 04.15.02 Quit RoC_MasterMind ("Leaving") 04.16.15 # lostlogic, your message cut out at "buffering code con..." 04.16.38 # siders it worthwhile to do some buffering if the disk happens to be spun up for some other reason. 04.17.29 # weird, irssi is supposed to auto-split 'em if they're going to be too long. 04.17.50 # lostlogic: Shouldn't the buffering code consider it worthwhile to top off the buffer *any* time the disk is spun up just about? 04.18.39 *** Saving seen data "./dancer.seen" 04.19.19 # Llorean: not sure the rationale there, just reading the code ;) 04.20.17 # how do i use the dict? 04.20.27 # As far as my brain goes, if you need to spend 45 seconds buffering total, and can get it with 7 spinups by piggybacking on user initiated ones, or 12 spinups if you ignore a few of them if the buffer isn't low enough, the 7 spinups is better even if one of them only buffers 3mb. 04.21.13 # Basically, "you'll always have the same net buffering time for X amount of data, so minimize the spinups if you can" 04.21.59 Quit ramon8 ("O FUK! WAATZ DAT SMELL?!!! O WAIT I FORGETS DAT I AM DA DOPEST SHIITTT!!!") 04.22.22 # Llorean: yeah, I see where you're coming from, but I'm guessing someone had a good reason for not buffering anytime the disk is spinning and the buffering thread happens to wake up 04.22.45 # lostlogic: I'd assume so too, I'm just really curious what it is. :) 04.22.50 # :) 04.23.38 # There's always the off chance that it's just a holdover from a point when the buffering code couldn't (or didn't choose to) know about other disk spinups, or similar. 04.25.03 # Llorean: more likely (as I look) it was added when before the buffering code would only buffer when it was low, I wonder if we can dig out of SVN when it was added. 04.25.41 Quit miepchen^schlaf (Read error: 110 (Connection timed out)) 04.25.44 # That's essentially what I meant. "Only refill when low, as we don't know what the disk is doing at any time so we just do it when we *know* we need to" 04.25.57 # nod 04.26.06 # But I rather like the idea of my buffer topping itself off when I launch a plugin or some such 04.26.10 Join miepchen^schlaf [0] (n=hihi@p54BF6D6B.dip.t-dialin.net) 04.26.43 # it will if the buffer is < 75% full at the time ;) 04.27.23 # Ah, but at my audiobook bitrates that could be something like half an hour of audio. 04.27.43 # *nod* 04.27.56 # Still, if the high watermark is around 75% it's not so bad. 04.28.01 # Still, seems a somewhat arbitrary location. 04.28.20 # yay magic numbers! 04.29.33 # I mean, I could understand not doing it in a situation where the seek for the file would take more than the read/buffer because of how little is needed, I suppose... 04.29.41 # But that seems like it'd be a much, much, much smaller number 04.29.58 # Llorean: yeah, specially with a 30m buffer 04.35.49 # Llorean: the other 'cost' to buffering early is that it does invalidate the just-played tracks more frequently making back skipping more often require a spin 04.35.59 Join a11313 [0] (n=a11313@CPE-69-23-137-242.wi.res.rr.com) 04.35.59 Join ddalton [0] (n=ubuntu@203-214-86-100.dyn.iinet.net.au) 04.36.58 # lostlogic: I would guess most triggered spinups during playback are either more tracks added (assuming that even triggers one, I'm not sure it'd need to with dircache), or launching a plugin. 04.37.04 # And with plugins at least, back skipping is unlikely 04.37.13 Part ddalton ("Ex-Chat") 04.37.23 # anyone know if a podzilla legacy binary can replace a rockbox binary on a device other than ipod? 04.37.47 # lostlogic: Even then, the "cost" increases after the 75% mark is reached, rather than decreases. :) 04.38.14 # a11313, what do you mean replace? podzilla is iPod specific AFAIK 04.38.45 Quit goldy ("CGI:IRC (EOF)") 04.38.50 # a11313: Not to mention it's not our software. 04.38.59 # a11313: rockbox is quite different from IPL 04.39.15 # safetydan granted the binary needs to be changed for input buttons, would it be able to load the binary if it has linux on it? 04.39.38 # a11313: rockbox is quite different from IPL 04.40.01 # Llorean: not exactly, the cost in this case is the same no matter how empty or full the buffer is -- it's the loss of the ability to skip back to the last played track w/o buffering and that's the only track that matters that's going to be clobbered 04.40.13 # a11313, what are you trying to do? 04.40.15 # what would make you think it could work? 04.40.51 # just looking into a mp3 player besides ipods that can have linux on it, preparing for when the flash chips on my nano croak 04.41.09 # any breaking news on the rb front? 04.41.16 # well, that is offtopic for this channel 04.41.17 # chances are I can look at the source of rockbox and add my applications to it 04.41.24 # rockbox isnt linux 04.41.27 # a11313, I'm not aware of any other Linux ports to MP3 players. Besides, this channel is about Rockbox not Linux. 04.41.39 # my apologies 04.41.44 # lostlogic: If the last file is 7mb long, but the previous buffer only held 6mb, will the newest one only have 1mb of it, or will it keep the previous 6mb around after refilling? 04.42.01 # I was under the the impression that rockbox ran on linux though 04.42.09 # it doesnt :) 04.43.18 # I believe the mrobe 500 has a linux port, but like you guys said thats off topic, and hey theres also google, thats how I found that 04.43.18 # okay, so I can't add homebrew games to the sansa e200 with rockbox? 04.43.38 # sure you can...you just need to port them to rockbox 04.43.54 # assuming you are talking about ones that arent included with rockbox 04.43.56 # okay, that's prettymuch what my question was, sorry if it went a little offtopic 04.45.21 # Llorean: if you buffer during a track, that track will be truncated up-to it's playing point 04.46.32 # lostlogic: Alright then, I maintain my statement that "if only a small amount of data needs to be buffered, you probably don't yet have a 'last track' on buffer to lose" :-P 04.46.37 Join ramon8 [0] (i=DontFuCk@adsl-71-146-171-171.dsl.pltn13.sbcglobal.net) 04.46.39 # Just seek-back within the current one. 04.47.48 # well as long as I have a plan b for an open source media player, may be back sometime soon. cheers :P 04.47.52 Quit a11313 ("Java user signed off") 04.47.55 # * safetydan wonders with we need big blinking red letters on the frontpage that say "Rockbox is not Linux" 04.48.11 # Clearly we need a recursive acronym. 04.48.29 # :) 04.48.39 # Though if we started doing that we'd end up with a lot of blinking messages, e.g. "Rockbox is not Linux", "Rockbox will not run on the iPod Classic", etc. 04.48.59 # i will never understand all those who think you can ever just drop something on a different device and have it *just work* 04.49.08 Quit scorche|w ("CGI:IRC (Session timeout)") 04.49.15 # about time! 04.49.31 # Like those people who wanted to know which file from an N64 emulator they needed to put in the rocks folder to have it run? 04.49.58 # there are many different types of those people, but they all have that underlying theory 04.50.17 # * scorche boggles 04.50.27 # Can I run rockbox on my laptop???? 04.50.33 # When will rockbox have wifi support??? 04.50.36 # Does it make pizza/?? 04.50.37 # you mean i cant run my exe files on rockbox? dangit ;) 04.52.17 Quit sounddude (Read error: 110 (Connection timed out)) 04.52.24 Join sounddude [0] (n=sounddud@d207-81-127-76.bchsia.telus.net) 05.01.12 # Llorean: the better one was the guy who though because there was an arm version of firefox it would work on rockbox 05.03.14 # That was quite impressive, yes. :) 05.08.14 Join Mouser_X [0] (i=cf9bb003@gateway/web/cgi-irc/ircatwork.com/x-b4c7091fa67ed16f) 05.13.38 Quit markun (Read error: 104 (Connection reset by peer)) 05.15.43 Quit bb (Nick collision from services.) 05.15.48 Join bb_ [0] (n=bb@unaffiliated/bb) 05.18.59 Join ddalton [0] (n=daniel_r@203-214-86-100.dyn.iinet.net.au) 05.19.27 Part ddalton 05.23.27 # Nico_P: For your reference, http://test.lostlogicx.com/transfer/rockbox/logf_buffering_stuck.txt <-- a logf of playback and buffering leading up to a stuck buffer 05.23.38 # (I really hope that he will find all of these messages that I've left him in the logs) 05.23.52 # Helllo. Im Back. Installed Everything! yay! 05.24.07 Join markun_ [0] (n=markun@bastards.student.utwente.nl) 05.25.46 Nick markun_ is now known as markun (n=markun@rockbox/developer/markun) 05.29.10 Quit midgey () 05.37.10 Join n17ikh [0] (n=n17ikh@c-76-23-98-11.hsd1.sc.comcast.net) 05.38.20 Quit webguest82 ("CGI:IRC (Ping timeout)") 05.44.26 Quit n17ikh|Lappy (Read error: 110 (Connection timed out)) 05.56.20 Quit RaRe (Read error: 104 (Connection reset by peer)) 05.57.41 Quit rotator () 06.04.06 Quit psycho_maniac (" HydraIRC -> http://www.hydrairc.com <- In tests, 0x09 out of 0x0A l33t h4x0rz prefer it :)") 06.05.27 Join RaRe [0] (n=Laffin_B@202-89-187-101.static.dsl.amnet.net.au) 06.16.17 Quit Rondom (Read error: 110 (Connection timed out)) 06.17.13 Join Rondom [0] (n=Rondom@p57A9491F.dip.t-dialin.net) 06.18.41 *** Saving seen data "./dancer.seen" 06.21.25 Part safetydan 06.23.55 # do we support id3v2 on flac? 06.24.02 Quit Mouser_X ("CGI:IRC (EOF)") 06.25.18 # We only support vorbis comments, I believe 06.25.50 # afaik, we only support "native" tags for most formats, with ID3 (both v1 and v2) considered 'native' for MP3. 06.26.47 # I'm about to start re-ripping all of my music to flac so I can throw away my CDs (or at least not worry about them) 06.26.48 Quit Strath (SendQ exceeded) 06.27.07 # Vorbis comments are more flexible than ID3 anyway, I think. 06.27.34 # yeah, they're just a bit harder to get grip to write 06.27.45 # Ah, yes, grip 06.28.08 # also, flac is very fast to decode, even from --best right? 06.28.29 # On coldfire, I believe it's a 0% boost ratio no matter which compression level you use. 06.36.49 # wow, encoding is very fast too... barely takes one core to keep up with ripping. 06.37.00 # ogg encoding takes both cores to keep up 06.38.38 Quit lazka (Remote closed the connection) 06.40.22 Join Mouser_X [0] (i=cf9bb003@gateway/web/cgi-irc/ircatwork.com/x-a405e8ee29bc4f0c) 06.42.06 Join advcomp2019_ [0] (n=advcomp2@unaffiliated/advcomp2019) 06.42.48 Quit advcomp2019 ("Leaving") 06.43.35 Nick advcomp2019_ is now known as advcomp2019 (n=advcomp2@unaffiliated/advcomp2019) 06.47.31 Join cabose61088 [0] (i=42702b8a@gateway/web/cgi-irc/labb.contactor.se/x-60243db040918cdf) 06.47.44 # ello 06.48.37 # i was wanting to know if there is any way possible that there is a couple hacks for the ipod nano 2g 06.49.39 # Well, maybe if you aim well enough, you could get a couple of hacks in with an axe. However, the iPod nano is pretty small. You'd have to be pretty precise. 06.49.56 # Other than that, I'm really not sure what you mean... 06.49.56 # cabose61088: The front page of the site says, fairly clearly, that the Nano 2G is not supported. 06.50.02 # lol 06.50.29 # i know that rockbox doesnt support it i was just wondering if there was any out there any where 06.50.51 # and to also ask what language rockbox is written in 06.50.55 # you're in the wrong channel to ask about that, really 06.50.58 # C and assembly 06.51.15 # * karashata needs to type faster... 06.51.21 # lol 06.53.51 # where do i find the source code for it since its open source 06.54.16 # im in college for computer programming so i wanted to take a look at it to see if i understand any of it 06.55.51 # Check the wiki: SimpleGuidetoCompiling (something like that) 06.56.01 # kk 07.02.28 Quit jhulst (Read error: 113 (No route to host)) 07.05.46 Quit Calcipher ("—I-n-v-i-s-i-o-n— 2.0 Build 3515 with A Pack Fix By www.ircmadeasy.com") 07.21.03 # Llorean: I do *not* want the anti-skip buffer banished. I just want it to work properly on all targets, with the lowest setting being 0. 07.21.28 # Right now this is only true for hwcodec 07.23.53 # The anti-skip buffer isn't meant for working around rockbox bugs wrt low watermark calculation, but for using the (hdd based) dap in a shaky environment, where the hdd might take longer for reading data 07.27.07 # amiconn: Ah, I thought I remembered you saying it was "unnecessary" but I could've misremembered. 07.27.49 # It is unnecessary on any flash based target 07.28.46 # Ah 07.39.34 Join tpickers66 [0] (n=chatzill@82-69-41-162.dsl.in-addr.zen.co.uk) 07.39.58 Quit tpickers66 (Client Quit) 07.42.41 # JdGordon: around? 07.46.50 Quit kubiix ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 07.47.52 Quit zicho (Remote closed the connection) 07.52.37 # amiconn: hey 07.56.10 # Llorean: time to delete the archived threads forum? 07.56.29 # I cant imagine there being any useful threads in there still 07.58.10 # JdGordon: There is a fundamental problem with the read-only lists (e.g. the info screens in debug you converted to lists) on targets with small displays (Player, other archoses when selecting a large font) 07.58.41 # The read-only lists don't have any scrolling lines. That makes e.g. the disk info screen completely useless on the player 07.58.56 # You can see what values it reads, but never the actual values... 07.59.14 # well... 2 options... 07.59.16 # Only noticed it now because the debug menu is rarely needed these days on archos 07.59.22 # either we enable scrolling on all lines 07.59.31 # or we enable the selection line so it can scroll 08.00.04 # I don't really like either option, at least on player 08.00.11 # or maybe we force the cursor instead of the line so its not so in-your-face? 08.00.45 # Otherwise I'd think all lines should scroll in read-only lists 08.00.59 # all lines scrolling is difficult to read imho 08.01.13 # but yeah, there may not be a better way to do it 08.01.38 # On Player, the old layout was rather nice, with the parameter currently displayed shown at the top line, in brackets, and the bottom line showing the actual contents/value, scrolling when longer than that line 08.02.12 # Hmm, we do have two-line info lists, don't we? 08.02.45 # yeah, the partitions screen is 2 line 08.02.49 # Hmm, that probably wouldn't be that nice for other targets 08.03.30 # I can see how having it split over 2 lines would be much better on player, but wouldnt work so well on larger displays 08.03.50 # yes 08.04.05 # And the ID3 viewer has kinda the same problem (it is currently 2-line iirc) 08.05.10 # viewports would be nice here... have each line split in 2, so the "data" bit scrolls but the "title" doesnt 08.05.26 # We should have a dedicated info list thingy, which would take the parameter names and values as separate items, and then either switch dynamically based on font, or the two-line layout selected permanently (player) 08.06.08 # Yes, viewports would even improve that, with all values in a separate colum for larger displays 08.07.55 # (larger displays and/or small fonts, of course) 08.08.03 # well.. a info list thingy widget could be added to the list semi easily i tihnk 08.08.21 # And yes, the id3 viewer is 2-line, and it shows the selector... 08.08.23 # but im not sure how much better it would look than the current 2 line view 08.09.27 Quit cabose61088 ("CGI:IRC (Ping timeout)") 08.10.47 Join hannesd_ [0] (n=light@gate-hannes-tdsl.imos.net) 08.10.53 # Hmm, that needs more thinking... 08.12.02 # it may be possible to keep the selection correclty without showing the selection 08.14.16 Join norbusan [0] (n=norbusan@chello213047086216.5.14.tuwien.teleweb.at) 08.14.20 Part norbusan 08.15.06 # where the heck is the id3 info screen code? 08.18.44 *** Saving seen data "./dancer.seen" 08.25.21 Quit BigBambi (Read error: 113 (No route to host)) 08.25.52 Nick bb_ is now known as bb (n=bb@unaffiliated/bb) 08.26.36 Quit hannesd (Read error: 110 (Connection timed out)) 08.26.37 Nick hannesd_ is now known as hannesd (n=light@gate-hannes-tdsl.imos.net) 08.26.51 Join Rob222241 [0] (n=Miranda@p54B17638.dip.t-dialin.net) 08.28.12 Join ender` [0] (i=krneki@84-255-206-8.static.t-2.net) 08.32.25 Quit Mouser_X ("CGI:IRC (Ping timeout)") 08.38.59 Join ackbahr [0] (n=ackbahr@d213-103-137-66.cust.tele2.ch) 08.43.54 Quit Rob2222 (Read error: 110 (Connection timed out)) 08.45.20 # amiconn: Just read your request from last night looking for a 5g tester. I can't do it immediately, but what do you need? 08.46.00 # A series of experiments with bcm commands, and with the method of writing data into its internal memory 08.46.19 # That *might* be different for G5s with hw_rev < 0xb0010 08.46.35 # Which OF did you look at, the 5.5g? 08.46.42 # But I don't have much time now either. Will you be around tonight? 08.46.45 # yes 08.46.51 # Yes, I should be. 08.46.52 # Or rather, still the rom 08.47.22 # I want to get a better understanding of how the bcm works 08.47.54 # With some magic it will be possible to eliminate the 14 ms wait while still using just the bcm rom firmware 08.48.18 # But is that 14ms wait a problem in practice? Does Rockbox attempt to update the screen that frequently? 08.48.47 # Yes, when the updates are small 08.48.52 # On a different matter - did you already look into replacing the range decoder in libdemac? 08.49.14 # I started looking, but didn't get very far. It's still a mystery to me... 08.49.35 # I couldn't immediately see much in common between the existing range coder and the one in ffmpeg. 08.49.45 # But I haven't given up. 08.49.46 # I am doing a quick test of entropy-only decoding on PP - and the entropy decoder is around 80% of the total decoding time on PP5002... 08.50.09 # Ouch... 08.50.26 # But looking at the code, it's not surprising - it does a lot per sample. 08.50.37 # That means the predictor + decorrelation is just 20% 08.51.05 # And speeding up the entropy decoder is *the* key to getting ape realtime on PP 08.51.23 # I don't think it's working in IRAM either... 08.51.24 # (or *usable*, as it already is barely realtime for -c1000 on PP502x) 08.52.16 # For PP5002 it also pays of to put code into iram 08.52.18 Quit ackbahr (Read error: 104 (Connection reset by peer)) 08.52.24 # *off 08.55.12 # Oh, and btw, asm'ising the mono predictor should help a bit too, as it is sometimes used in stereo files iiuc 08.56.10 # That's true. 08.56.12 Join safetydan [0] (n=safetyda@rockbox/developer/safetydan) 08.56.58 # On PP5002, the entropy decoding is ~77% of the total decoding time 08.57.16 # (those figures are without filtering, i.e. -c1000) 08.57.44 # Do you mean PP5022? You just said PP5002 was 80%. 08.57.44 # And on coldire, it's ~75% 08.57.55 # Eh, I meant 5020 08.57.59 # (tested on H10) 08.59.00 Join petur [0] (n=petur@rockbox/developer/petur) 09.00.28 Quit karashata ("Leaving.") 09.11.31 Join pondlife [0] (n=Steve@rockbox/developer/pondlife) 09.12.48 # linuxstb: On PP5002, even just running the entropy decoder isn't realtime: 80% on average (only minor differences between -c levels). On PP5020 it's 148% on average 09.16.07 # Let's hope we can find some magic... 09.16.38 # The 80% is due to the cache latency with code running from dram 09.16.52 Join Zagor_ [0] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) 09.16.58 # Putting the time critical routines into iram for PP5002 should fix that 09.17.16 Nick Zagor_ is now known as Zagor (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) 09.17.18 # But even then we need a faster entropy for everything PP... 09.17.25 # *entropy decoder 09.19.40 # pft, you and your ape 09.20.23 # preglow: It's a challenge... 09.22.00 # so is faad :P 09.23.36 # bah, aac 09.24.52 Join JdGordon|DS [0] (n=jdgordon@c210-49-113-143.smelb1.vic.optusnet.com.au) 09.24.53 # preglow: BTW, the Gigabeat S is armv6... 09.25.39 # (as if a vector FPU and 500+MHz wasn't enough) 09.25.40 # amiconn: you're working on ape, you don't get to diss aac :P 09.26.49 Join B4gder [0] (n=daniel@rockbox/developer/bagder) 09.28.27 Join pixelma [0] (i=pixelma@rockbox/staff/pixelma) 09.32.10 # aac is a pretty decent codec anyway 09.32.54 # linuxstb: having that gigabeat s cpu kinda makes the entire optimizing deal somewhat demotivating... 09.33.40 # Yes, it's hard to think of tasks it will struggle with... 09.35.07 Join roolku [0] (n=roolku@82-41-2-141.cable.ubr01.edin.blueyonder.co.uk) 09.39.36 Quit ramon8 (Read error: 110 (Connection timed out)) 09.41.26 Join lee-qid [0] (n=liqid@p549670EE.dip.t-dialin.net) 09.42.03 # preglow: the runtime with the OF is pretty bad, I'm sure that could be a motivation for some. 09.42.26 # how bad? 09.43.43 Join davina [0] (n=davina@cpc1-sout6-0-0-cust616.sotn.cable.ntl.com) 09.46.16 Join LinusN [0] (i=linus@rockbox/developer/LinusN) 09.48.59 # Around 12 hours for audio 09.49.54 Quit JdGordon|DS (Read error: 110 (Connection timed out)) 09.51.07 # Well, it's running Windows.... 09.51.40 # I would hope just a simple port of Rockbox with no specific optimisations would beat that. 09.52.40 # I guess it does 09.54.33 Join jmspeex [0] (n=jmspeex@142.163.233.220.exetel.com.au) 09.58.24 Join ditguy [0] (i=c27f0814@gateway/web/cgi-irc/labb.contactor.se/x-fbf960c09bf6ecce) 09.59.25 # Hello. Is there a wiki page or some other resources explaining what the dithering in RB is for and when it should be used? 10.01.09 # Ah, the manual has something about it but what would a "normal person" use? 10.01.42 # And what impact does it have on cpu usage (and hence battery life)? 10.03.44 # ditguy, it will have some impact on CPU usage. All DSP effects do. So yes your battery life will be affected. Normal people probably won't notice any difference in sound quality with dither on. 10.04.44 # Does anyone (apart from me) wish to see the Track Properties option in the browser context menus? 10.05.18 # ditguy: normal people wouldn't need it 10.05.26 # I'd think that's a valid UI option whenever you have a particular track selected, not sure how easy it would be to implement though. 10.05.54 # pondlife: What about combining it with the id3 info screen? 10.06.09 # Ah, I thought that was the same thing 10.06.27 # ditguy: http://forums.rockbox.org/index.php?topic=7179 10.06.28 # I thought by "track properties" you mean the file properties plugin. 10.06.31 # I'm talking about the screen displaying tags - under Show Track Info 10.06.43 # ditguy: that thread has some more info, plus an exaggerated sound sample 10.06.44 # Nope, the built-in track info 10.07.12 # pondlife: OK, I'm confused, I was thinking you wanted file properties in the WPS, but you want the id3 info in the file/db browser... 10.08.01 # Yes. The same ID3 info as is currently in the WPS context menu, to be in the browser menu (albeit only when a supported file type is selected?) 10.08.26 # What about adding that as an option in the file properties plugin? 10.09.29 # The properties plugin isn't in the context menu either, is it? 10.09.57 # it is 10.09.57 # It is. 10.09.59 # Currently, I only get Playlist in my context menu 10.10.08 # you in db browser? 10.10.11 # Yes 10.10.16 # there you go then :) 10.10.24 # Why does it matter? 10.10.34 # i tinhk its because the db doesnt work with filenames easily or something 10.10.46 # Each entry must resolve to a file... 10.11.00 # well yeah... but... 10.11.22 # Adding the file-based options to the db browser would seem to make sense... 10.11.23 # I can understand suppressing file operations (Rename/Delete) 10.11.43 # (apart from those...) 10.11.48 # I disagree... I tinhk properties shouldnt be in the db browser 10.11.49 # Cut + paste 10.11.56 # but by all means, add id3 to both browsers 10.12.31 # Why not Playlist Catalog, Properties and Add to shortcuts? 10.12.42 # I don't know what PC and ATS do.. 10.12.50 # * pondlife overuses TLAs 10.13.09 # shortcuts wouldnt work as expected i tinhk... 10.13.21 # wont it goto the filebrowser instead of the db browser? 10.13.26 # Nope, sounds very file systemy 10.13.48 # * linuxstb wonders why the file properties plugin displays info on a single line (key: value), but the id3 info screen uses double-lines. 10.13.51 # I never realised we have separate file and an ID3 properties pages 10.14.23 # I only ever used the nice 2-line ID3 one 10.14.39 # linuxstb: amiconn and i had a bit of a chat about doing both of those properly.. possibly modifying the list widget to be used as a info list and reformat depending on the screen space 10.14.59 # * JdGordon doesnt really like the 2 line display 10.15.29 # * JdGordon also plans to do that properly after tomorows exam 10.15.44 # I prefer it to the single one, clearer to read 10.16.44 # Maybe my font is larger than most though 10.17.37 # I don't normally suggest this, but would an option make more sense than trying to guess what looks better automatically? 10.17.58 # probably 10.18.20 # This could all be included in the properties plugin, right? 10.18.43 # So no bloat in the core, in fact we could perhaps remove the ID3 viewer from the core... 10.18.48 *** Saving seen data "./dancer.seen" 10.18.54 # Or is the plugin loading spinup a problem. 10.18.55 # the quick play i had before was modifieng the simplelist widget to handle it, so yeah shouldnt be a problem adding it to plugins 10.19.17 # I don't really like the plugin loading delay. 10.19.54 Quit TMM (Read error: 110 (Connection timed out)) 10.20.09 # * linuxstb wonders if some functionality could be built into the core, or as plugins, depending on RAM size 10.20.30 # * JdGordon was thinking the same 10.20.37 # dpesnt sound very KISS though 10.21.12 # Better than keeping the last plugin loaded or whatever was suggested last time we had this conversation. 10.21.20 # linuxstb, I can't reproduce the gain reset issue you saw with FS#7440 in the sim. The code for the setting is very simple so I've got no clues to go on for fixing it. 10.21.49 # pondlife: ? that sounds like a good way of stopping your complaint about load times 10.21.54 # if you keep runing the same plugin 10.22.06 # Well, yes. But far from KISS 10.22.24 # not at all 10.22.30 # Is the plugin buffer used for anything else? 10.22.35 # safetydan: I had a quick look at the wm*.c file, and it seems it wasn't remembering the gains when setting them. 10.22.43 # i.e. is it wasted space when not running a plugin? 10.25.35 # linuxstb, hrm... the "extern current_bass" is supposed to take care of that... 10.25.52 # * preglow ponders attempting to make speex encoding work... 10.26.22 # pondlife: the plugin buffer is "wasted" unless something else grabs it (like the playlist viewer).. but its easy to manage that so we know if it was stolen or not 10.26.35 # * JdGordon actually isnt 100% sure we dont do that 10.26.47 # OK, so there's no need to reload the last plugin from disk (assuming no steal) 10.27.09 # preglow: thanks for the link! It has a really nice explanation of what dithering is! 10.27.15 # safetydan: Why is that extern? 10.27.44 # linuxstb, the actual value is in firmware/sound.c 10.27.44 # And as for the context menu in the DB browser: I'd like if it contained 'properties' and 'add to favorites' 10.28.29 Join rep|icant [0] (n=rep|ican@adsl-074-183-167-249.sip.bhm.bellsouth.net) 10.28.47 # Add to favorites? Is that Playlist Catalog? 10.29.00 # pondlife: IIUC, if the plugin contains initialised data, it needs to be reloaded. 10.29.22 # Ah, yes. That's an assumption many plugins make, I expect 10.29.47 # But given how small most of the plugins are, maybe a plugin cache... 10.30.08 # pondlife: no, it's the shortcuts plugin 10.30.18 # pondlife: the 'add' part of it 10.31.18 # seems mp3_encoder is broken on iriver 10.35.04 Quit rep|icant_ (Read error: 110 (Connection timed out)) 10.35.18 # preglow, there was a flyspray issue raised at some point 10.35.39 # well, that's how i found out, so yeah 10.35.44 # thought i'd investiagte 10.35.52 # it's not any coldfire specific code's fault 10.36.02 Quit TotallyInfected () 10.36.14 # safetydan: I'll try and debug your patch on my 5g at some point. 10.37.04 # linuxstb, cheers. I'm sure it's something simple, but it's hard without the hardware. 10.38.00 # * JdGordon thinks all plugins should do a reset in plugin_entry so we can save loading 10.39.29 # Aside from properties, are there many plugins that are likely to be unloaded then reloaded? 10.39.31 # anyone know if any of the plugin libs stuff has static variables which would need reseting? 10.40.47 # properties looks like it has 1 variable which would need resetting... 10.42.38 # JdGordon: I think many plugins have static vars which would need resetting. Plugings are written in a non reentrant way. 10.43.08 # yes, but there isnt a reason why they couldnt be reset on load... 10.43.14 # * linuxstb wonders how complex it would be to cache the .rock at the end of the plugin buffer, given the fact most plugins are very small and don't call plugin_get_buffer() 10.43.22 Quit parafin|sleep (Read error: 113 (No route to host)) 10.43.34 Join parafin|sleep [0] (i=parafin@parafin.dialup.corbina.ru) 10.44.08 Join barrywardell [0] (n=barrywar@194.46.162.79) 10.44.09 # I was tihnking having an extra return value from the plugin which meant it was safe to reload the plugin from ram 10.44.16 # I tihnk that would be less complicated 10.44.36 # But that would build complication into any plugin that we wanted to use this feature with. 10.44.46 # Rather than being automatic. 10.44.46 # JdGordon: but how would you do it? That would require rewriting (or adding a reset func) to each plugin since you can't write a general routine for that 10.44.57 # but as pondlife said.. it would only be used really for properties... 10.45.12 # I was more thinking it wasn't really worthwhile complicating for... 10.45.29 # ditguy: we have a plugin entry point already... if a plugin wanted the ability it could add it... 10.45.32 # Rather, I'd consider if file properties could be built-in. 10.45.40 # i.e. combined with the ID3 info 10.45.54 # na... move id3 out and allow this reloading stuff in... 10.45.58 # free up some bi space 10.46.18 # it _might_ give us more leeway to move stuff to plugins... 10.46.24 # mp3_encoder can be used as both a plugin and viewer, why doesn't it show up in the plugin menu? 10.46.26 # pondlife: The file properties plugin probably needs to spin up the disk to read info from the file anyway... 10.46.28 # preglow: I think they get about 12 hours, -6 hours if you enable "harmonics" 10.46.31 # As long as the freed space isn't reused for the reload code 10.46.45 # I like the idea of linuxstb (keeping the original .rock at the end of the plugin buffer.) If the plugin is small enought we could reuse its binary image. If it's big it will be reloaded. All transparent and requires no plugin rewrites. 10.46.49 # linuxstb: Ah, the ID3 info doesn't of course ... 10.46.58 # pondlife: it doesnt? 10.47.03 # Not for the currently playing track. 10.47.11 # Indeed. 10.47.13 # all oter tracks it does though 10.47.34 # You can't use it for other tracks 10.47.36 # But that's what started this conversation - currently you can't view id3 info for anything other than the current track. 10.47.43 # That was my complaint 10.48.16 # Now I see why - so we just need to build ID3 info into the File Properties plugin and make them share UI (and code?). 10.48.28 # Then add it to the DB context menu and I'll be done 10.49.25 # ok, the plugins are tiny compared to the pluginbuf size (expect maybe archos?) linuxstb's idea is sounding doable 10.49.59 Quit parafin|sleep ("So long and thanks for all the fish") 10.50.03 # I'm not convinced my idea is good though - is it very common to load the same plugin twice, without also needing to spin the disk (i.e. viewers) 10.50.19 Join parafin|away [0] (i=parafin@paraf.in) 10.50.21 # games? 10.50.31 # we arnt talking twice immediatly... 10.51.10 # I'm just questioning the need for the feature... 10.51.46 Join karashata [0] (n=Kimi@207.35.118.181) 10.52.03 # I'd say we don't need it 10.52.06 # there is no need really... iits an extra bit of complexity for something which would be nice to have 10.52.07 # linuxstb: but keeping the .rock would do no harm 10.52.23 # it adds code 10.52.27 # it still potentially saves 1 big disk read 10.52.28 # B4gder: he-he, same thinking :-) 10.52.35 # JdGordon: Given that a spinup is needed for the file properties anyway, it's not worth it 10.52.56 # Properties and 'add to shortcuts' are good examples 10.53.05 # * JdGordon only uses flash targets atm so this whole thing is irrelevant anyway :p 10.53.09 # Properties needs a spinup anyway 10.53.17 # add to shortcuts too, I expect 10.53.29 # yeah shortcuts needs a file 10.53.38 # s/needs/opens 10.53.40 Join PaulJam [0] (i=PaulJam_@vpn-3125.gwdg.de) 10.53.41 # pondlife: but it would be still less disk IO 10.53.56 # isnt open() the really slow part of the access? 10.54.18 # ditguy: The spinup cost is the main one by a long shot 10.54.39 # Once you've had to do that, the i/o is cheap 10.55.24 # actually... what would be nice is if we could use the plugin buffer as a second codec buffer 10.55.26 # pondlife: ah... I though open() was also expensive (all that fat seeking) 10.56.45 # Not relative to the spinup. And properties will also need to open the file. 10.57.03 # yeah, but 1 open() is betteer than 2 10.57.26 # JdGordon: and two e are better than one :-))) 10.57.49 # JdGordon: Maybe you could write a little patch that logs which plugins have been opened, and check your usage pattern after a week... 10.58.28 # linuxstb: btw, I looked at the "unencrypted" Clix2 firmware again last night and did find some interesting patterns. 10.58.29 # ... if the plugin is in ram then call disk_wakeup(), then start the plugin which might speed it up a tiny bit 10.58.45 # linuxstb: thats easy.... brickmania once in the whole week.. and thats it :p 10.58.48 # linuxstb: there is 1 256bytes block which can be found throughout the firmware 10.59.31 # I xorred the firmware file with this block, but that didn't do the trick (although there are a lot of 00's now 11.00.44 # JdGordon: did you see any problems with my changes? 11.00.58 # not that i remember :p 11.01.07 # i was a bit asleep when i looked at it this morning 11.01.09 # you guys seen http://www.slashgear.com/sandisk-8gb-microsdhc-compatibility-test-278204.php ? 11.01.25 # okay, I'll go for it then 11.02.19 # daurnimator: haha, crappy stuff... 11.02.34 # * preglow finds the bug 11.02.35 # argghgh 11.02.43 # looks like memcpy is called before rb = api 11.03.54 Join Thundercloud [0] (n=thunderc@resnet14.nat.lancs.ac.uk) 11.03.54 # * linuxstb is curious about this MS lossless codec - http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/proceedings/&toc=comp/proceedings/dcc/2007/2791/00/2791toc.xml&DOI=10.1109/DCC.2007.51 11.03.57 # Anyone out there who uses oggs able to test a patch for me? http://www.rockbox.org/tracker/task/8048 is a two-liner to get rid of that annoying yellow in ogg_malloc_init(). 11.04.34 # ehrm 11.04.39 # I'd think the sansas would support the 8gb overlords? 11.04.48 # have anyone tried encoding mono files with mp3_encoder before? 11.04.58 # daurnimator: I'd guess rockbox does, yes 11.05.37 # will be tricky filling them without rockbox-native usb though... 11.05.52 # * JdGordon has a micro sdhc usb reader :) 11.05.52 # memory card reader 11.06.01 # yeah 11.06.06 # so eyah.. buy me a 8gb chip and l test it :D 11.06.08 # the result is sped up by a factor of two here... 11.06.10 # but that's cheating :) 11.06.21 # but yeah. it requires that the external reader groks it too 11.07.52 # JdGordon: do you still use your sansa? 11.08.06 # pondlife: is that patch either it works or doesnt? 11.08.12 # daurnimator: yeah, sitll my main dap 11.08.23 # JdGordon: I think so, but I don't have any oggs 11.08.39 # ok, ill try the patch and tell you if something funny happens 11.08.46 # do you know what i shuold look out for? 11.09.04 Quit barrywardell () 11.09.13 # With the current codec swapping problems you might need to compare before and after 11.10.10 # I don't think it'll break anything, but there's a very small chance of an overflow (long -> size_t) on 64-bit sims 11.10.41 # and of course by small you mean certain :) 11.10.49 # test on the player or sim? 11.10.56 # Both? 11.10.57 # weirdness. changing the UNCACHED_ADDR define from + to | causes gcc to claim "error: initializer element is not computable at load time" 11.11.06 # Player is more important, of course 11.11.36 # why is | any more difficult than + ? 11.11.52 # pondlife: codec failure in the 64bit sim 11.12.01 # Wow 11.12.11 # linuxstb: eyh, since you did test_codec and everything, what about making a transcoder plugins? :> 11.12.18 # JdGordon: Are you sure that's this patch? 11.12.21 # -s 11.12.22 Quit ditguy ("CGI:IRC") 11.12.27 # pondlife: nope 11.12.34 # Try without too.. 11.12.37 # ... checking on the dap 11.12.43 # Maybe I should hunt for an ogg on the web 11.12.57 # preglow: Sure, I've nothing else to do... ;) 11.13.38 # btw, can one do string comparisons with the preprocessor? 11.13.41 # pondlife: dcc? 11.13.56 # #if STRING_DEFINE != "", for eaxmple 11.15.19 # preglow: Should be easy to test - add a #warning to see if it tests true or not. 11.15.28 # it doesn't even compile... 11.16.00 Part pondlife ("Gone") 11.16.19 # token ""/"" is not valid in preprocessor expressions 11.16.30 # STRING_DEFINE is "/" 11.17.11 Join barrywardell [0] (n=barrywar@194.46.162.79) 11.17.22 # preglow: http://www.thescripts.com/forum/thread221655.html 11.17.47 # just found it :) 11.18.00 # and btw, why doesn't recorded stuff end up in /recordings anymore? 11.18.52 # preglow: you can set the recorcing dir via the contextmenu of folders now 11.18.53 # It's wherever you set it to be 11.19.12 # i've never set it to / 11.19.24 # it's always been /recordings by default, now it's / 11.19.25 # You've never not set it to /... 11.19.33 # and REC_BASE_DIR is defined to be "/" 11.20.02 # stuffing things in the root seems a bit dirty 11.20.09 # preglow: that changed AGES ago... 11.20.17 # didnt you help test that patch? 11.20.32 # it's because you can't "choose" root as recording directory by other means 11.20.48 # * linuxstb knew there must have been a good reason for it... 11.21.11 # JdGordon: doubt it 11.21.42 # mp3_encoder bugs because it doesn't expect REC_BASE_DIR to be / 11.21.49 # so it lists all files in the root twice 11.22.16 # mp3_encoder should use the setting... 11.22.27 # plugins have access to settings? 11.22.38 # rb->global_settings-> ... 11.22.39 # i guess they do 11.23.03 # Couldn't it just create a .mp3 with the same name and in the same place as the .wav? 11.23.08 Quit J3TC- (Read error: 113 (No route to host)) 11.23.20 # encoding and recording aren't the same in my mind... 11.23.26 # linuxstb: it does 11.23.37 # What's the problem then? 11.23.37 # linuxstb: it's for choosing a wav when called as a plugin 11.23.51 # Why would it need to be called as a plugin? 11.24.05 # i have no idea, it's always been like that 11.24.12 # shall i just gut that code out? 11.24.15 # Can it encode multiple files? 11.24.21 # i don't think so 11.24.44 # Unless you can think of a reason for it to be different to other viewers, then yes, I would say gut it. 11.25.22 Join pondlife [0] (n=Steve@rockbox/developer/pondlife) 11.25.25 Part pondlife ("Gone") 11.25.25 Join spiorf [0] (n=spiorf@host13-223-dynamic.1-79-r.retail.telecomitalia.it) 11.25.28 Join pondlife [0] (n=Steve@rockbox/developer/pondlife) 11.26.44 # consider it done 11.28.04 # it also assumes a max mp3 file name of 80 chars 11.28.06 # ahaha 11.29.06 # i can't be bothered to fix that, we should just do a transcoding plug 11.29.49 # JdGordon: Can you try a one -line mod for me? 11.30.17 # JdGordon: Change ogg_malloc_init() so the tmp_ptr setting is tmp_ptr = (long) (bufsize + 3) & ~3; 11.30.57 # the fact that it encodes my file at double speed i shall also ignore 11.31.59 # pondlife: file, line? 11.32.15 # JdGordon: The routine I patched ;) 11.32.24 # I'll make a new patch if you prefer 11.32.39 # bah, na ill manage 11.33.06 # Just the +3 bit to add 11.33.07 Quit barrywardell () 11.33.29 # yep, found it 11.33.59 # still codec failure 11.34.08 # OK, I'll forget it then 11.34.14 # Too much else to do, sorry 11.35.06 Part pondlife ("Gone") 11.36.51 Join Echelon [0] (n=SweetOne@pennilesshost.com) 11.43.04 # we're being watched!!!1 11.43.17 # Dang, I use that as a nick sometimes... :( 11.43.33 # In fact, my windows xp account is called Echelon.. lol 11.50.23 # preglow: Rather than a general transcoding plugin (with the complication of swapping the codecs), an encoder plugin similar to test_codec might be relatively easy. 11.50.58 # I don't know how the recording codecs work though... 11.51.04 # me neither 11.51.11 # but that encoder plugin would only read wavs, then? 11.51.25 # Yes. 11.51.27 # sure, leaps and bounds better than what we do now 11.51.40 # bolting on input codec support can be done later anyway 11.52.00 # but this maintaining an encoder plugin and encoder codec which is essentially the same code is silly 11.52.02 Quit Echel0n (Remote closed the connection) 11.53.07 Quit jhMikeS (Nick collision from services.) 11.53.12 Join jhMikeS [0] (n=jethead7@rockbox/developer/jhMikeS) 11.53.26 # * linuxstb spots someone who knows how the recording codecs work... 11.54.04 Quit spiorf (Remote closed the connection) 11.56.41 # god, i love the apple fanboys that can't understand why anyone would want to crack an iphone 11.58.26 # hehe 11.58.49 # Presumably they're not Rockbox users? ;) 12.01.56 # presumably they're twits 12.13.27 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 12.15.45 Join Nico_P [0] (n=nicolas@rockbox/developer/NicoP) 12.18.49 *** Saving seen data "./dancer.seen" 12.19.21 # Zagor: '+' means a fixed offset, '|' does not 12.20.04 Join moos [0] (i=moos@m147.net81-66-159.noos.fr) 12.21.49 Join rep|icant_ [0] (n=rep|ican@adsl-074-183-167-249.sip.bhm.bellsouth.net) 12.27.01 Join webguest68 [0] (i=7a691c82@gateway/web/cgi-irc/labb.contactor.se/x-afeab35e113d26b2) 12.27.07 # hi 12.27.27 # can anyone help me? 12.27.52 # hellllo 12.28.01 # that depends on the problem. just ask 12.28.50 # preglow: Do you think it's worth spending any time on faad, or should we keep waiting for ffmpeg? I'm thinking it could be simplified, first by stripping out all the unused code (i.e. everything in undefined #ifdefs, plus maybe more), and then seeing if it could be restructured. Seeing how the ffmpeg and helix codecs are structured might help with that. 12.28.55 Join midgey [0] (n=tjross@westquad-188-67.reshall.umich.edu) 12.28.56 # ok i just installed rockbox 12.29.04 # On what? 12.29.05 # i restarteed my ipod nano 12.29.05 Join J3TC- [0] (n=jetc123@dhcp78-54.njit.edu) 12.29.17 # and nothing happend 12.29.20 # it loaded normaly 12.29.39 # Did you run ipodpatcher? Or install the bootloader via Rockbox Utility? 12.30.07 # rockbox ultility 12.30.54 # When you did the bootloader installation, did you see a message saying it had worked? 12.31.07 # yes 12.31.14 # and then it told me to choose a theme 12.31.18 # i installed that also 12.31.25 # How are you restarting your Nano? Are you holding MENU+SELECT together? 12.31.48 # yes 12.31.58 Quit safetydan ("Leaving") 12.32.24 Quit rep|icant (Read error: 110 (Connection timed out)) 12.32.26 # is there another way restarting? 12.32.29 # Then it seems the bootloader installation didn't work. Try it again. 12.32.38 # i unsinstall? 12.32.48 # im using ipodnano 1gen 12.32.53 # No, no need to uninstall everything. Just do the bootloader install step again. 12.33.43 # i tryed to install it agin 12.33.45 # And no, there's no other way to restart an ipod. 12.33.52 # using small instal 12.33.57 # and i get some http error 12.34.46 # oh it says my bootloader is already up to date do i click ok or ignore? 12.35.42 Quit iamben (Read error: 104 (Connection reset by peer)) 12.36.57 # shouldent it say loading firmware? 12.37.00 # on my ipod 12.37.05 Quit midgey () 12.37.27 # You should click ignore. 12.37.51 # ok its downloading something 12.37.56 # Your ipod won't display any messages, unless there is an error. It will just go directly into Rockbox (assuming the bootloader is installed correctly) 12.38.24 # it says installation success 12.38.37 # i restart my ipod now? 12.38.49 # Yes 12.39.09 # its restarting 12.39.13 # apple logo poped up 12.39.20 # same thing.... 12.39.47 # does rockbox work on nanos? 12.40.16 # Yes. If your ipod wasn't supported, Rockbox Utility wouldn't autodetect it. 12.40.25 # And the bootloader install would give an error. 12.40.29 # ok what should i do 12.41.01 # is there suppose to be another theme? 12.41.02 # I don't know... You could try running ipodpatcher instead - instructions and links are in the manual. That's an alternative way to install the bootloader. 12.41.24 Join barrywardell [0] (n=barrywar@dhcp-892b9b55.ucd.ie) 12.41.27 # linuxstb: i was planning on finding out, waiting to see merbanan 12.41.37 # linuxstb: does it have much unused code, though? 12.41.45 # looked to me like it had everything needed and not much more 12.41.54 # it does deal with a lot of profiles we don't need, though 12.42.19 # There are a ton of #ifdefs, so I think it could be simplified. It wouldn't change what the compiled codec looks like, just make the source much simpler. 12.42.20 # i used ipodpatcher i installed it 12.42.33 # ok im going to try restartt 12.42.46 # YAYIT WORKED 12.43.39 # linux how do i load my old firmware after its on? 12.43.48 # linuxstb: ifdefs for what? 12.45.11 Quit SirFunk (Remote closed the connection) 12.45.13 # webguest68: there should be instructions in the getting started chapter of the manual 12.45.26 # preglow: The unsupported profiles. 12.45.46 # ok thanx 12.45.52 # preglow: Things that are undefined in common.h 12.46.12 # is rockbox suppose to be ugly? 12.46.21 # how would i change my background 12.46.25 # webguest68: Yes. But you can choose your own themes. 12.46.27 # ;) 12.46.41 # you can choose your own ugliness 12.46.57 # we worked hard to get it that ugly 12.46.58 # Although the default ugliness is hard to beat. 12.47.27 # lol 12.47.30 # uhh ok 12.47.47 # what do i do if my progress thing is not responding 12.48.31 # can i play gb games on this like iboy? 12.48.52 # * B4gder whispers rtfm 12.49.15 Join pondlife [0] (n=Steve@rockbox/developer/pondlife) 12.49.37 # anyone? 12.50.01 # you read the manual already? 12.50.31 # i read the quikstart 12.50.35 # it says nothing abt gb 12.50.36 # o.o 12.50.38 Join karashat1 [0] (n=Kimi@pool6-024.adsl.user.start.ca) 12.50.40 # webguest68: http://download.rockbox.org/manual/rockbox-ipodnano/rockbox-buildch9.html#x12-1800009.3.4 12.50.52 # well I won't say anything about it either ;-) 12.51.04 # if the quickstart contained everything, the rest of the manual wouldn't be needed, would it? 12.51.43 # ty im going sleep now 12.51.49 # sleep tight 12.52.00 Quit webguest68 ("CGI:IRC (EOF)") 12.52.25 Quit XavierGr () 12.52.39 # must have been very important if he wxpected it to be in the quickstart chapter... 12.52.42 Join XavierGr [0] (n=xavier@ppp25-208.adsl.forthnet.gr) 12.52.50 # *expected 12.53.52 # We obviously need a "Gaming quickstart" chapter... 12.54.18 # really important 12.54.39 # "You can play gameboy roms [...] and by the way, one minor function of rockbox is that it can play music" ;) 12.54.57 # :-) 12.55.25 Join karashat2 [0] (n=Kimi@pool1-181.adsl.user.start.ca) 12.57.42 Quit B4gder ("It is time to say moo") 12.58.26 Quit Weiss (Read error: 110 (Connection timed out)) 12.59.58 Join Joerg] [0] (n=chatzill@p5B0C9D83.dip0.t-ipconnect.de) 13.00.03 Quit J3TC- (Read error: 110 (Connection timed out)) 13.00.46 Join J3TC- [0] (n=jetc123@dhcp78-54.njit.edu) 13.02.01 Quit barrywardell () 13.02.06 Quit Joerg] (Client Quit) 13.04.52 Quit karashata (Read error: 110 (Connection timed out)) 13.05.32 Join mcuelenaere [0] (n=mcuelena@d54C5D879.access.telenet.be) 13.05.41 # hi 13.05.48 # could someone give me write access on the wiki? 13.06.20 # what is your wiki name? 13.06.41 # MaurusCuelenaere 13.07.05 Join rep|icant [0] (n=rep|ican@adsl-074-183-167-249.sip.bhm.bellsouth.net) 13.10.17 # mcuelenaere: done. 13.10.18 Quit mcuelenaere (Read error: 104 (Connection reset by peer)) 13.11.46 Quit karashat1 (Read error: 110 (Connection timed out)) 13.11.55 Join mcuelenaere [0] (n=mcuelena@d54C5D879.access.telenet.be) 13.11.58 # thanks! 13.12.39 # np 13.12.48 Quit mcuelenaere (Client Quit) 13.15.25 Quit rep|icant_ (Read error: 113 (No route to host)) 13.15.54 Quit Nico_P (Remote closed the connection) 13.16.49 Join Nico_P [0] (n=nicolas@rockbox/developer/NicoP) 13.17.39 # linuxstb: about the only thing i can see that currently would make faad a better choice than ffmpeg is that it supports aacplus 13.18.25 # Plus the fact that it works... 13.18.27 # anyway, i heard that faad now has changed their license again, and now to something more reasonable 13.19.24 # linuxstb: yeah, there's that 13.19.25 Join barrywardell [0] (n=barrywar@dhcp-892b9b55.ucd.ie) 13.19.55 # why do buschel's video speedup patches always end up lying around on the tracker? they seem like commit-right-away stuff to me 13.24.18 Join jay07 [0] (i=79ddc68d@gateway/web/cgi-irc/labb.contactor.se/x-5877f4ce67d86579) 13.24.36 # Hey i was wondering who coded rockbox? 13.24.39 # seems like faad still has the braindead clause 13.24.43 # jay07: lots of people did 13.25.15 # preglow: maybe he could have svn access (Buschel) 13.25.17 # jay07: the CREDITS file containing names of all contributors currently is 350+ names 13.25.19 # kewl... i want to know why its imposible to install firmware on the Nano Gen 2? 13.25.21 # moos: yeah, perhaps 13.25.44 # jay07: because the hardware is undocumented and the rom is encrypted, apple are trying hard to keep us from running our own code on it 13.26.01 # EVIL BASTARDS! 13.26.09 # this is the case for all their newer ipods 13.26.23 # they even glued the chips to the circuit board 13.26.34 # so i have to go out and source me a old ipod 13.26.37 # i can do that! 13.27.19 # sure 13.27.19 Quit jay07 (Client Quit) 13.27.31 # or you could buy something else than an ipod... 13.27.54 Quit J3TC- (Read error: 110 (Connection timed out)) 13.30.43 Quit animeloe ("This computer has gone to sleep") 13.33.39 # preglow: aacplus is realtime on the gigabeat F? 13.36.25 Join J3TC- [0] (n=jetc123@dhcp78-54.njit.edu) 13.37.49 # i think so, but dunno, really 13.38.13 # it should be possible to do realtime on ipods with a really, really optimized decoder 13.42.10 Join rep|icant_ [0] (n=rep|ican@adsl-074-183-167-249.sip.bhm.bellsouth.net) 13.46.31 Quit moos ("Glory to Rockbox") 13.49.57 Quit rep|icant (Read error: 110 (Connection timed out)) 13.54.33 # The H300 non-LCD remote has an odd keymapping. The long press on play brings up the pitch screen. On the main unit, this does nothing. 13.55.49 Join rep|icant [0] (n=rep|ican@adsl-074-183-167-249.sip.bhm.bellsouth.net) 14.01.44 # How do you bring up the pitch screen on the main unit? 14.02.05 # PLAY+UP/DOWN 14.02.12 # But it's broken after use of the remote 14.02.17 # I'm just logging a bug 14.02.39 # http://www.rockbox.org/tracker/task/8050 14.03.29 # I'd prefer the remote to have long play -> settings to be honest. But consistency would be a good second-best. 14.04.21 Quit rep|icant_ (Read error: 110 (Connection timed out)) 14.04.47 Join webguest17 [0] (i=53ed3d5a@gateway/web/cgi-irc/labb.contactor.se/x-3ce2a96a3b65cf4e) 14.05.36 Part webguest17 14.05.45 Join webguest55 [0] (i=53ed3d5a@gateway/web/cgi-irc/labb.contactor.se/x-125bebf0241ff8ab) 14.05.52 Quit webguest55 (Client Quit) 14.08.09 Join pixelma_ [0] (i=pixelma@212.204.47.129) 14.13.55 Join n1s [0] (n=nils@nl104-209-90.student.uu.se) 14.16.15 Quit pixelma (Nick collision from services.) 14.16.16 Nick pixelma_ is now known as pixelma (i=pixelma@rockbox/staff/pixelma) 14.18.52 *** Saving seen data "./dancer.seen" 14.22.02 Join webguest27 [0] (i=53ed3d5a@gateway/web/cgi-irc/labb.contactor.se/x-7cfe932fbac60dfc) 14.23.11 Quit webguest27 (Client Quit) 14.28.24 # Nico_P: did you see all the messages and theories I posted about the remaining buffering no-gos? 14.28.39 # I'm about to post another logf, this one from stopping at the beginning of a .sid 14.30.30 # http://test.lostlogicx.com/transfer/rockbox/logf_sid_buffering_stuck.txt 14.31.21 Join pixelma_ [0] (i=pixelma@rockbox/staff/pixelma) 14.31.28 Quit pixelma (Nick collision from services.) 14.31.29 Nick pixelma_ is now known as pixelma (i=pixelma@rockbox/staff/pixelma) 14.37.24 # lostlogic: I was just poking about in the Debug menu and I discovered the new buffering thread debug screen 14.37.59 # turns out the FLAC files are stopping playback when the "useful" buffer drops down to around 25 MB 14.38.29 # oh, that's weird. 14.38.57 # at least, if I'm understanding the slightly abbreviated labels correctly... 14.39.10 # yeah, you are. 14.39.28 Join pixelma_ [0] (i=pixelma@rockbox/staff/pixelma) 14.39.37 Quit pixelma (Nick collision from services.) 14.39.37 Nick pixelma_ is now known as pixelma (i=pixelma@rockbox/staff/pixelma) 14.39.44 # heh, never fails 14.39.46 Join webguest34 [0] (i=53ed3d5a@gateway/web/cgi-irc/labb.contactor.se/x-c68e68bf072d17b4) 14.39.51 # usefl should be how much unplayed data is left on the buffer, I've not had my playback stop when there's any (more than a few k) usefl left 14.39.55 Quit webguest34 (Client Quit) 14.40.46 # that's weird... 25mb is not < 75% full so it's not when the high callback triggers... wtf. 14.41.15 # heh, all my other files, MP3s, NSFs and SPCs play back with no issues 14.42.04 # i think the problem where playback stops with a half full buffer only happens for files that are larger than the buffer 14.42.32 # i got it with long mp3s too. 14.43.04 # PaulJam: that would make sense -- something gets stuck when it tries to shrink the playing file 14.43.14 Join JRoT [0] (n=JRoT@ip4da03737.direct-adsl.nl) 14.43.34 # only one or two of my FLAC files are actually bigger than the buffer, most of those are even smaller, so that's not my issue... 14.43.45 Nick karashat2 is now known as karashata (n=Kimi@pool1-181.adsl.user.start.ca) 14.43.49 # lostlogic: i posted my observations to fs#8031 14.44.08 # karashat2: it still could be the same issue actually because large files are still much more likely to force a shrink versus an invalidate. 14.45.07 # ahh... 14.46.08 # really need Nico_P to look at it because I don't have a strong handle on the callbacks between playback and buffering still 14.46.46 Join ditguy [0] (i=c27f0814@gateway/web/cgi-irc/labb.contactor.se/x-09ac2492c5d952e3) 14.47.57 # Bagder: are you the one who mainly makes the table (or scripts) with the recent SVN changes? Could you please output the release number for each commit? 14.48.22 # the only question I have is, why are the next and previous track mapped to the up and down on the scroll-pad for the H10 in the buffer debug screen? 14.48.23 # lostlogic: I saw the logs, yeah 14.48.35 # I'm suspecting the removal of can_add_handle 14.48.54 # ditguy: you can see the revision number in the browser stausbar when you hover over the diff link 14.51.18 # PaulJam: ah, that's the trick! But the number in a small font size wouldn't do no harm IMHO. E.g. under the date. 14.52.22 # karashata: Bad use of keymap actions.... 14.52.25 # lostlogic: I've been seeing audio dropouts in a situation where I had never seen any beofre 14.52.46 # I'm readding can_add_handle on a test build to see if there's a difference 14.53.02 # Nico_P: my issue was happening before that. the cost of can_add_handle's removal is worst case opening one file handle and 10 or 15 instructions. 14.53.23 # lostlogic: have you duplicated its logic elsewhere? 14.54.46 # Was can_add_handle doing it's check on the right thread? i.e. the buffering thread, not the API thread... 14.55.14 # Nico_P: hmm, you may be right, I thought i caught everything inside add_handle itself but I may have missed something when there's not even space to finish the current file out. 14.55.24 # pondlife: it was doing it on the caller's thread 14.55.40 # I thought so... that might not be safe 14.55.40 Quit JdGordon ("Konversation terminated!") 14.55.52 # lostlogic: yeah the case where you need to let the current handle finish buffering is vital 14.55.56 # pondlife: that was my thought, which is why I moved its (I thought) inside the mutex 14.56.02 # I'm not having the dropouts anymore btw 14.56.02 # I think we need to keep the logic, but in the buffering thread 14.56.11 # Nico_P: you added it back in? 14.56.15 # yes 14.56.37 # add_handle needs an added test 14.56.41 # Nico_P: ok, that's the problem with large files but there's still something else in there I think, having to do with callbacks 14.56.51 # Nico_P: yeah, I'll catch it since it's my breakage. 14.57.00 # Which callbacks? unbuffering? 14.57.04 # I can do it, I think I know what to do 14.57.11 # ok, cool then 14.57.19 # I have a nice test situation too 14.57.43 # pondlife: yeah -- I think the buffering api needs a per-handle callback to whomever buffered that handle to say that the handle is going to be freed _now_ and to rebuffer it if needed. 14.58.07 # but I can't think of a good way to do it without a closure and I"m not sure if C has closures 14.58.09 # lostlogic: handles should be freed (closed) only by the caller, the one who opened it 14.58.13 Join mf0102 [0] (n=michi@85.127.180.92) 14.58.25 # Nico_P is correct 14.59.00 # then the buffering api needs a finer grained way of asking the caller to close buffers "I need these buffers closed to stay afload here fellers" 14.59.12 # I thought of having the buffering thread close them and signal it to the caller, but it was hideously complicated and, IMHO, incorrect 14.59.17 # rather than the current buffer_low_callback "free anything you can" 14.59.33 # So is bufclose not being called in some case? 14.59.47 # i.e. is playback hanging onto a buffer handle? 14.59.48 # pondlife: that's what it looks like to me 14.59.58 # Well, that's the bug, no? 15.00.07 Join webguest70 [0] (i=53ed3d5a@gateway/web/cgi-irc/labb.contactor.se/x-ebf78252b2c3718a) 15.00.17 Quit webguest70 (Client Quit) 15.00.29 # right, but the root cause would be that the buffering API has no way to say "I'm trying to buffer wha tyou asked for but handle is in the way" 15.00.30 # Once a track has played, the handle should be freed (i.e. available for overwrite) 15.00.47 # pondlife: it's not freed until the buffer goes low and the buffer_low_callback is called 15.01.35 Join scorche|w [0] (n=8dc5049d@rockbox/administrator/scorche) 15.01.35 # Freed in what sense? There's "freed by a caller" (when bufclose() is called) and "overwritten".. 15.02.32 # I like to think of buffering as a specialized disk cache...not sure if that's accurate, but it's where I started. 15.03.32 # That's why I hoped http://www.rockbox.org/tracker/task/8029 wouldn't be a problem any more... i.e. while a file's data remains in the buffer, an attempt to read it shouldn't need a rebuffer. 15.04.07 # how is this possible, first i get a data abort, then a second later, an undefined instruction 15.04.36 Quit ditguy ("CGI:IRC") 15.04.44 # Didn't you implement the exception handlers? ;) 15.05.49 # yeah, and as far as i bloody know, they're final, nothing should happen after those, heh 15.05.54 # it happens consistently :P 15.06.04 # pondlife: I agree with you on fs#8029, but it's quite a big change ;) 15.06.18 # something probably goes wrong in the button handler or whatever' 15.06.26 # preglow: saw that too on my c200 15.06.32 # I know, but having the API in place should help immensely. 15.06.38 # I hope ;) 15.06.38 # indeed 15.06.53 # It's one for the future, sure. 15.07.43 # lostlogic: I have th fix ready, testing 15.08.09 # then I'll fix FS#8049 15.09.06 # hrm, perhaps i should have the data abort handler write the address it tried to access 15.10.00 # nah, i can't be bothered to write a load/store instruction disassembler right now... 15.10.31 # btw, that sounds like a stellar feature, inline disassesmbling at crashes :P 15.11.34 # I have a bug 15.11.46 # how can i see if it's jet reported? 15.12.21 # JRoT: search the tracker 15.12.28 # k 15.13.32 # i don't know where to look for 15.13.38 # i played music 15.13.46 # and suddenly it stopped 15.14.07 # JRoT: should be fixed by my commit from a couple minutes ago 15.14.09 # en now it says Undefined instruction at 40001340 (0) 15.14.12 # oh 15.14.35 # JRoT: ipod nano? 15.14.51 # sansa e260 15.15.07 # JRoT: try updating 15.15.18 # i've got the lastest build 15.15.34 # if you don't build yourself, wait 5 minutes for the build to complete, then update 15.15.49 # ? 15.16.00 # http://build.rockbox.org/dev.cgi 15.16.09 # is there an upddate every 5 minutes? 15.16.18 # Yes ;) 15.16.22 # No, not really 15.16.24 # JRoT: no, but a new version is built everytime we make a change 15.16.39 # JRoT: so it can be every 5 minutes sometimes 15.16.44 # k 15.16.59 # do need to commit this bug somewhere? 15.17.13 # if it's still there, maybe (search first) 15.17.22 # but I'm hoping it won't be there anymore 15.17.45 # k thnx 15.17.50 # is it hard to code? 15.18.34 # no, rockbox is just an afternoon hack really 15.18.38 # :-P 15.19.01 # JRoT: it's not too hard to learn 15.19.04 # * n1s utters about "enough monkeys with enough keyboards and all that" :-) 15.19.08 # mutters 15.19.18 # um... this is new... 15.19.34 # trying to switch from an NSF file to an MP3 while the player is still buffering 15.19.34 # a new bug? :p 15.19.39 # playback stops 15.19.46 # n1s: well, those that dont write C, just end up writing perl with plenty of regex ;) 15.19.51 # karashata: what rev? 15.19.54 # it switches the track, but playback stops completely 15.19.57 # 15374 15.19.59 # Nico_P any idea how to start? 15.20.00 # most recent 15.20.05 # scorche|w: let's do both! ;-) 15.20.30 # and trying to stop playback fully stalls the player... 15.20.35 # karashata i think we have the we got the same bug 15.20.45 # i skip track 15.20.50 # and it crashed 15.21.14 # oh... 15.21.15 # Bagder: way too early in the morning, and i havent had coffee yet! 15.21.16 # this is bad 15.21.33 # reset the player and rebooted it, and the first thing I get is a data abort 15.21.52 # * Bagder walks away again 15.21.52 # at 000FE6AC (0) 15.22.14 # do you have a sansa also? 15.22.22 # no, H10 20GB 15.22.48 # great... 15.23.09 # is a good thing I keep backups... 15.23.41 Join webguest81 [0] (i=53ed3d5a@gateway/web/cgi-irc/labb.contactor.se/x-916606a647982473) 15.23.43 # this build's no good, data aborts right on boot after playback stalls and a hard reset is done 15.24.04 # provided, of course, you want playback to resume right on boot 15.24.24 # can try with clean settings and see if it turns out alright 15.25.09 # ...which makes no difference 15.25.11 Quit webguest81 (Client Quit) 15.25.14 # playback is toast 15.25.21 # karashata: maybe there is a consistent crash on trying to load the song you're trying to resume to 15.25.35 # nope 15.25.48 # I cleared the settings and tried loading from the file browser 15.26.00 # crashed on trying to load even there too 15.26.10 # yeah but what did you try to load? 15.26.28 # mp3 15.26.35 # any mp3 song? 15.26.44 # any mp3 15.26.55 # flac files don't crash it, but they don't play back either 15.26.55 # my player also skips the track a little bit at the end with cossfading 15.27.42 # And now it's crashing again 15.27.45 # trying to play back an NSF file causes the player to hang entirely 15.27.46 # karashata: do you know what build you were running previously 15.27.51 # ? 15.27.55 # just a sec 15.27.56 # with nearly the same version 15.28.11 # 15370 15.29.28 # Undefined instructoin at 00061D10 is it this time 15.29.30 # trying to stop playback of SPC files causes the player to hang as well 15.30.00 # they don't play back, and as long as you don't try to stop them from not playing the player still responds 15.30.24 # hate to say it but you really killed something important there... 15.30.33 # apparently 15.31.51 # i'm going back to r15294-071025 15.32.01 # eee... 15.32.13 Join bascule [0] (i=86920029@gateway/web/cgi-irc/labb.contactor.se/x-aaf3c5a3c96e69ca) 15.32.30 # hmm, gonna try it again, I think it might have been something *I* did and not the build... 15.32.50 # * Nico_P has r15374 and it's fine 15.33.18 # i can only download 15370 according to the site 15.33.20 # JRoT: have you tried r15374? 15.33.38 # how do i download it 15.33.42 # http://build.rockbox.org/ 15.33.49 Join webguest97 [0] (i=5bc2ca05@gateway/web/cgi-irc/labb.contactor.se/x-8840df81280ea95b) 15.34.30 # hello, I have an Archos question = can anyone please help? 15.34.40 # i will try now Nico_P 15.34.56 # *try it 15.35.09 # * karashata grumbles 15.35.19 # Bagder: why doesn't the homepage have a link to MajorChanges anymore? 15.35.27 # I dunno what I did but whatever it was it really killed something... 15.35.41 # webguest97: only if you ask the question 15.36.07 Quit lostlogic (Remote closed the connection) 15.36.09 # OK = just checking to see if anyone was around :-) 15.36.13 # I recently flashed rockbox to my H120 (for speed and efficiency), but I *think* I flashed it to RAM as well as ROM. Is there any way of removing the RAM image to ensure I take advantage of the extra RAM buffer? 15.36.32 # karashata: it's working now? 15.36.43 # * preglow dropkicks arm 15.36.49 # I found the IriverFlashing Wiki page slightly confusing 15.36.49 # My Archos FM recorder is not being recognized under ubuntu = is this common? 15.37.05 # no, in fact, I think I have some personal issues with it I need to clear up now before I can check 15.37.17 # webguest97: clarify "recognized" 15.37.19 # Nico_P: same bug in 15374 15.37.23 # * scorche|w looks for....ah...there he is :) 15.37.24 # I'll get back to you as soon as I get it fixed 15.37.47 # Not seen at all - I plug it in and nothing happens at all 15.37.51 # JRoT: which one? 15.38.13 # webguest97: that is not common - you don't see anything in /var/log/messages? 15.38.27 # when i skip tracks it crashes complete 15.38.30 # webguest97: it's probably just not automounted 15.38.42 # will check - quite new to linux = brb 15.40.09 Join Stickman [0] (n=Miranda@82.152.82.150) 15.40.24 # Nico_P: when i skip tracks it crashes complete 15.40.53 # JRoT: yes, are both tracks the same codec? 15.41.27 Join toffe82 [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) 15.41.36 # Nico_P: all are MP3 15.41.46 # Had a look - can see nothing. I tried closing the log and reconnecting, but noerror or message of any kind 15.41.53 # I know it works 15.41.57 # * karashata wonders why the iriver firmware tool needs to format an already formatted player... 15.42.06 Join TTThomas_ [0] (n=root@c-68-38-172-205.hsd1.de.comcast.net) 15.43.08 # webguest97: did this work before? or is this the first time you try it? 15.43.50 # First time. It "works" under windows (there is no driver for it though, but it's recognized as a device) 15.44.14 # It plays, too. Original firmware and all the tunes I had from a couple of years back 15.44.18 # JRoT: could you send me one of your MP3 files? 15.44.27 # maybe it's tag-related or something 15.44.53 # sure i can 15.44.56 # JRoT: of course I want one that actually made your sansa crash 15.45.09 # webguest97: try, as root: mount /dev/sda1 /mnt 15.45.45 # is there a different procedure for updating rockbox versus the initial install? I am trying to update my build, and it locks up at the boot screen. 15.46.14 Nick TTThomas_ is now known as TTThomas (n=root@c-68-38-172-205.hsd1.de.comcast.net) 15.46.27 # TTThomas_: not really you usually don't have to update the bootloader though 15.46.42 # TTThomas: which player is it? 15.46.42 # It says "mount point does not exist" 15.46.51 # n1s: Toshiba F40 15.47.18 # TTThomas: does it work if you try with an older daily build? 15.47.31 # n1s: I have tried without updating the bootloader and with 15.48.10 # n1s: of course I haven't. I never think to try the simple things. 15.48.22 # I'll try that and let you know 15.50.37 Join webguest88 [0] (i=53ed3d5a@gateway/web/cgi-irc/labb.contactor.se/x-1888f278db197683) 15.50.39 Quit webguest97 ("CGI:IRC") 15.50.43 Join webguest97 [0] (i=5bc2ca05@gateway/web/cgi-irc/labb.contactor.se/x-9c8b851cce6dc689) 15.51.05 Quit webguest88 (Client Quit) 15.51.11 Join webguest60 [0] (i=53ed3d5a@gateway/web/cgi-irc/labb.contactor.se/x-8b7b9f7ec9ddadf6) 15.51.31 # ok, run "dmesg | tail -30". is there anything about scsi there? 15.51.39 # ^^ webguest97 15.51.42 # how do I get to previous daily builds? 15.52.02 # nevermind, i found it 15.52.35 # linuxstb could you please aff fotos and info about clix2 on wiki from http://forum.mp3store.pl/index.php?showtopic=17685 ? 15.52.37 Quit webguest60 (Client Quit) 15.53.14 Join webguest10 [0] (i=53ed3d5a@gateway/web/cgi-irc/labb.contactor.se/x-bfe51741e4e4faa6) 15.53.42 Quit webguest10 (Client Quit) 15.54.41 Quit bascule ("CGI:IRC 0.5.7 (2005/06/19)") 15.55.13 # "scsi5 : SCSI emulation for USB Mass Storage devices" = but that may have been for the thumb drive I used earlier 15.55.58 # As an aside, is there a workable XP driver (GPL or similar) for this device? 15.56.20 # XP has a build-in UMS driver 15.56.22 # webguest97: the fm recorder is universal mass storage compatible, no driver is needed 15.56.28 # webguest97: look at the storage size, your archos should have a larger disk than your thumb drive 15.57.18 # n1s: should i delete the current .rockbox directory or just overwrite it? 15.57.39 # found this too: "scsi 2:0:0:0: rejecting I/O to dead device" 15.57.52 # webguest97: ouch 15.57.53 # TTThomas: just overwriting should be fine but there is no harm in deleting it unless you want to keep settings and stuff that's in there 15.58.06 # ok 15.58.08 # ...except it ain't dead 15.58.38 # webguest97: well, it didn't work in winxp either 15.58.43 # webguest97: well something is wrong with it. this explains why it's not working on windows either. 15.58.55 # I'll give it another try in XP, but something weird is going on here 15.59.10 # webguest97: try it with the charger attached as well 15.59.13 # it connects, but says something like hardware config fail 15.59.27 # but it has worked 15.59.40 # and I have songs on it to prove it 15.59.43 # odd 15.59.54 # will try with the charger 15.59.56 # whee! kernel: sd 86:0:0:0: [sdb] Attached SCSI disk 16.00.04 # Zagor: wooooooooooooot! 16.00.13 # :) 16.00.15 # however: Unsupported sector size 131072. :-) 16.00.19 # lol 16.00.41 # woha! 16.00.51 # thx for all the advice and help 16.00.53 # Zagor: congrats! 16.01.00 # Zagor: excellent! 16.01.30 # it turns out my earlier mass-storage issue (tags in wrong order etc) was due to caching. big "doh" moment when I realized that... 16.01.36 Quit webguest97 ("CGI:IRC") 16.01.56 # Zagor: didn't the uncached macros work? 16.02.09 # sure, but you have to use them correctly too :-) 16.02.12 # haha 16.02.29 # specifically, not only when you send buffers to the usb controller but when you write to the area aswell. 16.02.30 Join lostlogic [0] (n=lostlogi@rockbox/developer/lostlogic) 16.02.36 # n1s: I deleted and wrote a new directory. when it boots I get a booting status screen that has 'Rockbox loaded.' as the final line, but it will not allow me to do anything. 16.03.05 # * linuxstb does the buggy UMS support dance 16.03.28 # so you're another step closer to usb support for sansa , Zagor? 16.03.30 # * LinusN rehearses the file system corruption dance 16.03.39 # * linuxstb makes backup 16.03.43 # JRoT: yeah a little step :) 16.03.59 # super! 16.04.09 # it also tells me I can hold menu when booting for rescue mode, vol+ button to restore original kernel and a button to load original firmware 16.05.00 # TTThomas: that is really weird I wonder if any of the gigabeat users around here have any ideas? 16.05.25 # TTThomas n1s: this looks like a very old boot loader 16.05.44 Quit miepchen^schlaf (Read error: 110 (Connection timed out)) 16.05.45 # it also won't let me connected via usb, so its back to my original build and try again. 16.05.59 # * TTThomas breaks out the screwdrivers 16.06.07 Join miepchen^schlaf [0] (n=hihi@p54BF6D6B.dip.t-dialin.net) 16.06.50 # TTThomas: this old bootloader will probably expect rockbox.gigabeat to be in the root and in raw format (i.e. not current format) 16.07.12 # TTThomas: how did you install the bl ? 16.07.44 # manually, monthes ago. 16.08.26 # TTThomas: I thought you said you tried updating the bootloader... 16.09.01 # TTThomas: What happens when you hold menu for rescue mode? You should be able to attach USB then and update. 16.09.04 # i did, it didnt work that why either 16.09.07 # I am fairly certain that this is the problem then - update your bootloader 16.09.26 Quit Zagor ("Client exiting") 16.10.03 # updating the bootloader is using the latest fwimg01.dat file correct? 16.10.29 # TTThomas: yes 16.11.00 # well that was fun, my leased server's internets were down for 10 minutes + 16.11.14 # ok 16.12.27 # i will need to update my .rockbox as well, or will my older build work with a newer bootloader 16.14.20 # TTThomas: well, it really depends if they were created before or after the change 16.14.28 # TTThomas: be safe and update 16.15.17 # k 16.15.21 # thought so 16.15.49 Join styleism [0] (n=sfgfadga@87-194-104-214.bethere.co.uk) 16.16.07 Join J-23 [0] (i=aldwulf@a187.net131.okay.pl) 16.16.09 # Hello! 16.16.28 # 'llo 16.17.29 # * J-23 waits for his player ;) 16.17.36 # well its amazing what happens when you do things in the correct order. 16.17.37 # TTThomas: and get rid of any lurking rockbox.gigabeat in the root for good measure 16.17.40 # wich one J-23? 16.18.05 # SanDisk Sansa c240 with radio (in Poland I can buy it without) 16.18.18 # in other countries probably too ;) 16.18.18 # it seems to be working now. version reports latest build 16.18.36 # my Sansa e280 arrived last friday <3 16.18.53 *** Saving seen data "./dancer.seen" 16.18.56 # i got my sansa e260 now for 3 weeks 16.19.08 # never used OF only for usb ;) 16.19.17 # are the sansa's that good? 16.19.24 # yeah 16.19.59 # i tried Sandisk's fw for couple of days, then changed to rockbox :) 16.20.08 # i'll pick one up next time i find one cheap. always love new toys to play with. 16.20.27 # e280 cost 114 euros here 16.20.32 # I've been using RB on my e270 since Jan. or so, I'm completely in love with it and far too excited about USB support...:) 16.20.35 # i didn't want a ipod, i think it's overrated 16.20.35 # i didn't even use the toshiba's fw for a day. wanted ogg support 16.20.57 # heh 16.21.08 # Thanks to everyone who is working / has worked on Rockbox, it's an amazing achievement 16.21.14 # I've never used sansa fw either 16.21.59 # actually it isn't a problem to having no usb support in rockbox with e200 16.22.19 # how do you get files over without usb? 16.22.30 # OF 16.22.31 # because when you plug it in when its turned off, it starts sansa fw 16.22.42 # ahh 16.22.46 # I guess you could use a MicroSD card and external reader to transfer files... 16.23.01 # yea, but that's too complicated ;) 16.23.08 Part hcs 16.23.13 # Indeed. 16.24.02 # does anyone know if the DB of OF updates faster when i put my music in an other dictory? 16.24.04 # btw, thank you n1s and roolku for your help. everything is copacetic now. 16.24.18 # great :-) 16.24.42 # JRoT: apparently it does but I haven't tried it 16.24.53 # i will try it tonight 16.25.02 # doesn't matter for rockbbox? 16.25.06 # because teh OF only looks in the Music folder 16.25.16 # Nope 16.25.24 Join rep|icant_ [0] (n=rep|ican@adsl-074-183-167-249.sip.bhm.bellsouth.net) 16.25.26 # :D 16.25.55 # i have a lot of theme garbage in my root folder. what files do I need to keep if I am trashing everything but what rockbox needs to run? 16.26.27 # Stickman: i put my music in the root of e280 with OF and it did found them 16.26.37 # TTThomas: Rockbox doesn't need anything outside the .rockbox folder. 16.26.47 # ok. 16.26.48 # Where I can learn to write RB plugins? 16.27.06 # J-23: What do you know already? e.g. can you program in C? 16.27.09 # bootsplash.raw was the onlyone i was really concerned about. 16.27.23 Join rotator [0] (n=e@rockbox/developer/rotator) 16.27.28 # J-23: http://www.rockbox.org/twiki/bin/view/Main/HowtoWritePlugins 16.27.41 Part LinusN 16.27.46 # linuxstb: No... 16.28.00 # I know only Perl basics and C++ basics 16.28.13 # If you know C++ basics, C should be straightforward. 16.28.32 # See the link LinusN posted, and also look at the source code to all the existing plugins. 16.28.58 # This is also a useful page - http://www.rockbox.org/twiki/bin/view/Main/GraphicsAPI 16.29.35 # Thanks. 16.29.36 # awesome. new build makes my buttons light up. 16.29.37 # and docs/PLUGINS although it's fairly dated. apps/plugin.h is also helpful 16.30.02 # tuplanolla: :( well that's just what I read somewhere. Maybe if you prefix the folder with a . ? 16.31.17 # If I'm trying to create a new directory on the Sansa, what's the button for 'OK'? I can enter the name but don't seem to be able to confirm. 16.31.48 # Stickman: Play 16.32.10 # Nope that goes up 16.32.19 Quit rep|icant (Read error: 110 (Connection timed out)) 16.32.25 # Stickman: rec? 16.32.29 # Hrm, was that changed.. 16.32.36 # does nothing 16.32.48 # Stickman: what sansa? 16.32.51 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 16.33.00 # pixelma: e270 16.33.42 # It *should* be play/up, unless it changed very recently 16.33.46 # play does it for me 16.34.06 # http://download.rockbox.org/manual/rockbox-sansae200/rockbox-buildch4.html#x7-410004.1.3 16.34.39 # Hmm, maybe I have an older/newer version...the ver I'm using is acouple fo weeks old 16.35.01 # That's more or less the same as I'm using 16.36.57 # Weird. The outside buttons move up/down/left/right. Select chooses a character or deletes it if you're over the text. Scroll wheel moves the cursor when you're over the text. Off exits without saving 16.37.18 Join jgarvey [0] (n=jgarvey@cpe-024-163-032-204.nc.res.rr.com) 16.38.29 # I am using a custom build so I suppose it might have some button patch...will check 16.39.33 # Sounds like it 16.39.34 Quit n1s () 16.39.38 # Aha...http://www.rockbox.org/tracker/task/7873 16.39.52 # That would do it.. 16.40.41 # * linuxstb reads the last SVN log message and wonders why lostlogic wants better mistakes... 16.43.17 # they always can be improved :) 16.45.12 # do most people use the database? my music is so disorganized that I just use the file folders 16.45.58 # * amiconn thinks would think the db *is* for people with disorganised collections 16.46.32 # wrong choice of words. my file tagging is so disorganized 16.46.54 # my folder structure is spot on. 16.47.15 # Then if you wanted, you could use an app to fix your tags based on the folder and file names. 16.47.31 # what kind of app? (linux preferably) 16.47.44 # I've never used one... 16.49.02 # Is it normal for playback to act like its stuck in low latency mode on a logf build? 16.50.47 # foobar can do that, afaik 16.51.19 # TTThomas, ex falso will do it 16.51.40 # k, i'll look into them 16.54.48 Quit J3TC- (Read error: 110 (Connection timed out)) 16.55.32 Join J3TC- [0] (n=jetc123@dhcp78-54.njit.edu) 17.00.57 Join japc [0] (n=japc@194.65.5.235) 17.05.13 Quit barrywardell () 17.05.31 # krazykit: ex falso is awesome. thanks! 17.06.00 # * preglow wonders if there is a fast way to do two parallell 16x16 multiplies with a 32x32 -> 64 multiply... 17.06.40 Quit freqmod_nx (Read error: 104 (Connection reset by peer)) 17.08.08 Join freqmod_nx [0] (i=freqmod@dhcp208-90.ed.ntnu.no) 17.08.58 Join ShadowCode [0] (n=aa@82.146.26.233) 17.10.37 Join donutman25 [0] (n=chatzill@65.75.87.48) 17.11.01 # what cen you tell me about ARM9 ? 17.11.31 Join midgey [0] (n=tjross@westquad-188-67.reshall.umich.edu) 17.11.51 # http://www.google.com/search?q=ARM9 17.12.17 # haha did that already 17.12.41 # what cen you tell me about ARM9 and RockBox 17.13.25 # ? 17.13.27 # well, what specifically are you looking for? 17.14.05 # the same thing I am looking for two months naw 17.14.12 # porting RockBox 17.14.18 # on RK2608 17.14.23 # rockchip 17.14.25 Join rep|icant [0] (n=rep|ican@adsl-074-183-167-249.sip.bhm.bellsouth.net) 17.14.25 # What's the exact CPU? 17.14.37 # RK2608A :)\ 17.15.20 # So what do you know about that CPU? Is a datasheet available? 17.16.39 # some one in hear send me a Datasheat but I lost it 17.16.48 # I know the CPU 17.17.06 # but dont know it so good to port it 17.17.06 # what do you mean? 17.17.07 Quit midgey () 17.17.25 Quit atsea-39 (Read error: 104 (Connection reset by peer)) 17.17.25 # I know what it supports 17.17.42 # but I dont know the asm instructions 17.18.02 # But it has some kind of ARM9 core? 17.18.08 # and it is ARM9 core 17.18.15 # yes 17.18.21 # it is ARM9 17.18.49 # I vaguely remeber looking at the datasheet 17.19.01 # lostlogic: Low latency mode? Not that I've noticed.... 17.19.04 # Then the asm will be standard ARM - not a problem. 17.19.09 # and I thought the examples looked like MIPS, not ARM, but I might be mistaken 17.19.47 # ShadowCode: better find the datasheet again 17.20.21 # from the review of the RK2606 rockchip i cen tell its ARM9 17.20.28 Quit lee-qid (Read error: 110 (Connection timed out)) 17.20.38 # and RK2606 and RK2608 are the same 17.20.46 # ShadowCode: do you have a link? 17.20.49 # if the link was posted here, you could try searching the logs 17.20.53 # http://translate.google.com/translate?u=http%3A%2F%2Fwww.itren.cn%2Fnews%2Fshownew.asp%3Fid%3D10189&langpair=zh%7Cen&hl=en&ie=UTF8 17.21.38 Quit rep|icant_ (Read error: 110 (Connection timed out)) 17.22.14 # the cpu was mentioned in irc on http://www.rockbox.org/irc/reader.pl?date=20070916 around 17:22 17.22.34 # * linuxstb is too slow searching the logs 17.22.52 # ShadowCode: You gave us a link to the datasheet at 17.43... 17.22.53 # * petur hugs google 17.23.15 # petur: you can link the post directly by time 17.23.30 # oh.. nice 17.25.27 # pondlife: It was not letting the pcm buffer reach nearly full before unboosting, I'm making sure it doesn't do the same on a normal build 17.25.51 # It was unboosting early? 17.25.54 # yeah 17.27.27 # http://admin.gestogospel.sk/datasheets/Rock26XX-datasheet.pdf 17.27.37 # linuxstb: do you recognize the "example software" asm instructions? 17.27.39 # hears the datasheat 17.27.53 # markun: No... 17.28.45 # And there is no mention of the word "arm" anywhere in the PDF 17.29.01 # Nor MIPS 17.29.27 # yes 17.29.27 # Maybe certain players have both an ARM core plus this chip in them though. 17.29.41 # but the review sead it's ARM 17.29.52 # You can't believe what you read on the Internet... 17.30.33 # yes but its bether that nothing 17.30.37 # Do you have a link to the review? 17.30.48 # http://translate.google.com/translate?u=http%3A%2F%2Fwww.itren.cn%2Fnews%2Fshownew.asp%3Fid%3D10189&langpair=zh%7Cen&hl=en&ie=UTF8 17.30.55 Quit Stickman ("-- no longer here --") 17.31.01 # IF you want I cen past the part on ARM 17.31.07 # linuxstb: these guys also seem to know what they are talking about: http://forum.mp3store.pl/lofiversion/index.php?t14695.html 17.31.10 # and no ARM either 17.32.12 # dont do it the leasy way look at he midle of the review 17.32.51 # if you want to search use RK2606 for the search 17.33.28 # It's odd that the datasheet doesn't mention anything about ARM though. 17.33.32 # ShadowCode: well, it doesn't look like ARM to me, and searching for all the instructions in the datasheet also didn't give me a clear picture which instruction set it is 17.33.52 # bah the hdd in my H140 is dead :/ 17.34.04 # Time to go 80GB? 17.34.15 # 80's are too rare and expensive 17.34.25 # Xerion: sell it to me, I have an extra 40g drive sitting around :-P 17.34.30 # think i'll try to find a 60GB HD on ebay or something 17.34.32 # * linuxstb feels smug for buying one when they were still available 17.35.14 # oh there is a 80 GB avaliable somewhere but for 200 euro, a bit too much ;) 17.35.44 # and wath core do you sugest ? 17.36.07 # something MIPS like 17.36.07 # stupid dutch ebay won't give me my password back :( 17.36.15 # Some marketing stuff.. http://www.dolphin.fr/corporate/announcements/publications/pdf/rockchip.pdf 17.36.21 # Probably no new info 17.36.52 # ShadowCode: I don't know what the chances are we will find a compiler for it.. 17.37.44 # waht is DAC 17.37.57 # Digital-analogue-converter 17.38.00 # http://www.dolphin.fr/flip/logic/logic_overview.html 17.38.46 # I don't think this is relevant, but they do compare it to ARM and MIPS cores. 17.38.53 # pondlife: still a lot of players add a wolfson DAC 17.39.54 # Here is the official site - http://www.rock-chips.com/en/en.asp 17.40.02 # and what is I2DSP 17.41.42 # in the datasheet it is mentioned Embedded DSP Core ? 17.42.27 Quit petur ("*plop*") 17.42.44 # * karashata has managed to find very little, other than that it's based on the ZSP400 DSP core 17.42.52 Quit sbeh (Remote closed the connection) 17.43.05 # * linuxstb is too slow again.... 17.43.45 # ShadowCode: Can you find any other references to it being ARM, apart from that link you gave? Nothing else appears to support that. 17.43.59 Quit Rob222241 (Read error: 104 (Connection reset by peer)) 17.44.00 # http://doc.chipfind.ru/lsil/zsp400.htm <- there's a datasheet for the ZSP400 DSP available for download there 17.45.48 # The instructions seem to match 17.46.21 # So conclusion is: Not a straightforward port... 17.46.39 # cen we test if its ARM or MIPS or ARC .. 17.46.45 Join Lear [0] (i=chatzill@rockbox/developer/lear) 17.46.50 # karashata: nice find 17.46.59 # ShadowCode: Do you have a firmware file for it? 17.46.59 # I do what I can 17.47.05 # yes 17.47.08 # I have many 17.47.18 # ShadowCode: encrypted? 17.47.24 # http://www.lsi.com/news/product_news/2003_10_15a.html <-- might wanna take a look at that 17.47.27 # and the updeat tools and the drivers 17.47.44 # I dont know maby 17.47.47 # I have to look 17.49.18 Join illissius` [0] (n=illissiu@91.83.19.40.pool.invitel.hu) 17.49.28 # lostlogic: I've noticed that the next track info doesn't seem to display for the last track in the buffer; should a request for next track info bring the buffering forward? 17.49.34 Quit advcomp2019 (Read error: 104 (Connection reset by peer)) 17.49.47 Join advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) 17.52.07 Join midgey [0] (n=tjross@westquad-188-67.reshall.umich.edu) 17.52.43 # http://www.verisilicon.com/en/products.asp?id=23&id2=37 <- dunno if that helps any, should I stop digging now before I turn up stuff that doesn't help? 17.53.25 # pondlife: that should (IMO) be handled entirely in the playback engine, it has a functin for loading just metadata for a track and holding it in its own buffer 17.53.49 # (this is what it did in the pre MoB world) 17.54.19 Quit J3TC- (Read error: 110 (Connection timed out)) 17.54.21 # OK, so that would trigger a spinup, which in turn would trigger a rebuffer, right? 17.54.31 Part pondlife ("Gone") 17.54.42 Join pondlife [0] (n=Steve@rockbox/developer/pondlife) 17.54.46 # Oops 17.55.02 # pondlife: well the way the old code did it was to actually buffer one extra metadata during a buffer fill.. "Buffer's done, read one more metadata and save it for use later" 17.55.08 Quit styleism (Read error: 110 (Connection timed out)) 17.55.12 # Yes the Firmware is cripted 17.55.42 # Ah, that is something that playback.c should still be doing 17.55.42 # ShadowCode: Do you have a link to a firmware file? 17.55.50 Join sbeh [0] (n=sbeh@mx0.ategram.com) 17.55.51 # pondlife: so if we don't do that inside playback then yes I suppose that a request should be made to buffer the next track, which would trigger the full rebuffer at that time. 17.56.23 # pondlife: but in order to supoprt next-track for tracks larger than the buffer I think playback needs to handle it entirely 17.56.35 # yes w8 a sec 17.56.58 # lostlogic: for tracks longer than the buffer it could simply load the metadata directly to nexttrack_id3 17.56.58 Quit scorche|w ("CGI:IRC (EOF)") 17.57.08 # Playback maintains its own copy anyway, it's just the timing. 17.57.24 # Nico_P: what about for shorter tracks that are just at the end of the buffer? 17.57.34 # Nico_P: It should do the same thing for all tracks, regardless of size 17.57.42 # do you think we should do a rebuffer as soon as that metadata is needed or have another id3 buffer in playback.c to hold it? 17.58.06 # Rebuffer would be more consistent 17.58.11 # But it should come out in the wash. 17.58.16 Join tedr0ck [0] (n=tedrock@d235-156-104.home1.cgocable.net) 17.58.17 # pondlife: when there are several tracks on the buffer, the metadata would be erased 17.58.35 # Wouldn't that handle be kept open? 17.58.48 # it's not a handle 17.59.07 # linuxstb: ftp://d:d@59.39.59.99:2121/teclast/mp3/TL-C260%28V01.10.0001%29.rar 17.59.19 # Ah, I thought there was a track and a metadata handle for each track. 17.59.23 # what I'm saing is that for tracks longer than the buffer, nextrack_id3 will always be empty so we can use it 17.59.33 # pondlife: it's the case 17.59.34 # and this is the upgread sofrware ftp://d:d@59.39.59.99:2121/teclast/mp3/Update.rar 18.00.11 # pondlife: I don't see a way we can handle it the same for both cases. 18.00.23 # dionoea: MoB was not implemented for hwcodec (yet) and afaik amiconn has no problems with his RecorderV1 18.00.43 # I don't really know the code well enough to comment in detail, I'm afraid. 18.00.44 Join javamon [0] (i=9db61aff@gateway/web/cgi-irc/labb.contactor.se/x-26a0a1d243d7d77b) 18.00.47 # pondlife: for a track longer than the buffer, the next track metadata cannot be on buffer, but for a track that happens to be at the end, it can be no the buffer but will only be if we do an early rebuffer 18.01.41 # We have to keep a copy off-buffer anyway then. 18.01.56 # yeah I think we have to use yet another static buffer 18.01.57 # Just the ID3/track structure 18.02.01 # Shouldn't the idea be that the playback engine never touches the disk - all disk I/O is done via the buffering API? 18.02.06 # Nico_P: that's what I'm afraid of. 18.02.30 # linuxstb: Not really, more that all audio buffer use goes via the API 18.02.32 # linuxstb: that would preclude providing next_track info when playing a > buffer sized track 18.02.48 Quit ATravelingGeek (Connection timed out) 18.02.50 Join scorche|w [0] (n=8dc5049d@rockbox/administrator/scorche) 18.03.13 Join webguest30 [0] (i=432024e6@gateway/web/cgi-irc/labb.contactor.se/x-204b8e360460fac8) 18.03.17 # Which is most of the time when we get to Archos-land. 18.03.27 Quit webguest30 (Client Quit) 18.03.32 # Or rather, much more often. 18.03.34 # lostlogic: Couldn't that be made a feature of the API - to always have that metadata available? 18.03.55 # linuxstb: the API isn't really meant for this sort of thing 18.03.56 # Seems to not be a buffer issue, just a playback one.. 18.04.54 # linuxstb: I was just running some scenarios in my head -- it would be possible to make the api reserve space at the end of buffering for an id3 struct which playback reads when it needs that metadata and immediateyl frees. 18.04.55 # But isn't the buffering intended to handle metadata? 18.04.58 # Nico_P: what do you think of that? 18.05.20 # Nico_P: it would require some reworking of the way space is reserved on the buffer perhaps, but should be doable. 18.05.31 Join kugel [0] (n=kugel@unaffiliated/kugel) 18.05.46 Quit javamon ("CGI:IRC (Ping timeout)") 18.05.55 # lostlogic: it could make things become quite complex 18.05.59 # There's a danger of wasting space with multiple copies of the id3 struct., no? 18.06.05 # i.e. in playback too 18.06.19 # pondlife: not sure I follow 18.06.19 Join Bradleian [0] (n=Bradleia@host213-160-109-48.dsl.vispa.com) 18.06.44 # We currently have statics in playback.c for the previous/current/next track, right? 18.06.47 # Nico_P: the main problem would come in keeping synchronized between cur_handle->widx and buf_widx but yes, it could be hairy. 18.07.30 # pondlife: yeah, having a "last" in addition shouldn't cause trouble, just waste space. Last would be only used to copy into next when the buffer doesn't have next and never for anything else 18.08.13 # Ah, I see.. Just a track struct, not full metadata. 18.08.19 # lostlogic: I think the static struct in playback.c is more KISS, especially as it's not really the buffering API's job to handle that 18.08.22 Join Rob2222 [0] (n=Miranda@p54B17638.dip.t-dialin.net) 18.08.34 # pondlife: jsut an struct id3 18.08.49 Quit sbeh ("changing servers") 18.08.52 # Nico_P: I agree ;) just trying to appease linuxstb ;) 18.08.57 Quit Bradleian ("Leaving") 18.09.06 # * pondlife wishes that struct wasn't called id3... :) 18.09.08 Join sbeh [0] (i=sbeh@serverstaff.de) 18.09.12 # pondlife: don't we all ;) 18.09.15 # it's actually called mp3 18.09.21 # Even worse! 18.09.24 # mp3entry... :p 18.09.25 # track_info ? 18.09.35 # Go on, you know you want to... 18.09.54 # it's about metadata... track_info is already used in playback.c 18.10.07 Quit tedrock (No route to host) 18.10.15 Join ATravelingGeek [0] (n=ATG@pdpc/supporter/student/ATravelingGeek) 18.10.59 # I was thinking about using offsets instead of pointers in struct mp3entry... it would make some things complicates 18.11.03 # complicated 18.11.53 # Nico_P: what does it complicate? 18.11.54 Nick sbeh is now known as gentoo (i=sbeh@serverstaff.de) 18.12.01 Nick gentoo is now known as sbeh (i=sbeh@serverstaff.de) 18.12.04 # lostlogic: access to the values 18.12.36 Quit illissius- (Read error: 110 (Connection timed out)) 18.12.47 # no more id3->artist... you'd need to change all the code that accesses it to (char *)(id3 + artist) 18.13.12 # or actually (char *)(id3 + id3->artist) 18.14.02 # I found something about zsp interupts int the datasheet the core is zsp ? 18.16.38 Join TMM [0] (n=hp@217.195.253.12) 18.16.45 # Nico_P: yeah, trunuf -- I wonder if we could do some macro magic on it 18.18.55 *** Saving seen data "./dancer.seen" 18.19.01 Quit midgey () 18.19.01 # yeah maybe #define ID3(ptr, string) (char *)(ptr->buffer + ptr->string) 18.22.35 Join barrywardell [0] (n=barrywar@dhcp-892b9b55.ucd.ie) 18.23.40 Join BigBambi [0] (n=alex@rockbox/staff/BigBambi) 18.29.09 Join webguest68 [0] (i=53ed3d5a@gateway/web/cgi-irc/labb.contactor.se/x-50c204ed4a93eb14) 18.29.53 Quit webguest68 (Client Quit) 18.30.58 Join ciapuppet [0] (i=tabac@gateway/gpg-tor/key-0xB9002659) 18.32.28 Quit kugel ("Benutzer ist abwesend.") 18.33.11 Nick parafin|away is now known as parafin (i=parafin@paraf.in) 18.33.42 # i did something while a song started playing: i held the rewind button in thinkin it would continue from the last songs ending position. but my sansa blacked out the screen and became unresponsive.. now the scroll wheel is lit up the entire time and the little thing wont power off 18.34.14 # hold power for a bit 18.34.23 Join Domonoky [0] (n=Domonoky@f051115217.adsl.alicedsl.de) 18.36.04 Nick ciapuppet is now known as ciapuppets (i=tabac@gateway/gpg-tor/key-0xB9002659) 18.37.26 # ShadowCode: 17:42 * karashata has managed to find very little, other than that it's based on the ZSP400 DSP core 18.38.02 Part J-23 18.39.24 # hhm 18.39.36 # ok so wat cen I do about it ? 18.40.04 # I want to crack this player and use the full power of the CPU 18.40.36 # hot damn.. that actually WORKED (did not the first time) thanks scorche 18.40.52 Nick ciapuppets is now known as ciapuppet (i=tabac@gateway/gpg-tor/key-0xB9002659) 18.41.04 # ShadowCode: maybe you can find this compiler: http://211.152.35.101/zsp/support/downloads/docs/pdf/compiler_sdk.pdf 18.41.24 Quit ciapuppet ("Leaving") 18.41.42 # "The C compiler ( sdcc) has been implemented by retargeting the Free Software Foundation's GNU compiler (gcc) for the ZSP architecture." 18.43.27 Join rep|icant_ [0] (n=rep|ican@adsl-074-183-167-249.sip.bhm.bellsouth.net) 18.43.41 Join ciapuppet [0] (i=tabac@gateway/gpg-tor/key-0xB9002659) 18.46.54 # is ther a guid on how no run test code on this player 18.47.32 # TL-C260 RockChip RK2608A :) 18.50.32 Quit rep|icant (Read error: 110 (Connection timed out)) 18.51.47 # ShadowCode: well, that is the whole point of a port...that is one of the steps to figure out 18.52.56 # Very bad 18.53.04 Quit idnar (Nick collision from services.) 18.53.07 Join idnar_ [0] (i=mithrand@unaffiliated/idnar) 18.54.50 # http://sdcc.sourceforge.net/ <-- no clue if this helps anyone at all, but, here ya go... 19.00.11 Nick ciapuppet is now known as jumpatrain (i=tabac@gateway/gpg-tor/key-0xB9002659) 19.02.29 # dionoea, pixelma: Current builds are working fine on hwcodec; I'm using my recorder this week, just updated the build y'day 19.02.58 Join webguest30 [0] (i=53ed3d5a@gateway/web/cgi-irc/labb.contactor.se/x-d4b69d72c561915e) 19.03.03 Quit webguest30 (Client Quit) 19.03.59 Join hcs [0] (n=agashlin@rockbox/contributor/hcs) 19.04.08 # very bad?...this is all part of the process for a port... 19.04.15 # amiconn: maybe you have an idea what could be wrong for him then... http://forums.rockbox.org/index.php?topic=13510.msg101844#msg101844 19.04.29 Join rep|icant [0] (n=rep|ican@adsl-074-183-167-249.sip.bhm.bellsouth.net) 19.05.01 Join lazka [0] (n=lazka@85-124-46-45.dynamic.xdsl-line.inode.at) 19.05.04 Quit pondlife ("Read error: 110 (Connection slimed out)") 19.07.51 Join bertrik [0] (n=Bertrik_@031-020-045-062.dynamic.caiway.nl) 19.09.02 # amiconn: you wouldn't happen to know of a fast trick to use 'smull' to calculate two packed 16x16 bit multiplies, would you? :> 19.10.21 # Afaik that's not possible 19.10.50 Quit bertrik (Client Quit) 19.11.07 Join bertrik [0] (n=Bertrik_@031-020-045-062.dynamic.caiway.nl) 19.11.16 Quit rep|icant_ (Read error: 110 (Connection timed out)) 19.13.07 # OOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 19.13.08 # Rockchip rk26** is based on zsp400 dsp core 19.13.17 # haha 19.13.52 Join linuxstb_ [0] (n=chatzill@i-83-67-212-170.freedom2surf.net) 19.13.54 # look this tread http://www.teclasters.com/showthread.php?t=483 19.14.17 # ShadowCode: We've been saying that for the past couple of hours... 19.14.22 # this is a disassembler for .rkp the game format of the player 19.14.44 # haha sry I was doing something else :) 19.15.14 # ok so I naw need a compiler to suport zsp400 ? 19.15.25 Join ilgufo [0] (n=matteo@host106-177-dynamic.4-87-r.retail.telecomitalia.it) 19.15.28 # * karashata nods 19.15.29 Quit jumpatrain ("Leaving") 19.15.36 # best of luck to ya, though 19.15.40 Join TotallyInfected [0] (n=ebola@pool-141-151-2-130.phlapa.east.verizon.net) 19.15.56 # I searched through everything I could think of and turned up nothing I would expect to be useful 19.17.07 # this guy maked the disassembler must know something 19.17.20 # I am going to get in touch with him 19.17.45 # Nico_P: I thought about storing the metadata strings as offsets, but am not sure it's a good idea. IIUC, they are read many times, so it may be more efficient to keep them as they are, and adjust the pointers if you move the struct. You would also need to change all the metadata parsers... 19.19.02 Join styleism [0] (n=sfgfadga@87-194-104-214.bethere.co.uk) 19.19.53 # linuxstb_: yes, that's what I realised. accessing is the critical operation, not moving 19.20.42 # karashata: I also found that sourceforge project, but it's not the same 19.21.43 # markun: unfortunately, anything else I tried turned up the PDF you got that comment from in the first place, and nothing else I figured could be useful 19.22.30 # linuxstb_: problem is that the buffer shouldn't hafta 'do stuff' to data as it moves it around on itself 19.23.09 # but then I guess we are an audio playback firmware so some level of special treatment may be 'right' 19.24.15 Join spiorf [0] (n=spiorf@host13-223-dynamic.1-79-r.retail.telecomitalia.it) 19.24.16 # amiconn: no, i didn't think so either, just wanted to see if you had any tricks up your sleeve, heh 19.24.25 # packed 1616 is giving me shit on arm 19.24.49 Join aurum_ [0] (n=aurum@ool-182f7087.dyn.optonline.net) 19.26.03 Join Bagder_ [0] (n=daniel@1-1-5-26a.hud.sth.bostream.se) 19.33.30 Part aurum_ 19.35.01 Join aurum_ [0] (n=aurum@ool-182f7087.dyn.optonline.net) 19.36.09 Join ompaul [0] (n=ompaul@gnewsense/friend/ompaul) 19.40.27 Join n1s [0] (n=nils@nl104-209-90.student.uu.se) 19.41.14 Part toffe82 19.42.25 Quit Bagder (Read error: 110 (Connection timed out)) 19.49.19 # Is someone hear know Chinies ?:) 19.49.34 # google cent translate something 19.53.20 Join Daniel_S [0] (i=57b0ddb3@gateway/web/cgi-irc/labb.contactor.se/x-c4d72bf0144d4170) 19.55.02 Join merbanan [0] (n=banan@83.233.243.136) 19.57.28 Join thegeek_ [0] (i=thegeek@s220b.studby.ntnu.no) 20.04.21 Quit Daniel_S ("CGI:IRC") 20.04.29 Join Daniel_S [0] (i=57b0ddb3@gateway/web/cgi-irc/labb.contactor.se/x-035a22028843f8ca) 20.06.13 Join darkless [0] (n=darkless@x1-6-00-1a-92-ea-71-14.k201.webspeed.dk) 20.07.31 Join rep|icant_ [0] (n=rep|ican@adsl-074-183-167-249.sip.bhm.bellsouth.net) 20.07.48 Quit rep|icant_ (Client Quit) 20.09.57 Quit aurum_ ("Time wasted on IRC: 45 minutes 45 seconds") 20.13.11 Quit Daniel_S ("CGI:IRC (EOF)") 20.13.32 Join Buschel [0] (n=abc@p54A3DDD5.dip.t-dialin.net) 20.13.49 Join Arathis [0] (n=doerk@p508A4B44.dip.t-dialin.net) 20.14.56 Quit thegeek (Read error: 110 (Connection timed out)) 20.15.49 Quit rep|icant (Read error: 110 (Connection timed out)) 20.16.41 Quit hcs ("Leaving.") 20.17.44 # preglow: If you have to process packed 16 bit samples, it still pays off on arm7tdmi to load multile sample pairs with ldmia, then decompose to do the multiplication 20.18.00 # amiconn: problem is i have so few registers 20.18.00 # See my demac filter code for arm7 20.18.57 *** Saving seen data "./dancer.seen" 20.19.02 # besides, high -> low = 1 cycle, low mask -> 2 cycles, that's just the same as an ldrsh 20.19.22 # Doing 8x ldrh costs 24 cycles, doing 1x ldmia into 4 regs costs 6 cycles, plus 12 for the decomposition (when signed; for unsigned it would be cheaper) 20.19.34 # That saves 25% 20.19.46 # amiconn: oh, i don't have enough registers for ldmia by far, ldr is all i can do 20.19.55 # Then it's not worth it 20.20.10 # perhaps in the .order_10 loop when i don't have enough regs for keeping the memory loaded anyway 20.20.37 # On arm7 it practically always pays off to use ldmia 20.20.41 # amiconn: i figure i'll gain more by keeping the eight memory values in registers than burst reading the 16 bit array anyway 20.20.44 # Even when loading just 2 regs 20.20.56 # small wonder, ldr is so slow... 20.21.23 # On arm9 and higher that advantage is gone - if you can put something between the load(s) and the processing instructions 20.21.32 Quit TMM (Read error: 110 (Connection timed out)) 20.21.54 # well, i get a data abort for some stupid reason anyway, so this is all moot until i fix that 20.22.17 # a data abort, then a second afterwards, illinstr exception :P 20.22.20 # amiconn: Did you look at my ARM version of the predictor decoder to see if it could be improved? 20.22.37 # linuxstb: I used it as a reference for my cf version... 20.23.09 # But the predictor isn't the bottleneck, as I confirmed this morning 20.26.41 # you're still sure it uses a range coder? 20.26.48 # yes 20.26.55 # range coding as in arithmetic coding? 20.26.56 Quit thegeek_ ("( www.nnscript.de :: NoNameScript 4.1 :: www.regroup-esports.com )") 20.27.04 # no wonder it's kinda heavy, then 20.27.08 # As in the twin of arithmetic coding, exactly 20.27.12 Quit scorche|w ("CGI:IRC (Ping timeout)") 20.28.08 # ape strikes me as somewhat overkill :P 20.28.18 # bloody order 1000 filters and range coding for marginal gains 20.28.45 # That's only the 'insane' compression - and that does 3 level filtering 20.29.07 # 16th order followed by 256th order followed by 1280th order 20.29.10 # you have to do such an insane amount of work to squeeze out those last bits 20.29.15 # wavpack uses only order 1 filters... 20.30.13 # -c1000 uses no extra filter. -c2000 uses 16th order, -c3000 uses 64th order, and -c4000 uses 32th order followed by 256th order 20.30.22 # kind of funny. did you knwo that the wording "xtreme" and "insane" were taken over from musepack and that this wording was defined in a night telephone conference with one tester, several beers and cigarettes? ;o) 20.30.44 # hahaha 20.30.47 # as it should be 20.31.09 # my room was quite foggy -- as my mind :) 20.31.09 Join przemhb [0] (n=przemhb@fan115.internetdsl.tpnet.pl) 20.31.17 # amiconn: while i remember, any reason buschel's latest patch isn't commited? 20.31.22 # Hi all 20.31.40 # Buschel: you had a look at sv8, btw? 20.31.43 # preglow: Which one? The one that just skips updates is dirrty... 20.31.56 # amiconn: 8041, don't think it skips updates 20.32.00 # preglow: not yet, only did 1 or 2 enc/dec tests 20.32.15 Quit ilgufo ("So Long, and Thanks For All the Fish - http://gufo.wordpress.com") 20.32.17 # Buschel: they're pestering my to sync rockbox with it all the time, heh 20.32.57 # i can guess 20.33.06 # i eventually will, but i can't be bothered now 20.33.10 # i don't really enjoy syncing... 20.33.18 # plus, it'll kill our sv4-6 support 20.33.26 # unless i merge it in, and i really, really can't be bothered 20.33.31 # syncing is great, merging is a pain :) 20.33.33 # i don't think many people have 4-6 files 20.33.38 # preglow: (1) the leaving out of certain register writes needs to be tested on an older G5 (hw rev before 0xb0010) 20.33.41 # Buschel: yeah, i mean merge, heh 20.33.46 # amiconn: oh, ok 20.33.56 Quit Nico_P (Remote closed the connection) 20.34.03 # why do they keep breaking the format anyway? 20.34.21 # musepack? 20.34.23 # (2) I have an idea how to hide the 14ms wait from the update functions completely, without missing updated content 20.34.24 # preglow: at least I should have some sv4-sv6... 20.34.25 # that happens really seldom 20.34.26 Join scorche|w [0] (n=8dc5049d@rockbox/administrator/scorche) 20.34.51 Join ilgufo [0] (n=matteo@host106-177-dynamic.4-87-r.retail.telecomitalia.it) 20.35.08 # The rectangle coordinate writes _are_ necessary with the current system, otherwise updates would be placed wrong 20.35.40 # musepack sv4-sv6 was availabe for very short time. i dont think there is a reasonable amount of files exisiting. the brakethrough came with sv7 20.35.54 # Leaving them out is possible when they didn't change from the last update, but the if() for checking would be almost slower than just doing the write 20.36.33 # ...if done the way I discovered - not all parameters need a call to lcd_bcm_write32(), only the first one. The bcm auto-increments the write address internally 20.36.37 Join ArterNauta [0] (n=M3@host237.190-139-46.telecom.net.ar) 20.36.39 # amiconn: i played around with creating a task which starts the updates 20.36.54 # A complete task would be overkill 20.37.20 # I'll try using a tick task, and if that can't be synchronised nicely, I'll hook into the scroll thread 20.38.06 # miconn: hmm, i also used a tick taks. why not using a tiny "real" taks and use semaphores for interacting? 20.38.15 Join obo [0] (n=obo@rockbox/developer/obo) 20.40.01 Join thegeek [0] (i=thegeek@s220b.studby.ntnu.no) 20.40.08 Quit styleism (Read error: 110 (Connection timed out)) 20.40.13 # amiconn: like giving the semaphore when pixel updates are finished. then driver task starts updates, waits until update finished and takes semaphore again? 20.40.54 # amiconn: this way we cpould meanwhile do further updates... (for same rect setup type) 20.41.05 # *could 20.41.19 # My idea allows putting new updates *always* 20.42.03 # The tick task is just for making sure that updated content written while an update is running will be shown even if there are no further calls to lcd_update_rect() or lcd_yuv_blit() afterwards 20.42.07 # even on changed rect setup? 20.42.28 # I will *never* change the rectangle once set up for fullscreen :) 20.42.52 # But of course I won't transfer the full rectangle everytime, that would be silly 20.43.35 # so, constant setup and then writing the pixel data to the appropriate dest... 20.44.33 # yup 20.45.17 Quit japc (Read error: 110 (Connection timed out)) 20.46.31 # maybe could take into account fs#8041 into account before? it does some speed-up of the lcd_update_rect (the asm-stuff) and some clean-up via removing un-needed calls. 20.47.00 # But I won't start to implement this before a G5 owner tests some stuff. I have the suspicion that the bcm in there is a bit different 20.47.01 # ahem, doubled "into account"... but you knwo what i mean 20.47.05 # hmm, the latest updates to playback code have broken the db statistics updating 20.47.29 # amiconn: just post a patch and ask for test? 20.47.46 # jhMikeS: patch for you in the tracker 20.47.47 Nick ArterNauta is now known as Arternauta (n=M3@host237.190-139-46.telecom.net.ar) 20.47.47 # The commands I found - there is a function that selects one of them based on the ipod's hw revision 20.48.14 # Either the bcm itself is different, or the firmware loaded into it from the flash rom 20.48.33 # The real challenge is to figure out how to use the on-disk bcm firmware 20.48.52 # we need to find out how to upload and use the apple codecs :> 20.49.33 # Based on what I found in the OF so far, it seems to be quite different. I did not find any of the command words found in the rom, nor those 0xE00nn addresses 20.50.06 # linuxstb said that he could perform those tests 20.50.42 # preglow: I would be even more interested in letting the bcm do the yuv conversion 20.51.03 # Afaiu, the bcm codecs are for mpeg4 and for h.264, not for mpeg2 20.51.54 Part Arternauta 20.51.58 # playback.c currently defines some callbacks that take a (bool) last_track argument, but none of the current callback users uses this last_track argument 20.52.17 # if that callback argument is removed, playback.c can get a little smaller and simpler, shall i submit a patch? 20.52.48 Join xys [0] (n=xys@74.85.70.250) 20.53.18 # amiconn: sure, but then you'll need a whole new tool set and docs on what kind of instruction set it uses... 20.53.28 # bertrik: If those are general callbacks which can also register on hwcodec, that engine would need to be adjusted as well 20.53.49 # But saving binsize is always nice.... 20.54.03 # as far as i can see (in the c code), nobody uses it 20.55.14 Quit linuxstb_ ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") 20.55.54 # I'll try to make a patch (and will no doubt find out if there's still a user somewhere) 20.56.01 Quit barrywardell () 20.56.56 Join styleism [0] (n=sfgfadga@87-194-104-214.bethere.co.uk) 20.57.33 # bertrik: Only tagtree.c seems to use it, and that one just uses (void)last_track; to silence gcc... 20.58.23 # yep, last_track isn't used at all 20.58.28 # that can be removed 20.58.47 # and it removes a special case from audio_generate_postbuffer_events and audio_clear_track_entries 20.59.23 # it was used a very long time ago.. 20.59.32 # It needs to be removed from firmware/mpeg.c as well then 20.59.50 # Slasheri: I guess that was only used in the old tagdb? 20.59.55 # indeed 21.00.29 # Iirc it was even me who added the callback mechanism to the hwcodec engine back then... 21.01.00 # current db engine commits changes to disk after a few seconds delay after last update request 21.01.03 Quit Buschel (Read error: 104 (Connection reset by peer)) 21.01.34 # Hmm, it's not delayed until the next spinup? 21.01.55 # nope, but playback engine makes sure those requests are made during spinup only 21.02.07 # Ah, hmm... 21.02.17 # amiconn: Me and my 5g are available... 21.02.22 # * amiconn isn't sure whether this works properly on hwcodec then 21.02.35 # linuxstb: Ah, nice :) 21.02.59 # linuxstb: First test: try the 4 known command words one by one in lcd_init() 21.03.04 # amiconn: but probably the db engine could be improved to handle all the caching itself 21.03.12 # (which is an empty fn in svn) 21.03.44 # Slasheri: I guess it works properly on hwcodec though, as those are buffer/unbuffer callbacks, and buffering requires the disk to be spinning 21.03.58 Join Buschel [0] (n=abc@p54A3DDD5.dip.t-dialin.net) 21.04.02 # indeed, it should 21.04.15 Quit billenium_ (Read error: 104 (Connection reset by peer)) 21.04.19 # but atm it seems no buffer callbacks are generated properly on the swcodec side 21.04.31 Nick idnar_ is now known as idnar (i=mithrand@unaffiliated/idnar) 21.05.20 # linuxstb: put the following 2 statements in lcd_init(), then build, install (just core is sufficient), boot and watch the screen during boot. Then do a quick measurement of fps (doing just one cpu freq is sufficient) 21.05.31 # amiconn: Do you mean lcd_init_device? 21.05.45 # ehm, yes 21.06.21 # lcd_bcm_write32(0x1F8, 0xFFF70008); BCM_CONTROL = 0x31; 21.06.49 # preglow: patch for me? just got home so time for a mail call I guess. 21.06.58 # Repeat this with the command value changed to 0xFFF5000A, then 0xFFEC0013, then 0xFFEB0014 21.07.52 # For me, executing 3 of those 4 just does nothing. 0xFFF70008 seems to be some kind of reset - it causes a brief flash of white followed by the normal display reappearing 21.08.33 # The ROM uses 2 commands in sequence, but that'll be the next test 21.09.37 Join Buschel_ [0] (n=abc@p54A3DDD5.dip.t-dialin.net) 21.09.37 Quit Buschel (Read error: 104 (Connection reset by peer)) 21.10.00 # i hate my notebooks battery save mode... 21.10.02 Quit scorche|w ("CGI:IRC (EOF)") 21.10.19 # Buschel_: This is #Rockbox... 21.10.42 # With the first command, I get an apple logo, then a white flash, then an apple logo, then the main menu in Rockbox - no Rockbox splash. 21.10.59 # Ah, so the reset takes a while 21.11.32 Join scorche|w [0] (n=8dc5049d@rockbox/administrator/scorche) 21.11.38 # (so the bcm misses our first lcd_update() - the one writing the splash screen 21.11.59 Join qweru [0] (n=kvirc@bb-87-80-66-156.ukonline.co.uk) 21.12.04 # llorean: i know, and i dislike beeing disconnected all the time when it shuts down 21.12.28 Quit xys ("Leaving") 21.13.12 Join syn4pse [0] (n=syn4pse@cpe-075-176-155-093.sc.res.rr.com) 21.14.29 Quit ShadowCode () 21.16.20 # can I #include in my plugin code? I want to implement tan() 21.17.10 # There is no math.h in rockbox, so no 21.17.22 # poop 21.17.24 # (unless I'm missing sth) 21.17.30 # amiconn: With the other three commands, everything seems normal. FPS appears identical in all 4 tests - 23.6/46.7fps @ 30MHz 21.17.42 # Okay, so the same what I get 21.17.54 # Yours was an 0xb0005 ? 21.18.06 # Let me double-check 21.18.25 # is there a sqrt()? 21.18.26 # Yes, HW info displays 0xb0005 21.18.31 # ok 21.18.57 # This is one of the first ipod videos - bought within the first couple of months of release. 21.19.15 # linuxstb: Okay. Next test would be to try the 2-command sequences the OF uses, in theit 4 permutations, with a sleep(5) inbetween 21.19.59 # lcd_bcm_write32(0x1F8, 0xFFEC0013); BCM_CONTROL = 0x31; sleep(5); lcd_bcm_write32(0x1F8, 0xFFF70008); BCM_CONTROL = 0x31; 21.20.34 # ..with the permutations being 0xFFEB0014 in the first command, and 0xFFF5000A in the second 21.21.27 # The OF uses 0xFFEC0013 on 0xb0010 and higher, and 0xFFEB0014 on earlier models 21.21.45 # So (13,08), (14,08), (13,0A), (14,0A) ? 21.22.17 Join Daniel_S [0] (i=57b0ddb3@gateway/web/cgi-irc/labb.contactor.se/x-6d65cf546f866ad3) 21.23.01 # First test gives the same effect as the previous first test - apple, white, apple, menu 21.23.03 Quit amiconn (Nick collision from services.) 21.23.09 Join amiconn [0] (n=jens@rockbox/developer/amiconn) 21.23.42 Join DerPapst [0] (n=DerPapst@p54B2C681.dip.t-dialin.net) 21.23.46 Join mirak [0] (n=mirak@m94.net81-66-75.noos.fr) 21.23.48 # 'lo all 21.24.11 Quit mirak (Remote closed the connection) 21.24.25 # iirc someone here wanted to have the source code of iboy? 21.25.00 # anyways... here it is. http://www.ipodlinux.org/Image:Iboy-0.7.5.4.tar.gz 21.25.35 # Is that the current source? Whenever I looked for source in the past, the source never matched the latest binaries... 21.25.43 # it is 21.25.54 # took me one month to get it :D 21.26.11 # Thanks, but I've no idea who was asking for it... 21.26.31 # it took you a month to get it? o_O 21.27.38 # yeah.. lot's of people don't take it that serious if they modify GPL'ed code that they have to release the source too. 21.27.44 # linuxstb: I forgot to mention that you need a forward declaration of lcd_bcm_write32(), but you obviously noticed... 21.27.52 # amiconn: Test 2 (14,08) is the same as the first. 21.28.02 # Yes, I just moved the init function further down... 21.28.13 # No speed difference either? 21.28.21 # No, all still the same. 21.28.37 # * amiconn really wonders what those '13' and '14' commands are for 21.28.57 # The rom seems to know a total of 4 lcd types... 21.29.02 # so i talked to one of the last devs and he managed to find the source somewhere and send it to me. 21.29.16 # DerPapst: I've noticed... ;) Odd for a Linux-based project... 21.29.23 # yeah 21.29.43 # quite odd...isnt it in cvs/svn? 21.29.45 # whe try to enfore these rules more strictly now. 21.29.52 # *we 21.30.24 # nope it's 3rd party and thus not in the official svn repo 21.31.14 # there is a svn repo for iboy however but this is a quiet old source snapshot (somewhere around 0.3.X or 0.5.X). 21.32.18 # linuxstb: Btw, the missing splash also happens here - didn't even notice that yesterday :> 21.32.32 # (when sending 0xfff7008 that is) 21.32.34 # amiconn: Test 3 (13,0A) shows the splash as normal, same FPS. 21.34.03 # The only command that seems to do anything is 0007 (apart from the known 0005: update rectangle) 21.34.06 # amiconn: are you after a video which isn't a 0xb0005? 21.34.37 # I have a recent one for testing (still LinusN's) - it's an 0xb0011 21.36.02 # Test 4 (14,0A) same as the third. 21.36.38 # Okay, thanks. Now you can remove the command stuff from lcd_init_device() (or just revert the file to svn) 21.36.56 # Next tests deal with lcd_bcm_setup_rect() 21.37.09 # There's more? ;) 21.37.25 # Yes :/ 21.37.33 # 3 to be precise 21.38.05 Join J3TC- [0] (n=jetc123@dhcp76-117.njit.edu) 21.38.22 # First one is testing the address auto-increment. That requires replacing all occurences of lcd_bcm_write32() in lcd_bcm_setup_rect() *except the first 2* 21.38.53 # I.e. leave the ones that write to 0x1F8 and 0xE0000, and replace all following one with just a write to BCM_DATA32 21.38.59 # OK. 21.39.08 # BCM_DATA32 = x; BCM_DATA32 = y; .... 21.39.23 Quit styleism (Read error: 110 (Connection timed out)) 21.39.25 # Should be 7 in total 21.41.27 # That seems fine. 21.42.34 # Okay, final 2 tests are for 'don't care' parameters in there 21.43.17 # First one: Set the first parameter (the one written to 0xe0000 in the second lcd_bcm_write32()) to 0, as well as the last 3 ones 21.43.41 # So write 0, then the 4 rectangle parameters, then 3 times 0 21.44.27 # OK 21.45.25 # Seems good. 21.45.55 Quit Siku () 21.46.09 # The final one is just for making sure those parameters are really ignored, by writing some arbitrary values. Make sure they take up more than 16 bits 21.46.24 # I used (decomal) 111111, 222222, 333333 and 444444 21.46.29 # *decimal 21.46.31 # So values I've put as zero? 21.46.32 Join advcomp2019_ [0] (n=advcomp2@unaffiliated/advcomp2019) 21.46.34 # yes 21.47.21 Quit Daniel_S ("CGI:IRC (EOF)") 21.47.55 Join midgey [0] (n=tjross@westquad-188-67.reshall.umich.edu) 21.48.14 Quit n17ikh () 21.49.18 Quit advcomp2019 (Nick collision from services.) 21.49.29 Nick advcomp2019_ is now known as advcomp2019 (n=advcomp2@unaffiliated/advcomp2019) 21.50.10 # Yes, that's fine too. 21.50.29 # Okay, so I can be fairly sure that different bcm versions are not an issue 21.50.43 # Thank you very much for testing :) 21.51.03 # You're welcome. Now you can work a miracle.... 21.51.07 # Forgot to ask - did you upgrade the firmware at some point? 21.51.21 # The OF (+flash) I mean... 21.51.32 # I can't remember... 21.51.42 # hmm, ok 21.52.11 # It possibly has been though. I can check the Apple firmware version now. 21.53.25 # It says 1.2.1 21.53.38 # * linuxstb has no idea what that means though... 21.54.01 # The diag mode displays the lcd type iirc 21.54.13 # Mine (well, LinusN's) is type 2 21.54.21 # * DerPapst guesses that it's the latest version of the apple bootloader 21.55.23 # linuxstb: Btw, while doing this, I am looking for backlight brightness and hdd power stuff in parallel 21.55.42 # I was just about to say that I noticed a backlight brightness test screen in diagmode... 21.55.46 # DerPapst: you can get the iboy source off of their sourceforge page (0.7.5.4) 21.56.05 # linuxstb: Yes, I found that screen's code in the rom, but I don't understand yet how it works 21.56.07 # midgey: didn't know they updated it 21.56.11 Join n17ikh|Lappy [0] (n=n17ikh@c-76-23-98-11.hsd1.sc.comcast.net) 21.56.27 # midgey: last time i checked it was outdated. 21.56.44 # amiconn: I assume you found my flashsplit program to separate the apps in the flash? 21.56.45 # Oct 03, 2007 21.56.45 # It calls several functions which do some weird calculations with the parameters, and then fiddle with both the gpio port range and 0x70000080 21.57.13 # DerPapst: its under the iBoy heading, not iBoy Source 21.57.19 # I can't find an lcd type display in the diagmode... 21.57.26 # I remember that program, but didn't use it. I just didassembled the whole blob 21.57.26 # its a tar.bz2 that contains the release binaries and source 21.57.35 # More than half of the rom is just empty... 21.57.39 # took me forever to find it a while back 21.58.51 # linuxstb: It's in the Accessories test 21.58.57 # amiconn: I just found "LCD ID : 2" - in the "Accessorize Test" screen. 21.59.05 # yes 21.59.22 # You'll now need a fw power cable to proceed... 21.59.36 # Or MENU+SELECT... 21.59.57 # Hmm, reset works. Somehow it didn't work the last time I tried - which puzzled me 22.00.21 # I know that reset should always work - that's why I was puzzled 22.01.15 # midgey: Have you looked at the iboy source in detail? 22.01.32 Quit merbanan (Remote closed the connection) 22.01.50 # linuxstb: I've looked at it, but I wouldn't say in detail 22.02.23 # Any plans to try and use some of the code for rockboy? 22.02.37 Join Frazz [0] (n=Fraser@thelawsons.plus.com) 22.03.13 # at one point a hacked their dynamic translator and asm code over into rockboy, but i never tested it 22.03.22 # s/a/I 22.03.44 # That sounds like a lot of work to not test... 22.03.54 # i dont know if i have that attempt floating around on this computer or the one at home 22.04.10 # linuxstb: blame the brother for not letting me borrow his iPod 22.04.22 # I assume the dynamic translater is arm only atm? 22.04.37 # * linuxstb takes midgey's brother off the cookie list 22.04.45 # amiconn: indeed 22.05.13 # to be honest, i really dont know that much about emulation or dynamic translation for that matter 22.05.20 # For rockbox it'll need some extension then. Could be done gradually if it doesn't break the interpreted execution 22.05.24 Quit Domonoky (Read error: 104 (Connection reset by peer)) 22.05.35 Join Domonoky [0] (n=Domonoky@e179088200.adsl.alicedsl.de) 22.05.39 # * amiconn is really curious how much dynamic translation helps 22.05.58 Join JdGordon [0] (n=jonno@c210-49-113-143.smelb1.vic.optusnet.com.au) 22.06.04 # I know that (win)uae profits a lot from the technique 22.06.42 Quit Rondom ("Ex-Chat") 22.07.02 Join Rondom [0] (n=Rondom@p57A9491F.dip.t-dialin.net) 22.07.06 # amiconn: i think they did some benchmarks and posted the results and a rundown of the code changes in a pdf on their sourceforge 22.07.34 # iboy runs at least a bit faster than realtime even with color roms 22.07.49 Quit mf0102 ("Verlassend") 22.07.54 # i've got some changes to the lcd code that I'd like to commit some time after this week 22.08.22 # the asm for the recorder will need updating, i've if 0'd it out in the patch 22.08.24 # The lcd code in rockboy is a real mess atm imho 22.08.38 # indeed 22.08.45 # The greyscale updates are done completely different from the colour ones 22.08.52 # DerPapst: Do you know if it also makes use of both cpu cores? 22.09.06 # it has some routines.. yes 22.09.15 # this patch tries to unify the code to use one routine for both 22.09.24 # and adds iPod greyscale support 22.09.35 # but it currently is ifdef hell 22.09.41 # yes 22.10.05 # Otoh I would like to see this code stay as fast as possible 22.10.08 # linuxstb: the code seems to use the cop here and there 22.10.37 # amiconn: i don't have any non-color targets to test on so i cant say if it has an inpact on speed 22.11.03 # amiconn: I made a patch for removal of the last_track argument removal: FS#8053 22.12.00 Join midgey_ [0] (n=tjross@westquad-188-19.reshall.umich.edu) 22.12.37 Quit midgey (Nick collision from services.) 22.12.48 Nick midgey_ is now known as midgey (n=tjross@westquad-188-19.reshall.umich.edu) 22.13.04 Nick ilgufo is now known as Er-Mentolino (n=matteo@host106-177-dynamic.4-87-r.retail.telecomitalia.it) 22.14.31 # bertrik: For hwcodec this could be simplified more 22.14.57 Quit crashd (Read error: 110 (Connection timed out)) 22.15.06 # The event_count variable does just exist for determining the last track 22.15.58 # ah, hadn't looked that far, doing one thing at a time 22.16.00 # So the whole first loop could go in each of the funtions 22.16.56 # want me to fix it? 22.17.16 # The first loop is just for determining how many unsent events are there, so the second loop knows when to set that flag 22.18.03 # And now I remember what this was for: it was indeed a hint for the old tagdb when to flush buffered data 22.18.24 # Man, this must have been ages ago... 22.18.59 *** Saving seen data "./dancer.seen" 22.19.45 Join Zagor [0] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) 22.20.22 # if anyone would like to take a look at the rockboy lcd changes, see FS #7546 22.20.39 # lcd_refreshline() is full of ifdefs... 22.21.20 # suggestions on a better method or a way around the ifdefs are welcome 22.22.10 # Without looking at the code, my only suggestion would be splitting the code into separate files, possibly with some duplication, but that could be cleaner than trying to do it all in one function. 22.22.34 # the main issue it the pixel format 22.22.39 # s/it/is 22.22.46 # So separate files by pixel format? 22.23.05 # might be an option 22.23.22 Join crashd [0] (i=foobar@lostnode.org) 22.23.23 # More than 2 years ago, r7376 from 21 Aug 2005.... 22.25.44 # midgey: You would probably also want to introduce a SOURCES file (so you can #ifdef files), and change the Makefile to use it. 22.25.46 Quit Buschel_ () 22.26.18 # midgey: If that dynamic translation can be put in platform-by-platform, I'd be really interested in trying to adapt it for SH1... 22.26.50 # Atm the recorder version is purely experimental, at 1..2fps... 22.26.58 # linuxstb: yes, that'd be the best way to do it 22.27.33 Quit Lear ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") 22.27.50 # amiconn: if i have some time this weekend i'll upload my attempt at hacking in the iboy stuff 22.27.56 # i highly doubt it will work 22.30.03 # And of course we should make it work on coldfire too 22.30.22 # * linuxstb wonders optimistically if Zagor would be interested in porting his USB code to Telechips ;) 22.30.24 # There are beginnings of 'dynarec' (as he called it) done by HCl... 22.30.42 # linuxstb: I definitely am 22.30.50 # linuxstb: First, it needs to be working... 22.31.05 # Which, the USB code or the Telechips port? ;) 22.31.14 # both 22.32.12 # * linuxstb goes back to reading the NAND datasheet... 22.32.21 Quit n17ikh|Lappy () 22.32.57 Quit J3TC- (Read error: 110 (Connection timed out)) 22.33.43 # Zagor: congratulations on your progress by the way. you're moving much faster than i would have thought 22.34.31 # midgey: nice of you say that (I think ;) personally I'm frustrated that I'm hitting so many problems slowing down my progress. 22.34.39 Join J3TC- [0] (n=jetc123@dhcp76-117.njit.edu) 22.35.52 # heh, even with your slow-ups you're moving fast 22.36.35 # i've never really looked into how usb works so it all seems complex to me 22.36.54 # * n1s got his gigabeat s today and is now standing with the crowd eagerly awaiting that usb code :-) 22.37.19 Quit jgarvey ("Leaving") 22.37.32 # Huh? Gigabeat has a hw bridge afaik... 22.37.37 # Ah, S 22.38.11 # n1s: can you run a test and read out three registers for me? 22.38.48 # Zagor: I haven't run any code on it yet but will probably look into it some time next week or so... 22.38.54 # ok 22.39.19 Quit amiconn (" rebbbbbooootttt") 22.39.20 Join kugel [0] (i=kugel@unaffiliated/kugel) 22.39.51 # Zagor: if you post what it is that you want to know you might get lucky if any of the gigabeat s hackers read the logs :) 22.40.44 Nick parafin is now known as parafin|away (i=parafin@paraf.in) 22.40.44 # or if it is a roadblock for you I'll try to get it running now... 22.41.04 Join kkurbjun_ [0] (n=kkurbjun@alamode.Mines.EDU) 22.41.19 # morning all 22.41.22 Join n17ikh|Lappy [0] (n=n17ikh@c-76-23-98-11.hsd1.sc.comcast.net) 22.41.27 # I've tried that a couple of days now. seems not many people are working on the S yet. it's not a roadblock, I'd just like to know how much the usb modules differ 22.41.57 # does anyone have a problem with aloowing the list to have scrollbars as its items? (so the debug screes can use the list widget) ? 22.44.07 # IIUC, the S port is still at a stage where it's hard to run code - it requires patching a windows installer and flashing the device. 22.44.27 Quit Er-Mentolino ("So Long, and Thanks For All the Fish - http://gufo.wordpress.com") 22.44.49 # linuxstb: that's as much as I have gathered 22.45.10 # JdGordon: I don't understand what you mean... 22.45.10 # and the wiki page isn't overly clear either :-) 22.45.42 Join bluey [0] (n=bluey@dslb-088-073-087-132.pools.arcor-ip.net) 22.46.00 # From what I've understood, it seems the S has an even more convoluted booting system than the Sansas with their 4 USB modes... 22.46.06 Quit Rondom ("Ex-Chat") 22.46.06 # linuxstb: the buffering and i tihnk one or two other debug windows have horizontal scroll bar things to show info.. I'm wondering if its a bad idea to allow the list to display them as items? 22.46.40 Join amiconn [0] (n=jens@rockbox/developer/amiconn) 22.46.48 # You mean the progress bar things? 22.46.53 # yeah 22.47.03 # * JdGordon not fully awake yet 22.48.18 # What's the reason for making the debug screens use the list widget? 22.48.22 # http://www.slimdevices.com/pi_squeezebox.html? <-- I want one and I want to hack it. 22.48.31 # amiconn: I know how im going to fix the info list things so it doesnt take much effort to fix the current screens... _BUT_ on bitmap lcd it is going to have to be a setting... the text callbacks dont know which display they are on so it cant reposition automatically) 22.49.23 # lostlogic: those squeezeboxs are nice eh ? 22.49.24 # linuxstb: really none... except maybe a bit of code shirnkage 22.50.18 # lostlogic: I can strongly recommend it. I've had one for years. 22.50.47 # nice, glad to hear I'm not the only one who's been struck by the bug to get his _digital_ audio wirelessly to his stereo. 22.50.54 # hehe 22.50.55 # hacking it is quite simple -- the server is made in perl :) 22.51.06 # i've been considering building my own setup with a cheap touchscreen interface 22.51.09 # ooh, one of my favorites 22.51.20 # * rasher coughs and points at the topic 22.51.20 # Zagor: is that the slimserver? 22.51.21 # Don't use 'simple' and 'perl' in one sentence... ;) 22.51.25 # crashd: yup 22.51.35 # amiconn: :( 22.51.37 # rasher: :( 22.51.42 Quit Toxicity999 (Read error: 113 (No route to host)) 22.51.44 # Zagor: What about the device itself? Is that's hackable, or do you have no desire to/ 22.52.00 # * linuxstb tries to justify this conversation by suggesting a Rockbox port 22.52.17 Quit homielowe (Read error: 110 (Connection timed out)) 22.52.32 # 250 MHz 8-way multithreaded RISC processor 22.52.36 # afaik it's fully documented. but the device has no storage, it's network based. so a rockbox port isn't quite the same as on normal daps. 22.52.36 Join Toxicity999 [0] (n=bryan@unaffiliated/Toxicity999) 22.52.36 # linuxstb: that was my first thought... but it alreasy supports most of our formats ... 22.52.45 # linuxstb: Btw, I verified my idea for a workaround to the occasional lcd freezes 22.52.46 # just what jhMikeS needs to break the kernel code again :D 22.52.47 # it's got 16m flash 22.53.11 # It's indeed just the bcm ignoring an update, so that our query-for-finish loop never ends 22.53.17 Nick Bagder_ is now known as Bagder (n=daniel@1-1-5-26a.hud.sth.bostream.se) 22.53.19 # so no internal storage fr music? 22.53.25 Join exius_ [0] (n=exius@adsl-99-163-180-137.dsl.lsan03.sbcglobal.net) 22.53.34 # JdGordon: no, it's a network player 22.53.43 # amiconn: I never experienced that, but then I don't use my 5g any more... 22.53.53 # hey, with the new buffering API, we could surely treat 802.11 like a hard disk :) 22.53.57 # I made it exit that loop after a second and simply go on with the next update for a test, additionally bringing up the backlight when it happens, so I'll notice 22.54.22 # Zagor: heard you had some nice progress with usb, congrats 22.54.27 # linuxstb: It only happens if a lot of screen updates are going on, e.g. if you have peakmeters in the wps 22.54.44 # what about this: http://www.overclockers.co.uk/showproduct.php?prodid=AV-001-PI&groupid=703&catid=827&subcat= 22.54.46 # With peakmetered wps, it'll happen 1..2 times per hour on average 22.54.49 # preglow: well, it's only a small step. but thanks anyway. 22.54.51 # that's asking to be hacked with its poor support for formats 22.55.01 Quit J3TC- (Read error: 110 (Connection timed out)) 22.55.48 # crashd: why even buy that if it's bad? get the squeezebox. they do it right. 22.56.07 # aye, but they are cheaper than the squeeze 22.56.21 # considerably cheaper 22.56.24 # ya, for a reason... 22.56.28 # yeah, but 22.56.45 # there's no reason that the soundbridge couldn't support other formats and be more featurefull 22.56.48 # just look at rockbox! ;) 22.57.51 # JdGordon: yes, that would be fun to break the kernel code on :) 22.58.20 # the thing with network players is that once they support wav, the server can transcode and send any format to it. heck you could listen to sid tunes on the squeezebox. 22.58.55 Join J3TC- [0] (n=jetc123@dhcp76-117.njit.edu) 22.58.56 # but that requires a hackable server 22.59.05 # or a hackable device :) 22.59.13 # anyway, it was just a suggestion, i've gotta get home, been at work way too long 23.02.11 Join Strath [0] (n=donat@dpc6747254230.direcpc.com) 23.05.11 # but first I have to know when libmpeg2 is actually done with a packet so buffering can safely overwrite it. I have a video where buffering ends up clobbering one or more during fill before libmpeg2 is done with it. (ah, but details) 23.05.57 Quit Domonoky (Read error: 104 (Connection reset by peer)) 23.06.42 Quit Frazz ("Leaving") 23.06.50 Join EnterUse1Name [0] (n=dave@ip-218.55.99.216.dsl-cust.ca.inter.net) 23.07.41 Quit EnterUserName (Read error: 113 (No route to host)) 23.08.48 # Zagor: come into #rockbox-community so the conversation can continue :) 23.09.41 # * scorche|w glares at other devs who miss out on the fun in community ;) 23.10.22 Quit Arathis ("Bye, bye") 23.12.28 Quit crashd (Remote closed the connection) 23.13.14 # * jhMikeS avoids #community to avoid spilling brain contents. Much better noone sees those. ;) 23.13.20 Quit midgey () 23.18.03 # it cant be worse than the ones spouted by the abi folks in there ;) 23.18.10 # whoops... /clear >_> 23.18.40 Part exius_ 23.18.49 # cp irc.log proof/ 23.18.52 # oops 23.19.00 # hehe 23.19.26 # we need some more devs in there! 23.19.41 # I would think we need more devs in here... 23.19.50 # well, both... 23.19.52 # ;) 23.20.01 # There's been no commits for almost 40 minutes ;) 23.20.08 # * scorche|w gasps 23.22.20 Join crashd [0] (i=foobar@lostnode.org) 23.23.00 Quit donutman25 ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") 23.24.05 Quit J3TC- (Read error: 110 (Connection timed out)) 23.25.46 # be 23.25.49 # bye 23.25.53 Part przemhb 23.28.19 Join animeloe [0] (n=animeloe@unaffiliated/animeloe) 23.29.49 Join midgey [0] (n=tjross@westquad-188-19.reshall.umich.edu) 23.37.13 Quit Slasheri (calvino.freenode.net irc.freenode.net) 23.37.13 NSplit calvino.freenode.net irc.freenode.net 23.37.13 Quit Jon-Kha (calvino.freenode.net irc.freenode.net) 23.37.24 NHeal calvino.freenode.net irc.freenode.net 23.37.24 NJoin Slasheri [0] (i=miipekk@rockbox/developer/Slasheri) 23.37.24 NJoin Jon-Kha [0] (n=Jon-Kha@80-248-247-190.cust.suomicom.fi) 23.37.32 Quit bluey ("This computer has gone to sleep") 23.38.22 Join Daniel_S [0] (i=57b0c83e@gateway/web/cgi-irc/labb.contactor.se/x-a678ddf080f0277b) 23.39.55 Join Bluedragoon [0] (i=18884b0d@gateway/web/cgi-irc/labb.contactor.se/x-9a585557d02046d6) 23.40.04 # hello 23.40.24 Quit Bluedragoon (Client Quit) 23.40.37 # heh... 23.40.45 Quit kkurbjun_ ("leaving") 23.43.32 Join safetydan [0] (i=dc9d468b@rockbox/developer/safetydan) 23.44.22 Join justlistenin [0] (i=968750f3@gateway/web/cgi-irc/labb.contactor.se/x-4fa9059ea300dbb8) 23.44.24 Quit davina (Remote closed the connection) 23.44.40 Join einhirn [0] (n=Miranda@p5B0319C6.dip0.t-ipconnect.de) 23.44.51 Part safetydan 23.45.32 # any news on e200 usb progress? 23.45.45 Join safetydan [0] (n=safetyda@rockbox/developer/safetydan) 23.46.03 # justlistenin: minor progress, nothing really interesting 23.47.03 # ah, ok. Thanks. Can't wait for it, but even with the database refresh everytime you add/remove music, its still better than OF :D 23.50.18 # justlistenin: do you know that the database refresh can be suppressed by a recent bootloader? 23.51.03 # i did not, I actually JUST downloaded the bootloader and installed it a few seconds ago. I haven't even unplugged my sansa yet because I am also adding a few themes 23.51.15 # that is an awesome thing to know, thank you! 23.51.41 # bertrik: what information do you need to find the same bits for c200? 23.51.55 # Zagor: That method won't work on c200 23.52.10 # :( 23.52.23 # c200 doesn't reboot after usb disconnect, it goes straight back into the of, so our bootloader can't intercept 23.52.32 # as stated in the commit message - I helped barrywardell to test it on c200 23.53.00 # Zagor: more motivation for you to work on usb ;) 23.53.06 Quit crashd (Read error: 110 (Connection timed out)) 23.53.12 # hehe 23.53.23 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 23.53.23 # good thinking, we don't want zagor to relax too much! ;-) 23.54.04 # no naps? :( 23.55.42 Join webguest46 [0] (i=4a469ecd@gateway/web/cgi-irc/labb.contactor.se/x-e8674c7ce8c70487) 23.56.05 Join RoC_MasterMind [0] (n=Free@c-66-177-39-225.hsd1.fl.comcast.net) 23.56.38 # what do i use to edit the rockbox bootloader. I want it so i can boot more than one .mi4 file. Like hold down the center button to load firmware. 23.57.01 # a text editor 23.57.11 # gcc and a clue 23.58.09 # is there direction somewhere that i could follow 23.59.00 Quit scorche|w ("CGI:IRC")