| 00:02:31 | | Join muesli- [0] (muesli_tv@80.81.21.116) |
| 00:02:49 | muesli- | re |
| 00:04:03 | preglow | oll |
| 00:04:29 | | Join muz [0] (~540910b6@labb.contactor.se) |
| 00:04:58 | muz | hey guys any more progress from yesterday on iriver? |
| 00:05:24 | * | preglow Hellfish and Producer - Toilet Wars |
| 00:06:02 | rasher | not really |
| 00:06:32 | muz | is the flac decoder nearly done |
| 00:06:57 | sneakums | well, the sound driver isn't done, so. |
| 00:07:09 | linuxstb | and the whole audio playback system isn't done... |
| 00:07:23 | muz | oh ok |
| 00:07:37 | muz | the sound part of this project is gonna take the longest imo |
| 00:07:51 | linuxstb | but I have got the FLAC decoder decoding data on the iRiver - at about 8% of real-time (but the iRiver itself is only running at about 10% of full capacity anyway) |
| 00:08:03 | preglow | it's gonne be a while until we make sound |
| 00:08:18 | preglow | so don't expect anything very soon |
| 00:08:40 | muz | okay, its just its sooo exciting |
| 00:08:50 | muz | i got myself some shure e2c's today |
| 00:08:51 | muesli- | yeah :D |
| 00:08:54 | preglow | linuxstb: ten percent is very probably an understatement |
| 00:09:22 | muesli- | better to say to less than 2 much ;) |
| 00:09:26 | preglow | indeed |
| 00:09:27 | preglow | heh |
| 00:09:37 | sneakums | you mean about the memory thing? |
| 00:09:50 | preglow | well, 10/140 < 0.10 |
| 00:09:55 | preglow | and the memory can be faster as well |
| 00:09:56 | sneakums | oh, ah. |
| 00:10:07 | preglow | so i at least hope we can expect more than that |
| 00:10:14 | muz | is that what linus is working on now, the clock speed? |
| 00:10:20 | preglow | i don't know |
| 00:10:30 | preglow | don't think so |
| 00:10:41 | muz | he aint been on today |
| 00:10:48 | preglow | clocking the cpu higher should be pretty easy, but it's not that important right now |
| 00:10:50 | linuxstb | I don't know when he's working on it, but I think he said he will do the clock speed before sound. |
| 00:11:00 | preglow | we'll see |
| 00:11:03 | preglow | give the guy a break ;) |
| 00:11:12 | preglow | he's been working like mad for a week now |
| 00:11:13 | muz | yeah sorry, hes a legend |
| 00:11:27 | muesli- | do i understand it right that youre gonna overclock it!? |
| 00:11:34 | preglow | muesli-: it's underclocked right now |
| 00:11:43 | preglow | muesli-: it's more like we're going to take it to its full potential |
| 00:11:59 | linuxstb | I'm sure someone will try it - lots of insane people around here... |
| 00:12:10 | muesli- | *arms up* |
| 00:12:14 | muesli- | :D |
| 00:12:24 | preglow | depends, might not be possible, heh |
| 00:12:28 | preglow | without raising the system clock, that is |
| 00:12:32 | amiconn | HCl: How large (in terms of weight and size) is an original gameboy? |
| 00:12:48 | HCl | amiconn: um. not sure. |
| 00:12:53 | HCl | light |
| 00:12:55 | HCl | and not big |
| 00:13:02 | thegeek | I think linus said he would work on usb and then clock, since usb is more or less done, he is prob. working on clock now |
| 00:13:06 | muz | is the iriver running at the archos' clock speed of 12 mhz? is that why u said 10% full speed? |
| 00:13:08 | preglow | usb _is_ done |
| 00:13:12 | thegeek | mhm |
| 00:13:16 | thegeek | but there were some bugs |
| 00:13:17 | preglow | at least i can't find any problems with it |
| 00:13:19 | thegeek | might be more;) |
| 00:13:21 | thegeek | ah |
| 00:13:21 | thegeek | k |
| 00:13:23 | preglow | and i've been using it this entire day |
| 00:13:26 | thegeek | yep |
| 00:13:29 | amiconn | HCl: If I succeed to get rockboy running on archos, it would probably run on a unit smaller than the original... |
| 00:13:30 | preglow | i found a bug yesterday, and that's been fixed |
| 00:13:37 | HCl | amiconn: heh |
| 00:14:23 | amiconn | HCl: Speaking about Ondio... |
| 00:14:24 | preglow | amiconn: isn't the archos cpu like 10 mhz? |
| 00:14:37 | thegeek | humhum |
| 00:14:56 | amiconn | Archos player & Ondio are 12 MHz, Recorders are ~11 MHz |
| 00:15:09 | preglow | then i'd pretty much say farewell to the interpreter core |
| 00:15:52 | amiconn | We'll see. Do you know the original gameboy clock? |
| 00:15:54 | preglow | five/four real clocks per interpreted clock is nigh well impossible |
| 00:15:58 | preglow | amiconn: 3-4 mhz |
| 00:16:43 | preglow | amiconn: yup, 4 mhz |
| 00:16:43 | amiconn | The original uses a Z80 derivate. Z80 can't do one instr/clock, shortest instructions need 4 cycles |
| 00:17:03 | preglow | amiconn: you'd still be cutting it _very_ close for an interpreter core |
| 00:17:18 | preglow | you still need to emulate the display hardware |
| 00:17:32 | preglow | i guess sound is pretty much out of the question on the archos, unless you have support for pcm |
| 00:17:41 | amiconn | Yeah, I don't say it'll run realtime as-is. However, I expect it to run faster than on current iRiver rockbox+ |
| 00:18:00 | preglow | amiconn: that'll probably be true, i think the sh1 is faster clock for clock than 68k derivatives |
| 00:18:12 | muz | whats the video plugin like on rockbox? |
| 00:18:23 | muz | is it like watchable? |
| 00:18:33 | amiconn | Plus the ram isn't set up conservative, and the lcd driver is asm optimized like hell |
| 00:18:52 | amiconn | muz: I think so, apart from the tiny screen |
| 00:19:06 | preglow | amiconn: what about display resolution? |
| 00:19:11 | muz | so it should be good on iriver with the bigger screen and greyscale |
| 00:19:42 | amiconn | In fact, the video plugin (and the other grayscale plugins) use a smart trick to show grayscale on an lcd that does only b&w in hardware |
| 00:20:18 | amiconn | preglow: Yes, display resolution is a problem on the archos |
| 00:20:36 | preglow | you could downsample, if it's very much smaller |
| 00:20:50 | thegeek | how hard is it to write a dynarec core compared to an interpreter core? |
| 00:20:50 | amiconn | The first version will simply use every other pixel from the original buffer |
| 00:20:51 | thegeek | much harder? |
| 00:21:05 | preglow | thegeek: yes, if you want to do it efficiently |
| 00:21:14 | amiconn | This gives the same visible area as the iriver version |
| 00:21:18 | thegeek | hmm |
| 00:21:18 | thegeek | k |
| 00:21:46 | preglow | amiconn: yes, but you'll have to do resampling by a whole number of pixels, everything else'll look like shit on a screen that tiny |
| 00:21:52 | preglow | and that really limits your options |
| 00:22:08 | preglow | so you might be stuck with skipping every second pixel |
| 00:22:34 | amiconn | Yes, that's what I mean (and will do first) |
| 00:22:38 | preglow | thegeek: as a matter of fact, it might not be that hard for a z80, it's got really few registers, that simplifies things a lot |
| 00:22:45 | thegeek | k |
| 00:22:51 | thegeek | not that I have the skills to do it |
| 00:22:53 | thegeek | ;) |
| 00:22:55 | preglow | haha |
| 00:22:59 | thegeek | just wondering here |
| 00:23:01 | preglow | i've never tried it myself, but i think i should be able to |
| 00:23:08 | thegeek | I know a little c/c++ |
| 00:23:11 | preglow | i'd have to be forced |
| 00:23:11 | thegeek | not much |
| 00:23:13 | preglow | and paid |
| 00:23:16 | thegeek | hehe |
| 00:23:17 | thegeek | well |
| 00:23:18 | preglow | but i might be able to do it |
| 00:23:18 | thegeek | actually |
| 00:23:23 | thegeek | I find it quite interesting |
| 00:23:33 | thegeek | I'm wondering if I'll learn it |
| 00:23:40 | preglow | you'll have to learn assembly first at least |
| 00:23:49 | thegeek | I know assembly |
| 00:23:52 | thegeek | or |
| 00:23:54 | preglow | then lucky you! |
| 00:24:00 | thegeek | I don't know how to code it very well |
| 00:24:07 | thegeek | but I know it well from debugging |
| 00:24:14 | thegeek | I was a 0day cracker for some time;) |
| 00:24:16 | thegeek | hum |
| 00:24:20 | thegeek | but I quit |
| 00:24:23 | thegeek | so don't shoot me |
| 00:24:25 | preglow | then learn z80 assembly and tel hcl you want to code a dynarec engine |
| 00:24:25 | preglow | heh |
| 00:24:31 | preglow | hahaha |
| 00:24:31 | thegeek | ;) |
| 00:24:32 | HCl | yay! :p |
| 00:24:34 | preglow | i've cracked things myself |
| 00:24:37 | preglow | so i won't shoot you |
| 00:24:37 | thegeek | hehe |
| 00:24:40 | thegeek | good;) |
| 00:24:45 | thegeek | really don't want to be shot |
| 00:25:21 | thegeek | but |
| 00:25:25 | thegeek | hmm |
| 00:25:34 | jyp | How/where are the plans to merge the lcd drivers common code ? |
| 00:25:48 | thegeek | surely there must be a z80 dynarec core that can be built upon? |
| 00:25:57 | HCl | i tried to search for it |
| 00:26:01 | HCl | but i guess i sought gameboy specific |
| 00:26:02 | jyp | (I might actually start gmini 220 lcd) |
| 00:26:04 | HCl | let me search again |
| 00:26:29 | thegeek | even if it is not gameboy specific it should help? |
| 00:27:00 | preglow | amiconn: so, having a hand coded asm lcd does speed things up? |
| 00:27:13 | preglow | lcd driver, yes |
| 00:27:47 | HCl | hrm.. |
| 00:27:50 | amiconn | preglow: Well, it depends. Iirc, the iriver (main) lcd is connected parallel, so it might go fast enough without asm. |
| 00:28:16 | amiconn | However, the archos lcd (and the iriver remote lcd) are connected serial |
| 00:28:24 | preglow | ahh, yes, it's put on the bus |
| 00:28:27 | preglow | that's right |
| 00:28:54 | amiconn | The archos lcd serial requires bitbanging (not connected to real serial port hardware) |
| 00:29:28 | | Quit funkymonkey (" HydraIRC -> http://www.hydrairc.com <- State of the art IRC") |
| 00:29:29 | amiconn | Our driver does right above 1 MBit/s, that's even slightly above specs for the lcd... |
| 00:29:51 | preglow | bitbanging? |
| 00:30:42 | amiconn | Yes. The lcd serial data line is connected to a universal i/o port pin of the cpu |
| 00:30:56 | amiconn | So we have to clock out each bit individually, in software |
| 00:31:03 | preglow | hahaha |
| 00:31:04 | HCl | well |
| 00:31:09 | preglow | i2c? |
| 00:31:09 | HCl | can't find a z80 dynarec engine |
| 00:31:21 | preglow | that's sounds like a plain pain in the ass to code |
| 00:31:23 | thegeek | bah |
| 00:31:34 | preglow | HCl: i could have told you that :P |
| 00:31:40 | HCl | yes yes. |
| 00:31:42 | HCl | shush you :P |
| 00:31:46 | amiconn | preglow: Look at firmware/drivers/lcd.S if you want to get an impression... |
| 00:31:51 | preglow | i just did |
| 00:32:11 | HCl | while we're talking about the underlying lcd |
| 00:32:24 | HCl | any chance we could make up an interface to have direct access to it? at least on the iriver? |
| 00:33:19 | preglow | why'd you want that? |
| 00:33:33 | preglow | if it is connected directly to the memory bus, that would be A Bad Idea |
| 00:33:45 | preglow | you need to copy the framebuffer to iram first anyway |
| 00:34:12 | preglow | but that's just if my assumption is correct, yes |
| 00:34:47 | HCl | so i wouldn't have to pass the internal rockbox buffer |
| 00:35:20 | * | HCl tries a slight optimization that should make rockboy 12% faster |
| 00:35:28 | HCl | oh wait, no |
| 00:35:30 | HCl | much less :/ |
| 00:35:32 | HCl | but still |
| 00:35:34 | HCl | a bit faster. |
| 00:35:57 | muesli- | boy *g* |
| 00:36:12 | preglow | what kind of optimization would that ne? |
| 00:36:27 | | Quit mecraw () |
| 00:37:02 | HCl | preglow: not making it do all the scanline graphic calculation for the scanlines that don't get drawn anyways |
| 00:37:32 | muz | hey would an engineering degree be useful in coding in stuff like rockbox |
| 00:37:45 | amiconn | HCl: Did you check whether gnuboy outputs the scanlines sequentially? |
| 00:37:53 | | Join gromit^ [0] (~gromit@ALagny-154-1-3-198.w83-112.abo.wanadoo.fr) |
| 00:38:42 | linuxstb | Oh dear... Unless I've done something badly wrong, libmad is decoding at about 4% of real-time. |
| 00:38:48 | HCl | amiconn: it does. |
| 00:38:59 | HCl | amiconn: i'm not sure whether i can guarantee it, but so far, it does. |
| 00:39:04 | amiconn | HCl: So there is another possible optimisation... |
| 00:39:05 | preglow | muz: depends on what engineering degree you're talking about |
| 00:39:27 | HCl | amiconn: i'm more looking at the build-scanline-data routine, see if i can turn it into a more compatible format |
| 00:39:45 | amiconn | HCl: That'd be an even better idea. |
| 00:39:59 | preglow | muz: and depends on how low level you wanna get, i'm in electric engineering myself, and this is just the thing for me |
| 00:40:04 | preglow | HCl: well, that's to be expected |
| 00:40:06 | muz | a general one |
| 00:40:06 | preglow | ehh |
| 00:40:09 | preglow | linuxstb: that's to be expected |
| 00:40:16 | amiconn | If you can make it produce 'scancolumns' instead of scan lines, this should gain much speed |
| 00:40:21 | HCl | i'm also looking at the cpu core to see how adaptable it is |
| 00:40:25 | HCl | amiconn: hmmmmm. |
| 00:40:30 | HCl | i'm not sure if i can do that |
| 00:40:34 | preglow | muz: i don't really know what you mean about 'a general one', i probably don't know the education system in where you're from |
| 00:40:46 | | Join ashridah [0] (ashridah@220-253-119-254.VIC.netspace.net.au) |
| 00:41:49 | muesli- | g'day mate :) |
| 00:41:57 | HCl | unfortunately |
| 00:42:00 | HCl | there is 0 documentation on this |
| 00:42:06 | HCl | and i have absolutely no clue what they are doing here |
| 00:42:16 | ashridah | cool. i managed to lock up my iriver while shutting it down in rockbox |
| 00:42:28 | ashridah | ps, if you insert the usb adapter while it's shutting down, it locks pu :) |
| 00:42:29 | ashridah | up even |
| 00:42:40 | preglow | amiconn: the lcd is addressed by column first? |
| 00:43:02 | amiconn | preglow: No, but the bytes are oriented vertically |
| 00:43:19 | preglow | really, funky |
| 00:43:29 | amiconn | That's the hardware format, see lcd-h100.c (and lcd-recorder.c) for comparison. |
| 00:43:35 | preglow | all the lcds i've progammed have been the other way around |
| 00:43:45 | | Join Stryke` [0] (~Chairman8@resnet-241-86.resnet.UMBC.EDU) |
| 00:44:00 | amiconn | You see, both the archos lcd and the iriver lcd in b&w mode have that format. |
| 00:45:02 | amiconn | Linus told that the iriver lcd in 4-gray mode uses a similar format as well, only that one bytes does no longer represent an 1x8 pixel column, but an 1x4 pixel one. |
| 00:45:16 | preglow | aye |
| 00:45:25 | HCl | okay |
| 00:46:37 | amiconn | The gmini lcd (jyp ?) seems to use the same bitmap format, so I'd consider this a common format. |
| 00:46:51 | preglow | lcd's are generally compatible in a lot of ways |
| 00:46:59 | thegeek | hmm ,the old spectrum used a z80 cpu I think , there is a dynarec emulator for it called Spectrem-Dr |
| 00:47:08 | preglow | it's not unusual to find some types are completely compatible |
| 00:47:08 | thegeek | http://groups-beta.google.com/group/comp.sys.sinclair/browse_frm/thread/c5e43634c7f01dba/37d91c35619247f1?q=z80+emulator+dynarec&_done=%2Fgroups%3Fq%3Dz80+emulator+dynarec%26hl%3Den%26lr%3D%26sa%3DN%26tab%3Dwg%26&_doneTitle=Back+to+Search&&d#37d91c35619247f1 |
| 00:47:24 | amiconn | thegeek: ZX Spectrum == Z80 @ 3.5 MHz |
| 00:47:31 | thegeek | oh |
| 00:47:31 | thegeek | hmm |
| 00:47:39 | thegeek | but it uses the same instruction set? |
| 00:47:50 | preglow | thegeek: and bear in mind that the gb cpu isn't a z80, just a z80 lookalike, might still be a good starting point, tho |
| 00:47:59 | thegeek | hmm |
| 00:48:02 | thegeek | ;) |
| 00:48:09 | thegeek | I'm just doing whatever I can to help here |
| 00:48:21 | preglow | didn't tell you to shut up, did i? ;) |
| 00:48:36 | preglow | time for coffee and cigarette |
| 00:48:40 | thegeek | even if the int. core is fast enought with rockbox fully optimized for iriver, dynarec would rock since you could perhaps do mp3+gamebou |
| 00:48:43 | thegeek | hehe |
| 00:48:46 | thegeek | *gameboy |
| 00:48:48 | jyp | amiconn, gmini 220 uses a different format |
| 00:48:51 | * | linuxstb thinks of Chuckie Egg... |
| 00:48:55 | * | HCl sighs |
| 00:49:22 | amiconn | jyp: Really? How does that look like? |
| 00:49:33 | jyp | Actually many modes are possible |
| 00:49:57 | amiconn | Is there a datasheet in the wiki already? |
| 00:50:09 | thegeek | hmm |
| 00:50:09 | HCl | hrm. |
| 00:50:12 | jyp | In Archos firmware, bpp = 4, 2 pixels per byte |
| 00:50:13 | thegeek | what cpu does the palm use? |
| 00:50:18 | jyp | organized as lines |
| 00:50:27 | preglow | thegeek: arm, i think |
| 00:50:29 | DMJC | how is audio decoding coming? |
| 00:50:31 | jyp | fully horizontal |
| 00:50:32 | thegeek | hmm |
| 00:50:32 | thegeek | k |
| 00:50:39 | preglow | most portable things use arms |
| 00:50:45 | jyp | Datasheet isn't in wiki yet ... |
| 00:50:47 | preglow | no pun intended whatsoever |
| 00:50:48 | jyp | I'm adding it |
| 00:50:48 | amiconn | old palms == dragon ball (68K derivate, much like coldfire) |
| 00:50:59 | thegeek | hmm |
| 00:51:00 | thegeek | but |
| 00:51:07 | thegeek | http://www.palminfocenter.com/comment_view.asp?ID=67 |
| 00:51:19 | thegeek | gameboy emu for palm |
| 00:51:20 | thegeek | and |
| 00:51:22 | thegeek | there is a comment there |
| 00:51:33 | thegeek | about how the 68000 is only running at 16mhz |
| 00:51:36 | HCl | is it open source? |
| 00:51:39 | thegeek | no idea |
| 00:51:42 | HCl | no, thats the commercial one |
| 00:51:44 | HCl | i already saw it |
| 00:51:48 | thegeek | barf that then |
| 00:51:52 | HCl | yup. |
| 00:53:02 | * | HCl tries to understand this stuff. |
| 00:53:21 | jyp | amiconn, http://www.mculand.com/sub1/mcu/calmrisc16_device/S3cc410.pdf |
| 00:54:00 | *** | Saving seen data "./dancer.seen" |
| 00:54:27 | HCl | i think i somewhat get it. |
| 00:54:36 | HCl | it might be possible to make it do scancolumn |
| 00:54:36 | HCl | s |
| 00:55:41 | ashridah | heh. i've still got a palm m100 lying around here someplace. haven't used it in ages, since i tried to make sense of the prc build environment under linux, and got hopelessly lost in the resource stuff. |
| 00:56:06 | preglow | does anyone know how the hell to stop windows from scanning my h120 whenever i connect it by usb?= |
| 00:56:13 | preglow | it's irritating the fucking hell out of me |
| 00:57:33 | | Quit ashridah ("Reconnecting") |
| 00:57:35 | | Join ashridah [0] (ashridah@220-253-119-254.VIC.netspace.net.au) |
| 00:57:49 | ashridah | preglow: tweakui should be able to |
| 00:58:02 | preglow | i'll try it |
| 00:58:21 | ashridah | it's under 'my computer'->'autoplay' |
| 00:58:35 | ashridah | you should be able to disable it for the drive the iriver usually shows up as |
| 00:58:52 | ashridah | or for 'removable devices' in general, although i'm not sure if that's worked for me |
| 00:58:58 | muesli- | i have tweakui installed |
| 00:58:58 | muesli- | if anyone finds a solution i'd like to know it as well |
| 00:59:15 | * | ashridah pokes |
| 00:59:27 | preglow | ashridah: which tweakui do you speak of, btw? there are quite a few programs by that name |
| 00:59:42 | ashridah | preglow: 'powertools for windows xp' |
| 00:59:43 | muesli- | i only know the one from m$ |
| 00:59:43 | * | HCl sighs |
| 00:59:47 | ashridah | it's an ms-made app |
| 01:00 |
| 01:00:17 | preglow | found it |
| 01:00:55 | ashridah | yeah. turning off the drive letter that the device shows up as here (i left a gap between my cdrom drives and my hard drives so that it'd always show there) did the trick for me |
| 01:01:07 | ashridah | doesn't even pop up an explorer window |
| 01:01:23 | preglow | ashridah: thanks, man, you cut my stress level in half |
| 01:01:29 | ashridah | heh |
| 01:01:33 | ashridah | yeah. i hate the autoplay crap |
| 01:01:36 | HCl | this is confusing x.x |
| 01:02:06 | preglow | now if i could only get xp to not require me to do that clicking shit before i can unplug my h120 |
| 01:02:18 | preglow | i probably don't have to, since they have disabled delayed writes for portable disks |
| 01:02:21 | preglow | but still |
| 01:02:28 | sneakums | it sure does like to whine |
| 01:02:51 | sneakums | although you haven't lived until you've seen a machine cripped by ~1500 'device disconnected' dialogs when a storage array has gone offline |
| 01:02:57 | amiconn | jyp: That's a pretty complete system-on-chip. USB, lcd controller, SmartMedia, RTC... |
| 01:03:04 | sneakums | i think we had to power-cycle it |
| 01:03:25 | ashridah | heh |
| 01:03:34 | ashridah | sneakums: could have been worse. could have been nfs :) |
| 01:03:40 | jyp | amiconn, indeed. It still amazes me ;): |
| 01:04:21 | | Quit muz ("CGI:IRC") |
| 01:06:19 | HCl | igh. |
| 01:06:20 | HCl | okay |
| 01:06:28 | HCl | i don't think i can rewrite this to scancolumns |
| 01:06:35 | HCl | its too much confusing code thats written without comments |
| 01:07:20 | jyp | HCl, it's still time to re-target to gmini 220 ;)) |
| 01:07:38 | thegeek | nono! |
| 01:07:42 | thegeek | don't give up on the gbemu |
| 01:07:49 | thegeek | we all want gb on our irivers |
| 01:07:50 | DMJC | iriver pwns j00 |
| 01:07:55 | thegeek | indeed. |
| 01:08:32 | jyp | hahahaaaa you all iRiver n00bs pity me! :P |
| 01:08:52 | Tang | About wavpack great news: |
| 01:08:58 | Tang | http://www.hydrogenaudio.org/forums/index.php?act=ST&f=2&t=27390&st=0# |
| 01:09:06 | Tang | Roberto amorim (thanks to him) |
| 01:10:00 | Tang | told me he mailed the wavpack author |
| 01:10:01 | Tang | :) |
| 01:10:18 | DMJC | yay doom3 addon |
| 01:11:00 | * | jyp melts himself |
| 01:11:03 | | Quit jyp ("poof!") |
| 01:11:51 | preglow | haha, i just noticed the optical output is enabled with rocbox |
| 01:11:52 | preglow | heh |
| 01:13:05 | HCl | yea. |
| 01:13:59 | Tang | lol will drain more battery power |
| 01:14:35 | linuxstb | Tang: Thanks for the update. It's good to know that the wavpack author is approachable in case of problems. |
| 01:15:00 | Tang | Indeed it's very cool |
| 01:15:36 | Tang | moreover seems this guy has skill in embedded development) |
| 01:16:00 | linuxstb | I'm sure lots of codec authors will be interested in this project - apart from FLAC and OGG, I can't think of any "non-mainstream" codecs with hardware support. |
| 01:16:14 | HCl | geeze. |
| 01:16:26 | HCl | *NO ONE* has ever attempted to optimize the cpu core of gnuboy u.u |
| 01:17:16 | linuxstb | HCl: What % of real-time do you think gnuboy is at the moment? |
| 01:17:16 | thegeek | ? |
| 01:17:23 | thegeek | but there is a x86 asm core? |
| 01:17:31 | thegeek | for gnuboy I neab |
| 01:17:32 | thegeek | mean |
| 01:17:46 | thegeek | surely that = optimizing? |
| 01:17:46 | Tang | indded linuxstb that was why i wanted to try approaching the HA community with Rbx... :) |
| 01:18:03 | HCl | linuxstb: it'd need to be near 60 times faster |
| 01:18:19 | HCl | there's an extreme amount of loss in the lcd driver |
| 01:18:29 | HCl | mostly because the iriver lcd/rockbox require you to do bitsets |
| 01:18:32 | HCl | rather than byte |
| 01:20:02 | HCl | there's an x86 cpu asm core written entirely in asm.. |
| 01:20:07 | HCl | i'd almost call it... dumb. |
| 01:20:16 | HCl | but i guess dynarec wasn't really invented back then |
| 01:20:43 | DMJC | how long ago? |
| 01:20:50 | DMJC | fx!32's been around for ages |
| 01:20:53 | preglow | don't give up yet, probably won't be long till the coldfire is running at full throttle, then you can sigh and say 'ITS HOPELESS' |
| 01:20:55 | HCl | gnuboy was written in 2001 |
| 01:20:59 | HCl | lmao. |
| 01:21:02 | HCl | i'm not giving up |
| 01:21:03 | HCl | at all. |
| 01:21:18 | HCl | i'm just saying, that i don't see an easy way to make it produce scancolumns |
| 01:21:22 | preglow | aren't there any other emulators out there, btw? |
| 01:21:26 | DMJC | what speed does the coldfire normally run at when it runs the iriver firmware? |
| 01:21:30 | HCl | unless you like |
| 01:21:35 | HCl | capture the scanlines in a buffer |
| 01:21:37 | preglow | DMJC: probably 140mhz |
| 01:21:39 | amiconn | HCl: Dynarec was already invented back then... |
| 01:21:42 | HCl | then when you receive scanline 143 |
| 01:21:47 | HCl | push the buffer to rockbox |
| 01:22:00 | DMJC | so why does rockbox run it so slowly? |
| 01:22:02 | HCl | what would be ideal, is to get the lcd to accept a byte array with the lower two bits being its value for each pixel |
| 01:22:06 | HCl | bitsets |
| 01:22:12 | HCl | in the current format |
| 01:22:13 | preglow | DMJC: because the cpu isn't clocked at more than 10mhz |
| 01:22:15 | HCl | one byte |
| 01:22:18 | DMJC | ? |
| 01:22:26 | HCl | is for 8 pixels / scanlines |
| 01:22:29 | preglow | DMJC: it's software controllable |
| 01:22:50 | DMJC | and it has a default slow state until it receives a "fast" command |
| 01:22:51 | HCl | so it has to set bits individually |
| 01:22:59 | HCl | which is expensiveish |
| 01:23:00 | preglow | DMJC: exactly |
| 01:23:16 | DMJC | cool |
| 01:23:29 | linuxstb | Isn't the Rockbox LCD driver about to change anyway to support 2-bits/pixel? Maybe 1-byte per pixel can happen then. |
| 01:23:33 | HCl | the idea is that it can be sped up a lot |
| 01:23:42 | HCl | linuxstb: its more about the lcd hardware format.. |
| 01:23:57 | HCl | i'm gonna make an attempt to write a "better" driver |
| 01:24:05 | preglow | HCl: well, you should be able to hack gnuboy to do it a bit more efficiently, but again, scanning in the y direction will be a bit more expensive on the coldfire part of things |
| 01:24:07 | HCl | it might be faster, who knows. |
| 01:24:25 | preglow | since it's probably set up to scan x first internally |
| 01:25:04 | amiconn | HCl: You could buffer 8 scanlines in the driver, then convert at the end. |
| 01:25:51 | amiconn | This would simply change to 4 once the rockbox lcd driver does 2 bit |
| 01:28:32 | HCl | yea. |
| 01:28:35 | HCl | thats my plan |
| 01:32:40 | HCl | i'm fearing this'll actually be slower, but who knows. |
| 01:34:12 | amiconn | Well, you'll still need bitsets no matter what. But as they can be put in a tight loop then, they're done in a register. |
| 01:34:39 | amiconn | Asm would help to speed it up even more (utilizing the carry bit) |
| 01:37:04 | preglow | HCl: getting a bit more than you bargained for, ehh? ;) |
| 01:37:11 | HCl | preglow: not really |
| 01:37:26 | preglow | no, i forgot, you initially wanted dynarec |
| 01:37:26 | preglow | heh |
| 01:37:39 | HCl | amiconn: i'm getting the feeling this'll be more efficient once rockbox has a 2bit buffer |
| 01:38:50 | HCl | ok. |
| 01:39:03 | HCl | old routine took 30 seconds to get from the start of mario to display output |
| 01:39:08 | HCl | now to time my new routine :x |
| 01:39:24 | * | preglow holds breat |
| 01:39:25 | preglow | h |
| 01:40:51 | HCl | gotta make it compile first >.o |
| 01:40:57 | HCl | variable name conflict |
| 01:41:15 | HCl | there. |
| 01:41:18 | * | HCl compiles |
| 01:41:29 | HCl | i think it'll actually be slower |
| 01:41:32 | HCl | but who knows. |
| 01:43:59 | HCl | that actually crashed it |
| 01:44:13 | preglow | and there was much rejoicing |
| 01:45:02 | HCl | :p |
| 01:45:10 | HCl | well ofcourse |
| 01:45:12 | HCl | i'm dumb |
| 01:45:14 | HCl | and stuff. |
| 01:45:15 | HCl | xD |
| 01:45:21 | HCl | i kind of forgot to increase the variable |
| 01:45:26 | HCl | that determines whether i get out of the loop |
| 01:45:38 | preglow | not entirely unessential |
| 01:48:37 | HCl | i don't see how it actually makes code smaller |
| 01:48:38 | HCl | but ok |
| 01:51:07 | HCl | i'm not sure if its any faster |
| 01:51:18 | HCl | anyways |
| 01:51:24 | HCl | i still have to map 4 bits to 1 color |
| 01:51:30 | HCl | so thats fairly expensive |
| 02:00 |
| 02:00:14 | * | HCl reads about the lcd driver and sighs. |
| 02:00:23 | | Quit Hohoman ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") |
| 02:00:30 | HCl | can't this thing scan horizontal instead of vertical? |
| 02:02:31 | amiconn | What difference would this make? If you buffer 8 scanlines, it should no longer matter. |
| 02:03:20 | HCl | hm |
| 02:03:21 | HCl | i guess |
| 02:04:33 | * | HCl ponders |
| 02:04:59 | | Join webguest61 [0] (~46127aee@labb.contactor.se) |
| 02:05:08 | | Quit webguest61 (Client Quit) |
| 02:05:18 | | Join toolmanwill [0] (~46127aee@labb.contactor.se) |
| 02:07:57 | | Quit toolmanwill (Client Quit) |
| 02:16:16 | Tang | i've to go |
| 02:16:18 | Tang | bye |
| 02:16:19 | | Quit Tang ("Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041108]") |
| 02:16:20 | HCl | cya |
| 02:17:41 | preglow | ahh, great, fireworks, sleep will come easily tonight |
| 02:25:05 | * | HCl scratches his head |
| 02:25:08 | HCl | i think its a little faster |
| 02:25:09 | HCl | but not much |
| 02:26:43 | | Quit edx (Read error: 110 (Connection timed out)) |
| 02:29:51 | * | HCl goes to sleep.. |
| 02:30:32 | amiconn | Hmm. |
| 02:30:45 | amiconn | Nite HCl |
| 02:31:23 | preglow | yes |
| 02:31:26 | preglow | i'll do the same |
| 02:31:40 | preglow | nite all |
| 02:31:52 | | Quit preglow ("rofllolmao") |
| 02:33:10 | HCl | amiconn: i'll put my new implementation version on my ftp.. hold on |
| 02:33:45 | amiconn | Argh! Every time I fetched that zip blob, you're going to update afterwards... |
| 02:33:54 | HCl | there.. |
| 02:33:58 | HCl | sorry :X |
| 02:34:09 | HCl | its one of the reasons why its handier to have it in cvs :x |
| 02:34:44 | HCl | anyways, thats the new version, its not that much faster, though the adding of the -O2 to the compile options helped a bit |
| 02:35:01 | HCl | once we have 2 bit color it should be a bit faster |
| 02:35:41 | amiconn | I need to cleanly integrate that into a build dir tree |
| 02:35:52 | HCl | yea |
| 02:36:07 | amiconn | You always distribute your whole dir, with all the junk in it... |
| 02:36:13 | HCl | sorry :X |
| 02:36:22 | HCl | i can zip up just my gnuboy dir from now on |
| 02:36:27 | HCl | assuming you have all the other changes |
| 02:36:44 | amiconn | Not yet... have to figure what these are |
| 02:38:00 | amiconn | Btw, the gnuboy dir also contains some junk. There is a .tar.gz .... |
| 02:38:12 | HCl | you can do cvs update in the dir and it'll say what files are modified compared to the cvs |
| 02:38:24 | HCl | the .tar.gz is mostly for if you need to compare to the original sources |
| 02:38:29 | HCl | it can just be removed |
| 02:38:44 | HCl | so can the asm dir in gnuboy/ since it contains x86 asm anyways |
| 02:38:55 | HCl | oh wait, i already deleted that |
| 02:39:21 | HCl | i can clean it up a bit tomorrow |
| 02:39:55 | HCl | and give you a dir with a clean cvs + changes and no other files |
| 02:40:22 | HCl | i'm gonna sleep now |
| 02:40:23 | HCl | night |
| 02:40:27 | amiconn | I'll try a diff agains my cvs dir |
| 02:40:37 | HCl | *nods* |
| 02:40:42 | HCl | well |
| 02:40:49 | HCl | i can give you a list of modified files |
| 02:40:49 | amiconn | (hoping that you updated recently) |
| 02:40:51 | HCl | in whisper |
| 02:40:54 | HCl | if you want |
| 02:54:04 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:12:57 | amiconn | I should go to sleep now |
| 03:13:06 | amiconn | Nite |
| 03:13:13 | | Part amiconn |
| 03:18:10 | | Join gromit`` [0] (~gromit@ALagny-154-1-4-1.w83-112.abo.wanadoo.fr) |
| 03:20:33 | | Quit ashridah ("out") |
| 03:23:16 | | Join elinenbe [0] (elinenbe_@207-237-225-9.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 03:23:46 | | Part Quelsaruk ("Ooh, look, a shiny object...") |
| 03:29:15 | | Join muesli|tarn [0] (muesli_tv@D2cfa.d.pppool.de) |
| 03:31:44 | | Quit gromit^ (Read error: 110 (Connection timed out)) |
| 03:31:49 | | Quit linuxstb (Read error: 60 (Operation timed out)) |
| 03:34:24 | | Quit Stryke` ("Friends don't let friends listen to Anti-Flag") |
| 03:38:14 | | Quit muesli- (Read error: 60 (Operation timed out)) |
| 03:46:05 | | Join orbital [0] (orbital@absolut.reject.org) |
| 03:47:04 | | Part orbital |
| 03:52:28 | | Quit gromit`` ("Leaving") |
| 04:00 |
| 04:01:21 | | Join diprospero [0] (~40e72d94@labb.contactor.se) |
| 04:01:48 | | Quit diprospero (Client Quit) |
| 04:01:55 | | Quit cYmen ("dying ....slowly") |
| 04:01:56 | | Join webguest78 [0] (~40e72d94@labb.contactor.se) |
| 04:02:04 | webguest78 | hello |
| 04:03:23 | | Part webguest78 |
| 04:06:30 | | Join QT [0] (as@area51.users.madwifi) |
| 04:08:03 | | Join edx [0] (edx@p54879908.dip.t-dialin.net) |
| 04:14:38 | | Join toolmanwv [0] (~aaa@pool-70-18-122-238.buff.east.verizon.net) |
| 04:19:21 | | Quit QT_ (Read error: 110 (Connection timed out)) |
| 04:20:11 | | Part toolmanwv |
| 04:20:40 | | Join toolmanwv [0] (~aaa@pool-70-18-122-238.buff.east.verizon.net) |
| 04:23:40 | | Part toolmanwv |
| 04:23:43 | | Join toolmanwv [0] (~aaa@pool-70-18-122-238.buff.east.verizon.net) |
| 04:46:02 | | Join Strath [0] (~mike@dgvlwinas01pool0-a212.wi.tds.net) |
| 04:46:11 | Strath | hey guys ;) |
| 04:48:01 | Strath | i was just looking around rockbox.org, i think there may be an error on the page http://www.rockbox.org/twiki/bin/view/Main/DocsIndex reguarding rel="nofollow" |
| 04:49:25 | Strath | (the last four links) |
| 04:54:08 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:18:10 | | Join webguest99 [0] (~cbc8c609@labb.contactor.se) |
| 05:49:50 | | Quit webguest99 ("CGI:IRC (EOF)") |
| 05:51:27 | | Quit DMJC ("Leaving") |
| 06:00 |
| 06:54:12 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:28:23 | | Join methangas [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk) |
| 07:33:03 | | Quit XShocK (" HydraIRC -> http://www.hydrairc.com <- Go on, try it!") |
| 07:37:18 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 07:38:17 | | Join R3nTiL_ [0] (~zorroz@217.30.249.65) |
| 07:46:38 | | Quit pill (Read error: 110 (Connection timed out)) |
| 07:56:47 | | Join DMJC [0] (~James@220-245-162-47-sa-nt.tpgi.com.au) |
| 07:57:48 | | Quit R3nTiL_ () |
| 08:00 |
| 08:16:47 | | Join pill [0] (dearth@ip-130.net-82-216-140.issy4.rev.numericable.fr) |
| 08:24:09 | | Quit midk ("Leaving") |
| 08:54:15 | *** | Saving seen data "./dancer.seen" |
| 08:57:03 | | Join amiconn [0] (~jens@pD9E7F6F4.dip.t-dialin.net) |
| 09:00 |
| 09:02:30 | rasher | Morning |
| 09:04:40 | amiconn | Morning |
| 09:06:57 | Strath | morning |
| 09:36:22 | | Nick Lynx_awy is now known as Lynx_ (HydraIRC@134.95.189.59) |
| 09:45:09 | amiconn | rasher: I had a look at your logo plugin |
| 09:45:25 | amiconn | Looks pretty clean, just some comments: |
| 09:46:12 | amiconn | (1) HAVE_LCD_BITMAP is used as a boolean define, so line 21 should read #ifdef HAVE_LCD_BITMAP |
| 09:46:51 | amiconn | (2) The variable button definitions are not really variable, so you could just use BUTTON_OFF directly |
| 09:47:20 | rasher | oh right, I thought about that, and then forgot |
| 09:47:21 | amiconn | (3) There is no reason why it should not run on gmini (simulator for now) |
| 09:47:45 | amiconn | (This would be solved automatically if (2) is resolved. |
| 09:47:52 | rasher | did I exclude it? |
| 09:47:55 | rasher | oh right, button defs |
| 09:48:08 | rasher | I'll make a newer version |
| 09:48:11 | amiconn | No, but you didn't include the variable button definition for it |
| 09:48:30 | rasher | Yes |
| 09:48:38 | rasher | well that'll come as a result of (2) |
| 09:48:45 | rasher | assuming gmini has a BUTTON_OFF |
| 09:48:53 | amiconn | The gmini also hast LEFT/RIGHT/UP/DOWN/OFF, and the lcd is almost the same size as the other archos units |
| 09:49:10 | rasher | excellent |
| 09:49:12 | amiconn | (128x64 instead of 112x64) |
| 09:49:40 | amiconn | (4) Do you plan to make the speed variable? I saw that 'timer' variable... |
| 09:50:00 | rasher | oh, that was just a leftover from mosaique on which I based it :) |
| 09:50:20 | rasher | not really |
| 09:50:55 | rasher | so.. remove button definitions.. change to #ifdef |
| 09:51:00 | amiconn | For (1), the 2 #if conditions could be combined to one. |
| 09:51:13 | rasher | Ah, how does that look? |
| 09:51:25 | amiconn | #if defined(HAVE_LCD_BITMAP) && (LCD_WIDTH > 90) |
| 09:51:38 | amiconn | >= 90 |
| 09:51:45 | amiconn | of course |
| 09:51:55 | rasher | 91, I guess |
| 09:52:05 | rasher | 90 was from a previous version of the small bitmap |
| 09:52:13 | rasher | which was slightly wrong-looking |
| 09:52:19 | amiconn | Hmm, then correct thios as well ;) |
| 09:52:23 | amiconn | *this |
| 09:52:39 | amiconn | > 90 would be correct then |
| 09:52:50 | rasher | I think >= 91 makes more sense |
| 09:52:58 | rasher | since 91 is the number in question |
| 09:53:45 | * | rasher makes iriversim and recorderv2sim |
| 09:55:07 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 09:55:15 | | Join midk_ [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 09:55:15 | | Quit midk (Connection reset by peer) |
| 09:57:16 | rasher | looks fine on those sims |
| 09:57:27 | rasher | I'll make a new patch then |
| 09:57:42 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 09:57:43 | | Join midk__ [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 09:57:45 | | Quit midk (Read error: 104 (Connection reset by peer)) |
| 09:57:47 | | Quit midk__ (Read error: 104 (Connection reset by peer)) |
| 09:57:54 | rasher | or maybe I'll just edit the original patch by hand |
| 09:58:16 | rasher | shouldn't be too hard |
| 09:58:48 | amiconn | For a new plugin, just submitting the .c file is okay. |
| 09:58:54 | rasher | ah |
| 10:00 |
| 10:00:27 | amiconn | A .ptach only makes sense if you change existing files, imho. |
| 10:00:33 | amiconn | .patch even. |
| 10:05:13 | * | rasher uploads the new version |
| 10:05:53 | rasher | or rather, deletes old version |
| 10:05:56 | rasher | THEN uploads new version |
| 10:07:39 | rasher | done |
| 10:10:27 | rasher | I wonder if I got the PluginIndex page right |
| 10:10:36 | rasher | or rather, if it catches all of the %Y%s |
| 10:12:06 | rasher | I wonder if there are a lot of orphan pages |
| 10:16:35 | rasher | amiconn: do you know about the stopwatch plugin? |
| 10:18:22 | rasher | wtf |
| 10:18:47 | rasher | instead of "Recording" on the main menu, I have "Max range" |
| 10:18:53 | rasher | eh |
| 10:18:57 | rasher | "Maximum of range" |
| 10:19:08 | rasher | (the Danish translation, that is) |
| 10:19:54 | rasher | must be a glitch in the build I have on my device, looks right in the sim |
| 10:20:21 | rasher | huh, I get it for English as well |
| 10:20:23 | rasher | strange |
| 10:20:24 | rasher | oh well |
| 10:20:50 | rasher | at least it's consistent |
| 10:25:35 | amiconn | This means your language strings are off by one (just looked up in english.lang) |
| 10:26:12 | amiconn | I have no idea why this is. It's working correctly here. |
| 10:26:31 | | Join webguest36 [0] (~54de5919@labb.contactor.se) |
| 10:28:14 | | Join Nibbler [0] (~sven@port-195-158-163-29.dynamic.qsc.de) |
| 10:28:18 | rasher | Yes, I don't know.. I don't remember fiddling with the languages |
| 10:28:25 | rasher | maybe I have |
| 10:28:38 | rasher | Works in the sim, and probably would work if I built and installed again |
| 10:28:55 | | Part webguest36 |
| 10:29:09 | * | rasher tries |
| 10:31:26 | | Join webguest73 [0] (~8446dbd5@labb.contactor.se) |
| 10:32:39 | | Quit midk_ ("Leaving") |
| 10:33:08 | rasher | ah, I might have an explanation |
| 10:33:21 | rasher | or at least, I might know what I did to make it happen |
| 10:34:05 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 10:34:35 | rasher | let me check this.. |
| 10:35:58 | rasher | yup |
| 10:36:11 | rasher | I chose '4. dansk' as default language in configure |
| 10:36:40 | amiconn | Hmm, that's strange. |
| 10:37:32 | amiconn | It should work correctly. There was a bug in the script that generates lang.[ch], but I fixed that. At least I think that I did... |
| 10:37:48 | rasher | could it be that I've simply messed up dansk.lang? |
| 10:38:20 | amiconn | I don't think so. The ID order is always taken from english.lang |
| 10:38:30 | amiconn | Could you please send me the generated lang.c and lang.h? |
| 10:38:35 | rasher | sure |
| 10:43:04 | rasher | rasher.dyndns.org/~rasher/lang.h">http://rasher.dyndns.org/~rasher/lang.h and .c |
| 10:49:58 | amiconn | Hmm. There is indeed a missing id. Need to check why; this shouldn't happen |
| 10:50:26 | rasher | heh |
| 10:50:32 | rasher | can you see which one? |
| 10:50:44 | amiconn | LANG_WEEKDAY_THURSDAY |
| 10:50:48 | rasher | hm |
| 10:50:57 | amiconn | But it should get included from english.lang instead... |
| 10:51:16 | amiconn | Looks like a bug in one of the scripts, or this one really messed up. |
| 10:51:30 | rasher | oh, it's not in dansk.lang |
| 10:51:37 | rasher | I wonder how that managed to get away |
| 10:51:41 | | Nick Strath is now known as StrathAFK (~mike@dgvlwinas01pool0-a212.wi.tds.net) |
| 10:51:46 | | Join loopz [0] (~3efe0020@labb.contactor.se) |
| 10:51:51 | rasher | oh, it's there |
| 10:51:58 | rasher | just not where you'd expect it to be |
| 10:52:05 | rasher | what the.. |
| 10:52:12 | amiconn | Yes, and the order messed up in lang.h as well |
| 10:52:27 | amiconn | This should never happen, so there is a bug in the script... |
| 10:52:53 | rasher | it could be that I messed up the original? |
| 10:52:55 | rasher | manually, that is |
| 10:53:05 | rasher | or should it cope with that? |
| 10:53:38 | amiconn | The ID order in other .lang files than english.lang shouldn't matter. |
| 10:54:19 | *** | Saving seen data "./dancer.seen" |
| 10:55:04 | * | amiconn is building a dansk recorder simulator... |
| 10:56:19 | rasher | that should prove amusing :) |
| 10:57:20 | amiconn | Hmm, looking correctly here. |
| 10:57:46 | rasher | Hrm |
| 10:58:22 | amiconn | Hmm, not really. |
| 10:58:32 | rasher | oh? |
| 10:58:46 | amiconn | While the menu is looking right, the lang.h order is wrong (same as yours) |
| 10:58:56 | rasher | the only place I've noticed a fault is in the main menu |
| 10:59:09 | rasher | where "Recording" is changed to "Maximum of range" |
| 10:59:18 | rasher | all other places look fine |
| 10:59:28 | rasher | I think |
| 10:59:34 | rasher | haven't noticed other places at least |
| 10:59:35 | amiconn | That's clear; I think you have a dansk.lng on your unit as well (with the 'official' id order) |
| 10:59:50 | rasher | ah |
| 11:00 |
| 11:00:05 | amiconn | So if this is loaded into the build which expects the wrong order, it'll mess up |
| 11:00:11 | rasher | heh |
| 11:08:04 | amiconn | Hmm. This cannot work without a major rework of the involved scripts. |
| 11:09:42 | amiconn | I didn't run into this, because I always select english as the build language, and then load deutsch.lng |
| 11:09:46 | rasher | maybe We should just fix dansk.lang and look the other way :) |
| 11:10:07 | rasher | yes, that's how I usually do it |
| 11:10:21 | amiconn | It will definitely work if the IDs are in the same order as in english.lang |
| 11:10:39 | amiconn | German, french and spanish are |
| 11:10:41 | rasher | yes |
| 11:11:00 | rasher | so it's just a matter of moving LANG_WEEKDAY_THURSDAY up between WEDNESDAY and FRIDAY ? |
| 11:11:09 | amiconn | However, there's a number of other languages, which are probably in the wrong order as well |
| 11:11:21 | amiconn | No, there are other IDs shuffled as well |
| 11:12:04 | rasher | oh |
| 11:12:08 | rasher | tragic |
| 11:12:24 | amiconn | It shouldn't be that hard to change uplang to sort the IDs, but this would make it difficult to preserve comments. |
| 11:12:38 | amiconn | (and it's perl, grr) |
| 11:12:49 | rasher | Heh |
| 11:13:10 | rasher | maybe it should only do the sorting when compiling? |
| 11:13:21 | rasher | Such that the order will be fixed at that point |
| 11:13:24 | rasher | instead of in the .lang |
| 11:13:32 | amiconn | It would have to work the other way round than now. |
| 11:14:26 | amiconn | Currently, it first reads english.lang and stores it in a hash. Then it reads the selected.lang, updates/checks with the english IDs, then writes the new file, ID by ID |
| 11:14:27 | | Quit loopz ("CGI:IRC (EOF)") |
| 11:14:39 | rasher | ah |
| 11:15:05 | amiconn | This way, the order of the generated file is always in the selected .lang order, except for IDs that are missing there |
| 11:15:48 | amiconn | It would have to work the other way round, i.e. first reading the selected .lang, then going through english.lang ID by ID |
| 11:16:10 | amiconn | Hmm. As I think it over, this is the more logical way... |
| 11:21:24 | | Join linuxstb [0] (~linuxstb@dsl-212-23-31-215.zen.co.uk) |
| 11:31:06 | amiconn | Gotta go now. |
| 11:31:16 | | Part amiconn |
| 11:32:31 | | Quit webguest73 ("CGI:IRC (EOF)") |
| 11:33:03 | | Join cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 11:48:05 | | Join Quel|out [0] (~kvirc@80.103.129.193) |
| 11:48:10 | Quel|out | morning |
| 11:48:18 | | Nick Quel|out is now known as Quelsaruk (~kvirc@80.103.129.193) |
| 11:50:18 | rasher | morning |
| 11:57:24 | muesli|tarn | g'day mates |
| 12:00 |
| 12:01:14 | rasher | Hrm, shouldn't http://www.rockbox.org/irc/ just link to the wikipage of ircnicks? |
| 12:01:21 | rasher | or at least |
| 12:01:30 | rasher | be updated with the nicks from ircnicks |
| 12:03:21 | Quelsaruk | hmmm |
| 12:04:18 | Quelsaruk | i suppose |
| 12:04:24 | Quelsaruk | ask Bagder :) |
| 12:05:55 | | Join ashridah [0] (ashridah@220-253-120-48.VIC.netspace.net.au) |
| 12:06:14 | | Quit xen` (Read error: 110 (Connection timed out)) |
| 12:06:31 | rasher | Bagder: shouldn't http://www.rockbox.org/irc/ just link to the wikipage of ircnicks, or at least be updated with the nicks from IrcNicks? |
| 12:06:50 | | Join alxcm [0] (~alx@hc6527634.dhcp.vt.edu) |
| 12:07:07 | alxcm | hey all |
| 12:07:12 | Quelsaruk | hi |
| 12:07:27 | alxcm | what's up? |
| 12:13:29 | | Quit alxcm ("leaving") |
| 12:16:16 | rasher | "the latest release of libFLAC has a compiler define (FLAC__INTEGER_ONLY_LIBRARY) that builds the whole library (decoder, encoder, etc.) with integer only" |
| 12:16:19 | rasher | cute |
| 12:25:01 | Bagder | rasher: turning that into a link to the wiki |
| 12:25:48 | linuxstb | rasher: Yes, saw that (and am using it). |
| 12:26:10 | rasher | still, the 64-bit ints :\ |
| 12:26:14 | | Join jyp [0] (~jp@129.23-136-217.adsl.skynet.be) |
| 12:30:00 | rasher | hi there |
| 12:30:12 | jyp | ho ho ho |
| 12:48:23 | HCl | its santa! |
| 12:48:52 | HCl | whatcha gonna get me for christmas :x i've been good! i built a gameboy emu for rockbox :x |
| 12:50:35 | | Join GnagelRam [0] (~chatzilla@gnagelram.olf.sgsnet.se) |
| 12:50:59 | | Quit Quelsaruk (Read error: 104 (Connection reset by peer)) |
| 12:53:07 | linuxstb | I've got libmad and libFLAC running as viewer plugins on the iRiver, but I'm getting some strange crashes - during read/write accesses and after the plugin returns control to Rockbox. |
| 12:53:27 | linuxstb | Does anyone have any debugging suggestions? |
| 12:53:32 | rasher | sounds good (and not so good) |
| 12:53:55 | linuxstb | They both work perfectly in the X11 Simulator. |
| 12:54:23 | *** | Saving seen data "./dancer.seen" |
| 12:54:32 | rasher | Could be ata strangeness perhaps? |
| 12:55:10 | linuxstb | rasher: Maybe, or maybe my plugins are overwriting memory used by Rockbox - but I would expect that to crash the Simulator as well. |
| 12:56:25 | linuxstb | If you recall, my FLAC viewer crashed (never returned from a call to rb->read()) if I was reading from the file as I was decoding it. But when I changed to reading the whole file into memory in advance, then all the reads worked fine. |
| 12:56:33 | | Join webguest93 [0] (~54de5919@labb.contactor.se) |
| 12:57:08 | linuxstb | Now the same happens with calls to rb->write if I am trying to write the output of the decoders to a file on disk - the LED stays on forever and the write() never returns. |
| 12:57:41 | linuxstb | It does all seem to be disk related - I've reformatted my iRiver, but that didn't change anything. |
| 12:58:21 | linuxstb | HCl: Did you have any problems when rockboy was writing debugging information to a file? |
| 13:00 |
| 13:01:10 | | Quit webguest93 (Client Quit) |
| 13:01:21 | HCl | linuxstb: yes, actually |
| 13:01:23 | linuxstb | The crash in the rb->write() call happens on about the 3rd or 4th call - possibly when the write buffer is full and Rockbox actually needs to access the disk. |
| 13:01:32 | HCl | i never even managed to get it to write to a file |
| 13:01:39 | HCl | probably because i messed up the first 3 times |
| 13:01:51 | HCl | and after that it proved unneeded |
| 13:01:59 | HCl | since i had gotten the lcd driver to work |
| 13:03:00 | linuxstb | HCl: And I assume your only reads are to read the entire ROM into memory at startup? |
| 13:03:10 | HCl | pretty much, yes. |
| 13:03:21 | HCl | but eventually i'm gonna want to store savegame data on disk |
| 13:04:36 | linuxstb | Would you mind putting some test writes (e.g. writing about 512KB of random data to disk) into your program. Ideally these should run about 30 seconds after the reads finished to duplicate my behaviour. |
| 13:05:07 | HCl | um. |
| 13:05:12 | HCl | maybe once i'm awake :X |
| 13:06:19 | linuxstb | HCl: I'll download your source and try it myself. |
| 13:06:26 | HCl | okay |
| 13:10:40 | | Join amiconn [0] (jens@pD9F5270D.dip.t-dialin.net) |
| 13:20:04 | rasher | linuxstb: another interesting fact - the batterytest plugin crashes as well |
| 13:20:08 | | Join Bagder_ [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) |
| 13:21:33 | amiconn | rasher: Battery_test writes a big file, then reads it at regular intervals. Plus it writes a .log file... |
| 13:21:53 | amiconn | sort.rock does work? |
| 13:22:34 | rasher | Doesn't happen here afaics. When I start battery_test, the iRiver stops responding. It creates a battery.dummy in the root-dir, this file is empty. |
| 13:23:06 | rasher | Hm, I don't know about that actually. I just added it in the wiki because I assumed it did |
| 13:24:27 | rasher | How do I check? |
| 13:24:58 | amiconn | sort.rock should sort the all lines of a file alphabetically. |
| 13:25:32 | amiconn | It works as a viewer plugin, i.e. "Open with.." -> "sort" on a file should sort that file |
| 13:25:43 | rasher | aha |
| 13:25:48 | rasher | looks like it worked |
| 13:26:03 | rasher | although for the file I tried it with, the lines were already in order |
| 13:26:04 | amiconn | Maybe it depends on the filesize |
| 13:26:13 | rasher | (and only 2 lines) |
| 13:26:27 | amiconn | (assuming there are problems with file read/write on iriver) |
| 13:26:39 | rasher | yes |
| 13:26:56 | rasher | sort went trough reading/writing just fine |
| 13:27:42 | amiconn | Battery test should create a big file (battery.dummy) in the root. This file will be the same size as the free RAM, i.e. ~31 MB on iriver. |
| 13:28:11 | amiconn | Then it opens a log and writes out the battery status and current time both to the log and the screen |
| 13:28:37 | rasher | that never happens |
| 13:28:51 | rasher | it only gets as far as to create battery.dummy afaics |
| 13:28:59 | rasher | or maybe I should let it try for a while |
| 13:29:01 | amiconn | After the time has passed that the buffer runs empty if it were a 128 kbps MP3, it re-reads the file and writes a new log entry |
| 13:29:29 | * | rasher starts batterytest |
| 13:29:29 | amiconn | (Thereby simulating the harddisk load pattern of mp3 playback) |
| 13:29:49 | amiconn | 31 MB should take a long time to drain on iriver... |
| 13:31:08 | rasher | oh |
| 13:31:10 | rasher | it exit |
| 13:31:31 | amiconn | If you press off, it should exit, otherwise not |
| 13:31:41 | rasher | I didn't |
| 13:31:58 | rasher | -rwxr-xr-x 1 rasher trusted 32M Aug 1 2003 battery.dummy |
| 13:32:00 | linuxstb | Well, I can't make rockboy crash with disk writes. I'm going to try to write a standalong plugin based on helloworld.c and see if I can make it crash with disk accesses. |
| 13:32:02 | rasher | well at least that's correct |
| 13:32:16 | rasher | maybe it crashes in the read? |
| 13:32:48 | amiconn | No battery.log? |
| 13:33:01 | linuxstb | It could just be a bug in my plugins (or my build commands). |
| 13:33:25 | amiconn | rasher: Maybe it exits because the battery state isn't properly detected yet. |
| 13:33:38 | rasher | amiconn: ah, that might very well be it |
| 13:33:40 | amiconn | There is a check that makes it exit if <5% battery left |
| 13:33:51 | rasher | that's probablly it then |
| 13:34:00 | amiconn | battery_test.c, lines 79..81 |
| 13:34:35 | amiconn | Okay, so battery_test simply does not work (yet), because the battery state check is wrong |
| 13:35:18 | * | rasher turns off that check and builds again |
| 13:38:03 | * | rasher starts battery_test |
| 13:39:35 | rasher | aha |
| 13:39:37 | rasher | it's working now |
| 13:39:50 | rasher | after 1:40 - battery - 1% :) |
| 13:42:10 | rasher | 31mb 128kbps mp3.. |
| 13:42:17 | rasher | I could be waiting for that for a while |
| 13:42:49 | Bagder_ | about 30 mins or so I'd guess |
| 13:43:00 | linuxstb | I'm not sure, but I think my plugins have decided to work now... |
| 13:43:48 | linuxstb | Could it be something to do with the battery indicator, causing problems with the disk accesses? |
| 13:44:41 | amiconn | rasher: ~33 min |
| 13:45:20 | rasher | linuxstb: shorten is both lossless and lossy apparently |
| 13:45:25 | rasher | but it looks like the license is horrible |
| 13:45:47 | rasher | let's see about free implementations |
| 13:45:47 | linuxstb | rasher: Yes, and so is WavPack.... |
| 13:46:14 | rasher | ah |
| 13:46:43 | sneakums | ah well, we'll always have paris^Wflac |
| 13:47:56 | * | rasher stares blankly at sneakums |
| 13:49:43 | linuxstb | Yes, my libmad decoder is writing to disk OK now. I've just played (on my PC) two seconds of audio decoded by libmad on the iRiver. |
| 13:50:09 | rasher | hurray |
| 13:50:29 | rasher | looks like the shorten source is under some silly non-commercial license, and no Free implementations exist |
| 13:51:15 | rasher | and a horribly vague license at that |
| 13:51:37 | linuxstb | Shorten is rapidly being replaced by FLAC as the de-facto lossless standard (with Monkey's and WavPack being minority formats). But for example, www.archive.org still use Shorten for their downloads. |
| 13:52:07 | rasher | okay |
| 13:52:10 | linuxstb | So Shorten support would be nice, but if the license doesn't allow it, then it's no big loss. |
| 13:52:25 | Bagder_ | got a URL for the shorten license? |
| 13:52:26 | rasher | Well we have to use a gpl compatible license don't we? |
| 13:52:32 | DMJC | what about matroska audio support? |
| 13:52:33 | Bagder_ | yes we do |
| 13:52:38 | linuxstb | Unless we decide we want to make a GPL exception for audio codecs. |
| 13:52:38 | Bagder_ | we distribute binaries |
| 13:52:39 | rasher | http://www.hornig.net/shorten/#license |
| 13:52:58 | rasher | that's not the primary shorten site, but the license is correct |
| 13:53:38 | Bagder_ | its short at least ;-) |
| 13:53:39 | rasher | linuxstb: relicensing to get shorten support.. sounds like a poor choice |
| 13:54:18 | linuxstb | rasher: iwe may have problems with other audio codecs as well. I'm not saying I'm in favour, I'm just mentioning the option. |
| 13:54:58 | rasher | linuxstb: doesn't that all fall down the moment we include outside gpl code? |
| 13:55:00 | Lynx_ | DMJC: istn't matroska just a container format? |
| 13:55:07 | rasher | as in, don't we lose that option |
| 13:55:31 | Bagder_ | rasher: that is indeed a grey area |
| 13:55:40 | linuxstb | I'm not an expert, but I'm sure the Linux Kernel has an exception to allow non-GPL'd kernel modules. |
| 13:55:40 | DMJC | not sure, but there is a matroska audio format |
| 13:55:50 | Bagder_ | it isn't much researched, as people tend to avoid that thinking |
| 13:56:02 | Bagder_ | linuxstb: actually no |
| 13:56:06 | DMJC | http://www.matroska.org/ |
| 13:56:12 | Bagder_ | linuxstb: its just Linus who says he doesn't care |
| 13:56:26 | Bagder_ | Torvalds that is |
| 13:56:49 | linuxstb | Bagder: So, strictly speaking, binary modules infringe the kernel license? |
| 13:56:50 | rasher | Alright. I'm no expert by far, it was just my understanding that by including other people's GPL code, you give up the ability to decide your own license (because then you'd be in violation with the GPL of the included code) |
| 13:56:59 | Bagder_ | linuxstb: yes, according to FSF |
| 13:57:14 | Lynx_ | DMJC: from the site: "Matroska, the extensible open standard Audio/Video container" |
| 13:57:18 | linuxstb | rasher; Yes, that's true, I think every contributor would need to agree. |
| 13:57:58 | rasher | linuxstb: and contributors might be something like "anyone involved in libmad" (assuming libmad is GPL, which I've no idea if it is) |
| 13:58:01 | rasher | right? |
| 13:58:03 | ashridah | rasher: that doesn't mean you can't license your own code with two different licenses |
| 13:58:19 | Bagder_ | rasher: no, only the ones owning the copyrights in libmad |
| 13:58:33 | linuxstb | I'm sorry I mentioned this now... |
| 13:58:35 | rasher | :) |
| 13:58:40 | Bagder_ | the copyright owner can relicense at will |
| 13:59:17 | * | linuxstb goes to read GPL faqs |
| 13:59:44 | rasher | ashridah: but for the non-GPL licensed code, you'd have to rip out everything GPLd |
| 13:59:50 | rasher | which would be a pain :\ |
| 13:59:54 | Bagder_ | but I strongly think we should avoid adding exceptions to the GPL license |
| 13:59:54 | rasher | I see why people avoid this |
| 14:00 |
| 14:00:35 | DMJC | just do what nvidia do |
| 14:00:38 | DMJC | obfuscate |
| 14:00:51 | Bagder_ | they provide a binary |
| 14:00:55 | ashridah | Bagder: particularly since the GPL code you link in needs to have an exception to YOU |
| 14:00:56 | Bagder_ | which violates the GPL |
| 14:00:58 | rasher | and some Free glue |
| 14:01:10 | Bagder_ | ashridah: yes |
| 14:01:11 | DMJC | they use lgpl code the bridge afaik |
| 14:01:18 | | Join preglow [0] (thomj@s183a.studby.ntnu.no) |
| 14:01:33 | Bagder_ | DMJC: that doesn't help, it is still technically a violation |
| 14:01:40 | Bagder_ | according to FSF's interpretation |
| 14:01:51 | Bagder_ | but Linus, as copyright owner does't persue |
| 14:01:55 | DMJC | bah, screw stallman, go with the practical option |
| 14:02:27 | DMJC | don't the rockbox developers own the copyright to their own code? |
| 14:02:28 | preglow | haha |
| 14:02:35 | Bagder_ | DMJC: yes of course |
| 14:02:45 | preglow | DMJC: you always own the copyright on your own code |
| 14:02:50 | preglow | DMJC: unless you sign it away |
| 14:03:01 | DMJC | so just choose not to pursue it? |
| 14:03:20 | rasher | Well, say we include a GPL codec |
| 14:03:25 | preglow | DMJC: practical is not always enough, i'm afraid, some people have to be forced to cooperate |
| 14:03:25 | rasher | and a non-gpl codec |
| 14:03:42 | rasher | the authors of the GPL codec would need to agree to this |
| 14:03:54 | Bagder_ | rasher: yes |
| 14:04:04 | linuxstb | rasher: What if the GPL'd and non-GPL'd codec were not linked to Rockbox at the same time? |
| 14:04:04 | DMJC | myself, i'd have bsd licensed it, I mean it's not like someone could ever make this stuff worth billions of dollars heh |
| 14:04:09 | Bagder_ | it would mean pain, trouble and more crap |
| 14:04:23 | preglow | DMJC: with a codec, i agree with you |
| 14:04:26 | rasher | DMJC: that doesn't change anything |
| 14:04:36 | rasher | DMJC: assuming you mean that rockbox should be bsd |
| 14:04:51 | rasher | outside (GPL) code could still create license problems |
| 14:04:53 | Bagder_ | if Rockbox were BSD, we'd avoid some problems |
| 14:04:58 | preglow | but why is this an issue, we aren't going to go into some licence trickery, are we? |
| 14:05:14 | Bagder_ | it isn't really an issue |
| 14:05:18 | rasher | preglow: read the irclog for 30 minutes before you entered :) |
| 14:05:25 | preglow | yes, i did |
| 14:05:26 | Bagder_ | until we want to use codecs that aren't incompatible with GPL |
| 14:05:30 | rasher | Yes. |
| 14:05:33 | preglow | but that's not an option anyway, is it? |
| 14:05:47 | rasher | it is.. given a number of things happen |
| 14:05:49 | Bagder_ | well, that's what we discuss :-) |
| 14:05:52 | preglow | heh |
| 14:05:56 | rasher | but it's all a big mess |
| 14:06:02 | preglow | you're opening a can of worms, that's for sure |
| 14:06:11 | Bagder_ | the thumb rule must be: no GPL exceptions |
| 14:06:14 | rasher | and the only codec right now is shorten, which isn't that interesting |
| 14:06:35 | preglow | there are great big lists of which licenses are compatible with gpl |
| 14:06:40 | rasher | So I think the conclusion is: Rockbox doesn't care right now. |
| 14:06:40 | amiconn | preglow: An unrelated question, out of curiosity: Is your norsk translation nynorsk or bokmål? |
| 14:06:46 | preglow | amiconn: bokmål |
| 14:06:58 | linuxstb | Monkey's Audio iis interesting, but I think the processor requirements make the license problem a non-issue. |
| 14:07:14 | preglow | amiconn: though it probably isn't that big a difference |
| 14:07:58 | linuxstb | Should I mention patents? What's the law in Sweden? |
| 14:08:05 | Lynx_ | linuxstb: well, practically support for minor lossless codecs is not that important anyway, as they can be converted to flac for example without loss |
| 14:08:19 | preglow | ahhh... patents.... |
| 14:08:43 | rasher | Lynx_: Very good point :) |
| 14:08:44 | preglow | by the way, when you buy an mp3 player, who has the license to play back mp3s? the company that made the player or you? |
| 14:08:56 | linuxstb | But if the worse happens, we are still lieft with OGG and FLAC - not that bad a situation. |
| 14:09:09 | preglow | linuxstb: heck, that would cover all my streaming music needs |
| 14:09:21 | | Quit Bagder_ ("Leaving") |
| 14:09:29 | preglow | i'm almost running vorbis exclusively as it is |
| 14:10:44 | Lynx_ | i'd guess out of all iriver owners less than 10% use ogg, and way less would use flac |
| 14:10:54 | rasher | Hrm |
| 14:10:59 | rasher | I think ogg usage is a bit larger |
| 14:11:23 | Lynx_ | actually i have not met anyone that has his/her main music library in flac, unless they need high quality stuff because they are musicians or such |
| 14:11:51 | rasher | mainly because iRiver is one of the few players with ogg-vorbis, so there'd be a rather large concentration of ogg users compared to general population |
| 14:11:53 | preglow | i'd use flac mainly for music production |
| 14:11:54 | Lynx_ | rasher: hmm, it may be on the iriver, because that is a selling point? |
| 14:11:58 | linuxstb | Lynx_: I do. |
| 14:12:04 | ashridah | Lynx_: i know someone who converted all his stuff to flac when the company who made his player added support for it (ie, he reripped all his music) |
| 14:12:05 | rasher | linuxstb: exactly :) |
| 14:12:06 | preglow | i also keep my ripped vinyls as flac files |
| 14:12:31 | Lynx_ | hmm, ok, my sample is probably too small ;) |
| 14:14:05 | Lynx_ | googling for file:.flac gives 1390, for .ogg 6950 and for .mp3 351000 results |
| 14:14:38 | linuxstb | Going back to my iRiver problem - I'm still getting crashes sometimes. But other times, the disk writes are working perfectly. Either it will crash on the first disk access, or it will work fine for them all. |
| 14:14:52 | rasher | Oh dear |
| 14:14:57 | rasher | battery_test crashed |
| 14:15:14 | rasher | I04:IllInstr |
| 14:15:20 | Lynx_ | linuxstb: does the false battery status go up and down, or stay more or less the same? |
| 14:15:22 | rasher | at 00000002 |
| 14:15:42 | linuxstb | It may have something to do with USB - it seems to always crash if I run it immediately after disconnecting. If I power down, then restart, it seems to work. |
| 14:15:45 | preglow | linuxstb: i didn't do anything but write files yesterday, never saw a crash |
| 14:16:12 | preglow | linuxstb: and a LOT of usb connects |
| 14:16:30 | preglow | linuxstb: that is, never saw a crash once i took my huge file buffer off the stack :P |
| 14:16:40 | linuxstb | Lynx_: At the moment, the indicator says ? |
| 14:16:55 | linuxstb | Lynx: But it is now flashing empty. |
| 14:17:07 | rasher | Battery_test said 1% |
| 14:17:40 | rasher | hrm, maybe even -1% |
| 14:17:52 | rasher | which is a stunning number |
| 14:17:54 | Lynx_ | linuxstb: i meant: is it determined at the beginning, and then if it is 'high' all your disk writes work, and if it is determined 'low' at the beginning, the first one crashes already. also, after usb connect the battery may be especially low. |
| 14:18:28 | amiconn | battery == -1% means "not yet known" in rockbox |
| 14:18:59 | amiconn | The power thread first measures for a while until it sets the real status |
| 14:19:33 | * | amiconn remembers something... |
| 14:19:40 | Lynx_ | does rockbox shutdown the box with low battery, or does it just physically run out of juice? |
| 14:21:04 | linuxstb | Are there any battery-level checks in the ATA code that I could remove? |
| 14:23:23 | amiconn | Nope, I just checked |
| 14:24:01 | amiconn | I remembered that there might be such check, as we have a function for that: bool battery_level_safe() |
| 14:24:32 | amiconn | Imho the battery state computation should be fixed. Shouldn't be that hard. |
| 14:25:00 | amiconn | Btw, amyone here who is familiar with X11 programming? |
| 14:25:15 | * | HCl quietly reads along |
| 14:28:00 | linuxstb | amioconn: Not for about 15 years - what do you want to do? |
| 14:28:18 | amiconn | I'm currently looking into the X11 simulator |
| 14:28:47 | | Join R3nTiL_ [0] (~zorroz@83.69.98.241) |
| 14:28:48 | amiconn | There are button handling problems which can imho only be solved if we use an interval timer |
| 14:29:17 | amiconn | Currently the X11 simulator is completely non-realtime |
| 14:30:16 | | Quit jyp ("poof!") |
| 14:30:24 | amiconn | I already found XtAppAddTimeOut(), but I'm not sure whether I'll get this to work. I also don't know yet where to put it. |
| 14:30:41 | amiconn | The whole X11 sim source looks a bit messy to me... |
| 14:31:18 | amiconn | I would then also need to disable X's keyboard auto-repeat |
| 14:31:49 | linuxstb | amiconn: I can't help with any of that. I think I've forgotten anything I ever knew about X11. |
| 14:32:24 | | Quit DMJC ("Leaving") |
| 14:35:35 | preglow | and i just plain hate x11 |
| 14:37:22 | amiconn | linuxstb: Maybe your random crashes are because of a stack overflow? I just saw that the stack overflow check in the thread scheduler is disabled for iriver & gmini |
| 14:37:31 | amiconn | (Btw, I wonder why this is) |
| 14:38:30 | preglow | good question |
| 14:38:37 | preglow | how large is the stack allowed to be? |
| 14:38:40 | preglow | normally, that is |
| 14:39:07 | linuxstb | Could I increase the stack to a huge size to check if that changes anything? |
| 14:39:28 | preglow | smashing the stack boundary sure does weird things |
| 14:39:36 | preglow | my h120 would never come out of usb mode when i managed that |
| 14:39:44 | preglow | and it would write partly garbage |
| 14:40:05 | linuxstb | Yes, I don't know what the stack usage of libFLAC and libmad is like, so that's a possibility. |
| 14:40:10 | amiconn | The standard thread stack size is 1024 bytes. The main thread (where plugins run in) has a bit more - 8 KB iirc |
| 14:41:11 | amiconn | The USB thread get 3 KB - it did overflow before... |
| 14:42:06 | linuxstb | amiconn: Should I try changing the 0x2000 in line 61 of firmware/app.lds (is that the right place?) |
| 14:42:58 | amiconn | I think it is. You could also try to enable the overflow check in thread.c , but I'd ask Linus first why this is disabled |
| 14:43:32 | linuxstb | I'll try adding a zero to the stack size and see what happens. |
| 14:44:07 | HCl | hm |
| 14:44:26 | HCl | rockboy crashes now and then, i wonder whether its related |
| 14:45:16 | preglow | as a matter of fact, it would not surprise me at all if this is true |
| 14:46:12 | linuxstb | Well, my first test after increasing the stack size seems to be working. I'll try some more... |
| 14:46:36 | HCl | stack size of 1024 bytes? O.O; |
| 14:46:44 | preglow | not for plugin |
| 14:46:47 | HCl | oh. |
| 14:47:02 | amiconn | Hey, you're programming an embedded system. |
| 14:47:06 | preglow | but yes, i quite happily smashed my stacks with a not very large number of kilobytes |
| 14:47:11 | HCl | mhm. |
| 14:47:12 | preglow | stack |
| 14:47:23 | preglow | and it did give rise to quite strange things, heh |
| 14:47:33 | HCl | amiconn: shall i clean up rockboy's code some more? |
| 14:48:16 | amiconn | I did not get it to compile on the sim so far. Didn't investigate yet... |
| 14:49:05 | amiconn | It complains about conflicting types for vsnprintf() - that's only a warning. It errors out on not finding widgets.h |
| 14:51:11 | linuxstb | No, increasing the stack size to 0x20000 didn't seem to solve the problem, but it's possibly working slightly better. I'll try increasing it even more. |
| 14:53:41 | linuxstb | I've enabled the stack-overflow check in thread.c, let's see what happens. |
| 14:54:10 | HCl | what does the stack overflow check do? |
| 14:54:27 | *** | Saving seen data "./dancer.seen" |
| 14:54:57 | linuxstb | HCl: It causes my iRiver to crash immediately on startup.... :-( |
| 14:55:02 | HCl | :X |
| 14:55:09 | HCl | bricked? :X |
| 14:55:17 | HCl | or wait, you didn't reflash.. |
| 14:55:29 | linuxstb | No, iRiver firmware is loading fine. |
| 14:55:34 | HCl | *nods* |
| 14:55:47 | linuxstb | Best not to touch what I don't understand.... |
| 14:57:59 | HCl | amiconn: shall i clean up the code of rockboy some? or..? |
| 14:58:18 | amiconn | I think leave it as-is for now. |
| 14:58:26 | HCl | mk.. |
| 14:58:50 | HCl | i was just hoping it could be allowed in cvs since it makes it easier for more people to work on it if they want to :X |
| 15:00 |
| 15:00:07 | preglow | HCl: have you modified the gnuboy code much? |
| 15:00:38 | HCl | a fair deal, yea, i can make you a .patch if you want to? |
| 15:00:55 | HCl | mostly some speed optimizations and a completely different way to do screen updates |
| 15:00:58 | preglow | nono, i have no time for coding right now |
| 15:01:00 | preglow | i was just wondering |
| 15:03:39 | muesli|tarn | preglow: disabling autostart for removable devices in tweakui didnt help btw |
| 15:04:24 | preglow | muesli|tarn: did for me |
| 15:04:43 | preglow | muesli|tarn: that is, i just removed autostart for j:\, which is the drive my h120 always shows up as |
| 15:04:50 | sneakums | there's only one way to settle this - a duel! |
| 15:05:00 | preglow | !!! |
| 15:05:12 | * | preglow fetches his dueling pistol |
| 15:05:16 | HCl | autostart settings is just when you have your iriver plugged in |
| 15:05:18 | * | rasher fetches 2 banjos |
| 15:05:19 | rasher | oh |
| 15:05:24 | HCl | and you select it |
| 15:05:27 | HCl | and click properties |
| 15:05:34 | HCl | autoplay -> always take this action: no action |
| 15:05:35 | HCl | done. |
| 15:05:39 | preglow | doesn't work here |
| 15:05:43 | preglow | that option isn't here |
| 15:05:46 | sneakums | i don't think there's a way to stop windows from automatically mounting the disk |
| 15:05:50 | muesli|tarn | yepp, here too |
| 15:05:51 | preglow | it's here for cdroms and such, but not for the h120 |
| 15:05:54 | sneakums | even if you disable autoplay |
| 15:06:07 | preglow | nono, mounting = okay, the pesky screen that asks me what i want to do is not |
| 15:06:17 | preglow | i want it to mount, but not nag |
| 15:06:17 | sneakums | ! |
| 15:06:19 | HCl | yea, thats autoplay |
| 15:06:22 | HCl | it works here for h140 |
| 15:06:38 | preglow | i'm okay anyway, it doesn't appear here anymore |
| 15:06:42 | muesli|tarn | autoplay/drives |
| 15:06:52 | muesli|tarn | i have disabled my typical drives |
| 15:06:55 | sneakums | is this specific to some version of windows or something? |
| 15:06:57 | muesli|tarn | let see what happens |
| 15:07:05 | sneakums | win2k never bothered me when i plugged in my h120 |
| 15:07:08 | muesli|tarn | i am running xp |
| 15:07:30 | rasher | xp is a bitch with the autoplay |
| 15:07:39 | muesli|tarn | yeah, 2k is quit uninteresting in an new plugged ihp |
| 15:08:06 | preglow | xp is a bitch, period |
| 15:08:08 | Lynx_ | muesli|tarn: home or pro? |
| 15:08:21 | muesli|tarn | pro |
| 15:08:34 | linuxstb | Does anyone here understand firmware/app.lds ? |
| 15:08:57 | muesli|tarn | heureka! |
| 15:09:01 | muesli|tarn | autoplay/drives |
| 15:09:13 | muesli|tarn | disabling the drives worxxx |
| 15:09:31 | muesli|tarn | ->tweakui |
| 15:10:09 | Lynx_ | or gpedit.msc -> computer config -> system -> turn off autoplay -> enabled |
| 15:11:26 | linuxstb | Aah. Just realised I was changing the stack size for the Gmini build..... |
| 15:12:12 | amiconn | :) |
| 15:12:24 | muesli|tarn | another anoying thing is that the iriver starts everytime with the same song after i pluged it to the computer |
| 15:12:25 | amiconn | Good that you found it. |
| 15:12:28 | linuxstb | Who agreed that line 61 was correct :-) |
| 15:12:47 | linuxstb | I'm now changing line 185 of app.lds |
| 15:13:44 | sneakums | muesli|tarn: the iriver firmware isn't too smart |
| 15:14:26 | sneakums | i have a feeling they might be storing the current track by number, and of course the numbering is invalidated if files are added or removed |
| 15:16:21 | rasher | so they just start by number 0001 :) |
| 15:16:26 | | Join Quelsaruk [0] (~kvirc@80.103.129.193) |
| 15:16:27 | * | rasher punches iRiver |
| 15:16:29 | Quelsaruk | afternoon |
| 15:18:20 | preglow | rasher: they do store current file by number, yes |
| 15:19:32 | Quelsaruk | amiconn: did you check Omnipage pro SAPI voices? |
| 15:19:40 | amiconn | Yes. |
| 15:20:09 | amiconn | Unfortunately they don't appear in the list, as you found as well |
| 15:22:51 | Quelsaruk | and i suspect there's no way to make them appear in the list |
| 15:22:53 | Quelsaruk | :) |
| 15:23:03 | amiconn | Yay! Disabling X keyboard autorepeat works! Hacky, but that is fixable... |
| 15:23:20 | Quelsaruk | ? ein? |
| 15:27:04 | linuxstb | amiconn: I think that's done the job :-) Increasing the stack to 0x20000 fixed my libmad plugin, but I had to increase it to 0x50000 to get libFLAC working. |
| 15:27:52 | amiconn | linuxstb: That means some more work on them, changing some variables to static... |
| 15:28:27 | linuxstb | amiconn: Yep, but at least they seem to be working reliably now. That's a big step. |
| 15:28:34 | amiconn | agreed. |
| 15:29:23 | linuxstb | Is there a way I can display the current stack usage? |
| 15:29:53 | linuxstb | Sorry, I've realised that doesn't make much sense. |
| 15:29:55 | amiconn | Hmm. I dunno whether the stack fill & check does work correctly. |
| 15:30:22 | amiconn | iRiver crashing with the check in thread.c enabled suggests that it doesn't |
| 15:30:48 | amiconn | If it works, you can check the peak stack usage of each thread in the debug menu. |
| 15:42:05 | linuxstb | At least I can now happilly say that both libmad and libFLAC are correctly decoding the data on the iRiver. So technically, the iRiver now supports FLAC - convert to WAV using Rockbox (in about 8% of real-time), then play it using the iRiver firmware :-) |
| 15:45:39 | | Part amiconn |
| 15:47:20 | Lynx_ | linuxstb: does libmad work in realtime? |
| 15:47:39 | linuxstb | Lynx: No :-( Even slower than FLAC - about 4% of real-time on my 192kbps test files. |
| 15:48:02 | linuxstb | But I'm not going to worry about that until Linus makes the iRiver run at full-speed. |
| 15:48:26 | preglow | mad should be even slower than flac |
| 15:48:45 | preglow | no surprise there |
| 15:51:01 | Lynx_ | why is the iriver firmware so much faster? it's all software decoding, too, isn't it? |
| 15:51:41 | preglow | hardware isn't properly utilized yet |
| 15:52:19 | linuxstb | Also, I'm sure the iRiver MPEG decoder will be a proprietory version, highly optimised for the coldfire. |
| 15:52:29 | Lynx_ | ah, so the processor runs faster with the iriver firware than it does currently with rockbox? |
| 15:52:32 | linuxstb | I think Motorola have written such a MP3 decoder. |
| 15:52:40 | Lynx_ | ok |
| 15:52:52 | linuxstb | Lynx_: Yes, probably at least 10x faster. |
| 15:53:00 | preglow | the mp3 decoder is very probably motorolas own |
| 15:53:09 | preglow | i doubt very much we'll be able to make ours that efficient |
| 15:53:31 | linuxstb | I forget the details, but a google for emac and mp3 will probably find the press release. |
| 15:53:45 | preglow | yes, it's on the 5249 page |
| 15:54:09 | Lynx_ | well, do we know how efficient the iriver one is? |
| 15:54:22 | preglow | no |
| 15:54:27 | preglow | and we probably never will |
| 15:54:43 | preglow | the closest we can do is compare battery usage, but that depends on a lot of other factors as well |
| 15:54:58 | preglow | but why should we care? we'll optimize our mp3 decoder as much as we can anyway |
| 15:58:15 | Lynx_ | an then we can always think that maybe the iriver decoder also just gets by with the available processor power ;) |
| 16:00 |
| 16:00:37 | | Quit R3nTiL_ () |
| 16:04:11 | preglow | haha |
| 16:04:27 | preglow | hadn't it been for the fact that i know the motorola decoder just uses 20% cpu ;) |
| 16:07:31 | Lynx_ | hmm, is it correct that if the we can't get libmad to use only like 50% (or less) there will be no crossfading? |
| 16:08:02 | Lynx_ | unless of course it is somehow calculated in non realtime while the first file is still playing... |
| 16:08:09 | linuxstb | Lynx_: I don't know how much CPU cross-fading will need, but surely it will be less than the actual MP3 decoding itself. |
| 16:08:25 | Lynx_ | but don't you have to decode two files at the same time? |
| 16:08:30 | sneakums | and as long as you're ahead of playback by a bit, you won't need to decode two files at once |
| 16:10:00 | | Join Sucka [0] (~NNSCRIPT@host81-156-215-25.range81-156.btcentralplus.com) |
| 16:10:14 | Lynx_ | are the files read into ram and then decoded (into ram), or decoded from disk into ram? |
| 16:10:40 | linuxstb | Lynx_: My tests are reading the files into RAM in advance, and then decoding them. |
| 16:10:54 | preglow | Lynx_: you can just start decoding the other file as soon as you're done decoding the first |
| 16:11:01 | preglow | Lynx_: you dont have to run the decoders in parallell |
| 16:11:12 | sneakums | and buffering lots of undecoded data should be better for battery life |
| 16:11:30 | linuxstb | preglow: As long as you have enough unplayed data in the PCM buffer fromt he previous track. |
| 16:11:51 | linuxstb | So that buffer needs to be big enough for that. |
| 16:11:54 | Lynx_ | ok, i get it |
| 16:12:45 | Lynx_ | it's 32 mb ram in the iriver, right? and pcm is about 8 times more data than mp3? |
| 16:12:51 | preglow | linuxstb: yes, but that's just a matter of buffering long enough ahead |
| 16:13:00 | preglow | Lynx_: that varies |
| 16:13:24 | Lynx_ | preglow: i know, but roughly 8 times... |
| 16:13:30 | preglow | more like nine |
| 16:13:46 | preglow | but no one uses 128kbs mp3 anymore |
| 16:13:47 | preglow | i hope |
| 16:14:27 | Lynx_ | but in mpc to mp3 back to pcm the second pcm file should be smaller, right? or is pcm always the same size per time? |
| 16:14:38 | Lynx_ | s/mpc/pcm |
| 16:14:40 | sneakums | pcm is fixed. |
| 16:14:44 | preglow | hell no |
| 16:14:50 | preglow | pcm is always the same size per second |
| 16:15:17 | preglow | a pcm file might contain perfect silence, and it would still be just as big as a pcm file containing music |
| 16:15:30 | Lynx_ | hmm, that's why it's called uncompressed i guess ;) |
| 16:15:44 | sneakums | a reasonable thesis. |
| 16:16:02 | | Quit Cassandra_ (Read error: 110 (Connection timed out)) |
| 16:16:06 | | Join Cassandra_ [0] (~christi@213.78.106.215) |
| 16:16:25 | Lynx_ | and that's why the lossless codecs are around...i learn more every day in #rockbox :) |
| 16:16:55 | Lynx_ | so flac is just like zip specialized for audio data? |
| 16:17:07 | rasher | Exactly |
| 16:17:14 | rasher | well |
| 16:17:19 | sneakums | altohugh flac tries different schemes for each block |
| 16:17:27 | rasher | It includes frame information and such so you can seek |
| 16:17:32 | rasher | which zip doesn't |
| 16:17:35 | linuxstb | Going back to my stack problems - libFLAC and libmad both now seem happy with a 32K stack. I can probably reduce it even more. |
| 16:17:37 | sneakums | sometimes it can't save space at all, so some blocks may be uncompressed |
| 16:18:44 | rasher | linuxstb: might a different stack sice change cpu usage? |
| 16:18:56 | linuxstb | rasher: I don't think so. |
| 16:19:04 | rasher | Okay. |
| 16:19:10 | sneakums | you either have enough stack, or you're scribbling all over the heap |
| 16:20:36 | rasher | I'll scribble all over your heap in a minute. |
| 16:20:40 | sneakums | :< |
| 16:21:14 | * | Lynx_ looks up heap in wikipedia |
| 16:22:37 | * | Lynx_ notices that it does not make sense to look up single words when you don't have a clue about the general concepts |
| 16:23:35 | sneakums | heh. |
| 16:23:37 | * | rasher gives Lynx_ a cookie |
| 16:24:24 | sneakums | i used the term in a more general sense than what the wikipedia article describes |
| 16:24:42 | * | Lynx_ greedily grabs the cookie, almost biting rashers hand |
| 16:25:02 | sneakums | and by "more general" i mean "wrong" |
| 16:25:54 | Lynx_ | sneakums: so it's a good thing i didn't understand the article? ;) |
| 16:33:28 | | Join jyp [0] (trilluser@83-134-33-22.Marais.GoPlus.FastDSL.tiscali.be) |
| 16:33:40 | | Join webguest93 [0] (~5345624c@labb.contactor.se) |
| 16:33:44 | | Join R3nTiL_ [0] (~zorroz@83.69.98.76) |
| 16:34:34 | | Quit ashridah ("sleep.") |
| 16:37:39 | | Quit webguest93 (Client Quit) |
| 16:37:51 | | Quit R3nTiL_ (Client Quit) |
| 16:46:55 | | Quit Diway () |
| 16:50:23 | Lynx_ | another question: if pcm is about 9 times as much as mp3 in data/time, and the iriver has 32 mb ram, we effectively get only the same buffering time as on the 4mb archos? |
| 16:50:49 | linuxstb | It depends how big the PCM buffer is - it will probably only be a few seconds, at the most. |
| 16:51:27 | Lynx_ | ah, right |
| 16:51:45 | preglow | the buffering time will be lousy with wav and such, yes |
| 16:51:55 | preglow | that's why you shouldn't use wavs on portable players ;) |
| 16:52:23 | sneakums | Lynx_: the ram will mostly be used to buffer mp3s and such, not decoded pcm |
| 16:52:27 | Lynx_ | how is the flac compression ratio? |
| 16:52:42 | linuxstb | WAV is all I've been using with the iRiver firmware - it can't play any of my compressed files :-( |
| 16:53:10 | linuxstb | But I have to admit, I rarely use it at the moment. |
| 16:53:21 | preglow | flac compression is usually around 1:2 |
| 16:53:28 | sneakums | the iriver was the first halfway decent player that would play vorbises |
| 16:53:28 | Lynx_ | linuxstb: and now you can, with if you wait a litte ;) |
| 16:53:36 | sneakums | before that i just suffered in silence |
| 16:53:43 | preglow | linuxstb: why couldn't you? |
| 16:54:03 | preglow | linuxstb: do you exclusively collect protected wma's or somethinmg? |
| 16:54:05 | rasher | we loves them vorbises.. preciousssesssss |
| 16:54:22 | sneakums | he mentioned mp2 at some point |
| 16:54:27 | preglow | ahh |
| 16:54:31 | *** | Saving seen data "./dancer.seen" |
| 16:54:33 | Lynx_ | wasn't he the flac guy? |
| 16:54:35 | preglow | well lucky him, mad supports all mpeg layers |
| 16:54:42 | rasher | flac and mp2, I think |
| 16:54:49 | linuxstb | My files are either MP2 (recordings from European digital radio/TV), AC3 (US digital TV) or FLAC. |
| 16:55:06 | preglow | linuxstb: are there tools to rip the mp2 straight from the broadcast? |
| 16:55:20 | linuxstb | preglow: Yes - linuxstb.org/">http://www.linuxstb.org/ :-) |
| 16:55:25 | preglow | hgahaha |
| 16:56:24 | linuxstb | It's trivial using the Linux DVB drivers from http://linuxtv.org - you just call a few ioctls to tune the card, another one to set "PID filters", and then read the MPEG Transport Stream direct from a device file. |
| 16:56:34 | Lynx_ | linuxstb: do you have to split the radio mp2 into songs by hand? If you want to have one file per song in the first place, that is. |
| 16:56:39 | preglow | which is how it should be |
| 16:57:36 | linuxstb | Lynx_: Yes. What I normally do is create a .cue file for shows that I want to listen to more than once. Otherwise, I just listen to the whole broadcast (John Peel, RIP) from start to end. |
| 16:58:04 | preglow | rip indeed |
| 16:58:26 | Lynx_ | linuxstb: depending on the show maybe silence detection would work somehow... |
| 16:58:36 | preglow | very few shows have silence |
| 16:58:42 | preglow | depends on the channel, probably |
| 16:59:02 | Lynx_ | preglow: and classic music channel have too much silence, probably ;) |
| 17:00 |
| 17:00:31 | Lynx_ | yawn, reading 6 gb textfiles into mysql takes longer than i thought... |
| 17:02:15 | * | linuxstb wonders why the .wav format has 16-bits to store the number of channels... |
| 17:03:17 | | Join Tang [0] (~chatzilla@ARennes-204-1-25-223.w217-128.abo.wanadoo.fr) |
| 17:03:27 | Tang | Hello :) |
| 17:03:40 | preglow | i wonder more why they store 8 bit samples as unsigned numbers and 16 bit samples as unsigned numbers |
| 17:03:42 | Lynx_ | hi |
| 17:03:43 | preglow | hi |
| 17:03:54 | muesli|tarn | hi tang |
| 17:04:03 | Tang | Hi Museli |
| 17:04:05 | Tang | :) |
| 17:04:06 | | Nick muesli|tarn is now known as muesli_ (muesli_tv@D2cfa.d.pppool.de) |
| 17:04:06 | linuxstb | evening all. |
| 17:04:11 | Tang | Sorry Muesli |
| 17:04:25 | Tang | Good evening linuxstb |
| 17:04:26 | muesli_ | for what? |
| 17:04:27 | Tang | :) |
| 17:04:34 | Tang | i've watched the codec part |
| 17:04:53 | Tang | cool you 've seen the last corrections by HA members |
| 17:05:04 | Tang | (for libFLAC specially) |
| 17:06:23 | linuxstb | Tang: Yes, libmad and libFLAC are now working (but outside the non-existent new Rockbox audio system) |
| 17:06:54 | Tang | Ah okay linux |
| 17:07:06 | Tang | i didn't know that they were ported yet |
| 17:07:07 | Tang | bravo |
| 17:07:43 | preglow | linuxstb: as for tremor, btw, you don't think we'd need the lowmem branch? |
| 17:07:52 | Tang | i'm gonna relay the info on my usual boards |
| 17:07:53 | Tang | :) |
| 17:08:21 | preglow | Tang: just make it clear we're not making sound yet, please |
| 17:08:26 | preglow | only wav writing |
| 17:08:32 | linuxstb | preglow: I've only very briefly looked at Tremor, I haven't started coding yet. Where would I find the lowmem branch? |
| 17:08:40 | Tang | yes no matter i've well understood |
| 17:08:43 | preglow | linuxstb: it's in cvs, but i don't think we'll need that |
| 17:08:56 | Tang | and i'm not guy who make false hope |
| 17:08:58 | preglow | linuxstb: it trades off memory requirements for cpu |
| 17:08:59 | Tang | don't worry |
| 17:09:01 | Tang | :) |
| 17:09:03 | linuxstb | preglow: Actually jsut raw PCM writing, I'm adding WAV headers as we speak. |
| 17:09:31 | * | rasher sets out putting together a wiki page with links interesting for blind users |
| 17:09:33 | preglow | linuxstb: remember to swap the endianess :P |
| 17:10:04 | linuxstb | preglow: Yep! |
| 17:10:41 | preglow | aiff writer would be neat as well |
| 17:11:04 | preglow | http://www.dspdimension.com/html/miniaiff.html |
| 17:11:37 | linuxstb | preglow: I'm not going to worry about AIFF yet, this is just for my own testing. In the long term, we should probably add AIFF support to Rockbox though - add it to the Codecs page. |
| 17:11:42 | | Join webguest58 [0] (~534e073f@labb.contactor.se) |
| 17:12:28 | preglow | no, just meant you might as well see if that lib's usable, if you haven't gotten too far in the wav stuff |
| 17:12:59 | sneakums | i found a lowmem tremor branch in xiph's svn |
| 17:13:01 | preglow | it uses f* file class :PP |
| 17:13:03 | preglow | calls |
| 17:13:07 | sneakums | http://svn.xiph.org/branches/lowmem-branch/Tremor/ |
| 17:13:27 | sneakums | the changelog doesn't say much though |
| 17:13:34 | linuxstb | sneakums: Thanks, I'll look at then when I start work on Tremor. |
| 17:13:39 | preglow | i haven't been able to find much info |
| 17:13:55 | preglow | though i did read a nice post recently, i'll see if i can find it |
| 17:14:03 | sneakums | the trunk remor has the same changelog |
| 17:14:14 | preglow | http://lists.xiph.org/pipermail/tremor/2005-February/001161.html |
| 17:14:15 | sneakums | guess you'd need to have a look at the commit history with xvn |
| 17:14:33 | linuxstb | preglow: Writing WAV is trivial, it's reliably reading them that can get difficult. |
| 17:15:14 | preglow | linuxstb: i know, i've made about three wav libs |
| 17:15:18 | preglow | one for each hard disk crash |
| 17:15:22 | sneakums | wow, those numbers look pretty decent. |
| 17:15:34 | preglow | sneakums: i agree, i don't think we'll be needing the lowmem branch |
| 17:16:14 | sneakums | they weren't kidding when they said lowmem |
| 17:18:38 | rasher | wow |
| 17:19:31 | Tang | Have you some contact with Xioh guys or any ogg coders? |
| 17:20:39 | linuxstb | Tang: No, there's been no need to yet. |
| 17:20:47 | Tang | okay |
| 17:21:07 | Tang | indeed it 'd very hard |
| 17:21:11 | preglow | i don't expect we'll need it either |
| 17:21:11 | Tang | :s |
| 17:21:47 | Tang | ok that's fine really |
| 17:25:59 | Tang | So i'm gonna correct the comparison chart abut iHP and mail this |
| 17:26:02 | Tang | cheers! |
| 17:28:18 | Tang | (mmm i think about something |
| 17:28:30 | Tang | when working on codec |
| 17:28:47 | Tang | are you working the metadata part in the same time |
| 17:29:17 | Tang | or would it be left for later? |
| 17:30:08 | linuxstb | Tang: I'm thinking about the metadata part at the same time... i.e. I'm not writing any code yet, but I'm sure it will be part of the first real implementation. |
| 17:30:16 | preglow | the metadata functionality would almost certainly have to be separate from the codecs, but i don't know |
| 17:30:25 | preglow | there might be clever ways of handling it |
| 17:30:36 | Tang | in fact i do know some METADAT are "transcodec" |
| 17:30:43 | preglow | Tang: exactly |
| 17:30:44 | Tang | exemple: PA can be used for both |
| 17:30:56 | Tang | MPC,PAEtag for |
| 17:31:05 | Tang | monkeyAudio but also MPC and MP3 |
| 17:31:15 | preglow | yes, and that's why i think they need to be separate |
| 17:31:32 | Tang | okay i was wondering about |
| 17:31:47 | preglow | we know of the issue, so it'll be in our design decision |
| 17:31:48 | Tang | but indeed sperate coding may be suitable |
| 17:32:42 | Tang | okay so if needed later i would search for info about metadata part at HA place |
| 17:35:23 | rasher | I started an index for blind users, but I don't really know where this info is collected, so if anyone could add "CategoryBlindUsers: <description>" to pages with information for blind users, or add links to http://www.rockbox.org/twiki/bin/view/Main/BlindUsersIndex that'd be great |
| 17:40:39 | | Join Hohoman [0] (~inte@hohoman.olf.sgsnet.se) |
| 17:40:39 | | Join xen` [0] (~xen@ADijon-151-1-62-183.w83-196.abo.wanadoo.fr) |
| 17:54:08 | | Join amiconn [0] (jens@pD9F51F7E.dip.t-dialin.net) |
| 17:55:04 | rasher | Evening Hohoman, xen`, amiconn |
| 17:55:31 | | Quit webguest58 ("CGI:IRC") |
| 18:00 |
| 18:04:33 | xen` | hi |
| 18:06:35 | Hohoman | good evening |
| 18:09:48 | | Join elinenbe_ [0] (elinenbe_@207-237-225-9.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 18:09:49 | | Quit elinenbe (Read error: 54 (Connection reset by peer)) |
| 18:09:52 | | Nick elinenbe_ is now known as elinenbe (elinenbe_@207-237-225-9.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 18:21:49 | linuxstb | Not sure if this is considered a bug, but I created a .wav file from my libFLAC plugin, and the 8.3 MS-DOS filename Rockbox gave it was "FLACTEST.A4L", and not "FLACTEST.WAV", as requested. |
| 18:22:28 | linuxstb | The iRiver then refused to recognise it as a WAV file - even though the long name is "flactest.wav" |
| 18:22:30 | rasher | that sounds very strange |
| 18:22:56 | | Join XShocK [0] (~XShocK@pcp09492659pcs.nrockv01.md.comcast.net) |
| 18:23:07 | amiconn | linuxstb: That's expected rockbox behaviour |
| 18:23:22 | amiconn | The 8.3 extension is generated randomly |
| 18:23:40 | HCl | why? |
| 18:23:57 | amiconn | Easier handling of duplicate shortnames |
| 18:24:07 | linuxstb | It looks like the iriver firmware ignores the long names when checking for filetypes, and just uses the short name. Hence .flac support can't happen :-) |
| 18:24:25 | HCl | hrm. |
| 18:24:57 | HCl | amiconn: how about only doing that when flactest.wav already exists? |
| 18:25:29 | HCl | sounds more sensible to me... |
| 18:27:01 | linuxstb | It could cause problems if people want to switch between Rockbox and the original firmware (heretics!) |
| 18:33:52 | linuxstb | Looking at the code in fat.c, it already checks if the proposed short name is used, and if so, changes the extension to something random and then retries. So I think the only necessary change would be to make "create_dos_name" more intelligent. |
| 18:35:58 | linuxstb | We could also change the "retry" logic to randomise the last three characters of the main part of the name, and leave the extension as it is. |
| 18:37:45 | | Quit toolmanwv (Read error: 104 (Connection reset by peer)) |
| 18:38:02 | preglow | i think that's a better idea |
| 18:38:04 | | Join toolmanwv [0] (~aaa@pool-70-18-122-238.buff.east.verizon.net) |
| 18:39:42 | rasher | doesn't windows do it by adding ~X to the main name? |
| 18:39:46 | rasher | where X is a number |
| 18:40:09 | preglow | yes |
| 18:40:20 | rasher | Why not use that strategy? |
| 18:41:55 | | Join Nuxator [0] (~chatzilla@abo-131-236-68.guy.modulonet.fr) |
| 18:42:57 | Nuxator | hi |
| 18:43:33 | linuxstb | evenin' |
| 18:44:20 | Nuxator | i just made a google search on coldfire mp3 |
| 18:44:24 | Nuxator | and found http://www.freescale.com/webapp/sps/download/mod_download.jsp?colCode=CFMP3DECAUDSW&prodCode=MCF5249L&nodeId=016246PCbf00M9&location=psp |
| 18:44:39 | Nuxator | it's an coldfire mp3 decoder |
| 18:45:18 | preglow | we can't use that |
| 18:45:27 | preglow | you have to bloody jump through hoops to get it |
| 18:45:34 | preglow | and once you have it, there are licensing restrictionms |
| 18:45:38 | Nuxator | SOFTWARE - MP3 Decoder – Using the MCF5249 feature set, the advanced MP3 decoder is engineered to require only 37 kB of memory and 19 MHz. The decoder can run from on-chip memory and is designed to require fewer CPU cycles than typical decoders. In turn, this design helps to provide longer product battery life for consumers. |
| 18:45:39 | sneakums | and libmad is ported and working anyway, thanks to linuxstb |
| 18:45:50 | preglow | Nuxator: we know of this |
| 18:45:56 | Nuxator | ok sorry |
| 18:46:01 | preglow | no need to apologize |
| 18:46:05 | preglow | but we can't use it |
| 18:46:11 | Nuxator | but wow only 19mhz to decode mp3 |
| 18:46:21 | preglow | yup, it's a very fast decoder |
| 18:46:32 | muesli_ | how many mhz does irivers cpu have? |
| 18:46:39 | Nuxator | 140 max |
| 18:46:45 | Sucka | wosh |
| 18:46:47 | Sucka | *woah |
| 18:46:52 | Nuxator | but it rns at 10 by now |
| 18:46:53 | muesli_ | wow |
| 18:47:09 | amiconn | Nuxator: This is just a question of the implementation & dsp features in the cpu |
| 18:47:17 | linuxstb | Has anyone read the license? Unless I've missed something obvious, we have the right to use it and redistrbute it in source and binary form. |
| 18:47:49 | preglow | linuxstb: then i propose someone be our "contact person" and get us this thing so i can study it :) |
| 18:47:50 | muesli_ | how much are normally those fees? |
| 18:48:02 | amiconn | The hw codec used in the archos (which is a dsp after all) runs at only ~18 MHz - and it is able to *encode* mp3 in realtime |
| 18:48:34 | rasher | It doesn't matter if the fee is $0, the point is that there are licensing restrictions that don't go well with the GPL |
| 18:48:46 | linuxstb | rasher: For example? |
| 18:48:53 | muesli_ | gpl? |
| 18:49:09 | rasher | linuxstb: oh.. :\ I haven't actually *read* the license :) |
| 18:49:15 | amiconn | Bagder: r u around? |
| 18:49:49 | linuxstb | I'm sure it isn't GPL compatible (that would be too good to be true), but I can't immediately see why not. |
| 18:49:56 | preglow | rasher: it actually allows you to change and redistribute the source |
| 18:50:09 | sneakums | the revocation clause is an additional restriction, i think |
| 18:50:15 | preglow | but it's not gpl compatible, no |
| 18:50:32 | preglow | but still, i'd love to study it |
| 18:50:53 | Nuxator | they are talking about a emac unit in coldfire wigh help decode algrithms |
| 18:50:55 | rasher | then you're in the horrible gray-zone area of derived works |
| 18:51:22 | sneakums | the emac is being investigated, i believe |
| 18:51:25 | preglow | rasher: if they allow redistribtion of their changed source anyway, i don't really think they care |
| 18:51:28 | linuxstb | I'm sure for legal reasons no-one involved in Rockbox should even download it unless we're sure about the license.. |
| 18:51:45 | preglow | it's in their best interest that this source gets studied |
| 18:52:02 | rasher | Maybe someone could ask them about it somehow |
| 18:52:14 | rasher | but extreme caution should be taken |
| 18:52:26 | sneakums | no sudden moves |
| 18:52:29 | preglow | worst case, the person that touches it should just not develop the mp3 part |
| 18:52:34 | linuxstb | rasher: Yes - that seems sensible. Ask if the code could be used in a GPL'd project. |
| 18:52:48 | preglow | linuxstb: i don't think motorola cares, the gpl people cares |
| 18:53:28 | rasher | Maybe someone could even ask about them releasing it as gpl |
| 18:53:30 | Tang | can't help this time sorry |
| 18:53:33 | sneakums | the indemnity clause also looks problematic |
| 18:53:38 | Tang | :/ |
| 18:53:43 | preglow | motorola will not gpl it |
| 18:53:48 | preglow | that's pretty certain |
| 18:53:58 | rasher | yeah |
| 18:54:00 | preglow | but hey, let's screw this for now |
| 18:54:01 | preglow | we've got mad |
| 18:54:06 | rasher | yes |
| 18:54:10 | preglow | i'd like layer 1 and 2 support anyway |
| 18:54:12 | muesli_ | dudes, what is a gpl ? :-) |
| 18:54:25 | preglow | muesli_: a software license |
| 18:54:26 | linuxstb | preglow: Motorola could license it to Rockbox under the GPL, but still keep their current license for other users. |
| 18:54:26 | rasher | let's see how much damage it does to battery life |
| 18:54:27 | sneakums | muesli_: the gnu general public licence |
| 18:54:34 | Sucka | how much processor power does MAD use? |
| 18:54:34 | amiconn | preglow: I don't care about layer 1, but layer 2 is also important for me |
| 18:54:35 | *** | Saving seen data "./dancer.seen" |
| 18:54:45 | sneakums | well, other users could then just get it from rockbox |
| 18:54:50 | sneakums | so they might not go for that |
| 18:54:50 | rasher | what sneakums said |
| 18:55:07 | linuxstb | Yes, we have to use MAD for layer 2, but if a better Layer 3 decoder can be found, we should use it. |
| 18:55:14 | sneakums | once you gpl something it can be redistributed indefinitely |
| 18:55:16 | preglow | well, if this is interesting, someone should mail them |
| 18:55:18 | preglow | simple as that |
| 18:55:30 | linuxstb | sneakums: But what are Motorola losing? They already give it away for free. |
| 18:55:38 | preglow | personally, the only thing i want from it is to see how they utilse emac instructions |
| 18:55:45 | sneakums | i'm not saying they win or lose anything |
| 18:56:00 | sneakums | i'm just saying it doesn't make sense to gpl something for only a subset |
| 18:56:07 | Nuxator | ooops i didn't expect to make people arging |
| 18:56:18 | sneakums | this is a discussion |
| 18:56:23 | Nuxator | ^^ |
| 18:56:23 | | Quit toolmanwv ("—I-n-v-i-s-i-o-n— 2.0 Build 3515") |
| 18:56:30 | ze | sneakums: there's plenty of dual-license stuff |
| 18:56:37 | rasher | What, I came here for an argument! |
| 18:56:41 | ze | like reiserfs |
| 18:56:43 | preglow | so, anyone willing to mail them? :P |
| 18:56:53 | linuxstb | rasher: No you didn't. |
| 18:56:54 | sneakums | true, but in that case you decide yourself which licence to use |
| 18:56:57 | Tang | You want someone exterior to rbx? |
| 18:56:57 | rasher | this should probably be a non-developer as well |
| 18:57:10 | rasher | just to be on the safe side |
| 18:57:16 | amiconn | If motorola releases it as gpl, it can only be used in open source projects (or they dual-license it) |
| 18:57:17 | rasher | linuxstb: Yes I did. |
| 18:57:23 | linuxstb | rasher: No you didn't. |
| 18:57:31 | rasher | etc. |
| 18:57:34 | preglow | ok, now it's an argument! |
| 18:57:39 | Tang | i do'nt mind doing |
| 18:57:47 | rasher | preglow: No it isn't! |
| 18:57:53 | preglow | hahah |
| 18:57:56 | * | linuxstb must stop that, it's silly. |
| 18:58:01 | Tang | but i think it'd be betetr someone who speak english better |
| 18:58:12 | Tang | toa voide misunderstanding |
| 18:58:14 | * | rasher nominates sneakums |
| 18:58:18 | preglow | go sneakums! |
| 18:58:20 | rasher | Just Because. |
| 18:58:30 | linuxstb | Let's wait and see what others (Bagder?) think iof it. |
| 18:58:56 | Tang | (question: will the ragument figure in the IRC log? :lol: ) |
| 18:59:17 | rasher | It certainly will |
| 18:59:31 | Tang | :D |
| 18:59:32 | amiconn | rasher: Iirc you run linux? |
| 18:59:41 | rasher | amiconn: absolutely |
| 18:59:45 | | Part GnagelRam |
| 19:00 |
| 19:00:14 | amiconn | Could you perhaps test my X11 hacks for me, as I can only test on cygwin? |
| 19:00:24 | rasher | Sure |
| 19:00:31 | rasher | send a patch or directions my way |
| 19:00:53 | amiconn | This is not yet the full rewrite of the X11 sim kb handling, it's a proof of concept |
| 19:01:07 | amiconn | One sec, generating patch... |
| 19:03:28 | amiconn | This applies to 3 files in /uisimulator |
| 19:03:53 | amiconn | After applying, build an X11 sim (preferably Ondio, but it shouldn't matter) |
| 19:04:15 | amiconn | Then start this sim, press some keys and watch the console output |
| 19:04:25 | rasher | okay, checking |
| 19:04:47 | amiconn | Two things should happen if things work as intended: |
| 19:05:02 | amiconn | (1) Keyboard repeat should be off |
| 19:05:20 | rasher | uh oh |
| 19:05:21 | amiconn | (2) The tick value printed should increase |
| 19:05:23 | rasher | didn't build |
| 19:05:33 | rasher | ../x11/screenhack.c: In function `main': |
| 19:05:33 | rasher | ../x11/screenhack.c:588: warning: implicit declaration of function `signal' |
| 19:05:33 | rasher | ../x11/screenhack.c:588: error: `SIGALRM' undeclared (first use in this function) |
| 19:05:48 | amiconn | Urgs... missing #include |
| 19:05:56 | amiconn | Strangely cygwin doesn't care |
| 19:06:47 | rasher | cygwin lacks discipline |
| 19:07:17 | amiconn | Please add #include <sys/time.h> somewhere at the top of /uisimulator/x11/screenhack.c and retry |
| 19:07:23 | | Join hubble [0] (hubble@h13n1fls302o1033.telia.com) |
| 19:07:37 | Nuxator | I found a pll wizard may help linusN with setting coldfire speed http://www.freescale.com/files/netcomm/software_tools/initialization/boot_code_generation/CFPLLCFG.zip |
| 19:07:52 | Nuxator | No registration needed for this one |
| 19:08:02 | rasher | haha, it's based on xscreensaver hacks? |
| 19:08:03 | Bagder | #include <signal.h> for signal() |
| 19:08:11 | Bagder | rasher: yeps |
| 19:08:17 | rasher | Amusing |
| 19:08:23 | * | amiconn notices bagder around |
| 19:08:29 | Bagder | I'm not really here |
| 19:08:33 | hubble | I've got the iRiver audio chip to initialize, mute and demute and it works =) |
| 19:08:45 | rasher | w00t |
| 19:08:48 | sneakums | ! |
| 19:09:03 | Nuxator | clwow |
| 19:09:06 | Bagder | cool progress hubble |
| 19:09:32 | amiconn | rasher: I think both includes are necessary |
| 19:09:35 | Bagder | jyp: you working on fixing the builds? |
| 19:09:36 | hubble | next is trying to write a sin-wave and see if I can get any sound out of it =) |
| 19:09:48 | rasher | amiconn: I added them both, it compiles |
| 19:10:25 | preglow | hubble: cool |
| 19:10:32 | preglow | hubble: that's all i2c, yes? |
| 19:10:46 | hubble | hehe.. it took some time reading the documentation, reversing the original firmware and getting it to work.. |
| 19:10:53 | hubble | preglow: yes |
| 19:11:03 | preglow | hubble: easier to write a sawtooth, heh, no sin() on 5249 |
| 19:11:21 | hubble | preglow: precalc table |
| 19:11:24 | amiconn | Bagder, jyp: There is an 'e' at the very start of thread.c |
| 19:11:30 | preglow | saw requires no table :P |
| 19:11:33 | | Quit thegeek (Read error: 104 (Connection reset by peer)) |
| 19:11:36 | rasher | preglow: I get a keypress at the beginning, nothing in between |
| 19:11:38 | rasher | oops |
| 19:11:45 | rasher | amiconn: I get a keypress at the beginning, nothing in between |
| 19:11:57 | rasher | amiconn: the tick count is larger at the end |
| 19:11:58 | amiconn | Do you get the release as well? |
| 19:12:01 | rasher | yes |
| 19:12:12 | amiconn | Nice, so this is working.... |
| 19:12:29 | rasher | it didn't bring up the menu, but I'm guessing it's not tied into the sim yet? |
| 19:12:30 | amiconn | I can go ahead reimplementing the keyboard handling based on that |
| 19:12:48 | preglow | hubble: so you're porting i2c.c as well? |
| 19:12:52 | amiconn | rasher: No, as I said, I merely wanted to know if it works on real X |
| 19:13:19 | rasher | amiconn: alright, that's fine then :) |
| 19:13:22 | amiconn | The timing of the X11 sim wil become much more similar to the target... |
| 19:13:29 | rasher | Great |
| 19:13:52 | hubble | preglow: not really, iriver has i2c interface in hw.. you basicly just write byte's to the CPU and it will take care of the bit-fiddeling etc |
| 19:14:01 | amiconn | Bagder: What I wanted to ask - I need a place where to put the timer routine, but I'm undecided in which file it should go |
| 19:15:16 | amiconn | The Win32 sim timing is handled in uisw32.c, so the equivalent would be uibasic.c |
| 19:15:29 | preglow | hubble: but yes, so you think you have i2s going as well? |
| 19:15:44 | amiconn | However, the Win32 sim doesn't use a separate routine, but the timer is part of the overall event loop |
| 19:15:55 | hubble | preglow: i hope so.. going to try that tonight |
| 19:16:19 | preglow | i can write you sin generation code in a jiffy |
| 19:16:39 | Bagder | amiconn: I don't have any strong opinion |
| 19:17:11 | linuxstb | Is www.rockbox.org down at the moment, or is it just me? I can ping it, but get nothing via http |
| 19:17:32 | rasher | Works For Me. |
| 19:17:34 | rasher | [tm] |
| 19:17:39 | linuxstb | Yes, and it's now working for me too. |
| 19:17:51 | * | Bagder is away again |
| 19:18:23 | amiconn | rasher: Not ® ? |
| 19:18:50 | rasher | That too, I guess. |
| 19:27:06 | | Join Stryke` [0] (~Chairman8@resnet-241-86.resnet.UMBC.EDU) |
| 19:28:03 | | Join webguest17 [0] (~44615070@labb.contactor.se) |
| 19:28:35 | | Quit webguest17 (Client Quit) |
| 19:28:44 | | Join nrjazz12 [0] (~44615070@labb.contactor.se) |
| 19:29:20 | nrjazz12 | hello |
| 19:30:18 | | Quit nrjazz12 (Client Quit) |
| 19:30:58 | | Quit Nuxator ("Chatzilla 0.9.67 [Firefox 1.0/20041108]") |
| 19:34:50 | Lynx_ | see you guys, i'm going hooome |
| 19:35:11 | | Nick Lynx_ is now known as Lynx_awy (HydraIRC@134.95.189.59) |
| 19:40:46 | linuxstb | Probably only Linus can answer this, but could the start_iriver_fw() function from bootloader/main.c be copied into Rockbox and then used to start the original firmware without needing to reboot? |
| 19:43:04 | preglow | probably, depends on how much the iriver firmware depends on the hardware state |
| 19:44:06 | amiconn | Something like RoLo on the archos units... |
| 19:46:02 | linuxstb | Would anyone else find that useful? |
| 19:46:39 | sneakums | personally, i hope to never have to use the iriver firmware again |
| 19:47:00 | | Part amiconn |
| 19:47:38 | rasher | maybe if we don't get mp3 recording/encoding going quickyl |
| 19:48:10 | Tang | or the tuner |
| 19:48:24 | linuxstb | or WMA playback |
| 19:48:30 | sneakums | none of which i use ^_^ |
| 19:48:36 | rasher | sneakums: how deviant |
| 19:48:41 | sneakums | thanks. |
| 19:48:48 | Tang | Someone can tell me the CPU complete name and his real speed for an HA memeber? |
| 19:48:57 | Tang | :) |
| 19:49:13 | | Join Patr3ck [0] (~patr3ck@pD9E5CDED.dip.t-dialin.net) |
| 19:49:34 | sneakums | CPU: Motorola SCF5249 140MHz coldfire |
| 19:49:39 | sneakums | or so says http://www.rockbox.org/twiki/bin/view/Main/IriverInfo |
| 19:49:42 | Tang | thanks :) |
| 19:49:54 | Tang | i'll give the info and the link |
| 19:49:55 | Tang | :) |
| 19:49:58 | Tang | thanks |
| 19:50:09 | preglow | Tang: they're welcome in the channel to ask themselves, seems kind of laborious to have to go through a board all the time |
| 19:50:27 | Sucka | whats HA? |
| 19:50:34 | rasher | hydrogenaudio |
| 19:50:39 | Tang | yes indeed i'll send a link to the channel do you know the syntax for an IRC link in BBcode? |
| 19:50:50 | preglow | no |
| 19:50:58 | preglow | just say #rockbox on irc.freenode.net |
| 19:51:01 | preglow | that should do it |
| 19:51:05 | Sucka | irc://net/channel |
| 19:51:07 | Sucka | just as a url |
| 19:51:17 | linuxstb | Or link to the IRC page on the Rockbox site - there's an archive there as well. |
| 19:51:41 | linuxstb | http://www.rockbox.org/irc/ |
| 19:52:21 | Tang | okay will use the IRC page access |
| 19:55:49 | jyp | Oops, I needed to go afk before the build finished |
| 19:55:57 | jyp | fixed. |
| 20:00 |
| 20:02:31 | | Nick StrathAFK is now known as Strath (~mike@dgvlwinas01pool0-a212.wi.tds.net) |
| 20:04:08 | Tang | NB: of course you can register and login at HA board too :) |
| 20:11:05 | | Quit Patr3ck () |
| 20:12:24 | | Join JeanLuc [0] (~51ada8c3@labb.contactor.se) |
| 20:17:41 | | Part JeanLuc |
| 20:20:16 | linuxstb | If anyone is interested in testing my libmad and libFLAC plugins, a rockbox.zip file is here: linuxstb.org/rockbox.zip">http://linuxstb.org/rockbox.zip |
| 20:21:17 | linuxstb | I'm preparing a source zip file now - I've made a few changes in various places in Rockbox, so I'll just upload the whole of the apps, firmware and uisimulator directories (they work in the X11 sim, but I haven't modified the Makefile(s) for win32). |
| 20:24:46 | xen` | linuxstb: its approx the final codec api format ? |
| 20:25:11 | hubble | just have to love the MCF5249 manual.. there are typos everywhere =) |
| 20:25:25 | xen` | and I would just have to do the same way in case I want to do another codec ? |
| 20:25:27 | linuxstb | xen`: No, it's just my test programs. There isn't really any API format at the moment. |
| 20:25:31 | xen` | oki |
| 20:27:48 | linuxstb | I've implemented them as "viewer" plugins that convert the selected file to WAV - "/flactest.wav" or "/madtest.wav" respectively. You can then reboot and play that WAV in the iRiver firmware. |
| 20:28:46 | linuxstb | Source: linuxstb.org/rockbox-codecs-source.tgz">http://linuxstb.org/rockbox-codecs-source.tgz |
| 20:29:37 | hubble | how is the mp3 player performing? realtime? |
| 20:29:45 | linuxstb | lol. |
| 20:29:49 | hubble | :) |
| 20:30:09 | | Join ep0ch [0] (HydraIRC@195.112.43.225) |
| 20:30:12 | linuxstb | libmad is currently running at about 3.8% of real-time. libFLAC is about 8% |
| 20:30:36 | hubble | doh! :) |
| 20:30:42 | linuxstb | But we don't know how big the problem will be until Linus fixes the CPU speed. |
| 20:31:20 | linuxstb | I may also have made mistakes with my implementations - so if people could seriously look at my code, it could help. |
| 20:31:43 | linuxstb | Especially the build commands (compiler flags, -D options etc). |
| 20:33:30 | izzy | I'll try to find some time to look at them |
| 20:34:48 | | Join mrelwood [0] (~54e68d2f@labb.contactor.se) |
| 20:34:57 | | Quit mrelwood (Client Quit) |
| 20:35:29 | | Join mrelwood [0] (~54e68d2f@labb.contactor.se) |
| 20:37:01 | | Quit methangas (" HydraIRC -> http://www.hydrairc.com <- IRC for those that like to be different") |
| 20:39:05 | mrelwood | since the rockbox for iriver is still on hold, have you guys found a suitable replacement for a md-recorder? amongst mp3-players that is. |
| 20:39:23 | sneakums | it's not hold |
| 20:39:26 | sneakums | work is ongoing |
| 20:41:45 | coob | mrelwood: wouldn't any mp3 player with recording abilities suit your needs? |
| 20:46:09 | Tang | The iHP1xx seems suitable it can record yet and will do better with rbx |
| 20:46:21 | Tang | but hard to find an iHP1xx now |
| 20:46:32 | preglow | mrelwood: what makes you think it's on hold? things have never gone quicker than right now |
| 20:47:41 | hubble | how good are the archoses recording quality? v2 recorder? ondio? |
| 20:49:28 | linuxstb | hubble: I don't know about the quality of the ADC, but the v2 recorder (and others with the MAS chip) can only record at a maximum quality of about 175kbps VBR MP3 |
| 20:51:35 | hubble | linuxstb: ok.. I was thinking on getting one just to record some voice.. Is the build-in mic useful? I know my H120 gets interference from the HDD if I use the internal mic.. |
| 20:52:19 | Tang | it's not interfernce |
| 20:52:36 | Tang | it's just that the int mic record the HDD activity sound |
| 20:52:42 | Tang | cause tey are too near |
| 20:52:44 | Tang | ;) |
| 20:52:56 | Tang | no electrical or magnetic phenomenon |
| 20:53:14 | hubble | Tang: ok :), does the archoes have the same problem? |
| 20:53:16 | linuxstb | More info on the Archos: http://www.rockbox.org/twiki/bin/view/Main/GeneralFAQ#Q78_How_do_I_control_the_recordi |
| 20:53:48 | linuxstb | (yes, the link does end with "cordi") |
| 20:54:04 | Quelsaruk | hubble: the archos has the same problem with the internal mic |
| 20:54:32 | hubble | Quelsaruk: ok |
| 20:54:37 | *** | Saving seen data "./dancer.seen" |
| 20:54:44 | linuxstb | There is a 140kbps VBR mono mode, which should be more than good enough for voice. |
| 20:55:42 | mrelwood | coob, i need atleast md-quality, so 320kbps |
| 20:56:10 | mrelwood | ...is the least i would accept |
| 20:56:15 | coob | er |
| 20:56:42 | coob | well will plain uncompressed recording do you? |
| 20:56:46 | | Nick Quelsaruk is now known as Quel|out (~kvirc@80.103.129.193) |
| 20:58:48 | linuxstb | I think the Nomad Jukebox 3 is gaining respect from DAT tapers for uncompressed WAV recording. |
| 21:00 |
| 21:02:23 | Tang | at linuxstb: |
| 21:02:25 | Tang | indeed |
| 21:02:49 | Tang | nomad are very famous in this domain |
| 21:03:38 | preglow | i hate this fucking emac shit |
| 21:03:38 | preglow | argh |
| 21:05:49 | rasher | the nomad jukebox looks like a fucking joke though |
| 21:07:03 | linuxstb | And I don't think it's acts as a USB mass-storage device - so you need Nomad's software to access it. I think that's what stopped me from buying one. |
| 21:07:36 | linuxstb | That, and the news that Rockbox was in the early stages of a port. |
| 21:08:52 | coob | heh and the archos recorder doesn't :P ugggly :) |
| 21:09:23 | | Join toufn [0] (~normandc@lns-vlq-3-str-82-64-202-245.adsl.proxad.net) |
| 21:12:44 | | Join Aison [0] (~hans@zux166-181.adsl.green.ch) |
| 21:14:31 | preglow | does anyone know of any other coldfire disassemblers? |
| 21:15:04 | | Join methangas [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk) |
| 21:15:39 | hubble | mrelwood: md quality? isn't atrax3(?) compression pretty pad? |
| 21:17:22 | hubble | preglow: i'm using IDA (old version).. it isn't lovely but it works.. have to go through and manually tell it like.. this is code, disassemble please.. |
| 21:17:48 | preglow | but swell, i have ida |
| 21:17:51 | preglow | didn't think of that |
| 21:17:59 | hubble | preglow: but it's great because it's support for cross-references, commenting, etc etc :) |
| 21:18:31 | hubble | preglow: i can send you my database of the original firmware so you get a jump-start |
| 21:21:01 | Tang | i didn't say i like the Nomad |
| 21:21:11 | Tang | but it's recognied for recodrding usage |
| 21:21:44 | preglow | i USED to have ida pro |
| 21:21:54 | * | preglow pats his crashed hard disk |
| 21:24:02 | hubble | preglow: oh :( |
| 21:26:28 | hubble | WOWA! |
| 21:26:37 | hubble | saw-tand working! |
| 21:26:51 | hubble | magic :) |
| 21:27:28 | preglow | you get sound???? |
| 21:27:53 | hubble | yep |
| 21:27:57 | preglow | goddamn, man |
| 21:28:01 | preglow | commit this as fast as you can! |
| 21:28:15 | | Join rjamorim [0] (rjamorim@200-140-251-189.cscgo203.dial.brasiltelecom.net.br) |
| 21:28:26 | rjamorim | OMG hello Tang :) |
| 21:28:36 | hubble | i dont have write access to cvs but i'm definitely going to continue with this.. very fun |
| 21:28:40 | Tang | Hello Roberto |
| 21:28:41 | Tang | :) |
| 21:28:59 | Tang | i presnet you to the Rbx team, |
| 21:29:08 | rjamorim | Greets! |
| 21:29:15 | Tang | it's Roberto Amorim from HA |
| 21:29:25 | Tang | (admi of rareware.org) |
| 21:29:31 | Tang | :) |
| 21:29:36 | preglow | woot |
| 21:29:39 | preglow | how timely |
| 21:29:39 | rjamorim | The CPU you mentioned is more than enough to decode and encode WavPack in real time, even at high mode |
| 21:29:44 | rjamorim | rarewareS.org, dude :) |
| 21:29:45 | preglow | we just made our first sound with rockbox |
| 21:29:49 | rjamorim | hehe |
| 21:29:51 | Tang | oups sorry |
| 21:29:55 | rjamorim | oh, my |
| 21:29:58 | Tang | (of course mùore than one rareware ;)) |
| 21:30:09 | rjamorim | heh, true |
| 21:30:59 | Tang | in fact LinusM is not here now |
| 21:31:10 | Tang | he's the HW specialist here |
| 21:31:19 | rjamorim | Oh, too bad |
| 21:31:23 | Tang | (he has released the bootloader) |
| 21:31:30 | rjamorim | I was going to ask if Coldfire is ARM based or 68K based |
| 21:31:44 | preglow | 68k |
| 21:31:46 | Tang | not ARM |
| 21:31:48 | preglow | with dsp extensions |
| 21:31:51 | Tang | 68k |
| 21:31:53 | Tang | :) |
| 21:32:01 | Tang | i let you with the specialists |
| 21:32:09 | Tang | Preglow hubble and so on |
| 21:32:10 | rjamorim | I think David has experience with ARM assembly (in case you guys need optimizations), but I don't know if he knows 68K assembly |
| 21:32:14 | rjamorim | Ah, OK |
| 21:32:41 | preglow | 68k assembly is very nice, he'll surely be willing to learn :P |
| 21:33:01 | rjamorim | I wonder why the heck the CPU is so underclocked, and then comes iRiver and whines that some Vorbis bitrates can't be decoded in real time :B |
| 21:33:08 | rjamorim | Haha, ok |
| 21:33:34 | rjamorim | He's working for a DVD controller manufacturer right now. He's very much into embedded stuff |
| 21:33:41 | rjamorim | Used to work for a printer maker before... |
| 21:33:55 | rjamorim | Programmed his printer to play a Bach fugue :S |
| 21:34:17 | preglow | rjamorim: it's software controllable |
| 21:34:29 | preglow | rjamorim: you can clock it however you want by adjusting pll registers |
| 21:34:36 | rjamorim | Hrm.. I see, but why? Battery saving? |
| 21:34:40 | preglow | rjamorim: it's just that linus hasn't had time to find a good working configuration yet |
| 21:34:45 | rjamorim | Ah |
| 21:34:53 | preglow | it will run at full throttle later |
| 21:35:03 | rjamorim | What compiler are you using? Metrowerks? |
| 21:35:05 | rjamorim | excellent |
| 21:35:08 | linuxstb | preglow: or hopefully less than full throttle. |
| 21:35:09 | preglow | gcc |
| 21:35:17 | rjamorim | hrm. Wouldn |
| 21:35:25 | preglow | metrowerks costs money, afaik |
| 21:35:30 | rjamorim | 't matrowerks create more optimized code? |
| 21:35:35 | rjamorim | Ah, good point :B |
| 21:35:39 | preglow | well, probably, but it's not free |
| 21:35:44 | rjamorim | yeah |
| 21:35:47 | preglow | we can't exactly tell people to pirate software if they want to develop |
| 21:35:50 | preglow | and gcc is pretty goox |
| 21:35:51 | preglow | good |
| 21:35:53 | linuxstb | Everything about Rockbox is open source - including the build tools. |
| 21:36:03 | preglow | the code it generates is pretty tight |
| 21:36:22 | preglow | 68k is a very old target for it, so has had time to mature |
| 21:36:38 | rjamorim | Ah, indeed. |
| 21:36:40 | rjamorim | That's great |
| 21:36:57 | sneakums | i think one of the first machines the gnu project had was a 68000 box |
| 21:42:34 | rjamorim | Tang: http://www.hydrogenaudio.org/forums/index.php?showtopic=27390&view=findpost&p=273224 |
| 21:44:17 | preglow | i wish to god i could make this emac unit work |
| 21:44:36 | rasher | hrm, the GPL, LGPL and BSD isn't a problem |
| 21:44:43 | preglow | using that lib is pretty much out of the question any way you look at it |
| 21:44:56 | preglow | motorola would have to release it as gpl |
| 21:44:59 | preglow | and that they won't do |
| 21:45:08 | rasher | or any other gpl compatible license |
| 21:45:21 | preglow | yes, bet they won't do that either, heh |
| 21:45:31 | rjamorim | Yes. Pretty much unlikely :B |
| 21:45:36 | rjamorim | Better focus on MAD |
| 21:46:19 | rasher | Dear Motorola, |
| 21:46:27 | rasher | We want your shit. Pick one: http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses |
| 21:46:30 | rasher | Love, |
| 21:46:31 | rasher | rasher |
| 21:46:36 | linuxstb | lol. |
| 21:46:49 | rjamorim | Right away, Mr. rasher |
| 21:46:59 | rjamorim | Thank-you for doing business with us |
| 21:47:03 | rasher | I wonder if it'd be worth the bother |
| 21:47:22 | rjamorim | Probably not |
| 21:47:27 | rjamorim | hehe, they even offer an MP3 encoder |
| 21:47:32 | rjamorim | Now TAHT would be sweet |
| 21:47:35 | linuxstb | rjamorim: Yes, we are focusing on MAD - if by some miracle we can use the Motorola decoder, it would only be for Layer III decoding anyway, and we want Layer II as well. |
| 21:47:42 | rjamorim | Even if quality is bad (as it likely is) |
| 21:47:52 | rjamorim | Ah, good point |
| 21:48:26 | Tang | okay Roberto i've read it |
| 21:50:03 | Tang | Bad quality for mad? |
| 21:50:37 | rjamorim | The MP3 encoder from motorola |
| 21:50:52 | rjamorim | It's full of constraints, so it can't be properly tuned. |
| 21:51:08 | sneakums | what sort of constraints? |
| 21:51:18 | rjamorim | Real time operation at a little more than 100mHz, low battery consumption, no FP values... |
| 21:51:28 | | Quit toufn ("Leaving") |
| 21:51:36 | rjamorim | Mostly RT operation at few CPU power |
| 21:52:03 | Tang | Ah okay |
| 21:53:11 | preglow | you can do quite a lot in 140 mhz |
| 21:53:25 | preglow | no floating point really doesn't restrict you that much, you just have to think more while coding |
| 21:53:30 | | Quit methangas (" HydraIRC -> http://www.hydrairc.com <- IRC with a difference") |
| 21:55:10 | rjamorim | Haha, yeah, but MP3 encoding at high quality would require more horse power than 140mHz, even with heavy ASM optimizations. |
| 21:55:40 | preglow | well, yes, if you want lame |
| 21:55:47 | preglow | but you can probably do pretty good stuff still |
| 21:56:21 | rjamorim | yeah, guess so |
| 21:59:59 | izzy | linuxstb: have you tried how much faster your flac decoder works if you don't write the output to a file? |
| 22:00 |
| 22:00:11 | hubble | preglow: why is it a problem to use the binary mp3 lib from motorola? it's almost as the linux kernel (nvidia) thing? as long as rockbox authors (linus?) are fine with it? |
| 22:00:38 | linuxstb | izzy: Yes, that's how it was working yesterday. There's virtually no difference to the % decoding speed. |
| 22:00:43 | izzy | ok |
| 22:01:26 | linuxstb | hubble: I mentioned the same thing this morning. Best to leave that can of worms closed for the moment. |
| 22:01:37 | hubble | linuxstb: ok =) |
| 22:02:47 | preglow | hubble: it's not binary |
| 22:03:18 | preglow | the simplest thing would just have someone ask if it's okay |
| 22:03:21 | preglow | but it's not urgent |
| 22:04:12 | hubble | preglow: aha.. it is only available commersially? |
| 22:05:48 | preglow | hubble: you have to contact them, but yes, it seems they expect you to be commercial, since they ask for phone number for your salesperson and stuff |
| 22:06:31 | | Quit mrelwood ("CGI:IRC (EOF)") |
| 22:06:37 | hubble | preglow: ok.. |
| 22:06:41 | preglow | i don't see why they restrict it like this in the first place |
| 22:06:47 | preglow | but corporations can be pretty stupid |
| 22:07:20 | rasher | They have a lot of people working hard on that |
| 22:07:32 | rjamorim | Damned dial-up. BBL |
| 22:07:35 | preglow | apparently |
| 22:07:35 | | Quit rjamorim ("On the Turning Away...") |
| 22:07:53 | preglow | if they release a lib that does fast mp3s on a coldfire, how the hell can they not benefit from releasing it freely? |
| 22:08:31 | | Quit Cassandra_ (Read error: 60 (Operation timed out)) |
| 22:08:34 | hubble | preglow: they cant decide if their main business is chips or software :) |
| 22:08:51 | rasher | I imagine it's down to concerned lawyers |
| 22:09:12 | | Join mrelwood [0] (~54e68d2f@labb.contactor.se) |
| 22:09:42 | preglow | yes, of coruse |
| 22:09:52 | preglow | lawyers need to be shot more often |
| 22:09:56 | mrelwood | hey, the iRiver port really has proceeded a lot! I guess there is no knowledge if the glitch will be apparent or not? |
| 22:10:07 | preglow | mrelwood: not yet |
| 22:10:16 | hubble | if it's hand optimized asm then it won't be any good for any other (compeditors) platform |
| 22:10:22 | preglow | mrelwood: we've barely gotten audio out to work, no recording yet |
| 22:10:31 | XShocK | hi all |
| 22:10:49 | mrelwood | preglow, well that is really good news! I suppose You are aware of the glitch? |
| 22:10:59 | XShocK | hmm, as i understand some people had gotten sound working somehow? |
| 22:11:25 | | Join Diway [0] (~diway@82.226.26.23) |
| 22:11:58 | | Quit muesli_ (Read error: 54 (Connection reset by peer)) |
| 22:13:05 | | Join muesli_- [0] (muesli_tv@D2cfa.d.pppool.de) |
| 22:13:43 | preglow | mrelwood: yes |
| 22:13:56 | preglow | XShocK: hubble just made sound out work |
| 22:14:19 | | Quit muesli_- (Read error: 104 (Connection reset by peer)) |
| 22:14:47 | XShocK | cool |
| 22:14:55 | | Quit midk ("Leaving") |
| 22:15:09 | | Join Cassandra_ [0] (~christi@213.78.161.214) |
| 22:15:21 | | Join muesli- [0] (muesli_tv@D2cfa.d.pppool.de) |
| 22:15:28 | | Quit muesli- (Read error: 104 (Connection reset by peer)) |
| 22:15:38 | mrelwood | man, I can't wait! I can't stay in my pants! If Rockbox fixes the glitch, it will become the Perfect DAP for me! |
| 22:16:05 | preglow | i think gas is frigging bugging on me here |
| 22:16:14 | preglow | i explicitely tell 'no shifts in multiply', it encodes 'shift left' |
| 22:16:22 | mrelwood | I took it back to the store because of the glitch, and I'm still without a player/recorder. |
| 22:16:37 | preglow | mrelwood: the glitch is really very easily fixable |
| 22:16:43 | | Join muesli_- [0] (muesli_tv@D2cfa.d.pppool.de) |
| 22:16:52 | preglow | mrelwood: just open the file with an audio editor and fix the glitch by hand |
| 22:17:51 | rasher | preglow: so even if it's a hardware problem, it's just a matter of making a "viewer" that fixes that error |
| 22:18:03 | rasher | right? |
| 22:18:14 | mrelwood | well, i'm not ready to do that to all recorded files. besides, the 45 samples are lost anyway, the recorded track is shorter than the original. |
| 22:19:09 | muesli_- | sorry mates..mirc kixxx my butt |
| 22:19:53 | muesli_- | was gayt!? |
| 22:20:03 | | Quit muesli_- (Read error: 54 (Connection reset by peer)) |
| 22:20:22 | preglow | rasher: it can be pretty hard to detect |
| 22:21:13 | rasher | preglow: ah, I don't know much about this glitch.. I don't really use my iRiver for recording |
| 22:21:37 | preglow | rasher: nor do i, but i checked it out once, it just drops a couple of samples from time to time |
| 22:21:53 | preglow | rasher: it probably occurs periodically, so could probably be easy to filter it out |
| 22:21:55 | izzy | linuxstb: what does the loop do in your flac plugin write-callback function? |
| 22:22:02 | rasher | oh, I thought it was periodical.. ah :) |
| 22:22:21 | mrelwood | during my testings it was always 44-45 samples, random interval was 20s - 1min. |
| 22:23:19 | mrelwood | and it had nothing to do with the time when the hd light was blinking, so what I understand it is not a buffer flushing issue after all. |
| 22:23:25 | preglow | hmmm |
| 22:23:45 | preglow | it's pretty hard to say without knowing what the firmware is like internally |
| 22:23:51 | preglow | but we'll find out soon enouygh anyway |
| 22:23:56 | mrelwood | :D |
| 22:23:57 | preglow | i require food |
| 22:24:49 | | Join muesli- [0] (muesli_tv@D2cfa.d.pppool.de) |
| 22:25:03 | | Part jyp ("poof!") |
| 22:25:11 | linuxstb | izzy: It converts from flac's "one array per channel" output to an interleaved stereo buffer. |
| 22:25:13 | mrelwood | I just ate a delicious steak, and brownie with ice-cream. I wish there was something I could do about the fw... |
| 22:28:08 | muesli- | mrelwood r u coming from the states? |
| 22:28:23 | | Join Patr3ck [0] (~patr3ck@pD9548C14.dip.t-dialin.net) |
| 22:28:35 | Patr3ck | /msg NickServ IDENTIFY internet |
| 22:28:48 | rasher | oops |
| 22:28:52 | muesli- | hihi |
| 22:28:52 | Patr3ck | :-) |
| 22:29:21 | mrelwood | muesli, no. Finland. |
| 22:29:30 | muesli- | ah, ok |
| 22:29:54 | muesli- | am just watching a documentary about unhealthy fast food ;) |
| 22:30:21 | mrelwood | "Supersize me"? |
| 22:31:03 | | Join twister [0] (~chatzilla@212.68.227.124.brutele.be) |
| 22:31:14 | muesli- | yeah, something like this |
| 22:31:30 | muesli- | 60% of all americans are overweighted ;) |
| 22:32:16 | | Quit twister (Client Quit) |
| 22:32:48 | mrelwood | well, finns are not that much worse... I heard that we are supposed to be the most american population in Europe! |
| 22:33:01 | mrelwood | worse, I mean better! :D |
| 22:34:35 | muesli- | you can eat as much as you can, but dont forget to move ;-) |
| 22:34:48 | | Join piratePenguin [0] (~piratepen@dialup391.ts527.cwt.esat.net) |
| 22:35:08 | | Join GnagelRam [0] (~chatzilla@gnagelram.olf.sgsnet.se) |
| 22:35:10 | mrelwood | I know. I'm still working on that myself, still recovering from a back surgery. |
| 22:36:07 | muesli- | :-/ hope you make progress |
| 22:36:27 | Tang | Finished my correction of the comparison chart |
| 22:36:31 | Tang | i send you |
| 22:36:33 | Tang | by mail |
| 22:36:44 | Tang | it's in a RTF attached file |
| 22:36:46 | Tang | :) |
| 22:37:07 | muesli- | me too pls ;) |
| 22:37:29 | mrelwood | muesli, slowly but unsurely... :P |
| 22:39:19 | | Quit piratePenguin (Client Quit) |
| 22:41:02 | muesli- | hi tang ;) |
| 22:41:45 | Tang | hhi Muesli |
| 22:43:01 | hubble | hm.. the sinus wave does not sound like a sinus should :) |
| 22:43:15 | muesli- | like a cosinus? ;=) |
| 22:44:33 | Tang | cannot sent the file |
| 22:44:41 | Tang | will retry tomorrow |
| 22:45:23 | | Quit Tang ("Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041108]") |
| 22:51:16 | preglow | hubble: no? |
| 22:51:30 | preglow | hubble: i've got a sine wave routine i know works |
| 22:53:02 | preglow | or is the problem the codec? heh |
| 22:53:28 | hubble | yea, it's probably i2s format or some codec setting |
| 22:53:32 | | Join amiconn [0] (~jens@pD9E7F6F4.dip.t-dialin.net) |
| 22:54:02 | | Quit ep0ch (" HydraIRC -> http://www.hydrairc.com <- Go on, try it!") |
| 22:54:37 | | Join webguest94 [0] (~4241a614@labb.contactor.se) |
| 22:54:40 | *** | Saving seen data "./dancer.seen" |
| 22:55:40 | webguest94 | question..does anyone use Trillian as an IRC client ? I'm trying to access this room via trillian |
| 22:56:26 | * | rasher bites his lip |
| 22:57:46 | | Quit webguest94 (Client Quit) |
| 22:59:03 | | Join webguest07 [0] (~4241a614@labb.contactor.se) |
| 23:00 |
| 23:00:18 | | Quit webguest07 (Client Quit) |
| 23:05:26 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 23:06:24 | mrelwood | Is any of You aware of a mp3 recorder that would record atleast 320kbps from line in with input metering? |
| 23:06:41 | mrelwood | and would be small enough to fit a pocket. |
| 23:06:50 | midk | the irivers do that, don't they? |
| 23:07:33 | hubble | preglow: okey.. now the sinwave is pretty good.. a few plopps because i'm not using interrupts to feed the audio data yet |
| 23:07:34 | rasher | 320kbps mp3 |
| 23:07:51 | midk | iriver does 320, right? |
| 23:07:56 | rasher | yup |
| 23:08:41 | preglow | mrelwood: at least? 320kbps is maximum for mp3 |
| 23:08:54 | preglow | hubble: goodie |
| 23:13:23 | hubble | wonder if it's the "analog mixer volume" or "master mixer volume" you're supposed to use interactively |
| 23:13:55 | | Quit HCl ("Lost terminal") |
| 23:14:34 | | Join hcl [0] (hcl@titania.student.utwente.nl) |
| 23:17:47 | mrelwood | preglow, I meant that wav is preferred. |
| 23:18:10 | mrelwood | midk, other than iRiver. Just in case the glitch can not be fixed after all. |
| 23:18:18 | midk | what glitch? |
| 23:19:30 | mrelwood | it drops 45 samples every now and then (20s - 1min), which will sound as a "snap" |
| 23:20:43 | mrelwood | do a search on "iriver recording glitch" with google, or misticriver.net forums or wherever, it is quite well known. |
| 23:21:14 | | Join amx [0] (~amx@Ottawa-HSE-ppp266560.sympatico.ca) |
| 23:23:54 | | Join jyp [0] (~jp@129.23-136-217.adsl.skynet.be) |
| 23:29:16 | | Quit midk ("Leaving") |
| 23:30:23 | | Join toolmanwv [0] (~aaa@pool-70-18-122-238.buff.east.verizon.net) |
| 23:35:45 | | Quit amx ("Client Exiting") |
| 23:51:20 | amiconn | Does anybody have an idea what "Xlib: unexpected async reply (sequence 0x155)!" means? |
| 23:51:21 | | Quit toolmanwv (Read error: 104 (Connection reset by peer)) |
| 23:51:42 | preglow | hubble: do you have any disassembled code that uses bloody mac instructions handy? |
| 23:51:55 | preglow | i can by no means make mac work in fractional operand mode |
| 23:53:10 | Bagder | amiconn: http://www.faqs.org/faqs/x-faq/part7/section-15.html |
| 23:56:52 | | Join amiconn_ [0] (~jens@pD9E7E529.dip.t-dialin.net) |
| 23:57:06 | | Quit amiconn (Nick collision from services.) |
| 23:57:06 | | Nick amiconn_ is now known as amiconn (~jens@pD9E7E529.dip.t-dialin.net) |
| 23:57:07 | preglow | and the docs can't bloody well agree on if 1 means signed or unsigned mode |
| 23:57:15 | amiconn | Hmm. That's actually bad, because for the new button handling to work, I need to poll button events from X asynchronously. |
| 23:57:19 | amiconn | However, I just tried polling slower. It *seems* to work |
icon identifies that the person is a core developer (has commit access).