--- Log for 18.02.105 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 14 days and 15 hours ago 00.00.00 # i just wondered how the sound progress for iriverbox is coming on 00.00.00 # yup 00.00.07 # oki.. great 00.00.14 # LinusN: where did you get that 54? 00.00.30 # dma0 is the 54th vector in system.c 00.00.32 # Digital007: we gave up because someone forgot to bring cookies 00.00.40 # what? 00.00.46 # why do u need cookiues for? 00.00.57 # to munch! 00.01.00 # Digital007: he was not answering your question with 54 =) 00.01.12 # i thhought u meant cookies as web code cookies 00.01.35 # what would http cookies have to do with embedded development/ 00.01.37 # ? 00.01.44 # omg 00.01.46 # would be great to have MP3Pro as a codec as well 00.02.35 # hehe 00.02.48 # gotta sleep, happy dma:ing 00.02.54 # MP3Pro sounds much better than WMA and almost as good as normal MP3 00.02.55 # whats the dma for? 00.03.02 # feeding the dac 00.03.05 # ok 00.03.09 Part LinusN 00.03.23 Join Nibbler [0] (~sven@port-195-158-163-29.dynamic.qsc.de) 00.03.37 # amiconn: any progress? 00.03.37 # hubble: did you understand where this 54 came from? I don't see anything like that in system.c 00.03.52 # HCl: Currently rewriting makefile... 00.03.54 # i thought the sound was 54% doen 00.03.55 # done 00.03.55 # okies.. 00.04.10 # what does flac require 64 bit numbers for? 32x32 muls? 00.04.34 # preglow: he mentioned something more in that forum thread, I closed that tab ;-) 00.05.16 # XShocK: if you count the index in irqname[] to DMA0 i guess that's 54 00.06.07 Quit skav (Read error: 54 (Connection reset by peer)) 00.06.14 # XShocK: but i'm not sure where DMA0 is defined 00.06.27 # ok. 00.06.43 # i guess this: default_interrupt (DMA0); /* DMA 0 */ 00.06.57 # and then i think you shoud put you own implementation 00.07.34 # we probably should use the emac for as much as possible anyway, so we might not be affected by all the 64 bit stuff 00.07.44 # XShocK: aa.. default_interrupt macro expands it into a function definition 00.08.07 Join fubar [0] (alan@moonfish.org.uk) 00.08.14 # XShocK: and then the .vectors array contains the function call 00.08.22 # s/call/pointer 00.09.03 # .vectors array? 00.09.26 # Bagder: i can't imagine why they'd need 64 bit variables other than to do 32x32 muls 00.09.26 # Bagder: and the emac does that for us 00.10.05 # hmmm 00.10.20 # he said this "FLAC supports up to 32-bits per sample losslessly which means there are a lot of 64-bit datapaths. and the seeking and metadata interfaces that work with 64-bit sample number are numerous." 00.10.35 Join mrmags [0] (~stryfe@ool-4351b9f0.dyn.optonline.net) 00.10.53 # support WMA Lossless!!!!!! 00.11.29 # why? 00.11.54 Quit Digital007 ("CGI:IRC (EOF)") 00.12.11 # oh, and get rockbox to make coffee!! ;p 00.12.15 Join Digital007 [0] (~acd5e828@labb.contactor.se) 00.12.18 # Bagder: the latter part shouldn't be that much of a problem, i think 00.12.23 # WMA Lossless - WAV quality at half the file size 00.12.34 # Digital007: Flac - WAV quality at half the file size 00.12.49 # Digital007: there's no way for us to support wma lossless, afaik ms has not released specs 00.13.02 # ok 00.13.38 # hrmf 00.16.43 # I know xine supports wma, but I'm not sure if it uses the win32 codec 00.17.51 # wma, yes, but does it support wma lossless? 00.18.08 # ffmpeg has a wma decoder, but there are quite a lot of wma versions around 00.21.04 # it probably uses the win32 codec anyway 00.21.20 # also, there's not that much lost in not supporting lossless formats 00.21.25 # people can always convert :) 00.21.33 # very true 00.22.11 # Aren't there licencing issues to worry about if ur writing software codecs? 00.22.36 # not worry, but we need to adhere 00.22.41 # ok 00.22.42 # ffmpeg has a fpoint wma decoder 00.22.54 # I've noticed that the battery meter always flashes empty even on a fully charged iRiver 00.23.18 # Bah, obviously I don't fully understand 'make' yet 00.23.32 # make[3]: *** No rule to make target `/home/Administrator/rb-gameboy/build/recorder/rockboy/cpu.o', n 00.23.32 # eeded by `/home/Administrator/rb-gameboy/build/recorder/rockboy/rockboy.elf'. Stop. 00.23.37 # Digital007: that's "covered" in the wiki 00.23.42 # k 00.24.00 # battery level detection isn't done yet 00.24.14 # The rule should be covered by including make.inc ... 00.25.16 Quit ashridah (Read error: 60 (Operation timed out)) 00.25.33 # check the depfile 00.26.00 # Hmm. It didn't build one. 00.26.03 # but I agree, it should be covered by that rule 00.26.36 # In fact, this should be in builddir/rockboy/ or may this not work, i.e. the dir not yet created (??) 00.27.22 # Hmm. Still not created... How is the depfile supposed to be created? 00.27.43 # SOURCES must contain all C sources 00.27.56 # C and asm actually 00.28.15 # This variable must be called exactly SOURCES ? 00.28.18 # yes 00.28.21 # make.inc uses that 00.28.30 # Ah, then this is the problem... 00.29.38 # the include line makes make check the depfile dependency and thus rebuild 00.29.58 # Now the depfile is there, but I still get the same error... 00.30.08 Quit muesli_- (Read error: 110 (Connection timed out)) 00.31.32 # Hmm, the depfile lists cpu.o in the wrong dir 00.32.01 # It wants it in builddir/ while I intend to have it in builddir/rockboy/ 00.32.09 # Is that possible? 00.32.40 # it is, the recorder/ and driver/ etc are treated that way 00.33.06 Quit methangas (" HydraIRC -> http://www.hydrairc.com <- IRC for those that like to be different") 00.33.29 # Yeah... but in these directories there is no separate Makefile. These are handled in the Makefile of the parent dir 00.33.48 # yes 00.33.55 # that's true 00.34.48 # ... its not very easily done atm, I think 00.34.57 Quit CoCoLUS () 00.36.30 # Hmm. if I redefine $(OBJDIR) within the Makefile, would this work? 00.37.01 # yes, that should work 00.37.54 # I've been planning to move all object files into subdirs better 00.38.19 # like you do now 00.39.02 # yea, every plugin should have its own subdir, really.. imho.. 00.39.06 # but ok, i'm gonna go sleep.. 00.39.32 # one subdir for each would be overkill 00.39.57 # having the ability to have one, yes 00.40.06 # yea, ok. 00.42.14 Join ashridah [0] (ashridah@220-253-118-175.VIC.netspace.net.au) 00.47.14 # * HCl suddenly discovers the existence of a rockbox forum 00.47.26 Join bagawk [0] (~Lee@bagawk.user) 00.47.45 # heh you don't want to go near those things :X 00.47.53 # Bagder: Redefining the variable doesn't work... 00.48.01 # noob support city :< 00.48.38 # lol 00.48.59 Quit DMJC ("Leaving") 00.49.38 # it's not that bad really 00.49.49 # just not of much use either 00.49.55 # I need to sleep. If you don't get any further amiconn, I'll help you sort that out tomorrow 00.50.02 # heh maybe not on rockbox ones... don't look in the ipl ones :< 00.50.28 # Bagder: Np, thanks for your help. Good night 00.50.46 # Well these are people who bought ipods, what did you expect? :) 00.53.08 Join linuxstb [0] (~linuxstb@dsl-212-23-31-215.zen.co.uk) 00.53.21 # are you saying all ipod users are thick? 00.53.56 # ipl? 00.54.02 # ipod linux... 00.54.07 # oh 00.54.10 # :p 00.54.12 # nope, but I'm rather guessing a lot are 00.54.18 # yeah well you'd be right :( 00.54.29 Quit bagawk ("Leaving") 00.55.50 # (about a lot.. not all heh) 00.56.51 *** Saving seen data "./dancer.seen" 00.57.56 # Well it was a generalization - those rarely fit everyone :) 00.58.20 Join skav [0] (skav@67-138-74-184.dsl1.merch.roc.ny.frontiernet.net) 00.58.28 # yea, you can't make a generalization without allowing room for exeptions 00.59.02 Join DrRick [0] (DrRick@81-86-80-158.dsl.pipex.com) 01.03.37 Join Quelsaruk [0] (~kvirc@80.103.134.240) 01.03.42 # i'm back 01.03.43 # :) 01.13.32 # ohno! :p 01.13.37 # hi :p 01.13.42 # :P 01.14.49 # * HCl goes to sleep :p 01.14.54 # nite 01.15.50 Quit DrRick () 01.22.22 Part mrmags 01.25.12 Quit lolo-laptop ("Client exiting") 01.25.52 Quit _aLF ("Leaving") 01.26.22 Join kramerica [0] (~lkd@hsdbsk142-165-191-185.sasknet.sk.ca) 01.29.38 Quit preglow ("off") 01.32.36 Quit Patr3ck (Read error: 54 (Connection reset by peer)) 01.36.59 Quit hubble () 01.39.21 # night! 01.39.41 Quit Quelsaruk ("KVIrc 3.0.1.99 'Realia'") 01.52.04 # yay! Makefile is working! 01.52.04 Quit kramerica (Read error: 104 (Connection reset by peer)) 01.57.51 # :) 01.57.57 # but i'm asleep *nods* 02.00.55 Quit Sucka ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") 02.06.43 # * HCl tries amiconn 's lcd driver for iriver 02.06.51 # amiconn: do you have an iriver? 02.06.58 # amiconn: made any pics of rockboy on archos yet? 02.07.00 # nope 02.07.17 # I tried making pics, but my batteries died again :( 02.07.33 # Does the lcd driver work? 02.10.22 # Btw, I renamed iriver.c to sys_rockbox.c 02.10.25 # it works 02.10.33 # it doesn't seem to be that much faster 02.10.37 # still about 1 fps 02.10.48 # but every bit helps, really 02.10.51 Join muz [0] (~54091287@labb.contactor.se) 02.11.13 # hey is it possible to play files from the tag database right now? 02.11.47 Quit Digital007 ("CGI:IRC (Ping timeout)") 02.14.23 # muz: On ajb it is. 02.14.34 # archos jukebox? 02.14.45 # yup 02.14.55 # it says on the wiki that u can only browse 02.15.10 # Then the wiki is out of date 02.15.22 # oh right 02.15.46 # is there any disadvantage in using the tag database (ie longer boot time as on iriver firmwar) 02.16.39 # I didn't test much, because my mp3 collection is well organised, but from the few tests I did I had the impresion it is slightly slower than file browsing 02.17.19 # but it still does things like accelerated scrolling, so one can navigate through lists quickly 02.17.29 # right? 02.17.38 # yup 02.17.52 # thats so cool 02.19.11 # how is linus getting along with the clock speed of the iriver? 02.19.45 # I have no idea. 02.20.11 # anyway thanks im gonna head off now 02.20.28 Quit muz ("CGI:IRC") 02.20.36 # well. at least interrupts seem easyish on z80 02.20.59 # Did you have a look at the cpu core emu? 02.21.39 # well, yea, but thats mostly gobbilygook, with gotos and too many defines, so i'm reading technical data 02.21.44 # http://www.work.de/nocash/pandocs.htm#gameboytechnicaldata 02.21.57 # apparently, there are only 5 interrupts 02.22.06 # video, lcd stat thingy, timer, serial and joypad 02.22.52 # and with dynarec, the biggest trouble is timing the interrupts right, really 02.22.59 # cause you get blocks of code 02.23.10 # that can't really stop execution 02.23.14 # in the middle 02.23.17 # to allow for an interrupt 02.24.03 # Hmm. I don't really know about how dynarec is implemented, and don't have the time to also deal with that, at least not atm. 02.24.10 # its fine :) 02.24.17 # i'm mostly waiting for linus to get it to 140mhz 02.24.19 # see how it runs then 02.24.23 # then start on dynarec 02.24.40 # Dynarec might be helpful on archos.... but it's a different cpu 02.24.48 # yea. 02.24.56 # but dynarec is fairly easy to port 02.25.11 # you just get things like void Z80_ADD_OPCODE() { } 02.25.25 # and you have to fill in the proper m68k assembly for it 02.25.46 # i'm not really gonna do any advanced optimalization. 02.25.54 # just chaining them together should provide more than enough speed 02.26.08 # but ok 02.26.09 # sleeeep. 02.26.11 # darnit 02.26.12 # >.< 02.26.14 # The makefile seems to work properly now. The next things I'l do are 02.26.22 # i promised my gf i'd go to sleep early, and again i haven't yet :( 02.26.26 # mm? 02.26.34 Join lostlogic [0] (~lostlogic@node-4024215a.mdw.onnet.us.uu.net) 02.26.57 # heh gnuboy runs better on os x than the normal os x emulators 02.27.01 # well, that's without sound 02.27.01 # (1) Write that loader plugin to allow rockboy for archos to run on unmodified rockbox (32 KB 'normal' plugin ram) 02.27.10 # mhm 02.27.20 # (2) Trash those darn warnings 02.27.24 # heheh 02.27.25 # (3) Commit to cvs 02.27.28 # yay. 02.27.46 # ..but all that has to wait due to sleep needed. 02.28.10 # Nite. 02.28.14 # night 02.28.30 Part amiconn 02.28.31 Quit edx (Read error: 110 (Connection timed out)) 02.42.00 Quit toolmanwv (Read error: 54 (Connection reset by peer)) 02.42.18 Join toolmanwv [0] (~aaa@pool-70-18-122-238.buff.east.verizon.net) 02.49.32 Quit coob (Read error: 60 (Operation timed out)) 02.56.53 *** Saving seen data "./dancer.seen" 03.01.28 Quit toolmanwv ("—I-n-v-i-s-i-o-n— 2.0 Build 3515") 03.03.58 Join cYmen_ [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 03.05.08 Quit cYmen (Read error: 104 (Connection reset by peer)) 03.30.26 Quit skav () 03.36.46 Quit Aison (Read error: 104 (Connection reset by peer)) 04.05.42 Join QT_ [0] (as@area51.users.madwifi) 04.07.45 Join edx [0] (edx@p54879BA1.dip.t-dialin.net) 04.09.01 Quit QT (Read error: 60 (Operation timed out)) 04.15.59 Join mrmags [0] (~stryfe@ool-4351b9f0.dyn.optonline.net) 04.21.48 Quit cYmen_ ("leaving") 04.30.00 Part mrmags 04.46.40 Quit XShocK (" HydraIRC -> http://www.hydrairc.com <- Leading Edge IRC") 04.56.57 *** Saving seen data "./dancer.seen" 06.56.59 *** No seen item changed, no save performed. 07.23.33 Join pilled [0] (dearth@ip-130.net-82-216-140.issy4.rev.numericable.fr) 07.30.03 Quit mecraw () 07.39.35 Join kramerica [0] (~lkd@hsdbsk142-165-191-185.sasknet.sk.ca) 07.42.57 Quit pill (Read error: 110 (Connection timed out)) 07.42.58 Nick pilled is now known as pill (dearth@ip-130.net-82-216-140.issy4.rev.numericable.fr) 07.57.04 Join Patr3ck [0] (~patr3ck@pD9ECFF37.dip.t-dialin.net) 07.57.05 Quit kramerica (Read error: 104 (Connection reset by peer)) 08.02.22 Quit Hohoman ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") 08.09.10 Join LinusN [0] (~linus@labb.contactor.se) 08.47.27 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 08.56.08 Quit Stryke` ("Friends don't let friends listen to Anti-Flag") 08.57.01 *** Saving seen data "./dancer.seen" 09.04.05 Join einhirn [0] (Miranda@bsod.rz.tu-clausthal.de) 09.04.38 # LinusN: no M3 yet? 09.04.48 # nope 09.05.16 # strange, its supposed to be in stores the 22nd 09.05.24 # yup 09.10.04 Nick Lynx_awy is now known as Lynx_ (HydraIRC@134.95.189.59) 09.13.01 # man, calculating all this clock timing is tedious... 09.13.44 # I figure that 09.15.48 # m3? you mean the other coldfire based mp3/ogg/flac player? 09.15.58 # no, its a swedish magazine 09.16.01 # paper version 09.16.06 # ah 09.16.28 # there just might be something about Rockbox is this upcoming issue 09.18.23 # :O 09.18.44 # nice 09.18.59 # is it in english or swedish? 09.19.04 # swedish 09.19.55 # we were interviewed for the article before xmas 09.20.27 # what did you say? 09.21.05 # we talked about Rockbox, what it is, how it started, what we do, who we are and what we are doing atm 09.21.11 # What if, the JoS players would use rockbox? ;) 09.21.46 # then of course, atm == late dec, which meant no working iRiver version 09.21.49 # JoS? 09.21.57 Join markun [0] (~markun@bastards.student.utwente.nl) 09.22.05 # good morning 09.22.16 # ashridah: "Jens of Sweden" I guess 09.22.26 # a brand of flash-based players 09.22.33 # ah 09.22.41 # I'm working on vorbis2wav but I have some problems.. 09.23.29 # markun: such as? 09.23.43 # I want to use the vorbisfile interface to decode a file, but when I link the plugin to libTremor I get this: 09.23.46 # /usr/home/karl/tmp/src/rockbox/rockbox-commit/apps/codecs/Tremor/vorbisfile.c:772: undefined reference to `read' 09.25.14 # Is there a way libTremor can read the file? 09.25.59 # you need to use the plugin api 09.27.43 # check Dave's plugins for the other codecs 09.28.02 # I got some inspiration from his code. 09.30.13 Quit ashridah (Nick collision from services.) 09.30.28 Join ashridah [0] (ashridah@220-253-120-220.VIC.netspace.net.au) 09.30.40 # @#$%^@$%^@!@#$%@%^#%^&* ! damned power just flickered :/ 09.34.16 Join bobTHC [0] (~foo@l03m-38-210.d1.club-internet.fr) 09.35.20 # morning all! 09.35.27 # morning 09.38.06 Quit ashridah ("ircII EPIC4-2.0 -- Are we there yet?") 09.38.29 Join ashridah [0] (ashridah@220-253-120-220.VIC.netspace.net.au) 09.38.43 # oops. 09.42.11 Join webguest34 [0] (~c31ce021@labb.contactor.se) 09.44.38 # I tried to pass the plugin_api struct to the codec so it can user rb->open, when I include in vorbisfile.c I get these errors: 09.44.49 # firmware/export/system.h:161: error: parse error before "unsigned" 09.45.19 # The plugins which also have compile fine. 09.55.47 # i don't think the codecs will have the same plugin api as the regular plugins 09.56.22 # no, but it's a start 09.56.27 # and i also don't think they should need file access 09.59.17 # I agree, but I just wanted to do a quick test to see if decoding worked. 10.00.28 # isn't that supposed to be done by the xxx2wav.rock plugins? 10.00.54 # * LinusN hasn't been involved in the codec stuff 10.01.27 # markun is working on such a xxx2wav.rock 10.01.34 # aha 10.01.35 # xxx being vorbis 10.01.35 # yes, I'm working on vorbis2wav.rock 10.05.50 # but then only the .rock file should include plugin.h, and the file i/o should be done there 10.06.47 # and then use memory buffers to pass data to and from the codec 10.07.14 # or am i out in the blue here? 10.07.35 # no, I agree with you 10.08.14 # * Bagder tries to build a h100 sim with gcc 3.3 10.08.19 # no work 10.08.25 # cc1: error: invalid parameter `large-function-insns' 10.08.56 # not sure what the best approach to this is 10.11.36 # no sim-specific makefile defines? 10.12.00 # I guess I could do that, but this isn't sim-specific 10.12.11 # this is gcc 3.3 vs 3.4 10.12.26 # no, someone might use a 3.3 cross compiler as well 10.12.48 # I'll do some magic in configure and set a variable 10.13.01 # gcc --version 10.13.05 # yes 10.14.00 Nick QT_ is now known as QT (as@area51.users.madwifi) 10.14.15 # configure is changed a lot in my new build stuff anyway 10.15.03 Join amiconn [0] (~jens@pD9E7F6F9.dip.t-dialin.net) 10.18.24 Quit ashridah ("Reconnecting") 10.18.40 Join ashridah [0] (ashridah@220-253-120-220.VIC.netspace.net.au) 10.19.35 # i am so over these power flickers 10.22.47 # amiconn: any success with your build? 10.26.29 # yup 10.26.39 # goodie 10.26.50 # I had to use 'override' to redefine the variable within the Makefile 10.27.43 Join Quelsaruk [0] (~kvirc@80.103.134.240) 10.27.48 # morning to all 10.28.24 # morning 10.30.23 Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) 10.31.54 # HCl: there? 10.32.21 # amiconn: aha 10.34.58 # <[IDC]Dragon> 2 days ago I saw the idea of treating the playback bitswap as a "codec", I like that 10.35.11 # i don't 10.35.15 # I like that 10.35.45 # it will cause more complex code and less battery life. for what? 10.35.46 # <[IDC]Dragon> makes the bitswap indepent of the buffer handling 10.36.07 # Zagor: one playing system regardless of target 10.36.12 # <[IDC]Dragon> and opens the door to "trick modes" 10.36.31 # I don't think it'll be more complex 10.36.49 # I think it'll in fact be simpler 10.36.52 # <[IDC]Dragon> I don't think it will affect battery life 10.37.07 # <[IDC]Dragon> we have to bitswap anyway 10.37.49 # splitting the buffer means we cannot load as big part of the file in ram 10.38.05 # <[IDC]Dragon> plus, with the new approach we bitswap on demand, just what's really played 10.38.33 # <[IDC]Dragon> the swapped buffer can be very small 10.38.44 # <[IDC]Dragon> just covering for our latencies 10.38.44 # Zagor: I think that will be neglectible. Imho the hw format playback buffer should be <64 KB 10.39.07 # I think the benefits outweighs the downsides 10.39.26 # the only benefit is aesthetical, as far as i see 10.39.31 # LinusN: Regarding your concern that searching for mp3 frame headers on archos will affect battery life because of cpu usage: If done efficiently, it should be possible to search the whole buffer in less than 2 secs cpu time 10.39.46 # Zagor: There are more benefits 10.40.09 # <[IDC]Dragon> we don't have to track headers all the time, only when pausing/skipping 10.40.36 # amiconn: such as? 10.41.05 Quit MO-Pantsu (Read error: 110 (Connection timed out)) 10.41.07 # grr, there's no 'if > variable' in makefiles 10.42.02 # Bagder: use the result from /bin/[ ? 10.42.05 # <[IDC]Dragon> 1) uniform architecture 2) no swap thread 3) probably simpler code 4) trick modes feasible (FF/FR, etc.) 10.42.06 # counting frames has the obvious benefit of displaying the correct playtime 10.42.17 # assuming you can test success/fail of a command 10.42.24 # "probably simpler code"? 10.42.46 # <[IDC]Dragon> I don't consider the current mpeg code simple 10.42.49 # ashridah: yes, possibly. I'll try... 10.42.51 # "no swap thread" no, because we call it "codec thread" instaed 10.43.06 # <[IDC]Dragon> but that's negotiable ;-) 10.43.26 Quit markun () 10.43.28 # <[IDC]Dragon> currently we have mpeg and swap thread 10.43.41 # LinusN: simpler since it would be one way of playing instead of two, as we would need this system anyway for non-MAS players 10.43.49 # [IDC]Dragon: ??? Iirc the mpeg thread also handles swapping 10.43.51 # what are these "trick modes"? 10.44.01 # <[IDC]Dragon> it does? sorry then 10.44.02 # FF/FR with sound 10.44.12 # why would that be easier with unswapped data? 10.44.40 # <[IDC]Dragon> there's no mixture of swapped and unswapped in the buffer 10.44.43 # No because of being unswapped, but because of having those 2 buffers 10.44.45 # Bagder: the iriver will not have swapping 10.44.55 # no, but codecs 10.45.00 # amiconn: why is that easier? 10.45.35 # <[IDC]Dragon> currently, trick modes would need to take swapped/unswapped into account 10.45.44 # My idea was to always give whole frames to the codec on all architectures, with 'codec' on archos being the swap 10.46.05 # So this allows for easy skipping of frames 10.46.16 # at least forward 10.46.19 # <[IDC]Dragon> I don't think we need to go that far 10.46.25 # backwards is another matter 10.46.30 # <[IDC]Dragon> but it's an option 10.46.48 # * LinusN is switching between 40MHz and 140MHz on his iriver 10.46.51 # Backwards would need a bit more cpu power, because in needs to search by brute force 10.47.08 # LinusN: cool! 10.47.33 # Forward can use the calculated frame length, as long as there is no sync error 10.47.51 # vbr? 10.47.59 # <[IDC]Dragon> for FF/FR in mp3, we need to modify the frames a bit, to strip the bit reservoir 10.48.55 # Zagor: What's the problem with vbr? You read the farme header, and calculate the frame length from the bitrate & padding etc. Then you know where the next frame should start 10.48.59 # <[IDC]Dragon> the Archos guys did that, with the SH 10.49.15 # <[IDC]Dragon> for the Oskar 10.49.40 # <[IDC]Dragon> (anchestor of the the JBR) 10.49.50 # [IDC]Dragon: ??? Modify the frame? I can't imagine how this is supposed to work... 10.49.51 # there were archoses before jbr? 10.50.09 # dwihno: oskar was a project for an electronics magazine iirc 10.50.32 # an mp3 player very similar to the jb 10.50.46 # <[IDC]Dragon> insert a dummy frame which contains just the bit reservoir, iirc 10.50.47 # or rather, jb is very similar to oskar 10.50.54 # aah 10.50.55 # okay 10.51.18 # <[IDC]Dragon> LinusN: almost, it appeared in a magazin (I have that issue), but existed before 10.51.38 # <[IDC]Dragon> do you want to hear the JBR history? 10.52.32 # <[IDC]Dragon> it started as a diploma thesis of 2 students at the TU Darmstadt 10.53.05 # <[IDC]Dragon> they build a box with a CD rom drive, the SH CPU and the MAS decoder 10.53.37 # [IDC]Dragon: How? Iiuc the bit reservoir is backward refence, i.e. a frame that needs some more bits can use unused bits from the previous frame. Such a frame cannot be decoded properly without that previous frame. 10.54.21 # <[IDC]Dragon> amiconn: the idea is to insert an extra frame to resolve this 10.54.38 # <[IDC]Dragon> then you have a clean cut point 10.55.10 # You would have to insert a frame containing the reservoir bits *before* the first frame. 10.55.34 # why is this even necessary? 10.55.50 # <[IDC]Dragon> because else it sound bad 10.55.58 # "bad"? 10.56.15 # when will it sound bad? 10.56.20 # <[IDC]Dragon> clicks from stream errors 10.56.29 # dropouts, yes 10.56.33 # [IDC]Dragon: The question is: where do you get the reservoir bits from? They are unknown as long as you don't have acces to the previous frame. 10.57.05 *** Saving seen data "./dancer.seen" 10.57.10 # <[IDC]Dragon> amiconn: yes, if you want to skip, you'll have to start paing attention to the bit reservoir 10.57.55 # Yeah.. I mean, how? 10.58.04 # Iirc mp3 is huffman coded... 10.58.29 # <[IDC]Dragon> I forgot the details, but the bit reservoir info is right after the header 10.59.03 # Plus, I don't think the audio glitches would decrease significantly with the bit reservoir correction. The stream ends don't match anyway 10.59.19 # <[IDC]Dragon> why not? 10.59.47 # <[IDC]Dragon> they used it even to accelerate/decelerate playback 10.59.55 # You play a chunk to the end, skip some frames, and start a new chunk. How are these 2 chunks supposed to match? 11.00.19 # <[IDC]Dragon> you make a new "seam" 11.00.24 # amiconn: the point is to make sure that the decoded frames are complete 11.00.38 # else the mas inserts silence for the duration of the frame 11.00.51 # <[IDC]Dragon> Archos used this even to modify playback speed 11.01.12 # <[IDC]Dragon> like, drop/duplicate every n frames 11.01.22 # LinusN: Yes, but the most would be that the first frame of the new chunk is silenced. Something I wouldn't really care... 11.01.39 # amiconn: for voice playback, you do 11.01.57 # <[IDC]Dragon> away now 11.02.25 # Nope. I don't mean to throw away the synchronisation to frame boundaries. 11.02.47 # Otherwise the mas needs to resync, which takes several frames 11.03.13 # I only mean to not care about the bit reservoir 11.03.34 # i know 11.04.24 # The current voice ui implementationdoes exactly that. 11.05.26 # NEWGCC=$(shell expr $(GCCNUM) ">" 303) 11.05.39 # then I can make a ifeq on that 11.05.50 # seems to work 11.07.55 Join ripnetuk [0] (~george@82-70-100-230.dsl.in-addr.zen.co.uk) 11.08.17 # new sim build patch uploaded 11.08.19 # <[IDC]Dragon> amiconn: and that's why we need to insert the silence clip, right? 11.11.13 # No, it isn't. We have to *append* the silence clip, because the mas obviously doesn't play a stream to its very end. 11.11.36 # When we switch clips (via shutup()), we do not insert it. 11.12.20 # <[IDC]Dragon> yes, ok 11.13.05 # <[IDC]Dragon> mabe one day I'll make a little test command line app to massage an mp3 stream 11.13.16 # <[IDC]Dragon> to test ff/fr 11.13.47 Join R3nTiL_ [0] (~zorroz@83.69.98.220) 11.13.47 # <[IDC]Dragon> with bit reservoir resolving 11.14.21 # The frame search would benefit from a fast memchr() (and something like memrchr() ) 11.14.36 # Shouldn't be hard with a little SH asm... 11.14.40 # <[IDC]Dragon> memrchr(), haha 11.15.02 # For the backwards search... 11.15.19 # <[IDC]Dragon> I thought you did memchr already, or was that strlen? 11.15.39 # I did strlen, but memchr() would be similar 11.16.01 # We don't use memchr() currently 11.16.14 # <[IDC]Dragon> ok 11.17.24 # <[IDC]Dragon> yesterday I've tries rockboy a bit 11.17.32 # <[IDC]Dragon> tried 11.17.52 # <[IDC]Dragon> cool, but sadly somehow hopeless 11.18.03 # ? 11.18.06 # <[IDC]Dragon> on the SH and the 112*64 11.18.21 # :) 11.18.34 # H 11.18.36 # ah 11.18.37 Quit Cassandra_ (Read error: 110 (Connection timed out)) 11.18.49 # <[IDC]Dragon> we'd need the pseudo-grayscale if we want to have chance to recognize anything 11.19.13 # hoh 11.19.15 # heh 11.19.15 Join Cassandra_ [0] (~christi@213.78.163.225) 11.19.17 # forget it 11.19.23 # and why? cause of the scaling? 11.19.26 # <[IDC]Dragon> like antialiasing compensating for a lack of resolution 11.19.55 # Now _that_ would be a slowdown... 11.20.05 # <[IDC]Dragon> sure 11.20.51 # <[IDC]Dragon> does a gameboy have a ROM, OS, or such? 11.20.51 Quit webguest34 ("CGI:IRC (EOF)") 11.20.52 # Perhaps we could halve the update frequency to 33 Hz when using only few grayscales 11.21.40 # <[IDC]Dragon> if yes, that could be mapped to native SH code 11.21.43 Join cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 11.22.02 # [IDC]Dragon: HCl is thinking about a dynarec implementation... 11.22.26 # <[IDC]Dragon> abybody remembering the N64 emu with it's high level emulation? 11.22.26 Join Sando [0] (kekekek@CPE-147-10-21-132.vic.bigpond.net.au) 11.22.35 # <[IDC]Dragon> what's dynarec? 11.22.43 # dynamic recompilation 11.22.58 # <[IDC]Dragon> sounds good 11.23.00 # [IDC]Dragon: ultrahle? 11.23.12 # I think it was the first 11.23.12 # <[IDC]Dragon> yes, that's the one 11.23.12 # if it can cache the recompiled stuff, that'd be awesome 11.23.47 # ashridah: Iiuc thats the point of dynarec. Without it, it wouldn't make sense... 11.23.59 # <[IDC]Dragon> and we need the wav codec, sigh 11.24.19 # <[IDC]Dragon> no progress yet 11.24.29 Quit Quelsaruk ("rebooting") 11.25.11 # I already had a look at the pattern update function. That's one of the parts available in asm for i386 11.25.33 # <[IDC]Dragon> pattern update? 11.25.41 # <[IDC]Dragon> is that the screen update? 11.25.50 # The C implementation is a real cpu sucker; 3 nested loops across a 4096x8x8 byte array... 11.25.54 # <[IDC]Dragon> or sprites? 11.26.20 # lcd.c: updatepatpix() 11.27.31 # no 11.27.33 # not ultrahle 11.27.39 # ultrahle is an entirely different concept 11.27.44 # than dynarec 11.27.44 # i thought hle was not dynarec - 11.28.03 # hle == catching api calls to nintendos library and re-implementing them (like wine) 11.28.12 # hle = recognising native library functions used to compile games and mapping them onto native library functions 11.28.48 # * HCl resumes sleeping, keeps getting nightmares u.u 11.28.51 Join Quelsaruk [0] (~kvirc@80.103.134.240) 11.28.55 # back 11.29.08 # i think it worked because nintendo had a standard dev library which almost all games linked into 11.29.26 # [IDC]Dragon: updatepatpix() should be easily made flying with SH1 asm... 11.29.45 # <[IDC]Dragon> is there a gameboy builtin library? 11.36.44 # lunch 11.36.59 # <[IDC]Dragon> what about an offline dynarec, convering the gamebay roms to something native? 11.37.10 # <[IDC]Dragon> converting 11.37.28 # * [IDC]Dragon is aware of his wild ideas 11.37.56 # <[IDC]Dragon> and wild spelling ;) 11.38.23 # That's a great idea! 11.38.43 # like rvf? a rgr? 11.39.43 # If it wasn't you who said it, I would say that person was bonkers :) 11.40.58 # [IDC]Dragon: Dynarec (or offline recompilation) will only speed up cpu emulation. Other parts need more speed too, as e.g. the mentioned updatepatpix() 11.41.27 # <[IDC]Dragon> I know, but the CPU emu doesn't come for free, too 11.41.49 # <[IDC]Dragon> I've seen that switch-case from hell 11.42.00 Join |Quelsar| [0] (~kvirc@80.103.134.240) 11.42.07 Quit Quelsaruk (Read error: 104 (Connection reset by peer)) 11.44.02 Quit R3nTiL_ () 11.44.12 Nick |Quelsar| is now known as quelsaruk (~kvirc@80.103.134.240) 11.48.47 # a switch for every instruction? 11.48.51 # (a case) 11.50.03 # re 11.50.05 # don't compilers attempt to reduce that to a simple indexed lookup table these days? 11.57.30 # <[IDC]Dragon> they try to make a jump table, yes 11.57.52 # <[IDC]Dragon> if the values are not too sparse 11.58.15 # easy on simple enums, but not when the case values are very large and very different 11.58.26 # like for opcides 11.58.29 # opcode 11.58.39 # <[IDC]Dragon> the opcode is 8 bit 11.58.47 # <[IDC]Dragon> so it could work out 11.59.53 # hmmm 12.01.01 # <[IDC]Dragon> it could even multiply the opcode with the worst-case op handler size, and do a staight jump 12.01.14 # <[IDC]Dragon> saving the table lookup 12.04.07 # mpa2wav.rock runs at 40% realtime in 140MHz :-( 12.04.28 # :-( I was expecting something like that. 12.04.43 # and crashes after a while 12.04.48 # What about FLAC? 12.05.01 # i have no flac files to try 12.05.23 # madplay -o wav:file.wav file.mp3 ; flac file.wav 12.05.53 # no madplay or flac here 12.06.29 # alt.binaries.mp3.lossless??? 12.07.21 # LinusN: is disk writing CPU intensive? 12.07.29 #