--- Log for 10.08.105  Server: brown.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 1 day and 11 hours ago

00.05.00 Join    cpenner [0] (n=d1595386@labb.contactor.se)
00.06.17 Quit    cpenner (Client Quit)
00.07.54 Join    Stryke` [0] (n=Chairman@cpe-24-168-110-99.si.res.rr.com)
00.11.07 Join    amiconn_ [0] (n=jens@p54BD571C.dip.t-dialin.net)
00.11.49 #       <Stryke`> anyone know any *nix mp3 player that can read/write replaygain id3v2 tags?
00.12.20 #       <crwl> i still suppose amarok can ;) 
00.12.41 #       <Stryke`> i looked at amaroks website
00.13.06 #       <Stryke`> not yet, i'm afraid
00.13.09 #       <webguest33> What does foobar's replaygain actually do?
00.13.20 #       <webguest33> Is it comparable to vorbisgain, or does it alter the mpeg frames?'
00.13.38 #       <Stryke`> very comparable to vorbisgain
00.13.47 #       <Stryke`> writes tags to apev2 or id3v2, depending on setting
00.14.38 #       <Moos> in id3v2 if you want to use it with Rockbox :)
00.14.43 #       <Stryke`> exactly
00.14.45 #       <crwl> Stryke`, hm, i just changed a title tag in a mp3 file to "blahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblah" in amarok and it shows ok at least in commandline madplay
00.14.51 #       <crwl> can't be id3v1
00.15.04 #       <Stryke`> oh, i know it supports id3v2
00.15.08 #       <Stryke`> its the replaygain i care about
00.15.21 #       <crwl> oops, oh :D 
00.15.42 #       <Stryke`> the only thing keeping me on windows at this point is foobar's replaygaining
00.15.49 #       <crwl> (hm, there's something odd in those id3v2 tags amarok writes - the commandline id3v2 tool doesn't recognize them)
00.16.12 #       <crwl> but i think there's no tool that adds replaygain stuff to id3v2 tags
00.16.25 #       <crwl> someone should patch the commandline version of mp3gain :P
00.16.34 #       <Stryke`> mp3gain is a different animal
00.16.44 #       <Moos> why don't use foobar?
00.16.53 #       <crwl> it does the same calculations, doesn't it? 
00.16.59 #       <Stryke`> it changes the headers, a player doesnt have to be replaygain compliant to play it
00.17.01 #       <webguest33> Well, it shouldn't be too hard to make it just write a tag instead of alter each frame
00.17.07 #       <Stryke`> it doesnt store its info in tags
00.17.12 #       <Stryke`> Moos: through wine?
00.17.12 #       <crwl> Stryke`, and that's why i said someone should patch mp3gain so it wouldn't do that
00.17.12 #       <Moos> i use foobar and it work like a charm
00.17.35 #       * webguest33 ponders filing a RFE with mp3gain
00.17.57 #       <Moos> i believe mp3gain don't use id3v2 tags
00.18.20 #       <webguest33> Which is the enhancement I'd be requesting
00.18.23 #       <crwl> it stores its undo information somewhere...
00.18.25 #       <webguest33> the ability to do that instead of altering the headers
00.18.39 #       <crwl> ah, in ape tags, it seems
00.18.41 #       <Moos> crwl: APE tag
00.18.43 #       <webguest33> ew
00.19.10 #       <Stryke`> APE tags are nice
00.19.26 #       <webguest33> But why..
00.19.29 #       <Moos> but don't implemented in Rockbox :)
00.19.36 Quit    amiconn (Read error: 60 (Operation timed out))
00.19.37 Nick    amiconn_ is now known as amiconn (n=jens@p54BD571C.dip.t-dialin.net)
00.19.46 #       <webguest33> What's the point of APE tags?
00.19.46 #       <Stryke`> yeah, they're so fast because they're at the end of the file like id3v1
00.20.13 #       <webguest33> How's that faster?
00.20.26 #       <crwl> the cleanest way might be to patch mp3gain to not change the frames and just add the ape tag and then patch rockbox to understand APE replaygain tags :P
00.20.39 #       <Stryke`> the whole file sometimes has to be re-written if the id3v2 tags were written without sufficient padding
00.20.39 #       <Moos> Lear it was the man who implemented Replaygain, maybe he will can the current patch of Frederic
00.21.17 #       <webguest33> Stryke`: oh that, well that only goes when tagging, which is a one-time offence
00.21.44 #       <webguest33> And having the tag at the beginning makes a whole lot more sense with streaming
00.21.46 #       <Stryke`> well on the programming side, most software doesnt 'fully' support id3v2, which should allow unicode tags
00.22.02 #       <crwl> all these mp3 tagging systems are pain in the ass
00.22.04 #       <webguest33> most software doesn't support ape tags at all
00.22.13 #       <Moos> true
00.22.34 #       <Stryke`> foobar is still the best example of gapless/replaygain/ape or id3v2
00.22.55 #       <Moos> foobar is excellent
00.23.17 #       <Stryke`> yes, i wish they're was a true *nix equivalent
00.23.48 #       <crwl> *nix equivalent would be to screw all those zillion nonstandard ways of doing the same thing and use ogg vorbis ;P
00.23.54 #       <Stryke`> heh
00.25.06 #       <webguest33> does foobar run on a multiuser windows system?
00.25.14 #       <webguest33> (not running as admin)
00.25.19 #       <Stryke`> yes, with per-user settings, i believe
00.28.55 #       <Moos> hardeep: Hi, are you here?
00.37.38 #       <Moos> probably not
00.37.55 #       <Moos> good night (or day) all
00.38.05 Quit    Moos (" HydraIRC -> http://www.hydrairc.com <- The future of IRC")
00.39.18 Quit    Luthion ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )")
00.44.18 Join    TCK [0] (i=TCK@81-86-97-222.dsl.pipex.com)
00.50.02 ***     Saving seen data "./dancer.seen"
01.05.46 Quit    hicks (Read error: 110 (Connection timed out))
01.12.15 Part    LinusN
01.23.19 #       <webguest33> Ah. Let's hope for a smarter convbdf.
01.26.30 Quit    t0mas ("CGI:IRC")
01.39.06 #       <stripwax_> webguest33 - is that the problem?
01.43.48 #       <webguest33> See the latest commit
01.47.15 Join    EBounding [0] (n=EBoundin@pcp02855240pcs.roylok01.mi.comcast.net)
01.47.23 #       <webguest33> Hm, or maybe the bitmap_t is in rockbox. Either way, it would be nice to be able to have >16 pixel wide fonts
01.53.32 Join    Febs [0] (n=Febs@207-172-122-81.c3-0.rdl-ubr4.trpr-rdl.pa.cable.rcn.com)
02.01.23 Join    sockerteze [0] (n=sockerte@pool-162-84-114-192.norf.east.verizon.net)
02.09.27 Quit    sockerteze ("Chatzilla 0.9.68.5 [Firefox 1.0.4/20050511]")
02.26.44 Quit    bluebrother^ (Read error: 110 (Connection timed out))
02.26.46 Quit    Stryke` ("Friends don't let friends listen to Anti-Flag")
02.35.17 Quit    EBounding (Read error: 60 (Operation timed out))
02.50.03 ***     Saving seen data "./dancer.seen"
02.50.36 Quit    stripwax_ (Read error: 110 (Connection timed out))
02.54.30 Quit    webguest33 ("CGI:IRC (Ping timeout)")
03.01.32 Quit    thegeek (Read error: 54 (Connection reset by peer))
03.06.02 Quit    Asku (brown.freenode.net irc.freenode.net)
03.06.02 NSplit  brown.freenode.net irc.freenode.net
03.06.02 Quit    mbr (brown.freenode.net irc.freenode.net)
03.06.02 Quit    dwihno (brown.freenode.net irc.freenode.net)
03.06.02 Quit    crashd (brown.freenode.net irc.freenode.net)
03.07.35 Join    crashd [0] (i=nobody@badger.ing.me.uk)
03.08.25 Join    mbr [0] (n=mb@stz-softwaretechnik.de)
03.08.42 Join    dwihno [0] (n=dw@81.8.224.89)
03.11.37 Join    Asku [0] (n=aksu@adsl-39.180-DynIP.ssp.fi)
03.18.09 Quit    edx (Read error: 104 (Connection reset by peer))
03.18.50 Join    thegeek [0] (n=thegeek@s201a.studby.ntnu.no)
03.22.19 Quit    thegeek (brown.freenode.net irc.freenode.net)
03.22.47 NHeal   brown.freenode.net irc.freenode.net
03.22.47 NJoin   thegeek [0] (n=thegeek@s201a.studby.ntnu.no)
03.27.07 Part    courtc ("Leaving")
03.27.20 Join    edx [0] (i=edx@p54A8EB85.dip.t-dialin.net)
03.31.26 Nick    Sucka is now known as Sucka`zZzZz (N=NNSCRIPT@host81-156-208-120.range81-156.btcentralplus.com)
03.38.38 Quit    thegeek (Read error: 54 (Connection reset by peer))
03.39.29 Join    thegeek [0] (n=thegeek@s201a.studby.ntnu.no)
03.41.05 Quit    thegeek (brown.freenode.net irc.freenode.net)
03.41.05 NSplit  brown.freenode.net irc.freenode.net
03.41.16 NHeal   brown.freenode.net irc.freenode.net
03.41.16 NJoin   thegeek [0] (n=thegeek@s201a.studby.ntnu.no)
03.45.23 Quit    thegeek (brown.freenode.net irc.freenode.net)
04.05.52 Join    QT [0] (i=as@madwifi/users/area51)
04.16.01 Join    EBounding [0] (n=EBoundin@pcp02855240pcs.roylok01.mi.comcast.net)
04.16.04 Quit    tvelocity ("Leaving")
04.18.03 Quit    QT_ (Read error: 110 (Connection timed out))
04.22.47 Quit    EBounding ()
04.48.28 Quit    edx (Read error: 110 (Connection timed out))
04.50.05 ***     Saving seen data "./dancer.seen"
04.52.16 Quit    hardeep ("Read error: 69 (Excessive tongue)")
04.59.01 Join    solex [0] (n=jrschulz@c204182.adsl.hansenet.de)
05.11.35 Quit    solex_ (Read error: 110 (Connection timed out))
05.25.14 Join    Speedforneed [0] (N=Blake@c-66-41-251-246.hsd1.mn.comcast.net)
05.29.06 Quit    Strath ("Client closed")
05.36.03 Join    Strath [0] (i=mike@dgvlwinas01pool0-a234.wi.tds.net)
05.37.10 Quit    Strath (Client Quit)
06.16.20 Quit    Febs (" HydraIRC -> http://www.hydrairc.com <- State of the art IRC")
06.22.56 Join    edx [0] (i=edx@p54A8D85C.dip.t-dialin.net)
06.38.06 Join    DarkkOne [0] (n=chatzill@cpe-66-68-93-2.austin.res.rr.com)
06.44.01 Quit    alxcm ("leaving")
06.50.09 ***     Saving seen data "./dancer.seen"
07.03.09 #       <ReKleSS> anyone know why the rockbox simulator would be dying with a floating point exception?
07.10.45 Quit    DarkkOne (Read error: 104 (Connection reset by peer))
07.34.31 Join    Cka3ka [0] (n=Cka3ka@ool-4355b700.dyn.optonline.net)
07.34.51 #       <Cka3ka> hey hey
07.35.04 #       <Cka3ka> its so quiet :-\
07.40.16 #       <Cka3ka> anyone still awake?
07.41.15 Quit    Cka3ka ()
07.45.24 Join    Coldtoast [0] (i=edan@ppp110-114.lns1.hba1.internode.on.net)
07.45.28 #       <Coldtoast> hey all
07.45.53 #       <Coldtoast> which build doesn't have the volume bug? I need to download the last one before the bug
07.46.50 #       <Coldtoast> I haven't been able to use Rockbox since the volume bug and don't really want to have to keep trying dailys til I find the last one that doesn't have it
07.51.27 #       <Coldtoast> is thre a reason it's been unfixed since it was introduced? it's been about a week since the prob has been there and it makes Rockbox pretty much unusable. have ppl been unable to find what the problem is?
08.15.17 Join    Nibbler [0] (n=sven@port-212-202-193-100.dynamic.qsc.de)
08.21.35 Join    NibbIer [0] (n=sven@port-212-202-78-84.dynamic.qsc.de)
08.29.01 Quit    einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
08.31.29 Join    xNibbler [0] (n=sven@port-212-202-193-100.dynamic.qsc.de)
08.32.12 Quit    Nibbler (Read error: 104 (Connection reset by peer))
08.36.12 Part    amiconn
08.41.54 Join    Nibbler [0] (n=sven@port-212-202-78-84.dynamic.qsc.de)
08.42.00 Quit    NibbIer (Read error: 104 (Connection reset by peer))
08.43.06 Join    amiconn [0] (n=jens@p54BD571C.dip.t-dialin.net)
08.50.12 ***     Saving seen data "./dancer.seen"
08.51.33 Join    NibbIer [0] (n=sven@port-212-202-193-100.dynamic.qsc.de)
08.52.03 Quit    xNibbler (Read error: 104 (Connection reset by peer))
08.53.36 Part    NibbIer ("Leaving")
08.53.43 Join    LinusN [0] (N=linus@labb.contactor.se)
09.00.27 Join    einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de)
09.02.17 Quit    Nibbler (Read error: 104 (Connection reset by peer))
09.06.06 Join    bluebrother^ [0] (n=c28@nat-ph3-wh.rz.uni-karlsruhe.de)
09.18.30 #       <bluebrother^> Coldtoast: still here?
09.18.52 #       <bluebrother^> ths bug has been discussed yesterday (or was it the day before?), just read the logs.
09.22.01 Join    webguest30 [0] (n=c31ce021@labb.contactor.se)
09.22.48 #       <Coldtoast> yep
09.22.56 #       <Coldtoast> ah ok
09.23.30 #       <Coldtoast> I found the last build that doesn't have it: 20050730
09.24.01 #       <Coldtoast> at least now I can take my h140 to the gym and use it. heh
09.24.07 #       <bluebrother^> to me that was 050726 ...
09.24.28 #       <Coldtoast> interesting there'd be a difference
09.24.57 #       <LinusN> which bug?
09.25.25 #       <bluebrother^> the volume bug.
09.25.28 #       <Coldtoast> when you change the volume, when it gets to around 80% (83 for me) it slows to a crawl and the volumd doesn't actually change
09.26.00 #       <Coldtoast> the WPS shows voluem changes about once a sec but the volume doesn't change and the player tends to become unresponsive
09.26.22 #       <Coldtoast> if you then change all the way down to 0, for example, the WPS shows the volume change but the volume doesn't actually change
09.26.28 #       <Coldtoast> but the track keeps playing fine
09.26.58 #       <Coldtoast> to turn it off, you have to hold in the button and it eventually responds
09.27.18 #       <LinusN> i sat all night trying to fix that bug
09.27.31 #       <LinusN> it's really hard to reproduce for me
09.27.48 #       <Coldtoast> it does it 100% of the time for me
09.28.09 #       <Coldtoast> if I change volume at full speed
09.28.19 #       <LinusN> does it matter which song you're playing?
09.28.26 #       <Coldtoast> nope
09.28.35 #       <bluebrother^> I sometimes had the impression this bug happens less when compiled with debug mode on.
09.28.36 #       <Coldtoast> I've only tried MP3 tho
09.28.36 #       <LinusN> whicih build?
09.28.45 #       <Coldtoast> from every build after 20050730
09.29.06 #       <Coldtoast> I'll try the latest now tho if you want
09.29.11 #       <LinusN> please do
09.29.27 #       <bluebrother^> for me this occured after amiconn's timer changes on 050727
09.31.09 #       <Coldtoast> LinusN
09.31.17 #       <Coldtoast> it doesn't do it with the latest!
09.31.22 #       <LinusN> figures
09.31.39 #       <LinusN> did it reset the settings?
09.31.44 #       <Coldtoast> nope
09.32.05 #       <Coldtoast> and I had 20050730 on there
09.32.21 #       <Coldtoast> I've tried builds between 20050730 and this latest bleeding edge and some have tho
09.32.39 #       <Coldtoast> aaah
09.32.41 #       <Coldtoast> yes it does
09.32.51 #       <LinusN> see? it comes and goes
09.32.51 #       <Coldtoast> but it does it much closer to 100%
09.33.16 #       <LinusN> as far as i can see, it's a timing problem, and can happen anytims
09.33.51 #       <Coldtoast> how frustratng for you guys
09.34.01 #       <LinusN> indeed
09.34.17 #       <bluebrother^> ok, got it.
09.34.22 #       <LinusN> as soon as i'm closing in on it, it goes away
09.34.52 #       <bluebrother^> just installed the latest daily. Reproducing took *way* longer than before but I could trigger the bug :(
09.35.08 #       <CoCoLUS> couldn't we just revert amiconn's timer code changes?
09.35.24 #       <LinusN> i'm not sure thay have anything to do with it
09.35.27 #       <LinusN> they
09.36.21 #       <CoCoLUS> you just said it's most likely a timing problem
09.36.28 #       <Coldtoast> will reverting break anything done since?
09.37.08 #       <LinusN> Coldtoast: reverting it will be a pain
09.37.30 #       <LinusN> and i want to know the cause of the bug before i do anything to fix it
09.37.31 #       <Coldtoast> yeah. I'd imagine so. it's been 8 days
09.40.24 #       <LinusN> what happens is that the uda1380 locks up and stops responding on the i2c bus
09.40.42 #       <LinusN> the lagging comes from the timeouts in the i2c driver
09.41.13 #       <LinusN> i've been trying to analyze the i2c bus, but it's difficult when you can't reproduce the bug on demand
09.41.39 #       * LinusN gets some coffee
09.41.43 #       <Coldtoast> wish I could send you my player
09.43.42 Join    UncleBill [0] (n=l@c-24-6-122-83.hsd1.ca.comcast.net)
09.43.51 #       <UncleBill> hello friends
09.44.17 #       <LinusN> hola
09.44.26 #       <Coldtoast> morning/afternoon/evening
09.45.33 #       <UncleBill> I'm interested in playing with the source and building for the iRiver, but nervous I'll crush it. how dangerous is just messing around without owning one of these P&E Wigglers?
09.45.43 #       <UncleBill> heya LinusN, Coldtoast
09.46.17 #       <CoCoLUS> uncle, as long as you don't mess with the bootloader, you're quite safe
09.46.41 #       <UncleBill> is there any functionality in the bootloader beyond booting the image?
09.46.47 #       <CoCoLUS> usb mode
09.46.50 #       <CoCoLUS> for recovery
09.46.54 #       <LinusN> for safety
09.47.22 #       <UncleBill> where can I read on building a development environment and building from source?
09.47.24 #       <LinusN> nobody has killed a player yet by installing rockbox
09.47.37 #       <LinusN> UncleBill: www.rockbox.org
09.47.44 #       <Coldtoast> wonder if anybody's managed to revive their player
09.47.57 #       <LinusN> revive from what?
09.48.03 #       <CoCoLUS> http://www.rockbox.org/twiki/bin/view/Main/CrossCompiler
09.48.08 #       <Coldtoast> from being bricked
09.48.34 #       <Coldtoast> by the stupid Iriver fw
09.48.34 #       <UncleBill> why there it is. don't know how I missed it. thx
09.48.40 #       <LinusN> http://www.rockbox.org/twiki/bin/view/Main/DevelopmentGuide
09.49.13 #       <Coldtoast> if there had been a bootloader for the h300, my friend wouldn't have had to RMA his player. heh
09.49.16 #       <LinusN> UncleBill: the "documentation" section on rockbox.org has all you need
09.49.30 #       <UncleBill> righteous
09.49.32 #       <Coldtoast> his got bricked the second day he had it
09.49.41 #       <UncleBill> this is a good thing you guys have going
09.50.10 #       <Coldtoast> he thinks it's cos he created a corrupted DB and enabled DB mode
09.50.30 #       <CoCoLUS> uncle, rockbox is great yes, as long as you don't try to change the volume... ;)
09.51.06 #       <LinusN> :-)
09.54.25 #       <CoCoLUS> it's interesting how one accepts bad products when there's no alternative
09.54.52 #       <CoCoLUS> everytime i use the original firmware now, i get seizures having to endure that font size
09.54.54 #       <Coldtoast> bad products?
09.55.01 #       <Coldtoast> oh. heh
09.55.25 #       <Coldtoast> it's funny tho
09.55.38 #       <Coldtoast> I've always liked my h140
09.55.53 #       <Coldtoast> even before rockbox,
09.56.14 #       <Coldtoast> I never realised how rough the iriver fw sounded tho. For things liek changing tracks
09.56.41 #       <Coldtoast> with teh iriver fw, I get a little glitch of sound just before it switches tracks. I'd never noticed it before
09.57.25 #       <CoCoLUS> you never noticed that -huge- gap between tracks?
09.57.34 #       <Coldtoast> of course I noticed that
09.58.22 #       <Coldtoast> that doesn't bother me as much as the shitty noise you hear when changng tracks tho
09.58.40 #       <Coldtoast> rockbox used to do it but Slasher fixed it
10.17.40 Join    ashridah [0] (i=ashridah@220-253-123-2.VIC.netspace.net.au)
10.18.21 Quit    merbanan (Read error: 104 (Connection reset by peer))
10.18.23 Join    banan_ [0] (i=banan@dalink.campus.luth.se)
10.24.21 Quit    banan_ (Read error: 104 (Connection reset by peer))
10.24.22 Join    banan__ [0] (i=banan@dalink.campus.luth.se)
10.50.15 ***     Saving seen data "./dancer.seen"
11.24.27 #       <amiconn> hi
11.24.42 #       * amiconn spots LinusN, aka Mr. mpeg.c ...
11.25.16 #       <amiconn> LinusN: are you around?
11.27.38 #       <ReKleSS> anyone know if alexspy comes on here?
11.28.05 #       <ReKleSS> or, has anybody else done anything about the remote wps/file tree?
11.30.40 Join    arfo_____ [0] (n=arfo@e178114228.adsl.alicedsl.de)
11.31.34 Nick    arfo_____ is now known as arfo (n=arfo@e178114228.adsl.alicedsl.de)
11.31.34 Quit    arfo (Client Quit)
11.32.31 Join    arfo [0] (n=arfo@e178114228.adsl.alicedsl.de)
11.35.34 #       <LinusN> amiconn: i'm here now
11.35.51 #       <LinusN> ReKleSS: no, we haven't worked on it
11.36.41 #       <ReKleSS> ok
11.36.42 #       <amiconn> LinusN: I found a bug in mpeg.c, immediately before my trip to Rome
11.37.05 #       <amiconn> mpeg.c, line 691 caused a NULL pointer access
11.37.13 #       <ReKleSS> that's the main thing stopping me from using rockbox instead of the original firmware, I'll start on that when I get a chance... probably this weekend sometime
11.37.23 #       <amiconn> Obviously it doesn't happen always
11.37.49 #       <LinusN> if (num_tracks_in_memory() > 1)
11.39.00 #       <LinusN> how can that cause a NULL pointer access?
11.39.14 #       <LinusN> which version of mpeg.c?
11.39.25 Join    XavierGr [0] (n=XavierGr@ppp28-adsl-244.ath.forthnet.gr)
11.39.33 #       <ReKleSS> well that was good timing...
11.40.16 #       <ReKleSS> XavierGr: you're alexspy, right?
11.40.25 #       <amiconn> LinusN: Ah, that was my modified version (the modifications don't influence this part; only recording)
11.41.24 #       <amiconn> It's line 696 in the cvs version
11.41.42 #       <amiconn> (the track->mempos access)
11.42.03 #       <XavierGr> yeah and hi
11.42.21 #       <ReKleSS> err... hi :p
11.42.31 #       <ReKleSS> how much progress have you made on the remote lcd stuff?
11.43.02 #       <LinusN> ok, so track_offset is off limits
11.43.51 #       <amiconn> My suspicion is that it happens if lines 664..672 detect a trackchange, and then line 691 checks num_tracks_in_memory() again, the count has not yet been updated
11.43.53 #       <XavierGr> Well it displays correctly the tree and the wps. Also there are many options to change and save. But there's still a bad bug that I can overcome by enabling an option to render the main unit OR the remote. See link
11.44.30 #       <XavierGr> http://www.misticriver.net/boards/showthread.php?t=25650
11.45.38 #       <amiconn> LinusN: I'm considering to permanently enable the memory guard on archos, "catch zero area" mode. Should help uncovering some bugs, but it's less convenient for the user...
11.45.50 #       <XavierGr> Unfortunately this is not a smart way to implement the remote. So it is a temporary way to use the remote until someone takes the task to do more proffesional work. Maybe after a lot of work I could make that happen we will see, no promises though
11.47.15 #       <XavierGr> amiconn: I have a new snake2.c file with 2 bugfixes of the hiscore. Are you interested?
11.49.27 #       <XavierGr> Also have you noticed that the simulator crashes (when changing char pointers in some manner) when the real player runs them correctly?
11.50.16 #       <XavierGr>     file = "/pic.jpg";
11.50.16 #       <XavierGr>     filepath = "/Image";
11.50.16 #       <XavierGr>  
11.50.16 DBUG    Enqueued KICK XavierGr
11.50.16 #       <XavierGr>     filename = rb->strcat(filepath,file);
11.50.16 #       <XavierGr>     rb->splash(HZ, true, filename);    
11.50.41 #       <XavierGr> this will crash the simulator but my player splashes a box with the whole filename.
11.51.26 #       <Slasher> XavierGr: eh, you can't do that
11.51.39 Nick    Sucka`zZzZz is now known as Sucka (N=NNSCRIPT@host81-156-208-120.range81-156.btcentralplus.com)
11.52.00 #       <XavierGr> why?
11.52.10 #       <XavierGr> my player runs fine with it...
11.52.11 #       <Slasher> XavierGr: you are trying to copy a longer string to the filepath that it has allocated memory
11.52.16 #       <Slasher> so it will overwrite something
11.52.47 #       <XavierGr> any better way to copy the whole string into 1 variable?
11.52.48 #       <Slasher> and generally you should never modify a constant string
11.53.46 #       <Slasher> char buf[40]; strncpy(buf, file, sizeof(buf)-1);
11.53.53 #       <Slasher> something like that should work
11.54.40 #       <Slasher> now i have to go ->
11.56.08 #       <XavierGr> bye Slasher.
12.00.43 Part    arfo
12.03.45 #       <LinusN> amiconn: it should be safe to change it so it checks the return value of get_trackdata() instead of num_tracks_in_memory()
12.08.56 #       <amiconn> The problem is that I don't fully understand the 'magic' done in transfer_end()
12.10.23 #       <amiconn> What do you think about enabling 'memory guard' to aid debugging?
12.10.33 #       <LinusN> fine with me
12.11.04 #       <LinusN> transfer_end() is not among the easiest parts of mpeg.c :-)
12.12.52 #       <LinusN> how do you go about to reproduce the bug?
12.14.33 #       <amiconn> I just enabled the memory guard and started playing music. After a couple of tracks I got a UserBrk interrupt.
12.15.23 #       <amiconn> I spotted the exact point with the help of the .map file and a disassembler listing
12.16.18 #       <amiconn> (fyi, I was using my Studio when this happened, but it should be model independent)
12.20.29 Join    Moos [0] (i=DrMoos@m29.net81-66-158.noos.fr)
12.20.48 #       <Moos> Hello guys ! :)
12.23.03 #       <LinusN> amiconn: i'll see if i can check it out this evening
12.23.43 Join    Febs [0] (n=Febs@207-172-122-81.c3-0.rdl-ubr4.trpr-rdl.pa.cable.rcn.com)
12.23.52 #       <XavierGr> hi Moos and Febs.
12.24.03 #       <Febs> Good morning.
12.24.28 #       <Moos> morning guys
12.29.50 Join    psychocydd [0] (i=psychocy@host217-44-38-58.range217-44.btcentralplus.com)
12.30.14 Part    psychocydd
12.34.32 #       <Coldtoast> anybody want to go to work for me?
12.36.42 #       <LinusN> tough question, where do you work?
12.38.25 #       <Coldtoast> nightclub. I'm a bouncer
12.41.03 #       <XavierGr> what's a bouncer?
12.41.53 #       <Coldtoast> nightclub security
12.42.04 #       <XavierGr> ohhh...
12.42.30 #       <XavierGr> I don't think I can do that. 
12.42.55 #       <Coldtoast> sure you can. it's great
12.43.14 #       <Coldtoast> each say is better than the next
12.43.15 #       <LinusN> Coldtoast: like "no membership card? get lost!"
12.43.16 #       <XavierGr> I am not so strong to be a security guy.
12.43.18 #       <Coldtoast> say=day
12.43.50 #       <Coldtoast> nah. like "Excuse me. We're non-smoking here. Just need you to take that to the smoking area"
12.43.59 #       <XavierGr> Tough job I would say and dangerous.
12.44.14 #       <Coldtoast> or "If you do that one more time I'm going to have to ask you to leave"
12.44.22 #       <XavierGr> I hope that you get paid well.
12.44.29 #       <Coldtoast> it's ok
12.44.52 #       <Coldtoast> only have to work ~25hrs a week and it's easily enough to live on
12.48.09 #       <Moos> is there any battle with hot guys who drunked much?
12.48.10 #       <Moos> :)
12.48.34 #       <Coldtoast> I'm doing well tho. so far, in the 2+ years I've been doing it, I've not been charged with assault yet nor have I had to visit hospital
12.48.46 #       <Moos> :)
12.49.07 #       <Moos> apear you work in a cool club
12.49.24 #       <Coldtoast> I thought one time I might have had a broken nose but it wasn't. was just a bit crunchy. heh
12.50.02 #       <Coldtoast> the only things that have really happaned are I've damaged my hands once each
12.50.17 ***     Saving seen data "./dancer.seen"
12.50.54 #       <Coldtoast> I can tell you one thing too. NEVER EVER hurt your thumbs. they're teh WORST things to hirt. worse than anything else I've had happen cos they take months to heal. MONTHS
12.51.34 #       <Moos> :)
12.51.54 #       <Coldtoast> I'd rather have a broken nose than damaged thumbs
12.51.58 #       <ReKleSS> coldtoast: what did you do to damage them?
12.52.05 #       <Moos> is it your regular work all the year?
12.52.14 #       <Coldtoast> restraining a guy for too long
12.52.36 #       <ReKleSS> ah
12.52.47 #       <Coldtoast> my you know the "heel" of your thumb? the big meaty part your thumb comes out of?
12.53.24 #       <ReKleSS> I can kind of see what damaging that would do...
12.53.30 #       <Coldtoast> that part went pretty much black and the bruising went all teh way around to the top of my hand near teh thumb and was yellow
12.53.51 #       <Coldtoast> took probably 7 months to heal properly
12.54.11 #       <Coldtoast> anyway. time to go get ready. later
12.54.25 #       <Moos> good day
12.56.22 #       <XavierGr> have a nice day (night) in your work
12.57.12 Join    leftright [0] (n=d4406110@labb.contactor.se)
12.58.04 #       <leftright> LinusN, you around /
12.59.34 #       <leftright> I managed to see RB crash twice on H140, with error IO3 adderr, 31022E3E
13.00.29 #       <leftright> it occured when using FIle Tree playback and it was transitioning from lat song in the album to first song in next album
13.00.41 #       <leftright> lat=last
13.01.41 #       <amiconn> LinusN: I'll see whether I can remember the album where this happened. Perhaps it needs a special constellation of buffer wrap & track change
13.02.04 #       <leftright> mp3 file, no crossfade, RG on, 'Move to next folder set'
13.11.33 #       <Febs> leftright, I've noticed the same thing:  http://forums.rockbox.org/index.php?topic=1163.0
13.12.14 #       <Febs> Except that I had RG off.
13.34.50 Join    Liehbeth [0] (n=negk@adsl-34-224-114.asm.bellsouth.net)
14.08.24 #       <XavierGr> is there a fixed space memory for plugins?
14.09.10 #       <XavierGr> Because when I try to make some big char arrays into the jpeg viewer the pictures aren't displayed correctly
14.24.32 Join    tvelocity [0] (n=tony@chan530-a143.otenet.gr)
14.28.25 Quit    Febs (Read error: 110 (Connection timed out))
14.30.39 #       <LinusN> XavierGr: check the map file
14.41.26 #       <leftright> anyone looked into the feature of ReplayGain going to track mode whenever shufle is enabled ?
14.42.26 #       <leftright> automatically
14.43.51 Part    Liehbeth
14.45.36 Ctcp    Ignored 1 channel CTCP requests in 0 seconds at the last flood
14.45.36 #       * leftright hugs ReplayGain
14.50.18 ***     Saving seen data "./dancer.seen"
14.54.54 #       <XavierGr> LinusN: I wish I knew what is the map file.... :p
14.55.04 Join    hicks [0] (n=hicks@zeus.mups.co.uk)
14.59.51 #       <LinusN> XavierGr: each .rock file has a .map file 
15.00.05 #       <LinusN> in the build dir
15.00.15 #       <XavierGr> ok thanks
15.06.07 #       <XavierGr> LinusN: When I make changes to a specific plug-in. Do I have to replace the .rockbox folder again or can I just throw the plugin there for replacement?
15.13.29 #       <LinusN> just replace the changed files
15.14.39 #       <amiconn> convbdf is a mess... :-/
15.18.56 #       <LinusN> amiconn: tell me about it
15.19.21 #       <LinusN> took me some time to find the 16-pixel bug
15.22.14 #       <amiconn> Yes, and the strange thing is that it shouldn't happen
15.22.32 #       <amiconn> Afaiu convbdf should work for arbitrary widths
15.23.29 #       <amiconn> I also don't understand why it uses this bitmap_t type. Using unsigned char for bitmap data would seem much more straightforward to me
15.23.29 Join    Maxime [0] (n=flemmard@cartec.net2.nerim.net)
15.23.44 #       <amiconn> No endian hassle, ...
15.23.54 #       <LinusN> yes, it could be a lot simpler
15.24.51 #       <LinusN> still, just using a 32-bit type would probably suffice
15.25.18 #       <amiconn> I'll probably throw out all old (non-ROTATEd stuff), then do some rewriting to get rid of the 16 pixel limit
15.25.37 #       <LinusN> have fun :-)
15.25.44 #       <amiconn> Haha :-/
15.26.07 #       <LinusN> i'll see if i can add memguard to the iriver as well
15.26.24 #       <LinusN> at least for the flash
15.26.27 #       <amiconn> I didn't find a comparable feature in the datasheet. Did you?
15.26.53 #       <LinusN> there is a hardware breakpoint unit
15.27.05 #       <amiconn> Does that allow to catch ranges
15.27.14 Join    muesli- [0] (i=muesli_t@Bc0a6.b.pppool.de)
15.27.21 #       <LinusN> yes
15.27.22 #       <muesli-> high
15.27.30 #       <amiconn> The user break controller in the SH1 is really useful for these purposes
15.27.53 #       <LinusN> indeed
15.28.08 #       <amiconn> Do you think renaming the UserBrk interrupt would be helpful?
15.29.18 #       <LinusN> renaming?
15.32.21 #       <amiconn> At the moment, rockbox displays "UserBrk" when memguard is enabled and an illegal access happens
15.32.57 #       <amiconn> We don't use the user break controller for anything else, so it might be useful to change the display name
15.33.24 #       <amiconn> ...to something giving a hint that an illegal memory access happened
15.34.08 #       <amiconn> Btw, on coldfire, there already is a 'hint' if you try to access certain areas (those that contain nothing)
15.34.23 #       <amiconn> Doing this causes the bus to hang.
15.34.38 #       <amiconn> I had to learn this when implementing the grayscale lib
15.37.08 #       <amiconn> I loaded a (byte) index from memory, but didn't obey the fact that the coldfire doesn't do any longword extension (signed or unsigned), unlike the SH1
15.37.42 #       <amiconn> I had to add a clr.l before the load operation...
15.38.21 Quit    ashridah ("Leaving")
15.45.37 Nick    banan__ is now known as merbanan (i=banan@dalink.campus.luth.se)
15.48.18 #       <LinusN> ok, i gotta go now, cu later
15.48.22 Part    LinusN
15.55.24 Quit    webguest30 ("CGI:IRC (EOF)")
16.07.04 #       <XavierGr> amiconn:do you know how can I extract a global_setting.value from a plugin?
16.07.33 #       <XavierGr> Example: I want to know the value of MAX_FILES_IN_DIR the user has from a plugin
16.07.46 #       <XavierGr> Which file I must include?
16.08.50 Quit    muesli- (Read error: 110 (Connection timed out))
16.13.59 #       <amiconn> XavierGr: From a plugin, you should never include other .h files than plugin.h or files from apps/plugins/lib
16.14.13 #       <amiconn> The global settings are available via the plugin api
16.14.37 #       <XavierGr> so to call the value I type rb->global_settings.value?
16.15.32 #       <amiconn> Almost.
16.15.46 #       <amiconn> global_settings is also a pointer in the api, so you need to use
16.15.57 #       <amiconn> rb->global_settings->value
16.16.05 #       <XavierGr> ok thanks!
16.16.27 #       <amiconn> Some plugins already use that, e.g. video.c
16.16.50 #       <XavierGr> One day I must understand this saperation of plug-ins and main threads
16.16.54 #       <amiconn> (not yet functional on iriv3er)
16.17.18 #       <Sucka> hooray! just got an email saying my iriver was repaired under warranty and theyre sending it back
16.17.20 #       * Sucka dances
16.17.30 #       <XavierGr> That's awesome
16.17.42 #       <XavierGr> well we all know iriver and it's replacement policy
16.17.53 #       <Sucka> i sent it back to the retailer actually
16.18.14 #       <Sucka> cheaper postage :D
16.18.32 #       <XavierGr> Whatever, I have heard many stories were the user was to blame but iriver replaced his player.
16.18.54 #       <Sucka> ^_^
16.22.05 #       <XavierGr> what was your case?
16.22.18 #       <XavierGr> What did you do to your player?
16.40.27 Join    ghostiger [0] (n=ghostige@tor/session/x-31680a8dfbecfa05)
16.45.05 Join    thegeek [0] (n=thegeek@s201a.studby.ntnu.no)
16.47.33 Quit    tvelocity ("Leaving")
16.50.21 ***     Saving seen data "./dancer.seen"
17.17.39 #       <XavierGr> which is the best way to reset a char array or a char *pointer?
17.25.23 Join    muesli- [0] (i=muesli_t@Bbc72.b.pppool.de)
17.26.51 Quit    UncleBill ("Client exited.")
17.39.16 Join    Lear [0] (n=chatzill@h244n6c1o285.bredband.skanova.com)
17.39.29 Join    UncleBill [0] (n=l@c-24-6-122-83.hsd1.ca.comcast.net)
17.39.36 #       <UncleBill> hello friends
17.39.54 #       <muesli-> g'day mate+
17.40.02 #       <UncleBill> heya muesli-
17.40.20 #       <muesli-> heyo
17.42.16 #       <XavierGr> hi
17.42.22 #       <Lear> XavierGr: null pointers are bad. :)
17.42.37 #       <XavierGr> I am lost...
17.42.52 #       <XavierGr> I use too many char pointers and then I cant controll them
17.43.26 #       <Lear> I was thinking about the one in the code you sent to the mailing list...
17.43.47 #       <XavierGr> forget that I must send an e-mail to warn not to look at it
17.44.08 #       <XavierGr> it is all wrong. I found something more quick and easy.
17.44.19 #       <XavierGr> Though the char pointer hell still exists
17.44.42 #       <XavierGr> I am trying to make single char arrays but then I am running out of plug-in memory
17.45.06 #       <Lear> sounds like you're creating huge arrays...
17.46.10 #       <XavierGr> well not sooo huge. I have cuted them for my test needs and still...
17.46.35 #       <XavierGr> the bigest char array I've got is 2 dimension [10][50]
17.46.38 #       <XavierGr> is that big?
17.46.58 #       <XavierGr> Though if I am carefull I will not need more that [3][MAX_PATH]
17.48.25 #       <Lear> no, that's not very big, but you must do something to run out of plugin memory (you do mean as in link error?)
17.48.49 #       <XavierGr> Another problem is that I am not used in using pointers. Ahhh old days in Visual Basic were more easy with strings...
17.49.23 #       <XavierGr> well I dont get an error, it is just that when I maximize the size of the arrays the jpeg viewer will not render the files correctly.
17.49.28 #       <XavierGr> Strange isn't it?
17.52.24 #       <XavierGr> You said that you were thinking something about the mail I sent in the list. Do you have a nice advise for me Lear? I could use some help.
17.53.44 #       <Lear> The code in the mail calls on a function to load a directory, but the "context" pointer is never initialized, and thus null.
17.54.05 #       <Lear> as for the rendering problem, as I don't  know much about the inner workings of the jpeg loader, I can't really help you there...
17.55.19 #       <XavierGr> Well I solved that problem.
17.55.21 #       <Lear> as for pointers, it really isn't that hard, once you get used to/learn the concept, but it is something you really need for C programming. :)
17.56.18 #       <XavierGr> Now I use something completely more light and fast to see the contetnts of a directory. (though still there is a gray area which I dont understand)
17.56.26 #       <XavierGr> I will PM it to you.
17.57.20 Join    bagawk [0] (n=lee@unaffiliated/bagawk)
17.59.27 Join    Nibbler [0] (n=sven@port-212-202-78-84.dynamic.qsc.de)
18.04.03 #       <XavierGr> I have to go. Later all!
18.04.05 Quit    XavierGr ()
18.18.18 #       <muesli-> cya mates
18.27.00 Quit    Maxime ()
18.27.00 Quit    muesli- (Read error: 104 (Connection reset by peer))
18.35.27 #       <UncleBill> I can't seem to get a development environment setup. I'm using cygwin and building for iRiver (m68k-elf). binutils-2.16 builds and installs fine. then I add the binutils bin to the head of my path. when I make gcc-3.3.4, I get errors in cc9Tass2.s about fmovem.l. any ideas?
18.42.35 #       <bagawk> nope
18.42.47 #       <bagawk> UncleBill, it might just be easiest to use BC's dev kit
18.43.08 #       <bagawk> http://homepage.ntlworld.com/cyborgsystems/CS_Main/RockBox/RockBox.htm
18.43.20 #       <UncleBill> I'll check it out
18.43.30 #       <bagawk> humm        gcc 3.3.4
18.43.42 #       <bagawk> I think they expect you to use a newer gcc version
18.43.45 #       <UncleBill> I'm just following the wiki directions
18.43.56 #       <bagawk> I tink they use that for archos SH1 players only
18.44.00 #       <UncleBill> it's very specific not to use newer gcc.
18.44.04 #       <UncleBill> gotcha
18.44.46 #       <bagawk> Thats it
18.45.02 #       <bagawk> You need gcc 3.4.X
18.45.32 #       <bagawk> Read the download the source/coldfire section
18.46.23 #       <UncleBill> yep. I was doing that as we talked. it compiled fine this time
18.46.54 #       <bagawk> ??
18.46.59 #       <bagawk> That was very fast
18.47.17 #       <UncleBill> (the wiki says this is a patch for a failure in binutils, not gcc, so I didn't think that comment was applicable)
18.47.35 #       <UncleBill> I had been building for maybe 5-10 mins now
18.50.24 ***     Saving seen data "./dancer.seen"
18.51.45 Join    _aLF [0] (n=Alexandr@mut38-2-82-67-66-128.fbx.proxad.net)
18.57.27 #       <UncleBill> bagawk, BC's dev kit has a list of "supported mp3 players", and they're all Archos's. are you sure it will work for iRiver (which has a different cpu)?
18.58.15 #       <bagawk> bagawk, yes,           but I just though of a even better way, since you already have downloaded and installed cygwin
18.58.31 #       <UncleBill> speak on, friend
18.58.34 Quit    Seed (Read error: 110 (Connection timed out))
18.58.37 #       <bagawk> http://www.rockbox.org/twiki/bin/view/Main/CygwinDevelopment
18.58.47 #       <bagawk> Rerun the cygwin setup.exe
18.59.06 #       <bagawk> (it will keep everything you have now)
18.59.12 #       <UncleBill> wow, that is cool
18.59.32 #       <bagawk> :)
18.59.35 #       <UncleBill> the wiki could use a bit of organization in this area (imho)
18.59.47 #       <bagawk> Yes
18.59.51 #       <bagawk> But it is a wiki
18.59.56 #       <bagawk> Anyone can change itr
19.00.17 #       <UncleBill> when I have everything going, I believe I'll do that
19.00.43 #       <UncleBill> ok, I may go back to the cygwin packages you pointed out, but for now, I have everything installed from source. I'll play with that a bit
19.02.47 Join    synd [0] (n=synd@h211.9.55.139.ip.alltel.net)
19.05.31 #       <bagawk> UncleBill, great
19.10.07 #       <UncleBill> thanks for the help, bagawk.
19.10.12 #       <UncleBill> gotta flee to work now. later, all
19.10.26 Quit    UncleBill ("Client exited.")
19.23.15 Quit    einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
19.38.28 Join    zezayer [0] (n=jake@87.81.166.52)
19.47.28 Quit    bagawk ("Leaving")
19.58.51 Part    zezayer
20.01.01 Join    cpenner [0] (n=d1595386@labb.contactor.se)
20.02.14 #       <cpenner> how do I go about filing a bug report for rockbox firmware for the iriver?
20.05.16 Quit    cpenner (Client Quit)
20.10.59 Join    einhirn [0] (i=Miranda@carlsberg.heim2.tu-clausthal.de)
20.25.48 Join    [1]Moos [0] (i=DrMoos@m29.net81-66-158.noos.fr)
20.25.49 Quit    Moos (Read error: 104 (Connection reset by peer))
20.25.51 Nick    [1]Moos is now known as Moos (i=DrMoos@m29.net81-66-158.noos.fr)
20.26.58 #       <Coldtoast> oh wow!
20.27.10 #       <Coldtoast> "podcast" is now in te Oxford dictionary!
20.27.20 #       <Coldtoast> that didn't take long!
20.39.35 Join    preglow [0] (n=536c28a0@labb.contactor.se)
20.39.38 #       <preglow> woopwoop
20.41.28 Quit    Speedforneed (Read error: 104 (Connection reset by peer))
20.42.12 #       <preglow> coding playback speed support for iriver rockbox should be a pretty quick hack
20.44.00 #       <Coldtoast> hey preglow
20.45.57 #       <preglow> hey
20.47.28 Join    Seed [0] (i=ben@l192-117-115-168.broadband.actcom.net.il)
20.47.39 Join    webguest81 [0] (n=5430934c@labb.contactor.se)
20.48.50 #       <preglow> yo, seed
20.48.54 #       <Seed> hi
20.48.55 #       <preglow> any news on musepack? :P
20.50.04 #       <Seed> no, sadly
20.50.11 #       <Seed> no good, no bad
20.50.25 ***     Saving seen data "./dancer.seen"
20.51.29 #       <preglow> heh
20.51.49 #       <preglow> rockbox support is still what i left it at, it seems
20.53.08 #       <Seed> I'm sad to not have been the person who created it
20.53.18 #       <Seed> or things would have gone very very differently
20.53.52 #       <Seed> one day it'll all be revelead
20.53.57 #       <Seed> <evil laughter>
20.54.02 Join    stevenm [0] (n=stevenm@pcp04417429pcs.nrockv01.md.comcast.net)
20.54.34 #       <preglow> heh
20.54.37 #       <preglow> hi, stevenm
20.55.08 #       <preglow> musepack port will require a ton of work, and i dont know if well ever get seeking working
20.55.17 #       <stevenm> preglow, hello
20.55.18 #       <preglow> but hell, i dont seek all that often anyway
20.56.32 #       <Lear> why would seeking be so hard (not being very familiar with the musepack port...)?
20.56.54 #       <preglow> lear: its hard to seek in musepack streams without walking the entire stream¨
20.57.19 #       <stevenm> it is like that with many tracker formats also
20.57.31 #       <preglow> lear: the musepack people themselves recommended backing up the decoder state at certain points to facilitate seeking, which i believe speaks volumes about how nice a format it is for seeking
20.58.09 Quit    ghostiger (Remote closed the connection)
20.58.09 #       <Seed> Lear: I'm sure people will accept it even without seeking at first.. but that's not a way to add a codec
20.58.11 #       <Seed> erm
20.58.13 #       <Seed> preglow
20.58.14 #       <Lear> you mean walking as in decoding pretty much the entire stream (up to the seek point)?
20.58.16 #       <Seed> sorry Lear :)
20.59.08 #       <preglow> lear: as in huffman decoding it until you reach the place you wanted to get to
20.59.09 Join    ghostiger [0] (n=ghostige@anonymous.genetikayos.com)
20.59.18 #       <preglow> lear: actually decoding the data shouldnt be necessary
20.59.32 #       <preglow> as in synthesizing the audio
20.59.50 #       <leftright> Lear: dont you think it would be nice if RG went automatically to 'Track' if shuflle is selected ? :)
21.00.01 #       <Lear> okay, could be worse, I guess... But what about the new stream format that has been discussed?
21.00.23 #       <Lear> leftright: as an option, perhaps. I don't want it, but I see the point in doing so.
21.00.26 #       <preglow> you got an url?
21.00.44 #       <preglow> i havent seen it, but at least they know about the problem, and there are several nice fixes for it
21.01.10 #       <Lear> you mean the stream format? I  has been mentioned on Frank Klemms web pages...
21.02.27 #       <Coldtoast> do any of you "reliably" get the volume bug?
21.02.33 #       <preglow> yeah
21.02.34 #       <preglow> i do
21.02.59 #       <Lear> coldtoast: as in sluggish response when rapidly changing it?
21.03.00 #       <Coldtoast> Linus said he randomly does. he''ll start to zero in on it and then it goes away
21.03.11 #       <Coldtoast> it's more than that lear
21.03.26 #       <Coldtoast> when it gets sluggish, try dropping the volume to 0
21.03.45 #       <Lear> yes, I know it stops working altogether...
21.03.55 #       <Coldtoast> eyah
21.03.58 #       <Coldtoast> err.. yeah
21.04.18 #       <Coldtoast> I tried the latest bleedign edge and I have to put the volume up much higher before I get it
21.04.50 #       <Coldtoast> I was getting it around 80% but I tried the latest bleeding edge and it doesn't do it til about 95%
21.05.10 #       <Lear> preglow: a very old link I had doesn't work, and googling didn't show anything likely in the first few pages...
21.05.15 Part    synd
21.06.03 #       <preglow> lear: didnt find it myself
21.06.07 #       <Lear> preglow: at least partial mirror is available here: http://www.hydrogenaudio.org/musepack/klemm/www.personal.uni-jena.de/~pfk/mpp/sv8/components.html
21.06.29 #       <preglow> i hope they get it going soonish
21.06.42 #       <preglow> i like the simplicity of the format, but not its current flaws
21.08.19 Quit    stevenm (Read error: 104 (Connection reset by peer))
21.09.27 #       <Lear> coldtoast: based on when the bug seems to start appearing, I suspect the timer changes from July 26. I'd like to hear what amiconn has to say about that. :)
21.09.44 #       <Coldtoast> CoCoLUS thought that too
21.10.16 #       <Coldtoast> said when the changes were implemented is when he started getting it. I don't get it til the build fromt eh 30th
21.10.39 #       <Coldtoast> actually, 31st. 30th is ok
21.11.18 Join    LinusN [0] (N=linus@labb.contactor.se)
21.11.42 #       <Lear> I downloaded a number of builds, and first found it in the July 27 build (and I tried hard in the 25 build).
21.12.54 #       <preglow> hi, linus
21.14.56 Join    dpassen1 [0] (n=derek@cpe-24-168-110-99.si.res.rr.com)
21.21.21 #       <Lear> hm.. should obsoleted strings be removed (as in emptied) immediately?
21.22.28 #       <Lear> I'd like to commit an update for the id3 info screen, where among other things, only LANG_ID3_NO_INFO is used when information is missing...
21.24.21 #       <LinusN> Lear: any and all improvements to the id3 info screen are welcome
21.25.05 #       <Lear> I suspected that. Thought it looked a bit silly with a ten row screen (in my case) and then only show text on two...
21.25.46 #       <Lear> But should I obsolete the no longer needed strings as a part of the commit? I think I've seen that, but...
21.26.44 #       <LinusN> yes do that
21.28.29 Quit    dpassen1 ("Leaving")
21.29.28 #       <preglow> linusn: so, rockbox has already got a playback speed config screen for platforms that support it?
21.29.44 #       <LinusN> Lear: regarding the resampler, will it choke if the codec changed the resampling factor on the fly?
21.29.57 #       <LinusN> not playback speed, pitch
21.30.13 #       <preglow> well, theyre directly related
21.30.14 #       <LinusN> as in sample rate
21.30.38 #       <preglow> the resampler should handle a changing delta just fine
21.30.44 #       <LinusN> good
21.30.53 #       <Lear> Don't think so. There's a "last_sample" that will be zeroed, causing a bad sample or two, but no more than that. :)
21.31.07 #       <preglow> ah, but dont reset that
21.31.11 #       <preglow> just change the delta
21.31.15 #       <preglow> thats all thats needed
21.32.04 #       <preglow> someone should make the resampler do a stereo stream in one pass ;)
21.32.06 #       <LinusN> i want the mp3 codec to switch sample rate depending on the decoded frames rather than trusting the info from the id3 parser
21.32.07 #       <Lear> Perhaps the set_frequency command should be changed (or a new one added), so that last_sample isn't touched, and perhaps not the phase either...
21.32.12 #       <preglow> another week, and i might be coding again
21.32.36 #       <preglow> linusn: yes, definitely
21.32.50 #       <LinusN> i'll test that
21.32.51 #       <preglow> linusn: there are plenty of files with wrong sfreq in the id3 tag
21.32.59 #       <Lear> linusn: yes, I gathered that, though one might want to make the id3 metadata parser a bit more robust (though I'm not sure how feasible that would be).
21.33.01 #       <LinusN> the freq is not in the tag
21.33.32 #       <LinusN> the id3 parser is quite robust if you ask me
21.33.52 #       <preglow> linusn: but yeah, playback speed/pitch control for iriver could be quickly hacked together by using the resampler
21.34.01 #       <LinusN> it's just that it does a lot more than parse id3 tags
21.38.02 #       <LinusN> i see two options for the frequency change
21.38.13 #       <LinusN> 1) add a SWITCH_FREQUENCY config
21.38.26 #       <LinusN> 2) add a RESET_RESAMPLER config
21.39.42 #       <preglow> how about just setting the resampler after the sfreq in the first frame? it should never change
21.40.13 #       <preglow> but of course, this is The Correct Way
21.40.15 #       <LinusN> i will only set it if it changes
21.40.25 #       <Lear> perhaps should have said, "mp3 metadata", there's lots of stuff parsed there...
21.41.36 #       <LinusN> i'll set it after decoding the first frame, then i know if it's a valid frame
21.41.47 #       <preglow> brb
21.42.03 #       <Lear> the dsp has a "full reset" and a "set sample frequency" command, but full reset isn't always executed.
21.42.19 #       <Lear> maybe "set new sample frequency" should be added...
21.42.26 #       <Lear> very simple to do...
21.42.40 #       <LinusN> and full reset doesn't reset the sample_data
21.43.50 #       <LinusN> having a SWITCH_FREQUENCY without resetting sample_data would allow us to set it on each frame regardless
21.45.27 #       <LinusN> the mpa codec sets stereo mode on the fly
21.45.42 #       <LinusN> so it could just as well set the delta as well
21.46.51 #       <LinusN> so, should i add DSP_SWITCH_FREQUENCY?
21.48.28 Join    hardeep [0] (i=hardeeps@freeshell.ORG)
21.49.43 #       <LinusN> why are the DSP_xxx symbols defined in playback.h?
21.51.16 #       <Lear> true, it doesn't reset the sample data, but the default is no resampling anyway...
21.51.47 Quit    Coldtoast ("Peace and Protection 4.22")
21.51.59 #       <Lear> some configurable items refer to the playback, and it's an enum...
21.52.30 #       <LinusN> i still don't get it
21.53.10 #       <Lear> yes, DSP_SWITCH_FREQUENCY, or something like that... (DSP_CHANGE...)
21.53.31 #       <LinusN> i though all the DSP_xxx items belonged to dsp.c
21.54.13 #       <Lear> the codec api has a configure function. some of the settings involve the buffering in playback.c. True, all DSP_* items belong to dsp.c, and playback.c passes any unknown settings to dsp.c.
21.54.45 #       <LinusN> ok i get it
21.54.55 #       <Lear> well, not all belong to dsp.c; the enable setting is in playback.c.
21.55.04 #       <Lear> So as to not call dsp_process unless needed.
21.55.18 #       <LinusN> but that is a CODEC_xxx symbol
21.56.10 Join    incognito [0] (n=450aa184@labb.contactor.se)
21.56.42 #       <Lear> ah, yes...
21.58.31 #       <incognito> does anyone know if anybody is optimizing mpc playback on the H1x series?   Its pretty cool that they play, although it cuts out every 5-10 seconds...
21.59.18 #       <Lear> not at the moment, afaik...
22.01.34 #       <incognito> does anyone want to speculate on a september 5th or earlier release with realtime playback of mpc?
22.01.53 #       <Lear> why that date?
22.02.03 #       <incognito> just threw it out there
22.03.28 #       <LinusN> realtime mpc will come when someone bothers to work on it
22.03.57 #       <preglow> incognito: we more or less need to rewrite the mpc code to make it work fast enough
22.05.48 #       <incognito> so it can be much more optimized i gather?
22.05.56 #       <preglow> oh yes, tons
22.06.01 #       <preglow> but the current code doesnt make it easy
22.06.07 #       <incognito> i see
22.06.13 #       <incognito> thanks for the response
22.06.13 #       <preglow> i just did the easiest optimisations and left it at that
22.06.42 #       <incognito> i was pleasantly surprised to hear my mpc files play at all on a portable :)
22.07.14 #       <preglow> heh
22.07.59 #       <preglow> but yeah, tons and tons of potential, you just need to find someone skilled in fixed point math and willing to do some work
22.08.16 #       <incognito> yeah, but then again, ogg vorbis is getting pretty damn close to mpc transparency rates
22.09.34 #       <preglow> its really bitter, because musepack is such a simple codec compared to for example vorbis
22.10.14 #       <incognito> very fast decoding also, at least on pc architecture
22.10.40 #       <preglow> yes, it _should_ be fast
22.11.29 #       <LinusN> on-the-fly frequency switch worked nicely
22.11.47 #       <preglow> well, it should
22.12.24 #       <LinusN> only problem will be the time estimate
22.12.45 #       <LinusN> which is based on the frequency
22.13.02 #       <LinusN> found by the metadata parser
22.14.47 #       <preglow> what does that base its findings on?
22.14.54 #       <preglow> the sfreq, that is
22.15.17 #       <LinusN> the metadata parser attempts to find the first valid mp3 frame header after the id3v2 tag
22.15.44 #       <LinusN> the initial sample frequency is taken from that
22.17.26 #       <LinusN> btw, samples_done isn't updated correctly when (re)winding
22.17.48 #       <LinusN> so the resume info is wrong when stopping the playback
22.19.00 #       <preglow> i dont think its ever correctly updated when seeking
22.19.15 #       <preglow> gapless playback is pretty broken at the moment as well
22.19.22 #       <preglow> but not much i can do about it right now
22.19.24 #       <LinusN> really?
22.19.34 #       <preglow> yeah, at least in the build i use now
22.19.54 #       <preglow> and its pretty recent
22.20.39 #       <Lear> I haven't noticed anything... I'm not using the most recent build, true, but I have there been any changes regarding that?
22.20.41 #       <preglow> ill contact gabriel bouvigne and ask him exactly how to implement gapless mp3, so i dont have to guess anymore
22.21.02 #       <Lear> It looks pretty much the same as foobar...
22.21.04 #       <preglow> lear: its pretty marginal, but id guess at least a thousand samples of noise/silence is inserted between tracs
22.21.10 #       <preglow> lear: thats where i took it from
22.21.28 #       <LinusN> sounds gapless to me
22.21.35 #       <LinusN> just tried
22.21.39 #       <preglow> ok, ill get me a new build
22.24.35 #       <preglow> i can most definitely hear a gap
22.25.09 #       <LinusN> hand me the two tracks
22.25.51 #       <preglow> gimme a sec, ill check more
22.26.13 #       <Lear> he, that's a new one... a woman with acrophobia drove up on a high bridge by accident, and didn't dare continue. The police had to rescue her.
22.26.30 #       <Lear> and that's with a lame encoded track (vbs)?
22.27.34 #       <preglow> yeah
22.28.26 #       <preglow> ive i also encoded a sine wave as two tracks
22.28.44 #       <preglow> that case will always glitch, thanks to mp3 weaknesses, but it shouldnt glitch this bad
22.29.28 Join    LaMeD [0] (n=554160c7@labb.contactor.se)
22.30.53 #       <LaMeD> Hey. I would like to search the repository for patches that have been accepted. I'm looking for one specific patch that I can't recall it's name :/
22.31.16 #       <Lear> so search! :)
22.31.35 #       <LaMeD> yeah.. where?
22.31.45 #       <LaMeD> how do i search the cvs?
22.31.53 #       <Lear> patch tracker on sourceforge.
22.38.20 #       <LinusN> am i right in that sample_count is only used to detect out-of-bounds seeking?
22.38.25 #       <LinusN> (in mpa.c)
22.40.07 #       <Lear> samplescount or sample_count?
22.40.07 Quit    incognito ("CGI:IRC (EOF)")
22.40.21 #       <LinusN> sorry, samplecount
22.41.32 #       <LinusN> and it seems as if it is supposed to contain the number of samples remaining
22.41.43 #       <Lear> seems like it, yes. I'd have expected it to be used to detect eof...
22.41.44 #       <LinusN> for some reason
22.42.00 Join    dcranford [0] (n=foo@c-66-41-112-239.hsd1.mn.comcast.net)
22.42.10 #       <amiconn> Lear: I don't think my shared timer implementation has to do (directly) with the slow response bug
22.42.26 #       <dcranford> Hi there, im trying to install bootloader 5 using fwpatcher, and it doesnt recognize the firmware
22.42.27 #       <amiconn> It only changed code which has absolutely nothing to do with i2c
22.42.41 #       <dcranford> BTW, this is on iriver h120
22.42.51 #       <amiconn> The only core feature affected is the backlight fading
22.43.02 #       <LinusN> amiconn: i don't think it has anything to do with it either
22.43.23 #       <LinusN> dcranford: which firmware are you patching?
22.43.34 #       <dcranford> 1.65 EN-US
22.43.44 #       <LinusN> unmodified?
22.43.48 #       <dcranford> correct
22.43.53 #       <preglow> i dont think samplecount has much of a function, out of bounds seeking can be detected in other ways
22.43.55 #       <Lear> when I tested it, the first build with the problem was the one that only contained the timer changes, so...
22.44.43 #       <Lear> and the slow response bug seems to be timing related somehow (make volume changes slower, and there's no problem).
22.44.49 #       <LinusN> dcranford: so you browse to the newly downloaded ihp_120.hex and fwpatcher says it doesn't recognize it?
22.45.05 Join    dpassen1 [0] (n=derek@cpe-24-168-110-99.si.res.rr.com)
22.45.19 #       <LinusN> preglow: i'll change it
22.45.43 #       <Lear> preglow: sine waves to cause a glitch, yes, but in real music, I can't detect any gaps, and that's what counts, imho. :)
22.46.07 #       <preglow> lear: they will always glitch, but i think theres a bigger gap than there should be
22.46.29 #       <Lear> I didn't hear much of a gap though.
22.46.50 #       <preglow> linusn: i think i orignally introduced it to know how many samples to play before discarding the samples that contain padding
22.47.37 #       <amiconn> preglow: I don't know exactly why that is, but Linus' fix for the id3v1 trimming fixed gapless playback for me
22.47.50 #       <dcranford> LinusN : that correct....here is my way of doing it....downloaded fwpatcher (July 22nd) from rockbox site....then download h120-bootloader.bin to desktop, then launch fwpatcher, browse to desktop, and fwpatcher doesnt see it
22.48.05 #       <amiconn> ...with the album that caused "negative gaps" before
22.48.15 #       <dcranford> LinusN : if I type in the name of the bootloader software I get that it is unrecognized firmware
22.48.15 #       <LinusN> fwpatcher contains bootloader.bin
22.48.29 #       <LinusN> dcranford: you need to download the original iriver firmware
22.49.04 #       <dcranford> oh I see, you download the iriver firmware and then the fwpatcher merges the 2 together?
22.49.10 #       <LinusN> fwpatcher patches the original firmware with the boot loader
22.49.11 #       <amiconn> LinusN: I hope to have correctly remembered the album that caused the illegal mem access a week ago; playing it now...
22.49.33 #       <amiconn> ...and yes, it already crashed
22.49.55 #       <dcranford> I see I thought it was like a bios update utility, where you download the utility then download the bin file and upload it to the player using that utility
22.50.03 #       <LinusN> preglow: ah, yes
22.50.14 #       <amiconn> ...within the first track (!)
22.50.28 ***     Saving seen data "./dancer.seen"
22.51.09 #       <amiconn> Trying again, watching it to find the exact spot...
22.52.11 #       <LinusN> the stop_skip is never handled
22.52.44 #       <dcranford> LinusN : ok the fwpatcher says it has patched successfully, do I now copy the file to the H120 and go through the firmware update process 
22.52.50 #       <LinusN> yes
22.53.18 #       <Lear> true, and wouldn't you need samplecount to detect when to do that?
22.53.25 #       <LinusN> yes i would
22.53.51 #       <LinusN> or i could detect that it is the last frame
22.54.08 #       <LinusN> and only play a fragment of it
22.54.25 #       <preglow> how do you detect the last frame reliably?
22.54.28 #       <LinusN> but the decoder doesn't know
22.54.41 #       <amiconn> LinusN: It happens at the very end of the first track
22.54.41 #       <preglow> indeed
22.54.51 #       <LinusN> amiconn: interesting
22.55.08 #       <amiconn> I'll try whether this happens with other albums as well
22.55.42 #       <amiconn> It seems the first track has a length and bitrate that needs almost exactly 3 buffer refills to play completely
22.56.09 #       <dcranford> now I suppose I need to get the rockbox software, where can I get the latest pre 2.5 software? Also I was wondering there hasnt been any updates to the testing of the H120 software since 7/20
22.56.24 #       <LinusN> summer time, you know
22.56.31 #       <LinusN> go to the daily builds page
22.57.00 #       <dcranford> LinusN : ok got it....is this "pretty" stable ?
22.57.06 #       <amiconn> LinusN: 192 kbps mp3 (cbr), length 3:31, with a personal rombox build on my Studio
22.57.07 #       <LinusN> as stable as it gets
22.57.13 #       <LinusN> :-)
22.57.29 #       <LinusN> amiconn: does it crash if you rolo a daily?
22.57.50 #       <amiconn> I can try
22.58.03 Quit    lostlogic (brown.freenode.net irc.freenode.net)
22.58.03 NSplit  brown.freenode.net irc.freenode.net
22.58.12 #       <LinusN> "rolo a daily" ... talk about rockbox lingo... :-)
22.58.34 NHeal   brown.freenode.net irc.freenode.net
22.58.34 NJoin   lostlogic [0] (N=lostlogi@node-4024215a.mdw.onnet.us.uu.net)
22.59.02 Quit    Seed (Read error: 104 (Connection reset by peer))
22.59.18 #       <amiconn> Usually I always run personal builds, especially on the Studio
22.59.25 Join    Seed [0] (i=ben@l192-117-115-168.broadband.actcom.net.il)
22.59.32 #       <LinusN> because...?
22.59.34 #       <amiconn> (You know, the HD poweroff issue...)
22.59.57 #       <amiconn> My Studio is working absolutely fine with it, but obviously not all players do
23.00.05 #       <LinusN> ah, yes
23.00.12 #       <LaMeD> Linus, other VIP: It's nice that you'r here, because I just wanted to make a small comment and don't know where to place it exactly: about two month ago a patch has been accepted that makes the marker stay at the middle of the screen, only getting to the ends on start/end of lists. I wanted to put out that this is not implemented on playlists and menus. (!)
23.00.31 #       <LinusN> true
23.00.37 #       <Bagder> LaMeD: feel free to fix
23.00.42 #       <LinusN> :-)
23.01.00 #       <LaMeD> I wish... ever heard of the disengajment in israel?
23.01.36 #       <leftright> woman are difficult to get along with
23.02.13 #       <LaMeD> sorry... disengagement. well i'm a soldier there. and trying to learn C out of .txt manuals i've put on my player 
23.02.43 #       <dcranford> sweet, ogg is working gapless on this
23.03.35 #       <preglow> .txt manuals and lots of practice will do just fine
23.03.53 #       <LaMeD> I promiss I'll fix everything right after knowing C.   now could any of you please just let this be known? I donno, put this on the right place on the requests?
23.04.18 #       <Bagder> LaMeD: I'm sure most of us know this
23.04.41 #       <Bagder> but adding a bug tracker entry about it could help reminding us
23.04.47 #       <LaMeD> preglow: could you please write me a C compiler for the H runtime? so I could practice when I'm away
23.05.34 #       <LaMeD> Bagder: yeah. I have no idea how to phrase that in as a bug tracker
23.05.51 #       <LaMeD> so would you? 
23.05.53 #       <LaMeD> yes?
23.05.54 #       <LaMeD> thanks
23.06.21 #       <leftright> anything else?
23.06.31 #       <LaMeD> coffee. thanks.
23.06.31 #       <LaMeD> I'll b back when i'll know C. swear.
23.07.20 #       <dcranford> LinusN : are we going to get some equalizer settings?
23.07.26 #       <amiconn> LinusN: It happens with a rolo'ed daily as well, only the address is different (obviously)
23.07.42 #       <LinusN> dcranford: i guess so, eventually
23.07.48 #       <LinusN> amiconn: good
23.07.58 #       <amiconn> So it has most likely nothing to do with a buffer wrap vs. track change
23.08.06 #       <LinusN> hand me the files, and i'll fire up my gdb
23.08.13 #       <amiconn> Then it should happen with other tracks as well, will try...
23.08.16 #       <preglow> im going to work on an equalizer soonish
23.08.42 #       <dcranford> LinusN : just wondering, the bass settings / treble settings are ok I would just like more presets ......also the volume seems to be a bit lower than stock firmware? Is it just me?
23.09.00 #       <preglow> dcranford: it is if you have volume at 100 and use the eq
23.09.47 #       <dcranford> preglow : ah so the bass/treble settings bring down the volume?
23.10.33 #       <LinusN> yes
23.10.38 #       <LinusN> "presets"?
23.10.47 #       <LinusN> you mean "rock" "jazz" etc?
23.10.54 #       <dcranford> LinusN : eq presets for "rock, jazz
23.11.01 #       <LinusN> :-)
23.11.10 #       <dcranford> LinusN : you got it
23.11.28 Join    Strath [0] (i=mike@dgvlwinas01pool0-a201.wi.tds.net)
23.11.30 #       <preglow> dcranford: the overall volume is reduced if there is a possibility for distortion, which there is with volume at 100 and additional eq gains
23.11.31 #       <dcranford> why do treble/bass settings bring down the volume?
23.11.39 #       <amiconn> dcranford: Boosting treble/bass brings down the volume if the boost can't be fulfilled otherwise
23.11.46 #       <dcranford> ah I see
23.12.24 Part    leftright
23.12.39 #       <amiconn> ...without causing really ugly distortions
23.12.54 #       <amiconn> The iriver firmware is cheating here; try the following
23.13.19 Quit    LaMeD ("CGI:IRC (EOF)")
23.13.22 #       <amiconn> In the iriver firmware, set bass & treble to flat, the max out the volume
23.13.39 #       <amiconn> (be sure to use the real max)
23.13.47 #       <amiconn> Then try increasing bass or treble.
23.13.57 #       <amiconn> You won't hear the faintest change...
23.14.03 #       <dcranford> yeah it gets fugly fast
23.14.10 #       <amiconn> The iriver firmware caps treble/bass instead
23.14.52 #       <dcranford> well, im using the crappy iriver stock phones for this test....my good phones are at work
23.15.25 #       <amiconn> LinusN: I just tested; it happens with all tracks, on all units
23.15.28 #       <preglow> but please, if anyone wants a new software based eq, id love to hear how people would like it to be
23.15.35 #       <preglow> i dont use them myself, so i dont know how i want it
23.15.50 #       <amiconn> Just start an arbitrary archos with a fairly recent build, enable memguard, then start playing an album
23.16.01 #       <amiconn> It will crash at the first track change...
23.16.03 #       <dcranford> preglow : like I said an adjustable eq with at least 8 channels
23.16.11 #       <LinusN> amiconn: ok
23.16.21 #       <dcranford> preglow : then presets for rock,jazz,pop,classical
23.16.23 #       <preglow> 8 bands, you mean?
23.16.34 #       <dcranford> preglow : yes bands (sorry)
23.16.37 #       <preglow> and what do you mean by adjustable?
23.16.52 #       <preglow> just gain adjustable?
23.16.56 #       <preglow> or q/center freq as well?
23.17.16 #       <dcranford> preglow : well you have the presets right...then you have the ability to manually set the seq as well
23.17.27 #       <amiconn> LinusN: Of course, use the zero area protection...
23.17.32 #       <LinusN> how silly, codec_set_elapsed_callback only updates the elapsed time if it is later than the current one
23.17.49 #       <preglow> not necessarily, heh, i could store the coefs in a table to avoid having the coef calculation code in fixed point
23.18.05 #       <LinusN> or...?
23.18.06 #       <dcranford> say the rock preset is a bit too bassy, you can just go into the manual eq and set it how you want it exactly
23.19.29 Quit    dcranford ()
23.19.42 #       <Lear> linusn: should always update, afaict...
23.20.08 #       <preglow> the gain of each band can be adjusted without recalculating the filter coefs, change in band placement needs recalc
23.20.22 #       <LinusN> i don't understand the if()'s in that function
23.20.32 #       <LinusN> why is it conditional?
23.21.14 #       <LinusN> i understand the latency, but not the other condition, in the "else"
23.21.24 #       <Lear> sorry, didn't check the playback.c code... :)
23.22.39 #       <LinusN> it only updates if the new elapsed time is either larger than the current, or at least 2ms smaller
23.23.27 #       <Lear> yeah, so the value doesn't change unless it is a "large" difference. don't see the need for that, I must say...
23.23.59 #       * preglow looks forward to starting audio effect box plugin
23.24.08 #       <preglow> and coding rockbox in general
23.26.17 Join    thomjoha [0] (n=thomjoha@hekta.edt.aft.hist.no)
23.26.25 Nick    thomjoha is now known as prethom (n=thomjoha@hekta.edt.aft.hist.no)
23.26.32 #       <prethom> preglow: begone!
23.26.38 Quit    preglow ("CGI:IRC")
23.26.54 Quit    Seed (Nick collision from services.)
23.27.00 Join    Seed [0] (i=ben@l192-117-115-168.broadband.actcom.net.il)
23.27.08 #       <prethom> i wonder how using this shell as a dev box would work...
23.27.23 #       <prethom> not having a linux server of my own any more sucks madly
23.32.13 Quit    webguest81 ("CGI:IRC (EOF)")
23.34.02 #       <amiconn> LinusN: I'm just reading the part about the breakpoint hardware of the coldfire. Seems it is working much the same way as the ubc in the SH1...
23.34.11 #       <LinusN> yes
23.37.00 #       <amiconn> Programming it is a bit different though, as it uses a special coldfire instruction instead of just a couple of memory-mapped registers
23.37.21 #       <LinusN> debugw
23.44.25 #       <amiconn> It shouldn't be difficult to replicate the archos memory guard functionality on iriver with that
23.44.43 #       <LinusN> goodie
23.44.56 #       <prethom> does it eat much resources?
23.45.05 #       <amiconn> The only thing I need to know is at which address the ROM is mapped
23.45.17 #       <amiconn> (RAM and IRAM are known)
23.46.28 #       <amiconn> prethom: It doesn't eat any resources (apart from a bit of code space) until it triggers
23.47.42 #       <amiconn> Well, perhaps the cpu draws a tiny bit more power
23.48.00 #       <LinusN> amiconn: rom is at 0
23.48.06 #       <amiconn> I don't know whether the breakpoint logic is switched off in case it is unused
23.48.17 #       <LinusN> 2mbytes
23.49.19 #       <amiconn> LinusN: Hmm, then it makes no sense to distinguish between illegal zero(-page) accesses and illegal ROM writes
23.49.54 #       <amiconn> It makes it impossible to declare zero(-area) reads illegal...
23.50.17 #       <LinusN> why?
23.51.01 #       <LinusN> we don't use the rom today
23.51.03 #       <amiconn> ROM code will be read from ROM, and I strongly hope rockbox will run from ROM one day on iriver
23.51.25 #       <LinusN> code from rom? why?
23.52.23 #       <amiconn> When rockbox will run from ROM, it will obviously be read from ROM, and will also read constant data from ROM
23.52.35 #       <LinusN> get real. you want to sacrifice cpu performance to save a few hundred kbytes?
23.52.52 #       <amiconn> Hmm?
23.52.53 #       <LinusN> i see absolutely no point in running from rom
23.52.57 #       <amiconn> I do.
23.53.01 #       <amiconn> Boot time.
23.53.25 #       <LinusN> so you want to waste cpu performance for a faster boot time?
23.53.26 #       <prethom> boot time is great as it is
23.53.27 #       <amiconn> Perhaps we can copy from ROM, but that also requires reading
23.53.41 #       <LinusN> yes, but then the memguard is off
23.53.42 #       <prethom> well, then enable the checking after copying
23.53.53 #       <amiconn> prethom: Boot time of iriver rockbox takes ages compared to archos rockbox boot from ROM
23.54.09 #       <prethom> yeah, id expect, but its still great
23.54.09 #       <prethom> heh
23.54.14 #       <amiconn> LinusN: On archos, memguard survives rolo
23.54.21 #       <prethom> whats the best archos unit, btw?
23.54.26 #       <amiconn> We would need to switch off then
23.54.42 #       <LinusN> so?
23.54.45 #       <amiconn> prethom: I can't say there is a 'best' unit; it depends what you want
23.54.52 #       <Bagder> prethom: a subject of preference, if you like the AA nimh or custom LiIo batteries basically
23.55.09 #       <amiconn> ...and what capacity, whether you want a radio etc
23.55.22 #       <prethom> well, radio as a feature is always good
23.55.28 #       <prethom> cant see why i wouldnt want it
23.55.37 #       <amiconn> The only units I would avoid (if not for development) are the Studio and the recorder V2
23.55.51 #       <LinusN> in my not-so-humble opinion, rombox on iriver is a waste of developer time and a waste of cpu performance
23.55.55 #       <prethom> think im getting my hands on an fm recorder, well see
23.56.01 #       <Bagder> there's only one archos model with FM and harddrive, the FM Recorder
23.56.15 #       <Bagder> one model that rockbox runs on that is
23.56.16 #       <amiconn> ...but the FM recorder's radio is rather bad
23.56.35 Quit    _aLF (Read error: 104 (Connection reset by peer))
23.56.38 #       <prethom> i dont much care about it anyway
23.57.03 Join    _aLF [0] (n=Alexandr@mut38-2-82-67-66-128.fbx.proxad.net)
23.57.09 #       <amiconn> Recorder V1: No radio, but spdif in/out, runs from 4 AA NiMH cells
23.57.30 #       <prethom> im not going to go out of my way to get an archos anyway, but if this girl i know wants to donate her fm recorder, ill just take it
23.57.37 #       <amiconn> FM recorder: Bad radio, but no spdif in, runs from a custom LiIon battery, a bit lighter
23.58.16 #       <amiconn> Ondio FM: Good radio (newer models only), no spdif at all, flash memory, much lighter, runs from 3 AAA cells
23.58.25 #       <Lear> re radio, how much work is it in getting it working on the iriver? don't we have the "chip driver" already?
23.58.35 #       <amiconn> (rechargeable or alkaline)
23.58.44 #       <amiconn> Lear: Yes we do