| 00:25:52 | aaabbb | _bilgus_: just better battery efficiency while also maximizing compression efficiency |
| 00:28:05 | *** | Saving seen data "./dancer.seen" |
| 00:30:10 | aaabbb | and opus is not that much worse than vorbis, but has amazing compression efficiency (80kbps is more than enough for me) |
| 00:34:29 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 00:38:55 | | Quit dconrad (Ping timeout: 244 seconds) |
| 00:58:12 | | Quit massive_H (Quit: Leaving) |
| 01:00 |
| 01:07:08 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 01:11:30 | | Quit dconrad (Ping timeout: 252 seconds) |
| 01:55:53 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 02:00 |
| 02:00:06 | | Quit dconrad (Ping timeout: 246 seconds) |
| 02:28:08 | *** | Saving seen data "./dancer.seen" |
| 02:44:20 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 02:48:37 | | Quit dconrad (Ping timeout: 248 seconds) |
| 02:58:51 | | Quit othello7 (Ping timeout: 252 seconds) |
| 03:00 |
| 03:08:42 | | Join Burak_ [0] (~Burak@185.25.123.34) |
| 03:12:04 | | Quit sebagala (Ping timeout: 260 seconds) |
| 03:32:59 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 03:37:21 | | Quit dconrad (Ping timeout: 252 seconds) |
| 03:39:11 | edhelas_ | Hi :) ! |
| 03:39:11 | edhelas_ | It seems that some changes were made regarding Lastfm scrobbling recently, I don't have to launch the plugin anymore on start ? How does it work ? |
| 03:39:11 | edhelas_ | Also, when opening the .scrobbler.log file on iPod Classic, what is the shortcut to quit the viewer ? |
| 04:00 |
| 04:02:03 | | Quit PheralSparky (Read error: Connection reset by peer) |
| 04:04:36 | | Quit jacobk (Ping timeout: 276 seconds) |
| 04:05:11 | | Join jacobk [0] (~quassel@47-186-65-73.dlls.tx.frontiernet.net) |
| 04:06:45 | | Join PheralSparky [0] (~S|h|a|w|n@user/shawn/x-4432647) |
| 04:21:34 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 04:25:42 | | Quit dconrad (Ping timeout: 246 seconds) |
| 04:28:09 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:05:46 | | Quit jn (Remote host closed the connection) |
| 05:08:23 | | Join jn [0] (~quassel@user/jn/x-3390946) |
| 05:10:11 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 05:14:42 | | Quit dconrad (Ping timeout: 252 seconds) |
| 05:19:26 | | Quit jn (Remote host closed the connection) |
| 05:21:21 | | Join jn [0] (~quassel@2a0a-a549-9227-0-20d-b9ff-fe49-15fc.ipv6dyn.netcologne.de) |
| 05:21:22 | | Quit jn (Changing host) |
| 05:21:22 | | Join jn [0] (~quassel@user/jn/x-3390946) |
| 05:27:07 | | Quit PheralSparky (Read error: Connection reset by peer) |
| 05:37:40 | | Quit winsim-buildbot (Ping timeout: 272 seconds) |
| 05:38:19 | | Join winsim-buildbot [0] (~lamest@85-218-172-116.norlyscustomer.net) |
| 05:53:12 | | Quit jn (Ping timeout: 252 seconds) |
| 05:58:42 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 05:59:02 | | Quit thanosengine (Quit: WeeChat 4.5.1) |
| 06:00 |
| 06:03:00 | | Quit dconrad (Ping timeout: 252 seconds) |
| 06:04:36 | | Join jn [0] (~quassel@user/jn/x-3390946) |
| 06:28:10 | *** | Saving seen data "./dancer.seen" |
| 06:47:21 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 06:51:46 | | Quit dconrad (Ping timeout: 248 seconds) |
| 07:00 |
| 07:28:09 | | Quit jn (Ping timeout: 260 seconds) |
| 07:35:37 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 07:40:00 | | Quit dconrad (Ping timeout: 244 seconds) |
| 08:00 |
| 08:04:49 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 08:04:59 | speachy | aaabbb: arm-specific optimizations were untouched; if anything there were slightly more in newer upstream, though most of it wasn't relevant for the ancient armv4t on the ipods |
| 08:05:37 | speachy | but yes, I added back all of the hot-paths-in-TCM annotations that I could find. it wasn't sufficient to get m68k to play back in realtime for higher bitrate files. |
| 08:09:03 | | Quit dconrad (Ping timeout: 252 seconds) |
| 08:14:51 | | Quit paulk (Ping timeout: 268 seconds) |
| 08:15:20 | | Join paulk [0] (~paulk@about/aquilenet/user/paulk) |
| 08:28:13 | *** | Saving seen data "./dancer.seen" |
| 08:31:49 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 08:31:56 | | Join thanosengine [0] (~thanos@user/thanosengine) |
| 08:31:59 | OlsroFR | Someone reported a crash (regression ?) on the iPod Nano: https://www.reddit.com/r/ipod/comments/1inf388/so_i_just_got_my_first_ipod_nano_1g_and_installed/ |
| 08:32:00 | speachy | hmm, one more change, not sure if it'll fit. |
| 08:34:28 | speachy | OlsroFR: without even the minimum info like "what version" it's a worthless bug report. |
| 08:35:14 | OlsroFR | I just sent this "What version of Rockbox do you use ? Does it happen every time ? Try the latest nightly and retry please" |
| 08:35:23 | OlsroFR | let's see |
| 08:48:53 | OlsroFR | aaabbb If you want the best quality & battery efficiency, there's musepack (at quality q4 or q5). It would soon much better/safer than mp3 in all cases, and can be decoded even faster |
| 08:49:20 | OlsroFR | opus has the best bitrate efficiency but is hard to decode so pushing hard the CPU, especially with old iPods |
| 08:49:41 | OlsroFR | It would do*/perform much better/safer than mp3 |
| 08:52:05 | | Join qf1 [0] (~qf@user/qf) |
| 08:52:19 | speachy | ok, let's see if this builds successfully on all targets. |
| 08:52:48 | OlsroFR | Don't expect a big difference of battery life between aac and mp3/musepack though, I made benchmarks and it is pretty marginal. It was less than 1 hour. AAC is a very good format to use with Rockbox, the modern Apple encoder with VBR gives a very solid reproduction starting 128kbps |
| 08:53:01 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 08:53:16 | speachy | basically it pushes the entire opus decoder state (~26K) into IRAM. |
| 08:53:38 | OlsroFR | Will this improve the decoding speed ? |
| 08:53:54 | OlsroFR | I remember that opus was particularly slow to decode, making the UI lags a lot on older iPods |
| 08:54:23 | OlsroFR | I have my audiobooks encoded in opus, so I will be very curious to test this, see if it will improve the experience |
| 08:54:42 | speachy | on the slowest devices, probably. |
| 08:54:58 | speachy | but just how much... *shrug* |
| 08:55:12 | OlsroFR | I saw the benchmarks and the Classics are already fast enough to decode it in real time without boost |
| 08:55:36 | speachy | (this might be the final piece that allows the old m68k targets to decode higher bitrate opus realtime |
| 08:56:52 | speachy | other arm7tdmi decixes (especially the older 1g-3g ipods) should see some improvement |
| 08:56:59 | OlsroFR | really exciting. OPUS is the most "next-gen" lossy codec |
| 08:57:35 | OlsroFR | now it supports even embedded album art on rockbox thanks to a recent patch |
| 08:57:37 | | Quit dconrad (Ping timeout: 248 seconds) |
| 08:57:59 | | Quit OlsroFR (Quit: Client closed) |
| 08:58:19 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 08:58:22 | OlsroFR | this make it very interesting to encode a lot of music for iPod Nanos that are heavily space contrained |
| 08:58:27 | aaabbb | yeah if i wasn't using opus i would use either vorbis or mpc, certainly not mp3 |
| 08:59:33 | speachy | unless you artifically constrain the bitrates the typical listening environment (and real-world ears) makes hearing these differences pretty much impossible. |
| 08:59:53 | aaabbb | mp3's differences? |
| 09:00 |
| 09:00:05 | speachy | mp3 vs vorbis vs aac vs whatever |
| 09:00:12 | aaabbb | oh right |
| 09:00:41 | aaabbb | but i like cramming lots of audio in so i use the lowest bitrate that is transparent to me |
| 09:00:51 | OlsroFR | mp3 is a very bad VBR codec, limited by the specs. But yeah in real conditions, lossy numeric encoders are very good nowadays |
| 09:01:11 | speachy | meaning the newer codecs do much better at lower bitrates but for non-streaming purposes (ie where bandwidth/space doesn't matter) it's pretty much indistinguishable |
| 09:01:15 | aaabbb | so for opus that is around 80kbps, for mp3 it's closer to 160 |
| 09:01:22 | speachy | yep |
| 09:01:57 | aaabbb | i know better trained ears can abx 96kbps for some samples, but my equipment and ears are not good enough for that |
| 09:02:10 | aaabbb | but that means that, for somewhat less battery life, i get literally double useful storage space |
| 09:02:41 | speachy | and "oh no I can only fit 8000 tracks instead of 15000" isn't exactly that big of a deal, when the actual real-world price difference is like $10. :D |
| 09:03:04 | aaabbb | true lol |
| 09:03:33 | speachy | and again, except for the oldest devices the analog path is the main power driver, not the CPU decoding. |
| 09:03:46 | aaabbb | it is? |
| 09:03:51 | aaabbb | what counts as "oldest"? |
| 09:04:38 | speachy | because the analog stuff is always on, and the SoC/memory/etc is always powered up fully because you have to continually pump data from memory into the audio codec. |
| 09:04:57 | speachy | only the cpu core itself gets to idle, everything else doesn't |
| 09:05:46 | speachy | eg on my mostly-modern xduoox3, I implemented full dynamic reclocking and it made no measureable difference in battery life even when running the core at 1/3 the speed all the time. |
| 09:06:05 | aaabbb | 4g ipod here |
| 09:06:19 | aaabbb | which is arm9 i think? |
| 09:06:23 | speachy | oldest meaning the m68k irivers since they're so old and relatively non-integrated |
| 09:06:28 | aaabbb | ahhh |
| 09:06:29 | speachy | 4g ipod is arm7tdmi |
| 09:06:36 | aaabbb | what about 5/6g? |
| 09:06:55 | speachy | that's an arm920 or arm926 I think |
| 09:07:01 | OlsroFR | 5g is almost feeling as slow as your 4g, very similar feeling |
| 09:07:13 | OlsroFR | but the 6g+ have a huge difference |
| 09:07:21 | OlsroFR | much faster CPU/GPU/IO |
| 09:07:27 | aaabbb | i assume 5g and 4g are roughly similar in terms of the speedup they get from moving things into tcm? |
| 09:07:40 | speachy | (armv5 instruction set, clock-for clock those things are something like double the performance to the arm7tdmi) |
| 09:07:45 | aaabbb | they both have like what, 32k dtcm or something like that |
| 09:08:01 | | Quit OlsroFR (Quit: Client closed) |
| 09:08:01 | speachy | yeah, I think the 4g and 5g are effectively the same SoC. |
| 09:08:29 | speachy | TCM and IRAM aren't necessarily the same thing. |
| 09:09:29 | aaabbb | i don't know much about arm but what i think is that tcm is basically just addressable cache, same performance as an l1 cache hit so effectively zero memory latency. is iram the same in that way? |
| 09:09:30 | speachy | TCM->IRAM->External RAM |
| 09:09:47 | speachy | cache is anotehr layer below that |
| 09:10:13 | aaabbb | right but internally, cache is implemented same way tcm is. and usually cache is disabled for the tcm address ranges since it would be pointless |
| 09:10:19 | speachy | the idea being that TCM typically runs at the full clock speed of the core but might be bandwidth constrained vs the cache. |
| 09:10:25 | aaabbb | at least on some older arm9s i worked with ages ago |
| 09:11:25 | speachy | a good rule of thumb is that each level is an order of magnitude slower |
| 09:12:26 | speachy | sweet, it built cleanly |
| 09:12:37 | speachy | grab it from: https://build.rockbox.org/ |
| 09:13:11 | aaabbb | last question then i'll leave you be, the opus optimizations you put back in used both tcm as well as iram? |
| 09:13:20 | aaabbb | hottest paths in tcm and second hottest in iram, where possible? |
| 09:14:02 | speachy | just IRAM. |
| 09:14:19 | aaabbb | ahh |
| 09:14:44 | aaabbb | then i imagine there is not much extra performance to gain with tcm |
| 09:14:45 | speachy | offhand I don't know what's in TCM (at least on the PP SoCs −− that may be per-cpu TCM which makes managing things more complicated) |
| 09:15:25 | aaabbb | i would assume that the heaviest cpu use would be the decoders, so that the rockbox os probably wouldn't put anything into the tcm itself, right? |
| 09:15:58 | speachy | the reason IRAM makes such a difference on the m68k targets is that there's no data cache. |
| 09:16:15 | aaabbb | ohhh |
| 09:16:50 | aaabbb | so then on newer devices like 4/5/6g ipods, the cache is probably big enough that manually putting things in iram does not give much of a speedup, much less manually putting things in tcm |
| 09:17:56 | speachy | aaabbb: decoders are cpu-intensive but not necessarily the most common. typically we reserve a chunk of IRAM for decoder use but it's a balancing act. stuff like memcpy, display routines, and other stuff that gets hit _far_ more often is usually prioritized |
| 09:18:46 | aaabbb | there's nothing that dynamically moves it, like when the system is not being interracted with, move the stuff needed to redraw out of iram, and then while the user is interacting with the ui, move it back into iram? |
| 09:19:17 | speachy | rockbox doesn't appear to distinguish between TCM and IRAM on the PP SoC. (and IRAM is only 48K total) |
| 09:19:32 | aaabbb | pp? |
| 09:19:50 | speachy | PlayerPortal, the family of SoCs that the pre-6g ipods use |
| 09:19:57 | aaabbb | oh i see |
| 09:20:02 | speachy | (and numerous others) |
| 09:20:03 | aaabbb | maybe they are the same thing on those socs? |
| 09:20:09 | speachy | might be |
| 09:20:28 | speachy | I don't have a datasheet handy |
| 09:20:49 | aaabbb | on the devices i worked on, tcm was split into itcm and dtcm (instruction and data). is iram limited like that? like cannot hold executable code? |
| 09:21:07 | aaabbb | on the pp soc that is |
| 09:21:36 | speachy | we don't put any code into the IRAM on the PPs |
| 09:22:17 | aaabbb | thank you for answering so many questions. at this point i'll get out of your hair and start looking through the code :) |
| 09:22:49 | speachy | https://git.rockbox.org/cgit/rockbox.git/tree/firmware/target/arm/pp/app-pp.lds |
| 09:22:59 | aaabbb | thank you! |
| 09:23:55 | speachy | moving code in and out of IRAM/TCM requires relocatable code (or overlays) and that swapping can easily dwarf any gains. |
| 09:24:35 | aaabbb | presumably the swapping would be rare, ie only when a user starts interacting with the ui and 1s after they stop interacting with it or something |
| 09:24:51 | speachy | consider OS context switches. |
| 09:25:23 | speachy | or even more coarsely, what if the screen is active and there's playback happening? |
| 09:25:28 | aaabbb | i can see how the code for that would be kept in iram at all times, but i was thinking of things for eg ui redrawing, displaying playlists etc |
| 09:25:51 | aaabbb | very fast redraw when only a progress bar is showing is not as important as when scrolling through a playlist |
| 09:25:56 | aaabbb | i would think |
| 09:26:02 | speachy | most UI stuff is limited by the person, there's no need to hyper-optimize things to that extent |
| 09:26:31 | aaabbb | oh ok, i assumed that things like drawing directory listings, thumbnails etc would be heavy on the cpu |
| 09:26:45 | speachy | but storing the framebuffer in IRAM (and often enough, low-level drawing routines) definitely helps overall. |
| 09:27:22 | speachy | otherwise, who cares if scrolling a list takes 50us longer? :D |
| 09:27:51 | aaabbb | i guess i majorly overestimated how much work scrolling takes :P |
| 09:28:23 | speachy | don't get me wrong, it's a _lot_ of work when you consider the whole stack but it's operating on human scale. |
| 09:28:51 | speachy | (and the data/code sizes we're working with usually vastly outstrip available IRAM) |
| 09:29:32 | | Quit TorC (Ping timeout: 244 seconds) |
| 09:29:37 | | Quit qf1 (Ping timeout: 248 seconds) |
| 09:32:45 | | Join TorC [0] (~Tor@fsf/member/TorC) |
| 09:38:31 | _bilgus_ | edhelas_, https://download.rockbox.org/daily/manual/rockbox-agptekrocker/rockbox-buildch11.html#x14-33000011.4.12 |
| 09:41:47 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 09:46:30 | | Quit dconrad (Ping timeout: 276 seconds) |
| 09:52:52 | _bilgus_ | aaabbb, display updates of text are actually the most intensive regular functions on the device |
| 09:53:46 | _bilgus_ | so in a round about way scrolling is expensive but really not much more than just refreshing static text |
| 09:55:18 | _bilgus_ | edhelas_, run the plugin once it'll ask you to enable playback logging, do your options now or w/e save and exit, now play some songs and run the plugin again it'll now have a export option |
| 09:56:25 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 09:57:10 | OlsroFR | +speachy I just tested the new OPUS code with my 4th gen. I still get some minor UI lags, but it seems better. It's convenient. I can play/pause etc, go back to the filebrowser menu, etc, and it does not freeze during many seconds anymore |
| 09:57:24 | OlsroFR | the experience seems pretty close now than what I get when playing AAC |
| 09:58:49 | _bilgus_ | edhelas_, to quit the viewer long press on an item and choose 'quit' |
| 09:58:53 | OlsroFR | I am going to enable the peak meter again on my theme for OPUS files, to see if it's usable. I had to disable it because it was making the experience even more laggier |
| 10:00 |
| 10:02:15 | OlsroFR | OK I confirm that opus + peak meter is still very usable now.... very good work, that's awesome really |
| 10:02:54 | OlsroFR | wow I spoke a bit too fast. Modifying the volume is very laggy now |
| 10:03:22 | OlsroFR | https://themes.rockbox.org/index.php?themeid=3541&target=ipod4g my theme (I just modified slightly the WPS to disable the condition on the opus format) |
| 10:05:38 | OlsroFR | OK. Now that I disabled the peak meter again in the theme, I can modify volume smoothly again |
| 10:06:16 | _bilgus_ | OlsroFR, I slowed down the peak meter so its likely better than it was a few months ago |
| 10:06:36 | _bilgus_ | its sill quite expensive.. |
| 10:06:52 | OlsroFR | So to conclude it's better than before, but it's still noticeably slower than AAC, and expensive enough to need me to put a theme condition to disable the peak meter completely here |
| 10:07:48 | OlsroFR | just tested with an Apple AAC TVBR -q99 file, and here I can modify the volume smoothly while it is playing and while the peak meter is jumping around |
| 10:14:02 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 10:16:40 | _bilgus_ | they aren't that much different in realtime required I'd have expected less difference |
| 10:18:37 | | Quit dconrad (Ping timeout: 244 seconds) |
| 10:18:45 | _bilgus_ | I guess depends on the quality it gos anywhere from a bit higher than AAC to double it |
| 10:21:36 | OlsroFR | _bilgus_ My opus files are audiobooks encoded at .opus 40kbps (stereo files, 20kbps per channel) |
| 10:24:02 | _bilgus_ | gerrits giving me strife tody |
| 10:28:15 | *** | Saving seen data "./dancer.seen" |
| 10:36:27 | | Quit OlsroFR (Quit: Client closed) |
| 10:41:18 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 10:43:16 | Xogium | looks like they were having exactly the same issue as I do, then. Trying to move the wheel with opus files playing is causing impressive lag |
| 10:43:46 | Xogium | I have no idea how the default theme is regarding the peak meter, but |
| 10:43:56 | Xogium | maybe related ? |
| 10:45:55 | | Quit dconrad (Ping timeout: 268 seconds) |
| 10:46:11 | | Join qf1 [0] (~qf@user/qf) |
| 10:56:59 | edhelas_ | _bilgus_ exported lines are not compatible with my scrobbler upload app |
| 10:57:01 | edhelas_ | SupertrampBrother Where You BoundEver Open Door6182L1738749366b4a66ea0-a029-477a-8ed8-76a26ac14455 |
| 10:57:01 | edhelas_ | Breakfast ClubBreakfast ClubNever Be the Same1243L1738750609 |
| 10:57:10 | edhelas_ | First one is valid, second one doesn't show up |
| 10:57:35 | edhelas_ | It misses the UUID at the end |
| 10:57:44 | _bilgus_ | hmm should be the same format |
| 10:58:40 | edhelas_ | https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/11EMFOkt1JXC/chat_.scrobbler |
| 11:00 |
| 11:00:15 | edhelas_ | Here's the file, only the Supertramp - Brother Where You Bound lines appears in my app, they were lines added by the plugin before the "export" changes |
| 11:01:28 | _bilgus_ | edhelas_, the log gets saved as playback.old rename it to .log again so you can keep your data |
| 11:04:49 | edhelas_ | Ok it seems that a <tab> is needed when there's no musicbrainz_track_id to append, to make the number of columns matches |
| 11:05:14 | edhelas_ | After adding a <tab> I was able to parse correctly the line in my client |
| 11:07:36 | _bilgus_ | hmm that means it failed with the old code too |
| 11:07:44 | _bilgus_ | I didn't change the formatting |
| 11:08:06 | _bilgus_ | you just happened to catch it with no mb ids |
| 11:08:39 | | Quit jacobk (Ping timeout: 260 seconds) |
| 11:09:03 | _bilgus_ | I'll push something by this eve could you give it a test in the next day or two to make sure it work for you? |
| 11:11:45 | _bilgus_ | I might be able to get something out now if gerrit will cooperate |
| 11:12:23 | speachy | yeah I rememer seeing folks complain about that formatting thing |
| 11:12:32 | speachy | but what we generate is actually legal |
| 11:12:49 | speachy | because that missing field is officially optional |
| 11:15:29 | _bilgus_ | its doing something weird though\ |
| 11:15:45 | _bilgus_ | in his bad file it just cuts the line off |
| 11:16:14 | _bilgus_ | the format has a hardcoded /t there but its not showing |
| 11:16:27 | _bilgus_ | maybe running out of buffer but I doubt it |
| 11:17:30 | _bilgus_ | my log however has it :/ |
| 11:18:10 | _bilgus_ | oh it is using fdprintf anyway so no buffer issue |
| 11:22:46 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 11:25:31 | _bilgus_ | could it be doing something weird like getting a escape char in mb_id that makes it discard the rest? empty string gets skipped by print f "" so what else could cause it to skip the last /t but not /lf |
| 11:27:30 | | Quit dconrad (Ping timeout: 260 seconds) |
| 11:36:47 | _bilgus_ | edhelas_, I'm not sure whats going on there it outputs fine on my device |
| 11:37:12 | _bilgus_ | \t after timestamp if mbid is missing |
| 11:48:29 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 11:57:34 | | Quit qf1 (Ping timeout: 252 seconds) |
| 11:57:37 | | Join qf [0] (~qf@user/qf) |
| 11:58:03 | _bilgus_ | I'll add a check for write errors thats all I can think of |
| 12:00 |
| 12:11:11 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 12:15:32 | | Quit dconrad (Ping timeout: 252 seconds) |
| 12:25:01 | | Join jacobk [0] (~quassel@utdpat242060.utdallas.edu) |
| 12:28:17 | *** | Saving seen data "./dancer.seen" |
| 12:43:50 | | Join jn [0] (~quassel@2a0a-a549-9227-0-20d-b9ff-fe49-15fc.ipv6dyn.netcologne.de) |
| 12:43:50 | | Quit jn (Changing host) |
| 12:43:50 | | Join jn [0] (~quassel@user/jn/x-3390946) |
| 12:55:58 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 13:00 |
| 13:00:21 | | Quit dconrad (Ping timeout: 248 seconds) |
| 13:24:34 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 13:28:52 | | Quit dconrad (Ping timeout: 252 seconds) |
| 13:32:42 | | Quit jacobk (Ping timeout: 276 seconds) |
| 13:44:49 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 13:50:54 | | Quit dconrad (Ping timeout: 276 seconds) |
| 14:00 |
| 14:07:00 | | Quit qf (Ping timeout: 252 seconds) |
| 14:09:18 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 14:09:35 | OlsroFR | got myself an USB tester |
| 14:09:35 | OlsroFR | With the modded USB cable (on Rockbox): |
| 14:09:36 | OlsroFR | 4th gen mono + real USB cable: 0.05A |
| 14:09:36 | DBUG | Enqueued KICK OlsroFR |
| 14:09:36 | OlsroFR | 4th gen mono + modded USB cable: 0.57A |
| 14:09:37 | OlsroFR | Fully charged iFlash Solo modded 7th gen: |
| 14:09:37 | *** | Alert Mode level 1 |
| 14:09:37 | OlsroFR | 7th gen+real USB cable: 0.07A/0.09A |
| 14:09:38 | *** | Alert Mode level 2 |
| 14:09:38 | OlsroFR | 7th gen+modded USB cable: 0.11A when idle, 0.23A when starting to play a new song |
| 14:09:38 | *** | Alert Mode level 3 |
| 14:09:38 | OlsroFR | the solution seems evident: find a dock that is compatible with the firewire charging protocol. |
| 14:09:39 | *** | Alert Mode level 4 |
| 14:09:39 | OlsroFR | On Stock OS: |
| 14:09:39 | *** | Alert Mode level 5 |
| 14:09:39 | OlsroFR | 7th gen fully charged+real USB cable: 0.07A/0.09A. Around 0.15A when playing Asphalt 4. |
| 14:09:40 | *** | Alert Mode level 6 |
| 14:09:40 | OlsroFR | With modded USB cable, it's almost the same |
| 14:10:24 | OlsroFR | as a power delivery method, I use an android generic fast charger. Also, no matter if using the cable that "simulate" high speed charging, it's always 5V, never 12V like firewire. |
| 14:11:09 | OlsroFR | So, for the 4th gen/minis (who also discharge) when docking, there probably no possible software solutions. For the classic/videos, they may be some kind of hidden way to allow the device to take more power from USB just like what does the Stock OS |
| 14:11:53 | OlsroFR | Right now, the way to get a good experience with all old iPods is to get a dock that is compatible with the firewire brick/modded USB cable then use it. I feel like the iPod will never discharge here, because it can draw much power. |
| 14:12:02 | OlsroFR | I am waiting to receive a new dock so I will be able to test that |
| 14:14:07 | OlsroFR | (because well, as long as there's backlight enabled/auto enabled on song change for 15s, after a long time playing music, even my 7th gen still discharges (very slowly). For the 4th gens another known solution is to plug it to the PC, because in this context it can charge just fine. |
| 14:18:24 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 14:19:36 | | Join jacobk [0] (~quassel@utdpat241106.utdallas.edu) |
| 14:19:41 | *** | Alert Mode OFF |
| 14:20:50 | OlsroFR | When plugged on my PC, my 4th gen is sometimes 0.45A on Rockbox but quickly decrease to 0.05A. On Stock OS disk mode, I get consistent 0.45A over USB to PC. When the same iPod is plugged into the wall plug, it stays at 0.07A max. This iPod behaves strangely on USB in many conditions, I don't feel like Rockbox can do much about it anyway. |
| 14:22:54 | | Quit dconrad (Ping timeout: 260 seconds) |
| 14:25:52 | Xogium | what about if you have brightness to the minimum and backlight off, does that work around the issue ? |
| 14:26:14 | OlsroFR | if backlight is completely off all the time it seemed to be fine |
| 14:26:37 | OlsroFR | but I like to light it up automatically for 15s before/after the song, with the according option, so I can see what is playing ;) |
| 14:26:57 | OlsroFR | the stock OS can be at 100% brightness 100% of the time and won't discharge that iPod 7th gen over USB |
| 14:27:08 | OlsroFR | I could also replicate this difference/issue with my iPod Video |
| 14:27:09 | Xogium | interesting |
| 14:27:53 | OlsroFR | for the 4th gen I can't blame Rockbox, it probably discharges on Stock OS aswell because of the faulty USB charging hardware implementation |
| 14:28:19 | Xogium | maybe the stock firmware does something fancy |
| 14:28:20 | *** | Saving seen data "./dancer.seen" |
| 14:30:24 | Xogium | no way to see on my side, that said |
| 14:30:59 | Xogium | but I never trust rb charging state at runtime because it keeps saying the battery is at 99% all the time when it's not |
| 14:31:17 | Xogium | so sometimes I've unplugged it from charging and rebooted it, only to discover it was in fact at 60% |
| 14:31:26 | OlsroFR | you will notice it Xogium only if you use a theme that show the battery percentage, otherwise it will be difficult to know |
| 14:31:49 | Xogium | nah in system -> rockbox info, battery is shown there |
| 14:31:49 | OlsroFR | the issue also is pretty vicious, it takes some minutes to trigger even with backlight off |
| 14:31:58 | OlsroFR | backlight on* |
| 14:35:05 | | Quit OlsroFR (Quit: Client closed) |
| 14:57:55 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 15:00 |
| 15:02:29 | | Quit dconrad (Ping timeout: 248 seconds) |
| 15:02:35 | | Join lebellium [0] (~lebellium@2a01cb0405d07f00ddfe7f05ebfe6631.ipv6.abo.wanadoo.fr) |
| 15:19:29 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 15:26:35 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 15:31:26 | | Quit dconrad (Ping timeout: 268 seconds) |
| 15:35:25 | | Quit user890104 (Ping timeout: 260 seconds) |
| 15:37:06 | | Join user890104 [0] (~Venci@freemyipod/user890104) |
| 15:38:33 | | Quit user890104 (Read error: Connection reset by peer) |
| 15:38:39 | | Join user890104_ [0] (~Venci@freemyipod/user890104) |
| 15:58:59 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 16:00 |
| 16:04:59 | | Quit jacobk (Ping timeout: 260 seconds) |
| 16:05:21 | | Quit dconrad (Ping timeout: 248 seconds) |
| 16:28:23 | *** | Saving seen data "./dancer.seen" |
| 16:41:39 | | Quit LjL (Read error: Connection reset by peer) |
| 16:42:10 | | Join LjL [0] (~ljl@user/ljl) |
| 16:43:32 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 16:48:09 | | Quit dconrad (Ping timeout: 260 seconds) |
| 16:53:45 | | Join jacobk [0] (~quassel@2603:8080:b200:7b02::771) |
| 17:00 |
| 17:03:19 | | Quit jacobk (Ping timeout: 260 seconds) |
| 17:10:37 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 17:15:14 | | Quit dconrad (Ping timeout: 248 seconds) |
| 17:42:59 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 17:47:39 | | Quit dconrad (Ping timeout: 260 seconds) |
| 18:00 |
| 18:15:28 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 18:17:33 | | Quit lebellium (Quit: Leaving) |
| 18:19:55 | | Quit dconrad (Ping timeout: 260 seconds) |
| 18:25:00 | | Join PheralSparky [0] (~S|h|a|w|n@user/shawn/x-4432647) |
| 18:28:26 | *** | Saving seen data "./dancer.seen" |
| 18:53:50 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 18:58:08 | | Quit dconrad (Ping timeout: 252 seconds) |
| 19:00 |
| 19:05:37 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 19:22:30 | | Join Crimson_Canadian [0] (~Crimson_C@70.52.176.11) |
| 19:24:54 | Crimson_Canadian | this is a test message, because i udon't know if this will work |
| 19:35:34 | | Quit Crimson_Canadian (Read error: Connection reset by peer) |
| 19:41:09 | | Join Crimson_Canadian [0] (~Crimson_C@bras-base-hmtnon0222w-grc-64-70-52-176-11.dsl.bell.ca) |
| 19:42:21 | | Quit dconrad () |
| 19:42:40 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 20:00 |
| 20:00:13 | | Join massiveH [0] (~massiveH@2600:4040:a982:5400:c839:a414:8b06:fd96) |
| 20:02:19 | | Quit Crimson_Canadian (Read error: Connection reset by peer) |
| 20:10:16 | | Join chris_s [0] (~chris_s@2a02:26f7:ec54:4000:a03:ba87:e9ad:6389) |
| 20:11:47 | | Quit CH23 (Quit: Ping timeout (120 seconds)) |
| 20:12:03 | | Join CH23 [0] (CH23@revspace/participant/ch23) |
| 20:14:46 | chris_s | speachy: it looks like https://git.rockbox.org/cgit/rockbox.git/commit/?id=801260dd79 needs more tweaking, on PP at least (I noticed, in the confirm message when deleting, garbage will be displayed: the char pointer was stored at 0x4000aa48 which is < VIRT_PTR+VIRT_SIZE so appears to be treated as a virtualized ID |
| 20:23:30 | chris_s | think it's just a typo? ( 0x4000000 instead of 0x40000000) |
| 20:24:51 | | Join jacobk [0] (~quassel@2603:8080:b200:7b02::771) |
| 20:28:28 | *** | Saving seen data "./dancer.seen" |
| 20:29:25 | | Quit chris_s (Quit: Client closed) |
| 20:31:18 | | Quit jacobk (Ping timeout: 276 seconds) |
| 20:31:33 | | Join chris_s [0] (~chris_s@2a09:bac2:291b:2478::3a2:f) |
| 20:37:41 | | Quit braewoods (Remote host closed the connection) |
| 20:37:56 | | Join braewoods [0] (~braewoods@user/braewoods) |
| 20:40:46 | | Quit chris_s (Quit: Client closed) |
| 20:58:59 | | Join jacobk [0] (~quassel@47-186-65-73.dlls.tx.frontiernet.net) |
| 21:00 |
| 21:01:54 | | Quit Ckat (Quit: this shouldn't be happening) |
| 21:02:18 | | Join Ckat [0] (~Ckat@xn--z7x.xn--6frz82g) |
| 21:21:37 | | Quit othello7 (Quit: othello7) |
| 21:33:18 | _bilgus_ | edhelas_, you should be able to just cop the plugin over but I sent thewhole build just in case https://www.mediafire.com/file/gcuw8expmwf6sac/ipod6g_scrobblertest_rockbox.zip/file |
| 21:34:27 | _bilgus_ | all I can this is we are running foul of something with fdprints buffer so I used a separate buffer to build everything after the path |
| 21:35:35 | _bilgus_ | If this still doesn't work I think its probably a bug in (sn,fd)printf |
| 21:36:24 | _bilgus_ | sorry 'all I can think is'* |
| 22:00 |
| 22:09:33 | aaabbb | speachy: do you think there would be much benefit for having the stack for the decoder kept in iram? |
| 22:10:33 | | Quit hactar|ant (Ping timeout: 252 seconds) |
| 22:13:40 | | Join hactar|ant [0] (~zem@97.115.152.249) |
| 22:13:51 | aaabbb | this can be done with makecontext() and swapcontext() although those are deprecated in posix.1-2008 but it is low-overhead |
| 22:15:01 | _bilgus_ | aaabbb codec_test_plugin |
| 22:16:36 | aaabbb | _bilgus_: i do not understand |
| 22:16:41 | _bilgus_ | run it first a few times on some varied samples we have them already https://www.rockbox.org/wiki/CodecPerformanceComparison.html, https://download.rockbox.org/test_files/ |
| 22:17:15 | _bilgus_ | get a baseline for what it already does and then try your ideas |
| 22:17:50 | aaabbb | ok. i just didn't want to duplicate effort if it was already tried or if there was a reason, it might not work well |
| 22:18:19 | _bilgus_ | all those codec comparisons were run witht the codec test plugin |
| 22:18:48 | aaabbb | i see. so that is just how i benchmark it? |
| 22:18:51 | _bilgus_ | its the only way to say definitively |
| 22:18:56 | _bilgus_ | yep |
| 22:19:17 | _bilgus_ | jump in rool up your sleeves and try some stuff |
| 22:19:24 | _bilgus_ | roll even lol |
| 22:19:26 | | Quit Moriar (Ping timeout: 252 seconds) |
| 22:21:05 | _bilgus_ | what I like to try with that is get like 4 versions going and just rename them and run another test |
| 22:22:03 | aaabbb | i need to familiarize myself more with rockbox architecture of course |
| 22:22:16 | _bilgus_ | the codecs are sorta their own |
| 22:22:26 | _bilgus_ | they are plugins |
| 22:22:31 | _bilgus_ | essentially |
| 22:22:53 | aaabbb | i mean like, how much the os already uses in iram |
| 22:24:28 | _bilgus_ | thats going to depend on the target but you can search for IRAM to get a rough idea in firmware/target/CPUTYPE/... |
| 22:28:29 | *** | Saving seen data "./dancer.seen" |
| 22:33:33 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 22:33:50 | aaabbb | 48kb total. speachy's optimization uses about 26kb, leaving 22kb left |
| 22:34:03 | aaabbb | for the pp target |
| 22:34:31 | aaabbb | then subtract whatever the os uses and that's how much extra iram there is to use i suppose |
| 22:37:52 | | Quit othello7 (Remote host closed the connection) |
| 22:38:17 | | Join othello7 [0] (~Thunderbi@100.36.176.164) |
| 22:39:33 | | Quit dconrad () |
| 23:00 |
| 23:27:30 | | Quit massiveH (Quit: Leaving) |
| 23:55:06 | _bilgus_ | somewhere thereabouts yes excepting alignment requirements |
icon identifies that the person is a core developer (has commit access).