--- Log for 03.10.112 Server: leguin.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 1 month and 4 days ago 00.01.48 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 00.03.41 Quit AlexP (Remote host closed the connection) 00.04.25 Quit kevku (Ping timeout: 260 seconds) 00.04.52 Join kevku [0] (x@indeed.tastes.like.everything.mm.am) 00.12.08 Quit saratoga (Quit: CGI:IRC) 00.16.07 Nick Provel_ is now known as Provel (~Provel@75-132-15-43.dhcp.stls.mo.charter.com) 00.16.57 Join amayer [0] (~alex@h62.26.25.72.ip.windstream.net) 00.17.20 # [Saint]: ping 00.31.46 Quit kevku (Ping timeout: 272 seconds) 00.36.27 Quit ender` (Quit: How do you generate a random string? Put a new user in front of VIM and tell him to save and quit. -- Duane Morin) 00.45.43 Quit pamaury_ (Ping timeout: 256 seconds) 00.52.48 Join AlexP [0] (~alex@rockbox/staff/AlexP) 00.57.27 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 00.58.50 Quit Rower85 (Read error: Connection reset by peer) 00.59.54 Quit eckoit (Quit: eckoit) 01.14.08 Join eckoit [0] (~ryan@50.65.10.24) 01.21.18 Join Keripo [0] (~Keripo@c-76-22-63-234.hsd1.wa.comcast.net) 01.23.33 Join Scromple_ [0] (~Simon@161.43.73.67) 01.25.47 Quit Scr0mple (Ping timeout: 246 seconds) 01.26.39 Quit mgottschlag (Ping timeout: 246 seconds) 01.29.11 Part amayer 01.30.45 Quit sakax (Remote host closed the connection) 01.40.22 Quit nosa-j (Ping timeout: 260 seconds) 01.43.23 Join nosa-j [0] (~m00k@184.76.254.130) 01.46.47 Quit mikroflops (Ping timeout: 246 seconds) 01.48.46 Join mikroflops [0] (~yogurt@h-34-239.a238.priv.bahnhof.se) 01.49.53 Quit tchan (Ping timeout: 260 seconds) 01.53.52 *** Saving seen data "./dancer.seen" 01.55.25 Quit Thra11_ (Ping timeout: 256 seconds) 01.59.09 Quit Gallomimia (Quit: Gallomimia) 02.21.29 Quit lebellium (Quit: ChatZilla 0.9.89 [Firefox 16.0/20120925201946]) 02.22.37 Quit Syconaut (Ping timeout: 256 seconds) 02.25.41 Join pedro_angelo [0] (~pedro_ang@186-241-153-164.user.veloxzone.com.br) 02.28.29 Join Syconaut [0] (viper@c-60fd72d5.162-1-64736c10.cust.bredbandsbolaget.se) 02.33.21 Join fyrestorm [0] (~nnscript@cpe-67-244-91-182.nyc.res.rr.com) 02.53.44 Quit XavierGr () 03.07.17 Quit Prodicus (Ping timeout: 246 seconds) 03.08.41 Quit scorche` (Ping timeout: 244 seconds) 03.10.36 Join Prodicus [0] (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) 03.12.01 Join scorche [0] (~scorche@rockbox/administrator/scorche) 03.13.42 Join mikroflops_ [0] (~yogurt@h-34-239.a238.priv.bahnhof.se) 03.17.28 Quit mikroflops (Ping timeout: 252 seconds) 03.17.57 Quit pedro_angelo (Remote host closed the connection) 03.27.42 Quit Prodicus (Ping timeout: 260 seconds) 03.31.16 Join zchs [0] (~zchs@ool-ad02eb3f.dyn.optonline.net) 03.33.48 Join Prodicus [0] (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) 03.42.27 Quit Prodicus (Ping timeout: 255 seconds) 03.43.23 Join Prodicus [0] (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) 03.53.56 *** Saving seen data "./dancer.seen" 04.01.49 Join [Saint_] [0] (~saint@rockbox/user/saint) 04.02.33 Quit [Saint] (Ping timeout: 240 seconds) 04.12.04 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.12.05 Quit amiconn (Disconnected by services) 04.12.09 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.12.21 Join pixelma [0] (pixelma@rockbox/staff/pixelma) 04.13.50 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 04.16.09 Quit pixelma_ (Ping timeout: 252 seconds) 04.16.10 Join mikroflops [0] (~yogurt@h-34-239.a238.priv.bahnhof.se) 04.19.36 Quit mikroflops_ (Ping timeout: 245 seconds) 04.21.29 Quit Epicanis (Quit: bedtime) 04.38.16 Join TheSphinX_ [0] (~briehl@p579CC23C.dip.t-dialin.net) 04.38.21 Quit T44 (Read error: Connection reset by peer) 04.40.04 Quit TheSphinX^ (Read error: Operation timed out) 04.45.02 Join mikroflops_ [0] (~yogurt@h-34-239.a238.priv.bahnhof.se) 04.45.52 Quit mikroflops (Read error: Operation timed out) 04.55.35 Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) 05.00.55 Nick [Saint_] is now known as [Saint] (~saint@rockbox/user/saint) 05.12.47 Join Topy44 [0] (~Topy44@f049128112.adsl.alicedsl.de) 05.19.13 Quit Keripo (Read error: Connection reset by peer) 05.19.27 Quit [7] (Disconnected by services) 05.19.36 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 05.48.06 Join webguest40 [0] (~62667a0a@www.haxx.se) 05.49.57 Quit webguest40 (Client Quit) 05.54.00 *** Saving seen data "./dancer.seen" 05.59.43 Join mikroflops [0] (~yogurt@h-34-239.a238.priv.bahnhof.se) 06.02.26 Quit mikroflops_ (Ping timeout: 240 seconds) 06.50.38 Join Keripo [0] (~Keripo@c-76-22-63-234.hsd1.wa.comcast.net) 06.52.22 Quit Prodicus (Ping timeout: 256 seconds) 06.52.57 Join mikroflops_ [0] (~yogurt@h-34-239.a238.priv.bahnhof.se) 06.56.54 Quit mikroflops (Ping timeout: 256 seconds) 06.58.59 Join Prodicus [0] (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) 07.12.29 Join mortalis [0] (~mortalis@195.34.194.126.kalibroao.ru) 07.17.39 Quit Prodicus (Ping timeout: 248 seconds) 07.26.30 Quit Totalled (Ping timeout: 240 seconds) 07.41.07 Join kevku [0] (x@indeed.tastes.like.everything.mm.am) 07.54.00 Join Gallomimia [0] (~Gallo@S01060026f3e151a0.ca.shawcable.net) 07.54.01 *** Saving seen data "./dancer.seen" 07.54.01 Quit Gallomimia (Excess Flood) 08.05.06 Join factor [0] (~factor@r74-195-218-112.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 08.16.08 Join LinusN [0] (~linus@giant.haxx.se) 08.24.10 Quit zoktar (Ping timeout: 245 seconds) 08.30.02 # * [Saint] wonders how hard it'd be to do file view settings on a per-folder basis in the file explorer. 08.33.28 # <[Saint]> all files in /bar, music only in /foo, supported files in /baz, etc. 08.33.45 Join stoffel [0] (~quassel@pD9E4208A.dip.t-dialin.net) 08.33.50 # <[Saint]> that'd be kinda cool. 08.39.42 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 08.40.30 Join zoktar [0] (~zoktar@78-72-49-215-no186.tbcn.telia.com) 08.52.00 Join ender` [0] (krneki@foo.eternallybored.org) 09.02.03 Join Rower85 [0] (husvagn@82.196.99.90) 09.12.33 Join petur [0] (~petur@rockbox/developer/petur) 09.14.10 Nick Zambezi_ is now known as Zambezi (Zulu@bnc.fran.dotbnc.se) 09.15.10 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 09.15.10 Quit pamaury (Changing host) 09.15.10 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 09.37.49 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 09.48.17 Join mikroflops [0] (~yogurt@h-34-239.a238.priv.bahnhof.se) 09.49.29 Quit mikroflops_ (Read error: Operation timed out) 09.54.04 *** Saving seen data "./dancer.seen" 09.54.10 Quit pamaury (Ping timeout: 255 seconds) 09.54.28 Join Gallomimia [0] (~Gallo@S01065cd9986bb715.ca.shawcable.net) 10.04.14 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 10.21.48 Quit mgottschlag (Ping timeout: 246 seconds) 10.23.04 Join minouch [0] (~d590c461@www.haxx.se) 10.41.41 Quit Galois (Ping timeout: 272 seconds) 10.52.42 Join pamaury [0] (~quassel@sphinx.lix.polytechnique.fr) 10.52.42 Quit pamaury (Changing host) 10.52.42 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.52.47 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 11.02.56 Join mikroflops_ [0] (~yogurt@h-34-239.a238.priv.bahnhof.se) 11.06.40 Quit mikroflops (Ping timeout: 245 seconds) 11.21.30 Quit mgottschlag (Ping timeout: 246 seconds) 11.22.45 Join einhirn [0] (~Miranda@p4FC74613.dip0.t-ipconnect.de) 11.23.48 Quit stoffel (Remote host closed the connection) 11.24.11 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 11.31.39 Quit mgottschlag (Ping timeout: 246 seconds) 11.32.50 Quit Gallomimia (Quit: Gallomimia) 11.36.04 Join {phoenix} [0] (~dirk@p4FEC58A4.dip.t-dialin.net) 11.40.44 Join lebellium [0] (~chatzilla@g231209006.adsl.alicedsl.de) 11.41.25 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 11.46.22 Quit Rower85 (Quit: Hmmm...) 11.46.34 Quit bluebrother (Disconnected by services) 11.46.39 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 11.48.56 Join Rower85 [0] (husvagn@82.196.99.90) 11.48.57 Quit fs-bluebot (Ping timeout: 246 seconds) 11.50.16 Join fs-bluebot [0] (~fs-bluebo@g225255254.adsl.alicedsl.de) 11.54.06 *** Saving seen data "./dancer.seen" 11.54.44 Join mgottschlag2 [0] (~quassel@2a00:1398:9:fb00:41c2:a5:80fa:9dba) 11.55.06 Quit mgottschlag (Ping timeout: 246 seconds) 11.55.39 Join Thra11_ [0] (~thrall@37.147.125.91.dyn.plus.net) 11.58.57 Quit mgottschlag2 (Ping timeout: 246 seconds) 12.04.16 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 12.05.34 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 12.09.04 Quit Keripo (Quit: Leaving.) 12.15.51 Quit linuxstb (Quit: This computer has gone to sleep) 12.16.48 Quit mgottschlag (Ping timeout: 246 seconds) 12.18.48 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 12.21.22 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 12.31.08 Quit mgottschlag (Read error: Connection reset by peer) 12.31.18 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 12.37.27 Quit mgottschlag (Ping timeout: 246 seconds) 12.38.03 Quit scorche (Disconnected by services) 12.38.07 Join scorche` [0] (~scorche@rockbox/administrator/scorche) 12.39.32 Join T44 [0] (~Topy44@g228174117.adsl.alicedsl.de) 12.41.37 Quit wodz (Quit: Leaving) 12.42.47 Join Buschel [0] (~chatzilla@p57905630.dip.t-dialin.net) 12.43.08 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 12.43.12 Quit Topy44 (Ping timeout: 246 seconds) 12.44.04 Quit minouch (Quit: CGI:IRC) 12.45.52 Join linuxstb [0] (~linuxstb@94-195-193-195.zone9.bethere.co.uk) 12.48.23 Quit mgottschlag (Ping timeout: 252 seconds) 12.53.24 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 12.56.03 Quit Rower85 (Read error: Connection reset by peer) 13.01.37 Join Rower85 [0] (husvagn@82.196.99.90) 13.02.18 Quit petur (Quit: *plop*) 13.10.44 Join mgottschlag2 [0] (~quassel@195.37.186.61) 13.10.57 Quit mgottschlag (Read error: Connection reset by peer) 13.20.09 Quit mgottschlag2 (Ping timeout: 246 seconds) 13.21.11 Quit Rower85 (Quit: Hmmm...) 13.21.42 Join dfkt [0] (dfkt@unaffiliated/dfkt) 13.22.25 # wodz (logs): I'm updated the atjboottool on my repo, it now successfully extracts the FWIMAGE.BIN file. All the drivers in it use the ELF format and I suspect the WELCOME.BIN file is the main binary but I don't have a mips toolchain to check that. Do you think I should integrate this tool to the rockbox repo ? 13.23.38 Join Prodicus [0] (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) 13.23.56 Quit zoktar (Ping timeout: 268 seconds) 13.25.06 Join Rower85 [0] (husvagn@82.196.99.90) 13.46.08 Join stoffel [0] (~quassel@pD9E4208A.dip.t-dialin.net) 13.47.22 Quit stoffel (Remote host closed the connection) 13.50.21 Quit T44 (Read error: Connection reset by peer) 13.50.38 Join Topy [0] (Topy44@g228174117.adsl.alicedsl.de) 13.52.19 Join stoffel [0] (~quassel@pD9E4208A.dip.t-dialin.net) 13.54.10 *** Saving seen data "./dancer.seen" 13.59.56 Quit stoffel (Remote host closed the connection) 14.02.03 Join einhirn [0] (~Miranda@p4FC74613.dip0.t-ipconnect.de) 14.03.05 Quit einhirn (Client Quit) 14.04.57 Join zoktar [0] (~zoktar@78-72-49-215-no186.tbcn.telia.com) 14.10.09 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 14.10.32 Quit linuxstb (Ping timeout: 256 seconds) 14.11.07 # pamaury: We have a tool for rknano so I don't see why not to commit ATJ tools to our repo 14.11.26 # ok, I'll do that then 14.11.50 # all in all this is impressive reverse engineer work done by rb dev :-) 14.12.00 # :) 14.12.01 Join stoffel [0] (~quassel@pD9E4208A.dip.t-dialin.net) 14.12.47 # if you want me to write the correspoding scrambling tool, please tell me, I don't know if you really plan to develop for this platform 14.14.14 # I plan to develop for this platform, but I don't need scrambling now. Studying OF will take some time considering I'll have to learn MIPS asm 14.14.37 # And first I would like to finish elf loader stuff 14.14.53 Join linuxstb [0] (~linuxstb@94-195-193-195.zone9.bethere.co.uk) 14.14.54 # sure 14.16.37 Quit stoffel (Ping timeout: 260 seconds) 14.19.28 Join amayer_ [0] (~alex@mail.weberadvertising.com) 14.30.22 # wodz: done 14.30.38 # feel free to edit/fix/improve it 14.31.18 # if I have the time, I'll try to rewrite it in C++ with a big number class and some more structures to better understand what it really does 14.32.59 # I don't know if it's really atj2137 specific or atj213x as the tool says 14.33.06 Join Totalled [0] (~Totalled@c-98-245-9-211.hsd1.co.comcast.net) 14.37.18 # It is easy to find out. Iriver E100 is based on ATJ2135n and firmware update image is available. But I guess this will work for 213x family 14.50.06 Quit factor (Quit: Leaving) 14.53.24 Join stoffel [0] (~quassel@pD9E4208A.dip.t-dialin.net) 14.57.48 Quit Buschel (Ping timeout: 246 seconds) 15.06.06 Quit Topy (Read error: Connection reset by peer) 15.06.13 Join T44 [0] (Topy44@g228174117.adsl.alicedsl.de) 15.10.02 Quit {phoenix} (Remote host closed the connection) 15.11.58 Quit wodz (Quit: Leaving) 15.35.27 Quit T44 (Read error: Connection reset by peer) 15.36.05 Join T44 [0] (Topy44@92.228.174.117) 15.39.22 # why is lang/ under apps/ ? 15.39.24 # i was looking for lang and apps/ seems like a confusing place to find it 15.43.53 Quit stoffel (Ping timeout: 260 seconds) 15.44.16 Join XavierGr [0] (XavierGr@rockbox/staff/XavierGr) 15.44.22 Quit mortalis (Quit: Leaving) 15.48.25 # amayer_: apps/ stands for "the application layer", which basically means everything that implements user functionality, i.e. not drivers 15.48.51 # oh ok. that makes a little more sense 15.49.41 # i was thinking apps like functionality wise 15.52.46 Part LinusN 15.54.13 *** Saving seen data "./dancer.seen" 15.58.18 Join Galois [0] (djao@efnet-math.org) 16.30.10 # I'm currently playing a 64kb/s opus file in realtime on the clipv1. It sounds great! Something in the last 2 or 3 commits did it. Before that it wouldn't play at all and froze on the WPS. Only problem now is that stopping playback freezes the player. If I pause first, it reboots. If it's playing when I stop, it hard freezes. 16.34.36 Quit pamaury (Ping timeout: 252 seconds) 17.02.02 Join saratoga [0] (123e0cca@gateway/web/freenode/ip.18.62.12.202) 17.03.02 Quit Zagor (Quit: Clint excited) 17.04.07 # 128k is also playing in realtime on the clip v1. But now I get a reboot instead of a hard freeze when I stop the track, whether it's playing or not. Trach switch works perfectly however. It's almost usable on this device. 17.04.39 # theres almost certainly not enough memory on the clipv1, so you're probably overwriting things in memory as you play 17.06.17 # Sounds logical, but then it shouldn't play at all I would think. I should be having the same problems I had 2 days ago, e.g. a hard freeze without playing anything. 17.06.19 # derf: said it should be ok 17.07.30 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 17.08.29 # i don't see why it shouldn't play 17.08.45 # funman: is there someway i can see what i'm about to push to rockbox git before I do it? 17.09.51 # * the-kyle got it to play 3 tracks in a row, at 64k and 128k. They play gaplessly, and I can skip to previous and next tracks. Pause/resume also work perfectly, and I am able to return to the main menu while playing, although it is just a bit sluggish, and voice clips tend to chop. Only stop seems to crash and reboot now. 17.09.59 # ugh i cannot use git at all 17.10.52 # saratoga: git push --dry-run 17.11.28 # Ah, it's hard freezing at the file browser. 17.11.37 # while a track is playing. 17.13.03 # do i need to setup the gerrit thing on each computer i want to push from? 17.13.55 # Oh weird. I can switch to recording while an opus file plays without freezing the device. 17.14.15 # It stops successfully and switches to recording mode. 17.14.43 # But then it freezes at the file browser the next time I try to open it. 17.15.36 Join freqmod [0] (~quassel@cm-84.215.142.108.getinternet.no) 17.15.39 # saratoga: you need to do the local setup steps in every repo, yes 17.15.49 # if you use the same ssh key on every machine you don't need to touch anything on the server 17.15.57 Join pedro_angelo [0] (~pedro_ang@186-241-153-164.user.veloxzone.com.br) 17.15.58 # but if they ahve different keys you need to add all the keys on the web too 17.16.42 # Buffer size: 3.99GB. This looks funky. 17.16.51 # ah yes i got it 17.17.01 # funman: dry run doesn't tell me what its actually committing though 17.17.10 # the-kyle: that's slightly less than zero, probably :) 17.17.24 # i just want to check what will actually get pushed 17.17.26 # saratoga: git log origin/master.. will show you all the commits you have locally that are not already there 17.17.49 # (the .. means "difference between" and the missing second argument defaults to "the HEAD of the current local branch") 17.17.59 # Wow! Looks like it will work nearly perfectly very soon then. Great work! 17.18.03 # is there some way to see the code though? 17.18.13 # i basically want to do svn diff 17.18.19 # so i can see what i'm about to change 17.18.44 # git log -p will show the patch for each commit. 17.18.49 # or you can just git diff origin/master 17.19.01 # to see a single diff that is the difference from the master branch to your local branch 17.19.25 # I thought i had to commit stuff before git would push them? 17.19.37 # isn't git diff just showing me all differences, not the ones i've committed? 17.19.42 # Upon turning on the device, the buffer size is shown as 133KB. 17.20.08 # git diff can compare anything to anything 17.20.24 # so how do i get it to show me just what i'm about to change on the main repo 17.20.38 # it depends what command you are about to run to push :) 17.20.44 # Buffer size is showing 3.99GB when I play a Vorbis file also. 17.20.46 # possibly you want git diff origin/master HEAD 17.20.57 # which is the difference between the server's master and your latest commit 17.21.13 # this will be the same as just `git diff origin/master` unless you have local changes you haven't committed 17.21.16 # that shows a bunch of stuff i didn't think i committed 17.21.21 # although maybe i did by accident 17.21.25 # i admit i have no idea what any of this means 17.21.37 # saratoga: your local branch is probably out of date with respect to master 17.21.47 # so you are also seeing the *reverse* diff for everything that' sbeen committed since you updated 17.21.50 # if that makes sense 17.21.58 # no its all stuff i changed 17.21.58 # do `git pull --rebase` first 17.22.07 # like adding the test codecs to SOURCES 17.22.24 # well, if they show up when you do `git diff origin/master HEAD` then you committed them 17.22.33 # crap 17.22.39 # is there only one commit in the log command i suggested? 17.23.36 # two, but one is the commit i just sent in through gerrit 17.23.42 # so i guess that needs to be rebased 17.23.55 # but i don't see the stuff i do on diff 17.24.20 # does git status say you have any local changes at all? 17.24.36 Quit funman (Ping timeout: 255 seconds) 17.25.00 Quit linuxstb (Ping timeout: 245 seconds) 17.25.01 # yes it shows the two commits 17.25.11 # the one from gerrit and the one i want to add 17.25.14 # i mean, local changes to files 17.25.47 # ah yes it shows two files modified 17.25.58 # plugins/SOURCES and somethign in firmware 17.26.00 # so you have a bunch of different things :) 17.26.14 # anyway. 17.26.17 # rebase, first 17.26.27 # so it will stop thinking you have two local commits taht aren't submitted. 17.26.34 # git pull --rebase? 17.26.34 # then look at git log -p origin/master.. 17.26.37 # yes 17.26.44 # the log should just have one commit in, then 17.26.52 # it complains that i have changes 17.26.53 # and the diff attached to it is hopefully the diff you meant to commit 17.27.02 # yeah, it will. :) 17.27.14 # stash them first 17.28.04 # huh pull says i'm up to date 17.28.06 # which can't be right 17.28.14 Join linuxstb [0] (~linuxstb@94-195-193-195.zone9.bethere.co.uk) 17.28.30 # Yes it can :) 17.28.42 # in fact, it almost certainly is, and you are mistaken 17.28.44 # :p 17.29.17 # git diff still shows other peoples commits though 17.29.17 # What did I say should be okay? 17.29.22 # shouldn't rebase fix that? 17.31.52 # i just want to add one line of code, is there someway i can delete my git repo and check it out again without having to redo the gerrit setup? 17.31.59 # you never need to delete the repo 17.32.06 # no matter what you do, prettymuch 17.32.35 # if you really want to get rid of the stuff you have done locally, git reset --hard origin/master will blow away the current branch and make it identical to the server again, including destroying local uncommitted changes 17.33.01 # i wouldn't suggest you do that because whatever state you are in you probably should work it out so you don't do it again :p 17.33.06 # but if you really can't be bothered that will work 17.35.06 Quit linuxstb (Ping timeout: 256 seconds) 17.38.16 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 17.38.17 Quit pamaury (Changing host) 17.38.17 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 17.43.07 Join linuxstb [0] (~linuxstb@46-65-38-42.zone16.bethere.co.uk) 17.44.55 Join funman [0] (~fun@rockbox/developer/funman) 17.45.05 # derf: you said opus decoder should fit in clipv1 ram no ? 17.45.38 Join stoffel [0] (~quassel@pD9E4208A.dip.t-dialin.net) 17.45.57 # I might have. How much does it have? 17.47.39 # 384kB for the codec iirc 17.47.40 Quit linuxstb (Read error: Connection reset by peer) 17.47.58 # Yeah, I agree that should be plenty. 17.49.00 Join n1s [0] (~n1s@nl118-168-30.student.uu.se) 17.49.01 Quit n1s (Changing host) 17.49.01 Join n1s [0] (~n1s@rockbox/developer/n1s) 17.53.12 # funman: derf: As far as I can tell, it's very, very close. Only place I have trouble is when I try to stop playback and return to the main menu or when I try to open the file browser while an Opus file is playing. 17.53.45 # the-kyle: I don't know enough about Rockbox to know why that in particular would be a problem. 17.54.16 *** Saving seen data "./dancer.seen" 17.54.18 # And there's still a little sluggishness when voice clips are played at the same time as an Opus file. 17.54.54 # But I expect both problems will be worked out very shortly. It's already progressed faster than I had imagined on this device. 17.55.43 # Both 64k and 128k play in realtime now. I haven't tested 256, but I think that's overkill on a 2GB player. 17.55.49 Join linuxstb [0] (~linuxstb@46-65-38-42.zone16.bethere.co.uk) 17.56.19 Quit linuxstb (Read error: No route to host) 17.57.03 # * the-kyle most likely will use 64k on this device, but may use 128k at times also. 17.57.58 # Neither bitrate is causing more or less problems in memory than the other. 17.58.12 Quit amayer_ (Ping timeout: 246 seconds) 17.58.57 # If it makes a difference, I've been setting the framesize to 60ms when encoding. I could run some tests with default framesize settings. 18.00.50 Join Buschel [0] (~chatzilla@p57905630.dip.t-dialin.net) 18.02.13 # funman: the clipv1 config #defines CODEC_SIZE 0x48000 which is 288k, is it bigger than that? 18.03.25 # the-kyle: do you have a clipv1 and is your build unmodified? 18.05.15 # n1s: I do have a clipv1, but it's currently running a modified build with hotkey and WPS announcement patches. I can run an unmodified build on it, as I do keep a clean unmodified git tree available for testing. 18.06.45 Join Epicanis [0] (~Epicanis@static-72-95-113-7.port.east.myfairpoint.net) 18.08.50 Join einhirn [0] (~Miranda@p4FC74613.dip0.t-ipconnect.de) 18.10.41 # the-kyle: those modifications shouldn't matter, i meant if the opus codec was unmodified. So it's working now? i remember it crashing for you, any idea when that stopped? 18.10.46 Quit n1s (Read error: Connection timed out) 18.11.27 Quit bootlkjkgf (Quit: you'll probably leave it Late ::: SO GET ON WITH IT ! http://www.ohloh.net/p/systemd) 18.12.21 # the clipv1 has 288KB of codec memory 18.13.20 # It crashed when I built it on Monday, but I tested it after rebuilding today and it works. 18.14.12 # Let me look at my opus codec. I may have cept the -Os flag. 18.14.17 # kept 18.14.44 # So the Makefile may be modified still. 18.16.10 # I do still have the -Os optimization set. Let me change it back to the default -O2 and see what happens. 18.16.56 # n1s: did you have time to test / measure the updated patch? 18.18.15 # i would check the map file and then log mallocs so that you can see how much (if any) extra memory is needed 18.19.28 Join n1s_web [0] (~82f3a81e@www.haxx.se) 18.19.39 # there he is :) 18.19.49 # n1s: did you have time to test / measure the updated patch? 18.20.28 # Buschel: nope but i can do it soonish 18.21.04 # fije, i am still curious ;) 18.21.11 # ahem, "fine" 18.21.15 # saratoga: i did check out how much memory it needs and i'ts something like 320k iirc, definitely more than 288k atm at least 18.21.54 # that global stack is 100k and afaict that's fairly arbitrary 18.22.01 # It is. 18.22.09 # Still need to sit down and compute what the real limit is. 18.22.10 # theres 320KB of total IRAM, but about 30KB is allocated for core features 18.22.34 # does opus use the normal codec malloc? 18.22.39 Quit crwl (Ping timeout: 255 seconds) 18.22.44 # It's playing with -O2, but it has lots of warbles and blips. 18.23.01 # It plays perfectly using -Os instead of -O2. 18.23.10 # but crashes on stop 18.23.10 # saratoga: yeah it allocs a few large buffers with it but then does it's own stack thing 18.23.33 # i'd be surprised if the codec alloc think didn't check for overflow 18.23.39 # I also get the same crash on stop with -O2. 18.23.42 # AFAIK its handled gracefully on things like AAC 18.24.10 # This is the 64k test. Trying 128. 18.24.19 # might be neat to print out the malloc pointers and see where exactly they end up in relation to the map file 18.24.38 Join crwl [0] (~crwlll@a91-156-110-12.elisa-laajakaista.fi) 18.24.40 # 128k plays a very small part of the file and stops. 18.24.58 # It plays about 0.1 to 0.2 seconds. 18.25.34 # followed by a hard freeze. All this is fixed by using -Os optimization instead of -O2. 18.28.51 # wait, which malloc does Opus use? 18.29.35 # the codec_malloc 18.29.50 # but the return isn't checked in opus in a lot of places 18.30.12 # so a nullpointer deref bug is quite likley imo 18.30.29 # "A lot of places"? 18.30.36 # AFAIK only the global stack alloc isn't checked. 18.30.55 # What others have you found? 18.31.34 # ah ok i thought it was using the more complicated malloc 18.31.46 # The libogg stuff does. 18.31.55 # But all of that should be checked. 18.32.29 # g#292 might be useful here 18.32.32 # 3Gerrit review #292 at http://gerrit.rockbox.org/r/292 : Introduce new logging system to codeclib. by Michael Giacomelli (changes/92/292/7) 18.32.34 # libopus itself only mallocs when you create the decoder context and for the global stack. 18.32.37 # could log malloc fails 18.32.48 # derf: i just grepped for opus_alloc, the three places in rate.c aren't checked but i'm not sure that's even run 18.32.56 # n1s_web: It's not. 18.33.54 # compute_pulse_cache() should only be used if you've enabled custom modes. 18.34.09 # Which I hope you haven't (for code size reasons if nothing else) 18.34.25 # no we haven't i wasn't checking thoroughly enough 18.39.44 # the allocation of the output buffer (which is quite pointless since it's statically sized but w/e) is not checked, that's not libopus code though but our codec 18.40.58 # can you just get rid of the dynamic allocation? 18.41.34 # yeah should be trivial 18.43.20 Join n1s [0] (~n1s@nl118-168-30.student.uu.se) 18.43.20 Quit n1s (Changing host) 18.43.20 Join n1s [0] (~n1s@rockbox/developer/n1s) 18.43.22 # can the global stack also be done at link time? or does it somehow change size? 18.43.42 # no, i't sstatically sized too 18.44.36 # ah nice 18.44.47 # what must be dynamically sized? 18.44.50 # only the libogg stuff is truly dynamic 18.45.01 # (AFAIK) 18.45.12 # and as long as we don't use custom modes 18.45.28 # does the libogg stuff use free? 18.45.50 Join WalkGood [0] (~4@unaffiliated/walkgood) 18.45.53 Quit stoffel (Ping timeout: 260 seconds) 18.47.51 # some functions call free but i'm not sure if they are ever run, the code_free function is umm, pointless :) 18.48.54 # yeah 18.53.06 # in a quick straignt test_codec run it doesn't ever call codec_free 18.59.07 # The libogg stuff uses realloc. 18.59.15 # I don't know if that's a problem for your codec_alloc. 19.00.06 # decoding the 64kbps test file on the sim codec_mallocs a total of 212kb 19.00.34 # I'm guessing there's more than 76 kB of code on top of that. 19.04.20 # yeah, the codec binary is currently 100k on the clip 19.04.45 # so some alloc has to be failing silently 19.07.36 # afaict the global stack alloc is not checked 19.08.17 # 12:30:37 < derf> AFAIK only the global stack alloc isn't checked. 19.09.27 Join pretty_function [0] (~sigBART@123.252.215.200) 19.09.39 Quit Buschel (Ping timeout: 248 seconds) 19.10.15 Quit Galois (Ping timeout: 272 seconds) 19.11.25 # derf: ah missed that, well it's the last alloc done and the biggest so if that isn't checked, well mystery solved 19.11.47 Join Buschel [0] (~chatzilla@p57905630.dip.t-dialin.net) 19.29.56 # derf: btw that 384kB includes the code (.text .rodata .data .bss) 19.32.34 Quit funman (Quit: leaving) 19.32.41 Join funman_ [0] (~fun@rockbox/developer/funman) 19.32.49 Nick funman_ is now known as funman (~fun@rockbox/developer/funman) 19.34.39 # funman: so it *is* using some other ram than just the iram? 19.34.47 # or what? 19.37.44 # no 19.38.28 # #define CODEC_SIZE 0x48000 /* in IRAM */ 19.38.54 # that's 288kB 19.39.14 # yeah, we keep 64kB for memcpy/memset etc 19.39.23 # so 320kB - 64kB = 288kB left only for codec 19.41.22 # anyway, that's less than the codec needs atm 19.41.33 # any idea what's at adress 0 on the clipv1 19.41.36 # ? 19.43.24 # if the global stack alloc fails as i think it would write to a null pointer 19.44.30 # reset vectors 19.44.55 # firmware/target/arm/as3525/app.lds should help 19.45.51 Join prof_wolfff [0] (~prof_wolf@213.37.219.103.dyn.user.ono.com) 19.46.29 # right, if those were overwritten it would be very unlikely that it would keep running, no? 19.46.53 # unless there's some unused allocation from this stack pointer at the start 19.52.03 # I don't think there is. 19.52.44 # If you're calling opus_multistream_decode(), the first thing it does is allocate a buffer to store the decoded audio for a single channel pair. 19.53.40 # an easy test would be to increase the global stack size so the alloc fails on the sim and see if it segfaults and check it out with gdb if it does 19.54.18 *** Saving seen data "./dancer.seen" 20.01.12 Quit sinthetek (Ping timeout: 240 seconds) 20.27.32 Quit pretty_function (Ping timeout: 240 seconds) 20.30.37 Join Horscht [0] (~Horscht@xbmc/user/horscht) 20.46.02 Quit Horscht (Quit: Verlassend) 20.52.12 Quit n1s_web (Quit: CGI:IRC (Ping timeout)) 20.53.44 # first global stack alloc is in opus_decode_frame and that's a pcm_transition buffer (960b for stereo 48kHz) that is only used sometimes (not for my test file) 20.53.50 Join TomecekGD [0] (~2eafec2a@www.haxx.se) 20.53.52 # so yeah this could work 20.56.38 Quit TomecekGD (Client Quit) 20.58.21 # n1s: Are you not using the multistream API? 20.59.11 # doesn't look like it but i'm not familiar with the api's availible, there's no opus_multistream_decode() function at least 21.00.00 # If you tried to get rid of unused code, you might have deleted opus_multistream.c. 21.01.10 # i haven't deleted any files so it wasn't in the initial commit 21.01.19 # Huh. 21.01.31 # Well, it's in the upstream repository :). 21.02.09 Quit Thra11_ (Ping timeout: 260 seconds) 21.02.29 # That's not going to help speed or memory usage, though. 21.02.38 # http://git.rockbox.org/?p=rockbox.git;a=commit;h=1b8e380 no such file, but a note that multi stream files may not be parsed correctly 21.02.57 # just wha'ts a multi stream file inopus anyway 21.02.58 # But it _will_ let you play files like that from the guy in here who was complaining his file encoded with -uncoupled didn't work. 21.02.59 # ? 21.03.33 # * the-kyle had the uncoupled problem. 21.03.44 # n1s: You can stuff data from multiple streams into a single Ogg packet, and then when it decodes them, map them to different output channels. 21.03.53 # It's how Opus scales beyond just stereo coupling. 21.04.26 # uncoupled problem: http://www.rockbox.org/tracker/task/12754 21.05.00 # Buschel: Thanks. Saved me having to try to find the fs# again. 21.05.07 # (Random butt-in question: when would you WANT to use uncoupled stereo?) 21.05.41 # i guess if you had multiple channels that were not spatially related 21.05.56 # See fs#12754. There are a couple of example files that link from there. 21.05.57 # http://www.rockbox.org/tracker/task/12754 3Opus decoder fails to play stereo tracks encoded with the "--uncoupled" option (bugs, unconfirmed) 21.05.58 # btw my sim experiment went as expected, with a 2MB global stack the sim segfaults when writing to a var allocated from it 21.06.15 # Great. 21.06.57 # The example files include a binaural beat that consists of two tones, the difference in frequency generates a sympathetic brainwave. 21.07.17 # These tones by nature cannot be spatially related. 21.07.32 # derf: well, we don't support more than stereo output even if there's a device we run on that can do it so decoding multichannel stuff is not of much interest to most rb developers :) 21.08.03 # coupled should probably work fine anyway as long as the bitrate isn't very low 21.08.10 # the uncopuled stereo is an edge case imo but perhaps that should be fixed by someone 21.08.15 # usually you want an option to not combine the channels to improve compression 21.09.20 # If the example files have been encoded with no coupling effects, meaning that each channel still plays separately and independently, then uncoupled is not a problem. 21.09.30 # at least it's a secondary concern to getting the codec to work well for regular files 21.09.47 Join sciopath [0] (~sciopath@yer91-2-82-237-54-159.fbx.proxad.net) 21.09.57 Quit crwl (Ping timeout: 260 seconds) 21.11.25 # At 128k, I didn't notice any coupling when playing a split track that had music on one side and background vocals on the other. Not sure about 64k though. This is different from the examples in fs#12754, but is another case where two channels will need to be encoded independently. 21.11.25 # http://www.rockbox.org/tracker/task/12754 3Opus decoder fails to play stereo tracks encoded with the "--uncoupled" option (bugs, unconfirmed) 21.11.40 # n1s: Well, ideally you should accept more channels (if the CPU is powerful enough) and downmix to stereo. 21.12.01 # This is, e.g., what Firefox does. 21.12.18 # derf: yeah we can't even decode in realtime on several targets for the high bitrates yet :) 21.13.22 # so multiplying the cpu time needed as well as requiring a lot more memory which would mean using slow ran for hot buffers just to decode, and then doing a good job downsampling, not likely i think 21.13.30 # slow ram 21.13.56 # at least not on the slower targets, on the very fast ones, perhaps if anyone cares enough 21.14.23 Join amayer_ [0] (~alex@mail.weberadvertising.com) 21.14.34 Quit Rower85 (Quit: Hmmm...) 21.14.47 Join shiftplusone [0] (~Shift@unaffiliated/shiftplusone) 21.14.56 Part shiftplusone ("Leaving") 21.16.28 Join crwl [0] (~crwlll@a91-156-110-12.elisa-laajakaista.fi) 21.17.00 # btw, nobody added opus to our manual yet... i thought this would be mandatory for new codecs :) 21.17.53 # n1s: I understand it's not a priority, I'm just saying in an ideal world... 21.18.13 Join LinusN [0] (~linus@giant.haxx.se) 21.18.47 # derf: yeah, but the downmixing is really unlikely i think 21.19.30 # i guess supporting the uncopuled stereo files shouldn't be too hard 21.30.39 # anyway, disabling most of the unused code, the new static iram stuff, the arm asm, perhaps reducing the globl stack size and building with -Os the codec should fit on the clipv1 21.31.43 # Buschel: your patch saves 9.5MHz on the 64kbps file on h300 21.32.03 # Just out of curiosity, if you encountered a multichannel opus recording and wanted to play it on a device which only supported stereo opus files, what kinds of processing (presumably on the pc) could you do other than decode->downmix->re-encode which has generation loss? 21.32.06 # e.g. I'm guessing it'd be entirely possible to write something that would simply discard all but one channel pair; that'd have limited usefulness, but... 21.33.08 # n1s: more than expected! it saved ~9 Mhz on pp as far as i remember... 21.34.13 # I'm working on global stack measurements. 21.34.48 # So far I'm over 64 kB for fixed and I haven't even gotten out of celt_decode_with_ec() yet. 21.37.12 Quit Torne (Quit: Lost terminal) 21.37.42 Join Torne [0] (~torne@rockbox/developer/Torne) 21.38.12 Quit WalkGood (Quit: ♪ ♫ ♪ ♫ ♪ ♫ ♪) 21.47.53 # Buschel: the comb filter could probably be done a lot better in asm for both cf and arm 21.48.35 # definately. it shouts for load multiple and multiply-adds :) 21.49.47 # but comb_filter only needs few CPU power when the patch is applied. 21.51.03 Join sakax [0] (~sakax@d8D862498.access.telenet.be) 21.51.19 # exactly, if you havent' set up the gerrit stuff i'll try to push more of your patch tomorrow, i'm too tired to trust myself now 21.51.39 Join mikroflops [0] (~yogurt@h-34-239.a238.priv.bahnhof.se) 21.52.47 # yes, that would be perfect. gerrit is still not set up for me. and before i am more into git i should not try to push anything... thanks for testing and pushing 21.54.22 *** Saving seen data "./dancer.seen" 21.55.27 Quit mikroflops_ (Ping timeout: 260 seconds) 21.59.08 Join wodz [0] (~wodz@89-76-32-53.dynamic.chello.pl) 21.59.25 # indeed, more than two thirds of the time both g0 and g1 are 0 when decoding the 64kbps file 21.59.37 Quit liar (Remote host closed the connection) 22.01.13 # where is the comb filter? 22.01.29 Join Bagder_ [0] (~daniel@178.174.211.166) 22.01.34 # celt.c 22.02.50 # could the atrac one you wrote a while back be adapted for that? 22.04.01 # i did not check this, but the remaining cpu time is only ~2 MHz on pp. it will be more effective to focus on the ifft 22.04.41 # oh 22.05.18 # Buschel: i think they'd be rahter interested in this patch for upstream 22.05.44 # well, derf is reading this :) 22.06.09 # Just a word of advice, relying on me to pay attention is a bad plan. 22.06.14 # I have too many things to pay attention to. 22.06.46 # pamaury: Regarding e150 firmware - it looks like SYSCFG.EXE or SYSCFG.SYS is starting code. .SYS seems to be plain binary objcopy of .EXE. There is cache initialization very near the entry point which is one of the earliest things made on MIPSes 22.06.53 # i will point you to the change as soon as it has been comitted 22.06.58 # Great. 22.08.41 # i tested doing three loops one gor g0 == 0, one for g1 == 0 and one for neither 0 and it saved another 0.15MHz or so but makes the code a lot less nice 22.09.19 # that was my thought as well. this way readability is much better 22.10.34 # n1s: did you my comment from yesterday about decode_pulses()? 22.11.21 # yeah, but i forgot about it again 22.11.35 # -> n1s: the profiling results i know show that decode_pulses() uses a reasonable amount of cpu time. what could be interesting on cf is to move the following variables to iram: u[] in decode_pulses(), iy[] in alg_unquant() and maybe also INV_TABLE[] in cwrs.c. on PP this has only few impact (~0.4 MHz faster), but on cf this might scale much better. those arrays are quite small and often used... 22.12.19 # on pp RAM access is cheap, maybe on cf this could be of more interest 22.12.45 # yeah, i think it was derf or someone else in #opus that said the whole thing could be replaced by a small function and a LUT 22.13.04 # so i was kind of hoping that would happen :) 22.13.58 # sounds good, the code now looks quite.... complicated 22.14.21 # If you look at http://people.xiph.org/~tterribe/celt/opusdec-0.006-float.tar.gz you'll find an implementation of that in celtdec.c 22.14.38 # It requires about 5 kB of table data (in celtdata.c). 22.14.52 # cheap 22.14.58 # :) 22.15.03 # You can save some cycles by doubling that. 22.15.15 # (right now it takes advantage of the fact that the table is symmetric) 22.15.35 # i guess it's not just copying some code over? 22.16.52 # celt_decode_pvq() should be basically waht you want. 22.16.57 # *what 22.16.59 # Buschel: anyway, i did thry putting INV_TABLE in iram earlier but didn't see any difference 22.17.17 Quit perrikwp (Ping timeout: 260 seconds) 22.17.34 # n1s: the other arrays look more interesting. they're accessed a lot in the current implementation 22.19.35 # Buschel: we don't define SMALL_FOOTPRINT so the u array is not used 22.20.53 # iy might be interesting though 22.21.05 # n1s: why is u[] not used? 22.21.22 # u[] gets used extensively, regardless of SMALL_FOOTPRINT. 22.21.42 Quit mc2739 (Ping timeout: 260 seconds) 22.21.54 # heh i totally misread the #endif as #else 22.22.38 # wow 22.23.20 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 22.26.19 # wow = you already tested it? 22.26.31 # no, wow = i can't read 22.27.37 # i've no idea what K can be but lets' see if it fits on the real stack 22.28.11 # IIRC, K is at most 128. 22.28.28 # just wanted to write the same ;) 22.28.28 # Earlier we allowed up to 32767, but I think we eventually got rid of that. 22.28.34 # should be good then 22.28.57 # it comes from some bitwise magic i'm too tired to figure out 22.29.30 # rate.h says MAX_PULSES is 128. 22.29.51 # i was stumbling over that bit-magic as well and decided to simply measure it for the test files 22.31.27 Join scorche [0] (~scorche@rockbox/administrator/scorche) 22.33.44 Quit scorche` (Ping timeout: 256 seconds) 22.34.45 # ah, it saved 12.7MHz so yeah wow, i can't believe i just ignored the part after the #endif :) 22.35.08 # cool, that's rather impressive :) 22.36.23 # you moved both arrays (iy and u) to iram? or just one of them? 22.36.34 # jus u 22.36.38 # just 22.36.53 # it doesn't even increase the peak stack usage 22.37.05 # well, then let's see what happens when iy is moved to iram as well :) 22.39.37 # Generally there's one write to each element of iy[] in decode_pulses(). 22.39.47 # Whereas u[] is accessed O(NK) times. 22.40.07 # Both reading and writing, and the constant out front is bigger than 1. 22.41.24 # iy gives another 2.7 22.41.47 # quite reasonable 22.42.24 # how many MHz does the 64kbps file need on h300 now? 22.43.02 # these changes on top of your patch (and my extra change to comb_filter) needs 80.45 now 22.44.49 # maybe even higher bitrates are realtime or close to it now 22.45.19 # still no increase in stack usage 22.46.11 # i would expect 128 kbps to work now, but not 256 kbps still should require too much cpu for realtime 22.50.47 # any idea what N can be? 22.52.42 # no, i tested quick-and-dirty with 1000. maybe derf can give some details 22.52.50 # n1s: 176, I believe. 22.53.09 # is there a define that can be used? 22.53.16 # No. 22.53.53 Join perrikwp [0] (~quassel@cpe-075-177-082-185.triad.res.rr.com) 22.54.25 # so, we should add our good old if-statement to keep the dynamic allocation if the static is too small 22.54.29 # It's the difference between the last two values of eband5ms shifted by maxLM. 22.56.03 Join lebellium_ [0] (~chatzilla@g231189151.adsl.alicedsl.de) 22.56.43 Quit saratoga (Ping timeout: 240 seconds) 22.57.32 Quit lebellium (Ping timeout: 240 seconds) 22.57.42 Nick lebellium_ is now known as lebellium (~chatzilla@g231189151.adsl.alicedsl.de) 22.58.35 Quit perrikwp (Ping timeout: 244 seconds) 22.58.37 # ah yes, i wish there were more comments or some more descriptive var names in this code 23.00.13 Quit wodz (Quit: Leaving) 23.00.21 # i am curios what a profiling would look like after all those changes. 23.01.59 # n1s: I blame all those problems on jmspeex :). 23.03.21 # Buschel: yeah, i'll try to redo them on cf when i find time, might not be before the weekend, have you tried running a profile on arm? 23.06.06 # no, i only commented some functions to get an educated guess. what do i need to do to run a real profiling? just building woith profiling enabled and letting it run? 23.06.26 Join Galois [0] (djao@efnet-math.org) 23.06.32 Quit einhirn (Ping timeout: 240 seconds) 23.19.50 Quit y4n (Quit: We're fucking 3LN!) 23.22.15 Join perrikwp [0] (~quassel@cpe-075-177-082-185.triad.res.rr.com) 23.26.44 # n1s: hmm, i tried to build like desribed here: http://www.rockbox.org/wiki/SourceProfiling. but it does not work for me. can you provide me a small patch as example how to change the code to get profiling enabled for opus? 23.27.00 Quit perrikwp (Ping timeout: 244 seconds) 23.28.19 Quit ser (Ping timeout: 245 seconds) 23.31.27 Join ser [0] (~ser@host1.tldp.ibiblio.org) 23.31.32 # however, need to get some sleep now. see you tomorrow 23.31.36 Quit Buschel (Quit: ChatZilla 0.9.88.2 [Firefox 15.0.1/20120905151427]) 23.32.57 # Buschel: i think i've lost the patch but it's fairly simple, 1) enable profiling when configuring 2) add -finstrument-functions to the codec CFLAGS (either by figuring out how to use the Make var PROFILE_OPTS or just hardcoding for now) 3) add ci->profile_thread at the beginning of codec_run and ci->profstop right before the return in codec_run 23.34.17 # run a regular benchmark with test_codec (will take a lot longer than usual) the profile_reader script has user help that should be all you need 23.34.46 Quit freqmod (Remote host closed the connection) 23.35.14 Quit n1s (Quit: Ex-Chat) 23.39.07 Quit ender` (Quit: With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925) 23.43.30 Quit amayer_ (Quit: going ~/) 23.44.05 Join perrikwp [0] (~quassel@cpe-075-177-082-185.triad.res.rr.com) 23.52.18 Quit Bagder_ (Quit: It is time to say moo) 23.53.46 Part LinusN 23.54.24 *** Saving seen data "./dancer.seen"