| 00:00:01 | haruki | ah yes, after running vbr-fix the file now lists as being ten minutes long |
| 00:00:20 | amiconn | yup. Odd playing time for both files. Iirc rockbox does not write the correct vbr geader when timesplit is on (probably it would take too long) |
| 00:01:29 | haruki | well thanks for helping me test this kludge ;) |
| 00:01:57 | haruki | i wonder if that fellow who is implementing this feature is using the same methods... |
| 00:02:02 | haruki | ;) |
| 00:03:37 | amiconn | I don't think so. A proper implementation would also allow to set a specific start time |
| 00:04:08 | amiconn | ...even waking up the recorder at the right time if you either have the alarm mod or a v2/fm |
| 00:05:34 | haruki | now that will be a very cool feature. hey i just had an odd idea, do you think the recorder is capable of a cutup feature? where it would "randomly" rearrange an mp3 file? |
| 00:06:51 | amiconn | Cutting mp3s is not that easy. First, cutting is only possible at frame boundaries |
| 00:08:14 | amiconn | If the bit reservoir is used, you will certainly hear a glitch at the cut point. Even without bit reservoir (independent frames) there will be a slight glitch |
| 00:08:46 | amiconn | But it is certainly possible to implement that, even on the players |
| 00:09:48 | haruki | interesting, i think i may look into that, i wonder if anyone would be interested in it besides me |
| 00:10:03 | | Join iRiverMan [0] (~acba8081@labb.contactor.se) |
| 00:11:18 | amiconn | haruki: There is already an mp3 split editor plugin, perhaps you can reuse some code |
| 00:12:09 | amiconn | Bagder: U there now? |
| 00:15:55 | haruki | thanks a lot amiconn! |
| 00:16:39 | | Quit iRiverMan ("CGI:IRC (EOF)") |
| 00:16:47 | amiconn | np |
| 00:18:17 | | Join einhirn [0] (~Miranda@carlsberg.heim2.tu-clausthal.de) |
| 00:18:19 | | Quit haruki (Remote closed the connection) |
| 00:33:14 | | Quit einhirn (Read error: 54 (Connection reset by peer)) |
| 00:34:39 | amiconn | Yay! Rockbox on Ondio is *significantly* more energy efficient than archos fw! |
| 00:38:03 | | Join einhirn [0] (~Miranda@carlsberg.heim2.tu-clausthal.de) |
| 00:39:28 | | Join gromit` [0] (~gromit@ALagny-151-2-8-106.w82-121.abo.wanadoo.fr) |
| 00:46:13 | | Quit _aLF ("Leaving") |
| 00:57:02 | *** | Saving seen data "./dancer.seen" |
| 01:00 |
| 01:20:27 | | Quit AciD (Remote closed the connection) |
| 01:24:15 | | Join napgravy [0] (user@S0106004095d1df8f.cg.shawcable.net) |
| 01:24:43 | | Quit napgravy (Client Quit) |
| 01:30:20 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 01:30:30 | amiconn | hi LinusN |
| 01:30:36 | LinusN | hi |
| 01:41:55 | amiconn | Did you notice my message about power drain with rockbox vs archos on Ondio? |
| 01:42:39 | amiconn | We can expect ~40% longer battery life |
| 01:47:05 | LinusN | are you kidding? |
| 01:47:27 | amiconn | Nope |
| 01:47:41 | amiconn | I wonder whether I should put the raw data into a wiki table |
| 01:48:45 | amiconn | I measured power consumption in various operating states and 2 different voltages with both firmwares |
| 01:50:38 | LinusN | why are we so much better? |
| 01:51:25 | amiconn | I think its because rockbox uses the sleep feature of the CPU. Power consumption varies much more with rockbox than it does with archos |
| 01:52:25 | amiconn | Some nice values, at 4.6 V (maximum voltage): Browser, no scrolling lines - rockbox 54 mA, archos 90 mA |
| 01:53:13 | amiconn | WPS, no scrolling, (rockbox: peakmeter, high performance) - rockbox 65 mA, archos 92 mA |
| 01:54:10 | amiconn | Playback, while reading from internal flash - rockbox 85 mA, archos 130 mA |
| 01:54:21 | amiconn | ... |
| 01:55:00 | LinusN | cool |
| 01:55:46 | amiconn | I think this is a strong argument for rockbox on Ondio: "Wanna waste less money for batteries - use rockbox!" |
| 01:57:33 | amiconn | I'll put together a little table. |
| 01:58:12 | LinusN | you said "did you notice my message" |
| 01:58:17 | LinusN | where was that? |
| 01:59:20 | LinusN | ah |
| 01:59:23 | LinusN | <amiconn> Yay! Rockbox on Ondio is *significantly* more energy efficient than archos fw! |
| 01:59:27 | amiconn | yup |
| 01:59:40 | LinusN | majpr coolness |
| 02:00 |
| 02:01:29 | amiconn | I hope Jörg will also do some measurements with his Ondio FM, for comparison. I expect similar figures |
| 02:02:32 | amiconn | I did thgat measurements mainly because I want to adapt the power thread runtime estimation |
| 02:02:35 | amiconn | *that |
| 02:02:39 | | Quit mecraw__ ("Trillian (http://www.ceruleanstudios.com)") |
| 02:04:58 | amiconn | The 10 hours given by archos are rather optimistic... with their firmware |
| 02:06:51 | amiconn | Multi-volume browsing would be the 2nd killer feature... |
| 02:15:49 | LinusN | absolutely |
| 02:17:26 | amiconn | Re your latest commit: More viewers coming up? |
| 02:21:21 | amiconn | We have an all-green build table :) |
| 02:25:14 | LinusN | yes, the menu had a maximum of 8, and viewers.txt had 8 also, so we couldn't add more |
| 02:25:42 | LinusN | favorites.rock is next to be added |
| 02:27:16 | amiconn | That reminds me I should finally do that .bmp loader... |
| 02:35:58 | amiconn | Current measurement table done. |
| 02:45:55 | amiconn | Tts, cu |
| 02:46:25 | | Part amiconn |
| 02:57:06 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:36:33 | | Join MisticJeff [0] (~0c68cc30@labb.contactor.se) |
| 03:36:46 | MisticJeff | howdy |
| 03:36:54 | LinusN | hola |
| 03:37:03 | MisticJeff | what's new? |
| 03:37:49 | LinusN | siting here, debugging the threading code on my iriver |
| 03:38:00 | MisticJeff | wow, lots of fun |
| 03:38:20 | MisticJeff | im at work |
| 03:38:29 | MisticJeff | just checking in, gotta run |
| 03:39:06 | MisticJeff | see you later and good luck... let me know if you or Zagor or both want to get an H140 |
| 03:39:35 | | Part MisticJeff |
| 03:40:51 | | Part LinusN |
| 04:00 |
| 04:52:29 | | Quit scott666_ ("i'll be back...eventually...") |
| 04:54:39 | | Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
| 04:57:08 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:55:11 | | Quit _Lucretia (Read error: 60 (Operation timed out)) |
| 06:00 |
| 06:08:30 | | Join _Lucretia [0] (~munkee@abyss2.demon.co.uk) |
| 06:19:48 | | Join ashridah [0] (ashridah@220.253.119.91) |
| 06:42:39 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 06:57:09 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:20:58 | | Join gromit`` [0] (~gromit@ALagny-151-2-8-139.w82-121.abo.wanadoo.fr) |
| 07:32:50 | | Join Stryke` [0] (~Chairman8@resnet-241-86.resnet.UMBC.EDU) |
| 07:37:31 | | Quit gromit` (Read error: 110 (Connection timed out)) |
| 07:40:44 | | Quit _Lucretia (Read error: 110 (Connection timed out)) |
| 07:41:41 | | Join _Lucretia [0] (~munkee@abyss2.demon.co.uk) |
| 07:43:32 | | Quit Stryke` ("Friends don't let friends listen to Anti-Flag") |
| 08:00 |
| 08:05:13 | | Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) |
| 08:05:48 | [IDC]Dragon | 'morning! |
| 08:05:54 | LinusN | hi |
| 08:06:22 | [IDC]Dragon | do you sleep at all? |
| 08:06:29 | LinusN | not really :-) |
| 08:06:49 | [IDC]Dragon | wish I could do that |
| 08:06:56 | LinusN | me too :-) |
| 08:09:16 | [IDC]Dragon | Jens' all green build table has a stain again |
| 08:09:26 | LinusN | yeah, my fault |
| 08:18:34 | [IDC]Dragon | I wonder why Rockbox consumes such significantly less power on the Ondio |
| 08:18:49 | LinusN | probably the SLEEP in the threading code |
| 08:19:03 | [IDC]Dragon | I once was comparing sleeping CPU vs. 100% busy, that was just a few mA |
| 08:19:16 | LinusN | hmmm |
| 08:20:26 | | Join MoGle3 [0] (mogle3@213.177.236.210.adsl.griffin.net.uk) |
| 08:33:14 | | Join Lucretia_ [0] (~munkee@abyss2.demon.co.uk) |
| 08:34:57 | | Quit _Lucretia (Read error: 110 (Connection timed out)) |
| 08:35:56 | | Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 08:40:33 | | Quit MoGl53 (Read error: 110 (Connection timed out)) |
| 08:44:01 | | Join amiconn [0] (~jens@pD95D1768.dip.t-dialin.net) |
| 08:44:26 | amiconn | Morning all |
| 08:44:56 | LinusN | hi |
| 08:45:53 | [IDC]Dragon | morning Jens |
| 08:46:22 | [IDC]Dragon | I haven't described my daily morning routine to you guys: |
| 08:46:52 | [IDC]Dragon | while still dark in the bedroom, I reach for my webpad, to check what you guys did last night |
| 08:48:05 | [IDC]Dragon | makes me feel like a lamer sometimes, when I went to bed like 4 hours earlier |
| 08:48:29 | LinusN | 4 hours! luxury! |
| 08:50:05 | [IDC]Dragon | indeed |
| 08:50:22 | [IDC]Dragon | with no kids, I have no such training |
| 08:50:28 | LinusN | :-) |
| 08:50:56 | | Join Zagor [242] (~bjst@labb.contactor.se) |
| 08:51:12 | LinusN | morning Zagor |
| 08:52:04 | Zagor | morning |
| 08:53:14 | [IDC]Dragon | yawning |
| 08:53:36 | * | Bagder enters |
| 08:53:41 | Bagder | hi crowd |
| 08:53:56 | amiconn | [IDC]Dragon: Also no kids here... |
| 08:53:59 | [IDC]Dragon | hi |
| 08:54:10 | [IDC]Dragon | amiconn: I guessed |
| 08:54:25 | [IDC]Dragon | a woman? |
| 08:54:38 | amiconn | nope |
| 08:55:02 | [IDC]Dragon | now I know the secret of Jens' hacking resourcefulness |
| 08:56:00 | LinusN | hi Bagder |
| 08:56:28 | * | Bagder only has one child, LinusN has two! |
| 08:57:11 | *** | Saving seen data "./dancer.seen" |
| 08:58:55 | [IDC]Dragon | amiconn: nice catch on the inits |
| 08:59:17 | amiconn | [IDC]Dragon: If you want to check something concerning the energy consumption rockbox<->archos, you could check whether archos fw holds the flash /cs low all the time (I didn't do this) |
| 08:59:39 | [IDC]Dragon | I can try, yes |
| 09:00 |
| 09:00:15 | [IDC]Dragon | or rather, do that (not much trying involved) |
| 09:00:49 | dwihno | Bagder only has one child, LinusN ;) |
| 09:02:09 | amiconn | [IDC]Dragon: (inits) Wasn't that easy to find, although the USB init problem was clearly visible in "Show IO ports", once I had a clue what might cause the instability |
| 09:03:02 | [IDC]Dragon | why is the order important? |
| 09:03:20 | LinusN | speaking of instability, i debugged the coldfire threading code for over an hour, with the DRAM refresh turned off :-) |
| 09:03:34 | [IDC]Dragon | oops |
| 09:03:34 | * | Bagder giggles |
| 09:03:46 | [IDC]Dragon | how long does it last without? |
| 09:04:24 | [IDC]Dragon | in the past, I found DRAMS very remarkably tolerant |
| 09:05:02 | LinusN | that's why i didn't notice at first |
| 09:05:11 | LinusN | it lasted for minutes |
| 09:05:34 | [IDC]Dragon | whow |
| 09:05:50 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 09:05:57 | LinusN | one or two bit faults here and there |
| 09:07:05 | [IDC]Dragon | amiconn: your power tests were with rombox, or reguler? |
| 09:08:34 | amiconn | rombox |
| 09:09:24 | [IDC]Dragon | did you compare rombox vs. "rambox"? |
| 09:12:13 | Bagder | whoa openneo commits |
| 09:12:24 | dwihno | speaking of nothing, rombox still stuffers from rld (I recall someone mentioning something about rld decrease after rombox) |
| 09:12:44 | Bagder | "Heap size increased to 63 KB" |
| 09:12:46 | Bagder | hehe |
| 09:13:41 | LinusN | they are slowly sinking into the dynamic memory swamp |
| 09:13:46 | Bagder | "Added support for autoexec.cfg" |
| 09:14:41 | Bagder | LinusN: indeed |
| 09:14:55 | Bagder | with 256K ram, 63 in the heap seems... excessive |
| 09:25:34 | | Join einhirn [0] (Miranda@bsod.rz.tu-clausthal.de) |
| 09:30:23 | | Quit ashridah ("woohoo! pizzapizzapizzapizzapizza PIZZA.... damn. that means i need the phone. sucky house") |
| 09:59:20 | amiconn | [IDC]Dragon: No I didn't compare, didn't think of it. Seems like a good thing to try... |
| 10:00 |
| 10:02:51 | amiconn | LinusN: Congrats on the iRiver progress, btw. |
| 10:07:07 | LinusN | it's nothing compared to what you guys have done with the Ondio, my hat is off |
| 10:07:40 | * | LinusN proudly hands over the Rockbox Speed-Porting award to Jens and Jörg |
| 10:08:41 | amiconn | For Ondio, we could re-use a large part of rockbox as-is, and we didn't have to deal with the lowest level. |
| 10:09:34 | LinusN | true, but you have done a remarkable job with the MMC driver |
| 10:09:38 | LinusN | and FAT16 |
| 10:09:45 | Zagor | the offer to sponsor your ondios is still valid, btw. |
| 10:16:14 | [IDC]Dragon | Ondio wasn't porting, rather "adjusting" |
| 10:17:32 | [IDC]Dragon | Zagor: thanks for the offer, I come back to that when we have users, and possibly donations from them |
| 10:20:44 | [IDC]Dragon | right now, ondio rockbox is a solution in search for the problem |
| 10:20:55 | LinusN | no |
| 10:21:19 | LinusN | it's a fun project for you and Jens, and Rockbox benefits from it |
| 10:21:52 | [IDC]Dragon | besides that, sure ;-) |
| 10:22:07 | Zagor | it's also a good test bench for some of the port preparations, such as the build tools and the button code |
| 10:23:35 | amiconn | Speaking of porting: As the init issues on Ondio are solved now, I'll go ahead and adapt some more plugins to Ondio. On the way I'll change all of them to use the default event handler. |
| 10:23:46 | LinusN | wonderful |
| 10:24:11 | amiconn | Q: Do you agree that after this is done, usb_screen() should be ditched from the plugin api? |
| 10:27:18 | LinusN | maybe |
| 10:27:41 | LinusN | if there isn't any use for it |
| 10:28:18 | [IDC]Dragon | are you happy with the cleanup callback? |
| 10:28:20 | LinusN | my original idea was that the plugin should "grab" the events itself if it didn't want/like the default handling |
| 10:28:42 | LinusN | (like if there was a need for cleanup) |
| 10:28:50 | LinusN | the callback solves most of these problems |
| 10:29:10 | LinusN | so i think the usb screen can go |
| 10:29:41 | LinusN | my original idea looked like this: |
| 10:29:52 | LinusN | case SYS_USB_INSERTED: |
| 10:30:00 | LinusN | cleanup(); |
| 10:30:15 | LinusN | default_handler(SYS_USB_INSERTED); |
| 10:30:19 | LinusN | break; |
| 10:30:54 | amiconn | I first considered this approach, but there is a problem with it. |
| 10:30:58 | LinusN | however, the callback idea might be better since we don't have to add new cases for new events that need cleanup |
| 10:31:07 | amiconn | Yes, that's the point |
| 10:31:29 | LinusN | and we can still do it "my way" if there is a need for it |
| 10:32:04 | LinusN | usb_screen() isn't directly called with my method either |
| 10:35:03 | amiconn | The other solution I discussed with Bagder is to introduce a second function that checks whether an event is to be handled by the default handler. |
| 10:35:41 | amiconn | ..and then do the following in the plugin: |
| 10:35:54 | amiconn | if (is_default_event(event) { |
| 10:36:00 | amiconn | cleanup(); |
| 10:36:11 | amiconn | default_event_handler(event); |
| 10:36:13 | amiconn | } |
| 10:44:39 | LinusN | nah |
| 10:45:04 | LinusN | i admit that it's "cleaner", but i can live with the callback as well |
| 10:47:14 | [IDC]Dragon | but this readsmore KISS |
| 10:49:13 | amiconn | ? |
| 10:49:27 | LinusN | in the KISS sense, i'd say is_default_event() is to prefer |
| 10:49:41 | [IDC]Dragon | you better see what's going on |
| 10:49:48 | LinusN | yup |
| 10:57:13 | *** | Saving seen data "./dancer.seen" |
| 10:58:01 | amiconn | So I think I should implement it that way... Only issue is that you have to remember to adapt this function as well whenever a new default event is added |
| 10:58:42 | LinusN | yes, but they can reside in the same file (misc.c) |
| 10:59:14 | amiconn | Of course |
| 10:59:26 | LinusN | still, it isn't waterproof, as not all (future) default events would need a cleanup |
| 11:00 |
| 11:00:27 | LinusN | but so far, all SYS_ events need cleanup |
| 11:02:57 | | Join ashridah [0] (ashridah@220-253-120-64.VIC.netspace.net.au) |
| 11:03:49 | [IDC]Dragon | then call it needs_cleanup() or so |
| 11:04:33 | [IDC]Dragon | it can call default_event_handler() by itself if not |
| 11:05:06 | LinusN | let's keep the callback |
| 11:05:25 | [IDC]Dragon | but this is a bit ugly again, because only in the cleanup case you'd have to call default_event_handler() afterwards |
| 11:05:25 | LinusN | then the default handler can decide if it has to call the cleanup function or not |
| 11:12:05 | amiconn | LinusN: That's like it is now |
| 11:14:29 | LinusN | yes |
| 11:15:32 | amiconn | Or with the 2-function approach, the first function could be called get_default_event_class() with an enum return value { DEFAULT_EVENT_NONE, DEFAULT_EVENT_SIMPLE, DEFAULT_EVENT_COMPLEX }, or such |
| 11:18:24 | LinusN | nah, let's keep the current solution, and we'll expand it if the need arises |
| 12:00 |
| 12:33:38 | | Quit scott666_ ("i'll be back...eventually...") |
| 12:54:07 | [IDC]Dragon | LinusN: want to have a final word about file/function names for the tuner split? |
| 12:57:17 | *** | Saving seen data "./dancer.seen" |
| 13:00 |
| 13:01:15 | | Join Norrin [0] (~440d6a3e@labb.contactor.se) |
| 13:01:42 | | Join Nuxator [0] (~chatzilla@pc102.ie2.u-psud.fr) |
| 13:02:15 | Norrin | Hello all. I have a Archos FMRecorder which I let the battery run down on. Now I can't get it to take a charge to turn back on. |
| 13:02:38 | LinusN | how long have you tried to charge it? |
| 13:02:46 | LinusN | have you flashed rockbox? |
| 13:02:47 | Norrin | When I plug in the charger, nothing comes on the screen and you can just hear it clicking. Let it on overnight. |
| 13:03:11 | Norrin | Yep, I've been using Rockbox for a while now. |
| 13:03:48 | Nuxator | hello all |
| 13:03:50 | Norrin | I've tried holding F1 when I plug it in along with pressing the ON and OFF buttons, it's dead. |
| 13:03:54 | LinusN | try to hold F1 when you insert the charger |
| 13:03:58 | LinusN | :-) |
| 13:04:14 | LinusN | also try to insert the USB cable as well |
| 13:04:20 | Nuxator | just wanted to show support to linusN for iriver port |
| 13:04:27 | LinusN | Nuxator: thanks |
| 13:04:47 | Nuxator | i see that screen is blicking ;) |
| 13:04:57 | LinusN | Nuxator: blink blink |
| 13:04:57 | Nuxator | next step hello world |
| 13:05:29 | Nuxator | keep going this good work see you |
| 13:06:49 | | Quit Nuxator ("ChatZilla 0.8.31 [Mozilla rv:1.4.1/20031008]") |
| 13:07:59 | Norrin | Tried USB cable also, nothing. I can barely see a little bit of the green light on when I plug it in. when I listen closely to the recorder, I can hear it clicking when it's plugged in. Not a hard drive click but something else. |
| 13:08:31 | LinusN | try to extract the battery and insert it again |
| 13:09:11 | Norrin | I was afraid you would say that. That's not so easy so I'll have to try it later and get back to you. |
| 13:11:00 | [IDC]Dragon | I wonder how this still happens, and if I can improve somehow |
| 13:11:50 | Zagor | I don't see what we can do on the LiIon models |
| 13:12:23 | [IDC]Dragon | shutdown the HD even earlier? |
| 13:13:01 | [IDC]Dragon | right now it's done by the bootloader, if charger plugged |
| 13:14:03 | [IDC]Dragon | it could be done by the flash "patch list", which is processed by the boot ROM, but then unconditional |
| 13:14:56 | [IDC]Dragon | the boot loader would have to conditionally switch it on again |
| 13:19:18 | LinusN | we should try that |
| 13:19:49 | [IDC]Dragon | so far, I stayed away from that patch list |
| 13:22:59 | Zagor | how long do we have the disk on today? |
| 13:23:05 | Zagor | 100ms? 50? |
| 13:23:22 | [IDC]Dragon | something it that range, perhaps |
| 13:23:43 | [IDC]Dragon | as long as it takes the boot rom to descramble my bootloader |
| 13:24:02 | [IDC]Dragon | plus some reset holdoff time |
| 13:24:08 | Zagor | what was the reason the bootloader enables it? |
| 13:24:33 | [IDC]Dragon | it doesn't, it disables it if the charger is plugged |
| 13:24:45 | [IDC]Dragon | the disk is on by hardware default |
| 13:25:19 | Zagor | so how fast does the archos firmware turn it off? |
| 13:25:42 | [IDC]Dragon | slower |
| 13:26:23 | Zagor | I thought using F1+ON was used as a "safe boot" for rundown batteries. is that not the case? |
| 13:27:53 | [IDC]Dragon | it is a safe mode for misflashed ucl, primarily |
| 13:29:32 | Zagor | yes, i just thought I had read somewhere about people having better luck booting with f1 when batteries are low. guess i was wrong. |
| 13:30:23 | LinusN | i have had the same problem with my fm, and it isn't even flashed |
| 13:31:46 | [IDC]Dragon | on sw charge controlled models, archos charges right away, vs. we are hesitating |
| 13:32:04 | Zagor | ah ok |
| 13:33:52 | [IDC]Dragon | none-flashed FMs are probably prone to flat batteries, too |
| 13:34:26 | [IDC]Dragon | since Archos has to shut off the disk as well, and are not getting there earlier |
| 13:35:15 | LinusN | i had that exact problem with my non-flashed fm |
| 13:35:36 | [IDC]Dragon | their loader is larger than mine, must take longer to descrable |
| 13:36:09 | [IDC]Dragon | but the patch list is processed by the boot rom, before it descrambles |
| 13:37:28 | [IDC]Dragon | the romless variant is different, that jump straight into my code |
| 13:37:39 | [IDC]Dragon | jumps |
| 13:49:12 | | Join webguest98 [0] (~c31ce021@labb.contactor.se) |
| 13:49:51 | [IDC]Dragon | LinusN: have you seen my question about filenames for the tuner split? |
| 13:50:41 | [IDC]Dragon | the driver is currently called fmradio.c |
| 13:51:29 | [IDC]Dragon | I locally added fmradio_i2c.c for the Philips physical interface |
| 13:52:16 | [IDC]Dragon | plus 2 new fils, tuner_philips.c and tuner_samsung.c, for the locical driver (the abstraction layer) |
| 13:52:58 | Zagor | is it probable that the fmradio_i2c.c code will be usable for another tuner? |
| 13:53:14 | [IDC]Dragon | no, not really |
| 13:53:46 | [IDC]Dragon | it transfers 5 bytes to/from a fixed I2C address |
| 13:54:02 | Zagor | i'd rather have it called something with philips then |
| 13:54:17 | [IDC]Dragon | like fmradio.c transfers 4 bytes via an SPI-ish protocol |
| 13:54:28 | [IDC]Dragon | for the samsung tuner |
| 13:54:49 | [IDC]Dragon | yes, renaming fmradio.c as well would be nicer |
| 13:55:07 | Zagor | yes |
| 13:55:33 | [IDC]Dragon | samsung_interface.c and philips_interface.c |
| 13:55:58 | [IDC]Dragon | or even with S1A0903X01 and TEA5767? |
| 13:55:59 | Zagor | is there really a point in putting those 100 lines of code into a separate file? |
| 13:56:27 | [IDC]Dragon | that is the code to be ported, for another box |
| 13:56:37 | [IDC]Dragon | the other code can stay |
| 13:58:07 | [IDC]Dragon | I'd rather prefer to pick the files per model via SOURCES |
| 13:58:37 | [IDC]Dragon | instead of #ifdef'ing two disjunct implementations |
| 13:58:37 | amiconn | [IDC]Dragon: Speaking about the scrambling: When I tried to disassemble the archos rom yesterday, I noticed the scrambling. Is this the same scrambling algo that is used for .ajz? |
| 13:58:59 | [IDC]Dragon | rom is unscrambled, flash is |
| 13:59:10 | amiconn | s/rom/flash/ |
| 13:59:14 | | Quit webguest98 ("CGI:IRC (EOF)") |
| 13:59:17 | [IDC]Dragon | do you know my "extract" tool? |
| 13:59:25 | amiconn | No? |
| 13:59:37 | [IDC]Dragon | it's in the flash subdir |
| 13:59:50 | [IDC]Dragon | an pulls a .ajz from a flash image |
| 13:59:54 | [IDC]Dragon | and |
| 14:00 |
| 14:00:32 | amiconn | Okay. I guess Iwon't need it now, since the init problems are solved. Maybe I have to use it again when I get to tackle the palyer flashing |
| 14:01:02 | [IDC]Dragon | I have all that taken apart already |
| 14:01:43 | Zagor | [IDC]Dragon: i assume there is a new tuner.h aswell? |
| 14:02:12 | [IDC]Dragon | Zagor: yes, this defines the tuner-independent interface |
| 14:03:45 | Zagor | do we have the philips radio datasheet? |
| 14:03:53 | amiconn | [IDC]Dragon: I got the archos fw flash version another way - unpacked the .ucl you provided :) |
| 14:04:00 | [IDC]Dragon | yes, see the Ondio wiki page |
| 14:04:22 | [IDC]Dragon | amiconn: that's another option, yes |
| 14:05:10 | [IDC]Dragon | the flash contains the (scrambled) archos loader, plus this image |
| 14:05:32 | [IDC]Dragon | Player don't have that loader, just one image |
| 14:05:41 | [IDC]Dragon | Players |
| 14:05:47 | Zagor | hmm I changed my mind. if fmradio_i2c.c is as simple as the current fmradio.c, I'd say fmradio_i2c is a good name. |
| 14:07:05 | Zagor | while it's not certain it will be compatible with other i2c-connected radios, it's not really philips specific either |
| 14:07:07 | amiconn | Zagor, LinusN: Speaking about the source tree - there is one file that imho should go into another folder |
| 14:07:17 | LinusN | the philips data sheet is on the regular data sheet page as well |
| 14:07:18 | [IDC]Dragon | the "full" name would rather be fmradio_ondio_tea5767 |
| 14:07:48 | [IDC]Dragon | I should merge the Ondio datasheets and port map |
| 14:08:38 | Zagor | [IDC]Dragon: not unless it contains tea5767-specific code. which I understand it doesn't. no need to make the name more narrow than necessary. |
| 14:09:01 | Zagor | LinusN: how is the tuner is connected to the cpu on the iriver? |
| 14:09:13 | amiconn | dac.h is in firmware/drivers, while it should go into firmware/export |
| 14:09:19 | LinusN | i2c bit-banging on port pins |
| 14:09:33 | [IDC]Dragon | it does, it transfers 5 bytes (the packet for that tuner) to its specific I2C address |
| 14:10:14 | [IDC]Dragon | it interfaces the tuner to a hardware |
| 14:10:14 | Zagor | well we don't want a new file for the iriver if we can avoid it, do we? |
| 14:10:49 | Zagor | the address can easily be a define, as can the port pins |
| 14:11:08 | [IDC]Dragon | you at least have to adjust the port banging |
| 14:11:38 | [IDC]Dragon | ok, then just fmradio_tea5767 |
| 14:11:49 | Zagor | why not i2c? |
| 14:12:09 | [IDC]Dragon | because it's for this tuner |
| 14:12:15 | Zagor | it's just transfer code, isn't it? |
| 14:12:32 | [IDC]Dragon | a fixed 5 bytes to the fixed tuner address |
| 14:13:00 | Zagor | <Zagor> the address can easily be a define |
| 14:13:19 | [IDC]Dragon | and the 5 bytes too? |
| 14:14:02 | Zagor | if we need to change it, we will. we'll solve that when we get to it. |
| 14:14:16 | [IDC]Dragon | ok |
| 14:14:52 | [IDC]Dragon | my local name still is fmradio_i2c.c, i was just evaluating this |
| 14:22:46 | [IDC]Dragon | I gotta go |
| 14:22:56 | | Quit [IDC]Dragon ("CGI:IRC") |
| 14:28:48 | | Join edooo [0] (~edooo_188@82.129.244.5) |
| 14:29:01 | | Quit edooo (Remote closed the connection) |
| 14:57:21 | *** | Saving seen data "./dancer.seen" |
| 15:00 |
| 15:09:19 | | Join elinenbe [0] (~elinenbe_@65.115.46.225) |
| 15:11:46 | amiconn | LinusN, Zagor: Got my remark about dac.h? |
| 15:13:33 | Zagor | yes. i agree if we use it in apps |
| 15:14:04 | LinusN | how do we solve it in a backwards-friendly way? |
| 15:14:25 | LinusN | maybe it doesn't matter |
| 15:14:26 | elinenbe | LinusN: nice work on the iriver... good luck with everything else. |
| 15:14:40 | LinusN | exports is in the include path anyway |
| 15:14:43 | LinusN | elinenbe: thanks |
| 15:15:55 | amiconn | Zagor: dac.h is the only .h file in firmware/drivers , that's what I'm wondering about |
| 15:16:42 | elinenbe | LinusN: what is the speed of the iriver CPU? |
| 15:16:59 | LinusN | we can control it via software |
| 15:17:21 | LinusN | up to roughly 120MHz i think |
| 15:17:35 | LinusN | but we'll probably settle around 70 for mp3 playback |
| 15:17:36 | elinenbe | LinusN: so it could be possible to achieve gameboy quality games on it then... |
| 15:17:43 | LinusN | :-) |
| 15:17:45 | Zagor | amiconn: the way I see it, if dac is only used by other drivers and not from apps code, it should stay there and not be exposed |
| 15:18:00 | elinenbe | it has the resolution and the grayscale, the speed and the sound. |
| 15:18:17 | LinusN | and the joystick :-) |
| 15:18:28 | LinusN | but only 4-way |
| 15:18:48 | elinenbe | can anyone say gameboy emulator? |
| 15:18:49 | elinenbe | ;) |
| 15:19:00 | LinusN | would be ninja-c00l |
| 15:19:35 | elinenbe | it would b3 phr4k1ng c00l |
| 15:27:19 | amiconn | Zagor: Ah ok. Didn't check yet whether it is used outside firmware/drivers |
| 15:31:08 | amiconn | Zagor: It is not used from apps but from firmware (mpeg.c and mp3_playback.c) |
| 15:32:01 | | Quit Headie (Read error: 104 (Connection reset by peer)) |
| 15:46:41 | | Part Zagor |
| 15:47:14 | | Part LinusN |
| 16:00 |
| 16:02:24 | | Quit elinenbe (" HydraIRC -> http://www.hydrairc.com <- IRC has never been so cool") |
| 16:05:44 | | Quit midk (Read error: 104 (Connection reset by peer)) |
| 16:26:52 | | Quit ashridah ("gone") |
| 16:27:29 | | Join methangas [0] (methangas@0x50c61d20.virnxx10.adsl-dhcp.tele.dk) |
| 16:37:28 | | Join MoGl53 [0] (mogle3@213.177.236.210.adsl.griffin.net.uk) |
| 16:55:39 | | Quit MoGle3 (Read error: 113 (No route to host)) |
| 16:57:03 | | Join MoGle3 [0] (mogle3@213.177.236.210.adsl.griffin.net.uk) |
| 16:57:22 | *** | Saving seen data "./dancer.seen" |
| 17:00 |
| 17:01:56 | | Join uski [0] (~uski@lns-th2-5f-81-56-234-40.adsl.proxad.net) |
| 17:13:52 | | Quit MoGl53 (Read error: 113 (No route to host)) |
| 17:16:25 | | Join mecraw__ [0] (~lmarlow@69.2.235.2) |
| 17:20:26 | | Quit MoGle3 (Read error: 113 (No route to host)) |
| 18:00 |
| 18:04:49 | einhirn | A little question: Now that we have MMC- and Fat16-Support due to the Ondio port, would it be possible to incoorporate an MMC-Card into the Jukebox recorder as "Battery extension"? I am just picking up an Idea that went through the Mailing list sometime 2002... |
| 18:05:21 | uski | _battery_ extension ? what do you mean ? |
| 18:06:03 | einhirn | Well, copy files from the Harddisk to the MMC card and play them from there. Long time no spin. Longer Battery time... |
| 18:07:41 | uski | oh ok |
| 18:07:56 | uski | i don't know how the MMC is connected to the CPU |
| 18:08:14 | uski | i know that in the recorders there is not a lot of spare I/O pins |
| 18:08:29 | uski | sth possible would be to connect the MMC on the same port than the LCD... adding a CS line |
| 18:10:09 | einhirn | Hmm... something like that... But isn't the LCD-Bus too busy? I am speaking about lets say 64MB or so, copied while playing? I think the management would be a pain... |
| 18:11:07 | uski | nope |
| 18:11:18 | uski | 128kbps mp3 = only 16kbytes/sec |
| 18:11:26 | uski | but that's the theory... |
| 18:11:36 | uski | the lcdbus is extremely busy only while doing grayscale |
| 18:11:51 | amiconn | MMC is serial, so if you do bit-banging, that's a lot of work... |
| 18:12:02 | uski | right |
| 18:12:20 | amiconn | In the Ondio, the MMC is hooked up on the serial port #1, so the remote control support would have to go for sure. |
| 18:12:26 | uski | maybe i would be possible to add some small circuitry along with the MMC connector.. |
| 18:12:41 | einhirn | The guy on the Mailing list thought about using Compact flash since it comes with ATA-like interface. And then attaching it as slave to the Harddisk bus... |
| 18:12:54 | uski | but it would be a pain to do |
| 18:13:00 | uski | yes |
| 18:13:47 | einhirn | I would even think about leaving out the mmc-connector... ;) I'd just solder thin wires to the card and stuff it inside the box... |
| 18:14:03 | amiconn | Then the i2c clock has to be re-routed, since PB13 is needed for the serial clock |
| 18:14:05 | uski | ah yea |
| 18:14:35 | amiconn | Plus, we would have to find another free port pin to hook up the chip select |
| 18:14:35 | uski | i think that if you want a long autonomy simply replace the HDD with a CompactFlash card. |
| 18:15:19 | einhirn | Yep... Thought about that too, but I'd have to cut back with the Data storage... |
| 18:16:01 | einhirn | OTOH, Seems like it would as hard to do as the 8mb-mod, if not harder... |
| 18:16:13 | amiconn | I think the 8 MB mod clearly shows that extending the memory doesn't yield that much of additional runtime, since the hd is not the only power-sucker. With 8 MB you have a >4 times as large buffer, but the runtime increases by a mere ~22 % |
| 18:16:37 | einhirn | ok... |
| 18:17:30 | einhirn | Well, my box has still some saving potential: I can replace the original HDD with a power saving modern one... |
| 18:18:26 | einhirn | It's just the tickling in the fingers, wanting to mod something on the Box, even if it doesn't make sense ;) |
| 18:18:50 | amiconn | I have put in an 80 GB disk, and I have white backlight... |
| 18:18:53 | | Join _aLF [0] (~Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net) |
| 18:18:55 | einhirn | ;) |
| 18:19:00 | _aLF | hi |
| 18:57:26 | *** | Saving seen data "./dancer.seen" |
| 20:00 |
| 20:11:44 | | Join Domonoky [0] (~trillian@pD9E41C4E.dip.t-dialin.net) |
| 20:37:30 | | Quit AciD (Connection reset by peer) |
| 20:38:00 | | Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 20:43:06 | | Quit _aLF (Read error: 54 (Connection reset by peer)) |
| 20:43:40 | | Part Domonoky |
| 20:57:28 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:47:10 | | Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
| 21:52:56 | | Quit einhirn (Read error: 54 (Connection reset by peer)) |
| 22:00 |
| 22:09:50 | scott666_ | has anyone heard of this? |
| 22:09:50 | scott666_ | http://www.jetaudio.com/products/iaudio/m3/index.html |
| 22:09:54 | | Nick scott666_ is now known as scott666 (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
| 22:21:13 | | Join einhirn [0] (~Miranda@carlsberg.heim2.tu-clausthal.de) |
| 22:29:33 | | Join [IDC]Dragon [0] (~idc-drago@pD9FF8743.dip.t-dialin.net) |
| 22:29:43 | amiconn | Hi again Jörg |
| 22:30:04 | [IDC]Dragon | hi again |
| 22:30:35 | amiconn | I just committed logarithmic scroll speed setting |
| 22:31:13 | [IDC]Dragon | I never felt a need to adjust that... |
| 22:31:41 | amiconn | This was an old idea of mine, and not hard to implement |
| 22:32:24 | amiconn | Code size should be somewhat smaller again on Ondio (because of my powermgmt changes) - maybe rombox fits for you again |
| 22:32:40 | [IDC]Dragon | it already does |
| 22:33:03 | [IDC]Dragon | but I'm about to burst is againwith the 2nd tuner |
| 22:33:11 | [IDC]Dragon | s/is/it |
| 22:34:08 | amiconn | I still wonder how we should implement the 2-disk handling, without breaking the function api... |
| 22:34:41 | [IDC]Dragon | which api? |
| 22:35:24 | amiconn | Erm, the lower layers of the firmware (fat driver, ata driver). The functions therein would need an additional parameter |
| 22:36:03 | [IDC]Dragon | yes, that's a bigger change |
| 22:36:28 | [IDC]Dragon | dunno if and how it could be hidden from the other models |
| 22:37:23 | amiconn | Yes, but that's my point here. |
| 22:38:08 | amiconn | The hot-unplug dismount is much easier, but of no use without the 2-disk handling |
| 22:39:37 | amiconn | I did additional power measurements with ram-based rockbox and added the results to the wiki table |
| 22:40:06 | [IDC]Dragon | you'd either #ifdef the prototypes, too, or accept a useless parameter for the other models |
| 22:41:28 | * | [IDC]Dragon reads wiki |
| 22:41:32 | amiconn | Yup. However, #ifdef'ing the prototypes will add a whole lot of #ifdefs. Or I'd have to duplicate almost all code |
| 22:42:25 | [IDC]Dragon | almost the same power figures, maybe a bit less for ROM |
| 22:43:09 | amiconn | ? The figures are a bit less when running from RAM, except for card access. This sucks a bit more, but for a shorter time |
| 22:43:10 | [IDC]Dragon | but interesting to know |
| 22:49:12 | | Join [av]bani [0] (~goemon@washuu.anime.net) |
| 22:49:33 | | Part [av]bani |
| 22:53:09 | amiconn | [IDC]Dragon: I had an idea for making the flash plugins a bit more safe. They should only allow to flash if the battery level is safe. Imagine Ondio batteries running out of power while flashing... |
| 22:57:32 | *** | Saving seen data "./dancer.seen" |
| 23:00 |
| 23:01:19 | [IDC]Dragon | yes, I could check that |
| 23:01:49 | amiconn | There is already a function for that, it only needs to be exported to the plugin api |
| 23:03:22 | amiconn | Ondio end-of-battery usually occurs suddenly. |
| 23:54:40 | | Join [av]bani [0] (~goemon@washuu.anime.net) |
| 23:54:45 | | Part [av]bani |
icon identifies that the person is a core developer (has commit access).