00:13:03 | fs-bluebot_ | Build Server message: New build round started. Revision 90c30bc, 282 builds, 10 clients. |
00:13:28 | speachy | okay, click on startup and most of the runtime pops gone too. |
00:13:59 | speachy | basically by switching the output away from the audio jacks when we're not actually playing anything. |
00:21:42 | _bilgus__ | nice |
00:32:41 | *** | Saving seen data "./dancer.seen" |
00:48:54 | fs-bluebot_ | Build Server message: Build round completed after 2152 seconds. |
00:48:56 | fs-bluebot_ | Build Server message: Revision 90c30bc result: All green |
00:48:57 | fs-bluebot_ | Build Server message: New build round started. Revision 1824f8b, 282 builds, 10 clients. |
01:00 |
01:05:19 | | Quit ac_laptop (Ping timeout: 246 seconds) |
01:10:11 | fs-bluebot_ | Build Server message: Build round completed after 1275 seconds. |
01:10:12 | fs-bluebot_ | Build Server message: Revision 1824f8b result: 0 errors 4 warnings |
02:00 |
02:32:25 | | Quit t0mato (Ping timeout: 240 seconds) |
02:32:44 | *** | Saving seen data "./dancer.seen" |
02:41:17 | | Join johnb5 [0] (~johnb2@p5b3af96a.dip0.t-ipconnect.de) |
02:45:42 | | Quit _bilgus__ (Ping timeout: 260 seconds) |
02:51:07 | | Join _bilgus__ [0] (~bilgus@65.186.35.190) |
03:00 |
03:18:42 | johnb5 | speachy : x3ii: when you pause a song, after ~3s I hear sound (similar to other players when you turn them off). It's not hurting your ears, but I feel it's new. |
03:18:56 | johnb5 | *hear a sound |
03:22:46 | | Join livvy [0] (~livvy@gateway/tor-sasl/livvy) |
03:23:10 | johnb5 | and when you have paused for > 3s, un-pause takes ~2s for the audio to resume. |
03:23:48 | johnb5 | fade-in/-out is switched off. |
03:26:13 | | Quit kugel (Ping timeout: 260 seconds) |
03:29:40 | | Join kugel [0] (~kugel@ip5b40d8e6.dynamic.kabel-deutschland.de) |
03:29:40 | | Quit kugel (Changing host) |
03:29:40 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
03:29:54 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
03:29:54 | | Quit pixelma (Quit: .) |
03:32:48 | | Join pixelma [0] (marianne@rockbox/staff/pixelma) |
03:33:29 | | Join amiconn [0] (~jens@rockbox/developer/amiconn) |
03:36:25 | johnb5 | That sound ("thump") is only on HP, not line-out (at least there I cannot hear it with my setup). |
03:48:17 | | Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) |
04:00 |
04:19:46 | | Quit johnb5 (Ping timeout: 256 seconds) |
04:32:45 | *** | Saving seen data "./dancer.seen" |
04:39:55 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
04:40:04 | | Quit __builtin (Quit: No Ping reply in 180 seconds.) |
04:40:43 | | Join __builtin [0] (~quassel@rockbox/developer/builtin) |
04:52:54 | | Join johnb3 [0] (~johnb2@p5b3af96a.dip0.t-ipconnect.de) |
04:57:02 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
06:00 |
06:32:46 | *** | Saving seen data "./dancer.seen" |
08:00 |
08:02:44 | | Quit pamaury (Ping timeout: 258 seconds) |
08:32:47 | *** | Saving seen data "./dancer.seen" |
08:36:59 | speachy | johnb3: lovely. so it appears we have a couple of options due to the jankiness of their implementation. |
08:37:19 | speachy | 1) put up with pops whenever audio starts or stops. |
08:38:16 | speachy | 2) have the first few seconds of audio cut off because it takes the player just that long to mute/unmute the actual analog output |
08:38:45 | speachy | 3) have the hardware _always_ playing an audio stream so the codec never turns off. |
08:40:26 | speachy | oh, that "thump" on pause/etc has always been there; it's just a code path I missed muting. which is just as well. |
08:41:01 | speachy | (@%#$ codec power saving mode..) |
08:41:38 | johnb3 | Well, the current status is not really annoying. The "thump" doesn't do any harm. The delayed un-pause needs getting accustomed to ... |
08:42:01 | speachy | the delay in audio output means we'll lose voice prompts too. |
08:42:30 | speachy | since the pop is due tothe codec powering back up, which only happens once the pcm data starts to flow. |
08:42:37 | speachy | (completely outside our control!) |
08:42:37 | johnb3 | so you're saying it really drops data? |
08:44:46 | speachy | johnb3: pretty sure, yeah. was going to switch back to the rocker and re-enable voice prompts to see if it was just the x3ii before I decided what to do next. |
08:46:49 | johnb3 | Just to be clear, I only hear the "thump" after doing pause (longer than 3s). No other occasion. |
08:47:14 | speachy | using the latest build, correct? |
08:47:20 | johnb3 | yes |
08:47:42 | speachy | that's because I didn't mute the output when pausing. |
08:48:46 | speachy | before I made those most recent commits you'd hear a loud pop when booting, and then a relatively soft pop every time anything interacted with the audio hardware −− starting, stopping, even adjusting the volume. |
08:50:40 | johnb3 | Something else: I feel I have seen the screen refresh/update problem again to some extent. Furthermore, stepping through System->Rockbox Info causes delays. Is this due to accessing / reading the SD information (I have a 200GB card). |
08:51:31 | johnb3 | yeah, that pop during boot was really annoying. |
08:51:43 | speachy | it still happens, just not as bad. anything that can cause filesystem access to block will cause the UI repainting to stutter, because it's generally happening in the same thread. |
08:51:44 | johnb3 | I read your commit messages. |
08:52:19 | johnb3 | I see. |
08:52:29 | speachy | and things like usb and headphone jack detection require querying the filesystem, at 10Hz I think. |
08:52:59 | speachy | (the solution is to add more indepdenent threads for this stuff) |
08:56:45 | speachy | ok, the rocker functions sanely with the muting. it's the xduoo that's pathologic with muting behavior. |
08:57:54 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
08:59:48 | speachy | yep, the blocking mute pause/unpause causes the UI to lag too. #$^@$#^ |
09:00 |
09:08:47 | speachy | I'm curious if the X20 exhibits the same insanity. |
09:09:56 | speachy | ooo! |
09:10:30 | speachy | they did expose the jz4450's powerdown time as a parameter. |
09:23:34 | | Join johnb5 [0] (~johnb2@p5b3af96a.dip0.t-ipconnect.de) |
09:28:16 | | Quit johnb5 (Ping timeout: 272 seconds) |
09:40:42 | | Quit TorC (Ping timeout: 260 seconds) |
09:41:37 | | Join TorC [0] (~Tor@fsf/member/TorC) |
09:42:26 | braewoods | speachy: couldn't you use inotify for that? |
09:42:35 | braewoods | though i recall that was mainly for regular files |
09:42:46 | braewoods | i don't know if it applies to virtual system files |
09:43:15 | braewoods | or even rely on ALSA or udev to help you out |
09:43:19 | braewoods | if those are even available |
09:43:34 | braewoods | i wouldn't know on such a resource strapped system |
09:45:57 | speachy | I don't think we can rely on inotify for sysfs. |
09:46:15 | braewoods | i see |
09:46:35 | braewoods | just asking since it's literally intended for this purpose |
09:47:03 | speachy | we might get hp/usb events through the input subsystem though. |
09:48:03 | braewoods | you could also see about detecting when the ALSA default output changes... it tends to do that automatically when the HP detection pin is triggered |
09:48:40 | braewoods | obviously no ACPI... |
09:48:53 | braewoods | i suppose most of the userspace helpers i'm used to are not present |
09:48:55 | braewoods | udev, etc |
09:49:04 | braewoods | probably just kernel apis |
09:51:18 | braewoods | interesting |
09:51:20 | braewoods | "Inotify does report some but not all events in sysfs and procfs." |
09:51:23 | braewoods | but not too specific |
09:53:45 | braewoods | speachy: does rockbox use custom shell scripts on the Linux targets? |
09:55:58 | speachy | braewoods: other than the initial startup script, no. |
09:56:44 | braewoods | speachy: i see. ok. i've seen people leave lingering shells behind because they don't end with exec |
09:56:55 | braewoods | it's a small ram optimization |
09:57:06 | speachy | ... now we actually do that |
09:57:24 | speachy | because the script ends in sleep and then reboot. :) |
09:57:37 | braewoods | so there is a lingering shell |
09:57:44 | braewoods | that waits for it to exit? |
09:58:01 | braewoods | ok. |
09:58:08 | speachy | it's busybox though, so it's just the incremental environment and overhead |
09:58:30 | speachy | the bigger issue is that we copy the rockbox binary into the ramdisk and run it from there. |
09:58:56 | braewoods | isn't that redundant? the kernel should be doing that when you try to execute it |
09:59:21 | speachy | not sure if that means we get two copies in RAM or just one. |
09:59:45 | speachy | (the pagecache might be smart enough to do the right thing) |
09:59:53 | braewoods | i just know that programs have to be loaded into RAM by the kernel prior to execution and they usually also do file caching |
09:59:55 | braewoods | but |
09:59:59 | braewoods | with the limited RAM |
10:00 |
10:00:02 | braewoods | caching would be limited |
10:00:42 | speachy | this is one of the reasons that the vortex ports execute off of onboard flash |
10:00:55 | braewoods | i see. |
10:01:19 | braewoods | is mmap helpful at all? |
10:01:30 | braewoods | i know people use it for custom allocations and such |
10:01:35 | braewoods | especially opening files read only |
10:01:47 | braewoods | perhaps even too big for ram, just relying on the kernel to map it in on demand |
10:02:46 | speachy | we use traditional file I/O APIs. which, interestingly enough, are often implented using mmap() by the C library |
10:03:03 | braewoods | so stdio |
10:03:09 | braewoods | hm. |
10:03:21 | braewoods | do your hosted target builds use threads? |
10:03:40 | speachy | pthreads, yes. |
10:03:43 | braewoods | if not you could gain a small performance boost from using the unlocked APIs as POSIX stdio uses locks for every access by default |
10:03:49 | braewoods | ok, nevermind. |
10:03:50 | speachy | (or sdl threads if it's an SDL target) |
10:04:38 | braewoods | i did experiments with reading text databases, like 10% gain in performance when i disabled the locks |
10:04:54 | braewoods | but not always safe to do |
10:05:31 | speachy | it seems prudent to create a couple more dedicated threads on the hosted targets −− input, display, audio. |
10:06:04 | braewoods | fair enough. i just know threads have overhead that may be unappealing in these more limited devices. |
10:06:11 | | Join johnb5 [0] (~johnb2@p5b3af96a.dip0.t-ipconnect.de) |
10:06:36 | speachy | it's only a little bit of incremental RAM use; these thigns have 1GHz of CPU to play with. |
10:06:41 | braewoods | context switching, locks, etc |
10:06:43 | braewoods | ah |
10:08:37 | braewoods | oddly enough i've found that just using C a lot of times was enough to cut the fat from programs |
10:08:46 | braewoods | even if it's not all that optimized |
10:09:28 | braewoods | speachy: has struct padding been a source of memory waste in rockbox? i know it can be an issue... |
10:09:48 | braewoods | i've always tried to minimize wasted memory |
10:11:01 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
10:32:48 | *** | Saving seen data "./dancer.seen" |
10:39:55 | speachy | it can be, but when your processors can't handle unaligned accesses you can't get too aggressive. we generally avoid forcing structures to be packed unless needed for interaction with external data or hardware. |
10:41:30 | fs-bluebot_ | Build Server message: New build round started. Revision d181576, 282 builds, 8 clients. |
10:42:15 | speachy | johnb3: I just pushed two commits; when the second build is done I'd appreciate it if you can give it a spin to see/hear what transpires. |
10:42:29 | johnb3 | sure |
10:42:32 | speachy | there's going to be a startup pop |
10:42:54 | speachy | haven't figured out how to shut that up without also killing the first couple seconds of audio. |
10:43:39 | speachy | ideally if you have a mixture of source sample rate material −− eg 44K mp3 and 48K opus. |
10:44:29 | speachy | interested in pause/idle/resume artifacts, switching-tracks artifacts (where sample rate changes), voice menu prompts getting cut off, etc. |
10:45:05 | johnb3 | ok, I will set up a proper file set. |
10:46:16 | speachy | in the mean time, I'm going to go off and do yard work! huzzah. |
10:49:27 | amiconn | :grml: Someone broke rbclient config, apparently without notifying build client owners. Or did I overlook some mail? |
10:54:33 | | Join MrZeus_ [0] (~MrZeus@2a02:c7f:70d0:6a00:c571:7edf:71a2:6289) |
10:57:00 | fs-bluebot_ | Build Server message: Build round completed after 930 seconds. |
10:57:03 | fs-bluebot_ | Build Server message: Revision d181576 result: All green |
10:57:05 | fs-bluebot_ | Build Server message: New build round started. Revision d4a620e, 282 builds, 8 clients. |
11:00 |
11:10:14 | | Quit johnb5 (Ping timeout: 272 seconds) |
11:16:16 | fs-bluebot_ | Build Server message: Build round completed after 1151 seconds. |
11:16:17 | fs-bluebot_ | Build Server message: Revision d4a620e result: All green |
11:28:38 | braewoods | speachy: ah, i'm not advocating for packed structures. |
11:29:02 | braewoods | speachy: optimized ones actually. they arrange fields by size to reduce padding |
11:29:47 | braewoods | -Wpadded, at least on modern compilers can be helpful for finding candidates |
11:36:27 | genevino | speachy: just tried the latest dev build and i don't get any kind of popping sound, even not when re-starting the device. |
11:51:25 | _bilgus__ | braewoods I generally try to arrange new / re arrange old structs for the best packing when I find em |
11:53:20 | _bilgus__ | that and stuff with lots of global vars those are the worst but usually get some saving performance moving them to a well packed struct |
11:53:52 | _bilgus__ | but I've only done that when refactoring stuff its a PITA |
11:55:50 | | Join johnb5 [0] (~johnb2@p5b3af96a.dip0.t-ipconnect.de) |
12:00 |
12:12:36 | _bilgus__ | I think I mentioned this years ago get_action(CONTEXT, TIMEOUT) immediately times out the first run it only has the expected behavior on subsequent runs |
12:14:00 | _bilgus__ | I wonder what i'd break if I changed that for plugins |
12:25:36 | | Quit pamaury (Ping timeout: 272 seconds) |
12:26:45 | speachy | only one way to find out! |
12:27:08 | speachy | genevino: you're on the rocker though, correct? |
12:28:35 | _bilgus__ | I know it messes up core |
12:29:35 | speachy | genevino: the changes I made should (finally) prevent any popping on the rocker during long pauses or when resuming playback |
12:32:00 | speachy | amiconn: a bad config got accidently pushed out a while ago, but AFAIK nothing's changed for at least a month or so... |
12:32:52 | *** | Saving seen data "./dancer.seen" |
12:34:12 | speachy | the last change was back in july. you probably had a runclient.sh with a toolchain that got yanked. |
12:39:32 | genevino | speachy: correct, that was on the rocker. |
12:54:45 | johnb3 | speachy : http://www.mediafire.com/file/4c0iwj7c8tgoww3/x3ii_test.pdf/file This is what I tested. |
12:55:21 | johnb3 | As you said, there is the nasty pop after boot. No issue seen on idle or voiced menus. |
12:57:21 | johnb3 | Pause/unpause every now and then I hear some pop, but I think I heard similar on other players (sansa). Nothing annoying. I had the impression, that it happens more often on the high sample rate tracks, almost never on mp3 and opus. |
12:57:30 | amiconn | speachy: Yes, meanwhile I noticed that the mips toolchain changed |
12:57:52 | amiconn | The problem is that I have rbclient running as a systemd user service, and only noticed that today |
12:58:26 | amiconn | There used to be announcement mails for build client owners when changes like this happened... |
12:58:47 | johnb3 | That track 7 (classical) @ 192kHz almost never has a pop on pause/unpause. |
12:59:03 | johnb3 | Sorry, track6. |
13:00 |
13:03:42 | genevino | speachy: yeah well i'm reading git log -p since a couple of days because i try to get more and more into the details of rockbox. it's pretty hard to follow along for me as i'm not comfortable with the code base, but i try my best to learn something. |
13:04:27 | genevino | speachy: it's great to see such active development though. |
13:07:04 | speachy | amiconn: the mips toolchain changed... a couple of years ago now? The change I made was getting rid of toolchain keywords that hadn't actually been used (or working) for even longer. (except for the android ones, which hadn't been available to download for about as long..) |
13:07:48 | speachy | but yeah, point well made; this should have been posted on the ML. |
13:09:05 | amiconn | Well my client used to run when I set up my new machine (back in November 2019), even if the "mipsel" toolchain was not been used (I simply copied my toolchain builds from my old machine) |
13:09:10 | genevino | speachy: but since you obviously touched both devices: agptek rocker or xduoo x3ii, what would you buy if you could choose? |
13:09:22 | johnb3 | speachy : so no particular findings from my side. |
13:09:49 | amiconn | Perhaps rbclient.pl should warn somehow if a deprecated (but still known) toolchain is enabled? |
13:10:35 | amiconn | "You still have toolchain xxx enabled which is deprecated and will be removed soon." or sth |
13:10:47 | speachy | amiconn: but folks that have it running as a system service won't ever actually notice a warning. |
13:12:12 | speachy | johnb3: I'm pretty sure that nasty startup pop is from the initial codec reset, but I'm not sure _where_ in the init code it gets triggered, and if we hold off on the unmute until PCM is kicked off, then the first second or so of whatever is played gets cut off (be it the music or the initial voice menu prompt) |
13:12:15 | amiconn | Hmm, not immediately, no |
13:13:06 | amiconn | But usually, when I create some service, I check if it's actually running using 'systemctl status xyz', an that shows the last few lines of log |
13:13:11 | johnb3 | Yeah, one needs to remember to plug or put on the headphones after boot then ;-) |
13:13:38 | amiconn | So if the toolchain is already deprecated at that point, I would have noticed |
13:21:49 | | Quit JanC (Remote host closed the connection) |
13:22:06 | speachy | but systemctl status would immetately show the failure due to the 'unknownnarch', whereas the deprecation warning could get lost due to log rollovers, especially if there are other toolchain/targets that still work |
13:22:15 | | Join JanC [0] (~janc@lugwv/member/JanC) |
13:25:00 | speachy | still seems like immediately erroring out is the least bad approach |
13:27:22 | | Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) |
13:31:22 | | Join johnb3 [0] (~johnb2@p5b3af96a.dip0.t-ipconnect.de) |
13:33:23 | amiconn | Error for unknown arch is obviously okay, but if we do it in two steps (deprecation, and later removal) it could be better for build client availability |
13:34:42 | amiconn | This way the client admin has a chance of noticing the deprecation (while his client is still contributing builds for other archs) before it's getting removed, which will effectively make the client unavailable |
13:34:45 | speachy | tbh, two decades of experience in this space has shown me that deprecation warnings are nearly completly useless; no code gets changed until it's actually removed. |
13:35:17 | amiconn | hmm |
13:36:09 | speachy | and absent some sort of way to filter that deprecation warning to a human, it'll be ignored because nobody looks at logs until something stops working |
13:37:53 | speachy | won't be a lot of work to add a warning; I just don't think it's going to actually accomplish anything. |
13:38:22 | speachy | (heh, spent longer talking about it here than it will take to implement..) |
13:40:57 | amiconn | Maybe I should implement some cronjob that checks whether rbclient.pl changed, and the send a local mail... |
13:44:59 | | Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) |
14:00 |
14:07:00 | speachy | amiconn: it's not changed often. There was a flurry of changes taht happened as a result of issues uncovered in the server migration, but it's otherwise pretty unremarkable. |
14:08:12 | | Join dungai [0] (5217cb23@cpc149992-brnt4-2-0-cust802.4-2.cable.virginm.net) |
14:08:43 | dungai | hello when will nwz-a829 be supported for nwztools? |
14:09:39 | dungai | https://pastebin.com/d99kxbQx |
14:14:17 | | Join petur [0] (~petur@rockbox/developer/petur) |
14:21:46 | fs-bluebot_ | Build Server message: New build round started. Revision 2e708c4, 282 builds, 9 clients. |
14:32:53 | *** | Saving seen data "./dancer.seen" |
14:36:50 | fs-bluebot_ | Build Server message: Build round completed after 905 seconds. |
14:36:52 | fs-bluebot_ | Build Server message: Revision 2e708c4 result: 36 errors 0 warnings |
14:51:32 | | Quit johnb5 (Ping timeout: 260 seconds) |
15:00 |
15:14:23 | | Quit kugel (Quit: Lost terminal) |
15:14:57 | | Join kugel [0] (~kugel@ip5b40d8e6.dynamic.kabel-deutschland.de) |
15:14:58 | | Quit kugel (Changing host) |
15:14:58 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
15:29:45 | fs-bluebot_ | Build Server message: New build round started. Revision 2b358ff, 282 builds, 9 clients. |
15:44:19 | | Join johnb5 [0] (~johnb2@p5b3af96a.dip0.t-ipconnect.de) |
15:52:10 | fs-bluebot_ | Build Server message: Build round completed after 1345 seconds. |
15:52:11 | fs-bluebot_ | Build Server message: Revision 2b358ff result: 22 errors 0 warnings |
15:59:19 | | Quit dungai (Remote host closed the connection) |
16:00 |
16:24:09 | fs-bluebot_ | Build Server message: New build round started. Revision d5167b1, 282 builds, 9 clients. |
16:25:06 | speachy | the M3K was just dropped off. |
16:25:27 | speachy | ... they actually mention the GPL on the packaging. Wow. |
16:25:51 | | Quit johnb5 (Quit: Nettalk6 - www.ntalk.de) |
16:32:55 | *** | Saving seen data "./dancer.seen" |
16:39:34 | fs-bluebot_ | Build Server message: Build round completed after 926 seconds. |
16:39:35 | fs-bluebot_ | Build Server message: Revision d5167b1 result: 6 errors 0 warnings |
16:56:57 | fs-bluebot_ | Build Server message: New build round started. Revision 1916aca, 282 builds, 9 clients. |
17:00 |
17:13:53 | fs-bluebot_ | Build Server message: Build round completed after 1016 seconds. |
17:14:00 | fs-bluebot_ | Build Server message: Revision 1916aca result: All green |
17:24:13 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
18:00 |
18:07:04 | | Quit petur (Ping timeout: 260 seconds) |
18:07:21 | | Join petur [0] (~petur@rockbox/developer/petur) |
18:09:54 | fs-bluebot_ | Build Server message: New build round started. Revision 80c3b84, 282 builds, 9 clients. |
18:10:47 | speachy | yay, a commit that I didn't make! :D |
18:11:06 | _bilgus__ | with that lua will have a new function splash_scroller that allows you to display a wall of text to the user with text reflow and scrolling |
18:11:26 | _bilgus__ | that took entirely longer than I expected tbh |
18:11:37 | _bilgus__ | feel like I say that a lot |
18:11:47 | speachy | ...indeed. |
18:11:58 | speachy | isn't that the normal state of affairs? |
18:12:24 | _bilgus__ | clearly :p |
18:25:33 | fs-bluebot_ | Build Server message: Build round completed after 940 seconds. |
18:25:34 | fs-bluebot_ | Build Server message: Revision 80c3b84 result: All green |
18:32:57 | *** | Saving seen data "./dancer.seen" |
18:33:38 | | Quit ZincAlloy (Quit: Leaving.) |
19:00 |
19:14:11 | | Quit pamaury (Ping timeout: 240 seconds) |
19:22:51 | braewoods | speachy: M3K? |
19:31:35 | | Quit lebellium (Quit: Leaving) |
19:36:29 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
19:37:17 | speachy | braewoods: fiio m3k. xvortex sent over the sources for his port about a week ago |
19:37:18 | | Join fs-bluebot [0] (~fs-bluebo@55d47294.access.ecotel.net) |
19:39:38 | | Quit bluebrother^ (Ping timeout: 258 seconds) |
19:40:04 | | Quit fs-bluebot_ (Ping timeout: 272 seconds) |
19:56:09 | braewoods | "affordable" |
19:56:12 | braewoods | they weren't kidding |
19:56:15 | braewoods | only $60 |
20:00 |
20:05:40 | | Quit Oksana (Read error: Connection reset by peer) |
20:06:41 | speachy | alas it's a featureless touch pad for input. |
20:07:18 | speachy | It has the 64MB X1000e in it |
20:11:23 | | Quit livvy (Ping timeout: 240 seconds) |
20:15:31 | braewoods | x1000e sounds like an ethernet chipset |
20:15:33 | braewoods | lol |
20:24:41 | fs-bluebot | Build Server message: New build round started. Revision f3ae48f, 282 builds, 9 clients. |
20:28:13 | speachy | Okay, the first pass at the re-worked M3K port is now in gerrit as g#2804 |
20:29:59 | | Quit MrZeus_ (Ping timeout: 272 seconds) |
20:30:31 | | Quit tbaxter (Quit: Leaving.) |
20:32:59 | *** | Saving seen data "./dancer.seen" |
20:42:17 | fs-bluebot | Build Server message: Build round completed after 1056 seconds. |
20:42:19 | fs-bluebot | Build Server message: Revision f3ae48f result: All green |
20:45:18 | | Join tbaxter [0] (~Adium@pool-100-34-20-58.phlapa.fios.verizon.net) |
20:47:30 | | Quit petur (Remote host closed the connection) |
21:00 |
21:00:57 | | Quit pixelma (Quit: .) |
21:00:58 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
21:01:13 | | Join pixelma [0] (marianne@rockbox/staff/pixelma) |
21:01:16 | | Join amiconn [0] (jens@rockbox/developer/amiconn) |
21:01:32 | | Quit atsampson (Ping timeout: 246 seconds) |
21:01:47 | | Join atsampson [0] (~ats@cartman.offog.org) |
21:32:54 | genevino | latest release i flashed to the rocker literally fixed all showstoppers for me btw. wonderful. |
21:48:31 | genevino | when skipping tracks too fast i get occasional segfaults, but hey, at least that's rare. |
22:00 |
22:04:58 | _bilgus__ | genevino can you get a segfault in lua_scripts playback.lua? it stops playback in between track changes |
22:05:56 | _bilgus__ | Plugins>demos>lua_scripts>playback.lua |
22:23:08 | | Join johnb3 [0] (~johnb2@p5b3af8be.dip0.t-ipconnect.de) |
22:31:02 | genevino | _bilgus__: that does in fact play music, but all controls are disabled and i can't do anything (except rebooting i guess, let me see...) |
22:31:35 | genevino | yeah i can only switch off and on from there |
22:31:43 | _bilgus__ | hmm might not have pla keymaps defined |
22:31:57 | _bilgus__ | x3II or rocker? |
22:32:16 | genevino | agptek rocker. |
22:33:02 | *** | Saving seen data "./dancer.seen" |
22:34:37 | _bilgus__ | no it appears to have the pla actions mapped hmm |
22:35:06 | _bilgus__ | does boomshine work for you? |
22:36:41 | _bilgus__ | I did just change the backend for rockbox events in lua so could be related |
22:36:55 | _bilgus__ | Plugins>games>boomshine |
22:36:55 | | Quit TheSeven (Ping timeout: 240 seconds) |
22:37:38 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
22:55:25 | | Quit johnb3 (Ping timeout: 240 seconds) |
23:00 |
23:00:55 | | Quit ac_laptop (Ping timeout: 240 seconds) |
23:41:34 | | Quit tbaxter (Quit: Leaving.) |
23:46:41 | speachy | my trip down the rabbit hole of CAPs has turned up a few interesting ones built on an STM32F7 |
23:54:05 | | Quit massiveH (Quit: Leaving) |
23:56:21 | speachy | including one variant with an actual tube amp in it. |
23:56:23 | speachy | ... |