00:00:52 | braewoods | why would anyone want to send so much automated traffic against rockbox.org? |
00:00:56 | braewoods | we have nothing really |
00:04:57 | *** | Saving seen data "./dancer.seen" |
00:09:58 | _bilgus | its probably that ransom message someone forwarded |
00:10:46 | _bilgus | eh n bitcoins or we will kill your firstborns in the night or wait was that it |
00:11:29 | _bilgus | something along those lines and we wondered what they thought we had to give em |
00:12:08 | _bilgus | 3 rubber bands and pocket lint better get macguiver to get something from that |
00:34:24 | | Join beencubed [0] (~beencubed@209.131.238.248) |
01:00 |
01:05:19 | | Quit ac_laptop (Ping timeout: 260 seconds) |
01:20:02 | | Quit massiveH (Quit: Leaving) |
02:00 |
02:04:58 | *** | Saving seen data "./dancer.seen" |
03:00 |
03:01:30 | | Quit ufdm (Remote host closed the connection) |
03:01:49 | | Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
03:23:56 | | Quit pixelma (Quit: .) |
03:23:56 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
03:24:55 | | Join amiconn [0] (jens@rockbox/developer/amiconn) |
03:24:56 | | Join pixelma [0] (marianne@rockbox/staff/pixelma) |
04:00 |
04:04:59 | *** | Saving seen data "./dancer.seen" |
04:41:20 | | Quit ZincAlloy (Quit: Leaving.) |
04:53:31 | | Join PimpiN8 [0] (~PimpiN8@82-75-30-111.cable.dynamic.v4.ziggo.nl) |
04:55:05 | | Quit PimpiN8 (Read error: Connection reset by peer) |
05:00 |
05:08:15 | | Quit Stanley00 (Remote host closed the connection) |
05:20:16 | | Join cela [0] (92c67a98@152.122.198.146.dyn.plus.net) |
05:21:01 | cela | _bilgus tested e09df1ce5bM-210405 posted on the forum still has the same playback issue |
05:21:56 | cela | Wodz might still drop by, he created the RK27xx port not sure if he still has a working device though |
05:35:50 | cela | Just retested the last commit that worked commit [83e8e35a5888e32b131d628b7516d0de1d73d760] , playback works fine |
05:36:22 | | Quit cela (Quit: Connection closed) |
05:39:22 | | Join MrZeus [0] (~MrZeus@2a02:c7f:a0aa:4400:7949:2774:350e:9e8b) |
06:00 |
06:05:03 | *** | Saving seen data "./dancer.seen" |
06:07:52 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
06:08:42 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
06:14:48 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
06:15:56 | speachy | braewoods: it's a host on the internet. that's all that's needed. |
06:25:58 | | Quit Stanley00 () |
06:30:07 | | Quit pixelma (Ping timeout: 260 seconds) |
06:30:34 | | Quit amiconn (Ping timeout: 276 seconds) |
06:30:38 | | Join pixelma [0] (marianne@rockbox/staff/pixelma) |
06:30:39 | | Join amiconn_ [0] (jens@rockbox/developer/amiconn) |
06:30:39 | | Nick amiconn_ is now known as amiconn (jens@rockbox/developer/amiconn) |
07:00 |
07:09:34 | fs-bluebot | Build Server message: New build round started. Revision 1aed109fa8, 298 builds, 10 clients. |
07:30:04 | fs-bluebot | Build Server message: Build round completed after 1230 seconds. |
07:30:08 | fs-bluebot | Build Server message: Revision 1aed109fa8 result: 1 errors 0 warnings |
08:00 |
08:05:05 | *** | Saving seen data "./dancer.seen" |
08:28:43 | speachy | cela, wait, current build worked? that really sounds like some sort of odd alignment quirk. But at least you narrowed it down to the codecs |
08:37:32 | | Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) |
08:53:40 | | Join cela [0] (92c67a98@152.122.198.146.dyn.plus.net) |
08:54:51 | cela | speachy no I just retested the last commit that worked back in 2017 :-) |
08:55:06 | speachy | aaah, okay, that was unclear |
08:55:36 | speachy | but at least straight-up PCM works. can you try other codecs or plugins that make sound? |
08:55:50 | cela | wodz is the man to get hold of, i think he does drop by from time to time. |
08:56:04 | speachy | (eg opus or flac, and the module/tracker plugin..) |
08:56:20 | speachy | haven't seen him here for some time, alas |
08:56:35 | speachy | problem is that nobody here actually has any rk27xx hardware. :/ |
08:57:41 | _bilgus | cela did you compile that test build on the current toolchain by chance? |
08:58:23 | cela | flac is the same, button sounds work. if all else fails it could be retired like Archos. |
08:58:42 | speachy | do plugins work at all? |
08:58:49 | cela | toolchain not sure i'd have to check |
08:59:06 | cela | no plugins are enabled |
08:59:57 | _bilgus | ok let me give you this working build compiler here and see if it still works for you |
09:00 |
09:00:18 | _bilgus | compiled* |
09:00:22 | cela | port was part complete, no usb transfer, charging only. |
09:03:02 | speachy | there are at least 8 rk27xx targets in the tree, including 3 that I ported over from the xvortex sources |
09:04:39 | speachy | we only provide dev/nightly builds for those three |
09:04:57 | speachy | wait, and the two hifimans too |
09:05:18 | cela | wow that many, hifiman would be best to test with, mine is just a no brand and they are not very consistent hardware wise. |
09:05:50 | speachy | consistent or not, codec functionality is pure sw and would presumably be the same on all of 'em. |
09:06:21 | cela | so they could all be broken |
09:06:30 | speachy | yeah. |
09:06:46 | speachy | well, can use some of the rockbox slush fund to pick up an old HM-601 |
09:07:42 | _bilgus | cela 83e8e35a5_rk27xx_rockbox-full.zip |
09:07:55 | _bilgus | thats that working commit compiled by me |
09:09:16 | speachy | oh, incidently, the xduoo x2 is an atj213x device. don't know about the new x2s yet. |
09:17:12 | speachy | whoops, make that AK2117C −− uses the same firmware image format as the ATJ213x |
09:17:35 | speachy | tihis thig has an 8051-derived core. |
09:18:33 | speachy | insane on-chip memory segmentation, and hw accelerators. |
09:19:28 | cela | bilgus 83e8e35a5_rk27xx_rockbox-full you complied works fine |
09:19:52 | cela | go to go |
09:20:03 | cela | *got to go |
09:20:07 | speachy | this makes the rknano family look like a supercomputer in comparison. sheesh. |
09:20:18 | | Quit cela (Quit: Connection closed) |
09:21:44 | _bilgus | cela thank you thats enough for me to go on |
09:22:06 | | Quit ZincAlloy (Quit: Leaving.) |
09:31:01 | speachy | _bilgus: think it's worth getting that hifiman 601? |
09:32:05 | _bilgus | what was the $$ on that one? |
09:32:24 | speachy | $91 shipped. |
09:32:34 | _bilgus | yeah thats not terrible |
09:32:47 | speachy | the DX50/DX90 seems to go for $150 or so |
09:32:58 | _bilgus | thats a bit steep for used |
09:33:57 | speachy | ok, should be here by next week they claim. |
09:44:00 | braewoods | it might be an opportunity to create specific ports out of the generic one |
09:44:53 | _bilgus | I wish they listed the embedded processor in the ad copy |
09:45:07 | | Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) |
09:53:14 | speachy | eh, largely moot these days unless someone finds a shipping container packed with a bunch |
09:57:04 | fs-bluebot | Build Server message: New build round started. Revision 74ae18cc8a, 298 builds, 10 clients. |
10:00 |
10:05:09 | *** | Saving seen data "./dancer.seen" |
10:11:46 | fs-bluebot | Build Server message: Build round completed after 882 seconds. |
10:11:50 | fs-bluebot | Build Server message: Revision 74ae18cc8a result: All green |
10:13:34 | _bilgus | how many devices do we have with remotes like 2? |
10:14:26 | speachy | at least 3 |
10:14:34 | _bilgus | my key remap idea isn't going to work with remotes in its current form |
10:15:48 | _bilgus | eh I guess its only going to be needed for the remotes but plugins I'll leave as is since there is already a way to supply button mapping for them |
10:16:23 | _bilgus | I do want to make the keymap plugin able to make them per plugin as well |
10:17:14 | _bilgus | so you could have doom_kmf and it would load when the plugin is opened |
10:18:04 | _bilgus | and since we can now call plugins from plugins the menu can be integrated in the plugin if the keymapper plugin exists |
10:34:07 | _bilgus | speachy https://www.mediafire.com/file/aeh7er1wmi87zel/asm_diff.diff/file <this is the diff between the previous working and the enum broken commit ln 954 looks interesting |
10:35:51 | speachy | line 954 of the actual diff, or 954 in the src/dest dump? |
10:36:37 | _bilgus | the diff line |
10:36:41 | _bilgus | not source |
10:37:59 | speachy | 'mov r0,r0,asl#24' being the difference? |
10:38:12 | _bilgus | asr is shift right |
10:38:19 | _bilgus | yeah |
10:38:53 | speachy | shift left, shift right |
10:40:57 | _bilgus | still not through the whole thing but so far beyond alignment that the only real diff |
10:41:28 | _bilgus | I'm spiining up the aligned one I sent yesterday to cut down on some of the noise |
10:42:58 | speachy | so it shifts back and forth. effectively zeroing out the upper 24 bits |
10:43:15 | _bilgus | in the working one |
10:43:30 | speachy | oh, thought it was the other way around |
10:43:59 | speachy | for an enum the max value is supposedly known |
10:44:28 | _bilgus | mmhmm so itd make sense to wipe out the upper |
10:46:29 | _bilgus | eh the aligned one is just different in other places i'll finish out this one |
10:52:07 | speachy | except ACTION_HALT is -1. :D |
10:52:53 | _bilgus | HA |
10:54:09 | speachy | we have like 4 defined values only |
10:54:18 | speachy | actualllly... |
11:00 |
11:16:40 | _bilgus | ok so what I don't see is how this would only affect this target |
11:17:36 | speachy | yeah, it's hardly our only armv5 platform |
11:19:13 | _bilgus | line 3919 wehn i goes into the codec entry |
11:19:26 | _bilgus | opus is the first one but it hasa similar change |
11:19:32 | _bilgus | for others |
11:19:57 | _bilgus | cmn not sure what that one is |
11:20:28 | _bilgus | compare negative |
11:24:17 | _bilgus | maybe not I only see opus speex and am3? whatever that is |
11:24:34 | _bilgus | did cela say some codec worked? |
11:26:05 | speachy | he tried flac too |
11:26:10 | speachy | so I presume mp3 + flac |
11:27:31 | _bilgus | yeah and I don't see either in here |
11:27:48 | _bilgus | opus aac wma wma pro mpa mpc |
11:28:19 | _bilgus | so I assume the codecs that are getting compiled here must have a different way of enry than the others |
11:28:26 | _bilgus | entry |
11:30:02 | _bilgus | or mp3 and flac are broken |
11:30:16 | _bilgus | ?? |
11:30:39 | _bilgus | nope found flac |
11:30:57 | _bilgus | no mp3 though maybe its a different name |
11:31:40 | speachy | w00000! |
11:31:52 | speachy | USSC ruled in favor of Google over Oracle. |
11:40:55 | | Quit pamaury (Ping timeout: 260 seconds) |
11:53:28 | _bilgus | so the codec enum is still an int |
11:54:30 | _bilgus | does that mean it should be cast to long in all these places by the lack of warning I'd say no? but maybe we can put a -1L or something |
12:00 |
12:00:43 | | Quit ZincAlloy (Quit: Leaving.) |
12:04:42 | _bilgus | the long min and long max take care of that I guess |
12:05:10 | *** | Saving seen data "./dancer.seen" |
12:16:58 | _bilgus | Its been about a week since we dropped thiose fixes for the ipod I guess we can't say we fixed anything but I guess its not broken worse either |
12:17:16 | braewoods | _bilgus: enums will expand to long if any of the constants are long |
12:17:18 | speachy | nobody's complained yet.. |
12:17:26 | braewoods | i learned that some time back |
12:17:51 | braewoods | so in theory |
12:17:59 | braewoods | if the first one is initialized as 0L |
12:18:05 | braewoods | the rest should be long as well |
12:18:44 | braewoods | here's some random C trivia... |
12:19:01 | _bilgus | YEah it sets them all to the biggest alignment |
12:19:06 | braewoods | given a function call, can you determine what order the arguments will be evaluated in? |
12:19:39 | _bilgus | thats up to the compiler IIRC |
12:19:45 | braewoods | yea, it's implementation defined |
12:19:50 | braewoods | so the answer is no |
12:20:02 | braewoods | it's why you need to be careful with side-effects in this context |
12:20:38 | braewoods | you can use them but you shouldn't use a set of side-effects where the order influences the end result |
12:21:16 | braewoods | i usually don't use side-effects in function call arguments |
12:21:21 | braewoods | seems bad practice |
12:21:36 | braewoods | can introduce bugs if you're not thinking carefully |
12:21:47 | _bilgus | a lot of the low level is like tha though and the compiler is generally pretty good at abstracting thoe details away but yes you are probably highlighting the reason only problem is without a device waiting 10 minutes - 1 day between builds gets annoying fast |
12:21:50 | braewoods | i'd rather avoid tricky parts of C honestly since they tend to introduce bugs |
12:22:48 | _bilgus | as much as I hate to add any limits I think maybe we need to add a NO ASM clause going forward unless really compelling |
12:23:11 | _bilgus | and then that there be left in the original c code with a NO_ASM switc or something |
12:23:11 | braewoods | you mean asm for new code? |
12:23:47 | braewoods | the only time ASM seems appropriate is when you absolutely need stuff to happen in a specific way at that level |
12:23:56 | braewoods | maybe bootloader code or so |
12:23:56 | _bilgus | yeah the codecs are always going to be needed |
12:24:10 | _bilgus | ASM in them just because they are way optimized |
12:24:54 | braewoods | i generally avoid ASM since it hinders the ability to benefit from compiler advances |
12:25:01 | braewoods | but bootstraping ASM is hardly performance critical |
12:25:42 | braewoods | you usually only run it once per boot or so |
12:25:48 | braewoods | so reliability is more important |
12:26:12 | _bilgus | just having the path easily back to original c code would be fine then we could disable them all and start reenabling them as testing proves them |
12:26:58 | _bilgus | but then that also add the you need to update 'dead' c code |
12:27:30 | _bilgus | still better than searching the SVN and uopdating dead c code |
12:27:59 | _bilgus | really dead then because it wasn't even near the ASM the last time someone touched it |
12:33:39 | _bilgus | it'll probably end up coming down to the memory layout is slightly different hiding a stackovf or something |
12:33:54 | _bilgus | or unhiding it |
12:34:07 | braewoods | we could start by removing code specific to ports that are half-baked that no one has contributed to in ages |
12:34:35 | _bilgus | they are kinda self contained though don't really bleed over into the others |
12:35:18 | _bilgus | not that it matters we can just put them in their own branch and excise them |
12:35:42 | _bilgus | easy enough to bring em back in if someone wants to take them up |
12:36:57 | _bilgus | for now.. |
12:37:31 | _bilgus | ok I've come up with a way to allow remotes and plugins to be remapped from the core rempa file |
12:38:00 | _bilgus | that should allow you to override everything yet still load custom keymaps in plugins |
12:39:04 | speachy | yeah, there's very little target-specific stuff outside of its specific subdir. just the occasional special-case here or there. |
12:39:33 | speachy | (unlike the hwcodec & archos stuff.. which had tentacles everywhere, due to history) |
12:50:37 | _bilgus | I'm so glad thats gone |
12:50:45 | _bilgus | only took 10 years |
12:50:48 | _bilgus | :p |
12:53:12 | _bilgus | I'm thinking rather than oring a shifted context with the action I'll just have it search for the context as a 3 int entry and then consider everything till a stop sentinel valid for that context |
12:53:28 | _bilgus | basically how it does it atm sorta |
12:55:02 | _bilgus | hmm that will make the plugin for generating them slightly more complicated |
13:00 |
13:04:21 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
13:04:22 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:5416:e4ab:d32e:1fe8) |
13:17:44 | | Quit ac_laptop (Ping timeout: 246 seconds) |
13:26:26 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
13:31:14 | | Nick dweeber` is now known as dweeber (~dweeber@c-73-52-129-219.hsd1.ut.comcast.net) |
13:33:03 | | Quit speachy (Ping timeout: 268 seconds) |
13:34:58 | | Quit emacsomancer (Ping timeout: 240 seconds) |
13:37:27 | | Join speachy [0] (~speachy@209.2.65.77) |
13:39:30 | | Join emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net) |
13:41:28 | | Quit ZincAlloy (Quit: Leaving.) |
13:47:41 | | Quit emacsomancer (Ping timeout: 240 seconds) |
13:51:43 | | Join emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net) |
13:56:55 | | Quit yosafbridge (Quit: Leaving) |
14:00 |
14:05:12 | *** | Saving seen data "./dancer.seen" |
14:06:57 | | Quit paulk-leonov (Read error: Connection reset by peer) |
14:08:38 | | Join yosafbridge [0] (~yosafbrid@static.38.6.217.95.clients.your-server.de) |
14:15:37 | | Join paulk-leonov [0] (~paulk-leo@vpn-0-22.aquilenet.fr) |
14:16:08 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
14:32:57 | | Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) |
15:00 |
15:12:48 | | Join PimpiN8 [0] (~PimpiN8@2001:1c04:3308:a500:686f:b150:a5a4:9c9) |
16:00 |
16:05:15 | *** | Saving seen data "./dancer.seen" |
16:31:24 | | Join dweeber_ [0] (~dweeber@c-73-52-129-219.hsd1.ut.comcast.net) |
16:33:47 | | Quit dweeber (Ping timeout: 240 seconds) |
16:36:19 | | Quit pamaury (Ping timeout: 260 seconds) |
16:37:26 | | Quit ZincAlloy (Quit: Leaving.) |
16:38:20 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
16:47:47 | | Quit Moarc (Read error: Connection reset by peer) |
16:48:08 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
16:55:49 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:e928:ee23:96e9:b094) |
16:55:58 | braewoods | i wonder if this will ever launch |
16:56:04 | braewoods | https://www.powerpc-notebook.org/ |
16:57:07 | braewoods | it won't be price competitive with pinebook pro but eh |
16:57:12 | braewoods | might be interesting none the less |
16:57:16 | | Nick dweeber_ is now known as dweeber (~dweeber@c-73-52-129-219.hsd1.ut.comcast.net) |
17:00 |
17:21:59 | | Join KalBot [0] (~matrixirc@connolly.tech) |
17:23:19 | | Quit ZincAlloy (Quit: Leaving.) |
18:00 |
18:05:17 | *** | Saving seen data "./dancer.seen" |
18:06:50 | | Quit lebellium (Quit: Leaving) |
18:20:10 | | Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) |
19:00 |
19:04:32 | | Join tomato1 [0] (t0mato@gateway/vpn/mullvad/tomato) |
19:06:39 | | Quit tomato (Ping timeout: 268 seconds) |
19:06:40 | | Nick tomato1 is now known as tomato (t0mato@gateway/vpn/mullvad/tomato) |
19:11:07 | | Quit pamaury (Ping timeout: 240 seconds) |
19:34:33 | | Quit ac_laptop (Quit: WeeChat 3.0) |
19:34:53 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
19:44:47 | | Join dconrad [0] (d026e411@208.38.228.17) |
19:49:59 | _bilgus | #3274 ok so I've reworked this a bit I think it should be a pretty efficient way to do this basically the beginning consists of a LUT with contexts the entries carry an index into the array of the first remapped action for that context with a sentinel at the end |
19:51:00 | _bilgus | a caveat is that you can't remap fall through contexts |
19:51:18 | _bilgus | so no system wide remaps I suppose |
19:52:06 | _bilgus | it could be changed by running through the table again after but I don't really see the need for the extra overhead |
19:58:08 | | Quit dconrad (Quit: Ping timeout (120 seconds)) |
20:00 |
20:05:20 | *** | Saving seen data "./dancer.seen" |
20:21:33 | | Quit MrZeus (Ping timeout: 246 seconds) |
20:43:05 | | Quit akaWolf (Ping timeout: 252 seconds) |
21:00 |
21:24:07 | | Join dconrad [0] (d026e411@208.38.228.17) |
21:40:32 | | Part dconrad |
21:41:34 | | Join dconrad [0] (~dconrad@208.38.228.17) |
21:51:59 | | Quit dconrad (Quit: Leaving) |
21:53:13 | | Join dconrad [0] (~dconrad@208.38.228.17) |
21:58:35 | | Quit dconrad (Quit: Leaving) |
22:00 |
22:01:10 | | Join dconrad [0] (~dconrad@208.38.228.17) |
22:05:21 | *** | Saving seen data "./dancer.seen" |
22:18:23 | | Quit ac_laptop (Ping timeout: 265 seconds) |
22:41:11 | | Join f1reflyylmao [0] (~f1refly@2a01:c22:9099:9f00:f73a:aed3:9302:975e) |
22:42:15 | | Quit f1refly (Ping timeout: 250 seconds) |
22:42:15 | | Nick f1reflyylmao is now known as f1refly (~f1refly@2a01:c22:9099:9f00:f73a:aed3:9302:975e) |
23:00 |
23:10:17 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
23:16:36 | braewoods | how annoying. |
23:16:49 | braewoods | i can't disassemble the gigabeat S because of a stripped external screw. |
23:57:29 | | Quit JanC (Remote host closed the connection) |
23:57:53 | | Join JanC [0] (~janc@lugwv/member/JanC) |