00:01:44 | | Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]) |
00:02:29 | | Quit robertd1 (Ping timeout: 260 seconds) |
00:04:37 | | Quit girafe (Read error: Connection reset by peer) |
00:05:17 | [Saint] | Well, if you're still talking about the SIM, presumably it's not ARM. |
00:10:34 | | Quit petur (Quit: Leaving) |
00:11:09 | | Join robertd1 [0] (~root@186-90-44-72.genericrev.cantv.net) |
00:13:59 | __builtin | it only stops playback on target |
00:15:32 | pamaury | __builtin: which targets is that ? Maybe the plugin is too big and needs more memory ? (just a tought, I really don't know how it works) |
00:15:50 | __builtin | ipod6g |
00:15:58 | __builtin | probably not though, I don't think that's how it works |
00:16:54 | [Saint] | I don't think that audiobuf can be dynamically resized during playback. |
00:17:12 | | Join Bray90820_ [0] (~bray90820@173-25-204-30.client.mchsi.com) |
00:17:13 | [Saint] | so if a plugin needs even a few bytes more than pluginbuf it'll stop playback I believe. |
00:17:38 | [Saint] | it'll only shrink the buffers back after the fact I think. |
00:18:06 | [Saint] | buflib is kinda half useful. |
00:18:39 | [Saint] | it's kinda removed from an actual dynamic buffering system, it's more retroactive than proactive by my understanding. |
00:18:53 | pamaury | I would think that the audiobuf contains several allocations and only the currently-being-played-chunk and the currently-being-decoded-chunk are locked ? |
00:19:10 | | Quit Bray90820 (Ping timeout: 248 seconds) |
00:19:14 | pamaury | but you're right that if they are in the middle of the memory, not much can be done |
00:19:22 | pamaury | since you can't move them without an MMU |
00:21:09 | | Quit robertd1 (Ping timeout: 260 seconds) |
00:24:25 | | Join robertd1 [0] (~root@186-90-44-72.genericrev.cantv.net) |
00:25:14 | __builtin | the only reason I'm concerned about this is that it might be related to a crash after audio is started from inside the plugin |
00:28:48 | | Quit robertd1 (Ping timeout: 258 seconds) |
00:32:08 | | Join robertd1 [0] (~root@186-90-44-72.genericrev.cantv.net) |
00:36:51 | | Quit ender` (Quit: #include <unistd.h> | #define Bork for | #define bork fork() | int main() { Bork(bork ;; bork) bork; }) |
00:37:44 | [Saint] | ah, right. |
00:39:18 | | Quit robertd1 (Ping timeout: 255 seconds) |
00:39:40 | __builtin | otherwise I have to rason to touch audio ;) |
00:40:00 | *** | Saving seen data "./dancer.seen" |
00:40:20 | __builtin | *no reason |
00:40:59 | | Join robertd1 [0] (~root@186-90-44-72.genericrev.cantv.net) |
00:42:41 | __builtin | AHA! |
00:42:48 | __builtin | it's an IRAM issue, I think |
00:43:31 | __builtin | though that doesn't explain audio stopping, or does it? o.O |
00:45:34 | __builtin | yes, that fixed it! |
00:45:44 | __builtin | something something audio IRAM |
00:45:54 | pamaury | __builtin: what fixed what ? |
00:46:08 | __builtin | removing ICODE_ATTR from a function |
00:46:13 | __builtin | gotta run now, sorry |
00:46:23 | pamaury | just curious, if you can describe it so hopefully someone knowledgeable can fix it ;) |
00:48:12 | [Saint] | ipod6g has some peculiarities with IRAM, but I can't see how this would affect it. |
00:48:51 | [Saint] | IIUC, it's basically got a 'fast' half, and a 'slow' half of IRAM, and no real way to designate to either reliably. |
00:49:16 | [Saint] | IMO there's no real reason to use IRAm at all on the ipod6g. |
00:49:34 | | Quit robertd1 (Ping timeout: 248 seconds) |
00:49:39 | [Saint] | It's not like the conventional RAM is slow. |
00:50:10 | | Join robertd1 [0] (~root@186-90-44-72.genericrev.cantv.net) |
00:52:08 | [Saint] | And I sincerely doubt that there would be any noticeable difference in runtime or performance without it. |
00:53:01 | [Saint] | Or even any difference at all, noticeable or otherwise. |
01:00 |
01:00:46 | | Quit robertd1 (Ping timeout: 248 seconds) |
01:01:49 | | Join robertd1 [0] (~root@186-90-44-72.genericrev.cantv.net) |
01:03:33 | | Quit pamaury (Ping timeout: 240 seconds) |
01:10:33 | prof_wolfff | __builtin: sorry cannot find it in the logs, i have many unread logs an probably missed something, what is the bug and the functions you are refering?, as Saint said IRAM should not affect, sometimes moving functions could masquerade some alignment of buffer overflow issues |
01:11:01 | prof_wolfff | alignment or* |
01:12:43 | [Saint] | [20170113111230] <__builtin> alright, looks like something is putting Q_AUDIO_STOP in the playback queue |
01:12:43 | [Saint] | [20170113111432] <__builtin> good thing is there's only 3 places in the code that do that |
01:12:43 | [Saint] | [20170113121401] <__builtin> it only stops playback on target |
01:12:43 | DBUG | Enqueued KICK [Saint] |
01:12:43 | [Saint] | [20170113124243] <__builtin> AHA! |
01:12:43 | [Saint] | [20170113124250] <__builtin> it's an IRAM issue, I think |
01:12:52 | [Saint] | [20170113124333] <__builtin> though that doesn't explain audio stopping, or does it? o.O |
01:12:53 | [Saint] | [20170113124536] <__builtin> yes, that fixed it! |
01:13:11 | [Saint] | that's really all there was too it - I guess you'll need to poke him to be more explicit. |
01:15:23 | prof_wolfff | [Saint]: thanks, __builtin: it would be useful to know how to reproduce it and the IRAM function involved |
01:20:42 | | Join smoke_fumus [0] (~smoke_fum@dynamic-vpdn-93-125-15-142.telecom.by) |
01:21:28 | | Quit robertd1 (Ping timeout: 256 seconds) |
01:34:33 | | Quit ZincAlloy (Quit: Leaving.) |
01:36:45 | prof_wolfff | [Saint]: about IRAM, OF uses IRAM as a ping-pong buffer for audio playback, can't remember the address and size of the buffers but i will bet that for powersaving it uses the first 128KB (slow block) while the DRAM is hibernated |
01:37:17 | | Quit scorche (Read error: Connection reset by peer) |
02:00 |
02:01:36 | __builtin | prof_wolfff: sorry I couldn't elaborate a bit more |
02:02:01 | __builtin | so the gist of it is this: I was investigating why two things were happening to my plugin(s) |
02:02:49 | __builtin | 1) audio stopped upon entering plugin without any reason |
02:03:29 | __builtin | 2) it crashed when entering a game while audio was being played |
02:03:53 | __builtin | so it turned out that it was crashing in a function with the ICODE_ATTR flag |
02:04:57 | __builtin | prof_wolfff: said function is available at: http://pastebin.com/73gsdj5g |
02:05:49 | __builtin | and that these two issues were related by that one function, as removing the ICODE_ATTR fixes both of them |
02:06:40 | prof_wolfff | i don't know too much about the plugin API, but IIRC some plugins stops playback and other does not, i.e FFT continues playback while running, IIRC some test plugin stops playback to use the audio buffer and there is a crash on exit because the audiobuf is not restored |
02:07:36 | prof_wolfff | have you tested if FFT has the same issue?, if FFT works then you can try to do in the same way and see what happens |
02:09:06 | __builtin | prof_wolfff: fft works normally, no crash |
02:09:11 | __builtin | and audio continues to play |
02:09:55 | __builtin | I know what causes issue 1), I think |
02:11:17 | prof_wolfff | the ICODE_ATTR functions belongs to your plugin? |
02:12:15 | __builtin | yes |
02:13:29 | prof_wolfff | probably it is not the case but i am wondering what happens if there is not enough free IRAM, could this happen? |
02:13:48 | __builtin | hmm, I don't think so, the linker should detect it |
02:14:38 | __builtin | I suspect that there may be a conflict between the ICODE_ATTR function and audio playback |
02:15:24 | | Join scorche [0] (~scorche@rockbox/administrator/scorche) |
02:15:35 | prof_wolfff | i don't know exactly how the plugins are loaded, IIRC some things could be configured as IRAM at compile time, but maybe someone could tell us how the plugins are loaded dinamically |
02:17:00 | __builtin | prof_wolfff: https://www.rockbox.org/wiki/PluginMemoryLayout should help |
02:17:44 | __builtin | the part on PLUGIN_IRAM_INIT is wrong, however |
02:18:39 | chrisjj | pamaury, to answer your 'does your mysterious ZEN with funny lcd works with the 03e version', yes it (Unit N) does. |
02:21:10 | chrisjj | (with no dots or any other obvious fault.) |
02:21:24 | chrisjj | I presume that's not the answer for which you were hoping. :) |
02:24:18 | chrisjj | (FTR for anyone following this in future, the 03e firmware updater shows the wrong version number http://i.imgur.com/ugX6R1t.png . And complains that an 80% charge is in sufficient, Goodness knows why.) |
02:25:13 | | Join xasthur [0] (18854eee@gateway/web/freenode/ip.24.133.78.238) |
02:26:09 | | Quit Senji (Ping timeout: 240 seconds) |
02:28:50 | | Quit skapazzo (Quit: leaving) |
02:34:37 | prof_wolfff | __builtin: i was looking to the .lds files and it seems everything is ok, there are 200KB of IRAM for codecs/plugins, but need to look at it on detail, anyway there is no benefict on using IRAM on ipod6g, the first 72Kb of the 200Kb region are slow memory |
02:35:28 | __builtin | I guess the safe move is "don't do it" for now |
02:37:24 | prof_wolfff | yes, for powersaving (and speed on read/store for actual IRAM data/code) i was planing to disable the IRAM on future |
02:40:03 | *** | Saving seen data "./dancer.seen" |
02:42:23 | xasthur | I need an advise guys. I have Sennheiser HD 202 headphones and Sony Nwz-A15 music player. Is it worth it to keep music files as .flac? Can anyone understand the difference between .flac and .mp3 with this devices? |
02:43:15 | __builtin | the advantage of FLAC over MP3 is that it's lossless, which means that no information is lost during compression |
02:44:04 | __builtin | however, keep in mind MP3 at high bitrates is essentially indistinguishable from any lossless format |
02:44:51 | xasthur | Thank you :) |
03:00 |
03:01:32 | | Quit xasthur (Quit: Page closed) |
03:13:00 | [Saint] | prof_wolfff: am I correct in my assumption that in terms of Rockbox, using (or not using) IRAM won't really make a shit of difference to either performance or runtime? |
03:13:47 | [Saint] | Oh, I see you've answered this above. My bad. Sorry for missing that. |
03:14:17 | [Saint] | Yes. I got the impression walking through the code a while back that the only thing using IRAM on this target actually does is convolute things. |
03:15:24 | [Saint] | __builtin: the plugin memory layout thing has probably been wrong ever since the buffering system was absolutely gutted and replaced with buflib. |
03:17:52 | [Saint] | chrisjj: it is very standard practice for many modern devices to refuse to do a firmware update unless it is 100% and externally powered. |
03:18:16 | [Saint] | The "goodness knows why" thing is that for some targets failing within this process would be irrecoverable. |
03:18:28 | [Saint] | It's basically just good industry practice. |
03:40:03 | prof_wolfff | [Saint]: yes, in addition disabling IRAM decreases power in about 1-2% (IIRC, maybe more), another way i found to 'easily' decrease power is to increase the DRAM refresh time, i got it up to unbelievable values, but there is no need to increase it too much to notice the powersaving |
03:50:25 | | Join ungali [0] (ungali@162-202-67-158.lightspeed.livnmi.sbcglobal.net) |
03:50:25 | | Quit ungali (Changing host) |
03:50:25 | | Join ungali [0] (ungali@unaffiliated/ungali) |
03:54:01 | | Join saratoga [0] (123e11e0@gateway/web/freenode/ip.18.62.17.224) |
03:54:33 | saratoga | prof_wolfff: 128KB of IRAM is what many PP devices had, so if the IRAM is any faster at all than DRAM the codecs could use it to improve speed |
03:54:49 | saratoga | they are already able to allocate either 96 or 128kb of IRAM via compile time switch |
04:00 |
04:00:51 | prof_wolfff | saratoga: on ipod6g first half (128Kb) of IRAM is at least 1/2 slower (actually 1/3 or 1/4 IIRC) than the second half, the IRAM second half is about as fast as DRAM: slightly faster on read and slightly slower on writes (or vice-versa, cannot recall), anyway it is not much noticed when cache is used (fortunately ipod6g cache size is 16KB), but very noticeable on non-cached or DMA transfers |
04:01:31 | saratoga | prof_wolfff: did you ever try it with codecs? |
04:03:16 | prof_wolfff | no, not tried to load codecs on DRAM instead of IRAM, i am supposing actually they are using 72Kb of slow IRAM |
04:03:52 | saratoga | performance for various codecs can be pretty sensitive to memory, its probably worth trying mp3/vorbis in the fast half and see what happens |
04:04:59 | prof_wolfff | it seem easy to do, will try it |
04:05:28 | | Quit ungali (Quit: ungali) |
04:05:50 | saratoga | i made standard test files for benchmarking if you need them: http://download.rockbox.org/test_files/ |
04:07:14 | saratoga | usually though vorbis and mp3 are good tests of memory performance |
04:08:52 | | Join ungali [0] (ungali@unaffiliated/ungali) |
04:09:13 | prof_wolfff | i performed some test a few months so the files are already on my device, i think it will be noticed, but not much at all because of the big cache size, but it also depends on the kind of code and data, maybe some codecs will be affected more than others |
04:10:25 | prof_wolfff | i will try to do the tests using codecs on IRAM an DRAM if possible |
04:10:50 | prof_wolfff | second IRAM half and* |
04:20:31 | Bilgus | Anyone want to give me some feedback on this time picker? http://imgur.com/a/6EYnW |
04:36:50 | | Join seanussija [0] (~Services@m83-178-180-237.cust.tele2.ee) |
04:36:56 | | Part seanussija |
04:40:05 | *** | Saving seen data "./dancer.seen" |
04:40:45 | Bilgus | [Saint]? |
04:46:46 | | Join IdentService [0] (~Services@m83-178-180-237.cust.tele2.ee) |
04:46:53 | | Part IdentService |
05:00 |
05:08:52 | [Saint] | Looks OK I guess. Not sure we need picosecond resolution though. ;) |
05:09:37 | [Saint] | No devices we support could even clock to that. What happened there, lol? |
05:11:08 | Bilgus | Oh i show it but it only goes down to 1000/HZ resolution |
05:11:34 | Bilgus | 10ms |
05:21:12 | Bilgus | I kinda figured i'd leave it since it makes it easier to distinguish which is the MS field at a glance |
05:23:25 | Bilgus | I guess I could make it a 'dot' |
05:25:12 | fs-bluebot | Build Server message: New build round started. Revision 954d934, 255 builds, 16 clients. |
05:36:58 | fs-bluebot | Build Server message: Build round completed after 706 seconds. |
05:37:00 | fs-bluebot | Build Server message: Revision 954d934 result: All green |
05:44:52 | | Quit ungali (Ping timeout: 240 seconds) |
06:00 |
06:26:53 | | Quit TheSeven (Ping timeout: 240 seconds) |
06:27:32 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
06:40:08 | *** | Saving seen data "./dancer.seen" |
06:44:14 | | Join Senji [0] (~Senji@85.187.103.250) |
08:00 |
08:07:54 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
08:07:54 | | Quit pixelma (Quit: .) |
08:08:05 | | Join pixelma [0] (~pixelma@rockbox/staff/pixelma) |
08:08:06 | | Join amiconn [0] (~amiconn@rockbox/developer/amiconn) |
08:12:06 | | Join parchd [0] (~parchd@unaffiliated/parchd) |
08:34:44 | | Join ender` [0] (krneki@foo.eternallybored.org) |
08:40:11 | *** | Saving seen data "./dancer.seen" |
08:46:57 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
09:00 |
09:22:02 | | Quit derf (Ping timeout: 248 seconds) |
09:22:06 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
09:22:07 | | Quit wodz (Client Quit) |
09:22:24 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
09:23:42 | | Join derf [0] (~derf@static-108-18-126-14.washdc.fios.verizon.net) |
09:46:59 | | Join elensil [0] (~edhelas@2001:1c02:1903:d800:809e:c47a:12e2:77b8) |
09:54:08 | | Quit dongs (Ping timeout: 255 seconds) |
09:55:09 | | Join dongs [0] (~dongs@bcas.tv) |
09:59:16 | | Join ungali [0] (ungali@unaffiliated/ungali) |
10:00 |
10:06:37 | | Join paulk-collins [0] (~paulk@147.210.245.180) |
10:19:31 | | Quit krnlyng (Ping timeout: 240 seconds) |
10:32:55 | | Join krnlyng [0] (~liar@178.114.161.35.wireless.dyn.drei.com) |
10:39:29 | | Join skapazzo [0] (~skapazzo@151.9.205.1) |
10:40:13 | *** | Saving seen data "./dancer.seen" |
10:43:52 | | Join xorly [0] (~xorly@193.85.203.185) |
10:53:01 | | Quit ungali (Quit: ungali) |
10:59:29 | | Quit xorly (Quit: WeeChat 1.7-dev) |
11:00 |
11:00:05 | | Join xorly [0] (~xorly@193.85.203.185) |
11:00:27 | | Quit xorly (Client Quit) |
11:01:04 | | Join xorly [0] (~xorly@193.85.203.185) |
11:14:17 | | Join robertd1 [0] (~root@186-90-12-124.genericrev.cantv.net) |
11:19:19 | | Quit xorly (Ping timeout: 252 seconds) |
11:41:44 | | Quit paulk-collins (Remote host closed the connection) |
11:48:43 | | Join xorly [0] (~xorly@193.85.203.185) |
11:51:24 | | Join pamaury [0] (~quassel@wks-50-63.mpi-sws.org) |
11:51:24 | | Quit pamaury (Changing host) |
11:51:24 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
11:53:25 | | Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) |
11:55:26 | pamaury | __builtin: are you doing a DEBUG build by any chance ? |
12:00 |
12:16:22 | chrisjj | pamaury, did you see my https://www.rockbox.org/irc/log-20170113#02:18:39 ? |
12:19:20 | | Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:7465:b03d:7f25:7749) |
12:31:04 | | Quit xorly (Ping timeout: 240 seconds) |
12:31:10 | wodz | [Saint]: ping |
12:40:15 | *** | Saving seen data "./dancer.seen" |
12:53:10 | | Quit StaticAmbience (Quit: No Ping reply in 180 seconds.) |
12:53:59 | | Join StaticAmbience [0] (~Quassel@host86-148-184-110.range86-148.btcentralplus.com) |
12:55:53 | | Quit einhirn (Read error: Connection reset by peer) |
13:00 |
13:05:41 | | Join petur [0] (~petur@dD5E0153A.access.telenet.be) |
13:05:41 | | Quit petur (Changing host) |
13:05:41 | | Join petur [0] (~petur@rockbox/developer/petur) |
13:20:29 | pamaury | chrisjj: yes I saw |
13:21:22 | pamaury | I need to double check the lcd init sequence see if there is any difference, otherwise I don't know what is wrong |
13:24:26 | chrisjj | OK, thanks. |
13:41:00 | | Join xorly [0] (~xorly@193.85.203.185) |
13:41:58 | | Join petur2 [0] (~petur@dD5E0153A.access.telenet.be) |
13:42:57 | | Quit petur (Disconnected by services) |
13:43:01 | | Nick petur2 is now known as petur (~petur@dD5E0153A.access.telenet.be) |
13:43:17 | | Quit petur (Changing host) |
13:43:17 | | Join petur [0] (~petur@rockbox/developer/petur) |
13:51:01 | | Quit xorly (Ping timeout: 245 seconds) |
13:51:31 | | Join xorly [0] (~xorly@193.85.203.185) |
14:00 |
14:39:08 | | Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) |
14:40:17 | *** | Saving seen data "./dancer.seen" |
14:41:29 | | Quit xorly (Ping timeout: 240 seconds) |
14:59:51 | | Join xorly [0] (~xorly@193.85.203.185) |
15:00 |
15:34:03 | | Quit wodz (Ping timeout: 260 seconds) |
15:46:14 | | Quit petur (Quit: Connection reset by beer) |
15:51:35 | | Quit robertd1 (Read error: No route to host) |
15:53:22 | | Join robertd1 [0] (~root@186-90-12-124.genericrev.cantv.net) |
16:00 |
16:22:01 | | Quit alexweissman (Remote host closed the connection) |
16:22:53 | | Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) |
16:27:34 | | Quit xorly (Ping timeout: 240 seconds) |
16:34:48 | | Quit alexweissman (Remote host closed the connection) |
16:40:18 | *** | Saving seen data "./dancer.seen" |
17:00 |
17:37:44 | chrisjj | On this Unit N boot to RB, subsequent to me reporting data aborts http://pastebin.com/8QByrMDh were 100%, further tests have caught a that launch fine. I'll reinstall and test again. |
17:56:09 | | Quit pamaury (Remote host closed the connection) |
18:00 |
18:00:00 | | Quit pamaury_ (Ping timeout: 240 seconds) |
18:04:31 | | Join alexweissman [0] (~alexweiss@2001:18e8:2:28b6:a425:1700:5242:d47a) |
18:09:07 | | Quit alexweissman (Ping timeout: 255 seconds) |
18:11:03 | | Join alexweissman [0] (~alexweiss@149-160-178-46.dhcp-bl.indiana.edu) |
18:11:50 | | Join alexweis_ [0] (~alexweiss@149-160-178-46.dhcp-bl.indiana.edu) |
18:11:51 | | Quit alexweissman (Read error: Connection reset by peer) |
18:15:03 | | Quit alexweis_ (Read error: Connection reset by peer) |
18:27:05 | chrisjj | s/have caught a that launch fine/have caught a few that launch fine/ |
18:28:37 | | Quit saratoga (Quit: Page closed) |
18:39:28 | | Join JanC_ [0] (~janc@lugwv/member/JanC) |
18:40:21 | *** | Saving seen data "./dancer.seen" |
18:40:45 | | Nick JanC is now known as Guest43962 (~janc@lugwv/member/JanC) |
18:40:45 | | Quit Guest43962 (Killed (verne.freenode.net (Nickname regained by services))) |
18:40:45 | | Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) |
18:41:26 | | Quit parchd (Ping timeout: 245 seconds) |
18:42:49 | | Quit elensil (Quit: Leaving.) |
18:55:28 | | Join lebellium [0] (~chatzilla@89-93-179-5.hfc.dyn.abo.bbox.fr) |
19:00 |
19:01:05 | | Join alexweissman [0] (~alexweiss@c-73-102-58-181.hsd1.in.comcast.net) |
19:53:41 | | Join petur [0] (~petur@rockbox/developer/petur) |
20:00 |
20:02:17 | prof_wolfff | saratoga, [Saint], __builtin: i was running some codec_tests using different IRAM configurations, first tried the second 128Kib of IRAM (IRAM1) and realized that tonight i was wrong: the second half is the slow IRAM not the first half, it is correctly documented on clocking-s5l8702.h but for some unknown reason i was confused, so actually there are 200KiB of IRAM (the first 72 are fast and the next 128 are slow) |
20:02:42 | | Quit alexweissman (Remote host closed the connection) |
20:06:25 | prof_wolfff | on other test using only DRAM for codecs, the results was much better for some codecs and slightly worse for others |
20:09:28 | prof_wolfff | the bigger codecs (those that actually are using IRAM1) are faster running on DRAM |
20:12:37 | prof_wolfff | actually i am running a test using 80KB of IRAM0 (and not using IRAM1), it seem that the results are slightly better than using SDRAM, i will post some result when finished but it seems that the solution is to disable IRAM1 and use IRAM0 that looks slighly faster than DRAM |
20:26:41 | prof_wolfff | test_codec ipod6g results: https://www.pastiebin.com/5879290e70343 |
20:30:29 | prof_wolfff | also found the results of the RAM read/write tests: https://www.pastiebin.com/58792a9139b6d |
20:40:22 | *** | Saving seen data "./dancer.seen" |
20:46:01 | | Quit jhMikeS (Ping timeout: 245 seconds) |
21:00 |
21:05:52 | | Join girafe [0] (~girafe@LFbn-1-11729-221.w2-7.abo.wanadoo.fr) |
21:13:10 | | Join alexweissman [0] (~alexweiss@2001:18e8:2:28b6:65ef:c5c:b76b:6c68) |
21:17:43 | | Quit alexweissman (Ping timeout: 256 seconds) |
21:47:13 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
21:56:34 | | Join alexweissman [0] (~alexweiss@2001:18e8:2:28b6:c15d:2b4b:63f9:2d54) |
21:58:57 | | Quit alexweissman (Remote host closed the connection) |
22:00 |
22:00:31 | | Quit michaelni (Read error: Connection reset by peer) |
22:03:35 | | Join TheLemonMan [0] (~root@irssi/staff/TheLemonMan) |
22:08:12 | | Join saratoga [0] (123e1c1b@gateway/web/freenode/ip.18.62.28.27) |
22:08:36 | saratoga | prof_wolfff: how does current git use IRAM exactly? DRAM for most things and then IRAM attributes to allocate specific data into IRAM? |
22:09:14 | saratoga | IIRC most codecs will only allocate up to 48kb by default (and optionally up to 96kb if a config file option is set), so they should all be using the fast IRAM |
22:10:22 | pamaury | I want to add/modify a setting to have the speaker enabled automatically on headphone unplug. Currently there is an on/off setting only, I'm thinking about a third option (when jack detection is possible): enable only when headphone unplugs. Does that make sense ? |
22:10:35 | pamaury | gevaerts: ^ |
22:10:35 | pamaury | [Saint]: ^ I know you are picky about settings |
22:11:09 | lebellium | I think on/off/auto makes sense |
22:11:24 | lebellium | that is how it's usually implemented in OF |
22:14:45 | prof_wolfff | saratoga: actually there are codecs that uses more than 72Kb and, IIRC someone was using 120KB or more, those codecs are getting the worse results using current GIT (72 fast + 128 slow), and better results using on DRAM, the best result for almost all codes is using 80KB of IRAM as PP5022/24 is doing, i configured all 'big' codecs as PP5022/24 |
22:15:38 | pamaury | which targets have speakers and jack detection ? I know at least X-Fi2 and Mozaic |
22:15:56 | pamaury | possible X-Fi Style |
22:16:10 | pamaury | and X-Fi3 |
22:16:46 | saratoga | prof_wolfff: IIRC all original IRAM targets had 96KB, with 32KB (or 48?) reserved for OS, so most codecs can't use more than that without configuring some preprocessor settings |
22:16:51 | lebellium | I confirm my X-Fi Style has a speaker |
22:17:08 | saratoga | i think big gives you 128k- 32kb? |
22:17:26 | | Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) |
22:17:30 | saratoga | or maybe 128k -48k, i forget |
22:17:39 | pamaury | I know but I don't remember if it has jack detection |
22:17:41 | saratoga | i didn't think any could use even 100kb though |
22:17:44 | lebellium | I can check |
22:17:50 | lebellium | If I manage to boot the OF :D |
22:17:55 | lebellium | damn crappy device |
22:18:08 | pamaury | apparently it has |
22:18:15 | pamaury | at least I wrote code for that apparently :D |
22:18:20 | chrisjj | X-Fi style speaker does mute on headphone jack insert. |
22:18:35 | chrisjj | (On OF.) |
22:18:45 | prof_wolfff | it seems that PP5022/24 is using 48+80KB (apps/pligins/plugins.lds) for plugins and also for codecs, i suppose that 80KB or IRAM0 are enough also for plugins, at least plugins working on PP should work |
22:18:50 | prof_wolfff | saratoga^ |
22:19:36 | lebellium | pamaury: it does work in RB |
22:19:44 | lebellium | just tried it |
22:20:35 | pamaury | you have rockbox on the X-Fi Style ? |
22:20:38 | lebellium | yes |
22:21:02 | pamaury | Funny, I didn't even write the instructions on the wiki, I must have sent you instructions then |
22:21:03 | lebellium | 2014 build |
22:21:18 | lebellium | yes, we probably worked in together by to the time |
22:21:27 | lebellium | back to* |
22:21:39 | pamaury | because install is a bit tricky, it requires scsitools, you cannot just drop firmware.sb |
22:21:39 | lebellium | but I never used it again since then |
22:21:46 | prof_wolfff | saratoga: some codecs are using more than 100Ks when they are configured to put almost everything on IRAM |
22:21:57 | pamaury | lebellium: do you think settings on/off/auto is clear enough ? |
22:22:07 | lebellium | pamaury: we did many things. But I know you have sometimes troubles to remember what we did aha :D |
22:22:07 | pamaury | like litterally "auto" ? |
22:22:19 | pamaury | I have a very bad memory |
22:22:27 | pamaury | not enough RAM ;) |
22:22:39 | lebellium | I would say "auto" yes, I think it's clear enough that "auto" means when plug/unplug the jack |
22:22:42 | prof_wolfff | saratoga: no just code, they are defining big .ibss sections |
22:23:04 | chrisjj | Better than auto is "when audio jack unused", I think. |
22:23:17 | lebellium | that's not a nice name for a setting |
22:23:19 | lebellium | too long |
22:23:31 | chrisjj | It's a description. |
22:23:56 | chrisjj | And one that is shorter than some others already in place. |
22:24:53 | pamaury | when the manual will document it |
22:25:12 | pamaury | and I think "auto" is clear enough, I mean there aren't many options for a speaker :D |
22:25:37 | lebellium | well, some people may think the speaker gets activated when clapping in your hands |
22:25:41 | lebellium | I don't know |
22:25:44 | chrisjj | You'll update the manual?? :-) |
22:27:17 | saratoga | prof_wolfff: then you probably want to set it to work like on PP5020 and older where the codecs are limited to less IRAM so that you don't use the slower stuff |
22:29:10 | lebellium | pamaury: https://www.rockbox.org/irc/log-20140222 |
22:29:31 | | Quit saratoga (Quit: Page closed) |
22:29:32 | prof_wolfff | yes the IRAM0 test (second column) uses the same configuration as PP, 48+80 Kb, actually it is 56+200, fortunatelly there was free space on the current 56Kb so it can be decreased to 48 with no other changes |
22:29:39 | prof_wolfff | saratoga^ |
22:29:48 | pamaury | lebellium: ah yes indeed |
22:30:10 | | Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) |
22:32:05 | chrisjj | Updating the ZEN X-Fi style manual won't be trivial... since this is one of the many manuals that are currently missing. |
22:33:09 | pamaury | chrisjj: this setting is generic, it's not specific to any device |
22:33:31 | pamaury | there are other devices with speaker and headphones |
22:33:33 | pamaury | detect |
22:33:37 | lebellium | looks like only Creative targets have a speaker |
22:33:45 | pamaury | except those are quite old (ondas) |
22:34:32 | chrisjj | Which device having a speaker also has an RB manual? |
22:35:03 | pamaury | I'm unsure between 1) make the current speaker_enable setting an int instead of bool and simply add the "auto" option when it makes sense 2) have two differen settings (speaker_enable vs speaker_mode) depending on whether jack detect exists |
22:35:39 | pamaury | chrisjj: ZEN X-Fi3 has a manual on my computer, I just haven't pushed it yet |
22:35:59 | pamaury | and the ondas most probably |
22:36:36 | chrisjj | Onda isn't even listed https://www.rockbox.org/manual.shtml |
22:36:58 | pamaury | too bad |
22:37:07 | lebellium | Ondio |
22:37:26 | | Quit alexweissman (Remote host closed the connection) |
22:37:51 | lebellium | ah non |
22:37:56 | lebellium | Onda VX777 |
22:37:58 | lebellium | my bad |
22:38:19 | chrisjj | Thanks. Note: Ondio's manual doesn't mention the speaker setting. |
22:38:59 | lebellium | I never noticed there is theme entry for Onda but no Rockbox build |
22:39:10 | chrisjj | Onda VX777 doesn't have a manual AFAICT. |
22:40:26 | *** | Saving seen data "./dancer.seen" |
22:40:36 | lebellium | pamaury: hum do you know why the Creative targets don't appear here http://themes.rockbox.org/ ? |
22:40:58 | pamaury | The Onda are most definitely built on every commit |
22:41:06 | pamaury | maybe the builds are just not advertised |
22:41:32 | chrisjj | pamaury, does ZEN have an unpushed manual? |
22:41:45 | pamaury | no, I don't rememer how the theme page works |
22:42:43 | pamaury | chrisjj: no |
22:46:39 | chrisjj | pamaury, if your speaker_enable choice is to show in the API function, then I vote for 1. Definitely. |
22:47:06 | lebellium | yp-r1 |
22:47:15 | lebellium | err, sorry |
22:47:52 | __builtin | pamaury: no, I wasn't |
22:48:00 | lebellium | I'm searching my logs how the theme website works. I'm sure I already asked how to get the YP-R1 show up on the theme website some years ago |
22:48:01 | __builtin | (using a debug build) |
22:48:33 | chrisjj | That would be the future API function, since there's none present at the moment, AFAICS. |
22:51:11 | pamaury | it's not that simple though, the audiohw driver doesn't know about the jack, the API will still be on/off. It's the apps/ code that handles the (un)plug magic. I am not sure it's really a good idea to have an API function that takes on/off/auto |
22:51:15 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
22:51:15 | * | pamaury needs to think about it |
22:53:46 | pamaury | or I could change the semantic of audiohw_enable_speaker: 0 means off, 1 means on, 2 means "on only if jack unplug", but this is a one time thing. Then apps/ is responsible for calling this function again when jack is (un)plugged |
22:58:23 | Bilgus | [Saint], After spending the day with that time selector I think it is less intuitive than the sprawling lists esp when the custom Values are taken in to account (on, off, eternal,...) so instead I think I'm just going to make a flag 'F_TIME_SETTING' with the 'F_TABLE_SETTING' & 'F_INT_SETTINGS' of the current menu system and have it take care of units, TALK IDs etc. |
23:00 |
23:00:31 | [Saint] | Hmmm, interesting. I did test that time picker yesterday, I hadn't got around to mentioning that on the gerrit task though. I think you're right, it is well implemented but it really does seem like the massive granular scrolling lists are the way to go. |
23:00:32 | chrisjj | pamaury, wouldn't that change break API compatibility? |
23:01:44 | pamaury | no, old targets still keep 0/1, semantic is unchanged, it only adds more possibility |
23:02:04 | [Saint] | The only thing that bugs the shit out of me with the aforementioned massive scrolling list of units is that some of them are entirely arbitrary for seemingly no reason. |
23:02:15 | chrisjj | lebellium: https://github.com/Rockbox/themesite/blob/master/README Line 21 might help? |
23:03:00 | Bilgus | I think i will remove that unless the user wants to put them in and allow NULL to auto generate them |
23:03:25 | [Saint] | Like, one timer setting will only go in units of 5 second increments, another in 2 second increments, the others in 1 second...etc. And the capped values which are often arbitrary as well can vary wildly. |
23:03:30 | Bilgus | of some DEFINE like DEFAULT_TALK_ID |
23:04:34 | Bilgus | Well the way I plan to do it will still allow that, I just see any reason to get rid of the ability to have non-sequential values for time |
23:04:48 | Bilgus | *Don't see |
23:05:16 | [Saint] | ...what exactly do you think I'm suggesting? |
23:05:31 | Bilgus | for instance one goes from like 1-7s 10 15 30 then 1m 5m 10m |
23:05:35 | chrisjj | pamaury, no chance of an app that reads the current bool breaking when you change it to an int and provide a new value that old apps don't recognise? |
23:06:36 | Bilgus | I think the table value ones return an index instead of a value though |
23:06:43 | [Saint] | Oh. Right. I see what you're talking about now. You're talking about a define to allow the settings lists to be either? |
23:06:45 | pamaury | I will double check, only very few places are supposed to read settings and it's easily grepped |
23:07:01 | Bilgus | I think I might just make the time ones return Ticks or MS always |
23:07:19 | chrisjj | Aren't plugins allows to read such settings? |
23:07:28 | chrisjj | s/allows/allowed/ |
23:07:31 | Bilgus | Saint Yes |
23:07:46 | Bilgus | I mean they already are in a way but its a mess |
23:08:15 | Bilgus | probably return MS always and expose a function for MS -> ticks |
23:08:26 | [Saint] | I think the shit thing is about having non-linear increments, and hear me out here...is that it is entirely inflexible. Like, if a user gets into the higher ranges and there's increments of say 15, 20, 30, etc. |
23:08:34 | [Saint] | ...what if they want, ...17.24? |
23:08:42 | pamaury | no plugins cannot read settings afaik and even if they can, grep shows that speaker is not touched by any plugin |
23:08:49 | pamaury | which is expected |
23:08:56 | chrisjj | Any plung in your hard drive, that is. |
23:09:16 | Bilgus | yeah thats what i tried to do with the ones i sent the screen shot for but it is un intuitive |
23:09:18 | chrisjj | Correction: Any plugin on your hard drive, that is. |
23:10:09 | [Saint] | A lot of these timer increments and their caps are absolutely arbitrary, and it's weird to see the different styles in the menus throughout the years. Some authors allow for much more/less granularity at seemingly the toss on a coin. |
23:10:24 | Bilgus | and with the old way a list of 100 MS to say 10 minutes would be massive on RAM |
23:10:37 | [Saint] | The inconsistency has always been one of my "roundtoit" things. |
23:11:15 | | Quit chrisjj (Quit: Page closed) |
23:12:02 | Bilgus | maybe it could be hybrid like have the list of values and a right key press increases the resolution |
23:12:43 | | Join chrisjj [0] (5001d87b@gateway/web/freenode/ip.80.1.216.123) |
23:13:00 | Bilgus | say the cursor is on 10 seconds and it is in 10 sec increments press right and it is at 10 sec but you have 5 sec increments |
23:13:09 | [Saint] | shit...y'know, I think there /is/ a picker like that somewhere in the core. |
23:13:16 | Bilgus | sorry *granularity |
23:13:16 | [Saint] | Dammit. I can't remember it. |
23:14:21 | Bilgus | If you could find it/ or are sure it is somewhere I'd love to have a lookse |
23:14:54 | __builtin | the date/time screen? |
23:15:26 | Bilgus | builtin that is the style the one I just did was in |
23:15:40 | Bilgus | https://imgur.com/a/6EYnW |
23:16:04 | Bilgus | it is not intuitive IMO |
23:16:28 | Bilgus | Its highly granular though |
23:17:45 | pamaury | chrisjj: I don't see your point, at the end of the day, there is no way not the break old code since it assumed only two possibilities and now there are three. |
23:18:12 | chrisjj | There is way. Your option 2. |
23:19:12 | lebellium | gevaerts: do you know why the YP-R1 and Onda don't show up on https://build.rockbox.org/ although they are in buildserver/build ? They're both the only 240x400 targets but I assume it's a coincidence |
23:21:24 | pamaury | chrisjj: it doesn't help, assuming (which is a big if) there is some code no in our repository that relies on the speaker setting to be a boolean, option #2 would simply delete this setting. Thus the code would most probably crash because it cannot find the setting. |
23:21:43 | | Part chrisb ("rcirc on GNU Emacs 26.0.50.1") |
23:22:14 | chrisjj | Ah, I misunderstood your option 2 then. |
23:22:15 | gevaerts | lebellium: pretty sure it's because they're listed as "unusable" in tools/builds.pm |
23:22:19 | [Saint] | I think maybe it's the pitch screen? |
23:22:23 | chrisjj | Option 3 then! |
23:22:37 | [Saint] | Bilgus: __builtin ^ |
23:23:00 | chrisjj | Option 3 leaves the existing bool and adds a second bool. |
23:23:15 | lebellium | gevaerts: ah! Thanks. It's a rule that only unstable and stable targets deserve to be visible, right? |
23:23:36 | gevaerts | I think so |
23:23:55 | chrisjj | The second bool is speaker_mode: 0 = speaker always, 1 = speaking only when audio jack unused. |
23:24:09 | pamaury | that is super ugly |
23:24:25 | chrisjj | How so? |
23:25:21 | chrisjj | That speaker_mode is I thought the speaker_mode your Option 2 was suggesting. |
23:25:29 | Bilgus | [Saint], __builtin So lets lay out some functionality for a good time picker we have 2 ways to allow the user 1 is a table and in that case the time flag (TF) will just take care of Talk Ids and units and then we have 2 the Int range with unit |
23:25:39 | pamaury | it creates an orthogonal setting for something not orthogonal, also it allows for setting that don't make sense, like speaker=off, speaker_mode = only when jack unplug |
23:26:19 | [Saint] | I think you could get fancy on most targets and use a duration of button_repeat to decide how to increment the units. |
23:26:45 | pamaury | not my option 2 is speaker_mode has three possibilities: off,on,auto. The difference with option #1 is that there are now two settings: speaker_enabled (bool) on targets without jack detect and speaker_mode (int) on targets with jack detect, but not both |
23:26:54 | [Saint] | individual clicks for granularity, and repeat press for nonlinear increments. |
23:27:20 | [Saint] | but we already kinda do that with the scroll acceleration. |
23:27:36 | Bilgus | that is pretty similar to what the Screen Shot one did |
23:28:00 | pamaury | anyway all of this is pointless, speaker is not exported to plugins, plugins don't have anyway of enabling/disabling the speaker |
23:28:32 | [Saint] | it's really weird that it keeps coming back to "massive infinitely long scrolling list" ending up being the most obvious and intuitive. |
23:28:35 | [Saint] | it's just implemented inconsistently in core for arbitrary reasons in most cases. |
23:28:39 | chrisjj | Option 3's second bool doesn't allow for a setting that doesn't make sense. It allows for a setting of speaker mode that has no effect unless speaker is not used. |
23:28:59 | pamaury | and I don't see how that helps |
23:29:07 | Bilgus | plus if you start doing that it will still be weird when On/off/eternal comes up |
23:29:11 | pamaury | that would mean exporting two settings to the user, very confusing |
23:29:36 | chrisjj | It helps by guaranteeing no breakage of existing code. |
23:29:52 | lebellium | gevaerts: looks like YP-R1 was forgotten in builds.pm. Onda is there in status 1 (unsuable) indeed. Might that explain why the YP-R1 doesn't show up on the theme website? (the Onda does) |
23:30:40 | gevaerts | the theme site needs things added to it manually |
23:30:46 | pamaury | chrisjj: but the only existing code in is rockbox and is trivial to fix |
23:30:46 | chrisjj | Exporting two settings a bit lnke Backlight and Backlight (While Plugged In). Not confusing I think. And not a confusing as broken code. |
23:31:08 | gevaerts | IIRC the original policy was "stable only", but there are a few exceptions |
23:31:20 | chrisjj | Ah, I thought there could be existing code in plugins. |
23:31:42 | chrisjj | Sorry if I am wrong. |
23:31:47 | pamaury | I told you, speaker is not exported to plugins |
23:33:04 | Bilgus | so maybe I can do infinite long list and left and right do page up/page down |
23:33:26 | chrisjj | And plugins can't read settings? You said "afaik". |
23:33:40 | | Quit skapazzo (Quit: leaving) |
23:33:53 | [Saint] | Bilgus: I tend to think you don't really need an 'off'. |
23:33:56 | [Saint] | 0 is off. |
23:34:22 | [Saint] | though that leaves the 'always' option still. |
23:34:23 | Bilgus | backlight had on =0 -1 = off |
23:34:40 | [Saint] | yeah, right. a lot of settings do that I think. |
23:34:44 | TorC | Bilgus: There actually is a time picker already in core much like the image you'd posted. It's the set time function. |
23:35:04 | Bilgus | I know TorC I based the style on that |
23:35:38 | TorC | Not surprised. I think it's pretty straightforward and obvious. |
23:36:07 | TorC | But then I'm not always the best choice of proxy for "most users" |
23:36:14 | Bilgus | except when you start allowing custom formatting with text options |
23:36:44 | pamaury | chrisjj: I can have a look, in doubt I just bump the plugin version: old binaries won't load because of mismatch, and old code won't compile because setting is different, no confusion possible |
23:36:46 | Bilgus | the list is more intuitive IMO |
23:37:45 | | Quit amayer (Quit: Leaving) |
23:37:51 | lebellium | gevaerts: are you the right guy to ask to add the 4 stable Creative targets, the 3 stable Sony targets and discuss for a possible exception for YP-R1N |
23:37:53 | lebellium | ? |
23:38:00 | Bilgus | If it was strictly time I love what I made and It was going to go in place of the alarm time picker but I spent the day with it and Am not impressed |
23:38:26 | chrisjj | Sounds like a reasonable compromise to me. Then yes I'd vote for your Option 1), though I cast that only as a future plug-in writer. |
23:39:57 | chrisjj | pamaury: ... and if you do find plugins can't read/write the speaker mode setting, then please register my vote for this to be remedied :-) |
23:41:39 | gevaerts | lebellium: can you provide the correct full name, checkwps-compatible name, resolution, depth, and name of the file in playerpics/ for them? |
23:42:00 | gevaerts | In triplicate, on the correct form, with stamps |
23:42:30 | pamaury | just looked, plugins can read/write settings (any setting), but if I change the setting name, they won't compile, so that seems like a good compromise to me. Again I don't see why any plugin would touch the speaker |
23:43:00 | * | gevaerts doesn't know anything about the YP-R1N's status, so he doesn't have an opinion |
23:43:14 | lebellium | I meant "?" instead of "N" |
23:43:49 | TorC | Bilgus: I suppose it is true that getting such a picker to act sensibly with the wide variety of value ranges needed for different settings is tricky, and at least the list ensures that picking non-sense values can't be done. |
23:43:52 | * | gevaerts doesn't know anything about the YP-R1's status, so he doesn't have an opinion :) |
23:44:00 | lebellium | I'm sure I can gather all those needed information quite easily. Maybe pamaury can help me for the display depth (Creative and SOny) |
23:44:17 | pamaury | lebellium: what do you need to know ? |
23:45:17 | Bilgus | TorC its fully ranged no chance of non-sense values just not intuitive |
23:47:01 | lebellium | pamaury: well, I'd like to gather the necessary data (what he wrote above) for stable targets missing on the theme website. That's Creative Zen Mosaic, Zen X-Fi, Zen X-Fi 3, Zen X-Fi Style, Sony NWZ-E360, NWZ-E370, NWZ-E380, Samsung YH-820 and YH-920 |
23:47:03 | TorC | Guess that's just a case where the first, simplest solution turns out to be the right one. More because anything else is overkill than anything else. |
23:48:51 | pamaury | lebellium: ok, which data ? (/me doesn't want to read the log) |
23:48:58 | chrisjj | pamaury: A plugin would touch the speaker if it wanted to give the user the option of turning on and off the speaker :-) |
23:49:18 | lebellium | pamaury: I guess I can find everything excep the display depth |
23:49:35 | lebellium | 16 or 24 |
23:49:51 | __builtin | chrisjj: no plugin needs that... |
23:50:02 | chrisjj | How so? |
23:51:31 | pamaury | lebellium: creativezenxfi.h:#define LCD_DEPTH 24 |
23:51:31 | pamaury | creativezenxfistyle.h:#define LCD_DEPTH 16 |
23:51:31 | pamaury | creativezenxfi2.h:#define LCD_DEPTH 16 |
23:51:31 | DBUG | Enqueued KICK pamaury |
23:51:31 | pamaury | creativezenmozaic.h:#define LCD_DEPTH 16 |
23:51:35 | pamaury | creativezenv.h:#define LCD_DEPTH 16 |
23:51:35 | pamaury | creativezenxfi3.h:#define LCD_DEPTH 16 |
23:51:35 | pamaury | creativezen.h:#define LCD_DEPTH 24 |
23:51:55 | pamaury | sonynwze370.h:#define LCD_DEPTH 16 |
23:51:55 | pamaury | sonynwze360.h:#define LCD_DEPTH 16 |
23:51:56 | lebellium | ok so I know where I have to look for the others |
23:52:00 | lebellium | thank |
23:52:03 | lebellium | s |
23:52:37 | pamaury | chrisjj: there is already a setting for that |
23:52:44 | pamaury | what's the point of duplicating a setting ? |
23:53:15 | chrisjj | There is already a setting for speaker, but not accessible while running a plugin AFAICT. |
23:53:25 | chrisjj | There's no point duplicating a setting. |
23:53:49 | chrisjj | There is point providing player controls in a plugin. |
23:55:56 | chrisjj | Players controls are already in many plugins. Menu "Playback Control". |