| 00:00:02 | | Quit _FireFly_ ("Leaving") |
| 00:01:01 | solexx | i hope so. :) |
| 00:04:28 | linuxstb | I've been playing a little with AAC - my current (non-working) aac.codec is over 1MB in size... Hopefully I'm doing something very wrong. |
| 00:05:47 | Bagder | that's usually an lds problem |
| 00:06:02 | Bagder | with something starting at address 0 |
| 00:07:52 | linuxstb | Well, the libfaad.a is 1.8MB |
| 00:08:03 | Bagder | oh |
| 00:09:47 | linuxstb | These are builds for the sim by the way. |
| 00:10:13 | linuxstb | Stripping libfaad.a takes it down to 270956 bytes. |
| 00:10:27 | Bagder | ok |
| 00:20:06 | *** | Saving seen data "./dancer.seen" |
| 00:31:24 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
| 00:37:48 | | Join MacDancer [0] (n=MacDance@adsl-69-109-189-106.dsl.pltn13.pacbell.net) |
| 00:38:01 | MacDancer | Hallo, all |
| 00:39:11 | MacDancer | I've a quick question that I haven't been able to find the answer to in the documentation so far... |
| 00:39:42 | MacDancer | I can't find the playback pitch/speed adjustment option anywhere, and I, unlike most people, could actually use it |
| 00:40:01 | MacDancer | Could someone give me directions? :\ |
| 00:49:06 | solexx | i don't think rockbox has this feature (at least not on iriver) |
| 00:49:17 | solexx | but i might be wrong |
| 00:50:39 | MacDancer | It's listed in the manual for the Archos players, but of course there isn't one for the iRiver port, so... |
| 00:51:20 | phaedrus961 | MacDancer: press on+up or on+down in the wps |
| 00:51:20 | * | solexx could have sworn he saw a light coming on |
| 00:51:32 | linuxstb | It's only implemented on the Archos, NOT the iriver at the moment. |
| 00:51:42 | MacDancer | Ah, that'll be it then |
| 00:51:52 | MacDancer | Thanks |
| 00:51:55 | phaedrus961 | np |
| 00:58:04 | | Quit MacDancer ("Leaving") |
| 01:00 |
| 01:12:12 | TiMiD | RotAtoR: still pbls with your plugin ? |
| 01:15:12 | phaedrus961 | TiMiD: something in your latest commit broke the buttonbar |
| 01:15:35 | TiMiD | oh ? |
| 01:15:41 | TiMiD | I test on sim |
| 01:15:58 | TiMiD | I have also the copyright to handle |
| 01:16:00 | phaedrus961 | if I scroll up or down in the filetree it disappears |
| 01:16:09 | TiMiD | erf |
| 01:16:55 | TiMiD | I build sim for archos |
| 01:17:36 | | Quit DangerousDan (Read error: 104 (Connection reset by peer)) |
| 01:20:12 | RotAtoR | TiMiD: yes |
| 01:20:54 | TiMiD | RotAtoR: did you tried without the font change |
| 01:21:08 | RotAtoR | yes, still no change :/ |
| 01:21:13 | TiMiD | (it will be ugly, but just to be sure the pbl isn't here) |
| 01:22:10 | RotAtoR | it's stange, i have an opening description screen with text that works fine |
| 01:22:40 | RotAtoR | it works to draw lines and rect all over the text there |
| 01:23:04 | RotAtoR | but for some reason, all but the text appears when in the main program loop |
| 01:23:18 | TiMiD | I didn't looked at your code too much (I catch a flew) but try to remove all the other drawing code excepted the update |
| 01:23:38 | RotAtoR | i did that too, the text still doesn't draw... |
| 01:23:59 | RotAtoR | it's aggravating >:( |
| 01:26:08 | TiMiD | test w/o lcd_set_drawmode |
| 01:26:36 | RotAtoR | ok, i'll look into that |
| 01:33:45 | RotAtoR | *sigh*, this is ridiculous, I just commented out all code that does anything with the lcd except for the text I want, and still nothing |
| 01:34:42 | RotAtoR | but it still works great in the sim ;) |
| 01:34:49 | TiMiD | you must at least have update |
| 01:35:13 | RotAtoR | well, yes, one update at the end |
| 01:36:40 | | Join whatboutbob [0] (n=cbd60b37@labb.contactor.se) |
| 01:37:55 | whatboutbob | timid: I'm getting the same issue as phaedrus961 |
| 01:38:28 | TiMiD | whatboutbob: I'm investigating it |
| 01:38:33 | RotAtoR | well, have to get going... will try more debugging later |
| 01:38:36 | TiMiD | (well I opened the source code :) ) |
| 01:38:46 | whatboutbob | doesn't happen when the remote's not plugged in. |
| 01:38:46 | | Nick RotAtoR is now known as RotAtoR|afk (n=e@12-210-82-91.client.insightBB.com) |
| 01:39:02 | TiMiD | whatboutbob: uh ? |
| 01:39:04 | whatboutbob | sorry..don't mean to bug you about it...and not complaining at all...just thought you'd like to know. |
| 01:39:15 | TiMiD | I like to know yes :) |
| 01:40:11 | TiMiD | I'm glad to say I can reproduce the bug on simulator :) |
| 01:40:14 | whatboutbob | timid: yeah, when the remote's not plugged in everything works fine. as soon as i plug the remote in usually within a few seconds of me browsing the filetree (with remote or main unit) the screen disappears |
| 01:41:20 | whatboutbob | timid: arch...scratch that. happens without remote plugged in. just didn't wait long enough it seems. |
| 01:47:41 | whatboutbob | just to ensure we're talking about the same bug, i'll be in the filetree, click right, the unit will have a little think, then the cursor will jump to the top of the filetree, then a few seconds later the screen will go blank. |
| 01:48:13 | TiMiD | the whole screen ? |
| 01:48:20 | whatboutbob | yup |
| 01:48:27 | TiMiD | on the sim I only see button bar which disepear |
| 01:50:29 | phaedrus961 | only the button bar disappears for me too |
| 01:50:50 | Moos | in the target? |
| 01:50:50 | whatboutbob | oh, ok, something weird going on with just me then it sees... |
| 01:51:04 | phaedrus961 | target and sim |
| 01:51:56 | whatboutbob | actually...i've just plugged the remote back in. when i play a song the remote stays in filetree mode while the unit goes to the wps. is that right? |
| 01:52:27 | TiMiD | I've a clue (maybe) |
| 01:52:40 | | Join thegeek [0] (n=thegeek@s115b.studby.ntnu.no) |
| 01:54:40 | TiMiD | whatboutbob: that's a normal behaviour |
| 01:54:40 | | Quit dpassen1 () |
| 01:54:41 | Moos | whatboutbob: bug for irivers? |
| 01:55:01 | Moos | ah :) |
| 01:55:09 | TiMiD | whatboutbob: the remote just doesn't clear the display when going to wps, and since wps is not implemented on remote .... |
| 01:56:02 | TiMiD | the remoite support is not full and even if I'm working on it I only have few time |
| 01:56:18 | Moos | hopefully that'll coming soon, hein TiMiD :) |
| 01:56:21 | whatboutbob | ahhh...hokay...i'll shuddup and sit quietly in the corner for a while then. :) |
| 01:57:02 | Moos | :D |
| 01:57:51 | TiMiD | yes if the users stops complaining about bugs :) |
| 01:58:00 | Moos | XD |
| 01:58:23 | TiMiD | (well it's only the second and it's not lethal so it's pretty good :p) |
| 01:58:42 | Moos | hehe |
| 02:00 |
| 02:10:45 | | Join Metuk [0] (n=5299eea1@labb.contactor.se) |
| 02:12:21 | | Quit Metuk (Client Quit) |
| 02:20:08 | *** | Saving seen data "./dancer.seen" |
| 02:21:18 | | Quit cYmen__ ("zZz") |
| 02:33:25 | | Quit Kohlriba ("Leaving") |
| 02:52:37 | | Join ashridah [0] (i=ashridah@220-253-121-184.VIC.netspace.net.au) |
| 02:16:08 | | Quit Moos ("Glory to Rockbox") |
| 02:22:32 | | Join actionshrimp [0] (i=dave@dhcp-163-1-214-173.seh.ox.ac.uk) |
| 02:57:19 | | Quit actionshrimp ("a bird in the bush is worth two in your house") |
| 03:00 |
| 03:20:10 | *** | Saving seen data "./dancer.seen" |
| 04:00 |
| 04:04:20 | | Quit RotAtoR|afk () |
| 05:00 |
| 05:14:59 | | Nick ashridah is now known as Lost-ash (i=ashridah@220-253-121-184.VIC.netspace.net.au) |
| 05:20:15 | *** | Saving seen data "./dancer.seen" |
| 06:00 |
| 06:33:24 | | Quit whatboutbob ("CGI:IRC (EOF)") |
| 07:00 |
| 07:20:17 | *** | Saving seen data "./dancer.seen" |
| 07:58:31 | | Join ashridah__ [0] (i=ashridah@220-253-123-36.VIC.netspace.net.au) |
| 07:58:55 | | Nick ashridah__ is now known as ashridah (i=ashridah@220-253-123-36.VIC.netspace.net.au) |
| 07:59:03 | | Quit Lost-ash (Nick collision from services.) |
| 07:59:23 | | Nick ashridah is now known as Lost-ash (i=ashridah@220-253-123-36.VIC.netspace.net.au) |
| 08:00 |
| 08:14:29 | | Join solexx_ [0] (n=jrschulz@c187101.adsl.hansenet.de) |
| 08:26:02 | | Quit solexx (Read error: 110 (Connection timed out)) |
| 09:00 |
| 09:20:20 | *** | Saving seen data "./dancer.seen" |
| 09:34:37 | | Join linuxstb_ [0] (n=5343d4aa@labb.contactor.se) |
| 09:37:40 | | Quit linuxstb_ (Client Quit) |
| 09:44:27 | | Join Musicmad [0] (n=Musicmad@port547.ds1-oebr.adsl.cybercity.dk) |
| 09:44:43 | | Quit Musicmad (Client Quit) |
| 10:00 |
| 10:11:40 | | Join ender` [0] (i=ychat@84.52.165.220) |
| 10:11:58 | linuxstb | Slasheri: There is a problem with your FLAC commit. |
| 10:12:37 | linuxstb | The FLAC decoder required an entire frame (or more) to be passed to the decode_frame function. But on the buffer wraparound point, the buffer will point to a partial frame. |
| 10:13:03 | linuxstb | That's why I didn't use the request_buffer function - I don't think it's possible to use it due to that issue. |
| 10:14:43 | Slasher | linuxstb: no |
| 10:15:01 | Slasher | playback engine guarantees it will not be partial |
| 10:15:35 | linuxstb | But I am now getting crashes in the FLAC codec. |
| 10:15:47 | linuxstb | Have you tried playing an album of FLAC tracks? |
| 10:15:50 | Slasher | At least if the MAX_FRAMESIZE is smaller than GUARD_BUFSIZE in playback.c |
| 10:15:58 | Slasher | Hmm, not yet.. I will try soon :) |
| 10:16:28 | linuxstb | I also hit the same problem with my ALAC decoder - see the code in there that either does a request_buffer or read. Without that, the codec crashes at the wraparound point. |
| 10:16:41 | Slasher | Hmm, interesting |
| 10:16:54 | linuxstb | How big is GUARD_BUFSIZE? |
| 10:17:30 | Slasher | MAX_FRAMESIZE 32768 |
| 10:17:48 | Slasher | GUARD_BUFSIZE (8*1024) |
| 10:17:54 | Slasher | ok, the guard buffer is too small |
| 10:17:58 | Slasher | Try increasing it :) |
| 10:18:05 | Slasher | Then it should no longer crash |
| 10:19:47 | linuxstb | Yes, FLAC frames are typically up to about 13KB. But can be bigger |
| 10:20:40 | Slasher | I think 32*1024 could be a good value then |
| 10:20:48 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
| 10:21:16 | Slasher | That would be the worst case |
| 10:22:25 | | Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-130-062.pools.arcor-ip.net) |
| 10:23:29 | linuxstb | Also, does the request_buffer function return 0 at the end of the file? |
| 10:24:08 | Slasher | linuxstb: Yes, it returns NULL and sets the buffer size to 0 |
| 10:24:39 | linuxstb | Did you manage to look at the crashing FLAC file? |
| 10:24:51 | Slasher | linuxstb: Yep, i fixed that :) |
| 10:25:03 | linuxstb | How? |
| 10:25:15 | Slasher | It was a caused by a missing semaphores in the playback engine |
| 10:25:21 | Slasher | just look at the latest two commits |
| 10:25:34 | linuxstb | Sorry, I missed that commit. Thanks for fixing :) |
| 10:25:39 | Slasher | :) |
| 10:26:08 | linuxstb | I've got to go now. Can you increase GUARD_BUFSIZE? |
| 10:26:16 | Slasher | ok, i will do that :) cu |
| 10:26:21 | linuxstb | bye. |
| 10:26:25 | linuxstb | Thanks. |
| 10:26:28 | Slasher | np :) |
| 10:35:44 | | Join Lear [0] (n=chatzill@h73n11c1o285.bredband.skanova.com) |
| 10:42:54 | | Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 10:54:19 | | Join Quelsaruk [0] (n=kvirc@80-103-103-117.mad1.adsl.uni2.es) |
| 10:54:24 | Quelsaruk | good morning |
| 11:00 |
| 11:07:20 | markun | morning Quelsaruk |
| 11:20:21 | *** | Saving seen data "./dancer.seen" |
| 11:22:00 | | Quit Kohlrabi ("Leaving") |
| 11:23:48 | | Quit Lear (Excess Flood) |
| 11:31:26 | | Nick Lost-ash is now known as ashridah (i=ashridah@220-253-123-36.VIC.netspace.net.au) |
| 11:52:15 | | Join actionshrimp [0] (i=dave@dhcp-163-1-214-173.seh.ox.ac.uk) |
| 11:53:16 | | Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-130-062.pools.arcor-ip.net) |
| 12:00 |
| 12:05:39 | | Join Lear [0] (n=chatzill@h73n11c1o285.bredband.skanova.com) |
| 12:08:45 | | Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) |
| 12:11:56 | linuxstb | Slasher: Are you still around? |
| 12:17:48 | Slasher | linuxstb: yes |
| 12:18:27 | linuxstb | I've been working on an AAC decoder, so we've now hit the problem of two codecs using the same extension (m4a). |
| 12:18:45 | Slasher | Ah, hmm |
| 12:19:19 | Slasher | I think we could probe the file format using the metadata instead of file extension only |
| 12:19:23 | linuxstb | My idea was to ensure that we always call get_metadata() before we load the relevant codec, and allow get_metadata() to change the codec type of the file after it analyses it. |
| 12:19:32 | Slasher | That would require some modifications to the probe_file_format function at least |
| 12:19:44 | Slasher | Hmm, that sounds good |
| 12:20:57 | linuxstb | I don't think playback.c should call probe_file_format() - just get_metadata(). |
| 12:21:14 | linuxstb | Or the other way around. i.e. just one function. |
| 12:21:26 | Slasher | true |
| 12:22:31 | Lear | Something unrelated: what is the purpose of the guard buffer? |
| 12:22:35 | linuxstb | Would you have time to make those changes to playback.c? I still don't understand it well enough. We need to be careful to only call it when the disk is spinning - i.e. just before we load the file (or codec) into the buffer. |
| 12:23:07 | linuxstb | Lear: It's to handle the case of a codec requesting a pointer to N bytes of data from the codec buffer, but the codec buffer being at the wraparound point. |
| 12:23:07 | Slasher | Lear: It will prevent passing partial buffer data to the codecs when the main file buffer wraps |
| 12:24:24 | linuxstb | i.e. the request_buffer() function is guaranteed to return either GUARD_BUFSIZE bytes or the number of bytes remaining in the file, whichever is larger. |
| 13:00 |
| 13:20:24 | *** | Saving seen data "./dancer.seen" |
| 13:59:03 | | Quit ashridah ("Leaving") |
| 13:59:17 | | Join ashridah [0] (i=ashridah@220-253-123-36.VIC.netspace.net.au) |
| 14:00 |
| 14:01:44 | | Join muesli- [0] (i=muesli_t@hmln-d9b8ef46.pool.mediaWays.net) |
| 14:01:54 | muesli- | reee |
| 14:04:11 | | Join thegeek_ [0] (n=thegeek@s115b.studby.ntnu.no) |
| 14:11:53 | | Quit Kohlrabi (Read error: 104 (Connection reset by peer)) |
| 14:12:16 | | Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-130-062.pools.arcor-ip.net) |
| 14:19:54 | | Quit thegeek (Read error: 110 (Connection timed out)) |
| 14:40:44 | | Quit ashridah ("Leaving") |
| 14:44:56 | phaedrus961 | hey all, I've just submitted a patch for convbdf to fix two problems: 1) fonts wider than 16 pixels are now converted correctly. 2) the offset table was always written, even when unneeded. |
| 14:45:08 | phaedrus961 | it can be found here: http://sourceforge.net/tracker/index.php?func=detail&aid=1342470&group_id=44306&atid=439120 |
| 15:00 |
| 15:06:14 | markun | thanks phaedrus961 |
| 15:20:26 | *** | Saving seen data "./dancer.seen" |
| 15:30:29 | | Quit DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 15:31:11 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
| 15:36:04 | | Quit Lear ("Chatzilla 0.9.68.5.1 [Firefox 1.5/undefined]") |
| 16:00 |
| 16:08:01 | | Join preglow [0] (n=thomjoha@hekta.edt.aft.hist.no) |
| 16:08:06 | preglow | woot |
| 16:08:15 | linuxstb | woot? |
| 16:08:37 | preglow | flac issue solved |
| 16:09:18 | linuxstb | Yep. It was a playback.c problem all along. Hopefully that will increase playback reliability in general. |
| 16:09:36 | preglow | yup |
| 16:10:32 | linuxstb | His patch to use request_buffer() instead of read() is also useful. As you probably read in the logs - I didn't fully understand how the buffering worked. |
| 16:10:48 | linuxstb | But it means FLAC uses 32KB less RAM. |
| 16:11:20 | preglow | flac has gotten really bloody lightweight |
| 16:11:30 | linuxstb | There's nothing left of it... |
| 16:11:49 | linuxstb | But don't worry, I've been trying to get libfaad2 working - that library makes libFLAC look streamlined. |
| 16:11:55 | preglow | hahah |
| 16:12:01 | preglow | yeah, i had a look at it |
| 16:12:03 | linuxstb | It is also malloc hell. |
| 16:12:22 | linuxstb | Using malloc for buffers 2 bytes long... |
| 16:12:25 | preglow | hahahhaha |
| 16:12:27 | preglow | good god |
| 16:12:33 | preglow | i wonder what the helix decoder looks like |
| 16:12:45 | linuxstb | We're not allowed to look - license issues :( |
| 16:12:56 | preglow | oh, i know that |
| 16:13:00 | preglow | just wondering |
| 16:13:23 | linuxstb | I'm curious too. |
| 16:13:45 | linuxstb | I think it will be a case of stripping down and rewriting parts of libfaad2. But it needs someone who understands AAC, or who wants to understand it. |
| 16:14:35 | merbanan | linuxstb: well first you need a fixedpoint mdct, do you have one of those ? |
| 16:15:13 | preglow | i think id like to study aac |
| 16:15:29 | preglow | we have got several of those |
| 16:15:35 | linuxstb | merbanan: I'm using libfaad2 in fixed point mode, so I assume it has one. |
| 16:15:42 | preglow | tremors got one, faads got one, a52 has got one |
| 16:16:32 | merbanan | hmm, last time I checked it didn't have one |
| 16:16:40 | merbanan | or did I check ??? |
| 16:16:45 | preglow | well |
| 16:16:47 | preglow | it does have one |
| 16:16:50 | preglow | im pretty certain of that |
| 16:17:02 | linuxstb | I think all the high-level code is working OK - parsing the m4a stream, extracting the codec data from the m4a header and using it to initialise libfaad2. Even seeking works. |
| 16:17:18 | linuxstb | It's working fairly reliably in the sim, but crashes on the target. |
| 16:17:31 | merbanan | linuxstb: what speed? |
| 16:17:52 | linuxstb | I don't know yet, it crashes on the sim before I get to hear anything. |
| 16:17:57 | linuxstb | I mean on the target. |
| 16:18:04 | preglow | oh? |
| 16:18:11 | linuxstb | But I imagine it's going to be very very slow. |
| 16:18:13 | preglow | didnt libfaad trigger tons of compiler bugs? |
| 16:18:39 | * | preglow looks forward to do some optimising |
| 16:18:56 | linuxstb | Not that many. I worked around them by changing some variables from signed to unsigned (or other way around). The diffs to the standard libfaad2 are tiny. |
| 16:19:05 | preglow | good |
| 16:19:19 | linuxstb | When it comes to putting it in CVS, I'll commit the clean libfaad2 first, then my workarounds. |
| 16:19:34 | linuxstb | There are also a ton of compiler warnings. Mainly about using char as an array subscript. |
| 16:20:33 | preglow | nice |
| 16:20:49 | preglow | i wonder what the odds of the codecs getting even more iram are :> |
| 16:21:12 | preglow | it certainly appears to be the single most important optimising point there is |
| 16:21:39 | linuxstb | Don't forget your DSP code will need IRAM as well. |
| 16:21:46 | preglow | not much |
| 16:21:57 | preglow | very little, as a matter of fact |
| 16:22:31 | preglow | we should really work to keep the main buffers of the codecs in iram during all the processing |
| 16:22:38 | preglow | thatll boost performance no end |
| 16:22:59 | preglow | excuse the total lack of apostrophes, i hate laptop keyboards |
| 16:23:08 | linuxstb | I assume you just mean the output buffer. I don't think putting the input buffer in IRAM helps much. |
| 16:23:16 | linuxstb | But I guess it depends on the codec. |
| 16:24:26 | preglow | i mean the output, yes |
| 16:24:47 | preglow | the output buffer will be traversed tons of times if we do some dsp |
| 16:26:27 | linuxstb | Do you think it will be possible to remove mallocs completely? I think alac has one (for the metadata), but I'll try and remove it. |
| 16:26:51 | linuxstb | FLAC is now completely static. I think liba52 is as well. |
| 16:27:42 | preglow | completely, sure |
| 16:27:48 | preglow | as long as were willing to set some max limits |
| 16:28:02 | preglow | btw, i think you can safely delete libflac now |
| 16:29:37 | linuxstb | OK, I'll do it later. |
| 16:31:33 | preglow | i hope to never see it again |
| 16:32:28 | merbanan | linuxstb: what speed? |
| 16:32:32 | merbanan | nm |
| 16:33:08 | merbanan | linuxstb: did you write your own implementations for the fft macros ? |
| 16:33:41 | linuxstb | No. I haven't touched anything inside the libraries. They all have their own implementations. |
| 16:35:13 | preglow | you cant very well use a common fft or mdct routine |
| 16:35:32 | preglow | everthing uses its own fixed point format |
| 16:35:39 | preglow | and in some cases you can optimise for certain block sizes |
| 16:35:39 | linuxstb | I've uploaded my current AAC source tree here: http://www.davechapman.f2s.com/rockbox/rockbox-aac.tgz |
| 16:36:12 | linuxstb | It contains the apps, firmware and tools directories - synced to current CVS. As I said, it works in the sim, but not on the target. |
| 16:36:19 | preglow | but im hoping someone will try implementing an imdct via ifft soon |
| 16:36:38 | merbanan | preglow: faad has that |
| 16:36:57 | merbanan | preglow: and they use macros for it also |
| 16:37:02 | preglow | then lets hope someone writes a fast fft for coldfire soon |
| 16:37:02 | preglow | heh |
| 16:37:14 | preglow | linuxstb: damn, its big |
| 16:38:53 | linuxstb | Do you mean the source or the compiled aac.codec? |
| 16:38:58 | preglow | source |
| 16:39:33 | linuxstb | I'm sure it contains a lot of unused code. See the common.h file for which bits are enabled. |
| 16:40:50 | merbanan | preglow: the fft is macrobased |
| 16:41:41 | merbanan | preglow: do some fast macros and it should work ok |
| 16:44:22 | novimon_ | anyone else get corrupted .flac files out of dbpoweramp? |
| 16:45:24 | preglow | doesnt everyone? |
| 16:45:31 | novimon_ | dunno? |
| 16:45:38 | novimon_ | I for sure do? |
| 16:46:05 | preglow | merbanan: only macros i can see are the general math macros |
| 16:48:02 | preglow | parts of libfaad also seem to use awkward fixed point formats, like musepack does :/ |
| 16:48:36 | preglow | linuxstb: btw, im pretty sure flac has too weak an output |
| 16:49:14 | merbanan | preglow: fixed.h |
| 16:49:29 | linuxstb | preglow: Do you mean the samples are shifted incorrectly? |
| 16:49:38 | merbanan | preglow: what awkward format ? |
| 16:50:11 | preglow | linuxstb: i dont know how, but the volume is too low |
| 16:50:11 | linuxstb | novimon_: How are they corrupted? dbpoweramp will add ID3 tags to your FLAC files unless you tell it not to (when ripping from CD). |
| 16:50:24 | linuxstb | We need a WAV writer... |
| 16:50:27 | preglow | yes |
| 16:50:30 | preglow | yes we do |
| 16:50:44 | linuxstb | But my "main.c" test program gives bit-perfect output. |
| 16:53:28 | preglow | ive got the same track encoded as ogg and flac here |
| 16:53:36 | preglow | the flac one is noticably weaker |
| 16:53:52 | preglow | seems to be half volume |
| 16:54:29 | preglow | merbanan: like 14.18 fixed point |
| 16:55:04 | preglow | merbanan: you need to shift by 14 after a mul, which loses tons of precision if you havent got a full 64 bit mul available |
| 16:55:07 | preglow | which coldfire doesnt |
| 16:55:59 | merbanan | ahh ok |
| 16:57:04 | preglow | libmusepack does this as well |
| 16:57:26 | | Quit DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 16:57:26 | preglow | and thanks to that we need to calculate a full 64 bit mul all the time, which slows stuff down no end |
| 16:59:19 | merbanan | and just doing 7.9 is too low precision ? |
| 16:59:25 | linuxstb | preglow: I think I know the FLAC volume problem. It's the code at line 450 of dsp.c. Now that SAMPLE_DEPTH is > NATIVE_DEPTH, the "+1" comes into effect. |
| 16:59:39 | preglow | yup |
| 16:59:41 | linuxstb | So I should probably configure SET_SAMPLE_DEPTH to 27 |
| 16:59:47 | preglow | thats what i suspected as well |
| 16:59:49 | preglow | well |
| 17:00 |
| 17:00:00 | preglow | i think we should clarify that issue and fix it so its consistet |
| 17:00:08 | | Quit lostlogic ("Going to the moon") |
| 17:00:33 | preglow | consistent |
| 17:01:22 | linuxstb | I also need to tell the DSP the real sample depth of the data - i.e. 16 or 24 bits. |
| 17:03:43 | | Quit muesli- (Read error: 104 (Connection reset by peer)) |
| 17:04:18 | | Join muesli- [0] (i=muesli_t@hmln-d5147619.pool.mediaWays.net) |
| 17:07:32 | preglow | why? |
| 17:08:26 | linuxstb | Because you told me I did :) You said the dithering code needs to know. |
| 17:08:32 | preglow | ahh, yes yes |
| 17:09:24 | preglow | but that can come when we make all the codecs do the 28 bit resolution thing |
| 17:09:48 | preglow | i still dont know if anyone opposes the idea |
| 17:10:05 | preglow | i think a lot of the mallocs in libfaad can be remove pretty easily |
| 17:11:06 | linuxstb | Please do and send me a patch. I've only removed one so far - in bits.c I think. It was using malloc on all the input data. So it crashed after reading 512KB of data. |
| 17:11:47 | preglow | hahahahha |
| 17:11:58 | linuxstb | That was pretty obvious though. |
| 17:12:06 | preglow | ill see what i can do once i get back home |
| 17:12:09 | preglow | later tonight |
| 17:12:35 | preglow | but ive gotta go for now |
| 17:12:35 | preglow | later |
| 17:12:41 | linuxstb | But more useful would be to try and debug it on the target to find out where it crashes. |
| 17:12:44 | linuxstb | bye. |
| 17:20:29 | *** | Saving seen data "./dancer.seen" |
| 17:21:04 | | Join mirak [0] (n=mirak@ip-84.net-82-216-142.rev.numericable.fr) |
| 17:21:42 | | Quit muesli- (Read error: 113 (No route to host)) |
| 17:34:05 | | Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
| 17:50:16 | | Join lostlogic [0] (n=lostlogi@node-4024215a.mdw.onnet.us.uu.net) |
| 17:50:55 | | Quit linuxstb (Read error: 110 (Connection timed out)) |
| 17:51:08 | | Nick linuxstb_ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
| 18:00 |
| 18:15:56 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
| 18:19:03 | | Join hshah [0] (n=545cb9e8@labb.contactor.se) |
| 18:19:34 | hshah | heya all.... TiMiD are you around by any chance? |
| 18:23:44 | | Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
| 18:37:16 | | Join amiconn [0] (n=jens@p54BD5229.dip.t-dialin.net) |
| 18:37:45 | amiconn | evening |
| 18:38:23 | | Join muesli- [0] (i=muesli_t@hmln-d9b8e274.pool.mediaWays.net) |
| 18:38:23 | | Join LinusN [0] (n=linus@labb.contactor.se) |
| 18:38:43 | Quelsaruk | hi amiconn, LinusN :) |
| 18:40:23 | LinusN | yo |
| 18:40:59 | amiconn | Bagder: r u there? |
| 18:41:20 | hshah | im looking to TiMiD... lol |
| 18:41:47 | hshah | hopefully he can update the root2wps patch... coz it no longer applied to the modifications made to tree.c |
| 18:41:52 | hshah | *applies |
| 18:42:47 | LinusN | the silly left-to-wps patch? |
| 18:43:28 | hshah | the AMAZING left-to-wps patch you mean :p |
| 18:43:38 | LinusN | :-) |
| 18:44:05 | hshah | its just a matter of preference though... some people like it, some people don't... you don't like it, but i do :p |
| 18:44:06 | amiconn | Jens |
| 18:44:13 | amiconn | oops :) |
| 18:44:22 | amiconn | wrong kb |
| 18:44:34 | | Join RotAtoR [0] (n=e@12-210-82-91.client.insightBB.com) |
| 18:46:07 | | Join linuxstb_ [0] (n=5343d4aa@labb.contactor.se) |
| 18:50:44 | LinusN | hshah: i lust uploaded a revised patch to the forum thread |
| 18:51:05 | LinusN | s/lust/just/ |
| 18:52:55 | | Quit hshah ("CGI:IRC (EOF)") |
| 18:53:27 | amiconn | LinusN: You updated a silly patch? ;) |
| 18:53:35 | | Join hshah [0] (n=545cb9e8@labb.contactor.se) |
| 18:54:07 | hshah | cool - thanks Linus |
| 18:54:18 | hshah | i actually tried to apply the patch myself... |
| 18:54:30 | hshah | sorry, i mean modify |
| 18:54:33 | | Quit lostlogic ("Going to the moon") |
| 18:54:36 | hshah | and i forgot to put it in { } |
| 18:54:54 | hshah | and went home from uni over the weekend, and could not move back out of a folder on my iriver |
| 18:55:09 | LinusN | :-) |
| 18:55:09 | hshah | listening to 1 album for a 5 hour round trip is not fun!!! |
| 18:55:36 | amiconn | You could have rebooted... |
| 18:55:43 | | Join lostlogic [0] (n=lostlogi@node-4024215a.mdw.onnet.us.uu.net) |
| 18:55:51 | hshah | mine resumed playback... |
| 18:56:06 | amiconn | Switch off resume on startup, then reboot |
| 18:56:13 | hshah | hmm... |
| 18:56:15 | LinusN | or (god forbid) use the original firmware |
| 18:56:20 | hshah | well im retarded... i didn't think of that |
| 18:56:26 | hshah | or that... |
| 18:56:34 | hshah | lol - come on guys... i was really tired |
| 18:56:37 | hshah | lol |
| 18:57:02 | hshah | anyways, im gonna have a quick game of CS on lan with my housemates, so chat later... and keep up the good rockbox work guys! |
| 18:57:23 | LinusN | cu |
| 19:00 |
| 19:02:46 | mirak | LinusN: hi |
| 19:02:49 | amiconn | LinusN: I want to implement memove() soon, but memmove() and memcpy() will be in one source file because memcpy() will actually be a subset of memmove() (fassembler versions). Do you have an idea how to call the source file? |
| 19:02:49 | mirak | hshah: hi |
| 19:02:55 | mirak | amiconn: hello |
| 19:03:14 | mirak | how is going the H300 version ? |
| 19:03:30 | mirak | I mean the bootloader |
| 19:03:30 | LinusN | amiconn: just let it be memcpy.c |
| 19:03:37 | LinusN | mirak: no progress yet |
| 19:03:45 | amiconn | It's memcpy_a.S today |
| 19:03:49 | mirak | would be motivating for H300 users in joining |
| 19:03:54 | LinusN | ok, then keep it that |
| 19:03:58 | LinusN | mirak: yes i know |
| 19:04:00 | mirak | in joining coding rockbox |
| 19:04:13 | amiconn | The plain c versions will be two files, because they can't be interleaved that way |
| 19:04:25 | LinusN | amiconn: sure |
| 19:04:29 | mirak | yep I am interested, but having nothing running is not appealing :D |
| 19:04:40 | mirak | LinusN: you own a H300 ? |
| 19:04:47 | LinusN | of course i do |
| 19:05:14 | amiconn | LinusN: Different question - is it possible to have the build system execute certain steps depending on the result of another? |
| 19:05:30 | LinusN | amiconn: not really, why? |
| 19:05:59 | amiconn | I'm thinking about a way to implement compressed images for recorder v1 (and perhaps player some time in the future) |
| 19:06:28 | LinusN | ok, images as in pictures? |
| 19:06:44 | amiconn | No, as in binary rockbox images |
| 19:06:50 | LinusN | i see |
| 19:07:09 | amiconn | Depending on the size of rockbox.bin, I want one of two different steps to be executed: |
| 19:07:48 | amiconn | (1) If rockbox.bin is smaller than the limit, it will just be scrambled as ajbrec.ajz / archos.mod |
| 19:08:26 | amiconn | (2) If it's larger, then an additional tiny loader should be built, tacked in front of rockbox.ucl, and then scrambled into ajbrec.ajz / archos.mod |
| 19:08:31 | LinusN | hehe, just like back in the old c64 days. sounds like a job for a shell or perl script |
| 19:08:46 | amiconn | Something like a self-extracting image |
| 19:08:47 | LinusN | mkimage.pl |
| 19:09:04 | amiconn | We already build rockbox.ucl anyway - veery handy for this :) |
| 19:09:20 | LinusN | :-) |
| 19:09:46 | amiconn | The ucl unpacker is also already present in the flash bootloader, and the decompressing loader will do almost the same |
| 19:10:14 | amiconn | ...it only has to copy the compressed image to end-of-ram before decompressing, because decompressing in-place won't work |
| 19:10:29 | mirak | LinusN: do you want money ? |
| 19:10:35 | mirak | LinusN: or chocolates :D |
| 19:10:40 | mirak | lol |
| 19:10:45 | LinusN | mirak: i want time :-) |
| 19:11:00 | mirak | how much time ? |
| 19:11:42 | LinusN | my point is, i have little time to work on rockbox at the moment, as i have a wife and two kids |
| 19:11:51 | LinusN | and a job |
| 19:12:55 | LinusN | not just any wife btw, as she is in a wheelchair, so she needs a lot of help |
| 19:13:23 | mirak | ok |
| 19:13:25 | LinusN | Quelsaruk: yes, she is in fact a little better |
| 19:13:28 | mirak | sorry |
| 19:13:37 | LinusN | that's life |
| 19:13:45 | LinusN | mine at least :-) |
| 19:14:33 | Quelsaruk | oh |
| 19:14:35 | Quelsaruk | That's great |
| 19:14:40 | LinusN | yes |
| 19:14:55 | LinusN | she has almost halved the morphine dose |
| 19:15:07 | Quelsaruk | good news, indeed |
| 19:15:08 | Quelsaruk | :) |
| 19:17:44 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
| 19:18:54 | Quelsaruk | time to go, see you later/another day |
| 19:19:00 | | Nick Quelsaruk is now known as Quel|away (n=kvirc@80-103-103-117.mad1.adsl.uni2.es) |
| 19:20:30 | *** | Saving seen data "./dancer.seen" |
| 19:29:27 | | Quit muesli- (Read error: 110 (Connection timed out)) |
| 19:39:25 | RotAtoR | I've run into a strange problem display text on the iriver wiht my plugin. Would anyone be willing to look at my code? |
| 19:39:47 | RotAtoR | I've got the problem narrowed down to one block of code, but it makes no sense to me. |
| 19:40:29 | LinusN | bejeweled? |
| 19:40:31 | RotAtoR | yes |
| 19:40:45 | RotAtoR | http://netfiles.uiuc.edu/aboot2/www/bejeweled-test.c |
| 19:40:45 | LinusN | show me |
| 19:41:12 | RotAtoR | I've got it narrowed down to one place in the function bejeweled_init() |
| 19:42:05 | RotAtoR | the act of running the "clear the playboard" section of code causes text not to be displayed on the screen ever again on the target only, but it still works fine on the sim |
| 19:42:49 | | Quit hshah ("CGI:IRC (EOF)") |
| 19:43:25 | RotAtoR | the strange thing is that all the other graphics display works fine, the mono_bitmap calls, lines, and rects |
| 19:43:35 | RotAtoR | just text stops working |
| 19:44:12 | LinusN | RotAtoR: haven't you swapped height and width in the loop? |
| 19:44:53 | LinusN | i runs from 0 to 9, but the array has only 8 elements in that dimension |
| 19:45:02 | RotAtoR | hmm, that could be a problem... |
| 19:45:23 | LinusN | i think you accidentally overwrite the static strings with 0's |
| 19:45:59 | RotAtoR | arrgh, i'll check into it |
| 19:46:15 | LinusN | btw, memset is your friend |
| 19:46:46 | RotAtoR | hmm, yeah, that would be easier since I set it all to 0 |
| 19:46:48 | LinusN | and using macros for height and width might be a good idea |
| 19:47:21 | RotAtoR | yeah, i know, it' still a work in progress :p |
| 19:48:55 | LinusN | gotta go, good luck |
| 19:49:03 | RotAtoR | thanks for the help! |
| 19:50:23 | LinusN | yw |
| 19:50:25 | | Part LinusN |
| 19:52:21 | | Join DrMoos [0] (i=DrMoos@m79.net81-66-158.noos.fr) |
| 19:53:11 | | Quit Moos (Read error: 104 (Connection reset by peer)) |
| 19:53:39 | | Quit mirak (Remote closed the connection) |
| 19:59:50 | | Nick DrMoos is now known as Moos (i=DrMoos@m79.net81-66-158.noos.fr) |
| 20:00 |
| 20:02:33 | | Join Sucka [0] (i=dave@dhcp-163-1-214-173.seh.ox.ac.uk) |
| 20:08:16 | | Join muesli_- [0] (i=muesli_t@hmln-d5147617.pool.mediaWays.net) |
| 20:11:30 | RotAtoR | LinusN: That was the problem, thanks. Hooray for mistakes so stupid they're impossible to see... :) |
| 20:23:16 | | Quit actionshrimp (Read error: 110 (Connection timed out)) |
| 20:43:15 | | Join muesli- [0] (i=muesli_t@hmln-d9b8efb3.pool.mediaWays.net) |
| 20:59:32 | | Quit muesli_- (Read error: 113 (No route to host)) |
| 21:00 |
| 21:02:58 | | Join DrMoos [0] (i=DrMoos@m79.net81-66-158.noos.fr) |
| 21:03:20 | | Quit Moos (Read error: 104 (Connection reset by peer)) |
| 21:03:29 | | Nick DrMoos is now known as Moos (i=DrMoos@m79.net81-66-158.noos.fr) |
| 21:20:34 | *** | Saving seen data "./dancer.seen" |
| 21:30:57 | | Quit Rick (Read error: 104 (Connection reset by peer)) |
| 21:32:07 | | Join Rick [0] (i=rick@pool-71-108-9-40.lsanca.dsl-w.verizon.net) |
| 21:43:10 | | Quit linuxstb_ ("CGI:IRC") |
| 21:48:50 | | Join [IDC]Dragon [0] (n=54839cd4@labb.contactor.se) |
| 21:49:40 | amiconn | hi [IDC]Dragon |
| 21:49:47 | [IDC]Dragon | hi guys |
| 21:49:48 | amiconn | ltnirc! |
| 21:49:54 | [IDC]Dragon | really |
| 21:50:20 | * | amiconn just committed a new SH1 memcpy() |
| 21:50:23 | [IDC]Dragon | and I'm only here to abuse some external brain |
| 21:50:36 | [IDC]Dragon | I need a very primitive PRNG |
| 21:50:55 | [IDC]Dragon | for my home networking controllers |
| 21:51:05 | amiconn | Just use the one from the grayscale lib |
| 21:51:12 | [IDC]Dragon | to determine a backoff interval on collisions |
| 21:51:30 | [IDC]Dragon | that's what I remembered, yes |
| 21:51:36 | amiconn | It only needs 16 bit ints |
| 21:52:00 | [IDC]Dragon | it would be cool to add some "randomness" whenever I encounter some |
| 21:52:26 | [IDC]Dragon | like, the local time stamp on incoming bytes |
| 21:52:32 | amiconn | In fact it's the algorithm that the good old ZX Spectrum used. Not taken from the code, it was described in the manual |
| 21:53:03 | amiconn | Linear congruency is almost trivial, you only need 'good' parameters |
| 21:53:03 | [IDC]Dragon | not taken form Z80 assembler? ;-) |
| 21:53:08 | amiconn | nope |
| 21:53:20 | amiconn | It's way easier with SH1 because it has mul |
| 21:53:29 | amiconn | 6 asm instructions for the prng itself |
| 21:54:27 | amiconn | Does your controller have mul? |
| 21:55:43 | [IDC]Dragon | I think so |
| 21:56:52 | [IDC]Dragon | (never went down to asm, gcc worked very well) |
| 21:58:10 | amiconn | Is this a 16 or 32 bit controller? |
| 21:58:51 | [IDC]Dragon | hehe, 8 bit |
| 21:58:56 | amiconn | urgs |
| 21:59:19 | [IDC]Dragon | no problem in C |
| 22:00 |
| 22:00:36 | [IDC]Dragon | I have some CRC code anyway, was thinking about using that |
| 22:00:53 | amiconn | Hmm? |
| 22:01:03 | [IDC]Dragon | easy re-randomisation |
| 22:01:03 | amiconn | What does CRC have to do with PRNG? |
| 22:01:19 | amiconn | How many random bits would you need? |
| 22:01:44 | [IDC]Dragon | very few, 2..4 |
| 22:01:46 | amiconn | Linear congruency is simple, but not all bits of the result are very random |
| 22:02:10 | amiconn | The prng in the grayscale is 16 bit. The upper 8 bits are random enough |
| 22:02:20 | [IDC]Dragon | yes, saw that |
| 22:02:33 | [IDC]Dragon | do you seed it? |
| 22:02:38 | amiconn | no |
| 22:03:24 | amiconn | No need to, as I only need a random 'looking' sequence. It can be the same every time the grayscale lib is used |
| 22:03:53 | amiconn | It avoid moire patterns |
| 22:03:59 | [IDC]Dragon | for me, a different sequence is essential |
| 22:04:13 | amiconn | Then you'll need a seed |
| 22:04:24 | amiconn | It's the same with all prngs |
| 22:04:36 | [IDC]Dragon | sure |
| 22:04:56 | [IDC]Dragon | the only thing that differs inbetween my controllers is the address |
| 22:05:11 | [IDC]Dragon | so that would be a first seed |
| 22:05:46 | amiconn | The sequences will be shifted anyway, because (I assume) the controllers aren't powered up at the same time |
| 22:05:59 | [IDC]Dragon | some more randomization on the way is welcome, like those timestamps when receiving external bytes |
| 22:06:28 | | Join einhirn [0] (i=Miranda@szgt-d9b8e2cf.pool.mediaWays.net) |
| 22:06:31 | [IDC]Dragon | they are powered on together |
| 22:06:46 | amiconn | ah, hmm |
| 22:06:51 | [IDC]Dragon | but reset hold time seems to vary |
| 22:07:07 | [IDC]Dragon | voltage rise, analog stuff |
| 22:07:39 | [IDC]Dragon | but that doesn't give me different numbers |
| 22:15:37 | * | [IDC]Dragon glances over the memcpy() |
| 22:16:22 | [IDC]Dragon | perhaps the most advanced the SH has ever seen ;-) |
| 22:17:10 | amiconn | Next thing (already started) is the reverse copy, then I'll combine both to form a memmove() with "embedded" memcpy() |
| 22:17:23 | amiconn | After that I'll do the same for coldfire |
| 22:18:30 | | Join JAJDude [0] (n=ca51121e@labb.contactor.se) |
| 22:23:26 | | Quit JAJDude (Client Quit) |
| 22:28:55 | | Join Kohlriba [0] (n=Kohlrabi@dslb-082-083-130-062.pools.arcor-ip.net) |
| 22:30:05 | [IDC]Dragon | reverse for bidir scrolling? |
| 22:31:51 | amiconn | For memmove() in general |
| 22:32:05 | amiconn | Useful for scrolling and other things |
| 22:46:23 | | Quit Kohlrabi (Read error: 110 (Connection timed out)) |
| 23:00 |
| 23:02:05 | | Join muesli_- [0] (i=muesli_t@hmln-d9b8ef50.pool.mediaWays.net) |
| 23:17:08 | | Join tvelocity [0] (n=tony@ipa97.7.tellas.gr) |
| 23:20:35 | *** | Saving seen data "./dancer.seen" |
| 23:25:49 | [IDC]Dragon | Jens, I use your PRNG now, with an extra randomize |
| 23:26:00 | | Quit muesli- (Read error: 110 (Connection timed out)) |
| 23:27:18 | amiconn | Wow... my reverse copy loop is working correctly at the first try |
| 23:27:34 | amiconn | suspicious, I'd say... |
| 23:28:28 | [IDC]Dragon | the coplex stuff is "always" correct, it's the simple things that breaks me |
| 23:28:38 | [IDC]Dragon | complex |
| 23:31:05 | amiconn | I should choose the reverse loop as 'standard' (the one used for memcpy). It's a bit faster than the forward case |
| 23:32:29 | [IDC]Dragon | never mind, I'm sleepy |
| 23:33:01 | [IDC]Dragon | goodnight |
| 23:33:09 | amiconn | nitey |
| 23:33:21 | | Quit [IDC]Dragon ("CGI:IRC (EOF)") |
| 23:49:03 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 23:58:43 | | Quit RotAtoR (Nick collision from services.) |
| 23:59:00 | | Join RotAtoR [0] (n=e@12-210-82-91.client.insightBB.com) |
icon identifies that the person is a core developer (has commit access).