| 00:00:01 | pillo | see you tomorrow! |
| 00:00:16 | preglow | yep |
| 00:00:17 | | Quit amiconn (Nick collision from services.) |
| 00:00:18 | | Nick amiconn_ is now known as amiconn (~jens@pD9E7F903.dip.t-dialin.net) |
| 00:00:41 | | Quit CoCoLUS () |
| 00:00:57 | preglow | a bloody optimization guide would have been great |
| 00:01:03 | preglow | but doesn't seem like motorola has one |
| 00:06:36 | | Join Renko [0] (~Renko@host81-154-33-157.range81-154.btcentralplus.com) |
| 00:07:13 | | Quit Stryke` ("Friends don't let friends listen to Anti-Flag") |
| 00:07:38 | preglow | how the hell motorola has managed to get an mp3 decoder running in 19mhz is beyond me :V |
| 00:07:50 | HCl | :P |
| 00:08:05 | rasher | I assume they know the processor pretty well :) |
| 00:08:11 | preglow | no shit |
| 00:08:38 | linuxstb | Would there be other bottlenecks on the iRiver? Maybe the memory? |
| 00:08:51 | preglow | wouldn't know |
| 00:09:03 | Patr3ck | how could profiling be added to the codecs? |
| 00:09:11 | preglow | Patr3ck: with difficulty |
| 00:09:28 | preglow | especially if you mean with gprof and those tool |
| 00:09:28 | preglow | s |
| 00:09:33 | Patr3ck | no |
| 00:09:52 | Patr3ck | add tick counts to the codec functions? |
| 00:09:58 | | Quit pillo ("CGI:IRC (EOF)") |
| 00:10:14 | preglow | it would have to be something like that, yes |
| 00:10:24 | preglow | but we'll need something lower resolution than ticks |
| 00:10:46 | Patr3ck | why? |
| 00:11:21 | preglow | well, 10ms is pretty much, and if the function executes quickly, it'll seem like it's using more time than it is |
| 00:11:51 | Patr3ck | I see, is a higher resolution possible with existing stuff in rockbox |
| 00:11:55 | preglow | don't know |
| 00:11:59 | preglow | should be |
| 00:12:04 | Patr3ck | ok |
| 00:12:21 | Patr3ck | besides the resolution, how would it be added |
| 00:13:07 | Patr3ck | the information must be added to a central information store from all over the codec |
| 00:13:08 | preglow | by simply just adding timing to the functions and storing results in a global array, i guess |
| 00:13:14 | preglow | i haven't done manual profiling before |
| 00:13:40 | Patr3ck | all the codecs would benefit from some simple common functions I guess |
| 00:14:51 | Patr3ck | just wondering were these functions should be placed... |
| 00:24:50 | | Join ashridah_ [0] (ashridah@220-253-120-66.VIC.netspace.net.au) |
| 00:25:04 | | Quit ashridah (Nick collision from services.) |
| 00:25:08 | | Nick ashridah_ is now known as ashridah (ashridah@220-253-120-66.VIC.netspace.net.au) |
| 00:26:01 | preglow | hmm |
| 00:26:13 | preglow | perhaps codecs should be placed in sram |
| 00:26:35 | preglow | that would put a size restriction on them, for sure |
| 00:27:04 | Bagder | should make an interesting test if nothing else |
| 00:27:37 | | Join condor9 [0] (jch@xmission.xmission.com) |
| 00:27:42 | preglow | i really think it does matter quite a lot |
| 00:27:48 | preglow | there are tons of memory accesses |
| 00:27:50 | | Quit muesli- (Read error: 110 (Connection timed out)) |
| 00:28:20 | condor9 | I recently switched from 2.2 to 2.4 and now my config.cfg won't automatically load. Is this a feature? |
| 00:28:25 | * | amiconn notices an active bagder |
| 00:28:44 | Bagder | alive at least ;-) |
| 00:28:49 | amiconn | :) |
| 00:29:15 | amiconn | Did you read about my idea about a clean fix for the sim compilation problems in the logs? |
| 00:29:38 | Bagder | no |
| 00:29:57 | Bagder | about what time/date? |
| 00:32:10 | amiconn | look at http://www.rockbox.org/irc/rockbox-20050220.txt starting around 00:30 |
| 00:33:23 | condor9 | How do you get the config file to load on startup? |
| 00:34:37 | preglow | what do you think would be faster, preload 8 coefs into d0-d7, then do eight consecutive mac operations, or do eight interleaved mac and load operations? |
| 00:34:44 | amiconn | condor9: .cfg files are never loaded automatically. |
| 00:35:25 | amiconn | condor9: The auto-loaded rockbox configuration is partly stored in the realtime clock (recorder models only), and partly in an unused sector on the harddisk |
| 00:35:44 | condor9 | Hmmm... but 2.2 used to correct? |
| 00:35:59 | condor9 | Seems odd that I have to load a config everytime. |
| 00:36:24 | amiconn | This configuration is invalidated when the configuration routines need to be changed, so with the 2.2->2.4 transistion, they are set back to the defaults |
| 00:36:47 | condor9 | Yuck. :( Thanks amiconn. |
| 00:36:51 | amiconn | If you saved the config to a .cfg file before, you should be able to load that with the new version |
| 00:37:16 | condor9 | Yeah I can load it, I just hate having to manually load it everytime. |
| 00:37:21 | amiconn | Once loaded, and the unit shut down properly, the settings should be autoloaded again |
| 00:37:50 | Bagder | amiconn: I'm not sure things are that easy, but I generally agree that POSIX things that Rockbox does, but that are simulated, should be ifdef'ed/moved out so that they are not done for simulators |
| 00:38:19 | amiconn | The ifdefing is problematic, as we have seen |
| 00:38:23 | condor9 | amiconn: Oh. Well, they aren't for me. I have a recorder (V1) with 2.4 built from source. |
| 00:39:11 | amiconn | condor9: How do you shut down the box after loading your settings? |
| 00:39:34 | Bagder | amiconn: yes it is, but what's the fix? renaming include files to not use posix names? I don't like that |
| 00:39:57 | amiconn | Bagder: No, I think my suggestion should work: |
| 00:40:31 | amiconn | - put all rockbox includes that are called the same as system includes and define posix functions into a separate include dir. |
| 00:40:42 | condor9 | amiconn: I hit the off button, it prompts to off again so I hit off. I also check to make sure there is some disk activity after saving my settings. |
| 00:41:07 | amiconn | Bagder: This requires additional functions which are not posix moving to other includes |
| 00:41:14 | Bagder | amiconn: but I like the sim to use the Rockbox-provided string and memory functions for example, not the compiler's or system's native ones |
| 00:41:37 | Bagder | I could of course live without them if forced ... :-) |
| 00:42:04 | amiconn | Then consider these functions as non-posix.... |
| 00:42:35 | amiconn | The dir with the posix includes should then be in the include path for target compiles, but not for sim compiles |
| 00:42:46 | Bagder | if that works, I'm all for it |
| 00:43:02 | Bagder | I doubt it will be that simple |
| 00:43:36 | amiconn | If you want to have certain functions always provided by rockbox, then this is of course also necessary for the sources under uisimulator/ |
| 00:43:49 | amiconn | Otherwise we'll get the same clashing again |
| 00:44:22 | amiconn | And of course, functions with the same name as a posix function, but with different semantics should be renamed |
| 00:44:40 | amiconn | The obvious example is sleep() |
| 00:44:51 | Bagder | sleep should be renamed indeed |
| 00:45:04 | Bagder | but opendir() is a nasty example |
| 00:45:12 | amiconn | Why? |
| 00:45:24 | amiconn | (I'm not a posix expert....) |
| 00:45:40 | Bagder | because rockbox uses and assume a proto by its own, and the simulator must "hijack" it to add a layer between rockbox and the OS |
| 00:45:50 | Bagder | hm |
| 00:45:54 | Bagder | no perhaps thats not a problem |
| 00:46:03 | Bagder | since it uses posix |
| 00:46:25 | amiconn | Maybe it is :( |
| 00:46:44 | | Quit condor9 ("Leaving") |
| 00:46:44 | amiconn | The file system emulation in a sub-dir, I forgot... |
| 00:47:01 | | Part hubble |
| 00:47:34 | preglow | chroot :) |
| 00:48:38 | amiconn | There is no chroot() in windows... (thinking win32 sim, it should work in cygwin for the x11 sim) |
| 00:49:19 | preglow | ahh, you support msvc as well, yes |
| 00:49:23 | preglow | forgot about that |
| 00:49:39 | amiconn | Not msvc, but building native win32 sim with cygwin gcc |
| 00:49:56 | preglow | well, yes, that as well |
| 00:50:04 | amiconn | The msvc support was there, but is surely broken by the new build system |
| 00:53:45 | | Quit Renko ("Leaving") |
| 00:57:36 | amiconn | Bagder: Where are those sim_* functions defined? |
| 00:57:54 | Bagder | in common/io.c |
| 00:58:20 | *** | Saving seen data "./dancer.seen" |
| 00:59:41 | amiconn | So what do you think about the following approach (it's actually similar to how things currently work iiuc): |
| 01:00 |
| 01:01:16 | amiconn | In each rockbox include that defines posix functions, set the appropriate sim_* define, selected by #ifdef SIMULATOR. |
| 01:01:28 | amiconn | All code in apps/ and firmware/ should then always use these includes |
| 01:01:29 | | Quit midk (Read error: 54 (Connection reset by peer)) |
| 01:02:11 | amiconn | The code in uisimulator/ however should then never use these includes, but the system ones. |
| 01:02:24 | amiconn | Then it should actually implement the sim_ |
| 01:02:35 | amiconn | * equivalents by using the system functions |
| 01:02:37 | Bagder | that sounds reasonable |
| 01:03:21 | Bagder | but then we'd need a dir with include files that aren't used for the sim |
| 01:03:30 | amiconn | yup |
| 01:03:38 | | Join Shity [0] (Shity@modemcable147.112-70-69.mc.videotron.ca) |
| 01:03:49 | Shity | anyone here ? |
| 01:03:52 | preglow | 6yes |
| 01:03:59 | Shity | stupid question |
| 01:04:00 | Bagder | we could actually just define for example "firmware/include/" to be that dir, and the "clean it up" to work as you described |
| 01:04:00 | Shity | but |
| 01:04:04 | Shity | are you italian |
| 01:04:08 | preglow | hell no |
| 01:04:20 | Shity | where can i find a channel with italians |
| 01:04:22 | Shity | i need some help |
| 01:04:24 | Bagder | c'mon preglow, admit it :-) |
| 01:04:25 | preglow | don't ask me |
| 01:04:33 | Shity | bagder are you ? |
| 01:04:33 | preglow | why do you need italians? |
| 01:04:39 | preglow | aren't us norwegians good enough? |
| 01:05:07 | Shity | i got a gay assignement to do and i just got couple of easy questions |
| 01:05:12 | preglow | Bagder: i would have to be excessively drunk |
| 01:05:15 | Shity | and i need an italian to asnwer them |
| 01:05:20 | jyp | Rofl |
| 01:05:21 | preglow | then go somewhere else |
| 01:05:35 | jyp | /kick Shity |
| 01:05:38 | Shity | yeah thanks for your help .. faggot |
| 01:05:40 | | Part Shity |
| 01:05:45 | jyp | bingo |
| 01:05:46 | preglow | ahh, trolls... |
| 01:06:24 | HCl | it gets boring, really |
| 01:06:36 | amiconn | Bagder: Using firmware/include for that actually sounds reasonable. Iirc these are mostly posix functions anyway. |
| 01:06:39 | rasher | Haha |
| 01:06:47 | rasher | That was... different. |
| 01:06:56 | rasher | It's not like this is a particularly large channel is it? |
| 01:07:01 | Bagder | amiconn: yes, that's why I think it would be a good dir to define to be this "target-only" dir |
| 01:07:16 | preglow | rasher: there are more than enough complete fools to go around |
| 01:07:22 | preglow | rasher: even in the smallest of channels |
| 01:07:24 | rasher | preglow: good point |
| 01:08:43 | amiconn | Bagder: This would work rather nicely, if I didn't overlook something: |
| 01:09:38 | amiconn | #ifdef SIMULATOR |
| 01:09:56 | amiconn | #define open(blah) sim_open(blah) |
| 01:09:58 | amiconn | #else |
| 01:10:13 | amiconn | int open(char *blah); |
| 01:10:18 | amiconn | #endif |
| 01:10:36 | Bagder | not even #else, since it needs the proto for sim_open() |
| 01:11:14 | amiconn | Ah, yes, this has to go before the #else then |
| 01:11:42 | amiconn | The proto after #else is of course necessary for building the target |
| 01:12:15 | Bagder | yes, open() is needed for target and sim_open() for sim |
| 01:12:23 | Bagder | so: |
| 01:12:26 | Bagder | ifdef SIM |
| 01:12:37 | Bagder | #define open() sim_open() |
| 01:12:41 | Bagder | #endif |
| 01:12:46 | Bagder | int open(char *bbbbb); |
| 01:13:11 | Bagder | hm |
| 01:13:15 | amiconn | ...and exactly this would not work, imho |
| 01:13:18 | Bagder | no |
| 01:13:26 | amiconn | #ifdef SIMULATOR |
| 01:13:29 | Bagder | and isn't this file in the target-only include dir anyway? |
| 01:13:51 | Bagder | the one with the open() proto I mean |
| 01:14:10 | preglow | bed, later all |
| 01:14:19 | | Quit preglow ("fugleskremsel") |
| 01:14:32 | amiconn | No, it is an include that is used by the main rockbox dirs only, but also for building the sim. |
| 01:15:01 | amiconn | I.e. files under apps/ and firmware/ should always use it, but files in uisimulator/ must never use it |
| 01:15:22 | Bagder | ah, right. I'm following |
| 01:15:52 | amiconn | So the main rockbox code will compile normally with open() etc. for target, but with the sim_ equivalents when building a sim |
| 01:16:01 | | Quit thegeek (Read error: 104 (Connection reset by peer)) |
| 01:16:10 | | Join G [0] (na@ti521110a080-0418.bb.online.no) |
| 01:16:32 | Bagder | right, but the file that provides an open() prototype, shouldn't it provide a sim_open() prototype when built for the sim? |
| 01:16:37 | amiconn | The files in uisimulator/ then have to implement all those sim_ equivalents, and must not use the mentioned includes, but rather the system includes |
| 01:16:56 | amiconn | Yes, that was my addittion after your comment. |
| 01:16:58 | amiconn | So: |
| 01:17:05 | amiconn | #ifdef SIMULATOR |
| 01:17:15 | Bagder | yes, we must differ between files that needs simulation and files that implement simulation |
| 01:17:16 | amiconn | #define open() sim_open() |
| 01:17:26 | amiconn | int sim_open(char *bbbbb); |
| 01:17:30 | amiconn | #else |
| 01:17:32 | amiconn | int open(char *bbbbb); |
| 01:17:34 | amiconn | #endif |
| 01:17:57 | Bagder | I don't see the diff between this and my version, but it doesn't matter much |
| 01:18:22 | Bagder | ah, possibly because the protos differ of course |
| 01:18:29 | amiconn | yup |
| 01:18:44 | Bagder | but that might cause compiler warnings |
| 01:18:55 | amiconn | Why? |
| 01:19:24 | amiconn | The prototype has to be exactly identical except for the name |
| 01:19:38 | Bagder | right |
| 01:19:53 | Bagder | but then you don't need two versions, since the define will work for the proto as well |
| 01:20:06 | Bagder | never mind, its not important for this discussion |
| 01:20:19 | amiconn | Ah, yes, you're right |
| 01:20:37 | amiconn | That looks even cleaner... |
| 01:21:41 | amiconn | The difference between the rockbox prototype and the system prototype (and possible change in behaviour, as for the file system simulation) are then handled by the sim_ function implementation in uisimulator/ |
| 01:21:57 | Bagder | yes |
| 01:22:36 | amiconn | Of course this means to have a sim_ implementation for every posix function, even those which don't need data munging, but the overhead introduced by that shouldn't matter |
| 01:22:36 | Bagder | checking now, the uisimulator/ files already seem to be built without using the include dir |
| 01:23:18 | Bagder | amiconn: no, I think it would make the sim clean and understandable even if there's a tiny overhead |
| 01:23:38 | amiconn | The posix functions that we want to always use the rockbox implementation will simply not get a sim_ define |
| 01:25:02 | amiconn | We wouldn't even need to rename sleep(), but I think it should be done because it is not exactly posix... |
| 01:25:29 | amiconn | I don't have an idea what it should be called though... |
| 01:25:45 | Bagder | hehe, me neither |
| 01:28:21 | Bagder | so basically, if we move the sim_* logic into the include/* headers, we should start getting it working right |
| 01:29:00 | Bagder | of course, there are some non-posix functions we want sim_* versions of too |
| 01:29:02 | amiconn | Yes, I think so too. |
| 01:29:06 | XShocK | is WAV codec done? |
| 01:29:23 | Bagder | ...most notable is lcd_update() |
| 01:29:31 | amiconn | Ah, yes. |
| 01:29:46 | amiconn | Well, these could use the same mechanism |
| 01:30:01 | linuxstb | XShocK: No. |
| 01:30:10 | | Join AC [0] (~5078751e@labb.contactor.se) |
| 01:30:19 | linuxstb | XShock: Are you ready for it? |
| 01:30:35 | amiconn | This sounds like a clear separation of rockbox code (which needs simulated functions) and simulator code (which provides them) |
| 01:30:48 | Bagder | exactly |
| 01:31:14 | XShocK | linuxstb: I think yes. |
| 01:31:45 | | Quit mrmags ("Download Gaim: http://gaim.sourceforge.net/") |
| 01:31:47 | amiconn | The way it provides them does not matter. Either it uses the system functions without changes, the system functions with some mangling (file, dir), or something completely different (lcd) |
| 01:32:28 | linuxstb | XShock: Does that mean you've made progress with sound? |
| 01:33:33 | XShocK | yes, me and hubble |
| 01:33:45 | XShocK | sounds very good actually. |
| 01:33:49 | Bagder | amiconn: I get a feeling this is the correct way forward |
| 01:34:01 | amiconn | I have to agree. |
| 01:34:30 | amiconn | How do you think we should tackle this? Specifically, could we share the work somehow? |
| 01:35:44 | Bagder | lemme dig into it tomorrow and see how much I can fix "at once", and then we'll talk more tomorrow |
| 01:36:18 | linuxstb | XShock: Congratulations to you and hubble. Can you give us any more information? How does it work? |
| 01:36:37 | Bagder | I'm going away on wednesday for a week, so I just have line one and a half day before that |
| 01:36:43 | Bagder | like |
| 01:36:55 | XShocK | currently it works on AUDIOTICK interrupt |
| 01:37:42 | XShocK | does not use DMA, since i couldn't figure out how to control its speed. |
| 01:38:04 | XShocK | with AUDIOTICK 44.1 16-bit works and souns well. |
| 01:38:21 | XShocK | *sounds |
| 01:39:04 | XShocK | i feed several samples into PDOR3 on each AUDIOTICK |
| 01:39:18 | amiconn | Bagder: okay. |
| 01:40:22 | jyp | sounds familiar, good ;) |
| 01:43:48 | jyp | bedtime |
| 01:43:50 | | Quit jyp ("poof!") |
| 01:43:50 | | Quit AC ("CGI:IRC (EOF)") |
| 01:44:57 | linuxstb | XShocK: What's next? Are you going to go back and try again with DMA? |
| 01:45:27 | | Quit DMJC (Read error: 110 (Connection timed out)) |
| 01:46:39 | XShocK | I will try it, yes |
| 01:47:17 | XShocK | I would really like it to be DMA |
| 01:47:27 | linuxstb | So all we need to do now is design and code an audio playback system and get the codecs running in real-time... |
| 01:47:40 | XShocK | yep. :) |
| 01:48:02 | linuxstb | That assumes Linus can get the iRiver running reliably at 140MHz and solve the ATA problem... |
| 01:48:08 | amiconn | linuxstb: It seems to me that the realtime codecs part is the bigger task... |
| 01:48:46 | linuxstb | Yep. |
| 01:49:07 | XShocK | did anyone try to do that m68k optimized MPEG decoder? |
| 01:49:12 | amiconn | I hope someone will have a look at the asm optimised mp3 decoder |
| 01:49:17 | amiconn | XShocK: :) |
| 01:49:30 | XShocK | :) |
| 01:50:11 | amiconn | I have the comparison on Amiga (m68k): The decoder by Stephane Tavenard is twice as fast as an optimised libmad... |
| 01:50:15 | linuxstb | I've had a quick look, but haven't had a chance to try to get it running on Rockbox yet. It may need some attention from someone who know m68k asm to get that part compiling with a modern gcc. |
| 01:50:32 | linuxstb | amiconn: That's promising. |
| 01:51:21 | amiconn | However, I wonder why libmad is that slow on a 140 MHz coldfire. It can do realtime on an 68060/50 (which runs at 100 MHz internally) |
| 01:51:54 | amiconn | Ah, I forgot something. The 68060 is superscalar (2 execution units) |
| 01:54:17 | XShocK | so as i understand that asm decoder is curently not compilable? |
| 01:54:50 | linuxstb | I read in the README that the ASM had not been translated to gcc syntax. But I have no idea what syntax it currently is in. |
| 01:54:54 | XShocK | *compileable | compilable? which one is correct? |
| 01:55:09 | linuxstb | "can not be compiled" |
| 01:55:47 | linuxstb | (if you can't spell a word, use a different one) |
| 01:57:32 | XShocK | but "compilable" is cooler. :) |
| 01:58:11 | linuxstb | :-). But I think the answer is no anyway. |
| 01:59:00 | linuxstb | But it shouldn't take too much work - I may give it a try tomorrow evening. |
| 01:59:25 | XShocK | I usually mess up rules of russian language with english. |
| 02:00 |
| 02:00:57 | | Join ghode|afk [0] (dude@host217-137-4-48.no-dns-yet.ntli.net) |
| 02:09:11 | | Quit ghode|afk () |
| 02:18:58 | | Quit edx (Read error: 60 (Operation timed out)) |
| 02:21:39 | | Join skav [0] (skav@67-138-74-184.dsl1.merch.roc.ny.frontiernet.net) |
| 02:30:48 | | Join DMJC [0] (~James@220-245-162-47-sa-nt.tpgi.com.au) |
| 02:34:18 | amiconn | Going to sleep now... night all |
| 02:34:56 | rasher | night |
| 02:34:59 | | Part amiconn |
| 02:36:27 | | Quit Patr3ck () |
| 02:58:23 | *** | Saving seen data "./dancer.seen" |
| 02:59:47 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 03:00 |
| 03:12:21 | | Quit XShocK (" HydraIRC -> http://www.hydrairc.com <-") |
| 03:24:24 | | Join midk_ [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 03:24:24 | | Quit midk_ (Client Quit) |
| 03:32:33 | | Join wacky_ [0] (~wacky@modemcable040.196-203-24.mc.videotron.ca) |
| 03:32:43 | wacky_ | hey boys and girls :) |
| 03:35:41 | | Join XShocK [0] (~XShocK@pcp09492659pcs.nrockv01.md.comcast.net) |
| 04:00 |
| 04:04:04 | | Quit wacky_ ("awright") |
| 04:05:54 | | Join QT [0] (as@area51.users.madwifi) |
| 04:09:21 | | Join edx [0] (edx@pD9EABF68.dip.t-dialin.net) |
| 04:17:44 | | Quit QT_ (Read error: 110 (Connection timed out)) |
| 04:35:15 | | Quit skav () |
| 04:35:31 | | Quit cYmen ("leaving") |
| 04:58:27 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:05:16 | | Join rwilco [0] (~douglas@moreen133.micro-mania.net) |
| 05:24:48 | | Part rwilco ("Leaving") |
| 05:25:17 | | Quit linuxstb (Read error: 110 (Connection timed out)) |
| 05:30:36 | | Quit XShocK (" HydraIRC -> http://www.hydrairc.com <- IRC with a difference") |
| 06:00 |
| 06:11:10 | | Join XShocK [0] (~XShocK@pcp09492659pcs.nrockv01.md.comcast.net) |
| 06:12:25 | XShocK | Hehe... cool. Rockbox plays WAV files. :) |
| 06:12:52 | rasher | Yay :D |
| 06:13:01 | rasher | That's damn cool indeed |
| 06:13:10 | rasher | dma? |
| 06:13:26 | XShocK | no |
| 06:14:03 | XShocK | I can't really understand how to make DMA work here.... |
| 06:14:19 | XShocK | I don't know methods to slow DMA down. |
| 06:14:21 | XShocK | or pause |
| 06:15:31 | XShocK | But for most purposes probably current implementation will work wel |
| 06:15:36 | XShocK | *well |
| 06:18:05 | rasher | Sounds good |
| 06:18:26 | rasher | Well this is certainly good news :) |
| 06:20:25 | XShocK | and now codecs.... i predict is the worst problem. :) |
| 06:22:33 | | Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) |
| 06:28:01 | XShocK | night all |
| 06:29:03 | | Quit XShocK (" HydraIRC -> http://www.hydrairc.com <- Go on, try it!") |
| 06:29:08 | rasher | night |
| 06:29:13 | rasher | well the codec api |
| 06:29:23 | rasher | hard to tune the codecs without knowing the speed |
| 06:29:25 | | Quit Lurkski ("Download Gaim: http://gaim.sourceforge.net/") |
| 06:29:40 | rasher | well, hard to know what you're aiming for, that is |
| 06:31:11 | | Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) |
| 06:32:48 | | Join Muntek [0] (~Muntek@adsl-68-90-41-29.dsl.hstntx.swbell.net) |
| 06:33:37 | | Part Muntek |
| 06:36:49 | | Join webguest39 [0] (~45568afc@labb.contactor.se) |
| 06:37:16 | | Quit webguest39 (Client Quit) |
| 06:50:39 | | Part Lurkski |
| 06:50:49 | | Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) |
| 06:57:35 | | Part Lurkski |
| 06:57:49 | | Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) |
| 06:58:31 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:24:54 | | Quit midk ("Leaving") |
| 08:00 |
| 08:08:46 | | Nick ashridah is now known as Lost-ash (ashridah@220-253-120-66.VIC.netspace.net.au) |
| 08:14:20 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 08:27:14 | Lost-ash | LinusN |
| 08:27:22 | | Nick Lost-ash is now known as ashridah (ashridah@220-253-120-66.VIC.netspace.net.au) |
| 08:27:23 | LinusN | hi |
| 08:27:35 | ashridah | *sigh* |
| 08:27:40 | | Nick ashridah is now known as Lost-ash (ashridah@220-253-120-66.VIC.netspace.net.au) |
| 08:27:42 | Lost-ash | back to cooking :/ |
| 08:27:59 | * | LinusN has to reboot |
| 08:28:01 | | Part LinusN |
| 08:28:26 | Lost-ash | gah. would help if i remembered to put the food on the heat :/ |
| 08:36:37 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 08:42:19 | | Part Lynx_awy ("bye!") |
| 08:44:34 | | Quit Lurkski (Read error: 110 (Connection timed out)) |
| 08:50:34 | | Part LinusN |
| 08:52:12 | | Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) |
| 08:58:34 | *** | Saving seen data "./dancer.seen" |
| 09:00 |
| 09:31:42 | | Join bobTHC [0] (~foo@l03v-35-141.d1.club-internet.fr) |
| 09:31:53 | bobTHC | morning folks! |
| 09:34:34 | * | Zagor yawns |
| 09:37:52 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 09:38:34 | * | dwihno wants zzz's |
| 09:38:51 | * | LinusN wants $$$'s |
| 09:40:14 | | Quit Lurkski (Read error: 60 (Operation timed out)) |
| 09:40:20 | dwihno | LinusN: Det är 3 dagar, 14 timmmar, 19 minuter och 51 sekunder kvar tills man får lön för mödan (2005-02-25) |
| 09:40:29 | dwihno | Just hang in there... :) |
| 09:40:34 | LinusN | :-) |
| 09:43:51 | | Nick Lost-ash is now known as ashridah (ashridah@220-253-120-66.VIC.netspace.net.au) |
| 09:46:20 | | Join linuxstb [0] (~linuxstb@dsl-212-23-31-215.zen.co.uk) |
| 09:48:16 | LinusN | Zagor: how's the free and independent life nowadays? |
| 09:48:33 | Zagor | pretty relaxed :-) |
| 09:48:55 | LinusN | :-) |
| 09:48:58 | dwihno | free? independent? |
| 09:49:40 | Zagor | yeah, i sorta... quit working. |
| 09:51:07 | dwihno | you did? |
| 09:51:16 | dwihno | are you serious? |
| 09:51:59 | Zagor | yeah. i'm only working for myself now. |
| 09:52:41 | Zagor | still feels really weird. i expect it will take a few weeks to establish some kind of routine. |
| 09:53:24 | dwihno | oh.. I wish you the best of luck |
| 09:53:33 | Zagor | thanks |
| 09:53:55 | dwihno | You'll do consulting within the Haxx sphear? |
| 09:54:50 | Zagor | no, i'll just be working on my web site. |
| 09:55:36 | dwihno | does it produce any money? |
| 09:55:48 | dwihno | I assume you're talking about your bostadsbytar-website |
| 09:55:59 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 09:56:23 | Zagor | yeah. it brings in enough to live on. |
| 09:56:42 | dwihno | it does? cool! |
| 09:57:27 | dwihno | Any bigger plans? |
| 09:58:17 | Zagor | nothing major, just various improvements |
| 09:59:00 | dwihno | Are you going to do anything special with your new-found time? |
| 09:59:40 | LinusN | sleep, watch tv |
| 09:59:48 | DeadMan | get fat |
| 10:00 |
| 10:00:46 | Zagor | hehe |
| 10:02:23 | Zagor | i'm going to do more fun stuff, like rockbox and various other little projects i didn't have time for before |
| 10:03:31 | dwihno | And I thought you were going to get away from the computers and spend more time practicing banjo :) |
| 10:04:25 | | Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) |
| 10:04:43 | Zagor | :) |
| 10:05:04 | | Quit Domin ("Curse - Version 1.5.1") |
| 10:05:48 | dwihno | I'd like to work less as well |
| 10:05:56 | dwihno | Perhaps 75% |
| 10:10:06 | bobTHC | have u seen the last mailman security issues ?? |
| 10:10:27 | bobTHC | https://lists.netsys.com/pipermail/full-disclosure/2005-February/031595.html |
| 10:12:06 | Zagor | fixed in our version |
| 10:12:12 | bobTHC | ;) |
| 10:12:27 | bobTHC | nothing to add |
| 10:13:42 | DeadMan | so what's in progress on iRiver at the moment? |
| 10:13:56 | * | LinusN is working on the cpu clocking |
| 10:14:08 | DeadMan | figured out the ata prob yet? |
| 10:14:20 | LinusN | haven't had time to work on it... |
| 10:14:24 | DeadMan | k |
| 10:14:46 | DeadMan | I saw xshock got wav playback working of a sort |
| 10:14:51 | LinusN | will connect a logic analyzer to study the timing |
| 10:15:05 | LinusN | i'm disappointed that he didn't get the dma working |
| 10:15:18 | DeadMan | I think he does not know how to do it |
| 10:15:26 | LinusN | probably |
| 10:15:41 | DeadMan | someone might be able to figure it out |
| 10:16:01 | LinusN | i was hoping to not have to do that myself... |
| 10:16:18 | DeadMan | heh. more work |
| 10:16:25 | LinusN | too much to do already |
| 10:16:40 | DeadMan | have a chat with him see if you can offer him pointers |
| 10:17:06 | LinusN | we seem to run past each other in the channel |
| 10:17:39 | DeadMan | on different times :) |
| 10:17:54 | DeadMan | tell him to stay up overnight ;) |
| 10:18:05 | LinusN | :-) |
| 10:19:19 | | Join Schnueff [0] (~mah@test0.cs.uni-sb.de) |
| 10:24:21 | | Quit Lurkski (Read error: 104 (Connection reset by peer)) |
| 10:29:09 | | Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) |
| 10:46:59 | | Join Patr3ck [0] (~patr3ck@p548CB018.dip.t-dialin.net) |
| 10:58:38 | *** | Saving seen data "./dancer.seen" |
| 11:00 |
| 11:29:49 | Lurkski | ; ) |
| 11:45:49 | ashridah | indeed |
| 11:56:07 | | Join amiconn [0] (~jens@pD9E7F903.dip.t-dialin.net) |
| 12:00 |
| 12:01:22 | | Quit DMJC ("Leaving") |
| 12:04:02 | | Quit bobTHC (Read error: 110 (Connection timed out)) |
| 12:06:37 | | Join Aison [0] (~hans@zux166-181.adsl.green.ch) |
| 12:07:09 | | Join jyp [0] (~jp@111-103.245.81.adsl.skynet.be) |
| 12:24:56 | | Quit ashridah ("bbs") |
| 12:26:19 | * | HCl stretches |
| 12:27:19 | Lurkski | ***just a stranger wondering how rockboy is advancing |
| 12:28:10 | LinusN | slowly...about 11MHz :-) |
| 12:28:28 | Lurkski | LOL! |
| 12:28:44 | Lurkski | at least fast levels will be easier |
| 12:31:33 | Lurkski | hey Linus...got a second? |
| 12:31:53 | Lurkski | got some nooby questions for you |
| 12:33:27 | LinusN | shoot |
| 12:33:28 | | Quit izzy (Read error: 60 (Operation timed out)) |
| 12:34:57 | Lurkski | Well I'm an H140 owner who's been following the IRC logs since you guys were first thinking about porting to the iriver. Watching you guys work has really given be the desire to learn programming....especially low-level..... |
| 12:35:00 | Lurkski | so |
| 12:35:26 | Lurkski | I was wondering where to start so that someday I might be capable of contributing to the project |
| 12:36:01 | dwihno | Learning C is a good start |
| 12:36:53 | LinusN | exactly |
| 12:36:53 | | Join ashridah [0] (ashridah@220-253-120-66.VIC.netspace.net.au) |
| 12:37:12 | Zagor | playing with plugins in the simulator is a good way to practice rockbox programming without having to dig too deep into the technical details of the hardware |
| 12:37:13 | LinusN | Lurkski: what programming experience do you have today? |
| 12:38:22 | Patr3ck | I am thinking about adding profiling to the codecs to support your optimizing efforts |
| 12:38:40 | Patr3ck | is therre something with higher resolution than ticks for measurement? |
| 12:38:40 | Lurkski | Well I used to own a vic-20 and a C64 when I was around 12-13 way back in the day that I learned some VERY basic BASIC if you will. |
| 12:39:14 | LinusN | Patr3ck: no, but there are free timers to use |
| 12:39:47 | Lurkski | you no the old 30 goto 10 stuff.....made some cool little programs for that age with the help of my mom's boyfriend at the time |
| 12:39:58 | Patr3ck | ok |
| 12:40:10 | Lurkski | no = know |
| 12:40:31 | Patr3ck | does the tree of function calls need to be preserved for the profiling information |
| 12:40:52 | Patr3ck | or is it enough to just keep call count and a sum of durations |
| 12:41:25 | linuxstb | Lurkski: The first thing is probably to set up the build environment (details are in the Wiki). You need that to be able to compile Rockbox yourself from the source code, and then you can start making little changes to see what happens. |
| 12:41:31 | Zagor | Patr3ck: any information is better than none. so start simple and expand as you go. |
| 12:41:59 | | Quit Ka (Read error: 60 (Operation timed out)) |
| 12:42:32 | Patr3ck | I already prepared some simple functions to add to a central profiling information array |
| 12:42:39 | Lurkski | Ok, set up the build environment and playaround with plugins in the simsounds like a good start........ |
| 12:42:43 | Patr3ck | these could be used by all codecs |
| 12:43:26 | Patr3ck | the codecs are plugins, so I would need to add these to the plugin api? |
| 12:43:49 | Zagor | the codecs aren't plugins yet. they only have some test plugins for development. |
| 12:43:58 | linuxstb | Lurkski: Only problem is that if you are using Windows, the simulators don't currently work. But hopefully these will be working soon. |
| 12:44:04 | Zagor | there will be a separate codec api added. |
| 12:44:23 | Patr3ck | I see |
| 12:45:28 | Patr3ck | I will have a look at the free timers this evening |
| 12:45:30 | linuxstb | One approach would be to create a profiling library - you could put this in apps/codecs/libProfile and this could be linked against the codec plugins in the same way as the actual codec libraries themselves. |
| 12:46:01 | linuxstb | Or you could add it to plugins/lib/ - then it could be used by Rockboy. |
| 12:46:14 | LinusN | i have plans to introduce a usec timer |
| 12:46:37 | Lurkski | Ok linuxstb, thanks.........also,I bought the Art of Assembly Language the other day and I've made it through chapter one.....I'm not computer retarded and not easily intimidated (spel?) and I look forward to continuing......I was told asm would teach me a lot about software's interation with the hardware and would also be of value when learning a higher lever language like C. But I wanted to ask the opinions of you guys because you alread |
| 12:46:38 | LinusN | for profiling and usleep() |
| 12:46:49 | Zagor | linuxstb: let's talk about the codec api. for starters, i think we should not load files into memory until we have a free codec slot. i.e. the codecs load the files. |
| 12:47:02 | Patr3ck | ok |
| 12:48:03 | Patr3ck | How would a profiling build be separated from a release build? |
| 12:48:20 | linuxstb | Zagor: I'm happy to talk about it. |
| 12:49:03 | linuxstb | I don't know what we will gain by letting the codecs load the files - why are you thinking that? |
| 12:50:00 | LinusN | Patr3ck: use a #define |
| 12:50:02 | Zagor | because we don't know which data is important, meaning we will load a lot of useless metadata which takes up ram space |
| 12:50:21 | Patr3ck | #ifdef PROFILING? |
| 12:51:27 | linuxstb | I've thought about that as well, but I think it will greatly simplify things if we load the entire file into the buffer. Most formats have the metadata at the start of the file, so as soon as the "file_open" function has been called, it can be discarded. |
| 12:52:00 | Zagor | the other thing is that we don't gain anything by loading the file before we call the codec. we have to spin up the disk to load the codec anyway. |
| 12:52:23 | linuxstb | Not if the codec is the same as the previous one. |
| 12:52:25 | Zagor | think dvd images - playing only the sound requires buffering the video data as well... |
| 12:53:54 | LinusN | Patr3ck: PROFILING sounds fine |
| 12:54:01 | | Part Lurkski |
| 12:54:12 | | Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) |
| 12:54:18 | Patr3ck | ok |
| 12:54:38 | linuxstb | I understand what you are saying, but if we ever did that, we could implement a demuxer using a seperate "container" API. The "codec API" would just deal with audio streams. |
| 12:54:41 | Patr3ck | linusn: for now i will try the free timers |
| 12:55:04 | LinusN | look at tick_start() in kernel.c for an example |
| 12:55:11 | Patr3ck | linusn: if you add something better I make sure it can be changed easily |
| 12:55:15 | ashridah | personally, i was thinking about something along the lines of being able to insert a small asm block in the code that'd push the current tick, the current PC into a small array of persistent memorny, then increment an index into it. then when playback is done, dump that to a file. |
| 12:55:22 | Patr3ck | linusn: ok, thanks |
| 12:56:10 | ashridah | should at least get us basic timing if we insert them selectively to try and narrow down expensive bits of code, i was considering implementing something like that into the vorbis code progressively deeper, but i don't know enough about the structure of rockbox yet :) |
| 12:56:10 | QT | Hi! sorry for the n00b question, but how useful is the iriver port currently? installable? |
| 12:56:11 | Zagor | linuxstb: yes but then we're really talking added code complexity. a more real-life example is mp3 files with 500KB album art tags. |
| 12:56:22 | ashridah | qt: installable. looks pretty. plays nothing. yet. |
| 12:56:41 | QT | ashridah: ok. thanks. |
| 12:57:02 | QT | i just wonder all the time when i read comments here which let me think that some guys have rockbox already installed |
| 12:57:11 | LinusN | quite a few |
| 12:57:26 | ashridah | qt: we do, but it's for development purposes. |
| 12:57:31 | Bagder | amiconn: you here? |
| 12:57:33 | QT | understood |
| 12:57:53 | QT | is it easy to revert to orig firmware? |
| 12:58:01 | LinusN | you don't need to |
| 12:58:23 | LinusN | the original is still in flash |
| 12:58:36 | QT | ok. so the orig FW stays on while rockbox is running |
| 12:58:42 | *** | Saving seen data "./dancer.seen" |
| 12:58:43 | LinusN | but yes, it is very easy to revert |
| 12:58:45 | ashridah | qt: the bootloader is built into the original, so hold down a button, and the original boots and operates as if nothing has changed. |
| 12:58:45 | QT | ok, similiar as to how the xbox mods work |
| 12:59:01 | QT | that is good news |
| 12:59:10 | linuxstb | Zagor: OK, I understand what you are saying. But won't it require more disk spin-ups if we need to initialise a codec before reading the data from disk? Maybe the "loader" functions should be hard-coded into Rockbox. |
| 12:59:34 | linuxstb | s/hard-coded/compiled/ |
| 13:00 |
| 13:00:06 | Zagor | no, we only spin up once: to load the codec and/or load new files |
| 13:01:45 | Zagor | we don't load a codec until it's time to read files |
| 13:03:02 | | Join preglow [0] (thomj@s183a.studby.ntnu.no) |
| 13:03:40 | linuxstb | OK, so you are saying that the codecs themselves should be responsible for reading the data from disk and putting it in the compressed data buffer? |
| 13:03:55 | linuxstb | And that they should strip out as much "junk" as they can. |
| 13:04:25 | Zagor | yes |
| 13:04:30 | | Join Zezayer [0] (~zezayer@host81-152-218-69.range81-152.btcentralplus.com) |
| 13:04:58 | Zagor | naturally rockbox needs to supervise it and allocate space so several codecs can coexist. |
| 13:05:23 | Zagor | but the codecs themselves know best how to make best use of the ram they get |
| 13:06:20 | linuxstb | How are you thinking that the "supervision" would work? How would the codecs be allocated parts of the memory buffer? |
| 13:06:40 | preglow | LinusN: what are your thoughts about moving the active codec to sram? got any estimate on how much that'll boost performance? |
| 13:07:15 | QT | stupid question. i am looking for a way to rename every occurence of cover.jpg to Folder.jpg throughout my MP3 collection. any idea how to do this? i tried with for() combined with find() but it has troubles with the directory names including a space |
| 13:08:02 | | Join cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 13:08:04 | linuxstb | QT: You possibly just need to put the variable representing the filename in quotes - "$x" |
| 13:08:06 | Zagor | linuxstb: the codec api will have something like a read() function which rockbox calls when the buffer needs refilling. this call can include a pointer and length. |
| 13:08:19 | QT | linuxstb: tried that and it failed |
| 13:08:51 | Zagor | linuxstb: ...and return a length indicating how much was used. |
| 13:08:59 | LinusN | preglow: the internal ram has 1-cycle fetches, so it will be a huge boost |
| 13:09:07 | ashridah | qt: do you have spaces in any of the directory names? |
| 13:09:08 | QT | linuxstb: i even first put all directories to file, editedt the file to have the entries withtin "..." but still the for cc in `cat dirlist` can not handle it |
| 13:09:18 | QT | ashridah: in most |
| 13:09:22 | Bagder | amiconn: in case you check the log later, here's my initial take at our simulator fix: http://daniel.haxx.se/rockbox/ |
| 13:09:32 | ashridah | then you're in for a painful trip |
| 13:09:54 | Zagor | preglow: we need to think about how we can do that dynamically in a nice way since we have limited iram and will support multiple concurrent codecs |
| 13:09:57 | QT | ashridah: that is what i found out too :-( then i was looking for a windows tool that could do it but no luck either |
| 13:10:11 | ashridah | shell scripts aren't your answer, dealing with spaces in them is a royal pain in the butt, because bash constantly insists on stripping out quotation marks. |
| 13:10:26 | Bagder | QT: I'd use find to get the list of names, then treat each line as a full file name and use quotes |
| 13:10:28 | ashridah | perl can work, although i don't know enough perl to help you. |
| 13:10:28 | amiconn | Bagder: I'm here now. |
| 13:10:39 | QT | my idea now is to have a script dive into every directory, then if cover.jpg is there, rename it to Folder.jpg and continue with next directory |
| 13:10:40 | preglow | Zagor: yes, at least gapless playback across different codecs isn't a huge issue |
| 13:10:49 | preglow | LinusN: i'm really starting to think it'll be necessary, you see |
| 13:11:03 | LinusN | i have thought so all the time... |
| 13:11:04 | Bagder | amiconn: ok, my patch there builds here but it might need futher tweaking to do good in cygwin land |
| 13:11:06 | QT | badger: that was my idea too. it just doesn't handle the spaces though |
| 13:11:17 | Bagder | QT: mv with quotes does handle spaces |
| 13:11:36 | QT | badger: it does. but not the for() loop |
| 13:11:36 | ashridah | Bagder, sure. but not when they're embedded inside a for/find loop |
| 13:11:54 | Bagder | so 1) don't use for or 2) change IFS |
| 13:11:55 | ashridah | even if you escape them, you've got to have multiple levels of escapes |
| 13:11:56 | preglow | LinusN: mention it next time, please, i actually thought we'd have to optimize it down to realtime level ;) |
| 13:12:00 | Zagor | preglow: actually, gapless playback doesn't require two concurrent codecs. but voice and game sounds do. |
| 13:12:05 | QT | i think my best bet is to use read() and setting IFS to something giid |
| 13:12:18 | ashridah | yeah. |
| 13:12:21 | QT | s/giid/good |
| 13:12:23 | Zezayer | hey guys im a bit of a noob on the rockbox front, and having dificulties compiling the iriver firmware, can anyone offer any halp or maybe a link to a complete .hex file. thanks, and just ignore me if u cant help. |
| 13:12:36 | LinusN | preglow: i wanted you to sweat a little... :-) |
| 13:12:36 | preglow | Zagor: ahh, no, do we ever require to _concurrent_ codecs? |
| 13:12:42 | ashridah | Zezayer: define 'difficulties' |
| 13:12:46 | preglow | s/to/two/ |
| 13:12:58 | Bagder | crossfading ;-) |
| 13:13:03 | Zagor | preglow: yes, for mp3 voices during ogg music playback for instance |
| 13:13:11 | preglow | that can be done by buffering pcm data a while in advance, heh |
| 13:13:19 | preglow | if our codecs are fast enough |
| 13:13:27 | Bagder | preglow: that would be very short cross fade then |
| 13:13:42 | | Join Patr3ck_ [0] (~patr3ck@p548CB835.dip.t-dialin.net) |
| 13:13:50 | LinusN | you don't have to decode simultaneously |
| 13:13:54 | preglow | LinusN: around how many cycles does an sdram access use? |
| 13:14:11 | LinusN | 5+1+1+1 for a 4 word burst |
| 13:14:11 | Zagor | linuxstb: |
| 13:14:17 | preglow | Bagder: well, realtime beatmatching is pretty much out of the question, yes |
| 13:14:23 | Bagder | btw, there's no daily odion FM build because we get a linker error |
| 13:14:24 | LinusN | bus cycles, that is, which is half the cpu frequency |
| 13:14:34 | Bagder | "region FLASH is full" |
| 13:14:36 | preglow | LinusN: ouch |
| 13:14:50 | Zagor | linuxstb: does this differ much from what you had in mind? |
| 13:15:00 | LinusN | Bagder: rombox? |
| 13:15:00 | preglow | so we might actually end up having to optimize codecs for size |
| 13:15:07 | Bagder | LinusN: yes, for ondiofm |
| 13:15:08 | LinusN | preglow: why?= |
| 13:15:28 | Zagor | preglow: hopefully it's enough to put only parts of the codecs in inram |
| 13:15:31 | LinusN | i don't think the entire codec needs to be in iram |
| 13:15:51 | preglow | true |
| 13:15:55 | preglow | indeed |
| 13:16:21 | preglow | but i guess imdct and those fellas are good canidates |
| 13:16:25 | LinusN | yup |
| 13:16:31 | preglow | how much of the sram will be taken be other stuff, btw? |
| 13:16:37 | preglow | does the framebuffer have to live there? |
| 13:16:46 | LinusN | lcd framebuffer is there atm |
| 13:17:52 | preglow | but yes, i tried optimizing synth_full in libmad yesterday, and i concluded it really saturated the memory bus |
| 13:18:02 | preglow | there virtually no difference no matter what i do |
| 13:18:04 | LinusN | currently, we use about 6kbytes out of 96 :-) |
| 13:18:35 | preglow | at least my libflac optimization had _some_ impact |
| 13:18:47 | linuxstb | Zagor: No, I think you are talking about something extra on top of what I proposed. I don't think the fact that the codecs help the audio system fill the buffer has to change how the decoding works. |
| 13:19:37 | Zagor | linuxstb: i agree |
| 13:19:44 | LinusN | preglow: would it help if some data was in iram too? |
| 13:19:52 | preglow | LinusN: most certainly |
| 13:20:13 | LinusN | so we would, for example, move the frame to iram before decoding |
| 13:20:22 | linuxstb | But I'm still not convinced that stripping out metadata is a good idea - for example, if the codec (such as FLAC) contains a seektable, then if we remove metadata, we may break seeking. |
| 13:20:31 | LinusN | sine tables etc? |
| 13:20:32 | amiconn | Bagder: The linker error for Ondio FM rombox has been there for a while. I wonder why the dailies worked before... |
| 13:20:41 | preglow | LinusN: yes, stuff like windows and twiddle factors |
| 13:20:50 | | Quit Schnueff ("leaving") |
| 13:21:10 | preglow | LinusN: there's a pretty large array of constant numbers in libmad, for example |
| 13:21:12 | Zagor | linuxstb: all i'm saying is i think the codec is best equipped to decide which data should be buffered in ram and which can be discarded. |
| 13:21:27 | LinusN | preglow: is it really a dct, or is it an fft? |
| 13:21:40 | preglow | LinusN: libmad actually has both a dct and an imdct |
| 13:21:55 | LinusN | oh |
| 13:21:55 | preglow | LinusN: you can calculate it using an fft, but that's not done in either libmad or tremor, afaik |
| 13:22:26 | LinusN | too few points to really make a difference, ? guess |
| 13:23:16 | amiconn | Bagder: Why are these (PREFIX) things still necessary in plugin.[ch]? I thought we can get rid of them completely with the new concept... |
| 13:23:17 | preglow | in what regard do you mean? |
| 13:23:40 | LinusN | how many points are the dct calculated for? |
| 13:23:45 | preglow | in mp3, 36 or 12 |
| 13:23:50 | preglow | depends on transient detector |
| 13:24:02 | preglow | short windows are used for transients |
| 13:24:02 | Bagder | amiconn: because the #defines doesn't work for the field members in the plugin struct |
| 13:24:25 | preglow | in vorbis, anything from 256 to 2048 can be used, two window sizes are set up in the header |
| 13:24:42 | LinusN | 36 point fft sounds small |
| 13:24:50 | Bagder | amiconn: I didn't want to make the defines more generic, like #define open sim_open because I think it'll be bad in the long run |
| 13:24:56 | LinusN | besides fft wants a power of 2 |
| 13:25:10 | preglow | yes, but using fft in an audio codec isn't really clever, mdct compacts more energy into fewer coefficients and thus compresses better |
| 13:25:13 | LinusN | vorbis sounds like an fft candidate though |
| 13:25:35 | preglow | it is if we can find a _very_ optimized fft routine |
| 13:25:49 | preglow | you need to do pre and post sorting as well if you calculate it using the fft |
| 13:25:50 | linuxstb | Zagor: What do you think about the concept of a "read callback" used by the codecs - i.e. a "pull" system instead of a "push" system. |
| 13:25:57 | LinusN | preglow: you're the expert |
| 13:27:01 | amiconn | Bagder: The defines don't work for the struct members? I can't imagine why that is atm... |
| 13:27:05 | preglow | but we'll see, not rewriting the codecs too much would be preferable, but does seem to be unavoidable |
| 13:27:19 | LinusN | indeed |
| 13:27:29 | Bagder | amiconn: because the defines look like #define open(x,y) and in the struct they are int (*open)(x,y) |
| 13:27:41 | amiconn | Ah, yes. |
| 13:28:08 | Zagor | linuxstb: i think that is the way to do it. give the codecs a proper api callback struct just like the plugins. |
| 13:28:29 | preglow | but moving to sram will be a very good first step, the transforms are very memory hungry, more or less every operation uses a memory access |
| 13:28:37 | LinusN | preglow: i'll look into the possibility to let the codecs copy code and data to iram |
| 13:28:50 | Bagder | anyone wants a cup of coffee? |
| 13:28:55 | LinusN | Bagder: please |
| 13:28:58 | preglow | i'm making one as we speak |
| 13:29:10 | * | Bagder walks to get a big cup for everyone |
| 13:29:21 | * | preglow tosses his cup out the window |
| 13:29:55 | * | LinusN swallows the cold remains of the last cup |
| 13:30:05 | | Quit Patr3ck (Read error: 110 (Connection timed out)) |
| 13:30:36 | linuxstb | Zagor: What about ID3-type metadata, should the codec API include a function to get the metadata from a disk file, without needing to initialise the codec instance? I'm thinking about getting "next track" info. |
| 13:31:07 | preglow | LinusN: the coldfire timers are pretty high resolution, yes? |
| 13:32:06 | Zagor | linuxstb: no that's not necessary. next track will already have been loaded, and the metadata parsed, by the time the information is to be displayed. just like today. |
| 13:32:17 | * | ashridah looks at the coffee strangely, and returns to his caffeinated mints. |
| 13:32:49 | preglow | i was thinking, having the timer interrupt look at its stack frame and note the previous %ip, wouldn't it be possible to have it save it in some table that's dumped to disk later, then translate all the addresses to function names? |
| 13:33:12 | preglow | simple profiling could be done that way, unless i'm terribly wrong, which i probably am |
| 13:33:27 | amiconn | Bagder: The simfix patch doesn't apply cleanly against cvs... uisimulator/common/dir.h fails |
| 13:33:40 | linuxstb | Zagor: Are you thinking of always having two codec instances "active" at the same time. i.e. one for the current track, and one for the next track, even if they are the same codec? |
| 13:33:52 | Bagder | amiconn: that should be removed anyway |
| 13:34:29 | amiconn | Yes.. I only wanted to mention it. You seem to have other changes there that aren't in cvs. |
| 13:34:41 | Zagor | linuxstb: no, but we always load as many tracks as we can fit in ram (or as many as our codec slots can fit). and metadata is parsed and "published" by the codecs when loading the files. |
| 13:35:06 | Bagder | amiconn: oh, right, but it removes all lines ;-) |
| 13:35:14 | preglow | Zagor: you fill the buffer completely, even though you can't fill the last track in its entirety, i hope? |
| 13:35:26 | Zagor | preglow: yes |
| 13:35:26 | linuxstb | Some codec libs (I'm thinking FLAC) will only give you access to the metadata after you have initialised the codec for decoding that dfile. |
| 13:35:28 | preglow | Zagor: good |
| 13:35:37 | LinusN | preglow: coldfire has 1-cycle resolution timers |
| 13:35:45 | linuxstb | But we can possibly work around that. |
| 13:35:48 | preglow | LinusN: would my profiling idea work? |
| 13:35:48 | Bagder | preglow: with only 1.7MB buffer that is usually the case you know ;-) |
| 13:36:31 | preglow | Bagder: hahaha, a miracle the disk doesn't wear out after a months use |
| 13:36:37 | LinusN | preglow: yes it could work |
| 13:36:39 | Zagor | linuxstb: yes, i know. but we will not load files into ram until we have a free codec slot that can load and parse it. |
| 13:38:27 | * | Zagor scours the kitchen for scraps of food. brb. |
| 13:39:30 | linuxstb | How many codec slots do you have in mind? There could easily be 3 or 4 different codecs needed to completely fill the memory with data (e.g. if the user is shuffling the whole disk). |
| 13:39:31 | preglow | do any of the 68k people know if burst moving data to registers with movem before doing computations is better than interleaving the computations with move instructions? |
| 13:39:52 | LinusN | preglow: yes and no |
| 13:40:39 | LinusN | if your data is in sdram and the code is in iram, i'd guess that interleaving might be better |
| 13:40:55 | LinusN | not necessarily though |
| 13:41:14 | * | LinusN is not a coldfire expert |
| 13:41:15 | Zagor | linuxstb: I think the default should be 2 slots. it's a balancing act. more slots waste ram (cost battery) for users with few formats, and few slots waste ram for users with many formats. |
| 13:41:16 | | Join Schnueff [0] (~mah@test0.cs.uni-sb.de) |
| 13:41:17 | preglow | i guess this is a special case, since i'm fetching data from two different locations |
| 13:42:02 | amiconn | Bagder: The x11 sim now compiles on cygwin, but fails to link. The win32 sim compile fails in filetypes.c at the plugin.h include |
| 13:42:13 | preglow | which are sequantial, if i'm not mistaken, reading sequantially is a lot better than constantly switching to different addresses |
| 13:42:50 | Bagder | amiconn: let's ignore the link failure for now, what's the filetypes.c problem? |
| 13:43:23 | LinusN | preglow: yes, sdram benefits from burst reads |
| 13:43:49 | linuxstb | My thoughts were to load the codec as late as possible - so there will be no compromise. We could compile the codec-specific loading and metadata parsing functions into Rockbox, and only dynamically load the actual decoding parts of the codecs. |
| 13:44:23 | linuxstb | If the loadable part of the codec didn't nead to be used until decoding, we would only need 2, or maybe even just 1 codec slot. |
| 13:44:54 | amiconn | Bagder: There's a heapload of errors, I'll send you the log |
| 13:45:00 | Bagder | sure |
| 13:45:22 | Bagder | linuxstb/Zagor: we could also consider having a few selected codecs "built-in" |
| 13:45:45 | Zagor | linuxstb: loading it late gives no benefit. the only cost is a spinup. spinning up to load a codec or codec+files is equivalent. |
| 13:45:49 | linuxstb | If the voice files are to be MP3, then it would make sense to have libmad built-in. |
| 13:46:15 | Zagor | Bagder: it won't give us any benefit, only "cost" when not in use |
| 13:46:26 | amiconn | I can't remember how to redirect both stdout and stderr to the same file atm... anybody? |
| 13:46:37 | Bagder | Zagor: it could be a gain "in average" |
| 13:46:50 | Bagder | amiconn: > file 2>&1 |
| 13:47:23 | HCl | i think we're doing something wrong if codecs have that much problems with working properly, and slight optimizations aren't going to help with it.. |
| 13:47:28 | Zagor | Bagder: no. you won't gain any spinups and you won't save any ram. in fact you will waste ram, since you have unused codec slot ram. |
| 13:47:30 | | Join bobTHC [0] (~foo@l03v-35-141.d1.club-internet.fr) |
| 13:48:16 | Bagder | it saves spinups if you use many codecs |
| 13:48:33 | Bagder | but never mind, it was just tossing in an idea |
| 13:48:36 | Zagor | no, since loading a codec doesn't add a spinup. it uses the same spinup used to load the file. |
| 13:48:37 | Bagder | I was |
| 13:48:46 | Bagder | Zagor: not if you use 5 codecs to fill the buffer |
| 13:48:48 | amiconn | Zagor: What about the voice ui? |
| 13:48:52 | Zagor | Bagder: yes |
| 13:48:52 | Bagder | since they won't fit |
| 13:49:10 | Bagder | oh you can of course, right |
| 13:49:19 | Bagder | just do it serially |
| 13:49:25 | | Join AC [0] (~5078751e@labb.contactor.se) |
| 13:49:38 | AC | morning |
| 13:49:54 | Zagor | you're right, if you have more formats than slots you will get more spinups. but hardcoding codecs isn improve |
| 13:50:06 | Zagor | isn't any better than simply increasing the number of slots |
| 13:50:13 | Bagder | true |
| 13:50:58 | AC | is it possible to get cvs write access? |
| 13:51:13 | Bagder | AC: yes |
| 13:51:20 | Bagder | AC: but you need to motivate it |
| 13:51:27 | Bagder | and prove yourself |
| 13:51:27 | linuxstb | That's why I was suggesting moving the "loader" functions (which will be quite simple, and may even be shared between audio formats) into the main Rockbox binary - we are then not limited by the number of codec slots. |
| 13:51:40 | Zagor | amiconn: the voice ui will get its' own ram buffer that is locked and not used for music buffering |
| 13:51:49 | AC | i need the access for the wavpack codec |
| 13:53:50 | linuxstb | The "loader" functions would also parse the metadata - this would be a good way to unify the metadata parsing in one place. |
| 13:54:01 | Zagor | linuxstb: however doing that means our codecs are not true plugins. i.e. you can't add a codec binary without recompiling rockbox. which would be a loss in my opinion. |
| 13:54:25 | AC | Bagder: what do you need for informations for the cvs-account? |
| 13:54:51 | linuxstb | Zagor: I don't think it's a big loss. New codecs will be rare. |
| 13:55:36 | LinusN | yes, but it would de impossible to have 3rd party codecs |
| 13:55:54 | linuxstb | Why would we want third-party codecs? |
| 13:56:33 | amiconn | Zagor: Yes, but the voice ui also needs the mp3 decoder |
| 13:57:06 | amiconn | (or any other compressed audio codec, but mp3 being the easiest) |
| 13:58:01 | preglow | amiconn: speex would probably be preferable for that |
| 13:58:01 | Zagor | linuxstb: more importantly, it's no gain. in order to use the loaded data we need to load the codec, which means spinning up the disk anyway |
| 13:58:45 | amiconn | preglow: That can be left for later, but the point is that for the voice ui, it would be preferable to have a locked codec |
| 13:58:49 | LinusN | linuxstb: i can imagine that somebody creates a codec that we aren't interested to have in our cvs |
| 13:59:19 | LinusN | either because it isn't particularly interesting, or because of patent issues |
| 13:59:26 | LinusN | or something else |
| 13:59:31 | preglow | amiconn: yes, and speex should be used from the start, imho, it's smaller and better suited |
| 13:59:53 | preglow | amiconn: size will probably not be an issue, forget it |
| 14:00 |
| 14:00:03 | Zagor | amiconn: i'm split between using a strict last-recently-used scheme for the codecs or allowing the voice ui to lock a codec into place. both have benefits and costs. |
| 14:00:32 | linuxstb | OK, I'm convinced now. |
| 14:01:08 | Zagor | linuxstb: excellent! :-) |
| 14:02:39 | AC | will be back... siwtching to linux to improve my wv2wav plugin |
| 14:02:45 | | Quit AC ("CGI:IRC") |
| 14:04:08 | Zagor | LinusN: btw, the dma layer is present in the wiki page. it's the "feeder". |
| 14:04:24 | LinusN | oki |
| 14:06:02 | linuxstb | However, I still think that stripping out the metadata will complicate the codec API for very little gain - but that's probably because I never put any metadata in my files anyway, so there is nothing to be discarded. |
| 14:06:41 | preglow | linuxstb: stripping out metadata how? |
| 14:07:02 | Zagor | some code needs to do that parsing, and I thing the codec is the right code to do it |
| 14:07:57 | Zagor | again, letting core rockbox do it would mean we cannot add support for any file format without modifying core rockbox |
| 14:11:20 | jyp | What's ata_enable exact purpose ? |
| 14:11:40 | LinusN | enable the buffers for the ata interface |
| 14:11:47 | jyp | Is it normal it is in disabled state when usb is plugged ? |
| 14:11:55 | jyp | Hello btw :P |
| 14:11:56 | LinusN | yes |
| 14:12:19 | jyp | Do you think it is possible the gmini has no such a feature ? |
| 14:12:31 | LinusN | perhaps |
| 14:12:43 | jyp | Alright, thanks |
| 14:12:45 | LinusN | it depends on the hardware |
| 14:13:09 | | Join AC [0] (~5078751e@labb.contactor.se) |
| 14:13:36 | linuxstb | Zagor: For MP3 we can strip out tags, and we still end up with a valid MP3 fille, for other formats, that may not be possible, So I think the "read" functions in practice, most of the codecs will have to read the entire file. But I agree that we should give codecs the opportunity to strip out parts of the file, so let's go with your idea. |
| 14:14:24 | linuxstb | i.e. it's an optimisation that we don't have to implement for all the codecs - at least not immediately. |
| 14:14:25 | ashridah | LinusN: hm. i just thought of something. the usb-ide bridge gets the ata timings correct automatically doesn't it? wouldn't you be able to nick them from the datasheet from the bridge? |
| 14:14:35 | Zagor | linuxstb: exactly |
| 14:14:36 | ashridah | or isn't it that simple. |
| 14:14:56 | linuxstb | We're happy then :-) |
| 14:15:01 | LinusN | ashridah: the ata timings are taken from the IDENTIFY command |
| 14:15:02 | Zagor | very :) |
| 14:15:34 | LinusN | 120ns cycle time in mode 4 |
| 14:15:41 | * | Zagor seriously considers buying one of those C64 DTV joysticks |
| 14:15:46 | * | ashridah probably should read more about ata before saying stuff in public. |
| 14:15:51 | LinusN | :-) |
| 14:16:31 | LinusN | it might very well be brain damage in my end |
| 14:16:42 | LinusN | i certainly hope so |
| 14:18:50 | LinusN | and untimately, it might not even be the ata timing that is the problem |
| 14:19:07 | LinusN | it could be sdram timing as well, but i doubt it |
| 14:19:30 | linuxstb | Zagor: have you thought about what threads we will need for audio playback? i.e will the "read data from disk" function in the codec be running in a different thread to the rest of the codec code? |
| 14:19:31 | LinusN | amiconn: u there? |
| 14:20:52 | Bagder | announce: fprintf() is soon known as fdprintf() in Rockbox |
| 14:21:42 | LinusN | aha |
| 14:21:45 | Bagder | sleep() is also subject for a rename |
| 14:21:58 | LinusN | oki |
| 14:22:06 | Bagder | to keep POSIX function names posix |
| 14:22:24 | linuxstb | Bagder: How about "tsleep" for "tick sleep" ? |
| 14:22:25 | Bagder | but we haven't come up with a good name for sleep() ;-) |
| 14:22:28 | LinusN | ksleep() for "kernel sleep" maybe? |
| 14:22:29 | Zagor | linuxstb: i'd like the codecs to be single-threaded. i think we should aim for that for starters, at least. |
| 14:22:35 | ashridah | rofl. i see someone made the minor change to the makefile i suggested. |
| 14:22:38 | * | ashridah exists! |
| 14:22:39 | preglow | tsleep for teick sleep? :V |
| 14:22:42 | preglow | tick |
| 14:23:50 | LinusN | SleepOneTick(HANDLE hThread, DWORD dwTicks); :-) |
| 14:23:55 | linuxstb | Zagor: I was thinking we would need different threads to a) keep the compressed data buffer full" and b) to actually decode the data. |
| 14:24:18 | | Quit elinenbe (Read error: 104 (Connection reset by peer)) |
| 14:24:48 | | Join elinenbe [0] (elinenbe_@207-237-225-9.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 14:24:55 | Zagor | linuxstb: hmm you are right, yes we will need that (or a very large pcm buffer, which we don't want) |
| 14:25:41 | LinusN | Zagor: it depends on how we design the codec thread |
| 14:26:01 | LinusN | the swapping doesn't need a separate thread today |
| 14:27:05 | | Join Bagder_ [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) |
| 14:27:15 | Zagor | no but we have a very long output buffer for that. the codecs will likely have to run once every few seconds, which means we cannot have multisecond disk accesses |
| 14:27:31 | LinusN | true |
| 14:27:42 | Bagder_ | amiconn: try my new -2 patch from the same place: http://daniel.haxx.se/rockbox/ |
| 14:27:42 | Zagor | spinning up and reading 25+ MB from disk will likely take a while |
| 14:28:20 | LinusN | how are the codecs designed? can we decode really small chunks at a time? |
| 14:28:36 | Zagor | my guess is that differs between codecs |
| 14:28:38 | | Join CoCoLUS [0] (~coco@h081217139221.dyn.cm.kabsi.at) |
| 14:28:56 | CoCoLUS | mornin |
| 14:28:57 | Zagor | however i assume most codecs can decode subsecond chunks |
| 14:29:18 | linuxstb | LinusN: audio frames (the minimum data that can be decoded in one function call) are normally no more than about 20ms-30ms |
| 14:29:31 | LinusN | somehow i feel that the stream-blabla stuff in the flac codec is really ugly |
| 14:30:06 | linuxstb | What do you mean? The API or the implementation? |
| 14:30:10 | LinusN | i want a clean buffer-in -> buffer-out concept |
| 14:30:33 | LinusN | the api |
| 14:30:43 | LinusN | just browsed the flac2wav plugin |
| 14:31:16 | linuxstb | You have the "decode single frame" function - which will give you one frame of PCM data. |
| 14:31:28 | LinusN | that sounds more like it |
| 14:32:26 | linuxstb | That's what the flac2wav plugin is using - "FLAC__seekable_stream_decoder_process_single()" |
| 14:33:08 | linuxstb | The problem is that we don't know how much data to give as input - which is why the use of read() callbacks (to let the codec "pull" data from the buffer) seems the easier way. |
| 14:33:19 | HCl | amiconn: i'm getting the feeling your rockboy makefile doesn't clean when you do make clean |
| 14:33:33 | | Join markun [0] (~markun@bastards.student.utwente.nl) |
| 14:33:37 | LinusN | linuxstb: maybe i just didn't look closely enough, my apologies |
| 14:33:58 | Zagor | linuxstb: oh, that wasn't what I meant with adding a read callback :) |
| 14:34:16 | linuxstb | Zagor: Yes, I know. We need two different read callbacks. |
| 14:34:30 | linuxstb | Or are you disagreeing with the second type of read callback? |
| 14:34:31 | Zagor | why can't the codec just use the ram directly? |
| 14:34:47 | amiconn | HCl: I would love to dig into it, but it may be really helpful to get the sims building again for that... |
| 14:35:05 | LinusN | amiconn: didn't you write a disk r/w test plugin? |
| 14:35:08 | amiconn | Bagder: Do I need to revert the first patch before? (I guess so) |
| 14:35:14 | Bagder_ | amiconn: yes, do that |
| 14:35:21 | amiconn | LinusN: yes I did |
| 14:35:28 | LinusN | can you email it? |
| 14:35:41 | amiconn | LinusN: It writes a file full of pseudo-random data, then reads back and compares |
| 14:36:01 | LinusN | looks like i need that |
| 14:37:07 | linuxstb | Zagor (from the Wiki): The alternative to using a read callback to pass data from the audio system to the codecs is for the audio system to pass a pointer to a memory buffer to the "decode_data()" routine. Although this seems the simpler approach, it will make the codec implementation more complex. The main problem is that the amount of input data required to decode X bytes of PCM data is only known by the codec - so allowing the codec to |
| 14:37:07 | linuxstb | request Y bytes of compressed data from the audio system is simpler than the audio system trying to predict how much data the codec will need in a particular decode step. |
| 14:38:39 | Zagor | linuxstb: i suggest skipping around that problem entirely. rockbox tells the codec: here's some ram you may use. the codec loads data into this ram. then rockbox says: please give me X pcm samples. |
| 14:39:16 | Zagor | rockbox does not care where in ram the codec is reading the compressed data |
| 14:39:27 | | Quit Bagder (Read error: 110 (Connection timed out)) |
| 14:40:23 | | Nick Bagder_ is now known as Bagder (~daniel@1-1-5-26a.hud.sth.bostream.se) |
| 14:41:41 | preglow | linuxstb: agreed there |
| 14:42:09 | linuxstb | Zagor: I'm not sure why you are against my idea of a read callback. I think it's a simple solution. |
| 14:42:48 | Zagor | I simply don't see why we need it |
| 14:44:32 | linuxstb | Because we need a way to give codecs access to the memory buffer. We have three options 1) Pass the codecs pointers to memory, 2) Use a read callback, 3) Just give the codecs access to a large chuink of memory for it to manage it's own buffering. |
| 14:44:57 | Zagor | i think option 3 is the best way |
| 14:46:20 | linuxstb | OK, can you explain how that would work? How would you decide how much memory to give to the codec? When would the codec be allowed to access the disk? |
| 14:48:14 | Zagor | we tell the codec to load a file, using a call such as load(). this call includes a pointer to and a length of a memory area the codec may use. the call returns how many bytes it actually used. |
| 14:49:18 | Zagor | remember not all file formats are streamed. think mod or sid playback, where the codec really needs random access to the whole file. |
| 14:51:08 | | Quit HCl ("Lost terminal") |
| 14:53:25 | Bagder | http://www.rockbox.org/twiki/bin/view/Main/UiSimulator |
| 14:53:28 | linuxstb | Would that then mean that the codecs need to have two threads - one to read data from disk and one to decode it? |
| 14:53:31 | Bagder | an embryo |
| 14:54:35 | Zagor | linuxstb: they do, but not because of this. they need that in any case. |
| 14:55:20 | amiconn | Bagder: Your second patch has the same problem... |
| 14:55:35 | Zagor | (because we need to be able to refill the buffer while playing music, which could be done by the same plugin) |
| 14:56:44 | linuxstb | So how much of the "compressed data buffer" would you give to a codec? All of it? |
| 14:57:16 | linuxstb | It just seems that all the work of the "audio system" is now being duplicated inside each of the codecs. |
| 14:57:27 | Bagder | amiconn: can you dcc me the new output? |
| 14:58:10 | linuxstb | i.e. that the "audio system" will be very simple, and the codecs more complicated. But I'm not saying that's a bad thing. |
| 14:58:20 | | Join muesli- [0] (muesli_tv@hmln-d51475b8.pool.mediaWays.net) |
| 14:58:27 | Zagor | linuxstb: the codec gets all free memory, uses as much as it needs and "returns the rest" (i.e. says how much it used) |
| 14:58:39 | Zagor | I don't see what is complex about it |
| 14:58:46 | *** | Saving seen data "./dancer.seen" |
| 14:59:29 | linuxstb | By "complex", I just mean that more work is done inside the codec, and less work (i.e. buffer management) is done in the audio system. |
| 14:59:55 | muesli- | hi |
| 15:00 |
| 15:00:00 | LinusN | hi |
| 15:00:15 | Zagor | i disagree. having a buffer does not mean it has to do any "buffer management". it's just a big chunk of ram. |
| 15:00:23 | linuxstb | We would want a codec to be able to read 4 or 5 files into memory during one spin-up (assuming there was space). |
| 15:01:31 | Zagor | true. hmm, let me think about that a bit. back in a bit. |
| 15:02:16 | linuxstb | The RAM is only "big" if the file is "small". If you have, for example, a 200MB file (which I have a lot of), then the codec will need to manage the buffer and also batch the disk reads to minimse the number of disk spin-ups. |
| 15:02:24 | | Join hcl [0] (hcl@titania.student.utwente.nl) |
| 15:02:29 | | Nick hcl is now known as HCl (hcl@titania.student.utwente.nl) |
| 15:02:32 | * | HCl whacks screen |
| 15:12:50 | Bagder | amiconn: ok, another shot. rerun configure after applying |
| 15:14:11 | amiconn | Bagder: Did you change the patch? |
| 15:14:29 | Bagder | yes, there's a -3 now |
| 15:18:27 | amiconn | Bagder: |
| 15:18:28 | amiconn | In file included from filetypes.c:31: |
| 15:18:28 | amiconn | plugin.h:69:30: plugin-win32.h: No such file or directory |
| 15:20:06 | Bagder | arg |
| 15:20:31 | LinusN | Bagder: do it right, once and for all :-) |
| 15:20:44 | jyp | or use a CVS branch :P |
| 15:20:44 | * | Bagder swings for LinusN |
| 15:20:51 | * | LinusN ducks |
| 15:21:31 | Bagder | amiconn: try copying some of the plugin-win32.h file from uisim/win32 into the plugin.h file instead |
| 15:22:07 | Bagder | I removed that dir from the include path when building firmware/ and apps/ stuff |
| 15:23:02 | Bagder | it felt like a clean break |
| 15:23:57 | amiconn | Hmm. If I don't overlook something, files in apps/ and firmware/ should never include files from the uisimulator/ tree |
| 15:24:14 | Bagder | correct |
| 15:24:19 | | Part Lurkski |
| 15:24:20 | Bagder | and that's why you get that failure ;-) |
| 15:24:36 | Bagder | the plugin-win32.h is in uisim/win32 |
| 15:25:01 | amiconn | Bagder: I need to figure out which stuff needs to get included. That may be a problem doing in parallel to work... |
| 15:25:24 | Bagder | amiconn: well, if you could just confirm that doing it works, I can do it too in my end |
| 15:27:18 | Bagder | amiconn: or just try my -4 patch |
| 15:27:57 | Bagder | I moved in what I think is needed |
| 15:28:29 | | Quit muesli- (Read error: 113 (No route to host)) |
| 15:28:40 | | Quit Zezayer ("ChatZilla 0.9.61 [Mozilla rv:1.7.2/20040804]") |
| 15:29:16 | | Join Zezayer [0] (~zezayer@host81-152-218-69.range81-152.btcentralplus.com) |
| 15:29:58 | | Part LinusN |
| 15:33:17 | amiconn | Bagder: Now it compiles farther, but there are some warnings, and then it errors in dir-win32.c. I'll send you the output |
| 15:33:32 | HCl | anyone around who might be able to run the rockboy.rock on my ftp on an iriver? i don't have my iriver around at the moment and i need to know whether it works or not.. |
| 15:33:49 | CoCoLUS | yeah here |
| 15:33:58 | HCl | ftp://titania.student.utwente.nl/rockboy.rock |
| 15:34:03 | HCl | it should work with current cvs |
| 15:34:05 | CoCoLUS | where to put the rom? |
| 15:34:11 | HCl | just anywhere |
| 15:34:17 | HCl | you need to install it as viewer |
| 15:34:19 | CoCoLUS | i have 18/2, that new enough?= |
| 15:34:23 | HCl | um. |
| 15:34:27 | HCl | i don't know, to be honest. |
| 15:34:29 | HCl | probably. |
| 15:34:50 | * | HCl is gonna run out of battery soon.. |
| 15:35:52 | linuxstb | HCl: I can try it as well. |
| 15:36:01 | HCl | please |
| 15:36:07 | HCl | i just need to know whether it still works or not |
| 15:36:23 | HCl | i made a few changements to the physical storage of gameboy registers, in preperation for dynarec |
| 15:36:29 | HCl | changes* O.o; |
| 15:36:33 | | Join R3nTiL [0] (~zorroz@83.69.98.221) |
| 15:36:34 | HCl | gee, that was a bad typo >.>; |
| 15:37:35 | linuxstb | HCl: I get "incompatible version" when trying to load your plugin... |
| 15:37:56 | linuxstb | Do you have a rockbox.iriver I can use with it? |
| 15:38:53 | amiconn | linuxstb: HCl extended the plugin api for rockboy, so you'll need the matching rockbox.iriver |
| 15:39:37 | HCl | linuxstb: hold on |
| 15:39:41 | CoCoLUS | me too |
| 15:39:44 | HCl | i thought it was up to date, but i should have it |
| 15:39:50 | HCl | there |
| 15:39:53 | HCl | on my ftp |
| 15:39:57 | HCl | rockbox.iriver |
| 15:41:02 | HCl | it actually is compatible with the old api, but it used a higher version number |
| 15:41:15 | Bagder | amiconn: try removing dir-win32.c from the uisim/win32/SOURCES |
| 15:41:25 | Bagder | it shouldn't be there for cygwin builds anyway |
| 15:41:32 | linuxstb | HCl: It's now running.... |
| 15:41:38 | Zagor | linuxstb: how about this: we (core rockbox) tell the codec to load a file to ram (or as much as fits). then, separately from that, we call it to start decoding from ram. thus the codec only ever handles one buffer at a time, which is handed to it as pointer/length by rockbox. |
| 15:41:43 | HCl | linuxstb: okies |
| 15:41:53 | HCl | linuxstb: tell me if you get screen output / if it seems to work properly |
| 15:42:04 | linuxstb | HCl: But my screen has gone blank - not even the frame counter. |
| 15:42:15 | HCl | hrm :/ |
| 15:42:19 | HCl | *sighs* |
| 15:42:25 | HCl | i don't understand whats going wrong :/ |
| 15:42:26 | linuxstb | Sorry, let me test again... |
| 15:42:38 | Zagor | core rockbox also tracks remaining buffer, and triggers refill |
| 15:42:39 | HCl | its not your fault, earlier i tried the same thing with a slightly different arrangement |
| 15:42:48 | HCl | and it went completely nuts |
| 15:42:52 | linuxstb | The frame counter has now appeared (after I pressed stop once) |
| 15:42:58 | HCl | okay o.o |
| 15:43:02 | HCl | what was it at? |
| 15:43:09 | linuxstb | 70 |
| 15:43:13 | HCl | gah. |
| 15:43:16 | linuxstb | It's at 70 now. |
| 15:43:19 | HCl | frustrating. |
| 15:43:26 | HCl | :( |
| 15:43:31 | preglow | HCl: dynarec? |
| 15:43:34 | HCl | *doesn't understand why it won't work at all* |
| 15:43:41 | HCl | preglow: no, just some changes to the interpreter |
| 15:43:54 | HCl | moving registers to 32 bit vars and not storing them in 1 word in memory |
| 15:44:07 | HCl | in preperation for dynarec |
| 15:44:52 | | Quit HCl ("Lost terminal") |
| 15:45:43 | | Join hcl [0] (hcl@titania.student.utwente.nl) |
| 15:45:48 | hcl | sorry |
| 15:45:50 | hcl | screen keeps crashing |
| 15:45:53 | hcl | >/ |
| 15:46:24 | jyp | Is there an api do dump textual data to disk ? |
| 15:46:50 | linuxstb | Zagor: But why does the codec need to handle the buffer at all? All the codecs I've looked at are perfectly happy to just treat the input as a stream and read sequenctially from the start to end. All the audio system needs to do is (with help from the codec provided "load and filter" function) is to manage a large ringbuffer. |
| 15:47:54 | hcl | linuxstb: did it show any output or did it just plain crash? |
| 15:48:25 | CoCoLUS | it loads the rom |
| 15:48:33 | CoCoLUS | shows a counter on the left top |
| 15:48:35 | Zagor | linuxstb: enforcing a stream concept removes all possibility of mod and sid support, which is sad methinks |
| 15:48:46 | hcl | CoCoLUS: whats the counter at? |
| 15:48:47 | CoCoLUS | then i get small bars from the top to the bottom :) |
| 15:48:49 | | Nick hcl is now known as HCl (hcl@titania.student.utwente.nl) |
| 15:48:53 | HCl | bars? |
| 15:48:53 | CoCoLUS | 7, 8, something like that |
| 15:49:00 | HCl | what rom are you loading? |
| 15:49:08 | CoCoLUS | the mario.gb from your ftp |
| 15:49:09 | HCl | mario starts displaying at 14 |
| 15:49:15 | linuxstb | No it doesn't. They can be a special case because their file sizes are so tiny (typically less than 64K). The gain is to make everything a lot simpler. |
| 15:49:20 | HCl | okay, tell me if it shows anything when it gets to 14 o.o; |
| 15:49:24 | Zagor | mods can be several megabytes |
| 15:49:26 | * | HCl 's class is starting.. |
| 15:49:28 | HCl | afk :/ |
| 15:49:39 | CoCoLUS | ok now there was some msg invalid opcode, and plugin returned error, went away before i could read it |
| 15:49:58 | | Quit ashridah ("sleep") |
| 15:50:19 | CoCoLUS | im sorry i can't help you more, i'll be back later if you need some more testing |
| 15:50:39 | Zagor | also, i still don't see how having a pointer to ram is complex |
| 15:50:59 | linuxstb | Zagor: Even so, I think we can handle them within the stream concept. We just need an option to the read callback that tells the audio API not to discard the data from the buffer. Normal "streaming codecs" will read and discard, MOD/SID won't. |
| 15:51:21 | Zagor | actually, the streamed concept is identical except you get lots of small buffers instead of one big. |
| 15:51:26 | jyp | Anyways you'll have a certain amount of data not to discard |
| 15:51:30 | jyp | imho |
| 15:51:42 | HCl | CoCoLUS: okay, thanks |
| 15:52:08 | linuxstb | My motivation is to try and keep the codecs simple. |
| 15:52:33 | linuxstb | HCl: No screen output, but I restarted it. Currently up to 170 frames. |
| 15:52:41 | HCl | linuxstb: what rom? mario? |
| 15:52:49 | Zagor | that is a great goal, which I agree with. but what is more complex about having a large buffer instead of a small? |
| 15:53:01 | HCl | its frustrating, it should work, i haven't changed anything that could affect this x.x |
| 15:53:12 | HCl | i might have messed up some endianness |
| 15:53:45 | linuxstb | Zagor: my concept is "no buffer" for the codecs. They just read data from the audio system. |
| 15:53:49 | HCl | let me build a new version.. |
| 15:53:58 | | Join Ka [0] (~tkirk@pcp0010733332pcs.howard01.md.comcast.net) |
| 15:54:03 | linuxstb | HCl: It's "JetPac" |
| 15:54:20 | Zagor | linuxstb: of course you have a buffer. you read data from the audio system into a small buffer, which the codec works on. |
| 15:54:27 | linuxstb | I did run it in earlier versions, and I'm sure there was screen output quite early. |
| 15:54:58 | HCl | or not |
| 15:55:03 | HCl | i'll bbl, battery empty |
| 15:55:05 | HCl | bye |
| 15:55:46 | | Quit Zezayer ("ChatZilla 0.9.61 [Mozilla rv:1.7.2/20040804]") |
| 15:55:50 | linuxstb | Zagor: In the case of MP3, you just request one MP3 frame which is then immediately passed to libmad, or you make use of the codec library's internal buffering. |
| 15:56:25 | linuxstb | i.e. the "wrapper" around libFLAC/libmad/whatever doesn't need to keep its own buffer. |
| 15:56:40 | Zagor | linuxstb: yeah, the buffer is one frame long. that is not simpler, it just means a lot more function calls. |
| 15:58:07 | Zagor | the fact that we'd need two ways of accessing the data speaks against the streaming solution, i think |
| 16:00 |
| 16:00:28 | Zagor | also, how would rockbox know how much data to stream? the codec would have to request first the frame header, decode that and then request the frame data. or? |
| 16:00:36 | | Join muesli- [0] (muesli_tv@1Cust198.tnt10.hnr2.deu.da.uu.net) |
| 16:00:39 | Zagor | (in case of vbr) |
| 16:02:28 | linuxstb | The codec knows how much to ask for. For most codecs, this is handled inside the actually library - libFLAC and Tremor for example use the concept of a read callback., so my reasoning is that it makes sense for our codec API to do the same. |
| 16:02:50 | Zagor | but mp3 can't know - each frame can have different length |
| 16:03:19 | preglow | linuxstb: libmad can do that too |
| 16:03:26 | Zagor | how? |
| 16:03:49 | Zagor | does the read callback _really_ just ask for one frame at a time? |
| 16:04:37 | preglow | its guess is probably better than ours anyway |
| 16:04:42 | linuxstb | We shouldn't care - the codec asks for whatever it needs. |
| 16:05:08 | linuxstb | Which is the whole concept of the read callback. |
| 16:06:22 | preglow | but what's the alternative? that rockbox guesses how much it needs? |
| 16:06:35 | preglow | callback or no, the codec needs to tell how much data it'll like |
| 16:06:48 | Bagder | amiconn: new patch uploaded, I'll be off now for a few hours, but I'll return later tonight |
| 16:07:00 | linuxstb | preglow: Zagor's alternative (IIUC) is to just give the codec access to a very large buffer to do what it likes with. |
| 16:08:16 | preglow | like the main mp3 buffer? |
| 16:08:47 | Zagor | preglow: yes |
| 16:08:54 | preglow | that would be optimal, but it would have to handle wraparound and such |
| 16:09:09 | preglow | we'd get away with no copy, which is a good thing |
| 16:09:24 | Zagor | it doesn't have to handle wraparound. that can be treated as a new buffer. |
| 16:09:47 | Zagor | (i.e. rockbox handles the wraparound) |
| 16:09:47 | preglow | well, sooner or later the data it needs will be situated at the end of ram, and the next part of that data will be some place at the start of it |
| 16:10:06 | preglow | well, we'll need to hack the codecs, then |
| 16:10:09 | preglow | which should be avoided |
| 16:10:23 | preglow | afaik, the codecs depend on getting the amount of data they need |
| 16:10:24 | preglow | nothing less |
| 16:10:50 | Zagor | that's not a problem |
| 16:10:57 | preglow | why not? |
| 16:11:23 | preglow | it requires making the codec load functions able to exit in mid load, which might not always be trivial |
| 16:11:44 | preglow | unless you do a copy anyway, in which case you might as well go with callbacks |
| 16:12:00 | Zagor | it always has to be able to do that - we have limited ram and may not fit the whole song |
| 16:12:08 | | Join izzy [0] (laitinei@huippu.net) |
| 16:12:11 | preglow | you have to buffer in advance |
| 16:12:13 | linuxstb | A read callback would handle wraparound once for all codecs - in the audio system. We wouldn't have to implement those kind of checks for every codec. |
| 16:12:13 | Zagor | so it needs to be able to load part of it |
| 16:12:30 | Zagor | <Zagor> (i.e. rockbox handles the wraparound) |
| 16:12:32 | preglow | Zagor: yes, but it always needs one frame's worth of data |
| 16:12:58 | preglow | if the frame ends halfway through, with the other end lying somewhere in the start of the mp3 buffer, you have a problem |
| 16:13:19 | preglow | afaik, the process that fills the mp3 buffer just reads 'till there's no more space |
| 16:13:24 | preglow | so that might very well happen |
| 16:14:18 | Zagor | of course. i still don't see what the problem is. |
| 16:15:03 | preglow | the problem is that unless you propose you hack the codec itself to handle the wraparound, it won't be able to abort reading the frame just so you can feed it more data |
| 16:15:30 | linuxstb | We have streaming codecs which are a lot more likely to not fit in the available RAM. We then have non-streaming codecs whcih afaik will always fit into the available RAM. IMO we should design the API towards the first case, and deal with the second as a special case. |
| 16:15:30 | preglow | you have to copy the different parts to a new frame buffer, and if you have to do that, what's the point of letting it access the mp3 buffer in the first place? |
| 16:16:05 | | Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) |
| 16:16:13 | Zagor | i prefer to avoid special cases altogether, if possible |
| 16:16:42 | preglow | a pure isstreaming() will do, just to let rockbox know if it has to care about prebuffering |
| 16:16:48 | preglow | has'nt |
| 16:17:06 | Zagor | ? rockbox will always handle prebuffering |
| 16:17:10 | linuxstb | Zagor; I don't see any problems implementing your idea or mine. It's just that for my idea, I think the actual codec implementations will be simpler. |
| 16:17:37 | | Join Zezayer [0] (~zezayer@host81-152-218-69.range81-152.btcentralplus.com) |
| 16:17:55 | preglow | Zagor: yes, but it doesn't need to consistantly keep track of whether the codec needs more data to be able to play the current track |
| 16:18:34 | linuxstb | The only disadvantage of my idea is that it will probably involve more memory copying, but with the advantage of less corner cases to worry about. |
| 16:18:43 | Zagor | preglow: ah, good point |
| 16:18:50 | preglow | Zagor: yes, i think so ;) |
| 16:19:18 | preglow | Zagor: aborting a frame decoder in the middle of huffman decompression, for example, is going to be painful to code |
| 16:19:39 | Zagor | linuxstb: i think we should only copy when necessary, i.e. at wraparound. |
| 16:19:47 | preglow | Zagor: that's a good point |
| 16:20:02 | Zagor | but i'm warming to the idea of having both ways to access data |
| 16:20:08 | preglow | but that only applies if the codec itself knows how long the frame will be |
| 16:20:18 | preglow | i don't know how true that is |
| 16:20:50 | preglow | if not, we have to start copying buffers in advance within a certain threshold of the mp3 buffer end |
| 16:21:08 | linuxstb | Zagor: For libFLAC and Tremor we have to copy the data "into" the codec anyway. They won't work on a pointer to a memory buffer. Other codecs are probably the same. |
| 16:21:09 | preglow | perhaps we can have the codec report max frame size |
| 16:21:23 | preglow | linuxstb: they wont? |
| 16:21:32 | Zagor | linuxstb: sure. but let's not add more copying than necessary. |
| 16:22:37 | linuxstb | preglow: I don't think so. They themselves use a read calllback, thereby forcing you to copy the data to the memory buffer libFLAC/Tremor gives you. |
| 16:22:52 | Zagor | preglow: i think we can define a max guaranteed contigous stream buffer size. |
| 16:23:38 | linuxstb | But of course, this would only happen once - we wouldn't need to copy once from the audio buffer to the "codec wrapper" and then again from the wrapper to the library. The "wrapper" would just forward the read request to the audio system. |
| 16:23:38 | preglow | but anyway |
| 16:23:46 | preglow | before we venture too deeply into this |
| 16:23:46 | | Quit markun () |
| 16:23:58 | preglow | i very much believe the frame data might need to be in sram |
| 16:24:08 | preglow | so a copy might be necessary |
| 16:24:34 | Zagor | what is the max frame size of vorbis and flac? |
| 16:24:44 | preglow | a lot |
| 16:24:52 | Zagor | >32KB? |
| 16:25:11 | preglow | well, both supports very high bitrates, i don't know exact number |
| 16:25:21 | linuxstb | I'm not sure about vorbis, but FLAC is 32K. In practice, FLAC frames are normally 4608 bytes - it's the default encoder setting for all compression levels. |
| 16:25:37 | preglow | frame length for vorbis can be changed by the encoder |
| 16:25:52 | preglow | linuxstb: how long is a flac frame? |
| 16:26:33 | linuxstb | Sorry, I think I'm confusing bytes and samples and compressed/uncompressed frames. Let me double-check. |
| 16:26:42 | Zagor | we don't necessarily have to support obescene worst cases either. i'm guessing many formats have very large theoretical limits that noone ever approaches in real life. |
| 16:27:05 | preglow | agreed |
| 16:27:13 | linuxstb | agreed. :-) |
| 16:30:16 | Zagor | then we can set aside a fixed amount of sram for each codec slot to use as it sees fit. |
| 16:31:09 | | Quit Lurkski (Read error: 60 (Operation timed out)) |
| 16:31:47 | linuxstb | How much sram is there? |
| 16:31:53 | preglow | 96kb |
| 16:32:11 | preglow | Zagor: no, i really think we'll end up using the entire sram for one codec |
| 16:32:21 | preglow | Zagor: at least if we want to obtain at least a semblance of good performance |
| 16:33:05 | preglow | and not using the entire sram when you can would be a huge waste |
| 16:33:19 | Zagor | umm, that means we can only ever have one codec |
| 16:33:25 | preglow | yes, at a time |
| 16:33:30 | linuxstb | That's going to take a lot of hacking into the codecs as well. |
| 16:33:32 | preglow | they will have to be swapped in and out |
| 16:33:59 | Zagor | that's really not what we want. but let's want and see what's possible first. |
| 16:34:04 | preglow | sure |
| 16:34:06 | Zagor | s/want/wait/ |
| 16:34:22 | preglow | but if we don't do it that way, we'll have to work wonders in size optimizing |
| 16:34:41 | linuxstb | All the codecs use lots of lookup tables - maybe it would just be enough to copy those into the sram. |
| 16:34:46 | | Join methangas [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk) |
| 16:34:56 | preglow | linuxstb: yes, and very probably some important code |
| 16:35:09 | preglow | linuxstb: like the lpc decoder in flac, and synth_full and imdct in libmad |
| 16:35:37 | preglow | but reserving space for all possible decoders would be stupid, imho, worst case there should be room for two, but not all |
| 16:35:53 | Zagor | not all possible codecs. all slots. |
| 16:36:08 | preglow | ahh, i'm not into the slot thing |
| 16:36:10 | Zagor | proposed default: 2 |
| 16:36:15 | preglow | then we agree once more |
| 16:37:43 | | Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) |
| 16:38:22 | | Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) |
| 16:39:14 | G | wtf R3nTiL ? |
| 16:39:47 | linuxstb | So where are we in the "read callback" vs "direct buffer access" discussion? |
| 16:39:59 | * | [IDC]Dragon hasn't read the full codec discussion backlog, but may add $0.02 |
| 16:40:10 | | Nick G is now known as thegeek_ (na@ti521110a080-0418.bb.online.no) |
| 16:40:11 | Zagor | linuxstb: I think I'd like both |
| 16:40:18 | [IDC]Dragon | I know DirectShow |
| 16:40:39 | [IDC]Dragon | and some proprietary multimedia architectures |
| 16:40:39 | preglow | btw, putting the frame in sram might be unnecessary after all, it's probably used sequantially |
| 16:41:00 | [IDC]Dragon | is DS, the work is split into a parser and a decoder |
| 16:41:07 | [IDC]Dragon | in |
| 16:41:33 | [IDC]Dragon | the parser understands the file format and pumps the data |
| 16:42:05 | [IDC]Dragon | the decoder receives a stream (normally), and pushes decoded data |
| 16:42:26 | [IDC]Dragon | the full output buffer will then stall the process |
| 16:42:27 | | Quit R3nTiL () |
| 16:42:30 | | Quit thegeek_ ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") |
| 16:42:46 | Zagor | [IDC]Dragon: yes, that's how we'll do it too. the codec first reads the file and puts data in ram, then (another funcion) decodes data from ram and produces pcm samples |
| 16:44:02 | linuxstb | But we also have the large buffer in the middle to deal with, and disk spinups to minimise. I think that's where views are differing. |
| 16:44:29 | [IDC]Dragon | spinups are a new concept to these architectures |
| 16:44:35 | Zagor | i thought we were finally agreeing :-) |
| 16:45:02 | linuxstb | Zagor: I don't think we're too far apart :-) |
| 16:45:44 | preglow | but you talk about accepting both methods now, and i don't really think they're mergeable, heh |
| 16:45:49 | [IDC]Dragon | another idea I once had is to use the bib buffer as a "plain" disk cache |
| 16:45:56 | preglow | it's either callback or no callback |
| 16:46:05 | preglow | not using a copy buffer all the time is agreed upon |
| 16:46:13 | preglow | in the case of a callback, we have to copy |
| 16:46:15 | [IDC]Dragon | and read ahead as much as possible without trashing some to-be-used data |
| 16:46:18 | Zagor | preglow: we can have two functions: give_me_x_bytes() or give_me_buffer() |
| 16:47:04 | Zagor | [IDC]Dragon: the problem with that is we risk caching a lot of useless data. such as album art or video data. |
| 16:47:16 | | Join G [0] (na@ti521110a080-0418.bb.online.no) |
| 16:47:30 | [IDC]Dragon | no, cache only the data you're about to read |
| 16:47:34 | amiconn | Zagor: I think the percentage of useless data is low |
| 16:47:53 | Zagor | amiconn: on average, yes. but why cache it? |
| 16:48:14 | Zagor | [IDC]Dragon: how do we know which data we're about to read? imagine playing sound off a dvd image. |
| 16:48:19 | amiconn | Um, because it makes the whole caching a lot simpler? Thinking KISS... |
| 16:48:37 | Zagor | simple but inefficient |
| 16:48:45 | [IDC]Dragon | Zagor: the same way we do now: read ahead in the playlist |
| 16:49:00 | Zagor | today we parse the file and only cache useful data |
| 16:49:01 | amiconn | Zagor: I think the"sound from a dvd image" is a *very* exotic example |
| 16:49:24 | [IDC]Dragon | ok, now I get you |
| 16:49:42 | linuxstb | amiconn: I agree with you AND Zagor :-). i.e. we should think of that as an optimisation. i.e. we don't have to worry about it if it is too much work to implement, but we should give the codecs the opportunity to say "that 500K of data is useless, don't bother to read it from disk". |
| 16:50:04 | Zagor | amiconn: i agree. but caching "blindly" doesn't really make things much simpler. the codec needs to parse the container format anyway. why not doing it while loading instead of while decoding? |
| 16:50:25 | amiconn | That means the codec is involved twice, at very differing points of time. |
| 16:50:42 | [IDC]Dragon | parsing and decoding |
| 16:50:49 | Zagor | yes, but that is no disadvantage. the spinup is already happening. |
| 16:50:59 | amiconn | First, when it comes to read data into the buffer, then when actual decoding takes place |
| 16:51:12 | amiconn | That may mean to holding many codecs in ram... |
| 16:51:27 | [IDC]Dragon | the parser may be re-used |
| 16:51:30 | Zagor | no. please read the log. we've been through this already :-) |
| 16:51:32 | [IDC]Dragon | like for AVI |
| 16:51:50 | [IDC]Dragon | sorry |
| 16:52:29 | Zagor | we started about 12:00 |
| 16:52:50 | Zagor | 12:46 to be exact |
| 16:55:38 | amiconn | Either holding many codecs, or frequently swapping in/ out, which might be necessary between refills (!) |
| 16:55:45 | linuxstb | Zagor: You mention disk spinup as the only cost - is CPU time spent parsing the data also not a significant cost? Especially if the codec is also trying to decode a file at the same time. |
| 16:56:21 | Zagor | parsing is generally not a cpu-intensive process. the formats are designed to be read with minial effort. |
| 16:56:31 | CoCoLUS | HCl? |
| 16:57:12 | linuxstb | But at the moment it looks like we will need every possible CPU cycle just to decode the audio. |
| 16:57:19 | amiconn | Zagor: Imagine one starts playig an mp3 file, which is followed by an ogg, which is followed by a flac, then an mp2. Let's say all these fit in the main buffer, then you need to swap codecs if you only have 2 slots.... |
| 16:57:40 | Zagor | linuxstb: indeed, but the parsing has to be done. it's not more efficient to do it later than sooner |
| 16:57:56 | Zagor | amiconn: yes. so we don't load all of them. |
| 16:58:04 | amiconn | ??? |
| 16:58:27 | amiconn | That would be even worse, imho. Not using the whole buffer we have to spare... |
| 16:58:40 | linuxstb | amiconn: you would still need the same number of disk spinups (to load codec plugins) - it's just that each one would read less data. So in that case I don't think it 'matters if the buffer is half empty. |
| 16:58:47 | *** | Saving seen data "./dancer.seen" |
| 16:58:50 | Zagor | read the log. there is no gain reading data you can't parse without another spinup. |
| 16:59:42 | Zagor | I'm afraid I have to go now. See you guys later. |
| 16:59:46 | | Quit Zagor ("Client exiting") |
| 17:00 |
| 17:01:35 | amiconn | I still wonder if it would be better to build all codecs into rockbox after all... |
| 17:02:41 | dwihno | how about similar units with less RAM? |
| 17:02:54 | dwihno | I mean with a "generic" pcm driver |
| 17:03:05 | dwihno | and how about playback buffer? |
| 17:03:23 | linuxstb | amiconn: Yes, that's an option, but it would be nice to not have to limit the number of supported codecs. |
| 17:05:52 | jyp | Indeed, I'd like (at least part of) the codecs to be built in, since gmini has only 16k |
| 17:06:02 | jyp | of code ram |
| 17:06:43 | linuxstb | jyp: Doesn't a limited amount of RAM imply a bigger need to have external, loadable plugins? |
| 17:07:02 | dwihno | I'm with linuxstb |
| 17:07:17 | dwihno | Having everything as plugins has its pro's |
| 17:07:28 | dwihno | Maximized playback buffer, for once |
| 17:07:37 | linuxstb | Or is it a case of so little memory, that the overhead of plugins is the problem. |
| 17:07:39 | jyp | That's fine as long as they are around 10k large |
| 17:08:15 | preglow | jyp: you've really got some nice limits going there |
| 17:09:05 | dwihno | jyp: how big are the plugins atm? |
| 17:09:21 | jyp | They aren't compiled atm ;) |
| 17:09:26 | dwihno | they aren't? |
| 17:09:32 | dwihno | boooo! :) |
| 17:09:35 | jyp | They aren't. |
| 17:10:40 | dwihno | booo! |
| 17:10:40 | dwihno | :) |
| 17:11:14 | amiconn | dwihno: The problem with the CalmRISC16 cpu core used in the gmini is that it is a harvard architecture, and the code address space is mapped to the flash only, except the tiny internal sram of the cpu |
| 17:11:58 | amiconn | Imho it is impossible to support plugins on that. All plugins need to be compiled in |
| 17:12:27 | jyp | My thinking too |
| 17:13:00 | amiconn | So for gmini, having all supported codecs builtin is actually a requirement... |
| 17:13:01 | [IDC]Dragon | is the flash sectored? |
| 17:13:11 | jyp | yes |
| 17:13:35 | dwihno | amiconn: aaah, that's sucky :/ |
| 17:13:37 | [IDC]Dragon | so you could swap the plugin |
| 17:13:40 | amiconn | [IDC]Dragon: You don't propose swapping plugins in & out by flashing, do you? |
| 17:13:48 | [IDC]Dragon | I do, yes |
| 17:13:51 | | Quit Lurkski (Read error: 110 (Connection timed out)) |
| 17:13:57 | G | humhum |
| 17:14:00 | | Nick G is now known as thegeek (na@ti521110a080-0418.bb.online.no) |
| 17:14:01 | | Nick thegeek is now known as thegeek_ (na@ti521110a080-0418.bb.online.no) |
| 17:14:23 | jyp | Problem is the flash supports only 100000 erases |
| 17:15:05 | jyp | (typical) |
| 17:15:23 | [IDC]Dragon | for plugins, this may be sufficient |
| 17:15:44 | [IDC]Dragon | the Odio flash has a similar rating, iirc |
| 17:16:04 | jyp | Are you using this method on the ondio too ? |
| 17:16:13 | amiconn | jyp: No |
| 17:16:16 | [IDC]Dragon | I meant the mass storage |
| 17:16:35 | * | preglow hugs his h120 |
| 17:16:52 | jyp | Ok, so the plan would be to flash the plugins independantly... |
| 17:16:55 | jyp | That's fine |
| 17:16:56 | amiconn | [IDC]Dragon: Yes, but for the mass storage, we're trying to keep the flash wear ing low |
| 17:17:39 | [IDC]Dragon | still, all the root file or fat modifications flash certain regions again and again |
| 17:18:47 | jyp | It's just as fine to flash the plugins separately, otho, why not have them compiled in ? |
| 17:19:10 | [IDC]Dragon | if it fits, ok |
| 17:19:19 | [IDC]Dragon | how big is your flash? |
| 17:19:49 | jyp | 1Mo, for the models examined |
| 17:19:58 | jyp | maybe 512k on others |
| 17:20:00 | * | [IDC]Dragon doubts he'll ever start 100000 plugins |
| 17:20:30 | jyp | We'd have a "plugin cache" anyways. |
| 17:21:50 | jyp | I'm begging to find this idea very interesting ;) |
| 17:21:55 | jyp | beggining |
| 17:22:11 | [IDC]Dragon | didn't Archos sell plugins for the Gmini? |
| 17:22:18 | HCl | back |
| 17:22:32 | jyp | planned (rumors says), but never done |
| 17:22:44 | [IDC]Dragon | no, they do |
| 17:22:53 | jyp | ah? |
| 17:22:54 | [IDC]Dragon | how's that done, technically? |
| 17:23:07 | jyp | What do you mean ? |
| 17:23:22 | [IDC]Dragon | my Archos contact told me they made a *lot* of money from Gmini plugins |
| 17:23:59 | jyp | What do you mean, technically? |
| 17:24:08 | [IDC]Dragon | are they always in, and just enabled, or how do they load code? |
| 17:24:38 | [IDC]Dragon | this was your problem, if you remember, harvard and stuff |
| 17:24:50 | jyp | heh ;) |
| 17:24:59 | dwihno | I think it's sucky. First of all, charging a lot of money for a unit with firmware, and then charging ADDITIONAL for features that should be built in! |
| 17:25:18 | [IDC]Dragon | tell that to M$ |
| 17:25:31 | jyp | My idea is that "plugins" were a complete new firmware with additional features |
| 17:26:00 | jyp | In all the code I've revered, not a single trace of "loadable" plugins |
| 17:26:05 | [IDC]Dragon | maybe |
| 17:26:09 | jyp | reversed |
| 17:27:41 | jyp | There's is, however, a certain type of upgrade |
| 17:27:59 | jyp | that checked the HD serial number |
| 17:28:20 | [IDC]Dragon | that sounds like it |
| 17:28:39 | [IDC]Dragon | the plugins were somehow bound to the box |
| 17:28:49 | jyp | besides that is was a normal flash |
| 17:29:01 | jyp | hence my previous hypothesis |
| 17:29:40 | jyp | They sold complete firmwares with plugins compiled in. |
| 17:29:59 | [IDC]Dragon | then there must be a user option to extract that number |
| 17:30:07 | jyp | yup, there is |
| 17:30:14 | [IDC]Dragon | to give Archos, when buying a "plugin" |
| 17:30:23 | jyp | splled out in the system menu |
| 17:30:45 | jyp | and in a file on the hd |
| 17:31:46 | [IDC]Dragon | now you want the file of a "loaded" box, eh? |
| 17:32:26 | jyp | I think I can get away without it |
| 17:33:44 | jyp | On a different subject; let's say I want to dump a debugging trace in a file |
| 17:33:52 | jyp | how should I do it ? |
| 17:34:40 | jyp | (on the target of course) |
| 17:35:28 | jyp | Is there some kind of "fprintf" ? |
| 17:35:30 | HCl | oi. |
| 17:35:31 | HCl | bug. |
| 17:35:42 | HCl | no wonder rockboy choked >.> |
| 17:35:59 | jyp | mmm, looks like I found it ;) |
| 17:36:38 | HCl | yea, there is |
| 17:39:07 | | Quit muesli- (Read error: 113 (No route to host)) |
| 17:42:51 | HCl | finally, stupid endian problems |
| 17:43:58 | | Quit Patr3ck_ ("User pushed the X - because it's Xtra, baby") |
| 17:44:38 | jyp | gotta go |
| 17:44:48 | | Quit jyp ("poof!") |
| 17:45:46 | * | HCl goes to eat dinner |
| 18:00 |
| 18:02:05 | | Join muesli- [0] (muesli_tv@1Cust121.tnt3.hnr2.deu.da.uu.net) |
| 18:14:19 | | Join hubble [0] (hubble@h13n1fls302o1033.telia.com) |
| 18:14:20 | | Quit muesli- (Read error: 54 (Connection reset by peer)) |
| 18:16:31 | | Join iSheep [0] (~a@dpc691997050.direcpc.com) |
| 18:16:39 | iSheep | Hi guys |
| 18:17:51 | iSheep | My FM Recorder (with the original Archos firmware) is hanging on startup, stopping midway through the process and then eventually shutting down. Anyone ever encounter this? |
| 18:23:57 | | Quit bobTHC ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") |
| 18:28:59 | | Join muesli- [0] (muesli_tv@1Cust225.tnt8.hnr2.deu.da.uu.net) |
| 18:42:00 | | Quit AC ("CGI:IRC (EOF)") |
| 18:43:03 | | Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) |
| 18:43:42 | Lurkski | playing with a new client....can anyone see this? |
| 18:44:04 | rasher | Sure |
| 18:44:17 | amiconn | [IDC]Dragon: r u there? |
| 18:44:44 | Lurkski | cool....thanks rasher.....just had to make sure firewall was not mesing things up again. LAter guys |
| 18:45:41 | | Part Lurkski |
| 18:50:49 | amiconn | Bagder: r u around? |
| 18:54:52 | HCl | back |
| 18:58:40 | [IDC]Dragon | amiconn: now I've looked |
| 18:58:49 | *** | Saving seen data "./dancer.seen" |
| 18:59:58 | amiconn | I did now implement the loader for rockboy the way I already explained. However, I wonder if it would be possible/ make sense to write an .elf loader as a plugin... |
| 19:00 |
| 19:00:37 | [IDC]Dragon | hmm, I once messed with elf |
| 19:00:55 | * | [IDC]Dragon tries to remember |
| 19:01:49 | [IDC]Dragon | hehe, you could make your loader a viewer for .elf |
| 19:02:28 | amiconn | Hmm. That might be possible, but it wouldn't be useful for rockboy. Rockboy is a viewer by itself... |
| 19:02:34 | | Quit muesli- (Read error: 110 (Connection timed out)) |
| 19:02:51 | [IDC]Dragon | ah, yes |
| 19:03:07 | * | [IDC]Dragon digs in old sources |
| 19:04:24 | amiconn | Imho there are 2 main problems: (1) Would an .elf loader fit in the plugin space, even leaving some buffer and (2) is it possible to do .elf handling chunked, without the need to load the whole .elf at once? |
| 19:05:03 | amiconn | That means, load the .elf bit by bit and directly link into the target ram area |
| 19:05:23 | [IDC]Dragon | I'd say this is unnecessary complex, but still searching... |
| 19:06:01 | | Join Stryke` [0] (~Chairman8@resnet-241-86.resnet.UMBC.EDU) |
| 19:06:02 | amiconn | Yes, it is not absolutely necessary, but at least I would like to know if it's prossible |
| 19:06:46 | amiconn | *possible |
| 19:07:18 | [IDC]Dragon | I used some open source code to review an elf |
| 19:07:30 | [IDC]Dragon | ... still searching... |
| 19:08:26 | [IDC]Dragon | perhaps it was elfdump |
| 19:09:14 | | Join MO-Pantsu [0] (Rori@deadman3000.plus.com) |
| 19:09:42 | [IDC]Dragon | once I went in an elf hexdum "by hand", but this was no fun |
| 19:10:39 | [IDC]Dragon | look here: http://elfio.sourceforge.net/index.php |
| 19:11:17 | [IDC]Dragon | yuck, c |
| 19:11:24 | [IDC]Dragon | C plusplus |
| 19:11:48 | [IDC]Dragon | cgiirc refuses 'plus' characters |
| 19:13:30 | rasher | hah |
| 19:16:34 | | Join XShocK [0] (~XShocK@pcp09492659pcs.nrockv01.md.comcast.net) |
| 19:19:52 | preglow | XShocK: any luck on dma? :P |
| 19:21:36 | amiconn | HCl: Does your cpu memory variable->cpu reg transition work now? |
| 19:21:59 | | Quit iSheep () |
| 19:23:53 | | Quit Schnueff ("leaving") |
| 19:25:40 | [IDC]Dragon | amiconn: I found my elfdump, it is ansi c |
| 19:26:36 | | Quit DeadMan (Read error: 110 (Connection timed out)) |
| 19:27:38 | [IDC]Dragon | now trying to tell where I fond it |
| 19:28:25 | HCl | amiconn: uh, i don't quite get what you meant with that XD |
| 19:28:41 | HCl | but yea, i altered the gameboy register memory layout, and its now suitable for dynarec |
| 19:29:31 | amiconn | HCl: I mean, you tried to change the gbz80 register layout in order to be able to hold them in host registers during execution of cpu_emulate() |
| 19:29:39 | HCl | yea. |
| 19:29:48 | HCl | here's my memory layout as it is at the moment: |
| 19:30:01 | amiconn | I think that if you can get dynarec to work, I might be able to adapt this for sh1 |
| 19:30:09 | HCl | registers a-e in 32bit vars, flags in 32 bit var, hl in 32 bit var |
| 19:30:27 | HCl | since hl is mostly used as an a# register, its more sensible to not split them up |
| 19:30:43 | XShocK | preglow: no, couldn't make DMA work right |
| 19:31:05 | amiconn | HCl: Both host cpus are not too different. (1) 16 registers, with the 16th being the stack pointer. (2) big endian |
| 19:31:15 | HCl | it nicely leaves me with 1 data register to still use |
| 19:31:28 | HCl | unless i put HL in an address register |
| 19:31:48 | amiconn | Sh1 is a bit more flexible, because there is no difference between address and data registers |
| 19:32:25 | preglow | amiconn: most instructions let you use both with the coldfire as well |
| 19:32:46 | amiconn | preglow: Yes, I know. As you said, most, but not all |
| 19:33:09 | amiconn | But there are some limitations of that kind on the sh as well |
| 19:33:28 | HCl | yea, definately more flexible |
| 19:33:34 | HCl | a# registers are really limited |
| 19:33:37 | amiconn | There are r0..r15, but some ops are only possible using r0 |
| 19:33:49 | HCl | sounds mips like. |
| 19:33:59 | HCl | only mips4 has r0 hardwired to 0 |
| 19:35:15 | preglow | haha |
| 19:41:02 | | Part hubble |
| 19:44:16 | | Join funkymonkey [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk) |
| 19:44:16 | | Quit methangas (Read error: 104 (Connection reset by peer)) |
| 19:46:39 | | Quit funkymonkey (Read error: 104 (Connection reset by peer)) |
| 19:51:36 | | Join methangas [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk) |
| 19:52:59 | | Join Sucka [0] (~NNSCRIPT@host81-156-213-142.range81-156.btcentralplus.com) |
| 19:59:53 | | Quit courtc (Read error: 110 (Connection timed out)) |
| 20:00 |
| 20:02:53 | | Join muesli- [0] (muesli_tv@Bbc7c.b.pppool.de) |
| 20:11:04 | | Join jyp [0] (~jp@111-103.245.81.adsl.skynet.be) |
| 20:17:05 | * | Bagder appears |
| 20:19:42 | amiconn | hi again Bagder |
| 20:19:49 | | Quit muesli- (Read error: 60 (Operation timed out)) |
| 20:19:58 | Bagder | where did the latest patch error out? |
| 20:20:42 | amiconn | The latest patch needs one slight change, then it compiles with a few warnings. |
| 20:20:50 | Bagder | aha |
| 20:20:57 | Bagder | yes, it did introduce a few new warnings |
| 20:21:06 | amiconn | However, it does not link at all, as the x11 sim compiled on cygwin |
| 20:21:11 | Bagder | and I haven't verified functionality properly yet |
| 20:21:17 | Bagder | ok |
| 20:21:25 | Bagder | so what's the needed change? |
| 20:21:38 | Bagder | I mean for the error |
| 20:22:37 | amiconn | In uisimulator/common/io.c, the mkdir call (line 194) must not use the #ifdef. It is return (mkdir)(buffer, 0666); for win32 on cygwin as well |
| 20:23:03 | amiconn | I got "too few arguments...." before I changed that |
| 20:23:30 | amiconn | Btw, why are some function calls enclosed in parentheses there? |
| 20:23:46 | Bagder | because of weirdo sim-#defines from the past |
| 20:23:53 | Bagder | shouldn't be necessary anymore |
| 20:23:55 | amiconn | AH, so this may go away |
| 20:24:00 | Bagder | yeps |
| 20:24:22 | amiconn | The linker throws a heapload of unresolved symbols... |
| 20:24:42 | Bagder | do you have an older CVS around to compare link command line with? |
| 20:24:57 | amiconn | No I don't |
| 20:25:02 | Bagder | ok |
| 20:25:37 | amiconn | I keep forgetting the correct command line to do a dated checkout... |
| 20:26:26 | Bagder | cvs update -D "date" |
| 20:26:26 | Bagder | I think |
| 20:28:01 | * | amiconn fetches cvs as of Feb 16 |
| 20:29:09 | | Join Strath [0] (~mike@dgvlwinas01pool0-a239.wi.tds.net) |
| 20:33:30 | amiconn | Bagder: I need to remove the '@' in front of the command call from the Makefile in order to see the line, right? |
| 20:33:39 | Bagder | yeps |
| 20:39:18 | Bagder | are you making one with the latest too? |
| 20:39:47 | | Nick Sucka is now known as Sucka`away (~NNSCRIPT@host81-156-213-142.range81-156.btcentralplus.com) |
| 20:40:04 | amiconn | Just a second; currently doing the same for X11 simulator & old cvs |
| 20:40:16 | Bagder | ok, that's useful too of course |
| 20:40:48 | * | Bagder walk away for 5 mins |
| 20:40:51 | Bagder | walks |
| 20:47:05 | | Part CoCoLUS |
| 20:49:17 | | Join _CoCoLUS [0] (~coco@h081217139221.dyn.cm.kabsi.at) |
| 20:51:05 | amiconn | Bagder: The x11 build now errors out in plugin.c. And maybe the win32build.log you got is mixed up. You client sent a strange resume request when I dcc'd the logfile |
| 20:53:11 | Bagder | can you understand why it complains on fdprintf() ? |
| 20:55:13 | Bagder | and for the link problems, can you try removing "-fno-builtin" from the Makefile in the build dir |
| 20:56:33 | amiconn | ah, the fdprintf thing maybe because I forgot to reconfigure, lemme check |
| 20:57:13 | amiconn | I reconfigured today, but maybe that was before another change to configure... |
| 20:58:09 | Bagder | I doubt that |
| 20:58:48 | Bagder | but try a make clean first |
| 20:58:52 | *** | Saving seen data "./dancer.seen" |
| 20:58:54 | Bagder | just in case |
| 20:59:36 | amiconn | That was indeed the problem, now X11 is on par with win32 - linker errors |
| 20:59:55 | amiconn | Again a resume request... |
| 21:00 |
| 21:00:39 | Bagder | that might be because I overwrite a previous file with the same name |
| 21:01:02 | Bagder | I don't get it |
| 21:01:12 | Bagder | why doesn't fdprintf() exist as a function in plugin.c ? |
| 21:01:21 | amiconn | It does now. |
| 21:01:22 | HCl | fprintf does. |
| 21:01:38 | Bagder | hm |
| 21:01:53 | Bagder | amiconn: then please resend the log ;-) |
| 21:02:07 | Bagder | HCl: not here, it is fdprintf() in my pending patch ;-) |
| 21:02:16 | HCl | mhm :p |
| 21:02:31 | | Nick _CoCoLUS is now known as CoCoLUS (~coco@h081217139221.dyn.cm.kabsi.at) |
| 21:03:05 | Bagder | try removing "-fno-builtin" from the Makefile in the build dir |
| 21:04:19 | amiconn | Huh? The linker options for the Win32 sim seem to be those that are intended to build the X11 simulator ???? |
| 21:04:35 | amiconn | export LDOPTS=-L/usr/X11R6/lib -lSM -lICE -lXt -lX11 -lXmu -lSM -lICE -lX11 -lpthread |
| 21:04:52 | Bagder | hm, you're right |
| 21:05:43 | Bagder | how silly |
| 21:08:22 | | Join pillo [0] (~burellil@adsl-ull-175-133.47-151.net24.it) |
| 21:09:05 | | Quit preglow ("n00bix") |
| 21:10:10 | Bagder | amiconn: ok, there's a -6 patch uploaded now |
| 21:10:21 | Bagder | requires a reconfigure |
| 21:11:28 | | Join preglow [0] (thomj@s183a.studby.ntnu.no) |
| 21:16:13 | | Quit rasher (Read error: 54 (Connection reset by peer)) |
| 21:16:17 | amiconn | Bagder: Now the mkdir() call has too many arguments... |
| 21:16:27 | Bagder | hahaha |
| 21:16:45 | Bagder | I think I know why |
| 21:16:46 | amiconn | Maybe some option is set differently in the makefile, making cygwin require the other syntax? |
| 21:16:51 | Bagder | yes |
| 21:16:55 | Bagder | -DNOCYGWIN I believe |
| 21:17:13 | Bagder | I added it now, since it was in the old one but not previously in the new |
| 21:17:34 | amiconn | The -Dno-cygwin is there to create standalone Win32 binaries that don't require the cygwin.dll |
| 21:17:50 | Bagder | yes |
| 21:17:58 | Bagder | but we don't care much about that |
| 21:18:02 | amiconn | This is desired for the win32 sim, otherwise it's not possible to lauch it by double-clicking |
| 21:18:08 | Bagder | aha |
| 21:18:58 | amiconn | I'll re-add the #ifdef... |
| 21:19:00 | Bagder | so perhaps we should put the mkdir back again then |
| 21:19:30 | | Join hubble [0] (hubble@h13n1fls302o1033.telia.com) |
| 21:21:41 | amiconn | Bagder: Hmm, still doesn't link... |
| 21:21:49 | | Join rashur [0] (~rasher@62.79.64.148.adsl.hs.tiscali.dk) |
| 21:22:06 | amiconn | Did you put the old log away? |
| 21:22:16 | Bagder | no, its still here |
| 21:23:03 | * | amiconn wants to send new log... |
| 21:23:16 | Bagder | wait, I notice a bug |
| 21:25:16 | Bagder | ok, beam it over |
| 21:27:07 | amiconn | Btw, the conditional defines at the top of firmware/include/file.h could be made unconditional, cause they are used by rockbox code only, or a I wrong? |
| 21:27:14 | amiconn | *am I wrong? |
| 21:27:56 | Bagder | yes they are |
| 21:28:20 | amiconn | Hmm. There is an #include <sys/types.h> at the top. Is this correct? |
| 21:28:28 | Bagder | I added such a file |
| 21:28:33 | amiconn | Ah. |
| 21:28:42 | Bagder | for size_t, off_t etc |
| 21:28:58 | Bagder | got bored by having to include file.h to get them |
| 21:29:21 | amiconn | Hmm. The defines therein could also be made unconditional (?) |
| 21:29:34 | Bagder | doesn't windows have a fsync() function ? |
| 21:29:52 | Bagder | amiconn: should be possible, yes, but I'm waiting with the beautifying things |
| 21:30:21 | amiconn | Okay, was just asking (partly myself) whether I understand what's going on... |
| 21:31:40 | amiconn | Shouldn't this read sim_fsync for simulator builds? |
| 21:32:02 | Bagder | yes, if we need to replace it |
| 21:32:07 | Bagder | which we seem to need |
| 21:32:49 | amiconn | Hmm. How is this handled in the old cvs build? |
| 21:33:33 | hubble | wow.. cool.. wav working |
| 21:33:42 | Bagder | amiconn: I don't really know why it works in the old one |
| 21:33:52 | amiconn | #ifdef WIN32 |
| 21:33:52 | amiconn | #define fsync _commit |
| 21:33:52 | amiconn | #endif |
| 21:33:58 | Bagder | aha |
| 21:34:07 | hubble | how's the codec-interface going? |
| 21:34:12 | amiconn | (that's from the old uisimulator/common/file.h) |
| 21:34:34 | amiconn | This seems to also use/need: |
| 21:34:34 | amiconn | #ifdef WIN32 |
| 21:34:35 | amiconn | #ifndef _commit |
| 21:34:35 | DBUG | Enqueued KICK amiconn |
| 21:34:35 | amiconn | extern int _commit( int handle ); |
| 21:35:24 | linuxstb | hubble: Read today's IRC log. I don't think anyone's coded anything yet (apart from what's in CVS). |
| 21:35:47 | hubble | linuxstb: ok.. i guess wiki is not updated? |
| 21:35:49 | Bagder | amiconn: I'm moving that to uisim/common/io.c and adding sim_fsync() there |
| 21:35:58 | amiconn | Okay. |
| 21:37:12 | amiconn | Then you don't need the define, but simply the commit() call iiuc |
| 21:37:24 | Bagder | yes |
| 21:38:08 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 21:38:08 | * | HCl suddenly realizes a fundemental flaw and why rockboy was crashing |
| 21:38:17 | Bagder | amiconn: uploading another version now |
| 21:38:30 | HCl | mental note; never forget to clear newly allocated ram |
| 21:39:41 | pillo | yeah that's quite a GoodThing(tm) ;) |
| 21:39:58 | | Join Chamois [0] (~52e2b617@labb.contactor.se) |
| 21:42:20 | | Join ghode|afk [0] (dude@host217-137-6-24.no-dns-yet.ntli.net) |
| 21:42:27 | amiconn | Bagder: Link problem with fsync() now gone. The other link problems are still there... |
| 21:42:47 | amiconn | I don't get why this doesn't want to link with windows native functions... |
| 21:43:02 | ghode|afk | preglow: err hi, wondering if there is any update on the windows firmware patcher you were working on? |
| 21:43:39 | Bagder | no, that's weird |
| 21:44:34 | amiconn | Hmm. Maybe the windows libs must be put after rockbox' own libs? |
| 21:44:51 | Bagder | perhaps |
| 21:44:52 | Chamois | i read wav works |
| 21:45:01 | amiconn | I once had the same problem, obviously the order of -l options is sometimes important |
| 21:45:02 | Chamois | sound works on iriver ? |
| 21:45:13 | preglow | ghode|afk: no, not really, it kind of works, but i don't urgently work on it, 'cause it's still a while to go before rockbox is release ready |
| 21:45:28 | Bagder | amiconn: yes, in not always so obvious ways |
| 21:45:55 | ghode|afk | ok thanks |
| 21:46:06 | amiconn | The old build put -lgdi32 -luser32 -mno-cygwin at the very end of the line... |
| 21:46:13 | * | ghode|afk goes back to reading irc logs. |
| 21:46:18 | | Quit ghode|afk (Client Quit) |
| 21:48:04 | Bagder | amiconn: edit apps/Makefile (line 107) and move $(LDOPTS) to the end of the link line |
| 21:49:29 | amiconn | I moved it behind -lcomsim, this should be sufficient... |
| 21:49:37 | Bagder | yeps |
| 21:49:56 | pillo | slightly ot: how do I tell vim to read the "vim special tags" in the files (such as /*vim: et sw=4 ts=8 sts=4 tw=78*/)? |
| 21:50:22 | * | Bagder uses emacs! |
| 21:50:42 | * | pillo loves that sweet :wq ;) |
| 21:52:09 | XShocK | came back home |
| 21:52:30 | hubble | XShocK: i got wav loading and playing from your code now =) |
| 21:52:31 | linuxstb | jyp: Are you around? |
| 21:52:36 | amiconn | Bagder: The link problems with the various gdi functions are solved by that. However, it still errors on undefined references to _LoadLibrary / FreeLibrary .... |
| 21:52:46 | XShocK | hubble: good. :) |
| 21:52:48 | hubble | XShocK: where did you get "*((&INTBASE)+8) = 72;" from and is it important? |
| 21:52:49 | | Join courtc [0] (~court@adsl-158-8-175.asm.bellsouth.net) |
| 21:53:20 | XShocK | Secondary Interrupt 8, AUDIOTICK vector set to 72. |
| 21:53:44 | amiconn | Bagder: Maybe the plugin_load functions also need sim_ implementations? Maybe a proper windows header needs to be included for these functions... |
| 21:53:54 | jyp | linuxstb: I'm here |
| 21:54:04 | jyp | for 1 hour maybe |
| 21:54:04 | Bagder | amiconn: I was just thinking in those lines too |
| 21:54:04 | hubble | XShocK: where did you read that you could set that number? i didnt find it in the docs |
| 21:54:14 | amiconn | Bagder: Want the log? |
| 21:54:17 | Chamois | how many time for wav in cbs ? |
| 21:54:21 | Chamois | *CVS |
| 21:54:27 | Bagder | amiconn: nah, not needed for this |
| 21:54:30 | XShocK | i will look it up now |
| 21:54:47 | linuxstb | jyp: I think your CVS change has broken libFLAC. |
| 21:55:27 | * | Bagder walks away for a while |
| 21:55:32 | linuxstb | That "realloc" is needed to allocate memory for the seektable - so a NULL pointer is now dereferenced. |
| 21:55:47 | jyp | linuxstb: mmm; I didn't intend to commit anything regarding libFLAC |
| 21:55:50 | XShocK | hubble: 9.4.2.2 |
| 21:55:54 | amiconn | Bagder: Same goes for the GetProcAddress warning... |
| 21:56:07 | linuxstb | It's the latest CVS change - "typo" was your log message :-) |
| 21:56:15 | XShocK | hubble: of User Manual |
| 21:56:28 | linuxstb | At 11.59 GMT today. |
| 21:56:58 | jyp | damn, I comitted the wrong file |
| 21:57:14 | linuxstb | No problem. Is there an easy way to reverse it? |
| 21:57:21 | jyp | I guess |
| 21:57:23 | XShocK | hubble: it says that RESET values of vectors are 0 initially, and i don't think there is any other way hardware of firmware set those things by itself. |
| 21:57:34 | hubble | XShocK: aha, i though you only could set the INTBASE byte, not that it was an entire array =)) |
| 21:57:41 | XShocK | *hardware or firmware :) |
| 21:57:54 | XShocK | :) |
| 21:59:38 | hubble | XShocK: so we can skip to set the INTBASE byte only to set the AUDIOTICKS? |
| 22:00 |
| 22:00:42 | XShocK | hubble: repeat, i didn't understand what you said. |
| 22:01:28 | linuxstb | jyp: Shall I reverse your commit or will you? |
| 22:01:40 | jyp | I'm looking into it |
| 22:02:01 | jyp | tough I don't quite remember the adequate cvs command |
| 22:04:20 | jyp | Ok I'm committing the reversal |
| 22:04:50 | linuxstb | Thanks. |
| 22:05:38 | jyp | Please check that it's the correct thing |
| 22:10:11 | | Join Patr3ck [0] (~patr3ck@pD9E5CB2F.dip.t-dialin.net) |
| 22:13:38 | | Quit Stryke` ("Friends don't let friends listen to Anti-Flag") |
| 22:15:26 | linuxstb | jyp: Yes, that's perfect - a diff between 1.3 and 1.5 shows no differences. Thanks. |
| 22:15:53 | HCl | xD |
| 22:16:00 | jyp | You're welcome; sorry for my bad move |
| 22:16:09 | HCl | my mobile phone company just managed to charge me MINUS 0.26 cents for using my mobile phone xD |
| 22:16:27 | HCl | they're actually paying me! XD |
| 22:16:40 | preglow | HCl: COMPLAIN! |
| 22:16:43 | HCl | xd |
| 22:16:48 | HCl | its hilarious |
| 22:16:52 | HCl | brb |
| 22:24:08 | | Join midk_ [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 22:30:24 | | Join LukeA [0] (~a@dpc691997050.direcpc.com) |
| 22:30:35 | jyp | linuxstb: it would be really cool if I could chose to compile only certain codecs |
| 22:31:00 | jyp | since some cause compile errors |
| 22:32:30 | linuxstb | jyp: Yes, I think we need that. Maybe Bagder has a better idea, but you could simply add a #if to the codecs/Makefile |
| 22:32:33 | | Quit midk (Read error: 60 (Operation timed out)) |
| 22:32:50 | jyp | Alternatively, I'll have to commit workarounds for all the codecs... |
| 22:33:07 | | Join Bluechip [0] (~BlueChip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) |
| 22:33:27 | jyp | so, just a "weak" request. |
| 22:34:05 | HCl | well, my dynarec crashes on opcode 50... why is that.. |
| 22:34:42 | linuxstb | jyp: Maybe we should make the codecs compile for you. Which ones work, and which ones don't |
| 22:35:14 | jyp | For now, none do :P |
| 22:36:18 | HCl | i wish there was a normal way to debug this :/ |
| 22:37:50 | HCl | watashi wa baka desu :x |
| 22:38:15 | jyp | HCl: do the gdb stub :) |
| 22:38:16 | LukeA | hey, how do I upgrade to the latest version of Rockbox? On my FM Recorder, it shows 2.1 whenever it starts up, and I'd like to put 2.4 on there |
| 22:38:37 | amiconn | HCl: I hope you leave dynarec selectable via a #define, or are you going to implement dynarec for the sims too? ;) |
| 22:39:23 | amiconn | Bagder: In case you're back: I have some more findings... |
| 22:43:13 | HCl | i'm making progress. |
| 22:43:23 | HCl | it can still be fairly easily to comment out |
| 22:44:30 | Bagder | back now |
| 22:44:40 | amiconn | Nice :) |
| 22:45:16 | amiconn | Two things: (1) It looks like we really need a simulator implementation for plugin_load() |
| 22:45:47 | | Quit LukeA () |
| 22:45:49 | amiconn | The old win32 sim used to use plugin-win32.h, and this included windows.h, but we can't include windows.h from plugin.h |
| 22:46:12 | Bagder | yeps, we'll do that for the sim version of plugin_load |
| 22:46:17 | amiconn | ..because then there are conflicting types again (and no clear separation between target & sim code |
| 22:46:57 | amiconn | (2) The X11 sim does *almost* link now, only one undefined symbol left: _stderr |
| 22:47:11 | amiconn | (for debugf(), ldebugf() ) |
| 22:47:53 | amiconn | This is still crossing rockbox<->simulator. It looks like we need sim_debugf() and sim_ldebugf() too |
| 22:48:01 | Bagder | yeps |
| 22:48:58 | amiconn | Did you try if your patches compile on Linux? |
| 22:49:08 | Bagder | yes |
| 22:49:22 | Bagder | plain linux, not the win32 crosscompile |
| 22:49:38 | Bagder | I believe it will have some issues |
| 22:49:44 | Bagder | but that's the least important version |
| 22:49:48 | amiconn | Yes. You don't get the undefined _stderr? |
| 22:49:57 | Bagder | no |
| 22:50:08 | amiconn | Hmm. I wonder why |
| 22:50:34 | amiconn | That means there is still some rockbox<->simulator overlap, because stderr is not defined at all in rockbox |
| 22:51:01 | | Quit jyp ("poof!") |
| 22:51:02 | Bagder | I believe its another issue with needing a system include file |
| 22:51:17 | Bagder | so makeing a sim_* version out of it should fix it |
| 22:52:03 | amiconn | debug.c includes stdarg.h. There is no stdarg.h in rockbox... |
| 22:52:36 | Bagder | but there is in the sh include path |
| 22:53:59 | | Join stripwax [0] (~stripwax@213-228-241-36.dsl.prodigynet.co.uk) |
| 22:54:05 | stripwax | ello |
| 22:54:07 | amiconn | Hmm. I think when rockbox and simulator code are separated and everything compiles cleanly, there are some #include statements in a number of source files that can & should be removed. |
| 22:54:29 | HCl | dohhhhh |
| 22:54:31 | * | HCl slaps himself. |
| 22:55:41 | stripwax | got a question about the iriver port - i notice some devs are now introducing EMAC specific code into their codecs - is the EMAC state properly saved/restored on a task switch? |
| 22:57:52 | * | HCl isn't sure what emac is so wouldn't know :x |
| 22:58:22 | stripwax | it's kinda like MMX or SSE on those Intel chips :-S |
| 22:58:23 | amiconn | stripwax: I think emac is handled the same way as the mac registers on sh - they're considered scratch registers |
| 22:58:30 | HCl | ah. |
| 22:58:53 | amiconn | And, since rockbox does not do preemptive multitasking, there is no need to preserve state |
| 22:58:55 | hubble | stripwax: we have cooperative multitasking? |
| 22:58:56 | *** | Saving seen data "./dancer.seen" |
| 22:59:24 | stripwax | I don't know how rockbox handles tasks. if it's cooperative I guess there's no problem! |
| 22:59:44 | amiconn | stripwax: extactly. |
| 22:59:51 | stripwax | thx! |
| 23:00 |
| 23:01:52 | preglow | yes, like he says |
| 23:02:22 | preglow | if you depend on %%macx contents over a yield(), you're very optimistic, heh |
| 23:03:22 | | Join DMJC [0] (~James@220-245-162-47-sa-nt.tpgi.com.au) |
| 23:07:34 | stripwax | Something else I had on my mind - for iRiver, is there any particular reason the LCD is initialised in mono mode rather than 4-color mode? Is it any harder to initialise in 4-color mode (and plot two bits per pixel)? That would seem like a first step towards a fully greyscale-enabled rockbox? |
| 23:07:58 | preglow | just not done yet |
| 23:08:06 | stripwax | fairynuff |
| 23:08:18 | Bagder | lots of consideration needs to be made first |
| 23:08:25 | Bagder | since all lcd code assumes b/w |
| 23:08:29 | amiconn | stripwax: It's not the init. The graphics routines need to be rewritten |
| 23:10:19 | stripwax | How much is there though - line drawing and font rendering just need to plot two bits per pixel instead of one .. -? |
| 23:10:50 | Bagder | then what would the point of using greyscale be? |
| 23:11:12 | Bagder | I'd say fonts and lines etc should be able to use greyscales |
| 23:11:33 | stripwax | the two bits needn't be the same ;-) |
| 23:12:16 | Bagder | right, and then you need a new font format and lots of new code and protos ;-) |
| 23:12:29 | amiconn | You need to be able to set the 'color' to use for the line/ pixel etc |
| 23:12:38 | stripwax | I don't understand why you'd need a new font format. The iRiver stock firmware doesn't store colored fonts |
| 23:12:43 | amiconn | Currently, there are set/clear/invert routines |
| 23:13:03 | Bagder | stripwax: we don't make their firmware ;-) |
| 23:13:10 | Bagder | *I* want multicolor fonts |
| 23:13:21 | Bagder | antialias! |
| 23:13:26 | amiconn | A new font format isn't necessary unless we want multicolour fonts, something unnecessary imho |
| 23:13:27 | rashur | That doesn't go too well with using bdf fonts though does it? |
| 23:13:47 | Bagder | we don't use bdf fonts |
| 23:13:48 | stripwax | Badger - my point is that, what if you want to color the fonts with top two pixels light grey, next two pixels dark grey, and the rest black. is that going to be a separate font file? |
| 23:13:56 | Bagder | we just convert from bdf to our own format |
| 23:14:34 | stripwax | Ok, antialias fonts will need a separate font file :-D |
| 23:14:50 | stripwax | amiconn - right so maybe the Set function could take an (optional) color arg |
| 23:14:59 | Bagder | although I agree multicolor font is not #1 on my prio list ;-) |
| 23:15:07 | amiconn | And btw, extending the gfx api to provide support for setting the colour (yes, also thinking ahead for H3xx) does not necessarily mean more code |
| 23:15:21 | stripwax | So just AND the font with a color and plot that |
| 23:15:36 | amiconn | Currently, there are 3 functions for each mode (drawline/ clearline/ invertline) |
| 23:15:49 | stripwax | 'mode'? |
| 23:15:54 | rashur | Bagder: well yes |
| 23:16:19 | amiconn | If we change this to a similar approach as the grayscale lib already uses, there would only be one drawline function |
| 23:16:57 | amiconn | stripwax: Yes. drawline() draws black pixels, clearline() draws white pixels, and invertline() inverts all pixels |
| 23:17:20 | amiconn | (I know that there is no invertline, but for other function the is an invert* kind) |
| 23:17:29 | stripwax | amiconn - by 'mode' did you mean 'drawing lines'? what are the other modes? |
| 23:17:59 | amiconn | No, by mode I mean how the drawing functions behave |
| 23:18:17 | amiconn | Currently, there is no mode concept, so all functions exist in different variants |
| 23:18:24 | stripwax | what did you mean by "3 functions for each mode" then? |
| 23:18:48 | amiconn | No, you got this slightly wrong (perhaps I was unclear) |
| 23:18:56 | stripwax | set/clear/invert functions for lines, text, and what else? |
| 23:19:27 | amiconn | I mean, since there is no concept of drawing modes, there are (max.) 3 functions for one graphics primitive, i.e. |
| 23:19:55 | Bagder | amiconn: ... and there's now a -8 patch uploaded |
| 23:20:12 | amiconn | drawpixel/clearpixel/invertpixel, drawline/clearline/invertline etc. |
| 23:20:41 | stripwax | amiconn - right ,so draw* could take an (optional) color arg .. .? |
| 23:21:29 | amiconn | Yes, that would be one option, but this usually leads to unnecessary many arguments, which in turn leads to larger binaries |
| 23:22:00 | amiconn | Please have a look at the grayscale lib. It uses a drawing mode concept, and a foregroud and background colour |
| 23:22:16 | amiconn | The mode and the two colours can be set by separate function calls |
| 23:22:20 | stripwax | amiconn - bigger binaries than having two functions to draw/clear every kind of graphic primative!? |
| 23:22:38 | amiconn | Nope, but bigger binaries than with the mode concept |
| 23:22:41 | stripwax | oh there's already a grayscale lib? ok I'll look at that. what uses it |
| 23:23:02 | amiconn | Believe me, I first had the 'extra arguments' approach within the grayscale lib... |
| 23:23:28 | stripwax | amiconn - no, I agree that a setforeground/setbackground is better |
| 23:23:32 | amiconn | The grayscale lib currently only works on the archos devices |
| 23:23:54 | amiconn | setforeground, setbackground, setmode, and (optionally) a function that sets all three |
| 23:24:30 | stripwax | Ok, now I'm really confused, because I thought Rockbox only supported 1-bit LCDs even on Archos? Guess I'll just go read the code again |
| 23:25:11 | Bagder | stripwax: that was before amiconn's magic greyscale lib ;-) |
| 23:25:14 | amiconn | The grayscale lib is only for plugins |
| 23:25:31 | amiconn | It uses temporal dithering to simulate up to 33 grayscales |
| 23:26:00 | stripwax | amiconn - heh, neat! |
| 23:26:37 | amiconn | It's e.g. used by the jpeg viewer |
| 23:28:05 | amiconn | Bagder: Building... |
| 23:28:35 | | Quit Zezayer ("ChatZilla 0.9.61 [Mozilla rv:1.7.2/20040804]") |
| 23:29:02 | * | HCl is finally getting the expected result from his dynarec |
| 23:29:48 | amiconn | Bagder: The linker errors with missing symbols are gone. :) However, now there is a duplicate symbol: _debugf :( |
| 23:29:56 | Bagder | oh |
| 23:30:08 | Bagder | did you make clean first? |
| 23:30:16 | Bagder | there's something broken with the dependencies atm |
| 23:30:18 | amiconn | Yup, and reconfigured as well |
| 23:30:18 | pillo | HCl: coool! |
| 23:30:21 | Bagder | ok |
| 23:30:24 | Bagder | I'll check |
| 23:30:27 | amiconn | Log? |
| 23:30:35 | Bagder | nah, not needed |
| 23:30:46 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 23:30:46 | amiconn | /uisimulator/common/io.c:346: multiple definition of `_debugf' |
| 23:30:57 | HCl | pillo: well, it just yells out "unimplemented opcode!" at the moment, but at least, its finally what its supposed to be doing |
| 23:31:04 | amiconn | uisimulator/win32/debug-win32.c:51: first defined here |
| 23:31:08 | LinusN | the emac accumulators are not preserved |
| 23:31:09 | Bagder | aha |
| 23:31:23 | pillo | HCl: cute anyways isn't it? ;) |
| 23:31:47 | Bagder | amiconn: you think the debug-win32.c approach is useful? |
| 23:32:33 | Bagder | I'm not even sure what it does |
| 23:32:44 | amiconn | Hmm. I don't know; didn't fiddle with windows debuggers so far |
| 23:33:07 | Bagder | ok, I'll leave it in and make the other code x11-specific |
| 23:34:09 | amiconn | It looks like it can hook into a debugger if present, otherwise simply uses printf(). I'd suggest to leave that as-is, even though I don't know how this is supposed to be used... |
| 23:34:26 | HCl | pillo: yup, now i can actually work on it |
| 23:35:06 | Bagder | amiconn: so if you "if 0" out the debugf functions in the bottom uisim/common/io.c can you link fine then? |
| 23:36:08 | amiconn | HCl: Is there some reading about dynarec you can point me to? I don't understand the following: |
| 23:36:40 | amiconn | You say that z80 instructions are compiled into host instructions until a jump instruction is detected. |
| 23:36:44 | HCl | yea |
| 23:37:06 | amiconn | How is the case handled if some code jumps *into* such a chain? |
| 23:37:08 | HCl | thats not in my dynarec yet, heh |
| 23:37:21 | HCl | it recompiles a new block |
| 23:37:34 | pillo | HCl: congrats & keep up the great job you're doing! We're all waiting for the two player version (one on the player, one on the remote) :) |
| 23:37:45 | amiconn | Hmm. Sounds a bit inefficient, memory-wise |
| 23:37:58 | HCl | yup, in a way, they are. |
| 23:38:05 | HCl | there's room for optimization. |
| 23:38:11 | HCl | but its not nice to fix. |
| 23:38:36 | HCl | you're free to offer suggestions, heh. |
| 23:38:42 | stripwax | Is dynarec something to do with the gameboy emulator? |
| 23:38:49 | HCl | mmm. |
| 23:39:25 | amiconn | HCl: (<HCl> you're free to offer suggestions, heh.) That's why I asked for recommended reading... |
| 23:40:19 | HCl | mmm. |
| 23:40:23 | HCl | i'm not sure if i have much... |
| 23:40:28 | HCl | let me search a bit. |
| 23:40:57 | Bagder | amiconn: http://daniel.haxx.se/rockbox/simfix-9.patch |
| 23:41:00 | amiconn | Bagder: Main simulator now builds & links. Even a number of plugin compiles & links fine. Then it errors in calendar.c |
| 23:41:22 | HCl | http://acorn.cybervillage.co.uk/emulation/dynrcomp.htm |
| 23:41:24 | HCl | how's that? |
| 23:41:27 | Bagder | (ok, never mind that patch it is just that little fix) |
| 23:41:56 | amiconn | Bagder: There are however warnings for the plugins about conflicting types... Want the log? |
| 23:42:03 | Bagder | sure |
| 23:43:07 | amiconn | Bah, resume.... |
| 23:43:51 | amiconn | I'll try x11 sim in the meantime... |
| 23:44:54 | | Part stripwax |
| 23:45:15 | | Quit midk_ ("Leaving") |
| 23:46:00 | Bagder | right, we need -fno-builtin to prevent warnings on some functions gcc has built-in stuff for |
| 23:46:29 | amiconn | Bagder: The win32 simulator .exe runs, but the background image isn't there. The icon is also missing. |
| 23:46:53 | | Quit methangas (" HydraIRC -> http://www.hydrairc.com <-") |
| 23:46:58 | amiconn | I presume the resource file isn't included |
| 23:47:44 | Bagder | it is supposed to ;-) |
| 23:50:08 | Bagder | so what is the calendar.c problem? |
| 23:50:43 | amiconn | Did you have a look at the log? And/or deleted it, to avoid the dcc resume? |
| 23:51:31 | | Join skav [0] (skav@67-138-74-184.dsl1.merch.roc.ny.frontiernet.net) |
| 23:51:31 | Bagder | I deleted it, it wasn't correct |
| 23:51:56 | amiconn | There :) |
| 23:53:06 | amiconn | Ah, it's fprintf... |
| 23:53:08 | Bagder | now why didn't I see that? ;-) was a fprintf() |
| 23:54:54 | amiconn | There are 'conflicting types for built-in function' warnings for the rockbox part too. Is that solved with -fno-builtin too? |
| 23:55:11 | Bagder | yes |
| 23:57:01 | | Join Renko [0] (~Renko@host217-43-59-232.range217-43.btcentralplus.com) |
| 23:57:01 | | Quit DMJC ("Leaving") |
icon identifies that the person is a core developer (has commit access).