--- Log for 16.10.115 Server: sinisalo.freenode.net Channel: #rockbox --- Nick: logbot- Version: Dancer V4.16 Started: 29 days and 19 hours ago 00.00.06 # clip zip: https://rmaa.dfkt.tk/Comparisons/Sansa%20Clip%20Zip%20-%20Impedances.htm 00.01.33 # I don't remember what I did with the fuze+ one, wait a minute 00.04.10 # http://amaury.pouly.free.fr/Images/Comparison.htm 00.05.34 # first link is not working for me.. hmm 00.05.34 # My conclusion is the Clip Zip is probably better 00.05.51 Join Strife89 [0] (~Strife89@2602:306:bce1:8c20:f1bd:bc21:34da:cee) 00.06.09 # well in my opinion it sounds better than creative 00.06.17 # hum, it works for me 00.07.11 # anyway, what is says is that the clip zip has a flatter response curve, better noise level, comparable dynamic range 00.08.19 # also the Fuze+ (and maybe the ZEN MX) suffers from a weird problem no captured by any test but definitly real: some kind of background noise that is extremely small but clearly hearable, probably because of the frequency and/or shape 00.08.52 # * pamaury should rmaa the Fiio X1 to compare ! 00.09.18 # mhm, thank you for informations. I'll stay with clip then, at least for now 00.09.42 # I need change it soon or later to something else, I would like to have rockbox on it 00.10.03 # Also not so big price, maybe a little more than sansa clip zip about 2 years ago :p 00.10.25 # well, there are not that many news devices with rockbox: we can't rockbox the new clip sport, the new Sont devices are really expensive for what they are 00.10.47 # the Fiio X1 has good sound but poor battery life and is already 100EUR 00.11.29 # Fiio announced the M3, apparently for $55 but it uses almost the same soc as the clip sport, so rockbox is a no-no at the moment :( 00.12.01 # yeah I heard about 512KB memory ;p 00.12.37 # yeah 00.12.42 # hmm, battery from apple music player fits sansa clip zip so I heard.. 00.12.51 # it's still avaiable to buy 00.13.16 # maybe I should get it then, mine sansa works fine but this battery... ugh.. 00.14.21 # also I don't need too much, my headphones are hmm.. just fine imo (creative aurvana live), also my hearing is not so good as it was ^^ 00.39.17 Quit o43 (Quit: Lost terminal) 00.42.28 *** Saving seen data "./dancer.seen" 00.47.53 Quit Topy44 (K-Lined) 00.53.06 Join Topy44 [0] (topy@ns3.kurz.pw) 00.59.17 Quit Strife89 (Ping timeout: 240 seconds) 01.10.03 # yeah, I can attest to the background noise on the fuze+ 01.11.57 Quit pamaury (Ping timeout: 260 seconds) 01.19.04 Quit krnlyng (Remote host closed the connection) 01.26.01 Join Bray90820 [0] (~Bray90820@2604:2d80:800a:8264:8d89:ed38:b531:5f62) 01.27.16 Join amiconn_ [0] (~amiconn@rockbox/developer/amiconn) 01.27.16 Quit amiconn (Killed (leguin.freenode.net (Nickname regained by services))) 01.27.16 Nick amiconn_ is now known as amiconn (~amiconn@rockbox/developer/amiconn) 01.27.47 Quit pixelma (Disconnected by services) 01.27.47 Join pixelma_ [0] (~pixelma@rockbox/staff/pixelma) 01.27.49 Nick pixelma_ is now known as pixelma (~pixelma@rockbox/staff/pixelma) 01.29.40 Join yuriks_ [0] (~quassel@opentyrian/developer/yuriks) 01.29.45 Join gbl08ma_ [0] (~gbl08ma@hydrogen.tny.im) 01.30.15 Quit yuriks (Remote host closed the connection) 01.30.15 Quit gbl08ma (Write error: Broken pipe) 01.30.16 Quit WakiMiko (Max SendQ exceeded) 01.30.16 Join jtdesigns01_ [0] (~quassel@2601:400:8000:2669:230:bdff:fe71:cebd) 01.30.29 Join foo|sh [0] (~quassel@2601:241:c200:4bc5:f534:3f14:7c03:f9e4) 01.30.59 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko) 01.32.18 Quit Bray9082_ (Ping timeout: 253 seconds) 01.32.50 Quit chrisb (Ping timeout: 265 seconds) 01.33.49 Quit olspookishmagus (Ping timeout: 265 seconds) 01.34.17 Quit jtdesigns01 (Ping timeout: 240 seconds) 01.34.17 Quit foolsh (Ping timeout: 240 seconds) 01.34.18 Quit chxr (Ping timeout: 265 seconds) 01.34.18 Quit GeekShadow (Ping timeout: 265 seconds) 01.34.18 Quit dys (Ping timeout: 265 seconds) 01.34.19 Quit Smarticles101 (Ping timeout: 265 seconds) 01.34.47 Quit akaWolf (Ping timeout: 265 seconds) 01.34.47 Quit zu (Ping timeout: 265 seconds) 01.34.47 Quit prof_wolfff (Ping timeout: 265 seconds) 01.34.48 Quit TD-Linux (Ping timeout: 265 seconds) 01.35.31 Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) 01.35.44 Join GeekShadow [0] (~antoine@nzf.turmel.info) 01.35.44 Quit GeekShadow (Changing host) 01.35.44 Join GeekShadow [0] (~antoine@reactos/tester/GeekShadow) 01.35.55 Nick olspookishmagus is now known as Guest29250 (~pookie@snf-137798.vm.okeanos.grnet.gr) 01.36.19 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 01.39.50 Join Smarticles101 [0] (~Smarticle@codmadnesspro.com) 01.40.03 Join TD-Linux [0] (~Thomas@about/essy/indecisive/TD-Linux) 01.40.11 Nick foo|sh is now known as foolsh (~quassel@2601:241:c200:4bc5:f534:3f14:7c03:f9e4) 01.40.29 Join dys [0] (~dys@ip-109-41-61-122.web.vodafone.de) 01.44.28 Join zu [0] (~zu@ks387228.kimsufi.com) 01.55.22 Quit bluebrother^ (*.net *.split) 01.55.22 Quit knittl (*.net *.split) 01.55.22 Quit suYin`OFF (*.net *.split) 01.55.22 Quit ZincAlloy1 (*.net *.split) 01.55.23 Quit [Franklin] (*.net *.split) 01.55.23 Quit dan- (*.net *.split) 01.55.23 Quit Guest29250 (*.net *.split) 01.55.23 Quit Topy44 (*.net *.split) 01.55.23 Quit x56 (*.net *.split) 01.55.23 Quit [Saint] (*.net *.split) 01.55.23 Quit tchan (*.net *.split) 01.55.23 Quit theemstra (*.net *.split) 01.55.23 Quit K1773R (*.net *.split) 01.55.23 Quit TD-Linux (*.net *.split) 01.55.23 Quit foolsh (*.net *.split) 01.55.23 Quit yuriks_ (*.net *.split) 01.55.24 Quit pixelma (*.net *.split) 01.55.24 Quit amiconn (*.net *.split) 01.55.24 Quit Bray90820 (*.net *.split) 01.55.24 Quit Jinx (*.net *.split) 01.55.24 Quit greatwolf (*.net *.split) 01.55.24 Quit Staphylo (*.net *.split) 01.55.25 Quit Jack87 (*.net *.split) 01.55.25 Quit JanC (*.net *.split) 01.55.25 Quit zoktar (*.net *.split) 01.55.25 Quit ChanServ (*.net *.split) 01.55.26 Quit JdGordon (*.net *.split) 01.55.26 Quit [7] (*.net *.split) 01.55.26 Quit alexbobp (*.net *.split) 01.55.26 Quit ranmachan (*.net *.split) 01.55.26 Quit ruhans (*.net *.split) 01.55.26 Quit ivologger (*.net *.split) 01.55.26 Quit kvieta (*.net *.split) 01.55.26 Quit webmeister (*.net *.split) 01.55.27 Quit jtdesigns01_ (*.net *.split) 01.55.27 Quit GodEater` (*.net *.split) 01.55.27 Quit Tristitia (*.net *.split) 01.55.27 Quit puckipedia (*.net *.split) 01.55.28 Quit mc2739 (*.net *.split) 01.55.28 Quit shamus (*.net *.split) 01.55.28 Quit user890104 (*.net *.split) 01.55.28 Quit Slasheri (*.net *.split) 01.55.28 Quit akaWolf (*.net *.split) 01.55.28 Quit WakiMiko (*.net *.split) 01.55.29 Quit APLU (*.net *.split) 01.55.29 Quit Unhelpful (*.net *.split) 01.55.29 Quit TorC (*.net *.split) 01.55.29 Quit haasn (*.net *.split) 01.55.29 Quit igitoor (*.net *.split) 01.55.30 Quit Rondom (*.net *.split) 01.55.30 Quit architekt (*.net *.split) 01.55.30 Quit soap (*.net *.split) 01.55.30 Quit preglow (*.net *.split) 01.55.30 Quit nosa-j (*.net *.split) 01.55.30 Quit megal0maniac (*.net *.split) 01.55.30 Quit ps-auxw (*.net *.split) 01.55.30 Quit uwe_ (*.net *.split) 01.55.30 Quit aevin (*.net *.split) 01.55.31 Quit Xyem (*.net *.split) 01.55.31 Quit froggyman (*.net *.split) 01.55.31 Quit Galois (*.net *.split) 01.55.31 Quit ender| (*.net *.split) 01.55.31 Quit scorche` (*.net *.split) 01.55.32 Quit simabeis_ (*.net *.split) 01.55.32 Quit Smarticles101 (*.net *.split) 01.55.32 Quit kugel__ (*.net *.split) 01.55.32 Quit scorche|sh (*.net *.split) 01.55.32 Quit funman (*.net *.split) 01.55.32 Quit orzo_ (*.net *.split) 01.55.32 Quit uwe_mobile (*.net *.split) 01.55.33 Quit rela (*.net *.split) 01.55.33 Quit orly_owl (*.net *.split) 01.55.33 Quit uber (*.net *.split) 01.55.33 Quit ParkerR (*.net *.split) 01.55.33 Quit jvd (*.net *.split) 01.55.33 Quit __jae__ (*.net *.split) 01.55.34 Quit mikroflops (*.net *.split) 01.55.34 Quit Marex (*.net *.split) 01.55.34 Quit ruskie (*.net *.split) 01.55.34 Quit sLite (*.net *.split) 01.55.34 Quit GeekShadow (*.net *.split) 01.55.34 Quit gbl08ma_ (*.net *.split) 01.55.34 Quit Mir (*.net *.split) 01.55.34 Quit n17ikh (*.net *.split) 01.55.34 Quit Makinit (*.net *.split) 01.55.34 Quit Guest18189 (*.net *.split) 01.55.34 Quit derf (*.net *.split) 01.55.34 Quit shmibs (*.net *.split) 01.55.34 Quit Petri152 (*.net *.split) 01.55.34 Quit rasher (*.net *.split) 01.55.35 Quit dongs (*.net *.split) 01.55.35 Quit dys (*.net *.split) 01.55.35 Quit fs-bluebot (*.net *.split) 01.55.35 Quit pablo_pi (*.net *.split) 01.55.35 Quit munch (*.net *.split) 01.55.35 Quit michaelni_ (*.net *.split) 01.55.35 Quit evilnick_ (*.net *.split) 01.55.35 Quit japc (*.net *.split) 01.55.35 Quit utrack (*.net *.split) 01.55.36 Quit bzed (*.net *.split) 01.55.36 Quit yosafbridge (*.net *.split) 02.07.50 Join simabeis_ [0] (~simabeis@lobmenschen.de) 02.07.50 Join scorche` [0] (~scorche@rockbox/administrator/scorche) 02.07.50 Join bzed [0] (~bzed@shell.bzed.at) 02.07.50 Join dongs [0] (~dongs@bcas.tv) 02.07.50 Join rasher [0] (~rasher@rockbox/developer/rasher) 02.07.50 Join Petri152 [0] (~Petri152@petritrebs.ca) 02.07.50 Join shmibs [0] (~shmibs@shmibbles.me) 02.07.50 Join derf [0] (~derf@static-108-18-126-14.washdc.fios.verizon.net) 02.07.50 Join Guest18189 [0] (~Slayer@c-69-255-136-113.hsd1.va.comcast.net) 02.07.50 Join Makinit [0] (makinit@makinit.nl) 02.07.50 Join n17ikh [0] (~n17ikh@unaffiliated/n17ikh) 02.07.50 Join utrack [0] (~u@unaffiliated/utrack) 02.07.50 Join japc [0] (~japc@194.65.5.235) 02.07.50 Join evilnick_ [0] (~evilnick@d54C3417E.access.telenet.be) 02.07.50 Join Mir [0] (~Mir@pool-100-39-12-139.lsanca.fios.verizon.net) 02.07.50 Join michaelni_ [0] (~michael@chello084114129144.4.15.vie.surfer.at) 02.07.50 Join munch [0] (~munch@unaffiliated/munch) 02.07.50 Join pablo_pi [0] (~pablo@190.148.249.124) 02.07.50 Join fs-bluebot [0] (~fs-bluebo@x5ce779a7.dyn.telefonica.de) 02.07.50 Join gbl08ma_ [0] (~gbl08ma@hydrogen.tny.im) 02.07.50 Join GeekShadow [0] (~antoine@reactos/tester/GeekShadow) 02.07.50 Join dys [0] (~dys@ip-109-41-61-122.web.vodafone.de) 02.07.50 Join prof_wolfff [0] (~prof_wolf@89.141.51.203.dyn.user.ono.com) 02.07.50 Join theemstra [0] (~theemstra@2a03:b0c0:2:d0::5c:4001) 02.07.50 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 02.07.50 Join [Saint] [0] (~hayden@rockbox/staff/saint) 02.07.50 Join x56 [0] (0x56@unaffiliated/x56) 02.07.50 Join Topy44 [0] (topy@ns3.kurz.pw) 02.07.50 Join Guest29250 [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) 02.07.50 Join yosafbridge [0] (~yosafbrid@105.ip-167-114-152.net) 02.07.50 Join knittl [0] (~knittl@fucktheforce.de) 02.07.50 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 02.07.50 Join suYin`OFF [0] (mysuyin@server2.shellfire.net) 02.08.46 Join JanC [0] (~janc@lugwv/member/JanC) 02.08.46 Join zoktar [0] (~zoktar@unaffiliated/zoktar) 02.09.11 Join chxr [0] (chxr@procasur.inc.cl) 02.09.11 Join ZincAlloy1 [0] (~Adium@p57B94F3E.dip0.t-ipconnect.de) 02.09.11 Join [Franklin] [0] (~quassel@unaffiliated/franklin) 02.09.11 Join dan- [0] (~d@unaffiliated/danneh-/x-7505085) 02.10.13 Join K1773R [0] (~K1773R@unaffiliated/k1773r) 02.10.22 Join Smarticles101 [0] (~Smarticle@codmadnesspro.com) 02.10.22 Join kugel__ [0] (~kugel@rockbox/developer/kugel) 02.10.22 Join funman [0] (~fun@rockbox/developer/funman) 02.10.22 Join scorche|sh [0] (~scorche@rockbox/administrator/scorche) 02.10.22 Join orzo_ [0] (joe@lasker.childrenofmay.org) 02.10.22 Join uwe_mobile [0] (~uwe@static.88-198-8-117.clients.your-server.de) 02.13.24 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 02.13.24 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko) 02.13.24 Join APLU [0] (~mulx@eva.aplu.fr) 02.13.24 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 02.13.24 Join TorC [0] (~TorC@fsf/member/TorC) 02.13.24 Join haasn [0] (~haasn@2a01:4f8:d13:5245::2) 02.13.24 Join igitoor [0] (igitur@unaffiliated/contempt) 02.13.24 Join Rondom [0] (~rondom@nonmodosedetiam.net) 02.13.24 Join architekt [0] (archi@i.love.coding4.coffee) 02.13.35 Join jtdesigns01 [0] (~quassel@2601:400:8000:2669:230:bdff:fe71:cebd) 02.13.35 Join GodEater` [0] (~whoknows@ec2-54-201-224-30.us-west-2.compute.amazonaws.com) 02.13.35 Join Tristitia [0] (~tristitia@178.18.241.185) 02.13.35 Join puckipedia [0] (puck@irc.puckipedia.com) 02.14.05 Join uber [0] (~uber@107.170.92.230) 02.14.05 Join soap [0] (~soap@rockbox/staff/soap) 02.14.05 Join preglow [0] (~thomj@2001:840:4243:3::101) 02.14.05 Join nosa-j [0] (~m00k@cpe-24-74-14-251.carolina.res.rr.com) 02.14.05 Join megal0maniac [0] (~megal0man@unaffiliated/megal0maniac) 02.14.05 Join ps-auxw [0] (~arneb@p50875EF1.dip0.t-ipconnect.de) 02.14.05 Join uwe_ [0] (~uwe_@dslb-088-067-177-159.088.067.pools.vodafone-ip.de) 02.14.05 Join aevin [0] (eivindsy@unaffiliated/aevin) 02.14.05 Join Xyem [0] (xyem@li193-64.members.linode.com) 02.14.05 Join froggyman [0] (~frogs@unaffiliated/froggyman) 02.14.05 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 02.14.05 Join ender| [0] (krneki@2a01:260:4094:1:42:42:42:42) 02.14.14 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 02.14.14 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 02.14.14 Join alexbobp [0] (~alex@capitalthree.pwnz.org) 02.14.14 Join ranmachan [0] (~ranma@yumi.uguu.de) 02.14.14 Join ruhans [0] (uid76353@gateway/web/irccloud.com/x-kvkdakobehqgmxcs) 02.14.14 Join ivologger [0] (~ivologger@216-227-60-165.dsl.chatny.frpt.net) 02.14.14 Join kvieta [0] (~kvieta@149.255.110.134) 02.14.14 Join webmeister [0] (webmeister@unaffiliated/webmeister) 02.17.17 Join rela [0] (~x@pdpc/supporter/active/rela) 02.17.17 Join orly_owl [0] (~david@unaffiliated/orly-owl/x-3167833) 02.17.17 Join ParkerR [0] (~ParkerR@unaffiliated/parkerr) 02.17.17 Join jvd [0] (~syscrash@poipu/developer/syscrash) 02.17.17 Join __jae__ [0] (~jae@dedicated.jaerhard.com) 02.17.17 Join mikroflops [0] (~yogurt@178.174.137.46) 02.17.17 Join Marex [0] (~Marex@195.140.253.167) 02.17.17 Join ruskie [0] (ruskie@sourcemage/mage/ruskie) 02.17.17 Join sLite [0] (~quassel@5.45.109.210) 02.18.14 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 02.18.14 Join shamus [0] (~shmaus@ip-206-192-194-12.marylandheights.ip.cablemo.net) 02.18.14 Join user890104 [0] (Venci@unaffiliated/user890104) 02.18.14 Join Slasheri [0] (miipekk@rockbox/developer/Slasheri) 02.21.49 Join TD-Linux [0] (~Thomas@about/essy/indecisive/TD-Linux) 02.21.49 Join foolsh [0] (~quassel@2601:241:c200:4bc5:f534:3f14:7c03:f9e4) 02.21.49 Join yuriks_ [0] (~quassel@opentyrian/developer/yuriks) 02.21.49 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 02.21.49 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 02.21.49 Join Jinx [0] (Dojo@unaffiliated/jinx) 02.21.49 Join greatwolf [0] (greatwolf@gateway/shell/panicbnc/x-pkmjqregtnryqcbe) 02.21.49 Join Staphylo [0] (~Staphylo@2a01:4f8:190:126a:d70a:378:c354:a3a3) 02.21.49 Join Jack87 [0] (Jack87@nasadmin/admin/jack87) 02.21.51 Quit Jinx (Ping timeout: 246 seconds) 02.23.50 Quit Smarticles101 (Ping timeout: 240 seconds) 02.24.05 Join Smarticles101_ [0] (~Smarticle@codmadnesspro.com) 02.25.53 Join rela_ [0] (~x@p200300764D773300253C33417C4CBA51.dip0.t-ipconnect.de) 02.27.19 Quit rela (Read error: Connection reset by peer) 02.27.52 Quit Smarticles101_ (Quit: Um, bai!) 02.28.43 Join Smarticles101 [0] (~Smarticle@codmadnesspro.com) 02.30.06 Join ChanServ [0] (ChanServ@services.) 02.30.06 Mode "#rockbox +o ChanServ " by sinisalo.freenode.net 02.30.18 Quit uber (Changing host) 02.30.18 Join uber [0] (~uber@unaffiliated/uber) 02.31.05 Join Jinx [0] (Dojo@108.202.196.185) 02.31.12 Quit Jinx (Changing host) 02.31.12 Join Jinx [0] (Dojo@unaffiliated/jinx) 02.31.27 Join Bray90820 [0] (~Bray90820@173-17-46-117.client.mchsi.com) 02.38.35 Quit Smarticles101 (Quit: Um, bai!) 02.42.31 *** Saving seen data "./dancer.seen" 02.53.43 Join Smarticles101 [0] (~Smarticle@codmadnesspro.com) 03.00.25 Join Strife89 [0] (~Strife89@adsl-98-80-212-18.mcn.bellsouth.net) 03.05.58 Quit ruhans (Ping timeout: 268 seconds) 03.09.58 # * [Saint] grumbles 03.10.14 # <[Saint]> something something, makefiles, something, build system, something, grumble. 03.11.31 # <[Saint]> I want the build system to respect the OUT_DIR_COMMON_BASE environment variable if present 03.18.46 # <[Saint]> Hmmmmm. The android build tools version detection is completely broken. 03.18.57 # <[Saint]> We sure as shit didn't future-proof that one. 03.20.17 # Saint: AB_REPEAT_ENABLE, ACTION_WPS_BROWSE, HAVE_AGC, HAVE_HISTOGRAM, have you tested it? can i commit them? 03.23.37 # <[Saint]> AB_REPEAT_ENABLE, ACTION_WPS_BROWSE were fine, HAVE_AGC compiles but I couldn't test it due to having no means of recording from mic/linein at the time. HAVE_HISTOGRAM appears to be entirely dead code, I need to look into that some more. 03.24.00 # <[Saint]> prof_wolfff: ^ 03.24.48 # <[Saint]> I was more interested in getting FM working at the time, but I didn't get particularly far. There's a fair amount of work to do there but I see you've laid the groundwork. 03.25.01 # TheSeven: g#898, i have tested a similar patch to this for more than 1/2 years and it works ok, how it works on nano2g?, i have similar patches to this, do you think it could be commited? 03.25.14 # 3Gerrit review #898 at http://gerrit.rockbox.org/r/898 : 3iPod Nano 2G and Classic: Fix power and charging detection. by Michael Sparmann 03.25.27 # <[Saint]> I also need to remember to push a patch when I get home. 03.25.48 # <[Saint]> I have figured out a _much_ nicer sounding piezoelectric 'beep' tone. 03.26.09 # <[Saint]> The click/beep we have presently sounds terrible. 03.26.16 # Saint: do you think i can commit AB_REPEAT_ENABLe and ACTION_WPS_BROWSE? 03.26.27 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) 03.26.30 # <[Saint]> Yes. 03.29.38 # Saint: g#379 is a patch for cpu_freq that gets ~14fps, do you think it is ok? i have tested it a bit, for me it is ok, but need users feedback to commit it, if it is not ok we need to try other approach to get a custom "browse menu" frequency, i think that 36MHz saves ~5% cpu and we need to try to use that freq while playing 03.29.49 # 3Gerrit review #379 at http://gerrit.rockbox.org/r/379 : 3iPod Classic: experimental CPU freq/volt scaling by Cástor Muñoz 03.30.01 Quit JdGordon (Ping timeout: 268 seconds) 03.30.09 # <[Saint]> No. Commit that and I'll yell at you. ;) 03.30.23 # :) 03.30.42 # have u tested it? 03.30.51 # <[Saint]> I have, yes. 03.31.04 # <[Saint]> The marginal savings are definitely not worth completely fucking up the user experience. 03.31.18 # <[Saint]> it makes it feel awful to use. 03.32.01 # <[Saint]> like, absolutely terrible. I can't offhand understand why it is so bad. 03.32.40 # <[Saint]> there doesn't seem to be any good reason as to why we shouldn't be able to puch enough frames at 36MHz. 03.32.58 # <[Saint]> Hell...look at the PortalPlayer iPods. 03.33.09 # <[Saint]> s/puch/push/g 03.33.19 Quit Strife89 (Ping timeout: 246 seconds) 03.33.25 Join ZincAlloy [0] (~Adium@p57B94899.dip0.t-ipconnect.de) 03.33.42 # we can try an intermediate (or even full) freq for browse menus, i think that playback at 36MHz is a must, i can try to play @36MHz and browse menus @54 MHz 03.34.26 Quit ZincAlloy1 (Ping timeout: 250 seconds) 03.34.30 # 36Mhz -> (14 fps), 54MHz -> 21 fps 03.35.50 # have you try g#379? (14 fps), it is so bad? 03.35.57 # <[Saint]> That's one thing I didn't understand with that patch, it seems to completely break the touchboosting. 03.36.01 # 3Gerrit review #379 at http://gerrit.rockbox.org/r/379 : 3iPod Classic: experimental CPU freq/volt scaling by Cástor Muñoz 03.36.09 # <[Saint]> EVen if I apply HAVE_GUI_BOOST, it seems to ignore it. 03.36.30 # ?\? 03.36.37 # <[Saint]> If we are clocking that low, we _absolutely_ need to boost on touch interaction. 03.37.13 # <[Saint]> I tried applying that define to see if it would help with the terrible update rate on the LCD, but, it seems to be ignored entirely. 03.38.10 # <[Saint]> perhaps I should try it again now that I'm not having to rebase all your changes into my tree. 03.39.10 # <[Saint]> but if we can't get the LCD refresh rate up to an acceptable level I would much rather have the runtime be ~30mins less than have a terrible user interface experience. 03.39.57 Join Strife89 [0] (~Strife89@adsl-98-80-212-18.mcn.bellsouth.net) 03.42.36 # ok, try it, for me it is not so bat (36MHz/14 fps), it is more fps than old internet videos, if needed i can try to use a target 54MHz intermediate frequency, in addition i am preparing some "controversial" memory powersave patches that lower refresh time to some unbeliable rates 03.43.41 # Saint: @36 MHz, maximum refresh rate is ~14 fps 03.45.00 # <[Saint]> the other thing I found curious is that I'm pretty sure we're supposed to boost in the WPS if there are peak meters in the theme. 03.45.12 # <[Saint]> but the refresh rate is messed up there too. 03.45.28 # <[Saint]> makes peak meters almost completely unusable. 03.45.28 # yes, looking at RB code i feel the same than you 03.46.50 # problem for me is that i don't know RB features very much, so sometimes i got surprised! 03.48.08 # <[Saint]> Well, HAVE_GUI_BOOST was added for the PP based iPods, to make scrolling through the lists a not-so-terrible-experience on low clocks. 03.48.41 # <[Saint]> The iPod Classic doesn't have HAVE_GUI_BOOST applied by default because the low clock is plenty high enough to push enough frames to the LCD to make this smooth. 03.48.57 # <[Saint]> But with your scaling patch, the clock is far too low for heavy UI work and it looks terrible. 03.49.16 # <[Saint]> So I enabled HAVE_GUI_BOOST on the ipod6g, but, to my surprise, it appeared to have absolutely no effect. 03.49.40 # <[Saint]> the user interface was still almost completely unusable. 03.49.42 # <[Saint]> it's...odd. 03.51.49 # <[Saint]> Does anyone happen to have a 64 bit Android 19.*.* build-tools? 03.51.58 # <[Saint]> Strife89, perhaps? 03.52.42 # <[Saint]> I can't be arsed monkeying around with the build client and build system to sidestep this shenanigans. 03.52.47 # Sorry, [Saint], I'm afraid not. :( 03.52.53 # <[Saint]> my Android SDK iis far too new 03.53.10 # I don't even have any 64-bit kernels set up, so I don't keep 64-bit software. 03.53.21 # <[Saint]> and there's some silly (smart at the time, silly now) version dependency checking code for build tools. 03.53.24 # i think that ATM GUI boost is activated, boosting GUI is not so bad, decrease playback frequency from actual 54MHz->36MHZ gives ~3-4 hours of additional playback, i will try to boost to 54 (or even 216MHZ) at target level code when LCD is awake an fall to 36 MHz when sleep, it seem that mp3 @320 can be decoded at 36 MHz 03.54.12 # <[Saint]> oh, hmmm, sorry - you're right, it is active by default, but it's deactivated in my tree. 03.54.16 # <[Saint]> whoops. 03.54.20 # [Saint]: If 32-bit is okay, I *might* have something from around that SDK version *somewhere* on one of my HDDs. 03.54.38 # <[Saint]> Strife89: nah, it's cool. I'll just monkey the build system behind its back. 03.54.49 # Okay. 03.55.02 # <[Saint]> I'll just symlink buiild-tools 23.*.* to 19.* 03.56.13 # <[Saint]> prof_wolfff: the Classic can do mp3 320 realtime decode in like 6~8MHz IIRC> 03.56.55 # <[Saint]> it's a bit of a beast. 03.57.09 # i am going to to compile bootloader using windows, what compiler is using RB to generate the rbutil for windows? 03.57.36 # have you tried bootloader 03.57.40 # ? 03.59.56 # <[Saint]> prof_wolfff: Qt/MinGW, I thought? 04.00.11 # <[Saint]> Also, no. Not presently. 04.00.35 # <[Saint]> ah, yes, Qt/MinGW - http://www.rockbox.org/wiki/RockboxUtilityDevelopment#How_To_Compile 04.04.46 Quit ZincAlloy (Quit: Leaving.) 04.05.10 # ok, i will try tomorrow a compilation, the bootloader development is at my own needs, i would like i RB people guides me if RB people thinks it needs some modifications, key pressed to access OF or RB or other things... 04.06.23 Join ruhans [0] (uid76353@gateway/web/irccloud.com/x-djeqxugfnbxjmhzn) 04.06.44 # this version of bootloader starts as a 'try' version, but it seems that it could be a commiteable one, what do you think? 04.09.05 # sorry, do have no tried it yet 04.22.00 # <[Saint]> lol, I should've thought about my client name and username on the host a bit more... 04.22.10 # <[Saint]> '2015-10-16 15:19:33 Server message: Welcome build-client-build-client. Your average build speed is 0 points/sec. Your average upload speed is 0 KB/s.' 04.22.21 # <[Saint]> prof_wolfff: no, I haven't. 04.42.34 *** Saving seen data "./dancer.seen" 05.20.25 Quit Strife89 (Quit: Off to bed) 05.27.55 Quit [7] (Disconnected by services) 05.28.04 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 05.43.04 Join JdGordon [0] (~jonno@ppp118-209-103-27.lns20.mel4.internode.on.net) 05.43.04 Quit JdGordon (Changing host) 05.43.04 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 05.45.52 Quit JdGordon_ (Ping timeout: 256 seconds) 06.09.37 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) 06.12.37 Quit JdGordon (Ping timeout: 260 seconds) 06.42.36 *** Saving seen data "./dancer.seen" 07.42.54 Quit JanC (Ping timeout: 240 seconds) 07.43.30 Quit amiconn (Remote host closed the connection) 07.43.30 Quit pixelma (Remote host closed the connection) 07.44.12 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 07.44.17 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 07.45.01 Quit knittl (Changing host) 07.45.01 Join knittl [0] (~knittl@unaffiliated/knittl) 07.57.00 Join JanC [0] (~janc@lugwv/member/JanC) 08.19.27 Nick Guest29250 is now known as olspookishmagus (~pookie@snf-137798.vm.okeanos.grnet.gr) 08.21.19 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 08.24.29 Join ender` [0] (krneki@foo.eternallybored.org) 08.42.37 *** Saving seen data "./dancer.seen" 08.50.33 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 09.05.38 Quit akaWolf (Ping timeout: 250 seconds) 09.05.55 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 09.06.25 Quit uber (Ping timeout: 240 seconds) 09.20.00 Join uber [0] (~uber@unaffiliated/uber) 09.29.28 Quit uber (Ping timeout: 252 seconds) 09.43.10 Join uber [0] (~uber@unaffiliated/uber) 09.43.11 Join xorly [0] (~xorly@ip-86-49-15-121.net.upcbroadband.cz) 09.43.49 Join petur [0] (~petur@rockbox/developer/petur) 10.06.19 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 10.09.13 Quit JdGordon_ (Ping timeout: 250 seconds) 10.42.38 *** Saving seen data "./dancer.seen" 10.43.51 Nick suYin`OFF is now known as suYin (mysuyin@server2.shellfire.net) 11.49.37 Join rela__ [0] (~x@p200300764D77330001311CD8D3AC164F.dip0.t-ipconnect.de) 11.51.30 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.52.17 # pamaury: ping 11.53.38 Quit rela_ (Ping timeout: 256 seconds) 11.53.50 Join rela_ [0] (~x@p200300764D773300BD9EFF398590F953.dip0.t-ipconnect.de) 11.57.14 Quit rela__ (Ping timeout: 250 seconds) 12.01.34 Quit rela_ (Ping timeout: 250 seconds) 12.09.23 # wodz: pong 12.09.31 # brb (coffee) 12.10.45 # pamaury: Do I recall correctly that in hwstub_shell DEV.read32(0xbfc00000) is supposed to read value from 0xbfc00000 ? 12.15.48 # yes 12.16.01 # a 32-bit integer 12.16.05 # atomically 12.16.26 Quit japc (Quit: Ex-Chat) 12.18.46 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 12.22.17 # hwstub lib is screwed on gerrit. TCP backend doesn't assign buf_sz which results in breaking early any other hwstub requests 12.23.50 # aaaah, I am dumb 12.25.21 # hmm 12.26.46 # I'm curious, I'm pretty sure the last time I updated hwstub on gerrit it was working 12.27.52 # I need to go, if you find a problem, describe how to reproduce it so I can have a look 12.30.31 # pamaury: Its a bit chicken and egg problem. In your version hwstub_open_tcp() called hwstub_open_internal() which in turn calls hwstub_get_desc() to get info about target and setup various fields of hwstub_device_t. 12.32.57 # pamaury: Now this is not valid anymore since hwstub_open_tcp() is supposed to connect to server only and hwserver_dev_open() is the point where link with physical device is established and hwstub_get_desc() can be called. 12.40.59 # I see, that's because there is no proper notion of context in your rework 12.41.22 # I've began some work for context handling, maybe let me have a try at it and hopefully it will fix everything 12.42.22 # yeah 12.42.39 *** Saving seen data "./dancer.seen" 12.46.29 Join Electricguy [0] (~quassel@217-211-154-12-no77.tbcn.telia.com) 12.59.47 # hmm, something is not working as it should in ajt213x hwstub. I am pretty sure that it used to recover from read fault from nonexisting address and now it simply crashes :/ 13.01.10 # wodz: did we commit the recover handler ? 13.01.27 # pamaury: didn't we? 13.03.29 # I don't know but I don't recall any change to the stub so I don't see how it could have become broken 13.03.48 # let me check 13.04.34 # it is committed: http://git.rockbox.org/?p=rockbox.git;a=commit;h=2cdfc43f10e3d755018ea508b64b209608d71864 13.05.48 # sooo, something somewhere got broken on atj 13.06.35 # strangely this is the last major commit on hwstub 13.06.46 # the only other change is trivial 13.07.19 # http://git.rockbox.org/?p=rockbox.git;a=commit;h=bc25437448c0642a8ea22e3f513ef1ca658dd737 13.07.51 # did you change your toolchain maybe ? 13.08.01 # don't think so 13.09.15 # hum, so maybe a library change ? 13.09.27 # I can't see how it could crash the device though 13.09.32 # but how? 13.10.46 # hum, thinking about it now, I think a few days ago I crashed my fuze+ with a bad read/write with hwstub 13.10.55 # so arm could be broken too... 13.11.05 # I need to check tonight 13.11.15 # (maybe it was an old version, I'm not sure) 13.24.01 # pamaury: I think I see where is problem and I think it is mips specific 13.24.14 # can you explain ? 13.28.11 # It is a bit complicated. Basically there are 2 registers k0 and k1 which are reserved for very lowlevel stuff. Normal code produced by compiler doesn't touch this two. I used them in implementing irq context specific stack (it saves store/restore in irq). BUT I also used them in recovery code. So I guess recovery code sets SP to something insane as a sidefect 13.28.48 # I mean on first irq after recovery 13.33.01 Quit petur (Remote host closed the connection) 13.51.24 Join ZincAlloy [0] (~Adium@p57B94899.dip0.t-ipconnect.de) 13.52.01 Quit Electricguy (Read error: Connection reset by peer) 14.16.29 # pamaury: Something strange is happening. The execution reaches set_data_abort_jmp() != 0 code path so it recovers from bad read. Something later is screwed. 14.30.35 # pamaury: Its unbelievable but hwstub and hwstub_shell from master DO work as expected 14.42.41 *** Saving seen data "./dancer.seen" 14.44.22 # that is strange 14.45.15 # wodz: maybe try to use wireshark, see if the requests are different ? 14.47.19 # print_log() seems to be affected as well 14.48.34 # this is really strange 14.53.56 # pamaury: As a side activity I played with MMU on atj. It is possible to remap (no surprise) dram and iram so no longjump is needed. 14.54.35 # how does the MMU help ? you get a protection fault ? 14.54.54 # pamaury: I statically remap and link binary in VMA 14.55.16 # mmu setup part is position independed piece of assembly in crt0.S 14.55.51 # I'm sorry, I don't see how this avoid the longjump, what happen if you make a faulty access ? 14.56.21 # maybe I'm missing something ^^ 14.56.31 # ah, not in this sense. I mean if you want to call code from iram running from dram or in reverse. 14.56.54 # with default mem layout this two addresses are too far for regular calls 14.57.13 # ahhhhhhh, understood :) 14.57.21 # probably a good idea indeed 15.00.55 # pamaury: BTW. I do have different compiler here and it barfs about lack of newline at the end of protocol.h and memory.h in hwstub 15.01.24 # ah yeah, I'll try to think about fixing those 15.02.42 # By the way, I think it would be nice to have a clean version of g#1210 15.02.43 Join amayer [0] (~amayer@mail.weberadvertising.com) 15.02.55 # 3Gerrit review #1210 at http://gerrit.rockbox.org/r/1210 : 3NOTFORMERGE: ./configure with arm-none-eabi by Nicky Sielicki 15.03.35 # because noawdays more and more cross compilers end up in repositories but they don't match the names of our configure script, although they probably work as well (if not better) 15.03.48 # arm-none-eabi is the typical example 15.04.18 # also mipsel-linux-gnu 15.04.33 # I am hesitant to do that. Currently we at least have KNOWN compiler. 15.05.03 # you would have to add a flag like --I-know-it-may-be-brokne 15.05.08 # the user can override compiler easily bit it must be explicit 15.05.30 # it would always be explicit anyway, I don't expect the configure script to pick up any toolchain 15.05.59 # and it would print a warning message saying this toolchain has not been tested 15.06.21 # I mean for example I just can't build the mips toolchain of rockboxdev.sh 15.06.46 # yeah, its waaaaay outdated 15.07.46 # and this way would make it *way* easier to test new toolchains too 15.08.13 # I don't mind explicit switch 15.09.10 # great :) I'll try to give a go at it, I don't know how much hacking it needs 15.09.48 # btw. You were talking about virtual mem support for ZEN MX. How you see it implemented (putting aside if ever) 15.12.01 # well, the simplest way would be to put the firmware on the flash storage at known location (ie not on the filesystem) so that the Nth page of the binary is at block OFFSET+N on the storage. Then you select threshold of how many code pages can live in the system memory and you put the constraint that all the data section must fit in RAM (ie these are not paged) 15.12.39 # essentially you page code and since you hardly need to have all of the code in RAM in a given context, you can greatly reduce RAM usage (I think) 15.13.27 # Now this is tricky because it means that pieces of the code can be paged out (apps/ mostly) but some not (firmware/ or at least all the parts necessary to read the storage) 15.14.36 # read the storage and manage paging :-) 15.14.45 # yeah :) 15.15.04 # is the flash memmaped or you need to fetch to ram first? 15.15.25 # I guess you could make it work with the firmware on the filesystem but 1) this is way more complicated 2) it needs all of the FS code unpaged too 15.15.25 # you need to fetch to ram, so this is kind of slow 15.16.05 # also all the interrupt code better be unpaged too 15.16.45 # Right, but this makes things a bit easier too. You need to put vm manager and storage driver in unpaged section 15.18.34 # to be honest, I have no idea how much ram you can win this way 15.18.50 # but this is not enough for atj found in the clip sport for example 15.19.51 # I treat it as purely academic discussion. Maybe 2MB targets could benefit but thats all 15.20.44 # I have no idea the OF works on those chips with <200kB of RAM 15.21.29 # pamaury: libc is in ROM, decoding is in hardware 15.21.45 # ah yeah, so basically the firmware does nothing 15.22.10 # pamaury: The memory is used mostly for (tiny) buffers I guess 16.05.00 Quit wodz (Quit: Leaving) 16.34.26 Join pablo_pi_ [0] (~pablo@190.148.249.124) 16.37.35 Quit pablo_pi (Ping timeout: 255 seconds) 16.42.44 *** Saving seen data "./dancer.seen" 16.44.55 Join pablo_pi [0] (~pablo@190.148.249.124) 16.47.38 Quit pablo_pi_ (Ping timeout: 252 seconds) 17.21.14 Quit zoktar (Ping timeout: 240 seconds) 17.23.20 Join zoktar [0] (~zoktar@78-72-45-32-no186.tbcn.telia.com) 17.23.20 Quit zoktar (Changing host) 17.23.20 Join zoktar [0] (~zoktar@unaffiliated/zoktar) 17.36.23 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 18.00.00 Quit alucryd (Remote host closed the connection) 18.30.43 Join pablo_pi_ [0] (~pablo@190.148.249.124) 18.34.01 Quit pablo_pi (Ping timeout: 260 seconds) 18.42.46 *** Saving seen data "./dancer.seen" 18.56.33 Join petur [0] (~petur@rockbox/developer/petur) 19.03.14 Quit Rondom (Remote host closed the connection) 19.13.54 Join alucryd [0] (~quassel@archlinux/developer/alucryd) 19.21.52 Quit alucryd (Remote host closed the connection) 19.23.27 Join alucryd [0] (~quassel@archlinux/developer/alucryd) 19.25.21 Quit alucryd (Remote host closed the connection) 19.27.05 Join alucryd [0] (~quassel@archlinux/developer/alucryd) 19.29.33 Quit pamaury (Ping timeout: 260 seconds) 19.31.24 Quit nosa-j (Ping timeout: 240 seconds) 19.35.05 Join lebellium [0] (~chatzilla@89-93-179-187.hfc.dyn.abo.bbox.fr) 19.46.37 Quit alucryd (Ping timeout: 240 seconds) 19.48.04 Join alucryd [0] (~quassel@archlinux/developer/alucryd) 19.57.10 Quit alucryd (Ping timeout: 264 seconds) 20.07.24 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 20.12.04 Quit zoktar (Quit: -) 20.14.50 Join alucryd [0] (~quassel@archlinux/developer/alucryd) 20.20.42 Join alucryd_ [0] (~quassel@archlinux/developer/alucryd) 20.21.55 Quit alucryd (Ping timeout: 256 seconds) 20.29.38 Quit alucryd_ (Ping timeout: 265 seconds) 20.38.00 Join alucryd [0] (~quassel@archlinux/developer/alucryd) 20.42.49 *** Saving seen data "./dancer.seen" 21.04.05 Join wodz [0] (~wodz@89-75-106-221.dynamic.chello.pl) 21.04.12 # pamaury: http://nuttx.org/doku.php?id=documentation:ondemandpaging 21.08.36 # this website seems slow as hell 21.10.44 # pamaury: nuttx is rtos which supports on demand paging 21.10.45 Join fs-bluebot_ [0] (~fs-bluebo@x5ce0edf7.dyn.telefonica.de) 21.10.49 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 21.10.56 # might be interesting to look how they did it 21.12.58 Quit fs-bluebot (Ping timeout: 255 seconds) 21.14.10 # wodz: i can't access the website 21.14.13 Quit bluebrother^ (Ping timeout: 260 seconds) 21.14.32 # pamaury: strange, I have no problem 21.15.13 # pamaury: try this http://webcache.googleusercontent.com/search?q=cache:mfj2keUkuJ4J:nuttx.org/doku.php%3Fid%3Ddocumentation:ondemandpaging+&cd=1&hl=en&ct=clnk&gl=pl&client=ubuntu 21.18.18 # now it works, strange 21.18.26 # yeah it's pretty much what I expected 21.19.14 # also there is this counter-intuitive thing that for best memory usage with on-demand paging, you probably want to allocate everything dynamically 21.20.33 # you mean to decreas .data section size? 21.20.36 # yes 21.20.52 # to not use memory for parts of the program that are inactive 21.21.14 # true, but this is HUGE departure from current code 21.22.27 # I know, that's why I was saying that doing on-demand paging is a huge change from the current code 21.22.34 # it's really like a new rockbox, litteraly 21.23.25 # also I'm not sure which threading model is best 21.23.59 # but I suspect cooperative threading is not the best either ^^ 21.25.47 # yeah, preemptive sounds like good fit for paging 21.29.44 # so let's restart rockbox from start, yeah \o/ 21.30.23 # how hard could it be anyway ? ;) 21.30.29 # *scratch 21.30.44 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) 21.32.41 Quit JdGordon (Ping timeout: 250 seconds) 21.36.23 # pamaury: A quick test - I built ipod video in thumb and .text is 0x694f0 bytes .data is 0x2d30 and .rodata is 0x234f8 21.36.44 # pamaury: .icode and .irodata are insignificant 21.37.35 # pamaury: of course there is also stack and .bss 21.37.59 # one of the problem here is the .data is missing several big bits: some buffers, allocated on start, audio buffer, plugin buffer 21.38.09 # screen buffer 21.38.44 # .bss is 0x77b90 bytes 21.38.54 # including COMMON 21.39.28 # that's huge 21.39.43 # isn't screen buffer static allocated? I am pretty sure it is 21.39.56 # yeah you are right, I didn't think about bss 21.40.18 # lcd_static_framebuffer is in COMMON 21.40.29 # but essentially bss is data, so that's around ~500kB of data 21.43.28 # so there is ~560kB of something which can be paged (.text + .rodata) 21.45.21 # doesn't look like worth effort 21.46.19 # no indeed, with the current code, paging wouldn't give us much because with a big data section and a not that big code one 21.46.46 # but that becomes an entirely different story if you can reduce the data section size 21.46.46 # amen 21.47.25 # ok, but this means writing os from scratch or at least HUGE rewrite 21.47.34 # yes :( 21.48.29 # I mean, the hardware part can probably be scavanged, I figure the codec one too (somehow). But everything else... 21.48.49 # considering available man hours this is no go 21.49.33 # on the other hand, that puts an entirely different perspective on the approach, like you may not want to write it in C 21.52.28 # and the rewrite would probably work much better on non-native platforms (android I'm looking at you) but yeah as for the manpower :-/ 22.01.23 Quit greatwolf (Remote host closed the connection) 22.15.14 # Considering embedded platforms the only alternative is very limited subset of C++. It is not that much win. 22.16.09 # on the contrary, you can now afford to have a lot of code (that's basically with paging) so you can use all the interesting C++ stuff like containers 22.16.26 # and C++ makes only sense when you have MMU really 22.16.32 # hiding all dynamic memory allocation, making memory management way simpler too 22.16.40 # on-demand paging requires mmu anyway 22.16.44 # true 22.18.02 Join rela [0] (~x@pdpc/supporter/active/rela) 22.19.56 # however, one could think about using a RTOS as the foundation, not everything would need to be rewritten from scratch 22.21.58 # Personally I don't like c++ on embedded exactly for this. It hides lots of things and relatively innocent looking code has huge impact on performance and memory usage. 22.23.15 # well you have to be careful, but with c you tend to write a lot of boilerplate, error prone, suboptimal-allocation-wise code 22.23.46 # anyway, that's not the main issue there 22.25.11 # One could start with nuttx and add drivers and codecs. The problem is withis 'one' exactly :-) 22.26.11 # one can do a lot of thing :) 22.29.27 # that would be interesting to try though, I mean hack nuttx, try to make it running on a device, just display a few things on the screen, to see how it goes 22.37.38 Quit wodz (Quit: Leaving) 22.42.51 *** Saving seen data "./dancer.seen" 22.55.24 Quit xorly (Ping timeout: 240 seconds) 22.57.12 Quit amayer (Quit: Leaving) 23.02.51 Join zoktar [0] (~zoktar@78-72-45-32-no186.tbcn.telia.com) 23.02.51 Quit zoktar (Changing host) 23.02.51 Join zoktar [0] (~zoktar@unaffiliated/zoktar) 23.08.58 Quit zoktar (Ping timeout: 246 seconds) 23.10.47 Join zoktar [0] (~zoktar@78.72.45.32) 23.10.47 Quit zoktar (Changing host) 23.10.47 Join zoktar [0] (~zoktar@unaffiliated/zoktar) 23.33.56 Quit petur (Remote host closed the connection) 23.47.33 Quit Smarticles101 (Quit: Um, bai!)