--- Log for 08.11.116 Server: karatkievich.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 month and 1 day ago 00.01.42 Part robertd1 00.05.51 Quit pamaury (Ping timeout: 244 seconds) 00.09.01 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll) 00.11.50 Quit krabador (Quit: Leaving) 00.13.34 Quit thrillho_ (Ping timeout: 252 seconds) 00.18.23 Quit ender` (Quit: XSLT is a failure wrapped in pain. There's no job for which XSLT is the right tool. If you think you found a job for which XSLT is a good tool, chances are the job itself is fucked up. — masklinn) 00.28.22 Join cryham_ [0] (~cryham@ip-94-42-235-87.multimo.pl) 00.30.35 # [Saint]: I tried to commit my new changes got a merge conflict I'm guessing because I didn't rebase first what do I need to do after the fact? 00.30.52 Quit cryham (Ping timeout: 245 seconds) 00.30.59 Nick cryham_ is now known as cryham (~cryham@ip-94-42-235-87.multimo.pl) 00.31.52 # <[Saint]> Do you have a diff of your changes saved? Be it externally or in git history? 00.32.42 # it'd be in git 00.32.44 # <[Saint]> You really shouldn't have gotten a merge conflict with this if you had a clean tree. My guess is unlrelated changes from an unclean state or a failed partial revert. 00.33.27 # I have a diff as well 00.34.56 Quit ZincAlloy1 (Quit: Leaving.) 00.36.29 Quit cc___ (Ping timeout: 250 seconds) 00.37.53 # <[Saint]> OK, so you _definitely_ have an external diff of your current change set? 00.38.34 # <[Saint]> If so, we can nuke the whole thing with absolute impunity. 00.38.39 # yes 00.39.17 # <[Saint]> We'll also work with branches this time, because developing in ~HEAD is...gross. 00.39.19 # <[Saint]> So: 00.39.21 # <[Saint]> 'git reset --hard origin/master' 00.39.52 # <[Saint]> 'git checkout -b dynamic_softlock' 00.40.13 # <[Saint]> 'patch -p1 < /path/to/diff.diff' 00.40.20 # <[Saint]> 'git add .' 00.40.26 # <[Saint]> 'git commit' 00.41.23 # <__builtin> ok, g#1413 is finalized, for the last time, I hope 00.41.25 # 3Gerrit review #1413 at http://gerrit.rockbox.org/r/1413 : 3XWorld: some fixes by Franklin Wei 00.42.44 # <[Saint]> Bilgus: and then we concentrate on getting it to Gerrit. 00.42.46 # <[Saint]> So: 00.43.09 # <[Saint]> 'git remote set-url --push origin ssh://Bilgus@gerrit.rockbox.org:29418/rockbox' 00.43.22 # <[Saint]> 'git push origin HEAD:refs/for/master' 00.43.53 # <[Saint]> and we're done, we know have committed staged local changes and pushed to the Gerrit ~REMOTE 00.44.01 # <[Saint]> s/know/now/ 00.44.57 # <[Saint]> NB: Replace 'Bilgus@gerrit.rockbox.org' with $YOUR_GERRIT_USER_NAME@gerrit.rockbox.org' 00.45.43 # thats it :) 00.46.02 # <[Saint]> AH, cool. Good guess, then. 00.46.09 # <[Saint]> You can just copy all that verbatim then. 00.46.28 # <[Saint]> sansa quotation, of course, but you'll figure that out one presumes. 00.46.32 # <[Saint]> *sans 00.46.40 Quit dfkt (Ping timeout: 244 seconds) 00.47.10 # ok so now what do I do with the failed one? 00.47.11 # <[Saint]> If Gerrit complains about you not being verified or authorized, please let me know. 00.47.36 # <[Saint]> I am assuming that you already have an ssh key generated and that the pubkey is already added to your Gerrit account. 00.47.45 # <[Saint]> If it is not, we need it to be. 00.48.04 # yeah its all up already 00.48.45 # http://gerrit.rockbox.org/r/#/c/1417/ 00.48.48 *** Saving seen data "./dancer.seen" 00.49.13 # <[Saint]> Ah, you mean it was up from a previous attempt, or it is up now as a result of this attempt? 00.49.16 # what do I do with this one though? >>http://gerrit.rockbox.org/r/#/c/1416/ 00.49.24 # This attempt 00.49.34 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll) 00.49.39 # <[Saint]> Right, shit, that would've been good to know. 00.49.50 # <[Saint]> I assumed, silly me. 00.50.36 # <[Saint]> We missed an opportunity to keep the original task - but, it isn't the end of the world. 00.51.02 # <[Saint]> If you're logged in to gerrit and you browse to that task you'll get an option to abandone the change set. 00.51.33 # k just wanted to be sure Thanks 00.51.43 # <[Saint]> For future reference, if this happens again, the thing Gerrit is interested in to associate changes with a patch set is the changid. 00.52.09 # <[Saint]> So the next time this happens, if there is one, copy the changeid from the previous patch set to the commit of the current patch set. 00.52.34 # <[Saint]> Then Gerrit will automatically add it as an iteration of that patch set instead of a new one. 00.53.04 # <[Saint]> The only concept of 'ownership' Gerrit has is $AUTHOR and $CHANGEID. 00.53.44 # AH ok I didn't realize we could copy it into a new commit 00.53.59 Quit thrillho_ (Ping timeout: 250 seconds) 00.54.25 # <[Saint]> With those set I could abduct your patch set for myself, or vice versa, right now. This is how it is possible for multiple people to work on one patch set, or for you/I to revive a patch set that needs to be rebased but the author has gone AWOL, etc. 00.55.13 # huh how do you do that without the ssh key? 00.55.40 # <[Saint]> The keys are not tied to any given patch set. 00.55.54 # <[Saint]> It is just to ensure that you're authorized to touch Gerrit, period. 00.56.18 # huh interesting 00.56.23 # <[Saint]> I just need *a* key that can be verified. I don't need *your* key. 00.57.00 # <[Saint]> All I need is at least seven digits of (or as many more as it takes to be unique) the changeid. 00.58.41 # <[Saint]> The only reason I would pass $AUTHOR is if I wanted to maintain the original authorship (which I like to do - but you can just outright 'steal' a patch set too without passing an author/email. 00.58.46 # Pretty cool, I saved your instructions for the next time FSM forbid I screw up 00.59.52 # <[Saint]> I take it you're familiar with https://www.rockbox.org/wiki/UsingGit ? 00.59.59 # <[Saint]> rockbox.org - Wiki > Main > UsingGit 01.00.45 # <[Saint]> If you want more overall familiarity with git as a whole: 01.00.46 # <[Saint]> http://gitref.org/ 01.00.54 # <[Saint]> gitref.org - Git Reference 01.01.28 # I've read through it several times now but didn't see anything about when you FSU 01.02.10 Join idonobm [0] (~idonob@S010610c37b922980.vs.shawcable.net) 01.02.29 # <[Saint]> That's tackled (albeit in a slightly different way to the (really aggressive) means I used in the FAQ on the UsingGit page. 01.02.33 Join idonobm_ [0] (~idonob@199-7-159-25.eng.wind.ca) 01.02.44 # I did the whole rebase thing but I guess I needed to git reset --hard origin/master instead 01.03.00 # <[Saint]> https://www.rockbox.org/wiki/UsingGit#Frequently_Asked_Questions 01.03.41 # <[Saint]> reset --hard origin/master is just a way of saying "reset this to the current state of the remote origin" 01.03.59 # I typically keep an origin and make a copy for each change and save patches into my "release" folder 01.04.21 # <[Saint]> but, for instance, you can also do "reset --hard HEAD~! to reset to the last commit in the local tree. 01.04.28 # <[Saint]> sorry, ~1 01.04.51 # <[Saint]> or ~2 to go back to local commits, etc. 01.04.58 # original* 01.05.18 # <[Saint]> Bilgus: yeah, that's kinda completely ignoring what a versioning system is actually for. 01.05.33 # <[Saint]> Understandable if you're not familiar with it though. 01.05.34 # yep :p 01.05.50 # <[Saint]> That's precisely what branches are for, which is why I elected to walk your through making one. 01.06.08 # <[Saint]> If you want to switch back to 'master' you would do 'git checkout master' 01.06.14 # much appreciated 01.06.42 Quit idonobm (Ping timeout: 260 seconds) 01.06.51 # <[Saint]> then rebase that or whatever if you want to, then if you want to work on dynamic_softlock again, checkout that branch. 01.07.08 # <[Saint]> you can create a (near) infinite amount of branches on any given tree. 01.07.12 # I will be sure to do that in the future its saved local though right? 01.07.25 # <[Saint]> I prefer to keep a distinct branch for each individual patch set. 01.07.47 # <[Saint]> Once you end up with a bunch of local changes stacked up it makes committing one specific patch set a pain in the tits. 01.07.57 # <[Saint]> Yes. It is saved locally. 01.08.19 # yeah putting a bunch of patches together 01.08.44 # been there already too 01.09.45 # <[Saint]> Though another way of handling this if you just want to make a quick change that doesn't warrant its own branch is to do 'git stash ; ; git stash pop' 01.10.14 # <[Saint]> you can also use git stash to rebase on top of staged (uncommitted) changes. 01.10.56 # <[Saint]> ala: 'git stash ; git pull --rebase ; git stash pop' 01.11.38 # <[Saint]> that will stash any unstaged changes, rebase to remote master, and then overlay your changes on top of the newly updated local HEAD of that branch. 01.12.22 # <[Saint]> If there are merge conflicts that arise during that, git will walk you through it with a dynamic/guided interface. 01.13.39 # that is what I tried before I asked for help but since I already committed it wouldn't allow me to re-commit 01.14.19 # <[Saint]> Ah, right. 01.15.00 # <[Saint]> Yeah that (push/pop) only really works elegantly with unstaged changes. 01.16.25 # <[Saint]> And if it helps at all - Don't feel any type of ways about fucking this up. There isn't a single person in this room that hasn't managed to butcher their local tree/branch so badly that they just took the "ahhhh fuck it" approach and nuked it from orbit. 01.16.33 # <[Saint]> I absolutely guarantee that. 01.16.49 # <[Saint]> There is absolutely nothing about git and/or Gerrit that is obvious or user friendly. 01.18.09 # <[Saint]> It is a very powerful tool. With that great power comes the ability to do very elegant and useful things, or screw up and trash your work - bonus points if you manage to screw it up so bad that you toast the reflog and make everything totally unrecoverable. 01.18.23 # <[Saint]> I have lost count of the number of times I have done this. 01.19.16 # <[Saint]> _In theory_ everything you do in git is 100% reversible as long as the reflog is intact, but sometimes it is just plain easier to dowse it all in gasoline and strike a match. 01.19.58 # <[Saint]> There's no shame to be had in this. I assure you ever developer here, of every level of competence, has done so. 01.23.20 Join gluytium [0] (~g@45.63.76.107) 01.29.31 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll) 01.32.01 # * Bilgus has little to no shame 01.34.19 Quit thrillho_ (Ping timeout: 260 seconds) 01.39.11 Join Harbec [0] (Harbec@dsl-152-37.b2b2c.ca) 01.40.08 # hi, yesterday I installed rockbox on an ipod classic 6th generation 01.50.03 Quit idonobm_ (Ping timeout: 256 seconds) 02.01.38 Join ruhans [0] (uid76353@gateway/web/irccloud.com/x-luoclzmcifekxmar) 02.01.45 Join fxharbec [0] (~Harbec@mtrlpq4613w-lp130-02-70-50-150-174.dsl.bell.ca) 02.02.20 # is there a way to connect my ipod in my car and have it working and display on screen? 02.03.32 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll) 02.03.56 Quit Harbec (Ping timeout: 252 seconds) 02.07.58 Quit thrillho_ (Ping timeout: 252 seconds) 02.11.35 Quit Rower (Ping timeout: 256 seconds) 02.19.58 Quit girafe (Read error: Connection reset by peer) 02.24.38 Quit krnlyng (Ping timeout: 260 seconds) 02.30.10 # <__builtin> fxharbec: are you talking about display mirroring? 02.36.34 Join krnlyng [0] (~liar@77.117.23.116.wireless.dyn.drei.com) 02.42.58 Quit soap (Read error: Connection reset by peer) 02.43.23 Join soap [0] (~soap@rockbox/staff/soap) 02.43.43 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll) 02.48.22 Quit thrillho_ (Ping timeout: 245 seconds) 02.48.50 *** Saving seen data "./dancer.seen" 02.57.38 # <__builtin> the profiling option appears to be broken 02.57.42 # <__builtin> at least in the plugin api 02.57.54 # <__builtin> rockbox/apps/plugin.c:555: error: ‘profile_thread’ undeclared here (not in a function) 02.58.32 # <[Saint]> In a sim or SDl build, or on-target? 02.58.46 # <__builtin> on-target 02.58.50 # <[Saint]> The former wouldn't surprise me at all. 02.59.07 # <[Saint]> The latter doesn't surprise me too much assuming you're talking about the Classic. 03.00.09 # <[Saint]> As you may well know there was quite a lot of stuff in that build that wasn't implemented despite there being no real barrier to it. 03.00.20 # <__builtin> it appears to be declared in firmware/kernel/thread-common.c 03.01.27 # <__builtin> so, how would I get it to work? 03.01.42 # <__builtin> is profiling specific to the target? 03.02.38 # <[Saint]> IIUC, "kindof". 03.03.03 # <[Saint]> It's kinda like how a logf build doesn't really do fuck all without sprinkling logf functions around where you want them. 03.03.32 # <[Saint]> That's my understanding of it at least. 03.10.23 # <__builtin> alright, so it should work in a sim, right? 03.10.48 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll) 03.16.45 Quit thrillho_ (Ping timeout: 256 seconds) 03.16.52 # <__builtin> well apparently now 03.16.54 # <__builtin> *not 03.32.10 # Car Ipod USB - I get an error message plugging my rockbox (model ipod classic 6th generation) in usb plug 03.42.37 Join krabador [0] (~krabador@unaffiliated/krabador) 03.43.59 Quit fxharbec () 03.46.49 # <__builtin> that's probably using IAP then 03.46.58 # * __builtin isn't too clear about the extent of rockbox's IAP support 03.50.09 Join idonobm [0] (~idonob@S010610c37b922980.vs.shawcable.net) 03.51.22 Quit krabador (Quit: Leaving) 03.51.44 # <__builtin> does anyone else know about this? 03.52.00 # <__builtin> [Saint]? 03.55.48 # <__builtin> hmm, it looks like there is some code for it in the tree 04.19.25 Join Saratoga_ [0] (32b117cb@gateway/web/freenode/ip.50.177.23.203) 04.20.30 # It's not possible to communicate with an iPod over usb using any of the apple accessory protocols, they're are encrypted and as far as I know the keys have not been extracted 04.20.52 # Only the unsecured serial port interface works 04.21.02 # Which isn't over usb 04.21.12 Quit Saratoga_ (Client Quit) 04.21.44 # All: anything already defined to grab the current context? WPS FM etc? 04.22.17 # Looks to me like main calls the individual contexts which return them as needed 04.48.51 *** Saving seen data "./dancer.seen" 04.53.24 Quit igitoor (Ping timeout: 260 seconds) 04.54.32 Join igitoor [0] (igitur@2a00:d880:3:1::c1ca:a648) 04.54.57 Quit Ivoah (Quit: Connection closed for inactivity) 05.00.36 Quit igitoor (Ping timeout: 260 seconds) 05.01.26 Join igitoor [0] (igitur@2a00:d880:3:1::c1ca:a648) 05.15.55 Quit igitoor (Changing host) 05.15.55 Join igitoor [0] (igitur@unaffiliated/contempt) 05.17.59 Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) 05.50.11 Join Ivoah [0] (uid49352@gateway/web/irccloud.com/x-olrstshcbicvucrq) 06.15.50 Join advcomp2019_ [0] (~advcomp20@65-131-157-74.sxct.qwest.net) 06.15.50 Quit advcomp2019_ (Changing host) 06.15.50 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) 06.16.54 Quit TheSeven (Disconnected by services) 06.17.03 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 06.17.08 Quit toehser (Ping timeout: 260 seconds) 06.17.34 Join toehser [0] (~tom@Connqueror.Toms.NET) 06.18.04 Quit advcomp2019 (Ping timeout: 260 seconds) 06.30.24 # Got that worked out 06.30.49 # anyone know how keymaps are loaded for each target? 06.48.54 *** Saving seen data "./dancer.seen" 06.52.42 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 06.55.13 Quit dfkt (Client Quit) 06.55.51 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 07.01.48 Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) 08.02.26 Join wodz [0] (~wodz@94-75-75-29.home.aster.pl) 08.19.14 Join ender` [0] (krneki@foo.eternallybored.org) 08.29.35 Quit pixelma_ (Quit: .) 08.29.35 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 08.31.59 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 08.32.02 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 08.39.06 # Build Server message: 3New build round started. Revision f2da975, 255 builds, 13 clients. 08.41.45 Join petur [0] (~petur@rockbox/developer/petur) 08.45.55 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 08.48.58 *** Saving seen data "./dancer.seen" 08.51.04 # Build Server message: 3Build round completed after 718 seconds. 08.51.05 # Build Server message: 3Revision f2da975 result: All green 08.59.35 # wodz: so hwstub is working with polling instead of irq ? 09.00.06 Quit alexweissman (Ping timeout: 252 seconds) 09.06.36 Quit pamaury (Ping timeout: 240 seconds) 09.18.34 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 09.57.38 Join elensil [0] (~edhelas@2001:1c02:1903:d800:9c3b:f83c:8a2b:ca7) 10.12.47 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.13.06 # pamaury: yes, reverting this commit restored working stub. 10.14.09 # Bilgus: keymaps are in apps/keymaps 10.14.15 # pamaury: I have a feeling I committed this rework from wrong branch. 10.14.39 # so you have a working irq version in another branch? 10.15.11 # I figured that out a few hours ago found the fun pointer to the static array 10.16.33 # I'm ready for bed at this point, the issue I have with context sensitive backlighting is the backlight is done in button.c which is lower in the chain than action.c 10.16.48 # I don't if the current wps context is stored somewhere or if the get_action_* function just don't take a current context parameter. I haven't looked at that in a long time 10.17.21 # it might be possible to have a function in the button driver to register a filter 10.17.41 # so that apps/ can tell firmware/ whether it wants backlight or not 10.17.57 # now I can block the backlight in button.c for the desired contexts but the filtering for the actions is painful at best 10.19.21 # I used get_action to store the current context and exposed it in another function that works fine 10.19.51 # registering a filter sounds interesting 10.20.08 # Bilgus: as a rule, code in firmware/ can never EVER call a function in apps/ 10.20.29 # the only way apps/ can talk to firmware/ is by registering a function 10.20.50 # (think of apps/ as userspace and firmware/ as kernel) 10.20.50 # good to know 10.22.19 # so first i guess will be an event for the current context? 10.23.56 # what is the registration mechnism? 10.31.54 # you have to create it, something like: 10.31.54 # void backlight_register_button_func(bool (*function)(int btn)); 10.31.54 # and the function given in parameter is called when on every button action to know if it should trigger backlight or not. Maybe it could/should be more generic and return on/off/don't change. But you get the idea 10.33.54 # EVENT_CLASS_BACKLIGHT 10.35.43 # that's a different thing 10.36.47 # event classes are for messages broadcasted to the system, mostly to tell them something important happened 10.37.17 # like "external storage was mounted" or "usb was plugged" 10.39.27 # oh ok so then you pass a pointer to the function that is in apps then? 10.40.19 # yeah 10.40.49 # ok so a callback then 10.40.51 # unless someone suggests a better approach 10.45.45 # ok good enough I mull on that for a bit and see what I come Thanks 10.45.56 Quit Bilgus (Quit: ciao) 10.47.29 # Does anyone remember the policy on removing forum accounts if users ask that? 10.49.00 *** Saving seen data "./dancer.seen" 10.51.07 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll) 11.04.50 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:a914:3fed:cc40:dc0e) 11.13.01 # gevaerts: does that need a policy? 11.14.49 # pamaury: Since I remember having irq version working it must be somewhere :-) 11.17.13 # pamaury: maybe not. In the current case the user has posted in one thread back in 2007, so probably not even historical significance. I'd say we don't just delete *posts* though without a good reason 11.18.32 # does deleting a users deletes its posts? 11.19.13 # Not necessarily. I get asked if I want to do that 11.19.36 # If not, the username is still shown but you can't easily search by user anymore on those posts 11.24.30 # then I guess it's not problem to delete a user 11.33.14 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) 11.50.31 Join robertd1 [0] (~as@201.208.225.40) 11.57.35 # pamaury: I've done it now. I suspect the best policy is to think about it first :) 11.57.41 # It doesn't happen very often anyway 12.03.27 Quit idonob (Ping timeout: 268 seconds) 12.20.27 Join idonob [0] (~Owner@S010610c37b922980.vs.shawcable.net) 12.32.22 Quit shamus (Read error: Connection reset by peer) 12.43.28 Join idonobm_ [0] (~idonob@199.119.235.179) 12.44.10 Quit thrillho_ (Ping timeout: 246 seconds) 12.45.39 Quit idonobm (Ping timeout: 248 seconds) 12.49.02 *** Saving seen data "./dancer.seen" 12.54.42 Join JanC_ [0] (~janc@lugwv/member/JanC) 12.55.57 Quit JanC (Killed (wilhelm.freenode.net (Nickname regained by services))) 12.55.57 Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) 12.59.25 Join Senji [0] (~Senji@212-5-158-45.ip.btc-net.bg) 13.03.31 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll) 13.04.45 Quit Senji (Read error: Connection reset by peer) 13.08.34 # pamaury, gevaerts: Can you look at #1389 and tell me why dsp_process() crashes in simulator (differently depending on which threading model is used)? pcm_output.c is slightly tweaked version form mpegplayer. 13.11.11 Quit idonobm_ (Ping timeout: 244 seconds) 13.12.14 Join Senji [0] (~Senji@212-5-158-45.ip.btc-net.bg) 13.22.41 # wodz: I'll have a look tonigt, although my knowledge of dsp stuff is zero 13.27.04 # pamaury_: I am pretty sure it is not dsp stuff by itself. It is some sort of memory corruption somewhere. 13.34.23 Join AndyP [0] (a5e150a4@gateway/web/freenode/ip.165.225.80.164) 13.34.46 Nick AndyP is now known as Guest92337 (a5e150a4@gateway/web/freenode/ip.165.225.80.164) 13.36.09 # On the point of IAP support, IAP over serial is well supported and most commands work. IAP over USB is NOT supported yet..... 13.36.38 Part Guest92337 13.38.10 Quit ZincAlloy (Quit: Leaving.) 14.00.34 Join shamus [0] (~shmaus@ip-206-192-195-210.marylandheights.ip.cablemo.net) 14.04.31 Quit Moarc (Remote host closed the connection) 14.15.39 Join Moarc [0] (~chujko@a105.net128.okay.pl) 14.26.06 Quit thrillho_ (Ping timeout: 256 seconds) 14.34.28 Join Senji_ [0] (~Senji@212-5-158-45.ip.btc-net.bg) 14.35.39 Quit Senji (Read error: Connection reset by peer) 14.41.06 Quit Senji_ (Ping timeout: 252 seconds) 14.49.03 *** Saving seen data "./dancer.seen" 15.06.05 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll) 15.17.32 Join idonobm [0] (~idonob@199.119.235.179) 15.31.19 Join anr_ [0] (5dbc8f01@gateway/web/freenode/ip.93.188.143.1) 15.31.33 Join TheLemonMan [0] (~root@unaffiliated/thelemonman) 15.32.17 # hi all, new here,i'm leaving in two hours, will read all tomorrow morning (GMT) 15.32.58 # i've been a happy user of rockbox for years (ipod, now sansa clip), recently got a FIIO X1 II, and happily read there is some interesting in porting to it 15.33.41 # i can code in c, being fluent in asm (x86 but can read other micros), and being using IDA for years 15.34.00 # I am here to offer my help in whatever it's needed, pcb scans? etc... 15.34.07 # If i can help in anything just tip me 15.34.10 # thanks all!!! 16.01.13 Quit wodz (Quit: Leaving) 16.04.24 Join paulk-minnie [0] (~paulk@147.210.204.186) 16.18.32 Join Bilgus [0] (ae6611d9@gateway/web/freenode/ip.174.102.17.217) 16.23.06 # figure out the jz4760b maybe? 16.23.16 # there's a linux patch forit 16.32.39 Quit shamus (Read error: Connection reset by peer) 16.42.15 Join krabador [0] (~krabador@unaffiliated/krabador) 16.47.25 Quit paulk-minnie (Quit: Leaving) 16.47.41 # sth: I am working on it. PCB scan would be useful, since we don't have them 16.47.53 # (I don't have the X1II, just the X1) 16.49.04 *** Saving seen data "./dancer.seen" 16.49.12 # also it would be useful to figure out how exactly the device boots. We know it uses linux, which I guess means u-boot. Fiio has not probably the source as of now, so we need to figure out a clean way to dual-boot 16.49.29 # s/probably/provided 16.49.57 # anr_: ^ 16.50.01 # sorry wrong person 16.59.09 Quit alexweissman (Remote host closed the connection) 17.14.29 Join idonobm_ [0] (~idonob@199-7-159-123.eng.wind.ca) 17.15.35 Quit idonobm (Ping timeout: 260 seconds) 17.16.52 Join paulk-collins [0] (~paulk@gagarine.paulk.fr) 17.18.23 Join idonobm [0] (~idonob@199.119.235.240) 17.20.36 Quit petur (Quit: Connection reset by beer) 17.20.58 Quit idonobm_ (Ping timeout: 252 seconds) 17.25.45 Quit pamaury (Remote host closed the connection) 17.29.15 Quit pamaury_ (Ping timeout: 240 seconds) 17.31.18 Quit JanC (Remote host closed the connection) 17.33.27 Join JanC [0] (~janc@lugwv/member/JanC) 17.37.46 Quit JanC (Remote host closed the connection) 17.38.16 Join JanC [0] (~janc@lugwv/member/JanC) 17.49.34 Join alexweissman [0] (~alexweiss@2001-18e8-2-28cc-f000-43c.dhcp6-bl.indiana.edu) 17.50.39 Quit paulk-collins (Remote host closed the connection) 17.54.04 Join paulk-collins [0] (~paulk@gagarine.paulk.fr) 18.07.55 *** Invited to ##openbroadcastsystems by funman!~fun@rockbox/developer/funman 18.08.12 *** Invited to ##openbroadcastsystems by funman!~fun@rockbox/developer/funman 18.11.18 Join idonobm_ [0] (~idonob@199.119.235.183) 18.12.18 Quit idonobm (Ping timeout: 252 seconds) 18.25.08 Quit thrillho_ (Ping timeout: 252 seconds) 18.25.21 Quit rela_ (Quit: Leaving) 18.29.28 Join rela [0] (~x@pdpc/supporter/active/rela) 18.35.11 # <__builtin> hmm, this is tricky 18.35.35 # * __builtin is trying to rewrite a PCM callback to just return a premixed buffer 18.36.02 # <__builtin> but writing the thread that populates that buffer requires sub-HZ timing 18.36.43 # <__builtin> at least with the buffer sizes I'm dealing with now 18.41.37 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:615a:fd77:b7ba:f8a6) 18.43.49 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) 18.45.05 Quit alexweissman (Remote host closed the connection) 18.49.06 *** Saving seen data "./dancer.seen" 18.53.17 Join alexweissman [0] (~alexweiss@2001-18e8-2-28cc-f000-43c.dhcp6-bl.indiana.edu) 18.53.52 # <__builtin> hmm I guess there's an issue if the IRQ is called while the mixer thread has a lock on the buffer 18.54.03 # <__builtin> and that'd lead to deadlock there 18.54.04 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll) 18.58.56 Join girafe [0] (~girafe@LFbn-1-8015-136.w90-112.abo.wanadoo.fr) 19.17.01 Join idonobm [0] (~idonob@199.119.235.196) 19.19.37 Quit idonobm_ (Ping timeout: 245 seconds) 19.23.55 Join thrillho [0] (~Luke@unaffiliated/rockandorroll) 19.26.47 Quit thrillho_ (Ping timeout: 250 seconds) 19.42.33 Join wodz [0] (~wodz@89-77-223-98.dynamic.chello.pl) 19.43.35 # __builtin: I don't know the architecture of xworld but if you produce sound in thread it doesn't need to be in small chunks. 19.44.13 # <__builtin> alright 19.44.34 Join chrisb [0] (~chrisb@pool-71-175-250-124.phlapa.east.verizon.net) 19.54.42 Quit alexweissman (Remote host closed the connection) 19.55.43 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 19.57.09 Join idonobm_ [0] (~idonob@199.119.235.139) 19.59.21 Quit idonobm (Ping timeout: 244 seconds) 20.05.14 Quit wodz (Ping timeout: 252 seconds) 20.05.15 Quit thrillho (Ping timeout: 240 seconds) 20.16.53 Quit JanC (Remote host closed the connection) 20.17.31 Join wodz [0] (~wodz@89-77-223-98.dynamic.chello.pl) 20.17.42 # __builtin: What governs time in xworld? 20.18.41 Join JanC [0] (~janc@lugwv/member/JanC) 20.23.23 Join lebellium [0] (~chatzilla@89-93-177-91.hfc.dyn.abo.bbox.fr) 20.23.38 Quit idonobm_ (Quit: Bye) 20.24.56 Join smoke_fumus [0] (~smoke_fum@leased-line-195-222-90-170.telecom.by) 20.27.32 # <__builtin> what do you mean? 20.30.35 # wodz: did you manage to build some sony nwz in the end? 20.30.55 # pamaury: build? 20.31.01 # buy ;) 20.31.13 # I guess building them will be hard :-p 20.31.44 Join alexweissman [0] (~alexweiss@149-160-182-203.dhcp-bl.indiana.edu) 20.32.10 # pamaury: yes, nwz-e474 (probably). My wife picked it up today 20.32.38 # __builtin: I mean what makes timing in xworld vm? 20.36.46 # <__builtin> wodz: the bytecode specifies how long to display a frame for 20.37.08 # <__builtin> and the vm sleeps for that long, minus the cycle delay 20.37.57 # __builtin: How is music produced and synced to frames then? 20.38.35 # pamaury: going back to Paris for vacations for 2 weeks. Should I take the A850 with me or you need more time before having something to test? 20.39.08 # lebellium: take it, I might send you stuff ;) 20.39.27 # you'll still be on irc? 20.41.08 # schedule is bumming around all day long and drinking beers every night 20.41.16 # :D 20.41.21 # my hope is to have working bootloader and rockbox without sound by the end of the week 20.41.24 # so I can be on IRC during the day 20.41.34 # ok great 20.47.55 # pamaury: I should be able to test something on this e474 considering it is 474 which I will verify on friday probably. 20.48.22 Join petur [0] (~petur@rockbox/developer/petur) 20.49.07 *** Saving seen data "./dancer.seen" 20.49.13 # ok 20.49.53 # I have almost finished my database on the various players, which should help me write this bootloader 20.50.03 # I am still unsure about how to compile the bootloader 20.50.26 # currently it is in directory in utils/ but in the long run, we need to build it using the build system I think 20.55.39 # pamaury: did you have time to look at g#1389 ? 20.55.40 # 3Gerrit review #1389 at http://gerrit.rockbox.org/r/1389 : 3Port of picoTTS by Marcin Bukat 20.56.34 # no 20.57.03 # what exactly should I look at? 20.57.26 # ah yeah the dsp stuff 20.58.02 # pamaury: As I said dsp stuff is IMO side effect as where this plugin crashes depends on threading mode used. 20.59.35 # <__builtin> wodz: well, the bytecode tells the mixer what it wants to play 20.59.44 # <__builtin> and then the mixer mixes the channels on-demand 21.00.39 # pamaury: In simulator with default threads it crashes in first call of dsp_process(). With sdl threads it produce 2MB+ of samples correctly and then suddenly freezes. 21.00.40 Quit alexweissman (Remote host closed the connection) 21.02.21 Join q3cpma [0] (~hadrien@AAubervilliers-651-1-296-208.w83-114.abo.wanadoo.fr) 21.03.16 # Hello, does anyone know if the native Opus gain tags (R128_*) are used by Rockbox? Or should i just transfer the Replaygain from the original files? 21.17.42 # q3cpma: no idea, hopefully someone who knows will answer 21.20.16 # pamaury: Okay. By the way, is there a real difference in power usage between Vorbis and Musepack (using git on a Sansa Clip+/Fuze+)? Seems like vorbis got quite fast in rockbox. 21.23.41 Join saratoga_ [0] (123e13c2@gateway/web/freenode/ip.18.62.19.194) 21.24.05 # q3cpma: https://www.rockbox.org/wiki/CodecPerformanceComparison 21.27.12 # saratoga_: I've seen this page. But I don't know how to map CPU frequency and power usage (voltage?). Since Musepack seems like a pain to use (ffmpeg doesn't support encoding and mpcenc discard all tags during conversion) 21.28.05 # I think I'll use Vorbis. Opus has a meaningfully higher power draw 21.28.13 # from your point of view, power consumption is frequency 21.31.35 Quit wodz (Ping timeout: 240 seconds) 21.31.53 # saratoga_: You mean it's linear? 21.32.24 # it's very nonlinear 21.32.33 # saratoga_: Like double the frequency means double the power draw? (without couting the screen backlight) 21.34.27 # saratoga_: usually frequency scaling involves voltage scaling, and power is typically f*V^2 21.34.38 # err q3cpma 21.35.01 Join alexweissman [0] (~alexweiss@149-160-182-203.dhcp-bl.indiana.edu) 21.35.28 # its not linear, theres fixed consumption just for being on, and all sorts of other things change as well 21.35.35 # pamaury: I see. But does voltage scale linearly with frequency? (in the voltage scaling implementation) 21.35.38 # but if you want to figure out what uses more, hten you just care about frequency 21.35.53 # saratoga_: Yeah, that why I said without the screen (which is the biggest consumer) 21.36.41 # q3cpma: no, but to give on an example on imx233: 21.37.06 # at 64MHz, voltage is 1.05V, at 400MHz, voltage is 1.55V 21.38.42 # I thought it was something like this (asymptotic). 21.42.26 Quit cc___ (Ping timeout: 256 seconds) 21.55.30 Quit alexweissman (Remote host closed the connection) 21.59.53 Join wodz [0] (~wodz@89-77-223-98.dynamic.chello.pl) 22.01.38 Part q3cpma 22.13.05 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") 22.17.29 Quit wodz (Quit: Leaving) 22.23.55 Join thrillho [0] (~Luke@unaffiliated/rockandorroll) 22.28.44 Quit thrillho (Ping timeout: 268 seconds) 22.49.08 *** Saving seen data "./dancer.seen" 22.49.19 Join thrillho [0] (~Luke@unaffiliated/rockandorroll) 22.49.39 Quit saratoga_ (Ping timeout: 260 seconds) 22.53.50 Quit thrillho (Ping timeout: 256 seconds) 22.58.46 Quit lebellium (Quit: ChatZilla 0.9.92 [Firefox 49.0.2/20161019084923]) 23.06.03 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 23.09.38 Join alexweis_ [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 23.09.55 Quit paulk-collins (Remote host closed the connection) 23.10.30 Quit alexweissman (Ping timeout: 244 seconds) 23.13.09 Join thrillho [0] (~Luke@unaffiliated/rockandorroll) 23.13.34 Quit anr_ (Ping timeout: 260 seconds) 23.14.31 Quit pamaury (Ping timeout: 246 seconds) 23.15.23 Quit ender` (Quit: The problem with political jokes is they get elected. — Henry Cate, VII) 23.17.40 Quit thrillho (Ping timeout: 246 seconds) 23.37.28 Part robertd1 23.53.29 Join thrillho [0] (~Luke@unaffiliated/rockandorroll) 23.58.02 Quit thrillho (Ping timeout: 244 seconds)