--- Log for 25.02.105 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 21 days and 15 hours ago 00.01.21 Join amiconn_ [0] (~jens@pD95D1BED.dip.t-dialin.net) 00.02.06 Quit methangas (" Want to be different? HydraIRC -> http://www.hydrairc.com <-") 00.02.34 Quit amiconn (Nick collision from services.) 00.02.34 Nick amiconn_ is now known as amiconn (~jens@pD95D1BED.dip.t-dialin.net) 00.03.45 # good rule: pay attention to your clobber list 00.04.04 # hehe 00.04.51 # Good rule; I know what happens if you don't... 00.04.57 # yes, so do i 00.05.03 # like the lockup i jjust described 00.05.14 # i clobbered a5, my clobber list said a6 00.06.13 Join BoD[] [0] (~BoD@JRAF.org) 00.06.18 # wouhouyouhou ! 00.09.05 # so... 00.09.08 # what's up ? 00.11.43 # meh, watching jerks on this chat, pondering on leaving it, you? 00.12.11 # jerk, am i? :P 00.12.21 # noo 00.12.22 # XD 00.12.24 # not *this* chat 00.12.27 # ? 00.12.28 # this as in, this other chat 00.12.34 # sorry 00.12.41 # jerks on this other chat* 00.12.52 # SO ANYWAY 00.12.57 # what about iRiver ? :) 00.13.12 # i have trouble getting it to not crash on dynarec. 00.13.20 # dynarec? 00.13.20 # by which temperature does intel cpus start throttling? 00.13.32 # varies 00.13.50 # dynamic recompilation - for gameboy 00.14.16 # ohh 00.14.22 # wow 00.14.32 # this recompiles ? 00.14.50 # it writes coldfire code on the fly, yea 00.14.55 # I didn't know emulators did that 00.15.03 # coldfire ? :) (sorry) 00.15.07 # the iriver cpu 00.15.10 # ok 00.15.22 # ok now the big question 00.15.31 # and yea, its mostly used since.. n64 emulators got around 00.15.37 # what model should I buy 00.15.55 # h140 ? 00.16.12 # have you seen the pmp models ? 00.16.17 # yea, i have 00.16.22 # no experience with them 00.16.37 # read on a review that it doesn't have much battery run time 00.16.44 # yeah me too 00.16.56 # but I mean they're only a bit more expensive 00.17.00 # but they can play video 00.17.09 # yup. 00.17.17 # => dilemna 00.17.20 # :) 00.17.23 # its certainly an interesting thing 00.17.40 # i'm mostly waiting on something like that, but having a pda integrated 00.17.48 # ah yeah 00.17.54 # something like the zaurus sl c3000, but with more diskspace and more cpu 00.17.57 # well Archos have a thing 00.18.10 # linux based, IIRC 00.18.29 # preglow: Your remark concerning clobber lists reminded me of something... thanks :) 00.18.56 # amiconn: my pleasure 00.19.16 # HCl: will rockbox work on a H140 00.19.29 # BoD[]: it already does 00.19.33 # oh 00.19.35 # sorry 00.19.45 # no need to apologize 00.20.03 # oh nono 00.20.09 # I mean the H300 00.20.17 # probably, yes 00.20.24 # h1x0 and h3x0 are very alike 00.20.28 # ahhh 00.20.34 # that's a good news 00.20.37 # but as far as i know 00.20.54 # the h3x0 has DRM, and no digital in or/and out (it was either one, don't know which) 00.21.03 # it has no s/pdif, no 00.21.12 # oh :( 00.21.19 # but it has usb host 00.21.24 # and drm is something you don't really want either 00.21.35 # HCl: well, it's 100% firmware based 00.21.40 # preglow: it is? 00.21.42 # HCl: afaik 00.21.46 # Hmm, and H3xx has colour display, not good for battery life... 00.21.47 # didn't know that 00.21.49 # I think I need usb host 00.21.51 # HCl: you even loose it if you flash a korean firmware 00.21.56 # HCl: it seems to have a key in the eeprom 00.22.06 # preglow: i thought it said you just can't play drm files anymore if you flash with korean 00.22.23 # but ok 00.22.30 # HCl: yes, but if you flash back to us, you can't play either 00.22.36 # you'll never get the key back 00.22.43 # what does the DRM do ? 00.22.53 # let you play protected music files 00.23.11 # but for "regular" mp3 files ? 00.23.16 # can't the h1x0 play drm files? 00.24.08 # I don't think so 00.24.12 # cause ... who has these files anyway ? :) 00.24.40 # preglow: If you want to know of what you did remind me, see my commit. It's a minor thing though. 00.24.51 # if I had a drm wma, I'd just reencode it in mp3 00.26.12 # is there a feature comparison chart like the one for archos, but for iRiver ? 00.26.50 Quit jyp ("poof!") 00.29.07 # BoD[]: the comparison chart includes iRiver 00.29.19 # oops :) 00.29.32 # and do you have the url? 00.29.48 # hrm 00.29.59 # ok I found it 00.30.00 # sorry 00.30.07 # alright :) 00.30.09 # amiconn: i can't see how clobber list made you think of that, but whatever ;) 00.30.31 # I don't mean io.c, but the second commit 00.30.37 # (in apps/plugins/lib 00.30.39 # ) 00.31.19 # ahh, there are more 00.31.32 # a bit more related, yes 00.42.06 Quit lolo-laptop ("Client exiting") 00.44.34 # the Automatic Volume Control works with iRiver ? 00.45.36 # nothing much sound related is done yet 00.45.40 # ok 00.45.44 # just codec work and sound output 00.45.59 # ok 00.46.26 # I guess the chart should be re-done 00.46.55 # with a column "iriver with rockbox" and "iriver without rockbox" 00.48.30 # and also a column for each archos model 00.49.12 # what, you mean like this? http://www.rockbox.org/twiki/bin/view/Main/FeatureComparison 00.50.05 # it'll get a thorough update when we're closer to release 00.50.48 # yeah I mean this one, but updated 00.51.01 # hey 00.51.09 # well right now "Rockbox" just means "on any model" 00.51.11 # is there a database in rockbox now ? 00.52.05 # like browse by artist / track / album / year / any id3 00.52.28 # cause I guess that's possible on iriver (right?) 00.53.51 # hrmf 00.54.04 # hmm? :) 00.54.05 # my short frame imdct create funny noises 00.54.12 # yes, i think that's possible 00.55.47 # BoD[]: There is a database now, also uable on archos models. Allow browse by/ search for artist/ album/ track. No year, genre or other tag yet. 00.56.45 # Why the **** xxx2wav gets linked to alpine_cdc.rock in the sim ??? 00.56.50 # amiconn: did you know 68k assembly, again? 00.57.03 # Hmm, not really 00.57.17 # I have an Amiga, and looked into it a bit. 00.58.03 # I don't know all those special features. I guess SH1 asm won't help you ;) 00.58.08 # haha 00.58.09 # not much 00.58.10 Quit Sucka ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") 00.58.20 # i've got most of it 00.58.28 # no, the addressing probably isn't what's wrong anyway 00.58.31 # amiconn : that's great :) 00.59.15 Join mecraw [0] (~mecraw@69.2.235.2) 00.59.52 Quit Renko ("Leaving") 01.00.21 *** Saving seen data "./dancer.seen" 01.02.04 # preglow: I'm currently investigating the odd behaviour of plugins (esp. the codec plugins) in the cygwin simulator builds. I wonder what a .wav header has to do in all (!) plugins... 01.02.44 # Anyone here who does simulator builds on Linux, and could check whether there is a .wav header in them too? 01.03.27 # i'm yet to build a simulator at all, actually 01.03.32 # haha 01.03.42 # i guess that unintended 01.03.46 # that's 01.04.12 # Yeah, I guess so, too. The old builds (last week's cvs) don't have that. 01.04.30 # There is a .wav header defined in xxx2wav.c 01.04.32 # FOOL 01.04.33 # ARGHHH 01.04.55 # It seems this gets omehow linked to all plugins. It shouldn't.... 01.05.02 # small wonder everything sounds bad, i've forgotten to dereference a pointer 01.05.10 # oops 01.05.20 # and asm blocks aren't very good at complaining 01.06.28 # Even helloworld.rock contains a .wav header now.... 01.06.48 # hahahah 01.07.41 # hm, shouldn't the timer event registers on iriver... 01.07.46 # TER0 and TER1 be defined as MBAR+0x151 and MBAR+0x191 instead of MBAR+0x150 and MBAR+0x190? 01.08.18 # MCF54249UM.pdf page 178 01.08.49 # arg MCF5249UM.pdf 01.09.50 # i never thought i'd think 15 registers would be too little 01.14.00 # i wish the libmad makefile would pick up changes 01.15.15 # anyway thanks guys! 01.15.18 # i go to sleep :) 01.15.31 Quit BoD[] ("mblelop !") 01.17.43 Quit cYmen_ (Read error: 113 (No route to host)) 01.19.25 Quit Aison (Connection refused) 01.20.20 Quit markun () 01.21.34 # The memmove() implementation in xxx2wav is wrong.... 01.22.33 # It only works correctly if moving backward, i.e. dest addr < source addr 01.23.36 # nice 01.23.37 # The declaration is also wrong. The destination pointer obviously doesn't point to constand data 01.23.45 # *constant 01.23.59 # linuxstb: defend yourself! 01.24.01 # memmove() is used by libmad and tremor 01.24.14 # err, by libmad and flac 01.24.50 # memchr() is unimplemented & does nothing. This is used by flac & tremor 01.25.17 # (although for metadata resp. framing only) 01.28.48 # probably would have noticed it otherwise, yes 01.30.02 Join lostlogic [0] (~lostlogic@node-4024215a.mdw.onnet.us.uu.net) 01.35.10 Quit XShocK (" HydraIRC -> http://www.hydrairc.com <- IRC has never been so good") 01.41.40 # newby question: ICR0 is defined at address 0x04c, I want to change ICR2 at address 0x04e 01.41.45 # then I would do for example ICR0 = (ICR0 & 0xff00ffff) | 0x008c0000; /* Interrupt on level 3.0 */ 01.41.57 # is this correct? 01.48.14 # or would I do ICR0 = (ICR0 & 0xffff00ff) | 0x00008c00; /* Interrupt on level 3.0 */ 01.48.30 # Yup 01.49.06 # The coldfire is big endian 01.52.59 # so from left to right the first 0xff is stored at ICR0, second 0xff at ICR1, 00 at ICR2 and last 0xff at ICR3? 01.54.30 # correct 01.54.37 # thanks 02.06.22 # amiconn: Good evening :-) Firstly, the xxx2wav.o is part of the plugin lib - so it's linked against every plugin in the same way the grayscale lib is. Does your HelloWorld.rock contain the grayscale lib as well? 02.06.38 # No, it doesn't 02.07.29 # That's how a library works - an object from it is only selected for linking if the binary the lib is linked to requires a symbol that is defined by the library object 02.08.01 # Otherwise almost all plugins would become too big to load on the archos 02.08.29 # I understand that - so why does your helloworld.rock contain xxx2wav.o, but not the rest of libplugin.a ? It doesn't on my setup. 02.08.46 # I don't know, but I want to find out. 02.09.14 # Possibly this is related to the odd behaviour of the plugins here 02.09.50 # Sounds possible - the linker must be linking it for a reason - presumably I've reused a symbol I shouldn't have done. 02.10.21 # Yes, but that would also mean all the plugins contain an unresolved symbol they shouldn't 02.11.14 # Unfortunately the plugins on Win32 are dlls and no final binary, so no .map file is generated 02.11.38 # The strange thing is that the X11 sim helloworld.rock doesn't contain xxx2wav when compiled under Linux. 02.12.05 # i give up 02.13.38 # Yes, that's what I wanted to know. The X11 sim plugins on cygwin also don't contain that .wav header, but the Win32 sim plugins do. 02.14.46 # They didn't contain that before the new build system (but then there was no xxx2wav either), and they also don't contain it when I don't link against the plugin library 02.15.11 # (but the the codec test plugins don't link successfully for obvious reasons) 02.15.16 # *then the 02.15.34 # Going back to memchr and memmove. memchr is only used by functions in libFLAC and Tremor that we don't use - which is why there was no need to implement it. I apologise for my memmove (it was late, I wrote it very quickly just to get libFLAC to compile, and it never caused a problem, so I forgot about it). 02.16.33 # I didn't do anything about memmove() yet - first wanted to solve the odd simulator problems. 02.17.07 # A correct memmove implementation isn't hard though 02.18.13 # I agree - as I said, I just wrote it very quickly without thinking. 02.21.11 # Hmm, I just looked at the symbol tables of xxx2wav.o and helloworld.o. I can't imagine which symbol causes the linker to link xxx2wav.o to all win32 plugins 02.21.40 # I need to hide each single function and retry until I find the offending one. 02.22.48 # time for bed, later 02.22.57 Quit preglow ("yep") 02.25.11 # linuxstb: Your check of CONFIG_HWCODEC at the top of xxx2wav.c cannot work. 02.27.11 # Why not? 02.27.55 # Both symbols are defined in config.c and includes of it, which in turn get included by plugin.h You check before that... 02.28.05 # s/symbols/macros/ 02.29.02 # err, config.h I mean 02.29.11 # OK. But that check is also part of the plugins/lib/SOURCES file - so the check in xxx2wav.c is redundant. 02.29.14 Quit Patr3ck () 02.29.31 # Yes, it's only a safety measure. 02.38.37 Quit mecraw () 02.39.10 # will rockbox read pda documents? text only? 02.39.14 # I mean pdf 02.39.25 Join telliott [0] (~telliott@208-251-255-120.res.evv.cable.sigecom.net) 02.39.46 # If someone writes a pdf plugin, then yes 02.40.58 # linuxstb: It is definitely one of the system function equivalents in xxx2wav.c that causes this odd behaviour on windows. I 'just' need to find out which one... 02.41.16 # Hi. Anyone else notice a bug with playlist creation in the latest daily builds? With recursively insert turned on, rockbox only adds the first folder under the current one. 02.41.38 # I have a V1 recorder. 02.41.55 # telliott: Which build did you test? Iirc Linus fixed this recently 02.43.09 # 5/21 02.44.27 # The fix should be in 2005-02-22 02.44.34 Quit telliott (Read error: 54 (Connection reset by peer)) 02.45.33 Join telliott [0] (~telliott@208-251-255-120.res.evv.cable.sigecom.net) 02.46.09 # Got disconnected. I'm using Monday's build, 2/21 02.46.29 # [02:44:17] The fix should be in 2005-02-22 02.46.41 # As amiconn said, it was fixed on the 21st so the 22nd daily build should be OK. 02.47.01 # Thanks. 02.47.35 # I love the id3 database brower for finding stuff. Now I need to fix all my tags. 02.51.54 Quit DMJC ("Leaving") 02.52.50 Join DMJC [0] (~James@220-245-162-47-sa-nt.tpgi.com.au) 02.59.32 Part telliott 03.00.23 *** Saving seen data "./dancer.seen" 03.00.34 # linuxstb: Now I know which functions in xxx2wav.c fool the win32 linker - malloc() and free() 03.01.22 # It seems the linker wants to use these implementations instead of the system native ones for the dll init or similar. Of course this cannot work... 03.01.43 # That explains it then. 03.02.29 # So if this shall work on all simulators, we need a workaround. Obviously these functions must be called differently, at least for simulator builds 03.03.19 # That implies a (small) change to all codecs. They need to have a header which is included by all source files (I think all codecs have one) 03.03.38 # I think we can live with that. 03.03.39 # Then we need a #define similar to the ones in file.h 03.03.51 # #ifdef SIMULATOR 03.04.13 # Why #ifdef SIMULATOR? Can't we just rename them for all builds? 03.04.23 # #define malloc(blurb) sim_malloc(blurb) 03.04.40 # of course we could them rename in general 03.05.09 # Something like my_malloc() or codec_malloc() or such 03.06.59 # What do you think about adding a .h file in apps/codecs, and then including that from all the plugin files (via the "all.h" or whatever they use). 03.09.19 # Sounds reasonable. However, the question remains where this should be placed. apps/codecs would be first choice, but this header is also needed in xxx2wav.h, i.e. in apps/plugins/lib 03.10.17 # Why is it needed by xxx2wav.h? Don't we just need define codec_mallocd() etc in xxx2wav.[ch] ? 03.11.54 # Yes, I mean xxx2wav.c. This is where codec_malloc() and friends are defined. If we declare them in xxx2wav.h (which would be the canonical place), this declaration needs to be duplicated in apps/codecs/.h 03.13.21 # In fact, I wouldn't call these functions codec_*. They are placed in the plugin lib after all, and may also be useful for other plugins. One such plugin is rockboy... 03.13.47 # ...which may in fact be the cause why HCl didn't get it to run on the simulator 03.14.11 # There is also a private malloc() implementation in it... 03.14.37 # I think rockboy failed in the simulator before I added xxx2wav, but of course that doesn't stop it being a problem. 03.15.08 # Yeah - xxx2wav causes problems because it defines malloc(). Rockboy defines malloc() itself... 03.15.28 # But I think codec_malloc is the best name - the implementation is good enough to be used generally. They will only work if the "local_init()" function has been called - which also loads a Wav file. 03.15.38 # ^not good enough 03.16.30 # Yes, I saw that. Of course this can be remedied. Split xxx2wav in two - the general malloc() part and the .wav handling part 03.17.19 # I wasn't thinking that xxx2wav and the codec plugins would be permanent parts of rockbox - they are just there so people can test and optimise the codec libraries. 03.17.20 # The malloc() function would need some more work though. Somehow it needs to be initialised 03.17.50 # Yes of course. Still, the malloc() part may be useful in general - one more reason to split it apart 03.18.13 # I think Bagder has said that he's got a malloc implementation he can use in Rockbox - which I am assuming is better than my 6 lines of C. 03.18.19 # Anyway, that doesn't need to be done right now, and we should name these functions codec_* 03.20.48 # If you want to give it a shot, feel free to do so. Otherwise I'll try to do that tomorrow. I need to sleep now. At least I know what is going wrong. 03.21.41 # Night 03.21.48 # I probably won't have time - I have real work to do whuch is why I'm up at 2.18am. Maybe tomorrow. 03.22.00 # Night. 03.22.10 # Already 3:22 am here... 03.22.26 Part amiconn 03.31.25 Join ashridah [0] (ashridah@220-253-120-15.VIC.netspace.net.au) 04.05.23 Join QT_ [0] (as@area51.users.madwifi) 04.21.17 Quit shx (Nick collision from services.) 04.22.29 Quit QT (Read error: 110 (Connection timed out)) 05.00.25 *** Saving seen data "./dancer.seen" 05.19.07 Join ze__ [0] (ze@adsl-69-231-197-65.dsl.irvnca.pacbell.net) 05.27.40 Quit linuxstb (Read error: 60 (Operation timed out)) 05.29.27 Quit ze (Read error: 104 (Connection reset by peer)) 05.29.27 Nick ze__ is now known as ze (ze@adsl-69-231-197-65.dsl.irvnca.pacbell.net) 07.00.27 *** Saving seen data "./dancer.seen" 07.13.49 Join StrathAFK [0] (~mike@dgvlwinas01pool0-a239.wi.tds.net) 07.17.48 # Can anyone tell me how the Battery Chain is connected? Please take a look at this Image and imagine it was a recorder. It is mainly for orientation http://www.gofurygo.de/webpost/archos_fix_1.jpg 07.18.17 Join LinusN [0] (~linus@labb.contactor.se) 07.18.31 # Hey Linus... 07.20.22 # So, in the Upper right Edge of the Picture there is the "GND", Battery Minus to Metal casing and to Archos mainboard (Upper Right Middle Solder Joint)... 07.21.47 # In the Upper left edge there is Battery Plus to lower Battery Minus, and Upper Metal Casing to lower Metal Casing. 07.23.50 # In the lower right edge there is A contact made with Battery Plus, and from there to Archos Mainboard. Problem here is that somehow the Metal casing (which still is connected to Battery Minus on the other side) is also connected to Battery Plus - Voila my Short Circuit. 07.24.25 Join midk [0] (~midk@c-67-161-124-8.client.comcast.net) 07.25.23 # Now I removed the lower Metal casing and the left side PCB, but still the Minus Pole gets somehow connected up to Plus pole in the lower Right edge... 07.25.47 # Can somebody Point me in the Right direction where I've got to search? 07.26.45 # I have to admit that I tinned the Lower-Right-Contact and the upper left one, too. I hope that that doesn't cause the Problem... 07.27.10 # * einhirn sighs - 07.27.10 # *sigh* 07.29.03 # * einhirn makes sad face - "I just want my Recorder back" 07.29.29 # poor you 07.29.34 # Thanks... 07.30.13 # which model? 07.30.40 # Recorder - Well, I have to man myself, someone out there had to go through about 6 Month without his device... 07.31.35 # i haven't followed your case, could you brief me? 07.31.56 # short cut to the casing? 07.32.28 Quit Strath (Read error: 110 (Connection timed out)) 07.32.35 # which picture are you referring to? 07.32.45 # somewhere it seems like that. I entered a Picture link for orientation (before you got online) 07.32.45 # - just imagine it to be a recorder... http://www.gofurygo.de/webpost/archos_fix_1.jpg 07.35.05 # so when did the short happen? 07.36.05 # Err... I thought to be a smart guy. And soldered in the lower batteries using three pieces of wire... 07.36.29 # huh? 07.36.33 # I connected the wire to the Pads where the Batteries would have been seated... 07.37.05 # I did that because my batteries are longer than the original ones and were bending the PCB away... 07.37.15 # ok 07.37.51 # and you removed the end pcb? 07.37.56 # (And I removed the lower left spring to release the tension - so I had to solder the Battery... 07.38.01 # ok 07.38.05 # Yes, for "Diagnostics"... 07.38.38 # as far as i can tell, the pcb needs to be there for grounding purposes 07.38.53 # There I saw that the both Metal casings are connected together... 07.39.06 # allright 07.39.44 # Ok, then there is just the Problem why both, the Plus pole and the Minus Pole of the Battery Chain are connected to it... 07.40.16 # to the left pcb? 07.40.57 # On the Upper Right edge it seems to be designed to be so (Wire through the Spring, soldered to the metal casing) 07.41.09 # the ground, yes 07.41.53 # But somehow I get connection from Metal casing to Battery contact on the Lower right side too... 07.42.19 Quit ashridah ("out") 07.42.24 # I think I shorted some PCB Layers or something... (don't hope so because that would seem to be fatal?) 07.42.38 # take a look at this: http://www.rockbox.org/docs/repairbattery.html 07.42.57 # Jupp... Did so before... 07.43.21 # The connections to the Metal casings were stretched out of solder on all four corners... 07.43.33 # So I resoldered them... 07.43.40 # are you sure that you haven't accidentally enlarged the solder blob to the left? 07.44.17 # next to the digi i/o connector 07.45.48 # Have done so while resoldering the metal casing... but by now I removed the Solder because I removed the Metal casing (for diagnostiscs) 07.46.04 # Is that where the both layers are shorted? 07.46.13 # could be 07.46.18 # Hmm... 07.46.32 # if the solder blob extended to the vias next to it 07.46.53 # There are three contacts on the left side, each one of them was Seperate... 07.46.57 # how did you discover the short? 07.47.41 # Plugging in Batteries and them getting warm... The Blobs never (to my knowledge) extended to another via or something... 07.48.01 # http://www.rockbox.org/internals/rec_rear_top.jpg 07.48.29 # see how the early models didn't suffer from this? :-) 07.48.53 # they used Solder sparingly but twisted the Metal casing in... 07.48.59 # yup 07.49.38 # anyway, i think it will get hot if you connect to the via right next to the blob at "94V-0" 07.50.37 # That I didn't do... Well, as I said I have to admit that I tinned the Plus pole just left above the 0127 07.50.40 # also, you might have blown a circuit or two 07.50.51 # Oh... That would be bad... 07.51.14 # but you measure a short with a mutlimeter? 07.51.19 # multimeter 07.51.31 # Anyway, thanks so far - Will get back online when I am at my workplace... 07.51.37 # Good morning everyone! 07.51.40 # ok 07.51.43 # dwihno: morning 07.51.45 # Yup. Multimeter: Plus to Metal casing short 07.52.09 # i think you want to replace the 7416 above the lcd 07.53.21 # Hmm... I don't see anything tagged like that... 07.53.29 # IRF7416 07.53.35 # 8 pins 07.53.58 # Two 8Pin SMDs, both tagged 4463 07.54.05 # hmmm 07.54.40 # * einhirn has to go - can't afford being late... 07.54.45 # oki 07.54.52 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 08.07.26 Join methangas [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk) 08.50.51 Join einhirn [0] (Miranda@bsod.rz.tu-clausthal.de) 08.51.48 # Hello... I'm back... 08.52.44 # LinusN: My agenda now is to unsolder the HDD-Connector PCB from the Device and check if the Short is located on it... 08.54.23 # If the short is not located on that board, I'll take a look at the 8pin-SMDs, they seem to/should be the Transistors that control Main Power and HDD Power - right? 08.54.47 # yes 08.55.04 # Perhaps Google will come up with a way to test these - hopefully without needing to unsolder them... 08.58.42 # I am afraid of blowing something else if I just plug in my Multimeter (at least it works with 9V - so if it injects that somewhere it doesn't belong to, it'll blow; right?) 08.59.23 # Well, I'll come back to you when I have results of the tests... 09.00.30 *** Saving seen data "./dancer.seen" 09.02.00 Join Sando [0] (kekekek@CPE-147-10-21-132.vic.bigpond.net.au) 09.05.22 # einhirn: what kind of multimeter do you have that uses 9V to measure conductance??? 09.17.57 Join ashridah [0] (ashridah@220-253-120-34.VIC.netspace.net.au) 09.37.18 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 09.40.26 Join jyp [0] (~jp@239.90-201-80.adsl.skynet.be) 09.54.08 # What's the semantic of struct fat_cache_entry, field secnum ? 10.00.23 # huh? 10.02.52 # it's the sector number of the cached sector 10.09.22 # As usual I like being sure ;) 10.10.00 Join R3nTiL_ [0] (~zorroz@83.69.98.227) 10.18.24 Join Patr3ck [0] (~patr3ck@pD9ECFFCE.dip.t-dialin.net) 10.24.43 # LinusN: I tried yesterday to get the free timer on iriver to work 10.24.52 # and? 10.25.02 # LinusN: I only managed to freeze it ;-) 10.25.03 # But 10.25.14 # I cross checked everything and spotted 10.25.22 # that TER0 and TER1 are defined as 10.25.44 # MBAR+150 and MBAR+190 10.26.03 # shouldn't that be MBAR+151 and MBAR+191? 10.26.34 # not if you access them as a word 10.26.40 # mcf5249um.pdf page 178 10.27.00 # ok 10.28.07 # so that was not the problem... 10.28.17 # when i designed the mcf5249.h file, i was misled by the manual that said that the internal registers weren't byte accessible 10.28.36 # i'll change that some day 10.29.07 # no problem, I only thought this could be the problem why my iriver froze. 10.29.11 # hrm. odd 10.29.36 # rockbox took a few minutes to recalc fsinfo just after i'd been using the iriver stock firmware to record something. 10.30.03 # anyway, I got some reaction from my programming ;-) 10.30.11 # I will try again this evening 10.31.44 # ashridah: seems like iriver invalidates the fsinfo once in a while 10.32.17 # yeah. i think i've noticed it doing that once before. 10.32.29 # after plugging the device into a usb port on a pc 10.39.15 Quit R3nTiL_ () 10.41.26 Quit jyp ("poof!") 10.56.12 Join Aison [0] (~hans@zux166-181.adsl.green.ch) 11.00.32 *** Saving seen data "./dancer.seen" 11.12.22 Join webguest63 [0] (~c31ce021@labb.contactor.se) 11.39.09 Join muesli- [0] (muesli_tv@c-180-220-173.cvx-h.dial.de.ignite.net) 11.40.01 # high 11.40.06 # low 11.40.39 # :-) 11.40.44 # hi linus 11.41.04 # hey ho 11.44.19 # how's goin in sweden? rode a reendeer today? 11.49.32 Join amiconn [0] (~jens@pD95D1BED.dip.t-dialin.net) 11.50.08 # muesli-: of course 12.00.04 # :D 12.00.55 # people got very excited about the news of playing wavs 12.03.25 # omgomgomg! 12.03.28 # heh 12.04.21 # if it's just a standalone bit of code streaming a wav file to the audio output, bfd. if it's a built in thread that's feeding data from a refillable buffer... :) 12.07.27 # the hardest part is going to be determining the size of the output buffer that's going to be able to handle the worst-case scenario of codecs, AND codec swapping. 12.16.14 # uff, dunno too much about this..2 b honest..nothing... 12.17.34 # well. okay. it's not as simple as just writing data to the headphone's output. if you don't have enough buffered data already ready to go, then it's possible that the device won't have enough time to read and decode more from the disk to fill up the buffer before you run out. 12.17.39 # if that happens, you get a skip 12.18.10 # makes sense 12.18.36 # if we want to provide seamless playback between songs, we need the buffer to be big enough to handle the changeover from one codec to another, as well as reading new data from the next file. 12.19.21 # yepp 12.19.46 # most of the time, we will have several songs already loaded in memory 12.20.22 # so the pcm output buffer doesn't have to take disk loading time into account 12.20.31 Nick QT_ is now known as QT (as@area51.users.madwifi) 12.20.34 # LinusN: that's true. 12.20.40 # how many songs can you buffer in one turn? 12.20.44 # but you have to make some allowances for potential worstcase scenarios 12.20.50 # like having to load a new codec plugin 12.21.08 # muesli-: the mp3 buffer is about 30MBytes today 12.21.13 # which could co-incide with the near depletion of the buffer, so you need watermarks and other fun stuff ;) 12.21.24 # yup 12.22.03 # so theoretically there are 32mb / ~5mb for each file possible? 12.22.20 # roughly 12.22.44 # rockbox tries to fit as much data in the buffer as possible 12.23.23 # i wonder why there are only 32mb of buffer..rams arent expensive in these days.. 12.23.56 #