| 00:00:16 | preglow | haha |
| 00:00:33 | | Quit ender` (Read error: 104 (Connection reset by peer)) |
| 00:03:47 | amiconn | LinusN: Do you think the patch should enabled continuous page mode as well? |
| 00:04:08 | LinusN | sure, why not? |
| 00:04:49 | len0x | @Moos - are you not getting my msg ? |
| 00:05:09 | Moos | nope ;) |
| 00:05:33 | tucoz | good night |
| 00:05:37 | | Part tucoz |
| 00:06:46 | len0x | @weird - I sent like 10 :) |
| 00:06:57 | Moos | :D |
| 00:07:12 | Moos | are you freenode registrated? |
| 00:07:19 | len0x | nope... |
| 00:08:23 | Moos | 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 | topbloke | hey can simulator builds of rockbox be downloaded anywhere? |
| 00:10:18 | LinusN | topbloke: no, you build them yourself |
| 00:10:54 | topbloke | oh they used to be on the site |
| 00:10:56 | topbloke | what happened |
| 00:12:32 | LinusN | i dunno, maybe we didn't see the point in providing them |
| 00:12:51 | topbloke | ok cool |
| 00:13:09 | LinusN | what would be the point? |
| 00:13:16 | topbloke | it lets people without a target play around with rockbox |
| 00:13:24 | topbloke | without messing with compling |
| 00:14:13 | topbloke | i wanted to see how rockboy runs on an iRiver |
| 00:14:54 | Bagder | you'd need to run on target to see that |
| 00:15:00 | topbloke | oh ok |
| 00:15:12 | Bagder | as the simulator doesn't run with the same speed |
| 00:15:42 | topbloke | is it playable at all on a real iRiver ? |
| 00:15:51 | LinusN | some games are |
| 00:15:58 | LinusN | like pokemon |
| 00:16:04 | topbloke | oh sweet |
| 00:16:11 | topbloke | pokemon i love that ! :) |
| 00:16:33 | LinusN | super marioland is quite playable as well |
| 00:16:44 | LinusN | no sound though |
| 00:17:01 | topbloke | how about on a archos recorder? |
| 00:17:12 | LinusN | haven't tried |
| 00:17:27 | topbloke | ok thanks |
| 00:17:41 | LinusN | time to sleep |
| 00:17:44 | LinusN | cu all |
| 00:17:51 | topbloke | bye |
| 00:17:52 | | Part LinusN |
| 00:19:46 | preglow | think i'll take his example |
| 00:19:48 | preglow | night all, later |
| 00:20:33 | len0x | 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 | amiconn | 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: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:57 | mannie | yo, 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:36 | mrmags | 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: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:23 | B4gder | http://hardware.slashdot.org/article.pl?sid=05/11/02/2055238&from=rss |
| 08:10:31 | B4gder | "Can Open Source Outdo the IPod?" |
| 08:10:58 | B4gder | 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 | ashridah | 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 | B4gder | hehe, yes |
| 08:23:38 | ashridah | i imagine the entire thread is full of morons going "oss will never come up with the clicky wheel!" |
| 08:23:52 | B4gder | yes, lots of that style |
| 08:23:59 | ashridah | and no actual discussion of reverse engineering, drm, or other issues facing it |
| 08:25:16 | amiconn | Haha, ""There is very little innovation left" |
| 08:25:25 | | Quit solexx (Read error: 104 (Connection reset by peer)) |
| 08:25:26 | amiconn | Someone please ask our blind users... |
| 08:25:33 | B4gder | haha |
| 08:25:46 | B4gder | apple sheep |
| 08:26:16 | amiconn | morning, btw :) |
| 08:29:52 | B4gder | 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 | B4gder | Zagor: http://forums.rockbox.org/index.php?topic=1737.0;topicseen |
| 08:45:21 | B4gder | the Rockbox wikipedia article has its flaws |
| 08:45:42 | B4gder | 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 | B4gder | 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 | amiconn | TiMiD: Are you around? |
| 09:00 |
| 09:00:46 | ashridah | heh. i love having flamewars with no-nothing overclockers :) |
| 09:03:31 | | Part LinusN |
| 09:08:29 | TiMiD | amiconn: yes I'm here (for 5 minutes, no more) |
| 09:19:27 | amiconn | There is a bug with the gui menu system and the voice ui |
| 09:20:52 | amiconn | 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 | amiconn | This worked before... |
| 09:22:20 | *** | Saving seen data "./dancer.seen" |
| 09:22:52 | TiMiD | ok |
| 09:23:08 | TiMiD | I'll look at this this evening |
| 09:23:13 | TiMiD | now I have to go ... |
| 09:23:51 | TiMiD | this shouldn't be too hard to fix |
| 09:25:05 | amiconn | Maybe 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:31 | webguest19 | hi |
| 11:16:21 | | Quit webguest19 (Client Quit) |
| 11:22:21 | *** | Saving seen data "./dancer.seen" |
| 11:30:44 | linuxstb | 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 | linuxstb | But I'm not sure how this test will end. What will happen when the battery runs out? |
| 11:31:43 | linuxstb | The battery indicator is currently showing about 30%-40% full. |
| 11:31:46 | | Join webguest82 [0] (n=3a4d50b4@labb.contactor.se) |
| 11:31:57 | webguest82 | hello |
| 11:32:28 | webguest82 | Connection does not become by irc program. |
| 11:35:19 | Rick | o.o |
| 11:36:31 | webguest82 | :) I like Rockbox so. |
| 11:36:57 | amiconn | Zagor: Installer builds are still not working ?!? :-(( |
| 11:39:59 | webguest82 | markun: Are you busy? |
| 11:46:17 | webguest82 | What is wps? |
| 11:56:02 | yngwi | wps is "while playing screen" |
| 11:56:57 | | Join LinusN [0] (n=linus@labb.contactor.se) |
| 11:57:15 | LinusN | amiconn: the innosetup scripts were lost in the twiki raid |
| 11:58:48 | webguest82 | thanks |
| 11:59:48 | amiconn | 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:00 |
| 12:03:38 | | Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 12:04:15 | LinusN | 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 | TiMiD | 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 | linuxstb_ | 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 | yngwi | nothing |
| 12:14:45 | yngwi | i think |
| 12:15:05 | yngwi | it runs until the power is too low for the harddisk to spin.. |
| 12:15:19 | yngwi | correct me if i'm not right with that |
| 12:16:34 | | Quit linuxstb (Read error: 110 (Connection timed out)) |
| 12:17:01 | linuxstb_ | 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 | linuxstb_ | Battery looks about 1/3 full. |
| 12:17:40 | linuxstb_ | Make that 1/4 full. |
| 12:18:31 | yngwi | 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 | yngwi | 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 | tucoz | 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 | LinusN | tucoz: rockbox doesn't shut down at all, the hardware does it |
| 12:28:56 | tucoz | ...and that a lithium-poly battery may be damaged if being <= 2.5 volts |
| 12:29:24 | linuxstb_ | So it's safe to let it run until death? |
| 12:30:07 | B4gder | "battery university" even claims that liIo batteries should be kept at no less than 40% charge level |
| 12:30:24 | B4gder | http://www.batteryuniversity.com/parttwo-34.htm |
| 12:30:31 | tucoz | 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 | B4gder | " 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 | B4gder | "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 | linuxstb | (sorry, ADSL playing up again). |
| 12:33:31 | TiMiD | I've a problem with cvs |
| 12:33:58 | TiMiD | export CVSROOT=:pserver:kevin@rockbox.haxx.se:/cvsroot/rockbox |
| 12:34:05 | TiMiD | cvs login |
| 12:34:06 | TiMiD | Logging in to :pserver:anonymous@rockbox.haxx.se:2401/cvsroot/rockbox |
| 12:34:13 | TiMiD | why is it anonymous ? |
| 12:34:21 | tucoz | So, 2.7 volts is perhaps a lower bound for voltage then? |
| 12:34:26 | *** | Alert Mode OFF |
| 12:34:36 | linuxstb | TiMiD: Because you originally checked out those files anonymously? |
| 12:34:46 | TiMiD | hmm maybe |
| 12:34:50 | tucoz | if the disk is still able to spin up at that voltage |
| 12:34:54 | linuxstb | cvs will look in a directory called "CVS" first to get the repository details. Look at the files in that directory. |
| 12:35:21 | TiMiD | you are right :) |
| 12:35:36 | linuxstb | You should just be able to edit those files manually. |
| 12:35:51 | linuxstb | But it may be easier to check out a fresh copy, and then transfer your modified files to that copy. |
| 12:35:51 | preglow | linuxstb: not too shabby a runtime for flac, if you ask me |
| 12:36:00 | linuxstb | preglow: I'm very happy. |
| 12:36:00 | preglow | linuxstb: is this with the stock battery? |
| 12:36:15 | | Quit Kohlrabi (Read error: 110 (Connection timed out)) |
| 12:36:18 | linuxstb | Yes - a completely unmodified H140. |
| 12:36:41 | | Quit cYmen___ (Connection timed out) |
| 12:36:47 | preglow | B4gder: given up on neuros, or? ;) |
| 12:37:14 | tucoz | What is next for you codec-phantoms? mod, sid? That would be so cool. |
| 12:37:15 | B4gder | not quite |
| 12:37:17 | B4gder | but almost |
| 12:37:24 | B4gder | and a major lack of time |
| 12:37:49 | yngwi | i'd really like to hear SID tunes on my iriver |
| 12:38:33 | preglow | tucoz: there's more than enough for me to do on the good old streaming formats yet |
| 12:38:41 | preglow | i don't consider any of them finished for release |
| 12:39:13 | preglow | at least some forum person says i've fixed the lame large enc_delay issue |
| 12:39:52 | tucoz | 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 | linuxstb | preglow: Does that mean that lame mp3 playback is perfectly gapless now? |
| 12:41:00 | preglow | linuxstb: no |
| 12:41:05 | preglow | linuxstb: more or less, at least |
| 12:41:12 | preglow | linuxstb: but seeking for one breaks it |
| 12:41:45 | preglow | but that should be easily fixable |
| 12:41:47 | tucoz | preglow, that is fully understandable. Sids and mods (when that time comes) is just the frosting of the cake :) |
| 12:42:23 | preglow | i'd like mod support |
| 12:42:37 | preglow | i'd also like spc support |
| 12:42:48 | preglow | sids would of course be nice too |
| 12:42:49 | tucoz | spc? is that speex? |
| 12:42:54 | preglow | spc is snes music |
| 12:42:57 | tucoz | hehe |
| 12:44:20 | preglow | 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 | tucoz | ah, that is true. Hmm, what is the problem with DUMB? floating point or something else? |
| 12:46:53 | tucoz | except from the codec api stuff |
| 12:48:02 | TiMiD | is it normal that voices makes the simulator segfault ? |
| 12:48:12 | TiMiD | (it works well on target) |
| 12:48:15 | | Quit linuxstb_ (Read error: 110 (Connection timed out)) |
| 12:48:22 | linuxstb__ | 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 | preglow | tucoz: floating point is its current problem, yes |
| 12:48:59 | preglow | linuxstb__: well, for one, the codec buffer have to start buffering whole files |
| 12:49:02 | preglow | just partial ones wont do |
| 12:49:06 | linuxstb__ | Yes, but these files are tiny? |
| 12:49:11 | preglow | not necessarily |
| 12:49:18 | preglow | i've seens xms that are fifteen meg big |
| 12:49:25 | preglow | tons of samples |
| 12:49:51 | preglow | my take at how this should work is the following: |
| 12:50:04 | linuxstb__ | That wouldn't be a change in the API as such, just changing the buffering behaviour for certain file types. |
| 12:50:12 | preglow | 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 | linuxstb__ | That could be the current get_metadata() function. |
| 12:50:44 | preglow | 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 | preglow | yes, sure, but then we'd have to start linking rockbox core with codec libs |
| 12:51:05 | preglow | these functions can be quite big |
| 12:53:01 | preglow | 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 | preglow | the latter would mean devising a codec format that can be relocatable, i guess |
| 12:54:24 | linuxstb__ | 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 | amiconn | 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 | TiMiD | ok |
| 12:54:40 | TiMiD | so I can commit |
| 12:55:30 | TiMiD | and what about the other problem you were talking about this morning ? |
| 12:56:03 | preglow | 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 | amiconn | 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 | preglow | but i would like all codec dependent functions to be placed in the plugins, eventually |
| 12:56:39 | preglow | 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 | LinusN | 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 | preglow | ditto |
| 13:00 |
| 13:00:23 | linuxstb__ | 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 | linuxstb__ | For example, the ALAC codec and AAC codec are almost identical - apart from calling different decode_frame() functions. |
| 13:04:16 | preglow | sure |
| 13:04:42 | preglow | well, it requires some thinking anyway |
| 13:05:17 | preglow | building the metadata loader into each codec plugin wouldn't be too nice either, some they're shared everywhere |
| 13:05:24 | preglow | so we might end up with metadata plugins as well, hehe |
| 13:05:54 | preglow | 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 | linuxstb__ | I think the actual metadata routines (ID3, ID3v2, Vorbis comments, Ape tags) could stay in the core. |
| 13:17:56 | linuxstb__ | 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 | preglow | 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 | preglow | 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 | webguest82 | 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 | linuxstb__ | 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 | preglow | webguest82: how fast the peak on the peak meter releases |
| 13:28:59 | preglow | linuxstb__: well, that'd be a step towards having them as plugins anyway |
| 13:29:15 | preglow | linuxstb__: if that can be done, then keeping them as plugins can be done just as easily |
| 13:29:50 | preglow | but no, the fact that nonstreaming formats need to load their own data needs consideration |
| 13:29:59 | linuxstb__ | 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 | linuxstb__ | I agree about the non-streaming codecs though. |
| 13:30:29 | preglow | 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 | linuxstb__ | The problem is that we don't have any, so we can't see how they need to work. |
| 13:30:44 | preglow | libdumb is in cvs :> |
| 13:44:50 | | Quit arkascha (Remote closed the connection) |
| 13:52:02 | amiconn | LinusN: I've zipped innosetup together with the scripts, 2.6 MB. Is DCC okay? |
| 13:52:10 | LinusN | try it |
| 13:52:52 | | Join _FireFly_ [0] (n=FireFly@p54A46225.dip.t-dialin.net) |
| 13:53:04 | LinusN | holy moses, it worked |
| 13:58:15 | preglow | !! |
| 14:00 |
| 14:01:14 | linuxstb__ | FLAC is now just over 12 hours and still going. |
| 14:01:24 | preglow | i'd say that's remarkable |
| 14:01:26 | amiconn | LinusN: There's no reason it should not work, except if you'd explicitly blocked it on your side |
| 14:01:47 | LinusN | firewalls |
| 14:01:49 | preglow | linuxstb__: and all q8 files, you say? |
| 14:01:53 | B4gder | and NATs |
| 14:02:13 | linuxstb__ | preglow: Yes - I'm playing the same -q 8 encoded album on repeat. |
| 14:03:22 | linuxstb__ | "View Battery" says 3.58 |
| 14:03:30 | preglow | starting to hit bottom then |
| 14:03:49 | linuxstb__ | Yes, only a tiny amount left in the battery indicator. |
| 14:04:18 | preglow | the iriver firmware would probably have shut down by now |
| 14:04:58 | amiconn | B4gder: I am behind a NAT router. It's really not difficult to configure it for working dcc |
| 14:07:47 | B4gder | not for you on your router, no |
| 14:07:58 | B4gder | there are still endless possibilities for it to go wrong |
| 14:09:01 | preglow | oh yes |
| 14:09:22 | LinusN | 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 | preglow | both clients need client configuration and router configuration that is correct |
| 14:09:38 | preglow | that is, just one of them needs the client config |
| 14:10:27 | amiconn | LinusN: Yes. I said that because I already configured that some time ago, and know that it works on my side |
| 14:10:58 | LinusN | and before that, did you explicitly block it on your side? |
| 14:11:43 | amiconn | The receiving client does not need special configuration, just outgoing connections to high ports must not be blocked |
| 14:12:00 | LinusN | my point is, that is only one of the many things that would prevent dcc from working |
| 14:12:32 | LinusN | so the sending client must have a properly configured router |
| 14:13:01 | amiconn | Yes, and that was my point. I know that my config is correct |
| 14:14:09 | LinusN | 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 | preglow | 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 | preglow | i wonder what the hell libflac did to make it so slow |
| 14:23:48 | linuxstb__ | the ffmpeg decoder is almost twice as fast running on my PC compared to the standard "flac". |
| 14:24:07 | linuxstb__ | Which surprised me even more than the iriver performance. |
| 14:25:08 | linuxstb__ | 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 | linuxstb__ | Anyway, now 12.5 hours and battery is 3.41 |
| 14:27:21 | linuxstb__ | Battery indicator now flashing.... |
| 14:28:38 | preglow | hehe |
| 14:28:45 | preglow | i'd turn it off soon, were i you |
| 14:29:07 | preglow | 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 | linuxstb__ | It's just managed one more buffer refill and is still going.... |
| 14:30:09 | linuxstb__ | But you're probably right - I should stop. |
| 14:31:12 | preglow | 12.5 hours is heaps beyond what i'd expected anyway |
| 14:32:15 | preglow | i wonder how much of that is caused by it never boosting |
| 14:32:21 | preglow | it does never boost even for q8 files, no? |
| 14:32:31 | linuxstb__ | I've not seen it boost, no. |
| 14:33:43 | linuxstb__ | Any idea what the battery life for other codecs are? Is 12.5 hours competitive with the lossy codecs? |
| 14:35:02 | linuxstb__ | OK, it's died now - it can't spin up the disk to refill the buffer. |
| 14:35:12 | linuxstb__ | Total length - 12 hours, 38 minutes. |
| 14:35:15 | preglow | haha |
| 14:35:21 | preglow | last i heard was 15.something |
| 14:35:24 | preglow | but i can't remember for what |
| 14:35:26 | preglow | think it was vorbis |
| 14:35:55 | linuxstb__ | It turned itself off, just before I plugged the charger in. |
| 14:36:11 | linuxstb__ | Think I'll leave it to rest for a while. |
| 14:36:47 | linuxstb__ | 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 | linuxstb__ | http://www.misticriver.net/showthread.php?t=30669 |
| 14:38:12 | preglow | then it flaming IS competitive |
| 14:38:31 | preglow | does cpu usage actually have that much to say? |
| 14:38:32 | linuxstb__ | Or Vorbis is bad.... |
| 14:38:55 | linuxstb__ | But it seems that Rockbox's vorbis is already better than iriver's. |
| 14:39:15 | preglow | what the hell? |
| 14:39:15 | linuxstb__ | (or iriver shuts down too early) |
| 14:39:23 | preglow | the first post there doesn't look very good |
| 14:39:46 | preglow | 112kbps mp3 should never boost either |
| 14:39:51 | preglow | so 11h is a bit... weird... |
| 14:40:02 | | Quit ashridah ("Leaving") |
| 14:40:35 | linuxstb__ | Not sure what this means in that post though: "Backlight usage: Average" |
| 14:40:46 | Slasher | Hmm, i got something like over 17h a long time ago when i tried 128kbps mp3 in "lab mode test" |
| 14:41:12 | preglow | Slasher: lab test mode? |
| 14:41:27 | preglow | linuxstb__: anyway, the extra hour for vorbis is more probably because of rockbox running the battery completely empty |
| 14:41:27 | Slasher | preglow: almost, i never touched the unit during that period |
| 14:41:39 | preglow | Slasher: what is 'lab mode test'? |
| 14:42:00 | linuxstb__ | 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 | Slasher | preglow: just something similar what iriver based it's runtime approximation |
| 14:42:23 | preglow | okies |
| 14:42:26 | preglow | Slasher: btw |
| 14:42:36 | preglow | Slasher: when 'go to next folder' option is on, the buffering stops at the end of a folder |
| 14:42:42 | amiconn | 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 | Slasher | preglow: yes, that is a problem with the playlist |
| 14:42:55 | amiconn | Oh, and btw, there's a crt0.S patch in the tracker :) |
| 14:43:18 | Slasher | 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 | preglow | Slasher: so next folder isnt added to the playlist before it reaches the end of the last song? |
| 14:43:21 | LinusN | saw that |
| 14:43:28 | LinusN | show me the rtim patch |
| 14:43:39 | Slasher | preglow: it looks like that |
| 14:45:21 | linuxstb__ | Sorry for the ignorant question, but what is the "go to next folder" option? What's considered the next folder? |
| 14:45:31 | preglow | the next folder in the dirlist |
| 14:45:44 | LinusN | amiconn: ok, so the only difference is that there is no read-modify-write? |
| 14:46:07 | LinusN | looks good to me |
| 14:46:08 | preglow | 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 | linuxstb__ | I just recursively add the parent directory to the playlist. |
| 14:46:52 | | Quit B4gder ("time to say moo") |
| 14:46:58 | preglow | i gues that's possible as well, i just never use playlists much |
| 14:47:02 | preglow | guess |
| 14:47:02 | webguest82 | What is Linear? |
| 14:47:17 | preglow | webguest82: for the peak meter? it just means it displays the sound level linearly, not as decibel |
| 14:47:22 | preglow | i prefer my peak meter linear |
| 14:47:40 | webguest82 | thanks ^^ |
| 14:47:43 | preglow | much easier to see if a codec doesn't use the full dynamic range that way |
| 14:48:23 | amiconn | LinusN: Some manipulations are read-modify-write, some are not |
| 14:48:47 | linuxstb__ | 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 | preglow | right |
| 14:49:09 | preglow | i haven't played too much with the options either :P |
| 14:49:22 | amiconn | 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 | linuxstb__ | Just sounds like another unneccessary option that complicates the playback engine. |
| 14:49:33 | preglow | truth to be told, i dont listen that much to my player any more |
| 14:49:37 | preglow | since i seldom travel |
| 14:49:37 | LinusN | amiconn: yes |
| 14:49:48 | preglow | still enjoy programming for it, though |
| 14:49:56 | amiconn | That's also why the cpufreq_idle setting needs two accesses to DCR |
| 14:50:37 | amiconn | 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 | preglow | Slasher: btw, do you have any idea why the low watermark boost isn't done in debug builds? |
| 14:51:10 | preglow | Slasher: it skips all the time |
| 14:51:27 | amiconn | ...and interrupts aren't disabled during frequency transition, so sdram accesses might happen |
| 14:51:30 | preglow | it boosts when the buffer is completely empty, but not before |
| 14:52:14 | Slasher | preglow: really? |
| 14:52:26 | Slasher | it works fine here (has always been worked) |
| 14:52:26 | preglow | Slasher: really |
| 14:52:31 | Slasher | weird.. |
| 14:52:34 | preglow | Slasher: linuxstb tried it as well |
| 14:52:45 | Slasher | Hmm, i haven't tried the newest build |
| 14:52:49 | preglow | Slasher: it always worked for me as well, so must be a recent change |
| 14:53:13 | Slasher | And can't compile at the moment because i have some new crossfade code that doesn't compile yet :) |
| 14:53:18 | preglow | hehe |
| 14:53:22 | preglow | what's it do? |
| 14:53:23 | Slasher | oh, interesting |
| 14:53:41 | | Nick linuxstb__ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
| 14:53:56 | Slasher | 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 | preglow | ahh, right |
| 14:54:06 | Slasher | Hopefully that's enough configuration for cf :) |
| 14:54:14 | preglow | should be, yes |
| 14:54:18 | amiconn | Imho it's too much ;) |
| 14:54:27 | Slasher | :D |
| 14:54:32 | preglow | should satisfy the crossfade heads, at least |
| 14:54:37 | Slasher | i hope so |
| 14:54:39 | preglow | i never use it myself |
| 14:55:05 | preglow | perhaps when i begin listening to single tracks instead of albums one day |
| 14:55:11 | linuxstb | Is there an option to only crossfade on shuffle? Or is that one option too much? |
| 14:55:32 | preglow | well, it's a bit hard for the playback engine to know if a playlist is shuffled, i think |
| 14:55:42 | preglow | it would need to check metadata |
| 14:56:25 | preglow | and btw, any reason why mp3data.c is in firmware? |
| 14:56:33 | Slasher | linuxstb: not at the moment but that sounds good to add also |
| 14:56:40 | preglow | i think the firmware and apps semantics need some fixing in places |
| 14:56:54 | linuxstb | preglow: That's how it's always been for the Archos - the mp3 functionality was considered part of the firmware. |
| 14:57:13 | preglow | yeah, i know, but it fits really badly for iriver |
| 14:57:15 | linuxstb | But I'm sure the "elders" have expressed a willingness for it to be moved. |
| 14:57:26 | preglow | i could have implemented stereo settings and playback speed long ago if it wasn't for this |
| 14:57:30 | linuxstb | (they will no doubt correct me if I'm wrong). |
| 14:58:46 | LinusN | preglow: move it then |
| 14:59:07 | LinusN | but then you have to move the archos playback engine as well |
| 14:59:29 | LinusN | which is something we should do anyway |
| 15:00 |
| 15:00:13 | preglow | don't think i'm the right man for that job, i'll undoubtedly screw something up |
| 15:00:21 | LinusN | yes you would :-) |
| 15:00:49 | preglow | since it probably a bit more work than just moving some files |
| 15:00:57 | LinusN | yup |
| 15:07:42 | | Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
| 15:15:37 | preglow | flac.c has tons of unused iram! |
| 15:16:13 | preglow | well, over 10kb at least |
| 15:16:39 | preglow | 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 | preglow | 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 | preglow | right, i actually saved it as floating point |
| 15:38:10 | linuxstb_ | That's the problem. |
| 15:38:36 | linuxstb_ | You can find some 24-bit FLACs at www.archive.org in the live music archive. |
| 15:38:49 | linuxstb_ | But most will also be 96KHz. |
| 15:38:58 | linuxstb_ | Which is pushing Rockbox a little too far. |
| 15:41:46 | markun | I downloaded some 24-bit wav's from a site, but I can't find it anymore. |
| 15:44:09 | markun | here: http://www.soundsonline.com/sophtml/details.phtml?sku=EW-165 (audio demos) |
| 15:45:32 | linuxstb_ | 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 | webguest82 | markun |
| 15:47:06 | linuxstb_ | 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:31 | preglow | yes i do |
| 16:16:48 | preglow | 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 | preglow | .section .icode,"ax",@progbits |
| 16:17:46 | preglow | instead of .text, or whatever i use |
| 16:18:02 | preglow | and that's the only place you need to change anything |
| 16:20:01 | preglow | linuxstb_: i'll try to make a optimised 24 bit lpc routine now |
| 16:20:57 | preglow | 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 | preglow | but of course, there's always other threads |
| 16:22:55 | linuxstb_ | It doesn't hurt - we're wasting the IRAM otherwise. |
| 16:23:07 | preglow | 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 | linuxstb_ | 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 | merbanan | how much of iram is availible ? |
| 16:26:08 | linuxstb_ | Here's a 24/96 FLAC show: http://www.archive.org/audio/etree-details-db.php?id=29456 |
| 16:26:43 | linuxstb_ | 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 | preglow | linuxstb_: only main stack and codec stacks are iram |
| 16:30:04 | linuxstb_ | Should I commit my ICODE changes for FLAC? |
| 16:30:15 | preglow | sure, why not |
| 16:30:38 | linuxstb_ | Everything in libffmpegFLAC is now in IRAM - 43844 bytes |
| 16:30:48 | preglow | so still room for the other lpc routine |
| 16:31:04 | preglow | well, at least it should |
| 16:32:11 | preglow | i'm thinking of various schemes on how to do it |
| 16:32:33 | preglow | i think i'll end up doing to emac passes, with a macsr change inbetween |
| 16:32:39 | preglow | two emac passes, even |
| 16:32:51 | linuxstb_ | OK, that's now in CVS. |
| 16:39:29 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 16:43:05 | linuxstb_ | Oops. Trying to play a 24/96 FLAC causes Rockbox to freeze... |
| 16:44:21 | preglow | ahh, yes, there's that |
| 16:44:29 | preglow | rockbox doesn't support 96 khz yet |
| 16:44:38 | preglow | it supports everything up to 65536hz :-) |
| 16:44:53 | preglow | don't know why it freezes, though |
| 16:44:56 | _FireFly_ | 1bit is missing ;) |
| 16:45:10 | _FireFly_ | to support 96khz |
| 16:45:11 | preglow | i think i'll use a 64 bit mul for the delta calc |
| 16:45:26 | preglow | _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 | preglow | no, no problem, i can just use a 64 bit mul |
| 16:46:59 | _FireFly_ | or that |
| 16:47:57 | preglow | the core probably uses that some other place already, so shouldn't be a problem |
| 16:48:09 | preglow | linuxstb_: exactly how does it freeze? |
| 16:51:07 | preglow | linuxstb_: that's weird, i only the fixed predictor frames in my 24 bit file |
| 16:51:16 | preglow | linuxstb_: even in my -8 encode |
| 16:54:00 | | Join linuxstb__ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
| 16:54:08 | linuxstb__ | I select the file, the WPS displays, but then it feezes before any sound is heard. |
| 16:54:15 | linuxstb__ | It's possible it's a FLAC bug - but the block size and frame size are within limits |
| 16:55:21 | linuxstb__ | 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 | preglow | i'm leeching the fourty meg one now |
| 16:56:05 | linuxstb__ | My ADSL may be unreliable, but the 8Mbit/s downloads are useful. |
| 16:56:09 | preglow | that's all i can take on this piece of moody shit adsl line without going mad |
| 16:56:21 | preglow | i've got about 6mbit download |
| 16:56:24 | preglow | but it's a bit up and down |
| 16:56:36 | linuxstb__ | I think I managed about 150KB/s from www.archive.org |
| 16:56:44 | preglow | 120 here |
| 16:57:02 | preglow | i liked my 100mbit better :/ |
| 16:57:08 | linuxstb__ | I bet you did. |
| 16:57:22 | Maxime | 1.97MB/s on oleane.fr .. |
| 16:58:02 | linuxstb__ | Maxime: What upload speeds do you get? |
| 16:58:17 | Maxime | ah in upload you speak? |
| 16:58:33 | Maxime | I'm on a 20M/1024K |
| 16:58:39 | linuxstb__ | My connection is 8Mbit/s download and 512kbps upload. |
| 16:59:41 | Maxime | where you are, does ADSL2+ exists? |
| 17:00 |
| 17:00:03 | linuxstb__ | Not yet, but I think it's coming in the next few months. |
| 17:00:12 | linuxstb__ | I'm in London. |
| 17:00:17 | Maxime | ok |
| 17:00:21 | Maxime | (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 | preglow | so, no one's got 24 bit flac files at ordinary sample rates? |
| 17:13:07 | linuxstb | Yes, I've got a 24-bit/44.1KHz file. Should I upload it somewhere? |
| 17:13:37 | preglow | dcc/upload/mail/whatever suits you best |
| 17:14:51 | linuxstb | Uploading now. Will PM the URL. |
| 17:15:06 | linuxstb | ETA about 5 minutes. |
| 17:16:28 | preglow | goodie |
| 17:22:15 | preglow | 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 | markun | preglow: there have been plans (for years) to switch to libogg2 |
| 17:24:21 | markun | Tremor's ogg handling is based on it, http://svn.xiph.org/trunk/ogg2/ |
| 17:24:35 | preglow | is it, now |
| 17:25:01 | preglow | i was just hoping that container format parsin wouldn't add any overhead |
| 17:25:02 | markun | Don't know if it's better. Maybe it's not so difficult to get libspeex to work with it. |
| 17:25:13 | preglow | but with libogg it seems like it's going to |
| 17:25:21 | preglow | markun: my first try will be to get flac working with it |
| 17:25:35 | markun | libogg or libogg2? |
| 17:25:49 | preglow | i'll have to have a further look before i decide on that |
| 17:25:55 | preglow | the libogg2 api is still under discussion |
| 17:26:33 | preglow | i wonder what happened to theora |
| 17:27:26 | markun | btw I made a joining function for arabic. Don't know if anyone is interested. |
| 17:28:12 | markun | I've been googling for an arabic iriver forum, but didn't find one. |
| 17:28:22 | preglow | seems ogg2 is zerocopy, yes |
| 17:28:50 | markun | 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 | linuxstb_ | Is ogg2 just a different API to the same format, or a new format? |
| 17:31:38 | markun | different api |
| 17:34:49 | linuxstb_ | preglow: Check your email for that FLAC file URL. |
| 17:35:45 | preglow | goodie |
| 17:35:46 | preglow | 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 | amiconn | 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 | preglow | amiconn: the routines are in libgcc, so it would have to be before that |
| 17:48:02 | preglow | amiconn: but otherwise, i think we should do it, your routine beats the gcc one by far |
| 17:49:25 | amiconn | Yeah, it's both smaller & faster |
| 17:50:01 | linuxstb | Would putting it in the codec lib work? |
| 17:50:46 | _FireFly_ | amiconn: what about the accuracy?? |
| 17:50:51 | amiconn | The name is __muldi3 |
| 17:51:03 | amiconn | _FireFly_: It's bit accurate |
| 17:51:25 | _FireFly_ | better as the gcc one |
| 17:51:34 | linuxstb | 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 | amiconn | _FireFly_: It's the same accuracy, it has to be |
| 17:52:50 | amiconn | We're talking about the 64*64->64bit integer multiplication |
| 17:56:20 | linuxstb | IIUC, the FLAC routine just needs a 32*32->64-bit multiplication. |
| 17:57:34 | preglow | linuxstb: yes |
| 17:57:46 | preglow | i'll just use both modes of the emac unit |
| 17:57:54 | amiconn | 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 | linuxstb | Which codecs need a 64x64->64 mult? |
| 17:59:38 | amiconn | 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 |
| 18:00:56 | amiconn | 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 | linuxstb | 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 | LinusN | every cycle counts |
| 18:06:27 | LinusN | the more time the cpu can spend in the idle sleep mode the better |
| 18:06:27 | preglow | indeed |
| 18:07:18 | preglow | ok, now let's hope that flac never uses the top bit in the accumulator |
| 18:07:48 | preglow | amiconn: would finding the top bit in the mul be much trouble? without performing another mul, that is |
| 18:08:10 | preglow | afaik, the top bit wil only be used if the two numbers in the mul are 0x80000000 and 0x80000000 |
| 18:11:54 | amiconn | yep, and it's possible, sacrificing 4 extra cpu cycles (5 if the correction is to be made) |
| 18:12:06 | linuxstb | Looking at the code (decode_subframe_lpc), the coefficients seem to only be a maximum of 15 bits. |
| 18:12:19 | linuxstb | So unless I'm misunderstanding, it's a 15-bit x 32-bit multiplication. |
| 18:15:41 | preglow | really, now |
| 18:16:26 | preglow | i wonder if i should even try to do a fraction emac mode solution only |
| 18:16:52 | preglow | 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 | linuxstb | s/wav/flac/ ?? |
| 18:17:27 | preglow | yes :) |
| 18:17:49 | linuxstb | Do you agree that it's a 15x32 multiplication? |
| 18:20:05 | | Join z0rr0 [0] (i=z0rr0@217.30.249.24) |
| 18:23:07 | preglow | most certainly looks like it, yes |
| 18:23:58 | preglow | but the other numbers might be anything then |
| 18:25:30 | linuxstb | Yes, anything up to 32-bits I think. |
| 18:26:03 | linuxstb | 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 | preglow | and i wonder what range qlevel is in |
| 18:27:27 | preglow | seems like it can be anything up to 32 |
| 18:27:41 | preglow | in which case the fractional mode might end up a bit tricky |
| 18:28:07 | linuxstb | Yes - qlevel is 5 bits |
| 18:29:02 | linuxstb | Do you know if wavpack has a similar routine? |
| 18:29:16 | preglow | hmm, no, wavpack does things sligtly differently, i believe |
| 18:29:27 | preglow | but it only uses frac mode, so it's got to do something similar |
| 18:29:37 | preglow | i haven't talked to david bryant for quite a while, so don't know |
| 18:30:04 | preglow | he's busy with a new version of wavpack, i think |
| 18:34:28 | preglow | 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 | preglow | 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 | preglow | but if sixteen bit output precision is ok, it might work |
| 18:48:12 | linuxstb | It would be much nicer to get the full 24-bit output - it's controversial to have an inaccurate FLAC decoder. |
| 18:49:13 | preglow | yep, than that's what i'll do |
| 18:49:20 | preglow | this is how wavpack handles it, btw |
| 18:49:48 | preglow | it doesn't guarantee that the lowest bits are accurate in a high res file |
| 18:49:54 | preglow | that is, our implementation of wavpack |
| 18:50:27 | linuxstb | 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:00 |
| 19:05:03 | preglow | indeed |
| 19:06:58 | preglow | 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 | preglow | amiconn: will a 64 bit variable shift routine be big? |
| 19:07:34 | preglow | left shift, that is |
| 19:07:51 | amiconn | Not really |
| 19:07:59 | preglow | how many registers will it use? |
| 19:08:04 | amiconn | It's a sub, 3 shifts and an or |
| 19:08:15 | preglow | i don't want to stack any variables :/ |
| 19:08:30 | amiconn | One additional register besides the operands |
| 19:08:31 | preglow | and i've only got one register free at the moment |
| 19:08:31 | preglow | argh |
| 19:08:37 | preglow | that's one more than i have |
| 19:08:38 | preglow | hrmph |
| 19:09:08 | preglow | in the worst case, that is |
| 19:10:12 | linuxstb | Does the DSP just truncate to 16-bits at the moment? |
| 19:11:30 | preglow | no |
| 19:11:35 | preglow | well, at the end it does |
| 19:11:37 | preglow | after processing |
| 19:11:49 | preglow | 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 | preglow | the whole point of having more than 16 bits precision is so some kind of processing can benefit from it |
| 19:13:50 | linuxstb | 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 | preglow | well, i certainly agree on that |
| 19:14:24 | preglow | i'll just see if a can free a register somewhere |
| 19:16:08 | preglow | well, i guess i can free the fetch variable and just add an extra move before the accumulator chains |
| 19:16:12 | preglow | chain |
| 19:16:47 | linuxstb | 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 | amiconn | preglow: If you wanna see the 32*32->64 top bit correction: http://amiconn.dyndns.org/muls323264.S |
| 19:19:32 | preglow | linuxstb: not exactly a crying matter |
| 19:21:44 | preglow | 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 | preglow | amiconn: what's up with the trap? how is that possible? |
| 19:26:57 | preglow | i thought trap was a one-word instruction |
| 19:27:10 | amiconn | No, there is trapf, trapf.w and trapf.l |
| 19:27:28 | amiconn | Check CFPRM.pdf (it's called tpf there) |
| 19:27:46 | preglow | ahh, so it's tpf |
| 19:28:47 | amiconn | 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 | amiconn | So either the trapf.w/trapf.l, or the shadowed instruction needs to be given as hex word(s) |
| 19:30:04 | amiconn | It's easier to reach the shadowed instruction with the first method |
| 19:31:08 | markun | 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 | preglow | 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 | markun | linuxstb: Are you closer to real-time decoding with aac? |
| 19:51:47 | amiconn | 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 | amiconn | Hopefully the code size decreased enough by then to allow for unicode support without slef-extraction |
| 19:53:31 | amiconn | About your arabic function: Imho 6KB is a bit heavy for it to reside in the core - just for one language |
| 19:53:56 | amiconn | ARe there many arabic rockbox users? What if other languages need simiar functions? |
| 19:55:02 | amiconn | There's an idea I'm thinking about for quite a while: rockbox should probably have language specific "plugin" code |
| 19:55:02 | markun | 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 | amiconn | 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 | amiconn | For example, 21 is "twenty one" in english, but the equivalent of "one-and-twenty" in german |
| 19:57:41 | markun | Should the arabic language plugin be loaded loaded when an arabic string is found or only when the user selects it? |
| 19:58:12 | amiconn | Hmm, arabic strings in filenames are a problem with that concept... |
| 19:58:28 | amiconn | My idea was to use it depending on the loaded .lng file |
| 19:59:13 | linuxstb | 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 | markun | amiconn: If you would like to take a look at the test code: http://130.89.160.166/rockbox/arabjoin.c |
| 20:00 |
| 20:01:17 | markun | 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 | preglow | markun: there's the helix decoder, which we can't use |
| 20:01:32 | linuxstb | There is one - the helix/real decoder. |
| 20:01:34 | preglow | that's almost certainly better |
| 20:02:53 | preglow | to optimise aac further, i'll need to dig into the source a bit and see how it works |
| 20:04:02 | linuxstb | There is always the ISO reference decoder. I don't know what license that's released under though. |
| 20:04:32 | preglow | ahaha |
| 20:04:34 | preglow | don't think about it |
| 20:04:39 | preglow | the reference decoders are always wildly shitty |
| 20:04:55 | linuxstb | But so is libfaad as far as we are concerned. |
| 20:05:03 | preglow | not _that_ shitty, i'm sure |
| 20:05:07 | preglow | but feel free to check it out |
| 20:05:26 | preglow | anyways |
| 20:05:39 | preglow | getting libmad to work as fast as it does today didn't exactly happen overnight either |
| 20:06:05 | Maxime | erm |
| 20:06:17 | Maxime | i've a question, i've had a strange issue this afternoon |
| 20:06:33 | Maxime | I was listening to radio, then I put one MP3, then I had the sound of the radio AND the mp3 |
| 20:06:46 | preglow | you probably exited the radio wrongly |
| 20:06:50 | Maxime | yeah |
| 20:06:54 | Maxime | this is funny so :p |
| 20:06:55 | Maxime | lol |
| 20:07:17 | Maxime | and I had a *PANIC$ |
| 20:07:49 | preglow | that's not intended, actually... |
| 20:07:50 | Maxime | 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 | preglow | you don't use any jpeg related patches? |
| 20:08:16 | Maxime | no |
| 20:08:26 | Maxime | it's the daily build from this morning |
| 20:09:47 | amiconn | markun: This is really 6KB of compiled code? Or do you mean it is 6KB as a test program? |
| 20:10:26 | amiconn | 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 | markun | yes, true. |
| 20:11:01 | markun | I was a bit pessimistic (and stupid) I guess |
| 20:11:11 | amiconn | 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 | linuxstb | preglow: You're right about the AAC reference code. I've now deleted it. |
| 20:13:28 | linuxstb | 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 | Maxime | (great the JPG viewer tho.. ^^) |
| 20:14:59 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
| 20:20:07 | markun | amiconn: With shorts and the big table included, arabjoin.o is 2732 bytes |
| 20:21:30 | amiconn | The .o doesn't tell much about the final code size. |
| 20:21:53 | amiconn | You would need to link, and then check the .map and/ or the binary |
| 20:21:57 | preglow | 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 | amiconn | Size can also vary significantly depending on the target |
| 20:22:37 | amiconn | (not the table though) |
| 20:26:37 | preglow | 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 | preglow | 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 | preglow | 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 | amiconn | 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 | preglow | iram |
| 20:34:09 | amiconn | 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 | preglow | 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 | preglow | i'm almost convinced the first method is faster |
| 20:36:02 | amiconn | 'almost' isn't 100% ;-) |
| 20:36:12 | | Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
| 20:36:12 | preglow | it is if you can't be bothered do to tests :P |
| 20:36:31 | amiconn | Well, memcpy is all about tests, tests, tests... |
| 20:36:41 | preglow | yup, and it's a bit more important for memcpy as well |
| 20:36:47 | amiconn | You see why it takes that long :-) |
| 20:36:54 | preglow | sure |
| 20:37:34 | preglow | amiconn: hmm, from i can see in your libmusepack shifting routine, you need two additional registers for shifting |
| 20:37:49 | amiconn | Not necessarily |
| 20:38:15 | amiconn | You said you need variable shift. One of the additional registers is the shift count |
| 20:38:58 | preglow | well, i see t2 and t1 as well |
| 20:39:23 | amiconn | Yes, but that's not only a 64 bit left shift. |
| 20:39:36 | preglow | no? |
| 20:39:52 | amiconn | It even is not a 64 bit shift at all. |
| 20:41:19 | amiconn | The shift part is a 'shortened' 64 bit right shift, in that we only need 32 bits of the result |
| 20:42:32 | preglow | that's what i want as well |
| 20:44:23 | amiconn | t1 is the result. You can reuse the same register that's used for the 'y' input |
| 20:44:35 | amiconn | (if you don't need it again afterwards) |
| 20:45:56 | preglow | i've got three registers |
| 20:46:05 | preglow | two of them contains a 64 bit number, the last one is free |
| 20:46:21 | preglow | the shift amount is contained in another register |
| 20:49:08 | amiconn | It's possible to save one register (with some penalty) if it's allowed to destroy the shift count |
| 20:49:21 | preglow | it's not |
| 20:49:32 | amiconn | It's possible to restore it, with some more penalty |
| 20:49:58 | preglow | 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 | preglow | ehh, that's wrong :> |
| 20:50:50 | amiconn | 5+8 = 13, only 2 registers left |
| 20:50:52 | preglow | yes, four contain parameters |
| 20:51:06 | preglow | i didth the order parameter, since the loop is unrolled and order thus hard coded |
| 20:51:07 | preglow | ditch |
| 20:51:11 | amiconn | Where do you get your 64 bit data from? |
| 20:51:21 | preglow | two sets of mac.l chains |
| 20:51:29 | preglow | one for the high bits, one for the low bits |
| 20:51:41 | amiconn | So, from the %accn registers? |
| 20:51:44 | preglow | yup |
| 20:51:55 | preglow | ahh, right |
| 20:51:59 | amiconn | Then it's possible, by reading one value twice |
| 20:52:06 | amiconn | (first time without movclr) |
| 20:52:12 | preglow | yes, necessarily :) |
| 20:52:32 | amiconn | You want to shift right? |
| 20:54:28 | preglow | yup |
| 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:39 | preglow | i've got more bits available in seven of the eight unrolled cases |
| 21:08:58 | preglow | registers, yes |
| 21:12:08 | preglow | but not so in the order > 8 case |
| 21:12:15 | preglow | which will undoubtedly be fun no matter how i do it |
| 21:14:23 | | Quit _FireFly_ ("Leaving") |
| 21:15:37 | preglow | 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 | amiconn | Just the tick counter, with enough repeats to make it sufficiently high precision |
| 21:16:08 | preglow | yes |
| 21:20:15 | amiconn | In the 16 bit routines, you only need to preserve 11 registers within the loop |
| 21:20:21 | muesli_- | re |
| 21:20:55 | amiconn | .. 8 coefficients, a0, d0 and a1. So what is the 4th parameter in the 24 bit case? |
| 21:21:30 | preglow | amiconn: eleven registers? i need to preserve four parameters, plus eight coefs, worst case |
| 21:22:10 | preglow | amiconn: i preserve d0, d1, a0, a1 |
| 21:22:27 | amiconn | Why a1? It's only needed at the start to load the coefficients... |
| 21:22:35 | preglow | :-) |
| 21:22:36 | *** | Saving seen data "./dancer.seen" |
| 21:22:51 | preglow | yes, valid point, valid point |
| 21:22:54 | | Join linuxstb_ [0] (n=5343d4aa@labb.contactor.se) |
| 21:24:05 | amiconn | You can even reuse a1 in the movem |
| 21:24:33 | preglow | indeed i can |
| 21:24:44 | preglow | 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 | linuxstb_ | preglow: In your 32-bit LPC routine, is it possible to unroll any of the higher (i.e. > 8) orders? |
| 21:42:48 | amiconn | 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: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:28 | preglow | linuxstb_: perhaps 9 |
| 22:36:54 | preglow | linuxstb_: i can unroll some instances in the older 16 bit version for sure |
| 22:37:07 | preglow | up to ten |
| 22:37:13 | preglow | should i? |
| 22:38:13 | preglow | i hate code like this, tons of duplicated code everywhere |
| 22:38:46 | TiMiD | amiconn: it's not a bug, it's wanted ... |
| 22:39:36 | linuxstb_ | 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 | TiMiD | I thought it would be more logicla to do like that with all text outputs |
| 22:39:53 | linuxstb_ | So yes, I think it's worthwhile. |
| 22:40:22 | linuxstb_ | I wouldn't worry about duplication either - I know it's untidy, but we have IRAM to spare for FLAC. |
| 22:40:48 | amiconn | TiMiD: Hmm.... |
| 22:41:02 | | Quit dpassen1 () |
| 22:41:26 | TiMiD | since it's handled generically anyway ... |
| 22:41:36 | amiconn | It looks rather odd, and the next message doesn't do that |
| 22:41:37 | preglow | linuxstb_: well, i can't unroll orders that high |
| 22:41:41 | amiconn | (the rolo thing) |
| 22:42:04 | linuxstb_ | preglow: I know. |
| 22:42:42 | TiMiD | the rolo message ? |
| 22:42:52 | TiMiD | you mean when it's rebooting ? |
| 22:43:50 | amiconn | yes |
| 22:44:30 | preglow | 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 | preglow | 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 | amiconn | The reboot request keeps the status bar, but the rolo message does not |
| 22:44:39 | amiconn | That's one reason why I thought it's a bug |
| 22:44:39 | amiconn | The other reason is that it looks squeezed |
| 22:44:43 | TiMiD | I didn't looked at that part of the code |
| 22:45:04 | TiMiD | so I didn"t changed it |
| 22:45:27 | amiconn | Related to that, it's probably a good idea to have a request widget |
| 22:45:45 | amiconn | ...at least for the common yes/no requests |
| 22:46:12 | TiMiD | hmm like the other one used for "reset settings" |
| 22:46:14 | TiMiD | ? |
| 22:46:52 | amiconn | Yes. Iirc there are more yes/no requests than just these 2 |
| 22:47:15 | TiMiD | I didn't thought about that but it's surea good idea :) |
| 22:47:28 | TiMiD | I'm doing right now a generic select widget |
| 22:47:39 | TiMiD | fthe menus |
| 22:47:53 | TiMiD | (for the ) |
| 22:48:00 | amiconn | This idea is even older than your gui work, just nobody implemented it yet |
| 22:48:43 | TiMiD | there is something like this in settings.c |
| 22:49:15 | TiMiD | but lot of code is duplicated since it handles bool, int, strings ... |
| 22:49:49 | TiMiD | anyway, about the statusbar, do you think it should be removed ? |
| 22:49:59 | amiconn | 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 | TiMiD | I don't know about that |
| 22:50:35 | TiMiD | 1kb of c code less >> binary smaller by 100 bytes |
| 22:50:42 | amiconn | I know that there is still some work left. Settings, radio screen recording screen, keyboard.... |
| 22:50:43 | TiMiD | not very efficient ;) |
| 22:50:57 | amiconn | Well, that varies a lot |
| 22:51:01 | preglow | seems we've got 64 bit flac, yes |
| 22:51:10 | preglow | 24 bit, at that |
| 22:51:19 | * | linuxstb_ cheers |
| 22:51:23 | amiconn | I was about to ask... |
| 22:51:42 | preglow | i got diverted for an hour |
| 22:51:50 | TiMiD | I try to do the work so that we can remove the old functions the sooner possible |
| 22:52:07 | TiMiD | there is also len0x and firefly helping |
| 22:57:44 | amiconn | 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 | amiconn | And you waste an instruction and a move :) |
| 22:58:13 | amiconn | I mean, a move instruction and a register |
| 22:58:36 | preglow | amiconn: i could just use duffs device for the residual handling |
| 22:58:47 | amiconn | ?? |
| 22:58:48 | preglow | at least the assembler equivalent of duffs device :) |
| 22:59:20 | preglow | three mac instructions, and just jump to the one giving me enough macs for the residual |
| 23:00 |
| 23:00:34 | amiconn | 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 | amiconn | 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 | amiconn | just use moveq.l #3,%d3 / and.l %d2,%d3 |
| 23:02:33 | amiconn | The and operation is commutative |
| 23:03:19 | preglow | 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 | preglow | amiconn: when you said i could reuse a1 in the movem |
| 23:36:22 | preglow | did you mean the following is possible: movem (%a1), %d0-d7/%a1-%a6 ? |
| 23:37:06 | amiconn | yeps |
| 23:37:31 | preglow | and it is! funnily enough, it turns out i screwed up some place else |
| 23:37:37 | preglow | who'd have thunk it |
| 23:37:50 | | Quit linuxstb (Read error: 110 (Connection timed out)) |
| 23:42:07 | preglow | i must be doing something completely moronic here |
| 23:43:00 | preglow | tell me |
| 23:43:07 | preglow | www.pvv.org/~thomj/rockbox/snip |
| 23:43:27 | preglow | 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 | amiconn | yes |
| 23:47:13 | preglow | then i wonder what the static bursts i guess mean |
| 23:47:18 | preglow | something else, i hope |
| 23:47:25 | amiconn | provided qlevel <= 32 |
| 23:48:16 | preglow | yes, it is |
| 23:48:29 | preglow | qlevel can't be even close to 32 |
| 23:49:00 | preglow | 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 |
icon identifies that the person is a core developer (has commit access).