--- 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.")