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

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

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

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2005-11-03

00:00:16preglowhaha
00:00:33 Quit ender` (Read error: 104 (Connection reset by peer))
00:03:47amiconnLinusN: Do you think the patch should enabled continuous page mode as well?
00:04:08LinusNsure, why not?
00:04:49len0x@Moos - are you not getting my msg ?
00:05:09Moosnope ;)
00:05:33tucozgood night
00:05:37 Part tucoz
00:06:46len0x@weird - I sent like 10 :)
00:06:57Moos:D
00:07:12Moosare you freenode registrated?
00:07:19len0xnope...
00:08:23Moostry 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:22topblokehey can simulator builds of rockbox be downloaded anywhere?
00:10:18LinusNtopbloke: no, you build them yourself
00:10:54topblokeoh they used to be on the site
00:10:56topblokewhat happened
00:12:32LinusNi dunno, maybe we didn't see the point in providing them
00:12:51topblokeok cool
00:13:09LinusNwhat would be the point?
00:13:16topblokeit lets people without a target play around with rockbox
00:13:24topblokewithout messing with compling
00:14:13topblokei wanted to see how rockboy runs on an iRiver
00:14:54Bagderyou'd need to run on target to see that
00:15:00topblokeoh ok
00:15:12Bagderas the simulator doesn't run with the same speed
00:15:42topblokeis it playable at all on a real iRiver ?
00:15:51LinusNsome games are
00:15:58LinusNlike pokemon
00:16:04topblokeoh sweet
00:16:11topblokepokemon i love that ! :)
00:16:33LinusNsuper marioland is quite playable as well
00:16:44LinusNno sound though
00:17:01topblokehow about on a archos recorder?
00:17:12LinusNhaven't tried
00:17:27topblokeok thanks
00:17:41LinusNtime to sleep
00:17:44LinusNcu all
00:17:51topblokebye
00:17:52 Part LinusN
00:19:46preglowthink i'll take his example
00:19:48preglownight all, later
00:20:33len0xanyone 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:35DBUGEnqueued KICK Midgey34
00:27:35DBUGEnqueued KICK Midgey34_
00:27:35***Alert Mode level 2
00:27:35DBUGEnqueued KICK Midgey34__
00:27:35DBUGEnqueued KICK Midgey34___
00:27:35***Alert Mode level 3
00:28:14amiconnLinusN: (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:07DBUGEnqueued 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:54DBUGEnqueued 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:00
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:00
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:57mannieyo, i was wondering if you guys had rockboy workin on the archos jukebox recorder..?
02:44:49 Quit mannie (Client Quit)
03:00
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:00
04:33:31 Quit paugh ("Leaving")
04:47:44 Quit RotAtoR ()
04:59:52 Quit topbloke ("bye")
05:00
05:17:14 Join XShocK [0] (n=XShocK@brewster.equinoxsensors.com)
05:22:18***Saving seen data "./dancer.seen"
06:00
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:36mrmagskeins 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:00
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:00
08:10:23B4gderhttp://hardware.slashdot.org/article.pl?sid=05/11/02/2055238&from=rss
08:10:31B4gder"Can Open Source Outdo the IPod?"
08:10:58B4gdertwo 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:36ashridahyeah, but you're forgetting that slashdot users have the attention span of gerbils, so they're perpetually amused by the clicky wheel
08:21:47B4gderhehe, yes
08:23:38ashridahi imagine the entire thread is full of morons going "oss will never come up with the clicky wheel!"
08:23:52B4gderyes, lots of that style
08:23:59ashridahand no actual discussion of reverse engineering, drm, or other issues facing it
08:25:16amiconnHaha, ""There is very little innovation left"
08:25:25 Quit solexx (Read error: 104 (Connection reset by peer))
08:25:26amiconnSomeone please ask our blind users...
08:25:33B4gderhaha
08:25:46B4gderapple sheep
08:26:16amiconnmorning, btw :)
08:29:52B4gderI 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:40B4gderZagor: http://forums.rockbox.org/index.php?topic=1737.0;topicseen
08:45:21B4gderthe Rockbox wikipedia article has its flaws
08:45:42B4gdersaid 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:03B4gderthat'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:25amiconnTiMiD: Are you around?
09:00
09:00:46ashridahheh. i love having flamewars with no-nothing overclockers :)
09:03:31 Part LinusN
09:08:29TiMiDamiconn: yes I'm here (for 5 minutes, no more)
09:19:27amiconnThere is a bug with the gui menu system and the voice ui
09:20:52amiconnWhen 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:01amiconnThis worked before...
09:22:20***Saving seen data "./dancer.seen"
09:22:52TiMiDok
09:23:08TiMiDI'll look at this this evening
09:23:13TiMiDnow I have to go ...
09:23:51TiMiDthis shouldn't be too hard to fix
09:25:05amiconnMaybe there's another problem.
09:38:59 Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-130-062.pools.arcor-ip.net)
10:00
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:00
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:31webguest19hi
11:16:21 Quit webguest19 (Client Quit)
11:22:21***Saving seen data "./dancer.seen"
11:30:44linuxstbMorning 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:06linuxstbBut I'm not sure how this test will end. What will happen when the battery runs out?
11:31:43linuxstbThe battery indicator is currently showing about 30%-40% full.
11:31:46 Join webguest82 [0] (n=3a4d50b4@labb.contactor.se)
11:31:57webguest82hello
11:32:28webguest82Connection does not become by irc program.
11:35:19Ricko.o
11:36:31webguest82:) I like Rockbox so.
11:36:57amiconnZagor: Installer builds are still not working ?!? :-((
11:39:59webguest82markun: Are you busy?
11:46:17webguest82What is wps?
11:56:02yngwiwps is "while playing screen"
11:56:57 Join LinusN [0] (n=linus@labb.contactor.se)
11:57:15LinusNamiconn: the innosetup scripts were lost in the twiki raid
11:58:48webguest82thanks
11:59:48amiconnLinusN: I have the scripts here. Zagor didn't mention they were lost when I first asked why the installer builds aren't working
12:00
12:03:38 Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de)
12:04:15LinusNamiconn: good, can you send them to me?
12:05:57 Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net)
12:08:21TiMiDamiconn: 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:37linuxstb_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:39yngwinothing
12:14:45yngwii think
12:15:05yngwiit runs until the power is too low for the harddisk to spin..
12:15:19yngwicorrect me if i'm not right with that
12:16:34 Quit linuxstb (Read error: 110 (Connection timed out))
12:17:01linuxstb_I guess I'll find out soon. But I'm already impressed - 10 1/4 hours and still running (flac -8 files).
12:17:18linuxstb_Battery looks about 1/3 full.
12:17:40linuxstb_Make that 1/4 full.
12:18:31yngwisounds 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:14DBUGEnqueued KICK cYmen
12:19:14DBUGEnqueued KICK cYmen_
12:19:14***Alert Mode level 2
12:19:14DBUGEnqueued KICK cYmen__
12:19:14DBUGEnqueued KICK cYmen___
12:19:14***Alert Mode level 3
12:19:16yngwibut 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:25DBUGEnqueued 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:09tucozlinuxstb_, 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:49LinusNtucoz: rockbox doesn't shut down at all, the hardware does it
12:28:56tucoz...and that a lithium-poly battery may be damaged if being <= 2.5 volts
12:29:24linuxstb_So it's safe to let it run until death?
12:30:07B4gder"battery university" even claims that liIo batteries should be kept at no less than 40% charge level
12:30:24B4gderhttp://www.batteryuniversity.com/parttwo-34.htm
12:30:31tucozlinuxstb_, 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:29B4gder" 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:05B4gder"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:26linuxstb(sorry, ADSL playing up again).
12:33:31TiMiDI've a problem with cvs
12:33:58TiMiDexport CVSROOT=:pserver:kevin@rockbox.haxx.se:/cvsroot/rockbox
12:34:05TiMiDcvs login
12:34:06TiMiDLogging in to :pserver:anonymous@rockbox.haxx.se:2401/cvsroot/rockbox
12:34:13TiMiDwhy is it anonymous ?
12:34:21tucozSo, 2.7 volts is perhaps a lower bound for voltage then?
12:34:26***Alert Mode OFF
12:34:36linuxstbTiMiD: Because you originally checked out those files anonymously?
12:34:46TiMiDhmm maybe
12:34:50tucozif the disk is still able to spin up at that voltage
12:34:54linuxstbcvs will look in a directory called "CVS" first to get the repository details. Look at the files in that directory.
12:35:21TiMiDyou are right :)
12:35:36linuxstbYou should just be able to edit those files manually.
12:35:51linuxstbBut it may be easier to check out a fresh copy, and then transfer your modified files to that copy.
12:35:51preglowlinuxstb: not too shabby a runtime for flac, if you ask me
12:36:00linuxstbpreglow: I'm very happy.
12:36:00preglowlinuxstb: is this with the stock battery?
12:36:15 Quit Kohlrabi (Read error: 110 (Connection timed out))
12:36:18linuxstbYes - a completely unmodified H140.
12:36:41 Quit cYmen___ (Connection timed out)
12:36:47preglowB4gder: given up on neuros, or? ;)
12:37:14tucozWhat is next for you codec-phantoms? mod, sid? That would be so cool.
12:37:15B4gdernot quite
12:37:17B4gderbut almost
12:37:24B4gderand a major lack of time
12:37:49yngwii'd really like to hear SID tunes on my iriver
12:38:33preglowtucoz: there's more than enough for me to do on the good old streaming formats yet
12:38:41preglowi don't consider any of them finished for release
12:39:13preglowat least some forum person says i've fixed the lame large enc_delay issue
12:39:52tucozit 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:28linuxstbpreglow: Does that mean that lame mp3 playback is perfectly gapless now?
12:41:00preglowlinuxstb: no
12:41:05preglowlinuxstb: more or less, at least
12:41:12preglowlinuxstb: but seeking for one breaks it
12:41:45preglowbut that should be easily fixable
12:41:47tucozpreglow, that is fully understandable. Sids and mods (when that time comes) is just the frosting of the cake :)
12:42:23preglowi'd like mod support
12:42:37preglowi'd also like spc support
12:42:48preglowsids would of course be nice too
12:42:49tucozspc? is that speex?
12:42:54preglowspc is snes music
12:42:57tucozhehe
12:44:20preglowtucoz: 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:07tucozah, that is true. Hmm, what is the problem with DUMB? floating point or something else?
12:46:53tucozexcept from the codec api stuff
12:48:02TiMiDis it normal that voices makes the simulator segfault ?
12:48:12TiMiD(it works well on target)
12:48:15 Quit linuxstb_ (Read error: 110 (Connection timed out))
12:48:22linuxstb__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:33preglowtucoz: floating point is its current problem, yes
12:48:59preglowlinuxstb__: well, for one, the codec buffer have to start buffering whole files
12:49:02preglowjust partial ones wont do
12:49:06linuxstb__Yes, but these files are tiny?
12:49:11preglownot necessarily
12:49:18preglowi've seens xms that are fifteen meg big
12:49:25preglowtons of samples
12:49:51preglowmy take at how this should work is the following:
12:50:04linuxstb__That wouldn't be a change in the API as such, just changing the buffering behaviour for certain file types.
12:50:12preglowthe 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:43linuxstb__That could be the current get_metadata() function.
12:50:44preglowit 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:00preglowyes, sure, but then we'd have to start linking rockbox core with codec libs
12:51:05preglowthese functions can be quite big
12:53:01preglowbut 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:41preglowthe latter would mean devising a codec format that can be relocatable, i guess
12:54:24linuxstb__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:25amiconnTiMiD: 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:31TiMiDok
12:54:40TiMiDso I can commit
12:55:30TiMiDand what about the other problem you were talking about this morning ?
12:56:03preglowlinuxstb__: 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:21amiconnThis is the other problem. It wasn't there when I last checked. Found it with the 'catch memory accesses' debugging feature
12:56:25preglowbut i would like all codec dependent functions to be placed in the plugins, eventually
12:56:39preglowso you can just remove the ones you don't like, and save memory
12:56:41CtcpIgnored 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:08LinusNamiconn: 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:35preglowditto
13:00
13:00:23linuxstb__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:35linuxstb__For example, the ALAC codec and AAC codec are almost identical - apart from calling different decode_frame() functions.
13:04:16preglowsure
13:04:42preglowwell, it requires some thinking anyway
13:05:17preglowbuilding the metadata loader into each codec plugin wouldn't be too nice either, some they're shared everywhere
13:05:24preglowso we might end up with metadata plugins as well, hehe
13:05:54preglowwhere 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:57linuxstb__I think the actual metadata routines (ID3, ID3v2, Vorbis comments, Ape tags) could stay in the core.
13:17:56linuxstb__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:26preglowmoving 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:17preglowlinuxstb__: 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:52webguest82What 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:14linuxstb__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:40preglowwebguest82: how fast the peak on the peak meter releases
13:28:59preglowlinuxstb__: well, that'd be a step towards having them as plugins anyway
13:29:15preglowlinuxstb__: if that can be done, then keeping them as plugins can be done just as easily
13:29:50preglowbut no, the fact that nonstreaming formats need to load their own data needs consideration
13:29:59linuxstb__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:18linuxstb__I agree about the non-streaming codecs though.
13:30:29preglowjust 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:31linuxstb__The problem is that we don't have any, so we can't see how they need to work.
13:30:44preglowlibdumb is in cvs :>
13:44:50 Quit arkascha (Remote closed the connection)
13:52:02amiconnLinusN: I've zipped innosetup together with the scripts, 2.6 MB. Is DCC okay?
13:52:10LinusNtry it
13:52:52 Join _FireFly_ [0] (n=FireFly@p54A46225.dip.t-dialin.net)
13:53:04LinusNholy moses, it worked
13:58:15preglow!!
14:00
14:01:14linuxstb__FLAC is now just over 12 hours and still going.
14:01:24preglowi'd say that's remarkable
14:01:26amiconnLinusN: There's no reason it should not work, except if you'd explicitly blocked it on your side
14:01:47LinusNfirewalls
14:01:49preglowlinuxstb__: and all q8 files, you say?
14:01:53B4gderand NATs
14:02:13linuxstb__preglow: Yes - I'm playing the same -q 8 encoded album on repeat.
14:03:22linuxstb__"View Battery" says 3.58
14:03:30preglowstarting to hit bottom then
14:03:49linuxstb__Yes, only a tiny amount left in the battery indicator.
14:04:18preglowthe iriver firmware would probably have shut down by now
14:04:58amiconnB4gder: I am behind a NAT router. It's really not difficult to configure it for working dcc
14:07:47B4gdernot for you on your router, no
14:07:58B4gderthere are still endless possibilities for it to go wrong
14:09:01preglowoh yes
14:09:22LinusNamiconn: 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:26preglowboth clients need client configuration and router configuration that is correct
14:09:38preglowthat is, just one of them needs the client config
14:10:27amiconnLinusN: Yes. I said that because I already configured that some time ago, and know that it works on my side
14:10:58LinusNand before that, did you explicitly block it on your side?
14:11:43amiconnThe receiving client does not need special configuration, just outgoing connections to high ports must not be blocked
14:12:00LinusNmy point is, that is only one of the many things that would prevent dcc from working
14:12:32LinusNso the sending client must have a properly configured router
14:13:01amiconnYes, and that was my point. I know that my config is correct
14:14:09LinusNi 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:34preglowlinuxstb__: 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:56preglowi wonder what the hell libflac did to make it so slow
14:23:48linuxstb__the ffmpeg decoder is almost twice as fast running on my PC compared to the standard "flac".
14:24:07linuxstb__Which surprised me even more than the iriver performance.
14:25:08linuxstb__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:07linuxstb__Anyway, now 12.5 hours and battery is 3.41
14:27:21linuxstb__Battery indicator now flashing....
14:28:38preglowhehe
14:28:45preglowi'd turn it off soon, were i you
14:29:07preglowi _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:47linuxstb__It's just managed one more buffer refill and is still going....
14:30:09linuxstb__But you're probably right - I should stop.
14:31:12preglow12.5 hours is heaps beyond what i'd expected anyway
14:32:15preglowi wonder how much of that is caused by it never boosting
14:32:21preglowit does never boost even for q8 files, no?
14:32:31linuxstb__I've not seen it boost, no.
14:33:43linuxstb__Any idea what the battery life for other codecs are? Is 12.5 hours competitive with the lossy codecs?
14:35:02linuxstb__OK, it's died now - it can't spin up the disk to refill the buffer.
14:35:12linuxstb__Total length - 12 hours, 38 minutes.
14:35:15preglowhaha
14:35:21preglowlast i heard was 15.something
14:35:24preglowbut i can't remember for what
14:35:26preglowthink it was vorbis
14:35:55linuxstb__It turned itself off, just before I plugged the charger in.
14:36:11linuxstb__Think I'll leave it to rest for a while.
14:36:47linuxstb__The only test I've seen was for Vorbis -q 5 files - 13h 1m for Rockbox, 12h 8m for iriver's firmware.
14:37:50linuxstb__http://www.misticriver.net/showthread.php?t=30669
14:38:12preglowthen it flaming IS competitive
14:38:31preglowdoes cpu usage actually have that much to say?
14:38:32linuxstb__Or Vorbis is bad....
14:38:55linuxstb__But it seems that Rockbox's vorbis is already better than iriver's.
14:39:15preglowwhat the hell?
14:39:15linuxstb__(or iriver shuts down too early)
14:39:23preglowthe first post there doesn't look very good
14:39:46preglow112kbps mp3 should never boost either
14:39:51preglowso 11h is a bit... weird...
14:40:02 Quit ashridah ("Leaving")
14:40:35linuxstb__Not sure what this means in that post though: "Backlight usage: Average"
14:40:46SlasherHmm, i got something like over 17h a long time ago when i tried 128kbps mp3 in "lab mode test"
14:41:12preglowSlasher: lab test mode?
14:41:27preglowlinuxstb__: anyway, the extra hour for vorbis is more probably because of rockbox running the battery completely empty
14:41:27Slasherpreglow: almost, i never touched the unit during that period
14:41:39preglowSlasher: what is 'lab mode test'?
14:42:00linuxstb__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:09Slasherpreglow: just something similar what iriver based it's runtime approximation
14:42:23preglowokies
14:42:26preglowSlasher: btw
14:42:36preglowSlasher: when 'go to next folder' option is on, the buffering stops at the end of a folder
14:42:42amiconnLinusN: 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:53Slasherpreglow: yes, that is a problem with the playlist
14:42:55amiconnOh, and btw, there's a crt0.S patch in the tracker :)
14:43:18Slasherpreglow: i think playlist_check(1) returns false or something like that so it can't buffer before calling playlist_next(1);
14:43:21preglowSlasher: so next folder isnt added to the playlist before it reaches the end of the last song?
14:43:21LinusNsaw that
14:43:28LinusNshow me the rtim patch
14:43:39Slasherpreglow: it looks like that
14:45:21linuxstb__Sorry for the ignorant question, but what is the "go to next folder" option? What's considered the next folder?
14:45:31preglowthe next folder in the dirlist
14:45:44LinusNamiconn: ok, so the only difference is that there is no read-modify-write?
14:46:07LinusNlooks good to me
14:46:08preglowi keep my albums in folders, sometimes with cd1 and cd2 subfolder, so i like it to advance further when it should
14:46:41linuxstb__I just recursively add the parent directory to the playlist.
14:46:52 Quit B4gder ("time to say moo")
14:46:58preglowi gues that's possible as well, i just never use playlists much
14:47:02preglowguess
14:47:02webguest82What is Linear?
14:47:17preglowwebguest82: for the peak meter? it just means it displays the sound level linearly, not as decibel
14:47:22preglowi prefer my peak meter linear
14:47:40webguest82thanks ^^
14:47:43preglowmuch easier to see if a codec doesn't use the full dynamic range that way
14:48:23amiconnLinusN: Some manipulations are read-modify-write, some are not
14:48:47linuxstb__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:58preglowright
14:49:09preglowi haven't played too much with the options either :P
14:49:22amiconnThe 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:27linuxstb__Just sounds like another unneccessary option that complicates the playback engine.
14:49:33preglowtruth to be told, i dont listen that much to my player any more
14:49:37preglowsince i seldom travel
14:49:37LinusNamiconn: yes
14:49:48preglowstill enjoy programming for it, though
14:49:56amiconnThat's also why the cpufreq_idle setting needs two accesses to DCR
14:50:37amiconnBefore 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:04preglowSlasher: btw, do you have any idea why the low watermark boost isn't done in debug builds?
14:51:10preglowSlasher: it skips all the time
14:51:27amiconn...and interrupts aren't disabled during frequency transition, so sdram accesses might happen
14:51:30preglowit boosts when the buffer is completely empty, but not before
14:52:14Slasherpreglow: really?
14:52:26Slasherit works fine here (has always been worked)
14:52:26preglowSlasher: really
14:52:31Slasherweird..
14:52:34preglowSlasher: linuxstb tried it as well
14:52:45SlasherHmm, i haven't tried the newest build
14:52:49preglowSlasher: it always worked for me as well, so must be a recent change
14:53:13SlasherAnd can't compile at the moment because i have some new crossfade code that doesn't compile yet :)
14:53:18preglowhehe
14:53:22preglowwhat's it do?
14:53:23Slasheroh, interesting
14:53:41 Nick linuxstb__ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net)
14:53:56Slasherpreglow: it provides the following options: crossfade enable, crossfade duration, fade in delay, fade in duration, fade out delay and fade out duration..
14:54:04preglowahh, right
14:54:06SlasherHopefully that's enough configuration for cf :)
14:54:14preglowshould be, yes
14:54:18amiconnImho it's too much ;)
14:54:27Slasher:D
14:54:32preglowshould satisfy the crossfade heads, at least
14:54:37Slasheri hope so
14:54:39preglowi never use it myself
14:55:05preglowperhaps when i begin listening to single tracks instead of albums one day
14:55:11linuxstbIs there an option to only crossfade on shuffle? Or is that one option too much?
14:55:32preglowwell, it's a bit hard for the playback engine to know if a playlist is shuffled, i think
14:55:42preglowit would need to check metadata
14:56:25preglowand btw, any reason why mp3data.c is in firmware?
14:56:33Slasherlinuxstb: not at the moment but that sounds good to add also
14:56:40preglowi think the firmware and apps semantics need some fixing in places
14:56:54linuxstbpreglow: That's how it's always been for the Archos - the mp3 functionality was considered part of the firmware.
14:57:13preglowyeah, i know, but it fits really badly for iriver
14:57:15linuxstbBut I'm sure the "elders" have expressed a willingness for it to be moved.
14:57:26preglowi could have implemented stereo settings and playback speed long ago if it wasn't for this
14:57:30linuxstb(they will no doubt correct me if I'm wrong).
14:58:46LinusNpreglow: move it then
14:59:07LinusNbut then you have to move the archos playback engine as well
14:59:29LinusNwhich is something we should do anyway
15:00
15:00:13preglowdon't think i'm the right man for that job, i'll undoubtedly screw something up
15:00:21LinusNyes you would :-)
15:00:49preglowsince it probably a bit more work than just moving some files
15:00:57LinusNyup
15:07:42 Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net)
15:15:37preglowflac.c has tons of unused iram!
15:16:13preglowwell, over 10kb at least
15:16:39preglowamiconn: 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:25preglowlinuxstb_: i get an error when i try to encode a 24 bit wav to flac, anything special i need to do?
15:34:22preglowright, i actually saved it as floating point
15:38:10linuxstb_That's the problem.
15:38:36linuxstb_You can find some 24-bit FLACs at www.archive.org in the live music archive.
15:38:49linuxstb_But most will also be 96KHz.
15:38:58linuxstb_Which is pushing Rockbox a little too far.
15:41:46markunI downloaded some 24-bit wav's from a site, but I can't find it anymore.
15:44:09markunhere: http://www.soundsonline.com/sophtml/details.phtml?sku=EW-165 (audio demos)
15:45:32linuxstb_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:25webguest82markun
15:47:06linuxstb_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:00
16:15:28 Quit XShocK (Remote closed the connection)
16:16:31preglowyes i do
16:16:48preglowgimme 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:42preglow.section .icode,"ax",@progbits
16:17:46preglowinstead of .text, or whatever i use
16:18:02preglowand that's the only place you need to change anything
16:20:01preglowlinuxstb_: i'll try to make a optimised 24 bit lpc routine now
16:20:57preglowa 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:10preglowbut of course, there's always other threads
16:22:55linuxstb_It doesn't hurt - we're wasting the IRAM otherwise.
16:23:07preglowlinuxstb_: 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:10linuxstb_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:05merbananhow much of iram is availible ?
16:26:08linuxstb_Here's a 24/96 FLAC show: http://www.archive.org/audio/etree-details-db.php?id=29456
16:26:43linuxstb_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:39preglowlinuxstb_: only main stack and codec stacks are iram
16:30:04linuxstb_Should I commit my ICODE changes for FLAC?
16:30:15preglowsure, why not
16:30:38linuxstb_Everything in libffmpegFLAC is now in IRAM - 43844 bytes
16:30:48preglowso still room for the other lpc routine
16:31:04preglowwell, at least it should
16:32:11preglowi'm thinking of various schemes on how to do it
16:32:33preglowi think i'll end up doing to emac passes, with a macsr change inbetween
16:32:39preglowtwo emac passes, even
16:32:51linuxstb_OK, that's now in CVS.
16:39:29 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
16:43:05linuxstb_Oops. Trying to play a 24/96 FLAC causes Rockbox to freeze...
16:44:21preglowahh, yes, there's that
16:44:29preglowrockbox doesn't support 96 khz yet
16:44:38preglowit supports everything up to 65536hz :-)
16:44:53preglowdon't know why it freezes, though
16:44:56_FireFly_1bit is missing ;)
16:45:10_FireFly_to support 96khz
16:45:11preglowi think i'll use a 64 bit mul for the delta calc
16:45:26preglow_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:18preglowno, no problem, i can just use a 64 bit mul
16:46:59_FireFly_or that
16:47:57preglowthe core probably uses that some other place already, so shouldn't be a problem
16:48:09preglowlinuxstb_: exactly how does it freeze?
16:51:07preglowlinuxstb_: that's weird, i only the fixed predictor frames in my 24 bit file
16:51:16preglowlinuxstb_: even in my -8 encode
16:54:00 Join linuxstb__ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net)
16:54:08linuxstb__I select the file, the WPS displays, but then it feezes before any sound is heard.
16:54:15linuxstb__It's possible it's a FLAC bug - but the block size and frame size are within limits
16:55:21linuxstb__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:44preglowi'm leeching the fourty meg one now
16:56:05linuxstb__My ADSL may be unreliable, but the 8Mbit/s downloads are useful.
16:56:09preglowthat's all i can take on this piece of moody shit adsl line without going mad
16:56:21preglowi've got about 6mbit download
16:56:24preglowbut it's a bit up and down
16:56:36linuxstb__I think I managed about 150KB/s from www.archive.org
16:56:44preglow120 here
16:57:02preglowi liked my 100mbit better :/
16:57:08linuxstb__I bet you did.
16:57:22Maxime1.97MB/s on oleane.fr ..
16:58:02linuxstb__Maxime: What upload speeds do you get?
16:58:17Maximeah in upload you speak?
16:58:33MaximeI'm on a 20M/1024K
16:58:39linuxstb__My connection is 8Mbit/s download and 512kbps upload.
16:59:41Maximewhere you are, does ADSL2+ exists?
17:00
17:00:03linuxstb__Not yet, but I think it's coming in the next few months.
17:00:12linuxstb__I'm in London.
17:00:17Maximeok
17:00:21Maxime(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:06preglowso, no one's got 24 bit flac files at ordinary sample rates?
17:13:07linuxstbYes, I've got a 24-bit/44.1KHz file. Should I upload it somewhere?
17:13:37preglowdcc/upload/mail/whatever suits you best
17:14:51linuxstbUploading now. Will PM the URL.
17:15:06linuxstbETA about 5 minutes.
17:16:28preglowgoodie
17:22:15preglowi'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:02markunpreglow: there have been plans (for years) to switch to libogg2
17:24:21markunTremor's ogg handling is based on it, http://svn.xiph.org/trunk/ogg2/
17:24:35preglowis it, now
17:25:01preglowi was just hoping that container format parsin wouldn't add any overhead
17:25:02markunDon't know if it's better. Maybe it's not so difficult to get libspeex to work with it.
17:25:13preglowbut with libogg it seems like it's going to
17:25:21preglowmarkun: my first try will be to get flac working with it
17:25:35markunlibogg or libogg2?
17:25:49preglowi'll have to have a further look before i decide on that
17:25:55preglowthe libogg2 api is still under discussion
17:26:33preglowi wonder what happened to theora
17:27:26markunbtw I made a joining function for arabic. Don't know if anyone is interested.
17:28:12markunI've been googling for an arabic iriver forum, but didn't find one.
17:28:22preglowseems ogg2 is zerocopy, yes
17:28:50markungreat! 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:25linuxstb_Is ogg2 just a different API to the same format, or a new format?
17:31:38markundifferent api
17:34:49linuxstb_preglow: Check your email for that FLAC file URL.
17:35:45preglowgoodie
17:35:46preglowthanks
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:23amiconnpreglow: 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:41preglowamiconn: the routines are in libgcc, so it would have to be before that
17:48:02preglowamiconn: but otherwise, i think we should do it, your routine beats the gcc one by far
17:49:25amiconnYeah, it's both smaller & faster
17:50:01linuxstbWould putting it in the codec lib work?
17:50:46_FireFly_amiconn: what about the accuracy??
17:50:51amiconnThe name is __muldi3
17:51:03amiconn_FireFly_: It's bit accurate
17:51:25_FireFly_better as the gcc one
17:51:34linuxstbIf 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:32amiconn_FireFly_: It's the same accuracy, it has to be
17:52:50amiconnWe're talking about the 64*64->64bit integer multiplication
17:56:20linuxstbIIUC, the FLAC routine just needs a 32*32->64-bit multiplication.
17:57:34preglowlinuxstb: yes
17:57:46preglowi'll just use both modes of the emac unit
17:57:54amiconnThat'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:58linuxstbWhich codecs need a 64x64->64 mult?
17:59:38amiconnThe 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
18:00:56amiconnAfaik 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:27linuxstbOn 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:51LinusNevery cycle counts
18:06:27LinusNthe more time the cpu can spend in the idle sleep mode the better
18:06:27preglowindeed
18:07:18preglowok, now let's hope that flac never uses the top bit in the accumulator
18:07:48preglowamiconn: would finding the top bit in the mul be much trouble? without performing another mul, that is
18:08:10preglowafaik, the top bit wil only be used if the two numbers in the mul are 0x80000000 and 0x80000000
18:11:54amiconnyep, and it's possible, sacrificing 4 extra cpu cycles (5 if the correction is to be made)
18:12:06linuxstbLooking at the code (decode_subframe_lpc), the coefficients seem to only be a maximum of 15 bits.
18:12:19linuxstbSo unless I'm misunderstanding, it's a 15-bit x 32-bit multiplication.
18:15:41preglowreally, now
18:16:26preglowi wonder if i should even try to do a fraction emac mode solution only
18:16:52preglowif 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:21linuxstbs/wav/flac/ ??
18:17:27preglowyes :)
18:17:49linuxstbDo you agree that it's a 15x32 multiplication?
18:20:05 Join z0rr0 [0] (i=z0rr0@217.30.249.24)
18:23:07preglowmost certainly looks like it, yes
18:23:58preglowbut the other numbers might be anything then
18:25:30linuxstbYes, anything up to 32-bits I think.
18:26:03linuxstbEven if the audio data is only 24-bit
18:27:00 Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr)
18:27:16preglowand i wonder what range qlevel is in
18:27:27preglowseems like it can be anything up to 32
18:27:41preglowin which case the fractional mode might end up a bit tricky
18:28:07linuxstbYes - qlevel is 5 bits
18:29:02linuxstbDo you know if wavpack has a similar routine?
18:29:16preglowhmm, no, wavpack does things sligtly differently, i believe
18:29:27preglowbut it only uses frac mode, so it's got to do something similar
18:29:37preglowi haven't talked to david bryant for quite a while, so don't know
18:30:04preglowhe's busy with a new version of wavpack, i think
18:34:28preglowso, if qlevel is something around 32, i can get rid of 17 of them by scaling the coefs to 32 bits
18:35:46preglowone 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:46preglowbut if sixteen bit output precision is ok, it might work
18:48:12linuxstbIt would be much nicer to get the full 24-bit output - it's controversial to have an inaccurate FLAC decoder.
18:49:13preglowyep, than that's what i'll do
18:49:20preglowthis is how wavpack handles it, btw
18:49:48preglowit doesn't guarantee that the lowest bits are accurate in a high res file
18:49:54preglowthat is, our implementation of wavpack
18:50:27linuxstbAh, 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:00
19:05:03preglowindeed
19:06:58preglowso, you think i should do it the proper and somewhat slower way for flac?
19:06:58 Quit akke ("CGI:IRC (EOF)")
19:07:21preglowamiconn: will a 64 bit variable shift routine be big?
19:07:34preglowleft shift, that is
19:07:51amiconnNot really
19:07:59preglowhow many registers will it use?
19:08:04amiconnIt's a sub, 3 shifts and an or
19:08:15preglowi don't want to stack any variables :/
19:08:30amiconnOne additional register besides the operands
19:08:31preglowand i've only got one register free at the moment
19:08:31preglowargh
19:08:37preglowthat's one more than i have
19:08:38preglowhrmph
19:09:08preglowin the worst case, that is
19:10:12linuxstbDoes the DSP just truncate to 16-bits at the moment?
19:11:30preglowno
19:11:35preglowwell, at the end it does
19:11:37preglowafter processing
19:11:49preglowand 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:44preglowthe whole point of having more than 16 bits precision is so some kind of processing can benefit from it
19:13:50linuxstbIt'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:00preglowwell, i certainly agree on that
19:14:24preglowi'll just see if a can free a register somewhere
19:16:08preglowwell, i guess i can free the fetch variable and just add an extra move before the accumulator chains
19:16:12preglowchain
19:16:47linuxstbOn 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:03amiconnpreglow: If you wanna see the 32*32->64 top bit correction: amiconn.dyndns.org/muls323264.S">http://amiconn.dyndns.org/muls323264.S
19:19:32preglowlinuxstb: not exactly a crying matter
19:21:44preglowamiconn: of course, i didn't think about the emac unit setting overflow true
19:22:32***Saving seen data "./dancer.seen"
19:26:31preglowamiconn: what's up with the trap? how is that possible?
19:26:57preglowi thought trap was a one-word instruction
19:27:10amiconnNo, there is trapf, trapf.w and trapf.l
19:27:28amiconnCheck CFPRM.pdf (it's called tpf there)
19:27:46preglowahh, so it's tpf
19:28:47amiconnIt'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:24amiconnSo either the trapf.w/trapf.l, or the shadowed instruction needs to be given as hex word(s)
19:30:04amiconnIt's easier to reach the shadowed instruction with the first method
19:31:08markunamiconn: 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:16preglowamiconn: 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:52markunlinuxstb: Are you closer to real-time decoding with aac?
19:51:47amiconnmarkun: Yes, perhaps, but not now. As mentioned, I'd prefer to wait with unicode commit until the gui transition is done
19:52:47amiconnHopefully the code size decreased enough by then to allow for unicode support without slef-extraction
19:53:31amiconnAbout your arabic function: Imho 6KB is a bit heavy for it to reside in the core - just for one language
19:53:56amiconnARe there many arabic rockbox users? What if other languages need simiar functions?
19:55:02amiconnThere's an idea I'm thinking about for quite a while: rockbox should probably have language specific "plugin" code
19:55:02markunI don't know of any arabic rockbox user. Googling for arabic pages with rockbox in it did not give any useful results.
19:56:16amiconnMy 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:55amiconnFor example, 21 is "twenty one" in english, but the equivalent of "one-and-twenty" in german
19:57:41markunShould the arabic language plugin be loaded loaded when an arabic string is found or only when the user selects it?
19:58:12amiconnHmm, arabic strings in filenames are a problem with that concept...
19:58:28amiconnMy idea was to use it depending on the loaded .lng file
19:59:13linuxstbmarkun: We're (preglow and I) are getting a little closer. But it's such a big codec, it's hard to optimise.
19:59:56markunamiconn: If you would like to take a look at the test code: http://130.89.160.166/rockbox/arabjoin.c
20:00
20:01:17markunlinuxstb: 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:30preglowmarkun: there's the helix decoder, which we can't use
20:01:32linuxstbThere is one - the helix/real decoder.
20:01:34preglowthat's almost certainly better
20:02:53preglowto optimise aac further, i'll need to dig into the source a bit and see how it works
20:04:02linuxstbThere is always the ISO reference decoder. I don't know what license that's released under though.
20:04:32preglowahaha
20:04:34preglowdon't think about it
20:04:39preglowthe reference decoders are always wildly shitty
20:04:55linuxstbBut so is libfaad as far as we are concerned.
20:05:03preglownot _that_ shitty, i'm sure
20:05:07preglowbut feel free to check it out
20:05:26preglowanyways
20:05:39preglowgetting libmad to work as fast as it does today didn't exactly happen overnight either
20:06:05Maximeerm
20:06:17Maximei've a question, i've had a strange issue this afternoon
20:06:33MaximeI was listening to radio, then I put one MP3, then I had the sound of the radio AND the mp3
20:06:46preglowyou probably exited the radio wrongly
20:06:50Maximeyeah
20:06:54Maximethis is funny so :p
20:06:55Maximelol
20:07:17Maximeand I had a *PANIC$
20:07:49preglowthat's not intended, actually...
20:07:50Maximelistening to a mp3, then opened a jpg, (no sound when the JPG appears), and then when i exited the JPG, *PANIC*
20:08:05preglowyou don't use any jpeg related patches?
20:08:16Maximeno
20:08:26Maximeit's the daily build from this morning
20:09:47amiconnmarkun: This is really 6KB of compiled code? Or do you mean it is 6KB as a test program?
20:10:26amiconnI 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:41markunyes, true.
20:11:01markunI was a bit pessimistic (and stupid) I guess
20:11:11amiconnWith shorts, the table should be a little above 1KB, with the big last part not #if'ed out like it is now
20:12:21linuxstbpreglow: You're right about the AAC reference code. I've now deleted it.
20:13:28linuxstbI 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:44Maxime(great the JPG viewer tho.. ^^)
20:14:59 Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se)
20:20:07markunamiconn: With shorts and the big table included, arabjoin.o is 2732 bytes
20:21:30amiconnThe .o doesn't tell much about the final code size.
20:21:53amiconnYou would need to link, and then check the .map and/ or the binary
20:21:57preglowhmm, 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:16amiconnSize can also vary significantly depending on the target
20:22:37amiconn(not the table though)
20:26:37preglowamiconn: 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:54preglowfetching 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:26preglowi 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:29amiconnIf 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:54NSplitkornbluth.freenode.net irc.freenode.net
20:31:13 Quit markun (kornbluth.freenode.net irc.freenode.net)
20:31:41preglowiram
20:34:09amiconnSounds like a small test is necessary
20:34:31NHealkornbluth.freenode.net irc.freenode.net
20:34:31NJoinmarkun [0] (n=karl@bastards.student.ipv6.utwente.nl)
20:34:44NJoinSlasher [0] (i=miipekk@ihme.org)
20:35:22preglowcan'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:38preglowi'm almost convinced the first method is faster
20:36:02amiconn'almost' isn't 100% ;-)
20:36:12 Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net)
20:36:12preglowit is if you can't be bothered do to tests :P
20:36:31amiconnWell, memcpy is all about tests, tests, tests...
20:36:41preglowyup, and it's a bit more important for memcpy as well
20:36:47amiconnYou see why it takes that long :-)
20:36:54preglowsure
20:37:34preglowamiconn: hmm, from i can see in your libmusepack shifting routine, you need two additional registers for shifting
20:37:49amiconnNot necessarily
20:38:15amiconnYou said you need variable shift. One of the additional registers is the shift count
20:38:58preglowwell, i see t2 and t1 as well
20:39:23amiconnYes, but that's not only a 64 bit left shift.
20:39:36preglowno?
20:39:52amiconnIt even is not a 64 bit shift at all.
20:41:19amiconnThe shift part is a 'shortened' 64 bit right shift, in that we only need 32 bits of the result
20:42:32preglowthat's what i want as well
20:44:23amiconnt1 is the result. You can reuse the same register that's used for the 'y' input
20:44:35amiconn(if you don't need it again afterwards)
20:45:56preglowi've got three registers
20:46:05preglowtwo of them contains a 64 bit number, the last one is free
20:46:21preglowthe shift amount is contained in another register
20:49:08amiconnIt's possible to save one register (with some penalty) if it's allowed to destroy the shift count
20:49:21preglowit's not
20:49:32amiconnIt's possible to restore it, with some more penalty
20:49:58preglowout 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:23preglowehh, that's wrong :>
20:50:50amiconn5+8 = 13, only 2 registers left
20:50:52preglowyes, four contain parameters
20:51:06preglowi didth the order parameter, since the loop is unrolled and order thus hard coded
20:51:07preglowditch
20:51:11amiconnWhere do you get your 64 bit data from?
20:51:21preglowtwo sets of mac.l chains
20:51:29preglowone for the high bits, one for the low bits
20:51:41amiconnSo, from the %accn registers?
20:51:44preglowyup
20:51:55preglowahh, right
20:51:59amiconnThen it's possible, by reading one value twice
20:52:06amiconn(first time without movclr)
20:52:12preglowyes, necessarily :)
20:52:32amiconnYou want to shift right?
20:54:28preglowyup
21:00
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:39preglowi've got more bits available in seven of the eight unrolled cases
21:08:58preglowregisters, yes
21:12:08preglowbut not so in the order > 8 case
21:12:15preglowwhich will undoubtedly be fun no matter how i do it
21:14:23 Quit _FireFly_ ("Leaving")
21:15:37preglowamiconn: 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:04amiconnJust the tick counter, with enough repeats to make it sufficiently high precision
21:16:08preglowyes
21:20:15amiconnIn the 16 bit routines, you only need to preserve 11 registers within the loop
21:20:21muesli_-re
21:20:55amiconn.. 8 coefficients, a0, d0 and a1. So what is the 4th parameter in the 24 bit case?
21:21:30preglowamiconn: eleven registers? i need to preserve four parameters, plus eight coefs, worst case
21:22:10preglowamiconn: i preserve d0, d1, a0, a1
21:22:27amiconnWhy a1? It's only needed at the start to load the coefficients...
21:22:35preglow:-)
21:22:36***Saving seen data "./dancer.seen"
21:22:51preglowyes, valid point, valid point
21:22:54 Join linuxstb_ [0] (n=5343d4aa@labb.contactor.se)
21:24:05amiconnYou can even reuse a1 in the movem
21:24:33preglowindeed i can
21:24:44preglowso 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:21linuxstb_preglow: In your 32-bit LPC routine, is it possible to unroll any of the higher (i.e. > 8) orders?
21:42:48amiconnTiMiD: 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:00
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:28preglowlinuxstb_: perhaps 9
22:36:54preglowlinuxstb_: i can unroll some instances in the older 16 bit version for sure
22:37:07preglowup to ten
22:37:13preglowshould i?
22:38:13preglowi hate code like this, tons of duplicated code everywhere
22:38:46TiMiDamiconn: it's not a bug, it's wanted ...
22:39:36linuxstb_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:47TiMiDI thought it would be more logicla to do like that with all text outputs
22:39:53linuxstb_So yes, I think it's worthwhile.
22:40:22linuxstb_I wouldn't worry about duplication either - I know it's untidy, but we have IRAM to spare for FLAC.
22:40:48amiconnTiMiD: Hmm....
22:41:02 Quit dpassen1 ()
22:41:26TiMiDsince it's handled generically anyway ...
22:41:36amiconnIt looks rather odd, and the next message doesn't do that
22:41:37preglowlinuxstb_: well, i can't unroll orders that high
22:41:41amiconn(the rolo thing)
22:42:04linuxstb_preglow: I know.
22:42:42TiMiDthe rolo message ?
22:42:52TiMiDyou mean when it's rebooting ?
22:43:50amiconnyes
22:44:30preglowi need to keep three parameters and need two working registers, 15 - 5 = 10, which is the highest order i can unroll
22:44:30preglowi can unroll all orders, sure, but then i need to start loading coefs all the time as well, and the advantage vanishes
22:44:39amiconnThe reboot request keeps the status bar, but the rolo message does not
22:44:39amiconnThat's one reason why I thought it's a bug
22:44:39amiconnThe other reason is that it looks squeezed
22:44:43TiMiDI didn't looked at that part of the code
22:45:04TiMiDso I didn"t changed it
22:45:27amiconnRelated to that, it's probably a good idea to have a request widget
22:45:45amiconn...at least for the common yes/no requests
22:46:12TiMiDhmm like the other one used for "reset settings"
22:46:14TiMiD?
22:46:52amiconnYes. Iirc there are more yes/no requests than just these 2
22:47:15TiMiDI didn't thought about that but it's surea good idea :)
22:47:28TiMiDI'm doing right now a generic select widget
22:47:39TiMiDfthe menus
22:47:53TiMiD(for the )
22:48:00amiconnThis idea is even older than your gui work, just nobody implemented it yet
22:48:43TiMiDthere is something like this in settings.c
22:49:15TiMiDbut lot of code is duplicated since it handles bool, int, strings ...
22:49:49TiMiDanyway, about the statusbar, do you think it should be removed ?
22:49:59amiconnI'm curious how much will be gained when you are at the point where you can remove the old statusbar code etc
22:50:10TiMiDI don't know about that
22:50:35TiMiD1kb of c code less >> binary smaller by 100 bytes
22:50:42amiconnI know that there is still some work left. Settings, radio screen recording screen, keyboard....
22:50:43TiMiDnot very efficient ;)
22:50:57amiconnWell, that varies a lot
22:51:01preglowseems we've got 64 bit flac, yes
22:51:10preglow24 bit, at that
22:51:19*linuxstb_ cheers
22:51:23amiconnI was about to ask...
22:51:42preglowi got diverted for an hour
22:51:50TiMiDI try to do the work so that we can remove the old functions the sooner possible
22:52:07TiMiDthere is also len0x and firefly helping
22:57:44amiconnpreglow: 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:00amiconnAnd you waste an instruction and a move :)
22:58:13amiconnI mean, a move instruction and a register
22:58:36preglowamiconn: i could just use duffs device for the residual handling
22:58:47amiconn??
22:58:48preglowat least the assembler equivalent of duffs device :)
22:59:20preglowthree mac instructions, and just jump to the one giving me enough macs for the residual
23:00
23:00:34amiconnYes, that's what I mean, but the coefficient fetch is also variable
23:01:43 Quit Midgey34 (Remote closed the connection)
23:02:15amiconninstead 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:18amiconnjust use moveq.l #3,%d3 / and.l %d2,%d3
23:02:33amiconnThe and operation is commutative
23:03:19preglowyes, 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:51preglowamiconn: when you said i could reuse a1 in the movem
23:36:22preglowdid you mean the following is possible: movem (%a1), %d0-d7/%a1-%a6 ?
23:37:06amiconnyeps
23:37:31preglowand it is! funnily enough, it turns out i screwed up some place else
23:37:37preglowwho'd have thunk it
23:37:50 Quit linuxstb (Read error: 110 (Connection timed out))
23:42:07preglowi must be doing something completely moronic here
23:43:00preglowtell me
23:43:07preglowwww.pvv.org/~thomj/rockbox/snip
23:43:27preglowshouldn'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:57amiconnyes
23:47:13preglowthen i wonder what the static bursts i guess mean
23:47:18preglowsomething else, i hope
23:47:25amiconnprovided qlevel <= 32
23:48:16preglowyes, it is
23:48:29preglowqlevel can't be even close to 32
23:49:00preglowthe 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

Previous day | Next day