Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2009-11-06

00:00:05LloreanIs there any way to make it skinnable? Break it into arbitrary conditionals similar to the volume one (and peakmeter left/right could each have a conditional like this) so that they can look nicer?
00:01:05JdGordon|*anything* is possible :)
00:01:36JdGordon|histogramn might be difficult to do, but it would be cool to split the peakmeter into 2 seperate tags
00:02:02LloreanOkay, "any good way" ? :-P
00:02:25 Quit bertrik ("De groeten")
00:02:31JdGordon|good from whos perspective?
00:02:51LloreanI don't know. Heh.
00:03:01LloreanYeah, I'd imagine it'd be more difficult for the histogram.
00:03:04JdGordon|it would be very cool to have it split into left and right, and have it draw like the progressbar does (and allow vertical also)
00:03:10LloreanAgreed!
00:03:22LloreanI've kinda felt the peakmeter is basically useless now for anyone wanting to use a modern theme.
00:03:30LloreanSince you can't really do anything with it.
00:03:59peturpeakmeter is essential for recording, though
00:04:21Lloreanpetur: I meant in playback, rather.
00:04:26peturah ok
00:04:34LloreanSince until recently recording screen theming was more or less just a pipe dream.
00:04:39 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk)
00:04:58peturvertical peakmeters would be a space saver
00:05:24peturand we need a big recording indicator. Or even change background according to state
00:05:28 Quit pamaury ("exit(*(int *)0 / 0);")
00:05:38*petur starts dreamin aloud
00:06:04LloreanWouldn't the recording indicator be as big or as little as the author wanted it, much like the playback indicator in the WPS?
00:06:34LloreanVertical peakmeters would be easy with tags similar to the volume tags. Volume can be arbitrary right now since it's just a certain range for each image.
00:07:13peturdon't forget peakmeters are updated *very* frequently
00:07:31JdGordon|25Hz
00:09:13LloreanI just meant in the sense of "if you are able to offer users the ability to use such tags, it would allow vertical peakmeters" as either way it's just replacing/redrawing images. The images at 25hz is probably the hard part, I guess.
00:09:45LloreanI guess the other alternative is doing them like the progress bar instead. Less flexible, but probably more able to be optimized.
00:09:55peturright now it paints black rectangles
00:10:27peturdoing a memcpy of an image should work too
00:10:29JdGordon|Llorean: for the peak bars I'd rather it work like that instead of having hundreds of conditionals...
00:10:35JdGordon|either of course could be fixed up
00:10:48LloreanI think doing it like volume is a lot more flexible from the user standpoint.
00:10:52gevaertsIf images aren't achievable, you could let orientation, size and colour be settable. Those shouldn't cost too much
00:10:56peturwe can start simple and go from there?
00:10:59LloreanYou could have a variety of neat effects based off the peak meters.
00:11:34JdGordon|cant you do colour already using viewports?
00:11:47LloreanI'd say you need two colors.
00:11:49LloreanBorder and filling.
00:12:03LloreanOr maybe a color and a gradient even.
00:12:05pixelmaI'm still annoyed be the two line heigh peakmeters on the Archos recording screen
00:12:14pixelmas/be/by
00:12:57JdGordon|you wouldnt like to make the rec screen skins would you? thats the only thing really stalling the work
00:13:10 Quit liar (Read error: 148 (No route to host))
00:13:38peturpixelma: if you enable trigger, they become smaller :p
00:13:38 Quit jgarvey ("Leaving")
00:14:24pixelmaat least it would be less ugly even if it wouldn't help readability of the settings on the screen
00:15:34 Quit stripwax ("http://miranda-im.org")
00:17:00 Quit cdleonard (Read error: 110 (Connection timed out))
00:17:01 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk)
00:18:16 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.")
00:19:05 Join pushnell [0] (n=p@24-177-121-33.dhcp.mdsn.wi.charter.com)
00:20:29 Quit stripwax (Client Quit)
00:21:28gevaertsthere seem to be 10 screen sizes that do recording
00:21:54JdGordon|hwcodec and swcodec cant share skins :(
00:22:15JdGordon|kugel: unless you come up with a way to fix the feautre check to get rid of the false branch?
00:24:14gevaertsJdGordon|: no problem. There is no screen size with both HWCODEC and SWCODEC recording targets :)
00:24:15 Join liar [0] (n=liar@83.175.83.185)
00:24:34gevaertsI haven't taken remotes into account here
00:24:44JdGordon|ok, good
00:25:04peturgah.. I really hate that histogram patch... "hey look, I can add 5 features in one patch" :/
00:25:44peturnot to mention it is 2+ years old
00:25:46gevaertsI assume that maybe you want things to look different depending on mono/grey/colour, but I suspect that that doesn't really make any difference for the actual layout
00:25:47pixelmaeven then there are no screens exactly the same size but close (Iriver remotes 128x64, Archos screens 112x64)
00:26:29peturright now the recording screen has a fixed top part and uses the rest for the list
00:26:47gevaertsso only width actually matters?
00:27:05gevaerts(if you want to reproduce the current look)
00:27:14peturactually, it handles some stuff differently for small screens
00:28:18peturcalculated in recording.c at lines 1133 and following
00:28:41Unhelpfulkugel: i'll do a new gcc when i get to work, with fno-short-enums as a multilib option, so it can be used without compile warnings. if it still works i'll pull svn, maybe your bug is new? ;)
00:28:49 Quit pushnell ()
00:29:15peturand it switches to sysfont if your selected font is too big to fit everything
00:29:37 Join AEnima1577 [0] (n=clbarnob@c-98-249-3-190.hsd1.va.comcast.net)
00:34:02 Join GeekShado_ [0] (n=Antoine@APoitiers-552-1-26-133.w86-217.abo.wanadoo.fr)
00:34:57JdGordon|petur: I'm giong to keep the list part avilable using the %Vi viewport tag in the rec screens skin file..
00:35:46petureuh... you need the listbox to be able to select volume, L/R gain,...
00:36:19peturup/down selects what you change, left/right chages the setting
00:37:21 Join FlynDice_ [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net)
00:40:50 Quit GeekShadow (Read error: 60 (Operation timed out))
00:42:00pixelmathe trigger bar might be an interesting part for skinning too - e.g. as petur mentioned if trigger is enabled and this bar is shown, the peakmeters are one line high on small screens and otherwise the peakmeters are two line high. I'd prefer if the list viewport was one line higher then but the point is that people may want a different layout depending on trigger enabled or not
00:42:10 Quit saratoga ("Page closed")
00:45:01JdGordon|petur: yes, but you will be able to position it anywhere... I can force it to fail if that isnt setup
00:47:56 Quit Reggy_L (Ping timeout: 180 seconds)
00:48:54 Quit Galois (Remote closed the connection)
00:49:03 Join Galois [0] (i=djao@efnet.math.uwaterloo.ca)
00:49:06seaniFolks, given Petur's "5 features in one patch" comment, what's my best strategy with changes to add Binary Skip / Search to the "Skip Length" menu. I have FS 10754 as a small change in the wings, can I add these changes into that patch? Or will it be studiously ignored if I do?
00:49:47 Quit FlynDice (Read error: 110 (Connection timed out))
00:50:24peturone feature per patch please
00:50:43peturas we do one feature per commit too
00:51:27Lloreanseani: You should do the binary skip as a setting for skip mode as one patch, then a second patch dependent on it for the automated use of it, etc.
00:51:48LloreanYou really haven't argued a solid case for why it should have such special handling other than "I would like it that way" so far anyway - it doesn't really seem to need it.
00:52:35LloreanIf a user's listening to large audio book files anyway, they aren't likely to need a normal full-track skip mode anyway, so can just leave the binary search mode on if that's the most likely use they'll have for full skips, and it needn't interfere with simple seeking
00:53:44 Quit ender` (" A computer program will always do what you tell it to, and seldom what you want it to.")
00:54:56seaniLlorean: I've abandoned the special "automatic" binary search on resume / long track, but if it's selected from the "Skip Length" menu it persists in the same manner as the other "Skip Length" settings. Does that seem acceptable?
00:55:19LloreanSounds good to me, at least.
00:56:07LloreanIn "binary search" mode, skipping always skips half the remaining time in that direction then?
00:57:08 Quit Lynx_ (" HydraIRC -> http://www.hydrairc.com <-")
00:57:13seaniYes, and if the direction is reversed because of overshoot, it moves half the distance back to the last selected point so you can "zero in" on a specific point.
00:57:26 Join saratoga [0] (i=9803c6dd@gateway/web/freenode/x-7241ef988c330d8d)
00:58:09saratogaBlue_Dude: I put some ifdefs in a while ago to make cross fade only work on targets with enough buffer to use it, but they don't cover all its code because I wasn't sure where it all was
00:58:09seaniIf no PREV / NEXT navigation is pressed for 5 seconds, it resets so that you start jumping half the length in either direction again.
00:58:11LloreanSounds okay to me so far. Not something I would likely use regularly.
00:58:13saratogathey mostly just disable it
00:58:32LloreanI fall asleep in audio books all the time, but I bookmark when I start feeling tired, so I have an approximate range to search in anyway.
00:58:49LloreanUsually that range is "just go back to the bookmark, you can't remember anything when you're tired anyway" :0
00:58:50Llorean:) even
00:59:03saratogahonestly though I've argued before that given how complicated/buggy our playback engine is that if someone ever wanted to seriously try and improve it they ought to be able to remove crossfade for a time and then allow it to be reimplemented once playback was more stable
00:59:28saratogaand any other "enhancements " that were largely hacked into playback
00:59:47Lloreansaratoga: I remember being in favor of that. I'm not often for the breaking of features temporarily, but I hear about crossfade being problematic so often it seems a candidate for exception.
01:00
01:00:44saratoga(i hope blue_dude checks the logs)
01:00:44seaniMore complicated to explain than to use. I agree, a bit overengineered just for the "falling asleep" scenario, but I thought general binary search might have a use for visually impaired users if the position was read out. Maybe easier than trying to gauge acceleration if you can't see the status bar.
01:00:48 Quit Lss (Read error: 104 (Connection reset by peer))
01:01:25 Join Blue_Dude [0] (n=chatzill@rockbox/developer/Blue-Dude)
01:01:32seaniNo idea how the "read out" bit would be done.
01:01:33Blue_Dudesaratoga: I do check the logs... :)
01:02:12saratogamy feeling is that if you want to remove a feature you better have a good reason and make sure the core developers don't kill you
01:02:34saratogabut if its simply not well implemented there is some justification for it . . .
01:02:35Lloreanseani: The problem with binary search, in general, is that it depends on accurately being able to determine if you're before or after the point you're aiming for. As soon as you make a mistake on that judgment once (for example, not remembering you'd already heard a portion that did actually happen before, so you think you're past where you've heard) it throws off the whole search
01:02:37Blue_DudeAnd I left the old ifdefs in place because there are some playback routines that use crossfade init even if it isn't implemented.
01:02:43LloreanAnd after the 5 second timeout the searching will be very wild again.
01:03:03LloreanI'm not entirely sure that it's not one of those "sounds good on paper, bad in practice" ideas, but I haven't tested it yet, so I'm not judging.
01:03:12Blue_Dudesaratoga: was that comment for me?
01:03:25saratogayes
01:03:38saratogaI should have said "playback feature"
01:03:55Blue_DudeI didn't take out any features yet. Just bitching about the code.
01:04:22saratogaI was referring to your question about how many people actually use crossfade
01:04:45Blue_DudeI'll leave it in. That was more venting than anything else. I'll make it work out.
01:05:17Blue_DudeAnd I'll refine the ifdefs when I've consolidated the code some more.
01:05:40 Quit pixelma (Nick collision from services.)
01:05:42 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma)
01:05:47 Quit amiconn (Nick collision from services.)
01:05:52 Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn)
01:05:58 Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn)
01:06:01 Quit petur (Read error: 54 (Connection reset by peer))
01:06:02 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma)
01:07:01saratogagood, I like the idea of having build that cannot use crossfade not compile with it, IMO it would be nice to have more playback features be optional features rather the integral parts of rockbox's core
01:08:42Blue_DudeI broke out codec_thread last week and that seems to work OK. Tonight I moved the track change/crossfade code to pcmbuf where it belongs. I'm going to finish paring down pcmbuf, then tackle playback.c. That should be fun.
01:09:51saratogaif you have time, keep an eye on the logic used to decide when to buffer a .codec file in playback.c, I'm pretty sure its buggy but couldn't quite get my head around it
01:10:08saratogaits all twisted into a half dozen functions
01:10:10Blue_DudeI'd really like to have pcmbuf be modular for all audio playback without having all this crosstalk with playback.c and whatnot.
01:10:20saratogathat would be nice
01:10:28saratogait would make debugging 10x easier
01:10:30***Saving seen data "./dancer.seen"
01:10:51Blue_DudeThen I'm going to steal code from voice_thread. Then do the software mixer in pcmbuf.
01:10:56Blue_DudeIt'll take time.
01:11:06JdGordon|begin dead serious here... isnt it almost at the point where writing a well designed engine from scratch would end up causing less headache than trying the wrangle the current engine into a known state (knwon being peopl actulaly understanding all of it)?
01:11:23seaniLlorean: It doesn't seem tricky in practice, but of course I'm happy messing about with it and YMMV. For seeking by timestamp where you know you want to be 1hr 32min 5s in, it seems very effective. For seeking according to memory, the 5 seconds is meant to allow a bit of context to be heard and give you time to make the decision. It's a bit arbitrary, I had it at 10 originally, but got impatient testing it :-) Anyway I'll disentangle the two and put it up se
01:11:23seaniparately to be kicked about.
01:11:28saratogabreaking it up makes it more understandable
01:11:33 Join AndyIL [0] (n=pasha_in@212.14.205.32)
01:11:46saratogaIMO playback and buffering aren't individually incomprensible, they're just all mixed up
01:12:00Blue_DudeI thought about it. But the core of pcmbuf already works well. Using a linked list to feed chunks to the pcm without memcpy. Great stuff.
01:12:30seaniOops giant noob posting, apologies.
01:13:30Blue_DudeI'm not going to try untangling buffering and playback. Buffering is getting pretty modular already. It mostly only passes handles, which is a good sign.
01:13:44 Join saratoga_lab [0] (i=9803c264@gateway/web/freenode/x-2db58b11b6c9acde)
01:13:52seaniLlorean: and of course I've got no idea if those examples bear any relation to anyone using it for anything other than me, sometime.
01:14:38Lloreanseani: for seeking by timestamp an actual screen where you could input the timestamp might be best. :-P
01:14:50Blue_DudeJdGordon: It might be worth redoing playback from scratch. But you'd probably have to sacrifice features at first to get there.
01:15:15LloreanRockbox 4.0 Beta - new playback engine. :-P
01:15:17Blue_DudeJdGordon|: Sorry, I always forget the "|"
01:15:40JdGordon|Llorean: new playback engine.. take 2!
01:16:02JdGordon|Blue_Dude: that wouldnt worry me.. I dont use any of the features which woudl dissapear :)
01:16:18saratoga_laband we do have the old releases for people who need them
01:16:25LloreanIf it happened in a branch (at least until playback without those features was reliable on all currently supported targets) I don't think it'd be too bad.
01:16:27saratoga_labprobably wouldn't take too long for things to be reimplemented
01:16:44LloreanThen you could bring it over to the mainline kinda like they did with the new KDE "well, it will be better, but for now we gotta turn all this stuff off"
01:16:47saratoga_labif they're actually useful and you left a clean way to reimplement them
01:17:58Blue_DudeOne big problem I see right off the bat is that there are at least four ways of passing information to and from playback: global variables, arguments, queue posts and send events. Just untangling the dependencies is going to be tough.
01:18:17saratoga_labthe globals are great
01:18:23saratoga_labsome barely have comments
01:18:24seaniTsk, right between the shoulder blades. It isn't the code that gets you in here, it's the sarcasm.
01:19:03saratoga_labi just hate the way theres 100 playback features most people use but we often (but not always) have a considerable delay when changing tracks
01:19:16saratoga_labfor no apparent reason
01:19:16Blue_DudeGlobals are great, as long as you have tight control of scope and limit duplications.
01:19:21Lloreanseani: I do see it as possibly a better alternative for seeking to a "I know it by ear" location for the blind, possibly.
01:20:07JdGordon|Blue_Dude: globals are never great! globals are a nessecary evil!
01:20:10Blue_Dudesaratoga_lab: that's one of the first areas I'm going to address: the user interface has to get more responsive.
01:20:22JdGordon|playback especially should have no outward facing globals
01:20:45Blue_DudeJdGordon|: Well, they're "great, but..."
01:21:18JdGordon|file scoped globals I dont have much problem with, assuming the file is only one module :)
01:21:21Blue_DudeI just added one of those the other day. It's aimed at pcmbuf. :)
01:22:00seaniLlorean: Any way I cut it, I need to understand how patches and the build process hang together in more detail - new to me. Some RTFM'ing required.
01:22:56Blue_DudeI know it's a problem. That's one thing I'm addressing with all this restructuring. Globals have two big things going for them though: they're fast and they don't take up much memory.
01:23:15Unhelpfulseani: a patch is merely a machine-readable list of instructions to look for specific lines as context, and then remove and/or insert specific lines at that location.
01:23:27saratoga_labseani: we commit patches and then the build system compiles them all and tells us if anything went wrong
01:23:29saratoga_labif it goes wrong you fix it
01:23:51UnhelpfulBlue_Dude: none at all, if they're data that we already stored for local use ;)
01:24:09 Quit GeekShado_ ("The cake is a lie !")
01:24:21 Quit AndyI (Read error: 110 (Connection timed out))
01:24:38Blue_DudeUnhelpful: I meant in comparison to function calls. Variables do consume *something*.
01:24:45saratoga_labwell playback is one place i think we could spare a tiny bit of memory if it improves maintainability
01:24:59saratoga_labi'm all for complicated optimization in codecs and drivers since no one ever has to read those
01:25:21 Quit freddyb (Read error: 113 (No route to host))
01:25:32seaniUnhelpful: Ta chaps, the principle is fine but, for instance, if I generate a patch and then grab the updated source, can I reapply the patch to the fresh source reliably (and how)?
01:25:45Blue_Dudesaratoga: I'm freeing up enough RAM that we can afford arrays of globals and not miss it. I'm focusing on structural integrity more than RAM at the moment though.
01:26:24Unhelpfulseani: a better way is to keep the patch applied in your checkout (or a separate checkout in which you work). update will note conflicts and give you an opportunity to resolve them.
01:27:15JdGordon|Blue_Dude: I know it's a problem. That's one thing I'm addressing with all this restructuring. Globals have two big things going for them though: they're fast and they don't take up much memory <−−- yeah, but they make it harder to understand and much easier to add bugs
01:29:38Blue_DudeYeah, that makes them a huge liability. One possible fix is to never put externs in header files, only in the code body. That will at least flag you if you're doing something that conflicts.
01:30:35Blue_DudeOnly really common variables might be an exception. audiobuf comes to mind.
01:31:19seaniUnhelpful: Ok, so actively merge-on-get? I'll do a bit of a just-in-case copy and then some tests. SVN is also a new to me so I'm still feeling my way there. First a sandwich.
01:32:47Unhelpfulseani: if nobody has committed changes that touch the same things as your local work, there shouldn't be any conflicts. you should know, though, that non-conflicting changes can still cause breakage, such as if i change a definition of a structure that you use.
01:33:15Blue_Dudeseani: Sandwich? Ham, sharp cheese, chipotle, light mayo, hold the onions, peppers OK. To go please?
01:33:34saratoga_labon a side note, I badly want a way to script playback actions so that we can do unit testing of playback features in the build system
01:33:49saratoga_laband of course actually have a way to reproduce playback bugs
01:33:52Unhelpful"but i don't have any..." "what, brains?" "no, sandwiches" "well what good are you then?"
01:34:49Unhelpfulsaratoga: on target or in sim? rasher and i talked a bit about scripting sim input to drive automatic screenshot creation, but i'm not sure how far he got...
01:34:57saratoga_labthe sim
01:35:03 Quit MethoS- (Remote closed the connection)
01:35:21saratoga_labsomething that just allowed running playback at 10x realtime with the ability to queue files would be great
01:36:58rasherUnhelpful: I got pretty far, actually. With the patch in FS #10575 and the script from FS #10571 I managed to automatically generate almost all screenshots for the e200 manual
01:37:11saratoga_labwoah
01:37:14seaniUnhelpful: Thanks for the warning. I've written a fair amount of embedded C (EPOS and other custom hardware) but it was some time ago, and the tools etc. were very different. I think I remember the general gotchas, but the tools are unfamiliar
01:37:24rasherHm, FS #10571 doesn't look completely updated
01:38:15seaniUnhelpful: Also I don't remember quite as many people demanding sandwiches, but I admit I'm out of touch with cutting edge methodologies.
01:38:41Blue_Dudesaratoga_lab: That should be a fairly easy fix. Look on uisimulator/sdl/sound.c. Just create a build mode that doesn't send samples to the sound card and instead returns a success code at 10x speed.
01:42:42rasherUnhelpful: I managed to create a "START_PLUGIN" command, but the result was hilariously flaky
01:46:25 Join Strife89 [0] (n=michael@adsl-146-208-155.mcn.bellsouth.net)
01:46:58 Join pushnell [0] (n=p@24-177-121-33.dhcp.mdsn.wi.charter.com)
01:47:02Unhelpfulkugel: so the things you fixed were enums in global_settings?
01:49:48pushnellHey all. New user, just installed v1.2.3 on a 5thgen iPod Video. Everything is great except I cannot get the thing to shut off. Long Play does nothing. Tried resetting to rockbox_default theme. Any other suggestions?
01:50:06saratoga_lab1.2.3 is the installer version number, not rockbox
01:50:15 Quit Thundercloud (Remote closed the connection)
01:50:42pushnellHrm, thanks saratoga_lab. Looking to see what version I actually installed then.
01:50:59pushnellversion 3.4
01:53:51 Part toffe82
01:53:56 Join TopyMobile_ [0] (n=topy@171-196.79-83.cust.bluewin.ch)
01:54:03 Quit TopyMobile (Read error: 113 (No route to host))
01:57:57kugelUnhelpful: yea, both statusbar settings
01:58:58 Quit zu_ (Read error: 54 (Connection reset by peer))
01:59:11pushnellOk, just confirmed that the idle power off is not working either.
01:59:17Unhelpfulkugel, i changed those, and did a completely clean e200 build with explicit -fshort-enums, and no modifications to force single core. it *seems* to boot? :P
02:00
02:00:58pushnellIs there any sort of user error I could be performing to cause this?
02:01:53 Quit seani ("Leaving")
02:04:10pushnellOk, booting back into factory firmware lets me power it off just fine. I'd have to say this is a bug.
02:04:29LloreanThe factory firmware doesn't power off
02:04:38LloreanIt just switches off the screen, and goes into a low-power mode.
02:04:56Unhelpfulversion on target says it was built today, and i'm listening to a vorbis file. i'm pretty sure i haven't somehow screwed up and not installed this build...
02:05:27 Join MG_Man [0] (n=MGMan@97.101.208.11)
02:05:53pushnellLlorean: OK, I'm new to ipods and to rockbox so pardon my ignorance. Long Play on rockbox does nothing though.
02:06:57Unhelpfulpushnell: hold it longer? on at least a few targets i believe that power-off requires an even longer press than usual long-press options..
02:07:14LloreanOn the iPod especially, since the regular long press stops playback
02:07:25LloreanAlso, it can be a little sensitive, so try not to wiggle your finger
02:07:56UnhelpfulLlorean: ah, i didn't know that there was already a normal long-press action for that button :)
02:08:46LloreanUnhelpful: Yeah. The iPod is a bit short on buttons (I think second shortest of non-touchscreen, with Ondio taking the prize)
02:08:47Unhelpfulhahah, i hung rockbox in a very *odd* way... non-responsive to input, "scanning disk..." splash is present, and playback is running uninterrupted :)
02:09:11LloreanSo "Play/Pause" has "Play/Pause" on tap, "Stop" on long, and "Shut down" on very long.
02:09:19LloreanI think it's the only button with a very-long though
02:10:20pushnellOk, I tried holding Play for 60 seconds from the WPS, was paused & brought back to menu but nothing. Held for another 60 secs from the menu, nothing. Was careful not to wiggle, the menu did not select up or down during either 60 secs.
02:11:02Lloreanpushnell: And what version number or revision is your Rockbox?
02:11:04saratoga_labthe hardware reboot kicks in at 30 so either its broken or you're not doing it right
02:11:13pushnellversion 3.4
02:11:32pushnellWhatever it's supposed to do from factory firmware, it does.
02:11:42Lloreansaratoga_lab: On the iPod? I don't think there is a hardware anything for just holding play.
02:11:59 Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
02:12:18saratoga_labtheres a hard reboot IIRC, at least my 3G had one
02:12:19pushnellI just installed today from installer 1.2.3, System -> Rockbox Info shows version 3.4
02:12:28pushnellhard reboot is Menu + Select
02:12:38pushnell(for like 10 secs)
02:12:38Lloreansaratoga_lab: Hard reboot is menu+select isn't it?
02:12:41saratoga_labah ok was remembering wrong
02:13:21Lloreanpushnell: We haven't heard anyone else using 3.4 report something like this. Is there anything unique or different about your iPod that might make it nonstandard?
02:13:25pushnellHrm :/ ... I actually bought this ipod because I discovered rockbox (and thus accessibility to ogg/flac).
02:13:36pushnellNot that I know of. Like I say, this is my first ipod.
02:13:42pushnellAnything I can check?
02:14:02pushnellIt shows as 30Gb (27.xx) in Windows.
02:14:19saratoga_labi guess you could try a newer build then 3.4 and see if its any different
02:14:27LloreanThat'd be the first thing to try, yeah.
02:14:55pushnellOk. Would that be a "current" build?
02:15:28 Part JohnTeddy
02:15:43saratoga_labi think its the current build button in rbutil
02:17:46pushnellHrm, I see nothing that says indicates what build is about to be installed.
02:18:24pushnell"Complete Installation" gives a dialog saying 3.4 will be installed.
02:18:41 Join CaptainKwel [0] (n=jason@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com)
02:18:41saratoga_labthe install picture on the website shows a chose of builds
02:18:54saratoga_labso i guess try harder
02:19:31kugelUnhelpful: strange..
02:20:40Unhelpfulkugel: that branch is well behind svn, i'm updating now :)
02:20:46Lloreanpushnell: There should be an option for current build.
02:20:49pushnellAh, if you do a manual install it asks. About to install r23540
02:21:14Unhelpfulabout 300 revisions behind :)
02:21:20pushnellWould the bootloader have changed since 3.4?
02:21:52Unhelpfulif a current build breaks it, then i get to bisect and find the rev that broke it... at least that makes it easy to locate the bug. vorbis worked for me, mp3 crashed. :/
02:22:33Lloreanpushnell: The bootloader rarely changes, and even when it does we're likely to have you install the most recent one rather than its state at the time of the releaase.
02:23:31 Quit LambdaCalculus37 ("Brooklyn time")
02:25:31Unhelpfuldo we have a test files set for our various codecs? i'd like to get an idea what does and does not work...
02:25:51LloreanSomewhat
02:25:54LloreanI think it's incomplete.
02:26:20Lloreanhttp://download.rockbox.org/test_files/
02:26:21kugelUnhelpful: *clean* svn except for global settings change
02:26:25kugeldoes not boot here
02:27:30pushnellOk, getting the same behavior on r23540
02:27:32Unhelpful*how* clean? my branch only modifies rockboxdev.sh, configure, and settings.h...
02:28:51kugelthe asterisks were supposed to indicate "completely clean"
02:29:10kugelalso, I did rm -rf * in the build dir before
02:32:18 Join panni_ [0] (i=hannes@ip-95-222-21-143.unitymediagroup.de)
02:33:35kugelI seem to get behind lcd_init() which is after settings_reset() (going by some flackering of the screen=
02:33:37kugel)
02:35:49Unhelpfulwell, again, if we know that some specific previous rev boots...
02:36:21kugelwhat does your updated branch do ?
02:38:00Unhelpfuli was at r23238. all i've done is modify configure to use arm-elf-eabi for all arm targets, and never to use the long-calls option on them, and modify rockboxdev to build 4.4.1 and a snapshot binutils for arm. and i have a different patch locally, since that isn't pulled from the svn tree.
02:38:34Unhelpfulthe patch disables exception information for libgcc, and adds another multilib branching for it, with a short-enums and a long-enums version of libgcc available.
02:39:32Unhelpfulthat way i can build RB with all long or all short enums without any worries or warnings about libgcc objects built with different options.
02:39:44kugelthat doesn't sound very clean :P
02:40:49Unhelpfulmaybe, but i'm only actually changing one bit of source, and it boots. i'm running r23540 now.
02:41:24 Join aaron [0] (n=quassel@adsl-065-013-002-216.sip.asm.bellsouth.net)
02:41:27 Nick aaron is now known as aaron424 (n=quassel@adsl-065-013-002-216.sip.asm.bellsouth.net)
02:42:02Unhelpfulvorbis playback now fails for me, makes funny sounds for a bit and then stops. mp3 fails with prefetch abort.
02:42:24kugelrecompiled codecs?
02:42:44kugelstuff that touches linking sometimes require deleting everything
02:42:58Unhelpfuli built everything in an empty build dir and then did make install...
02:43:46Unhelpfulthe enum type in global_settings thing is a bug either way, and should make no difference *without* short enums. that one should just be committed, i think.
02:44:38kugelha!
02:44:47kugelI didn't have -mno-long-calls
02:44:59kugelthat was why I didn't get the 60k binsize savings too ;)
02:45:00Unhelpfuli don't either, i just don't have -mlong-calls. :P
02:45:06kugelnow it boots too, strangely
02:45:36Unhelpfulkugel: interesting, so the bulk of the binsize savings really *is* due to long calls?
02:45:37kugelI didn't change configure except for fuze. I always manually edited the Makefile
02:45:38Unhelpfulthat's kind of scary.
02:46:00kugelit's also scary that it doesn't boot with long calls
02:46:45Unhelpfulyes, i don't like that, either.
02:47:11Unhelpfulalthough the whole point of this was to be able to remove them. :)
02:47:13kugeleabi alone is -6k btw
02:47:44kugelmp3/ogg/m3a all work
02:48:35Unhelpfulthey work on fuze? odd.
02:48:46kugele200
02:48:56kugelfuze doesn't work at all, panics in the sd driver
02:50:23Unhelpfulall of those formats are complicated enough that my files my exercise very different code than yours. to "really" test mp3 or vorbis you probably need a dozen or so files each.
02:50:42kugeldid you delete the build dir?
02:51:00kugelI tell you, that solves codec problems very often
02:51:09Unhelpfulyes, a completely fresh build. :P
02:51:32Unhelpfuli'll try again, and clear out my ccache as well, although ccache should *not* be mixing these things up.
02:51:59kugeljust take a different build dir then you don't need to clear ccache
02:52:44Unhelpfuli was *already* using a different build dir.
02:52:52kugelhm
02:53:55 Join gtkspert_ [0] (n=gtkspert@124-169-51-119.dyn.iinet.net.au)
02:54:02Unhelpfuland ccache doesn't know about paths anyway, it's keyed on compiler options and preprocessed source, isn't it?
02:54:17kugelit's not intelligent
02:54:23kugelit really uses paths
02:57:12Unhelpful"ccache is a compiler cache. It acts as a caching pre-processor to C/C++ compilers, using the -E compiler switch and a hash to detect when a compilation can be satisfied from cache."
03:00
03:01:17 Quit MG_Man ("...GOT AWAY SAFELY!")
03:03:21 Quit aaron424 (Remote closed the connection)
03:06:01kugelUnhelpful: it doesn't even kick in for files with different paths
03:06:29kugelwhat you quoted is the assurance that the cached file is sufficient for the same file
03:06:42 Quit gtkspert (Read error: 101 (Network is unreachable))
03:09:07 Quit TopyMobile_ (Read error: 113 (No route to host))
03:10:21Unhelpfulkugel: per the man page the input and output file paths are not mentioned as being part of the cache key.
03:10:31***Saving seen data "./dancer.seen"
03:11:37kugelI don't know where it's stored, but it does in fact not work for different pathes
03:12:07kugelwe found that by observing the build system
03:13:12Unhelpfulhm? i thought that the problem with ccache and the build system was us using -D options to pass in version strings and the like, and using them for every file...
03:13:54kugelno, builds are much faster since we changed the build dir to be constant per target
03:16:02Unhelpfulhrm. that's very odd, i'm surprised that ccache doesn't know better than to strip -o <filename> before keying the command line.
03:17:13Unhelpfulanother rebuild, and i still can't play vorbis :/
03:18:57Unhelpfuli wonder if git bisect can bisect the branch *under* the local branch
03:20:57kugeli wonder why all codecs are a tad bit slower, except mp3 which is very slightly faster
03:21:59*kugel hopes for gcc 4.5
03:22:14Unhelpfulkugel: stubbed long calls are going to be slightly slower than direct long calls - everywhere that calls in or out of iram is now a short call to a stub that jumps to the long-call address, so it's an additional branch compared to a direct long call.
03:22:43kugelUnhelpful: nah, that's not the problem
03:23:03kugelI had roughly the same figures with non-eabi 4.4.1
03:24:13Unhelpfulalso it's a vastly different gcc, and in particular appears to have made rather different inlining decisions. objdiff notes a *very* large number of symbols unique to each binary when comparing the same source built with and without eabi - this is probably largely due to functions having been inlined entirely by each version.
03:27:38kugelUnhelpful: I don't there are much stubs
03:27:49kugelthe short call limit is 64MB isn't it?
03:28:14Unhelpfulkugel: i belive so. only calls into, or out of, iram should be stubbed.
03:28:29kugelif possible
03:28:41Unhelpfulcalls where caller and callee are both in, or both out of iram will be short
03:28:44 Join froggyman [0] (n=187b533e@giant.haxx.se)
03:28:50froggyman:Nick linuxis#1
03:29:13 Nick froggyman is now known as Guest68424 (n=187b533e@giant.haxx.se)
03:29:13kugelI don't know the memory layout of PP, but iram and dram could be far away with *nothing* in between (i.e. nothing where you can insert stubs)
03:30:23 Quit Guest68424 (Client Quit)
03:30:58kugelI think all other ARMs have an mmu and short calls already (I don't know about the tcc ones thoug)
03:31:12 Quit panni_ (Read error: 54 (Connection reset by peer))
03:32:02 Join webguest27 [0] (n=187b533e@giant.haxx.se)
03:32:26Unhelpfulkugel: i don't know what you mean by "in between" - stubs are inserted in the same section as the functions that need them.
03:32:35 Nick webguest27 is now known as froggyman (n=187b533e@giant.haxx.se)
03:32:41Unhelpfulthe stubs *do* use long calls, or rather long jumps.
03:33:49saratoga_labunless the changes are dramatic its probably not worth worrying about
03:33:52kugelwhat's the advantage over real long calls there?
03:34:05saratoga_labwe can force or disable inlining and move things around in iram
03:34:26saratoga_labjumping to a stub is smaller then having long jumps everywhere
03:34:50kugelsaratoga_lab: flag losses nearly 20%, the other codecs <3%
03:35:39saratoga_labthats surprising but probably just something simple that can be fixed
03:36:04kugelsaratoga: but if you can access the stub only via long call, nothing is gained
03:36:27saratoga_labstubs are always in the same section though
03:36:42 Nick froggyman is now known as Msg (n=187b533e@giant.haxx.se)
03:36:45 Quit Msg (Client Quit)
03:36:51saratoga_labthats basically the idea as I understand it, just make little stub functions in each section in order to avoid long calls
03:37:03kugelbut that's not possible sometimes
03:37:45Unhelpfulkugel: a long-call stub costs 8B. a short call costs 4B. an inline long call costs 4B for the jump and 4B for the address - the target address is generally stored once by gcc per function using it, after the body of the function.
03:39:00kugelah so you the stub saves the 4B for saving the address repeatedly, but still does the long call?
03:39:08Unhelpfuland our memory layouts, even on targets using long calls without eabi, all have sections small enough that an address within the section can always be a short call.
03:39:39kugel(for calls that are too far away I mean=
03:39:42kugel)
03:39:44Unhelpfulkugel: yes and no. with -mlong-calls, gcc makes any call outside the current module a long call
03:40:08kugelI know what -mlong-call does
03:40:27Unhelpfulkugel: well, a lot of those can be direct short calls that don't use the stub.
03:40:51kugelI'm only talking about calls where a simple short call isn't possible at the moment
03:40:56Unhelpfulfor many functions, there are never any calls that would be out of range, and no stub is generated.
03:41:08kugelI got the fact that calls within the same sections are always short calls
03:41:40*kugel wonders why Unhelpful is answering questions that hasn't been asked :p
03:42:01Unhelpfulkugel: "where a simple short call isn't possible"?
03:42:24kugelif caller and callee are too far away
03:42:29Unhelpfulgcc generates asm instructions to do a short call to some function, by label/symbol
03:43:32Unhelpfulit's *always* a short call. *if* some call is found to be too far away at link time, the linker generates __<name>_veneer with a long jump to the true target address, and makes the short call go to the veneer function instead of the true target.
03:44:05kugeland what's the gain over a long call in the first place?
03:44:45Unhelpfulkugel: about 63KB total? ;)
03:45:31Unhelpfulthe gain is that we're not saving the target address for each function that calls it: 4B per target address per calling function. also , direct short calls are now possible between code in different source files.
03:46:43kugelis it possible to do long calls for calls into other sections, and short calls for calls within the same section/memory limit? or isn't that doable with the separate compiler and linker architecture?
03:47:53 Join [TiZ] [0] (n=trent@74-136-64-242.dhcp.insightbb.com)
03:48:35 Join TopyMobile [0] (n=topy@171-196.79-83.cust.bluewin.ch)
03:49:32Unhelpfulactually, i'm wrong about the savings per "actual" long call, it's larger, as long calls are done as <load address>, <branch to register>, so there's an extra 4B per *call* as well as the 4B used to store the address
03:50:06Unhelpfulthis is also why the linker can't just fit in direct long calls, they're more and different instructions than a short call
03:50:25[TiZ]Hi. I've got this weird redrawing error in my theme. It can be seen here: http://i.imagehost.org/download/0321/dump_091105-214212 There's supposed to be a new window around the song info, but instead only parts are replaced, and I can see the border of the menu window. (just two different backdrops.) The source .wps is at http://pastebin.com/m1dd11650 and for good measure, the sbs is at http://pastebin.com/m4cb70f22. How do I fix this?
03:51:53Unhelpfullong calls are ldr <reg> [pc, offset] ; mov lr, pc; bx <reg>. short calls are bl <offset>
03:53:39Unhelpfulthe linker can't change the assembly at link time, only the target offset or address. so the compiler has to decide whether to use a long or a short call, based on options passed and the heuristic with -mlong-calls of long calls unless the callee is in the same source module *and* section as the caller.
03:54:41kugelok, so you can only do all-or-nothing
03:56:00kugelso a long call is 12bytes in total?
03:56:35Unhelpful12B of instructions, and 4B to save the target address
03:56:53 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net)
03:56:57kugelerr, I meant 16
03:57:47kugelanyway, I wonder how to fix the fuze
03:57:57kugelI don't think we can enable eabi per target?
03:58:17Unhelpfulwell, the address is saved only once for each long call that a function might make. so if it has several places from which it might make long calls to the same function, it costs 4B for the address, and 12B per call.
03:58:46Unhelpfulkugel: sure we can, as long as we require that both eabi and non-eabi compilers be available. ;)
04:00
04:01:37Unhelpfulsome targets can build using arm-elf-foo, some using arm-elf-eabi-foo
04:01:55Unhelpfuldoes fuze work with a "normal" gcc-4.4.1?
04:02:18kugeli didnt test
04:02:57Unhelpfulyour fuze problems might not be eabi problems...
04:04:45 Quit kugel (Remote closed the connection)
04:05:59 Join freddyb [0] (n=fred@pool-70-104-101-195.chi.dsl-w.verizon.net)
04:08:25 Quit Rondom (Nick collision from services.)
04:08:35 Join Rondom [0] (n=Rondom@dslb-084-057-136-177.pools.arcor-ip.net)
04:13:51 Quit CaptainKwel (Remote closed the connection)
04:18:44 Quit Strife89 ("Bed.")
04:19:09 Quit Rob2222 ()
04:20:51 Quit TheSeven (Nick collision from services.)
04:21:00 Join Rob2222 [0] (n=Miranda@p4FDCCD6C.dip.t-dialin.net)
04:21:09 Join The_Seven [0] (n=theseven@rockbox/developer/TheSeven)
04:21:21 Nick The_Seven is now known as TheSeven (n=theseven@rockbox/developer/TheSeven)
04:25:03Unhelpfulsaratoga: am i right in thinking here that using a stub *slightly* mitigates the cost of the extra branch because the short call to the stub can use branch-and-link where the inline long call would've required an explicit mov lr, pc?
04:25:35Unhelpfulso that it amounts to a cost of one extra branch, minus one mov?
04:27:33 Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net)
04:43:05saratoga_labUnhelpful: i'm not really sure how this works
04:43:26saratoga_labbut branch instructions are probably pretty cheap compared saving the registers, at least on ARMv4
04:49:29 Quit AaronM ("Emo Time In My Corner... //_-")
05:00
05:04:38 Part froggyman
05:06:38 Quit BlakeJohnson86 (Read error: 110 (Connection timed out))
05:08:49 Quit [TiZ] ("Leaving")
05:09:37 Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net)
05:10:24 Quit adiroiban (Read error: 110 (Connection timed out))
05:10:33***Saving seen data "./dancer.seen"
05:13:38CIA-8New commit by 03blue_dude (r23541): pcmbuf: sorted functions into logical sections for readability. Tiny changes, nothing functional
05:19:12saratoga_labwoot!
05:20:14Blue_DudeThat's just cut and paste. It's not even a real change yet. I wanted a baseline though.
05:21:15Blue_Dudehmph.
05:21:47Blue_Dudeah ok, needs ifdef's for function prototypes. got it
05:21:52Unhelpfulsaratoga: expensive, i would think? i believe mov on arm is one cycle if the destination is not pc...
05:23:12Unhelpfuli wonder if it would be worthwhile to find some way to sort the _veneer functions all together and cache-align the first one, so that a cacheline can be loaded and guaranteed to contain a bunch of the veneers.
05:25:29CIA-8New commit by 03blue_dude (r23542): pcmbuf: need ifdef to fix yellow
05:26:06 Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.5.4/20091016092926]")
05:36:20 Nick FlynDice_ is now known as FlynDice (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net)
05:40:58saratoga_labUnhelpful: branches are one or two cycles of stall on such shallow pipelines, while storing registers is one clock per reg plus the overhead for moving them
05:41:22 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey)
05:43:16 Quit TopyMobile (Read error: 113 (No route to host))
05:44:42 Quit Horscht ("Verlassend")
05:47:11Unhelpfulsaratoga: there's overhead on a register-to-register move? it's not a store-to-memory.
06:00
06:00:38saratoga_labUnhelpful: doesn't it have to push some of the current registers onto the stack to make room for the function arguments?
06:03:13Unhelpfulsaratoga: it has to do that in either case. the savings i'm talking about is that it performs a short call to the veneer, using branch-and-link, as opposed to a long call, which has to do the link step explicitly (mov lr, pc). the veneer then does a load-to-pc to jump to the real target, so the veneer doesn't worry about register saving or argument setup, the caller does that exactly as it would have for a "real" short call.
06:06:04FlynDicefunman:(logs) I'm trying to understand UNALIGNED_NUM_SECTORS 10 in ata_sd_as3525.c and having a hard time figuring out why you used 10 here. Is this an alignment thing or buffer size thing or something else I don't quite understand yet?
06:09:05Unhelpfulshould os_exit in the lua plugin be labeled as non-returning and made void? it pretty clearly doesn't return a value, and this causes it to throw a warning on gcc4.4 :)
06:39:09 Quit maraz (Read error: 60 (Operation timed out))
06:45:08 Join gtkspert [0] (n=gtkspert@124-169-207-177.dyn.iinet.net.au)
06:55:06 Quit gtkspert_ (Read error: 101 (Network is unreachable))
06:56:08 Quit reid02 (Connection timed out)
06:56:19 Join reid02 [0] (n=reid85@CPE001cdf73661f-CM001ceacec55e.cpe.net.cable.rogers.com)
07:00
07:07:21 Quit liar (Read error: 148 (No route to host))
07:08:54 Quit BHSPitLappy (Remote closed the connection)
07:10:35***Saving seen data "./dancer.seen"
07:16:19 Join maraz [0] (i=maraz@xob.kapsi.fi)
07:17:03 Quit n1s (Read error: 110 (Connection timed out))
07:18:07 Join n1s [0] (n=n1s@rockbox/developer/n1s)
07:25:29 Join Dhraakellian [0] (n=ntryon@cpe-72-226-197-191.rochester.res.rr.com)
07:31:52 Quit phanboy4 (Read error: 54 (Connection reset by peer))
07:31:59 Quit bluebrother (Nick collision from services.)
07:32:01 Join bluebroth3r [0] (n=dom@rockbox/developer/bluebrother)
07:36:56 Quit freddyb (Read error: 60 (Operation timed out))
07:40:09 Quit dmb (Read error: 54 (Connection reset by peer))
07:40:54 Join dmb [0] (n=Dmb@unaffiliated/dmb)
07:55:59 Quit JdGordon ("Leaving.")
08:00
08:13:20 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon)
08:22:10Unhelpfulamiconn: if you haven't seen, kugel spotted a problem with an enum in global_settings. fixing that got us a working rockbox on e200, but vorbis stopped working for me when i updated my eabi branch, which had been at r23238. bisect got me to r23455, and reverting settings.h from that build and rebuilding the vorbis codec produces a working vorbis codec again :/
08:23:52Unhelpfulalso, kugel found out that he was still building with -mlong-calls. his build wouldn't boot on e200, removing the option got it working. it concerns me a bit that that should break anything. :/
08:26:34Unhelpfuland then he was suddenly able to reproduce my binsize deltas. gcc-4.4.1 and eabi produce a small delta even without changing long calls, but he was nowhere near the -63KB i was seeing
08:27:12saratoga_labi notice the real networks people have some benchmark data for their open source (but not GPL) MP3 and AAC decoders running on ARM7TDMI and ARM9TDMI, and their results are quite impressive
08:27:29saratoga_labwe can't use their code, but knowing what algorithms they use might be very interesting
08:29:35 Join ender` [0] (i=krneki@foo.eternallybored.org)
08:40:17 Join B4gder [0] (n=dast@giant.haxx.se)
08:45:59 Join swilde [0] (n=wilde@aktaia.intevation.org)
08:51:25 Join maruk [0] (n=papier@titanium.sdv.fr)
08:55:01 Join petur [50] (n=petur@rockbox/developer/petur)
08:55:03 Quit JdGordon ("Leaving.")
08:55:46 Join Rob2223 [0] (n=Miranda@p4FDCC8BE.dip.t-dialin.net)
08:57:01 Join flydutch [0] (n=flydutch@host248-201-dynamic.15-87-r.retail.telecomitalia.it)
08:58:01 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon)
09:00
09:04:56 Join pamaury [0] (n=pamaury@140.77.26.171)
09:05:45 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net)
09:09:12 Join phanboy4 [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net)
09:09:29 Join pyro_maniac [0] (i=foobar@p57BB93CE.dip0.t-ipconnect.de)
09:10:39***Saving seen data "./dancer.seen"
09:11:35 Quit saratoga_lab ("Page closed")
09:12:47 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk)
09:13:19 Quit Rob2222 (Read error: 110 (Connection timed out))
09:15:44 Quit pyro_maniac (Read error: 131 (Connection reset by peer))
09:16:30 Join Zagor [242] (n=bjorn@rockbox/developer/Zagor)
09:18:18 Quit JdGordon (Read error: 60 (Operation timed out))
09:20:08 Quit pamaury (Remote closed the connection)
09:20:57 Join pamaury [0] (n=pamaury@140.77.26.171)
09:23:17 Quit scorche (Nick collision from services.)
09:24:03 Join scorche [50] (n=scorche@rockbox/administrator/scorche)
09:30:18 Part B4gder
09:30:53 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de)
09:42:23Unhelpfulamiconn: iramcopy is supposed to have a 16-byte-aligned load address, right? i think we've seen this bug before, when i tried with the binutils 2.19 snapshots, though i'm not really sure how it's being *triggered* now.
09:43:41 Quit StealthyXIIGer (Read error: 60 (Operation timed out))
09:45:16 Join LinusN [0] (n=linus@rockbox/developer/LinusN)
09:57:03Unhelpfulthat gcc is compiling some functions differently when a struct they don't use is changed is a bit odd, but i think the reason the codec fails is due to a -2-byte offset introduced in the load address: http://www.pastie.org/686145
09:57:28Unhelpfulthere's a similar offset in the mp3 codec, probably why it crashes.
09:57:28 Quit shai ("Leaving")
09:57:57 Quit Thundercloud (Remote closed the connection)
10:00
10:00:02 Quit fyrestorm ("Ur skills' fireproof like a wooden panel -- U got feds talking leet on your IRC channel!")
10:08:30 Join B4gder [0] (n=dast@giant.haxx.se)
10:10:34 Join seani [0] (n=seani@78.33.109.70)
10:12:36 Join zu [0] (n=zu@bucketheaded.eu)
10:12:47 Quit reid02 (Read error: 110 (Connection timed out))
10:13:06 Join reid02 [0] (n=reid85@CPE001cdf73661f-CM001ceacec55e.cpe.net.cable.rogers.com)
10:24:53 Quit n1s (Read error: 110 (Connection timed out))
10:40:10amiconnUnhelpful: iramcopy doesn't need to be aligned to more than 4 bytes (iirc we're doing word copy)
10:40:54*amiconn isn't sure what this .map paste is supposed to tell him
10:43:51Unhelpful.iram is AT(iramcopy) in the linker script - shouldn't the load address equal the address for iramcopy? i see "0x01e97250 iramcopy = (. - 0x10000000)
10:44:04Unhelpfuland then ".iram 0x4000c000 0x42b8 load address 0x01e97248
10:44:12Unhelpfulgrr, stupid copying newlines :/
10:44:19amiconnHmm, that's a codec .map, and codec_crt0.c uses memcpy(), so alignment is unimportant
10:45:30amiconnThe +/- 0x10000000 is correct. It comes from the nocachebss section right before .iram
10:47:06Unhelpfulbut shouldn't .iram's load address = iramcopy?
10:47:32amiconnIt is...
10:48:19Unhelpfulthen i'm a bit confused about the map file, because i see two different addresses...
10:48:30amiconniramcopy is at 0x01e97248
10:48:44amiconnThis is the also the load address
10:48:51amiconns/also//
10:48:57Unhelpfuldoesn't 0x01e97250 iramcopy = (. - 0x10000000)
10:49:20amiconnEh, wait
10:49:27amiconnThere's an offset of 0x8
10:49:29Unhelpfulgrr. doesn't "0x01e97250 iramcopy = (. - 0x10000000)" indicated iramcopy = 0x01e97250 ?
10:50:02Unhelpfuli can't seem to copy from pastie without picking up the newline, and quassel sends on a pasted newline :/
10:50:48 Quit phanboy4 (Read error: 110 (Connection timed out))
10:52:18*amiconn wonders what the linker is doing there
10:52:30Unhelpfulamiconn: yes. we saw that offset the *last* time i tried to get eabi and long-call veneers working, it happens with newer binutils when linking eabi objects. if you shuffle padding around in the linker script you can get it to disappear, or you can add padding to any section before .ncdata, and depending on the magic alignment you hit, it *might* disappear.
10:52:44*Unhelpful wonders if this happens if .ncdata is not empty...
10:54:44 Join DerPapst [0] (n=DerPapst@79.232.244.25)
11:00
11:10:43***Saving seen data "./dancer.seen"
11:37:05 Join MethoS- [0] (n=clemens@134.102.106.250)
11:39:15Unhelpfulamiconn: hrm, the offset seems to disappear if i calculate iramcopy as (. - 0x10000000 + 0xf) & 0xffffff0
11:41:46 Join webguest24 [0] (n=45048e54@giant.haxx.se)
11:42:31 Quit webguest24 (Client Quit)
11:48:15 Join TopyMobile [0] (n=topy@171-196.79-83.cust.bluewin.ch)
11:50:18 Quit MethoS- (Remote closed the connection)
11:53:38 Quit pamaury ("exit(*(int *)0 / 0);")
12:00
12:12:32 Join shai [0] (n=Shai@l192-117-110-233.cable.actcom.net.il)
12:14:42 Join funman [0] (n=fun@rockbox/developer/funman)
12:24:24 Join adiroiban [0] (n=adiroiba@h194-54-129-79.teleson.ro)
12:32:51 Join teru [0] (n=teru@KD059133112132.ppp.dion.ne.jp)
12:33:11 Quit CIA-8 (lindbohm.freenode.net irc.freenode.net)
12:33:11NSplitlindbohm.freenode.net irc.freenode.net
12:33:11 Quit Torne (lindbohm.freenode.net irc.freenode.net)
12:34:25 Join Torne [0] (i=torne@lowell.wolfpuppy.org.uk)
12:35:42 Join CIA-15 [0] (n=CIA@208.69.182.149)
12:36:40 Join AaronM [0] (n=Aaron@adsl-4-241-157.mem.bellsouth.net)
12:36:43Unhelpfulhrm, or given that no codec or plugin seems to place anything in .ncdata, that section could just disappear from plugin.lds...
12:37:59funmanUnhelpful: true
12:39:54Unhelpfuli wonder if that will kill the offset bug, too...
12:40:53funmanoffset bug ? I don't think removing an empty section would have any effect
12:41:41Unhelpfulfunman: look up a bit to my discussion w/ amiconn regarding very funny goings-on with newer binutils ;)
12:42:39Unhelpfulbasically the . = ALIGN(16) inside the empty .ncdata was affecting some addresses but not others, so that in some cases the load address for .iram didn't actually equal iramcopy :/
12:42:55funmanI see
12:44:11Unhelpfulno idea why. it's happening with newer binutils since 2.19 snapshots or so. :/
12:45:12Unhelpfulespecially weird since .iram is AT (iramcopy) - how can it calculate a value for iramcopy and then use a different one for the load address? seems like it has to be a bug.
12:45:48funmandid you check the .elf file?
12:47:21Unhelpfulnot very closely, i looked at the address for iramcopy and the .iram load address in the .map files.
12:48:59funmanI wonder how helpful the binutils developers would be to help debug this :/
12:49:22Unhelpfuli compared disassemblies between the revisions where vorbis stopped working for me, and noted that some addresses were different, but not much else.
12:49:54Unhelpfuli posted a bug when i encountered this with 2.19 snapshots. i've never been able to get things down to a *simple* test case, though. :/
12:51:38Unhelpfulyay, vorbis no longer skips tracks, and mp3 no longer crashes. :)
12:55:57Unhelpfulhrm, fuze is single-core, so it defines an empty NOCACHEDATA_ATTR and SHAREDDATA_ATTR, right? so it has an empty .ncdata for the core app... i wonder if kugel's crash on booting eabi fuze builds is the same as my codec problems.
12:57:28amiconnUnhelpful: ALIGN (0x10)
12:57:28funmanUnhelpful: there's no .ncdata in fuze core app
12:57:39amiconn..is supposed to do exactly that
12:57:44amiconnSounds like a linker bug
12:59:57 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com)
13:00
13:05:48amiconnUnhelpful: Maybe it doesn't like the mix of calculation within output sections and outside them?
13:06:46amiconnThe alignment happens inside .ncdata, but the calculation of iramcopy happens outside
13:07:16funmanthe problem is only here when .ncdata is empty ?
13:09:06amiconnUnhelpful: What happens if you pull the second . = ALIGN(CACHEALIGN_SIZE);
13:09:29amiconn...outside the output section (but keep it inside the #ifdef)?
13:09:46amiconn@hrmphs at pastie copying
13:10:32 Quit DerPapst ("Leaving.")
13:10:45***Saving seen data "./dancer.seen"
13:14:09 Join gitster` [0] (n=user@68.225.240.211)
13:14:15NHeal(timeout) lindbohm.freenode.net irc.freenode.net
13:29:12 Quit gitster (Read error: 110 (Connection timed out))
13:34:17 Join Scotty1975 [0] (n=520b9334@giant.haxx.se)
13:36:38Unhelpfulfunman: i don't know, i just know that it is for codecs and plugins.
13:37:17 Quit Scotty1975 (Client Quit)
13:37:21 Join Scotty1975 [0] (n=520b9334@giant.haxx.se)
13:38:13Unhelpfulamiconn: couldn't we just assign iramcopy=. before .ncdata? and i'm sure it *is* a linker bug, but until i can create a *small* test case that doesn't require rockbox, i'm not sure if there will be much help :/
13:38:44Scotty1975Hi, can anyone tell me if Rockbox can be used to update a SONY NW-S202 512Mb DMP?
13:38:58B4gderScotty1975: see rockbox.org (no it can't)
13:39:50Scotty1975Without reading that, can u say why? :{
13:40:03B4gdersure, because nobody did the necessary work
13:40:09Scotty1975lol
13:40:16amiconnUnhelpful: Obviously not, as it needs to come after that section...
13:40:20Scotty1975will they in future?
13:40:24B4gderScotty1975: they?
13:40:31B4gdersony?
13:40:31UnhelpfulScotty1975: if somebody does the necessary work. ;)
13:40:58Scotty1975cool, cheers
13:41:23Scotty1975goddam slackers @ SONY :{
13:41:32Unhelpfulamiconn: "after"? but isn't its address before it (- NOCACHDATA_SIZE or whatever)?
13:41:48amiconnNo it's not
13:41:50UnhelpfulScotty1975: somebody who owns one has to work on it. :)
13:42:06Scotty1975I would if I knew anything about coding
13:42:08amiconnNOCACHEDATA_SIZE is 0x10000000, i.e. the offset
13:42:19B4gderScotty1975: a new rockbox port is a lot of work for a long time
13:42:51amiconnBut if .ncdata is not empty, the iramcopy needs to come after that (or more precisely, after its "mirror" in the cached area)
13:43:13Scotty1975ok guys, maybe I'll just buy a DMP that already has support then
13:43:28B4gderthat's way easier, yes ;-)
13:43:53Scotty1975l8erz :{}
13:44:07UnhelpfulB4gder: with the availability problems, are you sure that 'easier' is the word you want to use? ;)
13:44:11 Quit Scotty1975 ("CGI:IRC")
13:44:37B4gderI'm sure hunting down an already supported player still is easier than doing a new port
13:44:52B4gderif a bit different
13:46:04 Quit antil33t ()
13:52:20 Join dfkt [0] (i=dfkt@unaffiliated/dfkt)
13:53:05CIA-15New commit by 03teru (r23543): Merge duplicating code to move cursor left/right. ...
13:54:34 Join polobricolo [0] (i=5243467c@gateway/web/freenode/x-b62899126a6f5cab)
13:55:50 Join antil33t [0] (n=Mudkips@122-57-252-164.jetstream.xtra.co.nz)
13:58:54 Quit pushnell (Read error: 54 (Connection reset by peer))
13:59:00 Join pushnell [0] (n=p@24-177-121-33.dhcp.mdsn.wi.charter.com)
13:59:34 Join Omlet [0] (i=omlet05@169.158-241-81.adsl-dyn.isp.belgacom.be)
13:59:42 Join Omlet05 [0] (i=omlet05@81.241.158.169)
14:00
14:04:11 Join |DaMaGeD| [0] (n=|DaMaGeD@83.149.19.106)
14:06:33|DaMaGeD|hmm.is SVN ver of onplay.c compiles good?
14:07:08Unhelpfulamiconn: i think i understand... and kugel's fuze problem is something else, unless there's another way to trigger this. do you want me to look for a "better" workaround than removing .ncdata from plugin.lds?
14:08:16amiconnRemoving it would be a bad idea. The fact that it isn't used currently doesn't mean it won't be used in the future
14:08:28amiconnI already made a suggestion, did you try that?
14:11:24Unhelpfuli'll have to try that later. ;)
14:16:46 Quit zu (Remote closed the connection)
14:18:28 Join zu [0] (n=zu@88.191.93.109)
14:19:28 Quit funman ("free(random());")
14:25:11 Part B4gder
14:33:21 Quit Omlet (Client Quit)
14:33:21 Quit Omlet05 (Client Quit)
14:41:21 Quit polobricolo ("Page closed")
14:41:30 Join amiconn_ [0] (i=jens@rockbox/developer/amiconn)
14:42:16 Join jon-kha [0] (i=jon-kha@83.150.91.127)
14:42:29 Quit amiconn_ (Client Quit)
14:59:44 Quit |DaMaGeD| (Read error: 145 (Connection timed out))
15:00
15:03:42 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky)
15:07:10 Join martian67 [0] (n=lol3@about/linux/regular/martian67)
15:10:48***Saving seen data "./dancer.seen"
15:21:29 Quit teru ("Quit")
15:24:23 Quit TopyMobile (Read error: 113 (No route to host))
15:29:09 Join aaron [0] (n=quassel@adsl-065-013-002-216.sip.asm.bellsouth.net)
15:29:43 Nick aaron is now known as aaron424 (n=quassel@adsl-065-013-002-216.sip.asm.bellsouth.net)
15:29:46 Quit martian67 ()
15:30:58 Join martian67 [0] (n=lol3@about/linux/regular/martian67)
15:34:14 Join freddyb [0] (n=fred@pool-70-104-101-195.chi.dsl-w.verizon.net)
15:38:07 Join liar [0] (n=liar@83.175.83.185)
15:47:05 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net)
15:51:53 Join TopyMobile [0] (n=topy@171-196.79-83.cust.bluewin.ch)
15:53:51 Part LinusN
15:56:49 Join evilnick_B [0] (i=0c140464@rockbox/staff/evilnick)
16:00
16:01:03 Join froggyman [0] (n=187b533e@giant.haxx.se)
16:01:22 Quit AEnima1577 ("Leaving.")
16:03:24 Join n1s [0] (n=n1s@rockbox/developer/n1s)
16:15:22 Join polobricolo [0] (n=polobric@AGrenoble-257-1-56-80.w86-206.abo.wanadoo.fr)
16:16:15 Quit niekie (Remote closed the connection)
16:16:31 Join barrywardell [0] (n=barrywar@rockbox/developer/barrywardell)
16:26:37 Join michse [0] (n=hebz0rl@dslb-088-067-213-031.pools.arcor-ip.net)
16:28:45 Quit michse (Client Quit)
16:28:57 Quit pixelma (Read error: 131 (Connection reset by peer))
16:28:57 Quit amiconn (Read error: 104 (Connection reset by peer))
16:29:09 Join Lss [0] (n=Lss@cm46.delta91.maxonline.com.sg)
16:29:17 Join pixelma [0] (i=quassel@rockbox/staff/pixelma)
16:29:26 Join amiconn [0] (i=quassel@rockbox/developer/amiconn)
16:30:56 Quit Zagor ("Don't panic")
16:32:11 Join MethoS- [0] (n=clemens@134.102.106.250)
16:36:19 Join jgarvey [0] (n=jgarvey@174.97.130.131)
16:37:08 Quit froggyman ("CGI:IRC")
16:40:38 Join niekie [0] (i=quasselc@dreamworld.bergnetworks.com)
16:41:46 Join funman [0] (n=fun@rockbox/developer/funman)
16:43:37 Join toffe82 [0] (n=chatzill@12.169.218.14)
16:54:27 Join craig` [0] (n=user@71-218-118-143.hlrn.qwest.net)
17:00
17:00:32 Quit petur ("beer time")
17:05:10FlynDicefunman: ping
17:05:25funmanpong
17:05:51FlynDiceHi, Im trying to figure out UNALIGNED_NUM_SECTORS 10 in ata_sd_as3525.c.
17:05:56 Quit freddyb (Read error: 60 (Operation timed out))
17:06:14FlynDiceIs ththat number arrived at for a reason?
17:06:21FlynDicethe 10 I mean...
17:06:51funman"a bit but not too much"
17:07:17funmannow i've seen mentioned here that a lot of code would only transfer 1 sector at a time
17:07:28funman(not including test_disk)
17:07:48FlynDiceI've found that by increasing it the copy times fom disk to disk are cut by almost 50 %
17:07:49funmanit should not be too big to not eat too much bin size
17:08:13funmaniirc i had make tests with different values (using test_disk) but i'm not sure anymore
17:08:22 Quit Hadaka (lindbohm.freenode.net irc.freenode.net)
17:08:22NSplitlindbohm.freenode.net irc.freenode.net
17:08:22 Quit shaggy-h (lindbohm.freenode.net irc.freenode.net)
17:08:22 Quit jasio (lindbohm.freenode.net irc.freenode.net)
17:08:22 Quit jordan` (lindbohm.freenode.net irc.freenode.net)
17:08:23 Join Naked [0] (n=naked@naked.iki.fi)
17:08:29 Join jordan`` [0] (n=jordan@78.235.252.137)
17:08:31FlynDicewould the increased buffer size impact the clip?
17:08:34 Quit preglow (lindbohm.freenode.net irc.freenode.net)
17:08:39 Nick Naked is now known as Hadaka (n=naked@naked.iki.fi)
17:08:39polobricoloin thread.c, where are r0, r1 and r2 stored
17:08:52 Join preglow [0] (i=thomj@129.241.210.199)
17:08:57funmanit would impact every model
17:09:03funmanthe Clip is already broken anyway so
17:09:06 Quit CIA-15 (lindbohm.freenode.net irc.freenode.net)
17:09:06 Quit SUSaiyan (lindbohm.freenode.net irc.freenode.net)
17:09:06 Quit lyngaas (lindbohm.freenode.net irc.freenode.net)
17:09:11NHeallindbohm.freenode.net irc.freenode.net
17:09:11NJoinSUSaiyan [0] (n=SUSaiyan@cc84863-b.zwoll1.ov.home.nl)
17:09:12polobricolothe reg struct contains only r4-r11 sp or lr
17:09:22polobricolo*and lr
17:09:43 Join CIA-6 [0] (n=CIA@208.69.182.149)
17:10:38Bob_C_FlynDice: What size did you increase it to?
17:10:49***Saving seen data "./dancer.seen"
17:10:55funmanpolobricolo: it seems all the scratch registers (r0-r3, r12) aren't stored but i'm not sure why
17:10:58n1spolobricolo: giving more context or lines in the file might help people know what you are looking for
17:11:03FlynDicewell I tried all the way up to 127...
17:11:09n1ss/for/at/
17:11:47 Quit funman ("free(random());")
17:11:51FlynDiceBob_C_: at 127 it took half the time to copy from 1 disk to the other
17:13:25FlynDiceI found something in a sandisk manual that addressed using at least 64 when writing to optimize the way the cards erase before a write
17:13:35NJoinjasio [0] (n=yann@cpc2-rdng20-2-0-cust902.15-3.cable.virginmedia.com)
17:14:35Bob_C_Larger transfers will give better throughput, the question is whether the extra memory used could be better used for something else
17:15:15FlynDiceI also tried the pre-erase command that the sd spec reccommends before a SD_WRITE_MULTIPLE_BLOCK but the results were about the same...
17:15:55FlynDiceBob_C_: Yes, that's why I'm asking...
17:16:39domonokyBob_C_: does the pcm driver for mini2440 use DMA, and if yes which channel ? (it looks like it does, but it doesnt use the dma-s3c2440 functions)
17:17:17Bob_C_Sure, I understand. I am interested because I borrowed most of the code from the as2525 SD driver for the mini2440
17:18:19Bob_C_domonoky: it uses DMA, but the "legacy" routines from the Gigabeat F. Ideally it would be rewritten to use the more generic interface
17:19:25NJoinlyngaas [0] (n=staale@19.81-167-149.customer.lyse.net)
17:19:26domonokyah ok, do you know which dma channel this uses ?
17:19:39n1sgevaerts: iirc you have a private build system for rockbox, or at least a setup to build all targets and a mcahine fast enough to make it feasible?
17:20:24gevaertsn1s: I have a machine that can do all normal builds in slightly more than half an hour, yes
17:20:36gevaerts(access to)
17:20:45n1sno sims?
17:20:55Bob_C_domonoky: I believe dma-target.h has that, but the channels are hard-coded in places
17:21:13gevaertsn1s: it does all builds, but I don't know how long sims take
17:21:48n1sgevaerts: would you test build the sims with a patch i've made?
17:22:00gevaertssure
17:22:24Bob_C_domonoky: pcm should use channel 2 in both gigabeat/mini2440 I think
17:22:41n1sgreat :)
17:23:01domonokyoki, so channel 3 and 4 are free at moment. :-)
17:23:20Bob_C_domonoky: or 1 and 3?
17:24:14 Quit aaron424 (Remote closed the connection)
17:24:28domonokyBob_C_: you are right
17:25:07 Quit TopyMobile (Read error: 60 (Operation timed out))
17:25:23Bob_C_domonoky: what is your plan?
17:26:32domonokythinking about usb support. will see how far i can get, as i dont know much about usb at moment :-)
17:26:59n1sgevaerts: here it is: http://encodable.com/cgi-bin/filechucker.cgi?action=landing&path=/&file=simconf.diff
17:28:34 Quit polobricolo (Read error: 60 (Operation timed out))
17:30:59gevaertsn1s: what do you want built? Just all sims, or also the normal builds?
17:31:15gevaertsor everything?
17:31:15 Quit HBK ()
17:31:16n1sgevaerts: all sims should be enough
17:32:09n1sEverything Else Should Be Unaffected (tm)
17:32:21Bob_C_domonoky: cool, some USBness would be handy
17:32:48gevaertsn1s: "should"? :) Also, do you just want compile issues, or do I have to keep the files?
17:34:08n1sgevaerts: i just want to know if the sims compile cleanly, nothing in their function should have changed
17:34:12gevaertsok
17:34:24*gevaerts presses enter
17:34:26n1sso , go a head and throw everything away
17:34:35n1s\o/
17:34:40Bob_C_domonoky: I recommend looking at table 8-1 in the SoC datasheet to see how channels can best be assigned
17:34:56*n1s hears the atom breathe out a sigh of release
17:35:10n1ss/release/relief/
17:36:06 Join AEnima1577 [0] (n=clbarnob@nc6520b67.cns.vt.edu)
17:36:22 Join kugel [0] (n=kugel@rockbox/developer/kugel)
17:36:35gevaertsn1s: going home now. I guess the builds will be more or less done when I get back online
17:38:38 Join TopyMobile [0] (n=topy@171-196.79-83.cust.bluewin.ch)
17:38:46n1sok, cheers
17:39:26kugelFlynDice: on flash we don't really need the much ram. it's basically only useful for not powering up the flash so often. but if taking ram away to make flash transfers faster, that's still a netgain since that also reduces the time the flash is powered
17:40:11 Join Horscht [0] (n=Horscht2@xbmc/user/horscht)
17:40:38kugelflydutch: on 8MB the unaligned buffer could be in IRAM, that's hardly used so far
17:40:42kugelFlynDice: ^
17:49:02 Quit kugel (Remote closed the connection)
17:49:34 Join HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com)
17:49:40 Quit barrywardell ()
17:50:01 Join AEnima15771 [0] (n=clbarnob@nc6520b67.cns.vt.edu)
17:53:36 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon)
17:57:26 Join _zic [0] (n=user@91-171-85-90.rev.libertysurf.net)
18:00
18:06:10gevaertsn1s: gevaerts/errors.zip">http://www.evonet.be/~gevaerts/errors.zip
18:06:27 Join kugel [0] (n=kugel@rockbox/developer/kugel)
18:07:25 Join KushVapors [0] (n=Kush@pool-96-229-86-91.lsanca.dsl-w.verizon.net)
18:12:17FlynDicekugel: So you think that would be a good tradeoff, the tranfer speed for binsize increase?
18:15:50 Quit n1s (Read error: 110 (Connection timed out))
18:17:29kugeldefinitely
18:18:04kugelif you put it in IRAM it's not even a binsize increase
18:18:47 Join n1s [0] (n=n1s@rockbox/developer/n1s)
18:19:30 Quit AEnima1577 (Connection timed out)
18:20:20 Quit Sajber^ (Read error: 104 (Connection reset by peer))
18:20:25 Quit Rob2223 ()
18:21:38kugelFlynDice: the core uses ~100k so far (77k of it is lcd framebuffer). I think mp3 codec uses another 128, so we have almost 100k free
18:22:31kugelit might not be worth/useful for 2MB, but I'd say it's good for 8MB
18:25:49n1sgevaerts: thanks, good thing you did those test builds :D
18:28:06 Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net)
18:30:28FlynDicekugel: Well let me get some organized, concrete data to look at here and I'll bring this back up later.
18:32:34 Quit maruk ("Leaving.")
18:33:33gevaertsn1s: why? It's only 9 of them! ;)
18:35:11 Join hebz0rl [0] (n=hebz0rl@dslb-088-067-213-031.pools.arcor-ip.net)
18:38:28 Nick hebz0rl is now known as hebz0rl_ (n=hebz0rl@dslb-088-067-213-031.pools.arcor-ip.net)
18:38:32 Nick hebz0rl_ is now known as hebz0rl (n=hebz0rl@dslb-088-067-213-031.pools.arcor-ip.net)
18:39:28 Part hebz0rl ("Verlassend")
18:42:04 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl)
18:42:10 Join hebz0rl [0] (n=hebz0rl@dslb-088-067-213-031.pools.arcor-ip.net)
18:42:58 Join Rob2222 [0] (n=Miranda@p4FDCC8BE.dip.t-dialin.net)
18:48:29 Join phanboy4 [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net)
18:49:16 Quit hebz0rl ("Verlassend")
18:49:30 Join hebz0rl [0] (n=hebz0rl@dslb-088-067-213-031.pools.arcor-ip.net)
18:50:53 Quit hebz0rl (Client Quit)
18:51:52 Part craig` ("ERC Version 5.3 (IRC client for Emacs)")
18:52:06 Join hebz0rl [0] (n=hebz0rl@dslb-088-067-213-031.pools.arcor-ip.net)
18:52:38 Join freddyb [0] (n=fred@pool-70-104-101-195.chi.dsl-w.verizon.net)
18:57:37kugelFlynDice: mounting fails if I put it in iram
18:59:16FlynDicekugel: Ha Ha, I just tried that too and was looking over UNCACHED_ADDR and mapping stuff in system-as3525....
18:59:25kugelFlynDice: 1MB is much faster with a bigger buffer
18:59:49kugelstrangely, uncached seems to be faster with SVN for 4k chunks
19:00
19:01:00FlynDicekugel: Do you know how much we typically buffer at once? Do we use up the pcm buffer and then go get say 4 MB at a time?
19:01:31kugelthe audio buffer fills as fast as possible
19:01:52kugelit only stops shorty after each file
19:03:07kugeliram seems mapped correctly
19:04:42 Join JdGordon| [0] (n=Miranda@nat/microsoft/x-zfrvshkhrhqcctkc)
19:10:52***Saving seen data "./dancer.seen"
19:11:52GodEateranyone have any idea what pamaury wanted from me last night?
19:12:47 Quit freddyb (Read error: 60 (Operation timed out))
19:13:43seaniFolks, I've separated the additions in FS #10754 from my "Binary Skip" additions and popped them into FS #10766 - could someone take a look at them / give them a spin? Ta.
19:15:20GodEaterwth has happened to my source tree? :(
19:15:51kugelFlynDice: if you're bored, you could find out why the samsas panic at boot if you build rockbox with eabi
19:17:01FlynDiceof course I woul have to google eabi first.....
19:18:00kugelthe first result for "arm eabi" gives a pretty good overview
19:22:02FlynDiceI fly airplanes and solve puzzles, all this coding stuff is just advanced sudoku where I have to learn the tools as i go ;-)
19:31:44 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
19:42:07kugelFlynDice: any idea why we block while wakeup_wait in the sd driver?
19:42:45FlynDicenope, have wondered myself an not asked funman yet.....
19:44:21kugelFlynDice: ok, I see why iram doesn't work
19:45:23kugeldma needs the physical addresses. we define the sections for the remapped iram
19:45:25 Join funman [0] (n=fun@rockbox/developer/funman)
19:45:45funmanFlynDice: kugel: i just thought about these unaligned transfers
19:45:59 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net)
19:46:07funmanIIUC the reason DMA is not enabled on PP is that all buffers need to be laigned on cache size for DMA to work
19:46:26funmanthe patch they are working on should just make that, so when it's finished we could remove the need for this buffer
19:47:02funmanit should be as easy as identify all the buffers used for transfers and declare them as aligned (or align them if they need to be allocated on the stack)
19:47:27kugelfunman: what problem/question are you refering too?
19:48:44funmanenlarge/move the aligned buffer used in Sansa AMS SD driver
19:49:36funmankugel: we block in wakeup_wait because we wait for the transfer to be finished before returning, isn't it obvious ?
19:50:08kugelIIRC, the current thread is always blocked, the block parameter is about whether to block other threads
19:50:51funmanoh ..
19:52:00bertrikkugel, really?
19:52:09bertrikI thought this meant how long to wait
19:52:17kugellooking at wakeup_wait, I'm not sure
19:52:20funmanbtw wakeup_wait has a return value that we don't check
19:52:24bertrikso TIMEOUT_BLOCK basically means to wait forever
19:52:49 Quit AlexP (Remote closed the connection)
19:53:26bertrikfunman, I am confused a bit by function sd_wait_for_state
19:53:29funmanWell block_thread() only blocks the current thread
19:53:55funman * Indefinitely block a thread on a blocking queue for explicit wakeup.
19:54:02 Quit Rob2222 (Remote closed the connection)
19:54:06 Join MaadMan [0] (n=MaadMan@188-192-221-19-dynip.superkabel.de)
19:54:18funmanbertrik: what does confuse you in the function ?
19:54:30bertrikIt seems we are very careful there to count only the time we spent in our own waiting loop and not the time spent yielding
19:54:36 Join Rob2222 [0] (n=Miranda@p4FDCC8BE.dip.t-dialin.net)
19:54:39 Quit Rob2222 (Remote closed the connection)
19:54:52bertrikWhy is that?
19:55:01 Join Rob2222 [0] (n=Miranda@p4FDCC8BE.dip.t-dialin.net)
19:55:36funmanno idea, it looks wrong
19:55:56 Quit AEnima15771 (Read error: 110 (Connection timed out))
19:55:59bertrikIf we just set a simple deadline, the code can be much simpler
19:56:30funmanI must have made the mistake when converting the code from PP which uses USEC and not ticks
19:57:56funmanwe must count the time spent yielding
19:59:12*kugel wonders what senes it makes to call wakeup_wait with TIMEOUT_NOBLOCK then
20:00
20:01:26funmanwhen the thread has already been signalled, it resets signalling
20:02:22 Quit funman ("free(random());")
20:03:01 Join bmbl [0] (n=Miranda@unaffiliated/bmbl)
20:03:31FlynDiceAs long as everyone is looking at ams SD code I'd also like to bring up the fact that we don't seem to check the card response status bits for errors, we only check the controller status errors.
20:09:21 Join Sajber^ [0] (n=Sajber@c-6c3671d5.012-155-73746f22.cust.bredbandsbolaget.se)
20:13:43 Quit KushVapors ("Leaving")
20:14:13 Join domonoky1 [0] (n=Domonoky@g229151246.adsl.alicedsl.de)
20:16:44domonoky1TheSeven: i am just looking at the usb-s3c6400 code, and wonder: is it correct that usb_init_device() calls usb_drv_exit() ?
20:18:25TheSevendomonoky1: not sure, but i would expect that to be somewhere in a #ifndef USE_ROCKBOX_USB
20:18:59domonoky1it is, but i wonder about a init function calling a exit function.
20:19:46TheSevenifNdef
20:19:55 Quit domonoky (Read error: 60 (Operation timed out))
20:20:02domonoky1or is this wanted, so usb is powered down at bootup ?
20:20:09TheSevenexactly.
20:20:19domonoky1ah, now i understand :-)
20:20:36TheSevenif we don't use rockbox usb, we don't need to care about that controller, so we just shut it off
20:20:57TheSeven(and we do the same while it's disconnected, even if USE_ROCKBOX_USB is defined)
20:21:10TheSeventhe usb controller accounts for more current than the whole rest of the ipod
20:23:05domonoky1oki, thanks for the info.. i am just looking at it, to maybe copy some of the logic for mini2440 :-)
20:25:56domonoky1at the moment i got my mini2440 to send me the reset interrupt at connect, but i am unsure what i have todo next to get further in the usb-init process *need to read more docs/sources* :-)
20:31:03 Quit Utchybann ("I like core dumps")
20:40:39 Join petur [50] (n=petur@rockbox/developer/petur)
20:50:00 Join darkham [0] (n=darkham@host94-182-dynamic.47-79-r.retail.telecomitalia.it)
20:52:02 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net)
20:56:05 Quit AndyIL (Read error: 104 (Connection reset by peer))
20:58:11 Join AndyI [0] (n=pasha_in@212.14.205.32)
20:58:46 Quit Galois (No route to host)
20:59:51 Quit _zic ("Ухожу")
21:00
21:00:10 Quit n1s (Read error: 110 (Connection timed out))
21:02:54 Quit Xerion (" ")
21:10:55***Saving seen data "./dancer.seen"
21:11:18 Join webguest58 [0] (n=4007a467@giant.haxx.se)
21:11:21 Join Galois [0] (i=djao@efnet.math.uwaterloo.ca)
21:13:52 Quit webguest58 (Client Quit)
21:13:55 Quit kugel (Remote closed the connection)
21:13:57 Join webguest53 [0] (n=4007a467@giant.haxx.se)
21:14:49 Quit reid02 (Connection timed out)
21:15:53 Part Computer
21:16:01 Quit webguest53 (Client Quit)
21:16:14 Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl)
21:44:36 Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net)
21:46:58 Join reid05 [0] (n=reid85@CPE001cdf73661f-CM001ceacec55e.cpe.net.cable.rogers.com)
21:55:10 Join n1s [0] (n=n1s@rockbox/developer/n1s)
21:56:20 Quit Rob2222 ()
22:00
22:08:29bluebroth3rhmm. That cross compiling support in sansapatche and ipodpatcher makes it noticably harder to create a more generic Makefile for building a library.
22:08:32 Nick bluebroth3r is now known as bluebrother (n=dom@rockbox/developer/bluebrother)
22:27:46linuxstbbluebrother: I wouldn't want to lose that...
22:33:39 Join freddyb [0] (n=fred@pool-71-171-209-35.chi01.dsl-w.verizon.net)
22:35:26bluebrotherlinuxstb: I guessed that :)
22:38:03linuxstbbluebrother: Just confirming... ;)
22:38:23bluebrotherdo you think it would be acceptable to change to some "make RBARCH=w32" instead of "make sansapatcher.exe"?
22:38:34bluebrothers/some/something like/
22:39:47linuxstbI don't really mind, as long as it's still possible. But what about creating different Makefiles (possibly sharing some things via a common include) ?
22:41:27bluebrotherhmm, that's another option. I was thinking about moving all those OS X lib trickery into a common Makefile later.
22:42:14 Part froggyman
22:43:19 Join notlistening [0] (n=tom@94-195-105-95.zone9.bethere.co.uk)
22:45:44notlisteningdomonoky1, I have been quite quiet for some time now so thought i would check in and see if there was anything that needed doing on the SAPI side? I am rapidly developing the next version and fixing some bugs. Any ideas from from side?
22:46:36domonoky1notlistening: not really, i didnt found the time and motivation to work at it.. but i hope to continue it sometime :-)
22:48:09notlisteningno worries i have seen your busy on another player ;)
22:49:15notlisteningWell there is a whole load of stuff my end like documentation and stuff so i will make a big push on the next release to get everything u otgether my end.
22:49:21domonoky1two things come in mind. startup speed (especially on linux) and binary size would be nice if it could be improved :-)
22:50:02notlisteninglol he wants the world ;D
22:50:48domonoky1:-)
22:52:05notlisteningI think the start time has improved now i am using the latest version of wine, and i can try and cut down the binary by purging uneeded packages
22:52:41notlisteningI will add them to the wish list
22:52:51notlisteningHow is the mini going?
22:53:43domonoky1pretty good. audio works.. all thanks to Bob_C :-)
22:54:18 Quit TopyMobile (Read error: 113 (No route to host))
22:54:41 Join TopyMobile [0] (n=topy@232-194.79-83.cust.bluewin.ch)
22:55:15notlisteningyeah some really great work going on there...just wish someone would implement networking into rockbox :D
22:55:30 Quit evilnick_B ("Page closed")
22:56:42 Join LambdaCalculus37 [0] (n=LambdaCa@rockbox/staff/LambdaCalculus37)
22:57:06freddybIs anyone watching FS #10371 - recording for AMS Sansa? I've been using the rec-v11.diff for a while now and haven't had a crash.
22:57:28domonoky1notlistening: if someone would write the networkdriver, i will port lwip to rockbox :-)
22:58:16freddybHas anyone (besides FlynDice) tried my keyboard patch for scroll wheel models? (FS #10763)
22:58:19bertrikI don't see the point of networking in rockbox, but everybody's free to try of course
22:59:54domonoky1bertrik: nfs or smb client would be cool.
23:00
23:00:13 Quit gevaerts (Nick collision from services.)
23:00:22 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts)
23:01:00bertrika coworker did smb on top of lwip on a 8051-type processor once, he claimed it wasn't actually that complex
23:01:55LambdaCalculus37bertrik: Networking in Rockbox would be more useful if we ever got a Rio Karma port started.
23:02:02notlisteningwell if there are players that are supporting network interfaces then networking become a viable option for rockbox
23:02:18Bagderisn't there already networking-over-usb things?
23:02:38notlisteningwhen you run through the usecase of having a rockbox based in car player or home audio system
23:04:04notlisteningdoes that move outside the realms of what the steering board would see fit for purpose?
23:05:30 Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net)
23:06:22TorneBagder: yeah, we could implement a usb network endpoint and then people could use smb or similar instead of mtp/msc
23:06:25Torne:)
23:06:53Tornemight be considered preferable to mtp by soem people for using devices that cna't be exported as msc..
23:07:02Torne(real flash filesystems)
23:07:27Bagderright, but which can't be msc but can be a network endpoint?
23:07:40gevaertsTorne: do you actually see a real reason to prefer smb over mtp?
23:07:57bertriknotlistening, as far as I know, there is no exactly defined scope of what rockbox should be limited to
23:08:27Bagdereveryone's scope is slightly different ;-)
23:08:28TorneBagder: well we don't have any targets taht can't do MSC atm
23:08:41Tornebut various people seem to be slightly interested in flash FSes and the like
23:08:44notlisteninganother quick question GPL v2 vs GPL3 why can you not include code from a GPL3 project?
23:08:52Bagderwe can
23:08:59Bagderbut then we'd have to be gplv3
23:09:35Bagderand we're not in agreement that's where we want to go
23:10:23notlisteningahh okay the higher liscence takes presidence
23:10:58gevaertsnot as such
23:10:59***Saving seen data "./dancer.seen"
23:11:08Bagderthe effect is such at least
23:11:23gevaertsIt's just that if one part of the code is "v2 or higher" and another is "v3", the whole is v3
23:12:03gevaertshypothetically speaking you could have a strict v2 project and a v3-or-lower project that combine to a v2 project...
23:13:15notlisteningSo there is an espeak plugin being developed and that seems to be the stopper on it?
23:13:30 Join Utchybann [0] (n=lolo@ede67-1-81-56-102-26.fbx.proxad.net)
23:14:12 Quit domonoky1 (Read error: 104 (Connection reset by peer))
23:14:18 Quit petur (Remote closed the connection)
23:15:12notlisteninghttp://www.rockbox.org/tracker/task/7660?string=Voice+tag+for+recordings&project=1&type[0]=4&sev[0]=&pri[0]=&due[0]=&reported[0]=&cat[0]=&status[0]=open&percent[0]=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=
23:15:17n1snotlistening: yes, as is explained in that task
23:15:47n1swhat is unfortunate is that the espeak eveloper did not seem to think this was a problem
23:15:57n1ss/eve/deve
23:16:49notlisteningok, i was just trying to understand more than "you just can't"
23:17:45Bagderwell, read the licenses ;-)
23:18:17n1sin short: gpl v2 and v3 are incompatible, we however allow our code to be reliseced to v3 but are not sure we want to
23:19:00notlisteningGot it
23:19:30n1s... go with v3 for rockbox, a for or unofficial build could do this
23:19:35n1sforK
23:19:51 Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
23:22:01 Join AlexP [0] (n=alex@rockbox/staff/AlexP)
23:22:25 Join Sajber^1 [0] (n=Sajber@c-6c3671d5.012-155-73746f22.cust.bredbandsbolaget.se)
23:23:48 Join tchan1 [0] (n=tchan@c-67-173-9-133.hsd1.il.comcast.net)
23:28:46 Quit AaronM (Remote closed the connection)
23:30:11 Quit tchan1 ("WeeChat 0.3.1-dev")
23:30:24 Quit notlistening ("Leaving")
23:30:51 Join tchan1 [0] (n=tchan@c-67-173-9-133.hsd1.il.comcast.net)
23:30:56 Join AaronM [0] (n=Aaron@adsl-4-241-157.mem.bellsouth.net)
23:31:54 Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow)
23:32:01 Quit tchan (Nick collision from services.)
23:32:06 Nick tchan1 is now known as tchan (n=tchan@c-67-173-9-133.hsd1.il.comcast.net)
23:32:44 Join aaron [0] (n=quassel@adsl-065-013-002-216.sip.asm.bellsouth.net)
23:32:49 Quit aaron (Remote closed the connection)
23:33:26*Unhelpful thinks he follows polobricolo's question... caller-saved registers aren't saved on thread change since the thread calling yield() has already done this itself.
23:33:53amiconnCorrect
23:34:28amiconnIn fact yield() is just a normal function call in cooperative threading, so no need to save scratch registers
23:34:36amiconn(in yield())
23:35:03Unhelpfulexcept that we "return" to where somebody else called yield ;)
23:35:35amiconnAs seem from the function calling it, we're just returning (after some time)
23:36:42 Join AEnima1577 [0] (n=clbarnob@nc652104f.cns.vt.edu)
23:39:15 Quit AEnima1577 (Client Quit)
23:39:30 Quit Sajber^ (Read error: 110 (Connection timed out))
23:40:42 Quit jgarvey ("Leaving")
23:43:19 Quit TopyMobile (Read error: 104 (Connection reset by peer))
23:44:31 Join TopyMobile [0] (n=topy@232-194.79-83.cust.bluewin.ch)
23:44:41 Quit darkham ("Sto andando via")
23:47:11CIA-6New commit by 03bertrik (r23544): Meizu M6SP: initialise and use SDRAM
23:48:56 Quit n1s ("Lmnar")
23:51:32 Quit z35 ("Leaving")
23:51:33 Quit bmbl ("Bye!")
23:51:35 Quit AaronM ("goin to MS this weekend :/")
23:52:08 Join Lynx_ [0] (n=Lynx@cable-213-168-64-165.netcologne.de)

Previous day | Next day