--- Log for 30.12.110 Server: brown.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 3 days and 22 hours ago 00.00.30 # [Saint]: because I wished to see something != 0 which could have been a sign for a CLK divider > ^1 00.00.36 # > 1 00.00.42 # thomasjfox: sure 00.00.59 Nick kugel is now known as kugel2 (~kugel@rockbox/developer/kugel) 00.01.05 Nick kugel2 is now known as kugel (~kugel@rockbox/developer/kugel) 00.01.31 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 00.01.31 # * jhMikeS wonders if "clever trick" means "non-blocking" 00.01.31 # [Saint]: excure my english, I am not always able to express fine details ;) especially not after 3 beers 00.01.55 # <[Saint]> Ah, while you're poking around with the LCD...if you find anything that could cause FS#11820 don't hesitate to throw something at me to test while I can. 00.02.08 # <[Saint]> And, your English is fine ;) 00.02.44 # <[Saint]> the artefacts left on screen with the Colour on shutdown are BLOODY annoying! 00.02.48 # Saint: Unless you have a slow connection, you can pretty easily download an ubuntu VM image off sourceforge, then run rockboxdev.sh there 00.03.07 # or even just download the crummy one with the compiler already installed on our wiki 00.03.32 # <[Saint]> saratoga: very slow connection at the moment. 00.03.42 # ah sucks 00.04.18 # jhMikes, kugel: The codec thread starts running and fills up the pcm buffer. The dma transfer gets his own start address. There are multiple chunks in the pcm buffer queue and we update the write position when we add a new chunk. So basically the codec thread and the dma engine work on the same data but not on the same area of the data. As the dma thread still reads data from the beginning of the buffer, we can update the 00.04.20 # write position without trouble. Or how does the non-blocking update for the DMA engine work? 00.04.36 # [Saint]: this bug report sounds similar to an effect I knew from the iPod Video. Solution was to write a white (?) full screen image to clear the display before shutdown... something like this... 00.05.08 Nick froggyman_ is now known as froggyman (~seth@98.115.0.7) 00.05.13 Quit froggyman (Changing host) 00.05.13 Join froggyman [0] (~seth@unaffiliated/froggyman) 00.05.21 Nick [Saint] is now known as S_a_i_n_t (S_a_i_n_t@203.184.0.89) 00.05.21 DBUG Enqueued KICK S_a_i_n_t 00.06.12 # thomasjfox: that's about it, yes. at least according to my (limited) understandings of the pcm stuf 00.07.14 # the DMA engine protects itself against another IRQ by masking the IRQ line, so that is safe 00.07.17 # thomasjfox: nonblocking queue adt sort of. I'm not sure if things are safe when space is tight though. I think I've seen it freeze if kept consistently very low on data. 00.07.58 # jhMikeS: Well, the code smell like it (no offense) 00.07.58 # jhMikeS: I think I've seen that freeze on the app as well 00.08.10 # Buschel: CLCD_CLOCK_SRC: C0000000 00.08.57 # thomasjfox: typically there's very little masking of audio dma interrupts. they're usually higher than HIGHEST_IRQ_LEVEL and specially synchronized. 00.08.58 # commit_chunk() f.e. quickly updates the write position 00.09.32 # though "quickly" means it's not protected by any kind of locking 00.09.40 # S_a_i_n_t: bad again... at least from we know about PP502x so far, there is nothing I can do... 00.09.44 # nor should it be locked 00.10.10 # locking = bad 00.10.14 # S_a_i_n_t: +30% for YUV i not bad though 00.10.31 # I didn't want to say I want a mutex in there :o) 00.10.53 # I'm just thinking things through for the app case on a SMP box 00.10.56 # Buschel: From my tests, I would say commit. 00.11.16 # I even notice some plugins perform a lot better. 00.11.27 # chopper.rock for one is a lot smoother 00.12.27 # kugel: something looks fishy when the read and write positions might collide but I never really went deep 00.12.44 # boomshine.lua also is less visably choppy, chopper.rock used to suffer from very bad tearing on some lines, now it is still quite bad, but not nearly *as* bad. 00.13.00 # thomasjfox: the host should handle this kind of issues SMP boxes 00.13.06 # And yes Buschel, a 30% speed-up is nothing to be sneezed at. 00.13.12 Quit komputes (Quit: I haven't slept for ten days, because that would be too long.) 00.13.29 Quit bertrik (Quit: :tiuQ) 00.13.35 # Though, your Nano2G LCD optimisations make it look rather negligible 00.14.16 # kugel: If the sim is using the new sigaltstack instead of the SDL_mutex, chances improve of things going wrong on SMP boxes if the dma buffer is low 00.14.29 # dma buffer = pcm buffer 00.15.06 # would that be bad? 00.15.27 # the intend of the sim is to simulate real target situation, not "just work" 00.15.56 # if this kind of situation can happen on target we should be happy that we can simulate it now 00.16.06 # :) 00.16.24 # Let me think about a "use case" 00.16.58 Nick S_a_i_n_t is now known as [Saint] (S_a_i_n_t@203.184.0.89) 00.16.58 DBUG Enqueued KICK [Saint] 00.17.14 Quit Bagder (Quit: It is time to say moo) 00.17.22 # but I still don't think SMP is an issue. we don't do SMP on our own, only if the host wants us to, in which case the host has to handle the SMP-related issues (and external context switch) 00.17.46 # that includes synchronizing the caches of the cpu 00.17.51 # New commit by 03Buschel (r28930): Speed up of iPod nano 1G and iPod color LCD. Use HDD6330 asm part for YUV blitting, introduce special handling for full width screen updates. Speed up ... 00.19.51 # r28930 build result: 8 errors, 0 warnings (Buschel committed) 00.19.54 # kugel: Please correct me if I'm wrong: If we run rockbox as an application on a multi core Intel box, we will get memory ordering issues as the SDL audio thread might run on another core. 00.20.20 # I don't think so 00.20.31 # kugel: Though we just read from the pcm buffer with our own start address 00.20.36 # tomasjfox:mpegplayer's pcm buffer is quite a bit simpler to understand but perhaps just as alarming :) 00.20.40 # the threads thing is putting the many core issues into a blackbox 00.21.04 Join parafin [0] (parafin@paraf.in) 00.21.13 # kugel: How is that working? 00.21.21 # multithreaded apps that work correctly on a single cpu setup also work correctly on a many core/multi cpu setup 00.21.39 # New commit by 03Buschel (r28931): Forgot one file. 00.22.03 # though I imagine it's possible to hide and data barrier and cache issues in the pcm driver, where it's normally done anyway 00.22.25 # kugel: Almost correct 00.22.36 # kugel: Let's say you have a multithreaded app on a single core box 00.23.08 # If you use volatile for the shared primitives, you're fine 00.23.09 # kugel: if correct practices are observed and threads always treated as concurrent 00.23.18 # <[Saint]> Buschel: Well, yeah...I know you're a busy man...but if you do come up with anything for the iPod Colour screen artefacts issue, gimme a yell. 00.23.27 # without memory barriers, this will break on a SMP box 00.23.32 # jhMikeS: that's my point yes 00.23.49 # <[Saint]> And, thanks for your work on Nano1/2G and Colour recently 00.23.51 # r28931 build result: All green 00.23.56 # <[Saint]> Buschel: ^ 00.24.12 # [Saint]: thanks for testing! 00.24.22 # <[Saint]> Nano2G LCD is *damn* fast now. 00.24.34 # thomasjfox: if shared data has no memory barriers it's not working correctly on a single cpu setup too 00.24.40 # <[Saint]> very smooth movies/plugins...very nice. 00.24.59 # kugel: I was talking about primitive types 00.25.26 # primitive types + volatile works fine on single core IMHO 00.25.42 # what primitive types do you mean? 00.25.49 # Uint32 f.e. 00.26.13 # even those need locks on a fully concurrent system 00.26.39 Quit pamaury (Remote host closed the connection) 00.27.22 # huh? That's news to me. 00.29.14 # f.e. if I only use it as a "done" flag 00.29.49 # <[Saint]> If it too much hassle, forget it...but if you can roll me a build with FS#11707 added I will test that as well and you can commit that too... 00.29.57 # <[Saint]> Buschel: ^ 00.30.12 # <[Saint]> I have already tested it on two Nano1Gs, with success. 00.30.45 # it doesn't matter, writing that flag is not necessarily a single instruction (nothing is guaranteed to be a single instruction if you're writing C anyway), and you can always get preempted during updating the flag 00.32.08 # kugel: Ah ok, here's my error: I was thinking about a single instruction (which it usually is) 00.32.25 # volatile is enough if only one side has write-access to the flag, but if more than 1 runnable unit has write access you need locks, regardless of the size 00.32.35 # yes, that's true 00.33.06 # thomasjfox: it's not, especially not on risc machines (like ARM) where writing to memory is always at least two instructions 00.33.29 # [Saint]: good point. FS#11707 was in the builds I have send you as well :) 00.33.45 # <[Saint]> Aha! I'll test it now then ;) 00.34.24 # soap: just saw your results. pretty good :) did you see any flaws in movie playback or YUV blitting during test_fps? 00.34.34 # kugel: ok, thanks 00.34.59 # <[Saint]> Buschel: Working as expected here on 2 iPod Colours. 00.35.00 # Anyway, it's not an issue at all if the pcm buffer is not on the low watermark :) 00.35.54 # kugel: btw: Increasing the stack size solved the native arm threads crash issue 00.35.54 # <[Saint]> I'd be damn surprised if it worked on the Nano1G, Colour, but not the 4G. 00.36.01 # but gcc has some atomic data types for some architectures to get around without locks from other libraries. I don't know supported they really are though 00.36.06 # Buschel, test FPS is too fast to see much, no gross flaws. I spent about 20 minutes booting back and forth between patched and stock firmware and watching Elephant's Dream, and was unable to notice any subtle artifacts. Give me a second nano 1G if you want a definitive statement. 00.36.25 # kugel: on ARM they are emulated in software 00.36.43 Join Strife89TX [0] (~cstrife89@adsl-80-195-64.mcn.bellsouth.net) 00.36.47 # ah, so they suck :) 00.36.47 # The Nano 1G's screen is so amazingly narrow in the useable viewing angle that it would be hard to distinguish subtle errors. 00.36.53 # kugel: On Intel the atomic operations use the corresponding cpu instructions 00.37.15 # Buschel, thanks for your work. GLAD to support your return to PP ipod work!!! 00.37.16 # kugel: The new Cortex A9 added those missing atomic instructions 00.37.28 # <[Saint]> soap: It's that 3~4mm thick piece of clear plastic on the fron of 'em...sucks. 00.37.36 # <[Saint]> *front 00.37.41 # Otherwise SMP would suck a lot on those... 00.38.08 # SMP isn't what we need to worry about, concurrency is 00.38.11 # New commit by 03Buschel (r28932): Submit FS#11707. Add line out power off to iPods nano1G, color and 4G. 00.38.14 # That was the article on the arm blog I posted earlier 00.38.19 # I don't think so Saint, the off-axis contrast is horrible and reveals lots of encoding artifacts otherwise hidden well by ffmpeg. 00.39.31 # SMP only adds true parallelism, but concurrency always had that in mind 00.39.56 # Yes, of course (though I like to mix those two up ;)) 00.40.13 # r28932 build result: All green 00.40.31 # Though this is a no issue on real "rockbox" hardware because of the cooperative threads 00.40.38 # concurrency just means true parallelism where available, otherwise quasi-parallelism :) 00.41.33 # concurrency is a no-issue if we use our own scheduler right 00.41.37 # but we do have multi core targets with true parallism. it's just not implemented in the sim or the app 00.42.15 # So how does rockbox perform locking on those? 00.42.37 # corelocks, peterson algorithm as jhMikeS noted earlier 00.44.07 # cooperative threads alone aren't very concurrent because you know that you can't be preempted, and we abuse that fact a lot. but in some areas we can offload threads to other cores where we do need some locking 00.45.41 Quit stoffel (Ping timeout: 276 seconds) 00.47.35 # kugel: So if I look at corelock_lock(), I don't see any memory barriers in there or at least I don't see them with my limited arm assembler knowledge 00.47.54 # well, we know we can't be preempted iff we know for a fact that the code that is called doesn't preempt you :) 00.49.12 Quit n1s (Quit: Lämnar) 00.51.46 # kugel: But I better shut up, I'm not really into the arm details :) 00.52.42 # thomasjfox: you can see the peterson algorithm in the c version 00.54.13 # it's not a "memory barrier", but more generally a means to prevent multiple threads/cores enter the same critical section at the same time 00.55.51 Quit JesusFreak316 (Ping timeout: 240 seconds) 00.55.52 # kugel: Yes, I understood that. But those flags must be read/written in an atomic way, no? 00.56.10 # no 00.57.27 # does PP reorder memory access? 00.57.32 # it just requires that things be well ordered and in this case, not cacheable ram 00.57.34 # no 00.57.38 # ah ok :) 00.58.02 Quit Keripo1 (Quit: Leaving.) 00.59.41 Ctcp Ignored 2 channel CTCP requests in 11 minutes and 37 seconds at the last flood 00.59.41 # * thomasjfox just learned a lot today about the inner workings of rockbox. And there's way more to learn... 01.00.40 # so, Buschel, you saying you want more long-term testing of v03/ v04 of FS 11843? 01.00.51 # peterson uses this array for each core to get around the atomic thing 01.01.07 # IIUC 01.01.15 Join tuxifier [0] (~ha@stgt-5f7019d0.pool.mediaWays.net) 01.01.55 # <[Saint]> Buschel: In case you missed it earlier, yes, Line Out works as expected on iPod Colour and iPod Nano (I have two of each to test on). 01.02.14 # <[Saint]> I'd be very surprised if iPod 4th Gen behaved any differently. 01.02.44 # hi everyone sansa clip+ with rockbox 3.7.1 doesn't recognize tanscend 16gb microSD card - am I missing sth? 01.02.55 # soap: I hopefully did not mess up my comments -> I was talking of FS#11830 (ATA) reagrding long-term testing 01.03.23 # [Saint]: yes, that's why I already submitted the patch :) 01.03.28 Join kugel_ [0] (~kugel@e178061098.adsl.alicedsl.de) 01.03.42 # <[Saint]> Hmmmmm, whoops. 01.03.45 # ofw scans it without any problems 01.03.50 Quit kugel (Disconnected by services) 01.03.52 # <[Saint]> Sorry Buschel, I missed that commit. 01.03.59 # no prob ;) 01.04.01 # <[Saint]> Or, my notify script did, rather. 01.04.09 Quit ender` (Quit: All power corrupts, but we need electricity.) 01.04.24 # hi everyone sansa clip+ with rockbox 3.7.1 doesn't recognize tanscend 16gb microSD card - am I missing sth? 01.04.33 Quit kugel_ (Remote host closed the connection) 01.04.41 Join kugel [0] (~kugel@rockbox/developer/kugel) 01.04.44 # <[Saint]> I know it's just dumd luck that you've been working on the targets I own, but I appreciate it nonetheless Buschel. 01.04.47 # <[Saint]> Thankyou. 01.04.54 # <[Saint]> *dumb 01.06.11 # there's an even weirder lock in core_sleep/wake so wakeups aren't missed, it's sort of a lock but not quite 01.06.30 # can anyone even read me? 01.06.43 # tuxifier: there was some change to improve microSD card handling just a few days ago. Please try a current build 01.07.19 # pixelma: ah all right will do - thanks 01.07.29 # soap: now I got you... on nano1G there is no testing of FS#11843 v04 needed. from theory v04 should not have issues on iPod nano1g, on iPod color the LCD IF might be too slow to transfer the last pixel before the next has been converted 01.09.28 Quit kevku (Ping timeout: 260 seconds) 01.10.16 Join kugel_ [0] (~kugel@g231105073.adsl.alicedsl.de) 01.10.38 Quit kugel (Disconnected by services) 01.10.42 # FIFO wait can also be removed for nano2G YUV blitting as the LCD IF is (now) fast enough as well. 01.11.42 # would give +19% on nano2G and +10% on nano1G/color 01.11.51 # (for YUV) 01.13.32 Quit kugel_ (Remote host closed the connection) 01.13.42 Join kugel [0] (~kugel@rockbox/developer/kugel) 01.14.27 # jhMikeS: Speaking of core_sleep(), that's exactly what I need now. Thanks for your patience, the same to kugel 01.15.25 # core_sleep() is what calls wait_for_interrupt() 01.15.53 # ;) 01.16.13 # pixelma: current build installed - rockbox info says HD1 not present 01.16.33 # jhMikeS: are these nops in core_sleep() really only needed for the beast, or are they needed on all armv6+ (or even v5+)? 01.17.10 # could this be a settings thing? 01.17.47 # tuxifier: hmm, I don't have a Clip+ so wasn't sure if it fixed the problems for everyone. I think I saw reports of it in the forum but no details 01.17.50 # yes, 11830 will be long-term tested by me on the Nano. Need it tested on nano2g or Video? Regardless I _was_ asking about 11843 and was curious why you submitted v02 and not v03. 01.18.12 # kugel: not sure about that but if they pipeline, they might execute instructions after the wfi 01.18.32 # I'd have to say "most likely yes" really 01.19.02 # all arms do pipelining, just the length of the pipe differs (larger with later versions) 01.19.13 # tuxifier: I don't think that it could be settings related. Is there a difference if you plug the card while Rockbox is already running or when it is already inserted while booting? 01.19.30 # soap, Buschel: as expected, stock r28914 won't even rolo on my device, but v07 works without a hitch 01.19.32 # even on PP, if a wake instruction immediately follows a sleep instruction, the processor fails to sleep 01.19.53 Quit thomasjfox (Remote host closed the connection) 01.21.16 Part tuxifier ("Konversation terminated!") 01.21.20 # soap: testing 11830 on Video is reasonable, nano2g uses different code. v02 was submitted as this is the safe version. v03 can result in flaws if the YUV-conversion of pixels takes less time than emptying the FIFO to LCD. this could theoretically happen on the iPod color display (even though Saint did not see such flaws in his tests) 01.21.34 # maraz: good! :) 01.22.50 Join kugel_ [0] (~kugel@e178061161.adsl.alicedsl.de) 01.22.59 # * [Saint] wonders what type of black magic makes heat aggrivate this issue 01.23.16 # <[Saint]> fucking...voodoo. 01.23.33 # I would say if there are no new bug reports on non-nano1g targets within 1 week I will submit FS#11830 v07. 01.23.51 Quit kugel (Ping timeout: 240 seconds) 01.23.53 # <[Saint]> And, why some Nanos are totally cool with it, and others go on strike in various amusing ways. 01.23.56 # heating a chip makes everything noiser, so if you're running something too fast such that it doesn't have enough time to settle down between cycles, heating it will make that worse 01.24.13 # so you'll be more likely to get a 0 when you wanted a 1 01.24.47 # <[Saint]> I also wonder why your Nano1G fucks out at 76MHz, and I have one that tops at 80, and one that tops at 100. 01.25.22 # <[Saint]> Err, so, you're *works* at 76MHz, and messes up at 80, correct? 01.25.29 # <[Saint]> s/so/sorry/ 01.25.37 Quit liar (Quit: Leaving) 01.26.08 # * [Saint] noe sees he has confuses saratoga and soap again...dammit. 01.26.15 Quit kugel_ (Changing host) 01.26.15 Join kugel_ [0] (~kugel@rockbox/developer/kugel) 01.26.16 # <[Saint]> *now, argh. 01.26.21 Nick kugel_ is now known as kugel (~kugel@rockbox/developer/kugel) 01.27.14 Quit kugel (Remote host closed the connection) 01.27.22 Join kugel [0] (~kugel@rockbox/developer/kugel) 01.27.51 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 01.28.01 # when you bump it up to 100 do you keep all the other clocks the same or change the dividers somewhere? 01.28.26 # <[Saint]> It's a patch from Buschel, so I assume all is correct ;) 01.28.32 # <[Saint]> I run it at 24/100 01.28.56 # <[Saint]> I'm aware that punching in a number doesn't change the frequency 01.29.48 # Buschel, but you commited v02 of the LCD/YUV patch, not v02 of the NanoGlitch patch... I'm totally confused now. 01.30.02 # <[Saint]> It's interesting...it must be quite rare for those chips to tolerate 100MHz. 01.30.16 # Saint: did soap ever try his at 100MHz? it may still work at that 01.30.18 # <[Saint]> Only 1 of my devices has ever clocked that high (Nano1G) 01.30.31 # As how can there be bug reports on non-nano targets for the DMA patch? 01.30.37 # <[Saint]> saratoga: I believe not, though I am unsure. 01.30.43 # maybe MHz fly off in little bit when it runs too fast? over time, not enough MHz left 01.31.07 # soap: ok, let me be more precise: FS#11830 (ATA) needs at least 1 week of testing before I will submit it. 01.31.20 # [Saint], Mine works at 76 w/o buschel's DMA work. Mine works at 80 with the DMA fix. 01.31.36 # <[Saint]> will it clock to 100? 01.31.41 # <[Saint]> have you ever tried? 01.32.01 # no, I have not tried to 100 01.32.10 # soap: FS#11843 -> v02 was submitted due to the reasons stated above (stable for all targets, as iPod color's LCD might be too slow) 01.32.11 # <[Saint]> if it won't, it will just fail to find rockbox.ipod (most common error I found) 01.32.26 # * jhMikeS puts on his Ted Stevens thinking cap in hopes he can lend insight 01.32.39 # Congressman Ted Stevens? 01.33.07 # Buschel, I will make my nano running 11830 v07 my only target for the next week. 01.33.12 # <[Saint]> soap: It might be worth trying it at 24/100...my Nano1G clocked at those unboosted/boosted sppeds kicks the ass of the stock SVN Nano1G. 01.33.20 # <[Saint]> like, really kicks its ass. 01.33.43 # [Saint], it very well might, as the issue appears to be memory not cpu. 01.33.48 # soap: it is reasonable to wait for non-nano1g bug reports as v07 changes DMA code for all PP502x targets. 01.34.05 # <[Saint]> battery life, response, GUI, everything feels a lot nicer. 01.34.12 # Buschel, but who will be testing on non-nano targets? ;) 01.34.22 # <[Saint]> battery life is markedly improved at those clocks also. 01.34.53 # [Saint], after this issue is fixed I very well might play w/100. 01.34.57 # soap: I will have my iPod Video up a few times, maybe Saint uses his color a bit? 01.34.59 # :) 01.35.08 # but since my Nanos are my exercise iPods they don't need great battery life. 01.35.12 # i wanted to make the some of the PP devices use 24Mhz as the low clock for a while now 01.35.25 # my 2GB nano1g is still my primary DAP. :) 01.35.31 # <[Saint]> Buschel: I have two of them now, and it's my new primary player (well, the CF'd one is). 01.35.35 # probably worthwhile on everything with a smallish screen 01.35.40 # hey, any ideas why the battery life on Sansa Fuze is so low? 01.35.48 # nope 01.36.14 # with OF I get ~24hrs, RB gives ~5hrs 01.36.36 # you should get about 12 hours IIRC 01.36.43 # how are you testing? 01.37.05 # <[Saint]> Buschel: Which build is it you'd like me to continue testing? Or, can you please apply the patch in question to a current build, and I will gladly test long-term on iPod Colour(s). 01.37.26 # <[Saint]> (No rush, though) 01.37.33 # saratoga: hmm, no test, just normal usage 01.37.47 # saratoga: I might try battery benchmark 01.37.50 # [Saint], doing so already for you 01.38.01 # you're probably underestimating it, or else you have a bad battery and have badly overestimated teh OF 01.38.12 # <[Saint]> soap: Thanks. 01.38.16 # [Saint], soap: the 100 MHz clock on PP's does not increase the runtime. the better runtime is caused by the 24 MHz unboosted clock. the 100 MHz boost combined with gui boost (FS#8668) is just compensating for a slow UI when purely using 24 MHz. 01.38.41 # [Saint]: its all in the binaries we have exchanged today :) 01.38.50 # Buschel, yes. I'm a MP3 user, so 24 might help a bit. 01.39.18 # soap: a lot. -6 MHz clock = -1.5 mA 01.39.33 # we'll talk in one week. 01.39.35 # <[Saint]> Ah, yes. I was not sure exactly which of the magic tricks in the patch you gave me really gave the battery savings, or if it was a combination of them all. 01.40.09 # <[Saint]> I wish that both of my 1G Nanos would run at 100MHz, though 01.40.27 # maybe they both will with the ata work 01.40.47 # <[Saint]> Buschel: Is it quite common for those PP chips to not clock that high? 01.40.49 # inability to find rockbox.ipod is a symptom I currently have with stock SVN when hot. 01.41.45 # <[Saint]> Ah, right. That was what I was getting when I put the 24/100/gui boost patch on one Nano1G, but not the other. 01.42.03 # <[Saint]> I eventually trimmed the patch down, and it didn't like the 100MHz clock. 01.42.07 # [Saint]: only few tried yet. I know of some Video's which run @100 MHz or higher and your nano1g 01.42.17 Quit Strife89TX (Quit: Shutting off TX) 01.42.31 # maybe they'd all run at 100 post ATA work. 01.42.38 # <[Saint]> they are rated for 80MHz, is this correct? 01.43.11 # but why is 24/100 needed, is 24/80 not responsive feeling enough? 01.43.12 # saratoga: I don't think so, been using RB for a week only and the difference is quite dramatic, I mean, you can actually see the battery % going down if you stare at the thing for a few min 01.43.59 # <[Saint]> soap: 24 feels a bit low without the GUI boosting, but 24/80 is fine. 01.44.01 # saratoga: but considering OF refused to work, RB is a plus in so many other ways 01.44.05 # eRivas, that just means RB's battery meter is more responsive than the Original Firmware's battery meter. It need not be evidence of anything else. 01.44.51 # lol@soap 01.45.18 # http://cleansoap.org/iles/SaintColorAtaV07.zip and why you laughing at me jhMikeS? 01.45.43 # <[Saint]> thankyou, soap. 01.45.50 # http://cleansoap.org/files/SaintColorAtaV07.zip <-- oops bad link 01.46.07 # [Saint]: from product briefs -> PP5020 max 80 MHz, PP5022 max 100 MHz 01.46.22 # [Saint]: nano1G and Video use 5021 :) 01.46.43 # soap: just wonder what that meant. if it would last a long time it you shouldn't be able to *see* the meter dropping consistently 01.46.43 # [Saint]: http://www.rockbox.org/wiki/PortalPlayer 01.47.14 # jhMikeS, to *see* it drop one would need to have the hog of a backlight on! ;) 01.47.16 # soap: 24/80 is fast enough, 24/100 is just faster ;) 01.47.49 # <[Saint]> Buschel: Does boosting at 100MHz save like *no* power at all (I thought maybe because of decreased time to complete CPU intensive tasks?), or is it am amount that is practically immeasurable and not worth it when compared to the saving that 24MHz clock offers? 01.48.26 # [Saint]: it should save no power 01.48.29 # soap: that happens yes but them it should go back up after it goes off 01.48.34 # <[Saint]> Hmmm. 01.49.03 # [Saint]: but on iPod Video you can watch movies with reasonable framerates -- that's why I use this clock 01.50.15 # <[Saint]> rather lucky to get one that clocks that high, then. I'm glad at least one of mine does. 01.50.20 # wow, the PluginMpegplayer performance numbers for the Video are way out of date. 01.50.54 *** Saving seen data "./dancer.seen" 01.51.34 # soap, [Saint]: you update PluginMpegplayer fps for color and nano1g :) should be faster now 01.51.49 # you *could* update.... 01.52.22 # * [Saint] fires up FFmpeg 01.52.25 # soap: the iPod Video should not be any faster now... 01.52.38 # use the provided files for testing, [Saint], no other will be comparable. 01.52.47 # [Saint]: just use the videos from the wiki page. 01.53.29 # <[Saint]> Hmm, is there one file that exists anywhere with all common test files? 01.53.39 # <[Saint]> I've been meaning to grab them, but never have. 01.54.10 # http://www.rockbox.org/wiki/PluginMpegplayer#Sample_Videos 01.54.59 # <[Saint]> where are the codec sample files located? I should probably grab those also. 01.55.47 # http://download.rockbox.org/test_files/ 01.57.26 # * [Saint] decides to wait to DL all of those test files. 01.57.44 # <[Saint]> I will, but not until my faster connection is restored again. 01.58.00 # <[Saint]> It would take all day to get them all on this connection. 01.59.36 # * Buschel needs to update PluginMpegplayer for nano2g as well 02.02.12 # * [Saint] still has a hard time believing how much the Nano2G got optimized... 02.02.29 # <[Saint]> didn't it end up at around +~25% 02.02.35 # <[Saint]> more? 02.02.41 # <[Saint]> *250 rather 02.03.08 # <[Saint]> (regarding LCD) 02.03.40 # no, maybe half of it. ~ 10-15% faster for movie playback 02.04.04 # <[Saint]> I meant the LCD in general. 02.04.44 # <[Saint]> you pushed some pretty crazy optimazations to Nano2G LCD in the past weeks. 02.05.39 # oops, didn't see the last comments. it was 3x for RGB and 2x for YUV on nano2g 02.05.52 # (for LDS type) 02.06.10 # <[Saint]> yes, very nice. 02.07.37 # and from we saw today in your measurements I expect there is a (yet hidden) clock divider active for the color lcd... 02.07.57 # could easily be a factor of 2. 02.08.31 # <[Saint]> Well, I'm happy to keep testing as long as I'm around. 02.08.57 # <[Saint]> And, now you know I have a Colour as well. ;) 2, rather 02.15.03 # do elements declared down a .wps file have priority over those declared above? 02.15.28 # <[Saint]> yes. 02.15.45 # <[Saint]> well, not declared, but called. 02.15.47 Quit Gareth (Ping timeout: 265 seconds) 02.15.53 # yeah, that 02.16.06 # sorry, too much css for me, lol 02.16.29 Join Gareth [0] (~gareth@www.wiked.org) 02.17.31 # <[Saint]> it pays to declare everything (all your %xl's, additional fonts, etc.) in one lump at the beginning of the WPS. 02.17.42 # <[Saint]> It's cleaner, and saves some hassle. 02.19.22 # <[Saint]> but to simplify: if %xd(foo) is called on the line above %xd(bar) then foo will be drawn before bar. 02.19.36 # <[Saint]> How noticable that effect is may vary, though. 02.24.43 # [Saint]: do you have an iPod Photo as well? 02.28.25 # well, images will be drawn over the previous one, so if foo and bar overlap bar wil be visible 02.35.47 # <[Saint]> Buschel: Unfortunately no. 02.36.08 # <[Saint]> I have a feeling that Strife89 might have a Photo though Buschel 02.37.41 # amiconn: would be great if you could retest test_fps on your iPod Photo (assumption based on LcdFrameRate Wiki). when comparing the latest results on iPod color to your last measurements on iPod Photo there seem to be differences in the LCD bridge configuration between both (similar to the effect seen in the nano2g). do you have any idea where to search for the register that might control... 02.37.43 # ...this clock divider? 02.38.48 # amiconn: the iPod Photo is a lot faster than the iPod Color in terms of LCD transfer speed. 02.39.52 # aren't the color and photo the same? 02.41.20 # saratoga: the speed is significantly different. maybe this is just a default config of some register... 02.41.35 # no i mean aren't they the same device? 02.42.49 # hmm, not sure. for rockbox it is the same build, but I do not know whether the hardware differs a bit... 02.43.27 # i think they're the same device, but its possible theres different revisions 02.43.53 # IPL does not recognize different versions. http://ipl.derpapst.eu/wiki/Generations#iPod_Photo_.28Photo.29_.2F_Color_iPod_.28Color.29 02.44.45 # Now I know Rockbox surpassed them as source of iPod knowledge, but their "generations" page was long considered gospel. 02.45.00 # if LcdFrameRate is correct the speed is that different (by a factor of > 1.5) that there should be at least a different LCD or LCD IF config 02.45.24 # raw LCD is slower but YUV is faster? 02.45.36 # (in [Saint]'s test (Hayden)) 02.46.17 # YUV is faster, but nearly identical to RGB 02.46.44 # wikipedia says that the "Photo" was the name of the device when it was sold alongside the 4th Gray. It was renamed to "iPod with Color Display" when the Gray was dropped from the lineup. Aka Ipod Color 02.47.17 # <[Saint]> http://en.wikipedia.org/wiki/List_of_iPod_models lists the release dates, and potential differences. 02.47.27 # <[Saint]> some had firewire/some didn't, etc. 02.47.47 # no 02.48.12 # that's poorly worded. "Firewire AND USB" there was no OR. 02.48.22 # you can use firewire or USB. 02.48.32 # they contain firewire AND usb capabilities. 02.49.19 # It isn't that some have one and some have the other. 02.49.37 # soap: btw, I am surprised of the MpegPlayer speed up for nano1g. more than I expected 02.49.48 # it was an OLD prior as well. 02.50.36 # jhMikeS, it would be nice if show FPS in mpegplayer persisted over the movie. You have to watch very closely to catch the fps update in the split second it's onscreen before the movie overwrites it. 02.50.57 # <[Saint]> The Colour seems to be what the Photo turned into, and the Photo was a 4Th Gen with a colour LCD slapped on it. The Colour has the same highest capacity, but lower lowest capacity than the photo, and no "middle" capacity like the Photo either. 02.51.43 # the video could be clipped out from that area but then the FPS would run a little high on tests 02.52.19 # [Saint], mid-model bump in capacity is not unusual for them. My summary of the Photo wikipedia page from six minutes ago fits your presented evidence as well as doesn't require a supposed version 4.5 which is undocumented anywhere in the literature. 02.52.49 # jhMikeS, could the FPS display simply be synced to the mpeg frames? 02.53.16 # (causing a little loss in FPS during tests) 02.53.23 # ok, I really need some sleep now. thanks for all your support! good night :) 02.53.30 Quit Buschel (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]) 02.53.31 # <[Saint]> o/ 02.54.33 # sure, that would act like clipping it. I suppose it doesn't matter too much so long as the conditions are always the same between tests 02.55.39 # from where does RB pull the setting for rockbox failsafe, the .wps file of that name is a dummy 02.56.59 # soap: I've wanted to fix that too rather than just do some test mode where you don't see stats until it's finished 03.00.39 Quit kugel (Remote host closed the connection) 03.03.43 # a tiny box with nothing but the FPS would probably work. the rest is that info just debugging stuff. 03.03.58 # yea 03.05.37 # guys, what is the absolute path to a file in the microSD card? 03.07.56 # <[Saint]> /foo/bar/baz. is it not? 03.08.43 # <[Saint]> or similar, I don't remember it being rocket science. 03.09.03 # <[Saint]> why not just make a playlist from the device and save it to disk, then take a look at it? 03.09.56 # good idea 03.10.30 # I have to put playslists on /playlist, right, for them to appear in the catalog? 03.14.06 # <[Saint]> No 03.14.29 # UNIX or DOS paths? 03.14.50 # <[Saint]> It can be any Dir, just put "playlist catalog directory: /Path/to/playlist/catalogue" in your .cfg file 03.15.03 # they seem to work both, at least for relative paths 03.22.06 Join telliott [0] (~Tim@d27-96-170-180.evv.wideopenwest.com) 03.31.30 Quit GeekShadow (Quit: The cake is a lie !) 03.32.20 # soap: Oh, but why should I do it? I mean, does anyone even really care? If you can't read it, it means it's pretty darn fast already so who's complaining? 03.33.32 Quit JdGordon (Ping timeout: 265 seconds) 03.41.56 Quit telliott (Read error: Connection reset by peer) 03.46.02 Quit BlakeJohnson86 (Quit: Leaving.) 03.46.34 Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 03.46.40 Join telliott [0] (~Tim@d27-96-170-180.evv.wideopenwest.com) 03.50.58 *** Saving seen data "./dancer.seen" 04.22.16 DEBUG EOF from server (Connection timed out) (snapshot: netstuff.c line 545) 04.22.16 *** Cleanup 04.22.16 *** Cleanup 04.22.16 *** No seen item changed, no save performed. 04.22.16 *** Exit 04.22.18 *** Started Dancer V4.16 04.22.18 *** Connected to irc.freenode.net on port 6667 04.22.18 *** Logfile for #rockbox started 04.22.21 Mode "logbot :+i" by logbot 04.22.25 *** Server message 501: 'logbot :Unknown MODE flag' 04.22.25 Join logbot [0] (~rockbox@giant.haxx.se) 04.22.25 Join telliott [0] (~Tim@d27-96-170-180.evv.wideopenwest.com) 04.22.25 Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 04.22.25 Join Gareth [0] (~gareth@www.wiked.org) 04.22.25 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 04.22.25 Join parafin [0] (parafin@paraf.in) 04.22.25 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 04.22.25 Join CaptainKewl [0] (~captainke@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 04.22.25 Join mortalscan [0] (~mortalsca@109.169.55.155) 04.22.25 Join B4gder [0] (~daniel@rockbox/developer/bagder) 04.22.25 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 04.22.25 Join krazykit [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) 04.22.25 Join GuySoft [0] (guy@bzq-79-183-3-236.red.bezeqint.net) 04.22.25 Join Horscht [0] (~Horschti@xbmc/user/horscht) 04.22.25 Join eRivas [0] (~je@190.150.0.99) 04.22.25 Join AndyI [0] (~pasha_int@212.14.211.84) 04.22.25 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.22.25 Join user890104 [0] (~Venci@6bez10.info) 04.22.25 Join sasquatch [0] (~username@92.116.109.239) 04.22.25 Join AlexP [0] (~alex@rockbox/staff/AlexP) 04.22.25 Join anewuser [0] (anewuser@unaffiliated/anewuser) 04.22.25 Join [Saint] [0] (S_a_i_n_t@203.184.0.89) 04.22.25 Join elcan [0] (user36@pr0.us) 04.22.25 Join crwl [0] (~crwlll@dsl-jklbrasgw1-fe8edf00-29.dhcp.inet.fi) 04.22.25 Join Kitar|st [0] (~Kitarist@89.142.76.239) 04.22.25 Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek) 04.22.25 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 04.22.25 Join niekie [0] (~niek@CAcert/Assurer/niekie) 04.22.25 Join Dreamxtreme [0] (~Dre@92.30.156.129) 04.22.25 Join amiconn [0] (quassel@rockbox/developer/amiconn) 04.22.25 Join pixelma [0] (quassel@rockbox/staff/pixelma) 04.22.25 Join Barahir_ [0] (~jonathan@frnk-4d0094ae.pool.mediaWays.net) 04.22.25 Join mikroflops_ [0] (~yogurt@h-34-71.A238.priv.bahnhof.se) 04.22.25 Join saratoga [0] (9803c6dd@gateway/web/freenode/ip.152.3.198.221) 04.22.25 Join merbanan [0] (~banan@c-94-255-218-107.cust.bredband2.com) 04.22.25 Join tempname [0] (generic@server1.unitedservers.de) 04.22.25 Join pjm0616 [0] (~user@114.200.203.243) 04.22.25 Join Guest88817 [0] (~henk@henk.hnjs.ch) 04.22.25 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 04.22.25 Join timccc [0] (~timccc@112.166.15.141) 04.22.25 Join xavieran [0] (~xavieran@ppp118-209-39-163.lns20.mel4.internode.on.net) 04.22.25 Join Xerion [0] (~xerion@54196686.cm-5-2b.dynamic.ziggo.nl) 04.22.25 Join YPSY [0] (~ypsy@geekpadawan.de) 04.22.25 Join soap [0] (~soap@rockbox/staff/soap) 04.22.25 Join tmzt [0] (~tmzt@76.211.0.152) 04.22.25 Join FOAD [0] (~dok@83.161.135.61) 04.22.25 Join preglow [0] (thomj@tvilling2.pvv.ntnu.no) 04.22.25 Join Stummi [0] (Stummi@rockbox/developer/Stummi) 04.22.25 Join bzed [0] (~bzed@devel.recluse.de) 04.22.25 Join jfc^2 [0] (~john@dpc6682208002.direcpc.com) 04.22.25 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 04.22.25 Join blast007 [0] (~blast007@bzflag/developer/Blast) 04.22.25 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 04.22.25 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 04.22.25 Join GodEater [0] (~bibble@rockbox/staff/GodEater) 04.22.25 Join thegeek [0] (~nnscript@132.108.34.95.customer.cdi.no) 04.22.25 Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) 04.22.25 Join jordan` [0] (~jordan@jem75-13-78-235-252-137.fbx.proxad.net) 04.22.25 Join literal [0] (hinrik@w.nix.is) 04.22.25 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 04.22.25 Join bug2000 [0] (~bug@unaffiliated/bug2000) 04.22.25 Join the_Kyle [0] (~kyle@71.23.64.127) 04.22.25 Join pikytcus_ [0] (~bigd@failbox.co.cc) 04.22.25 Join Galois [0] (djao@efnet-math.org) 04.22.25 Join simonrvn [0] (simon@209.128-ppp.3menatwork.com) 04.22.25 Join rvvs89 [0] (rvvs89@mussel.ucc.gu.uwa.edu.au) 04.22.25 Join chattr [0] (~mike@244.87.189.72.cfl.res.rr.com) 04.22.25 Join Dhraakellian [0] (~ntryon@cpe-67-240-248-41.rochester.res.rr.com) 04.22.25 Join aevin [0] (eivindsy@unaffiliated/aevin) 04.22.25 Join Torne [0] (torne@rockbox/developer/Torne) 04.22.25 Join scorche|1h [0] (~scorche@rockbox/administrator/scorche) 04.22.25 Join m|c [0] (~mtq@h1439481.stratoserver.net) 04.22.25 Join ved [0] (ved@ddsbox.co.cc) 04.22.25 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 04.22.25 Join n17ikh [0] (~n17ikh@c-68-59-25-51.hsd1.sc.comcast.net) 04.22.25 Join dionoea [0] (~dionoea@videolan/developer/dionoea) 04.22.25 Join jepler [0] (~jepler@emc/developer/pdpc.professional.jepler) 04.22.25 Join Guinness` [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net) 04.22.25 Join rasher [0] (~rasher@rockbox/developer/rasher) 04.22.25 Join MagusG [0] (magusg@c-71-59-57-46.hsd1.ga.comcast.net) 04.22.25 Join simabeis [0] (~simabeis@lobmenschen.de) 04.22.25 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 04.22.25 Join linuxguy3 [0] (~timj@adsl-75-57-165-250.dsl.emhril.sbcglobal.net) 04.22.25 Join fred_2 [0] (fred@ircop.efnet.at) 04.22.25 Join kkit|sh [0] (krazykit@silenceisdefeat.com) 04.22.25 Join scorche [0] (~scorche@rockbox/administrator/scorche) 04.22.25 Join knittl [0] (~knittl@unaffiliated/knittl) 04.22.25 Join avacore^ [0] (~avacore@1008ds1-rdo.0.fullrate.dk) 04.22.25 Join Bushmills [0] (~Bushmills@scarydevilmonastery.net) 04.22.25 Join Zambezi [0] (Zulu@unaffiliated/zambezi) 04.22.25 Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) 04.22.25 Join Utchy [0] (~Utchy@rps6752.ovh.net) 04.22.25 Join Rondom [0] (~rondom@lvps178-77-79-47.dedicated.hosteurope.de) 04.22.25 Join TBCOOL [0] (~tb@c-3c3671d5.09-42-73746f22.cust.bredbandsbolaget.se) 04.22.25 Join Slasheri [0] (miipekk@rockbox/developer/Slasheri) 04.22.25 Join Bawitdaba [0] (~Sphinx@cpe-74-70-40-135.nycap.res.rr.com) 04.22.25 Join maraz [0] (maraz@kapsi.fi) 04.22.25 Join ThomasAH [0] (~thomas@aktaia.intevation.org) 04.22.25 Join Battousai [0] (~bryan@gentoo/developer/battousai) 04.22.25 Join Loto [0] (~nfs@xbmc/user/Loto) 04.22.25 Join zu_ [0] (~zu@ks355000.kimsufi.com) 04.22.25 Join part [0] (part@62.220.235.11) 04.22.25 Join burn [0] (~burn@cl-1079.bru-01.be.sixxs.net) 04.22.25 Join Hadaka [0] (~naked@naked.iki.fi) 04.22.25 Join ack [0] (~ack@mingbai.org) 04.22.25 Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) 04.22.25 Join powell14ski [0] (~powell14s@c-67-177-228-132.hsd1.co.comcast.net) 04.22.25 Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) 04.22.25 Join yosafbridge [0] (~yosafbrid@li125-242.members.linode.com) 04.22.25 Join lostlogic [0] (~lostlogic@rockbox/developer/lostlogic) 04.22.25 Join jobec [0] (paulus@kapsi.fi) 04.22.25 Join CIA-7 [0] (~CIA@208.69.182.149) 04.22.25 Join amee2k [0] (~thomas@ve504.cugnet.net) 04.22.25 Join @ChanServ [0] (ChanServ@services.) 04.22.25 Join iq [0] (~iq@unaffiliated/iq) 04.22.25 Join alexbobP [0] (~alex@adsl-75-63-1-71.dsl.austtx.sbcglobal.net) 04.22.25 Join Kohlrabi [0] (~kohlrabi@kohlio.de) 04.22.25 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 04.22.57 Join Barahir [0] (~jonathan@frnk-590f4f6e.pool.mediaWays.net) 04.26.08 Quit Barahir_ (Ping timeout: 240 seconds) 04.30.25 Quit the_Kyle (Quit: Leaving.) 04.48.06 Quit eRivas (Quit: Saliendo) 04.53.16 Quit amiconn (Disconnected by services) 04.53.17 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.53.31 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.53.32 Quit pixelma (Disconnected by services) 04.53.34 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.53.35 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.54.14 Join JdGord [0] (~jonno@124-149-188-197.dyn.iinet.net.au) 05.09.38 Join the_Kyle [0] (~kyle@71.23.64.127) 05.19.22 Quit elcan (Ping timeout: 240 seconds) 05.20.08 Join elcan [0] (user36@pr0.us) 05.29.56 Join guymann [0] (~charles@66-159-148-95.adsl.snet.net) 05.29.56 Quit Horscht (Quit: Verlassend) 05.37.22 Quit Keripo (Quit: Leaving.) 05.49.23 Quit telliott (Ping timeout: 246 seconds) 06.22.19 *** Saving seen data "./dancer.seen" 06.34.00 Quit Loto (Quit: Loto) 06.50.46 Join Loto [0] (~nfs@S01060012171a84e3.no.shawcable.net) 06.50.46 Quit Loto (Changing host) 06.50.46 Join Loto [0] (~nfs@xbmc/user/Loto) 07.00.27 Join JdGordy [0] (~jonno@58.104.46.46) 07.04.37 Quit JdGord (Ping timeout: 260 seconds) 07.12.44 Join froggyman [0] (~seth@98.115.0.7) 07.12.44 Quit froggyman (Changing host) 07.12.44 Join froggyman [0] (~seth@unaffiliated/froggyman) 07.16.11 Quit CaptainKewl (Ping timeout: 255 seconds) 07.16.12 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 07.19.32 Quit elcan (Read error: Operation timed out) 07.24.04 Quit JdGordy (Quit: Bye) 07.27.40 Join elcan [0] (user36@pr0.us) 07.28.11 Quit Loto (Quit: Loto) 07.31.26 Join Loto [0] (~nfs@xbmc/user/Loto) 07.33.10 Quit elcan (Ping timeout: 276 seconds) 07.33.23 Join elcan [0] (user36@pr0.us) 07.45.11 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 08.11.32 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 08.12.51 Join feisar- [0] (jljhook@irkki.fi) 08.22.20 *** Saving seen data "./dancer.seen" 08.48.58 Quit elcan (Read error: Connection reset by peer) 08.53.45 Quit rasher (Quit: leaving) 08.55.25 Join ender` [0] (krneki@foo.eternallybored.org) 08.55.37 Join elcan [0] (user36@pr0.us) 08.58.54 Quit elcan (Read error: Connection reset by peer) 08.58.59 Quit BHSPitMonkey (Ping timeout: 260 seconds) 09.00.38 Join elcan [0] (user36@pr0.us) 09.11.23 Quit Judas_PhD (Ping timeout: 240 seconds) 09.25.47 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 09.26.56 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 09.27.25 Join factor [0] (~factor@75.108.68.114) 09.34.41 Join stoffel [0] (~quassel@p57B4D3C8.dip.t-dialin.net) 09.37.09 Join webguest79 [0] (~4c5595ff@giant.haxx.se) 09.40.01 # hello? 09.43.29 # nevermind, found what I was looking for. 09.43.57 Quit webguest79 (Quit: CGI:IRC (EOF)) 09.47.12 Join LinusN [0] (~linus@rockbox/developer/LinusN) 09.49.12 Quit antil33t () 09.53.20 Join antil33t [0] (~Mudkips@124-197-51-80.callplus.net.nz) 09.55.15 Join einhirn [0] (~Miranda@p54850A3E.dip0.t-ipconnect.de) 09.56.11 Quit the_Kyle (Ping timeout: 240 seconds) 09.57.22 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 10.12.12 Quit JdGordon (Quit: Leaving.) 10.12.20 Join n1s [0] (~n1s@rockbox/developer/n1s) 10.12.49 Join rasher [0] (~rasher@0x5550f5a3.adsl.cybercity.dk) 10.12.49 Quit rasher (Changing host) 10.12.49 Join rasher [0] (~rasher@rockbox/developer/rasher) 10.12.50 Join the_Kyle [0] (~kyle@71.23.64.127) 10.22.22 *** Saving seen data "./dancer.seen" 10.28.14 Quit n1s (Ping timeout: 265 seconds) 10.29.37 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 10.34.29 Join kevku [0] (~kevku@2001:7d0:0:f000::135d) 10.58.11 Quit kadoban (Ping timeout: 240 seconds) 11.14.10 Quit the_Kyle (Ping timeout: 276 seconds) 11.23.57 Quit JdGordon (Ping timeout: 250 seconds) 11.29.51 Join maxexcloo [0] (~maxexcloo@c220-239-60-101.belrs4.nsw.optusnet.com.au) 11.30.41 # Hey, I was wondering if anyone is working on an iPod Touch/iPhone port 11.30.48 # Just a question 11.30.54 Join the_Kyle [0] (~kyle@71.23.64.127) 11.31.54 Join bmbl [0] (~bmbl@dsl26-226.pool.bitel.net) 11.31.54 Quit bmbl (Changing host) 11.31.54 Join bmbl [0] (~bmbl@unaffiliated/bmbl) 11.36.59 # haven't heard about anyone 11.38.23 Join dfkt [0] (dfkt@unaffiliated/dfkt) 11.39.24 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 11.41.51 # Pity, my iPod is useless then :( 11.45.53 Join fml [0] (~chatzilla@manz-5f74a35c.pool.mediaWays.net) 11.47.04 Quit fml (Client Quit) 11.48.40 Quit maxexcloo (Quit: Leaving) 11.51.15 Quit BHSPitMonkey (Remote host closed the connection) 11.53.10 Join JdGord [0] (~jonno@58.104.46.46) 11.53.10 Join Topy44 [0] (~Topy44@g228174232.adsl.alicedsl.de) 12.05.07 # useless? I think the iPod touch is also pretty usable with OF 12.07.47 # for playing flac? But anyway - he already left and - you don't say that in a #rockbox channel ;) 12.09.00 # :p 12.13.37 Join JdGordy [0] (~jonno@124-149-188-197.dyn.iinet.net.au) 12.16.45 Quit JdGord (Ping timeout: 260 seconds) 12.17.56 Quit Kitar|st (Read error: Connection reset by peer) 12.18.01 Join Kitar|st [0] (~Kitarist@BSN-182-97-6.dial-up.dsl.siol.net) 12.22.26 *** Saving seen data "./dancer.seen" 12.22.28 Quit Kitar|st (Ping timeout: 246 seconds) 12.27.55 Join Kitar|st [0] (~Kitarist@BSN-143-105-49.dial-up.dsl.siol.net) 12.31.40 Quit TheSeven (Ping timeout: 255 seconds) 12.36.33 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 12.41.50 Quit JdGordon (Quit: Leaving.) 12.41.57 Join JdGordon| [0] (~jonno@124-149-188-197.dyn.iinet.net.au) 12.41.57 Quit JdGordon| (Changing host) 12.41.57 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 12.42.50 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.49.01 Quit Topy44 (Read error: Connection reset by peer) 12.49.17 Join Topy44 [0] (~Topy44@g228174232.adsl.alicedsl.de) 12.49.54 Quit advcomp2019 (Ping timeout: 264 seconds) 12.52.35 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 12.59.19 # . 13.00.46 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 13.10.48 Quit JdGordon| (Quit: Lost terminal) 13.11.08 Join kugel [0] (~kugel@rockbox/developer/kugel) 13.12.02 Quit simabeis (Quit: Lost terminal) 13.18.45 Quit JdGordy (Quit: Bye) 13.27.08 Join Buschel [0] (~chatzilla@p54A3AFCC.dip.t-dialin.net) 13.27.42 Join T44 [0] (~Topy44@f048206115.adsl.alicedsl.de) 13.31.00 Quit Topy44 (Ping timeout: 240 seconds) 13.37.03 Quit Buschel (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]) 13.45.37 Join bluebrother [0] (~dom@f053154058.adsl.alicedsl.de) 13.45.37 Quit bluebrother (Changing host) 13.45.37 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 13.46.01 Join Topy [0] (~Topy44@f048241024.adsl.alicedsl.de) 13.46.34 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 13.47.50 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) 13.48.12 Quit T44 (Ping timeout: 240 seconds) 13.48.13 Quit bluebroth3r (Ping timeout: 246 seconds) 14.02.28 Join DerPapst [0] (~Alexander@91-66-226-46-dynip.superkabel.de) 14.02.50 Quit LambdaCalculus37 (Quit: off to the salt mines) 14.03.01 Part the_Kyle 14.22.29 *** Saving seen data "./dancer.seen" 14.26.54 Join fml [0] (~chatzilla@manz-5f74a35c.pool.mediaWays.net) 14.28.44 # Interesting: in file.h, under certain circumstances, both the macro "close" (which expands to "sim_close") and the function "close" are declared. Such a mess! 14.30.57 # Same for lseek, fsync and read. 14.31.52 # the magic for all those functions is quite a nightmare imo 15.06.08 Join Buschel [0] (~chatzilla@p54B66FF8.dip.t-dialin.net) 15.09.30 # [Saint]: regarding FS#11820 -> the white-out of the LCD before shutting it off is still active for the iPod color. maybe the sleep() is not long enough... 15.11.44 Quit Topy (Ping timeout: 240 seconds) 15.12.11 # [Saint]: I have prepared a version with longer sleep() -> http://www.sendspace.com/file/rmnkbk 15.14.38 Join Topy44 [0] (~Topy44@f048241024.adsl.alicedsl.de) 15.22.42 Quit Buschel (Remote host closed the connection) 15.30.04 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 15.30.04 Quit bertrik (Changing host) 15.30.04 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 15.33.45 Join CaptainKewl [0] (~captainke@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 15.36.39 Quit kevku (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/) 15.41.38 # soap: out of interest, what kind of speeds you get transferring music to your nano1g? after the initial burst, i seem to cap out at about 2,8MB/s. 15.42.02 # the initial burst is the OS caching things 15.43.14 # <[Saint]> maraz: ~3MBps here (yes, after the first burst of speed from a large-ish transfer) 15.43.32 # kugel: yep 15.49.57 Quit benedikt93 (Quit: Bye ;)) 15.50.26 Join TheSeven|Mobile [0] (~theseven@rockbox/developer/TheSeven) 15.50.41 Quit TheSeven|Mobile (Client Quit) 15.51.11 Join TheSeven|Mobile [0] (~theseven@rockbox/developer/TheSeven) 15.52.27 # * TheSeven|Mobile is experiencing weird problems with his nano2g 15.52.45 # <[Saint]> such as? 15.53.58 # i'm currently on the road, listening to music and experiencing some weird issues, some of which point to playback/wps bugs, others to obscure undervolting or memory corruption glitches 15.54.30 # * [Saint] frowns at the idea of WPS bugs. 15.55.19 # <[Saint]> well, in his code anyway ;) 15.55.27 # it all started when i was at the last few seconds of the last track of a dynamic playlist (the contents of a folder), and 15.55.38 # wanted to skip back to the beginning of it 15.56.49 # i just hit the left button a dozen times, and after that the wps was still claiming to be at the last track, it said it was playing something, but there was no pcm output 15.57.25 # further navigation attempts just made the wps show question marks 15.57.38 # <[Saint]> how many tracks? 15.57.48 # <[Saint]> I'm trying it with ~1500 now 15.58.11 Join komputes [0] (~komputes@ubuntu/member/komputes) 15.58.11 # then i paused and resumed playback, and it realized that it was at the end of the playlist and stopped playback 15.58.17 # as just 42 tracks over here 15.58.55 # <[Saint]> Nice 15.59.00 # <[Saint]> Good catch. 15.59.12 # then i just entered the same folder and hit the first track, erasing the old dynamic playlist 15.59.27 # can you reproduce that? 15.59.33 # <[Saint]> yep, you've definitely discovered a bug. 15.59.39 # that would be good... 15.59.50 # <[Saint]> It will be to do with the %pE tag 16.00.03 # * TheSeven|Mobile will check if it's on flyspray when he's back home 16.00.34 # * TheSeven|Mobile thinks playback being generally buggy in that kind of corner cases is a well-known issue 16.00.57 # <[Saint]> at ~15 seconds, the WPS checks for the next track, and if it doesn't fine one...it should not be an issue. 16.01.08 # <[Saint]> apparently it always expects to find one? 16.01.27 # <[Saint]> who knows, but...it' almost certainly wasn't tested in this case. 16.01.34 # <[Saint]> it's quite obscure ;) 16.01.38 # <[Saint]> Good catch. 16.01.54 # maraz, very slow to the nano 16.02.21 # sudo dd if=/dev/sdb2 of=/dev/null bs=64K gave be 5.7MB/s FROM the nano 16.03.01 # I believe that is an ooold problem at track changes, IIRC it doesn't even have to do with %pE or %pS 16.03.03 # and 2.8 MB/s TO the nano is like 50% higher than what I would get. 16.03.28 Join simabeis [0] (~simabeis@lobmenschen.de) 16.03.59 # <[Saint]> TheSeven|Mobile: The more I look at it, there's really no logic for that tag to handle that case. 16.04.08 # <[Saint]> It always expects a next track. 16.04.32 # but now for the Weird Things(tm): when i selected that track, it started playing normally again, and i just put it away. then, some time later, at the end of a track (i don't remember if it was the first one) it started playing tracks from a completely different folder, which i hadn't even selected before during that boot 16.05.19 # <[Saint]> well, that, I *can't* explain. 16.05.26 # <[Saint]> The weirdness with the WPS I can. 16.06.30 # after some tracks i pulled it out of my pocket again to check something, and realized that the wps was showing the first track from the folder it jumped to, but the progress bar showing the time which it was currently playing 16.08.08 # then i selected a track from the folder i originally wanted to play, and it crashed with a lowlevel nand write error panic 16.08.09 # <[Saint]> No idea about that one, the other is just the weirdness with the %pE tag I think...I *think*. At %pE checks for a next track, in my code it looks for metadata and if it can't find any will display a filename....but there's no case for "no file found", and no way to add one AFAIK. 16.08.34 # <[Saint]> the "next track" logic should be aware of "no next track"...surely? 16.08.36 # after rebootingg it, i could play the very same tracks perfectly fine 16.09.10 # it's just like no metadata then, even no filename 16.09.43 # <[Saint]> pixelma: they are the same? they always expect a "next ?" 16.09.53 # also, when my brother was using it some days before, he had a complete lockup during playback, and a prefetch abort at a ram address 16.10.05 Join Buschel [0] (~chatzilla@p54A39EA5.dip.t-dialin.net) 16.10.12 # so this part of the problem might point to hardware instability 16.10.13 # if "filename" is untrue then you know it's the last track 16.10.27 # Buschel: You're the one I was looking for :) 16.10.38 # * Buschel hides away 16.11.01 # were there any nano2g boosting/power management changes since r28818? 16.11.02 # <[Saint]> pixelma: *facepalm* 16.11.12 # <[Saint]> you just gave me an idea how to fix it, thanks. 16.11.25 # or on hwcodec "not buffered yet" 16.11.31 # let me check 16.11.48 # my nano2g is currently running this build (with aafonts and hw keyclick patches), and it went nuts several times during the last days 16.11.50 Join sassi [0] (~ruedi@dslb-088-065-017-172.pools.arcor-ip.net) 16.11.51 # <[Saint]> yes, I just need to add another condition for "nothing" when there's no filename found. 16.12.04 # <[Saint]> that was kinda silly, but...it's a case that hasn't come up until now. 16.12.31 # TheSeven|Mobile: no, only LCD related stuff 16.12.47 # [Saint]: I don't think you can fix these weird issues during track change/end of track with a WPS "fix" 16.13.14 # <[Saint]> I should be able to fix this one. 16.13.18 # <[Saint]> I'll have a play. 16.14.24 # it is a code problem which I think exists since MoB or so - more or less obvious 16.16.55 Join GeekShadow [0] (~Antoine@93.21.159.10) 16.16.55 Quit GeekShadow (Changing host) 16.16.55 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 16.16.57 Quit TheSeven|Mobile (Ping timeout: 276 seconds) 16.17.29 Join TheSeven|Mobile [0] (~theseven@rockbox/developer/TheSeven) 16.20.20 # Buschel: could our power management be a bit too aggressive? 16.20.45 # I did no experience any problems so far... 16.21.25 # I'd like to report a bug but i think it might be already reported in different words 16.21.58 # on the Ipod Video 80GB playback stops after skipping lots of tracks 16.22.09 # you have you reboot the player 16.22.30 *** Saving seen data "./dancer.seen" 16.23.39 # New commit by 03Buschel (r28933): Major speedup of iPod nano 2G. Part 7: Disable reading FIFO state in YUV blitting. Speedup is +19% for YUV. 16.24.42 # * TheSeven|Mobile thinks this is similar to the problem he's experiencing... too many skipping activity during rebuffering and playback will lock up, sounds like a race condition 16.25.54 # r28933 build result: All green 16.26.03 # yes sounds like it 16.26.34 # ok i'll report it 16.30.42 # * TheSeven|Mobile wonders if linuxstb found time to look into the ipod classic port 16.32.44 # * Buschel experienced something similar yesterday on his iPod Video 30GB (playback frozen after several skip forwards) 16.35.50 # opened a task 16.35.57 # i've seen that before, i think its a playback.c bug 16.37.23 Part LinusN 16.46.41 # New commit by 03Buschel (r28934): Submitted the wrong file with r28933. 16.48.36 # r28934 build result: All green 16.50.11 Quit Buschel (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]) 16.51.22 # <[Saint]> TheSeven|Mobile: I have a feeling I'm able to "fix" that issue with the %pE tag, or at least create conditional statements that avoid the issue...but I need to basically completely re-write the conditional statements for metadata/file display in that theme, which will be a real bitch. 16.51.40 # <[Saint]> I'll have a look at it lunchtime tomorrow, I'm far too tired presently. 16.51.48 # <[Saint]> Thanks for bringing it to my attention. 16.59.43 Quit sassi (Remote host closed the connection) 17.00.08 Join CaptainKwel [0] (~captainke@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 17.00.40 Quit CaptainKewl (Ping timeout: 250 seconds) 17.28.11 Quit factor (Ping timeout: 240 seconds) 17.29.07 Join factor [0] (~factor@75.108.68.114) 17.30.00 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 17.30.34 Quit Bawitdaba (Ping timeout: 250 seconds) 17.30.47 Join Bawitdaba [0] (~Sphinx@cpe-74-70-40-135.nycap.res.rr.com) 17.35.09 Join Alchimysta [0] (~975346b2@giant.haxx.se) 17.35.48 Quit Alchimysta (Client Quit) 17.44.03 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) 17.47.35 Join webguest_j [0] (~50ab34ac@giant.haxx.se) 17.48.02 Quit ender` (Quit: How many SEO experts does it take to change a light bulb, lightbulb, light, bulb, lamp, lighting, switch, sex, xxx, hardcore) 17.49.19 Quit t0rc (Client Quit) 17.49.19 Join ender` [0] (krneki@foo.eternallybored.org) 17.51.44 Join Buschel [0] (~chatzilla@p54A39EA5.dip.t-dialin.net) 17.52.36 # Thanks again for building/maintaining Rockbox! After 5 years with an Archos Recorder and Rockbox 2.5 I now have a Sansa Clip+, and Rockbox works much better than the OF. Thanks again! 17.53.28 # TheSeven: what issues made you think of to tight power management settings? the playback issues? 17.54.05 # playback jumping to tracks in a completely different folders, prefetch aborts that can't even happen in theory, weird NAND errors, lockups 17.54.34 # <[Saint]> fwiw, my Nano2Gs aren't doing anything weird. 17.54.52 Quit webguest_j (Quit: CGI:IRC) 17.55.04 # <[Saint]> except that "last in playlist" thing you pointed out, all is well here. 17.55.37 # [Saint]: could you already check the binary I have prepared today? (LCD shutdown) 17.56.43 # <[Saint]> Buschel: I have not had a chance to yet as the GF has the Colours (one in the car, and one in her locker at work :/), but I will when I can, yes. 17.56.57 # <[Saint]> The screen corruption is very annoying, thanks for looking into it. 17.57.46 # TheSeven: I would like to submit a slightly changed version of FS#11782 (slightly changed = do not change DRAM timings for boosted (=Apple OF), derivde unboosted DRAM timings from the boosted). Do you have any objections? 17.59.18 # [Saint]: you should always keep one target of each model ;) 18.01.19 # <[Saint]> Buschel: I try to, she'f forgotten she already had one in her locker, and took the other one also. ;) 18.01.25 # <[Saint]> *she'd 18.01.33 # Buschel: you only want to add those writes to MIUSDPARA? 18.01.54 # TheSeven: yes 18.01.59 # sounds good to me 18.02.06 # <[Saint]> there's also 2~3 Nanos in the car (I hope, as, I don't know where thay are otherwise) 18.05.25 Quit feisar- (Ping timeout: 272 seconds) 18.05.37 Join feisar- [0] (jljhook@irkki.fi) 18.06.05 # TheSeven: you also think its better to base on the Apple OF settings? those are a bit less tight regarding row cycle time. 18.07.01 # (and row cycle time) 18.07.16 # ahem, and row active time 18.07.19 # deviating from this would require extensive testing as they're using several different chips 18.08.03 # can we be sure the OF settings are the same for different chips? 18.08.09 # i generally don't have objections to just trying this either, but that might possibly end up as lots of weird issues like the ones i just had 18.08.18 # * Buschel thinks of the LCD weridness 18.08.29 # i didn't find differences 18.08.47 # good 18.09.16 Join the_Kyle [0] (~kyle@71.23.64.127) 18.09.28 # I could also read the settings for boosted and derive the unboosted register settings from it 18.10.19 Join MethoS- [0] (~clemens@134.102.106.250) 18.10.27 # too much magic though... 18.10.50 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 18.12.41 # we're pretty sure apple always initializes that to the same value, and iloader will do so as well 18.14.22 # ok, I wil just derive the 48MHz settings from the 96MHz ones. Also, I will only add those MIUSDPARA writes for nano 2g. 18.14.55 # Am I correct in thinking that the code for booting to the Clip+ OF when USB is connected while the player is powered off can be found in rbutil/mkamsboot/dualboot/dualboot.S? 18.16.03 # the settings for the meizu's look pretty similar (one is using the more tight numbers from my patch, the other is similar to the nano's) 18.16.30 # This file seems to be correct based on its comments. 18.16.59 # the_Kyle: yes. Be careful with that one though. If you make a mistake, fixing it involves opening the player and shorting pins 18.17.02 # (at least) 18.19.34 # <[Saint]> then trying to find someone else to do so to make a backup of the OF recovery image. 18.19.49 # Well, all I've done so far is to simply disable the USB checks. But when I rebuild mkamsboot and upgrade the bootloader, I still get dropped into the OF when USB is connected. Worse still, ever since I first got Rockbox USB mostly working, the OF hasn't mounted on my computer. 18.19.55 # <[Saint]> putting a copy of the FW in there "just works". 18.20.05 Join mirak [0] (~mirak@85-170-106-220.rev.numericable.fr) 18.20.07 # <[Saint]> but there's more magic the OF expects to find in there also. 18.21.20 Quit fml (Ping timeout: 255 seconds) 18.22.31 *** Saving seen data "./dancer.seen" 18.25.04 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 18.26.22 # I only disabled the USB checks last night, but the OF hasn't been able to mount for much longer. I just didn't give it much thought, since once I got Rockbox USB working, I have only accidentally used the OF by plugging in USB while the player is powered off. This accidental use of the OF is what I'm trying to fix by disabling USB checking so that it falls through to the Rockbox boot. 18.26.42 # the_Kyle: pastebin your diff 18.32.07 # * the_Kyle is waiting for pastebin. It's slow today. 18.35.31 # saratoga: http://pastebin.ca/2034325 18.36.53 # the_Kyle: you wanted to remove the USB check right? 18.36.58 # i think you just removed the button check 18.36.59 # Yes. 18.37.05 # TheSeven: Hi. I got as far as compiling your patch, but no further. Turns out I didn't have any spare time these holidays... 18.37.09 # although its hard to tell since theres so many white space changes 18.37.10 # Button still works. 18.37.22 # well then you tried to remove it :) 18.37.37 # I didn't think I changed any spacing. 18.38.07 # Maybe something I did in the commenting? 18.39.02 # looking at that S file, it checks the buttons first, and then checks the USB 18.39.15 # it looks like you just made some changes to the button code, but left the USB untouched 18.39.19 # linuxstb: did you see the gentlemen mail? :) 18.39.22 # <[Saint]> perhaps, there's a diff flag to avaiod whitespace, perhaps that would have made it easier to read. 18.39.38 # i would revert your changes, and then search through the text for "USB", then go from there 18.39.56 # TheSeven: No, but I've seen your comments here - congratulations! 18.40.19 # but the branch to the function called "boot_of" at the end of the USB detection code looks promising (although I didn't test this and if i'm wrong you could brick your player so please double check carefully...) 18.40.34 # Interestingly, that was what I thought I did. 18.40.39 # linuxstb: so i think all the needed drivers should be done now :) 18.41.17 # I originally tried commenting out the boot_of line, but that also seems to have no effect. 18.42.05 # I would have thought that commenting that out would have caused the code to fall through to Rockbox. 18.44.07 Quit froggyman (Quit: Ex-Chat) 18.48.47 Join einhirn [0] (~Miranda@p54850A3E.dip0.t-ipconnect.de) 18.49.03 Quit mirak (Remote host closed the connection) 18.49.15 # Oh. I think I see part of the problem. Looks like the assembly code takes @ instead of // for one-line comments. This may be why my original attempt to disable the boot_of branch at the end of the USB check didn't work. I'm used to C comments. 18.49.56 Quit einhirn (Client Quit) 18.51.21 Join einhirn [0] (~Miranda@p54850A3E.dip0.t-ipconnect.de) 18.52.37 # C comments work because the file goes through cpp 18.56.30 # I assume I can leave everything as it is in #ifdef SANSA_CLIPV2 since I'm working with a Clip+. 18.59.33 # Is there anything else I need to do to rebuild mkamsboot other than make inside of rbutil/mkamsboot? 18.59.50 Quit einhirn (Ping timeout: 260 seconds) 19.00.01 # make -C dualboot/ 19.00.37 # Ah. I think that's my other problem. I just did make. 19.01.17 Quit bmbl (Quit: Verlassend) 19.03.56 # It's trying to use arm-elf-gcc, which I thought tools/rockboxdev.sh was supposed to pull in, but it gives me "command not found." 19.05.01 Join einhirn [0] (Miranda@vpn10.rz.tu-clausthal.de) 19.05.01 # * the_Kyle is surprised that mkamsboot even worked at all. 19.05.27 Quit Buschel (Ping timeout: 276 seconds) 19.07.36 # the_Kyle: change it to call arm-elf-eabi-gcc 19.08.00 # kugel: Thanks. 19.08.59 Quit [Saint] (Quit: I'm only going to Heaven if it feels like Hell, I'm only going to Heaven if it tastes like caramel...) 19.22.51 Quit Judas_PhD (Ping timeout: 276 seconds) 19.25.25 Quit kugel (Ping timeout: 240 seconds) 19.32.49 Join kugel [0] (~kugel@rockbox/developer/kugel) 19.34.55 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 19.36.34 Join mirak [0] (~mirak@85-170-106-220.rev.numericable.fr) 19.38.06 Join Buschel [0] (~chatzilla@p54B66865.dip.t-dialin.net) 19.40.26 Join Keripo1 [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 19.41.00 Quit Keripo (Ping timeout: 250 seconds) 19.42.09 Quit mirak (Remote host closed the connection) 19.45.41 Join Horscht [0] (~Horschti@xbmc/user/horscht) 19.47.03 # Trying again, I commented out only the branch to boot_of in the USB check, make -C dualboot/ from within rbutil/mkamsboot/ and patched my 1.2.15 OF using my shiny new mkamsboot. After what appeared to be a successful upgrade, I'm still being dropped into the OF when USB is connected while powered off. 19.47.22 # Diff is at http://pastebin.ca/2034412 19.50.04 Join toffe82 [0] (~chatzilla@adsl-75-8-206-58.dsl.frs2ca.sbcglobal.net) 19.50.14 Join JesusFreak316 [0] (~JesusFrea@pool-173-65-113-24.tampfl.fios.verizon.net) 19.52.21 Quit Buschel (Ping timeout: 260 seconds) 19.55.31 # the_Kyle: the diff looks ok to me 19.55.31 Quit TheSeven (Read error: Connection reset by peer) 19.58.02 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 19.58.11 Quit stoffel (Ping timeout: 260 seconds) 19.58.12 Quit TheSeven|Mobile (Remote host closed the connection) 20.02.01 # Did I miss something when I rebuilt mkamsboot? Do I need to do anything with the .arm files it made during build? 20.05.01 # On a different note, I managed to get the OF to turn on the radio, but I noticed that I hear a rhythmic clicking sound in Rockbox that I don't hear in the OF. Did I find a bug? 20.05.45 # It's a minor annoyance, because I only hear it when the signal is weak. 20.06.48 # But the OF doesn't click no matter how weak the signal is. I didn't try recording, however, because I can't make the OF speak. 20.08.23 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 20.22.35 *** Saving seen data "./dancer.seen" 20.25.38 Join [Saint] [0] (S_a_i_n_t@203.184.1.132) 20.32.26 Join Buschel [0] (~chatzilla@p54B66865.dip.t-dialin.net) 20.33.10 Quit dfkt (Read error: Connection reset by peer) 20.33.10 Join dfkt_ [0] (dfkt@unaffiliated/dfkt) 20.38.25 Join CaptainKewl [0] (captainkew@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 20.40.39 # why doesn't editing firmware/SOURCES trigger rebuilding files in /firmware unless I do a make clean? 20.40.46 # i thought the make files could see changes to SOURCES 20.40.51 Quit CaptainKwel (Ping timeout: 276 seconds) 20.46.28 # <[Saint]> That sounds broken, it *should* look there... 20.47.44 Join perfectdrug [0] (~54b414e6@giant.haxx.se) 20.49.16 Quit mortalscan (Remote host closed the connection) 20.49.32 Join mortalscan [0] (~mortalsca@109.169.55.155) 20.49.42 # hey haven't been here for a while 20.50.30 # I updated http://www.rockbox.org/tracker/task/11796 thought this might help :) 20.51.09 Join CaptainKwel [0] (captainkew@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 20.51.24 Quit CaptainKewl (Ping timeout: 276 seconds) 20.51.49 Quit JesusFreak316 (Ping timeout: 240 seconds) 20.59.58 Join Xerion_ [0] (~xerion@54196686.cm-5-2b.dynamic.ziggo.nl) 21.03.01 Quit perfectdrug (Quit: CGI:IRC (EOF)) 21.03.02 Quit Xerion (Ping timeout: 240 seconds) 21.03.02 Nick Xerion_ is now known as Xerion (~xerion@54196686.cm-5-2b.dynamic.ziggo.nl) 21.03.05 Join perfectdrug1 [0] (~marko@p54B414E6.dip0.t-ipconnect.de) 21.05.40 Join JesusFreak316 [0] (~JesusFrea@pool-173-65-105-252.tampfl.fios.verizon.net) 21.08.02 Nick dfkt_ is now known as dfkt (dfkt@unaffiliated/dfkt) 21.21.19 Quit niekie (Read error: Operation timed out) 21.21.30 Join fyrestorm [0] (~nnscript@cpe-69-203-144-35.si.res.rr.com) 21.21.32 Quit GodEater (Read error: Operation timed out) 21.21.37 Join GodEater [0] (~bibble@cl-711.lon-02.gb.sixxs.net) 21.21.37 Quit GodEater (Changing host) 21.21.37 Join GodEater [0] (~bibble@rockbox/staff/GodEater) 21.22.06 # <[Saint]> Hmmmm, it seems that approximately only every 1 out of 5 times the database is initialized that the progress in the Debug (Keep Out!) --> View Database Info screen is anywhere near accurate with the percentile it reports. 21.22.37 # <[Saint]> The other 4 of 5 times it will simply show "Progress: -1%" 21.22.41 Quit Battousai (Read error: Operation timed out) 21.22.45 Join Battousai_ [0] (~bryan@2001:470:8830::80) 21.22.47 Quit Galois (Ping timeout: 260 seconds) 21.22.50 # this percentile is not supposed to be accurate 21.23.49 # <[Saint]> Well, that's good then...as it's now at ~220% :P 21.23.50 # New commit by 03Buschel (r28935): Submit FS11782: Use faster DRAM timings in unboosted state for S5L870x. DRAM read +8%, DRAM write +37%, DRAM copy +25% faster. 21.24.29 # <[Saint]> Buschel: Nice. 21.24.39 # Yep :) 21.24.41 # <[Saint]> Those numbers come from Nano2G testing I assume. 21.25.08 # Yes, you're right. Should have written this in the commit message. 21.25.12 # <[Saint]> Do any devs even own a Meizu? 21.25.22 # <[Saint]> I never hear anyone talk of them really. 21.25.29 # yes 21.25.30 Join niekie [0] (quasselcor@CAcert/Assurer/niekie) 21.25.33 Quit ps-auxw (Ping timeout: 272 seconds) 21.25.39 # afaik the ports sleep 21.25.49 # r28935 build result: All green 21.25.55 # <[Saint]> Ah, I take it you don't use it much gevaerts...? 21.26.09 # bertrik has a few, markun has one or two, and mine are distributed :) 21.26.25 # oh, and Bagder has one too I think 21.26.48 # [Saint]: using it wouldn't make much difference 21.27.01 # <[Saint]> Heh, the port isn't in what one could call "active development" anymore I take it? 21.27.44 # Well, I thought about the port a few weeks ago. Does that count? 21.28.48 # <[Saint]> Probably not, if it did then Rockbox probably supports every DAP imaginable ;) 21.29.36 # Speaking of thinking... 21.29.55 # What's the current status of the various AMS microSD problems? 21.30.18 # And/or startup issues 21.30.44 # * gevaerts is asking with his pointy release hat on 21.32.14 Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) 21.32.18 # gevaerts: occasional problems with random cards 21.32.22 Join froggyman [0] (~seth@unaffiliated/froggyman) 21.32.32 # So still not resolved? 21.32.50 # theres been some improvement since 3.7, but not resolved 21.33.12 # hm, ok 21.33.44 Quit feisar- (Ping timeout: 264 seconds) 21.33.50 # i think problems are fairly rare since no developer has a problem card 21.34.04 Join feisar- [0] (jljhook@irkki.fi) 21.34.18 # Aren't they typically with large cards? 21.34.30 # * gevaerts isn't sure if many developers have those 21.34.51 # i think i've seen them with smaller cards, but yeah many are large cards 21.34.56 # my 16GB works great though 21.35.53 # The problem with "better but not resolved" is of course that it's not clear if we want a point release for that 21.36.12 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 21.36.13 Quit Galois (Client Quit) 21.36.31 # "fixed" is much easier to decide on :) 21.37.34 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 21.38.52 Quit Galois (Client Quit) 21.39.55 # i don't think its worth doing a point release 21.41.57 Quit einhirn (Read error: Connection reset by peer) 21.42.21 Join Galois [0] (djao@efnet-math.org) 21.45.29 Join thomasjfox [0] (~thomasjfo@dslb-088-067-037-223.pools.arcor-ip.net) 21.48.34 Quit factor (Read error: Connection reset by peer) 21.49.37 # [Saint], I got one M3 21.49.53 # but i'm not involved in development of rockbox 21.53.30 Join factor [0] (~factor@75.108.68.114) 21.54.25 Quit factor (Read error: Connection reset by peer) 21.55.26 Quit Judas_PhD (Ping timeout: 240 seconds) 21.55.38 Join factor [0] (~factor@75.108.68.114) 22.05.17 # themeeditor looks like this on my machine (ubuntu 10.10 and looked the same with 10.04) what could be wrong? http://img227.imageshack.us/img227/5840/bildschirmfotosu.png 22.08.29 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 22.10.14 # what are this 2 blank windows suposed to show? 22.15.45 # soap: you there? 22.22.39 *** Saving seen data "./dancer.seen" 22.26.42 # when implementing a codec driver, what should i set the volume setting range to? 22.26.48 # just the master volume range of the codec? 22.27.01 # or should i account for additional digital gain values? 22.28.37 # TheSeven: the output stage of the codec has a maximum voltage level, that should be 0 dB 22.28.55 # if you have additional digital gain, that should be configured such that it pushes the level above 0 dB 22.29.09 # i think it can go up to +12dB or something, with clipping starting at slightly above 0dB 22.29.22 # thats fine for rockbox 22.29.49 # the only thing to watch for is that what you set 0 dB to is actually the level where clipping starts, we've screwed that up before on a few targets 22.30.23 # huh? shouldn't 0dB be 0dB? 22.30.50 # i mean 0dBV of course 22.31.02 # 0dB is just whatever level clips 22.31.13 Quit komputes (Quit: I haven't slept for ten days, because that would be too long.) 22.31.14 # not necessarily referenced to 0dBv 22.31.28 # i think most players clip around 300-600mV FWIW 22.31.57 # they're not actually calibrated though, so 0dB is just some random level dictated by the supply voltage the voltage drop across the output transistors 22.32.07 # ah, that's new to me 22.32.20 # i thought we calibrated them to 0dBV (like it seems to be true for the wm8975) 22.32.35 # my nano2g can drive ~1100mV without clipping 22.32.49 # (into a line load) 22.32.50 # and ~900mV into 16 Ohms 22.33.07 # 0dBv is 1 volt, which is within about 1-2 dB of most players at least 22.36.10 # soap: can you check this patch on your nano 1g -> http://pastie.org/1418235 22.36.29 # soap: the YUV functionality is of interest. and -- if it works -- the speed. 22.36.45 # now, once again, should i use DAC gains and similar things (that affect line out) to extend the volume range? 22.37.45 # TheSeven: I would say yes, if main volume does not reach at least -75 dB 22.39.06 # IIUC the master volume goes down to -102dB, and i can get another -58dB at the amplifiers 22.39.12 # that would be -160dB 22.39.13 # TheSeven: we implemented volume range extension for some codecs because the main volume was too loud in the lowest settings for some use cases. 22.39.34 # TheSeven: -102 dB is more than sufficient to my eyes (or better: to my ears) 22.39.48 # hm, but those probably affect line out AFAICT 22.40.38 # the quirky solution would be setting master to -12dB, line out to +12dB, and the headphone amp to -58dB to reach -70dB 22.40.44 # (without affecting line out) 22.41.03 # if we want to go lower than that, we probably need to get the lineout down as well 22.41.56 # ah, now I got you... sounds the same than the iPod Videos codec. -58 dB is too few. in this case you should use the DAC to further reduce some dB -- even if the lineouts are affected as well 22.42.00 # that should be sufficient 22.42.42 Join Fuhrer [0] (75d3557b@gateway/web/freenode/ip.117.211.85.123) 22.43.09 Quit Fuhrer (Client Quit) 22.43.14 # this beast is slightly complex: http://www.cirrus.com/en/pubs/proDatasheet/CS42L55_F1.pdf 22.43.19 # page 26 onward 22.44.26 # TheSeven: http://svn.rockbox.org/viewvc.cgi?view=rev&revision=24318 also contains the manual remark that lineout is affected. 22.45.25 # i'll probably just implement the -58..+12dB scale for now, we can add the quirks later 22.45.33 # of course 22.47.04 # urgh. 1.5dB step size for the tone control. how do i handle that? 22.47.11 # do we use the hardware tone control at all? 22.47.20 # (if not, i can power down the DSP block) 22.49.11 # we use hardware tone control to avoid the CPU load 22.50.49 # hm, how do i handle those stupid 1.5dB steps then? 22.51.10 # TheSeven: I'm sure other targets have 1.5dB steps - IIRC, Rockbox uses units of 0.1dB internally 22.51.36 # not in struct sound_settings_info 22.52.31 # TheSeven: you could introduce a lookup table 22.52.57 # check gigabeat f's code for details 22.53.43 # i like how detailed that datasheet is, and it has actual measured values rather then just "low power" or "improved quality" 22.56.06 Quit fyrestorm (Quit: lamers envy me like they envy bill g -- main boot xp, just the way it should be!) 22.57.22 # usually we just map the steps as closely as possible if they don't go 1dB at a time 22.57.44 # saratoga: look at those curves on page 69, especially the bottom left one :) 22.57.53 # that isn't really advertising material for them :-P 22.58.31 # heh they really measured everything 23.00.10 # saratoga: it's been done on gigabeat f, 1.5dB steps are easy and even voice properly 23.00.15 # 0.5-0.7mW for DSP effects, i wonder how much more efficient that is then CPU 23.00.33 # yeah i know 23.00.58 # saratoga: a lot 23.01.03 # Buschel, back, and can test. 23.01.06 # does SOUND_STEREO_WIDTH need support from the codec? 23.01.26 # jhMikeS: all the sansas are like that too 23.01.30 # i can't see it being referenced anywhere in the wm8975 driver 23.02.10 # soap: great, I do not expect that this works with the first shot... 23.02.17 # TheSeven: tone control is about equal to one DSP filter right? so thats a couple MHz, how efficient is your CPU? 23.02.35 # actually if your'e arm9E now its probably even less mhz 23.02.38 # i doubt the cpu can do that in the µW range 23.03.48 # are you sure? 23.04.10 # even the old as3525 only needed 250uW per MHz, and if you only need ~2MHz 23.04.12 # depends on how many MHz that actually is 23.04.18 # TheSeven: SOUND_STEREO_WIDTH is a sw effect 23.04.26 # i have no power measurements at all so far for the ipod classic 23.04.47 # if its as over engineered as everything else apple does i bet it kicks the crap out of amsv1 23.05.08 # * TheSeven doubts that as well 23.05.32 # those thingys seem to be rather bad in terms of memory bandwidth 23.05.44 # whats the nano2g battery life like? 23.05.53 # for some reason I thought it was much better then the sansas 23.06.03 Join fml [0] (~chatzilla@manz-5f74a35c.pool.mediaWays.net) 23.06.08 # jhMikeS: is SOUND_BALANCE also an SW effect, or is that implemented by shifting channel gains in the codec? 23.06.21 # saratoga: ask Buschel :) 23.06.31 # 24h 23.06.40 # channel gains mostly 23.06.44 # clip+ is about 17 hours 23.06.59 # I think there's one dap with a sw volume control 23.07.29 # yeah the Ingenic one 23.07.32 # also, MIPS 23.07.36 # weird little device 23.08.28 # FWIW i started working on ARMv5 DSP functions, which will be nice, i guess squeeze that last Mhz or so out of the effects code 23.08.37 # slow going though since i suck as asm 23.09.39 # Buschel: did you try test_codec with r28935? 23.09.49 # i wonder if codecs are faster now that the dram is a little better 23.10.24 # * thomasjfox thinks he sucks more at creating debian packages than saratoga sucks at asm ;) 23.10.27 Quit fml (Client Quit) 23.10.40 # saratoga: I tried a while ago before I submitted. the effect was measurable but minor (for mpc) 23.11.05 # i guess any codecs that see a big improvement are probably ones were we don't use much IRAM 23.11.11 # saratoga: I guess the more IRAM-optimized a codec is the less effect will be seen 23.11.30 # :) same thougts 23.11.33 # :) 23.12.25 # damn, i don't really have time to complete that port 23.12.33 # it's way more work than i had expected 23.12.42 # gevaerts, I recently did a fix for AMSv2 uSD card problems that could be backported 23.12.45 # the classic? 23.12.52 # yep 23.13.21 # the fix was of the sprinkle-arbitrary-delay-until-it-works kind though 23.13.27 # saratoga: i have proof of concept code for basically everything up and running, but porting that into rockbox's architecture is way more work than i would have thought 23.13.53 # yeah i believe that 23.13.59 # i still don't understand how our drivers actually work 23.14.04 # just bits and pieces 23.14.08 # and the AMSv1 just had the clocking change patch reverted, so uSD should work on AMSv1 again too 23.14.21 # bertrik: are there people left for whom it doesn't work? 23.14.23 # hm 23.14.28 # Buschel, does not work. During the YUV test instead of a nice square in the middle of the screen I get a band across the upper half of the screen of what appears to be "halftone" colors. 23.14.30 # saratoga: I tried armv6 ones for the effect and didn't really see it help a great deal, could've done it kinda wrong though :\ 23.14.51 # you dsp_armv6? 23.14.57 # for AMSv2 I hear nothing but good news now 23.15.30 # OK. If bad reports don't come in during the next few days, I'd say we do a 3.7.2 23.15.39 # bertrik: is that committed? 23.15.48 # saratoga: only the sample_output_mono/stereo really got better by any significant margin 23.15.56 # saratoga, yes, but only to trunk, not to any branch 23.16.03 # bertrik: http://forums.rockbox.org/index.php/topic,25726.msg176184.html#msg176184 23.16.44 # gevaerts: are you planning to do stable vs. development releases? i.e. release 3.8 some day, then 3.7.3, and only recommend the 3.8 branch as of 3.8.1? 23.16.57 # TheSeven: not *planning* :) 23.17.07 # We're supposed to be doing that now! 23.17.11 # saratoga: of course, there wasn't much to do because it stayed 32 bits 23.17.16 # Oh, right, I see what you mean 23.17.24 # a freeze could be some other problem 23.17.26 # No, I don't think we'll maintain old releases 23.17.46 # soap: ok, found three issues. next try: http://pastie.org/1418326 23.17.47 # Yes, I don't trust any freeze report until the filesystem has been checked... 23.17.49 # jhMikeS: i was working on a v5/v6 version of apply_gain, i think that can be made 2x faster, but its already pretty fast 23.17.55 # i don't think anybody has ever really discussed how long we should keep the old branches alive 23.18.45 # bertrik: i mean theres still some outstanding issues with that fix, obviously it helps some people's problem 23.18.53 # TheSeven: indeed not, but I also don't think anyone wants to volunteer to maintain previous release branches 23.18.54 # "even with that fix" 23.19.25 # saratoga: if the problem is related to the driver and not to bad tracks or a bad filesystem 23.19.29 # saratoga: it looks like it needs reordering at least 23.19.40 Join JdGordon| [0] (~jonno@124-149-188-197.dyn.iinet.net.au) 23.19.40 Quit JdGordon| (Changing host) 23.19.40 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 23.19.50 # soap: wait, typo in the code, next patch follows in a few secs 23.20.07 # was going to use 16 bit values for the gain, drop the long multiplies, and then unroll it 6x, should fly on arm11 23.20.31 # thanks to those nice 64 bit load/stores 23.20.38 Quit anewuser (Ping timeout: 240 seconds) 23.21.10 # soap: http://pastie.org/1418335 23.21.22 # ok 23.22.40 # hmm test codec's dsp test function seems to be broken for me 23.22.59 # saratoga: hmmm, I did try more than the 2x unroll already there-- diminishing returns, but maybe without long stuff could be different 23.24.44 # New commit by 03rmenes (r28936): Rockbox Utility: Add in support to install Rockbox on the Philips ... 23.25.31 Join LambdaCalculus37 [0] (~rmenes@static-71-249-221-104.nycmny.east.verizon.net) 23.25.31 Quit LambdaCalculus37 (Changing host) 23.25.31 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) 23.25.55 # fullscreen graphic failure this time, Buschel. The same pattern as before on the top of the screen and a new pair of patterns on the lower half. 23.26.07 # arm11 can do a load/mac/store in 2 clocks, so unrolling is helpful to keep loop overhead from getting too high 23.26.19 # but yeah 4x was probably fine, but i had the registers so why not 23.26.42 # r28936 build result: All green 23.26.43 Join GeekShad0w [0] (~Antoine@93.21.159.10) 23.27.00 # with branch prediction and code caching I don't think loop overhead is so great 23.27.25 # if a branch is consistently taken in a loop, is it 1 cycle? 23.27.27 # soap: what is the speed like? I would like to see whether further debugging would be helpful... 23.27.30 # I can start photographing the exact screen output if that would help in diagnosis, Buschel. 23.27.31 # I don't remember if those are predicted though 23.27.35 # i haven't figured out branches on arm11 yet 23.27.57 # there are details in the guides on what's predicted and not 23.28.01 # Buschel, The graphical glitches as I describe happen at the start of the YUV fps test and crash the system. 23.28.06 # I never see the speed. 23.28.10 # i'm sure the branch predictor gets a for loop right, theres no way it couldn't except maybe ont he first and last iteration 23.28.12 # ooops 23.28.19 # just don't know how long it takes to issue 23.28.29 # 80.5 fps for full-screen LCD updates, but that's the only number I get to see clearly before the death. 23.28.48 # soap: that should not happen... let me check again 23.29.26 # oh, and I'm running unboosted, yell if you want me to boost. 23.29.37 # soap: that's fine 23.29.48 # Just got back from the gym when I saw your highlight, I'm going to hop in the shower, brb. 23.30.05 # ok 23.32.09 # appently it predicts all forward conditional branches as not taken and all backward ones are taken 23.33.09 Quit saratoga (Ping timeout: 265 seconds) 23.35.59 Quit Judas_PhD (Quit: This is a quitting message) 23.40.37 # * jhMikeS wonders why cache apis have so many aliases now ?? 23.41.30 # ok Buschel 23.41.47 # still reviewing 23.47.19 # soap: easier approach -> http://pastie.org/1418406 23.48.59 # easier? 23.49.22 # did you just refactor your approach while I washed? 23.49.38 Join Bagder [0] (~daniel@rockbox/developer/bagder) 23.50.24 # oh, I refactored just a bit. this will work for nano only, not for the iPod color. but this way I hope to track down the issue 23.51.14 Join JesusFreak316_ [0] (~JesusFrea@pool-173-65-105-252.tampfl.fios.verizon.net) 23.51.48 # same screen pattern as before in test_fps 23.52.13 # still crashing? 23.52.18 # (this was the 4th patch, same pattern as the third patch) 23.52.36 # yes, well unless I totally forget how to exit the plugin while the screen is corrupted. 23.52.50 # pressing Menu 23.52.54 # ;) 23.52.59 # ;) 23.53.26 Quit JesusFreak316 (Ping timeout: 240 seconds) 23.53.32 # is there a chance that the dma issue my Nano has is causing the corruption of the display in this instance? Any overlap at all? 23.53.34 Join BHSPitMonkey [0] (~stephen@68-185-207-215.dhcp.dntn.tx.charter.com) 23.53.35 Quit BHSPitMonkey (Changing host) 23.53.35 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 23.53.55 Join saratoga [0] (9803c6dd@gateway/web/freenode/ip.152.3.198.221) 23.53.56 # soap: no, should be a logical failure... 23.54.44 Quit kadoban (Ping timeout: 264 seconds) 23.55.47 Quit GeekShad0w (Ping timeout: 255 seconds) 23.58.30 # I can start photographing the exact screen output if that would help in diagnosis, Buschel. 23.58.53 # soap: why not, maybe it gives a hint