--- Log for 30.10.105  Server: kornbluth.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 1 day and 21 hours ago

00.00.02 Quit    _FireFly_ ("Leaving")
00.01.01 #       <solexx> i hope so. :)
00.04.28 #       <linuxstb> I've been playing a little with AAC - my current (non-working) aac.codec is over 1MB in size...  Hopefully I'm doing something very wrong.
00.05.47 #       <Bagder> that's usually an lds problem
00.06.02 #       <Bagder> with something starting at address 0
00.07.52 #       <linuxstb> Well, the libfaad.a is 1.8MB
00.08.03 #       <Bagder> oh
00.09.47 #       <linuxstb> These are builds for the sim by the way.
00.10.13 #       <linuxstb> Stripping libfaad.a takes it down to 270956 bytes.
00.10.27 #       <Bagder> ok
00.20.06 ***     Saving seen data "./dancer.seen"
00.31.24 Join    DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se)
00.37.48 Join    MacDancer [0] (n=MacDance@adsl-69-109-189-106.dsl.pltn13.pacbell.net)
00.38.01 #       <MacDancer> Hallo, all
00.39.11 #       <MacDancer> I've a quick question that I haven't been able to find the answer to in the documentation so far...
00.39.42 #       <MacDancer> I can't find the playback pitch/speed adjustment option anywhere, and I, unlike most people, could actually use it
00.40.01 #       <MacDancer> Could someone give me directions? :\
00.49.06 #       <solexx> i don't think rockbox has this feature (at least not on iriver)
00.49.17 #       <solexx> but i might be wrong
00.50.39 #       <MacDancer> It's listed in the manual for the Archos players, but of course there isn't one for the iRiver port, so...
00.51.20 #       <phaedrus961> MacDancer: press on+up or on+down in the wps
00.51.20 #       * solexx could have sworn he saw a light coming on
00.51.32 #       <linuxstb> It's only implemented on the Archos, NOT the iriver at the moment.
00.51.42 #       <MacDancer> Ah, that'll be it then
00.51.52 #       <MacDancer> Thanks
00.51.55 #       <phaedrus961> np
00.58.04 Quit    MacDancer ("Leaving")
01.12.12 #       <TiMiD> RotAtoR: still pbls with your plugin ?
01.15.12 #       <phaedrus961> TiMiD: something in your latest commit broke the buttonbar
01.15.35 #       <TiMiD> oh ?
01.15.41 #       <TiMiD> I test on sim
01.15.58 #       <TiMiD> I have also the copyright to handle
01.16.00 #       <phaedrus961> if I scroll up or down in the filetree it disappears
01.16.09 #       <TiMiD> erf
01.16.55 #       <TiMiD> I build sim for archos
01.17.36 Quit    DangerousDan (Read error: 104 (Connection reset by peer))
01.20.12 #       <RotAtoR> TiMiD: yes
01.20.54 #       <TiMiD> RotAtoR: did you tried without the font change 
01.21.08 #       <RotAtoR> yes, still no change :/
01.21.13 #       <TiMiD> (it will be ugly, but just to be sure the pbl isn't here)
01.22.10 #       <RotAtoR> it's stange, i have an opening description screen with text that works fine
01.22.40 #       <RotAtoR> it works to draw lines and rect all over the text there
01.23.04 #       <RotAtoR> but for some reason, all but the text appears when in the main program loop
01.23.18 #       <TiMiD> I didn't looked at your code too much (I catch a flew) but try to remove all the other drawing code excepted the update
01.23.38 #       <RotAtoR> i did that too, the text still doesn't draw...
01.23.59 #       <RotAtoR> it's aggravating >:(
01.26.08 #       <TiMiD> test w/o lcd_set_drawmode
01.26.36 #       <RotAtoR> ok, i'll look into that
01.33.45 #       <RotAtoR> *sigh*, this is ridiculous, I just commented out all code that does anything with the lcd except for the text I want, and still nothing
01.34.42 #       <RotAtoR> but it still works great in the sim ;)
01.34.49 #       <TiMiD> you must at least have update
01.35.13 #       <RotAtoR> well, yes, one update at the end
01.36.40 Join    whatboutbob [0] (n=cbd60b37@labb.contactor.se)
01.37.55 #       <whatboutbob> timid:  I'm getting the same issue as phaedrus961
01.38.28 #       <TiMiD> whatboutbob: I'm investigating it
01.38.33 #       <RotAtoR> well, have to get going... will try more debugging later
01.38.36 #       <TiMiD> (well I opened the source code :) )
01.38.46 #       <whatboutbob> doesn't happen when the remote's not plugged in.
01.38.46 Nick    RotAtoR is now known as RotAtoR|afk (n=e@12-210-82-91.client.insightBB.com)
01.39.02 #       <TiMiD> whatboutbob: uh ?
01.39.04 #       <whatboutbob> sorry..don't mean to bug you about it...and not complaining at all...just thought you'd like to know.
01.39.15 #       <TiMiD> I like to know yes :)
01.40.11 #       <TiMiD> I'm glad to say I can reproduce the bug on simulator :)
01.40.14 #       <whatboutbob> timid: yeah, when the remote's not plugged in everything works fine.  as soon as i plug the remote in usually within a few seconds of me browsing the filetree (with remote or main unit) the screen disappears
01.41.20 #       <whatboutbob> timid: arch...scratch that. happens without remote plugged in.  just didn't wait long enough it seems.
01.47.41 #       <whatboutbob> just to ensure we're talking about the same bug, i'll be in the filetree, click right, the unit will have a little think, then the cursor will jump to the top of the filetree, then a few seconds later the screen will go blank.
01.48.13 #       <TiMiD> the whole screen ?
01.48.20 #       <whatboutbob> yup
01.48.27 #       <TiMiD> on the sim I only see button bar which disepear
01.50.29 #       <phaedrus961> only the button bar disappears for me too
01.50.50 #       <Moos> in the target?
01.50.50 #       <whatboutbob> oh, ok, something weird going on with just me then it sees...
01.51.04 #       <phaedrus961> target and sim
01.51.56 #       <whatboutbob> actually...i've just plugged the remote back in.   when i play a song the remote stays in filetree mode while the unit goes to the wps. is that right?
01.52.27 #       <TiMiD> I've a clue (maybe)
01.52.40 Join    thegeek [0] (n=thegeek@s115b.studby.ntnu.no)
01.54.40 #       <TiMiD> whatboutbob: that's a normal behaviour
01.54.40 Quit    dpassen1 ()
01.54.41 #       <Moos> whatboutbob: bug for irivers?
01.55.01 #       <Moos> ah :)
01.55.09 #       <TiMiD> whatboutbob: the remote just doesn't clear the display when going to wps, and since wps is not implemented on remote ....
01.56.02 #       <TiMiD> the remoite support is not full and even if I'm working on it I only have few time
01.56.18 #       <Moos> hopefully that'll coming soon, hein TiMiD :)
01.56.21 #       <whatboutbob> ahhh...hokay...i'll shuddup and sit quietly in the corner for a while then. :)
01.57.02 #       <Moos> :D
01.57.51 #       <TiMiD> yes if the users stops complaining about bugs :)
01.58.00 #       <Moos> XD
01.58.23 #       <TiMiD> (well it's only the second and it's not lethal so it's pretty good :p)
01.58.42 #       <Moos> hehe
02.10.45 Join    Metuk [0] (n=5299eea1@labb.contactor.se)
02.12.21 Quit    Metuk (Client Quit)
02.20.08 ***     Saving seen data "./dancer.seen"
02.21.18 Quit    cYmen__ ("zZz")
02.33.25 Quit    Kohlriba ("Leaving")
02.52.37 Join    ashridah [0] (i=ashridah@220-253-121-184.VIC.netspace.net.au)
02.16.08 Quit    Moos ("Glory to Rockbox")
02.22.32 Join    actionshrimp [0] (i=dave@dhcp-163-1-214-173.seh.ox.ac.uk)
02.57.19 Quit    actionshrimp ("a bird in the bush is worth two in your house")
03.20.10 ***     Saving seen data "./dancer.seen"
04.04.20 Quit    RotAtoR|afk ()
05.14.59 Nick    ashridah is now known as Lost-ash (i=ashridah@220-253-121-184.VIC.netspace.net.au)
05.20.15 ***     Saving seen data "./dancer.seen"
06.33.24 Quit    whatboutbob ("CGI:IRC (EOF)")
07.20.17 ***     Saving seen data "./dancer.seen"
07.58.31 Join    ashridah__ [0] (i=ashridah@220-253-123-36.VIC.netspace.net.au)
07.58.55 Nick    ashridah__ is now known as ashridah (i=ashridah@220-253-123-36.VIC.netspace.net.au)
07.59.03 Quit    Lost-ash (Nick collision from services.)
07.59.23 Nick    ashridah is now known as Lost-ash (i=ashridah@220-253-123-36.VIC.netspace.net.au)
08.14.29 Join    solexx_ [0] (n=jrschulz@c187101.adsl.hansenet.de)
08.26.02 Quit    solexx (Read error: 110 (Connection timed out))
09.20.20 ***     Saving seen data "./dancer.seen"
09.34.37 Join    linuxstb_ [0] (n=5343d4aa@labb.contactor.se)
09.37.40 Quit    linuxstb_ (Client Quit)
09.44.27 Join    Musicmad [0] (n=Musicmad@port547.ds1-oebr.adsl.cybercity.dk)
09.44.43 Quit    Musicmad (Client Quit)
10.11.40 Join    ender` [0] (i=ychat@84.52.165.220)
10.11.58 #       <linuxstb> Slasheri: There is a problem with your FLAC commit.  
10.12.37 #       <linuxstb> The FLAC decoder required an entire frame (or more) to be passed to the decode_frame function.  But on the buffer wraparound point, the buffer will point to a partial frame.
10.13.03 #       <linuxstb> That's why I didn't use the request_buffer function - I don't think it's possible to use it due to that issue.
10.14.43 #       <Slasher> linuxstb: no
10.15.01 #       <Slasher> playback engine guarantees it will not be partial
10.15.35 #       <linuxstb> But I am now getting crashes in the FLAC codec.
10.15.47 #       <linuxstb> Have you tried playing an album of FLAC tracks?
10.15.50 #       <Slasher> At least if the MAX_FRAMESIZE is smaller than GUARD_BUFSIZE in playback.c
10.15.58 #       <Slasher> Hmm, not yet.. I will try soon :)
10.16.28 #       <linuxstb> I also hit the same problem with my ALAC decoder - see the code in there that either does a request_buffer or read.  Without that, the codec crashes at the wraparound point.
10.16.41 #       <Slasher> Hmm, interesting
10.16.54 #       <linuxstb> How big is GUARD_BUFSIZE?
10.17.30 #       <Slasher> MAX_FRAMESIZE 32768
10.17.48 #       <Slasher> GUARD_BUFSIZE  (8*1024)
10.17.54 #       <Slasher> ok, the guard buffer is too small
10.17.58 #       <Slasher> Try increasing it :)
10.18.05 #       <Slasher> Then it should no longer crash
10.19.47 #       <linuxstb> Yes, FLAC frames are typically up to about 13KB.  But can be bigger
10.20.40 #       <Slasher> I think 32*1024 could be a good value then
10.20.48 Join    DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se)
10.21.16 #       <Slasher> That would be the worst case
10.22.25 Join    Kohlrabi [0] (n=Kohlrabi@dslb-082-083-130-062.pools.arcor-ip.net)
10.23.29 #       <linuxstb> Also, does the request_buffer function return 0 at the end of the file?
10.24.08 #       <Slasher> linuxstb: Yes, it returns NULL and sets the buffer size to 0
10.24.39 #       <linuxstb> Did you manage to look at the crashing FLAC file?
10.24.51 #       <Slasher> linuxstb: Yep, i fixed that :)
10.25.03 #       <linuxstb> How?
10.25.15 #       <Slasher> It was a caused by a missing semaphores in the playback engine
10.25.21 #       <Slasher> just look at the latest two commits
10.25.34 #       <linuxstb> Sorry, I missed that commit.  Thanks for fixing :)
10.25.39 #       <Slasher> :)
10.26.08 #       <linuxstb> I've got to go now.  Can you increase GUARD_BUFSIZE?
10.26.16 #       <Slasher> ok, i will do that :) cu
10.26.21 #       <linuxstb> bye.
10.26.25 #       <linuxstb> Thanks.
10.26.28 #       <Slasher> np :)
10.35.44 Join    Lear [0] (n=chatzill@h73n11c1o285.bredband.skanova.com)
10.42.54 Join    cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de)
10.54.19 Join    Quelsaruk [0] (n=kvirc@80-103-103-117.mad1.adsl.uni2.es)
10.54.24 #       <Quelsaruk> good morning
11.07.20 #       <markun> morning Quelsaruk 
11.20.21 ***     Saving seen data "./dancer.seen"
11.22.00 Quit    Kohlrabi ("Leaving")
11.23.48 Quit    Lear (Excess Flood)
11.31.26 Nick    Lost-ash is now known as ashridah (i=ashridah@220-253-123-36.VIC.netspace.net.au)
11.52.15 Join    actionshrimp [0] (i=dave@dhcp-163-1-214-173.seh.ox.ac.uk)
11.53.16 Join    Kohlrabi [0] (n=Kohlrabi@dslb-082-083-130-062.pools.arcor-ip.net)
12.05.39 Join    Lear [0] (n=chatzill@h73n11c1o285.bredband.skanova.com)
12.08.45 Join    Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr)
12.11.56 #       <linuxstb> Slasher: Are you still around?
12.17.48 #       <Slasher> linuxstb: yes
12.18.27 #       <linuxstb> I've been working on an AAC decoder, so we've now hit the problem of two codecs using the same extension (m4a).
12.18.45 #       <Slasher> Ah, hmm
12.19.19 #       <Slasher> I think we could probe the file format using the metadata instead of file extension only
12.19.23 #       <linuxstb> My idea was to ensure that we always call get_metadata() before we load the relevant codec, and allow get_metadata() to change the codec type of the file after it analyses it.
12.19.32 #       <Slasher> That would require some modifications to the probe_file_format function at least
12.19.44 #       <Slasher> Hmm, that sounds good
12.20.57 #       <linuxstb> I don't think playback.c should call probe_file_format() - just get_metadata().
12.21.14 #       <linuxstb> Or the other way around.  i.e. just one function.
12.21.26 #       <Slasher> true
12.22.31 #       <Lear> Something unrelated: what is the purpose of the guard buffer?
12.22.35 #       <linuxstb> Would you have time to make those changes to playback.c?  I still don't understand it well enough.  We need to be careful to only call it when the disk is spinning - i.e. just before we load the file (or codec) into the buffer.
12.23.07 #       <linuxstb> Lear: It's to handle the case of a codec requesting a pointer to N bytes of data from the codec buffer, but the codec buffer being at the wraparound point.
12.23.07 #       <Slasher> Lear: It will prevent passing partial buffer data to the codecs when the main file buffer wraps
12.24.24 #       <linuxstb> i.e. the request_buffer() function is guaranteed to return either GUARD_BUFSIZE bytes or the number of bytes remaining in the file, whichever is larger.
13.20.24 ***     Saving seen data "./dancer.seen"
13.59.03 Quit    ashridah ("Leaving")
13.59.17 Join    ashridah [0] (i=ashridah@220-253-123-36.VIC.netspace.net.au)
14.01.44 Join    muesli- [0] (i=muesli_t@hmln-d9b8ef46.pool.mediaWays.net)
14.01.54 #       <muesli-> reee
14.04.11 Join    thegeek_ [0] (n=thegeek@s115b.studby.ntnu.no)
14.11.53 Quit    Kohlrabi (Read error: 104 (Connection reset by peer))
14.12.16 Join    Kohlrabi [0] (n=Kohlrabi@dslb-082-083-130-062.pools.arcor-ip.net)
14.19.54 Quit    thegeek (Read error: 110 (Connection timed out))
14.40.44 Quit    ashridah ("Leaving")
14.44.56 #       <phaedrus961> hey all, I've just submitted a patch for convbdf to fix two problems: 1) fonts wider than 16 pixels are now converted correctly. 2) the offset table was always written, even when unneeded.
14.45.08 #       <phaedrus961> it can be found here: http://sourceforge.net/tracker/index.php?func=detail&aid=1342470&group_id=44306&atid=439120
15.06.14 #       <markun> thanks phaedrus961
15.20.26 ***     Saving seen data "./dancer.seen"
15.30.29 Quit    DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
15.31.11 Join    DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se)
15.36.04 Quit    Lear ("Chatzilla 0.9.68.5.1 [Firefox 1.5/undefined]")
16.08.01 Join    preglow [0] (n=thomjoha@hekta.edt.aft.hist.no)
16.08.06 #       <preglow> woot
16.08.15 #       <linuxstb> woot?
16.08.37 #       <preglow> flac issue solved
16.09.18 #       <linuxstb> Yep.  It was a playback.c problem all along.  Hopefully that will increase playback reliability in general.
16.09.36 #       <preglow> yup
16.10.32 #       <linuxstb> His patch to use request_buffer() instead of read() is also useful.  As you probably read in the logs - I didn't fully understand how the buffering worked.
16.10.48 #       <linuxstb> But it means FLAC uses 32KB less RAM.
16.11.20 #       <preglow> flac has gotten really bloody lightweight
16.11.30 #       <linuxstb> There's nothing left of it...
16.11.49 #       <linuxstb> But don't worry, I've been trying to get libfaad2 working - that library makes libFLAC look streamlined.
16.11.55 #       <preglow> hahah
16.12.01 #       <preglow> yeah, i had a look at it
16.12.03 #       <linuxstb> It is also malloc hell.
16.12.22 #       <linuxstb> Using malloc for buffers 2 bytes long...
16.12.25 #       <preglow> hahahhaha
16.12.27 #       <preglow> good god
16.12.33 #       <preglow> i wonder what the helix decoder looks like
16.12.45 #       <linuxstb> We're not allowed to look - license issues :(
16.12.56 #       <preglow> oh, i know that
16.13.00 #       <preglow> just wondering
16.13.23 #       <linuxstb> I'm curious too.  
16.13.45 #       <linuxstb> I think it will be a case of stripping down and rewriting parts of libfaad2.  But it needs someone who understands AAC, or who wants to understand it.
16.14.35 #       <merbanan> linuxstb: well first you need a fixedpoint mdct, do you have one of those ?
16.15.13 #       <preglow> i think id like to study aac
16.15.29 #       <preglow> we have got several of those
16.15.35 #       <linuxstb> merbanan: I'm using libfaad2 in fixed point mode, so I assume it has one.
16.15.42 #       <preglow> tremors got one, faads got one, a52 has got one
16.16.32 #       <merbanan> hmm, last time I checked it didn't have one
16.16.40 #       <merbanan> or did I check ???
16.16.45 #       <preglow> well
16.16.47 #       <preglow> it does have one
16.16.50 #       <preglow> im pretty certain of that
16.17.02 #       <linuxstb> I think all the high-level code is working OK - parsing the m4a stream, extracting the codec data from the m4a header and using it to initialise libfaad2.  Even seeking works.
16.17.18 #       <linuxstb> It's working fairly reliably in the sim, but crashes on the target.
16.17.31 #       <merbanan> linuxstb: what speed?
16.17.52 #       <linuxstb> I don't know yet, it crashes on the sim before I get to hear anything.
16.17.57 #       <linuxstb> I mean on the target.
16.18.04 #       <preglow> oh?
16.18.11 #       <linuxstb> But I imagine it's going to be very very slow.
16.18.13 #       <preglow> didnt libfaad trigger tons of compiler bugs?
16.18.39 #       * preglow looks forward to do some optimising
16.18.56 #       <linuxstb> Not that many.  I worked around them by changing some variables from signed to unsigned (or other way around).  The diffs to the standard libfaad2 are tiny.
16.19.05 #       <preglow> good
16.19.19 #       <linuxstb> When it comes to putting it in CVS, I'll commit the clean libfaad2 first, then my workarounds.
16.19.34 #       <linuxstb> There are also a ton of compiler warnings.  Mainly about using char as an array subscript.
16.20.33 #       <preglow> nice
16.20.49 #       <preglow> i wonder what the odds of the codecs getting even more iram are :>
16.21.12 #       <preglow> it certainly appears to be the single most important optimising point there is
16.21.39 #       <linuxstb> Don't forget your DSP code will need IRAM as well.
16.21.46 #       <preglow> not much
16.21.57 #       <preglow> very little, as a matter of fact
16.22.31 #       <preglow> we should really work to keep the main buffers of the codecs in iram during all the processing
16.22.38 #       <preglow> thatll boost performance no end
16.22.59 #       <preglow> excuse the total lack of apostrophes, i hate laptop keyboards
16.23.08 #       <linuxstb> I assume you just mean the output buffer.  I don't think putting the input buffer in IRAM helps much.
16.23.16 #       <linuxstb> But I guess it depends on the codec.
16.24.26 #       <preglow> i mean the output, yes
16.24.47 #       <preglow> the output buffer will be traversed tons of times if we do some dsp
16.26.27 #       <linuxstb> Do you think it will be possible to remove mallocs completely?  I think alac has one (for the metadata), but I'll try and remove it.
16.26.51 #       <linuxstb> FLAC is now completely static.  I think liba52 is as well.
16.27.42 #       <preglow> completely, sure
16.27.48 #       <preglow> as long as were willing to set some max limits
16.28.02 #       <preglow> btw, i think you can safely delete libflac now
16.29.37 #       <linuxstb> OK, I'll do it later.  
16.31.33 #       <preglow> i hope to never see it again
16.32.28 #       <merbanan> linuxstb: what speed?
16.32.32 #       <merbanan> nm
16.33.08 #       <merbanan> linuxstb: did you write your own implementations for the fft macros ?
16.33.41 #       <linuxstb> No.  I haven't touched anything inside the libraries.   They all have their own implementations.
16.35.13 #       <preglow> you cant very well use a common fft or mdct routine
16.35.32 #       <preglow> everthing uses its own fixed point format
16.35.39 #       <preglow> and in some cases you can optimise for certain block sizes
16.35.39 #       <linuxstb> I've uploaded my current AAC source tree here: http://www.davechapman.f2s.com/rockbox/rockbox-aac.tgz
16.36.12 #       <linuxstb> It contains the apps, firmware and tools directories - synced to current CVS.  As I said, it works in the sim, but not on the target.
16.36.19 #       <preglow> but im hoping someone will try implementing an imdct via ifft soon
16.36.38 #       <merbanan> preglow: faad has that
16.36.57 #       <merbanan> preglow: and they use macros for it also
16.37.02 #       <preglow> then lets hope someone writes a fast fft for coldfire soon
16.37.02 #       <preglow> heh
16.37.14 #       <preglow> linuxstb: damn, its big
16.38.53 #       <linuxstb> Do you mean the source or the compiled aac.codec?
16.38.58 #       <preglow> source
16.39.33 #       <linuxstb> I'm sure it contains a lot of unused code.  See the common.h file for which bits are enabled.
16.40.50 #       <merbanan> preglow: the fft is macrobased
16.41.41 #       <merbanan> preglow: do some fast macros and it should work ok
16.44.22 #       <novimon_> anyone else get corrupted .flac files out of dbpoweramp?
16.45.24 #       <preglow> doesnt everyone?
16.45.31 #       <novimon_> dunno?
16.45.38 #       <novimon_> I for sure do?
16.46.05 #       <preglow> merbanan: only macros i can see are the general math macros
16.48.02 #       <preglow> parts of libfaad also seem to use awkward fixed point formats, like musepack does :/
16.48.36 #       <preglow> linuxstb: btw, im pretty sure flac has too weak an output
16.49.14 #       <merbanan> preglow: fixed.h
16.49.29 #       <linuxstb> preglow: Do you mean the samples are shifted incorrectly?
16.49.38 #       <merbanan> preglow: what awkward format ?
16.50.11 #       <preglow> linuxstb: i dont know how, but the volume is too low
16.50.11 #       <linuxstb> novimon_: How are they corrupted?  dbpoweramp will add ID3 tags to your FLAC files unless you tell it not to (when ripping from CD).
16.50.24 #       <linuxstb> We need a WAV writer...
16.50.27 #       <preglow> yes
16.50.30 #       <preglow> yes we do
16.50.44 #       <linuxstb> But my "main.c" test program gives bit-perfect output.
16.53.28 #       <preglow> ive got the same track encoded as ogg and flac here
16.53.36 #       <preglow> the flac one is noticably weaker
16.53.52 #       <preglow> seems to be half volume
16.54.29 #       <preglow> merbanan: like 14.18 fixed point
16.55.04 #       <preglow> merbanan: you need to shift by 14 after a mul, which loses tons of precision if you havent got a full 64 bit mul available
16.55.07 #       <preglow> which coldfire doesnt
16.55.59 #       <merbanan> ahh ok
16.57.04 #       <preglow> libmusepack does this as well
16.57.26 Quit    DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
16.57.26 #       <preglow> and thanks to that we need to calculate a full 64 bit mul all the time, which slows stuff down no end
16.59.19 #       <merbanan> and just doing 7.9 is too low precision ?
16.59.25 #       <linuxstb> preglow: I think I know the FLAC volume problem.  It's the code at line 450 of dsp.c.  Now that SAMPLE_DEPTH is > NATIVE_DEPTH, the "+1" comes into effect.
16.59.39 #       <preglow> yup
16.59.41 #       <linuxstb> So I should probably configure SET_SAMPLE_DEPTH to 27
16.59.47 #       <preglow> thats what i suspected as well
16.59.49 #       <preglow> well
17.00.00 #       <preglow> i think we should clarify that issue and fix it so its consistet
17.00.08 Quit    lostlogic ("Going to the moon")
17.00.33 #       <preglow> consistent
17.01.22 #       <linuxstb> I also need to tell the DSP the real sample depth of the data - i.e. 16 or 24 bits.
17.03.43 Quit    muesli- (Read error: 104 (Connection reset by peer))
17.04.18 Join    muesli- [0] (i=muesli_t@hmln-d5147619.pool.mediaWays.net)
17.07.32 #       <preglow> why?
17.08.26 #       <linuxstb> Because you told me I did :)  You said the dithering code needs to know.
17.08.32 #       <preglow> ahh, yes yes
17.09.24 #       <preglow> but that can come when we make all the codecs do the 28 bit resolution thing 
17.09.48 #       <preglow> i still dont know if anyone opposes the idea
17.10.05 #       <preglow> i think a lot of the mallocs in libfaad can be remove pretty easily
17.11.06 #       <linuxstb> Please do and send me a patch.  I've only removed one so far - in bits.c I think.  It was using malloc on all the input data.  So it crashed after reading 512KB of data.
17.11.47 #       <preglow> hahahahha
17.11.58 #       <linuxstb> That was pretty obvious though.
17.12.06 #       <preglow> ill see what i can do once i get back home
17.12.09 #       <preglow> later tonight
17.12.35 #       <preglow> but ive gotta go for now
17.12.35 #       <preglow> later
17.12.41 #       <linuxstb> But more useful would be to try and debug it on the target to find out where it crashes.
17.12.44 #       <linuxstb> bye.
17.20.29 ***     Saving seen data "./dancer.seen"
17.21.04 Join    mirak [0] (n=mirak@ip-84.net-82-216-142.rev.numericable.fr)
17.21.42 Quit    muesli- (Read error: 113 (No route to host))
17.34.05 Join    linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net)
17.50.16 Join    lostlogic [0] (n=lostlogi@node-4024215a.mdw.onnet.us.uu.net)
17.50.55 Quit    linuxstb (Read error: 110 (Connection timed out))
17.51.08 Nick    linuxstb_ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net)
18.15.56 Join    DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se)
18.19.03 Join    hshah [0] (n=545cb9e8@labb.contactor.se)
18.19.34 #       <hshah> heya all.... TiMiD are you around by any chance?
18.23.44 Join    paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822)
18.37.16 Join    amiconn [0] (n=jens@p54BD5229.dip.t-dialin.net)
18.37.45 #       <amiconn> evening
18.38.23 Join    muesli- [0] (i=muesli_t@hmln-d9b8e274.pool.mediaWays.net)
18.38.23 Join    LinusN [0] (n=linus@labb.contactor.se)
18.38.43 #       <Quelsaruk> hi amiconn, LinusN :)
18.40.23 #       <LinusN> yo
18.40.59 #       <amiconn> Bagder: r u there?
18.41.20 #       <hshah> im looking to TiMiD... lol
18.41.47 #       <hshah> hopefully he can update the root2wps patch... coz it no longer applied to the modifications made to tree.c
18.41.52 #       <hshah> *applies
18.42.47 #       <LinusN> the silly left-to-wps patch?
18.43.28 #       <hshah> the AMAZING left-to-wps patch you mean :p
18.43.38 #       <LinusN> :-)
18.44.05 #       <hshah> its just a matter of preference though... some people like it, some people don't... you don't like it, but i do :p
18.44.06 #       <amiconn> Jens
18.44.13 #       <amiconn> oops :)
18.44.22 #       <amiconn> wrong kb
18.44.34 Join    RotAtoR [0] (n=e@12-210-82-91.client.insightBB.com)
18.46.07 Join    linuxstb_ [0] (n=5343d4aa@labb.contactor.se)
18.50.44 #       <LinusN> hshah: i lust uploaded a revised patch to the forum thread
18.51.05 #       <LinusN> s/lust/just/
18.52.55 Quit    hshah ("CGI:IRC (EOF)")
18.53.27 #       <amiconn> LinusN: You updated a silly patch? ;)
18.53.35 Join    hshah [0] (n=545cb9e8@labb.contactor.se)
18.54.07 #       <hshah> cool - thanks Linus
18.54.18 #       <hshah> i actually tried to apply the patch myself...
18.54.30 #       <hshah> sorry, i mean modify
18.54.33 Quit    lostlogic ("Going to the moon")
18.54.36 #       <hshah> and i forgot to put it in { }
18.54.54 #       <hshah> and went home from uni over the weekend, and could not move back out of a folder on my iriver
18.55.09 #       <LinusN> :-)
18.55.09 #       <hshah> listening to 1 album for a 5 hour round trip is not fun!!!
18.55.36 #       <amiconn> You could have rebooted...
18.55.43 Join    lostlogic [0] (n=lostlogi@node-4024215a.mdw.onnet.us.uu.net)
18.55.51 #       <hshah> mine resumed playback...
18.56.06 #       <amiconn> Switch off resume on startup, then reboot
18.56.13 #       <hshah> hmm...
18.56.15 #       <LinusN> or (god forbid) use the original firmware
18.56.20 #       <hshah> well im retarded... i didn't think of that
18.56.26 #       <hshah> or that...
18.56.34 #       <hshah> lol - come on guys... i was really tired
18.56.37 #       <hshah> lol
18.57.02 #       <hshah> anyways, im gonna have a quick game of CS on lan with my housemates, so chat later... and keep up the good rockbox work guys!
18.57.23 #       <LinusN> cu
19.02.46 #       <mirak> LinusN: hi
19.02.49 #       <amiconn> LinusN: I want to implement memove() soon, but memmove() and memcpy() will be in one source file because memcpy() will actually be a subset of memmove() (fassembler versions). Do you have an idea how to call the source file?
19.02.49 #       <mirak> hshah: hi
19.02.55 #       <mirak> amiconn: hello
19.03.14 #       <mirak> how is going the H300 version ?
19.03.30 #       <mirak> I mean the bootloader
19.03.30 #       <LinusN> amiconn: just let it be memcpy.c
19.03.37 #       <LinusN> mirak: no progress yet
19.03.45 #       <amiconn> It's memcpy_a.S today
19.03.49 #       <mirak> would be motivating for H300 users in joining 
19.03.54 #       <LinusN> ok, then keep it that
19.03.58 #       <LinusN> mirak: yes i know
19.04.00 #       <mirak> in joining coding rockbox
19.04.13 #       <amiconn> The plain c versions will be two files, because they can't be interleaved that way
19.04.25 #       <LinusN> amiconn: sure
19.04.29 #       <mirak> yep I am interested, but having nothing running is not appealing :D
19.04.40 #       <mirak> LinusN: you own a H300 ?
19.04.47 #       <LinusN> of course i do
19.05.14 #       <amiconn> LinusN: Different question - is it possible to have the build system execute certain steps depending on the result of another?
19.05.30 #       <LinusN> amiconn: not really, why?
19.05.59 #       <amiconn> I'm thinking about a way to implement compressed images for recorder v1 (and perhaps player some time in the future)
19.06.28 #       <LinusN> ok, images as in pictures?
19.06.44 #       <amiconn> No, as in binary rockbox images
19.06.50 #       <LinusN> i see
19.07.09 #       <amiconn> Depending on the size of rockbox.bin, I want one of two different steps to be executed:
19.07.48 #       <amiconn> (1) If rockbox.bin is smaller than the limit, it will just be scrambled as ajbrec.ajz / archos.mod
19.08.26 #       <amiconn> (2) If it's larger, then an additional tiny loader should be built, tacked in front of rockbox.ucl, and then scrambled into ajbrec.ajz / archos.mod
19.08.31 #       <LinusN> hehe, just like back in the old c64 days. sounds like a job for a shell or perl script
19.08.46 #       <amiconn> Something like a self-extracting image
19.08.47 #       <LinusN> mkimage.pl
19.09.04 #       <amiconn> We already build rockbox.ucl anyway - veery handy for this :)
19.09.20 #       <LinusN> :-)
19.09.46 #       <amiconn> The ucl unpacker is also already present in the flash bootloader, and the decompressing loader will do almost the same
19.10.14 #       <amiconn> ...it only has to copy the compressed image to end-of-ram before decompressing, because decompressing in-place won't work
19.10.29 #       <mirak> LinusN: do you want money ?
19.10.35 #       <mirak> LinusN: or chocolates :D
19.10.40 #       <mirak> lol
19.10.45 #       <LinusN> mirak: i want time :-)
19.11.00 #       <mirak> how much time ?
19.11.42 #       <LinusN> my point is, i have little time to work on rockbox at the moment, as i have a wife and two kids
19.11.51 #       <LinusN> and a job
19.12.55 #       <LinusN> not just any wife btw, as she is in a wheelchair, so she needs a lot of help
19.13.23 #       <mirak> ok
19.13.25 #       <LinusN> Quelsaruk: yes, she is in fact a little better
19.13.28 #       <mirak> sorry
19.13.37 #       <LinusN> that's life
19.13.45 #       <LinusN> mine at least :-)
19.14.33 #       <Quelsaruk> oh
19.14.35 #       <Quelsaruk> That's great
19.14.40 #       <LinusN> yes
19.14.55 #       <LinusN> she has almost halved the morphine dose
19.15.07 #       <Quelsaruk> good news, indeed
19.15.08 #       <Quelsaruk> :)
19.17.44 Join    matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se)
19.18.54 #       <Quelsaruk> time to go, see you later/another day
19.19.00 Nick    Quelsaruk is now known as Quel|away (n=kvirc@80-103-103-117.mad1.adsl.uni2.es)
19.20.30 ***     Saving seen data "./dancer.seen"
19.29.27 Quit    muesli- (Read error: 110 (Connection timed out))
19.39.25 #       <RotAtoR> I've run into a strange problem display text on the iriver wiht my plugin.  Would anyone be willing to look at my code?
19.39.47 #       <RotAtoR> I've got the problem narrowed down to one block of code, but it makes no sense to me.
19.40.29 #       <LinusN> bejeweled?
19.40.31 #       <RotAtoR> yes
19.40.45 #       <RotAtoR> http://netfiles.uiuc.edu/aboot2/www/bejeweled-test.c
19.40.45 #       <LinusN> show me
19.41.12 #       <RotAtoR> I've got it narrowed down to one place in the function bejeweled_init()
19.42.05 #       <RotAtoR> the act of running the "clear the playboard" section of code causes text not to be displayed on the screen ever again on the target only, but it still works fine on the sim
19.42.49 Quit    hshah ("CGI:IRC (EOF)")
19.43.25 #       <RotAtoR> the strange thing is that all the other graphics display works fine, the mono_bitmap calls, lines, and rects
19.43.35 #       <RotAtoR> just text stops working
19.44.12 #       <LinusN> RotAtoR: haven't you swapped height and width in the loop?
19.44.53 #       <LinusN> i runs from 0 to 9, but the array has only 8 elements in that dimension
19.45.02 #       <RotAtoR> hmm, that could be a problem...
19.45.23 #       <LinusN> i think you accidentally overwrite the static strings with 0's
19.45.59 #       <RotAtoR> arrgh, i'll check into it
19.46.15 #       <LinusN> btw, memset is your friend
19.46.46 #       <RotAtoR> hmm, yeah, that would be easier since I set it all to 0
19.46.48 #       <LinusN> and using macros for height and width might be a good idea
19.47.21 #       <RotAtoR> yeah, i know, it' still a work in progress :p
19.48.55 #       <LinusN> gotta go, good luck
19.49.03 #       <RotAtoR> thanks for the help!
19.50.23 #       <LinusN> yw
19.50.25 Part    LinusN
19.52.21 Join    DrMoos [0] (i=DrMoos@m79.net81-66-158.noos.fr)
19.53.11 Quit    Moos (Read error: 104 (Connection reset by peer))
19.53.39 Quit    mirak (Remote closed the connection)
19.59.50 Nick    DrMoos is now known as Moos (i=DrMoos@m79.net81-66-158.noos.fr)
20.02.33 Join    Sucka [0] (i=dave@dhcp-163-1-214-173.seh.ox.ac.uk)
20.08.16 Join    muesli_- [0] (i=muesli_t@hmln-d5147617.pool.mediaWays.net)
20.11.30 #       <RotAtoR> LinusN: That was the problem, thanks. Hooray for mistakes so stupid they're impossible to see... :)
20.23.16 Quit    actionshrimp (Read error: 110 (Connection timed out))
20.43.15 Join    muesli- [0] (i=muesli_t@hmln-d9b8efb3.pool.mediaWays.net)
20.59.32 Quit    muesli_- (Read error: 113 (No route to host))
21.02.58 Join    DrMoos [0] (i=DrMoos@m79.net81-66-158.noos.fr)
21.03.20 Quit    Moos (Read error: 104 (Connection reset by peer))
21.03.29 Nick    DrMoos is now known as Moos (i=DrMoos@m79.net81-66-158.noos.fr)
21.20.34 ***     Saving seen data "./dancer.seen"
21.30.57 Quit    Rick (Read error: 104 (Connection reset by peer))
21.32.07 Join    Rick [0] (i=rick@pool-71-108-9-40.lsanca.dsl-w.verizon.net)
21.43.10 Quit    linuxstb_ ("CGI:IRC")
21.48.50 Join    [IDC]Dragon [0] (n=54839cd4@labb.contactor.se)
21.49.40 #       <amiconn> hi [IDC]Dragon
21.49.47 #       <[IDC]Dragon> hi guys
21.49.48 #       <amiconn> ltnirc!
21.49.54 #       <[IDC]Dragon> really
21.50.20 #       * amiconn just committed a new SH1 memcpy()
21.50.23 #       <[IDC]Dragon> and I'm only here to abuse some external brain
21.50.36 #       <[IDC]Dragon> I need a very primitive PRNG
21.50.55 #       <[IDC]Dragon> for my home networking controllers
21.51.05 #       <amiconn> Just use the one from the grayscale lib
21.51.12 #       <[IDC]Dragon> to determine a backoff interval on collisions
21.51.30 #       <[IDC]Dragon> that's what I remembered, yes
21.51.36 #       <amiconn> It only needs 16 bit ints
21.52.00 #       <[IDC]Dragon> it would be cool to add some "randomness" whenever I encounter some
21.52.26 #       <[IDC]Dragon> like, the local time stamp on incoming bytes
21.52.32 #       <amiconn> In fact it's the algorithm that the good old ZX Spectrum used. Not taken from the code, it was described in the manual
21.53.03 #       <amiconn> Linear congruency is almost trivial, you only need 'good' parameters
21.53.03 #       <[IDC]Dragon> not taken form Z80 assembler?  ;-)
21.53.08 #       <amiconn> nope
21.53.20 #       <amiconn> It's way easier with SH1 because it has mul
21.53.29 #       <amiconn> 6 asm instructions for the prng itself
21.54.27 #       <amiconn> Does your controller have mul?
21.55.43 #       <[IDC]Dragon> I think so
21.56.52 #       <[IDC]Dragon> (never went down to asm, gcc worked very well)
21.58.10 #       <amiconn> Is this a 16 or 32 bit controller?
21.58.51 #       <[IDC]Dragon> hehe, 8 bit
21.58.56 #       <amiconn> urgs
21.59.19 #       <[IDC]Dragon> no problem in C
22.00.36 #       <[IDC]Dragon> I have some CRC code anyway, was thinking about using that
22.00.53 #       <amiconn> Hmm?
22.01.03 #       <[IDC]Dragon> easy re-randomisation
22.01.03 #       <amiconn> What does CRC have to do with PRNG?
22.01.19 #       <amiconn> How many random bits would you need?
22.01.44 #       <[IDC]Dragon> very few, 2..4
22.01.46 #       <amiconn> Linear congruency is simple, but not all bits of the result are very random
22.02.10 #       <amiconn> The prng in the grayscale is 16 bit. The upper 8 bits are random enough
22.02.20 #       <[IDC]Dragon> yes, saw that
22.02.33 #       <[IDC]Dragon> do you seed it?
22.02.38 #       <amiconn> no
22.03.24 #       <amiconn> No need to, as I only need a random 'looking' sequence. It can be the same every time the grayscale lib is used
22.03.53 #       <amiconn> It avoid moire patterns
22.03.59 #       <[IDC]Dragon> for me, a different sequence is essential
22.04.13 #       <amiconn> Then you'll need a seed
22.04.24 #       <amiconn> It's the same with all prngs
22.04.36 #       <[IDC]Dragon> sure
22.04.56 #       <[IDC]Dragon> the only thing that differs inbetween my controllers is the address
22.05.11 #       <[IDC]Dragon> so that would be a first seed
22.05.46 #       <amiconn> The sequences will be shifted anyway, because (I assume) the controllers aren't powered up at the same time
22.05.59 #       <[IDC]Dragon> some more randomization on the way is welcome, like those timestamps when receiving external bytes
22.06.28 Join    einhirn [0] (i=Miranda@szgt-d9b8e2cf.pool.mediaWays.net)
22.06.31 #       <[IDC]Dragon> they are powered on together
22.06.46 #       <amiconn> ah, hmm
22.06.51 #       <[IDC]Dragon> but reset hold time seems to vary
22.07.07 #       <[IDC]Dragon> voltage rise, analog stuff
22.07.39 #       <[IDC]Dragon> but that doesn't give me different numbers
22.15.37 #       * [IDC]Dragon glances over the memcpy()
22.16.22 #       <[IDC]Dragon> perhaps the most advanced the SH has ever seen ;-)
22.17.10 #       <amiconn> Next thing (already started) is the reverse copy, then I'll combine both to form a memmove() with "embedded" memcpy()
22.17.23 #       <amiconn> After that I'll do the same for coldfire
22.18.30 Join    JAJDude [0] (n=ca51121e@labb.contactor.se)
22.23.26 Quit    JAJDude (Client Quit)
22.28.55 Join    Kohlriba [0] (n=Kohlrabi@dslb-082-083-130-062.pools.arcor-ip.net)
22.30.05 #       <[IDC]Dragon> reverse for bidir scrolling?
22.31.51 #       <amiconn> For memmove() in general
22.32.05 #       <amiconn> Useful for scrolling and other things
22.46.23 Quit    Kohlrabi (Read error: 110 (Connection timed out))
23.02.05 Join    muesli_- [0] (i=muesli_t@hmln-d9b8ef50.pool.mediaWays.net)
23.17.08 Join    tvelocity [0] (n=tony@ipa97.7.tellas.gr)
23.20.35 ***     Saving seen data "./dancer.seen"
23.25.49 #       <[IDC]Dragon> Jens, I use your PRNG now, with an extra randomize
23.26.00 Quit    muesli- (Read error: 110 (Connection timed out))
23.27.18 #       <amiconn> Wow... my reverse copy loop is working correctly at the first try
23.27.34 #       <amiconn> suspicious, I'd say...
23.28.28 #       <[IDC]Dragon> the coplex stuff is "always" correct, it's the simple things that breaks me
23.28.38 #       <[IDC]Dragon>     complex
23.31.05 #       <amiconn> I should choose the reverse loop as 'standard' (the one used for memcpy). It's a bit faster than the forward case
23.32.29 #       <[IDC]Dragon> never mind, I'm sleepy
23.33.01 #       <[IDC]Dragon> goodnight
23.33.09 #       <amiconn> nitey
23.33.21 Quit    [IDC]Dragon ("CGI:IRC (EOF)")
23.49.03 Quit    einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
23.58.43 Quit    RotAtoR (Nick collision from services.)
23.59.00 Join    RotAtoR [0] (n=e@12-210-82-91.client.insightBB.com)