--- Log for 01.11.105 Server: kornbluth.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 3 days and 22 hours ago 00.00.25 Quit Kohlriba ("Leaving") 00.01.00 # amiconn: the unicode patch is very nice... it would be great if that was merged into CVS one day. 00.02.27 # linuxstb: i can't even find where to control the bitrate in this thing 00.03.09 # elinenbe: Be patient... first TiMiD has to finish his remote work 00.03.33 # preglow: I guess you've installed iTunes? 00.04.26 # linuxstb: aye 00.04.27 Quit Maxime (Read error: 104 (Connection reset by peer)) 00.04.54 Join Maxime [0] (n=flemmard@fbx.flemmard.net) 00.06.40 # I don't know about the Windows version, but on the Mac, it's the application menu, then preferences, then advanced, then importing. 00.07.18 # amiconn: about the code size decrease, I'm becoming skeptical :) (well once the work finished, we will return around the initial level, but not as big as I expected : the menu's new implementation reduced it by 300bytes ... very poor ) 00.07.22 # <_FireFly_> it seams that f2_screen, f3_screen and handle_usb in wps.h are not used can they be removed ?? 00.07.26 # linuxstb: yeah, i found it 00.07.31 # linuxstb: didn't notice the tabs 00.07.35 Quit matsl (Remote closed the connection) 00.08.06 # linuxstb: is vbr aac normal? 00.08.44 # I don't think iTunes does VBR. But Nero does. 00.09.25 # Just noticed the VBR checkbox - I guess it does it now. 00.11.19 # hrmph, MUL_R is used not only for sbr 00.11.29 # but most extensively in sbr, it seems 00.15.48 # * preglow cuddles MUL_F 00.15.57 # i love it when the fixed point formats line up with what the emac unit uses 00.17.38 # Is that good news then? 00.18.17 # indeed 00.18.28 # let's hope for some long accumulator chains 00.18.35 # although i'm pretty certain they aren't there 00.18.51 # aac doesn't use any good old-fashioned fir filtering 00.18.55 # that i know of, at least 00.19.53 # bad news is that the REAL_PRECISION is used in a couple of places 00.20.00 # we might need to do a proper 64 bit multiply for that 00.21.28 # In case you're wondering, my choice of what is in IRAM is pretty random. So feel free to change it if you think it can be better used elsewhere. 00.21.34 # The full 64*64->64 ? 00.23.04 # amiconn: no, musepack style 00.23.37 # but ok, i'm doing a couple of tests right now 00.23.38 # That's not too bad. Variable shift as well? 00.24.37 # amiconn: nope, fixed shift 00.24.51 # amiconn: but the majority of all muls will be emac 00.25.04 # does anyone know if the "cc" clobber flag is really necessary? 00.25.37 # I'm not 100% sure, but I never used it and didn't run into problems 00.30.04 # * preglow spots a two-space indent level and looks at the culprit :P 00.30.47 # <_FireFly_> it seams that the functions f2_screen, f3_screen, refresh_wps and handle_usb in wps.h are not used can they be removed ?? 00.31.59 # _FireFly_: yes 00.32.05 # <_FireFly_> k 00.32.22 # <_FireFly_> i'm trying to make a wps-widget :) 00.34.52 # preglow: Fixed in CVS. I'm trying to comply... 00.34.59 # goodie 00.35.43 # i used to to two-level indenting myself when i used pascal 00.35.51 # which is quite luckily very long ago 00.36.25 # Maybe that's where I picked up the habit from - I used pascal for a long time. 00.36.56 Join len0x_ [0] (n=len0x@mobileweb08.london.02.net) 00.37.13 # _FireFly_: a widget that does what? 00.37.59 Quit Maxime (Read error: 104 (Connection reset by peer)) 00.38.18 Quit _DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 00.38.19 Join Maxime [0] (n=flemmard@fbx.flemmard.net) 00.38.26 # <_FireFly_> draws the wps :) 00.38.31 # replacing the math function alone isn't going to save aac, it seems 00.38.44 # argh!!!! ice! 00.39.37 # what's taking the most time in AAC decoding? iDCT? 00.39.46 # i have no idea 00.39.48 # <_FireFly_> elinenbe: i try to adapt the current wps code to the new multi-screen support 00.40.13 # len0x_: not all words starting with an 'i' has to have a lowercase i, you know, it's called an IMDCT ;) 00.40.48 # :) 00.42.03 # back in the days it was just iDTC :) 00.42.15 # iDCT :) 00.42.23 Join RotAtoR [0] (n=e@12-210-82-91.client.insightBB.com) 00.42.45 # anyway - does it use asm ? 00.42.54 # len0x_: nope 00.43.06 # len0x_: everything but trivial multiply functions are c 00.43.21 Mode "#rockbox +o LinusN " by ChanServ (ChanServ@services.) 00.43.34 Kick (#rockbox len0x :LinusN) by LinusN!n=linus@labb.contactor.se 00.44.11 Mode "#rockbox -o LinusN " by LinusN (n=linus@labb.contactor.se) 00.46.03 Quit len0x_ ("Trillian (http://www.ceruleanstudios.com") 00.47.39 Join len0x [0] (n=len0x@mobileweb08.london.02.net) 00.48.22 # what the hell is it about libfaad that keeps provoking these ICEs 00.49.21 # Did the version in CVS compile for you? 00.50.05 # yes 00.50.11 # it worked just fine with a replaced MUL_F 00.50.20 # i've now replaced MUL_C, and it ICEs in tns.c 00.50.48 # trying to replace functions with macros 00.51.03 # nope, same error 00.51.49 # One of the problems I had was the faad_getbits() function. It was originally inline, but that caused ICEs. So I had to make it a normal function. 00.52.15 # Maybe it's worth trying gcc4 00.52.26 # perhaps 00.53.06 # linuxstb: but now i made the mul functions macros, and it still didn't help. making them ordinary functions are out of the question 00.53.41 Join einhirn [0] (i=Miranda@szgt-d9b8e957.pool.mediaWays.net) 00.53.47 # is tns.c necessary for lc operation? 00.54.16 # I have no idea. 00.55.09 # i'm using gcc 3.4.1, however, could you test out the file with your gcc if it's newer? 00.55.39 # Sure. But I'm not confident it will be any better. 00.55.47 # I'm using 3.4.4 00.55.50 Part len0x 00.56.30 # www.pvv.org/~thomj/rockbox/fixed.h 00.57.46 Quit tvelocity ("Leaving") 00.59.05 # ICE :( 00.59.23 # arghhhh 00.59.24 # tns.c:257 00.59.28 # yes 00.59.57 # we've got heaps of codecs with no ICEs, and now suddenly, tons of them in one codec 01.02.50 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 01.05.20 # I already got memcpy() 3.5x..4x as fast as the C version for most alignment combos. That's still without using burst mode... :-) 01.06.12 # hahaha 01.08.00 # Seems promising :) 01.08.54 # Otoh, this might become a pretty large beast 01.09.19 # about how large? 01.10.16 # 242 bytes already. Using burst mode optimised for various alignments might easily quadruple this. 01.10.25 # memmove will double the size again 01.11.01 # well, as long as the speedup is goog enough 01.11.06 # good, even 01.11.22 # but it might be a tad too large for putting in iram 01.19.59 Quit _FireFly_ (Read error: 110 (Connection timed out)) 01.21.04 *** Saving seen data "./dancer.seen" 01.28.29 # still not realtime, hrmph 01.34.48 # Did you solve the ICE problem? 01.35.26 Nick paugh is now known as AliasCoffee (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) 01.37.55 # no 01.38.05 # i'm just ignoring that particular mul function for now 01.38.20 # LinusN: Is there a reason why you didn't enable SDRAM page mode in the bootloader? 01.40.53 # amiconn: instead of burst-only page mode? 01.41.04 # yes 01.41.50 Join ashridah [0] (i=ashridah@220-253-123-180.VIC.netspace.net.au) 01.43.49 # Afaiu, this isn't really 'instead of'. If PM isn't set, the coldfire uses page mode for bursts only. If it's set, the coldfire uses page mode for both burst and normal accesses 01.44.42 # (when appropriate) 01.45.08 # amiconn: iirc, i interpreted it as "instead of" for some reason, but now that i look at it, i seem to have been wrong 01.45.12 # The benefits might be small, because the coldfire doesn't have warp mode & ras down 01.45.27 # and the pipeline is rather lame 01.45.52 # still, i don't see a penalty 01.46.09 # how is the pipeline lame? 01.46.10 # but there has to be one, otherwise it wouldn't have been an option 01.49.19 # MCF5249UM.pdf, section 7.3.3.4: "The use of continuous page mode is recommended because it can provide a slight performance increase." 01.50.33 Quit linuxstb ("CGI:IRC") 01.50.35 # preglow: it's short, and doesn't group data access and instruction fetches very well, so it makes bad use of the burst controller 01.51.11 # admittedly, it's not all about the pipeline, it's more about the memory controller 01.51.23 # exactly how short is it? i've tried to find some info about the pipeline, but i've failed miserably 01.54.13 Join Mxm`Pas`Bien [0] (n=flemmard@fbx.flemmard.net) 01.54.13 Quit Maxime (Read error: 104 (Connection reset by peer)) 01.55.05 Nick linuxstb_ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net) 01.56.13 Quit Moos ("Glory to Rockbox") 01.56.31 Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) 01.59.02 # Wow... memory accesses on coldfire are pathetic. I did some calculations based on my memcpy() timing 01.59.26 # we know that... 01.59.46 # A loop that would take 5 cpu clocks per pass according to the instruction timing, but copies one long from dram to dram takes 43 clocks (!!) 02.00.20 # tried enabling page mode to see if it gets better? 02.00.51 # Page mode wouldn't help in this case. Source & destination are in different pages 02.01.33 # are you sure the memory timing is as tight as it can be? 02.02.06 Quit Moos ("Glory to Rockbox") 02.02.18 Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) 02.02.28 # yes it is 02.03.55 # oh well 02.07.59 # unfortunately, the sdram controller clock is always 1/2 the cpu clock 02.08.07 # even at 11mhz 02.08.22 # a major suckfactor 02.08.49 # man, aac is pretty memory heavy 02.08.49 # :/ 02.18.02 # we could have half a meg of iram for this and still not have enough 02.20.18 # gotta sleep, nite all 02.20.35 Part LinusN 02.22.26 # no matter what i stuff into iram, it's still dog slow 02.31.12 Quit Slasher (kornbluth.freenode.net irc.freenode.net) 02.31.12 NSplit kornbluth.freenode.net irc.freenode.net 02.39.06 Quit Moos ("Glory to Rockbox") 02.39.33 # bed 02.39.53 Join Naked [0] (i=naked@naked.iki.fi) 02.43.33 NHeal kornbluth.freenode.net irc.freenode.net 02.43.33 NJoin Slasher [0] (i=miipekk@ihme.org) 02.46.45 Quit AliasCoffee ("Leaving") 02.50.32 Quit Hadaka (Read error: 111 (Connection refused)) 02.51.11 Nick Naked is now known as Hadaka (i=naked@naked.iki.fi) 03.11.53 Quit cYmen ("zZz") 03.21.08 *** Saving seen data "./dancer.seen" 03.28.58 Quit Mxm`Pas`Bien (Read error: 104 (Connection reset by peer)) 03.29.26 Join bagawk [0] (n=lee@unaffiliated/bagawk) 03.32.48 Join Maxime [0] (n=flemmard@fbx.flemmard.net) 03.51.14 Join Mxm`Pas`Bien [0] (n=flemmard@fbx.flemmard.net) 03.51.14 Quit Maxime (Read error: 104 (Connection reset by peer)) 03.55.22 Join Lost-ash [0] (i=ashridah@220-253-120-150.VIC.netspace.net.au) 03.55.24 Quit ashridah (Nick collision from services.) 03.55.43 Nick Lost-ash is now known as ashridah (i=ashridah@220-253-120-150.VIC.netspace.net.au) 04.38.06 Join Paul_The_Nerd [0] (n=paulthen@cpe-66-68-93-2.austin.res.rr.com) 05.01.13 # Bagder, good day :-) 05.21.13 *** Saving seen data "./dancer.seen" 05.41.46 Join Maxime [0] (n=flemmard@fbx.flemmard.net) 05.41.46 Quit Mxm`Pas`Bien (Read error: 104 (Connection reset by peer)) 05.48.04 Quit Paul_The_Nerd ("Chatzilla 0.9.68a [Firefox 1.0.7/20050915]") 06.19.22 Join Serotta_b [0] (n=johhny@c-67-161-105-190.hsd1.wa.comcast.net) 06.19.22 Quit Maxime (Read error: 104 (Connection reset by peer)) 06.19.30 Join Maxime [0] (n=flemmard@fbx.flemmard.net) 06.20.34 Part Serotta_b 06.39.33 Quit bagawk (""umount /dev/brain"") 06.40.09 Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 06.49.31 Quit RotAtoR () 07.21.17 *** Saving seen data "./dancer.seen" 07.35.48 Join Mxm`Pas`Bien [0] (n=flemmard@fbx.flemmard.net) 07.35.54 Quit Maxime (Read error: 104 (Connection reset by peer)) 07.36.56 Nick Mxm`Pas`Bien is now known as Maxime (n=flemmard@fbx.flemmard.net) 07.57.27 Quit matsl (Remote closed the connection) 08.05.55 Quit lostlogic ("Going to the moon") 08.16.39 Join solexx_ [0] (n=jrschulz@c203186.adsl.hansenet.de) 08.28.09 Quit solexx (Connection timed out) 08.33.50 Join webguest82 [0] (n=3a4d5064@labb.contactor.se) 08.34.08 # hello 08.34.50 # There is that wonder of some piece. Do you have person who reply? 08.35.44 # Can you find out iRiver H300's firmware source? 08.35.49 # Do you have person who answer? 08.36.47 # the source code to the iriver firmware? we won't ever get that 08.37.39 # Too .. 08.38.15 # Is not it hard to manufacture one after another? 08.38.34 # we can disassemble it. 08.38.48 # someone probably already has to a degree. 08.39.14 # the only thing impeeding H300 development at the moment is really manpower 08.39.31 # the people who have the tools who can work on it are very busy with work atm. 08.40.10 # What work is ashridah doing? 08.40.55 # not much. i pretty much test rockbox against my H140 whenever i get time 08.41.28 # Are there much that know about H300? 08.41.43 Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) 08.42.24 # most of the problems facing rockbox on H300 involve tracing the hardware and working with the unit with a BDM 08.42.43 # hehe 08.42.44 # as i say, the rockbox developer with the tools to do that is currently busy. 08.42.47 # you sound like an alien webguest82 08.43.53 # thegeek: So. 08.44.21 # thegeek: i'm guessing he's using a translator like babelfish. wasn't there someone else who found a better one? 08.44.29 # I am H300 user who live in South Korea. 08.45.06 # Used babelfish before, but unuse now. 08.45.19 # Babelfish is miserable. 08.45.25 # indeed 08.45.35 # it doesn't seem to have improved too much 08.46.00 # Speech which do now may understand. 08.46.17 # Is using program of HaanGuide. 08.47.19 # Where does ashridah live? 08.47.25 # anyway, as i was saying, the main obstacle with H300 and rockbox is free time for the developers who are working on it. 08.47.31 # I'm in Australia. 08.48.24 # :) 08.48.34 # Live in the good country. 08.48.56 # The South Korea is complicated and dizzy. 08.48.57 # ashridah : yeah, I guessed that 08.49.10 # actually webguest82 08.49.14 # it was not that bad 08.49.24 # I've seen much worse results from babelfish 08.49.38 # it was just wierd enough to sound like an alien;) 08.50.11 # Where does thegeek live? 08.50.56 # Norway:) 08.51.01 # way up north 08.51.02 # Does not the South Korea have a person who work in RockBox? 08.51.20 # Norway is the great country. 08.51.21 # I dont think so 08.51.26 # yep, it's nice:) 08.51.46 # OTL 08.52.28 # Do you know meaning of 'OTL'? 08.52.47 # not really;) 08.53.25 # Do not I know? 08.53.37 # Do not you know? 08.53.49 # (was mistake) 08.54.24 # I do not know what it means;) 08.54.28 # 'OTL' is Emoticon that express image that a person is miscarrying. 08.54.49 # ah, I see, it means you dont understand ? 08.54.52 # Various Emoticons are used in the South Korea. 08.54.58 # ;) 08.55.35 # The South Korea is that is the bad country. 08.55.54 # bad country? 08.55.57 # you dont like it there? 08.56.08 # How does the South Korea think about the country? 08.57.08 # otl ;) 08.58.37 # 'OTL' is that express that a person miscarries. 08.59.20 # OTL 08.59.20 # O - Head 08.59.20 # T - Trunk 08.59.20 DBUG Enqueued KICK webguest82 08.59.20 # L - Leg 09.00.16 # Even if the South Korea may go first in technology, the other is bad seldom. 09.01.11 Quit goa ("Client suicide") 09.02.03 # By the way, what is BDM Iraneunge? 09.03.48 # Oh sorry 09.03.49 # What is 'BDM'? 09.04.49 Quit webguest82 ("CGI:IRC (EOF)") 09.05.12 Join webguest82 [0] (n=3a4d5064@labb.contactor.se) 09.05.21 # Returned. 09.05.41 # webguest82: 'BDM' is a special debugging interface for embedded hardware 09.06.12 # many embedded processors such as the motorola coldfire in the iriver devices have special debugging interfaces, the BDM hooks into those (amoungst other things) 09.06.15 Join goa [0] (i=hd@gate-hannes-tdsl.imos.net) 09.06.19 # Then, is work about H300 childhood yet? 09.09.18 # i'm not sure i understood that question, say it another way? 09.11.09 # I am sorry. 09.11.13 # Is work about H300 startup yet? 09.12.45 # it's started 09.12.48 # it's just not progressing very fast 09.13.24 # Is ashridah busy? 09.14.18 # i'm not a developer, i just test on the H140 09.14.27 # but atm i've got exams 09.15.10 # I want to do small work. 09.17.04 # Can I do if do well C language? 09.17.56 # most of rockbox is in C, and development can be done without extensive hardware specific knowledge. You may be better off asking questions on the mailing list tho. I'm not a rockbox developer as such, just an occasional tester 09.18.30 # ha ha 09.20.41 # Seem to be many as know still. 09.21.19 *** Saving seen data "./dancer.seen" 09.22.57 Quit webguest82 ("CGI:IRC (EOF)") 09.23.00 Join webguest82 [0] (n=3a4d5064@labb.contactor.se) 09.23.34 # Site structure of rock box is difficult. 09.25.49 # it contains a lot of technical information, it might be difficult to read when translated, yeah 09.26.04 # unfortunately, it's unlikely that there's much that can be done, i don't believe we really have any developers who speak korean 09.26.41 # Is no there a person to do Korean? 09.27.22 Join ender` [0] (i=ychat@84.52.165.220) 09.28.36 # May I how about if I do such work? :) 09.29.57 # it's possible. I don't know how much support rockbox's interface code has for korean. You'd definently need to join the mailing list and discuss it, but that might be difficult. the main problem i have is that i'm not a rockbox developer, i can't really say what needs to be done 09.35.07 # there's a unicode patch pending that should enable korean and most other languages too 09.36.02 # English learns. 09.36.06 # Of course someone would need to create the korean translation 09.38.07 # English - > Hangul translation possible. 09.41.35 # It does not well that speak in English, but it does well that translate from English into Hangul. 09.47.03 # Thank that give help variously today. 09.49.00 Quit XavierGr (Read error: 110 (Connection timed out)) 09.49.10 # bye~ 09.49.26 Quit webguest82 ("CGI:IRC (EOF)") 09.57.04 # amiconn: I have a korean translation here. 09.57.47 # and a japansese one 10.03.30 # and I have a cup of coffee! 10.03.36 # :-P 10.08.42 # B4gder: Which version of gcc does the server use to generate the H1x0 simulator auto builds? 10.09.04 # gcc (GCC) 4.0.2 (Debian 4.0.2-2) 10.09.14 Quit ender` (Read error: 104 (Connection reset by peer)) 10.09.32 Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) 10.09.45 # That explains the current warnings then. I'm not getting them with 3.3.5 10.10.08 # actually when I think about it, the configure outputs the gcc version 10.10.24 # but yes, gcc4 is a lot more picky 10.10.27 # That's true. Very useful. 10.12.21 # then the gcc4 builds even inhibits some warnings 10.12.29 # using -Wno-pointer-sign 10.14.59 # I don't want to commit a patch without testing it, and I don't have gcc4. But I guess it's about time I upgraded (I'm on Debian). 10.15.32 # it seems to work rather well 10.15.36 # linuxstb: the gcc 4 transition's going to start merging into testing soon 10.15.56 # I use gcc4 quite a lot 10.16.04 # I'm running unstable - so I'm guessing I can just do "apt-get install gcc-4.0" 10.16.12 # yeps 10.16.17 # linuxstb: it should already be the default compiler 10.16.35 # It isn't for me. But I don't run "upgrade" very often. 10.16.39 # if you've been dist-upgrading, the compiler itself will be all you're missing, almost everything will have been compiled for it 10.17.01 # I generally just upgrade packages when I need to. 10.17.49 # gcc4, x.org, openoffice2 tiny little updates... :-) 10.20.39 Join _FireFly_ [0] (n=FireFly@p54A45739.dip.t-dialin.net) 10.22.32 # I've just installed gcc-4.0, and nothing else was upgraded. So I guess I was already most of the way there. 10.23.02 # rerun configure then before you build the sim, or you'll get a bazillion extra bonus warnings 10.23.29 # Mmm. /usr/bin/gcc is still a symbolic link to gcc-3.3. Is there a "correct" way to change that? 10.24.14 # <_FireFly_> distri ?? 10.24.58 # distri ? 10.25.03 # mine is a link to gcc-4.0 10.25.10 # but I don't know exactly what made it so 10.25.33 # <_FireFly_> which distribution(debian, fc3, gentoo, ...) do you use 10.25.49 # _FireFly_: Debian unstable. 10.26.45 # Oh well, just changed the link manually. I'll soon find out if that breaks anything. 10.28.54 # linuxstb: the 'gcc' package should deal with that 10.29.26 # if you'd just installed gcc-4.0 or something, it wouldn't set the default 10.30.09 # $ dpkg -S /usr/bin/gcc 10.30.10 # gcc: /usr/bin/gcc 10.31.40 # ashridah: Thanks. I just did an "apt-get install gcc" and that updated the symbolic link. 10.32.21 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 10.32.21 # * ashridah nods 10.52.32 # OK, we should have a nice clean build table again now. 10.58.45 Join muesli_- [0] (i=muesli_t@Bc148.b.pppool.de) 10.58.53 # hi 11.17.34 # gcc 4 is already default in debian testing 11.17.37 # (4.0.2) 11.18.21 Join tvelocity [0] (n=tony@ipa105.5.tellas.gr) 11.21.21 *** Saving seen data "./dancer.seen" 11.31.46 # amiconn: interesting, didn't think they'd started the c++ abi push yet. 11.49.55 Quit muesli_- (Read error: 110 (Connection timed out)) 12.06.17 Quit DangerousDan (Read error: 104 (Connection reset by peer)) 12.11.24 Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) 12.22.41 Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 12.27.53 Join cYmen_ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 12.31.46 Join muesli_- [0] (i=muesli_t@Bc124.b.pppool.de) 12.32.27 Nick solexx_ is now known as solexx (n=jrschulz@c203186.adsl.hansenet.de) 12.33.06 Join cYmen__ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 12.35.21 Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-130-062.pools.arcor-ip.net) 12.38.15 Join cYmen___ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 12.38.15 *** Alert Mode level 1 12.38.15 DBUG Enqueued KICK cYmen 12.38.15 DBUG Enqueued KICK cYmen_ 12.38.15 *** Alert Mode level 2 12.38.15 DBUG Enqueued KICK cYmen__ 12.38.15 DBUG Enqueued KICK cYmen___ 12.38.15 *** Alert Mode level 3 12.40.03 Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) 12.40.18 # Hello guys 12.40.21 Quit cYmen (Connection timed out) 12.43.18 Quit Moos (Read error: 104 (Connection reset by peer)) 12.43.27 Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) 12.43.34 Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 12.43.34 *** Alert Mode level 4 12.43.34 *** Alert Mode level 5 12.43.34 DBUG Enqueued KICK cYmen 12.43.34 *** Alert Mode level 6 12.43.34 *** Alert Mode level 7 12.43.34 *** Alert Mode level 8 12.44.13 # Slasher: Hi, are you around? I encountered one odd playback bug :( 12.45.36 Quit cYmen_ (Connection timed out) 12.45.44 # when playing one song, and wait for filling bufering 12.46.36 # when it's done, and I skip back for replay song before his end, the player freeze in spining down 12.46.51 # easy to reproduce 12.47.03 # anyone here can reproduce it? 12.47.47 # Moos: Hmm, i will try that 12.48.19 # Hi: since your last playback change this week end 12.48.59 # good, i can reproduce it 12.48.59 Quit Moos (Read error: 104 (Connection reset by peer)) 12.49.00 Join DrMoos [0] (i=DrMoos@m79.net81-66-158.noos.fr) 12.49.24 Nick DrMoos is now known as Moos (i=DrMoos@m79.net81-66-158.noos.fr) 12.49.24 # DrMoos: i was able to reproduce it - fix coming soon 12.49.36 # oki thanks 12.50.41 # (ah, one detail, when song is Paused, and you start another, if crossfade enabled, you have the 'end' of the song before starting the other.. starting the other without finishing the paused song will be great, no?) 12.50.46 Quit cYmen__ (Success) 12.51.10 # Maxime: Hmm, i can fix that too 12.51.29 # because it's "surprizing" the fadeout of the other song .. 12.52.02 # true 12.52.09 # ^^ 12.52.25 # and I always have a bug 12.52.44 # I have to start player, play, stop, shutdown, power on again and play again to have sound.. 12.53.03 # the first start, i have no sound 12.53.06 # and the player "lags" 12.53.19 # to shutdown, it reacts 20-30s after the button press 12.53.35 *** Alert Mode OFF 12.54.10 # Hmm, that's weird :/ 12.54.13 # it(s strange, it seems i'm the only with this problem 12.54.35 # and sometimes the player hangs, i'm forced to reset it 12.54.39 # It's probably hardware related 12.54.50 # i've tried deleting the whole rockbox folder, resetting config and so on 12.54.54 # but nothing changes 12.55.02 # and the original firmware haven't this issue 12.56.02 # but it's a very annoying issue 12.56.57 Quit cYmen___ (Connection timed out) 12.57.23 # unfortunately it's hard for us to fix it because no any developer has encountered it 12.57.34 # yeah.. 12.57.36 # i know 12.57.51 # but I have no idea of how to "isolate" this issue.. 12.58.37 # I you want to try, you could try to change some hardware initialization code from the rockbox source. (Something audio and i2c related for example) 12.58.53 # but what(s strange 12.58.59 # is that it's one time on two 12.59.06 # 1. no sound, 2. sound 12.59.32 # i'll try one thing 12.59.50 # btw, if you use rolo to reload rockbox, do you get sound then=? 12.59.56 # hm 12.59.57 # i'll try 12.59.58 # Or do you have to power it completely off? 13.00.00 # good 13.01.12 # hum 13.01.52 # i dont understand 13.01.59 # it's when the player is a long time powered off 13.02.16 # but .. can't explain this .. 13.02.23 # coz no RTC or else.. 13.02.27 # eating time, bbl 13.06.19 Join muesli- [0] (i=muesli_t@c-180-36-74.h.dial.de.ignite.net) 13.09.12 Join amiconn_ [0] (n=jens@p54BD7D7A.dip.t-dialin.net) 13.14.08 Quit muesli_- (Read error: 104 (Connection reset by peer)) 13.16.27 # see, the player was powered off when I was eating, and now, no sound 13.16.58 Join LinusN [0] (n=linus@labb.contactor.se) 13.17.03 # when No sound, when I restart rockbox using RoLo, don't have sound 13.17.09 # Slasher? 13.17.13 # Maxime: which bootloader version do you have? 13.17.24 # 2 i think 13.17.31 # that's your problem 13.17.34 # ah.. 13.17.39 # It's a known problem? 13.17.48 # yes 13.17.57 # when player was powered of a few minutes, no sound, the restart, sound again 13.17.58 # ok 13.18.09 # however, it should be fixable in rockbox as well 13.18.11 # Just out of interest, what was the fix? 13.18.33 Quit muesli- (Read error: 104 (Connection reset by peer)) 13.18.47 # the uda1380 isn't properly reset, so it doesn't reply to i2c commands 13.19.21 # so i'm going to upgrade bootloader then.. 13.19.33 # worth a try 13.19.38 # yup 13.19.55 # because this was very annoying lol 13.20.03 # why is the uda init in the bootloader at all? 13.20.18 # wouldn't it be better if it touched as little as possible? 13.20.18 # http://forums.rockbox.org/index.php?topic=1383.0 13.20.34 # preglow: yes, rockbox should reset it as well 13.21.01 # the bootloader resets it to get rid of an annoying "hum" during boot 13.21.07 # ahh 13.21.25 *** Saving seen data "./dancer.seen" 13.21.37 # and each reset produces a slight "pop", so resetting it twice might be annoying too 13.22.06 # Hmm, i wonder if we could prevent those reset pops too 13.22.08 # <_FireFly_> would be a mute before resetting help 13.22.36 # we can't mute before reset, since it doesn't respond to i2c commands before reset 13.22.46 # <_FireFly_> ok 13.22.49 # preglow: Any progress with AAC? 13.23.23 # none at all 13.23.42 # i'd absolutely love to run some memory access analyzer on this beast 13.23.55 # replacing the fixed point functions with emac equivalents didn't help much 13.24.12 # so it's obvious it's the memory accesses that are bogging stuff down 13.24.15 # I think the memory is the problem - it's using too much slow DRAM 13.24.19 # and faad most certainly seems to use much of it... 13.24.27 # hehe. I think we agree. 13.24.32 # i can perhaps fit one or two important buffers in iram 13.24.37 # the rest, no way 13.24.57 Join Mxm`Pas`Bien [0] (n=flemmard@fbx.flemmard.net) 13.24.58 # the fft/mdct does a ton of memory accesses, so might be beneficial to stuff something around that in iram 13.25.02 # problem is, everything's so big.. 13.25.05 # Do you think some of the buffers could be merged and therefore share the same IRAM? 13.25.14 # i have no idea yet 13.25.24 # i'd need to understand the code to know 13.25.36 # and right now i haven't even superficially looked at it 13.25.50 # Yes, I want to use the sim to try and trace the common code paths. At the moment I don't have a clue what it's doing. 13.27.31 # also, defining out the profiles i don't want in common.h doesn't do anything for the plugin size 13.27.38 Quit amiconn (Read error: 110 (Connection timed out)) 13.27.39 Nick amiconn_ is now known as amiconn (n=jens@p54BD7D7A.dip.t-dialin.net) 13.27.41 # You should be able to use DEBUGF - I've defined a macro for it in common.h. We should probably move that to codeclib.h 13.27.49 # (in the sim I mean) 13.27.57 # Or LOGF for the target. 13.28.05 # Inside libfaad. 13.29.11 # yup 13.29.15 Part LinusN 13.29.21 # but i wont have time for rockbox today 13.29.37 # but please do tell if you get some analyzing done for libfaad 13.30.02 # we most certainly don't need SSR, LTP and LD 13.30.08 # Not sure when I'll get time, but I do want to try and understand libfaad a little better. Maybe tonight. 13.30.08 # we MIGHT not need main either 13.30.52 # I'll also install gcc4 for m68k and see if that makes any difference with the ICEs 13.31.00 # that would be great 13.31.07 # i tried compiling gcc4 once, failed miserably 13.31.14 # but that was on this box, which is amd64 13.32.20 # I think there is also a problem with the Makefile dependencies for libfaad - so be careful. If you change libfaad, then aac.codec isn't always updated. 13.32.33 # oh? 13.32.46 # think i'll just do some deleting and try again, then 13.33.21 # not very likely, though, i think the time stamp changed 13.34.14 Join Webguest82 [0] (n=zeroirc@58.77.80.100) 13.34.31 # hello~ 13.35.32 # oh well 13.35.40 # the gaps are lot smaller than the audio parts now 13.35.43 # but still not realtime 13.35.48 # i expect it'll be a bitch making this realtime as well 13.35.53 # but i've got to go for a sec 13.36.57 # Established IRC at to have a Maneunsigan conversation little more with you danger and injury. :) 13.37.31 # -> Established IRC at to have a conversation during little more much times with you danger and injury. 13.38.45 # linuxstb: you prolly need to add a .elf line for the faad codec like the other codecs are listed 13.39.09 # hm, no sorry 13.39.24 Ctcp Ignored 5 channel CTCP requests in 5 minutes and 19 seconds at the last flood 13.39.24 # * B4gder looks again 13.39.27 # Was H100's firmware made already all? 13.39.29 # yes you do 13.39.53 # Was Hangul translation published? 13.39.58 # * B4gder is confused and will shutup 13.40.07 # Korean 13.41.14 # Is thing which is made in Korean? 13.42.27 Quit Maxime (Read error: 110 (Connection timed out)) 13.48.53 Quit Webguest82 ("Http://www.ZeroIRC.NET ΆΖ Zero IRC ΆΖ Ver 2.8") 14.03.34 Join muesli_- [0] (i=muesli_t@c-180-216-214.cvx-h.dial.de.ignite.net) 14.13.54 Quit ashridah ("Leaving") 14.18.37 Quit muesli_- (Read error: 104 (Connection reset by peer)) 14.39.12 # Moos: fixed 14.50.39 # Slasher: That commit fixes a seeking problem I had as well. 14.53.20 # what kind of seeking problem? 14.55.08 # If I was randomly seeking backwards and forwards in the same file, then eventually it would stop playback and the hard disk would stay active. I then had to stop playback and restart it. 14.55.34 # But that wasn't normal use - I was trying as hard as I could to break it. 14.55.43 # But now I can't. 15.04.52 # linuxstb: that's good :) 15.19.37 Join tucoz [0] (n=81b17b04@labb.contactor.se) 15.19.52 # Hi, Slasheri, are you here? 15.21.12 # I noticed something that is reproduceable(?). When I play a song from an album and press the joystick left during the last seconds of the song to play the song again, the wps do not update. 15.21.26 *** Saving seen data "./dancer.seen" 15.21.48 # this is iriver 15.27.02 # This is for instance song 1 out of 10 in an album. I listen to the first song, and want to hear it again and press left during the last few seconds. Then wps is no more updated and the next song starts playing instead of the same track playing again. 15.29.54 # The problem is that Rockbox has already started decoding the next track. So you are probably trying to seek in the next track, not the one that's being displayed. 15.30.20 # So I'm not sure what the solution could be. It will be worse if you've got crossfade enabled - if you seek during the crossfade, what is Rockbox supposed to do? 15.30.40 # linuxstb: that is probably true. I just noticed that the wps says track 2:14. But, it is not updated. 15.31.01 # I'm not trying to say Rockbox is correct. Just that it's a tricky problem. 15.31.28 # It is not that much of an issue, but the wps should not 'freeze' when this happens. 15.32.34 # If you ignore the WPS problem, what happens? I'm guessing the seek is interpreted as being a seek in the next track. 15.32.45 # linuxstb: correct 15.33.36 # I guess the next track is already in the pcm buffer, and that is why this happens. 15.34.25 # It's the fact that the codec is in the process of decoding the next track. A seek is processed by the codec - so after the previous track has been completely decoded, you can't seek in it any more. 15.35.57 # Ok, that makes sense. Still, there is a bug with the wps that makes it not updating. 15.39.43 # It's possible that the WPS information for the previous track has been thrown away by that point. But I don't really know that code very well, so I'm only guessing. 15.40.15 # Does the WPS display correctly for the next track? Or is that the problem? 15.40.26 # wps is a bit glitchy 15.40.30 # especially for short tracks 15.41.48 # the problem is that the WPS is not updating. The information for the previous track is showing. The time shows for instance 3.15/3.18 (3.15 being the time for the press left to happen, and 3.18 the total track length) 15.42.13 # and track number showing track 2:14 15.43.06 # which is correct. But, nothing else is working. That is no progress bar updates, peak meters, id3 info etc. 15.44.07 # The id3 tags showing are those for the track that _were_ playing. 15.56.04 Join lostlogic [0] (n=lostlogi@node-4024215a.mdw.onnet.us.uu.net) 15.59.47 Part tucoz 16.01.47 Quit Moos ("Glory to Rockbox") 16.02.02 Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) 16.59.33 Join DMJC [0] (n=DMJC-L@220-245-177-240-sa-pppoe.tpgi.com.au) 16.59.37 # um... ok 16.59.44 # can someone help me with warranty info? 16.59.46 Quit DMJC (Client Quit) 17.01.00 Join DMJC [0] (n=DMJC-L@220-245-177-240-sa-pppoe.tpgi.com.au) 17.01.09 # anyone here from australia? 17.01.14 # I need to know some info fast 17.01.17 # IHP-140 17.01.22 # I need to do a warranty claim 17.01.41 # to uninstall rockbox... do I just flash it with the original firmware? 17.01.50 # I sat on my iriver, the screen is busted 17.02.03 # the actual unit itself seems fine except the lcd screen 17.02.12 # the glass outer cover of the screen is intact 17.02.49 # I also need to know which version of the firmware to use 17.02.55 # american? 17.04.04 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 17.04.12 # that shouldn't matter 17.04.40 # flash it with the original firmware and remove the .rockbox directory at root 17.06.03 # ok 17.06.45 # luckily it's under warranty 17.12.30 # of course, warranties usually don't cover user-induced damage 17.12.38 # but i hear iriver hasn't been too strict on that 17.13.52 # nice 17.13.54 # hmm 17.13.59 # how the hell do I flash this thing? 17.14.15 # I can't see the option, screen damage makes it unreadable 17.14.16 # i think it's doable with the remote 17.19.26 Join DMJC-L [0] (n=DMJC-L@220-245-177-240-sa-pppoe.tpgi.com.au) 17.20.50 # hmmm 17.20.53 # ok I reflashed 17.21.04 # and now it doesn't boot unless I hit the reset button 17.21.30 *** Saving seen data "./dancer.seen" 17.22.34 Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU) 17.24.15 Join rubberglove [0] (n=463079b7@labb.contactor.se) 17.25.20 # hello all (or any!) i was just trying to compile todays build and got this error: make: *** libm4a: No such file or directory. Stop. 17.25.53 # did you re-run configure? 17.26.07 # yup. 17.26.12 # i'll try it again. 17.27.33 # did you use 'cvs up -d' (the -d being the key) or how did you get the source? 17.28.12 # the daily builds page.. with the 'latest' source 17.28.26 # ok, I'll check that... 17.29.18 # yup. same error. i ran make clean and then configure 17.30.31 # right, libm4a is missing 17.31.24 # oops. 17.31.36 # fixed in CVS just now 17.31.49 # Thanks - sorry about that. 17.32.07 # cool. thanks. 17.33.18 # Is anyone worried about libFLAC still being in CVS? I was going to delete it, but then thought we might want to try the encoder one day. 17.33.31 # nah, leave it around 17.34.54 # The "apps" directory is almost 40MB now... 17.35.33 # Totals grouped by language (dominant language first): 17.35.33 # ansic: 235877 (95.26%) 17.35.40 # perl: 5621 (2.27%) 17.35.40 # sh: 3457 (1.40%) 17.35.40 # asm: 2513 (1.01%) 17.35.43 # not bad 17.35.45 # (lines of code) 17.36.13 # Total Estimated Cost to Develop = $ 8,812,593 17.36.15 # ;-) 17.36.20 # hahah 17.36.45 # count and estimate by 'sloccount' 17.36.55 Quit Moos (Read error: 104 (Connection reset by peer)) 17.37.03 Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) 17.37.15 # that's entire rockbox? 17.37.19 # yes 17.37.33 # codecs amount to quite a fraction 17.37.53 # I would guess the majority. 17.37.58 # codecs are ~100K lines 17.38.37 # time to go 17.38.39 Quit B4gder ("time to say moo") 17.39.23 # More useless stats - rockbox.iriver: 224356 bytes, aac.codec: 471428 bytes 17.39.29 # ahahahah 17.39.35 Quit DMJC (Read error: 110 (Connection timed out)) 17.40.23 # Even removing the bss, I think aac.codec is bigger than rockbox... 17.41.44 # i wonder how that's possible... 17.41.55 # this is the same codec they're stuffing in mobile phones 17.41.59 # hardware based, sure, but still 17.42.40 # I'm sure we can strip it down a lot - it will just take some time for us to understand it. 17.42.48 # yep 17.42.54 # it's quite a complicated piece of software 17.43.06 Quit DMJC-L (Read error: 110 (Connection timed out)) 17.44.48 Join ender` [0] (i=ychat@84.52.165.220) 17.47.25 Join DMJC [0] (n=DMJC-L@220-245-177-240-sa-pppoe.tpgi.com.au) 17.47.37 Nick DMJC is now known as DMJC-sleep (n=DMJC-L@220-245-177-240-sa-pppoe.tpgi.com.au) 17.48.01 # linuxstb: I checked the apps/ dir size, including subdirs. 9.97 MB, occupying 12 MB of disk space. Nowhere near 40 MB... 17.48.16 Quit ender` (Read error: 104 (Connection reset by peer)) 17.49.17 # All source dirs together: 15.5 MB 17.50.11 # Must be my cluster size then. "du -m" says 39MB 17.51.17 # Oops. No - it's the test WAV file I have in there.... 17.51.48 # Now it's about 13MB of space. 18.04.46 Join ender` [0] (i=ychat@84.52.165.220) 18.10.42 Quit rubberglove ("CGI:IRC") 18.32.12 Join DrMoos [0] (i=DrMoos@m79.net81-66-158.noos.fr) 18.32.23 Quit Moos (Read error: 104 (Connection reset by peer)) 18.32.29 Nick DrMoos is now known as Moos (i=DrMoos@m79.net81-66-158.noos.fr) 19.13.47 Quit Moos ("Glory to Rockbox") 19.14.56 Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) 19.21.31 *** Saving seen data "./dancer.seen" 19.30.30 # linuxstb: we agree we're not going to support more than two channels unless multichannel is the norm for the codec in question (like ac3), yes? 19.34.13 Join arkascha [0] (n=arkascha@xdsl-213-196-216-245.netcologne.de) 19.35.56 Quit arkascha (Remote closed the connection) 19.43.55 # amiconn: i've solved the mystery of the slow layer1, it seems 19.46.08 # amiconn: seems it was a cache issue, it works without boosting for 256kbps layer 1 if i just inline the per sample function that's used in the frame decoding 20.48.43 Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) 20.49.10 Quit ghode|afk (Read error: 104 (Connection reset by peer)) 20.49.41 Quit Mxm`Pas`Bien (Read error: 104 (Connection reset by peer)) 20.52.19 Join Maxime [0] (n=flemmard@fbx.flemmard.net) 20.55.54 Join ghode|afk [0] (n=garudin@host-212-158-193-204.bulldogdsl.com) 21.19.07 Quit ghode|afk (Read error: 104 (Connection reset by peer)) 21.19.49 # preglow: Nice... Did you check whether this also helps layer 2 performance? 21.20.13 # amiconn: it can't, layer 1 and 2 decoding is separate 21.20.22 # amiconn: but if you mean just inlining, i'm going to try that afterwards 21.20.23 # Oh ok 21.20.51 # layer 2 decoding has a similar routine, but it eats three samples and not just one 21.21.04 # i'll check it out anyway, there's no reason for layer2 to actually be slower than layer3 21.21.13 # i hate these one way associative caches 21.21.32 *** Saving seen data "./dancer.seen" 21.22.14 # It's not necessarily a cache issue 21.22.32 # You say this function is called for every sample, i.e. really often 21.22.47 # Parameter passing is done via the stack on coldfire 21.23.49 # yes, sure 21.23.54 # but i can't imagine it should hurt _this_ much 21.23.55 # i mean 21.24.06 # it's actually heavier than a full imdct per band 21.24.10 # and that's just plain impossible 21.24.28 # Inlining avoids the whole call overhead 21.24.43 # it does 21.24.46 # and it can aid optimising 21.25.04 # perhaps i should just try compiling the entirety of libmad O3 21.25.16 # that should auto-inline functions if it thinks it'll benefit 21.25.27 # I can't build the h1x0 win32 sim, I get a really strange error 21.26.02 # CC bits.c 21.26.02 # In file included from common.h:261, 21.26.02 # from bits.c:28: 21.26.02 DBUG Enqueued KICK amiconn 21.26.02 # fixed.h: In function `MUL_R': 21.26.02 # fixed.h:67: error: `_asm' undeclared (first use in this function) 21.26.02 *** Alert Mode level 1 21.26.02 # fixed.h:67: error: (Each undeclared identifier is reported only once 21.26.04 # fixed.h:67: error: for each function it appears in.) 21.26.06 # fixed.h:67: error: parse error before '{' token 21.26.08 # fixed.h:71: warning: no return statement in function returning non-void 21.26.10 # fixed.h: In function `MUL_C': 21.26.12 # etc etc 21.26.26 # some more undeclared symbols named "_asm" 21.26.31 # ahh, riiight 21.26.39 # it probably doesn't check if it uses msvc or gcc 21.26.46 # libfaad uses msvc style inline asm 21.26.52 # This is really strange, I can build the x11 sim just fine - also under cygwin, using the very same gcc! 21.27.23 # #if defined(_WIN32) && !defined(_WIN32_WCE) 21.27.27 # yes, like i thought 21.27.28 # urgs 21.27.45 # I think that can be safely removed... 21.28.10 # i think i'm a bit lagged 21.29.20 # Way back in time we had an msvc project for building the sim, but that broke long ago, and was removed because nobody fixed it again 21.29.31 # just as well 21.29.36 # can't see a reason to use msvc 21.33.45 # apart from the ui, of course 21.33.52 # the compiler itself isn't very good 21.36.03 *** Alert Mode OFF 21.41.39 # Imho these msvc-style inlines should be removed, and perhaps replaced by gcc-style inline asm for x86 21.41.44 # What do you think? 21.42.59 # i agree 21.43.08 # can't see a use for the msvc ones, at least 21.43.27 # though i'm a bit puzzled by the need for these functions anyway 21.43.44 # i would have thought x86 compilers were clever enough to actually use those instructions anyway 21.45.16 # Perhaps msvc isn't? ;) 21.45.31 # wouldn't have surprised me 21.45.35 # it used to be a really poor compiler 21.45.41 # though i here the more recent incarnations are pretty good 21.57.20 # What's so special about these inlines? The use of the imul instruction. 21.57.25 # yes 21.57.31 # (I'm an x86 asm noob) 21.57.31 # it does a 32x32->64 bit mul 21.57.43 # i'm not much of an expert myself 21.57.46 # but i know that 21.57.59 # If so, I think the inlines can probably removed 21.58.03 # and then theres the shrd instruction, that does shifting from one register to another one 21.58.04 # gcc, uses imul 21.59.19 # I disassembled the simulator aac.codec with objdump, and checked a function that uses some MUL_R s 21.59.51 # does it use shrd as well? 22.00.14 # There are seveal imul instruction, and also some shrd 22.00.19 # *several 22.00.46 # anywho 22.00.52 # i think they can be removed 22.01.04 # i refuse to believe modern compilers can't do 64 bit muls on x86 22.01.21 # x86 asm looks strange 22.01.29 # and the less i see of the idiot inline assembler thing msvc uses, the better 22.01.31 # in what way? 22.02.16 # Really complex instruction format, and looong instructions 22.02.34 # It seems instructions can be any length from 1 to 10 bytes 22.03.00 # yup 22.03.05 # the instruction length varies wildly 22.03.36 # i'm not really fond of x86 assembler myself 22.04.04 # it got a bit easier with x86-64, since you at least get a semi-decent number of registers to play around with 22.11.15 # i'll try inlining the layer 2 routine now, and see if it helps 22.11.22 # Okay, completely removed these inlines locally. Now the win32 sim builds again :) 22.11.49 # Shall I commit? 22.14.41 # sure 22.14.55 # amiconn: performance actually seemed to get worse if i inline II_samples 22.16.13 # but it's hard to say, at least it didn't get any better that i could see 22.18.36 # aac.codec is a monster on the sim as well. 250KB for win32, and 662KB (!) for x11 22.18.47 # eh? 22.18.55 # what's the size difference? 22.19.10 # I'm not sure... perhaps debug symbols 22.19.23 # All codecs are larger for x11 than for win32 22.19.49 # it doesn't make sense to include debug symbols in a binary image 22.20.10 # The sim codecs aren't plain binary images 22.20.13 # and the size for windows doesn't make sense either, that's actually almost twice as small as for the actual target version 22.20.16 # no? 22.20.17 # They are shared libraries 22.20.19 # ok 22.21.42 # Some codecs are half the size of the target version in windows, but some are roughly equal in size 22.21.42 # i'd like for us to use something like that on target as well, one day 22.21.50 # at least just a simple format with relocation information 22.22.00 # This doesn't correlate to the absolute size, must be something else 22.22.33 # i think i'll just commit the few libfaad macros i have so far 22.22.51 # without commiting the one that provokes the ICE 22.23.30 # You could put that in as well, and disable it for now (#if 0) 22.28.55 Quit Kohlrabi (Nick collision from services.) 22.28.58 Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-130-062.pools.arcor-ip.net) 22.33.08 # hmm 22.33.42 # MUL_R requires me to do a 64 bit shift by 17 22.33.53 # think i'll just modify your libmusepack routine a bit for that one 22.34.39 Join ghode|afk [0] (i=testing@host-212-158-193-204.bulldogdsl.com) 22.38.32 # shift by 17? 22.38.50 # Shouldn't that be 14? 22.40.14 # Iiuc this is exactly the same as mpc_multiply() 22.43.40 Join muesli_- [0] (i=muesli_t@Bc0a8.b.pppool.de) 22.45.22 # should be 14, yes, i misread 22.45.37 # mpc_multiply shifts by 16 22.46.16 # bah 22.46.18 # forget me 22.46.28 # yes, i can just use the mpc_multiply verbatim, it seems 22.53.46 Join Midgey34 [0] (n=chatzill@c-67-172-68-52.hsd1.mi.comcast.net) 23.10.52 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 23.10.52 # * preglow hopes for a new ICE 23.12.45 # bah 23.21.33 *** Saving seen data "./dancer.seen" 23.48.19 Join RotAtoR [0] (n=e@12-210-82-91.client.insightBB.com) 23.54.04 Quit _FireFly_ ("Leaving") 23.56.54 Quit Kohlrabi (Read error: 104 (Connection reset by peer)) 23.58.20 # preglow: I've just updated to your fixed.h changes, and I am just getting noise out of the decoder now.