--- Log for 21.02.105 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 17 days and 15 hours ago 00.00.01 # see you tomorrow! 00.00.16 # yep 00.00.17 Quit amiconn (Nick collision from services.) 00.00.18 Nick amiconn_ is now known as amiconn (~jens@pD9E7F903.dip.t-dialin.net) 00.00.41 Quit CoCoLUS () 00.00.57 # a bloody optimization guide would have been great 00.01.03 # but doesn't seem like motorola has one 00.06.36 Join Renko [0] (~Renko@host81-154-33-157.range81-154.btcentralplus.com) 00.07.13 Quit Stryke` ("Friends don't let friends listen to Anti-Flag") 00.07.38 # how the hell motorola has managed to get an mp3 decoder running in 19mhz is beyond me :V 00.07.50 # :P 00.08.05 # I assume they know the processor pretty well :) 00.08.11 # no shit 00.08.38 # Would there be other bottlenecks on the iRiver? Maybe the memory? 00.08.51 # wouldn't know 00.09.03 # how could profiling be added to the codecs? 00.09.11 # Patr3ck: with difficulty 00.09.28 # especially if you mean with gprof and those tool 00.09.28 # s 00.09.33 # no 00.09.52 # add tick counts to the codec functions? 00.09.58 Quit pillo ("CGI:IRC (EOF)") 00.10.14 # it would have to be something like that, yes 00.10.24 # but we'll need something lower resolution than ticks 00.10.46 # why? 00.11.21 # well, 10ms is pretty much, and if the function executes quickly, it'll seem like it's using more time than it is 00.11.51 # I see, is a higher resolution possible with existing stuff in rockbox 00.11.55 # don't know 00.11.59 # should be 00.12.04 # ok 00.12.21 # besides the resolution, how would it be added 00.13.07 # the information must be added to a central information store from all over the codec 00.13.08 # by simply just adding timing to the functions and storing results in a global array, i guess 00.13.14 # i haven't done manual profiling before 00.13.40 # all the codecs would benefit from some simple common functions I guess 00.14.51 # just wondering were these functions should be placed... 00.24.50 Join ashridah_ [0] (ashridah@220-253-120-66.VIC.netspace.net.au) 00.25.04 Quit ashridah (Nick collision from services.) 00.25.08 Nick ashridah_ is now known as ashridah (ashridah@220-253-120-66.VIC.netspace.net.au) 00.26.01 # hmm 00.26.13 # perhaps codecs should be placed in sram 00.26.35 # that would put a size restriction on them, for sure 00.27.04 # should make an interesting test if nothing else 00.27.37 Join condor9 [0] (jch@xmission.xmission.com) 00.27.42 # i really think it does matter quite a lot 00.27.48 # there are tons of memory accesses 00.27.50 Quit muesli- (Read error: 110 (Connection timed out)) 00.28.20 # I recently switched from 2.2 to 2.4 and now my config.cfg won't automatically load. Is this a feature? 00.28.25 # * amiconn notices an active bagder 00.28.44 # alive at least ;-) 00.28.49 # :) 00.29.15 # Did you read about my idea about a clean fix for the sim compilation problems in the logs? 00.29.38 # no 00.29.57 # about what time/date? 00.32.10 # look at http://www.rockbox.org/irc/rockbox-20050220.txt starting around 00:30 00.33.23 # How do you get the config file to load on startup? 00.34.37 # what do you think would be faster, preload 8 coefs into d0-d7, then do eight consecutive mac operations, or do eight interleaved mac and load operations? 00.34.44 # condor9: .cfg files are never loaded automatically. 00.35.25 # condor9: The auto-loaded rockbox configuration is partly stored in the realtime clock (recorder models only), and partly in an unused sector on the harddisk 00.35.44 # Hmmm... but 2.2 used to correct? 00.35.59 # Seems odd that I have to load a config everytime. 00.36.24 # This configuration is invalidated when the configuration routines need to be changed, so with the 2.2->2.4 transistion, they are set back to the defaults 00.36.47 # Yuck. :( Thanks amiconn. 00.36.51 # If you saved the config to a .cfg file before, you should be able to load that with the new version 00.37.16 # Yeah I can load it, I just hate having to manually load it everytime. 00.37.21 # Once loaded, and the unit shut down properly, the settings should be autoloaded again 00.37.50 # amiconn: I'm not sure things are that easy, but I generally agree that POSIX things that Rockbox does, but that are simulated, should be ifdef'ed/moved out so that they are not done for simulators 00.38.19 # The ifdefing is problematic, as we have seen 00.38.23 # amiconn: Oh. Well, they aren't for me. I have a recorder (V1) with 2.4 built from source. 00.39.11 # condor9: How do you shut down the box after loading your settings? 00.39.34 # amiconn: yes it is, but what's the fix? renaming include files to not use posix names? I don't like that 00.39.57 # Bagder: No, I think my suggestion should work: 00.40.31 # - put all rockbox includes that are called the same as system includes and define posix functions into a separate include dir. 00.40.42 # amiconn: I hit the off button, it prompts to off again so I hit off. I also check to make sure there is some disk activity after saving my settings. 00.41.07 # Bagder: This requires additional functions which are not posix moving to other includes 00.41.14 # amiconn: but I like the sim to use the Rockbox-provided string and memory functions for example, not the compiler's or system's native ones 00.41.37 # I could of course live without them if forced ... :-) 00.42.04 # Then consider these functions as non-posix.... 00.42.35 # The dir with the posix includes should then be in the include path for target compiles, but not for sim compiles 00.42.46 # if that works, I'm all for it 00.43.02 # I doubt it will be that simple 00.43.36 # If you want to have certain functions always provided by rockbox, then this is of course also necessary for the sources under uisimulator/ 00.43.49 # Otherwise we'll get the same clashing again 00.44.22 # And of course, functions with the same name as a posix function, but with different semantics should be renamed 00.44.40 # The obvious example is sleep() 00.44.51 # sleep should be renamed indeed 00.45.04 # but opendir() is a nasty example 00.45.12 # Why? 00.45.24 # (I'm not a posix expert....) 00.45.40 # because rockbox uses and assume a proto by its own, and the simulator must "hijack" it to add a layer between rockbox and the OS 00.45.50 # hm 00.45.54 # no perhaps thats not a problem 00.46.03 # since it uses posix 00.46.25 # Maybe it is :( 00.46.44 Quit condor9 ("Leaving") 00.46.44 # The file system emulation in a sub-dir, I forgot... 00.47.01 Part hubble 00.47.34 # chroot :) 00.48.38 # There is no chroot() in windows... (thinking win32 sim, it should work in cygwin for the x11 sim) 00.49.19 # ahh, you support msvc as well, yes 00.49.23 # forgot about that 00.49.39 # Not msvc, but building native win32 sim with cygwin gcc 00.49.56 # well, yes, that as well 00.50.04 # The msvc support was there, but is surely broken by the new build system 00.53.45 Quit Renko ("Leaving") 00.57.36 # Bagder: Where are those sim_* functions defined? 00.57.54 # in common/io.c 00.58.20 *** Saving seen data "./dancer.seen" 00.59.41 # So what do you think about the following approach (it's actually similar to how things currently work iiuc): 01.01.16 # In each rockbox include that defines posix functions, set the appropriate sim_* define, selected by #ifdef SIMULATOR. 01.01.28 # All code in apps/ and firmware/ should then always use these includes 01.01.29 Quit midk (Read error: 54 (Connection reset by peer)) 01.02.11 # The code in uisimulator/ however should then never use these includes, but the system ones. 01.02.24 # Then it should actually implement the sim_ 01.02.35 # * equivalents by using the system functions 01.02.37 # that sounds reasonable 01.03.21 # but then we'd need a dir with include files that aren't used for the sim 01.03.30 # yup 01.03.38 Join Shity [0] (Shity@modemcable147.112-70-69.mc.videotron.ca) 01.03.49 # anyone here ? 01.03.52 # 6yes 01.03.59 # stupid question 01.04.00 # we could actually just define for example "firmware/include/" to be that dir, and the "clean it up" to work as you described 01.04.00 # but 01.04.04 # are you italian 01.04.08 # hell no 01.04.20 # where can i find a channel with italians 01.04.22 # i need some help 01.04.24 # c'mon preglow, admit it :-) 01.04.25 # don't ask me 01.04.33 # bagder are you ? 01.04.33 # why do you need italians? 01.04.39 # aren't us norwegians good enough? 01.05.07 # i got a gay assignement to do and i just got couple of easy questions 01.05.12 # Bagder: i would have to be excessively drunk 01.05.15 # and i need an italian to asnwer them 01.05.20 # Rofl 01.05.21 # then go somewhere else 01.05.35 # /kick Shity 01.05.38 # yeah thanks for your help .. faggot 01.05.40 Part Shity 01.05.45 # bingo 01.05.46 # ahh, trolls... 01.06.24 # it gets boring, really 01.06.36 # Bagder: Using firmware/include for that actually sounds reasonable. Iirc these are mostly posix functions anyway. 01.06.39 # Haha 01.06.47 # That was... different. 01.06.56 # It's not like this is a particularly large channel is it? 01.07.01 # amiconn: yes, that's why I think it would be a good dir to define to be this "target-only" dir 01.07.16 # rasher: there are more than enough complete fools to go around 01.07.22 # rasher: even in the smallest of channels 01.07.24 # preglow: good point 01.08.43 # Bagder: This would work rather nicely, if I didn't overlook something: 01.09.38 # #ifdef SIMULATOR 01.09.56 # #define open(blah) sim_open(blah) 01.09.58 # #else 01.10.13 # int open(char *blah); 01.10.18 # #endif 01.10.36 # not even #else, since it needs the proto for sim_open() 01.11.14 # Ah, yes, this has to go before the #else then 01.11.42 # The proto after #else is of course necessary for building the target 01.12.15 # yes, open() is needed for target and sim_open() for sim 01.12.23 # so: 01.12.26 # ifdef SIM 01.12.37 # #define open() sim_open() 01.12.41 # #endif 01.12.46 # int open(char *bbbbb); 01.13.11 # hm 01.13.15 # ...and exactly this would not work, imho 01.13.18 # no 01.13.26 # #ifdef SIMULATOR 01.13.29 # and isn't this file in the target-only include dir anyway? 01.13.51 # the one with the open() proto I mean 01.14.10 # bed, later all 01.14.19 Quit preglow ("fugleskremsel") 01.14.32 # No, it is an include that is used by the main rockbox dirs only, but also for building the sim. 01.15.01 # I.e. files under apps/ and firmware/ should always use it, but files in uisimulator/ must never use it 01.15.22 # ah, right. I'm following 01.15.52 # So the main rockbox code will compile normally with open() etc. for target, but with the sim_ equivalents when building a sim 01.16.01 Quit thegeek (Read error: 104 (Connection reset by peer)) 01.16.10 Join G [0] (na@ti521110a080-0418.bb.online.no) 01.16.32 # right, but the file that provides an open() prototype, shouldn't it provide a sim_open() prototype when built for the sim? 01.16.37 # The files in uisimulator/ then have to implement all those sim_ equivalents, and must not use the mentioned includes, but rather the system includes 01.16.56 # Yes, that was my addittion after your comment. 01.16.58 # So: 01.17.05 # #ifdef SIMULATOR 01.17.15 # yes, we must differ between files that needs simulation and files that implement simulation 01.17.16 # #define open() sim_open() 01.17.26 # int sim_open(char *bbbbb); 01.17.30 # #else 01.17.32 # int open(char *bbbbb); 01.17.34 # #endif 01.17.57 # I don't see the diff between this and my version, but it doesn't matter much 01.18.22 # ah, possibly because the protos differ of course 01.18.29 # yup 01.18.44 # but that might cause compiler warnings 01.18.55 # Why? 01.19.24 # The prototype has to be exactly identical except for the name 01.19.38 # right 01.19.53 # but then you don't need two versions, since the define will work for the proto as well 01.20.06 # never mind, its not important for this discussion 01.20.19 # Ah, yes, you're right 01.20.37 # That looks even cleaner... 01.21.41 # The difference between the rockbox prototype and the system prototype (and possible change in behaviour, as for the file system simulation) are then handled by the sim_ function implementation in uisimulator/ 01.21.57 # yes 01.22.36 # Of course this means to have a sim_ implementation for every posix function, even those which don't need data munging, but the overhead introduced by that shouldn't matter 01.22.36 # checking now, the uisimulator/ files already seem to be built without using the include dir 01.23.18 # amiconn: no, I think it would make the sim clean and understandable even if there's a tiny overhead 01.23.38 # The posix functions that we want to always use the rockbox implementation will simply not get a sim_ define 01.25.02 # We wouldn't even need to rename sleep(), but I think it should be done because it is not exactly posix... 01.25.29 # I don't have an idea what it should be called though... 01.25.45 # hehe, me neither 01.28.21 # so basically, if we move the sim_* logic into the include/* headers, we should start getting it working right 01.29.00 # of course, there are some non-posix functions we want sim_* versions of too 01.29.02 # Yes, I think so too. 01.29.06 # is WAV codec done? 01.29.23 # ...most notable is lcd_update() 01.29.31 # Ah, yes. 01.29.46 # Well, these could use the same mechanism 01.30.01 # XShocK: No. 01.30.10 Join AC [0] (~5078751e@labb.contactor.se) 01.30.19 # XShock: Are you ready for it? 01.30.35 # This sounds like a clear separation of rockbox code (which needs simulated functions) and simulator code (which provides them) 01.30.48 # exactly 01.31.14 # linuxstb: I think yes. 01.31.45 Quit mrmags ("Download Gaim: http://gaim.sourceforge.net/") 01.31.47 # The way it provides them does not matter. Either it uses the system functions without changes, the system functions with some mangling (file, dir), or something completely different (lcd) 01.32.28 # XShock: Does that mean you've made progress with sound? 01.33.33 # yes, me and hubble 01.33.45 # sounds very good actually. 01.33.49 # amiconn: I get a feeling this is the correct way forward 01.34.01 # I have to agree. 01.34.30 # How do you think we should tackle this? Specifically, could we share the work somehow? 01.35.44 # lemme dig into it tomorrow and see how much I can fix "at once", and then we'll talk more tomorrow 01.36.18 # XShock: Congratulations to you and hubble. Can you give us any more information? How does it work? 01.36.37 # I'm going away on wednesday for a week, so I just have line one and a half day before that 01.36.43 # like 01.36.55 # currently it works on AUDIOTICK interrupt 01.37.42 # does not use DMA, since i couldn't figure out how to control its speed. 01.38.04 # with AUDIOTICK 44.1 16-bit works and souns well. 01.38.21 # *sounds 01.39.04 # i feed several samples into PDOR3 on each AUDIOTICK 01.39.18 # Bagder: okay. 01.40.22 # sounds familiar, good ;) 01.43.48 # bedtime 01.43.50 Quit jyp ("poof!") 01.43.50 Quit AC ("CGI:IRC (EOF)") 01.44.57 # XShocK: What's next? Are you going to go back and try again with DMA? 01.45.27 Quit DMJC (Read error: 110 (Connection timed out)) 01.46.39 # I will try it, yes 01.47.17 # I would really like it to be DMA 01.47.27 # So all we need to do now is design and code an audio playback system and get the codecs running in real-time... 01.47.40 # yep. :) 01.48.02 # That assumes Linus can get the iRiver running reliably at 140MHz and solve the ATA problem... 01.48.08 # linuxstb: It seems to me that the realtime codecs part is the bigger task... 01.48.46 # Yep. 01.49.07 # did anyone try to do that m68k optimized MPEG decoder? 01.49.12 # I hope someone will have a look at the asm optimised mp3 decoder 01.49.17 # XShocK: :) 01.49.30 # :) 01.50.11 # I have the comparison on Amiga (m68k): The decoder by Stephane Tavenard is twice as fast as an optimised libmad... 01.50.15 # I've had a quick look, but haven't had a chance to try to get it running on Rockbox yet. It may need some attention from someone who know m68k asm to get that part compiling with a modern gcc. 01.50.32 # amiconn: That's promising. 01.51.21 # However, I wonder why libmad is that slow on a 140 MHz coldfire. It can do realtime on an 68060/50 (which runs at 100 MHz internally) 01.51.54 # Ah, I forgot something. The 68060 is superscalar (2 execution units) 01.54.17 # so as i understand that asm decoder is curently not compilable? 01.54.50 # I read in the README that the ASM had not been translated to gcc syntax. But I have no idea what syntax it currently is in. 01.54.54 # *compileable | compilable? which one is correct? 01.55.09 # "can not be compiled" 01.55.47 # (if you can't spell a word, use a different one) 01.57.32 # but "compilable" is cooler. :) 01.58.11 # :-). But I think the answer is no anyway. 01.59.00 # But it shouldn't take too much work - I may give it a try tomorrow evening. 01.59.25 # I usually mess up rules of russian language with english. 02.00.57 Join ghode|afk [0] (dude@host217-137-4-48.no-dns-yet.ntli.net) 02.09.11 Quit ghode|afk () 02.18.58 Quit edx (Read error: 60 (Operation timed out)) 02.21.39 Join skav [0] (skav@67-138-74-184.dsl1.merch.roc.ny.frontiernet.net) 02.30.48 Join DMJC [0] (~James@220-245-162-47-sa-nt.tpgi.com.au) 02.34.18 # Going to sleep now... night all 02.34.56 # night 02.34.59 Part amiconn 02.36.27 Quit Patr3ck () 02.58.23 *** Saving seen data "./dancer.seen" 02.59.47 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 03.12.21 Quit XShocK (" HydraIRC -> http://www.hydrairc.com <-") 03.24.24 Join midk_ [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 03.24.24 Quit midk_ (Client Quit) 03.32.33 Join wacky_ [0] (~wacky@modemcable040.196-203-24.mc.videotron.ca) 03.32.43 # hey boys and girls :) 03.35.41 Join XShocK [0] (~XShocK@pcp09492659pcs.nrockv01.md.comcast.net) 04.04.04 Quit wacky_ ("awright") 04.05.54 Join QT [0] (as@area51.users.madwifi) 04.09.21 Join edx [0] (edx@pD9EABF68.dip.t-dialin.net) 04.17.44 Quit QT_ (Read error: 110 (Connection timed out)) 04.35.15 Quit skav () 04.35.31 Quit cYmen ("leaving") 04.58.27 *** Saving seen data "./dancer.seen" 05.05.16 Join rwilco [0] (~douglas@moreen133.micro-mania.net) 05.24.48 Part rwilco ("Leaving") 05.25.17 Quit linuxstb (Read error: 110 (Connection timed out)) 05.30.36 Quit XShocK (" HydraIRC -> http://www.hydrairc.com <- IRC with a difference") 06.11.10 Join XShocK [0] (~XShocK@pcp09492659pcs.nrockv01.md.comcast.net) 06.12.25 # Hehe... cool. Rockbox plays WAV files. :) 06.12.52 # Yay :D 06.13.01 # That's damn cool indeed 06.13.10 # dma? 06.13.26 # no 06.14.03 # I can't really understand how to make DMA work here.... 06.14.19 # I don't know methods to slow DMA down. 06.14.21 # or pause 06.15.31 # But for most purposes probably current implementation will work wel 06.15.36 # *well 06.18.05 # Sounds good 06.18.26 # Well this is certainly good news :) 06.20.25 # and now codecs.... i predict is the worst problem. :) 06.22.33 Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) 06.28.01 # night all 06.29.03 Quit XShocK (" HydraIRC -> http://www.hydrairc.com <- Go on, try it!") 06.29.08 # night 06.29.13 # well the codec api 06.29.23 # hard to tune the codecs without knowing the speed 06.29.25 Quit Lurkski ("Download Gaim: http://gaim.sourceforge.net/") 06.29.40 # well, hard to know what you're aiming for, that is 06.31.11 Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) 06.32.48 Join Muntek [0] (~Muntek@adsl-68-90-41-29.dsl.hstntx.swbell.net) 06.33.37 Part Muntek 06.36.49 Join webguest39 [0] (~45568afc@labb.contactor.se) 06.37.16 Quit webguest39 (Client Quit) 06.50.39 Part Lurkski 06.50.49 Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) 06.57.35 Part Lurkski 06.57.49 Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) 06.58.31 *** Saving seen data "./dancer.seen" 07.24.54 Quit midk ("Leaving") 08.08.46 Nick ashridah is now known as Lost-ash (ashridah@220-253-120-66.VIC.netspace.net.au) 08.14.20 Join LinusN [0] (~linus@labb.contactor.se) 08.27.14 # LinusN 08.27.22 Nick Lost-ash is now known as ashridah (ashridah@220-253-120-66.VIC.netspace.net.au) 08.27.23 # hi 08.27.35 # *sigh* 08.27.40 Nick ashridah is now known as Lost-ash (ashridah@220-253-120-66.VIC.netspace.net.au) 08.27.42 # back to cooking :/ 08.27.59 # * LinusN has to reboot 08.28.01 Part LinusN 08.28.26 # gah. would help if i remembered to put the food on the heat :/ 08.36.37 Join LinusN [0] (~linus@labb.contactor.se) 08.42.19 Part Lynx_awy ("bye!") 08.44.34 Quit Lurkski (Read error: 110 (Connection timed out)) 08.50.34 Part LinusN 08.52.12 Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) 08.58.34 *** Saving seen data "./dancer.seen" 09.31.42 Join bobTHC [0] (~foo@l03v-35-141.d1.club-internet.fr) 09.31.53 # morning folks! 09.34.34 # * Zagor yawns 09.37.52 Join LinusN [0] (~linus@labb.contactor.se) 09.38.34 # * dwihno wants zzz's 09.38.51 # * LinusN wants $$$'s 09.40.14 Quit Lurkski (Read error: 60 (Operation timed out)) 09.40.20 # LinusN: Det är 3 dagar, 14 timmmar, 19 minuter och 51 sekunder kvar tills man får lön för mödan (2005-02-25) 09.40.29 # Just hang in there... :) 09.40.34 # :-) 09.43.51 Nick Lost-ash is now known as ashridah (ashridah@220-253-120-66.VIC.netspace.net.au) 09.46.20 Join linuxstb [0] (~linuxstb@dsl-212-23-31-215.zen.co.uk) 09.48.16 # Zagor: how's the free and independent life nowadays? 09.48.33 # pretty relaxed :-) 09.48.55 # :-) 09.48.58 # free? independent? 09.49.40 # yeah, i sorta... quit working. 09.51.07 # you did? 09.51.16 # are you serious? 09.51.59 # yeah. i'm only working for myself now. 09.52.41 # still feels really weird. i expect it will take a few weeks to establish some kind of routine. 09.53.24 # oh.. I wish you the best of luck 09.53.33 # thanks 09.53.55 # You'll do consulting within the Haxx sphear? 09.54.50 # no, i'll just be working on my web site. 09.55.36 # does it produce any money? 09.55.48 # I assume you're talking about your bostadsbytar-website 09.55.59 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 09.56.23 # yeah. it brings in enough to live on. 09.56.42 # it does? cool! 09.57.27 # Any bigger plans? 09.58.17 # nothing major, just various improvements 09.59.00 # Are you going to do anything special with your new-found time? 09.59.40 # sleep, watch tv 09.59.48 # get fat 10.00.46 # hehe 10.02.23 # i'm going to do more fun stuff, like rockbox and various other little projects i didn't have time for before 10.03.31 # And I thought you were going to get away from the computers and spend more time practicing banjo :) 10.04.25 Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) 10.04.43 # :) 10.05.04 Quit Domin ("Curse - Version 1.5.1") 10.05.48 # I'd like to work less as well 10.05.56 # Perhaps 75% 10.10.06 # have u seen the last mailman security issues ?? 10.10.27 # https://lists.netsys.com/pipermail/full-disclosure/2005-February/031595.html 10.12.06 # fixed in our version 10.12.12 # ;) 10.12.27 # nothing to add 10.13.42 # so what's in progress on iRiver at the moment? 10.13.56 # * LinusN is working on the cpu clocking 10.14.08 # figured out the ata prob yet? 10.14.20 # haven't had time to work on it... 10.14.24 # k 10.14.46 # I saw xshock got wav playback working of a sort 10.14.51 # will connect a logic analyzer to study the timing 10.15.05 # i'm disappointed that he didn't get the dma working 10.15.18 # I think he does not know how to do it 10.15.26 # probably 10.15.41 # someone might be able to figure it out 10.16.01 # i was hoping to not have to do that myself... 10.16.18 # heh. more work 10.16.25 # too much to do already 10.16.40 # have a chat with him see if you can offer him pointers 10.17.06 # we seem to run past each other in the channel 10.17.39 # on different times :) 10.17.54 # tell him to stay up overnight ;) 10.18.05 # :-) 10.19.19 Join Schnueff [0] (~mah@test0.cs.uni-sb.de) 10.24.21 Quit Lurkski (Read error: 104 (Connection reset by peer)) 10.29.09 Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) 10.46.59 Join Patr3ck [0] (~patr3ck@p548CB018.dip.t-dialin.net) 10.58.38 *** Saving seen data "./dancer.seen" 11.29.49 # ; ) 11.45.49 # indeed 11.56.07 Join amiconn [0] (~jens@pD9E7F903.dip.t-dialin.net) 12.01.22 Quit DMJC ("Leaving") 12.04.02 Quit bobTHC (Read error: 110 (Connection timed out)) 12.06.37 Join Aison [0] (~hans@zux166-181.adsl.green.ch) 12.07.09 Join jyp [0] (~jp@111-103.245.81.adsl.skynet.be) 12.24.56 Quit ashridah ("bbs") 12.26.19 # * HCl stretches 12.27.19 # ***just a stranger wondering how rockboy is advancing 12.28.10 # slowly...about 11MHz :-) 12.28.28 # LOL! 12.28.44 # at least fast levels will be easier 12.31.33 # hey Linus...got a second? 12.31.53 # got some nooby questions for you 12.33.27 # shoot 12.33.28 Quit izzy (Read error: 60 (Operation timed out)) 12.34.57 # Well I'm an H140 owner who's been following the IRC logs since you guys were first thinking about porting to the iriver. Watching you guys work has really given be the desire to learn programming....especially low-level..... 12.35.00 # so 12.35.26 # I was wondering where to start so that someday I might be capable of contributing to the project 12.36.01 # Learning C is a good start 12.36.53 # exactly 12.36.53 Join ashridah [0] (ashridah@220-253-120-66.VIC.netspace.net.au) 12.37.12 # playing with plugins in the simulator is a good way to practice rockbox programming without having to dig too deep into the technical details of the hardware 12.37.13 # Lurkski: what programming experience do you have today? 12.38.22 # I am thinking about adding profiling to the codecs to support your optimizing efforts 12.38.40 # is therre something with higher resolution than ticks for measurement? 12.38.40 # Well I used to own a vic-20 and a C64 when I was around 12-13 way back in the day that I learned some VERY basic BASIC if you will. 12.39.14 # Patr3ck: no, but there are free timers to use 12.39.47 # you no the old 30 goto 10 stuff.....made some cool little programs for that age with the help of my mom's boyfriend at the time 12.39.58 # ok 12.40.10 # no = know 12.40.31 # does the tree of function calls need to be preserved for the profiling information 12.40.52 # or is it enough to just keep call count and a sum of durations 12.41.25 # Lurkski: The first thing is probably to set up the build environment (details are in the Wiki). You need that to be able to compile Rockbox yourself from the source code, and then you can start making little changes to see what happens. 12.41.31 # Patr3ck: any information is better than none. so start simple and expand as you go. 12.41.59 Quit Ka (Read error: 60 (Operation timed out)) 12.42.32 # I already prepared some simple functions to add to a central profiling information array 12.42.39 # Ok, set up the build environment and playaround with plugins in the simsounds like a good start........ 12.42.43 # these could be used by all codecs 12.43.26 # the codecs are plugins, so I would need to add these to the plugin api? 12.43.49 # the codecs aren't plugins yet. they only have some test plugins for development. 12.43.58 # Lurkski: Only problem is that if you are using Windows, the simulators don't currently work. But hopefully these will be working soon. 12.44.04 # there will be a separate codec api added. 12.44.23 # I see 12.45.28 # I will have a look at the free timers this evening 12.45.30 # One approach would be to create a profiling library - you could put this in apps/codecs/libProfile and this could be linked against the codec plugins in the same way as the actual codec libraries themselves. 12.46.01 # Or you could add it to plugins/lib/ - then it could be used by Rockboy. 12.46.14 # i have plans to introduce a usec timer 12.46.37 # Ok linuxstb, thanks.........also,I bought the Art of Assembly Language the other day and I've made it through chapter one.....I'm not computer retarded and not easily intimidated (spel?) and I look forward to continuing......I was told asm would teach me a lot about software's interation with the hardware and would also be of value when learning a higher lever language like C. But I wanted to ask the opinions of you guys because you alread 12.46.38 # for profiling and usleep() 12.46.49 # linuxstb: let's talk about the codec api. for starters, i think we should not load files into memory until we have a free codec slot. i.e. the codecs load the files. 12.47.02 # ok 12.48.03 # How would a profiling build be separated from a release build? 12.48.20 # Zagor: I'm happy to talk about it. 12.49.03 # I don't know what we will gain by letting the codecs load the files - why are you thinking that? 12.50.00 # Patr3ck: use a #define 12.50.02 # because we don't know which data is important, meaning we will load a lot of useless metadata which takes up ram space 12.50.21 # #ifdef PROFILING? 12.51.27 # I've thought about that as well, but I think it will greatly simplify things if we load the entire file into the buffer. Most formats have the metadata at the start of the file, so as soon as the "file_open" function has been called, it can be discarded. 12.52.00 # the other thing is that we don't gain anything by loading the file before we call the codec. we have to spin up the disk to load the codec anyway. 12.52.23 # Not if the codec is the same as the previous one. 12.52.25 # think dvd images - playing only the sound requires buffering the video data as well... 12.53.54 # Patr3ck: PROFILING sounds fine 12.54.01 Part Lurkski 12.54.12 Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) 12.54.18 # ok 12.54.38 # I understand what you are saying, but if we ever did that, we could implement a demuxer using a seperate "container" API. The "codec API" would just deal with audio streams. 12.54.41 # linusn: for now i will try the free timers 12.55.04 # look at tick_start() in kernel.c for an example 12.55.11 # linusn: if you add something better I make sure it can be changed easily 12.55.15 # personally, i was thinking about something along the lines of being able to insert a small asm block in the code that'd push the current tick, the current PC into a small array of persistent memorny, then increment an index into it. then when playback is done, dump that to a file. 12.55.22 # linusn: ok, thanks 12.56.10 # should at least get us basic timing if we insert them selectively to try and narrow down expensive bits of code, i was considering implementing something like that into the vorbis code progressively deeper, but i don't know enough about the structure of rockbox yet :) 12.56.10 # Hi! sorry for the n00b question, but how useful is the iriver port currently? installable? 12.56.11 # linuxstb: yes but then we're really talking added code complexity. a more real-life example is mp3 files with 500KB album art tags. 12.56.22 # qt: installable. looks pretty. plays nothing. yet. 12.56.41 # ashridah: ok. thanks. 12.57.02 # i just wonder all the time when i read comments here which let me think that some guys have rockbox already installed 12.57.11 # quite a few 12.57.26 # qt: we do, but it's for development purposes. 12.57.31 # amiconn: you here? 12.57.33 # understood 12.57.53 # is it easy to revert to orig firmware? 12.58.01 # you don't need to 12.58.23 # the original is still in flash 12.58.36 # ok. so the orig FW stays on while rockbox is running 12.58.42 *** Saving seen data "./dancer.seen" 12.58.43 # but yes, it is very easy to revert 12.58.45 # qt: the bootloader is built into the original, so hold down a button, and the original boots and operates as if nothing has changed. 12.58.45 # ok, similiar as to how the xbox mods work 12.59.01 # that is good news 12.59.10 # Zagor: OK, I understand what you are saying. But won't it require more disk spin-ups if we need to initialise a codec before reading the data from disk? Maybe the "loader" functions should be hard-coded into Rockbox. 12.59.34 # s/hard-coded/compiled/ 13.00.06 # no, we only spin up once: to load the codec and/or load new files 13.01.45 # we don't load a codec until it's time to read files 13.03.02 Join preglow [0] (thomj@s183a.studby.ntnu.no) 13.03.40 # OK, so you are saying that the codecs themselves should be responsible for reading the data from disk and putting it in the compressed data buffer? 13.03.55 # And that they should strip out as much "junk" as they can. 13.04.25 # yes 13.04.30 Join Zezayer [0] (~zezayer@host81-152-218-69.range81-152.btcentralplus.com) 13.04.58 # naturally rockbox needs to supervise it and allocate space so several codecs can coexist. 13.05.23 # but the codecs themselves know best how to make best use of the ram they get 13.06.20 # How are you thinking that the "supervision" would work? How would the codecs be allocated parts of the memory buffer? 13.06.40 # LinusN: what are your thoughts about moving the active codec to sram? got any estimate on how much that'll boost performance? 13.07.15 # stupid question. i am looking for a way to rename every occurence of cover.jpg to Folder.jpg throughout my MP3 collection. any idea how to do this? i tried with for() combined with find() but it has troubles with the directory names including a space 13.08.02 Join cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 13.08.04 # QT: You possibly just need to put the variable representing the filename in quotes - "$x" 13.08.06 # linuxstb: the codec api will have something like a read() function which rockbox calls when the buffer needs refilling. this call can include a pointer and length. 13.08.19 # linuxstb: tried that and it failed 13.08.51 # linuxstb: ...and return a length indicating how much was used. 13.08.59 # preglow: the internal ram has 1-cycle fetches, so it will be a huge boost 13.09.07 # qt: do you have spaces in any of the directory names? 13.09.08 # linuxstb: i even first put all directories to file, editedt the file to have the entries withtin "..." but still the for cc in `cat dirlist` can not handle it 13.09.18 # ashridah: in most 13.09.22 # amiconn: in case you check the log later, here's my initial take at our simulator fix: http://daniel.haxx.se/rockbox/ 13.09.32 # then you're in for a painful trip 13.09.54 # preglow: we need to think about how we can do that dynamically in a nice way since we have limited iram and will support multiple concurrent codecs 13.09.57 # ashridah: that is what i found out too :-( then i was looking for a windows tool that could do it but no luck either 13.10.11 # shell scripts aren't your answer, dealing with spaces in them is a royal pain in the butt, because bash constantly insists on stripping out quotation marks. 13.10.26 # QT: I'd use find to get the list of names, then treat each line as a full file name and use quotes 13.10.28 # perl can work, although i don't know enough perl to help you. 13.10.28 # Bagder: I'm here now. 13.10.39 # my idea now is to have a script dive into every directory, then if cover.jpg is there, rename it to Folder.jpg and continue with next directory 13.10.40 # Zagor: yes, at least gapless playback across different codecs isn't a huge issue 13.10.49 # LinusN: i'm really starting to think it'll be necessary, you see 13.11.03 # i have thought so all the time... 13.11.04 # amiconn: ok, my patch there builds here but it might need futher tweaking to do good in cygwin land 13.11.06 # badger: that was my idea too. it just doesn't handle the spaces though 13.11.17 # QT: mv with quotes does handle spaces 13.11.36 # badger: it does. but not the for() loop 13.11.36 # Bagder, sure. but not when they're embedded inside a for/find loop 13.11.54 # so 1) don't use for or 2) change IFS 13.11.55 # even if you escape them, you've got to have multiple levels of escapes 13.11.56 # LinusN: mention it next time, please, i actually thought we'd have to optimize it down to realtime level ;) 13.12.00 # preglow: actually, gapless playback doesn't require two concurrent codecs. but voice and game sounds do. 13.12.05 # i think my best bet is to use read() and setting IFS to something giid 13.12.18 # yeah. 13.12.21 # s/giid/good 13.12.23 # hey guys im a bit of a noob on the rockbox front, and having dificulties compiling the iriver firmware, can anyone offer any halp or maybe a link to a complete .hex file. thanks, and just ignore me if u cant help. 13.12.36 # preglow: i wanted you to sweat a little... :-) 13.12.36 # Zagor: ahh, no, do we ever require to _concurrent_ codecs? 13.12.42 # Zezayer: define 'difficulties' 13.12.46 # s/to/two/ 13.12.58 # crossfading ;-) 13.13.03 # preglow: yes, for mp3 voices during ogg music playback for instance 13.13.11 # that can be done by buffering pcm data a while in advance, heh 13.13.19 # if our codecs are fast enough 13.13.27 # preglow: that would be very short cross fade then 13.13.42 Join Patr3ck_ [0] (~patr3ck@p548CB835.dip.t-dialin.net) 13.13.50 # you don't have to decode simultaneously 13.13.54 # LinusN: around how many cycles does an sdram access use? 13.14.11 # 5+1+1+1 for a 4 word burst 13.14.11 # linuxstb: 13.14.17 # Bagder: well, realtime beatmatching is pretty much out of the question, yes 13.14.23 # btw, there's no daily odion FM build because we get a linker error 13.14.24 # bus cycles, that is, which is half the cpu frequency 13.14.34 # "region FLASH is full" 13.14.36 # LinusN: ouch 13.14.50 # linuxstb: does this differ much from what you had in mind? 13.15.00 # Bagder: rombox? 13.15.00 # so we might actually end up having to optimize codecs for size 13.15.07 # LinusN: yes, for ondiofm 13.15.08 # preglow: why?= 13.15.28 # preglow: hopefully it's enough to put only parts of the codecs in inram 13.15.31 # i don't think the entire codec needs to be in iram 13.15.51 # true 13.15.55 # indeed 13.16.21 # but i guess imdct and those fellas are good canidates 13.16.25 # yup 13.16.31 # how much of the sram will be taken be other stuff, btw? 13.16.37 # does the framebuffer have to live there? 13.16.46 # lcd framebuffer is there atm 13.17.52 # but yes, i tried optimizing synth_full in libmad yesterday, and i concluded it really saturated the memory bus 13.18.02 # there virtually no difference no matter what i do 13.18.04 # currently, we use about 6kbytes out of 96 :-) 13.18.35 # at least my libflac optimization had _some_ impact 13.18.47 # Zagor: No, I think you are talking about something extra on top of what I proposed. I don't think the fact that the codecs help the audio system fill the buffer has to change how the decoding works. 13.19.37 # linuxstb: i agree 13.19.44 # preglow: would it help if some data was in iram too? 13.19.52 # LinusN: most certainly 13.20.13 # so we would, for example, move the frame to iram before decoding 13.20.22 # But I'm still not convinced that stripping out metadata is a good idea - for example, if the codec (such as FLAC) contains a seektable, then if we remove metadata, we may break seeking. 13.20.31 # sine tables etc? 13.20.32 # Bagder: The linker error for Ondio FM rombox has been there for a while. I wonder why the dailies worked before... 13.20.41 # LinusN: yes, stuff like windows and twiddle factors 13.20.50 Quit Schnueff ("leaving") 13.21.10 # LinusN: there's a pretty large array of constant numbers in libmad, for example 13.21.12 # linuxstb: all i'm saying is i think the codec is best equipped to decide which data should be buffered in ram and which can be discarded. 13.21.27 # preglow: is it really a dct, or is it an fft? 13.21.40 # LinusN: libmad actually has both a dct and an imdct 13.21.55 # oh 13.21.55 # LinusN: you can calculate it using an fft, but that's not done in either libmad or tremor, afaik 13.22.26 # too few points to really make a difference, ? guess 13.23.16 # Bagder: Why are these (PREFIX) things still necessary in plugin.[ch]? I thought we can get rid of them completely with the new concept... 13.23.17 # in what regard do you mean? 13.23.40 # how many points are the dct calculated for? 13.23.45 # in mp3, 36 or 12 13.23.50 # depends on transient detector 13.24.02 # short windows are used for transients 13.24.02 # amiconn: because the #defines doesn't work for the field members in the plugin struct 13.24.25 # in vorbis, anything from 256 to 2048 can be used, two window sizes are set up in the header 13.24.42 # 36 point fft sounds small 13.24.50 # amiconn: I didn't want to make the defines more generic, like #define open sim_open because I think it'll be bad in the long run 13.24.56 # besides fft wants a power of 2 13.25.10 # yes, but using fft in an audio codec isn't really clever, mdct compacts more energy into fewer coefficients and thus compresses better 13.25.13 # vorbis sounds like an fft candidate though 13.25.35 # it is if we can find a _very_ optimized fft routine 13.25.49 # you need to do pre and post sorting as well if you calculate it using the fft 13.25.50 # Zagor: What do you think about the concept of a "read callback" used by the codecs - i.e. a "pull" system instead of a "push" system. 13.25.57 # preglow: you're the expert 13.27.01 # Bagder: The defines don't work for the struct members? I can't imagine why that is atm... 13.27.05 # but we'll see, not rewriting the codecs too much would be preferable, but does seem to be unavoidable 13.27.19 # indeed 13.27.29 # amiconn: because the defines look like #define open(x,y) and in the struct they are int (*open)(x,y) 13.27.41 # Ah, yes. 13.28.08 # linuxstb: i think that is the way to do it. give the codecs a proper api callback struct just like the plugins. 13.28.29 # but moving to sram will be a very good first step, the transforms are very memory hungry, more or less every operation uses a memory access 13.28.37 # preglow: i'll look into the possibility to let the codecs copy code and data to iram 13.28.50 # anyone wants a cup of coffee? 13.28.55 # Bagder: please 13.28.58 # i'm making one as we speak 13.29.10 # * Bagder walks to get a big cup for everyone 13.29.21 # * preglow tosses his cup out the window 13.29.55 # * LinusN swallows the cold remains of the last cup 13.30.05 Quit Patr3ck (Read error: 110 (Connection timed out)) 13.30.36 # Zagor: What about ID3-type metadata, should the codec API include a function to get the metadata from a disk file, without needing to initialise the codec instance? I'm thinking about getting "next track" info. 13.31.07 # LinusN: the coldfire timers are pretty high resolution, yes? 13.32.06 # linuxstb: no that's not necessary. next track will already have been loaded, and the metadata parsed, by the time the information is to be displayed. just like today. 13.32.17 # * ashridah looks at the coffee strangely, and returns to his caffeinated mints. 13.32.49 # i was thinking, having the timer interrupt look at its stack frame and note the previous %ip, wouldn't it be possible to have it save it in some table that's dumped to disk later, then translate all the addresses to function names? 13.33.12 # simple profiling could be done that way, unless i'm terribly wrong, which i probably am 13.33.27 # Bagder: The simfix patch doesn't apply cleanly against cvs... uisimulator/common/dir.h fails 13.33.40 # Zagor: Are you thinking of always having two codec instances "active" at the same time. i.e. one for the current track, and one for the next track, even if they are the same codec? 13.33.52 # amiconn: that should be removed anyway 13.34.29 # Yes.. I only wanted to mention it. You seem to have other changes there that aren't in cvs. 13.34.41 # linuxstb: no, but we always load as many tracks as we can fit in ram (or as many as our codec slots can fit). and metadata is parsed and "published" by the codecs when loading the files. 13.35.06 # amiconn: oh, right, but it removes all lines ;-) 13.35.14 # Zagor: you fill the buffer completely, even though you can't fill the last track in its entirety, i hope? 13.35.26 # preglow: yes 13.35.26 # Some codec libs (I'm thinking FLAC) will only give you access to the metadata after you have initialised the codec for decoding that dfile. 13.35.28 # Zagor: good 13.35.37 # preglow: coldfire has 1-cycle resolution timers 13.35.45 # But we can possibly work around that. 13.35.48 # LinusN: would my profiling idea work? 13.35.48 # preglow: with only 1.7MB buffer that is usually the case you know ;-) 13.36.31 # Bagder: hahaha, a miracle the disk doesn't wear out after a months use 13.36.37 # preglow: yes it could work 13.36.39 # linuxstb: yes, i know. but we will not load files into ram until we have a free codec slot that can load and parse it. 13.38.27 # * Zagor scours the kitchen for scraps of food. brb. 13.39.30 # How many codec slots do you have in mind? There could easily be 3 or 4 different codecs needed to completely fill the memory with data (e.g. if the user is shuffling the whole disk). 13.39.31 # do any of the 68k people know if burst moving data to registers with movem before doing computations is better than interleaving the computations with move instructions? 13.39.52 # preglow: yes and no 13.40.39 # if your data is in sdram and the code is in iram, i'd guess that interleaving might be better 13.40.55 # not necessarily though 13.41.14 # * LinusN is not a coldfire expert 13.41.15 # linuxstb: I think the default should be 2 slots. it's a balancing act. more slots waste ram (cost battery) for users with few formats, and few slots waste ram for users with many formats. 13.41.16 Join Schnueff [0] (~mah@test0.cs.uni-sb.de) 13.41.17 # i guess this is a special case, since i'm fetching data from two different locations 13.42.02 # Bagder: The x11 sim now compiles on cygwin, but fails to link. The win32 sim compile fails in filetypes.c at the plugin.h include 13.42.13 # which are sequantial, if i'm not mistaken, reading sequantially is a lot better than constantly switching to different addresses 13.42.50 # amiconn: let's ignore the link failure for now, what's the filetypes.c problem? 13.43.23 # preglow: yes, sdram benefits from burst reads 13.43.49 # My thoughts were to load the codec as late as possible - so there will be no compromise. We could compile the codec-specific loading and metadata parsing functions into Rockbox, and only dynamically load the actual decoding parts of the codecs. 13.44.23 # If the loadable part of the codec didn't nead to be used until decoding, we would only need 2, or maybe even just 1 codec slot. 13.44.54 # Bagder: There's a heapload of errors, I'll send you the log 13.45.00 # sure 13.45.22 # linuxstb/Zagor: we could also consider having a few selected codecs "built-in" 13.45.45 # linuxstb: loading it late gives no benefit. the only cost is a spinup. spinning up to load a codec or codec+files is equivalent. 13.45.49 # If the voice files are to be MP3, then it would make sense to have libmad built-in. 13.46.15 # Bagder: it won't give us any benefit, only "cost" when not in use 13.46.26 # I can't remember how to redirect both stdout and stderr to the same file atm... anybody? 13.46.37 # Zagor: it could be a gain "in average" 13.46.50 # amiconn: > file 2>&1 13.47.23 # i think we're doing something wrong if codecs have that much problems with working properly, and slight optimizations aren't going to help with it.. 13.47.28 # Bagder: no. you won't gain any spinups and you won't save any ram. in fact you will waste ram, since you have unused codec slot ram. 13.47.30 Join bobTHC [0] (~foo@l03v-35-141.d1.club-internet.fr) 13.48.16 # it saves spinups if you use many codecs 13.48.33 # but never mind, it was just tossing in an idea 13.48.36 # no, since loading a codec doesn't add a spinup. it uses the same spinup used to load the file. 13.48.37 # I was 13.48.46 # Zagor: not if you use 5 codecs to fill the buffer 13.48.48 # Zagor: What about the voice ui? 13.48.52 # Bagder: yes 13.48.52 # since they won't fit 13.49.10 # oh you can of course, right 13.49.19 # just do it serially 13.49.25 Join AC [0] (~5078751e@labb.contactor.se) 13.49.38 # morning 13.49.54 # you're right, if you have more formats than slots you will get more spinups. but hardcoding codecs isn improve 13.50.06 # isn't any better than simply increasing the number of slots 13.50.13 # true 13.50.58 # is it possible to get cvs write access? 13.51.13 # AC: yes 13.51.20 # AC: but you need to motivate it 13.51.27 # and prove yourself 13.51.27 # That's why I was suggesting moving the "loader" functions (which will be quite simple, and may even be shared between audio formats) into the main Rockbox binary - we are then not limited by the number of codec slots. 13.51.40 # amiconn: the voice ui will get its' own ram buffer that is locked and not used for music buffering 13.51.49 # i need the access for the wavpack codec 13.53.50 # The "loader" functions would also parse the metadata - this would be a good way to unify the metadata parsing in one place. 13.54.01 # linuxstb: however doing that means our codecs are not true plugins. i.e. you can't add a codec binary without recompiling rockbox. which would be a loss in my opinion. 13.54.25 # Bagder: what do you need for informations for the cvs-account? 13.54.51 # Zagor: I don't think it's a big loss. New codecs will be rare. 13.55.36 # yes, but it would de impossible to have 3rd party codecs 13.55.54 # Why would we want third-party codecs? 13.56.33 # Zagor: Yes, but the voice ui also needs the mp3 decoder 13.57.06 # (or any other compressed audio codec, but mp3 being the easiest) 13.58.01 # amiconn: speex would probably be preferable for that 13.58.01 # linuxstb: more importantly, it's no gain. in order to use the loaded data we need to load the codec, which means spinning up the disk anyway 13.58.45 # preglow: That can be left for later, but the point is that for the voice ui, it would be preferable to have a locked codec 13.58.49 # linuxstb: i can imagine that somebody creates a codec that we aren't interested to have in our cvs 13.59.19 # either because it isn't particularly interesting, or because of patent issues 13.59.26 # or something else 13.59.31 # amiconn: yes, and speex should be used from the start, imho, it's smaller and better suited 13.59.53 # amiconn: size will probably not be an issue, forget it 14.00.03 # amiconn: i'm split between using a strict last-recently-used scheme for the codecs or allowing the voice ui to lock a codec into place. both have benefits and costs. 14.00.32 # OK, I'm convinced now. 14.01.08 # linuxstb: excellent! :-) 14.02.39 # will be back... siwtching to linux to improve my wv2wav plugin 14.02.45 Quit AC ("CGI:IRC") 14.04.08 # LinusN: btw, the dma layer is present in the wiki page. it's the "feeder". 14.04.24 # oki 14.06.02 # However, I still think that stripping out the metadata will complicate the codec API for very little gain - but that's probably because I never put any metadata in my files anyway, so there is nothing to be discarded. 14.06.41 # linuxstb: stripping out metadata how? 14.07.02 # some code needs to do that parsing, and I thing the codec is the right code to do it 14.07.57 # again, letting core rockbox do it would mean we cannot add support for any file format without modifying core rockbox 14.11.20 # What's ata_enable exact purpose ? 14.11.40 # enable the buffers for the ata interface 14.11.47 # Is it normal it is in disabled state when usb is plugged ? 14.11.55 # Hello btw :P 14.11.56 # yes 14.12.19 # Do you think it is possible the gmini has no such a feature ? 14.12.31 # perhaps 14.12.43 # Alright, thanks 14.12.45 # it depends on the hardware 14.13.09 Join AC [0] (~5078751e@labb.contactor.se) 14.13.36 # Zagor: For MP3 we can strip out tags, and we still end up with a valid MP3 fille, for other formats, that may not be possible, So I think the "read" functions in practice, most of the codecs will have to read the entire file. But I agree that we should give codecs the opportunity to strip out parts of the file, so let's go with your idea. 14.14.24 # i.e. it's an optimisation that we don't have to implement for all the codecs - at least not immediately. 14.14.25 # LinusN: hm. i just thought of something. the usb-ide bridge gets the ata timings correct automatically doesn't it? wouldn't you be able to nick them from the datasheet from the bridge? 14.14.35 # linuxstb: exactly 14.14.36 # or isn't it that simple. 14.14.56 # We're happy then :-) 14.15.01 # ashridah: the ata timings are taken from the IDENTIFY command 14.15.02 # very :) 14.15.34 # 120ns cycle time in mode 4 14.15.41 # * Zagor seriously considers buying one of those C64 DTV joysticks 14.15.46 # * ashridah probably should read more about ata before saying stuff in public. 14.15.51 # :-) 14.16.31 # it might very well be brain damage in my end 14.16.42 # i certainly hope so 14.18.50 # and untimately, it might not even be the ata timing that is the problem 14.19.07 # it could be sdram timing as well, but i doubt it 14.19.30 # Zagor: have you thought about what threads we will need for audio playback? i.e will the "read data from disk" function in the codec be running in a different thread to the rest of the codec code? 14.19.31 # amiconn: u there? 14.20.52 # announce: fprintf() is soon known as fdprintf() in Rockbox 14.21.42 # aha 14.21.45 # sleep() is also subject for a rename 14.21.58 # oki 14.22.06 # to keep POSIX function names posix 14.22.24 # Bagder: How about "tsleep" for "tick sleep" ? 14.22.25 # but we haven't come up with a good name for sleep() ;-) 14.22.28 # ksleep() for "kernel sleep" maybe? 14.22.29 # linuxstb: i'd like the codecs to be single-threaded. i think we should aim for that for starters, at least. 14.22.35 # rofl. i see someone made the minor change to the makefile i suggested. 14.22.38 # * ashridah exists! 14.22.39 # tsleep for teick sleep? :V 14.22.42 # tick 14.23.50 # SleepOneTick(HANDLE hThread, DWORD dwTicks); :-) 14.23.55 # Zagor: I was thinking we would need different threads to a) keep the compressed data buffer full" and b) to actually decode the data. 14.24.18 Quit elinenbe (Read error: 104 (Connection reset by peer)) 14.24.48 Join elinenbe [0] (elinenbe_@207-237-225-9.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 14.24.55 # linuxstb: hmm you are right, yes we will need that (or a very large pcm buffer, which we don't want) 14.25.41 # Zagor: it depends on how we design the codec thread 14.26.01 # the swapping doesn't need a separate thread today 14.27.05 Join Bagder_ [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) 14.27.15 # no but we have a very long output buffer for that. the codecs will likely have to run once every few seconds, which means we cannot have multisecond disk accesses 14.27.31 # true 14.27.42 # amiconn: try my new -2 patch from the same place: http://daniel.haxx.se/rockbox/ 14.27.42 # spinning up and reading 25+ MB from disk will likely take a while 14.28.20 # how are the codecs designed? can we decode really small chunks at a time? 14.28.36 # my guess is that differs between codecs 14.28.38 Join CoCoLUS [0] (~coco@h081217139221.dyn.cm.kabsi.at) 14.28.56 # mornin 14.28.57 # however i assume most codecs can decode subsecond chunks 14.29.18 # LinusN: audio frames (the minimum data that can be decoded in one function call) are normally no more than about 20ms-30ms 14.29.31 # somehow i feel that the stream-blabla stuff in the flac codec is really ugly 14.30.06 # What do you mean? The API or the implementation? 14.30.10 # i want a clean buffer-in -> buffer-out concept 14.30.33 # the api 14.30.43 # just browsed the flac2wav plugin 14.31.16 # You have the "decode single frame" function - which will give you one frame of PCM data. 14.31.28 # that sounds more like it 14.32.26 # That's what the flac2wav plugin is using - "FLAC__seekable_stream_decoder_process_single()" 14.33.08 # The problem is that we don't know how much data to give as input - which is why the use of read() callbacks (to let the codec "pull" data from the buffer) seems the easier way. 14.33.19 # amiconn: i'm getting the feeling your rockboy makefile doesn't clean when you do make clean 14.33.33 Join markun [0] (~markun@bastards.student.utwente.nl) 14.33.37 # linuxstb: maybe i just didn't look closely enough, my apologies 14.33.58 # linuxstb: oh, that wasn't what I meant with adding a read callback :) 14.34.16 # Zagor: Yes, I know. We need two different read callbacks. 14.34.30 # Or are you disagreeing with the second type of read callback? 14.34.31 # why can't the codec just use the ram directly? 14.34.47 # HCl: I would love to dig into it, but it may be really helpful to get the sims building again for that... 14.35.05 # amiconn: didn't you write a disk r/w test plugin? 14.35.08 # Bagder: Do I need to revert the first patch before? (I guess so) 14.35.14 # amiconn: yes, do that 14.35.21 # LinusN: yes I did 14.35.28 # can you email it? 14.35.41 # LinusN: It writes a file full of pseudo-random data, then reads back and compares 14.36.01 # looks like i need that 14.37.07 # Zagor (from the Wiki): The alternative to using a read callback to pass data from the audio system to the codecs is for the audio system to pass a pointer to a memory buffer to the "decode_data()" routine. Although this seems the simpler approach, it will make the codec implementation more complex. The main problem is that the amount of input data required to decode X bytes of PCM data is only known by the codec - so allowing the codec to 14.37.07 # request Y bytes of compressed data from the audio system is simpler than the audio system trying to predict how much data the codec will need in a particular decode step. 14.38.39 # linuxstb: i suggest skipping around that problem entirely. rockbox tells the codec: here's some ram you may use. the codec loads data into this ram. then rockbox says: please give me X pcm samples. 14.39.16 # rockbox does not care where in ram the codec is reading the compressed data 14.39.27 Quit Bagder (Read error: 110 (Connection timed out)) 14.40.23 Nick Bagder_ is now known as Bagder (~daniel@1-1-5-26a.hud.sth.bostream.se) 14.41.41 # linuxstb: agreed there 14.42.09 # Zagor: I'm not sure why you are against my idea of a read callback. I think it's a simple solution. 14.42.48 # I simply don't see why we need it 14.44.32 # Because we need a way to give codecs access to the memory buffer. We have three options 1) Pass the codecs pointers to memory, 2) Use a read callback, 3) Just give the codecs access to a large chuink of memory for it to manage it's own buffering. 14.44.57 # i think option 3 is the best way 14.46.20 # OK, can you explain how that would work? How would you decide how much memory to give to the codec? When would the codec be allowed to access the disk? 14.48.14 # we tell the codec to load a file, using a call such as load(). this call includes a pointer to and a length of a memory area the codec may use. the call returns how many bytes it actually used. 14.49.18 # remember not all file formats are streamed. think mod or sid playback, where the codec really needs random access to the whole file. 14.51.08 Quit HCl ("Lost terminal") 14.53.25 # http://www.rockbox.org/twiki/bin/view/Main/UiSimulator 14.53.28 # Would that then mean that the codecs need to have two threads - one to read data from disk and one to decode it? 14.53.31 # an embryo 14.54.35 # linuxstb: they do, but not because of this. they need that in any case. 14.55.20 # Bagder: Your second patch has the same problem... 14.55.35 # (because we need to be able to refill the buffer while playing music, which could be done by the same plugin) 14.56.44 # So how much of the "compressed data buffer" would you give to a codec? All of it? 14.57.16 # It just seems that all the work of the "audio system" is now being duplicated inside each of the codecs. 14.57.27 # amiconn: can you dcc me the new output? 14.58.10 # i.e. that the "audio system" will be very simple, and the codecs more complicated. But I'm not saying that's a bad thing. 14.58.20 Join muesli- [0] (muesli_tv@hmln-d51475b8.pool.mediaWays.net) 14.58.27 # linuxstb: the codec gets all free memory, uses as much as it needs and "returns the rest" (i.e. says how much it used) 14.58.39 # I don't see what is complex about it 14.58.46 *** Saving seen data "./dancer.seen" 14.59.29 # By "complex", I just mean that more work is done inside the codec, and less work (i.e. buffer management) is done in the audio system. 14.59.55 # hi 15.00.00 # hi 15.00.15 # i disagree. having a buffer does not mean it has to do any "buffer management". it's just a big chunk of ram. 15.00.23 # We would want a codec to be able to read 4 or 5 files into memory during one spin-up (assuming there was space). 15.01.31 # true. hmm, let me think about that a bit. back in a bit. 15.02.16 # The RAM is only "big" if the file is "small". If you have, for example, a 200MB file (which I have a lot of), then the codec will need to manage the buffer and also batch the disk reads to minimse the number of disk spin-ups. 15.02.24 Join hcl [0] (hcl@titania.student.utwente.nl) 15.02.29 Nick hcl is now known as HCl (hcl@titania.student.utwente.nl) 15.02.32 # * HCl whacks screen 15.12.50 # amiconn: ok, another shot. rerun configure after applying 15.14.11 # Bagder: Did you change the patch? 15.14.29 # yes, there's a -3 now 15.18.27 # Bagder: 15.18.28 # In file included from filetypes.c:31: 15.18.28 # plugin.h:69:30: plugin-win32.h: No such file or directory 15.20.06 # arg 15.20.31 # Bagder: do it right, once and for all :-) 15.20.44 # or use a CVS branch :P 15.20.44 # * Bagder swings for LinusN 15.20.51 # * LinusN ducks 15.21.31 # amiconn: try copying some of the plugin-win32.h file from uisim/win32 into the plugin.h file instead 15.22.07 # I removed that dir from the include path when building firmware/ and apps/ stuff 15.23.02 # it felt like a clean break 15.23.57 # Hmm. If I don't overlook something, files in apps/ and firmware/ should never include files from the uisimulator/ tree 15.24.14 # correct 15.24.19 Part Lurkski 15.24.20 # and that's why you get that failure ;-) 15.24.36 # the plugin-win32.h is in uisim/win32 15.25.01 # Bagder: I need to figure out which stuff needs to get included. That may be a problem doing in parallel to work... 15.25.24 # amiconn: well, if you could just confirm that doing it works, I can do it too in my end 15.27.18 # amiconn: or just try my -4 patch 15.27.57 # I moved in what I think is needed 15.28.29 Quit muesli- (Read error: 113 (No route to host)) 15.28.40 Quit Zezayer ("ChatZilla 0.9.61 [Mozilla rv:1.7.2/20040804]") 15.29.16 Join Zezayer [0] (~zezayer@host81-152-218-69.range81-152.btcentralplus.com) 15.29.58 Part LinusN 15.33.17 # Bagder: Now it compiles farther, but there are some warnings, and then it errors in dir-win32.c. I'll send you the output 15.33.32 # anyone around who might be able to run the rockboy.rock on my ftp on an iriver? i don't have my iriver around at the moment and i need to know whether it works or not.. 15.33.49 # yeah here 15.33.58 # ftp://titania.student.utwente.nl/rockboy.rock 15.34.03 # it should work with current cvs 15.34.05 # where to put the rom? 15.34.11 # just anywhere 15.34.17 # you need to install it as viewer 15.34.19 # i have 18/2, that new enough?= 15.34.23 # um. 15.34.27 # i don't know, to be honest. 15.34.29 # probably. 15.34.50 # * HCl is gonna run out of battery soon.. 15.35.52 # HCl: I can try it as well. 15.36.01 # please 15.36.07 # i just need to know whether it still works or not 15.36.23 # i made a few changements to the physical storage of gameboy registers, in preperation for dynarec 15.36.29 # changes* O.o; 15.36.33 Join R3nTiL [0] (~zorroz@83.69.98.221) 15.36.34 # gee, that was a bad typo >.>; 15.37.35 # HCl: I get "incompatible version" when trying to load your plugin... 15.37.56 # Do you have a rockbox.iriver I can use with it? 15.38.53 # linuxstb: HCl extended the plugin api for rockboy, so you'll need the matching rockbox.iriver 15.39.37 # linuxstb: hold on 15.39.41 # me too 15.39.44 # i thought it was up to date, but i should have it 15.39.50 # there 15.39.53 # on my ftp 15.39.57 # rockbox.iriver 15.41.02 # it actually is compatible with the old api, but it used a higher version number 15.41.15 # amiconn: try removing dir-win32.c from the uisim/win32/SOURCES 15.41.25 # it shouldn't be there for cygwin builds anyway 15.41.32 # HCl: It's now running.... 15.41.38 # linuxstb: how about this: we (core rockbox) tell the codec to load a file to ram (or as much as fits). then, separately from that, we call it to start decoding from ram. thus the codec only ever handles one buffer at a time, which is handed to it as pointer/length by rockbox. 15.41.43 # linuxstb: okies 15.41.53 # linuxstb: tell me if you get screen output / if it seems to work properly 15.42.04 # HCl: But my screen has gone blank - not even the frame counter. 15.42.15 # hrm :/ 15.42.19 # *sighs* 15.42.25 # i don't understand whats going wrong :/ 15.42.26 # Sorry, let me test again... 15.42.38 # core rockbox also tracks remaining buffer, and triggers refill 15.42.39 # its not your fault, earlier i tried the same thing with a slightly different arrangement 15.42.48 # and it went completely nuts 15.42.52 # The frame counter has now appeared (after I pressed stop once) 15.42.58 # okay o.o 15.43.02 # what was it at? 15.43.09 # 70 15.43.13 # gah. 15.43.16 # It's at 70 now. 15.43.19 # frustrating. 15.43.26 # :( 15.43.31 # HCl: dynarec? 15.43.34 # *doesn't understand why it won't work at all* 15.43.41 # preglow: no, just some changes to the interpreter 15.43.54 # moving registers to 32 bit vars and not storing them in 1 word in memory 15.44.07 # in preperation for dynarec 15.44.52 Quit HCl ("Lost terminal") 15.45.43 Join hcl [0] (hcl@titania.student.utwente.nl) 15.45.48 # sorry 15.45.50 # screen keeps crashing 15.45.53 # >/ 15.46.24 # Is there an api do dump textual data to disk ? 15.46.50 # Zagor: But why does the codec need to handle the buffer at all? All the codecs I've looked at are perfectly happy to just treat the input as a stream and read sequenctially from the start to end. All the audio system needs to do is (with help from the codec provided "load and filter" function) is to manage a large ringbuffer. 15.47.54 # linuxstb: did it show any output or did it just plain crash? 15.48.25 # it loads the rom 15.48.33 # shows a counter on the left top 15.48.35 # linuxstb: enforcing a stream concept removes all possibility of mod and sid support, which is sad methinks 15.48.46 # CoCoLUS: whats the counter at? 15.48.47 # then i get small bars from the top to the bottom :) 15.48.49 Nick hcl is now known as HCl (hcl@titania.student.utwente.nl) 15.48.53 # bars? 15.48.53 # 7, 8, something like that 15.49.00 # what rom are you loading? 15.49.08 # the mario.gb from your ftp 15.49.09 # mario starts displaying at 14 15.49.15 # No it doesn't. They can be a special case because their file sizes are so tiny (typically less than 64K). The gain is to make everything a lot simpler. 15.49.20 # okay, tell me if it shows anything when it gets to 14 o.o; 15.49.24 # mods can be several megabytes 15.49.26 # * HCl 's class is starting.. 15.49.28 # afk :/ 15.49.39 # ok now there was some msg invalid opcode, and plugin returned error, went away before i could read it 15.49.58 Quit ashridah ("sleep") 15.50.19 # im sorry i can't help you more, i'll be back later if you need some more testing 15.50.39 # also, i still don't see how having a pointer to ram is complex 15.50.59 # Zagor: Even so, I think we can handle them within the stream concept. We just need an option to the read callback that tells the audio API not to discard the data from the buffer. Normal "streaming codecs" will read and discard, MOD/SID won't. 15.51.21 # actually, the streamed concept is identical except you get lots of small buffers instead of one big. 15.51.26 # Anyways you'll have a certain amount of data not to discard 15.51.30 # imho 15.51.42 # CoCoLUS: okay, thanks 15.52.08 # My motivation is to try and keep the codecs simple. 15.52.33 # HCl: No screen output, but I restarted it. Currently up to 170 frames. 15.52.41 # linuxstb: what rom? mario? 15.52.49 # that is a great goal, which I agree with. but what is more complex about having a large buffer instead of a small? 15.53.01 # its frustrating, it should work, i haven't changed anything that could affect this x.x 15.53.12 # i might have messed up some endianness 15.53.45 # Zagor: my concept is "no buffer" for the codecs. They just read data from the audio system. 15.53.49 # let me build a new version.. 15.53.58 Join Ka [0] (~tkirk@pcp0010733332pcs.howard01.md.comcast.net) 15.54.03 # HCl: It's "JetPac" 15.54.20 # linuxstb: of course you have a buffer. you read data from the audio system into a small buffer, which the codec works on. 15.54.27 # I did run it in earlier versions, and I'm sure there was screen output quite early. 15.54.58 # or not 15.55.03 # i'll bbl, battery empty 15.55.05 # bye 15.55.46 Quit Zezayer ("ChatZilla 0.9.61 [Mozilla rv:1.7.2/20040804]") 15.55.50 # Zagor: In the case of MP3, you just request one MP3 frame which is then immediately passed to libmad, or you make use of the codec library's internal buffering. 15.56.25 # i.e. the "wrapper" around libFLAC/libmad/whatever doesn't need to keep its own buffer. 15.56.40 # linuxstb: yeah, the buffer is one frame long. that is not simpler, it just means a lot more function calls. 15.58.07 # the fact that we'd need two ways of accessing the data speaks against the streaming solution, i think 16.00.28 # also, how would rockbox know how much data to stream? the codec would have to request first the frame header, decode that and then request the frame data. or? 16.00.36 Join muesli- [0] (muesli_tv@1Cust198.tnt10.hnr2.deu.da.uu.net) 16.00.39 # (in case of vbr) 16.02.28 # The codec knows how much to ask for. For most codecs, this is handled inside the actually library - libFLAC and Tremor for example use the concept of a read callback., so my reasoning is that it makes sense for our codec API to do the same. 16.02.50 # but mp3 can't know - each frame can have different length 16.03.19 # linuxstb: libmad can do that too 16.03.26 # how? 16.03.49 # does the read callback _really_ just ask for one frame at a time? 16.04.37 # its guess is probably better than ours anyway 16.04.42 # We shouldn't care - the codec asks for whatever it needs. 16.05.08 # Which is the whole concept of the read callback. 16.06.22 # but what's the alternative? that rockbox guesses how much it needs? 16.06.35 # callback or no, the codec needs to tell how much data it'll like 16.06.48 # amiconn: new patch uploaded, I'll be off now for a few hours, but I'll return later tonight 16.07.00 # preglow: Zagor's alternative (IIUC) is to just give the codec access to a very large buffer to do what it likes with. 16.08.16 # like the main mp3 buffer? 16.08.47 # preglow: yes 16.08.54 # that would be optimal, but it would have to handle wraparound and such 16.09.09 # we'd get away with no copy, which is a good thing 16.09.24 # it doesn't have to handle wraparound. that can be treated as a new buffer. 16.09.47 # (i.e. rockbox handles the wraparound) 16.09.47 # well, sooner or later the data it needs will be situated at the end of ram, and the next part of that data will be some place at the start of it 16.10.06 # well, we'll need to hack the codecs, then 16.10.09 # which should be avoided 16.10.23 # afaik, the codecs depend on getting the amount of data they need 16.10.24 # nothing less 16.10.50 # that's not a problem 16.10.57 # why not? 16.11.23 # it requires making the codec load functions able to exit in mid load, which might not always be trivial 16.11.44 # unless you do a copy anyway, in which case you might as well go with callbacks 16.12.00 # it always has to be able to do that - we have limited ram and may not fit the whole song 16.12.08 Join izzy [0] (laitinei@huippu.net) 16.12.11 # you have to buffer in advance 16.12.13 # A read callback would handle wraparound once for all codecs - in the audio system. We wouldn't have to implement those kind of checks for every codec. 16.12.13 # so it needs to be able to load part of it 16.12.30 # (i.e. rockbox handles the wraparound) 16.12.32 # Zagor: yes, but it always needs one frame's worth of data 16.12.58 # if the frame ends halfway through, with the other end lying somewhere in the start of the mp3 buffer, you have a problem 16.13.19 # afaik, the process that fills the mp3 buffer just reads 'till there's no more space 16.13.24 # so that might very well happen 16.14.18 # of course. i still don't see what the problem is. 16.15.03 # the problem is that unless you propose you hack the codec itself to handle the wraparound, it won't be able to abort reading the frame just so you can feed it more data 16.15.30 # We have streaming codecs which are a lot more likely to not fit in the available RAM. We then have non-streaming codecs whcih afaik will always fit into the available RAM. IMO we should design the API towards the first case, and deal with the second as a special case. 16.15.30 # you have to copy the different parts to a new frame buffer, and if you have to do that, what's the point of letting it access the mp3 buffer in the first place? 16.16.05 Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) 16.16.13 # i prefer to avoid special cases altogether, if possible 16.16.42 # a pure isstreaming() will do, just to let rockbox know if it has to care about prebuffering 16.16.48 # has'nt 16.17.06 # ? rockbox will always handle prebuffering 16.17.10 # Zagor; I don't see any problems implementing your idea or mine. It's just that for my idea, I think the actual codec implementations will be simpler. 16.17.37 Join Zezayer [0] (~zezayer@host81-152-218-69.range81-152.btcentralplus.com) 16.17.55 # Zagor: yes, but it doesn't need to consistantly keep track of whether the codec needs more data to be able to play the current track 16.18.34 # The only disadvantage of my idea is that it will probably involve more memory copying, but with the advantage of less corner cases to worry about. 16.18.43 # preglow: ah, good point 16.18.50 # Zagor: yes, i think so ;) 16.19.18 # Zagor: aborting a frame decoder in the middle of huffman decompression, for example, is going to be painful to code 16.19.39 # linuxstb: i think we should only copy when necessary, i.e. at wraparound. 16.19.47 # Zagor: that's a good point 16.20.02 # but i'm warming to the idea of having both ways to access data 16.20.08 # but that only applies if the codec itself knows how long the frame will be 16.20.18 # i don't know how true that is 16.20.50 # if not, we have to start copying buffers in advance within a certain threshold of the mp3 buffer end 16.21.08 # Zagor: For libFLAC and Tremor we have to copy the data "into" the codec anyway. They won't work on a pointer to a memory buffer. Other codecs are probably the same. 16.21.09 # perhaps we can have the codec report max frame size 16.21.23 # linuxstb: they wont? 16.21.32 # linuxstb: sure. but let's not add more copying than necessary. 16.22.37 # preglow: I don't think so. They themselves use a read calllback, thereby forcing you to copy the data to the memory buffer libFLAC/Tremor gives you. 16.22.52 # preglow: i think we can define a max guaranteed contigous stream buffer size. 16.23.38 # But of course, this would only happen once - we wouldn't need to copy once from the audio buffer to the "codec wrapper" and then again from the wrapper to the library. The "wrapper" would just forward the read request to the audio system. 16.23.38 # but anyway 16.23.46 # before we venture too deeply into this 16.23.46 Quit markun () 16.23.58 # i very much believe the frame data might need to be in sram 16.24.08 # so a copy might be necessary 16.24.34 # what is the max frame size of vorbis and flac? 16.24.44 # a lot 16.24.52 # >32KB? 16.25.11 # well, both supports very high bitrates, i don't know exact number 16.25.21 # I'm not sure about vorbis, but FLAC is 32K. In practice, FLAC frames are normally 4608 bytes - it's the default encoder setting for all compression levels. 16.25.37 # frame length for vorbis can be changed by the encoder 16.25.52 # linuxstb: how long is a flac frame? 16.26.33 # Sorry, I think I'm confusing bytes and samples and compressed/uncompressed frames. Let me double-check. 16.26.42 # we don't necessarily have to support obescene worst cases either. i'm guessing many formats have very large theoretical limits that noone ever approaches in real life. 16.27.05 # agreed 16.27.13 # agreed. :-) 16.30.16 # then we can set aside a fixed amount of sram for each codec slot to use as it sees fit. 16.31.09 Quit Lurkski (Read error: 60 (Operation timed out)) 16.31.47 # How much sram is there? 16.31.53 # 96kb 16.32.11 # Zagor: no, i really think we'll end up using the entire sram for one codec 16.32.21 # Zagor: at least if we want to obtain at least a semblance of good performance 16.33.05 # and not using the entire sram when you can would be a huge waste 16.33.19 # umm, that means we can only ever have one codec 16.33.25 # yes, at a time 16.33.30 # That's going to take a lot of hacking into the codecs as well. 16.33.32 # they will have to be swapped in and out 16.33.59 # that's really not what we want. but let's want and see what's possible first. 16.34.04 # sure 16.34.06 # s/want/wait/ 16.34.22 # but if we don't do it that way, we'll have to work wonders in size optimizing 16.34.41 # All the codecs use lots of lookup tables - maybe it would just be enough to copy those into the sram. 16.34.46 Join methangas [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk) 16.34.56 # linuxstb: yes, and very probably some important code 16.35.09 # linuxstb: like the lpc decoder in flac, and synth_full and imdct in libmad 16.35.37 # but reserving space for all possible decoders would be stupid, imho, worst case there should be room for two, but not all 16.35.53 # not all possible codecs. all slots. 16.36.08 # ahh, i'm not into the slot thing 16.36.10 # proposed default: 2 16.36.15 # then we agree once more 16.37.43 Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) 16.38.22 Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) 16.39.14 # wtf R3nTiL ? 16.39.47 # So where are we in the "read callback" vs "direct buffer access" discussion? 16.39.59 # * [IDC]Dragon hasn't read the full codec discussion backlog, but may add $0.02 16.40.10 Nick G is now known as thegeek_ (na@ti521110a080-0418.bb.online.no) 16.40.11 # linuxstb: I think I'd like both 16.40.18 # <[IDC]Dragon> I know DirectShow 16.40.39 # <[IDC]Dragon> and some proprietary multimedia architectures 16.40.39 # btw, putting the frame in sram might be unnecessary after all, it's probably used sequantially 16.41.00 # <[IDC]Dragon> is DS, the work is split into a parser and a decoder 16.41.07 # <[IDC]Dragon> in 16.41.33 # <[IDC]Dragon> the parser understands the file format and pumps the data 16.42.05 # <[IDC]Dragon> the decoder receives a stream (normally), and pushes decoded data 16.42.26 # <[IDC]Dragon> the full output buffer will then stall the process 16.42.27 Quit R3nTiL () 16.42.30 Quit thegeek_ ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") 16.42.46 # [IDC]Dragon: yes, that's how we'll do it too. the codec first reads the file and puts data in ram, then (another funcion) decodes data from ram and produces pcm samples 16.44.02 # But we also have the large buffer in the middle to deal with, and disk spinups to minimise. I think that's where views are differing. 16.44.29 # <[IDC]Dragon> spinups are a new concept to these architectures 16.44.35 # i thought we were finally agreeing :-) 16.45.02 # Zagor: I don't think we're too far apart :-) 16.45.44 # but you talk about accepting both methods now, and i don't really think they're mergeable, heh 16.45.49 # <[IDC]Dragon> another idea I once had is to use the bib buffer as a "plain" disk cache 16.45.56 # it's either callback or no callback 16.46.05 # not using a copy buffer all the time is agreed upon 16.46.13 # in the case of a callback, we have to copy 16.46.15 # <[IDC]Dragon> and read ahead as much as possible without trashing some to-be-used data 16.46.18 # preglow: we can have two functions: give_me_x_bytes() or give_me_buffer() 16.47.04 # [IDC]Dragon: the problem with that is we risk caching a lot of useless data. such as album art or video data. 16.47.16 Join G [0] (na@ti521110a080-0418.bb.online.no) 16.47.30 # <[IDC]Dragon> no, cache only the data you're about to read 16.47.34 # Zagor: I think the percentage of useless data is low 16.47.53 # amiconn: on average, yes. but why cache it? 16.48.14 # [IDC]Dragon: how do we know which data we're about to read? imagine playing sound off a dvd image. 16.48.19 # Um, because it makes the whole caching a lot simpler? Thinking KISS... 16.48.37 # simple but inefficient 16.48.45 # <[IDC]Dragon> Zagor: the same way we do now: read ahead in the playlist 16.49.00 # today we parse the file and only cache useful data 16.49.01 # Zagor: I think the"sound from a dvd image" is a *very* exotic example 16.49.24 # <[IDC]Dragon> ok, now I get you 16.49.42 # amiconn: I agree with you AND Zagor :-). i.e. we should think of that as an optimisation. i.e. we don't have to worry about it if it is too much work to implement, but we should give the codecs the opportunity to say "that 500K of data is useless, don't bother to read it from disk". 16.50.04 # amiconn: i agree. but caching "blindly" doesn't really make things much simpler. the codec needs to parse the container format anyway. why not doing it while loading instead of while decoding? 16.50.25 # That means the codec is involved twice, at very differing points of time. 16.50.42 # <[IDC]Dragon> parsing and decoding 16.50.49 # yes, but that is no disadvantage. the spinup is already happening. 16.50.59 # First, when it comes to read data into the buffer, then when actual decoding takes place 16.51.12 # That may mean to holding many codecs in ram... 16.51.27 # <[IDC]Dragon> the parser may be re-used 16.51.30 # no. please read the log. we've been through this already :-) 16.51.32 # <[IDC]Dragon> like for AVI 16.51.50 # <[IDC]Dragon> sorry 16.52.29 # we started about 12:00 16.52.50 # 12:46 to be exact 16.55.38 # Either holding many codecs, or frequently swapping in/ out, which might be necessary between refills (!) 16.55.45 # Zagor: You mention disk spinup as the only cost - is CPU time spent parsing the data also not a significant cost? Especially if the codec is also trying to decode a file at the same time. 16.56.21 # parsing is generally not a cpu-intensive process. the formats are designed to be read with minial effort. 16.56.31 # HCl? 16.57.12 # But at the moment it looks like we will need every possible CPU cycle just to decode the audio. 16.57.19 # Zagor: Imagine one starts playig an mp3 file, which is followed by an ogg, which is followed by a flac, then an mp2. Let's say all these fit in the main buffer, then you need to swap codecs if you only have 2 slots.... 16.57.40 # linuxstb: indeed, but the parsing has to be done. it's not more efficient to do it later than sooner 16.57.56 # amiconn: yes. so we don't load all of them. 16.58.04 # ??? 16.58.27 # That would be even worse, imho. Not using the whole buffer we have to spare... 16.58.40 # amiconn: you would still need the same number of disk spinups (to load codec plugins) - it's just that each one would read less data. So in that case I don't think it 'matters if the buffer is half empty. 16.58.47 *** Saving seen data "./dancer.seen" 16.58.50 # read the log. there is no gain reading data you can't parse without another spinup. 16.59.42 # I'm afraid I have to go now. See you guys later. 16.59.46 Quit Zagor ("Client exiting") 17.01.35 # I still wonder if it would be better to build all codecs into rockbox after all... 17.02.41 # how about similar units with less RAM? 17.02.54 # I mean with a "generic" pcm driver 17.03.05 # and how about playback buffer? 17.03.23 # amiconn: Yes, that's an option, but it would be nice to not have to limit the number of supported codecs. 17.05.52 # Indeed, I'd like (at least part of) the codecs to be built in, since gmini has only 16k 17.06.02 # of code ram 17.06.43 # jyp: Doesn't a limited amount of RAM imply a bigger need to have external, loadable plugins? 17.07.02 # I'm with linuxstb 17.07.17 # Having everything as plugins has its pro's 17.07.28 # Maximized playback buffer, for once 17.07.37 # Or is it a case of so little memory, that the overhead of plugins is the problem. 17.07.39 # That's fine as long as they are around 10k large 17.08.15 # jyp: you've really got some nice limits going there 17.09.05 # jyp: how big are the plugins atm? 17.09.21 # They aren't compiled atm ;) 17.09.26 # they aren't? 17.09.32 # boooo! :) 17.09.35 # They aren't. 17.10.40 # booo! 17.10.40 # :) 17.11.14 # dwihno: The problem with the CalmRISC16 cpu core used in the gmini is that it is a harvard architecture, and the code address space is mapped to the flash only, except the tiny internal sram of the cpu 17.11.58 # Imho it is impossible to support plugins on that. All plugins need to be compiled in 17.12.27 # My thinking too 17.13.00 # So for gmini, having all supported codecs builtin is actually a requirement... 17.13.01 # <[IDC]Dragon> is the flash sectored? 17.13.11 # yes 17.13.35 # amiconn: aaah, that's sucky :/ 17.13.37 # <[IDC]Dragon> so you could swap the plugin 17.13.40 # [IDC]Dragon: You don't propose swapping plugins in & out by flashing, do you? 17.13.48 # <[IDC]Dragon> I do, yes 17.13.51 Quit Lurkski (Read error: 110 (Connection timed out)) 17.13.57 # humhum 17.14.00 Nick G is now known as thegeek (na@ti521110a080-0418.bb.online.no) 17.14.01 Nick thegeek is now known as thegeek_ (na@ti521110a080-0418.bb.online.no) 17.14.23 # Problem is the flash supports only 100000 erases 17.15.05 # (typical) 17.15.23 # <[IDC]Dragon> for plugins, this may be sufficient 17.15.44 # <[IDC]Dragon> the Odio flash has a similar rating, iirc 17.16.04 # Are you using this method on the ondio too ? 17.16.13 # jyp: No 17.16.16 # <[IDC]Dragon> I meant the mass storage 17.16.35 # * preglow hugs his h120 17.16.52 # Ok, so the plan would be to flash the plugins independantly... 17.16.55 # That's fine 17.16.56 # [IDC]Dragon: Yes, but for the mass storage, we're trying to keep the flash wear ing low 17.17.39 # <[IDC]Dragon> still, all the root file or fat modifications flash certain regions again and again 17.18.47 # It's just as fine to flash the plugins separately, otho, why not have them compiled in ? 17.19.10 # <[IDC]Dragon> if it fits, ok 17.19.19 # <[IDC]Dragon> how big is your flash? 17.19.49 # 1Mo, for the models examined 17.19.58 # maybe 512k on others 17.20.00 # * [IDC]Dragon doubts he'll ever start 100000 plugins 17.20.30 # We'd have a "plugin cache" anyways. 17.21.50 # I'm begging to find this idea very interesting ;) 17.21.55 # beggining 17.22.11 # <[IDC]Dragon> didn't Archos sell plugins for the Gmini? 17.22.18 # back 17.22.32 # planned (rumors says), but never done 17.22.44 # <[IDC]Dragon> no, they do 17.22.53 # ah? 17.22.54 # <[IDC]Dragon> how's that done, technically? 17.23.07 # What do you mean ? 17.23.22 # <[IDC]Dragon> my Archos contact told me they made a *lot* of money from Gmini plugins 17.23.59 # What do you mean, technically? 17.24.08 # <[IDC]Dragon> are they always in, and just enabled, or how do they load code? 17.24.38 # <[IDC]Dragon> this was your problem, if you remember, harvard and stuff 17.24.50 # heh ;) 17.24.59 # I think it's sucky. First of all, charging a lot of money for a unit with firmware, and then charging ADDITIONAL for features that should be built in! 17.25.18 # <[IDC]Dragon> tell that to M$ 17.25.31 # My idea is that "plugins" were a complete new firmware with additional features 17.26.00 # In all the code I've revered, not a single trace of "loadable" plugins 17.26.05 # <[IDC]Dragon> maybe 17.26.09 # reversed 17.27.41 # There's is, however, a certain type of upgrade 17.27.59 # that checked the HD serial number 17.28.20 # <[IDC]Dragon> that sounds like it 17.28.39 # <[IDC]Dragon> the plugins were somehow bound to the box 17.28.49 # besides that is was a normal flash 17.29.01 # hence my previous hypothesis 17.29.40 # They sold complete firmwares with plugins compiled in. 17.29.59 # <[IDC]Dragon> then there must be a user option to extract that number 17.30.07 # yup, there is 17.30.14 # <[IDC]Dragon> to give Archos, when buying a "plugin" 17.30.23 # splled out in the system menu 17.30.45 # and in a file on the hd 17.31.46 # <[IDC]Dragon> now you want the file of a "loaded" box, eh? 17.32.26 # I think I can get away without it 17.33.44 # On a different subject; let's say I want to dump a debugging trace in a file 17.33.52 # how should I do it ? 17.34.40 # (on the target of course) 17.35.28 # Is there some kind of "fprintf" ? 17.35.30 # oi. 17.35.31 # bug. 17.35.42 # no wonder rockboy choked >.> 17.35.59 # mmm, looks like I found it ;) 17.36.38 # yea, there is 17.39.07 Quit muesli- (Read error: 113 (No route to host)) 17.42.51 # finally, stupid endian problems 17.43.58 Quit Patr3ck_ ("User pushed the X - because it's Xtra, baby") 17.44.38 # gotta go 17.44.48 Quit jyp ("poof!") 17.45.46 # * HCl goes to eat dinner 18.02.05 Join muesli- [0] (muesli_tv@1Cust121.tnt3.hnr2.deu.da.uu.net) 18.14.19 Join hubble [0] (hubble@h13n1fls302o1033.telia.com) 18.14.20 Quit muesli- (Read error: 54 (Connection reset by peer)) 18.16.31 Join iSheep [0] (~a@dpc691997050.direcpc.com) 18.16.39 # Hi guys 18.17.51 # My FM Recorder (with the original Archos firmware) is hanging on startup, stopping midway through the process and then eventually shutting down. Anyone ever encounter this? 18.23.57 Quit bobTHC ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") 18.28.59 Join muesli- [0] (muesli_tv@1Cust225.tnt8.hnr2.deu.da.uu.net) 18.42.00 Quit AC ("CGI:IRC (EOF)") 18.43.03 Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) 18.43.42 # playing with a new client....can anyone see this? 18.44.04 # Sure 18.44.17 # [IDC]Dragon: r u there? 18.44.44 # cool....thanks rasher.....just had to make sure firewall was not mesing things up again. LAter guys 18.45.41 Part Lurkski 18.50.49 # Bagder: r u around? 18.54.52 # back 18.58.40 # <[IDC]Dragon> amiconn: now I've looked 18.58.49 *** Saving seen data "./dancer.seen" 18.59.58 # I did now implement the loader for rockboy the way I already explained. However, I wonder if it would be possible/ make sense to write an .elf loader as a plugin... 19.00.37 # <[IDC]Dragon> hmm, I once messed with elf 19.00.55 # * [IDC]Dragon tries to remember 19.01.49 # <[IDC]Dragon> hehe, you could make your loader a viewer for .elf 19.02.28 # Hmm. That might be possible, but it wouldn't be useful for rockboy. Rockboy is a viewer by itself... 19.02.34 Quit muesli- (Read error: 110 (Connection timed out)) 19.02.51 # <[IDC]Dragon> ah, yes 19.03.07 # * [IDC]Dragon digs in old sources 19.04.24 # Imho there are 2 main problems: (1) Would an .elf loader fit in the plugin space, even leaving some buffer and (2) is it possible to do .elf handling chunked, without the need to load the whole .elf at once? 19.05.03 # That means, load the .elf bit by bit and directly link into the target ram area 19.05.23 # <[IDC]Dragon> I'd say this is unnecessary complex, but still searching... 19.06.01 Join Stryke` [0] (~Chairman8@resnet-241-86.resnet.UMBC.EDU) 19.06.02 # Yes, it is not absolutely necessary, but at least I would like to know if it's prossible 19.06.46 # *possible 19.07.18 # <[IDC]Dragon> I used some open source code to review an elf 19.07.30 # <[IDC]Dragon> ... still searching... 19.08.26 # <[IDC]Dragon> perhaps it was elfdump 19.09.14 Join MO-Pantsu [0] (Rori@deadman3000.plus.com) 19.09.42 # <[IDC]Dragon> once I went in an elf hexdum "by hand", but this was no fun 19.10.39 # <[IDC]Dragon> look here: http://elfio.sourceforge.net/index.php 19.11.17 # <[IDC]Dragon> yuck, c 19.11.24 # <[IDC]Dragon> C plusplus 19.11.48 # <[IDC]Dragon> cgiirc refuses 'plus' characters 19.13.30 # hah 19.16.34 Join XShocK [0] (~XShocK@pcp09492659pcs.nrockv01.md.comcast.net) 19.19.52 # XShocK: any luck on dma? :P 19.21.36 # HCl: Does your cpu memory variable->cpu reg transition work now? 19.21.59 Quit iSheep () 19.23.53 Quit Schnueff ("leaving") 19.25.40 # <[IDC]Dragon> amiconn: I found my elfdump, it is ansi c 19.26.36 Quit DeadMan (Read error: 110 (Connection timed out)) 19.27.38 # <[IDC]Dragon> now trying to tell where I fond it 19.28.25 # amiconn: uh, i don't quite get what you meant with that XD 19.28.41 # but yea, i altered the gameboy register memory layout, and its now suitable for dynarec 19.29.31 # HCl: I mean, you tried to change the gbz80 register layout in order to be able to hold them in host registers during execution of cpu_emulate() 19.29.39 # yea. 19.29.48 # here's my memory layout as it is at the moment: 19.30.01 # I think that if you can get dynarec to work, I might be able to adapt this for sh1 19.30.09 # registers a-e in 32bit vars, flags in 32 bit var, hl in 32 bit var 19.30.27 # since hl is mostly used as an a# register, its more sensible to not split them up 19.30.43 # preglow: no, couldn't make DMA work right 19.31.05 # HCl: Both host cpus are not too different. (1) 16 registers, with the 16th being the stack pointer. (2) big endian 19.31.15 # it nicely leaves me with 1 data register to still use 19.31.28 # unless i put HL in an address register 19.31.48 # Sh1 is a bit more flexible, because there is no difference between address and data registers 19.32.25 # amiconn: most instructions let you use both with the coldfire as well 19.32.46 # preglow: Yes, I know. As you said, most, but not all 19.33.09 # But there are some limitations of that kind on the sh as well 19.33.28 # yea, definately more flexible 19.33.34 # a# registers are really limited 19.33.37 # There are r0..r15, but some ops are only possible using r0 19.33.49 # sounds mips like. 19.33.59 # only mips4 has r0 hardwired to 0 19.35.15 # haha 19.41.02 Part hubble 19.44.16 Join funkymonkey [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk) 19.44.16 Quit methangas (Read error: 104 (Connection reset by peer)) 19.46.39 Quit funkymonkey (Read error: 104 (Connection reset by peer)) 19.51.36 Join methangas [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk) 19.52.59 Join Sucka [0] (~NNSCRIPT@host81-156-213-142.range81-156.btcentralplus.com) 19.59.53 Quit courtc (Read error: 110 (Connection timed out)) 20.02.53 Join muesli- [0] (muesli_tv@Bbc7c.b.pppool.de) 20.11.04 Join jyp [0] (~jp@111-103.245.81.adsl.skynet.be) 20.17.05 # * Bagder appears 20.19.42 # hi again Bagder 20.19.49 Quit muesli- (Read error: 60 (Operation timed out)) 20.19.58 # where did the latest patch error out? 20.20.42 # The latest patch needs one slight change, then it compiles with a few warnings. 20.20.50 # aha 20.20.57 # yes, it did introduce a few new warnings 20.21.06 # However, it does not link at all, as the x11 sim compiled on cygwin 20.21.11 # and I haven't verified functionality properly yet 20.21.17 # ok 20.21.25 # so what's the needed change? 20.21.38 # I mean for the error 20.22.37 # In uisimulator/common/io.c, the mkdir call (line 194) must not use the #ifdef. It is return (mkdir)(buffer, 0666); for win32 on cygwin as well 20.23.03 # I got "too few arguments...." before I changed that 20.23.30 # Btw, why are some function calls enclosed in parentheses there? 20.23.46 # because of weirdo sim-#defines from the past 20.23.53 # shouldn't be necessary anymore 20.23.55 # AH, so this may go away 20.24.00 # yeps 20.24.22 # The linker throws a heapload of unresolved symbols... 20.24.42 # do you have an older CVS around to compare link command line with? 20.24.57 # No I don't 20.25.02 # ok 20.25.37 # I keep forgetting the correct command line to do a dated checkout... 20.26.26 # cvs update -D "date" 20.26.26 # I think 20.28.01 # * amiconn fetches cvs as of Feb 16 20.29.09 Join Strath [0] (~mike@dgvlwinas01pool0-a239.wi.tds.net) 20.33.30 # Bagder: I need to remove the '@' in front of the command call from the Makefile in order to see the line, right? 20.33.39 # yeps 20.39.18 # are you making one with the latest too? 20.39.47 Nick Sucka is now known as Sucka`away (~NNSCRIPT@host81-156-213-142.range81-156.btcentralplus.com) 20.40.04 # Just a second; currently doing the same for X11 simulator & old cvs 20.40.16 # ok, that's useful too of course 20.40.48 # * Bagder walk away for 5 mins 20.40.51 # walks 20.47.05 Part CoCoLUS 20.49.17 Join _CoCoLUS [0] (~coco@h081217139221.dyn.cm.kabsi.at) 20.51.05 # Bagder: The x11 build now errors out in plugin.c. And maybe the win32build.log you got is mixed up. You client sent a strange resume request when I dcc'd the logfile 20.53.11 # can you understand why it complains on fdprintf() ? 20.55.13 # and for the link problems, can you try removing "-fno-builtin" from the Makefile in the build dir 20.56.33 # ah, the fdprintf thing maybe because I forgot to reconfigure, lemme check 20.57.13 # I reconfigured today, but maybe that was before another change to configure... 20.58.09 # I doubt that 20.58.48 # but try a make clean first 20.58.52 *** Saving seen data "./dancer.seen" 20.58.54 # just in case 20.59.36 # That was indeed the problem, now X11 is on par with win32 - linker errors 20.59.55 # Again a resume request... 21.00.39 # that might be because I overwrite a previous file with the same name 21.01.02 # I don't get it 21.01.12 # why doesn't fdprintf() exist as a function in plugin.c ? 21.01.21 # It does now. 21.01.22 # fprintf does. 21.01.38 # hm 21.01.53 # amiconn: then please resend the log ;-) 21.02.07 # HCl: not here, it is fdprintf() in my pending patch ;-) 21.02.16 # mhm :p 21.02.31 Nick _CoCoLUS is now known as CoCoLUS (~coco@h081217139221.dyn.cm.kabsi.at) 21.03.05 # try removing "-fno-builtin" from the Makefile in the build dir 21.04.19 # Huh? The linker options for the Win32 sim seem to be those that are intended to build the X11 simulator ???? 21.04.35 # export LDOPTS=-L/usr/X11R6/lib -lSM -lICE -lXt -lX11 -lXmu -lSM -lICE -lX11 -lpthread 21.04.52 # hm, you're right 21.05.43 # how silly 21.08.22 Join pillo [0] (~burellil@adsl-ull-175-133.47-151.net24.it) 21.09.05 Quit preglow ("n00bix") 21.10.10 # amiconn: ok, there's a -6 patch uploaded now 21.10.21 # requires a reconfigure 21.11.28 Join preglow [0] (thomj@s183a.studby.ntnu.no) 21.16.13 Quit rasher (Read error: 54 (Connection reset by peer)) 21.16.17 # Bagder: Now the mkdir() call has too many arguments... 21.16.27 # hahaha 21.16.45 # I think I know why 21.16.46 # Maybe some option is set differently in the makefile, making cygwin require the other syntax? 21.16.51 # yes 21.16.55 # -DNOCYGWIN I believe 21.17.13 # I added it now, since it was in the old one but not previously in the new 21.17.34 # The -Dno-cygwin is there to create standalone Win32 binaries that don't require the cygwin.dll 21.17.50 # yes 21.17.58 # but we don't care much about that 21.18.02 # This is desired for the win32 sim, otherwise it's not possible to lauch it by double-clicking 21.18.08 # aha 21.18.58 # I'll re-add the #ifdef... 21.19.00 # so perhaps we should put the mkdir back again then 21.19.30 Join hubble [0] (hubble@h13n1fls302o1033.telia.com) 21.21.41 # Bagder: Hmm, still doesn't link... 21.21.49 Join rashur [0] (~rasher@62.79.64.148.adsl.hs.tiscali.dk) 21.22.06 # Did you put the old log away? 21.22.16 # no, its still here 21.23.03 # * amiconn wants to send new log... 21.23.16 # wait, I notice a bug 21.25.16 # ok, beam it over 21.27.07 # Btw, the conditional defines at the top of firmware/include/file.h could be made unconditional, cause they are used by rockbox code only, or a I wrong? 21.27.14 # *am I wrong? 21.27.56 # yes they are 21.28.20 # Hmm. There is an #include at the top. Is this correct? 21.28.28 # I added such a file 21.28.33 # Ah. 21.28.42 # for size_t, off_t etc 21.28.58 # got bored by having to include file.h to get them 21.29.21 # Hmm. The defines therein could also be made unconditional (?) 21.29.34 # doesn't windows have a fsync() function ? 21.29.52 # amiconn: should be possible, yes, but I'm waiting with the beautifying things 21.30.21 # Okay, was just asking (partly myself) whether I understand what's going on... 21.31.40 # Shouldn't this read sim_fsync for simulator builds? 21.32.02 # yes, if we need to replace it 21.32.07 # which we seem to need 21.32.49 # Hmm. How is this handled in the old cvs build? 21.33.33 # wow.. cool.. wav working 21.33.42 # amiconn: I don't really know why it works in the old one 21.33.52 # #ifdef WIN32 21.33.52 # #define fsync _commit 21.33.52 # #endif 21.33.58 # aha 21.34.07 # how's the codec-interface going? 21.34.12 # (that's from the old uisimulator/common/file.h) 21.34.34 # This seems to also use/need: 21.34.34 # #ifdef WIN32 21.34.35 # #ifndef _commit 21.34.35 DBUG Enqueued KICK amiconn 21.34.35 # extern int _commit( int handle ); 21.35.24 # hubble: Read today's IRC log. I don't think anyone's coded anything yet (apart from what's in CVS). 21.35.47 # linuxstb: ok.. i guess wiki is not updated? 21.35.49 # amiconn: I'm moving that to uisim/common/io.c and adding sim_fsync() there 21.35.58 # Okay. 21.37.12 # Then you don't need the define, but simply the commit() call iiuc 21.37.24 # yes 21.38.08 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 21.38.08 # * HCl suddenly realizes a fundemental flaw and why rockboy was crashing 21.38.17 # amiconn: uploading another version now 21.38.30 # mental note; never forget to clear newly allocated ram 21.39.41 # yeah that's quite a GoodThing(tm) ;) 21.39.58 Join Chamois [0] (~52e2b617@labb.contactor.se) 21.42.20 Join ghode|afk [0] (dude@host217-137-6-24.no-dns-yet.ntli.net) 21.42.27 # Bagder: Link problem with fsync() now gone. The other link problems are still there... 21.42.47 # I don't get why this doesn't want to link with windows native functions... 21.43.02 # preglow: err hi, wondering if there is any update on the windows firmware patcher you were working on? 21.43.39 # no, that's weird 21.44.34 # Hmm. Maybe the windows libs must be put after rockbox' own libs? 21.44.51 # perhaps 21.44.52 # i read wav works 21.45.01 # I once had the same problem, obviously the order of -l options is sometimes important 21.45.02 # sound works on iriver ? 21.45.13 # ghode|afk: no, not really, it kind of works, but i don't urgently work on it, 'cause it's still a while to go before rockbox is release ready 21.45.28 # amiconn: yes, in not always so obvious ways 21.45.55 # ok thanks 21.46.06 # The old build put -lgdi32 -luser32 -mno-cygwin at the very end of the line... 21.46.13 # * ghode|afk goes back to reading irc logs. 21.46.18 Quit ghode|afk (Client Quit) 21.48.04 # amiconn: edit apps/Makefile (line 107) and move $(LDOPTS) to the end of the link line 21.49.29 # I moved it behind -lcomsim, this should be sufficient... 21.49.37 # yeps 21.49.56 # slightly ot: how do I tell vim to read the "vim special tags" in the files (such as /*vim: et sw=4 ts=8 sts=4 tw=78*/)? 21.50.22 # * Bagder uses emacs! 21.50.42 # * pillo loves that sweet :wq ;) 21.52.09 # came back home 21.52.30 # XShocK: i got wav loading and playing from your code now =) 21.52.31 # jyp: Are you around? 21.52.36 # Bagder: The link problems with the various gdi functions are solved by that. However, it still errors on undefined references to _LoadLibrary / FreeLibrary .... 21.52.46 # hubble: good. :) 21.52.48 # XShocK: where did you get "*((&INTBASE)+8) = 72;" from and is it important? 21.52.49 Join courtc [0] (~court@adsl-158-8-175.asm.bellsouth.net) 21.53.20 # Secondary Interrupt 8, AUDIOTICK vector set to 72. 21.53.44 # Bagder: Maybe the plugin_load functions also need sim_ implementations? Maybe a proper windows header needs to be included for these functions... 21.53.54 # linuxstb: I'm here 21.54.04 # for 1 hour maybe 21.54.04 # amiconn: I was just thinking in those lines too 21.54.04 # XShocK: where did you read that you could set that number? i didnt find it in the docs 21.54.14 # Bagder: Want the log? 21.54.17 # how many time for wav in cbs ? 21.54.21 # *CVS 21.54.27 # amiconn: nah, not needed for this 21.54.30 # i will look it up now 21.54.47 # jyp: I think your CVS change has broken libFLAC. 21.55.27 # * Bagder walks away for a while 21.55.32 # That "realloc" is needed to allocate memory for the seektable - so a NULL pointer is now dereferenced. 21.55.47 # linuxstb: mmm; I didn't intend to commit anything regarding libFLAC 21.55.50 # hubble: 9.4.2.2 21.55.54 # Bagder: Same goes for the GetProcAddress warning... 21.56.07 # It's the latest CVS change - "typo" was your log message :-) 21.56.15 # hubble: of User Manual 21.56.28 # At 11.59 GMT today. 21.56.58 # damn, I comitted the wrong file 21.57.14 # No problem. Is there an easy way to reverse it? 21.57.21 # I guess 21.57.23 # hubble: it says that RESET values of vectors are 0 initially, and i don't think there is any other way hardware of firmware set those things by itself. 21.57.34 # XShocK: aha, i though you only could set the INTBASE byte, not that it was an entire array =)) 21.57.41 # *hardware or firmware :) 21.57.54 # :) 21.59.38 # XShocK: so we can skip to set the INTBASE byte only to set the AUDIOTICKS? 22.00.42 # hubble: repeat, i didn't understand what you said. 22.01.28 # jyp: Shall I reverse your commit or will you? 22.01.40 # I'm looking into it 22.02.01 # tough I don't quite remember the adequate cvs command 22.04.20 # Ok I'm committing the reversal 22.04.50 # Thanks. 22.05.38 # Please check that it's the correct thing 22.10.11 Join Patr3ck [0] (~patr3ck@pD9E5CB2F.dip.t-dialin.net) 22.13.38 Quit Stryke` ("Friends don't let friends listen to Anti-Flag") 22.15.26 # jyp: Yes, that's perfect - a diff between 1.3 and 1.5 shows no differences. Thanks. 22.15.53 # xD 22.16.00 # You're welcome; sorry for my bad move 22.16.09 # my mobile phone company just managed to charge me MINUS 0.26 cents for using my mobile phone xD 22.16.27 # they're actually paying me! XD 22.16.40 # HCl: COMPLAIN! 22.16.43 # xd 22.16.48 # its hilarious 22.16.52 # brb 22.24.08 Join midk_ [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 22.30.24 Join LukeA [0] (~a@dpc691997050.direcpc.com) 22.30.35 # linuxstb: it would be really cool if I could chose to compile only certain codecs 22.31.00 # since some cause compile errors 22.32.30 # jyp: Yes, I think we need that. Maybe Bagder has a better idea, but you could simply add a #if to the codecs/Makefile 22.32.33 Quit midk (Read error: 60 (Operation timed out)) 22.32.50 # Alternatively, I'll have to commit workarounds for all the codecs... 22.33.07 Join Bluechip [0] (~BlueChip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) 22.33.27 # so, just a "weak" request. 22.34.05 # well, my dynarec crashes on opcode 50... why is that.. 22.34.42 # jyp: Maybe we should make the codecs compile for you. Which ones work, and which ones don't 22.35.14 # For now, none do :P 22.36.18 # i wish there was a normal way to debug this :/ 22.37.50 # watashi wa baka desu :x 22.38.15 # HCl: do the gdb stub :) 22.38.16 # hey, how do I upgrade to the latest version of Rockbox? On my FM Recorder, it shows 2.1 whenever it starts up, and I'd like to put 2.4 on there 22.38.37 # HCl: I hope you leave dynarec selectable via a #define, or are you going to implement dynarec for the sims too? ;) 22.39.23 # Bagder: In case you're back: I have some more findings... 22.43.13 # i'm making progress. 22.43.23 # it can still be fairly easily to comment out 22.44.30 # back now 22.44.40 # Nice :) 22.45.16 # Two things: (1) It looks like we really need a simulator implementation for plugin_load() 22.45.47 Quit LukeA () 22.45.49 # The old win32 sim used to use plugin-win32.h, and this included windows.h, but we can't include windows.h from plugin.h 22.46.12 # yeps, we'll do that for the sim version of plugin_load 22.46.17 # ..because then there are conflicting types again (and no clear separation between target & sim code 22.46.57 # (2) The X11 sim does *almost* link now, only one undefined symbol left: _stderr 22.47.11 # (for debugf(), ldebugf() ) 22.47.53 # This is still crossing rockbox<->simulator. It looks like we need sim_debugf() and sim_ldebugf() too 22.48.01 # yeps 22.48.58 # Did you try if your patches compile on Linux? 22.49.08 # yes 22.49.22 # plain linux, not the win32 crosscompile 22.49.38 # I believe it will have some issues 22.49.44 # but that's the least important version 22.49.48 # Yes. You don't get the undefined _stderr? 22.49.57 # no 22.50.08 # Hmm. I wonder why 22.50.34 # That means there is still some rockbox<->simulator overlap, because stderr is not defined at all in rockbox 22.51.01 Quit jyp ("poof!") 22.51.02 # I believe its another issue with needing a system include file 22.51.17 # so makeing a sim_* version out of it should fix it 22.52.03 # debug.c includes stdarg.h. There is no stdarg.h in rockbox... 22.52.36 # but there is in the sh include path 22.53.59 Join stripwax [0] (~stripwax@213-228-241-36.dsl.prodigynet.co.uk) 22.54.05 # ello 22.54.07 # Hmm. I think when rockbox and simulator code are separated and everything compiles cleanly, there are some #include statements in a number of source files that can & should be removed. 22.54.29 # dohhhhh 22.54.31 # * HCl slaps himself. 22.55.41 # got a question about the iriver port - i notice some devs are now introducing EMAC specific code into their codecs - is the EMAC state properly saved/restored on a task switch? 22.57.52 # * HCl isn't sure what emac is so wouldn't know :x 22.58.22 # it's kinda like MMX or SSE on those Intel chips :-S 22.58.23 # stripwax: I think emac is handled the same way as the mac registers on sh - they're considered scratch registers 22.58.30 # ah. 22.58.53 # And, since rockbox does not do preemptive multitasking, there is no need to preserve state 22.58.55 # stripwax: we have cooperative multitasking? 22.58.56 *** Saving seen data "./dancer.seen" 22.59.24 # I don't know how rockbox handles tasks. if it's cooperative I guess there's no problem! 22.59.44 # stripwax: extactly. 22.59.51 # thx! 23.01.52 # yes, like he says 23.02.22 # if you depend on %%macx contents over a yield(), you're very optimistic, heh 23.03.22 Join DMJC [0] (~James@220-245-162-47-sa-nt.tpgi.com.au) 23.07.34 # Something else I had on my mind - for iRiver, is there any particular reason the LCD is initialised in mono mode rather than 4-color mode? Is it any harder to initialise in 4-color mode (and plot two bits per pixel)? That would seem like a first step towards a fully greyscale-enabled rockbox? 23.07.58 # just not done yet 23.08.06 # fairynuff 23.08.18 # lots of consideration needs to be made first 23.08.25 # since all lcd code assumes b/w 23.08.29 # stripwax: It's not the init. The graphics routines need to be rewritten 23.10.19 # How much is there though - line drawing and font rendering just need to plot two bits per pixel instead of one .. -? 23.10.50 # then what would the point of using greyscale be? 23.11.12 # I'd say fonts and lines etc should be able to use greyscales 23.11.33 # the two bits needn't be the same ;-) 23.12.16 # right, and then you need a new font format and lots of new code and protos ;-) 23.12.29 # You need to be able to set the 'color' to use for the line/ pixel etc 23.12.38 # I don't understand why you'd need a new font format. The iRiver stock firmware doesn't store colored fonts 23.12.43 # Currently, there are set/clear/invert routines 23.13.03 # stripwax: we don't make their firmware ;-) 23.13.10 # *I* want multicolor fonts 23.13.21 # antialias! 23.13.26 # A new font format isn't necessary unless we want multicolour fonts, something unnecessary imho 23.13.27 # That doesn't go too well with using bdf fonts though does it? 23.13.47 # we don't use bdf fonts 23.13.48 # Badger - my point is that, what if you want to color the fonts with top two pixels light grey, next two pixels dark grey, and the rest black. is that going to be a separate font file? 23.13.56 # we just convert from bdf to our own format 23.14.34 # Ok, antialias fonts will need a separate font file :-D 23.14.50 # amiconn - right so maybe the Set function could take an (optional) color arg 23.14.59 # although I agree multicolor font is not #1 on my prio list ;-) 23.15.07 # And btw, extending the gfx api to provide support for setting the colour (yes, also thinking ahead for H3xx) does not necessarily mean more code 23.15.21 # So just AND the font with a color and plot that 23.15.36 # Currently, there are 3 functions for each mode (drawline/ clearline/ invertline) 23.15.49 # 'mode'? 23.15.54 # Bagder: well yes 23.16.19 # If we change this to a similar approach as the grayscale lib already uses, there would only be one drawline function 23.16.57 # stripwax: Yes. drawline() draws black pixels, clearline() draws white pixels, and invertline() inverts all pixels 23.17.20 # (I know that there is no invertline, but for other function the is an invert* kind) 23.17.29 # amiconn - by 'mode' did you mean 'drawing lines'? what are the other modes? 23.17.59 # No, by mode I mean how the drawing functions behave 23.18.17 # Currently, there is no mode concept, so all functions exist in different variants 23.18.24 # what did you mean by "3 functions for each mode" then? 23.18.48 # No, you got this slightly wrong (perhaps I was unclear) 23.18.56 # set/clear/invert functions for lines, text, and what else? 23.19.27 # I mean, since there is no concept of drawing modes, there are (max.) 3 functions for one graphics primitive, i.e. 23.19.55 # amiconn: ... and there's now a -8 patch uploaded 23.20.12 # drawpixel/clearpixel/invertpixel, drawline/clearline/invertline etc. 23.20.41 # amiconn - right ,so draw* could take an (optional) color arg .. .? 23.21.29 # Yes, that would be one option, but this usually leads to unnecessary many arguments, which in turn leads to larger binaries 23.22.00 # Please have a look at the grayscale lib. It uses a drawing mode concept, and a foregroud and background colour 23.22.16 # The mode and the two colours can be set by separate function calls 23.22.20 # amiconn - bigger binaries than having two functions to draw/clear every kind of graphic primative!? 23.22.38 # Nope, but bigger binaries than with the mode concept 23.22.41 # oh there's already a grayscale lib? ok I'll look at that. what uses it 23.23.02 # Believe me, I first had the 'extra arguments' approach within the grayscale lib... 23.23.28 # amiconn - no, I agree that a setforeground/setbackground is better 23.23.32 # The grayscale lib currently only works on the archos devices 23.23.54 # setforeground, setbackground, setmode, and (optionally) a function that sets all three 23.24.30 # Ok, now I'm really confused, because I thought Rockbox only supported 1-bit LCDs even on Archos? Guess I'll just go read the code again 23.25.11 # stripwax: that was before amiconn's magic greyscale lib ;-) 23.25.14 # The grayscale lib is only for plugins 23.25.31 # It uses temporal dithering to simulate up to 33 grayscales 23.26.00 # amiconn - heh, neat! 23.26.37 # It's e.g. used by the jpeg viewer 23.28.05 # Bagder: Building... 23.28.35 Quit Zezayer ("ChatZilla 0.9.61 [Mozilla rv:1.7.2/20040804]") 23.29.02 # * HCl is finally getting the expected result from his dynarec 23.29.48 # Bagder: The linker errors with missing symbols are gone. :) However, now there is a duplicate symbol: _debugf :( 23.29.56 # oh 23.30.08 # did you make clean first? 23.30.16 # there's something broken with the dependencies atm 23.30.18 # Yup, and reconfigured as well 23.30.18 # HCl: coool! 23.30.21 # ok 23.30.24 # I'll check 23.30.27 # Log? 23.30.35 # nah, not needed 23.30.46 Join LinusN [0] (~linus@labb.contactor.se) 23.30.46 # /uisimulator/common/io.c:346: multiple definition of `_debugf' 23.30.57 # pillo: well, it just yells out "unimplemented opcode!" at the moment, but at least, its finally what its supposed to be doing 23.31.04 # uisimulator/win32/debug-win32.c:51: first defined here 23.31.08 # the emac accumulators are not preserved 23.31.09 # aha 23.31.23 # HCl: cute anyways isn't it? ;) 23.31.47 # amiconn: you think the debug-win32.c approach is useful? 23.32.33 # I'm not even sure what it does 23.32.44 # Hmm. I don't know; didn't fiddle with windows debuggers so far 23.33.07 # ok, I'll leave it in and make the other code x11-specific 23.34.09 # It looks like it can hook into a debugger if present, otherwise simply uses printf(). I'd suggest to leave that as-is, even though I don't know how this is supposed to be used... 23.34.26 # pillo: yup, now i can actually work on it 23.35.06 # amiconn: so if you "if 0" out the debugf functions in the bottom uisim/common/io.c can you link fine then? 23.36.08 # HCl: Is there some reading about dynarec you can point me to? I don't understand the following: 23.36.40 # You say that z80 instructions are compiled into host instructions until a jump instruction is detected. 23.36.44 # yea 23.37.06 # How is the case handled if some code jumps *into* such a chain? 23.37.08 # thats not in my dynarec yet, heh 23.37.21 # it recompiles a new block 23.37.34 # HCl: congrats & keep up the great job you're doing! We're all waiting for the two player version (one on the player, one on the remote) :) 23.37.45 # Hmm. Sounds a bit inefficient, memory-wise 23.37.58 # yup, in a way, they are. 23.38.05 # there's room for optimization. 23.38.11 # but its not nice to fix. 23.38.36 # you're free to offer suggestions, heh. 23.38.42 # Is dynarec something to do with the gameboy emulator? 23.38.49 # mmm. 23.39.25 # HCl: ( you're free to offer suggestions, heh.) That's why I asked for recommended reading... 23.40.19 # mmm. 23.40.23 # i'm not sure if i have much... 23.40.28 # let me search a bit. 23.40.57 # amiconn: http://daniel.haxx.se/rockbox/simfix-9.patch 23.41.00 # Bagder: Main simulator now builds & links. Even a number of plugin compiles & links fine. Then it errors in calendar.c 23.41.22 # http://acorn.cybervillage.co.uk/emulation/dynrcomp.htm 23.41.24 # how's that? 23.41.27 # (ok, never mind that patch it is just that little fix) 23.41.56 # Bagder: There are however warnings for the plugins about conflicting types... Want the log? 23.42.03 # sure 23.43.07 # Bah, resume.... 23.43.51 # I'll try x11 sim in the meantime... 23.44.54 Part stripwax 23.45.15 Quit midk_ ("Leaving") 23.46.00 # right, we need -fno-builtin to prevent warnings on some functions gcc has built-in stuff for 23.46.29 # Bagder: The win32 simulator .exe runs, but the background image isn't there. The icon is also missing. 23.46.53 Quit methangas (" HydraIRC -> http://www.hydrairc.com <-") 23.46.58 # I presume the resource file isn't included 23.47.44 # it is supposed to ;-) 23.50.08 # so what is the calendar.c problem? 23.50.43 # Did you have a look at the log? And/or deleted it, to avoid the dcc resume? 23.51.31 Join skav [0] (skav@67-138-74-184.dsl1.merch.roc.ny.frontiernet.net) 23.51.31 # I deleted it, it wasn't correct 23.51.56 # There :) 23.53.06 # Ah, it's fprintf... 23.53.08 # now why didn't I see that? ;-) was a fprintf() 23.54.54 # There are 'conflicting types for built-in function' warnings for the rockbox part too. Is that solved with -fno-builtin too? 23.55.11 # yes 23.57.01 Join Renko [0] (~Renko@host217-43-59-232.range217-43.btcentralplus.com) 23.57.01 Quit DMJC ("Leaving")