--- Log for 28.10.121  Server: calcium.libera.chat  Channel: #rockbox
--- Nick: rb-logbot  Version: Dancer V4.16  Started: 11 days and 2 hours ago

00.48.04 ***     Saving seen data "./dancer.seen"
02.48.08 ***     No seen item changed, no save performed.
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.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.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.50.56 #       <edhelas> It seems that deactivating a few features didn't changed the IRAM overflow limit. I'll try to investigate more
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.18.05 Quit    massiveH (Quit: Leaving)
10.48.22 ***     Saving seen data "./dancer.seen"
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.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.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.48.30 ***     Saving seen data "./dancer.seen"
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.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> 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.19.00 Quit    nihilazo (Quit: Leaving)
17.20.31 Quit    lebellium (Quit: Leaving)
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.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.48.39 ***     Saving seen data "./dancer.seen"
21.10.25 Quit    ac_laptop (Ping timeout: 260 seconds)
22.48.43 ***     Saving seen data "./dancer.seen"