--- Log for 15.05.110 Server: jordan.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 8 days and 12 hours ago 00.00.03 # dfkt: do you think rockboxed clip+ has lower volume than clipv1 ? 00.00.11 # gevaerts: Just for my own edification, is this sort of problem in Cygwin itself, or a consequence of compiling with MinGW, or what? I'd like to know better what's going on behind the scenes. 00.00.53 # funman, lower than rockboxed clipv1? i will check 00.01.08 # New commit by 03gevaerts (r26030): Move include/sys along with libc/, so hosted (sim/RaaA) builds use the proper files for their OS 00.01.39 # Blue_Dude: no, just the includes being messed up 00.01.42 # New commit by 03funman (r26031): fuzev2: prevent button light flickering when accessing µSD 00.01.51 # That's not the only problem unfortunately, there seems to be more 00.02.10 # FlynDice: fyi, we can modify B5 just after MCI_COMMAND has been written (it's fast enough to not see the flickering) 00.03.42 # gevaerts: Just curious why it showed up for my build but not on the build server. 00.04.10 Join polobricolo [0] (~polobrico@AGrenoble-257-1-31-224.w86-194.abo.wanadoo.fr) 00.05.15 # Blue_Dude: is "system headers are messy and unpredictable" good enough? ;) 00.05.30 Join Schmogel [0] (~Miranda@p3EE2230E.dip0.t-ipconnect.de) 00.05.57 # I think no-one is running a build client on cygwin 00.06.29 # What are bmp2rb_mono and bmp2rb_native in the configure file ? 00.06.31 # New commit by 03Buschel (r26032): Fix FS#11261 (slow seek forward in mpc files). Since the introduction of the sv8 library mpc did not use efficient buffering when seeking forward. ... 00.12.33 # gevaerts: that's as good an explanation as any. :) 00.12.59 # New commit by 03funman (r26033): cast ssize_t to long 00.15.12 Join Kitr88 [0] (~Kitar_st@BSN-143-96-93.dial-up.dsl.siol.net) 00.16.41 # New commit by 03funman (r26034): another cast ssize_t -> long 00.17.09 # * gevaerts thinks that more coordination is needed :\ 00.17.40 Quit Kitar|st (Ping timeout: 248 seconds) 00.18.06 # funman: please warn if you're going to fix things that someone else has just caused. Changing a file, test-compiling, and then getting commit errors is no fun 00.18.22 # sorry 00.18.25 # especially if your fix is wrong 00.18.38 # is it? 00.19.29 # well, it's not the best fix anyway 00.19.31 Quit Kitr88 (Ping timeout: 240 seconds) 00.19.36 Join Kitar|st [0] (Kitar_st@BSN-182-127-162.dial-up.dsl.siol.net) 00.19.49 # New commit by 03gevaerts (r26035): Fix various size_t related warnings and errors 00.20.00 # printf has modifiers for size_t 00.20.14 # i checked rockbox' format.c for %z but it's not there 00.20.42 # hm 00.21.15 # These are all in DEBUGF(), so it might not matter 00.21.26 # The problem is that size_t can have various sizes 00.21.44 # Thought size_t was an unsigned int. 00.21.46 # true, but here it was used together with (unsigned) longs 00.21.59 # Agh. 00.22.03 # Blue_Dude: no. It might be, but it's not always 00.22.06 # Blue_Dude: not on 64bits i think where int is 4 bits 00.22.09 # 4 bytes* 00.22.27 # Int seems to be 4 bytes anyway. 00.22.28 # gevaerts: isn't DEBUGF usable over (usb) serial ? 00.22.36 # Same size as long. 00.22.38 # I think. 00.22.46 # Depends. 00.22.53 # Sigh. 00.23.17 # Blue_Dude: exactly. That's why they added the %z thing :) 00.24.20 # Yeah. All things considered I like fixed size types for bit twiddling. 00.24.40 # New commit by 03gevaerts (r26036): Hopefully the last warning 00.24.55 # gevaerts: debugf() use rockbox formats with HAVE_GDB_API 00.25.12 # or SH debug (but who uses SH) 00.25.44 # funman: hm, right. There are other %zs already though (but not since very long) 00.26.03 # I'd actually say that implementing %z is the right fix if this is a real problem 00.26.35 # Now the rest of the mingw errors... 00.27.15 # Warning in codecs/flac.c line 505... 00.27.58 # But it compiles so far. 00.29.49 # More warnings, all the same. 00.30.45 # Yeah, they're LOGF format string mismatches. 00.31.32 Join halmi [0] (~netbook@80-123-32-141.adsl.highway.telekom.at) 00.32.04 # gevaerts: http://pastie.org/961075 00.32.15 # building under cygwin still quits with error 00.32.34 # (ps sim only) 00.32.38 # *pc 00.32.41 # funman: exactly, not very big, obviously correct, and solves a lot of problems :) 00.33.17 # After that someone needs to go over all the casts to check if they're really needed of course 00.33.23 Join joeyg [0] (~apoelstra@S010600236999fec1.vs.shawcable.net) 00.33.35 # i know someone who would really like to do that 00.33.38 # Someone* 00.34.03 # "warning: format ‘%zd’ expects type ‘signed size_t’, but argument 6 has type ‘ssize_t’ 00.34.15 # You just can't win! 00.34.18 # hum 00.34.24 # haha, how about ptrdiff_t? 00.34.50 # * gevaerts ignores that warning! 00.35.17 # Agh. Back in a while. Maybe we oughta just put a cast on all of them and be done with it. 00.35.32 # Just a thought. Lots of work though. 00.35.50 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 00.37.20 Quit Buschel (Ping timeout: 260 seconds) 00.37.41 Quit funman (Quit: free(random());) 00.38.29 Quit cdb (Ping timeout: 276 seconds) 00.39.17 Quit merbanan (Ping timeout: 276 seconds) 00.45.37 Part toffe82 00.51.38 Quit petur (Quit: router upgrade) 00.54.19 Quit stripwax (Ping timeout: 240 seconds) 00.54.38 Join Forsaken_Boy [0] (~chatzilla@24.138.199.192) 00.57.33 Quit bertrik (Remote host closed the connection) 00.57.54 # New commit by 03gevaerts (r26037): Make the sim buildable with mingw again 01.01.30 Join petur [0] (~petur@rockbox/developer/petur) 01.01.43 # Blue_Dude: can you check if it also works for you? 01.04.55 Quit pamaury (Ping timeout: 252 seconds) 01.06.15 Join solexx [0] (~jrschulz@e176104138.adsl.alicedsl.de) 01.09.04 Quit solexx_ (Ping timeout: 260 seconds) 01.23.15 Quit ender` (Quit: Inside every cynical person, there is a disappointed idealist. -- George Carlin) 01.26.29 Quit petur (Quit: Zzzzz) 01.26.36 Join Strife89 [0] (~Strife89@adsl-67-49-42.mcn.bellsouth.net) 01.31.29 Quit flydutch (Quit: /* empty */) 01.37.26 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 01.38.30 Join bluefoxx [0] (~FuzzyLomb@S0106000347a5e69e.vs.shawcable.net) 01.46.05 Quit jd (Read error: Connection reset by peer) 01.47.31 Quit Schmogel (Ping timeout: 240 seconds) 01.50.31 *** Saving seen data "./dancer.seen" 02.00.28 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 02.01.56 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 02.03.22 Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) 02.05.18 Quit DerPapst (Quit: Leaving.) 02.06.39 Quit kisak (Ping timeout: 245 seconds) 02.11.19 Join kisak [0] (~kisak@c-98-235-209-218.hsd1.pa.comcast.net) 02.12.14 Quit halmi (Ping timeout: 276 seconds) 02.18.16 Join ollebe [0] (~olle@root.rot.sgsnet.se) 02.19.39 Join Rob2223 [0] (~Miranda@p4FDCAEA1.dip.t-dialin.net) 02.23.00 Quit Rob2222 (Ping timeout: 246 seconds) 02.29.25 Join merbanan [0] (~banan@c-94-255-217-84.cust.bredband2.com) 02.33.21 Quit n1s (Quit: Lämnar) 02.37.21 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 02.51.47 Quit merbanan (Ping timeout: 248 seconds) 02.56.22 Join huelk_ [0] (~huelk@dtmd-4db7991f.pool.mediaWays.net) 02.59.56 Part Boldfilter 03.00.07 Quit huelk (Ping timeout: 265 seconds) 03.04.04 Join ischeriad [0] (~ischeriad@p5B0A11E3.dip0.t-ipconnect.de) 03.06.38 Quit ischeria1 (Ping timeout: 240 seconds) 03.08.37 Quit Forsaken_Boy (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 03.12.06 # oh ... topic / http://www.rockbox.org/wiki/DevConEuro2010 conflict ... is it Ghent or Gent? 03.18.12 Join intrados [0] (~intrados@adsl-99-22-68-153.dsl.wotnoh.sbcglobal.net) 03.18.26 Quit togetic (Quit: WeeChat 0.3.0) 03.27.18 Quit powell14ski (Ping timeout: 240 seconds) 03.33.22 Join powell14ski_ [0] (~powell14s@c-24-9-7-198.hsd1.co.comcast.net) 03.35.09 Quit GeekShadow (Quit: The cake is a lie !) 03.39.52 Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) 03.40.47 # gevaerts: Sorry to vanish like that. Anyway, it compiles, but I do get warnings. I have logf enabled for my sim build, so that's why I'm getting those warnings. 03.44.15 Join TillW [0] (~Till@CPE0018395fb63b-CM00195ee38f2c.cpe.net.cable.rogers.com) 03.44.36 Quit TillW (Client Quit) 03.45.00 Join CGL [0] (~CGL@190.207.156.230) 03.50.32 *** Saving seen data "./dancer.seen" 03.54.22 Quit adnyxo (Quit: Leaving) 03.57.33 # New commit by 03Blue_Dude (r26038): Fix logf lines in codecs (type mismatches) 03.59.29 Join ischeria1 [0] (~ischeriad@p5B0A21F6.dip0.t-ipconnect.de) 04.03.26 Join Forsaken_Boy [0] (~chatzilla@24.138.199.192) 04.03.30 Quit ischeriad (Ping timeout: 276 seconds) 04.04.35 Join anewuser [0] (anewuser@unaffiliated/anewuser) 04.09.21 Quit Forsaken_Boy (Read error: Connection reset by peer) 04.12.06 Quit TheSeven (Ping timeout: 240 seconds) 04.15.32 Join Boldfilter [0] (~Boldfilte@adsl-82-77-225.jax.bellsouth.net) 04.16.21 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.17.44 # Found other problems in some plugins. warning: signed size_t format, ssize_t arg. Well. 04.18.05 # That won't be fixed with a cast. 04.20.01 # Unless, casting a ssize_t to signed size_t makes sense. 04.20.18 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.20.18 Quit pixelma (Disconnected by services) 04.20.23 Quit amiconn (Disconnected by services) 04.20.24 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.20.33 Join stormdragon2976 [0] (~stormdrag@137.118.186.73) 04.20.38 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.20.44 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.21.05 # Hi 04.23.19 # I wrote a bash script in Linux to generate .talk files. I found out only after finishing the script that the files aren't just MP3s with modified extentions. Does anyone know a command line way to generate the files? 04.24.10 # Preferably using sox? 04.26.00 # Nope, a cast to "signed size_t" doesn't work at all. 04.29.16 # All the lines I can't fix with a cast use "%zd" in them. I can change that but it won't fix the formatting problem in the library. 04.33.30 Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 04.36.03 # stormdragon2976: on most devices the talk files are speex, not mp3 04.36.15 # the makefile should be able to generate them for you, or you can use rbutil to do it 04.41.13 Join zak1111 [0] (~zak@adsl-71-147-38-80.dsl.emhril.sbcglobal.net) 04.41.36 Part zak1111 04.42.28 # The Utility doesn't work with Orca (the screen reader for Gnome) It's written in qt4 I think, and Orca doesn't work with QT apps. 04.42.53 # Unless there's a commandline way to do it? 04.44.58 # yes, the makefile 04.45.18 # awesome 04.45.54 # How would I use it? 04.47.44 # same way as making a normal rockbox build, except select "voice" as the build type in the configure script instead of "normal" 04.48.51 # Lol I am behind in the learning process. I bought my player with Rockbox pre-installed. 04.49.46 Join dys` [0] (~andreas@krlh-5f72c56f.pool.mediaWays.net) 04.52.05 Quit dys (Ping timeout: 276 seconds) 04.54.47 Join zak1111 [0] (~zak@adsl-71-147-38-80.dsl.emhril.sbcglobal.net) 04.55.35 Part zak1111 04.55.46 Quit Barahir (Ping timeout: 240 seconds) 04.57.39 Join Barahir [0] (~jonathan@frnk-590fc3e7.pool.mediaWays.net) 04.57.57 # stormdragon2976: if you're just running stock rockbox, then maybe its easiest to just use our voice files 04.58.53 # Maybe so, but I would like to be able to have the song and folder names read instead of spelled. I am only one step away from making that happen. 04.59.11 # If only sox supported speex files lol 04.59.16 Part Boldfilter 05.03.56 Join togetic [0] (~togetic@c-71-228-184-130.hsd1.al.comcast.net) 05.03.58 Quit togetic (Changing host) 05.03.58 Join togetic [0] (~togetic@unaffiliated/ibuffy) 05.05.39 # More logf drama: /rockbox/firmware/logf.c:216: warning: implicit declaration of function `vuprintf' 05.16.22 # I think I found the answer. There is a speex encoder in the Ubuntu repository. 05.17.14 # New commit by 03Blue_Dude (r26039): Fix include problem 05.20.15 # Blue_Dude: have you seen FS#11270 - PictureFlow - WPS Integration patch 05.20.21 # it looks vaguely related to hotkeys 05.20.37 # I haven't. I don't even know what pictureflow is. 05.20.57 # its a plugin that lets you browse albums via their album art instead of pure text menus 05.21.08 # its semi-integrated into the actual gui 05.23.34 # Hm. 05.24.46 # i only mention it to you because it talks about hotkeys 05.25.40 # I grabbed the word hotkey out of thin air. 05.25.48 # Does it mean the same thing there? 05.34.32 # New commit by 03Blue_Dude (r26040): Eliminate %zd tag in printf format strings, replace them with %ld. The %z formatter kept generating type mismatch warnings. 05.42.41 # New commit by 03Blue_Dude (r26041): Fix yellow: missed a cast 05.47.08 # New commit by 03Blue_Dude (r26042): vuprintf does not belong in stdio.h, causes problems with other versions of stdio.h 05.48.15 # I feel like the sim police tonight. 05.48.20 Join rasher [0] (~rasher@rockbox/developer/rasher) 05.48.43 # That should be the last compile warning though. 05.50.34 *** Saving seen data "./dancer.seen" 05.51.23 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 05.52.05 Quit ollebe (Quit: Leaving) 05.52.15 Join RankFrank [0] (~rankfrank@ip24-253-23-120.lv.lv.cox.net) 06.01.24 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 06.01.45 Quit kramer3d (Ping timeout: 240 seconds) 06.05.04 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 06.08.59 Join Forsaken_Boy [0] (~chatzilla@24.138.199.192) 06.11.12 Quit kenguest (Read error: Connection reset by peer) 06.14.08 Join umrain [0] (~umra_n@pool-71-127-239-226.nwrknj.east.verizon.net) 06.17.00 Nick umrain is now known as umrain_ (~umra_n@pool-71-127-239-226.nwrknj.east.verizon.net) 06.17.25 Nick umrain_ is now known as umrain (~umra_n@pool-71-127-239-226.nwrknj.east.verizon.net) 06.17.49 Join kenguest [0] (~radagast@lir.talideon.com) 06.21.18 Quit leavittx (Remote host closed the connection) 06.29.15 # Do the speex files have to be a specific bitrate? 06.30.30 Quit arbingordon (Quit: `) 06.31.20 Join zak_ [0] (~zak@adsl-71-147-38-80.dsl.emhril.sbcglobal.net) 06.31.32 Quit zak_ (Remote host closed the connection) 06.33.59 Quit kramer3d (Quit: This computer has gone to sleep) 06.36.06 # stormdragon2976: see this link: http://www.rockbox.org/wiki/VoiceHowto#Automated_generation_of_talk_cli 06.36.22 # the tools take care of things like that automatically 06.37.13 # hmm though thats Windows only if that matters 06.42.22 # I don't have access to a Win box. 06.47.19 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 06.52.03 Quit anewuser (Quit: for SELL 2 by the price of 1 now!) 06.59.26 # New commit by 03jethead71 (r26043): wm8978: Clean out silly macros. Use 'POS' convention instead for shifted bitfields. Additionally, use volume update latching for all volume settings. 07.00.14 # Any usb experts here? 07.00.37 Join arbingordon [0] (~w@unaffiliated/arbingordon) 07.00.53 # I'm getting the config request from the host, pass that on to the usb_core, and try to send the response back. 07.01.26 # I can see that the response is received by the host, but something is wrong on a low level. 07.01.58 # Somehow the receive seems to timeout (5 seconds), but still gets the data correctly. 07.02.16 # But since it timed out or so the host ignores the data it got. 07.02.36 # this is on AMS? 07.02.51 Quit arbingordon (Client Quit) 07.02.52 # Yeah 07.03.57 # ah didn't realize you were working no that :) 07.04.53 # I've been working on that since thursday :) 07.07.16 # http://pastebin.com/FLARbgc6 07.07.17 Quit evilnick (Read error: Connection reset by peer) 07.07.18 # whats actually involved in porting a new USB controller to the current stack? 07.07.43 Join evilnick [0] (~Evilnick@ool-457bccf5.dyn.optonline.net) 07.07.44 # i guess at the high level some kind of send and recv functions, but I'm guessing USB is a little more complicated then that 07.08.19 # Well most of the low-level stuff is handled by the controller. 07.08.28 # The main problem is figuring out how the controller works. 07.09.39 # Receiving packets was the easy part. Getting it to send was a bit more tricky and obviously something is still going wrong. 07.19.57 Quit BHSPitMonkey (Quit: Ex-Chat) 07.20.54 Join Horschti [0] (~Horscht2@xbmc/user/horscht) 07.21.21 Quit Horscht (Ping timeout: 268 seconds) 07.21.37 Quit CGL (Ping timeout: 240 seconds) 07.25.21 Quit Xerion (Quit: ) 07.29.36 Join Schmogel [0] (~Miranda@p3EE22109.dip0.t-ipconnect.de) 07.29.50 Nick dys` is now known as dys (~andreas@krlh-5f72c56f.pool.mediaWays.net) 07.36.06 Join CGL [0] (~CGL@190.207.156.230) 07.40.28 Join mikroflops_ [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) 07.44.59 Quit mikroflops (Ping timeout: 276 seconds) 07.46.25 Quit Forsaken_Boy (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 07.50.00 Quit huelk_ (Ping timeout: 240 seconds) 07.50.38 *** Saving seen data "./dancer.seen" 08.00.31 Join Highlander [0] (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) 08.05.30 Join Buschel [0] (~ab@p54A3BDCB.dip.t-dialin.net) 08.14.41 # lol my computer recognizes and can play these .talk files but they still aren't working on the MP3 Player. 08.15.22 # I am using a speex encoder and still no luck. 08.19.04 # stormdragon2976: if your computer can play them, then they're probably not in the right format 08.19.23 # i don't think anything outside of rockbox will decode rockbox formated speex files 08.19.34 # though i'm not certain how this works 08.19.49 # * S_a_i_n_t suggests using VoiceBox in a VM 08.20.00 # (if you're not on a WinSys) 08.21.03 # "On Archos players, .talk files are normal MP3 files. On other players, they are in a Rockbox-specific Speex format produced by the rbspeexenc utility, which is distributed with Rockbox." 08.21.07 Quit joeyg (Ping timeout: 252 seconds) 08.22.28 # ahh, I'll go find that. 08.22.35 Join joeyg [0] (~apoelstra@S010600236999fec1.vs.shawcable.net) 08.27.19 Quit saratoga (Quit: Page closed) 08.33.25 Quit Buschel (Ping timeout: 260 seconds) 08.33.36 Quit Schmogel (Ping timeout: 240 seconds) 08.36.41 Join zak1111 [0] (~zak@adsl-71-147-38-80.dsl.emhril.sbcglobal.net) 08.39.26 Quit CGL (Remote host closed the connection) 08.39.36 Part stormdragon2976 ("Leaving.") 08.41.33 Join ssorgatem [0] (~ssorgatem@83.54.169.89) 08.49.33 Quit joeyg (Quit: lions and tigers and bears, oh my!) 08.54.50 Join flydutch [0] (~flydutch@host138-162-dynamic.14-87-r.retail.telecomitalia.it) 08.55.41 Quit Strife89 (Quit: Bed.) 09.10.29 Quit RankFrank (Ping timeout: 245 seconds) 09.13.26 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 09.16.41 Join RankFrank [0] (~rankfrank@ip24-253-23-120.lv.lv.cox.net) 09.29.54 # or he could just use the Rockbox Utility... (regarding the .talk files generation) 09.36.25 # ok, just read his problem using the Utility because of the Orca screenreader 09.36.41 # +about and +sorry 09.37.46 Part zak1111 ("Leaving") 09.50.40 *** Saving seen data "./dancer.seen" 09.51.26 # I recently had the idea to make the "Now playing" in cabbiev2 a text string, adding it to the lang files so it is possible to localise it (and use something else for e.g. the radio screen etc.). The problem is that it could only be a smaller font which probably won't have a lot of non-latin characters and can't have. Would it be acceptable to add a comment for the translators "Leave it untranslated if your string can't be displayed with small-font 09.51.26 # -of-choice"? 09.54.38 # then it will stay as it is for those in the WPS and still will be more flexible for use in the radio screen, or the menus if someone attempts an SBS. 09.57.50 Join webguest79 [0] (~43aa7d5a@giant.haxx.se) 09.59.34 # hello...? 09.59.55 Quit webguest79 (Client Quit) 10.05.52 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 10.06.41 # JdGordon: In your new WPS format, how many tags are there with optional parameters at the beginning of the list? 10.07.03 # 2 or 3? 10.07.15 # we can make it 0 if you would prefer? 10.07.31 # That would definitely make things a lot easier to parse 10.07.56 # ok, so totally forget about optionals for now... 10.08.04 # Okay 10.08.37 # They're easy enough if they come at the end of the list, it just gets really hard to discern what's what if they can come at the beginning or the end 10.09.25 # fair enough 10.10.33 # So for the tag specifications, I'll leave out the ?, and just keep the | to mark the beginning of optionals, along with prefixed numbers to specify groups of the same type 10.11.10 # I'll add a patch with what I've got so far to FS before I go to sleep 10.11.17 Join Orion7 [0] (~IceChat7@c-71-204-140-208.hsd1.ca.comcast.net) 10.11.59 # how far have yoiu got? 10.13.23 # Right now, it can reliably assemble a parse tree from plaintext, comments, and newlines, and I've got as far as retrieving the param list for a tag name, but I've been stalled trying to figure out how I'd do those optional params :P 10.14.44 # And while the code to parse them isn't there yet, it does recognize when there are sublines coming, so that will be straightforward once I've got the tag function finished 10.14.46 # depends how you pass the params in... I was thinking just split up the param list and determine if the optional one is there based on the number of params listed 10.15.15 # That works for simple cases, but the problem comes when you have, say, one optional at the beginning and two optionals at the end 10.16.09 # And then if the end optionals don't have to be grouped together, you have to analyze the types of the parameters to figure out which one is going to be the optional 10.16.22 # leave that to the tag handler 10.17.15 # So you don't want me to check types at all? 10.17.56 # its up to you, of course I'm happy to say that optionals must be at the end also 10.18.52 # Lets just go with optionals at the end, then. That'll give some more useful debug output from the parser 10.25.42 # jhMikeS: you have to be in the recording screen to record? 10.28.46 # Added a comment with new patch to FS#11265, I'm done for the day 10.30.25 # Do comment if you spot any bugs, or have comments on architecture 10.30.38 # ill have a look if i get a chnace toinght 10.31.38 # Don't worry too much about it if you don't, hopefully I'll have a lot more to show in the next day or two 10.35.51 Quit Orion7 (Ping timeout: 252 seconds) 10.37.26 Join ender` [0] (krneki@foo.eternallybored.org) 10.47.39 Join funman [0] (~fun@rockbox/developer/funman) 10.53.46 # JdGordon: yes 10.54.16 # ah ok 10.54.20 # I didnt know that 10.54.50 # except on hwcodec radio targets ;) 10.54.52 # though I do have some thoughts on letting it run independent of UI 10.57.20 # are menus voiced when listening to FM on c200v1/e200v1 ? 10.57.59 # can anyone confirm soe things I'm seeing in "Viewer" for me please? Scroll down to th e bottom of a file being viewed, "show footer" in viewer options needs to be set to "page num" (I'm using "rockbox-info.txt" to reproduce), now scroll back up to the top of the file and note the page number is not 1. 10.58.41 # it takes quite a bit more scrolling to reach "page 1" on my Nanos despite it actually showing the top of the page. 10.59.09 # funman: yes 11.00.33 # at least in a slightly older build. I don't know if FMS support could have changed something there but don't expect any problems there 11.02.24 # * JdGordon glares at pixelma for that accusation 11.02.37 # huh? 11.04.21 # I said I *don't* expect problems there but it's quite a big change and I haven't tried with my c200 so there still might be a small possibilty 11.04.22 # voices don't work on clipv1 at all 11.04.58 # funman: did you check voice file size and free RAM? 11.05.28 Join n1s [0] (~n1s@rockbox/developer/n1s) 11.05.30 # no, i think i don't need to check to know that the problem is RAM ;) 11.06.15 # well, the Clipv1 has 2MB of RAM, no? 11.06.16 # FM + voicing works fine on fuzev1 11.06.19 # yes 11.06.56 # amiconn: ape insane on gigabeat S is now 112.62% realtime 11.07.11 # 468.8 MHz 11.07.35 # funman: how much of it is free then with current Rockbox? 11.07.47 Join nls [0] (~n1s@90-230-78-242-no134.tbcn.telia.com) 11.08.12 # heh, I see amiconn has just done the same tests :) 11.08.33 # or is the process of so doing given the wiki page editing :) 11.08.49 # audio buffer is 473040 bytes (r26027) 11.11.23 # that seems way too small 11.11.32 # fuze? 11.11.44 # no clip, the fuze works fine with 8mb 11.11.59 # ok *phew* 11.12.20 # AlexP: Yes. I'm also making the CPU information a bit more precise 11.13.55 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 11.15.26 # New commit by 03uchida (r26044): ID3 tags parser separates from metadata/mp3.c 11.18.46 # look like a bigger change (at least something with the potential to cause problems at different place) - out of the blue 11.19.32 # New commit by 03funman (r26045): as3543: output sum of line & dac to have voicing work while using FM 11.20.04 # funman: maybe you could look into the mechanism used for the archos ondios for voice loading, they don't load the entire voicefile to memor, which all other targets do (which obviously doesn't work if the file is too big) 11.20.32 # umm, the voice file needs to fit on the Ondios too 11.21.17 # completely. The mechanism is there to make loading and playing the clip faster IIRC 11.21.54 # 941kB is obviously too big 11.21.55 # s/loading/accessing 11.23.14 # pixelma: ah, yes, just saw that, hmm 11.23.56 # but loading the clips on demand should be fst enough on a newer flash target 11.24.40 # New commit by 03uchida (r26046): fix yellow 11.26.38 # does voice work at all on the clips? 11.27.00 # JdGordon: no, loading the voicefiel fails since it's too big 11.32.34 Join stoffel [0] (~quassel@p57B49FFD.dip.t-dialin.net) 11.35.18 # amiconn: Isn't the % needed to play realtime dependent on the cpu? i.e. even though the beast is 112% realtime is has ~ 65 MHz left, so should easily be realtime 11.35.27 # yes 11.35.42 # I'd just like the line to be entirely green :) 11.35.55 # There is a problem anyway - somehow the anchor syntax for portalplayer doesn't want to work 11.36.42 Join dfkt [0] (dfkt@unaffiliated/dfkt) 11.36.52 # Ah, wrong order 11.40.25 # so here is a fun suggestion... can we make buffering allow you to request a handle which is a set size, guarenteed to fit (so it dumps handles if it needs to) and static so it doesnt move? 11.40.34 # pixelma: n1s: the voice file is only loaded as needed because of slow access but it still reserves the full room for it 11.40.56 Quit nls (Quit: Lämnar) 11.40.59 # JdGordon: That would be malloc, so no 11.41.21 # :p worth a shot anyway 11.41.36 # load_voicefile() checks if it fits but not talk_init() 11.41.48 # funman: that's what I meant 11.41.55 # funman: yes, i saw that, but maybe it can be adapted 11.42.42 # i think loading on demand should be fast enough on the clip, so we need only a buffer to hold one clip 11.44.16 # hi all 11.44.35 # I'm unable to use festival with rockboxutility 11.44.53 # it does work with "make voice", though 11.45.13 # n1s, funman: On the Ondios this would probably be a good idea as well, as it would allow better quality voices 11.45.48 # The buffer should hold a bit more than just one clip though. It would allow loading the next clip while the current one is still playing 11.46.11 # * amiconn thinks an lru cache like for the font might be useful 11.47.02 # amiconn: yeah, an lru could be good 11.47.06 # eh mru 11.47.47 Join merbanan [0] (~banan@c-94-255-217-84.cust.bredband2.com) 11.48.00 # funman: I knew swcodec needs quite a lot more RAM for itself but I am surprised that it is so much more 11.48.05 # a bit 11.48.09 # oh that sounds like coming up with a solution before determining that there is a problem in the first place 11.48.19 # ah, no the cache algos' name use inversed logic 11.49.15 # funman: is the pcmbuffer smaller on the clip? 11.49.17 # bertrik: what are you referring to? 11.49.33 # buffering voice clips 11.50.03 # n1s: it is 1s (176k) 11.50.06 # bertrik: there is a proble --- it doesn't work 11.50.12 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 11.50.24 # but which problem isn't determined? 11.50.25 # funman: ok 11.50.36 # should i commit http://pastie.org/961428 ? 11.50.41 *** Saving seen data "./dancer.seen" 11.50.57 # I'm questioning the need for a cache to load the next clip while the current one is still playing, suggested by amiconn 11.51.07 # at least playback will continue to work when voicing is enabled & there is a .voice file 11.52.06 # bertrik: that will make it quicker 11.52.48 # bertrik: Caching would reduce the number of disk accesses, i.e. it should help saving battery 11.53.02 # It also helps keeping the codec running 11.54.14 # Hey did anyone try to port rockbox to a ARM Cortex target ? 11.54.37 # (eg an STM32 cpu) 11.54.52 # ok, I see your point, but we have no idea if those things are really a problem right now, i.e. it might already be quick enough, battery savings may be negligible, etc. 11.56.13 # polobricolo: don't think so, but as long as it's not one of the thumb-only cores it shouldn't be too much trouble 11.58.23 Join DerPapst [0] (~Alexander@p4FE8FD3F.dip.t-dialin.net) 11.58.25 # Any LCD expert here ? 11.59.07 # several, I guess :) 11.59.12 # general rule: just ask 12.00.22 # n1s: ok in fact i'm trying to port rockbox to a stm32 evaluation board (it has lcd, speaker/jack, microphone, microsd card reader (no internal memory though) 12.01.39 # cool, how are lcd screens generally controlled, is spi a usually way or not ? 12.02.40 # so all the threading part would still work 12.03.27 # most of the ones I've looked at had a parallel bus, spi is serial so it needs a very high bit rate to get reasonable transfer speeds 12.04.09 # from the physical point of view, I can say that the lcd (of unknown type) has 96x32 pixels and is connected to the board by 8 pins 12.04.11 # polobricolo: most of rockbox is independent of the port, you basically need setup code for your cpu, and drivers for your hardware (and some keymaps) 12.04.31 # doesn't the ipod mini2g use a serial bus? 12.04.32 # (except if there are hidden one but I doubt it) 12.05.39 # if the display is small (few pixels and/or low color depth), then a serial interface like spi is possible 12.05.49 # New commit by 03funman (r26047): talk_init() : don't try to load the voice file if it won't fit in memory ... 12.06.48 # pamaury, do you have access to the schematic, maybe you can tell something from the names of the signals 12.07.03 # Is there a kind of standard or is every lcd completely different from the others ? 12.11.10 Join dfkt_ [0] (dfkt@unaffiliated/dfkt) 12.11.23 # I think there's no formal standard, but a lot of interfaces look quite similar anyway, like there's usually some kind of clock signal, R/W signal and a signal to select between command and data mode 12.11.35 Quit pamaury (Ping timeout: 252 seconds) 12.13.47 Quit dfkt (Disconnected by services) 12.13.50 Nick dfkt_ is now known as dfkt (dfkt@unaffiliated/dfkt) 12.20.09 # New commit by 03uchida (r26048): mp3: when ID3 tags are not found, search APE tags 12.20.34 # eh 12.21.29 # * pixelma wonders why uchida (ucchan?) isn't around 12.21.38 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 12.22.17 # ok thanks 12.22.57 # *grumble* 12.23.26 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 12.23.38 # When did that get it? 12.23.47 # I thought there was a long argument about that 12.23.58 # * pamaury thought there was a kind of nodo AlexP about non-id3 tags 12.24.09 # *s/AlexP/about :) 12.24.16 # s/about/ 12.24.21 # pamaury: Yes, something like that 12.24.42 # I really really really wish (for the 5th or 6th time now) that uchida was around when committing 12.24.43 # Did uchida asked before comitting ? 12.24.47 # nope 12.24.52 # He is never here anyway 12.25.19 # I know, but I really think it ought to be a "rule" that when committing you are on IRC 12.25.28 # that too, but I also don't like that uchida made some big changes without being around here and I haven't seen discussion about it. Also the split of the ID3 parser before - I'm curious how much it was tested 12.25.36 # If you are at a computer to commit then you should be on IRC 12.25.46 # * AlexP adds it to the devcon page 12.25.55 # almost +3k on hwcodec targets :( 12.26.16 # perhaps it ought to be reverted, then... 12.26.25 # At least until the discussion is had 12.26.59 # uchida often do big commits without asking 12.27.01 # * Unhelpful has taken reading of non-native tag formats to be a NODO for as long as he's been involved, and imagines it goes back rather farther than that 12.27.03 # I guess that's because APE tags didn't have to be parsed before at all 12.27.32 # pamaury: Yes, and is never here 12.27.41 # He has been asked to be multiple times before 12.27.56 Join einhirn [0] (~Miranda@p54851C10.dip0.t-ipconnect.de) 12.27.57 Join JdGordon_ [0] (~jd@rockbox/developer/JdGordon) 12.28.07 # I saw him here before committing TTA but it isn't often 12.28.50 # I mean that he is around 12.30.37 # Someone want to revert that? 12.31.08 # Ape in mp3 has been nodo for a long time 12.31.36 # Go for it 12.32.04 # I'm afk 12.32.15 # No you're not! 12.32.27 # Unless it is ghost JdGordon_ typing :) 12.32.30 # well ask him to revert rather 12.32.45 # I've sent a mail to the dev list, people can chime in :) 12.32.51 # having to go through the ml 12.33.46 # reverting commit of someone else is impolite IMO, i prefer asking (or be asked if i did the commit) 12.34.20 # funman: I agree, unless they aren't around 12.34.29 # he didn't ask before either and isn't around now 12.34.49 # I've added it to the devcon talking points list - that you should be in IRC when you commit stuff 12.34.59 # Or rather, whether we think people should be 12.36.49 Join b0hoon [0] (~quassel@klient-88-135-173-197.StrefaWiFi.kolnet.eu) 12.37.27 # i think some people don't like irc so for me the mailing list is sufficient (discussions can be close to real-time) 12.38.19 # Its more about discussion than being online 12.38.24 # yeah, true 12.39.38 # * AlexP replies to his own e-mail 12.39.40 Quit stoffel (Remote host closed the connection) 12.40.13 # i also think that it's easier to discuss on the mailing list for uchida if he's using a translator (all content is on topic in a given thread) 12.40.33 # irc talks often need a bit of filtering 12.40.40 # this is also true 12.41.15 # perhaps we should just ask him why he doesn't find irc more convenient to use 12.41.41 # * funman uses irc by laziness and wait for uchida to pop up 12.47.06 # as for that commit.. it should only be swcodec 12.47.07 # funman: talk work now while playing radio, but english.voice somehow does not 12.47.37 # I dont actually have any problem with APE in mp3 if it is efectivly free (which it is on swcodec) 12.48.08 # ThomasAH: perhaps you need an up to date file? i used the english.voice from build.rockbox.org 12.48.13 Join dfkt_ [0] (dfkt@unaffiliated/dfkt) 12.48.30 # funman: I always rebuild from svn to be sure it matches 12.48.53 # so talking directories work but not menus? 12.49.15 # you always build a voice file too? 12.49.24 # funman: talking directories with .talk clips work, spelling directories and talked menus don't 12.49.54 # pixelma: yes, this way I don't have to check if it is really needed :) 12.50.17 # pamaury: There are several different LCD interfaces, all of them are used in some targets: serial (SPI), 8/9 bit parallel, and 16/18 bit parallel 12.50.58 # Examples for serial are the archoses, the iriver and iaudio remotes, and the mini G2 (but the latter uses the PP built-in bridge to do the conversion) 12.51.30 # do they have something in command except spi ? 12.51.34 # *common 12.52.16 Quit dfkt (Ping timeout: 265 seconds) 12.53.01 # The command set/ registers depend on the controller. The method is similar for all of them, but the register numbers and bit patterns are usually different 12.53.20 # * amiconn thinks r26048 should be reverted 12.54.17 # pixelma: (I used to not build it in the past, but when funman enabled additional features in the clip+, the menu was always off by one) 12.54.47 # ThomasAH: i didn't use .talk files, only voice 12.54.51 # pixelma: and the OF database refresh takes much longer than building the voice file many times 12.55.02 # ok thanks 12.55.13 # funman: I'll double check now 12.55.26 # amiconn: we just discussed this 20 minutes ago :) 12.55.35 # yes, saw that 12.57.38 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 12.58.29 # i am not sure i want to make voicing work on clipv1/c200v2 : it would shrink the playback buffer, and then i'd have to fix playback bug. i think i'm not up the task and don't want to drive crazy on this 13.02.46 # ok, clean svn r26037, rebuild rockbox-full.zip and english.voice, installed fixed.cfg and fmpresets, nothing else ... now waiting for the OF media refresh 13.02.55 # clean svn r26047 13.03.06 # * ThomasAH should use more copy&paste :) 13.03.55 Quit JdGordon_ (Quit: Bye) 13.08.19 # funman: still no voice menus 13.08.55 # what if you disable .talk? 13.09.23 # ThomasAH: and the setting is enabled? Might be silly but worth a check ;) 13.09.41 # funman: does not help 13.09.56 # pixelma: yes, I tripple checked that :) 13.10.16 # and you use english in the language settings too? 13.10.46 # pixelma: yes ... and the compiled english.voice file is binary identical to some previous versions, too 13.11.19 # switching to a different language and back does not help 13.13.32 # booting an older rockbox.sansa via file browser brings voices back 13.13.44 # (with everything else identical) 13.14.17 # hmm yes i have no voice anymore too 13.14.27 # funman: somehow this is good news :) 13.14.40 # how older is the working rockbox.sansa ? 13.14.49 # funman: yesterday 13.15.21 # that's a good, small timeframe 13.15.46 # OTOH, voice worked for me 2 hours ago ;) 13.16.41 # * funman slaps himself repeatedly 13.16.46 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 13.17.03 # funman? 13.17.20 # my supposed clipv1 fix in r26047 is incorrect 13.18.38 Quit n1s (Ping timeout: 252 seconds) 13.19.31 # New commit by 03funman (r26049): fix inverted logic in r26047: voice works again 13.21.01 Join stoffel [0] (~quassel@p57B49FFD.dip.t-dialin.net) 13.21.10 # * b0hoon says hi. 13.21.16 # ThomasAH: everything's alright now? 13.21.20 # hello b0hoon 13.22.02 # i will promote pb vibe to the stable ports today if nobody still objects. 13.23.09 # b0hoon: isn't it better to wait for next release? 13.24.12 # funman: why it would be better? 13.24.35 # b0hoon: there would be a release build 13.24.44 # Llorean: I really the idea of having the font/language loader check compatibility 13.24.57 # amiconn: So do others, now people need to reply to the list saying so :) 13.25.02 Join marc2003 [0] (~chatzilla@94-195-146-151.zone9.bethere.co.uk) 13.26.10 # any plan on a release? we are now more than 3 months after 3.5 13.26.13 # funman: yes, but if i'll do it now it will be available in the next release anyway 13.27.00 # rasher: It would eliminate one of the easiest remaining ways to get an indecipherable UI, at least. 13.27.03 # funman: I'll check (at least the patch looks promising :)) 13.27.20 # hey funman, this is the output after making that you suggested on ABI 13.27.22 # sd0: 15994652 + 1 > 15993856 13.27.33 # Llorean: I almost have a patch ready for genlang to add a string simply consisting of all characters used in that language 13.27.46 # (which is the easist part, to me, anyway) 13.28.19 # b0hoon: we would need a new rbutil release too? it lists the vibe 500 as unstable 13.28.48 # Hey, first time I got that far: 13.28.52 # May 15 20:26:56 navi kernel: [207036.298943] usb 1-3: New USB device found, idVendor=0781, idProduct=7452 13.28.55 # May 15 20:26:56 navi kernel: [207036.298943] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 13.28.58 # May 15 20:26:56 navi kernel: [207036.298943] usb 1-3: Product: Rockbox media player 13.29.01 # May 15 20:26:56 navi kernel: [207036.298943] usb 1-3: Manufacturer: Rockbox.org 13.29.04 # May 15 20:27:01 navi kernel: [207041.299256] usb 1-3: can't set config #1, error -110 13.29.29 # marc2003: hey, what is the exact size of the drive reported by your OS ? (whole drive, not partition) 13.29.39 # ranma: \o/ 13.30.04 # 'refresh database' must die, with pain 13.30.22 # The error is because it called usb_drv_send with len>64, which I don't handle yet :) 13.30.42 # ranma: do you use DMA ? 13.30.45 Join moos [0] (moos@rockbox/staff/moos) 13.30.48 # But I think sending control responses works now. 13.30.53 # Yes, it's using DMa. 13.31.22 # I don't think you can use PIO with this thing and it has it's own DMA controller... 13.31.33 # aah so you're not using the pl081 ? 13.33.01 Join anewuser [0] (anewuser@unaffiliated/anewuser) 13.33.24 # funman: 7810MB according to disk management on windows 7. i'm not sure how to get more accurate. i have ubuntu in VMware if you can tell me what to do (i'm a linux noob) 13.33.29 # funman: yes, but it can be unstable i think in rbutil for the next rbutil release 13.33.42 # funman: please look at the last sentence in "Current status of supported targets" section, (TargetStatus on the Wiki) 13.33.57 # Nope, it has it's own DMA descriptor format, flags etc. 13.34.08 # funman: "Whilst every effort is made to try and ensure..." 13.36.00 # marc2003: oops I see the bug it's my fault, sorry :D 13.36.46 # b0hoon: ah ok 13.36.49 # funman: works fine now 13.36.58 # funman: (even while and after playing radio) 13.37.13 # ranma: ok i thought we would have to use pl081 channel 1 and give up any future hope for USB audio ;) 13.39.21 # marc2003: can you test http://pastie.org/961507 ? 13.39.57 # funman: thanks ... one question regarding patching the manual: Would you or other devs prefer one larger patch which fixes/improves documentation for clip1/2/+ buttons or smaller patches with one change per patch? 13.42.16 Join sadzior [0] (~sadzior90@agy158.internetdsl.tpnet.pl) 13.42.49 # when will rockbox 3.6 be released 13.42.50 # ? 13.42.55 # approximatelly 13.43.09 # ThomasAH: depends what you consider 'one' change 13.43.28 # sadzior: there's no immediate plan for it at the moment 13.44.11 # sadzior: Not confirmed, but I guess it will be a few weeks 13.44.28 # It shoyuld be fairly soon though, no? 13.44.36 # Do we want it before or after devcon? 13.44.56 Join petur [0] (~petur@rockbox/developer/petur) 13.45.54 # funman: currently it is one patch "improve the manual regarding buttons of Sansa Clip and Clip+" with subtopics "missing hold button on Sansa Clip+" and "reverts FS#11241, which confused "context of WPS" (button_context_wps) and "context of WPS context menu" (button_context_tree)" 13.46.11 # funman: then I noticed that Home/Submenu are wrong in the WPS help, too 13.47.34 # funman: preparing a series of patches with corrsponding descriptions for commit messages is no problem for me, but of course more work for the one who has to apply/commit in the end 13.49.10 # do what you feel is better 13.49.37 # funman: ok, then I'll make single patches ... combining them is easier than splitting :) 13.50.42 *** Saving seen data "./dancer.seen" 13.51.39 # funman: i'm getting these errors applying the patch 13.51.42 # patch unexpectedly ends in middle of line 13.51.50 # are there any plans to improve battery life on fuze? 13.51.59 # Hunk #2 succeeded at 817 with fuzz 1. 13.52.34 # i'll try it anyway :p 13.52.41 Quit TheSeven (Remote host closed the connection) 13.53.11 # marc2003: just add a newline at the end of the patch (pastie removes it) 13.53.31 # sadzior: well it depends, do you have any plan to improve it ? 13.54.18 # I'm not aware of any obvious power wasters on the fuze 13.54.41 Quit stoffel (Ping timeout: 246 seconds) 13.55.41 # there have been improvements in runtime by disabling the radio chip if unused and also recently a patch to stop DRAM clocks when idle 13.55.44 # bertrik: playback wrt idle mode needs 10mA more on rockbox, and only 2mA more on OF (on c200v2) 13.58.05 # maybe we can reduce some bias currents in the audio stages, but that would likely make audio quality worse 13.58.39 # yeah, but it would require some learning c and asm, so it makes it pretty much long termed, so to say 14.00.18 # funman: that looks to have done the trick. the database built with no problems. thanks. 14.00.32 # last test i made, rockbox lasted 66% of the OF time 14.01.53 # marc2003: thanks 14.01.55 # New commit by 03funman (r26050): as3525: fix capacity sanity check ... 14.02.21 Quit marc2003 (Quit: ChatZilla 0.9.86 [Firefox 3.6.4/20100503122926]) 14.02.33 Quit FlynDice (Remote host closed the connection) 14.03.09 # ranma made some comparison of codec settings between rockbox and OF, right (IIRC)? 14.04.32 # yes, saratoga committed some changes with this data 14.06.07 # i have an analog multimeter, perhaps i could try to use it on my clip 14.06.31 # IIUC i need to remove the battery and provide another source of current ? 14.07.24 # bertrik: i have tried to higher the burst size for pcm DMA transfers but it had a very little (if any) effect on battery 14.07.30 Quit krazykit (Read error: Connection reset by peer) 14.08.27 # funman, I think if you measure the current drawn through the USB cable when the battery is fully charged, then that current is also a good way to compare power consumption 14.11.01 Join krazykit [0] (~kkit@70.236.74.71) 14.11.04 # why is there 3 wires on the battery? -, + and N 14.11.41 # is the ground - or N ? 14.15.35 # probably one wire for a thermistor to measure the battery temperature 14.16.55 # I think - is the "ground", + is the positive terminal and N is the thermistor (maybe N for NTC?) 14.17.29 Join stoffel [0] (~quassel@p57B49FFD.dip.t-dialin.net) 14.17.48 # i think too, + is red, - is black and N is blue 14.20.15 Quit flydutch (Quit: /* empty */) 14.23.36 Quit bertrik (Remote host closed the connection) 14.26.08 Join n1s [0] (~n1s@rockbox/developer/n1s) 14.27.23 # funman: BTW, still haven't gotten around to do proper current measurements on memory reads. 14.27.24 Join einhirn_ [0] (Miranda@vpn10.rz.tu-clausthal.de) 14.28.03 # I tried it with my cheap multimeter at home, but the voltage drop over the internal measurement resistor is too high. 14.30.07 # At least I can say it looks like a tight memory read loop uses more current on iram than extram, maybe because iram is faster and it can do more read operations / less waitstates, meaning a less idle processor. 14.30.50 # Because on the iram loop the player turns off with voltage dropping too low, with extram it stays on. 14.31.08 Quit einhirn (Ping timeout: 240 seconds) 14.37.14 Join Jaykay [0] (~chatzilla@p5DC57860.dip.t-dialin.net) 14.38.41 # '< 14.41.27 # bertrik: btw i have my clipv1 opened and it's hardware revision 1.4, is yours different ? 14.41.30 Join theli_ua [0] (~theli@132-19-133-95.pool.ukrtel.net) 14.42.57 Join CFP [0] (~Create@ip-118.net-81-220-138.rev.numericable.fr) 14.48.07 Part b0hoon ("GTG. Bye.") 14.53.50 Quit stoffel (Ping timeout: 246 seconds) 15.04.03 Join Trou [0] (trou@sha2.info) 15.04.45 Quit funman (Quit: free(random());) 15.06.23 Join kugel [0] (~kugel@rockbox/developer/kugel) 15.08.43 # hello everyone :) Before I reboot to linux, is there anybody here who know how to modify kkurbjun gigabeat flashwriter to accept a new hash? 15.08.49 # knows* 15.09.35 # * kugel grumbles a bit about the libc related committs yesterday 15.09.48 # New commit by 03jethead71 (r26051): Gigabeat S: Fully enable access to hardware tone controls and 3-D effect feature. Under the hood, it's designated a hardware equalizer since it is ... 15.16.32 Part sadzior 15.17.14 # gevaerts: we use our *printf on cygwin/mingw, I believe, which could be why %z fails for it. I think we should just add it to our implementation 15.17.55 # OR we check again whether we really need our *printf there, that comment is old and in the meantime there's a new cygwin version 15.18.00 Part theli_ua 15.27.20 Join cdb [0] (~cdb@206-248-133-92.dsl.teksavvy.com) 15.28.10 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 15.30.04 # New commit by 03jethead71 (r26052): Hopefully get some green back from r26051. 15.31.32 Quit CFP (Read error: Connection reset by peer) 15.32.15 Quit moos (Ping timeout: 258 seconds) 15.32.23 # JdGordon: I would also vote for optional parameters always at the end 15.32.51 # I'm happy with using a differnet tag for those instead 15.33.18 Quit einhirn_ (Read error: Connection reset by peer) 15.34.15 Quit Highlander (Quit: Quitte) 15.35.33 # kugel: right. I'd prefer to do both think, i.e. support %z (that takes about 16 bytes according to my experiments last night), and use native printf in the sim 15.36.09 # * gevaerts *hates* casts in printf-like calls. Those should use the correct format string 15.36.32 # * kugel too 15.37.26 # what is %z? 15.37.27 # I'm wondering which cygwin version Blue_Dude is running 15.37.33 # there are not enough modifiers ! Which one do you use to output a uintX_t for example ? 15.37.54 # pamaury: c99 specifies tags for them but we do not support them 15.38.33 # JdGordon: that's the one for size_t 15.38.47 # pamaury: http://code.google.com/p/msinttypes/ 15.40.13 # let's use C++ then :) 15.40.26 # why c++? 15.42.12 # yes! and then real OO! 15.42.19 # none of this nonesense marco crap to do it 15.42.20 # aaaaah! 15.42.40 # * n1s grabs a pitchfork 15.42.49 # and malloc! and xml! 15.43.05 # * n1s stabs JdGordon with pitchfork 15.44.43 # JdGordon: not malloc, but new! 15.47.10 Quit pamaury (Ping timeout: 252 seconds) 15.50.14 # gevaerts: btw, I didn't move firmware/include/sys/ to libc because it's not iso c and I didn't decide what to do with it yet, of course I didn't know it breaks weirdo cygwin again 15.50.40 Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) 15.50.44 *** Saving seen data "./dancer.seen" 15.50.53 # * Blue_Dude grumbles about compile warnings. :) 15.51.06 # Blue_Dude: what cygwin version do you run? 15.51.15 # kugel: Using 1.7. 15.51.21 # I think... 15.51.41 # Checking where I can find that info. 15.51.47 Join cfp [0] (~cfp@ip-118.net-81-220-138.rev.numericable.fr) 15.52.06 # I assume you could just run the installer again, that worked on 1.6 15.53.29 # It doesn't say. 15.53.31 # GodEater: Refering to FS#7505, you did flash you Gigabeat, although it wasn't recognized by kkurbjun tool. 15.53.49 # Blue_Dude: can you update? 15.53.51 # could you provide me with a little more info on how you did that? 15.54.06 # It is some variant of 1.7. I don't know the subversion. 15.54.21 # gevaerts: I believe you did too. Could you explain how you modified the code? 15.54.30 # JdGordon: that also works, remember you invented the dual use of %Vi :) 15.54.47 # I'm not really sure I understand how it works 15.55.54 # Or else, if anyone has a clue, I'm all ears :) 15.55.56 # gevaerts: we probably should support more tags in *printf, e.g. to make logf and debugf more compatible 15.56.30 # cfp: see the top of gigabeat_flash.c, but make sure you know that there are some risks :) 15.56.36 # cygwin1.dll has a version of 1.7.1. 15.57.05 # gevaerts: I know =) But I'd like to try it anyway, although I don't quite get how the array is formatted, despite the comments 15.57.31 # cfp: don't touch the array, that's overkill! 15.57.39 # The problem with %z was compiler warnings. Signed size_t format, ssize_t argument. I know, they're the same thing, but the formatted didn't know that. 15.58.09 # Blue_Dude: your fix is technically wrong on 64 bit systems though 15.58.12 # gevaerts: oh? So I should just ENABLE_DEV ? 15.58.33 # yes, but don't tell anyone! We don't want people to test this without thinking about the risks first 15.59.03 # *formatter 15.59.03 # So cast the ssize_t arguments as long with %ld tags and it was happy. 15.59.19 # Blue_Dude: yes, but I'm not 15.59.19 # Blue_Dude: have you tried #define ssize_t signed size_t? 15.59.21 # gevaerts: I will be silent (do expect me to ask a lot of questions though if it fails =)) 15.59.36 # Blue_Dude: that's a workaround at most 15.59.51 # gevaerts: I've seen that some people restored a backup posted by others that was recognized by the code ; would you recommend that? 16.00.01 # Blue_Dude: I don't know if it's a windows or a msvc thing, but long is usually 32bit under windows environments 16.00.22 # while size_t is 32bit or 64bit depending on the cpu 16.00.37 # cfp: I'd suspect that if one image works, other images compatible with that image will also work, so it probably doesn't matter much 16.01.15 # And the Rockbox stdio.h had a "foreign" function that was not present in the other stdio.h libraries. format.h already had the prototype so I used it. 16.01.30 # yea, I forgot to remove it from stdio.h 16.02.46 # does bass/treble cutoff already show up in the menus on D2? something's odd here. 16.03.07 # gevaerts: Ok, I guess I'll give it a go then :) 16.03.09 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 16.03.32 Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) 16.03.38 # Sorry. I could see your replies on the log but not in the IRC window. 16.04.06 # gevaerts: What about those disabled lines though? 16.04.11 # #if !defined(ENABLE_DEV) 16.04.11 # splash_pause(true, "ERROR: Forcing backup restoration!"); 16.04.11 # do_flash_restore(); 16.04.11 DBUG Sent KICK cfp to server 16.04.11 # #endif 16.04.11 Kick (#rockbox cfp :No flooding!) by logbot!~rockbox@giant.haxx.se 16.04.29 Join cfp [0] (~cfp@ip-118.net-81-220-138.rev.numericable.fr) 16.04.38 # woops 16.04.48 # seems I shouldn't have posted those lines 16.04.49 # pastebin 16.04.52 # yup 16.04.57 # sorry everyone :s 16.05.13 # * gevaerts thinks that while that should indeed have gone to a pastebin, logbot might be a bit too trigger-happy 16.05.48 # kugel: I can indeed update. I think we're up to 1.7.5 now. 16.05.52 # odd, it defined the CAPS but the string is only designated for ipodvideo. somehow I woke-up the feature, probably throught a proper #include somewhere. 16.06.31 # cfp: that's fine too. If I understand the code correctly, it checks there if the end result has an expected md5sum, which it won't if the initial setup didn;t match 16.06.51 # gevaerts: Ok, thanks =) 16.07.45 # kugel: did you see funman's %z patch last night? 16.07.54 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 16.08.30 # gevaerts: yes, now. I don't think that's the correct way 16.09.41 # or specifically it should cast to size_t in the body of that case 16.11.02 # I'm not entirely sure if (s)size_t valid in va_arg(), I think there are some type restrictions for casting in va_arg() 16.12.08 # kugel: we know this code is for on-target rockbox use though, so assuming that size_t and long are the same there could be OK 16.12.15 # Anyway, sorry if I stepped on toes with argument casts. 16.12.47 # gevaerts: not necessarily. format.c is compiled for sims to, and is used for fdprintf and vuprintf (IIRC) 16.13.02 # ah, ok 16.13.33 # In that case the patch is indeed too simple and probably wrong 16.13.55 # * gevaerts wants to know where mingw's ssize_t comes from 16.15.14 # Yeah! 16.15.27 # It works /perfectly/ \o/ 16.15.48 # * cfp bows to kkurbjun and thanks gevaerts =) 16.16.18 # gevaerts: \usr\include\mingw\sys\types.h 16.16.36 # New commit by 03jethead71 (r26053): Hopefully finish off the red from r26051. 16.17.14 # It's a long there. 16.19.55 Nick dfkt_ is now known as dfkt (dfkt@unaffiliated/dfkt) 16.20.06 # Also \usr\include\sys\types.h 16.20.13 # ok, http://pastie.org/961617 gives me the same warning. This is *wrong*! 16.20.31 # Double yeah :)) 16.20.42 # cfp: happy? :) 16.20.46 # My second Gigabeat works too \o/ 16.20.53 # geaverts: more than that =) 16.20.58 # woops 16.21.02 # gevaerts* 16.21.25 # is format speed critical or why don't we just use a full-blown implementation of which a hand full exists on the net? 16.21.55 # gevaerts: does #define ssize_t signed size_t work? 16.22.05 # kugel: I definitely hope that no speed critical code is mucking around with format strings :) 16.22.18 # kugel: won't that throw away the sign? 16.22.19 # gevaerts: I must say Karl did an impressive work there. And this is definitely convincing me /not/ to buy another DAP =) 16.22.20 # A full-blown one will use more RAM though 16.22.42 # Or at least make a negative number really, really big? 16.23.15 # if we give up 10k on fonts then we can give 500 bytes on a widely used function IMO 16.24.31 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 16.25.19 # kugel: IIRC one of our committers has worked on http://sourceforge.net/projects/ctrio/ 16.26.12 # kugel: And the fact that people use arguments like that is exactly why I'm against giving up RAM so often. Everything should be judged on its own merit, not how much RAM was used for other things (I have no idea if your thing is worth the RAM or not, I'm just opposed to that being used as an argument) 16.26.57 # * Llorean also dislikes the "if I free up X amount, I should then be able to spend kugel: "signed size_t" does not work at all 16.27.32 Quit n1s (Ping timeout: 245 seconds) 16.28.41 # gevaerts: something is broken on the mingw side I think 16.28.49 # kugel: yes, I'm going to ask there 16.30.09 # cfp: amazing how having two players makes one more likely to try risky things, isn't it? ;) 16.34.02 # kugel: apparently the basic problem is that msvcrt (which mingw-produced binaries use) doesn't know about %zd 16.34.19 # jep, I'm reading :) 16.37.03 # I suspect we have to either provide our own stdio or stick to strick iso-C things 16.37.13 Quit mt (Remote host closed the connection) 16.37.45 # geaverts: Quite :) 16.37.47 Join Boldfilter [0] (~Boldfilte@adsl-82-77-225.jax.bellsouth.net) 16.37.51 # now, gigs won't let me power down when plugged, not just when charging. :\ 16.38.43 # If you really want a bullet proof, gcc specific solution, then you can use gcc builtins to compute at compile time the good printf modifier... 16.40.09 # gevaerts: Actually, I thought my first one was dead when I came back from a travel last year, and then it happened that opening it and pluging the drive directly to my computer did the trick, so that's basically when I installed rockbox. I then got the second one when the first's screen broke, and eventually replaced the screen anyway =) 16.43.27 # Anyway, I'd like to thank all the people behind the rockbox firmware. It's a great project, great to use, great to involve in, which has a wonderful dev team, lots of helpful people, and an impressive dynamic. Thanks everyone! 16.45.51 # goodbye everyone :) 16.46.07 # gevaerts: thanks for your help =) 16.46.27 Quit cfp (Quit: Quitte) 16.51.58 # * gevaerts looks at trio 16.53.25 # gevaerts: seems we should go for PRIdMAX 16.54.11 # even if we use our format; if we use the mingw headers we will still get that warning 16.55.35 # kugel: that's *ugly* 16.56.19 # ugly but at least iso c compatible 16.56.36 # we don't write iso c... 16.57.04 # kugel: do you really propose to use that in *every* format string? 16.57.29 # only for the ones that use (s)size_t I guess 16.57.38 # which is a lot of them 16.58.04 # what is this PRIdMAX thing ? 16.58.17 # New commit by 03jethead71 (r26054): Gigabeat S: There's no reason to pause the LCD DMA when changing the framebuffer address. 16.58.33 # pamaury: it's an ugly macro that contains the format specifier for intmax_t 16.58.36 Join funman [0] (~fun@rockbox/developer/funman) 16.58.42 # or we make our own stdio, which includes our format.h on mingw/cygwin and the systems stdio.h on the rest 16.59.04 # what about this: ignore cygwin/mingw completely 16.59.12 # kugel: yes, that's what I propose 16.59.28 # but we can't use native printf then 17.00.07 # is that a problem? Native printf is broken 17.00.41 Quit pamaury (Quit: Page closed) 17.00.48 # kugel: http://pastie.org/961646 - slows down scrollwheel updates on fuzev2 (minimum of 3 ms between handling a new interrupt) 17.00.51 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 17.00.58 # * gevaerts looks at trio 17.01.08 Join dfkt_ [0] (~dfkt@unaffiliated/dfkt) 17.02.00 # funman: does it work well? I have thought about a similar solution 17.02.03 Quit dfkt (Disconnected by services) 17.02.06 Nick dfkt_ is now known as dfkt (~dfkt@unaffiliated/dfkt) 17.02.12 # 3ms sounds a bit high though 17.02.27 # seems to be fine, i have tried with 5ms to be like fuzev1 (1/(2*HZ)) but 3ms is fine 17.03.17 # New commit by 03jethead71 (r26055): If HAVE_POWEROFF_WHILE_CHARGING is not defined and the charging configuration specifies CHARGING_MONITOR or greater, allow poweroff while plugged but ... 17.03.33 # kugel: gevaerts: i am not trolling when I propose to ignore cygwin/mingw/msvcrt, there are usable workarounds (running linux in a VM) for people using windows 17.04.02 # is the problem only about warnings ? 17.04.12 # pamaury: no, unfortunately not 17.04.20 # funman: we don't talk about compiling target builds from windows, but to compile the sim (or RaaA later) to run in windows 17.04.22 # %zd and %zu print "zd" and "zu" 17.04.34 # and why do we need %zd and %zu ? 17.04.38 # i guess printf() can also crash ? variable arguments are shifted 17.04.44 # pamaury: for size_t and ssize_t 17.04.50 # oh sorry .. 17.04.58 # funman: oh, right. Probably that too 17.05.20 Quit bmbl (Quit: Bye!) 17.05.34 # gevaerts: trio looks messy, http://www.jhweiss.de/software/snprintf.html looks more sane 17.05.41 # can you add a platform check to use specific cygwin code in this case? 17.06.15 # I don't see the point, if it's only for size_t and ssize_t, use a macro like PFSS for size_t modifier and go on 17.06.20 # a whole new printf() shouldn't be needed if the only thing which needs fixing is '%z' 17.06.39 # 7.7k lines seems overkill 17.07.05 # kugel: or just extend out format.c properly and use that 17.07.10 Join cfp [0] (~cfp@ip-118.net-81-220-138.rev.numericable.fr) 17.08.09 # isn't mingw_printf() the c99 compatible version of mingw ? 17.08.30 # funman: Did you see my patch at http://www.rockbox.org/tracker/task/11110 ? 17.09.15 # http://git.videolan.org/?p=vlc.git;a=blob;f=include/vlc_common.h;hb=HEAD#l59 17.09.19 # funman: been testing this for a month now, works fine =) 17.09.45 Join GodEater_ [0] (~bibble@cl-711.lon-02.gb.sixxs.net) 17.09.45 Quit GodEater_ (Changing host) 17.09.45 Join GodEater_ [0] (~bibble@rockbox/staff/GodEater) 17.10.37 Quit GodEater (Quit: leaving) 17.10.50 Nick GodEater_ is now known as GodEater (~bibble@rockbox/staff/GodEater) 17.11.25 # funman: yes, that's the sort of uglyness I don't want 17.11.33 # funman: could you commit it? The current version quite frequently gets calculations wrong 17.12.10 # cfp: looking at it 17.12.31 # gevaerts: well there has to be a workaround somehow 17.12.55 # the PRI* aren't needed as long as we don't try to print int??_t 17.13.52 # if you don't want to use printf from mingw 'libc.dll' you'll have to redefine printf to something else anyway 17.14.01 # and how do you avoid printing those? 17.14.39 # easy: you don't at all 17.15.12 # i suggest you ask j-b on #videolan as he went through this trouble already 17.18.03 # hm i can't find any doc on mingw_snprintf, nor find it in the headers i have :o 17.19.53 # trio handles ssize_t and %zd wrong 17.20.47 # there is an alternative solution: under mingw, define printf as a macro which calls a converter function, that way, it will print everything correctly 17.20.48 # New commit by 03funman (r26056): Fix alarmclock plugin time miscalculation ... 17.21.46 # (if it's just for the %zd and %zu) 17.22.24 # pamaury: int*_t as well it seems 17.22.53 # changing format string in place would work if the format string is writable 17.23.17 # and if new format specifiers are not larger (ex: %ld -> %lld) 17.23.19 # well, you could copy it to a spare buffer 17.23.21 Join n1s [0] (~n1s@rockbox/developer/n1s) 17.23.35 # ah right you could use the stack 17.23.53 # but a converter for all sorts of *printf seems a lot of work 17.23.57 # If you're doing that, why not just have the macro call another printf()? 17.24.23 Quit pamaury (Quit: Page closed) 17.24.33 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 17.25.02 # which one? 17.25.26 # the problem is only with mingw ? 17.25.39 # pamaury: who knows? 17.26.09 # I mean, does this problem arise on target ? 17.26.18 # on target we use our own formatter 17.26.40 # That one doesn't do %z right now, but we can fix that 17.26.54 # Yes, so it's just for mingw basically 17.28.18 # And I don't see the problem with int*_t, it's about finding the good modifier on different hosts ? 17.28.36 Quit jordan` (Quit: Coyote finally caught me) 17.33.17 # gevaerts: btw, i think specifiers are only a real problem when using int64_t 17.33.58 # pamaury: int*_t specifiers are in the form PRId64 defined in headers 17.34.12 # __mingw_printf seems like the way to go 17.34.38 # in fact they are defined to "lld" "ld" or alike 17.34.50 # we just need -D__USE_MINGW_ANSI_STDIO=1 on the cmd line it seems 17.35.10 # I think the problem is that windows use special specifiers for them 17.35.26 # gevaerts: can you test compile your test.c with that? 17.35.31 # yeah, "I64d", which gnu functions don't know 17.36.09 # * pamaury always thought printf modifiers were broken 17.36.36 # pamaury: well %d is a printf modifier and i guess it's working everywhere 17.36.47 # not, the size modifiers 17.36.58 # %8d ? 17.37.00 # you should be able to write %d for any integer 17.37.13 # and not fiddle with those horrible %ld, %hd, ... 17.37.14 # kugel: what exactly? Just adding -D__USE_MINGW_ANSI_STDIO=1 doesn't change anything 17.37.25 # and %lld now... 17.37.46 # it should according to http://www.mail-archive.com/mingw-w64-public@lists.sourceforge.net/msg00400.html 17.38.30 # Maybe with a newer version 17.40.55 # works for me, with ubuntu mingw (4.2.1-sjlj) 17.41.39 # printf() is redefined internally to mingw headers to use __mingw_printf() 17.41.46 # weird 17.42.02 # and PRId64 works like expected, no redefinition needed 17.42.12 # Does %z work? 17.42.18 # gevaerts: i586-mingw32msvc-gcc -D__USE_MINGW_ANSI_STDIO=1 test.c -o test.exe -Wall works for me 17.42.39 # yes 17.43.21 # ok, so my mingw is probably too old. It also claims to be 4.2.1-sjlj... 17.43.38 # same here... :) 17.43.41 # gevaerts: did you include stdio.h ? 17.43.51 # funman: of course! 17.43.58 Join jordan` [0] (~jordan@jem75-13-78-235-252-137.fbx.proxad.net) 17.43.59 # any commiter for http://www.rockbox.org/tracker/task/11275 ? small fix in francais.lang 17.44.23 # gevaerts: i'm using the 32bits version of mingw on 64bits host if it makes a difference 17.44.29 # funman: me too 17.45.28 # cfp: I would commit it if I could but I'm behind a proxy, however I can confirm it's a good french translation :) So anyone can commit it please ? 17.45.40 # what's the problem with mingw? 17.47.52 # gevaerts: 0a6f49536b39cc1a6f733b5ea9e7b399 /usr/i586-mingw32msvc/include/stdio.h 17.48.06 # pamaury: :) 17.48.16 # cfp: pamaury: je vais le faire 17.48.36 # funman: different here. Oh well... 17.48.39 # funman: ça marche =) 17.48.52 # If newer mingws can handle this, I think we're fine 17.49.23 # New commit by 03funman (r26057): Small mistake in francais.lang ... 17.49.33 # it also works with mingw32 from the mingw-w64 package 17.49.41 # funman: merci =) 17.49.46 # no problem ;) 17.50.05 Join amr1 [0] (~29ea38ee@giant.haxx.se) 17.50.21 # goodbye everyone =) (funman: remember about FS#11110 ;)) 17.50.26 Quit cfp (Quit: Quitte) 17.50.39 # * kugel has the same file as funman 17.50.46 *** Saving seen data "./dancer.seen" 17.51.02 # gevaerts: we are not fine if the cygwin shipped gcc is too old too 17.51.49 # New commit by 03jethead71 (r26058): i.MX31: Issue some NOP's immediately after MCR WFI to prevent premature execution of subsequent code. 17.52.13 # pixelma: can you compile http://pastie.org/961623 with "gcc -D__USE_MINGW_ANSI_STDIO=1 test.c -o test.exe -Wall" under cygwin? 17.52.48 # pixelma: or (preferably) http://pastie.org/961623 17.53.09 # That one makes the ssize_t negative, so we can test if it *really* works 17.53.11 # is our firmware/include/_ansi.h going to be used elsewhere than on target builds ? 17.53.14 # * kugel slaps gevaerts 17.53.50 # oh, sst is -1! 17.53.55 # that it doesn't work here 17.53.59 # then* 17.54.01 # it's the same link... also.. 17.54.16 # oh, it edited in-place? 17.54.16 # it prints 1 1 for me 17.54.35 # you lot need to be a bit more descriptive about what I need to do 17.54.38 # ah wow 17.54.52 # since when does pastie.org do that!? 17.54.58 # pixelma: put it in a file named "test.c" and run kugel's command 17.55.48 # ok, nevermind me, it does work 17.59.02 Quit merbanan (Ping timeout: 240 seconds) 17.59.08 # it just complained about no newline at the end of file 17.59.27 # What output do you get if you run the resulting test.exe? 17.59.31 # anything as a result I need to check - another file or so? 17.59.51 # -1 1 17.59.59 # nice! 18.00.05 # Wait, cygwin... That will build cygwin binaries by default, not mingw 18.00.43 # Good enough for cygwin sims I guess 18.00.56 # the difference seems to be a command line switch, I suspect -DXXX stuff is compatible anyway 18.01.05 # what about crosscompiled sims? 18.01.13 Quit JohannesSM64 (Read error: Operation timed out) 18.01.31 # pixelma: binaries built with mingw on ubuntu seem to be OK 18.01.39 # oh, you said this version works for you before 18.01.51 # kugel: ping 18.01.57 # * gevaerts is now confused 18.02.46 # pixelma: now you could compile a sim in cygwin, but before running make edit the Makefile (in the build dir) and add '-D__USE_MINGW_ANSI_STDIO=1' to the GCCOPTS line 18.02.56 # amr1: pong 18.03.02 # I was testing diacritics support on simulator, but after r26019 I noticed that the last character containing diacritics appears as the first character in the line 18.03.08 # kugel: if you have some minutes ;) 18.03.16 # sure :) 18.03.16 # could that be related to the host headers ? 18.03.40 # amr1: on the sim? 18.03.42 # or both 18.04.20 # till now, on the sim, i didn't install on target yet, but it was working till r26018 18.04.49 # can you delete the build dir and try again? 18.05.32 # while it appears possible, I doubt it's related to my commit. I think the diacritics code doesn't use standard functions 18.05.39 # I did that already, and even tried to download a new fresh tree from svn 18.05.50 # kugel: I guess I should update to recent SVN before or not? 18.06.47 # pixelma: maybe to r26039, r26040 "fixed" warnings which should not appear with that line added to GCCOPTS 18.07.09 # ok 18.08.52 # svn seems a bit slow to me today 18.10.20 # I'll do a make clean just in case even though it'll take longer 18.11.07 Quit n1s (Quit: Lämnar) 18.19.34 # kugel: diacritics.c includes only system.h, while lcd-bitmap-common.c includes , , "string-extra.h" 18.19.40 # could it be a function in "string-extra.h" ? 18.21.49 # New commit by 03funman (r26059): fuzev2: fix buttonlight flashing on µSD access (2nd try) ... 18.23.43 # kugel: about the fuzev2 scrollwheel should I put this on flyspray? you want to experiment with other delays than 3ms ? 18.25.19 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 18.28.19 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 18.30.17 # novel question funman, is there any real penalty to that buttonlight flickering with uSD? (decreased battery life/premature death of the light/ -or- just because it's inconsistant with other player behavior?) 18.30.21 Join Strife89 [0] (~Strife89@adsl-67-49-42.mcn.bellsouth.net) 18.31.26 # i didn't measure (or tried to) any impact, it's just for consistance (same thing happens on fuzev1/e200v2) 18.31.52 # fair enough 18.33.06 # funman: just go for it, if it's an improvement 18.34.16 # New commit by 03funman (r26060): fuzev2: leave at least 3ms between scrollwheel events ... 18.35.55 # kugel: I got three warnings but I am not sure if they are just because of the "hacked" makefile 18.38.18 # http://pastebin.com/pvHze58q with r26039 and an M5 sim with FM functions enabled 18.40.30 Quit kugel (Ping timeout: 264 seconds) 18.43.59 Join kugel [0] (~kugel@rockbox/developer/kugel) 18.44.37 # pixelma: :/ that's the warning we try to resolve 18.49.31 # pixelma: no other warnings, though? 18.49.41 # except the buffering.c one I mean 18.50.31 # the midiutil and a different ones (all of the same type) which have been there before though 18.50.56 # I think they don't matter here 18.51.00 Join merbanan [0] (~banan@c-94-255-217-84.cust.bredband2.com) 18.51.10 Join CGL [0] (~CGL@190.207.156.230) 18.51.12 # * kugel wonders if r26058 also helps on as3525v2 18.51.15 # funman: ^ 18.51.37 # amiconn mentioned cpu_/core_sleep problems on PP 18.52.44 # i think i tried that already 18.52.58 # btw i wondered what would happen if we wrote CGU_PROC & CGU_PERI in one ldm instruction 18.53.03 # stm* 18.58.03 # looking at i2c -> i can trigger INT_AUDIO interrupt just by reading IRQ_ENRD2 18.59.41 Nick CGL is now known as X_CGL (~CGL@190.207.156.230) 19.00.36 Nick X_CGL is now known as n00b2Hack_CGL (~CGL@190.207.156.230) 19.00.46 Quit kugel (Remote host closed the connection) 19.02.50 Nick n00b2Hack_CGL is now known as CGL (~CGL@190.207.156.230) 19.03.01 Nick CGL is now known as GGG (~CGL@190.207.156.230) 19.03.45 Quit funman (Quit: free(random());) 19.03.50 Nick GGG is now known as Gen_CGL (~CGL@190.207.156.230) 19.04.39 Nick Gen_CGL is now known as ZZZzzzz (~CGL@190.207.156.230) 19.04.39 Join Luca_S [0] (~4f083e4f@giant.haxx.se) 19.04.45 Nick ZZZzzzz is now known as Z (~CGL@190.207.156.230) 19.05.08 Nick Z is now known as ZZZZ (~CGL@190.207.156.230) 19.05.14 Nick ZZZZ is now known as ZZZZZ (~CGL@190.207.156.230) 19.05.48 Nick ZZZZZ is now known as ZZZzzzZZZ (~CGL@190.207.156.230) 19.07.14 # could you please stop that? 19.08.45 Nick ZZZzzzZZZ is now known as [CGL] (~CGL@190.207.156.230) 19.08.56 Nick [CGL] is now known as [CGL]_ZZZzzzZZZ (~CGL@190.207.156.230) 19.13.45 Join kugel [0] (~kugel@rockbox/developer/kugel) 19.13.56 # ... or may the choice of compiling host libs or rb libs be a configure option before making ? 19.15.47 # gevaerts: had a look at my sim-target-tree work? 19.17.24 # kugel: a bit. I've tried to rebase it to current master so I could see the entire thing as one diff, but I failed 19.17.36 # gevaerts: don't do that :P 19.17.51 # Why not? It was in a temporary branch! 19.18.07 # got co master && got co -b diff_branch && git merge sim-target-tree && git diff master..HEAD 19.19.04 # maybe update master and sim-target-tree so that they're on the same svn rev before 19.19.53 # gevaerts: I uploaded the entire diff on the tracker, btw 19.20.22 # (again, co==checkout, /me always forgets his aliases are not default) 19.22.35 # gevaerts: don't do that because rebasing is not suitable for this situation 19.23.03 # I don't even know how it handles the merge commits 19.23.10 # kugel: what? git co is not common everywhere? 19.24.58 Join stoffel [0] (~quassel@p57B4A012.dip.t-dialin.net) 19.25.42 Quit GeekShadow (Read error: Connection reset by peer) 19.26.38 Join mikroflops [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) 19.27.49 Join LowRider [0] (~LowRider@dhcp-095-096-028-100.chello.nl) 19.27.49 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 19.29.19 # * LowRider Brand New!Notebooks and LCD TVs.Discounts up to 30%. The newest electronics only http://www.elplace.com/ 19.29.36 Mode "#rockbox +o gevaerts" by ChanServ (ChanServ@services.) 19.29.38 Kick (#rockbox LowRider : ) by gevaerts!~fg@rockbox/developer/gevaerts 19.29.41 Mode "#rockbox -o gevaerts" by ChanServ (ChanServ@services.) 19.30.21 Quit mikroflops_ (Ping timeout: 240 seconds) 19.32.41 # kugel: I'm going to assume that the patch indeed does what your description says it does :) 19.36.36 Join funman [0] (~fun@rockbox/developer/funman) 19.36.39 # gevaerts: still problems looking at it? 19.37.06 # kugel: no, but, well, you know how big that diff is :) 19.37.13 # pamaury: i have found the usb init code on clipv2! 19.37.30 # gevaerts: you could look at the individual commit diffs 19.37.31 # funman: great ! 19.37.39 # kugel: not after that merge! 19.37.44 # funman: what does it do ? 19.37.45 # although they're somewhat hard to find with that merge commits 19.37.50 # pamaury: it looks like the as353x one 19.37.52 # That's why I wanted a rebase :) 19.37.56 # pamaury: dunno ;) 19.38.04 # i'm looking at i2c code for now 19.38.12 # at which address ? 19.38.17 # it is executed in the AUDIO isr 19.38.25 # gevaerts: I think searching for "Thomas Martitz" in the shortlog view on repo.or.cz 19.38.31 # +works 19.38.43 # huh, that's highly logical 19.38.59 # kugel: it doesn't really matter. Moving files around isn't *that* exciting to look at 19.39.49 # funman: true, there are lots of references to usb registers, that's great 19.40.25 # pamaury: i have just looked at reference to 0x804 bit 1 which is soft disconnect of dctl in linux 19.40.59 # I'll have a closer look at it later, I'm just wondering why it's in the audio isr... 19.41.17 # is it shared in some way with something else ? 19.41.26 # we detect usb this way on as3525v1 19.41.32 # and soon, on as3525v2 too 19.41.47 # how ? 19.41.58 Join webguest17 [0] (~57da58a3@giant.haxx.se) 19.41.58 # the usb plug causes an audio isr ? 19.42.24 # I went to http://translate.rockbox.org/edit.php?lang=espanol and filled in the spanish translations 19.42.35 # pamaury: yes, look at ascodec-as3525.c 19.42.50 # Iḿ going to submit it to the patch tracker, is there anything else I should do_ 19.42.56 # ? 19.43.49 # funman: ok, I saw it once but wondered what it was doing here :) 19.44.15 # kugel: that looks OK I think. I guess one of the next steps would be to unify init() in apps/main.c? 19.44.45 # webguest17: I think that's all. Make sure to provide your real name on the tracker 19.45.03 # gevaerts: that could be done yes, but it's not very critical 19.45.08 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 19.45.41 # I'd like to resync the pth work to the latest changes and submit that too 19.45.45 # ok, sounds good, just saw the message about the IRC chat on the tracker page and figured I should check in here 19.45.47 # I think it should be done at some point, but you're right, no hurry 19.47.24 Quit stoffel (Remote host closed the connection) 19.49.32 Quit webguest17 (Quit: CGI:IRC (EOF)) 19.50.03 # kugel: I couldn't figure out a function that seems non standard specific to diacritics in lcd-bitmap-common, and idea ? 19.50.50 *** Saving seen data "./dancer.seen" 19.55.04 # ranma: i think reading ENRD has an effect on clearing interrupts 19.59.49 Join voRia [0] (~voria@ppp-7-75.98-62.inwind.it) 19.59.52 # Yes, that's true. 20.01.39 # if i add a read of ENRD2 at the end of ascodec_init() then the code works as expected on fuzev2 20.01.47 Part voRia ("Leaving.") 20.01.59 # but after backlight goes off it doesn't work 20.02.08 # Interrupt requests in ENRD[012] are cleared on read of the corresponding register. 20.02.51 # Better designs have a separate interrupt_clear register instead of having the clear as a side-effect of read... 20.04.14 # well the interrupt just stop to happen and i should see a lot (for adc) 20.04.24 # Hmm, I thought that was specified in the Datasheet, but apparently not. 20.04.41 # I guess I must have found that out while writing the as3525 audio_irq code... 20.05.13 # start -> dbg menu to see the counters of i2c -> can see it moving and stop at 11833 int_audio_ctr & 7 int_adc 20.05.22 # To be sure to have cleared all interrupt sources you should read all 3 ENRD-Registers 20.06.04 # we don't use ENRD1 though 20.06.50 # That's why my INT_AUDIO handler does a 3-byte read starting with ENRD0 20.07.00 Quit ssorgatem (Read error: Connection reset by peer) 20.07.16 Join ssorgatem [0] (~ssorgatem@83.54.169.89) 20.07.54 # If you do single-byte reads for ENRD0 and ENRD2, you have to send the address twice 20.08.07 # So in the end the three-byte read is not slower. 20.09.05 # ADDR DATA ADDR DATA vs ADDR DATA DATA DATA should be pretty much take the same time 20.09.25 Join ssorgatem_ [0] (~ssorgatem@181.Red-88-8-243.dynamicIP.rima-tde.net) 20.10.39 # hm but why interrupts stop all of a sudden ? 20.11.52 # Maybe check that no one else has overwritten ENRD? 20.12.03 # That's why I had to change the charger control code. 20.12.15 # supposedly it uses the same code 20.13.02 Quit ssorgatem (Ping timeout: 265 seconds) 20.13.03 # hm but we use the special PMU registers on v2, it might have an effect 20.13.35 Quit JohannesSM64 (Quit: WeeChat 0.3.3-dev) 20.14.36 Join cr [0] (~cr@151.95.159.239) 20.15.16 # You could try if it's lowactive instead of highactive on AMSv2... 20.15.41 # but in 10s i see like 20000 INT_AUDIO interrupts 20.16.55 # if i comment IRQ_HIGHACTIVE it's teh same 20.16.57 # So, you see INT_AUDIO interrupts, but only the adc finished path is not taken? 20.17.21 # nope it's taken 10 or 15 times 20.18.58 # actually it seems to stop when i enter debug menu :? 20.19.10 # (view HW info) 20.20.01 # Then I can only assume something is writing to ENRD2 and setting bit0 to 0, disabling the interrupt source. 20.20.15 # Or the bitfield meanings are different. 20.21.51 # oh i see a suspicious adc_read() 20.22.30 # right! 20.23.04 Join saratoga [0] (~463f90ed@gateway/web/freenode/x-muiafugysxcsulse) 20.23.15 # btw, thousands of INT_AUDIO interrupts per second doesn't look normal, does it ? 20.23.40 Quit Strife89 (Quit: Reboot.) 20.24.07 # Hmm, good question. 20.24.53 # USB detection works fine (didn't try charger or rtc) 20.25.02 Join benji13 [0] (~benji13@189.107.185.112) 20.25.56 # You could try just disabling the adc interrupt and wait. 20.26.20 # that's what i'm doing to avoid deadlocks when the INT_AUDIO stop 20.26.51 # Did you also disable the ADC bit in ENRD2? And it's still generating thousands of INT_AUDIO? 20.27.54 # yes 20.28.07 # ~2000 per second 20.29.04 # Do you have a patch for debug info in the menu? 20.29.21 # kugel: I believe I could use a slightly newer gcc if that could make a difference? My cygwin install is quite old and I onbly updated a few tex packages maybe 20.30.30 # http://pastie.org/961833 20.31.07 # Hmm, my current build has debug enabled, so I should easily get at the stats on my AMSv1... 20.32.10 # 30 int_audio in 10s 20.32.22 Part Trou ("Leaving") 20.34.30 Quit benji13 (Quit: Leaving) 20.36.51 Join Xerion [0] (~xerion@82-170-197-160.ip.telfort.nl) 20.37.04 # writing 0 to all 3 registers & all combinations of pushpull/highactive -> same effect 20.37.43 # it wants to tell us something 20.40.15 # So, maybe it's connected to a different irq? 20.40.33 Join arbingordon [0] (~w@unaffiliated/arbingordon) 20.40.35 # you mean there's another unrelated condition which triggers it ? 20.42.14 Join DataGhost [0] (~dataghost@17-18-ftth.onsnetstudenten.nl) 20.42.14 Quit DataGhost (Changing host) 20.42.14 Join DataGhost [0] (~dataghost@unaffiliated/dataghost) 20.42.15 # I mean, maybe the audio block interrupt line is not connected to interrupt source 9 on the VIC 20.42.31 Quit kramer3d (Quit: This computer has gone to sleep) 20.42.37 # Instead source 9 is connected to something else that generates your 20000 ints per second. 20.43.31 # So effectively you're polling the ENRD* status very often instead of reacting to the proper interrupt. 20.44.18 # At that rate you may call the next async i2c read while the last is still unfinished. 20.44.31 # audio9 is used for enabling usb at least 20.44.45 # That would screw up the reading and explain why you suddenly don't get the ADC notices anymore 20.46.00 # does the OF use interrupts? 20.46.06 # on amsv1 20.46.14 # IIRC not 20.46.47 Quit cr (Quit: It's time to live and it's time to die!) 20.46.49 # don't see it in the isr table 20.47.33 # clipv2 use the same table than clipv1, but it has the interrupt 9 (supposedly audio) too 20.49.02 Join ssorgatem__ [0] (~ssorgatem@181.Red-88-14-186.dynamicIP.rima-tde.net) 20.49.37 # i'm gonna try the unused ones 20.49.45 Quit ssorgatem_ (Ping timeout: 246 seconds) 20.50.19 # Ah, wait. I'm used VIC_INT_EN_CLEAR = INTERRUPT_AUDIO;, so async_read can't get called again until the read is finished. 20.50.35 Join Strife89 [0] (~Strife89@adsl-67-49-42.mcn.bellsouth.net) 20.51.21 # Maybe there's some ENRD3? Something else that uses the AUDiO_INT and is not acked so you have a 'screaming' interrupt line. 20.51.23 Join benji13 [0] (~benji13@189.107.185.112) 20.51.41 # And it's 'only' 2000 irqs per second because it's limited by the i2c read spead. 20.52.24 Nick [CGL]_ZZZzzzZZZ is now known as [CGL] (~CGL@190.207.156.230) 20.56.21 # ive found some code which reads IRQ_ENRD2 and set bit 0 20.59.46 # To verify it's source 9, you could mask the irq, read the vic raw irq status, trigger it using an adc read, wait a little, read the vic raw irq status again. 21.00.24 # i see 21.01.03 # Maybe insert a 'read ENRD*' before the first 'read the vic raw irq status' 21.01.05 # but supposedly if we have continuous interrupts the condition is always present ? 21.01.32 # funman: hm, the scrollwheel works OK now, still not optimal though 21.01.42 # kugel: i think i borked repeat 21.01.43 # very fast scrolling is now impossible it seems 21.02.05 # kugel: try with 1 or 2 ms ? 21.03.02 # Well if you see some other masked irq in the raw status getting triggered by it you'd see it's most likely that one instead of 9 21.03.13 # I think it needs more thinking. the e200v1 irq works well 21.03.42 # the difference is that you can scroll faster because the wheel is bigger size-wise, and that the fuze's wheel triggers twice as often 21.03.50 Join mt [0] (~mtee@41.233.140.212) 21.03.55 Quit mt (Changing host) 21.03.55 Join mt [0] (~mtee@rockbox/developer/mt) 21.03.56 # But ideally you'd do the check somewhere early in the startup, so if something later triggers the stuck interrupt it's not stuck yet. 21.04.23 # I'll have a look in a gsoc-free minute, not too early though :) 21.05.47 # hm, since when does fm radio work? i missed something 21.06.39 # kugel: not sure if it works fine there were some bug reports when i added it (1 week ago or so) 21.07.44 # last time I tried, a couple of days ago, it worked great. even preset scanning :) 21.08.16 # i supposed it got fixed by a random commit 21.09.23 # ranma: it's the good one: before ascodec_init(), vic raw intr = 0, after, = 1<<9 21.09.49 Quit Luca_S (Quit: CGI:IRC) 21.11.02 # So the question is why acking the IRQ doesn't work. :) 21.11.17 # we're only 'acking' the vic 21.11.24 # ah no we're not 21.11.55 # well it should be automatic with the vic 21.12.00 # with vector mdoe at least 21.12.21 # No, the ENRD[0-2]-read should effectively be the ACK 21.12.30 # right 21.12.38 # on the as3517 of as3525 21.12.43 # about as3543, .. 21.13.14 # *you are now aware that we have some linux source code for as3543* 21.14.06 # #define AFE_AS3543_ID (0x27) 21.14.14 # hu ho 21.14.21 # is there a define using as3543 ? 21.14.38 # pamaury: in audio code only 21.15.15 # Hmm, what about the AFE_PMU_ENABLE register muxing? 21.15.22 # 0x27 shouldn't be an ID, so perhaps we're reading the wrong registers 21.17.15 # it's used with registers 0x17 - 0x1B 21.17.55 # 1B = backlight, the others = ? 21.19.13 # 1A = AFE_PLL 21.19.38 Join b0hoon [0] (~quassel@unregister005160097217.c160.msk.pl) 21.20.32 # The ascodec_read to ack the IRQ should make sure to switch to bank0 first (write 0 to AFE_PMU_ENABLE) 21.20.51 Join B4gder [0] (~daniel@rockbox/developer/bagder) 21.21.24 # irq are disabled when using AFE_PMU_ENABLE but i didn't think a reset was required 21.21.34 # e.g. the linux as3543_write/read is a wrapper to write/read_mux with bank=0 21.22.41 # adding 'ascodec_write(AS3543_PMU_ENABLE, 0);' at the end of ascodec_write_pmu() -> same 21.24.29 # New commit by 03b0hoon (r26061): Promote Packard Bell Vibe 500 to stable. 21.25.43 # AMS website show as3518 & as3542 but no available datasheets 21.26.06 # b0hoon: congrats for this port 21.26.22 # funman: thank you :) 21.27.54 Join CFP [0] (~Create@ip-118.net-81-220-138.rev.numericable.fr) 21.27.59 Join TFGBD [0] (~i4hjer@c-98-225-178-26.hsd1.pa.comcast.net) 21.28.04 # funman: but it's nothing comparing to your work on sandisk's... 21.28.13 Quit CFP (Client Quit) 21.28.13 # ah nevermind the 0x27 is a content, not an index 21.28.58 # b0hoon: i think i spend wayyyyyyyyyyyy too much time on this 21.29.08 # Is there an exe based rockbox bootstrap for Portable Media Center Windows CE based Platforms like the Zune? 21.29.15 # no 21.29.54 # I'm sure you are aware the Zunes can now run any unsigned exe, right 21.30.08 # right 21.30.19 # good stuff 21.30.37 # no one showed up with a patch for making rockbox run on zune though, we're all waiting ;) 21.30.55 # jhMikeS: "[0 ... AUDIOHW_EQ_BAND_NUM-1] = -1" is that a gcc extension? 21.31.10 # I'd imagine the Gigabeat PMC version would run without modification on the first models 21.31.30 # buttons are probably different 21.31.35 # the 0x38 'UID0' register reads as 0xA8 on fuzev2, not 0x27 like linux code suggests 21.31.37 # Huh, as353x has mp3 hw decoding? 21.31.45 # not as far as we know 21.31.48 # I guess someone just needs to write that magic .exe 21.31.56 # New commit by 03b0hoon (r26062): front page: move the PB Vibe 500 to the stable category. 21.32.10 # ranma: some have h264 decoding too, but we're not using the as353x soc, just parts of it 21.32.25 # Hmm. 21.32.41 # ranma: i have the as3531 datasheet (the one without h264) but there's nothing to be seen there 21.33.41 # ooooh perhaps not 21.33.52 # irqenrd_1 = 0x24 21.35.00 # irqenrd_1 = 0x25, according to another page of the datasheet :/ 21.37.05 # Well, you could write a 0 to it in ascodec_init(), just to be safe :) 21.37.18 # * b0hoon supposes that the front page won't change automatically, hm. 21.37.34 # Bagder: ping 21.38.13 # ranma: writing 0 to 0x23 & 0x24 + reading -> same :/ 21.38.15 # or... B4gder: ping 21.38.41 # b0hoon: you should change status in tools/builds.pm too 21.38.43 # * B4gder pretends he's not here 21.39.05 # B4gder: hi. why? :D 21.39.23 # because I'm lazy and scared of having to do actual work! 21.40.59 # one can not argue with that :) 21.41.19 # B4gder: ok, so may i ask you in your free time to update the front page, please? 21.41.26 # just did it 21.41.57 # funman: have done it already 21.42.07 # * ranma needs some sleep now, oyasumi... 21.42.16 # ranma: btw, if we make usb work, we'll need new bootloaders i think 21.42.26 # aligato ranma 21.42.41 # B4gder: thanks alot 21.43.08 # writing 0xff to 0x23 / 0x24 has an effect: interrupts stopped quickly, next step: try each bit 21.43.50 Quit saratoga (Quit: Page closed) 21.44.13 # funman: Well, it's semi-working already :) 21.44.14 # http://pastie.org/961881 21.44.56 # New commit by 03funman (r26063): adc-as3514.c: cosmetics ... 21.47.02 # the ffmpeg decoder stored the decoded samples in floating point format (http://www.pastie.org/961874 line 1403), the sim can't work with that, can it ? (I'm getting too much noise with the output, sort of like the noise you get from applying a ridiculous gain on the signal) 21.47.18 # s/stored/stores 21.48.33 # mt: I don't know if sdl can, but my alsa sim work should be able to handle it 21.50.54 *** Saving seen data "./dancer.seen" 21.51.09 # mt: look in uisimulator/sdl/sound.c:315 if you can change the format 21.52.18 # kugel: Is the alsa sim stuff still in your git repo or in svn ? 21.52.23 # it's signed 16 bits system order -> little endian on x86 ? 21.52.28 # funman: ok thanks, will look there 21.52.51 # mt: in the git repo, and not up to date but I can have a look at updating 21.52.59 # in SDL_audio.h you can only select byte order, signed/unsigned and 8/16 bits 21.54.07 # also the most recent commit removed that ability because I thought it's useless :p 21.54.17 # :D 21.54.25 # well it sort of is 21.54.53 # I could commit the code as is right now, not caring about that noise, since I should get rid of the floating point stuff anyway 21.58.05 Quit bluebrother (Disconnected by services) 21.58.08 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 21.58.21 Quit bieber (Ping timeout: 246 seconds) 22.02.07 # mt: try to dump samples in a file and ffmpeg -i foo -acodec pcm_s16le out.wav? 22.04.35 Quit funman (Quit: free(random());) 22.05.10 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 22.25.25 Quit B4gder (Quit: It is time to say moo) 22.25.58 # New commit by 03jethead71 (r26064): YUV Dither: r12 saving was removed but stacked parameter load offset wasn't changed to compensate, resulting in an improperly aligned dither kernel. 22.27.38 Quit kugel (Remote host closed the connection) 22.30.57 Join digitalz [0] (~digitalz@85-202-57-18.internetia.net.pl) 22.35.37 # * digitalz Discounts!! Our Special Limited Time Offers Up To May,22!!!New BranD!! Notebooks,Plasma and LCD TV's.Buy your electronic needs at our unique prices. Laptop Sony VAIO® VGN-FW590FFD-575,57$!!!Apple MacBook® Air MC234LL/A-695,27$!!! http://www.elplace.com/ 22.35.58 Quit digitalz (K-Lined) 22.37.02 Join kugel [0] (~kugel@rockbox/developer/kugel) 22.42.18 # * kugel is going the sim-target-tree in a few seconds 22.42.35 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 22.52.35 Quit Jaykay (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 22.54.22 Part b0hoon ("GTG. Bye.") 22.54.24 Join robin0800 [0] (~quassel@genkt-050-207.t-mobile.co.uk) 22.57.00 Quit TheSeven (Ping timeout: 276 seconds) 22.59.08 Quit DataGhost (Ping timeout: 240 seconds) 23.00.21 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 23.00.27 Quit liar (Quit: Verlassend) 23.00.52 Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-hlzjjzgdsdosrljp) 23.02.50 # New commit by 03kugel (r26065): - Move uisimulator/sdl/*.[ch] into the target tree, under firmware/target/hosted/sdl, uisdl.c is split up across button-sdl.c and system-sdl.c. ... 23.04.51 # jhMikeS: r260055 breaks archos 23.05.37 # Devices which don't have HAVE_POWEROFF_WHILE_CHARGING defined are *physically* incabale of being powered off while connected to the charger 23.06.13 # That means a recorder will _hard freeze_ when it's done charging now (and no actively used) 23.07.10 Quit benji13 (Quit: Leaving) 23.11.21 # New commit by 03kugel (r26066): Get checkwps going again, don't mess with sdl in it. 23.12.16 Quit intrados (Ping timeout: 264 seconds) 23.12.22 # amiconn: not only archos I think 23.13.06 # probably 23.13.38 # amiconn: I see. 23.15.13 Join intrados [0] (~intrados@adsl-99-90-140-105.dsl.wotnoh.sbcglobal.net) 23.15.17 # I think HAVE_POWEROFF_WHILE_CHARGING should be defined for the beast (because it actually can be powered off), and software controlled charging needs special handling in another way (another #define or perhaps a combined one with multiple possible values) 23.15.58 # yes, it's far more trouble than it's worth and quite annoying to see the splash just because it's plugged (which it still shows) 23.16.10 # The Player and Recorder do have a charging screen 23.16.22 # if you try to power down/ 23.16.23 # ? 23.16.34 # Right now it's only used when rockbox is flashed, and the box is plugged in 23.16.48 # ipods will just reboot also 23.17.08 # i just came on to point that out but amiconn beat me to it ik see 23.17.09 # One idea to extend it was to make "poweroff" go to the charging screen if the user tries to power off on targets which can't 23.17.33 # It just hasn't been done yet... 23.17.49 # I wanted to do something like that, then once it's finished, power off 23.17.54 Quit robin0800 (Quit: No Ping reply in 180 seconds.) 23.18.20 Join robin0800 [0] (~quassel@genkt-050-207.t-mobile.co.uk) 23.22.16 # are we really goinng to allow ape tags on mp3? 23.22.49 # we should probably discuss it 23.23.11 # Torne: The majority of people today have said no 23.23.19 # I'd say no 23.23.21 # as currently implemented it looks pretty harmless on SWCODEC at least 23.23.28 # Last time it was discussed it came out as no I think 23.23.32 # (unless we also support vorbis comments on SID) 23.23.33 Join fml [0] (~chatzilla@pD9E3C89C.dip.t-dialin.net) 23.23.46 # it means the files are corrupt, no? 23.23.56 # ape tags aren't properly desynched 23.24.13 # so they can be interpreted as broken mpeg frames 23.24.16 # APE tags aren't native to mp2/mp3 23.24.26 # My main beef is just that it wasn't discussed at all, and done for hwcodec too 23.24.34 # yah, i mean from the decoder's pov 23.24.53 # The consensus in the past was that rockbox should support the native tagging format(s) of every audio format it supports, but not more 23.25.29 # mp3 is a special case though since it has no native format, 2 widely used ones, and a third less common one 23.25.59 # id3 is designed to be ignorable by decoders though, ape is not 23.26.13 # so its presence means the file is observably corrupt 23.26.25 # because it takes care not to put a sync word in the tag somewhere? 23.26.38 # Hello. There has been some discussion about FS#11271 (font with digits only). We came to the conclusion that it should not be part of the font pack but rather be part of a theme bundle. But if someone would install such theme, the font would be copied to the font folder, and we'd have the same situation as we had if the font was in the font pack. 23.26.48 # yes, great care in fact 23.26.49 # I'd consider id3v1 and id3v2 the native tagging formats for mp2/mp3 23.26.56 # fml: That is a good point 23.27.12 # fml: The codepage idea sounded a good one to me 23.27.24 # New commit by 03jethead71 (r26067): Revert r26055 since it breaks certain Archos targets. 23.27.32 # amiconn: Maybe not native, but at least a standard in practice. 23.27.40 # is avoiding a sync word really a problem for a tag that can only go at the end of the file? 23.28.06 # i though id3v2 needed them since it has to be at the start of the file for streaming, while id3v1 didn't since its always the end 23.28.50 Quit robin0800 (Quit: No Ping reply in 180 seconds.) 23.29.03 # I mean there's no difference in how the font gets into the font directory. And hence there's no point in not letting the new font into the pack. The idea with the lang files telling what char areas they need and fonts telling what char areas they cover is of course very good. 23.29.15 Join robin0800 [0] (~quassel@genkt-050-207.t-mobile.co.uk) 23.29.38 # Anyway, I think the current position is "native tags only", and if people want to change that they need to get a consensus *first* 23.29.44 # saratoga: files with ape tags can make bad noises at the end of playback on some dumb decoders. i have heard. :) 23.29.44 # exactly 23.30.00 # fml: The difference is that we don't provide fonts that can't be used to render the default language. If someone downloads a theme it's more or less their own responsibility - themes can also break the UI in plenty of other ways as well. 23.30.01 Quit TheSeven (Remote host closed the connection) 23.30.07 # gevaerts: The consensus earlier seemed to be revert, but he hasn't replied to mails 23.30.15 # Llorean: Well, if you define native as "being designed for that audio format", id3 *is* native - just implemented after the format itself, not together with it 23.30.23 # Torne: is our decoder dumb like that? 23.30.34 Join Buschel [0] (~ab@p54A3CAD4.dip.t-dialin.net) 23.30.47 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 23.30.58 # saratoga: no idea, and it could be fixed not to be if it was, on swcodec 23.31.09 # amiconn: Ah. I tend to think of native as a two-way street but that's a good way of looking at it too. 23.31.12 # We should probably show a splash if we detect a corrupt file :) 23.31.18 # Llorean: wouldn't it then be sensible to keep the fonts that have been installed with a theme in a special ("private") folder? 23.31.22 # gevaerts: I think currently we just skip them. 23.31.22 # a player that knows what ape is can obviously ignore it 23.31.30 # gevaerts: nah, silently crash :) 23.31.47 # we should do something for unplayable files, yeah 23.31.53 # fml: That could be a good idea 23.32.03 # IIRC you walk an mp3 file one frame at a time looking at the sync words, so if the tag is at the end like id3v1 or apev2, the risk of detecting it is very small, since the sync word must appear, and it must appear at precisely the right location 23.32.06 # New commit by 03jethead71 (r26068): Gigabeat S: Not defining HAVE_POWEROFF_WHILE_CHARGING is far too disruptive given that it's not obligatory for the hardware to avoid poweroff while ... 23.32.22 # fml: It might actually be ideal to allow themes to keep their personal fonts in the same folder as their bitmaps (as themes with fonts using the same name can overwrite each others' which can be a problem if two people have converted the same font in different ways, or similar) 23.32.26 # we skip unplayably large aac files atm 23.32.26 Quit amr1 (Quit: CGI:IRC (EOF)) 23.32.26 # and this is a source of confusion to some peopple i've takled to 23.32.40 # i'm sure it can be made to happen, but i'm skeptical a correctly parsing decoder will ever have it happen on a real file 23.33.11 # less that we skip them and more that the parser fails on them gracefully :) 23.33.21 # Feeding random data to the MAS (on hwcodec) often causes funny noises 23.33.29 # saratoga: it's only an *additional* argument against it 23.33.38 # Torne: Is there a reason we still don't support arbitrary length MP4? Is it a "can't" with the way we're set up or something? 23.33.49 # *Imo* we should detect and skip ape tags on mp3, but nothing more 23.33.57 # we don't know how to do it since none of us can understand the mp4 spec 23.34.05 # Llorean: cant without changing the way wed use the seek index 23.34.11 # i think 23.34.23 # Torne: Does that mean they could be playable without seeking (or without fast or accurate seeking)? 23.34.32 # not sure 23.34.32 # gevaerts: Llorean: the problem with this would be (a) that some fonts would be stored many times and (b) that fonts are loaded automatically only if they are stored in the fonts folder, and we don't explicitly load themes on start. If we did it then we could store fonts anywhere and they would load correctly. 23.34.38 # yeah i had a patch to do that a while ago, but we weren't sure it would work on all files 23.34.51 # the main use case is apple audio books though.. 23.34.54 # it basically stepped an mp4 file like an mp3, going from frame to frame without using the header to find them 23.35.03 # fml: If they're WPS fonts (which is the only location it would make sense for) does the automatic loading actually come into effect? 23.35.21 # i think the concern was that it might have been possible to put stuff in between frames in an mp4 file 23.35.22 # for which seeking is useful :) 23.35.43 # Llorean: So it would still have to put a custom ui font defined in the theme in fonts? 23.35.54 # AlexP: Huh? 23.35.57 # Llorean: do you mean that the WPS specifies where the font is stored anyway? 23.36.16 # AlexP: Can we currently have more than one font for the list? I'm not too familiar with multifont. 23.36.22 # Llorean: A theme can define a custom UI font 23.36.23 # Llorean: so that these fonts can be stored anywhere? 23.36.30 # A font that isn't in the fontpack 23.36.31 # if the main argument against apev2 support isn't how much we like the standard, nor how much it costs to implement, what exactly is the argument? 23.36.39 # Llorean: theme!=wps 23.36.45 # So wouldn't that need to be in fonts to be autoloaded? 23.37.18 # years ago i thought we concluded it wasn't worthwhile because it would be hard to work into our metadata parsing efficiently, but it seems that is not the case 23.38.21 # wasn't it also about potentially useless seeking? 23.38.25 # gevaerts, AlexP: Aren't fonts loaded via viewport definition? 23.38.35 # Which means they're in a wps/sbs/whatever, which is manually loaded at boot. 23.38.43 # So the only font that is "autoloaded" is the one in the .cfg? 23.38.47 # Even if there isn't a ui viewport used? 23.38.54 # Llorean: the one in the .cfg comes with the theme... 23.39.04 # pixelma: maybe, but that only happens if you have the apev2 tag and no id3 tag, so it hardly seems like a problem 23.39.44 # what if I have no tags at all? 23.40.09 # gevaerts: If it's a UI font, it should be okay to go in the main fonts folder. I didn't mean that *all* their fonts should go in a personal folder, just ones that aren't necessarily usable to switch to manually 23.40.29 # gevaerts: Basically, give them the option of using a personal folder when necessary. 23.40.44 # it'll seek to the end of the file anyway if you have no tags (since the id3v1 tag could be there), i'm not sure if theres another seek or not 23.41.03 # Llorean: ok, that could work 23.41.06 # hmm, I experience hard crashes with my iPod Video builds at an address that points to settings_list. 23.42.29 # gevaerts: It's not ideal, since sometimes they'll make all the fonts "private" except the main UI one when they don't need to be (and sometimes they'll stuff extra ones in the fonts folder that shouldn't be there) but it gives conscientious authors the tools they need, which is close to the best you can do unless you get "picky" loaders that reject fonts that are incompatible with the language (and vice versa) 23.43.13 # Llorean: yes, it looks like a good compromise that's easy to implement 23.43.26 # * gevaerts only guesses at that last bit 23.43.30 # pixelma: looking at the code, i think it'll seek 96 bytes forward from the current file position 23.44.35 # i'm not sure what that does physically, since sectors are hundreds or thousands of bytes, probably it doesn't actually do anything to the disk, but i don't understand well enough to say for sure 23.44.44 # * kugel doesn't the ape problem, i.e. what's the reason against reading them? 23.45.17 # * gevaerts thinks that the main problem is that this was committed without any prior discussion 23.45.29 # like 10 years ago there was a big argument about id3v2 verses apev2 on the internet, ever since then people have had very strong feelings about file tags 23.45.46 # Llorean: but then we don't need to change anything! It's just the matter of how authors organize their theme bundles. 23.46.02 # well, I can understand that someone doesn't see a discussion needed he/she didn't know about that general consensus to not read ape 23.46.09 # was it on the NoDo list? 23.46.11 Join ssorgatem [0] (~ssorgatem@83.54.169.89) 23.46.18 # kugel: yes, I just checked 23.46.26 # What's the point of having a consensus if people are going to ignore it anyway? 23.47.02 # fml: Well, the ideal would be to fix the problem in the language / font loaders so that nothing else matters. 23.47.32 # New commit by 03alle (r26069): Format FM frequency depending on the regional settings (FS#11273) 23.47.33 # gevaerts: ah, I didn't know it's on the NoDo list. then yes, he simply ignored it 23.47.46 Quit robin0800 (Quit: No Ping reply in 180 seconds.) 23.48.13 Join robin0800 [0] (~quassel@genkt-050-207.t-mobile.co.uk) 23.48.29 # well presumably he didn't realize it was on the list 23.48.47 # surely reading the nodo list isn't too much to expect? 23.49.16 # Llorean: that would be a safety check, but if all authors behave then we wouldn't actually need it 23.49.49 # fml: There's no way to make authors behave though. Many of them won't even know they need to, probably. 23.49.56 # mind you, the one in the docs folder is not exactly up-to-date 23.50.09 Quit ssorgatem__ (Ping timeout: 276 seconds) 23.50.58 *** Saving seen data "./dancer.seen" 23.51.04 # If he looked at the NODO in the source, then I can't blame him. That should be updated or removed 23.51.08 # Llorean: sure! That's like everywhere in the real life! :-) 23.51.31 # anyone mind if I replace the one in the source with a link to the wiki? 23.51.43 # saratoga: sounds like a good idea 23.52.05 Quit merbanan (Ping timeout: 246 seconds) 23.52.15 # AlexP: maybe, but IMHO we *can* blame him for not discussing this at all 23.52.21 # certainly 23.52.26 # And it isn't the first time 23.52.31 # he hasn't... discussed other things either 23.52.35 # in the past ;) 23.53.44 # Given that NODO discussion is on the devcon list, what about this now then? 23.53.55 # revert 23.54.15 # yah, it can always go back in again if decided that way.. 23.54.26 # New commit by 03saratoga (r26070): Remove outdated NODO list from the docs folder. Replace it with a link to the wiki. 23.54.29 # I say revert for now (given it is on the NODO), then discuss at Devcon and re-add depending on decission 23.54.29 # the longer it sits there the more likely any mp3-with-ape-using users will expect it ;) 23.54.42 # at very least revert the HWCODEC changes, since those don't make much sense IMO 23.55.21 # now there's some discussion about themes and fonts, can I plug my question about the "Now playing" in cabbiev2 again? My idea was to make it a text (and then language) string so it is more flexible for further use and translatable to some extent. The latter refers to the problem that it is only possible in a smallish font which likely won't support many non-latin characters. Would it be acceptable to still make a lang string out of it and put a "Use 23.55.21 # English if your translation can't be displayed with the smallish font"? That'll give us a bit more localisation than there is now and as I said flexibilty for e.g. the FM screen and less bitmaps 23.56.01 # A question to all C experts: how can I ensure that an int value is in the range 0..N-1? val %= N; if (val <0) val += N;? It's from skin_tokens.c:417 23.56.13 # pixelma: Sure, localisation is always good 23.57.21 # New commit by 03gevaerts (r26071): Revert r26048. APE tags in mp3 is explicitely on http://www.rockbox.org/wiki/NoDo ... 23.58.05 # have to recheck which font that could be - and until there is a way for "inverted" text, it'll probably stay a bitmap on monochrome screens 23.58.31 # so it feels a bit hackish