| 00:00:05 | Llorean | Is 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:05 | JdGordon| | *anything* is possible :) |
| 00:01:36 | JdGordon| | histogramn might be difficult to do, but it would be cool to split the peakmeter into 2 seperate tags |
| 00:02:02 | Llorean | Okay, "any good way" ? :-P |
| 00:02:25 | | Quit bertrik ("De groeten") |
| 00:02:31 | JdGordon| | good from whos perspective? |
| 00:02:51 | Llorean | I don't know. Heh. |
| 00:03:01 | Llorean | Yeah, I'd imagine it'd be more difficult for the histogram. |
| 00:03:04 | JdGordon| | 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:10 | Llorean | Agreed! |
| 00:03:22 | Llorean | I've kinda felt the peakmeter is basically useless now for anyone wanting to use a modern theme. |
| 00:03:30 | Llorean | Since you can't really do anything with it. |
| 00:03:59 | petur | peakmeter is essential for recording, though |
| 00:04:21 | Llorean | petur: I meant in playback, rather. |
| 00:04:26 | petur | ah ok |
| 00:04:34 | Llorean | Since 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:58 | petur | vertical peakmeters would be a space saver |
| 00:05:24 | petur | and 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:04 | Llorean | Wouldn'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:34 | Llorean | Vertical 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:13 | petur | don't forget peakmeters are updated *very* frequently |
| 00:07:31 | JdGordon| | 25Hz |
| 00:09:13 | Llorean | I 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:45 | Llorean | I guess the other alternative is doing them like the progress bar instead. Less flexible, but probably more able to be optimized. |
| 00:09:55 | petur | right now it paints black rectangles |
| 00:10:27 | petur | doing a memcpy of an image should work too |
| 00:10:29 | JdGordon| | Llorean: for the peak bars I'd rather it work like that instead of having hundreds of conditionals... |
| 00:10:35 | JdGordon| | either of course could be fixed up |
| 00:10:48 | Llorean | I think doing it like volume is a lot more flexible from the user standpoint. |
| 00:10:52 | gevaerts | If images aren't achievable, you could let orientation, size and colour be settable. Those shouldn't cost too much |
| 00:10:56 | petur | we can start simple and go from there? |
| 00:10:59 | Llorean | You could have a variety of neat effects based off the peak meters. |
| 00:11:34 | JdGordon| | cant you do colour already using viewports? |
| 00:11:47 | Llorean | I'd say you need two colors. |
| 00:11:49 | Llorean | Border and filling. |
| 00:12:03 | Llorean | Or maybe a color and a gradient even. |
| 00:12:05 | pixelma | I'm still annoyed be the two line heigh peakmeters on the Archos recording screen |
| 00:12:14 | pixelma | s/be/by |
| 00:12:57 | JdGordon| | 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:38 | petur | pixelma: if you enable trigger, they become smaller :p |
| 00:13:38 | | Quit jgarvey ("Leaving") |
| 00:14:24 | pixelma | at 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:28 | gevaerts | there seem to be 10 screen sizes that do recording |
| 00:21:54 | JdGordon| | hwcodec and swcodec cant share skins :( |
| 00:22:15 | JdGordon| | kugel: unless you come up with a way to fix the feautre check to get rid of the false branch? |
| 00:24:14 | gevaerts | JdGordon|: 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:34 | gevaerts | I haven't taken remotes into account here |
| 00:24:44 | JdGordon| | ok, good |
| 00:25:04 | petur | gah.. I really hate that histogram patch... "hey look, I can add 5 features in one patch" :/ |
| 00:25:44 | petur | not to mention it is 2+ years old |
| 00:25:46 | gevaerts | I 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:47 | pixelma | even then there are no screens exactly the same size but close (Iriver remotes 128x64, Archos screens 112x64) |
| 00:26:29 | petur | right now the recording screen has a fixed top part and uses the rest for the list |
| 00:26:47 | gevaerts | so only width actually matters? |
| 00:27:05 | gevaerts | (if you want to reproduce the current look) |
| 00:27:14 | petur | actually, it handles some stuff differently for small screens |
| 00:28:18 | petur | calculated in recording.c at lines 1133 and following |
| 00:28:41 | Unhelpful | kugel: 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:15 | petur | and 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:57 | JdGordon| | petur: I'm giong to keep the list part avilable using the %Vi viewport tag in the rec screens skin file.. |
| 00:35:46 | petur | euh... you need the listbox to be able to select volume, L/R gain,... |
| 00:36:19 | petur | up/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:00 | pixelma | the 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:01 | JdGordon| | 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:06 | seani | Folks, 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:24 | petur | one feature per patch please |
| 00:50:43 | petur | as we do one feature per commit too |
| 00:51:27 | Llorean | seani: 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:48 | Llorean | You 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:35 | Llorean | If 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:56 | seani | Llorean: 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:19 | Llorean | Sounds good to me, at least. |
| 00:56:07 | Llorean | In "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:13 | seani | Yes, 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:09 | saratoga | Blue_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:09 | seani | If 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:11 | Llorean | Sounds okay to me so far. Not something I would likely use regularly. |
| 00:58:13 | saratoga | they mostly just disable it |
| 00:58:32 | Llorean | I 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:49 | Llorean | Usually that range is "just go back to the bookmark, you can't remember anything when you're tired anyway" :0 |
| 00:58:50 | Llorean | :) even |
| 00:59:03 | saratoga | honestly 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:28 | saratoga | and any other "enhancements " that were largely hacked into playback |
| 00:59:47 | Llorean | saratoga: 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:44 | saratoga | (i hope blue_dude checks the logs) |
| 01:00:44 | seani | More 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:32 | seani | No idea how the "read out" bit would be done. |
| 01:01:33 | Blue_Dude | saratoga: I do check the logs... :) |
| 01:02:12 | saratoga | my 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:34 | saratoga | but if its simply not well implemented there is some justification for it . . . |
| 01:02:35 | Llorean | seani: 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:37 | Blue_Dude | And 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:43 | Llorean | And after the 5 second timeout the searching will be very wild again. |
| 01:03:03 | Llorean | I'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:12 | Blue_Dude | saratoga: was that comment for me? |
| 01:03:25 | saratoga | yes |
| 01:03:38 | saratoga | I should have said "playback feature" |
| 01:03:55 | Blue_Dude | I didn't take out any features yet. Just bitching about the code. |
| 01:04:22 | saratoga | I was referring to your question about how many people actually use crossfade |
| 01:04:45 | Blue_Dude | I'll leave it in. That was more venting than anything else. I'll make it work out. |
| 01:05:17 | Blue_Dude | And 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:01 | saratoga | good, 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:42 | Blue_Dude | I 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:51 | saratoga | if 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:08 | saratoga | its all twisted into a half dozen functions |
| 01:10:10 | Blue_Dude | I'd really like to have pcmbuf be modular for all audio playback without having all this crosstalk with playback.c and whatnot. |
| 01:10:20 | saratoga | that would be nice |
| 01:10:28 | saratoga | it would make debugging 10x easier |
| 01:10:30 | *** | Saving seen data "./dancer.seen" |
| 01:10:51 | Blue_Dude | Then I'm going to steal code from voice_thread. Then do the software mixer in pcmbuf. |
| 01:10:56 | Blue_Dude | It'll take time. |
| 01:11:06 | JdGordon| | 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:23 | seani | Llorean: 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:23 | seani | parately to be kicked about. |
| 01:11:28 | saratoga | breaking it up makes it more understandable |
| 01:11:33 | | Join AndyIL [0] (n=pasha_in@212.14.205.32) |
| 01:11:46 | saratoga | IMO playback and buffering aren't individually incomprensible, they're just all mixed up |
| 01:12:00 | Blue_Dude | I 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:30 | seani | Oops giant noob posting, apologies. |
| 01:13:30 | Blue_Dude | I'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:52 | seani | Llorean: 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:38 | Llorean | seani: for seeking by timestamp an actual screen where you could input the timestamp might be best. :-P |
| 01:14:50 | Blue_Dude | JdGordon: It might be worth redoing playback from scratch. But you'd probably have to sacrifice features at first to get there. |
| 01:15:15 | Llorean | Rockbox 4.0 Beta - new playback engine. :-P |
| 01:15:17 | Blue_Dude | JdGordon|: Sorry, I always forget the "|" |
| 01:15:40 | JdGordon| | Llorean: new playback engine.. take 2! |
| 01:16:02 | JdGordon| | Blue_Dude: that wouldnt worry me.. I dont use any of the features which woudl dissapear :) |
| 01:16:18 | saratoga_lab | and we do have the old releases for people who need them |
| 01:16:25 | Llorean | If 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:27 | saratoga_lab | probably wouldn't take too long for things to be reimplemented |
| 01:16:44 | Llorean | Then 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:47 | saratoga_lab | if they're actually useful and you left a clean way to reimplement them |
| 01:17:58 | Blue_Dude | One 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:17 | saratoga_lab | the globals are great |
| 01:18:23 | saratoga_lab | some barely have comments |
| 01:18:24 | seani | Tsk, right between the shoulder blades. It isn't the code that gets you in here, it's the sarcasm. |
| 01:19:03 | saratoga_lab | i 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:16 | saratoga_lab | for no apparent reason |
| 01:19:16 | Blue_Dude | Globals are great, as long as you have tight control of scope and limit duplications. |
| 01:19:21 | Llorean | seani: 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:07 | JdGordon| | Blue_Dude: globals are never great! globals are a nessecary evil! |
| 01:20:10 | Blue_Dude | saratoga_lab: that's one of the first areas I'm going to address: the user interface has to get more responsive. |
| 01:20:22 | JdGordon| | playback especially should have no outward facing globals |
| 01:20:45 | Blue_Dude | JdGordon|: Well, they're "great, but..." |
| 01:21:18 | JdGordon| | file scoped globals I dont have much problem with, assuming the file is only one module :) |
| 01:21:21 | Blue_Dude | I just added one of those the other day. It's aimed at pcmbuf. :) |
| 01:22:00 | seani | Llorean: 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:56 | 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. |
| 01:23:15 | Unhelpful | seani: 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:27 | saratoga_lab | seani: we commit patches and then the build system compiles them all and tells us if anything went wrong |
| 01:23:29 | saratoga_lab | if it goes wrong you fix it |
| 01:23:51 | Unhelpful | Blue_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:38 | Blue_Dude | Unhelpful: I meant in comparison to function calls. Variables do consume *something*. |
| 01:24:45 | saratoga_lab | well playback is one place i think we could spare a tiny bit of memory if it improves maintainability |
| 01:24:59 | saratoga_lab | i'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:32 | seani | Unhelpful: 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:45 | Blue_Dude | saratoga: 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:24 | Unhelpful | seani: 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:15 | JdGordon| | 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:38 | Blue_Dude | Yeah, 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:35 | Blue_Dude | Only really common variables might be an exception. audiobuf comes to mind. |
| 01:31:19 | seani | Unhelpful: 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:47 | Unhelpful | seani: 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:15 | Blue_Dude | seani: Sandwich? Ham, sharp cheese, chipotle, light mayo, hold the onions, peppers OK. To go please? |
| 01:33:34 | saratoga_lab | on 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:49 | saratoga_lab | and of course actually have a way to reproduce playback bugs |
| 01:33:52 | Unhelpful | "but i don't have any..." "what, brains?" "no, sandwiches" "well what good are you then?" |
| 01:34:49 | Unhelpful | saratoga: 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:57 | saratoga_lab | the sim |
| 01:35:03 | | Quit MethoS- (Remote closed the connection) |
| 01:35:21 | saratoga_lab | something that just allowed running playback at 10x realtime with the ability to queue files would be great |
| 01:36:58 | rasher | Unhelpful: 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:11 | saratoga_lab | woah |
| 01:37:14 | seani | Unhelpful: 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:24 | rasher | Hm, FS #10571 doesn't look completely updated |
| 01:38:15 | seani | Unhelpful: 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:41 | Blue_Dude | saratoga_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:42 | rasher | Unhelpful: 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:02 | Unhelpful | kugel: so the things you fixed were enums in global_settings? |
| 01:49:48 | pushnell | Hey 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:06 | saratoga_lab | 1.2.3 is the installer version number, not rockbox |
| 01:50:15 | | Quit Thundercloud (Remote closed the connection) |
| 01:50:42 | pushnell | Hrm, thanks saratoga_lab. Looking to see what version I actually installed then. |
| 01:50:59 | pushnell | version 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:57 | kugel | Unhelpful: yea, both statusbar settings |
| 01:58:58 | | Quit zu_ (Read error: 54 (Connection reset by peer)) |
| 01:59:11 | pushnell | Ok, just confirmed that the idle power off is not working either. |
| 01:59:17 | Unhelpful | kugel, 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:58 | pushnell | Is there any sort of user error I could be performing to cause this? |
| 02:01:53 | | Quit seani ("Leaving") |
| 02:04:10 | pushnell | Ok, booting back into factory firmware lets me power it off just fine. I'd have to say this is a bug. |
| 02:04:29 | Llorean | The factory firmware doesn't power off |
| 02:04:38 | Llorean | It just switches off the screen, and goes into a low-power mode. |
| 02:04:56 | Unhelpful | version 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:53 | pushnell | Llorean: OK, I'm new to ipods and to rockbox so pardon my ignorance. Long Play on rockbox does nothing though. |
| 02:06:57 | Unhelpful | pushnell: 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:14 | Llorean | On the iPod especially, since the regular long press stops playback |
| 02:07:25 | Llorean | Also, it can be a little sensitive, so try not to wiggle your finger |
| 02:07:56 | Unhelpful | Llorean: ah, i didn't know that there was already a normal long-press action for that button :) |
| 02:08:46 | Llorean | Unhelpful: Yeah. The iPod is a bit short on buttons (I think second shortest of non-touchscreen, with Ondio taking the prize) |
| 02:08:47 | Unhelpful | hahah, i hung rockbox in a very *odd* way... non-responsive to input, "scanning disk..." splash is present, and playback is running uninterrupted :) |
| 02:09:11 | Llorean | So "Play/Pause" has "Play/Pause" on tap, "Stop" on long, and "Shut down" on very long. |
| 02:09:19 | Llorean | I think it's the only button with a very-long though |
| 02:10:20 | pushnell | Ok, 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:02 | Llorean | pushnell: And what version number or revision is your Rockbox? |
| 02:11:04 | saratoga_lab | the hardware reboot kicks in at 30 so either its broken or you're not doing it right |
| 02:11:13 | pushnell | version 3.4 |
| 02:11:32 | pushnell | Whatever it's supposed to do from factory firmware, it does. |
| 02:11:42 | Llorean | saratoga_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:18 | saratoga_lab | theres a hard reboot IIRC, at least my 3G had one |
| 02:12:19 | pushnell | I just installed today from installer 1.2.3, System -> Rockbox Info shows version 3.4 |
| 02:12:28 | pushnell | hard reboot is Menu + Select |
| 02:12:38 | pushnell | (for like 10 secs) |
| 02:12:38 | Llorean | saratoga_lab: Hard reboot is menu+select isn't it? |
| 02:12:41 | saratoga_lab | ah ok was remembering wrong |
| 02:13:21 | Llorean | pushnell: 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:25 | pushnell | Hrm :/ ... I actually bought this ipod because I discovered rockbox (and thus accessibility to ogg/flac). |
| 02:13:36 | pushnell | Not that I know of. Like I say, this is my first ipod. |
| 02:13:42 | pushnell | Anything I can check? |
| 02:14:02 | pushnell | It shows as 30Gb (27.xx) in Windows. |
| 02:14:19 | saratoga_lab | i guess you could try a newer build then 3.4 and see if its any different |
| 02:14:27 | Llorean | That'd be the first thing to try, yeah. |
| 02:14:55 | pushnell | Ok. Would that be a "current" build? |
| 02:15:28 | | Part JohnTeddy |
| 02:15:43 | saratoga_lab | i think its the current build button in rbutil |
| 02:17:46 | pushnell | Hrm, I see nothing that says indicates what build is about to be installed. |
| 02:18:24 | pushnell | "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:41 | saratoga_lab | the install picture on the website shows a chose of builds |
| 02:18:54 | saratoga_lab | so i guess try harder |
| 02:19:31 | kugel | Unhelpful: strange.. |
| 02:20:40 | Unhelpful | kugel: that branch is well behind svn, i'm updating now :) |
| 02:20:46 | Llorean | pushnell: There should be an option for current build. |
| 02:20:49 | pushnell | Ah, if you do a manual install it asks. About to install r23540 |
| 02:21:14 | Unhelpful | about 300 revisions behind :) |
| 02:21:20 | pushnell | Would the bootloader have changed since 3.4? |
| 02:21:52 | Unhelpful | if 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:33 | Llorean | pushnell: 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:31 | Unhelpful | do 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:51 | Llorean | Somewhat |
| 02:25:54 | Llorean | I think it's incomplete. |
| 02:26:20 | Llorean | http://download.rockbox.org/test_files/ |
| 02:26:21 | kugel | Unhelpful: *clean* svn except for global settings change |
| 02:26:25 | kugel | does not boot here |
| 02:27:30 | pushnell | Ok, getting the same behavior on r23540 |
| 02:27:32 | Unhelpful | *how* clean? my branch only modifies rockboxdev.sh, configure, and settings.h... |
| 02:28:51 | kugel | the asterisks were supposed to indicate "completely clean" |
| 02:29:10 | kugel | also, 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:35 | kugel | I seem to get behind lcd_init() which is after settings_reset() (going by some flackering of the screen= |
| 02:33:37 | kugel | ) |
| 02:35:49 | Unhelpful | well, again, if we know that some specific previous rev boots... |
| 02:36:21 | kugel | what does your updated branch do ? |
| 02:38:00 | Unhelpful | i 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:34 | Unhelpful | the 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:32 | Unhelpful | that 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:44 | kugel | that doesn't sound very clean :P |
| 02:40:49 | Unhelpful | maybe, 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:02 | Unhelpful | vorbis playback now fails for me, makes funny sounds for a bit and then stops. mp3 fails with prefetch abort. |
| 02:42:24 | kugel | recompiled codecs? |
| 02:42:44 | kugel | stuff that touches linking sometimes require deleting everything |
| 02:42:58 | Unhelpful | i built everything in an empty build dir and then did make install... |
| 02:43:46 | Unhelpful | the 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:38 | kugel | ha! |
| 02:44:47 | kugel | I didn't have -mno-long-calls |
| 02:44:59 | kugel | that was why I didn't get the 60k binsize savings too ;) |
| 02:45:00 | Unhelpful | i don't either, i just don't have -mlong-calls. :P |
| 02:45:06 | kugel | now it boots too, strangely |
| 02:45:36 | Unhelpful | kugel: interesting, so the bulk of the binsize savings really *is* due to long calls? |
| 02:45:37 | kugel | I didn't change configure except for fuze. I always manually edited the Makefile |
| 02:45:38 | Unhelpful | that's kind of scary. |
| 02:46:00 | kugel | it's also scary that it doesn't boot with long calls |
| 02:46:45 | Unhelpful | yes, i don't like that, either. |
| 02:47:11 | Unhelpful | although the whole point of this was to be able to remove them. :) |
| 02:47:13 | kugel | eabi alone is -6k btw |
| 02:47:44 | kugel | mp3/ogg/m3a all work |
| 02:48:35 | Unhelpful | they work on fuze? odd. |
| 02:48:46 | kugel | e200 |
| 02:48:56 | kugel | fuze doesn't work at all, panics in the sd driver |
| 02:50:23 | Unhelpful | all 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:42 | kugel | did you delete the build dir? |
| 02:51:00 | kugel | I tell you, that solves codec problems very often |
| 02:51:09 | Unhelpful | yes, a completely fresh build. :P |
| 02:51:32 | Unhelpful | i'll try again, and clear out my ccache as well, although ccache should *not* be mixing these things up. |
| 02:51:59 | kugel | just take a different build dir then you don't need to clear ccache |
| 02:52:44 | Unhelpful | i was *already* using a different build dir. |
| 02:52:52 | kugel | hm |
| 02:53:55 | | Join gtkspert_ [0] (n=gtkspert@124-169-51-119.dyn.iinet.net.au) |
| 02:54:02 | Unhelpful | and ccache doesn't know about paths anyway, it's keyed on compiler options and preprocessed source, isn't it? |
| 02:54:17 | kugel | it's not intelligent |
| 02:54:23 | kugel | it really uses paths |
| 02:57:12 | Unhelpful | "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:01 | kugel | Unhelpful: it doesn't even kick in for files with different paths |
| 03:06:29 | kugel | what 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:21 | Unhelpful | kugel: 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:37 | kugel | I don't know where it's stored, but it does in fact not work for different pathes |
| 03:12:07 | kugel | we found that by observing the build system |
| 03:13:12 | Unhelpful | hm? 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:54 | kugel | no, builds are much faster since we changed the build dir to be constant per target |
| 03:16:02 | Unhelpful | hrm. 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:13 | Unhelpful | another rebuild, and i still can't play vorbis :/ |
| 03:18:57 | Unhelpful | i wonder if git bisect can bisect the branch *under* the local branch |
| 03:20:57 | kugel | i 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:14 | Unhelpful | kugel: 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:43 | kugel | Unhelpful: nah, that's not the problem |
| 03:23:03 | kugel | I had roughly the same figures with non-eabi 4.4.1 |
| 03:24:13 | Unhelpful | also 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:38 | kugel | Unhelpful: I don't there are much stubs |
| 03:27:49 | kugel | the short call limit is 64MB isn't it? |
| 03:28:14 | Unhelpful | kugel: i belive so. only calls into, or out of, iram should be stubbed. |
| 03:28:29 | kugel | if possible |
| 03:28:41 | Unhelpful | calls 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:50 | froggyman | :Nick linuxis#1 |
| 03:29:13 | | Nick froggyman is now known as Guest68424 (n=187b533e@giant.haxx.se) |
| 03:29:13 | kugel | I 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:58 | kugel | I 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:26 | Unhelpful | kugel: 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:41 | Unhelpful | the stubs *do* use long calls, or rather long jumps. |
| 03:33:49 | saratoga_lab | unless the changes are dramatic its probably not worth worrying about |
| 03:33:52 | kugel | what's the advantage over real long calls there? |
| 03:34:05 | saratoga_lab | we can force or disable inlining and move things around in iram |
| 03:34:26 | saratoga_lab | jumping to a stub is smaller then having long jumps everywhere |
| 03:34:50 | kugel | saratoga_lab: flag losses nearly 20%, the other codecs <3% |
| 03:35:39 | saratoga_lab | thats surprising but probably just something simple that can be fixed |
| 03:36:04 | kugel | saratoga: but if you can access the stub only via long call, nothing is gained |
| 03:36:27 | saratoga_lab | stubs 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:51 | saratoga_lab | thats basically the idea as I understand it, just make little stub functions in each section in order to avoid long calls |
| 03:37:03 | kugel | but that's not possible sometimes |
| 03:37:45 | Unhelpful | kugel: 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:00 | kugel | ah so you the stub saves the 4B for saving the address repeatedly, but still does the long call? |
| 03:39:08 | Unhelpful | and 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:39 | kugel | (for calls that are too far away I mean= |
| 03:39:42 | kugel | ) |
| 03:39:44 | Unhelpful | kugel: yes and no. with -mlong-calls, gcc makes any call outside the current module a long call |
| 03:40:08 | kugel | I know what -mlong-call does |
| 03:40:27 | Unhelpful | kugel: well, a lot of those can be direct short calls that don't use the stub. |
| 03:40:51 | kugel | I'm only talking about calls where a simple short call isn't possible at the moment |
| 03:40:56 | Unhelpful | for many functions, there are never any calls that would be out of range, and no stub is generated. |
| 03:41:08 | kugel | I 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:01 | Unhelpful | kugel: "where a simple short call isn't possible"? |
| 03:42:24 | kugel | if caller and callee are too far away |
| 03:42:29 | Unhelpful | gcc generates asm instructions to do a short call to some function, by label/symbol |
| 03:43:32 | Unhelpful | it'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:05 | kugel | and what's the gain over a long call in the first place? |
| 03:44:45 | Unhelpful | kugel: about 63KB total? ;) |
| 03:45:31 | Unhelpful | the 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:43 | kugel | is 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:32 | Unhelpful | actually, 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:06 | Unhelpful | this 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:53 | Unhelpful | long calls are ldr <reg> [pc, offset] ; mov lr, pc; bx <reg>. short calls are bl <offset> |
| 03:53:39 | Unhelpful | the 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:41 | kugel | ok, so you can only do all-or-nothing |
| 03:56:00 | kugel | so a long call is 12bytes in total? |
| 03:56:35 | Unhelpful | 12B 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:57 | kugel | err, I meant 16 |
| 03:57:47 | kugel | anyway, I wonder how to fix the fuze |
| 03:57:57 | kugel | I don't think we can enable eabi per target? |
| 03:58:17 | Unhelpful | well, 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:46 | Unhelpful | kugel: sure we can, as long as we require that both eabi and non-eabi compilers be available. ;) |
| 04:00 |
| 04:01:37 | Unhelpful | some targets can build using arm-elf-foo, some using arm-elf-eabi-foo |
| 04:01:55 | Unhelpful | does fuze work with a "normal" gcc-4.4.1? |
| 04:02:18 | kugel | i didnt test |
| 04:02:57 | Unhelpful | your 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:03 | Unhelpful | saratoga: 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:35 | Unhelpful | so 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:05 | saratoga_lab | Unhelpful: i'm not really sure how this works |
| 04:43:26 | saratoga_lab | but 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:38 | CIA-8 | New commit by blue_dude (r23541): pcmbuf: sorted functions into logical sections for readability. Tiny changes, nothing functional |
| 05:19:12 | saratoga_lab | woot! |
| 05:20:14 | Blue_Dude | That's just cut and paste. It's not even a real change yet. I wanted a baseline though. |
| 05:21:15 | Blue_Dude | hmph. |
| 05:21:47 | Blue_Dude | ah ok, needs ifdef's for function prototypes. got it |
| 05:21:52 | Unhelpful | saratoga: expensive, i would think? i believe mov on arm is one cycle if the destination is not pc... |
| 05:23:12 | Unhelpful | i 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:29 | CIA-8 | New commit by blue_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:58 | saratoga_lab | Unhelpful: 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:11 | Unhelpful | saratoga: there's overhead on a register-to-register move? it's not a store-to-memory. |
| 06:00 |
| 06:00:38 | saratoga_lab | Unhelpful: doesn't it have to push some of the current registers onto the stack to make room for the function arguments? |
| 06:03:13 | Unhelpful | saratoga: 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:04 | FlynDice | funman:(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:05 | Unhelpful | should 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:10 | Unhelpful | amiconn: 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:52 | Unhelpful | also, 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:34 | Unhelpful | and 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:12 | saratoga_lab | i 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:29 | saratoga_lab | we 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:23 | Unhelpful | amiconn: 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:03 | Unhelpful | that 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:28 | Unhelpful | there'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:10 | amiconn | Unhelpful: 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:51 | Unhelpful | .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:04 | Unhelpful | and then ".iram 0x4000c000 0x42b8 load address 0x01e97248 |
| 10:44:12 | Unhelpful | grr, stupid copying newlines :/ |
| 10:44:19 | amiconn | Hmm, that's a codec .map, and codec_crt0.c uses memcpy(), so alignment is unimportant |
| 10:45:30 | amiconn | The +/- 0x10000000 is correct. It comes from the nocachebss section right before .iram |
| 10:47:06 | Unhelpful | but shouldn't .iram's load address = iramcopy? |
| 10:47:32 | amiconn | It is... |
| 10:48:19 | Unhelpful | then i'm a bit confused about the map file, because i see two different addresses... |
| 10:48:30 | amiconn | iramcopy is at 0x01e97248 |
| 10:48:44 | amiconn | This is the also the load address |
| 10:48:51 | amiconn | s/also// |
| 10:48:57 | Unhelpful | doesn't 0x01e97250 iramcopy = (. - 0x10000000) |
| 10:49:20 | amiconn | Eh, wait |
| 10:49:27 | amiconn | There's an offset of 0x8 |
| 10:49:29 | Unhelpful | grr. doesn't "0x01e97250 iramcopy = (. - 0x10000000)" indicated iramcopy = 0x01e97250 ? |
| 10:50:02 | Unhelpful | i 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:30 | Unhelpful | amiconn: 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:15 | Unhelpful | amiconn: 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:11 | NSplit | lindbohm.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:43 | Unhelpful | hrm, or given that no codec or plugin seems to place anything in .ncdata, that section could just disappear from plugin.lds... |
| 12:37:59 | funman | Unhelpful: true |
| 12:39:54 | Unhelpful | i wonder if that will kill the offset bug, too... |
| 12:40:53 | funman | offset bug ? I don't think removing an empty section would have any effect |
| 12:41:41 | Unhelpful | funman: look up a bit to my discussion w/ amiconn regarding very funny goings-on with newer binutils ;) |
| 12:42:39 | Unhelpful | basically 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:55 | funman | I see |
| 12:44:11 | Unhelpful | no idea why. it's happening with newer binutils since 2.19 snapshots or so. :/ |
| 12:45:12 | Unhelpful | especially 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:48 | funman | did you check the .elf file? |
| 12:47:21 | Unhelpful | not very closely, i looked at the address for iramcopy and the .iram load address in the .map files. |
| 12:48:59 | funman | I wonder how helpful the binutils developers would be to help debug this :/ |
| 12:49:22 | Unhelpful | i compared disassemblies between the revisions where vorbis stopped working for me, and noted that some addresses were different, but not much else. |
| 12:49:54 | Unhelpful | i 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:38 | Unhelpful | yay, vorbis no longer skips tracks, and mp3 no longer crashes. :) |
| 12:55:57 | Unhelpful | hrm, 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:28 | amiconn | Unhelpful: ALIGN (0x10) |
| 12:57:28 | funman | Unhelpful: there's no .ncdata in fuze core app |
| 12:57:39 | amiconn | ..is supposed to do exactly that |
| 12:57:44 | amiconn | Sounds 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:48 | amiconn | Unhelpful: Maybe it doesn't like the mix of calculation within output sections and outside them? |
| 13:06:46 | amiconn | The alignment happens inside .ncdata, but the calculation of iramcopy happens outside |
| 13:07:16 | funman | the problem is only here when .ncdata is empty ? |
| 13:09:06 | amiconn | Unhelpful: What happens if you pull the second . = ALIGN(CACHEALIGN_SIZE); |
| 13:09:29 | amiconn | ...outside the output section (but keep it inside the #ifdef)? |
| 13:09:46 | amiconn | @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:15 | NHeal | (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:38 | Unhelpful | funman: 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:13 | Unhelpful | amiconn: 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:44 | Scotty1975 | Hi, can anyone tell me if Rockbox can be used to update a SONY NW-S202 512Mb DMP? |
| 13:38:58 | B4gder | Scotty1975: see rockbox.org (no it can't) |
| 13:39:50 | Scotty1975 | Without reading that, can u say why? :{ |
| 13:40:03 | B4gder | sure, because nobody did the necessary work |
| 13:40:09 | Scotty1975 | lol |
| 13:40:16 | amiconn | Unhelpful: Obviously not, as it needs to come after that section... |
| 13:40:20 | Scotty1975 | will they in future? |
| 13:40:24 | B4gder | Scotty1975: they? |
| 13:40:31 | B4gder | sony? |
| 13:40:31 | Unhelpful | Scotty1975: if somebody does the necessary work. ;) |
| 13:40:58 | Scotty1975 | cool, cheers |
| 13:41:23 | Scotty1975 | goddam slackers @ SONY :{ |
| 13:41:32 | Unhelpful | amiconn: "after"? but isn't its address before it (- NOCACHDATA_SIZE or whatever)? |
| 13:41:48 | amiconn | No it's not |
| 13:41:50 | Unhelpful | Scotty1975: somebody who owns one has to work on it. :) |
| 13:42:06 | Scotty1975 | I would if I knew anything about coding |
| 13:42:08 | amiconn | NOCACHEDATA_SIZE is 0x10000000, i.e. the offset |
| 13:42:19 | B4gder | Scotty1975: a new rockbox port is a lot of work for a long time |
| 13:42:51 | amiconn | But if .ncdata is not empty, the iramcopy needs to come after that (or more precisely, after its "mirror" in the cached area) |
| 13:43:13 | Scotty1975 | ok guys, maybe I'll just buy a DMP that already has support then |
| 13:43:28 | B4gder | that's way easier, yes ;-) |
| 13:43:53 | Scotty1975 | l8erz :{} |
| 13:44:07 | Unhelpful | B4gder: 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:37 | B4gder | I'm sure hunting down an already supported player still is easier than doing a new port |
| 13:44:52 | B4gder | if a bit different |
| 13:46:04 | | Quit antil33t () |
| 13:52:20 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 13:53:05 | CIA-15 | New commit by teru (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:08 | Unhelpful | amiconn: 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:16 | amiconn | Removing 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:28 | amiconn | I already made a suggestion, did you try that? |
| 14:11:24 | Unhelpful | i'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:10 | FlynDice | funman: ping |
| 17:05:25 | funman | pong |
| 17:05:51 | FlynDice | Hi, 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:14 | FlynDice | Is ththat number arrived at for a reason? |
| 17:06:21 | FlynDice | the 10 I mean... |
| 17:06:51 | funman | "a bit but not too much" |
| 17:07:17 | funman | now i've seen mentioned here that a lot of code would only transfer 1 sector at a time |
| 17:07:28 | funman | (not including test_disk) |
| 17:07:48 | FlynDice | I've found that by increasing it the copy times fom disk to disk are cut by almost 50 % |
| 17:07:49 | funman | it should not be too big to not eat too much bin size |
| 17:08:13 | funman | iirc 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:22 | NSplit | lindbohm.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:31 | FlynDice | would 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:39 | polobricolo | in thread.c, where are r0, r1 and r2 stored |
| 17:08:52 | | Join preglow [0] (i=thomj@129.241.210.199) |
| 17:08:57 | funman | it would impact every model |
| 17:09:03 | funman | the 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:11 | NHeal | lindbohm.freenode.net irc.freenode.net |
| 17:09:11 | NJoin | SUSaiyan [0] (n=SUSaiyan@cc84863-b.zwoll1.ov.home.nl) |
| 17:09:12 | polobricolo | the reg struct contains only r4-r11 sp or lr |
| 17:09:22 | polobricolo | *and lr |
| 17:09:43 | | Join CIA-6 [0] (n=CIA@208.69.182.149) |
| 17:10:38 | Bob_C_ | FlynDice: What size did you increase it to? |
| 17:10:49 | *** | Saving seen data "./dancer.seen" |
| 17:10:55 | funman | polobricolo: it seems all the scratch registers (r0-r3, r12) aren't stored but i'm not sure why |
| 17:10:58 | n1s | polobricolo: giving more context or lines in the file might help people know what you are looking for |
| 17:11:03 | FlynDice | well I tried all the way up to 127... |
| 17:11:09 | n1s | s/for/at/ |
| 17:11:47 | | Quit funman ("free(random());") |
| 17:11:51 | FlynDice | Bob_C_: at 127 it took half the time to copy from 1 disk to the other |
| 17:13:25 | FlynDice | I 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:35 | NJoin | jasio [0] (n=yann@cpc2-rdng20-2-0-cust902.15-3.cable.virginmedia.com) |
| 17:14:35 | Bob_C_ | Larger transfers will give better throughput, the question is whether the extra memory used could be better used for something else |
| 17:15:15 | FlynDice | I 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:55 | FlynDice | Bob_C_: Yes, that's why I'm asking... |
| 17:16:39 | domonoky | Bob_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:17 | Bob_C_ | Sure, I understand. I am interested because I borrowed most of the code from the as2525 SD driver for the mini2440 |
| 17:18:19 | Bob_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:25 | NJoin | lyngaas [0] (n=staale@19.81-167-149.customer.lyse.net) |
| 17:19:26 | domonoky | ah ok, do you know which dma channel this uses ? |
| 17:19:39 | n1s | gevaerts: 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:24 | gevaerts | n1s: I have a machine that can do all normal builds in slightly more than half an hour, yes |
| 17:20:36 | gevaerts | (access to) |
| 17:20:45 | n1s | no sims? |
| 17:20:55 | Bob_C_ | domonoky: I believe dma-target.h has that, but the channels are hard-coded in places |
| 17:21:13 | gevaerts | n1s: it does all builds, but I don't know how long sims take |
| 17:21:48 | n1s | gevaerts: would you test build the sims with a patch i've made? |
| 17:22:00 | gevaerts | sure |
| 17:22:24 | Bob_C_ | domonoky: pcm should use channel 2 in both gigabeat/mini2440 I think |
| 17:22:41 | n1s | great :) |
| 17:23:01 | domonoky | oki, so channel 3 and 4 are free at moment. :-) |
| 17:23:20 | Bob_C_ | domonoky: or 1 and 3? |
| 17:24:14 | | Quit aaron424 (Remote closed the connection) |
| 17:24:28 | domonoky | Bob_C_: you are right |
| 17:25:07 | | Quit TopyMobile (Read error: 60 (Operation timed out)) |
| 17:25:23 | Bob_C_ | domonoky: what is your plan? |
| 17:26:32 | domonoky | thinking about usb support. will see how far i can get, as i dont know much about usb at moment :-) |
| 17:26:59 | n1s | gevaerts: 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:59 | gevaerts | n1s: what do you want built? Just all sims, or also the normal builds? |
| 17:31:15 | gevaerts | or everything? |
| 17:31:15 | | Quit HBK () |
| 17:31:16 | n1s | gevaerts: all sims should be enough |
| 17:32:09 | n1s | Everything Else Should Be Unaffected (tm) |
| 17:32:21 | Bob_C_ | domonoky: cool, some USBness would be handy |
| 17:32:48 | gevaerts | n1s: "should"? :) Also, do you just want compile issues, or do I have to keep the files? |
| 17:34:08 | n1s | gevaerts: i just want to know if the sims compile cleanly, nothing in their function should have changed |
| 17:34:12 | gevaerts | ok |
| 17:34:24 | * | gevaerts presses enter |
| 17:34:26 | n1s | so , go a head and throw everything away |
| 17:34:35 | n1s | \o/ |
| 17:34:40 | Bob_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:10 | n1s | s/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:35 | gevaerts | n1s: 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:46 | n1s | ok, cheers |
| 17:39:26 | kugel | FlynDice: 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:38 | kugel | flydutch: on 8MB the unaligned buffer could be in IRAM, that's hardly used so far |
| 17:40:42 | kugel | FlynDice: ^ |
| 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:10 | gevaerts | n1s: 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:17 | FlynDice | kugel: 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:29 | kugel | definitely |
| 18:18:04 | kugel | if 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:38 | kugel | FlynDice: 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:31 | kugel | it might not be worth/useful for 2MB, but I'd say it's good for 8MB |
| 18:25:49 | n1s | gevaerts: 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:28 | FlynDice | kugel: 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:33 | gevaerts | n1s: 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:37 | kugel | FlynDice: mounting fails if I put it in iram |
| 18:59:16 | FlynDice | kugel: Ha Ha, I just tried that too and was looking over UNCACHED_ADDR and mapping stuff in system-as3525.... |
| 18:59:25 | kugel | FlynDice: 1MB is much faster with a bigger buffer |
| 18:59:49 | kugel | strangely, uncached seems to be faster with SVN for 4k chunks |
| 19:00 |
| 19:01:00 | FlynDice | kugel: 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:31 | kugel | the audio buffer fills as fast as possible |
| 19:01:52 | kugel | it only stops shorty after each file |
| 19:03:07 | kugel | iram 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:52 | GodEater | anyone have any idea what pamaury wanted from me last night? |
| 19:12:47 | | Quit freddyb (Read error: 60 (Operation timed out)) |
| 19:13:43 | seani | Folks, 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:20 | GodEater | wth has happened to my source tree? :( |
| 19:15:51 | kugel | FlynDice: if you're bored, you could find out why the samsas panic at boot if you build rockbox with eabi |
| 19:17:01 | FlynDice | of course I woul have to google eabi first..... |
| 19:18:00 | kugel | the first result for "arm eabi" gives a pretty good overview |
| 19:22:02 | FlynDice | I 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:07 | kugel | FlynDice: any idea why we block while wakeup_wait in the sd driver? |
| 19:42:45 | FlynDice | nope, have wondered myself an not asked funman yet..... |
| 19:44:21 | kugel | FlynDice: ok, I see why iram doesn't work |
| 19:45:23 | kugel | dma 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:45 | funman | FlynDice: 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:07 | funman | IIUC 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:26 | funman | the patch they are working on should just make that, so when it's finished we could remove the need for this buffer |
| 19:47:02 | funman | it 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:27 | kugel | funman: what problem/question are you refering too? |
| 19:48:44 | funman | enlarge/move the aligned buffer used in Sansa AMS SD driver |
| 19:49:36 | funman | kugel: we block in wakeup_wait because we wait for the transfer to be finished before returning, isn't it obvious ? |
| 19:50:08 | kugel | IIRC, the current thread is always blocked, the block parameter is about whether to block other threads |
| 19:50:51 | funman | oh .. |
| 19:52:00 | bertrik | kugel, really? |
| 19:52:09 | bertrik | I thought this meant how long to wait |
| 19:52:17 | kugel | looking at wakeup_wait, I'm not sure |
| 19:52:20 | funman | btw wakeup_wait has a return value that we don't check |
| 19:52:24 | bertrik | so TIMEOUT_BLOCK basically means to wait forever |
| 19:52:49 | | Quit AlexP (Remote closed the connection) |
| 19:53:26 | bertrik | funman, I am confused a bit by function sd_wait_for_state |
| 19:53:29 | funman | Well block_thread() only blocks the current thread |
| 19:53:55 | funman | * 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:18 | funman | bertrik: what does confuse you in the function ? |
| 19:54:30 | bertrik | It 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:52 | bertrik | Why is that? |
| 19:55:01 | | Join Rob2222 [0] (n=Miranda@p4FDCC8BE.dip.t-dialin.net) |
| 19:55:36 | funman | no idea, it looks wrong |
| 19:55:56 | | Quit AEnima15771 (Read error: 110 (Connection timed out)) |
| 19:55:59 | bertrik | If we just set a simple deadline, the code can be much simpler |
| 19:56:30 | funman | I must have made the mistake when converting the code from PP which uses USEC and not ticks |
| 19:57:56 | funman | we 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:26 | funman | when 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:31 | FlynDice | As 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:44 | domonoky1 | TheSeven: i am just looking at the usb-s3c6400 code, and wonder: is it correct that usb_init_device() calls usb_drv_exit() ? |
| 20:18:25 | TheSeven | domonoky1: not sure, but i would expect that to be somewhere in a #ifndef USE_ROCKBOX_USB |
| 20:18:59 | domonoky1 | it is, but i wonder about a init function calling a exit function. |
| 20:19:46 | TheSeven | ifNdef |
| 20:19:55 | | Quit domonoky (Read error: 60 (Operation timed out)) |
| 20:20:02 | domonoky1 | or is this wanted, so usb is powered down at bootup ? |
| 20:20:09 | TheSeven | exactly. |
| 20:20:19 | domonoky1 | ah, now i understand :-) |
| 20:20:36 | TheSeven | if we don't use rockbox usb, we don't need to care about that controller, so we just shut it off |
| 20:20:57 | TheSeven | (and we do the same while it's disconnected, even if USE_ROCKBOX_USB is defined) |
| 20:21:10 | TheSeven | the usb controller accounts for more current than the whole rest of the ipod |
| 20:23:05 | domonoky1 | oki, thanks for the info.. i am just looking at it, to maybe copy some of the logic for mini2440 :-) |
| 20:25:56 | domonoky1 | at 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:29 | bluebroth3r | hmm. 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:46 | linuxstb | bluebrother: 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:26 | bluebrother | linuxstb: I guessed that :) |
| 22:38:03 | linuxstb | bluebrother: Just confirming... ;) |
| 22:38:23 | bluebrother | do you think it would be acceptable to change to some "make RBARCH=w32" instead of "make sansapatcher.exe"? |
| 22:38:34 | bluebrother | s/some/something like/ |
| 22:39:47 | linuxstb | I 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:27 | bluebrother | hmm, 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:44 | notlistening | domonoky1, 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:36 | domonoky1 | notlistening: not really, i didnt found the time and motivation to work at it.. but i hope to continue it sometime :-) |
| 22:48:09 | notlistening | no worries i have seen your busy on another player ;) |
| 22:49:15 | notlistening | Well 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:21 | domonoky1 | two things come in mind. startup speed (especially on linux) and binary size would be nice if it could be improved :-) |
| 22:50:02 | notlistening | lol he wants the world ;D |
| 22:50:48 | domonoky1 | :-) |
| 22:52:05 | notlistening | I 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:41 | notlistening | I will add them to the wish list |
| 22:52:51 | notlistening | How is the mini going? |
| 22:53:43 | domonoky1 | pretty 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:15 | notlistening | yeah 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:06 | freddyb | Is 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:28 | domonoky1 | notlistening: if someone would write the networkdriver, i will port lwip to rockbox :-) |
| 22:58:16 | freddyb | Has anyone (besides FlynDice) tried my keyboard patch for scroll wheel models? (FS #10763) |
| 22:58:19 | bertrik | I don't see the point of networking in rockbox, but everybody's free to try of course |
| 22:59:54 | domonoky1 | bertrik: 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:00 | bertrik | a coworker did smb on top of lwip on a 8051-type processor once, he claimed it wasn't actually that complex |
| 23:01:55 | LambdaCalculus37 | bertrik: Networking in Rockbox would be more useful if we ever got a Rio Karma port started. |
| 23:02:02 | notlistening | well if there are players that are supporting network interfaces then networking become a viable option for rockbox |
| 23:02:18 | Bagder | isn't there already networking-over-usb things? |
| 23:02:38 | notlistening | when you run through the usecase of having a rockbox based in car player or home audio system |
| 23:04:04 | notlistening | does 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:22 | Torne | Bagder: yeah, we could implement a usb network endpoint and then people could use smb or similar instead of mtp/msc |
| 23:06:25 | Torne | :) |
| 23:06:53 | Torne | might be considered preferable to mtp by soem people for using devices that cna't be exported as msc.. |
| 23:07:02 | Torne | (real flash filesystems) |
| 23:07:27 | Bagder | right, but which can't be msc but can be a network endpoint? |
| 23:07:40 | gevaerts | Torne: do you actually see a real reason to prefer smb over mtp? |
| 23:07:57 | bertrik | notlistening, as far as I know, there is no exactly defined scope of what rockbox should be limited to |
| 23:08:27 | Bagder | everyone's scope is slightly different ;-) |
| 23:08:28 | Torne | Bagder: well we don't have any targets taht can't do MSC atm |
| 23:08:41 | Torne | but various people seem to be slightly interested in flash FSes and the like |
| 23:08:44 | notlistening | another quick question GPL v2 vs GPL3 why can you not include code from a GPL3 project? |
| 23:08:52 | Bagder | we can |
| 23:08:59 | Bagder | but then we'd have to be gplv3 |
| 23:09:35 | Bagder | and we're not in agreement that's where we want to go |
| 23:10:23 | notlistening | ahh okay the higher liscence takes presidence |
| 23:10:58 | gevaerts | not as such |
| 23:10:59 | *** | Saving seen data "./dancer.seen" |
| 23:11:08 | Bagder | the effect is such at least |
| 23:11:23 | gevaerts | It's just that if one part of the code is "v2 or higher" and another is "v3", the whole is v3 |
| 23:12:03 | gevaerts | hypothetically speaking you could have a strict v2 project and a v3-or-lower project that combine to a v2 project... |
| 23:13:15 | notlistening | So 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:12 | notlistening | http://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:17 | n1s | notlistening: yes, as is explained in that task |
| 23:15:47 | n1s | what is unfortunate is that the espeak eveloper did not seem to think this was a problem |
| 23:15:57 | n1s | s/eve/deve |
| 23:16:49 | notlistening | ok, i was just trying to understand more than "you just can't" |
| 23:17:45 | Bagder | well, read the licenses ;-) |
| 23:18:17 | n1s | in 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:00 | notlistening | Got it |
| 23:19:30 | n1s | ... go with v3 for rockbox, a for or unofficial build could do this |
| 23:19:35 | n1s | forK |
| 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:53 | amiconn | Correct |
| 23:34:28 | amiconn | In fact yield() is just a normal function call in cooperative threading, so no need to save scratch registers |
| 23:34:36 | amiconn | (in yield()) |
| 23:35:03 | Unhelpful | except that we "return" to where somebody else called yield ;) |
| 23:35:35 | amiconn | As 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:11 | CIA-6 | New commit by bertrik (r23544): Meizu M6SP: initialise and use SDRAM |
| 23:48:56 | | Quit n1s ("Lämnar") |
| 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) |
icon identifies that the person is a core developer (has commit access).