--- Log for 08.09.111 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 3 days and 17 hours ago 00.01.44 Quit bertrik (Quit: :tiuQ) 00.12.50 Quit lebellium (Quit: ChatZilla 0.9.87 [Firefox 7.0/20110902161802]) 00.18.31 # shouldn't r30468 be only applied for mingw builds? 00.21.37 # OK, I found the same question as mine in the forum... and a link to mp4muxer, which works like a charm under Wine, and everything is perfect: I can read my music on my player 00.21.51 # n1s: Llorean: thanks a lot for your help 00.22.15 # (and for doing rockbox if you're both developpers :) ) 00.23.07 # no problem, it's a limitation of our aac codec 00.24.25 Join saratoga [0] (9803ec71@gateway/web/freenode/ip.152.3.236.113) 00.25.11 # Another question: would it be possible to make my player boot the original firmware by default but keep the possibility to boot rockbox? 00.25.37 # (this is just out of curiosity, I *will* use rockbox :-) ) 00.25.37 # possible, but not very easy 00.25.45 # ok 00.26.06 Quit liar (Quit: hallowed are the ori!) 00.26.17 # you'd need to make a (probably) small change to the bootloader but you'd need a build environmet to build it 00.26.41 # ok 00.27.50 Join froggyman [0] (~seth@50.105.133.91) 00.27.50 Quit froggyman (Changing host) 00.27.50 Join froggyman [0] (~seth@unaffiliated/froggyman) 00.28.46 Quit ender` (Quit: C++ is a modern language where your parent can't touch your privates but your friends can!) 00.34.27 Join Scromple [0] (~Simon@115-64-195-104.static.tpgi.com.au) 00.34.41 Join TheLemonMan [0] (~LemonBoy@ppp-219-56.26-151.libero.it) 00.45.53 Quit JesusFreak316 () 00.46.17 Join JesusFreak316 [0] (~JesusFrea@pool-173-65-77-65.tampfl.fios.verizon.net) 00.47.18 *** Saving seen data "./dancer.seen" 01.00.40 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 01.08.39 Quit FoH_Phobos (Quit: leaving the market—and net access) 01.16.32 # New commit by 03kugel (r30469): Buflib: Clarification about invalid handles ... 01.19.09 # r30469 build result: 9 errors, 0 warnings (kugel committed) 01.20.13 # New commit by 03kugel (r30470): Remove unecessary casting 01.23.15 # r30470 build result: 8 errors, 0 warnings (kugel committed) 01.32.58 Join ReimuHakurei_ [0] (~kudo@wireless.sit-co.net) 01.33.03 Quit ReimuHakurei (Read error: Connection reset by peer) 01.42.23 # jhMikeS: the short audio stop is heavily less noticable with Q_AUDIO_REMAKE_AUDIO_BUFFER 01.56.20 # jhMikeS: can you please have alook at http://pastie.org/2500075 ? I'm not 100% certain if I implemented it correctly (although I think I did) 02.02.16 Join soap [0] (~soap@94.75.232.194) 02.02.16 Quit soap (Changing host) 02.02.16 Join soap [0] (~soap@rockbox/staff/soap) 02.05.27 Quit robin0800 (Ping timeout: 258 seconds) 02.05.45 Join Lalufu [0] (~sun@unaffiliated/lalufu) 02.06.08 Join soap__ [0] (~soap@66.178.206.246) 02.08.09 # Hi. 02.08.49 # I could need a hand by someone familiar with the PP5020 chip. 02.08.56 Quit soap (Ping timeout: 276 seconds) 02.09.05 Join robin0800 [0] (~robin0800@149.254.61.29) 02.09.18 # I'm trying to get IAP support running on a iPod mini 2g, and it basically works. 02.09.33 Join soap [0] (~soap@80.90.43.9) 02.09.43 Quit soap (Changing host) 02.09.43 Join soap [0] (~soap@rockbox/staff/soap) 02.10.02 # problem is that all the code assumes that the serial pins on the apple connector are routed to the SER0 on the PP5020, while on the mini2g it seems to be connected to SER1. 02.10.27 Quit soap__ (Ping timeout: 245 seconds) 02.11.06 # I have no idea if this is something that can be changed by twiddling the right registers on the PP502 02.11.35 # but if it can all that's missing for this to work OOTB would be a line in firmware/drivers/serial.c 02.14.01 # kugel: "(0 is also not a valid handle)" I tihnk adds confusion. There is no need to specify it if you already know everything returns negative numbers for error values 02.14.20 # core_free() returns 0 02.14.35 # thats different though 02.15.03 # you wouldnt expect people to do handle = core_free() 02.15.22 # well, saying a negative number is an error might lead to thinking 0 is ok 02.15.38 # JdGordon: this is the intention of returning 0 02.15.53 # I dont think that is a good idea 02.16.18 # core_free should return void to stop that 02.16.34 # does close(fd) return an int?> 02.17.08 # hmm, interesting 02.17.17 # it actually returns 0 on success 02.17.23 Join JesusFreak316_ [0] (~JesusFrea@pool-173-65-77-65.tampfl.fios.verizon.net) 02.17.31 # as the comment says 02.17.31 Quit JesusFreak316 (Read error: Connection reset by peer) 02.17.31 # why? 02.17.31 # no 02.18.23 # heh, right 02.18.23 # I'm repeatedly annoyed that free() doesn't return NULL 02.19.04 Quit robin0800 (Ping timeout: 240 seconds) 02.20.03 # how does buf_get_data cope with handle == 0? 02.20.57 # not at all, and I don't really want to add useless error checking there 02.21.29 # so anyone doing handle = core_free() and checks for handle < 0 before opening it will crash? 02.22.08 # indeed your scrobbler commit is incorrect 02.22.18 # core_free(scrobbler_cache); 02.22.20 # scrobbler_cache = 0; 02.22.46 # yes 02.22.46 # well, no, it probably wont even crash 02.22.59 # which one? 02.23.13 # sorry, maybe not, viewing on webvcs is a bit hard 02.23.38 # even #define CORE_UNDEFINED_HANDLE 0 and using that would be ok 02.23.50 # actually no 02.24.36 # to keep it simple everywhere core_free() should return void, and 0 shuold be technically legal but never actually used 02.24.59 # how's that keeping it simple? 02.25.20 # you *always* check against <0 02.26.26 # most of the time I check ">0" actually. the return of alloc is "<0" 02.29.02 # " (0 is also not a valid handle)" is still confusing 02.29.27 # it sounds very clear to me 02.29.41 # of course it does, you wrote it 02.29.49 # there is a reason authors use editors 02.30.44 # "#define CORE_HANDLE_UNALLOCATED 0" to at least make it explicit then 02.31.04 # error < CORE_HANDLE_UNALLOCATED < legal handle 02.31.44 Join robin0800 [0] (~robin0800@genld-218-237.t-mobile.co.uk) 02.32.11 # Also, the first comment block in buflib.h talks about callbacks for when the data moves, but doesnt talk about how moving happens, or what causes it 02.32.41 # If I didnt know a yield could cause a move I'd almost certainly cause a crash on my first attempt to use buflib 02.34.32 Join kugel_ [0] (~kugel@rockbox/developer/kugel) 02.35.13 # because that's implementation details 02.35.13 # because that's implementation details 02.35.13 Quit Zarggg (Read error: Connection reset by peer) 02.35.14 Quit kugel (Read error: Connection reset by peer) 02.35.14 Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) 02.35.25 # it's mentioned that you need to re-get the pointer after yield() 02.35.40 # where is the user documentation for it? 02.35.53 # kugel: the param shouldn't be necessary for audio_fill_file_buffer. the only place it can be trashed is if playback was stopped or a remake message was received, which make it trash it itself 02.36.06 # JdGordon: at buflib_get_data() 02.37.14 # ok, so once again I ask, How does one go about loading a file into a handle pointer without worrying about it moving data on me? 02.38.01 Quit akaWolf (Ping timeout: 250 seconds) 02.38.03 # lock the buffer (return BUFLIB_CANNOT_MOVE in the move callback while within read()/write()) 02.38.10 # or use a temp buffer 02.38.37 # the voice pcm out buffer ought to use buflib instead of being handled in playback. is there any sort of "unmovable allocation" that won't hurt anything? 02.38.59 # jhMikeS: no 02.39.13 # unmoveable does hurt 02.39.29 # more than one of those even more so 02.40.02 # the comments in that file are really badly layed out. Don't take that as a personal offense or disregard it because its me saying it... 02.40.03 # not that it's required, voice_thread would just have to deal with it properly in that case 02.40.43 # * JdGordon still fails to see why there is no buflib_un/lock_handle() helper function 02.41.26 # * jhMikeS would have gone with "if obtaining a pointer from a handle, use it, then release it to make it movable" 02.42.23 # jhMikeS: you can do that.. 02.42.26 # actually yeah, that is probably better, always lock the handle in buf_get_data() and require and ungetter to pretty much guarentee it cant crash it 02.44.05 # you can implement a get&lock-use-release scheme just fine, it's done in many places 02.44.11 # I hacked that into buffer.c, sort of, with buf_pin_handle so that atomic codecs don't have to be scared of shrink ops 02.44.26 # it's not the default because it's desired to design the code so that locking isn't needed at all 02.44.35 # kugel_: sure, but why implement it half a dozen times when it can be done by the lib? 02.44.50 # then we'll never escape compulsive cooperative threading :\ 02.45.13 # we wont anyway 02.45.26 # bunk 02.46.36 # I've been pondering quite some time. some hotspots would need some reworking but it should be possible and definity better for an app to run directly on the os 02.46.46 Quit milk (Read error: Connection reset by peer) 02.47.01 # we don't need that 02.47.17 # we're not going to have apps that we don't have complete control over 02.47.23 *** Saving seen data "./dancer.seen" 02.47.45 # we never know 100% what code we are calling will yield or not 02.47.46 # I'm talking about running hosted 02.48.39 # JdGordon: I did it very pessimistic, I only did not lock for mem* and str* functions basically 02.48.39 # JdGordon: sometimes it changes, sometimes it varies with the target. 02.48.56 # kugel_: ? 02.49.23 # for all otehr functions I assumed "may yield now or later" 02.49.43 # implictly locking will also do absolutly nothing if there is no yielding 02.49.51 # so it is a simple clever safety mechanism 02.50.27 # it adds noise for releasing when locking wasn't needed in the first place 02.51.35 # * kugel_ also wants to note that he didn't design buflib that way, I just added other bits to it 02.51.56 # adding 1 line in the dozen places it is used is not unmanagele noise 02.52.17 # ok good, so you wont be offended if someone just does this change anyway then? 02.52.18 # I rather have a pair of lock()/unlock() rather than a get_data() and a forgotten release() 02.52.49 # it is exactly the same 02.52.52 # the former is the better pattern for this 02.53.18 # garbage collection! :) 02.53.23 # I object if you want to change this 02.53.26 # if you know for sure the code around your usage doesnt yield then the function is going to be small enough to not have buf_release() get in the way 02.53.37 # the implicit lock just helps your laziness 02.53.40 # if you *dont know for sure* you add 2 calls 02.54.14 # which is not even sure since locking isn't needed in many many cases 02.54.20 # well, you don't know for sure what will happen deep inside if you give up control to some other api but only when it's fairly simple and regulated 02.54.28 # exactly 02.54.37 # you really should be locking on every access 02.54.45 # s/you/callers/ 02.55.03 # what did I just say? "I only did not lock for mem* and str*" 02.55.30 # but actually half of the buffer uses are for just these 02.56.13 # kugel: you did catch my comment about the playback patch? 02.56.42 # jhMikeS: and did you catch that you can implement locking just fine, it's just that I object to the implicit lock? 02.56.45 # := 02.56.46 # :)* 02.56.56 # * jhMikeS slaps kugel 02.57.08 # yes, sir! 02.57.25 # jhMikeS: the one that the param isn't needed? 02.57.31 # yeah 02.57.53 # if it's trashed from anywhere else, it also crashing :) 02.58.15 Quit kadoban (Read error: Connection reset by peer) 02.58.34 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 02.58.40 # well, i was a) to lazy to analyze the other 3-4 callers, and b) the non-noalloc version makes a buflib_alloc call which shouldn't be done if it's alraedy allocated 02.59.33 # and the other way around it shouldn't be ommitted if it's not allocated yet 03.00.04 # since the other 3-4 callers worked with doing the alloc() call now, I assumed it's not alloced when they're called 03.00.16 # audio_play_start will alloc it, other callers call that only when already in operation 03.00.57 # spurious messages are properly rejected, since playback doesn't know what order they'll come in advance 03.01.10 # kugel_: Unhelpful originoally did buflib right? 03.01.29 # * Unhelpful runs the hell away ;) 03.01.53 # chicken! :) 03.02.03 # i did, what's the question? 03.02.19 # jhMikeS: not sure I understand that 03.02.39 # what your take on implictly locking the buffer in buf_get_data() for safety 03.03.20 # * kugel_ disagrees that the implicit lock adds safety 03.03.37 # you are just wrong 03.03.58 # kugel_: not sure it's imporant so much as, to go to anything but initialized, audio must be stopped. to start audio, it must be initialized, which audio takes care of just before needing the buffer 03.04.16 # nothing stops someone unknowingly causing a yield and trashing the pointer 03.04.21 # lock()/unlock() pair is far more readable, and with the implicit lock you can forget the release (even mroe since the the aquire isn't explicit) 03.04.57 # if it's trashed at any time during playback, well, that's a bug, one I'm pretty sure doesn't exist 03.05.01 # JdGordon: alright. enough discussed 03.05.05 # keeping in mind that when i designed this there was basically one thread that could be manipulating buffers? :P 03.05.09 # tired of your attitude really 03.05.48 # Unhelpful: indeed, but now its a free for all 03.05.49 # jhMikeS: trashed isn't the same as unallocated, is it? 03.07.03 # as far as playback is concerned, yes, someone else has been using that area for any purpose but playback 03.07.48 # what if someone did audio_get_buffer()? trashed but still allocated then 03.07.54 # what the heck it's still doing in audio_fill_file buffer, I should kick myself 03.08.20 # i think i have no idea how we ensure that somebody else doesn't fail a buffer because a buf_get_data locked things and compact can't run. :/ 03.08.51 # the other calls are purely dynamic rebuffering of tracks while playing 03.10.08 # Unhelpful: so the point is that if you dont need the lock doesnt affect anything, if you *do* yield then your pointer will be invalid when you come back 03.10.16 Quit robin0800 (Ping timeout: 264 seconds) 03.10.24 # allocations dont necesarrily fail when locked 03.11.04 # arg, "if you dont yield the lock doesnt ..." 03.11.26 # right. but if you don't yield you are needlessly blocking compaction... 03.11.57 # only if you get stuck in a loop 03.12.18 # but usages of the handle pointer should be short lived 03.13.08 # jhMikeS: so it should always call noalloc()? 03.14.01 Nick JesusFreak316_ is now known as JesusFreak316 (~JesusFrea@pool-173-65-77-65.tampfl.fios.verizon.net) 03.14.02 # it cannot call audio_reset_buffer() unconditionally, because it would then free/re-alloc the buffer within the shrink_callback 03.14.15 # (potentially) 03.14.59 Join robin0800 [0] (~robin0800@genld-217-237.t-mobile.co.uk) 03.14.59 # i guess i don't really see a big pressure in either direction - if locking is implicit, you *may* lock when you don't need to, and you have to worry about making sure you balance get/release. if locking is explicit, you never have a needless lock, but must remember to lock before yield (or re-get after), and to unlock anything that you lock. yes? 03.15.24 # yes 03.15.40 # with the point that locking when unnecesarily is less bad than not locking when it is required 03.15.54 # kugel_: just get the memory managment out of audio_fill_file_buffer altogether, move it to audio_start_playback just before that call 03.16.12 # * JdGordon would just add buf_get_and_lock(handle) 03.16.26 # then its not magically locking 03.17.01 # i guess i just don't see that as being as big a concern as having to be careful about your lock balancing, whether the locks are implicit or explicit. that will itself require more care than minding what you might call that could yield. 03.18.21 # I guess the idea is that you can control your own code much better than another's 03.19.44 # jhMikeS: you're saying the other callers don't need it? 03.20.04 Quit robin0800 (Ping timeout: 240 seconds) 03.20.30 # you're concerned about not being able to reasonably know what could yield? 03.20.38 # playback.c isn't my area of expertise 03.20.54 # Unhelpful: I think the possibility of using an invalid pointer outwieghs the "difficulty" of making sure you unlock correctly 03.21.22 # and I'm more concerned that buflib users will forget that reqwuirement 03.23.11 # jhMikeS: I'd be happy if you play with this more :) 03.23.33 # kugel_: the param? no; the buffer, by the design of the engine must exist already for everyone but audio_start_playback. logically, one can know that by the fact that stop must be done to lower it's status from initialized to something else 03.24.53 # any other caller must be called after playback is started, ergo, any other caller must have the buffer in hand 03.25.06 # I meant the memory management part in fill_file_buffer 03.25.33 # yeah, it should just get out of there 03.25.56 # if you moved it I'd feel a lot more easy 03.26.22 Join robin0800 [0] (~robin0800@149.254.60.168) 03.29.08 Quit TheLemonMan (Quit: WeeChat 0.3.5) 03.30.45 # what I had in mind: http://pastie.org/private/mcghwnpcmuwr4d9c3bnx5a 03.37.39 # hm, that's it? 03.37.51 # well, I trust you on that :) 03.40.31 # that should be it 03.41.53 Quit MethoS- (Read error: Connection reset by peer) 03.43.49 # * jhMikeS goes back to recall just why it was ever there, if the older revision could even sanely hint at such a thing 03.44.22 Quit robin0800 (Quit: Leaving) 03.45.05 # jhMikeS: as for when to realloc. it's pretty safe to realloc always, except from within that shrink_callback. 03.45.11 # when is it unsafe to not realloc? 03.45.54 # perhaps just ask if (audio_handle <= 0) realloc... else noalloc() 03.47.22 # now it's my responsibility? :) 03.48.31 Quit pamaury (Remote host closed the connection) 04.02.10 Quit amiconn (Disconnected by services) 04.02.11 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.02.23 Quit pixelma (Disconnected by services) 04.02.25 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.02.27 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.02.31 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.05.19 # arighty - http://pastie.org/private/bu4htdg5ti20zqt50pmqaw 04.06.52 Join robin0800 [0] (~robin0800@genld-224-239.t-mobile.co.uk) 04.11.34 # * jhMikeS is ever twitchy about voice knowledge still existing inside playback.c when it's really now in effect two playback engines 04.12.43 # two - between voice and audio that is 04.16.45 # btw, maybe radio or any other source should get a volume cut during voice playback. it's easier now since voice just pushes the hint, which wasn't the case before 04.22.34 # the old, old way of swapping codecs for voice just seems so surreal now ... :) 04.24.52 Quit robin0800 (Quit: Leaving) 04.28.22 Join robin0800 [0] (~robin0800@genld-219-248.t-mobile.co.uk) 04.32.41 Join Horscht [0] (~Horscht@p57B57130.dip.t-dialin.net) 04.32.41 Quit Horscht (Changing host) 04.32.41 Join Horscht [0] (~Horscht@xbmc/user/horscht) 04.33.08 Quit Horschti (Ping timeout: 258 seconds) 04.35.03 Quit saratoga (Quit: Page closed) 04.36.23 Quit TheSeven (Disconnected by services) 04.37.16 Join [7] [0] (~TheSeven@rockbox/developer/TheSeven) 04.47.27 *** Saving seen data "./dancer.seen" 04.55.52 Join tjb0607_ [0] (~quassel@208-100-128-206.bendbroadband.com) 04.56.34 Quit tjb0607 (Read error: Connection reset by peer) 04.59.37 Quit pixelma (Disconnected by services) 04.59.38 Quit amiconn (Disconnected by services) 04.59.39 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.59.40 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.59.42 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.59.59 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 05.04.34 Quit JesusFreak316 (Ping timeout: 252 seconds) 05.26.38 Quit Horscht (Quit: Verlassend) 05.39.45 Join Rob2222 [0] (~Miranda@p4FFF2A71.dip.t-dialin.net) 05.43.03 Quit Rob2223 (Ping timeout: 245 seconds) 05.48.53 Quit factor (Ping timeout: 245 seconds) 05.56.48 Quit jhMikeS (Ping timeout: 245 seconds) 06.02.01 Join factor [0] (~factor@74.197.205.204) 06.10.58 Join mr_boring [0] (4471cf4d@gateway/web/freenode/ip.68.113.207.77) 06.12.31 # my clip+'s database seems to need re-initializing much too often. can anyone help? 06.18.11 # rockbox's or the sansa one? 06.19.18 # rockbox :) 06.25.10 # ok, I dont really know the db well, it asks you to init each time you go into the db menu or something? 06.27.13 # almost. not quiet that predictable. often once it's already initialized properly, been played with, shut down and turned back on. 06.29.22 # sometime it hangs at "[total # of] files found," sometimes at "0 files found"... just tonight it worked correctly after much struggling, then once it was done i went browsing, and it still said "database is not ready." 06.29.24 Join kevin128 [0] (~kevin@69-12-206-218.dsl.dynamic.sonic.net) 06.29.57 # Hey, is it possible to have rockbox read a txt file to me via speech synth? 06.30.05 # not currently 06.30.29 # that would be an awesome feature. i wonder if someone could hack the Espeak synthesizer to work as a plugin 06.31.12 # i know Espeak is supposed to be very lax on the system requirements so it should be possible 06.31.16 # TTS in the core is something we want, we cant do it because the TTS we want to use is gplv3 and we dont want to do that 06.31.27 # it might even be espeak that was looked at 06.41.45 # It was espeak 06.42.20 Quit robin0800 (Quit: Leaving) 06.47.28 *** Saving seen data "./dancer.seen" 06.48.46 Quit Keripo1 (Ping timeout: 258 seconds) 06.51.15 Quit mr_boring (Quit: Page closed) 07.01.45 Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) 07.04.39 # Regarding espeak - I am interested in porting it. I have done some preliminary steps. There is port of an ancient espeak version as a plugin (still maintained outside of FS) but I would strongly prefer to port recent version with minimal changes to make our life easier later with sync. 07.05.21 # do i remember correctly that someone emailed the author asking to relicense to gplv2+? 07.05.22 # The problem with endianess seems to be matter of compile option + proper generation of dictionaries. 07.06.03 # JdGordon: yes and the answer was that he doesn't see the point of changing license 07.07.20 # The BIG drawback of straight port is the memory requirement. Espeak loads all helper data to ram which takes ~600kB. 07.07.53 # thats fine on most targets :) 07.08.14 # this will exclude the most popular sansas 07.08.25 # is it all actually required? 07.08.52 # can we do the same trick hwcodec does with voice and just load it from disk as needed? 07.09.07 # those targets are flash so disk access is fast enough 07.09.23 # From the first glance it's hard to tell. I was thinking of just what you said 07.09.41 # something like memmap() 07.10.32 # There are a few places which uses floating point calc (but this is a minor issue) 07.10.33 # but if the license is an issue why bother? 07.11.44 # JdGordon: We agreed at DevCon that we can accept v3 code BUT if there will be possibility to conditionally compile pure v2 binary. That means some HAVE_GPLV3 protect define or something 07.12.12 # with plugin that's fairly easy 07.12.22 # thats going to be fun to manage! 07.13.20 # I guess that enough v3 code which make us thinking about license change 07.13.35 # but this is far future if ever 07.17.00 Quit wodz (Quit: Leaving) 07.36.31 # JdGordon: Just for the record, I think mandatory code review is a good idea in an environment where people are really dedicated to making it work. 07.37.03 # My main concern (I wouldn't call it an objection) is that I don't feel our environment has enough people to do the review, and qualified to review certain parts of the code, and it'll just create a larger bottleneck. 07.37.15 # I don't think I communicated that as well as I'd have liked to. 07.39.57 Quit God_Eater (Ping timeout: 252 seconds) 07.53.52 Join God_Eater [0] (93722cc8@rockbox/staff/GodEater) 08.03.52 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 08.07.07 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 08.07.32 Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) 08.08.33 # kugel_: would you mind updating http://www.rockbox.org/wiki/AllocatingRAM (preferably with examples) 08.09.59 Quit powell14ski (Quit: powell14ski) 08.10.25 Join powell14ski [0] (~powell14s@c-174-51-194-6.hsd1.co.comcast.net) 08.10.40 # eghm, *could you update 08.17.58 Join B4gder [0] (~daniel@www.haxx.se) 08.17.58 Quit B4gder (Changing host) 08.17.58 Join B4gder [241] (~daniel@rockbox/developer/bagder) 08.19.09 Join LinusN [0] (~linus@giant.haxx.se) 08.19.54 Join Scr0mple [0] (~Simon@115-64-195-104.static.tpgi.com.au) 08.23.39 # New commit by 03buschel (r30471): MIPS uses GCC 4.1.2 which was wrongly detected as supporting '-fgnu89-inline'. Now only set this parameter if GCCNUM > 401. 08.23.55 Join Buschel [0] (~chatzilla@p54A3A9A3.dip.t-dialin.net) 08.24.02 Quit Scromple (Ping timeout: 260 seconds) 08.27.07 # r30471 build result: 92 errors, 0 warnings (buschel committed) 08.27.27 # Buschel: sorry, that's my fault 08.27.32 # I'll rerun the build 08.28.21 # yesterday CIA said my commit was fine even though it was not, I hope now it doing the opposite :) 08.28.50 # when speaking about mips - there is patch rotting on tracker about impossible asm constraint with newer gas/gcc 08.28.53 # yesterday was a database bug. today I added a bad build client. 08.30.24 # r30471 build result: All green 08.31.53 Join nick-p [0] (~nick@82-69-105-120.dsl.in-addr.zen.co.uk) 08.32.07 # gotta go to work now 08.32.10 Quit Buschel (Quit: ChatZilla 0.9.87 [Firefox 6.0.2/20110902133214]) 08.32.59 Join ender` [0] (~ender@foo.eternallybored.org) 08.36.02 Quit powell14ski (Quit: powell14ski) 08.47.32 *** Saving seen data "./dancer.seen" 08.59.43 # r30471 build result: All green 09.07.49 Join Scromple_ [0] (~Simon@115-64-195-104.static.tpgi.com.au) 09.08.22 Quit Scromple_ (Client Quit) 09.10.35 Quit Scr0mple (Ping timeout: 252 seconds) 09.34.51 Quit wodz (Quit: Leaving) 09.54.51 Quit God_Eater (Quit: Page closed) 09.56.21 Join God_Eater [0] (93722cd1@rockbox/staff/GodEater) 10.08.04 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 10.09.09 Join evilnick_ [0] (~evilnick@5ad33e3b.bb.sky.com) 10.09.09 Quit evilnick (Read error: Connection reset by peer) 10.11.54 Quit evilnick_ (Read error: Connection reset by peer) 10.32.20 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 10.36.22 # using buflib for background images in the skins is going to be *interesting* 10.36.54 # every time the buffer moves it will require a lcd_set_backdrop() :/ 10.37.16 # Sounds like something that wants to lock the buffer then 10.38.22 # Of course the buffer may move seldom enough for this not to be a major issue 10.39.24 # this is something which absolutly shldnt lock the buffer :) 10.39.39 # the allocated size is pretty large and could cause big fragmentation 10.40.03 # actually, after typing that second line I dont tihnk it wil be so problematic 10.40.36 # each handle is indivdually "locked" right? 10.41.04 # kugel_, bluebroth3r: When building mingw32-sdl as per wiki instructions, it isn't prefixed. You don't need to change path either; 'configure' figures out which 'sdl-config' is the correct one from 'sdl-config --libs' output 10.41.57 Quit mudd1 (Read error: Operation timed out) 10.42.21 # The mingw32 one has '-mwindows' while the native one does not. 10.43.40 # err... how the heck do I go about adding a new block to a handle? 10.43.53 # * JdGordon is very scared by union buflib_data 10.44.38 # "adding a new block"? 10.45.50 # Actually, I suspect we want one or two more callbacks. The current move callback is called *before* moving, which means you can't do things like call lcd_set_backdrop() from it 10.46.24 # I'm going to do regular images first which is easy 10.46.26 # Zagor: ping 10.46.33 # amiconn: pong 10.46.52 # And moving that call to *after* the move will make it impossible to deny moving from it, which also isn't too good 10.47.10 # * gevaerts decides that kugel's input is needed here 10.47.12 # but I think this locking mechanism is way overkill for most users, I want to add a simple bool to the handle for locked and then buf_get_and_lock(handle) and buf_unlock(handle) to make that work and ignore the callbacks 10.47.35 *** Saving seen data "./dancer.seen" 10.47.43 # [15:52:06] B4gder: Where in svn can I find the build colouring script? And if it's not in svn atm, could you add it there? 10.47.43 # [15:52:32] It needs fixing... 10.47.54 # Zagor^ 10.51.28 Nick kugel_ is now known as kugel (~kugel@rockbox/developer/kugel) 10.51.52 # you can do lcd_set_backdrop() from the callback 10.52.10 # it only sets the pointer, and doesnt draw from it 10.52.17 # why oh why are the block numbers not coming from an enum? :'( 10.52.20 # JdGordon: go add this thing, I'll still object 10.52.27 # good for you 10.52.43 # I suggest you go reading logs where I considered adding lock mechanism into buflib and discussed it with gevaerts 10.53.01 # it's not like you're the first one with this idea 10.53.13 # did I say i thought that? 10.53.21 # I think you'll find I was in that conversation also 10.53.39 # amiconn: http://svn.rockbox.org/viewvc.cgi/www/buildserver/showbuilds.pl?view=log 10.53.47 # there was another one where you were absent, IIRC 10.54.44 # * JdGordon waiats a link 10.54.46 # awaits* 10.55.38 # unless someone else wants to go to the efffort of mpving the 400K skin buffer acrosss? 10.56.07 # you want to make it unmoveable entirely? 10.56.26 # no 10.57.03 # Zagor: That one does the build table; I'm looking for the script that's colouring the individual build logs 10.57.10 # oh 10.58.03 # kugel: right, and there shouldn't be a yield between the callback and the actual move I guess, so things are indeed fine, at least for this case 10.58.36 # JdGordon: I explicitely decided against making having locking in buflib (it's not meant to provide that since it wants things moveable). I would prefer if you respect this decision 10.58.48 # or rather, gevaerts and I did 10.59.57 # its alot easier to argue against a wrong descision than a right one.... 11.00.22 # it's right in my book 11.01.27 # New commit by 03zagor (r30472): Added build log viewer to svn. 11.01.57 # amiconn: http://svn.rockbox.org/viewvc.cgi/www/buildserver/shownewlog.cgi?view=log 11.02.20 # I'm not convincesd, and i cant find the logs 11.03.24 # I also don't want multiple ways of locking, but a single one 11.03.51 # buflib isnt your baby 11.04.30 Quit kevin128 (Quit: Leaving.) 11.04.54 # Can we evaluate the current system the way it stands, and discuss changes if and when it *actually* appears that the current API has problems? 11.06.28 # I have issues wth it right now. Instead of a simple function call I have to implement the whole callback system and then keep track of wheather its ok to move or not now 11.06.53 # you always need to keep track 11.07.04 # not to mention the overhead of the callbacks being called and the binsize that would incur 11.07.24 # and yes, you need to implement callbacks (that's even a wanted hurdle) because not requiring locks at all is the default 11.07.50 # psudeo code for what i want: { alloc_buffer(); lock_buffer(); load_bmp(get_buf_data()); unlock;} 11.07.59 # 5 lines which you're turning into 3 functions 11.08.13 # not requireing locks means someone is not going to lock it when it needs to be 11.08.33 # you can implement it that way in your .c file 11.08.44 # just don't make it into buflib 11.09.34 # implicit locking means someone is not going to release the lock, making the whole buflib effort useless 11.09.34 # dinner time 11.09.50 # how is get_data_and_lock() implicit? 11.13.16 # have you written any working code by now? or are you complaining without having even used the api? 11.14.27 Join thomasjfox [0] (~tomj@rockbox/developer/thomasjfox) 11.15.27 Join petur [0] (~petur@rockbox/developer/petur) 11.18.05 Quit God_Eater (Quit: Page closed) 11.23.00 Quit thomasjfox (Remote host closed the connection) 11.25.29 Join casainho [0] (~chatzilla@pal-213-228-181-14.netvisao.pt) 11.25.55 # New commit by 03zagor (r30473): Sanitize parameters. 11.38.43 # Zagor: can you look at r30153? that commit was reverted later but the issue is still there 11.39.50 Quit petur (Read error: Connection reset by peer) 11.57.28 Quit casainho (Remote host closed the connection) 11.58.13 Join casainho [0] (~chatzilla@pal-213-228-181-14.netvisao.pt) 12.00.13 # gevaerts: out of curiosity, have you had a play with your skin list idea yet? 12.01.06 # JdGordon: not yet. I've been a lot busier than expected these last two days 12.04.49 # ok 12.06.02 Join God_Eater [0] (93722cc8@rockbox/staff/GodEater) 12.06.43 # does this new sking thingy make it possible to replace all lists? 12.07.05 # is it guarenteed nothing will yield between getting the move callback and the move completing? 12.07.15 # n1s: all except multi-line-selector lists 12.07.39 # JdGordon: aha 12.07.55 # JdGordon: it's like that in the current implementation, and I'm pretty sure breaking that will cause a *lot* of pain, so I'd say yes 12.08.00 # actually, I'm not even sure if I left that check in the code or not, so it might work 12.09.10 # gevaerts: it would be nice if that guarentee was in the existing code so it doesnt change by someone later 12.09.35 # true 12.09.58 # JdGordon: is the selector bar customizable as well? 12.11.20 # n1s: with a bit of skin trickery you can do pretty much whatever you want. each item draws all the viewports with a specified label 12.11.25 # so images, colouring, whatever 12.11.39 # the skin engine needs some drawing primatives to make it better though 12.11.48 # i.e draw rect, line, etc 12.12.17 # cool, so i could draw a custom image as a selector? 12.12.43 # sure 12.15.07 Join TheLemonMan [0] (~LemonBoy@ppp-153-16.26-151.libero.it) 12.20.14 Join chu [0] (~ma@115.74.72.185) 12.20.17 # Hi 12.20.24 # I have a gigabeatS 12.20.36 # when I run drictly from AC adapter 12.20.52 # the rockbox report the volage 2.4V 12.21.50 # I measure the voltage output from the adpater is 5.35V 12.22.16 # so I wonder if that is a problem with my player 12.22.43 # or do rockbox report inaccurate ? 12.23.07 # rockbox reports the *battery* voltage - not the voltage being supplied by the power adaptor. 12.23.15 # ah 12.23.27 # JdGordon: sure (although not written explicitely) 12.23.45 # kugel: is there a helper macro to move a cached pointer? 12.24.56 # no, not yet, but tagtree.c has one 12.25.37 # seems filetypes.c also has one... not yet means its coming? 12.25.46 # * JdGordon realised thugh he can use new directly here though 12.25.53 # someone could ad it 12.35.49 Join user890104 [0] (~Venci@89.252.237.109) 12.38.26 # * JdGordon wonders what the val in the buflib debug menu means 12.39.56 # the same the val member of union buflib_data means. number of union buflib_data to skip past the end of the allocation 12.40.09 # so it relates to the size 12.41.04 # it would be "nice" if selecting the handle would give a full description of the handle 12.41.35 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.41.51 # does http://pastebin.com/ExZV9ibh look correct? 12.42.48 Quit God_Eater (Ping timeout: 252 seconds) 12.42.52 # oh poo... [saint] how would you like a tag to change the background image dynamically in skins? 12.43.28 # hmm, core_* really shold just use malloc for hosted targets 12.43.43 # seen as using the 8mb audio buffer is a waste for them 12.45.12 # cool! adding in the core_free() call in that patch killed it :) 12.46.28 Quit chu () 12.47.38 *** Saving seen data "./dancer.seen" 12.52.40 Join soap__ [0] (~soap@66.178.206.246) 12.52.46 Quit soap__ (Client Quit) 12.53.13 Join Jerom1 [0] (~jerome@2a02:8420:216:a800:f66d:4ff:fe45:790f) 12.55.39 Join God_Eater [0] (93722cd0@rockbox/staff/GodEater) 12.55.54 # * JdGordon just loves memory leaks :) 12.56.38 Quit soap (Ping timeout: 264 seconds) 12.59.27 # * JdGordon thinks there may be a serious mem leak in skin backdrops in svn 13.00.43 # hmm, actually no, its safe, only because of the terrible buffer managemnt there already 13.00.45 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 13.00.50 # causing mem leaks moving to buflib though :/ 13.02.39 Quit Jerom1 (Quit: Leaving.) 13.02.53 # kugel: updated now. web site commits needs to be manually pulled by a swede. 13.03.29 # New commit by 03zagor (r30474): Rename $gecko to $push and increase block to later firefox versions. 13.07.41 Quit nick-p (Quit: Leaving) 13.08.30 # kugel: I'm getting a crash in buflib_get_data() with handle==13 13.09.27 # well, that's not nice 13.13.56 # kugel: http://pastebin.com/GbVQuFUG see anything obvious? 13.14.23 # it all loads fine the first time, reloading a theme crashes it 13.16.37 # If I have a patch regarding logf.{c,h}, what category would I file that under? 13.16.53 # JdGordon: I don't see anything obviously wrong 13.16.58 Quit wodz (Read error: Operation timed out) 13.17.04 # haha oops 13.18.22 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 13.18.41 # you don't need to init handles with -1, just leave them 0 and check for >0 everywhere else 13.20.53 # Lalufu: i'd say operating system 13.22.25 # n1s: thanks 13.24.32 # New commit by 03jdgordon (r30475): Use buflib for the skin backdrop images potentially allowing multiple images per skin in the future 13.26.36 # JdGordon: do you want to make each skin object buflib aware? 13.26.37 Join evilnick_ [0] (~evilnick@92.40.254.205.threembb.co.uk) 13.27.07 # r30475 build result: 225 errors, 1 warnings (jdgordon committed) 13.27.37 # kugel: no, no need, only the big items, i.e images 13.27.54 # way too many pointers to make it worth the effort 13.28.10 # oh FFS 13.28.21 Quit evilnick (Read error: Operation timed out) 13.28.43 # deltas are pretty nice :p 13.29.00 # the skin ram usage info doesn't include backdrops now does it? 13.29.28 # not anymore it doesnt 13.29.34 # it did before that commit 13.31.16 Quit evilnick_ (Ping timeout: 252 seconds) 13.34.09 # New commit by 03jdgordon (r30476): fix checkwps 13.35.45 # JdGordon: why don't you add the missing bits to checkwps? 13.35.46 Join jordan` [0] (~gromit@2001:660:3302:2826:225:90ff:fe20:d9a8) 13.35.58 # with each #ifdef checkwps gets more useless 13.36.10 # and the code uglier 13.36.24 Quit kadoban (Ping timeout: 252 seconds) 13.36.39 # r30476 build result: All green 13.37.43 # the first statement is nonesense 13.38.29 # it's not 13.39.08 # checkwps is only to check the language parses 13.39.10 # in r30463 checkwps doesn't parse some stuff anymore 13.39.12 # so yes, it is incorrect 13.40.54 # there are other ifdef like this in parsing 13.41.50 # go ahead and fix them if they annoy you 13.42.01 # you'll quickly realise there is a danm good reason for them 13.42.16 # I *wont* have a hissy fit if you do that 13.42.42 # I just asked you about the reason for that 13.43.57 # maybe its different for german, but in english questions usuually end with a ? 13.45.07 # "13:36 < kugel> JdGordon: why don't you add the missing bits to checkwps?" 13.46.04 # sorry, I didnt see that line :/ 13.46.19 # because they are unecessary, the parserlib does it 13.47.12 # but the other parser can reject tags outside the parserlib? 13.47.24 # yes 13.47.42 # that particular !checkwps block doesnt rejct anything 13.47.54 # and the others are for when it is impossible for checkwps to know 13.48.54 # okay 13.49.57 # but I still think r30476 could have added buflib to checkwps to avoid #ifdef 13.50.40 # if you want to do it go for it, I think that is completly pointless though 13.51.54 # once I move image loading into buflib I wonder what a sensible size for the remaining required buffer is 13.52.02 # it doesnt really make sense to base it on the screen size 13.55.20 # the screen size might still make sense (as in, a larger screen can fit more info, and this more LOCs in the .wps), but rather loosely 13.58.29 # each tag is something like 12 bytes+param data... I think 2K is probably more than enough 13.58.39 # maybe 4K 14.03.46 Quit user890104 () 14.05.40 Join nick-p [0] (~nick@82-69-105-120.dsl.in-addr.zen.co.uk) 14.10.28 Join user890104-freen [0] (~user89010@2a01:4f8:101:2a4:0:bc28:b2e1:9) 14.10.47 Nick user890104-freen is now known as user890104 (~user89010@2a01:4f8:101:2a4:0:bc28:b2e1:9) 14.11.04 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 14.18.58 Join WalkGood [0] (~WalkGood@unaffiliated/walkgood) 14.19.56 # e00-sim with cabbie loaded is now 28KB/241KB :) 14.20.00 # e200-sim* 14.20.07 # still seems too high 14.21.07 # ah, the font 14.21.17 # hmm. thats going to be tricky to move :/ 14.22.22 # cabbie loads an additional font? 14.23.17 Quit user890104 (Quit: .) 14.23.38 Join user890104 [0] (~Venci@2a01:4f8:101:2a4:0:bc28:b2e1:9) 14.24.15 # dont think so 14.24.23 # but still, nfi how to put the font in buflib 14.24.49 # got the buffer down to 94K on e200 from the origional 400 or so which i tihnk is a good days work 14.28.08 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 14.37.12 Quit jhMikeS (Read error: Connection reset by peer) 14.38.15 # New commit by 03jdgordon (r30477): make some stuff static 14.38.23 # New commit by 03jdgordon (r30478): Use buflib for skin images. Allows much more images to be loaded 14.39.08 # ^ annoyingly simple... doesnt mean having to implement the lock mechanism myself isnt a bad thing 14.40.03 Join jhMikeS [0] (~jethead71@c-68-61-166-99.hsd1.mi.comcast.net) 14.40.03 Quit jhMikeS (Changing host) 14.40.03 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 14.41.02 # r30477 build result: All green 14.41.41 # that commit is going to crew android which used to use malloc for all those images 14.43.25 # r30478 build result: All green 14.43.39 Quit casainho (Ping timeout: 276 seconds) 14.44.35 # New commit by 03nls (r30479): FS#12257 by Michael Goerner, fixing stone colours in goban for inversed displays (clips and mrobe100). 14.45.31 Quit B4gder (Quit: Konversation terminated!) 14.46.35 # amiconn: any thoughts on if it would be possible to use buflib with fonts? or because of its current implementation its just Too Damn Hard with all the pointers? 14.47.01 # that would free up a heap f statically allocated ram which is often unused 14.47.19 # r30479 build result: All green 14.47.40 *** Saving seen data "./dancer.seen" 14.47.46 # are there actually many pointers when the whole font is loaded? 14.48.07 # the font cache is complicated, but if we used buflib we could, in many cases, just allocate a buffer big enough to load without the cache being used. 14.48.35 # what about unifont? 14.48.50 # depends how much ram you have :) 14.48.54 # actually im not sure if the cache even uses pointers 14.49.13 # It has some kind of header bit that has at least some addresses in it 14.49.18 # but most of the cache is just an array, yes 14.49.25 Quit wodz (Read error: Operation timed out) 14.49.27 # (iirc) 14.49.52 # if there are only a few pointers which need updating it wont be a problem to move 14.50.20 # kugel: any plans for a plugin to visualise the buffers state with all the current allocs? 14.51.10 # visualize how? 14.51.47 # a literal map of the allocations... |||empty||....| 14.52.21 # i hope the allocation algorithm is correct :) I've just double the normal alocations 14.52.36 # the debug menu doesnt do that? 14.53.22 # the debug menu is truly useless.... maybe if val had a meaning it would be better but just an address and a name isnt very useful 14.53.38 # val relates to the size, as I said 14.53.47 # essentially, multiply it by 4 14.53.50 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 14.54.03 # it is a map of the buflib buffer 14.59.54 Join zerly [0] (~91f8c301@www.haxx.se) 15.01.05 Quit wodz (Quit: Leaving) 15.04.04 Quit zerly (Client Quit) 15.07.48 # JdGordon: did you try changing themes during playback also? 15.08.16 # does it work? 15.08.23 # dont know 15.08.42 # I mean it should, but I didn't try 15.08.48 Quit EvanCarroll (*.net *.split) 15.08.49 Quit scorche|sh (*.net *.split) 15.08.49 Quit crwl (*.net *.split) 15.08.50 Quit rasher (*.net *.split) 15.08.50 Quit preglow (*.net *.split) 15.08.50 Quit feisar-_ (*.net *.split) 15.08.50 Quit merbanan (*.net *.split) 15.08.50 Quit Xerion (*.net *.split) 15.08.50 Quit user829385 (*.net *.split) 15.08.50 Quit Zagor (*.net *.split) 15.08.51 Quit Torne (*.net *.split) 15.08.52 Quit ruskie (*.net *.split) 15.08.52 Quit aevin (*.net *.split) 15.08.52 Quit otih (*.net *.split) 15.08.52 Quit Guest33080 (*.net *.split) 15.08.53 Quit [fred] (*.net *.split) 15.08.54 Join preglow [0] (thomj@tvilling2.pvv.ntnu.no) 15.08.54 Join feisar- [0] (jljhook@ihq.in) 15.08.58 Join aevin [0] (eivindsy@unaffiliated/aevin) 15.08.58 Join scorche|sh [0] (~scorche@squisch.net) 15.09.07 Join Torne [0] (~torne@lil.wolfpuppy.org.uk) 15.09.08 Quit Torne (Changing host) 15.09.08 Join Torne [0] (~torne@rockbox/developer/Torne) 15.09.13 Join EvanCarroll [0] (~ecarroll@64.200.109.13) 15.09.15 # if it doesnt its either because i messed up the locks or buflib doesnt work correctly 15.09.18 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 15.09.19 Join merbanan [0] (~banan@c-62-220-165-114.cust.bredband2.com) 15.09.22 Join Xerion [0] (~xerion@5419A766.cm-5-2c.dynamic.ziggo.nl) 15.09.33 Join crwl [0] (~crwlll@dsl-jklbrasgw1-ffb9c300-103.dhcp.inet.fi) 15.09.34 Join ack [0] (~ack@88.191.116.126) 15.09.42 Join user829385 [0] (~aoeu@112.166.15.141) 15.10.01 Nick ack is now known as Guest35783 (~ack@88.191.116.126) 15.10.04 Join otih [0] (~otih@0x01.f2tec.de) 15.10.04 Quit otih (Changing host) 15.10.04 Join otih [0] (~otih@CAcert/Assurer/otih) 15.10.55 # kugel: commit what all the hub-bub was about last night for playback.c? 15.11.57 # jhMikeS: you think it's fine that way, yes? 15.12.39 # the final version should work. I'm going to build it and actually run it through a few check though (which is happening now) 15.21.14 Join [fred] [0] (fred@ircop.efnet.at) 15.29.02 Join rasher [0] (~rasher@rockbox/developer/rasher) 15.30.46 Join JesusFreak316 [0] (~JesusFrea@131.247.39.75) 15.35.04 # it's being - interesting. it doesn't resume properly if restarted from shrink_callback but instead restarts from the beginning of the track. it does work for cuesheet and crossfade 15.39.40 Quit krazykit (Remote host closed the connection) 15.39.47 Join krazykit [0] (~quassel@li135-248.members.linode.com) 15.42.06 # is core_shrink() used anywhere? 15.42.11 Join y4n [0] (y4n@unaffiliated/y4ndexx) 15.42.24 # would bad things happen if that always returns false? 15.43.35 # it's called in playback.c 15.46.56 # http://pastebin.com/ZDWkWFAr is my patch to make APPLICATION builds use host malloc for everything except playback.. unfortunately it panifc()'s playback and backdrop images dont load... 15.46.58 # * jhMikeS isn't sure how core_shrink could work safely if playback is still going 15.47.03 # a second set of eyes would be nice 15.47.17 # jhMikeS: it resumes from the start if it's called repeatedly 15.47.34 # I tried with enabling scrobbler and timestretch 15.48.01 # works fine with scrobbler (1 alloc), but starts from the beginning for timestretch (4 subsequent allocs) 15.48.02 # the codec probably isn't finished 15.48.24 # JdGordon: no, nothing bad 15.48.44 # core_shrink is all or nothing. if it returns false then everythign is as before 15.48.56 # ok 15.49.06 # it's most prominently used in the shrink_callback in playback.c, but also for tagtree 15.49.47 # is the comment unclear about it? 15.49.58 # looks like it depends on the target then, which means it needs to not lose the offset if the codec hasn't completed starting by the next restart 15.50.36 Join ruskie [0] (ruskie@sourcemage/mage/ruskie) 15.50.43 # jhMikeS: this is also observable in svn with teh plain stop/start calls 15.51.35 # you're saying resume is being dodgey? 15.52.33 Join MethoS- [0] (~clemens@134.102.106.250) 15.56.25 # jhMikeS: yea 15.57.03 # jhMikeS: if the stop/start pair is too frequently it'll "resume" from the beginning 15.58.29 # not surprising, and I'm not sure what to do about it. the codec gets around to updating things whenever it does and it may never get around to it between calls 15.59.44 # because the codec thread doesn't run? 16.00.01 # hmm, ok, after playback does core_alloc_maximum() how do the following allocs work? 16.00.36 # buflib asks playback to get rid of some by calling teh shrink callback 16.00.45 # kugel: or not enough to get back into a decoding loop 16.01.01 # if there's not enough free space gained by compaction, that is 16.01.40 # jhMikeS: can stop block until resume info is ready? 16.03.14 # anyway, it's only a minor annoyance if you ask me 16.03.15 # it might never be ready depending upon what transpires 16.03.31 # it's clunky though 16.03.56 # my debug output makes no sense... I can see the shrink happening untill the 16th alloc and because it is not happening it fails 16.03.57 # and not what's intended 16.04.01 # perhaps re-use the previous resume info? 16.04.11 # is 16 a magic number? or a fluke? 16.04.47 # magic numbers shouldn't be involved 16.05.03 # it's there, in playing_id3, at least initially, then gets clobbered after the first restart 16.06.26 Join stoffel [0] (~quassel@p57B4BB59.dip.t-dialin.net) 16.06.45 # whats the playbacks buffer callback function name? 16.06.51 # once control is given to the codec, the codec master of elapsed and offset 16.06.57 # *is 16.08.15 # what the heck? it just stops calling the shrink callback :/ 16.09.04 # perhaps because the alloc succeds without it? 16.09.12 # no, it fails 16.09.41 # and this is with size=4 16.09.54 # size=4? 16.10.13 # what do you need such a tiny alloc for? 16.10.26 # http://pastebin.com/G4JMvu8q the log of the run 16.10.47 Quit JesusFreak316 (Ping timeout: 260 seconds) 16.10.51 # see the pastebin before, use host malloc on app builds 16.12.24 # can we post-pone this work until things are settled with buflib? 16.12.36 Quit antil33t (Read error: Connection reset by peer) 16.12.55 Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz) 16.13.08 # I use RaaA exclusively these days so I basically only test through this, and don't want a separate code path now already 16.13.33 # its not being commited yet 16.13.38 # just saying 16.14.07 # but, fwiw, I'd just implement the buflib api with a malloc backend instead of what that diff is doing 16.15.13 # * jhMikeS would like the id3 to stop being used directly for positioning and instead use a function call to ask for the position 16.17.02 # kugel: well, doing it in core_* means it keeps buflib.c completly clean 16.17.43 # I have a buflib-with-malloc.c in my mind 16.18.25 # and since you can call buflib directly (e.g. in plugins) it makes more sense to back buflib with malloc instead of core_* IMO 16.18.30 # kugel: fine, if nothing's gotten worse, commit that stuff, or I will and I'll think about what makes sense in regard to hardening the resume information against rapid starts and stops 16.18.36 # i might give up anyway... no way im going to dive into buflib.c to figure out why it isnt working 16.19.03 # kugelhoq would you do alloc_maximum() though? 16.19.32 # malloc(MEMORYSIZE) 16.20.30 # or the size the context was initialized with 16.21.25 # wont that leave an 8MB buffer not being used at all? 16.21.44 # err, where buffer_alloc() ends 16.22.15 # what do you mean? 16.22.35 # the static buffer[MEMORYSIZE] would be removed 16.22.42 Join JesusFreak316 [0] (~JesusFrea@2607:fe50:0:8100:4dd6:5391:f627:d523) 16.24.54 Join JesusFreak316_ [0] (~JesusFrea@2607:fe50:0:8100:4dd6:5391:f627:d523) 16.26.49 Quit JesusFreak316_ (Client Quit) 16.27.19 Join JesusFreak316_ [0] (~JesusFrea@2607:fe50:0:8100:4dd6:5391:f627:d523) 16.27.40 Quit JesusFreak316 (Ping timeout: 264 seconds) 16.27.42 Nick JesusFreak316_ is now known as JesusFreak316 (~JesusFrea@2607:fe50:0:8100:4dd6:5391:f627:d523) 16.29.17 # I'm not completly sure buflib is actually working 16.30.00 # well, it shouldn't fail to shrink after the 15th alloc 16.30.06 # I'll have a look 16.30.23 # im looking into fs#12265 16.30.24 # http://www.rockbox.org/tracker/task/12265 3Sansa Clip+ cannot display cabbiev2 wps at r30478 (bugs, unconfirmed) 16.31.28 # New commit by 03kugel (r30480): Buflib/swcodec: Improve playback stopping behavior on allocation. ... 16.31.57 # what does Buffer: in rockbox info point to now days? 16.32.45 # the audiobuf if allocated, the what's available in buflib otherwise 16.32.58 # what audio_buffer_available() returns, specifically 16.34.05 # r30480 build result: All green 16.36.32 # core_allo_ex() is only being called once as expetced for each of my handles, yet they are appearing quite a few times in the debug menu 16.36.57 # in svn or with that diff? 16.37.05 # svn 16.37.49 # how does the buffer shrink work if playback is still using the buffer? 16.37.52 # New commit by 03kugel (r30481): Make genlang faster by doing better regexes. ... 16.38.30 # hm, that Torne's work, git-svn dropped the author of course :( 16.38.57 # jhMikeS: ? 16.39.43 # our patch was about exactly that 16.39.52 # Wait, I thought that got committed ages ago :0 16.40.16 # kugel: it calls core_shrink then restarts playback 16.40.23 # yes 16.40.24 # r30481 build result: All green 16.40.56 # gevaerts: I think re-running the build scores is in order 16.41.12 # kugel: it can't change anything there as far, not safely 16.41.26 # *as far as overwriting playback's data 16.41.36 # what? 16.41.41 # kugel: I'll try to remember doing that in the weekend. That's several hours of hot laptop :) 16.42.04 # kugel: i had an idea for how to do that even faster but haven't gotten around to trying it yet. it may not actually be faster. 16.42.05 # kugel: is there any chance something would be able to overwrite the audio buffer there? 16.42.57 # kugel: profiling genlang properly turned out to be annoying and i got bored of messing with perl 16.42.57 # jhMikeS: you said it's safe :) 16.43.13 # jhMikeS: it should use the new buffer when audio_start_playback() returns, no? 16.43.32 # Torne: the profiling I did was quite convinient 16.43.42 # kugel: The profiling I did *looked* convenient 16.43.50 # but i found it was extremely unstable 16.44.00 # and with miniscule almost-noop changes to the source, it would radically change the profile 16.44.09 # er, not "and" there. 16.44.45 # kugel: within the fill_file_buffer it is, that part 16.45.39 # the restart will task switch unless on the audio thread 16.45.51 # yes 16.46.12 # not sure what you mean 16.46.37 # kugel: can you grab svn and run the clip+ sim in gdb and watch it crash? it crahses on core_free() on a valid handle 16.46.48 # can do 16.46.54 # there are enough yield points inside the audio thread that, well, I don't know what it's doing at the time 16.47.03 # 5 16.47.10 # s/5// 16.47.35 # the shrink_callback() is called on the thread that does the alloc 16.47.42 *** Saving seen data "./dancer.seen" 16.48.11 # kugel: skin_parser.c:1495 is where it gets interesting 16.48.26 # plus, core_alloc() can't return before the shrink_callback returned 16.48.34 # the first few images allocate fine, then one doesnt allocate and the core_free() for the valid ones all crash 16.48.37 # is the alloc always at the end? 16.48.38 # so the new alloc shouldn't be able to overwrite audio buffer 16.51.16 # what if reset_buffer is called while another thread is waiting inside shrink_callback? 16.52.01 Join JesusFreak316_ [0] (~JesusFrea@2607:fe50:0:8100:4dd6:5391:f627:d523) 16.53.29 # New commit by 03kugel (r30482): Exit of SDL_WaitEvent() returns an error. ... 16.53.39 # that annoyed me long enough 16.54.25 Quit JesusFreak316 (Ping timeout: 260 seconds) 16.55.40 # read_bmp_fd() returns tiny sizes for me 16.55.45 # 50 bytes, etc 16.56.00 # very small images 16.56.00 # r30482 build result: All green 16.56.18 # core_free() shouldnt be crashing though 16.56.19 Quit JesusFreak316_ (Read error: Connection reset by peer) 16.56.29 # it looks like something is trashing buflib 16.57.39 Join JesusFreak316 [0] (~JesusFrea@2607:fe50:0:8100:4dd6:5391:f627:d523) 16.59.21 Quit nick-p (Quit: Leaving) 16.59.22 # hmm, the shrink callback is called more than once for the allocs? 16.59.48 # who are oyu asking?! 17.00.26 # nobody :) 17.00.44 # * JdGordon mutters something about missing unit tests 17.00.54 # ah 17.01.01 # there is indeed a magic number involved 17.01.30 # * JdGordon cries a little 17.02.02 # buflib_available() reserves space for 16 future handles 17.02.45 # I that's what BUFLIB_SHRINK_POS_BACK is about, if there's not enough room to store the handles (the integer) 17.03.49 # 16 byutes for the name? thats a bit wrong 17.04.12 Quit otih (Excess Flood) 17.04.12 Quit amiconn (Excess Flood) 17.04.14 Quit Unhelpful (Excess Flood) 17.04.19 Join amiconn [0] (quassel@rockbox/developer/amiconn) 17.04.20 Quit niekie (Excess Flood) 17.04.24 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 17.04.39 Quit amiconn (Excess Flood) 17.04.51 Join amiconn [0] (quassel@rockbox/developer/amiconn) 17.05.07 Quit balintx (Excess Flood) 17.05.10 Quit amiconn (Excess Flood) 17.05.16 Join otih [0] (~otih@0x01.f2tec.de) 17.05.16 Quit otih (Changing host) 17.05.16 Join otih [0] (~otih@CAcert/Assurer/otih) 17.05.17 Join amiconn [0] (quassel@rockbox/developer/amiconn) 17.05.25 # I need to go, will look later 17.05.26 Quit Unhelpful (Excess Flood) 17.05.26 Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) 17.05.28 Quit [7] (Excess Flood) 17.05.34 Quit otih (Excess Flood) 17.05.35 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 17.05.39 Join niekie [0] (~niek@CAcert/Assurer/niekie) 17.05.41 Quit amiconn (Excess Flood) 17.05.50 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 17.06.10 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 17.06.14 Quit amiconn (Excess Flood) 17.06.29 # * jhMikeS suggests not changing filebuflen off-thread 17.06.36 Quit Unhelpful (Excess Flood) 17.06.39 Join otih [0] (~otih@0x01.f2tec.de) 17.06.39 Quit otih (Changing host) 17.06.39 Join otih [0] (~otih@CAcert/Assurer/otih) 17.06.40 Quit JesusFreak316 (Ping timeout: 260 seconds) 17.06.44 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 17.06.51 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 17.06.51 Join amiconn [0] (quassel@rockbox/developer/amiconn) 17.06.56 Quit balintx (Excess Flood) 17.07.31 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 17.07.32 Quit benedikt93 (Read error: Connection reset by peer) 17.07.56 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 17.07.58 Join balintx_ [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) 17.08.25 # well, its after 1am here, and its not my bug so im going to bed. If there is lots of complaints someone please revert all my commits tonight 17.09.08 # its not crashing all targets. very annoying anyway 17.09.11 Quit niekie (Excess Flood) 17.09.12 Quit y4n (Quit: PANTS OFF!) 17.09.39 # jhMikeS: before buflib filebuflen wasn't a global at all, should be safe 17.09.49 Join simonlnu_ [0] (n1orJxlc1b@unaffiliated/simonrvn) 17.09.59 Join y4n [0] (y4n@unaffiliated/y4ndexx) 17.10.15 Nick balintx_ is now known as balintx (~quassel@szerver1.gulyasp-koll.sulinet.hu) 17.10.30 Join niekie [0] (~niek@CAcert/Assurer/niekie) 17.11.17 Join tjb0607 [0] (~quassel@208-100-128-206.bendbroadband.com) 17.11.17 Join Lalufu_ [0] (~sun@ryoko.camperquake.de) 17.11.18 Join desowin_ [0] (~desowin@ip-69-162-133-250.static.chi2.systeminplace.net) 17.11.35 Join rinaku_ [0] (johan@nibox.dgmil.net) 17.12.19 Join rasher_ [0] (~rasher@rockbox/developer/rasher) 17.13.19 Join ack [0] (~ack@mingbai.org) 17.13.35 # it was based upon some globals 17.13.46 Nick ack is now known as Guest64469 (~ack@mingbai.org) 17.16.17 # I suppose I shouldn't worry about this without removing some further dependencies with voice 17.16.41 Join maraz_ [0] (maraz@kapsi.fi) 17.16.46 Quit ps-auxw (Disconnected by services) 17.16.48 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 17.17.01 Join ps-auxw [0] (~arneb@p4FF7FE6B.dip.t-dialin.net) 17.18.10 Quit rasher (*.net *.split) 17.18.23 Quit Guest35783 (*.net *.split) 17.18.23 Quit user890104 (*.net *.split) 17.18.23 Quit tjb0607_ (*.net *.split) 17.18.23 Quit froggyman (*.net *.split) 17.18.23 Quit fs-bluebot (*.net *.split) 17.18.23 Quit Farthen (*.net *.split) 17.18.23 Quit simonlnu (*.net *.split) 17.18.23 Quit parafin (*.net *.split) 17.18.23 Quit ender| (*.net *.split) 17.18.23 Quit Lalufu (*.net *.split) 17.18.23 Quit desowin (*.net *.split) 17.18.23 Quit maraz (*.net *.split) 17.18.23 Quit Hadaka (*.net *.split) 17.18.23 Quit rinaku (*.net *.split) 17.18.23 Nick rasher_ is now known as rasher (~rasher@rockbox/developer/rasher) 17.18.23 Nick simonlnu_ is now known as simonlnu (n1orJxlc1b@unaffiliated/simonrvn) 17.18.47 Quit otih (Excess Flood) 17.18.47 Quit Unhelpful (Excess Flood) 17.18.48 Quit amiconn (Excess Flood) 17.18.48 Quit niekie (Excess Flood) 17.18.51 Quit TheSeven (Excess Flood) 17.18.52 Quit balintx (Excess Flood) 17.18.55 Join amiconn [0] (quassel@rockbox/developer/amiconn) 17.18.56 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 17.19.06 Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) 17.19.19 Quit amiconn (Excess Flood) 17.19.21 Quit balintx (Excess Flood) 17.19.36 Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) 17.19.38 Join user890104 [0] (~Venci@2a01:4f8:101:2a4:0:bc28:b2e1:9) 17.19.50 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 17.19.50 Join otih [0] (~otih@0x01.f2tec.de) 17.19.54 Quit otih (Changing host) 17.19.54 Join otih [0] (~otih@CAcert/Assurer/otih) 17.19.55 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 17.19.55 Quit balintx (Excess Flood) 17.19.56 Quit Unhelpful (Excess Flood) 17.19.59 Join amiconn [0] (quassel@rockbox/developer/amiconn) 17.20.04 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 17.20.06 Join niekie [0] (~niek@CAcert/Assurer/niekie) 17.20.09 Quit otih (Excess Flood) 17.20.21 Quit amiconn (Excess Flood) 17.20.28 Join amiconn [0] (quassel@rockbox/developer/amiconn) 17.21.02 Quit Unhelpful (Excess Flood) 17.21.13 Join otih [0] (~otih@0x01.f2tec.de) 17.21.14 Quit otih (Changing host) 17.21.14 Join otih [0] (~otih@CAcert/Assurer/otih) 17.21.38 Join Farthen [0] (~Farthen@2a01:4f8:101:2a4:0:bc28:b2e1:9) 17.21.45 Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) 17.22.07 Quit TheSeven (Excess Flood) 17.23.02 Join froggyman [0] (~seth@unaffiliated/froggyman) 17.23.09 Join parafin [0] (parafin@paraf.in) 17.23.25 Join ender| [0] (~ender1@foo.eternallybored.org) 17.23.25 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 17.23.39 Quit niekie (Excess Flood) 17.23.50 Join fs-bluebot [0] (~fs-bluebo@g226068205.adsl.alicedsl.de) 17.24.02 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 17.24.11 Join Naked [0] (~naked@naked.iki.fi) 17.24.24 Nick Naked is now known as Hadaka (~naked@naked.iki.fi) 17.24.59 Join niekie [0] (~niek@CAcert/Assurer/niekie) 17.26.15 Quit antil33t () 17.26.41 Quit balintx (Read error: Connection reset by peer) 17.26.43 Quit tjb0607 (Read error: Connection reset by peer) 17.26.45 Quit otih (Read error: Connection reset by peer) 17.26.45 Quit pixelma (Remote host closed the connection) 17.26.45 Quit amiconn (Write error: Connection reset by peer) 17.26.55 Quit Unhelpful (Read error: Connection reset by peer) 17.28.16 Quit niekie (Read error: Connection reset by peer) 17.29.58 Join amiconn [0] (quassel@rockbox/developer/amiconn) 17.29.58 Join pixelma [0] (quassel@rockbox/staff/pixelma) 17.31.08 Quit TheSeven (Ping timeout: 240 seconds) 17.31.35 # think I'll have to have codecs update their offset explicitely as well as elapsed instead of inferring it from ci.curpos automatically 17.34.26 Part Zagor 17.34.56 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 17.36.40 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 17.38.14 Join Keripo [0] (~Keripo@165.123.49.253) 17.42.12 Nick Lalufu_ is now known as Lalufu (~sun@ryoko.camperquake.de) 17.42.24 Quit Lalufu (Changing host) 17.42.24 Join Lalufu [0] (~sun@unaffiliated/lalufu) 17.43.05 Quit Keripo (Client Quit) 17.46.43 Quit user890104 (Quit: .) 17.46.43 Quit Farthen (Quit: ZNC - http://znc.in) 17.47.15 Join user890104 [0] (~Venci@2a01:4f8:101:2a4:0:bc28:b2e1:9) 17.47.45 Join Farthen [0] (~Farthen@2a01:4f8:101:2a4:0:bc28:b2e1:9) 17.48.24 Join lebellium [0] (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr) 17.49.51 Part LinusN 17.51.53 # jhMikeS: recently i've experienced some hangs on my h300 with voice enabled while browsing the filesystem 17.53.54 # n1s: doesn't have to be a new thing. It sounds familiar on coldfire targets, something that hit irregularly and became more rare over time 17.54.24 # pixelma: ah 17.54.49 Join Keripo [0] (~Keripo@seas584.wireless-pennnet.upenn.edu) 17.54.50 # there was a fix for that, but now, things work very differently, but is it in pcm or talk? 17.55.19 # no idea, it just hangs 17.55.34 # no backlight action? 17.56.45 Join powell14ski_ [0] (~powell14s@c-174-51-194-6.hsd1.co.comcast.net) 17.59.17 # heh, playback get 5 restart messages in rapid fire when enabling timestretch (??) 17.59.28 # jhMikeS: nope, seems to be triggered by filename spelling 17.59.51 # completely frozen with bl on and disk spinning 18.00.18 Quit Keripo (Quit: Leaving.) 18.02.47 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 18.03.12 Quit pamaury (Remote host closed the connection) 18.03.17 # try upping the voice stack size? that seems to be cut rather close 18.04.18 # wait, wtf. I tried it on the beast and the entire framebuffer was splashed with random pixels 18.04.44 # the backdrop buffer got blasted 18.04.53 Join balintx_ [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) 18.05.05 # jhMikeS: that has never been fixed completely for me. It happened recently with an around r30000 build on M5 for me. I usually have voice enabled but it didn't happen very often anymore 18.05.52 # there is something wrong and it's not just coldfire 18.06.20 # I was testing the filename spelling btw. voice menus are alright 18.06.45 Join Stummi [0] (~Stummi@rockbox/developer/Stummi) 18.08.22 Nick balintx_ is now known as balintx (~quassel@szerver1.gulyasp-koll.sulinet.hu) 18.08.51 # on the beast with filename spelling: http://jhmikes.cleansoap.org/dump 110908-120426.bmp 18.08.54 Quit balintx (Read error: Connection reset by peer) 18.09.09 # bah http://jhmikes.cleansoap.org/dump%20110908-120426.bmp 18.09.47 # funky 18.10.06 # .bmp? :o 18.10.07 # i can't reproduce the hang with a larger voice stack though 18.10.37 Join Keripo [0] (~Keripo@seas584.wireless-pennnet.upenn.edu) 18.10.42 # could be undetectable stack overflow then 18.10.59 # Stummi: it's USB screenshot, which is .bmp :) 18.12.07 Quit factor (Read error: Connection reset by peer) 18.12.14 Quit Stummi (Remote host closed the connection) 18.17.45 Join Stummi [0] (~Stummi@rockbox/developer/Stummi) 18.18.25 # ok, I guess voice menus aren't fine afterall. they were before last time I did anything with voice. it's clobbering everything now 18.20.22 # yeah i can reproduce with larger stack, i just messed up with the settings before :/ 18.21.26 # I'm pointing finger now. It was fine a few days ago for me. 18.28.47 Join factor [0] (~factor@74.197.205.204) 18.29.14 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 18.31.51 # I think the audio buffer is getting changed but not getting marked as no longer valid 18.32.29 # if voice tries to run, it's still using the old buffer values 18.43.32 Quit Stummi (Remote host closed the connection) 18.44.51 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 18.46.09 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 18.46.50 Join Stummi [0] (~Stummi@rockbox/developer/Stummi) 18.47.45 *** Saving seen data "./dancer.seen" 18.51.35 # If I go back to the last commit I made, the voice is alright. 18.52.23 Join WalkGood_ [0] (~WalkGood@adsl-108-132-12-123.mia.bellsouth.net) 18.52.23 Quit WalkGood_ (Changing host) 18.52.23 Join WalkGood_ [0] (~WalkGood@unaffiliated/walkgood) 18.52.50 Quit WalkGood (Disconnected by services) 18.52.56 Nick WalkGood_ is now known as WalkGood (~WalkGood@unaffiliated/walkgood) 18.54.44 # we have a wiki page on how to cross compile the sim with MinGW? 18.57.13 # aha, voice only gets a renew on the audio buffer if it went to state trashed, but resetting as a restart takes it down to voiced only state, meaning voice never gets it updated 19.22.39 Join Horscht [0] (~Horscht@p5DD57871.dip.t-dialin.net) 19.22.39 Quit Horscht (Changing host) 19.22.39 Join Horscht [0] (~Horscht@xbmc/user/horscht) 19.29.25 Quit Keripo (Ping timeout: 260 seconds) 19.33.06 Join Keripo [0] (~Keripo@hou450.wireless-pennnet.upenn.edu) 19.37.03 # New commit by 03bluebrother (r30483): Fix toolchain installation. ... 19.37.07 Quit Keripo (Ping timeout: 240 seconds) 19.39.38 # r30483 build result: All green 19.48.03 # bluebroth3r: are you sure that doesn't break windows installs? 19.48.03 Quit fs-bluebot (Read error: Connection reset by peer) 19.48.03 Quit bluebroth3r (Read error: Connection reset by peer) 19.48.19 # New commit by 03bluebrother (r30484): Improve sim win32 cross compiling. ... 19.48.21 Join bluebrother [0] (~dom@g226068205.adsl.alicedsl.de) 19.48.22 Quit bluebrother (Changing host) 19.48.22 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 19.48.48 # bluebrother: sure that android installer change doesn't break windows/linux installs? 19.50.22 # preglow: it doesn't break on Linux. I've tried that :) 19.50.30 # r30484 build result: All green 19.50.48 # and on Windows ... well, building for Android with Cygwin is broken anyway. 19.51.00 # and who cares about windows! \o/ :P 19.51.17 # I had a look into that some time ago but wasn't motivated too much to get it fixed. I looks like it will be quite a bit of work. 19.51.41 # pft, sod it 19.51.56 Join fs-bluebot [0] (~fs-bluebo@g226068205.adsl.alicedsl.de) 19.52.00 # sometimes I have such kind of motivations ;-) 19.52.24 # (likely to happen when I'm using Windows for some Rockbox Utility thing) 19.52.41 Join Buschel [0] (~chatzilla@p54A3A789.dip.t-dialin.net) 19.52.44 Join Strife89 [0] (~Strife89@207.144.201.128) 19.57.13 Quit stoffel (Remote host closed the connection) 20.04.03 Join Horschti [0] (~Horscht@p5DD56B71.dip.t-dialin.net) 20.04.03 Quit Horschti (Changing host) 20.04.03 Join Horschti [0] (~Horscht@xbmc/user/horscht) 20.05.03 Quit Horscht (Ping timeout: 252 seconds) 20.06.02 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 20.10.51 Join Keripo [0] (~Keripo@hou450.wireless-pennnet.upenn.edu) 20.11.09 # hmm, since r30478 my WPS does not load anymore. cabbiev2 works fine 20.12.11 Quit Stummi (Ping timeout: 258 seconds) 20.12.15 Join robin0800 [0] (~robin0800@149.254.60.171) 20.12.18 # simulator give a warning: "Unable to load font 3: 'blalbla.ftn'" 20.13.27 # everything works as expected at r30477 and below 20.15.18 # cabbiev2 doesn't use any extra fonts, so it looks like some font loading problem 20.15.38 # I will add a note to FS#12265 20.15.38 # http://www.rockbox.org/tracker/task/12265 3Sansa Clip+ cannot display cabbiev2 wps at r30478 (bugs, unconfirmed) 20.15.39 Quit Keripo (Ping timeout: 260 seconds) 20.16.00 # * bertrik wonders why show_logo has a return argument 20.16.16 # return value 20.16.49 Join Stummi [0] (~Stummi@rockbox/developer/Stummi) 20.17.20 Join balintx_ [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) 20.20.45 Join niekie [0] (~niek@CAcert/Assurer/niekie) 20.20.53 Nick balintx_ is now known as balintx (~quassel@szerver1.gulyasp-koll.sulinet.hu) 20.21.25 # Also a bit peculiar that each bootloader declares show_logo it again instead of using a common header file 20.21.54 # blame copy n' paste programming I'd say =) 20.22.37 Quit robin0800 (Ping timeout: 240 seconds) 20.22.38 Quit balintx (Read error: Connection reset by peer) 20.23.51 Quit niekie (Read error: Connection reset by peer) 20.24.41 Join balintx_ [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) 20.27.51 Join Keripo [0] (~Keripo@165.123.49.226) 20.28.28 Join kevin128 [0] (~kevin@69-12-206-218.dsl.dynamic.sonic.net) 20.28.30 Quit pixelma (Excess Flood) 20.28.32 # it seems my WPS issue is caused by too small SKIN_BUFFER_SIZE, I have attached a patch to FS#12265 which fixes this for me 20.28.33 # http://www.rockbox.org/tracker/task/12265 3Sansa Clip+ cannot display cabbiev2 wps at r30478 (bugs, unconfirmed) 20.28.39 Join pixelma [0] (quassel@rockbox/staff/pixelma) 20.29.10 # so it turns out there is an espeak plugin for Rockbox, but I have to compile it. can anyone tell me where I can learn to compile *plugins* please? I'm looking on the wiki and it just talks about compiling rockbox itsself. 20.29.45 Join niekie [0] (~niek@CAcert/Assurer/niekie) 20.30.20 # kevin128: plugins are a part of Rockbox. You need to build Rockbox to be able building a plugin 20.31.16 # New commit by 03bertrik (r30485): Remove return value from show_logo() in bootloader/ 20.32.27 Quit pixelma (Excess Flood) 20.32.38 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 20.32.40 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 20.33.25 # r30485 build result: All green 20.36.31 # so I would download and extract the plugin into a rockbox source tree and then build the whole thing for my particular device? 20.40.13 Quit pixelma (Excess Flood) 20.40.22 Join pixelma [0] (quassel@rockbox/staff/pixelma) 20.41.18 Quit niekie (Read error: Connection reset by peer) 20.41.52 Nick balintx_ is now known as balintx (~quassel@szerver1.gulyasp-koll.sulinet.hu) 20.46.21 Quit benedikt93 (Read error: Connection reset by peer) 20.47.43 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 20.47.47 *** Saving seen data "./dancer.seen" 20.53.20 Quit Keripo (Quit: Leaving.) 20.53.33 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 20.57.19 # kevin128: basically, yes 20.59.27 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 21.14.41 Quit Stummi (Ping timeout: 260 seconds) 21.15.09 # Lalufu, you have some way to make iap work on a new target? 21.18.43 # so if the espeak folder has a MakeFie, do I stick it in /rockbox/firmware or rockbox/apps/plugins? 21.22.14 Join robin0800 [0] (~robin0800@149.254.61.29) 21.23.14 Quit amiconn (Remote host closed the connection) 21.23.14 Quit pixelma (Remote host closed the connection) 21.23.39 Join amiconn [0] (quassel@rockbox/developer/amiconn) 21.23.42 Join pixelma [0] (quassel@rockbox/staff/pixelma) 21.25.35 # bertrik: I am trying to get it to work on a iPod Mini 2G. 21.26.22 # Did you just change SER0 to SER1 so far? 21.26.33 # to make serial basically work: yes. 21.27.05 # oh cool, then iap should work nearly automatically too I guess 21.27.52 Quit Buschel (Quit: ChatZilla 0.9.87 [Firefox 6.0.2/20110902133214]) 21.27.54 # End goal is to make it talk to an Audi car entertainment system 21.27.56 # can you both tx and rx? 21.28.02 # yes 21.28.14 Join petur [0] (~petur@rockbox/developer/petur) 21.29.11 # it looks to me as if support in IMA for retrieving playlist information is a bit patchy. 21.30.19 # I'm currently reverse engineering what the Audi is doing, using an iPod touch as the reference 21.30.37 Join saratoga [0] (9803ec71@gateway/web/freenode/ip.152.3.236.113) 21.31.46 Part WalkGood 21.31.47 Join funman [0] (~fun@rockbox/developer/funman) 21.32.26 Quit benedikt93 (Quit: Bye ;)) 21.38.11 Quit robin0800 (Read error: Connection reset by peer) 21.38.21 Join robin0800_ [0] (~robin0800@149.254.61.29) 21.39.40 # I'm not sure if the SER0/SER1 mapping can be fixed by poking some registers on the PP5020 21.39.51 # if not the patch is going to be rather ugly. 21.40.06 # can't just preprocessor it? 21.40.20 # but from a hardware perspective everything seems to work, now I'm wrestling with ima.c 21.40.24 # I was thinking along the line of using something like SER_LCR and define it as either SER0_LCR or SER1_LCR depending on the target 21.41.16 # The other way is to use a base register plus offsets (so by changing the base register you can switch between ser0 and ser1) instead of direct serial port addresses 21.41.28 # can be done, I think, but that's rather ugly. 21.41.46 # iap is already ugly ... :) 21.41.47 Quit kevin128 (Quit: Leaving.) 21.42.01 # bertrik: so did you try code on a real clipzip? 21.42.15 # funman, no I don't have a clipzip yet 21.42.32 # iap is not touched by this, the changes are in serial.c and system-pp502x.c 21.42.52 # system-pp502x.c is only one line, for setting up the interrupt 21.43.37 # bertrik: someone else maybe? 21.53.43 Join niekie [0] (~niek@CAcert/Assurer/niekie) 21.56.15 Join Keripo [0] (~Keripo@SEAS302.wlan.seas.upenn.edu) 21.59.40 # funman, I'd rather not let a non-developer try experimental code, and there's no rockbox dev with the device AFAIK 22.00.11 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 22.02.57 Quit y4n (Quit: PANTS OFF!) 22.03.47 Join Stummi [0] (~Stummi@rockbox/developer/Stummi) 22.05.28 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 22.07.26 Join kevin128 [0] (~kevin@69-12-206-218.dsl.dynamic.sonic.net) 22.07.45 # ok, I've compiled rockbox for my D2, but the espeak plugin didn't build with it 22.08.18 # if i go into the espeak plugin directory and type make, i get makesrc.inc not found 22.10.18 # kevin128: plugins should build together with the rest of the system. Running make in random directories is going to have unpredictable and interesting results. Your problem most probably is that the espeak plugin/patch on flyspray is rather old and got out of sync with modern rockbox 22.32.06 Quit petur (Remote host closed the connection) 22.32.30 Quit Keripo (Quit: Leaving.) 22.37.49 # aha, I think I know what's causing FS#12265 22.37.50 # http://www.rockbox.org/tracker/task/12265 3Sansa Clip+ cannot display cabbiev2 wps at r30478 (bugs, unconfirmed) 22.38.16 Join reuttles [0] (~5cNed@69-165-173-252.dsl.teksavvy.com) 22.40.04 # I suspect: since buflib reserves space for handles after alloc_maximum() there's free space after the audio buffer 22.40.21 # that's sufficiently large for the tiny monochrome bitmaps 22.40.38 Quit Stummi (Quit: Bye!) 22.41.05 # thus, a tiny allocation sneaks in behind audiobuf 22.41.17 # can rockbox be set up to only turn on the backlight if I press a certain button? for example not having it turn on if I turn up/down the volume or advance to a next track 22.42.39 # all fine, except that only audiobuf can shrink on its back to make room for handles. the tiny alloc can't shrink, and thus no room can be made for handles 22.43.24 # Hi, I am having problems with a Sansa Clip v1. It was playing fine, reached the end of the album and stopped, so I put it down. The next time I went to use it it would not turn on at all (no display). Connected to USB, the screen turns on as normal and is detected by the PC. I have tried the standard reset (holding power switch), updating to latest Sansa FW, reinstalling RB bootloader, and 22.43.24 # doing complete reinstall of RB, no change. I thought it might be the power switch, but when USB is attached and switch is held, Charging/Connected screen will turn off after ~10 seconds. Any suggestions? 22.43.34 # not sure how to solve 22.45.08 # I've also tried booting to the Sansa FW using power+left dir key, that doesn't do anything either. 22.47.13 # the problem is that the audiobuf is unmoveable so compacting stuff behind it is likely to fail 22.47.50 *** Saving seen data "./dancer.seen" 22.54.32 # but otoh, rockbox clearly shouldn't crash if the skin engine runs OOM 22.58.04 Quit funman (Quit: leaving) 22.59.07 Join viperfang_ [0] (~viperfang@cpc2-nrwh9-2-0-cust228.4-4.cable.virginmedia.com) 22.59.27 Quit ender` (Quit: If the experiment works, you must be using the wrong equipment. -- Patrick's Theorem) 22.59.27 # Good evening all 22.59.50 # I have an IPod 6G that crashes whilst in USB mode... anyone heard of this? 23.04.31 # I believe n1s had a similar problem and knows more but am not sure 23.07.04 # yep 23.07.33 # viperfang_: see FS#12083 23.07.35 # http://www.rockbox.org/tracker/task/12083 3Add delay to usb-s3c6400x init to fix usb hang on some ipod classics (patches, new) 23.07.39 # I have the 128GB model, I believe Classic G2, you? 23.07.54 # same i think 23.08.09 # Ah, so if I were compiling from svn that should be fixed? 23.08.20 # nope 23.08.47 # dang 23.08.48 # i really should commit that fix though, needs a bit more testing on nano2g i think 23.09.11 # viperfang_: if you can compile, just apply the patch and it should work fine 23.10.20 # heh, just compiled, looks like another run :-) 23.17.52 Join nick-p [0] (~nick@82-69-105-120.dsl.in-addr.zen.co.uk) 23.19.34 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 23.28.53 Part Strife89 ("Vamoose!") 23.30.37 Quit ReimuHakurei_ (Read error: Connection reset by peer) 23.30.55 Join ReimuHakurei_ [0] (~kudo@wireless.sit-co.net) 23.33.45 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 23.40.32 Join nameless [0] (b8980af8@gateway/web/freenode/ip.184.152.10.248) 23.41.06 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 23.41.52 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 23.44.38 # Hello everyone. I have a slight problem, my iPod Nano 1G is stuck at "Divide by zero at 01F8055C (0)" after being in the metronome app. 23.46.03 Quit God_Eater (Ping timeout: 252 seconds) 23.52.49 Quit ReimuHakurei_ (Read error: Connection reset by peer) 23.53.05 Join ReimuHakurei [0] (~kudo@wireless.sit-co.net) 23.53.22 # nameless: reset it 23.54.21 # nameless: http://www.rockbox.org/wiki/IpodFAQ#How_do_I_reset_the_iPod_63 23.56.46 Quit kevin128 (Quit: Leaving.) 23.56.46 # Thank you! I shall remember this ( i think it will happen again). Bye! 23.56.49 Quit nameless (Quit: Page closed) 23.58.21 Quit Unhelpful (Read error: Connection reset by peer)