| 00:00:13 | Quelsaruk | morning |
| 00:00:14 | Quelsaruk | :D |
| 00:00:25 | muesli_- | g'day :D |
| 00:00:28 | | Join preglow [0] (thomj@s183a.studby.ntnu.no) |
| 00:01:06 | | Join amiconn_ [0] (~jens@pD9E7EB82.dip.t-dialin.net) |
| 00:03:42 | | Quit Renko (Remote closed the connection) |
| 00:04:27 | | Quit hubble () |
| 00:10:40 | | Quit cYmen (Read error: 113 (No route to host)) |
| 00:17:33 | | Quit amiconn (Read error: 110 (Connection timed out)) |
| 00:17:33 | | Nick amiconn_ is now known as amiconn (~jens@pD9E7EB82.dip.t-dialin.net) |
| 00:26:08 | | Join pill [0] (dearth@ip-130.net-82-216-140.issy4.rev.numericable.fr) |
| 00:26:09 | | Quit muesli_- (Read error: 104 (Connection reset by peer)) |
| 00:31:12 | | Quit Sucka ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") |
| 00:43:11 | Patr3ck | can someone explain what the function wake_up_thread() in kernel.h does? |
| 00:46:38 | | Join Sykoghost [0] (~chatzilla@ip24-251-1-227.ph.ph.cox.net) |
| 00:51:28 | Patr3ck | maybe tommorow... |
| 00:55:41 | preglow | well, i wakes threads that are sleeping |
| 00:56:00 | Patr3ck | i have seen it in interrupt handling routines |
| 00:56:46 | Patr3ck | other threads go to sleep when the interrupt occures and awaken when the interrupt routine finishes? |
| 00:56:52 | | Quit Digital007 ("CGI:IRC (EOF)") |
| 00:56:54 | preglow | it just resets num_sleepers, which is set to number of sleeping threads |
| 00:57:09 | preglow | so it bascially just wakes everything up |
| 00:57:30 | preglow | what makes a thread sleep is dependent on what it does, i guess |
| 00:57:32 | preglow | really don't know |
| 00:57:52 | Patr3ck | ok |
| 00:57:53 | preglow | cool, when all threads sleep, rockbox set cpu to sleep mode |
| 00:58:11 | Patr3ck | saves power? |
| 00:58:20 | preglow | yup |
| 00:58:30 | preglow | does absolutely nothing until an interrupt occurs |
| 00:58:36 | Patr3ck | cool |
| 00:59:18 | Patr3ck | which will happen every 1 ms if i am able to program that second timer the coldfire has ;-) |
| 00:59:53 | *** | Saving seen data "./dancer.seen" |
| 01:00 |
| 01:01:14 | preglow | what are you going to use it for? |
| 01:01:20 | Patr3ck | profiling |
| 01:01:36 | Patr3ck | measure time in milliseconds |
| 01:01:44 | | Quit Sykoghost ("Chatzilla 0.9.67 [Firefox 1.0/20041107]") |
| 01:01:51 | preglow | how do you plan to do the profiling? just insert timing in all the functions? |
| 01:02:10 | Patr3ck | naive approach for now |
| 01:02:40 | preglow | i was thinking of a way to do it more automatically |
| 01:02:44 | Patr3ck | add PROFILING_START(symbol_name), PROFILING_STOP(symbol_name) to every function to profile |
| 01:03:11 | Patr3ck | add the information gathered to a central array |
| 01:03:27 | preglow | having the timer interrupt check its own stackframe to find the previous eip, then add that eip to an array that gets dumped to a file at some point |
| 01:03:38 | preglow | s/eip/ip/ |
| 01:03:42 | preglow | i forget i'm not on x86 anymore, heh |
| 01:04:01 | preglow | then you can translate those ip addresses to function name with the rockbox.map file |
| 01:04:15 | Patr3ck | i see |
| 01:04:33 | Quelsaruk | sleep(); |
| 01:04:33 | preglow | the only problem is: the rockbox map file doesn't contain names of static functions :/ |
| 01:04:36 | | Quit Quelsaruk ("KVIrc 3.0.1.99 'Realia'") |
| 01:04:44 | Patr3ck | the array would grow very fast though? |
| 01:04:56 | preglow | yes |
| 01:04:56 | Patr3ck | ah |
| 01:05:04 | preglow | one entry for every ip |
| 01:05:13 | preglow | which would be a lot in the end |
| 01:05:23 | preglow | possibly _very_ big, yes, you've got a good point :P |
| 01:05:32 | Patr3ck | ;-) |
| 01:06:02 | Patr3ck | with that method, could a tree like structure of function call be recorded? |
| 01:06:15 | Patr3ck | s/call/calls/ |
| 01:07:25 | preglow | hmm |
| 01:07:26 | preglow | don't think so |
| 01:07:50 | Patr3ck | my code isn't doing it now, but that would be possible to add |
| 01:07:54 | preglow | it would eliminate the need for having to modify functions |
| 01:08:00 | Patr3ck | yes |
| 01:08:04 | preglow | but it would only give relative timing |
| 01:08:08 | preglow | but that should be enough, really |
| 01:08:22 | preglow | if one function has 3242352 hits, and another 483, you know which of them to optimize ;) |
| 01:08:31 | Patr3ck | right |
| 01:08:43 | Patr3ck | not having to modifiy the code to profile would be a big plus |
| 01:09:13 | preglow | but the point you raised is a good one, we would have to make an internal address->function name table |
| 01:09:25 | preglow | or write to disk from the interrupt handler, which i guess is Bad |
| 01:10:02 | Patr3ck | not good for time measurement |
| 01:10:27 | preglow | time isn't measured anyway, you're just measuring which functions is used most |
| 01:10:33 | preglow | not how much time they use |
| 01:10:33 | Patr3ck | ah |
| 01:10:54 | preglow | you can translate that information to time used if you time the program, though |
| 01:12:10 | Patr3ck | if the time is not measured, writing to disk during profiling shouldn't be an issue? |
| 01:12:36 | preglow | no, but can you write to disk in an interrupt handler? |
| 01:12:48 | Patr3ck | i have no idea :-) |
| 01:14:23 | preglow | i'd say go for your idea right now |
| 01:14:24 | preglow | heh |
| 01:14:27 | preglow | you need the timer anywa |
| 01:14:28 | preglow | y |
| 01:15:06 | Patr3ck | it already works, using ticks for measurement at the moment |
| 01:15:18 | preglow | cool |
| 01:15:26 | Patr3ck | after the other timer is done i will switch to it |
| 01:15:52 | Patr3ck | only thing that bothers me is the overhead of the profiling corrupting the measurement of time |
| 01:17:20 | Patr3ck | the overhead of profiling will be added to the time used of a function deeper in the call tree |
| 01:18:58 | | Join XShocK [0] (~XShocK@pcp09492659pcs.nrockv01.md.comcast.net) |
| 01:20:58 | | Quit midk ("Leaving") |
| 01:27:56 | | Join ashridah [0] (ashridah@220-253-119-163.VIC.netspace.net.au) |
| 01:29:34 | Patr3ck | preglow: thinking about your idea, why not only store ip adresses + call count in an array |
| 01:29:51 | preglow | Patr3ck: because the ip address would be different more or less every time |
| 01:31:26 | Patr3ck | preglow: it does not correspond directly to a function... |
| 01:31:40 | Patr3ck | preglow: would it be possible to do the but if you translate ip addresses to function names |
| 01:31:43 | Patr3ck | ops |
| 01:31:57 | preglow | yes it does, but a function can correspond to many addresses |
| 01:32:15 | preglow | Patr3ck: well, yes, it would, but impractical :/ |
| 01:32:16 | preglow | but: |
| 01:32:21 | preglow | you can do it in two passes |
| 01:32:24 | preglow | one pass where you write |
| 01:32:28 | preglow | another where you time |
| 01:32:47 | Patr3ck | preglow: translate them to function names in the interrupt? |
| 01:32:59 | preglow | yes, but it would require a huge lookup table |
| 01:33:11 | preglow | and a script would have to be written to translate the map file to a lookup table |
| 01:34:03 | Patr3ck | too bad, not changing the code to profile would be a winner :-) |
| 01:34:29 | preglow | but yes, the ip -> function name resolution can be done by a script |
| 01:34:54 | preglow | but yes, i don't know if i can access the disk in an interrupt |
| 01:34:57 | preglow | need to find that out |
| 01:35:12 | Patr3ck | if its done by a script you still have the fast growing array of ips |
| 01:35:28 | preglow | yes, but that's no problem |
| 01:35:42 | preglow | a huge file should be done pretty quickly |
| 01:35:55 | preglow | i wonder how the gnu profiler handles this |
| 01:36:05 | preglow | it does something very much like this, i think |
| 01:38:09 | Patr3ck | well, for now I will finish what I started... |
| 01:38:19 | preglow | do that |
| 01:38:49 | | Quit Aison ("( www.nnscript.de :: NoNameScript 3.72 :: www.XLhost.de )") |
| 01:41:54 | Patr3ck | to bed now, bye |
| 01:42:29 | | Quit Patr3ck () |
| 01:56:01 | | Join markun [0] (~markun@bastards.student.utwente.nl) |
| 01:57:05 | | Quit mecraw () |
| 01:58:33 | markun | for all you log readers: I added _LOW_ACCURACY_ to the building of Tremor. vorbis2wav now gives me 4.27% real-time. |
| 01:58:41 | | Quit markun (Client Quit) |
| 02:00 |
| 02:26:48 | | Join stevenm [0] (~stevenm@stevenm-router.student.umd.edu) |
| 02:26:58 | stevenm | Hello. Anyone here working on the iriver port ? |
| 02:27:57 | preglow | depends on what part you mean |
| 02:28:17 | stevenm | I am looking for someone who can test the beginnings of my MIDI codec on the target |
| 02:28:34 | stevenm | Or on a simulator, if the sim build supports sound now |
| 02:28:36 | preglow | you haven't got a player yourself? :P |
| 02:28:49 | preglow | well, the player itself sure as hell doesn't support sound yet |
| 02:28:56 | stevenm | nah, all I've got is an ajbrec |
| 02:28:57 | preglow | that is, it does, but the changes aren't in cvs yet |
| 02:29:07 | stevenm | I see.. |
| 02:29:24 | | Quit edx (Read error: 110 (Connection timed out)) |
| 02:29:26 | preglow | so unless it renders to wav or something, no can do |
| 02:29:26 | stevenm | What kind of code are you "allowed" to write for Iriver ? |
| 02:29:42 | stevenm | like, can you use mallocs or not ? |
| 02:29:59 | stevenm | right now it ouptputs to a pc's sound card.. but that's a PC |
| 02:30:02 | preglow | depends on how much memory you need, i think malloc is available now |
| 02:30:48 | stevenm | Hmm |
| 02:31:05 | stevenm | I am allocating a few large blocks and a bunch of small ones |
| 02:31:17 | preglow | what are you using the memory for?= |
| 02:31:28 | stevenm | by large I mean around 16k, and the smaller ones are around 3 -100 bytes |
| 02:31:36 | preglow | if this is supposed to be a codec, you should use the mp3 buffer anyway |
| 02:31:59 | stevenm | for a MIDI file, it has to load the whole thing into memory before being able to play it |
| 02:32:06 | preglow | yes |
| 02:32:17 | stevenm | But if it's a MIDI file, it will very rarely be over 100k |
| 02:32:28 | preglow | but if the memory you need is to be constantly used throughout the song, you can just as well reserve some space for it in the mp3 buffer while you're loading the midi file |
| 02:33:15 | stevenm | I see |
| 02:33:23 | stevenm | How big is the MP3 buffer ? |
| 02:33:31 | preglow | about 30 odd meg |
| 02:33:37 | stevenm | And, if I do not put it in the MP3 buffer, how much 'non-MP3' memory is there ? |
| 02:33:40 | preglow | that's where all the tracks are put |
| 02:33:52 | preglow | that i don't know |
| 02:33:56 | stevenm | wow.. that is quite a bit of memory |
| 02:33:59 | preglow | my guess would be 'not much' |
| 02:34:03 | stevenm | Well... |
| 02:34:17 | stevenm | I think right now I will leave the tracks in regular memory |
| 02:34:33 | stevenm | because I'll most likely need the MP3 buffer for the wavetables, **IF** I ever figure out the GUS patch format |
| 02:35:08 | preglow | you should find gus patch loaders around, tons of programs have used those patches |
| 02:35:20 | preglow | when you make the codec, you should use the mp3 buffer for all you can |
| 02:35:30 | stevenm | Hmm |
| 02:35:45 | preglow | pattern data, sound fonts, data you need during the whole duration of the track |
| 02:35:56 | preglow | it doesn't matter, it'll be just like using malloc anyway, i guess |
| 02:36:02 | stevenm | How can I use it? Is there a special routine that will allocate memory within it? Or do i just get handed a pointer to the beginning of this buffer ? |
| 02:36:09 | preglow | it isn't done yet |
| 02:36:17 | preglow | we're still discussing the codec api |
| 02:36:20 | stevenm | I see |
| 02:36:58 | stevenm | well right now, the player runs on a PC, but only one file is actually dependent on a PC. the rest should work fine w/ iriver |
| 02:37:11 | preglow | great, no floating point i hope? |
| 02:37:18 | preglow | though i can't see why a midi player would require that, heh |
| 02:37:44 | stevenm | Weeell...... |
| 02:37:55 | stevenm | There's 'some' floating point |
| 02:37:59 | preglow | used for what? |
| 02:38:05 | stevenm | just for the sine math |
| 02:38:12 | preglow | i can pretty much guarantee you it's easily removed anyway |
| 02:38:26 | stevenm | yea |
| 02:38:26 | preglow | what do you use sines for? |
| 02:38:51 | stevenm | Since I don't have a patch loader, but I felt like testing everything else, I just syntehsized each note on each instrument as a sine wave |
| 02:39:02 | preglow | ahh, won't need that in the final codec ;) |
| 02:39:12 | stevenm | hopefully not..... if I can figure out GUS |
| 02:39:14 | preglow | i've done a sine routine in fixed point math anyway |
| 02:39:28 | stevenm | yea, it shouldn't be too hard |
| 02:39:44 | stevenm | or I can do that Taylor thing.. I won't need too much percision |
| 02:40:06 | preglow | that'll work too, yes |
| 02:40:25 | stevenm | what's the maximum sampling rate / sample size I can use ? |
| 02:42:03 | preglow | hardware limit is around 100khz |
| 02:42:12 | preglow | but can't see why anyone would want to use more than 48khz on a portable |
| 02:42:14 | stevenm | woow |
| 02:42:35 | stevenm | right now I have it set at 41000, but that can be easily changed |
| 02:42:40 | preglow | yup |
| 02:42:51 | stevenm | it's fairly independent of that |
| 02:42:52 | preglow | most people will probably have to nonstreaming codecs set at 44.1khz |
| 02:42:55 | preglow | the |
| 02:43:29 | stevenm | all the timing is based on how quickly the device can play back its buffer.. knowing the sampling rate, it generates the right number of samples per MIDI tick |
| 02:43:50 | stevenm | if you feel like checking this thing out (and have linux) there's a link on the wiki |
| 02:44:13 | stevenm | i'm just not sure how to write to the iriver dsp.. guess i'll have to wait for the codec api |
| 02:44:20 | preglow | yup |
| 02:44:24 | preglow | we're not sure ourselves, right now |
| 02:44:25 | preglow | heh |
| 02:44:31 | preglow | we've had some discussions, but that's that |
| 02:44:54 | stevenm | yea it must be annoying to make a cross-platform codec api |
| 02:45:06 | stevenm | iriver, plus that gmini thing |
| 02:45:25 | preglow | that will be interesting, yes |
| 02:45:57 | stevenm | Do you know of a good place to find an explaination of the GUS format ? |
| 02:46:17 | stevenm | I been trying to figure this out for a while... most results I get are old obscure DOS utilities for loading GUS data into a GUS card |
| 02:46:30 | stevenm | no code, of course |
| 02:46:43 | preglow | what extension is it? |
| 02:46:52 | stevenm | .pat |
| 02:46:58 | preglow | yes, remembered) |
| 02:47:17 | preglow | i wish i still had a gus |
| 02:47:20 | stevenm | I did find one place that gives the structure of the header.. just the field names, but nothing about what they mean |
| 02:48:13 | preglow | what about soundfonts, btw? |
| 02:48:28 | stevenm | I gather they are similar to GUS patches |
| 02:48:56 | preglow | a bit more elaborate |
| 02:48:59 | stevenm | I think I came across a utility that will turn amny gus patches into a soundfont, and vice versa |
| 02:49:41 | preglow | sf2 specifies filter settings and stuff |
| 02:49:47 | stevenm | Wow |
| 02:49:50 | preglow | don't know if it's actually used, though |
| 02:50:25 | stevenm | I looked at the header description.. there's stuff in there that I haven't even heard of |
| 02:50:47 | stevenm | it's so intimidating... forget tremolo and vibrato, right now I just want to load a sample |
| 02:51:18 | preglow | both are piece of cake anyway, but i understand your concern ;) |
| 02:51:42 | preglow | but yes, gus patch doesn't look too hard, but there are some fields i don't understand |
| 02:51:45 | stevenm | yea.. once I get the basic parts of it down, I can probably code the "extra" stuff.. but just loading one wavefurm would be nice |
| 02:51:59 | stevenm | do you know how to read a GUS file ?? |
| 02:52:08 | preglow | no, i'm just looking at a rough spec |
| 02:53:55 | stevenm | I was going back and forth about what would be easier, emulating an FM chip or figuring out GUS |
| 02:54:12 | preglow | haha |
| 02:54:29 | stevenm | way back when, I made a simple 8Khz patch set.. of just raw data, no ADSR or anything. it sounds like JUNK but it wasn't exactly meant for a PC |
| 02:54:31 | preglow | writing a simple fm synth is also piece of cake |
| 02:54:36 | stevenm | Really ? |
| 02:54:39 | preglow | yes |
| 02:54:57 | stevenm | Where would you get the formula for producing a sample? |
| 02:55:07 | stevenm | and, where would you get the FM parameters for each MIDI instrument ? |
| 02:55:22 | preglow | the last would be 'through trial and error' |
| 02:55:41 | stevenm | ah |
| 02:55:45 | preglow | unless you emulate an opl chip and make a loader for those patches |
| 02:55:51 | preglow | in which case you've got more work on your hands |
| 02:56:12 | stevenm | I have been digging whru the Fm emulator built into scummvm |
| 02:56:15 | preglow | but fm is just a bunch of sine waves ticling each other in a nice fashion |
| 02:56:21 | stevenm | yea |
| 02:56:31 | preglow | and the sine wave routine i've already got |
| 02:56:35 | stevenm | in their code, I saw a HUGE table, named simply gm_to_fm[] |
| 02:56:41 | preglow | hmm |
| 02:56:58 | stevenm | only, there is no explaination of what order the parameters are in |
| 02:57:10 | preglow | but no |
| 02:57:17 | preglow | sample loader is the way to go |
| 02:57:20 | preglow | for now, at least |
| 02:57:46 | stevenm | The problems: the whole code has been adapted for scummvm, in C++, and the synth file (which looks ike YS2126?) is all in Japanese |
| 02:58:05 | stevenm | you're probably right |
| 02:58:11 | preglow | http://www.wotsit.org/download.asp?f=patfmt |
| 02:58:14 | preglow | http://www.wotsit.org/download.asp?f=pat2 |
| 02:58:19 | preglow | you've seen those two, i take it? |
| 02:58:49 | preglow | the last one seems to be slightly different, but's got more explanations of the fields |
| 02:59:04 | stevenm | getting off-site link errors |
| 02:59:15 | preglow | ahh |
| 02:59:18 | preglow | www.wotsit.org |
| 02:59:20 | preglow | search for 'pat' |
| 02:59:23 | preglow | first two hits |
| 02:59:39 | stevenm | yea.. got it |
| 02:59:55 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:00:28 | stevenm | I have seen this |
| 03:00:47 | stevenm | What are layers ? |
| 03:00:56 | | Join skav [0] (skav@67-138-74-184.dsl1.merch.roc.ny.frontiernet.net) |
| 03:01:11 | preglow | i have no idea, and it doesn't seem to be supported anyway |
| 03:01:27 | preglow | it probably refers to layered samples, playing several samples simultaneously |
| 03:01:40 | stevenm | dang |
| 03:01:46 | preglow | like in a piano, the hammer and the vibrating string |
| 03:01:53 | preglow | could be separate samples |
| 03:01:55 | preglow | but i'm not sure |
| 03:02:07 | stevenm | hmm.. that makes sense |
| 03:02:27 | preglow | but yes, as it says, i think layers = 1 is most common, and then you don't have to worry about it :) |
| 03:02:40 | stevenm | I see |
| 03:02:56 | stevenm | now, when they say, 'attack rate' / envelope rate / etc, what units are they using ? |
| 03:03:10 | stevenm | I mean, it's just a number.. how do you make use of it in the code ? |
| 03:03:32 | preglow | i have no idea |
| 03:03:37 | preglow | same with tremolo and vibrato |
| 03:03:42 | preglow | they're pretty useless with no reference |
| 03:03:47 | stevenm | yea |
| 03:04:07 | stevenm | you know what |
| 03:04:13 | stevenm | I remember an old windows program, Awave |
| 03:04:24 | stevenm | and I know I tried using it to figure out GUS before |
| 03:04:49 | stevenm | do you think it would be reasonable to use this thing to extract the data out of the GUS files into, say, .raw files or .wav, and then try to work with those ? |
| 03:05:02 | preglow | well, what would you gain? |
| 03:05:12 | stevenm | at least I would know the format of the files I am dealing with |
| 03:05:24 | preglow | sure, you don't have to write a pat parser, but that doesn't look like it's too hard |
| 03:05:34 | preglow | but the tremolo settings and so forth will still be a mystery |
| 03:05:35 | stevenm | Hmm |
| 03:06:08 | stevenm | All I REALLY need to know is the waveform, the sampling rate / sample size, and what MIDI note this waveform represents |
| 03:06:43 | preglow | envelope too is pretty important |
| 03:06:55 | stevenm | ah |
| 03:07:08 | preglow | or the sounds will sound very unnatural |
| 03:07:12 | preglow | like old mods, heh |
| 03:07:13 | stevenm | could you maybe explain the whole envelope thing to me? I know it has to do with volume/fading, but what is it exactly ? |
| 03:07:52 | preglow | it's just to regulate the sound level of different parts of the sound, you've got an attack part that fades slowly from 0 to max level at the start of the sound |
| 03:08:04 | stevenm | I understand the basics of ADSR, but how does that relate to envelope ? |
| 03:08:04 | preglow | and a release part the fades slowly to 0 after the note has been dropped |
| 03:08:15 | preglow | well, an adsr is an envelope |
| 03:08:28 | stevenm | ahhh |
| 03:08:31 | preglow | i don't know how it's specified in the file, if that's what you mean |
| 03:09:20 | stevenm | it looks like the file has an 'envelope rate' and 'envelope offset' but how to process that, I have no idea |
| 03:09:26 | preglow | nor have i |
| 03:09:30 | preglow | you would need much better docs |
| 03:09:37 | preglow | but yes, soundfonts are another solution |
| 03:09:43 | preglow | i think they've got way better docs |
| 03:09:54 | stevenm | do you know anything about soundfonts ? |
| 03:09:59 | preglow | you've still got plenty of time to fiddle around with this ;) |
| 03:10:01 | preglow | not very much, no |
| 03:10:05 | preglow | the very basics |
| 03:10:23 | preglow | and the fact that they're alot more complicated than .pat files |
| 03:10:34 | stevenm | hmm |
| 03:10:59 | stevenm | I guess one idea I can try, I can load EVERY field in the file, then open that file in that Awave program and compare its file info to what I've got loaded |
| 03:11:14 | stevenm | see if there's some sort of correlation |
| 03:11:35 | preglow | soundfonts are riff files, it seem |
| 03:11:45 | stevenm | last time I tried this.. I tried loading a .pat and feeding the waveform to the PC's dsp.. got a bunch if garbled noise, gave up |
| 03:11:48 | preglow | yes, but does awave interpret envelope data and such? |
| 03:11:59 | stevenm | yea.. it'll give you a picture of the waveform, even |
| 03:13:06 | stevenm | I don't remember too well.. it's still on my 200mhz dell.. and that's at my anut's crazy fiancee's house |
| 03:13:08 | preglow | good god, the sf2 spec is boring |
| 03:13:21 | stevenm | hm ? |
| 03:13:48 | preglow | i'm flipping through the soundfont spec |
| 03:13:58 | preglow | it's about ninety pages |
| 03:14:01 | stevenm | is it descriptive ? |
| 03:14:02 | stevenm | wow |
| 03:14:15 | stevenm | I wonder how many pages of code that would translate to :) |
| 03:14:27 | preglow | its very descriptive, heh |
| 03:14:56 | preglow | figures and everything |
| 03:15:15 | stevenm | one reason I'm sort of leaning towards GUS is that there's a nice patch set called EAWPatches that is I think GPLed and freely available |
| 03:15:43 | preglow | complete with filter specifications and all |
| 03:15:48 | stevenm | filters ? |
| 03:15:55 | preglow | yes, resonant lowpass ones |
| 03:16:06 | preglow | i've done that on the coldfire as well, so it's covered if its needed |
| 03:16:23 | stevenm | what are those ? |
| 03:16:43 | preglow | kind of hard to explain, you've probably heard them tons of times |
| 03:16:45 | preglow | classic synth effect |
| 03:16:58 | | Join ze__ [0] (ze@adsl-69-231-209-37.dsl.irvnca.pacbell.net) |
| 03:17:20 | stevenm | hmm.. I guess i could use the coldfire version if that's needed |
| 03:17:38 | stevenm | I wonder, would the iriver have enough processing power to deal with all this ? |
| 03:17:38 | preglow | yep, but it's far in the future |
| 03:17:44 | preglow | just work on the .pat loader from now |
| 03:17:46 | preglow | yes, it should |
| 03:18:10 | stevenm | I got the c++ version of my program to run on a 133Mhz system w/o problems.. but that's using 8k patches |
| 03:18:14 | preglow | midi playback is just basically playing enveloped samples |
| 03:18:19 | stevenm | yea |
| 03:18:36 | preglow | but i've got to go to bed |
| 03:18:39 | stevenm | Ah |
| 03:18:44 | stevenm | do you come here often ? |
| 03:18:58 | preglow | yup, i'm in here all the time these days |
| 03:19:06 | stevenm | cool. maybe I will see you again |
| 03:19:12 | preglow | probably |
| 03:19:14 | preglow | but later |
| 03:19:16 | | Quit preglow ("off") |
| 03:19:17 | stevenm | thanks for the help, and good night |
| 03:19:20 | | Quit stevenm ("Leaving") |
| 03:19:25 | | Join Andrew179 [0] (~gtg516h@r42h108.res.gatech.edu) |
| 03:24:12 | | Quit XShocK (" HydraIRC -> http://www.hydrairc.com <- State of the art IRC") |
| 03:25:19 | | Join amall [0] (~gffdsgs@cvg-165-104-211.cinci.rr.com) |
| 03:28:18 | | Quit ze (Read error: 110 (Connection timed out)) |
| 03:28:18 | | Nick ze__ is now known as ze (ze@adsl-69-231-209-37.dsl.irvnca.pacbell.net) |
| 03:30:12 | | Quit ashridah ("Leaving") |
| 03:30:23 | | Join ashridah [0] (ashridah@220-253-119-163.VIC.netspace.net.au) |
| 03:35:01 | | Join StrathAFK [0] (~mike@dgvlwinas01pool0-a239.wi.tds.net) |
| 03:53:30 | | Quit Strath (Read error: 110 (Connection timed out)) |
| 03:58:52 | | Join edx [0] (edx@p54879699.dip.t-dialin.net) |
| 04:00 |
| 04:05:55 | | Join QT_ [0] (as@area51.users.madwifi) |
| 04:14:28 | | Quit QT (Read error: 60 (Operation timed out)) |
| 04:59:59 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:39:08 | | Quit skav () |
| 05:47:40 | | Quit pill (Read error: 60 (Operation timed out)) |
| 06:00 |
| 06:26:20 | | Join pill [0] (dearth@ip-130.net-82-216-140.issy4.rev.numericable.fr) |
| 07:00 |
| 07:00:02 | *** | Saving seen data "./dancer.seen" |
| 07:24:03 | | Join DMJC [0] (~James@220-245-162-47-sa-nt.tpgi.com.au) |
| 07:28:10 | | Join Strath [0] (~mike@dgvlwinas01pool0-a239.wi.tds.net) |
| 07:42:09 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 07:42:43 | | Quit StrathAFK (Read error: 110 (Connection timed out)) |
| 07:44:29 | rasher | Morning |
| 07:45:08 | LinusN | morning |
| 07:59:50 | dwihno | good morning people. |
| 08:00 |
| 08:28:46 | | Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) |
| 09:00 |
| 09:00:05 | *** | Saving seen data "./dancer.seen" |
| 09:00:35 | | Join Sando [0] (kekekek@CPE-147-10-21-132.vic.bigpond.net.au) |
| 09:07:39 | | Nick Lynx_awy is now known as Lynx_ (HydraIRC@134.95.189.59) |
| 09:20:14 | | Join cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 09:26:25 | | Join Schnueff [0] (~mah@134.96.247.237) |
| 09:30:03 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 09:31:25 | | Join Zagor [242] (foobar@h254n2fls31o265.telia.com) |
| 09:31:35 | Zagor | morning |
| 09:32:17 | midk | hey |
| 10:00 |
| 10:25:42 | | Part Lurkski |
| 10:34:48 | | Join Renko [0] (~Renko@host81-152-87-173.range81-152.btcentralplus.com) |
| 10:42:35 | | Join Patr3ck [0] (~patr3ck@p548CB368.dip.t-dialin.net) |
| 10:49:59 | | Join webguest02 [0] (~c31ce021@labb.contactor.se) |
| 10:52:37 | LinusN | wee, moving selected portions of libmad code and data (and the main stack) to internal RAM boosted the 140MHz performance from 40% to 65% |
| 10:53:21 | LinusN | 140MHz FLAC is now at 111% :-) |
| 10:53:59 | dwihno | Yay! |
| 10:54:01 | LinusN | the stack in internal RAM gives a nice boost |
| 10:54:28 | LinusN | bad news is that 140MHz seems to overheat the cpu when the disk is spinning a lot |
| 10:54:56 | dwihno | :( |
| 10:55:01 | dwihno | That's bad news |
| 10:55:11 | Zagor | is anyone on the mad-dev list? |
| 10:55:36 | Renko | ach we can just strap on some watercooling ;) |
| 10:56:42 | Zagor | it appears rob leslie is pretty quick at answering questions there |
| 11:00 |
| 11:00:07 | *** | Saving seen data "./dancer.seen" |
| 11:02:10 | Zagor | "It runs on my wimpy 50 MHz MPC860 PowerPC, uses about 80% of the CPU". is ppc really that much faster per clock? are we getting killed by our slow memory/no data cache? |
| 11:02:25 | | Join jyp [0] (~jp@243-108.245.81.adsl.skynet.be) |
| 11:03:57 | amiconn | I just had an idea. There is a port of libmad to the Amiga (m68k!) which obviously is optimised, because it runs at ~125% realtime on an 68060/50. As it is a port of libmad, it comes with sources. Maybe this helps to optimise the coldfire version... ftp://de.aminet.net/pub/aminet/util/libs/mpega_libmad.lha |
| 11:04:47 | Zagor | definitely worth looking at |
| 11:05:45 | Zagor | wow, it was a long time since I ran lha last :) |
| 11:06:42 | LinusN | those were the days |
| 11:07:21 | Lynx_ | LinusN: do you know if the battery consumption is a lot higher with the cpu at 140? |
| 11:07:41 | LinusN | from what i have read, not a lot |
| 11:08:10 | amiconn | LinusN: How come the cpu can be overheated... this is called *cold*fire, right? ;-) |
| 11:08:20 | LinusN | :-) |
| 11:12:07 | Zagor | oddly enough, i can't see any optimisations in that code. very little changes overall. |
| 11:15:36 | Zagor | the only substantial change is the addition of synth_quart() in synt.c |
| 11:17:34 | amiconn | Hmm. synth_quart() is only for full compatibility to original mpega.library, which can render pcm output at full, half, or quarter frequency |
| 11:17:37 | LinusN | synth.c is the main cpu hog |
| 11:18:02 | dwihno | replace it with techno.c and it will be much better ;) |
| 11:18:14 | amiconn | That is necessary to achieve realtime on slower cpus than 68060 |
| 11:19:25 | Zagor | the only assembler change is a miniscule adjustment to fixed.h: |
| 11:19:31 | Zagor | @@ -380,8 +380,7 @@ |
| 11:19:31 | Zagor | "adde %1,%4,%5" \ |
| 11:19:31 | Zagor | : "=r" (lo), "=r" (hi) \ |
| 11:19:31 | Zagor | : "%r" (lo), "r" (__lo), \ |
| 11:19:31 | Zagor | - "%r" (hi), "r" (__hi) \ |
| 11:19:31 | Zagor | - : "xer"); \ |
| 11:19:33 | | Join Aison [0] (~hans@zux166-181.adsl.green.ch) |
| 11:19:33 | Zagor | + "%r" (hi), "r" (__hi)); \ |
| 11:19:34 | LinusN | putting the huffman tables in iram gives us 68% real time |
| 11:20:11 | amiconn | So if there are no significant optimisations in it, this means 68060 @50 MHz is actually faster than coldfire @140 MHz. That puzzles me, despite the fact that 68060 doubles the clock internally. |
| 11:21:05 | LinusN | the 68060 has a data cache, for starters |
| 11:22:08 | amiconn | Yes it has. Hmm, it is also superscalar... I can try this evening and check how mpega_libmad performs with superscalar & data cache disabled. |
| 11:26:36 | amiconn | Zagor: This change is for PowerPC... but then I can find no asm optimisation for 68k in this file... |
| 11:28:02 | amiconn | How large is the coldfire's icache? |
| 11:28:50 | LinusN | 8k |
| 11:29:25 | | Join webguest99 [0] (~50cb3bd2@labb.contactor.se) |
| 11:40:37 | | Join preglow [0] (thomj@s183a.studby.ntnu.no) |
| 11:41:49 | preglow | long until these changes are cvs, linus? |
| 11:42:21 | LinusN | they are just experiments |
| 11:42:41 | LinusN | quick hacks |
| 11:42:47 | preglow | ok |
| 11:43:37 | preglow | i've done a full emac optimize of synth_full (not dct) in OPT_DSO mode that didn't look like it made much difference |
| 11:44:08 | LinusN | nice |
| 11:44:21 | LinusN | io think it will, combined with my optimizations |
| 11:44:26 | preglow | perhaps |
| 11:44:26 | | Quit webguest99 ("CGI:IRC (Ping timeout)") |
| 11:45:02 | preglow | all it does in OPT_DSO mode is really to remove the explicit adds, and move half of the moves into the mac operation |
| 11:45:40 | preglow | and OPT_DSO is default if you've got no processor specific mac macro support in fixed.h |
| 11:46:55 | LinusN | care to send me your changes? |
| 11:47:04 | preglow | sure, gimme a sec |
| 11:47:23 | * | LinusN is cooling down his iriver with his frozen lunch |
| 11:47:56 | dwihno | frozen lunch? didn't you bring the sauerkraut I made specially for you? :( |
| 11:47:58 | preglow | does it get really hot?= |
| 11:47:59 | dwihno | :) |
| 11:48:33 | preglow | LinusN: http://glow.m0f0.net/rockbox/synth.c |
| 11:48:51 | preglow | LinusN: really just an experiment on my part as well, i'm not that familiar with what's efficient on a coldfire |
| 11:49:48 | preglow | clobbering all the data registers might not be that clever in a loop, on second thought |
| 11:50:26 | LinusN | :-) |
| 11:50:46 | LinusN | objdump is your friend |
| 11:51:05 | preglow | yeah, i know, i just haven't got that version compiled right now |
| 11:51:13 | preglow | and now: shower |
| 11:53:47 | preglow | and if you can think of a way to do that parallel move and allow the mac stuff to be macros, please tell me ;) |
| 11:59:21 | LinusN | speed record! |
| 11:59:47 | LinusN | 95%!!!! |
| 11:59:54 | dwihno | Almost there... :) |
| 12:00 |
| 12:02:53 | LinusN | and it still sounds excellent |
| 12:03:17 | dwihno | you got sound on target? |
| 12:03:33 | LinusN | no, i play the .wav file with the iriver firmware |
| 12:04:08 | preglow | what codec? |
| 12:04:31 | LinusN | mad |
| 12:04:36 | preglow | the opt helped?? |
| 12:04:40 | LinusN | indeed |
| 12:04:42 | preglow | haha |
| 12:04:42 | preglow | great |
| 12:04:54 | LinusN | from 68% to 95% |
| 12:04:57 | preglow | ahahaha |
| 12:05:07 | preglow | doing dct should help as well |
| 12:05:08 | dwihno | :) |
| 12:05:09 | preglow | well ok |
| 12:05:20 | preglow | getting this baby realtime should be possible then |
| 12:05:25 | preglow | lots more to optimize |
| 12:05:27 | LinusN | the low memory bandwidth is our biggest enemy |
| 12:05:52 | preglow | yes, i figured as much |
| 12:06:05 | LinusN | just moving the stack to iram made the flac go 111% |
| 12:06:30 | preglow | how large can the stack grow? |
| 12:06:45 | LinusN | it is 32k now |
| 12:07:53 | preglow | ouch |
| 12:08:16 | LinusN | but we only use 25% |
| 12:08:34 | preglow | but btw, is there a penalty to pay on accesses if you keep them close together? |
| 12:09:09 | LinusN | guess so, if they are in SDRAM |
| 12:09:26 | preglow | that's what i meant, yes |
| 12:09:51 | | Join ripnetuk [0] (~george@82-70-100-230.dsl.in-addr.zen.co.uk) |
| 12:09:52 | preglow | i do a move.m before all the macs so i wouldn't have to keep accessing memory in different places |
| 12:10:13 | ripnetuk | 95% :) |
| 12:10:57 | preglow | but does the cpu go very hot? |
| 12:11:04 | LinusN | preglow: looks like it's the other way around |
| 12:11:21 | LinusN | keep the dram accesses close and sequential |
| 12:11:28 | LinusN | hmmm |
| 12:11:45 | LinusN | maye i could tweak the dram controller a little |
| 12:13:23 | jyp | Question; is there a method to flush a file being written to ? |
| 12:13:33 | jyp | does flush_cache do it ? |
| 12:13:52 | jyp | fsync ? |
| 12:14:23 | LinusN | fsync |
| 12:14:35 | jyp | thanks |
| 12:14:50 | LinusN | preglow: it apparently goes too hot in 140MHz if the disk is spinning a lot |
| 12:15:54 | ripnetuk | how do you know the temprature? does it have a built in measurement, or does it throw an exception if it gets too hot? |
| 12:16:12 | LinusN | preglow: we might gain speed if we do dram fetches with movem, and i enable Page Mode in the dram controller |
| 12:16:12 | ashridah | you can use SMART ata commands to get the temp iirc |
| 12:16:57 | LinusN | ripnetuk: it is my guess, since it crashes when it's warm |
| 12:17:11 | | Join Tang [0] (~chatzilla@ARennes-252-1-29-52.w83-195.abo.wanadoo.fr) |
| 12:17:17 | ripnetuk | i see |
| 12:18:49 | LinusN | we will need a lot more that 100% from the codecs, to allow for the rest of rockbox to run during the decoding... |
| 12:19:20 | Tang | Hi all :) |
| 12:19:21 | LinusN | s/that/than/ |
| 12:19:24 | LinusN | hi Tang |
| 12:19:27 | Tang | Hi Linus |
| 12:19:28 | dwihno | Bonjour Tang |
| 12:19:29 | Tang | :) |
| 12:19:39 | Tang | lol bonjour thanks |
| 12:19:48 | LinusN | ca va? |
| 12:20:12 | Tang | eh eh your frnech is fluent lol |
| 12:20:19 | Tang | ca va merci |
| 12:20:20 | Tang | :) |
| 12:20:34 | Tang | with my new remote life is cooler... ;) |
| 12:20:49 | LinusN | ah, nice for you |
| 12:21:00 | Tang | Thanks :) |
| 12:21:00 | dwihno | Une baguette pour moi, s'il vous plait |
| 12:21:03 | preglow | but yes, beating 100% should be ok |
| 12:21:09 | preglow | lots to be optimized in libmad yet |
| 12:21:16 | LinusN | good |
| 12:21:51 | Tang | ROFL you've remebered the essential things dwhino |
| 12:21:53 | Tang | ;) |
| 12:22:09 | LinusN | and it's nice that flac is >100% now |
| 12:22:20 | preglow | yes |
| 12:22:48 | preglow | i'll hack my lpc routine to do orders higher than 8 as well |
| 12:23:11 | preglow | and maybe rewrite the whole thing in asm |
| 12:23:16 | dwihno | Tang: c'est va bien :) |
| 12:23:39 | LinusN | dwihno: ? |
| 12:23:46 | dwihno | I'd love to see how far the optimizations can go |
| 12:23:48 | LinusN | that didn't quite make sense |
| 12:23:55 | dwihno | tres bien dårå :) |
| 12:24:15 | preglow | that's got to be wrong |
| 12:25:26 | Tang | :) |
| 12:26:26 | preglow | LinusN: would enabling page mode hurt other code much? |
| 12:26:31 | Tang | About the latests progress of the sound output |
| 12:26:38 | LinusN | preglow: no |
| 12:26:40 | Tang | "( plays samples with original quality)" |
| 12:26:55 | Tang | does it mean wave is played even if not in real time? |
| 12:27:06 | Tang | Or i misenderstood again? |
| 12:27:27 | preglow | Tang: it plays things you throw at it and it sounds like it should |
| 12:27:49 | preglow | Tang: the realtime problem comes with the codecs, not the sound output driver |
| 12:27:59 | Tang | Ah oaky :) |
| 12:28:04 | Tang | thanks for the explanation |
| 12:28:08 | Tang | :) |
| 12:28:16 | preglow | haha, no problem |
| 12:32:21 | Tang | It's very nice from you |
| 12:32:24 | LinusN | preglow: the clobbering of all the registers doesn't seem to matter much |
| 12:33:12 | preglow | great |
| 12:33:23 | preglow | as long as there's enough for a loop index and a couple of address registers |
| 12:35:11 | | Nick QT_ is now known as QT (as@area51.users.madwifi) |
| 12:40:35 | LinusN | dct32 is a nasty blob of code |
| 12:41:47 | preglow | yes, i know |
| 12:42:04 | preglow | i plan to unleash mighty asm blocks on it later |
| 12:42:20 | LinusN | sounds comforting :-) |
| 12:42:44 | LinusN | lunch time |
| 12:43:38 | preglow | agreed |
| 12:44:55 | Tang | good lunch |
| 12:44:56 | Tang | :) |
| 12:47:21 | Tang | lunch for me too bye all :) |
| 12:57:33 | Marco | Tang, I think you wanted talk to me ! |
| 12:59:30 | | Join hw1979 [0] (~hw1979@221.216.15.41) |
| 13:00 |
| 13:00:08 | *** | Saving seen data "./dancer.seen" |
| 13:00:39 | hw1979 | does rockbox supports creative jukebox Zen player? |
| 13:00:49 | HCl | no. |
| 13:00:55 | HCl | goodmorning |
| 13:01:50 | hw1979 | morning |
| 13:09:08 | * | HCl scratches his head |
| 13:09:15 | HCl | can anyone tell me why memory accesses are so slow? |
| 13:09:21 | | Join shx [0] (~a4810127@labb.contactor.se) |
| 13:10:59 | | Join XShocK [0] (~XShocK@pcp09492659pcs.nrockv01.md.comcast.net) |
| 13:12:11 | LinusN | XShocK: hi |
| 13:12:17 | XShocK | hi |
| 13:12:25 | LinusN | HCl: because it's sdram |
| 13:12:53 | HCl | mk.. |
| 13:13:05 | midk | who make xchat go boop. |
| 13:13:14 | preglow | sdram _is_ slow |
| 13:13:23 | preglow | want to see how good a modern x86 does without its cache? :P |
| 13:13:29 | LinusN | HCl: the external bus is half the frequency of the cpu |
| 13:13:43 | LinusN | and an sdram access takes 5 of those |
| 13:13:50 | LinusN | cycles |
| 13:13:53 | dwihno | preglow: disabling the cache is funny :) |
| 13:14:01 | ashridah | preglow: no thanks. i used a celeron back when they were produced with no onboard cache |
| 13:14:04 | * | ashridah shudders |
| 13:14:05 | preglow | dwihno: yes, and not something you do twice |
| 13:14:17 | | Join Patr3ck_ [0] (~patr3ck@pD9ECFFCE.dip.t-dialin.net) |
| 13:14:30 | LinusN | and the coldfire doesn't have a data cache |
| 13:14:31 | ashridah | then they put cache on die, and the celerons were suddenly better performers than the supposedly better performing pII's :) |
| 13:14:42 | * | ashridah hands intel a cookie |
| 13:14:47 | LinusN | only instruction cache |
| 13:14:50 | preglow | LinusN: well, iram pretty much is user selectable data cache, heh |
| 13:14:55 | dwihno | preglow: heh, true, true |
| 13:14:55 | LinusN | yeah |
| 13:15:09 | preglow | it doesn't get much better than single cycle |
| 13:15:45 | LinusN | so a random sdram access takes 10(!) cpu cycles |
| 13:15:52 | XShocK | when should sound changes be commited to cvs? |
| 13:15:53 | preglow | nasty |
| 13:15:58 | LinusN | XShocK: asap |
| 13:16:24 | XShocK | ok |
| 13:16:36 | LinusN | XShocK: can you explain why you had problems running dma from sdram? |
| 13:19:10 | XShocK | hubble said that it was glitching, i run his version, it was really glitching. Then he left, and I did everything in SRAM 4kb, everything wrked perfectly |
| 13:19:30 | XShocK | I will check my sdram version now |
| 13:19:51 | LinusN | having the pcm buffer in sram is very much unwanted |
| 13:20:18 | XShocK | i am also thinking that |
| 13:20:57 | LinusN | i'd like to play with your code |
| 13:21:24 | XShocK | ok. will compile for non SRAM, test, and send you |
| 13:22:15 | LinusN | no, i'd like the source code |
| 13:22:51 | XShocK | yes, i was talking about sorces. :) |
| 13:23:04 | LinusN | ok, my mistake |
| 13:27:06 | | Quit hw1979 (Read error: 104 (Connection reset by peer)) |
| 13:28:01 | XShocK | naybe email is better |
| 13:30:28 | LinusN | linus at haxx.se |
| 13:30:36 | | Quit Patr3ck (Read error: 110 (Connection timed out)) |
| 13:33:18 | XShocK | it plays samples 44.1khz 16-bit stereo |
| 13:33:57 | Patr3ck_ | must the function wake_up_thread() always be called at the end of an interrupt handler? |
| 13:37:46 | jyp | no |
| 13:38:17 | jyp | only if a thread has to be awaken |
| 13:38:55 | Patr3ck_ | TIMER0 interrupt handler always calls wake_up_thread() |
| 13:39:39 | jyp | because a thread may be sleeping for x ticks |
| 13:40:02 | jyp | when the timer expires it has to be awaken |
| 13:40:09 | Patr3ck_ | I see |
| 13:40:14 | Patr3ck_ | thanks |
| 13:40:16 | jyp | np |
| 13:43:26 | | Quit Marco (Read error: 110 (Connection timed out)) |
| 13:51:01 | | Quit Andrew179 ("Chatzilla 0.9.67 [Firefox 1.0+/20050223]") |
| 13:55:53 | Tang | Arf i missed Marco... :( |
| 13:58:54 | preglow | my god, untangling dct32 to use mac efficiently will be a nightmare :/ |
| 13:59:04 | LinusN | absolutely |
| 13:59:21 | preglow | it uses temp variables, and i will have to keep those in the accumulators |
| 13:59:31 | LinusN | have fun! :-) |
| 13:59:32 | preglow | and preferably in asm, to utilize the parallel load |
| 13:59:43 | preglow | hahah |
| 13:59:44 | preglow | i shall try |
| 14:00 |
| 14:02:08 | Tang | Finally the CPU still run at 11MHz for now no? |
| 14:02:36 | preglow | in cvs, yes, but linus has got it running full speed |
| 14:02:53 | ripnetuk | did Linus ever work out what was causing the ATA to fail at high speed? |
| 14:02:58 | Tang | Ah very interesting |
| 14:02:59 | LinusN | yes |
| 14:02:59 | Tang | :) |
| 14:03:06 | Tang | Bravo Linus |
| 14:03:09 | Tang | :) |
| 14:03:19 | ripnetuk | what was it? |
| 14:03:38 | LinusN | well, it looks like the cpu gets overheated at 140MHz when the hard drive is spinning a lot |
| 14:03:47 | ripnetuk | (all this techy stuff is possibly more satisfying that actually having rockbox on my iRiver :) |
| 14:04:06 | ripnetuk | so no major design fault on the iRiver then... thats good |
| 14:04:18 | Tang | So i imagine even with iRiver fw the CPU run underclocked? |
| 14:04:38 | preglow | ripnetuk: you wouldn't call overheating coldfire a major design flaw? ;) |
| 14:04:55 | Tang | Seems to be |
| 14:04:57 | preglow | not much to be done about it, granted |
| 14:05:11 | LinusN | Tang: from what i have heard, it is max 96MHz with the iriver fw |
| 14:05:38 | Tang | maybe it explaine what i encountereed one day after many fw upgrade when changing my logos |
| 14:05:45 | Tang | linusN thanks :) |
| 14:05:48 | ripnetuk | well... its only a design flaw if something that could be done free (ie, extra connection from coldfire -> ata controll) has not been done. |
| 14:06:04 | ripnetuk | If iRiver can get mp3 decoiding at real time without having to have a HUGE heat sync, then power to them |
| 14:06:14 | ripnetuk | (but not quite as many watts of power as Rockbox :) |
| 14:07:21 | ripnetuk | at least the extra heat will prevent the LCD from slowing down any more - it snowed in London yesterday, and the remote LCD was well sluggish |
| 14:07:23 | ripnetuk | :) |
| 14:08:36 | XShocK | -) |
| 14:08:43 | preglow | i presume i can assume we have at least gcc 3.1? |
| 14:09:13 | preglow | ripnetuk: it's areound -15 C here now, imagine how it performs outside |
| 14:10:12 | CoCoLUS | mornin |
| 14:10:26 | Tang | mornin Coco |
| 14:10:38 | Tang | (not morning here however) |
| 14:11:48 | | Quit webguest02 ("CGI:IRC (EOF)") |
| 14:11:59 | HCl | Tang: what did you encounter when changing logos? |
| 14:12:27 | Tang | in fact was strange |
| 14:12:31 | Tang | i did many chage |
| 14:12:47 | Tang | and once when i did my fw upgrade (to change logos) |
| 14:13:11 | Tang | the LCD displayed a truncated image of the logo |
| 14:13:26 | Tang | i was quite afraid |
| 14:13:37 | HCl | mhm |
| 14:13:43 | Tang | so i didn't started my iHP immediatly |
| 14:13:50 | Tang | i waited a little bit |
| 14:13:50 | preglow | LinusN: will a simple thing like using one movem instead of two move.ls be faster? |
| 14:14:02 | Tang | and then when i turn it on again |
| 14:14:08 | Tang | thje logo was normal |
| 14:14:16 | Tang | and everything was OK |
| 14:14:16 | LinusN | preglow: yes |
| 14:15:56 | | Join ze__ [0] (ze@adsl-69-231-195-207.dsl.irvnca.pacbell.net) |
| 14:16:04 | HCl | strange |
| 14:17:27 | Tang | indeed |
| 14:17:34 | Tang | but since this strange bug |
| 14:17:42 | Tang | some month go |
| 14:17:54 | Tang | i didn't encountered any issue |
| 14:18:31 | Tang | and i did may upgrade for change logo some days ago with the IGCv2.0 release... ;) |
| 14:19:38 | | Nick Strath is now known as StrathAFK (~mike@dgvlwinas01pool0-a239.wi.tds.net) |
| 14:20:34 | preglow | argh, all this bloody register allocation is why we have compilers, goddamnit |
| 14:21:04 | LinusN | so patch the compiler then :-) |
| 14:22:07 | | Join Wizerl [0] (~merlin@dsl-082-083-245-033.arcor-ip.net) |
| 14:25:00 | preglow | hmm |
| 14:25:01 | preglow | heh |
| 14:26:42 | | Quit ze (Read error: 110 (Connection timed out)) |
| 14:26:42 | | Nick ze__ is now known as ze (ze@adsl-69-231-195-207.dsl.irvnca.pacbell.net) |
| 14:30:48 | preglow | seems libmad make is still broken |
| 14:30:59 | LinusN | how? |
| 14:31:05 | preglow | if i change something, make doesn't care |
| 14:31:15 | LinusN | that's true |
| 14:33:50 | | Join linuxstb [0] (~linuxstb@host213-123-154-169.in-addr.btopenworld.com) |
| 14:35:16 | preglow | linuxstb: seen the good news? my synth.c opt really worked well |
| 14:35:31 | | Part XShocK |
| 14:35:34 | | Join XShocK [0] (~XShocK@pcp09492659pcs.nrockv01.md.comcast.net) |
| 14:37:30 | linuxstb | preglow: I didn't see your synth.c optimisation, but I saw Linus's work on rearranging the memory usage. I'm very happy that FLAC is now > 100%. |
| 14:37:49 | preglow | linuxstb: libmad is 95% realtime now |
| 14:38:25 | * | linuxstb is very happy |
| 14:38:29 | XShocK | wow... didn't realize that it is progressing so fast.. :) |
| 14:38:39 | preglow | the synth_full opt i did the other day that i claimed didn't work at all, really shaved nearly 30% off |
| 14:38:53 | CoCoLUS | whats the vorbis status? |
| 14:38:57 | linuxstb | Congratulations. Are there any other areas that you think will gain us more speed? |
| 14:39:08 | preglow | linuxstb: i'm working on another one as we speak |
| 14:39:40 | linuxstb | Did I read correctly that the iRiver firmware runs the iRiver at 96MHz |
| 14:40:02 | preglow | don't know, linus mentioned he heard so |
| 14:41:37 | linuxstb | From what Linus said about the overheating at 140MHz, it seems that we can't run the iRiver at that speed, at least not for long periods? |
| 14:41:49 | LinusN | seems so |
| 14:42:18 | CoCoLUS | at how many procent is the ogg codec now? |
| 14:42:24 | CoCoLUS | eh percent |
| 14:42:34 | LinusN | don't know |
| 14:42:43 | CoCoLUS | guess? :) |
| 14:43:17 | | Join Chamois [0] (~3e234217@labb.contactor.se) |
| 14:44:01 | preglow | CoCoLUS: not much |
| 14:44:16 | preglow | CoCoLUS: round 4.5 with speed optimizations |
| 14:44:25 | CoCoLUS | :/ |
| 14:44:25 | Chamois | preglow : libmad is 95% realtime with wich CPU speed ? |
| 14:44:31 | preglow | Chamois: 140mhz :P |
| 14:44:45 | CoCoLUS | is there really that much difference btw mad/vorbis/flac? |
| 14:45:00 | preglow | well, not that much between mad/vorbis, i believe |
| 14:45:06 | preglow | but flac is much easier to decode |
| 14:45:36 | linuxstb | Has anyone tested libmad with different bitrates and layer2/layer3 files? It would be good to know if the speed varies very much with the input bitrate. |
| 14:46:10 | dwihno | LinusN: test libmad with starka såsen |
| 14:46:18 | dwihno | it's a good test tune |
| 14:46:21 | CoCoLUS | are these libmad changes in the cvs yet? |
| 14:46:26 | LinusN | no |
| 14:46:33 | linuxstb | Also, I'm assuming that's a 44.1KHz test file, a 48KHz file would obviously be about 10% slower. |
| 14:46:36 | LinusN | gotta run |
| 14:46:41 | | Part LinusN |
| 14:47:45 | Tang | hi chamois |
| 14:47:50 | Tang | (j y vais par contre) |
| 14:47:52 | Tang | +++ |
| 14:47:58 | Tang | Cheers evryone :) |
| 14:48:22 | CoCoLUS | well i guess then i can't help with testing decoding speeds |
| 14:48:23 | | Quit Tang ("Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041108]") |
| 14:49:05 | linuxstb | It would be nice to get a test suite of audio files in the different codec formats - I'll try and set something up. I can download some recordings from www.archive.org (e.g. a "taper-friendly" band like the Grateful Dead that allows online sharing of recordings). |
| 14:49:58 | preglow | yes |
| 14:50:01 | preglow | that would be good |
| 14:50:10 | | Quit edx (Read error: 60 (Operation timed out)) |
| 14:50:49 | | Join R3nTiL [0] (~zorroz@83.69.98.135) |
| 15:00 |
| 15:00:09 | *** | Saving seen data "./dancer.seen" |
| 15:02:53 | | Join R3nTiL_ [0] (~zorroz@83.69.98.116) |
| 15:03:04 | | Quit R3nTiL (Read error: 54 (Connection reset by peer)) |
| 15:03:56 | | Join lolo-laptop [0] (~lostlogic@68.251.84.226) |
| 15:07:29 | preglow | ok |
| 15:07:38 | preglow | it looks like mpa2wav makes broken wavs here |
| 15:07:42 | preglow | anyone else got this? |
| 15:08:48 | linuxstb | Last time I tested it, it worked. |
| 15:09:26 | preglow | i checked out of cvs right now, and it makes a wav file 44 bytes big |
| 15:09:31 | preglow | i'm testing flac2wav now |
| 15:10:01 | linuxstb | 44 bytes is just the WAV header - no data. |
| 15:10:08 | preglow | yes, i know |
| 15:10:39 | preglow | and the screen isn't redrawn correctly after the new splash now |
| 15:10:41 | ashridah | flac2wav just dies after reading a chunk of data here. |
| 15:10:47 | ashridah | could be the largish flac file i have tho |
| 15:11:06 | preglow | flac decodes correctly |
| 15:11:07 | preglow | hm |
| 15:11:29 | preglow | curse me for a fool! |
| 15:11:41 | preglow | again i have to ask you to disregard me |
| 15:11:49 | * | linuxstb disregards preglow |
| 15:12:35 | linuxstb | ashridah: flac2wav does seem to fail sometimes on large files. |
| 15:12:46 | linuxstb | I'm not sure why, but haven't really investigated it. |
| 15:19:02 | preglow | does CONFIG_CPU and those defines get passed to everything? |
| 15:27:24 | | Quit R3nTiL_ () |
| 15:27:30 | lolo-laptop | Noticed that tremor was switched to LOW_ACCURACY in rockbox CVS −− maybe something like this that another embeded team did would make more sense: |
| 15:27:41 | lolo-laptop | set the maximum bitrate used by the "high accuracy" decoder. Otherwise the "low accuracy" decoder will be used. 275000 is the default value. |
| 15:29:28 | linuxstb | I haven't really looked at Tremor, so can't comment - markun is the person working with Tremor. I think it all depends on what the optimisations can achieve - as far as I know, nothing has been done to that decoder yet. |
| 15:31:04 | linuxstb | But I'm curious - which other embedded team are you talking about? |
| 15:32:47 | lolo-laptop | something called phatbox |
| 15:32:51 | ashridah | linuxstb: switching the termor code to define LOW_ACCURACY during compile pushed performance from 0.09 to 2-3% realtime :) |
| 15:33:01 | lolo-laptop | http://phatbox.sixpak.org/phatbox/ogg.phtml |
| 15:33:22 | lolo-laptop | 2-3%!? :-( |
| 15:33:29 | lolo-laptop | at what clock speed? |
| 15:33:35 | | Quit Sando (Read error: 104 (Connection reset by peer)) |
| 15:33:39 | jyp | 1THz |
| 15:33:42 | jyp | :P |
| 15:34:29 | * | jyp ninja-flips back |
| 15:34:56 | ashridah | lolo-laptop: it needs work, clearly. |
| 15:35:01 | lolo-laptop | ashridah: nod |
| 15:35:09 | ashridah | even in the simulator, on a 2GHz machine it goes at about 20-30% realtime. |
| 15:35:17 | ashridah | the simulator, oddly, does a *lot* of sleeping |
| 15:35:31 | ashridah | which is surprising, since no-one seems to be suggesting the simulator is attempting to show realtime actions |
| 15:35:43 | lolo-laptop | strange indeed |
| 15:36:22 | lolo-laptop | bad high precision integer dependencies stalling it or something? Is the coldfire even pipelined beyond 2 stages? |
| 15:36:57 | preglow | no, nothling that, i think, probably just a ton of 32x32 bit multiplies |
| 15:37:04 | preglow | libmad is also very slow |
| 15:37:08 | lolo-laptop | *twitch* nod |
| 15:38:25 | | Join markun [0] (~markun@bastards.student.utwente.nl) |
| 15:39:12 | ashridah | speak of the devil |
| 15:39:16 | markun | linuxstb: Did you see what we did wrong with _LOW_ACCURACY_ all the time? Just forgot to include config.h somewhere.. |
| 15:39:49 | | Quit ashridah ("sleep") |
| 15:42:49 | markun | preglow: I emailed one of the guys who optimized the tremor mdct using fft if he could send me a patch, but I'm not counting on anything. |
| 15:43:14 | markun | Would you like to take a look at it if you're finished with the other codecs? |
| 15:46:39 | markun | lolo-laptop: In misc.h in the Tremor dir is says _LOW_ACCURACY_ is just for using 32-bit multiplies instead of 64-bit. |
| 15:46:50 | lolo-laptop | markun: ahh, OK |
| 15:47:27 | markun | vorbis now decodes at 4.26% (used to be 0.9%) |
| 15:47:44 | dwihno | 4.26% (?!) |
| 15:47:47 | dwihno | that's slow |
| 15:47:51 | dwihno | :) |
| 15:48:00 | rasher | better than 0.9 :) |
| 15:48:06 | rasher | A vast improvement actually |
| 15:48:17 | markun | Maybe Linux could test it at 140MHz. |
| 15:48:21 | markun | Linus :) |
| 15:48:52 | linuxstb | markun: I'm not really planning to look inside the codecs too much - other people are doing that. There seems to be a need for someone to work on the new audio framework itself, so that's what I'm going to be concentrating on. |
| 15:49:08 | preglow | linuxstb: good |
| 15:49:17 | preglow | that's what's needed most right now |
| 15:49:51 | linuxstb | It's less interesting from a "hacker's" point of view, but needs to be done. |
| 15:50:35 | preglow | indeed |
| 15:50:51 | preglow | especially since sound ouput is more or less done |
| 15:51:22 | linuxstb | Everything seems to be in place for audio playback, apart from the 'easy" task of bolting everything together. |
| 15:53:26 | markun | Do we want a better malloc, of rather no malloc at all? I was looking at some ideas from Doug Lea's malloc: http://gee.cs.oswego.edu/dl/html/malloc.html |
| 15:53:47 | | Join Daddynik82gr [0] (daddynik@212.251.78.163) |
| 15:54:18 | | Part Daddynik82gr |
| 15:55:46 | linuxstb | markun: I know Bagder said he had a malloc implementation "ready" to plug into Rockbox if we needed it - I don't know any details though. Ideally we don't want malloc, but I don't think anyone is against it in principle - if it proves to be useful. |
| 15:56:45 | linuxstb | e.g. the idea of a "codec malloc" was suggested for use only by the codecs - not by the rest of Rockbox. |
| 15:58:16 | markun | linuxstb: vorbis2wav is also byteswapping in the simulator. Don't know why #if BYTE_ORDER == BIG_ENDIAN doesn't work.. |
| 15:59:48 | markun | hm.. I think it should work now because we include config.h in os_types.h.. |
| 16:00 |
| 16:03:34 | markun | yes, it works now. |
| 16:16:18 | | Part Wizerl ("Kopete 0.9.2 : http://kopete.kde.org") |
| 16:24:32 | | Join methangas [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk) |
| 16:36:01 | | Join stevenm [0] (~stevenm@stevenm-router.student.umd.edu) |
| 16:36:45 | stevenm | Hello |
| 16:37:34 | stevenm | preglow, I wrote that GUS parser.. very basic stage but it loads all the samples from the file and can play them correctly |
| 16:38:52 | preglow | stevenm: great |
| 16:39:07 | preglow | now for finding the envelope info, heh |
| 16:39:22 | stevenm | yea |
| 16:39:45 | stevenm | it was annoying because the doc specified fields as bytes, words, dwords.. then it just goes, 'Integer' |
| 16:40:34 | stevenm | just thought i'd tell you that |
| 16:40:56 | stevenm | envelope is an array of 6 bytes. there are 2 of them.. envelope 'sweep' and 'offset' |
| 16:41:41 | stevenm | whatever that means |
| 16:42:37 | preglow | haha |
| 16:42:40 | preglow | i have no idea |
| 16:42:51 | | Join dropandho [0] (~a@h-67-100-106-171.nycmny83.covad.net) |
| 16:42:59 | dropandho | hey all! |
| 16:43:29 | dropandho | long time listener....1st time caller |
| 16:44:12 | stevenm | hello |
| 16:44:16 | dropandho | hey |
| 16:44:31 | stevenm | what's up? |
| 16:44:42 | dropandho | is the "todays log" weird on the wiki? |
| 16:44:50 | dropandho | not too much here |
| 16:44:51 | dropandho | u? |
| 16:45:05 | Zagor | the recent changes? |
| 16:45:15 | dropandho | the irc logs |
| 16:45:20 | dropandho | for "todays log" |
| 16:45:33 | Zagor | looks good to me |
| 16:45:42 | Zagor | 16.44.42 # <dropandho> is the "todays log" weird on the wiki? |
| 16:45:42 | dropandho | it doesn't load up in the browser anymore |
| 16:45:49 | dropandho | hehe |
| 16:46:16 | dropandho | in firefox it prompts you to save the txt file...and not just load it in the browser |
| 16:46:20 | dropandho | weird |
| 16:46:35 | Zagor | yeah, i get that too now. hmm, i wonder what's changed. |
| 16:46:48 | dropandho | yeah |
| 16:47:09 | dropandho | according to the wiki it hasnt changed in a few days |
| 16:47:20 | dropandho | it started sometime last night (usa eastern time) |
| 16:48:00 | | Quit ripnetuk (Remote closed the connection) |
| 16:48:07 | Zagor | the wiki changelog doesn't cover all pages on the web site, only those under the /twiki directory |
| 16:48:15 | dropandho | gotcha |
| 16:48:35 | dropandho | that makes sense...as it auto-populates |
| 16:48:44 | stevenm | anyways, i'm off to get food. goodbye people |
| 16:48:46 | preglow | my god |
| 16:48:50 | preglow | i am not man enough for the gcc source code |
| 16:48:51 | dropandho | take care! |
| 16:48:58 | | Part stevenm ("breakfast") |
| 16:48:59 | dropandho | u can do it! |
| 16:50:24 | dropandho | Zagor...thanks for looking into it....i follow the logs everyday....so i am missing it! |
| 16:51:56 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 16:52:13 | | Join einhirn [0] (Miranda@bsod.rz.tu-clausthal.de) |
| 16:52:40 | Zagor | hmm, doesn't mozilla use some silly algorithm to try and discern of a plain/text document is really plaintext? i bet it decides our log is binary. |
| 16:55:46 | rasher | Which dates? |
| 16:55:52 | Zagor | yup, that was it. stripped out a few ^O and now it works. |
| 16:56:16 | rasher | how silly |
| 16:56:19 | Zagor | very |
| 16:58:02 | | Quit Chamois ("CGI:IRC") |
| 16:58:23 | preglow | Zagor: mozilla primarily relies on mime types, afaik |
| 16:59:35 | Zagor | you'd think so, yes. but it also does idiotic text analysis and decides sometimes mime type text/plain isn't really plain and thus hardcodes a save dialog instead of what the user wants to do. |
| 17:00 |
| 17:00:12 | *** | Saving seen data "./dancer.seen" |
| 17:03:42 | | Join mecraw [0] (~mecraw@69.2.235.2) |
| 17:04:50 | preglow | does it? |
| 17:04:56 | preglow | never experienced that |
| 17:05:04 | preglow | i thought that was more internet explorer's domain ;) |
| 17:05:26 | Zagor | yeah. i don't know why they do it. |
| 17:05:49 | preglow | so, any gcc hackers here that want to make emac intrinsics support for me? |
| 17:07:09 | Zagor | :) |
| 17:18:27 | linuxstb | Zagor: I haven't got time to talk about the details ATM, but was wondering what your plans (if any) were for the new audio playback system in Rockbox - is it one of your priorities? |
| 17:20:36 | | Quit XShocK (Read error: 104 (Connection reset by peer)) |
| 17:20:37 | | Join Marco [0] (~Azureus@bzq-165-126.dsl.bezeqint.net) |
| 17:22:04 | Zagor | yes it is. i had hoped to start writing the buffering code this week, but unfortunately some real world events interfered and took away much of my time. |
| 17:24:18 | linuxstb | Is there anything specific I can do to help? Real Work has got in the way the last few days, but hopefully I can work on it this weekend. |
| 17:26:19 | | Join zezayer [0] (~zezayer@host81-152-218-69.range81-152.btcentralplus.com) |
| 17:29:58 | Zagor | i don't know. it's not yet completely structured in my head. |
| 17:31:57 | HCl | good |
| 17:32:04 | HCl | my dynarec successfully returned after the call |
| 17:34:00 | linuxstb | I'm happy to continue work on the codec parts - i.e. implementing the "wrappers" arround the codec libraries. But I'm not sure how much work that will be - hopefully not very much. |
| 17:35:02 | linuxstb | The harder part would be the dynamic loading of codec plugins - but I'm guessing a lot of that can be stolen from the existing plugin code. |
| 17:35:33 | Zagor | you could perhaps go ahead the codec api and loader, possibly by extending apps/plugin.c |
| 17:38:24 | | Join XShocK [0] (~XShocK@pcp09492659pcs.nrockv01.md.comcast.net) |
| 17:42:38 | linuxstb | OK. What I'll probably do (hopefully this evening) is update the Wiki based on what we talked about the other day. We can then chat again and hopefully finalise the API. I'll then start implementing it. |
| 17:42:51 | | Quit Renko (Remote closed the connection) |
| 17:44:42 | | Join hubble [0] (hubble@h13n1fls302o1033.telia.com) |
| 17:55:57 | | Quit Schnueff ("bald wech") |
| 18:00 |
| 18:00:14 | | Quit Patr3ck_ () |
| 18:04:17 | Zagor | linuxstb: sounds good. i'll be away now for the evening. |
| 18:12:49 | | Quit zezayer (Read error: 110 (Connection timed out)) |
| 18:13:03 | | Quit jyp (Read error: 110 (Connection timed out)) |
| 18:15:54 | | Join zezayer [0] (~zezayer@host81-152-218-69.range81-152.btcentralplus.com) |
| 18:16:21 | | Join BoD[] [0] (~BoD@JRAF.org) |
| 18:16:25 | BoD[] | heyyy |
| 18:16:40 | BoD[] | so |
| 18:16:51 | BoD[] | I was planning on buying an iRiver |
| 18:17:13 | BoD[] | is rockbox planned on a i3xx ? |
| 18:17:28 | BoD[] | i mean H3xx |
| 18:18:23 | preglow | it might very well happen |
| 18:18:28 | preglow | but no guarantees |
| 18:18:36 | | Join Sucka [0] (~NNSCRIPT@host81-156-213-142.range81-156.btcentralplus.com) |
| 18:18:44 | | Quit einhirn (Read error: 104 (Connection reset by peer)) |
| 18:18:51 | BoD[] | it seems that there are some good progress on the H1xx |
| 18:19:08 | BoD[] | but I really need the usb host features of the 3xx :) |
| 18:19:23 | preglow | well, if there's a datasheet on the host component, it should be doable |
| 18:19:38 | BoD[] | great |
| 18:20:07 | BoD[] | and then rockbox will rox my world again :) |
| 18:20:21 | BoD[] | (i'm a former archos owner) |
| 18:20:34 | | Quit linuxstb (Read error: 110 (Connection timed out)) |
| 18:31:09 | | Join Diway [0] (~diway@82.226.26.23) |
| 18:36:31 | BoD[] | anyway :) I'll be back ! |
| 18:36:53 | | Quit BoD[] ("m!") |
| 18:37:52 | | Join edx [0] (edx@pD9EAB23B.dip.t-dialin.net) |
| 18:42:34 | | Quit edx (Client Quit) |
| 18:49:36 | | Join edx [0] (edx@pD9EAB23B.dip.t-dialin.net) |
| 18:52:23 | | Join webguest43 [0] (~8f416314@labb.contactor.se) |
| 18:54:20 | webguest43 | Hi ! For some odd reason the "current log" link on the IRC webpage does not open in my browser any more, instead wants do download the file. Something wrong at my end ? |
| 18:59:46 | Lynx_ | i think that's being worked on... |
| 19:00 |
| 19:00:15 | *** | Saving seen data "./dancer.seen" |
| 19:00:23 | Lynx_ | try a different browser, maybe |
| 19:01:34 | webguest43 | thanks |
| 19:01:36 | | Quit webguest43 ("CGI:IRC") |
| 19:03:24 | | Join einhirn [0] (Miranda@carlsberg.heim2.tu-clausthal.de) |
| 19:05:51 | | Quit zezayer ("ChatZilla 0.9.61 [Mozilla rv:1.7.2/20040804]") |
| 19:08:36 | | Nick Lynx_ is now known as Lynx_awy (HydraIRC@134.95.189.59) |
| 19:14:36 | | Join Stryke` [0] (~Chairman8@resnet-241-86.resnet.UMBC.EDU) |
| 19:23:15 | einhirn | Hi Guys! |
| 19:25:11 | einhirn | Sorry if this is a FAQ, but is there a Guide to (trying to) fix the GND-Problem? My Recorder sometimes just stops playback (Plays, then Silence, then a bit more sound, then Stop, sometimes even Shutdown.) even though there should be Battery left... |
| 19:26:33 | einhirn | I think I just found it myself. Thanks though! |
| 19:30:06 | | Join jyp [0] (~jp@243-108.245.81.adsl.skynet.be) |
| 19:30:37 | preglow | i take it the coldfire doesn't have a cycle counter? |
| 19:45:59 | | Quit jyp ("poof!") |
| 19:48:09 | einhirn | So, I found the Problem: The Batteries I used are some (about 1,5 or so) mm too high. All Solder Joints to the Case are broken at least on one side of the board... Is there any way to get the batteries to fit in (other than buying new, AA-Conforming Batteries?) |
| 19:50:02 | einhirn | Also the PCB is slightly bent out where the Batteries were seated... Quite freaky... |
| 19:57:40 | amiconn | The bending is quite common, since the board isn't thick, and the springs are quite tight. |
| 19:59:14 | einhirn | amiconn: So I shouldn't care much about that? I am just resoldering the Joints in the Place they are now (a little bit further apart - I hope that it does the trick... |
| 20:00 |
| 20:00:52 | amiconn | Just try that. Btw, I wonder whether your batteries are really a bit too long. Maybe you only get the impression that they're too long by the tight fit |
| 20:01:05 | amiconn | Did you compare with other AA-sized batteries? |
| 20:01:42 | einhirn | I compared with the Cells that were in it when I bought it. Green-Shrinkwrapped |
| 20:01:42 | einhirn | 1500mAh-Cells... |
| 20:02:21 | amiconn | Hmm, strange. AA batteries that violate the specs.. |
| 20:03:25 | amiconn | I have the opposite problem with the rechargeable AAA cells I bought for my Ondio. They are a bit shorter than the usual non-rechargeable, so they wiggle a bit and fall out quite easily when I open the battery cover |
| 20:08:44 | einhirn | Well, that may be fixable easily... just add some kind of spacer between the cells if needed. But I can't cut off pieces of my Batteries (well, I can, but then they wouln't work anymore...) |
| 20:11:33 | einhirn | I am Tempted to remove the Springs, because of the bending PCB... It looks as if it was going to break... |
| 20:11:48 | | Quit ze ("new drives") |
| 20:23:56 | | Join DrRick [0] (DrRick@81-86-225-245.dsl.pipex.com) |
| 20:28:54 | preglow | anyone skilled in 68k addressing here? :V |
| 20:52:27 | | Quit DrRick () |
| 20:56:46 | amall | WE should make a rockbox for gmini 400 |
| 20:58:58 | einhirn | Hey, who needs exchangeable batteries anyway ;) I just removed those annoying Springs and soldered the Batteries in... |
| 21:00 |
| 21:00:18 | *** | Saving seen data "./dancer.seen" |
| 21:10:49 | amall | ooh |
| 21:14:08 | | Part amall |
| 21:17:12 | einhirn | Hmm... I somehow screwed up... I would get an instant short circuit when putting the other pair of batteries in... |
| 21:17:15 | einhirn | Grrr... |
| 21:33:40 | einhirn | I think I shorted out something on the drive connector side... Will take a closer look there after unmounting the drive... |
| 21:41:57 | einhirn | Hmm... Why the heck... Now I've got to figure out how to solder this without a short-circuit... Both Grounds are connected. But somehow they are connected on the other side too... |
| 21:47:25 | einhirn | Wait. Let me get some sense in what I am talking: There are four Battery contacts. My units keypad is pointing to me. The plus Pole upper left is connected to the metal piece. I think that is the problem... |
| 21:48:10 | einhirn | Because the Metal piece is bridged to the other metal piece on the other side of the unit (by the little pcb on the Keypad end of the unit... |
| 21:48:32 | | Join ze [0] (ze@adsl-69-231-240-42.dsl.irvnca.pacbell.net) |
| 21:54:10 | preglow | like, if i need to access 'myarray[5 - index]', how do i translate that to a m68k address? |
| 21:54:21 | preglow | both myarray and index are in registers |
| 21:59:06 | | Nick StrathAFK is now known as Strath (~mike@dgvlwinas01pool0-a239.wi.tds.net) |
| 22:00 |
| 22:05:56 | | Quit Stryke` ("Friends don't let friends listen to Anti-Flag") |
| 22:33:20 | | Join ashridah [0] (ashridah@220-253-118-134.VIC.netspace.net.au) |
| 22:34:08 | | Join webguest27 [0] (~541b2395@labb.contactor.se) |
| 22:34:26 | | Join jyp [0] (~jp@243-108.245.81.adsl.skynet.be) |
| 22:36:00 | | Nick jyp is now known as MrHankey (~jp@243-108.245.81.adsl.skynet.be) |
| 22:36:05 | | Nick MrHankey is now known as jyp (~jp@243-108.245.81.adsl.skynet.be) |
| 22:48:44 | webguest27 | preglow: You need to NEG index first, and then use Address Register Indirect with Index (8-Bit displacement) Mode |
| 22:49:21 | preglow | ghah |
| 22:49:26 | preglow | i was hoping i didn't have to do that |
| 22:49:30 | webguest27 | preglow: Syntax: (d8, An, Xn.SIZE*SCALE) |
| 22:49:50 | preglow | yes, i've got that, i just thought negative scalers were allowed |
| 22:49:56 | webguest27 | preglow: d8 = displacement : 5 |
| 22:50:24 | webguest27 | preglow: No negative unfortunately |
| 22:50:35 | preglow | ok, back to code, then |
| 22:51:29 | | Quit midk (Read error: 104 (Connection reset by peer)) |
| 22:52:24 | | Quit hubble () |
| 22:53:50 | | Quit webguest27 ("CGI:IRC") |
| 23:00 |
| 23:00:19 | *** | Saving seen data "./dancer.seen" |
| 23:02:04 | einhirn | Maybe I found the problem: I tinned the upper right contact for the plus pole... Maybe I caused the short circuit by letting some tin get into the hole through the PCB. |
| 23:02:12 | einhirn | Could that be? |
| 23:03:36 | einhirn | Err... I'll just go to bed now, cure some of that flu and then sometime get back to work on this nasty problem... ThanksAnyway - further help will be appreciated... |
| 23:06:14 | | Join muesli- [0] (muesli_tv@Bbc9c.b.pppool.de) |
| 23:07:20 | muesli- | high |
| 23:11:18 | HCl | low. |
| 23:14:05 | rasher | hellow |
| 23:15:10 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 23:17:00 | | Join linuxstb [0] (~linuxstb@dsl-212-23-31-215.zen.co.uk) |
| 23:17:43 | | Quit linuxstb (Client Quit) |
| 23:17:51 | muesli- | :) |
| 23:18:43 | muesli- | g'night.. |
| 23:19:30 | HCl | nightnight. |
| 23:21:38 | | Quit mecraw (Connection timed out) |
| 23:22:15 | | Join Patr3ck [0] (~patr3ck@pD9E5CC66.dip.t-dialin.net) |
| 23:23:51 | | Join cYmen_ [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 23:25:01 | | Quit cYmen (Read error: 104 (Connection reset by peer)) |
| 23:30:01 | | Quit muesli- (Read error: 60 (Operation timed out)) |
| 23:30:03 | | Join Renko [0] (~Renko@host81-154-33-142.range81-154.btcentralplus.com) |
| 23:31:01 | | Quit ashridah ("gone") |
| 23:32:21 | preglow | hahah |
| 23:32:33 | preglow | my wonderful code bloody locked my player up |
| 23:34:55 | | Quit Patr3ck () |
| 23:35:13 | HCl | m? |
| 23:37:11 | | Join linuxstb [0] (~linuxstb@dsl-212-23-31-215.zen.co.uk) |
| 23:41:18 | | Join Patr3ck [0] (~patr3ck@pD9E5CC66.dip.t-dialin.net) |
| 23:49:59 | | Quit midk ("Leaving") |
| 23:50:31 | | Quit ze ("last bit of drive-juggling") |
| 23:56:41 | | Quit dropandho () |
| 23:57:16 | | Join ze [0] (ze@adsl-69-231-222-54.dsl.irvnca.pacbell.net) |
| 23:57:37 | preglow | arghh |
icon identifies that the person is a core developer (has commit access).