--- Log for 16.12.105  Server: kornbluth.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 1 month and 11 days ago

00.00.04 #       <Mmmm> Kyl3: try leaving out the first /
00.00.12 #       <Kyl3> ok
00.01.06 #       <Kyl3> File to patch: apps/gui/gwps-common.c
00.01.08 #       <Kyl3> apps/gui/gwps-common.c: No such file or directory
00.01.08 #       <Kyl3> Skip this patch? [y]
00.01.17 Join    webguest72 [0] (n=3e4f4094@labb.contactor.se)
00.02.08 Quit    Jungti1234 ("bye")
00.02.53 #       <Kyl3> I need this patch. For remote support
00.04.36 #       <Kyl3> and whatever p value i put (0 through 5) I get:
00.05.05 #       <Kyl3> ~/build> patch --binary -p5 < remote_type.patch
00.05.06 #       <Kyl3> missing header for unified diff at line 4 of patch
00.05.08 #       <Kyl3> (Stripping trailing CRs from patch.)
00.05.11 #       <Kyl3> can't find file to patch at input line 4
00.05.13 #       <Kyl3> Perhaps you used the wrong -p or --strip option?
00.05.27 #       <Mmmm> Is the apps directory in the directory you are patching from?
00.05.41 #       <Kyl3> Yes
00.06.07 #       <Kyl3> But.
00.06.18 #       <Kyl3> I went to /apps/gui
00.06.21 #       <Kyl3> and
00.06.38 #       <Kyl3> theres only gwps_common.o
00.06.42 #       <Kyl3> not.c
00.06.52 #       <Mmmm> oh dear! :D
00.07.08 #       <Mmmm> looks like you may not have the source code there!
00.07.11 #       <Kyl3> thats a bad thing eh?
00.07.29 #       <Kyl3> OH WAIT
00.07.39 #       <mirak_> is there something like feof
00.07.43 #       <mirak_> to know the end of a file ?
00.07.48 #       <mirak_> in the api ...
00.08.01 #       <Kyl3> the SOURCE is in the /home/guest
00.08.17 #       <webguest72> mirak_: the read returns 0 I believe
00.08.24 #       <webguest72> Or something like that..
00.08.26 #       <Kyl3> the /home/guest/build is where its compiled in
00.08.30 #       <mirak_> ok
00.08.41 #       <webguest72> Check the PLUGIN_API in docs
00.09.15 ***     Alert Mode OFF
00.10.15 #       <webguest72> actually, read returns something less than count
00.11.51 Quit    pinkutank ()
00.15.00 #       <Mmmm> Kyl3: You need to put the source in /home/guest/build and patch here. Then make in home/guest/build/compiled
00.15.27 Join    ashridah [0] (n=ashridah@67.106.77.212.ptr.us.xo.net)
00.15.41 #       <Kyl3> Yeah I did that.I'm still trying to get it to work though I still get the error
00.16.33 #       <Mmmm> -p1 ?
00.17.43 #       <Kyl3> No -p0
00.17.54 #       <Kyl3> -p1 gives me SO many errors
00.18.16 #       <Kyl3> ~>patch --binary -p1 < remote_type.patch
00.18.18 #       <Kyl3> (Stripping trailing CRs from patch.)
00.18.18 #       <Kyl3> patching file apps/gui/gwps-common.c
00.18.18 #       <Kyl3> Reversed (or previously applied) patch detected! Assume -R? [n]
00.18.23 #       <Kyl3> that for all the files
00.21.07 Join    webguest66 [0] (n=ca7d0006@labb.contactor.se)
00.22.09 #       <Mmmm> right...now its working! although it seems you have applied the patch before or maybe the patch is already in cvs! what player are you using?
00.22.23 Quit    Kohlrabi ("Leaving")
00.22.26 #       <Kyl3> H300
00.23.14 #       <Kyl3> but I hadent patched before
00.23.39 #       <Kyl3> maybe I should download a clean source
00.23.53 Join    xmixahlx [0] (n=xmixahlx@64.122.111.98)
00.24.48 #       <Mmmm> That might do the trick...you never know! hasn't h300 got remote support yet then?
00.25.05 #       <Kyl3> Yes but not the
00.25.11 #       <Kyl3> H300 LCD remote
00.27.02 #       <Mmmm> ahh, I see... What patch are you using?
00.27.35 #       <Kyl3> it was one that isnt on the list. a forum made one
00.28.07 #       <Kyl3> it enables a menu that asks what remote you have then it maps the buttons accordingly
00.30.07 Quit    perplexity (Read error: 113 (No route to host))
00.30.23 #       <Kyl3> ~>patch --binary -p1 < remote_type.patch
00.30.26 #       <Kyl3> (Stripping trailing CRs from patch.)
00.30.27 #       <Kyl3> patching file apps/gui/gwps-common.c
00.30.28 #       <Kyl3> (Stripping trailing CRs from patch.)
00.30.30 #       <Kyl3> patching file apps/gui/gwps.c
00.30.31 #       <Kyl3> (Stripping trailing CRs from patch.)
00.30.33 #       <Kyl3> patching file apps/lang/english.lang
00.30.34 #       <Kyl3> (Stripping trailing CRs from patch.)
00.30.35 #       <Kyl3> patching file apps/settings.c
00.30.37 #       <Kyl3> (Stripping trailing CRs from patch.)
00.30.38 #       <Kyl3> patching file apps/settings.h
00.30.41 #       <Kyl3> (Stripping trailing CRs from patch.)
00.30.42 #       <Kyl3> patching file apps/settings_menu.c
00.30.44 #       <Kyl3> (Stripping trailing CRs from patch.)
00.30.46 #       <Kyl3> patching file firmware/drivers/button.c
00.30.48 #       <Kyl3> (Stripping trailing CRs from patch.)
00.30.50 #       <Kyl3> patching file firmware/export/button.h
00.30.58 #       <Kyl3> does that mean it worked?
00.31.04 #       <Kyl3> thats with the new source
00.31.08 #       <Mmmm> Oh yes!! :D
00.31.12 Join    mind_less [0] (n=Tim@209.51.83.226)
00.31.39 #       <Kyl3> Ok! thanks Mmmm! now, I'm gonna compile and see if it works
00.31.54 #       <Mmmm> Told you -p1 would do it! hee hee
00.35.24 #       <Mmmm> Goodnight folks..........
00.35.44 #       <Kyl3> night
00.35.51 Quit    Mmmm ("ZZZZZZzzzzzz.....")
00.38.25 Quit    idanm (Read error: 110 (Connection timed out))
00.45.21 #       <Kyl3> After all that the patch doesnt even work?
00.49.10 #       <Kyl3> wait yes it does
00.53.54 Join    aliask [0] (n=chatzill@c210-49-190-113.eburwd8.vic.optusnet.com.au)
00.54.06 Quit    DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
00.54.25 Quit    Moos ("Happy Birthday Rockbox")
00.54.32 Quit    xmixahlx ("blah blah blah")
01.05.52 Quit    ender` (" Top reason why compilers are like women: Miss a period and they go crazy")
01.06.10 Quit    linuxstb_ ("CGI:IRC")
01.15.37 ***     Saving seen data "./dancer.seen"
01.43.55 Quit    dpassen1 ()
01.48.09 #       <linuxstb> Good and bad news for iPod audio - Rockbox on the ipod can decode a 3m 23s FLAC -8 file in 2m 36s, but the same file in Vorbis (-q 6) takes 1m 55 seconds to decode just the first 60s of the track.  A 192kbps MP3 file is slower than Vorbis - 1m 59s for the first 60s.
01.48.19 #       <linuxstb> This is using IRAM, but no assembler optimisations.
01.49.23 #       <linuxstb> This is also just using a single CPU running at 75MHz.
01.54.52 #       <webguest72> Any arm opts for flac already present?
01.55.24 #       <webguest72> ah, you said that
01.57.22 #       <linuxstb> No, but libmad has some ARM opts - I've enabled them and am about to test.
01.57.51 Quit    webguest66 ("CGI:IRC")
01.59.47 #       <webguest72> Hrm, isn't this still at least as fast as it was on the coldfire?
01.59.58 #       <webguest72> at first, that is
02.00.48 #       <webguest72> 50% of realtime doesn't sound bad for a first-try, non-optimized
02.03.13 #       <linuxstb> It's not too bad.  But we are already using IRAM for the codecs, so that optimisation technique has been used up.
02.03.28 #       <linuxstb> All that's left is assembler.  Plus using the iPod's second CPU of course.
02.05.07 #       <linuxstb> So I'm a bit disappointed.  But at least my format of choice (FLAC) is already running at about 130% realtime on just a single CPU.
02.09.14 #       <webguest72> Ah right, the iram
02.10.41 #       <mirak_> linuxstb: isn't ipod crap anyway ?
02.11.06 #       <mirak_> that's just a genuine question, I don't have one ^^
02.11.48 #       <linuxstb> I like the hardware.
02.12.03 #       <linuxstb> Apple's software is irrelevant.
02.12.56 #       <mirak_> it's pretty
02.13.16 #       <mirak_> the wheel is uncomparable to the crappy H300 direction pad
02.13.37 #       <mirak_> really the pad is crap ..
02.18.50 #       <ashridah> i've seen some fairly poor analysis results of the audio output stages of the ipod hardware
02.19.00 #       <ashridah> crappy bass response and whatnot
02.19.19 #       <ashridah> don't know how it compares to iriver's hardware tho
02.19.41 #       <mirak_> iriver is supposed to be better on audio
02.19.48 #       <linuxstb> Once we get Rockbox playing audio, we can do some fair comparisons.
02.21.19 Join    lostlogi1x [0] (n=lostlogi@node-4024215a.mdw.onnet.us.uu.net)
02.22.49 Join    lostlogic_ [0] (n=lostlogi@node-4024215a.mdw.onnet.us.uu.net)
02.22.49 ***     Alert Mode level 1
02.22.49 ***     Alert Mode level 2
02.22.49 DBUG    Enqueued KICK lostlogi1x
02.22.49 DBUG    Enqueued KICK lostlogic_
02.22.49 ***     Alert Mode level 3
02.23.39 Quit    lostlogic (Nick collision from services.)
02.23.40 Nick    lostlogic_ is now known as lostlogic (n=lostlogi@node-4024215a.mdw.onnet.us.uu.net)
02.23.40 DBUG    Enqueued KICK lostlogic
02.23.40 ***     Alert Mode level 4
02.23.54 Join    Sucka [0] (n=NNSCRIPT@host86-136-20-96.range86-136.btcentralplus.com)
02.25.47 #       <ashridah> linuxstb: well, i'm more talking about the output's capability to drive a set of earphones
02.26.01 #       <ashridah> ie, the DAC's quality.
02.26.06 #       <ashridah> more so than software decoding quality
02.27.11 Quit    San (Read error: 110 (Connection timed out))
02.27.29 Quit    webguest72 ("CGI:IRC (Ping timeout)")
02.27.49 Quit    webguest44 ("CGI:IRC")
02.33.41 ***     Alert Mode OFF
02.34.18 #       <linuxstb> ashridah: Yes, I know.  But I would like to hear what Rockbox can do before passing final judgement.
02.35.32 #       <mirak_> ok I am stuck on compilation
02.35.47 #       <mirak_> http://paste.ubuntu-nl.org/5802
02.37.34 #       <linuxstb> Either I didn't do things correctly, or the ARM optimisations in libmad make virtually no difference.  The same 60s of audio now takes 1m 50s (compared to 1m 59s without any arm asm)
02.37.42 Quit    Weazel_ (Read error: 104 (Connection reset by peer))
02.38.17 Quit    lostlogicx (Read error: 110 (Connection timed out))
02.38.35 #       <mirak_> well they said that ipod could probably not play ogg
02.38.43 #       <mirak_> maybe they where right ^^
02.38.49 #       <ashridah> 'were'
02.38.54 #       <mirak_> were
02.39.17 #       <ashridah> mirak_: that looks more like an error before the #include is used
02.39.32 Quit    actionshrimp (Read error: 110 (Connection timed out))
02.39.36 #       <ashridah> wait, i read the wrong brace, nevermind
02.39.41 #       <linuxstb> mirak_: No, we'll get Ogg on the iPod.
02.39.53 #       <mirak_> I dare you
02.39.57 #       <mirak_> ;)
02.40.15 #       <ashridah> you're daring him to do something he's already working on?
02.40.42 Ctcp    Ignored 4 channel CTCP requests in 2 hours and 24 minutes at the last flood
02.40.42 #       * ashridah seems to recall that some of the codecs started out at 10% of realtime or something initially on iriver :)
02.40.51 #       <mirak_> what is _EXFUN ?
02.40.57 #       <mirak_> there is the same in rockbox
02.41.06 #       <mirak_> _VOID	_EXFUN(qsort,(_PTR __base, size_t __nmemb, size_t __size, int(*_compar)(const _PTR, const _PTR)));
02.41.34 #       <linuxstb> It's a macro defined in firmware/include/_ansi.h
02.42.39 #       <mirak_> have you seen the error ?
02.44.28 #       <mirak_> I don't understand why the error appears now
02.44.39 #       <mirak_> there might a conflict with the defines or something
02.44.59 #       <linuxstb> I would just remove the asserts from that .c file
02.45.05 #       <linuxstb> and not include the .h file.
02.45.50 #       <mirak_> I don't even know what inserts it
02.45.51 #       <linuxstb> In fact, there are no asserts in that .c file, so simply remove the #include
02.46.00 #       <mirak_> assert.h ?
02.46.08 #       <linuxstb> Yes.
02.46.30 #       <linuxstb> assert.h defines the function assert() - which isn't in that file.
02.46.39 #       <linuxstb> So the include isn't needed.
02.47.15 #       <mirak_> but it's included nowhere
02.47.19 #       <mirak_> from nowhere
02.47.41 #       <linuxstb> A quick grep shows assert.h is included in all the motion/estimation*.c files, but assert() isn't in those files (or anywhere else)
02.48.00 #       <mirak_> argh my search fonction in eclipse have a problem then
02.48.11 #       <linuxstb> Bah!  use grep
02.48.31 #       <mirak_> yeah
02.51.59 Join    YouCeyE [0] (n=YouCeyE@vp089013.reshsg.uci.edu)
02.53.10 Join    webguest72 [0] (n=3e4f4094@labb.contactor.se)
02.55.18 #       <webguest72> mirak_: IPL already plays ogg. I'd be very much surprised if Rockbox cannot do it better
02.59.36 #       <linuxstb> webguest72: I'm not sure IPL manages to play high bitrate vorbis files though.
03.02.01 #       <markun> mirak_ just compiled his xvid plugin, but is too tired to even test it :)
03.02.22 #       <markun> Well, we'll know tomorrow
03.03.34 #       <linuxstb> I've just tried a vorbis -q 4 file (128kbps), and 60s of audio takes 1m 44s to decode.
03.04.10 #       <linuxstb> (compared to 1m 55s for the same audio encoded at -q 6)
03.06.45 #       <linuxstb> But lossless wavpack is flying - a 3m 23s track decoded in 1m 31s
03.07.19 #       <webguest72> Just wayt til bryan gets hold of some arm processor
03.08.31 #       <linuxstb> You mean David Bryant?
03.09.18 #       <linuxstb> I'm not sure there's any work he needs to do.  It's running at more than 200% realtime already on a single 75MHz ARM.
03.10.42 #       <webguest72> Yeah, him.
03.11.04 #       <webguest72> Well, the faster the merrier
03.11.32 #       <linuxstb> And the wavpack encoder is running at about 130% realtime as well.
03.15.41 ***     Saving seen data "./dancer.seen"
03.19.23 #       <webguest72> So where is the huge influx of disgruntled ipl devs?
03.28.09 Join    Jungti1234 [0] (n=d3f86683@labb.contactor.se)
03.28.33 #       <Jungti1234> hi
03.30.39 Join    xbshift [0] (i=shift@CPE000c6e94cf09-CM001225d870de.cpe.net.cable.rogers.com)
03.32.57 #       <xbshift> hey
03.34.21 #       <Jungti1234> hey
03.37.27 #       <xbshift> hey
03.42.51 Quit    Kyl3 (Read error: 104 (Connection reset by peer))
03.43.21 Quit    Jungti1234 ("CGI:IRC (EOF)")
03.44.01 Join    amiconn_ [0] (n=jens@p54BD43A6.dip.t-dialin.net)
03.49.26 Quit    webguest72 ("CGI:IRC (Ping timeout)")
04.00.33 Quit    amiconn (Read error: 110 (Connection timed out))
04.00.34 Nick    amiconn_ is now known as amiconn (n=jens@p54BD43A6.dip.t-dialin.net)
04.05.21 Join    San [0] (n=sanitari@213-202-173-68.bas504.dsl.esat.net)
04.08.29 Join    Paul_The_Nerd [0] (n=paulthen@cpe-66-68-93-2.austin.res.rr.com)
04.13.53 Quit    mind_less ("Download Gaim: http://gaim.sourceforge.net/")
04.17.06 Nick    Sucka is now known as actionshrimpo (n=NNSCRIPT@host86-136-20-96.range86-136.btcentralplus.com)
04.17.07 Nick    actionshrimpo is now known as actionshrimp (n=NNSCRIPT@host86-136-20-96.range86-136.btcentralplus.com)
04.33.12 Join    tvelocity [0] (n=tony@84.254.9.197)
04.38.36 Quit    DrumRBoy320|away (Read error: 110 (Connection timed out))
04.45.15 Quit    San (Read error: 110 (Connection timed out))
05.01.12 Join    Rob2222_ [0] (n=Miranda@ACB198DB.ipt.aol.com)
05.15.42 ***     Saving seen data "./dancer.seen"
05.19.27 Quit    Rob2222 (Read error: 110 (Connection timed out))
05.23.48 Quit    YouCeyE ("Leaving")
05.41.29 Join    DJDD_ [0] (n=DJDD@220-245-186-182.static.tpgi.com.au)
05.50.00 Join    nathanh [0] (n=nathanh@220-245-216-23-act-pppoe.tpgi.com.au)
06.17.49 Join    San [0] (n=sanitari@213-202-135-223.bas502.dsl.esat.net)
06.17.56 Quit    Benacool ()
06.18.13 Join    DrumRBoy320|away [0] (n=Drumrboy@ool-44c20ff1.dyn.optonline.net)
06.18.38 Join    Bubs [0] (n=bubsterb@S010600045a2dbea0.vf.shawcable.net)
06.18.53 #       <Bubs> hello
06.19.10 Quit    Bubs (Client Quit)
06.26.50 Join    Jungti1234 [0] (n=jungti12@58.77.81.144)
06.35.34 #       <lostlogic> is comparing a constant and a register or comparing a register and a register faster?
06.36.54 #       <dwihno> afaik reg+reg is faster (at least, on x86)
06.37.13 Quit    DrumRBoy320|away (Read error: 110 (Connection timed out))
06.37.16 #       <dwihno> but I'm not really sure
06.42.36 #       <lostlogic> I think I'm concluding the same on coldfire -- use of extension words will be slower than comparing two preloaded registers.
06.43.28 #       <dwihno> what are you diggin at?
06.44.08 #       <lostlogic> just toying with Tremor, and relearning m68k... in the unlikely case that I see something worth optimizing, I will.
06.47.40 #       <dwihno> ah, okay! are there any obvious bottlenecks?
06.48.39 #       <lostlogic> sadly , I think the obvious ones are already dead.
06.48.47 #       <lostlogic> or optimized
06.49.08 #       <lostlogic> the question right now is why am I seeing a jbsr for an inline'd function?
06.50.09 #       <dwihno> I am NOT 68k compliant ;)
06.51.15 #       <lostlogic> jbsr jump to subroutine
06.51.38 #       <lostlogic> the assembly clearly shows this supposedly inlined function being jumped to, and that irritates the living junk out of me.
06.51.48 #       <lostlogic> can't we trust compilers to listen to us at all?
06.53.03 #       <dwihno> rule #1 - never assume anything :)
06.53.38 #       <lostlogic> too long to inline maybe.
06.54.04 #       <nathanh> rule #2 - dont assume rule #1 is correct
06.56.11 #       <dwihno> hehe
07.01.36 Quit    RotAtoR ()
07.15.46 ***     Saving seen data "./dancer.seen"
07.22.42 #       <lostlogic> gah, GCC sucks.
07.22.43 #       <lostlogic>   move.w profiling,%d0  | profiling, profiling
07.22.43 #       <lostlogic>   jbne .L28 |
07.22.43 #       <lostlogic>   .loc 1 184 0
07.22.43 #       <lostlogic>   move.w profiling,%d0  | profiling, profiling
07.22.43 ***     Alert Mode level 1
07.22.43 #       <lostlogic>   addq.l #1,%d0 |, tmp34
07.22.45 #       <lostlogic>   move.w %d0,profiling  | tmp34, profiling
07.23.01 #       <lostlogic> should be 2 instructions and a jump, not 4 and a jump.
07.24.55 #       <lostlogic> I think we might be able to make an appreciable difference in the speed of rockbox on iRiver by teaching GCC that addq can work on an effective address, but then I could be totally wrong.
07.27.22 #       <nathanh> rule #3 - greater performance gains are through changes to algorithm, not changes to tools or language
07.27.27 #       <Bger> morning
07.27.38 #       <nathanh> rule #4 - rule #2 also applies to rule #3 :-)
07.27.44 #       <nathanh> gday bger
07.28.05 #       <Paul_The_Nerd> nathanh: I would wager that significant performance gains could be found in many applications by changing languages. :-P
07.28.22 #       <nathanh> i often find french is the fastest :-P
07.29.40 #       <Paul_The_Nerd> Hahaha
07.32.44 ***     Alert Mode OFF
07.42.26 Quit    DJDD_ (Read error: 104 (Connection reset by peer))
07.57.45 Join    linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net)
07.57.46 Quit    aliask ("Chatzilla 0.9.69 [Firefox 1.5/2005111116]")
07.59.36 Quit    linuxstb (Read error: 110 (Connection timed out))
08.09.49 Quit    mikearthur (Read error: 104 (Connection reset by peer))
08.19.20 Join    DrumRBoy320|away [0] (n=Drumrboy@ool-44c20ff1.dyn.optonline.net)
08.42.17 Quit    nathanh (Read error: 104 (Connection reset by peer))
08.45.08 Quit    ^BeN^ (Read error: 110 (Connection timed out))
08.45.29 #       <Bger> hahaha "Top reason why compilers are like women: Miss a period and they go crazy" 
08.45.40 #       <Paul_The_Nerd> Hahaha
08.46.01 #       <Bger> (found in yesterday's log)
08.48.53 #       <DreamTactix291> lol
08.51.30 Join    Kohlrabi [0] (n=Kohlrabi@dslb-082-083-129-077.pools.arcor-ip.net)
08.53.52 Join    linuxstb__ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net)
08.54.52 Join    _FireFly_ [0] (n=icechat5@pd95b7c08.dip0.t-ipconnect.de)
08.55.22 Join    ender` [0] (i=ychat@84.52.165.220)
08.56.07 Quit    linuxstb_ (Read error: 110 (Connection timed out))
08.56.14 #       <Bger> ender` good quit message ;)
08.56.34 #       <ender`> :)
08.58.14 #       <Jungti1234> hi
08.59.56 #       <preglow> linuxstb__: so, you made a dummy driver?
09.00.36 Join    georgeblunt [0] (n=georgebl@82.149.71.170)
09.00.40 #       <georgeblunt> g'morning
09.01.24 Quit    DrumRBoy320|away (Read error: 110 (Connection timed out))
09.01.33 #       <Bger> moin
09.02.08 #       <preglow> linuxstb__: i don't get how the codecs can be that slow when wavpack encode was so fast :/
09.02.28 #       <preglow> perhaps the 64 bit muls really slow stuff down
09.02.58 #       <Bger> doesn't the arm have 64 bit mul ?
09.04.56 #       <preglow> yes it does
09.05.01 #       <preglow> but it's not as fast as the emac
09.05.05 #       <preglow> far, far from it
09.05.12 #       <Bger> aha :(
09.05.13 #       <preglow> unless portalplayer has done some fanciness
09.06.53 #       <Bger> and there isn't something like emac on PP's chips 
09.06.55 #       <Bger> ?
09.11.10 #       <preglow> well
09.11.19 #       <preglow> there's the 64 bit multiplier which we're talking about
09.11.25 #       <preglow> it's better than the emac, just slower
09.11.36 #       <preglow> again, unless portalplayer's juiced it up
09.11.40 #       <preglow> which they really should have
09.11.57 #       <Bger> let's hope they've done it
09.15.48 ***     Saving seen data "./dancer.seen"
09.17.36 #       <preglow> doubt they have
09.17.47 #       <preglow> but their product spec talks about some mac thing
09.17.54 #       <preglow> and i don't know what they're talking about
09.18.19 #       <Bger> maybe sthing different from the standart 64bit mul
09.18.31 #       <Bger> standarD
09.26.00 #       <Jungti1234> What is rtc?
09.26.11 #       <Bger> RealTime Clock
09.26.44 #       <Jungti1234> ah
09.28.27 #       <Jungti1234> But, doesn't it support?
09.29.49 #       <Bger> it's not supported yet in rockbox
09.30.17 #       <Jungti1234> Then, what is 'h300-rtc.diff'?
09.31.34 #       <Bger> where ?
09.32.04 #       <Jungti1234> That I know, maybe its Bagder made.
09.32.18 #       <Bger> where did you see it ?
09.32.28 #       <Jungti1234> IRC
09.32.51 #       <preglow> bagder doesn't even have h300
09.33.01 #       <Bger> link?
09.33.13 #       <Jungti1234> ah
09.33.23 #       <Jungti1234> Then..
09.33.29 #       <Jungti1234> linux_stb?
09.33.45 #       <preglow> he has ipod
09.33.50 #       <Bger> Jungti1234 where did you see this h300-rtc.diff 
09.33.57 #       <Jungti1234> wait
09.34.00 #       <Jungti1234> i find it
09.34.18 #       <Jungti1234> <linuxstb_> LinusN: I've committed that patch.  All I've done on the h300 is here: http://www.davechapman.f2s.com/rockbox/h300-rtc.diff
09.35.08 #       <Bger> hmmm
09.35.50 #       <Jungti1234> <LinusN> linuxstb: ok, so now we need to find a clean solution to the i2c problem
09.36.12 #       <Bger> Jungti1234 when did this happen ?
09.36.24 #       <Jungti1234> 12-11
09.38.08 #       <Bger> starting 01.32.40
09.39.27 #       <Jungti1234> yes
09.39.55 Join    Zagor [0] (n=bjst@194-237-150-170.customer.telia.com)
09.40.45 #       <Bger> so it's not ready
09.45.44 #       <preglow> at least ipod keypad is almost completely useful now
09.48.25 #       <Jungti1234> het
09.48.28 #       <Jungti1234> hey
09.49.08 #       <Bger> good news :)
09.50.04 #       <Jungti1234> There is no subject to sudoku.
09.50.36 #       <Jungti1234> -> Sudoku is no subject.
09.51.27 #       <Bger> ?
09.51.38 #       <Bger> what do you want to say, Jungti1234 ?
09.51.44 #       <Jungti1234> ah..
09.52.03 #       <Jungti1234> Nothing. :(
09.54.34 Quit    San (Read error: 110 (Connection timed out))
09.55.01 #       <preglow> i am an idiot :/
09.55.07 #       <Jungti1234> Is so difficult to make understood you.
09.55.44 #       <Bger> Jungti1234 try different translation engine....
09.55.54 #       <Bger> or, better, try to learn some english ...
09.55.58 #       <Jungti1234> -_-;
09.56.01 #       <Jungti1234> yes.
09.56.20 #       <Bger> preglow : what's the problem
09.56.22 #       <Jungti1234> I'm learning English.
09.56.32 #       <preglow> Bger: the problem is i'm an idiot
09.56.36 #       <preglow> the perpetual problem
09.56.38 #       <Bger> hahaha
09.56.48 #       <Bger> what to say about myself then ...
09.57.12 #       <Jungti1234> Are you really idiot?
09.57.19 #       <preglow> linuxstb__: www.pvv.org/~thomj/rockbox/rockbox.ipod when you're here
09.57.28 #       <preglow> linuxstb__: the clickwheel is a bit more usable now
09.58.03 #       <Bger> these 64bit amds are really sensitive to memory's chips...
09.58.06 #       <Jungti1234> wow
09.58.35 Nick    Lynx_awy is now known as Lynx_ (n=lynx@tina-10-4.genetik.uni-koeln.de)
09.59.05 #       <Jungti1234> It works!
09.59.44 #       <Bger> Jungti1234 what?
09.59.49 #       <Jungti1234> rtc
10.00.17 #       <Bger> i don't think it's stable 
10.00.37 #       <Jungti1234> what is stable?
10.01.07 #       <Bger> i mean
10.01.24 #       <Bger> that if you enable rtc
10.01.26 Join    LinusN [0] (n=linus@labb.contactor.se)
10.01.33 #       <Bger> rockbox may hang/lose sound ...
10.01.40 #       <Bger> morning, LinusN ;)
10.01.53 #       <LinusN> morning
10.02.11 Join    Vlad0man [0] (n=Vladoman@p54A7F0AA.dip.t-dialin.net)
10.02.41 #       <Jungti1234> hehe
10.02.53 #       <Jungti1234> It has some problem.
10.04.15 Quit    Vladoman (Read error: 110 (Connection timed out))
10.06.01 #       <Jungti1234> It doesn't save of time that I change.
10.06.17 #       <LinusN> Jungti1234: now you know why we haven't committed that patch
10.06.40 #       <Bger> LinusN is that the only reason ?
10.06.44 #       <Jungti1234> Know already. :)
10.06.46 #       <LinusN> no
10.07.02 #       <Bger> i read something about i2c ...
10.07.10 #       <Jungti1234> yes.
10.07.27 #       <LinusN> the rtc functions need to be interrupt protected, to not screw up the I2C communication
10.07.57 #       <Bger> hm, there was some silly about i2c in h100 ...
10.07.59 #       <Bger> iirc
10.08.07 #       <Bger> is it here too (h300) ?
10.08.30 #       <LinusN> you mean the missing clk pullup?
10.08.41 #       <Bger> i don't remember 
10.08.49 Join    einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de)
10.08.54 #       <LinusN> i guess that's what you mean
10.09.03 #       <Bger> but it was something that iriver engeneers where to blame
10.09.11 #       <LinusN> and the clk line is pulled up on the h300
10.09.29 #       <LinusN> i blame iriver engineers for a lot of silly mistakes
10.09.38 #       <Bger> hehe
10.09.39 #       <Bger> like ?
10.09.46 #       <LinusN> the clk pullup being one of them
10.10.08 #       <LinusN> on the h100, the lcd register select should have been connected to an address line
10.10.09 #       <Paul_The_Nerd> Is there documentation somewhere to help me get started on how to properly make a plugin, or would my best plan be to just use an existing one as a template and learn by doing?
10.10.22 #       <preglow> it isn't??
10.10.27 #       <preglow> how logical
10.10.30 #       <Bger> Paul_The_Nerd see apps/plugins/helloworld.c
10.10.34 #       <LinusN> Paul_The_Nerd: start with the hello_world plugin
10.10.37 #       <Bger> this is the most simple 
10.10.38 #       <Bger> one
10.10.52 #       <LinusN> preglow: it's connected to a gpio
10.10.55 #       <Bger> and look at other ones
10.11.00 #       <Paul_The_Nerd> Alright, thanks
10.11.09 #       <preglow> LinusN: makes sense to waste gpios on that yes
10.11.11 #       <LinusN> they changed it on the h300
10.11.14 #       <Bger> and ... ask :)
10.11.18 #       <Paul_The_Nerd> Also, is there a maximum plugin size?
10.11.27 #       <preglow> Paul_The_Nerd: depends on arch
10.11.28 #       <Bger> yes, for iriver 768k for now
10.11.30 #       <preglow> Paul_The_Nerd: 32kb on archos
10.11.40 #       <Paul_The_Nerd> This would be an iRiver+ plugin, theoretically
10.11.45 #       <preglow> the 768kb will be changed to 512kb Real Soon Now
10.11.48 #       <LinusN> however, they changed it in a silly way, using the A1 address pin
10.11.57 #       <Paul_The_Nerd> Why down to 512?
10.12.03 #       <preglow> Paul_The_Nerd: because 768 is really much
10.12.07 #       <LinusN> effectively preventing burst transfers... :-(
10.12.16 #       <Bger> :(
10.13.26 #       <Bger> hm, is the battery voltage in rb on h300 correct ?
10.13.45 #       <LinusN> yes, it should be correct
10.14.33 #       <Bger> hm, so this means that on h300 the battery goes down to as much as 3.15V, while on h100 it goes down to ~ 2.6V ?
10.14.54 #       <Bger> that is, before the unit turns of
10.14.55 #       <Bger> f
10.15.18 #       <LinusN> Bger: have you tried to boot the original after it has turned off?
10.15.25 #       <Bger> yes
10.15.38 #       <Bger> i even tryed when rb still worked ... no effecty
10.16.02 #       <LinusN> i think we still have a serious power issue on the h300
10.16.11 #       <Bger> like ?
10.16.28 #       <LinusN> like drawing far too much power
10.16.37 #       <preglow> oh`?
10.16.39 #       <Bger> yes ...
10.16.43 #       <Bger> :(
10.16.53 #       <Bger> i think part of the problem is the lcd_update() ...
10.16.55 #       <preglow> because of lacking power management or...?
10.17.28 #       <LinusN> preglow:  i fear that it might be because of faulty port pin settings
10.17.41 #       <Bger> i.e. ?
10.17.51 #       <LinusN> a collision
10.18.19 #       <Bger> ok, it's clear to me already :))
10.18.51 #       <LinusN> hehe, it means setting a port pin to an output when it should be an input
10.19.42 #       <LinusN> also, we should turn off the lcd when it isn't visible, and even stop sending data to it
10.19.55 #       <Bger> LinusN i was looking into that ...
10.20.03 #       <LinusN> i know
10.20.07 #       <LinusN> any luck?
10.20.18 #       <Bger> reading the datasheet
10.20.52 #       <Bger> btw, where did you get all these writes in lcd_init_device() from ?
10.20.59 #       <mirak_> hello
10.21.06 #       <LinusN> from the original firmware
10.21.21 #       <Slasheri> |;; AUTHORITY SECTION:
10.21.22 #       <Slasheri> |rockbox.org.            345550  IN      NS      ns2.rockbox.org.
10.21.22 #       <Slasheri> |rockbox.org.            345550  IN      NS      ns1.rockbox.org.
10.21.27 #       <Slasheri> eh, that's "nice"
10.21.46 #       <Slasheri> i still have to wait 3 days before forums.rockbox.org resolves to the right ip on my work machine
10.22.07 #       <Slasheri> the ttl seems to be a way too high..
10.22.29 #       <preglow> LinusN: can you save much power by switching off the lcd? i thought it didn't draw much
10.22.42 #       <Bger> preglow the lcd_update is slow....
10.22.44 Quit    Jungti1234 ("bye")
10.24.05 #       <Bger> and @ 11MHz (fm radio) is awfully slow...
10.26.19 #       <mirak_> when writting with snprintf there is no scrolling of the screen ?
10.26.40 #       <preglow> you don't write with snprintf
10.26.45 #       <preglow> you write with lcd_puts
10.26.48 #       <preglow> and no, that's doesn't scroll
10.26.57 #       <preglow> you have to use the _scrolling version to make it scroll
10.27.39 #       <preglow> lct_puts_sroll, for example
10.29.50 #       <mirak_> void (*lcd_puts_scroll)(int x, int y, const unsigned char* string);   ok, so if I alway use 0,0 the screen while scroll
10.29.54 #       <mirak_> ?
10.30.26 #       <mirak_> I should just write to file
10.31.39 #       <Bger> mirak_ these are the coordinates
10.31.44 #       <Bger> x and y
10.31.48 #       <mirak_> yes
10.32.09 #       <Bger> use x=0 and y=... 
10.32.25 #       <LinusN> Bger: regarding the fm screen, we should do some changes:
10.32.31 #       <LinusN> 1) Remove the peak meter
10.32.33 #       <mirak_> where is the scrolling then ?
10.32.38 #       <LinusN> 2) boost the cpu when seeking
10.32.55 #       <Bger> uh:(
10.33.13 #       <markun> morning mirak_ 
10.34.16 #       <mirak_> hi
10.34.58 #       <mirak_> sorry I don't understand how it can have coordinates and still scroll
10.35.10 #       <mirak_> is that a lateral scrolling ?
10.37.02 #       <mirak_> that's a line scrolling that's not what I need
10.38.36 #       <Bger> ah, what scrolling do you need ?
10.38.41 #       <Bger> scrolling text ?
10.38.54 #       <Bger> like going from down to up ?
10.39.57 #       <mirak_> yes, I was looking how credits do it
10.40.08 #       <mirak_> but that's a bit complicated
10.40.19 #       <Bger> there's no standard way ...
10.40.19 #       <mirak_> I just needed a console style output
10.41.16 #       <mirak_> argh
10.42.23 #       <Bger> LinusN according to the datasheet the "standby sequence" (p 131) is power off sequence + STB=1 ? or i don't get it right ...
10.42.53 Join    DrumRBoy320|away [0] (n=Drumrboy@ool-44c20ff1.dyn.optonline.net)
10.43.32 #       <markun> mirak_: maybe output some simple messages to the screen like 'decoding frame 1' and write the full messages to a file?
10.46.01 #       <preglow> mirak_: if you have a remote control, i'd just use logf
10.46.13 #       <Bger> oh, yes
10.47.18 #       <linuxstb__> preglow: That button driver's looking good now.
10.47.31 #       <mirak_> no remote
10.47.56 #       <LinusN> Bger: i think it's somewhat confusing too
10.48.30 #       <preglow> linuxstb__: still plenty of room for improvement
10.48.32 #       <LinusN> Bger: but i guess the STB and SLP modes are for the *controller* and the display on/off are for the LCD
10.48.41 #       <preglow> linuxstb__: but yeah, how fares the codecs? :/
10.48.48 #       <Bger> aha...
10.48.55 #       <LinusN> i don't think the sleep/standby modes will matter much
10.49.04 #       <Bger> ok, just asking
10.49.23 #       <Bger> this datasheet isn't one of the clearest (at least for me)
10.50.18 #       <LinusN> lcd power supply current (256k colors): 1.68mA max
10.51.25 #       <LinusN> current consumption during transfers: 11mA
10.57.25 #       <linuxstb__> preglow: I assume you read the disappointing results with a dummy driver?
10.57.39 #       <preglow> yes, exactly
10.57.45 #       <preglow> but you hadn't enabled some opts yet
10.57.48 #       <preglow> like arm opts for libmad
10.57.51 #       <preglow> which will matter
10.58.10 #       <linuxstb__> I enabled those, but they only seemed to give a very small improvement - unless I didn't properly enable them.
10.58.15 #       <preglow> :///
10.58.18 #       <preglow> well
10.58.25 #       <preglow> that sucks
10.58.57 #       <Bger> no, u'll have the oportunity to optimise libmad once more :))
10.59.13 #       <preglow> just defining FPM_ARM should be all you need
10.59.21 #       <linuxstb__> I defined FPM_ARM and ASO_IMDCT in globals.h and added imdct_l_arm.S to the SOURCES
10.59.22 #       <preglow> plus adding the arm assembler file to SOURCES
10.59.27 #       <preglow> hrmphhhh
11.00.24 #       <preglow> how far towards realtime is it with those enabled?
11.01.01 #       <linuxstb__> 1m 50s to decode 1m of audio (1m 55s without the opts)
11.01.51 #       <linuxstb__> Sorry, 1m 59s without the opts.  1m 55s is the vorbis time to decode the same 1m sample.
11.02.06 #       <preglow> wah?
11.02.16 #       <preglow> libmad and tremor is about equally fast?
11.02.34 #       <amiconn> LinusN: Missed my question y'day?
11.06.06 Join    DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se)
11.06.41 Quit    DrumRBoy320|away (Read error: 110 (Connection timed out))
11.07.00 #       <preglow> linuxstb__: what bitrates are we talking, btw?
11.07.34 #       <linuxstb__> 192kbps
11.07.57 #       <dwihno> for (i=0; i<len; i++) dest[i] = decoding_table[(unsigned char)src[i]]; <-- is this unoptimal?
11.08.55 #       <preglow> linuxstb__: how...
11.09.43 #       <preglow> what...
11.09.50 #       <preglow> i seriously hope you've done some mistake
11.09.53 #       <linuxstb__> It's possible my audio driver isn't doing the right thing, but the timings for FLAC and WavPack seem reasonable.
11.09.54 #       <preglow> this just sounds plain weird
11.10.06 #       <linuxstb__> Although wavpack was a lot faster than FLAC.
11.10.19 #       <preglow> weird...
11.11.37 #       <linuxstb__> I hope I am making a mistake.  But maybe that shows why IPL don't use libmad.
11.12.22 #       <linuxstb__> I only looked briefly at libmad, but I think you've optimised things for Coldfire that don't have ARM optimisations.
11.13.07 #       <preglow> i don't think i have
11.13.13 #       <preglow> the MLA macros, etc, should be fine for arm
11.13.25 #       <preglow> they weren't for coldfire, that's why i had to optimise so much
11.14.49 #       <linuxstb__> So if mad really is this slow, you can't see any obvious areas for improvement?
11.15.45 #       <LinusN> amiconn: the two delay calls?
11.15.52 ***     Saving seen data "./dancer.seen"
11.15.54 Join    webguest91 [0] (n=864c035f@labb.contactor.se)
11.16.33 #       <amiconn> LinusN: yup
11.16.45 #       <LinusN> my LA measurements showed that the FM chip wasn't fast enough to respond
11.17.07 #       * amiconn wonders why this worked on H1x0 then
11.17.08 #       <LinusN> so we read the data just as it was changed by the tuner
11.17.17 #       <LinusN> i wonder that too
11.17.30 #       <LinusN> pure luck i guess
11.17.45 #       <amiconn> Apart from that, why not just increase the DELAY instead of using 2 ?
11.17.55 #       <markun> linuxstb__: the profiling code would not be useful
11.18.04 #       <LinusN> amiconn: then all other delays would be longer
11.18.13 #       <linuxstb__> markun: Which profiling code?  Are you talking about xvidcore?
11.18.28 #       <markun> no, someone was writing a profiler for tremor
11.18.44 #       <markun> don't remember his nick
11.18.56 #       <linuxstb__> That was lostlogic
11.20.10 #       <preglow> sure it would be usefyk
11.20.12 #       <preglow> useful too
11.20.16 #       <preglow> if it works for arm as well
11.23.23 #       <amiconn> LinusN: The FM tuner chip does clock stretching, doesn't it?
11.23.38 #       * amiconn wonders why we can be too fast
11.24.19 #       <LinusN> as far as i could see, it didn't try to stretch the clock
11.25.38 #       <LinusN> however, it might work better if i make use of the clk pullup on the h300
11.26.34 #       <LinusN> one problem is that the data hold time is pretty short
11.26.57 #       <LinusN> ah, never mind, that's not the problem here
11.27.01 #       <dwihno> How do you make gcc output asm out of c stuff?
11.27.26 #       <LinusN> dwihno: that's what gcc does ;-)
11.28.14 #       <preglow> -S
11.28.24 #       <preglow> or -s, can't remember
11.28.30 #       <dwihno> ;)
11.28.36 #       <XavierGr> Morning all.
11.28.40 #       <XavierGr> Bger are you here?
11.29.07 #       <dwihno> Way!
11.29.11 #       <dwihno> thanks preglow!
11.29.26 #       <dwihno> LinusN: naa-haa, it outputs exe files! ;D
11.31.11 #       <Bger> XavierGr yep
11.31.38 #       <XavierGr> You said you made some changes in battery_benchmark plugin the other day.
11.32.03 #       <Bger> yep, but they are not finished and i'm now looking at the lcd driver of h300
11.32.06 Join    mirak [0] (n=mirak@AAubervilliers-152-1-9-186.w82-121.abo.wanadoo.fr)
11.32.32 #       <XavierGr> What did you modified in summary?
11.32.43 #       <Bger> silly things, mainly
11.32.53 #       <Bger> but i want to take a look at the thread
11.33.33 #       <XavierGr> ok, did you do a benchmark on your unit?
11.33.42 #       <Bger> hm, partially
11.34.02 Quit    mirak_ (Read error: 110 (Connection timed out))
11.34.16 #       <Bger> i'll do full one next week probably 
11.34.41 #       <mirak> I heard that the memory limit was 800ko for plugins 
11.34.42 Join    San [0] (n=test@A-78-27.cust.iol.ie)
11.34.45 #       <mirak> is that right ?
11.34.47 #       <XavierGr> it would be nice to know how H300 can last while playing music with rockbox.
11.35.03 #       <XavierGr> 768 for iriver 32 for archos
11.35.34 #       <XavierGr> or do you mean rockbox limit if you change the define?
11.36.01 #       <mirak> 768 for static memory ?
11.36.23 #       <XavierGr> I think yes
11.36.29 #       <mirak> well the frames into the codec requires 1200000ko
11.36.40 #       <mirak> plus the file buffer
11.36.57 #       <XavierGr> I guess you will have to sue the audio buffer.
11.36.57 #       <mirak> I need to change that
11.36.58 #       <LinusN> mirak: then you have to use the audio buffer
11.37.01 #       <XavierGr> ^use
11.37.16 #       <dwihno> People writing assembly using the gcc format must have the patience of angels
11.37.38 #       <XavierGr> mirak: there is no point to use the plugin buffer for video
11.37.57 #       <XavierGr> (of course you should get advantage of the remaining plugin buffer too)
11.38.48 #       <mirak> ok but if I use that buffer while playing something will not do it
11.39.01 #       <Bger> mirak yes
11.39.18 #       <Bger> but the video plugin should stop the music playback anyway
11.39.20 #       <mirak> ok for now we will do dirty
11.39.39 #       <Bger> (and use some plugin interface to the codecs)
11.39.42 #       <mirak> I will do something clean later
11.40.49 #       <preglow> dwihno: me, patience of angel?
11.41.00 #       <preglow> a fine judge of character you are :)
11.41.59 #       <XavierGr> mirak if you use the audio buffer music will stop automatically
11.42.08 #       <mirak> well I am not even sure the static vars of the codec fit in 700ko
11.42.22 Quit    Paul_The_Nerd ("Chatzilla 0.9.68.5.1 [Firefox 1.5/undefined]")
11.42.42 #       <XavierGr> mirak then use buffers from the audio plugin.
11.42.49 #       <XavierGr> audio buffer I mean
11.43.04 #       <preglow> mirak: you'll need to use the file buffer for all the codec data
11.43.08 #       <dwihno> preglow: compared to the intel format (I think what's it's called), the gnu format is completely bongo
11.43.24 #       <preglow> dwihno: ahh, you mean at&t format vs intel format?
11.43.30 #       <mirak> 768ko is for the codec vars, including the binary ?
11.43.31 #       <preglow> i don't think any of them are particularily nice
11.43.54 #       <XavierGr> mirak:yes
11.44.03 #       <dwihno> preglow: aah, that's what the gcc format is...
11.44.13 #       <XavierGr> wait codec vars you mean plugin variables?
11.44.16 #       <preglow> but lunch time
11.44.27 #       <mirak> preglow: I see how to use the codec buffer, howevr I am afraid that the static vars and structs plus the binary takes more than 768ko
11.45.03 #       <mirak> XavierGr: yes plugin variables
11.45.21 #       <mirak> XavierGr: I don't know how I can monitor that space
11.45.28 #       <XavierGr> mirak why not make the static vars buffer arrays from the audio buffer?
11.45.40 #       <XavierGr> you can quite easily I think.
11.45.44 #       <mirak> XavierGr: just imagine the work
11.45.57 #       <XavierGr> oh I don't know about that
11.46.45 #       <XavierGr> But I had the same problem in my first jpeg file scrolling aproach.
11.47.09 #       <XavierGr> I declared a big array statically and in the worst case I was left without memory.
11.47.51 #       <webguest91> hi, i have a problem: rockbox often freezes on my h320 after i have looked at a textfile when i try to enter the settings menu or the file menu, is this a known bug?
11.49.14 #       <Bger> XavierGr btw regarding battery time, i think that rb is nearly 2 times less than original fw :(
11.49.34 #       <XavierGr> 2 times!!!! OMG.
11.49.43 #       <Bger> that's, of course, on h300
11.49.55 #       <mirak> XavierGr: ok what happens when there is not enough static memory ?
11.50.03 #       <XavierGr> In iHP we loose 1-2 hours in mp3 playback.
11.50.17 #       <mirak> it crashes ?
11.50.44 #       <amiconn> The plugin won't link if you use too much space
11.51.26 #       <Bger> XavierGr under 2, but i think it's more close to 2 than to 1.5 ...
11.51.58 #       <webguest91> mirak: it doesn't react on button presses anymore and i have to reset the unit
11.54.04 Quit    San (Read error: 110 (Connection timed out))
12.00.43 Join    Jungti1234 [0] (n=jungti12@58.77.81.144)
12.01.05 #       <Jungti1234> help
12.01.10 #       <XavierGr> what?
12.01.20 #       <Jungti1234> I was making out dictionary.
12.01.28 #       <linuxstb__> preglow: My audio code is now committed.  We just need to add the DMA to actually write data to the DAC and it should work...
12.01.42 #       <Jungti1234> It's rockbox dict plugin.
12.01.57 #       <Jungti1234> By the way, error became.
12.02.03 Nick    linuxstb__ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net)
12.02.27 #       <XavierGr> ah I don't know a thing about the dictionary plugin.
12.02.47 #       <Jungti1234> Error: Some files couldn't be opened
12.03.18 #       <dwihno> preglow: aah, that's what the gcc format is...
12.03.22 #       <dwihno> wups
12.04.30 Join    Zak1392 [0] (n=zkeeping@CPE-144-137-199-238.sa.bigpond.net.au)
12.04.40 #       <Zak1392> hey guys
12.04.45 #       <Jungti1234> help me..
12.04.54 #       <Bger> Jungti1234 be more specific
12.04.58 Join    JdGordon [0] (n=52a6ed38@labb.contactor.se)
12.05.03 #       <JdGordon> hey all
12.05.12 #       <Jungti1234> hi
12.05.14 #       <Bger> yep
12.05.23 #       <Jungti1234> Bger: What?
12.05.29 #       <JdGordon> have i missed much in the last 2 weeks?
12.06.10 #       <Jungti1234> maybe.
12.06.30 Quit    DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
12.06.44 #       <XavierGr> OMG this is the 3rd time I change my approach on the jpeg file scroller.
12.07.08 #       <Bger> hehehe XavierGr 
12.07.08 Quit    JdGordon (Client Quit)
12.07.13 #       <XavierGr> First with statical buffers. Then with dynamic buffers, and now I use rockbox internal dir buffer.
12.07.14 #       <Bger> Jungti1234 you said "help me"
12.07.20 #       <Jungti1234> yes
12.07.27 #       <XavierGr> It was so much easier to implement the third approach.
12.07.33 #       <Bger> :)
12.07.37 #       <Bger> XavierGr is it ready ?
12.07.39 #       <XavierGr> But I learned a lot from the previous too.
12.07.40 #       <mirak> XavierGr: do you use a struct for static buffer ?
12.07.47 #       <XavierGr> The first was like crap.
12.07.49 #       <Jungti1234> [20:01:20] <Jungti1234> I was making out dictionary.
12.07.49 #       <Jungti1234> [20:01:42] <Jungti1234> It's rockbox dict plugin.
12.07.49 #       <Jungti1234> [20:01:57] <Jungti1234> By the way, error became.
12.07.49 DBUG    Enqueued KICK Jungti1234
12.07.49 #       <Jungti1234> [20:02:47] <Jungti1234> Error: Some files couldn't be opened
12.08.29 #       <Jungti1234> Do you know? :)
12.08.42 #       <XavierGr> mirak, no I don't have any structs. The only struct I made is the tree context struct but that is only 1struct.
12.09.05 #       <XavierGr> or do you mean structure of memory
12.09.27 #       <Bger> Jungti1234 just a sec
12.09.34 #       <Jungti1234> ok thanks
12.09.37 #       <Zak1392> what is the dictionary?
12.09.52 #       <Bger> Zak1392 a dictionary :)
12.10.01 #       <Zak1392> a word dictionary?
12.10.14 Nick    ashridah is now known as Lost-ash (n=ashridah@67.106.77.212.ptr.us.xo.net)
12.10.38 #       <XavierGr> mirak: I need only 1 array that in worst case scenario will be 10000.
12.10.58 #       <XavierGr> Instead of declaring it as static I use the get_plugin_buffer() function
12.11.06 #       <Bger> Zak1392 yes
12.11.17 #       <Zak1392> does it work for h300s?
12.11.25 #       <Jungti1234> yes
12.11.28 #       <Bger> it's a viewer
12.11.33 #       <mirak> XavierGr: what exacty you get with that method ?
12.11.37 #       <Bger> Jungti1234 according to the plugin's source
12.11.41 #       <Bger> it searches for 2 files
12.11.47 #       <Jungti1234> I know.
12.12.01 #       <Jungti1234> wn_g.pl, wn_s.pl?
12.12.17 #       <XavierGr> get_plugin_buffer(&buf_size) will return to me a pointer after the binary plugin. (I will get a pointer to the plugin buffer that is not used) and buf_size will be changed to the size of the free plugin buffer.
12.12.17 #       <Bger> .rockbox/rocks/dict.index and dict.desc
12.12.30 #       <Jungti1234> -_-; no..
12.12.46 #       <Jungti1234> I can't make 'Dict.index'.
12.12.54 #       <mirak> what means "warning: implicit declaration of function" or how to avoid it ?
12.12.56 #       <Bger> Jungti1234 why ?
12.13.00 #       <Jungti1234> It becomes error.
12.13.04 #       <XavierGr> mirak: every time I increment my pointer I make sure to reduce buf_size and then check if it is below 0.
12.13.10 #       <Zak1392> where can i download the index?
12.13.49 #       <Bger> huh :( there was wiki page about that plugin, but it is lost ... :(
12.14.00 #       <XavierGr> mirak buf_size = 0 then you have run out of plugin memory and then you need to call plugin_get_audio buffer to use the audio memory.
12.14.42 #       <mirak> I used that approach for the fake malloc
12.14.50 #       <mirak> there is no boundary verification though
12.14.53 #       <Jungti1234> I read already wiki page.
12.15.14 #       <XavierGr> buf_size is used for boundary verification.
12.15.16 #       <Jungti1234> And did along it.
12.15.35 #       <XavierGr> or do you mean something else?
12.16.11 #       <XavierGr> mirak problem is when you need 2 big buffers that you don't know exactly how big they will be.
12.16.13 #       <Bger> XavierGr afaik, buf_size is the size of the buffer
12.16.31 #       <XavierGr> of the buffer left.
12.16.32 #       <Bger> i mean, the memory you have 
12.16.37 #       <Bger> yep
12.16.59 #       <XavierGr> E.g: Plugin binary 50kb plugin (whole memory) 100kb
12.17.13 #       <XavierGr> after the call buf_size = 50kb
12.17.40 #       <mirak> ../m68k-elf/bin/ld: section .rodata [32f40000 -> 32f46ccf] overlaps section .text [32f40000 -> 32f94283]
12.17.46 #       <mirak> crap ...
12.17.51 #       <XavierGr> so if you increment your buffer array you will say: bif_size -= sizeof(you variable)
12.18.05 #       <XavierGr> (^you variable)
12.18.08 #       <XavierGr> argh
12.18.10 #       <XavierGr> ^your
12.19.43 #       <Zak1392> does anybody have the dictionary files so I can download them?
12.20.07 #       <Jungti1234> http://www.themp3players.com/archives/2005/11/cowon-iaudio-u3-cracked/
12.20.13 #       <Bger> there were some
12.21.11 #       <Jungti1234> http://www.rockbox.org/twiki/bin/view/Main/RockboxDictionary
12.21.15 #       <linuxstb> mirak: It looks like your plugin is too big.
12.21.49 #       <Rick> what the heck are you doing mirak? :P
12.21.59 #       <XavierGr> video codec I think
12.22.21 #       <Bger> hehe this PCF50606/05 is very popular :)
12.22.34 #       <Bger> also the FM tuner TEA5767
12.22.41 #       <Jungti1234> oh no.... http://www.cdpkorea.com/zboard4/data/freeboard/cdpkorea-1134651692-1.jpg
12.23.03 #       <Rick> hahahahaha
12.23.09 #       <mirak> linuxstb: can I change this limits, at least for me
12.23.10 #       <mirak> ?
12.23.25 #       <Bger> mirak yes, u can ...
12.23.26 #       <Jungti1234> and  http://www.cdpkorea.com/zboard4/data/freeboard/cdpkorea-1134651822-2.jpg
12.24.02 #       <Bger> in the corresponding config-h300.h
12.24.10 #       <Bger> (firmware/export/config-h300.h)
12.24.13 #       <linuxstb> mirak: Change PLUGIN_BUFFER_SIZE in firmware/export/config-h300.h
12.24.15 #       <Bger> there is PLUGIN_BUFFER_SIZE
12.24.37 #       <Bger> eh :)
12.24.54 #       <linuxstb> (I'm guessing you're working with a h300)
12.25.10 #       <Zak1392> does anybody have ready made dictionary files I can download?
12.27.24 #       <Bger> Zak1392 there were, but after deleting of the wiki ...
12.27.57 #       <Bger> iirc the format is pretty stright-forward
12.28.04 #       <Zak1392> does anybody have the time to upload the files? i really want to try this out now ;)
12.28.13 #       <Bger> straight
12.28.28 #       <mirak> ok it builds at least ...
12.29.38 #       <Bger> Zak1392 ask t0mas 
12.29.40 #       <mirak> well I think I will use 6 mega bytes and don't bother with the audio buffer for now
12.29.50 #       <Bger> he is plugin's author
12.30.40 #       <XavierGr> mirak what your plugin can currently do?
12.31.01 #       <mirak> it's supposed to be able to decode a file
12.31.11 #       <mirak> it's based on the exemples provided
12.31.20 #       <XavierGr> so no rendering yet?
12.31.23 #       <mirak> it should output images
12.31.29 #       <mirak> no rendering
12.31.36 #       <Jungti1234> Bger: You don't know?
12.33.29 #       <Bger> no
12.34.03 #       <Bger> hm, w8 sec
12.34.08 #       <preglow> linuxstb: i thought ipl didn't use dma
12.34.34 #       <linuxstb> The audio driver seems to
12.35.12 #       <linuxstb> Or maybe I'm misunderstanding - the functions have dma in the name, but I haven't looked at them in detail yet.
12.35.54 #       <linuxstb> And I managed to stop my "dummy" audio driver working when I cleaned it up for CVS...
12.36.15 #       <XavierGr> now I will perform a test with 6'776 files!
12.36.40 #       <Bger> so, to make dictionary files, you use tools/rdf2binary
12.36.49 #       <Bger> i'm reading the source now
12.36.53 #       <Jungti1234> ok
12.37.50 #       <Bger> so, the input format is 
12.38.09 #       <Bger> "word<tab>description"
12.38.17 #       <Jungti1234> tab?
12.38.18 #       <Bger> where <tab> = tab character
12.39.31 #       <Bger> and, afaik, they should be sorted 
12.40.32 #       <Bger> so
12.40.40 #       <Bger> the procedure is 
12.41.40 #       <Bger> 1) create file with all words in it in the format <word><tab><meaning><newline><word2><tab><meaning2><newline>
12.41.44 #       <Bger> etc
12.41.58 #       <Bger> 2) sort the file
12.42.33 #       <Jungti1234> hmm
12.42.40 #       <linuxstb> preglow: I've just fixed the audio code - dummy playback should now be working.
12.43.24 Quit    actionshrimp (Read error: 110 (Connection timed out))
12.44.18 #       <preglow> goodie good good
12.44.29 #       <preglow> i just got three tons of equipment to set up in here, so i'll be busy for at least an hour
12.45.12 #       <Bger> wow
12.45.44 #       <Bger> 3) save it as dict.preparsed
12.46.21 #       <Bger> 4) run the rdf2binary
12.47.06 #       <Jungti1234> T.T Bger...
12.47.33 #       <Bger> 5) copy dict.index and dict.desc to your iriver in the .rockbox\rocks directory
12.47.37 #       <Jungti1234> It is difficult that make all words to file.
12.47.46 #       <Bger> yeah, i know
12.47.54 #       <Bger> btw, it doesn't support unicode (yet)
12.49.17 Quit    edx (Read error: 110 (Connection timed out))
12.51.04 #       <Jungti1234> -_-;;;
12.53.43 Join    webguest63 [0] (n=414a01b0@labb.contactor.se)
12.55.11 Join    nathanh [0] (n=wosjowj@220-245-216-23-act-pppoe.tpgi.com.au)
12.55.14 #       <XavierGr> ok here is the latest jpeg file scroller anyone wants to take a peek and comment it?
12.55.16 #       <XavierGr> https://sourceforge.net/tracker/?func=detail&aid=1266294&group_id=44306&atid=439120
12.55.32 #       <webguest63> with shuffle mode selected, why aren't new additions to the playlist shuffled ?
12.56.07 #       <XavierGr> OMG now that I think of it I am working for this 5 months
12.56.24 #       <XavierGr> (not continuously but I started in August)
12.56.36 #       <webguest63> starting with a clean playlist, the first entry into playlist is shuffled, but thereafter not, is this how it should be ?
12.58.56 Join    Weazel_ [0] (n=kweetnie@cc126458-a.frane1.fr.home.nl)
12.59.14 Join    Kaggen [0] (n=kaggen@nl-67-224.netlogon.liu.se)
13.01.45 Quit    webguest63 ("CGI:IRC (Ping timeout)")
13.07.58 Quit    Zak1392 ()
13.10.35 Join    Febs [0] (i=Febs@dhcp64-134-210-122.hfwsf.sjc.wayport.net)
13.10.41 Join    petur [0] (n=d4efd6a6@labb.contactor.se)
13.11.25 Quit    ehntoo ("Leaving")
13.11.51 #       <petur> Bger: yesterday you said the H300 didn't exactly hang when you tried enabling recording. Mine does when I try ;)
13.12.00 Join    frederic_ [0] (n=chatzill@i577B922C.versanet.de)
13.12.04 Quit    frederic_ (Client Quit)
13.12.22 #       <petur> maybe it's do to with me using gcc 4.0.2
13.15.56 ***     Saving seen data "./dancer.seen"
13.16.20 #       <Jungti1234> ok. Thanks Bger :)
13.16.54 #       <Bger> petur are you sure ?
13.17.06 #       <petur> yep
13.17.15 #       <Bger> hm, i'm using 3.4.4
13.17.22 #       <Bger> mine... hm
13.17.29 #       <petur> didn't respond to anything
13.17.43 #       <Bger> it responded to keypresses in the meaning of backlight turning on
13.17.56 #       <Bger> and it did hard shutdown
13.18.12 #       <petur> my backlight stayed on... wait, let me try that again
13.18.12 Join    edx [0] (i=edx@p54A87CCA.dip.t-dialin.net)
13.18.23 #       <Bger> (rb waits for 8 secs after initiating the shutdown, and after that powers off)
13.18.34 #       <mirak> the plugin source files in a plugin/plug_folder , I have some problems building it 
13.18.40 Ctcp    Ignored 1 channel CTCP requests in 0 seconds at the last flood
13.18.40 #       * petur already grabs his paperclip
13.18.46 #       <mirak> the plugin source files are in a plugin/plug_folder , I have some problems building it 
13.19.18 #       <mirak> I have problems with using make stuffs
13.19.43 #       <petur> you're right, it still turns off the backlight
13.19.54 #       <petur> had the timeout too big
13.20.00 #       <Bger> and after that turns it on on keypress
13.20.11 #       <petur> it does
13.20.32 #       <petur> but nothing else
13.20.58 #       <Bger> press the "stop" key enough time to turn off
13.21.16 #       <petur> will have a go at it tonight if I get the time
13.21.24 #       <Bger> oki
13.21.29 #       <petur> hehe, that worked too
13.21.39 #       * petur puts paperclip away
13.21.44 #       <Bger> hehe:)
13.22.16 #       <Bger> btw i don't know how is it with h300s, but h100's reset pin is easy to broke
13.23.05 #       <petur> I'll be carefull then... I get the feeling I'll be needing it
13.23.08 #       <Bger> so i use a toothpick
13.23.22 #       <Bger> hehe for sure
13.23.53 #       <petur> got to go, work calls...
13.23.57 #       <Bger> oki
13.24.01 Quit    petur ("CGI:IRC 0.5.7 (2005/06/19)")
13.24.20 #       <mirak> undefined references to some function
13.24.50 #       <mirak> I tryed to like for other plugins
13.24.53 #       <mirak> to do
13.25.33 #       <linuxstb> Are the undefined references xvidcore functions or general system functions?
13.25.46 #       <mirak> that's xvidcore function
13.26.12 #       <mirak> seems it doesn't try to make the sources in the folder
13.26.42 #       <mirak> I have put the header to the codec
13.26.47 #       <mirak> in include
13.27.01 #       <mirak> seems it's not enough
13.27.35 #       <linuxstb> You should copy one of the other multi-file plugin Makefiles - such as databox/Makefile and change the SRC line in there to include all the .c files in xvidcore and your main plugin file.
13.27.38 #       <mirak> I though headers were chain loading themselves
13.27.51 #       <mirak> well I did that
13.28.12 #       <linuxstb> Headers don't affect the linking.
13.28.37 #       <linuxstb> So you have a subdirectory in apps/plugins with the xvidcore code and your plugin code and a Makefile?
13.28.38 #       <mirak> http://paste.ubuntu-nl.org/5819
13.28.48 #       <mirak> yes
13.29.05 #       <mirak> I tried to put the plug file into /plugins/
13.29.14 #       <mirak> but that's the same
13.29.16 #       <linuxstb> And you modified apps/plugins/Makefile to add the name of your subdirectory to SUBDIRS ?
13.29.38 #       <Bger> mirak see the databox 
13.29.45 #       <markun> or rockboy
13.29.45 #       <Bger> or searchengine's makefiles
13.30.14 #       <mirak> I have a run cvs update it probably removed it
13.30.31 #       <linuxstb> No, cvs update wouldn't undo any of your local changes
13.30.46 #       <linuxstb> Did you add anything to apps/plugins/SOURCES ?
13.32.09 #       <mirak> I addes ./xvid/xvidplug.c
13.32.13 #       <mirak> I added ./xvid/xvidplug.c
13.32.25 #       <linuxstb> That was a mistake - you shouldn't change SOURCES
13.32.42 #       <mirak> du no somebody told me to change it
13.32.47 #       <mirak> mmm
13.33.11 #       <linuxstb> SOURCES is just for single-file plugins.  For multi-file plugins, you use SUBDIR in the Makefile.
13.34.52 Join    San [0] (n=test@213-202-145-65.bas502.dsl.esat.net)
13.35.05 Join    Mmmm [0] (n=mscarrat@cpc4-hem13-3-1-cust63.lutn.cable.ntl.com)
13.38.18 #       <Jungti1234> hehehe
13.38.18 #       <Jungti1234> http://cafefiles.naver.net/data10/2005/12/16/208/h300-rtc.jpg
13.39.49 #       <mirak> linuxstb: I think I must change all the memset to rb->memset . I am not sure what is the good approach. I was about to do #define memset rb->memset , but I wonder how global the rb variable can be
13.40.28 #       <Bger> wow Jungti1234 only if i understood anything below the statusbar :)
13.40.48 #       <Jungti1234> :)
13.41.21 #       <mirak> if I put rb not as static, will it interfer with rest of the programm ?
13.42.36 #       <linuxstb> In a .h file that is included in all the xvidcore .c files, you need to put "extern struct plugin_api* rb" and "#define memset rb->memset"
13.42.37 #       <Bger> mirak why don't write something like extern struct plugin_api rb
13.42.52 #       <linuxstb> You then also need to make sure that rb is defined as a global variable in your main plugin.c file
13.42.54 #       <Bger> and also remove the static before the define
13.43.16 #       <linuxstb> Bger: :)
13.43.20 #       <mirak> ok
13.43.22 #       <Bger> linuxstb :)
13.43.34 #       <Bger> ok, i can't be better than native english speaker :)
13.44.30 #       <linuxstb> You should probably do the same with memcpy - to use the optimised Rockbox version.
13.46.44 #       <preglow> definitely
13.47.46 #       <mirak> yeah I will use all of them
13.47.50 #       <linuxstb> mirak: You also need to include <plugin.h> in the header file before you use struct plugin_api
13.56.33 #       <Jungti1234> B3205346686
13.56.33 #       <linuxstb> preglow: Does the line selector bar flicker when you move it on the Nano?
13.58.29 #       <preglow> flicker how?
13.59.04 #       <preglow> i think it looks just fine
13.59.19 Quit    San (Read error: 110 (Connection timed out))
13.59.42 #       <linuxstb> It seems that a button press interferes with the LCD update.  So if I move it one position, it moves cleanly, but if I'm moving it two or three positions (i.e. button presses are still happening during the first redraw), it flickers.
14.00.39 #       <preglow> well, the lcd update probably takes bloody ages, so small wonder
14.00.47 #       <preglow> the interrupt handler does a small udelay
14.05.07 #       <Jungti1234> Bger
14.08.05 #       <Bger> yes?
14.10.04 #       <Bger> hm, i need little help
14.10.08 #       <linuxstb> preglow: Would you be happy if we removed the IPOD_NANO_PAD define, and just used IPOD_4G_PAD ?
14.10.23 #       <linuxstb> I'm assuming your driver is identical for both.
14.10.38 #       <preglow> not much use for the nano define, no
14.10.44 #       <preglow> so at least i wouldn't mind it
14.11.08 #       <linuxstb> OK, I'll do that sometime after you commit your button driver, unless you do it first.
14.11.13 #       <Bger> could someone of you see the ipod/h300's lcd controller's datasheet (available in the wiki) and look at page 51?
14.11.15 #       <preglow> we'll see
14.12.32 #       <mirak> char tmp[256]; memset(tmp, 0, 256);    there is this error : error: dereferencing pointer to incomplete type
14.13.00 Quit    Febs (Read error: 113 (No route to host))
14.13.03 #       <mirak> the memset is postprocessed as rb->memset(tmp, 0, 256);
14.13.09 #       <linuxstb> If you have #defined memset to be rb->memset, then it doesn't understand the type of rb
14.13.25 #       <linuxstb> Have you included plugin.h ?
14.13.41 #       <linuxstb> And also done the "extern struct plugin_api* rb"
14.14.08 #       <Bger> and remove the static word before declaring rb ...
14.14.33 #       <mirak> http://paste.ubuntu-nl.org/5820
14.14.35 Join    amar [0] (i=user@80-44-103-237.dynamic.dsl.as9105.com)
14.14.43 #       <mirak> I removed static like you said
14.15.09 #       <mirak> #include "../rb_api.h" 
14.15.21 #       <mirak> I put this line in the file that says the error
14.15.21 #       <Bger> hm
14.15.36 #       <linuxstb> Does the compiler give any other warnings?  
14.16.16 #       <Bger> hm, w8
14.16.19 #       <mirak> http://paste.ubuntu-nl.org/5821
14.16.24 #       <Bger> what's the name of this file ?
14.16.36 #       <mirak> Bger: check the pastebin
14.16.39 #       <Bger> that  "#include <plugin.h>
14.16.45 #       <preglow> man, this performance can't be for real
14.17.30 #       <mirak> Bger: "../rb_api.h"
14.17.36 #       <Bger> mirak change that _PLUGIN_H_
14.17.37 #       <Bger> or
14.17.37 #       <linuxstb> preglow: I hope not.
14.17.55 #       <preglow> wav files should _fly_
14.17.56 #       <preglow> they don't
14.18.04 #       <Bger> one of the first lines of plugin.h checks for exactly the same define
14.18.17 #       <linuxstb> preglow: They fly for me.  But maybe it's the disk reading slowing it down.
14.18.29 #       <mirak> Bger: oh sorry I am stupid I forgot to change it
14.18.29 #       <preglow> well, they're fast here
14.18.34 #       <preglow> but not as fast as i would have thought
14.18.54 #       <linuxstb> By fly, I mean they are about 400% realtime.
14.19.06 #       <mirak> Bger: I just pasted ...
14.19.16 #       <preglow> linuxstb: that doesn't qualify
14.19.24 #       <preglow> i also get 400% realtime, but that's nothing
14.19.30 #       <preglow> hmm
14.19.36 #       <preglow> rockbox sometimes reboots here
14.19.36 #       <Bger> mirak ?
14.19.48 #       <preglow> ogg playback is faster than realtime here
14.19.55 #       <preglow> mp3 playback is about realtime
14.20.09 #       <mirak> Bger: I pasted the ifdef strcutre but forgot to change to the appropriate name
14.20.12 #       <linuxstb> Mmm.  Strange.  So it seems there is more going on than I thought.
14.20.32 #       <linuxstb> I could do with someone that understands the pcm_playback.c code to look at the ipod version.
14.20.43 #       * preglow summons the mighty Slasheri
14.20.51 #       <Bger> mirak oh, never mind :)
14.20.54 Quit    einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
14.21.32 Join    webguest79 [0] (n=3efc4010@labb.contactor.se)
14.22.07 #       <linuxstb> preglow: You are doing a lot of summoning
14.22.17 #       <preglow> lots of questions merits lots of summoning
14.22.20 #       <Bger> please, let someone look at www.rockbox.org/twiki/pub/Main/DataSheets/e789r_101.pdf
14.22.27 #       <Bger> page 51
14.22.30 #       <preglow> plus, my summing skills have rusted a bit, obviously
14.22.35 #       <preglow> summoning...
14.22.41 #       <linuxstb> LinusN?
14.22.59 #       <_FireFly_> Bger: what should be on page 51 ??
14.23.13 #       <linuxstb> Bger: Are you talking about power-saving?
14.23.41 #       <Bger> i just want to understand what does the text about (for example) VDV4-0 mean
14.23.51 Quit    webguest91 ("CGI:IRC (Ping timeout)")
14.24.03 #       <preglow> linuxstb: it still locks on some disk accesses here :/
14.24.18 #       <linuxstb> I get the same - it's very unstable at the moment.
14.24.29 #       <Bger> does it mean that we have 32 steps between 0.6 and 1.23 
14.24.37 #       * linuxstb summons someone that understands the ATA code
14.24.40 #       <Bger> (5 bits, 2^5)
14.25.11 #       <Bger> so i must divide (1.23-0.6)/32 for a step ?
14.25.40 Quit    webguest79 (Client Quit)
14.25.53 #       <preglow> linuxstb: both mp3 and ogg are most definitely realtime here
14.26.04 #       <preglow> mp3 even at 230kbps
14.26.30 #       <Bger> 230 or 320:)
14.26.33 #       <linuxstb> That's good news then.  
14.26.47 #       <preglow> what i wrote
14.26.59 #       <linuxstb> Is that with the ARM opts I enabled?
14.27.07 #       <preglow> it's with whatever you commited
14.27.17 #       <linuxstb> OK, so yes.
14.27.25 #       <linuxstb> (assuming that worked)
14.28.06 Join    elinenbe_ [0] (i=trilluse@207-237-225-224.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com)
14.28.06 Quit    elinenbe (Read error: 104 (Connection reset by peer))
14.28.12 #       <linuxstb> preglow: How about AAC?
14.28.12 Nick    elinenbe_ is now known as elinenbe (i=trilluse@207-237-225-224.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com)
14.30.51 #       <preglow> i need to copy some first
14.30.52 #       <preglow> gimme a sec
14.31.12 #       <LinusN> linuxstb: what do you want to know about the ata code?
14.31.13 #       <Bger> linuxstb ?
14.31.21 #       <Bger> ah, LinusN :)
14.31.40 #       <Bger> could you help me ?
14.32.06 #       <LinusN> with what?
14.32.13 #       <Bger> see above, pls
14.32.22 #       <Bger> the lcd controller datasheet, page 51
14.32.24 #       <preglow> oh, joy to the world
14.32.26 #       <preglow> usb1.1
14.32.58 Quit    Weazel_ ()
14.36.20 #       <preglow> haha, what the hell
14.36.24 #       <preglow> the mic amp's got a fan
14.36.33 #       <preglow> oh well
14.36.49 #       <linuxstb> LinusN: I would just like somebody to look at the ipod version and tell me if there is something obvious that I've missed.
14.37.23 #       <linuxstb> Disk access seems to work, but also seems unreliable.
14.37.31 #       <linuxstb> If that makes sense :)
14.37.43 #       <LinusN> Bger: as i understand it, each bit of the R, G or B component has its own voltage regulator, that adds to the final intensity of the pixel
14.37.48 #       <preglow> i've gutted the ipl button driver completely
14.38.13 #       <preglow> now it's at least starting to look presentable
14.38.25 #       <LinusN> linuxstb: it doesn't work?
14.38.38 #       <preglow> it works sporadically
14.38.43 #       <preglow> sometimes it seems to just hang when accessing
14.38.53 #       <LinusN> oh
14.39.33 #       <LinusN> preglow: does it have support for IORDY?
14.39.44 Quit    _FireFly_ ("IceChat - what the cool people use")
14.40.04 #       <preglow> ask linuxstb, i have no idea
14.40.23 #       <preglow> it's probably very hard to see from the ipl sources...
14.40.41 #       <preglow> where such a thing as iordy might very well be called 0xf3459328
14.40.48 #       <linuxstb> In the disk info, it says "IORDY support: yes" and "IORDY disable: yes"
14.40.59 #       <linuxstb> (in the debug menu)
14.41.19 #       <preglow> and you're sure the function getting that info is correct?
14.41.37 #       <LinusN> linuxstb: i mean if the ata *controller* supports iordy
14.42.02 #       <linuxstb> LinusN: I don't know.
14.42.12 #       <LinusN> one possible cause of a hang could be that you enable iordy in the controller, but the iordy signal isn't connected
14.42.15 Quit    Mmmm ()
14.42.34 #       <LinusN> do you know how "hard" the hang is?
14.42.44 #       <LinusN> does the cpu halt completely?
14.42.52 Join    Mmmm [0] (n=mscarrat@cpc4-hem13-3-1-cust63.lutn.cable.ntl.com)
14.42.54 #       <preglow> it easily might
14.42.57 #       <preglow> the backlight never turns of
14.42.58 #       <preglow> f
14.44.06 #       <Slasheri> preglow: hi :)
14.44.25 #       <preglow> why, good day
14.44.41 #       <mirak> motion/estimation_pvop.c:798: error: conflicting types for 'MotionEstimation'
14.44.41 #       <mirak> motion/motion.h:62: error: previous declaration of 'MotionEstimation' was here
14.44.53 #       <mirak> conflicting types 
14.45.04 #       <Slasheri> preglow: you summoned me ;)
14.45.14 #       <mirak> I don't see why I got that now and not on the PC build
14.45.34 #       <preglow> Slasheri: yeah, linuxstb was looking for someone who understood the pcm_playback.c code
14.45.35 #       <Slasheri> linuxstb: the pcm_playback driver should be easy to do to communicate with the pcmbuf properly
14.45.41 #       <Slasheri> yes
14.45.56 #       <Slasheri> it just needs to generate the callbacks when it needs more data
14.46.28 #       <mirak> I got a dupe
14.46.36 #       <mirak> seems the preprocessor asn't done is jobe
14.47.02 #       <linuxstb> Slasheri: I think that's the problem - I'm probably not callling get_more() enough.
14.47.29 #       <linuxstb> Could you have a quick look at the CVS version of pcm_playback.c and let me know how I can make it empty the PCM buffer as quickly as the codecs can fill it?
14.47.40 #       <Slasheri> ah. Hmm, please check also the simulator audio code. It should be quite simplified pcm_playback driver
14.47.58 #       <preglow> i wonder what in the nano's making the sound...
14.48.30 #       <Slasheri> linuxstb: sure, just a moment. I will have a quick look on it (have to go to bus soon)
14.48.30 #       <preglow> linuxstb: aac might be realtime
14.48.32 Join    DrumRBoy320|away [0] (n=Drumrboy@ool-44c20ff1.dyn.optonline.net)
14.48.40 #       <linuxstb> preglow: That's what I thought...
14.49.22 #       <preglow> linuxstb: why?
14.49.49 #       <Slasheri> linuxstb: you should empty the buffer on so that the hardware pcm buffer keeps full all the time
14.50.24 #       <linuxstb> preglow: I don't know...
14.50.27 #       <preglow> man, wavpack flies
14.50.51 #       <Slasheri> linuxstb: so you should call the get_more always when there is free space on the hardware buffer, or on dma request
14.51.47 #       <preglow> oh, how i long for the time we'll try to support pp5002
14.51.48 #       <preglow> ...
14.51.54 #       <Slasheri> linuxstb: oh, i looked the wrong commit.. :)
14.54.19 #       <Slasheri> linuxstb: hmm, seems like you need to enable the dma..
14.54.50 #       <LinusN> linuxstb: is the ipod ata code in cvs?
14.54.54 #       <Slasheri> and i think it could be a good idea completely separate the uda and wm8975 driver if they are very different
14.55.20 #       <preglow> LinusN: yeah
14.55.47 #       <Slasheri> linuxstb: the driver/hardware should run the pcm buffer and request data always when it needs to
14.56.38 #       <linuxstb> Slasheri: I just wanted to do a dummy driver for now so we can see how fast the codecs are working.
14.56.54 Join    Weazel_ [0] (n=kweetnie@cc126458-a.frane1.fr.home.nl)
14.57.05 #       <linuxstb> Is that possible without a lot of work?
14.57.11 #       <Slasheri> ah! Hmm.
14.57.23 #       <LinusN> linuxstb: i don't see anything suspicious in the ipod ata driver
14.57.26 #       <Slasheri> should be. Then you should prevent running the pcm buffer completely empty
14.57.50 #       <Slasheri> you could somehow check with the pcmbuf.c call pcmbuf_is_lowdata() and if true, wait a bit
14.58.00 #       <linuxstb> LinusN: Is there anything I can do to test your IORDY theory?
15.02.42 #       <linuxstb> Slasheri: Why is it a bad thing for the pcm buffer to become empty when I want to let the codecs decode as fast as they can?
15.05.46 #       <LinusN> linuxstb: you can try to disable iordy with the SET_FEATURES command
15.06.59 #       <LinusN> linuxstb: in the set_features() function, change:
15.07.08 #       <LinusN>         { 83, 14, 0x03, 0 },   /* force PIO mode */
15.07.10 #       <LinusN> to:
15.07.55 #       * Bagder makes a drum roll...
15.07.56 #       <LinusN>         { 83, 14, 0x03, 1 },   /* force PIO mode without IORDY */
15.08.57 #       <preglow> musepack doesn't play at all...
15.09.02 #       <preglow> probably my budggy opts
15.10.31 #       <mirak> there is a portab.h file in xvid source with a bunch of #defines depending on arch. maybe one could look at it and correct some things
15.10.32 #       <linuxstb> LinusN: Trying now.  Thanks.
15.10.33 #       <mirak> http://paste.ubuntu-nl.org/5822
15.10.51 Quit    tvelocity ("Leaving")
15.10.58 #       <mirak> It's about type depending on the compilator
15.12.24 #       <Bagder> doesn't look like it needs any adjustments
15.13.18 Quit    Mmmm ()
15.14.07 #       <linuxstb> preglow: Can you test the change Linus suggested?  I'm not sure, but I think it might have done the trick.
15.14.12 #       <preglow> ok
15.14.37 #       <markun> mirak: things can be removed and you can do #define read_counter rb->current_tick I think
15.15.58 ***     Saving seen data "./dancer.seen"
15.16.22 #       <mirak> CACHE_LINE is the bus size to do alignements
15.16.30 #       <mirak> I used 32 bits
15.16.35 #       <preglow> plugin still gives me a blank screen here
15.16.45 #       <mirak> if it's this ...
15.17.12 #       <linuxstb> preglow: I'm only getting that with bejeweled.  Other plugins seem to be working reliably.  But it may just have been luck
15.17.30 #       <preglow> lemme see
15.18.16 #       <preglow> why does starfield only sometimes have stars at all? :>
15.19.22 #       <preglow> nah, cube fucks up and snow does as well
15.19.30 #       <preglow> so plugins are definitely not working any more than before here
15.21.14 #       <preglow> can't seem to get other disk accesses to lock up, though
15.21.19 #       <markun> mirak: Yes, I think you did it correct like that
15.24.32 Quit    Jungti1234 (Read error: 110 (Connection timed out))
15.24.35 #       <linuxstb> preglow: I've got to run now, I'll investigate the IPL source a little more this evening.
15.24.49 #       <linuxstb> Let me know if you think Linus's change improves things.
15.25.09 #       <preglow> yea
15.27.32 Quit    DrumRBoy320|away (Read error: 110 (Connection timed out))
15.46.43 Join    muesli- [0] (n=muesli_t@141.71.4.220)
15.52.01 #       <mirak> motion/estimation_pvop.c:798: error: conflicting types for 'MotionEstimation'
15.52.01 #       <mirak> motion/motion.h:63: error: previous declaration of 'MotionEstimation' was here
15.52.30 #       <Bagder> make them identical
15.52.37 #       <mirak> the types match already
15.52.51 #       <Bagder> so the compiler is wrong?
15.52.59 #       <mirak> I was wondering if postprocesser was doing some stuff
15.53.09 #       <mirak> that's why I showed portab.h
15.53.10 #       <Bagder> you mean preprocessor
15.53.17 #       <mirak> pre
15.53.23 #       <Bagder> then run only that and see
15.53.30 #       <Bagder> use gcc's -E option for that
15.55.36 #       <mirak> how ?
15.55.39 #       * Bger never has known that LCD controller is such complicated beast ...
15.56.36 #       <mirak> I added it to c flags of the make
15.58.48 #       <mirak> the prototype match the definition
15.59.28 #       <Bagder> so you're saying gcc is drunk then?
15.59.47 #       <Slasheri> linuxstb: because then audio will stop if the buffer gets empty and restart again after few chunks are buffered
16.01.29 #       <mirak> Bagder: maybe I can send you the tar and you debug it for me
16.02.44 #       <Bagder> nah, I don't have time now. Gonna leave soon. I could have a peek later tonight perhaps
16.11.21 Part    amar
16.13.23 #       <mirak> is there an equivalent to scanf ?
16.13.23 Quit    nathanh (Read error: 104 (Connection reset by peer))
16.13.43 #       <Bagder> no
16.15.34 #       <amiconn> LinusN, linuxstb: Afaik, the 'force PIO without IORDY' will only work for disks which support IORDY disable
16.16.15 Quit    muesli- ("ich will Kühe!!!")
16.16.57 #       <mirak> Bagder: how would you translate that  sscanf(tmp, "XviD%dC", &dec->bs_version); ?
16.17.51 #       <Bagder> get all digits between the D and the C
16.18.04 #       <Bagder> and make an atoi() on them
16.18.49 #       <LinusN> amiconn: yes, of course
16.20.05 Join    _FireFly_ [0] (n=FireFly@p54A4624B.dip.t-dialin.net)
16.23.31 #       <mirak> Bagder: here sscanf scans the full buffer tmp until it matches Xvid%dC ?
16.24.03 #       <Bagder> no
16.24.15 #       <mirak> it scans from the start of tmp
16.24.21 #       <Bagder> yes
16.24.32 #       <mirak> ok so that's not that hard to emulate
16.24.58 Quit    georgeblunt (" HydraIRC -> http://www.hydrairc.com <- The dawn of a new IRC era")
16.25.18 #       <mirak> Bagder: is it possible to extend the rockbox library of functions ?
16.25.31 #       <Bagder> in fact, you can probably get away with !memcmp(tmp, "Xvid") and then do atoi() on tmp+4
16.25.42 #       <Bagder> mirak: of course
16.26.03 #       <Bagder> mirak: these libc style functions are in firmware/common/
16.26.06 #       <mirak> yes but it needs to stop after %d
16.26.19 #       <Bagder> atoi() only scans decimal digits
16.26.24 #       <mirak> great
16.26.50 #       <_FireFly_> atoi stops when it founds a non decimal character
16.27.46 #       <mirak> ok, I don't know how undefined parameters are handled by C though
16.28.06 #       <Bagder> undefined?
16.28.11 #       <Bagder> they can't be 
16.28.20 #       <mirak> unfinite
16.28.25 #       <mirak> infinite
16.28.35 #       <Bagder> an inifinite parameter?
16.28.40 #       <mirak> scanf(bla,blab, ... )
16.28.49 #       <Bagder> you mean the ... concept?
16.28.53 #       <mirak> yeah
16.28.55 #       <_FireFly_> that is done via va_lists
16.29.08 #       <Bagder> mirak: check the printf() code etc
16.29.24 #       <_FireFly_> yepp
16.29.31 #       <mirak> that's what I was looking for
16.29.35 #       <mirak> is it in rockbox
16.29.36 #       <mirak> ?
16.29.49 #       <Bagder> "mirak: these libc style functions are in firmware/common/"
16.29.59 #       <mirak> yes, but I don't see printf
16.30.01 #       <Bagder> see sprintf.c
16.30.13 #       * Bagder runs off
16.30.14 #       <mirak> ah my eyes ...
16.30.22 #       <Bger> time to say moo? :))))))))
16.30.30 #       <_FireFly_> moep :)
16.30.53 #       <mirak> but I must then add it to the api ?
16.33.46 #       <mirak> ok I will not do that it's to complicated
16.34.25 #       <mirak> pfff
16.37.40 #       <mirak> ok %d is just one digit
16.37.43 #       <mirak> ?
16.37.53 #       <mirak> that simplifies things a lot then
16.37.54 Quit    z35 (Read error: 110 (Connection timed out))
16.38.28 #       <_FireFly_> mirak: it doesn't matter when using atoi or miss i something ?
16.38.51 #       <mirak> i = sscanf(tmp, "DivX%dBuild%d%c", &version, &build, &packed);
16.39.12 #       <mirak> the problem is I need to now the size in characters of %d
16.39.21 #       <_FireFly_> ??
16.39.36 #       <mirak> well we want to %d
16.39.49 #       <_FireFly_> to what ??
16.39.58 #       <mirak> get !
16.40.12 #       <mirak> so the first one is easy
16.40.36 #       <_FireFly_> the second also :)
16.40.37 #       <mirak> if we give to atoi   char[4] to skip Xvid
16.40.51 #       <mirak> _FireFly_: how do you do that ?
16.41.35 #       <mirak> with a for and trying to check if next character  is not a digit
16.41.37 #       <_FireFly_> simply combine with sprintf the Xvid nad the fetched first number and then use strlen 
16.41.46 #       <_FireFly_> or so
16.42.11 #       <mirak> what ?
16.42.46 #       <mirak> I don't see how you do that
16.42.52 Part    LinusN
16.42.54 #       <_FireFly_> sprintf(buf,"DivX%d",number); where number iid the first number which you got
16.43.21 #       <mirak> mmm
16.43.22 #       <_FireFly_> then an strlen(buf) gives you the new position 
16.43.23 #       <mirak> :)
16.43.42 #       <_FireFly_> plus the numbers of chars for Build :)
16.43.44 #       <mirak> yeah that's nice
16.44.15 #       <_FireFly_> sprintf(buf,"Divx%dBuild",number);
16.44.30 #       <_FireFly_> then the strlen will get the position for the second number
16.44.37 #       <_FireFly_> the start position
16.51.14 Quit    akaidiota (Read error: 110 (Connection timed out))
17.00.43 Quit    Zagor ("Client exiting")
17.05.56 #       <mirak> char buf[30];
17.05.57 #       <mirak> 				version=rb->atoi(tmp[4]);
17.05.57 #       <mirak> 				rb->sprintf(buf,sizeof(buf),"Divx%dBuild",version);
17.05.57 DBUG    Enqueued KICK mirak
17.05.57 #       <mirak> 				build=rb->atoi(tmp[strlen(buf)]);
17.05.57 #       <mirak> 				rb->sprintf(buf,sizeof(buf),"Divx%dBuild%d",version,build);
17.05.57 ***     Alert Mode level 1
17.05.57 #       <mirak> 				packed=rb->atoi(tmp[strlen(buf)]);
17.06.07 #       <mirak> seems that's it
17.06.59 #       <_FireFly_> is packed really an number ??
17.07.25 #       <_FireFly_> because '<mirak> i = sscanf(tmp, "DivX%dBuild%d%c", &version, &build, &packed);' say that packed %c is
17.09.24 Join    DrumRBoy320|away [0] (n=Drumrboy@ool-44c20ff1.dyn.optonline.net)
17.09.46 #       <mirak> _FireFly_: yeah it's a caracter
17.09.47 #       <mirak> I missed
17.09.59 #       <mirak> I am glad to have flooded the channel :)
17.10.22 #       <mirak> packed=tmp[strlen(buf)];
17.10.41 #       <mirak> by the way it should be  rb->strlen
17.11.01 #       <_FireFly_> yepp  but my code was only an example :)
17.11.27 #       <mirak> hey I accuse nobody :)
17.11.57 #       <mirak> hopefully there is no other scanf
17.12.19 #       <_FireFly_> why don*t you search the source for it ??
17.13.05 #       <mirak> I said to my self that if it's not in rockbox maybe it uses some other lib
17.14.07 #       <lostlogi1x> why does "if (profiling) profilign++; else goto out;" cause profiling to be loaded two separate times into the same register on instructions separated by nothing but a conditional jump?
17.14.18 #       <amiconn> What other lib should that be? Rockbox is a 'freestanding' environment as gcc defines it
17.14.43 #       <mirak> amiconn: libs in the scanf linux source
17.15.02 #       <mirak> I don't have checked so I don't know
17.15.32 #       <_FireFly_> afaik sscanf depends on nothing other fns
17.15.36 Nick    lostlogi1x is now known as lostlogicx (n=lostlogi@node-4024215a.mdw.onnet.us.uu.net)
17.15.36 DBUG    Enqueued KICK lostlogicx
17.15.50 #       <mirak> that's in libc sources?
17.15.58 ***     Alert Mode OFF
17.16.01 ***     Saving seen data "./dancer.seen"
17.16.12 #       <_FireFly_> mirak: what do you want to say to us ??
17.16.37 #       <_FireFly_> it thought i meant that you hope that no other sscanf-call is in the xvid sources
17.16.56 #       <_FireFly_> so i said that you should search the xvid-sources about it
17.17.03 #       <mirak> there is no other scanf calls, there was only 4
17.17.27 #       <_FireFly_> <mirak> hopefully there is no other scanf << what then did you meant whith  that ??
17.17.27 #       <mirak> I though you asked me to search scanf sources in libc sources
17.17.54 #       <mirak> I though you asked me to search scanf sources in libc sources to adapt it rockbox
17.18.02 #       <mirak> to
17.18.08 #       <_FireFly_> no i didn't :)
17.28.26 Quit    DrumRBoy320|away (Read error: 110 (Connection timed out))
17.30.00 Quit    Bger (Read error: 113 (No route to host))
17.31.24 Join    Mmmm [0] (n=Mmmm@cpc4-hem13-3-1-cust63.lutn.cable.ntl.com)
17.31.40 #       <mirak> I still end on the same error
17.32.03 #       <mirak> motion/estimation_pvop.c:798: error: conflicting types for 'MotionEstimation'
17.32.03 #       <mirak> motion/motion.h:63: error: previous declaration of 'MotionEstimation' was here
17.32.03 #       <mirak> motion/estimation_pvop.c:798: error: conflicting types for 'MotionEstimation'
17.32.03 #       <mirak> motion/motion.h:63: error: previous declaration of 'MotionEstimation' was here
17.32.09 #       <mirak> I got that in a row
17.32.16 #       <mirak> the two in a row
17.33.09 #       <mirak> the prototype in motion.h really match prototype in estimation_pvop.c
17.38.45 Quit    Mmmm (" HydraIRC -> http://www.hydrairc.com <- The future of IRC")
17.50.48 Join    Mmmm [0] (n=mscarrat@cpc4-hem13-3-1-cust63.lutn.cable.ntl.com)
17.50.48 Quit    Weazel_ (Read error: 104 (Connection reset by peer))
18.01.55 #       <lostlogicx> c
18.02.16 Join    linuxstb_ [0] (n=linuxstb@213.86.218.27)
18.02.26 Ctcp    Ignored 2 channel CTCP requests in 9 minutes and 39 seconds at the last flood
18.02.26 #       * Mmmm watches the tumbleweed being blown across the street
18.03.14 #       <linuxstb_> mirak: That function using the type "IMAGE", which is defined as a struct of three "uint8_t" variables.  I'm guessing that the .h and .c files include different header files, resulting in different interpretations of uint8_t
18.04.09 #       <mirak> I removed an include of the rb api and don't have this error for now
18.05.43 #       <linuxstb_> global.h looks a mess of definitions and #ifdefs - if I was you I would delete everything from that file that you don't need.  That will stop other unexpected problems in the future.
18.06.01 Part    Kaggen
18.06.22 #       <mirak> well there is also all VMS crap and IA32 or 64 assembly
18.06.34 #       <mirak> there is really a lot of stuff that could be cleaned
18.06.44 #       <mirak> including the encoder parts
18.14.30 #       <Slasheri> ah, now dual tagcache operation seems to work. It can be accessed from disk and it's automatically loaded into ram.. really fast :)
18.16.36 #       <_FireFly_> Slasheri: dual ??
18.17.11 #       <Slasheri> _FireFly_: yes, of course. So loading the cache into ram is not necessary to use it
18.17.16 #       <Cassandra> Nice.
18.17.32 #       <_FireFly_> Slasheri: what do you mean with dual ??
18.17.38 #       <Slasheri> and if tag database can be displayed immediately after boot without waiting it to be loaded into ram
18.17.56 #       <Slasheri> _FireFly_: operating directly from disk (something like tagdb did) and without disk
18.18.05 #       <_FireFly_> ah ok
18.18.43 #       <mirak> what about #include <stdio.h>
18.18.46 #       <mirak> string
18.18.48 #       <mirak> etcetera
18.18.51 #       <mirak> I should get rid of that
18.18.57 #       <mirak> ?
18.18.59 #       <Slasheri> i think i could also add the crc thing to enable a separate runtime db
18.19.37 #       <Cassandra> Huh?
18.22.12 #       <Slasheri> tagdb stored a crc checksum of the first 32 KiB of every file to identify the files inside the database. Tag cache works little differently, but adding that crc as a separate tag should be nice way to do it
18.22.23 #       <_FireFly_> Slasheri: i have a small function for crc (ripped of from zlib-sources)
18.22.32 Nick    Lynx_ is now known as Lynx_awy (n=lynx@tina-10-4.genetik.uni-koeln.de)
18.22.33 #       <Slasheri> Then song scores can be saved to a separate file and identified with that crc instead of file name
18.22.54 #       <Slasheri> _FireFly_: hmm, sounds nice if that's small :)
18.23.11 #       <Cassandra> I think I missed something.  What's the difference between tag cache and tag db?  Is tagdb now obsolete?
18.23.14 #       <_FireFly_> afaik the biggest is the lookup-table
18.24.03 #       <Slasheri> Cassandra: tagdb is a completely another implementation to support features tagdb couldn't offer. But i wouldn't say tagdb is obsolote, at least not at the moment
18.24.05 #       <_FireFly_> Slasheri: on home.arcor.de/s.wezel there is a zip-file calld read-zip.zip
18.24.11 #       <Slasheri> *tagcache
18.24.19 #       <Slasheri> _FireFly_: i will have a look :)
18.24.30 #       <Cassandra> tagcache is still pre-generated on host, I assume?
18.24.39 #       <Slasheri> no, on the player only
18.24.47 #       <Slasheri> on background just like dircache
18.25.02 #       <Cassandra> Oh, right.
18.25.07 #       <Cassandra> Cool.
18.25.15 #       <Slasheri> and when adding new files, the tagcache is updated - not completely regenerated
18.25.37 #       <_FireFly_> Slasheri: the background-cache guru :)
18.25.41 #       <Slasheri> hehe :D
18.25.41 #       <Cassandra> So why doesn't it supercede tagdb?  What's it missing?
18.25.55 #       <Slasheri> Cassandra: it might in future, but i cannot promise that :)
18.26.51 #       <Slasheri> at least it should offer the same feature tagdb did and more (for example genre searches). But i don't have an archos so i could test how the implementation works on those players (but it should work)
18.27.51 #       <mirak> how can I remove the pointers cast warning ?
18.27.55 #       <mirak> from gcc
18.27.55 #       <Slasheri> probably i have some kind of patch to test in few days
18.28.05 #       <Slasheri> mirak: you should cast the pointers :)
18.28.08 #       <Cassandra> Good good.
18.28.26 #       <Cassandra> It's nice not to have to rely on an off-player solution.
18.28.39 #       <mirak> Slasheri: it should be ok with the cast. gcc says tons of warnings for xvid
18.28.45 #       <mirak> I don't want them
18.28.52 #       <Slasheri> ah :/
18.28.55 #       <mirak> since it works, I didn't touched it
18.28.59 #       <Slasheri> then you probably have to edit the Makefile
18.29.14 #       <Slasheri> or fix those warnings.. :)
18.30.42 #       <mirak> I don't understand why there is all this warnings, because when we make for pc there is not that much warnings
18.30.46 #       <Slasheri> _FireFly_: oh, that crc function looks great, at least it should be fast
18.30.53 #       <mirak> maybe that's the cross compiler options
18.31.01 #       <_FireFly_> there are also two examples how to use it :)
18.31.06 #       <Slasheri> hehe :)
18.31.23 #       <_FireFly_> one which makes it char by char the other uses a buffer
18.39.18 #       <preglow> Slasheri: btw, did you try to fix the problem with the glitching between track changes when skipping?
18.39.21 #       <preglow> i can't remember
18.39.36 #       <preglow> i just had it happen just now again, but it's been ages since last time
18.41.41 #       <linuxstb_> mirak: Don't ignore warnings - they are there for a reason :)
18.42.27 #       <Slasheri> preglow: Hmm, that was without crossfade?
18.43.02 #       <Slasheri> i did some fixes but that problem seems to be more difficult to reproduce/fix
18.44.30 #       <preglow> without, yes
18.44.53 #       <preglow> well, it's pretty obvious why the problem occurs, no?
18.44.55 #       <Slasheri> and that glitch happened when next track was loaded from buffer and not from disk?
18.45.01 #       <preglow> from buffer, y es
18.45.03 #       <Slasheri> no
18.45.12 #       <Slasheri> ok, then it's probably connected to the crossfade bug
18.45.29 #       <preglow> crossfade bug which happens when i don't use crossfading? :>
18.45.37 #       <XavierGr> Slasher I can confirm this too.
18.45.45 #       <XavierGr> Without crossfade it wil pop like hell.
18.45.48 #       <Slasheri> yes, some parts of the crossfade engine are always used when switching tracks in buffer..
18.45.51 #       <Slasheri> to prevent gaps
18.46.00 #       <XavierGr> can't we just stop audio right before the track changes.
18.46.07 #       <XavierGr> also I can get pops on track transitions.
18.46.11 #       <Slasheri> yes, that would be the simplest solution
18.46.20 #       <Slasheri> pops are crossfade bug
18.46.37 #       <mirak> linuxstb: I don't know how to deal with that. Like I don't know what do if there is an error, at the end but only warnings in the gcc message
18.46.58 #       <Slasheri> and i still don't know for sure what causes those bugs.. but i will investigate those
18.47.55 #       <XavierGr> It is the #1 bug in the audio aspect for me. I always hesitate to change tracks because of this
18.48.09 #       <Slasheri> oh :/
18.48.18 #       <Slasheri> the crossfade pops?
18.48.30 #       <XavierGr> without crossfade
18.49.01 #       <Slasheri> ah, that's weird.. i try to reproduce that problem soon
18.49.23 #       <XavierGr> maybe I will have to send you some recoreded samples to see.
18.49.45 #       <XavierGr> anyway have to run, later all.
18.49.49 #       <Slasheri> would be really helpful, if the problem is easily reproducable with those samples
18.49.55 #       <Slasheri> see you :)
18.50.06 #       <preglow> i wouldn't want to stop playback when the track already is in the buffer
18.50.27 #       <XavierGr> also (on a final note) while most of the times crossfade will work out fine. When you fiddle a lot with it it will just brake or don't crossfade at all
18.50.51 #       <XavierGr> fiddle = change tracks quikly just after audio started.
18.50.59 #       <Slasheri> don't crossfade at all is intended solution when buffer has not enough samples
18.51.03 #       <XavierGr> brake = pop or something like that.
18.51.14 #       <Slasheri> but those pops are not intended :)
18.51.17 #       <XavierGr> ah ok then
18.51.59 #       <XavierGr> I will see if I can get you songs that have such behaviour and maybe I will record those pops using the line out.
18.52.03 #       <XavierGr> bye
18.52.05 Part    XavierGr
18.52.09 Quit    Rob2222_ ()
18.53.38 #       <preglow> linuxstb_: will commit the button functions very soon now
18.58.52 #       <preglow> linuxstb_: i'll just remove all references to IPOD_NANO_PAD, then
19.00.49 #       <mirak> kbox/firmware/include/string.h:27: error: parse error before '->' token
19.00.58 #       <mirak> I got a problem with the #define approach
19.01.04 #       <mirak> for memset
19.01.32 #       <mirak> isn't it weird that the #define memset memset-> goes that far ?
19.01.41 #       <preglow> linuxstb_: on no, even with the iordy fix, i got a hang on trying to play a track here
19.01.50 #       <preglow> and
19.02.01 #       <_FireFly_> mirak: #define memset memset-> ??
19.02.12 #       <mirak> _FireFly_: mmm ?
19.02.23 #       <linuxstb_> mirak: Don't include string.h
19.02.26 #       <Slasheri> eh, that couldn't work..
19.02.33 #       <_FireFly_> Slasheri: ;)
19.02.33 #       <preglow> linuxstb_: could you test a build before i commit?
19.02.49 #       <linuxstb_> Sorry, my iPod is at home, and I'm not.
19.03.06 #       <_FireFly_> mirak: i think you mean #define memset rb->memset don't you  ??
19.03.10 #       <linuxstb_> And I'm about to visit the beer shop for the evening.
19.03.46 #       <preglow> i want to go back to the pub :/
19.04.15 #       <linuxstb_> No, you must stay and code
19.04.36 #       <preglow> don't think i'll bother going down alone anyway
19.06.05 #       <linuxstb_> Well, have a good evening whatever you do.  I'll check the logs tonight, so let me know if you want me to test a build before you commit.
19.06.06 #       <linuxstb_> Later.
19.06.10 #       <preglow> nah
19.06.10 Quit    linuxstb_ ("Leaving")
19.06.12 #       <preglow> i'll just commit
19.06.44 Join    perplexity [0] (n=joust@217.165.115.94)
19.06.48 #       <preglow> it's not like the intended audience (you and me) are going to shoot me if it fails anyway
19.06.51 #       <preglow> that is, i might shoot myself
19.07.09 #       <_FireFly_> :)
19.10.08 Join    DrumRBoy320|away [0] (n=Drumrboy@ool-44c20ff1.dyn.optonline.net)
19.16.04 ***     Saving seen data "./dancer.seen"
19.26.02 #       <preglow> god damn
19.26.28 #       <preglow> i find out _NOW_ that non-phixion is playing here in bloody two hours
19.26.35 #       <preglow> commit will have to wait, later all
19.28.05 #       <mirak> _FireFly_: yes sorry
19.28.11 #       <mirak> va_start(args, fmt);
19.28.11 #       <mirak> 	vsprintf(buf, fmt, args);
19.28.11 #       <mirak> 	va_end(args);
19.28.20 #       <mirak> that vsprintf is bothering me
19.28.34 #       <mirak> by what can I replace it ?
19.31.36 #       <_FireFly_> vsnprintf ?? ;)
19.33.20 #       <Mmmm> who're non-phixian??
19.33.54 #       <Slasheri> Hmm, seems that the fs readwrite routine is still quite buggy with read & write..
19.35.33 Join    Rob2222 [0] (n=Miranda@ACB198DB.ipt.aol.com)
19.36.24 #       <mirak> _FireFly_: there is no vsnprintf in the api
19.37.15 #       <_FireFly_> sprintf.c ??
19.37.26 #       <_FireFly_> ;)
19.37.53 #       <_FireFly_> but it could that this fn  is missing in the plugin-api struct
19.37.57 #       <_FireFly_> could be
19.38.03 #       <Maxime`> what's the difference between 'sprintf' and 'snprintf' ? oO
19.38.17 #       <Slasheri> Maxime`: snprintf takes the buffer size
19.38.26 #       <_FireFly_> :)
19.38.34 #       <Maxime`> ok
19.38.34 #       <Slasheri> so you should use it always, unless you are absolutely sure the can't be a buffer overflowing
19.38.45 #       <Maxime`> thx
19.38.47 #       <Slasheri> *there
19.42.50 Quit    ze (Read error: 110 (Connection timed out))
19.44.47 #       <mirak> _FireFly_: I added the method the the structure api
19.44.57 #       <mirak> I don't need to initialise it ?
19.45.06 #       <_FireFly_> afaik not
19.45.15 #       <_FireFly_> or what do you mean
19.45.26 #       <mirak> I added the type to the api struct
19.45.33 #       <mirak> in plugin.h
19.46.01 #       <_FireFly_> then you need to initialise it in plugin.c
19.46.04 #       <mirak> _FireFly_: but shouldn't it be initialised or sometinh ?
19.46.55 #       <_FireFly_> ^^
19.46.56 #       <mirak> ok got it
19.46.58 Quit    Mmmm ()
19.48.00 Join    Mmmm [0] (n=mscarrat@cpc4-hem13-3-1-cust63.lutn.cable.ntl.com)
19.51.37 #       <mirak> _FireFly_: it doesn't work
19.51.43 #       <mirak> no wonder why it's not in ^^
19.52.10 #       <_FireFly_> they do you have made something wrong
19.52.55 #       <_FireFly_> then
19.53.42 #       <mirak> plugin.h:301: error: parse error before "va_list"
19.53.43 #       <mirak> plugin.h:301: warning: function declaration isn't a prototype
19.54.07 #       <_FireFly_> int (*vsnprintf)(char *buf, int size, const char *fmt, va_list ap);
19.54.32 #       <_FireFly_> does your line in plugin.h looks the same ??
19.55.12 Join    dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU)
19.55.14 #       <mirak>     int (*vsnprintf)(char *buf, int size, const char *fmt, va_list ap);
19.55.19 Quit    dpassen1 (Client Quit)
19.55.25 #       <mirak> _FireFly_: the same
19.55.51 #       <mirak>    /* strings and memory */
19.55.51 #       <mirak>     snprintf,
19.55.51 #       <mirak>     vsnprintf,
19.55.51 #       <mirak>     strcpy,
19.56.03 Join    dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU)
19.56.24 #       <mirak> I don't know what's wrong
19.56.37 #       <Bagder> you miss an #include
19.57.40 #       <_FireFly_> yeah
19.58.00 #       <_FireFly_> stdarg.h i guess
19.58.29 #       <_FireFly_> or is it stdio.h 
19.58.50 #       <_FireFly_> yepp it is stdio
19.58.54 #       <_FireFly_> stdio.h
19.59.16 #       <_FireFly_> hmm
19.59.38 #       <_FireFly_> this is already included in plugin.h
20.02.06 #       <_FireFly_> strange i can't find an header in the rb-sources which defines the va_list
20.04.51 #       <_FireFly_> ok if i add stdarg.h then it works
20.05.23 #       <_FireFly_> but stdio.h includes also stdarg.h
20.05.36 #       <_FireFly_> and stdio.h is included in plugin.h
20.07.51 #       <mirak> thanks !
20.07.55 #       <_FireFly_> so why i need it then
20.08.07 #       <_FireFly_> to include it a second time in plugin.h
20.09.10 #       <_FireFly_> and i see also that in stdio.h vsnprintf is also defined
20.09.32 #       <_FireFly_> instead va_list it is __VALIST
20.19.25 #       <mirak> /usr/local/coldfire/lib/gcc/m68k-elf/3.4.4/../../../../m68k-elf/bin/ld: /home/karim/Prog/src/rockbox/builddir/apps/plugins/xvid/xvid_decraw.elf: section .data lma 0x32a547b4 overlaps previous sections
20.19.27 Quit    DrumRBoy320|away (Read error: 110 (Connection timed out))
20.19.32 #       <mirak> hi still have that error
20.19.36 Part    zeero ("Leaving")
20.19.42 #       <mirak> though I exetended plugin memory
20.19.50 Join    bazz [0] (n=nick@fw.cerisent.com)
20.20.30 #       <_FireFly_> mirak: i think you mean that your plugin is too big ?
20.20.38 #       <mirak> yes
20.20.59 #       <mirak> #define PLUGIN_BUFFER_SIZE 0x600000
20.21.05 #       <mirak> maybe that's too big now
20.21.06 #       <mirak> ^^
20.24.55 #       <bazz> so, i'd like to check in/submit what i have of the sdl port of the sim.  it works on linux, has some issues on windows, but i figure i can let other people hack at it too if they want.  what would be the process for that?
20.29.26 Join    ze [0] (i=ze@ca-dstreet-cuda1-c6a-130.snbrca.adelphia.net)
20.37.26 Quit    solexx_ ("reboot :(")
20.43.36 Join    solexx [0] (n=jrschulz@d027082.adsl.hansenet.de)
20.43.36 Join    DrumRBoy320|away [0] (n=Drumrboy@ool-44c20ff1.dyn.optonline.net)
20.46.04 Quit    Mmmm ()
20.46.21 #       <mirak> bye
20.46.24 Quit    mirak ("Ex-Chat")
21.07.56 Join    einhirn [0] (i=Miranda@szgt-d9b8e8f6.pool.mediaWays.net)
21.08.02 Quit    DrumRBoy320|away (Read error: 110 (Connection timed out))
21.09.58 Join    solexx_ [0] (n=jrschulz@d001091.adsl.hansenet.de)
21.16.08 ***     Saving seen data "./dancer.seen"
21.21.53 Quit    solexx (Read error: 110 (Connection timed out))
21.24.09 Join    petur [0] (i=petur@d54C1B62E.access.telenet.be)
21.27.20 #       <petur> Bger?
21.31.31 Join    muesli__ [0] (i=muesli_t@Bbc78.b.pppool.de)
21.32.06 #       <muesli__> high
21.32.37 #       <petur> very
21.34.43 #       <petur> ha!
21.35.56 Quit    elinenbe (" Try HydraIRC -> http://www.hydrairc.com <-")
21.37.48 Join    Mmmm [0] (n=mscarrat@cpc4-hem13-3-1-cust63.lutn.cable.ntl.com)
21.39.01 Quit    _FireFly_ ("Leaving")
21.43.00 #       <petur> JIHAAAAAA
21.44.01 #       <Mmmm> Ooh, that sounds like fun... can I have a go?
21.44.21 #       <petur> just got recording on H300 working, I think
21.44.48 #       <petur> at least the peakmeters were reacting on the internal mic
21.44.52 #       <Mmmm> well done.......you think?
21.45.35 #       <petur> I pressed stop and there was no file in the recordings dir, but I don't know how to operate, so maybe I didn't start it at all
21.45.42 #       <petur> just a sec...
21.46.30 Join    gromit` [0] (n=gromit`@ras75-5-82-234-244-69.fbx.proxad.net)
21.47.16 #       <petur> yes it does! internal mic recording is working
21.47.28 #       <petur> now the external source...
21.49.50 #       <Mmmm> Blimey the H300 is really comming along at a blazing rate!
21.50.46 #       <petur> hmmm still some work to do
21.51.02 #       <petur> line-in is almost inaudible
21.51.31 #       <petur> and each start or end of the recording has some noise attached
21.51.39 #       <petur> any H1xx user around?
21.52.23 Quit    ender` (Read error: 110 (Connection timed out))
21.52.25 #       <Mmmm> yep...
21.52.49 #       <petur> done recording on it?
21.52.55 #       <Mmmm> oh yes!
21.53.10 #       <petur> no noise added at begin or end?
21.53.47 #       <Mmmm> not that I remember...hang on, i'll check...
21.55.39 #       <Mmmm> Nope...nothing
21.56.22 #       <petur> feared that... will have to find out before releasing this...
22.01.19 Join    muesli- [0] (i=muesli_t@Bbcb4.b.pppool.de)
22.02.20 #       <petur> radio recording works also :D
22.03.33 Quit    muesli__ (Read error: 104 (Connection reset by peer))
22.08.57 Quit    solexx_ (Read error: 104 (Connection reset by peer))
22.09.53 Join    DT291 [0] (n=DreamTac@adsl-19-241-33.bna.bellsouth.net)
22.09.53 Quit    DreamTactix291 (Read error: 104 (Connection reset by peer))
22.11.25 Join    solexx [0] (n=jrschulz@c146142.adsl.hansenet.de)
22.12.14 #       <petur> Mmmm, still here?
22.12.42 #       <Mmmm> yep
22.13.44 #       <petur> does the original H1xx firmware also allows to select mic-in or line-in?
22.13.52 #       <petur> (both external)
22.14.06 #       <lostlogicx> hmph gcc4 makes bigger code than gcc3.4.4 and causes my optimizations to overflow iram.
22.14.40 #       <petur> :( my crosscompiler is 4.0.2
22.14.40 #       <Mmmm> yes, the external mic in has a boosted signal
22.14.42 #       <lostlogicx> make zip
22.14.48 #       <petur> hehe
22.15.09 #       <petur> Hmmm, thanks
22.15.17 #       <lostlogicx> petur: hehe, it isn't a huge difference, but I just had to pull my latest IRAM'd function out.
22.15.31 Nick    Lost-ash is now known as ashridah (n=ashridah@67.106.77.212.ptr.us.xo.net)
22.16.06 #       <petur> I meant Mmmm of course
22.16.32 Join    Moos [0] (i=Moos@m196.net81-66-159.noos.fr)
22.16.37 #       <Mmmm> Of course :D
22.17.21 #       <petur> regarding http://forums.rockbox.org/index.php?topic=1911.msg13431#msg13431 I think it would be better to change the gain descriptions
22.17.49 #       <petur> because there is analog gain and digital decimation
22.18.13 #       <petur> I think the user should know which one he is changing
22.18.30 Quit    linuxstb (Read error: 110 (Connection timed out))
22.21.44 #       <Slasheri> hehe, just browsing with tagcache.. seems to work pretty well now (as fast browsing as with dircache), and supported modes are artists - albums - songs, albums - songs, genres - artists - albums - songs, songs. In fact all searches are possible with the tagcache api :)
22.22.15 #       <Moos> Hi: w00t :)
22.22.18 #       <dpassen1> sounds great Slasheri
22.22.18 #       <petur> way to go!
22.22.30 #       <Slasheri> hi Moos :)
22.22.38 #       <Slasheri> i will provide a patch for testing in a few days
22.22.43 #       <Moos> Slasheri: something to test?
22.22.48 #       <Slasheri> soon :)
22.22.49 #       <Moos> hehe :)
22.22.57 #       <Moos> ok let us know
22.25.14 #       <Mmmm> Petur: the gains are currently under different menus so you already can tell which you are changing
22.25.30 #       <dpassen1> in current implementation, how is two artists with the same titled album handled?
22.26.40 #       <petur> I'll need to talk to the one who made this...
22.37.59 #       <Slasheri> dpassen1: hmm, i don't know about the current tagdb, but my implementation puts both artists under the album then. In fact a good point, it might be better to separate the artists
22.38.10 #       <Slasheri> +same
22.39.08 #       <Slasheri> if separated, we would just display two albums with the same name on the album browser
22.41.20 #       <dpassen1> or it could go you pick the album then are presented with a list of artists, including an entry All Artists .. this would allow for Compilations and Various Artists albums to work seemlessly
22.43.12 #       <Slasheri> ah, true
22.43.22 #       <Slasheri> that should be possible to do
22.47.18 Join    DrumRBoy320|away [0] (n=Drumrboy@ool-44c20ff1.dyn.optonline.net)
22.49.33 #       <dpassen1> probably would be better off listening to someone who intends to use the tagdb, though, hah
22.51.27 Quit    Mmmm ()
22.56.32 #       <DrumRBoy320|away> is C++ compatable with rockbox at all?
22.57.10 #       <Bagder> what do you mean?
22.57.39 #       <petur> no C++
22.57.58 #       <Bagder> you _can_ do C++
22.58.15 #       <petur> can you?
22.58.20 #       <Bagder> yes
22.58.37 #       <Bagder> it would be possible to write a plugin in C++ for example
22.58.40 #       <DrumRBoy320|away> lol, i took a book out on C++ from my schools computer library
22.58.50 #       <Bagder> just that nothing so far is C++
22.58.58 #       <Bagder> and you'd get a hard time to explain why you use it
22.59.02 #       <Bagder> to let it go in
22.59.09 #       <DrumRBoy320|away> lol, w/e
22.59.14 #       <DrumRBoy320|away> i just wanna experiment
22.59.15 #       <petur> would not be very memory efficient to start
22.59.31 #       <DrumRBoy320|away> already! :P
22.59.31 #       <Bagder> DrumRBoy320|away: then why use C++? C is fine
22.59.41 #       <DrumRBoy320|away> well, i dont have a book on c...
22.59.52 #       <petur> all objects on the stack (no memory allocation)
22.59.56 #       <DrumRBoy320|away> i really want to be able to code and do my own thing
23.00.06 Quit    einhirn (Read error: 110 (Connection timed out))
23.00.12 #       <petur> do get a book on C
23.00.28 #       <DrumRBoy320|away> hmm, ok
23.00.33 #       <petur> the C++ book will start by mentioning that C knowledge is required
23.00.43 #       <DrumRBoy320|away> its a beginners book
23.00.49 #       <DrumRBoy320|away> so maybe it will teach C first>
23.00.54 #       <DrumRBoy320|away> ?*
23.00.57 #       <Bagder> possibly
23.01.01 #       <petur> oh, maybe there are some C chapters
23.01.19 #       <DrumRBoy320|away> maybe
23.01.22 #       <DrumRBoy320|away> its a text book
23.01.44 #       <petur> anyway, most stuff about control flow and variables is the same
23.01.59 #       <DrumRBoy320|away> throws you straight into C++
23.02.01 #       <ashridah> DrumRBoy320|away: i'd think it hsould be. a picture book would be difficult to learn from :)
23.02.02 #       <petur> stop when they start about classes...
23.02.15 #       <DrumRBoy320|away> hmm, ok
23.03.57 #       <DrumRBoy320|away> http://www.skylit.com/cppquotes.html
23.05.26 #       <lostlogicx> ZOMG I learned from that book sr. year of hs.
23.05.50 #       <lostlogicx> ::shakehead:: it's mostly functional, it'll be a fine place to start, if I recall correctly.
23.06.15 #       <DrumRBoy320|away> cool :)
23.06.29 #       <DrumRBoy320|away> im only a soph, so it might be a lil over my head
23.06.32 #       <DrumRBoy320|away> w/e ill try
23.06.58 #       <lostlogicx> *shrug* programming is just about solving problems through a logical process, if you've had algebra and geometry, you'll be fine.
23.07.46 Quit    calbearfan ()
23.07.47 #       <DrumRBoy320|away> well... i know some basic... haha and im in algebra now
23.07.52 #       <DrumRBoy320|away> i think im in algebra
23.07.58 #       <DrumRBoy320|away> idk what im in... lol
23.10.37 Join    linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net)
23.13.33 Quit    Rick (Read error: 104 (Connection reset by peer))
23.15.15 Join    Rick [0] (i=rick@pool-71-108-9-40.lsanca.dsl-w.verizon.net)
23.16.09 ***     Saving seen data "./dancer.seen"
23.42.46 Join    RotAtoR [0] (n=e@12-210-82-91.client.insightBB.com)
23.43.09 Join    aquarius [0] (n=aquarius@82-47-92-64.cable.ubr04.dudl.blueyonder.co.uk)
23.43.21 Quit    Moos (Read error: 104 (Connection reset by peer))
23.43.23 Join    [1]Moos [0] (i=Moos@m196.net81-66-159.noos.fr)
23.43.33 Quit    DrumRBoy320|away (Read error: 110 (Connection timed out))
23.51.01 Quit    [1]Moos (" HydraIRC -> http://www.hydrairc.com <- The professional IRC Client")
23.52.45 Join    livesNbox [0] (n=livesNbo@68-76-129-2.ded.ameritech.net)
23.53.48 #       <livesNbox> hey guys.. I've got rockbox latest on a h320 -- love all of the functionality... one question -- when I have the player in "car adapter" mode -- and I turn my car on, it boots into the default iriver firmware...  I have to then turn the unit off, unplug the power cord, then turn it back on, let it boot into rockbox, then plug the power back in.. a
23.54.04 #       <livesNbox> I'd like to just boot right back into rockbox and continue the song that was playing when I turned the car off.
23.54.26 #       <ashridah> livesNbox: they haven't hooked that particular startup method in iriver's firmware yet
23.54.41 #       <livesNbox> ah ok...
23.54.42 #       <ashridah> the H1xx only had one power on method, the H3xx has several
23.54.51 #       <livesNbox> I'll just keep watching then..
23.55.12 #       <ashridah> so far as i know, they're not deliberately ignoring it, it's just a priority issue atm
23.55.23 #       <ashridah> (and it gives people a failsafe for the time being)
23.56.49 #       <livesNbox> one more quick question...  I switched around between some of the wps's and it seems like the font you pick can drastically mess up the alignment -- how do you know what font a wps wants to be in ?
23.57.12 #       <ashridah> use themes instead
23.57.27 #       <ashridah> those set the font for the theme automagically. setting an individual WPS doesn't garuntee that
23.57.59 #       <muesli-> all wps should be "themed" my 0.0002c
23.58.24 #       <ashridah> muesli-: i imagine eventually they will be, it's a matter of transition, i'd say.
23.58.55 #       <livesNbox> themes eh