--- Log for 26.09.112 Server: leguin.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 27 days and 0 hours ago 00.03.53 Join amayer [0] (~alex@h210.53.213.151.dynamic.ip.windstream.net) 00.09.41 Quit lorenzo92 (Quit: ChatZilla 0.9.89 [Firefox 15.0.1/20120907231657]) 00.28.26 Quit ender` (Quit: There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare) 00.28.44 # hello all - any news regarding the nano2g usb issue ? :D 00.39.03 Quit ChanServ (*.net *.split) 00.39.33 Quit mgottschlag (Ping timeout: 240 seconds) 00.46.31 Join ChanServ [0] (ChanServ@services.) 00.46.31 Mode "#rockbox +o ChanServ " by leguin.freenode.net 00.50.00 Quit scorche (Ping timeout: 245 seconds) 00.53.08 Join scorche [0] (~scorche@rockbox/administrator/scorche) 01.26.07 Quit lebellium (Quit: ChatZilla 0.9.89 [Firefox 16.0/20120919065210]) 01.40.54 Quit eckoit (Quit: eckoit) 01.41.31 Quit amayer (Quit: amayer) 01.42.13 Quit n1s (Quit: Ex-Chat) 01.42.17 Join amayer [0] (~alex@h210.53.213.151.dynamic.ip.windstream.net) 01.50.20 *** Saving seen data "./dancer.seen" 01.52.42 Quit XavierGr (Ping timeout: 260 seconds) 01.58.57 Join XavierGr [0] (XavierGr@rockbox/staff/XavierGr) 02.53.55 # <[Saint]> sakax: I'm guessing "it's still fudged" won't satisfy? 02.54.01 # <[Saint]> ;) 02.57.09 # <[Saint]> Long story short, as I know it: USB in git HEAD is broken; attempts have been made to disable rockbox USB and reboot to the OF on USB insertion but the code that handles this isn't functioning as it was prior to the driver rework that broke USB in the first place. 03.02.38 # <[Saint]> even though it's a bit of a hassle, one can still reboot to the OF and use USB there, or force Emergency Disk Mode and use USB there (either by menu+select; play+select in a traditional installation or from the emCORE menu directly in an emCORE enabled setup). 03.20.00 Quit Syconaut (Ping timeout: 245 seconds) 03.47.41 Quit bootinfdsds (Read error: Connection reset by peer) 03.48.15 Join bootlkjkgf [0] (~Prmhfhfx@92.39.204.151) 03.50.21 *** Saving seen data "./dancer.seen" 03.58.36 Join eckoit [0] (~ryan@50.65.10.24) 04.06.32 Join ser [0] (~ser@host1.tldp.ibiblio.org) 04.06.36 Quit ser (Read error: Connection reset by peer) 04.09.25 Join ser [0] (~ser@host1.tldp.ibiblio.org) 04.18.47 Quit Jack87 (Ping timeout: 260 seconds) 04.20.22 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.20.22 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.20.22 Quit pixelma (Disconnected by services) 04.20.22 Quit amiconn (Disconnected by services) 04.20.24 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.20.26 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.38.57 Quit TheSphinX^ (Read error: Operation timed out) 04.41.10 Join Jack87 [0] (Jack87@nasadmin/admin/jack87) 04.46.39 Join TheSphinX^ [0] (~briehl@p5B322B6E.dip.t-dialin.net) 05.25.07 Part amayer 05.26.34 Quit TheSeven (Disconnected by services) 05.26.43 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 05.50.23 *** Saving seen data "./dancer.seen" 06.51.22 Quit soap (Ping timeout: 256 seconds) 06.56.12 Join Totalled [0] (~Totalled@c-98-245-9-211.hsd1.co.comcast.net) 07.04.58 Quit eckoit (Quit: eckoit) 07.05.54 Quit pedro_angelo (Read error: Connection reset by peer) 07.13.48 Join eckoit [0] (~ryan@50.65.10.24) 07.13.57 Quit factor (Read error: Connection reset by peer) 07.21.16 Quit sciopath (Read error: Connection reset by peer) 07.29.35 Join mortalis [0] (~mortalis@195.34.194.126.kalibroao.ru) 07.32.08 Join factor [0] (~factor@r74-195-187-142.msk1cmtc01.mskgok.ok.dh.suddenlink.net) 07.36.23 Quit the-kyle (Quit: Leaving.) 07.38.49 Join soap [0] (~soap@cpe-174-102-110-153.woh.res.rr.com) 07.38.50 Quit soap (Changing host) 07.38.50 Join soap [0] (~soap@rockbox/staff/soap) 07.50.24 *** Saving seen data "./dancer.seen" 07.54.29 Quit pixelma (Read error: Connection reset by peer) 07.54.29 Quit amiconn (Write error: Connection reset by peer) 07.54.48 Join amiconn [0] (amiconn@rockbox/developer/amiconn) 07.54.49 Join pixelma [0] (pixelma@rockbox/staff/pixelma) 08.39.35 Join Zagor [0] (~bjst@sestofw01.enea.se) 08.39.35 Quit Zagor (Changing host) 08.39.35 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 08.39.37 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 08.49.57 Quit Rower85 (Read error: Connection reset by peer) 09.07.54 Join LinusN [0] (~linus@giant.haxx.se) 09.20.19 Quit bertrik (Ping timeout: 248 seconds) 09.24.41 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 09.24.54 Join webguest319 [0] (~3e8ec2cb@www.haxx.se) 09.25.56 # Hello 09.27.02 # I noticed that both the Clip+ and Clip v1 referres to http://download.rockbox. org/bootloader/sandisk-sansa/mkamsboot/ 09.27.19 # I ran the executable, and it is version 1.5. 09.28.03 # But I also found http://download.rockbox.org/bootloader/sandisk-sansa/mkamsboot-1.6/ 09.30.12 # Is 1.6 beta, or is the PDF out of date, or has someone just forgot to replace the 1.5 executables in /mkamsboot with the ones from /mkamsboot-1.6 ? 09.35.20 Join petur [0] (~petur@rockbox/developer/petur) 09.36.04 Join Buschel [0] (~chatzilla@p57905E53.dip.t-dialin.net) 09.50.28 *** Saving seen data "./dancer.seen" 10.19.17 Quit XavierGr (Ping timeout: 260 seconds) 10.19.54 Join Thra11_ [0] (~thrall@31.185.128.199) 10.35.45 Join n1s [0] (~n1s@nl118-168-30.student.uu.se) 10.35.46 Quit n1s (Changing host) 10.35.46 Join n1s [0] (~n1s@rockbox/developer/n1s) 10.40.20 Quit [Saint] (Remote host closed the connection) 10.41.57 Join [Saint] [0] (~saint@rockbox/user/saint) 10.45.05 Quit Prodicus (Ping timeout: 264 seconds) 10.49.11 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 10.50.09 # mortalis: ping 10.50.33 # wodz: pong 10.51.23 # mortalis: I played a bit with the patch. Definitely there is improvement with current init sequence as various glitches go away. 10.51.51 # mortalis: Although 'guarding' part is incorrect imo. 10.52.21 # All in all it almost work 10.52.29 # irq trigger only 1 time during single lcd_update 10.52.47 # have you confirmed this on the target? 10.53.26 # yes, i checked this by comparing lcd_update counts and interrupts count 10.54.13 Quit funman (Quit: Lost terminal) 10.54.56 # anyway, version with irqs doesn't work for me when i start playing mp3, ape or wv 10.55.17 Join funman [0] (~fun@rockbox/developer/funman) 10.58.12 # http://pastie.org/4805446 this DOESN'T work. First update is correct (as I can see rockbox logo) but second messes up the screen 10.58.19 # in version with while i discovered that frequent lcd updates during playback cause glitches. IIRC i don't have glitches when i use full lcd_update instead of partial. I'll check this latter 10.59.21 # you need to protect partial updates to occure when full screen update is still in progress 10.59.46 # indeed 11.01.15 # Reading manual once more it seems like lcdif can generate irq on successful buffer write. Maybe we should explore this route? 11.02.10 Join lebellium [0] (~chatzilla@e178184159.adsl.alicedsl.de) 11.06.37 # wodz: code that you pasted doesn't work, and with semaphores it works? I think this is because while(lcd_updating); isn't safe in multithreaded environment. 11.08.22 # with semaphore no lcd_update takes effect. It sits on blocking semaphore and because dma is not activated yet it dedlocks 11.10.53 # if you talking about clear patchset 5 then semaphore initialization incorrect there. Try this semaphore_init(&lcd_updating, 1, 1); 11.11.56 # will try later 11.17.06 # i guess my problem with irq version could be solved by protecting partial updates. 11.18.20 Quit mgottschlag (Ping timeout: 244 seconds) 11.18.44 # hopefully 11.23.22 # mortalis: With this approach semaphore_init(&lcd_updating, 1, 1) it is basically the same as mutex. If mutex version doesn't work for you semaphore should fail as well 11.46.02 Quit bluebrother (Ping timeout: 256 seconds) 11.46.52 Quit fs-bluebot (Ping timeout: 264 seconds) 11.47.55 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 11.48.18 Join fs-bluebot [0] (~fs-bluebo@g231121134.adsl.alicedsl.de) 11.50.01 # wodz: When i said that mutex doesn't work i didn't mean that "version with mutex doesn't work". I meant that mutex itself doesn't work. 11.50.12 # in other words mutex_lock doesn't lock 11.50.32 *** Saving seen data "./dancer.seen" 11.52.29 # what? 11.53.53 # that would mean serious bug in kernel 11.58.01 # i know, maybe i just updated rb incorrectly (forget to unmount before ejecting sd card or something) so i had old binary. i'll check it once more later 12.03.43 # hum has anyone noticed a strange RDS behaviour on the Zip (latest build)? 12.05.44 # it starts displaying the right RDS info but after a few seconds it displays the RB virtual keyboard (abcdefghig etc) and strange caracters 12.08.53 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 12.09.20 # Heh looks like mem corruption. Segfaults have been seen associated with RDS on hosted targets (R0) recently. This could be the same 12.10.26 # hum ok 12.10.38 # so it's a known issue? 12.11.15 # not much - you are the first one to report such behavior on native target 12.12.34 # n1s: you've added several performance optimizations to the opus decocer. can you give some numbers on the current performance? your commit messages only state deltas :) 12.13.39 # Buschel: the 64kbps test file i've been using is now 77.96% realtime on cf, 88.48% realtime on pp and 220% realtime on amsv1 12.14.52 # still some way to go ;) 12.15.51 # yeah, better iram use gives a nice further speedup on cf but i haven't done it in a clean way yet :) 12.16.52 # for arm i guess, more/better asm for some of the hot functions might be needed 12.20.49 # yep. you have added asm for MULT16_32_Q15 only. are the other operations not significantly used? 12.23.47 # hmm, sim just crashed with message: queue_post ovf q=082A27A0 12.24.13 # I just pressed mapped button a few times 12.25.39 # lebellium: You should highlight this to bertrik and kugel 12.26.27 # okay 12.26.28 # I'll do that 12.28.16 # wodz: sometimes the sim cannot keep up with poping input events, then the event queue overflows 12.28.48 # kugel: with like 10 consecutive key presses? 12.29.57 # normally a single press leads to more input events (since polling happens at tick rate) 12.30.11 # i don't know the queue limit 12.31.31 # hmm, in regular binary it doesn't crash. Plugins tends to crash though 12.35.00 # the keyboard buffer isnt on the buflib buffer but static storage 12.36.16 # lebellium: what happens if you open the keyboard after this happens? 12.36.53 Quit scorche (Disconnected by services) 12.36.57 Join scorche` [0] (~scorche@rockbox/administrator/scorche) 12.37.06 # Buschel: it's the most common one, and one which gave crap code for both arm and cf 12.38.11 # the fft uses complex multiplies which in turn uses the MULT16_32_Q15 but they could probably be made faster by writing them as asm directly (using mac capabilities) 12.38.36 # i haven't gotten around to doing that yet 12.38.52 # n1s: clt_mdct_backward looks like it could be further optimized as well... as you just said using multiply-add. 12.39.06 # there seems to be quite some potential :) 12.39.46 # do we have official test files? 12.40.02 # On the other topic- I have mostly working bFLT on PP. I found only pitch_detector to hang. Doom complaints on missing wad file correctly. Other 'problematic' plugins randomly tested work. All this is with hacked version of elf2flt and code compiled with -mlong-calls 12.40.26 # brb 12.40.41 # Buschel: we have IIRC 12.41.17 # Buschel: yes, jmspeex suggested the biggest win for the mdct would probably come from replacing it with a better implementation 12.41.43 # Buschel: bertrik made some test files that i'm using but i'm not sure if they got uploaded to the site 12.42.30 # Buschel: are you planning to work on something? (just so we don't do the same thing :)) 12.42.32 # kugel: like for example adding a preset name? the keyboard displays properly. 12.47.42 # do I read correctly that opus suffers from resampling in our case? 12.52.15 # kugel & wodz: here's a screen of the bug on my device: http://imageshack.us/a/img855/8724/dump120926124155.png and http://imageshack.us/a/img837/2154/dump120926124439.png 12.52.27 Quit Synergist (Ping timeout: 268 seconds) 13.02.29 # n1s: I do not see any opus test files on the rockbxo site. can you upload your test files somewhere? 13.03.13 Quit petur (Quit: *plop*) 13.03.25 # n1s: changing the mdct might be a good idea. but I've heard the opus does not use N^2 sizes? 13.03.52 # n1s: maybe I will spend some time on this. in which area are you working right now? 13.04.36 Join the-kyle [0] (~kyle@cpe-024-211-185-030.nc.res.rr.com) 13.06.44 Join dfkt [0] (dfkt@unaffiliated/dfkt) 13.13.48 Join lebellium_ [0] (~chatzilla@e178184159.adsl.alicedsl.de) 13.15.19 # wodz: i think -mlong-calls is an acceptable work around until the bug is resolved (if at all) 13.15.45 # only codecs/plugins need that flag right? 13.16.52 Quit lebellium (Ping timeout: 264 seconds) 13.16.53 # Buschel: mostly looking at iram and cf asm, also made some changes suggested by jmspeex to the deemphasis loop 13.16.58 Nick lebellium_ is now known as lebellium (~chatzilla@e178184159.adsl.alicedsl.de) 13.18.53 # Buschel: bertrik uploaded them here https://docs.google.com/file/d/0ByItZAj1MynOUmJOWVl6Xy1QSG8/edit?pli=1 13.19.14 # kugel: For now only plugins (as I didn't work on converting codecs to bflt). When bflt loader will work with -mlong-calls builded plugins we could dive into ld internals. Looking at ld code it should be fairly easy. 13.19.51 # The provide internally reloc info for the symbols introduced by veneer insertion. They just don't bother to insert this info in final elf 13.19.54 # huh? without alcohol? 13.20.21 # ok, realistically alcohol is still needed :P 13.20.28 # :) 13.21.53 # The blocker is lack of documentation about ld/as internals. 13.23.30 # perhaps it's worth posting that find to the bug report 13.23.43 # then hopefully someone can be bothered with a quick fix 13.24.39 # n1s: thanks 13.27.29 # kugel: Don't think so. They call elf32_arm_final_link_relocate() for inserted veneers. This function performs final relocation (all addresses are known at this point) using associated internal reloc info. They discard anything intermediate (like reloc info) just because it is final link. 13.28.13 # The file of question is bfd/elf32-arm.c in binutils if you are interested. 13.29.55 # On the other hand there is gas/write.c where is code used by assembler to output relocations. The solution is probably to still part of it and insert in elf32_arm_final_link_relocate() 13.30.28 # n1s: do you have any kind of profiling information or an idea which parts of the decoder consume the most cpu time? 13.30.54 # I am unable however to much arguments needed. 13.31.57 # Buschel: http://www.rockbox.org/irc/log-20120922#10:50:39 13.37.25 # Buschel: those are on coldfire before i made any changes but i think the rough areas eating cpu are the same 13.38.35 # i guess i should try running a profile on arm too 13.39.22 # from your optimizations it is obvious that cf suffers badly from the lack of dcache 13.39.51 # yes, the combination of slow ram and no dcache 13.39.58 Join Synergist [0] (~synfn@node1.customhost.org.uk) 13.39.58 Quit Synergist (Changing host) 13.39.58 Join Synergist [0] (~synfn@unaffiliated/synergist) 13.40.07 # this silk-stuff is only used for very low bitrates? 13.40.18 # so I would expect profiling on arm differ significantly 13.41.17 # Buschel: afaik, yes and those seem to be comfortably realtime everywhere 13.41.38 # Buschel: no. There is mixed mode also: https://wiki.xiph.org/OpusFAQ#Why_not_keep_the_SILK_and_CELT_codecs_separate.3F 13.41.38 # so, we better don't care about that :) 13.44.27 # i just ran the profiles on 16 and 64 kbps and the 16 seems to be only silk and 64 only celt so perhaps i should run 32kbps too to see how hybrid does (benchmarking, it was slightly faster than 64kbps but not by that much while 16kbps was several times faster) 13.46.26 # again, do we resample output from opus decoder? 13.46.32 Join XavierGr [0] (XavierGr@rockbox/staff/XavierGr) 13.50.33 *** Saving seen data "./dancer.seen" 14.01.48 Quit mgottschlag (Ping timeout: 246 seconds) 14.05.06 Quit webguest319 (Quit: CGI:IRC (Ping timeout)) 14.05.30 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 14.08.41 Quit wodz (Quit: Leaving) 14.13.00 Quit mgottschlag (Ping timeout: 246 seconds) 14.13.44 Join megal0maniac [0] (~root@dsl-244-148-217.telkomadsl.co.za) 14.14.20 # Hi all. I was just wondering, is there a reason that there isn't a bootloader USB mode on the clipplus? Or that there is one on the fuzeplus? 14.15.09 # Experience has shown that USB still isn't exactly stable on the clipplus, and on the fuzeplus it is more reliable in bootloader mode. Less (or no) data aborts and the like. 14.19.29 # we generally only have bootloader usb on targets where it's required to install (like the gigabeat S) 14.19.48 # i have previously pondered trying to enable it on more platforms but never got around to doing anything 14.19.59 # it shouldn't actually be more reliable. 14.20.09 # it's teh exact same code doing all the USB/storage bits. 14.20.28 # But less other stuff running simultaneously. 14.20.37 # Very little runs when in usb mode anyway 14.20.49 # but yes, there is a difference 14.21.05 # the kind of issue there should be pretty easy to fix though (things like, stuff trying to read from files while in usb mode) 14.21.13 # (the font cache did this for a long time) :) 14.21.54 Join amayer_ [0] (~alex@mail.weberadvertising.com) 14.22.24 # but yes, for reasons of recovering from rockbox being broken i would quite like having bootloader usb on more targets 14.22.44 Join hietanen [0] (hietanen@mustatilhi.cs.tut.fi) 14.22.52 # Torne: Also, amsv2 targets seem to need all the help they can get :) 14.23.04 Nick hietanen is now known as herrandy (hietanen@mustatilhi.cs.tut.fi) 14.23.05 # usb works fine on my clipv2 :) 14.23.24 # On my clipplus, it works 70-80% of the time 14.24.01 # right, but the thing is, most of the possible reasons for it to not work reliably are problems in the usb stack, not problems caused by running in the full system 14.24.22 # if a given target really *is* more reliable in bootloader, then that's probably something we can track down and fix fairly easily 14.24.28 # and then you don't need bootloader usb :) 14.24.34 # * the-kyle seems to be having better luck with the clip+ in USB mode. It appears to work a bit more reliably for me. 14.24.59 # Sometimes the USB logo will remain when disconnected, and the player needs to be hard reset 14.25.19 # Last time it did this, I didn't notice. And it killed the battery dead :) 14.25.26 # Yes, I did see that yesterday, running from git with some mods of my own. 14.25.40 # My mods aren't related to USB. 14.25.47 # Torne: But I hear you. Thanks 14.27.02 # megal0maniac: feel free to try and get it enabled and try it out 14.27.21 # Torne: Heh. You overestimate my coding ability :P 14.27.31 # i am in fvour of it being enabled on any target that doesn't have either 1) a rom-based disk mode like the ipod or 2) too little space to make the bootloader larger for it 14.27.55 # purely so it can be used to recover from accidentally deleting .rockbox or whatever, without having to dualboot the OF 14.27.57 # Sounds like the Clip+ is the ideal target. 14.28.12 # Why is it enabled on the fuzeplus anyway? 14.28.24 # megal0maniac: no idea. possibly someone just wanted it during development 14.28.36 # the only target i know of where it's required is the Beast, where it's needed to install 14.28.43 # because the default firmware doesn't have MSC, only MTP 14.28.47 # and thus you can't copy .rockbox on there 14.29.02 # (possibly also other gigabeat devices, iunno) 14.29.33 # Interestingly, on the fuzeplus, it doesn't notice if you drop firmware.sb on it while in bootloader USB mode. You *have* to be in OF USB mode 14.29.41 # "doesn't notice"? 14.29.54 # oh, you mean it won't flash it 14.29.56 # no, of course not 14.30.08 # we don't have any of the code to reflash the device 14.30.11 # only the OF does 14.30.34 # But you can boot into OF and it still won't flash 14.30.47 # it probably only checks for the file after usb unplug 14.30.51 # not at boot 14.31.54 # I'll try copying it in bootloader mode, then going into OF USB mode and unplugging. I don't recall that working either, but I'll check 14.32.33 # i don't think we care 14.32.42 # what the OF's weird logic is doesn't really matter :) 14.33.08 # Yeah.. I think it's documented anyway. If not, I'll add it 14.33.32 # unless the OF's limitations actually cause a problem following our install instructions it's not really important 14.40.53 Join Prodicus [0] (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) 14.43.40 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 14.52.13 # n1s: I will take a look at comb_filter(). This function takes ~10% of CPU (based on the profiling results) and seems to have some opportunities for optimization 14.58.12 # see you later 14.58.15 Quit Buschel (Quit: ChatZilla 0.9.88.2 [Firefox 15.0.1/20120905151427]) 15.00.57 Quit mgottschlag (Ping timeout: 246 seconds) 15.03.50 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 15.05.53 Join wodz [0] (~wodz@89-76-32-53.dynamic.chello.pl) 15.06.44 # mortalis: both mutex version and semaphore version with your fix produce glitches. 15.07.15 # well semaphore version hangs on second lcd_update 15.11.35 # for me it hangs only on starting playback (semaphore version with my fix). Same thing happens with semaphore version with your fix. 15.13.55 # btw, what would happen if transfer complete when irq are disabled? Interrupt just skipped or it will trigger after irqs enabled? 15.14.13 # dunno 15.22.38 Join test [0] (~57ee5441@www.haxx.se) 15.24.06 Quit test (Client Quit) 15.25.12 # wodz: what if without partial updates? 15.26.11 # mortalis: you mean with lcd_update() as partial updates? 15.26.18 # yes 15.27.04 Quit factor (Ping timeout: 264 seconds) 15.27.50 # It does second lcd_update() with a glitch and hangs (it sits on rockbox logo which is displayed twice) 15.28.18 Join pystar89 [0] (~pystar89@ip-5-146-40-148.unitymediagroup.de) 15.29.40 # wodz: yes, we resample. it always outputs 48kHz 15.30.30 # n1s: So I guess we mitigate any quality advantage of opus with our current resampler :-) 15.33.57 # probably :) 15.35.33 Join kevku [0] (x@indeed.tastes.like.everything.mm.am) 15.50.35 *** Saving seen data "./dancer.seen" 15.52.58 Join japc [0] (~japc@194.65.5.235) 16.02.39 Quit japc (Quit: Ex-Chat) 16.08.17 Quit mortalis (Quit: Leaving) 16.31.15 Quit XavierGr (Ping timeout: 240 seconds) 16.33.00 Nick megal0maniac is now known as megal0maniac_afk (~root@dsl-244-148-217.telkomadsl.co.za) 16.39.45 Quit swiftkick (Read error: Connection reset by peer) 16.45.52 Join factor [0] (~factor@r74-195-187-142.msk1cmtc01.mskgok.ok.dh.suddenlink.net) 16.52.03 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 16.58.53 Quit Zagor (Quit: Clint excited) 17.04.51 Nick megal0maniac_afk is now known as megal0maniac (~root@dsl-244-148-217.telkomadsl.co.za) 17.13.04 Quit thegeek_ (Read error: No route to host) 17.13.30 Join thegeek [0] (~thegeek@171.17.9.46.customer.cdi.no) 17.16.20 Nick scorche` is now known as scorche (~scorche@rockbox/administrator/scorche) 17.33.43 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 17.43.22 Join Scr0mple [0] (~Simon@161.43.73.67) 17.45.47 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 17.46.52 Quit Scromple (Ping timeout: 244 seconds) 17.50.39 *** Saving seen data "./dancer.seen" 18.25.11 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 18.32.08 Join Wardo [0] (~Mirandaha@176-120-190-109.dsl.ovh.fr) 18.37.07 Join pedro_angelo [0] (~pedro_ang@201-29-245-101.user.veloxzone.com.br) 18.40.42 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 18.47.02 Join mortalis [0] (~4d6c62b1@www.haxx.se) 18.53.04 Join dfkt_ [0] (dfkt@unaffiliated/dfkt) 18.54.11 Quit dfkt (Ping timeout: 248 seconds) 18.56.04 Quit amayer_ (Quit: going ~/) 19.04.17 Part LinusN 19.04.21 Quit factor (Read error: Connection reset by peer) 19.06.44 Join factor [0] (~factor@r74-195-187-142.msk1cmtc01.mskgok.ok.dh.suddenlink.net) 19.13.18 Quit mgottschlag (Ping timeout: 246 seconds) 19.15.50 # mutexes doesn't work 19.15.56 # at least on rk27xx 19.16.23 # code after http://pastie.org/4810120 executed 19.17.50 Quit dfkt_ (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) 19.20.33 # mortalis: I think that's exactly the difference between a mutex and a 1-token semaphore 19.21.15 # the thread holding the mutex does not block on mutex_lock 19.23.06 Join dfkt [0] (dfkt@unaffiliated/dfkt) 19.25.06 # so second mutex_lock will block only if it called by another thread, rigth? 19.30.31 # the holding thread can call mutex_lock as many times as it likes, any other thread will block on it, the mutex will be available again if mutex_unlock is called exactly as many times as mutex_lock before it 19.34.09 Join LinusN [0] (~linus@giant.haxx.se) 19.36.59 Part LinusN 19.42.00 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 19.42.33 # mutexes are recursive indeed 19.47.32 Join amayer_ [0] (~alex@mail.weberadvertising.com) 19.50.42 *** Saving seen data "./dancer.seen" 19.57.18 Nick LittleCreature is now known as Slartibartfast (~fearofmus@unaffiliated/fearofmusic) 20.00.07 Join ender` [0] (krneki@foo.eternallybored.org) 20.01.55 Quit factor (Ping timeout: 248 seconds) 20.02.28 Nick Slartibartfast is now known as LittleCreature (~fearofmus@unaffiliated/fearofmusic) 20.04.06 Quit benedikt93 (Quit: Bye ;)) 20.04.47 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 20.19.34 Join pretty_function [0] (~sigBART@123.252.215.33) 20.22.54 Quit einhirn (Read error: Connection reset by peer) 20.28.12 Join Viper^ [0] (viper@c-60fd72d5.162-1-64736c10.cust.bredbandsbolaget.se) 20.31.04 Join Syconaut [0] (viper@c-60fd72d5.162-1-64736c10.cust.bredbandsbolaget.se) 20.36.34 # bertrik: have you seen reports about recent problems with rds? 20.36.45 # Anything could happen in the next 90 minutes [bookmark] http://www.kickstarter.com/projects/Musopen/open-source-bug-tracking 20.37.14 # vaguely 20.38.27 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 20.40.48 Nick megal0maniac is now known as megal0maniac_afk (~root@dsl-244-148-217.telkomadsl.co.za) 20.43.33 Nick megal0maniac_afk is now known as megal0maniac (~root@dsl-244-148-217.telkomadsl.co.za) 20.50.58 Join lorenzo92 [0] (~chatzilla@95.232.111.82) 20.52.02 # kugel: this is the trace, rockbox with debug symbols, bt command: http://pastebin.com/NZ72cpRD 20.59.56 # not very useful 21.01.58 Nick megal0maniac is now known as megal0maniac_afk (~root@dsl-244-148-217.telkomadsl.co.za) 21.02.16 Part megal0maniac_afk 21.08.11 # d 21.08.21 # wodz: some ideas to make it useful? need to say that I get a warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. 21.11.04 Quit ser (Remote host closed the connection) 21.12.30 Quit shai (Ping timeout: 244 seconds) 21.12.40 # wodz: I updated g306. It's works for without any issues, also i removed some unnecessary things. 21.12.41 # 3Gerrit review #306 at http://gerrit.rockbox.org/r/306 : rk27xx lcd code rework by Andrew Ryabinin (changes/06/306/6) 21.13.31 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 21.13.38 # *for me 21.13.59 # wodz: trying to do coredump and the analysis.. 21.19.03 # mortalis: So no locking at all, right? You simply poll for dma finish bit 21.20.08 # yes 21.20.57 # kugel: http://pastebin.com/uPTf0Cip ; to show the segmentation fault... 21.22.33 # mortalis: Will test tomorrow morning 21.23.27 Quit wodz (Quit: Leaving) 21.24.01 Quit y4n (Quit: only amiga makes it possible) 21.28.58 Join ser [0] (~ser@2610:28:3090:3001:a:a:a:dead) 21.32.15 # kugel: 0x00056f08 is lcd_alpha_bitmap_part_mix, while 0x00056e90 is something in the function around line 895 21.34.35 Quit mortalis (Quit: CGI:IRC (Ping timeout)) 21.35.37 # kugel: :o :o doesn't crash if I keep the player running in the main menu, I'll try now with another theme (cabbie, previously using lebellium's theme!) 21.36.08 # kugel: oh! strange characters...no crash but strange carachters at a times... 21.36.25 # i'll get a capture 21.36.28 # *picture 21.38.09 # lebellium: yep, exactly the same issue as for the sansa or so... 21.39.20 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 21.39.29 # lebellium: rds on R0 crashes with segmentation fault with your theme 21.39.38 Join Buschel [0] (~chatzilla@p57905E53.dip.t-dialin.net) 21.48.27 # kugel, lebellium: definitely. Problems with lebellium's theme! without it, I don't notice anything strange. Now I'll try with the interrupt way of capture signal packet arrived... 21.50.34 # It's always my theme's fault on any target. Damn it :( 21.50.46 *** Saving seen data "./dancer.seen" 21.51.30 Quit shamus (Read error: Connection reset by peer) 21.51.59 # lebellium: too much professonal :p ;) 21.53.56 Join shamus [0] (~shamus@ip-206-192-195-49.marylandheights.ip.cablemo.net) 21.56.28 # kugel: indeed, with cabbie works perfectly also the interrupt way, no problems at all. Hence, semaphores are working also on R0 apparently 21.57.15 Quit ender` (Quit: And I don't offend religious people, they offend themselves. -- Markus Persson (notch)) 22.02.34 Quit pedro_angelo (Remote host closed the connection) 22.04.05 Join ender` [0] (krneki@foo.eternallybored.org) 22.06.21 Join Horscht [0] (~Horscht@p54946283.dip.t-dialin.net) 22.06.24 Quit Horscht (Changing host) 22.06.24 Join Horscht [0] (~Horscht@xbmc/user/horscht) 22.11.34 # my theme seems to cause various issues on many targets including Clip Zip, Fuze, Fuze+, R0 etc... anyone willing to investigate a bit further?. The only difference I see with the other themes is that the code is generally more complicated and the BMP resources may be bigger. But it should work :( 22.13.40 # lebellium: what is your theme and target(link?) 22.13.42 # i dont have time right now but i might later tonight 22.15.54 # Just type "lebellium Samsung-like" as theme name on http://themes.rockbox.org/ and you'll find 6 themes. They all cause various issues, typically USB connection (Clip Zip and also Fuze+ I guess), and now RDS on Clip Zip and R0? 22.16.49 # As if my code always reached the skin engine or rockbox limitations? :( 22.17.25 # what is rds? 22.18.02 # Radio Data System 22.18.15 # got it. thats what google said but i wasnt sure 22.18.16 # supported by Clip Zip/ Fuze+ and R0 22.19.43 # so it only breaks on the RDS or breaks ramdomly? 22.21.38 # Lorenzo just said it breaks on the RDS with the R0. I can't try myself as he's currently working on the RDS patch, therefore I don't have RDS on my R0. 22.21.50 # yet* 22.22.42 # and the USB connection still doesn't work on the Clip Zip with my theme. The situation has not changed over the year :( 22.23.38 # lebellium: USB connection????!!! 22.23.50 # lebellium: I got some crashes with usb too -.- 22.24.48 # blasted theme, it's so frustrating... 22.25.17 # I don't know for USB, will test out. Don't think that's about you're theme 22.25.18 # ;) 22.27.30 # lorenzo92: are sure you have all the correct fonts loaded(not all of them are included in the font folder) 22.28.58 Quit pretty_function (Remote host closed the connection) 22.29.06 # without the correct fonts, Rockbox immediately crash so that's not the cause ;) 22.30.01 # so your theme is being displayed in RDS then it crashes? 22.31.20 # that's what Lorenzo noticed indeed 22.31.30 # not correctly, it crashes after a little time, say 1 minute or so 22.31.51 # hmm... does the theme engine have a specific amount of memory it can use? 22.32.14 # amayer_: I don't know anything about that, but I'm quite sure the segfault happens in lcd_alpha_bitmap_part_mix 22.32.17 Quit eckoit (Quit: eckoit) 22.32.21 # (gdb) 22.33.14 # lebellium: are all your themes exactly the same? 22.33.16 # i noticed they have v1.xx 22.33.18 # what is the resolution of the device in question? 22.33.48 # I find your question quite strange :) 22.33.55 # seperate topic: 22.33.57 # should RDS be in http://www.rockbox.org/wiki/ProjectGlossary ? 22.34.11 # lebellium: how so? 22.34.28 # lorenzo92: the bt suggests debug symbols aren't proper 22.34.35 # type "lebellium samsung-like" as theme name on the theme page and then it will display the 6 themes with the indication "designed for LCD size: " 22.34.39 # properly compiled in 22.35.32 Join Prodicus_ [0] (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) 22.35.36 # kugel: okay, anyways my implementation works ... the bug is somewhere else :) so final question: it's better the implementation with interrupt or the one with register polling? I guess the first, right? 22.35.41 # there's probably a bug in the radio/rds related skin code. I don't think it received a lot of testing 22.35.44 Quit Prodicus (Ping timeout: 252 seconds) 22.35.57 Nick Prodicus_ is now known as Prodicus (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) 22.36.10 # amayer_: RDS isn't a rockbox term. It's quite commonly used... 22.36.20 # normally yes, but I think its not safe at the moment 22.36.47 # Feel free to add it if you like though 22.37.09 # lorenzo92: ^ 22.37.12 # lebellium: i did that. 22.37.14 # but all your themes say they are different versions.(v1.00, 1.50, 1.30,...) 22.37.16 # im wondering if they are all exactly the same, or if they each different features. 22.37.18 # the theme page doesnt tell me what the target is. so thats why i asked for the resolution of the device that is actin up 22.37.26 # s/actin/acting/ 22.39.50 Join factor [0] (~factor@r74-195-187-142.msk1cmtc01.mskgok.ok.dh.suddenlink.net) 22.40.19 # lorenzo92: do you know in which context the callback is called by the kernel? I guess its like a signal handler, I.e. the process current stack is used? 22.41.14 # they are not exactly the same of course but they share many features, the code is more or less similar on each target. The different version number is just because they have not been made at the same time. The new clip+ theme I made yesterday includes features in v1.00 that the Clip Zip had to wait for v1.30 to get as the 1st version was made last year ;) 22.42.09 # the Clip Zip has a 96*96 display and the R0 has a 240*320 display 22.42.25 # kugel: well safe or not, it hasn't crashed for more than 10 mins. anyways that doesn't tell us anything :) the callback is the address of the function in rockbox 22.42.50 # at first I used also a workqueue of linux kernel, don't know precisely how does it work 22.42.59 # now I tried to remove it and works anyways 22.43.16 # the callback releases the semaphore only! 22.43.16 # did you modify the kernel module? 22.43.19 # yep 22.43.36 # kugel: do you want to see the code? 22.43.56 # with polling that wouldn't be necessary right? 22.44.08 # sure 22.44.11 # kugel: exactly! 22.44.33 # maybe it's better, need to see from the cpu usage point of view, but it's surely around 2% more 22.44.37 # nothing important then 22.44.43 Join eckoit [0] (~ryan@96.53.108.182) 22.45.16 # you wouldnt need to poll every tick would you? 22.45.36 # * kugel doesnt know anything about RDS, e.g. how often new data comes in 22.45.39 # kugel: nono! it's just every sleep(1) for the moment 22.45.47 # I'll explain 22.46.09 # si4709 radio module gpio pin goes to low for at least 5 ms when data is ready to be read 22.46.26 # either using the interrupt or using register poll I guess 22.46.41 # need to see the doc for that 22.47.58 # how many seconds are sleep(1), you think? 1/100? 22.48.27 Join XavierGr [0] (XavierGr@rockbox/staff/XavierGr) 22.48.55 # the parameter is in ticks, so yes 1/100 22.50.19 # can you post the new kernel module code somehwere nevertheless? I want to see how the callback mechanism works 22.50.20 # technically it's at least 1 22.50.28 # well, 1 to almost 2 22.50.36 # n1s: thanks :) 22.50.45 # kugel: yes, of course!! 22.52.06 # kugel: perhaps it's a little naive, but works ^^ http://pastie.org/4811270 22.52.22 # kugel: notice that I've just removed workqueue, commented! 22.53.05 # lorenzo92: uh oh, I'm surprised this works 22.53.21 # I dont think it would on x86 or newer ARM architectures 22.53.34 # kugel: ah! xD nice to know hehe 22.53.52 # kugel: is the function calling evil, right? 22.54.12 # normally you cannot (and shouldn't) use user-space pointers directly 22.54.56 # I've tought about that, but then another possibility is? 22.55.27 Join lebellium_ [0] (~chatzilla@g231191239.adsl.alicedsl.de) 22.56.45 # it's evil for 2 reasons; a) the callback is executed in kernel space (i.e. it could possibly access kernel internals and mess the entire kernel up) and 2) kernel-space and user-space pointers are incompatible (user-space pointers are usually virtual addresses, other measures might be applied too) and cannot be derefenced directly 22.57.11 # kugel: clear, indeed. 22.57.23 Quit lebellium (Ping timeout: 244 seconds) 22.57.37 Nick lebellium_ is now known as lebellium (~chatzilla@g231191239.adsl.alicedsl.de) 22.57.41 # kugel: I copied the way structs are sent through ioctls 22.57.48 # I don't know if there's any possibility to execute userspace code other than through signals 22.58.01 # oh well right copy_from_user 22.58.12 # perhaps this does something? 22.59.13 Quit liar (Ping timeout: 256 seconds) 22.59.38 # it at the very least converts the user-space pointer to kernel space; but the arg parameter, not the data arg points to 23.00.01 # you pass the function address as data so I don't expect it gets fixed 23.00.38 Quit kevku (Ping timeout: 260 seconds) 23.00.57 Join kevku [0] (x@indeed.tastes.like.everything.mm.am) 23.01.03 # okay. perhaps there are other tecniques like event devices (or how they're called), more suitable. I understood that I need to cleanup the register polling way :D 23.02.27 # lebellium: one thing I'm missing: is your device displaying bad data also with cabbie/other themes? 23.03.32 # i think the simplest for now is keeping the polling, perhaps at a lower rate 23.03.53 # yes, I think sleep(10) or greater is enough! 23.03.55 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 23.04.02 # but 23.04.26 # the way I'm getting the register isn't nice...can I do something on the si470x header file? 23.04.38 # perhaps externalizing register getting/setting 23.06.42 # i.e. writing prototype in the header ^^ 23.08.37 # I would also disable the interrupt! 23.09.40 Quit amayer_ (Ping timeout: 264 seconds) 23.09.42 Quit liar (Remote host closed the connection) 23.15.26 # lorenzo92: on the clip zip the dfkt theme also displays bad RDS data. I did not try other themes 23.15.56 # lebellium: okay, good to know, perhaps try also with cabbie when possible... 23.16.30 # kugel: do you think creating a new thread and destroying it when enabling/disabling radio is good or not? 23.17.03 # I guess there is no cabbiev2 FMS on the clip zip 23.17.12 # you can set it to sleep forever when radio is disabled 23.18.03 # lorenzo92: what do you mean with the way you get the registers? 23.18.31 # ah right you did not see the code... 23.21.03 # kugel: to explain. si4700_read_reg is available within si4700.c code, the prototype isn't in the header file si4700.h. I put it in the header file to access the function from my target code! 23.23.09 # you call si4700_rds_read_raw() 23.23.38 # kugel: ah no, nevermind...found out ;) 23.27.14 # ??? 23.28.13 # kugel: nothing nothing, don't care :) 23.35.43 # well, alright :) 23.37.52 Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) 23.41.53 # kugel: btw, do you still have the R0 device? :) 23.44.05 # sure 23.44.12 # kugel: cpu usage okay, seems working fine. Good for R0 ;) 23.45.38 # kugel: apart screen corruption, happens sometimes 23.50.47 *** Saving seen data "./dancer.seen" 23.50.48 # lorenzo92: i hope to see a patch on gerrit soon :) 23.54.58 # lorenzo92: which skin tag is causing the trouble? 23.55.21 # lebellium: ? 23.55.26 # we just did a test 23.55.47 # it seems that %tz (RDS text) is causing issues 23.56.07 # Need further testing but %ty (RDS name) should be OK 23.57.39 # strange. the %tz code directly calls a low level function which returns the string from a static array 23.58.27 # isn't that perhaps a string isn't \x00 ending?