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

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

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

#rockbox log for 2005-02-21

00:00:01pillosee you tomorrow!
00:00:17 Quit amiconn (Nick collision from services.)
00:00:18 Nick amiconn_ is now known as amiconn (
00:00:41 Quit CoCoLUS ()
00:00:57preglowa bloody optimization guide would have been great
00:01:03preglowbut doesn't seem like motorola has one
00:06:36 Join Renko [0] (
00:07:13 Quit Stryke` ("Friends don't let friends listen to Anti-Flag")
00:07:38preglowhow the hell motorola has managed to get an mp3 decoder running in 19mhz is beyond me :V
00:07:50HCl :P
00:08:05rasherI assume they know the processor pretty well :)
00:08:11preglowno shit
00:08:38linuxstbWould there be other bottlenecks on the iRiver? Maybe the memory?
00:08:51preglowwouldn't know
00:09:03Patr3ckhow could profiling be added to the codecs?
00:09:11preglowPatr3ck: with difficulty
00:09:28preglowespecially if you mean with gprof and those tool
00:09:52Patr3ckadd tick counts to the codec functions?
00:09:58 Quit pillo ("CGI:IRC (EOF)")
00:10:14preglowit would have to be something like that, yes
00:10:24preglowbut we'll need something lower resolution than ticks
00:11:21preglowwell, 10ms is pretty much, and if the function executes quickly, it'll seem like it's using more time than it is
00:11:51Patr3ckI see, is a higher resolution possible with existing stuff in rockbox
00:11:55preglowdon't know
00:11:59preglowshould be
00:12:21Patr3ckbesides the resolution, how would it be added
00:13:07Patr3ckthe information must be added to a central information store from all over the codec
00:13:08preglowby simply just adding timing to the functions and storing results in a global array, i guess
00:13:14preglowi haven't done manual profiling before
00:13:40Patr3ckall the codecs would benefit from some simple common functions I guess
00:14:51Patr3ckjust wondering were these functions should be placed...
00:24:50 Join ashridah_ [0] (
00:25:04 Quit ashridah (Nick collision from services.)
00:25:08 Nick ashridah_ is now known as ashridah (
00:26:13preglowperhaps codecs should be placed in sram
00:26:35preglowthat would put a size restriction on them, for sure
00:27:04Bagdershould make an interesting test if nothing else
00:27:37 Join condor9 [0] (
00:27:42preglowi really think it does matter quite a lot
00:27:48preglowthere are tons of memory accesses
00:27:50 Quit muesli- (Read error: 110 (Connection timed out))
00:28:20condor9I 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:44Bagderalive at least ;-)
00:29:15amiconnDid you read about my idea about a clean fix for the sim compilation problems in the logs?
00:29:57Bagderabout what time/date?
00:32:10amiconnlook at starting around 00:30
00:33:23condor9How do you get the config file to load on startup?
00:34:37preglowwhat 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:44amiconncondor9: .cfg files are never loaded automatically.
00:35:25amiconncondor9: 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:44condor9Hmmm... but 2.2 used to correct?
00:35:59condor9Seems odd that I have to load a config everytime.
00:36:24amiconnThis 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:47condor9Yuck. :( Thanks amiconn.
00:36:51amiconnIf you saved the config to a .cfg file before, you should be able to load that with the new version
00:37:16condor9Yeah I can load it, I just hate having to manually load it everytime.
00:37:21amiconnOnce loaded, and the unit shut down properly, the settings should be autoloaded again
00:37:50Bagderamiconn: 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:19amiconnThe ifdefing is problematic, as we have seen
00:38:23condor9amiconn: Oh. Well, they aren't for me. I have a recorder (V1) with 2.4 built from source.
00:39:11amiconncondor9: How do you shut down the box after loading your settings?
00:39:34Bagderamiconn: yes it is, but what's the fix? renaming include files to not use posix names? I don't like that
00:39:57amiconnBagder: No, I think my suggestion should work:
00:40:31amiconn- put all rockbox includes that are called the same as system includes and define posix functions into a separate include dir.
00:40:42condor9amiconn: 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:07amiconnBagder: This requires additional functions which are not posix moving to other includes
00:41:14Bagderamiconn: 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:37BagderI could of course live without them if forced ... :-)
00:42:04amiconnThen consider these functions as non-posix....
00:42:35amiconnThe dir with the posix includes should then be in the include path for target compiles, but not for sim compiles
00:42:46Bagderif that works, I'm all for it
00:43:02BagderI doubt it will be that simple
00:43:36amiconnIf you want to have certain functions always provided by rockbox, then this is of course also necessary for the sources under uisimulator/
00:43:49amiconnOtherwise we'll get the same clashing again
00:44:22amiconnAnd of course, functions with the same name as a posix function, but with different semantics should be renamed
00:44:40amiconnThe obvious example is sleep()
00:44:51Bagdersleep should be renamed indeed
00:45:04Bagderbut opendir() is a nasty example
00:45:24amiconn(I'm not a posix expert....)
00:45:40Bagderbecause 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:54Bagderno perhaps thats not a problem
00:46:03Bagdersince it uses posix
00:46:25amiconnMaybe it is :(
00:46:44 Quit condor9 ("Leaving")
00:46:44amiconnThe file system emulation in a sub-dir, I forgot...
00:47:01 Part hubble
00:47:34preglowchroot :)
00:48:38amiconnThere is no chroot() in windows... (thinking win32 sim, it should work in cygwin for the x11 sim)
00:49:19preglowahh, you support msvc as well, yes
00:49:23preglowforgot about that
00:49:39amiconnNot msvc, but building native win32 sim with cygwin gcc
00:49:56preglowwell, yes, that as well
00:50:04amiconnThe msvc support was there, but is surely broken by the new build system
00:53:45 Quit Renko ("Leaving")
00:57:36amiconnBagder: Where are those sim_* functions defined?
00:57:54Bagderin common/io.c
00:58:20***Saving seen data "./dancer.seen"
00:59:41amiconnSo what do you think about the following approach (it's actually similar to how things currently work iiuc):
01:01:16amiconnIn each rockbox include that defines posix functions, set the appropriate sim_* define, selected by #ifdef SIMULATOR.
01:01:28amiconnAll 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:11amiconnThe code in uisimulator/ however should then never use these includes, but the system ones.
01:02:24amiconnThen it should actually implement the sim_
01:02:35amiconn* equivalents by using the system functions
01:02:37Bagderthat sounds reasonable
01:03:21Bagderbut then we'd need a dir with include files that aren't used for the sim
01:03:38 Join Shity [0] (
01:03:49Shityanyone here ?
01:03:52preglow 6yes
01:03:59Shitystupid question
01:04:00Bagderwe could actually just define for example "firmware/include/" to be that dir, and the "clean it up" to work as you described
01:04:04Shityare you italian
01:04:08preglowhell no
01:04:20Shitywhere can i find a channel with italians
01:04:22Shityi need some help
01:04:24Bagderc'mon preglow, admit it :-)
01:04:25preglowdon't ask me
01:04:33Shitybagder are you ?
01:04:33preglowwhy do you need italians?
01:04:39preglowaren't us norwegians good enough?
01:05:07Shityi got a gay assignement to do and i just got couple of easy questions
01:05:12preglowBagder: i would have to be excessively drunk
01:05:15Shityand i need an italian to asnwer them
01:05:21preglowthen go somewhere else
01:05:35jyp /kick Shity
01:05:38Shityyeah thanks for your help .. faggot
01:05:40 Part Shity
01:05:46preglowahh, trolls...
01:06:24HClit gets boring, really
01:06:36amiconnBagder: Using firmware/include for that actually sounds reasonable. Iirc these are mostly posix functions anyway.
01:06:47rasherThat was... different.
01:06:56rasherIt's not like this is a particularly large channel is it?
01:07:01Bagderamiconn: yes, that's why I think it would be a good dir to define to be this "target-only" dir
01:07:16preglowrasher: there are more than enough complete fools to go around
01:07:22preglowrasher: even in the smallest of channels
01:07:24rasherpreglow: good point
01:08:43amiconnBagder: This would work rather nicely, if I didn't overlook something:
01:09:38amiconn#ifdef SIMULATOR
01:09:56amiconn#define open(blah) sim_open(blah)
01:10:13amiconnint open(char *blah);
01:10:36Bagdernot even #else, since it needs the proto for sim_open()
01:11:14amiconnAh, yes, this has to go before the #else then
01:11:42amiconnThe proto after #else is of course necessary for building the target
01:12:15Bagderyes, open() is needed for target and sim_open() for sim
01:12:26Bagderifdef SIM
01:12:37Bagder#define open() sim_open()
01:12:46Bagderint open(char *bbbbb);
01:13:15amiconn...and exactly this would not work, imho
01:13:26amiconn#ifdef SIMULATOR
01:13:29Bagderand isn't this file in the target-only include dir anyway?
01:13:51Bagderthe one with the open() proto I mean
01:14:10preglowbed, later all
01:14:19 Quit preglow ("fugleskremsel")
01:14:32amiconnNo, it is an include that is used by the main rockbox dirs only, but also for building the sim.
01:15:01amiconnI.e. files under apps/ and firmware/ should always use it, but files in uisimulator/ must never use it
01:15:22Bagderah, right. I'm following
01:15:52amiconnSo 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] (
01:16:32Bagderright, but the file that provides an open() prototype, shouldn't it provide a sim_open() prototype when built for the sim?
01:16:37amiconnThe 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:56amiconnYes, that was my addittion after your comment.
01:17:05amiconn#ifdef SIMULATOR
01:17:15Bagderyes, we must differ between files that needs simulation and files that implement simulation
01:17:16amiconn#define open() sim_open()
01:17:26amiconnint sim_open(char *bbbbb);
01:17:32amiconnint open(char *bbbbb);
01:17:57BagderI don't see the diff between this and my version, but it doesn't matter much
01:18:22Bagderah, possibly because the protos differ of course
01:18:44Bagderbut that might cause compiler warnings
01:19:24amiconnThe prototype has to be exactly identical except for the name
01:19:53Bagderbut then you don't need two versions, since the define will work for the proto as well
01:20:06Bagdernever mind, its not important for this discussion
01:20:19amiconnAh, yes, you're right
01:20:37amiconnThat looks even cleaner...
01:21:41amiconnThe 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:22:36amiconnOf 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:36Bagderchecking now, the uisimulator/ files already seem to be built without using the include dir
01:23:18Bagderamiconn: no, I think it would make the sim clean and understandable even if there's a tiny overhead
01:23:38amiconnThe posix functions that we want to always use the rockbox implementation will simply not get a sim_ define
01:25:02amiconnWe wouldn't even need to rename sleep(), but I think it should be done because it is not exactly posix...
01:25:29amiconnI don't have an idea what it should be called though...
01:25:45Bagderhehe, me neither
01:28:21Bagderso basically, if we move the sim_* logic into the include/* headers, we should start getting it working right
01:29:00Bagderof course, there are some non-posix functions we want sim_* versions of too
01:29:02amiconnYes, I think so too.
01:29:06XShocKis WAV codec done?
01:29:23Bagder...most notable is lcd_update()
01:29:31amiconnAh, yes.
01:29:46amiconnWell, these could use the same mechanism
01:30:01linuxstbXShocK: No.
01:30:10 Join AC [0] (
01:30:19linuxstbXShock: Are you ready for it?
01:30:35amiconnThis sounds like a clear separation of rockbox code (which needs simulated functions) and simulator code (which provides them)
01:31:14XShocKlinuxstb: I think yes.
01:31:45 Quit mrmags ("Download Gaim:")
01:31:47amiconnThe 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:28linuxstbXShock: Does that mean you've made progress with sound?
01:33:33XShocKyes, me and hubble
01:33:45XShocKsounds very good actually.
01:33:49Bagderamiconn: I get a feeling this is the correct way forward
01:34:01amiconnI have to agree.
01:34:30amiconnHow do you think we should tackle this? Specifically, could we share the work somehow?
01:35:44Bagderlemme dig into it tomorrow and see how much I can fix "at once", and then we'll talk more tomorrow
01:36:18linuxstbXShock: Congratulations to you and hubble. Can you give us any more information? How does it work?
01:36:37BagderI'm going away on wednesday for a week, so I just have line one and a half day before that
01:36:55XShocKcurrently it works on AUDIOTICK interrupt
01:37:42XShocKdoes not use DMA, since i couldn't figure out how to control its speed.
01:38:04XShocKwith AUDIOTICK 44.1 16-bit works and souns well.
01:39:04XShocKi feed several samples into PDOR3 on each AUDIOTICK
01:39:18amiconnBagder: okay.
01:40:22jypsounds familiar, good ;)
01:43:50 Quit jyp ("poof!")
01:43:50 Quit AC ("CGI:IRC (EOF)")
01:44:57linuxstbXShocK: 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:39XShocKI will try it, yes
01:47:17XShocKI would really like it to be DMA
01:47:27linuxstbSo all we need to do now is design and code an audio playback system and get the codecs running in real-time...
01:47:40XShocKyep. :)
01:48:02linuxstbThat assumes Linus can get the iRiver running reliably at 140MHz and solve the ATA problem...
01:48:08amiconnlinuxstb: It seems to me that the realtime codecs part is the bigger task...
01:49:07XShocKdid anyone try to do that m68k optimized MPEG decoder?
01:49:12amiconnI hope someone will have a look at the asm optimised mp3 decoder
01:49:17amiconnXShocK: :)
01:50:11amiconnI have the comparison on Amiga (m68k): The decoder by Stephane Tavenard is twice as fast as an optimised libmad...
01:50:15linuxstbI'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:32linuxstbamiconn: That's promising.
01:51:21amiconnHowever, 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:54amiconnAh, I forgot something. The 68060 is superscalar (2 execution units)
01:54:17XShocKso as i understand that asm decoder is curently not compilable?
01:54:50linuxstbI 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:54XShocK*compileable | compilable? which one is correct?
01:55:09linuxstb"can not be compiled"
01:55:47linuxstb(if you can't spell a word, use a different one)
01:57:32XShocKbut "compilable" is cooler. :)
01:58:11linuxstb:-). But I think the answer is no anyway.
01:59:00linuxstbBut it shouldn't take too much work - I may give it a try tomorrow evening.
01:59:25XShocKI usually mess up rules of russian language with english.
02:00:57 Join ghode|afk [0] (
02:09:11 Quit ghode|afk ()
02:18:58 Quit edx (Read error: 60 (Operation timed out))
02:21:39 Join skav [0] (
02:30:48 Join DMJC [0] (
02:34:18amiconnGoing to sleep now... night all
02:34:59 Part amiconn
02:36:27 Quit Patr3ck ()
02:58:23***Saving seen data "./dancer.seen"
02:59:47 Join midk [0] (
03:12:21 Quit XShocK (" HydraIRC -> <-")
03:24:24 Join midk_ [0] (
03:24:24 Quit midk_ (Client Quit)
03:32:33 Join wacky_ [0] (
03:32:43wacky_hey boys and girls :)
03:35:41 Join XShocK [0] (
04:04:04 Quit wacky_ ("awright")
04:05:54 Join QT [0] (as@area51.users.madwifi)
04:09:21 Join edx [0] (
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:05:16 Join rwilco [0] (
05:24:48 Part rwilco ("Leaving")
05:25:17 Quit linuxstb (Read error: 110 (Connection timed out))
05:30:36 Quit XShocK (" HydraIRC -> <- IRC with a difference")
06:11:10 Join XShocK [0] (
06:12:25XShocKHehe... cool. Rockbox plays WAV files. :)
06:12:52rasherYay :D
06:13:01rasherThat's damn cool indeed
06:14:03XShocKI can't really understand how to make DMA work here....
06:14:19XShocKI don't know methods to slow DMA down.
06:14:21XShocKor pause
06:15:31XShocKBut for most purposes probably current implementation will work wel
06:18:05rasherSounds good
06:18:26rasherWell this is certainly good news :)
06:20:25XShocKand now codecs.... i predict is the worst problem. :)
06:22:33 Join Lurkski [0] (
06:28:01XShocKnight all
06:29:03 Quit XShocK (" HydraIRC -> <- Go on, try it!")
06:29:13rasherwell the codec api
06:29:23rasherhard to tune the codecs without knowing the speed
06:29:25 Quit Lurkski ("Download Gaim:")
06:29:40rasherwell, hard to know what you're aiming for, that is
06:31:11 Join Lurkski [0] (
06:32:48 Join Muntek [0] (
06:33:37 Part Muntek
06:36:49 Join webguest39 [0] (
06:37:16 Quit webguest39 (Client Quit)
06:50:39 Part Lurkski
06:50:49 Join Lurkski [0] (
06:57:35 Part Lurkski
06:57:49 Join Lurkski [0] (
06:58:31***Saving seen data "./dancer.seen"
07:24:54 Quit midk ("Leaving")
08:08:46 Nick ashridah is now known as Lost-ash (
08:14:20 Join LinusN [0] (
08:27:22 Nick Lost-ash is now known as ashridah (
08:27:40 Nick ashridah is now known as Lost-ash (
08:27:42Lost-ashback to cooking :/
08:27:59*LinusN has to reboot
08:28:01 Part LinusN
08:28:26Lost-ashgah. would help if i remembered to put the food on the heat :/
08:36:37 Join LinusN [0] (
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] (
08:58:34***Saving seen data "./dancer.seen"
09:31:42 Join bobTHC [0] (
09:31:53bobTHCmorning folks!
09:34:34*Zagor yawns
09:37:52 Join LinusN [0] (
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:20dwihnoLinusN: 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:29dwihnoJust hang in there... :)
09:43:51 Nick Lost-ash is now known as ashridah (
09:46:20 Join linuxstb [0] (
09:48:16LinusNZagor: how's the free and independent life nowadays?
09:48:33Zagorpretty relaxed :-)
09:48:58dwihnofree? independent?
09:49:40Zagoryeah, i sorta... quit working.
09:51:07dwihnoyou did?
09:51:16dwihnoare you serious?
09:51:59Zagoryeah. i'm only working for myself now.
09:52:41Zagorstill feels really weird. i expect it will take a few weeks to establish some kind of routine.
09:53:24dwihnooh.. I wish you the best of luck
09:53:55dwihnoYou'll do consulting within the Haxx sphear?
09:54:50Zagorno, i'll just be working on my web site.
09:55:36dwihnodoes it produce any money?
09:55:48dwihnoI assume you're talking about your bostadsbytar-website
09:55:59 Join midk [0] (
09:56:23Zagoryeah. it brings in enough to live on.
09:56:42dwihnoit does? cool!
09:57:27dwihnoAny bigger plans?
09:58:17Zagornothing major, just various improvements
09:59:00dwihnoAre you going to do anything special with your new-found time?
09:59:40LinusNsleep, watch tv
09:59:48DeadManget fat
10:02:23Zagori'm going to do more fun stuff, like rockbox and various other little projects i didn't have time for before
10:03:31dwihnoAnd I thought you were going to get away from the computers and spend more time practicing banjo :)
10:04:25 Join Lurkski [0] (
10:05:04 Quit Domin ("Curse - Version 1.5.1")
10:05:48dwihnoI'd like to work less as well
10:05:56dwihnoPerhaps 75%
10:10:06bobTHChave u seen the last mailman security issues ??
10:12:06Zagorfixed in our version
10:12:27bobTHCnothing to add
10:13:42DeadManso what's in progress on iRiver at the moment?
10:13:56*LinusN is working on the cpu clocking
10:14:08DeadManfigured out the ata prob yet?
10:14:20LinusNhaven't had time to work on it...
10:14:46DeadManI saw xshock got wav playback working of a sort
10:14:51LinusNwill connect a logic analyzer to study the timing
10:15:05LinusNi'm disappointed that he didn't get the dma working
10:15:18DeadManI think he does not know how to do it
10:15:41DeadMansomeone might be able to figure it out
10:16:01LinusNi was hoping to not have to do that myself...
10:16:18DeadManheh. more work
10:16:25LinusNtoo much to do already
10:16:40DeadManhave a chat with him see if you can offer him pointers
10:17:06LinusNwe seem to run past each other in the channel
10:17:39DeadManon different times :)
10:17:54DeadMantell him to stay up overnight ;)
10:19:19 Join Schnueff [0] (
10:24:21 Quit Lurkski (Read error: 104 (Connection reset by peer))
10:29:09 Join Lurkski [0] (
10:46:59 Join Patr3ck [0] (
10:58:38***Saving seen data "./dancer.seen"
11:29:49Lurkski; )
11:56:07 Join amiconn [0] (
12:01:22 Quit DMJC ("Leaving")
12:04:02 Quit bobTHC (Read error: 110 (Connection timed out))
12:06:37 Join Aison [0] (
12:07:09 Join jyp [0] (
12:24:56 Quit ashridah ("bbs")
12:26:19*HCl stretches
12:27:19Lurkski***just a stranger wondering how rockboy is advancing
12:28:10LinusNslowly...about 11MHz :-)
12:28:44Lurkskiat least fast levels will be easier
12:31:33Lurkskihey a second?
12:31:53Lurkskigot some nooby questions for you
12:33:28 Quit izzy (Read error: 60 (Operation timed out))
12:34:57LurkskiWell 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:26LurkskiI was wondering where to start so that someday I might be capable of contributing to the project
12:36:01dwihnoLearning C is a good start
12:36:53 Join ashridah [0] (
12:37:12Zagorplaying 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:13LinusNLurkski: what programming experience do you have today?
12:38:22Patr3ckI am thinking about adding profiling to the codecs to support your optimizing efforts
12:38:40Patr3ckis therre something with higher resolution than ticks for measurement?
12:38:40LurkskiWell 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:14LinusNPatr3ck: no, but there are free timers to use
12:39:47Lurkskiyou 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:40:10Lurkskino = know
12:40:31Patr3ckdoes the tree of function calls need to be preserved for the profiling information
12:40:52Patr3ckor is it enough to just keep call count and a sum of durations
12:41:25linuxstbLurkski: 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:31ZagorPatr3ck: 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:32Patr3ckI already prepared some simple functions to add to a central profiling information array
12:42:39LurkskiOk, set up the build environment and playaround with plugins in the simsounds like a good start........
12:42:43Patr3ckthese could be used by all codecs
12:43:26Patr3ckthe codecs are plugins, so I would need to add these to the plugin api?
12:43:49Zagorthe codecs aren't plugins yet. they only have some test plugins for development.
12:43:58linuxstbLurkski: Only problem is that if you are using Windows, the simulators don't currently work. But hopefully these will be working soon.
12:44:04Zagorthere will be a separate codec api added.
12:44:23Patr3ckI see
12:45:28Patr3ckI will have a look at the free timers this evening
12:45:30linuxstbOne 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:01linuxstbOr you could add it to plugins/lib/ - then it could be used by Rockboy.
12:46:14LinusNi have plans to introduce a usec timer
12:46:37LurkskiOk 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:38LinusNfor profiling and usleep()
12:46:49Zagorlinuxstb: 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:48:03Patr3ckHow would a profiling build be separated from a release build?
12:48:20linuxstbZagor: I'm happy to talk about it.
12:49:03linuxstbI don't know what we will gain by letting the codecs load the files - why are you thinking that?
12:50:00LinusNPatr3ck: use a #define
12:50:02Zagorbecause we don't know which data is important, meaning we will load a lot of useless metadata which takes up ram space
12:50:21Patr3ck#ifdef PROFILING?
12:51:27linuxstbI'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:00Zagorthe 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:23linuxstbNot if the codec is the same as the previous one.
12:52:25Zagorthink dvd images - playing only the sound requires buffering the video data as well...
12:53:54LinusNPatr3ck: PROFILING sounds fine
12:54:01 Part Lurkski
12:54:12 Join Lurkski [0] (
12:54:38linuxstbI 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:41Patr3cklinusn: for now i will try the free timers
12:55:04LinusNlook at tick_start() in kernel.c for an example
12:55:11Patr3cklinusn: if you add something better I make sure it can be changed easily
12:55:15ashridahpersonally, 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:22Patr3cklinusn: ok, thanks
12:56:10ashridahshould 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:10QTHi! sorry for the n00b question, but how useful is the iriver port currently? installable?
12:56:11Zagorlinuxstb: 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:22ashridahqt: installable. looks pretty. plays nothing. yet.
12:56:41QTashridah: ok. thanks.
12:57:02QTi just wonder all the time when i read comments here which let me think that some guys have rockbox already installed
12:57:11LinusNquite a few
12:57:26ashridahqt: we do, but it's for development purposes.
12:57:31Bagderamiconn: you here?
12:57:53QTis it easy to revert to orig firmware?
12:58:01LinusNyou don't need to
12:58:23LinusNthe original is still in flash
12:58:36QTok. so the orig FW stays on while rockbox is running
12:58:42***Saving seen data "./dancer.seen"
12:58:43LinusNbut yes, it is very easy to revert
12:58:45ashridahqt: 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:45QTok, similiar as to how the xbox mods work
12:59:01QTthat is good news
12:59:10linuxstbZagor: 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.
13:00:06Zagorno, we only spin up once: to load the codec and/or load new files
13:01:45Zagorwe don't load a codec until it's time to read files
13:03:02 Join preglow [0] (
13:03:40linuxstbOK, 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:55linuxstbAnd that they should strip out as much "junk" as they can.
13:04:30 Join Zezayer [0] (
13:04:58Zagornaturally rockbox needs to supervise it and allocate space so several codecs can coexist.
13:05:23Zagorbut the codecs themselves know best how to make best use of the ram they get
13:06:20linuxstbHow are you thinking that the "supervision" would work? How would the codecs be allocated parts of the memory buffer?
13:06:40preglowLinusN: what are your thoughts about moving the active codec to sram? got any estimate on how much that'll boost performance?
13:07:15QTstupid 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] (
13:08:04linuxstbQT: You possibly just need to put the variable representing the filename in quotes - "$x"
13:08:06Zagorlinuxstb: 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:19QTlinuxstb: tried that and it failed
13:08:51Zagorlinuxstb: ...and return a length indicating how much was used.
13:08:59LinusNpreglow: the internal ram has 1-cycle fetches, so it will be a huge boost
13:09:07ashridahqt: do you have spaces in any of the directory names?
13:09:08QTlinuxstb: 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:18QTashridah: in most
13:09:22Bagderamiconn: in case you check the log later, here's my initial take at our simulator fix:
13:09:32ashridahthen you're in for a painful trip
13:09:54Zagorpreglow: 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:57QTashridah: 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:11ashridahshell 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:26BagderQT: I'd use find to get the list of names, then treat each line as a full file name and use quotes
13:10:28ashridahperl can work, although i don't know enough perl to help you.
13:10:28amiconnBagder: I'm here now.
13:10:39QTmy 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:40preglowZagor: yes, at least gapless playback across different codecs isn't a huge issue
13:10:49preglowLinusN: i'm really starting to think it'll be necessary, you see
13:11:03LinusNi have thought so all the time...
13:11:04Bagderamiconn: ok, my patch there builds here but it might need futher tweaking to do good in cygwin land
13:11:06QTbadger: that was my idea too. it just doesn't handle the spaces though
13:11:17BagderQT: mv with quotes does handle spaces
13:11:36QTbadger: it does. but not the for() loop
13:11:36ashridahBagder, sure. but not when they're embedded inside a for/find loop
13:11:54Bagderso 1) don't use for or 2) change IFS
13:11:55ashridaheven if you escape them, you've got to have multiple levels of escapes
13:11:56preglowLinusN: mention it next time, please, i actually thought we'd have to optimize it down to realtime level ;)
13:12:00Zagorpreglow: actually, gapless playback doesn't require two concurrent codecs. but voice and game sounds do.
13:12:05QTi think my best bet is to use read() and setting IFS to something giid
13:12:23Zezayerhey 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:36LinusNpreglow: i wanted you to sweat a little... :-)
13:12:36preglowZagor: ahh, no, do we ever require to _concurrent_ codecs?
13:12:42ashridahZezayer: define 'difficulties'
13:12:58Bagdercrossfading ;-)
13:13:03Zagorpreglow: yes, for mp3 voices during ogg music playback for instance
13:13:11preglowthat can be done by buffering pcm data a while in advance, heh
13:13:19preglowif our codecs are fast enough
13:13:27Bagderpreglow: that would be very short cross fade then
13:13:42 Join Patr3ck_ [0] (
13:13:50LinusNyou don't have to decode simultaneously
13:13:54preglowLinusN: around how many cycles does an sdram access use?
13:14:11LinusN5+1+1+1 for a 4 word burst
13:14:17preglowBagder: well, realtime beatmatching is pretty much out of the question, yes
13:14:23Bagderbtw, there's no daily odion FM build because we get a linker error
13:14:24LinusNbus cycles, that is, which is half the cpu frequency
13:14:34Bagder"region FLASH is full"
13:14:36preglowLinusN: ouch
13:14:50Zagorlinuxstb: does this differ much from what you had in mind?
13:15:00LinusNBagder: rombox?
13:15:00preglowso we might actually end up having to optimize codecs for size
13:15:07BagderLinusN: yes, for ondiofm
13:15:08LinusNpreglow: why?=
13:15:28Zagorpreglow: hopefully it's enough to put only parts of the codecs in inram
13:15:31LinusNi don't think the entire codec needs to be in iram
13:16:21preglowbut i guess imdct and those fellas are good canidates
13:16:31preglowhow much of the sram will be taken be other stuff, btw?
13:16:37preglowdoes the framebuffer have to live there?
13:16:46LinusNlcd framebuffer is there atm
13:17:52preglowbut yes, i tried optimizing synth_full in libmad yesterday, and i concluded it really saturated the memory bus
13:18:02preglowthere virtually no difference no matter what i do
13:18:04LinusNcurrently, we use about 6kbytes out of 96 :-)
13:18:35preglowat least my libflac optimization had _some_ impact
13:18:47linuxstbZagor: 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:37Zagorlinuxstb: i agree
13:19:44LinusNpreglow: would it help if some data was in iram too?
13:19:52preglowLinusN: most certainly
13:20:13LinusNso we would, for example, move the frame to iram before decoding
13:20:22linuxstbBut 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:31LinusNsine tables etc?
13:20:32amiconnBagder: The linker error for Ondio FM rombox has been there for a while. I wonder why the dailies worked before...
13:20:41preglowLinusN: yes, stuff like windows and twiddle factors
13:20:50 Quit Schnueff ("leaving")
13:21:10preglowLinusN: there's a pretty large array of constant numbers in libmad, for example
13:21:12Zagorlinuxstb: 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:27LinusNpreglow: is it really a dct, or is it an fft?
13:21:40preglowLinusN: libmad actually has both a dct and an imdct
13:21:55preglowLinusN: you can calculate it using an fft, but that's not done in either libmad or tremor, afaik
13:22:26LinusNtoo few points to really make a difference, ? guess
13:23:16amiconnBagder: 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:17preglowin what regard do you mean?
13:23:40LinusNhow many points are the dct calculated for?
13:23:45preglowin mp3, 36 or 12
13:23:50preglowdepends on transient detector
13:24:02preglowshort windows are used for transients
13:24:02Bagderamiconn: because the #defines doesn't work for the field members in the plugin struct
13:24:25preglowin vorbis, anything from 256 to 2048 can be used, two window sizes are set up in the header
13:24:42LinusN36 point fft sounds small
13:24:50Bagderamiconn: 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:56LinusNbesides fft wants a power of 2
13:25:10preglowyes, but using fft in an audio codec isn't really clever, mdct compacts more energy into fewer coefficients and thus compresses better
13:25:13LinusNvorbis sounds like an fft candidate though
13:25:35preglowit is if we can find a _very_ optimized fft routine
13:25:49preglowyou need to do pre and post sorting as well if you calculate it using the fft
13:25:50linuxstbZagor: 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:57LinusNpreglow: you're the expert
13:27:01amiconnBagder: The defines don't work for the struct members? I can't imagine why that is atm...
13:27:05preglowbut we'll see, not rewriting the codecs too much would be preferable, but does seem to be unavoidable
13:27:29Bagderamiconn: because the defines look like #define open(x,y) and in the struct they are int (*open)(x,y)
13:27:41amiconnAh, yes.
13:28:08Zagorlinuxstb: i think that is the way to do it. give the codecs a proper api callback struct just like the plugins.
13:28:29preglowbut 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:37LinusNpreglow: i'll look into the possibility to let the codecs copy code and data to iram
13:28:50Bagderanyone wants a cup of coffee?
13:28:55LinusNBagder: please
13:28:58preglowi'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:36linuxstbZagor: 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:07preglowLinusN: the coldfire timers are pretty high resolution, yes?
13:32:06Zagorlinuxstb: 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:49preglowi 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:12preglowsimple profiling could be done that way, unless i'm terribly wrong, which i probably am
13:33:27amiconnBagder: The simfix patch doesn't apply cleanly against cvs... uisimulator/common/dir.h fails
13:33:40linuxstbZagor: 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:52Bagderamiconn: that should be removed anyway
13:34:29amiconnYes.. I only wanted to mention it. You seem to have other changes there that aren't in cvs.
13:34:41Zagorlinuxstb: 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:06Bagderamiconn: oh, right, but it removes all lines ;-)
13:35:14preglowZagor: you fill the buffer completely, even though you can't fill the last track in its entirety, i hope?
13:35:26Zagorpreglow: yes
13:35:26linuxstbSome 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:28preglowZagor: good
13:35:37LinusNpreglow: coldfire has 1-cycle resolution timers
13:35:45linuxstbBut we can possibly work around that.
13:35:48preglowLinusN: would my profiling idea work?
13:35:48Bagderpreglow: with only 1.7MB buffer that is usually the case you know ;-)
13:36:31preglowBagder: hahaha, a miracle the disk doesn't wear out after a months use
13:36:37LinusNpreglow: yes it could work
13:36:39Zagorlinuxstb: 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:30linuxstbHow 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:31preglowdo 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:52LinusNpreglow: yes and no
13:40:39LinusNif your data is in sdram and the code is in iram, i'd guess that interleaving might be better
13:40:55LinusNnot necessarily though
13:41:14*LinusN is not a coldfire expert
13:41:15Zagorlinuxstb: 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] (
13:41:17preglowi guess this is a special case, since i'm fetching data from two different locations
13:42:02amiconnBagder: 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:13preglowwhich are sequantial, if i'm not mistaken, reading sequantially is a lot better than constantly switching to different addresses
13:42:50Bagderamiconn: let's ignore the link failure for now, what's the filetypes.c problem?
13:43:23LinusNpreglow: yes, sdram benefits from burst reads
13:43:49linuxstbMy 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:23linuxstbIf 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:54amiconnBagder: There's a heapload of errors, I'll send you the log
13:45:22Bagderlinuxstb/Zagor: we could also consider having a few selected codecs "built-in"
13:45:45Zagorlinuxstb: 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:49linuxstbIf the voice files are to be MP3, then it would make sense to have libmad built-in.
13:46:15ZagorBagder: it won't give us any benefit, only "cost" when not in use
13:46:26amiconnI can't remember how to redirect both stdout and stderr to the same file atm... anybody?
13:46:37BagderZagor: it could be a gain "in average"
13:46:50Bagderamiconn: > file 2>&1
13:47:23HCli 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:28ZagorBagder: 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] (
13:48:16Bagderit saves spinups if you use many codecs
13:48:33Bagderbut never mind, it was just tossing in an idea
13:48:36Zagorno, since loading a codec doesn't add a spinup. it uses the same spinup used to load the file.
13:48:37BagderI was
13:48:46BagderZagor: not if you use 5 codecs to fill the buffer
13:48:48amiconnZagor: What about the voice ui?
13:48:52ZagorBagder: yes
13:48:52Bagdersince they won't fit
13:49:10Bagderoh you can of course, right
13:49:19Bagderjust do it serially
13:49:25 Join AC [0] (
13:49:54Zagoryou're right, if you have more formats than slots you will get more spinups. but hardcoding codecs isn improve
13:50:06Zagorisn't any better than simply increasing the number of slots
13:50:58ACis it possible to get cvs write access?
13:51:13BagderAC: yes
13:51:20BagderAC: but you need to motivate it
13:51:27Bagderand prove yourself
13:51:27linuxstbThat'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:40Zagoramiconn: the voice ui will get its' own ram buffer that is locked and not used for music buffering
13:51:49ACi need the access for the wavpack codec
13:53:50linuxstbThe "loader" functions would also parse the metadata - this would be a good way to unify the metadata parsing in one place.
13:54:01Zagorlinuxstb: 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:25ACBagder: what do you need for informations for the cvs-account?
13:54:51linuxstbZagor: I don't think it's a big loss. New codecs will be rare.
13:55:36LinusNyes, but it would de impossible to have 3rd party codecs
13:55:54linuxstbWhy would we want third-party codecs?
13:56:33amiconnZagor: Yes, but the voice ui also needs the mp3 decoder
13:57:06amiconn(or any other compressed audio codec, but mp3 being the easiest)
13:58:01preglowamiconn: speex would probably be preferable for that
13:58:01Zagorlinuxstb: 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:45amiconnpreglow: 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:49LinusNlinuxstb: i can imagine that somebody creates a codec that we aren't interested to have in our cvs
13:59:19LinusNeither because it isn't particularly interesting, or because of patent issues
13:59:26LinusNor something else
13:59:31preglowamiconn: yes, and speex should be used from the start, imho, it's smaller and better suited
13:59:53preglowamiconn: size will probably not be an issue, forget it
14:00:03Zagoramiconn: 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:32linuxstbOK, I'm convinced now.
14:01:08Zagorlinuxstb: excellent! :-)
14:02:39ACwill be back... siwtching to linux to improve my wv2wav plugin
14:02:45 Quit AC ("CGI:IRC")
14:04:08ZagorLinusN: btw, the dma layer is present in the wiki page. it's the "feeder".
14:06:02linuxstbHowever, 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:41preglowlinuxstb: stripping out metadata how?
14:07:02Zagorsome code needs to do that parsing, and I thing the codec is the right code to do it
14:07:57Zagoragain, letting core rockbox do it would mean we cannot add support for any file format without modifying core rockbox
14:11:20jypWhat's ata_enable exact purpose ?
14:11:40LinusNenable the buffers for the ata interface
14:11:47jypIs it normal it is in disabled state when usb is plugged ?
14:11:55jypHello btw :P
14:12:19jypDo you think it is possible the gmini has no such a feature ?
14:12:43jypAlright, thanks
14:12:45LinusNit depends on the hardware
14:13:09 Join AC [0] (
14:13:36linuxstbZagor: 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:24linuxstbi.e. it's an optimisation that we don't have to implement for all the codecs - at least not immediately.
14:14:25ashridahLinusN: 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:35Zagorlinuxstb: exactly
14:14:36ashridahor isn't it that simple.
14:14:56linuxstbWe're happy then :-)
14:15:01LinusNashridah: the ata timings are taken from the IDENTIFY command
14:15:02Zagorvery :)
14:15:34LinusN120ns 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:16:31LinusNit might very well be brain damage in my end
14:16:42LinusNi certainly hope so
14:18:50LinusNand untimately, it might not even be the ata timing that is the problem
14:19:07LinusNit could be sdram timing as well, but i doubt it
14:19:30linuxstbZagor: 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:31LinusNamiconn: u there?
14:20:52Bagderannounce: fprintf() is soon known as fdprintf() in Rockbox
14:21:45Bagdersleep() is also subject for a rename
14:22:06Bagderto keep POSIX function names posix
14:22:24linuxstbBagder: How about "tsleep" for "tick sleep" ?
14:22:25Bagderbut we haven't come up with a good name for sleep() ;-)
14:22:28LinusNksleep() for "kernel sleep" maybe?
14:22:29Zagorlinuxstb: i'd like the codecs to be single-threaded. i think we should aim for that for starters, at least.
14:22:35ashridahrofl. i see someone made the minor change to the makefile i suggested.
14:22:38*ashridah exists!
14:22:39preglowtsleep for teick sleep? :V
14:23:50LinusNSleepOneTick(HANDLE hThread, DWORD dwTicks); :-)
14:23:55linuxstbZagor: 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] (
14:24:55Zagorlinuxstb: hmm you are right, yes we will need that (or a very large pcm buffer, which we don't want)
14:25:41LinusNZagor: it depends on how we design the codec thread
14:26:01LinusNthe swapping doesn't need a separate thread today
14:27:05 Join Bagder_ [0] (
14:27:15Zagorno 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:42Bagder_amiconn: try my new -2 patch from the same place:
14:27:42Zagorspinning up and reading 25+ MB from disk will likely take a while
14:28:20LinusNhow are the codecs designed? can we decode really small chunks at a time?
14:28:36Zagormy guess is that differs between codecs
14:28:38 Join CoCoLUS [0] (
14:28:57Zagorhowever i assume most codecs can decode subsecond chunks
14:29:18linuxstbLinusN: audio frames (the minimum data that can be decoded in one function call) are normally no more than about 20ms-30ms
14:29:31LinusNsomehow i feel that the stream-blabla stuff in the flac codec is really ugly
14:30:06linuxstbWhat do you mean? The API or the implementation?
14:30:10LinusNi want a clean buffer-in -> buffer-out concept
14:30:33LinusNthe api
14:30:43LinusNjust browsed the flac2wav plugin
14:31:16linuxstbYou have the "decode single frame" function - which will give you one frame of PCM data.
14:31:28LinusNthat sounds more like it
14:32:26linuxstbThat's what the flac2wav plugin is using - "FLAC__seekable_stream_decoder_process_single()"
14:33:08linuxstbThe 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:19HClamiconn: i'm getting the feeling your rockboy makefile doesn't clean when you do make clean
14:33:33 Join markun [0] (
14:33:37LinusNlinuxstb: maybe i just didn't look closely enough, my apologies
14:33:58Zagorlinuxstb: oh, that wasn't what I meant with adding a read callback :)
14:34:16linuxstbZagor: Yes, I know. We need two different read callbacks.
14:34:30linuxstbOr are you disagreeing with the second type of read callback?
14:34:31Zagorwhy can't the codec just use the ram directly?
14:34:47amiconnHCl: I would love to dig into it, but it may be really helpful to get the sims building again for that...
14:35:05LinusNamiconn: didn't you write a disk r/w test plugin?
14:35:08amiconnBagder: Do I need to revert the first patch before? (I guess so)
14:35:14Bagder_amiconn: yes, do that
14:35:21amiconnLinusN: yes I did
14:35:28LinusNcan you email it?
14:35:41amiconnLinusN: It writes a file full of pseudo-random data, then reads back and compares
14:36:01LinusNlooks like i need that
14:37:07linuxstbZagor (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:07linuxstb 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:39Zagorlinuxstb: 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:16Zagorrockbox 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 (
14:41:41preglowlinuxstb: agreed there
14:42:09linuxstbZagor: I'm not sure why you are against my idea of a read callback. I think it's a simple solution.
14:42:48ZagorI simply don't see why we need it
14:44:32linuxstbBecause 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:57Zagori think option 3 is the best way
14:46:20linuxstbOK, 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:14Zagorwe 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:18Zagorremember 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:28linuxstbWould that then mean that the codecs need to have two threads - one to read data from disk and one to decode it?
14:53:31Bagderan embryo
14:54:35Zagorlinuxstb: they do, but not because of this. they need that in any case.
14:55:20amiconnBagder: Your second patch has the same problem...
14:55:35Zagor(because we need to be able to refill the buffer while playing music, which could be done by the same plugin)
14:56:44linuxstbSo how much of the "compressed data buffer" would you give to a codec? All of it?
14:57:16linuxstbIt just seems that all the work of the "audio system" is now being duplicated inside each of the codecs.
14:57:27Bagderamiconn: can you dcc me the new output?
14:58:10linuxstbi.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] (
14:58:27Zagorlinuxstb: 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:39ZagorI don't see what is complex about it
14:58:46***Saving seen data "./dancer.seen"
14:59:29linuxstbBy "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.
15:00:15Zagori disagree. having a buffer does not mean it has to do any "buffer management". it's just a big chunk of ram.
15:00:23linuxstbWe 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:31Zagortrue. hmm, let me think about that a bit. back in a bit.
15:02:16linuxstbThe 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] (
15:02:29 Nick hcl is now known as HCl (
15:02:32*HCl whacks screen
15:12:50Bagderamiconn: ok, another shot. rerun configure after applying
15:14:11amiconnBagder: Did you change the patch?
15:14:29Bagderyes, there's a -3 now
15:18:28amiconnIn file included from filetypes.c:31:
15:18:28amiconnplugin.h:69:30: plugin-win32.h: No such file or directory
15:20:31LinusNBagder: do it right, once and for all :-)
15:20:44jypor use a CVS branch :P
15:20:44*Bagder swings for LinusN
15:20:51*LinusN ducks
15:21:31Bagderamiconn: try copying some of the plugin-win32.h file from uisim/win32 into the plugin.h file instead
15:22:07BagderI removed that dir from the include path when building firmware/ and apps/ stuff
15:23:02Bagderit felt like a clean break
15:23:57amiconnHmm. If I don't overlook something, files in apps/ and firmware/ should never include files from the uisimulator/ tree
15:24:19 Part Lurkski
15:24:20Bagderand that's why you get that failure ;-)
15:24:36Bagderthe plugin-win32.h is in uisim/win32
15:25:01amiconnBagder: I need to figure out which stuff needs to get included. That may be a problem doing in parallel to work...
15:25:24Bagderamiconn: well, if you could just confirm that doing it works, I can do it too in my end
15:27:18Bagderamiconn: or just try my -4 patch
15:27:57BagderI 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] (
15:29:58 Part LinusN
15:33:17amiconnBagder: 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:32HClanyone 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:49CoCoLUSyeah here
15:34:03HClit should work with current cvs
15:34:05CoCoLUSwhere to put the rom?
15:34:11HCljust anywhere
15:34:17HClyou need to install it as viewer
15:34:19CoCoLUSi have 18/2, that new enough?=
15:34:27HCli don't know, to be honest.
15:34:50*HCl is gonna run out of battery soon..
15:35:52linuxstbHCl: I can try it as well.
15:36:07HCli just need to know whether it still works or not
15:36:23HCli made a few changements to the physical storage of gameboy registers, in preperation for dynarec
15:36:29HClchanges* O.o;
15:36:33 Join R3nTiL [0] (~zorroz@
15:36:34HClgee, that was a bad typo >.>;
15:37:35linuxstbHCl: I get "incompatible version" when trying to load your plugin...
15:37:56linuxstbDo you have a rockbox.iriver I can use with it?
15:38:53amiconnlinuxstb: HCl extended the plugin api for rockboy, so you'll need the matching rockbox.iriver
15:39:37HCllinuxstb: hold on
15:39:41CoCoLUSme too
15:39:44HCli thought it was up to date, but i should have it
15:39:53HClon my ftp
15:41:02HClit actually is compatible with the old api, but it used a higher version number
15:41:15Bagderamiconn: try removing dir-win32.c from the uisim/win32/SOURCES
15:41:25Bagderit shouldn't be there for cygwin builds anyway
15:41:32linuxstbHCl: It's now running....
15:41:38Zagorlinuxstb: 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:43HCllinuxstb: okies
15:41:53HCllinuxstb: tell me if you get screen output / if it seems to work properly
15:42:04linuxstbHCl: But my screen has gone blank - not even the frame counter.
15:42:15HClhrm :/
15:42:25HCli don't understand whats going wrong :/
15:42:26linuxstbSorry, let me test again...
15:42:38Zagorcore rockbox also tracks remaining buffer, and triggers refill
15:42:39HClits not your fault, earlier i tried the same thing with a slightly different arrangement
15:42:48HCland it went completely nuts
15:42:52linuxstbThe frame counter has now appeared (after I pressed stop once)
15:42:58HClokay o.o
15:43:02HClwhat was it at?
15:43:16linuxstbIt's at 70 now.
15:43:26HCl :(
15:43:31preglowHCl: dynarec?
15:43:34HCl*doesn't understand why it won't work at all*
15:43:41HClpreglow: no, just some changes to the interpreter
15:43:54HClmoving registers to 32 bit vars and not storing them in 1 word in memory
15:44:07HClin preperation for dynarec
15:44:52 Quit HCl ("Lost terminal")
15:45:43 Join hcl [0] (
15:45:50hclscreen keeps crashing
15:45:53hcl >/
15:46:24jypIs there an api do dump textual data to disk ?
15:46:50linuxstbZagor: 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:54hcllinuxstb: did it show any output or did it just plain crash?
15:48:25CoCoLUSit loads the rom
15:48:33CoCoLUSshows a counter on the left top
15:48:35Zagorlinuxstb: enforcing a stream concept removes all possibility of mod and sid support, which is sad methinks
15:48:46hclCoCoLUS: whats the counter at?
15:48:47CoCoLUSthen i get small bars from the top to the bottom :)
15:48:49 Nick hcl is now known as HCl (
15:48:53CoCoLUS7, 8, something like that
15:49:00HClwhat rom are you loading?
15:49:08CoCoLUSthe from your ftp
15:49:09HClmario starts displaying at 14
15:49:15linuxstbNo 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:20HClokay, tell me if it shows anything when it gets to 14 o.o;
15:49:24Zagormods can be several megabytes
15:49:26*HCl 's class is starting..
15:49:28HClafk :/
15:49:39CoCoLUSok 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:19CoCoLUSim sorry i can't help you more, i'll be back later if you need some more testing
15:50:39Zagoralso, i still don't see how having a pointer to ram is complex
15:50:59linuxstbZagor: 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:21Zagoractually, the streamed concept is identical except you get lots of small buffers instead of one big.
15:51:26jypAnyways you'll have a certain amount of data not to discard
15:51:42HClCoCoLUS: okay, thanks
15:52:08linuxstbMy motivation is to try and keep the codecs simple.
15:52:33linuxstbHCl: No screen output, but I restarted it. Currently up to 170 frames.
15:52:41HCllinuxstb: what rom? mario?
15:52:49Zagorthat is a great goal, which I agree with. but what is more complex about having a large buffer instead of a small?
15:53:01HClits frustrating, it should work, i haven't changed anything that could affect this x.x
15:53:12HCli might have messed up some endianness
15:53:45linuxstbZagor: my concept is "no buffer" for the codecs. They just read data from the audio system.
15:53:49HCllet me build a new version..
15:53:58 Join Ka [0] (
15:54:03linuxstbHCl: It's "JetPac"
15:54:20Zagorlinuxstb: of course you have a buffer. you read data from the audio system into a small buffer, which the codec works on.
15:54:27linuxstbI did run it in earlier versions, and I'm sure there was screen output quite early.
15:54:58HClor not
15:55:03HCli'll bbl, battery empty
15:55:46 Quit Zezayer ("ChatZilla 0.9.61 [Mozilla rv:1.7.2/20040804]")
15:55:50linuxstbZagor: 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:25linuxstbi.e. the "wrapper" around libFLAC/libmad/whatever doesn't need to keep its own buffer.
15:56:40Zagorlinuxstb: yeah, the buffer is one frame long. that is not simpler, it just means a lot more function calls.
15:58:07Zagorthe fact that we'd need two ways of accessing the data speaks against the streaming solution, i think
16:00:28Zagoralso, 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] (
16:00:39Zagor(in case of vbr)
16:02:28linuxstbThe 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:50Zagorbut mp3 can't know - each frame can have different length
16:03:19preglowlinuxstb: libmad can do that too
16:03:49Zagordoes the read callback _really_ just ask for one frame at a time?
16:04:37preglowits guess is probably better than ours anyway
16:04:42linuxstbWe shouldn't care - the codec asks for whatever it needs.
16:05:08linuxstbWhich is the whole concept of the read callback.
16:06:22preglowbut what's the alternative? that rockbox guesses how much it needs?
16:06:35preglowcallback or no, the codec needs to tell how much data it'll like
16:06:48Bagderamiconn: new patch uploaded, I'll be off now for a few hours, but I'll return later tonight
16:07:00linuxstbpreglow: Zagor's alternative (IIUC) is to just give the codec access to a very large buffer to do what it likes with.
16:08:16preglowlike the main mp3 buffer?
16:08:47Zagorpreglow: yes
16:08:54preglowthat would be optimal, but it would have to handle wraparound and such
16:09:09preglowwe'd get away with no copy, which is a good thing
16:09:24Zagorit doesn't have to handle wraparound. that can be treated as a new buffer.
16:09:47Zagor(i.e. rockbox handles the wraparound)
16:09:47preglowwell, 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:06preglowwell, we'll need to hack the codecs, then
16:10:09preglowwhich should be avoided
16:10:23preglowafaik, the codecs depend on getting the amount of data they need
16:10:24preglownothing less
16:10:50Zagorthat's not a problem
16:10:57preglowwhy not?
16:11:23preglowit requires making the codec load functions able to exit in mid load, which might not always be trivial
16:11:44preglowunless you do a copy anyway, in which case you might as well go with callbacks
16:12:00Zagorit 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] (
16:12:11preglowyou have to buffer in advance
16:12:13linuxstbA 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:13Zagorso it needs to be able to load part of it
16:12:30Zagor<Zagor> (i.e. rockbox handles the wraparound)
16:12:32preglowZagor: yes, but it always needs one frame's worth of data
16:12:58preglowif the frame ends halfway through, with the other end lying somewhere in the start of the mp3 buffer, you have a problem
16:13:19preglowafaik, the process that fills the mp3 buffer just reads 'till there's no more space
16:13:24preglowso that might very well happen
16:14:18Zagorof course. i still don't see what the problem is.
16:15:03preglowthe 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:30linuxstbWe 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:30preglowyou 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] (
16:16:13Zagori prefer to avoid special cases altogether, if possible
16:16:42preglowa pure isstreaming() will do, just to let rockbox know if it has to care about prebuffering
16:17:06Zagor? rockbox will always handle prebuffering
16:17:10linuxstbZagor; 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] (
16:17:55preglowZagor: 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:34linuxstbThe 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:43Zagorpreglow: ah, good point
16:18:50preglowZagor: yes, i think so ;)
16:19:18preglowZagor: aborting a frame decoder in the middle of huffman decompression, for example, is going to be painful to code
16:19:39Zagorlinuxstb: i think we should only copy when necessary, i.e. at wraparound.
16:19:47preglowZagor: that's a good point
16:20:02Zagorbut i'm warming to the idea of having both ways to access data
16:20:08preglowbut that only applies if the codec itself knows how long the frame will be
16:20:18preglowi don't know how true that is
16:20:50preglowif not, we have to start copying buffers in advance within a certain threshold of the mp3 buffer end
16:21:08linuxstbZagor: 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:09preglowperhaps we can have the codec report max frame size
16:21:23preglowlinuxstb: they wont?
16:21:32Zagorlinuxstb: sure. but let's not add more copying than necessary.
16:22:37linuxstbpreglow: 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:52Zagorpreglow: i think we can define a max guaranteed contigous stream buffer size.
16:23:38linuxstbBut 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:38preglowbut anyway
16:23:46preglowbefore we venture too deeply into this
16:23:46 Quit markun ()
16:23:58preglowi very much believe the frame data might need to be in sram
16:24:08preglowso a copy might be necessary
16:24:34Zagorwhat is the max frame size of vorbis and flac?
16:24:44preglowa lot
16:25:11preglowwell, both supports very high bitrates, i don't know exact number
16:25:21linuxstbI'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:37preglowframe length for vorbis can be changed by the encoder
16:25:52preglowlinuxstb: how long is a flac frame?
16:26:33linuxstbSorry, I think I'm confusing bytes and samples and compressed/uncompressed frames. Let me double-check.
16:26:42Zagorwe 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:13linuxstbagreed. :-)
16:30:16Zagorthen 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:47linuxstbHow much sram is there?
16:32:11preglowZagor: no, i really think we'll end up using the entire sram for one codec
16:32:21preglowZagor: at least if we want to obtain at least a semblance of good performance
16:33:05preglowand not using the entire sram when you can would be a huge waste
16:33:19Zagorumm, that means we can only ever have one codec
16:33:25preglowyes, at a time
16:33:30linuxstbThat's going to take a lot of hacking into the codecs as well.
16:33:32preglowthey will have to be swapped in and out
16:33:59Zagorthat's really not what we want. but let's want and see what's possible first.
16:34:22preglowbut if we don't do it that way, we'll have to work wonders in size optimizing
16:34:41linuxstbAll 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] (
16:34:56preglowlinuxstb: yes, and very probably some important code
16:35:09preglowlinuxstb: like the lpc decoder in flac, and synth_full and imdct in libmad
16:35:37preglowbut reserving space for all possible decoders would be stupid, imho, worst case there should be room for two, but not all
16:35:53Zagornot all possible codecs. all slots.
16:36:08preglowahh, i'm not into the slot thing
16:36:10Zagorproposed default: 2
16:36:15preglowthen we agree once more
16:37:43 Join Lurkski [0] (
16:38:22 Join [IDC]Dragon [0] (
16:39:14Gwtf R3nTiL ?
16:39:47linuxstbSo 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_ (
16:40:11Zagorlinuxstb: I think I'd like both
16:40:18[IDC]DragonI know DirectShow
16:40:39[IDC]Dragonand some proprietary multimedia architectures
16:40:39preglowbtw, putting the frame in sram might be unnecessary after all, it's probably used sequantially
16:41:00[IDC]Dragonis DS, the work is split into a parser and a decoder
16:41:33[IDC]Dragonthe parser understands the file format and pumps the data
16:42:05[IDC]Dragonthe decoder receives a stream (normally), and pushes decoded data
16:42:26[IDC]Dragonthe full output buffer will then stall the process
16:42:27 Quit R3nTiL ()
16:42:30 Quit thegeek_ ("( :: NoNameScript 3.81 :: )")
16:42:46Zagor[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:02linuxstbBut 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]Dragonspinups are a new concept to these architectures
16:44:35Zagori thought we were finally agreeing :-)
16:45:02linuxstbZagor: I don't think we're too far apart :-)
16:45:44preglowbut you talk about accepting both methods now, and i don't really think they're mergeable, heh
16:45:49[IDC]Dragonanother idea I once had is to use the bib buffer as a "plain" disk cache
16:45:56preglowit's either callback or no callback
16:46:05preglownot using a copy buffer all the time is agreed upon
16:46:13preglowin the case of a callback, we have to copy
16:46:15[IDC]Dragonand read ahead as much as possible without trashing some to-be-used data
16:46:18Zagorpreglow: we can have two functions: give_me_x_bytes() or give_me_buffer()
16:47:04Zagor[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] (
16:47:30[IDC]Dragonno, cache only the data you're about to read
16:47:34amiconnZagor: I think the percentage of useless data is low
16:47:53Zagoramiconn: on average, yes. but why cache it?
16:48:14Zagor[IDC]Dragon: how do we know which data we're about to read? imagine playing sound off a dvd image.
16:48:19amiconnUm, because it makes the whole caching a lot simpler? Thinking KISS...
16:48:37Zagorsimple but inefficient
16:48:45[IDC]DragonZagor: the same way we do now: read ahead in the playlist
16:49:00Zagortoday we parse the file and only cache useful data
16:49:01amiconnZagor: I think the"sound from a dvd image" is a *very* exotic example
16:49:24[IDC]Dragonok, now I get you
16:49:42linuxstbamiconn: 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:04Zagoramiconn: 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:25amiconnThat means the codec is involved twice, at very differing points of time.
16:50:42[IDC]Dragonparsing and decoding
16:50:49Zagoryes, but that is no disadvantage. the spinup is already happening.
16:50:59amiconnFirst, when it comes to read data into the buffer, then when actual decoding takes place
16:51:12amiconnThat may mean to holding many codecs in ram...
16:51:27[IDC]Dragonthe parser may be re-used
16:51:30Zagorno. please read the log. we've been through this already :-)
16:51:32[IDC]Dragonlike for AVI
16:52:29Zagorwe started about 12:00
16:52:50Zagor12:46 to be exact
16:55:38amiconnEither holding many codecs, or frequently swapping in/ out, which might be necessary between refills (!)
16:55:45linuxstbZagor: 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:21Zagorparsing is generally not a cpu-intensive process. the formats are designed to be read with minial effort.
16:57:12linuxstbBut at the moment it looks like we will need every possible CPU cycle just to decode the audio.
16:57:19amiconnZagor: 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:40Zagorlinuxstb: indeed, but the parsing has to be done. it's not more efficient to do it later than sooner
16:57:56Zagoramiconn: yes. so we don't load all of them.
16:58:27amiconnThat would be even worse, imho. Not using the whole buffer we have to spare...
16:58:40linuxstbamiconn: 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:50Zagorread the log. there is no gain reading data you can't parse without another spinup.
16:59:42ZagorI'm afraid I have to go now. See you guys later.
16:59:46 Quit Zagor ("Client exiting")
17:01:35amiconnI still wonder if it would be better to build all codecs into rockbox after all...
17:02:41dwihnohow about similar units with less RAM?
17:02:54dwihnoI mean with a "generic" pcm driver
17:03:05dwihnoand how about playback buffer?
17:03:23linuxstbamiconn: Yes, that's an option, but it would be nice to not have to limit the number of supported codecs.
17:05:52jypIndeed, I'd like (at least part of) the codecs to be built in, since gmini has only 16k
17:06:02jypof code ram
17:06:43linuxstbjyp: Doesn't a limited amount of RAM imply a bigger need to have external, loadable plugins?
17:07:02dwihnoI'm with linuxstb
17:07:17dwihnoHaving everything as plugins has its pro's
17:07:28dwihnoMaximized playback buffer, for once
17:07:37linuxstbOr is it a case of so little memory, that the overhead of plugins is the problem.
17:07:39jypThat's fine as long as they are around 10k large
17:08:15preglowjyp: you've really got some nice limits going there
17:09:05dwihnojyp: how big are the plugins atm?
17:09:21jypThey aren't compiled atm ;)
17:09:26dwihnothey aren't?
17:09:32dwihnoboooo! :)
17:09:35jypThey aren't.
17:11:14amiconndwihno: 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:58amiconnImho it is impossible to support plugins on that. All plugins need to be compiled in
17:12:27jypMy thinking too
17:13:00amiconnSo for gmini, having all supported codecs builtin is actually a requirement...
17:13:01[IDC]Dragonis the flash sectored?
17:13:35dwihnoamiconn: aaah, that's sucky :/
17:13:37[IDC]Dragonso you could swap the plugin
17:13:40amiconn[IDC]Dragon: You don't propose swapping plugins in & out by flashing, do you?
17:13:48[IDC]DragonI do, yes
17:13:51 Quit Lurkski (Read error: 110 (Connection timed out))
17:14:00 Nick G is now known as thegeek (
17:14:01 Nick thegeek is now known as thegeek_ (
17:14:23jypProblem is the flash supports only 100000 erases
17:15:23[IDC]Dragonfor plugins, this may be sufficient
17:15:44[IDC]Dragonthe Odio flash has a similar rating, iirc
17:16:04jypAre you using this method on the ondio too ?
17:16:13amiconnjyp: No
17:16:16[IDC]DragonI meant the mass storage
17:16:35*preglow hugs his h120
17:16:52jypOk, so the plan would be to flash the plugins independantly...
17:16:55jypThat's fine
17:16:56amiconn[IDC]Dragon: Yes, but for the mass storage, we're trying to keep the flash wear ing low
17:17:39[IDC]Dragonstill, all the root file or fat modifications flash certain regions again and again
17:18:47jypIt's just as fine to flash the plugins separately, otho, why not have them compiled in ?
17:19:10[IDC]Dragonif it fits, ok
17:19:19[IDC]Dragonhow big is your flash?
17:19:49jyp1Mo, for the models examined
17:19:58jypmaybe 512k on others
17:20:00*[IDC]Dragon doubts he'll ever start 100000 plugins
17:20:30jypWe'd have a "plugin cache" anyways.
17:21:50jypI'm begging to find this idea very interesting ;)
17:22:11[IDC]Dragondidn't Archos sell plugins for the Gmini?
17:22:32jypplanned (rumors says), but never done
17:22:44[IDC]Dragonno, they do
17:22:54[IDC]Dragonhow's that done, technically?
17:23:07jypWhat do you mean ?
17:23:22[IDC]Dragonmy Archos contact told me they made a *lot* of money from Gmini plugins
17:23:59jypWhat do you mean, technically?
17:24:08[IDC]Dragonare they always in, and just enabled, or how do they load code?
17:24:38[IDC]Dragonthis was your problem, if you remember, harvard and stuff
17:24:50jypheh ;)
17:24:59dwihnoI 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]Dragontell that to M$
17:25:31jypMy idea is that "plugins" were a complete new firmware with additional features
17:26:00jypIn all the code I've revered, not a single trace of "loadable" plugins
17:27:41jypThere's is, however, a certain type of upgrade
17:27:59jypthat checked the HD serial number
17:28:20[IDC]Dragonthat sounds like it
17:28:39[IDC]Dragonthe plugins were somehow bound to the box
17:28:49jypbesides that is was a normal flash
17:29:01jyphence my previous hypothesis
17:29:40jypThey sold complete firmwares with plugins compiled in.
17:29:59[IDC]Dragonthen there must be a user option to extract that number
17:30:07jypyup, there is
17:30:14[IDC]Dragonto give Archos, when buying a "plugin"
17:30:23jypsplled out in the system menu
17:30:45jypand in a file on the hd
17:31:46[IDC]Dragonnow you want the file of a "loaded" box, eh?
17:32:26jypI think I can get away without it
17:33:44jypOn a different subject; let's say I want to dump a debugging trace in a file
17:33:52jyphow should I do it ?
17:34:40jyp(on the target of course)
17:35:28jypIs there some kind of "fprintf" ?
17:35:42HClno wonder rockboy choked >.>
17:35:59jypmmm, looks like I found it ;)
17:36:38HClyea, there is
17:39:07 Quit muesli- (Read error: 113 (No route to host))
17:42:51HClfinally, stupid endian problems
17:43:58 Quit Patr3ck_ ("User pushed the X - because it's Xtra, baby")
17:44:38jypgotta go
17:44:48 Quit jyp ("poof!")
17:45:46*HCl goes to eat dinner
18:02:05 Join muesli- [0] (
18:14:19 Join hubble [0] (
18:14:20 Quit muesli- (Read error: 54 (Connection reset by peer))
18:16:31 Join iSheep [0] (
18:16:39iSheepHi guys
18:17:51iSheepMy 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 ("( :: NoNameScript 3.81 :: )")
18:28:59 Join muesli- [0] (
18:42:00 Quit AC ("CGI:IRC (EOF)")
18:43:03 Join Lurkski [0] (
18:43:42Lurkskiplaying with a new client....can anyone see this?
18:44:17amiconn[IDC]Dragon: r u there?
18:44:44Lurkskicool....thanks rasher.....just had to make sure firewall was not mesing things up again. LAter guys
18:45:41 Part Lurkski
18:50:49amiconnBagder: r u around?
18:58:40[IDC]Dragonamiconn: now I've looked
18:58:49***Saving seen data "./dancer.seen"
18:59:58amiconnI 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:37[IDC]Dragonhmm, I once messed with elf
19:00:55*[IDC]Dragon tries to remember
19:01:49[IDC]Dragonhehe, you could make your loader a viewer for .elf
19:02:28amiconnHmm. 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]Dragonah, yes
19:03:07*[IDC]Dragon digs in old sources
19:04:24amiconnImho 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:03amiconnThat means, load the .elf bit by bit and directly link into the target ram area
19:05:23[IDC]DragonI'd say this is unnecessary complex, but still searching...
19:06:01 Join Stryke` [0] (~Chairman8@resnet-241-86.resnet.UMBC.EDU)
19:06:02amiconnYes, it is not absolutely necessary, but at least I would like to know if it's prossible
19:07:18[IDC]DragonI used some open source code to review an elf
19:07:30[IDC]Dragon... still searching...
19:08:26[IDC]Dragonperhaps it was elfdump
19:09:14 Join MO-Pantsu [0] (
19:09:42[IDC]Dragononce I went in an elf hexdum "by hand", but this was no fun
19:10:39[IDC]Dragonlook here:
19:11:17[IDC]Dragonyuck, c
19:11:24[IDC]DragonC plusplus
19:11:48[IDC]Dragoncgiirc refuses 'plus' characters
19:16:34 Join XShocK [0] (
19:19:52preglowXShocK: any luck on dma? :P
19:21:36amiconnHCl: 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]Dragonamiconn: I found my elfdump, it is ansi c
19:26:36 Quit DeadMan (Read error: 110 (Connection timed out))
19:27:38[IDC]Dragonnow trying to tell where I fond it
19:28:25HClamiconn: uh, i don't quite get what you meant with that XD
19:28:41HClbut yea, i altered the gameboy register memory layout, and its now suitable for dynarec
19:29:31amiconnHCl: 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:48HClhere's my memory layout as it is at the moment:
19:30:01amiconnI think that if you can get dynarec to work, I might be able to adapt this for sh1
19:30:09HClregisters a-e in 32bit vars, flags in 32 bit var, hl in 32 bit var
19:30:27HClsince hl is mostly used as an a# register, its more sensible to not split them up
19:30:43XShocKpreglow: no, couldn't make DMA work right
19:31:05amiconnHCl: Both host cpus are not too different. (1) 16 registers, with the 16th being the stack pointer. (2) big endian
19:31:15HClit nicely leaves me with 1 data register to still use
19:31:28HClunless i put HL in an address register
19:31:48amiconnSh1 is a bit more flexible, because there is no difference between address and data registers
19:32:25preglowamiconn: most instructions let you use both with the coldfire as well
19:32:46amiconnpreglow: Yes, I know. As you said, most, but not all
19:33:09amiconnBut there are some limitations of that kind on the sh as well
19:33:28HClyea, definately more flexible
19:33:34HCla# registers are really limited
19:33:37amiconnThere are r0..r15, but some ops are only possible using r0
19:33:49HClsounds mips like.
19:33:59HClonly mips4 has r0 hardwired to 0
19:41:02 Part hubble
19:44:16 Join funkymonkey [0] (
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] (
19:52:59 Join Sucka [0] (
19:59:53 Quit courtc (Read error: 110 (Connection timed out))
20:02:53 Join muesli- [0] (
20:11:04 Join jyp [0] (
20:17:05*Bagder appears
20:19:42amiconnhi again Bagder
20:19:49 Quit muesli- (Read error: 60 (Operation timed out))
20:19:58Bagderwhere did the latest patch error out?
20:20:42amiconnThe latest patch needs one slight change, then it compiles with a few warnings.
20:20:57Bagderyes, it did introduce a few new warnings
20:21:06amiconnHowever, it does not link at all, as the x11 sim compiled on cygwin
20:21:11Bagderand I haven't verified functionality properly yet
20:21:25Bagderso what's the needed change?
20:21:38BagderI mean for the error
20:22:37amiconnIn 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:03amiconnI got "too few arguments...." before I changed that
20:23:30amiconnBtw, why are some function calls enclosed in parentheses there?
20:23:46Bagderbecause of weirdo sim-#defines from the past
20:23:53Bagdershouldn't be necessary anymore
20:23:55amiconnAH, so this may go away
20:24:22amiconnThe linker throws a heapload of unresolved symbols...
20:24:42Bagderdo you have an older CVS around to compare link command line with?
20:24:57amiconnNo I don't
20:25:37amiconnI keep forgetting the correct command line to do a dated checkout...
20:26:26Bagdercvs update -D "date"
20:26:26BagderI think
20:28:01*amiconn fetches cvs as of Feb 16
20:29:09 Join Strath [0] (
20:33:30amiconnBagder: I need to remove the '@' in front of the command call from the Makefile in order to see the line, right?
20:39:18Bagderare you making one with the latest too?
20:39:47 Nick Sucka is now known as Sucka`away (
20:40:04amiconnJust a second; currently doing the same for X11 simulator & old cvs
20:40:16Bagderok, that's useful too of course
20:40:48*Bagder walk away for 5 mins
20:47:05 Part CoCoLUS
20:49:17 Join _CoCoLUS [0] (
20:51:05amiconnBagder: 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:11Bagdercan you understand why it complains on fdprintf() ?
20:55:13Bagderand for the link problems, can you try removing "-fno-builtin" from the Makefile in the build dir
20:56:33amiconnah, the fdprintf thing maybe because I forgot to reconfigure, lemme check
20:57:13amiconnI reconfigured today, but maybe that was before another change to configure...
20:58:09BagderI doubt that
20:58:48Bagderbut try a make clean first
20:58:52***Saving seen data "./dancer.seen"
20:58:54Bagderjust in case
20:59:36amiconnThat was indeed the problem, now X11 is on par with win32 - linker errors
20:59:55amiconnAgain a resume request...
21:00:39Bagderthat might be because I overwrite a previous file with the same name
21:01:02BagderI don't get it
21:01:12Bagderwhy doesn't fdprintf() exist as a function in plugin.c ?
21:01:21amiconnIt does now.
21:01:22HClfprintf does.
21:01:53Bagderamiconn: then please resend the log ;-)
21:02:07BagderHCl: not here, it is fdprintf() in my pending patch ;-)
21:02:16HClmhm :p
21:02:31 Nick _CoCoLUS is now known as CoCoLUS (
21:03:05Bagdertry removing "-fno-builtin" from the Makefile in the build dir
21:04:19amiconnHuh? The linker options for the Win32 sim seem to be those that are intended to build the X11 simulator ????
21:04:35amiconnexport LDOPTS=-L/usr/X11R6/lib -lSM -lICE -lXt -lX11 -lXmu -lSM -lICE -lX11 -lpthread
21:04:52Bagderhm, you're right
21:05:43Bagderhow silly
21:08:22 Join pillo [0] (
21:09:05 Quit preglow ("n00bix")
21:10:10Bagderamiconn: ok, there's a -6 patch uploaded now
21:10:21Bagderrequires a reconfigure
21:11:28 Join preglow [0] (
21:16:13 Quit rasher (Read error: 54 (Connection reset by peer))
21:16:17amiconnBagder: Now the mkdir() call has too many arguments...
21:16:45BagderI think I know why
21:16:46amiconnMaybe some option is set differently in the makefile, making cygwin require the other syntax?
21:16:55Bagder-DNOCYGWIN I believe
21:17:13BagderI added it now, since it was in the old one but not previously in the new
21:17:34amiconnThe -Dno-cygwin is there to create standalone Win32 binaries that don't require the cygwin.dll
21:17:58Bagderbut we don't care much about that
21:18:02amiconnThis is desired for the win32 sim, otherwise it's not possible to lauch it by double-clicking
21:18:58amiconnI'll re-add the #ifdef...
21:19:00Bagderso perhaps we should put the mkdir back again then
21:19:30 Join hubble [0] (
21:21:41amiconnBagder: Hmm, still doesn't link...
21:21:49 Join rashur [0] (
21:22:06amiconnDid you put the old log away?
21:22:16Bagderno, its still here
21:23:03*amiconn wants to send new log...
21:23:16Bagderwait, I notice a bug
21:25:16Bagderok, beam it over
21:27:07amiconnBtw, 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:14amiconn*am I wrong?
21:27:56Bagderyes they are
21:28:20amiconnHmm. There is an #include <sys/types.h> at the top. Is this correct?
21:28:28BagderI added such a file
21:28:42Bagderfor size_t, off_t etc
21:28:58Bagdergot bored by having to include file.h to get them
21:29:21amiconnHmm. The defines therein could also be made unconditional (?)
21:29:34Bagderdoesn't windows have a fsync() function ?
21:29:52Bagderamiconn: should be possible, yes, but I'm waiting with the beautifying things
21:30:21amiconnOkay, was just asking (partly myself) whether I understand what's going on...
21:31:40amiconnShouldn't this read sim_fsync for simulator builds?
21:32:02Bagderyes, if we need to replace it
21:32:07Bagderwhich we seem to need
21:32:49amiconnHmm. How is this handled in the old cvs build?
21:33:33hubblewow.. cool.. wav working
21:33:42Bagderamiconn: I don't really know why it works in the old one
21:33:52amiconn#ifdef WIN32
21:33:52amiconn#define fsync _commit
21:34:07hubblehow's the codec-interface going?
21:34:12amiconn(that's from the old uisimulator/common/file.h)
21:34:34amiconnThis seems to also use/need:
21:34:34amiconn#ifdef WIN32
21:34:35amiconn#ifndef _commit
21:34:35DBUGEnqueued KICK amiconn
21:34:35amiconnextern int _commit( int handle );
21:35:24linuxstbhubble: Read today's IRC log. I don't think anyone's coded anything yet (apart from what's in CVS).
21:35:47hubblelinuxstb: ok.. i guess wiki is not updated?
21:35:49Bagderamiconn: I'm moving that to uisim/common/io.c and adding sim_fsync() there
21:37:12amiconnThen you don't need the define, but simply the commit() call iiuc
21:38:08CtcpIgnored 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:17Bagderamiconn: uploading another version now
21:38:30HClmental note; never forget to clear newly allocated ram
21:39:41pilloyeah that's quite a GoodThing(tm) ;)
21:39:58 Join Chamois [0] (
21:42:20 Join ghode|afk [0] (
21:42:27amiconnBagder: Link problem with fsync() now gone. The other link problems are still there...
21:42:47amiconnI don't get why this doesn't want to link with windows native functions...
21:43:02ghode|afkpreglow: err hi, wondering if there is any update on the windows firmware patcher you were working on?
21:43:39Bagderno, that's weird
21:44:34amiconnHmm. Maybe the windows libs must be put after rockbox' own libs?
21:44:52Chamoisi read wav works
21:45:01amiconnI once had the same problem, obviously the order of -l options is sometimes important
21:45:02Chamoissound works on iriver ?
21:45:13preglowghode|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:28Bagderamiconn: yes, in not always so obvious ways
21:45:55ghode|afkok thanks
21:46:06amiconnThe 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:04Bagderamiconn: edit apps/Makefile (line 107) and move $(LDOPTS) to the end of the link line
21:49:29amiconnI moved it behind -lcomsim, this should be sufficient...
21:49:56pilloslightly 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:09XShocKcame back home
21:52:30hubbleXShocK: i got wav loading and playing from your code now =)
21:52:31linuxstbjyp: Are you around?
21:52:36amiconnBagder: The link problems with the various gdi functions are solved by that. However, it still errors on undefined references to _LoadLibrary / FreeLibrary ....
21:52:46XShocKhubble: good. :)
21:52:48hubbleXShocK: where did you get "*((&INTBASE)+8) = 72;" from and is it important?
21:52:49 Join courtc [0] (
21:53:20XShocKSecondary Interrupt 8, AUDIOTICK vector set to 72.
21:53:44amiconnBagder: Maybe the plugin_load functions also need sim_ implementations? Maybe a proper windows header needs to be included for these functions...
21:53:54jyplinuxstb: I'm here
21:54:04jypfor 1 hour maybe
21:54:04Bagderamiconn: I was just thinking in those lines too
21:54:04hubbleXShocK: where did you read that you could set that number? i didnt find it in the docs
21:54:14amiconnBagder: Want the log?
21:54:17Chamoishow many time for wav in cbs ?
21:54:27Bagderamiconn: nah, not needed for this
21:54:30XShocKi will look it up now
21:54:47linuxstbjyp: I think your CVS change has broken libFLAC.
21:55:27*Bagder walks away for a while
21:55:32linuxstbThat "realloc" is needed to allocate memory for the seektable - so a NULL pointer is now dereferenced.
21:55:47jyplinuxstb: mmm; I didn't intend to commit anything regarding libFLAC
21:55:54amiconnBagder: Same goes for the GetProcAddress warning...
21:56:07linuxstbIt's the latest CVS change - "typo" was your log message :-)
21:56:15XShocKhubble: of User Manual
21:56:28linuxstbAt 11.59 GMT today.
21:56:58jypdamn, I comitted the wrong file
21:57:14linuxstbNo problem. Is there an easy way to reverse it?
21:57:21jypI guess
21:57:23XShocKhubble: 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:34hubbleXShocK: aha, i though you only could set the INTBASE byte, not that it was an entire array =))
21:57:41XShocK*hardware or firmware :)
21:59:38hubbleXShocK: so we can skip to set the INTBASE byte only to set the AUDIOTICKS?
22:00:42XShocKhubble: repeat, i didn't understand what you said.
22:01:28linuxstbjyp: Shall I reverse your commit or will you?
22:01:40jypI'm looking into it
22:02:01jyptough I don't quite remember the adequate cvs command
22:04:20jypOk I'm committing the reversal
22:05:38jypPlease check that it's the correct thing
22:10:11 Join Patr3ck [0] (
22:13:38 Quit Stryke` ("Friends don't let friends listen to Anti-Flag")
22:15:26linuxstbjyp: Yes, that's perfect - a diff between 1.3 and 1.5 shows no differences. Thanks.
22:16:00jypYou're welcome; sorry for my bad move
22:16:09HClmy mobile phone company just managed to charge me MINUS 0.26 cents for using my mobile phone xD
22:16:27HClthey're actually paying me! XD
22:16:40preglowHCl: COMPLAIN!
22:16:48HClits hilarious
22:24:08 Join midk_ [0] (
22:30:24 Join LukeA [0] (
22:30:35jyplinuxstb: it would be really cool if I could chose to compile only certain codecs
22:31:00jypsince some cause compile errors
22:32:30linuxstbjyp: 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:50jypAlternatively, I'll have to commit workarounds for all the codecs...
22:33:07 Join Bluechip [0] (
22:33:27jypso, just a "weak" request.
22:34:05HClwell, my dynarec crashes on opcode 50... why is that..
22:34:42linuxstbjyp: Maybe we should make the codecs compile for you. Which ones work, and which ones don't
22:35:14jypFor now, none do :P
22:36:18HCli wish there was a normal way to debug this :/
22:37:50HClwatashi wa baka desu :x
22:38:15jypHCl: do the gdb stub :)
22:38:16LukeAhey, 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:37amiconnHCl: I hope you leave dynarec selectable via a #define, or are you going to implement dynarec for the sims too? ;)
22:39:23amiconnBagder: In case you're back: I have some more findings...
22:43:13HCli'm making progress.
22:43:23HClit can still be fairly easily to comment out
22:44:30Bagderback now
22:44:40amiconnNice :)
22:45:16amiconnTwo things: (1) It looks like we really need a simulator implementation for plugin_load()
22:45:47 Quit LukeA ()
22:45:49amiconnThe 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:12Bagderyeps, we'll do that for the sim version of plugin_load
22:46:17amiconn..because then there are conflicting types again (and no clear separation between target & sim code
22:46:57amiconn(2) The X11 sim does *almost* link now, only one undefined symbol left: _stderr
22:47:11amiconn(for debugf(), ldebugf() )
22:47:53amiconnThis is still crossing rockbox<->simulator. It looks like we need sim_debugf() and sim_ldebugf() too
22:48:58amiconnDid you try if your patches compile on Linux?
22:49:22Bagderplain linux, not the win32 crosscompile
22:49:38BagderI believe it will have some issues
22:49:44Bagderbut that's the least important version
22:49:48amiconnYes. You don't get the undefined _stderr?
22:50:08amiconnHmm. I wonder why
22:50:34amiconnThat 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:02BagderI believe its another issue with needing a system include file
22:51:17Bagderso makeing a sim_* version out of it should fix it
22:52:03amiconndebug.c includes stdarg.h. There is no stdarg.h in rockbox...
22:52:36Bagderbut there is in the sh include path
22:53:59 Join stripwax [0] (
22:54:07amiconnHmm. 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:31*HCl slaps himself.
22:55:41stripwaxgot 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:22stripwaxit's kinda like MMX or SSE on those Intel chips :-S
22:58:23amiconnstripwax: I think emac is handled the same way as the mac registers on sh - they're considered scratch registers
22:58:53amiconnAnd, since rockbox does not do preemptive multitasking, there is no need to preserve state
22:58:55hubblestripwax: we have cooperative multitasking?
22:58:56***Saving seen data "./dancer.seen"
22:59:24stripwaxI don't know how rockbox handles tasks. if it's cooperative I guess there's no problem!
22:59:44amiconnstripwax: extactly.
23:01:52preglowyes, like he says
23:02:22preglowif you depend on %%macx contents over a yield(), you're very optimistic, heh
23:03:22 Join DMJC [0] (
23:07:34stripwaxSomething 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:58preglowjust not done yet
23:08:18Bagderlots of consideration needs to be made first
23:08:25Bagdersince all lcd code assumes b/w
23:08:29amiconnstripwax: It's not the init. The graphics routines need to be rewritten
23:10:19stripwaxHow much is there though - line drawing and font rendering just need to plot two bits per pixel instead of one .. -?
23:10:50Bagderthen what would the point of using greyscale be?
23:11:12BagderI'd say fonts and lines etc should be able to use greyscales
23:11:33stripwaxthe two bits needn't be the same ;-)
23:12:16Bagderright, and then you need a new font format and lots of new code and protos ;-)
23:12:29amiconnYou need to be able to set the 'color' to use for the line/ pixel etc
23:12:38stripwaxI don't understand why you'd need a new font format. The iRiver stock firmware doesn't store colored fonts
23:12:43amiconnCurrently, there are set/clear/invert routines
23:13:03Bagderstripwax: we don't make their firmware ;-)
23:13:10Bagder*I* want multicolor fonts
23:13:26amiconnA new font format isn't necessary unless we want multicolour fonts, something unnecessary imho
23:13:27rashurThat doesn't go too well with using bdf fonts though does it?
23:13:47Bagderwe don't use bdf fonts
23:13:48stripwaxBadger - 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:56Bagderwe just convert from bdf to our own format
23:14:34stripwaxOk, antialias fonts will need a separate font file :-D
23:14:50stripwaxamiconn - right so maybe the Set function could take an (optional) color arg
23:14:59Bagderalthough I agree multicolor font is not #1 on my prio list ;-)
23:15:07amiconnAnd 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:21stripwaxSo just AND the font with a color and plot that
23:15:36amiconnCurrently, there are 3 functions for each mode (drawline/ clearline/ invertline)
23:15:54rashurBagder: well yes
23:16:19amiconnIf we change this to a similar approach as the grayscale lib already uses, there would only be one drawline function
23:16:57amiconnstripwax: Yes. drawline() draws black pixels, clearline() draws white pixels, and invertline() inverts all pixels
23:17:20amiconn(I know that there is no invertline, but for other function the is an invert* kind)
23:17:29stripwaxamiconn - by 'mode' did you mean 'drawing lines'? what are the other modes?
23:17:59amiconnNo, by mode I mean how the drawing functions behave
23:18:17amiconnCurrently, there is no mode concept, so all functions exist in different variants
23:18:24stripwaxwhat did you mean by "3 functions for each mode" then?
23:18:48amiconnNo, you got this slightly wrong (perhaps I was unclear)
23:18:56stripwaxset/clear/invert functions for lines, text, and what else?
23:19:27amiconnI mean, since there is no concept of drawing modes, there are (max.) 3 functions for one graphics primitive, i.e.
23:19:55Bagderamiconn: ... and there's now a -8 patch uploaded
23:20:12amiconndrawpixel/clearpixel/invertpixel, drawline/clearline/invertline etc.
23:20:41stripwaxamiconn - right ,so draw* could take an (optional) color arg .. .?
23:21:29amiconnYes, that would be one option, but this usually leads to unnecessary many arguments, which in turn leads to larger binaries
23:22:00amiconnPlease have a look at the grayscale lib. It uses a drawing mode concept, and a foregroud and background colour
23:22:16amiconnThe mode and the two colours can be set by separate function calls
23:22:20stripwaxamiconn - bigger binaries than having two functions to draw/clear every kind of graphic primative!?
23:22:38amiconnNope, but bigger binaries than with the mode concept
23:22:41stripwaxoh there's already a grayscale lib? ok I'll look at that. what uses it
23:23:02amiconnBelieve me, I first had the 'extra arguments' approach within the grayscale lib...
23:23:28stripwaxamiconn - no, I agree that a setforeground/setbackground is better
23:23:32amiconnThe grayscale lib currently only works on the archos devices
23:23:54amiconnsetforeground, setbackground, setmode, and (optionally) a function that sets all three
23:24:30stripwaxOk, 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:11Bagderstripwax: that was before amiconn's magic greyscale lib ;-)
23:25:14amiconnThe grayscale lib is only for plugins
23:25:31amiconnIt uses temporal dithering to simulate up to 33 grayscales
23:26:00stripwaxamiconn - heh, neat!
23:26:37amiconnIt's e.g. used by the jpeg viewer
23:28:05amiconnBagder: 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:48amiconnBagder: The linker errors with missing symbols are gone. :) However, now there is a duplicate symbol: _debugf :(
23:30:08Bagderdid you make clean first?
23:30:16Bagderthere's something broken with the dependencies atm
23:30:18amiconnYup, and reconfigured as well
23:30:18pilloHCl: coool!
23:30:24BagderI'll check
23:30:35Bagdernah, not needed
23:30:46 Join LinusN [0] (
23:30:46amiconn/uisimulator/common/io.c:346: multiple definition of `_debugf'
23:30:57HClpillo: well, it just yells out "unimplemented opcode!" at the moment, but at least, its finally what its supposed to be doing
23:31:04amiconnuisimulator/win32/debug-win32.c:51: first defined here
23:31:08LinusNthe emac accumulators are not preserved
23:31:23pilloHCl: cute anyways isn't it? ;)
23:31:47Bagderamiconn: you think the debug-win32.c approach is useful?
23:32:33BagderI'm not even sure what it does
23:32:44amiconnHmm. I don't know; didn't fiddle with windows debuggers so far
23:33:07Bagderok, I'll leave it in and make the other code x11-specific
23:34:09amiconnIt 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:26HClpillo: yup, now i can actually work on it
23:35:06Bagderamiconn: so if you "if 0" out the debugf functions in the bottom uisim/common/io.c can you link fine then?
23:36:08amiconnHCl: Is there some reading about dynarec you can point me to? I don't understand the following:
23:36:40amiconnYou say that z80 instructions are compiled into host instructions until a jump instruction is detected.
23:37:06amiconnHow is the case handled if some code jumps *into* such a chain?
23:37:08HClthats not in my dynarec yet, heh
23:37:21HClit recompiles a new block
23:37:34pilloHCl: 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:45amiconnHmm. Sounds a bit inefficient, memory-wise
23:37:58HClyup, in a way, they are.
23:38:05HClthere's room for optimization.
23:38:11HClbut its not nice to fix.
23:38:36HClyou're free to offer suggestions, heh.
23:38:42stripwaxIs dynarec something to do with the gameboy emulator?
23:39:25amiconnHCl: (<HCl> you're free to offer suggestions, heh.) That's why I asked for recommended reading...
23:40:23HCli'm not sure if i have much...
23:40:28HCllet me search a bit.
23:41:00amiconnBagder: Main simulator now builds & links. Even a number of plugin compiles & links fine. Then it errors in calendar.c
23:41:24HClhow's that?
23:41:27Bagder(ok, never mind that patch it is just that little fix)
23:41:56amiconnBagder: There are however warnings for the plugins about conflicting types... Want the log?
23:43:07amiconnBah, resume....
23:43:51amiconnI'll try x11 sim in the meantime...
23:44:54 Part stripwax
23:45:15 Quit midk_ ("Leaving")
23:46:00Bagderright, we need -fno-builtin to prevent warnings on some functions gcc has built-in stuff for
23:46:29amiconnBagder: The win32 simulator .exe runs, but the background image isn't there. The icon is also missing.
23:46:53 Quit methangas (" HydraIRC -> <-")
23:46:58amiconnI presume the resource file isn't included
23:47:44Bagderit is supposed to ;-)
23:50:08Bagderso what is the calendar.c problem?
23:50:43amiconnDid you have a look at the log? And/or deleted it, to avoid the dcc resume?
23:51:31 Join skav [0] (
23:51:31BagderI deleted it, it wasn't correct
23:51:56amiconnThere :)
23:53:06amiconnAh, it's fprintf...
23:53:08Bagdernow why didn't I see that? ;-) was a fprintf()
23:54:54amiconnThere are 'conflicting types for built-in function' warnings for the rockbox part too. Is that solved with -fno-builtin too?
23:57:01 Join Renko [0] (
23:57:01 Quit DMJC ("Leaving")

Previous day | Next day