Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2010-12-30

00:00:30Buschel[Saint]: because I wished to see something != 0 which could have been a sign for a CLK divider > ^1
00:00:36Buschel> 1
00:00:42jhMikeSthomasjfox: 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:31CtcpIgnored 1 channel CTCP requests in 0 seconds at the last flood
00:01:31*jhMikeS wonders if "clever trick" means "non-blocking"
00:01:31Buschel[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:48saratogaSaint: Unless you have a slow connection, you can pretty easily download an ubuntu VM image off sourceforge, then run there
00:03:07saratogaor 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:42saratogaah sucks
00:04:18thomasjfoxjhMikes, 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:20thomasjfoxwrite position without trouble. Or how does the non-blocking update for the DMA engine work?
00:04:36Buschel[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@
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@
00:05:21DBUGEnqueued KICK S_a_i_n_t
00:06:12kugelthomasjfox: that's about it, yes. at least according to my (limited) understandings of the pcm stuf
00:07:14thomasjfoxthe DMA engine protects itself against another IRQ by masking the IRQ line, so that is safe
00:07:17jhMikeSthomasjfox: 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:58thomasjfoxjhMikeS: Well, the code smell like it (no offense)
00:07:58kugeljhMikeS: I think I've seen that freeze on the app as well
00:08:10S_a_i_n_tBuschel: CLCD_CLOCK_SRC: C0000000
00:08:57jhMikeSthomasjfox: typically there's very little masking of audio dma interrupts. they're usually higher than HIGHEST_IRQ_LEVEL and specially synchronized.
00:08:58thomasjfoxcommit_chunk() f.e. quickly updates the write position
00:09:32thomasjfoxthough "quickly" means it's not protected by any kind of locking
00:09:40BuschelS_a_i_n_t: bad again... at least from we know about PP502x so far, there is nothing I can do...
00:09:44jhMikeSnor should it be locked
00:10:10jhMikeSlocking = bad
00:10:14BuschelS_a_i_n_t: +30% for YUV i not bad though
00:10:31thomasjfoxI didn't want to say I want a mutex in there :o)
00:10:53thomasjfoxI'm just thinking things through for the app case on a SMP box
00:10:56S_a_i_n_tBuschel: From my tests, I would say commit.
00:11:16S_a_i_n_tI even notice some plugins perform a lot better.
00:11:27S_a_i_n_tchopper.rock for one is a lot smoother
00:12:27jhMikeSkugel: something looks fishy when the read and write positions might collide but I never really went deep
00:12:44S_a_i_n_tboomshine.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:00kugelthomasjfox: the host should handle this kind of issues SMP boxes
00:13:06S_a_i_n_tAnd 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:35S_a_i_n_tThough, your Nano2G LCD optimisations make it look rather negligible
00:14:16thomasjfoxkugel: 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:29thomasjfoxdma buffer = pcm buffer
00:15:06kugelwould that be bad?
00:15:27kugelthe intend of the sim is to simulate real target situation, not "just work"
00:15:56kugelif this kind of situation can happen on target we should be happy that we can simulate it now
00:16:24thomasjfoxLet 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@
00:16:58DBUGEnqueued KICK [Saint]
00:17:14 Quit Bagder (Quit: It is time to say moo)
00:17:22kugelbut 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:46kugelthat includes synchronizing the caches of the cpu
00:17:51CIA-7New commit by Buschel (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:51CIA-7r28930 build result: 8 errors, 0 warnings (Buschel committed)
00:19:54thomasjfoxkugel: 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:20kugelI don't think so
00:20:31thomasjfoxkugel: Though we just read from the pcm buffer with our own start address
00:20:36jhMikeStomasjfox:mpegplayer's pcm buffer is quite a bit simpler to understand but perhaps just as alarming :)
00:20:40kugelthe threads thing is putting the many core issues into a blackbox
00:21:04 Join parafin [0] (
00:21:13thomasjfoxkugel: How is that working?
00:21:21kugelmultithreaded apps that work correctly on a single cpu setup also work correctly on a many core/multi cpu setup
00:21:39CIA-7New commit by Buschel (r28931): Forgot one file.
00:22:03jhMikeSthough 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:25thomasjfoxkugel: Almost correct
00:22:36thomasjfoxkugel: Let's say you have a multithreaded app on a single core box
00:23:08thomasjfoxIf you use volatile for the shared primitives, you're fine
00:23:09jhMikeSkugel: 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:27thomasjfoxwithout memory barriers, this will break on a SMP box
00:23:32kugeljhMikeS: that's my point yes
00:23:49[Saint]And, thanks for your work on Nano1/2G and Colour recently
00:23:51CIA-7r28931 build result: All green
00:23:56[Saint]Buschel: ^
00:24:12Buschel[Saint]: thanks for testing!
00:24:22[Saint]Nano2G LCD is *damn* fast now.
00:24:34kugelthomasjfox: 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:59thomasjfoxkugel: I was talking about primitive types
00:25:26thomasjfoxprimitive types + volatile works fine on single core IMHO
00:25:42kugelwhat primitive types do you mean?
00:25:49thomasjfoxUint32 f.e.
00:26:13kugeleven those need locks on a fully concurrent system
00:26:39 Quit pamaury (Remote host closed the connection)
00:27:22thomasjfoxhuh? That's news to me.
00:29:14thomasjfoxf.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:45kugelit 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:08thomasjfoxkugel: Ah ok, here's my error: I was thinking about a single instruction (which it usually is)
00:32:25kugelvolatile 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:35thomasjfoxyes, that's true
00:33:06kugelthomasjfox: it's not, especially not on risc machines (like ARM) where writing to memory is always at least two instructions
00:33:29Buschel[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:24Buschelsoap: just saw your results. pretty good :) did you see any flaws in movie playback or YUV blitting during test_fps?
00:34:34thomasjfoxkugel: ok, thanks
00:34:59[Saint]Buschel: Working as expected here on 2 iPod Colours.
00:35:00thomasjfoxAnyway, it's not an issue at all if the pcm buffer is not on the low watermark :)
00:35:54thomasjfoxkugel: 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:01kugelbut 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:06soapBuschel, 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:25thomasjfoxkugel: on ARM they are emulated in software
00:36:43 Join Strife89TX [0] (
00:36:47kugelah, so they suck :)
00:36:47soapThe Nano 1G's screen is so amazingly narrow in the useable viewing angle that it would be hard to distinguish subtle errors.
00:36:53thomasjfoxkugel: On Intel the atomic operations use the corresponding cpu instructions
00:37:15soapBuschel, thanks for your work. GLAD to support your return to PP ipod work!!!
00:37:16thomasjfoxkugel: 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 '
00:37:41thomasjfoxOtherwise SMP would suck a lot on those...
00:38:08kugelSMP isn't what we need to worry about, concurrency is
00:38:11CIA-7New commit by Buschel (r28932): Submit FS #11707. Add line out power off to iPods nano1G, color and 4G.
00:38:14thomasjfoxThat was the article on the arm blog I posted earlier
00:38:19soapI don't think so Saint, the off-axis contrast is horrible and reveals lots of encoding artifacts otherwise hidden well by ffmpeg.
00:39:31kugelSMP only adds true parallelism, but concurrency always had that in mind
00:39:56thomasjfoxYes, of course (though I like to mix those two up ;))
00:40:13CIA-7r28932 build result: All green
00:40:31thomasjfoxThough this is a no issue on real "rockbox" hardware because of the cooperative threads
00:40:38kugelconcurrency just means true parallelism where available, otherwise quasi-parallelism :)
00:41:33thomasjfoxconcurrency is a no-issue if we use our own scheduler right
00:41:37kugelbut we do have multi core targets with true parallism. it's just not implemented in the sim or the app
00:42:15thomasjfoxSo how does rockbox perform locking on those?
00:42:37kugelcorelocks, peterson algorithm as jhMikeS noted earlier
00:44:07kugelcooperative 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:35thomasjfoxkugel: 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:54jhMikeSwell, 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:46thomasjfoxkugel: But I better shut up, I'm not really into the arm details :)
00:52:42kugelthomasjfox: you can see the peterson algorithm in the c version
00:54:13kugelit'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:52thomasjfoxkugel: Yes, I understood that. But those flags must be read/written in an atomic way, no?
00:57:27thomasjfoxdoes PP reorder memory access?
00:57:32jhMikeSit just requires that things be well ordered and in this case, not cacheable ram
00:57:38thomasjfoxah ok :)
00:58:02 Quit Keripo1 (Quit: Leaving.)
00:59:41CtcpIgnored 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:40soapso, Buschel, you saying you want more long-term testing of v03/ v04 of FS 11843?
01:00:51kugelpeterson uses this array for each core to get around the atomic thing
01:01:15 Join tuxifier [0] (
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:44tuxifierhi everyone sansa clip+ with rockbox 3.7.1 doesn't recognize tanscend 16gb microSD card - am I missing sth?
01:02:55Buschelsoap: I hopefully did not mess up my comments -> I was talking of FS #11830 (ATA) reagrding long-term testing
01:03:23Buschel[Saint]: yes, that's why I already submitted the patch :)
01:03:28 Join kugel_ [0] (
01:03:42[Saint]Hmmmmm, whoops.
01:03:45tuxifierofw 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:59Buschelno 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:24tuxifierhi 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:06:11jhMikeSthere'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:30tuxifiercan anyone even read me?
01:06:43pixelmatuxifier: there was some change to improve microSD card handling just a few days ago. Please try a current build
01:07:19tuxifierpixelma: ah all right will do - thanks
01:07:29Buschelsoap: 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] (
01:10:38 Quit kugel (Disconnected by services)
01:10:42BuschelFIFO wait can also be removed for nano2G YUV blitting as the LCD IF is (now) fast enough as well.
01:11:42Buschelwould give +19% on nano2G and +10% on nano1G/color
01:11:51Buschel(for YUV)
01:13:32 Quit kugel_ (Remote host closed the connection)
01:13:42 Join kugel [0] (~kugel@rockbox/developer/kugel)
01:14:27thomasjfoxjhMikeS: Speaking of core_sleep(), that's exactly what I need now. Thanks for your patience, the same to kugel
01:15:25kugelcore_sleep() is what calls wait_for_interrupt()
01:16:13tuxifierpixelma: current build installed - rockbox info says HD1 not present
01:16:33kugeljhMikeS: are these nops in core_sleep() really only needed for the beast, or are they needed on all armv6+ (or even v5+)?
01:17:10tuxifiercould this be a settings thing?
01:17:47pixelmatuxifier: 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:50soapyes, 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:12jhMikeSkugel: not sure about that but if they pipeline, they might execute instructions after the wfi
01:18:32jhMikeSI'd have to say "most likely yes" really
01:19:02kugelall arms do pipelining, just the length of the pipe differs (larger with later versions)
01:19:13pixelmatuxifier: 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:30marazsoap, Buschel: as expected, stock r28914 won't even rolo on my device, but v07 works without a hitch
01:19:32jhMikeSeven 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:20Buschelsoap: 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:34Buschelmaraz: good! :)
01:22:50 Join kugel_ [0] (
01:22:59*[Saint] wonders what type of black magic makes heat aggrivate this issue
01:23:33BuschelI 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:56saratogaheating 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:13saratogaso 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: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] (
01:28:01saratogawhen 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:48soapBuschel, 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 must be quite rare for those chips to tolerate 100MHz.
01:30:16saratogaSaint: 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:31soapAs 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:43jhMikeSmaybe MHz fly off in little bit when it runs too fast? over time, not enough MHz left
01:31:07Buschelsoap: ok, let me be more precise: FS #11830 (ATA) needs at least 1 week of testing before I will submit it.
01:31:20soap[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:01soapno, I have not tried to 100
01:32:10Buschelsoap: 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:39soapCongressman Ted Stevens?
01:33:07soapBuschel, 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/ 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:43soap[Saint], it very well might, as the issue appears to be memory not cpu.
01:33:48Buschelsoap: 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:12soapBuschel, but who will be testing on non-nano targets? ;)
01:34:22[Saint]battery life is markedly improved at those clocks also.
01:34:53soap[Saint], after this issue is fixed I very well might play w/100.
01:34:57Buschelsoap: I will have my iPod Video up a few times, maybe Saint uses his color a bit?
01:35:08soapbut since my Nanos are my exercise iPods they don't need great battery life.
01:35:12saratogai wanted to make the some of the PP devices use 24Mhz as the low clock for a while now
01:35:25marazmy 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:35saratogaprobably worthwhile on everything with a smallish screen
01:35:40eRivashey, any ideas why the battery life on Sansa Fuze is so low?
01:36:14eRivaswith OF I get ~24hrs, RB gives ~5hrs
01:36:36saratogayou should get about 12 hours IIRC
01:36:43saratogahow 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:33eRivassaratoga: hmm, no test, just normal usage
01:37:47eRivassaratoga: I might try battery benchmark
01:37:50soap[Saint], doing so already for you
01:38:01saratogayou'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:16Buschel[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:41Buschel[Saint]: its all in the binaries we have exchanged today :)
01:38:50soapBuschel, yes. I'm a MP3 user, so 24 might help a bit.
01:39:18Buschelsoap: a lot. -6 MHz clock = -1.5 mA
01:39:33soapwe'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:27soapmaybe 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:49soapinability 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:07Buschel[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:31soapmaybe they'd all run at 100 post ATA work.
01:42:38[Saint]they are rated for 80MHz, is this correct?
01:43:11soapbut why is 24/100 needed, is 24/80 not responsive feeling enough?
01:43:12eRivassaratoga: 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:01eRivassaratoga: but considering OF refused to work, RB is a plus in so many other ways
01:44:05soapeRivas, 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:45:18soap and why you laughing at me jhMikeS?
01:45:43[Saint]thankyou, soap.
01:45:50soap <−− oops bad link
01:46:07Buschel[Saint]: from product briefs -> PP5020 max 80 MHz, PP5022 max 100 MHz
01:46:22Buschel[Saint]: nano1G and Video use 5021 :)
01:46:43jhMikeSsoap: 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:47:14soapjhMikeS, to *see* it drop one would need to have the hog of a backlight on! ;)
01:47:16Buschelsoap: 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:26Buschel[Saint]: it should save no power
01:48:29jhMikeSsoap: that happens yes but them it should go back up after it goes off
01:49:03Buschel[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:20soapwow, the PluginMpegplayer performance numbers for the Video are way out of date.
01:50:54***Saving seen data "./dancer.seen"
01:51:34Buschelsoap, [Saint]: you update PluginMpegplayer fps for color and nano1g :) should be faster now
01:51:49Buschelyou *could* update....
01:52:22*[Saint] fires up FFmpeg
01:52:25Buschelsoap: the iPod Video should not be any faster now...
01:52:38soapuse the provided files for testing, [Saint], no other will be comparable.
01:52:47Buschel[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:59[Saint]where are the codec sample files located? I should probably grab those also.
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:41[Saint]*250 rather
02:03:08[Saint](regarding LCD)
02:03:40Buschelno, 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:39Buscheloops, didn't see the last comments. it was 3x for RGB and 2x for YUV on nano2g
02:05:52Buschel(for LDS type)
02:06:10[Saint]yes, very nice.
02:07:37Buscheland from we saw today in your measurements I expect there is a (yet hidden) clock divider active for the color lcd...
02:07:57Buschelcould 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:03eRivasdo elements declared down a .wps file have priority over those declared above?
02:15:45[Saint]well, not declared, but called.
02:15:47 Quit Gareth (Ping timeout: 265 seconds)
02:15:53eRivasyeah, that
02:16:06eRivassorry, too much css for me, lol
02:16:29 Join Gareth [0] (
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:43Buschel[Saint]: do you have an iPod Photo as well?
02:28:25JdGordonwell, 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:41Buschelamiconn: 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:43Buschel...this clock divider?
02:38:48Buschelamiconn: the iPod Photo is a lot faster than the iPod Color in terms of LCD transfer speed.
02:39:52saratogaaren't the color and photo the same?
02:41:20Buschelsaratoga: the speed is significantly different. maybe this is just a default config of some register...
02:41:35saratogano i mean aren't they the same device?
02:42:49Buschelhmm, not sure. for rockbox it is the same build, but I do not know whether the hardware differs a bit...
02:43:27saratogai think they're the same device, but its possible theres different revisions
02:43:53soapIPL does not recognize different versions.
02:44:45soapNow I know Rockbox surpassed them as source of iPod knowledge, but their "generations" page was long considered gospel.
02:45:00Buschelif 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:24soapraw LCD is slower but YUV is faster?
02:45:36soap(in [Saint]'s test (Hayden))
02:46:17BuschelYUV is faster, but nearly identical to RGB
02:46:44soapwikipedia 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] lists the release dates, and potential differences.
02:47:27[Saint]some had firewire/some didn't, etc.
02:48:12soapthat's poorly worded. "Firewire AND USB" there was no OR.
02:48:22soapyou can use firewire or USB.
02:48:32soapthey contain firewire AND usb capabilities.
02:49:19soapIt isn't that some have one and some have the other.
02:49:37Buschelsoap: btw, I am surprised of the MpegPlayer speed up for nano1g. more than I expected
02:49:48soapit was an OLD prior as well.
02:50:36soapjhMikeS, 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:43jhMikeSthe video could be clipped out from that area but then the FPS would run a little high on tests
02:52:19soap[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:49soapjhMikeS, could the FPS display simply be synced to the mpeg frames?
02:53:16soap(causing a little loss in FPS during tests)
02:53:23Buschelok, 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:54:33jhMikeSsure, 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:39eRivasfrom where does RB pull the setting for rockbox failsafe, the .wps file of that name is a dummy
02:56:59jhMikeSsoap: 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:43jhMikeSa tiny box with nothing but the FPS would probably work. the rest is that info just debugging stuff.
03:05:37eRivasguys, what is the absolute path to a file in the microSD card?
03:07:56[Saint]<MICROSD1>/foo/bar/baz.<ext> 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:56eRivasgood idea
03:10:30eRivasI have to put playslists on /playlist, right, for them to appear in the catalog?
03:14:29eRivasUNIX 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:03eRivasthey seem to work both, at least for relative paths
03:22:06 Join telliott [0] (
03:31:30 Quit GeekShadow (Quit: The cake is a lie !)
03:32:20jhMikeSsoap: 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] (
03:46:40 Join telliott [0] (
03:50:58***Saving seen data "./dancer.seen"
04:22:16DEBUGEOF from server (Connection timed out) (snapshot: netstuff.c line 545)
04:22:16***No seen item changed, no save performed.
04:22:18***Started Dancer V4.16
04:22:18***Connected to on port 6667
04:22:18***Logfile for #rockbox started
04:22:21Mode"logbot :+i" by logbot
04:22:25***Server message 501: 'logbot :Unknown MODE flag'
04:22:25 Join logbot [0] (
04:22:25 Join telliott [0] (
04:22:25 Join BlakeJohnson86 [0] (
04:22:25 Join Gareth [0] (
04:22:25 Join Keripo [0] (
04:22:25 Join parafin [0] (
04:22:25 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS)
04:22:25 Join CaptainKewl [0] (
04:22:25 Join mortalscan [0] (~mortalsca@
04:22:25 Join B4gder [0] (~daniel@rockbox/developer/bagder)
04:22:25 Join kadoban [0] (
04:22:25 Join krazykit [0] (
04:22:25 Join GuySoft [0] (
04:22:25 Join Horscht [0] (~Horschti@xbmc/user/horscht)
04:22:25 Join eRivas [0] (~je@
04:22:25 Join AndyI [0] (~pasha_int@
04:22:25 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven)
04:22:25 Join user890104 [0] (
04:22:25 Join sasquatch [0] (~username@
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@
04:22:25 Join elcan [0] (
04:22:25 Join crwl [0] (
04:22:25 Join Kitar|st [0] (~Kitarist@
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@
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] (
04:22:25 Join mikroflops_ [0] (
04:22:25 Join saratoga [0] (9803c6dd@gateway/web/freenode/ip.
04:22:25 Join merbanan [0] (
04:22:25 Join tempname [0] (
04:22:25 Join pjm0616 [0] (~user@
04:22:25 Join Guest88817 [0] (
04:22:25 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother)
04:22:25 Join timccc [0] (~timccc@
04:22:25 Join xavieran [0] (
04:22:25 Join Xerion [0] (
04:22:25 Join YPSY [0] (
04:22:25 Join soap [0] (~soap@rockbox/staff/soap)
04:22:25 Join tmzt [0] (~tmzt@
04:22:25 Join FOAD [0] (~dok@
04:22:25 Join preglow [0] (
04:22:25 Join Stummi [0] (Stummi@rockbox/developer/Stummi)
04:22:25 Join bzed [0] (
04:22:25 Join jfc^2 [0] (
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] (
04:22:25 Join antil33t [0] (
04:22:25 Join jordan` [0] (
04:22:25 Join literal [0] (
04:22:25 Join shai [0] (
04:22:25 Join bug2000 [0] (~bug@unaffiliated/bug2000)
04:22:25 Join the_Kyle [0] (~kyle@
04:22:25 Join pikytcus_ [0] (
04:22:25 Join Galois [0] (
04:22:25 Join simonrvn [0] (
04:22:25 Join rvvs89 [0] (
04:22:25 Join chattr [0] (
04:22:25 Join Dhraakellian [0] (
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] (
04:22:25 Join ved [0] (
04:22:25 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb)
04:22:25 Join n17ikh [0] (
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] (
04:22:25 Join rasher [0] (~rasher@rockbox/developer/rasher)
04:22:25 Join MagusG [0] (
04:22:25 Join simabeis [0] (
04:22:25 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
04:22:25 Join linuxguy3 [0] (
04:22:25 Join fred_2 [0] (
04:22:25 Join kkit|sh [0] (
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] (
04:22:25 Join Bushmills [0] (
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] (
04:22:25 Join Rondom [0] (
04:22:25 Join TBCOOL [0] (
04:22:25 Join Slasheri [0] (miipekk@rockbox/developer/Slasheri)
04:22:25 Join Bawitdaba [0] (
04:22:25 Join maraz [0] (
04:22:25 Join ThomasAH [0] (
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] (
04:22:25 Join part [0] (part@
04:22:25 Join burn [0] (
04:22:25 Join Hadaka [0] (
04:22:25 Join ack [0] (
04:22:25 Join balintx [0] (
04:22:25 Join powell14ski [0] (
04:22:25 Join Farthen [0] (
04:22:25 Join yosafbridge [0] (
04:22:25 Join lostlogic [0] (~lostlogic@rockbox/developer/lostlogic)
04:22:25 Join jobec [0] (
04:22:25 Join CIA-7 [0] (~CIA@
04:22:25 Join amee2k [0] (
04:22:25 Join @ChanServ [0] (ChanServ@services.)
04:22:25 Join iq [0] (~iq@unaffiliated/iq)
04:22:25 Join alexbobP [0] (
04:22:25 Join Kohlrabi [0] (
04:22:25 Join gevaerts [0] (~fg@rockbox/developer/gevaerts)
04:22:57 Join Barahir [0] (
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] (
05:09:38 Join the_Kyle [0] (~kyle@
05:19:22 Quit elcan (Ping timeout: 240 seconds)
05:20:08 Join elcan [0] (
05:29:56 Join guymann [0] (
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] (
06:50:46 Quit Loto (Changing host)
06:50:46 Join Loto [0] (~nfs@xbmc/user/Loto)
07:00:27 Join JdGordy [0] (~jonno@
07:04:37 Quit JdGord (Ping timeout: 260 seconds)
07:12:44 Join froggyman [0] (~seth@
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] (
07:19:32 Quit elcan (Read error: Operation timed out)
07:24:04 Quit JdGordy (Quit: Bye)
07:27:40 Join elcan [0] (
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] (
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] (
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] (
08:55:37 Join elcan [0] (
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] (
09:11:23 Quit Judas_PhD (Ping timeout: 240 seconds)
09:25:47 Join Judas_PhD [0] (
09:26:56 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey)
09:27:25 Join factor [0] (~factor@
09:34:41 Join stoffel [0] (
09:37:09 Join webguest79 [0] (
09:43:29webguest79nevermind, 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] (
09:55:15 Join einhirn [0] (
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] (
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@
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] (
11:30:41maxexclooHey, I was wondering if anyone is working on an iPod Touch/iPhone port
11:30:48maxexclooJust a question
11:30:54 Join the_Kyle [0] (~kyle@
11:31:54 Join bmbl [0] (
11:31:54 Quit bmbl (Changing host)
11:31:54 Join bmbl [0] (~bmbl@unaffiliated/bmbl)
11:36:59pixelmahaven't heard about anyone
11:38:23 Join dfkt [0] (dfkt@unaffiliated/dfkt)
11:39:24 Join liar [0] (
11:41:51maxexclooPity, my iPod is useless then :(
11:45:53 Join fml [0] (
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@
11:53:10 Join Topy44 [0] (
12:05:07Stummiuseless? I think the iPod touch is also pretty usable with OF
12:07:47pixelmafor playing flac? But anyway - he already left and - you don't say that in a #rockbox channel ;)
12:13:37 Join JdGordy [0] (
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] (
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] (
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] (
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] (
12:49:54 Quit advcomp2019 (Ping timeout: 264 seconds)
12:52:35 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
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] (
13:27:42 Join T44 [0] (
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] (
13:45:37 Quit bluebrother (Changing host)
13:45:37 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
13:46:01 Join Topy [0] (
13:46:34 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier.
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] (
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] (
14:28:44fmlInteresting: 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:57fmlSame for lseek, fsync and read.
14:31:52pamaurythe magic for all those functions is quite a nightmare imo
15:06:08 Join Buschel [0] (
15:09:30Buschel[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:11Buschel[Saint]: I have prepared a version with longer sleep() ->
15:14:38 Join Topy44 [0] (
15:22:42 Quit Buschel (Remote host closed the connection)
15:30:04 Join bertrik [0] (
15:30:04 Quit bertrik (Changing host)
15:30:04 Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
15:33:45 Join CaptainKewl [0] (
15:36:39 Quit kevku (Quit: KVIrc 4.0.2 Insomnia
15:41:38marazsoap: 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:02kugelthe 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:32marazkugel: 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:58TheSeven|Mobilei'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:27TheSeven|Mobileit 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:38TheSeven|Mobilewanted to skip back to the beginning of it
15:56:49TheSeven|Mobilei 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:25TheSeven|Mobilefurther 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:11TheSeven|Mobilethen i paused and resumed playback, and it realized that it was at the end of the playlist and stopped playback
15:58:17TheSeven|Mobileas just 42 tracks over here
15:59:00[Saint]Good catch.
15:59:12TheSeven|Mobilethen i just entered the same folder and hit the first track, erasing the old dynamic playlist
15:59:27TheSeven|Mobilecan you reproduce that?
15:59:33[Saint]yep, you've definitely discovered a bug.
15:59:39TheSeven|Mobilethat 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 should not be an issue.
16:01:08[Saint]apparently it always expects to find one?
16:01:27[Saint]who knows,' almost certainly wasn't tested in this case.
16:01:34[Saint]it's quite obscure ;)
16:01:38[Saint]Good catch.
16:01:54soapmaraz, very slow to the nano
16:02:21soapsudo dd if=/dev/sdb2 of=/dev/null bs=64K gave be 5.7MB/s FROM the nano
16:03:01pixelmaI believe that is an ooold problem at track changes, IIRC it doesn't even have to do with %pE or %pS
16:03:03soapand 2.8 MB/s TO the nano is like 50% higher than what I would get.
16:03:28 Join simabeis [0] (
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:32TheSeven|Mobilebut 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:30TheSeven|Mobileafter 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:08TheSeven|Mobilethen 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 <timeout_value> %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:36TheSeven|Mobileafter rebootingg it, i could play the very same tracks perfectly fine
16:09:10pixelmait's just like no metadata then, even no filename
16:09:43[Saint]pixelma: they are the same? they always expect a "next <blah>?"
16:09:53TheSeven|Mobilealso, 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] (
16:10:12TheSeven|Mobileso this part of the problem might point to hardware instability
16:10:13pixelmaif "filename" is untrue then you know it's the last track
16:10:27TheSeven|MobileBuschel: You're the one I was looking for :)
16:10:38*Buschel hides away
16:11:01TheSeven|Mobilewere 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:25pixelmaor on hwcodec "not buffered yet"
16:11:31Buschellet me check
16:11:48TheSeven|Mobilemy 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] (
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,'s a case that hasn't come up until now.
16:12:31BuschelTheSeven|Mobile: no, only LCD related stuff
16:12:47pixelma[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:24pixelmait is a code problem which I think exists since MoB or so - more or less obvious
16:16:55 Join GeekShadow [0] (~Antoine@
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:20TheSeven|MobileBuschel: could our power management be a bit too aggressive?
16:20:45BuschelI did no experience any problems so far...
16:21:25DreamxtremeI'd like to report a bug but i think it might be already reported in different words
16:21:58Dreamxtremeon the Ipod Video 80GB playback stops after skipping lots of tracks
16:22:09Dreamxtremeyou have you reboot the player
16:22:30***Saving seen data "./dancer.seen"
16:23:39CIA-7New commit by Buschel (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:54CIA-7r28933 build result: All green
16:26:03Dreamxtremeyes sounds like it
16:26:34Dreamxtremeok 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:50Dreamxtremeopened a task
16:35:57saratogai've seen that before, i think its a playback.c bug
16:37:23 Part LinusN
16:46:41CIA-7New commit by Buschel (r28934): Submitted the wrong file with r28933.
16:48:36CIA-7r28934 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] (
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@
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] (
17:35:09 Join Alchimysta [0] (
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] (
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] (
17:51:44 Join Buschel [0] (
17:52:36webguest_jThanks 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:28BuschelTheSeven: what issues made you think of to tight power management settings? the playback issues?
17:54:05TheSevenplayback 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:37Buschel[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:46BuschelTheSeven: 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:18Buschel[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:33TheSevenBuschel: you only want to add those writes to MIUSDPARA?
18:01:54BuschelTheSeven: yes
18:01:59TheSevensounds 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] (
18:06:05BuschelTheSeven: you also think its better to base on the Apple OF settings? those are a bit less tight regarding row cycle time.
18:07:01Buschel(and row cycle time)
18:07:16Buschelahem, and row active time
18:07:19TheSevendeviating from this would require extensive testing as they're using several different chips
18:08:03Buschelcan we be sure the OF settings are the same for different chips?
18:08:09TheSeveni 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:29TheSeveni didn't find differences
18:09:16 Join the_Kyle [0] (~kyle@
18:09:28BuschelI could also read the settings for boosted and derive the unboosted register settings from it
18:10:19 Join MethoS- [0] (~clemens@
18:10:27Buscheltoo much magic though...
18:10:50 Join Keripo [0] (
18:12:41TheSevenwe're pretty sure apple always initializes that to the same value, and iloader will do so as well
18:14:22Buschelok, I wil just derive the 48MHz settings from the 96MHz ones. Also, I will only add those MIUSDPARA writes for nano 2g.
18:14:55the_KyleAm 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:03Buschelthe 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:30the_KyleThis file seems to be correct based on its comments.
18:16:59gevaertsthe_Kyle: yes. Be careful with that one though. If you make a mistake, fixing it involves opening the player and shorting pins
18:17:02gevaerts(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:49the_KyleWell, 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] (
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] (
18:26:22the_KyleI 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:42saratogathe_Kyle: pastebin your diff
18:32:07*the_Kyle is waiting for pastebin. It's slow today.
18:36:53saratogathe_Kyle: you wanted to remove the USB check right?
18:36:58saratogai think you just removed the button check
18:37:05linuxstbTheSeven: 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:09saratogaalthough its hard to tell since theres so many white space changes
18:37:10the_KyleButton still works.
18:37:22saratogawell then you tried to remove it :)
18:37:37the_KyleI didn't think I changed any spacing.
18:38:07the_KyleMaybe something I did in the commenting?
18:39:02saratogalooking at that S file, it checks the buttons first, and then checks the USB
18:39:15saratogait looks like you just made some changes to the button code, but left the USB untouched
18:39:19TheSevenlinuxstb: 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:38saratogai would revert your changes, and then search through the text for "USB", then go from there
18:39:56linuxstbTheSeven: No, but I've seen your comments here - congratulations!
18:40:19saratogabut 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:34the_KyleInterestingly, that was what I thought I did.
18:40:39TheSevenlinuxstb: so i think all the needed drivers should be done now :)
18:41:17the_KyleI originally tried commenting out the boot_of line, but that also seems to have no effect.
18:42:05the_KyleI 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] (
18:49:03 Quit mirak (Remote host closed the connection)
18:49:15the_KyleOh. 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] (
18:52:37kugelC comments work because the file goes through cpp
18:56:30the_KyleI assume I can leave everything as it is in #ifdef SANSA_CLIPV2 since I'm working with a Clip+.
18:59:33the_KyleIs 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:01kugelmake -C dualboot/
19:00:37the_KyleAh. I think that's my other problem. I just did make.
19:01:17 Quit bmbl (Quit: Verlassend)
19:03:56the_KyleIt's trying to use arm-elf-gcc, which I thought tools/ was supposed to pull in, but it gives me "command not found."
19:05:01 Join einhirn [0] (
19:05:01*the_Kyle is surprised that mkamsboot even worked at all.
19:05:27 Quit Buschel (Ping timeout: 276 seconds)
19:07:36kugelthe_Kyle: change it to call arm-elf-eabi-gcc
19:08:00the_Kylekugel: 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] (
19:36:34 Join mirak [0] (
19:38:06 Join Buschel [0] (
19:40:26 Join Keripo1 [0] (
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:03the_KyleTrying 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:22the_KyleDiff is at
19:50:04 Join toffe82 [0] (
19:50:14 Join JesusFreak316 [0] (
19:52:21 Quit Buschel (Ping timeout: 260 seconds)
19:55:31kugelthe_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:01the_KyleDid I miss something when I rebuilt mkamsboot? Do I need to do anything with the .arm files it made during build?
20:05:01the_KyleOn 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:45the_KyleIt's a minor annoyance, because I only hear it when the signal is weak.
20:06:48the_KyleBut 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@
20:32:26 Join Buschel [0] (
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] (
20:40:39saratogawhy doesn't editing firmware/SOURCES trigger rebuilding files in /firmware unless I do a make clean?
20:40:46saratogai 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] (
20:49:16 Quit mortalscan (Remote host closed the connection)
20:49:32 Join mortalscan [0] (~mortalsca@
20:49:42perfectdrughey haven't been here for a while
20:50:30perfectdrugI updated thought this might help :)
20:51:09 Join CaptainKwel [0] (
20:51:24 Quit CaptainKewl (Ping timeout: 276 seconds)
20:51:49 Quit JesusFreak316 (Ping timeout: 240 seconds)
20:59:58 Join Xerion_ [0] (
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 (
21:03:05 Join perfectdrug1 [0] (
21:05:40 Join JesusFreak316 [0] (
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] (
21:21:32 Quit GodEater (Read error: Operation timed out)
21:21:37 Join GodEater [0] (
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:50pamaurythis percentile is not supposed to be accurate
21:23:49[Saint]Well, that's good it's now at ~220% :P
21:23:50CIA-7New commit by Buschel (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:39BuschelYep :)
21:24:41[Saint]Those numbers come from Nano2G testing I assume.
21:25:08BuschelYes, 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:30 Join niekie [0] (quasselcor@CAcert/Assurer/niekie)
21:25:33 Quit ps-auxw (Ping timeout: 272 seconds)
21:25:39Buschelafaik the ports sleep
21:25:49CIA-7r28935 build result: All green
21:25:55[Saint]Ah, I take it you don't use it much gevaerts...?
21:26:09gevaertsbertrik has a few, markun has one or two, and mine are distributed :)
21:26:25gevaertsoh, and Bagder has one too I think
21:26:48gevaerts[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:44gevaertsWell, 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:36gevaertsSpeaking of thinking...
21:29:55gevaertsWhat's the current status of the various AMS microSD problems?
21:30:18gevaertsAnd/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:18saratogagevaerts: occasional problems with random cards
21:32:22 Join froggyman [0] (~seth@unaffiliated/froggyman)
21:32:32gevaertsSo still not resolved?
21:32:50saratogatheres been some improvement since 3.7, but not resolved
21:33:12gevaertshm, ok
21:33:44 Quit feisar- (Ping timeout: 264 seconds)
21:33:50saratogai think problems are fairly rare since no developer has a problem card
21:34:04 Join feisar- [0] (
21:34:18gevaertsAren't they typically with large cards?
21:34:30*gevaerts isn't sure if many developers have those
21:34:51saratogai think i've seen them with smaller cards, but yeah many are large cards
21:34:56saratogamy 16GB works great though
21:35:53gevaertsThe 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] (
21:36:13 Quit Galois (Client Quit)
21:36:31gevaerts"fixed" is much easier to decide on :)
21:37:34 Join Galois [0] (
21:38:52 Quit Galois (Client Quit)
21:39:55saratogai 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] (
21:45:29 Join thomasjfox [0] (
21:48:34 Quit factor (Read error: Connection reset by peer)
21:49:37GeekShadow[Saint], I got one M3
21:49:53GeekShadowbut i'm not involved in development of rockbox
21:53:30 Join factor [0] (~factor@
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@
22:05:17perfectdrug1themeeditor looks like this on my machine (ubuntu 10.10 and looked the same with 10.04) what could be wrong?
22:08:29 Join Judas_PhD [0] (
22:10:14perfectdrug1what are this 2 blank windows suposed to show?
22:15:45Buschelsoap: you there?
22:22:39***Saving seen data "./dancer.seen"
22:26:42TheSevenwhen implementing a codec driver, what should i set the volume setting range to?
22:26:48TheSevenjust the master volume range of the codec?
22:27:01TheSevenor should i account for additional digital gain values?
22:28:37saratogaTheSeven: the output stage of the codec has a maximum voltage level, that should be 0 dB
22:28:55saratogaif you have additional digital gain, that should be configured such that it pushes the level above 0 dB
22:29:09TheSeveni think it can go up to +12dB or something, with clipping starting at slightly above 0dB
22:29:22saratogathats fine for rockbox
22:29:49saratogathe 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:23TheSevenhuh? shouldn't 0dB be 0dB?
22:30:50TheSeveni mean 0dBV of course
22:31:02saratoga0dB 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:14saratoganot necessarily referenced to 0dBv
22:31:28saratogai think most players clip around 300-600mV FWIW
22:31:57saratogathey'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:07TheSevenah, that's new to me
22:32:20TheSeveni thought we calibrated them to 0dBV (like it seems to be true for the wm8975)
22:32:35TheSevenmy nano2g can drive ~1100mV without clipping
22:32:49TheSeven(into a line load)
22:32:50TheSevenand ~900mV into 16 Ohms
22:33:07saratoga0dBv is 1 volt, which is within about 1-2 dB of most players at least
22:36:10Buschelsoap: can you check this patch on your nano 1g ->
22:36:29Buschelsoap: the YUV functionality is of interest. and −− if it works −− the speed.
22:36:45TheSevennow, once again, should i use DAC gains and similar things (that affect line out) to extend the volume range?
22:37:45BuschelTheSeven: I would say yes, if main volume does not reach at least -75 dB
22:39:06TheSevenIIUC the master volume goes down to -102dB, and i can get another -58dB at the amplifiers
22:39:12TheSeventhat would be -160dB
22:39:13BuschelTheSeven: 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:34BuschelTheSeven: -102 dB is more than sufficient to my eyes (or better: to my ears)
22:39:48TheSevenhm, but those probably affect line out AFAICT
22:40:38TheSeventhe quirky solution would be setting master to -12dB, line out to +12dB, and the headphone amp to -58dB to reach -70dB
22:40:44TheSeven(without affecting line out)
22:41:03TheSevenif we want to go lower than that, we probably need to get the lineout down as well
22:41:56Buschelah, 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:00saratogathat should be sufficient
22:42:42 Join Fuhrer [0] (75d3557b@gateway/web/freenode/ip.
22:43:09 Quit Fuhrer (Client Quit)
22:43:14TheSeventhis beast is slightly complex:
22:43:19TheSevenpage 26 onward
22:44:26BuschelTheSeven: also contains the manual remark that lineout is affected.
22:45:25TheSeveni'll probably just implement the -58..+12dB scale for now, we can add the quirks later
22:45:33Buschelof course
22:47:04TheSevenurgh. 1.5dB step size for the tone control. how do i handle that?
22:47:11TheSevendo we use the hardware tone control at all?
22:47:20TheSeven(if not, i can power down the DSP block)
22:49:11Buschelwe use hardware tone control to avoid the CPU load
22:50:49TheSevenhm, how do i handle those stupid 1.5dB steps then?
22:51:10linuxstbTheSeven: I'm sure other targets have 1.5dB steps - IIRC, Rockbox uses units of 0.1dB internally
22:51:36TheSevennot in struct sound_settings_info
22:52:31BuschelTheSeven: you could introduce a lookup table
22:52:57jhMikeScheck gigabeat f's code for details
22:53:43saratogai 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:22saratogausually we just map the steps as closely as possible if they don't go 1dB at a time
22:57:44TheSevensaratoga: look at those curves on page 69, especially the bottom left one :)
22:57:53TheSeventhat isn't really advertising material for them :-P
22:58:31saratogaheh they really measured everything
23:00:10jhMikeSsaratoga: it's been done on gigabeat f, 1.5dB steps are easy and even voice properly
23:00:15saratoga0.5-0.7mW for DSP effects, i wonder how much more efficient that is then CPU
23:00:33saratogayeah i know
23:00:58TheSevensaratoga: a lot
23:01:03soapBuschel, back, and can test.
23:01:06TheSevendoes SOUND_STEREO_WIDTH need support from the codec?
23:01:26saratogajhMikeS: all the sansas are like that too
23:01:30TheSeveni can't see it being referenced anywhere in the wm8975 driver
23:02:10Buschelsoap: great, I do not expect that this works with the first shot...
23:02:17saratogaTheSeven: tone control is about equal to one DSP filter right? so thats a couple MHz, how efficient is your CPU?
23:02:35saratogaactually if your'e arm9E now its probably even less mhz
23:02:38TheSeveni doubt the cpu can do that in the µW range
23:03:48saratogaare you sure?
23:04:10saratogaeven the old as3525 only needed 250uW per MHz, and if you only need ~2MHz
23:04:12TheSevendepends on how many MHz that actually is
23:04:18jhMikeSTheSeven: SOUND_STEREO_WIDTH is a sw effect
23:04:26TheSeveni have no power measurements at all so far for the ipod classic
23:04:47saratogaif 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:32TheSeventhose thingys seem to be rather bad in terms of memory bandwidth
23:05:44saratogawhats the nano2g battery life like?
23:05:53saratogafor some reason I thought it was much better then the sansas
23:06:03 Join fml [0] (
23:06:08TheSevenjhMikeS: is SOUND_BALANCE also an SW effect, or is that implemented by shifting channel gains in the codec?
23:06:21TheSevensaratoga: ask Buschel :)
23:06:40jhMikeSchannel gains mostly
23:06:44saratogaclip+ is about 17 hours
23:06:59jhMikeSI think there's one dap with a sw volume control
23:07:29saratogayeah the Ingenic one
23:07:32saratogaalso, MIPS
23:07:36saratogaweird little device
23:08:28saratogaFWIW 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:37saratogaslow going though since i suck as asm
23:09:39saratogaBuschel: did you try test_codec with r28935?
23:09:49saratogai 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:40Buschelsaratoga: I tried a while ago before I submitted. the effect was measurable but minor (for mpc)
23:11:05saratogai guess any codecs that see a big improvement are probably ones were we don't use much IRAM
23:11:11Buschelsaratoga: I guess the more IRAM-optimized a codec is the less effect will be seen
23:11:30Buschel:) same thougts
23:12:25TheSevendamn, i don't really have time to complete that port
23:12:33TheSevenit's way more work than i had expected
23:12:42bertrikgevaerts, I recently did a fix for AMSv2 uSD card problems that could be backported
23:12:45saratogathe classic?
23:13:21bertrikthe fix was of the sprinkle-arbitrary-delay-until-it-works kind though
23:13:27TheSevensaratoga: 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:53saratogayeah i believe that
23:13:59saratogai still don't understand how our drivers actually work
23:14:04saratogajust bits and pieces
23:14:08bertrikand the AMSv1 just had the clocking change patch reverted, so uSD should work on AMSv1 again too
23:14:21gevaertsbertrik: are there people left for whom it doesn't work?
23:14:28soapBuschel, 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:30jhMikeSsaratoga: 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:51saratogayou dsp_armv6?
23:14:57bertrikfor AMSv2 I hear nothing but good news now
23:15:30gevaertsOK. If bad reports don't come in during the next few days, I'd say we do a 3.7.2
23:15:39saratogabertrik: is that committed?
23:15:48jhMikeSsaratoga: only the sample_output_mono/stereo really got better by any significant margin
23:15:56bertriksaratoga, yes, but only to trunk, not to any branch
23:16:44TheSevengevaerts: 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:57gevaertsTheSeven: not *planning* :)
23:17:07gevaertsWe're supposed to be doing that now!
23:17:11jhMikeSsaratoga: of course, there wasn't much to do because it stayed 32 bits
23:17:16gevaertsOh, right, I see what you mean
23:17:24bertrika freeze could be some other problem
23:17:26gevaertsNo, I don't think we'll maintain old releases
23:17:46Buschelsoap: ok, found three issues. next try:
23:17:47gevaertsYes, I don't trust any freeze report until the filesystem has been checked...
23:17:49saratogajhMikeS: 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:55TheSeveni don't think anybody has ever really discussed how long we should keep the old branches alive
23:18:45saratogabertrik: i mean theres still some outstanding issues with that fix, obviously it helps some people's problem
23:18:53gevaertsTheSeven: indeed not, but I also don't think anyone wants to volunteer to maintain previous release branches
23:18:54saratoga"even with that fix"
23:19:25gevaertssaratoga: if the problem is related to the driver and not to bad tracks or a bad filesystem
23:19:29jhMikeSsaratoga: it looks like it needs reordering at least
23:19:40 Join JdGordon| [0] (
23:19:40 Quit JdGordon| (Changing host)
23:19:40 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon)
23:19:50Buschelsoap: wait, typo in the code, next patch follows in a few secs
23:20:07saratogawas going to use 16 bit values for the gain, drop the long multiplies, and then unroll it 6x, should fly on arm11
23:20:31saratogathanks to those nice 64 bit load/stores
23:20:38 Quit anewuser (Ping timeout: 240 seconds)
23:22:40saratogahmm test codec's dsp test function seems to be broken for me
23:22:59jhMikeSsaratoga: hmmm, I did try more than the 2x unroll already there−− diminishing returns, but maybe without long stuff could be different
23:24:44CIA-7New commit by rmenes (r28936): Rockbox Utility: Add in support to install Rockbox on the Philips ...
23:25:31 Join LambdaCalculus37 [0] (
23:25:31 Quit LambdaCalculus37 (Changing host)
23:25:31 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37)
23:25:55soapfullscreen 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:07saratogaarm11 can do a load/mac/store in 2 clocks, so unrolling is helpful to keep loop overhead from getting too high
23:26:19saratogabut yeah 4x was probably fine, but i had the registers so why not
23:26:42CIA-7r28936 build result: All green
23:26:43 Join GeekShad0w [0] (~Antoine@
23:27:00jhMikeSwith branch prediction and code caching I don't think loop overhead is so great
23:27:25saratogaif a branch is consistently taken in a loop, is it 1 cycle?
23:27:27Buschelsoap: what is the speed like? I would like to see whether further debugging would be helpful...
23:27:30soapI can start photographing the exact screen output if that would help in diagnosis, Buschel.
23:27:31jhMikeSI don't remember if those are predicted though
23:27:35saratogai haven't figured out branches on arm11 yet
23:27:57jhMikeSthere are details in the guides on what's predicted and not
23:28:01soapBuschel, The graphical glitches as I describe happen at the start of the YUV fps test and crash the system.
23:28:06soapI never see the speed.
23:28:10saratogai'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:19saratogajust don't know how long it takes to issue
23:28:29soap80.5 fps for full-screen LCD updates, but that's the only number I get to see clearly before the death.
23:28:48Buschelsoap: that should not happen... let me check again
23:29:26soapoh, and I'm running unboosted, yell if you want me to boost.
23:29:37Buschelsoap: that's fine
23:29:48soapJust got back from the gym when I saw your highlight, I'm going to hop in the shower, brb.
23:32:09jhMikeSappently 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:30soapok Buschel
23:41:47Buschelstill reviewing
23:47:19Buschelsoap: easier approach ->
23:49:22soapdid you just refactor your approach while I washed?
23:49:38 Join Bagder [0] (~daniel@rockbox/developer/bagder)
23:50:24Buscheloh, 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] (
23:51:48soapsame screen pattern as before in test_fps
23:52:13Buschelstill crashing?
23:52:18soap(this was the 4th patch, same pattern as the third patch)
23:52:36soapyes, well unless I totally forget how to exit the plugin while the screen is corrupted.
23:52:50Buschelpressing Menu
23:53:26 Quit JesusFreak316 (Ping timeout: 240 seconds)
23:53:32soapis 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] (
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.
23:53:56Buschelsoap: 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:30soapI can start photographing the exact screen output if that would help in diagnosis, Buschel.
23:58:53Buschelsoap: why not, maybe it gives a hint

Previous day | Next day