| 00:22:08 | Nyaa | did test codec thing for opus on ipodvideo |
| 00:22:15 | Nyaa | without dsp - 122.03% realtime |
| 00:22:21 | Nyaa | with dsp - 108.63% realtime |
| 00:23:13 | Nyaa | so, not a whole lot of overhead there |
| 00:29:57 | | Join user890104 [0] (~Venci@freemyipod/user890104) |
| 00:31:26 | | Join spork_ [0] (topic@213-234-20-31.ftth.glasoperator.nl) |
| 00:35:29 | | Quit spork (*.net *.split) |
| 00:35:29 | | Quit user890104_ (*.net *.split) |
| 00:37:17 | | Quit m01 (Quit: Konversation terminated.) |
| 00:39:59 | | Join m01 [0] (~quassel@vps-b172b88b.vps.ovh.net) |
| 01:00 |
| 01:03:36 | | Join advcomp2019_ [0] (~advcomp20@user/advcomp2019) |
| 01:05:28 | | Quit advcomp2019 (Ping timeout: 256 seconds) |
| 01:21:05 | | Nick spork_ is now known as spork (topic@213-234-20-31.ftth.glasoperator.nl) |
| 01:57:46 | *** | Saving seen data "./dancer.seen" |
| 01:58:58 | | Join advcomp2019 [0] (~advcomp20@user/advcomp2019) |
| 02:00 |
| 02:01:56 | | Quit advcomp2019_ (Ping timeout: 260 seconds) |
| 02:59:12 | | Quit CH23_M (Ping timeout: 252 seconds) |
| 02:59:31 | | Join CH23_M [0] (~CH23@revspace/participant/ch23) |
| 03:00 |
| 03:18:22 | | Quit CH23_M (Read error: Connection reset by peer) |
| 03:18:40 | | Join CH23_M [0] (~CH23@revspace/participant/ch23) |
| 03:57:50 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:57:52 | *** | No seen item changed, no save performed. |
| 06:00 |
| 06:11:41 | | Quit jacobk (Quit: No Ping reply in 180 seconds.) |
| 06:18:50 | | Join jacobk [0] (~quassel@64.189.201.150) |
| 07:00 |
| 07:11:32 | buZz | Nyaa: decoding is faster without hw acceleration? |
| 07:11:58 | buZz | or is that percentage 'amount of time to decode' :) |
| 07:52:52 | | Quit sebagala (Ping timeout: 245 seconds) |
| 07:53:08 | | Join sebagala [0] (~Burak@185.25.123.34) |
| 07:57:54 | *** | Saving seen data "./dancer.seen" |
| 08:00 |
| 08:14:11 | speachy | buZz: if "100%" means we can (just barely) decode it fast enough for realtime playback, lower numbers means it's going to stutter (at best) while higher numbers means there's spare CPU cycles for something other than decoding the audio. Like updating the UI, or possibly even going into lower-power mode. |
| 08:15:21 | speachy | for comparison, IIRC xDuoo X3 can decode opus at nearly 6x realtime. |
| 08:15:30 | buZz | isnt DSP using hw decoding? |
| 08:19:13 | gevaerts | "dsp" here means effects like equaliser |
| 08:19:27 | buZz | ahhh |
| 08:19:36 | buZz | so, software effects |
| 08:19:48 | speachy | equalizer, playback speed/pitch control, etc. |
| 08:21:39 | gevaerts | Rockbox doesn't do any hardware decoding, except on the (very) old Archos hardware |
| 08:37:12 | | Quit sebagala (Ping timeout: 240 seconds) |
| 08:47:00 | _bilgus | and we ripped it out |
| 08:48:18 | gevaerts | Well, yes and no. There hasn't been a new release yet since then! |
| 08:48:37 | _bilgus | the DSP stuff uses quite a bit of CPU figure even on the devices that do OPUS pretty ok start adding echo and signal processing and your battery life is noticably affected |
| 08:51:42 | _bilgus | I remeber this convo with speachy about upstream opus pushing underpowered devices ever closer to the brink |
| 08:51:53 | _bilgus | https://gerrit.rockbox.org/r/c/rockbox/+/2057 |
| 08:56:14 | _bilgus | we still pushed it 2 years later but I don't remember the specific reason that said Nyaa I'd try the downstream we had prior to see what kind of an increase you get on that hardware vs what we were testing [libopus Sansa Clip+ (Head) Desperation - Opus 64k 056.35 347.69 617.01% 031.11 ; libopus Sansa Clip+ (upstream) Desperation - Opus 64k 061.68 347.69 563.69% 034.06] |
| 08:57:44 | _bilgus | mind you upstream there ^ is current HEAD |
| 09:00 |
| 09:01:41 | _bilgus | gevaerts, noted. |
| 09:02:09 | _bilgus | back to FAT32 and long latencies wouldn't multiple partitions solve most of those issues? |
| 09:02:52 | _bilgus | we have support for that in the codebase already |
| 09:04:09 | _bilgus | I think the main issue with FAT32 is windows won't do the format because microsoft has stake in making exfat defacto |
| 09:04:19 | _bilgus | so meh Fuck MS lets do FAT32 |
| 09:04:46 | _bilgus | you already need tons of 3rd party tools to windows effectively whats one more? |
| 09:05:58 | | Join sebagala [0] (~Burak@185.25.123.34) |
| 09:11:06 | | Quit sebagala (Ping timeout: 256 seconds) |
| 09:14:48 | | Join sebagala [0] (~Burak@185.25.123.34) |
| 09:57:55 | *** | Saving seen data "./dancer.seen" |
| 10:00 |
| 10:11:59 | kirvesAxe | _bilgus_, well yeah, M$ is what it is... although I was a bit surprised when they published the specs for exFAT in 2019 (probably they finally realized its usage will die otherwise lol) |
| 10:15:39 | kirvesAxe | and yeah multiple partitions might solve some problems. but they would create others. It would be a horrible PITA to have to organize a large music collection and the playlists with that :) |
| 10:40:49 | speachy | there's nothing wrong with exFAT technically. or legally, any more. |
| 10:42:27 | speachy | but if rockbox gets exFAT support, most players we support will lose the ability to use the original device firmware. |
| 10:43:12 | speachy | (ie if we move to GPT partitioning and exFAT root) |
| 11:00 |
| 11:15:24 | | Quit jacobk (Ping timeout: 248 seconds) |
| 11:33:22 | | Join jacobk [0] (~quassel@129.110.241.106) |
| 11:57:34 | | Join Schimon [0] (a2fe4b5ecb@irc.cheogram.com) |
| 11:57:58 | *** | Saving seen data "./dancer.seen" |
| 12:00 |
| 12:25:17 | | Quit jacobk (Ping timeout: 248 seconds) |
| 12:39:46 | | Join lebellium [0] (~lebellium@2a01cb040610e000cc2c76c9e81294bd.ipv6.abo.wanadoo.fr) |
| 12:40:34 | | Join paulk-bis [0] (~paulk@vpn-0-22.aquilenet.fr) |
| 12:40:47 | | Quit paulk (Ping timeout: 244 seconds) |
| 13:00 |
| 13:28:41 | | Quit CH23_M (Read error: Connection reset by peer) |
| 13:28:51 | | Join CH23_M [0] (~CH23@revspace/participant/ch23) |
| 13:29:00 | | Quit CH23_M (Read error: Connection reset by peer) |
| 13:29:15 | | Join CH23_M [0] (~CH23@revspace/participant/ch23) |
| 13:38:18 | | Quit CH23_M (Ping timeout: 252 seconds) |
| 13:39:32 | | Join CH23_M [0] (~CH23@revspace/participant/ch23) |
| 13:43:42 | | Quit CH23_M (Read error: Connection reset by peer) |
| 13:43:56 | | Join CH23_M [0] (~CH23@revspace/participant/ch23) |
| 13:58:02 | *** | Saving seen data "./dancer.seen" |
| 13:59:09 | | Join jacobk [0] (~quassel@129.110.242.224) |
| 14:00 |
| 14:25:02 | kirvesAxe | speachy, well that might definately be a bad tradeoff in some cases :) |
| 14:29:16 | Nyaa | i mean if you take a fuck microsoft stance just do ext2 :p |
| 14:34:39 | * | Nyaa wonders how difficult it would be to implement an MTP usb mode |
| 14:34:54 | Nyaa | then aside from OF support it wouldn't matter what filesystem is used |
| 14:35:12 | Nyaa | [at least for transferring stuff to/from it] |
| 14:36:55 | Nyaa | would also, in theory, allow for playing music at the same time you're doing usb stuff, though a lot of devices probably don't have enough memory/resources for that\ |
| 14:48:46 | | Join bilgus_ph [0] (~bilgus_ph@12.74.64.2) |
| 14:51:09 | bilgus_ph | KirvesAxe i remember that but wasn't it only to OIC members though? As in still proprietary unless you join their cabal |
| 14:53:58 | | Quit bilgus_ph (Quit: Connection closed) |
| 15:00 |
| 15:01:15 | lebellium | @Mt83 (logs) : regarding SonyNWDestTool for S615F : I used to work with paumary on that tool but that was several years ago and none of us is still really involved in the project. |
| 15:01:15 | lebellium | He was basically doing all the tech/dev thing and I was assisting him with "QA" (I have a huge DAPs collection) and maintaining the wiki page. |
| 15:01:15 | lebellium | I just tried with my NWZ-S615F and I can confirm I get the same error (Cannot read node 'shp') as you do with your Japanese NW. |
| 15:01:15 | DBUG | Enqueued KICK lebellium |
| 15:01:15 | lebellium | Searching through ICR logs, you can find another user getting the same issue back to 2021: https://www.rockbox.org/irc/log-20210615 |
| 15:01:18 | lebellium | https://www.rockbox.org/irc/log-20170108 (12:17): I also got an error with the S615 and pamaury replied it used a too old Linux kernel to be supported |
| 15:01:21 | lebellium | Meanwhile he extracted the NVP map from each Sony player's Linux kernel (root/utils/nwztools/database/nvp), including the S615, that's why this device may seem to be supported in the tool and why the error message is a bit different ("This device doesn't have node 'shp'" vs "Cannot read node 'shp') but as despite the known NVP map we are not able to read the 'shp' node from the device, we can't do anything. |
| 15:01:26 | lebellium | I'm afraid there is no solution here. |
| 15:13:27 | kirvesAxe | _bilgus_, actually you might be right, it might actually even need a licensing fee B$ |
| 15:16:53 | Nyaa | the trick is to just not be in europe where software patents are invalid lol |
| 15:16:56 | Nyaa | er |
| 15:16:59 | Nyaa | sleepy |
| 15:17:03 | Nyaa | the trick is to be in europe* |
| 15:17:08 | Nyaa | or not in the usa, more specifically |
| 15:19:43 | kirvesAxe | Only sharing exFAT-compatible rockbox from europe-based servers? lol |
| 15:20:17 | Nyaa | most countries don't consider software patents valid lol |
| 15:21:09 | | Quit jacobk (Ping timeout: 252 seconds) |
| 15:21:14 | kirvesAxe | yeah. |
| 15:21:24 | Nyaa | they treat software like maths |
| 15:22:20 | Nyaa | a specific implementation can be copyright, but the method itself doesn't have any protections |
| 15:24:46 | | Quit othello7 (Quit: othello7) |
| 15:31:01 | Nyaa | tbf some of the codecs shipped in rockbox are also covered by software patents, no? |
| 15:36:46 | buZz | likely even .wav is patented |
| 15:36:58 | Nyaa | the patent is probably expired by now |
| 15:37:01 | buZz | patents dont really limit using tech though :) |
| 15:37:11 | Nyaa | like how mp3's patent expired |
| 15:37:11 | buZz | unless you plan on selling rockbox |
| 15:37:35 | buZz | i dont believe mpeg1 was patented? |
| 15:38:16 | buZz | maybe some en/decoder implementation though |
| 15:39:23 | Nyaa | buZz, mmm, looks like US courts have deemed noncommercial use also falls under the patents |
| 15:39:42 | buZz | well, ~99.6% of nations globally arent the US ;) |
| 15:39:58 | Nyaa | yes but the us is also basically the only place that has software patents |
| 15:40:10 | Nyaa | [japan does too but they're far more limited than the usa's] |
| 15:40:11 | buZz | easiest to ignore then :D |
| 15:41:40 | Nyaa | iirc, japan's software patents are limited to the case where such software ties with a specific piece of hardware |
| 15:46:15 | Nyaa | ah, the UK also seems to have software patents, but aside from that, doesn't look like a single software patent has been successfully enforced in the EU |
| 15:46:57 | Nyaa | [tricking the patent office into issuing a patent by phrasing your patent funny, and being able to actually enforce it, are different things] |
| 15:47:10 | spork | there are much bigger and richer targets than a nice jukebox software for abandonned hardware |
| 15:47:22 | Nyaa | yeah probably, you never know though |
| 15:47:40 | Nyaa | a company could pull a nintendo and decide to sue you anyway |
| 15:48:40 | spork | make it a plugin |
| 15:50:36 | speachy | exFAT is still patented, but effectively (if not explicitly) license/royalty free due to MS's actions. |
| 15:50:52 | speachy | as for ext2, it's a LOT more complicated than FAT32. |
| 15:51:41 | buZz | patenting something doesnt explicitly prevent people from using it |
| 15:51:42 | speachy | and there's the beginning of an MTP implementation in gerrit, would be a good starting place. |
| 15:52:59 | speachy | preventing others from using it (without permission, which usually means royalties) is the entire point of patents. |
| 15:53:36 | speachy | (well, "to promote progress in the arts" is the "point" of patents, but "exclusive use" is the mechanism) |
| 15:54:24 | speachy | of course, patents eventually expire. |
| 15:54:37 | Nyaa | wonder if it would be possible to make filesystem stuff also loadable via a plugin-like system |
| 15:54:49 | speachy | and the patent holder doesn't _have_ to enforce it offensively. |
| 15:55:06 | speachy | (unlike trademarks, there's no "use it or lose it" principle) |
| 15:55:57 | speachy | possible, of course. worth the effort? I highly doubt it. |
| 15:56:14 | speachy | what's the benefit? |
| 15:56:47 | speachy | (especially considering that, for example, our bootloaders need to be able to access the filesystems too) |
| 15:57:07 | Nyaa | right, but it could be done in a similar method to how EFI does it |
| 15:57:19 | Nyaa | where you have a fat32 partition the bootloader loads the next stage of stuff out of |
| 15:58:04 | *** | Saving seen data "./dancer.seen" |
| 15:58:39 | | Join jacobk [0] (~quassel@utdpat241106.utdallas.edu) |
| 16:00 |
| 16:02:30 | Nyaa | [plus having a bootloader partition would open up opportunity for having a configurable bootloader menu, easily booting multiple versions of rockbox, etc] |
| 16:03:23 | speachy | at that point we might as well just use Linux. |
| 16:04:20 | Nyaa | i mean, linux would probably handle threading better lol |
| 16:04:22 | speachy | and stop reinventing the wheel |
| 16:04:41 | buZz | :D |
| 16:04:49 | buZz | doesnt rockbox already target linux? |
| 16:04:58 | buZz | as standalone SDL application or something |
| 16:05:27 | speachy | our crappiest (ie arm7tdmi/arm9tdmi) targets are mostly SOL, but everything else has the capabilities to run a full OS with an MMU etc. |
| 16:05:59 | Nyaa | i mean µClinux exists |
| 16:06:01 | buZz | armv5 without mmu should be able to run uClinux just fine |
| 16:06:04 | buZz | :) |
| 16:06:14 | speachy | yeah, we can run as a native Linux application. We also have an SDL application, but that's not used on actual player hardware normally. |
| 16:06:28 | buZz | thusfar ;) |
| 16:06:40 | speachy | uClinux is not worth the effort here, as it's IMO the worst of both worlds. |
| 16:06:49 | Nyaa | lol |
| 16:07:36 | speachy | thusfar because none of our "hosted" targets actually include SDL. We directly use the linux APIs instead of having to deal with adding SDL on top of that too. |
| 16:07:47 | Nyaa | probably a good idea lol |
| 16:09:00 | speachy | uClinux gives us drivers and tht sort of thing but "userspace" is a complete cluster-f |
| 16:10:08 | speachy | if we wanted to scrap the linux builds on these players and roll our own, we could end upw ith a much nicer system overall. Except for teh minor detail that there's no kernel sources for any of these things and we'd therefore have to port Linux ourselves. |
| 16:10:46 | speachy | (at _best_ there's an ancient kernel drop −− I think Sony was generally GPL compliant −− but the rest... nope) |
| 16:10:48 | Nyaa | oh wait upstream linux can already be compiled without using mmu |
| 16:11:41 | speachy | yes, but uclinux (ie mmu-less linux) has some major restritions on what "userspace" entails. binaries have to be specially compiled for it, lots of restritions, and no executable relocation is possible. |
| 16:12:13 | Nyaa | yeah but if you're going to only run a single application [rockbox] that probably doesn't matter |
| 16:12:42 | speachy | we still ahve to deal with the overhead even if it's just one application. |
| 16:13:11 | speachy | (overhead of maintaining our own complete "userspace", that is) |
| 16:13:46 | Nyaa | isn't there already a "userspace" of sorts |
| 16:14:10 | speachy | no such thing as generic userspace. it owuld need to be compiled for each target, based on how we've configured the kernel etc. |
| 16:15:33 | Nyaa | hmm, just compile as a kernel module, problem solved /s |
| 16:15:41 | speachy | (by that I mean libc (+ anything else we need) |
| 16:16:42 | Nyaa | don't need to care about userspace if you just run in kernelspace |
| 16:18:49 | speachy | either way the code has to be written. |
| 16:20:13 | speachy | and by doing that you lose the advantage of readily-available libraries. Plus you still need some minimal userspace, if only an init process. |
| 16:21:16 | speachy | given the amount of effort (vs return) there are much better uses of time, but far be it for me to say what one should or shouldn't do. |
| 16:44:01 | | Quit jacobk (Ping timeout: 258 seconds) |
| 16:49:45 | Nyaa | i wonder if upstream opus would care about the performance on armv4 targets |
| 16:52:14 | | Join jacobk [0] (~quassel@129.110.242.224) |
| 16:59:38 | Nyaa | also don't all ARM7DMI chips that have a cache also have an MMU? |
| 16:59:51 | Nyaa | ARM7TDMI* |
| 17:00 |
| 17:05:23 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 17:05:23 | * | Nyaa wonders |
| 17:06:13 | Nyaa | on the ipod targets, are codecs running out of SDRAM or IRAM? |
| 17:26:37 | | Join othello7 [0] (~Thunderbi@pool-100-36-166-8.washdc.fios.verizon.net) |
| 17:45:47 | Nyaa | ??? |
| 17:46:14 | Nyaa | i changed one option in the makefile and ran test again and got 120% realtime with dsp |
| 17:46:18 | * | Nyaa unsets it and tests again |
| 17:51:27 | | Quit lebellium (Quit: Leaving) |
| 17:58:06 | *** | Saving seen data "./dancer.seen" |
| 18:00 |
| 18:21:00 | | Quit jacobk (Ping timeout: 252 seconds) |
| 18:21:36 | | Join jacobk [0] (~quassel@utdpat241106.utdallas.edu) |
| 19:00 |
| 19:33:36 | | Quit jacobk (Ping timeout: 252 seconds) |
| 19:56:17 | _bilgus | be mindful of running stuff in the BGD i usually boot a clean install no db only the settings being tested and just the test files |
| 19:57:01 | Nyaa | yeah i can't seem to get numbers that bad now lol |
| 19:57:38 | Nyaa | though it would make more sense to do tests with background stuff given that's more representative of real world usage |
| 19:58:07 | *** | Saving seen data "./dancer.seen" |
| 19:58:10 | _bilgus | only if you can replicate them |
| 19:58:14 | _bilgus | ... |
| 19:59:42 | Nyaa | that's the thing about real world usage, you'll never get the same results twice :p |
| 19:59:54 | Nyaa | but you can repeat the test multiple times and do a statistical analysis |
| 20:00 |
| 20:02:01 | _bilgus | or just do it clean and assume you need 150 to be safe |
| 20:02:48 | Nyaa | time to mod the ipod to use the case for a heatsink and just overclock it past 80mhz lol |
| 20:03:28 | _bilgus | worked for my ti-86 |
| 20:03:38 | Nyaa | i have one of those lol |
| 20:03:43 | Nyaa | also a ti-85 and a ti-81 |
| 20:03:50 | _bilgus | best eng calc ever |
| 20:04:00 | Nyaa | the 85 is dead though [was when i got it lol] |
| 20:04:04 | Nyaa | been meaning to fix it |
| 20:04:31 | Nyaa | mild water damage and probably a dead fuse or zener diode somewhere |
| 20:04:57 | _bilgus | likely bad ribbon cable water will corrode them off the board |
| 20:05:20 | Nyaa | don't remember seeing any damage near ribbon cables |
| 20:05:24 | Nyaa | only near battery compartment |
| 21:00 |
| 21:37:49 | _bilgus | Nyaa, id try adding back some of the ICONST tags and such and see if it fits and if it makes it faster https://gerrit.rockbox.org/r/c/rockbox/+/2057/5/lib/rbcodec/codecs/libopus/celt/cwrs.c#b421 |
| 21:47:46 | Nyaa | putting decoding look in IRAM would definitely help on pp5002 given hardware bug but idk if it would help on pp5020/pp5022 |
| 21:48:02 | Nyaa | loop* |
| 21:48:51 | Nyaa | with pp5002 anything running from sdram is effectively running at half clock rate due to said bug |
| 21:58:10 | *** | No seen item changed, no save performed. |
| 22:00 |
| 22:00:07 | _bilgus | another https://gerrit.rockbox.org/r/c/rockbox/+/2057/5/lib/rbcodec/codecs/libopus/celt/entcode.c |
| 22:01:15 | _bilgus | probably explains the usual ifdefs around those pp50xx |
| 22:20:20 | _bilgus | final one https://gerrit.rockbox.org/r/c/rockbox/+/2057/5/lib/rbcodec/codecs/libopus/celt/static_modes_fixed.h |
| 22:35:08 | Nyaa | it's the SILK code mostly |
| 22:35:20 | Nyaa | encoded celt-only results in ~160% realtime with dsp |
| 22:36:05 | Nyaa | well SILK/Hybrid are the slower ones |
| 22:38:34 | Nyaa | SILK gets ~110% realtime with dsp, Hybrid gets ~120% realtime with dsp, and CELT gets ~160% realtime with dsp |
| 22:53:21 | | Quit LjL (Quit: Scappò via con la paura di arrugginire. Il giornale di ieri lo dà morto arrugginito. I becchini ne raccolgono spesso fra la gente che si lascia piovere addosso.) |
| 22:54:45 | | Join LjL [0] (~ljl@user/ljl) |
| 23:00 |
| 23:34:38 | | Quit buZz (Ping timeout: 246 seconds) |
| 23:34:46 | | Join buZz [0] (~buzz@proletaric.artisnotcrime.com) |
| 23:58:13 | *** | Saving seen data "./dancer.seen" |
icon identifies that the person is a core developer (has commit access).