--- Log for 16.05.110 Server: jordan.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 9 days and 12 hours ago 00.00.11 # gevaerts: could you comment on the 0..N-1 question? If I'm correct we could slightly reduce bin size. 00.00.32 Quit robin0800 (Quit: No Ping reply in 600 seconds.) 00.00.57 Join robin0800 [0] (~quassel@genkt-050-207.t-mobile.co.uk) 00.01.44 # fml: it all depends on what exactly you want I guess. What you propose will make sure it's between 0 and N-1, but it could be argued (for some cases) that negatives should become 0 and >=N should become N-1 00.01.53 # downloaded svn build 26070 for iPod Video crashes with "undefined construction at 000A7F4C" 00.02.16 # where do we have the map files? 00.02.50 # fml: in that case, your code would be smaller while doing the same, yes 00.02.53 # gevaerts: sure. But what I'm asking about is how to get the value into 0..N-1 by adding or subtracting N as needed. 00.03.04 # unless I'm too sleepy right now :) 00.03.11 # * Buschel is a bit in a hurry as he will start his 1 week travel tomorrow morning and wants to have usable and up-to-date rockbox on his iPod 00.04.11 # Buschel: Any chance you accidentally put the wrong RAM size version on it? 00.04.19 # fml: does your fm frequency mean, I'll only get onw decimal now automatically? 00.04.24 # +change 00.04.48 # Llorean: No. This also happens on my local builds. 00.04.58 # pixelma: If you have a region set that changes in 0.1 MHz steps, yes 00.05.12 # pixelma: yes, if you use European region settings. You'll get two digits if you use Italy (IIRC). 00.05.22 # kugel: you know there are still remaining reds? 00.05.31 # yes, just saw 00.06.03 # Imo the language/ voice mechanism shouldn't be used for stuff like wps 00.06.36 # I mean, for translating/ voicing strings which aren't part of the core (or plugins, once the support for that is done) 00.06.47 # doesn't the tuner still use 0.05 for searching? I remember the c200 tuner even saving presets this way - I know that's wrong but I still would like to see that 00.08.00 # amiconn: there already is a "use lang sting blah" tag and used for the "Next:" etc. in cabbiev2 00.08.01 # pixelma: you mean when auto scanning? 00.08.13 # yes 00.08.27 # That's a different thing - you only reuse a string that already exists 00.08.56 # Btw, I'd like to know who messed up voice ids recently... 00.09.15 # nope, there were 2 or so added just for this purpose, "Next:" being the example that comes to mind 00.09.24 # Might be. But to be honest: in 99.99% of the cases you'll have a zero at the end which is not needed. 00.09.30 # only for cabbiev2 though 00.09.45 # * Buschel suspects r26051 is the case for the crahes and builds 26050 00.10.20 # the database tool needs rework :\ 00.11.07 # pixelma: were you talking to me? 00.11.22 # fml: but how can I find out now if the c200 tuner got it all wrong? 00.11.37 # kugel: everything that tries to use rockbox code on an OS needs rework... 00.11.49 # that's correct :( 00.11.59 # pixelma: you'll hear it 00.12.00 # the "Next" and cabbiev2 statements were directed to amiconn 00.12.17 # fml: I doubt it 00.12.23 # pixelma: if there is noise then something is wrong and the tuner is not properly tuned 00.12.29 # I'm not entirely sure why the database tool uses io.c.. 00.12.55 # kugel: because that made it compile at the time I guess 00.12.56 # pixelma: it's only displaying. The values is stored as before, and tuning is maded as before 00.13.07 # fml: reception isn't great with this tuner and sometimes the x.x5 sounded even better 00.13.11 # probably to provide file io because the system's functions were incompatible 00.14.02 # pixelma: but to make 0.05 changes you have to switch to a region that allows that. And then you'll automatically get two digits after the point. 00.14.08 # fml: a preset that is (even falsely) saved as x.x5 - how will it be displayed? 00.14.26 # pixelma: as x.x 00.14.52 Quit robin0800 (Remote host closed the connection) 00.15.17 # rounded up or down - what if it saved 91.55 and 91.60? and I've seen that happen 00.15.36 # pixelma: I see: it's a trade off. But I think your case is rather an exception while mine is more common. 00.16.05 # pixelma: the second digit is just cut, i.e. round down 00.16.24 Join Kitr88 [0] (~Kitar_st@BSN-210-231-196.dial-up.dsl.siol.net) 00.16.44 # it somehow feels inaccurate to me :\ 00.16.47 # pixelma: 91.5 and 91.6, respectively 00.17.11 # well, imagine 91.5 and 91.55 then 00.17.47 # Isn't the fundamental issue here that the c200 FM driver even provides those numbers? 00.17.59 # I can make the formatting so that the trailing 0 (second digit) is cut, but a non-zero not. Would it be better? 00.18.10 Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) 00.18.18 # gevaerts: maybe it is 00.18.39 Quit Kitar|st (Ping timeout: 240 seconds) 00.18.56 # But I'll have to leave in a minute. If you have any thoughts please post them on the mailing list. 00.19.10 Part fml ("Bye!") 00.19.14 # the TEA tuner in my other targets is noticably better 00.21.17 Quit Kitr88 (Ping timeout: 268 seconds) 00.21.47 Quit pamaury (Quit: Page closed) 00.21.59 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 00.22.53 Join Kitar|st [0] (Kitar_st@BSN-182-88-26.dial-up.dsl.siol.net) 00.25.08 # New commit by 03kugel (r26072): Fix last reds, database tool definitely needs rework. 00.25.48 # kugel: there was not only red for database tool, also for the OndioFM sim for some reason ;) 00.26.03 # I saw that 00.26.09 # http://www.rockbox.org/wiki/NoDoDiscussion#Add_support_for_non_standard_tag 00.26.21 # updated with the rational we discussed today 00.28.23 # kugel: *those* reds are fixed :) 00.29.17 Quit TheSeven (Remote host closed the connection) 00.29.31 # hm that was not a bad red 00.31.07 # ideally button-sdl.h should be named button-target.h so that it's not included in sim builds 00.31.10 # that email about running our libcook on solaris big endian hardware 00.31.21 # am i right in thinking theres no way such a device exists that doens't have an FPU? 00.31.26 # New commit by 03kugel (r26073): Correct button_read_device prototype for HAVE_BUTTON_DATA. 00.31.41 # jhMikeS: can you please urgently take a look at FS#11277 ? 00.32.52 # the build table is pretty damn useful these days 00.33.30 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 00.33.48 # saratoga: 32 bit solaris isn't too new. It will depend on versions I guess 00.35.17 # wikipedia says sparc v7 had an FPU in 1986 00.35.22 Quit ender` (Quit: If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell) 00.35.41 # though it looks like our makefile is broken on ubuntu too, so maybe this should be fixed 00.36.59 # saratoga: I'm not entirely sure if *all* sparcs have an FPU, but yes, the fact that it's one that runs solaris makes it more likely 00.42.56 # dark times for rockbox... green tables, but: iPod Video Sim does not build on cygwin, iPod Video for target crashes at startup... 00.43.23 Quit pamaury (Quit: Page closed) 00.43.34 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 00.43.50 # so, the build table is not "pretty damn useful", but "pretty damn misleading"... 00.45.11 # obviously it can only check for compiler errors 00.46.05 # * Buschel is just frustrated... 00.46.09 Quit TheSeven (Remote host closed the connection) 00.46.19 # pc sim build error -> http://www.pastebin.org/241094 00.47.21 # it builds fine with mingw here 00.47.32 # in fact, I just wanted to update my iPod before my trip. Now I am stuck since 1 hour or so :( 00.47.56 # will use my good old r26050 and hope that the dust settled until end of next week 00.47.57 # Buschel: Can you use a slightly older revision for now? 00.48.11 # AlexP: that's what i will do :) 00.48.43 # good plan :) 00.49.06 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 00.49.36 Quit pamaury (Quit: Page closed) 00.50.04 # ok guys, have a good night and see you next weekend! 00.50.17 Quit Buschel () 00.50.39 # arg 00.50.57 # Buschel: try if that helps against the EXIT_SUCCESS error: http://pastie.org/962024 00.52.05 # kugel: the %zs introduced in r25850 and r25852 still "break" mingw builds 00.54.20 # yes, that's unfortunate 00.54.45 # for some reason that mingw ansi stdio define doesn't help 00.59.55 # I asked before but didn't get an answer - would updating gcc possibly help? I think I'm not at the latest possible under cygwin 01.00.20 # i doubt it 01.00.32 # updating cygwin might be a good idea anyway :P 01.00.45 # pixelma: I doubt it. The issue isn't exactly simple unfortunately :\ 01.01.16 # gevaerts: hm, I think it does help actually 01.01.43 # replacing the snprintf in menu.c in rockbox with __mingw_printf makes the warning disappear 01.03.06 # kugel: we're actually confusing issues here I think. Cygwin and mingw aren't *exactly* the same. If you do a regular build in cygwin, you'll get a binary that's linked against cygwin's libc, not msvcrt 01.03.24 # There's also the fact that my mingw here doesn't even have __mingw_printf 01.03.46 # gevaerts: they aren't identical, no, but the difference is only their specfiles 01.03.57 # and perhaps not the same exact version/patches 01.04.07 # it seems to have something to do with some plugins re-#defining the functions in questions which maybe breaks the mingw mechanism 01.04.13 # they're the same *target*, more or less :) 01.04.18 # Torne: but this isn't actually a gcc issue, it's a libc issue 01.04.47 # well, the import libraries and headers for msvcrt should be the same in both, barring again minor version diffs 01.05.34 # Torne: yes, if you build a mingw/msvcrt binary. 01.05.45 # Not if you build a cygwin binary 01.05.55 # Oh, er, of course 01.05.56 # gahh, __mingw_snprintf still doesn't know %lld! 01.06.24 # yeah, the spec for -mcygwin has a different include/lib path than -mno-cygwin. *blames brain* 01.06.43 Join solexx_ [0] (~jrschulz@e176104205.adsl.alicedsl.de) 01.10.07 Quit solexx (Ping timeout: 264 seconds) 01.10.27 # not sure how to solve the midiutils.c one 01.13.05 # hm, I don't see that one 01.13.26 # /home/kugel/rbdev/rockbox-git/apps/plugins/midi/midiutil.c:137: error: redefinition of ‘printf’ 01.13.26 # /usr/lib/gcc/i586-mingw32msvc/4.4.2/../../../../i586-mingw32msvc/include/stdio.h:252: note: previous definition of ‘printf’ was here 01.14.17 # I got that one too 01.14.19 # I'd say that plugins have no business stealing common names 01.14.49 # Just rename it to my_printf() in that plugin 01.15.15 # it should still be perfectly valid to override the system's printf, no? 01.16.02 # maybe, but that doesn't make it a good idea 01.16.06 # I can only imagine prototype mismatch but it doesn't look like it 01.16.48 # gevaerts: the %z things can be solved with -D__USE_MINGW_ANSI_STDIO=1 here 01.17.03 # I don't know about %zd but it works for %z(u) 01.17.27 Quit petur (Quit: Zzzzz) 01.17.36 # yes, but it doesn't work everywhere 01.17.42 # the redefinition of rockboy/doom breaks mingw's mechanism to replace it with __mingw_snprintf but that's solvable 01.17.47 # haha TTA can have both ID3 and APE tags 01.17.54 # and unless we understand where and why, that makes it unsafe I think 01.18.05 # where does it not work? 01.18.39 # well here 01.19.17 # that's very strange 01.19.34 # And from that mailing list thread you pointed to, it seems that this is indeed something that doesn't work in all versions 01.20.01 # can you post your mingw's stdio.h? 01.20.51 # http://pastebin.com/nzUSNv27 01.22.12 # it doesn't have "extern int __mingw_stdio_redirect__(fprintf)(FILE*, const char*, ...);" and friends 01.26.16 Join krabador [0] (~ubuntu@host158-217-dynamic.117-80-r.retail.telecomitalia.it) 01.31.09 # gevaerts: did you compile mingw yourself? 01.31.17 # no 01.31.45 # ubuntu's package seems to have it correctly 01.37.55 # kugel: what 01.38.04 # s your version of mingw32-runtime? 01.39.03 # Version: 3.15.2-0ubuntu1 01.39.26 # ok, I have 3.13 01.41.49 # which is nearly three years old :\ 01.43.59 # debian doesn't seem to offer any newer versions 01.44.10 # If I install ubuntu's mingw32-runtime, it works fine 01.45.37 # We'll just have to decide if requiring this newer set of libraries is ok or not 01.46.41 # I'd say yes, but debian is pretty major :/ 01.47.18 # it is indeed, but this is a package with no dependencies and no conflicts, so grabbing the package from ubuntu is easy 01.47.27 # but even then it's not completely solved. there's %lld used somewhere 01.47.43 # where? 01.47.53 # doom, d_deh.c 01.49.42 # also a few in speex.c 01.50.59 *** Saving seen data "./dancer.seen" 01.51.06 # Still, I prefer a solution that leaves eight cases looking possibly ugly to one that makes nearly every single format string hurt eyes 01.53.15 # are you sure? %lld seems to work here 01.54.31 Quit Boldfilter (Ping timeout: 264 seconds) 01.55.08 # http://pastie.org/962079 01.58.15 # that's really weird. It works in my test program 02.00.34 Quit TheSeven (Ping timeout: 268 seconds) 02.00.55 # right, it also works here in a test program 02.01.44 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 02.02.05 # this is all very weird :( 02.03.33 # I also don't get any warning in doom 02.06.31 Quit TheSeven (Ping timeout: 264 seconds) 02.07.21 # gevaerts: trying the doom cflags for the test app without success :( 02.08.07 # kugel: you did add the -D__USE_MINGW_ANSI_STDIO=1 to GCCOPTS? 02.08.14 # yea 02.09.17 # and it's there if you run make V=1? 02.09.23 # (for the doom files) 02.10.23 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 02.11.06 # yep 02.16.11 # kugel: I get http://pastie.org/962099 for d_deh.c 02.18.12 Join Rob2222 [0] (~Miranda@p4FDCBF20.dip.t-dialin.net) 02.18.51 # http://pastie.org/962103 is mine 02.21.56 Quit Rob2223 (Ping timeout: 248 seconds) 02.22.14 # * kugel likes the comment "// All deh values are ints or longs" 02.22.34 # it means they use int64_t even though it's casted to long at max 02.25.20 # All I can see is that you end up with -D__USE_MINGW_ANSI_STDIO=1 twice, and that you put it in a different place in the commandline 02.25.40 # Apart from that (and a different target) they're identical 02.26.02 # I added it to EXTRADEFINES as well 02.27.20 Quit DerPapst (Quit: Leaving.) 02.30.07 # fg@zorac:/tmp$ /usr/bin/i586-mingw32msvc-gcc --version 02.30.07 # i586-mingw32msvc-gcc (GCC) 4.2.1-sjlj (mingw32-2) 02.30.19 # I suspect that one will also be the same though 02.30.50 # gevaerts: http://mingw-users.1079350.n2.nabble.com/Multiple-definition-of-printf-with-when-using-USE-MINGW-ANSI-STDIO-td3559137.html explains why that 3.15 introduced __D_USE_MINGW_ANSI_STDIO 02.30.58 # which is apparently also the cause for the printf error 02.31.14 Join wincent [0] (~wincent@f055225162.adsl.alicedsl.de) 02.31.31 Quit wincent (Changing host) 02.31.32 Join wincent [0] (~wincent@rockbox/developer/wincent) 02.33.19 Quit TheSeven (Ping timeout: 245 seconds) 02.33.24 # ok, and that one should also be gone with new enough mingw runtime 02.35.58 # I can't find the file the cvs commit mentions 02.36.25 # which one? 02.36.38 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 02.38.09 # Anyway, if compiler-as-packaged-by-distribution-is-not-good-enough is the only problem, I see no serious reason to not just add a mingw toolchain to rockboxdev.sh 02.38.57 # that's a good idea 02.40.18 # ah, wrong repo :\ 02.42.10 # hm, the static keyword is still there in the gnuc part of __mingw_stdio_redirect__ definition 02.43.18 # ah, interesting, the stdio functions expand to functions within the source file 02.46.45 # hm, I think plugin.h includes too much 02.51.46 # gevaerts: I wonder if the __mingw_printf thing is only a temporary solution; it won't help if we ever happen to have a native win32 port 02.52.15 # kugel: maybe, but that's a problem for whoever does that port 02.53.03 Join RPG-Master [0] (~RPG-Maste@173-17-238-80.client.mchsi.com) 02.53.48 # Hey, last time I used Rockbox on my Fuze, it tended to suck the battery quicker then the default firmware. Is it doing any better these days? 02.54.06 # * kugel this mingw mess distracted me from updating my pth work :/ 02.54.32 # RPG-Master: better than before but still worse than the OF I think 02.56.01 # kugel: L( 02.56.04 # *:( 02.58.51 # My poor friend has a Zune G1. Has anyone attempted porting Rockbox to it? 02.59.32 # nope 03.02.36 # gevaerts: adding a mingw target to rockboxdev.sh won't help for cygwin, will it? 03.04.05 # i thought you could build the compiler on cygwin with it 03.04.46 # yea, the cross compiler, but it would be strange to build a "native" compiler with it 03.05.01 # kugel: which particular issues does cygwin have? 03.05.16 # the same as mingw I think 03.05.21 # It seems to do %z correctly at least 03.07.53 Part RPG-Master ("Ex-Chat") 03.10.12 Join mobile [0] (~evilnick|@ool-457bccf5.dyn.optonline.net) 03.10.26 # kugel: mingw-runtime seems to be at 3.17 or 3.18 in cygwin 03.10.54 # so for cygwin-native builds I don't see a problem at all, and for mingw builds there shouldn't be any either 03.16.17 # ok, that sounds good 03.16.44 Quit kugel (Remote host closed the connection) 03.16.44 Quit mobile (Remote host closed the connection) 03.17.52 Join mobile [0] (~mobile@ool-457bccf5.dyn.optonline.net) 03.27.15 Quit adnyxo (Ping timeout: 264 seconds) 03.38.25 Join ischeriad [0] (~ischeriad@p5B0A280A.dip0.t-ipconnect.de) 03.40.19 Join Boldfilter [0] (~Boldfilte@adsl-71-215-115.jax.bellsouth.net) 03.42.15 Quit ischeria1 (Ping timeout: 264 seconds) 03.51.01 *** Saving seen data "./dancer.seen" 04.10.22 Quit JdGordon (Quit: Leaving.) 04.12.59 Quit TheSeven (Ping timeout: 276 seconds) 04.16.05 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.19.04 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.19.04 Quit pixelma (Disconnected by services) 04.19.08 Quit amiconn (Disconnected by services) 04.19.11 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.19.23 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.19.30 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.21.56 Join Forsaken_Boy [0] (~chatzilla@24.138.199.192) 04.26.06 Join JdGordon [0] (~Miranda@123-243-140-31.static.tpgi.com.au) 04.26.06 Quit JdGordon (Changing host) 04.26.06 Join JdGordon [0] (~Miranda@rockbox/developer/JdGordon) 04.31.45 Quit krabador (Remote host closed the connection) 04.46.27 # the 2 cons for APE in mp3 is utter crap 04.49.46 Join dys` [0] (~andreas@krlh-5f737ea2.pool.mediaWays.net) 04.51.16 Quit GeekShadow (Quit: The cake is a lie !) 04.51.23 Quit Forsaken_Boy (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 04.51.50 Quit dys (Ping timeout: 276 seconds) 04.51.56 Join Barahir_ [0] (~jonathan@frnk-590ff8f2.pool.mediaWays.net) 04.55.33 Quit Barahir (Ping timeout: 264 seconds) 04.57.10 Quit Strife89 (Ping timeout: 260 seconds) 04.59.13 Quit Bagder (Ping timeout: 258 seconds) 04.59.46 Join Strife89 [0] (~Strife89@adsl-80-148-66.mcn.bellsouth.net) 05.05.17 Join Forsaken_Boy [0] (~chatzilla@24.138.199.192) 05.08.16 Part Boldfilter 05.13.42 Join Bagder [0] (~daniel@rockbox/developer/bagder) 05.14.58 Quit elcan (Read error: Connection reset by peer) 05.18.22 Part TFGBD 05.28.30 Join elcan [0] (user36@pr0.us) 05.40.23 Quit anewuser (Quit: for SELL 2 by the price of 1 now!) 05.51.04 *** Saving seen data "./dancer.seen" 06.16.01 Quit JdGordon (Ping timeout: 260 seconds) 06.23.33 # Ugh. usb_core seems to sometimes pass UNCACHED_ADDR() ptrs to usb_drv_send or usb_drv_recv? That looks broken to me... 06.25.28 # New commit by 03jethead71 (r26074): Make sure to include audiohw.h in settings.h or the definition of struct user_settings could get out of sync amongnst various #includes. Might be the ... 06.27.16 # ranma: not if it needs physical, uncached addresses. careful with that! :) 06.27.23 Quit Strife89 (Quit: Bed. ZZzzzzzzzz....) 06.28.44 # if this is for AMS, then that memory setup is dodgey (mapping cached right on top of physical, and making uncached address a virtual one) 06.30.40 # other targets map cached=physical, cached=virtual. personally, if I started working on AMS, I'll probably fix that blunder 06.34.59 Join JdGordon [0] (~jd@110.22.128.31) 06.34.59 Quit JdGordon (Changing host) 06.34.59 Join JdGordon [0] (~jd@rockbox/developer/JdGordon) 06.35.14 # s/cached=physical/uncached=physical 06.37.48 Quit JdGordon (Client Quit) 06.37.57 Join JdGordon [0] (~jd@rockbox/developer/JdGordon) 06.37.57 Join Xerion_ [0] (~xerion@82-170-197-160.ip.telfort.nl) 06.39.43 Quit Xerion (Read error: Operation timed out) 06.39.43 Nick Xerion_ is now known as Xerion (~xerion@82-170-197-160.ip.telfort.nl) 06.40.02 Quit JdGordon (Client Quit) 06.40.11 Join JdGordon [0] (~jd@rockbox/developer/JdGordon) 06.42.28 Quit JdGordon (Client Quit) 06.42.47 Join JdGordon [0] (~jd@rockbox/developer/JdGordon) 06.55.51 Quit JdGordon (Quit: Bye) 06.56.09 Join JdGordon_ [0] (~jd@rockbox/developer/JdGordon) 07.00.36 Quit JdGordon_ (Ping timeout: 246 seconds) 07.00.45 Join FlynDice [0] (~FlynDice@12.198.123.130) 07.05.04 # Something I've noticed recently (got some new IEMs) is that my DAPs (Nano 1/2G) produce a weird white-noise/hiss when they are first started up (audible even at very low volumes) and that this hiss will persist untill either the first keyclick, .voice/.talk, or audio file is played. Any ideas? 07.05.15 # New IEMs have made this *really* noticable. 07.06.00 # After even one single, solitary keyclick the hiss/noise stops dead... 07.06.24 # something not set up properly until audio is first played? 07.06.41 # * S_a_i_n_t shrugs 07.08.03 # gigabeat F/X once had something like that where the first audio out fixed a problem, only it wasn't noise but heavy current draw 07.08.14 Join bieber [0] (~bieber@162-78.97-97.tampabay.res.rr.com) 07.08.31 # I've always noticed a "click" or a "pop" when the DAP first starts up, but only just now noticed that it persists with a hissing sound until keyclick/voice/playback etc. 07.08.42 # then silence is actually silent. 07.17.19 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 07.18.05 Quit Horschti (Ping timeout: 246 seconds) 07.22.16 Join Buschel [0] (~ab@p54A3B2A0.dip.t-dialin.net) 07.22.52 Quit Zarggg (Quit: Zarggg) 07.29.21 Join Zarggg [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 07.30.25 Join funman [0] (~fun@rockbox/developer/funman) 07.32.13 # kugel: your small patch to button_sdl.c helps. pcsim is building again with cygwin. 07.39.25 Join mikroflops_ [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) 07.43.12 Quit mikroflops (Ping timeout: 240 seconds) 07.46.07 # S_a_i_n_t: Might it be flash access? See if doing something that involves several loads like switching themes also produces it? 07.46.58 # Llorean: Already had that idea ;) And (unfortunately) the hiss/white-noise is only present on startup. 07.47.23 # TheSeven had an explanation for the "pop" on startup, but it was a bit too tachie for myself. 07.47.30 # it persists after all activity from database and dircache stops? 07.47.32 # *techie even 07.48.17 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 07.48.19 # jhMikeS: Yep, if I start the DAp and just leave it (assuming that idle shutdown is off) it will hiss all day if I let it. 07.49.15 # Buschel: is that ipodvideo problem fixed? 07.51.06 *** Saving seen data "./dancer.seen" 07.53.08 # someone with very low quality IEMs could well miss this hiss, or if they just start up the DAP and start navigating the menu with keyclicks or .voice/.talk enabled. But (as with most things of this type) now that I *have* noticed it, I can't *not* hear it ;) 07.53.13 # apparently the as3543 rtc has an auto-wakeup feature 08.11.05 # jhMikeS: just testing for pc sim (it also crashed) as my iPod is already hidden somewhere in the void of my luggage 08.14.23 # jhMikeS: hmm, sim still hangs. 08.14.59 # jhMikeS: but it looks different. at least the menu shows up 08.15.02 Join esperegu [0] (~quassel@145.116.15.244) 08.15.27 # cheap fuzes on woot in the US today 08.18.34 # is anyone not happy with the radio art system I've setup? I.e images are in .rockbox/fmpresets/.bmp or .jpg ? 08.19.14 # if the sim hangs, then that's sort of good...I can at least play with that 08.20.27 # jhMikeS: yep. good luck! :o) 08.20.32 # :) 08.21.19 # bye 08.21.21 Quit Buschel () 08.30.51 Quit S_a_i_n_t () 08.32.14 Quit JdGordon (Ping timeout: 268 seconds) 08.35.51 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.5.171) 08.38.22 Quit mobile (Read error: Connection reset by peer) 08.44.05 # jhMikeS: charging on the fuzev1 seems to be broken in today, could you charging commits have caused that? 08.44.36 Quit esperegu (Ping timeout: 258 seconds) 08.45.56 Join esperegu [0] (~quassel@145.116.15.244) 08.46.21 # oddly the clipv2 seems fine 08.58.03 # I reverted the commits 09.00.06 Quit arbingordon (Quit: `) 09.00.44 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 09.05.29 # woa: the (public) as3527 datasheet use an as3543 (or compatible) and all the bits are detailed 09.11.42 # btw, the as3527 mentions as3517, so the as3525(v1) doesn't use it 09.14.12 Quit [CGL] (Read error: Connection reset by peer) 09.16.17 # * jhMikeS can't even compile the ipv sim 09.17.05 Quit Beta2K (Ping timeout: 260 seconds) 09.18.00 Join Beta2K [0] (~Beta2K@d24-36-126-101.home1.cgocable.net) 09.20.21 # * jhMikeS gives it one more round, clean :\ 09.22.52 # urgh, button-sdl.c 176, implicit declaration of function exit, EXIT_SUCCESS undeclared 09.34.31 Quit Galois (Ping timeout: 264 seconds) 09.39.58 Quit esperegu (Read error: Operation timed out) 09.42.06 Join hebz0rl [0] (~hebz0rl@dslb-088-067-199-071.pools.arcor-ip.net) 09.42.09 Join esperegu [0] (~quassel@145.116.15.244) 09.51.10 *** Saving seen data "./dancer.seen" 09.52.20 Join stoffel [0] (~quassel@p57B4CBEF.dip.t-dialin.net) 09.54.52 Quit esperegu (Ping timeout: 260 seconds) 09.55.05 Join esperegu [0] (~quassel@145.116.15.244) 09.57.27 Quit wincent (Ping timeout: 276 seconds) 10.04.11 Join n1s [0] (~n1s@rockbox/developer/n1s) 10.23.24 Quit n1s (Read error: Connection reset by peer) 10.23.33 Join n1s [0] (~n1s@rockbox/developer/n1s) 10.23.53 Join mitk [0] (~mitk@chello089078013146.chello.pl) 10.24.09 Part mitk 10.24.20 Join mitk [0] (~mitk@chello089078013146.chello.pl) 10.35.17 # the 'as3514' in as3525 seems to be an as3515 10.39.45 Join DataGhost [0] (~dataghost@17-18-ftth.onsnetstudenten.nl) 10.39.45 Quit DataGhost (Changing host) 10.39.45 Join DataGhost [0] (~dataghost@unaffiliated/dataghost) 10.40.49 Join ender` [0] (krneki@foo.eternallybored.org) 10.52.34 Join flydutch [0] (~flydutch@host138-162-dynamic.14-87-r.retail.telecomitalia.it) 10.53.09 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 10.57.47 Join DerPapst [0] (~Alexander@p4FE8ECC9.dip.t-dialin.net) 11.00.17 # ranma: ascodec_*_endofch_irq() is both an exported function & a static inline 11.03.40 # from -community... is anyone looking at commiting 11270?> 11.04.20 # JdGordon: I had wondered if you'd looked at that. 11.04.28 Join Lombax [0] (~FuzzyLomb@S0106000347a5e69e.vs.shawcable.net) 11.05.01 # i looked at the first version... i dont have any objections to it.... does anyone? 11.05.23 Join azazel [0] (~FuzzyLomb@S0106000347a5e69e.vs.shawcable.net) 11.05.25 # Am I right in thinking that oscilloscope, fft, other audio-relevant plugins could be done in the same way? 11.07.26 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 11.07.33 # sure... but thats not really the way to do it 11.08.03 Quit bluefoxx (Ping timeout: 240 seconds) 11.08.56 Quit Lombax (Ping timeout: 260 seconds) 11.09.47 Join merbanan [0] (~banan@c-94-255-217-84.cust.bredband2.com) 11.09.48 # Well, I hardly have any sway regarding if it gets committed or not, but I think it's a damn fine idea. 11.10.42 Quit azazel (Ping timeout: 268 seconds) 11.14.02 Join bluefoxx [0] (~FuzzyLomb@S0106000347a5e69e.vs.shawcable.net) 11.21.10 Quit Forsaken_Boy (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 11.22.06 # New commit by 03funman (r26075): as3525v1 use an as3515 audio codec/PMU, not an as3517 as previously thought ... 11.29.09 # funman: But arm/ascodec-target.h does not get included on AMS, right? In as3525/ascodec-target.h it's not an inline. 11.29.46 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 11.30.09 # I think armv6 (clean|invalidate)_dcache range is broken 11.31.15 # ranma: ah right i was reading the wrong file 11.31.35 # you have an armv6? 11.32.33 # Oh, ok, it's armv4 11.32.46 # Then armv4 (clean|invaliate)_dcache range is broken :) 11.33.06 # what's wrong with it? 11.33.47 # I think it's just not working properly. If I use clean_dcache_range(buf, buflen) it doesn't work, clean_dcache() seems to work though. 11.34.41 # does it work if you align buf on 32 bytes? 11.34.52 # align start of buffer & buffer size 11.35.26 # I'm getting the buffer from usb_core, but I tried clean_dcache_range(buf-32, buflen+64)... 11.36.09 # buf is in 0x30xxxxxx range ? 11.36.19 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 11.36.58 # i.e. not UNCACHED(something) 11.37.38 # Yep. I have to explicitly catch uncached buffers and convert the address, because I can't DMA to/from an uncached address... 11.37.57 # UNCACHED is only used in storage driver it seems 11.38.14 # I think it's broken that usb-storage passes in UNCACHED addresses. 11.38.46 # I'd rather it wouldn't do that :) 11.39.36 # yes it should go in the target drivers 11.39.41 # the core doesn't know if we use dma or not 11.43.19 # Hmm, I don't see why clean_dcache_range doesn't work. 11.43.54 # nothing accessing the data after you cleaned it ? 11.45.00 # Nope, right now I'm copying it over into my own buffer and that's only accessed in that function. 11.45.23 # Hmm, but I should check alignment... 11.47.02 # No, even if it's not aligned, the buffer before that one is not used, so it shouldn't be a problem with some other data sharing the same cacheline... 11.47.34 # And thinking of cachelines, I wonder if I can even trust usb_core to pass in cacheline aligned buffer for receive and transmit... 11.48.03 # what if you only access the uncached buffer? 11.48.33 # Then I definetly have to use a local buffer. 11.48.42 # The samsung usb driver doesn't use one though. 11.49.01 # I'm using usb-s3c6400x.c as a reference here... 11.49.48 # Which also uses clean_dcache() and invalidate_dcache() instead of the range() variants. 11.49.56 Join kugel [0] (~kugel@rockbox/developer/kugel) 11.51.13 *** Saving seen data "./dancer.seen" 11.51.19 # ranma: I think the usb buffers are cache aligned 11.51.47 # New commit by 03kugel (r26076): Fix building on cygwin. 11.53.11 # I just found a potential issue with my dma descriptors sharing cachelines with other data... 11.56.11 Quit mitk (Quit: Leaving) 12.01.42 Quit shaggy-h (Ping timeout: 240 seconds) 12.02.43 Join JdGordon1 [0] (~jonno@123-243-140-31.static.tpgi.com.au) 12.02.48 Join MethoS- [0] (~clemens@134.102.106.250) 12.14.44 Quit bieber (Ping timeout: 260 seconds) 12.15.08 Join bieber [0] (~bieber@162-78.97-97.tampabay.res.rr.com) 12.21.55 # kugel: what's the proper off_t min/max definition? 12.22.15 # don't know 12.22.57 # I thought you might with all the sim stuff...hmm 12.23.36 # yea, but off_t is something I never understood ;) 12.24.33 # New commit by 03funman (r26077): as3525: make sure we don't use a negative number of sectors ... 12.25.05 # i think it's important for handling files > 2 or 4GB on 32bits cpus 12.25.12 # just a signed offset, related to the whole size_t and ssize_t group I guess 12.26.27 # know the max would save me checks here...hmmm...google 12.26.30 # i don't see off_t in posix/limits.h 12.27.03 # jhMikeS: size_t might be smaller than off_t though 12.27.14 Join Jaykay [0] (~chatzilla@p5DC56DEC.dip.t-dialin.net) 12.27.17 # I thought the opposite 12.27.46 # size_t can't go past 4G on 32 bits cpu but you can still be at position 8GB of a very large file 12.27.47 # I'm handling files so I'm keeping it consistent. 12.28.22 # http://pastie.org/962419 <-- this is on a 64bit system 12.28.39 # it only creates off_t as 64bit and off64_t when asked to 12.30.32 # jhMikeS: how about if (sizeof(off_t) == sizeof(long)) OFF_T_MAX = LONG_MAX else {...} ? 12.31.01 # better just cast off_t to long long 12.31.11 # why? 12.31.21 # it's simpler no? 12.31.31 # but is it correct? 12.31.53 # JdGordon: I don't object to the principle :) 12.32.01 # i guess 12.32.26 # i can't find 'off_t' in n1256.pdf (ISO/IEC 9899:TC3 draft) 12.32.44 # that's because it's not iso c 12.32.58 # is it posix? 12.33.13 # posix/unix yes, defined in sys/types.h 12.35.22 Join pamaury_ [0] (~c2c7a50a@rockbox/developer/pamaury) 12.35.41 Join Llorean1 [0] (~DarkkOne@adsl-99-158-45-131.dsl.hstntx.sbcglobal.net) 12.36.40 Quit Llorean (Ping timeout: 260 seconds) 12.37.08 Quit bieber (Ping timeout: 260 seconds) 12.37.31 Quit pamaury (Ping timeout: 252 seconds) 12.37.34 Join bieber [0] (~bieber@162-78.97-97.tampabay.res.rr.com) 12.40.59 # * kugel would like to commit his pth thread work 12.40.59 Join moos [0] (moos@rockbox/staff/moos) 12.41.43 # gevaerts: ping :) 12.42.33 # hmmm...of course there's always (~(type)0 - ((type)1 << (sizeof (type)*8 - 1)) :) 12.44.14 # or just the last term - 1 12.49.45 # ranma: usb serial works? 12.56.31 # Didn't try, but since usb-storage is nowhere near working yet... 12.59.12 # i'd have left storage for the end, simplest things first ;) 12.59.44 # anyone got a radio target able to do a test? 13.00.43 # does anyone know which targets have HAVE_NOISY_IDLE_MODE enabled? 13.00.57 # Ah, damn. I see why control sends don't work without memcpy to my buffer. The core buffer is in iram and so the address is wrong, but doesn't give a bus error since it's an extram alias address 13.01.17 # JdGordon1: what test? 13.01.21 # gevaerts: uploaded the patch to FS#11234. jhMikeS, you're potentially also interested in it? 13.01.28 # a patch 13.01.43 # Is there 'virt2bus' or something like that? 13.01.55 # JdGordon1: well, what patch? 13.02.27 # 11263.. but it needs some setup... meh never mind 13.02.53 # ranma: UNCACHED_ADDR for iram I think 13.03.09 # hm, no 13.03.18 # * jhMikeS has to disagree about cooperative being advantageous, other than that I'll looksee :) 13.04.05 # ranma: but subtracting IRAM_ORIG from the start pointer should work 13.06.08 # -IRAM_ORIG+DRAM_ORIG+MEM*(1<<20) 13.06.21 Quit esperegu (Read error: Operation timed out) 13.06.56 # funman: that's the start of the alias, he needs the phys. location for dma 13.07.00 # hm no that's the reverse :o 13.07.09 # * JdGordon1 thinks there is a bug in the dependancy generation 13.07.25 # then -(what i said) ;) 13.07.33 # filetypes.c shuold be depending on english.lang but once every so often it will start compiling before the langs are done 13.08.03 # if (addr & 0x10000000) { /* uncached address */ 13.08.04 # addr -= 0x10000000; 13.08.04 # } 13.08.04 DBUG Sent KICK ranma to server 13.08.04 # if (addr >= IRAM_ORIG) { /* iram address */ 13.08.04 # addr -= IRAM_ORIG; 13.08.04 Kick (#rockbox ranma :No flooding!) by logbot!~rockbox@giant.haxx.se 13.08.53 Join ranma [0] (ranma@mx.tdiedrich.de) 13.09.17 # someone should hug logbot a bit, it's quite sensitive these days 13.09.41 # seems to be 5 lines in no time 13.10.28 # jhMikeS: not advantageous generally but in our situation 13.11.26 # as3525v2 do NOT use as3517 (they have separate line1/line2 and mic1/mic2 registers), so assumption of as3543 still holds 13.12.27 Join esperegu [0] (~quassel@145.116.15.244) 13.13.29 # funman: I just looked at the audio isr of the fuzev2 firmware and indeed it does some initialization but I don't understand how it decides ot init usb or not... 13.13.40 Nick pamaury_ is now known as pamaury (~c2c7a50a@rockbox/developer/pamaury) 13.13.44 # New commit by 03jdgordon (r26078): FS#11263 - Radio Art support! %C and %Cl tags work in the radio screen and Base Skin when the radio is running. ... 13.14.13 # pamaury: isn't it just unconditional? 13.14.20 # nope 13.14.46 # it reads a value in memory which is a pointer and then reads the content and compare to 0 13.14.51 # AlexP: hey, can you fix the manual for that ci? do I need to add a FS task for it? 13.15.05 # I can, and yes please as I can't right now :) 13.15.15 Join Schmogel [0] (~Miranda@p3EE21A0F.dip0.t-ipconnect.de) 13.15.17 # and I don't want to forget 13.16.08 # * JdGordon1 spots the sbs being called the Custom Status Bar in the manual and decides to go against all his morals and fix it 13.16.19 # hehe :~) 13.16.21 # pamaury: it writes 1 just after so I guess it's: static bool usb_detected = false; if(usb_detected) return; usb_detected=1; 13.17.02 # btw usb detection works the same way than on as3525, but i still don't get why we get thousands of audio interrupts 13.17.02 Join petur [0] (~petur@rockbox/developer/petur) 13.17.13 # they tend to just stop at random also 13.17.16 Quit esperegu (Ping timeout: 260 seconds) 13.17.24 # the 2 additional irq registers just read as 0 13.17.30 # AlexP: do you know which file chap 12.c would be in? 13.17.45 # But i audio isr only used for usb detection ? Doesn't that defeat the purpose of 'audio' interrupt ? 13.17.47 # *is 13.17.48 # what is the chapter? 13.17.49 # ah found it 13.20.18 # pamaury: 'audio' is named AFE in linux code 13.20.19 # yeah, no idea how to fix the manul for radio art... 13.20.37 # it's used for interrupts of audio/pmu .. i guess the name is bad yes 13.20.39 # AlexP: two manual questions: (1) I have a patch to update and make the start screen description more complete, would you have a look? (2) Do you think it is possible to make the \Actions use "\ActionBlah (remote: \ActionRCBlah)" except in the button table environment? 13.20.44 # New commit by 03jdgordon (r26079): .sbs is base skin, not custom statusbar 13.21.11 # I'm looking for a more general solution to this so I don't have to look for every text 13.21.26 # ranma: http://pastie.org/962443 fixes http://forums.rockbox.org/index.php?topic=24817.msg166850 -> is it ok? 13.22.03 # pixelma: 1) Sure 2) sounds like the best plan - you mean is there a way to automagically do it? 13.22.06 # AlexP: I would think that's a cleaner solution and avoids things being forgotten later 13.22.52 # AlexP: yes, I could *imagine* there is a way to set this up in preamble.tex etc. 13.22.55 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 13.23.13 # I guess there are two options - a new macro, or to redefine the current one so it does one thing in button tables and one thing everywhere else 13.24.16 # I don't immediately know how, but it must be possible :) 13.24.18 # I'd prefer the latter I think, the former means going through all texts and change to the new macro 13.24.33 # that's a shame the fuzev2 write a undocument bit in PCGCCTL... 13.24.44 # pixelma: Yes, it would be good I think 13.24.58 # and later have to rethink if you need \ActionAllBlah or not 13.25.37 # AlexP: about (1) - pastebin good enough or the tracker? 13.26.54 # pastebin I'd have thought if we are looking now 13.28.08 # New commit by 03jdgordon (r26080): yellow go bye bye 13.28.55 # AlexP: http://pastebin.com/PCdNUPPF there are some comments in it for myself 13.30.18 # rasher: ping 13.30.26 # JdGordon1: yes? 13.30.36 # pixelma: "automatically start to record" --> "automatically start recording" 13.31.12 # I'm a bit puzzled by the linux code for the as353x, it's incosnistent in the use of bitfields... something lsb to msb and something the reverse :( Furthermore, there are plenty of naming inconsistencies 13.31.16 # rasher: have you got a sec to look at a patch for the theme site to run the fms's through checkwps? 13.31.30 # trying to find it on the tracker... 13.31.43 # pamaury: perhaps there will be similarities with the as352x code? 13.31.56 # http://www.rockbox.org/tracker/task/11262 13.32.08 # Only other thing - I can't remember what the convention is (if we have one) w.r.t. using capital letters after the item: e.g. [Item.] description - shoukd description be Description? The full stop suggests yes 13.32.11 # @ pixelma 13.33.19 # not sure there is a convention, I just kept it the same style as before 13.33.24 # funman: not really :( 13.33.30 # JdGordon1: and checkwps parses .fms files? 13.33.41 # AlexP: but maybe there should be one 13.33.54 # JdGordon1: I don't see anyway that could possibly break anything 13.34.04 # it should, I dont tihnk it cares about file extensions 13.34.15 # Ah 13.34.20 # pixelma: I think it'll look odd to have a full stop after the item name, then start with a small letter 13.34.34 # true 13.34.36 # arg, checkwps is braindead checking for remotes 13.35.26 # JdGordon1: it's okay, the theme site doesn't check them (I think) :) 13.35.46 # if that patch is ok ill commit it 13.36.13 # It should be, go ahead and I'll import it 13.37.23 # New commit by 03jdgordon (r26081): make the themesite check .fms files through checkwps 13.37.45 # JdGordon1: change is live now 13.37.55 # cheers 13.37.57 # New commit by 03jdgordon (r26082): make checkwps accept .rfms files as remote skins 13.38.44 # * JdGordon1 wishes there was a way to know which themes use what skins, and tag stats 13.39.11 # JdGordon: I've often wished the same... 13.39.22 # also having it not download every theme for a target... grab them in lots of 10 or something 13.40.38 # rasher: the theme site also checks the cfgs, right? Could it reject greyscale themes for displays that exist as greyscale and colour - made for colour targets and setting global foreground colours? They are not rejected currently if the WPS does not define different colours then they are technically correct but since greyscale doesn't know foreground and background colours you can end up with an unreadable display 13.40.57 # happens when the theme uses white text on a dark backdrop 13.41.28 # the backdrop will be displayed but the text is still black on the greyscale display 13.41.50 # kugel: Was there any recent discussion about the decision to move the sim SDL code into target tree? (I haven't been paying close attention the last few days) 13.42.14 # linuxstb: yes, on the ML 13.42.44 # I tried to ping because I remembered you wanted to take part but you weren't available 13.43.21 # pixelma: The problem I see here is that \ActionXxx is defined in the keymap file, not preamble.tex, and I don't know which is run through first. The second problem is that what is then wanted is after that definition to redefine \ActionXxx = \ActionXxx (remote: \ActionRcXxx) but only for specific places - I think we will need a different macro 13.43.45 # Unless latex has a sort of built in search and replace function 13.48.04 # I thought of the spot where the definition of how to deal with \Action, is it not in preamble.tex? 13.48.16 # * pixelma should take a look herself 13.48.45 # New commit by 03funman (r26083): as3525: don't use incomplete USB code when charging 13.49.24 # pixelma: Can't see anything - each \ActionXxx is a macro defined in the keymap file 13.51.16 *** Saving seen data "./dancer.seen" 13.52.56 # hmm... I thought it would be similar to making button tables 2 or 3 columns depending on HAVEREMOTEKEYMAP or not 13.53.37 # That just changes the table though, you still need to type in both \Action \ActionRc 13.54.12 # kugel: Sorry I missed that thread. I'm still not convinced it's a good idea - simulating Rockbox running on a real target is not the same as RaaA, so my feeling is that there won't end up being much in common (but I may of course be wrong - you've looked at this a lot more than me). So I think I would have preferred the sim SDL code was copied to create a clean SDL target - once the sim code is stripped out, I don't think there's much l 13.54.12 # eft. 13.54.23 # AlexP: yeah, I meant the principle "deal with things differently" 13.54.45 # I think each action needs a new macro - at least that way people don't have to litter the source with \opt{remote}, it is done automatically 13.55.11 Quit FlynDice (Remote host closed the connection) 13.55.53 # linuxstb: That's unfortunate. I am convinced 13.57.03 # kugel: Convinced of what? 13.57.04 # for now I only moved the "sdl device driver", the common sim-only related code is still in uisimulator/common 13.57.49 # New commit by 03nls (r26084): Since we no longer use -fno-strict-aliasing in CFLAGS we don't need to strip it out for the codecs. 13.57.50 # convinced that it's a good idea 13.58.23 Quit funman (Quit: free(random());) 13.58.26 Quit TheSeven (Ping timeout: 276 seconds) 14.00.06 # even more so after doing the work 14.03.18 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 14.03.58 # pixelma: http://pastebin.com/PH3miXGw works fine at the end of preamble.tex, but the downside is that it needs one for each action, and then people need to use different macros in the text and in the button tables. Also, if remotekeymap is defined but the specific key isn't, it'll fail to build 14.04.40 # Who is working on the as2525v2 and can answer my question ? There a function called during usb initialisation which set a bit in a register at 0xC8100020 but I can't find what it is, any idea ? It's just after the CCU ones... 14.05.49 # is there any reason why not overwriting CFLAGS in root.make is a bad idea? we currently overwrite it but if we didn't, testing with different compiler flags is much easier. 14.08.12 # does a .lang file need a newline at the end? 14.08.49 Join fml [0] (~d9e3d4bf@giant.haxx.se) 14.08.55 Quit JdGordon1 (Ping timeout: 246 seconds) 14.09.00 # n1s: overwrite what? 14.09.24 # can't you just do make CFLAGS="whatever" ? 14.10.23 # pixelma: one more thought about displaying FM frequencies: what would you do if the excat value reported by the chip is 85,123,456? Would you display all the digits? I think no. S oI think we should assume that the chip gives us numbers accorsing to the step spec. 14.10.53 # ...and hence the change is OK 14.11.28 Quit fml (Client Quit) 14.12.44 # Torne: no, because tools/root.make overwrites it 14.12.51 # eh? 14.13.16 # n1s: how? 14.13.21 # making root.make just append stuff works of course but i wonder if it's likely that CFLAGS will contain junk 14.13.31 # variables on the make command line take precedence over variables in the makefile 14.13.34 # kugel: Even after seeing your work, I'm not convinced - I still think the code will (or at least, should) diverge over time. But I'll agree to disagree, especially as I seem to be on my own here ;) 14.13.42 # the CFLAGS= line in root.make will be ignored if you specify it 14.14.16 # n1s: i think you are confusing CFLAGS="foo" make, with make CFLAGS="foo" 14.14.21 # these behave very differently 14.14.46 # variable setting in a makefile overwrites the default values inherited from the environment, but variable setting in the make arguments overrides the makefile 14.15.21 # (unless the variable is set with the "override" keyword in the makefile) 14.15.23 # Torne: aha 14.15.51 # but i want to add stuff to cflags, not override it... 14.16.24 # well, that's trickier, yes 14.16.49 # but trusting the value inherited from the environment at all seems like a very bad idea 14.17.01 # maybe i should just add a new var that gets included in CFLAGS 14.17.02 # if you want a convenient way to append more flags, stuff $(EXTRA_CFLAGS) on the end or something 14.17.14 # exactly 14.22.13 # should i then set EXTRA_CFLAGS inside root.make to an empty string to not accidentally get junk? (I am not very much at home in makefiles :/) 14.23.07 # yes 14.24.51 # AlexP: I would have put the \opt{HAVEREMOTEKEYMAP} inside the first newcommand and around the remote: part - or is this not possible? 14.25.10 # probably is, yes 14.25.17 # kugel: pong 14.25.27 # I'm just looking at checking whether a macro is defined or not 14.25.42 # gevaerts: posted the pth patch to FS#11234 14.25.55 # As not all targets have all actions (for both main and remote) 14.25.56 # kugel: yes, looking now 14.26.09 # And if you try to use one that doesn't exist it errors out 14.26.47 # gevaerts: I pushed to the git repo as well now, but delete the branch before you pull because I messed it up :) 14.27.00 # AlexP: then I'd think the keymap files need fixing. The same happens currently with all other \ActionBlah definitions IIRC 14.27.08 # * n1s thinks he's got a highscore :) 14.27.45 # pixelma: For the main keymaps, yes - but what about remotes? They don't always let you do everything through lack of buttons 14.27.48 # congrats 14.27.53 Join anewuser [0] (anewuser@unaffiliated/anewuser) 14.28.33 # kugel: nothing a proper reset --hard won't fix :) 14.28.53 # n1s: according to http://www.rockbox.org/wiki/BuildHighScores yes, \o/ 14.28.58 # AlexP: hrrm 14.29.18 # I can check if a macro is defined fine, but it just makes each definition quite big 14.30.04 # one mo, I'll give you an example 14.30.40 # this reds are really impressive 14.30.53 Join einhirn [0] (~Miranda@p54851442.dip0.t-ipconnect.de) 14.31.11 # it's an easy fix but svn is weird 14.31.23 # n1s: well done! 14.31.37 # i accidentally deleted the file and svn up doesn't get it back... 14.31.39 # I don't like the fact that this solution needs one for each \Action anyways. I had hoped that it is possible to make latex just take the string after the \Action (e.g. StdNext) and put the pieces together 14.31.45 # gevaerts: thank you, sir! 14.32.15 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 14.33.48 # kugel: looks ok to me 14.33.56 # AlexP: not sure if that is possible and I see your point about the processing order now 14.34.45 # New commit by 03nls (r26085): fix red 14.36.18 # number of affected targets might be interesting in the high score page too as the more ports exist, the sum can be easily higher 14.37.41 # make an average 14.38.00 # * pamaury thinks of the best way to get a high score ... :) 14.38.08 # or that 14.39.10 # n1s: add your incredible high score to http://www.rockbox.org/wiki/BuildHighScores please :9 14.39.18 # already donew! 14.39.22 # The current way is fine. It just means that you can't claim sole credit for a high score, you have to acknowledge the work of porters :) 14.39.26 # hooray for descriptive commit messages too :| 14.40.07 # * n1s thanks all the porters who's invaluable work he built upon 14.40.26 # not there yet, there's still a yellow :) 14.40.37 # kugel: that's not mine 14.41.08 # or shouldn't be, it's about implicit declaration of memset so someone forgot to include the header or something 14.41.13 # pixelma: http://pastebin.com/0cePBxep works 14.42.11 # n1s: I can fix it 14.42.16 # pixelma: I think the problem is that different remote actions might be available on different targets 14.42.25 # pixelma: So you sort of have to test for them anyway 14.43.11 # New commit by 03kugel (r26086): memset is in string.h, not memory.h. 14.45.24 Quit Jaykay (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 14.45.34 # n1s: but it seems to be exposed by your commit, strange 14.45.43 # pixelma: It might be possible to build something with this to do what you want, I'm not sure :) 14.46.49 Nick Llorean1 is now known as Llorean (~DarkkOne@adsl-99-158-45-131.dsl.hstntx.sbcglobal.net) 14.46.50 # speaking of button actions, pixelma: did you get around testing the pla patch on other targets? 14.46.57 Quit Llorean (Changing host) 14.46.57 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 14.47.26 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 14.49.24 # I tested on my M5 and if I remember correctly I had a problem in metronome with short Select being "tap" and long being "play", I'd also prefer that in this case "play" would be on the Play button (might apply to other keymaps too) 14.49.38 # the other things were fine 14.55.11 # kugel: ^ 14.55.43 # don't you need to be able to press tap quickly? 14.56.35 # AlexP: I'll think it through but it doesn't look as straight-forward and elegant as I hoped but thanks for looking :) 14.57.08 # pixelma: The only advantage of doing it this way rather than manually is that it can't get forgotten 14.57.19 # kugel: tapping is fine but play is not and it would be easier if it was on a different button 14.57.33 # "play" that is 14.57.50 # different button is not something you'll do with pla :) 14.58.23 # yeah, which is why I think metronome is not a PLA plugin 14.58.33 # or shouldn't be 14.58.53 # I'm satisfied if it's better than before with my patch 15.02.06 # it could be that in the metronome case SVN is "better" on targets which have an extra Play button but I would need to check. But of course metronome is broken completely on other targets in SVN 15.02.38 # pixelma: I think the major barrier here is that when running through the text macros are just expanded - they can only be expanded to the thing they are defined as. You can define them differently depending on other options, but once defined they are static (unless you redefine them). 15.02.48 # ah 15.03.21 # Its extremely unlikely anyone here cares about pong, but, is there any likelyhood of FS#5855 ever seeing SVN? I think pong is awesome, but I only have iPod targets and its far too hard (plus risks bending the clickwheel) to play 2 player on it, and without FS#5855 1 player is impossible (or, just *very* boring...) 15.03.54 # pixelma: what was the plugin for I you a pastebin patch when asking you for testing the last time? 15.03.57 # I've had it in my builds for ages, pong AI ftw! 15.04.56 # s/for I/for which I gave/ 15.06.24 # kugel: if I understand you correctly then it was for metronome too and the tap/play thing (about the release action or so). But I think that it was in my M5 test build too, though I start to doubt now 15.06.25 Quit einhirn (Read error: Connection reset by peer) 15.07.53 Join JdGordon1 [0] (~jonno@123-243-140-31.static.tpgi.com.au) 15.07.55 # pixelma: no, iirc the problem was that trying to play also generates a tap 15.08.54 # no? 15.09.01 # the action system is extensible on a per plugin basis so certain targets could behave differently 15.10.27 Join funman [0] (~fun@rockbox/developer/funman) 15.10.51 Join einhirn [0] (~Miranda@p54851442.dip0.t-ipconnect.de) 15.11.09 # new patch up at fs#10387 15.13.30 Quit einhirn (Read error: Connection reset by peer) 15.13.32 # ok, I'll rerun tests with this later today 15.13.56 # gevaerts: any idea why we are using signed for number of sectors to transfer? (in fat & storage drivers) 15.14.11 # pixelma: I changed nothing so that shouldn't be really needed, but I still welcome it anyway of course 15.14.50 # funman: no. I think that was there before I touched things 15.15.34 Join einhirn [0] (~Miranda@p54851442.dip0.t-ipconnect.de) 15.15.55 # kugel: could you update the wiki a bit with what you plan to do next? 15.16.14 # gevaerts: ok, I'll do it this evening 15.16.22 # or earlier 15.16.32 # ok 15.17.24 # fat driver use longs :o 15.17.44 # funman: I saw in your work on fuzev2 that you commented a bit a function called at usb initialisation which read/writes a register at 0xC8100020, any idea of the purpose of this register ? (it seems ccu related) 15.18.38 Quit n1s (Ping timeout: 258 seconds) 15.18.55 Quit stoffel (Ping timeout: 246 seconds) 15.19.58 # nope 15.20.27 Quit einhirn (Ping timeout: 265 seconds) 15.25.48 # funman: the usb init code seems to wait a bit between each register write, is that common to the rest of the code or not ? 15.26.24 # sometimes there are useless waits 15.28.33 Quit togetic (Read error: Operation timed out) 15.29.12 Join n1s [0] (~n1s@rockbox/developer/n1s) 15.31.09 # e200v1/c200v1 can detect the charger both by as3514 and by a GPIO ? 15.31.36 # power_input_status() uses the GPIO but powermgmt-ascodec.c check charger presence with as3514 bits 15.32.19 # same for philips sa9200 15.32.46 # New commit by 03jdgordon (r26087): fix a minor fms presetlist viewer bug with displaying prev when you are on the first playlist 15.34.59 Join robin0800 [0] (~quassel@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 15.35.05 Join togetic [0] (~togetic@unaffiliated/ibuffy) 15.35.50 # any suggestions on how and where to do a "what system is controlling audio now?" (playback, radio, recording, plugins)? 15.35.53 # misc.c? 15.36.36 # pointer punning isn't an issue now, right? locally I get no complaints. 15.43.52 # ranma: r25299/powermgmt-ascodec.c: why replacing an ascodec_read() by disable_endofch_irq()? 15.44.04 # it effectively remains disabled instead of just clearing the interrupt 15.48.32 Join stoffel [0] (~quassel@p57B4CBEF.dip.t-dialin.net) 15.51.17 *** Saving seen data "./dancer.seen" 15.54.49 # jhMikeS: I hope that was related to my pth patch? :) 15.55.27 Join mobile [0] (~mobile@ool-457bccf5.dyn.optonline.net) 15.55.47 Quit mobile (Client Quit) 15.56.04 Join mobile [0] (~mobile@ool-457bccf5.dyn.optonline.net) 15.56.42 Quit mt (Ping timeout: 240 seconds) 15.56.56 Part mobile 15.57.17 Join mobile [0] (~mobile@ool-457bccf5.dyn.optonline.net) 15.57.46 Quit mobile (Remote host closed the connection) 15.58.07 Join mobile [0] (~mobile@ool-457bccf5.dyn.optonline.net) 15.58.53 Quit mobile (Client Quit) 15.59.09 Join evilnick|ipad [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 16.01.42 Join yawny [0] (user36@pr0.us) 16.03.31 Quit elcan (Ping timeout: 260 seconds) 16.04.21 Join mt_ [0] (~mtee@41.233.140.212) 16.04.37 Nick mt_ is now known as mt (~mtee@41.233.140.212) 16.05.37 # kugel: actually mine. it's preferrable to pun like: uint8_t x; fn(void **pp); fn((void **)&x); 16.06.16 # should be: uint8_t *x; 16.06.40 # I needed to hide it before in mpegplayer 16.06.50 # jhMikeS: there is a switch for more aliasing warnings that still warns about a few cases 16.07.15 # i have tried googling for the aliasing rules with regard to void pointers but have not found an answer... 16.08.08 # I"m not getting any complaints casting to void **. I think I did before. 16.10.24 # I think you can do whatever you want with char pointers 16.10.37 # including cast back and forth to any other pointers 16.11.33 # linuxstb: has the idea of making the sim buttons have the same combo limitations as real targets actually ever come up? 16.13.23 # jhMikeS: http://svn.rockbox.org/viewvc.cgi/trunk/firmware/target/arm/powermgmt-ascodec.c?revision=19748&view=markup /* Clear out interrupts (important!) */ 16.13.31 # do you remember the story behind this comment ? 16.13.56 # JdGordon1: Yes, many times. 16.14.32 # I wonder why its never been done? should be relativly simple and useful 16.14.34 # Normally whenever someone commits code with button mappings that don't work on a real device... 16.14.59 # JdGordon1: with the sim drivers not in the target tree it wasn't really straightforward ;) 16.15.11 # since e200v1/c200v1 do not use interrupts it sounds weird 16.16.50 # as i read it you can only check for end of charging once : if the bit is set, the next time you try to read it will be unset 16.19.09 # kugel: IIUC you may cast and pointer to a char and dereference it but you may not cast a char to any other type and dereference it 16.19.18 # s/and/any/ 16.19.52 # n1s: IIRC the aliasing rules don't apply to (unsigned) char*, which may or may not disagree with what you just said :) 16.20.35 # kugel: IIUC they do, you may cast stuff TO char* but not from 16.20.52 # funman: probably, and it's probably important too :) 16.21.23 # i think it's harmful 16.21.25 # the problem with the whole strict aliasing is that there seems to be noone that understands it fully 16.21.28 # funman: if you don't, it won't see end of charge 16.21.47 # why that? 16.22.22 # reading it clears it and I think it's edge triggered, but if you need any of those other ints elsewhere, that read will clear them 16.22.40 # * JdGordon1 must be really naive re sim Vs RaaA... the only big difference I tihnk of is how threads are done 16.22.59 # or at least sim Vs SDL RaaA 16.23.04 # jhMikeS: hm but if you clear it, then you won't see the end of charge ? 16.23.08 # funman: ask the designers, but it won't get the signal properly and the charger won't stop 16.23.19 Quit stoffel (Ping timeout: 246 seconds) 16.23.55 # funman: actually, I think you'll see a pending end of charge at the start, a false one (it's coming back to me) 16.24.54 # i moved enabling of interrupt after the HZ/10 delay 16.25.03 # does that remove the false one? 16.25.10 # I don't think it did 16.25.42 # I went through all sorts of different checks myself, I know that much 16.26.40 # was it consistent or random? 16.28.50 # seems to work on as3525(v1) but the code use interrupts 16.28.59 # consistent. I reckoned the low current (zero current) managed to trigger it 16.29.12 # low current? 16.29.26 # from it being off 16.30.10 # if you get end of charge that early, the batt would already be too high to trigger charging anyway 16.30.31 # that is, once the regulator is enabled 16.30.39 # oh ok 16.30.43 # funman: The thing is that the interrupt enables are write-only, you can't read the 'enabled or not' back. 16.31.02 # ranma: well i got it but reading the register will clear the interrupts 16.31.07 # On read you get wether or not an interrupt is pending for that source and the interrupt request is also acked/cleared. 16.31.40 # Yeah, but only the one will be acked. You don't have to write enable again, it's still set. 16.31.43 # some files (including powermgmt-ascodec.c) read IRQ_ENRD0 directly so that doesn't go well with interrupts 16.31.44 # JdGordon1: I *hope* the ui will be adapted to work nicely with the hos OS, i would want d&d etc if i used it on a desktop system 16.31.59 # ranma: what were you answering to? 16.32.23 # funman: then it should be signaled through a dispatch instead, not read directly except by one reader 16.32.24 # linuxstb: would it help if the target-tree move was described as "Provide a cleaner base to start splitting simulator and RaaA" instead of "Prepare for RaaA"? 16.32.25 # 16:23 < funman> jhMikeS: hm but if you clear it, then you won't see the end of charge ? 16.32.34 Join CGL [0] (~CGL@190.207.156.230) 16.32.46 # jhMikeS: yes that's what i do 16.32.47 # n1s: well, at that point it starts sounding more like you want a new frontend to the playback engine more than RaaA 16.32.58 # I just think that merging common code again later would be a nightmare 16.33.05 # I dont know what d&d is? 16.33.09 # funman: I suppose this file needs to just have a callback set instead that sets a var 16.33.13 # ranma: if you ack it just after initializing the interrupt, then next times you read it it will be already acked? 16.33.42 # JdGordon: yes, that is probably what i want d&d == drag and drop 16.33.45 # mt: he posted to the -dev ml 16.33.50 # Sure. I just misunderstood your sentence to mean you thought, you'd not get an end of charging irq then anymore 16.34.00 # http://pastie.org/962556 <- this is what i have so far 16.34.13 # well that's what i mean 16.34.14 # I don't see any reason why RaaA needs to look or behave anything like rockbox on a target 16.34.50 # kugel: I didn't receive the message, and saw Dave Hooper copying it to the -dev ml ? 16.34.59 # * kugel doesn't understand why linuxstb thinks that "sdl in the target tree" == "sim and app are the same" 16.35.00 # Well, if internally to the codec a new 'end of charging' event is triggerted, it will set the interrupt status again to 1 and because the 'enable' is still 1 it will trigger the interrupt. 16.35.32 # (time go this way ->) enable interrupt , sleep, interrupt is triggered, sleep ends, read blindly interrupt register and acknowledge the interrupt, read enrd0 -> bit is 0 ? 16.35.37 # mt: his initial message is posted to the -dev ml here 16.35.49 # ok, i suppose it just happens once 16.35.52 # Unless you also write a 0 back to the enable bit, then of course the interrupt source is masked. 16.36.50 # funman: Ok, yeah. In that timeline you won't figure out the source for that one interrupt. 16.37.28 # jhMikeS: i'll try with discharged fuze v1 & v2 to see if that happens 16.37.29 # kugel: Because it's "sdl in the target tree", and not "sim in the target tree". I simply think that RaaA should be developed without being distracted (or influenced) by the sim. Improving the sim is an independent task. 16.37.32 # kugel: hmm, you're right. I wonder why I didn't receive it. 16.38.00 # mt: looked at your spam folder? 16.38.28 # funman: Anyway, if somewhere else is blindly reading IRQ_ENRDx because it's doing a RMW cycle to set a bit, then you'd should probably add a wrapper like ascodec_(enable|disable)_endofch_irq() 16.38.36 # any objections to splitting apps/recorder/radio.c into lots of seperate files in apps/radio/ ? 16.38.54 # kugel: Yep, it's there .. and even cc'd to me 16.39.14 # linuxstb: I think kugel's current work isn't really RaaA yet, more like "getting the code in a good shape to make it easy to work on OS-based rockbox-derived things" 16.39.24 # ranma: see the patch i just posted ;) 16.39.40 # And that includes the sim, RaaA, and possibly even checkwps and the database 16.39.43 # gevaerts: correct it's the groundwork thing we talked about 16.40.07 # that's what I did, i just saw this strange thing in powermgmt-ascodec.c 16.40.24 # and fwiw it could help me understand what happens on as3525v2 when i try to use interrupts 16.40.26 # Ah, I see 16.41.04 # New commit by 03jethead71 (r26088): MPEGPlayer: Add a second layer of caching to help speed up byte-wise scanning and seeking a bit. 16.41.57 Nick CGL is now known as [CGL] (~CGL@190.207.156.230) 16.41.59 # BTW, you could just use ascodec_enrd0_shadow instead of adding two new bools 16.42.03 # do you remember why you skipped those bits from the interrupt handler and read them directl? 16.42.23 # gevaerts: kugel: there is a legitimate concern that eventually low level stuff (thread? sound?) will make assumptions for SDL, and that because the sim uses SDL the sim will get those assumptions which arnt nessecarily correct for the sim only 16.42.31 # true 16.42.32 # funman: I know it happened on as3514 on e200v1. if it's different, I wouldn't change it there. 16.42.56 # JdGordon1: sorry, I don't understand what you're saying 16.43.06 # I think I wanted to go over the pwrmgmt code and see if theres other stuff that could use the interrupts, but I didn't get around to do it/forgot ^^; 16.43.08 # JdGordon1: that's right, but I already ported a different thread and sound library so I know where the assumptions are and how to clear them up 16.43.09 Join detaos [0] (~quassel@ip72-218-104-242.hr.hr.cox.net) 16.43.19 # jhMikeS: well this is supposedly the same, i'll make some tests and i'll ask you to test a patch before committing anything. if it's specific to e200v1 we can put an ifdef 16.43.40 # HAVE_SDL_SOUND is a good example.. that might one day be completly replaced later which makes perfect sense for RaaA, but would be a terrible mistake for sim 16.44.09 Quit detaos (Remote host closed the connection) 16.44.11 # kugel: and in 6 months time? a year? 2 years... just because *you* know them now doesnt mean you will be the one maiting it later 16.44.19 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 16.44.33 # now i only tested if end of charge would trigger starting from 97 or 98% charged 16.44.37 Join detaos [0] (~quassel@ip72-218-104-242.hr.hr.cox.net) 16.45.24 # JdGordon: in 6 month? That's out of question, I'm expected to be done with that by august 16.45.26 # jhMikeS: is that really bad if end of charge doesn't happen? (because it doesn't in current svn) 16.45.53 # kugel: you are totally missing the point 16.45.54 # funman: yes, then the charger runs and that's harmful to the battery 16.45.57 Join stoffel [0] (~quassel@p57B4CBEF.dip.t-dialin.net) 16.46.10 # JdGordon1: I think kugel answered that in his email. "There's no different way of doing it differently *within* SDL happening" 16.46.40 # well, runs continuously anyway. it *must* stop 16.46.53 # ranma: i think r25299 disabled the irq for endofch 16.46.58 # JdGordon1: Give us a real example of what you'd change in an SDL driver where your point would be valid :) 16.47.56 # I'm not saying there is a better way, or that the concern will actually happen.. I'm just trying to understand linuxstb's concern(?) 16.48.14 Quit bluebroth3r (Ping timeout: 276 seconds) 16.48.30 # but I guarentee that someone is going to replace #ifdef SIMULATOR with *_SDL_* something which will cause sim problems 16.48.37 Join arbingordon [0] (~w@unaffiliated/arbingordon) 16.48.41 # can you just turn off that bloody pun warning on colfire? wtf 16.49.21 # of course, there should be no #ifdef SIMULATOR's in apps/ anyway 16.49.35 # exactly. As long as they're there, we have problems anyway 16.50.43 # there is still some target code in apps/ 16.51.10 # funman: But AMS doesn't use an irq for that and PP should be unaffected by the r25299 IIRC 16.51.31 # * JdGordon1 thinks RaaA is silly and someone should work on stripping the playback engine out completly instead! 16.51.35 # JdGordon1: I'll be investigating all the #ifdef SIMULATOR in a later step, hopefully resolving any (even possible) related problems 16.51.36 # kugel: what option does turn off that warning? 16.51.39 # ranma: powermgmt-ascodec.s is shared with the PP 16.52.11 # Ah, wait, because of the 'clear out', hmm, missed that. 16.52.21 # * jhMikeS should just leave it there since it's a bloody stoopid warning 16.52.26 # i think you mistook a read() for a write() 16.52.36 # jhMikeS: well, -fno-strict-aliasing is the only that comes into my mind, but that was removed just a few days ago 16.52.52 # jhMikeS: -fno-strict-aliasing disables all the aliasing optimizations and warnings 16.53.02 # jhMikeS: it could be that the old cf gcc isn't smart enough 16.53.20 # yeah, the old gcc gives some false positives apparently 16.53.22 # Probably because of the comment, I don't think of ACKing an irq when it says 'clear out' :) 16.53.41 # I remember someone saying the abilities of gcc to detect aliasing-related quirks improved slowly over time 16.54.10 # That would need a ascodec_clear_endofch_irq(); instead. 16.54.20 # perhaps disabling and reenabling it after would do the trick? 16.54.38 # n1s: optimizations too? it can't just be shut up without consequences to code? 16.54.39 # Which would do the read on PP and on AMS it's a noop 16.55.17 # meh, back to ridiculousness then :\ 16.55.21 # jhMikeS: yes there's a -Wno-strict-aliasing 16.55.22 # Disabling and reenabling _might_ work, but I wouldn't be on that... 16.55.45 # bah, i'll test more tomorrow 16.56.02 # also, it will be easier to test with usb serial 16.56.05 # * funman looks at ranma 16.56.08 # ...but it then *might* break on some code that it assumes follows aliasing rules AFAIU 16.56.08 # ;)) 16.56.36 # funman: I've been chasing heisenbugs today mostly. 16.56.44 # want some help? 16.56.52 # The latest version of the code has regressed somewhat. 16.57.24 # n1s: you seems to imply it had other consequeces which were not desireable (optimizations) 16.57.55 # and W not f 16.57.57 # *ah 16.58.16 # This one works almost, it reliably gets until the point where it tries to read the partition table. http://pastie.org/962580 16.58.24 # Good chance that usbserial might work with that one. 16.58.40 # gevaerts: I guess my concern is that I see see RaaA and the sim as fundamentally independent, so I don't see sharing code between them as any kind of priority - I see sharing code as something that will get in the way. By saying that there is only one way to do things in SDL isn't the point - the point is the details of the abstraction you provide by your SDL drivers may not be the same for the two purposes. 16.58.53 # And this is my current working version: http://pastie.org/962581 16.58.59 # jhMikeS: i dont' think disabling the optimizations are tahat bad, i've never seen them give any significant speedup 16.59.27 # linuxstb: but the driver API is defined elsewhere anyway 16.59.34 Quit robin0800 (Remote host closed the connection) 16.59.44 # linuxstb: they are different, but not the sdl parts of it 17.00.34 # the sdl stuff should've been in the target tree from the beginning IMO, and that it's there makes RaaA easier for me 17.01.27 # copying and leaving the sim aside has no advantage except an upcoming nightmare at either maintaining or merging both later 17.02.03 # the nightmare is a disadvantage of course 17.04.24 # But that should be weighed up against the flexibility of being free from the sim when developing RaaA. But if, as you claim, there will be a loit of code in common between the sim and RaaA, I can't see why that would be a nightmare. It would only be a nightmare if the code diverged. 17.04.48 # and you think I didn't weight it up? 17.05.25 # * jhMikeS goes back to brute force concealment (easiest) 17.06.00 # New commit by 03alle (r26089): Rearrange statements for a small binsize reduction; delete unneeded braces 17.07.11 Quit detaos (Remote host closed the connection) 17.07.47 # that commit isnt going to work 17.08.09 Join Boldfilter [0] (~Boldfilte@adsl-71-215-115.jax.bellsouth.net) 17.08.18 # what does % do with negative numbers? 17.08.34 # -1%5 ? 17.08.37 # -1 17.09.09 # sqrt(2) mod pi? 17.09.13 # I think the mathematical definition and what programming languages do differs here 17.09.19 Join detaos [0] (~quassel@ip72-218-104-242.hr.hr.cox.net) 17.09.39 # * amiconn is clearly with linuxstb regarding sim code and target tree 17.09.48 # I think the binsize reduction comes from making the while() an if() not from the rearangement, which in fact changed the logic too 17.11.23 # there isn't even a binsize reduction it seems 17.12.14 # * gevaerts grumbles about people being opposed to things after a commit which was announced a week in advance on the mailing list 17.12.21 # kugel: To be honest, yes, I don't think you fully weighed it up ;) Your view right from the start was to use target-tree to share code between the sim and RaaA, and you never seemed to have seriously considered not doing that.. 17.12.24 # New commit by 03jethead71 (r26090): MPEGPlayer: reconceal the point puns 17.13.39 Quit JohannesSM64 (Excess Flood) 17.14.03 # Wasn't our policy last year to have GSOC work happen in branches? 17.14.52 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 17.15.18 # * linuxstb isn't complaining about how kugel went about the commit - it's his own fault for not paying enough attention during the last week. 17.15.28 # linuxstb: my view was influenced by saratoga, but believe it or not I weighted it up. I just came to a different conclusion as you 17.15.30 # New commit by 03alle (r26091): Improve spacing in comments 17.16.49 # Llorean: for some projects that's doable, but with the RaaA project, at least for the current phase, if you don't commit it quickly to trunk, merging will be horrible 17.17.29 # New commit by 03jethead71 (r26092): How punny. Just one more whack-a-mole to get. 17.17.54 # the german wikipedia article mentions 2 mod variants, the mathematical and the symmetrical one. C appears to use the symmetrical one (-a mod b == -(a mod b)) 17.18.13 # I also think fml's commit doesn't work 17.18.52 # just for the fact that preset_count is added *after* taking the mod, and not before, but well 17.19.43 Quit yosafbridge (Quit: Coyote finally caught me) 17.20.22 # if -1%5 == -1 then it should work 17.21.01 Join yosafbridge [0] (~yosafbrid@li14-39.members.linode.com) 17.21.06 # as long as preset is never less than -present_count 17.21.13 Join halmi [0] (~netbook@80-123-38-28.adsl.highway.telekom.at) 17.22.33 # JdGordon: what is 1%5? 17.22.59 Quit evilnick|ipad (Remote host closed the connection) 17.23.07 # 1 17.23.11 # according to that wiki article C does -1%5 == (1%5)*-1 17.23.30 # * gevaerts wonders if we disagree about the end result for RaaA/sim, or just the way to get there 17.23.33 # ranma: which revision is your current svn checkout ? 17.24.16 # gevaerts: I personally am not too concerned about the end result for RaaA, as long as it doesn't reduce the ability of the sims to be used for what they currently are supposed to do. 17.24.23 # gevaerts: from what I remember about its start then it wasn't clear 17.24.41 # pixelma: I mean specifically the target tree discussion here 17.25.47 Quit halmi (Read error: Connection reset by peer) 17.27.08 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 17.27.31 # * kugel thought 1%5 = 5 or some reason 17.28.16 # kugel: You will never, ever get the number on the right side of a % out of modulus 17.28.23 # Well 17.28.25 # Maybe if 0s are involved 17.28.27 # I really don't know there 17.28.49 # %0 will give you a nice div0 exception 17.29.16 # i like the % pi of jhMikeS ;) 17.30.37 # google does "(-1) mod 5 = 4" 17.30.49 # ranma: yesterday it worked (linux reacted) on clipv1 but not today, i assume usb only works on odd days 17.32.45 # kugel: That's because, I assume, mathematically a remainder can only ever be positive. 17.33.12 # * kugel thinks r26089 doesn't help anything except creating confusion 17.37.08 # funman: 25990 17.37.09 Quit n1s (Ping timeout: 240 seconds) 17.40.04 # gevaerts: Using terms like "RaaA/sim" is the main problem I have - I don't want to see the two things being lumped together. But as long as they are thought of independently, and there is the possibility to do things differently in one than the other, then I'm basically happy. 17.42.28 Quit funman (Quit: free(random());) 17.42.59 Quit JohannesSM64 (Quit: WeeChat 0.3.3-dev) 17.44.11 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 17.45.26 # linuxstb: ok, I think we can promise that 17.45.33 # * gevaerts looks at kugel 17.45.53 # Yep, I think so too 17.50.21 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 17.51.21 *** Saving seen data "./dancer.seen" 17.54.42 Quit anewuser (Quit: for SELL 2 by the price of 1 now!) 18.02.03 Quit JdGordon (Quit: Leaving.) 18.05.08 # * kugel needs soon to think about #defines to use for RaaA 18.05.58 # #define CONFIG_CPU [CPU_]SDL seems weird, but that would be inline with the current ports 18.06.51 # kugel: isn't CONFIG_CPU used to switch optimisations? 18.07.05 # yes and no 18.07.30 # mostly for optimizations as far as iram allocation is concerned 18.07.54 # for asm, the #defines CPU_ARM, CPU_COLDFIRE, etc are used 18.08.09 Join Jaykay [0] (~chatzilla@p5DC56DEC.dip.t-dialin.net) 18.09.38 # CONFIG_CPU is #undef'd in the sim so that work out as well 18.10.36 # but I could also imagine a higher CONFIG_PLATFORM (could be e.g. PLATFORM_NATIVE or PLATFORM_HOSTED) 18.10.51 # yes, that seems better 18.11.16 # * gevaerts wonders about sims for RaaA targets 18.11.23 # a mix of both could also work 18.13.40 Quit S_a_i_n_t () 18.16.47 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 18.18.56 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.246) 18.20.45 # gevaerts: That could be complicated, since you'd then want to simulate the native widgets of the device if they're used. 18.21.01 # Llorean: don't shatter my dreams! 18.21.03 # Don't many RaaA targets have emulators or other development tools anyway, so a sim may not be necessary? 18.21.12 # *potential RaaA targets, rather 18.21.28 # they do, but they 18.21.33 # 're not always easy to set up 18.22.07 # Well, sims that had no additional dependencies beyond our current ones would be neat of course. 18.22.13 Quit S_a_i_n_t (Client Quit) 18.24.26 Quit bieber (Ping timeout: 260 seconds) 18.24.51 Join bieber [0] (~bieber@162-78.97-97.tampabay.res.rr.com) 18.25.26 # * kugel wonders about the "native widgets" talk 18.25.30 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.250) 18.26.01 # kugel: You'll note I said "if they're used" 18.26.33 # yep, it hasn't been decided whether we want that or not 18.26.39 # but I would not want them 18.26.40 # As an app, there are many situations where keeping the Rockbox UI metaphor is extremely restrictive. 18.27.02 # that depends on the device 18.27.05 # Anyone with a PP5020 target around that uses the colour lcd bridge? 18.27.40 # kugel: Yes, but it should generally be assumed that it could end up on such a device - while it doesn't need to use native widgets now, it should strive to not rule out the possibility to do so later. 18.27.49 # for instance on a smartphone I can imagine that our own gui could work extremly well (i.e. as well as it would if rockbox is run natively) 18.28.01 # amiconn: "the color" meaning "in color" or "the same one as the iPod color" or? 18.28.23 # * pixelma somehow doubts many people would know if their player is a PP5020 target with the lcd colour bridge 18.28.28 # The same bridge (in the PP) as the ipod color 18.28.33 # but on a PC it could be akward indeed 18.28.35 # amiconn: Which targets is that, then? 18.29.03 # Examples: iPod Color, Nano G1, H10 (big and small), e200v1 18.29.08 # kugel: On some smartphones it might be very much preferred to use, for example, a native file browsing interface if available, etc. Rockbox's current one is pretty clunky, even with text, compared to what such users may be used to. 18.29.13 # amiconn: I have a nano G1 18.29.27 # but do we agree that the native widget thing is out of scope for this gsoc project? I don't want to rule it out completely but I don't really want to work on it during the summer (especially since I have personal interest for it) 18.29.32 # kugel: But I'm just saying, we should try to assume we might want to in the future *if reasonably possible* 18.29.39 # I'd need an iospace dump from 0x70008000 to 0x7000ffff (i.e. 32KByte) 18.29.51 # I could do it myself if I had an appropraite target with me 18.29.58 # *no* personal interest 18.30.09 # kugel: In my opinion, you shouldn't need to work on native widgets unless everything else works. But you should try to make sure that, if possible, replacing one of ours with a native one won't be harder than it needs to be (if it doesn't make your work significantly harder) 18.30.31 Join einhirn [0] (~Miranda@p54851442.dip0.t-ipconnect.de) 18.30.32 # Oh, hmm, nano g1 is not suitable 18.30.32 # that's fine with me 18.30.40 # amiconn: Unless there's a way to do that without me compiling my own build, I don't think I can help. No build environment atm. 18.30.46 # Ah, never mind then. 18.30.48 # It doesn't use PP5020, but PP5022, and that has different io aliasing 18.31.12 # So essentially just ipod color and H10 (big/ small) 18.31.35 # kugel: I think that's good then. I doubt we're going to decide if we want native widgets or not any time soon anyway, and some targets Rockbox widgets are simply going to be better anyway, so support for *our* widgets will always be necessary I think. 18.31.35 # It looks like the elio might use an alias address - I'd do it myself, but I don't have a suitable target with me 18.34.47 # amiconn: I can do it, but my H10 needs to charge a bit first apparently 18.37.57 Join mighty_ [0] (~mighty@41.251.99.59) 18.38.08 # Hi 18.38.17 # * amiconn can do it later tonight 18.38.26 # amiconn: I assume I just need to adjust dbg_save_roms() in apps/debug_menu.c a bit? 18.38.47 # anyone speak french ? 18.38.51 Nick mighty_ is now known as mighty (~mighty@41.251.99.59) 18.39.06 Nick mighty is now known as Angelichounet (~mighty@41.251.99.59) 18.39.41 # :-/ 18.39.50 # I did a rudimentary PP5020 emulation for skyeye. So far it only emulates core id, pp version and the usec timer in a proper way 18.40.02 # gevaerts: Yes, that should work 18.40.37 # gevaerts, hello 18.40.47 # I found a bunch of accesses to 0x7000ad00, which our pp5020.h doesn't know. It might have to do with lcd 18.41.12 # gevaerts: Hmm, better dump the whole 64KB starting at 0x70000000 18.41.19 Join Strife89 [0] (~Strife89@adsl-67-63-181.mcn.bellsouth.net) 18.41.42 # Anyone know if it is possible to install games on iPod Nano 3nd gen ? 18.42.45 # yes, no. 18.43.05 # ;) No, sorry. It isn't. 18.43.05 # :-/ 18.43.06 # do you mean a 2nd or a 3rd generation Nano? Also installing any games is off-topic here, installing Rockbox is not 18.43.57 # je parle de Rockbox, mais j'arrive pas à l'installer pour avoir des jeux sur mon ipod 18.44.03 # * gevaerts hopes that his H10 will be charged enough to actually boot rockbox soon 18.44.23 # oups 18.44.27 Quit GeekShadow (Read error: Connection reset by peer) 18.44.41 # I talk about Rockbox, but I can not install it for games on my ipod 18.44.54 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 18.45.47 # is your Nano a 3rd generation one? The "short/fat" one? 18.46.41 # Nano a 3rd generation 18.46.45 # and fat 18.47.04 # then no, it's currently not possible to install Rockbox on it 18.47.27 # mouarf xD 18.47.43 # thank you anyway 18.49.54 Quit Angelichounet (Quit: Quitte) 18.52.52 Join anewuser [0] (anewuser@unaffiliated/anewuser) 18.54.21 Quit BeFalou (Ping timeout: 240 seconds) 18.56.00 Join n1s [0] (~n1s@rockbox/developer/n1s) 18.56.54 Join BeFalou [0] (~mamutoi@unaffiliated/befalou) 18.57.15 Quit kugel (Remote host closed the connection) 18.57.31 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 19.04.29 Quit BeFalou (Remote host closed the connection) 19.07.37 Join BeFalou [0] (~mamutoi@unaffiliated/befalou) 19.12.12 Quit JohannesSM64 (Quit: WeeChat 0.3.3-dev) 19.12.32 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 19.13.43 Quit stoffel (Remote host closed the connection) 19.13.46 # while the sim compiled for me under cygwin it isn't usable, background etc. appears and goes to the menu but it is unresponisve and I can't do anything. Does anyone else see that? 19.15.29 # revision 26092, fm enabled M5 sim 19.16.58 # * pixelma could also try a crosscompiled sim 19.21.04 # I'm trying a mingw sim here 19.23.49 # amiconn: http://www.evonet.be/~gevaerts/iospace.bin 19.25.33 # Thanks 19.27.27 # Hmm, that stuff at 0x7000ad00 isn't lcd... but there is something 19.28.09 # * amiconn spots a possible optimisation when dealing with the colour bridge though 19.28.48 # pixelma: a mingw-built sim in wine also seems to ignore all keypresses 19.29.00 # * amiconn wonders whether he could dump the iospace on the elio, even if lcd isn't working 19.29.25 # gevaerts: did you try a linux "native" sim also? 19.29.33 # pixelma: yes. That one works 19.30.03 # *sigh* 19.30.36 # The good news is that one doesn't need cygwin to work on this :) 19.30.40 # at least you can reproduce... 19.31.54 # Hmm, ipod (and hence rockbox) already uses an alias for the colour bridge.... that one is avaliable at base 0x70008Y00 with Y = {0, 2, 4, 6, 8 , a, c, e} 19.32.42 Join saratoga_ [0] (~463f90ed@gateway/web/freenode/x-jjduostbjujjnlkh) 19.32.53 # * amiconn wonders why... 19.33.04 # can an article about rockbox use our logo? 19.33.23 # pixelma: I suspect "and the implicit application thread will now act as our main thread (previously a separate one was created for this in thread initialization)" in r26065 19.37.06 # saratoga_: I don't see why not but don't know a lot about licenses 19.37.24 # saratoga_: sounds like basic fair use to me 19.37.42 # wiki says they can, so sounds good 19.44.11 Join Xqtftqx [0] (~Xqtftqx@d118-75-250-46.try.wideopenwest.com) 19.44.55 # are there any present devices i can buy in a store that rockbox runs on 19.46.40 # That depends on what you mean by "runs" 19.46.59 # And possibly "buy in a store" 19.47.14 # pixelma: I've submitted FS#11280 for this. This is really something for kugel to look at 19.47.19 Quit anewuser (Quit: for SELL 2 by the price of 1 now!) 19.47.23 # Hmm, PP502x might have two colour lcd bridges... 19.47.27 # Is there a device being manufactured that rockbox is usable to play audio on 19.47.37 # Xqtftqx: Basically, there's a list of supported and unstable targets on the front page. 19.47.40 # Look for them in stores near you. 19.47.51 # gevaerts: thanks, just wanted to ask if you were looking into it 19.47.56 # Xqtftqx: I suspect some of the newer sansas 19.48.55 # pixelma: I looked a bit, but this is going to be related to threading changes, and I really don't know those well enough to look for this efficiently 19.51.22 *** Saving seen data "./dancer.seen" 19.52.14 # saratoga_: Some math help. :) .. 1024 samples/channel * 2channels = 2048 samples .. for 2 bytes/sample, the total size should be 4KB .. I'm getting the total size from the wma pro decoder to be 8KB .. Is there something I'm missing ?? 19.52.22 Join mikroflops [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) 19.52.58 # mt: does it returin 32 bit samples? many codecs do 19.53.47 # it returns floats yes .. but then the size is 16K .. I divided that by 2 because I'm converting them to 16-bit signed ints, so I'm getting 8K 19.54.37 # i'll look at svn 19.54.43 Join esperegu [0] (~quassel@145.116.15.244) 19.55.50 Quit mikroflops_ (Ping timeout: 248 seconds) 19.59.22 # WMA standard actually returns 2048 sample per channel per frame for 44.1khz audio 19.59.40 # WMA Pro seems to use the same transforms, so maybe its 2048 per frame too? 20.00.15 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 20.00.16 # actually looking at the code it seems like it can also return 4096 samples, but probably only at higher sampling rates 20.00.45 # I'll check .. although I have audio working already in the sim, but I wanted to know why I needed to divide the output data_size by 2.. 20.01.16 # well actually by 4 .. 20.01.22 # 2 for 2 bytes/sample 20.01.38 # and then the other still-unknown 2 20.02.12 # where do you divide it by 2/4? 20.02.18 # wmapro.c? 20.04.13 # yes 20.04.29 # I'll submit a patch very soon .. 20.05.08 # but for now .. I divide by 2 first when I convert the output format to int16_t in wmaprodec.c .. 20.05.09 Quit Jaykay (Ping timeout: 240 seconds) 20.05.17 # then I divide by 4 in wmapro.c 20.05.21 Quit n1s (Ping timeout: 240 seconds) 20.05.40 # oh 20.05.51 # it's actually 2048 samples 20.06.22 # :) 20.06.44 # if possible could you make wmapro.c return 32 bit ints? 20.07.50 # But the sim uses s16bit pcm ? 20.08.04 # the DSP code though runs in full 32 bit precision 20.08.26 # so it'll convert everything back to 32 bit when it does EQ, replaygain, etc 20.09.14 # Alright 20.09.34 # see: http://svn.rockbox.org/viewvc.cgi/trunk/apps/codecs/wma.c?r1=13925&r2=14224 20.09.37 # hmm .. something isn't right 20.09.59 # the decoder is actually only filling a total of 2k samples 20.10.24 # so it is 1024 per channel? 20.11.19 # Yes 20.11.30 # New commit by 03funman (r26093): Clipv2/+ : ascodec register 0x25 is not related to backlight 20.11.35 # dump_context says it's 2048/frame 20.12.08 # so it should be 1k/channel 20.14.27 Join stoffel [0] (~quassel@p57B4CBEF.dip.t-dialin.net) 20.15.09 # mt: int total_samples = s->samples_per_frame * s->num_channels; 20.15.20 # samples_per_frame is per channel i think 20.17.06 # Still it's only filling 2k locations .. if I pass pcmbuf_insert a count of 4k, I'm giving it just 2K of zeros. 20.17.55 # can you check how many samples wmapro_window is generating? 20.22.50 # it seems to be 256/channel 20.24.00 # saratoga_: ^ 20.25.35 # mt: in wma there can be many blocks per frame 20.25.55 # its not like cook where they're all the same size, instead you just have to add up to samples_per_frame 20.26.10 # so 2048 is valid, as is 256+512+256+1024 20.26.21 # (sorry if you already knew that) 20.29.22 # you mean 2K per channel ? 20.30.59 # yeah i *think* 20.31.08 # wma stadard is 2k per channel at 44.1k anyway 20.31.21 # as is vorbis and aac 20.31.43 # Everything says it has to be 4K .. but what I'm hearing disagrees :) 20.32.01 # can you print all the sizes used by wmapro_window in one frame? 20.32.07 # saratoga_: I'll submit a patch so it would be easier to discuss ok ? 20.32.12 # sounds good 20.33.01 Join wincent [0] (~wincent@g227112211.adsl.alicedsl.de) 20.39.52 Quit GeekShadow (Ping timeout: 268 seconds) 20.42.39 Quit stoffel (Remote host closed the connection) 20.43.37 Quit intrados (Quit: WeeChat 0.3.2) 20.46.12 Quit TheSeven (Read error: Connection reset by peer) 20.46.30 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 20.46.41 # saratoga_: http://www.rockbox.org/tracker/task/11281 20.54.10 # mt: it looks fine to me, and very similar to wma 20.55.54 # unfortunately i have no way to compile it for another hour or so 20.56.05 Quit esperegu (Ping timeout: 248 seconds) 20.56.12 # Ok no problem .. 20.56.21 Quit ssorgatem (Quit: Konversation terminated!) 20.56.33 Join ssorgatem [0] (~ssorgatem@83.54.169.89) 20.58.36 # saratoga_: Could that clicking noise be a precision problem ? 20.58.57 # could be overflow, could be dropped samples somewhere 20.59.04 # overflow usually sounds like a burst of static 21.00.16 # dropped samples would just give silence, no ? 21.01.33 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 21.01.44 # depends how many you drop 21.01.51 # if its just a few its a click or a pop 21.01.54 # outlen /= 4; //XXX: Why 4 ? 21.02.03 Join esperegu [0] (~quassel@145.116.15.244) 21.02.07 # isn't this just converting from bytes from floats? 21.02.12 Quit esperegu (Remote host closed the connection) 21.02.12 # since 4 bytes per float? 21.03.13 Join krabador [0] (~ubuntu@host158-217-dynamic.117-80-r.retail.telecomitalia.it) 21.03.25 Quit wincent (Changing host) 21.03.25 Join wincent [0] (~wincent@rockbox/developer/wincent) 21.03.46 # i'm probably missing something stupid, but it seems like the decoder tells you the number of bytes its returned, and it returns floating point samples, so you have to divide by 4 to get the number of samples 21.08.44 # saratoga_: you're right .. but I'm converting the samples to int16 in wmaprodec.c (decode_packet() ).. so the output number of bytes should be /2 not /4 21.10.59 Quit guysoft22 (Read error: Connection reset by peer) 21.11.14 Join guysoft22 [0] (guy@bzq-79-180-53-22.red.bezeqint.net) 21.11.54 # sorry i was looking at the unpatched version . . . 21.13.25 # Ah ok no problem. 21.13.38 Join dobson [0] (~rokas@88.118.35.180) 21.14.11 # hey guys, i have quite a big idea, that you may could bring to reality 21.14.40 # you know when you go to recording and you can hear surroundings amplified 21.15.10 # so why not to make funcktion to invert the sound, that player would become noise canceling 21.15.18 # theoreticly 21.15.34 # its not really possible given how noise cancelation works 21.16.08 # whel noise cancelation works by inverting sound wawe, so it couls ilaminte each other 21.16.28 # i think that shouldn 21.16.35 # be hard to do 21.17.17 # yes but it requires you to measure the noise field essentially at the point where you're canceling it, so you need special headphones that are designed to work with it 21.17.32 # you can't just measure sound at the player and expect it to be in phase with sound in your ear 21.17.42 # yea you need to sinchronize it 21.18.01 Quit flydutch (Quit: /* empty */) 21.18.01 # thats where programing comes in 21.18.15 # its not possible to do this in software 21.18.31 # all that noise canceling headphones do invert sound vawe 21.19.10 # i'm not talking about playing music at the same time 21.19.15 # heh well if you've discovered a way to do this, then by all means submit a patch 21.19.54 # i'm don't know anything about rockbox code :) 21.20.11 # but i will try to just invert sound with amplifier 21.20.16 # i think thats the least of your problems :) 21.20.44 # and if that works it should be plausible to invert it in player 21.20.48 # i think :) 21.21.17 # thing like that would be incredible upgrade in rockbox 21.24.09 # incredible indeed 21.33.45 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 21.35.26 # I think we would all be interested to see you make it work 21.35.51 # I think it is fair to say that we are sceptical too 21.36.41 Quit domonoky (Client Quit) 21.37.02 Quit saratoga_ (Quit: Page closed) 21.37.06 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 21.37.23 Part Boldfilter 21.39.39 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 21.41.20 # AlexP: I reworked the start screen description quite a bit according to your suggestion about item and explanation not starting lower case (also put things a bit differently to make the text shorter) - http://pastebin.com/x7N85PS7 21.42.29 # oh, and linuxstb once said that he would drop the "will" in all those sentences so I tried that. I overlooked some it seems though 21.47.00 # pixelma: I changed a couple of minor things: http://pastebin.com/2YsPnhtC 21.47.12 # pixelma: One thing is the verb form - Show vs Shows 21.47.38 # Both are there - I changed them all to the Shows form, but I can't remember what the consensus was for the rest of the manual 21.47.45 # yep, found it too :\ 21.48.49 # what do you think in general - is this version "better"? 21.48.56 # Yep :) 21.50.35 # ok, after checking if there is some guideline regarding shows/show and potentially adapt to it, I'll commit that then. Improvements can still be done later but the current description is a bit coarse IMO 21.51.12 # pixelma: The manual was changed to be all one way (after some discussion), so it *should* be easy to just see what is used now :) 21.51.26 *** Saving seen data "./dancer.seen" 21.51.46 Join lpereira [0] (~lucien@170.184.84-79.rev.gaoland.net) 21.52.35 # really? 21.52.51 # yeah, I'll see if I can find a date 21.53.17 # I think I saw something in the guidelines once but I have my doubts that it is used consistently now 21.56.20 Quit bieber (Ping timeout: 268 seconds) 21.56.46 Join bieber [0] (~bieber@162-78.97-97.tampabay.res.rr.com) 22.01.11 Join bholu [0] (~43a248e4@giant.haxx.se) 22.01.58 # AlexP: hmm, nothing on LatexGuidelines... would be nice if you would find something :) 22.01.58 Quit bholu (Client Quit) 22.02.19 # I'll have to search the commits - give me a while :) 22.02.25 # sure 22.08.00 Quit dobson (Ping timeout: 276 seconds) 22.08.55 # pixelma: http://www.rockbox.org/tracker/task/10861 - I assume the IRC discussion was the same day. Just before that it was changed to the other form, then this task changed it to this. The commit is linked from the task, there was another commit shortly afterwards (by alle) to change a few missed ones 22.09.36 Join tenfoot [0] (~57708228@giant.haxx.se) 22.09.50 Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) 22.10.17 # kugel: any special reason you yanked out my logf debug lines from the sdl sound code? They were in there for a reason. 22.11.04 # AlexP: thanks 22.11.11 # Moving files is one thing. You gotta do what you gotta do. Moving then and then making undocumented changes is something else. 22.11.15 # *them 22.14.07 # In addition, putting the debugaudio code within conditional compile statements negates the value of having --debugaudio on the command line. 22.14.12 # >:( 22.14.21 # AlexP: although it is for a different kind of description. The thing that got me a bit is the beginning of the first explanation - "Rockbox starts", then all the following sentences looked weird 22.17.02 # pixelma: Yes, I agree - I think here removing the "Rockbox" then having everyhting as "Start" would look better. 22.17.21 # Also, "Go to the WPS and resume playback from where it was" 22.17.53 # fine, I'll trust your opinion as a native speaker :) 22.18.04 # Actually, "Start Rockbox in the ..." 22.19.16 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 22.19.16 # do I need the "in" in this sentence? 22.19.31 # err... I mean the second one 22.19.35 # Maybe "Set the screen that Rockbox will start in. The default is..." 22.20.02 # Which sentence now? :) 22.20.08 # there is a default? 22.20.41 # I don't know, I was just looking at the English 22.21.09 # line 14 in the pastebin 22.21.15 # oh, I didn't mean the introduction but the explanation of the first item 22.21.37 # the "previous screen" one 22.21.39 # yeah, I think you need the in 22.21.45 # the second in 22.21.58 # If the sentence stays like that anyway - I'll try rearranging 22.22.52 # "Start Rockbox in the same screen as when it was shut off" maybe 22.23.31 Join Strife1989 [0] (~Strife89@adsl-80-135-156.mcn.bellsouth.net) 22.23.37 # meh, I just realised that I point out the default twice in my patch (introduction and "main menu" item) 22.25.37 Join Strife89|Laptop [0] (~Strife89@adsl-80-129-208.mcn.bellsouth.net) 22.26.12 Quit Strife89 (Ping timeout: 276 seconds) 22.26.27 Nick Strife89|Laptop is now known as Strife89 (~Strife89@adsl-80-129-208.mcn.bellsouth.net) 22.28.39 Quit Strife1989 (Ping timeout: 276 seconds) 22.29.02 Quit Xqtftqx (Ping timeout: 252 seconds) 22.32.32 Quit stripwax (Read error: Connection reset by peer) 22.36.51 Join Boldfilter [0] (~Boldfilte@adsl-71-215-115.jax.bellsouth.net) 22.37.20 # AlexP: final version (I hope) - http://pastebin.com/mDFvSgLr 22.40.15 # pixelma: A couple of tiny changes, but looks good! http://pastebin.com/easNpE1r 22.44.43 Join n1s [0] (~n1s@rockbox/developer/n1s) 22.47.08 Quit bmbl (Quit: Bye!) 22.48.11 # many thanks :) 22.48.39 # no worries :) 22.52.28 Quit dfkt (Ping timeout: 264 seconds) 22.54.37 Quit GeekShadow (Quit: The cake is a lie !) 22.56.00 Join max242 [0] (~m.debacke@90.144-67-87.adsl-dyn.isp.belgacom.be) 22.56.32 Join Farthen_ [0] (~Farthen@f054014207.adsl.alicedsl.de) 22.56.36 Quit Farthen_ (Client Quit) 22.57.26 Quit petur (Quit: Zzzz) 23.03.55 Quit Schmogel (Ping timeout: 265 seconds) 23.03.56 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 23.04.49 # is there anybody in here who has seen my post on about PictureFlow locking up the Fuze V1? 23.05.01 # i posted this here: http://forums.rockbox.org/index.php?topic=24496.msg165106#msg165106 23.05.44 # New commit by 03pixelma (r26094): Update and complete the start screen option description in the manual. Thanks to Alex Parker for the native speaker help. 23.06.02 Quit JohannesSM64 (Quit: WeeChat 0.3.3-dev) 23.10.12 # max242: did you figure out which revision caused the problem? 23.11.13 Join Schmogel [0] (~Miranda@p3EE21A0F.dip0.t-ipconnect.de) 23.11.25 # yeah, that was 25299 23.12.04 # quite a long way back, and current revisions still have the same issue 23.12.34 # what do i need to do to reproduce it? 23.13.32 # that's a very good question, i don't know yet what causes PictureFlow to lock up the Fuze V1 23.14.21 # i thought it had to do with the size of the microSD card i've got plugged in 23.14.28 # which is 16G 23.14.57 # but apparently, my fuze also locks up every now and then having no microSD card inserted at all 23.16.10 # funman replied to the thread i started a couple of times 23.16.12 # does pictureflow lock up for you then without the card and just a bit of music on the internal memory? 23.16.24 # max242: maybe a stupid question, and probably not helpful, but is the filesystem OK? 23.17.18 # gevaerts: yes, the filesystem is ok, i've even reformatted the Fuze to be sure on this one 23.18.30 # max242: can you put your .rockbox/config.cfg on pastebin.com or similar? 23.19.16 # pixelma: pictureflow locks up randomly during the generation of the .pfraw files, at least that's what i think is wrong 23.20.11 # well you mentioned a possible relation to your microSD card which I wanted to find out more about 23.20.24 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 23.20.41 # gevaerts: i'm new in this thing, and never used pastebin.com before. do i need an account 23.20.49 # no 23.20.57 # no, you just paste some stuff there and you get a link 23.22.01 # does it matter which revision i currently am using? Because i'm on r26093 right now 23.22.05 Join anewuser [0] (anewuser@unaffiliated/anewuser) 23.22.07 # no 23.22.07 Quit liar (Quit: Verlassend) 23.23.37 Quit tenfoot (Quit: CGI:IRC) 23.23.42 # how come picture flow doesn't update its album cache automatically 23.24.03 # it recognizes new albums, but i have to tell it to rebuild the cache before they have album art 23.24.11 Quit anewuser (Client Quit) 23.25.28 # ok, my config.cfg is on pastebin now: http://pastebin.com/YXMeM6KL 23.25.31 # well other then that it seems to work on my fuzev1 23.26.18 # linuxstb: Do you think I should commit the colour lcd bridge un-aliasing? 23.26.21 # do we really have database autoupdate off by default? 23.26.21 # nothing too special there I'd say 23.26.49 Quit n1s (Ping timeout: 260 seconds) 23.28.11 # saratoga: what do you mean by pictureflow recognizing new albums? I always do rebuild the database, then trigger PictureFlow to generate a new cache 23.28.31 # * gevaerts doesn't have a fuze so he can't really try to reproduce this 23.28.47 # i copied new songs to the player, then loaded pictureflow, they show up, but theres no thumbnails for them until i tell it to rebuild 23.29.19 # it seems like pictureflow should rebuild its album art whenever it detects new songs 23.30.25 # so i assume you do let rockbox update the database automagically? 23.31.48 # linuxstb: I tested it on my Color and my H10 and it works. Someone should dump regs on a colour PP5021/2/4 to verify (that *excludes* c200v1) 23.32.20 # Oh, and it also excludes the Video, as well as the e200v1 23.33.01 # i also do remember that funman was thinking that there might be issues with the database, and that this maybe is the cause of these pictureflow issues? 23.33.23 # yes I set it to update automatically 23.33.50 # i even thought at one point that it has to do with timing issues towards the storage 23.33.53 # amiconn: how close were you to having skyeye working? 23.34.30 # saratoga: Depends. skyeye itself works, but depending on i/o emulation the boot rom may take wrong code paths 23.35.06 # so probably not very close to booting rockbox 23.35.19 Quit guysoft22 (Read error: Connection reset by peer) 23.35.22 # Certainly not, and that's not my goal at all 23.35.36 Join guysoft22 [0] (guy@bzq-79-180-53-22.red.bezeqint.net) 23.35.36 # I hope to find the elio's lcd init 23.36.18 Quit merbanan (Ping timeout: 265 seconds) 23.36.19 # Or rather, the lcd driver. 23.36.45 # also something i should mention: i also do have some issues every now and then when generating the database 23.37.20 Join M3DLG [0] (~M3DLG@bb-87-81-252-83.ukonline.co.uk) 23.38.19 # i think it is skipping some steps when trying to commit the database 23.38.50 # but it's been a while when i had these issues, and i don't remember exactly 23.40.37 # also building the database was sometimes very slow 23.40.51 # saratoga - right, pictureflows 'database' of album art is different to the rockbox tag database; and in fact pictureflow seems to index album art by an ID that becomes invalid if you add more albums and rebuild the database 23.41.39 # that makes sense, but its odd that it will see new entries and not try to load the art for them 23.42.10 # e.g. pictureflow has image A for album 1, image B for album 2, image C for album 3 .. and then you add a new album and rebuild the database, and now image B shows up for album 4 which happens to be alphabetically between album 1 and album 2 (or something like that) 23.42.13 # are you sure, about it using a different album data base? 23.42.24 # pixelma - see above 23.42.34 # *not* a different album database 23.43.06 # different 'database' of tag order. it seems to assign album art by an indexing scheme that is immediately invalid as soon as you rebuild the database 23.43.19 # ^rebuild the rockbox tag database 23.43.23 # stripwax: I meant the album "list". I think it's taken from the database, the indexed pictures are not 23.43.32 Quit lpereira (Quit: Leaving.) 23.43.55 # yes. whatever it is that tries to do the "left outer join" of those two lists, doesn't do a good job if the db updates 23.44.06 # ah so the album art i saw was probbaly for the wrong album? 23.44.11 # probably 23.44.20 # stripwax: pictureflow uses the album index from the database, and that becomes wrong whenever albums are added or deleted 23.44.26 # that'd do it, yep 23.44.38 # my database has close to 6000 entries, could that be a potential issue? 23.44.43 # (unless this addition/ deletion happens at the very end) 23.44.44 # pictureflow seems pretty close to being useful, maybe that guy who added the hotkey stuff for it will be interested in improving it 23.45.02 # wasn't that kugel? 23.45.08 # The album list is sorted alphabetically, in order to allow chunked browsing 23.45.13 # http://www.rockbox.org/tracker/task/11270 23.45.29 # This problem exists since pictureflow has been introduced 23.45.44 # (i suspect I know the answer alread, but -) wouldn't it be better for pictureflow to record the album art id into the database itself? 23.45.59 # no 23.46.08 # The database is a core thing 23.47.01 # All it needs to do is to use a better index instead of the database's internal album id 23.47.15 # right 23.47.38 # when pictureflow is preparing it's album artwork, there's a green progress bar 23.47.48 # that's right 23.47.55 # wouldn't it be usefull to show where it is at already? 23.48.02 # "at" ? 23.48.21 # i mean, which directory or file it is processing 23.48.36 # I don't know - would it? how would that help? 23.48.42 # i understood pictureflow is generating pfraw files 23.49.19 # max242: does your pictureflow still crash if you use the same files, but from the simulator? 23.49.58 # i've never really used the simulator before, but that definitely seems a good idea 23.50.44 # theme site needs the fuzev2 added to it 23.50.45 # however, i have a iPoD video around, and there i never got these pictureflow issues 23.50.59 # does it have exactly the same folder structure as your fuze? 23.51.28 *** Saving seen data "./dancer.seen" 23.51.32 # no, it has different content, and i don't use it that much because of the battery draining too fast 23.52.13 # Llorean: ping 23.53.46 # ok, i'll try to use the simulator on the same batch of files later during the week, i'm off to bed now 23.57.08 Quit Xerion (Ping timeout: 240 seconds)