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

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

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

#rockbox log for 2024-05-14

00:01:42_bilgus_sure looks like flac is a better choice
00:02:07aaabbbwell flac is lossless :p
00:02:29aaabbbmy thoughts are between opus, vorbis, and mpc
00:05:00_bilgus_and mpc appears to be the lowest processor speed for realtime
00:06:08_bilgus_really though you'll have to try on your device I did some stuff to speed up opus decoding it was something like .5 of a second decrease but thats not going to skew those results much
00:08:17_bilgus_figure also upstream has already assed their own arm ASM code for the spots they deemed necessary so I doubt much if left lying around besides tricks to get your buffers aligned optimally etc
00:08:34_bilgus_sory added*
00:08:40aaabbbbut at least it uses the tcm?
00:13:13_bilgus_uh you'd have to look I think the codecs do get access to fastmem we'd call it ...
00:14:13_bilgus_IRAM I think
00:29:46aaabbbon arm it's tcm (tightly coupled memory)
00:31:43aaabbbi know vorbis uses it i think for its codebooks or something, idk about opus
00:44:55***Saving seen data "./dancer.seen"
01:00
01:02:43 Quit jacobk (Ping timeout: 268 seconds)
01:03:20 Join jacobk [0] (~quassel@47-186-70-49.dlls.tx.frontiernet.net)
01:13:25 Quit pixelma (Quit: .)
01:13:25 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
01:14:26 Join amiconn [0] (jens@p200300ea87348b00305e95fffec66ff3.dip0.t-ipconnect.de)
01:14:27 Join pixelma [0] (marianne@p200300ea87348b00305e95fffec66ff3.dip0.t-ipconnect.de)
01:25:19 Quit othello7 (Quit: othello7)
02:00
02:44:59***Saving seen data "./dancer.seen"
03:00
03:10:48 Quit CH23[m] (Read error: Connection reset by peer)
03:11:03 Join CH23[m] [0] (~CH23@revspace/participant/ch23)
04:00
04:18:27 Quit jacobk (Ping timeout: 260 seconds)
04:45:01***Saving seen data "./dancer.seen"
06:00
06:07:11 Quit b0 (Ping timeout: 260 seconds)
06:07:22 Join b0 [0] (~b0@user/b0)
06:45:04***Saving seen data "./dancer.seen"
07:00
07:31:17 Quit PheralSparky (Read error: Connection reset by peer)
07:31:50 Join PheralSparky [0] (~Shawn@user/shawn/x-4432647)
07:36:09 Quit Maxdamantus (Ping timeout: 268 seconds)
07:36:37 Join Maxdamantus [0] (~Maxdamant@user/maxdamantus)
07:58:35 Quit Galois (Ping timeout: 272 seconds)
08:00
08:00:16 Quit PheralSparky (Quit: Leaving)
08:03:33speachyaaabbb: I guess in the end, what target, and what you are trying to accomplish matters.
08:04:17speachyopus is more than optimiazed enoughj for realtime on all of our supported targets. flac works too of course but the files are far larger and storage will spend more time powered up as a result.
08:05:23speachyif you are trying to maximize battery life, the mp3 is probably best but keep in ind that the actual CPU is only a small-ish part of the power consumption of a system actively playing back audio.
08:14:24speachyif you want to apply dsp effects on top, that's going to hurt vs not, no matter which codec you're using.
08:14:52speachyditto resampling. 5ch 24bit 192KHz FLACs are going to have issues on an ipod, for example.
08:45:07***Saving seen data "./dancer.seen"
09:00
09:03:54 Quit gevaerts (Ping timeout: 255 seconds)
09:20:25 Join f_ [0] (~AUGESOUND@user/f-:38077)
09:45:04 Join Galois [0] (djao@efnet.math.uwaterloo.ca)
09:45:05 Quit Galois (Remote host closed the connection)
09:45:40 Join Galois [0] (djao@efnet.math.uwaterloo.ca)
10:00
10:02:44 Quit CH23 (Ping timeout: 256 seconds)
10:03:15 Join gevaerts [0] (~fg@user/gevaerts)
10:06:13 Quit Galois (Ping timeout: 256 seconds)
10:15:01 Quit CH23[m] (Ping timeout: 255 seconds)
10:15:13 Join CH23[m] [0] (~CH23@revspace/participant/ch23)
10:22:46 Join Galois [0] (djao@efnet.math.uwaterloo.ca)
10:25:00 Quit speachy (Quit: WeeChat 4.2.2)
10:30:13 Join speachy [0] (~speachy@rockbox/developer/speachy)
10:30:13Mode"#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat)
10:32:31 Quit Galois (Ping timeout: 268 seconds)
10:45:10***Saving seen data "./dancer.seen"
10:52:56speachyaaabbb: another thing to keep in mind that optimized asm for armv4t might be _slower_ on an armv5/v6 processor than the native output of gcc.
10:57:38speachyno IRAM use in opus from what I can tell. Looks like it got lost in the 2019 rebase.
10:59:24_bilgus_might explain the slightly lower performance
10:59:34_bilgus_pre to current
10:59:59speachyyeah some dynamically-allocated tables were static and put in IRAM
11:00
11:02:22speachythey were that way in the original commit though.
11:03:02speachyso I suspect it was an upstream change.
11:03:58speachyanyway. these days "arm optimizations" usually involve the SIMD engines on >=v7 cores.
11:04:45_bilgus_I sped up decoding by .5s with a patch so that means there could potentially be a bit left if one were motivated to look
11:05:07 Join jacobk [0] (~quassel@2600:100c:b2a7:99fd:15d3:6a3a:f9e5:764b)
11:05:28speachy0.5s out of how long?
11:05:29 Join Galois [0] (djao@efnet.math.uwaterloo.ca)
11:06:07_bilgus_it would have been on the test files
11:06:36speachy0.5s out of 5s is signifcant, less so if it's out of 120s. :)
11:07:11 Quit jacobk (Read error: Connection reset by peer)
11:07:20speachyI have a partial speex update in one of my trees too.
11:07:51_bilgus_the terrible test track is almost 3 minutes infact
11:08:29_bilgus_like I said it wouldnt have moved it in those codec comparisons
11:11:39_bilgus_so really if aaabbb is really concerned about the performance going back to prior to sync would get some performance at the cost of buggier playback, higher stack usage, and prossibly lower quality reproduction
11:11:55 Join jacobk [0] (~quassel@2600:100c:b2a7:99fd:15d3:6a3a:f9e5:764b)
11:13:56speachyand the power consumption of shuffling the data out the DACs plus the analog circuits will dwarf the codec overhead anyway. even on the ipod.
11:14:21speachy(where we're what, 5x realtime on a single core?)
12:00
12:02:36 Quit CH23[m] (Read error: Connection reset by peer)
12:02:55 Join CH23[m] [0] (~CH23@revspace/participant/ch23)
12:21:40 Quit CH23[m] (Ping timeout: 260 seconds)
12:22:13 Join CH23[m] [0] (~CH23@revspace/participant/ch23)
12:45:11 Join CH23 [0] (~CH23@revspace/participant/ch23)
12:45:12***Saving seen data "./dancer.seen"
12:57:46 Quit CH23 (Remote host closed the connection)
12:59:54 Join CH23 [0] (~CH23@revspace/participant/ch23)
13:00
13:10:40 Quit CH23[m] (Read error: Connection reset by peer)
13:11:00 Join CH23[m] [0] (~CH23@revspace/participant/ch23)
13:34:24 Quit jacobk (Read error: Connection reset by peer)
13:41:37 Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net)
14:00
14:03:34 Quit f_ (Quit: To contact me, send a memo using MemoServ, PM f_[xmpp], or send an email. See https://vitali64.duckdns.org/.)
14:20:30 Join jacobk [0] (~quassel@2600:100c:b2a7:99fd:15d3:6a3a:f9e5:764b)
14:45:15***Saving seen data "./dancer.seen"
15:00
15:00:45 Quit othello7 (Ping timeout: 256 seconds)
15:29:40 Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net)
16:00
16:08:29 Join PheralSparky [0] (~Shawn@user/shawn/x-4432647)
16:45:18***Saving seen data "./dancer.seen"
16:48:48 Quit jacobk (Read error: Connection reset by peer)
16:53:36 Join jacobk [0] (~quassel@47-186-70-49.dlls.tx.frontiernet.net)
17:00
17:30:44 Join othello8 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net)
18:00
18:45:22***Saving seen data "./dancer.seen"
18:51:48 Quit othello8 (Ping timeout: 260 seconds)
19:00
19:03:22 Join advcomp2019__ [0] (~advcomp20@user/advcomp2019)
19:07:11 Quit advcomp2019_ (Ping timeout: 264 seconds)
19:34:21 Join massiveH [0] (~massiveH@2600:4040:a982:c800:9a:a851:feda:38ff)
20:00
20:14:20aaabbbis iram the same as tcm?
20:16:48aaabbbhow big is the tcm in classic ipods and other old arm systems of that era?
20:23:17 Quit CH23[m] (Ping timeout: 240 seconds)
20:25:21 Quit CH23 (Ping timeout: 252 seconds)
20:30:31 Join CH23 [0] (~CH23@revspace/participant/ch23)
20:41:05 Join CH23[m] [0] (~CH23@revspace/participant/ch23)
20:45:24***Saving seen data "./dancer.seen"
20:47:41 Quit CH23[m] (Ping timeout: 256 seconds)
20:48:36 Quit CH23 (Ping timeout: 255 seconds)
20:55:17 Join CH23[m] [0] (~CH23@revspace/participant/ch23)
21:00
21:00:14 Join CH23 [0] (~CH23@revspace/participant/ch23)
21:08:52speachyaaabbb: the 1g-3g have 96GB of IRAM, the 4g/5g have 128KB. 48KB is used for the main system; the rest is reserved for the codecs.
21:11:25aaabbb96gb? :D
21:11:35speachy96K, sorry.
21:11:57speachyIRAM is not necessarily TCM.
21:12:16aaabbbdoes it have the same performance as tcm (same number of cycles as an l1 cache hit)?
21:15:16speachyin this context, "TCM" is on-chip SRAM, and "IRAM" is TCM that the processor can execute code from.
21:15:30speachyit is much faster than the off-chip DRAM.
21:16:19speachyother chips might have, say, 1MB of on-chip SRAM but 64KB of even lower-latency TCM.
21:17:03aaabbbok i mean true tcm (itcm and dtcm only). so i guess the on-chip sram is faster, but not as fast as true tcm
21:19:10speachybottom line is that the IRAM is the fastest RAM in the system for the PP devices. Whether or not it's strictly "TCM" is moot.
21:23:06aaabbbif opus doesn't use the tcm at all then that might be some easy performance gains there
21:23:18aaabbbi'll look into if there is an easy win i can write a patch
21:25:46speachyif you look at the git commit history and the big reabase in 2019, search for IRAM and you'll see what was dropped.
21:26:18aaabbbany reason why it was dropped?
21:26:21aaabbbor just lost?
21:28:30speachythis is just conjecture on my part but upstream changed the code structure a decent amount, includingthe lifecycle of the formerly-in-iram structures.
21:29:04speachyIIRC the performance hit was like a couple of percent.
21:29:13aaabbbupstream? i didn't know rockbox had an upstream
21:29:21speachyupstream libpous
21:29:41aaabbboh
21:30:19speachybut the improvements/fixes/etc were far more important than chasing down a couple of percent hit, as even our slowest target could easily manage realtime decoding.
21:33:14aaabbbdo most of the targets use the fixed point build?
21:33:19speachythey all do.
21:33:50speachyonly a handful of our targets even have an FPU at all.
21:35:55speachyand we have no OS-level support for that. IIRC there's one niche videogame codec that requires an FPU so is only built on a handful of hosted targets.
21:36:40speachyI started working on adding FPU support to the native mips port but decided it wasn't worth the overhead.
21:37:00aaabbbas in emulated floating point?
21:37:23aaabbbmight be nsf that requires fpu
21:37:24speachyno, the processor has a proper IEEE754-compliant FPU.
21:41:45speachythe ayumi emulator.'=
21:43:16 Quit speachy (Quit: WeeChat 4.2.2)
21:45:52 Join speachy [0] (~speachy@rockbox/developer/speachy)
21:45:52Mode"#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat)
22:00
22:03:10 Quit bbbccc (Quit: ZNC 1.9.0 - https://znc.in)
22:08:35 Join bbbccc [0] (~aaabbb@user/aaabbb)
22:10:54 Quit bbbccc (Client Quit)
22:30:40 Quit speachy (Quit: WeeChat 4.2.2)
22:40:28 Quit massiveH (Quit: Leaving)
22:45:25***Saving seen data "./dancer.seen"
23:00
23:18:58 Join belak51 [0] (~belak@user/belak)
23:20:43 Quit belak (Ping timeout: 272 seconds)
23:21:05 Nick belak51 is now known as belak (~belak@user/belak)
23:46:26 Quit CH23 (Quit: Leaving)

Previous day | Next day