--- Log for 01.06.111 Server: pratchett.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 4 days and 7 hours ago 00.03.02 Quit ender` (Quit: The sentence 'On the fish and chips-sign he wanted to have a hyphen between fish and and and and and chips.' would be a lot clearer if there was a quotation mark between 'between' and 'fish' and 'fish' and 'and' and 'and' and 'and' and 'and' and 'and' a) 00.03.27 # jhMikeS: a mutex seems obvious here, the callback comes from another pthread 00.04.25 Quit sasquatch (Ping timeout: 252 seconds) 00.05.20 Quit kevku (Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/) 00.06.39 # I guess for that one. I'm just glad I took another look at the SDL on account of discussing this :) 00.06.59 Quit domonoky (Read error: Connection reset by peer) 00.10.13 # I just hope in this case it doesn't induce a deadlock because pcm.c uses the lockout when calling the low level routines 00.10.51 Join Zambezi_ [0] (Zulu@80.67.9.2) 00.12.53 Quit Zambezi (Ping timeout: 276 seconds) 00.12.55 Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) 00.17.39 Quit guymann_ (Ping timeout: 240 seconds) 00.19.42 Join guymann [0] (~charles@66-159-173-235.adsl.snet.net) 00.24.42 Join guymann_ [0] (~charles@69.0.11.74) 00.25.12 Quit guymann (Ping timeout: 248 seconds) 00.29.49 # ooh, rockbox works 00.31.32 # of course :) 00.32.07 # wow, rockbox widget! 00.34.21 Quit liar (Ping timeout: 258 seconds) 00.34.53 Quit Sundiver (Ping timeout: 260 seconds) 00.39.13 Join T44 [0] (~Topy44@f049040011.adsl.alicedsl.de) 00.39.44 Quit robin0800_ (Quit: Leaving) 00.42.36 Quit Topy (Ping timeout: 255 seconds) 00.43.18 Quit efyx (Remote host closed the connection) 00.46.23 Join Scromple [0] (~Simon@115-64-195-104.tpgi.com.au) 00.46.35 Join robin0800 [0] (~robin0800@149.254.60.160) 00.47.34 Quit T44 (Read error: Connection reset by peer) 00.52.52 Quit robin0800 (Quit: Leaving) 00.53.41 Join robin0800 [0] (~robin0800@149.254.61.232) 00.55.11 Join Topy44 [0] (~Topy44@f049040011.adsl.alicedsl.de) 01.02.57 Quit Rondom (Disconnected by services) 01.03.07 Join niekie_ [0] (~niek@CAcert/Assurer/niekie) 01.03.08 Quit ranmachan (Ping timeout: 248 seconds) 01.03.31 Join Rondom [0] (~rondom@2a01:488:66:1000:b24d:4f2f:0:1) 01.03.38 Quit niekie (Write error: Connection reset by peer) 01.04.25 *** Saving seen data "./dancer.seen" 01.08.15 Join ranmachan [0] (ranma@yumi.tdiedrich.de) 01.19.15 Quit robin0800 (Ping timeout: 252 seconds) 01.24.22 # * kugel isn't sure how to deal with direct audiobuf access in mp3data.c and mpeg.c 01.26.17 Quit piotrekm (Quit: piotrekm) 01.27.45 Quit sideral (Quit: Leaving.) 01.28.05 Quit guymann_ (Ping timeout: 246 seconds) 01.28.25 Join guymann [0] (~charles@66-159-174-62.adsl.snet.net) 01.34.14 Quit mudd1 (Ping timeout: 250 seconds) 01.40.41 # so, vbr calls plugin_get_audio_buffer() and calls into mp3data.c which heavily relies on reading from audiobuf directly 01.40.51 # how to solve that? 01.41.18 # this is most certainly buggy 01.42.21 Quit keyb_gr (Ping timeout: 252 seconds) 01.45.26 Join sideral [0] (~sideral@rockbox/developer/sideral) 01.49.45 Quit Rob2223 (Read error: Connection reset by peer) 01.54.05 Join Rob2222 [0] (~Miranda@p4FFF382C.dip.t-dialin.net) 01.54.05 Quit AlexP (Remote host closed the connection) 01.54.05 Join AlexP [0] (~alex@rockbox/staff/AlexP) 01.54.05 Quit ps-auxw (Ping timeout: 248 seconds) 01.54.05 Quit logbot_ (Ping timeout: 276 seconds) 01.54.05 *** ERROR: (Closing Link: giant.haxx.se (Ping timeout: 276 seconds)) from pratchett.freenode.net 01.54.05 *** Cleanup 01.54.05 *** Cleanup 01.54.05 *** Saving seen data "./dancer.seen" 01.54.05 *** Exit 01.54.07 *** Started Dancer V4.16 01.54.07 *** Connected to irc.freenode.net on port 6667 01.54.07 *** Logfile for #rockbox started 01.54.09 Mode "logbot_ :+i" by logbot_ 01.54.12 *** Server message 501: 'logbot_ :Unknown MODE flag' 01.54.13 Join logbot_ [0] (~rockbox@giant.haxx.se) 01.54.13 Join AlexP [0] (~alex@rockbox/staff/AlexP) 01.54.13 Join Rob2222 [0] (~Miranda@p4FFF382C.dip.t-dialin.net) 01.54.13 Join sideral [0] (~sideral@rockbox/developer/sideral) 01.54.13 Join guymann [0] (~charles@66-159-174-62.adsl.snet.net) 01.54.13 Join ranmachan [0] (ranma@yumi.tdiedrich.de) 01.54.13 Join Rondom [0] (~rondom@2a01:488:66:1000:b24d:4f2f:0:1) 01.54.13 Join niekie_ [0] (~niek@CAcert/Assurer/niekie) 01.54.13 Join Topy44 [0] (~Topy44@f049040011.adsl.alicedsl.de) 01.54.13 Join Scromple [0] (~Simon@115-64-195-104.tpgi.com.au) 01.54.13 Join Zambezi_ [0] (Zulu@80.67.9.2) 01.54.13 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) 01.54.13 Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek) 01.54.13 Join ReimuHakurei [0] (~reimu@74.112.212.15) 01.54.13 Join bluebrother-bot [0] (~bluebroth@g224236183.adsl.alicedsl.de) 01.54.13 Join maraz [0] (maraz@kapsi.fi) 01.54.13 Join krazykit [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) 01.54.13 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 01.54.13 Join Horscht [0] (~Horscht@xbmc/user/horscht) 01.54.13 Join bthomson [0] (~bthomson@c-68-33-5-232.hsd1.va.comcast.net) 01.54.13 Join wtachi [0] (~wtachi@cpe-065-190-012-236.nc.res.rr.com) 01.54.13 Join froggyman [0] (~seth@unaffiliated/froggyman) 01.54.13 Join factor [0] (~factor@r74-195-188-223.msk1cmtc01.mskgok.ok.dh.suddenlink.net) 01.54.13 Join user890104 [0] (~Venci@6bez10.info) 01.54.13 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 01.54.13 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 01.54.13 Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) 01.54.13 Join mikroflops_ [0] (~yogurt@h-34-156.A238.priv.bahnhof.se) 01.54.13 Join jordan`` [0] (gromit@2a01:e34:eebf:c890:21a:4dff:fe63:6966) 01.54.13 Join kugel [0] (~kugel@rockbox/developer/kugel) 01.54.13 Join boghog [0] (~aphax@2001:980:34c7:0:1e6f:65ff:fe86:1e03) 01.54.13 Join Keripo [0] (~Keripo@c-76-28-198-27.hsd1.wa.comcast.net) 01.54.13 Join FoH [0] (~foh@adsl-98-83-124-213.bhm.bellsouth.net) 01.54.13 Join ender| [0] (krneki@foo.eternallybored.org) 01.54.13 Join amiconn [0] (quassel@rockbox/developer/amiconn) 01.54.13 Join pixelma [0] (quassel@rockbox/staff/pixelma) 01.54.13 Join Galois [0] (djao@efnet-math.org) 01.54.13 Join Hadaka [0] (~naked@naked.iki.fi) 01.54.13 Join scorche|sh [0] (~scorche@67.18.187.47) 01.54.13 Join FOAD [0] (~dok@83.161.135.61) 01.54.13 Join knittl [0] (~knittl@unaffiliated/knittl) 01.54.13 Join Elfish [0] (amba@fuplz.co.cc) 01.54.13 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 01.54.13 Join TBCOOL [0] (~tb@c-3c3671d5.09-42-73746f22.cust.bredbandsbolaget.se) 01.54.13 Join logvelc_ [0] (~erik@elbereth.midgard.liu.se) 01.54.13 Join bzed [0] (~bzed@devel.recluse.de) 01.54.13 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 01.54.13 Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) 01.54.13 Join mystica555 [0] (~Mike@71-33-177-238.hlrn.qwest.net) 01.54.13 Join [Saint] [0] (~st.lasciv@124-197-3-117.callplus.net.nz) 01.54.13 Join eGen_ [0] (generat0r@gate.mmdecin.cz) 01.54.13 Join mystica555_ [0] (~mike@71-33-177-238.hlrn.qwest.net) 01.54.13 Join yosafbridge [0] (~yosafbrid@li125-242.members.linode.com) 01.54.13 Join rasher [0] (~rasher@rockbox/developer/rasher) 01.54.13 Join jae [0] (~jae@dedicated.jaerhard.com) 01.54.13 Join CIA-58 [0] (cia@cia.atheme.org) 01.54.13 Join simonlnu [0] (simon@unaffiliated/simonrvn) 01.54.13 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 01.54.13 Join saratoga [0] (9803c6dd@gateway/web/freenode/ip.152.3.198.221) 01.54.13 Join alexbobp [0] (~alex@209.135.10.128) 01.54.13 Join rudi_s [0] (~simon@217.172.186.125) 01.54.13 Join Guinness [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net) 01.54.13 Join Xerion [0] (~xerion@5419A766.cm-5-2c.dynamic.ziggo.nl) 01.54.13 Join crwl [0] (~crwlll@dsl-jklbrasgw1-fe8edf00-29.dhcp.inet.fi) 01.54.13 Join JesusChrysler [0] (~JesusChry@c-69-253-15-232.hsd1.pa.comcast.net) 01.54.13 Join Vimk [0] (~Vimk@fireslash.net) 01.54.13 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 01.54.13 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 01.54.13 Join Staphylo [0] (staphylo@hyperion.epimeros.org) 01.54.13 Join powell14ski_ [0] (~powell14s@c-24-9-5-214.hsd1.co.comcast.net) 01.54.13 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) 01.54.13 Join preglow [0] (thomj@rockbox/developer/preglow) 01.54.13 Join z35 [0] (~z35@ool-18bdad71.dyn.optonline.net) 01.54.13 Join desowin [0] (~desowin@atheme/member/desowin) 01.54.13 Join jepler [0] (~jepler@emc/developer/pdpc.professional.jepler) 01.54.13 Join Utchy [0] (~Utchy@rps6752.ovh.net) 01.54.13 Join pikytcus [0] (~bigd@failbox.co.cc) 01.54.13 Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) 01.54.13 Join merbanan [0] (~banan@c-94-255-222-82.cust.bredband2.com) 01.54.13 Join avacore [0] (~avacore@90.184.100.129) 01.54.13 Join soap [0] (~soap@rockbox/staff/soap) 01.54.13 Join iq [0] (~iq@unaffiliated/iq) 01.54.13 Join Torne [0] (~torne@rockbox/developer/Torne) 01.54.13 Join Buganini [0] (~buganini@2001:288:c237:0:dead:beef:cafe:babe) 01.54.13 Join n17ikh [0] (~n17ikh@c-68-59-25-51.hsd1.sc.comcast.net) 01.54.13 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 01.54.13 Join scorche [0] (~scorche@rockbox/administrator/scorche) 01.54.13 Join Bagder [0] (~daniel@rockbox/developer/bagder) 01.54.13 Join martii [0] (martii@sokrates.mimuw.edu.pl) 01.54.13 Join zu [0] (~zu@ks355000.kimsufi.com) 01.54.13 Join GodEater [0] (~bibble@rockbox/staff/GodEater) 01.54.13 Join jfc [0] (~john@static-72-73-80-12.ptldme.east.myfairpoint.net) 01.54.13 Join aevin [0] (eivindsy@unaffiliated/aevin) 01.54.13 Join pjm0616 [0] (~user@110.8.235.86) 01.54.13 Join Espreon [0] (~espreon@wesnoth/developer/espreon) 01.54.13 Join [fred] [0] (fred@ircop.efnet.at) 01.54.13 Join Slasheri [0] (miipekk@rockbox/developer/Slasheri) 01.54.13 Join simabeis [0] (~simabeis@lobmenschen.de) 01.54.13 Join dionoea [0] (~dionoea@videolan/developer/dionoea) 01.54.13 Join ThomasAH [0] (~thomas@aktaia.intevation.org) 01.54.13 Join parafin [0] (parafin@paraf.in) 01.54.13 Join tguinot [0] (~tguinot@ks22840.kimsufi.com) 01.54.13 Join YPSY [0] (~ypsy@geekpadawan.de) 01.54.13 Join Barahir [0] (~jonathan@fb08schindler24.anorg.chemie.uni-giessen.de) 01.54.13 Join kkit|sh [0] (~kkit@li135-248.members.linode.com) 01.54.13 Join feisar-_ [0] (jljhook@ihq.in) 01.54.13 Join ack` [0] (~ack@mingbai.org) 01.54.13 Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) 01.54.13 Join ved [0] (ved@ddsbox.co.cc) 01.54.13 Join @ChanServ [0] (ChanServ@services.) 01.54.46 Quit FOAD (Ping timeout: 260 seconds) 01.55.43 Join FOAD [0] (~dok@83.161.135.61) 01.55.51 Quit gevaerts (Ping timeout: 244 seconds) 01.56.31 Quit krazykit (Ping timeout: 260 seconds) 01.56.44 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 01.56.53 Join krazykit [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) 01.59.22 Quit Scromple (Ping timeout: 240 seconds) 02.00.10 Join guymann_ [0] (~charles@66-159-173-149.adsl.snet.net) 02.02.06 Quit guymann (Ping timeout: 276 seconds) 02.02.53 Quit ack` (Ping timeout: 258 seconds) 02.03.41 Join ack` [0] (~ack@mingbai.org) 02.06.22 Join ps-auxw [0] (~arneb@p4FF7FD32.dip.t-dialin.net) 02.06.32 Quit sideral (Ping timeout: 248 seconds) 02.12.54 Quit ps-auxw (Quit: leaving) 02.15.34 Nick guymann_ is now known as guymann (~charles@66-159-173-149.adsl.snet.net) 02.18.23 Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) 02.19.27 # https://developer.mozilla.org/en-US/demos/detail/doom-on-the-web/ chrome is up to 700MB ram usage on the tab running doom 02.19.31 # and it hasnt even started yet! 02.19.47 # haha, chrome killed it 02.22.09 # kugel: my somewhat-ignorant attempt that I have no idea if it will really work without deadlock or even compile: http://pastebin.com/VCLut6eK (can remove pcm_play_dma_started_callback calls to test with current SVN) 02.22.55 # /join #rockbox-chrome 02.23.29 # woops, wrongchannel :) 02.29.01 # jhMikeS: anything changed other than the mutex thing? 02.29.09 # no 02.29.43 # oh. just removing that call you said I could 02.30.52 # diffs are more appreciated :) 02.31.16 # if you wish :) 02.33.13 # http://pastebin.com/9qDZ91bp 02.33.51 # late :P 02.36.02 # jhMikeS: "if (--audio_locked == 0); 02.36.02 # unlock_audio();"!! 02.38.41 # jhMikeS: compiled fine after few fixes, music plays but I'll test the next few days 02.38.59 # perhaps it magically fixes all issues :) 02.40.36 # fwiw, here's the fixed patch http://pastebin.com/eNE0rJt5 02.41.06 # jhMikeS: why the reference counting? recursive mutexes are fine aren't they? 02.41.58 # gah, this one http://pastebin.com/L8kx8jQL 02.42.44 # oops, semicolon fail 02.44.45 # one thing I didn't get easy info on was if you need to call pthread_mutex_destroy for a static mutex :\\ 02.56.18 # jhMikeS: I guess so, but you can also initialize it at runtime to make sure it's correct 02.56.59 # I just read some doc that said it's only for dynamic ones 02.57.48 # I wanted the fast, non-reentrant variety. about the only thing else I'd change would be in the realm of priority inheritance 02.58.34 Join heyappleknife [0] (~62f513ee@giant.haxx.se) 02.59.35 # the first chunk in http://www.rockbox.org/tracker/task/11925?getfile=23312 has an enum using SCREEN_* prefix... any ideas what a better prefix would be? 03.00.01 # it is to list the actual screen the user is in... 03.00.10 # maybe I go the android-type thing and use ACTIVITY_? 03.03.29 Quit heyappleknife (Client Quit) 03.07.44 Quit bzed (Remote host closed the connection) 03.07.52 Join bzed [0] (~bzed@devel.recluse.de) 03.09.09 # * jhMikeS now finds different doc that suggests a static mutex should be destroy ... *shakes head* 03.18.32 Join ReimuHakurei_ [0] (~reimu@74.112.212.15) 03.18.32 Quit ReimuHakurei (Read error: Connection reset by peer) 03.37.52 # <[Saint]> Oh! 03.38.03 # * [Saint] yay!'s at r29940 03.40.56 Quit t0rc (Quit: WeeChat 0.3.5) 03.41.38 # [Saint]: assuming you're going to do new builds for the above commit, can you test FS#11925 please? 03.41.39 # http://www.rockbox.org/tracker/task/11925 3Add a proper "current screen" system (patches, new) 03.42.07 # <[Saint]> Haha...assuming ;) 03.42.09 # except looking at the order on CheckWPS and the patch, the %cs tag order changes so you might want to reorder it to be correct 03.42.15 # you're not? 03.42.29 # <[Saint]> I've had that in my tree since it went up. 03.42.51 # <[Saint]> 'twas just a general "yay, it's in svn now". 03.43.07 # bah, just hoped you like having svn+patches, not oldsvn_patches :) 03.43.11 # <[Saint]> I can test your patch at some stage today, though ;) 03.43.18 # yippee :) 03.43.45 # I'm hoping to commit it tomorow/tonight (depending on testing and time) 03.45.03 # <[Saint]> Ok, yeah...looking at it, I might carve it up a bit and add it back to the tracker when I'm finished with testing. Just to make it resemble svn ordering currently with anything new tacked onto the end. 03.45.32 # it shouldnt need too much fiddling 03.45.39 # just the order in misc.h 03.45.48 # <[Saint]> that way it shouldn't break any current themes either, unless I'm missing something. 03.46.25 # <[Saint]> Hmmm, no actually, other themes that use %cs will have screwed up ordering no matter how I order it, or outright fail no? 03.46.39 Quit bieber (Ping timeout: 255 seconds) 03.47.08 Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) 03.47.18 # <[Saint]> if the expected number of args isn't there it will fail to parse, if I understand it right anyway. 03.47.25 # no 03.47.40 # its a conditional..... %?cs is fine if it has 15 options 03.48.01 # i'd like to not break themes, thoguuh I dont really care too much if we need to 03.48.07 # this system is far better than svn 03.48.41 # <[Saint]> Oh, ok. that's cool then. If that's the case as long as the ordering is the same then new args tacked onto the end it should "just work" for old and new themes. 03.53.13 Join Sundiver [0] (~angel@174.124.76.11) 03.54.08 *** Saving seen data "./dancer.seen" 04.00.00 Join Scromple [0] (~Simon@115-64-195-104.tpgi.com.au) 04.06.46 Join linuxguy3 [0] (~timj@216-80-116-174.c3-0.lem-ubr1.chi-lem.il.cable.rcn.com) 04.08.17 # "processor not implemented" when building sim? how the... 04.17.11 Quit mc2739 (Quit: leaving) 04.21.34 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 04.34.21 Quit TheSeven (Disconnected by services) 04.34.30 Join [7] [0] (~TheSeven@rockbox/developer/TheSeven) 04.34.45 Quit pixelma (Disconnected by services) 04.34.46 Quit amiconn (Disconnected by services) 04.34.46 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.34.47 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.34.50 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.35.04 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.35.09 Join quem [0] (~foo@c83-254-247-9.bredband.comhem.se) 04.36.48 # my 1st-gen ipod nano's flash seems to be reaching its end of life... any decent contemporary players that run rockbox? 04.51.41 # <[Saint]> "contemporary"? 04.52.43 # <[Saint]> It depends on too many factors to jsut say "get "...what are you looking for? Flash? Hdd? is expandable memory important? etc. 04.55.07 Join JoshuaChang [0] (~JoshuaCha@180.175.6.233) 04.57.10 # <[Saint]> If you're happy with a 1st Gen Nano...I'd highly advise getting another. The SQ is *awesome* in the Nano1G and aside from my Android handset, it's my preferred player. 04.57.11 Join kugel_ [0] (~kugel@rockbox/developer/kugel) 05.00.40 Quit kugel (Ping timeout: 276 seconds) 05.12.00 # [Saint]: flash, 4gb. about it. 05.12.41 # hmm... 05.14.55 Join Rob2223 [0] (~Miranda@p4FFF21B2.dip.t-dialin.net) 05.18.25 Quit Rob2222 (Ping timeout: 246 seconds) 05.30.09 Quit Horscht (Quit: Verlassend) 05.48.25 Join Mikeb0ok [0] (~mike@71-33-177-238.hlrn.qwest.net) 05.48.31 Join MikeH__ [0] (~Mike@71-33-177-238.hlrn.qwest.net) 05.48.31 *** Alert Mode level 1 05.48.31 DBUG Enqueued KICK mystica555 05.48.31 DBUG Enqueued KICK mystica555_ 05.48.31 *** Alert Mode level 2 05.48.31 DBUG Enqueued KICK Mikeb0ok 05.48.31 DBUG Enqueued KICK MikeH__ 05.48.31 *** Alert Mode level 3 05.52.09 Quit mystica555 (Ping timeout: 258 seconds) 05.52.12 Quit mystica555_ (Ping timeout: 260 seconds) 05.54.10 *** Saving seen data "./dancer.seen" 05.58.32 *** Alert Mode OFF 06.01.02 Quit ReimuHakurei_ (Read error: Connection reset by peer) 06.01.37 Join ReimuHakurei [0] (~reimu@74.112.212.15) 06.29.25 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 06.35.51 Quit wtachi (Quit: &) 06.41.03 Nick MikeH__ is now known as mystica555 (~Mike@71-33-177-238.hlrn.qwest.net) 06.41.03 DBUG Enqueued KICK mystica555 06.47.55 Quit bzed (Ping timeout: 276 seconds) 06.49.26 Join bzed [0] (~bzed@devel.recluse.de) 06.53.54 Ctcp Ignored 5 channel CTCP requests in 52 minutes and 32 seconds at the last flood 06.53.54 # * JdGordon prods [Saint] with FS#11925 - updated so you dont need to hack the order 06.53.55 # http://www.rockbox.org/tracker/task/11925 3Add a proper "current screen" system (patches, new) 07.06.00 Nick Mikeb0ok is now known as mystica555_ (~mike@71-33-177-238.hlrn.qwest.net) 07.06.00 DBUG Enqueued KICK mystica555_ 07.11.21 Join sideral [0] (~sideral@rockbox/developer/sideral) 07.18.42 Quit Zarggg (Quit: Zarggg) 07.24.02 Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) 07.28.09 # wtachi: come back online! :D 07.28.46 Join Buschel [0] (~chatzilla@p54B675C2.dip.t-dialin.net) 07.39.25 Join esperegu [0] (~quassel@145.116.15.244) 07.54.12 *** Saving seen data "./dancer.seen" 08.01.13 Join sasquatch [0] (~username@46.115.0.246) 08.03.14 Join mudd1 [0] (~cmertes@ip-78-94-202-227.unitymediagroup.de) 08.10.22 Join pamaury [0] (~quassel@128.247.66.86.rev.sfr.net) 08.10.22 Quit pamaury (Changing host) 08.10.22 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 08.12.27 Quit Buschel (Quit: ChatZilla 0.9.86.1 [Firefox 3.6.17/20110420140830]) 08.13.10 Quit user890104 (Ping timeout: 240 seconds) 08.16.06 Join user890104 [0] (~Venci@6bez10.info) 08.17.37 Quit sideral (Quit: Leaving.) 08.21.39 Quit zu (Read error: Operation timed out) 08.21.48 Join kZard|2 [0] (~kZard@146.232.190.241) 08.21.56 Join zu [0] (~zu@ks355000.kimsufi.com) 08.23.24 # Is rockbox being developed for 6th gen iPods? 08.23.43 # <[Saint]> If you mean the Classic, yes. 08.23.47 Join Jerom1 [0] (~jerome@95.171.142.86) 08.23.51 # yes, 08.24.07 # ok cool, is it at all usable? 08.24.38 # <[Saint]> Yes, but your definition of usable and mine may differ. 08.24.50 # hehehe 08.25.09 # <[Saint]> it's definitely far from "stable", and right now builds are not released via rockbox.org 08.25.23 # true. I used RockBox on my 4th gen ipod photo earlier this year 08.25.42 # it kept crashing 08.25.54 # but, I think it was because of a faulty hard drive 08.26.11 # <[Saint]> Well, that's highly unusual...that device has been stable for quite some time. 08.26.27 # <[Saint]> I own two personally and run them without problem. 08.26.31 # yea. was quite nice while it worked though 08.27.04 # <[Saint]> If you'd like to know more about the Class Rockbox port, the best place to help you is the #freemyipod project. 08.27.04 # I thought that the 5th gen and 6th gen ipods were much more closely related 08.28.02 # o? 08.28.03 # <[Saint]> No, there's pretty much nothing in common between the 5th and 6th gen iPod 08.28.03 # wow seriously? 08.28.03 # <[Saint]> apart from the fact that they are both iPods, yes. 08.28.03 # excuse my ignorance, but feature wise they seem basically the same 08.28.07 # wow, thats quite interesting 08.29.42 # <[Saint]> Right now, to run Rockbox on the Classic you need an application called emCORE, this is developed seperately from ROckbox by the guys at freemyipod.org 08.30.12 # <[Saint]> installation will completely wipe the device, and there is no dual-boot. 08.30.56 # ok 08.31.01 # meh 08.31.08 # I should've bought a 5th gen then 08.31.28 # I just want to be able to carry all my music with me. 08.31.41 Join B4gder [0] (~daniel@www.haxx.se) 08.31.41 Quit B4gder (Changing host) 08.31.41 Join B4gder [0] (~daniel@rockbox/developer/bagder) 08.31.47 # (with gapless playback of course) 08.34.04 Quit Zambezi_ (Changing host) 08.34.04 Join Zambezi_ [0] (Zulu@unaffiliated/zambezi) 08.34.18 Nick Zambezi_ is now known as Zambezi (Zulu@unaffiliated/zambezi) 08.39.28 Join LinusN [0] (~linus@giant.haxx.se) 08.41.55 Quit Jerom1 (Quit: Leaving.) 08.44.06 Join ender` [0] (krneki@foo.eternallybored.org) 08.45.16 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 08.51.58 Join kevku [0] (~kevku@2001:470:28:773:babe:feed:dead:bee) 08.54.23 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 08.54.31 Quit bertrik (Changing host) 08.54.31 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 08.56.07 Join n1s [0] (~quassel@rockbox/developer/n1s) 09.07.14 Quit ender` (Quit: It's is not, it isn't ain't, and it's it's, not its, if you mean it is. If you don't, it's its. Then too, it's hers. It isn't her's. It isn't our's either. It's ours, and likewise yours and theirs.) 09.12.20 Join sideral [0] (~sideral@213.165.85.248) 09.12.20 Quit sideral (Changing host) 09.12.20 Join sideral [0] (~sideral@rockbox/developer/sideral) 09.15.10 Join keyb_gr [0] (~chatzilla@p5080EBC8.dip.t-dialin.net) 09.29.53 Quit Scromple (Read error: Connection reset by peer) 09.31.34 Quit bertrik (Ping timeout: 260 seconds) 09.40.51 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 09.42.01 # sideral: you should add yourself to IrcNicks 09.44.48 # n1s: That would allow mapping my IRC name to my real name way too easily for my tastes. I'd like to be know as "sideral" around here :) 09.47.58 Quit mudd1 (Ping timeout: 276 seconds) 09.49.24 # n1s: Do you think the FS#12065 fix is ready for commit? I'd like to get it in, but I'll be on vacation for a few days starting tomorrow 09.49.25 # http://www.rockbox.org/tracker/task/12065 3Database RAM cache doesn't work with Chinese-simp (bugs, unconfirmed) 09.51.47 # sideral: it fixed the crash for me and looks ok but i don't know the database code well enough to know :) 09.52.32 # in other words, if you think it's fine i think you should commit 09.53.35 # n1s: OK, will do. You can do an emergency back-out if things start crashing when I'm off :) 09.54.00 # sure 09.54.15 *** Saving seen data "./dancer.seen" 09.54.31 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 09.58.04 # AlexP: does it still make sense to commit fixes to the 3.8 stable branch 09.58.06 # ? 10.00.39 # New commit by 03sideral (r29941): FS#12065 - Fix two regressions introduced with r26192 (FS#10976 / ... 10.00.41 # http://www.rockbox.org/tracker/task/12065 3Database RAM cache doesn't work with Chinese-simp (bugs, unconfirmed) 10.00.41 # http://www.rockbox.org/tracker/task/10976 3String isn't in language files (bugs, closed) 10.05.39 # r29941 build result: 123 errors, 0 warnings (sideral committed) 10.07.04 # Looks like the storebror-daniel build client has a serious issue. 10.07.59 # weird 10.08.21 # the path to the crtbeginS.o file includes a susoicious "i486" 10.08.38 # suspicious 10.08.56 # well, it's a sim build 10.09.22 # seems to be an x86 32-bit vs 64-bit issue 10.09.34 # I don't think so, this is a pure 32bit box 10.09.50 # ah, it is 32 bit 10.10.18 # "crtbeginS.o: file class ELFCLASS64" 10.10.34 # ah indeed 10.10.43 # why would ld find that? 10.10.59 # my compiler and ld work fine for other stuff 10.11.26 # wrong compiler package? that path shouldn't have 64-bit object files 10.11.27 # gcc (Debian 4.6.0-10) 4.6.1 20110526 (prerelease) / GNU ld (GNU Binutils for Debian) 2.21.51.20110523 10.11.34 # it is not the wrong compiler 10.12.07 # check which package the file belongs to 10.12.50 # none... 10.12.56 # strange 10.13.04 # gcc-4.6: /usr/lib/gcc/i486-linux-gnu/4.6/crtbeginS.o 10.13.10 # but I have the /usr/lib/gcc/i486-linux-gnu/4.6.1/crtbeginS.o 10.13.20 # perhaps a left-over from an earlier install? 10.13.28 # nah, symlink 10.13.31 # it is gcc 4.6 10.13.39 # /usr/lib/gcc/i486-linux-gnu/4.6.1 -> 4.6 10.13.48 # ah 10.14.52 # what does "file" say about the file 10.15.26 # /usr/lib/gcc/i486-linux-gnu/4.6.1/crtbeginS.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped 10.16.04 # either file or binutils is lying :) 10.16.49 # and why does it only say that error on that specific ld? 10.17.31 # LD vorbis.codec 10.17.33 # /usr/bin/ld: /home/daniel/src/rockbox/buildmeown-sansa/apps/codecs/libtlsf.a(tlsf.o)(.text.ls_bit+0x5b): reloc against `.rodata': error 4 10.17.41 Quit JoshuaChang (Quit: ChatZilla 0.9.86.1 [Firefox 4.0.2pre/20110429182132]) 10.18.01 # something is not fine 10.19.14 # The last batch of errors looks scary: " /usr/bin/ld: unknown operator '(' in complex symbol" 10.27.21 # and all of those errors at once makes me really wondering what the heck is going on 10.27.54 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 10.27.54 # * B4gder shuts down the build client 10.28.37 # trying a sim build on my debian netbook (also 32 bit) i get the ELFCLASS error too 10.29.24 # what ld/binutils version? 10.29.40 # same as yours, current in sid 10.29.46 # ok 10.35.10 # gcc 4.5 gives the same error 10.37.01 # so more likely caused by binutils i'd guess 10.37.10 # yes, that'd be my guess too 10.43.27 Quit [Saint] (Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.) 10.45.41 Join [Saint] [0] (~st.lasciv@124-197-3-117.callplus.net.nz) 10.51.57 # * [Saint] wonders what an "xPod" is... 11.04.21 # building with -fPIC -fvisibility=hidden like we do on 64 bit works fine, i wonder if there's a downside to it 11.06.30 # <[Saint]> every time you use it, you kill a kitten. 11.08.42 # so it seems that for some reason gcc is screwing up in non pic mode and producing elf64 files ?! 11.09.04 # or well binutils is screing up, not gcc 11.29.29 Quit B4gder (Quit: Konversation terminated!) 11.34.47 Quit pamaury (Remote host closed the connection) 11.51.07 Quit keyb_gr (Remote host closed the connection) 11.54.18 *** Saving seen data "./dancer.seen" 12.00.42 Quit sideral (Quit: Leaving.) 12.01.43 Nick kugel_ is now known as kugel (~kugel@rockbox/developer/kugel) 12.07.00 # <[7]> [Saint]: did you get around to trying the nano2g bootloaders? 12.08.39 # amiconn: how does HWCODEC use audiobuf? especially with regards to voice 12.13.59 Join timccc [0] (~aoeu@112.166.15.141) 12.15.01 # mpeg.c and the freaking #ifdef-hell in talk.c mightily confuses me 12.28.06 Part LinusN 12.28.07 Join LinusN [0] (~linus@giant.haxx.se) 12.28.28 # New commit by 03nls (r29942): FS#12140 by Sean Bartell, Make various codec stuff static. 12.28.29 # http://www.rockbox.org/tracker/task/12140 3Make various codec stuff static (patches, unconfirmed) 12.32.26 Join swilde [0] (~wilde@aktaia.intevation.org) 12.32.36 # r29942 build result: All green 12.36.25 Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com) 12.49.09 # New commit by 03nls (r29943): Add Sean Bartell to CREDITS. 12.50.47 # we're getting pretty close to 600 contributors 12.53.01 # r29943 build result: All green 13.01.03 # n1s: -fPIC makes code bigger and slower... it shouldn't be needed to make things work if they aren't in shared libraries.. 13.05.49 # hmm, plugins are compiled as shared 13.06.46 # and gcc docs say that you should use -fpic or -fPIC when using -shared "For predictable results" 13.07.46 # so maybe only plugins and codecs need it? 13.11.52 # * n1s tries 13.12.44 # well, codecs predictably crash if you run multiple rockbox instances :) 13.13.12 # is this for the simulator? 13.14.22 Join sideral [0] (~sideral@213.165.85.248) 13.14.32 Quit sideral (Changing host) 13.14.32 Join sideral [0] (~sideral@rockbox/developer/sideral) 13.14.45 # Torne: yeah 13.15.33 # new binutils in debian won't link the 32 bit sims anymore 13.15.49 # then yes, the bits that are build shared should be -fPIC 13.16.04 # i wasn't entirely sure what the effect of your diff was 13.16.41 # it adds -fPIC and -fvisibility=hidden to everything, which made it work 13.17.05 Quit sideral (Remote host closed the connection) 13.17.23 # just adding those flags to things built with -shared doesnt work or i did something wrong 13.17.27 # what diff? 13.17.40 Join sideral [0] (~sideral@213.165.85.248) 13.17.40 Quit sideral (Changing host) 13.17.40 Join sideral [0] (~sideral@rockbox/developer/sideral) 13.17.41 # ahh :) 13.18.13 # n1s: you need to add it to the compilation of all the source files for things which will eventually go into shared libraries 13.18.20 # n1s: not just to the actual linker invocation with -shared 13.18.32 # but you shouldn' tneed to have it for compilation of files which won't go into shared libraries. 13.18.56 # Torne: right, didn't look how SHARED_FLAG is used 13.19.50 # hidden visibility is.. interesting 13.19.53 # not sure why that would be required. 13.20.10 # that's required for 64 bit, i just copied both of them 13.20.12 # but it shouldn't hurt as long as any symbols we call from the so's are exported. 13.20.19 # it shouldn't be required on 64-bit either 13.20.36 # without it, we get some very interesting crashes 13.20.38 # normal unix shared libraries don't default symbols to hidden. 13.21.11 # then i suppose we do something wrong 13.21.12 # do codecs have functions whose names shadow things in libc/other libraries that the sim is linked to? 13.21.19 # because that would explain it :) 13.21.21 # our codecs aren't normal shared libraries :) 13.21.42 # well no. 13.21.48 # It's not bad or anything 13.21.59 # If it links and works with it then we must be exporting any symbols we care about :) 13.22.05 # it's just a little odd 13.22.19 # i added it years ago and it's worked fine since then 13.22.47 # 64 bit sims build everything with -fPIC too 13.22.53 # it's possible they shadow other symbols, lots of imported code :) 13.23.06 # well again, PIC doesn't break anything 13.23.10 # but it makes the code slower and bigger. 13.23.19 # for the sim we may not care :) 13.23.23 # i'm unsure if i care enough about slow and big sims to hack around it 13.23.26 # but you wouldn't want to introduce it anywhere else 13.25.11 # the place i added it is in simcc() that should only be used for sims, but i assume it is also used for RaaA on linux 13.26.22 # probably didn'T have SHARED_FLAGS back then 13.27.01 # SHARED_FLAG doesn't help as it's only for linking 13.27.16 # well if we also build codecs as shared libs there then you'd ahve to do sometime. 13.27.20 Quit sideral (Remote host closed the connection) 13.27.23 # the alternative to PIC ther would be "lol magic" 13.27.32 # er, have to do something 13.27.38 # PIC is probably easier :) 13.28.14 # yes but it's more effort to make only the things that need PIC use it than just make everything use it :) 13.28.21 Join sideral [0] (~sideral@rockbox/developer/sideral) 13.30.19 # either hacking codecs.make and plugins.make slightly or add more flags to the generated Makefile that they use 13.31.06 # so SHARED_FLAG -> SHARED_LDFLAG and adding SHARED_CFLAGS 13.34.45 Join nirv [0] (~ohboy@c-75-72-136-46.hsd1.mn.comcast.net) 13.37.35 Quit sideral (Remote host closed the connection) 13.38.19 Join sideral [0] (~sideral@213.165.85.248) 13.38.19 Quit sideral (Changing host) 13.38.19 Join sideral [0] (~sideral@rockbox/developer/sideral) 13.41.54 Join esperegu_ [0] (~quassel@145.116.10.163) 13.42.40 Quit esperegu (Ping timeout: 240 seconds) 13.43.01 Part sideral 13.43.08 Join sideral [0] (~sideral@rockbox/developer/sideral) 13.45.41 # it almost worked! 13.46.07 # only, doom decided to link a core file which made it break 13.46.49 # remove doom! 13.46.57 # (that was asking for that ;-) 13.47.19 # the main sim and codecs seem fine though 13.48.52 # this is an amazing hack though, why include a file from the core in a plugin instead of just putting the thing in the plugin or just adding it to the core and using the api? 13.52.15 # Stuff that's needed *only* in plugins should not bloat the core 13.52.48 # but why not put it in the pluginlib or the plugins themselves? 13.54.19 *** Saving seen data "./dancer.seen" 13.56.22 # Is this about sscanf? 13.56.27 # yes 13.57.28 # Iirc the idea was that it might be used in the core eventually, hence it has been put there in order to avoid duplication 13.57.59 # * amiconn thinks this should probably be changed 14.00.07 # yeah, i think it should go to the pluginlib 14.01.30 Quit robin0800 (Quit: Leaving) 14.01.55 # anyway, except for that the patch adding the flags only to codecs and plugins works 14.03.23 Join stoffel [0] (~quassel@p57B4B0A6.dip.t-dialin.net) 14.06.17 # building wothout -fvisibility=hidden seems to make no difference, i can't remember how it used to crash though 14.18.00 # IMO the whole C library should be build as an extra library which core, plugins and codecs link independantly 14.18.29 # the wrappers in the plugin- and codec-api regularly create problems 14.24.16 # maybe 14.24.44 # Although on non-app builds, I'd say that libc might be implemented using such wrappers 14.24.51 # it's especially strange for sim and app builds, where the actual functions are in the hosts C library anyway (so either you get them directly or through the apis) 14.28.23 # gevaerts: that's even more call overhead, and it doesn't solve the probles the wrapper usually create; it's mostly the headers which clash with the api declaration 14.28.56 # we basically use reserved names there which is calling from problems 14.28.58 # Well, non-app and non-sim 14.29.53 # kugel: I doubt we can afford the code duplication on lowmem, so we have to keep some sort of call-to-core there 14.30.20 # Maybe I'm misunderstanding what you mean though 14.30.25 # gevaerts: the apis would get smaller, giving more mem for the core 14.31.08 # wouldn't we need a dynamic linker to do that? 14.31.18 # and remember, only the .o files which are actually used are linked it; many plugins would only link few (if any) files so the size increase should be usually negible 14.32.18 # (the individual .o files are usually tiny in our libc) 14.33.20 # not to mention that linking independantly (and therefore including the appropriate headers instead of just plugin.h) is making things for porting stuff to rockbox 14.34.43 # code size of plugins was never a problem (did anyone even look at it for plugins?), not even on lowmem 14.35.03 # * gevaerts disagrees with that 14.35.14 # total memory usage for plugins is important 14.36.16 # Well, rb->open() and friends have real problems for hosted builds, moving to (fully external libc-provided) open() would help a lot there. However, for non-hosted traditional builds there's no reason why open() couldn't call rb->open internally 14.36.45 # Well, open() is a bad example, since it *has* to call rb->open() somehow 14.36.56 # Things like strlcpy() are probably better examples 14.37.06 # And that internal call can be inlined 14.42.34 # * kugel suspects the code size increase wouldn't be noticeable on most plugins, e.g. those which only call 1 or 2 string functions 14.43.23 # sure but it still could make some plugin too big to fit on some target 14.43.29 # * gevaerts knows that some plugins for sh stop building due to lack of space when one merely switches compilers 14.46.00 # it might also be possbile that code size actually decreases, since an api call needs a lot more instructions than a direct call 14.47.48 # so for a sufficient number of calls linking directly might be smaller (and of course faster) 14.55.48 # gevaerts: that would be 2 separate wrapper libraries (oen for codecs, one for plugins?) 14.58.37 # the extra cost of an api call is basically loading a pointer from an offset of the api pointer 15.08.14 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 15.16.46 Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com) 15.25.10 Quit n1s (Remote host closed the connection) 15.26.55 Join kZard [0] (~kZard@146.232.190.241) 15.29.09 Quit kZard|2 (Ping timeout: 240 seconds) 15.36.12 # [Saint]: ping? 15.52.11 Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) 15.52.16 Join n1s [0] (~quassel@rockbox/developer/n1s) 15.54.20 *** Saving seen data "./dancer.seen" 15.56.26 # anyone want to comment on FS#11925 before i commit it? 15.56.27 # http://www.rockbox.org/tracker/task/11925 3Add a proper "current screen" system (patches, new) 15.56.43 Quit bzed (Remote host closed the connection) 15.57.11 Join bzed [0] (~bzed@devel.recluse.de) 16.00.05 Quit piotrekm (Ping timeout: 244 seconds) 16.04.13 Join sideral1 [0] (~sideral@213.165.85.248) 16.04.13 Quit sideral (Disconnected by services) 16.04.14 Nick sideral1 is now known as sideral (~sideral@213.165.85.248) 16.04.14 Quit sideral (Changing host) 16.04.14 Join sideral [0] (~sideral@rockbox/developer/sideral) 16.06.47 Join piotrekm [0] (~piotrek@aeav40.neoplus.adsl.tpnet.pl) 16.06.47 Quit piotrekm (Changing host) 16.06.47 Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) 16.07.28 Join panni__ [0] (~hannes@ip-178-202-7-195.unitymediagroup.de) 16.07.32 Quit panni__ (Remote host closed the connection) 16.07.51 Quit sideral (Remote host closed the connection) 16.08.04 Join sideral [0] (~sideral@213.165.85.248) 16.08.04 Quit sideral (Changing host) 16.08.04 Join sideral [0] (~sideral@rockbox/developer/sideral) 16.11.34 Quit mystica555 (Read error: Operation timed out) 16.11.41 Part LinusN 16.12.44 Join mystica555 [0] (~Mike@71-33-177-238.hlrn.qwest.net) 16.18.06 Quit sideral (Remote host closed the connection) 16.18.32 Join sideral [0] (~sideral@213.165.85.248) 16.18.32 Quit sideral (Changing host) 16.18.32 Join sideral [0] (~sideral@rockbox/developer/sideral) 16.18.58 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 16.28.21 Quit sideral (Remote host closed the connection) 16.28.46 Join sideral [0] (~sideral@213.165.85.248) 16.28.46 Quit sideral (Changing host) 16.28.46 Join sideral [0] (~sideral@rockbox/developer/sideral) 16.28.50 Quit stoffel (Read error: Operation timed out) 16.31.34 # does the manual distinguish between the normal menu's and the toplevel menu? 16.37.29 # pixelma: bluebrother: I need to fix the %cs listing in the manual, it is now 15 options, is there a nice simple way to make a list for it in TeX? 16.37.51 # or should i just fix it and let someone else make it look goood? 16.41.09 Quit bluebrother (Disconnected by services) 16.41.10 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 16.41.50 # New commit by 03jdgordon (r29944): FS#11925 - Add a proper system to keep track of the current screen/activity to make %cs far more useful 16.43.49 Quit bluebrother-bot (Ping timeout: 255 seconds) 16.46.06 # r29944 build result: All green 16.47.58 Join sideral1 [0] (~sideral@213.165.85.248) 16.47.58 Quit sideral (Disconnected by services) 16.47.58 Quit sideral1 (Changing host) 16.47.58 Join sideral1 [0] (~sideral@rockbox/developer/sideral) 16.48.37 Quit sideral1 (Remote host closed the connection) 16.48.54 Join sideral [0] (~sideral@213.165.85.248) 16.48.54 Quit sideral (Changing host) 16.48.54 Join sideral [0] (~sideral@rockbox/developer/sideral) 16.50.28 Join wtachi [0] (~wtachi@cpe-065-190-012-236.nc.res.rr.com) 16.58.52 Quit sideral (Remote host closed the connection) 16.59.29 Join sideral [0] (~sideral@213.165.85.248) 16.59.31 Quit sideral (Changing host) 16.59.31 Join sideral [0] (~sideral@rockbox/developer/sideral) 17.02.38 Part Zagor 17.09.07 Quit sideral (Remote host closed the connection) 17.09.41 Join sideral [0] (~sideral@213.165.85.248) 17.09.41 Quit sideral (Changing host) 17.09.41 Join sideral [0] (~sideral@rockbox/developer/sideral) 17.11.27 Quit nirv (Ping timeout: 276 seconds) 17.26.12 Quit robin0800 (Quit: Leaving) 17.32.29 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 17.45.36 Join bluebrother-bot [0] (~bluebroth@f053154182.adsl.alicedsl.de) 17.45.42 Part sideral 17.52.04 Quit piotrekm (Quit: piotrekm) 17.54.24 *** Saving seen data "./dancer.seen" 18.08.11 Join u42p [0] (~v35b@d084169.adsl.hansenet.de) 18.35.44 Quit liar (Ping timeout: 258 seconds) 18.37.18 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 18.38.02 Part domonoky 18.43.30 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.43.30 Quit bertrik (Changing host) 18.43.30 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 18.46.09 Join ender` [0] (krneki@foo.eternallybored.org) 18.50.17 Quit swilde (Quit: ERC Version 5.3 (IRC client for Emacs)) 18.58.26 Join stoffel [0] (~quassel@p57B4B0A6.dip.t-dialin.net) 19.03.28 # amiconn: did you see my earler question? 19.04.15 # ahem 19.04.34 # On hwcodec voice is loaded into the audio buffer while playback is stopped 19.04.59 # This is mostly because of being lowmem - we just cannot set aside the voice buffer permanently 19.05.39 # But since hwcodec can only play one audio stream at a time anyway, this is no loss 19.06.21 # there's no obvious control transfer 19.06.40 # As for buffering, everything is done in mpeg.c. It's the playback engine as well as the recording engine (when MAS3587F is present) 19.07.25 # Transforming hwcodec to the new playback engine is still a todo 19.08.04 # so voice is only loaded when playback is stopped, this is AFAICS the same on swcodec. but what about playing back? 19.08.17 # only one of voice or audio plays at a time? 19.08.23 Join petur [0] (~petur@rockbox/developer/petur) 19.09.03 # Yes - there is no other way 19.09.16 # Perhaps I missed it, but who makes sure they don't happen in parallel? 19.09.20 # Starting playback throws the voice file out of ram 19.09.55 Part u42p ("Leaving") 19.10.09 # There's a somewhat special handling on Ondios, in that the voice file isn't loaded at once, but memory wise that makes no difference 19.11.15 # Ondios load each voice clip at first access. If it would load the whole file at once, there would be a ~5 second delay after playback before the voice starts talking 19.12.36 # but it (possibly) has the entire voice in memory? 19.12.59 # I already wondered about VOICE_PROGRESSIVE_LOAD vs VOICE_PARTIAL_LOAD 19.14.48 # Iirc mpeg.c calls talk_buffer_steal() when starting playback (regarding locking) 19.16.12 # Yes, the in-memory layout of the voice file on the Ondios is exactly the same as on the other archoses, except that there are gaps for all clips which haven't been played after the last voice file reload 19.16.17 # the talk_* functions also check audio_status() 19.16.22 # (which I saw just now) 19.16.53 # So if on Ondio the voice file doesn't fit into ram, it won't work. There is no true partial file handling 19.17.34 # Ah, this is what's called progressive load nowadays 19.17.46 # I want to remove direct audiobuf accesses, so I looked how I could give an entity the control over the audiobuf, but this voice/audio handling confuses me 19.18.09 # There's also recording to take into consideration 19.18.11 # also because it seemed different between hwcodec and swcodec, but now I realize it's mostly about memory size 19.19.19 # It's not only memory size, but also "disk" speed 19.19.29 # yes, that too 19.20.10 # * amiconn thinks the partial loading method could be ported to the Ondios 19.20.37 # It would have the advantage that there's no hard limit for voice file size anymore, so one could even use a high quality voice 19.21.57 # essentially, partial loads 64 clips, and then as needed after that (like progressive) 19.22.28 # no hard limit, but it drops already loaded clips 19.23.15 # 64 is the voice queue depth 19.26.09 # it's also the size of the cache 19.42.22 Join Horscht [0] (~Horscht@p5DD567F6.dip.t-dialin.net) 19.42.22 Quit Horscht (Changing host) 19.42.22 Join Horscht [0] (~Horscht@xbmc/user/horscht) 19.43.31 # amiconn: so mpeg.c is in actual control, and someone has to stop playback if voice should be played 19.44.41 # Someone == either the user, or playback ends 19.44.55 # so no code does automatically? 19.45.03 # No 19.45.12 # Playback has priority over voice 19.45.17 # good to know 19.51.09 Quit sasquatch (Ping timeout: 240 seconds) 19.53.51 Join u42p [0] (~v35b@d084169.adsl.hansenet.de) 19.54.25 *** Saving seen data "./dancer.seen" 19.58.51 Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) 20.05.20 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 20.07.49 Quit stoffel (Ping timeout: 252 seconds) 20.15.24 Quit n1s (Remote host closed the connection) 20.17.32 Join TheLemonMan [0] (~lem0n@151.26.5.138) 20.21.43 # jhMikeS: how hard would it be to change the audiobuf layout? 20.22.03 Part u42p ("Leaving") 20.22.31 # from [[|TALK]|SCRATCH|BUFFERING|PCM|] to [BUFFERING|SCRATCH|[TALK|]PCM]? 20.23.05 # point is, if compation should work nicely the audio buffer wants to be resizable 20.23.14 Join funman [0] (~fun@rockbox/developer/funman) 20.23.45 # taking buffering away from the front, so that PCM and TALK can deal with dma without worring about buffer shortage 20.28.43 Nick niekie_ is now known as niekie (~niek@CAcert/Assurer/niekie) 20.32.33 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 20.32.34 Quit pamaury (Changing host) 20.32.34 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 20.39.30 # * kugel wonders if Slasheri or pamaury already looked at his dircache patches 20.40.25 # I had a quick look, did you add some mor e? 20.40.50 # no 20.46.29 Quit petur (Quit: here today, gone tomorrow) 20.50.21 # kugel: it should be pretty flexible 20.52.28 Quit TheLemonMan (Quit: Ex-Chat) 20.54.07 # amiconn: I don't see talk_buffer_steal() being called from mpeg.c 20.54.34 # kugel: Must admit to wondering what the advantage is to the second 20.55.39 # jhMikeS: the buffering portion should be the easiest to resize 20.56.02 # talk and pcm deal with dma so they can't easily be resized or moved 20.56.37 # so if one does buflib_alloc(), and the audio buffer needs to be shrinked to allow the allocation, the layout should make that most easy 20.58.42 # buffering sure needs to be redone though 20.59.41 # why not allocate scratch from buflib? 21.01.50 # jhMikeS: that could also be done 21.01.52 Join JesusFreak316 [0] (~JesusFrea@pool-173-65-69-63.tampfl.fios.verizon.net) 21.02.12 # buffering doesn't necessarily need to be redone IIUC 21.02.33 # If I get the mixer in soon enough, the voice pcm and beep pcm buffers can be dynamic too 21.02.34 # On hwcodec buffering and "pcm" is all the same - mpeg.c playback - and it uses dma too 21.02.55 # anyway, resizing also means enlarging the buffer if something was freed in the meantime which works best for buffering 21.03.08 # jhMikeS: but they may not move, no? 21.03.14 # kugel: the data it carries about handles is based on thing mod the buffer size (if it's a differnt size things won't be right) 21.03.28 # I'm not sure about the call chain that leads to talk_buffer_steal() when starting playback on hwcodec 21.03.34 # kugel: they can if the beep or voice is idle, sure 21.04.06 # but not at all times 21.04.47 # amiconn: it looks like it just starts playing and hopes voice gets it right (it checks audio_status() with each voice/talk request) 21.05.35 # jhMikeS: well, if it isn't too risky to race with dma, then sure they can be dynamic too 21.06.26 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 21.09.22 # amiconn: I'm looking for a proper place to reset the buffer prior to starting playback 21.09.56 # kugel: right now it's less flexible that it would be 21.10.24 # what do you mean? 21.11.21 # amiconn: playlist_start() maybe? 21.12.36 # with the mixer, the channels use independent buffers and one knows when the channel is operating but right now, what it's using depends on if it's mixing or not because audio is playing or not 21.15.15 Quit funman (Ping timeout: 244 seconds) 21.16.21 # but I do know the audio buffer can't just be resized without throwing a bunch of index data out of whack 21.17.41 Join funman [0] (~fun@rockbox/developer/funman) 21.18.11 Join sasquatch [0] (~username@46.115.24.189) 21.21.32 # jhMikeS: well, it's not fatal if it isn't easily possible 21.21.53 # but it's still easier to use the buffering buffer for resizing 21.28.11 Quit dfkt (Read error: Connection reset by peer) 21.28.17 Join dfkt [0] (dfkt@unaffiliated/dfkt) 21.43.54 Quit GeekShadow (Quit: The cake is a lie !) 21.44.56 # * kugel suddenly notices why changing languages stops playback 21.45.18 Quit sasquatch (Ping timeout: 240 seconds) 21.48.11 # amiconn: it looks like language loading slightly bugged on hwcodec 21.50.26 # ah no, only if there was VOICE_PARTIAL_LOAD 21.52.02 Quit funman (Quit: leaving) 21.52.46 Quit [Saint] (Ping timeout: 250 seconds) 21.52.52 Join robin0800 [0] (~robin0800@149.254.61.36) 21.54.26 *** Saving seen data "./dancer.seen" 21.57.20 Join [Saint] [0] (~st.lasciv@124-197-3-117.callplus.net.nz) 21.58.27 Quit piotrekm (Quit: piotrekm) 22.30.36 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 22.42.20 Quit esperegu_ (Read error: Connection reset by peer) 22.43.28 Quit AlexP (Ping timeout: 250 seconds) 22.45.20 Quit efyx (Remote host closed the connection) 22.46.12 Quit sinthetek (Ping timeout: 252 seconds) 22.50.22 Quit benedikt93 (Quit: Welcome to the Internet, where the men are men, the women are men and the children are agents of the FBI) 22.54.19 Join fml [0] (~chatzilla@manz-5f74b333.pool.mediaWays.net) 22.55.17 # amiconn: hello. You don't like git? Why? I do not use it either but not because I don't like it but rather because I just didn't have to use it. 22.59.31 Quit guymann (Quit: brb) 23.07.05 Join guymann [0] (~charles@66-159-173-149.adsl.snet.net) 23.08.22 Quit user890104 (Read error: Connection reset by peer) 23.09.15 Quit robin0800 (Quit: Leaving) 23.10.24 Quit factor (Quit: Leaving) 23.13.08 Quit fml (Quit: ChatZilla 0.9.86.1 [Firefox 3.6.17/20110422054454]) 23.13.23 Join robin0800 [0] (~robin0800@149.254.60.34) 23.14.40 Join AlexP [0] (~alex@rockbox/staff/AlexP) 23.17.43 Join NoPinky [0] (~NoPinky@drsd-4dbd9f82.pool.mediaWays.net) 23.17.48 # hello 23.18.17 # I have a kind of bricked 8gb sansa clip+ lying around 23.19.01 Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek) 23.19.02 # I was messing with external batteries, it worked for quite a while but then something happened 23.19.16 # rockbox would not boot anymore 23.20.18 # when I plug the clip+ to the pc via usb it is recognised correctly, even the microsd drive is shown 23.20.46 # but not even the original sansa system would load 23.21.13 # Now i can only use it as a flashdrive and microsd card reader 23.21.24 # anyone has an idea to unbrick it? 23.26.34 Quit bthomson (Quit: WeeChat 0.3.3-dev) 23.30.19 Join bthomson [0] (~bthomson@c-68-33-5-232.hsd1.va.comcast.net) 23.31.17 Join user890104 [0] (~Venci@6bez10.info) 23.41.27 Quit ReimuHakurei (Read error: Connection reset by peer) 23.49.21 Join ReimuHakurei [0] (~reimu@74.112.212.15) 23.50.38 Quit kevku (Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/) 23.54.31 *** Saving seen data "./dancer.seen"