Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2015-10-08

00:00:12pamauryI think it would be better to somehow "post" the disconnect events to the thread
00:01:19wodzServer thread is actually separate process
00:01:36wodzBut generally I agree with you.
00:02:52pamauryah right, hum
00:03:33pamauryone way I see is to have a list of "pending deletion"
00:04:04pamauryand the event loop process the deletion before looking at the events
00:04:12pamauryand you need to protect this by mutexes
00:05:14pamauryor myabe simpler, if this is possible, have a boolean to say "something change" and on each change, poll each device to see if it's still connected (but I don't know if this information by the libusb API
00:08:50wodzBut change is caused by unplug. Nothing can save you.
00:09:25pamaurywhat do you mean ?
00:09:45pamauryI hope (and guess) that libusb will just fail if you send a request to a disconnect device
00:10:02pamaurythe problem is that if you free the device in the hotplug event and right after it, use in the thread...
00:10:22wodzah, you mean that it will segfault when callback frees the structure, hmm
00:10:50pamauryyeah the event loop will access a freed structure, and crash
00:11:23pamauryi mean this is theoretical but concurrency is always dangerous, you have to think about it long enough to be sure ;)
00:14:06wodzThere is other possibility. Instead of sharing dev_node_t between dev_list and reflist make it separate copies. Use only reflist one in 'client process'. If request fails check if global copy is still there - if not delete from reflist
00:15:34pamauryyeah should works too, I like this idea :)
00:16:24pamauryI think libusb has an error define for disconnected device
00:16:29pamaurylike LIBUSB_ERR_DISCONNECTED
00:17:23pamauryjust checked ;)
00:17:45wodzok so this should work then
00:19:09 Join jtdesigns01 [0] (~jonathan@2601:400:8000:2669:8534:77a1:38bf:4ff4)
00:19:44 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
00:34:42 Quit wodz (Quit: Leaving)
00:34:51 Quit ender` (Quit: Revised log levels proposal: "fyi," "wtf," and "omg.")
00:38:18***Saving seen data "./dancer.seen"
00:47:51[7]prof_wolfff: just saw your DMA patch
00:48:12[7]IIRC (and it's been quite a while ago), dma_get_peak_buffer is used by visualization plugins and that kind of thing
00:48:33[7]it's supposed to return audio data as close as possible to the current playback position
00:49:06[7]the name probably originates from a VU meter display on the archoses or something
01:03:39prof_wolfff7: i need to look closely to this function, IIRC the problem is that the internal double buffer are not consecutive positions, i think i leave it as it because didn't find a place where it is used and test it
01:04:25[7]I guess some plugins such as vu meter will use it
01:07:17 Quit pamaury (Ping timeout: 240 seconds)
01:09:29prof_wolfffi see it is used by pcm_calculate_peaks() but cannot find any utility using it, will see at the vu-meter more closely, IIRC i tried it in the past with no problems
01:16:00prof_wolfff7: ATM i am testing the vu-meter and it works (apparently) well, anyways i am adding to my TODO list to review the dma_get_peak_buffer() function, it should be used from somewhere...
01:17:36prof_wolfffor it could be related with SWCODEC
01:20:47 Join [Franklin] [0] (~franklin@unaffiliated/franklin)
01:23:37[Franklin]can someone merge g#1206 please?
01:23:47[Franklin]just a bug fix
01:25:13*foolsh wonders where our ircbot friend is at tonight?
01:25:54jtdesigns01ircbot friend?
01:26:14[Franklin]jtdesigns01: there's usually (sometimes?) a bot in here
01:26:22[Franklin]called fs-bluebot
01:26:24foolshyeah, it's real useful
01:26:46jtdesigns01he seems to come in and out
01:26:49jtdesigns01oh, i see
01:27:06foolshpost a gerrit task number i.e. g#1206 and it will post back useful info and links
01:27:13jtdesigns01for autocompleting " g#1206"
01:27:45foolshwhen a patch is merged it will give build farm stats to
01:28:21[Franklin]jtdesigns01: how's your SWDF plugin coming along?
01:28:56jtdesigns01still totally confused about the random "undefined instruction" errors
01:29:30[Franklin]try building it in the simulator to debug
01:29:40[Franklin]and if it doesn't build in the simulator, it's a bug! :P
01:30:04jtdesigns01i dont get any crashes in the simulator
01:30:18[Franklin]that's a start
01:30:41[Franklin]try putting some splash instructions at key points so you can narrow down where the crash is then
01:31:13foolshjtdesigns01: where is this? I'll build it to and see what comes of it
01:31:19*[Franklin] is too lazy to debug any other way
01:31:29foolshthere is no other way
01:31:50jtdesigns01 g#1215
01:32:49jtdesigns01you will have to remove the extra parentheses on line 19
01:33:35jtdesigns01i commited before saving. [[facepalm]]
01:33:54[Franklin]so commit again ;)
01:34:02foolshYou can push as many times as you need
01:34:35jtdesigns01open this file with it
01:34:47jtdesigns01(its a viewer)
01:35:12jtdesigns01(not the zip file, the file in it :D)
01:35:30[Franklin]speaking of which...
01:35:41*[Franklin] tossed around the idea of an archive viewer a while back
01:36:21foolshokey dokey
01:42:33foolshwell it builds so there is hope :)
01:46:25foolshjtdesigns01: so it flashes something about there being four files and then presents with me with a list SECBASE.(INF,GOL,LEV,O) but I can't seem to do anyhting else
01:47:11jtdesigns01yeah, just exit and retry a couple of times.
01:47:15foolshAh the third time I run it I get the undefined instruction so that's kind of wierd,
01:48:00foolshnot releasing some ram properly somewhere maybe?
01:49:16foolshis bm.h supposed to be blank?
01:50:01jtdesigns01its not fully implemented yet
01:50:19foolshyou don't say :P
01:50:29foolsh^ a joke
01:54:19foolshso what is the expected out put?
01:55:28jtdesigns01at this point it is only supposed to display the list and not crash :)
01:55:56jtdesigns01after i get the crash fixed, you will be able to click on the entries in the list and view them.
01:56:02*[Franklin] takes a look at it
01:56:46[Franklin]there might be a bug on line 19
01:57:06[Franklin]oh, never mind
01:57:27[Franklin]but you still shouldn't assume type sizes, ever
01:58:26jtdesigns01in my local copy i dont
01:58:32jtdesigns01will push
01:59:14jtdesigns01never mind, wont push, its too broken
01:59:31jtdesigns01too many unfinished changes that didnt work
02:01:08[Franklin]jtdesigns01: you're also allocating list_array on the stack
02:01:33[Franklin]that might not be a problem with mastern being small, but as it grows, it could become a problem
02:01:48[Franklin]the stack size is relatively small in rockbox, 4K IIRC
02:02:16jtdesigns01yeah it always dies immediately on huge files
02:02:25jtdesigns01just straight die
02:02:34jtdesigns01not undefined insatruction
02:02:42jtdesigns01but that is to be excpectyed
02:03:07jtdesigns01afk for a little bit will be back
02:06:29[Franklin]foolsh: I'll get the ducky code commented so it's a bit easier to understand
02:11:21[Franklin]and add some instructions while I'm at it...
02:23:17jtdesigns01ok, i`m back
02:23:23jtdesigns01find anything out?
02:23:26 Quit ps-auxw (Ping timeout: 246 seconds)
02:23:37*foolsh will get manual entry ironed out some time in the next week
02:23:46*foolsh is off to bed
02:24:04 Quit aevin (Ping timeout: 240 seconds)
02:24:04jtdesigns01see ya foolsh
02:25:05 Join aevin [0] (eivindsy@unaffiliated/aevin)
02:25:58[Franklin]\o foolsh
02:29:26 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs)
02:29:46 Quit uwe_ (Ping timeout: 255 seconds)
02:36:53 Join uwe_ [0] (
02:38:21***Saving seen data "./dancer.seen"
02:42:45jtdesigns01[Franklin]: is it possible that I could be somehow using up more ram each time i run my plugin?
02:43:10jtdesigns01because it often takes a couple of runs before it crashes
02:46:26[Franklin]try allocating globally and find out
02:46:31[Franklin]actually, never mind
02:46:37jtdesigns01allocating globally?
02:46:39[Franklin]that won't work because it's dynamically allocated
02:46:58[Franklin](place it in global scope so it's not on the stack)
02:47:09jtdesigns01i see
02:47:12[Franklin]it might be the dynamic alloc that's failing
02:47:30[Franklin]try writing a malloc function using the plugin buffer
02:47:56jtdesigns01that sounds... interesting
02:48:02*[Franklin] has one ready to use
02:48:09[Franklin]just let my pastebin it
02:48:47jtdesigns01oh, btw it never crashes before the list in my experience
02:49:24[Franklin]if that's the case, try narrowing it down more
02:49:40[Franklin]place splashes on every other line if you have to!
02:49:44jtdesigns01will do, gonna add some splashes
02:50:00jtdesigns01lol thx
02:50:50[Franklin]btw, here's a quick 'n dirty malloc:
02:53:51[Franklin]should be self-contained
02:54:56[Franklin]just remove the call to error()
03:26:52jtdesigns01[Franklin], when the error happens, it happens on the first call to synclist_draw
03:27:51[Franklin]every time?
03:28:12jtdesigns01pretty sure
03:28:29[Franklin]ok, dig deeper!
03:28:40jtdesigns01yep checking the get name cb now
03:29:07[Franklin]well, you declared a function inside a function
03:29:10*[Franklin] has never seen that before
03:30:05[Franklin]I don't think it's technically allowed
03:30:17[Franklin]so you probably shouldn't do it
03:30:34[Franklin]they're a GCC extension, it seems
03:32:51[Franklin]try moving it out to global or file scope and test it
03:38:52jtdesigns01that may actually have solved it
03:39:51jtdesigns01but now i have to rewrite more stuff out of the main function so that i can dynamically allocate the list_array
03:40:26jtdesigns01right now i`m just setting it to 200 long
03:44:45jtdesigns01time for bed now, thanks for the great suggestions
03:45:20jtdesigns01i will rewrite the necessary parts, and then push sometime tomorrow (hopefully)
03:45:34 Quit jtdesigns01 (Quit: Leaving)
03:51:30 Quit [Franklin] (Remote host closed the connection)
03:59:33 Quit JanC (Ping timeout: 240 seconds)
04:12:20 Join Strife89 [0] (
04:13:03 Join JanC [0] (~janc@lugwv/member/JanC)
04:13:12 Join goom [0] (
04:38:14 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon)
04:38:23***Saving seen data "./dancer.seen"
04:41:27 Quit JdGordon_ (Ping timeout: 250 seconds)
05:10:51 Quit prof_wolfff (Ping timeout: 244 seconds)
05:11:18 Join prof_wolfff [0] (
05:23:01 Quit djukon (Ping timeout: 272 seconds)
05:35:54 Quit [7] (Disconnected by services)
05:36:03 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
05:46:32 Quit FSanches (Quit: Leaving.)
05:49:50 Join djukon [0] (transitor@gateway/shell/insomnia247/x-dgrvbavwlvqswkvg)
05:51:12 Part djukon
06:04:11 Quit Strife89 (Ping timeout: 272 seconds)
06:07:51 Quit kvieta- (Excess Flood)
06:09:17 Join kvieta [0] (~kvieta@
06:38:24***Saving seen data "./dancer.seen"
07:13:25 Quit jtdesigns01bot (Ping timeout: 240 seconds)
07:20:20user890104prof_wolfff: /* iPod Classic: decrypted hashes for known OFs */
07:20:23user890104/* TODO?: v2.0.1 */
07:20:36user890104does this mean it won't install on 2.0.1?
07:20:49user890104my ipod classic 2g has this version
08:02:53 Quit goom (Quit: Leaving)
08:04:36 Join wodz [0] (
08:27:26 Quit pixelma (Remote host closed the connection)
08:27:26 Quit amiconn (Remote host closed the connection)
08:27:37 Join pixelma [0] (~pixelma@rockbox/staff/pixelma)
08:27:42 Join amiconn [0] (~amiconn@rockbox/developer/amiconn)
08:34:25 Join ender` [0] (
08:38:25***Saving seen data "./dancer.seen"
08:57:31 Join jtdesigns01bot [0] (
09:02:01 Join petur [0] (~petur@
09:02:01 Quit petur (Changing host)
09:02:01 Join petur [0] (~petur@rockbox/developer/petur)
09:34:01 Join fs-bluebot [0] (
09:40:28prof_wolfffuser890104: i was not sure if 2.0.1 was used by any device, but knowing that i will try to add the hash for 2.0.1 ASAP, i suppose i can use my devices (1G and 3G) to get it, it i can not get it i will ask you to try it on your 2G device
09:40:33 Join pedro_angelo [0] (~pedro_ang@
10:38:27***Saving seen data "./dancer.seen"
10:47:29 Join ztcptxm1bx [0] (~pedro_ang@
10:47:45 Quit ztcptxm1bx (Remote host closed the connection)
10:47:45 Quit pedro_angelo (Remote host closed the connection)
11:17:47 Quit Petri152 (Ping timeout: 264 seconds)
11:18:10 Join Petri152 [0] (
11:58:16 Join FSanches [0] (~felipe@2804:14c:37:268b:7409:d0db:e96a:3912)
12:15:13wodzpamaury: (log) I updated g#1222. There is still a lot to do but 1) I realized that fork() creates complete separate copy so global variables can't be shared between so I switched to pthreads and protected devlist with mutex. 2) I hit nasty limitation of hotplug support in libusb. You need to call libusb_handle_events_completed() periodically otherwise events are not passed down to the callback function.
12:15:24fs-bluebotGerrit review #1222 at : Extend hwstub_server so it can be used as generic backend by Marcin Bukat
12:16:09wodzpamaury: (log) I wonder how hotplug worked in qeditor. Maybe making other libusb calls is ok as well.
12:38:31***Saving seen data "./dancer.seen"
13:20:39 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
13:25:03pamaurywodz: you are right, I don't know how it works without calling libusb_handle_events_completed() regularly
13:26:53pamaurywodz: there is still too much code duplication, this is make it hard to check everything, now there that there is a lot of sync going on
13:29:41pamauryI need to review this code carefully
13:58:02wodzI agree, but I wanted to have logic in place before thinking how to refactor this
14:18:51 Join jtdesigns01 [0] (~jonathan@2601:400:8000:2669:44e0:9b5a:3db7:c548)
14:27:00 Quit FSanches (Excess Flood)
14:27:44 Join FSanches [0] (~felipe@2804:14c:37:268b:7409:d0db:e96a:3912)
14:36:17 Quit utrack (Ping timeout: 240 seconds)
14:38:33***Saving seen data "./dancer.seen"
14:39:36 Join utrack [0] (~u@unaffiliated/utrack)
14:56:20 Quit cmhobbs (Ping timeout: 255 seconds)
15:13:32 Join stickyb1t [0] (
15:20:14 Quit wodz (Quit: Leaving)
15:22:45 Quit stickyb1t (Ping timeout: 246 seconds)
15:23:41 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon)
15:26:56 Quit JdGordon (Ping timeout: 256 seconds)
15:39:06 Join amayer [0] (
15:57:21 Quit petur (Quit: Leaving)
16:36:11 Quit jtdesigns01 (Remote host closed the connection)
16:38:34***Saving seen data "./dancer.seen"
16:46:44 Join ZincAlloy [0] (
16:53:48 Quit [Saint] (Remote host closed the connection)
16:56:00 Join [Saint] [0] (~hayden@rockbox/staff/saint)
17:11:56 Join jtdesigns01 [0] (~Thunderbi@2601:400:8000:2669:b4fe:516a:6cd7:1d55)
18:04:53 Quit uber (Ping timeout: 265 seconds)
18:12:45 Join stickyb1t [0] (
18:17:44 Quit stickyb1t (Ping timeout: 240 seconds)
18:21:05 Join uber [0] (~uber@unaffiliated/uber)
18:38:37***Saving seen data "./dancer.seen"
18:41:10 Join stickyb1t [0] (
18:50:17 Join petur [0] (~petur@rockbox/developer/petur)
18:55:29 Quit stickyb1t (Ping timeout: 240 seconds)
19:06:03 Quit pamaury (Ping timeout: 246 seconds)
19:10:48 Join ps-auxw [0] (
19:20:26 Quit orly_owl (Quit: leaving)
19:22:01 Join orly_owl [0] (~david@unaffiliated/orly-owl/x-3167833)
19:22:24 Join krabador [0] (~krabador@unaffiliated/krabador)
19:33:37 Quit shamus (Read error: Connection reset by peer)
19:34:23 Join shamus [0] (
19:36:39 Quit shamus (Read error: Connection reset by peer)
19:37:04 Join shamus [0] (
19:55:27 Join stickyb1t [0] (
20:04:50 Quit stickyb1t (Quit: Konversation terminated!)
20:05:04 Join stickyb1t [0] (
20:06:52 Quit stickyb1t (Read error: Connection reset by peer)
20:38:40***Saving seen data "./dancer.seen"
20:39:47 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
20:48:03 Quit krabador (Quit: Take The Time)
20:57:54 Join lebellium [0] (
21:06:50 Join krabador [0] (~krabador@unaffiliated/krabador)
21:07:47 Quit bluebrother (Disconnected by services)
21:07:52 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
21:08:06 Join fs-bluebot_ [0] (
21:10:25 Quit fs-bluebot (Ping timeout: 250 seconds)
21:11:22 Join bp0 [0] (~bp@unaffiliated/bp0)
21:13:43 Quit krabador (Ping timeout: 256 seconds)
21:15:50 Join krabador [0] (~krabador@unaffiliated/krabador)
21:16:45 Quit bp0 (Quit: Leaving)
21:16:47 Join bertrik [0] (~quassel@rockbox/developer/bertrik)
21:24:53 Join o43 [0] (
21:45:46 Quit krabador (Quit: Take The Time)
21:54:45 Join krabador [0] (~krabador@unaffiliated/krabador)
22:11:31 Quit bertrik (Remote host closed the connection)
22:11:41 Quit o43 (Quit: Lost terminal)
22:30:42 Quit FSanches (Quit: Leaving.)
22:30:48[Saint]prof_wolfff: you around hun?
22:31:23[Saint]Sorry. Nevermind.
22:38:42***Saving seen data "./dancer.seen"
22:53:52 Join stickyb1t [0] (
22:54:34 Quit stickyb1t (Client Quit)
22:55:05 Join stickyb1t [0] (
22:56:44 Quit ender` (Quit: You do not need a parachute to skydive. You only need a parachute to skydive twice.)
23:07:56 Quit petur (Quit: Leaving)
23:26:31 Quit krabador (Quit: Take The Time)
23:30:17[Saint]Why is it that only the iriver H* have automatic gain control enabled?
23:30:47[Saint]Is this hardware dependent (it doesn't /appear/ to be...?
23:31:20pamaury[Saint]: no idea
23:32:02[Saint]This mess and confusion might be the kicker I need to finally do a proper target define template
23:32:38[Saint]the way we handle (or rather, the way we absolutely, completely, and totally do not handle...) defines in the source tree is rather annoying.
23:33:41pamaurywhich define controls AGC ?
23:33:57[Saint]just a brief look seems to suggest that there's several defines with very similar, or even identical functions, that could be condensed.
23:34:05[Saint]ummmm, HAVE_AGC
23:34:57[Saint]grep tells me that it's only actually used by the iriver H*
23:35:16[Saint]But, offhand, I can't seem to find any reason /why/ this is so.
23:35:56 Quit stickyb1t (Read error: Connection reset by peer)
23:36:12 Join stickyb1t [0] (
23:36:36 Quit stickyb1t (Client Quit)
23:37:08[Saint]Touching every single target config, and pretty much every area of the source, isn't ideal - and it's not necessarily something I /want/ to do...but I think it's high time that we had a nice template for new ports with nicely sectioned out defines.
23:37:56[Saint]Doing so would also give me a chance to clean them up and make sure they are applied in a uniform fashion.
23:38:58pamauryit is not unlikely that there is target specific code in recording.c
23:39:14[Saint]I might wrap a little ncurses UI around a script to generate target templates.
23:39:54[Saint]Is uniform and consistent target configs a thing that people might want? Or is it not worth stepping on everything for the sake of a little (a lot, really) more readability?
23:40:46[Saint]You can trace the source backwards in a few areas where cutting and pasting target define blocks has backfired on people.
23:44:13pamauryrather than a ncurses UI, I think the first work would be to have a template config with the list of ALL possible defines (which are not target specific of course) with a description of what it does
23:44:59pamauryit is also quite possible that some define are not independent and could be simplified but that's a major work I think
23:46:03[Saint]Ah, yes, I should probably stop assuming that people are aware of my thought process.
23:46:34[Saint]Yes. The aformentioned massive list of all possible defines is indeed a prerequisite of the ncurses wrapper I was thinking of.
23:47:46[Saint]If you get the time to look at this, even though I know it's not your particular area of expertise, it would be nice if someone could either confirm or deny my suspicion that there's no obvious good reason for automatic gain control to be disabled on everything except the irivers.
23:48:08[Saint]I understand that is a reasonably big ask, but I would sincerely appreciate it.
23:48:41[Saint]I can follow most of the code in recording.c, but there's a few blocks I'm not entirely sure of.
23:49:11 Quit amayer (Quit: Leaving)
23:49:19[Saint]tracking just HAVE_AGC gives me no reason to believe it should be hardware/device dependent.
23:50:47[Saint]It almost seems as though it was just entirely forgotten about.
23:51:23pamauryyeah, I was never aware there was AGC for recording ^^
23:51:34foolshHAVE_AGC isn't the most informative define
23:51:44[Saint]Nor was I until about ~10 minutes ago.
23:51:53pamauryI guess the trivial check is to try and add HAVE_AGC to a random target and see if it compiles/work
23:52:03*[Saint] nods
23:52:07[Saint]Doing that now. :)
23:53:57[Saint]I discovered this by accident adding a define for supplying a fake USB vendor/product ID for the iPods
23:54:08 Join [Franklin] [0] (~franklin@unaffiliated/franklin)
23:54:36*[Saint] knows how to define definite defines
23:54:40[Saint]#define USB_USE_ALTERNATE_VID_PID
23:54:48[Saint] one's going to ask what that does.
23:55:00 Quit lebellium (Quit: ChatZilla 0.9.92 [Firefox 42.0/20151005144425])
23:55:12[Saint](and, yes, I do realize that this is never going to make it into mainline)
23:55:36[Franklin]so what's the point then?
23:56:38[Saint]I've been supplying custom builds for ipod6g for an eternity. Just making life a bit easier on myself.
23:57:17[Saint]Essentially just to combat USB car audio and Apple Mac devices that are "too smart" for their own good.
23:57:24[Franklin]so there's no "generic" VID/PID combo out there?

Previous day | Next day