--- Log for 13.02.105  Server: zelazny.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 9 days and 15 hours ago

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.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.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.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.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.18.10 Join    webguest99 [0] (~cbc8c609@labb.contactor.se)
05.49.50 Quit    webguest99 ("CGI:IRC (EOF)")
05.51.27 Quit    DMJC ("Leaving")
06.54.12 ***     Saving seen data "./dancer.seen"
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.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.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.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> 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.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.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.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.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.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.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 - 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.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.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.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.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: 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: 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.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.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