--- Log for 21.12.104 Server: niven.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 month and 11 days ago 00.08.27 Part amiconn 00.17.46 Join Mythril [0] (~chatzilla@216-210-228-4.atgi.net) 00.19.43 # I was wondering if there are any similiar projects for the Archos AV120 http://www.thinkgeek.com/electronics/mp3/5fe2/ 00.22.07 *** Saving seen data "./dancer.seen" 00.49.54 Quit Stryke` (Read error: 110 (Connection timed out)) 00.59.45 Join acidnite [0] (~c058a723@labb.contactor.se) 01.00.28 Part acidnite 01.12.00 Join webguest71 [0] (~40fc5e91@labb.contactor.se) 01.13.03 Quit webguest71 (Client Quit) 01.44.28 Join Digital007 [0] (~c35d210c@labb.contactor.se) 01.44.29 Quit Digital007 (Client Quit) 01.44.31 Join Digital007 [0] (~c35d210c@labb.contactor.se) 01.45.18 Quit Digital007 (Client Quit) 01.45.36 Join Digital007 [0] (~acbccfea@labb.contactor.se) 01.47.12 # Hi 01.50.04 Quit mecraw ("Trillian (http://www.ceruleanstudios.com)") 01.50.05 # Saw the progress with iriver 02.00.25 Quit Dulcise ("ChatZilla 0.9.61 [Mozilla rv:1.7.3/20040910]") 02.20.26 Join Stryke` [0] (~Chairman8@24-168-110-99.si.rr.com) 02.22.08 *** Saving seen data "./dancer.seen" 03.01.05 Quit Stryke` (Read error: 110 (Connection timed out)) 03.18.12 Quit Digital007 ("CGI:IRC (Ping timeout)") 04.22.09 *** Saving seen data "./dancer.seen" 04.30.31 Join Stryke` [0] (~Chairman8@24-168-110-99.si.rr.com) 04.48.34 Quit MooMaunder (Read error: 110 (Connection timed out)) 05.06.08 Quit Stryke` (Read error: 110 (Connection timed out)) 06.04.26 Join Nhanced1 [0] (~no@ip24-255-57-73.tc.ph.cox.net) 06.04.42 # hey guys 06.05.38 # * Nhanced1 can hear crickets 06.11.25 Join midk [0] (~midk@c-24-18-39-204.client.comcast.net) 06.12.10 # wow its dead in here 06.12.25 # are you around midk? 06.13.40 # yeah, what's up? 06.13.55 # nothin, lookin for someone to talk to 06.14.20 # you work on the archos or the iriver? or you a groupie too? hehe 06.14.48 # depends on what you'd define working on.. i created the clock plugin for rockbox (archos) :) 06.15.22 # nice 06.16.09 # what development platform do you use to code plugins for rockbox? I only know a little Java and we used eclipse, what language is used? 06.17.41 # rockbox is something like 95% C, and for me, linux for programming/compiling 06.18.14 # oh, i see, ive got mandrake on my laptop, what distro you running? 06.18.45 # mandrake as well :) 06.19.20 # I like its ease 06.19.37 # I didnt want to mess with it, but I like knowing I can 06.20.04 # yeah 06.21.30 # How did you get involved with rockbox in the beginning? 06.22.11 *** Saving seen data "./dancer.seen" 06.22.48 # mh.. ran into it reading reviews about the jbr20.. got one... learned a ton from just reading rockbox code.. did small modifications.. got a book... and now i have created the largest plugin for rockbox! mwawhha! 06.23.41 # wait.. you had C experience before rockbox right? 06.24.07 # nope 06.24.13 # wow, impressive 06.24.42 # how old are you if you dont mind me asking? 06.25.13 # If i had known what i know now when i had started, 75% of what I have now could have been done in just a couple days, meaning probably about 10% of the time 06.25.25 # 14 06.25.27 # :) 06.46.13 # Good morning! 06.53.13 # I was wondering if there are any similiar projects for the Archos AV120 http://www.thinkgeek.com/electronics/mp3/5fe2/ 06.54.35 # Judging from the discussions on this channel, I don't think the archos units will get another port 06.55.09 # dislike of the archos abound? 06.55.39 # If (read: when) the iriver port is completed, I wouldn't be surprised if the work on newer iriver models will be intensified 06.56.41 # dunno really 06.57.49 # There has been discussions whether the archos deserves rockbox at all 06.58.43 # 'deserves'? 06.59.09 # can't remember the details 06.59.14 # you can check the logs 07.01.55 # either way, imo a pointless topic... what hardware exactly 'deserves' attention? 07.02.18 # Well, cooperative companies 07.02.25 # Perhaps neuros? 07.03.01 # archos markedly uncooperative? 07.03.02 # Speeds up the port, the hardware gets the best firmware available, it's a win/win situation 07.03.27 Quit Nhanced1 (Read error: 110 (Connection timed out)) 07.03.53 # Björn or Daniel got a mail from "the big A", asking for permission to include the firmware on the driver disc 07.03.58 # afaik, that never happened 07.06.28 # they said ok as long as archos would give them some information, iirc, but archos never got back to them 07.08.10 # information wants to be free 07.10.27 # I can see they wouldn't want to release information without a NDA, but afaik, they didn't even offer that (even though it wouldn't be an option) 07.55.46 Quit midk (Remote closed the connection) 08.17.45 Join LinusN [0] (~linus@labb.contactor.se) 08.22.05 # You don't know how to get papers on processors used in mobile phones? :) 08.22.13 *** Saving seen data "./dancer.seen" 08.22.14 # Or whatever is ticking inside :) 08.35.39 Quit einhirn (Read error: 104 (Connection reset by peer)) 08.40.53 # dwihno: well, you'll need to find out which processor it is 08.55.47 Join amiconn [0] (~jens@pD9E7FF46.dip.t-dialin.net) 08.56.36 # dwihno: for the record, the main issue with archos regarding them distributing rockbox was that they wanted to issue a press release 08.57.10 # where we would claim that Rockbox was a collaboration project with Archos and us 08.57.32 # and we just couldn't accept that, since they haven't helped us a single bit 09.00.37 # LinusN: ah, okay. 09.00.49 # LinusN: WHen you say that, I do remember. 09.00.59 # I'm getting too old for this "software" stuff ;) 09.01.39 # and now, when archos has started refusing warranty repairs for those who have installed rockbox, we are even less inclined to port to another archos platform 09.02.13 # installed or flashed 09.02.18 # both, iirc 09.02.24 # flashed, I can understand 09.02.47 # Even if it's a lame excuse for poorly assembly 09.06.41 # yeah, i can stretch myself to understanding the flash case, if the fault was because of a corrupt flash 09.07.23 # Evil Company (tm) 09.07.39 # Or perhaps a new rockbox port would be in order to piss them off even more ;) 09.07.43 # nah, j/k 09.07.46 Join amiconn_ [0] (~jens@pD9E7F894.dip.t-dialin.net) 09.10.35 Quit amiconn (Nick collision from services.) 09.10.35 Nick amiconn_ is now known as amiconn (~jens@pD9E7F894.dip.t-dialin.net) 09.14.03 Join JJ-Demon [0] (~JJ@203-206-17-167.dyn.iinet.net.au) 09.15.03 Join amiconn_ [0] (~jens@pD9E7F586.dip.t-dialin.net) 09.17.45 Join amiconn__ [0] (~jens@pD9E7F5C6.dip.t-dialin.net) 09.18.49 Quit amiconn (Nick collision from services.) 09.18.49 Nick amiconn__ is now known as amiconn (~jens@pD9E7F5C6.dip.t-dialin.net) 09.18.54 Quit amiconn_ (Nick collision from services.) 09.19.25 # Bah, T-Offline :-[ 09.21.12 Join midk [0] (~midk@c-24-18-39-204.client.comcast.net) 09.37.32 Quit midk ("just STOP it arspy") 09.38.08 Join midk [0] (~midk@c-24-18-39-204.client.comcast.net) 09.50.53 Join amiconn_ [0] (~jens@pD9E7F63D.dip.t-dialin.net) 09.55.14 Quit midk ("just STOP it arspy") 09.59.16 Join amiconn__ [0] (~jens@pD9E7FF79.dip.t-dialin.net) 09.59.25 Quit amiconn (Read error: 60 (Operation timed out)) 09.59.26 Nick amiconn__ is now known as amiconn (~jens@pD9E7FF79.dip.t-dialin.net) 10.02.39 Join bobTHC [0] (~foo@l03m-40-193.d1.club-internet.fr) 10.02.42 # hi all 10.06.22 Quit amiconn_ (Read error: 60 (Operation timed out)) 10.22.14 *** Saving seen data "./dancer.seen" 10.22.37 Join MooMaunder [0] (~me@194.152.87.150) 10.22.43 # hi 10.22.52 # hi 10.23.26 Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) 10.26.41 # hi [IDC]Dragon 10.31.21 # <[IDC]Dragon> hi Jens 10.31.55 # <[IDC]Dragon> in case anybody saw my suggested options for the multivolume implementation, I went for 2) now 10.32.08 # Re your options for adding the volume/disk parameter: I also thought about this problem some time ago. 10.32.23 # <[IDC]Dragon> making a little macro to hide the extra argument, member, etc 10.32.29 # I'd go for the macro-that-conditionally-folds-to-nothing solution 10.32.50 # <[IDC]Dragon> yes, that's how I started it now 10.33.30 # <[IDC]Dragon> but had some struggle with a comma in the macro 10.34.29 # <[IDC]Dragon> I solved that with a different macro for anything containing a comma 10.35.08 # <[IDC]Dragon> haven't proceeded to struct members yet, dunno how a semicolon will work out 10.35.51 Join amiconn_ [0] (~jens@pD9E7EA9D.dip.t-dialin.net) 10.36.01 Quit amiconn_ (Nick collision from services.) 10.36.36 Join amiconn_ [0] (~jens@pD9E7EA9D.dip.t-dialin.net) 10.36.45 Quit amiconn (Nick collision from services.) 10.36.46 Nick amiconn_ is now known as amiconn (~jens@pD9E7EA9D.dip.t-dialin.net) 10.37.57 # amiconn: did you mail the guy who wrote the player flash bug report we discussed? 10.40.46 # [IDC]Dragon: IMHO, major preprocessing is not very KISS 10.43.37 # <[IDC]Dragon> I know, and didn't like the other options, too 10.43.44 # <[IDC]Dragon> any idea? 10.46.27 # Iirc, the STR() macro does the same 10.46.38 # i think option 3 looked ok 10.46.45 # <[IDC]Dragon> which wasn't very nice, either 10.46.50 # which functions are we talking about? 10.46.53 # <[IDC]Dragon> the STR(), I mean 10.48.00 # <[IDC]Dragon> low-level file and fat 10.48.53 # <[IDC]Dragon> in case 3) will be acceptable, I still would start with the macro way 10.49.04 # <[IDC]Dragon> it can be easily removed later 10.49.12 # sure 10.49.17 # <[IDC]Dragon> but is difficult to introduce 10.49.41 # <[IDC]Dragon> afterwards 10.50.16 # <[IDC]Dragon> plus, we can count the macro usage and base a decision on that 10.50.46 # i think 3) is best too. the extra code isn't huge and won't make stuff much more complex. in addition, we will be able to support multiple partitions for people who like that. 10.51.41 # <[IDC]Dragon> right now, we don't know the penalty, so I'd prefer to have it conditional first 10.52.52 # we don't know the penalty? 10.53.00 # <[IDC]Dragon> do you? 10.53.31 # i would expect you did, since you have the code :) 10.53.58 # <[IDC]Dragon> I started writing some smaller fraction yesterday 10.54.39 # <[IDC]Dragon> bottom-up, not much more than the ata read/write yet 10.54.47 # aha, ok 10.55.19 # <[IDC]Dragon> nothing that does something useful yet 10.56.07 # I dislike option 3, as I much dislike unused code 10.56.46 # i guess the multiple buffers are the greatest penalty. we might want to make the number of volumes configurable, to avoid wasting ram unnecessarily. 10.57.59 # amiconn: well there shouldn't be much unused code really. just code that supports something not everybody uses. 10.58.13 # <[IDC]Dragon> I have made a #define for the # of volumes 11.00.07 # i think you should do what is easiest for you right now. then we have a basis for discussion and can adjust it later if we want to. 11.00.24 # incremental development 11.00.26 # Zagor: Of course the buffers are the greatest penalty. I mean, unconditionally adding the volume parameter to the api functions adds unused code to the platforms which don't support multiple volumes 11.01.11 # amiconn: the harddisk units could use multiple volume support too. we've had requests for multiple partition support, for instance. 11.02.19 # There are actually 2 different levels where support is needed: (1) multi-volume for the file system. While this might be useful for supporting multiple partitions, I don't see the advantage of doing so 11.03.01 # (2) mutli-disk support in the ata driver. I don't see how this could be useful for the hd based units 11.04.47 # i agree. however i don't think multi-disk ata support will add so much code that it's worth the extra complexity of having it compile time selectable. but we will see. 11.06.56 # [IDC]Dragon: Did you read the mail about the Studio 20 which displays "Wrong Boot ROM" when trying to flash? 11.07.07 # <[IDC]Dragon> no 11.07.14 # <[IDC]Dragon> mailing list or forum? 11.07.18 # ml 11.07.24 # * [IDC]Dragon looks 11.07.50 # It looks like this box actually got a *different* boot rom... 11.08.56 # <[IDC]Dragon> interesting 11.09.13 # <[IDC]Dragon> we never had that, across all platforms 11.10.12 # I just sent an answer. The ROM dump could be very interesting... 11.12.14 # <[IDC]Dragon> maybe it's a ROMless player 11.12.23 Join Lynx_ [0] (HydraIRC@134.95.189.59) 11.13.03 # [IDC]Dragon: Shouldn't the flash plugin then request the _norom.bin, instead complaining about wrong boot rom? 11.13.41 # <[IDC]Dragon> perhaps. dunno if that check is done the same way for players, but likely 11.13.59 # <[IDC]Dragon> let's wait until we have a dump 11.16.25 Quit bobTHC (Read error: 110 (Connection timed out)) 11.19.39 Join ripnetuk [0] (~george@82-70-100-230.dsl.in-addr.zen.co.uk) 11.23.10 # Has anyone else found that plugging in the iRiver into a Linux box and THEN turning it on causes Linux to not pick it up? its fine if I turn it on first. (2.6) 11.23.34 # i did just that and it worked fine for me 11.24.00 # it used to work on my old distro (MDK 10.0) but now on MDK 10.1 it fails. I suspect UDEV is the culpret :) 11.24.54 # did you check dmesg or lsusb to see if the device was seen at all? 11.28.06 # not yet... lsusb sounds helpful ;) 11.29.32 # i basically wanted to know that other people using udev could get it working ok... 11.29.47 # will check lsusb tonight 11.29.51 # thanks :) 11.32.14 Join amiconn_ [0] (~jens@pD9E7F904.dip.t-dialin.net) 11.32.42 Quit amiconn (Nick collision from services.) 11.32.43 Nick amiconn_ is now known as amiconn (~jens@pD9E7F904.dip.t-dialin.net) 11.42.06 # <[IDC]Dragon> amiconn is today's AciD 11.42.51 # Grr, my DSL connection is sometimes flakey. I dunno why; T-Online blames T-Net and vice versa :-[ 11.43.56 # Zagor: I now sent an email concerning the shutdown problem, as well as putting my questions in the tracker. 11.50.06 Join amiconn_ [0] (~jens@pD9E7E9F1.dip.t-dialin.net) 11.51.40 Quit amiconn (Nick collision from services.) 11.51.41 Nick amiconn_ is now known as amiconn (~jens@pD9E7E9F1.dip.t-dialin.net) 11.52.35 Quit MooMaunder (Read error: 104 (Connection reset by peer)) 11.58.59 Join MooMaunder [0] (~me@194.152.87.150) 12.12.13 Quit ripnetuk ("Leaving") 12.22.18 *** Saving seen data "./dancer.seen" 12.22.37 Join ehdeixtezet [0] (edx@p54879546.dip.t-dialin.net) 12.26.59 Join amiconn_ [0] (~jens@pD95D18A8.dip.t-dialin.net) 12.27.03 Quit amiconn (Nick collision from services.) 12.27.05 Nick amiconn_ is now known as amiconn (~jens@pD95D18A8.dip.t-dialin.net) 12.27.42 # amiconn: your disconnect message is "Nick collision from services". it doesn't sound like a connection problem. 12.28.12 # Nope. This is what I do when I reconnect after getting disconnected 12.28.32 # "/msg nickserv ghost amiconn " 12.29.10 # aha 12.29.30 # It is definitely a connection problem, the DSL modem gets desynchronized (sync led becomes red), and the connection breaks because of that 12.29.37 # ok 12.29.53 # I contacted T-Net again, hopefully they find the cause 12.31.58 # *Once* I accidentally "ghosted" myself 12.49.15 # [IDC]Dragon: Do you know whether the boot rom is also partially scrambled? 12.50.06 # what does the ghost do? 12.50.24 # <[IDC]Dragon> amiconn: the boot rom is unscrambled 12.50.57 # <[IDC]Dragon> have you gotten the dump already? 12.51.23 # Lynx_: If you registered your nick, and get disconnected, you can "ghost" your previous nick. This makes it go away immediately, instead only after the (reletively long, on freenode) timeout 12.51.45 # ah, ok 12.52.43 # [IDC]Dragon: Nope, only asking preventively. 12.53.39 # I did not yet analyze the original bootrom completely, only small parts 12.53.48 # <[IDC]Dragon> I did 12.54.05 # (e.g. the part where the lcd lines are checked, to find I need to pull pb1..pb3) 12.55.07 # <[IDC]Dragon> I must have a commented disassembly somewhere 12.56.05 # Meanwhile it isn't hard ffor me to read SH1 disassembly as-is. 12.56.47 # <[IDC]Dragon> I started my flash adventure in the boot rom 12.57.14 # <[IDC]Dragon> I've been quite slow on it, took me a while 12.59.03 # <[IDC]Dragon> and I commented most of the lines, went thoroughly 12.59.27 # <[IDC]Dragon> found it, do you want it? 13.00.42 # I did a similar thing with the MMC driver part of the Ondio firmware (Though I did the commenting the old-fashioned way - with a pen on a paper printout) 13.01.17 # Could be interesting, yes please. 13.03.37 # <[IDC]Dragon> ok, sent 13.04.22 # <[IDC]Dragon> I also ran it through an instruction set simulator 13.05.55 # If this odd Studio 20 really has a different boot rom, but the flash content is the same, I think flashing the same firmware .bin should be safe (as long as the alternative boot rom doesn't check a new checksum or such). The good thing is that both ROM version and archos fw version of this box are the same as mine 13.06.51 # <[IDC]Dragon> maybe it has a flaky rom 13.11.05 Quit Ka (Nick collision from services.) 13.12.45 # Imho that would be even more strange than a really different rom, as the boot ROM is internal to the CPU 13.13.35 Join Ka_ [0] (~tkirk@pcp0010732484pcs.howard01.md.comcast.net) 13.48.40 Part amiconn 14.22.19 *** Saving seen data "./dancer.seen" 14.24.43 Join bobTHC [0] (~foo@l03m-40-193.d1.club-internet.fr) 14.24.45 # re 14.29.27 # is the tag database being worked on by anyone? 14.32.12 # yes, me 14.32.51 # Zagor: cool :-) 14.33.03 # but i want to release 2.4 before i commit this code 14.33.23 # Zagor: so it's progressed to a usable state already? 14.33.34 # yes 14.34.44 Join Quelsaruk [0] (~kvirc@80.103.138.199) 14.34.51 # hi 14.34.52 # :) 14.35.01 # yo 14.35.17 # so long time amigo ;) 14.37.32 # Zagor: but i guess it will be some time before 2.4 comes? 14.37.54 # hi bobTHC 14.37.56 # :) 14.37.59 # no, 2.4 is due rather soon 14.38.12 # christmas present? 14.38.21 # possibly 14.38.25 # it's will bea agreat one 14.39.06 # s/bea/be 14.39.32 # btw, i suggest we (developers) mark bugs we consider release critical priority 9. 14.40.25 # do we have any candidates for that right now? (I don't consider player flashing release-ready yet so that does not count) 14.41.25 # :) 14.47.47 # i don't have any candidates 14.48.33 # Zagor: can i look in the wiki what the major changes towards 2.4 are? 14.49.23 # there are no major changes 14.49.23 # iriver suppoert ;) 14.49.35 # mainly bug fixes 14.50.01 # ok... 14.50.59 # <[IDC]Dragon> small bug fixes 14.51.26 # <[IDC]Dragon> we never had such a small step like the 2.4 release, if it happens now 14.51.53 # <[IDC]Dragon> anything visible to the user? 14.52.26 # <[IDC]Dragon> I don't dare to ask it a feature 14.53.59 # frequent releases are good, it brings the bug fixes to more users 14.54.40 # <[IDC]Dragon> I'm not argueing 14.54.49 # ok :) 14.56.32 # <[IDC]Dragon> the good thing is that that the documentation is still up to date 14.57.14 # except for the ondio stuff 14.57.50 Quit MooMaunder () 14.58.07 # <[IDC]Dragon> different topic: do you agree that a joint FAT cache is sufficient? 14.58.34 # LinusN: I forgot to congratulate you on your progress! I salute you (and you other HW ninjas out there, I am in envy of your knowledge!) 14.58.47 # a single cache, shared by all volumes? or a single cache, invalidated when you change volume? 14.59.09 # <[IDC]Dragon> then I'll add the volume to the struct, instead of duplicating it 14.59.49 # <[IDC]Dragon> shared cache, yes 15.00.22 # <[IDC]Dragon> it's unlikely that you work with files on different volumes at the same time 15.01.10 # unless of course the playlist is on one volume and the actual song is on another 15.01.34 # but I agree a little performance penalty in such a case is acceptable 15.02.37 Join amiconn [0] (~jens@pD95D18A8.dip.t-dialin.net) 15.03.00 # <[IDC]Dragon> the size of 32 sectors hasn't been determined by statistical analysis, I bet? 15.03.13 # no 15.03.21 # just a finger in the air :) 15.03.49 # <[IDC]Dragon> that's proven analysis ;-) 15.04.43 # I guess working with files from both volumes at once will occur quite often: playlists from one, track from the other; playlist control file, working with plugins... 15.05.18 # <[IDC]Dragon> yes, but sequentially 15.05.18 # Plus, the file/directory moving has to be cross-volume aware 15.05.38 # <[IDC]Dragon> which file moving? 15.09.41 Join thegeek_ [0] (~thegeek@ti521110a080-1161.bb.online.no) 15.09.54 Nick thegeek_ is now known as thegeek (~thegeek@ti521110a080-1161.bb.online.no) 15.16.36 Join MooMaunder [0] (~me@194.152.87.150) 15.20.01 # gotta go 15.20.02 Part Zagor 15.21.35 # [IDC]Dragon: It's not yet available from any menu, but the rename() function is able to move a file to another directory as well. Of course this can't work across different volumes 15.25.04 # <[IDC]Dragon> then we either extend or drop that 15.35.10 Join trakc [0] (~8259cda3@labb.contactor.se) 15.36.39 Part trakc 15.37.17 Part amiconn 15.54.42 Quit [IDC]Dragon ("CGI:IRC (EOF)") 16.00.43 Join R3nTiL [0] (~zorroz@83.69.98.147) 16.01.57 # do you think it's possible to assign a fixed wide size and a special font (terminal like) when you reading .nfo files with txt viewer 16.02.04 # ?? 16.03.36 # so when you make a .nfo file you can format it so everyone reads it perfectly 16.03.37 # :) 16.04.15 # the "standart" is 82 char wide 16.04.17 # ;) 16.04.39 # and terminal font (for ascii art displaying) 16.05.06 Join R3nTiL1 [0] (~zorroz@83.69.98.59) 16.12.03 # what i said is clear or not ? 16.12.23 # hmmm 16.12.30 # lol 16.12.32 # :) 16.12.39 # i think so 16.12.47 # * Quelsaruk grins 16.13.12 # u kwow what i mean ;) 16.13.20 # yes 16.13.21 # i do 16.15.06 # an example : http://www.nforce.nl/nfos/renderer/ls-black.php?id=81519 16.15.27 # it's better than 10 lines of explaination ;) 16.18.32 # do you think it's possible when u open a .nfo file to be displayed like the exemple (of course it's not fit in the screen but with arrow keys) 16.22.23 *** Saving seen data "./dancer.seen" 16.26.33 Quit R3nTiL1 () 16.28.00 Quit R3nTiL (Read error: 113 (No route to host)) 16.38.52 # i think so 16.38.58 # more or less 16.39.13 # the screen is not as big as a computer's one 16.39.17 # :P 16.39.49 # lol 16.51.17 Join mecraw [0] (~lmarlow@69.2.235.2) 16.59.49 Quit bobTHC (Read error: 60 (Operation timed out)) 17.12.11 Join bobTHC [0] (~foo@l03m-40-193.d1.club-internet.fr) 17.13.02 # re 17.13.10 # re 17.14.21 # fucking isp too much deconnection this afternoon 17.14.45 # hehe 17.21.05 # I fill a request form for what i ask (true nfo support) ? 17.36.36 # : 17.36.38 # :) 17.39.57 # i'm harassing u ? 17.40.19 Join Tang [0] (~chatzilla@120-113-118-80.kaptech.net) 17.40.48 # of course not! 17.45.43 # Hello i wonder is there some contact with iRiver now? Can't understand this from logs... :/ 17.46.56 # hi Tang, afaik, Linus is porting rockbox to iRiver 17.47.10 # Hello Quelsaruk 17.47.20 # yesterday he was playing with his iRiver, flashing it and so on :) 17.47.25 # indeed i know this 17.48.00 # but i read some logs 17.48.02 # and sems 17.48.56 # i cant' undestand if the compagny has been contacted (or had contacted Rbx)? 17.49.07 # or are they only talking about Neuros? 17.49.12 # i don't know 17.49.39 # maybe LinusN or Bagder can help you 17.50.00 # ok don't mind 17.50.08 # thanks Quelsaruk 17.50.11 # :) 17.50.15 # :) 17.50.22 # you are welcome 17.55.11 Join amiconn [0] (~jens@pD9E7EBEF.dip.t-dialin.net) 17.55.19 # Tang: which company? 17.55.34 # Hello Linus 17.56.00 # I could'nt understand if you are in contact with iRiver or only with neuros 18.03.55 Quit Quelsaruk (Read error: 104 (Connection reset by peer)) 18.05.32 Join Quelsaruk [0] (~kvirc@80.103.138.199) 18.05.36 # re 18.06.05 # :) 18.22.26 *** Saving seen data "./dancer.seen" 18.26.39 Join Leety-Aravil [0] (~Miranda@p54806B9B.dip.t-dialin.net) 18.29.27 Quit Lynx_ (" HydraIRC -> http://www.hydrairc.com <- \o/") 18.29.45 # Neuros have contacted us, nobody else 18.34.29 # how is the work on the bootloader going? 18.39.56 Quit bobTHC ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") 18.45.12 # ok thanks linus :) 18.45.23 # i've to go 18.45.39 # good evening 18.47.41 # thegeek: it's nearly done, but i won't have time to work on it until next year 18.47.48 # gotta go 18.47.50 Part LinusN 18.53.50 Quit gromit` (Read error: 104 (Connection reset by peer)) 18.55.50 Join gromit` [0] (~gromit`@ras75-5-82-234-244-69.fbx.proxad.net) 19.13.27 Join methangas [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk) 19.16.28 Join Stryke` [0] (~Chairman8@24-168-110-99.si.rr.com) 19.31.19 Quit Mythril ("Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041107]") 19.31.34 # thank god next year is only a few days off;) 19.32.55 # hehe 19.34.28 Join webguest73 [0] (~52221489@labb.contactor.se) 19.35.05 Quit hile (Read error: 104 (Connection reset by peer)) 19.41.49 Quit webguest73 ("CGI:IRC (EOF)") 19.50.07 Quit Stryke` (Read error: 110 (Connection timed out)) 20.07.44 Join midk [0] (~midk@c-24-18-39-204.client.comcast.net) 20.22.28 *** Saving seen data "./dancer.seen" 20.26.14 Join hile [0] (hile@hack.fi) 20.51.30 # Ok Linus and all rockbox team 20.51.52 # i f you don't check irc nor me 20.52.12 # i wish you merry christhmas and happy new year 20.52.15 # cheers 20.55.32 Quit Tang ("Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041108]") 21.17.44 Join marc [0] (~marc@pub212004076150.hfc.datazug.ch) 21.19.34 Join Stryke` [0] (~Chairman8@24-168-110-99.si.rr.com) 21.30.33 Quit midk ("just STOP it arspy") 21.31.08 Join midk [0] (~midk@c-24-18-39-204.client.comcast.net) 21.33.57 Quit marc (Remote closed the connection) 21.34.46 Quit midk (Client Quit) 21.51.55 Quit Quelsaruk (Read error: 110 (Connection timed out)) 21.52.55 Quit Leety-Aravil (Read error: 104 (Connection reset by peer)) 22.22.14 Join windchill [0] (~marc@pub212004076150.hfc.datazug.ch) 22.22.30 *** Saving seen data "./dancer.seen" 22.40.05 Join [IDC]Dragon [0] (~idc-drago@pD9FF8D95.dip.t-dialin.net) 22.40.24 # <[IDC]Dragon> hi again 22.47.23 Join Zagor [0] (foobar@h254n2fls31o265.telia.com) 22.49.26 Join LinusN [0] (~linus@labb.contactor.se) 22.50.34 # <[IDC]Dragon> hi guys 22.50.44 # hi 22.50.57 # <[IDC]Dragon> I see requests forr beeping in recording mode 22.51.28 # <[IDC]Dragon> most likely possible by pulsing some mute or so 22.51.52 # <[IDC]Dragon> there is a patch for a battery warning, and keyclick 22.52.06 # i experimented with that some months ago. there's even a patch for it. it never turned out really well though. 22.52.20 # <[IDC]Dragon> the beep or the patch? 22.52.31 # both. i wrote the patch. 22.52.42 # <[IDC]Dragon> ah 22.53.35 # I wonder if we could construct a single no-reservoir mp3 frame that we could loop for a beep effect 22.53.54 # <[IDC]Dragon> that's what the chip8 does 22.54.10 # <[IDC]Dragon> but won't help in recording mode 22.54.12 # oh, i didn't know that 22.54.27 # ah right, we are already recording 22.54.56 # <[IDC]Dragon> amicon,, master of MAS datasheet, do you read? 22.55.16 # <[IDC]Dragon> amiconn, I mean 22.55.40 # well my patch didn't try beeping really, it was more focused on key clicks which failed to be consistent. it might be worth a try again. 22.56.23 # <[IDC]Dragon> doest the 100 Hz timer use a higher resolution we could poll for? 22.57.00 # yes, but it restarts 22.57.35 # <[IDC]Dragon> ok, but we could modulo-poll 22.57.56 Quit Stryke` (Read error: 110 (Connection timed out)) 22.58.05 # <[IDC]Dragon> I don't want to "waste" an extra timer for this 23.00.27 # still, just turning down the volume to 0 for a few tenths of a second when starting/stopping the recording might be enough 23.01.31 # <[IDC]Dragon> doing it 1000 times on and off may beep 23.01.47 # yes it will 23.01.49 # <[IDC]Dragon> perhaps no timer is needed, just the I2C delay 23.02.11 # exactly 23.02.26 # * [IDC]Dragon flexes 23.04.23 # <[IDC]Dragon> mpeg_beep() ? 23.05.10 # perhaps dac_beep() since it really has nothing to do with mpeg 23.06.02 # reboot time, cu 23.06.04 Part LinusN 23.06.05 # * [IDC]Dragon discovers such a module 23.06.15 # <[IDC]Dragon> never been there 23.06.26 # :) 23.06.49 Join ripnetUK [0] (~mirc@82-70-100-230.dsl.in-addr.zen.co.uk) 23.06.51 # <[IDC]Dragon> recorders have that as well? 23.07.16 # ah, no 23.07.53 # <[IDC]Dragon> just stumbled over the #ifdef 23.07.57 # maybe mas_beep() then 23.08.35 # <[IDC]Dragon> strictly speaking, mas is a layer too deep 23.08.35 Quit windchill ("User disconnected") 23.08.57 # yeah, you're right 23.11.19 # <[IDC]Dragon> back to mpeg_beep() ? 23.12.16 # i'd be fine with just a generic beep(). after all, we'll implement it differently on the irivers for instance (i.e. not in the mpeg-related code) 23.14.13 # <[IDC]Dragon> ok, I'll call it beep and place it into mpeg.c, where to put the prototype? 23.15.33 # how about we call it mpeg_beep for now, put the prototype in mpeg.h and then we rename it later. we are going to have to change a lot of things in the mpeg/audio code anyway. 23.16.19 # <[IDC]Dragon> hmm, ok 23.20.12 Quit methangas (" Like VS.net's GUI? Then try HydraIRC -> http://www.hydrairc.com <-") 23.31.26 # <[IDC]Dragon> it beeps 23.37.03 # nice 23.37.29 # <[IDC]Dragon> rather low, sounds like a ship 23.37.45 # <[IDC]Dragon> but definitely a feedback 23.38.33 # did you lot manage to get the MAS chip to make a beep? i wanted to do that ages ago... how did u do it? play a mp3 of a beep, or somehow program it to make a beep? 23.39.12 # <[IDC]Dragon> I just toggle a register 23.39.27 # toggle volume on/off fast makes a click, with repeated clickly makes a beep 23.39.42 # <[IDC]Dragon> playing an mp3 snipplet doesn't work in recording mode 23.39.53 # :) smart 23.40.10 # <[IDC]Dragon> not really, gimme a break 23.40.19 # does that mean it only works when there is sound anyway?> 23.40.48 # ripnetUK: no 23.41.04 # im interested because i spent some (unsuccessful) time trying to hack it to pop a beep sample into hte mp3 buffer... was beyond what i could do tho 23.42.35 # <[IDC]Dragon> now it's pretty easy, see the metronome or chip8 plugin 23.44.43 # yay, poland derailed the eu software patent steamtrain this afternoon 23.45.09 # <[IDC]Dragon> \o/ 23.45.41 # <[IDC]Dragon> although I never liked their EU attitude... 23.46.06 # sounds like how people played samples through the SID chip on c64 23.46.08 # now let's hope luxembourg does a better job with their presidency than the dutch did... 23.46.22 # ze: yes, that's the same method 23.46.34 Join G [0] (~thegeek@ti521110a080-0188.bb.online.no) 23.46.35 # fun 23.49.26 Join ripnet [0] (~mirc@82-70-100-230.dsl.in-addr.zen.co.uk) 23.49.27 Quit ripnet (Remote closed the connection) 23.50.34 Quit ripnetUK () 23.54.03 # <[IDC]Dragon> it beeps, but doesn't record any more :( 23.54.29 Quit thegeek (Read error: 110 (Connection timed out)) 23.54.29 # <[IDC]Dragon> diddy's wild register hacking seems to have side effects 23.54.47 # oops :) 23.54.59 # <[IDC]Dragon> I took his sequence: mas_codec_writereg(0, 0); mas_codec_writereg(0, 1); 23.57.08 Quit Hadaka (Remote closed the connection) 23.57.10 Join Naked [0] (naked@naked.iki.fi) 23.57.29 Nick Naked is now known as Hadaka (naked@naked.iki.fi) 23.57.34 # <[IDC]Dragon> MASter amiconn is not around?