00:02:09 | *** | Saving seen data "./dancer.seen" |
00:04:16 | Wett | I see lines like CONFIG_HWCODEC == MASNONE, which HWCODEC corresponds to the iriver ? |
00:05:23 | linuxstb | Update to the latest CVS. It was changed recently. Or search for "pcm_" |
00:06:54 | Wett | yeah, have some pcm_play_data (my package is just a few days old) |
00:07:38 | Wett | but pcm is uncompressed data, I guess i'll have to use a codec, right ? |
00:17:25 | | Join [IDC]Dragon [0] (n=idc-drag@p548381CF.dip0.t-ipconnect.de) |
00:18:28 | linuxstb | Wett: Yes. You can either attempt to modify Rockbox to give plugins access to the codec API, or just link your plugin against one of the codec libraries (e.g. libmad), and do your own decoding "internally". |
00:19:54 | Wett | ok... i don't know at all how i'll be able to do that but... Oo I guess i may understand better if I look at some .h files |
00:20:06 | linuxstb | In the short term, it's going to be easier to just link against libmad and copy code from mpa.c to do the decoding. |
00:20:30 | Wett | what is mpa.c ? |
00:20:37 | linuxstb | apps/codecs/mpa.c |
00:21:09 | linuxstb | It's the MPEG codec - i.e. the code that sits between libmad and Rockbox. |
00:21:43 | Wett | (and I guess libmad is the for mp3 :) |
00:21:47 | linuxstb | You basically just need to find out how to use libmad - you feed it compressed MPEG frames, and it gives you back PCM data. |
00:21:59 | linuxstb | Yes - and MP1/2 |
00:22:10 | Wett | ok, should be not as hard as I thought |
00:22:41 | linuxstb | The .c files in apps/codecs are relatively small, and should be relatively easy to read. |
00:23:08 | Wett | okayy, thanks a lot ! i'll see what I can do from now on :) |
00:23:48 | Moos | is it still for video plugin port for irivers? :) |
00:24:04 | linuxstb | You could also look at the old "mpa2wav.c" plugin - I wrote this before Rockbox could play audio on the iriver in order to test libmad. As the name suggests, it decodes an MPEG audio file (e.g. mp3) to WAV. |
00:24:05 | Wett | yep |
00:24:06 | Moos | video+sound? |
00:24:09 | Moos | ok |
00:24:09 | Wett | yep ! |
00:24:18 | linuxstb | It's in CVS, but I think it's been "removed". |
00:24:20 | Wett | already managed to play the video :) |
00:24:28 | Moos | congrates |
00:24:44 | linuxstb | Does your plugin play the video format used on the Archos? |
00:24:51 | Wett | yes |
00:24:57 | Wett | i just port it |
00:25:19 | Moos | Wett: your man is amiconn or IDC Dragon |
00:25:21 | Moos | :) |
00:25:41 | Wett | amiconn already helped me yesterday on iriver lcd ^^ |
00:25:47 | Moos | :D |
00:26:14 | Wett | linuxstb -> how can i find it if it's been removed ? |
00:26:17 | webguest63 | The feature-thaw is looking to be eventful |
00:26:37 | linuxstb | Wett: Check the "Attic" when browsing CVS: http://www.rockbox.org/viewcvs.cgi/apps/plugins/Attic/mpa2wav.c?view=markup |
00:26:45 | Moos | isn't you IDC Drangon, who ported this video things in archos? |
00:26:57 | Wett | ok |
00:27:39 | | Quit ashridah ("Leaving") |
00:28:08 | [IDC]Dragon | hi |
00:28:15 | [IDC]Dragon | not ported, but made |
00:28:23 | Moos | Hello hehe :) |
00:28:32 | Wett | hello ! |
00:29:50 | [IDC]Dragon | dos it play sound, too? |
00:29:54 | [IDC]Dragon | does |
00:30:01 | Wett | I'm working on it |
00:30:07 | [IDC]Dragon | nice |
00:30:26 | [IDC]Dragon | did you extend the size? |
00:30:43 | [IDC]Dragon | or playing backwards-compatible? |
00:30:44 | Wett | btw, i guess it's possible to modify tools in order to produces 160x128 video ? |
00:30:52 | [IDC]Dragon | sure |
00:31:04 | [IDC]Dragon | which are you using? |
00:31:05 | Wett | lol, it's compatible for now, i'm just playing little videos |
00:31:16 | Wett | for now, the easy way |
00:31:16 | | Quit LameD ("CGI:IRC (EOF)") |
00:31:35 | [IDC]Dragon | which is? |
00:31:39 | Wett | i took a little look at rvf_mux.c, it looked possible to change |
00:32:01 | linuxstb | Is it possible to transcode MPEG-2 to the Rockbox format (under Linux)? |
00:32:01 | Wett | using RockVideo.exe |
00:32:08 | [IDC]Dragon | the DirectShow one is nicer, but not open source |
00:32:17 | Wett | and a directshow plugin |
00:32:57 | Wett | hm, so i'll definetly have to modify rvf_mux |
00:33:17 | [IDC]Dragon | or I'll have to modify the DirectShow filter |
00:33:51 | Wett | I didn't find the source, and I'm not sure at all i'll be able to do that |
00:33:53 | | Join gromit` [0] (n=gromit`@ras75-5-82-234-244-69.fbx.proxad.net) |
00:34:18 | Wett | I'll begin with the other solution ^^ |
00:34:23 | [IDC]Dragon | I haven't disclosed the sources for that |
00:34:39 | [IDC]Dragon | too much overlap with my job |
00:35:14 | [IDC]Dragon | be prepared for huuuge video files then |
00:35:52 | Wett | hm... how can I find the source for the directshow filtrer then ? |
00:36:25 | [IDC]Dragon | you can't, I'm not releasing them |
00:36:47 | Wett | oh, okok I misread sorry |
00:37:02 | [IDC]Dragon | you probably won't be able to compile that anyway |
00:37:03 | linuxstb | Does anyone know if the "halftone" program work with the yuv4mpeg format used by mjpegtools? |
00:37:14 | Wett | yes, i guess Oo |
00:37:58 | [IDC]Dragon | (needs MSVC and the DirectX SDK) |
00:40:07 | Wett | (I have ! lol, it doesn't matter) |
00:40:36 | [IDC]Dragon | ah, ok |
00:41:25 | | Join TCK [0] (i=TCK@81-86-98-102.dsl.pipex.com) |
00:48:09 | Rick | iriver = gapless support? (friend is asking) |
00:48:19 | Rick | I don't recall if it was ever implemented |
00:48:36 | | Quit ender` (Read error: 113 (No route to host)) |
00:48:44 | webguest63 | It is. There's a very very minor glitch |
00:49:57 | Rick | thanks |
00:50:09 | Rick | who're you anywawy? :) |
00:51:09 | webguest63 | just a user |
00:51:27 | webguest63 | hm, just checked.. couldn't here any transition at all |
00:51:28 | Rick | oh, ok :P |
00:51:59 | OnkelJonas | hey... do any of you have experience with "the godfather"? (tagging program) |
00:52:29 | | Quit paugh ("Leaving") |
00:55:22 | linuxstb | Rick: iriver is 100% gapless for everything apart from MP3s |
00:55:53 | linuxstb | For MP3s, I think that gapless is now working (using lame to encode the tracks), but there may be a few minor problems remaining. |
00:57:06 | webguest63 | This was from an mp3 I had split with a program that reportedly splits at frame-boundries |
00:58:27 | linuxstb | That should work fine then. It will be decoded as if it was a single long file. |
00:58:48 | linuxstb | The problem comes when tracks are encoded individually. |
01:00 |
01:03:15 | | Join Febs [0] (n=Febs@207-172-122-81.c3-0.rdl-ubr4.trpr-rdl.pa.cable.rcn.com) |
01:07:45 | | Quit Sucka ("a bird in the bush is worth two in your house") |
01:11:28 | Moos | good night @ all ! |
01:11:38 | | Quit Moos (" HydraIRC -> http://www.hydrairc.com <- Try something fresh") |
01:14:01 | | Quit bluebrother^ ("Leaving") |
01:15:19 | | Quit webguest63 ("CGI:IRC") |
01:19:55 | | Quit DangerousDan (Read error: 110 (Connection timed out)) |
01:26:52 | | Quit hicks ("Too lazy to change my quit message") |
01:31:00 | | Join solex_ [0] (n=jrschulz@c147121.adsl.hansenet.de) |
01:31:29 | Wett | [IDC]Dragon : Can I know how are stored audio blocks in the rvf format ? Are they composed of just one frame, or more like little mp3 files ? |
01:32:06 | [IDC]Dragon | they are whatever fits |
01:32:14 | [IDC]Dragon | not frame aligned |
01:32:34 | [IDC]Dragon | however, there is a tiny header in each block |
01:32:59 | [IDC]Dragon | telling you about frame starts |
01:33:25 | [IDC]Dragon | the mp3 data is bitswapped |
01:33:50 | Wett | and don't know what it means ^^ |
01:33:52 | [IDC]Dragon | but the file format is prepared for other audio formats |
01:34:27 | [IDC]Dragon | bitswapped like the voice files |
01:34:31 | Wett | i'm not very familiar with audio format anyway |
01:34:51 | [IDC]Dragon | no, this is a crappy Archos workaround |
01:35:10 | [IDC]Dragon | the serial shifts the bits out in wrong order |
01:35:32 | [IDC]Dragon | so we're better off if the data is already bitswapped |
01:35:52 | Wett | the only thing i understand here is : it's better so |
01:36:36 | | Quit matsl (Remote closed the connection) |
01:37:05 | Wett | if a read well, the codec decode frame per frame. How big a frame can be ? Is there only one frame in an audio block ? |
01:37:09 | [IDC]Dragon | this format is compensating a hardware shortcoming |
01:37:30 | Wett | ok |
01:37:32 | [IDC]Dragon | no, frames are unrelated to blocks |
01:38:35 | [IDC]Dragon | but for seek convenience, my audio header tells you if and where a frame starts within this block |
01:39:30 | Wett | oh ! so there's just a stream all along the file, wich I have to feed with blocks when i run out of data, right ? |
01:40:11 | [IDC]Dragon | minus the headers, yes |
01:40:48 | Wett | got it. thanks ! |
01:41:23 | [IDC]Dragon | and for the special case of Archos mp3 audio, you need to twist the bytes |
01:41:44 | [IDC]Dragon | like done in talk.c, too |
01:42:05 | [IDC]Dragon | which also deals with pre-bitswapped mp3 data |
01:42:18 | Wett | but, will I have to kinda twist them back ? |
01:42:30 | Wett | if the mp3 is already bitswapped |
01:42:56 | [IDC]Dragon | yes, this is what I'm trying to say |
01:43:25 | Wett | arg sorry i'm a little slow :p |
01:44:35 | [IDC]Dragon | np |
01:45:30 | Wett | so, what does it concretely say ? that bits are reversed ? |
01:45:48 | [IDC]Dragon | yes, MSB becomes LSB |
01:45:59 | Wett | xD google is my friend |
01:46:30 | [IDC]Dragon | talk.c is your better friend |
01:46:35 | | Quit solex (Connection timed out) |
01:46:55 | [IDC]Dragon | such is done there, already |
01:47:32 | Wett | yes ! I'll just have to steal some code, exactly what I do from the beginning |
01:48:18 | | Join Mxm`Pas`Bien [0] (n=flemmard@fbx.flemmard.net) |
01:48:24 | [IDC]Dragon | such a thief! |
01:49:14 | Wett | lol kinda :D |
02:00 |
02:02:12 | *** | Saving seen data "./dancer.seen" |
02:05:54 | | Quit Maxime (Read error: 110 (Connection timed out)) |
02:13:44 | | Quit preglow ("leaving") |
02:17:42 | [IDC]Dragon | goodnight! |
02:18:04 | Wett | goodnight, I'm going to sleep in a while, too |
02:18:08 | [IDC]Dragon | and happy ROMBoxing |
02:18:24 | [IDC]Dragon | to any Archos users out there |
02:18:38 | | Quit [IDC]Dragon () |
02:23:17 | Wett | gn all :) |
02:23:21 | | Quit Wett () |
02:28:54 | | Quit AdNauseam ("leaving") |
02:48:54 | | Quit linuxstb (Read error: 113 (No route to host)) |
04:00 |
04:02:13 | *** | Saving seen data "./dancer.seen" |
04:46:51 | pike | rockbox;iriver can you lock remote and mainunit independently yet ? |
05:00 |
05:24:59 | | Join yeft [0] (n=chatzill@pcp04990735pcs.benslm01.pa.comcast.net) |
05:25:35 | yeft | !seen midk |
05:25:47 | yeft | no .. no |
05:26:31 | | Quit yeft (Client Quit) |
06:00 |
06:02:15 | *** | Saving seen data "./dancer.seen" |
06:46:26 | | Join midk [0] (n=Zakk@c-24-16-191-240.hsd1.wa.comcast.net) |
06:47:20 | | Join LinusN [0] (n=linus@labb.contactor.se) |
06:48:59 | | Join webguest65 [0] (n=8ddfd339@labb.contactor.se) |
06:59:50 | | Quit webguest65 ("CGI:IRC (EOF)") |
07:00 |
07:08:32 | LinusN | bleh, the line-selector uproar is getting louder each day |
07:11:54 | | Join kurzhaarrocker [0] (n=none@dsl-084-061-011-125.arcor-ip.net) |
07:21:40 | kurzhaarrocker | In convbdf there's a variable which is declared in the middle of a function instead of the begin of the block. That causes problems with old compliers. Do we care about that? |
07:24:06 | kurzhaarrocker | That variable is int ofr = 0; |
07:24:08 | * | kurzhaarrocker must go |
07:24:21 | | Quit kurzhaarrocker () |
07:24:21 | midk | kurzy! :) |
07:24:23 | midk | :( |
07:27:10 | LinusN | he obviously didn't check the cvs log, i fixed that yesterday |
07:28:07 | | Join ender` [0] (i=ychat@tm.213.143.74.124.dc.telemach.net) |
07:34:26 | | Quit TCK (Read error: 104 (Connection reset by peer)) |
07:36:13 | | Join tvelocity [0] (n=tony@ipa203.4.tellas.gr) |
07:47:14 | CoCoLUS | the sony psp launched today all over europe... and i was thinking |
07:47:21 | CoCoLUS | it -would- be a viable plattform for rockbox :) |
07:47:27 | | Quit midk ("Leaving") |
07:48:56 | amiconn | morning |
07:51:36 | LinusN | morning |
07:53:38 | | Quit ender` (Read error: 110 (Connection timed out)) |
07:54:22 | tvelocity | morning |
07:54:31 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
08:00 |
08:02:17 | *** | Saving seen data "./dancer.seen" |
08:17:37 | | Join kurzhaarrocker [0] (n=Phil@p50908699.dip0.t-ipconnect.de) |
08:19:51 | | Quit solex_ ("leaving") |
08:25:53 | | Quit DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
08:28:45 | | Join solex [0] (n=jrschulz@c147121.adsl.hansenet.de) |
08:42:53 | | Nick Mxm`Pas`Bien is now known as Mxm`PasLa (n=flemmard@fbx.flemmard.net) |
08:43:35 | kurzhaarrocker | In recording.c the variable path_buffer is defined in line 247 and in line 307. I am convinced that the definition in 307 can be omitted as both variables are merely used as parameters and not for storage. |
08:44:30 | kurzhaarrocker | hm. Or we could move the global definition in 247 to a local variable of trigger_listener. |
08:46:26 | kurzhaarrocker | (which might save MAX_PATH Bytes) |
08:47:18 | LinusN | ok |
08:49:39 | kurzhaarrocker | Strange. It doesn't seem to affect the size of rockbox. Are static variables allocated on a heap? |
08:50:54 | LinusN | yes |
08:50:59 | kurzhaarrocker | ok |
08:51:14 | LinusN | in the .bss segment |
08:51:23 | LinusN | allocated at startup |
08:51:41 | LinusN | so it won't affect the size of the rockbox image |
08:51:47 | LinusN | unless it's initialized |
08:52:00 | LinusN | then the init values have to be stored in the image |
08:52:12 | kurzhaarrocker | no it isn'n initialized |
08:53:04 | amiconn | LinusN: I found another strong argument for the line-selector pointer removal: The arrow didn't scale so it worked very poor with larger fonts. The inverse bar doesn't have that problem |
08:53:40 | LinusN | yeah, but that would have been easy to fix |
08:53:50 | LinusN | i'm having second thoughts |
08:54:41 | kurzhaarrocker | You don't want to put the arrow back, do you? |
08:55:51 | LinusN | personally, i don't care, more than i like the reduced code complexity because of the way it was imlemented |
08:56:32 | LinusN | we could make it a little simpler by centralizing the cursor display |
08:56:40 | LinusN | and reintroduce the arrow |
08:56:54 | | Join cheriff [0] (n=davidm@cheriff.ken.nicta.com.au) |
08:57:10 | LinusN | so maybe we should revert the change and rework the cursor code after the release |
08:57:42 | LinusN | the fm code is small enough to fit anyway |
08:58:17 | kurzhaarrocker | Btw: When you have "resume on startup" enabled "Show recording screen on startup" doesn't work. Bug or feature? |
08:58:34 | LinusN | hmmm |
08:58:38 | LinusN | i'd say bug |
08:58:45 | kurzhaarrocker | me too :) |
09:00 |
09:01:44 | kurzhaarrocker | Should I write a bug report or add that in wiki to ReleaseTodo? |
09:01:57 | amiconn | LinusN: I think it's about time to centralise the listbrowser code |
09:02:07 | LinusN | amiconn: absolutely |
09:02:31 | LinusN | the tree and playlist browsers would be a lot simpler |
09:02:37 | amiconn | A related thing is that we should have a request() in addition to our splash() |
09:02:41 | LinusN | and the lcd remote display would too |
09:02:47 | LinusN | amiconn: yeah |
09:02:49 | amiconn | Tree, playlist, menu |
09:04:36 | amiconn | I am thinking about real *quick* menus, but I'm undecided whether this would be a good idea |
09:04:56 | amiconn | This results from my double-click discussion with Jörg |
09:05:05 | | Join linuxstb [0] (i=dave@dsl-212-23-31-215.zen.co.uk) |
09:06:17 | amiconn | What about a menu that pops up with a short click of one button, then stays for a short time, allowing to select n different options with n buttons. If nothing is selected in say, one second, it would disappear again |
09:07:20 | kurzhaarrocker | Hard to tell without trying the feel - But I think I'd prefer the quick menues as they are now. |
09:08:49 | amiconn | Yes, but the current quick-menus have some problems |
09:08:55 | kurzhaarrocker | Or do you mean you still could use those quick menus as key combos and they would disappear immediately? |
09:09:05 | amiconn | (1) Only the recorders have 2 of them, and the iriver has one |
09:09:28 | kurzhaarrocker | (It's that key combo thing I'm after) |
09:09:34 | amiconn | (2) Due to the way they work, the quick-operation mode doesn't work for many buttons |
09:09:57 | amiconn | That's why they use only 3 (they could use 4), and even one of the 3 doesn't work when flipped |
09:12:38 | LinusN | how would this menu work, i mean how are the items selected? |
09:14:38 | amiconn | The items would be selected by a click of a button |
09:14:46 | LinusN | as today? |
09:15:10 | amiconn | It's basically an "extended double-click", the second click may be a different button than the first |
09:15:46 | LinusN | like the nokia phones? |
09:16:09 | amiconn | Hmm, I don't know the current nokia gui at all |
09:17:25 | LinusN | ok, so the only real difference would be that it disappears automatically? |
09:19:31 | amiconn | Differences against current quick-screens: They wouldn't operate as button combos, in order to block less buttons. They would allow more buttons within the menu because of that. They would disappear automatically |
09:22:23 | amiconn | They would disappear either if a button is selected or they timeout |
09:22:52 | kurzhaarrocker | apropos button combos: the recorder is off. I hold the f2 button and then switch it on with the on button. It turns on but doesn't boot. Is there a hidden feature or another bug? |
09:25:48 | LinusN | i wouldn't like them to disappear when a button is pressed, that would make it a pain to cycle the repeat mode setting |
09:26:02 | LinusN | kurzhaarrocker: a hidden feature |
09:27:57 | | Join B4gder [0] (n=daniel@static-213-115-255-230.sme.bredbandsbolaget.se) |
09:29:52 | LinusN | kurzhaarrocker: hmmm, f2 *should* boot normally, if i understand it correctly |
09:31:13 | kurzhaarrocker | er, sorry, I meant F3 |
09:32:29 | LinusN | f3 starts the MiniMon |
09:32:50 | LinusN | a way of restoring a corrupt flash via the serial port |
09:32:54 | kurzhaarrocker | ok |
09:37:39 | linuxstb | LinusN: Obviously I'm in favour of reversing the cursor patch. I'm also more than happy to work on cleaning that part of the code - unless others wish to do it. |
09:39:23 | | Join paugh [0] (n=pete@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
09:39:47 | LinusN | linuxstb: let me think about it |
09:40:10 | linuxstb | Thanks - I can't ask more than that. |
09:43:06 | kurzhaarrocker | Something else I failed to implement: In recording screen I'd like to make the on-button switch to wps and play the last recorded file immdiately. |
09:44:25 | LinusN | kurzhaarrocker: submit a patch |
09:44:37 | kurzhaarrocker | Unfortunately I failed |
09:44:53 | LinusN | kurzhaarrocker: :-) |
09:44:56 | kurzhaarrocker | after recording it switches back to the menu |
09:45:30 | kurzhaarrocker | That is quite generic code where I don't know how to hook in that it should return to wps instead. |
09:45:39 | | Quit linuxstb ("Leaving") |
09:46:33 | | Nick cheriff is now known as cheriff_AWAY (n=davidm@cheriff.ken.nicta.com.au) |
09:47:09 | kurzhaarrocker | I'm talking about main_menu.c , rec_menu. |
09:57:57 | LinusN | kurzhaarrocker: that isn't trivial, i know |
10:00 |
10:00:05 | | Quit webguest61 ("CGI:IRC (Ping timeout)") |
10:01:10 | kurzhaarrocker | I thought: maybe store a hint in some static variable in recording_menu, abuse SYS_USB_CONNECTED to quit the menu at all, and than check and process that static hint within the caller of main_menu. But that feels so ugly. |
10:02:21 | *** | Saving seen data "./dancer.seen" |
10:03:18 | * | B4gder buckles up |
10:03:26 | * | Rick steals B4gder's buckle. |
10:04:57 | LinusN | ok, now the arrow cursor is back |
10:09:40 | kurzhaarrocker | Decreasing CONFIG_BLOCK_VERSION is funny. |
10:10:02 | LinusN | :-) |
10:10:10 | LinusN | doesn't matter in this case |
10:12:38 | | Join [IDC]Dragon [0] (n=idc-drag@p548381CF.dip0.t-ipconnect.de) |
10:14:56 | LinusN | ok, finally we can have conditional images in the wps |
10:15:07 | | Join thomjoha [0] (n=thomjoha@hekta.edt.aft.hist.no) |
10:16:00 | | Nick thomjoha is now known as preglow (n=thomjoha@hekta.edt.aft.hist.no) |
10:16:06 | preglow | so, someone whined the cursor back? ;) |
10:16:42 | solex | LinusN: conditional images are cool. I didn't know they didn'twork unitl now, but I already thought about using them! :) |
10:16:58 | LinusN | preglow: yes :-) |
10:16:59 | [IDC]Dragon | what a pity, we're too weak to clean out the feature clutter... ;-) |
10:17:06 | LinusN | hehe |
10:17:39 | LinusN | what is rockbox, if not features? |
10:17:55 | preglow | LinusN: change the default to bar, then we can remove the cursor again in six months or so, heh |
10:18:03 | LinusN | hehe |
10:18:10 | [IDC]Dragon | I want the arrow on the right, and non-solid, can I have an extra option, please? |
10:18:29 | LinusN | submit a patch :-) |
10:19:49 | solex | is there a big performance/memory penalty associated with conditional images |
10:19:57 | solex | say, for play status? |
10:20:15 | * | solex thinks about implementing his own status bar |
10:20:15 | LinusN | no |
10:20:39 | solex | so all images are kept in memory all the time? |
10:22:11 | LinusN | yes |
10:34:30 | pike | rockbox;iriver can you lock remote and mainunit independently yet ? |
10:36:06 | LinusN | it doesn't work? |
10:36:30 | pike | reason I ask is, I feel myself unable to use the remote, when I take up the mainunit I have somehow managed to go into the settings menu |
10:36:43 | | Join darkskiez [0] (n=darkskie@194.247.78.146) |
10:36:55 | pike | if you say the 2 locks are independant, I'll do more testing |
10:37:26 | B4gder | we don't have remote support yet, afaicr |
10:37:34 | LinusN | the remote keys work |
10:37:39 | B4gder | they do? |
10:37:42 | B4gder | hehe |
10:37:43 | darkskiez | my iriver has died :( power light comes on when you plug it in to charge, but doesnt ever finish, and it doesnt power up. Anyone have any idea if its a common fault that might be repairable ? |
10:38:48 | LinusN | darkskiez: did you do anything to it? |
10:39:09 | LinusN | like connect it to a third-party charger? |
10:39:24 | darkskiez | i did yeh, it charged fine once on it though |
10:39:28 | darkskiez | and the spec matched |
10:40:04 | LinusN | and the polarity was ok too? |
10:40:30 | darkskiez | yup, it successfully charged it one night, polarity and voltage matched |
10:40:50 | LinusN | the symptoms show that it is killed beyond repair |
10:40:52 | darkskiez | went to turn it on a few days later, thought battery was flat, plugged it in to charge and it didnt stop |
10:41:24 | LinusN | you could try to replace the battery, but i doubt that it would help |
10:41:31 | amiconn | boooooooooo for the line selector reversal! :-(( |
10:41:32 | darkskiez | just as rockbox was maturing too :( |
10:42:15 | darkskiez | is the drive pinout the same as a laptop hdd ? |
10:42:20 | * | [IDC]Dragon joins the boooooooo |
10:42:23 | darkskiez | connector wise, if I want the data |
10:42:40 | LinusN | darkskiez: don't remember |
10:42:50 | pike | what does "Dir Buffer is Full" mean, I get that when I enter some of my folders |
10:43:23 | LinusN | pike: it means that the directory buffer is too small to hold all file/dir names |
10:43:31 | LinusN | how many files are there? |
10:43:55 | pike | would need to check |
10:44:04 | pike | currently trying locking |
10:44:24 | LinusN | pike: either organize your files better, or increase the buffer size |
10:44:49 | LinusN | general settings->system->limits |
10:44:51 | CoCoLUS | the latter one being the quicker solution |
10:48:58 | pike | 546 files |
10:49:40 | LinusN | the default buffer size is 400 files |
10:50:07 | pike | thx |
10:51:50 | | Join leftright [0] (n=d4406110@labb.contactor.se) |
10:52:26 | leftright | perhaps the default buffer should be increased for those that dont read manuals and phone support :) |
10:52:37 | pike | how does rockbox handle this: player is off, charger is connected. leave it during night, later you power it on while charger is still connected. now indicator shows that it's charging |
10:53:05 | preglow | hmm |
10:53:41 | B4gder | leftright: no |
10:53:45 | preglow | boost ratio isn't a very good performance indicator :) |
10:54:16 | LinusN | pike: rockbox doesn't yet detect that the battery isn't being charged, only that the charger is connected |
10:54:55 | leftright | hmm, why does the charge light extinguish after charging the batt ? |
10:55:04 | leftright | with charger still connected |
10:55:08 | pike | ah I see, so all the charge indicator shows, is that external power is used ? |
10:55:19 | pike | but it indicated charging !? :) |
10:55:26 | pike | green diode was off |
10:56:03 | [IDC]Dragon | hehe, Creative delivered ~4000 Zen player with a virus on the disk |
10:56:41 | LinusN | pike: rockbox doesn't yet detect that the battery isn't being charged |
10:57:32 | pike | 2x negative declaration, too confusing |
10:58:58 | LinusN | on the iriver, rockbox only detects that the charger is attached, it doesn't yet detect the battery full condition |
10:59:18 | darkskiez | pike: i think with the iriver is off and u charge it rockbox doesnt do anything. |
10:59:34 | leftright | for info, I have been playing mp3 files since the 27th (with 27th's build) and R-Box hasnt crashed once |
10:59:54 | LinusN | darkskiez: true |
11:00 |
11:03:42 | darkskiez | if I was buying a new mp3 player now my beautiful iriver has died, it it worth getting an H300 series ? |
11:04:27 | B4gder | what decides if it is "worth it" then? |
11:04:47 | B4gder | it is probable that Rockbox will run on it in a future |
11:05:22 | paugh | darkskiez, i've heard that iriver are pretty good ad fixing or replacing broken units regardless of the circumstances. maybe try sending it back? |
11:10:51 | pike | loaded with rockbox ? ;) |
11:11:19 | amiconn | LinusN: Now we're almost back to square one with the code size issue :( |
11:12:31 | [IDC]Dragon | how do I get gcc 3.3.6 ina convenient way? (cygwin complied) |
11:13:03 | [IDC]Dragon | is BC up to that? |
11:13:03 | | Quit leftright ("CGI:IRC (EOF)") |
11:13:27 | paugh | pike: "regardless of the circumstances" |
11:13:33 | paugh | ;) |
11:13:47 | amiconn | [IDC]Dragon: I've just built it myself. |
11:14:14 | amiconn | The good thing is that if you have an up-to-date cygwin installation, you don't need the newlib workaround any more |
11:14:33 | amiconn | That reduced gcc build time from >2 hours to ~30 minutes on my laptoü |
11:14:38 | amiconn | *laptop |
11:14:54 | [IDC]Dragon | läptöp |
11:15:26 | [IDC]Dragon | I don't know if my cygwin is up to date |
11:15:41 | [IDC]Dragon | do you mind sending me the binary? |
11:15:50 | amiconn | I am updating my cygwin installation more or less regularly |
11:16:07 | amiconn | The cygwin installer handles this very well |
11:16:24 | darkskiez | paugh: out of warranty :( |
11:16:30 | [IDC]Dragon | I'm a fan of "if it aint broken, don't fix it" |
11:17:14 | amiconn | [IDC]Dragon: My binaries are built to run from /opt/sh1. If you also want it that way, I could zip this folder. |
11:17:15 | [IDC]Dragon | after overcoming being an adolescent version junkie |
11:17:31 | * | [IDC]Dragon checks |
11:18:06 | amiconn | You would then have to include /opt/sh1/bin into your search path if it's not already there |
11:18:33 | amiconn | 82.4 MB uncompressed |
11:19:04 | amiconn | ...containing sh binutils 2.16, gcc 3.3.6 and gdb 6.1.1 |
11:19:06 | [IDC]Dragon | I'm different, have the compiler in /rockbox/bin |
11:19:19 | [IDC]Dragon | phew |
11:20:29 | darkskiez | d'ya reckon i can get a working mainboard from somewhere, like if someones dropped it an forked the hdd/screen |
11:20:34 | [IDC]Dragon | I thought I just need the 3 sh-elf-*.exe files |
11:20:36 | darkskiez | i have, i hope, i working hdd and screen |
11:20:42 | amiconn | I used to have /rockbox as well, but moved to using /opt for everything extra |
11:20:57 | amiconn | I have the m68k toolchain under /opt/m68k |
11:21:15 | amiconn | [IDC]Dragon: No, you'll need all the libraries etc as well |
11:21:19 | [IDC]Dragon | me too, I just found |
11:21:55 | amiconn | 54.9 MB uncompressed for m68k (binutils 2.16, gcc 3.4.4, no gdb) |
11:22:27 | [IDC]Dragon | my m68k dir has 28 MB |
11:23:38 | | Join Wett [0] (i=Wett@AMontpellier-251-1-34-153.w83-113.abo.wanadoo.fr) |
11:24:18 | amiconn | You probably have an older revision of gcc 3.4, and it was built to support mcf52xx only (old gcc build patch) |
11:24:28 | [IDC]Dragon | I was wrong, sh-elf stuff runs from /opt/sh1, too |
11:24:43 | amiconn | My version supports all m68k targets except 68040 (new gcc build patch) |
11:24:47 | [IDC]Dragon | which has 37 MB |
11:24:56 | amiconn | sh-elf-gcc -v ? |
11:25:12 | [IDC]Dragon | for me not needing it, I have more than enough ;-) |
11:25:28 | [IDC]Dragon | 3.3.5 |
11:26:07 | amiconn | sh-elf-as −−version ? |
11:26:29 | [IDC]Dragon | 2.15 |
11:26:56 | amiconn | old ;) |
11:27:35 | amiconn | My whole opt folder is 44.8 MB zipped |
11:27:39 | [IDC]Dragon | yes, I'd like to have the "official" compiler when releasing bootbox |
11:28:38 | | Join Aramil [0] (n=tony@ipa219.5.tellas.gr) |
11:28:43 | [IDC]Dragon | let's see what Eric has for us |
11:30:35 | [IDC]Dragon | 2.16 binutils, but stil gcc 3.3.5 |
11:31:12 | amiconn | I'm putting my opt folder zip onto my web server, see pm for link :) |
11:31:33 | [IDC]Dragon | please take out the 68k |
11:32:10 | * | [IDC]Dragon is updating cygwin now |
11:32:25 | [IDC]Dragon | so I'll be fine with binutils, too |
11:32:40 | * | kurzhaarrocker thinks it is incredible that compilers & co can be serveral dozen MB big |
11:34:17 | [IDC]Dragon | sh-elf-as −−version is 2.16 now |
11:36:59 | | Quit tvelocity (Connection timed out) |
11:46:43 | | Join webguest35 [0] (n=c3442cce@labb.contactor.se) |
11:47:21 | | Quit webguest35 (Client Quit) |
11:49:19 | | Join Zagor [0] (i=foobar@pdpc/supporter/sustaining/Zagor) |
11:51:25 | [IDC]Dragon | hi Zagor, long not "seen" |
11:52:01 | Zagor | yeah. life somehow seems to keep me busy... :-) |
11:52:07 | [IDC]Dragon | me too |
11:59:06 | preglow | i don't see why the emac needs to be initialised from within mpa.c |
11:59:21 | preglow | it should be initialised locally wherever it's needed |
12:00 |
12:02:24 | *** | Saving seen data "./dancer.seen" |
12:03:03 | | Part Aramil ("Leaving") |
12:04:37 | * | preglow summons Slasher |
12:06:35 | Slasher | preglow: Hmm, i am not sure but there will be a glitch after boot if the mac is not initialized |
12:06:50 | | Join Mark__ [0] (n=Mark@cpc1-bele3-3-1-cust167.belf.cable.ntl.com) |
12:06:51 | preglow | then i've screwed up some place |
12:07:01 | preglow | ahh |
12:07:04 | preglow | i know why, of course |
12:07:10 | preglow | i'll move it to libmad init code |
12:07:10 | Slasher | hmm :) |
12:07:11 | preglow | where it belongs |
12:07:24 | Slasher | good, it's definately a better place :) |
12:08:06 | preglow | hmm |
12:08:16 | preglow | we might need a swap-back routine for the codecs |
12:08:34 | preglow | for instance, if you play wavpack, and use mp3s for voice, the results might be rubbish |
12:09:18 | preglow | bad example, flac would be a better example |
12:09:38 | preglow | since sets the emac in integer mode |
12:09:52 | preglow | since flac sets, yes |
12:10:12 | Slasher | oh, that might be a problem |
12:10:14 | preglow | yes |
12:10:21 | preglow | problem is that mad_f_mul is used everywhere in libmad code |
12:10:26 | preglow | and it expects the emac to be set in frac mode |
12:10:38 | preglow | i can't set the emac to frac mode in every mad_f_mul, that would slow things down |
12:11:01 | Slasher | hmm.. maybe the codec swap routine should check the mac mode and reset it back what it was when switching the codec back |
12:11:07 | preglow | hmm |
12:11:09 | preglow | that's a good idea |
12:11:12 | preglow | very nice |
12:11:14 | Slasher | :) |
12:12:24 | preglow | doesn't need to check either, just saving it and reverting it would do nicely |
12:12:38 | preglow | afaik, at least |
12:14:54 | preglow | think i'll put the emac init in mad_frame_decode, that _should_ do the trick |
12:16:26 | preglow | and there's _got_ to be a more structured way of doing the codecs than a while (1) and gotos ;) |
12:16:31 | Slasher | yes, that should be enough because the codec swap can happen only during pcmbuf_insert -callback |
12:16:44 | Slasher | hehe :D |
12:17:02 | preglow | but anywho, i need to put up some furniture and go vote |
12:18:07 | preglow | all these practicalities are stealing my rockbox time :/ |
12:28:56 | | Join Moos [0] (i=DrMoos@m29.net81-66-158.noos.fr) |
12:29:14 | Moos | Good evening |
12:29:22 | | Join webguest33 [0] (n=3e06ae68@labb.contactor.se) |
12:29:53 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
12:30:03 | | Join webguest63 [0] (n=3e06ae68@labb.contactor.se) |
12:31:56 | | Quit webguest63 (Client Quit) |
12:33:20 | amiconn | preglow: Some time ago I experimented with the MAC for faster 64x64 bit multiplication. |
12:34:32 | amiconn | I remember some codecs had mac init problems, causing periodic bursts of static when mandelbrot.rock with the macified 64 bit multiplication was running while music was playing |
12:35:00 | amiconn | Iirc one of these was mpa.codec, and vorbis.codec didn't have that problem |
12:35:46 | amiconn | It's a non-issue now, because I scrapped the macified routine as using standard mulu.l and mulu.w was faster anyway |
12:36:13 | amiconn | (not due to the instructions being faster, but due to using less registers, hence less stack access) |
12:36:52 | | Nick Mark__ is now known as Mark__`afk (n=Mark@cpc1-bele3-3-1-cust167.belf.cable.ntl.com) |
12:44:29 | | Quit webguest33 ("CGI:IRC (Ping timeout)") |
12:44:51 | | Join hicks [0] (n=hicks@zeus.mups.co.uk) |
12:48:39 | | Quit DangerousDan (Read error: 104 (Connection reset by peer)) |
13:00 |
13:10:43 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
13:18:46 | | Quit Nibbler (Read error: 113 (No route to host)) |
13:19:27 | | Join Nibbler [0] (n=sven@port-212-202-77-14.dynamic.qsc.de) |
13:23:45 | | Join Sucka [0] (n=NNSCRIPT@host81-156-159-120.range81-156.btcentralplus.com) |
13:26:33 | | Quit paugh ("speaking of reboots..") |
13:42:32 | HCl | gee.. |
13:46:42 | pill | hi |
13:46:44 | HCl | hello |
13:47:22 | pill | would it be possible for rockbox to open .nfo files using terminal 9 font? |
13:50:20 | HCl | no idea |
13:50:21 | HCl | o.o |
13:52:26 | | Join edx__ [0] (n=A@p54A851CA.dip.t-dialin.net) |
14:00 |
14:02:26 | *** | Saving seen data "./dancer.seen" |
14:08:54 | | Quit edx (Read error: 110 (Connection timed out)) |
14:09:09 | | Nick edx__ is now known as edx (n=A@p54A851CA.dip.t-dialin.net) |
14:12:06 | | Quit Sucka ("a bird in the bush is worth two in your house") |
14:14:26 | | Nick Mark__`afk is now known as Mark__ (n=Mark@cpc1-bele3-3-1-cust167.belf.cable.ntl.com) |
14:14:55 | preglow | amiconn: you raise a good point |
14:15:22 | preglow | i'm starting to believe macsr should perhaps be saved in the thread context |
14:27:15 | amiconn | Hmm, we could consider macsr belonging to the volatile environment, as gcc doesn't save this in functions (because it doesn't know about it) |
14:27:50 | amiconn | However, not all threads use the mac, so the additional overhead might not be desirable |
14:38:24 | | Quit [IDC]Dragon (Read error: 110 (Connection timed out)) |
14:42:27 | | Quit kurzhaarrocker (Remote closed the connection) |
14:42:56 | | Join drfeelgood [0] (n=ndblew@pcp09539345pcs.arnysm01.nj.comcast.net) |
14:43:23 | drfeelgood | good morning! |
14:44:14 | drfeelgood | got a small problem w/ my H120 and Rockbox |
14:44:35 | LinusN | shoot |
14:44:43 | drfeelgood | I just upgraded to the 09/01 bleeding edge build as of 8am EST |
14:45:04 | drfeelgood | i also tried to upgrade to the latest bootloader |
14:45:20 | drfeelgood | i patched the firmware and all like it says on the site |
14:45:39 | drfeelgood | when i disconnected my H120, it recognized the new v. of rockbox and asked to reboot, which i did |
14:45:56 | drfeelgood | i then turned the player off and tried to reboot into the iRiver fw |
14:46:15 | drfeelgood | (this is before I could flash the latest patched firmware) |
14:46:28 | drfeelgood | Now, it hangs on the "read file System" display |
14:46:41 | LinusN | is the battery charged? |
14:46:45 | drfeelgood | yes |
14:46:53 | | Join muesli- [0] (i=muesli_t@hmln-d9b8e277.pool.mediaWays.net) |
14:47:04 | drfeelgood | my reading according to rockboot v4 loading screen is 4.01v |
14:47:16 | LinusN | ok, start the player with the usb cord inserted |
14:47:21 | muesli- | re |
14:47:25 | LinusN | it will enter usb mode |
14:47:32 | LinusN | then you should be able to perform a scandisk |
14:48:23 | LinusN | the iriver firmware has issues with the file system |
14:49:02 | amiconn | LinusN: What's your opinion about saving macsr in the thread context? |
14:49:22 | LinusN | amiconn: not sure |
14:49:44 | LinusN | but if it simplifies for the codecs, i'm all for it |
14:50:28 | drfeelgood | LinusN: do I want to have scandisk automatically fix errors or attempt recovery of bad sectors? |
14:50:40 | LinusN | not automatically |
14:50:57 | drfeelgood | so if i don't choose that, it'll prompt me at the end? |
14:51:01 | LinusN | yes |
14:51:06 | drfeelgood | ok |
14:51:30 | drfeelgood | ok, i just ran scandisk. |
14:51:47 | drfeelgood | It ran through and at the end popped up a box saying "disk scan complete" |
14:51:51 | drfeelgood | or something to that nature |
14:51:56 | LinusN | figures |
14:52:09 | LinusN | it found no faults, but still the iriver firmware hangs |
14:52:15 | LinusN | that sucks |
14:52:21 | drfeelgood | that was my theory |
14:52:52 | drfeelgood | what doubly sucks is that I rely on the iRiver fw for remote support still |
14:53:08 | | Join Sucka [0] (n=NNSCRIPT@host81-156-159-120.range81-156.btcentralplus.com) |
14:53:17 | drfeelgood | i wasn't thrilled with the patch for rockbox, so i'm just gonna wait it out until it's built in by you guys |
14:53:41 | LinusN | drfeelgood: there is a tool called "directory snoop" |
14:53:54 | | Join webguest78 [0] (n=3e4f4094@labb.contactor.se) |
14:54:08 | LinusN | that might give us some clue why this happens |
14:54:25 | drfeelgood | ok |
14:54:29 | drfeelgood | where do i get it? |
14:54:47 | webguest78 | Hey Linus (if you're here) could the songrating WPS tag work like the new playmode does? So I can put different text (or image!) depending on the rating? |
14:55:48 | LinusN | drfeelgood: http://www.briggsoft.com/dsnoop.htm |
14:56:14 | LinusN | webguest78: that could be arranged |
14:57:04 | webguest78 | Great! |
14:58:17 | webguest78 | maybe it should be a different tag, so people that want the old version don't have to do %?rr<0|1|2|3|4|5|6|7|8|9|10> |
14:59:40 | drfeelgood | alright linus, i got directory snoop - anything specific i need to do? |
14:59:42 | LinusN | it should work both ways |
15:00 |
15:00:02 | LinusN | drfeelgood: i haven't run directory snoop in years, so i don't really remember |
15:00:13 | | Join muesli__ [0] (i=muesli_t@hmln-d514762e.pool.mediaWays.net) |
15:00:14 | webguest78 | Ah, didn't know how it worked so I thought maybe it wouldnt work |
15:00:24 | amiconn | webguest78: Isn't the plain rating tag %rr ? |
15:00:40 | amiconn | So it would automatically be different from %?rr |
15:01:07 | LinusN | %rr will show the rating |
15:01:09 | webguest78 | Okay |
15:01:15 | Wett | Sorry to bother you, but i'd like to understand how works the codecs architecture... I read mpa.c but there a too much things I don't know : how is feed the input buffer, etc. |
15:01:22 | amiconn | In fact all conditional and multi-conditional tags could work that way. |
15:01:22 | LinusN | %?rr<|||||||> will work too |
15:01:27 | webguest78 | So it's only in the case of %?rr that it acts differently? |
15:02:02 | amiconn | Without ? they would return a number of 0..n (0..1 for booleans), and with ? they would use the <..|..|..> form |
15:02:17 | amiconn | That should allow for some nice code reuse... |
15:02:28 | LinusN | the volume would be a pain though :-) |
15:03:22 | amiconn | Well, you aren't forced to use the %?tag<..|..> form |
15:03:40 | LinusN | of course not |
15:07:02 | muesli__ | could we have a condition to use a pic for the codec? |
15:09:30 | webguest78 | if it works like amiconn suggests you could |
15:09:42 | | Quit OnkelJonas (Read error: 104 (Connection reset by peer)) |
15:09:59 | LinusN | it already works like that |
15:10:25 | LinusN | (internally) |
15:11:33 | webguest78 | so it could be made to work like that with not so much effort? |
15:11:38 | LinusN | soon done |
15:12:01 | webguest78 | cool |
15:14:33 | | Join Aison [0] (n=hans@zux166-181.adsl.green.ch) |
15:16:52 | drfeelgood | Linus, i know this sounds a little drastic, but if I backed up the entire drive and reformatted it, think that would alleviate the error? |
15:17:28 | LinusN | yes |
15:17:52 | LinusN | drfeelgood: http://www.rockbox.org/twiki/bin/view/Main/IriverFAQ#The_original_firmware_no_longer_ |
15:18:59 | drfeelgood | well, thanks for your help. |
15:19:22 | drfeelgood | just dragging and dropping all the files off my drive onto my C: drive is enough of a backup, right? |
15:19:45 | LinusN | yes |
15:20:08 | drfeelgood | well, i'll be off to reformat my drive. |
15:20:18 | drfeelgood | Thanks for the troubleshooting help! |
15:20:21 | LinusN | ok, %?rr<|||> and %?fc<||||> is now possible |
15:21:12 | webguest78 | talk about quick action to user-requests ^_^ |
15:21:26 | B4gder | let's hope we add new codec names to the end then ;-) |
15:21:26 | webguest78 | thanks! |
15:22:42 | Wett | Just in case of anyone didn't see my question a little above, i'd like but don't find the way to play sound in a plugin :) |
15:22:57 | | Quit muesli- (Read error: 110 (Connection timed out)) |
15:23:13 | Moos | Salut Wett :) |
15:23:27 | Moos | how are you with your video plugin? |
15:23:37 | Wett | same as yesterday :( |
15:23:45 | Moos | still playback problems? |
15:23:55 | * | B4gder doesn't know how to play sound in plugins |
15:23:55 | Wett | I'm not used with this buffered and stream stuff |
15:24:31 | Wett | I'd like to understand what mpa.c does exactly, reading the code is not enough... |
15:25:47 | LinusN | the plugin interface can only currently only play pcm audio on the iriver |
15:26:22 | Wett | yes, I know that, so I wanted to deal with any codec directly |
15:26:38 | Wett | to be exact, with libmad |
15:26:53 | LinusN | that is unfortunately not possible in a plugin |
15:26:55 | LinusN | yet |
15:27:30 | LinusN | why do we have AFMT_APE and AFMT_REAL? |
15:27:48 | LinusN | and AFMT_AAC? |
15:28:05 | B4gder | for codecs? |
15:28:14 | LinusN | seems silly to have defines for formats we don't support |
15:28:26 | B4gder | I thought APE was a tag format |
15:28:27 | Wett | oh, I see... So I can't do anything until this is upgraded... |
15:28:36 | LinusN | Wett: or make it happen |
15:29:04 | LinusN | i'll remove the unsupported formats |
15:29:35 | B4gder | LinusN: add a comment about adding new ones to the end of the list for WPS enum reasons |
15:29:35 | webguest78 | cool, my rating is now shown as roman numerals |
15:29:43 | LinusN | yup |
15:29:45 | webguest78 | (not exactly what I was aiming for, but for testing..) |
15:30:05 | | Nick Mark__ is now known as Mark__`afk (n=Mark@cpc1-bele3-3-1-cust167.belf.cable.ntl.com) |
15:30:41 | Wett | ok, so i'll have to do it myself. But the problem is the same than before : I don't understand everything in this codec arch. :D |
15:33:06 | | Join linuxstb [0] (n=d556da1b@labb.contactor.se) |
15:33:46 | linuxstb | Wett: I don't think you need to know about the codec architecture - your plugin won't use it. |
15:34:20 | linuxstb | You should look at mpa.c as an example of how to use libmad. |
15:34:39 | linuxstb | (unless Rockbox is changed to give plugins access to the codecs) |
15:35:20 | Wett | that's what I did, but there are a lot of things I don't get ! Don't know where are the buffers, how they are feeds, etc |
15:35:40 | linuxstb | Have you looked at the mpa2wav plugin? |
15:36:05 | linuxstb | That simply works by reading the whole MP3 file into a memory buffer, and then decoding it using libmad, and writing to a WAV file on disk. |
15:36:19 | Wett | yep :( This is the first time I get into audio stuff, seems it's may be a little too early |
15:36:41 | LinusN | linuxstb: that plugin is gone |
15:36:48 | linuxstb | I think mpa2wav is simpler than mpa.c - mpa.c has been developed quite a lot, and contains a lot of irrelevant code |
15:36:57 | linuxstb | LinusN: I know - but it's in CVS still (Attic) |
15:37:19 | Wett | yes, dragon gave me the link yesterday |
15:38:22 | Wett | Can I ask precise question about libmad functions here ? |
15:38:55 | linuxstb | I don't have much time, but shoot. |
15:40:57 | Wett | the main function seems to be mad_frame_decode() which take a frame and a stream struct. where is stored the input and output buffers ? |
15:42:06 | | Join ashridah [0] (i=ashridah@220-253-122-238.VIC.netspace.net.au) |
15:42:24 | LinusN | gotta go |
15:42:26 | | Part LinusN |
15:42:59 | Wett | can I just give the codec some frames, without any mp3 headers or others informations about frequency, etc. ? |
15:44:03 | linuxstb | The output data is stored in Frame, which is then converted into PCM samples by the mad_synth_frame function. This creates a Synth struct containing the actual PCM samples. |
15:44:15 | linuxstb | Frame also contains the samplerate etc of the decoded frame. |
15:45:09 | linuxstb | I'm not sure I can remember how the input buffer works (I'm looking at the source now), but yes, I think you just pass the data blindly and don't have to worry about initialising anything. |
15:45:55 | linuxstb | You seem to use the mad_stream_buffer function to give libmad data. You call this before you call mad_frame_decode. |
15:46:40 | linuxstb | So you start by calling mad_stream_init, mad_frame_init and mad_synth_init. |
15:46:48 | Wett | great ! Can I pass data not frame aligned ? |
15:47:09 | Wett | I mean, using mad_stream_buffer |
15:47:29 | linuxstb | You then call mad_stream_buffer to give some data, followed by mad_decode_frame and then mad_synth_frame |
15:47:57 | Wett | ok I see better what they're for |
15:51:20 | Wett | about input buffer filling, if I get stream.next_frame!=0, that means next time codec will need a new frame, right ? |
15:52:10 | Wett | well, you're busy I don't bother you anymore :) thanks a lot ! |
15:52:33 | B4gder | rockbox talk isn't bothering us |
15:52:40 | linuxstb | Sorry - I am busy. I'll try to come back tonight when I'm not supposed to be working at the same time :) |
15:52:59 | Wett | lol ok ^^ |
15:53:24 | linuxstb | I may be able to find a simple libmad example program that I based mpa.c on. I haven't used libmad for a few months, so I've forgotten the details. |
15:53:34 | linuxstb | bbl. |
15:53:37 | | Quit linuxstb ("CGI:IRC") |
15:53:58 | webguest78 | hm, why does the preload tag have coordinates? wouldn't it be more flexible to put the coordinates when you're displaying it? |
15:54:07 | webguest78 | the image preload tag, that is. |
15:54:19 | B4gder | just to make the conditional use of it easier |
15:54:42 | webguest78 | But what if you want to show the same image twice, in different places |
15:54:45 | B4gder | otherwise it would be a whole lot of nested | |
15:54:49 | webguest78 | true |
15:54:52 | B4gder | webguest78: then you preload both |
15:55:01 | webguest78 | I see |
15:55:22 | B4gder | a future fix will make sure that the second one isn't loaded but uses the first buffer again |
15:55:53 | | Quit muesli__ (Read error: 110 (Connection timed out)) |
15:59:42 | amiconn | B4gder: I think giving the coordinates within the display tag instead of the load tag is the better way |
16:00 |
16:00:29 | amiconn | It's simpler to reuse images in multiple positions, and it could even be extended to clip regions |
16:00:36 | | Quit drfeelgood () |
16:01:25 | amiconn | This way we wouldn't need multiple .bmp files for multiple wps graphics. All graphics belonging to one wps design could be part of one single .bmp |
16:02:27 | *** | Saving seen data "./dancer.seen" |
16:04:21 | amiconn | Linus' last change introduces a problem on archos... :( |
16:12:42 | webguest78 | is 2-bit greyscale planned for wps bitmaps? |
16:17:13 | webguest78 | Are comments in WPS only allowed at the top? |
16:19:33 | | Nick Aison is now known as NewOrleans (n=hans@zux166-181.adsl.green.ch) |
16:19:41 | | Quit NewOrleans ("has quit USA (Excess Flood)") |
16:21:25 | | Quit edx (Read error: 104 (Connection reset by peer)) |
16:21:41 | | Join Aison [0] (n=hans@zux166-181.adsl.green.ch) |
16:27:36 | | Join edx [0] (n=A@p54A851CA.dip.t-dialin.net) |
16:32:17 | | Quit webguest78 ("CGI:IRC (EOF)") |
16:45:58 | | Join drfeelgood [0] (n=ndblew@pcp09539345pcs.arnysm01.nj.comcast.net) |
16:47:05 | drfeelgood | hello everyone! question, what do I use to format the player if windows won't allow me to format the player? |
16:47:08 | | Join kurzhaarrocker [0] (n=Phil@p50908699.dip0.t-ipconnect.de) |
16:47:30 | kurzhaarrocker | grrrr. How am I supposed to update a patch when sourceforge doesn't work! |
16:47:30 | drfeelgood | i've tried using a program LinusN recommended, SwissKnife, but that hangs whenever i try to access the drive |
16:47:35 | ashridah | wihch playm odel? |
16:47:47 | ashridah | drfeelgood: which player are we talking about? |
16:48:01 | dwihno | drfeelgood: there is also some application demo from paragon software |
16:48:12 | drfeelgood | H120 |
16:48:27 | ashridah | drfeelgood: iriver's original firmware has a format feature built in |
16:48:41 | drfeelgood | sry, i can't access that |
16:48:41 | ashridah | just go to the general menu |
16:48:58 | drfeelgood | to make a long story short, i couldn't access the iriver fw |
16:48:59 | ashridah | sounds like the player's borked then to me |
16:49:05 | drfeelgood | so i was going to reformat |
16:49:13 | | Part kurzhaarrocker |
16:49:22 | drfeelgood | copied everything off, started a reformat, program hung part way through |
16:49:24 | ashridah | i'm not sure how formatting'd help tbh |
16:49:50 | ashridah | iriver's firmware tends to work to a point even if the hd's been trashed. |
16:49:51 | drfeelgood | linusN and i decided it was a file system problem, as per the Iriver FAQ for non-booting orig. fw |
16:50:35 | drfeelgood | thank god, i forgot about that |
16:50:39 | drfeelgood | let me try something |
16:50:42 | ashridah | interesting. as i say, most of the hd issues i've seen with iriver's firmware have still resulted in an iriver firmware that booted (but wigged out when trying to browse the tree) |
16:50:48 | drfeelgood | how long does the iRiver f/w take to reformat the drive |
16:51:05 | ashridah | drfeelgood: about 20-30 seconds |
16:51:13 | ashridah | it's not long, |
16:51:15 | drfeelgood | well, we'll see |
16:51:23 | ashridah | it repartitions too |
16:51:42 | drfeelgood | i just reformatted, forgot i could ignore rockbox, who wigged over my HD and boot into iRiver |
16:51:55 | * | ashridah nods |
16:52:08 | ashridah | that's what i meant. get into iriver's firmware, and use its built in format tool |
16:52:20 | drfeelgood | phew! |
16:52:26 | drfeelgood | windows sees the drive again |
16:52:27 | ashridah | heh |
16:52:50 | drfeelgood | now, when i was trying to copy all the files off BEFORE the reformat, one of my config files wouldn't copy |
16:53:06 | drfeelgood | it said "Can't read from source disk/file" or something along those lines |
16:53:17 | drfeelgood | might that have been messing up the iriver f/w? |
16:53:42 | drfeelgood | when windows wouldn't delete the file, i just went into dos and trashed it since it wasn't my primary cfg file |
16:53:50 | ashridah | hrm, as i say, i've found the iriver firmware to be reasonably robust |
16:54:05 | ashridah | i'd have been inclined to run chkdsk against the unit |
16:54:16 | drfeelgood | i ran windows built in scandisk |
16:54:25 | drfeelgood | when you open the drive properties under tools |
16:54:28 | drfeelgood | no problems |
16:54:35 | drfeelgood | none from norton's disk doctor either |
16:54:50 | drfeelgood | that's what made Linus and I decide on reformatting it |
16:55:02 | drfeelgood | well, i'm gonna copy my files back over |
16:55:07 | drfeelgood | thanks for the trauma support |
16:55:32 | drfeelgood | how stable is rockboot v5? |
16:57:08 | | Quit Febs (Read error: 110 (Connection timed out)) |
16:58:08 | | Quit drfeelgood () |
17:00 |
17:00:41 | preglow | amiconn: a simple 32 bit save extra per thread doesn't sound like any overhead worth mentioning to me |
17:01:14 | preglow | amiconn: the alternative is having a 'codec_restore' function that has to be called every time a codec needs to generate data |
17:01:50 | preglow | amiconn: plus, this isn't just a codec problem, it's a problem for ordinary plugins using emac as well, the only easy way to fix this is to ad macsr to the thread context, or require everyone to reinit the emac after every yield() |
17:01:58 | preglow | add |
17:03:29 | | Join Febs [0] (n=Febs@207-172-120-139.c3-0.rdl-ubr4.trpr-rdl.pa.cable.rcn.com) |
17:03:59 | preglow | hmm, there might be a problem with the dsp part of the thread clobbering macsr as well |
17:04:48 | amiconn | dsp runs in audio thread, while codecs run in codec thread, correct? |
17:05:13 | preglow | i have no idea whatsoever |
17:05:26 | preglow | if the only thing running in the codec thread is the actual codec, then the context save will do fine |
17:07:52 | amiconn | So there are 2 questions: (1) In which thread does the dsp code run (2) is saving MACSR enough? What about the accumulators and MASK |
17:07:54 | amiconn | ? |
17:08:37 | amiconn | Still, each part needs to init the emac at the start |
17:08:43 | preglow | we will never depend on mask the way we depend on macsr |
17:08:59 | preglow | and we've got a zero accumulator policy |
17:09:04 | preglow | you leave them at zero when you're done with them |
17:09:19 | preglow | i decided this because of the movclr instruction |
17:09:32 | | Quit ashridah ("sleep") |
17:09:59 | preglow | amiconn: at the start, yes, but i don't need to worry about macsr in every single mad_f_mul anymore |
17:10:00 | amiconn | On SH1, the multiplication accumulator (used for both normal multiply insn and mac) is declared scratch, so we can do this on coldfire as well |
17:10:28 | preglow | amiconn: i'd much rather like them to be required to be zero, then you don't need to clear them before you use them |
17:10:41 | preglow | amiconn: it's just a matter of always using movclr.l instead of move.l |
17:11:26 | amiconn | I think it doesn't matter |
17:11:51 | amiconn | Both methods have the same drawback that you can't rely on the accumulator content after yield() |
17:11:56 | preglow | well, it clearly does, my way saves code space and is slightlyfaster |
17:12:09 | amiconn | Maybe another thread changed it (to zero or whatever) |
17:12:19 | preglow | amiconn: for example, mad_f_mul can't be coded the way it is if i can't rely on the accumulators being zero |
17:12:41 | preglow | amiconn: i'll have to add a move.l #0, %acc0 to every single mad_f_mul in all of libmad |
17:12:57 | preglow | so it does matter |
17:13:12 | amiconn | I mean if we say accumulators are scratch, this policy can be added and wouldn't influence thread switching |
17:13:26 | amiconn | So be it the zero policy... |
17:13:31 | preglow | ahh, yes |
17:13:35 | preglow | but it already is that way ;) |
17:13:39 | amiconn | Yes |
17:13:51 | amiconn | I hope interrupt code will never use the emac... |
17:14:09 | preglow | can't see a reason for it to do so, still, it wont be a problem |
17:14:17 | amiconn | It would, for sure |
17:14:29 | preglow | why? it just has to save the entire emac state |
17:14:57 | amiconn | Hmm, but __attribute__((interrupt_handler)) |
17:15:11 | amiconn | doesn't do this, as gcc doesn't know about emac... |
17:15:29 | preglow | ahh, yes, i completely forgot it's in c |
17:15:29 | preglow | heh |
17:15:33 | preglow | brb, wash clothes |
17:15:53 | amiconn | gcc should really learn about emac... |
17:16:47 | preglow | oh, i agree |
17:16:52 | preglow | i tried looking at it to add it |
17:16:55 | preglow | but it's way over my head |
17:17:45 | amiconn | Neither do I have any idea about adding such things to gcc... |
17:18:05 | amiconn | I would like to add my ed 64bit multiplication... |
17:20:56 | | Join yngwi [0] (n=chatzill@chello080109107064.1.15.vie.surfer.at) |
17:21:30 | | Join TCK [0] (i=TCK@81-86-100-125.dsl.pipex.com) |
17:24:06 | preglow | i would like to add a complete intrinsics set |
17:24:14 | preglow | that schedules instructions optimally |
17:24:20 | preglow | should be a simple job for gcc, but i dont know how |
17:24:43 | preglow | not much to schedule, just stuff as many mac.l as possible in a row, and wait 2 cycles before you fetch after a mac |
17:24:53 | preglow | but brb, gotta wash kitchen |
17:28:23 | B4gder | wash kitten? ;-) |
17:28:47 | | Quit Febs (Read error: 110 (Connection timed out)) |
17:33:27 | | Join LinusN [0] (n=linus@labb.contactor.se) |
17:43:12 | amiconn | LinusN: Your latest change causes a problem on archos... |
17:44:06 | LinusN | how? |
17:44:22 | amiconn | The AFMT_* values no longer match the strings in id3.c on archos, because the string for mpeg layer 1 is #ifdef'ed, but you removed the #ifdefs for the AFMT_* values |
17:44:30 | LinusN | ah, yes |
17:45:52 | amiconn | The endmarker could also be removed, and the char * array shortened by one as a result |
17:47:32 | LinusN | fixed |
17:47:42 | | Quit DangerousDan (Read error: 104 (Connection reset by peer)) |
17:47:53 | LinusN | gotta go |
17:47:55 | | Part LinusN |
17:48:15 | amiconn | The endmarker is only used to determine the number of entries, and that can be done with sizeof(codec_labels)/sizeof(char*) |
17:55:38 | preglow | amiconn: but yeah, you agree adding macsr to the thread context would simplify things quite a bit? |
17:59:50 | | Join amiconn_ [0] (n=jens@p54BD5589.dip.t-dialin.net) |
18:00 |
18:02:30 | *** | Saving seen data "./dancer.seen" |
18:08:13 | | Quit Sucka ("a bird in the bush is worth two in your house") |
18:08:41 | | Join Sucka [0] (n=NNSCRIPT@host81-156-159-120.range81-156.btcentralplus.com) |
18:12:48 | | Quit yngwi ("Chatzilla 0.9.68a [Firefox 1.0.6/20050717]") |
18:17:37 | | Quit amiconn (Read error: 110 (Connection timed out)) |
18:17:37 | | Nick amiconn_ is now known as amiconn (n=jens@p54BD5589.dip.t-dialin.net) |
18:36:14 | | Join webguest66 [0] (n=8ddfd339@labb.contactor.se) |
18:36:44 | | Quit webguest66 (Client Quit) |
18:37:40 | | Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU) |
18:40:35 | * | amiconn is really disappointed about today's changes :( |
18:43:18 | pike | http://www.mareikegast.de/refugee-radio/index.html |
18:44:27 | preglow | what about them? |
18:44:27 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
18:50:00 | | Quit darkskiez () |
19:00 |
19:03:18 | | Nick Mark__`afk is now known as Mark__ (n=Mark@cpc1-bele3-3-1-cust167.belf.cable.ntl.com) |
19:03:18 | Mark__ | _( Y )_ |
19:03:18 | Mark__ | ()~*~() |
19:03:18 | Mark__ | (_)-(_) |
19:05:47 | preglow | yes, that's quite something you've got there |
19:29:29 | | Join _Wett [0] (i=Wett@AMontpellier-251-1-45-253.w81-251.abo.wanadoo.fr) |
19:29:36 | | Join bagawk [0] (i=1000@unaffiliated/bagawk) |
19:33:31 | | Nick Mark__ is now known as Mark__`afk (n=Mark@cpc1-bele3-3-1-cust167.belf.cable.ntl.com) |
19:37:03 | | Nick Mark__`afk is now known as Mark__ (n=Mark@cpc1-bele3-3-1-cust167.belf.cable.ntl.com) |
19:37:03 | Mark__ | _( Y )_ |
19:37:03 | Mark__ | ()~*~() |
19:37:03 | Mark__ | (_)-(_) |
19:37:43 | bagawk | Ok |
19:38:00 | preglow | anyone for banning people who use away nicks? |
19:38:16 | bagawk | B4gder, I assume you are 'bagder'? |
19:38:16 | Mark__ | :O |
19:38:37 | Mark__ | i really dont know why the bunny script keeps bleeding over to this channel |
19:38:45 | preglow | hahah |
19:38:46 | Mark__ | i'll /part for now to stop it |
19:38:48 | preglow | you _have_ a bunny script? :P |
19:38:53 | Mark__ | _ _ |
19:38:53 | Mark__ | ( \_/ ) |
19:38:53 | Mark__ | (=^_^=) |
19:38:53 | DBUG | Enqueued KICK Mark__ |
19:38:53 | Mark__ | (-)_(-) |
19:38:54 | Mark__ | yes! |
19:39:03 | | Quit Wett (Read error: 110 (Connection timed out)) |
19:39:07 | preglow | now, there's a sensible thing to have |
19:39:08 | bagawk | Not that is pointless... |
19:39:09 | Mark__ | its also a teddy and penguin script |
19:39:13 | Mark__ | (o_ |
19:39:13 | Mark__ | //\ |
19:39:13 | Mark__ | V_/_ |
19:39:20 | preglow | agreed, please stop spamming |
19:39:25 | Mark__ | ok |
19:39:35 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
19:39:35 | * | Mark__ slaps Mark__ around the head with box of matches. |
19:58:19 | pike | ho bagawk |
19:59:17 | bagawk | pike, Hello |
19:59:32 | pike | heh |
19:59:36 | bagawk | pike, I had no idea you were the same pike |
19:59:44 | | Join LinusN [0] (n=linus@labb.contactor.se) |
19:59:53 | pike | so many of us? |
20:00 |
20:01:00 | bagawk | Hey LinusN |
20:01:19 | bagawk | LinusN, I was thinking of adding a parts avail page to the wiki |
20:01:21 | | Join arkascha [0] (n=arkascha@xdsl-213-196-209-136.netcologne.de) |
20:01:39 | bagawk | LinusN, I have a number of parts around people could use (screens, buttons etc) |
20:01:56 | bagawk | LinusN, Is that okay by you? |
20:02:24 | LinusN | absolutely |
20:02:33 | LinusN | amiconn: u there? |
20:02:34 | *** | Saving seen data "./dancer.seen" |
20:02:52 | preglow | what kind of parts? |
20:03:51 | bagawk | preglow, archos parts |
20:04:37 | preglow | ahh |
20:05:10 | arkascha | got a clear newby question about a firmware build under GNU/linux. Firmware has only 8kb and produces a roro checksum error. Any easy hint? |
20:05:36 | preglow | ehh |
20:05:38 | preglow | so it should |
20:05:41 | preglow | target? |
20:05:45 | arkascha | sorry, iriver |
20:05:52 | preglow | gcc and ld version? |
20:06:05 | arkascha | gcc 3.4.4 and a moment... |
20:06:21 | arkascha | ld 2.15.94 |
20:07:46 | preglow | strange |
20:07:55 | preglow | no link errors? |
20:08:02 | arkascha | no error, no warning |
20:08:16 | arkascha | reproducable |
20:08:23 | | Quit dpassen1 () |
20:09:07 | preglow | what does 'file' say to rockbox.iriver? |
20:09:19 | preglow | forget it |
20:09:24 | preglow | it's raw, of course |
20:09:26 | arkascha | rockbox.iriver: data |
20:10:14 | arkascha | sorry for the newby stuff, just tried rockbox first time yesterday, it rocks ! thanx ! |
20:10:15 | LinusN | did you follow the instructions here: http://www.rockbox.org/twiki/bin/view/Main/DevelopmentGuide |
20:10:34 | arkascha | gotta check, a second |
20:10:57 | arkascha | yep, that's it |
20:11:07 | LinusN | especially rhis: http://www.rockbox.org/twiki/bin/view/Main/HowToCompile |
20:11:31 | preglow | you _could_ try upgrading to binutils 2.16 |
20:11:36 | arkascha | yep, read that one |
20:12:27 | LinusN | 8k... |
20:12:43 | arkascha | I installed binutils 2.16 especially for rockbox, since I usually have 2.15 |
20:13:06 | LinusN | m68k-elf-as −−version |
20:13:35 | | Nick Mark__ is now known as Mark__`afk (n=Mark@cpc1-bele3-3-1-cust167.belf.cable.ntl.com) |
20:13:35 | DBUG | Enqueued KICK Mark__`afk |
20:13:44 | arkascha | sorry, I am a newby, I did specify m68k as target |
20:13:53 | arkascha | , that what you mean |
20:14:09 | LinusN | no, type what i wrote |
20:14:35 | LinusN | btw, the target should be "m68k-elf" |
20:14:42 | arkascha | wait a second, even more beginner stuff: you don't say the rockbox.elf file is the right firmware? |
20:14:51 | LinusN | rockbox.iriver |
20:15:08 | arkascha | ok, thought so. I did specify m68k-elf as target sorry |
20:15:33 | LinusN | no errors whatsoever? |
20:15:56 | arkascha | bash: m68k-elf-as: command not found - of course |
20:16:00 | arkascha | no compile errors... |
20:16:05 | preglow | hmm? |
20:16:14 | LinusN | command not found? |
20:16:20 | LinusN | then it can't work |
20:16:20 | preglow | that's wrong |
20:16:26 | preglow | you should have the entire binutils toolchain |
20:16:32 | preglow | i wonder why the hell it built |
20:16:46 | arkascha | sorry LinuxN: GNU assembler 2.16 was the correct result |
20:16:58 | arkascha | This assembler was configured for a target of `m68k-elf' |
20:18:03 | LinusN | sounds correct |
20:18:35 | LinusN | and m68k-elf-gcc −−version? |
20:18:54 | arkascha | m68k-elf-gcc (GCC) 3.4.4 |
20:19:16 | LinusN | source from cvs? |
20:19:44 | arkascha | download from link latest version, not cvs checkout |
20:20:02 | | Nick Mark__`afk is now known as Mark__ (n=Mark@cpc1-bele3-3-1-cust167.belf.cable.ntl.com) |
20:20:02 | DBUG | Enqueued KICK Mark__ |
20:20:08 | LinusN | ok, so you have a rockbox-20050901/ directory? |
20:21:05 | arkascha | no, called rockbox-2.4, but I don't remember if I renamed it, gotta check that |
20:21:15 | LinusN | 2.4???? |
20:21:25 | LinusN | that won't work |
20:21:27 | arkascha | sorry, said I am a bloody beginner |
20:21:41 | LinusN | you must use a daily build |
20:22:03 | preglow | how'd you actually manage to compile 2.4 for m68k? |
20:22:13 | arkascha | configure / make ... .-) |
20:22:52 | preglow | yes, seems we solved it then, hehe |
20:23:06 | arkascha | I'll try the daily build and be back, *thanx* for the help ! |
20:23:52 | preglow | you should be fine with a daily |
20:24:03 | bagawk | LinusN, I added a parts page, but it does not show up as a link on the main wiki page? |
20:24:20 | LinusN | bagawk: should it? |
20:24:31 | bagawk | LinusN, See yes |
20:24:37 | bagawk | LinusN, Look at the main wiki page |
20:25:02 | LinusN | they don't end up there automatically, you know |
20:25:08 | bagawk | LinusN, |
20:25:13 | bagawk | Yes |
20:25:17 | LinusN | and please rename it to a proper WikiWord |
20:25:30 | bagawk | LinusN, ahh yes |
20:25:58 | LinusN | SpareParts maybe? |
20:26:08 | amiconn | LinusN: Now I am here |
20:26:18 | LinusN | amiconn: dosappointed? |
20:26:32 | preglow | msdosappointed |
20:27:30 | amiconn | LinusN: Yes |
20:27:51 | amiconn | One reason already killed by me |
20:27:59 | | Join Lear [0] (n=chatzill@h179n2c1o285.bredband.skanova.com) |
20:28:20 | LinusN | the codec type? |
20:29:32 | preglow | something tells me the code size is another thing |
20:29:46 | | Quit cYmen ("wusch") |
20:30:38 | LinusN | yes of course |
20:30:42 | amiconn | Yes. |
20:30:51 | LinusN | fortunately, the builds are still green |
20:31:08 | preglow | so we've gotten to a point where we really can't add anything to the archos builds without doing massive size opts first? |
20:31:12 | amiconn | The reintroduction of the line selection pointer eats more than 1KB |
20:31:22 | LinusN | yup |
20:31:23 | amiconn | ..for no reason, imho |
20:31:33 | LinusN | in your humble opinion, yes |
20:31:35 | preglow | i dont think your reason was the reason for it being reintroduced, heh |
20:31:36 | amiconn | There are some optimisation possibilities |
20:32:27 | amiconn | I hope to be able to get some in before the release |
20:32:54 | LinusN | time to read a fairy tale to my son |
20:33:03 | LinusN | cu later |
20:33:05 | amiconn | One of them will hopefully fix the long line problem in the quickscreens |
20:33:10 | LinusN | amiconn: nice |
20:33:12 | | Part LinusN |
20:34:35 | | Nick _Wett is now known as Wett (i=Wett@AMontpellier-251-1-45-253.w81-251.abo.wanadoo.fr) |
20:38:14 | amiconn | preglow: Regarding binary size: Now we have ~550 *bytes* to play with on the fmrecorder (worst-case target) |
20:38:32 | preglow | well, it was bound to happen sooner or later |
20:39:18 | amiconn | Yes, but it can be made happen far later with some clever optimisation |
20:39:31 | preglow | yes, but it will happen |
20:39:34 | preglow | and i wonder how we'll deal with that |
20:39:41 | amiconn | The reintroduction of the pointer arrow was a plain rollback of not-very-clever code |
20:40:00 | preglow | yes |
20:40:31 | amiconn | We will need quite some extra space if we want to use the pcm codec |
20:40:41 | amiconn | I do want that! |
20:41:17 | preglow | yes, of course |
20:41:21 | preglow | it's a major feature |
20:41:25 | preglow | how much are we talking? |
20:46:12 | amiconn | The codec itself is ~3K words == 12 KByte |
20:47:01 | amiconn | It can be compressed to ~7.5 KByte as the MAS only uses 20 bit words, at the cost of some extra code |
20:47:31 | amiconn | Of course some extra code is needed for downloading the codec to the MAS, set it up etc. |
20:47:56 | amiconn | The playback engine must also be extended to handle MPEG <-> PCM switching |
20:49:14 | amiconn | ...and the recording engine needs the same extension |
20:50:17 | preglow | still |
20:50:31 | preglow | time to get optimising then ;) |
20:52:01 | amiconn | I agree with several others that the playback engines should be unified |
20:52:35 | amiconn | ...but for this, the swcodec playback engine first has to get more stable, and some major annoyances must be solved |
20:53:17 | amiconn | The good thing if we do this is that we could handle codecs on archos in a similar way as on iriver |
20:55:14 | amiconn | This would save quite some space, no inclusion of the pcm codec in the core... |
20:56:02 | preglow | but mpeg.c will need quite a rewrite for this |
20:56:05 | | Nick Mark__ is now known as Mark__`afk (n=Mark@cpc1-bele3-3-1-cust167.belf.cable.ntl.com) |
20:56:05 | DBUG | Enqueued KICK Mark__`afk |
20:57:15 | amiconn | The goal is to remove mpeg.c, imho |
20:57:56 | amiconn | Some hw access functions will probably stay in the firmware layer, the rest should be application layer as on iriver |
20:58:05 | amiconn | i.e. using playback.c |
20:58:50 | preglow | yep |
20:59:05 | preglow | well, what are the major annoyances with the playback engine? |
20:59:57 | amiconn | The biggest one is the removal of nonexistent files from the playlist |
21:00 |
21:00:13 | amiconn | It should silently skip them and leave the playlist alone |
21:00:24 | amiconn | mpeg.c does this |
21:00:33 | preglow | well |
21:00:52 | preglow | that should be a quick fix? if i don't remember incorrectly, it was only recently added |
21:01:02 | preglow | and i agree that is the way it should be handled |
21:01:18 | amiconn | It was added because the code didn't handle missing files well |
21:01:37 | amiconn | ..so another way of handling these must be introduced |
21:02:55 | amiconn | The archos playback code uses a "skip index" in its internal tracklist that indicates how many steps in the playlist to go forward in order to get from the current track to the next one |
21:03:14 | amiconn | This index is usually 1, unless files are missing |
21:03:23 | Slasher | amiconn: that will be fixed after the feature freeze |
21:03:27 | Slasher | (the playlist thing) |
21:04:03 | Slasher | i don't want to introduce the skip index to playback.c, it's ugly solution.. |
21:04:46 | amiconn | Why do you think it's ugly? |
21:04:59 | Slasher | there is many ways you could do it wrong |
21:05:08 | Slasher | in fact it would be quite hard to get it working right |
21:06:13 | Slasher | i think a better way would be that playlist engine can mark the incorrect entries temporarily and skip them on playlist_peek |
21:06:52 | amiconn | It is working quite well on archos. We used to have quite some strange problems with nonexistent files before it was introduced |
21:11:19 | preglow | and btw |
21:11:33 | preglow | how is it possible that a simple selectable cursor uses 1kb of code? |
21:11:58 | amiconn | Did you have a look at the implementation? |
21:12:14 | amiconn | It's a fact that it increases binary size by >1KB |
21:15:38 | amiconn | Same is true for iriver btw, only that it's almost neglectible there |
21:16:02 | amiconn | There is no such hard limit on iriver as is on archos |
21:18:19 | amiconn | The thing is that the archos firmware is designed to load update firmwares from disk. The first method for loading rockbox was therefore relatively simple - it is built in a way that the archos firmware in the rom loads it as such an update firmware |
21:19:07 | amiconn | There is a hard limit in this process - archos rom won't load a firmware >200 KB |
21:19:38 | | Join webguest61 [0] (n=d5ee4441@labb.contactor.se) |
21:19:43 | amiconn | However, due to the mentioned design, not all archoses are flashable, as they don't need to be. |
21:21:28 | amiconn | Archos saved some pennies by not using 39VF020 flash roms in all units. Some have 37VF020 s which aren't in-circuit flashable. |
21:22:06 | amiconn | That means we can't get around the 200KB limit by flashing as that wouldn't work for all units |
21:22:53 | amiconn | All of the above isn't true for the Ondios, but that doesn't help us here. The worst cases are fmrecorder and recorderv2 regarding code size |
21:23:28 | | Quit bagawk ("Leaving") |
21:24:22 | webguest61 | Hi; a quick question as I'm a li'll bit confused: will it be possible to play some videos on iRiver iHP 1**? |
21:25:23 | | Nick Mark__`afk is now known as Mark__ (n=Mark@cpc1-bele3-3-1-cust167.belf.cable.ntl.com) |
21:25:23 | DBUG | Enqueued KICK Mark__ |
21:30:51 | preglow | yes, know about the limit |
21:31:06 | preglow | perhaps |
21:31:09 | preglow | webguest61: might be |
21:31:22 | preglow | webguest61: just need someone to come and implement it |
21:31:53 | | Join ender` [0] (n=ender@tm.213.143.74.124.dc.telemach.net) |
21:32:15 | webguest61 | preglow: I see; good to know it can be done :) |
21:32:21 | preglow | 'course it can be done |
21:32:35 | preglow | all depends on the video format you're speaking of, of course |
21:33:07 | preglow | problem with h1x0 is that it hasn't got a display with a lot of colours |
21:33:12 | preglow | so we need to do some grayscale magic |
21:33:18 | preglow | which also takes some cpu |
21:33:23 | preglow | amiconn: you got any numbers on that, btw? |
21:33:30 | amiconn | preglow: Do you think it would be good to add macsr to the context and change the iram distribution now? |
21:33:33 | webguest61 | yeah, I was just thinking of any, even basic formats |
21:33:44 | amiconn | Then you could do some codec magic if you want... |
21:33:49 | | Join TCK- [0] (i=TCK@85-210-11-133.dsl.pipex.com) |
21:33:54 | preglow | amiconn: well, of course i do, the macsr is almost a bugfix, and iram, well, i can work on codecs then :) |
21:34:14 | amiconn | I'll see what I can do ;) |
21:34:17 | preglow | great |
21:34:47 | amiconn | webguest61: I'm almost sure the .rvf format as used on the archos will work on H1x0 as well one day |
21:34:51 | preglow | i'm not quite confident enough in myself to go around chaning the linker files to do it myself yet |
21:34:55 | preglow | changing |
21:36:11 | preglow | hmm, btw, can i assume that only one instance of a codec will be used at a time? |
21:36:19 | preglow | so i can make libflac data static, for instance |
21:36:21 | preglow | it mallocs a lot |
21:36:57 | preglow | codec swapping wont be touched, since it actually loads two instances of the actual plugin unless i've been mistaken |
21:37:05 | amiconn | I think you can assume that, as for the second instance used in talk.c the whole codec gets swapped |
21:37:12 | preglow | yes, indeed |
21:37:28 | preglow | i can't think why we'd need two actual data structure based instances |
21:37:39 | preglow | i actually already assume this in wavpack and a52 |
21:38:09 | preglow | if i can toss the mallocs out the window, i'm quite confident i can get flac up to snuff |
21:38:36 | preglow | and that without actually touching too much code, something that would have a real impact on whats left of my sanity |
21:41:29 | amiconn | I should really look into asm optimising memcpy() ... sigh... |
21:41:43 | preglow | that would certainly be good |
21:42:02 | amiconn | I think this will help a number of codecs to gain some speed |
21:42:11 | preglow | oh yes, and very probably the voice ui as well |
21:42:27 | amiconn | Perhaps I should switch to memmove() before doing the asm |
21:42:34 | amiconn | I want to do that anyway |
21:44:07 | | Join Bazz [0] (n=nick@fw.cerisent.com) |
21:45:08 | Bazz | i'm trying to build the rockbox simulator for iriver h120, configure goes fine, but when i make i get: <stdin>:1:11: config.h: No such file or directory, and then failuers in uibasic.c |
21:45:10 | Bazz | any ideas |
21:45:20 | preglow | amiconn: whatever floats your boat, would be great anyway |
21:50:03 | | Quit TCK (Read error: 110 (Connection timed out)) |
21:55:59 | | Nick Mark__ is now known as Mark__`afk (n=Mark@cpc1-bele3-3-1-cust167.belf.cable.ntl.com) |
21:55:59 | DBUG | Enqueued KICK Mark__`afk |
21:59:32 | | Join Inverno [0] (n=desgaste@85.138.23.156) |
22:00 |
22:00:07 | Inverno | hey any devs here? |
22:00:09 | | Quit arkascha (Read error: 110 (Connection timed out)) |
22:00:11 | amiconn | preglow: MACSR now part of thread context, about to commit... |
22:00:55 | Inverno | i tried a build last night and rockbox seemed to be using the hardrive much more and literally eating chunks of battery life out of my iriver h-140 |
22:02:20 | preglow | amiconn: excellent |
22:02:33 | preglow | Inverno: when? |
22:02:37 | *** | Saving seen data "./dancer.seen" |
22:02:42 | | Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
22:02:43 | preglow | Inverno: when browsing? playing? |
22:03:04 | amiconn | The good thing is that it only adds one instruction and one longword access to each of context store and context load |
22:03:13 | Inverno | Im not very sure now but it seemed like all the time |
22:03:16 | Slasher | amiconn: Hmm, you changed that codec index to start from 0.. there was a reason why it started from 1, i hope that doesn't break the playback code. But i might investigate tomorrow, now sleep -> |
22:03:25 | Inverno | wait ill fire it up |
22:03:41 | amiconn | Slasher: What might fail? |
22:03:57 | Slasher | i am not sure, but now i really need to go. cu tomorrow |
22:03:58 | amiconn | Only the code for unknown codec is zero now |
22:05:34 | Inverno | doesn't seem to be acting up now but it was when I was editing a playlist |
22:05:43 | Inverno | with playback at the same time |
22:06:27 | Inverno | it whent from two third full to half battery in some 20 minutes ;| (low volume using headsets and mp3/ogg playback no flacs) |
22:06:54 | amiconn | preglow: Context change committed :) |
22:07:53 | Lear | Hm.. Normal playback seems fine (very quick look on a fresh build). |
22:08:30 | Lear | But I made a full rebuild, still no cursor option... Odd... |
22:09:35 | amiconn | Haha, funny effect: |
22:09:58 | amiconn | I am playing some flacs for a test, have voice menu enabled, and entered the menu and left it again |
22:10:21 | Lear | Looks like linus forgot to roll back settings_menu.c... :) |
22:10:32 | amiconn | Several seconds later it said "general settings" (in german), with some further seconds spacing... |
22:11:04 | preglow | haha |
22:11:12 | preglow | well, flac doesn't leave much time to libmad |
22:11:16 | preglow | cpu time, that is |
22:13:13 | amiconn | Yes, especially with flacs encoded with -8 |
22:13:28 | preglow | oh well |
22:13:35 | preglow | i _should_ be able to work wonders for flac |
22:13:37 | preglow | we'll see |
22:13:51 | amiconn | I'm just fiddling with the linker scripts.... |
22:14:21 | Lear | better than wavpack even? |
22:14:41 | preglow | Lear: no, not really |
22:14:45 | preglow | but who knows |
22:15:33 | Lear | just wondering, since that uses ~45% boost, iirc... |
22:15:48 | preglow | wavpack? |
22:15:53 | preglow | i've got files that doesn't boost at all |
22:16:28 | Lear | I haven't tried much, granted, just a track or two... |
22:16:50 | amiconn | Maybe it's a matter of lossless vs. lossy mode |
22:17:04 | amiconn | I've encoded a whole album for testing as lossless |
22:17:09 | amiconn | Doesn't boost at all |
22:17:42 | Lear | no, I did a lossless compress, don't remember the settings though... |
22:17:55 | amiconn | I used maximum compression |
22:18:25 | amiconn | -h |
22:18:25 | preglow | amiconn: it is |
22:18:35 | preglow | amiconn: lossy files require much more |
22:19:35 | Lear | ok, it was more like 30-35% (for a ~900 kbps file)... |
22:20:25 | preglow | Lear: but i've seen varying cpu usage with lossless files as well, yes |
22:26:04 | | Join ender1 [0] (i=ychat@tm.213.143.74.124.dc.telemach.net) |
22:33:05 | | Quit ender` (Read error: 110 (Connection timed out)) |
22:39:26 | | Quit Bazz ("Client exiting") |
22:40:44 | amiconn | Something is wrong with the wavpack codec |
22:40:59 | amiconn | The voice ui doesn't work when playing wavpack |
22:41:08 | amiconn | It works with all others I can test |
22:42:20 | preglow | heh |
22:42:23 | preglow | lemme think |
22:42:26 | preglow | what's the glitch? |
22:43:01 | amiconn | It simply doesn't talk, even when paused |
22:43:21 | amiconn | After stopping playback the voice ui speaks the last queued clip |
22:43:55 | | Quit Inverno ("Client exiting") |
22:46:54 | preglow | queer |
22:48:14 | Lear | hm.. where does the codec swap happen anyway? |
22:48:31 | Lear | during pcmbuf_insert? |
22:50:40 | Lear | Yep, but only if the DSP is runnig. Which isn't the case for wavpack (except for resampling). Should be easy to fix. |
22:50:41 | amiconn | Hmm, mow much stack is displayed as used directly after boot with cvs rockbox? |
22:51:03 | Lear | which stack? which platform? |
22:51:22 | amiconn | Ergh, h1x0, main stack |
22:51:31 | Lear | one minute... |
22:51:45 | Lear | 6% |
22:51:55 | Lear | (that's before your context fix, btw). |
22:52:12 | preglow | i firmly believe the dsp should always be enabled |
22:52:13 | amiconn | Gah, voice UI causes rockbox to hang after returning from rockboy |
22:52:16 | preglow | that's a nonsense option |
22:52:35 | preglow | the dsp layer knows far better than the codec itself whether dsp operations are needed |
22:53:39 | Lear | but that's not really the issue in the wavpack case... |
22:54:26 | Lear | if dsp processing is off, codec_pcmbuf_insert_split_callback isn't called (the way it is done now), where the swap is done... |
22:54:51 | Lear | but currently the voice requires dsp to be always on, no matter what. |
22:55:05 | | Join Domonoky [0] (n=Domonoky@p549ACE46.dip.t-dialin.net) |
22:55:28 | preglow | so i say let's remove the dsp enable flag |
22:55:30 | preglow | it's nonsense |
22:55:43 | amiconn | Lear: thx |
22:55:47 | Domonoky | is it possible to compile a simulator build with Logf ? |
22:55:56 | Lear | I've done that... |
22:56:01 | amiconn | It's possible to reduce main stack on h1x0 to the same size as on archos |
22:56:01 | Bagder | Domonoky: yes |
22:56:02 | Lear | Was a little while ago though. |
22:56:17 | amiconn | Usage is 37% after returning from rockboy (the biggest stack eater) |
22:56:18 | Domonoky | how do i configure this ? |
22:56:22 | | Join zezayer_ [0] (n=zezayer@87.81.166.52) |
22:56:34 | Bagder | Domonoky: like you do it for target, select devel build |
22:56:43 | Bagder | then select sim and logf |
22:56:55 | Lear | and dsp_process isn't quite made with that in mind, so I suspect it wouldn't be as efficient as it could be then (when always on, that is). |
22:57:04 | | Nick zezayer_ is now known as zezayer (n=zezayer@87.81.166.52) |
22:57:32 | Domonoky | ah.. thx |
22:57:46 | preglow | Lear: so, as it is now, if a codec doesn't enable dsp, not even replaygain will be done? |
22:57:59 | Ctcp | Ignored 5 channel CTCP requests in 1 hour and 42 minutes at the last flood |
22:57:59 | * | amiconn hands preglow an extra 16KB of iram for codecs :) |
22:58:10 | * | preglow thanks amiconn and wraps sleeves up |
22:58:28 | preglow | now for a better way to measure performance increases |
22:58:39 | Lear | nope, I don't think so... But for all formats that supports replaygain should enable it... |
22:58:52 | preglow | well |
22:58:56 | preglow | i think it's stupid |
22:59:02 | preglow | it should be rewritten to always be enabled |
22:59:08 | amiconn | Why not simply always enable it? |
22:59:13 | Lear | and wavpack does that too. |
22:59:16 | preglow | if i enable eq, i don't want a friggin codec to override it for me |
22:59:18 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
22:59:35 | Lear | what eq? :) |
22:59:40 | amiconn | Even formats without replaygain support need it when playing at samplerates != 48kHz |
22:59:51 | amiconn | ...and stereo width would need it, and... |
22:59:55 | Lear | and so they enable it... |
22:59:59 | | Quit Aison () |
23:00 |
23:00:48 | Domonoky | hm.. i get an error, when compiling with german as standart language. |
23:00:49 | Lear | but you're right, dsp.c could contain the on/off logic. |
23:01:01 | Domonoky | a missing quote.. |
23:01:11 | | Quit cYmen ("zZz") |
23:01:12 | Domonoky | seem easy to fix :-) |
23:02:15 | Lear | Still, don't quite understand why the voice requires the dsp to be on; it doesn't seem to use it anyway... |
23:02:31 | preglow | welcome to evolutionary software design |
23:02:36 | amiconn | Lear: Now only 484 bytes left for fmrecorder after re-adding the pointer menu option... |
23:02:48 | preglow | well, it had to be done |
23:02:58 | Lear | Only uses the dsp-enabled pcmbuf_insert callback to do the swap... |
23:03:04 | amiconn | Lear: The sample rate is well below 44.1kHz for voice |
23:03:08 | Lear | amiconn, doesn't surprise me. :) |
23:03:13 | | Nick ender1 is now known as ender` (i=ychat@tm.213.143.74.124.dc.telemach.net) |
23:03:45 | Lear | well, so the voice codec requires the dsp, doesn't mean the music codec should be forced to have it... |
23:04:00 | amiconn | I think the dsp does the mixing (?) |
23:04:24 | Lear | nope, done in pcmbuf.c (as is the case for crossfading). |
23:04:42 | amiconn | Are there two dsp instances? |
23:05:01 | Lear | sort of, two states (data structs)... |
23:05:10 | amiconn | airgh |
23:05:13 | Lear | I guess that |
23:05:18 | Lear | 's the same. |
23:05:38 | preglow | hmm |
23:05:39 | Lear | It needs to keep config, resample state, dither state... |
23:06:08 | preglow | i wonder how easy it'd be to add a realtime measurement to the audio thread debug screen |
23:08:19 | Lear | boost rate is almost that. You don't want 90%+ boost, because buffering gets really slow then... |
23:08:33 | preglow | yeah, but it takes a while to reach a number i can use |
23:08:45 | Lear | oh well, time to hit the sack. bye. |
23:09:01 | | Quit Lear ("Chatzilla 0.9.68.5 [Firefox 1.0+/undefined]") |
23:10:36 | | Nick Mark__`afk is now known as Mark__ (n=Mark@cpc1-bele3-3-1-cust167.belf.cable.ntl.com) |
23:10:36 | DBUG | Enqueued KICK Mark__ |
23:10:36 | Mark__ | _( Y )_ |
23:10:36 | Mark__ | ()~*~() |
23:10:36 | Mark__ | (_)-(_) |
23:10:45 | preglow | Mark__: please, shut it off |
23:10:52 | Mode | "#RockBox +o Bagder " by ChanServ (ChanServ@services.) |
23:10:56 | preglow | it doesn't add to the conversation |
23:15:16 | solex | Did anybody already try to use the new wps image features? |
23:15:19 | amiconn | Domonoky: Fixed, thanks |
23:15:44 | Bagder | we don't _use_ features, we just add them ;-P |
23:15:57 | solex | :-D |
23:15:59 | solex | the wiki says "The image tag must be on its own line" |
23:16:08 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
23:16:08 | * | Bagder never records, never edit playlists and uses default of most stuff etc |
23:16:11 | * | amiconn never used images in the wps yet |
23:16:30 | solex | but the example below ("using images") suggests something else: |
23:16:37 | solex | %?mm<%xdb|%xdc|%xdd|%xde> |
23:16:37 | amiconn | Bagder: There is one thing I never used the default for - the line selector ;/ |
23:16:40 | Bagder | I don't think that "own line" is true |
23:17:42 | solex | forget it, my girlfriend says I need to sleep now :) |
23:17:43 | | Join webguest05 [0] (n=51f2f01a@labb.contactor.se) |
23:17:48 | Bagder | haha |
23:18:12 | solex | it's true! |
23:18:33 | preglow | she's fooling you! |
23:18:34 | solex | it was a tough ikea day. |
23:18:39 | preglow | oh god |
23:18:41 | preglow | you need to sleep! |
23:18:47 | preglow | i had one of those two days ago |
23:18:49 | preglow | slept like a child |
23:18:53 | Bagder | those days require sleep |
23:19:29 | solex | the ikea part wasn't that hard, but tidying up the room to build the table.. |
23:19:47 | * | solex ligths his last cigarette for the day |
23:20:48 | * | preglow joins in |
23:21:20 | solex | cool, remote smoking |
23:21:37 | preglow | no, it's pretty local |
23:21:40 | preglow | smells like it, at least |
23:22:06 | * | preglow strokes all his new iram |
23:22:10 | solex | bye |
23:22:15 | Bagder | pervert! |
23:22:17 | Bagder | ;-) |
23:22:21 | | Nick solex is now known as solex_away (n=jrschulz@c147121.adsl.hansenet.de) |
23:22:32 | preglow | if it feels good, it can't be bad! |
23:23:42 | amiconn | preglow: Btw, when adapting the iram sizes, I overlooked the 2 #defines in playback.c first. Gave very funny effects with the voice UI enabled |
23:23:59 | preglow | haha |
23:24:01 | amiconn | (codec iram was swapped incompletey) |
23:27:30 | | Join wacky_ [0] (n=wacky@modemcable006.177-201-24.mc.videotron.ca) |
23:27:40 | wacky_ | hey guys, anyone knows about the iAudio port development effort ? |
23:27:46 | | Join Paul_The_Nerd [0] (n=chatzill@cpe-66-68-93-2.austin.res.rr.com) |
23:29:58 | preglow | you'd have to ask austriancoder |
23:30:18 | Bagder | he's been very quiet recently |
23:33:47 | wacky_ | hmm... |
23:34:01 | wacky_ | I just bought an X5L, and was very pleased to see that Rockbox was being ported there too :) |
23:34:22 | wacky_ | since my iRiver H120,s LCD was broken!! |
23:34:25 | wacky_ | *ouch* |
23:34:45 | Bagder | I'm sure you can get good money for the rest of it |
23:34:45 | | Quit TCK- (Read error: 110 (Connection timed out)) |
23:35:38 | wacky_ | well.. I'd rather give good money to have it repaired or replaced.. but I just can't ! |
23:39:33 | wacky_ | who would buy that ? |
23:39:53 | Bagder | people who fry their players with bad chargers |
23:40:07 | Bagder | since they'll have a good lcd left |
23:41:51 | wacky_ | hmm.. but all I want is the Rockbox |
23:41:53 | wacky_ | running somewhere! |
23:41:56 | | Nick Mark__ is now known as Mark__`afk (n=Mark@cpc1-bele3-3-1-cust167.belf.cable.ntl.com) |
23:41:56 | DBUG | Enqueued KICK Mark__`afk |
23:42:05 | wacky_ | your software is my desire !! |
23:42:20 | Bagder | then join up with ac and the iaudio dudes and make it happen |
23:42:25 | Bagder | he seems to need some help |
23:42:41 | wacky_ | Imagine I could have a remote capturing software running on a tiny machine like an iAudio or an iRiver! wow.. |
23:42:53 | wacky_ | well I'm of no use for hardware stuff |
23:43:01 | wacky_ | it seems the iAudio port needs a bootloader also |
23:43:13 | wacky_ | and it seems that the only one who has ever worked with the bootloader stuff, is Linus |
23:48:44 | | Join webguest83 [0] (n=18d79b85@labb.contactor.se) |
23:49:01 | webguest83 | i hope someone's here... |
23:49:10 | webguest83 | is there a way to change the boot logo easily? |
23:49:25 | Bagder | it depends |
23:49:29 | Bagder | on what you call easy |
23:49:44 | webguest83 | ill consider "compiling" an easy task |
23:49:47 | Bagder | you need to replace a piece of source code |
23:49:52 | webguest83 | but "programming" = not easy |
23:49:54 | webguest83 | ic |
23:50:03 | webguest83 | apps/icons.c is it? |
23:50:09 | Bagder | sounds right |
23:50:30 | webguest83 | those hex numbers seem to be it... |
23:50:33 | Bagder | yes |
23:50:37 | | Quit zezayer ("Chatzilla 0.9.68.5 [SUSE 1.0.6-4.1/20050715]") |
23:50:41 | Bagder | bmp2rb is the tool |
23:50:41 | webguest83 | and im stuck there :) |
23:50:44 | webguest83 | ah |
23:51:13 | webguest83 | size limit? |
23:51:25 | wacky_ | why is it a so widespread habit to include pictures as hex stuff in source code ? |
23:51:32 | wacky_ | wouldn't file loading be easier ? |
23:51:38 | Bagder | haha |
23:51:41 | Bagder | before ata is inited? |
23:51:42 | webguest83 | haha |
23:51:45 | dwihno | \o/ |
23:51:49 | dwihno | A great idea! |
23:51:55 | | Quit DangerousDan (Read error: 104 (Connection reset by peer)) |
23:52:00 | webguest83 | ok how bout this |
23:52:14 | webguest83 | is it safe to completely remove that picture loading lines? |
23:52:16 | Bagder | webguest83: I don't think there's a limit other than screen size, but you may need to edit the code if you change size |
23:52:19 | wacky_ | oh :) right |
23:52:21 | webguest83 | so it boots up faster? |
23:52:30 | webguest83 | well.. hmm |
23:52:42 | Bagder | I don't think you'll see any difference by removing the pic |
23:52:44 | Zagor | webguest05: sure. i bet you'll gain at least 30 ms :-) |
23:52:45 | Bagder | but sure, try |
23:53:18 | webguest83 | lol 30ms.. |
23:53:35 | webguest83 | oh, and when i said "size" i mean the dimensions |
23:54:07 | Bagder | me too |
23:54:41 | webguest83 | oh ok :p |
23:55:17 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
23:55:34 | | Quit DangerousDan (Client Quit) |
23:56:01 | | Nick Mark__`afk is now known as Mark__ (n=Mark@cpc1-bele3-3-1-cust167.belf.cable.ntl.com) |
23:56:01 | DBUG | Enqueued KICK Mark__ |
23:56:07 | | Nick Mark__ is now known as Mark__`away (n=Mark@cpc1-bele3-3-1-cust167.belf.cable.ntl.com) |
23:56:07 | DBUG | Enqueued KICK Mark__`away |
23:58:42 | webguest83 | ah, the dimensions are in the code itself.. |
23:58:48 | webguest83 | ok i got everything, ty :) |
23:58:55 | | Quit webguest83 ("CGI:IRC") |