| 00:00:10 | Lear | so would it mostly be a question of enabling it and getting the audio routing right then? |
| 00:00:37 | amiconn | No, we need an i2c driver for the chip and some adjustments in the radio screen as well |
| 00:01:29 | amiconn | LinusN: Maybe rombox makes no sense for actually running it (I'm still not fully convinced btw), but it has at least one benefit for development: it allows to actually check whether 'const' is used correctly |
| 00:02:01 | amiconn | It depends on the access speed of the ROM vs. the RAM |
| 00:02:16 | amiconn | Iriver RAM is sloow, so.... |
| 00:04:33 | | Join ashridah [0] (i=ashridah@220-253-123-146.VIC.netspace.net.au) |
| 00:05:08 | LinusN | amiconn: correct const usage is mainly valuable when running from rom |
| 00:05:38 | amiconn | Mainly, but not only |
| 00:10:18 | | Join webguest30 [0] (n=51429e1d@labb.contactor.se) |
| 00:10:33 | webguest30 | Hello folks |
| 00:10:33 | Lear | OT: Why does cygwin ship with such an old version of tar... :/ |
| 00:11:19 | webguest30 | quick question for the core developers |
| 00:12:15 | webguest30 | there are a lot of patches in the tracker who could be very good for rockbox |
| 00:12:30 | | Join amiconn_ [0] (n=jens@p54BD7405.dip.t-dialin.net) |
| 00:12:32 | | Join tofusalad [0] (n=450aa184@labb.contactor.se) |
| 00:12:47 | webguest30 | just wondering why the core devlopers can't apply them |
| 00:13:01 | webguest30 | is it hard to do? |
| 00:13:03 | Bagder | time |
| 00:13:19 | webguest30 | a ok, the patches are incompleted? |
| 00:13:21 | Bagder | some are hard, some are easy |
| 00:13:27 | Bagder | they all require time |
| 00:13:28 | LinusN | often, yes |
| 00:13:35 | webguest30 | ok |
| 00:13:49 | Bagder | its very easy to throw in a quick hack in the tracker |
| 00:14:15 | Bagder | that breaks 7 builds and isn't following our coding standards |
| 00:14:31 | Bagder | ... and then 27 people in the forums ask why it isn't in the CVS yet |
| 00:14:32 | webguest30 | ok |
| 00:14:48 | * | Bagder is a cynic today |
| 00:14:52 | webguest30 | scuse me for this stupid question :) |
| 00:14:55 | Bagder | hehe |
| 00:15:01 | Bagder | no worries really |
| 00:15:12 | webguest30 | :) |
| 00:15:15 | webguest30 | :) |
| 00:16:00 | webguest30 | i see for exemple one fix for dsp |
| 00:16:25 | webguest30 | in Lear's and Slasheri territory |
| 00:16:33 | Bagder | if you apply the patches and try them out |
| 00:16:35 | Bagder | it helps |
| 00:16:50 | webguest30 | a ok |
| 00:17:05 | Bagder | knowing that the patches work/fix the problems are often a good feedback |
| 00:17:15 | webguest30 | the patch tracker don't have few restrictions for prevent this? |
| 00:17:21 | Lear | I know Linus is working on applying one dsp-related patch... |
| 00:17:26 | LinusN | yes i am |
| 00:17:35 | webguest30 | a ok :) |
| 00:17:36 | amiconn_ | Btw, the hebrew/arabic patch still has a problem. |
| 00:18:13 | amiconn_ | While it does no longer modify the input string (which isn't allow since it is a const), it now isn't reentrant |
| 00:18:30 | amiconn_ | ...which is a problem with the 2 LCD drivers on iriver |
| 00:18:38 | | Quit amiconn (Nick collision from services.) |
| 00:18:39 | | Nick amiconn_ is now known as amiconn (n=jens@p54BD7405.dip.t-dialin.net) |
| 00:19:07 | amiconn | I considered adding that call to lcd-h100-remote.c, but the dropped the idea |
| 00:19:08 | webguest30 | I don't understand the patch "add to playlist" in the tracker maybe hardeep can explain me? |
| 00:19:44 | amiconn | ...because of my idea to introduce a secondary UI thread for the remote one day |
| 00:20:24 | webguest30 | please do amiconn if you have time :) |
| 00:21:08 | webguest30 | the Xavier's patch is good but not the good way |
| 00:21:08 | | Quit tofusalad ("CGI:IRC (EOF)") |
| 00:21:25 | amiconn | Hmm, maybe there is no problem, I need to think a bit about it again |
| 00:21:52 | Lear | if the bidi patch uses static buffers, then it would be, I think... |
| 00:21:58 | amiconn | Otherwise the problem would hit even without a secondary display, when the scroll thread does its work in parallel to the ui... |
| 00:22:45 | amiconn | Lear: Maybe not. Sometimes I forget that rockbox does cooperative multitasking, and that allows to do some things that are forbidden with preemptive multitasking |
| 00:23:14 | Lear | quite true... |
| 00:23:24 | amiconn | Yes, it uses static buffers to reverse the rtl parts if bidi is enabled |
| 00:24:16 | amiconn | However, there is no yield() between the reversal and the actual output |
| 00:24:43 | amiconn | As long as no interrupt routine tries to use lcd text output... |
| 00:25:42 | Lear | Otoh, it only needs to reverse the on-screen chars, afaict, so a small stack buffer in the lcd driver would be enough, wouldn't it? |
| 00:26:18 | amiconn | I hope that someone completes the unicode patch one day... |
| 00:26:45 | amiconn | Lear: I'm not sure |
| 00:27:26 | amiconn | The problematic thing is that with bidi, you don't know which part of the original string needs to be displayed before actually doing the reversal |
| 00:28:29 | Lear | btw, found another ctype bug the other day... |
| 00:28:41 | amiconn | If it is a long string which consists of arabic (or hebrew) only, it will be the end of the string, but not if the string contains both arabic/hebrew and latin... |
| 00:28:56 | | Quit ashridah ("uni. mutter") |
| 00:33:21 | hardeep | webguest30: I don't really understand the purpose of that patch either... re: add to playlist |
| 00:33:53 | HCl | hey amiconn.. think you'll have a little time soon to check those rundb events on archos..? |
| 00:38:38 | webguest30 | Hardeep: i find this discussion for understand a bit but not really http//forums.rockbox.org/index.php?topic=1185.0 |
| 00:39:11 | webguest30 | http://forums.rockbox.org/index.php?topic=1185.0 |
| 00:39:59 | webguest30 | if it can help you didn't read it |
| 00:41:17 | webguest30 | prethom: spexx is it again in your plan? |
| 00:43:21 | webguest30 | nope? |
| 00:45:23 | webguest30 | Good evenings all and still thanks for all your works |
| 00:45:40 | | Part webguest30 |
| 00:50:31 | *** | Saving seen data "./dancer.seen" |
| 01:00 |
| 01:05:21 | | Quit _aLF ("Leaving") |
| 01:12:16 | | Quit Lear ("Chatzilla 0.9.68.5 [Firefox 1.0.6/20050720]") |
| 01:21:54 | | Quit dpassen1 (Remote closed the connection) |
| 01:25:01 | | Join Febs [0] (n=Febs@207-172-122-81.c3-0.rdl-ubr4.trpr-rdl.pa.cable.rcn.com) |
| 01:28:55 | prethom | webguest30: yes, ill add speex support soonish, if you read the logs |
| 01:32:07 | prethom | amiconn: if you want faster layer 1/2 playback, there are a couple of frequently used tables in layer12.c that could probably benefit from being in iram |
| 01:35:54 | | Quit ghostiger ("Leaving") |
| 01:42:54 | prethom | im off |
| 01:42:58 | | Quit prethom ("foop") |
| 01:47:52 | | Quit Moos (" Try HydraIRC -> http://www.hydrairc.com <-") |
| 02:00 |
| 02:00:59 | | Join TCK- [0] (i=TCK@81-86-96-223.dsl.pipex.com) |
| 02:05:55 | | Join OnkelJonas [0] (n=kartoffe@ip230.rev112.brygge.net) |
| 02:06:30 | | Part OnkelJonas |
| 02:15:21 | | Join Omar [0] (n=nospam@cpc4-eswd1-3-0-cust156.renf.cable.ntl.com) |
| 02:19:19 | | Quit TCK (Read error: 110 (Connection timed out)) |
| 02:41:36 | * | LinusN goes to sleep |
| 02:41:39 | | Part LinusN |
| 02:43:03 | | Quit Omar () |
| 02:50:34 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:07:42 | | Quit Sucka ("a bird in the bush is worth two in your house") |
| 03:08:15 | | Join dpassen1 [0] (n=derek@cpe-24-168-110-99.si.res.rr.com) |
| 03:12:44 | | Quit Rick (Read error: 104 (Connection reset by peer)) |
| 03:13:51 | | Join Rick [0] (i=rick@pool-71-108-13-143.lsanca.dsl-w.verizon.net) |
| 03:19:43 | | Quit Rick (Read error: 104 (Connection reset by peer)) |
| 03:20:40 | | Join Rick [0] (i=rick@pool-71-108-13-143.lsanca.dsl-w.verizon.net) |
| 03:24:59 | | Quit Rick (Read error: 104 (Connection reset by peer)) |
| 03:25:09 | | Join ansivirus [0] (n=ansiviru@ppp-69-148-71-237.dsl.rcsntx.swbell.net) |
| 03:26:20 | | Join Rick [0] (i=rick@pool-71-108-13-143.lsanca.dsl-w.verizon.net) |
| 03:34:17 | | Quit Rick (Read error: 104 (Connection reset by peer)) |
| 03:35:54 | | Join Rick [0] (i=rick@pool-71-108-13-143.lsanca.dsl-w.verizon.net) |
| 03:38:51 | | Quit lostlogic (Read error: 110 (Connection timed out)) |
| 03:38:51 | | Quit Rick (Read error: 104 (Connection reset by peer)) |
| 03:40:01 | | Join Rick [0] (i=rick@pool-71-108-13-143.lsanca.dsl-w.verizon.net) |
| 03:40:57 | | Quit Rick (Read error: 104 (Connection reset by peer)) |
| 03:41:19 | | Quit ansivirus ("Leaving") |
| 03:42:08 | | Join Rick [0] (i=rick@pool-71-108-13-143.lsanca.dsl-w.verizon.net) |
| 04:00 |
| 04:06:10 | | Join QT_ [0] (i=as@madwifi/users/area51) |
| 04:18:04 | | Quit QT (Read error: 110 (Connection timed out)) |
| 04:33:41 | | Join edx__ [0] (i=edx@p54A8DBB0.dip.t-dialin.net) |
| 04:39:28 | | Quit Strath ("Client closed") |
| 04:48:15 | | Quit edx (Read error: 110 (Connection timed out)) |
| 04:48:20 | | Join rubberglove [0] (n=46308405@labb.contactor.se) |
| 04:50:36 | *** | Saving seen data "./dancer.seen" |
| 04:54:26 | | Quit rubberglove ("CGI:IRC (EOF)") |
| 04:59:53 | | Join solex_ [0] (n=jrschulz@c219041.adsl.hansenet.de) |
| 05:00 |
| 05:10:24 | | Quit solex (Connection timed out) |
| 05:10:53 | | Join lostlogic [0] (n=lostlogi@node-4024215a.mdw.onnet.us.uu.net) |
| 05:26:06 | | Nick edx__ is now known as edx (i=edx@p54A8DBB0.dip.t-dialin.net) |
| 05:28:39 | | Quit lostlogic (Read error: 145 (Connection timed out)) |
| 05:51:45 | | Quit hardeep ("[BX] Automatically bored away") |
| 06:00 |
| 06:12:51 | | Quit dpassen1 ("Friends Don't Let Friends Listen To Anti-Flag") |
| 06:20:37 | | Join Coldtoast [0] (i=edan@ppp110-114.lns1.hba1.internode.on.net) |
| 06:50:37 | *** | Saving seen data "./dancer.seen" |
| 06:58:03 | | Quit Ismo (Read error: 104 (Connection reset by peer)) |
| 06:58:13 | | Join Ismo [0] (i=laitinei@huippu.net) |
| 07:00 |
| 07:14:20 | | Quit thegeek (Read error: 104 (Connection reset by peer)) |
| 07:16:03 | | Join thegeek [0] (n=thegeek@s201a.studby.ntnu.no) |
| 07:49:11 | | Quit merbanan (Read error: 104 (Connection reset by peer)) |
| 07:49:55 | | Join merbanan [0] (i=banan@dalink.campus.luth.se) |
| 07:51:11 | | Quit thegeek (Read error: 104 (Connection reset by peer)) |
| 07:51:43 | | Join thegeek [0] (n=thegeek@s201a.studby.ntnu.no) |
| 07:55:41 | | Join banan_ [0] (i=banan@dalink.campus.luth.se) |
| 07:56:03 | | Quit merbanan (Read error: 104 (Connection reset by peer)) |
| 07:58:53 | | Join Maxime [0] (n=flemmard@cartec.net2.nerim.net) |
| 08:00 |
| 08:16:48 | | Quit Seed (Read error: 110 (Connection timed out)) |
| 08:27:17 | | Join SRM [0] (i=Shamrock@68-112-49-085.dhcp.hlrg.nc.charter.com) |
| 08:28:18 | | Quit crashd (Remote closed the connection) |
| 08:29:33 | | Quit ShamrockMan (Read error: 104 (Connection reset by peer)) |
| 08:29:39 | | Join banan__ [0] (i=banan@dalink.campus.luth.se) |
| 08:29:55 | | Quit banan_ (Read error: 104 (Connection reset by peer)) |
| 08:31:13 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 08:33:28 | | Join crashd [0] (i=nobody@badger.ing.me.uk) |
| 08:50:40 | *** | Saving seen data "./dancer.seen" |
| 08:57:29 | | Join LinusN [0] (N=linus@labb.contactor.se) |
| 09:00 |
| 09:00:13 | | Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) |
| 09:06:03 | | Quit pabs (Remote closed the connection) |
| 09:06:05 | | Join pabs [0] (n=pabs@ip68-100-248-22.dc.dc.cox.net) |
| 09:24:59 | | Join lostlogic [0] (n=lostlogi@node-4024215a.mdw.onnet.us.uu.net) |
| 09:52:57 | | Join ashridah [0] (i=ashridah@220-253-123-47.VIC.netspace.net.au) |
| 09:57:40 | | Quit Rick (Read error: 104 (Connection reset by peer)) |
| 09:58:15 | | Join Rick [0] (i=rick@pool-71-108-13-143.lsanca.dsl-w.verizon.net) |
| 10:00 |
| 10:04:21 | ReKleSS | anyone know why I would be getting a floating point exception when I try to run the ui simulator, build for iriver? |
| 10:08:47 | ReKleSS | same thing happens if it's build for archos |
| 10:09:02 | LinusN | hmmm |
| 10:09:16 | LinusN | have you changed any of the code? |
| 10:10:00 | ReKleSS | no, fresh cvs checkout |
| 10:10:14 | ReKleSS | and gdb won't tell me anything... |
| 10:10:48 | LinusN | cygwin? |
| 10:11:02 | ReKleSS | gentoo |
| 10:11:36 | LinusN | i seem to recall that this could happen if some code was accidentally placed in the ICODE section |
| 10:12:11 | LinusN | i ranm the sim last night on my debian without problems |
| 10:13:18 | ReKleSS | what version of gcc? |
| 10:14:11 | LinusN | 3.3.6 |
| 10:14:42 | ReKleSS | 3.4.3 here |
| 10:15:27 | ReKleSS | what the heck... a printf added to the first line of main doesn't display |
| 10:16:20 | ReKleSS | is there anything I can do about this ICODE thing? |
| 10:18:44 | LinusN | check the map file, apps/rockbox.map |
| 10:21:18 | ReKleSS | strlen and memcpy are in there |
| 10:22:18 | | Join webguest20 [0] (n=c31ce021@labb.contactor.se) |
| 10:22:46 | ReKleSS | that's a bad thing, right? |
| 10:23:31 | LinusN | hehe |
| 10:24:35 | LinusN | yes it is |
| 10:26:13 | LinusN | ReKleSS: wanna try a fix? |
| 10:30:14 | LinusN | http://linus.haxx.se/simpatch.diff |
| 10:45:45 | Coldtoast | hey |
| 10:45:49 | Coldtoast | the volume bug is fixed? |
| 10:46:17 | Coldtoast | I just updated to the latest bleeding edge and it doesn't seem to be doing it |
| 10:47:15 | pike | quick Q guys, I wanna try rockbox on my h120 now, is there more than one method ? (I read how to do it on misticriver) is this method reversable if shit would hit the fan ? |
| 10:49:38 | LinusN | Coldtoast: no it isn't fixed |
| 10:49:48 | LinusN | pike: huh? |
| 10:49:58 | Coldtoast | ok. so it'd just beign random on me then |
| 10:50:07 | Coldtoast | whereas 100% of the time before I'd get it |
| 10:50:14 | pike | to put it bluntly: could I make a brick of my iriver using rockbox ? |
| 10:50:42 | *** | Saving seen data "./dancer.seen" |
| 10:51:08 | LinusN | nobody has done it yet |
| 10:51:15 | Coldtoast | you can UN-brick your player with Rockbox tho :) |
| 10:51:29 | Coldtoast | f you ever get the "Read file system" hang |
| 10:51:44 | LinusN | yes, the rockbox boot loader is in fact safer than the original |
| 10:52:06 | pike | ok, then Im gonna try this method http://www.misticriver.net/boards/showpost.php?p=283091&postcount=24 |
| 10:52:11 | pike | unless you have a better way |
| 10:52:20 | Coldtoast | so even if you never install Rockbox, it's a good idea to use the bootloader |
| 10:52:29 | LinusN | pike: that's the way |
| 10:52:39 | pike | oki then :) |
| 10:52:43 | pike | thx |
| 10:54:04 | LinusN | Coldtoast: i managed to get an i2c trace of the volume bug last night |
| 10:54:32 | LinusN | it turns out that rockbox writes to an undefined address in the uda1380 |
| 10:54:42 | LinusN | and the uda hangs |
| 10:56:09 | CoCoLUS | and why does it do that? :) |
| 10:57:44 | LinusN | if i only knew |
| 11:00 |
| 11:01:37 | pike | curious, how come your mpc codec is almost 10times as large as ours |
| 11:01:41 | pike | (XBMC) |
| 11:01:53 | pike | I know ours is from foobar |
| 11:06:33 | LinusN | x86, right? |
| 11:06:59 | ReKleSS | LinusN: sorry, had to go eat.... the ptach didn't work |
| 11:07:05 | ReKleSS | no effect |
| 11:07:12 | LinusN | really? |
| 11:07:25 | LinusN | did you do "make clean"? |
| 11:07:33 | ReKleSS | yes |
| 11:07:56 | ReKleSS | strlen and memcpy moved out of icode |
| 11:08:00 | ReKleSS | but I still get FPE |
| 11:08:27 | LinusN | can i see the map file somehow? |
| 11:08:34 | ReKleSS | sure, just a moment |
| 11:08:47 | ReKleSS | gr.... my ftp servers still don't work... |
| 11:11:20 | ReKleSS | LinusN: http://s20.yousendit.com/d.aspx?id=02VGAGGCLEP831LALAAUKQFZD3 |
| 11:18:24 | LinusN | i don't see anything obvious |
| 11:19:36 | CoCoLUS | <fn~LinusN> x86, right? |
| 11:19:39 | CoCoLUS | yeah |
| 11:20:13 | LinusN | afaik, mpc has tons of assembler optimizations for x86 |
| 11:21:39 | | Join mrelwood [0] (n=54e68ce1@labb.contactor.se) |
| 11:22:14 | mrelwood | I find the iRiver on the daily builds. does it mean it can serve use for a ordinary user? |
| 11:22:29 | CoCoLUS | depends on what you define as ordinary |
| 11:23:31 | crwl | if ordinary user doesn't need radio or recording, rockbox does everything better than the original fimrware, i'd say |
| 11:23:38 | pike | sorry yes, xbmc is also x86 |
| 11:23:41 | ReKleSS | or remote |
| 11:23:46 | crwl | hum, except maybe those SRS effects and.. remote :) |
| 11:23:54 | CoCoLUS | and... volume changing :P |
| 11:24:00 | LinusN | :-P |
| 11:24:09 | crwl | is there something wrong with it? |
| 11:24:22 | ReKleSS | I'll be getting onto the remote as soon as I have a working simulator or toolchain |
| 11:24:52 | CoCoLUS | crwl, volume changing currently hangs your player (sometimes, i think) |
| 11:24:56 | mrelwood | ohkay. i WOULD like to change the volume though... ;) |
| 11:25:14 | ReKleSS | what's wrong with the volume? |
| 11:25:30 | CoCoLUS | <fn~LinusN> it turns out that rockbox writes to an undefined address in the uda1380 |
| 11:25:31 | CoCoLUS | <fn~LinusN> and the uda hangs |
| 11:26:21 | crwl | hm, i haven't seen that, it has become terribly slow though, if i've changed the volume much and quickly |
| 11:26:53 | ashridah | crwl: you have seen it if volume slows down. the entire player doesn't hang |
| 11:27:01 | crwl | ashridah, ah, ok |
| 11:27:17 | crwl | i've never really run to it in daily use... |
| 11:27:31 | crwl | but maybe that's because of replaygain support :) |
| 11:27:36 | ashridah | just the volume changes don't end up having an affect |
| 11:27:39 | ashridah | effect even |
| 11:29:06 | LinusN | do any of you experience the volume bug today? |
| 11:30:09 | LinusN | i think i have an idea what it could be |
| 11:30:22 | CoCoLUS | you said it wasn't fixed, didn't you? |
| 11:30:41 | LinusN | i mean i want one of you guys to do a test |
| 11:33:30 | CoCoLUS | i'm sorry, don't have my iriver with me here at work... |
| 11:37:47 | Febs | I can test it. Which build should I use? |
| 11:38:07 | ReKleSS | LinusN: just talked to ninj4 (the guy with the drowned iriver), he's not getting the volume bug |
| 11:38:25 | ReKleSS | err |
| 11:38:28 | ReKleSS | <NINJ4> volume control died |
| 11:38:40 | CoCoLUS | how does one drown his iriver? |
| 11:38:58 | Febs | CoCoLUS, you'd be surprised at how many people drop them in toilets. |
| 11:38:59 | ReKleSS | CoCoLUS: accident with a raincoat pouch |
| 11:39:25 | ReKleSS | it runs... mostly... but rockbox doesn't run reliably on it |
| 11:40:52 | LinusN | is ninj4 the same guy as "tandoc" in the forums? |
| 11:40:54 | ReKleSS | yeah |
| 11:41:12 | LinusN | "works like a charm." he said |
| 11:41:23 | ReKleSS | now it does... |
| 11:43:12 | | Join tandoc [0] (n=harbl@c210-49-191-25.eburwd8.vic.optusnet.com.au) |
| 11:43:22 | LinusN | hi tandoc |
| 11:43:26 | tandoc | allo allo |
| 11:43:39 | CoCoLUS | aloha |
| 11:43:41 | LinusN | rainman himself |
| 11:43:44 | LinusN | :-) |
| 11:44:33 | tandoc | i'm assuming you gave me the latest daily build of rockbox |
| 11:44:44 | CoCoLUS | what a felony... making his iriver wet... :) |
| 11:44:47 | tandoc | since my friend and i get the same volume bug |
| 11:44:49 | tandoc | shhh |
| 11:44:54 | tandoc | it's the damn jacket's fault |
| 11:44:56 | tandoc | >.> |
| 11:45:09 | tandoc | 'waterproof' |
| 11:45:11 | ReKleSS | I never said I get the volume bug |
| 11:45:23 | ReKleSS | although I probably do |
| 11:45:31 | tandoc | oh wait |
| 11:45:43 | tandoc | you didn't upgrade to the latest daily build did you? |
| 11:45:51 | ReKleSS | not yet |
| 11:46:01 | tandoc | well you told me about it, so i assumed you had it too |
| 11:46:23 | LinusN | if my theory is correct, the bug is easier to reproduce if you play a high bitrate file |
| 11:46:30 | tandoc | yup |
| 11:46:46 | LinusN | i get it with the latest build, btw |
| 11:46:58 | CoCoLUS | we need that guy who had his whole collection @ 320 kbps :) |
| 11:47:09 | LinusN | holy moses |
| 11:47:16 | tandoc | half of mine is D: |
| 11:47:23 | ReKleSS | I think I've still got a few 500kbit vorbis files |
| 11:47:34 | Febs | 320kbps ... waste of space. |
| 11:47:39 | CoCoLUS | kind of... how to put it... unnecessary |
| 11:47:57 | tandoc | it's what the files came at, i don't feel like reencoding them... |
| 11:48:14 | CoCoLUS | but that discussion has had it's place here... |
| 11:48:14 | tandoc | not that.. i.. download music.. illegally =/ |
| 11:48:23 | tandoc | i'm sure it has |
| 11:48:40 | CoCoLUS | too often, if you ask me :) |
| 11:48:45 | tandoc | lol |
| 11:49:23 | tandoc | would you consider it blasphemy to cover your ihp with black electrical tape? |
| 11:49:28 | LinusN | ok, i *seem* to have found the bug |
| 11:49:46 | CoCoLUS | i would consider it blasphemy if'd paint it white and scribble IPOD on it |
| 11:49:53 | ReKleSS | lol cocolus |
| 11:50:11 | tandoc | oh good |
| 11:50:12 | CoCoLUS | black is ok... as long as you don't write U2 on it... :) |
| 11:50:18 | tandoc | mine's covered in electrical tape |
| 11:50:21 | LinusN | it's not an easy one to fix though |
| 11:50:23 | tandoc | because i scratched it.. |
| 11:50:51 | CoCoLUS | tandoc, just admit it, it's a diy rain-shield :) |
| 11:50:59 | tandoc | damn straight. |
| 11:52:26 | CoCoLUS | <fn~LinusN> ok, i *seem* to have found the bug |
| 11:52:27 | CoCoLUS | where? |
| 11:52:57 | LinusN | the i2c controller doesn't like changing the bit rate prescaler on the fly |
| 11:53:36 | LinusN | so if rockbox boosts/unboosts the cpu during an i2c transfer, the i2c controller screws up |
| 11:54:11 | Coldtoast | tandoc |
| 11:54:16 | Coldtoast | don't cover it in electrical tape |
| 11:54:17 | tandoc | ? |
| 11:54:22 | CoCoLUS | hmm... that wasn't changed with the suspected timer change from amiconn, was it? |
| 11:54:22 | Coldtoast | do the brushed metal mod :) |
| 11:54:29 | tandoc | its not completely covered.. |
| 11:54:34 | tandoc | just the scratches... |
| 11:54:40 | tandoc | really, really big scratches... |
| 11:54:50 | tandoc | brushed metal mod? |
| 11:54:52 | LinusN | CoCoLUS: no, but the backlight uses the timer, and also boosts the cpu |
| 11:55:12 | LinusN | so the timing might have changed, exposing the bug |
| 11:56:00 | CoCoLUS | ic... how much work would it be to stop changing the cpu speed while a i2c transfer is in progress? |
| 11:56:35 | LinusN | unfortunately not that easy, but i'll work on it |
| 11:57:07 | DBUG | Enqueued KICK tandoc |
| 11:57:07 | tandoc | ( LinusN ): so what did you change in rockbox to disable the hdd check, or whatever it happens to be? |
| 11:57:29 | LinusN | i removed the call to check_registers() in ata.c |
| 11:57:57 | tandoc | ah, so that'd involve compiling myself to rollback to an older rockbox =____= |
| 11:58:39 | Coldtoast | tandoc: http://www.misticriver.net/boards/showthread.php?t=24795&highlight=brushed |
| 11:59:11 | LinusN | tandoc: i'll see if we can do something about it permanently |
| 11:59:25 | LinusN | i seem to recall that someone else had the same -32 error as you |
| 11:59:30 | tandoc | hmm, the problem is only on highbit rate files... |
| 11:59:53 | LinusN | tandoc: can you reproduce it? |
| 11:59:59 | tandoc | yeah |
| 12:00 |
| 12:00:28 | tandoc | 192kbit is perfectly fine |
| 12:01:22 | tandoc | hey sexy, i might do that mod... |
| 12:02:33 | Coldtoast | yeah. be sure to clearcoat it tho :) |
| 12:02:59 | tandoc | something i probably couldn't do if my life, or mp3 player, depended on it |
| 12:03:10 | Coldtoast | hehe |
| 12:04:10 | tandoc | but i'd probably fail at getting a brushed finish |
| 12:04:10 | | Quit Coldtoast (Read error: 104 (Connection reset by peer)) |
| 12:04:29 | tandoc | buh bye |
| 12:05:45 | LinusN | ouch! the backlight handler calls cpu_boost() from an interrupt! |
| 12:06:16 | LinusN | bad bad bad |
| 12:15:32 | ashridah | wow. that does look nice. |
| 12:15:49 | ashridah | pity i suck with handy work. i'd probably flubb the varnish job |
| 12:17:30 | tandoc | i'm happy with my electrical tape :D |
| 12:19:44 | ashridah | interestingly, none of the paint has scratched off on mine |
| 12:19:54 | ashridah | and i've had it over a year and a half now |
| 12:20:15 | tandoc | had mine the same amount of time |
| 12:20:20 | tandoc | lots of scratches :P |
| 12:20:32 | ashridah | the screen has some marks |
| 12:20:35 | ReKleSS | mine doesn't have a metal case... no paint to scratch :p |
| 12:20:38 | ashridah | but the paint is fine |
| 12:30:41 | LinusN | the backlight dimmer code is really nasty |
| 12:30:57 | LinusN | it boosts and unboosts like crazy |
| 12:31:18 | ReKleSS | ...just for a little fade effect??? |
| 12:32:43 | LinusN | it needs to boost during the fade |
| 12:32:46 | ashridah | ReKleSS: yeah, it does pulse width modulation |
| 12:33:03 | LinusN | but a design flaw makes it boost and unboost for every key event |
| 12:33:27 | LinusN | and it unboosts from an interrupt, a totally forbidden thing |
| 12:33:36 | ashridah | that tends to be fairly heavy for the granularity of fade. |
| 12:34:03 | ReKleSS | it seems ridiculous, just for eye candy |
| 12:34:17 | LinusN | it's not really necessary to boost for performance reasons |
| 12:36:02 | LinusN | but the timing changes if the cpu frequency is changed during the fade, causing it to flicker |
| 12:41:24 | | Join Moos [0] (i=DrMoos@m29.net81-66-158.noos.fr) |
| 12:41:39 | Moos | Good Day all |
| 12:42:28 | Moos | hey Linus puzzled with the bug volume |
| 12:50:46 | *** | Saving seen data "./dancer.seen" |
| 12:51:12 | | Join thomjoha [0] (n=thomjoha@hekta.edt.aft.hist.no) |
| 12:51:14 | thomjoha | hi |
| 12:51:17 | | Nick thomjoha is now known as preglow (n=thomjoha@hekta.edt.aft.hist.no) |
| 12:51:48 | Moos | Hello |
| 12:54:03 | pike | is rockbox planning to add audible ff/rw ? |
| 12:54:10 | | Quit lostlogic (Read error: 110 (Connection timed out)) |
| 12:54:17 | pike | testing rockbox on iriver now |
| 12:56:44 | LinusN | pike: no plans, but anyone is free to implement it |
| 12:56:47 | preglow | hmm, no |
| 12:57:00 | preglow | i asked the other people, and most of the devs dont want audible seeking |
| 12:57:06 | preglow | although id like it myself |
| 12:57:13 | pike | or beef up remote so you can see position ? |
| 12:57:28 | pike | maybe thats just skin related, I used rockbox for a full 10 minutes |
| 12:58:04 | LinusN | preglow: if you manage to implement audible seeking, i won't stop you |
| 12:58:16 | LinusN | provided there is an option |
| 12:59:08 | preglow | LinusN: its not that important to me, and indeed, itll be hard to adapt each codec to support it |
| 12:59:21 | LinusN | oh yes |
| 12:59:53 | preglow | mp3 will be easy, vorbis too, but i dont know about the other ones |
| 13:00 |
| 13:00:39 | | Join lostlogic [0] (n=lostlogi@node-4024215a.mdw.onnet.us.uu.net) |
| 13:00:56 | pike | but regarding remote, I just see the logo, and it's sure a nice logo ;) but maybe remote could be used for some info ? |
| 13:01:12 | preglow | well have remote wps some happy dau |
| 13:01:13 | preglow | day |
| 13:01:16 | preglow | please work on it |
| 13:01:16 | preglow | heh |
| 13:02:05 | Febs | preglow, I saw on yesterday's IRC log that you were asking about suggestions for EQs. |
| 13:02:17 | preglow | correct |
| 13:03:04 | Febs | I think that a simple 5 band EQ would probably do 90% of what most people need. |
| 13:03:08 | Moos | preglow is back? :) |
| 13:03:20 | preglow | sort of, give me another week and well see |
| 13:03:39 | pike | what speed (X) does it seek with when I FF using remote |
| 13:03:55 | pike | same as main unit I suppose, but I dont know what that uses either |
| 13:04:06 | Febs | I'd like to see parametric EQ where one could set Q and frequency in addition to gain ... |
| 13:04:21 | Febs | ...but I'm not sure whether that would be too confusing for most users. |
| 13:04:46 | preglow | we could hide the center freq/q options somehow |
| 13:05:04 | Febs | That was my thought too. |
| 13:05:45 | Febs | And of couse, people seem to love "presets" like "rock," "jazz" etc. ... though I think that those names are meaningless. |
| 13:06:10 | tandoc | people use those?! |
| 13:06:10 | preglow | pretty much |
| 13:06:23 | pike | "eq" in org fw was pretty bad |
| 13:06:34 | pike | it can only get better :) |
| 13:06:34 | Febs | tandoc, yeah, you would be suprised by how many people think that if they are listening to rock, they need the "rock" eq. |
| 13:06:36 | preglow | well, yes, it isnt a proper eq |
| 13:06:49 | tandoc | i like my battery life... |
| 13:07:21 | Febs | I actually use EQ very little, but in certain situations would like the flexibility of a parametric EQ. |
| 13:08:15 | Febs | Also, and this probably goes without saying, but I think that any EQ implementation should allow the user to cut frequencies as well as boost them. |
| 13:08:34 | preglow | of course |
| 13:09:34 | pike | a good eq design would be if you can never clip the signal |
| 13:10:01 | pike | so instead of raising something , you would lower the rest |
| 13:10:12 | preglow | well, that involves decreasing the volume |
| 13:10:27 | preglow | yes |
| 13:10:50 | preglow | it will work like the current bass/treble controls work |
| 13:11:05 | Febs | In terms of pre-scaling the volume, you mean? |
| 13:11:08 | preglow | if youre at 100 volume, everything but the band in question will get lower |
| 13:13:42 | preglow | theres no way around that |
| 13:16:35 | Febs | Understood. Though I've seen people argue that they should be allowed to push the EQ into clipping if they want so that they can get more volume. LOL. |
| 13:16:54 | preglow | well, i can always add an option... |
| 13:17:01 | ReKleSS | "idiot mode" |
| 13:17:22 | ReKleSS | just provide a complex looking interface that does nothing |
| 13:17:47 | Febs | Ha ha. Make it one of the presets: rock, classical, jazz, and ultrabass placebo. |
| 13:18:30 | ReKleSS | I just want an eq setting that reduces the bass a bit... |
| 13:18:44 | preglow | ahahah |
| 13:18:46 | LinusN | well, it still makes sense if the audio has a low level to start with |
| 13:18:52 | preglow | sure |
| 13:19:02 | pike | and thats what en EQ is for, to compensate for speakers |
| 13:19:08 | preglow | i actually want a flag to make the rockbox volume go above 100 |
| 13:19:44 | preglow | tons of old records are recorded at a pretty low volume |
| 13:19:51 | LinusN | afaik, the uda can't boost the volume |
| 13:20:00 | LinusN | 0db is max |
| 13:20:01 | preglow | i know, software will take care of the boosting |
| 13:20:12 | preglow | its a simple multiply |
| 13:20:44 | LinusN | i have been looking into missing fundamental bass boosting |
| 13:20:51 | Febs | On the fly peak normalization might be cool. Is such a thing possible? |
| 13:21:07 | Febs | LinusN, like the SRS "Trubass"? |
| 13:21:08 | preglow | Febs: of course |
| 13:21:14 | LinusN | Febs: yes |
| 13:21:18 | pike | really ? |
| 13:21:28 | Febs | preglow, I think that would be a feature that would be very popular. |
| 13:21:46 | pike | it would have to correct realtime, and if song has a silent part, it would boost like he** |
| 13:21:53 | preglow | missing fundamental boosting could be done by lowpass filering the signal, distorting it in some way, then adding that to the original signal |
| 13:22:51 | LinusN | the algorithms i have studied involve removing the fundamental in the source before adding the harnmonics |
| 13:23:12 | preglow | i didnt think the fundamental was audible anyway |
| 13:23:18 | preglow | of course, it will eat headroom |
| 13:23:23 | preglow | and might cause clipping |
| 13:23:46 | LinusN | basically a lowpass filter to find the fundamental, create the harmonics and att them to the signal with the fundamental removed |
| 13:24:00 | LinusN | s/att/add/ |
| 13:24:43 | Febs | I think that the point of providing the harmonics is to compensate for speakers, headphones, etc. that can't reproduce the lower frequencies. If the fundamental is inaudible anyway, than removing them makes sense. |
| 13:24:49 | preglow | well, removing the fundamental is just highpass filtering |
| 13:24:53 | LinusN | yes |
| 13:25:04 | preglow | but does the algo also involve finding the exact frequency of the fundamental? |
| 13:25:15 | LinusN | not necessarily |
| 13:26:35 | preglow | good |
| 13:26:38 | preglow | that hairier |
| 13:26:39 | LinusN | there are algos that try to synthesize the harmonics by analysing the frequencies of the source |
| 13:27:00 | LinusN | but they are complicated, power hungry, and not necessarily better sounding |
| 13:27:31 | | Join Sucka [0] (n=NNSCRIPT@host81-156-208-120.range81-156.btcentralplus.com) |
| 13:29:27 | Febs | pike, going back to your point about boosting silent parts, I am not talking about dynamic range compression. I am talking about finding the peak, and then scaling the gain of the entire song so that the peak is at 0dB. |
| 13:29:59 | preglow | well, youre more or less asking for a replaygain scanner |
| 13:30:00 | Febs | That would boost silent parts and possible expose some noise, but no more so than turning up the volume or using replaygain. |
| 13:30:27 | preglow | so youd like the peak to be found prior the actually playing the track? |
| 13:30:42 | preglow | i need to find out how to make an apostrophe on this bloody keyboard |
| 13:30:51 | Febs | Yeah, that would be the concept. |
| 13:31:06 | preglow | well, might as well add a full blown replaygain scanner, then |
| 13:31:39 | pike | Febs: isnt that called um ReplayGain ? |
| 13:32:02 | pike | or you would have the player do the scanning ? (slooow) and you can only find the peak by scanning the whole song |
| 13:32:08 | Febs | preglow: suppose you could. I thought that peak normalization, while a little cruder, would be easier. |
| 13:32:46 | Febs | pike, as I understand replaygain and mp3gain, they use some sort of process to calculate the apparent volume and compensate for that. They're doing something a little more complex than simply setting all files so that they peak at the same point. |
| 13:33:18 | pike | they both fins the peak (afaik) and use that as reference point |
| 13:33:24 | pike | you must have a reference point |
| 13:34:36 | Febs | Right, but with simple peak normalization, a modern recording with really squashed dynamic range is still going to sound a lot louder than an older tune that has some high peaks but is at a lower average gain. |
| 13:35:01 | Febs | Replaygain−−as I understand it, which admittedly could be wrong−−compensates for those differences. |
| 13:35:37 | pike | not sure what you mean, but how will you eliminate the scanning process ? |
| 13:35:43 | LinusN | preglow: http://www.esat.kuleuven.ac.be/~spch/mpca/papers/aarts:mpca02.pdf |
| 13:36:03 | Febs | *I* wouldn't. Preglow would! |
| 13:36:50 | Febs | Seriously, though, I know how it works in theory, but I don't know the mechanics for implementing it on a DAP. |
| 13:37:05 | pike | how does it work in theory ? |
| 13:37:11 | pike | I never heard of anything similar |
| 13:37:44 | pike | think I would have it if was practical or possible |
| 13:38:05 | pike | if it* |
| 13:38:16 | Febs | I should rephrase: I understand the concept, rather than the mechanics. I shouldn't suggest that I understand the math behind it. |
| 13:39:05 | Febs | Peak normalization: scan the song, find the peak, calculate the multiplier needed to bring the peak to x (usually 0dB), and multiply the whole song by that constant. |
| 13:39:31 | pike | yes, thats straightforward |
| 13:40:27 | Febs | Replaygain: Replaygain: scan the song, calculate the apparent volume, calculate the multiplier needed to adjust from that apparent volume to a certain fixed standard. Usually NOT 0dB or quieter songs would need to be clipped to bring them to the same level as louder songs. |
| 13:41:06 | preglow | replaygain finds both the peak and the a-weighted average volume |
| 13:41:41 | Febs | Ah, that makes sense. |
| 13:42:35 | preglow | peak volume is a nice measure to have around anyway, especially since it tends to be higher than 1 for codecs with filter banks |
| 13:42:45 | Febs | Well, gotta go to work. Sadly, that will undoubtedly be far less interesting than this discussion. |
| 13:42:52 | preglow | everything is, heh |
| 13:43:10 | | Quit Febs (" HydraIRC -> http://www.hydrairc.com <- Leading Edge IRC") |
| 13:43:20 | preglow | anywho, is there some way to make rockbox go to the next folder when its done with the current one? |
| 13:43:28 | preglow | like, without my intervention |
| 13:43:35 | ashridah | didn't someone add an option for that? |
| 13:44:04 | preglow | yes, but you need to skip the track by hand |
| 13:44:22 | preglow | it doesnt go the next folder if the last track finishes by itself |
| 13:44:26 | preglow | perhaps thats a bug? |
| 13:45:36 | preglow | ghmm |
| 13:45:37 | preglow | im wrong |
| 13:45:39 | preglow | it works now |
| 13:51:24 | preglow | LinusN: well, yes, that describes more or less what i imagined |
| 13:51:48 | preglow | shouldnt be impossible, we can implement filters very efficiently |
| 13:55:03 | | Join Rockdude05 [0] (n=chatzill@exhax16-b021.dialup.optusnet.com.au) |
| 13:56:27 | Rockdude05 | hey, does anyone here use te solitaire plugin? |
| 13:57:08 | Rockdude05 | its the only stable game whilst playing music, so would adding grey and fixing a few bugs be a big pain in the bu,? |
| 13:57:11 | Rockdude05 | *bum |
| 13:59:13 | preglow | probably not, you just need someone to do it |
| 13:59:30 | preglow | i for one isnt even slightly interested in hacking on games |
| 13:59:52 | preglow | someone teach me proper english grammar before i make a larger fool of myself |
| 14:00 |
| 14:00:17 | LinusN | i think you've already reached the limit |
| 14:00:29 | Rockdude05 | wel it's not quite hacking, just fixing silly things like not being able to select cards, or distinguishing between black+red cards, nothing important :) |
| 14:00:50 | preglow | good, then i dont have to worry about it |
| 14:01:01 | LinusN | Rockdude05: the most unsexy kind of programming |
| 14:01:40 | CoCoLUS | anyone who's using sexy and programming in the same sentence is kinda suspect to me... |
| 14:02:30 | Moos | :-) |
| 14:02:34 | Rockdude05 | urm wel i dont get you there but im sure its meaningful ;) well in that case i must do my homework and learn all this.... i used to program loads so yeah... time to go make a large black paperweight |
| 14:05:15 | Rockdude05 | oh ahem whilst im here also, is there a low battery sequence or not? i seem to recall some sort of change log about it a while ago but my player still goes off its nut on 0% |
| 14:06:01 | LinusN | there is no low battery handling |
| 14:06:09 | Rockdude05 | cheers :) |
| 14:06:15 | LinusN | the only thing is that the boot loader warns if the battery is low |
| 14:07:03 | Rockdude05 | i see |
| 14:09:40 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 14:09:40 | * | preglow is finally coding rockbox again |
| 14:11:54 | preglow | how is iram usage currently? 32kb core, 32 plugin and 32 codec? |
| 14:12:27 | Rockdude05 | question time again ;) how much of the iriver resources are available after decoding audio? on average after mp3/ogg/wav for example. is there enough for, as mentioned, stereo width processing etc? or do they all still need optimizing? |
| 14:12:40 | preglow | more optimising coming up |
| 14:12:52 | preglow | some of them are pretty fast |
| 14:12:58 | preglow | mp3 is pretty fast, wavpack is very fast |
| 14:13:03 | preglow | vorbis is also getting there |
| 14:13:17 | preglow | more than enough for stereo width processing |
| 14:14:23 | Rockdude05 | yeah i saw some 10% speedup things a while back, which is nice :P also, with crossfade, can someone just quikcly exlain how that works.for example, do both songs have to be decoded at once, or is it buffered? |
| 14:15:09 | Rockdude05 | yes because i noticed stereo width is already in the menu but not functional, so i assume thats in archos (although isnt the archos effects/decoding hardware orientated?) |
| 14:15:42 | LinusN | yes, all signal processing is in "hardware" |
| 14:15:44 | preglow | buffered |
| 14:15:45 | LinusN | in the archos |
| 14:16:38 | LinusN | the archos decoder hardware has a pretty sophisticated mixer that allows us to tweak the stereo width |
| 14:16:58 | Rockdude05 | thanks, sorry for the questions youve probably answered 1000 times already, but im sure theyre better than some ;) |
| 14:17:08 | Rockdude05 | ok i see |
| 14:17:49 | LinusN | we could add a similar mixer to the iriver |
| 14:17:56 | preglow | LinusN: but yeah, you got any idea about my iram question? |
| 14:18:58 | preglow | codecs should have more than 32kb iram :/ |
| 14:19:01 | | Join oxygen77 [0] (i=nobody@yossman.net) |
| 14:19:23 | preglow | perhaps it would be a good idea to split mp3 and mp1/mp2 into different codecs |
| 14:19:39 | preglow | they share some code, but not all |
| 14:19:47 | Rockdude05 | i must say (no i wont go into this dribble about how rubbish srs is) that stereo width can be especially useful when using vorbis through line out, and more specifically through an amp or speakers, as the vorbis width always seems very small and i'm sure i read somewhere that it's a known issue with ogg (stereo image is quite, wel, joint still). |
| 14:20:06 | preglow | stereo is always joint in vorbis, i believe |
| 14:20:18 | preglow | but yeah, stereo with should be a quickie to add |
| 14:20:45 | preglow | width, even |
| 14:21:42 | LinusN | hmmm, it looks like the codecs share the iram with plugins (!) |
| 14:21:49 | preglow | ! |
| 14:22:10 | preglow | ahh, yes, that is true |
| 14:22:28 | LinusN | so if a plugin uses iram the codec will crash |
| 14:22:28 | preglow | and i believe thats quite ok, plugins requiring iram will probably be too intensive to run when audio is playing anyway |
| 14:22:34 | Rockdude05 | yes, until a point, but the image can be narrow if i'm understood, so sounds bad on good speakers. on the subject, do you know what percentage or settngs are line out on rockbox or iriver, and also if it in fact matters if i use the headphone jack or line out jack. also (phew) will (i've been doing this) sticking 2 headphones in each jack (line out+headphone) kill the player? (bass etc still... |
| 14:22:35 | Rockdude05 | ...works with line out) |
| 14:23:03 | preglow | Rockdude05: it matters if youre using headphones, line out doesnt have an amp |
| 14:23:14 | preglow | Rockdude05: but if youre connecting to an amp, it shouldnt matter |
| 14:23:40 | Rockdude05 | so technically my headphones shouldnt be working from line out? |
| 14:23:56 | preglow | Rockdude05: they do, but theyll distort a lot, since the line out cant drive them properly |
| 14:24:04 | preglow | Rockdude05: at least my headphones distort like mad from line out |
| 14:24:30 | ze | they distort? hows that? |
| 14:25:10 | Rockdude05 | someone's going to flinch at this, but i sometimes run 6 headphones from my iriver, with about 70% vol on each and low bass to reduce distortion, so my friends can hear in school etc. although this is pretty insane, will this damage my layer? |
| 14:25:12 | ze | just curious, i've never heard of headphones distorting from too weak of a signal |
| 14:25:13 | Rockdude05 | *player |
| 14:25:37 | preglow | Rockdude05: no |
| 14:26:07 | Rockdude05 | just reduce battery life? |
| 14:26:19 | preglow | not by much, i believe |
| 14:26:32 | Rockdude05 | well how efficient ;) |
| 14:26:35 | preglow | the headphone amp can only give so much current |
| 14:27:03 | Rockdude05 | i know... i dont know myself how i get it all going |
| 14:27:15 | Rockdude05 | i get a few strange looks |
| 14:27:15 | preglow | ze: the headphones themselves arent distorting, its the line out driver circuitry thats distorting, it isnt designed to be connected to a low-impedance load |
| 14:27:26 | ze | preglow: ah |
| 14:27:59 | Rockdude05 | ah, therefore high impedence into low impedence = screwy sound |
| 14:28:53 | preglow | a headphone is around 16 ohms, or something, whereas a proper amp input should be several hundred kiloohms |
| 14:29:34 | ze | my headphones are 64, and i've seen several in the hundreds, maybe even thousands... never in the hundred thousands though hehe |
| 14:29:39 | preglow | LinusN: but where does the remaining 64k go? the core cant possibly need that much |
| 14:30:05 | preglow | high impedance headphones do exist, they used them in the olden days of amateur radio |
| 14:30:21 | preglow | they could drive headphones from the power of radio waves alone |
| 14:30:23 | preglow | which is insane |
| 14:30:28 | ze | hehe |
| 14:30:33 | LinusN | preglow: the main stack eats most of it, iirc |
| 14:30:34 | ze | its not that insane... |
| 14:31:05 | preglow | LinusN: ahh, yes, but is that needed currently? the codecs are the most sensitive stack users, and theyve got their own stack currently |
| 14:31:15 | ze | in fact transistor radios + peizo earpieces did it all the time, didn't they? heh |
| 14:31:24 | LinusN | i think we can reduce the main stack |
| 14:31:33 | preglow | transistor radios were powered, crystal radios werent |
| 14:31:34 | tandoc | before i sleep, i just want to thank you again linus for making rockbox work on my zombie of an mp3 player :D |
| 14:31:43 | LinusN | tandoc: you're welcome |
| 14:31:47 | ze | er oh crystal radios, sorry, you know what i meant |
| 14:31:52 | preglow | sure, hehe |
| 14:32:03 | LinusN | tandoc: make sure you report if anything else breaks |
| 14:32:42 | tandoc | roger that |
| 14:32:52 | ze | and ya know tesla did all sorts of powering things with radio waves :p |
| 14:32:54 | preglow | the codec stack needs to be pretty big, libmad for one requires at least 20k |
| 14:33:37 | Rockdude05 | does anyone agree with me on this... with all the pop-up messages on r.b, should the background be a lighter grey? i simply cant read it sometimes |
| 14:34:00 | preglow | dont think ive ever had any problems with that |
| 14:35:23 | Rockdude05 | well no but its a small thing that could help, especially when you use stupidly small fonts like me |
| 14:36:47 | preglow | but i dont think we have a lighter shade of grey anyway |
| 14:37:30 | Rockdude05 | *thinks*.... theres four. black, white, light grey and dark grey? |
| 14:37:35 | LinusN | no, we would have to adjust the palette |
| 14:38:33 | Rockdude05 | so its not as simple as changing a couple of characters :P |
| 14:38:35 | Rockdude05 | sorry |
| 14:39:21 | Rockdude05 | bloody windows users and their GUI's like me eh? ;) |
| 14:41:14 | preglow | oh well |
| 14:41:17 | preglow | i need to go |
| 14:41:18 | preglow | later |
| 14:41:24 | | Quit preglow ("ex") |
| 14:43:45 | Rockdude05 | yeah im off too, getting late here in aussieland |
| 14:43:50 | | Quit Rockdude05 ("Chatzilla 0.9.68.5 [Firefox 1.0.4/20050511]") |
| 14:50:49 | *** | Saving seen data "./dancer.seen" |
| 14:52:09 | oxygen77 | hello, any news on wav playback ? |
| 15:00 |
| 15:03:52 | | Quit webguest20 ("CGI:IRC") |
| 15:06:05 | LinusN | wav playback for archos? |
| 15:06:12 | oxygen77 | yup |
| 15:06:18 | LinusN | not that i know of |
| 15:06:46 | oxygen77 | k, I've succesfully run archos wav codec on AV's MAS |
| 15:24:34 | | Quit mrelwood ("CGI:IRC") |
| 15:29:11 | | Join ep0ch_ [0] (n=ep0ch@84.12.175.21) |
| 15:29:23 | | Nick ep0ch_ is now known as ep0ch (n=ep0ch@84.12.175.21) |
| 15:30:02 | ep0ch | please can someone had the peak meter range values as tags to WPS please :) |
| 15:30:10 | ep0ch | had = add |
| 15:30:50 | ep0ch | so i can see that the bottom of the peak meter is -55 db and the top is 0 db |
| 15:40:57 | | Part LinusN |
| 15:42:56 | | Part oxygen77 |
| 16:00 |
| 16:10:23 | | Quit ashridah (Read error: 110 (Connection timed out)) |
| 16:50:53 | *** | Saving seen data "./dancer.seen" |
| 16:55:33 | | Join niobos [0] (n=niels@144.19-136-217.adsl.skynet.be) |
| 16:56:27 | niobos | hi all |
| 17:00 |
| 17:04:56 | | Quit einhirn (Read error: 104 (Connection reset by peer)) |
| 17:07:26 | | Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) |
| 17:12:16 | | Join pabs_ [0] (n=pabs@xor.pablotron.org) |
| 17:18:58 | | Join amiconn_ [0] (n=jens@p54BD7F1E.dip.t-dialin.net) |
| 17:22:51 | | Quit pabs (Nick collision from services.) |
| 17:22:56 | | Nick pabs_ is now known as pabs (n=pabs@xor.pablotron.org) |
| 17:24:35 | | Join bagawk [0] (n=lee@unaffiliated/bagawk) |
| 17:29:45 | | Quit amiconn (Nick collision from services.) |
| 17:29:46 | | Nick amiconn_ is now known as amiconn (n=jens@p54BD7F1E.dip.t-dialin.net) |
| 17:36:26 | | Quit niobos ("leaving") |
| 17:54:48 | | Quit ep0ch ("Trillian (http://www.ceruleanstudios.com") |
| 18:00 |
| 18:04:08 | | Join courtc [0] (n=court@adsl-33-131-149.asm.bellsouth.net) |
| 18:05:27 | | Join courtc_ [0] (n=court@adsl-33-131-149.asm.bellsouth.net) |
| 18:05:36 | | Quit courtc_ (Read error: 104 (Connection reset by peer)) |
| 18:07:26 | | Join Lear [0] (n=chatzill@h244n6c1o285.bredband.skanova.com) |
| 18:19:26 | | Join Coldtoast [0] (i=edan@ppp110-114.lns1.hba1.internode.on.net) |
| 18:50:34 | | Join psychocydd [0] (i=psychocy@host217-44-38-58.range217-44.btcentralplus.com) |
| 18:50:44 | | Part psychocydd |
| 18:50:54 | *** | Saving seen data "./dancer.seen" |
| 19:00 |
| 19:01:47 | | Quit bagawk ("Leaving") |
| 19:08:22 | | Join Maxime`Mrn [0] (n=flemmard@cartec.net2.nerim.net) |
| 19:08:23 | | Quit Maxime (Read error: 104 (Connection reset by peer)) |
| 19:25:48 | amiconn | Hmm, no Linus here :/ |
| 19:26:04 | | Join LinusN [0] (N=linus@labb.contactor.se) |
| 19:26:14 | amiconn | hi LinusN |
| 19:26:21 | LinusN | i feel like batman |
| 19:26:25 | amiconn | Did you monitor the log? ;) |
| 19:26:27 | LinusN | coming when you call for me |
| 19:26:29 | Coldtoast | hah |
| 19:26:37 | LinusN | i just sat down to read it |
| 19:26:40 | amiconn | I wanted to talk about the backlight fading |
| 19:26:46 | LinusN | oh yes |
| 19:26:49 | Coldtoast | (>^<) |
| 19:26:59 | LinusN | Coldtoast: :-) |
| 19:27:03 | amiconn | I wonder what leads you to conclude it boost/unboosts frequently, and from the isr? |
| 19:27:16 | amiconn | Did you some do some bdm sessions? |
| 19:27:16 | Coldtoast | hard to do teh batsignal |
| 19:27:20 | LinusN | the unboost is in the isr |
| 19:27:32 | amiconn | Yes, the unboost, once, when the fade is complete |
| 19:27:37 | LinusN | nope |
| 19:27:51 | amiconn | Huh? |
| 19:28:00 | LinusN | the way the code is written, it registers and starts the timer for every keypress |
| 19:28:12 | amiconn | Hmm? |
| 19:28:19 | LinusN | the isr concludes that the light is on and unboosts |
| 19:28:27 | | Quit Coldtoast ("Peace and Protection 4.22") |
| 19:28:40 | LinusN | i logf()ed it |
| 19:28:49 | amiconn | It concludes this *only* if 2 conditions are true |
| 19:29:43 | amiconn | (1) The pwm value reached the target value *and* (2) this target value is either full on or full off |
| 19:30:11 | LinusN | and both are of course true when the backlight is lit |
| 19:30:27 | amiconn | Or do you mean __backlight_on() is called for every keypress? |
| 19:30:49 | amiconn | This would mean there's something wrong with the design of the backlight thread... |
| 19:30:50 | LinusN | __backlight_on() is called, and after that backlight_dim() |
| 19:31:00 | amiconn | Yes of course |
| 19:31:23 | LinusN | the backlight logic wasn't designed for fading |
| 19:31:25 | amiconn | The thing is that this has nothing to do with the dimming code, but is a design flaw in the backlight thread |
| 19:31:48 | | Join merbanan [0] (n=banan@dalink.campus.luth.se) |
| 19:32:08 | amiconn | Still it doesn't make sense to call __backlight_on() over and over if the light is already on |
| 19:32:30 | LinusN | maybe not, but it is simpler than mirroring the state in a variable |
| 19:32:37 | LinusN | kiss, you know |
| 19:32:42 | amiconn | I could add a protection |
| 19:32:49 | | Quit banan__ (Read error: 104 (Connection reset by peer)) |
| 19:32:54 | amiconn | ...in backlight_dim() |
| 19:33:06 | LinusN | sure, plus move the cpu_boost(false) from the isr |
| 19:33:10 | amiconn | Btw, I didn't change this part of the logic with my timer changes |
| 19:33:17 | LinusN | i'm not blaming you |
| 19:33:41 | amiconn | I only changed the way how the dimming logic decides whether it is okay to use the timer |
| 19:33:59 | amiconn | So I wonder why these changes uncovered this problem |
| 19:34:20 | LinusN | beats me |
| 19:35:12 | amiconn | backlight_dim() should only start the dimming process if the new target value is different from the old |
| 19:35:47 | amiconn | However, I have no idea how to move the unboost out of the isr |
| 19:36:03 | amiconn | I also don't understand the problem with it being in the isr |
| 19:36:39 | LinusN | in the old version of the backlight code, backlight_start_timer() returned immediately if bl_timeractive was true |
| 19:36:56 | amiconn | Yes, and it still does that |
| 19:36:57 | LinusN | the boost counter isn't protected |
| 19:37:11 | LinusN | hmmm, yes |
| 19:37:19 | amiconn | I merely incorporated the code from backlight_start_timer() into backlight_dim() |
| 19:37:25 | LinusN | true |
| 19:37:44 | amiconn | Both functions were rather small, and backlight_start_timer() only being used there |
| 19:38:09 | LinusN | let the isr send an event to the backlight thread |
| 19:38:22 | amiconn | Hmm. |
| 19:38:23 | LinusN | then the backlight thread can unboost |
| 19:38:44 | amiconn | This is prone to a race condition... |
| 19:38:54 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 19:38:57 | amiconn | Hmm, perhaps not |
| 19:38:57 | LinusN | perhaps |
| 19:39:18 | amiconn | What if backlight_dim() is called before this event is processed? |
| 19:39:27 | amiconn | *called again |
| 19:39:33 | LinusN | then we have two boosts |
| 19:39:38 | LinusN | and two unboosts |
| 19:39:41 | amiconn | Yes, for a short time. |
| 19:39:46 | amiconn | Should be okay then |
| 19:40:14 | amiconn | However, it makes the dimming a bit more scattered |
| 19:40:21 | LinusN | this is only one of the problems for the i2c, btw |
| 19:41:06 | amiconn | I have an idea what might be another problem |
| 19:41:24 | amiconn | We always set the i2c prescaler last, after switching the cpu frequency |
| 19:41:26 | LinusN | any boost/ubnoost while running i2c is a problem |
| 19:41:46 | amiconn | However, this causes the i2c frequency being way too high for a short time when boosting |
| 19:41:54 | LinusN | true |
| 19:42:11 | amiconn | We need to increase the prescaler before boosting, but decrease after unboosting |
| 19:42:24 | LinusN | i'm not sure that's enough |
| 19:42:36 | LinusN | we don't know how the prescaler works internally |
| 19:42:37 | amiconn | Maybe this problem manifested because of the increased i2c clock |
| 19:42:43 | LinusN | probably |
| 19:42:55 | amiconn | Remember, we accidentally ran it at half the desired frequency |
| 19:43:03 | amiconn | ...that is 50 kHz |
| 19:43:10 | LinusN | ye |
| 19:43:30 | amiconn | Now we run it at the desired 100 kHz |
| 19:43:47 | LinusN | it might be necessary to protect the i2c comm from frequency changes |
| 19:44:13 | LinusN | but your solution might just as well work |
| 19:44:33 | amiconn | I wonder what may cause these i2c problem if not only the clock being out of specs |
| 19:44:42 | LinusN | i wonder if the internal counter is reset when we write the prescaler |
| 19:45:07 | LinusN | i can see from a logic analyser trace that one clock period is insanely short |
| 19:45:23 | amiconn | Afaiu i2c should work even if the frequency changes within the transfer |
| 19:45:32 | LinusN | i2c itself yes |
| 19:45:42 | amiconn | ...as long as it stays within the limit |
| 19:45:47 | LinusN | but we don't know how the controller is implemented |
| 19:46:00 | LinusN | we can guess though |
| 19:46:20 | | Join dpassen1 [0] (n=derek@cpe-24-168-110-99.si.res.rr.com) |
| 19:46:24 | LinusN | and setting the prescaler before and after the change might be the solution |
| 19:46:38 | amiconn | Maybe it's not the frequency change, but the MFDR change while i2c is running |
| 19:46:55 | LinusN | that's what i mean |
| 19:47:12 | amiconn | What about choosing MFDR in a way that the maximum allowed i2c clock isn't exceeded when boosting, and then letting it alone? |
| 19:47:29 | amiconn | Iirc the maximum i2c clock allowed with most devices is 400 kHz |
| 19:47:37 | | Join MO-Pantsu [0] (i=MO-Pants@deadman3000.plus.com) |
| 19:47:43 | LinusN | that would make it very slow in the normal frequency |
| 19:47:57 | MO-Pantsu | Are there any plans to enabled the radio? |
| 19:47:58 | LinusN | the controller can only do 100khz |
| 19:48:03 | amiconn | We would then run at 160 kHz at the normal frequency |
| 19:48:03 | LinusN | MO-Pantsu: of course |
| 19:48:12 | MO-Pantsu | k :) |
| 19:49:01 | LinusN | "The interface operates up to 100 kbps with maximum bus loading and timing." |
| 19:50:24 | LinusN | i love the i2c timing specs in the manual |
| 19:50:30 | LinusN | "tbd ms" |
| 19:51:06 | LinusN | every single value is tbd |
| 19:51:41 | | Join banan_ [0] (i=banan@dalink.campus.luth.se) |
| 19:52:00 | | Quit merbanan (Read error: 104 (Connection reset by peer)) |
| 19:58:43 | | Join einhirn [0] (i=Miranda@carlsberg.heim2.tu-clausthal.de) |
| 19:58:55 | LinusN | amiconn: so we set the i2c prescaler after setting the pll in bypass |
| 19:59:22 | LinusN | then there is no risk of overclocking it |
| 20:00 |
| 20:09:18 | | Join XavierGr [0] (n=XavierGr@ppp9-adsl-110.ath.forthnet.gr) |
| 20:09:31 | XavierGr | Hi all! |
| 20:29:02 | LinusN | amiconn: setting the i2c prescaler after setting the pll in bypass mode did not help |
| 20:29:27 | LinusN | so it is probably the writing of the prescaler that causes it |
| 20:36:34 | | Nick dionoea is now known as charlie_brown (N=dionoea@muscipula152.via.ecp.fr) |
| 20:36:47 | | Nick charlie_brown is now known as dionoea (N=dionoea@muscipula152.via.ecp.fr) |
| 20:43:03 | LinusN | this isn't good at all |
| 20:43:27 | LinusN | it leaves us with two options: |
| 20:43:37 | LinusN | 1) always boost during i2c communication |
| 20:43:59 | | Nick banan_ is now known as merbanan (i=banan@dalink.campus.luth.se) |
| 20:44:00 | LinusN | 2) inhibit frequency changes during i2c communication |
| 20:44:15 | LinusN | hmmm, three options |
| 20:44:56 | LinusN | 3) let set_cpu_frequency() wait for the current i2c byte transfer before switching frequency |
| 20:45:26 | LinusN | that might actually be the "cleanest" solution |
| 20:45:26 | Lear | The wait in 3 is quite short? |
| 20:46:01 | LinusN | it could be several milliseconds |
| 20:46:19 | LinusN | the uda1380 is pretty slow with the ack's |
| 20:46:34 | Lear | That's what I mean by short... :) |
| 20:46:42 | LinusN | oh .-) |
| 20:47:14 | amiconn | LinusN: 2) and 3) are no viable options imho |
| 20:47:36 | LinusN | why not 3)? |
| 20:48:03 | amiconn | Both options delay the frequency change. Imho not good if we want to boost because we need the cpu power... |
| 20:48:24 | amiconn | I think leaving mfdr alone after init would be kiss |
| 20:48:47 | amiconn | Even with 100 kHz at 120 MHz, this would still run around 40 kHz at 48 MHz |
| 20:48:49 | LinusN | probably, but then we would have to run it very slow at the normal frequency |
| 20:48:50 | Lear | amiconn: shouldn't be a problem for playback at least... |
| 20:49:03 | amiconn | I guess we don't do really large i2c transfers... |
| 20:49:08 | LinusN | no we don't |
| 20:49:25 | LinusN | i'll try that |
| 20:49:25 | amiconn | Erm, 48 MHz is the normal frequency? |
| 20:49:53 | amiconn | Or do you mean the default 11 MHz, which we normally won't use for prolonged times, except in USB mode? |
| 20:50:17 | LinusN | no i don't mean 11 |
| 20:50:18 | amiconn | Of course this would run i2c at a mere 9 khz |
| 20:50:36 | LinusN | it will do that during the frequency switch |
| 20:50:44 | LinusN | but not for more than a few ms |
| 20:50:46 | amiconn | If all timings are tbd, you could try to measure the possible maximum |
| 20:50:55 | *** | Saving seen data "./dancer.seen" |
| 20:51:11 | amiconn | My guess is it will run way beyond 100 kHz |
| 20:51:33 | amiconn | Remember that we're effectifely overclocking the MAS on archos when pitching up? |
| 20:51:47 | LinusN | i think we should ask freescale |
| 20:52:02 | | Quit XavierGr () |
| 20:52:08 | amiconn | We can pitch up to 200%, meaning the MAS pll will run at ~48 MHz instead of ~24 MHz, yet it runs stable for extended times |
| 20:52:41 | | Join hardeep [0] (i=hardeeps@norge.freeshell.ORG) |
| 20:53:39 | LinusN | looks promising |
| 20:53:43 | LinusN | no hang |
| 20:53:50 | LinusN | yet |
| 20:54:16 | amiconn | Does some code yield() while an i2c transfer is running? |
| 20:54:25 | LinusN | yes |
| 20:54:37 | amiconn | Hmm, ok :/ |
| 20:54:40 | LinusN | while it waits for each byte to be transferred |
| 20:54:57 | LinusN | and acked |
| 20:55:35 | LinusN | looks like we have nailed the sucker |
| 20:56:10 | LinusN | we should still change the backlight handling though |
| 20:56:33 | LinusN | will you have a look at it? |
| 21:00 |
| 21:00:00 | amiconn | <sigh> I think I should do that |
| 21:00:17 | amiconn | The first part is rather simple, the second part needs a bit more thinking |
| 21:00:36 | amiconn | Btw, did you already have a look at the NULL pointer access on archos? |
| 21:00:42 | LinusN | not yet |
| 21:02:18 | LinusN | btw, we have had at least two irivers that fail the check_registers() test in ata.c |
| 21:02:21 | amiconn | I also still have your oldplayer around... waiting for a button from Jörg |
| 21:02:47 | LinusN | one of them works perfectly with the test removed |
| 21:02:57 | amiconn | Yes, that's strange |
| 21:03:03 | LinusN | i don't know about the other one |
| 21:03:09 | amiconn | Do all irivers use the Toshiba disks? |
| 21:03:15 | LinusN | i think so |
| 21:03:51 | amiconn | Toshiba MK4004GAH here... |
| 21:04:19 | amiconn | I wonder what may cause the test to fail, if everything else works... |
| 21:04:35 | LinusN | scares me |
| 21:05:24 | * | LinusN is running the logic analyser with win98 in vmware |
| 21:05:47 | LinusN | saves me from rebooting when i want to run the analyzer |
| 21:05:48 | amiconn | Hmm? |
| 21:06:19 | amiconn | Ah, so your main OS isn't windows on this box |
| 21:06:31 | LinusN | not if i have a choice |
| 21:07:12 | LinusN | vmware is such a cool piece of software |
| 21:07:46 | amiconn | Yes indeed |
| 21:07:55 | amiconn | Only I use it the other way round... |
| 21:08:02 | LinusN | yeah, i know |
| 21:08:08 | LinusN | makes it even cooler |
| 21:16:05 | amiconn | Hmm, is there a timing specification for the ata register test? |
| 21:16:55 | amiconn | check_registers() performs a maximum of 64 tries. Perhaps this is too short for some disks on iriver? |
| 21:17:57 | LinusN | i find it interesting that it would need several retries in the first place |
| 21:18:25 | amiconn | Also, there is an interesting comment at line 1420 in ata.c |
| 21:18:56 | amiconn | Did that setting of IDECONFIGx already happen at the point check_registers() is called? |
| 21:19:35 | amiconn | I think there must be a reason for the 64 tries... |
| 21:22:43 | amiconn | Afaik such a thing never happened on archos (check_registers() failing on a unit otherwise working fine), at least since I joined the project |
| 21:25:37 | LinusN | it was added for the gmini, god knows why |
| 21:26:07 | LinusN | and yes, set_cpu_frequency() is called before ata_init() |
| 21:28:27 | LinusN | oh, the coldstart detection doesn't work on the iriver |
| 21:31:36 | LinusN | hmmm, maybe it does |
| 21:32:07 | LinusN | nope, it is broken |
| 21:32:33 | LinusN | so there won't be any wait_bsy() call before check_registers |
| 21:33:10 | LinusN | btw, why is the wait_bsy() conditional at all? |
| 21:33:18 | LinusN | should never hurt |
| 21:34:17 | Lear | linusn: that i2c prescaler change, does that fix the volume hang bug? |
| 21:34:26 | amiconn | LinusN: Where? |
| 21:34:33 | LinusN | Lear: yes |
| 21:34:51 | LinusN | in init_and_check() |
| 21:39:38 | amiconn | I don't k now the exact reason for this. I unified some code and made up this function, mainly to solve the problem with the archos failing to boot when pressing ON in the charging screen back then |
| 21:39:51 | amiconn | (I added the retry with always using hard reset) |
| 21:40:10 | LinusN | i think the loop should go away and the wait_bsy() should be unconditional |
| 21:40:22 | amiconn | I didn't change the sequence itself |
| 21:40:42 | amiconn | Do you mean the loop in check_registers()? |
| 21:40:46 | LinusN | yes |
| 21:41:12 | LinusN | something is really broken if you have to retry register writes |
| 21:41:48 | amiconn | I think you said the coldstart detection is broken? |
| 21:41:54 | LinusN | yes it is |
| 21:42:09 | amiconn | However, this shouldn't trigger this check_registers() problem |
| 21:42:15 | LinusN | but i don't see why the wait_bsy() shouldn't be there anyway |
| 21:42:25 | LinusN | exactly |
| 21:42:44 | amiconn | The retry in ata.c lines 1439..1445 should catch it |
| 21:43:35 | amiconn | Well, it's an unnecessary call when not coldstarting (I think), so it saves a bit of boot time not doing it |
| 21:46:02 | amiconn | Why the heck does an ext3 file system need an fsck? |
| 21:46:51 | amiconn | A regular check, I mean |
| 21:47:21 | LinusN | i don't know, it does that every x boots on my system |
| 21:47:36 | | Join Coldtoast [0] (i=edan@ppp110-114.lns1.hba1.internode.on.net) |
| 21:47:39 | amiconn | Yes, here too (for the first time now in my vm) |
| 21:54:13 | Coldtoast | I can't seem to reproduce the volume bug at all now |
| 21:54:22 | Moos | Hey Lear, thanks for your pre-amp support :) |
| 21:55:50 | LinusN | Coldtoast: which build? |
| 21:56:51 | Coldtoast | the one before the spurt of build in teh last couple of hours |
| 21:57:00 | | Join tvelocity [0] (n=tony@chan530-a135.otenet.gr) |
| 21:57:14 | Coldtoast | here we go. the 23:19 build |
| 21:58:37 | Coldtoast | I'll try the latest |
| 22:00 |
| 22:00:33 | Coldtoast | same with the latest |
| 22:00:39 | Coldtoast | I was getting it 100% of the time |
| 22:00:48 | Coldtoast | now I'm getting it 0% of the time it seems |
| 22:07:48 | Coldtoast | cool. with the replaygain implementation, you can pump the bass up and use replaygain to get the volume back |
| 22:08:45 | Lear | with lots of clipping? :) |
| 22:08:58 | dpassen1 | lol |
| 22:09:14 | Coldtoast | heh. well, it's a matter of adjusting th epreamp just right tho :) |
| 22:09:46 | dpassen1 | any difference between preamping and raising the volume? |
| 22:09:50 | Coldtoast | it's sure easy to get it to clip tho :) |
| 22:10:05 | Coldtoast | yeah. with the bass right up, volume gets limited |
| 22:10:21 | dpassen1 | oh |
| 22:10:22 | Lear | yes, preamp works on the sample values, rather than the volume "knob"... |
| 22:18:04 | amiconn | Lear: This new id3 info screen is looking rather strange to me :/ |
| 22:18:45 | Lear | amiconn: what do you mean? |
| 22:18:52 | Coldtoast | bass set to 8, treble set to 2, replaygain preamp at 7 seems to sound ok |
| 22:19:23 | Lear | coldtoast: remember that preamp is only applied to files with replaygain information... |
| 22:19:24 | amiconn | Lear: I find it harder to read and use than the old one-tag-per screen implementation |
| 22:19:41 | Coldtoast | Lear: yeah. I replaigained my whole collection the othe rday |
| 22:19:58 | amiconn | Especially irritating is the 2-line alternating between the field name and content |
| 22:20:16 | amiconn | Looks really strange on my recorder with rockfont-8 |
| 22:20:36 | Lear | you have a point, but I thought it looked silly with only two rows on text on a screen that fits 10+, so I tried to do something about it... |
| 22:21:36 | amiconn | Yes, and I know that having field name and content side-by-side isn't that good an idea either. The displays aren't that large, even on H1x0 |
| 22:22:28 | amiconn | I think this would only work nicely with icons for the fields, but then we would need decent and resource-conserving vector icons... |
| 22:22:35 | Coldtoast | what sort of impact will all this replaygain stuff have on battery life? |
| 22:23:02 | Lear | very little. I can't see any difference in boost rate at least... |
| 22:23:20 | Coldtoast | excellent |
| 22:23:34 | Coldtoast | heh. I've not charged my player in 2 weeks... just realised |
| 22:24:04 | Coldtoast | I think since putting the 2200mAH battery in, I've charged it 3 times in teh last month |
| 22:24:18 | Coldtoast | only using it about 15hrs a week tho |
| 22:24:23 | Moos | apear you don't use it a lot |
| 22:24:28 | Moos | a ok |
| 22:29:08 | | Join hanklords [0] (n=hank@gov91-1-82-234-90-79.fbx.proxad.net) |
| 22:37:18 | Lear | linusn: in your mpa.c update, what was the reason for putting the first call to recalc_samplecount() inside the while loop? It was outside before the change... |
| 22:41:08 | LinusN | i didn't see a need to call it outside the looå |
| 22:41:11 | LinusN | loop |
| 22:42:04 | Lear | well, I see no need to call it inside the loop... :) |
| 22:42:04 | LinusN | it needs to be called inside the loop anyway if the frequency divider changes |
| 22:42:18 | amiconn | Hmm, could someone with a better knowledge of perl please fix buildzip.pl to not include an empty codecs/ dir for hwcodec units? |
| 22:42:22 | Lear | well, you have the second call for that, in the "if frequency changed" block. |
| 22:42:37 | Bagder | amiconn: sure, I'll give it a check |
| 22:42:39 | LinusN | oops |
| 22:42:51 | LinusN | it was late :-) |
| 22:43:28 | Lear | I'm looking at gapless improvements, so I can take that... |
| 22:43:33 | LinusN | thanks |
| 22:43:40 | Lear | stop_skip should be used... |
| 22:43:53 | LinusN | i'm struggling with the fm radio i2c |
| 22:44:28 | Lear | ah, so it is difficult... good news that you're working with it though. :) |
| 22:44:48 | LinusN | should be very easy, but i can't get it to work for some reason |
| 22:45:04 | amiconn | I'm currently testing my updated german translation |
| 22:45:13 | amiconn | Replaygain gave me a hard time .... |
| 22:47:07 | Lear | using stop_skip seems to completely remove the glitch in the sine test case. :) |
| 22:47:56 | Lear | amiconn: Probably better off not translating it... |
| 22:48:01 | LinusN | yeah, i didn't bother to fix that in my update |
| 22:48:36 | Lear | now I just need to make sure it doesn't quit too early... |
| 22:48:57 | Coldtoast | writing ID3 tags isn't going to affect replaygain info is it? |
| 22:49:05 | Coldtoast | probably a silly question |
| 22:49:50 | Lear | as long as the program updating the tags leaves the TXXX frames, no... |
| 22:50:25 | Coldtoast | I'll give foobar2k a try |
| 22:50:31 | Coldtoast | I usually use Tag & Rename |
| 22:50:32 | | Join elinenbe [0] (i=elinenbe@207-237-225-9.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 22:50:56 | *** | Saving seen data "./dancer.seen" |
| 22:52:14 | amiconn | Lear: I don't think so. Not translating it would lead to many so-called (in german) "denglisch" phrases, which I severely dislike... |
| 22:53:11 | amiconn | ...or I would have to leave many more expressions untranslated, which jeopardises the purpose of a language file... |
| 22:53:39 | LinusN | as i see it, Replaygain is a name, much like a trademark |
| 22:53:58 | LinusN | not supposed to be translated |
| 22:54:24 | LinusN | like "Windows" |
| 22:54:37 | amiconn | LinusN, different question for you: What would I have to do to get some optimised asm routines considered for inclusion by the gcc team? |
| 22:54:59 | LinusN | send a patch to the gcc mailing list |
| 22:55:09 | Lear | Interesting... Samplecount seems to be very reliable, but the time estimate is can be a couple of seconds off (for a long file). |
| 22:55:20 | amiconn | I can't do a proper patch against the gcc source |
| 22:55:35 | amiconn | I don't know how gcc includes its library routines |
| 22:55:51 | amiconn | I'm talking about my optimised 64 bit multiplication routines |
| 22:56:13 | LinusN | join the mailing list and ask them |
| 22:56:34 | LinusN | i don't really know myself |
| 22:56:40 | amiconn | The SH1 routine is around 2.5 times faster than the (obviously compiled from plain C) version, and the coldfire routine is ~10% faster than the already optimised gcc routine |
| 22:57:03 | amiconn | ...and of course both routines are also smaller than the originals |
| 22:57:17 | LinusN | do they work on all coldfire variants? |
| 22:57:37 | amiconn | They should work on all coldfire v2 variants |
| 22:58:00 | amiconn | No exotic instructions used |
| 22:58:21 | amiconn | Perhaps they work on even more 68k derivates; I can't test... |
| 22:59:12 | amiconn | The SH1 routine should also work on SH2 and SH-DSP, but I don't know whether gcc already has optimised routines for these |
| 22:59:31 | amiconn | ...and of course it wouldn't be the optimal routine for these |
| 22:59:36 | Lear | most exotic is mulu.l, afaict, so it should work on most... |
| 22:59:58 | amiconn | mulu.l is just 32x32->32bit |
| 23:00 |
| 23:00:26 | amiconn | I am relying on that truncation |
| 23:00:37 | Lear | yes, but not all cpu:s have them, afaicr. E.g., 68000 lacks it, I think. |
| 23:00:55 | amiconn | Yes, the very old variants don't have that |
| 23:04:49 | | Join Cassandra [0] (n=cassandr@82-70-230-150.dsl.in-addr.zen.co.uk) |
| 23:05:43 | Cassandra | Hello all. |
| 23:06:12 | amiconn | hi Cassandra |
| 23:06:26 | Cassandra | I swear there is some sort of conspiracy. The feature freeze coincides with my holiday. I'll have about 5 days of freeze to do the manual in. |
| 23:10:35 | Coldtoast | heh. pointless game of the day: translate a phrase from English to some other language using Babelfish then translate the result back to English |
| 23:10:41 | amiconn | Cassandra: Certainly not from my side. I was on a trip to Rome when Daniel announced the freeze... |
| 23:11:18 | Cassandra | ami: Oh, I'm not blaming anyone. Just bad luck. |
| 23:11:31 | Cassandra | I'll see if I can get some done next week anywayl. |
| 23:11:38 | Coldtoast | night |
| 23:11:41 | | Quit Coldtoast ("Peace and Protection 4.22") |
| 23:12:21 | Cassandra | *sigh* Player now has a working hard disk in it, but still won't boot. |
| 23:12:45 | Cassandra | I was hoping to have it running in time for the 2.5 manual, but looks like I'm going to have to manage without it. |
| 23:13:08 | Cassandra | I'm impressed by how thoroughly someone managed to knacker this unit. |
| 23:18:56 | | Join stripwax_ [0] (n=stripwax@213-228-241-36.dsl.prodigynet.co.uk) |
| 23:19:09 | stripwax_ | hello |
| 23:21:04 | | Quit Rick (Read error: 104 (Connection reset by peer)) |
| 23:21:33 | | Join Rick [0] (i=rick@pool-71-108-13-143.lsanca.dsl-w.verizon.net) |
| 23:23:36 | amiconn | Cassandra: You should get in contact with [IDC]Dragon |
| 23:24:08 | amiconn | He has a big pile of archoses (mostly players) from an aucktion of defective units |
| 23:24:39 | amiconn | Some of them are probably only missing a harddisk to get them working again |
| 23:26:05 | | Quit Rick (Read error: 104 (Connection reset by peer)) |
| 23:27:11 | | Join Rick [0] (i=rick@pool-71-108-13-143.lsanca.dsl-w.verizon.net) |
| 23:30:40 | amiconn | LinusN: Btw, the protection from extraneous calls also fixes a glitch in Info->Debug->CPU frequency that I observed some time ago |
| 23:32:19 | stripwax_ | When I'm looking at the playback thread debug info on rockbox, it looks like the pcm buffer never gets fully full. is that expected? also it never gets anywhere near empty either (seems to get to about 60% full before boost kicks in when playing q5 oggs -> boost ratio of about 25%). Is this not aggressive enough? |
| 23:33:19 | amiconn | Pressing SELECT very short did set the CPU to 11 MHz, but holding it a bit longer resetted it again to 48 MHz. Pressing Left/Right or other unassigned buttons did the same - now I know why... |
| 23:35:22 | Lear | stripwax_: the "watermark" of the pcm buffer is quite high, that's why boost kicks in soon. I've tried with a reduced watermark, and it seems to work well... |
| 23:35:22 | LinusN | amiconn: glitch? you mean that it flickers beween 120 and 48 mhz? |
| 23:35:44 | amiconn | [23:33:19] <amiconn> Pressing SELECT very short did set the CPU to 11 MHz, but holding it a bit longer... |
| 23:35:53 | LinusN | ah |
| 23:36:31 | amiconn | That was because of the button events triggering that very short boost/unboost sequence... |
| 23:36:52 | stripwax_ | Lear - any idea why it's set so high? also any idea why (it seems like) the buffer never gets fully filled? |
| 23:38:15 | Lear | not really, no. It made some sense to have it that large when the pcmbuffer was 3 times larger, but perhaps I just wasn't reduced when the pcmbuf was reduced... |
| 23:38:29 | Lear | as to filling, I don't know really... |
| 23:38:44 | stripwax_ | Lear - ahhhh.... didn't know pcmbuf was reduced. yeah, that could well be it |
| 23:38:47 | stripwax_ | thx |
| 23:39:21 | | Join Strath [0] (i=mike@dgvlwinas01pool0-a217.wi.tds.net) |
| 23:39:48 | | Join ender` [0] (i=ychat@tm.213.143.74.124.dc.telemach.net) |
| 23:47:07 | | Join Craig__ [0] (n=chatzill@dpc6682050001.direcpc.com) |
| 23:48:09 | LinusN | amiconn: are you working on the unboost fix too? |
| 23:48:17 | amiconn | Just committed... |
| 23:48:54 | LinusN | gr8 |
| 23:48:56 | amiconn | It was indeed as simple as to send an event to the backlight thread, and unboost from there |
| 23:49:05 | LinusN | neat |
| 23:52:02 | Craig__ | hi all. anyone interested in a patch "prompt user to save modified current playlists if some action is about to wipe it"? |
| 23:53:03 | amiconn | I think this would be rather annoying... |
| 23:53:43 | Craig__ | more annoying than losing a playlist it took an hour to make? |
| 23:54:15 | amiconn | That never happened to me, being a rockbox user for over 2 years now |
| 23:55:21 | Craig__ | I'm an iRiver user, and currently the difference is between a long and a short push. It's come up in the forums before I believe. |
| 23:55:30 | amiconn | (referring to both loosing a playlist unintentionally, and also making a playlist taking that long) |
| 23:55:58 | Lear | He, I'm not sure if I've ever saved a playlist from Rockbox (other than by mistake)... |
| 23:56:11 | amiconn | Yes I know what the difference is. It's the same on archos, not from the beginning, but for quite some time now |
| 23:56:27 | amiconn | I don't understand how you can get this wrong |
| 23:57:17 | amiconn | The actions are assigned in a way that the safer action happens (just displaying the context menu) if you accidentally push longer than intended |
| 23:57:25 | Craig__ | Use case: sitting around the camp fire. Passing the iRiver around the friends saying "pick the next few tracks". They will always lose it |
| 23:58:22 | Craig__ | No, short push is make new dynamic playlist from directory. Long push is go to menu to add to playlist. |
icon identifies that the person is a core developer (has commit access).