| 00:03:16 | | Join lasser [0] (n=chatzill@Wac10.w.pppool.de) |
| 00:05:49 | | Quit petur (Remote closed the connection) |
| 00:08:44 | | Quit toffe82 (Read error: 110 (Connection timed out)) |
| 00:09:02 | | Quit wingmanz (Read error: 110 (Connection timed out)) |
| 00:12:40 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 00:14:56 | | Quit tyfoo2 ("Carpe diem") |
| 00:15:14 | funman | doesn't 'i2sout' sound like 'made to play pcm' ? |
| 00:17:53 | funman | The interface in Sansa AMS look simple enough. It uses DMA (and it seems we can put the DMA code in common with the SD driver) |
| 00:21:07 | kugel | funman: I didn't really have success with that CCU_IO removed |
| 00:21:14 | kugel | on my fuze with microsd |
| 00:24:45 | funman | kugel: the state of this register didn't change on your fuze, if you have problems with it then the bug is elsewhere |
| 00:24:59 | | Quit FOAD (Read error: 110 (Connection timed out)) |
| 00:24:59 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 00:26:26 | funman | note that the code is 'filled' with calls panicf() to ease debugging |
| 00:29:39 | | Quit MethoS- (Remote closed the connection) |
| 00:30:25 | | Quit bluebrother ("leaving") |
| 00:37:50 | | Quit faemir (Remote closed the connection) |
| 00:43:57 | | Quit ender` (" Intelligence is the ability to avoid doing work, yet getting the work done. -- Linus Torvalds") |
| 00:44:55 | | Quit lasser ("ChatZilla 0.9.83 [Iceweasel 3.0.3/2008092816]") |
| 00:46:05 | Unhelpful | jhMikeS: i see that, looking at the patch. i thought you'd meant cross-fading or fade-on-stop, sorry. |
| 00:47:23 | | Quit jhulst (Read error: 104 (Connection reset by peer)) |
| 00:47:40 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 00:49:50 | soap | RomanGwizdz appears to be be using the wiki as rapidshare, currently. |
| 00:50:18 | soap | uploaded a non-compliant theme, made no entry for it, just attached the files. |
| 00:55:56 | | Join Cristatus [0] (n=Cristatu@163.14-200-80.adsl-dyn.isp.belgacom.be) |
| 00:56:04 | | Quit bertrik ("Leaving") |
| 00:56:17 | Cristatus | how do i sent files to my recently rockboxed ipod G4? |
| 00:56:28 | Cristatus | *send |
| 00:56:48 | Cristatus | (i know it's a stupid question, but i can't find the answer anywhere) |
| 00:57:40 | funman | just copy the files in the ipod folder |
| 00:57:55 | funman | no need to use a specific software like itunes, use the software of your choice |
| 00:58:02 | Cristatus | just drop it in in the root? |
| 00:58:21 | funman | drop it where you want |
| 00:58:25 | Cristatus | i see |
| 00:58:37 | Cristatus | also, it's an ipod photo, can i play videos with it now? |
| 00:59:09 | funman | i'm not sure, just check the manual it should have all the details |
| 00:59:30 | Unhelpful | look here for video info: http://www.rockbox.org/twiki/bin/view/Main/PluginMpegplayer |
| 00:59:50 | Unhelpful | the performance numbers may be out-of-date. the rest is pretty much true, to my knowledge. |
| 01:00 |
| 01:01:37 | Cristatus | aw crap |
| 01:01:40 | | Quit tessarakt ("Client exiting") |
| 01:01:41 | Cristatus | i can only play mpg? |
| 01:02:12 | Cristatus | how do i convert an mp4 to mpg? |
| 01:02:22 | jhMikeS | Unhelpful: not every refinement was done but it should fade for on/off |
| 01:04:40 | | Join ubuntu [0] (n=ubuntu@host220-183-dynamic.53-79-r.retail.telecomitalia.it) |
| 01:05:01 | | Quit herrwaldo (Read error: 131 (Connection reset by peer)) |
| 01:05:26 | Cristatus | on vista |
| 01:06:18 | | Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) |
| 01:06:36 | funman | Cristatus: look the bottom of the wiki page |
| 01:08:04 | Cristatus | i don't see anything about conversion o_O |
| 01:08:41 | funman | I do : "How to encode files" |
| 01:13:10 | ubuntu | nothing for archos AV320? |
| 01:13:24 | Llorean | ubuntu: No. |
| 01:14:07 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 01:14:50 | ubuntu | very sad... rockbox is very nice, a very cool project... |
| 01:15:13 | ubuntu | and i miss in my archos AV320 a flac support |
| 01:18:28 | | Quit ubuntu (Client Quit) |
| 01:18:34 | | Join darkhamm [0] (n=ubuntu@host220-183-dynamic.53-79-r.retail.telecomitalia.it) |
| 01:22:31 | | Quit reacocard (".") |
| 01:26:49 | | Join simongmzlj [0] (n=simongmz@76-10-132-131.dsl.teksavvy.com) |
| 01:28:55 | | Join homielowe [0] (n=homielow@d206-116-134-81.bchsia.telus.net) |
| 01:29:42 | | Quit funman ("leaving") |
| 01:29:54 | | Join toffe82_ [0] (n=chatzill@ppp-71-130-79-83.dsl.frs2ca.pacbell.net) |
| 01:30:01 | | Nick toffe82_ is now known as toffe82 (n=chatzill@ppp-71-130-79-83.dsl.frs2ca.pacbell.net) |
| 01:30:10 | Nico_P | jhMikeS: have you started investigating the IPU on the S? |
| 01:34:13 | | Quit simongmzlj (Remote closed the connection) |
| 01:35:38 | | Part Cristatus |
| 01:36:45 | | Join einhirn [0] (i=Miranda@p5B033904.dip0.t-ipconnect.de) |
| 01:37:29 | | Join miepchen^schlaf [0] (n=miepchen@p579EC5C7.dip.t-dialin.net) |
| 01:39:09 | | Quit Nico_P (Remote closed the connection) |
| 01:39:46 | | Quit einhirn (Client Quit) |
| 01:41:22 | | Join einhirn [0] (i=Miranda@p5B033904.dip0.t-ipconnect.de) |
| 01:44:56 | | Quit darkhamm (Client Quit) |
| 01:46:29 | *** | Saving seen data "./dancer.seen" |
| 01:55:20 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 01:59:34 | | Quit jhulst (Remote closed the connection) |
| 02:00 |
| 02:02:56 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 02:07:39 | | Quit Thundercloud (Remote closed the connection) |
| 02:15:58 | | Join tchan1 [0] (n=tchan@c-24-12-190-140.hsd1.il.comcast.net) |
| 02:16:34 | | Quit tchan (Read error: 60 (Operation timed out)) |
| 02:25:46 | | Quit tvelocity ("Αποχώρησε") |
| 02:27:08 | | Join webguest92 [0] (n=430aeeaf@gateway/web/cgi-irc/labb.contactor.se/x-53bd9222c3e499f8) |
| 02:27:14 | | Quit webguest92 (Client Quit) |
| 02:28:12 | | Part Llorean |
| 02:38:09 | | Join webguest70 [0] (n=4d152bae@gateway/web/cgi-irc/labb.contactor.se/x-83d11c9cf8286bd2) |
| 02:39:47 | kugel | jhMikeS: ping! I added a comment on fs#6800 (backlight fading) |
| 02:39:50 | | Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.4/2008102920]") |
| 02:43:31 | | Quit webguest70 ("CGI:IRC (Ping timeout)") |
| 02:54:17 | | Join perrikwp [0] (i=d1a8d351@gateway/web/ajax/mibbit.com/x-e3089d9d95195e95) |
| 02:58:18 | | Part pixelma |
| 02:58:29 | | Join pixelma2 [0] (n=marianne@rockbox/staff/pixelma) |
| 03:00 |
| 03:01:35 | | Join Llorean [0] (n=DarkkOne@ppp-70-242-15-169.dsl.hstntx.swbell.net) |
| 03:05:02 | | Quit aarcane ("Leaving") |
| 03:08:58 | | Quit homielowe () |
| 03:15:11 | Unhelpful | thinking about the aliasing artifacts in the area scaler, it looks like the options if staying with the area scaler are to either overlap the areas (probably very difficult to implement in this design, as-is), or to blur the output data as a separate step, something that can probably be done with one or two ouput-width lines of extra data |
| 03:15:50 | Unhelpful | the second will be easier, and the amount of blurring will be the same each time, because it's done in the output space. but maybe i should look to a different filter method entirely. |
| 03:17:08 | saratoga | Unhelpful: I don't think some aliasing is intolerable, particularly given how small and low quality most device screens are |
| 03:17:22 | saratoga | for larger, faster devices, a better resizer should probably be used |
| 03:17:30 | saratoga | depending of course on memory and cpu availability |
| 03:18:22 | | Nick tchan1 is now known as tchan (n=tchan@c-24-12-190-140.hsd1.il.comcast.net) |
| 03:18:51 | Unhelpful | saratoga: it gets possibly ugly, at that point. lanczos will be *very* ugly to do "for real", because it's essentially a kernel filter with values derived from the distance of the contributing source pixels from the destination, and using sines. |
| 03:19:20 | saratoga | initially i'd be happy with just a simple linear interpolator |
| 03:19:33 | saratoga | lancoz is complete overkill for our needs |
| 03:19:40 | Unhelpful | saratoga: in the downscaling case, isn't linear pretty much the same as area? |
| 03:22:10 | saratoga | i think area has better alias rejection |
| 03:23:34 | saratoga | linear is basically just decimation |
| 03:26:57 | Unhelpful | hrm, you're right, if it's bilinear from just the neighbor source pixels. |
| 03:28:11 | saratoga | i think the first step is to just get some sort of resizing in place thats efficient and light enough on memory for all bitmap targets to use |
| 03:28:28 | saratoga | then we can look into more appealing forms of resampling |
| 03:29:07 | Unhelpful | would somebody more inside of rockbox be able to help a little bit with actually putting my sample filter into rockbox, in that case? |
| 03:29:33 | Unhelpful | s/sample/area/ |
| 03:30:02 | Unhelpful | well, i mean, refactoring it from a demo app to something that can be tested inside rb. not outright merging it. :) |
| 03:31:56 | saratoga | Unhelpful: we don't have anything at all setup for doing resizing at the moment |
| 03:32:13 | saratoga | the first thing the patch for resizing does is add all that |
| 03:32:36 | saratoga | so whenever that is included, it should be straightforward for you to experiment with other resize code |
| 03:32:39 | Unhelpful | i believe there was some objetion to the weight of the scaler itself, though? |
| 03:32:50 | saratoga | yes the cost is quite high, ~ 20KB |
| 03:33:07 | saratoga | although that includes both bilinear and area sampling w/ 5 lines |
| 03:33:23 | saratoga | i think dropping area sampling on some targets would save at least 5KB |
| 03:34:33 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 03:35:13 | Unhelpful | now, since metadata-on-buffer, there's still not a real malloc, but it would be possible to grab some buffer space while loading an image with other metadata, and free it when the scaling is complete? |
| 03:36:38 | | Join n17ikh|Lappy [0] (n=n17ikh@130-127-73-84.lightsey.resnet.clemson.edu) |
| 03:37:52 | saratoga | Unhelpful: you'd probably have to ask Nico_P about that |
| 03:38:32 | Unhelpful | if not, we could assume that we're never scaling to a size greater than the target display, and have a fixed buffer in that size. |
| 03:38:49 | linuxstb | Making the resizing dependent on the audio buffer would limit its use to only album art though, and I'm not sure it's worth the effort. |
| 03:42:24 | Unhelpful | linuxstb: that's a good point. the area scaler can be done on <scale> input lines, with 10x<owidth> bytes of buffer... so, a fixed buffer on a 240-wide target would be ~2.4KB of permanent buffer. |
| 03:42:36 | Llorean | linuxstb: I'm not sure there are many other in-core uses for scalable images. |
| 03:42:42 | Llorean | The only other one I can think of are iconsets. |
| 03:43:03 | Unhelpful | probably should use the larger dimension of the target display, in case the image is wanted rotated? |
| 03:43:05 | Llorean | And that can be solved a different way (including prescaled default iconset for each font size, in case the theme doesn't include one) |
| 03:43:14 | Llorean | "each font size" being "each official font size" |
| 03:43:16 | linuxstb | Maybe backdrop, especially when jpeg support is in the core. |
| 03:43:54 | linuxstb | But jpeg may need different buffering anyway... |
| 03:44:12 | Unhelpful | i think scaling a backdrop when you install it on a target is not so horrid, compared to scaling album art per-album |
| 03:44:59 | Unhelpful | linuxstb: if the destination buffer is already reserved, though, you can rotate line-by-line as you copy from the scaler line buffer to the output buffer |
| 03:45:38 | Unhelpful | or even hand the scaler line and pixel strides for the destination buffer that are reversed, and let it write final output straight to the image buffer |
| 03:46:22 | linuxstb | But yes, in theory you could grab space from the audio buffer - I think the earlier version of the resize patch did that. |
| 03:46:32 | *** | Saving seen data "./dancer.seen" |
| 03:46:35 | linuxstb | Although I don't know how reliable it was. |
| 03:48:07 | Unhelpful | with output direct to an image buffer, scaler buffer could be 8x<owidth>, plus whatever the line of input it's reading from takes up. |
| 03:48:27 | saratoga | grabbing space is always nice since it saves space for people who don't want album art |
| 03:49:49 | Unhelpful | if we assume that that's the only place the scaler will be used, i'd say that's the way to go |
| 03:50:22 | Unhelpful | assuming a graceful failure can be managed on buffer shortage - presumably we can say there's not enough room, and RB will try to load the stuff again later? |
| 03:51:38 | Llorean | There shouldn't ever be buffer shortages as long as you load the image *before* buffering the associated song. |
| 03:51:57 | | Quit DerDome (Read error: 110 (Connection timed out)) |
| 03:52:05 | | Join DerDome [0] (n=DerDome@dslb-082-083-218-228.pools.arcor-ip.net) |
| 03:52:24 | Llorean | Or rather, the only shortage would be on the last image, which you then just give up on and do at the beginning of the next rebuffer, right? |
| 03:54:35 | Unhelpful | Llorean: it sounds like you're saying it would/could do what i said, basically, then? provided the image scaler can pass notice of the failure up? |
| 03:55:12 | Llorean | I don't know. |
| 03:55:52 | linuxstb | Shouldn't it be the other way around? i.e. the buffering code passes a temporary buffer to the read_bmp function? |
| 03:56:45 | Llorean | linuxstb: Wouldn't you need two things: a destination in the audio buffer for the post-scale image, and then a temporary buffer immediately after it that's for temporary use in the scaling? |
| 03:57:04 | linuxstb | Yes |
| 03:57:24 | Unhelpful | Llorean: that would be the case. and the temp buffer space will depend in part on the line size of the input. |
| 03:58:06 | Unhelpful | i *need* a whole line at a time, as this it written. i could do instead with the ability to reset the reader to the start of a specific line. |
| 03:58:18 | linuxstb | Thinking about future jpeg support, I'm thinking of a "preload_image" function that will open the file, parse the header, and return the sizes of buffers the main decoding code will need. The calling function is then responsible for allocating those buffers, and then calling the decode/scale functions. |
| 03:58:23 | Unhelpful | hrm, actually, no, i think i could take a line in chunks. |
| 03:59:05 | | Join webguest041 [0] (n=46f11d5c@gateway/web/cgi-irc/labb.contactor.se/x-559a6b38763a3dae) |
| 03:59:11 | Llorean | Since it's a temporary buffer anyway, I don't think we need to worry much about its size. |
| 03:59:13 | webguest041 | hello |
| 03:59:37 | Llorean | If there's not enough room for a single line of the image, then the amount of free buffer is probably too small for practical buffering of audio either, so it'd be okay to end this rebuffer loop I imagine. |
| 03:59:45 | Unhelpful | linuxstb: a jpeg decoder should be able to do with srcwidth*8 bytes of buffer, or srcheight*8 (i can't remember if jpeg stores blocks row-first or column-first) |
| 04:00 |
| 04:01:40 | | Quit webguest041 (Client Quit) |
| 04:01:46 | Unhelpful | and you can potentially quarter the decoder's needed buffer for each power-of-two scale factor, up to 1/8 |
| 04:21:14 | | Quit einhirn (Read error: 104 (Connection reset by peer)) |
| 04:23:27 | | Join blkhawk- [0] (n=blkhawk@e176228166.adsl.alicedsl.de) |
| 04:26:22 | | Join SpeakerMania [0] (n=Steven--@71-33-164-194.hlrn.qwest.net) |
| 04:27:02 | SpeakerMania | Is there any ongoing development on the iPod Touch? |
| 04:27:33 | Llorean | Not really, no. |
| 04:27:45 | Unhelpful | SpeakerMania: to my knowledge, there's no progress at all running custom OS code on the device. |
| 04:28:12 | SpeakerMania | Is there a clear reason for this? (ie, lack of hardware, general confusion about the actual hardware, etc) |
| 04:28:47 | Llorean | SpeakerMania: Nobody who's actually interested in it has done the work. |
| 04:29:09 | Unhelpful | Llorean: that's a target with firmware signing and encryption as well, is it not? |
| 04:29:13 | SpeakerMania | That's a shame. :( |
| 04:29:17 | Llorean | Unhelpful: Rockbox could be run as an app though |
| 04:29:32 | Llorean | SpeakerMania: Well, you could be the one to begin work on it. |
| 04:29:36 | Unhelpful | Llorean: certainly not via the store... |
| 04:29:46 | Unhelpful | they don't like "duplicate" functionality |
| 04:30:00 | Llorean | Unhelpful: yeah, but if I understand, jailbreaking is more or less trivial these days |
| 04:30:32 | SpeakerMania | Llorean: Unfortunately all I know is the basics of Small Basic (lol), but I program extensively in PHP which I hear is similar to C, etc. |
| 04:30:45 | Unhelpful | i believe you can also load custom apps with the devkit, if you agree to the terms, and use MacOS |
| 04:31:05 | Unhelpful | PHP is not very much like C, except in some of the syntax. |
| 04:31:15 | Llorean | SpeakerMania: "The amount of time it takes to learn and do it" is still a lot shorter than "never" |
| 04:31:23 | Unhelpful | and this is getting pretty off-topic |
| 04:31:38 | SpeakerMania | Llorean: Indeed. |
| 04:31:47 | SpeakerMania | Off-topic? |
| 04:31:49 | SpeakerMania | ^_^ |
| 04:33:57 | Unhelpful | SpeakerMania: PHP, details of iPhone app installation, are not related to rockbox itself. but if you want me to rant at you about PHP's warts, you can join #rockbox-community |
| 04:36:12 | | Quit jhulst (Remote closed the connection) |
| 04:38:02 | | Join miepchen^schlaf_ [0] (n=miepchen@p579ECC64.dip.t-dialin.net) |
| 04:40:00 | | Quit blkhawk (Read error: 113 (No route to host)) |
| 04:40:25 | | Nick blkhawk- is now known as blkhawk (n=blkhawk@e176228166.adsl.alicedsl.de) |
| 04:41:34 | Unhelpful | Llorean: say, a handle, a callback function that gets one line of data, the start of the buffer, the available space, and the input dimensions and output constraints could be passed to the scaler? that leaves flexibility for using any format loadable in-core. the scaler can return the quantity of buffer used by the output image, or 0 on failure. |
| 04:41:46 | | Join gregorovius [0] (n=diego@host128.190-31-14.telecom.net.ar) |
| 04:42:28 | gregorovius | Hi... I remember there was some info somewhere on the wiki about player sizes, but I can't find it... any hints? |
| 04:42:44 | Unhelpful | storage sizes? |
| 04:42:57 | gregorovius | no, physical sizes |
| 04:43:15 | gregorovius | at least I _think_ i saw that on the rockbox wiki |
| 04:44:51 | linuxstb | http://www.rockbox.org/twiki/bin/view/Main/DeviceChart |
| 04:45:29 | gregorovius | that's it, thanks |
| 04:46:52 | | Quit SpeakerMania ("Leaving") |
| 04:48:59 | saratoga | linuxstb: your "preload_image" function would be there so that temporary buffers could be allocated in the audio buffer and then freed before buffering was completed then? or do i misunderstand your idea |
| 04:49:35 | linuxstb | Yes |
| 04:50:32 | saratoga | thats a neat idea |
| 04:50:49 | saratoga | would allow for very high quality resizing without much memory hit |
| 04:51:19 | * | Unhelpful still doesn't consider the area results very high quality on his cover2, cover5, and cover8 samples |
| 04:51:50 | linuxstb | But this sounds like we're going round in circles, back towards the first resize patch that simply loaded the entire bitmap to the audio buffer, then resized it... |
| 04:51:51 | Unhelpful | i think a lanczos-like filter could be done with ~<scalefactor> lines of the source image availble |
| 04:52:22 | Unhelpful | linuxstb: except that we're talking about scaler that takes input line-at-a-time |
| 04:52:42 | linuxstb | saratoga: I agree with you that the first step is to simply get something committed, and then we can evaluate different algorithms, with different memory/cpu requirements. |
| 04:52:58 | Unhelpful | so we're allocating the output space, and behind that a series of small buffers the scaler uses, which may be overwritten when it's done. |
| 04:54:05 | | Quit miepchen^schlaf (Success) |
| 04:54:32 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 04:54:38 | Unhelpful | heh, could we load the whole image, ask the IPU to scale it, and then copy it back to buffer, on beast? |
| 04:55:14 | Unhelpful | some of the claims for IPU-based video acceleration suggest that it can do at least *some* operations on an image that is accessible from memory afterward |
| 04:56:01 | saratoga | linuxstb: the memory use for even a very complicated resampling algorithm would be much, much smaller then loading the entire image |
| 04:56:32 | saratoga | probably by a factor of a hundred or more for a typical sized album art |
| 04:58:32 | Unhelpful | the bilinear upscaler can probably be done with... i'm going to say, 8*owidth+1*iwidth bytes of scratch space |
| 04:59:00 | | Join Horschti [0] (n=Horscht@p4FD4FF2A.dip.t-dialin.net) |
| 04:59:08 | saratoga | why 8*out_width? |
| 04:59:46 | | Quit Horscht (Nick collision from services.) |
| 04:59:51 | Unhelpful | two owidth buffers of 32-bit ints, which will hold linear-scaled lines of input date, then we interpolate between those to produce each output line. |
| 05:00 |
| 05:00:31 | Unhelpful | saratoga: because i think that interpolating those two lines direct to 8-bit is a bad idea if we're going to interpolate between them as well |
| 05:00:36 | saratoga | ah ok was figuring we'd use 16 bit samples, but i suppose converting could be annoying |
| 05:02:06 | Unhelpful | 16-bit might be fine. the area scaler uses an accumulator buffer, so the values in it need to hold 255*256*(scale^2) without overflowing |
| 05:02:57 | | Quit Bensawsome ("The awsome is gone :(") |
| 05:03:18 | saratoga | you can prescale values to avoid overflow |
| 05:03:40 | Unhelpful | the bilinear is just storing a temp value for a single pixel, fixed point to reduce rounding errors. 16 bits is fine, i'd think. |
| 05:04:37 | Unhelpful | saratoga: i'd rather not in the area scaler, since the precision loss is potentially multiplied by many pixels. i could, however, have it do a prescale if the scalefactor is beyond the limits of the filter without one. |
| 05:05:35 | Unhelpful | first i need to figure out why that problem i mentioned in the other channel happens... or just port the thing to rockbox, where that problem probably won't happen due to framework differences. |
| 05:05:46 | saratoga | Unhelpful: I think most LCDs only do 5-6 bits per color channel, so rounding error is probably irrelevent |
| 05:06:52 | Unhelpful | do you think reducing the size of a one-or-two-line temp buffer by half would make the patch more palatable? |
| 05:07:07 | Unhelpful | also, there's the getting-jpeg-into-core issue, before a scaler is of much use, isn't there? |
| 05:07:41 | Llorean | A scaler would still be useful with bitmap album art. |
| 05:07:58 | Llorean | Since it means you don't need multiple copies for different sized themes. |
| 05:08:08 | saratoga | we'll probably go through all of this again whenever JPEG is ready |
| 05:08:33 | Llorean | In fact, I personally don't think it's even unreasonable to say "please prescale all your album art to X*Y or less, and we'll handle downscaling only" |
| 05:09:11 | | Join Darksair [0] (n=user@125.33.193.195) |
| 05:09:13 | Unhelpful | and nico_p is the person to talk to about hooking a scaler into the current album-art load mechanism? |
| 05:09:16 | Llorean | For example "All album art must be no larger than the largest dimension of your screen, times two, squared" so 640x640 for iPods, 440x440 for Sansas, etc. |
| 05:10:07 | saratoga | Unhelpful: have you looked at FS #9458 ? |
| 05:10:30 | Unhelpful | Llorean: that wouldn't eliminate the upscaling case. and the area scaler, as written, can handle about 1/256 scalefactor. |
| 05:11:02 | Llorean | Unhelpful: Huh? |
| 05:11:09 | saratoga | yeah but i doubt it has enough memory to buffer an entire line |
| 05:11:43 | Unhelpful | Llorean: a max image size would not keep you from ever wanting to upscale. if your cover art is smaller than the display size in wps, you might want that bilinear scaler. |
| 05:11:43 | saratoga | or at least if you try to declare int cache_line[10000] your patch is probably going to be rejected pretty fast |
| 05:12:09 | saratoga | i don't think unscaling is a very interesting case from our point of view |
| 05:12:15 | Llorean | Unhelpful: If it's smaller than the WPS size, they could upscale it to the largest size any of their WPSes will use in advance, then let Rockbox downscale. |
| 05:12:16 | saratoga | the memory requirements should be no different |
| 05:12:19 | Unhelpful | heh, 10k isn't enough on beast, you'd need 61440 :D |
| 05:12:38 | Llorean | If upscaling is "free" in terms of added code, sure. |
| 05:12:47 | Llorean | But i just don't think it's something we should care too much about adding support for if it's not. |
| 05:12:58 | saratoga | we'll probbaly just limit BMPs to 500 or 1000 pixels, and [eventually] jpegs of 8 times that |
| 05:13:06 | Unhelpful | Llorean: it can't be completely free, the best filters for up- and down-scaling aren't the same. |
| 05:13:17 | Llorean | Unhelpful: That's kinda what i assumed. |
| 05:13:28 | Unhelpful | well, ok, the cheapest-acceptable ones. |
| 05:13:47 | Llorean | I propose we should say "we don't care about upscaling, please do any upscaling in advance". The goal should be "allow users to have on file per album" rather than "ensure users never, ever, ever need to prescale" |
| 05:13:58 | Llorean | *one file per album |
| 05:16:15 | Unhelpful | i think that's fair. the only way i'd say upscaling might be free is if 1) my pseudo-lanczos concept pans out and 2) i can use that same design for upscaling |
| 05:16:51 | saratoga | upscaling would be nice to have i ugess, but i don't see any reason it needs to be in the resize patch |
| 05:16:55 | saratoga | we can always add things later |
| 05:17:18 | Llorean | I don't see upscaling as being particularly useful except maybe if we start scaling icons. |
| 05:17:19 | saratoga | really just getting any resize at all would be nice so that things can be tested and tweaked |
| 05:17:40 | Unhelpful | Llorean: which isn't compatible with on-audio-buffer rescale-while-loading :/ |
| 05:17:42 | saratoga | rescaling icons might not look so good so i don't think most people would do it |
| 05:17:58 | Llorean | Yeah |
| 05:18:15 | Unhelpful | saratoga: i agree on that, the line-art-ish samples in the set i put up show the worst aliasing by far |
| 05:18:15 | saratoga | same goes for WPS bmps [or jpegs] |
| 05:18:16 | Llorean | In my opinion, if we want to always have scaled icons, we just provide a bunch of premade icons and have it load some based on the height of the font. |
| 05:18:23 | Llorean | And if they want to use third-party fonts, they just get their own icons. |
| 05:18:35 | Llorean | Unhelpful: Samples somewhere? |
| 05:18:36 | Unhelpful | the 'A' in cover2 is nasty |
| 05:18:49 | saratoga | i guess in the extreme case the build script could do resizing too |
| 05:19:18 | Unhelpful | https://looking-glass.us/~chshrcat/area_scale_test/ |
| 05:20:06 | Unhelpful | those are from a test-case 8-bit grayscale sampler. what remains would be to do the same thing for each channel, and pack target bitmap pixels. |
| 05:20:39 | saratoga | i think you may be underestimating the visibility of artifacts on a device screen |
| 05:20:52 | saratoga | the contrast and color resolution will be much worse then on a desktop screen |
| 05:20:57 | Unhelpful | over, you mean? |
| 05:21:01 | Llorean | Unhelpful: Have you tried viewing bitmaps of those on-player? |
| 05:21:02 | saratoga | yes over |
| 05:21:08 | Llorean | I bet most of those look almost perfectly acceptable on the player screens |
| 05:21:18 | Llorean | At the very least, they're "good enough" compared to "no scaling at all" |
| 05:21:36 | | Part toffe82 |
| 05:21:38 | Unhelpful | Llorean: that i have not done. rockpaint can load bitmaps, right? |
| 05:22:10 | Llorean | Yup |
| 05:24:08 | Llorean | And I think 95% of users wouldn't even complain about how they look on a PC screen for simple WPS album art. |
| 05:25:26 | Unhelpful | they're less obvious on player. 8 doesn't look noticeably bad at all, 2 and 5 are much less jarring, although still noticeable. |
| 05:26:54 | saratoga | i guess the real test is if you can tell theres aliasing without having seen the original recently |
| 05:27:31 | saratoga | for what its worth, I think bilinear is pretty widely used for resizing video in embedded devices |
| 05:29:15 | Unhelpful | saratoga: bilinear is good for upscaling. you need to use <scale>x<scale> pixels of input for it to downscale much better than nearest-neighbor, and at that point, it's practically an area scaler, with more math. |
| 05:30:06 | saratoga | yeah but people aren't all that bothered by aliasing in images I think |
| 05:30:52 | Llorean | I'm sure they won't be with album art. |
| 05:31:13 | Llorean | Honestly, I see enough aliasing in print adds and images scaled badly for TV that I think average users are pretty blind to it. |
| 05:32:24 | Unhelpful | looking at #9458, though, it looks like the bilinear and nearest-neighbor are just being used for larger images |
| 05:33:10 | saratoga | yes aliasing on TV drives me nuts but I'm the only person I know who even recognizes it |
| 05:33:12 | Unhelpful | maybe in the next couple days i should take a look at incorporating the test scaler into that patch as an all-purpose scaler? |
| 05:37:31 | Unhelpful | *sigh* i had a hunch that upping the sub-pixel accuracy at area edges might improve the quality. it doesn't. i'll still look into varying that, though, since that will allow the scalefactor range to be extended without overflowing. |
| 05:46:35 | *** | Saving seen data "./dancer.seen" |
| 05:46:50 | | Join aarcane [0] (n=aarcane@c-67-187-242-146.hsd1.ca.comcast.net) |
| 05:48:15 | | Quit Horschti ("User was distributing pornography on server; system seized by FBI") |
| 05:59:21 | | Quit saratoga ("CGI:IRC (EOF)") |
| 06:00 |
| 06:01:39 | | Quit obo ("bye") |
| 06:30:57 | | Join sin613 [0] (n=pbarton@host-8-122-107-208.midco.net) |
| 06:36:49 | Unhelpful | Llorean: i note that the scalers in #9458 are borrowed from plugin lib. if they're moved into core, they could be added to the plugin API, right? that would be a total binsize win, although a core binsize loss, still. and an area sampler that's not limited at 1/5 scalefactor would make it pretty reasonable to remove the nearest-neighbor scaler. |
| 06:37:45 | | Quit Zarggg () |
| 06:37:51 | Llorean | Unhelpful: Making the core one more universal just to save for plugins doesn't make much sense. |
| 06:40:56 | Unhelpful | so core binsize is going to be more a factor than plugin binsize. fair enough, i haven't seen that very many plugins appear to use the scalers, anyway. is there anything that really needs different scale factors per axis? |
| 06:42:19 | Unhelpful | i'd favor aspect-preserving scale for album art. i don't remember what pictureflow does. and i think that people really *could* just scale their own for sliding puzzle. |
| 06:43:12 | | Quit linuxstb (Remote closed the connection) |
| 06:48:09 | Llorean | I think we really should just be concerned with core scaling right now. |
| 06:48:37 | Llorean | Someone can add as complex a scaler as they want for use in plugins later if certain features aren't available through the existing one in plugins. |
| 07:00 |
| 07:10:39 | Unhelpful | Llorean: i'll try to get some work in on this over the next few days. if we're assuming an album-art-only scaler, we can drop nearest-neighbor completely. i'll definitely need help with scaled output direct to buffer and scratch-space-on-buffer. getting those in gets rid of the static line buffers. |
| 07:18:42 | | Quit gregorovius () |
| 07:37:08 | | Join LinusN [0] (n=linus@rockbox/developer/LinusN) |
| 07:46:21 | amiconn | Unhelpful: There are targets with non-square pixels |
| 07:46:39 | *** | Saving seen data "./dancer.seen" |
| 07:47:22 | amiconn | (none of the *existing* more severe cases will have album art and the scaler in the core though) |
| 07:47:59 | Llorean | I think even with non-square pixel targets in the future (if such happen), we can ask them to scale their AA to the proper aspect. |
| 07:48:14 | * | Llorean is still in the "core scaling means asking them to scale once, not asking them never to scale" camp. :) |
| 07:49:28 | amiconn | I'm not just thinking about album art. I want to add a scaler to jpeg.rock so that the first zoom level will always be full-screen (currently it is the largest that fits the screen) |
| 07:50:15 | amiconn | And on archos the scaler should also compensate the non-square pixels |
| 07:51:03 | * | amiconn also wants optional auto-rotation in the jpeg viewer |
| 07:51:06 | LinusN | i think it should be convenient to use rockbox |
| 07:51:07 | Unhelpful | amiconn: there are area and bilinear scalers in plugin lib. |
| 07:51:31 | LinusN | and scaling the album art definitely helps |
| 07:51:38 | Llorean | LinusN: I think preparing your album art once is still pretty convenient. |
| 07:52:01 | LinusN | not as convenient as not needing to do it at all |
| 07:52:17 | Unhelpful | and i'm getting a definite impression that (not entirely unreasonably) a patch that does too much will have trouble getting into core |
| 07:52:17 | Llorean | Not needing to do it at all means we have to upscale, downscale, deal with arbitrary sizes that may be ridiculous... |
| 07:52:31 | LinusN | yes |
| 07:52:42 | amiconn | LinusN: Well, you still need to convert once; it's unlikely that the album art comes in BMP format (most common is probably JPEG) |
| 07:52:44 | Llorean | LinusN: We could even have RBUtil handle a scan and preparation, to make it as easy as possible. |
| 07:52:56 | LinusN | amiconn: i want jpeg decoding as well |
| 07:54:07 | LinusN | Llorean: that's probably the closest thing to a solution we can get, if we don't do it in rockbox |
| 07:54:57 | amiconn | Afaik it's not possible to scale JPEG on the fly on load (scale arbitrarily I mean; 1/2, 1/4 and 1/8 are possible in the idct of course) |
| 07:55:26 | J-23 | hmm, when I'm booting newest code for e200v2's I see "Connected" screen from the OF |
| 07:55:31 | LinusN | amiconn: it would have to be done in two passes |
| 07:55:31 | J-23 | I can |
| 07:55:37 | J-23 | argh, enter again |
| 07:57:19 | amiconn | LinusN: That would need (potentially very large) intermediate buffers |
| 07:57:20 | | Quit rasher (Read error: 104 (Connection reset by peer)) |
| 07:57:28 | LinusN | amiconn: maybe |
| 07:57:45 | sin613 | amiconn & LinusN: which of you should i be speaking with regarding development for the iaudio x5? |
| 07:57:56 | LinusN | both i guess :-) |
| 07:58:05 | Unhelpful | once again, i don't see why we can't scale on load, with a temp buffer that holds one row of macroblocks. |
| 07:58:57 | amiconn | Actually jpeg could scale down to other factors too: 7/8, 6/8, 5/8, .... Each of those factors requires another idct |
| 07:59:37 | LinusN | Unhelpful: i believe we can do it in a quite efficient way, the question is if we are prepared to do the programming work, and if we think the increased complexity and binary size is worth it |
| 08:00 |
| 08:00:00 | amiconn | It could also scale up this way. [IDC]Dragon once pointed me to a page where using custom idcts with different output sizes was described |
| 08:00:34 | amiconn | This method can even scale X and Y by different factors |
| 08:02:07 | Unhelpful | LinusN: my idea of an album-art-only scaler takes a callback function for a pointer to the next line. a line-at-a-time jpeg decoder can then decode one line of macroblocks, and pass pointers into it when the callback is called. |
| 08:02:33 | | Join rasher [0] (n=rasher@0x5550f5a3.adsl.cybercity.dk) |
| 08:03:43 | JdGordon | can anyone think of a reason why the file dirfilter could ever change (while the browser is open) other than with the quickscreen? |
| 08:04:59 | amiconn | JdGordon: Yes, and someone already told you: loading a .cfg |
| 08:05:15 | JdGordon | I didnt get an answer yesterday... |
| 08:05:27 | JdGordon | but yes thats a good reason :/ |
| 08:06:19 | | Quit BHSPitLappy ("Ex-Chat") |
| 08:06:20 | amiconn | http://www.rockbox.org/irc/log-20081116#15:14:04 |
| 08:08:14 | Unhelpful | amiconn: my google-fu is too weak to find that jpeg info, right now. and it might be easier just to use a fixed set of idcts for 1, 1/2, 1/4, 1/8 |
| 08:09:35 | amiconn | http://jpegclub.org/djpeg/jidctred.c This one has a whole bunch of idcts |
| 08:10:44 | amiconn | Explanation etc here: http://jpegclub.org/djpeg/ |
| 08:11:30 | J-23 | Is it known what USB controller do e200v2's have? |
| 08:21:07 | * | JdGordon wonders why scrobbler_init() and scrobbler_shutdown() are in tree.c in amongst the tree init/shutdown code?! |
| 08:21:38 | JdGordon | and playlist_shutdown() is there also |
| 08:22:02 | | Quit miepchen^schlaf_ () |
| 08:22:54 | LinusN | JdGordon: i believe it could be because it was the most convenient way of doing it back then, since the scrobbler has no thread of its own |
| 08:23:20 | JdGordon | instead of just being in system_flush() and system_restore()? |
| 08:24:06 | LinusN | i guess so |
| 08:24:43 | LinusN | when are those called? |
| 08:25:00 | JdGordon | usb dis/connect |
| 08:25:10 | JdGordon | and clean poweroff |
| 08:25:16 | JdGordon | from the default event handler |
| 08:25:42 | LinusN | maybe system_flush/restore are newer than the scrobbler? |
| 08:25:50 | LinusN | just a guess |
| 08:26:45 | JdGordon | could be... objections to me moving them out? |
| 08:27:22 | JdGordon | anyone know of any bugs related to scrobbler not logging tracks on shutdown? |
| 08:28:31 | LinusN | not sure |
| 08:29:27 | JdGordon | no there wont be.. it looked like a flush call was missing, but scrobbler_flush is inside scrobbler_shutdown... |
| 08:29:36 | JdGordon | system_flush is MUCH older than scrobbler |
| 08:29:42 | JdGordon | r7516 |
| 08:31:18 | amiconn | The shutdown handling needs complete rework anyway |
| 08:32:07 | JdGordon | it seems its not really threadsafe? the default event handler could end up getting called in any thread? |
| 08:32:20 | | Quit GodEater ("http://www.mibbit.com ajax IRC Client") |
| 08:32:27 | | Join GodEater [0] (i=c2cbc962@gateway/web/ajax/mibbit.com/x-e4c36f89481b0b47) |
| 08:34:19 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 08:36:18 | LinusN | JdGordon: only the main thread should call the default event handler |
| 08:36:27 | | Quit Darksair (Read error: 60 (Operation timed out)) |
| 08:37:44 | JdGordon | sure, but its easy to tihnk it could be accidently be called in the wrong thread |
| 08:38:48 | LinusN | sure it could be, but that only means that we should take care when coding |
| 08:39:34 | amiconn | Afaik the default event handler is never called from somewhere else than the main thread |
| 08:39:53 | JdGordon | yeah, just checked... looks safe for now |
| 08:40:45 | amiconn | But the shutdown handling is nasty: It's called from the main thread, even if the feature being shut down has its own thread, and at least on some targets, shutdown terminates some threads |
| 08:41:45 | amiconn | Instead, the shutdown code should tell each thread to cleanly prepare for shutdown, optionally (compile-time) *without* terminating the thread, but putting it into idle state. The latter is needed for proper suspend |
| 08:42:32 | JdGordon | and stuff like scrobbler and playlist should setup callbacks for the events instead of poluting misc.c |
| 08:42:34 | amiconn | This thread shutdown needs to be coordinated. At least some threads depend on others, so order is important |
| 08:47:24 | | Join Bagderr [241] (n=daniel@rockbox/developer/bagder) |
| 08:47:49 | | Nick Bagderr is now known as B4gder (n=daniel@rockbox/developer/bagder) |
| 08:48:05 | | Quit BigBambi (Read error: 113 (No route to host)) |
| 08:51:09 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
| 08:52:34 | | Join Rob2222 [0] (n=Miranda@p4FDCF789.dip.t-dialin.net) |
| 09:00 |
| 09:03:40 | | Quit sin613 ("Leaving.") |
| 09:10:44 | | Quit Rob2223 (Read error: 110 (Connection timed out)) |
| 09:14:21 | | Quit denes_ (Read error: 110 (Connection timed out)) |
| 09:14:41 | | Join denes_ [0] (n=denes@pool-5626.adsl.interware.hu) |
| 09:21:44 | | Join DTU_student [0] (n=82e149de@gateway/web/cgi-irc/labb.contactor.se/x-9d2d2d2779cbc569) |
| 09:21:47 | DTU_student | hi guys |
| 09:21:56 | jchillerup | hi |
| 09:22:04 | jchillerup | (are you a DTU student :)) |
| 09:22:13 | DTU_student | yup |
| 09:22:21 | DTU_student | Doing a poster about Rockbox |
| 09:22:27 | DTU_student | An assignment |
| 09:22:28 | jchillerup | For DTU? |
| 09:22:33 | jchillerup | Oh, OK... |
| 09:22:40 | jchillerup | I'm studying there too |
| 09:22:51 | DTU_student | I was wondering if there's any screenshots for Rockbox |
| 09:22:56 | DTU_student | ok cool :P |
| 09:23:12 | jchillerup | Yeah, sure, they're on the wiki |
| 09:23:13 | B4gder | tried the manual? |
| 09:23:27 | B4gder | the manual, the wiki or wikipedia or ... |
| 09:23:38 | scorche | DTU_student: there are some in the manual, but one of the aspects of rockbox is themability, so it can look quite different in some screens... |
| 09:23:56 | DTU_student | ok |
| 09:24:02 | jchillerup | http://www.rockbox.org/twiki/bin/view/Main/ScreenShots |
| 09:24:33 | B4gder | also note that we have many different targets that look quite different |
| 09:24:42 | B4gder | due to screen constraints |
| 09:24:44 | scorche | jchillerup: that page is ooooooold |
| 09:24:50 | jchillerup | yeah, i see |
| 09:25:24 | scorche | DTU_student: you can also make your own screenshots if you wish...the process is in the manual |
| 09:25:45 | DTU_student | Well |
| 09:25:57 | jchillerup | I have an iPod 30G with rockbox... |
| 09:26:07 | DTU_student | I thought many times about using Rockbox on my ipod |
| 09:26:09 | jchillerup | (and I'm in the process of porting it to Nintendo DS) |
| 09:26:19 | DTU_student | But im short of time with this poster :D |
| 09:26:25 | jchillerup | heh |
| 09:26:47 | B4gder | sleep less, hack on rockbox more! |
| 09:26:50 | DTU_student | :P |
| 09:27:06 | DTU_student | So can I use the picture on the boot screen on my poster? No copyright or anything? |
| 09:27:25 | DTU_student | Copyright © 1999-2008 by the contributing authors. |
| 09:27:42 | jchillerup | I guess nobody would mind |
| 09:27:50 | jchillerup | what exactly is the poster on? |
| 09:27:56 | B4gder | copyright sure, but licensed to be used |
| 09:28:02 | DTU_student | ok thx |
| 09:28:27 | jchillerup | if you need me to take some screenshot, I can do that |
| 09:28:39 | jchillerup | if you need anything special |
| 09:28:43 | DTU_student | Well we have a subject called Real time systems.. then we need to critically analyse a real-time system |
| 09:28:58 | DTU_student | The organization of the kernel and such |
| 09:29:06 | B4gder | real-time by the original and strict sense? |
| 09:29:10 | DTU_student | And my team is doing about rockbox |
| 09:29:13 | jchillerup | software technology or design and innovation? |
| 09:29:26 | DTU_student | Diplom IT :) |
| 09:29:32 | jchillerup | oh. |
| 09:29:39 | | Join THe [0] (n=82e149e3@gateway/web/cgi-irc/labb.contactor.se/x-3315d7268e1bd767) |
| 09:29:53 | DTU_student | well it doesn't need to be a hard real time system |
| 09:30:35 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
| 09:30:53 | THe | Hello, |
| 09:30:54 | kugel | jhMikeS: ping |
| 09:31:07 | | Quit THe (Client Quit) |
| 09:31:17 | | Join Apprentice [0] (n=82e149e3@gateway/web/cgi-irc/labb.contactor.se/x-7ac92ca8dcd32804) |
| 09:32:00 | DTU_student | hmm |
| 09:32:17 | DTU_student | I really dont know what to write about rockbox... |
| 09:32:28 | DTU_student | The objectives are these: |
| 09:32:44 | DTU_student | You can critically analyze a real-time system and propose an operating system organization which is particularly suitable for supporting the real-time system. ● You can critically analyze an operating system and propose some applications for which it is particularly suitable. |
| 09:33:38 | B4gder | so, then do that! |
| 09:33:51 | | Quit pixelma2 ("-") |
| 09:34:02 | | Join pixelma [50] (i=pixelma@rockbox/staff/pixelma) |
| 09:35:15 | DTU_student | Well... we've written about what rockbox is.. and why people should use rockbox..and which kernel structure it is.. something about why you dont use malloc |
| 09:35:21 | DTU_student | But it doesnt fit that much :P |
| 09:35:42 | | Quit Apprentice (Client Quit) |
| 09:36:12 | | Quit kugel (Remote closed the connection) |
| 09:36:28 | jchillerup | DTU_student: http://www.rockbox.org/twiki/bin/view/Main/RockboxArchitecture |
| 09:36:36 | jchillerup | DTU_student: http://www.rockbox.org/twiki/bin/view/Main/RockboxKernel |
| 09:36:41 | | Join SimonG [0] (n=82e149e3@gateway/web/cgi-irc/labb.contactor.se/x-2b9f94ac591e6012) |
| 09:37:29 | | Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) |
| 09:38:15 | DTU_student | I've searched these pages hundreds of times :p |
| 09:38:46 | SimonG | hi |
| 09:38:46 | scorche | so what do you want from us? |
| 09:39:50 | DTU_student | I want you to guide me :P |
| 09:40:14 | | Join wingmanz [0] (n=wingmanz@212.93.97.181) |
| 09:40:21 | SimonG | can anybody give me the "Line of the line" on why i should use rockbox instead of my apple firmware? I've read the pro's but not that many con's, This cant be? |
| 09:40:38 | jchillerup | do you need a con? |
| 09:40:39 | SimonG | what are the con's? |
| 09:40:40 | scorche | SimonG: well, there is the WhyRockbox wiki page |
| 09:40:40 | B4gder | SimonG: try it out and see for yourself |
| 09:40:48 | Llorean | DTU_student: It's your project. If you have specific questions about Rockbox ask them, but there's not really anyone here can do to tell you what to do, just answer specific questions about the project. |
| 09:40:53 | jchillerup | The battery life is reduced somewhat |
| 09:41:16 | Llorean | jchillerup: When was the last time you did a comparative benchmark? |
| 09:41:19 | jchillerup | Partly because of the more powerful playback, partly of hardware issues, as far as I'm concerned |
| 09:41:28 | scorche | jchillerup: that statement is likely wrong...which device are you talking about? |
| 09:41:29 | jchillerup | Llorean: quite a while, but rockbox DOES play louder |
| 09:41:35 | jchillerup | ipod video 30g |
| 09:41:36 | Llorean | jchillerup: Yes, but that's not comparative. |
| 09:41:39 | scorche | "more powerful playback"? |
| 09:41:41 | SimonG | is there really any change in sound? I read that ipods allready are cream of the crop ? |
| 09:41:50 | | Quit jhulst (Remote closed the connection) |
| 09:41:56 | scorche | ipods are far from cream-of-the-crop |
| 09:41:56 | jchillerup | Yes, my ipod 30g clips the bass in Apple OS |
| 09:42:02 | jchillerup | I have sennheiser hd202 |
| 09:42:11 | Llorean | jchillerup: "Reduced battery life because you do different things" isn't actually "reduced". It's like saying "If you turn up the volume in the apple firmware, it reduces your battery life." That doesn't mean the Apple_OS has less battery life than Apple_OS. |
| 09:42:11 | jchillerup | doesn't clip in rockbox |
| 09:42:13 | wingmanz | ipods have really bad sound. rockbox much better |
| 09:42:30 | jchillerup | Llorean: guess I stand corrected |
| 09:42:44 | scorche | wingmanz: ipods are a hardware device...rockbox is a formware...that doesnt make sense |
| 09:42:45 | SimonG | how come? |
| 09:42:55 | scorche | s/formware/firmware |
| 09:43:01 | Llorean | jchillerup: Battery life may be reduced by features, but under identical conditions Rockbox performs very similarly in terms of battery life to the stock firmware. |
| 09:43:02 | wingmanz | i mean ipod firmware |
| 09:43:04 | SimonG | why cant a proffessional team like them create the best? |
| 09:43:13 | jchillerup | Llorean: fine. good. |
| 09:43:15 | Llorean | SimonG: They can. But it would make it cost more. |
| 09:43:20 | B4gder | SimonG: the "best" is hardly objective |
| 09:43:25 | jchillerup | SimonG: it all comes down to economic interests |
| 09:43:36 | scorche | wingmanz: then that is incorrect...please come back with some RMAA results provinf your statement...all i have seen points that they are essentially the same |
| 09:43:50 | Llorean | jchillerup: Anyway, please check on more objective data like benchmarks when trying to give out information like that. |
| 09:43:52 | jchillerup | apple for example only want to support their own format (+ mp3) |
| 09:43:53 | SimonG | oh.. well im kinda critical to this subject since rockbox can make it for free? |
| 09:44:07 | jchillerup | linux is free too |
| 09:44:15 | jchillerup | linux is used in many, many enterprises |
| 09:44:18 | Llorean | SimonG: It's fully reversible, anyway. |
| 09:44:31 | SimonG | yes |
| 09:44:40 | SimonG | how much space do i need for rockbox? |
| 09:44:50 | Llorean | Depends on what extras you install. |
| 09:44:52 | scorche | download the zip file and find out |
| 09:44:53 | DTU_student | SimonG is my co student for this poster |
| 09:45:03 | Llorean | But less than 10mb for a base install. |
| 09:45:18 | SimonG | shit. thats nothing |
| 09:45:30 | scorche | the expletive is unneccesary... |
| 09:45:32 | jchillerup | the menu structure is somewhat different compared to the apple os |
| 09:45:54 | jchillerup | where you would normally press menu to get one "step" up, you would press back in Rockbox |
| 09:45:57 | SimonG | so having it on my ipod will only "cost" 10mb |
| 09:45:59 | scorche | a bit more than "somewhat", but of course it is...we dont try to emulate the apple firmware... |
| 09:46:12 | jchillerup | the menu toggles between the music you play and the .. menu. |
| 09:46:22 | scorche | SimonG: sure... |
| 09:46:22 | B4gder | SimonG: it will also cost you the experience of realizing what Apple didn't offer you... :-) |
| 09:46:25 | jchillerup | SimonG: yeah, but there are extras |
| 09:46:31 | SimonG | haha |
| 09:46:36 | jchillerup | "But wait... there's more!" |
| 09:46:37 | SimonG | :D i will |
| 09:46:40 | scorche | jchillerup: you dont need to say all the differences...this is what the manual is for |
| 09:46:42 | jchillerup | (Doom 2, for example) |
| 09:46:45 | *** | Saving seen data "./dancer.seen" |
| 09:46:54 | jchillerup | scorche: didn't mean to explain any other differences |
| 09:47:05 | jchillerup | but a fact is that I didnd't know how to navigate rockbox at first |
| 09:47:14 | SimonG | its not gonna hurt to try |
| 09:47:14 | scorche | which is why the manual is there.. |
| 09:47:15 | jchillerup | i'm trying to help these guys... |
| 09:47:25 | Llorean | jchillerup: help them by pointing them to the manual, perhaps? |
| 09:47:33 | jchillerup | You already did. |
| 09:47:39 | SimonG | thanks guys |
| 09:47:41 | jchillerup | But yeah, read the manual too |
| 09:47:58 | DTU_student | You really like that manual :D |
| 09:48:17 | SimonG | ill install it tomorrow since its not my ipod i need to persuade my gf |
| 09:48:29 | scorche | if you bothered to write it would you not reference people towards it/ |
| 09:48:45 | SimonG | anyways we know more to write about but the manual isnt that juicy as the info u guys give us |
| 09:49:07 | scorche | isnt as "juicy"?...what info are you looking for? |
| 09:49:20 | SimonG | just the simple questions as "cons" |
| 09:49:44 | B4gder | there are no cons in my view |
| 09:49:45 | jchillerup | One other con of Rockbox on an ipod is that girls can't. handle. it. |
| 09:49:48 | jchillerup | But that's also a pro sometimes |
| 09:49:53 | SimonG | its easy to only write about cons compared to other "firmwares" but imo a good product will eplxain at least a few cons |
| 09:49:56 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
| 09:49:58 | scorche | the "cons" are different for everyone...we say to figure them out for yourself, because what you consider a con might very likely not be one in my eyes |
| 09:50:01 | Llorean | jchillerup: That's stupid and subjective. Please, try to stay serious in here. |
| 09:50:10 | jchillerup | yeah, ok, sorry |
| 09:50:18 | SimonG | lol hehe good one though :P |
| 09:50:30 | SimonG | i understand |
| 09:50:33 | jchillerup | but really, it's all about figuring out how the menu works |
| 09:50:43 | scorche | for you, perhaps.... |
| 09:50:43 | DTU_student | So.. when will I get my money for marketing rockbox? |
| 09:50:50 | jchillerup | scorche: come on. for everybody |
| 09:50:58 | DTU_student | :D |
| 09:50:59 | scorche | jchillerup: no |
| 09:51:01 | Llorean | jchillerup: I dunno, many of us found it easy and intuitive. |
| 09:51:02 | jchillerup | you need to know how the menu works to use it |
| 09:51:08 | SimonG | well mac isnt easy for a windows user |
| 09:51:37 | jchillerup | Coming straight from the ipod bandwagon, you need to wrap your head around a new menu system. That's both true and understandable. |
| 09:51:37 | SimonG | so i guess rockbox isnt "as easy" to begin with |
| 09:51:40 | scorche | DTU_student: uh...when we become rich?...rockbox is a volunteer project that gets no funding such as that.. |
| 09:51:41 | jchillerup | It is! |
| 09:51:52 | scorche | jchillerup: not all of us came from "the ipod bandwagon" |
| 09:51:54 | Llorean | SimonG: It's easier for some people |
| 09:52:01 | jchillerup | No you did not, but SimonG and I did. |
| 09:52:03 | pixelma | hooray for generalisations... |
| 09:52:07 | DTU_student | It was a joke :P |
| 09:52:10 | scorche | jchillerup: so? |
| 09:52:10 | Llorean | SimonG: How easy it is depends entirely upon how many expectations you bring with you, and whether you're willing to read over the basics in the manual first. |
| 09:52:15 | jchillerup | Please, people, I'm trying to help this guy. |
| 09:52:36 | * | B4gder tries to confuse him by injecting truths |
| 09:52:40 | Llorean | jchillerup: But instead you're making stupid generalizations like when you said it's difficult "for everybody" |
| 09:53:07 | jchillerup | sigh. |
| 09:53:09 | Llorean | Which is patently untrue. It's difficult *for people used to the way the iPod firmware works* if and only if they expect Rockbox to work the same way, and are unable to grasp the differences. |
| 09:53:17 | scorche | SimonG: as i said before, there are no explicit "cons" because everyone is different and this is a subjective experience...play with it for yourself and figure out the cons FOR YOU |
| 09:53:32 | B4gder | I installed rockbox on a ipod video for a 20 year old girl once who never used it before |
| 09:53:34 | SimonG | i wonder who got "acess" to update the rockbox firmware? i mean if some developer makes something genious will he present it for a "rockbox leading developer team" and they will implement it or ? |
| 09:53:36 | B4gder | she had no problems at all |
| 09:53:56 | Llorean | scorche: I think the two biggest "cons" are "USB may not always work on the first attempt" and "You can't play DRMed music." Whether they affect your or not, these are two things Rockbox definitely doesn't address (one yet, the other ever) |
| 09:53:58 | jchillerup | B4gder: I didn't either, when I grasped the menu system. |
| 09:53:58 | scorche | SimonG: we have the tracker and svn...it is like many other open source organizations |
| 09:54:18 | DTU_student | This chat browser is making my browser freeze :P |
| 09:54:25 | | Quit DTU_student ("CGI:IRC") |
| 09:55:05 | scorche | Llorean: right...i mentioned the "subjective experience" as that is what is being talked about...as an example, USB works fine for me and i dont care about DRMed music, so those are not cons for me |
| 09:55:06 | | Join Sarquah [0] (n=hl@wnn73222.wireless.dtu.dk) |
| 09:55:16 | * | Sarquah is DTU_student |
| 09:55:34 | Llorean | scorche: I think it's important, though, to qualify as "Cons" anything you "lose" from the original firmware. |
| 09:55:44 | SimonG | indeed |
| 09:55:47 | Llorean | Whether you use it or not, a reduction in functionality available is a "con" |
| 09:56:06 | B4gder | you gain the inability to not play drm-polluted music! |
| 09:56:09 | scorche | Llorean: but i thought their project was on rockbox...not rockbox on the ipod...there are many different original firmwares around |
| 09:56:14 | Llorean | The cons, though, are different from player to player in the sense that some never supported DRM to begin with, and many have perfectly working USB in Rockbox. |
| 09:56:15 | | Quit MegafEee ("KVIrc 4.0.0 Insomnia http://www.kvirc.net/") |
| 09:56:30 | SimonG | im allready convinced that rockbox will only enhance ur audio player. no doubt about it.. but there's allways something that could be improved.. remember nothing is perfect |
| 09:56:51 | scorche | SimonG: hence why constant development happens... |
| 09:56:56 | B4gder | we have some 200 open bug reports... |
| 09:57:01 | Llorean | scorche: You can address this, though, rather than simply saying "Well, I can't guess what they may be for you" |
| 09:58:05 | scorche | Llorean: right, but as the project (from what they have said earlier) is on "rockbox", they would need to....why are we discussing this betweent he two of us again? |
| 09:58:16 | Sarquah | The picture about the kernel. Isn't more about the scheduler and the threads? |
| 09:58:47 | B4gder | Sarquah: our kernel doesn't do a lot more than so ;-) |
| 09:58:53 | Sarquah | ok |
| 10:00 |
| 10:01:59 | | Part LinusN |
| 10:02:06 | | Join lasser [0] (n=chatzill@W8f7c.w.pppool.de) |
| 10:06:04 | | Join rost [0] (n=rost@dsl-213-134-254-075.solcon.nl) |
| 10:08:05 | rost | Hi guys, I have an issue with the battery and booting rockbox on my X5 |
| 10:08:14 | | Quit wingmanz () |
| 10:08:23 | rost | when I just keep it on it'll get a playtime of about 4-5 hours |
| 10:08:39 | rost | but when I shut it down halfway, say 2 hours in it wont boot rockbox |
| 10:08:44 | rost | claiming the battery is low |
| 10:09:12 | rost | when I bootstrap it with the charger and remove the charger I get another two hours of playtime |
| 10:09:22 | scorche | are you running a current build or 3.0? |
| 10:09:24 | scorche | have you compared with what you get in the original firmware?...it may just be a bad battery |
| 10:09:33 | rost | current build |
| 10:09:57 | rost | the battery does give quite low voltages on boot, but the meter gradually increases when its been on for a while |
| 10:09:59 | | Quit DerDome (Read error: 145 (Connection timed out)) |
| 10:10:49 | Sarquah | :o |
| 10:11:00 | Llorean | rost: If you're only getting 4-5 hours normally, it sounds like your battery is very old. |
| 10:11:20 | rost | it is |
| 10:11:44 | rost | but my issue is, when I leave it on all the way I get the 4-5 hours no problem |
| 10:11:53 | rost | but when I restart it halway it wont boot again |
| 10:12:02 | rost | *halfway |
| 10:12:18 | rost | while it should have a few hours left |
| 10:12:24 | Llorean | Yes, but this is still just an issue with it being an old battery. There's not much Rockbox can do to compensate for it. |
| 10:12:41 | Llorean | It may have a few hours left, once booted, but it may be having difficulty booting. |
| 10:12:54 | rost | ok |
| 10:12:55 | rost | ty |
| 10:15:49 | Sarquah | I should really install rockbox |
| 10:21:32 | SimonG | which video can rockbox not play that other firmwares can? |
| 10:21:53 | scorche | SimonG: have you read the wiki page PluginMpegplayer ? |
| 10:22:21 | SimonG | yea and its like rockbox can play everything.. or is something left out? |
| 10:22:39 | scorche | ......far from it...i suggest you read it again... |
| 10:22:53 | * | GodEater hasn't read a PluginMpegPlayer page which claims Rockbox can play everything |
| 10:23:06 | SimonG | http://www.rockbox.org/twiki/bin/view/Main/PluginMpegplayer#Supported_Targets |
| 10:23:28 | B4gder | targets in this context are devices, the hardware |
| 10:23:42 | scorche | targets?...were you not referring to video types/codecs? |
| 10:24:18 | SimonG | that was just the page i read, yes scorche thats what im looking for |
| 10:24:35 | * | scorche wonders what is unclear about "It is currently capable of playing back MPEG-1 and MPEG-2 video streams with MPEG audio multiplexed into .mpg files (MPEG Program Stream) and raw MPEG-1 and MPEG-2 video streams." |
| 10:26:00 | SimonG | i cant find the page where i can see what rockbox can play compared to other devices, as far as i remembere this is such a description? |
| 10:26:10 | scorche | huh? |
| 10:26:32 | B4gder | SimonG: scorche just pasted exactly what rockbox can play |
| 10:26:34 | | Quit Thundercloud (Remote closed the connection) |
| 10:26:49 | SimonG | there was a page on what rockbox featurred and what the other firmware featrude |
| 10:26:55 | B4gder | you'll have to reseach what the OFs can play or not |
| 10:27:24 | B4gder | http://www.rockbox.org/twiki/bin/view/Main/WebHome?topic=FeatureComparison |
| 10:27:27 | scorche | there is this, but it is far from complete or even updated currently likely http://www.rockbox.org/twiki/bin/view/Main/FeatureComparison |
| 10:27:45 | SimonG | ahh |
| 10:27:51 | SimonG | thx |
| 10:28:09 | B4gder | and it doesn't compare video formats to any decent extent |
| 10:28:19 | B4gder | even if it mentions some |
| 10:28:22 | SimonG | oh |
| 10:28:23 | scorche | i would suggest acclimating yourself to the search feature of the wiki or even a google search of "site:www.rockbox.org/twiki/" |
| 10:30:27 | Sarquah | <3 |
| 10:35:03 | | Join Darksair [0] (n=user@125.33.193.195) |
| 10:37:13 | | Join LinusN [0] (n=linus@rockbox/developer/LinusN) |
| 10:39:45 | | Join reacocard [0] (n=reacocar@WL-112.CINE.HMC.Edu) |
| 10:45:11 | | Join einhirn [0] (i=Miranda@p5B0316EB.dip0.t-ipconnect.de) |
| 10:46:15 | | Part rost |
| 10:47:30 | | Quit einhirn (Read error: 104 (Connection reset by peer)) |
| 10:48:29 | Sarquah | Is it true to say that the kernel has no structure or is it monolithic? |
| 10:49:24 | | Join einhirn [0] (i=Miranda@p5B0316EB.dip0.t-ipconnect.de) |
| 10:50:17 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 10:51:08 | GodEater | Sarquah: from looking at your task, it seems to be *you're* supposed to be analyzing Rockbox to discover this information. Not just asking us. |
| 10:51:26 | Sarquah | Im analysing |
| 10:52:49 | Sarquah | I guess it is monolithic.. |
| 10:53:32 | | Quit einhirn (Read error: 104 (Connection reset by peer)) |
| 10:59:37 | JdGordon | how would people feel about a "repeat last playlist action" (needs a better name) option in the browser context menu at the same level as playlist? It was driving me mad that I wanted to keep doing "insert last" but its a hassle to do more than a few times... |
| 10:59:38 | | Nick Darksair is now known as Darksair{away} (n=user@125.33.193.195) |
| 11:00 |
| 11:00:15 | | Join MegafEee [0] (n=Linux@unaffiliated/megaf) |
| 11:03:31 | | Quit MegafEee (Client Quit) |
| 11:03:34 | kugel | JdGordon: do you plan to FS #9514 soon? |
| 11:03:40 | kugel | +commit |
| 11:05:06 | | Join culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) |
| 11:05:20 | JdGordon | whats 9514? |
| 11:05:47 | JdGordon | ah no... not until its needed |
| 11:06:08 | kugel | ok |
| 11:06:24 | * | JdGordon would like to have a discussion on the way we all want to do custom viewports for themers though |
| 11:06:57 | kugel | custom viewports in which way? for lists? |
| 11:07:15 | JdGordon | well lists are most of the gui so yes, but in general |
| 11:07:24 | kugel | ah, I remember. You think we should be able to create a custom vp for each screen |
| 11:09:59 | kugel | JdGordon: I plan to sync my custom list patch soonish, I'm still having problems with statusbar here and there |
| 11:10:04 | JdGordon | B4gder: you want me to commit 9556 if its just waiting for someone who can be bothered patching and ci-in? |
| 11:10:37 | JdGordon | kugel: what sort of problems? |
| 11:10:41 | kugel | (my last sync attempt rendered the statusbar un-update-able) |
| 11:10:54 | JdGordon | ouch! |
| 11:10:57 | * | LinusN is annoyed by the "make zip" dependency...... |
| 11:11:42 | kugel | JdGordon: We should probably viewportify the statusbar first |
| 11:11:55 | * | kugel gotta go |
| 11:11:58 | | Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.3/2008101315]") |
| 11:12:29 | | Quit SimonG ("CGI:IRC (EOF)") |
| 11:12:47 | B4gder | LinusN: I think that change is up for revertion anyway, as we're several people who're against it |
| 11:13:12 | LinusN | JdGordon: i'm about to commit it |
| 11:13:25 | JdGordon | ok |
| 11:18:05 | * | linuxstb is also annoyed by the make zip dependency |
| 11:19:25 | * | pixelma is still annoyed by failing builds for rombox targets ;) |
| 11:19:49 | pixelma | sometimes under certain circumstances |
| 11:20:17 | JdGordon | planet alignment... |
| 11:20:49 | JdGordon | pixelma: any ideas how hard (if possible) it would be to dump some text from the manual to a text file for use in a plugin? |
| 11:21:10 | pixelma | no idea |
| 11:21:41 | | Join dany_21a_ [0] (n=dan@85-127-10-6.dynamic.xdsl-line.inode.at) |
| 11:22:35 | * | B4gder reads about the openmoko removal of code due to mp3 licensing... |
| 11:23:05 | linuxstb | encoder or decoder? |
| 11:23:10 | B4gder | decoder I believe |
| 11:23:17 | linuxstb | And you mean patent licensing? |
| 11:23:19 | scorche | nice thing rockbox isnt based in the US... |
| 11:23:34 | B4gder | linuxstb: i think so, but it's not clear to me yet |
| 11:23:51 | B4gder | http://lwn.net/Articles/307386/ |
| 11:24:21 | pixelma | JdGordon: but if you can do LaTeX > html or pdf then I could imagine that a tool exists that can convert it to txt too. But I don't know too much about it either... |
| 11:25:27 | B4gder | I think they chase after license money even outside the US |
| 11:25:58 | linuxstb | JdGordon: What text do you need? |
| 11:26:18 | B4gder | http://lists.openmoko.org/pipermail/community/2008-November/035635.html |
| 11:26:57 | scorche | B4gder: but depending on the laws of the nation, they may or may not be legally forced to license it to use it legally, no? |
| 11:27:04 | * | scorche looks at that sentence a second time |
| 11:27:06 | B4gder | right |
| 11:29:36 | linuxstb | So openmoko.org are actually selling devices with their software on? |
| 11:29:49 | B4gder | no |
| 11:30:03 | B4gder | or at least I don't think they do |
| 11:30:11 | linuxstb | That's what their home page says |
| 11:30:16 | B4gder | oh |
| 11:30:21 | linuxstb | "Openmoko is currently selling the Neo FreeRunner phone..." |
| 11:30:22 | * | B4gder stand corrected |
| 11:30:52 | B4gder | but there's a .com and an .org and I don't know how much they share |
| 11:35:52 | | Join jeffdameth [0] (n=jeff@dyndsl-095-033-101-135.ewe-ip-backbone.de) |
| 11:36:52 | | Join PaulJam [0] (i=PaulJam_@vpn-3026.gwdg.de) |
| 11:39:36 | JdGordon | linuxstb: just a random thought for now... |
| 11:42:01 | * | linuxstb guesses a settings plugin with help text from the manual |
| 11:43:36 | | Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) |
| 11:46:46 | *** | Saving seen data "./dancer.seen" |
| 11:50:10 | | Quit jeffdameth1 (Read error: 113 (No route to host)) |
| 11:50:14 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 11:50:22 | J-23 | .com = OpenMoko, Inc., .org = OpenMoko developers and users community |
| 11:58:45 | | Join tvelocity [0] (n=tony@adsl6-251.her.forthnet.gr) |
| 12:00 |
| 12:05:12 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
| 12:06:20 | | Quit Sarquah () |
| 12:18:08 | | Part dany_21a_ |
| 12:19:09 | JdGordon | kugel: you mentioned viewporting the statusbar before running off before.... I think everyone agrees the statusbar should be wps-ified instead of just reworking it to fit in a viewport |
| 12:21:04 | | Join dany_21a_ [0] (n=dan@85-127-10-6.dynamic.xdsl-line.inode.at) |
| 12:22:07 | kugel | JdGordon: that doesn't sound contradicting to me |
| 12:23:02 | kugel | Do you think we'll get around putting it into a viewport when wps'ifying? |
| 12:23:22 | JdGordon | I assume both would be done together |
| 12:23:52 | kugel | yes. And I don't think both has to be done with the same patch |
| 12:24:34 | JdGordon | of course not... but there is hardly point doing the viewporting patch until either its wps-ified, or the custom viewport patch (however its done) is finished |
| 12:25:39 | * | JdGordon wants to stir up trouble and suggest the ability to keep the entire screen wps-able with a tag to specify where the list/menu/rest-of-screen should fit |
| 12:25:50 | JdGordon | and keep the wps updated even when not really "in" the wps |
| 12:26:21 | kugel | if I need to viewportify the statusbar for my custom list patch, then I'll do it. But I won't mess with wps'ifying it as well, since it's not what the patchh aims for |
| 12:29:41 | JdGordon | linuxstb: amiconn: B4gder: LinusN: (anyone else awake)? how would you feel about adding a tick task (or something similar) which would be used to tell stuff like the statusbar to redraw instaed of requiring every screen to manually update it? |
| 12:30:30 | linuxstb | What do you mean by "tell the statusbar to redraw" ? |
| 12:30:37 | kugel | JdGordon: keeping the wps updated when it's not shown would be a considerable waste of battery life. 15% difference has been messured in showing the wps vs showing the menu |
| 12:31:12 | JdGordon | linuxstb: well, to update.. instead of having statusbar_update() in every gui loop |
| 12:31:25 | linuxstb | JdGordon: You mean to actually redraw the status bar in a tick task? |
| 12:31:41 | JdGordon | oh crap.. right.. wrong thread |
| 12:32:39 | JdGordon | is there a nice way to have a background timer in the main thread other than sending a message and using the default event handler? |
| 12:33:12 | * | kugel thinks of a viewport manager which issues refreshing every shown viewport periodically |
| 12:33:40 | JdGordon | I implemented that a while ago but got the impression it was overengineering |
| 12:33:53 | JdGordon | its proably still on the tracker |
| 12:35:13 | | Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) |
| 12:36:41 | JdGordon | cant find it |
| 12:37:48 | | Join moos [0] (i=moos@81-66-141-133.rev.numericable.fr) |
| 12:38:15 | | Join tyfoo [0] (n=tyfoo@dyndsl-095-033-095-110.ewe-ip-backbone.de) |
| 12:38:30 | | Join DerDome [0] (n=DerDome@141.71.76.72) |
| 12:39:50 | | Join Nibbler [0] (n=Nibbler@e181066183.adsl.alicedsl.de) |
| 12:40:54 | | Nick Darksair{away} is now known as Darksair (n=user@125.33.193.195) |
| 13:00 |
| 13:11:17 | * | Unhelpful wonders if the extra-large jpeg idct would be a "good" way to bring subsampled chroma planes of jpeg in line with luma |
| 13:20:29 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 13:24:18 | | Quit kugel (Read error: 113 (No route to host)) |
| 13:27:53 | | Quit culture (Read error: 104 (Connection reset by peer)) |
| 13:40:04 | | Join culture_ [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) |
| 13:46:50 | *** | Saving seen data "./dancer.seen" |
| 13:50:53 | | Quit bmbl ("Woah!") |
| 13:52:50 | | Join Bensawsome [0] (n=Bensawso@unaffiliated/bensawsome) |
| 13:56:06 | | Join nplus [0] (n=nplus@141.25.Globcom.Net) |
| 13:57:40 | | Quit DerDome ("Leaving.") |
| 13:58:46 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
| 14:00 |
| 14:00:13 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 14:00:49 | | Part LinusN |
| 14:01:08 | | Quit culture_ (Connection timed out) |
| 14:01:54 | | Join Casainho [0] (n=chatzill@bl10-161-236.dsl.telepac.pt) |
| 14:02:21 | Casainho | hello :-) |
| 14:02:36 | | Join Schmogel [0] (n=Miranda@p3EE21F5F.dip0.t-ipconnect.de) |
| 14:03:53 | | Join Strife89 [0] (i=a810ebb0@gateway/web/ajax/mibbit.com/x-0cdcb6d5286ce5b3) |
| 14:04:02 | Casainho | I am having a problem on a RB port for an ARM MCU, I am having problems with IRQs, system simple hangs when I use them. I made a disassembly and I can't see the IRQ table, can please someone give a look and give opinion? : http://pastebin.com/m207dc0b0 |
| 14:04:33 | | Join TheSphinX^ [0] (n=cold@p54A5D93C.dip.t-dialin.net) |
| 14:05:10 | * | Strife89 is curious as to the changes for r19122. |
| 14:05:42 | Casainho | here is the disassembly: http://pastebin.com/m382e8c5 |
| 14:07:03 | B4gder | I don't really understand the question, but none of them seem to have the exception vectors at that address |
| 14:09:34 | Casainho | B4gder: can you please show me a disassembly of a bootloader.elf, like for example the for the Sansa V2? I would like to compare but I don't have my PC untill next 48 hours... |
| 14:10:36 | Casainho | B4gder: so the problem must be that... for some reason, the elf file don't have the vectors... hmmm, should I see if on crts.o they are there? |
| 14:11:59 | B4gder | iirc, crt0.S copies the exception vectors to address 0x0 |
| 14:12:19 | B4gder | crt0-pp.S |
| 14:12:42 | | Quit LinuxMafia (Remote closed the connection) |
| 14:12:42 | Unhelpful | Nico_P: i was looking to work on a more commit-ready, album-art-only scaling patch. i'm told you're the one to talk to about the metadata-on-buffer stuff, and i wondered if it would be feasible, when we come to loading the album art, to take a piece of buffer for the final, scaled bitmap, and "borrow" a bit more past that for the scaler's temporary use. |
| 14:14:11 | linuxstb | Casainho: Have you looked at the crt0.S files underneath firmware/target/arm/ in Rockbox? Did you base your crt0.S on one of those? |
| 14:14:39 | Casainho | B4gder: but my linker script should put them at that address, because SDRAM starts at it: http://code.google.com/p/rockboxplayer/source/browse/trunk/rockbox_port/firmware/target/arm/at91sam/rockboxplayerlittle/crt0.S −−−− http://code.google.com/p/rockboxplayer/source/browse/trunk/rockbox_port/firmware/target/arm/at91sam/boot.lds |
| 14:15:08 | Casainho | linuxstb: please see that 2 files :-) |
| 14:16:15 | | Quit tyfoo ("Carpe diem") |
| 14:16:56 | Unhelpful | also, what's being borrowed is one line of data in the input size, and several in the output size, if that matters - not enough to load the whole bitmap into buffer. |
| 14:17:43 | linuxstb | Casainho: Please see the Rockbox source code ;) If you worked by modifying existing Rockbox files, things would be much simpler for you. |
| 14:18:16 | linuxstb | But the problem is that your linker script is putting .vectors in the wrong place |
| 14:18:45 | Casainho | oh, I am seeing now... I am putting the section .vectors very after DRAMORIG... may that is the problem! :-( |
| 14:19:28 | Casainho | linuxstb: eheh - seems that :-) I need to work on linker script then ;-) :-) thank you all :-) |
| 14:20:09 | linuxstb | I'll say it again - it will be easier if you start from Rockbox code, and adapt existing files, rather then starting from other source code. |
| 14:20:35 | linuxstb | Rockbox has plenty of working crt0.S and boot.lds combinations for you to use. |
| 14:22:21 | Casainho | linuxstb: but I don't have any explanation of how linker script works on Rockbox pages, but I have that explanation on other example source codes, that's why I am doing like this :-) |
| 14:22:37 | B4gder | Casainho: we're a large crowd here who can explain |
| 14:22:42 | B4gder | and the lds scripts work the same all over |
| 14:22:56 | linuxstb | You could also use the explanations on your example files to help you understand how the Rockbox files work. |
| 14:23:00 | B4gder | ... they put sections in various places in the output |
| 14:23:24 | linuxstb | You will eventually need to understand Rockbox code if you want to port Rockbox to your hardware. |
| 14:24:17 | Casainho | and I am learning, but not taking the straight path... because I even don't know how is it, I am learning.... :-) |
| 14:24:25 | Casainho | thank you :-) |
| 14:28:19 | Casainho | bye bye :-) |
| 14:28:23 | | Quit Casainho ("ChatZilla 0.9.83 [Firefox 3.0.4/2008102920]") |
| 14:30:06 | kugel | Unhelpful: I'm not sure why you now start to make your own bmp resize |
| 14:30:06 | | Quit kugel (Remote closed the connection) |
| 14:30:32 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
| 14:34:45 | | Quit super (Read error: 104 (Connection reset by peer)) |
| 14:36:10 | Unhelpful | kugel: i've been given the impression that reducing the binsize cost will make resize-on-load more commit friendly. stripping out special cases not related to album art will do that. using dynamically allocated scratch space from the buffer will help as well, will it not? |
| 14:37:06 | Unhelpful | i'm not talking about a complete fresh start, more along the lines of reworking the existing patchset to achieve these goals |
| 14:37:34 | kugel | why should we limit the resize feature to album art? |
| 14:38:27 | Unhelpful | because it will satisfy the vast majority of people who want it at all, and limiting the feature will allow the various space savings i mention. |
| 14:38:56 | kugel | also, who says the current patch on the tracker is not commit friendly? |
| 14:39:44 | kugel | we already had a patch which was album art only and used the audio buffer in the pre-buffer phase for temporary cache |
| 14:39:51 | kugel | that was rejected |
| 14:39:53 | Unhelpful | that seems to be what i'm hearing? |
| 14:40:08 | Unhelpful | that patch loaded the whole bitmap into the buffer. this would not. |
| 14:40:31 | | Join funman [0] (n=fun@AToulouse-158-1-121-95.w90-55.abo.wanadoo.fr) |
| 14:40:35 | kugel | that doesn't matter since it's using the audio buffer until it's filled |
| 14:41:07 | kugel | loading the whole bitmap or not doesn't reduce memory free for buffering |
| 14:41:37 | kugel | that's only the case if you're going to a dedicated buffer |
| 14:41:42 | Unhelpful | kugel: it does if the bitmap is not large enough to fit, but the scaled bitmap + file would be. |
| 14:41:49 | | Nick JdGordon is now known as JdGordon|zzz (n=jonno@rockbox/developer/JdGordon) |
| 14:42:08 | n1s | bitmaps can take a fair bit of memory so i agree |
| 14:42:14 | * | B4gder agrees too |
| 14:42:26 | B4gder | 2500x2500 was mentioned before and they can be superhuge |
| 14:42:56 | Unhelpful | even 500x500 3/4MB |
| 14:43:00 | B4gder | yeps |
| 14:43:23 | kugel | but that 3/4 are available for audio after the resizing happened |
| 14:43:26 | n1s | 2500² in 24 bit would take ~18MB :) |
| 14:43:42 | kugel | +MB |
| 14:43:47 | Unhelpful | kugel: not if there aren't 3/4MB available |
| 14:43:50 | B4gder | hopefully a jpeg is compressed ;-) |
| 14:44:25 | * | linuxstb thinks something wrong when the cover art is larger than the track... |
| 14:44:31 | | Join super [0] (i=1000@c80-217-68-219.bredband.comhem.se) |
| 14:44:49 | B4gder | cover art inside the track is wrong by definition imho, as that puts the same art in 10-15 tracks or so |
| 14:45:10 | kugel | Unhelpful: I would it find much better if you contributed to the patch that makes resizing available for different usages |
| 14:45:17 | Unhelpful | linuxstb: depends, if it's jpeg and decompressed is larger than the track, i'm not sure that's quite as wrong. |
| 14:45:34 | linuxstb | Unhelpful: Yes, I thought of that case after I said it... |
| 14:45:37 | Unhelpful | kugel: i'll start there, but i'll definitely not be able to achieve the same reduction for that. |
| 14:45:54 | | Quit amiconn (Nick collision from services.) |
| 14:46:00 | | Join amiconn [50] (n=jens@rockbox/developer/amiconn) |
| 14:46:18 | B4gder | I think a streamlined specified purpose implementation is better than a half-decent generic one |
| 14:46:44 | kugel | why half-decent? |
| 14:46:46 | B4gder | as we don't have any particular jpeg scaling need in the core |
| 14:47:00 | | Quit funman ("leaving") |
| 14:47:16 | Unhelpful | B4gder: in the jpeg case, the scaler needs whole lines, and 8x8 macroblocks need to be decoded at once. so the one line of input width turns into 8... but still not the entire file worth. |
| 14:47:19 | B4gder | I think Unhelpful's way is the way and wasting/assuming audio buffer is half-decent |
| 14:47:57 | Unhelpful | B4gder: the current generic resize patch doesn't do that, it uses fixed-size line buffers, i believe. |
| 14:48:08 | B4gder | aha |
| 14:48:15 | B4gder | then I misunderstood |
| 14:48:52 | kugel | B4gder: the current resize patch is also resize on load. The difference is that it can be used in a more generic way |
| 14:51:18 | n1s | kugel: where else do we need resizing? |
| 14:51:27 | Unhelpful | kugel: what else in the core needs a more generic scaler? i was given the impression that if a more generic scaler would make the core binsize too much larger, that that should be in the plugin lib, and a less generic, smaller one could go in core. |
| 14:51:57 | Unhelpful | n1s: right now, i believe the resize patch handles backdrops, icons, etc? |
| 14:52:35 | | Quit markun (Read error: 104 (Connection reset by peer)) |
| 14:52:52 | n1s | since icons are tiny i expect the result to be quite bad and backdrops should be part of a theme so prepared at the right size |
| 14:52:53 | kugel | iconsets to fit the fonts are an example. Also future features could use it |
| 14:53:11 | kugel | n1s: then you take bigger iconsets and scale them down |
| 14:53:27 | kugel | Unhelpful: have you tested how much binsize you safe? |
| 14:53:36 | Unhelpful | kugel: a small target or source size will make the area scaler results look not so good. |
| 14:53:47 | kugel | against the bmp resize patch? |
| 14:53:52 | Unhelpful | kugel: how am i supposed to test that without actually writing it? |
| 14:54:00 | Unhelpful | which is why i was asking Nico_P :/ |
| 14:54:09 | linuxstb | The static buffer used by the current resize patch is (I think) something like 15KB - so the question is whether we think that's acceptable for the core. But that could be reduced by removing the area sampling version of the resize (that's the version that requires the largest working buffer). |
| 14:54:14 | kugel | I have the feeling you don't safe that much |
| 14:54:41 | Unhelpful | linuxstb: area sampler can be reworked for a *much* smaller buffer. |
| 14:54:58 | kugel | yep, especially if you unify the feature set (e.g. removing area sampling) |
| 14:55:11 | | Join markun [50] (n=markun@rockbox/developer/markun) |
| 14:55:21 | Unhelpful | area sampler is the only half-decent one if you're downscaling by more than 2x |
| 14:55:31 | B4gder | it still makes sense to use the m-o-b to put the art |
| 14:55:34 | Unhelpful | bilinear is not a good scaler in that case. |
| 14:55:35 | linuxstb | kugel: The area sampler uses 5 cache lines, the bilinear one 2 lines. |
| 14:56:10 | kugel | does anyone know why we need full lines? |
| 14:56:27 | kugel | shouldn't the "right" resize be independant in both width and height? |
| 14:56:43 | | Join LambdaCalculus37 [0] (i=44a04303@gateway/web/ajax/mibbit.com/x-1c9319f68bde7c06) |
| 14:56:46 | Unhelpful | linuxstb: it can be done with one cache line easily, for any area size, and with a partial cache line a bit harder. |
| 14:57:15 | kugel | Unhelpful: actually I think scaling by more than 2x will be the typical usecase |
| 14:57:32 | kugel | (except for high res display targets maybe) |
| 14:57:55 | Unhelpful | kugel: i thought so as well, which means the area sampler must stay. |
| 14:58:59 | Unhelpful | also, a resampler will either need a whole line at once, or if it uses chunks, the ability to request the same chunk of at least two different lines. |
| 14:59:05 | kugel | Unhelpful: can you tell me why full-width cache lines are needed? |
| 14:59:48 | Unhelpful | ... i think i *might* know a way to chunk the bilinear sampler, as well. :D |
| 14:59:58 | linuxstb | Unhelpful: So you're thinking of the resampler requesting image data, rather than the image loader calling the resampler? |
| 15:00 |
| 15:00:53 | Unhelpful | linuxstb: yes, or the loader having a sampler state that it passes to the sampler, along with one line of image at a time. |
| 15:02:27 | Unhelpful | kugel: it will be much harder for jpeg, which will be decoding 8 lines at a time, when the sampler needs the next chunk of the first line or two. you'd almost have to decode macroblocks on request (and several times) or cache an entire row of them. |
| 15:05:50 | | Quit kugel (Remote closed the connection) |
| 15:06:06 | | Quit Strife89 ("mibbit.com: Class time.") |
| 15:07:53 | | Join __lifeless [0] (n=lifeless@90.151.208.23) |
| 15:17:30 | | Quit _lifeless (Read error: 110 (Connection timed out)) |
| 15:19:48 | amiconn | Unhelpful: You cannot go back & forth in a jpeg file, because the data is huffman coded. It also looks like the macroblocks for Y, U and V can be ordered in several ways |
| 15:28:54 | | Join jgarvey [0] (n=jgarvey@cpe-098-026-069-229.nc.res.rr.com) |
| 15:37:47 | | Join petur [50] (n=petur@rockbox/developer/petur) |
| 15:40:13 | | Quit moos ("reboot") |
| 15:46:44 | | Quit JdGordon|zzz (Read error: 110 (Connection timed out)) |
| 15:46:52 | *** | Saving seen data "./dancer.seen" |
| 15:48:14 | | Join moos [0] (i=moos@81-66-141-133.rev.numericable.fr) |
| 15:53:11 | | Quit dany_21a_ (Remote closed the connection) |
| 15:53:33 | | Join dany_21a_ [0] (n=dan@85-127-10-6.dynamic.xdsl-line.inode.at) |
| 15:58:29 | | Join tyfoo [0] (n=tyfoo@dyndsl-095-033-095-110.ewe-ip-backbone.de) |
| 15:58:34 | | Join Acksaw [0] (n=omgwtfbb@cpc2-stok5-0-0-cust754.bagu.cable.ntl.com) |
| 15:58:52 | | Join funman [0] (n=fun@AToulouse-158-1-36-88.w90-50.abo.wanadoo.fr) |
| 16:00 |
| 16:02:44 | | Join MethoS [0] (n=clemens@host-091-097-240-047.ewe-ip-backbone.de) |
| 16:05:28 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
| 16:06:26 | funman | kugel: is the SD driver fine on the FuZe, for the embedded SD ? |
| 16:06:52 | kugel | funman: let me try again. Haven't since your commit |
| 16:13:25 | Unhelpful | amiconn: it's *possible*, if you build a macroblock index... doesn't jpeg use one huffman table for the whole file, or at least per-plane? |
| 16:15:34 | | Quit bmbl ("Woah!") |
| 16:15:42 | | Quit lasser ("ChatZilla 0.9.83 [Iceweasel 3.0.3/2008092816]") |
| 16:16:05 | | Quit Acky (Connection timed out) |
| 16:17:00 | n1s | hmm, getting rid of a useless memcpy in midiplayer did nothing for performance, and utilizing the multipliers early termination gave only a slight improvement... |
| 16:17:32 | funman | isn't there some tools for profiling rockbox ? |
| 16:17:58 | n1s | yes, i guess that's what i'll have to do |
| 16:18:18 | linuxstb | Is there any asm in it at the moment? |
| 16:19:27 | n1s | linuxstb: nope, I made a stupid little inline function for doing MUL with expclicit operand ordering and got a small improvement |
| 16:20:02 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 16:20:57 | linuxstb | What does the midi player actually do? I thought it "simply" played instrument samples and mixed them. Or does it need to do lots of DSP-like processing? |
| 16:23:00 | Unhelpful | linuxstb: yes, instrument samples may need stretched and pitch-shifted to the correct duration and tone, i believe? |
| 16:24:36 | n1s | linuxstb: it does a fair bit of multiplication, but i'm not so sure that's the major bottleneck |
| 16:28:47 | | Quit TheSphinX^ (Remote closed the connection) |
| 16:31:20 | n1s | It kind of feels like some big simplification is missing but i can't tell what it should be, ideas are welcome |
| 16:34:24 | | Join ap0 [0] (n=kvirc@mer90-1-88-166-249-88.fbx.proxad.net) |
| 16:37:55 | dany_21a_ | hi funman, i have the recent svn trunk on my fuze some houres ago... in my case it stucks after "Loading firmware" appears... |
| 16:38:00 | funman | some files in firmware/target/arm/tms320dm320/dsp have windows line terminators. Is that allowed ? |
| 16:38:29 | funman | dany_21a_: hello, did you make sure the whole FAT filesystem was within the 1st GB ? |
| 16:38:34 | agaffney | if nothing bitches... |
| 16:39:00 | dany_21a_ | i have inserted some printf into the bootloader in found that it stuck at the fd = open(filename, O_RDONLY); in common.c:210 |
| 16:39:04 | dany_21a_ | funman: uhm... no |
| 16:39:16 | dany_21a_ | okay... how can i do this? |
| 16:39:27 | | Quit Bensawsome (Read error: 60 (Operation timed out)) |
| 16:39:39 | funman | I believe just create a 900MB partition at the beginning of the disk |
| 16:39:44 | kugel | dany_21a_: I formatted my fuze and put nothing but the .rockbox dir on it |
| 16:40:19 | dany_21a_ | kugel okay... will try that |
| 16:40:47 | | Join TheSphinX^ [0] (n=cold@p54A5D93C.dip.t-dialin.net) |
| 16:40:55 | * | kugel wonders if fdinel/atomicpunk has some success with the buttons |
| 16:45:12 | | Join Bensawsome [0] (n=Bensawso@unaffiliated/bensawsome) |
| 16:45:59 | | Join linuxstb_ [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 16:46:11 | | Quit linuxstb (Nick collision from services.) |
| 16:46:11 | | Join toffe82 [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) |
| 16:46:13 | | Nick linuxstb_ is now known as linuxstb (n=linuxstb@rockbox/developer/linuxstb) |
| 16:46:14 | kugel | Hey, abi is doing a survey about audio formats. Something that rockbox should do too imho |
| 16:46:43 | n1s | funman: no, windows linene endings are not allowed |
| 16:46:57 | B4gder | kugel: why? |
| 16:47:14 | linuxstb | B4gder: So we can do lots of nice statistics... |
| 16:47:19 | LambdaCalculus37 | funman: Those need to be fixed to have Unix line terminators. |
| 16:47:27 | B4gder | statistics! yay |
| 16:47:32 | kugel | with nice colorful pie charts etc |
| 16:48:02 | funman | doesn't svn properties include a useful eol-style ? (i remember it was not so useful but i can be wrong) |
| 16:48:15 | | Quit ap0 ("Ba") |
| 16:48:23 | n1s | funman: it does |
| 16:48:39 | n1s | eol-style: native should be used |
| 16:48:41 | linuxstb | But it doesn't seem to be consistently used everywhere in Rockbox. |
| 16:48:48 | funman | too bad i can't set svn properties with git-svn |
| 16:48:49 | linuxstb | What's the default then, if that's not there? |
| 16:49:10 | funman | i would expect keep original line ending |
| 16:49:15 | n1s | linuxstb: default seems to be no properties set at all |
| 16:49:18 | | Join gregorovius [0] (n=diego@host128.190-31-14.telecom.net.ar) |
| 16:50:10 | Nico_P | Unhelpful: hi |
| 16:50:11 | dany_21a_ | funman: yep, the 1GB was the problem... formatted the disk with 500MB now it works... ahm... comes to "ATA error: -2" (have rebooted 5 times) |
| 16:50:24 | | Join Bensawesome [0] (n=Bensawso@unaffiliated/bensawsome) |
| 16:50:35 | | Quit markun ("leaving") |
| 16:50:51 | funman | on something completely different: the dma controller in sansa ams has 2 channels, I expect one to be used for pcm playback and one for SD transfers. But then we couldn't use it for PCM recording: is parallel recording and playback an existing/common feature in rockbox targets ? |
| 16:51:01 | | Quit Bensawesome (Client Quit) |
| 16:51:17 | linuxstb | No, it doesn't exist yet - other targets also have limited numbers of DMA channels. |
| 16:51:52 | funman | dany_21a_: that error must mean that the initialization of the SD slot failed (probably if you have no SD card inserted). I don't know how to fix that since I have no SD slot, perhaps you can look ? |
| 16:52:44 | kugel | dany_21a_: you need to remove that return in the external sd init |
| 16:53:05 | kugel | funman: I've put a quick fix for that to pastebin a few days ago |
| 16:53:21 | dany_21a_ | funman: again true, if i put a MSD into the slot it came some steps further |
| 16:53:31 | kugel | http://pastebin.com/m525569a6 |
| 16:53:35 | funman | kugel: i don't know how rockbox handle SD cards either, so you need to speak with the other devs. (*looks at linuxstb*) |
| 16:54:18 | kugel | funman: it's just that the sd init returns the init of the (optional!) microsd failed |
| 16:54:20 | dany_21a_ | now i see s shiftet screen with *PANIC* Correct status 0x20 (actually only see "orrect"−−- i guess this means correct?) |
| 16:54:38 | linuxstb | funman: I can't help - I've never worked with SD cards in Rockbox. |
| 16:55:39 | funman | kugel: ok looks simple enough to fix |
| 16:55:56 | kugel | funman: removing that return will still init the microsd, but not error out if it failed |
| 16:57:21 | dany_21a_ | funman, kugel any idea why this wont work? normaly i should see a change on GPIOA when plug/unplug USB-power...or? http://pastebin.com/m338d8e4d |
| 16:58:22 | kugel | dany_21a_: I don't know what reset_screen() is. Try lcd_update() |
| 16:58:47 | dany_21a_ | kugel: i see the printf correct (the counter is counting up) |
| 16:59:33 | kugel | dany_21a_: I'm not the gpio expert. But afaik you cannot read and write them at the same time. |
| 17:00 |
| 17:00:09 | kugel | so you would switch the to read every 100ms or so and printf them, and between you set it to write |
| 17:00:50 | kugel | but other people will be able to help you more I'm sure |
| 17:01:05 | dany_21a_ | i just wanted to only read them... and those pins which set as output should not interfere with this |
| 17:01:33 | funman | dany_21a_: the delay is *way* too fast |
| 17:01:46 | funman | iirc a 0x1000000 counter is ~1s |
| 17:02:10 | kugel | I don't think so |
| 17:02:21 | funman | i don't think either, i'm sure ;) |
| 17:02:29 | dany_21a_ | the reset_sreen takse also quite a time... the counter increases about at a 1/10th of secound |
| 17:02:37 | kugel | but it's been some time since I played around with delays so.. |
| 17:03:12 | dany_21a_ | ie. i see the wanted output line correct... but the presented data does not change ... |
| 17:03:21 | | Join linuxstb_ [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 17:04:05 | funman | dany_21a_: I record reading the 8 pins from the same register (3FC) was buggy, and this is why we read them from one register per pin |
| 17:04:30 | | Quit linuxstb (Read error: 104 (Connection reset by peer)) |
| 17:04:39 | | Nick linuxstb_ is now known as linuxstb (n=linuxstb@rockbox/developer/linuxstb) |
| 17:05:16 | dany_21a_ | i also thought that this might be a problem... but could hardly belive it... as it presents valid looking data (eg. not all the same, not all zero, and not all 0xff) - but maybe ill try pin-by-pin |
| 17:06:02 | kugel | dany_21a_: trying to get something to know about the buttons too? |
| 17:06:10 | dany_21a_ | yep :) |
| 17:06:55 | funman | kugel: I committed your fix for the SD slot |
| 17:07:23 | kugel | cool |
| 17:09:28 | funman | thanks :) don't hesitate to shout on me when you have patches :p |
| 17:09:58 | kugel | funman: I will, you know it. |
| 17:10:58 | kugel | B4gder, linuxstb, anyone: want to look at http://www.rockbox.org/tracker/task/9559 ? |
| 17:11:15 | kugel | that'd be particulary usefull to boot from the microsd |
| 17:13:29 | kugel | funman: oh thanks for the credits. but I suppose real names are liked more (not that I need the credit at all :p ) |
| 17:13:57 | gevaerts | kugel: I'd do s/warning/error/ |
| 17:14:11 | kugel | funman: I see, you didn't like the comment |
| 17:14:21 | linuxstb | funman: Yes, please use people's real names in commit messages |
| 17:15:41 | kugel | gevaerts: I made it a warning since it will still search (in / ) for the binary |
| 17:16:21 | funman | kugel: ok next time i'll put your name; and in fact I fixed it before looking at your patch so i didn't add the comment :P |
| 17:16:35 | kugel | ah ok |
| 17:17:24 | funman | gevaerts: or nothing at all, it will error if it's not defined anyway |
| 17:18:40 | | Quit funman ("leaving") |
| 17:18:44 | gevaerts | That too |
| 17:19:27 | linuxstb | And shouldn't it go in all the other bootloaders as well? |
| 17:19:28 | kugel | either way, would be nice if committed |
| 17:19:53 | kugel | linuxstb: isn't load_firmware used by all bootloaders |
| 17:19:55 | kugel | ? |
| 17:20:04 | linuxstb | grep for ".rockbox" in that directory... |
| 17:21:37 | kugel | well, seems it was stupid to think fixing that in common.c would fix it for all bootloader |
| 17:21:47 | * | kugel goes to have a look |
| 17:23:03 | linuxstb | The main-pp.c bootloader is a special case - it loads firmwares in .mi4 format, not the standard Rockbox format. I've no idea what the gigabeast bootloader is up to... |
| 17:24:35 | linuxstb | It seems to be trying /.rockbox/.rockbox/rockbox.gigabeat |
| 17:24:43 | n1s | the bootloaders are a mess of different styles and features |
| 17:25:12 | linuxstb | Then //.rockbox/rockbox.gigabeat |
| 17:26:21 | kugel | gevaerts: add #define BOOTDIR "/.rockbox" after the warning or remove it alltogether? |
| 17:26:59 | gevaerts | kugel: IMO remove it |
| 17:27:03 | n1s | linuxstb: that is weird but could be a leftover from when we had to send rockbox.gigabeat over MTP |
| 17:27:12 | gregorovius | just curious, but do you think it's possible for rockbox to support the video accel chip on the 5g ipods? likely? |
| 17:27:17 | kugel | ok |
| 17:28:01 | n1s | gregorovius: possible, yes likely to happen, no (unless we somehow get the docs) |
| 17:28:08 | linuxstb | n1s: No, I think it's a mistake - it's calling the common load_firmware() function, but passing in "/.rockbox" as part of the filename, which it shouldn't do. |
| 17:30:11 | gregorovius | n1s: reverse-engineering is not possible? |
| 17:31:41 | linuxstb | gregorovius: I think the problem is simply that no-one is very interested - it's just one target amongst the 28 or so that Rockbox runs on, so it's a lot of work for one specific target. |
| 17:31:51 | n1s | gregorovius: it is _technically_ possible but as i said it is unlikely to happen unless we get the docs and afaik amiconn had a brief glance at the code it runs and concluded that it was not arm/m68k/sh or mips so a whole new arch for us |
| 17:32:30 | J-23 | hmm, why sd_init detects if SD card is present? |
| 17:32:37 | J-23 | internal SD is *always* in the slot |
| 17:33:05 | gregorovius | hm, I see |
| 17:36:18 | kugel | linuxstb: indeed |
| 17:36:34 | kugel | linuxstb: I'll have that fixed |
| 17:36:44 | kugel | but I wonder what apple_os.ipod is |
| 17:39:04 | | Join {phoenix} [0] (n=dirk@p54B45AEE.dip.t-dialin.net) |
| 17:40:14 | | Join herrwaldo [0] (n=waldo@ip-81-11-217-235.dsl.scarlet.be) |
| 17:40:59 | | Join sarixe [0] (n=sarixe@ool-43540968.dyn.optonline.net) |
| 17:41:54 | J-23 | yeaah |
| 17:42:06 | J-23 | I get to menu on my e280v2 |
| 17:42:46 | linuxstb | kugel: That's the Apple firmware for ipods... |
| 17:43:01 | gregorovius | one more q: I guess rockbox reads files in any standard artist/album/track structure or similar, and if I understand correctly the original ipod firmare uses a convoluted dir. structure... so rockbox can read music in the itunes structure, but not the opposite? |
| 17:43:21 | | Quit moos ("Rockbox rules the DAP world") |
| 17:43:50 | B4gder | gregorovius: rockbox reads music files wherever you want it to |
| 17:43:52 | | Quit aarcane ("Leaving") |
| 17:44:07 | B4gder | so yes it can read ipod's way but not vice versa |
| 17:44:13 | kugel | linuxstb: I expected that. I don't know how exactly the bootloader works for ipods, so I didn't know the apple of is dumped to a .ipod (or whatever) |
| 17:44:31 | kugel | anyway. I've updated the patch |
| 17:44:40 | B4gder | gregorovius: but the ipod OF messes up the file names and places badly so if you want to keep them like that you want to use the database in rockbox |
| 17:44:57 | kugel | oops |
| 17:45:17 | linuxstb | kugel: It's not normally - that's an optional way to dualboot. |
| 17:45:29 | kugel | ah ok |
| 17:45:32 | gregorovius | I see, thanks |
| 17:45:44 | * | kugel deleted one slash too much |
| 17:46:53 | *** | Saving seen data "./dancer.seen" |
| 17:50:24 | kugel | ok, that should be done now |
| 17:51:21 | kugel | linuxstb, gevaerts: I think it's fine now |
| 17:52:56 | kugel | no, now! |
| 17:53:11 | kugel | being lazy doesn't pay off |
| 17:53:51 | J-23 | and being crazy does ;) |
| 18:00 |
| 18:06:32 | | Part B4gder |
| 18:06:41 | | Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) |
| 18:12:33 | | Join faemir [0] (n=quassel@88-106-238-33.dynamic.dsl.as9105.com) |
| 18:23:20 | | Quit gregorovius (Success) |
| 18:35:14 | amiconn | n1s: According to the .elf header, the machine id for the VideoCore is 0x5f - and that's an unknwon id according to the info about .elf I could find |
| 18:35:25 | | Join beta [0] (i=1000@d36-104-39.home1.cgocable.net) |
| 18:35:52 | n1s | amiconn: aha, so probably some proprietary dsp instruction set? |
| 18:36:27 | amiconn | Test-disassembling with mips and arm objdump didn't produce meaningful code |
| 18:36:42 | amiconn | Yes, I think it's some custom dsp |
| 18:36:53 | | Join dabujo [0] (i=xx@p4FDB00EC.dip0.t-ipconnect.de) |
| 18:39:07 | kugel | dany_21a_: qphow's it going? |
| 18:39:12 | kugel | how* |
| 18:42:49 | n1s | amiconn: so even with docs if someone wanted to code for it they would need to create an assembler or write raw code themselves, not fun :/ |
| 18:44:28 | * | n1s has some limited success with this midi stuff, my testfile now skips less than half as bad as it used to :) |
| 18:44:52 | dany_21a_ | not much... did some googeling if i find someting about how to scan the APB bus for all the PrimeCells (their datasheet suggests that this is possible), only to check if Sandisk has further modified the SoC (beside the secon SD/MMC interface) |
| 18:45:06 | dany_21a_ | no luck so far, (^ kugel) |
| 18:45:47 | linuxstb | n1s: Probably a more feasible approach would be to reverse-engineer the API the main Apple firmware uses to communicate with the broadcom chip, but at best that would just let us do exactly what Apple do with it. |
| 18:46:07 | n1s | linuxstb: true |
| 18:46:36 | n1s | but i guess that's what most of the users want anyway... not that that matters :) |
| 18:47:18 | | Quit Darksair ("Do you hear that? This is the sound of inevitability. This is the sound of your death, Mr. Anderson.") |
| 18:48:12 | | Join Lear [0] (i=chatzill@rockbox/developer/lear) |
| 18:50:01 | amiconn | linuxstb: The names of the library files are interesting. It seems like there is a complete mpeg4 decoder, including aac audio, and that aac decoder passes the pcm stream back to the cpu |
| 18:50:23 | amiconn | h264 fwiw |
| 18:51:20 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 18:51:34 | linuxstb | amiconn: Yes, I noticed those. |
| 18:51:54 | kugel | Ok, the OF does NOT like altered partition table |
| 18:53:03 | kugel | I think I broke my fuze |
| 18:53:42 | kugel | dany_21a_: did your gpio stuff not work? |
| 18:57:18 | kugel | do not, ever, try to format your fuze with gparted |
| 18:59:14 | | Quit ameyer ("leaving") |
| 18:59:53 | | Join BigBambi [0] (n=Alex@rockbox/staff/BigBambi) |
| 19:00 |
| 19:00:10 | | Quit bmbl (Client Quit) |
| 19:01:03 | | Join captainkewl [0] (i=2669ecc2@gateway/web/ajax/mibbit.com/x-9d8a3e0c6b7749d2) |
| 19:06:35 | kugel | dany_21a_: ping |
| 19:07:13 | | Join maffe [0] (n=Miranda@p5B040F78.dip0.t-ipconnect.de) |
| 19:10:20 | dany_21a_ | kugel: the disk you see over usb shouldnt contain a partition-table, its a plain partition...so gparted is not good :) |
| 19:10:46 | kugel | dany_21a_: duh, I rescued it...using windows |
| 19:11:01 | dany_21a_ | kugel: I used "sudo mkfs.vfat -I /dev/sdf 50000" to create a 500MB partition |
| 19:11:30 | kugel | I definitely should've asked you before |
| 19:11:40 | kugel | dany_21a_: so you got nothing with the gpio scan? |
| 19:11:53 | dany_21a_ | still at it... |
| 19:11:58 | dany_21a_ | how did you recover? |
| 19:12:02 | kugel | did you at least receive the usb insertion yet? |
| 19:12:15 | kugel | dany_21a_: well, windows format seems to work flawlessly |
| 19:12:27 | dany_21a_ | ah..okay |
| 19:12:50 | kugel | although I damaged it even more selecting a cluster size, instead of just saying "standardsize" |
| 19:13:05 | kugel | but the of booted, and the pc got it. |
| 19:13:49 | kugel | dany_21a_: I think I were able to recover it with a dump you would've sent me :) |
| 19:15:25 | | Quit maffe ("IRC ist obsolet!") |
| 19:15:58 | dany_21a_ | still see no reaction on usb power... but i'am now able to scan for APB-Blocks... just have to check what the reported ID's mean... so far nothing surprising found |
| 19:16:32 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
| 19:16:40 | | Part domonoky |
| 19:16:45 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
| 19:18:03 | | Quit robin0800 (Success) |
| 19:22:53 | | Join maffe [0] (n=Miranda@p5B040F78.dip0.t-ipconnect.de) |
| 19:25:16 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 19:27:35 | | Quit tyfoo ("Carpe diem") |
| 19:30:00 | | Quit sarixe ("Ex-Chat") |
| 19:32:10 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
| 19:40:13 | Unhelpful | ok... scaling up or down, possibly independently on each axis, with lines the size of the maximum screen dimension, should be doable w/ two of those lines (but of a larger intermediate type), and a line of however many pixels of input you want to accept at once. i *think* it is possible, but some of it too complicated for me to be sure until i have it on paper. i guess the question is, would the binsize minders consider th |
| 19:40:13 | Unhelpful | ose small fixed buffers acceptable, and would the want-it-for-general-use people be happy with that, and the limitation that it can't output at sizes bigger than the screen? |
| 19:41:26 | Unhelpful | i'll work on another test app when i have time, since i think the design will be useful even if we're going to insist on using buffer space for the temp data. |
| 19:44:35 | | Join miepchen^schlaf [0] (n=miepchen@p579ECC64.dip.t-dialin.net) |
| 19:46:58 | *** | Saving seen data "./dancer.seen" |
| 19:47:01 | | Join culture_ [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) |
| 19:48:35 | J-23 | ls |
| 19:48:37 | | Join DerDome [0] (n=DerDome@dslb-082-083-218-228.pools.arcor-ip.net) |
| 19:48:39 | J-23 | argh :D |
| 19:48:47 | J-23 | dany_21a_: you probably need to reformat your player |
| 19:50:18 | dany_21a_ | J-23... nooo dont want to :) (maybe you mean kugel) |
| 19:50:32 | dany_21a_ | btw, kugel... did you recover your player now or not? |
| 19:50:40 | J-23 | 16.37.55 # <dany_21a_> hi funman, i have the recent svn trunk on my fuze some houres ago... in my case it stucks after "Loading firmware" appears... |
| 19:51:39 | dany_21a_ | ah.. okay - solved that error by formating the partion as a ~500MB vfat |
| 20:00 |
| 20:00:40 | | Join ibseo [0] (n=hd@p5B161939.dip0.t-ipconnect.de) |
| 20:01:38 | | Quit maffe ("IRC ist obsolet!") |
| 20:01:53 | amiconn | Unhelpful: I think 2 lcd-width lines of buffer are perfectly okay. I guess intermediate type is 32 bit for speed? |
| 20:02:18 | domonoky | hm, sd-driver on v2 works now really nice on m200v4. But it still could potentially yield() when the interrupts are disabled.. |
| 20:02:58 | amiconn | domonoky: Then the next step should be to get rid of the interupt disabling |
| 20:03:28 | domonoky | amiconn: yes, thats getting the DMA controller to work... i still need to read up more on it... |
| 20:06:59 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 20:11:23 | | Quit __lifeless (Read error: 104 (Connection reset by peer)) |
| 20:11:26 | | Join _lifeless [0] (n=lifeless@90.151.208.23) |
| 20:15:41 | | Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) |
| 20:17:57 | kugel | dany_21a_: yes |
| 20:26:13 | | Join darkham [0] (n=ubuntu@host220-183-dynamic.53-79-r.retail.telecomitalia.it) |
| 20:26:33 | | Join markun [50] (n=markun@rockbox/developer/markun) |
| 20:26:55 | | Join funman [0] (n=fun@AToulouse-158-1-135-122.w90-38.abo.wanadoo.fr) |
| 20:27:42 | | Join mia38 [0] (n=flahfhlq@114-134.mg.cgocable.ca) |
| 20:29:46 | | Quit TheSphinX^ ("XChat@Linux") |
| 20:30:32 | kugel | dany_21a_: did you already see the main menu? |
| 20:30:55 | kugel | I saw it once, shorty (followed by a data abort) |
| 20:31:28 | | Join mia-38 [0] (n=flahfhlq@114-134.mg.cgocable.ca) |
| 20:31:47 | | Quit mia38 (Client Quit) |
| 20:32:26 | | Quit ibseo ("quit") |
| 20:33:13 | | Quit mia-38 (Client Quit) |
| 20:33:30 | dany_21a_ | kugel: no... havent seen the menu sofar on my fuze :/ |
| 20:33:59 | funman | kugel: strange, did you check where in the binary this data abort happened (with objdump on rockbox.elf) ? |
| 20:34:36 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 20:34:42 | kugel | funman: no. I'm experiencing many data aborts trying to boot rockbox |
| 20:35:47 | | Quit Schmogel (Read error: 104 (Connection reset by peer)) |
| 20:36:34 | kugel | funman: that was before your commit (with domonoky's diff though) |
| 20:37:48 | domonoky | it seems the fuze has other/different problems.. the sd-driver is very stable on m200v4 now.. |
| 20:37:53 | kugel | funman: here's my discussion with domonoky. I somewhere mention the adress of the data aborts http://www.rockbox.org/irc/log-20081115#20:00 |
| 20:39:05 | domonoky | kugel: is the sd-driver in the bootloader working reliable ? (ie no checksum errors? ) |
| 20:39:28 | funman | the adress is useless without the binary, but i suppose with the commit which really make sd_write_sectors() fail it's gone |
| 20:40:09 | kugel | domonoky: I'm right know trying svn |
| 20:41:51 | funman | domonoky: i started reading the pl081 (dma controller) datasheet, but i've no prior experience with dma |
| 20:42:06 | kugel | funman: another problem on the fuze is that the display is shifted left by some 15-20px |
| 20:42:07 | domonoky | funman: same for me :-) |
| 20:42:52 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 20:43:10 | funman | kugel: perhaps the screen is smaller than the controller's area. Try to do precise mesures with lcd_draw_(h|v)line and look at how it is done in the Clip LCD driver (it's shifted by 2 pixels) |
| 20:43:44 | funman | draw a vertical line at offset x, see if it's displayed. draw at offset x+1, .. |
| 20:43:56 | kugel | funman: it only happens in the binary (not in the bootloader) as far as I can see |
| 20:44:57 | funman | domonoky: perhaps this can be useful: ubuntu.com/73446/">http://paste.ubuntu.com/73446/ :) |
| 20:45:05 | kugel | btw: svn gives me: incorrect status 0x20 (well, I can only see orrect status, but going after your commit it can only be line 599 (incorrect status) |
| 20:45:59 | domonoky | kugel: 0x20 is the fifo overrun, i think. strange. |
| 20:46:22 | funman | kugel: do you have the pl180 datasheet ? 0x20 is bit 5 set: RXOVERRUN |
| 20:46:39 | kugel | no, I don't have this |
| 20:47:01 | funman | you should test this bit, and jump with goto just before sending the SD_STOP_TRANSMISSION command |
| 20:47:30 | funman | kugel: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0172a/index.html |
| 20:47:56 | funman | see the description of MCIStatus register for the meaning of each bit |
| 20:48:12 | domonoky | but seems strange that he is getting overruns when we busyloop and have interrupts disabled.. is the sd interface so fast that we miss it in this few instructions ? |
| 20:48:43 | funman | the peripheral clock is running at 64MHz, no idea about the 'mclk' clock used in the pl180 |
| 20:49:44 | kugel | funman: could it be related to the wrongly recognized capacity? I haven't changed anything regarding that yet. And I also didn't create a <1GB partition |
| 20:49:51 | | Join AndyIL [0] (i=AndyI@212.14.205.32) |
| 20:50:41 | | Nick scorche|1h is now known as scorche|sh (n=scorche@squisch.net) |
| 20:51:18 | funman | I don't think so, but you will confirm, won't you ? :) |
| 20:58:09 | Unhelpful | amiconn: is 32-bit going to be fastest, generally? |
| 21:00 |
| 21:00:48 | linuxstb | kugel: Regarding your LCD offset problem, try swapping "0" and "20" in the lcd_set_flip() function in lcd-fuze.c |
| 21:01:26 | | Quit AndyI (Read error: 110 (Connection timed out)) |
| 21:03:31 | funman | which records me some lcd functions are still to be done for the sansa clip ... |
| 21:03:38 | Unhelpful | hrm, C locals go on the stack, right? would buffer of that size on the stack be a problem, or should there be a single global buffer (which will also make the scaler non-reentrant, of course) |
| 21:04:02 | kugel | linuxstb: yep that did it |
| 21:06:30 | linuxstb | kugel: OK, thanks. I'll commit. |
| 21:07:17 | kugel | funman: I suppose the sd driver is stable. The bootloader executes rockbox on every try. Just the main binary fails |
| 21:07:39 | kugel | i.e. it says executing just fine |
| 21:07:58 | kugel | funman: btw: the 10s poweroff is rather annoying imho |
| 21:08:18 | funman | the bootloader use of sd is simple enough to not trigger much problems |
| 21:08:36 | funman | kugel: not being able to use the power button is more annoying for me |
| 21:08:57 | domonoky | kugel: why is it annoying ? it allows us to use the menu/power button.. (not on fuze of course :-) ) |
| 21:09:17 | | Join sin613 [0] (n=pbarton@host-8-122-107-208.midco.net) |
| 21:09:18 | kugel | domonoky: well, as long as I only get panicfs I'd rather have a fast shutdown :p |
| 21:09:48 | domonoky | kugel: and you can easily put a if def around it, on your local code... |
| 21:09:51 | funman | you could but a delay and then a power_off() into panicf() ? |
| 21:12:19 | kugel | huh? |
| 21:12:48 | funman | of course domonoky solution is simpler |
| 21:14:18 | * | linuxstb isn't sure how we would want to use the power button on the clip though |
| 21:16:05 | funman | it's stop/go back in the keymap at the moment, but feel free to modify it :) |
| 21:17:16 | linuxstb | That seems about as good as anything... |
| 21:18:52 | | Join lasser [0] (n=chatzill@W8f7c.w.pppool.de) |
| 21:19:55 | kugel | I'd agree to have it has generic stop button for all screens |
| 21:20:42 | funman | it could have another function, i really don't want to mess with the keymap. |
| 21:23:07 | | Join aarcane [0] (n=aarcane@c-67-187-242-146.hsd1.ca.comcast.net) |
| 21:26:09 | | Join fml [0] (n=4fd3c724@gateway/web/cgi-irc/labb.contactor.se/x-d64904f642791816) |
| 21:26:44 | fml | Hello. Anyone here to commit FS #9557? |
| 21:31:55 | | Quit Nibbler (Read error: 104 (Connection reset by peer)) |
| 21:34:59 | | Quit nplus (Remote closed the connection) |
| 21:37:04 | | Join Aicart [0] (n=aideb@unaffiliated/aicart) |
| 21:37:07 | Aicart | Hi |
| 21:37:19 | Aicart | Can I restore my ipod without Itunes ? |
| 21:38:05 | BigBambi | Yes, one mo |
| 21:38:10 | | Quit denes_ (Read error: 113 (No route to host)) |
| 21:38:39 | | Join denes_ [0] (n=denes@pool-8227.adsl.interware.hu) |
| 21:38:40 | BigBambi | http://www.rockbox.org/twiki/bin/view/Main/IpodManualRestore |
| 21:39:29 | Aicart | oh thanks :) |
| 21:42:12 | | Quit {phoenix} (Read error: 104 (Connection reset by peer)) |
| 21:46:37 | | Join Strife89 [0] (n=michael@204.116.245.152) |
| 21:46:59 | *** | Saving seen data "./dancer.seen" |
| 21:48:26 | | Quit lasser (Read error: 110 (Connection timed out)) |
| 21:48:36 | dany_21a_ | funman: i get that "incorrect state 0x20" when the function sd_read_sectors gets called with incount=1 could that be a path to a bug? (ie. a off by one or smth. I dont fully (nearly anyhow) understand the sd-transfer code) |
| 21:49:24 | dany_21a_ | (actually the state is 0x22A020 - so the half-full-bit is set |
| 21:49:26 | dany_21a_ | ) |
| 21:49:38 | funman | the SD controller fills the FIFO. so we wait until it's half full, and read the half, then we wait again, read etc .. |
| 21:49:40 | | Join Nibbler [0] (n=Nibbler@e181114058.adsl.alicedsl.de) |
| 21:50:05 | funman | when the FIFO is full and the controller tries to write data, the rx overrun bit is set to notify that we have lost some data |
| 21:50:59 | funman | i means we were not fast enough to read/empty the FIFO to leave room for further data read |
| 21:51:08 | dany_21a_ | okay... could the incount=1 (and therfore half means 1/2=0) make problems? |
| 21:51:22 | | Join ap0 [0] (n=kvirc@mer90-1-88-166-249-88.fbx.proxad.net) |
| 21:51:25 | funman | no, incount is a number of sectors (512 bytes) |
| 21:51:51 | funman | the FIFO is 16*32 bits wide and we read the half (8 32 bits words) at each time |
| 21:51:51 | | Join massiveH [0] (n=massiveH@pool-71-187-243-194.nwrknj.fios.verizon.net) |
| 21:52:29 | funman | if you see the rxoverrun bit set, goto just before the send_cmd(.. SD_STOP_TRANSMISSION) to try again to transfer this full sector |
| 21:52:33 | | Join draft [0] (n=draft@222-209.adsl.lpoy.dnainternet.fi) |
| 21:52:37 | funman | or group of 1-127 sectors |
| 21:52:51 | draft | is there any way to format iPod Mini's memory from Rockbox? |
| 21:53:05 | draft | i think it might have some bad sectors or something |
| 21:54:35 | dany_21a_ | can the FIFO overrun with incout=1=>512byte at all? (16*32=512, so it actually should get full, but not overrun) |
| 21:55:23 | n1s | draft: not inside rockbox no, you need to use the original firmware's disk mode to access the drive from a computer |
| 21:56:15 | funman | dany_21a_: the FIFO is 16*32 bIts, and we can transfer minimum 512 bYtes (*8) so it will overrun if we don't empty it while it's being filled |
| 21:58:31 | | Join shotofadds [0] (n=rob@rockbox/developer/shotofadds) |
| 21:59:19 | | Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") |
| 21:59:32 | dany_21a_ | funman damn.. thx... y!=i |
| 22:00 |
| 22:01:34 | pixelma | bits != bites too ;) |
| 22:03:07 | funman | :) |
| 22:06:00 | draft | n1s: so i need install itunes |
| 22:06:02 | draft | ... :| |
| 22:06:33 | n1s | draft: that is not what i said, you need to do it from the computer is what i said |
| 22:07:10 | n1s | see this page http://www.rockbox.org/twiki/bin/view/Main/IpodManualRestore |
| 22:07:54 | n1s | i thought you just had some file system corruption though, not that you were in need of a full-blown restore |
| 22:09:28 | Aicart | I have crashed it ! |
| 22:09:28 | Aicart | xD |
| 22:09:49 | Aicart | I can enter to the test tool but the computer doesn't recognize it |
| 22:10:41 | Aicart | It's call Ipod Diagnostincs |
| 22:12:08 | Aicart | in disk mode ... i'll try |
| 22:14:05 | | Join merbanan [0] (n=banan@83.233.243.188) |
| 22:15:46 | | Quit Lear ("ChatZilla 0.9.83 [Firefox 3.1b2pre/20081114034305]") |
| 22:15:52 | | Quit draft ("Lost terminal") |
| 22:19:25 | | Join saratoga [0] (n=9803c264@gateway/web/cgi-irc/labb.contactor.se/x-9f73f515af348274) |
| 22:20:32 | saratoga | is DMA ever used outside of drivers? |
| 22:21:13 | | Quit merbanan (Remote closed the connection) |
| 22:21:29 | Bagder | no, I don't think so |
| 22:21:33 | n1s | saratoga: how do you mean? |
| 22:22:22 | funman | it could be used in memcpy() if i understand correctly |
| 22:23:04 | Unhelpful | funman: it's not too often called "DMA" when only the CPU is doing it, though, is it? |
| 22:23:26 | n1s | on coldfires pcm_play_data uses the dma (indirectkly), i'm not sure if that counts as driver usage though |
| 22:23:35 | funman | it wouldn't be the CPU here, but the DMA hardware |
| 22:23:54 | funman | i.e. use the hardware to copy from memory to memory |
| 22:23:59 | domonoky | the DMAC in the as3525 can do mem-to-mem transfers... |
| 22:24:38 | * | shotofadds got red but can't see an error in the build log... is the script dependant on the rockbox.xxx output file? |
| 22:24:40 | Unhelpful | funman: oh, in that case, that's DMA... i guess i'd not call memcpy a driver. |
| 22:24:42 | funman | seeing how simple these PrimeCell chips seem to be, I believe it's a common feature to other hardware (just a supposition) |
| 22:25:03 | n1s | on the coldfires the dma can not access (all of the) iram though so having memcpy rely on it there would be nasty |
| 22:25:13 | saratoga | funman: the problem with using it for memcpy is that its probably slower then having the CPU do it |
| 22:25:15 | shotofadds | because that changed from rockbox.iaudio to rockbox.d2 in this revision (since the d2 has never been an iAudio-branded player) |
| 22:25:15 | domonoky | but we only have two channels.. so we probably should only use it for audio and sd... |
| 22:25:19 | | Quit Aicart (Remote closed the connection) |
| 22:25:31 | Bagder | shotofadds: ah yes that's probably it |
| 22:25:39 | * | Bagder takes a peek |
| 22:26:35 | Bagder | shotofadds: for the bootloader as well? |
| 22:26:42 | funman | domonoky: do you understand how we specify the source/destination peripherals in DMAC_C(0|1)_CONFIGURATION register ? the peripheral ID is 4 bits wide but I don't know what's the value for, say, PL180 |
| 22:26:45 | saratoga | anyway was just wondering about using it in codecs, although it seems like most DMA controllers are too limited to be really useful anyway |
| 22:27:38 | shotofadds | Bagder: I don't think the rockbox.d2 is actually used in the bootloader build. the useful file is actually bootloader/bootloader.bin |
| 22:28:31 | Bagder | well, it is built anyway ;-) |
| 22:28:33 | shotofadds | Of course this change also forces people to update their D2 bootloaders, but I figured it was a good time since reading in the new NAND driver seems pretty reliable ;) |
| 22:28:54 | shotofadds | Bagder: the answer to your question was yes ;) |
| 22:29:10 | | Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) |
| 22:29:17 | Bagder | good d2 news anyway |
| 22:30:20 | | Quit dabujo ("( www.nnscript.com :: NoNameScript 4.2 :: www.regroup-esports.com )") |
| 22:30:44 | shotofadds | yes, very good news - it seems very reliable here. I need to do some more hacking to make it work reliably on M200/DAX, then I might think about write support... |
| 22:31:19 | shotofadds | preglow has been having some successes with the SD code recently too, so things are looking up! |
| 22:31:29 | saratoga | has vitja been around lately? i figured he'd want to take a look at the NAND access on TCC eventually, he seems to have a knack for that sort of thing |
| 22:31:49 | shotofadds | I haven't seen him for a while.. I might ping him an email at some point |
| 22:32:25 | #>> | "seen" used by Zagor (n=bjst@rockbox/developer/Zagor) [snoop prevented] |
| 22:34:10 | | Join bluebrother [0] (n=dom@rockbox/staff/bluebrother) |
| 22:35:42 | | Quit Thundercloud (Remote closed the connection) |
| 22:35:53 | | Quit darkham ("Sto andando via") |
| 22:39:33 | | Quit n1s () |
| 22:42:54 | | Join toffe82_ [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) |
| 22:44:48 | domonoky | funman: no, i dot really understand how the eripheral selection should work. it looks like the DMAC has different dma-request lines, you you have to select the right one, which is connect to the needed peripheral.. |
| 22:45:48 | funman | ah right, I thought there was some logic with the 'PrimeCell ID' available for each peripheral connected to the bus, but maybe it's some hardwired lines |
| 22:46:32 | domonoky | it looks like, but i am not sure... |
| 22:46:42 | | Quit toffe82 (Read error: 60 (Operation timed out)) |
| 22:46:52 | | Nick toffe82_ is now known as toffe82 (n=chatzill@h-74-0-180-178.snvacaid.covad.net) |
| 22:48:15 | dany_21a_ | funman: for it looks like you can make the DMA "listening" on various bits in some (but dunno how defined) Statusregister (which may hardwired, or maybe direct by address)... look in the pdf for the MMC: "TxHalfEmpty Set to HIGH when 8 or more transmit FIFO words are empty. This flag can be used as a DMA request." |
| 22:48:17 | domonoky | the as3525 datasheet also says the dmac provides 16 dma request lines.. so its hardwired.. |
| 22:49:07 | linuxstb | saratoga: I _think_ someone implemented a memcpy using DMA for the Gigabeat F, but IIRC it was reverted. I can't remember the details though. |
| 22:50:06 | | Join Simoj [0] (n=Simoj@80-47-166-244.lond-th.dynamic.dial.as9105.com) |
| 22:50:12 | markun | linuxstb: I believe it turned out to be slower |
| 22:50:14 | funman | dany_21a_: yup, we can use this bit (in MCIMask0 and 1) to trigger an interrupt and start a DMA transfer, but I understand that the DMA controller must be properly setup first |
| 22:50:45 | markun | but in the early days of the port we didn't really benchmark |
| 22:52:47 | funman | r4406 mention patch #917153 - did you use something else than FlySpray ? |
| 22:53:40 | linuxstb | markun: Which reminds me, there's still an assembler bitmap drawing function in the gigabeat lcd driver that needs benchmarking - and then either used on other targets or reverted... |
| 22:53:46 | | Join darkham [0] (n=ubuntu@host220-183-dynamic.53-79-r.retail.telecomitalia.it) |
| 22:55:56 | preglow | shotofadds: went away for the weekend, back now, and will continue prodding sd tomorrow |
| 22:56:21 | preglow | though i still can't read proper data for it, at least now the fifo fills with the correct number of bytes, but only for sdhc cards |
| 22:56:28 | | Part Simoj ("Leaving") |
| 22:56:28 | preglow | sd cards still bug out for some reason |
| 23:00 |
| 23:03:37 | captainkewl | linuxstb: re mikmod codec, sorry I haven't gotten back to you on this yet. Rough past few weeks. I have stripped out a lot of unnecessary code −− drivers and routines that just aren't used. Right now the working build only supports the 4 main types (and XM seems to be a bit broken right now). I don't know how much memory actually is used by each type, but revisiting the plugin might be worthwhile to that end. |
| 23:04:12 | shotofadds | preglow: you just know that'll be some daft typo somewhere ;-) btw. when you get a chance, do try out the new nand driver. I haven't had a single failed boot for >1 week and I can't quite believe it's true.. |
| 23:04:31 | captainkewl | My thinking at this point isn't so much that things need to be changed for the codec api as it is that maybe mikmod should just be left as a plugin −− for probably the same reasons that midi is. |
| 23:04:34 | | Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) |
| 23:05:55 | pixelma | captainkewl: have you had a look at how the current mod codec works? |
| 23:05:55 | captainkewl | Also slightly hung up on some dependencies on functions defined in firmware/common and how to address them without bloating the build unnecessarily −− might be tied to the way XM is malfunctioning. |
| 23:06:30 | linuxstb | What functions in firmware/common/ do you need? |
| 23:06:58 | captainkewl | Enough to know how files are loaded, but I'm not entirely sure what it does with any other memory it needs. |
| 23:07:42 | | Quit fml ("CGI:IRC (EOF)") |
| 23:07:49 | captainkewl | strncmp, strncpy, random |
| 23:07:53 | | Quit massiveH (Read error: 113 (No route to host)) |
| 23:08:53 | linuxstb | They should all be in the plugin API - you can't use them directly. |
| 23:09:01 | captainkewl | And then there's the whole malloc deal. |
| 23:10:11 | linuxstb | Ideally you should get rid of all mallocs, and use fixed-sized buffers instead. That would allow you to know exactly how much RAM is required for decoding. |
| 23:10:32 | preglow | shotofadds: will do |
| 23:10:57 | pixelma | IIRC the current mod codec could play my 2 mods that were larger than the codec buffer (they would fit now in the larger one so can't test anymore) |
| 23:11:23 | captainkewl | Right, I'm just not sure there's any way to predict that and it's really sort of out of my depth. |
| 23:11:49 | * | kugel wonders why bluebrother is so particulary keen on using that "string" CONSTANT "string" stuff |
| 23:12:05 | linuxstb | captainkewl: How big are the actual files you play? |
| 23:12:25 | bluebrother | kugel: it's simply more efficient |
| 23:12:32 | captainkewl | I've seen IT and XM files at 1mb or so. |
| 23:12:43 | gevaerts | Unhelpful: I just had a look at your area scaling tests, and I think they are most probably good enough |
| 23:12:50 | bluebrother | needs less RAM, less const data and less processing time. |
| 23:12:52 | kugel | bluebrother: in which way? |
| 23:13:17 | kugel | also: "this can be done simpler" != "this can be done more efficiently" |
| 23:14:07 | bluebrother | well, not requiring printf to do any replacements is simpler *and* more efficient |
| 23:14:14 | bluebrother | so what's your point? |
| 23:14:38 | pixelma | linuxstb: I have an .it file that's almost 8MB but usually they are smaller... the largest .mods I had are less than 1MB (not sure how represantative my collection is though) |
| 23:14:59 | kugel | I'd be surprised if gcc wouldn't optimize it at compile time anyway |
| 23:15:17 | kugel | but I say it again, I really don't care, so if that's the show stopper, change it |
| 23:15:20 | | Quit MethoS (Remote closed the connection) |
| 23:15:28 | bluebrother | feel free to check it |
| 23:15:42 | Bagder | gcc won't optimize away a %s usage |
| 23:15:50 | | Join MethoS [0] (n=clemens@host-091-097-240-047.ewe-ip-backbone.de) |
| 23:15:52 | Unhelpful | gcc can't always optimize away user-defined functions based on the constancy of their inputs |
| 23:15:55 | linuxstb | bluebrother: One issue is if the constant is used in multiple places - if you keep it separate, then it might actually reduce size to use %s with it... |
| 23:15:58 | Unhelpful | in fact, i rather doubt it ever can. |
| 23:15:59 | bluebrother | printf is a rather complex function, so I don't think gcc _can_ even optimize it away |
| 23:15:59 | kugel | Bagder: if the argument is a literal constant? |
| 23:16:09 | Bagder | no, it won't |
| 23:16:25 | Nico_P | Unhelpful: hi, you wanted to talk to me? |
| 23:16:28 | bluebrother | linuxstb: true, if you put it into const data and use a pointer to it. |
| 23:16:46 | linuxstb | bluebrother: IIUC gcc should optimise away duplicate const strings |
| 23:17:04 | bluebrother | ah. That's nice. |
| 23:17:16 | bluebrother | though I wouldn't want to trust the compiler that much ;-) |
| 23:18:04 | domonoky | you never know what gcc does.. we have often see it doing stupid things... |
| 23:18:14 | Unhelpful | Nico_P: yes, but it might be too early, after some talking with other people. i'm working on a smaller rescaler, but there seem to be more than a few people who want it to work for non-album-art cases, so i'm thinking i should at least implement a first test without using the buffer for scratch space. |
| 23:18:43 | Nico_P | I agree |
| 23:18:45 | * | bluebrother sees a commercial compiler doing stupid things every other day |
| 23:19:24 | linuxstb | Unhelpful: So how small do you think you can make the temporary buffer? |
| 23:19:24 | * | domonoky thinks every compilier does stupid thing if you look at the gernated asm... :-) |
| 23:19:35 | bluebrother | domonoky: true ;-) |
| 23:19:36 | kugel | linuxstb: so what's your point of view in this case? |
| 23:19:40 | Nico_P | Unhelpful: lately I've been thinking of a way to get the playback thread to free some buffer space so that others (typically plugins) can get some. I guess it could also be helpful for scaling |
| 23:19:54 | bluebrother | now put in a crappy cpu architecture and have real fun :) |
| 23:20:09 | kugel | "%s", BOOTFILE or BOOTFILE "" |
| 23:20:14 | linuxstb | kugel: Personally, I would have written it like bluebrother - my instinct is to do things at compile-time whenever possible. |
| 23:20:18 | Nico_P | Unhelpful: how much scratch space is going to be needed? |
| 23:20:23 | Unhelpful | linuxstb: i don't think i can do away with having two output-line-sized buffers of a larger type, uint32 has worked well in my test case and i'm told it should be fast to manipulate |
| 23:20:32 | | Quit petur ("Zzzzz") |
| 23:21:04 | Unhelpful | but, i could easily clamp the output line size at the largest dimension of the screen - i can't see any reasonable use for scaler output larger than the screen. |
| 23:22:23 | linuxstb | If you just need output-line-sized buffers, then that's going to be fine - you should be able to allocate it on the stack. |
| 23:22:59 | gevaerts | Unhelpful: I assume that's 32bit per pixel per colour? |
| 23:23:34 | gevaerts | So screen width * 3 * 32bit * 2 lines? |
| 23:23:37 | Unhelpful | there will also be a need for whatever-is-deemed-a-reasonable-size of raw input data - i'm fairly sure i can make both bilinear and area scalers work without having a whole line, and i think perhaps the display width would be a reasonable chunk size, or we could just make it 256. |
| 23:24:09 | | Quit bmbl ("Woah!") |
| 23:24:25 | Unhelpful | gevaerts: that's what i'm working with at present. i don't think i can do the temp data in chunks, because one line of final output will have contributions from more than one line of input. |
| 23:24:37 | | Join tyfoo [0] (n=tyfoo@dyndsl-095-033-066-206.ewe-ip-backbone.de) |
| 23:25:09 | gevaerts | You could if you allow seeking in the source, but that's madness |
| 23:25:31 | Unhelpful | gevaerts: that was my opinion as well. |
| 23:26:07 | gevaerts | So we're looking at about 8k on the biggest current supported target |
| 23:26:29 | Unhelpful | i'm trying to work on the chunked line scalers, but i'll have to start trying to wake up the rest of my family soon, and my mind says, "there's not enough time to get anywhere, why start?" |
| 23:29:27 | | Quit reacocard (".") |
| 23:29:34 | | Quit Strife89 (Remote closed the connection) |
| 23:29:50 | Unhelpful | ...is 8KB really reasonable to allocate on stack? |
| 23:30:26 | gevaerts | It depends on the thread you're in I guess, but is seems a bit big to me |
| 23:31:15 | Unhelpful | also, i could use screen width instead of largest screen dimension, if i can assume that inputs are row-then-column ordering. |
| 23:31:22 | linuxstb | I think the stack is 9KB, so no, not reasonable... |
| 23:32:58 | Unhelpful | that would only be different on portrait targets, anyway, and i need to find out if that assumption is valid or not... but i can't find anything that states what order JPEG macroblocks are stored in. |
| 23:34:52 | Unhelpful | linuxstb: that brings us back, then, to saying an extra ~8KB of core binsize for static buffers, or doing it on the buffer, and not really having it usable outside of album art. |
| 23:35:04 | Unhelpful | neither of those options will satisfy everybody |
| 23:36:03 | gevaerts | Unhelpful: I still haven't seen a real example of in-core non-AA scaling though |
| 23:36:11 | Llorean | No option ever satisfies everyone. |
| 23:36:38 | Unhelpful | gevaerts: people want it for icons, or for backdrops, etc. |
| 23:36:43 | gevaerts | Icons don't count IMO as they are much smaller, so even if those are wanted they can be done on the stack |
| 23:36:44 | | Join jeffdameth1 [0] (n=jeff@dyndsl-095-033-065-036.ewe-ip-backbone.de) |
| 23:36:54 | | Quit jgarvey ("Leaving") |
| 23:37:06 | gevaerts | And backdrops? Do you really need to scale those? |
| 23:37:06 | Llorean | I don't think scaling for backdrops is suitable. |
| 23:37:11 | Unhelpful | gevaerts: but that means having two copies of the scaler, one with stack allocation. |
| 23:37:14 | Llorean | They should be pre-scaled as part of a theme. |
| 23:37:22 | | Quit jeffdameth (Read error: 60 (Operation timed out)) |
| 23:37:41 | Unhelpful | Llorean: i agree, they're a theme component, but i am only saying what was said when i tried to talk about this as an album-art-only thing |
| 23:37:46 | gevaerts | Unhelpful: not really. You just have two memory allocators at the start to choose from |
| 23:37:53 | gevaerts | The rest is still the same code |
| 23:37:57 | Llorean | I'm still in the "asking users to scale any image, once, is not unreasonable" |
| 23:38:21 | | Quit domonoky (Read error: 104 (Connection reset by peer)) |
| 23:38:34 | gevaerts | Album art is annoying because you want to copy the same files to all your players, and you want to switch themes, but backdrops? |
| 23:39:29 | Llorean | I think we're really trying to address the "switch themes" issue more than anything else. |
| 23:40:01 | Unhelpful | gevaerts: does rockbox have a way for me to allocate from the stack, after function start? |
| 23:40:10 | | Join reacocard [0] (n=reacocar@WL-112.CINE.HMC.Edu) |
| 23:40:46 | Unhelpful | Llorean: that's the issue i care about. and i wouldn't mind if the scaler can handle album art which might be larger than the screen - which i'm pretty sure it can do, now. |
| 23:41:22 | funman | Unhelpful: int[10000000] ? |
| 23:41:42 | funman | you can use int[i] for dynamic size allocation also |
| 23:41:50 | | Quit darkham (Read error: 104 (Connection reset by peer)) |
| 23:42:13 | gevaerts | Yes, but that's not very convenient for this case I think |
| 23:42:14 | | Join darkham [0] (n=ubuntu@host220-183-dynamic.53-79-r.retail.telecomitalia.it) |
| 23:42:16 | | Quit darkham (Read error: 131 (Connection reset by peer)) |
| 23:42:25 | gevaerts | Although it is usable |
| 23:42:27 | | Join darkham [0] (n=ubuntu@host220-183-dynamic.53-79-r.retail.telecomitalia.it) |
| 23:42:28 | Unhelpful | right, C dynamic arrays. that's definitely a way to do it. will an int[0] disappear completely? |
| 23:42:28 | | Quit darkham (Read error: 104 (Connection reset by peer)) |
| 23:42:42 | | Join darkham [0] (n=ubuntu@host220-183-dynamic.53-79-r.retail.telecomitalia.it) |
| 23:42:43 | | Quit darkham (Read error: 104 (Connection reset by peer)) |
| 23:42:50 | gevaerts | Maybe it won't, but who cares about a few bytes on the stack? |
| 23:43:05 | bluebrother | gevaerts: the stack cares? ;-) |
| 23:43:15 | * | funman hands iso C99 to Unhelpful |
| 23:44:29 | gevaerts | bluebrother: has it told you? |
| 23:44:56 | bluebrother | hmm. I should ask ... |
| 23:45:19 | Unhelpful | how is that handled, though? i assume the stack pointer just gets moved? |
| 23:45:31 | gevaerts | I guess so |
| 23:47:01 | *** | Saving seen data "./dancer.seen" |
| 23:48:09 | | Part captainkewl |
| 23:48:34 | Nico_P | at the risk of seeming stupid, I'd like to know what you mean by "dynamic array" in C... |
| 23:49:09 | gevaerts | Nico_P: int size=whatever, char array[size]; |
| 23:49:15 | Unhelpful | Nico_P: current C specs permit run-time sizing of a declared array |
| 23:49:37 | gevaerts | Actually, does gcc 3.4 allow that already? |
| 23:50:02 | Nico_P | ah right. I was thinking of some sort of resizing |
| 23:50:16 | Nico_P | how recent is that spec? |
| 23:50:36 | Unhelpful | according to funman, iso C99, it would seem |
| 23:51:05 | * | Nico_P is too young to have known anything else than C99 |
| 23:52:40 | funman | i didn't mean it was not present in previous standards, it's just the newest one i know about :) |
| 23:53:37 | Unhelpful | funman: it's not in C89, apparently, as it's stated to be offered as a non-standard extension to C89 in gcc. |
| 23:53:43 | Unhelpful | http://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Variable-Length.html#Variable-Length |
| 23:53:55 | Nico_P | http://en.wikipedia.org/wiki/C99 |
| 23:54:19 | gevaerts | It works in gcc 2.95, so we're safe anyway |
| 23:54:23 | | Quit tyfoo (Connection reset by peer) |
| 23:54:42 | Unhelpful | ah, alloca is what i want, if i just want to extend my stack frame by N and get a void* to the beginning of that chunk. |
| 23:55:01 | Unhelpful | but arr[i] is definitely prettier... |
| 23:55:28 | Nico_P | does rockbox have alloca? |
| 23:55:32 | gevaerts | I don't think rockbox has alloca() though |
| 23:56:08 | gevaerts | hm, yes it does |
| 23:56:37 | funman | according to the manpage, i thought it was provided by the compiler (or the libgcc?) |
| 23:57:06 | gevaerts | You need #define alloca __builtin_alloca though |
| 23:58:04 | denes_ | gevaerts: hi! |
| 23:58:08 | gevaerts | I think alloca() is nicer in this particular case, as it would just be if(is_small) buffer=alloca(size) else buffer=audiobuffer_steal(size) |
| 23:58:38 | gevaerts | Hi denes_! |
icon identifies that the person is a core developer (has commit access).