--- Log for 11.08.105  Server: brown.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 2 days and 11 hours ago

00.00.10 #       <Lear> so would it mostly be a question of enabling it and  getting the audio routing right then?
00.00.37 #       <amiconn> No, we need an i2c driver for the chip and some adjustments in the radio screen as well
00.01.29 #       <amiconn> LinusN: Maybe rombox makes no sense for actually running it (I'm still not fully convinced btw), but it has at least one benefit for development: it allows to actually check whether 'const' is used correctly
00.02.01 #       <amiconn> It depends on the access speed of the ROM vs. the RAM
00.02.16 #       <amiconn> Iriver RAM is sloow, so....
00.04.33 Join    ashridah [0] (i=ashridah@220-253-123-146.VIC.netspace.net.au)
00.05.08 #       <LinusN> amiconn: correct const usage is mainly valuable when running from rom
00.05.38 #       <amiconn> Mainly, but not only
00.10.18 Join    webguest30 [0] (n=51429e1d@labb.contactor.se)
00.10.33 #       <webguest30> Hello folks
00.10.33 #       <Lear> OT: Why does cygwin ship with such an old version of tar... :/
00.11.19 #       <webguest30> quick question for the core developers
00.12.15 #       <webguest30> there are a lot of patches in the tracker who could be very good for rockbox
00.12.30 Join    amiconn_ [0] (n=jens@p54BD7405.dip.t-dialin.net)
00.12.32 Join    tofusalad [0] (n=450aa184@labb.contactor.se)
00.12.47 #       <webguest30> just wondering why the core devlopers can't apply them
00.13.01 #       <webguest30> is it hard to do?
00.13.03 #       <Bagder> time
00.13.19 #       <webguest30> a ok, the patches are incompleted?
00.13.21 #       <Bagder> some are hard, some are easy
00.13.27 #       <Bagder> they all require time
00.13.28 #       <LinusN> often, yes
00.13.35 #       <webguest30> ok
00.13.49 #       <Bagder> its very easy to throw in a quick hack in the tracker
00.14.15 #       <Bagder> that breaks 7 builds and isn't following our coding standards
00.14.31 #       <Bagder> ... and then 27 people in the forums ask why it isn't in the CVS yet
00.14.32 #       <webguest30> ok
00.14.48 #       * Bagder is a cynic today
00.14.52 #       <webguest30> scuse me for this stupid question :)
00.14.55 #       <Bagder> hehe
00.15.01 #       <Bagder> no worries really
00.15.12 #       <webguest30> :)
00.15.15 #       <webguest30> :)
00.16.00 #       <webguest30> i see for exemple one fix for dsp
00.16.25 #       <webguest30> in Lear's and Slasheri  territory
00.16.33 #       <Bagder> if you apply the patches and try them out
00.16.35 #       <Bagder> it helps
00.16.50 #       <webguest30> a ok
00.17.05 #       <Bagder> knowing that the patches work/fix the problems are often a good feedback
00.17.15 #       <webguest30> the patch tracker don't have few restrictions for prevent this?
00.17.21 #       <Lear> I know Linus is working on applying one dsp-related patch...
00.17.26 #       <LinusN> yes i am
00.17.35 #       <webguest30> a ok :)
00.17.36 #       <amiconn_> Btw, the hebrew/arabic patch still has a problem.
00.18.13 #       <amiconn_> While it does no longer modify the input string (which isn't allow since it is a const), it now isn't reentrant
00.18.30 #       <amiconn_> ...which is a problem with the 2 LCD drivers on iriver
00.18.38 Quit    amiconn (Nick collision from services.)
00.18.39 Nick    amiconn_ is now known as amiconn (n=jens@p54BD7405.dip.t-dialin.net)
00.19.07 #       <amiconn> I considered adding that call to lcd-h100-remote.c, but the dropped the idea
00.19.08 #       <webguest30> I don't understand the patch "add to playlist" in the tracker maybe hardeep can explain me?
00.19.44 #       <amiconn> ...because of my idea to introduce a secondary UI thread for the remote one day
00.20.24 #       <webguest30> please do amiconn if you have time :)
00.21.08 #       <webguest30> the Xavier's patch is good but not the good way
00.21.08 Quit    tofusalad ("CGI:IRC (EOF)")
00.21.25 #       <amiconn> Hmm, maybe there is no problem, I need to think a bit about it again
00.21.52 #       <Lear> if the bidi patch uses static buffers, then it would be, I think...
00.21.58 #       <amiconn> Otherwise the problem would hit even without a secondary display, when the scroll thread does its work in parallel to the ui...
00.22.45 #       <amiconn> Lear: Maybe not. Sometimes I forget that rockbox does cooperative multitasking, and that allows to do some things that are forbidden with preemptive multitasking
00.23.14 #       <Lear> quite true...
00.23.24 #       <amiconn> Yes, it uses static buffers to reverse the rtl parts if bidi is enabled
00.24.16 #       <amiconn> However, there is no yield() between the reversal and the actual output
00.24.43 #       <amiconn> As long as no interrupt routine tries to use lcd text output...
00.25.42 #       <Lear> Otoh, it only needs to reverse the on-screen chars, afaict, so a small stack buffer in the lcd driver would be enough, wouldn't it?
00.26.18 #       <amiconn> I hope that someone completes the unicode patch one day...
00.26.45 #       <amiconn> Lear: I'm not sure
00.27.26 #       <amiconn> The problematic thing is that with bidi, you don't know which part of the original string needs to be displayed before actually doing the reversal
00.28.29 #       <Lear> btw, found another ctype bug the other day...
00.28.41 #       <amiconn> If it is a long string which consists of arabic (or hebrew) only, it will be the end of the string, but not if the string contains both arabic/hebrew and latin...
00.28.56 Quit    ashridah ("uni. mutter")
00.33.21 #       <hardeep> webguest30: I don't really understand the purpose of that patch either... re: add to playlist
00.33.53 #       <HCl> hey amiconn.. think you'll have a little time soon to check those rundb events on archos..?
00.38.38 #       <webguest30> Hardeep: i find this discussion for understand a bit but not really http//forums.rockbox.org/index.php?topic=1185.0
00.39.11 #       <webguest30> http://forums.rockbox.org/index.php?topic=1185.0
00.39.59 #       <webguest30> if it can help you didn't read it
00.41.17 #       <webguest30> prethom: spexx is it again in your plan?
00.43.21 #       <webguest30> nope?
00.45.23 #       <webguest30> Good evenings all and still thanks for all your works
00.45.40 Part    webguest30
00.50.31 ***     Saving seen data "./dancer.seen"
01.05.21 Quit    _aLF ("Leaving")
01.12.16 Quit    Lear ("Chatzilla 0.9.68.5 [Firefox 1.0.6/20050720]")
01.21.54 Quit    dpassen1 (Remote closed the connection)
01.25.01 Join    Febs [0] (n=Febs@207-172-122-81.c3-0.rdl-ubr4.trpr-rdl.pa.cable.rcn.com)
01.28.55 #       <prethom> webguest30: yes, ill add speex support soonish, if you read the logs
01.32.07 #       <prethom> amiconn: if you want faster layer 1/2 playback, there are a couple of frequently used tables in layer12.c that could probably benefit from being in iram
01.35.54 Quit    ghostiger ("Leaving")
01.42.54 #       <prethom> im off
01.42.58 Quit    prethom ("foop")
01.47.52 Quit    Moos (" Try HydraIRC -> http://www.hydrairc.com <-")
02.00.59 Join    TCK- [0] (i=TCK@81-86-96-223.dsl.pipex.com)
02.05.55 Join    OnkelJonas [0] (n=kartoffe@ip230.rev112.brygge.net)
02.06.30 Part    OnkelJonas
02.15.21 Join    Omar [0] (n=nospam@cpc4-eswd1-3-0-cust156.renf.cable.ntl.com)
02.19.19 Quit    TCK (Read error: 110 (Connection timed out))
02.41.36 #       * LinusN goes to sleep
02.41.39 Part    LinusN
02.43.03 Quit    Omar ()
02.50.34 ***     Saving seen data "./dancer.seen"
03.07.42 Quit    Sucka ("a bird in the bush is worth two in your house")
03.08.15 Join    dpassen1 [0] (n=derek@cpe-24-168-110-99.si.res.rr.com)
03.12.44 Quit    Rick (Read error: 104 (Connection reset by peer))
03.13.51 Join    Rick [0] (i=rick@pool-71-108-13-143.lsanca.dsl-w.verizon.net)
03.19.43 Quit    Rick (Read error: 104 (Connection reset by peer))
03.20.40 Join    Rick [0] (i=rick@pool-71-108-13-143.lsanca.dsl-w.verizon.net)
03.24.59 Quit    Rick (Read error: 104 (Connection reset by peer))
03.25.09 Join    ansivirus [0] (n=ansiviru@ppp-69-148-71-237.dsl.rcsntx.swbell.net)
03.26.20 Join    Rick [0] (i=rick@pool-71-108-13-143.lsanca.dsl-w.verizon.net)
03.34.17 Quit    Rick (Read error: 104 (Connection reset by peer))
03.35.54 Join    Rick [0] (i=rick@pool-71-108-13-143.lsanca.dsl-w.verizon.net)
03.38.51 Quit    lostlogic (Read error: 110 (Connection timed out))
03.38.51 Quit    Rick (Read error: 104 (Connection reset by peer))
03.40.01 Join    Rick [0] (i=rick@pool-71-108-13-143.lsanca.dsl-w.verizon.net)
03.40.57 Quit    Rick (Read error: 104 (Connection reset by peer))
03.41.19 Quit    ansivirus ("Leaving")
03.42.08 Join    Rick [0] (i=rick@pool-71-108-13-143.lsanca.dsl-w.verizon.net)
04.06.10 Join    QT_ [0] (i=as@madwifi/users/area51)
04.18.04 Quit    QT (Read error: 110 (Connection timed out))
04.33.41 Join    edx__ [0] (i=edx@p54A8DBB0.dip.t-dialin.net)
04.39.28 Quit    Strath ("Client closed")
04.48.15 Quit    edx (Read error: 110 (Connection timed out))
04.48.20 Join    rubberglove [0] (n=46308405@labb.contactor.se)
04.50.36 ***     Saving seen data "./dancer.seen"
04.54.26 Quit    rubberglove ("CGI:IRC (EOF)")
04.59.53 Join    solex_ [0] (n=jrschulz@c219041.adsl.hansenet.de)
05.10.24 Quit    solex (Connection timed out)
05.10.53 Join    lostlogic [0] (n=lostlogi@node-4024215a.mdw.onnet.us.uu.net)
05.26.06 Nick    edx__ is now known as edx (i=edx@p54A8DBB0.dip.t-dialin.net)
05.28.39 Quit    lostlogic (Read error: 145 (Connection timed out))
05.51.45 Quit    hardeep ("[BX] Automatically bored away")
06.12.51 Quit    dpassen1 ("Friends Don't Let Friends Listen To Anti-Flag")
06.20.37 Join    Coldtoast [0] (i=edan@ppp110-114.lns1.hba1.internode.on.net)
06.50.37 ***     Saving seen data "./dancer.seen"
06.58.03 Quit    Ismo (Read error: 104 (Connection reset by peer))
06.58.13 Join    Ismo [0] (i=laitinei@huippu.net)
07.14.20 Quit    thegeek (Read error: 104 (Connection reset by peer))
07.16.03 Join    thegeek [0] (n=thegeek@s201a.studby.ntnu.no)
07.49.11 Quit    merbanan (Read error: 104 (Connection reset by peer))
07.49.55 Join    merbanan [0] (i=banan@dalink.campus.luth.se)
07.51.11 Quit    thegeek (Read error: 104 (Connection reset by peer))
07.51.43 Join    thegeek [0] (n=thegeek@s201a.studby.ntnu.no)
07.55.41 Join    banan_ [0] (i=banan@dalink.campus.luth.se)
07.56.03 Quit    merbanan (Read error: 104 (Connection reset by peer))
07.58.53 Join    Maxime [0] (n=flemmard@cartec.net2.nerim.net)
08.16.48 Quit    Seed (Read error: 110 (Connection timed out))
08.27.17 Join    SRM [0] (i=Shamrock@68-112-49-085.dhcp.hlrg.nc.charter.com)
08.28.18 Quit    crashd (Remote closed the connection)
08.29.33 Quit    ShamrockMan (Read error: 104 (Connection reset by peer))
08.29.39 Join    banan__ [0] (i=banan@dalink.campus.luth.se)
08.29.55 Quit    banan_ (Read error: 104 (Connection reset by peer))
08.31.13 Quit    einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
08.33.28 Join    crashd [0] (i=nobody@badger.ing.me.uk)
08.50.40 ***     Saving seen data "./dancer.seen"
08.57.29 Join    LinusN [0] (N=linus@labb.contactor.se)
09.00.13 Join    einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de)
09.06.03 Quit    pabs (Remote closed the connection)
09.06.05 Join    pabs [0] (n=pabs@ip68-100-248-22.dc.dc.cox.net)
09.24.59 Join    lostlogic [0] (n=lostlogi@node-4024215a.mdw.onnet.us.uu.net)
09.52.57 Join    ashridah [0] (i=ashridah@220-253-123-47.VIC.netspace.net.au)
09.57.40 Quit    Rick (Read error: 104 (Connection reset by peer))
09.58.15 Join    Rick [0] (i=rick@pool-71-108-13-143.lsanca.dsl-w.verizon.net)
10.04.21 #       <ReKleSS> anyone know why I would be getting a floating point exception when I try to run the ui simulator, build for iriver?
10.08.47 #       <ReKleSS> same thing happens if it's build for archos
10.09.02 #       <LinusN> hmmm
10.09.16 #       <LinusN> have you changed any of the code?
10.10.00 #       <ReKleSS> no, fresh cvs checkout
10.10.14 #       <ReKleSS> and gdb won't tell me anything...
10.10.48 #       <LinusN> cygwin?
10.11.02 #       <ReKleSS> gentoo
10.11.36 #       <LinusN> i seem to recall that this could happen if some code was accidentally placed in the ICODE section
10.12.11 #       <LinusN> i ranm the sim last night on my debian without problems
10.13.18 #       <ReKleSS> what version of gcc?
10.14.11 #       <LinusN> 3.3.6
10.14.42 #       <ReKleSS> 3.4.3 here
10.15.27 #       <ReKleSS> what the heck... a printf added to the first line of main doesn't display
10.16.20 #       <ReKleSS> is there anything I can do about this ICODE thing?
10.18.44 #       <LinusN> check the map file, apps/rockbox.map
10.21.18 #       <ReKleSS> strlen and memcpy are in there
10.22.18 Join    webguest20 [0] (n=c31ce021@labb.contactor.se)
10.22.46 #       <ReKleSS> that's a bad thing, right?
10.23.31 #       <LinusN> hehe
10.24.35 #       <LinusN> yes it is
10.26.13 #       <LinusN> ReKleSS: wanna try a fix?
10.30.14 #       <LinusN> http://linus.haxx.se/simpatch.diff
10.45.45 #       <Coldtoast> hey
10.45.49 #       <Coldtoast> the volume bug is fixed?
10.46.17 #       <Coldtoast> I just updated to the latest bleeding edge and it doesn't seem to be doing it
10.47.15 #       <pike> quick Q guys, I wanna try rockbox on my h120 now, is there more than one method ? (I read how to do it on misticriver) is this method reversable if shit would hit the fan ?
10.49.38 #       <LinusN> Coldtoast: no it isn't fixed
10.49.48 #       <LinusN> pike: huh?
10.49.58 #       <Coldtoast> ok. so it'd just beign random on me then
10.50.07 #       <Coldtoast> whereas 100% of the time before I'd get it
10.50.14 #       <pike> to put it bluntly: could I make a brick of my iriver using rockbox ?
10.50.42 ***     Saving seen data "./dancer.seen"
10.51.08 #       <LinusN> nobody has done it yet
10.51.15 #       <Coldtoast> you can UN-brick your player with Rockbox tho :)
10.51.29 #       <Coldtoast> f you ever get the "Read file system" hang
10.51.44 #       <LinusN> yes, the rockbox boot loader is in fact safer than the original
10.52.06 #       <pike> ok, then Im gonna try this method http://www.misticriver.net/boards/showpost.php?p=283091&postcount=24
10.52.11 #       <pike> unless you have a better way
10.52.20 #       <Coldtoast> so even if you never install Rockbox, it's a good idea to use the bootloader
10.52.29 #       <LinusN> pike: that's the way
10.52.39 #       <pike> oki then :)
10.52.43 #       <pike> thx
10.54.04 #       <LinusN> Coldtoast: i managed to get an i2c trace of the volume bug last night
10.54.32 #       <LinusN> it turns out that rockbox writes to an undefined address in the uda1380
10.54.42 #       <LinusN> and the uda hangs
10.56.09 #       <CoCoLUS> and why does it do that? :)
10.57.44 #       <LinusN> if i only knew
11.01.37 #       <pike> curious, how come your mpc codec is almost 10times as large as ours
11.01.41 #       <pike> (XBMC)
11.01.53 #       <pike> I know ours is from foobar
11.06.33 #       <LinusN> x86, right?
11.06.59 #       <ReKleSS> LinusN: sorry, had to go eat.... the ptach didn't work
11.07.05 #       <ReKleSS> no effect
11.07.12 #       <LinusN> really?
11.07.25 #       <LinusN> did you do "make clean"?
11.07.33 #       <ReKleSS> yes
11.07.56 #       <ReKleSS> strlen and memcpy moved out of icode
11.08.00 #       <ReKleSS> but I still get FPE
11.08.27 #       <LinusN> can i see the map file somehow?
11.08.34 #       <ReKleSS> sure, just a moment
11.08.47 #       <ReKleSS> gr.... my ftp servers still don't work...
11.11.20 #       <ReKleSS> LinusN: http://s20.yousendit.com/d.aspx?id=02VGAGGCLEP831LALAAUKQFZD3
11.18.24 #       <LinusN> i don't see anything obvious
11.19.36 #       <CoCoLUS> <fn~LinusN> x86, right?
11.19.39 #       <CoCoLUS> yeah
11.20.13 #       <LinusN> afaik, mpc has tons of assembler optimizations for x86
11.21.39 Join    mrelwood [0] (n=54e68ce1@labb.contactor.se)
11.22.14 #       <mrelwood> I find the iRiver on the daily builds. does it mean it can serve use for a ordinary user?
11.22.29 #       <CoCoLUS> depends on what you define as ordinary
11.23.31 #       <crwl> if ordinary user doesn't need radio or recording, rockbox does everything better than the original fimrware, i'd say
11.23.38 #       <pike> sorry yes, xbmc is also x86
11.23.41 #       <ReKleSS> or remote
11.23.46 #       <crwl> hum, except maybe those SRS effects and.. remote :)
11.23.54 #       <CoCoLUS> and... volume changing :P
11.24.00 #       <LinusN> :-P
11.24.09 #       <crwl> is there something wrong with it?
11.24.22 #       <ReKleSS> I'll be getting onto the remote as soon as I have a working simulator or toolchain
11.24.52 #       <CoCoLUS> crwl, volume changing currently hangs your player (sometimes, i think)
11.24.56 #       <mrelwood> ohkay. i WOULD like to change the volume though... ;)
11.25.14 #       <ReKleSS> what's wrong with the volume?
11.25.30 #       <CoCoLUS> <fn~LinusN> it turns out that rockbox writes to an undefined address in the uda1380
11.25.31 #       <CoCoLUS>  <fn~LinusN> and the uda hangs
11.26.21 #       <crwl> hm, i haven't seen that, it has become terribly slow though, if i've changed the volume much and quickly 
11.26.53 #       <ashridah> crwl: you have seen it if volume slows down. the entire player doesn't hang
11.27.01 #       <crwl> ashridah, ah, ok 
11.27.17 #       <crwl> i've never really run to it in daily use... 
11.27.31 #       <crwl> but maybe that's because of replaygain support :) 
11.27.36 #       <ashridah> just the volume changes don't end up having an affect
11.27.39 #       <ashridah> effect even
11.29.06 #       <LinusN> do any of you experience the volume bug today?
11.30.09 #       <LinusN> i think i have an idea what it could be
11.30.22 #       <CoCoLUS> you said it wasn't fixed, didn't you?
11.30.41 #       <LinusN> i mean i want one of you guys to do a test
11.33.30 #       <CoCoLUS> i'm sorry, don't have my iriver with me here at work...
11.37.47 #       <Febs> I can test it.  Which build should I use?
11.38.07 #       <ReKleSS> LinusN: just talked to ninj4 (the guy with the drowned iriver), he's not getting the volume bug
11.38.25 #       <ReKleSS> err
11.38.28 #       <ReKleSS> <NINJ4> volume control died
11.38.40 #       <CoCoLUS> how does one drown his iriver?
11.38.58 #       <Febs> CoCoLUS, you'd be surprised at how many people drop them in toilets.
11.38.59 #       <ReKleSS> CoCoLUS: accident with a raincoat pouch
11.39.25 #       <ReKleSS> it runs... mostly... but rockbox doesn't run reliably on it
11.40.52 #       <LinusN> is ninj4 the same guy as "tandoc" in the forums?
11.40.54 #       <ReKleSS> yeah
11.41.12 #       <LinusN> "works like a charm." he said
11.41.23 #       <ReKleSS> now it does...
11.43.12 Join    tandoc [0] (n=harbl@c210-49-191-25.eburwd8.vic.optusnet.com.au)
11.43.22 #       <LinusN> hi tandoc 
11.43.26 #       <tandoc> allo allo
11.43.39 #       <CoCoLUS> aloha
11.43.41 #       <LinusN> rainman himself
11.43.44 #       <LinusN> :-)
11.44.33 #       <tandoc> i'm assuming you gave me the latest daily build of rockbox
11.44.44 #       <CoCoLUS> what a felony... making his iriver wet... :)
11.44.47 #       <tandoc> since my friend and i get the same volume bug
11.44.49 #       <tandoc> shhh
11.44.54 #       <tandoc> it's the damn jacket's fault
11.44.56 #       <tandoc> >.>
11.45.09 #       <tandoc> 'waterproof'
11.45.11 #       <ReKleSS> I never said I get the volume bug
11.45.23 #       <ReKleSS> although I probably do
11.45.31 #       <tandoc> oh wait
11.45.43 #       <tandoc> you didn't upgrade to the latest daily build did you?
11.45.51 #       <ReKleSS> not yet
11.46.01 #       <tandoc> well you told me about it, so i assumed you had it too
11.46.23 #       <LinusN> if my theory is correct, the bug is easier to reproduce if you play a high bitrate file
11.46.30 #       <tandoc> yup
11.46.46 #       <LinusN> i get it with the latest build, btw
11.46.58 #       <CoCoLUS> we need that guy who had his whole collection @ 320 kbps :)
11.47.09 #       <LinusN> holy moses
11.47.16 #       <tandoc> half of mine is D:
11.47.23 #       <ReKleSS> I think I've still got a few 500kbit vorbis files
11.47.34 #       <Febs> 320kbps ... waste of space.
11.47.39 #       <CoCoLUS> kind of... how to put it... unnecessary
11.47.57 #       <tandoc> it's what the files came at, i don't feel like reencoding them...
11.48.14 #       <CoCoLUS> but that discussion has had it's place here...
11.48.14 #       <tandoc> not that.. i.. download music.. illegally =/
11.48.23 #       <tandoc> i'm sure it has
11.48.40 #       <CoCoLUS> too often, if you ask me :)
11.48.45 #       <tandoc> lol
11.49.23 #       <tandoc> would you consider it blasphemy to cover your ihp with black electrical tape?
11.49.28 #       <LinusN> ok, i *seem* to have found the bug
11.49.46 #       <CoCoLUS> i would consider it blasphemy if'd paint it white and scribble IPOD on it
11.49.53 #       <ReKleSS> lol cocolus
11.50.11 #       <tandoc> oh good
11.50.12 #       <CoCoLUS> black is ok... as long as you don't write U2 on it... :)
11.50.18 #       <tandoc> mine's covered in electrical tape
11.50.21 #       <LinusN> it's not an easy one to fix though
11.50.23 #       <tandoc> because i scratched it..
11.50.51 #       <CoCoLUS> tandoc, just admit it, it's a diy rain-shield :)
11.50.59 #       <tandoc> damn straight.
11.52.26 #       <CoCoLUS> <fn~LinusN> ok, i *seem* to have found the bug
11.52.27 #       <CoCoLUS> where?
11.52.57 #       <LinusN> the i2c controller doesn't like changing the bit rate prescaler on the fly
11.53.36 #       <LinusN> so if rockbox boosts/unboosts the cpu during an i2c transfer, the i2c controller screws up
11.54.11 #       <Coldtoast> tandoc
11.54.16 #       <Coldtoast> don't cover it in electrical tape
11.54.17 #       <tandoc> ?
11.54.22 #       <CoCoLUS> hmm... that wasn't changed with the suspected timer change from amiconn, was it?
11.54.22 #       <Coldtoast> do the brushed metal mod :)
11.54.29 #       <tandoc> its not completely covered..
11.54.34 #       <tandoc> just the scratches...
11.54.40 #       <tandoc> really, really big scratches...
11.54.50 #       <tandoc> brushed metal mod?
11.54.52 #       <LinusN> CoCoLUS: no, but the backlight uses the timer, and also boosts the cpu
11.55.12 #       <LinusN> so the timing might have changed, exposing the bug
11.56.00 #       <CoCoLUS> ic... how much work would it be to stop changing the cpu speed while a i2c transfer is in progress?
11.56.35 #       <LinusN> unfortunately not that easy, but i'll work on it
11.57.07 DBUG    Enqueued KICK tandoc
11.57.07 #       <tandoc> 12(10 LinusN 12): so what did you change in rockbox to disable the hdd check, or whatever it happens to be?
11.57.29 #       <LinusN> i removed the call to check_registers() in ata.c
11.57.57 #       <tandoc> ah, so that'd involve compiling myself to rollback to an older rockbox =____=
11.58.39 #       <Coldtoast> tandoc: http://www.misticriver.net/boards/showthread.php?t=24795&highlight=brushed
11.59.11 #       <LinusN> tandoc: i'll see if we can do something about it permanently
11.59.25 #       <LinusN> i seem to recall that someone else had the same -32 error as you
11.59.30 #       <tandoc> hmm, the problem is only on highbit rate files...
11.59.53 #       <LinusN> tandoc: can you reproduce it?
11.59.59 #       <tandoc> yeah
12.00.28 #       <tandoc> 192kbit is perfectly fine
12.01.22 #       <tandoc> hey sexy, i might do that mod...
12.02.33 #       <Coldtoast> yeah. be sure to clearcoat it tho :)
12.02.59 #       <tandoc> something i probably couldn't do if my life, or mp3 player, depended on it
12.03.10 #       <Coldtoast> hehe
12.04.10 #       <tandoc> but i'd probably fail at getting a brushed finish
12.04.10 Quit    Coldtoast (Read error: 104 (Connection reset by peer))
12.04.29 #       <tandoc> buh bye
12.05.45 #       <LinusN> ouch! the backlight handler calls cpu_boost() from an interrupt!
12.06.16 #       <LinusN> bad bad bad
12.15.32 #       <ashridah> wow. that does look nice.
12.15.49 #       <ashridah> pity i suck with handy work. i'd probably flubb the varnish job
12.17.30 #       <tandoc> i'm happy with my electrical tape :D
12.19.44 #       <ashridah> interestingly, none of the paint has scratched off on mine
12.19.54 #       <ashridah> and i've had it over a year and a half now
12.20.15 #       <tandoc> had mine the same amount of time
12.20.20 #       <tandoc> lots of scratches :P
12.20.32 #       <ashridah> the screen has some marks
12.20.35 #       <ReKleSS> mine doesn't have a metal case... no paint to scratch :p
12.20.38 #       <ashridah> but the paint is fine
12.30.41 #       <LinusN> the backlight dimmer code is really nasty
12.30.57 #       <LinusN> it boosts and unboosts like crazy
12.31.18 #       <ReKleSS> ...just for a little fade effect???
12.32.43 #       <LinusN> it needs to boost during the fade
12.32.46 #       <ashridah> ReKleSS: yeah, it does pulse width modulation
12.33.03 #       <LinusN> but a design flaw makes it boost and unboost for every key event
12.33.27 #       <LinusN> and it unboosts from an interrupt, a totally forbidden thing
12.33.36 #       <ashridah> that tends to be fairly heavy for the granularity of fade. 
12.34.03 #       <ReKleSS> it seems ridiculous, just for eye candy
12.34.17 #       <LinusN> it's not really necessary to boost for performance reasons
12.36.02 #       <LinusN> but the timing changes if the cpu frequency is changed during the fade, causing it to flicker
12.41.24 Join    Moos [0] (i=DrMoos@m29.net81-66-158.noos.fr)
12.41.39 #       <Moos> Good Day all
12.42.28 #       <Moos> hey Linus puzzled with the bug volume
12.50.46 ***     Saving seen data "./dancer.seen"
12.51.12 Join    thomjoha [0] (n=thomjoha@hekta.edt.aft.hist.no)
12.51.14 #       <thomjoha> hi
12.51.17 Nick    thomjoha is now known as preglow (n=thomjoha@hekta.edt.aft.hist.no)
12.51.48 #       <Moos> Hello
12.54.03 #       <pike> is rockbox planning to add audible ff/rw ?
12.54.10 Quit    lostlogic (Read error: 110 (Connection timed out))
12.54.17 #       <pike> testing rockbox on iriver now
12.56.44 #       <LinusN> pike: no plans, but anyone is free to implement it
12.56.47 #       <preglow> hmm, no
12.57.00 #       <preglow> i asked the other people, and most of the devs dont want audible seeking
12.57.06 #       <preglow> although id like it myself
12.57.13 #       <pike> or beef up remote so you can see position ?
12.57.28 #       <pike> maybe thats just skin related, I used rockbox for a full 10 minutes
12.58.04 #       <LinusN> preglow: if you manage to implement audible seeking, i won't stop you
12.58.16 #       <LinusN> provided there is an option
12.59.08 #       <preglow> LinusN: its not that important to me, and indeed, itll be hard to adapt each codec to support it
12.59.21 #       <LinusN> oh yes
12.59.53 #       <preglow> mp3 will be easy, vorbis too, but i dont know about the other ones
13.00.39 Join    lostlogic [0] (n=lostlogi@node-4024215a.mdw.onnet.us.uu.net)
13.00.56 #       <pike> but regarding remote, I just see the logo, and it's sure a nice logo ;) but maybe remote could be used for some info ?
13.01.12 #       <preglow> well have remote wps some happy dau
13.01.13 #       <preglow> day
13.01.16 #       <preglow> please work on it
13.01.16 #       <preglow> heh
13.02.05 #       <Febs> preglow, I saw on yesterday's IRC log that you were asking about suggestions for EQs.
13.02.17 #       <preglow> correct
13.03.04 #       <Febs> I think that a simple 5 band EQ would probably do 90% of what most people need.
13.03.08 #       <Moos> preglow is back? :)
13.03.20 #       <preglow> sort of, give me another week and well see
13.03.39 #       <pike> what speed (X) does it seek with when I FF using remote
13.03.55 #       <pike> same as main unit I suppose, but I dont know what that uses either
13.04.06 #       <Febs> I'd like to see parametric EQ where one could set Q and frequency in addition to gain ...
13.04.21 #       <Febs> ...but I'm not sure whether that would be too confusing for most users.
13.04.46 #       <preglow> we could hide the center freq/q options somehow
13.05.04 #       <Febs> That was my thought too.
13.05.45 #       <Febs> And of couse, people seem to love "presets" like "rock," "jazz" etc. ... though I think that those names are meaningless.
13.06.10 #       <tandoc> people use those?!
13.06.10 #       <preglow> pretty much
13.06.23 #       <pike> "eq" in org fw was pretty bad
13.06.34 #       <pike> it can only get better :)
13.06.34 #       <Febs> tandoc, yeah, you would be suprised by how many people think that if they are listening to rock, they need the "rock" eq.
13.06.36 #       <preglow> well, yes, it isnt a proper eq
13.06.49 #       <tandoc> i like my battery life...
13.07.21 #       <Febs> I actually use EQ very little, but in certain situations would like the flexibility of a parametric EQ.
13.08.15 #       <Febs> Also, and this probably goes without saying, but I think that any EQ implementation should allow the user to cut frequencies as well as boost them.
13.08.34 #       <preglow> of course
13.09.34 #       <pike> a good eq design would be if you can never clip the signal
13.10.01 #       <pike> so instead of raising something , you would lower the rest
13.10.12 #       <preglow> well, that involves decreasing the volume
13.10.27 #       <preglow> yes
13.10.50 #       <preglow> it will work like the current bass/treble controls work
13.11.05 #       <Febs> In terms of pre-scaling the volume, you mean?
13.11.08 #       <preglow> if youre at 100 volume, everything but the band in question will get lower
13.13.42 #       <preglow> theres no way around that
13.16.35 #       <Febs> Understood.  Though I've seen people argue that they should be allowed to push the EQ into clipping if they want so that they can get more volume.  LOL.
13.16.54 #       <preglow> well, i can always add an option...
13.17.01 #       <ReKleSS> "idiot mode"
13.17.22 #       <ReKleSS> just provide a complex looking interface that does nothing
13.17.47 #       <Febs> Ha ha.  Make it one of the presets:  rock, classical, jazz, and ultrabass placebo.
13.18.30 #       <ReKleSS> I just want an eq setting that reduces the bass a bit...
13.18.44 #       <preglow> ahahah
13.18.46 #       <LinusN> well, it still makes sense if the audio has a low level to start with
13.18.52 #       <preglow> sure
13.19.02 #       <pike> and thats what en EQ is for, to compensate for speakers
13.19.08 #       <preglow> i actually want a flag to make the rockbox volume go above 100
13.19.44 #       <preglow> tons of old records are recorded at a pretty low volume
13.19.51 #       <LinusN> afaik, the uda can't boost the volume
13.20.00 #       <LinusN> 0db is max
13.20.01 #       <preglow> i know, software will take care of the boosting
13.20.12 #       <preglow> its a simple multiply
13.20.44 #       <LinusN> i have been looking into missing fundamental bass boosting
13.20.51 #       <Febs> On the fly peak normalization might be cool.  Is such a thing possible?
13.21.07 #       <Febs> LinusN, like the SRS "Trubass"?
13.21.08 #       <preglow> Febs: of course
13.21.14 #       <LinusN> Febs: yes
13.21.18 #       <pike> really ?
13.21.28 #       <Febs> preglow, I think that would be a feature that would be very popular.
13.21.46 #       <pike> it would have to correct realtime, and if song has a silent part, it would boost like he**
13.21.53 #       <preglow> missing fundamental boosting could be done by lowpass filering the signal, distorting it in some way, then adding that to the original signal
13.22.51 #       <LinusN> the algorithms i have studied involve removing the fundamental in the source before adding the harnmonics
13.23.12 #       <preglow> i didnt think the fundamental was audible anyway
13.23.18 #       <preglow> of course, it will eat headroom
13.23.23 #       <preglow> and might cause clipping
13.23.46 #       <LinusN> basically a lowpass filter to find the fundamental, create the harmonics and att them to the signal with the fundamental removed
13.24.00 #       <LinusN> s/att/add/
13.24.43 #       <Febs> I think that the point of providing the harmonics is to compensate for speakers, headphones, etc. that can't reproduce the lower frequencies.  If the fundamental is inaudible anyway, than removing them makes sense.
13.24.49 #       <preglow> well, removing the fundamental is just highpass filtering
13.24.53 #       <LinusN> yes
13.25.04 #       <preglow> but does the algo also involve finding the exact frequency of the fundamental?
13.25.15 #       <LinusN> not necessarily
13.26.35 #       <preglow> good
13.26.38 #       <preglow> that hairier
13.26.39 #       <LinusN> there are algos that try to synthesize the harmonics by analysing the frequencies of the source
13.27.00 #       <LinusN> but they are complicated, power hungry, and not necessarily better sounding
13.27.31 Join    Sucka [0] (n=NNSCRIPT@host81-156-208-120.range81-156.btcentralplus.com)
13.29.27 #       <Febs> pike, going back to your point about boosting silent parts, I am not talking about dynamic range compression.  I am talking about finding the peak, and then scaling the gain of the entire song so that the peak is at 0dB.
13.29.59 #       <preglow> well, youre more or less asking for a replaygain scanner
13.30.00 #       <Febs> That would boost silent parts and possible expose some noise, but no more so than turning up the volume or using replaygain.
13.30.27 #       <preglow> so youd like the peak to be found prior the actually playing the track?
13.30.42 #       <preglow> i need to find out how to make an apostrophe on this bloody keyboard
13.30.51 #       <Febs> Yeah, that would be the concept.
13.31.06 #       <preglow> well, might as well add a full blown replaygain scanner, then
13.31.39 #       <pike> Febs: isnt that called um ReplayGain ?
13.32.02 #       <pike> or you would have the player do the scanning ? (slooow) and you can only find the peak by scanning the whole song
13.32.08 #       <Febs> preglow: suppose you could.  I thought that peak normalization, while a little cruder, would be easier.
13.32.46 #       <Febs> pike, as I understand replaygain and mp3gain, they use some sort of process to calculate the apparent volume and compensate for that.  They're doing something a little more complex than simply setting all files so that they peak at the same point.
13.33.18 #       <pike> they both fins the peak (afaik) and use that as reference point
13.33.24 #       <pike> you must have a reference point
13.34.36 #       <Febs> Right, but with simple peak normalization, a modern recording with really squashed dynamic range is still going to sound a lot louder than an older tune that has some high peaks but is at a lower average gain.
13.35.01 #       <Febs> Replaygain--as I understand it, which admittedly could be wrong--compensates for those differences.
13.35.37 #       <pike> not sure what you mean, but how will you eliminate the scanning process ?
13.35.43 #       <LinusN> preglow: http://www.esat.kuleuven.ac.be/~spch/mpca/papers/aarts:mpca02.pdf
13.36.03 #       <Febs> *I* wouldn't.  Preglow would!
13.36.50 #       <Febs> Seriously, though, I know how it works in theory, but I don't know the mechanics for implementing it on a DAP.
13.37.05 #       <pike> how does it work in theory ?
13.37.11 #       <pike> I never heard of anything similar
13.37.44 #       <pike> think I would have it if was practical or possible
13.38.05 #       <pike> if it*
13.38.16 #       <Febs> I should rephrase:  I understand the concept, rather than the mechanics.  I shouldn't suggest that I understand the math behind it.
13.39.05 #       <Febs> Peak normalization: scan the song, find the peak, calculate the multiplier needed to bring the peak to x (usually 0dB), and multiply the whole song by that constant.
13.39.31 #       <pike> yes, thats straightforward
13.40.27 #       <Febs> Replaygain:  Replaygain:  scan the song, calculate the apparent volume, calculate the multiplier needed to adjust from that apparent volume to a certain fixed standard.  Usually NOT 0dB or quieter songs would need to be clipped to bring them to the same level as louder songs.
13.41.06 #       <preglow> replaygain finds both the peak and the a-weighted average volume
13.41.41 #       <Febs> Ah, that makes sense.
13.42.35 #       <preglow> peak volume is a nice measure to have around anyway, especially since it tends to be higher than 1 for codecs with filter banks
13.42.45 #       <Febs> Well, gotta go to work.  Sadly, that will undoubtedly be far less interesting than this discussion.
13.42.52 #       <preglow> everything is, heh
13.43.10 Quit    Febs (" HydraIRC -> http://www.hydrairc.com <- Leading Edge IRC")
13.43.20 #       <preglow> anywho, is there some way to make rockbox go to the next folder when its done with the current one?
13.43.28 #       <preglow> like, without my intervention
13.43.35 #       <ashridah> didn't someone add an option for that?
13.44.04 #       <preglow> yes, but you need to skip the track by hand
13.44.22 #       <preglow> it doesnt go the next folder if the last track finishes by itself
13.44.26 #       <preglow> perhaps thats a bug?
13.45.36 #       <preglow> ghmm
13.45.37 #       <preglow> im wrong
13.45.39 #       <preglow> it works now
13.51.24 #       <preglow> LinusN: well, yes, that describes more or less what i imagined
13.51.48 #       <preglow> shouldnt be impossible, we can implement filters very efficiently
13.55.03 Join    Rockdude05 [0] (n=chatzill@exhax16-b021.dialup.optusnet.com.au)
13.56.27 #       <Rockdude05> hey, does anyone here use te solitaire plugin?
13.57.08 #       <Rockdude05> its the only stable game whilst playing music, so would adding grey and fixing a few bugs be a big pain in the bu,?
13.57.11 #       <Rockdude05> *bum
13.59.13 #       <preglow> probably not, you just need someone to do it
13.59.30 #       <preglow> i for one isnt even slightly interested in hacking on games
13.59.52 #       <preglow> someone teach me proper english grammar before i make a larger fool of myself
14.00.17 #       <LinusN> i think you've already reached the limit
14.00.29 #       <Rockdude05> wel it's not quite hacking, just fixing silly things like not being able to select cards, or distinguishing between black+red cards, nothing important :)
14.00.50 #       <preglow> good, then i dont have to worry about it
14.01.01 #       <LinusN> Rockdude05: the most unsexy kind of programming
14.01.40 #       <CoCoLUS> anyone who's using sexy and programming in the same sentence is kinda suspect to me...
14.02.30 #       <Moos> :-)
14.02.34 #       <Rockdude05> urm wel i dont get you there but im sure its meaningful ;) well in that case i must do my homework and learn all this.... i used to program loads so yeah... time to go make a large black paperweight
14.05.15 #       <Rockdude05> oh ahem whilst im here also, is there a low battery sequence or not? i seem to recall some sort of change log about it a while ago but my player still goes off its nut on 0%
14.06.01 #       <LinusN> there is no low battery handling
14.06.09 #       <Rockdude05> cheers :)
14.06.15 #       <LinusN> the only thing is that the boot loader warns if the battery is low
14.07.03 #       <Rockdude05> i see
14.09.40 Ctcp    Ignored 1 channel CTCP requests in 0 seconds at the last flood
14.09.40 #       * preglow is finally coding rockbox again
14.11.54 #       <preglow> how is iram usage currently? 32kb core, 32 plugin and 32 codec?
14.12.27 #       <Rockdude05> question time again ;) how much of the iriver resources are available after decoding audio? on average after mp3/ogg/wav for example. is there enough for, as mentioned, stereo width processing etc? or do they all still need optimizing?
14.12.40 #       <preglow> more optimising coming up
14.12.52 #       <preglow> some of them are pretty fast
14.12.58 #       <preglow> mp3 is pretty fast, wavpack is very fast
14.13.03 #       <preglow> vorbis is also getting there
14.13.17 #       <preglow> more than enough for stereo width processing
14.14.23 #       <Rockdude05> yeah i saw some 10% speedup things a while back, which is nice :P also, with crossfade, can someone just quikcly exlain how that works.for example, do both songs have to be decoded at once, or is it buffered?
14.15.09 #       <Rockdude05> yes because i noticed stereo width is already in the menu but not functional, so i assume thats in archos (although isnt the archos effects/decoding hardware orientated?)
14.15.42 #       <LinusN> yes, all signal processing is in "hardware"
14.15.44 #       <preglow> buffered
14.15.45 #       <LinusN> in the archos
14.16.38 #       <LinusN> the archos decoder hardware has a pretty sophisticated mixer that allows us to tweak the stereo width
14.16.58 #       <Rockdude05> thanks, sorry for the questions youve probably answered 1000 times already, but im sure theyre better than some ;)
14.17.08 #       <Rockdude05> ok i see
14.17.49 #       <LinusN> we could add a similar mixer to the iriver
14.17.56 #       <preglow> LinusN: but yeah, you got any idea about my iram question?
14.18.58 #       <preglow> codecs should have more than 32kb iram :/
14.19.01 Join    oxygen77 [0] (i=nobody@yossman.net)
14.19.23 #       <preglow> perhaps it would be a good idea to split mp3 and mp1/mp2 into different codecs
14.19.39 #       <preglow> they share some code, but not all
14.19.47 #       <Rockdude05> i must say (no i wont go into this dribble about how rubbish srs is) that stereo width can be especially useful when using vorbis through line out, and more specifically through an amp or speakers, as the vorbis width always seems very small and i'm sure i read somewhere that it's a known issue with ogg (stereo image is quite, wel, joint still).
14.20.06 #       <preglow> stereo is always joint in vorbis, i believe
14.20.18 #       <preglow> but yeah, stereo with should be a quickie to add
14.20.45 #       <preglow> width, even
14.21.42 #       <LinusN> hmmm, it looks like the codecs share the iram with plugins (!)
14.21.49 #       <preglow> !
14.22.10 #       <preglow> ahh, yes, that is true
14.22.28 #       <LinusN> so if a plugin uses iram the codec will crash
14.22.28 #       <preglow> and i believe thats quite ok, plugins requiring iram will probably be too intensive to run when audio is playing anyway
14.22.34 #       <Rockdude05> yes, until a point, but the image can be narrow if i'm understood, so sounds bad on good speakers. on the subject, do you know what percentage or settngs are line out on rockbox or iriver, and also if it in fact matters if i use the headphone jack or line out jack. also (phew) will (i've been doing this) sticking 2 headphones in each jack (line out+headphone) kill the player? (bass etc still...
14.22.35 #       <Rockdude05> ...works with line out)
14.23.03 #       <preglow> Rockdude05: it matters if youre using headphones, line out doesnt have an amp
14.23.14 #       <preglow> Rockdude05: but if youre connecting to an amp, it shouldnt matter
14.23.40 #       <Rockdude05> so technically my headphones shouldnt be working from line out?
14.23.56 #       <preglow> Rockdude05: they do, but theyll distort a lot, since the line out cant drive them properly
14.24.04 #       <preglow> Rockdude05: at least my headphones distort like mad from line out
14.24.30 #       <ze> they distort? hows that?
14.25.10 #       <Rockdude05> someone's going to flinch at this, but i sometimes run 6 headphones from my iriver, with about 70% vol on each and low bass to reduce distortion, so my friends can hear in school etc. although this is pretty insane, will this damage my layer?
14.25.12 #       <ze> just curious, i've never heard of headphones distorting from too weak of a signal
14.25.13 #       <Rockdude05> *player
14.25.37 #       <preglow> Rockdude05: no
14.26.07 #       <Rockdude05> just reduce battery life?
14.26.19 #       <preglow> not by much, i believe
14.26.32 #       <Rockdude05> well how efficient ;)
14.26.35 #       <preglow> the headphone amp can only give so much current
14.27.03 #       <Rockdude05> i know... i dont know myself how i get it all going
14.27.15 #       <Rockdude05> i get a few strange looks
14.27.15 #       <preglow> ze: the headphones themselves arent distorting, its the line out driver circuitry thats distorting, it isnt designed to be connected to a low-impedance load
14.27.26 #       <ze> preglow: ah
14.27.59 #       <Rockdude05> ah, therefore high impedence into low impedence = screwy sound
14.28.53 #       <preglow> a headphone is around 16 ohms, or something, whereas a proper amp input should be several hundred kiloohms
14.29.34 #       <ze> my headphones are 64, and i've seen several in the hundreds, maybe even thousands... never in the hundred thousands though hehe
14.29.39 #       <preglow> LinusN: but where does the remaining 64k go? the core cant possibly need that much
14.30.05 #       <preglow> high impedance headphones do exist, they used them in the olden days of amateur radio
14.30.21 #       <preglow> they could drive headphones from the power of radio waves alone
14.30.23 #       <preglow> which is insane
14.30.28 #       <ze> hehe
14.30.33 #       <LinusN> preglow: the main stack eats most of it, iirc
14.30.34 #       <ze> its not that insane...
14.31.05 #       <preglow> LinusN: ahh, yes, but is that needed currently? the codecs are the most sensitive stack users, and theyve got their own stack currently
14.31.15 #       <ze> in fact transistor radios + peizo earpieces did it all the time, didn't they? heh
14.31.24 #       <LinusN> i think we can reduce the main stack
14.31.33 #       <preglow> transistor radios were powered, crystal radios werent
14.31.34 #       <tandoc> before i sleep, i just want to thank you again linus for making rockbox work on my zombie of an mp3 player :D
14.31.43 #       <LinusN> tandoc: you're welcome
14.31.47 #       <ze> er oh crystal radios, sorry, you know what i meant
14.31.52 #       <preglow> sure, hehe
14.32.03 #       <LinusN> tandoc: make sure you report if anything else breaks
14.32.42 #       <tandoc> roger that
14.32.52 #       <ze> and ya know tesla did all sorts of powering things with radio waves :p
14.32.54 #       <preglow> the codec stack needs to be pretty big, libmad for one requires at least 20k
14.33.37 #       <Rockdude05> does anyone agree with me on this... with all the pop-up messages on r.b, should the background be a lighter grey? i simply cant read it sometimes
14.34.00 #       <preglow> dont think ive ever had any problems with that
14.35.23 #       <Rockdude05> well no but its a small thing that could help, especially when you use stupidly small fonts like me
14.36.47 #       <preglow> but i dont think we have a lighter shade of grey anyway
14.37.30 #       <Rockdude05> *thinks*.... theres four. black, white, light grey and dark grey?
14.37.35 #       <LinusN> no, we would have to adjust the palette
14.38.33 #       <Rockdude05> so its not as simple as changing a couple of characters :P
14.38.35 #       <Rockdude05> sorry
14.39.21 #       <Rockdude05> bloody windows users and their GUI's like me eh? ;)
14.41.14 #       <preglow> oh well
14.41.17 #       <preglow> i need to go 
14.41.18 #       <preglow> later
14.41.24 Quit    preglow ("ex")
14.43.45 #       <Rockdude05> yeah im off too, getting late here in aussieland
14.43.50 Quit    Rockdude05 ("Chatzilla 0.9.68.5 [Firefox 1.0.4/20050511]")
14.50.49 ***     Saving seen data "./dancer.seen"
14.52.09 #       <oxygen77> hello, any news on wav playback ?
15.03.52 Quit    webguest20 ("CGI:IRC")
15.06.05 #       <LinusN> wav playback for archos?
15.06.12 #       <oxygen77> yup
15.06.18 #       <LinusN> not that i know of
15.06.46 #       <oxygen77> k, I've succesfully run archos wav codec on AV's MAS
15.24.34 Quit    mrelwood ("CGI:IRC")
15.29.11 Join    ep0ch_ [0] (n=ep0ch@84.12.175.21)
15.29.23 Nick    ep0ch_ is now known as ep0ch (n=ep0ch@84.12.175.21)
15.30.02 #       <ep0ch> please can someone had the peak meter range values as tags to WPS please :)
15.30.10 #       <ep0ch> had = add
15.30.50 #       <ep0ch> so i can see that the bottom of the peak meter is -55 db and the top is 0 db
15.40.57 Part    LinusN
15.42.56 Part    oxygen77
16.10.23 Quit    ashridah (Read error: 110 (Connection timed out))
16.50.53 ***     Saving seen data "./dancer.seen"
16.55.33 Join    niobos [0] (n=niels@144.19-136-217.adsl.skynet.be)
16.56.27 #       <niobos> hi all
17.04.56 Quit    einhirn (Read error: 104 (Connection reset by peer))
17.07.26 Join    einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de)
17.12.16 Join    pabs_ [0] (n=pabs@xor.pablotron.org)
17.18.58 Join    amiconn_ [0] (n=jens@p54BD7F1E.dip.t-dialin.net)
17.22.51 Quit    pabs (Nick collision from services.)
17.22.56 Nick    pabs_ is now known as pabs (n=pabs@xor.pablotron.org)
17.24.35 Join    bagawk [0] (n=lee@unaffiliated/bagawk)
17.29.45 Quit    amiconn (Nick collision from services.)
17.29.46 Nick    amiconn_ is now known as amiconn (n=jens@p54BD7F1E.dip.t-dialin.net)
17.36.26 Quit    niobos ("leaving")
17.54.48 Quit    ep0ch ("Trillian (http://www.ceruleanstudios.com")
18.04.08 Join    courtc [0] (n=court@adsl-33-131-149.asm.bellsouth.net)
18.05.27 Join    courtc_ [0] (n=court@adsl-33-131-149.asm.bellsouth.net)
18.05.36 Quit    courtc_ (Read error: 104 (Connection reset by peer))
18.07.26 Join    Lear [0] (n=chatzill@h244n6c1o285.bredband.skanova.com)
18.19.26 Join    Coldtoast [0] (i=edan@ppp110-114.lns1.hba1.internode.on.net)
18.50.34 Join    psychocydd [0] (i=psychocy@host217-44-38-58.range217-44.btcentralplus.com)
18.50.44 Part    psychocydd
18.50.54 ***     Saving seen data "./dancer.seen"
19.01.47 Quit    bagawk ("Leaving")
19.08.22 Join    Maxime`Mrn [0] (n=flemmard@cartec.net2.nerim.net)
19.08.23 Quit    Maxime (Read error: 104 (Connection reset by peer))
19.25.48 #       <amiconn> Hmm, no Linus here :/
19.26.04 Join    LinusN [0] (N=linus@labb.contactor.se)
19.26.14 #       <amiconn> hi LinusN
19.26.21 #       <LinusN> i feel like batman
19.26.25 #       <amiconn> Did you monitor the log? ;)
19.26.27 #       <LinusN> coming when you call for me
19.26.29 #       <Coldtoast> hah
19.26.37 #       <LinusN> i just sat down to read it
19.26.40 #       <amiconn> I wanted to talk about the backlight fading
19.26.46 #       <LinusN> oh yes
19.26.49 #       <Coldtoast> (>^<)
19.26.59 #       <LinusN> Coldtoast: :-)
19.27.03 #       <amiconn> I wonder what leads you to conclude it boost/unboosts frequently, and from the isr?
19.27.16 #       <amiconn> Did you some do some bdm sessions?
19.27.16 #       <Coldtoast> hard to do teh batsignal
19.27.20 #       <LinusN> the unboost is in the isr
19.27.32 #       <amiconn> Yes, the unboost, once, when the fade is complete
19.27.37 #       <LinusN> nope
19.27.51 #       <amiconn> Huh?
19.28.00 #       <LinusN> the way the code is written, it registers and starts the timer for every keypress
19.28.12 #       <amiconn> Hmm?
19.28.19 #       <LinusN> the isr concludes that the light is on and unboosts
19.28.27 Quit    Coldtoast ("Peace and Protection 4.22")
19.28.40 #       <LinusN> i logf()ed it
19.28.49 #       <amiconn> It concludes this *only* if 2 conditions are true
19.29.43 #       <amiconn> (1) The pwm value reached the target value *and* (2) this target value is either full on or full off
19.30.11 #       <LinusN> and both are of course true when the backlight is lit
19.30.27 #       <amiconn> Or do you mean __backlight_on() is called for every keypress?
19.30.49 #       <amiconn> This would mean there's something wrong with the design of the backlight thread...
19.30.50 #       <LinusN> __backlight_on() is called, and after that backlight_dim()
19.31.00 #       <amiconn> Yes of course
19.31.23 #       <LinusN> the backlight logic wasn't designed for fading
19.31.25 #       <amiconn> The thing is that this has nothing to do with the dimming code, but is a design flaw in the backlight thread
19.31.48 Join    merbanan [0] (n=banan@dalink.campus.luth.se)
19.32.08 #       <amiconn> Still it doesn't make sense to call __backlight_on() over and over if the light is already on
19.32.30 #       <LinusN> maybe not, but it is simpler than mirroring the state in a variable
19.32.37 #       <LinusN> kiss, you know
19.32.42 #       <amiconn> I could add a protection
19.32.49 Quit    banan__ (Read error: 104 (Connection reset by peer))
19.32.54 #       <amiconn> ...in backlight_dim()
19.33.06 #       <LinusN> sure, plus move the cpu_boost(false) from the isr
19.33.10 #       <amiconn> Btw, I didn't change this part of the logic with my timer changes
19.33.17 #       <LinusN> i'm not blaming you
19.33.41 #       <amiconn> I only changed the way how the dimming logic decides whether it is okay to use the timer
19.33.59 #       <amiconn> So I wonder why these changes uncovered this problem
19.34.20 #       <LinusN> beats me
19.35.12 #       <amiconn> backlight_dim() should only start the dimming process if the new target value is different from the old
19.35.47 #       <amiconn> However, I have no idea how to move the unboost out of the isr
19.36.03 #       <amiconn> I also don't understand the problem with it being in the isr
19.36.39 #       <LinusN> in the old version of the backlight code, backlight_start_timer() returned immediately if bl_timeractive was true
19.36.56 #       <amiconn> Yes, and it still does that
19.36.57 #       <LinusN> the boost counter isn't protected
19.37.11 #       <LinusN> hmmm, yes
19.37.19 #       <amiconn> I merely incorporated the code from backlight_start_timer() into backlight_dim()
19.37.25 #       <LinusN> true
19.37.44 #       <amiconn> Both functions were rather small, and  backlight_start_timer() only being used there
19.38.09 #       <LinusN> let the isr send an event to the backlight thread
19.38.22 #       <amiconn> Hmm.
19.38.23 #       <LinusN> then the backlight thread can unboost
19.38.44 #       <amiconn> This is prone to a race condition...
19.38.54 Quit    einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
19.38.57 #       <amiconn> Hmm, perhaps not
19.38.57 #       <LinusN> perhaps
19.39.18 #       <amiconn> What if backlight_dim() is called before this event is processed?
19.39.27 #       <amiconn> *called again
19.39.33 #       <LinusN> then we have two boosts
19.39.38 #       <LinusN> and two unboosts
19.39.41 #       <amiconn> Yes, for a short time.
19.39.46 #       <amiconn> Should be okay then
19.40.14 #       <amiconn> However, it makes the dimming a bit more scattered
19.40.21 #       <LinusN> this is only one of the problems for the i2c, btw
19.41.06 #       <amiconn> I have an idea what might be another problem
19.41.24 #       <amiconn> We always set the i2c prescaler last, after switching the cpu frequency
19.41.26 #       <LinusN> any boost/ubnoost while running i2c is a problem
19.41.46 #       <amiconn> However, this causes the i2c frequency being way too high for a short time when boosting
19.41.54 #       <LinusN> true
19.42.11 #       <amiconn> We need to increase the prescaler before boosting, but decrease after unboosting
19.42.24 #       <LinusN> i'm not sure that's enough
19.42.36 #       <LinusN> we don't know how the prescaler works internally
19.42.37 #       <amiconn> Maybe this problem manifested because of the increased i2c clock
19.42.43 #       <LinusN> probably
19.42.55 #       <amiconn> Remember, we accidentally ran it at half the desired frequency
19.43.03 #       <amiconn> ...that is 50 kHz
19.43.10 #       <LinusN> ye
19.43.30 #       <amiconn> Now we run it at the desired 100 kHz
19.43.47 #       <LinusN> it might be necessary to protect the i2c comm from frequency changes
19.44.13 #       <LinusN> but your solution might just as well work
19.44.33 #       <amiconn> I wonder what may cause these i2c problem if not only the clock being out of specs
19.44.42 #       <LinusN> i wonder if the internal counter is reset when we write the prescaler
19.45.07 #       <LinusN> i can see from a logic analyser trace that one clock period is insanely short
19.45.23 #       <amiconn> Afaiu i2c should work even if the frequency changes within the transfer
19.45.32 #       <LinusN> i2c itself yes
19.45.42 #       <amiconn> ...as long as it stays within the limit
19.45.47 #       <LinusN> but we don't know how the controller is implemented
19.46.00 #       <LinusN> we can guess though
19.46.20 Join    dpassen1 [0] (n=derek@cpe-24-168-110-99.si.res.rr.com)
19.46.24 #       <LinusN> and setting the prescaler before and after the change might be the solution
19.46.38 #       <amiconn> Maybe it's not the frequency change, but the MFDR change while i2c is running
19.46.55 #       <LinusN> that's what i mean
19.47.12 #       <amiconn> What about choosing MFDR in a way that the maximum allowed i2c clock isn't exceeded when boosting, and then letting it alone?
19.47.29 #       <amiconn> Iirc the maximum i2c clock allowed with most devices is 400 kHz
19.47.37 Join    MO-Pantsu [0] (i=MO-Pants@deadman3000.plus.com)
19.47.43 #       <LinusN> that would make it very slow in the normal frequency
19.47.57 #       <MO-Pantsu> Are there any plans to enabled the radio?
19.47.58 #       <LinusN> the controller can only do 100khz
19.48.03 #       <amiconn> We would then run at 160 kHz at the normal frequency
19.48.03 #       <LinusN> MO-Pantsu: of course
19.48.12 #       <MO-Pantsu> k :)
19.49.01 #       <LinusN> "The interface operates up to 100 kbps with maximum bus loading and timing."
19.50.24 #       <LinusN> i love the i2c timing specs in the manual
19.50.30 #       <LinusN> "tbd ms"
19.51.06 #       <LinusN> every single value is tbd
19.51.41 Join    banan_ [0] (i=banan@dalink.campus.luth.se)
19.52.00 Quit    merbanan (Read error: 104 (Connection reset by peer))
19.58.43 Join    einhirn [0] (i=Miranda@carlsberg.heim2.tu-clausthal.de)
19.58.55 #       <LinusN> amiconn: so we set the i2c prescaler after setting the pll in bypass
19.59.22 #       <LinusN> then there is no risk of overclocking it
20.09.18 Join    XavierGr [0] (n=XavierGr@ppp9-adsl-110.ath.forthnet.gr)
20.09.31 #       <XavierGr> Hi all!
20.29.02 #       <LinusN> amiconn: setting the i2c prescaler after setting the pll in bypass mode did not help
20.29.27 #       <LinusN> so it is probably the writing of the prescaler that causes it
20.36.34 Nick    dionoea is now known as charlie_brown (N=dionoea@muscipula152.via.ecp.fr)
20.36.47 Nick    charlie_brown is now known as dionoea (N=dionoea@muscipula152.via.ecp.fr)
20.43.03 #       <LinusN> this isn't good at all
20.43.27 #       <LinusN> it leaves us with two options:
20.43.37 #       <LinusN> 1) always boost during i2c communication
20.43.59 Nick    banan_ is now known as merbanan (i=banan@dalink.campus.luth.se)
20.44.00 #       <LinusN> 2) inhibit frequency changes during i2c communication
20.44.15 #       <LinusN> hmmm, three options
20.44.56 #       <LinusN> 3) let set_cpu_frequency() wait for the current i2c byte transfer before switching frequency
20.45.26 #       <LinusN> that might actually be the "cleanest" solution
20.45.26 #       <Lear> The wait in 3 is quite short?
20.46.01 #       <LinusN> it could be several milliseconds
20.46.19 #       <LinusN> the uda1380 is pretty slow with the ack's
20.46.34 #       <Lear> That's what I mean by short... :)
20.46.42 #       <LinusN> oh .-)
20.47.14 #       <amiconn> LinusN: 2) and 3) are no viable options imho
20.47.36 #       <LinusN> why not 3)?
20.48.03 #       <amiconn> Both options delay the frequency change. Imho not good if we want to boost because we need the cpu power...
20.48.24 #       <amiconn> I think leaving mfdr alone after init would be kiss
20.48.47 #       <amiconn> Even with 100 kHz at 120 MHz, this would still run around 40 kHz at 48 MHz
20.48.49 #       <LinusN> probably, but then we would have to run it very slow at the normal frequency
20.48.50 #       <Lear> amiconn: shouldn't be a problem for playback at least...
20.49.03 #       <amiconn> I guess we don't do really large i2c transfers...
20.49.08 #       <LinusN> no we don't
20.49.25 #       <LinusN> i'll try that
20.49.25 #       <amiconn> Erm, 48 MHz is the normal frequency?
20.49.53 #       <amiconn> Or do you mean the default 11 MHz, which we normally won't use for prolonged times, except in USB mode?
20.50.17 #       <LinusN> no i don't mean 11
20.50.18 #       <amiconn> Of course this would run i2c at a mere 9 khz
20.50.36 #       <LinusN> it will do that during the frequency switch
20.50.44 #       <LinusN> but not for more than a few ms
20.50.46 #       <amiconn> If all timings are tbd, you could try to measure the possible maximum
20.50.55 ***     Saving seen data "./dancer.seen"
20.51.11 #       <amiconn> My guess is it will run way beyond 100 kHz
20.51.33 #       <amiconn> Remember that we're effectifely overclocking the MAS on archos when pitching up?
20.51.47 #       <LinusN> i think we should ask freescale
20.52.02 Quit    XavierGr ()
20.52.08 #       <amiconn> We can pitch up to 200%, meaning the MAS pll will run at ~48 MHz instead of ~24 MHz, yet it runs stable for extended times
20.52.41 Join    hardeep [0] (i=hardeeps@norge.freeshell.ORG)
20.53.39 #       <LinusN> looks promising
20.53.43 #       <LinusN> no hang
20.53.50 #       <LinusN> yet
20.54.16 #       <amiconn> Does some code yield() while an i2c transfer is running?
20.54.25 #       <LinusN> yes
20.54.37 #       <amiconn> Hmm, ok :/
20.54.40 #       <LinusN> while it waits for each byte to be transferred
20.54.57 #       <LinusN> and acked
20.55.35 #       <LinusN> looks like we have nailed the sucker
20.56.10 #       <LinusN> we should still change the backlight handling though
20.56.33 #       <LinusN> will you have a look at it?
21.00.00 #       <amiconn> <sigh> I think I should do that
21.00.17 #       <amiconn> The first part is rather simple, the second part needs a bit more thinking
21.00.36 #       <amiconn> Btw, did you already have a look at the NULL pointer access on archos?
21.00.42 #       <LinusN> not yet
21.02.18 #       <LinusN> btw, we have had at least two irivers that fail the check_registers() test in ata.c
21.02.21 #       <amiconn> I also still have your oldplayer around... waiting for a button from Jörg
21.02.47 #       <LinusN> one of them works perfectly with the test removed
21.02.57 #       <amiconn> Yes, that's strange
21.03.03 #       <LinusN> i don't know about the other one
21.03.09 #       <amiconn> Do all irivers use the Toshiba disks?
21.03.15 #       <LinusN> i think so
21.03.51 #       <amiconn> Toshiba MK4004GAH here...
21.04.19 #       <amiconn> I wonder what may cause the test to fail, if everything else works...
21.04.35 #       <LinusN> scares me
21.05.24 #       * LinusN is running the logic analyser with win98 in vmware
21.05.47 #       <LinusN> saves me from rebooting when i want to run the analyzer
21.05.48 #       <amiconn> Hmm?
21.06.19 #       <amiconn> Ah, so your main OS isn't windows on this box
21.06.31 #       <LinusN> not if i have a choice
21.07.12 #       <LinusN> vmware is such a cool piece of software
21.07.46 #       <amiconn> Yes indeed
21.07.55 #       <amiconn> Only I use it the other way round...
21.08.02 #       <LinusN> yeah, i know
21.08.08 #       <LinusN> makes it even cooler
21.16.05 #       <amiconn> Hmm, is there a timing specification for the ata register test?
21.16.55 #       <amiconn> check_registers() performs a maximum of 64 tries. Perhaps this is too short for some disks on iriver?
21.17.57 #       <LinusN> i find it interesting that it would need several retries in the first place
21.18.25 #       <amiconn> Also, there is an interesting comment at line 1420 in ata.c
21.18.56 #       <amiconn> Did that setting of IDECONFIGx already happen at the point check_registers() is called?
21.19.35 #       <amiconn> I think there must be a reason for the 64 tries...
21.22.43 #       <amiconn> Afaik such a thing never happened on archos (check_registers() failing on a unit otherwise working fine), at least since I joined the project
21.25.37 #       <LinusN> it was added for the gmini, god knows why
21.26.07 #       <LinusN> and yes, set_cpu_frequency() is called before ata_init()
21.28.27 #       <LinusN> oh, the coldstart detection doesn't work on the iriver
21.31.36 #       <LinusN> hmmm, maybe it does
21.32.07 #       <LinusN> nope, it is broken
21.32.33 #       <LinusN> so there won't be any wait_bsy() call before check_registers
21.33.10 #       <LinusN> btw, why is the wait_bsy() conditional at all?
21.33.18 #       <LinusN> should never hurt
21.34.17 #       <Lear> linusn: that i2c prescaler change, does that fix the volume hang bug?
21.34.26 #       <amiconn> LinusN: Where?
21.34.33 #       <LinusN> Lear: yes
21.34.51 #       <LinusN> in init_and_check()
21.39.38 #       <amiconn> I don't k now the exact reason for this. I unified some code and made up this function, mainly to solve the problem with the archos failing to boot when pressing ON in the charging screen back then
21.39.51 #       <amiconn> (I added the retry with always using hard reset)
21.40.10 #       <LinusN> i think the loop should go away and the wait_bsy() should be unconditional
21.40.22 #       <amiconn> I didn't change the sequence itself
21.40.42 #       <amiconn> Do you mean the loop in check_registers()?
21.40.46 #       <LinusN> yes
21.41.12 #       <LinusN> something is really broken if you have to retry register writes
21.41.48 #       <amiconn> I think you said the coldstart detection is broken?
21.41.54 #       <LinusN> yes it is
21.42.09 #       <amiconn> However, this shouldn't trigger this check_registers() problem
21.42.15 #       <LinusN> but i don't see why the wait_bsy() shouldn't be there anyway
21.42.25 #       <LinusN> exactly
21.42.44 #       <amiconn> The retry in ata.c lines 1439..1445 should catch it
21.43.35 #       <amiconn> Well, it's an unnecessary call when not coldstarting (I think), so it saves a bit of boot time not doing it
21.46.02 #       <amiconn> Why the heck does an ext3 file system need an fsck?
21.46.51 #       <amiconn> A regular check, I mean
21.47.21 #       <LinusN> i don't know, it does that every x boots on my system
21.47.36 Join    Coldtoast [0] (i=edan@ppp110-114.lns1.hba1.internode.on.net)
21.47.39 #       <amiconn> Yes, here too (for the first time now in my vm)
21.54.13 #       <Coldtoast> I can't seem to reproduce the volume bug at all now
21.54.22 #       <Moos> Hey Lear, thanks for your pre-amp support :)
21.55.50 #       <LinusN> Coldtoast: which build?
21.56.51 #       <Coldtoast> the one before the spurt of build in teh last couple of hours
21.57.00 Join    tvelocity [0] (n=tony@chan530-a135.otenet.gr)
21.57.14 #       <Coldtoast> here we go. the 23:19 build
21.58.37 #       <Coldtoast> I'll try the latest
22.00.33 #       <Coldtoast> same with the latest
22.00.39 #       <Coldtoast> I was getting it 100% of the time
22.00.48 #       <Coldtoast> now I'm getting it 0% of the time it seems
22.07.48 #       <Coldtoast> cool. with the replaygain implementation, you can pump the bass up and use replaygain to get the volume back
22.08.45 #       <Lear> with lots of clipping? :)
22.08.58 #       <dpassen1> lol
22.09.14 #       <Coldtoast> heh. well, it's a matter of adjusting th epreamp just right tho :)
22.09.46 #       <dpassen1> any difference between preamping and raising the volume?
22.09.50 #       <Coldtoast> it's sure easy to get it to clip tho :)
22.10.05 #       <Coldtoast> yeah. with the bass right up, volume gets limited
22.10.21 #       <dpassen1> oh
22.10.22 #       <Lear> yes, preamp works on the sample values, rather than the volume "knob"...
22.18.04 #       <amiconn> Lear: This new id3 info screen is looking rather strange to me :/
22.18.45 #       <Lear> amiconn: what do you mean?
22.18.52 #       <Coldtoast> bass set to 8, treble set to 2, replaygain preamp at 7 seems to sound ok
22.19.23 #       <Lear> coldtoast: remember that preamp is only applied to files with replaygain information...
22.19.24 #       <amiconn> Lear: I find it harder to read and use than the old one-tag-per screen implementation
22.19.41 #       <Coldtoast> Lear: yeah. I replaigained my whole collection the othe rday
22.19.58 #       <amiconn> Especially irritating is the 2-line alternating between the field name and content
22.20.16 #       <amiconn> Looks really strange on my recorder with rockfont-8
22.20.36 #       <Lear> you have a point, but I thought it looked silly with only two rows on text on a screen that fits 10+, so I tried to do something about it...
22.21.36 #       <amiconn> Yes, and I know that having field name and content side-by-side isn't that good an idea either. The displays aren't that large, even on H1x0
22.22.28 #       <amiconn> I think this would only work nicely with icons for the fields, but then we would need decent and resource-conserving vector icons...
22.22.35 #       <Coldtoast> what sort of impact will all this replaygain stuff have on battery life?
22.23.02 #       <Lear> very little. I can't see any difference in boost rate at least...
22.23.20 #       <Coldtoast> excellent
22.23.34 #       <Coldtoast> heh. I've not charged my player in 2 weeks... just realised
22.24.04 #       <Coldtoast> I think since putting the 2200mAH battery in, I've charged it 3 times in teh last month
22.24.18 #       <Coldtoast> only using it about 15hrs a week tho
22.24.23 #       <Moos> apear you don't use it a lot
22.24.28 #       <Moos> a ok
22.29.08 Join    hanklords [0] (n=hank@gov91-1-82-234-90-79.fbx.proxad.net)
22.37.18 #       <Lear> linusn: in your mpa.c update, what was the reason for putting the first call to recalc_samplecount() inside the while loop? It was outside before the change...
22.41.08 #       <LinusN> i didn't see a need to call it outside the looå
22.41.11 #       <LinusN> loop
22.42.04 #       <Lear> well, I see no need to call it inside the loop... :)
22.42.04 #       <LinusN> it needs to be called inside the loop anyway if the frequency divider changes
22.42.18 #       <amiconn> Hmm, could someone with a better knowledge of perl please fix buildzip.pl to not include an empty codecs/ dir for hwcodec units?
22.42.22 #       <Lear> well, you have the second call for that, in the "if frequency changed" block.
22.42.37 #       <Bagder> amiconn: sure, I'll give it a check
22.42.39 #       <LinusN> oops
22.42.51 #       <LinusN> it was late :-)
22.43.28 #       <Lear> I'm looking at gapless improvements, so I can take that...
22.43.33 #       <LinusN> thanks
22.43.40 #       <Lear> stop_skip should be used...
22.43.53 #       <LinusN> i'm struggling with the fm radio i2c
22.44.28 #       <Lear> ah, so it is difficult... good news that you're working with it though. :)
22.44.48 #       <LinusN> should be very easy, but i can't get it to work for some reason
22.45.04 #       <amiconn> I'm currently testing my updated german translation
22.45.13 #       <amiconn> Replaygain gave me a hard time ....
22.47.07 #       <Lear> using stop_skip seems to completely remove the glitch in the sine test case. :)
22.47.56 #       <Lear> amiconn: Probably better off not translating it...
22.48.01 #       <LinusN> yeah, i didn't bother to fix that in my update
22.48.36 #       <Lear> now I just need to make sure it doesn't quit too early...
22.48.57 #       <Coldtoast> writing ID3 tags isn't going to affect replaygain info is it?
22.49.05 #       <Coldtoast> probably a silly question
22.49.50 #       <Lear> as long as the program updating the tags leaves the TXXX frames, no...
22.50.25 #       <Coldtoast> I'll give foobar2k a try
22.50.31 #       <Coldtoast> I usually use Tag & Rename
22.50.32 Join    elinenbe [0] (i=elinenbe@207-237-225-9.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com)
22.50.56 ***     Saving seen data "./dancer.seen"
22.52.14 #       <amiconn> Lear: I don't think so. Not translating it would lead to many so-called (in german) "denglisch" phrases, which I severely dislike...
22.53.11 #       <amiconn> ...or I would have to leave many more expressions untranslated, which jeopardises the purpose of a language file...
22.53.39 #       <LinusN> as i see it, Replaygain is a name, much like a trademark
22.53.58 #       <LinusN> not supposed to be translated
22.54.24 #       <LinusN> like "Windows"
22.54.37 #       <amiconn> LinusN, different question for you: What would I have to do to get some optimised asm routines considered for inclusion by the gcc team?
22.54.59 #       <LinusN> send a patch to the gcc mailing list
22.55.09 #       <Lear> Interesting... Samplecount seems to be very reliable, but the time estimate is can be a couple of seconds off (for a long file).
22.55.20 #       <amiconn> I can't do a proper patch against the gcc source
22.55.35 #       <amiconn> I don't know how gcc includes its library routines
22.55.51 #       <amiconn> I'm talking about my optimised 64 bit multiplication routines
22.56.13 #       <LinusN> join the mailing list and ask them
22.56.34 #       <LinusN> i don't really know myself
22.56.40 #       <amiconn> The SH1 routine is around 2.5 times faster than the (obviously compiled from plain C) version, and the coldfire routine is ~10% faster than the already optimised gcc routine
22.57.03 #       <amiconn> ...and of course both routines are also smaller than the originals
22.57.17 #       <LinusN> do they work on all coldfire variants?
22.57.37 #       <amiconn> They should work on all coldfire v2 variants
22.58.00 #       <amiconn> No exotic instructions used
22.58.21 #       <amiconn> Perhaps they work on even more 68k derivates; I can't test...
22.59.12 #       <amiconn> The SH1 routine should also work on SH2 and SH-DSP, but I don't know whether gcc already has optimised routines for these
22.59.31 #       <amiconn> ...and of course it wouldn't be the optimal routine for these
22.59.36 #       <Lear> most exotic is mulu.l, afaict, so it should work on most...
22.59.58 #       <amiconn> mulu.l is just 32x32->32bit
23.00.26 #       <amiconn> I am relying on that truncation
23.00.37 #       <Lear> yes, but not all cpu:s have them, afaicr. E.g., 68000 lacks it, I think.
23.00.55 #       <amiconn> Yes, the very old variants don't have that
23.04.49 Join    Cassandra [0] (n=cassandr@82-70-230-150.dsl.in-addr.zen.co.uk)
23.05.43 #       <Cassandra> Hello all.
23.06.12 #       <amiconn> hi Cassandra
23.06.26 #       <Cassandra> I swear there is some sort of conspiracy.  The feature freeze coincides with my holiday.  I'll have about 5 days of freeze to do the manual in.
23.10.35 #       <Coldtoast> heh. pointless game of the day: translate a phrase from English to some other language using Babelfish then translate the result back to English
23.10.41 #       <amiconn> Cassandra: Certainly not from my side. I was on a trip to Rome when Daniel announced the freeze...
23.11.18 #       <Cassandra> ami: Oh, I'm not blaming anyone.  Just bad luck.
23.11.31 #       <Cassandra> I'll see if I can get some done next week anywayl.
23.11.38 #       <Coldtoast> night
23.11.41 Quit    Coldtoast ("Peace and Protection 4.22")
23.12.21 #       <Cassandra> *sigh* Player now has a working hard disk in it, but still won't boot.
23.12.45 #       <Cassandra> I was hoping to have it running in time for the 2.5 manual, but looks like I'm going to have to manage without it.
23.13.08 #       <Cassandra> I'm impressed by how thoroughly someone managed to knacker this unit.
23.18.56 Join    stripwax_ [0] (n=stripwax@213-228-241-36.dsl.prodigynet.co.uk)
23.19.09 #       <stripwax_> hello
23.21.04 Quit    Rick (Read error: 104 (Connection reset by peer))
23.21.33 Join    Rick [0] (i=rick@pool-71-108-13-143.lsanca.dsl-w.verizon.net)
23.23.36 #       <amiconn> Cassandra: You should get in contact with [IDC]Dragon
23.24.08 #       <amiconn> He has a big pile of archoses (mostly players) from an aucktion of defective units
23.24.39 #       <amiconn> Some of them are probably only missing a harddisk to get them working again
23.26.05 Quit    Rick (Read error: 104 (Connection reset by peer))
23.27.11 Join    Rick [0] (i=rick@pool-71-108-13-143.lsanca.dsl-w.verizon.net)
23.30.40 #       <amiconn> LinusN: Btw, the protection from extraneous calls also fixes a glitch in Info->Debug->CPU frequency  that I observed some time ago
23.32.19 #       <stripwax_> When I'm looking at the playback thread debug info on rockbox, it looks like the pcm buffer never gets fully full.  is that expected?   also it never gets anywhere near empty either   (seems to get to about 60% full before boost kicks in when playing q5 oggs ->  boost ratio of about 25%).    Is this not aggressive enough?
23.33.19 #       <amiconn> Pressing SELECT very short did set the CPU to 11 MHz, but holding it a bit longer resetted it again to 48 MHz. Pressing Left/Right or other unassigned buttons did the same - now I know why...
23.35.22 #       <Lear> stripwax_: the "watermark" of the pcm buffer is quite high, that's why boost kicks in soon. I've tried with a reduced watermark, and it seems to work well...
23.35.22 #       <LinusN> amiconn: glitch? you mean that it flickers beween 120 and 48 mhz?
23.35.44 #       <amiconn> [23:33:19] <amiconn> Pressing SELECT very short did set the CPU to 11 MHz, but holding it a bit longer...
23.35.53 #       <LinusN> ah
23.36.31 #       <amiconn> That was because of the button events triggering that very short boost/unboost sequence...
23.36.52 #       <stripwax_> Lear - any idea why it's set so high?   also any idea why (it seems like) the buffer never gets fully filled?
23.38.15 #       <Lear> not really, no. It made some sense to have it that large when the pcmbuffer was 3 times larger, but perhaps I just wasn't reduced when the pcmbuf was reduced...
23.38.29 #       <Lear> as to filling, I don't know really...
23.38.44 #       <stripwax_> Lear  -  ahhhh....    didn't know pcmbuf was reduced.   yeah, that could well be it
23.38.47 #       <stripwax_> thx
23.39.21 Join    Strath [0] (i=mike@dgvlwinas01pool0-a217.wi.tds.net)
23.39.48 Join    ender` [0] (i=ychat@tm.213.143.74.124.dc.telemach.net)
23.47.07 Join    Craig__ [0] (n=chatzill@dpc6682050001.direcpc.com)
23.48.09 #       <LinusN> amiconn: are you working on the unboost fix too?
23.48.17 #       <amiconn> Just committed...
23.48.54 #       <LinusN> gr8
23.48.56 #       <amiconn> It was indeed as simple as to send an event to the backlight thread, and unboost from there
23.49.05 #       <LinusN> neat
23.52.02 #       <Craig__> hi all. anyone interested in a patch "prompt user to save modified current playlists if some action is about to wipe it"?
23.53.03 #       <amiconn> I think this would be rather annoying...
23.53.43 #       <Craig__> more annoying than losing a playlist it took an hour to make?
23.54.15 #       <amiconn> That never happened to me, being a rockbox user for over 2 years now
23.55.21 #       <Craig__> I'm an iRiver user, and currently the difference is between a long and a short push. It's come up in the forums before I believe.
23.55.30 #       <amiconn> (referring to both loosing a playlist unintentionally, and also making a playlist taking that long)
23.55.58 #       <Lear> He, I'm not sure if I've ever saved a playlist from Rockbox (other than by mistake)...
23.56.11 #       <amiconn> Yes I know what the difference is. It's the same on archos, not from the beginning, but for quite some time now
23.56.27 #       <amiconn> I don't understand how you can get this wrong
23.57.17 #       <amiconn> The actions are assigned in a way that the safer action happens (just displaying the context menu) if you accidentally push longer than intended
23.57.25 #       <Craig__> Use case: sitting around the camp fire. Passing the iRiver around the friends saying "pick the next few tracks". They will always lose it
23.58.22 #       <Craig__> No, short push is make new dynamic playlist from directory. Long push is go to menu to add to playlist.