| 00:48:04 | *** | Saving seen data "./dancer.seen" |
| 02:00 |
| 02:48:08 | *** | No seen item changed, no save performed. |
| 03:00 |
| 03:36:19 | edhelas | Hi, by trying to compile the USB Audio branch I have an IRAM overflow |
| 03:36:21 | edhelas | /usr/local/lib/gcc/arm-elf-eabi/4.9.4/../../../../arm-elf-eabi/bin/ld : /home/edhelas/Repositories/rockbox/build/rockbox.elf la section «.stack» ne va pas s'adapter à la région «IRAM» |
| 03:36:21 | edhelas | /usr/local/lib/gcc/arm-elf-eabi/4.9.4/../../../../arm-elf-eabi/bin/ld : la région «IRAM» est débordée de 648 octets |
| 03:36:21 | edhelas | collect2: erreur: ld a retourné 1 code d'état d'exécution |
| 03:36:43 | edhelas | both for iPod Video and iPod Mini devices, any ideas how I can fix it ? |
| 03:51:32 | munkis | figure out ho to make the code footprint smaller, or alternatively remove a feature you don't use |
| 03:53:32 | edhelas | is there a simple way to toggle features ? |
| 03:55:28 | munkis | a lot of features are gated behind #ifdef s if you want to remove something you can carefully change them to #ifdef 0 or remove the #define from the config file |
| 04:00 |
| 04:02:38 | edhelas | which ones did you disabled for example :) ? |
| 04:04:55 | munkis | I am using fuze+ which has 8x the ram and ospace issues |
| 04:05:46 | munkis | also jst to make sure you know the patch is to let you use your rockbox device as a speaker for a usb host not the otjer wa around. |
| 04:17:47 | edhelas | yes :) |
| 04:48:12 | *** | No seen item changed, no save performed. |
| 06:00 |
| 06:48:14 | *** | No seen item changed, no save performed. |
| 06:50:45 | | Join ac_laptop [0] (~ac_laptop@2a01:cb1c:3c8:2700:e29d:31ff:fe2d:a258) |
| 07:00 |
| 07:50:56 | edhelas | It seems that deactivating a few features didn't changed the IRAM overflow limit. I'll try to investigate more |
| 08:00 |
| 08:20:55 | speachy | what's in IRAM tends to be things like hot code routines (eg for stuff like display or interrupt handling) and data that is critical for performance |
| 08:21:00 | speachy | (eg audio buffers) |
| 08:27:33 | spork | when playback is stopped you have the option 'clear list & play shuffled', when playback is paused or playing you do not. is there a special reason for that? |
| 08:28:09 | spork | 'clear list & play next' does exist in both states |
| 08:31:23 | amdj | speachy: the ground loop isolator I bought (https://www.ebay.co.uk/itm/164876981937) has fixed the issue; my multimeter confirms there's no DC continuity between the 2 grounds, and it no longer cuts out audio and clicks (power bank) or crashes almost immediately (car). :) |
| 08:46:44 | amdj | speachy: https://www.youtube.com/watch?v=Lu1ChPYSc2g :) |
| 08:48:18 | *** | No seen item changed, no save performed. |
| 08:48:51 | | Join massiveH [0] (~massiveH@ool-18e4ebfe.dyn.optonline.net) |
| 10:00 |
| 10:18:05 | | Quit massiveH (Quit: Leaving) |
| 10:48:22 | *** | Saving seen data "./dancer.seen" |
| 11:00 |
| 11:01:12 | | Join chris_s [0] (~chris_s@ip-95-223-74-217.hsi16.unitymediagroup.de) |
| 11:04:48 | chris_s | bilgus: ok, thanks! |
| 11:05:17 | chris_s | spork: I could be way off base, but iirc it has something to do with the peculiarities of the implementation to add shuffled tracks to the playlist. |
| 11:05:26 | chris_s | "Insert Shuffled" actually inserts the tracks at random *positions* to the playlist instead of only in random order (i.e. something like "Play Next Shuffled" doesn't currently exit). |
| 11:05:38 | chris_s | This works fine and makes no difference if you start over with a new playlist anyway, but becomes a problem when the playlist already contains something (during playback or when paused). |
| 11:05:58 | chris_s | Maybe it's not difficult to change, I don't know, but when I looked into it at some point it seemed less than trivial to me, at least at first sight. |
| 11:08:41 | | Quit chris_s (Quit: Connection closed) |
| 11:52:14 | spork | sure, but the option is to 'clear list' |
| 11:52:28 | spork | so the existing list should not matter ? |
| 12:00 |
| 12:14:27 | | Join chris_s [0] (~chris_s@ip-95-223-74-217.hsi16.unitymediagroup.de) |
| 12:15:11 | | Quit chris_s (Client Quit) |
| 12:16:25 | | Join chris_s [0] (~chris_s@ip-95-223-74-217.hsi16.unitymediagroup.de) |
| 12:20:08 | chris_s | well, when something is already playing/paused, Clear List & Play Next will continue playing the current track at least, so it's not quite the same as when playback is stopped and a new playlist is immediately created |
| 12:22:26 | | Quit chris_s (Quit: Connection closed) |
| 12:22:36 | | Quit wolfshappen (Ping timeout: 245 seconds) |
| 12:26:19 | | Join wolfshappen [0] (~waff@irc.furworks.de) |
| 12:33:11 | spork | ok, that is a difference indeed |
| 12:33:50 | spork | but 'clear list & play next' is there and sounds very similar |
| 12:34:15 | spork | i am trying to play a folder shuffled btw, not a single tracks |
| 12:36:22 | spork | (captain obvious, of course it is a folder. hard to shuffle a single track ..) |
| 12:41:31 | | Quit wolfshappen (Ping timeout: 265 seconds) |
| 12:42:13 | | Join wolfshappen [0] (~waff@irc.furworks.de) |
| 12:42:18 | | Join nihilazo [0] (~nihilazo@2607:f298:5:101d:f816:3eff:fe1a:29a3) |
| 12:48:26 | *** | Saving seen data "./dancer.seen" |
| 13:00 |
| 13:07:39 | | Join chris_s [0] (~chris_s@ip-95-223-74-217.hsi16.unitymediagroup.de) |
| 13:08:36 | chris_s | certainly seems useful and possibly more straightforward to implement than I’m imagining. |
| 13:08:52 | | Quit chris_s (Client Quit) |
| 13:13:14 | nihilazo | hi, I've been making a plugin using the guide on the wiki and it builds for my x3 (which is cool). Once it's built, how do I transfer it to my player? Is there any more to do than just copying the .rock file? |
| 13:13:43 | | Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) |
| 13:13:55 | speachy | I'd recommend the 'make zip' and then unzip the whole thing to the player. just to make sure everything is in sync. |
| 13:14:09 | nihilazo | ok |
| 13:14:54 | nihilazo | just extract over the existing .rockbox? |
| 13:18:35 | speachy | yep |
| 13:19:08 | nihilazo | ayy it runs! |
| 13:19:10 | nihilazo | my plugin works :D |
| 13:19:19 | nihilazo | well, it doesn't do what it's meant to yet. But progress! |
| 13:19:36 | speachy | hey, getting it running at all is 90% of the effort |
| 13:19:50 | speachy | now you just have to finish the second 90%. |
| 13:19:59 | nihilazo | hmmm |
| 13:19:59 | nihilazo | lol |
| 13:22:41 | nihilazo | also, is there a more convenient way to develop a rockbox plugin than having a fork of all of rockbox? |
| 13:23:11 | nihilazo | rn I'm developing my plugin inside the apps/plugins/ dir of a clone of the entire rockbox source |
| 13:23:25 | speachy | that's how pretty much all development happens...? |
| 13:23:29 | nihilazo | ok on |
| 13:23:34 | nihilazo | s/ok on/oh ok/ |
| 13:23:42 | nihilazo | just wondering if there is a different plugin dev environment or smth |
| 13:23:53 | speachy | patches proposed for inclusion (or not) get shoved into gerrit for review |
| 13:24:22 | nihilazo | oh, I'm not really planning to have this made part of rockbox proper, it's an experiment more than anything rn |
| 13:44:17 | | Join lebellium [0] (~lebellium@2a01cb04012c0900f0a1188d85eb059e.ipv6.abo.wanadoo.fr) |
| 14:00 |
| 14:48:30 | *** | Saving seen data "./dancer.seen" |
| 15:00 |
| 15:00:27 | nihilazo | what type are the values returned by LCD_RGBPACK()? |
| 15:07:28 | nihilazo | maybe I'm XY-questioning. I want to store a color pallete, what's the best way to do that |
| 15:08:47 | nihilazo | I could do an array of arrays of 3 values for r, g, and b |
| 15:08:59 | nihilazo | but I thought using a more native format would be better |
| 15:45:48 | | Nick tertu2 is now known as tertu (~tertu@2601:449:8380:8aa0:d250:99ff:fedf:91a7) |
| 15:55:05 | | Quit tertu (Changing host) |
| 15:55:05 | | Join tertu [0] (~tertu@user/tertu) |
| 16:00 |
| 16:09:44 | _bilgus | nihilazo, unsigned int |
| 16:10:36 | nihilazo | cool thanks |
| 16:25:58 | nihilazo | I'm getting an odd bug with building my plugin (for either the simulator or x3) where somehow the linker doesn't seem to find realloc https://ttm.sh/eAR.txt |
| 16:26:11 | nihilazo | I can't think of why this could be because I thought this was a very standard function |
| 16:29:48 | nihilazo | (my code is just being uploaded rn if anybody needs to look at it) |
| 16:31:38 | nihilazo | nihilazo/rockbox/src/branch/varvara/apps/plugins/varvara/devices/ppu.c">https://tildegit.org/nihilazo/rockbox/src/branch/varvara/apps/plugins/varvara/devices/ppu.c this is where the offending realloc is |
| 16:32:46 | _bilgus | the plugins don't do realloc or alloc |
| 16:33:11 | _bilgus | might be mapped already but IIRC you have to do your own wrapper using buflib |
| 16:33:29 | nihilazo | buflib? |
| 16:33:49 | _bilgus | you feed it a mempool and it allocs and shuffles for you |
| 16:34:11 | nihilazo | mempool? sorry I'm confused by all of this |
| 16:34:14 | _bilgus | i think the helper is in plugins/lib |
| 16:34:20 | nihilazo | so rockbox has all its own memory management stuff? |
| 16:34:22 | nihilazo | basically |
| 16:34:28 | nihilazo | for plugins |
| 16:34:42 | _bilgus | ok so rockbox doesn't use malloc or alloc you are probably blowing the heap |
| 16:35:18 | nihilazo | wait I don't think I even need alloc here |
| 16:35:21 | nihilazo | one sec |
| 16:36:42 | _bilgus | you get a plugin buffer that your program runs from you get the rest of pluginbuf |
| 16:37:00 | _bilgus | you can also take over the audio playback buffer |
| 16:37:33 | _bilgus | rb->plugin_get_buffer(&size) |
| 16:37:37 | nihilazo | I will eventually need to do audio playback from within my plugin |
| 16:38:09 | _bilgus | rb->plugin_get_audio_buffer(&size) |
| 16:38:23 | _bilgus | the pcm buffer likely |
| 16:39:07 | _bilgus | there should be enough source material in the other plugins but keep in mind that most functions are provided through the plugin struct (rb->) |
| 16:39:34 | nihilazo | ok thanks |
| 16:39:53 | _bilgus | you have to provide them if they aren't (or possibly pull them in from core) makes duplicated code |
| 16:40:29 | _bilgus | keep inmind that static allocs don't really cost you more in the plugins |
| 16:40:41 | _bilgus | infaxct they cost less.. |
| 16:41:04 | nihilazo | yeah I'm rewriting my thing to just need static ones |
| 16:41:12 | nihilazo | no dynamic alloc should be needed |
| 16:41:13 | _bilgus | figure the file gets processed and the whole shebang gets copied to the pluginbuf |
| 16:44:13 | nihilazo | ? |
| 16:44:45 | _bilgus | our plugins are technically a big compiled block of data that has offsets aligned to run in the pluginbuf at a specific offset in ram they are not position independent |
| 16:45:23 | _bilgus | so to compile a plugin its locked to that specific version of core |
| 16:45:51 | nihilazo | ok |
| 16:45:56 | _bilgus | essentially each of the plugins occupy the same place (from the view of the compiler) |
| 16:47:31 | _bilgus | think of it like this if it weren't for the plugin buffer your rockbox install would just have your plugin buffer occupying the binary |
| 16:48:17 | _bilgus | instead each plugin gets compiled as if it were the only code then we shuffle them in and out |
| 16:48:33 | *** | Saving seen data "./dancer.seen" |
| 16:49:33 | _bilgus | whatever is left after your binary data is the plugin_buf presented in the rb->pluginbuf fn |
| 16:51:50 | nihilazo | ok |
| 17:00 |
| 17:19:00 | | Quit nihilazo (Quit: Leaving) |
| 17:20:31 | | Quit lebellium (Quit: Leaving) |
| 18:00 |
| 18:05:35 | | Quit ZincAlloy (Quit: Leaving.) |
| 18:06:00 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:6a:60cd:1468:c48e) |
| 18:06:13 | | Quit ZincAlloy (Client Quit) |
| 18:48:35 | *** | Saving seen data "./dancer.seen" |
| 19:00 |
| 19:57:53 | | Quit speachy (Ping timeout: 244 seconds) |
| 19:58:41 | | Join speachy [0] (~speachy@taster.shaftnet.org) |
| 19:58:42 | | Quit speachy (Changing host) |
| 19:58:42 | | Join speachy [0] (~speachy@rockbox/developer/speachy) |
| 19:58:42 | Mode | "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) |
| 20:00 |
| 20:48:39 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:10:25 | | Quit ac_laptop (Ping timeout: 260 seconds) |
| 22:00 |
| 22:48:43 | *** | Saving seen data "./dancer.seen" |
icon identifies that the person is a core developer (has commit access).