| 00:16:07 | | Quit Midgey34 (Remote closed the connection) |
| 00:21:15 | preglow | oh? |
| 00:21:17 | preglow | works just fine here |
| 00:21:40 | preglow | compiled again, works just fine |
| 00:21:50 | preglow | i'll try a make clean and see if it's a dep problem |
| 00:22:41 | preglow | ahhhh |
| 00:22:44 | preglow | i know what it is |
| 00:22:55 | preglow | i forgot to commit the macsr change |
| 00:23:43 | preglow | i've placed it in NeAACDecInit2, do you think that'll suffice? |
| 00:23:50 | preglow | any function that is always called will do |
| 00:25:04 | | Quit ender` (Read error: 113 (No route to host)) |
| 00:28:37 | preglow | linuxstb: try it now |
| 00:29:39 | preglow | perhaps NeAACDecOpen would have been a better place? |
| 00:32:19 | preglow | i've also disabled SSR, LD and LTP locally, but this results in: no major code size changes, and several warnings in the code |
| 00:32:51 | | Join ashridah [0] (i=ashridah@220-253-121-29.VIC.netspace.net.au) |
| 00:35:57 | | Quit DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 00:40:08 | | Quit paugh ("brb") |
| 00:40:18 | linuxstb | preglow: Yes, that's fine again now. |
| 00:40:52 | | Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
| 00:42:11 | linuxstb | It's definitely more than 50% realtime now. |
| 00:43:17 | preglow | then hooray |
| 00:43:23 | preglow | i'm looking into having it output 32 bit numbers now |
| 00:43:25 | linuxstb | SSR is already disabled in libfaad - see the "#ifdef FIXED_POINT" lines in common.h. "MAIN" is also disabled. |
| 00:43:28 | preglow | and deinterleaved |
| 00:43:42 | preglow | so dsp doesn't have so much work to do |
| 00:43:58 | linuxstb | Is the output buffer in IRAM? |
| 00:44:21 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
| 00:44:30 | preglow | not yet |
| 00:44:33 | preglow | that is, it is here |
| 00:44:35 | preglow | but not in cvs |
| 00:44:44 | linuxstb | But that doesn't help the speed much? |
| 00:44:47 | preglow | no |
| 00:44:51 | preglow | nothing seems to help the speed much |
| 00:45:16 | | Quit DangerousDan (Read error: 104 (Connection reset by peer)) |
| 00:45:19 | preglow | so i've just diverged into something i know will help: 32 bit deinterleaved data |
| 00:45:40 | | Join Sandking [0] (n=jacek@ogorek.akron.wroc.pl) |
| 00:51:34 | preglow | i'm not THAT far from realtime for 128kbps here |
| 00:52:12 | | Quit tvelocity ("Leaving") |
| 00:52:26 | linuxstb | nice. |
| 00:52:42 | linuxstb | How much of the IRAM are you using now? |
| 00:52:45 | preglow | not veru |
| 00:53:09 | preglow | about 30k |
| 00:53:16 | preglow | more or less arbitrarily allocated |
| 00:53:26 | preglow | output buffers are iram, at least |
| 00:53:35 | preglow | but that might not be the wisest choice for this code |
| 00:53:35 | preglow | fc |
| 00:53:39 | preglow | codec <- |
| 00:54:09 | preglow | when you did your iram allocating, did you have any reason for using it the places you did, or was it completely random? |
| 00:54:17 | preglow | just so i know i can remove them |
| 00:54:22 | linuxstb | completely random. |
| 00:56:25 | preglow | it doesn't have any option for non-interleaved audio, it seems |
| 00:56:26 | preglow | hooray |
| 00:57:24 | TiMiD | hi there |
| 00:57:31 | preglow | hello |
| 00:57:58 | TiMiD | I just tried to add a new file to CVS (cvs add) and now when I commit I get this error : |
| 00:58:01 | TiMiD | cvs update: warning: `textarea.c' was lost |
| 00:58:13 | TiMiD | what does that means ? |
| 00:58:49 | preglow | that you've deleted it |
| 00:58:57 | preglow | ahh, riight |
| 00:59:05 | preglow | it deletes it, then updates it to get the id string right |
| 00:59:15 | TiMiD | hmm ok :) |
| 00:59:22 | preglow | you probably commited it with just $id:$ in the header, right? |
| 00:59:27 | TiMiD | so everything is ok ;) |
| 00:59:30 | TiMiD | yes :) |
| 00:59:36 | preglow | yes, and now it's magically filled out ;) |
| 00:59:42 | TiMiD | huhu :) |
| 01:00 |
| 01:00:36 | preglow | what the flaming hell is this????? |
| 01:00:49 | preglow | floating point math in our output routine? |
| 01:00:55 | TiMiD | uh ? |
| 01:01:25 | preglow | forget it, just me being stupid |
| 01:04:43 | | Quit cYmen ("zZz") |
| 01:05:01 | linuxstb | TiMiD: onplay.c is still utf-8 :) |
| 01:06:36 | preglow | there's a bit of processing in the output driver i'll just go ahead and bypass |
| 01:07:08 | linuxstb | preglow: Where is that? |
| 01:07:49 | TiMiD | arghhhhhhhh |
| 01:07:55 | preglow | linuxstb: output.c |
| 01:08:50 | TiMiD | my editor must be cursed, that's the only possibility :) |
| 01:09:52 | TiMiD | ouch a warning |
| 01:10:04 | linuxstb | preglow: Pretty obvious place for it. |
| 01:10:58 | preglow | yep |
| 01:11:09 | preglow | i'll just bypass the entire thing |
| 01:11:12 | linuxstb | Can we set FAAD_FMT_FIXED somewhere to make it output native format? |
| 01:11:38 | preglow | in practice, that's what i'm doing |
| 01:12:07 | linuxstb | So are you bypassing that function completely? |
| 01:12:53 | linuxstb | I forgot that AAC is used for multi-channel sound sometimes. But I don't think we need to support that. |
| 01:13:38 | preglow | now,let's see |
| 01:13:42 | preglow | linuxstb: nor do i |
| 01:13:52 | preglow | linuxstb: i'm bypassing it completely and just accessing time_out as is |
| 01:14:42 | | Quit dpassen1 () |
| 01:16:33 | preglow | a wee bit closer to realtime again with that |
| 01:17:42 | linuxstb | Do you still copy the data, or do you just return the data directly from time_out? |
| 01:18:36 | preglow | i use time_out directly from the codec plugin |
| 01:18:39 | preglow | just to see if it works |
| 01:18:45 | preglow | i don't know if i'll bother to do anything cleaner |
| 01:19:03 | linuxstb | I don't mind cleaning that up. Is time_out in IRAM? |
| 01:19:12 | preglow | it is here |
| 01:19:23 | preglow | but i got some nice clipping free with this one |
| 01:19:24 | preglow | i wonder why |
| 01:19:43 | preglow | i've updated SET_SAMPLE_DEPTH to 29 |
| 01:19:51 | preglow | but it clips at around 0.2 full scale |
| 01:21:02 | preglow | plus, i did some assumptions when putting time_out in iram, namely: no more than two channels, and max frame size is 2048 |
| 01:21:27 | preglow | hmm, or 1024, it seems... |
| 01:21:36 | *** | Saving seen data "./dancer.seen" |
| 01:21:38 | preglow | which must be perfectly valid, seeing as how it works |
| 01:22:51 | | Quit muesli_- (Read error: 110 (Connection timed out)) |
| 01:25:01 | preglow | seems clipping limits aren't automatically set |
| 01:25:04 | preglow | i wonder why |
| 01:32:06 | preglow | linuxstb: but ok, what i've basically done now is comment away the Out_To_PCM call in aac_frame_decode, and then just access hDecode->time_out directly from aac.c |
| 01:33:06 | linuxstb | I think that's fair enough. |
| 01:34:20 | linuxstb | So that means we don't need to malloc sample_buffer ? |
| 01:35:01 | preglow | it's never used, so no |
| 01:35:23 | preglow | iram or no, i can see no reason for us to not just simply access time_out as is |
| 01:35:26 | preglow | we have no conversion needs |
| 01:35:39 | linuxstb | I agree. |
| 01:36:30 | preglow | TiMiD: what's up, i can't build anymore |
| 01:37:03 | preglow | gui/statusbar.h:113: error: `NB_SCREENS' undeclared here (not in a function) |
| 01:37:19 | TiMiD | erm |
| 01:37:29 | TiMiD | it compiles very well here |
| 01:37:31 | TiMiD | let me see |
| 01:37:43 | preglow | i just did cvs update, make clean, and reconfigure |
| 01:37:56 | linuxstb | Same problem here. |
| 01:37:57 | Moos | red builds |
| 01:38:13 | TiMiD | oucchhhhhh |
| 01:38:17 | TiMiD | wtf |
| 01:38:27 | TiMiD | I just added a .h |
| 01:38:42 | TiMiD | and corrected a UTF-8 pbl |
| 01:39:10 | preglow | do a cvs diff and check what's different on your part |
| 01:39:13 | preglow | it's got to be something |
| 01:39:50 | TiMiD | I try to recompile on my box |
| 01:40:22 | TiMiD | but look my other CVS changes just did some yellow because I forgot a .h (my gcc didn't told me that) |
| 01:41:16 | TiMiD | I'm investigating this |
| 01:42:03 | preglow | NB_SCREENS is defined in screen_access.h, so it obviously isn't included when it should be |
| 01:42:09 | preglow | i can't imagine something else being wrong |
| 01:42:12 | TiMiD | ok |
| 01:42:15 | TiMiD | I see |
| 01:42:17 | preglow | i'll just go brush my teeth in the meanwhile |
| 01:42:23 | TiMiD | it's a circular include problem |
| 01:47:52 | preglow | any fix forthcoming? |
| 01:48:00 | TiMiD | no :/ |
| 01:48:06 | TiMiD | I've spotted the pbl |
| 01:48:20 | preglow | you really need to test everything before you commit |
| 01:48:25 | TiMiD | anyway you just have to remove the #include "textarea.h" |
| 01:48:31 | preglow | if you can't fix it now, revert it until you can fix it |
| 01:48:42 | TiMiD | in screen_acces.h if youi need to work |
| 01:49:00 | TiMiD | but I'm a little lost here |
| 01:49:03 | preglow | nono, if you're not going to fix it now, you need to revert your changes |
| 01:49:21 | TiMiD | ok how do I do this ? |
| 01:49:38 | TiMiD | if I revert my changes there will be a warning |
| 01:49:47 | preglow | a warning is better than a broken build |
| 01:49:52 | TiMiD | yep |
| 01:50:12 | preglow | you revert things more or less just by removing what you commited, then commiting again |
| 01:50:16 | preglow | at least that's the only way i know of |
| 01:50:35 | | Quit DMJC-sleep (Read error: 110 (Connection timed out)) |
| 01:50:58 | linuxstb | TiMiD: Just remove that troublesome include from your local copy and commit that change. |
| 01:51:05 | linuxstb | I agree that yellow is better than red. |
| 01:52:21 | TiMiD | the problem is that there are other changes in my local copy |
| 01:52:29 | linuxstb | I'll commit it then. |
| 01:52:38 | TiMiD | I'm testing if it doesn't break anything (it shouldn't) and I commit) |
| 01:53:00 | preglow | if you can't, there's no trouble for us to do it |
| 01:53:04 | preglow | it's just a matter of removing a line |
| 01:53:41 | preglow | but didn't this show up in your build, or didn't you test it at all before commiting? |
| 01:53:53 | preglow | if it's the last: don't do it again ;) |
| 01:54:02 | TiMiD | it's the last :p |
| 01:54:10 | preglow | yes, everyone needs to get burnt once on that |
| 01:54:12 | TiMiD | (I didn't recompiled it for a small include :) ) |
| 01:54:42 | preglow | but get in the habit of building everything, even the smallest change |
| 01:54:44 | TiMiD | everything is working well with my last changes so I commit |
| 01:54:51 | preglow | okies |
| 01:56:32 | TiMiD | anyway the problem is still here :( |
| 01:56:44 | TiMiD | I need to find a way fo fix this warning |
| 01:57:18 | preglow | sure, and we'll allow you to do that in peace and quiet as soon as we can continue on our coding :) |
| 01:57:22 | linuxstb | Yes, it compiles fine now - with that single warning. |
| 01:57:47 | TiMiD | once again I'm dumb :( |
| 01:58:05 | TiMiD | I included the .h in screen_access.h instead of .c :p |
| 01:58:12 | preglow | so it's fixed? |
| 01:58:21 | TiMiD | I hope |
| 01:58:26 | preglow | then hooray! |
| 01:58:30 | TiMiD | but I have no way to see if there is a warning |
| 01:58:39 | TiMiD | since gcc doesn't warns |
| 01:58:44 | preglow | oh? |
| 01:58:47 | preglow | what gcc version ? |
| 01:58:52 | preglow | it warns here |
| 01:58:59 | TiMiD | 3.4.4 |
| 01:59:06 | preglow | weird |
| 01:59:12 | preglow | i've got 3.4.1 and that warns |
| 01:59:41 | TiMiD | maybe because I compile it for simulator |
| 02:00 |
| 02:00:42 | preglow | maybe |
| 02:00:46 | preglow | why do that? |
| 02:00:53 | linuxstb | I think you should always compile for the target before comitting - it's much more important than the sim. |
| 02:01:27 | linuxstb | Even though with the part of Rockbox you're working on, it shouldn't matter - but it obviously does. |
| 02:01:40 | preglow | you haven' |
| 02:01:51 | preglow | you haven't got an actual unit? |
| 02:01:56 | TiMiD | I 'll do it by now, I had problems with a plugin working fine on simulator but not on target |
| 02:02:05 | TiMiD | ? |
| 02:02:13 | preglow | ahh, forget it |
| 02:02:25 | preglow | i'm so used to never using the sim myself, i just assume no one else does as well :) |
| 02:02:51 | TiMiD | If I didn't owned a unit, I wouldn't be there I think :p |
| 02:03:14 | preglow | ohh, it's not the first time someone coded without a unit |
| 02:03:28 | linuxstb | I've started using the sim a little recently (AAC only worked in the sim for a while). It makes debugging a lot easier - DEBUGF is very useful. |
| 02:03:45 | TiMiD | they code without getting the taste of their work ? |
| 02:04:00 | TiMiD | linuxstb: yes, the sim also saves your USB cable :) |
| 02:04:46 | linuxstb | It would be useful for a H3x0 owner to get a the H3x0 sim working. That could speed up development in advance of the bootloader. |
| 02:05:36 | preglow | perhaps i should try making speex work in the sim first |
| 02:05:43 | preglow | i'm so used to being unable to use the sim i don't even consider it |
| 02:06:08 | linuxstb | preglow: Yes, I think you would find it easier. |
| 02:06:40 | linuxstb | Do you use cygwin or a Linux box for your compiles? |
| 02:07:42 | preglow | remote linux box |
| 02:08:05 | preglow | i've got cygwin installed, so i've got an x server handy |
| 02:08:10 | preglow | audio will be another issue, however |
| 02:08:50 | TiMiD | I never managed to make audio work on the sim :( |
| 02:09:55 | preglow | i could of course just use a win32 sim and copy it all the time |
| 02:09:57 | preglow | not too much of a bother |
| 02:12:39 | linuxstb | Even without sound, it could still be useful. Once you get to that stage, then the sim probably isn't that useful any more. |
| 02:15:20 | preglow | man, my h120 reacts violently to usb unplugging now |
| 02:15:41 | preglow | flashes up an illinstr, and then the backlight starts _strobing_ |
| 02:16:13 | preglow | hahaha |
| 02:16:18 | preglow | iriver firmware loaded after restart |
| 02:17:28 | preglow | i just might be writing outside some buffers here... |
| 02:18:25 | | Nick paugh is now known as AliasCoffee (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
| 02:19:17 | linuxstb | wtf. Playing a 24-bit WAV files causes the CPU to boost... |
| 02:20:21 | preglow | hahah |
| 02:20:37 | preglow | heavy stuff, that |
| 02:22:56 | linuxstb | 24-bit wavs have a higher boost ratio than wavpack... |
| 02:23:32 | preglow | snappy |
| 02:23:38 | linuxstb | I think that proves we shouldn't use the boost ratio to measure CPU usage. |
| 02:23:41 | preglow | any obvious reasons for this...? |
| 02:23:54 | preglow | i've always said we shouldn't do that |
| 02:23:56 | linuxstb | I'm guessing playback.c is confused. |
| 02:24:59 | preglow | arghh |
| 02:25:08 | preglow | whatever important arrays i put in iram: no dice |
| 02:25:46 | preglow | linuxstb: those arrays aren't marked const |
| 02:26:15 | linuxstb | Which arrays? |
| 02:26:53 | linuxstb | The wav ones? |
| 02:27:04 | linuxstb | True. They should have been. |
| 02:29:33 | preglow | talking libfaad here |
| 02:30:03 | preglow | now i'm using 37k iram |
| 02:30:12 | preglow | solely for imdct arrays |
| 02:30:42 | linuxstb | How close are you to realtime now? |
| 02:31:31 | preglow | am i the only one with the usb disconnect glitch? |
| 02:32:42 | preglow | it's a bit hard to say, i can't say i ever hear any improvement |
| 02:33:08 | linuxstb | preglow: I just got an illegal instruction when disconnecting from USB. |
| 02:33:49 | preglow | that's what get as well |
| 02:33:52 | linuxstb | Yes, it's repeatable. |
| 02:33:52 | preglow | what i get as well |
| 02:33:55 | preglow | consequently |
| 02:34:03 | linuxstb | I04: IllInstr at 00000002 |
| 02:34:07 | preglow | yup |
| 02:34:37 | linuxstb | Was it us or TiMiD? |
| 02:34:44 | preglow | i have no idea |
| 02:34:46 | linuxstb | I'm guessing it's a screen problem. |
| 02:34:49 | preglow | i don't see how it can have been any of us |
| 02:35:17 | preglow | at least i don't see how it can have been me ;) |
| 02:35:32 | preglow | but ok |
| 02:35:35 | preglow | this is frustrating |
| 02:35:55 | preglow | i just leeched aac.codec from the latest daily build, and there is almost _no_ difference |
| 02:36:00 | preglow | i can't hear any difference at all |
| 02:36:08 | preglow | i'll just toss my aac.codec up so you can have a listen |
| 02:36:18 | linuxstb | You mean difference in speed? |
| 02:37:00 | preglow | yes |
| 02:37:16 | preglow | www.pvv.org/~thomj/rockbox/aac.codec |
| 02:38:48 | | Quit Moos ("Glory to Rockbox") |
| 02:38:52 | linuxstb | I think it is slightly better - more music between gaps. |
| 02:39:59 | preglow | i somehow expected more than sligtly better after getting rid of the sample conversion and buffer copying, plus placing all important imdct buffers in iram |
| 02:40:21 | linuxstb | But did you remove other buffers from iram? |
| 02:40:40 | linuxstb | It's definitely better though. |
| 02:41:01 | preglow | i removed the ones you put there, if that's what you mean |
| 02:41:40 | preglow | right now it contains around five buffers, and each is around 8kb large |
| 02:44:04 | linuxstb | But at least your sample conversion removes the need for a set of mallocs. |
| 02:45:10 | preglow | sure, but i would have expected more from the iram |
| 02:45:25 | preglow | perhaps i'm just mistaken as to what arrays are actually used the most |
| 02:46:33 | preglow | there are buffers flying around everywhere, so it's a bit hard to know without reading the code more thoroughly |
| 02:48:29 | preglow | in any case, i think we can just plain forget decoding anything but LC files |
| 02:48:34 | preglow | perhaps main |
| 02:48:50 | preglow | i'd love to decode sbr files, but we can more or less just forget that |
| 02:49:35 | TiMiD | linuxstb: does the unit crashes ? |
| 02:49:44 | preglow | TiMiD: yep, on usb deplug |
| 02:49:46 | linuxstb | TiMiD: Yes - when removing USB. |
| 02:49:52 | TiMiD | :( |
| 02:49:54 | linuxstb | I've just broken the sim :). |
| 02:50:05 | linuxstb | We're having a bad night. |
| 02:50:23 | TiMiD | grrrrrrrrrrrrrrrr |
| 02:50:59 | TiMiD | I test on my unit |
| 02:53:24 | preglow | i love the fact that DEBUGF and LOGF don't take the api struct as a parameter, like LOGF(ci, "hehe"); |
| 02:53:26 | linuxstb | OK, sim should be fixed. |
| 02:53:31 | preglow | they just simply assume 'rb', which is braindead |
| 02:53:33 | linuxstb | preglow: I know. |
| 02:53:49 | linuxstb | I'll try and fix that one day. |
| 02:53:59 | linuxstb | At least it should be "ci", not "rb". |
| 02:54:01 | preglow | a lot of code needs updating if you do :P |
| 02:54:14 | preglow | linuxstb: well, same mechanism is used for plugins, where they're often called rb |
| 02:54:47 | TiMiD | crash :( bad |
| 02:57:10 | * | preglow hopes LOGF is still working |
| 02:57:19 | TiMiD | the crash happens only when dircache is enabled |
| 02:57:39 | preglow | TiMiD: it didn't happen before today, i think |
| 02:57:46 | TiMiD | I don't know |
| 02:58:08 | | Join actionshrimp [0] (i=dave@dhcp-163-1-214-173.seh.ox.ac.uk) |
| 02:58:09 | TiMiD | what should I do ? |
| 02:58:22 | linuxstb | Yes, it started late tonight. |
| 02:58:25 | preglow | ignore it |
| 02:58:39 | preglow | and ask some of the big boys tomorrow |
| 02:58:47 | TiMiD | hmm ok |
| 02:59:00 | TiMiD | maybe it's not dorectly related to my code |
| 02:59:07 | linuxstb | You could try and narrow down which commit broke it. |
| 02:59:11 | preglow | unless you can be bothered to find out which commit broke it |
| 02:59:52 | preglow | i'm pretty sure it's not one of mine, the only core part i've touched is dsp.c |
| 03:00 |
| 03:00:28 | TiMiD | how do you get the code source for a given date ? |
| 03:01:11 | linuxstb | I think it's something like "cvs co -D '2005-11-01 23:20' apps" |
| 03:02:18 | preglow | hmm |
| 03:02:23 | preglow | remote support breaks remote logf |
| 03:03:36 | TiMiD | preglow: just set NB_SCREENS to 1 in screen_access.h |
| 03:04:00 | TiMiD | it will not write on the remote with that |
| 03:04:03 | preglow | TiMiD: isn't there a way for that be done automatically if ROCKBOX_HAVE_LOGF (or whatever it's called) is set? |
| 03:04:30 | preglow | perhaps there should be a new option for remote logf |
| 03:04:46 | preglow | for people who use the remote and wants logf file writing support only |
| 03:04:57 | TiMiD | maybe unset HAVE_REMOTE_LCD |
| 03:05:12 | TiMiD | hmm not a good idea |
| 03:05:27 | TiMiD | anyway if you just change NB_SCREENS it will be good |
| 03:06:22 | linuxstb | I think you should set NB_SCREENS to 1 when ROCKBOX_HAS_LOGF. The other case will be the minority. |
| 03:06:45 | linuxstb | That can be done in screen_access.h |
| 03:06:55 | TiMiD | ok |
| 03:07:37 | TiMiD | I'm recompiling a build from this morning |
| 03:07:44 | TiMiD | I will see if it crash |
| 03:07:50 | TiMiD | the I go to sleep :) |
| 03:07:53 | TiMiD | then |
| 03:08:27 | TiMiD | ok the build from this morning doesn't compile |
| 03:08:43 | linuxstb | preglow: Try changing line 33 of screen_accesss.h to #if defined(HAVE_REMOTE_LCD) && !defined (ROCKBOX_HAS_LOGF) |
| 03:08:58 | TiMiD | linuxstb: I will commit that |
| 03:09:13 | linuxstb | Test it first :) I don't have a remote, so I'm only guessing. |
| 03:10:05 | TiMiD | anyway I'm very annoyed by the crash |
| 03:10:17 | TiMiD | what does the error means ? |
| 03:12:33 | preglow | illegal instruction encountered at an iram address |
| 03:12:34 | preglow | i think |
| 03:13:32 | TiMiD | never encountered that :( |
| 03:14:27 | TiMiD | well I saw it once when I compiled rb for a slightly different model of cpu |
| 03:15:49 | preglow | think i need to start calling it a night |
| 03:16:09 | TiMiD | yes |
| 03:16:10 | preglow | i was suspecting my iram arrays were never used, and overwritten with some malloced ones |
| 03:16:14 | preglow | but turns out that's not the case :/ |
| 03:19:11 | linuxstb | preglow: Does point 4c) in this forum post mean anything to you? http://forums.rockbox.org/index.php?topic=1721.msg11280#msg11280 |
| 03:19:40 | linuxstb | The sentence about Rockbox not supporting large delays in LAME headers |
| 03:21:22 | preglow | linuxstb: well, no |
| 03:21:38 | *** | Saving seen data "./dancer.seen" |
| 03:21:41 | preglow | linuxstb: the only delay i know of in mpeg audio, is encoder delay, and that doesn't vary too much |
| 03:22:15 | preglow | linuxstb: it doesn't say anything about a lame header that i can see |
| 03:23:09 | linuxstb | This post could be useful: http://www.hydrogenaudio.org/forums/index.php?showtopic=35654 |
| 03:23:24 | linuxstb | It refers to "encoder padding" |
| 03:23:28 | linuxstb | as well as delay. |
| 03:23:40 | preglow | linuxstb: btw, your remote change worked |
| 03:23:43 | preglow | think i'll commit it |
| 03:24:53 | preglow | linuxstb: right, they call that delay |
| 03:25:11 | preglow | linuxstb: in that case, he's right, i always did wonder if delays that large existed |
| 03:25:15 | preglow | and now i know |
| 03:26:38 | | Join pokecapn [0] (n=rofl@hc65252ea.dhcp.vt.edu) |
| 03:27:07 | pokecapn | I want to make a really simple change to the code, should I just bug a developer or should I figure out how to do it myself |
| 03:27:50 | linuxstb | pokecapn: What's the change? |
| 03:28:11 | pokecapn | increasing the maximum encoder delay that's allowed in the lame tag |
| 03:28:25 | linuxstb | hehe. We were just discussing that. |
| 03:28:27 | pokecapn | i'm assuming the code there was ganked from foobar 0.8.3 but foobar does it wrong |
| 03:28:31 | preglow | pokecapn: you'll need more than just a one line change |
| 03:28:41 | pokecapn | well if i wanted to do it properly yeah |
| 03:28:55 | preglow | i was planning to fix it tomorrow |
| 03:29:27 | pokecapn | the proper way would be removing that line entirely and looking at the crc, but i have no idea how to do that so i was just going to increase the limits in the if statement |
| 03:29:33 | pokecapn | but yeah if it's being worked on already that's great |
| 03:29:33 | preglow | no, not just that |
| 03:29:40 | pokecapn | what else? |
| 03:29:48 | preglow | the code just supports skipping one frame at the moment |
| 03:29:51 | preglow | one frame is 1152 samples |
| 03:29:53 | | Quit actionshrimp ("a bird in the bush is worth two in your house") |
| 03:30:07 | pokecapn | oh i see |
| 03:30:09 | preglow | but like i said, i'll see about fixing it tomorrow |
| 03:30:12 | pokecapn | cool |
| 03:30:34 | pokecapn | carry on then |
| 03:30:35 | | Quit pokecapn (Client Quit) |
| 03:31:03 | preglow | i need to verify that mpa.c does proper gapless as well |
| 03:31:09 | preglow | i suspect it doesn't |
| 03:31:56 | linuxstb | I wonder if foobar attempts gapless AAC. |
| 03:33:07 | preglow | god knows |
| 03:33:15 | preglow | if it does, you should be able to so it from the plugin source |
| 03:39:37 | preglow | but i need to call it a night |
| 03:39:38 | preglow | later, all |
| 03:41:38 | linuxstb | me too. night. |
| 04:00 |
| 04:56:33 | | Join Lost-ash [0] (i=ashridah@220-253-123-107.VIC.netspace.net.au) |
| 05:00 |
| 05:03:51 | | Quit ashridah (Nick collision from services.) |
| 05:03:58 | | Nick Lost-ash is now known as ashridah (i=ashridah@220-253-123-107.VIC.netspace.net.au) |
| 05:11:39 | | Quit AliasCoffee ("zzz") |
| 05:21:39 | *** | Saving seen data "./dancer.seen" |
| 06:00 |
| 06:36:02 | | Quit RotAtoR () |
| 07:00 |
| 07:21:43 | *** | Saving seen data "./dancer.seen" |
| 07:23:22 | | Join ender` [0] (i=ychat@84.52.165.220) |
| 07:38:27 | | Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-130-062.pools.arcor-ip.net) |
| 07:47:28 | | Join B4gder [0] (n=daniel@static-213-115-255-230.sme.bredbandsbolaget.se) |
| 07:49:07 | amiconn | morning |
| 07:49:13 | B4gder | hey |
| 07:49:54 | amiconn | B4gder: Could you perhaps have a look at fixing buildzip.pl ? |
| 07:50:09 | B4gder | yeps, I will |
| 07:51:10 | amiconn | thanks |
| 08:00 |
| 08:09:48 | | Quit ashridah ("Leaving") |
| 08:12:46 | | Quit Kohlrabi (Read error: 104 (Connection reset by peer)) |
| 08:17:43 | | Join solexx_ [0] (n=jrschulz@c223035.adsl.hansenet.de) |
| 08:29:39 | | Quit solexx (Read error: 110 (Connection timed out)) |
| 08:30:53 | | Join ashridah [0] (i=ashridah@220-253-121-238.VIC.netspace.net.au) |
| 08:42:52 | | Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) |
| 08:55:56 | | Quit Rick (Read error: 104 (Connection reset by peer)) |
| 08:57:51 | | Join Rick [0] (i=rick@pool-71-108-9-40.lsanca.dsl-w.verizon.net) |
| 09:00 |
| 09:07:27 | | Join _FireFly_ [0] (n=FireFly@p54A477F8.dip.t-dialin.net) |
| 09:20:25 | | Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-130-062.pools.arcor-ip.net) |
| 09:21:47 | *** | Saving seen data "./dancer.seen" |
| 09:27:23 | | Join Zagor [0] (n=bjst@pdpc/supporter/sustaining/Zagor) |
| 09:30:04 | | Quit ryan_j ("leaving") |
| 09:30:34 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
| 09:49:01 | | Join DMJC [0] (n=DMJC-L@220-245-177-240-sa-pppoe.tpgi.com.au) |
| 10:00 |
| 10:02:09 | | Quit ghode|afk (Read error: 110 (Connection timed out)) |
| 10:13:20 | | Quit Seed (Nick collision from services.) |
| 10:13:25 | | Join Seedy [0] (i=ben@85-64-200-85.barak-online.net) |
| 10:22:02 | | Nick solexx_ is now known as solexx (n=jrschulz@c223035.adsl.hansenet.de) |
| 10:45:46 | | Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 10:46:27 | | Quit Kohlrabi ("Leaving") |
| 10:50:57 | | Join cYmen_ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 10:56:07 | | Join arkascha [0] (n=arkascha@mailout.imageware.de) |
| 10:56:11 | | Join cYmen__ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 10:59:26 | | Join thegeek_ [0] (n=thegeek@s115b.studby.ntnu.no) |
| 10:59:27 | | Quit thegeek (Read error: 104 (Connection reset by peer)) |
| 11:00 |
| 11:01:22 | | Join cYmen___ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 11:01:22 | *** | Alert Mode level 1 |
| 11:01:22 | DBUG | Enqueued KICK cYmen |
| 11:01:22 | DBUG | Enqueued KICK cYmen_ |
| 11:01:22 | *** | Alert Mode level 2 |
| 11:01:22 | DBUG | Enqueued KICK cYmen__ |
| 11:01:22 | DBUG | Enqueued KICK cYmen___ |
| 11:01:22 | *** | Alert Mode level 3 |
| 11:03:45 | | Quit cYmen (Connection timed out) |
| 11:06:32 | | Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 11:06:32 | *** | Alert Mode level 4 |
| 11:06:32 | *** | Alert Mode level 5 |
| 11:06:32 | DBUG | Enqueued KICK cYmen |
| 11:06:32 | *** | Alert Mode level 6 |
| 11:06:32 | *** | Alert Mode level 7 |
| 11:06:32 | *** | Alert Mode level 8 |
| 11:07:30 | | Join tvelocity [0] (n=tony@ipa105.5.tellas.gr) |
| 11:08:46 | | Quit cYmen_ (Connection timed out) |
| 11:11:18 | | Join Paul_The_Nerd [0] (n=paulthen@cpe-66-68-93-2.austin.res.rr.com) |
| 11:13:45 | | Quit cYmen__ (Connection timed out) |
| 11:14:40 | | Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-130-062.pools.arcor-ip.net) |
| 11:16:33 | *** | Alert Mode OFF |
| 11:18:50 | | Quit cYmen___ (Connection timed out) |
| 11:21:50 | *** | Saving seen data "./dancer.seen" |
| 11:40:23 | | Join ghode|afk [0] (n=garudin@host-212-158-193-204.bulldogdsl.com) |
| 11:44:36 | | Join lamed [0] (n=d4b3395e@labb.contactor.se) |
| 11:45:29 | _FireFly_ | what's going on with this cYmen guy |
| 11:46:42 | | Quit lamed (Client Quit) |
| 11:47:04 | ashridah | crappy isp, |
| 11:47:09 | | Join lamed [0] (n=d4b3395e@labb.contactor.se) |
| 11:47:33 | lamed | who is working to complete the new gui? |
| 11:48:32 | | Join Mxm`Pas`Bien [0] (n=flemmard@fbx.flemmard.net) |
| 11:49:09 | lamed | (gui_list) |
| 11:49:29 | _FireFly_ | what is with gui_list ?? |
| 11:49:45 | lamed | well, it' |
| 11:50:18 | lamed | it's not complete isn't it. it doesn't use it to show the playlist nor menus. and i guess that is being worked on. |
| 11:51:29 | _FireFly_ | gui_list widget itself is complete but not all gui elements use a widget like gui_list currently |
| 11:51:52 | _FireFly_ | i'm currently trying to dig into wps to create a wps-widget |
| 11:52:31 | _FireFly_ | lamed: do you use the latest cvs-version ?? |
| 11:52:51 | _FireFly_ | because the menus are also "ported" to the new gui-system |
| 11:53:34 | _FireFly_ | only showing and changing settings on the remote doesn't work currently but the menu's itself woks on the main-screen |
| 11:53:46 | lamed | it is indeed corrently missing. i can assume that every list will use the gui_list? like the menus? firefly - acctually no. I'm just asking a bunch of questions to make sure that my in progress patch is heading in the right direction |
| 11:54:16 | _FireFly_ | which patch ?? |
| 11:55:08 | lamed | (sssh... a seceret... it's working on my iriver but it's not totally done yet...) |
| 11:57:22 | lamed | do you think it is apropriate |
| 11:57:25 | lamed | sorry |
| 11:59:06 | | Join LinusN [0] (n=linus@labb.contactor.se) |
| 12:00 |
| 12:00:10 | | Join webguest82 [0] (n=3a4d5064@labb.contactor.se) |
| 12:00:21 | webguest82 | Is hard to connect by irc program. |
| 12:01:44 | | Quit ghode|afk (Read error: 110 (Connection timed out)) |
| 12:05:02 | | Quit Maxime (Read error: 110 (Connection timed out)) |
| 12:06:05 | amiconn | hi LinusN |
| 12:06:15 | LinusN | salut |
| 12:06:59 | linuxstb | Does anyone else get an illegal instruction error when unplugging usb on an iriver with the current cvs? |
| 12:07:11 | _FireFly_ | i will try |
| 12:08:06 | linuxstb | i.e. install the latest bleeding edge build, then reboot to run it, then enter USB mode, then leave USB mode |
| 12:08:20 | _FireFly_ | k |
| 12:08:49 | markun | webguest82: You are from korea, right? |
| 12:10:13 | lamed | devs, wil you object a patch tha adds LCD_PUTS_OFFSET & LCD_PUTS_SCROLL_OFFSET in all drivers for some specific usage?(and changes the old calls to one-line functions) I mean, nobody would mind if there are some more lcd functions right..? I know it sound really stupid question, but that is to be intended my first serious patch, and the other way i could do it (instead of making a new function and replacing older to macros) is to change lcd_puts & lc |
| 12:10:47 | _FireFly_ | linuxstb: i become I04: IllInstr at 00000002 |
| 12:10:57 | lamed | -inside the functions |
| 12:11:02 | webguest82 | markun: Yes |
| 12:11:04 | linuxstb | _FireFly_: Yes, that's what preglow and I found last night. |
| 12:11:42 | linuxstb | The most likely culprit is one of TiMiD's gui patches last night, but I haven't looked at the changes in detail. |
| 12:12:01 | _FireFly_ | maby in the text-widget |
| 12:12:06 | _FireFly_ | maybe |
| 12:12:07 | markun | webguest82: I looked in the logs and see you have a H3xx. If you had a H1xx I could build you a rockbox.zip with unicode and korean. |
| 12:13:28 | webguest82 | Because there is no money impatiently, can not buy H100. |
| 12:13:31 | webguest82 | :) |
| 12:13:36 | lamed | please try to answer my weird question.. it's important for my prograss |
| 12:14:16 | webguest82 | Thank if make. |
| 12:14:16 | LinusN | lamed: what would lcd_puts_offset() do? |
| 12:16:17 | _FireFly_ | linuxstb: or maybe it has something to do with the problem mentioned in this comment which i have found in some plugins |
| 12:16:25 | _FireFly_ | otherwise you will get lovely "I04: IllInstr" errors... :-) */ |
| 12:16:36 | _FireFly_ | otherwise you will get lovely "I04: IllInstr" errors... :-) */ |
| 12:16:36 | _FireFly_ | rb = api; |
| 12:16:47 | lamed | linusn: puts the text offseted. actually, it will pass the integer to lcd_puts_style_offset like it does now to lcd_puts_style, and there, instead of using lcd_putsxy it will use lcd_putsxyofs with that integer. |
| 12:17:00 | _FireFly_ | if you are using a global api pointer, don't forget to copy it! |
| 12:17:00 | _FireFly_ | otherwise you will get lovely "I04: IllInstr" errors... :-) |
| 12:17:06 | webguest82 | markun: Can you give now? |
| 12:17:31 | linuxstb | _FireFly_: No, I don't think this has anything to do with plugins. Same error, but I think a different reason. |
| 12:17:31 | markun | webguest82: I can, but what use is it if you don't have a H1xx? |
| 12:18:07 | linuxstb | TiMiD said that it only happens when dircache is enabled. |
| 12:18:16 | webguest82 | Can do. |
| 12:19:36 | webguest82 | How do you give? |
| 12:20:00 | lamed | linusn? |
| 12:20:29 | LinusN | lamed: should work, methinks |
| 12:22:45 | lamed | linusN: it does work.. i'm wondering if that might be accepted to the CVS? it's indeed needed (will be done porbebly this~next week |
| 12:22:47 | webguest82 | markun: Will you give? |
| 12:23:04 | markun | webguest82: ok, give me a few minutes |
| 12:23:21 | webguest82 | ok |
| 12:23:30 | LinusN | lamed: i can't say that it would be accepted, since you don't tell me what the rest of the patch does |
| 12:24:00 | lamed | :D thanks a lot for the answers |
| 12:24:52 | lamed | Gday all |
| 12:25:02 | | Quit lamed ("CGI:IRC") |
| 12:25:59 | | Join Febs [0] (n=cfac7a51@labb.contactor.se) |
| 12:26:55 | | Join Maxime [0] (n=flemmard@fbx.flemmard.net) |
| 12:31:23 | | Part LinusN |
| 12:34:47 | webguest82 | markun: %u3147o you use MSN messenger? |
| 12:34:59 | webguest82 | D |
| 12:35:18 | markun | webguest82: hirsxbergo@hotmail.com |
| 12:37:21 | _FireFly_ | linuxstb: i had just run a logf version of the build |
| 12:38:14 | _FireFly_ | and then i become a I00: failure and in the remote the last displayed call is "Building directory cache" |
| 12:39:08 | linuxstb | That seems to confirm what TiMiD said last night - that it's only a problem when dircache is enabled. |
| 12:39:26 | _FireFly_ | but what changes tricker this |
| 12:39:31 | linuxstb | It's probably just trying to access a null function pointer. |
| 12:40:06 | webguest82 | markun: Added. |
| 12:41:24 | | Quit Kohlrabi (Read error: 104 (Connection reset by peer)) |
| 12:44:00 | | Quit Mxm`Pas`Bien (Read error: 110 (Connection timed out)) |
| 12:51:53 | DMJC | anyone know what model of LCD screen the iriver has? |
| 12:51:57 | DMJC | IHP-140 |
| 12:52:04 | linuxstb | I don't understand why, but removing the call to "gui_textarea_clear(&screens[i]);" at the very end of apps/tree.c fixes the illegal instruction bug. |
| 12:52:08 | DMJC | model name etc, mate of mine is an electrical engineer |
| 12:52:23 | DMJC | he's looking at ordering the part/fixing the busted lcd screen for me |
| 12:52:42 | B4gder | http://www.rockbox.org/twiki/bin/view/Main/IriverHardwareComponents#The_LCD_module |
| 12:53:11 | amiconn | It seems that TiMiD's latest changes triggers this IllInstr exception after USB, but only on iriver and only if the dircache is enabled |
| 12:54:03 | amiconn | It looks to me like some uninitialised function pointer is called (derived from the address of the IllInstr) |
| 12:54:07 | linuxstb | amiconn: See my previous message. |
| 12:54:27 | linuxstb | (2 minutes ago) |
| 12:54:27 | amiconn | The question is why this pointer is only uninitialised when dircache is on |
| 12:55:05 | linuxstb | It's obvious now. |
| 12:55:18 | amiconn | Maybe it's not uninitialised in the first place, but gets overwritten somehow |
| 12:55:20 | linuxstb | It accesses screens[i] OUTSIDE the for loop. |
| 12:55:35 | linuxstb | i.e. screens[2] if NB_SCREENS is 2. |
| 12:56:01 | linuxstb | This is the tree_restore() function at the very end of tree.c |
| 12:56:30 | linuxstb | But I don't understand what that code is for in the first place. |
| 12:57:16 | amiconn | I think it's for removing the "rebuilding dircache.." info when the rebuild is done |
| 12:57:48 | amiconn | If so, then it should be in another for() loop |
| 12:57:50 | linuxstb | So we need a second for loop to iterate through the screens after the dircache is built? |
| 12:57:59 | _FireFly_ | yepp |
| 12:58:20 | _FireFly_ | or if it works remove it |
| 12:58:34 | _FireFly_ | if it works without explicitly clean the area |
| 12:58:36 | linuxstb | No, I think the correct solution is a second for loop. |
| 12:58:52 | linuxstb | Timid: You around? |
| 13:00 |
| 13:01:39 | linuxstb | Adding the second for loop works fine. Should I commit it? |
| 13:02:53 | _FireFly_ | why not i think this was a mistake from him |
| 13:04:33 | TiMiD | I'h here |
| 13:04:36 | TiMiD | reading the logs |
| 13:04:39 | _FireFly_ | :) |
| 13:05:40 | linuxstb | TiMiD: I've just committed a fix to the I04 error. |
| 13:05:43 | TiMiD | ok |
| 13:05:54 | linuxstb | We're pretty sure it's correct. |
| 13:06:18 | TiMiD | the problem was that it accessed screens[2] ? |
| 13:06:22 | _FireFly_ | yepp |
| 13:06:36 | linuxstb | Yes - accessing screens[i] OUTSIDE the for loop. So i would be equal to 2. |
| 13:06:53 | TiMiD | ouch |
| 13:06:58 | _FireFly_ | :) |
| 13:07:09 | _FireFly_ | a c'n'p error |
| 13:07:24 | _FireFly_ | i think |
| 13:07:29 | TiMiD | maybe I c'n'p at the wrong place :p |
| 13:07:44 | _FireFly_ | the place isn't worng at all :) |
| 13:07:45 | TiMiD | ouch :) |
| 13:07:50 | TiMiD | I see the error now :p |
| 13:07:54 | TiMiD | I forgot the loop :) |
| 13:08:05 | _FireFly_ | yepp and fixed in cvs |
| 13:08:32 | TiMiD | that's what happens when you are tired but still programming |
| 13:08:57 | TiMiD | _FireFly_: about your wps widget, there is gui_textarea that could be useful |
| 13:09:23 | TiMiD | (I changed the API a little, but it's more logical and easy that way) |
| 13:09:35 | TiMiD | Im' afk for 30mn |
| 13:10:15 | | Join amiconn_ [0] (n=jens@p54BD4E7D.dip.t-dialin.net) |
| 13:10:27 | | Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) |
| 13:11:41 | Moos | Hello all |
| 13:12:07 | markun | Hi Moos! |
| 13:14:25 | preglow | bloody gapless mp3 |
| 13:15:09 | | Quit webguest82 ("CGI:IRC (EOF)") |
| 13:20:47 | DMJC | anyone know where you can get a replacement lcd screen for iriver iho-140? |
| 13:20:50 | DMJC | ihp |
| 13:21:18 | B4gder | ebay |
| 13:21:28 | B4gder | it'll come attached to an iriver ;-) |
| 13:21:52 | DMJC | bah |
| 13:21:53 | *** | Saving seen data "./dancer.seen" |
| 13:22:01 | DMJC | should be able to do it much cheaper than that |
| 13:23:46 | B4gder | then do that |
| 13:24:32 | tvelocity | my ISP sucks cock |
| 13:24:36 | | Quit amiconn (Read error: 110 (Connection timed out)) |
| 13:24:37 | | Nick amiconn_ is now known as amiconn (n=jens@p54BD4E7D.dip.t-dialin.net) |
| 13:24:39 | tvelocity | i'd like you all to know that |
| 13:25:33 | preglow | for free? |
| 13:25:52 | DMJC | I need to know what the lcd display's part number is |
| 13:26:01 | DMJC | it's not made by iriver is it? |
| 13:26:05 | preglow | DMJC: i doubt it'll be easy to get that way |
| 13:26:13 | B4gder | DMJC: seen the URL I showed you? |
| 13:26:17 | DMJC | if I can get the part I can get it fixed |
| 13:26:23 | DMJC | saw the url on the website |
| 13:26:33 | B4gder | it mentions the specific epson model |
| 13:26:36 | DMJC | ah |
| 13:26:37 | DMJC | k |
| 13:26:43 | B4gder | Epson S1D15E06 |
| 13:27:02 | B4gder | which it most likely is |
| 13:28:06 | DMJC | thanks |
| 13:32:33 | DMJC | hmm |
| 13:32:45 | DMJC | someone's claimed that screen is also used on ipod |
| 13:34:21 | B4gder | http://ipodlinux.org/Generations |
| 13:34:54 | B4gder | the 4g ipod as an lcd with the same resolution |
| 13:34:57 | B4gder | has |
| 13:36:08 | | Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-130-062.pools.arcor-ip.net) |
| 13:36:28 | DMJC | hmm |
| 13:37:56 | DMJC | hmm so is the lcd different from the controller? |
| 13:38:04 | DMJC | the actual screen is cracked on mine |
| 13:38:09 | DMJC | that's what I'm looking to replace |
| 13:41:08 | | Join ghode|afk [0] (n=garudin@host-212-158-193-204.bulldogdsl.com) |
| 13:42:22 | | Quit ashridah ("sleep") |
| 13:44:33 | Ctcp | Ignored 5 channel CTCP requests in 5 minutes and 10 seconds at the last flood |
| 13:44:33 | * | B4gder feels good today |
| 13:44:46 | B4gder | BOINC converted to using libcurl |
| 13:56:00 | preglow | god, how i hate adsl |
| 13:58:24 | Zagor | beats modems :-) |
| 14:00 |
| 14:00:00 | preglow | depends on who's supplying |
| 14:00:11 | preglow | this connection is too moody for me |
| 14:00:29 | B4gder | that's not quite adsl's fault ;-) |
| 14:00:32 | | Quit ghode|afk (Read error: 110 (Connection timed out)) |
| 14:00:59 | preglow | oh, no, but the lousy upstream is, and that's another of my gripes |
| 14:01:02 | preglow | i want sdsl :/ |
| 14:01:15 | B4gder | vdsl is |
| 14:01:27 | preglow | but you need to pay through the nose for that here |
| 14:01:41 | Zagor | that's not adsl's fault either :-) |
| 14:01:44 | B4gder | and live above a "station" |
| 14:02:26 | Zagor | otoh you pesky norwegians will soon have bought most of our net infrastructure if you continue at the current pace :-) |
| 14:02:33 | | Quit Strath (Read error: 104 (Connection reset by peer)) |
| 14:02:40 | B4gder | btw, I learned that wimax won't be that fun as it sometimes is said to be |
| 14:02:58 | preglow | Zagor: hahaha |
| 14:08:54 | preglow | eXCELLENT!! |
| 14:09:02 | preglow | sent my h120 hurtling towards the ground |
| 14:09:13 | preglow | let's hope this marks the end of my rockbox involvment |
| 14:09:21 | B4gder | was it on? |
| 14:09:32 | preglow | no, and it starts just fine |
| 14:09:34 | preglow | pfew |
| 14:10:33 | preglow | i think the disk is designed to take quite a punch, as long as it isn't on |
| 14:10:52 | B4gder | yes, several Gs |
| 14:11:14 | B4gder | I remmber reading the number before, but I've forgot |
| 14:12:08 | Zagor | iirc, the disk is encased in a nice rubber holder on the iriver that should lower the Gs quite a bit |
| 14:12:14 | | Quit Sandking () |
| 14:13:41 | preglow | yes, assuming i replaced it properly :P |
| 14:14:19 | preglow | B4gder: more than several gs, i think it was something around 40 |
| 14:15:40 | | Join amiconn_ [0] (n=3e088e42@labb.contactor.se) |
| 14:16:37 | * | amiconn_ wonders what's going on with his home connection |
| 14:16:44 | markun | B4gder: I see you committed the iso8859-*.bdf fonts. Do you remember where you got them from? |
| 14:17:07 | B4gder | no, I believe they came in a patch or similar |
| 14:18:52 | markun | I am replacing fonts with their unicode parents. The iso8859 fonts are made from the GNU Unifont I think. |
| 14:21:28 | markun | I am replacing fonts with their unicode parents. The iso8859 fonts are made from the GNU Unifont I think. |
| 14:43:50 | | Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
| 14:53:36 | | Quit Febs ("CGI:IRC (Ping timeout)") |
| 14:54:09 | | Quit B4gder ("time to say moo") |
| 14:54:47 | _FireFly_ | TiMiD: to use the text_widget maybe also for wps was a suggestion which i had made to you yesterday :) |
| 14:59:36 | | Quit linuxstb (Read error: 110 (Connection timed out)) |
| 15:00 |
| 15:08:14 | TiMiD | ok |
| 15:08:53 | TiMiD | it doesn't really handles text anyway, just the area in which text can be typed |
| 15:09:05 | TiMiD | s/typed/displayed/ |
| 15:09:20 | _FireFly_ | yepp i saw it |
| 15:10:40 | _FireFly_ | the first problem which i have to solve is, to make a good data-structur for each wps |
| 15:11:25 | _FireFly_ | which all necessary information so that on the and only a draw_wps(<wps-struct> ) is needed to draw it :) |
| 15:11:49 | | Quit TiMiD (Remote closed the connection) |
| 15:21:11 | linuxstb_ | _FireFly_: Isn't that data structure just a copy of the WPS text file? |
| 15:21:56 | *** | Saving seen data "./dancer.seen" |
| 15:22:25 | | Join LinusN [0] (n=linus@labb.contactor.se) |
| 15:23:02 | | Join TiMiD[FD] [0] (n=TiMiD[FD@asgard.valombre.net) |
| 15:23:33 | | Quit TiMiD[FD] (Client Quit) |
| 15:23:41 | _FireFly_ | what about the images, the lines and sulines |
| 15:24:03 | _FireFly_ | which are currently separatly saved |
| 15:24:26 | _FireFly_ | in ram |
| 15:24:53 | preglow | hmm |
| 15:25:13 | preglow | when i've got "move to next folder enabled", audio buffering doesn't continue once the last track in the folder has been loaded |
| 15:25:16 | linuxstb_ | _FireFly_: True. I suppose you need to gather them all together into a struct. |
| 15:25:24 | preglow | is this a feature or a bug? |
| 15:25:38 | _FireFly_ | if i only save the format-buffer then i have to parse this buffer complete each time the screen is updated |
| 15:25:47 | linuxstb_ | preglow: I would say that's a bug. |
| 15:26:04 | linuxstb_ | _FireFly_: I thought that's how it worked now (but I could be wrong) |
| 15:26:08 | | Join TiMiD [0] (n=TiMiD@asgard.valombre.net) |
| 15:26:36 | linuxstb_ | _FireFly_: In fact just ignore me. I shouldn't talk about things I don't know anything about. |
| 15:26:50 | _FireFly_ | :) |
| 15:27:04 | LinusN | _FireFly_: linuxstb_ is basically right |
| 15:27:20 | linuxstb_ | I am? :) |
| 15:27:43 | LinusN | the wps file is parsed and split into sublines, and the images are loaded |
| 15:27:54 | _FireFly_ | i know |
| 15:28:06 | LinusN | but the %-codes are reformatted each time the wps updates |
| 15:30:11 | * | markun gets a bit tired of talking to a translator program.. |
| 15:30:11 | _FireFly_ | the only problem i currently see is how to manage the 2dim arrays for the lines because MAXLINES depends on the screen-size |
| 15:30:38 | | Join hshah [0] (n=545cb9e8@labb.contactor.se) |
| 15:30:55 | LinusN | _FireFly_: ah yes, you don't want the remote struct to be unnecessarily large? |
| 15:31:10 | _FireFly_ | if i can avoid it |
| 15:31:11 | _FireFly_ | yes |
| 15:31:13 | TiMiD | that would bea easy if we had malloc ... |
| 15:31:19 | _FireFly_ | yepp |
| 15:31:23 | LinusN | don't swear |
| 15:31:36 | LinusN | and we do have semi-dynamic memory |
| 15:32:04 | linuxstb_ | Can't you just index the arrays manually - i.e. a[y*width+x] |
| 15:32:18 | LinusN | buffer_alloc() |
| 15:32:47 | TiMiD | hmm so the wps aray would be initialized at the very beginning |
| 15:32:53 | LinusN | sure |
| 15:35:23 | _FireFly_ | a simple solution would be to have for each wps-struct the same size which will be the size from the largest display on the system |
| 15:36:09 | _FireFly_ | and have a additional var which has the actual max-lines which can be displayed on the display which is represented by the wps-struct |
| 15:36:11 | TiMiD | buffer_alloc is not a very complicated solution |
| 15:36:15 | LinusN | yes, or allocate the buffers with buffer_alloc() |
| 15:36:48 | TiMiD | _FireFly_: the var that represents tne number of lines that can be displayed is in the screen struct |
| 15:36:57 | TiMiD | nb_lines |
| 15:37:15 | TiMiD | you also have char_width and char_height |
| 15:38:12 | _FireFly_ | equals the value in this var this define: #define MAX_LINES (LCD_HEIGHT/5+1) ?? |
| 15:38:27 | LinusN | TiMiD: when are char_height/char_width updated? |
| 15:38:39 | TiMiD | LinusN: that's the good question :) |
| 15:39:10 | TiMiD | they are actually updated when a function needs them |
| 15:39:32 | TiMiD | when they are susceptible to change |
| 15:40:05 | TiMiD | but the most convenient thing would be IMHO to do that in the code that changes the font for example |
| 15:41:07 | | Join RiverFish [0] (n=d99b747d@labb.contactor.se) |
| 15:41:29 | | Join ghode|afk [0] (i=testing@host-212-158-193-204.bulldogdsl.com) |
| 15:41:48 | RiverFish | Someone mentioned here that some people think that RockBox sounds worse that iRiver firmware |
| 15:42:13 | RiverFish | Is there any likely reason for RockBox sounding different other than the different treble and boost behaviour |
| 15:42:27 | LinusN | well, we have different codecs |
| 15:42:55 | RiverFish | do the fixed point codecs produce the same output PCM as the reference floating point codecs? |
| 15:43:02 | preglow | RiverFish: no |
| 15:43:23 | preglow | RiverFish: every codec has sligthly different output |
| 15:43:42 | RiverFish | ok that's news to me |
| 15:43:54 | RiverFish | I'd that all codecs had to produce the same PCM to be compliant |
| 15:44:01 | preglow | not so |
| 15:44:04 | preglow | it has to be the same within a limit |
| 15:44:10 | RiverFish | ok |
| 15:44:15 | preglow | it depends on the codec |
| 15:44:21 | preglow | it is like this for mp3, at least |
| 15:44:28 | preglow | and other formally defined codecs |
| 15:44:40 | RiverFish | i mostly use vorbis and thinking of using musepack |
| 15:44:41 | LinusN | there are also different levels of compliance for mp3 |
| 15:45:06 | preglow | RiverFish: the iriver firmware might also be using 20 bit output |
| 15:45:29 | preglow | RiverFish: but anyway, i've personally decided to ignore these claims until i see hard proof (double blind tests) |
| 15:45:53 | preglow | shouldn't take long to conduct a proper test |
| 15:45:56 | Kohlrabi | I consider gapless playback much more important than slight subconscious differences :) |
| 15:46:04 | RiverFish | would comparing the SPDIF output from both firmwares work? |
| 15:46:17 | preglow | RiverFish: that would be the best approach currently, yes |
| 15:46:35 | preglow | LinusN: btw, did you notice what bit depth the spdif output from the iriver firmware had? |
| 15:46:51 | LinusN | no... |
| 15:47:19 | RiverFish | I'll do some tests if I can find some time |
| 15:50:21 | linuxstb_ | One possible difference is that Rockbox doesn't do any processing on the audio if you don't ask it to. We don't know if that's the case for the iriver firmware. |
| 15:50:57 | linuxstb_ | I read a complaint from someone saying that WAV sounded better than FLAC - the reason turned out to be winamp processing the audio differently in the two cases. |
| 15:52:05 | preglow | can't say i miss winamp |
| 15:52:07 | RiverFish | Rockbox not doing automatic processing without asking is a big IMO |
| 15:52:16 | RiverFish | big plus that is |
| 15:52:19 | preglow | guess who's using the web client ;) |
| 15:52:27 | Kohlrabi | *g* |
| 15:52:41 | _FireFly_ | ?? |
| 15:52:54 | linuxstb_ | +++ I'm not. |
| 15:53:32 | preglow | but anywho |
| 15:53:39 | preglow | lame headers are only found on mp3 files, yes? |
| 15:53:45 | preglow | so i can hard code the mp3 frame size |
| 15:54:16 | linuxstb_ | preglow: Are you talking about mp1/mp2 files? Or other formats completely? |
| 15:54:45 | preglow | i'm talking about lame headers only being found on mp3 files and not mp1/mp2, yes |
| 15:54:50 | preglow | basically anything handled by mpa.c |
| 15:55:13 | preglow | i'm trying to fix the large enc_delay problem |
| 15:55:22 | linuxstb_ | I can't think of a reason for people to encode their own mp2 files. They will normally be recordings from digital tv/radio broadcasts. In which case, there won't be any headers at all. |
| 15:55:45 | preglow | i prefer listening to mp2 files any day |
| 15:55:59 | preglow | so i might have wanted to do that instead of mp3, but i use vorbis ;) |
| 15:56:45 | preglow | forget it, i'll just assume i always see a layer 3 frame size and put in a warning for the people who know better than me |
| 15:56:50 | linuxstb_ | I would say assume it will only be layer 3 - you can always fix it in the future. |
| 15:57:38 | preglow | another problem is i don't have test files |
| 15:58:16 | preglow | that use such insanely high enc_delays, that is |
| 15:58:38 | RiverFish | preglow: suspect that iRiver firmware SPDIF output is 16 bit |
| 15:58:50 | preglow | RiverFish: do you have any idea of finding out? |
| 15:58:56 | preglow | s/idea/way/ |
| 15:58:57 | RiverFish | since it works with my cheap SoundBlaster http://www.soundblaster.com/products/MP3 / |
| 15:59:34 | preglow | i think i'll remove all these commented splash() functions from mpa.c |
| 16:00 |
| 16:00:26 | | Quit ghode|afk (Read error: 110 (Connection timed out)) |
| 16:01:47 | RiverFish | oops there I go again web clienting :) |
| 16:01:59 | RiverFish | mp3plus that should read |
| 16:03:55 | _FireFly_ | should i made the size of the format-buffer always be 1600bytes or should this size be selectable by the programmer which use this widget |
| 16:04:00 | RiverFish | preglow: is mp2 noticeably better. I've never tried it head to head with mp3 |
| 16:04:21 | preglow | RiverFish: i prefer the encoding artifacts of mp2 to those in mp3 |
| 16:04:56 | preglow | mp2 encoding artifacts sound more or less like those in musepack |
| 16:05:53 | RiverFish | on a brief listening musepack artifacts seem more natural and easier to live with |
| 16:06:20 | preglow | yes, exactly |
| 16:06:55 | preglow | subband codecs operate on much coarser frequency bands, and very seldom eliminate entire frequency bands |
| 16:07:02 | preglow | so you'll pretty much only get more noise here and there |
| 16:07:08 | preglow | not so with transform codecs |
| 16:07:26 | TiMiD | _FireFly_: I would rather use a fiexed value |
| 16:07:45 | TiMiD | 1600bytes should be enought for everyone : |
| 16:07:48 | TiMiD | :) |
| 16:07:53 | RiverFish | i find mp3 really tiring to listen to. vorbis is better but I'm interested in trying musepack seriously |
| 16:07:54 | | Part LinusN |
| 16:08:18 | _FireFly_ | k and the same for the Maximages(52) ?? |
| 16:10:13 | TiMiD | if you do it variable, it would need an additionnal entry in the config menu that is big enougth |
| 16:10:22 | TiMiD | but it's as you wish :) |
| 16:11:43 | markun | RiverFish: about differences in mp3 decoder output: http://www.underbit.com/resources/mpeg/audio/compliance/ |
| 16:12:24 | RiverFish | markun: thx |
| 16:15:21 | | Quit hshah ("CGI:IRC") |
| 16:30:49 | RiverFish | Can't see any discussion of allowed vorbis decoder differences in the spec http://xiph.org/vorbis/doc/Vorbis_I_spec.html |
| 16:31:05 | RiverFish | But there's some talk about the low and high accuracy modes of tremor |
| 16:33:42 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 16:34:37 | amiconn_ | preglow: Why do you need to assume a frame size? |
| 16:37:25 | amiconn_ | You can calculate the frame size from the header, rockbox already has a function to do that |
| 16:46:42 | preglow | think libmad has as well |
| 16:46:44 | preglow | btw |
| 16:46:53 | preglow | am i the only one having some problems with the lower watermark on the pcm buffer? |
| 16:46:57 | preglow | it never boosts now |
| 16:46:59 | preglow | so i get skips all the time |
| 16:47:38 | preglow | RiverFish: vorbis doesn't have any formal accuracy spec yet |
| 16:48:04 | preglow | RiverFish: the low and high accuracy modes of tremor is something different, we use high accuracy mode |
| 16:48:47 | RiverFish | preglow: yep just found // #define _LOW_ACCURACY_ commented out |
| 16:54:09 | linuxstb_ | preglow: Which codec (for your watermark problems) ? |
| 16:56:01 | | Quit RiverFish ("CGI:IRC") |
| 16:56:06 | preglow | linuxstb_: i tried both mp3 and vorbis |
| 16:56:23 | preglow | think i'll just try a daily to see if it's just me screwing up |
| 16:58:36 | linuxstb_ | Maybe that's the reason for my 24-bit WAV boosting. |
| 16:59:25 | linuxstb_ | Anyway, it works file with ALAC. Just trying some others. |
| 16:59:58 | linuxstb_ | MP2 is fine. |
| 17:00 |
| 17:00:59 | preglow | giving daily a try now |
| 17:01:03 | linuxstb_ | MP3 seems fine as well. |
| 17:01:38 | preglow | nope, daily works fine |
| 17:01:42 | preglow | i wonder how i managed to break this |
| 17:10:01 | preglow | hmm, could you try a debug build with logf enabled for me? that seems to trigger it here |
| 17:15:53 | linuxstb_ | Yep, I'll try it now. |
| 17:22:00 | *** | Saving seen data "./dancer.seen" |
| 17:23:01 | linuxstb_ | Yes, I'm getting the same problem. Very odd. |
| 17:23:22 | preglow | i've used debug builds often before, so it's a new problem |
| 17:24:18 | | Join Febs [0] (n=40be24f0@labb.contactor.se) |
| 17:26:30 | | Quit DMJC (Read error: 110 (Connection timed out)) |
| 17:35:11 | preglow | amiconn_: besides, i don't think you'll ever see a lame info header on anything but mp3 |
| 17:42:30 | | Join ghode|afk [0] (n=garudin@host-212-158-193-204.bulldogdsl.com) |
| 17:55:53 | | Join muesli_- [0] (i=muesli_t@Bc15e.b.pppool.de) |
| 17:57:14 | muesli_- | high |
| 18:00 |
| 18:04:02 | | Quit ghode|afk (Read error: 110 (Connection timed out)) |
| 18:04:11 | | Join Jue_ [0] (i=Jue@213.47.176.27) |
| 18:05:31 | Jue_ | hi |
| 18:07:42 | Jue_ | (in advance: sorry for my bad english) i have got some questions about the iriver H1xx-Rockbox. |
| 18:08:22 | preglow | shoot |
| 18:10:07 | Jue_ | thanks. As there are only to players that support FLAC (The H1xx with Rockbox and the X5) wich one should i choose. I heard many complaints about the x5-firmware and very good things about the soundquality of the H1xx-series. Am i right so far? |
| 18:10:36 | | Quit Paul_The_Nerd ("Chatzilla 0.9.68a [Firefox 1.0.7/20050915]") |
| 18:11:25 | preglow | as far as i know |
| 18:11:25 | Jue_ | I also heared, that the X5 does not support gapless replay. Will the a Rockbox-H1xx support gapless replay and replaygain with my Q8-Flac-files? |
| 18:11:35 | preglow | rockbox already does support gapless playbacj |
| 18:11:44 | preglow | and rockbox has a very efficient flac implementation |
| 18:12:04 | preglow | it SHOULD support gapless flac |
| 18:12:10 | preglow | as well as flac replaygain |
| 18:12:34 | preglow | give me a second, and i can verify the gapless part, at least |
| 18:12:49 | Jue_ | thank you very much. |
| 18:14:21 | preglow | just need to do some ripping and encoding, give me five minutes |
| 18:14:43 | Jue_ | no problem. ^^ |
| 18:14:55 | linuxstb_ | Yes, FLAC is definitely gapless. |
| 18:15:03 | preglow | there you have it, heh |
| 18:15:09 | Jue_ | and the replaygain-support? |
| 18:15:21 | preglow | i think we support replaygain for almost all our formats |
| 18:15:24 | linuxstb_ | I'm not sure. But if it's not there we can easily add it. |
| 18:15:59 | Jue_ | cool. |
| 18:16:19 | | Quit Febs ("CGI:IRC (EOF)") |
| 18:16:22 | preglow | and i'm pretty sure someone added replaygain support for flac |
| 18:17:01 | Jue_ | how much battery duration could i expect if i play Flac-q8-files without using the display often? |
| 18:17:30 | preglow | linuxstb_: god damn, wavpack is a fast encoder |
| 18:17:55 | linuxstb_ | Jue_: I don't know. I plan to do such a test soon. Maybe overnight tonight to see if it's still running in the morning. |
| 18:17:56 | preglow | linuxstb_: heaps faster than flac, and actually makes smaller files |
| 18:18:24 | linuxstb_ | preglow: Yes, I know the encoder is fast. But I didn't think the files were significantly smaller. |
| 18:18:42 | linuxstb_ | e.g. something like 30MB for Wavpack, 31MB for FLAC |
| 18:18:54 | preglow | linuxstb_: no, not very much, but they are consistently smaller |
| 18:19:26 | | Join Lear [0] (n=chatzill@h73n11c1o285.bredband.skanova.com) |
| 18:22:02 | Jue_ | hrm... another question: does Rockbox feature the display of individual vorbis comments? For example: I added Vorbis comments for "Mood" and "Rating". |
| 18:22:56 | linuxstb_ | I think someone has written a patch for that, but it's not been comitted to Rockbox CVS yet. |
| 18:23:37 | preglow | most definitely gapless |
| 18:24:27 | linuxstb_ | But I think I broke replaygain when I wrote the new FLAC decoder. |
| 18:24:56 | linuxstb_ | I think I just need to add the codec_set_replaygain(ci->id3) call back into flac.c |
| 18:25:07 | Jue_ | yeah. then it would be possible to sort them by rating and so on? When the H1xx's Soundquality is as good as i heared... this would be perfect. |
| 18:27:06 | linuxstb_ | Replaygain should now be working for FLAC again. Just committed it to CVS. |
| 18:28:08 | linuxstb_ | Jue_: No - Rockbox doesn't do anything with the tags - it just displays them. |
| 18:28:41 | preglow | i hate the way the seek bar skips back to where it was, before finally advancing to where it was when you seek |
| 18:28:56 | linuxstb_ | There is a "tag database" in development - that may be able to do what you want. But not many developers use it, and it doesn't seem to be developed very much. |
| 18:29:14 | Jue_ | would be great. A Flac-player with gapless replay, replaygain and individual vorbis comments (when will this patch be commited to the CVS?). great! |
| 18:29:48 | linuxstb_ | The patch will be committed when a developer with CVS access takes an interest in it. |
| 18:30:25 | Jue_ | oh. even without the database. this is really awesome. thanks, linuxstb! |
| 18:30:53 | linuxstb_ | preglow: I agree with you about the seek bar. |
| 18:30:55 | Lear | linuxstb_: btw, there was a reason for using rb as api pointer in wav.c, as you noticed... :) |
| 18:31:15 | linuxstb_ | Lear: Yes, but I don't think any of the codecs should be using "rb". |
| 18:31:15 | preglow | linuxstb_: i wonder if it is that way on archos as well |
| 18:31:52 | Lear | then I think codec.h should redefine DEBUGF/LOGF... |
| 18:32:04 | preglow | i think it should take the api ptr as an argument |
| 18:32:08 | preglow | LOGF(ci, "w00t"); |
| 18:33:05 | linuxstb_ | We could do it in codeclib.h - defining "ci" as an external variable. |
| 18:33:35 | linuxstb_ | I also want LOGF/DEBUGF inside the codec libraries, not just the main codec .c file. |
| 18:34:19 | linuxstb_ | Lear: Did you try playing 24-bit WAV files. I tried one yesterday, and it causes the CPU to boost more than Wavpack does when playing 24-bit files. |
| 18:34:28 | | Part Jue_ ("Verlassend") |
| 18:35:16 | Lear | linuxstb_: I think I did... Didn't check on CPU usage though. |
| 18:49:39 | | Join _aLF [0] (n=Alexandr@mut38-2-82-67-66-128.fbx.proxad.net) |
| 18:54:35 | preglow | none if you fellas got any mp3 files with a large enc_delay? |
| 18:56:57 | preglow | the wps is completely helpless for a series of small files |
| 19:00 |
| 19:05:13 | | Quit muesli_- (Read error: 110 (Connection timed out)) |
| 19:12:16 | Lear | but is that caused by enc_delay? doesn't similar things happen with oggs? (maybe you mean something different by helpless wps...) |
| 19:12:25 | | Quit amiconn_ ("CGI:IRC") |
| 19:12:39 | preglow | nonono, nothing to do with delay |
| 19:12:58 | preglow | it's got to do with the wps fucking up towards the end of all files |
| 19:13:28 | preglow | hmm, i need a mono mp3 |
| 19:19:42 | preglow | i'm still not entirely satisifed with the gapless |
| 19:19:51 | preglow | sounds like foobar still does a slightly better job |
| 19:22:04 | *** | Saving seen data "./dancer.seen" |
| 19:23:18 | Lear | but they do things pretty much in the same way... |
| 19:23:29 | Lear | biggest difference is the decoder. |
| 19:23:38 | preglow | Lear: you did the if (stop_skip > 0) part in mpa.c, yes? |
| 19:23:42 | preglow | i don't quite get why it's needed |
| 19:24:00 | Lear | yes, just looked at how foobar did it. :) |
| 19:24:15 | preglow | Lear: the lame header handling in mpa.c is similar to foobars because that's where i found out how it worked ;) |
| 19:25:03 | preglow | samplecount already does account for stop_skip |
| 19:25:06 | Lear | I kind of guessed that... |
| 19:25:07 | preglow | so i don't see why it needs to be done again |
| 19:27:09 | | Join tucoz [0] (n=81b17b04@labb.contactor.se) |
| 19:27:13 | Lear | but samplecount wasn't really used before, was it? |
| 19:27:23 | tucoz | Hi, what is the proper way of deleting wikispam? |
| 19:27:36 | tucoz | HanSolo has entered a few links in a clever way |
| 19:27:58 | preglow | Lear: perhaps :) |
| 19:28:34 | preglow | Lear: no, you most certainly seem to be right |
| 19:29:33 | tucoz | I mean, how do I revert a change to a previous version of the wiki page in question? |
| 19:29:34 | Lear | that's what made me look at it to start with... |
| 19:32:09 | preglow | it just needs to be adapted somewhat, though, framelength == 0 is no longer a breaking condition |
| 19:32:59 | preglow | i wonder if samplesdone is calculated properly when seeking |
| 19:33:19 | Lear | it is, as long as there's a stop_skip? |
| 19:34:14 | preglow | Lear: there are files with a start_trim big enough to encompass several frames |
| 19:34:26 | preglow | Lear: so the first couple of frames might end up with a framelength == 0 |
| 19:35:16 | preglow | lead_trim, whatever |
| 19:35:20 | tucoz | Zagor, Bagder: You need to delete HanSolo from the wiki, spammer. |
| 19:35:22 | Lear | how could that be? the file starts with short frames or what? |
| 19:35:41 | preglow | Lear: the first couple of frames might contain pure bitreservoir buildup |
| 19:36:05 | preglow | Lear: http://www.hydrogenaudio.org/forums/index.php?showtopic=35654 |
| 19:36:17 | Lear | true... |
| 19:37:34 | preglow | it's kind of a stretch, but i figured i might as well support it |
| 19:37:39 | preglow | i'll just remove the break condition |
| 19:39:08 | preglow | it would rather be better to break if samplesdone > samplecount |
| 19:39:13 | preglow | which is the case if max is negative |
| 19:39:38 | preglow | but then we'll break files with an incorrect frame number in the header |
| 19:42:00 | preglow | sobut those are broken now anyway by the same code, it seems |
| 19:55:01 | | Quit DangerousDan (Read error: 110 (Connection timed out)) |
| 19:59:02 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
| 20:00 |
| 20:05:13 | | Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
| 20:05:15 | | Join pengo [0] (n=xtofu@catv-50626042.catv.broadband.hu) |
| 20:07:19 | | Join ghode|afk [0] (i=testing@host-212-158-193-204.bulldogdsl.com) |
| 20:07:59 | | Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU) |
| 20:08:50 | | Quit tucoz ("CGI:IRC 0.5.4 (2004/01/29)") |
| 20:20:26 | | Quit linuxstb_ (Read error: 104 (Connection reset by peer)) |
| 20:21:00 | | Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
| 20:27:48 | | Quit ghode|afk (Read error: 110 (Connection timed out)) |
| 20:28:51 | | Quit dpassen1 (Read error: 110 (Connection timed out)) |
| 20:31:02 | | Join linuxstb__ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
| 20:31:29 | preglow | linuxstb__: yo, should i commit my sample conversion bypass thing even though it isn't exactly elegant? |
| 20:31:48 | preglow | i might not have time to work on rockbox for some days |
| 20:32:42 | linuxstb__ | Yes, commit it. I may have time to tidy it up a little. |
| 20:33:32 | | Join adiamas [0] (n=adiamas@12.109.187.84) |
| 20:33:34 | preglow | okies |
| 20:33:39 | preglow | it's just a little thing anyway |
| 20:34:57 | * | adiamas perks up |
| 20:36:49 | preglow | hmm |
| 20:37:21 | preglow | when i start passing 32 bit ints to pcmbuf_insert, shouldn't i do frameInfo.samples*4 and not frameInfo.samples*2 like in your 16 bit version? |
| 20:38:16 | preglow | i sorely wish slasheri would sanitize the argument format to that function |
| 20:38:27 | preglow | it just doesn't make sense as it is |
| 20:39:26 | preglow | haha, it's realtime if i increase it to *4 :PP |
| 20:39:30 | preglow | but with a nice time stretch |
| 20:39:44 | _FireFly_ | :) |
| 20:43:03 | pengo | i wish you could change the speed of audio (without changing the pitch) |
| 20:43:14 | pengo | podcasters talk too slowly |
| 20:43:57 | pengo | and most music is better when 12% faster |
| 20:44:11 | preglow | pengo: i'm going to fix that some day |
| 20:44:22 | pengo | preglow: i love you. |
| 20:44:24 | preglow | pengo: i could have done it right now since it's not very hard, but some quirks in rockbox makes it hard |
| 20:45:02 | preglow | linuxstb__: just be aware that this method might break for channels > 2 streams |
| 20:45:11 | preglow | since libfaad does some internal channel mapping |
| 20:45:38 | | Quit linuxstb_ (Read error: 110 (Connection timed out)) |
| 20:46:54 | preglow | linuxstb__: you wouldn't happen to have some isp troubles, would you? ;) |
| 20:47:58 | linuxstb__ | preglow: Yep. ADSL.... |
| 20:48:08 | | Nick linuxstb__ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
| 20:49:20 | linuxstb | preglow: As long as we add something like MAX_CHANNELS define (set to 2), I don't think it's a problem. |
| 20:50:52 | pengo | i wouldn't mind having 200ms (or 100ms) as an option for backlight fade in.. 500 is too long. |
| 20:52:25 | | Quit tvelocity ("Leaving") |
| 20:53:06 | preglow | pengo: you know, i agree |
| 20:57:56 | | Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
| 21:00 |
| 21:07:41 | | Join linuxstb__ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
| 21:13:38 | | Quit linuxstb (Read error: 110 (Connection timed out)) |
| 21:22:08 | *** | Saving seen data "./dancer.seen" |
| 21:23:17 | | Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU) |
| 21:24:11 | | Quit linuxstb_ (Read error: 110 (Connection timed out)) |
| 21:29:13 | | Quit _FireFly_ ("Leaving") |
| 21:30:00 | | Join RotAtoR [0] (n=e@12-210-82-91.client.insightBB.com) |
| 21:34:01 | | Join yngwi [0] (n=chatzill@chello080109107064.1.15.vie.surfer.at) |
| 21:35:14 | | Part yngwi |
| 21:37:24 | | Quit adiamas ("Chatzilla 0.9.68a [Firefox 1.0.7/20050915]") |
| 21:38:09 | | Join yngwi [0] (n=chatzill@chello080109107064.1.15.vie.surfer.at) |
| 21:38:53 | yngwi | #join irc.pathos.irc-mania.de |
| 21:38:56 | | Quit yngwi (Client Quit) |
| 21:39:30 | preglow | yes, very likely |
| 21:41:15 | | Join godzirra [0] (i=shawn@c-24-131-13-213.hsd1.va.comcast.net) |
| 21:41:30 | godzirra | Heya guys. Quick question... is there anyway to set rockbox to autoresume where it was before it turned off last? |
| 21:42:06 | crwl | yes |
| 21:42:36 | godzirra | Can you tell me how? :) |
| 21:42:36 | crwl | there's auto resume (or similar) in settings |
| 21:42:39 | preglow | you can always resume by pressing 'play' when you boot |
| 21:42:47 | preglow | after you boot, that is |
| 21:43:04 | godzirra | Hrm.. how do I get to settings on an iriver then? I've looked everywhere I can and I dont see autoresume. And I have a fairly new release of rockbox |
| 21:44:52 | crwl | it's behind the a/b button |
| 21:45:30 | godzirra | Hmm.. I get Shuffle Mode - Repeat Mode - and Show Files options when I try that. |
| 21:45:47 | dpassen1 | don't hold it down long |
| 21:45:55 | godzirra | Oh. |
| 21:45:56 | godzirra | duh |
| 21:46:09 | preglow | it's in general settings->playback->resume on startup |
| 21:46:26 | godzirra | Thanks very much :) |
| 21:46:31 | godzirra | I love rockbox. |
| 21:46:36 | preglow | you should ;) |
| 21:47:56 | godzirra | I do. i've been using it for about 4 months now. |
| 21:48:00 | godzirra | Its fantastic. |
| 21:54:15 | | Join LinusN [0] (n=linus@labb.contactor.se) |
| 22:00 |
| 22:00:47 | amiconn | preglow: The seek bar snap-back is an iriver-only glitch. On archos it's glitchless |
| 22:08:41 | | Join ghode|afk [0] (n=garudin@host-212-158-193-204.bulldogdsl.com) |
| 22:14:10 | preglow | amiconn: i suspected as much |
| 22:14:19 | amiconn | LinusN: Do you know whether the SDRAM controller should notice on-the-fly changes of the page mode bit in DACR0? I tried that in a test plugin measuring copy time with and without movem for various alignments, and didn't observe any speed change? |
| 22:15:20 | LinusN | i'm not sure, but i think it should work |
| 22:15:49 | amiconn | strange... |
| 22:29:42 | | Quit Kohlrabi (Nick collision from services.) |
| 22:29:46 | | Join Kohlriba [0] (n=Kohlrabi@dslb-082-083-130-062.pools.arcor-ip.net) |
| 22:30:06 | | Join len0x [0] (n=len0x@mobileweb08.london.02.net) |
| 22:50:42 | | Part len0x |
| 22:52:13 | | Join len0x [0] (n=len0x@mobileweb08.london.02.net) |
| 22:54:51 | | Join Midgey34 [0] (n=chatzill@c-67-172-68-52.hsd1.mi.comcast.net) |
| 23:00 |
| 23:00:37 | | Quit Lear ("Chatzilla 0.9.68.5.1 [Firefox 1.5/undefined]") |
| 23:01:09 | | Join DMJC-L [0] (n=DMJC-L@220-245-177-240-sa-pppoe.tpgi.com.au) |
| 23:04:21 | | Quit dpassen1 () |
| 23:20:48 | preglow | ok, we got a user on the forum saying seeking messes up the samplesdone, so it's as i thought |
| 23:21:04 | LinusN | saw that too |
| 23:22:10 | *** | Saving seen data "./dancer.seen" |
| 23:23:27 | preglow | i'll see if i can get proper gapless mp3 going some day soon |
| 23:25:51 | preglow | i should probably just mail the lame guy who has a page about this and ask him exactly how to do it |
| 23:26:17 | preglow | the foobar2000 mp3 plugin does some strange things including codec latency which i've tried to replicate, but don't understand completely |
| 23:26:37 | | Quit RotAtoR (Read error: 113 (No route to host)) |
| 23:27:29 | preglow | should also do some proper lame header parsing, what i put in there some time ago only qualifies as a hack |
| 23:33:23 | * | Bagder pokes on glibc with a stick |
| 23:33:40 | | Part pengo |
| 23:34:09 | | Join tucoz [0] (n=50ca6645@labb.contactor.se) |
| 23:34:27 | amiconn | LinusN: I had a look at the SDRAM init, and there are some points that don't look right to me... |
| 23:34:38 | LinusN | good |
| 23:35:01 | amiconn | It might not help to improve speed, but could you have a look as well? |
| 23:35:16 | LinusN | sure |
| 23:35:23 | tucoz | Hello, is there a reason to why wma is still listed as supperted in rockbox. Played one by mistake with somewhat of a failure. |
| 23:35:40 | preglow | tucoz: listed as supported where? |
| 23:35:42 | amiconn | First, firmware/crt0.S, line 194 and 196 |
| 23:35:45 | tucoz | In rockbox |
| 23:35:49 | LinusN | the only reason is to create playlists |
| 23:35:53 | preglow | tucoz: what linus said |
| 23:36:12 | Bagder | it isn't "supported" in any other way that it creates playlists with them |
| 23:36:13 | preglow | tucoz: you can rest assured that wma wont be supported in rockbox for a long, long time, if ever |
| 23:36:29 | amiconn | DCR is set to 0x8001 for h120, but to 0x8204 for h100. The low 9 bits are correct, that's the refresh cycle count |
| 23:37:15 | tucoz | Ah, get it. Thought I remember something like that. Still, isnt it a nice thing to simply remove that playlist functionality now that rockbox, well, rocks on the iriver. |
| 23:37:16 | amiconn | Bits 9 and 10 (RTIM) are what is fishy. For h120 it's 00, which means a tRC of 3 bus clocks |
| 23:38:03 | amiconn | 3 bus clocks are sufficient for 11 MHz and 45 MHz operation. For 124 MHz operation, one bus cycle is 16.1 ns, x3 is 48.3 ns |
| 23:38:14 | amiconn | Our SDRAM wants tRC >= 65 ns... |
| 23:38:19 | preglow | tucoz: i tend to agree |
| 23:38:32 | LinusN | amiconn: ouch |
| 23:38:32 | preglow | people can always just enable 'show all files' |
| 23:38:43 | amiconn | ...which means to set RTIM to 01 (6 bus clocks) for 124 MHz |
| 23:38:55 | Bagder | tucoz: people with WMA files could still build the playlists with rockbox and then reboot to play them... |
| 23:39:00 | tucoz | as these horrible wma files could be in a directory and rockbox will try to play them with unwanted results. |
| 23:39:18 | Bagder | rockbox should not play them "with unwanted results" |
| 23:39:21 | Bagder | that is the bug |
| 23:39:28 | LinusN | tucoz: rockbox should handle that much better |
| 23:39:31 | tucoz | Bagder: ok, fair enough. |
| 23:39:47 | LinusN | amiconn: sounds fair |
| 23:39:55 | amiconn | For h100 it's the reverse problem. RTIM is set to 10, which means tRC = 9 clks - a waste |
| 23:40:20 | LinusN | either we keep it at 6x, or make it dynamic |
| 23:40:27 | LinusN | i vote for 6x |
| 23:40:40 | tucoz | Bagder: btw, have you deleted HanSolo from the wiki? I deleted some massive spam from him earlier on, but wasn´t sure what to do with the user. |
| 23:40:46 | amiconn | I'd vote for making it dynamic. |
| 23:41:01 | amiconn | We already fiddle with DRC in set_cpu_frequency() anyway |
| 23:41:05 | amiconn | *DCR |
| 23:41:12 | LinusN | tucoz: i have personally deleted him twice |
| 23:41:21 | tucoz | LinusN: hehe |
| 23:41:34 | LinusN | amiconn: true |
| 23:41:36 | tucoz | ...well looks like he is back. |
| 23:42:18 | amiconn | LinusN: Next thing is the sequence of lines 229..238 in crt0.S |
| 23:42:40 | Bagder | hansolo removed |
| 23:43:12 | Bagder | again |
| 23:43:22 | tucoz | goodie, I googled for HanSolo and twiki and that gave a lot of hits. |
| 23:43:27 | Bagder | next time I'll start blocking his IP |
| 23:43:34 | preglow | how about doing it now! |
| 23:43:34 | amiconn | MCF5249UM.pdf p. 109 says that the init sequence requires to enable refresh first, then wait for at least 8 refresh cycles |
| 23:44:05 | amiconn | The code does it the other way round. It might be irrelevant if I read the Samsung datasheet correctly |
| 23:44:22 | len0x | guys, why do you run CVS on insecure pserver instead of a proper ssh? |
| 23:44:30 | LinusN | no it doesn't do it the other way around |
| 23:44:39 | preglow | because we're not afraid of password sniffing? :) |
| 23:44:46 | Bagder | len0x: because we're not afraid |
| 23:45:10 | LinusN | amiconn: it's only missing the 8-refresh wait |
| 23:45:11 | Bagder | it really is very little risk involved |
| 23:45:12 | amiconn | LinusN: The sequence in the code is precharge -> wait -> enable refresh -> MRS |
| 23:45:51 | LinusN | and the sequence in the data sheet is precharge -> wait ->enable refresh -> wait -> MRS |
| 23:46:17 | amiconn | Yes, but the first wait is so short that we don't need an instruction to cover it, at least not at 11 MHz |
| 23:46:20 | LinusN | "3. Issue a PALL command to the SDRAMs by setting DCR[IP] and accessing a SDRAM location. Wait the time (determined by tRP) before any other execution." |
| 23:46:33 | amiconn | Yeps. tRP is 20 ns .... |
| 23:46:38 | LinusN | haha |
| 23:47:02 | tucoz | I think it is time for me to say Hooray for rockbox. Cheers to all the developers :) |
| 23:47:32 | * | Bagder joins in the cheering |
| 23:48:00 | LinusN | amiconn: in any case, it takes quite a long time before the sdram is accessed after enabling the refresh |
| 23:48:18 | LinusN | but yes, we should fix that |
| 23:48:18 | amiconn | LinusN: Finally, lines 247..248 of crt0.S seem to be superfluous. Quote from the cf manual: "The DRAM controller clears IMRS after the MRS command finishes." |
| 23:48:21 | tucoz | I found myself looking through all the menus yesterday and found out just _how_ good it is. |
| 23:48:33 | * | preglow cheers loudly |
| 23:48:39 | amiconn | No need to clear ourselves... |
| 23:49:38 | amiconn | I'll try the dynamic RTIM. I won't try the bootloader changes myself without a BDM... |
| 23:50:06 | preglow | wimp! |
| 23:50:18 | LinusN | amiconn: file a patch, so i can fix it in the next bootloader version |
| 23:50:20 | tucoz | Btw, the ihpos-guy seem to make some progress with his hacking. http://ihpos.blogspot.com . |
| 23:51:58 | preglow | tucoz: persistent fellow |
| 23:52:17 | amiconn | LinusN: For proper wait fixing, how do you interpret the 8 refreshes we have to wait? Is that 8 full 8192-cycles (64 ms each), or simply 8 single refreshes? |
| 23:52:18 | Bagder | reinventing the wheel big time |
| 23:52:31 | tucoz | Bagder: haha |
| 23:52:32 | LinusN | indeed, and where is the source? |
| 23:53:36 | amiconn | Samsung says "issue 2 or more auto-refresh commands". I think that means 2 or more single refreshes (8 to play safe) |
| 23:53:37 | LinusN | amiconn: i interpret it as 8 single refreshes |
| 23:53:49 | preglow | oh well, he's probably having a blast |
| 23:53:58 | Bagder | certainly |
| 23:53:58 | preglow | someone mail him and tell him to join us :) |
| 23:54:05 | Bagder | but he mentions having problems to find info |
| 23:54:10 | Bagder | info we have since long |
| 23:54:15 | preglow | well, he knows about us |
| 23:54:17 | preglow | he's using our bootloader |
| 23:54:25 | Bagder | yes |
| 23:54:32 | Bagder | he's on a solo raid for sure |
| 23:54:43 | tucoz | probably, he said in a comment that he is thinking of that, and that he uses this as a learning experience. |
| 23:54:44 | amiconn | LinusN: So our loop can be somewhat shorter. 8 refreshes means 8*32 bus cycles for h120, and 8*80 bus cycles for h100 |
| 23:54:46 | | Quit DangerousDan (Read error: 104 (Connection reset by peer)) |
| 23:55:06 | Bagder | not everyone is a team player |
| 23:55:20 | LinusN | apparently not this guy |
| 23:56:32 | tucoz | well, seems like he could be. http://www.blogger.com/comment.g?blogID=17048932&postID=112994985131055021 |
| 23:57:29 | | Join Strath [0] (n=mike@dpc674681214.direcpc.com) |
| 23:57:55 | preglow | well, i get what he's doing very well, he's probably learning a bunch |
| 23:58:00 | linuxstb__ | Someone let him loose on a H340 |
| 23:58:06 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
| 23:58:18 | Bagder | hehe |
| 23:58:22 | Bagder | now there's an idea |
icon identifies that the person is a core developer (has commit access).