--- Log for 03.11.105 Server: kornbluth.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 5 days and 22 hours ago 00.00.16 # haha 00.00.33 Quit ender` (Read error: 104 (Connection reset by peer)) 00.03.47 # LinusN: Do you think the patch should enabled continuous page mode as well? 00.04.08 # sure, why not? 00.04.49 # @Moos - are you not getting my msg ? 00.05.09 # nope ;) 00.05.33 # good night 00.05.37 Part tucoz 00.06.46 # @weird - I sent like 10 :) 00.06.57 # :D 00.07.12 # are you freenode registrated? 00.07.19 # nope... 00.08.23 # try to registred your nick for send and receive private msg 00.08.28 Join topbloke [0] (i=top_blok@adsl-69-209-21-84.dsl.emhril.ameritech.net) 00.09.22 # hey can simulator builds of rockbox be downloaded anywhere? 00.10.18 # topbloke: no, you build them yourself 00.10.54 # oh they used to be on the site 00.10.56 # what happened 00.12.32 # i dunno, maybe we didn't see the point in providing them 00.12.51 # ok cool 00.13.09 # what would be the point? 00.13.16 # it lets people without a target play around with rockbox 00.13.24 # without messing with compling 00.14.13 # i wanted to see how rockboy runs on an iRiver 00.14.54 # you'd need to run on target to see that 00.15.00 # oh ok 00.15.12 # as the simulator doesn't run with the same speed 00.15.42 # is it playable at all on a real iRiver ? 00.15.51 # some games are 00.15.58 # like pokemon 00.16.04 # oh sweet 00.16.11 # pokemon i love that ! :) 00.16.33 # super marioland is quite playable as well 00.16.44 # no sound though 00.17.01 # how about on a archos recorder? 00.17.12 # haven't tried 00.17.27 # ok thanks 00.17.41 # time to sleep 00.17.44 # cu all 00.17.51 # bye 00.17.52 Part LinusN 00.19.46 # think i'll take his example 00.19.48 # night all, later 00.20.33 # anyone has an idea what combination of buttons on main iRiver unit I can use for folder skip? 00.25.07 Join Midgey34_ [0] (n=chatzill@c-67-172-68-52.hsd1.mi.comcast.net) 00.26.12 Join Midgey34__ [0] (n=chatzill@c-67-172-68-52.hsd1.mi.comcast.net) 00.27.35 Join Midgey34___ [0] (n=chatzill@c-67-172-68-52.hsd1.mi.comcast.net) 00.27.35 *** Alert Mode level 1 00.27.35 DBUG Enqueued KICK Midgey34 00.27.35 DBUG Enqueued KICK Midgey34_ 00.27.35 *** Alert Mode level 2 00.27.35 DBUG Enqueued KICK Midgey34__ 00.27.35 DBUG Enqueued KICK Midgey34___ 00.27.35 *** Alert Mode level 3 00.28.14 # LinusN: (when you check the log) - patch uploaded. 00.29.52 Quit DMJC-L (Read error: 110 (Connection timed out)) 00.30.07 Join Midgey34____ [0] (n=chatzill@c-67-172-68-52.hsd1.mi.comcast.net) 00.30.07 *** Alert Mode level 4 00.30.07 *** Alert Mode level 5 00.30.07 DBUG Enqueued KICK Midgey34____ 00.30.07 *** Alert Mode level 6 00.30.07 *** Alert Mode level 7 00.30.07 *** Alert Mode level 8 00.30.07 *** Alert Mode level 9 00.39.27 Part len0x 00.39.27 Quit Moos ("Glory to Rockbox") 00.40.08 *** Alert Mode OFF 00.41.04 Quit Midgey34 (Read error: 110 (Connection timed out)) 00.41.42 Quit Midgey34____ ("Chatzilla 0.9.68.5.1 [Firefox 1.0.7/20051010]") 00.41.54 Join Midgey34 [0] (n=chatzill@c-67-172-68-52.hsd1.mi.comcast.net) 00.41.54 *** Alert Mode level 1 00.41.54 *** Alert Mode level 2 00.41.54 DBUG Enqueued KICK Midgey34 00.41.54 *** Alert Mode level 3 00.42.05 Quit Midgey34_ (Read error: 110 (Connection timed out)) 00.45.44 Quit Midgey34___ (Read error: 110 (Connection timed out)) 00.49.56 Join DMJC [0] (n=DMJC-L@220-245-177-240-sa-pppoe.tpgi.com.au) 00.51.56 *** Alert Mode OFF 00.55.07 Quit Midgey34__ (Read error: 110 (Connection timed out)) 00.57.59 Quit Midgey34 (Read error: 110 (Connection timed out)) 01.01.58 Nick linuxstb__ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net) 01.08.41 Quit Kohlriba ("Leaving") 01.20.13 Quit matsl ("Leaving") 01.22.13 *** Saving seen data "./dancer.seen" 02.07.27 Join RotAtoR [0] (n=e@12-210-82-91.client.insightBB.com) 02.13.34 Join webguest00 [0] (n=546416a9@labb.contactor.se) 02.14.39 Quit webguest00 (Client Quit) 02.27.03 Quit _aLF ("^^") 02.43.16 Join mannie [0] (n=45dd4025@labb.contactor.se) 02.43.57 # yo, i was wondering if you guys had rockboy workin on the archos jukebox recorder..? 02.44.49 Quit mannie (Client Quit) 03.05.11 Quit cYmen ("zZz") 03.22.15 *** Saving seen data "./dancer.seen" 03.29.56 Join wireddd [0] (n=wired@68-117-215-114.dhcp.athn.ga.charter.com) 04.33.31 Quit paugh ("Leaving") 04.47.44 Quit RotAtoR () 04.59.52 Quit topbloke ("bye") 05.17.14 Join XShocK [0] (n=XShocK@brewster.equinoxsensors.com) 05.22.18 *** Saving seen data "./dancer.seen" 06.00.36 Join ashridah [0] (i=ashridah@220-253-121-245.VIC.netspace.net.au) 06.40.24 Join mrmags [0] (n=stryfe@dsl254-076-201.nyc1.dsl.speakeasy.net) 06.42.36 # keins wachs? 06.43.01 Quit Rick (Read error: 104 (Connection reset by peer)) 06.43.55 Join Rick [0] (i=rick@pool-71-108-9-40.lsanca.dsl-w.verizon.net) 07.09.32 Quit DMJC (Read error: 110 (Connection timed out)) 07.15.56 Quit mrmags ("Download Gaim: http://gaim.sourceforge.net/") 07.22.19 *** Saving seen data "./dancer.seen" 07.36.52 Join Aison [0] (n=hans@zux166-181.adsl.green.ch) 07.56.04 Join B4gder [0] (n=daniel@static-213-115-255-230.sme.bredbandsbolaget.se) 07.56.35 Quit Aison (Read error: 104 (Connection reset by peer)) 08.10.23 # http://hardware.slashdot.org/article.pl?sid=05/11/02/2055238&from=rss 08.10.31 # "Can Open Source Outdo the IPod?" 08.10.58 # two tiny mentionings of Rockbox and lots of crap said 08.15.03 Join ender` [0] (i=ychat@84.52.165.220) 08.18.50 Join solexx_ [0] (n=jrschulz@c225214.adsl.hansenet.de) 08.21.36 # yeah, but you're forgetting that slashdot users have the attention span of gerbils, so they're perpetually amused by the clicky wheel 08.21.47 # hehe, yes 08.23.38 # i imagine the entire thread is full of morons going "oss will never come up with the clicky wheel!" 08.23.52 # yes, lots of that style 08.23.59 # and no actual discussion of reverse engineering, drm, or other issues facing it 08.25.16 # Haha, ""There is very little innovation left" 08.25.25 Quit solexx (Read error: 104 (Connection reset by peer)) 08.25.26 # Someone please ask our blind users... 08.25.33 # haha 08.25.46 # apple sheep 08.26.16 # morning, btw :) 08.29.52 # I got quite a lot of traffic to the curl site from another recent slashdot article: http://linux.slashdot.org/article.pl?sid=05/11/01/215201&tid=106 08.32.38 Join thegeek [0] (n=thegeek@s115b.studby.ntnu.no) 08.38.40 # Zagor: http://forums.rockbox.org/index.php?topic=1737.0;topicseen 08.45.21 # the Rockbox wikipedia article has its flaws 08.45.42 # said about the Archos players: "These devices have relatively weak main CPUs and instead offload music playback to dedicated hardware MP3 decoding chips (similar to the Apple iPod)." 08.46.03 # that's not similar to the ipod... 08.49.22 Join LinusN [0] (n=linus@labb.contactor.se) 08.50.59 Quit thegeek_ (Read error: 110 (Connection timed out)) 08.53.38 Quit ghode|afk (Read error: 110 (Connection timed out)) 08.54.25 # TiMiD: Are you around? 09.00.46 # heh. i love having flamewars with no-nothing overclockers :) 09.03.31 Part LinusN 09.08.29 # amiconn: yes I'm here (for 5 minutes, no more) 09.19.27 # There is a bug with the gui menu system and the voice ui 09.20.52 # When you move the cursor from item to item, the items are voiced, but not when you enter a menu or leave a sub-menu 09.21.01 # This worked before... 09.22.20 *** Saving seen data "./dancer.seen" 09.22.52 # ok 09.23.08 # I'll look at this this evening 09.23.13 # now I have to go ... 09.23.51 # this shouldn't be too hard to fix 09.25.05 # Maybe there's another problem. 09.38.59 Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-130-062.pools.arcor-ip.net) 10.33.19 Join ghode|afk [0] (n=garudin@host-212-158-193-204.bulldogdsl.com) 10.35.24 Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) 11.03.36 Join yngwi [0] (n=chatzill@chello080109107064.1.15.vie.surfer.at) 11.05.45 Quit DangerousDan (Read error: 104 (Connection reset by peer)) 11.13.30 Join blackax [0] (n=blackax@netblock-66-245-244-93.dslextreme.com) 11.14.16 Join webguest19 [0] (n=42f5f45d@labb.contactor.se) 11.14.31 # hi 11.16.21 Quit webguest19 (Client Quit) 11.22.21 *** Saving seen data "./dancer.seen" 11.30.44 # Morning all. I'm currently running a test to see how many hours of FLAC playback Rockbox can manage (currently 9.5 hours and still running). 11.31.06 # But I'm not sure how this test will end. What will happen when the battery runs out? 11.31.43 # The battery indicator is currently showing about 30%-40% full. 11.31.46 Join webguest82 [0] (n=3a4d50b4@labb.contactor.se) 11.31.57 # hello 11.32.28 # Connection does not become by irc program. 11.35.19 # o.o 11.36.31 # :) I like Rockbox so. 11.36.57 # Zagor: Installer builds are still not working ?!? :-(( 11.39.59 # markun: Are you busy? 11.46.17 # What is wps? 11.56.02 # wps is "while playing screen" 11.56.57 Join LinusN [0] (n=linus@labb.contactor.se) 11.57.15 # amiconn: the innosetup scripts were lost in the twiki raid 11.58.48 # thanks 11.59.48 # LinusN: I have the scripts here. Zagor didn't mention they were lost when I first asked why the installer builds aren't working 12.03.38 Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 12.04.15 # amiconn: good, can you send them to me? 12.05.57 Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 12.08.21 # amiconn: I just corrected this problem, what is the other you were talking about ? 12.08.50 Join cYmen_ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 12.13.37 # Anyone know what Rockbox on the iriver does when the battery is too low? I'm doing a playback test, but have never run the battery flat before. 12.14.01 Join cYmen__ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 12.14.39 # nothing 12.14.45 # i think 12.15.05 # it runs until the power is too low for the harddisk to spin.. 12.15.19 # correct me if i'm not right with that 12.16.34 Quit linuxstb (Read error: 110 (Connection timed out)) 12.17.01 # I guess I'll find out soon. But I'm already impressed - 10 1/4 hours and still running (flac -8 files). 12.17.18 # Battery looks about 1/3 full. 12.17.40 # Make that 1/4 full. 12.18.31 # sounds good 12.19.14 Join cYmen___ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 12.19.14 *** Alert Mode level 1 12.19.14 DBUG Enqueued KICK cYmen 12.19.14 DBUG Enqueued KICK cYmen_ 12.19.14 *** Alert Mode level 2 12.19.14 DBUG Enqueued KICK cYmen__ 12.19.14 DBUG Enqueued KICK cYmen___ 12.19.14 *** Alert Mode level 3 12.19.16 # but you know that running your battery very low could damage it, right? 12.21.24 Quit cYmen (Connection timed out) 12.24.25 Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 12.24.25 *** Alert Mode level 4 12.24.25 *** Alert Mode level 5 12.24.25 DBUG Enqueued KICK cYmen 12.24.25 *** Alert Mode level 6 12.24.25 *** Alert Mode level 7 12.24.25 *** Alert Mode level 8 12.25.28 Join tucoz [0] (n=81b17b04@labb.contactor.se) 12.25.38 Quit tucoz (Client Quit) 12.26.01 Join tucoz [0] (n=martin@hornved.ii.uib.no) 12.27.08 Quit ashridah (Read error: 110 (Connection timed out)) 12.28.09 # linuxstb_, looks promising that FLAC test of yours. I found a post on misticriver stating that Rockbox will shut down when the battery is around 2.7 volts 12.28.16 Join ashridah [0] (i=ashridah@220-253-123-89.VIC.netspace.net.au) 12.28.49 # tucoz: rockbox doesn't shut down at all, the hardware does it 12.28.56 # ...and that a lithium-poly battery may be damaged if being <= 2.5 volts 12.29.24 # So it's safe to let it run until death? 12.30.07 # "battery university" even claims that liIo batteries should be kept at no less than 40% charge level 12.30.24 # http://www.batteryuniversity.com/parttwo-34.htm 12.30.31 # linuxstb_, read the post by Febs. http://www.misticriver.net/showthread.php?t=27832&highlight=battery 12.30.34 Quit cYmen_ (Connection timed out) 12.31.29 # " Some lithium-ion batteries fail due to excessive low discharge. If discharged below 2.5 volts per cell, the internal safety circuit opens and the battery appears dead." 12.31.41 Quit cYmen__ (Connection timed out) 12.32.05 # "if the cell voltage has fallen below 1.5V/cell and has remained in that state for a few days, a recharge should be avoided because of safety concerns." ;-) 12.32.59 Join linuxstb__ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 12.33.22 Nick linuxstb__ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net) 12.33.26 # (sorry, ADSL playing up again). 12.33.31 # I've a problem with cvs 12.33.58 # export CVSROOT=:pserver:kevin@rockbox.haxx.se:/cvsroot/rockbox 12.34.05 # cvs login 12.34.06 # Logging in to :pserver:anonymous@rockbox.haxx.se:2401/cvsroot/rockbox 12.34.13 # why is it anonymous ? 12.34.21 # So, 2.7 volts is perhaps a lower bound for voltage then? 12.34.26 *** Alert Mode OFF 12.34.36 # TiMiD: Because you originally checked out those files anonymously? 12.34.46 # hmm maybe 12.34.50 # if the disk is still able to spin up at that voltage 12.34.54 # cvs will look in a directory called "CVS" first to get the repository details. Look at the files in that directory. 12.35.21 # you are right :) 12.35.36 # You should just be able to edit those files manually. 12.35.51 # But it may be easier to check out a fresh copy, and then transfer your modified files to that copy. 12.35.51 # linuxstb: not too shabby a runtime for flac, if you ask me 12.36.00 # preglow: I'm very happy. 12.36.00 # linuxstb: is this with the stock battery? 12.36.15 Quit Kohlrabi (Read error: 110 (Connection timed out)) 12.36.18 # Yes - a completely unmodified H140. 12.36.41 Quit cYmen___ (Connection timed out) 12.36.47 # B4gder: given up on neuros, or? ;) 12.37.14 # What is next for you codec-phantoms? mod, sid? That would be so cool. 12.37.15 # not quite 12.37.17 # but almost 12.37.24 # and a major lack of time 12.37.49 # i'd really like to hear SID tunes on my iriver 12.38.33 # tucoz: there's more than enough for me to do on the good old streaming formats yet 12.38.41 # i don't consider any of them finished for release 12.39.13 # at least some forum person says i've fixed the lame large enc_delay issue 12.39.52 # it is so bad that libsidplay is totally c++'ified. Lot's of dynamic memory allocation. That is the big hurdle of sid's in rockbox I think. 12.40.28 # preglow: Does that mean that lame mp3 playback is perfectly gapless now? 12.41.00 # linuxstb: no 12.41.05 # linuxstb: more or less, at least 12.41.12 # linuxstb: but seeking for one breaks it 12.41.45 # but that should be easily fixable 12.41.47 # preglow, that is fully understandable. Sids and mods (when that time comes) is just the frosting of the cake :) 12.42.23 # i'd like mod support 12.42.37 # i'd also like spc support 12.42.48 # sids would of course be nice too 12.42.49 # spc? is that speex? 12.42.54 # spc is snes music 12.42.57 # hehe 12.44.20 # tucoz: but the codec api and the buffering system would need work before any of those formats can be implemented 12.44.22 Join linuxstb__ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 12.46.07 # ah, that is true. Hmm, what is the problem with DUMB? floating point or something else? 12.46.53 # except from the codec api stuff 12.48.02 # is it normal that voices makes the simulator segfault ? 12.48.12 # (it works well on target) 12.48.15 Quit linuxstb_ (Read error: 110 (Connection timed out)) 12.48.22 # preglow: I'm not sure how much the codec api would need to change. The codec would just need to use the "request_buffer" callback to get access to the entire buffer containing the track (playback.c would have to ensure it is available) and then the codec would just play it, never advancing the buffer pointer until the end. 12.48.33 # tucoz: floating point is its current problem, yes 12.48.59 # linuxstb__: well, for one, the codec buffer have to start buffering whole files 12.49.02 # just partial ones wont do 12.49.06 # Yes, but these files are tiny? 12.49.11 # not necessarily 12.49.18 # i've seens xms that are fifteen meg big 12.49.25 # tons of samples 12.49.51 # my take at how this should work is the following: 12.50.04 # That wouldn't be a change in the API as such, just changing the buffering behaviour for certain file types. 12.50.12 # the codec plugin itself gets to have a loader function that get's called whenever the buffering system is about to load a file 12.50.43 # That could be the current get_metadata() function. 12.50.44 # it gets a file handle, so it can read whatever it likes, then usually processeses the data, and puts it in the mp3 buffer in processed form 12.51.00 # yes, sure, but then we'd have to start linking rockbox core with codec libs 12.51.05 # these functions can be quite big 12.53.01 # but yes, they'd need to be part of static rockbox somehow, either by being compiled in, or by being loaded at startup from the codec plugins somehow 12.53.41 # the latter would mean devising a codec format that can be relocatable, i guess 12.54.24 # It depends how we view the codec plugins - do we want the codec plugins to be completely standalone (i.e. you can add a new format by just adding a new plugin), or are we just using plugins as a way to swap code in and out of Rockbox. 12.54.25 # TiMiD: There is a problem with a null pointer access in the talk code, but only on iriver. It may or may not be caused by your gui changes 12.54.31 # ok 12.54.40 # so I can commit 12.55.30 # and what about the other problem you were talking about this morning ? 12.56.03 # linuxstb__: if we were to move metadata and loader functionality to plugins, this would be a part of the plugins that rockbox would keep loaded at all times anyway 12.56.21 # This is the other problem. It wasn't there when I last checked. Found it with the 'catch memory accesses' debugging feature 12.56.25 # but i would like all codec dependent functions to be placed in the plugins, eventually 12.56.39 # so you can just remove the ones you don't like, and save memory 12.56.41 Ctcp Ignored 11 channel CTCP requests in 11 hours and 56 minutes at the last flood 12.56.41 # * amiconn wonders whether he is the only one actually using it from time to time 12.57.08 # amiconn: i rarely use it, mostly because i forget about it 12.57.46 Quit linuxstb (Read error: 110 (Connection timed out)) 12.58.04 Quit webguest82 ("CGI:IRC (EOF)") 12.58.35 # ditto 13.00.23 # preglow: I would like to move closer towards separating the container format parsing from the actual decoding. Which I think is similar to your idea of having loader functions. 13.01.35 # For example, the ALAC codec and AAC codec are almost identical - apart from calling different decode_frame() functions. 13.04.16 # sure 13.04.42 # well, it requires some thinking anyway 13.05.17 # building the metadata loader into each codec plugin wouldn't be too nice either, some they're shared everywhere 13.05.24 # so we might end up with metadata plugins as well, hehe 13.05.54 # where a codec plugin specifies which metadata formats it uses 13.08.08 Part tucoz ("Leaving") 13.08.22 Join amiconn_ [0] (n=jens@p54BD41E4.dip.t-dialin.net) 13.16.57 # I think the actual metadata routines (ID3, ID3v2, Vorbis comments, Ape tags) could stay in the core. 13.17.56 # But we could then have plugins for the container formats, and plugins for the actual codecs. 13.22.25 *** Saving seen data "./dancer.seen" 13.22.26 # moving everything to plugins would also probably mean a pretty hefty startup time 13.23.17 Join webguest82 [0] (n=3a4d50b4@labb.contactor.se) 13.23.17 # linuxstb__: if we can think of a good way to make the container format and codec interact, then sure 13.24.40 Nick yngwi is now known as yngwi_away (n=chatzill@chello080109107064.1.15.vie.surfer.at) 13.24.52 # What is Peak Release? 13.26.23 Quit amiconn (Read error: 110 (Connection timed out)) 13.26.23 Nick amiconn_ is now known as amiconn (n=jens@p54BD41E4.dip.t-dialin.net) 13.28.14 # preglow: I'm not convinced the container parsers need to be plugins. I would probably be happy to make them part of the core as well. But we'll see how things develop. 13.28.40 # webguest82: how fast the peak on the peak meter releases 13.28.59 # linuxstb__: well, that'd be a step towards having them as plugins anyway 13.29.15 # linuxstb__: if that can be done, then keeping them as plugins can be done just as easily 13.29.50 # but no, the fact that nonstreaming formats need to load their own data needs consideration 13.29.59 # I don't see why we need (in the long term) the .c files in apps/codecs. That logic should be the same for all codecs, so could be moved elsewhere. 13.30.18 # I agree about the non-streaming codecs though. 13.30.29 # just loading the file into the codec buffer wont do, these formats are not used to using their data as it's stored in the file 13.30.31 # The problem is that we don't have any, so we can't see how they need to work. 13.30.44 # libdumb is in cvs :> 13.44.50 Quit arkascha (Remote closed the connection) 13.52.02 # LinusN: I've zipped innosetup together with the scripts, 2.6 MB. Is DCC okay? 13.52.10 # try it 13.52.52 Join _FireFly_ [0] (n=FireFly@p54A46225.dip.t-dialin.net) 13.53.04 # holy moses, it worked 13.58.15 # !! 14.01.14 # FLAC is now just over 12 hours and still going. 14.01.24 # i'd say that's remarkable 14.01.26 # LinusN: There's no reason it should not work, except if you'd explicitly blocked it on your side 14.01.47 # firewalls 14.01.49 # linuxstb__: and all q8 files, you say? 14.01.53 # and NATs 14.02.13 # preglow: Yes - I'm playing the same -q 8 encoded album on repeat. 14.03.22 # "View Battery" says 3.58 14.03.30 # starting to hit bottom then 14.03.49 # Yes, only a tiny amount left in the battery indicator. 14.04.18 # the iriver firmware would probably have shut down by now 14.04.58 # B4gder: I am behind a NAT router. It's really not difficult to configure it for working dcc 14.07.47 # not for you on your router, no 14.07.58 # there are still endless possibilities for it to go wrong 14.09.01 # oh yes 14.09.22 # amiconn: you said "there is no reason for it not to work unless you explicitly block it", and then you say that you had to configure it to make it work 14.09.26 # both clients need client configuration and router configuration that is correct 14.09.38 # that is, just one of them needs the client config 14.10.27 # LinusN: Yes. I said that because I already configured that some time ago, and know that it works on my side 14.10.58 # and before that, did you explicitly block it on your side? 14.11.43 # The receiving client does not need special configuration, just outgoing connections to high ports must not be blocked 14.12.00 # my point is, that is only one of the many things that would prevent dcc from working 14.12.32 # so the sending client must have a properly configured router 14.13.01 # Yes, and that was my point. I know that my config is correct 14.14.09 # i see now what you mean, i thought you were speaking in general terms 14.16.48 Quit blackax (Read error: 113 (No route to host)) 14.17.22 Join blackax [0] (n=blackax@netblock-66-245-244-93.dslextreme.com) 14.22.34 # linuxstb__: well, hooray, the q8 files should be a lot heavier to decode as well 14.22.50 Join akke [0] (n=82ed341b@labb.contactor.se) 14.22.56 # i wonder what the hell libflac did to make it so slow 14.23.48 # the ffmpeg decoder is almost twice as fast running on my PC compared to the standard "flac". 14.24.07 # Which surprised me even more than the iriver performance. 14.25.08 # I'm also surprised that no other software seems to use the ffmpeg FLAC decoder - but I suppose the reason is that it isn't nicely packaged like libFLAC. 14.25.15 Join einhirn [0] (i=Miranda@szgt-d9b8e94d.pool.mediaWays.net) 14.27.07 # Anyway, now 12.5 hours and battery is 3.41 14.27.21 # Battery indicator now flashing.... 14.28.38 # hehe 14.28.45 # i'd turn it off soon, were i you 14.29.07 # i _think_ someone managed to brick their player by running it too far down 14.29.16 Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-130-062.pools.arcor-ip.net) 14.29.47 # It's just managed one more buffer refill and is still going.... 14.30.09 # But you're probably right - I should stop. 14.31.12 # 12.5 hours is heaps beyond what i'd expected anyway 14.32.15 # i wonder how much of that is caused by it never boosting 14.32.21 # it does never boost even for q8 files, no? 14.32.31 # I've not seen it boost, no. 14.33.43 # Any idea what the battery life for other codecs are? Is 12.5 hours competitive with the lossy codecs? 14.35.02 # OK, it's died now - it can't spin up the disk to refill the buffer. 14.35.12 # Total length - 12 hours, 38 minutes. 14.35.15 # haha 14.35.21 # last i heard was 15.something 14.35.24 # but i can't remember for what 14.35.26 # think it was vorbis 14.35.55 # It turned itself off, just before I plugged the charger in. 14.36.11 # Think I'll leave it to rest for a while. 14.36.47 # The only test I've seen was for Vorbis -q 5 files - 13h 1m for Rockbox, 12h 8m for iriver's firmware. 14.37.50 # http://www.misticriver.net/showthread.php?t=30669 14.38.12 # then it flaming IS competitive 14.38.31 # does cpu usage actually have that much to say? 14.38.32 # Or Vorbis is bad.... 14.38.55 # But it seems that Rockbox's vorbis is already better than iriver's. 14.39.15 # what the hell? 14.39.15 # (or iriver shuts down too early) 14.39.23 # the first post there doesn't look very good 14.39.46 # 112kbps mp3 should never boost either 14.39.51 # so 11h is a bit... weird... 14.40.02 Quit ashridah ("Leaving") 14.40.35 # Not sure what this means in that post though: "Backlight usage: Average" 14.40.46 # Hmm, i got something like over 17h a long time ago when i tried 128kbps mp3 in "lab mode test" 14.41.12 # Slasher: lab test mode? 14.41.27 # linuxstb__: anyway, the extra hour for vorbis is more probably because of rockbox running the battery completely empty 14.41.27 # preglow: almost, i never touched the unit during that period 14.41.39 # Slasher: what is 'lab mode test'? 14.42.00 # That's how I would describe my test as well - setting it going to repeat an album forever, and not touching the unit until it dies. 14.42.09 # preglow: just something similar what iriver based it's runtime approximation 14.42.23 # okies 14.42.26 # Slasher: btw 14.42.36 # Slasher: when 'go to next folder' option is on, the buffering stops at the end of a folder 14.42.42 # LinusN: I have a patch for system.c, implemeting dynamic RTIM setting in system.c. Would you like to have a look at it? 14.42.53 # preglow: yes, that is a problem with the playlist 14.42.55 # Oh, and btw, there's a crt0.S patch in the tracker :) 14.43.18 # preglow: i think playlist_check(1) returns false or something like that so it can't buffer before calling playlist_next(1); 14.43.21 # Slasher: so next folder isnt added to the playlist before it reaches the end of the last song? 14.43.21 # saw that 14.43.28 # show me the rtim patch 14.43.39 # preglow: it looks like that 14.45.21 # Sorry for the ignorant question, but what is the "go to next folder" option? What's considered the next folder? 14.45.31 # the next folder in the dirlist 14.45.44 # amiconn: ok, so the only difference is that there is no read-modify-write? 14.46.07 # looks good to me 14.46.08 # i keep my albums in folders, sometimes with cd1 and cd2 subfolder, so i like it to advance further when it should 14.46.41 # I just recursively add the parent directory to the playlist. 14.46.52 Quit B4gder ("time to say moo") 14.46.58 # i gues that's possible as well, i just never use playlists much 14.47.02 # guess 14.47.02 # What is Linear? 14.47.17 # webguest82: for the peak meter? it just means it displays the sound level linearly, not as decibel 14.47.22 # i prefer my peak meter linear 14.47.40 # thanks ^^ 14.47.43 # much easier to see if a codec doesn't use the full dynamic range that way 14.48.23 # LinusN: Some manipulations are read-modify-write, some are not 14.48.47 # preglow: I don't use playlists either, I just "play" the parent directory. I think you need to enable the "recursively add to playlist" option though. 14.48.58 # right 14.49.09 # i haven't played too much with the options either :P 14.49.22 # The point is that RTIM must be handled similar to RC, i.e. set to 6 clks before transition to cpufreq_max, but reset to 3 clks after unboosting 14.49.27 # Just sounds like another unneccessary option that complicates the playback engine. 14.49.33 # truth to be told, i dont listen that much to my player any more 14.49.37 # since i seldom travel 14.49.37 # amiconn: yes 14.49.48 # still enjoy programming for it, though 14.49.56 # That's also why the cpufreq_idle setting needs two accesses to DCR 14.50.37 # Before unboosting, we need to set RC to the idle value, but not yet set RTIM to 3 clks, because it might be that we come from cpufreq_max 14.51.04 # Slasher: btw, do you have any idea why the low watermark boost isn't done in debug builds? 14.51.10 # Slasher: it skips all the time 14.51.27 # ...and interrupts aren't disabled during frequency transition, so sdram accesses might happen 14.51.30 # it boosts when the buffer is completely empty, but not before 14.52.14 # preglow: really? 14.52.26 # it works fine here (has always been worked) 14.52.26 # Slasher: really 14.52.31 # weird.. 14.52.34 # Slasher: linuxstb tried it as well 14.52.45 # Hmm, i haven't tried the newest build 14.52.49 # Slasher: it always worked for me as well, so must be a recent change 14.53.13 # And can't compile at the moment because i have some new crossfade code that doesn't compile yet :) 14.53.18 # hehe 14.53.22 # what's it do? 14.53.23 # oh, interesting 14.53.41 Nick linuxstb__ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net) 14.53.56 # preglow: it provides the following options: crossfade enable, crossfade duration, fade in delay, fade in duration, fade out delay and fade out duration.. 14.54.04 # ahh, right 14.54.06 # Hopefully that's enough configuration for cf :) 14.54.14 # should be, yes 14.54.18 # Imho it's too much ;) 14.54.27 # :D 14.54.32 # should satisfy the crossfade heads, at least 14.54.37 # i hope so 14.54.39 # i never use it myself 14.55.05 # perhaps when i begin listening to single tracks instead of albums one day 14.55.11 # Is there an option to only crossfade on shuffle? Or is that one option too much? 14.55.32 # well, it's a bit hard for the playback engine to know if a playlist is shuffled, i think 14.55.42 # it would need to check metadata 14.56.25 # and btw, any reason why mp3data.c is in firmware? 14.56.33 # linuxstb: not at the moment but that sounds good to add also 14.56.40 # i think the firmware and apps semantics need some fixing in places 14.56.54 # preglow: That's how it's always been for the Archos - the mp3 functionality was considered part of the firmware. 14.57.13 # yeah, i know, but it fits really badly for iriver 14.57.15 # But I'm sure the "elders" have expressed a willingness for it to be moved. 14.57.26 # i could have implemented stereo settings and playback speed long ago if it wasn't for this 14.57.30 # (they will no doubt correct me if I'm wrong). 14.58.46 # preglow: move it then 14.59.07 # but then you have to move the archos playback engine as well 14.59.29 # which is something we should do anyway 15.00.13 # don't think i'm the right man for that job, i'll undoubtedly screw something up 15.00.21 # yes you would :-) 15.00.49 # since it probably a bit more work than just moving some files 15.00.57 # yup 15.07.42 Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 15.15.37 # flac.c has tons of unused iram! 15.16.13 # well, over 10kb at least 15.16.39 # amiconn: is there any chance of rockbox using your 64 bit muls instead of gccs? i see it's used pretty much in all our codecs 15.22.26 *** Saving seen data "./dancer.seen" 15.23.21 Quit linuxstb (Read error: 110 (Connection timed out)) 15.31.25 # linuxstb_: i get an error when i try to encode a 24 bit wav to flac, anything special i need to do? 15.34.22 # right, i actually saved it as floating point 15.38.10 # That's the problem. 15.38.36 # You can find some 24-bit FLACs at www.archive.org in the live music archive. 15.38.49 # But most will also be 96KHz. 15.38.58 # Which is pushing Rockbox a little too far. 15.41.46 # I downloaded some 24-bit wav's from a site, but I can't find it anymore. 15.44.09 # here: http://www.soundsonline.com/sophtml/details.phtml?sku=EW-165 (audio demos) 15.45.32 # I've now moved most of the FLAC codec into IRAM (using ICODE_ATTR), and 24-bit playback is now at about 60% boost. It wasn't quite realtime before. 15.46.25 # markun 15.47.06 # preglow: Do you know how I could move your lpc_decode_emac() function into IRAM? Using ICODE_ATTR on the function prototype doesn't work. 15.48.34 Quit webguest82 ("CGI:IRC (EOF)") 15.58.01 Quit Kohlrabi ("Leaving") 16.15.28 Quit XShocK (Remote closed the connection) 16.16.31 # yes i do 16.16.48 # gimme a sec 16.17.00 Quit linuxstb_ (Read error: 104 (Connection reset by peer)) 16.17.37 Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 16.17.42 # .section .icode,"ax",@progbits 16.17.46 # instead of .text, or whatever i use 16.18.02 # and that's the only place you need to change anything 16.20.01 # linuxstb_: i'll try to make a optimised 24 bit lpc routine now 16.20.57 # a bit weird that putting all code in iram affects it that much, i would have thought the flac codec so small that it would be cached most of the time 16.21.10 # but of course, there's always other threads 16.22.55 # It doesn't hurt - we're wasting the IRAM otherwise. 16.23.07 # linuxstb_: 24 bit 96khz audio is not too much for rockbox, at least it shouldn't be after i've made an assembler version of that lpc routine 16.25.10 # I'll find some 24/96 files on www.archive.org for testing then :) 16.25.30 Join tvelocity [0] (n=tony@84.254.11.113) 16.26.05 # how much of iram is availible ? 16.26.08 # Here's a 24/96 FLAC show: http://www.archive.org/audio/etree-details-db.php?id=29456 16.26.43 # merbanan: 96KB is currently split into 48KB for the codecs, 9KB for the stack used by codecs, and the rest for other parts of Rockbox (mainly stacks I think). 16.27.39 # linuxstb_: only main stack and codec stacks are iram 16.30.04 # Should I commit my ICODE changes for FLAC? 16.30.15 # sure, why not 16.30.38 # Everything in libffmpegFLAC is now in IRAM - 43844 bytes 16.30.48 # so still room for the other lpc routine 16.31.04 # well, at least it should 16.32.11 # i'm thinking of various schemes on how to do it 16.32.33 # i think i'll end up doing to emac passes, with a macsr change inbetween 16.32.39 # two emac passes, even 16.32.51 # OK, that's now in CVS. 16.39.29 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 16.43.05 # Oops. Trying to play a 24/96 FLAC causes Rockbox to freeze... 16.44.21 # ahh, yes, there's that 16.44.29 # rockbox doesn't support 96 khz yet 16.44.38 # it supports everything up to 65536hz :-) 16.44.53 # don't know why it freezes, though 16.44.56 # <_FireFly_> 1bit is missing ;) 16.45.10 # <_FireFly_> to support 96khz 16.45.11 # i think i'll use a 64 bit mul for the delta calc 16.45.26 # _FireFly_: yes, but if i give it one more bit, the resampling will be slightly more inaccurate 16.46.07 # <_FireFly_> hmm then we have maybe a problem 16.46.18 # no, no problem, i can just use a 64 bit mul 16.46.59 # <_FireFly_> or that 16.47.57 # the core probably uses that some other place already, so shouldn't be a problem 16.48.09 # linuxstb_: exactly how does it freeze? 16.51.07 # linuxstb_: that's weird, i only the fixed predictor frames in my 24 bit file 16.51.16 # linuxstb_: even in my -8 encode 16.54.00 Join linuxstb__ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 16.54.08 # I select the file, the WPS displays, but then it feezes before any sound is heard. 16.54.15 # It's possible it's a FLAC bug - but the block size and frame size are within limits 16.55.21 # You can download my test file (80MB) from here: http://www.archive.org/download/spr2005-07-22.lsd2.flac24/spr2005-07-22t01.flac 16.55.44 # i'm leeching the fourty meg one now 16.56.05 # My ADSL may be unreliable, but the 8Mbit/s downloads are useful. 16.56.09 # that's all i can take on this piece of moody shit adsl line without going mad 16.56.21 # i've got about 6mbit download 16.56.24 # but it's a bit up and down 16.56.36 # I think I managed about 150KB/s from www.archive.org 16.56.44 # 120 here 16.57.02 # i liked my 100mbit better :/ 16.57.08 # I bet you did. 16.57.22 # 1.97MB/s on oleane.fr .. 16.58.02 # Maxime: What upload speeds do you get? 16.58.17 # ah in upload you speak? 16.58.33 # I'm on a 20M/1024K 16.58.39 # My connection is 8Mbit/s download and 512kbps upload. 16.59.41 # where you are, does ADSL2+ exists? 17.00.03 # Not yet, but I think it's coming in the next few months. 17.00.12 # I'm in London. 17.00.17 # ok 17.00.21 # (i'm in Lyon) 17.06.36 Join FireFly_ [0] (n=FireFly@p54A46225.dip.t-dialin.net) 17.06.36 Quit _FireFly_ (Read error: 104 (Connection reset by peer)) 17.06.53 Nick linuxstb__ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net) 17.07.01 Nick FireFly_ is now known as _FireFly_ (n=FireFly@p54A46225.dip.t-dialin.net) 17.07.52 Quit linuxstb_ (Read error: 110 (Connection timed out)) 17.11.06 # so, no one's got 24 bit flac files at ordinary sample rates? 17.13.07 # Yes, I've got a 24-bit/44.1KHz file. Should I upload it somewhere? 17.13.37 # dcc/upload/mail/whatever suits you best 17.14.51 # Uploading now. Will PM the URL. 17.15.06 # ETA about 5 minutes. 17.16.28 # goodie 17.22.15 # i've had a look at libogg, and thus far it looks like memory copying hell 17.22.29 *** Saving seen data "./dancer.seen" 17.23.02 # preglow: there have been plans (for years) to switch to libogg2 17.24.21 # Tremor's ogg handling is based on it, http://svn.xiph.org/trunk/ogg2/ 17.24.35 # is it, now 17.25.01 # i was just hoping that container format parsin wouldn't add any overhead 17.25.02 # Don't know if it's better. Maybe it's not so difficult to get libspeex to work with it. 17.25.13 # but with libogg it seems like it's going to 17.25.21 # markun: my first try will be to get flac working with it 17.25.35 # libogg or libogg2? 17.25.49 # i'll have to have a further look before i decide on that 17.25.55 # the libogg2 api is still under discussion 17.26.33 # i wonder what happened to theora 17.27.26 # btw I made a joining function for arabic. Don't know if anyone is interested. 17.28.12 # I've been googling for an arabic iriver forum, but didn't find one. 17.28.22 # seems ogg2 is zerocopy, yes 17.28.50 # great! I wonder how much it differs from Tremor's ogg. 17.28.58 Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 17.31.25 # Is ogg2 just a different API to the same format, or a new format? 17.31.38 # different api 17.34.49 # preglow: Check your email for that FLAC file URL. 17.35.45 # goodie 17.35.46 # thanks 17.41.41 Quit linuxstb (Read error: 110 (Connection timed out)) 17.41.57 Nick linuxstb_ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net) 17.47.23 # preglow: Perhaps it's possible to put the 64 bit mul in a lib, with the same name as gcc knows it (muldi3 iirc), and link against this lib before the default libs. I'm not sure, never tried to replace standard library routines so far... 17.47.41 # amiconn: the routines are in libgcc, so it would have to be before that 17.48.02 # amiconn: but otherwise, i think we should do it, your routine beats the gcc one by far 17.49.25 # Yeah, it's both smaller & faster 17.50.01 # Would putting it in the codec lib work? 17.50.46 # <_FireFly_> amiconn: what about the accuracy?? 17.50.51 # The name is __muldi3 17.51.03 # _FireFly_: It's bit accurate 17.51.25 # <_FireFly_> better as the gcc one 17.51.34 # If it means anything, the code in the codec lib appears before libgcc in the map files for codecs. So does that mean it gets linked first? 17.52.32 # _FireFly_: It's the same accuracy, it has to be 17.52.50 # We're talking about the 64*64->64bit integer multiplication 17.56.20 # IIUC, the FLAC routine just needs a 32*32->64-bit multiplication. 17.57.34 # linuxstb: yes 17.57.46 # i'll just use both modes of the emac unit 17.57.54 # That's a different thing, and it seems gcc doesn't use a special routine for that, although it probably has such special library routines (if I read the gcc source properly) 17.58.58 # Which codecs need a 64x64->64 mult? 17.59.38 # The 32*32->64 we're doing using both emac and mulu requires the emac to be in fractional mode, so it isn't generic, and it's really only a 32*32->63 bit mul, which may hit us in exactly one case 18.00.56 # Afaik none of the optimised codecs use 64*64->64 for actual decoding, but it's still used for some purposes, also in the core. 18.03.27 # On a different subject, now that some codecs are comfortable running at 45MHz, any idea how much more power can be saved by optimising them further? 18.05.51 # every cycle counts 18.06.27 # the more time the cpu can spend in the idle sleep mode the better 18.06.27 # indeed 18.07.18 # ok, now let's hope that flac never uses the top bit in the accumulator 18.07.48 # amiconn: would finding the top bit in the mul be much trouble? without performing another mul, that is 18.08.10 # afaik, the top bit wil only be used if the two numbers in the mul are 0x80000000 and 0x80000000 18.11.54 # yep, and it's possible, sacrificing 4 extra cpu cycles (5 if the correction is to be made) 18.12.06 # Looking at the code (decode_subframe_lpc), the coefficients seem to only be a maximum of 15 bits. 18.12.19 # So unless I'm misunderstanding, it's a 15-bit x 32-bit multiplication. 18.15.41 # really, now 18.16.26 # i wonder if i should even try to do a fraction emac mode solution only 18.16.52 # if i could do that, 24 bit wavs would decode just as fast as 16 bit wavs 18.17.07 Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU) 18.17.21 # s/wav/flac/ ?? 18.17.27 # yes :) 18.17.49 # Do you agree that it's a 15x32 multiplication? 18.20.05 Join z0rr0 [0] (i=z0rr0@217.30.249.24) 18.23.07 # most certainly looks like it, yes 18.23.58 # but the other numbers might be anything then 18.25.30 # Yes, anything up to 32-bits I think. 18.26.03 # Even if the audio data is only 24-bit 18.27.00 Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) 18.27.16 # and i wonder what range qlevel is in 18.27.27 # seems like it can be anything up to 32 18.27.41 # in which case the fractional mode might end up a bit tricky 18.28.07 # Yes - qlevel is 5 bits 18.29.02 # Do you know if wavpack has a similar routine? 18.29.16 # hmm, no, wavpack does things sligtly differently, i believe 18.29.27 # but it only uses frac mode, so it's got to do something similar 18.29.37 # i haven't talked to david bryant for quite a while, so don't know 18.30.04 # he's busy with a new version of wavpack, i think 18.34.28 # so, if qlevel is something around 32, i can get rid of 17 of them by scaling the coefs to 32 bits 18.35.46 # one of them also vanishes in the way fractional mode works, so i've got 16 left to worry about, which would yield 16 bits of output precision in the worst case 18.36.05 Join muesli_- [0] (i=muesli_t@Bbc88.b.pppool.de) 18.36.14 Quit z0rr0 ("Bye Bye") 18.43.46 # but if sixteen bit output precision is ok, it might work 18.48.12 # It would be much nicer to get the full 24-bit output - it's controversial to have an inaccurate FLAC decoder. 18.49.13 # yep, than that's what i'll do 18.49.20 # this is how wavpack handles it, btw 18.49.48 # it doesn't guarantee that the lowest bits are accurate in a high res file 18.49.54 # that is, our implementation of wavpack 18.50.27 # Ah, so that's why it's the same speed as a 16-bit file. 18.53.59 Join Febs [0] (n=40be24f0@labb.contactor.se) 19.05.03 # indeed 19.06.58 # so, you think i should do it the proper and somewhat slower way for flac? 19.06.58 Quit akke ("CGI:IRC (EOF)") 19.07.21 # amiconn: will a 64 bit variable shift routine be big? 19.07.34 # left shift, that is 19.07.51 # Not really 19.07.59 # how many registers will it use? 19.08.04 # It's a sub, 3 shifts and an or 19.08.15 # i don't want to stack any variables :/ 19.08.30 # One additional register besides the operands 19.08.31 # and i've only got one register free at the moment 19.08.31 # argh 19.08.37 # that's one more than i have 19.08.38 # hrmph 19.09.08 # in the worst case, that is 19.10.12 # Does the DSP just truncate to 16-bits at the moment? 19.11.30 # no 19.11.35 # well, at the end it does 19.11.37 # after processing 19.11.49 # and there isn't much processing done at the moment, admittedly... 19.11.49 Quit muesli_- (Read error: 110 (Connection timed out)) 19.12.04 Join thegeek_ [0] (n=thegeek@s175a.studby.ntnu.no) 19.13.44 # the whole point of having more than 16 bits precision is so some kind of processing can benefit from it 19.13.50 # It's up to you, but I think it would be nice to have the option of true 24-bit output - just because we can. 19.14.00 # well, i certainly agree on that 19.14.24 # i'll just see if a can free a register somewhere 19.16.08 # well, i guess i can free the fetch variable and just add an extra move before the accumulator chains 19.16.12 # chain 19.16.47 # On a different subject, I've moved all of libalac into IRAM - there is still about 8KB left... We have too much IRAM for some of the codecs. 19.18.03 # preglow: If you wanna see the 32*32->64 top bit correction: http://amiconn.dyndns.org/muls323264.S 19.19.32 # linuxstb: not exactly a crying matter 19.21.44 # amiconn: of course, i didn't think about the emac unit setting overflow true 19.22.32 *** Saving seen data "./dancer.seen" 19.26.31 # amiconn: what's up with the trap? how is that possible? 19.26.57 # i thought trap was a one-word instruction 19.27.10 # No, there is trapf, trapf.w and trapf.l 19.27.28 # Check CFPRM.pdf (it's called tpf there) 19.27.46 # ahh, so it's tpf 19.28.47 # It's a bit ugly to use it the way I do here, because you can't just write the instruction, gas will (of course) complain about the missing operand 19.28.48 Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-130-062.pools.arcor-ip.net) 19.28.58 Quit thegeek (Read error: 110 (Connection timed out)) 19.29.24 # So either the trapf.w/trapf.l, or the shadowed instruction needs to be given as hex word(s) 19.30.04 # It's easier to reach the shadowed instruction with the first method 19.31.08 # amiconn: I made a function for proper arabic. It's about 6k compiled and we are over the limit already. Would you like to look at making rockbox self-extracting? 19.31.16 # amiconn: but that was a bit clever 19.40.23 Join muesli_- [0] (i=muesli_t@Bbc62.b.pppool.de) 19.41.29 Quit muesli_- (Client Quit) 19.47.34 Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 19.48.58 Quit linuxstb (Read error: 104 (Connection reset by peer)) 19.50.02 Nick linuxstb_ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net) 19.50.52 # linuxstb: Are you closer to real-time decoding with aac? 19.51.47 # markun: Yes, perhaps, but not now. As mentioned, I'd prefer to wait with unicode commit until the gui transition is done 19.52.47 # Hopefully the code size decreased enough by then to allow for unicode support without slef-extraction 19.53.31 # About your arabic function: Imho 6KB is a bit heavy for it to reside in the core - just for one language 19.53.56 # ARe there many arabic rockbox users? What if other languages need simiar functions? 19.55.02 # There's an idea I'm thinking about for quite a while: rockbox should probably have language specific "plugin" code 19.55.02 # I don't know of any arabic rockbox user. Googling for arabic pages with rockbox in it did not give any useful results. 19.56.16 # My original idea was to use it for the number-voicing algorithm, because that's different per language 19.56.42 Join Lear [0] (n=chatzill@h73n11c1o285.bredband.skanova.com) 19.56.55 # For example, 21 is "twenty one" in english, but the equivalent of "one-and-twenty" in german 19.57.41 # Should the arabic language plugin be loaded loaded when an arabic string is found or only when the user selects it? 19.58.12 # Hmm, arabic strings in filenames are a problem with that concept... 19.58.28 # My idea was to use it depending on the loaded .lng file 19.59.13 # markun: We're (preglow and I) are getting a little closer. But it's such a big codec, it's hard to optimise. 19.59.56 # amiconn: If you would like to take a look at the test code: http://130.89.160.166/rockbox/arabjoin.c 20.01.17 # linuxstb: It would be nice if a better coded aac decoder would be found (like you did for flac) but I guss the chances of that happening are very small 20.01.30 # markun: there's the helix decoder, which we can't use 20.01.32 # There is one - the helix/real decoder. 20.01.34 # that's almost certainly better 20.02.53 # to optimise aac further, i'll need to dig into the source a bit and see how it works 20.04.02 # There is always the ISO reference decoder. I don't know what license that's released under though. 20.04.32 # ahaha 20.04.34 # don't think about it 20.04.39 # the reference decoders are always wildly shitty 20.04.55 # But so is libfaad as far as we are concerned. 20.05.03 # not _that_ shitty, i'm sure 20.05.07 # but feel free to check it out 20.05.26 # anyways 20.05.39 # getting libmad to work as fast as it does today didn't exactly happen overnight either 20.06.05 # erm 20.06.17 # i've a question, i've had a strange issue this afternoon 20.06.33 # I was listening to radio, then I put one MP3, then I had the sound of the radio AND the mp3 20.06.46 # you probably exited the radio wrongly 20.06.50 # yeah 20.06.54 # this is funny so :p 20.06.55 # lol 20.07.17 # and I had a *PANIC$ 20.07.49 # that's not intended, actually... 20.07.50 # listening to a mp3, then opened a jpg, (no sound when the JPG appears), and then when i exited the JPG, *PANIC* 20.08.05 # you don't use any jpeg related patches? 20.08.16 # no 20.08.26 # it's the daily build from this morning 20.09.47 # markun: This is really 6KB of compiled code? Or do you mean it is 6KB as a test program? 20.10.26 # I don't believe the actual code is 6KB, and btw, you can save half of the table size by using short instead of long 20.10.41 # yes, true. 20.11.01 # I was a bit pessimistic (and stupid) I guess 20.11.11 # With shorts, the table should be a little above 1KB, with the big last part not #if'ed out like it is now 20.12.21 # preglow: You're right about the AAC reference code. I've now deleted it. 20.13.28 # I did some work on AAC yesterday to strip out most of the mallocs and replace with static buffers. Once I tidy it up, I'll commit it. I couldn't find any speed improvements though. 20.14.44 # (great the JPG viewer tho.. ^^) 20.14.59 Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) 20.20.07 # amiconn: With shorts and the big table included, arabjoin.o is 2732 bytes 20.21.30 # The .o doesn't tell much about the final code size. 20.21.53 # You would need to link, and then check the .map and/ or the binary 20.21.57 # hmm, i wonder if can calculate something in acc0 using frac mode, then swap to integer mode, calculate something in acc1, then get both results correctly 20.22.16 # Size can also vary significantly depending on the target 20.22.37 # (not the table though) 20.26.37 # amiconn: hmm, what do you think would be faster, fetching the entire sample array twice and doing the 64 bit mac in two passes, one with frac and one with integer mode, or instead fetching the once, and simulating the lower mac operation with muls and add? 20.26.54 # fetching the samples once, that's supposed to be 20.28.44 Join godzirra_ [0] (i=shawn@c-24-131-13-213.hsd1.va.comcast.net) 20.29.09 Quit godzirra (Nick collision from services.) 20.29.14 Nick godzirra_ is now known as godzirra (i=shawn@c-24-131-13-213.hsd1.va.comcast.net) 20.30.26 # i tend to think the first, since the muls operation uses the emac unit on mcf5249, and this might stall the mac chain, but i'm not sure, one source says a mac.l operation only uses one cycle 20.30.29 # If you mean fetching from DRAM, then fetching once should definitely be faster 20.30.29 Quit LinusN ("disconnecting from stoned server.") 20.30.54 Quit Slasher (kornbluth.freenode.net irc.freenode.net) 20.30.54 NSplit kornbluth.freenode.net irc.freenode.net 20.31.13 Quit markun (kornbluth.freenode.net irc.freenode.net) 20.31.41 # iram 20.34.09 # Sounds like a small test is necessary 20.34.31 NHeal kornbluth.freenode.net irc.freenode.net 20.34.31 NJoin markun [0] (n=karl@bastards.student.ipv6.utwente.nl) 20.34.44 NJoin Slasher [0] (i=miipekk@ihme.org) 20.35.22 # can't be bothered to isolate the code and do a test 20.35.36 Quit linuxstb (Read error: 104 (Connection reset by peer)) 20.35.38 # i'm almost convinced the first method is faster 20.36.02 # 'almost' isn't 100% ;-) 20.36.12 Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 20.36.12 # it is if you can't be bothered do to tests :P 20.36.31 # Well, memcpy is all about tests, tests, tests... 20.36.41 # yup, and it's a bit more important for memcpy as well 20.36.47 # You see why it takes that long :-) 20.36.54 # sure 20.37.34 # amiconn: hmm, from i can see in your libmusepack shifting routine, you need two additional registers for shifting 20.37.49 # Not necessarily 20.38.15 # You said you need variable shift. One of the additional registers is the shift count 20.38.58 # well, i see t2 and t1 as well 20.39.23 # Yes, but that's not only a 64 bit left shift. 20.39.36 # no? 20.39.52 # It even is not a 64 bit shift at all. 20.41.19 # The shift part is a 'shortened' 64 bit right shift, in that we only need 32 bits of the result 20.42.32 # that's what i want as well 20.44.23 # t1 is the result. You can reuse the same register that's used for the 'y' input 20.44.35 # (if you don't need it again afterwards) 20.45.56 # i've got three registers 20.46.05 # two of them contains a 64 bit number, the last one is free 20.46.21 # the shift amount is contained in another register 20.49.08 # It's possible to save one register (with some penalty) if it's allowed to destroy the shift count 20.49.21 # it's not 20.49.32 # It's possible to restore it, with some more penalty 20.49.58 # out of the 15 available registers, five contains parameters i need to keep, among them the shift count, eight contain coefs, and the three that are left are the ones i'm speaking about 20.50.23 # ehh, that's wrong :> 20.50.50 # 5+8 = 13, only 2 registers left 20.50.52 # yes, four contain parameters 20.51.06 # i didth the order parameter, since the loop is unrolled and order thus hard coded 20.51.07 # ditch 20.51.11 # Where do you get your 64 bit data from? 20.51.21 # two sets of mac.l chains 20.51.29 # one for the high bits, one for the low bits 20.51.41 # So, from the %accn registers? 20.51.44 # yup 20.51.55 # ahh, right 20.51.59 # Then it's possible, by reading one value twice 20.52.06 # (first time without movclr) 20.52.12 # yes, necessarily :) 20.52.32 # You want to shift right? 20.54.28 # yup 21.02.40 Quit DangerousDan (Read error: 110 (Connection timed out)) 21.06.47 # * preglow ponders 21.07.22 # * amiconn wonders 21.07.36 Nick Seedy is now known as Seed (i=ben@85-64-200-85.barak-online.net) 21.07.46 # * amiconn wonders whether handling the low and high bits separately will work 21.08.39 # i've got more bits available in seven of the eight unrolled cases 21.08.58 # registers, yes 21.12.08 # but not so in the order > 8 case 21.12.15 # which will undoubtedly be fun no matter how i do it 21.14.23 Quit _FireFly_ ("Leaving") 21.15.37 # amiconn: in your tests, do you just use the tick counter, or something more high res? 21.15.42 Join muesli_- [0] (i=muesli_t@Bc0a1.b.pppool.de) 21.16.04 # Just the tick counter, with enough repeats to make it sufficiently high precision 21.16.08 # yes 21.20.15 # In the 16 bit routines, you only need to preserve 11 registers within the loop 21.20.21 # re 21.20.55 # .. 8 coefficients, a0, d0 and a1. So what is the 4th parameter in the 24 bit case? 21.21.30 # amiconn: eleven registers? i need to preserve four parameters, plus eight coefs, worst case 21.22.10 # amiconn: i preserve d0, d1, a0, a1 21.22.27 # Why a1? It's only needed at the start to load the coefficients... 21.22.35 # :-) 21.22.36 *** Saving seen data "./dancer.seen" 21.22.51 # yes, valid point, valid point 21.22.54 Join linuxstb_ [0] (n=5343d4aa@labb.contactor.se) 21.24.05 # You can even reuse a1 in the movem 21.24.33 # indeed i can 21.24.44 # so i get a more general dx register instead 21.25.03 Join bluebrother^ [0] (n=c28@nat-ph3-wh.rz.uni-karlsruhe.de) 21.29.23 Join arkascha [0] (n=arkascha@xdsl-195-14-222-42.netcologne.de) 21.30.02 Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) 21.34.21 # preglow: In your 32-bit LPC routine, is it possible to unroll any of the higher (i.e. > 8) orders? 21.42.48 # TiMiD: I found another problem with your new code: If you put a new rockbox version on the drive, when the request "Boot changed. Reboot?" appears, the status bar isn't cleared 21.42.50 Quit linuxstb (Read error: 104 (Connection reset by peer)) 21.43.25 Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 21.49.31 Quit linuxstb_ ("CGI:IRC (Ping timeout)") 21.51.55 Join linuxstb_ [0] (n=5343d4aa@labb.contactor.se) 22.01.54 Quit Lear ("Chatzilla 0.9.68.5.1 [Firefox 1.5/undefined]") 22.06.56 Join RotAtoR [0] (n=e@12-210-82-91.client.insightBB.com) 22.09.29 Join Midgey34 [0] (n=chatzill@c-67-172-68-52.hsd1.mi.comcast.net) 22.28.34 Quit Kohlrabi (Read error: 104 (Connection reset by peer)) 22.28.54 Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-129-112.pools.arcor-ip.net) 22.33.07 Join ashridah [0] (i=ashridah@220-253-122-123.VIC.netspace.net.au) 22.36.27 Quit muesli_- (Read error: 110 (Connection timed out)) 22.36.28 # linuxstb_: perhaps 9 22.36.54 # linuxstb_: i can unroll some instances in the older 16 bit version for sure 22.37.07 # up to ten 22.37.13 # should i? 22.38.13 # i hate code like this, tons of duplicated code everywhere 22.38.46 # amiconn: it's not a bug, it's wanted ... 22.39.36 # preglow: I've just done a quick analysis of some "flac -8" files, and the > 8 orders are the majority in the file. Order 12 is the most common. 22.39.47 # I thought it would be more logicla to do like that with all text outputs 22.39.53 # So yes, I think it's worthwhile. 22.40.22 # I wouldn't worry about duplication either - I know it's untidy, but we have IRAM to spare for FLAC. 22.40.48 # TiMiD: Hmm.... 22.41.02 Quit dpassen1 () 22.41.26 # since it's handled generically anyway ... 22.41.36 # It looks rather odd, and the next message doesn't do that 22.41.37 # linuxstb_: well, i can't unroll orders that high 22.41.41 # (the rolo thing) 22.42.04 # preglow: I know. 22.42.42 # the rolo message ? 22.42.52 # you mean when it's rebooting ? 22.43.50 # yes 22.44.30 # i need to keep three parameters and need two working registers, 15 - 5 = 10, which is the highest order i can unroll 22.44.30 # i can unroll all orders, sure, but then i need to start loading coefs all the time as well, and the advantage vanishes 22.44.39 # The reboot request keeps the status bar, but the rolo message does not 22.44.39 # That's one reason why I thought it's a bug 22.44.39 # The other reason is that it looks squeezed 22.44.43 # I didn't looked at that part of the code 22.45.04 # so I didn"t changed it 22.45.27 # Related to that, it's probably a good idea to have a request widget 22.45.45 # ...at least for the common yes/no requests 22.46.12 # hmm like the other one used for "reset settings" 22.46.14 # ? 22.46.52 # Yes. Iirc there are more yes/no requests than just these 2 22.47.15 # I didn't thought about that but it's surea good idea :) 22.47.28 # I'm doing right now a generic select widget 22.47.39 # fthe menus 22.47.53 # (for the ) 22.48.00 # This idea is even older than your gui work, just nobody implemented it yet 22.48.43 # there is something like this in settings.c 22.49.15 # but lot of code is duplicated since it handles bool, int, strings ... 22.49.49 # anyway, about the statusbar, do you think it should be removed ? 22.49.59 # I'm curious how much will be gained when you are at the point where you can remove the old statusbar code etc 22.50.10 # I don't know about that 22.50.35 # 1kb of c code less >> binary smaller by 100 bytes 22.50.42 # I know that there is still some work left. Settings, radio screen recording screen, keyboard.... 22.50.43 # not very efficient ;) 22.50.57 # Well, that varies a lot 22.51.01 # seems we've got 64 bit flac, yes 22.51.10 # 24 bit, at that 22.51.19 # * linuxstb_ cheers 22.51.23 # I was about to ask... 22.51.42 # i got diverted for an hour 22.51.50 # I try to do the work so that we can remove the old functions the sooner possible 22.52.07 # there is also len0x and firefly helping 22.57.44 # preglow: You could unroll the residual handling in the default lpc case: a sequence of 3 move.l -(%a2),.. / mac.l pairs, dispatched via a jumptable 22.58.00 # And you waste an instruction and a move :) 22.58.13 # I mean, a move instruction and a register 22.58.36 # amiconn: i could just use duffs device for the residual handling 22.58.47 # ?? 22.58.48 # at least the assembler equivalent of duffs device :) 22.59.20 # three mac instructions, and just jump to the one giving me enough macs for the residual 23.00.34 # Yes, that's what I mean, but the coefficient fetch is also variable 23.01.43 Quit Midgey34 (Remote closed the connection) 23.02.15 # instead of move.l %d2, %d3 / moveq.l #3, %d4 / and.l %d4, %d3 23.02.17 Quit ender` (Read error: 104 (Connection reset by peer)) 23.02.18 # just use moveq.l #3,%d3 / and.l %d2,%d3 23.02.33 # The and operation is commutative 23.03.19 # yes, yes it is 23.17.08 Nick paugh is now known as AliasAle (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) 23.21.03 Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 23.22.04 Join linuxstb__ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 23.22.37 *** Saving seen data "./dancer.seen" 23.23.48 Join _Nilisco [0] (i=nilisco@wrath.shellfx.net) 23.24.46 Quit matsl (Remote closed the connection) 23.26.42 Quit linuxstb_ ("CGI:IRC (Ping timeout)") 23.27.30 Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 23.31.03 Quit Febs ("CGI:IRC (EOF)") 23.34.27 Quit Nilisco (Read error: 110 (Connection timed out)) 23.35.51 # amiconn: when you said i could reuse a1 in the movem 23.36.22 # did you mean the following is possible: movem (%a1), %d0-d7/%a1-%a6 ? 23.37.06 # yeps 23.37.31 # and it is! funnily enough, it turns out i screwed up some place else 23.37.37 # who'd have thunk it 23.37.50 Quit linuxstb (Read error: 110 (Connection timed out)) 23.42.07 # i must be doing something completely moronic here 23.43.00 # tell me 23.43.07 # www.pvv.org/~thomj/rockbox/snip 23.43.27 # shouldn't that do what i want? shift right %d1 times and return the bottom part of the shift 23.43.28 Quit linuxstb__ (Read error: 110 (Connection timed out)) 23.46.57 # yes 23.47.13 # then i wonder what the static bursts i guess mean 23.47.18 # something else, i hope 23.47.25 # provided qlevel <= 32 23.48.16 # yes, it is 23.48.29 # qlevel can't be even close to 32 23.49.00 # the mul result can be 32 + 15 big, shift that anything close to 32 bits, and the result sure as hell isn't 24 bit any longer