00:00:01 | amiconn | preglow: You won't get me to buy an ipod ;) |
00:00:22 | linuxstb_ | Buy a H10 then... |
00:00:28 | amiconn | bah |
00:00:30 | linuxstb_ | Even less docs.. |
00:00:36 | amiconn | Yes, exactly |
00:00:42 | mirak | does a function like memcopy is implemented in assembler in gcc according to the target cpu, or does it uses C code ? |
00:00:44 | * | amiconn neeeeds datasheets |
00:01:31 | mirak | tucoz: in Blade Trinity you can see a blind using braille stuffs |
00:01:36 | mirak | that's a reference |
00:01:37 | mirak | lol |
00:01:58 | tucoz | mirak, ok. I have seen them though. Cool device. |
00:02:02 | linuxstb_ | ^BeN^ Which player are you using? |
00:02:24 | mirak | so gcc doesn't support exactly the m5249 |
00:02:33 | markun | amiconn: Gigabeat perhaps? :) |
00:02:35 | mirak | ? |
00:02:39 | ^BeN^ | h3000 |
00:02:41 | ^BeN^ | 3300 |
00:02:42 | ^BeN^ | 300 |
00:02:44 | ^BeN^ | grr |
00:02:52 | amiconn | markun: I don't buy overkill hardware |
00:02:53 | markun | amiconn: I know.. not enough buttons located on the front. |
00:02:57 | amiconn | brb |
00:03:00 | | Quit amiconn (" HydraIRC -> http://www.hydrairc.com <-") |
00:03:02 | markun | Ah yes, too much CPU |
00:03:25 | petur | Can somebody tell me where the audio mux pin is set for the H1xx? |
00:03:41 | tucoz | markun, the gigabeat is so powerful it almost doesn't qualify as a embedded device |
00:04:14 | markun | We can underclock the CPU of course |
00:04:19 | Midgey34 | anyone know what is wrong with this line? if(rb->read(fd, score, sizeof(score)) <= 0) break; |
00:04:19 | Midgey34 | warning: passing arg 2 of pointer to function makes pointer from integer without a cast |
00:04:42 | linuxstb_ | You need to use &score |
00:04:49 | markun | Or maybe have 1 extra CPU boost level :) |
00:05:01 | LinusN | Midgey34: what are you doing? |
00:05:04 | | Quit DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
00:05:05 | tucoz | heeh, like the older 486's. Wasn't the 486sx a 486dx(?) with the fpu disabled. |
00:05:15 | tucoz | and underclocked |
00:05:15 | petur | 486sx |
00:05:39 | Midgey34 | LinusN: I'm working on rockblox using the vertical patch as a base |
00:05:44 | LinusN | petur: the audio mux pin is described in the wiki |
00:05:50 | markun | tucoz: hey, the gigabeat also doesn't have FPU |
00:05:58 | LinusN | Midgey34: there is a highscore api in the plugin library |
00:06:10 | tucoz | markun, grrr. Then it's cool. ;) |
00:06:17 | Midgey34 | ah, I see, I'll look it up |
00:06:24 | LinusN | petur: ah, you mean where in the code? |
00:06:26 | webguest02 | markun: Any idea what to look for in this dir that might cause scrolling to get slow? |
00:06:34 | markun | tucoz: nog even multi processor :) |
00:06:38 | ^BeN^ | Night All |
00:06:59 | tucoz | hehe, that is quite cool. multi-processor mp3-players |
00:07:12 | tucoz | or did you mean not even...? |
00:07:21 | markun | webguest02: can you dump the filenames to a textfile? Then I can recreate the dir and maybe find out what's wrong |
00:07:34 | webguest02 | I have the dir as 0byte files |
00:07:40 | Midgey34 | LinusN: is not using the highscore lib frowned upon? I'm using the code from bejeweled with slight modifications |
00:07:45 | markun | tucoz: only 1 cpu (unlike the ipods) |
00:07:48 | webguest02 | where I have already removed some files, and it still does it |
00:08:01 | webguest02 | I'll zip it up |
00:08:04 | webguest02 | hang on |
00:08:06 | markun | ok |
00:08:14 | tucoz | oh. I am looking forward to see your progress with gigabeat. |
00:08:15 | LinusN | petur: pcm_record.c: pcm_record_mux() |
00:08:28 | markun | tucoz: it will have to wait till next year |
00:08:49 | petur | yuck. what is it doing there? |
00:08:51 | LinusN | Midgey34: not frowned upon, but we would appreciate if the plugins could use the same code |
00:09:00 | Midgey34 | alright |
00:09:04 | linuxstb_ | markun: That's only 18 days away... |
00:09:08 | LinusN | Midgey34: however, no plugin uses it, afaik |
00:09:12 | tucoz | markun, that is soon |
00:09:16 | markun | :) |
00:09:17 | tucoz | :) |
00:09:26 | petur | and why is there fmradio.c and fmradio_i2c.c :( |
00:09:38 | LinusN | Midgey34: so you are free to redesign it to your liking and make both bejeweled and rockblox use it |
00:09:53 | petur | I would have expected stuff like enabling radio (switching mux pin) in fmradio.c |
00:10:02 | LinusN | petur: because different platforms use different fm chips |
00:10:12 | petur | that I can understand |
00:10:14 | LinusN | petur: historical reasons, mostly |
00:10:21 | | Join amiconn [0] (n=jens@p54BD4683.dip.t-dialin.net) |
00:10:34 | petur | may as well clean up a bit then... |
00:10:34 | LinusN | petur: the mux isn't necessarily a radio function |
00:11:10 | LinusN | the mux controls what audio source is routed to the ADC |
00:11:19 | tucoz | markun, still, do you like the gigabeat as it is though? It looks very neat. |
00:11:27 | petur | ah - only for recording then |
00:11:28 | LinusN | in this case it's radio or line in |
00:11:46 | petur | so for radio playback, I don't have to switch anything |
00:11:54 | LinusN | for recording and also radio playback, since we rerout the ADC right to the DAC |
00:12:16 | LinusN | yes, you need to set the ADC source to radio |
00:12:25 | petur | great... |
00:12:34 | markun | tucoz: yes, I like it. I made some screenshots of a movie and viewed them on the Gigabeat, looked very nice. |
00:12:54 | | Quit Kohlrabi ("Leaving") |
00:13:04 | petur | well if it's ok for you I'll take some more time and try to clean it up a bit |
00:13:14 | LinusN | what needs cleaning up? |
00:13:27 | tucoz | markun, the resolution of the screen is very nice. Especially that it has a standard aspect-ratio. |
00:13:35 | petur | fmradio.c and fmradio_i2c.c ? |
00:13:37 | tucoz | ...when tilted that is |
00:14:13 | markun | tucoz: The X30 has a nicer screen, but the internals are almost the same, so I think it will not difficult to support it as well. |
00:14:39 | LinusN | petur: fmradio.c is for the archos fm recorder, which talks SPI with the chip |
00:14:42 | tucoz | markun, doesn't yours have 240x320 resolution? |
00:14:59 | LinusN | petur: and fmradio_i2c.c is for the archos ondio and the iriver |
00:15:05 | LinusN | which talk i2c |
00:15:09 | | Join ehntoo [0] (n=ehntoo@24-177-166-0.dhcp.mrqt.mi.charter.com) |
00:15:10 | markun | yes, but it's 2.2" and not 2.4 |
00:15:17 | tucoz | I see. |
00:15:34 | petur | I saw that, but it's not very clear... |
00:15:48 | tucoz | have you recieved the source code yet? |
00:15:57 | markun | no, still not |
00:16:03 | LinusN | petur: no it isn't 100% clear |
00:16:06 | webguest02 | markun: http://www.badongo.com/file.php?file=problematic+files__2005-12-13_Problematic.zip&s= |
00:16:12 | LinusN | petur: what do you suggest? |
00:16:12 | webguest02 | I believe that should work |
00:16:29 | petur | it could use something like the lcd-xxx file naming but that would be overkill |
00:16:35 | petur | need to think about it |
00:17:47 | markun | petur: file renaming is not nice with cvs. Wait till we switch over to svn |
00:18:02 | petur | ok |
00:18:30 | webguest02 | markun: And please no comments on the music taste! |
00:18:38 | | Quit Moos ("Glory to Rockbox") |
00:18:58 | markun | :) |
00:19:05 | petur | I'll first try to get radio working, then make a common I2C bitbanger. |
00:20:03 | markun | webguest02: yes, it lags here too |
00:20:27 | webguest02 | Ah, well that's at least something |
00:20:53 | webguest02 | I'm slowly trying to remove files with suspicious names |
00:23:58 | LinusN | petur: good |
00:24:04 | webguest02 | down to 94 files now. Still lagging. |
00:25:09 | petur | port pins adjusted, probably need to enable radio functionality for H300 somewhere and then read the RB manual how to operate it :D |
00:26:32 | webguest02 | 24 files. Still lagging. |
00:27:29 | Midgey34 | while I'm here, are there any changes or suggestion people have for the Sokoban patch I wrote the other day? |
00:27:29 | Midgey34 | http://sourceforge.net/tracker/index.php?func=detail&aid=1378064&group_id=44306&atid=439120 |
00:30:43 | petur | uh-oh - adding radio will screw up my settings |
00:30:47 | | Quit ReKleSS (kornbluth.freenode.net irc.freenode.net) |
00:30:47 | NSplit | kornbluth.freenode.net irc.freenode.net |
00:30:59 | petur | enabling the define adds them somewhere in the middle :( |
00:31:50 | petur | hehe, seems I need to define some buttons first too |
00:33:15 | linuxstb_ | petur: You can use the same button definitions as the H100 - just do || CONFIG_KEYPAD == IRIVER_H300_PAD |
00:33:37 | petur | already busy ;) |
00:33:59 | | Nick webguest02 is now known as JackP (n=3e4f4094@labb.contactor.se) |
00:41:27 | petur | I get the feeling that code dealing with buttons will need some reworking - many #ifdefs in there |
00:41:39 | petur | many targets... |
00:45:04 | | Part tucoz ("Leaving") |
00:46:38 | NHeal | kornbluth.freenode.net irc.freenode.net |
00:46:38 | NJoin | ReKleSS [0] (n=ReKleSS@c220-237-136-11.mckinn1.vic.optusnet.com.au) |
00:49:02 | petur | damn... won't boot (shows only RB logo) |
00:49:11 | petur | Could it be the settings change? |
00:49:25 | LinusN | petur: maybe |
00:49:32 | petur | will bump my version number |
00:49:33 | LinusN | hold rec when you boot next time |
00:49:46 | petur | that should stop it from trying to load |
00:49:49 | | Join nathanh [0] (n=cb1a1042@labb.contactor.se) |
00:50:00 | petur | I can't get that trick to work |
00:50:00 | LinusN | petur: that resets the settings, yes |
00:50:18 | petur | I tried it yesterday for my brightness thing |
00:50:28 | petur | when exactly should I start holding REC? |
00:52:07 | JackP | Before the logo comes on, I think |
00:52:50 | petur | that's what I tried: as soon as the bootloader start printing... |
00:53:34 | petur | right, any quick hints where the settings version number is defined... |
00:54:27 | nathanh | petur: h300? hold rec while its off, then hold play while still holding rec until iriver has booted |
00:54:28 | petur | is it CONFIG_BLOCK_VERSION? |
00:55:01 | petur | nathanh: don't want to boor iRiver :D want to reset my settings ... |
00:55:09 | petur | (boot) |
00:55:48 | nathanh | yeah, ive lost all interest in booting iriver too :-) |
00:56:06 | petur | except for recording and usbhost! |
00:56:18 | petur | And I need those damn things |
00:57:47 | petur | damn cygwin is slow :( |
01:00 |
01:01:27 | | Quit ender` (" Oh, I'm also going to hunt you down in real life, break all your fingers and both your wrists, smash your computer, and cut ) |
01:01:36 | petur | changed CONFIG_BLOCK_VERSION, still no boot. Let's try without radio... |
01:01:48 | mirak | there is only 96kB of fast ram ? |
01:04:36 | mirak | LinusN: how much is it faster to move some data to fast ram, then do the computing on it, move it back to slow ram, instead of just computing in the slow ram ? |
01:04:54 | mirak | I mean in your experience for what kind of computing it's worse |
01:04:57 | mirak | worth |
01:07:49 | linuxstb | mirak: It will obviously depend on how much that memory is accessed. But the slow ram is very slow. Also, codecs and plugins only have 48kb of iram - the rest is used by other parts of Rockbox. |
01:08:22 | mirak | because since a frame is bigger alone than the iram |
01:08:45 | mirak | only operations on blocks would have a meaning |
01:08:51 | mirak | to be done in fast ram |
01:08:58 | mirak | (still on xvid) |
01:09:09 | mirak | I have not abandonned yet |
01:09:12 | mirak | :) |
01:09:13 | | Part Sando |
01:10:07 | mirak | linuxstb: so for a full image, you need to pass each blocks for each type of frame (Y,U,V) |
01:10:16 | linuxstb | This is the kind of optimisation you can experiment with when you get it working. Don't forget that if you want audio with your video, then the audio codecs will also be fighting for iram - they will struggle without it. |
01:10:17 | mirak | from slow ram to iram |
01:10:28 | mirak | lol |
01:10:37 | linuxstb | It's not going to be easy... |
01:10:42 | mirak | nope |
01:10:59 | mirak | iriver took almost 2 years to achieve that, if not more |
01:11:18 | mirak | the video codec appeared on later firmwares |
01:11:22 | petur | great... if I build with radio it doesn't boot. If I remove radio, everythings OK :( |
01:11:43 | mirak | they probably also stripped to death the code but you need to know what you are doing to do that |
01:11:49 | LinusN | petur: so there's obviously something wrong with the radio |
01:11:55 | petur | step one: enable radio, do not touch mux |
01:11:58 | LinusN | petur: enable the logf function |
01:12:07 | petur | ah, where's that? |
01:12:20 | mirak | linuxstb: when a codec alone have a binary bigger than iram, how do you proceed ? |
01:12:31 | LinusN | when you run configure, select "developer" and then logf |
01:12:48 | LinusN | you will then see logf() messages on the remote lcd |
01:12:50 | linuxstb | mirak: You specify which functions and which data structures are in iram. The rest are in sdram. |
01:13:10 | petur | remote lcd? don't have a remote.... |
01:13:11 | linuxstb | Only one or two audio codecs are small enough to fit entirely in iram. |
01:14:03 | mirak | linuxstb: so in general is it faster to move the code to iram dynamically ? |
01:14:20 | mirak | I guess rockbox doesn't do that |
01:14:28 | nathanh | woo, new cvs doesnt flicker, what was the fix? |
01:14:31 | mirak | that's a bit hard to do probablt |
01:14:34 | *** | Saving seen data "./dancer.seen" |
01:14:47 | linuxstb | We've never tried moving code to iram. You generally get much better improvements using the iram for data - the Coldfire has a code cache, but no data cache (IIUC) |
01:15:04 | petur | _FireFly_ made a ticking patch that solved the flickering :D |
01:15:22 | nathanh | gah? |
01:15:27 | mirak | LinusN: ok thanks, I understand better now |
01:15:29 | linuxstb | (I mean we've never tried dynamically moving code to iram) |
01:15:44 | petur | (only update the LCD in one place) |
01:15:48 | nathanh | oh right |
01:16:17 | mirak | linuxstb: so in average it's less a waste to move the data. I don't realise how fast it is to move data from slow ram to iram |
01:17:04 | petur | LinusN: logf only goes to the LCD of the remote? Just checking... because then it's useless for me. |
01:17:23 | mirak | linuxstb: you will need to write your own compilator to do that |
01:17:27 | LinusN | petur: it is also stored in ram, so you can view it and save it to disk in the debug menu |
01:17:29 | mirak | no ? |
01:17:45 | linuxstb | You mean to move code in and out of iram? |
01:17:47 | petur | helps a lot if it doesn't boot :( |
01:17:55 | mirak | linuxstb: yes |
01:18:08 | linuxstb | No, I'm sure there are tricks to make that possible. |
01:19:15 | mirak | linuxstb: by moving the code of the size of the struct of the function into iram then using |
01:19:33 | mirak | the variable that point to that iram place |
01:20:19 | mirak | seems doable like that as far as I have understand what it's possible to do with C |
01:21:01 | amiconn | I doubt that moving code will give any speed improvement, I'd expect the opposite |
01:21:28 | mirak | amiconn: for code that acces to slow ram or iram data ? |
01:21:40 | amiconn | _any_ code |
01:22:03 | mirak | what lead you to that conclusion ? (just want to learn more) |
01:22:06 | amiconn | (1) While moving, the code is treated as data, so there is no caching |
01:22:20 | amiconn | (2) After moving, you have to invalidate the icache |
01:22:32 | mirak | why 2 ? |
01:22:52 | mirak | invalidate what ? |
01:23:09 | amiconn | (2) The coldfire has icache, so every code snippet that's run more than once would be cached with high probability |
01:23:17 | amiconn | icache == instruction cache |
01:23:42 | amiconn | The last (2) should have been (3) |
01:24:16 | mirak | how does the cpu knows it doing the instruction set more than once ? |
01:24:40 | mirak | how does the cpu knows he is running a particular instruction block more than once ? |
01:25:04 | mirak | well nevermind that's to complicated |
01:25:18 | amiconn | It doesn't know beforehand |
01:25:18 | LinusN | mirak: google for "cpu cache" |
01:25:50 | amiconn | It just caches the code it executes, and if it's executed a second time while still in the cache, executes it from there |
01:27:07 | nathanh | mirak: you'll need to understand the cache to get video playback |
01:27:24 | petur | LinusN: still won't boot without touching the mux pin, so it must be the I2C |
01:27:31 | LinusN | ok |
01:28:05 | LinusN | i had the same strange hang when i tried to enable recording |
01:28:26 | mirak | amiconn: I understand the concept, but was wondering how he was knowing he was about to run the same code again to run it inside the cache and not the ram |
01:28:31 | petur | will continue tomorrow. You need the changes I made? |
01:28:41 | petur | guess not |
01:28:42 | | Join Paul_The_Nerd [0] (n=paulthen@cpe-66-68-93-2.austin.res.rr.com) |
01:28:49 | LinusN | petur: would be nice to see them |
01:29:03 | mirak | amiconn: but well that's not necessary to understand how to use it |
01:29:08 | petur | will dump it on the mailing list |
01:29:19 | LinusN | petur: or to me |
01:29:27 | petur | even better |
01:29:36 | LinusN | mailing list is probably better |
01:29:40 | LinusN | never mnind |
01:29:52 | LinusN | linus at haxx dot se |
01:29:52 | petur | beware - they probably have bad line endings ;) |
01:29:57 | LinusN | haha |
01:30:07 | petur | sorry, W2K user |
01:30:13 | amiconn | petur: Get a decent editor ;) |
01:30:17 | petur | like? |
01:30:20 | LinusN | emacs |
01:30:26 | petur | ^%#^%* |
01:30:29 | amiconn | ConTEXT (my favourite on windows) |
01:30:37 | mirak | amiconn: in fact I was wondering that in case the code in ram was modified, but I just read that's a nono ro do that now |
01:30:44 | petur | using M$ devstudio atm |
01:30:55 | mirak | to/ro |
01:31:18 | amiconn | mirak: That's what I meant with (2). There is no bus snooping, so the CPU doesn't know the RAM contents has changed |
01:31:38 | mirak | amiconn: ah ok |
01:31:39 | mirak | :) |
01:32:02 | nathanh | emacs is pretty good, now if only it had a decent text editor |
01:32:31 | mirak | nathanh: eclipse is not bad with DCT. |
01:32:53 | mirak | if you disable indexing |
01:35:53 | | Quit nathanh ("CGI:IRC (EOF)") |
01:36:24 | | Join nathanh [0] (n=cb1a1042@labb.contactor.se) |
01:39:13 | petur | LinusN: mail is on its way |
01:39:34 | petur | Doesn't the bitbanging suffer from CPU freq changes? |
01:40:07 | petur | I mean that delay loop is freq dependent, no? |
01:42:27 | | Part Midgey34 |
01:43:25 | | Quit novimon_ (Read error: 104 (Connection reset by peer)) |
01:44:23 | | Join mind_less [0] (n=Tim@209.51.83.226) |
01:45:26 | LinusN | petur: yes |
01:46:25 | petur | right now I'm not sure anymore what code gets used: fmradio or fmradio_i2c |
01:46:38 | petur | but that will be for tomorrow |
01:47:17 | petur | goodnight |
01:47:31 | | Quit petur ("here today, gone tomorrow") |
01:47:55 | | Join novimon [0] (n=novimon@a84-230-230-239.elisa-laajakaista.fi) |
01:47:59 | | Quit Rick (Read error: 104 (Connection reset by peer)) |
01:49:04 | | Join Rick [0] (n=rick@pool-71-108-9-40.lsanca.dsl-w.verizon.net) |
01:57:11 | | Quit Paul_The_Nerd ("Chatzilla 0.9.68.5.1 [Firefox 1.5/undefined]") |
01:59:23 | nathanh | just a few 100 bytes)? |
01:59:35 | | Quit dpassen1 () |
01:59:44 | nathanh | blah, stupid irc client... i can appreciate that rtc is limited to 44 bytes, but why is hd_bits limited to just a few 100 bytes? |
02:00 |
02:05:30 | | Quit XavierGr (Read error: 104 (Connection reset by peer)) |
02:07:53 | linuxstb | nathanh: Because it is stored in a sector on the disk. But there is talk of changing that. |
02:08:01 | LinusN | the config sector is 512 bytes |
02:08:23 | nathanh | oh right, so its currently not a file, its an actual sector |
02:08:28 | nathanh | the intention is to make it a file? |
02:08:35 | LinusN | but that sector doesn't only contain settings, it also contains the resume info |
02:14:39 | nathanh | right, so theres config bits in rtc ram and in a single disk sector |
02:15:04 | nathanh | there are also per-app settings stored in files, each app using its own read/write and parsing routines |
02:16:58 | LinusN | nathanh: "app"? |
02:17:04 | nathanh | .rock files |
02:17:05 | nathanh | plugins |
02:20:17 | | Quit Febs ("CGI:IRC") |
02:22:55 | | Quit Rob2222 () |
02:26:28 | JackP | DNS is so annoying. Forums still not working |
02:26:30 | LinusN | wee, h300 lcd dma works! :-) |
02:27:53 | amiconn | Hmm. Is using DMA faster/ as fast as a line-read-optimised CPU transfer would be? |
02:28:33 | amiconn | Oh, btw, what was the problem? |
02:28:50 | LinusN | the usual stuff, unclear data sheets :-) |
02:29:23 | LinusN | the DONE bit had to be manually reset between transfers |
02:32:12 | LinusN | the sad part is that a line-optimized cpu transfer would be too fast for the lcd |
02:32:49 | LinusN | the dma can do line optimized transfers, but it is too fast at 124mhz |
02:33:16 | PaulJ | JackP: add the line "72.29.70.124 forums.rockbox.org" to your HOSTS file |
02:33:28 | LinusN | and it's the time between transfers that is the problem, so increasing the waitstates doesn't help |
02:37:46 | JackP | PaulJ: Yeah, I know, just annoys me |
02:38:45 | LinusN | amiconn: a full lcd update takes 6.7ms in 45mhz |
02:39:01 | Weazel_ | forum works here |
02:39:54 | amiconn | LinusN: I mean line-optimised reading from DRAM, then writing to the LCD according to specs (but in the fast mode with multiples of 4 words) |
02:41:54 | | Quit nathanh ("CGI:IRC (EOF)") |
02:43:13 | | Join DJDD_ [0] (n=DJDD@220-245-186-182.static.tpgi.com.au) |
02:43:59 | LinusN | amiconn: it turns out that we can't use the fast ram mode |
02:44:18 | LinusN | because the lcd expects CS to be low during the entire transaction |
02:44:29 | LinusN | 4-word burst |
02:45:10 | amiconn | Oh, and we can't do that? |
02:45:25 | amiconn | (hold CS low I mean) |
02:46:09 | * | amiconn notices there are no H3x0 schematics on the website :( |
02:46:58 | | Quit mikearthur (Read error: 104 (Connection reset by peer)) |
02:47:19 | LinusN | hehe, no, i haven't made any schematics |
02:49:07 | LinusN | amiconn: hmmm, i might be wrong about the cs |
02:52:25 | | Join dropandho [0] (n=dropandh@cpe-24-193-36-91.nyc.res.rr.com) |
02:52:36 | dropandho | hey all! |
02:52:43 | amiconn | Bah, we won't benefit from fast mode at 45 MHz |
02:53:01 | dropandho | Linus- im in forum heaven! |
02:53:29 | | Join Sando [0] (n=lolsteam@techgaming.net) |
02:53:31 | amiconn | Bus cycle time is 88.5 ns, so we need one wait anyway, and then we're at 177ns, for which slow mode is sufficient |
02:54:03 | | Quit linuxstb_ ("CGI:IRC (Ping timeout)") |
02:54:24 | amiconn | >wrong<, try again... |
02:54:50 | amiconn | Bus cyle time is 44.28 ns ... |
02:57:25 | dropandho | linus- im back to bug u! |
03:00 |
03:07:52 | | Join YouCeyE [0] (n=YouCeyE@unaffiliated/youceye) |
03:14:38 | *** | Saving seen data "./dancer.seen" |
03:18:32 | | Join Paul_The_Nerd [0] (n=paulthen@cpe-66-68-93-2.austin.res.rr.com) |
03:24:40 | LinusN | amiconn: lcd_update() takes roughly 26ms in 45mhz and 10ms in 124mhz |
03:26:42 | lostlogic | wow, not much that can be done to optimize that either :( |
03:27:43 | JackP | ouch |
03:27:51 | dropandho | linus my friend! |
03:28:09 | | Join aliask [0] (n=chatzill@c210-49-190-113.eburwd8.vic.optusnet.com.au) |
03:28:26 | dropandho | wonderin if you ended up finding the R20 and R22 components on the ticking unit |
03:29:34 | LinusN | dropandho: i have measured the ticking board, and the isolation between analog and digital ground is not 100% on the ticking board |
03:29:49 | LinusN | i have yet to find out how and why |
03:29:52 | dropandho | got it....i have an odd thought on that one |
03:30:05 | dropandho | got it- thanks for investigating that deeper |
03:30:27 | dropandho | i remember the_winch said that the board was missing R20 and R22....any idea? |
03:30:35 | dropandho | (that is theboard u have) |
03:30:38 | LinusN | not really |
03:30:49 | dropandho | odd |
03:30:59 | dropandho | is he really missing those? |
03:32:30 | LinusN | well, r20 and r22 is missing on my other board as well |
03:32:38 | aliask | Is the bug about rockbox crashing when the "show files" setting in the quickscreen is set to ID3 database known? |
03:32:49 | LinusN | aliask: yes |
03:33:01 | aliask | Goodo then. |
03:33:07 | dropandho | so i wonder if we can find a corolation between these missing spots and the tick |
03:33:52 | LinusN | dropandho: i doubt it |
03:34:24 | dropandho | my non-technical thought was that if it is the interference b/w the analog and the digital ports....maybe there should be a setting to disable the digital when you dont need it...so you can stop the interference...and stop the ticking |
03:35:45 | LinusN | the digital i/o is used to communicate with the remote |
03:36:02 | dropandho | crap! |
03:36:03 | LinusN | it's not the s/pdif, if that's what you're thinking |
03:36:14 | dropandho | yes- that was what i was thinkin |
03:37:07 | dropandho | what a total bummer |
03:38:11 | LinusN | i'm suspecting that it's a problem with the pcb itself |
03:38:29 | dropandho | yeah...nothing that any software can mend |
03:39:14 | dropandho | what did the latest tick-fix add? |
03:39:35 | LinusN | fewer lcd updates |
03:41:02 | dropandho | coo- the usual |
03:41:24 | dropandho | glad people are still working on this! |
03:42:20 | LinusN | gotta get some sleep |
03:42:25 | LinusN | cu tomorrow |
03:42:30 | dropandho | def..night! |
03:42:32 | aliask | G'night! |
03:42:41 | | Part mind_less |
03:42:43 | | Part LinusN |
03:43:38 | | Join amiconn_ [0] (n=jens@p54BD45AD.dip.t-dialin.net) |
03:49:08 | | Quit JackP ("CGI:IRC") |
03:49:42 | dropandho | is it me...or did the forum stop responding? |
03:51:34 | Paul_The_Nerd | It looks like it's working to me... |
03:58:11 | | Join tvelocity [0] (n=tony@84.254.13.74) |
04:00 |
04:00:30 | | Quit amiconn (Read error: 110 (Connection timed out)) |
04:00:31 | | Nick amiconn_ is now known as amiconn (n=jens@p54BD45AD.dip.t-dialin.net) |
04:00:55 | dropandho | weird- broken over here |
04:05:12 | Paul_The_Nerd | It just loves me more than you. |
04:08:45 | dropandho | hehe |
04:52:09 | | Join scott666 [0] (n=18f53a30@labb.contactor.se) |
04:52:52 | | Quit scott666 (Client Quit) |
04:54:31 | | Join scott666 [0] (n=scott666@c-24-245-58-48.hsd1.mn.comcast.net) |
04:58:48 | scott666 | this channel is a lot bigger than i remember it. |
04:58:53 | scott666 | and just as quiet |
04:58:54 | scott666 | heh |
04:59:44 | dropandho | shhh |
04:59:48 | dropandho | this is the study room sir |
04:59:51 | dropandho | please keep it down |
04:59:53 | scott666 | haha |
04:59:57 | dropandho | hehe |
05:00 |
05:00:16 | dropandho | the time difference thing is what keeps em quiet i believe |
05:00:22 | scott666 | yeah |
05:00:37 | scott666 | well, it was quiet most of the time when i was here regularly too |
05:01:02 | dropandho | ahh |
05:01:13 | dropandho | they do get chatty at times |
05:01:13 | scott666 | my arches died a while back |
05:01:27 | dropandho | blah |
05:01:33 | scott666 | so i kinda fell out of the rockbox community |
05:01:40 | dropandho | u get a new dap? |
05:01:46 | | Quit tvelocity (Remote closed the connection) |
05:01:48 | scott666 | looking into that now |
05:02:20 | scott666 | whats this about rockbox on ipods?? |
05:02:29 | | Join tvelocity [0] (n=tony@84.254.13.74) |
05:02:32 | dropandho | yeah, they are working on that |
05:02:36 | dropandho | not sure where it stands tho |
05:02:44 | dropandho | i know that it seems to be comming along tho |
05:03:11 | scott666 | hows the iriver port coming along? |
05:03:25 | dropandho | no official release for the 120/140 |
05:03:36 | dropandho | but it has been solid for many months now |
05:03:42 | dropandho | just cleaning up the loose ends |
05:04:00 | dropandho | the 320/340 just started up maybe a month or 2 ago |
05:04:00 | scott666 | and the 320? not so much? |
05:04:04 | scott666 | ok |
05:04:13 | dropandho | and is rapidly moving along as they can use much of the code base |
05:04:20 | dropandho | i dont know where it stands |
05:04:22 | | Join nathanh [0] (n=ca7d0006@labb.contactor.se) |
05:04:27 | dropandho | but i think it is fairly functional |
05:04:32 | dropandho | i would check out the website |
05:04:39 | dropandho | they have been keeping that up-to-date |
05:05:06 | scott666 | yeah |
05:05:13 | scott666 | i check in about once a month |
05:05:17 | scott666 | i see 1.5 is out |
05:05:18 | scott666 | thats new |
05:05:33 | dropandho | 2.5- ya |
05:05:52 | scott666 | my archos died before 2.4 went official |
05:06:10 | scott666 | so yeah, havnt really been keeping up |
05:06:40 | dropandho | it's a whole new world! |
05:06:47 | scott666 | the only thing i use it for now is a portable HD |
05:06:57 | scott666 | i should load up 2.5 |
05:07:10 | dropandho | the audio jacks die? |
05:08:18 | scott666 | yup |
05:08:22 | scott666 | FMR |
05:09:07 | scott666 | it cna still record too |
05:09:14 | scott666 | but i havnt had need for that lately |
05:12:24 | dropandho | damn- it looks like my forums link is pointing to 66.194.238.140 ...that's the old one- right? |
05:14:40 | *** | Saving seen data "./dancer.seen" |
05:17:29 | PaulJ | the new ip is 72.29.70.124 |
05:20:12 | scott666 | question: whats the difference between rockbox.ucl and rombox.ucl? |
05:20:28 | dropandho | yeah....weird....so i wonder why i am now back to the old one |
05:20:33 | dropandho | it propgated |
05:20:45 | dropandho | already |
05:20:51 | dropandho | do i need to wait again? |
05:21:15 | scott666 | answer: rombox doesn't work. |
05:31:34 | PaulJ | dropandho: you could add the line "72.29.70.124 forums.rockbox.org" to your hosts file |
05:33:14 | | Quit dropandho () |
05:37:10 | | Part PaulJ |
06:00 |
06:01:33 | | Quit DreamTactix291 (Read error: 110 (Connection timed out)) |
06:01:41 | | Join xbshift [0] (i=shift@CPE000c6e94cf09-CM001225d870de.cpe.net.cable.rogers.com) |
06:03:39 | | Quit Strath (Read error: 104 (Connection reset by peer)) |
06:05:08 | | Join Strath [0] (n=mike@dpc674681214.direcpc.com) |
06:08:13 | | Join calbearfan [0] (n=calalum8@c-24-6-162-234.hsd1.ca.comcast.net) |
06:10:21 | calbearfan | Hi, anyone there to answer a question for a new Rockbox user on an iriver H140? |
06:10:31 | nathanh | im around, not sure how much help i can be though |
06:11:02 | scott666 | im also around, but will almost certainly be useless |
06:11:16 | calbearfan | I'm having a problem with several podcasts −− it seems like the gap detection is detecting silence in the middle of a recording and it won't let me play the rest of the podcast. Is this a known issue? |
06:11:37 | calbearfan | When I play using the normal iriver firmware, it plays fine |
06:11:48 | nathanh | dont know about that one |
06:11:52 | nathanh | i wasnt aware there was gap detection either |
06:12:11 | | Join Membrillo [0] (n=sam_kill@CPE-60-229-178-37.nsw.bigpond.net.au) |
06:12:25 | | Join lostlogic_ [0] (n=lostlogi@node-4024215a.mdw.onnet.us.uu.net) |
06:12:30 | calbearfan | for example, all the NPR podcasts have this little tune at the beginning of the podcast, then silence. All the podcasts look like they are 4 seconds long using Rockbox, but several minutes long using the iriver firmware. |
06:13:00 | calbearfan | I just get the tune, then it moves on to the next song. |
06:13:08 | | Join lostlogi1x [0] (n=lostlogi@node-4024215a.mdw.onnet.us.uu.net) |
06:13:08 | *** | Alert Mode level 1 |
06:13:08 | DBUG | Enqueued KICK lostlogicx |
06:13:08 | DBUG | Enqueued KICK lostlogic |
06:13:08 | *** | Alert Mode level 2 |
06:13:08 | DBUG | Enqueued KICK lostlogic_ |
06:13:08 | DBUG | Enqueued KICK lostlogi1x |
06:13:08 | *** | Alert Mode level 3 |
06:13:35 | nathanh | cant help, you'll need to ask one of the devs |
06:13:43 | nathanh | they'll probably get all excited over a bug like that :-) |
06:13:53 | calbearfan | it's very strange, and since it always seems to happen during silence, it seems like it would be some kind of silence detection |
06:14:18 | calbearfan | since iriver isn't officially released, I should use the mailing list? |
06:14:20 | | Join webguest52 [0] (n=3e4f4094@labb.contactor.se) |
06:14:53 | webguest52 | Hi, was reading the logs. As far as I know, there's no silence detection. |
06:15:09 | webguest52 | My guess is that they're doing something funky with the mp3s |
06:15:38 | calbearfan | it's consistent for me. actually, now that I think about it, I think I've only tested with a single podcast in a directory. maybe I'll test a bit more |
06:15:44 | scott666 | yes, use the mailing list |
06:15:54 | webguest52 | or wait around here |
06:17:09 | webguest52 | Do you have an url for these mp3s? |
06:17:27 | calbearfan | that might make sense (something funky with the mp3s). since it is a standard lead-in, they are probably fusing it together with the content, maybe in a nonstandard way. |
06:17:42 | webguest52 | That's what I'm guessing |
06:17:57 | calbearfan | then maybe it wouldn't be silence, just a screwed up portion of the mp3 |
06:18:02 | | Quit NibbIer (Read error: 110 (Connection timed out)) |
06:18:29 | calbearfan | I also can't seek back into the mp3 from the next podcast |
06:19:51 | calbearfan | an NPR feed I have problems with is http://www.npr.org/rss/podcast.php?id=1090&uid=n1qe4e85742c986fdb81d2d38ffa0d5d53 |
06:20:07 | calbearfan | (user-friendly feed name, courtesy of iTunes I imagine) |
06:20:31 | nathanh | i wonder if it is two mp3s |
06:20:46 | nathanh | the little mp3 at the start is all rockbox sees, thinks its 4 seconds long |
06:22:06 | calbearfan | yep, that's probably it. the one I'm currently testing that has problems is from 11/29 (npr_20051129_atc_04) |
06:22:10 | webguest52 | calbearfan: Filesize of 2.2mb sound right? |
06:22:22 | webguest52 | hrm |
06:22:31 | webguest52 | Alright, think I'm getting the latest one |
06:23:09 | *** | Alert Mode OFF |
06:23:47 | calbearfan | I'm going to download that one too and check it out |
06:25:35 | | Join Nibbler [0] (n=sven@e181101211.adsl.alicedsl.de) |
06:26:12 | calbearfan | yep, same problem with the latest (npr_20051212_me_03.mp3) |
06:26:29 | | Quit lostlogic (Nick collision from services.) |
06:26:39 | | Nick lostlogic_ is now known as lostlogic (n=lostlogi@node-4024215a.mdw.onnet.us.uu.net) |
06:26:39 | DBUG | Enqueued KICK lostlogic |
06:27:32 | webguest52 | yeah |
06:27:55 | | Quit lostlogicx (Read error: 110 (Connection timed out)) |
06:28:06 | calbearfan | happened to you too? are you doing it on an iriver, or a different platform? |
06:28:22 | webguest52 | Iriver |
06:29:28 | calbearfan | hey, totally unrelated, what is everyone's favorite theme? any good ones that don't come with the latest builds? |
06:29:54 | nathanh | iAmp |
06:30:11 | webguest52 | I haven't decided on one yet |
06:30:23 | lostlogic | the wps I made :) |
06:30:50 | calbearfan | lostlogic: what's cool about yours? |
06:31:06 | calbearfan | other than it's yours? :) |
06:31:35 | lostlogic | displays complete information (including brief next track info), clean, easy to read, no bitmaps |
06:31:43 | lostlogic | http://misticriver.net/showthread.php?t=32563 <−− last WPS on that thread |
06:31:58 | calbearfan | cool, i'll give it a try. |
06:32:42 | | Quit webguest52 ("CGI:IRC (EOF)") |
06:32:42 | | Quit nathanh ("CGI:IRC (EOF)") |
06:32:57 | calbearfan | anybody have a non-iriver that wants to try to see if an mp3 that is failing on an iriver fails for a different platform? |
06:33:18 | calbearfan | I imagine it should fail on all though |
06:33:57 | scott666 | uhh |
06:34:07 | scott666 | do i have to be able to hear it to know if its failing? |
06:34:52 | | Quit RotAtoR () |
06:35:03 | calbearfan | no. an mp3 that is several minutes long is showing up in rockbox as 4 seconds long. probably because of the way NPR is tacking a standard sound to the beginning of the podcast. |
06:35:26 | calbearfan | in the iriver firmware, it plays fine |
06:35:47 | scott666 | i have an archos FMR with a broken headphone jack |
06:38:09 | calbearfan | using a podcast reader, subscribe to http://www.npr.org/rss/podcast.php?id=1090&uid=n1qe4e85742c986fdb81d2d38ffa0d5d53 then download the only file in the feed |
06:39:08 | calbearfan | looks like the file is http://cdn.npr-podcasts.speedera.net/anon.npr-podcasts/podcast/1090/npr_20051212_me_03.mp3 |
07:00 |
07:08:53 | | Join nathanh [0] (n=ca7d0006@labb.contactor.se) |
07:14:42 | *** | Saving seen data "./dancer.seen" |
07:18:38 | | Quit Membrillo () |
07:19:59 | | Quit Paul_The_Nerd (Excess Flood) |
07:33:10 | | Join perplexity [0] (n=joust@217.165.110.88) |
07:34:17 | | Join mind_less [0] (n=Tim@209.51.83.226) |
07:36:22 | Bger | morning :) |
07:36:50 | scott666 | just barely |
07:36:57 | scott666 | <american |
07:39:36 | dwihno | Wee! Morning! |
07:40:16 | dwihno | only 1h 40 minutes 'til sunrise! |
07:41:06 | scott666 | this channel got a hell of a lot more idlers since iwas here last |
07:41:19 | thegeek_ | only 1h 20m until my exam starts |
07:41:23 | thegeek_ | I'm fucked |
07:41:50 | | Quit nathanh ("CGI:IRC") |
07:41:58 | | Join DreamTactix291 [0] (n=DreamTac@adsl-19-241-33.bna.bellsouth.net) |
07:47:55 | Bger | thegeek_ wish u luck |
07:47:56 | amiconn | linuxstb: Red builds... |
07:49:56 | thegeek_ | hehe, thanks Bger |
07:50:00 | thegeek_ | I need it;) |
07:52:41 | scott666 | is there a 'whats new in 2.5' page somewhere? |
07:53:02 | Bger | there was one anecdote about the fact that the bad student learns only 3 topics of 30 and on the exam the theme is one of the 3, and the good student doesn't learn only 3 topics and on the exam he has one of these 3 |
07:55:04 | thegeek_ | well |
07:55:10 | thegeek_ | in this exam that is certainly true |
07:55:14 | thegeek_ | discrete math |
07:55:26 | thegeek_ | so many different and quite separate subjects |
07:56:31 | Bger | scott666 there was something like "changes done since v 2.4" ... |
07:57:00 | Bger | Bagder ? |
07:57:13 | Bger | scott666 archos user ? |
07:57:35 | | Quit mind_less (Read error: 110 (Connection timed out)) |
08:00 |
08:06:01 | scott666 | i was |
08:06:15 | Bger | This guy Tomasz Malesinski is insane ... to make a emulator alone ... |
08:06:18 | scott666 | and i was still around when 2.4 came out |
08:06:34 | Bger | s/a/an |
08:07:01 | Bger | scott666 if u have cvs u can get all changes yourself |
08:07:50 | scott666 | no, i meant more like a summary |
08:08:10 | Bger | u are asking for archos, aren't u |
08:08:24 | scott666 | or in general |
08:08:32 | scott666 | my archos is deadish |
08:08:36 | Bger | if so, one of the biggest fixes is the RLD bug... |
08:08:42 | | Join webguest71 [0] (n=3e4f4094@labb.contactor.se) |
08:08:43 | scott666 | holy crap! |
08:08:51 | scott666 | thats awesome |
08:08:53 | Bger | general... iriver doesn't have 1 release |
08:09:04 | webguest71 | scott666: http://www.rockbox.org/twiki/bin/view/Main/ChangeLog25 |
08:09:07 | Bger | applauds goes to amiconn :P |
08:09:27 | Bger | s/goes/go |
08:09:31 | webguest71 | and http://www.rockbox.org/twiki/bin/view/Main/ReleaseNotes25 |
08:10:23 | scott666 | thanks |
08:13:01 | | Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) |
08:14:31 | | Quit webguest71 ("CGI:IRC (EOF)") |
08:26:44 | scott666 | another quick question: is there a page comparing the specs of the h1x0 and h3x0 somewhere? |
08:28:10 | | Join mind_less [0] (n=Tim@209.51.83.226) |
08:28:40 | | Join ender` [0] (i=ychat@84.52.165.220) |
08:29:43 | Bger | yep |
08:32:08 | Bger | http://www.rockbox.org/twiki/bin/view/Main/IriverH3XXHardwareComponents |
08:32:34 | Bger | also http://www.rockbox.org/twiki/bin/view/Main/DeviceChart |
08:38:40 | scott666 | so the main differences are the button layout and the LCD? |
08:39:35 | Lost-ash | and usb2go |
08:39:43 | Lost-ash | and the H300 has a built in RTC |
08:39:48 | Lost-ash | and can charge from usb iirc |
08:39:52 | | Nick Lost-ash is now known as ashridah (n=ashridah@69.55.227.55) |
08:39:58 | scott666 | usb2go? |
08:40:25 | ashridah | yeah. basically the device can be a usb host, so it can read files off some digital cameras. |
08:40:33 | scott666 | oh |
08:40:35 | scott666 | i see |
08:40:42 | ashridah | (and pretty much any other usb device, subject to driver support) |
08:40:50 | Bger | yep |
08:41:07 | ashridah | rockbox doesn't have support for it yet, but i imagine someone will be insane enough to try eventually :) |
08:41:14 | scott666 | yeah |
08:41:21 | Ctcp | Ignored 5 channel CTCP requests in 13 minutes and 31 seconds at the last flood |
08:41:21 | * | Bger has insane plans ... |
08:41:45 | scott666 | is the HD upgradable for either? |
08:41:56 | Bger | yes |
08:42:02 | ashridah | not really. |
08:42:07 | scott666 | heh |
08:42:16 | Bger | the 40GB models are upgradable to 60GB atm, but 80GB are coming |
08:42:27 | Bger | and 20GB models are upgradable to 40GB |
08:42:28 | ashridah | not to the degree that one can do it for the archos's, you need special screw drivers |
08:42:32 | scott666 | oh right, they use 1.8" disks |
08:42:32 | ashridah | but it can and has been done |
08:42:49 | scott666 | how special? |
08:43:09 | Bger | scott666 the form factor is more special |
08:43:15 | ashridah | just a set of star screwdrivers. |
08:43:21 | Bger | i mean, this is not the standard laptop 2.5" drive |
08:43:26 | scott666 | yeah |
08:43:28 | ashridah | misticriver.net has info on the procedure iirc |
08:43:40 | scott666 | ok, ill look around there |
08:43:54 | Bger | but the drives are expensive |
08:44:19 | scott666 | yeah |
08:44:37 | scott666 | i should be able to live with 40gb |
08:54:35 | scott666 | right |
08:54:41 | scott666 | so any idea where i can actually buy one? |
08:54:53 | Bger | h300 ? |
08:54:55 | Bger | or h100 ? |
08:55:05 | scott666 | h140 im looking for right now |
08:55:09 | Bger | ebay |
08:55:14 | scott666 | none |
08:55:16 | scott666 | only remotes |
08:57:06 | Bger | advancedmp3players.co.uk ? |
08:58:36 | scott666 | im american |
08:58:52 | * | Bagder listens to the recorded rockbox review at http://www.MosenExplosion.com |
08:59:14 | scott666 | they have the h340 for $475 + international shipping−−not really ideal |
09:00 |
09:02:46 | Bger | hm, i can't help you then... |
09:02:51 | Bger | ask @ MR |
09:03:00 | scott666 | will do |
09:03:07 | preglow | god, how a week of uninterrupted raining puts me in a foul mood |
09:07:24 | scott666 | why does a several year old player cost more than a brand new video ipod? :-/ |
09:07:47 | Bagder | the rockbox effect! ;-) |
09:08:32 | scott666 | that effect being that rockbox only runs on players that have been discontinued? |
09:08:39 | scott666 | :-p |
09:08:43 | Bagder | hehe |
09:09:13 | Bagder | if the ipod dudes are fast enough we might have a short time of actually working on a player that is available |
09:09:45 | preglow | http://www.ohl.to/iriver/tests/ |
09:09:48 | preglow | ehh |
09:09:52 | preglow | sporadic paste |
09:09:57 | preglow | i need to reassign that mousebutton |
09:10:37 | preglow | btw, it seems we might be able to get a port up and running in not too long a time |
09:10:54 | preglow | it seems we'll be able to run adequately on only one cpu |
09:11:03 | Bagder | wow, cool |
09:11:09 | preglow | did a naive test |
09:11:22 | preglow | wav2wv runs at 150% realtime on one 75mhz core |
09:11:29 | preglow | 195% on 120mhz coldfire |
09:11:29 | scott666 | so is the work being done on the video ipods? the daily build page says nano and 'color' |
09:11:45 | Bagder | scott666: no |
09:12:07 | | Part mind_less |
09:12:20 | | Join nathanh [0] (n=cb1a1042@labb.contactor.se) |
09:12:45 | saa[b_r]ider | even the H1x0 has a pricey tag now-a-days |
09:12:56 | scott666 | yeah, tell me about it |
09:12:57 | saa[b_r]ider | maybe higher than the H300 |
09:12:58 | preglow | Bagder: on ipod colour and ipod nano |
09:13:01 | preglow | ehh |
09:13:08 | preglow | scott666: on ipod colour and ipod nano |
09:13:19 | scott666 | whats an ipod color? couple generations back? |
09:13:24 | scott666 | or ipod photo? |
09:13:24 | preglow | one |
09:13:33 | preglow | another name for a photo, or something |
09:13:37 | scott666 | ok |
09:13:40 | preglow | i'm not completely sure |
09:13:50 | preglow | even the ipodlinux guys haven't figured out the video yet |
09:13:56 | preglow | it does some things quite differently |
09:13:56 | saa[b_r]ider | it has to be the iPod photo |
09:14:00 | scott666 | yeah, doesnt shock me |
09:14:14 | preglow | they've got a whole new dsp/cpu they need to figure out how works |
09:14:44 | *** | Saving seen data "./dancer.seen" |
09:15:46 | | Quit perplexity (Read error: 110 (Connection timed out)) |
09:16:21 | | Join perplexity [0] (n=joust@217.165.115.94) |
09:20:08 | | Join Paul_The_Nerd [0] (n=paulthen@cpe-66-68-93-2.austin.res.rr.com) |
09:24:28 | | Quit Paul_The_Nerd (Client Quit) |
09:31:03 | | Join use_off [0] (n=Yusuf@broadband-197-9.sarimulia.net) |
09:34:44 | preglow | didn't linus get some docs on some ifp cpu on time? |
09:36:07 | Bagder | hm, I remember him getting something but I don't reall the details |
09:36:41 | preglow | this malesinski fellow most certainly seems like somone we want on the team :> |
09:36:59 | Bagder | oh yes |
09:37:49 | preglow | linuxstb: btw, i've figured out why disk accesses sometimes work and sometimes not. it turns out it never works after the spin down time has been exceeded |
09:46:45 | | Join Membrillo [0] (n=sam_kill@CPE-60-229-178-37.nsw.bigpond.net.au) |
09:55:21 | merbanan | this one is for the scandinavians, http://nrk.no/redskap/utskriftsvennlig/5286975.html |
09:56:27 | preglow | hehehe |
09:56:50 | Bagder | B-] |
09:56:58 | preglow | clever norwegian, that |
09:58:08 | markun | Hey, I can even read that :) |
09:58:20 | markun | Looks quite a lot like dutch even |
10:00 |
10:00:21 | preglow | haha |
10:00:24 | preglow | there are similarities |
10:00:29 | preglow | but dutch sounds really strange :P |
10:01:18 | | Join Vladoman [0] (n=Vladoman@p54A7FD06.dip.t-dialin.net) |
10:01:56 | markun | preglow: did you receive the crossfeed sample by jlo? |
10:02:30 | | Quit Vlad0man (Read error: 110 (Connection timed out)) |
10:03:00 | preglow | ahh, yes i did |
10:03:07 | preglow | i'll do a blind test today |
10:03:18 | preglow | just as soon as i figure out how this program works |
10:03:26 | preglow | it's jave, must be blocking my brainwaves |
10:03:28 | preglow | java |
10:03:47 | markun | he wrote a crossfeed implementation in java? |
10:03:49 | Bagder | that's what java does ;-) |
10:04:31 | preglow | nono |
10:04:36 | preglow | the blind test program |
10:04:43 | preglow | abchr or whatever |
10:05:03 | preglow | he did the crossfeeds in reaktor, as is wise |
10:06:12 | markun | isn't is also possible with foobar? |
10:06:49 | preglow | well, you can't exactly design effects in foobar |
10:06:54 | preglow | you need to write them in c first |
10:06:55 | preglow | c++ |
10:06:58 | preglow | easier with reaktor |
10:07:44 | | Join webguest02 [0] (n=c35d1541@labb.contactor.se) |
10:08:22 | webguest02 | morninh |
10:08:33 | | Join LinusN [0] (n=linus@labb.contactor.se) |
10:08:35 | preglow | apparently |
10:08:41 | webguest02 | how is development going for iPod as I may get an iPod for christmas? |
10:08:50 | preglow | it's progressing steadily |
10:08:56 | Bger | webguest02 nano and colour for now |
10:08:58 | preglow | we might have sound pretty sooon |
10:09:11 | webguest02 | yea |
10:09:23 | preglow | since the arm cores seem to be surprisingly fast |
10:09:32 | Membrillo | i got one of the new videos a couple of weeks ago |
10:09:41 | preglow | LinusN: didn't you get some docs for some ifp cpu from someone at some time? |
10:09:49 | webguest02 | There is one thing I am concerned. iPod doesn't use drag and drop to transfer files to the device, you have to use iTunes. So when Rockbox does work on the iPod you still have to use iTunes? |
10:10:04 | LinusN | preglow: yes, from philips |
10:10:14 | preglow | what core? |
10:10:19 | Membrillo | no, it will most likely use a different database system that doesnt use the itunes_DB |
10:10:41 | LinusN | but those docs don't tell much about the cpu itself, mainly about the api to their audio framework |
10:10:41 | webguest02 | I like the black version of the iPod |
10:11:00 | Membrillo | does anyone know how you update the iPod firmware though? is it easily possible? |
10:11:00 | preglow | LinusN: riight, but is still of use? |
10:11:14 | preglow | Membrillo: hell yes |
10:11:20 | preglow | Membrillo: you mean the official firmware? |
10:11:27 | Bagder | webguest02: so far, you can't even use the itunes approach for rockbox on ipod |
10:11:34 | webguest02 | Also is it possible to repairi a broken headphone socket if the sound only comes out of one side? |
10:11:37 | preglow | Bagder: should we ever support that? :-) |
10:11:42 | webguest02 | yea i know bagder, but I was just wondering |
10:11:42 | Bagder | I doubt it |
10:11:47 | Membrillo | i dont really know much about ipods. Is it easy to flash firmware? |
10:11:51 | webguest02 | iTunes is a horrible program |
10:12:00 | preglow | Bagder: well, it is possible. there is this libitunesdb |
10:12:07 | Bagder | right |
10:12:08 | preglow | Membrillo: you don't flash |
10:12:16 | preglow | Membrillo: it's completely disk based |
10:12:28 | preglow | Membrillo: which is good, because it makes it almost impossible to brick an ipod |
10:12:29 | | Part scott666 |
10:12:29 | Membrillo | really? the ipod FW is disk based... interesting |
10:12:39 | Bagder | like the good old Archos |
10:12:43 | Membrillo | what if you deleted the fw? that would brick it |
10:12:45 | preglow | Membrillo: god knows i've tried, and i haven't succeeded yet |
10:12:50 | preglow | Bagder: apart from being even a bit more clever |
10:12:56 | preglow | Bagder: you can brick an archos pretty easily, yeah? |
10:12:56 | Bagder | Membrillo: not at all, the bootloader is in flash |
10:12:58 | webguest02 | I like to see how iPodbox handles the clickwheel interface |
10:13:04 | Bagder | preglow: no |
10:13:05 | preglow | ahh |
10:13:06 | preglow | ok |
10:13:10 | preglow | so exactly like ipod, htne |
10:13:17 | preglow | then <- |
10:13:30 | Bagder | preglow: the difference is that the Archos had an internal version in case it found no disk-based |
10:13:36 | preglow | ahh, right |
10:13:46 | preglow | ipod's got the disk mode |
10:13:54 | Membrillo | does the ipod wheel respond to tapping in certain locations, or do you have to drag across for a response |
10:13:55 | preglow | and the diagnostics |
10:14:06 | preglow | Membrillo: drag, but it's not impossible to code tapping support |
10:14:22 | LinusN | preglow: i believe i gave him the docs i had |
10:14:46 | preglow | btw |
10:14:52 | preglow | decoding oggs on a 60mhz arm??? |
10:14:54 | Membrillo | preglow, so would it be possible to be, for example, holding on left? |
10:14:58 | preglow | that's pretty hardcore |
10:15:10 | Membrillo | and get a continuous left response |
10:15:23 | preglow | Membrillo: possible, yes, but i don't think it's a very good idea |
10:15:26 | Membrillo | like holding a button |
10:15:43 | Membrillo | why? it would be good for games, rather than scrolling around all the time |
10:15:45 | preglow | Membrillo: usually it's a bit hard to press a button by accident, but just brushing the wheel is enough for it to register it as a press |
10:15:53 | | Quit webguest02 ("CGI:IRC (EOF)") |
10:15:57 | preglow | Membrillo: btw, holding might not work |
10:16:06 | preglow | Membrillo: it might just register one press, then nothing more |
10:16:10 | Membrillo | ah ok |
10:16:27 | Membrillo | i guess alternatives are still coming out |
10:16:31 | preglow | i wonder if iriver use the epic core at all |
10:16:40 | preglow | 24 bit dsp, sounds a bit like what i'm using now |
10:18:30 | | Join mikearthur [0] (n=mike@82-41-227-152.cable.ubr11.edin.blueyonder.co.uk) |
10:18:44 | preglow | bet it's easy to get tools for it... |
10:19:44 | | Quit San (Read error: 110 (Connection timed out)) |
10:20:46 | | Join linuxstb_ [0] (n=5343d4aa@labb.contactor.se) |
10:20:52 | | Quit edx (Read error: 110 (Connection timed out)) |
10:29:36 | | Join Jungti1234 [0] (n=jungti12@58.77.81.144) |
10:31:07 | linuxstb_ | preglow: Sorry about breaking your Nano build. I shouldn't make a big commit and then go to bed... |
10:32:13 | preglow | didn't notice they were broken |
10:32:40 | preglow | but feel free to fix ;) |
10:32:41 | Bagder | haha |
10:32:49 | preglow | not going to compile for a while anyway |
10:33:06 | nathanh | hrm, im trying to grok gwps, i got a question |
10:35:08 | | Join tatham [0] (n=cbd685ab@labb.contactor.se) |
10:35:21 | linuxstb_ | preglow: I'll just disable the two broken plugins (Bejeweled and Sudoku) for the Nano. |
10:35:24 | | Join tathamoddie [0] (n=tatham@203-214-133-171.perm.iinet.net.au) |
10:35:28 | use_off | . |
10:35:36 | linuxstb_ | They need bitmaps for your size LCD. |
10:35:44 | tathamoddie | howdy folks ... anyone able to answer a H300 question quickly? |
10:36:19 | tathamoddie | ? |
10:36:46 | Bagder | try us |
10:36:51 | nathanh | tatha: quickly is guaranteed, accuracy is 50/50 |
10:37:02 | tathamoddie | ok - i just installed the rockbox stuff |
10:37:08 | tathamoddie | (i love it already btw) |
10:37:12 | tathamoddie | i installed the bootloader |
10:37:14 | tathamoddie | works fine |
10:37:25 | tathamoddie | i can see that screen ... and i can revert back to iriver |
10:37:50 | tathamoddie | but in a stupid case of me not reading the doco very well i didnt copy the .rockbox and rockbox.iriver files to the root |
10:37:57 | tathamoddie | so it has the bootloader but not the software |
10:38:07 | tathamoddie | meaning it always defaults to iriver firmware |
10:38:17 | tathamoddie | now the device wont mount as a hard drive though in win xp |
10:38:26 | tathamoddie | you plug in the USB cable and it just says "Charging" |
10:38:32 | nathanh | press the play button |
10:38:35 | nathanh | it will then connect to XP |
10:38:58 | tathamoddie | ah! |
10:39:04 | tathamoddie | i was pushing and holding |
10:39:08 | tathamoddie | turns out you need to tap |
10:39:13 | tathamoddie | thanks guys :) |
10:39:17 | tathamoddie | you really do rock |
10:39:39 | nathanh | ok, so im trying to grok gwps... i can see the parsing code that loads a .wps file into wps_data |
10:39:58 | nathanh | i dont grok the relationship between the parsed code and wps_refresh |
10:40:18 | Bagder | the wps code is hairy |
10:40:33 | nathanh | is the contents of wps_data a linear representation of the .wps file? |
10:40:46 | Bagder | yes I believe it is |
10:40:46 | nathanh | so if i iterate over the array of lines, its the same thing as iterating over the .wps file? |
10:41:03 | Bagder | except that it has skipped comments etc |
10:41:15 | nathanh | what i want to do is stick a new tag in for color and add a routine to wps_refresh that changes foreground/background |
10:41:28 | nathanh | which i think will be simpler than adding a new parameter to every existing tag |
10:41:47 | Bagder | sounds fair |
10:41:52 | LinusN | preglow: i just studied the SAA7750 data sheets some more, and it doesn't seem like the EPICS7A core is meant to do codec tasks |
10:41:55 | nathanh | ive dotted lcd_set_foregrounds around the code inside wps_refresh and ive got a funky looking colour display already |
10:42:01 | nathanh | but its not very useful like that |
10:42:34 | LinusN | it looks more like postprocessing, like ultrabass, eq and stuff |
10:42:44 | nathanh | ok, so what i dont understand is where wps_refresh interprets the tags |
10:43:03 | nathanh | i see the flags variable, but i dont see how that relates to the tags |
10:43:44 | Bagder | hey! we missed the anniversary! |
10:43:50 | Bagder | 2001-12-07 |
10:43:53 | LinusN | damn! |
10:43:57 | Bagder | " First mail! ;-)" |
10:44:44 | | Quit use_off () |
10:44:44 | | Quit tatham ("CGI:IRC (EOF)") |
10:49:01 | preglow | LinusN: they do specify it can decompress audio |
10:49:06 | tathamoddie | (sidenote: i've just installed rockbox on a mate's h340. he's blind and this is an absolute godsend for him. thanks guys) |
10:49:31 | tathamoddie | (is there any way to get it to pronounce artist names / song titles ... we have voice menus working) |
10:49:51 | amiconn | LinusN: Last night you said lcd_update() takes 6.7ms at 45 MHz, and later that it takes 26ms. Which value is true, or which value relates to what lcd_update() method/version? |
10:49:57 | Bagder | tathamoddie: there's a script available that generates spoken file names |
10:50:14 | Bagder | or at least directory names |
10:50:18 | tathamoddie | badger: where am i looking / what am i searching for? |
10:50:46 | Bagder | http://www.rockbox.org/twiki/bin/view/Main/VoiceHowto |
10:51:15 | tathamoddie | thanks again |
10:52:11 | LinusN | amiconn: the latter one is correct, i'm afraid |
10:52:34 | LinusN | and it's the word-by-word dma version |
10:52:34 | preglow | hooray for us! hooray for rockbox! |
10:52:54 | nathanh | eek, 26ms |
10:53:00 | preglow | LinusN: but yeah, the propaganda sheets say they can be usde for decompressing audio and for postprocessing |
10:53:13 | nathanh | is that perhaps the cause of the ticking sound that happened with the earlier iriver h300 firmwares and the lcd remotes? |
10:53:18 | preglow | LinusN: a 100mips dsp core should indeed be good and solid for decoding audio |
10:53:40 | LinusN | would be nice |
10:54:13 | preglow | and nearly impossible |
10:54:21 | preglow | unless someone coughs up some datasheets for it |
10:54:52 | linuxstb_ | preglow: You can safely "cvs update" now if you wish. |
10:55:02 | LinusN | the epics core is located between the arm and the CODEC |
10:55:48 | preglow | LinusN: gr8 |
10:56:02 | | Quit tvelocity (Remote closed the connection) |
10:56:08 | linuxstb_ | LinusN: Does it have code in ROM or does it have to be loaded by the main firmware? |
10:56:57 | LinusN | it seems like the epic is preprogrammed, but it is "field upgradeable" with a 4kword instruction ram |
10:57:01 | | Quit Membrillo () |
10:57:55 | | Quit linuxstb_ ("CGI:IRC") |
11:00 |
11:00:43 | LinusN | i wish some 3d gfx artist could render some nice gems for bejeweled |
11:01:00 | | Join Polo_o [0] (n=polo_o@82-69-160-166.dsl.in-addr.zen.co.uk) |
11:01:08 | nathanh | why dont you nick the ones from gnome bejeweled and downsize them in gimp? |
11:01:25 | preglow | LinusN: i wish they'd just steal the ones from the gnome port |
11:01:38 | Bger | haha |
11:01:40 | LinusN | are they up for grabs? |
11:01:42 | * | nathanh hi5 |
11:01:46 | preglow | well, it's gpl... |
11:01:56 | preglow | anyway, that's not the problem |
11:02:02 | preglow | it was some deal of transparent backgrounds |
11:02:35 | Bagder | http://sebdelestaing.free.fr/gweled/ |
11:02:51 | nathanh | bagder: they're purdy |
11:03:21 | LinusN | go get'em! |
11:03:44 | Bagder | I have no sim or device that can show colors ;-) |
11:04:03 | * | preglow kicks bagder towards the apple store |
11:04:09 | Bagder | hehe |
11:04:22 | LinusN | i wish an sdl ninja could bless the x11 sim with some colors |
11:04:22 | nathanh | half tempted to get a nano and run rockbox on it |
11:04:28 | nathanh | the apple fanboys at my work would have kittens |
11:04:58 | preglow | nathanh: especially in the half working state it is now |
11:05:08 | preglow | nathanh: it would be like seeing an ipod after a mountain climbing accident |
11:05:10 | nathanh | no audio? |
11:05:27 | preglow | no audio and glitchy controls |
11:06:55 | preglow | the graphics are svg! |
11:06:56 | preglow | excellent |
11:06:58 | | Join tvelocity [0] (n=tony@84.254.13.74) |
11:07:01 | preglow | then we can scale them as large as wel want |
11:07:04 | preglow | s/wel/we/ |
11:07:04 | LinusN | the h300 file browser scroll still lags, even with the optimized lcd dma |
11:07:14 | Bger | :( |
11:07:20 | nathanh | the lags not so bad, but would be nice if releasing the button flushed the queue |
11:07:45 | nathanh | so as to not generate more events |
11:08:09 | preglow | LinusN: i have no lagging on nano, why is it so slow on h3x0? |
11:08:43 | LinusN | 45mhz, lots of bitmap operations in a slow sdram |
11:08:56 | LinusN | that's my theory at least |
11:08:59 | preglow | well |
11:09:05 | preglow | is nano framebuffer in iram, then? |
11:09:12 | LinusN | i dunno |
11:09:20 | preglow | if it is, it's got to be eating almost all of it |
11:09:57 | preglow | yes, 46k |
11:10:15 | LinusN | how big is the nano lcd? |
11:10:17 | preglow | we have 64kb iram for core on nano, though |
11:10:29 | nathanh | sheesh, it uses that much iram for a framebuffer |
11:10:30 | preglow | 176x132 |
11:10:38 | nathanh | must be so they can get smooth video |
11:10:45 | Bger | 77k for h300 iirc |
11:10:45 | nathanh | the iriver video playback is jerky |
11:10:46 | LinusN | preglow: that's a lot smaller than 220x176 |
11:10:50 | preglow | i gues |
11:10:51 | preglow | s |
11:10:52 | Bger | 16bit |
11:11:14 | Bger | 77440 |
11:11:18 | preglow | linuxstb: does your file browser lag? |
11:11:20 | Bagder | that's 60% of the h3x0 screen area |
11:12:10 | preglow | ipod video is 320x240... |
11:12:24 | Bagder | gigabeat too iirc |
11:12:31 | | Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-131-040.pools.arcor-ip.net) |
11:12:31 | | Quit nathanh ("CGI:IRC (EOF)") |
11:12:32 | preglow | i hope they use some special framebuffer ram |
11:14:48 | *** | Saving seen data "./dancer.seen" |
11:15:18 | LinusN | Bagder: "bag of shit" :-) |
11:15:18 | amiconn | LinusN: My calculations tell me that it should be possible to get H300 lcd_update() timings down to ~10ms with single writes, and to ~8 ms if multiple writes can be made working |
11:16:10 | LinusN | so far i've had no success with fast ram mode |
11:16:18 | | Join nathanh [0] (n=cb1a1042@labb.contactor.se) |
11:16:28 | LinusN | and the lcd controller can't handle bursts at 124mhz |
11:16:44 | Bagder | LinusN: I couldn't resist ;-) |
11:17:17 | LinusN | so it looks like we'll have toi resort to movem.w for reads and simple move.w for writes |
11:17:38 | amiconn | (There is no movem.w, only movem.l |
11:17:45 | LinusN | gah |
11:17:51 | LinusN | swap.w? |
11:18:16 | Bagder | my dns still resolves the former forum IP |
11:18:21 | amiconn | LinusN: Yes. |
11:18:22 | Bagder | annoying |
11:18:27 | LinusN | Bagder: indeed |
11:18:29 | preglow | Bagder: mine too |
11:18:38 | preglow | this is one of the longest dns propagation times i've ever seen |
11:18:41 | LinusN | Bagder: i cheat with /etc/hosts |
11:18:49 | Bagder | I'll do that too |
11:18:53 | amiconn | Bagder: Then something is wrong with the TTL interpretation of your DNS. Works fine here |
11:19:13 | amiconn | LinusN: Btw, my timing estimations are for 45 MHz |
11:19:21 | Bagder | well, it is my ISP's DNS |
11:20:04 | | Join nathanh_ [0] (n=wosjowj@220-245-222-198-act-pppoe.tpgi.com.au) |
11:20:04 | | Quit nathanh (Client Quit) |
11:20:16 | LinusN | amiconn: so it would be a movem.l, and a couple of move.w/swap combinations |
11:20:42 | | Nick nathanh_ is now known as nathanh (n=wosjowj@220-245-222-198-act-pppoe.tpgi.com.au) |
11:21:23 | LinusN | the problem with the fast ram mode seems to be that it updates the GRAM pointer wrong |
11:24:09 | LinusN | probably because the CS is negated for every word |
11:25:08 | linuxstb | preglow: The directory browser doesn't keep up with the buttons - but I don't know if that's a button driver issue or a file browser issue. |
11:26:25 | linuxstb | And no, we don't use IRAM for the 16-bit framebuffer. |
11:26:56 | amiconn | LinusN: Where is CS connected? |
11:27:09 | amiconn | Would be helpful if there were schematics... |
11:27:18 | | Quit nathanh ("Quit") |
11:27:20 | LinusN | LCD CS -> Coldfire CS1 |
11:27:28 | LinusN | same as H1x0 |
11:27:55 | LinusN | i simply haven't had time to draw schematics |
11:29:13 | LinusN | if only we could control the time between accesses with the CS logic... |
11:29:32 | amiconn | I see that CS1 is also GPIO58. What if we control that manually? |
11:29:49 | LinusN | we can't, since the data bus is shared |
11:30:10 | amiconn | hmm... |
11:31:31 | | Join nathanh [0] (n=wosjowj@220-245-222-198-act-pppoe.tpgi.com.au) |
11:32:23 | | Quit mirak (Read error: 110 (Connection timed out)) |
11:32:24 | preglow | linuxstb: it doesn't here either, actually, but i suspect that's a button driver issue |
11:32:52 | preglow | does the file browser/menus etc. empty the button queue before they act? |
11:33:03 | preglow | i guess they don't |
11:34:04 | | Join Aramil [0] (n=tony@84.254.9.197) |
11:35:43 | | Join mirak [0] (n=mirak@AAubervilliers-152-1-77-182.w86-198.abo.wanadoo.fr) |
11:37:44 | | Join KN|stiff [0] (n=phhome@Fd697.f.strato-dslnet.de) |
11:38:04 | | Quit KN|stiff (Client Quit) |
11:38:49 | * | preglow reads up on doxygen |
11:39:47 | amiconn | LinusN: (1) Is it essential that the burst write is exactly 4 words, or can it be longer? (2) If you enable the BSTW bit for CS1, does the coldfire still negate CS between words? |
11:40:08 | LinusN | amiconn: it must be a multiple of 4 |
11:40:20 | amiconn | (3) Does the LCD controller use the address bits? |
11:40:44 | LinusN | 2) I don't know, i'll check |
11:41:03 | amiconn | If the answers are 1-yes, 2-no and 3-no, it should be possible to use line bursts for LCD write |
11:41:08 | LinusN | 3) yes, A1 is used for register select |
11:41:24 | amiconn | bah |
11:41:36 | LinusN | anyway, that doesn't matter, since the bursts are too fast |
11:41:53 | amiconn | Even with the appropriate number of wait states? |
11:42:29 | LinusN | the wait states isn't the problem |
11:42:42 | LinusN | it's the time *between* writes that is the problem |
11:43:43 | LinusN | line-burst dma works fine in 45mhz |
11:44:02 | | Quit tvelocity (Read error: 101 (Network is unreachable)) |
11:45:19 | amiconn | So then we could use different lcd data writes depending on CPU clock |
11:45:43 | LinusN | perhaps |
11:46:55 | Bger | LinusN what about adding a check to lcd_update[_rect] if the backlight is on and only if it's on to update the screen ? |
11:50:45 | nathanh | woot, i have color wps |
11:51:25 | linuxstb | nathanh: Do scrolling lines work properly? |
11:51:33 | nathanh | ? what do you mean ? |
11:51:53 | linuxstb | I mean do you just have one fg/bg colour, or do you change them for different parts of the WPS? |
11:52:02 | nathanh | diff colors for diff parts |
11:52:12 | nathanh | i have a new tag, insert it anywhere, changes the color of all subsequent tags |
11:52:47 | Bagder | and do you have any scrolling parts of the screen? |
11:53:00 | nathanh | nothing scrolling |
11:53:10 | | Join XavierGr [0] (n=XavierGr@ppp27-adsl-27.ath.forthnet.gr) |
11:53:29 | Bger | morning, XavierGr ;) |
11:53:48 | Bagder | lunch! |
11:53:54 | Bger | heh, yeah |
11:54:06 | Bger | it's 12:53 in bg and greece |
11:55:27 | linuxstb | nathanh: The information about a scrolling line is stored in a "struct scrollinfo" (defined in export/lcd.h). This doesn't include bg/fg colours - which is why I think scrolling will probably not work as you intend. |
11:55:30 | mirak | 11:56 in France |
11:55:42 | nathanh | ok, i picked a long filename |
11:55:48 | nathanh | it scrolls fine in beautiful green |
11:55:58 | LinusN | amiconn: gah, it turns out that the bursts are too fast even in 45mhz |
11:56:00 | mirak | Bger: are you at the sun time or is their a lag ? |
11:56:21 | linuxstb | nathanh: My guess it that scrolling lines use the last set of fg/bg colours you define on the WPS. |
11:56:23 | Bger | no daylight |
11:56:34 | Bger | just UTC+2 |
11:57:08 | | Join KN|stiff [0] (n=phhome@Fd697.f.strato-dslnet.de) |
11:57:10 | mirak | Bger: two times a year our governement decide to change the time |
11:57:17 | Bger | here too |
11:57:23 | LinusN | Bger: we will add a lcd_enable() function that will handle this, plus the power to the lcd |
11:57:25 | mirak | it's supposed to save energy |
11:57:28 | | Quit KN|stiff (Client Quit) |
11:57:28 | Bger | but it's not in effect |
11:57:39 | mirak | it disturbs cows I have heard |
11:57:45 | Bger | LinusN anything i can do about this ? |
11:57:45 | nathanh | moo |
11:58:00 | mirak | cows says meuhh here |
11:58:07 | Bger | hahaha |
11:58:22 | nathanh | claris says meuhh |
11:58:34 | mirak | I had that discussion about animals shoots |
11:58:37 | mirak | shouts |
11:58:43 | | Join HypnoticMonkey [0] (n=522788bc@labb.contactor.se) |
11:58:44 | LinusN | Bger: i dunno |
11:58:48 | mirak | it's fun |
11:58:53 | mirak | but of topic |
12:00 |
12:00:08 | linuxstb | nathanh: What do your new tags look like? Can you give an example? |
12:01:02 | nathanh | #C00ff00 is green |
12:01:27 | nathanh | im trying to grok this scrolling problem, see if its a showstopper |
12:01:36 | linuxstb | So you use # instead of % for the tag? |
12:01:44 | nathanh | blah, sorry, force of habit |
12:01:48 | nathanh | %C00ff00 |
12:02:18 | | Join San [0] (n=sanitari@212.2.181.61) |
12:02:48 | linuxstb | Regarding scrolling, try setting a WPS with two scrolling lines, each using different fg/bg colours. |
12:03:14 | nathanh | aye, trying that now |
12:03:59 | * | amiconn wonders why a burst write with the appropriate number of wait states can be too fast |
12:04:51 | nathanh | boo, its a showstopper, all scrolling lines = color of last line in wps |
12:06:09 | amiconn | Yes of course |
12:06:10 | linuxstb | I think it's relatively easy to fix. You need to add bgcolor and fgcolor to the scrollinfo struct in export/lcd.h (only for targets that have colour LCDs), change the LCD code to store and retrieve the colours from there for scrolling lines. |
12:06:17 | amiconn | Scrolling needs rework |
12:06:36 | nathanh | aye, ill do that |
12:06:54 | amiconn | linuxstb: That seems like a half-hearted fix to me |
12:07:09 | linuxstb | Why? |
12:07:27 | linuxstb | The scrollinfo struct should contain all info needed to draw the line. |
12:07:30 | nathanh | id rather work it so scrolling lines were rendered as part of format_display |
12:08:39 | amiconn | linuxstb: Yes, but the line based scrolling is too unflexible, plus I'd want some more attributes (like bold/ italic flags) |
12:08:51 | nathanh | hrm, i like the cut of your jib |
12:09:09 | preglow | :/ |
12:09:15 | linuxstb | amiconn: Is there any other solution apart from extending the scrollinfo struct to contain those extra attributes? |
12:09:17 | preglow | then we need italic and bold fonts loaded all the time as well |
12:09:30 | preglow | commence designing the new font system, someone |
12:09:37 | amiconn | nathanh: The scrolling has to be done in a separate thread if we don't want it really jumpy. That's the reason why it is part of the driver |
12:09:37 | preglow | i want to be able to use several fonts at one time |
12:09:44 | linuxstb | We already have a glyph cache IIUC. |
12:09:46 | nathanh | format_display is too slow to render each frame? |
12:09:57 | amiconn | preglow: Algorithmic emboldening/ italicising |
12:10:37 | amiconn | nathanh: It might be slow, but the main point is that the scrlling has to be handled in regular intervals |
12:10:59 | preglow | amiconn: that's never pretty |
12:10:59 | nathanh | so thats gui_wps_refresh? |
12:11:29 | preglow | amiconn: you can't italicise a font algorithmically, just slant it |
12:11:32 | preglow | amiconn: italic != slanted |
12:11:40 | amiconn | Yes I know |
12:11:49 | nathanh | strikes me that the colors will have to be stored in the format_lines |
12:12:41 | XavierGr | Hello all! Yes it's midday right now here :) |
12:12:53 | LinusN | amiconn: the wait states only define the time that CS is low |
12:12:53 | Bger | ;) |
12:13:17 | LinusN | but you can't control how long it should take until the next access is started |
12:13:32 | amiconn | LinusN: For bursts, CS is low during the whole burst access according to the datasheet |
12:13:39 | LinusN | so the CS-low period is nice and long, but the CS-high period is too short |
12:14:35 | LinusN | yes, but that probably only works if the target address is auto-incremented |
12:14:44 | LinusN | and burst is enabled |
12:16:14 | LinusN | in my current dma setup, the sdram data is read in 16-byte bursts, and written with 8 consecutive word writes |
12:16:35 | LinusN | and that fails because the time between the writes is too short |
12:17:22 | amiconn | Does the DMA controller allow burst writes without address increment? |
12:17:52 | LinusN | the bursts are not controlled by the dma controller |
12:18:16 | LinusN | i just tell it to read entire lines from the source, and the sdram controller does the bursting |
12:18:45 | amiconn | What if you enable burst write for CS1 and use DMA? |
12:18:55 | LinusN | will try |
12:21:05 | | Join edx [0] (i=edx@p54A87573.dip.t-dialin.net) |
12:21:17 | linuxstb | amiconn: If adding bgcolor and fgcolor to the scrollinfo struct is "half-hearted", what do you have in mind? |
12:21:33 | LinusN | the data sheet says that bursts are only done if the destination data size is larger than the chip select data size, i.e a 32-bit write to a 16-bit port |
12:21:59 | LinusN | and then the cs controller increases the address |
12:22:01 | LinusN | damn! |
12:22:28 | LinusN | why couldn't they have put regsel on a higher address pin? |
12:24:42 | LinusN | amiconn: so i guess we'll have to try the movem/move/swap hack |
12:27:23 | nathanh | linuxstb: the scroll thread redraws the string each time |
12:27:36 | nathanh | with an optional pixel offset based on the current scroll state |
12:28:09 | nathanh | how about storing the entire string rendered offscreen and blitting the required x/y/w/h of it onscreen |
12:28:28 | nathanh | that way the string can be rendered in its desired color ahead of time |
12:28:42 | linuxstb | nathanh: That will require a lot more memory for the scroll buffers. |
12:28:49 | nathanh | also means we could scroll bitmaps |
12:28:54 | Bagder | and it doesn't handle transparancy |
12:29:11 | nathanh | it could handle transparency with an alpha channel (even a 1bit channel) |
12:29:15 | Bagder | true |
12:30:32 | linuxstb | Currently the scrolling code can handle 26 lines, each containing 255 characters using any size font. |
12:30:42 | linuxstb | That's a large bitmap. |
12:31:30 | nathanh | at the very least id like to try blitting the onscreen bitmap to the left/right, then only rendering the bit that needs to be re-rendered |
12:32:38 | Bagder | unless there's a bg pic ;-) |
12:32:59 | nathanh | blah |
12:33:39 | Bagder | my cell phone has a bg picture present in all screens and it looks nice |
12:33:55 | linuxstb | my cell phone has a bg picture present in all screens and it looks horrible |
12:34:02 | Bagder | haha |
12:34:09 | preglow | mine has a bg on the main screen |
12:34:15 | preglow | looks horrible, but that's thanks to me |
12:34:47 | nathanh | the current scrolling code flickers because it does lcd_fillrect followed by lcd_putsxyofs |
12:35:01 | nathanh | if it rendered offscreen then blitted onscreen, it would not flicker |
12:35:13 | LinusN | nathanh: why would that flicker? |
12:35:15 | linuxstb | It probably flickers because the lcd update is slow. |
12:35:45 | LinusN | nathanh: all lcd drawing is done offscreen |
12:35:49 | linuxstb | nathanh: The LCD is only written do during an lcd_update() |
12:35:55 | linuxstb | s/do/to/ |
12:36:03 | nathanh | ahh, ok |
12:36:10 | nathanh | so its flickering because its a cheaparse lcd :-) |
12:36:19 | LinusN | lol |
12:36:36 | LinusN | no, it's a cheaparse engineer who connected the lcd on the pcb |
12:36:46 | Bger | lol |
12:37:17 | Bger | some poor chinese working for a cup of rice a day |
12:37:27 | LinusN | korean, rather |
12:37:43 | Bger | manifactured by iriver, made in china |
12:38:21 | aliask | But who ordered the chinese guy to do it that way? |
12:38:30 | aliask | Wow this is so deep... and pointless. |
12:38:37 | nathanh | im looking at puts_scroll, you can supply arbitrary xpos/ypos, thats the top-left corner |
12:38:42 | Bger | the last was not said as something funny ... |
12:38:55 | nathanh | but i dont see a value for a clip window... does it render right up to the right edge? |
12:40:43 | nathanh | blh, i see that it does |
12:41:06 | nathanh | so you can have a scroll that extends from halfway on the screen to the right edge of the screen |
12:41:16 | nathanh | but you cant have a scroll that is completely detached from both edges of the screen |
12:45:14 | | Quit edx (Read error: 110 (Connection timed out)) |
12:46:26 | | Quit Aramil ("Leaving") |
12:46:36 | Bagder | "realloc: warning: points to free buffer" MPeye uses malloc() ! ;-) |
12:46:42 | | Join Petur [0] (n=d4efd6a6@labb.contactor.se) |
12:47:28 | | Join Moos [0] (n=DrMoos@m196.net81-66-159.noos.fr) |
12:47:29 | Bger | Petur hi |
12:47:34 | Petur | LinusN: is there hope for a bootloader that can do USB? |
12:48:23 | Petur | It came to my mind that I lost a lot of time yesterday evening booting into the iRiver FW when my test crashed |
12:48:30 | Bagder | now why can't I ever remember how to force objdump to dissassemble a binary file... |
12:48:39 | Petur | Bger: hi, thanks for fixing my patches |
12:48:57 | Bger | Petur heh, for nothing |
12:49:07 | Bger | btw, i suggest you to use cvs, really |
12:49:27 | linuxstb | Bagder: "-b binary" |
12:49:42 | Bagder | dang |
12:49:44 | Bagder | right, thanks! |
12:49:57 | linuxstb | Something not obvious from the man page |
12:50:02 | LinusN | Petur: yes |
12:50:38 | Petur | I like TortoiseCvs, I'm no longer used to command line stuff ;) |
12:51:11 | Petur | I think it can put all patches into one file, and after that I'll use a line-ending-fix tool |
12:51:35 | Bger | Bagder the next to the last string of strings dump is funny |
12:52:12 | Bagder | which is that? |
12:52:25 | | Quit elinenbe (" HydraIRC -> http://www.hydrairc.com <- IRC with a difference") |
12:52:36 | Bagder | I'm a bit surprised there aren't more strings available |
12:52:36 | Petur | this webclient is nice... but it's not good for my growing rockbox addiction |
12:53:15 | Bger | "A sibal jola jjajungna jakku ssang soriman nane!!!" |
12:53:16 | Bagder | I love the paths to source code in the firmware: |
12:53:19 | Bagder | "\HddCodeHW\source\key_isr.c" |
12:53:35 | HypnoticMonkey | petur: agreed |
12:53:43 | Bagder | Bger: it sure sounds korean to me! ;-) |
12:54:00 | Bger | more interesting are "http://", "ftp://" and "file://" |
12:54:20 | Bagder | hehe |
12:55:37 | Bger | how this "unsigned char table[] = { ... }; has been included ... |
12:56:31 | preglow | markun: you get the gigabeat sources yet? |
12:57:23 | markun | not yet |
12:58:15 | markun | I posted a message on mygigabeat asking for a defective player, but the chances of that will be pretty slim I guess |
12:58:25 | Bagder | Bger: I'm quite sure it executes code at 0x10000000 - |
12:58:54 | Bger | so? |
12:58:55 | | Part LinusN |
13:00 |
13:00:44 | linuxstb | Anyone understand this line: "A sibal jola jjajungna jakku ssang soriman nane!!!" |
13:00:56 | linuxstb | (from the mpeye firmware) |
13:01:17 | Bagder | Jungti1234: here? |
13:01:51 | linuxstb | The three exclamation marks are making me curious... |
13:01:56 | linuxstb | Must be important |
13:02:19 | Bger | like "what, the fsck!!!" |
13:02:32 | preglow | we will sure you for looking!!! |
13:02:35 | preglow | sue!!! |
13:02:43 | nathanh | or "i like exclamation points!!!" |
13:03:16 | Bger | or "i must stop being lazy!!!" |
13:03:56 | nathanh | ok, ive haxored the code and i now have scrolling lines in diff colors |
13:03:59 | nathanh | i am leetzor |
13:04:18 | nathanh | multilines even work properly |
13:04:24 | nathanh | diff colors for diff times of the multiline |
13:05:46 | Bger | nathanh submit patch!!! :) |
13:06:04 | nathanh | you betcha |
13:06:16 | | Join tucoz [0] (n=martin@hornved.ii.uib.no) |
13:06:24 | | Quit ashridah ("later") |
13:08:00 | linuxstb | Bger: Sorry, I didn't see you posted the same quote as me five minutes earlier!!! |
13:08:16 | tucoz | hello, I thought my h120 had died on me today. When I pressed on play nothing happened. Probably out of juice. But, as soon as I put the charger in it started without me pressing anything. Guess it had enough power to register the button, but not enough to start anything else. |
13:08:18 | Bger | hahaha :) |
13:08:35 | tucoz | phew |
13:08:57 | preglow | hehe |
13:09:03 | preglow | cpu running at about 0.5hz |
13:09:05 | Bger | ok, tripple exclamation marks are stylish these days ... :) |
13:10:19 | tucoz | preglow, 8008 emulation ;) |
13:10:34 | Bger | heh |
13:10:37 | tucoz | oh, 0.5hz even |
13:10:49 | tucoz | I thought you said MHz |
13:13:52 | tucoz | hmm, how did the ifp-porter manage to decode oggs with the original firmware? It is way beyond me to understand his porting approach. |
13:14:03 | Bagder | why? |
13:14:11 | Bagder | he's writing an emulator for the cpu |
13:14:20 | tucoz | Is it supported by the original fw? oggs that is |
13:14:25 | Bagder | yes |
13:14:26 | preglow | yea |
13:14:29 | tucoz | oh, I see :) |
13:14:32 | preglow | but damn |
13:14:35 | preglow | ogg decoding on 60mhz arm |
13:14:39 | preglow | pretty cool |
13:14:50 | *** | Saving seen data "./dancer.seen" |
13:14:51 | Bagder | yes |
13:15:00 | preglow | but btw |
13:15:03 | tucoz | I thought he somehow managed to add ogg decoding to the original fw. hehe |
13:15:07 | Cassandra | Hmmm. Yoghurt does not improve the looks oif the Nano at all. |
13:15:13 | preglow | his patch says it removes the low bitrate ogg limit |
13:15:21 | preglow | does it actually work with low bitrate oggs, then? |
13:15:23 | nathanh | is there any way to run rockbox normal interface without detaching UMS? |
13:15:25 | tucoz | I see, anyway. I am impressed |
13:15:32 | preglow | Cassandra: try coffee |
13:15:42 | Bagder | nathanh: no |
13:15:46 | tucoz | coffee with lot's of cream and lot's of sugar |
13:16:05 | Cassandra | preglow: Coffee crime! Every drop is sacred. |
13:16:11 | Zagor | we sure have a shedload of ports going now |
13:16:20 | Zagor | going on |
13:16:24 | tucoz | I understand the emulator approach. It was the ogg part I didn't get. |
13:16:24 | Bagder | indeed |
13:16:36 | Bger | so "~" is binary not ? |
13:16:36 | tucoz | Zagor, quite a monster you have created :) |
13:17:12 | Bagder | Bger: it is a one-bit complement operation, yes |
13:17:33 | Cassandra | Well, it's not so much the number of active ports as the number of useable ones. |
13:17:49 | Cassandra | Most ports don't seem to make it to that stage. |
13:17:50 | * | Bger hides |
13:17:56 | nathanh | im really really _really_ impressed with rockbox |
13:18:02 | tucoz | was the intention in the beginning to just support one target, or were the multiplatform in your mind from the start? |
13:18:07 | preglow | Zagor: the more the merrier |
13:18:14 | nathanh | gapless playback, 7 seconds ontime, its so much better than the original firmware |
13:18:15 | Bger | Cassandra i think that even h300 port is pretty usable atm |
13:18:23 | preglow | nothing like a big multiplatform mess to round off the day |
13:18:40 | Bagder | tucoz: we did focus on more than one Archos player from day 1 |
13:18:45 | Zagor | Cassandra: absolutely. I'm just glad people are taking time to try the effort, even if most probably won't complete. |
13:18:55 | Cassandra | Bger, I'd agree with that. If it plays music, it's pretty much useable. Although I don't regard the H300 port as particularly different from the H100. |
13:18:57 | tucoz | Bagder, ok. Not like Linux then. |
13:19:11 | Cassandra | Certainly no more so that the Recorder port was from the player. |
13:19:18 | nathanh | linux was never multiplatform |
13:19:26 | nathanh | the first version linus even said "this will only ever be for i386" |
13:19:33 | Bger | heh |
13:19:38 | Zagor | tucoz: that is the reason the two dirs "apps" and "firmware" |
13:19:43 | tucoz | yes, I've read that discussion. Funny. |
13:19:52 | tucoz | Zagor, I see. |
13:19:56 | nathanh | whats the res of the h300 screen |
13:20:10 | Bger | what ? the same LCD controller on h300, nano and photo? |
13:20:12 | Bger | nathanh 220x176 |
13:20:27 | nathanh | thx |
13:20:42 | Bger | nathanh see the DeviceChart topic in the wiki |
13:20:57 | Bagder | it would be neat to have the ipod color and nano added to that |
13:21:10 | Cassandra | I didn't realise the Nano LCD controller was the same as the H300. |
13:21:35 | Cassandra | Bagder: I should be able to give that a little more time after Christmas. |
13:21:53 | Cassandra | Although my low level skills are weak and puny. |
13:22:12 | Cassandra | (Well, in the new year, really) |
13:22:41 | preglow | it'll be playing audio by then, mark my words! |
13:22:54 | * | Bger writes down |
13:22:55 | Cassandra | Uh-huh. |
13:23:15 | preglow | well, at least if the arm core is as powerful as it looks like right now |
13:23:17 | linuxstb | preglow: Assuming we can fix the ATA problem. |
13:23:23 | preglow | linuxstb: what at problem? |
13:23:27 | Cassandra | This is my unconvinced face. It doesn't come over well on IRC, I'm afraid. |
13:23:42 | linuxstb | preglow: You told me that the ATA driver doesn't work properly. |
13:23:47 | linuxstb | (on the nano) |
13:24:52 | Cassandra | Ah, is that why I can't boot the original firmware then? |
13:25:04 | linuxstb | No, I think that's a different problem. I'm still investigating. |
13:25:13 | preglow | 09:37 < preglow> linuxstb: btw, i've figured out why disk accesses sometimes work and sometimes not. it turns out it never works after the spin down time has been exceeded |
13:25:38 | Bagder | yes, the flash spinning down can't be good ;-P |
13:25:41 | linuxstb | OK, so how do we fix it? Never spin down the disk on the Nano? |
13:25:42 | Cassandra | linuxstb, if you want any testing done, mail me or grab me when I'm around. |
13:25:52 | preglow | linuxstb: sounds like a good temp solution to me :-) |
13:26:07 | Bger | one less thread on nano ? :) |
13:26:42 | linuxstb | preglow: OK, I'll look at that and give you a new ata.c to try. |
13:26:49 | Cassandra | I'd have thought that an instruction to spin down the flash'd just do nothing, myself. |
13:27:01 | preglow | Cassandra: it might and it might not |
13:27:08 | preglow | Cassandra: it might have some power preservation function, for example |
13:27:29 | Bagder | and obviously it does something |
13:27:37 | Cassandra | *nod* |
13:27:54 | preglow | brb |
13:27:55 | Cassandra | I guess a trawl through the iPodLinux ata code may be in order. |
13:32:07 | | Part tucoz ("Leaving") |
13:33:32 | preglow | well, it's based on ipl code as is |
13:34:20 | | Part Petur |
13:35:11 | linuxstb | preglow: As a quick test, I think you could remove the call to create_thread() in drivers/ata.c, and also remove the queue_post() call in ata_sleep() in the same file. |
13:35:24 | linuxstb | That should prevent the sleep code from ever being called. |
13:35:55 | preglow | will afterwards |
13:38:18 | steveb | ok. if you were going to buy an mp3 player right now which one would it be? and it has to have >30GB of space... |
13:38:41 | nathanh | anybody who is interested, the colorised wps patch is up on sf |
13:39:10 | nathanh | steveb: right now, id buy the iriver h340, cos it runs rockbox! |
13:39:26 | nathanh | but if it didnt run rockbox, i wouldnt recommend the h340 |
13:39:31 | steveb | heh cool. i used to own an h340. |
13:39:34 | steveb | they are pretty sweet |
13:39:43 | steveb | having a hard time finding people who sell them in the uk tho |
13:39:48 | nathanh | crappy startup time, no gapless, otherwise they're ok |
13:39:52 | linuxstb | steveb: The best Rockbox target at the moment is the H140 - but they are discontinued. |
13:40:10 | steveb | yeh |
13:40:21 | steveb | i see that the h340 rockbox stuff is coming on quite fast tho |
13:41:17 | steveb | nathanh: start up time doesnt bother me... once its running its running |
13:41:55 | nathanh | rockbox on the h340 is great... when i stop the car to duck into the shops, it pauses, when i restart the car, within 2 seconds it has resumed |
13:42:15 | steveb | heh cool. |
13:42:33 | linuxstb | The only other choices are the iAudio X5 (port planned, but not really started yet), and the iPod (but not the new video iPod - the version just before that model) |
13:42:33 | steveb | oh for the record, trying to install flash linux to a partition on the h340 is a Bad Thing (tm) |
13:42:42 | steveb | fuck the iPod... |
13:42:47 | steveb | i hate those things |
13:43:05 | steveb | i do not see why people like that silly wheel thing so much |
13:43:30 | steveb | ill check out some h340 prices |
13:43:42 | preglow | click wheel = lovely |
13:44:08 | markun | steveb: more control over the scroll speed than with buttons maybe |
13:44:26 | steveb | maybe... it just annoys me |
13:46:08 | HypnoticMonkey | its not very intuitive to scroll downwards by making a semi circle as far as im concerned. i feel that vertical touch pads are superior. |
13:46:37 | preglow | i think it's very intuitive |
13:46:41 | preglow | plus, it's more efficient |
13:46:51 | preglow | anyway, it's just a preference |
13:46:58 | preglow | use whatever floats your boat |
13:47:07 | steveb | yeh |
13:47:53 | | Join Febs [0] (i=Febs@dhcp64-134-210-122.hfwsf.sjc.wayport.net) |
13:48:15 | | Join edx [0] (i=edx@p54A85462.dip.t-dialin.net) |
13:48:15 | steveb | no one seems to be selling the ones with the remote any more :-/ |
13:48:34 | linuxstb | preglow: I don't know why, but enabling dircache on my ipod caused it to stop booting up. |
13:49:13 | nathanh | ive had lockup problems on the h340/rockbox with dircache on |
13:49:23 | nathanh | requiring a reset with a pin |
13:49:32 | preglow | btw |
13:49:42 | preglow | the clock now overwrites the hd indicator in the status bar |
13:49:45 | preglow | any way to fix that? |
13:49:49 | linuxstb | nathanh: When did it lock up? |
13:50:09 | nathanh | a few seconds after the thing booted |
13:50:11 | linuxstb | preglow: I guess the ipod is the first target with both a clock and virtual LED. The h300 will have the same problem though. |
13:50:20 | nathanh | so you can feel the disk chattering away, building the dircache |
13:50:22 | nathanh | and a song is playing |
13:50:25 | nathanh | then it just locks solid |
13:50:41 | linuxstb | preglow: I guess it's a simple fix in the status bar code. |
13:50:47 | Zagor | that's because dircache is evil ;-) |
13:51:24 | preglow | dircache is god |
13:51:31 | preglow | a very gentle and nice god |
13:51:38 | nathanh | dircache is awesome, disk doesnt spin up when you move around the tree |
13:51:40 | preglow | rockbox without dircache is a pain to use |
13:51:47 | nathanh | thats a zillion times better than iriver firmware |
13:52:17 | linuxstb | nathanh: So building the cache at the same time as playback causes problems for you sometimes? |
13:52:19 | nathanh | i adore the fadeout/fadein when you pause... i owe a beer to whomever wrote that |
13:52:28 | nathanh | linux: yeah, not all the time, just once in a while |
13:56:30 | Slasheri | nathanh: that is probably caused by too long file names |
13:56:47 | Slasheri | recent unicode patch broke rockbox's support with long files |
13:57:11 | | Quit Kohlrabi (Read error: 104 (Connection reset by peer)) |
13:57:51 | nathanh | ahh, k |
13:58:11 | nathanh | is anybody working on gui code? id like to collaborate |
13:58:33 | nathanh | im looking at these screens -> http://www.mygigabeat.com/2005/05/screen-photos-of-gigabeat-f40.html <- and i want my rockbox to look the same :-) |
13:59:08 | preglow | Slasheri: why hasn't that been fixed yet? should be trivial |
14:00 |
14:00:18 | Slasheri | preglow: yes, but i don't know.. That doesn't matter whether the dircache is enabled or not.. When you encounter a long file name (for example browsing directories), rockbox instantly hangs needing to reset |
14:00:27 | aliask | nathanh: Maybe not look the same, but have the same amount of configureability. |
14:00:37 | preglow | yes, i know, why hasn't it been fixed in rockbox? |
14:02:14 | linuxstb | Slasheri: What do you mean by too long? You mean longer than MAX_PATH after being converted to utf-8 ? |
14:02:25 | Slasheri | preglow: i think the problem was that increasing MAX_PATH would also increase stack sizes.. But something has to be done on the file system level if it exceeds the MAX_PATH limit |
14:02:46 | Slasheri | linuxstb: yes, something like that. I don't know exactly what triggers the crash |
14:02:56 | Slasheri | only that long file names causes it |
14:03:43 | nathanh | why not use dynamically sized strings, rather than an array of [MAX_PATH+1] |
14:03:52 | linuxstb | preglow: Try http://www.davechapman.f2s.com/rockbox/statusbar.diff |
14:03:53 | preglow | we don't do dynamic allocation |
14:04:04 | nathanh | why not |
14:04:09 | Bger | urgh, this must go in the genreal FAQ |
14:04:10 | Slasheri | that would require to use dynamic memory allocation and it is not currently implemented |
14:04:14 | * | Bagder prepares for the why-not-malloc talk ;-) |
14:04:20 | preglow | nathanh: because we would have to reserve the max amount of memory anyway |
14:04:27 | preglow | nathanh: we might as well just do it statically |
14:04:41 | preglow | someone desperately needs to put up a faq entry on this |
14:04:55 | * | nathanh fears he has struck a nerve |
14:05:01 | Bagder | hehe |
14:05:09 | Bagder | nathanh: we have this conversation with all newcomers |
14:05:13 | linuxstb | nathanh: It's a question every new dev asks. |
14:05:27 | Bger | nathanh see, we want to use all available memory for buffer |
14:05:29 | nathanh | so its a frequently asked question |
14:05:33 | preglow | oh yes |
14:05:34 | Bger | yep |
14:05:38 | nathanh | if only there was some easy to deal with these frequently asked questions :-) |
14:05:49 | linuxstb | It's already patented |
14:06:31 | nathanh | so the buffer cant be dynamically resized, so theres no point in dynamically resizing whats left |
14:06:33 | nathanh | is that the argument? |
14:07:05 | preglow | nathanh: the argument is that if we were to have malloc, we also need to have a malloc buffer, which would mean we can't use that memory for file buffer anyway, so there's no point |
14:07:15 | preglow | nathanh: in practice, we would use _more_ memory than if we had used static allocation |
14:08:00 | Febs | Can anyone tell me what causes the "failed to load archos/_temp_codec.dll" error on the sim? I searched the IRC logs and saw this asked a few times, but never answered. |
14:08:01 | Slasheri | nathanh: the main problem is the fragmentation of memory, but that could be voided with refreshing the memory pointers |
14:08:17 | preglow | Slasheri: i don't see that as the main problem at all, the main problem is that it's pointless |
14:08:29 | | Quit tathamoddie () |
14:08:31 | Slasheri | preglow: hmm, true |
14:09:02 | preglow | Slasheri: you a) end up having to worry about memory leaks, b) will use more memory for malloc buffer than you did for static buffers in the first place |
14:09:13 | preglow | Slasheri: two negatives and no gains |
14:09:23 | preglow | plus, the code gets bigger |
14:09:26 | nathanh | not having dynamic heap is gonna make it hard to implement compositing |
14:09:33 | nathanh | which is my personal interest for coding |
14:09:39 | preglow | no, it's not |
14:09:43 | preglow | you just grab as much memory as you need |
14:09:48 | Slasheri | unless we would use that malloc buffer almost for everything allocation, then it would become more effective. But then we would have performance problems and the memory leaks |
14:09:52 | preglow | if you think you might need a megabyte, then you grab a megabyte |
14:09:57 | Slasheri | preglow: yes |
14:10:00 | nathanh | depends on the wps is the problem |
14:10:13 | nathanh | a wps with a dozen bitmaps might need 100kb, with a 100 bitmaps might need 1mb |
14:10:16 | Bger | nathanh you can ask for the audio buffer |
14:10:34 | Bger | hmm, but yes not for the wps |
14:10:36 | preglow | Slasheri: space-wise, using malloc will never be more effective than using static buffers, unless you're willing to run the risk of having malloc return NULL sometimes |
14:10:41 | nathanh | im guessing the audio buffer must be contiguous |
14:11:17 | Slasheri | preglow: yep, or we could just block the malloc until it succeeded (with the risk of dead-locking whole system) |
14:11:21 | preglow | yes... |
14:11:26 | preglow | in the end, i can't see any reason |
14:11:35 | preglow | if i don't have to use malloc, i'm all the merrier |
14:11:35 | nathanh | static allocation upfront certainly makes the system easier to debug |
14:11:41 | preglow | i hate having to free stuff |
14:12:07 | preglow | and why the hell people actually _want_ malloc, is beyond me |
14:12:09 | preglow | you're all crazy! |
14:12:11 | preglow | i mean !!! |
14:12:26 | nathanh | hehehe |
14:12:29 | Bger | hehehe |
14:12:31 | * | nathanh regrets asking |
14:12:32 | Bger | :) |
14:12:51 | preglow | we currently waste half a meg on malloc buffer for codecs :/// |
14:12:57 | Bger | nathanh the problem is not that u ask, but that nearly everyone asks ... |
14:12:58 | preglow | i'm sure that can be cut down on, though |
14:13:09 | preglow | Bger: and that i see it as blatantly obvious... |
14:13:22 | Bger | heh |
14:13:28 | nathanh | one benefit of a truly dynamic system - audio buffer too - is that the audio buffer could be a bit larger |
14:13:36 | Bger | btw, what's the interface between the h300's lcd and cpu ? |
14:13:36 | preglow | i wonder if i ever asked about this once upon a time |
14:13:36 | Bagder | no way |
14:13:38 | preglow | can't remember it now |
14:13:41 | nathanh | but i guess it dont matter too much |
14:13:46 | preglow | nathanh: no it wouldn't |
14:13:50 | preglow | nathanh: it would be smaller |
14:13:54 | Bagder | indeed |
14:13:56 | nathanh | hows that |
14:14:04 | preglow | because you have to reserve more memory for the malloc buffer |
14:14:06 | nathanh | because of the overhead? |
14:14:19 | nathanh | of storing the free list? |
14:14:20 | linuxstb | You don't want a malloc to fail - so you have to keep the memory unused. |
14:14:24 | Bger | preglow except the case when the audio buffer is dynamic also |
14:14:27 | nathanh | o i c |
14:14:31 | preglow | because of a) you can't ever be sure how much memory is going to be allocated, so you're going to have to overdesign the limit a bit. b) fragmentation will assure that you need even more space for the buffer |
14:14:54 | Bger | but yes, b)... |
14:15:19 | Bger | again |
14:15:20 | preglow | the malloc support data itself is also another matter |
14:15:32 | preglow | malloc also makes it difficult to use iram |
14:15:33 | Slasheri | another way could be to wait memory to be freed from the audio buffer, and then malloc that.. :) |
14:15:34 | Bger | what's the connection between the lcd and cpu in h300 ? |
14:15:35 | preglow | so there !!! |
14:15:41 | Bger | parallel or SPI |
14:15:49 | linuxstb | Slasheri: Stop!!! :) |
14:15:51 | nathanh | hahaha |
14:15:52 | Slasheri | hehe :D |
14:16:02 | Bger | Slasheri : that was what i wanted to say |
14:16:08 | preglow | would be the best status message ever |
14:16:21 | nathanh | do the .rock files have pre-alloc as well? |
14:16:29 | preglow | having to wrap every malloc with a lcd_puts that says "Trying to malloc, stand by!!!" |
14:16:39 | preglow | nathanh: yes |
14:16:40 | linuxstb | Unless the status message scrolled, in which case you would have no memory to scroll it... |
14:16:41 | Bger | nathanh there are 768kb reserved for plugins |
14:16:44 | Bger | on irivers |
14:16:49 | Bagder | "no memory received yet, we continue to wait..." |
14:17:06 | nathanh | where should i look to see the memory map |
14:17:19 | linuxstb | apps/rockbox.map in your build directory. |
14:17:19 | Bger | nathanh u can also get the audiobuffer from a plugin |
14:17:24 | nathanh | thx |
14:17:39 | Bger | plugin_get_buffer or something simillar |
14:18:00 | Bger | amiconn ? |
14:18:02 | linuxstb | Bger: That gets what is left out of the 768kb. There is also get_audio_buffer() or similar. |
14:18:45 | nathanh | that gapless on an ogg album is just _perfect_ |
14:18:50 | Bger | linuxstb u mean what lefts after loading the code of the plugin |
14:18:50 | mirak | it's a choice to not have the function headears in the .h ? |
14:19:08 | linuxstb | Bger: Yes - code and static data |
14:19:17 | Bger | uf, yes |
14:21:32 | nathanh | interesting, a long list of albums scrolls faster when music is playing than when its stopped |
14:21:39 | nathanh | im guessing that cpu_burst isnt enabled for list scrolling |
14:22:34 | linuxstb | nathanh: Correct. It will be sad if the CPU needs to be boosted just for the GUI code. |
14:22:52 | nathanh | it does need to be; button press events when holding the button occur faster than it can scroll |
14:23:02 | nathanh | or it needs scroll skipping |
14:23:18 | nathanh | currently the events queue up and when you let go of the button, it keeps scrolling for a few seconds |
14:23:23 | preglow | hehe |
14:23:32 | preglow | credits also scroll faster with music playing |
14:24:06 | linuxstb | nathanh: The alternative is to speed up the gui code. |
14:24:06 | | Quit HypnoticMonkey ("CGI:IRC (EOF)") |
14:24:35 | preglow | linuxstb: i wonder how we should handle that with click wheel scrolling |
14:24:43 | preglow | linuxstb: will be very awkward if that is boost dependant |
14:25:35 | nathanh | needs skip; the location in the list is determined by the button presses, but what the list displays is a best effort |
14:25:56 | linuxstb | I'm thinking the button driver could send page_down events. |
14:26:43 | linuxstb | Did you say that the hardware seems to have its own button queue? |
14:27:10 | nathanh | dunno, when i let go of the button it keeps scrolling for a bit |
14:27:21 | nathanh | and if i hold the down button, then let go and press left |
14:27:28 | nathanh | it scrolls for a bit and then jumps up a level in the tree |
14:27:29 | linuxstb | nathanh: Sorry, I was talking to preglow about the iPod :) |
14:27:34 | Bger | nathanh regarding scrolling: do you know that u can scroll one "page" at a time if you hold down the play button while pressing up/down |
14:27:45 | nathanh | well that's obvious!!! |
14:46:16 | | Quit nathanh ("Quit") |
14:46:56 | linuxstb | Any H300 owners around? Can you charge via USB without entering USB disk mode? |
14:48:27 | mirak | does rockbox works for big sound files over 30 megs for exemple ? |
14:48:57 | mirak | linuxstb: you can't charge and play at the same time |
14:49:05 | mirak | or use UMS |
14:49:13 | mirak | via USB |
14:49:38 | preglow | mirak: yes |
14:49:45 | linuxstb | mirak: You mean that you can either 1) Charge, 2) Use UMS or 3) play music |
14:49:54 | preglow | mirak: though it might have bugs, depends on the codecs |
14:49:56 | preglow | codec |
14:49:58 | mirak | is there some docs about the audi api ? |
14:50:07 | | Quit Nibbler (Read error: 110 (Connection timed out)) |
14:50:12 | linuxstb | Sadly not. |
14:50:16 | mirak | linuxstb: with usb yes |
14:50:20 | | Join Nibbler [0] (n=sven@port-212-202-77-101.dynamic.qsc.de) |
14:50:39 | mirak | you can't use UMS or listen music and charge at the same time via usb |
14:50:48 | Bger | linuxstb what about charging ? |
14:51:19 | Bger | h300 can be charged through USB |
14:51:22 | mirak | could you point me where a music reading sequence start in the code ? |
14:51:31 | linuxstb | Bger: mirak has answered - I was wondering if you could charge via usb at the same time as using the player normally to listen to music. |
14:51:48 | Bger | but when u charge it this way u can't do anything other with it |
14:52:07 | Bger | btw, i think it should be possible... |
14:52:23 | mirak | it would be cool |
14:52:43 | linuxstb | It's a question for Linus when he's next around. |
14:54:03 | linuxstb | I need to explore the same issues on the ipod - but the ipod does UMS in software so it should be more flexible. |
14:54:28 | preglow | it does? |
14:54:45 | linuxstb | I'm pretty sure it's a routine in flash. |
14:55:13 | markun | Doesn't the only have code to go into charging mode when you press a key and insert the USB cable? |
14:55:13 | mirak | wow the codec api seems tuff |
14:55:19 | markun | only->ondio |
14:55:20 | linuxstb | Also, the ipod appears in Linux with a hard disk model name of "ipod" - not the real hard disk model name. |
14:55:36 | linuxstb | So something odd is going on somewhere. |
14:55:44 | mirak | it's same for H300 |
14:55:56 | preglow | linuxstb: i get the ipod name here |
14:55:57 | mirak | /media/H300 |
14:56:01 | preglow | linuxstb: that is, what i named it in itunes |
14:56:23 | | Join Jungti1234__ [0] (n=jungti12@58.77.81.144) |
14:56:28 | Bger | linuxstb : for the h300 i'm pretty sure this info is written in the config eeprom of the usb->ata bridge |
14:56:36 | Jungti1234__ | hi |
14:56:45 | Bagder | yes, the ondio has the option to not go into UMS mode when you insert the cable |
14:56:48 | linuxstb | Bger: OK, that's possible. |
14:57:11 | mirak | the codec api redirect data directly to pcm device or is it possible to output to something else ? |
14:57:21 | preglow | linuxstb: that means we can do pretty much cool stuff in usb mode, then... |
14:57:23 | mirak | do we have the choice ? |
14:58:11 | linuxstb | preglow: In theory. I believe the IPL people are working on the usb hardware. |
14:58:20 | Bger | Jungti1234__ hi. could u translate this "A sibal jola jjajungna jakku ssang soriman nane!!!" |
14:58:28 | Jungti1234__ | -_- |
14:58:29 | linuxstb | Please!!! |
14:58:29 | Jungti1234__ | hey |
14:58:34 | Bger | :)) |
14:58:41 | Jungti1234__ | It means bad. |
14:58:44 | Jungti1234__ | very bad |
14:58:50 | mirak | I mean is the codec api reusable for something else than audio ? |
14:59:01 | mirak | than audio stream |
14:59:03 | Jungti1234__ | VERY!!!! |
14:59:17 | linuxstb | mirak: Are you thinking about video? |
14:59:18 | Bger | huh ... swear-word ? |
14:59:32 | mirak | linuxstb: yes ... I have no global view of what happens |
14:59:51 | mirak | linuxstb: some info would be welcolme. Maybe you can tell me where to look first |
14:59:55 | mirak | in the code |
14:59:57 | linuxstb | Yes, the existing codec api will work perfectly well for video with virtually no changes. |
15:00 |
15:00:01 | Bger | Jungti1234__ ? |
15:00:09 | linuxstb | You will just need a way to disable the display of the WPS. |
15:00:16 | mirak | linuxstb: you mean all the buffering part |
15:00:20 | linuxstb | Yes. |
15:00:24 | mirak | great |
15:00:45 | Jungti1234__ | hmm.. |
15:01:05 | linuxstb | The playback code is responsible for loading the data from disk and buffering it. You basically just access it as a stream via read() commands. |
15:01:23 | Jungti1234__ | Do you want translation? |
15:01:24 | linuxstb | And you have a function you can call to send audio data to the DSP. |
15:01:50 | mirak | linuxstb: ok. There is some exemple about how to use xvid, the interface is quiet simple |
15:01:57 | linuxstb | If it isn't there already, you will need to add the lcd functions to the codec api so you can write to the screen. |
15:02:19 | Bger | Jungti1234__ yes, please |
15:02:31 | linuxstb | The codec API is in apps/codecs.[ch] and the plugin API is in apps/plugin.[ch] - you can copy things that are in the plugin API and make them available to codecs. |
15:03:12 | linuxstb | But you probably just need a pointer to the lcd_framebuffer array, and the lcd_update() function. |
15:04:00 | Jungti1234__ | hmm |
15:04:44 | linuxstb | mirak: Does the decoder read the input data as a stream or does it do a lot of seeking? |
15:05:00 | Jungti1234__ | Bger: That's abusive. |
15:05:17 | linuxstb | It comes from the firmware of the MPeye MP3 player. |
15:05:22 | Bger | Jungti1234__ |
15:05:27 | Bger | heh, linuxstb said it before me |
15:05:34 | Bger | haha so abuses in the firmware |
15:05:49 | Jungti1234__ | a stream of abuse |
15:05:58 | Bger | something like "why the f*** are you looking here" ? :) |
15:06:06 | Jungti1234__ | f u c k |
15:06:31 | Jungti1234__ | Who used such word? |
15:06:39 | preglow | haha |
15:06:50 | preglow | some witty engineer who just stringed along some curse words |
15:07:05 | Jungti1234__ | He is bad guy. |
15:07:12 | preglow | like skeletor? |
15:07:21 | linuxstb | That's what using malloc does to you. |
15:07:22 | Zagor | ooh, nasty. illinstr during playback in archos version 2.5. |
15:07:36 | mirak | linuxstb: that's a stream, you put data from file into a buffer, then you give the buffer begining to the decode function. The decode function returns a used_bytes value that help you to know where you are in the buffer, then you call again the decode function with buffer+used_bytes |
15:07:53 | preglow | Zagor: easily reproducible? |
15:08:11 | mirak | linuxstb: output_data is a parameter that returns the decoded frame |
15:08:12 | | Join StrathAFK [0] (n=mike@dpc674681214.direcpc.com) |
15:08:16 | Jungti1234__ | = ¾Æ ¾¾¹ß Á¹¶ó Â¥Áõ³ª ÀÚ²Ù ½Ö¼Ò¸®¸¸ ³ª³×!!! |
15:08:20 | Zagor | yes, too easy. it happens every time I power up (resume = yes) |
15:08:22 | linuxstb | mirak: OK, so you can use the get_buffer() function to get a pointer to data in the codec buffer, and the advance_buffer afterwards to increase the codec buffer pointer by used_bytes. |
15:08:35 | Jungti1234__ | Did you see? |
15:08:39 | Jungti1234__ | kkk |
15:09:06 | linuxstb | mirak: The only problem is the buffer wraparound point. Do you know the maximum size of data that the decoder will consume? |
15:09:09 | Bger | Jungti1234__ only non-meaning letters |
15:09:23 | mirak | linuxstb: don't know |
15:09:53 | mirak | linuxstb: I guess it can't be bigger than a frame size |
15:10:03 | mirak | or two frames |
15:10:07 | linuxstb | mirak: You will probably need to decide on a maximum value for that. |
15:10:28 | mirak | linuxstb: I am not there yet. but any info are welcome |
15:11:06 | mirak | linuxstb: it would be usefull to have the function header in the .h file no ? |
15:11:07 | Jungti1234__ | Ah motherfucker shit pair voice sounds constantly!!! |
15:11:17 | Jungti1234__ | -_-; |
15:11:43 | Jungti1234__ | Short word: motherfucker |
15:11:48 | linuxstb | The get_buffer() function is guaranteed to return a pointer to a contiguous buffer containing the number of bytes you request ONLY if you request less than GUARD_BUFSIZE bytes (currently 32kb) |
15:12:00 | Jungti1234__ | Did you understand? |
15:12:15 | Bger | Jungti1234__ yes, enough |
15:12:26 | preglow | we should start a library of strings found in firmware |
15:12:31 | preglow | i bet there's tons of nice stuff |
15:12:32 | Bger | hahhaha |
15:12:33 | linuxstb | mirak: I don't understand your question. Which function(s) are you talking about? |
15:12:36 | Jungti1234__ | It's bad. |
15:12:47 | Jungti1234__ | Who said such word? |
15:13:06 | Bagder | Jungti1234: it is from the MPeye music player firmware image |
15:13:12 | Jungti1234__ | I will scare him. |
15:13:26 | mirak | linuxstb: since a .c is associated to a .h, the function in the .c can have their header into the .h. sort of to have the interface |
15:13:26 | Jungti1234__ | hahaha I know MPeye |
15:13:34 | Bger | Jungti1234__ we don't know ... someone who has been part of the development team of MPeye |
15:13:39 | Jungti1234__ | The company became dishonor. |
15:13:47 | mirak | linuxstb: rather than searching the functions into the .c files |
15:13:58 | Jungti1234__ | The company was ruined. |
15:14:14 | Bger | what ? are you sure ? |
15:14:14 | mirak | linuxstb: I have seen that into xvid code, that's easy to undertand and you can take only what you need |
15:14:32 | Bger | mirak afaik same is here |
15:14:36 | Jungti1234__ | MPeye was ruined!! |
15:14:41 | linuxstb | mirak: Only the functions exported from the .c file have their prototypes in the .h file. |
15:14:43 | Bger | but there are many "private" functions |
15:14:52 | mirak | linuxstb: ah ok |
15:14:53 | *** | Saving seen data "./dancer.seen" |
15:14:58 | mirak | ok |
15:15:01 | Bger | and they are not described in the header files |
15:15:08 | Jungti1234__ | hmm |
15:15:11 | mirak | nope lol |
15:15:16 | Jungti1234__ | I go to bed. |
15:15:18 | mirak | not muich description |
15:15:29 | Bger | nite, Jungti1234 |
15:15:44 | Jungti1234__ | You don't say such word. |
15:16:03 | Jungti1234__ | understand? :( |
15:16:05 | | Quit Strath (Connection timed out) |
15:16:22 | Jungti1234__ | bye |
15:16:22 | | Part Jungti1234__ |
15:17:26 | mirak | linuxstb: can I ask you a question ? |
15:17:35 | Bger | nite = good night ... |
15:17:41 | linuxstb | mirak: Was that the question? |
15:18:05 | Zagor | crash-casuing file (on archos rec20 v2.5): http://bjorn.haxx.se/illinstr.mp3 |
15:18:13 | mirak | linuxstb: I have some question about how it works. |
15:18:32 | mirak | linuxstb: for exemple, where is the starting point from the moment you click on an audio file |
15:18:41 | Zagor | no time to debug myself, unfortunately |
15:18:42 | mirak | I mean where does it start in the code |
15:19:49 | linuxstb | mirak: The playback code is in apps/playback.c - but I don't understand it. I only deal with the actual codecs themselves. |
15:20:13 | linuxstb | If you look at the source to some of the codecs in apps/codecs/ then that may give you a better idea. |
15:23:26 | mirak | I don't understand how the code is interfaced |
15:23:46 | | Quit g33 ("they call me snyggve because im so snygg") |
15:23:53 | mirak | I don't know generally how dynamic libraries works |
15:25:25 | mirak | that's not easy :-/ |
15:27:07 | linuxstb | The codec is loaded from disk into memory by the playback code, and then the playback code calls the codec entry function with a pointer to a "struct codec_api". That struct contains pointers to all the "external" functions that the codec can use. |
15:27:10 | mirak | ok that's all in th struct |
15:30:26 | mirak | linuxstb: ok so on e of the job is to have function that interface the codec side with the api right ? |
15:31:32 | mirak | ok it's clearer now |
15:31:42 | Jungti1234 | hehe |
15:31:43 | Jungti1234 | Bger |
15:31:59 | Bger | what ? |
15:32:09 | Bger | i mean, yes ? |
15:32:22 | mirak | hem so the codec is a thread in itself ? |
15:32:36 | Jungti1234 | I mean '"A sibal jola jjajungna jakku ssang soriman nane!!!" |
15:32:41 | mirak | ok codec_start that's says it all |
15:33:03 | Jungti1234 | bye :) |
15:33:05 | | Quit Jungti1234 ("Bye~ - http://cafe.naver.com/iriverh300") |
15:33:07 | Bger | hahaha |
15:35:07 | Bger | how should i interpret this reaction ? :) |
15:35:24 | amiconn | Bger: yes? |
15:35:51 | Bger | amiconn ... never mind i wanted to ask what's the interface between the lcd and cpu of h300 |
15:37:04 | Bger | is it parallel or spi ? |
15:38:13 | | Join webguest26 [0] (n=c2848364@labb.contactor.se) |
15:38:34 | webguest26 | is the bootloader for ipod out? |
15:38:41 | preglow | not exactly out |
15:38:44 | preglow | but it works |
15:38:52 | webguest26 | not out for public ? |
15:38:56 | preglow | correct |
15:39:22 | saa[b_r]ider | it's in CVS |
15:40:02 | preglow | ipod rockbox isn't exactly usable for the general public yet either |
15:40:53 | | Join Rob2222 [0] (n=Miranda@ACB71591.ipt.aol.com) |
15:40:56 | webguest26 | but how about colour support for rockbox h3xx ? anybody working on it ? saabrider? |
15:41:02 | saa[b_r]ider | btw, i told a friend of mine about the iPod port, and I'm trying to convince him to help you guys out with the coding :) only he has a 3G iPod |
15:41:34 | | Quit aliask ("Chatzilla 0.9.69 [Firefox 1.5/2005111116]") |
15:41:41 | preglow | saa[b_r]ider: hooray! we need someone to port to 3g :P |
15:42:03 | saa[b_r]ider | color is implemented in some of the plug-ins in the H300... |
15:42:26 | webguest26 | yeah i saw that in misticriver :D |
15:43:01 | saa[b_r]ider | preglow: to be honest, I'm not an iPod advocate, but Rockbox is cool, and I'd like to see it spread :) |
15:43:30 | | Quit Nibbler ("life is like a rental car, you fuck it up, and give it back.") |
15:43:46 | | Join Nibbler [0] (n=sven@port-212-202-77-101.dynamic.qsc.de) |
15:44:17 | webguest26 | yeah but i mean if we someday can have our own bitmaps on the background of rockbox? |
15:44:35 | saa[b_r]ider | any one know how colors are changed in plug-ins? |
15:45:06 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
15:45:25 | saa[b_r]ider | webguest: a lot of us think it would be great to have color in the H300... but many other things are more important. just wait |
15:46:02 | webguest26 | like what ?;) |
15:46:22 | Bger | like radio, recording ... |
15:46:33 | Bger | faster lcd updates ... |
15:46:38 | Bger | bootloader USB mode ... |
15:46:47 | saa[b_r]ider | if you noticed, there's also the flickering screen, and the low battery life... |
15:46:55 | linuxstb | beer... |
15:47:00 | saa[b_r]ider | I'd think these things are more important ;) |
15:47:24 | Bger | especially the last :) |
15:47:40 | webguest26 | okey i get it;) |
15:47:45 | saa[b_r]ider | as someone said, it should at least be on par with the H1x0 port, then they can start thinking of other stuff |
15:48:29 | | Join Rob2222 [0] (n=Miranda@ACB71591.ipt.aol.com) |
15:49:46 | saa[b_r]ider | i'm not a programmer, so bare with me... how are .rock files edited? |
15:49:58 | saa[b_r]ider | hex editor? |
15:50:21 | Bger | ??? |
15:50:23 | Bger | saa[b_r]ider ? |
15:50:30 | Bger | you usually edit the source |
15:50:35 | Bger | and after that recompile |
15:50:36 | | Join PaulJ [0] (n=PaulJ@vpn-3047.gwdg.de) |
15:50:38 | saa[b_r]ider | oh... |
15:50:54 | saa[b_r]ider | makes more sense :) |
15:51:36 | saa[b_r]ider | what would the source for pong be? |
15:51:50 | Bger | apps/plugins/pong.c |
15:52:17 | saa[b_r]ider | I swear, I must be blind :| thanks Bger :) |
15:52:23 | Bger | hehe for nothing |
15:54:43 | linuxstb | Does anyone actually play pong? I don't think I could persuade a friend it's a good way to pass the time... |
15:55:06 | saa[b_r]ider | probably snake is better... |
15:55:20 | Bger | hehe |
15:55:35 | saa[b_r]ider | I found it difficult to get the bats to move quickly enough to where the ball is heading |
15:55:49 | saa[b_r]ider | especially that you do it for both players! |
15:56:12 | linuxstb | But you get a nice "comet" effect on the h140 lcd. |
15:56:50 | saa[b_r]ider | and you get nice colors on the H340 LCD :D |
15:57:48 | saa[b_r]ider | linuxstb: j/k ;) "comet" you mean like a trail? |
16:00 |
16:03:13 | linuxstb | saa[b_r]ider: Yes. |
16:07:44 | | Quit webguest26 ("CGI:IRC") |
16:08:01 | preglow | hmm |
16:08:07 | preglow | i wonder what the cop does now, when an interrupt occurs |
16:08:46 | preglow | perhaps i need to enable interrupts for that too |
16:10:03 | linuxstb | Zagor: Your nice illinstr.mp3 file causes the iriver to just freeze when I try and play it. Now I need a paper clip... |
16:10:56 | Zagor | whee |
16:10:59 | preglow | what does foobar say about it? |
16:11:08 | linuxstb | It must be an id3v2 parsing bug. |
16:11:15 | Zagor | linuxstb: probably, yes |
16:11:30 | preglow | arGGH |
16:11:36 | preglow | i just curled it to stdio |
16:11:49 | linuxstb | Use wget :) |
16:12:13 | linuxstb | (Bagder's away, it's OK) |
16:12:34 | preglow | who the flaming fuck even connects the pc speaker anymore? |
16:12:40 | preglow | god, that was annoying |
16:15:20 | linuxstb | Have you had a chance to try disabling the ATA sleep command yet? |
16:18:29 | preglow | nope |
16:18:32 | preglow | will soon |
16:18:44 | steveb | is rockbox on the h340 functional? if i wanted to try it what should i expect? |
16:19:29 | linuxstb | You can read the forum dedicated to rockbox on the h340 here: http://forums.rockbox.org/index.php?board=6.0 |
16:19:38 | preglow | if you're lucky |
16:19:39 | linuxstb | Or the ones at misticriver.net |
16:19:47 | preglow | oy, it loads now |
16:19:49 | steveb | oh thanks |
16:19:55 | * | linuxstb forgets that he has changed his /etc/hosts |
16:20:07 | steveb | haha |
16:20:08 | steveb | i love that |
16:20:29 | steveb | i couldnt understand why my pc was going to localhost for a website that should be on my server |
16:20:33 | steveb | until i remembered... |
16:24:40 | | Quit San (Read error: 110 (Connection timed out)) |
16:24:53 | markun | linuxstb: pong on ipod would be cool. The wheel makes it more like the original game. |
16:27:32 | linuxstb | I would prefer breakout |
16:27:55 | linuxstb | How would two players use an ipod? |
16:27:57 | markun | a car racing simulator! :) |
16:28:30 | linuxstb | hehe |
16:29:33 | markun | If you could make a voip ap somehow you could use the wheel as an old fashion dial :) |
16:29:41 | markun | app |
16:30:26 | preglow | listening to some crossfeed samples now |
16:30:31 | preglow | looking forward to see what's what |
16:34:45 | markun | can't you tell by the volume difference? |
16:35:00 | preglow | guess i can, though it wasn't as drastic as i remember |
16:35:07 | preglow | 2.wav sounds the worst of them |
16:35:51 | preglow | i think i like 3.wav best |
16:38:41 | | Join amar [0] (n=502c706b@labb.contactor.se) |
16:39:17 | preglow | what was the setup again? one was the crossfeed we have now, one was the new one, and the last was...? |
16:39:50 | markun | don't know. Maybe 1 is the original? |
16:40:49 | preglow | i assume lsd1.wav is the original, yes |
16:40:55 | preglow | but can't remember what the remaining one is |
16:41:50 | preglow | anywho, gotta dinner |
16:47:20 | | Join lamed [0] (n=d4b3395e@labb.contactor.se) |
16:48:57 | lamed | hello |
16:50:35 | XavierGr | Hi |
16:50:51 | steveb | are the rockbox forums down? |
16:51:44 | Lynx_ | no |
16:51:57 | steveb | i cant connect :-/ |
16:52:17 | Lynx_ | works for me... |
16:52:32 | steveb | what ip is it resolving to? |
16:52:38 | Zagor | the address has changed |
16:52:44 | Zagor | ip address |
16:52:53 | steveb | to what? |
16:53:23 | Zagor | 72.29.70.124 |
16:54:01 | Lynx_ | when the h340 is i usb mode, will it use usb power? |
16:56:17 | | Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-131-040.pools.arcor-ip.net) |
16:57:55 | lamed | xaviergr, can you give me t0mas's email in a private message? |
17:00 |
17:01:42 | XavierGr | ok |
17:01:45 | | Join Mark__ [0] (n=Mark@ACCA8508.ipt.aol.com) |
17:01:59 | Mark__ | hai |
17:05:11 | Bger | nite |
17:07:49 | | Quit Febs (Read error: 110 (Connection timed out)) |
17:14:57 | *** | Saving seen data "./dancer.seen" |
17:22:19 | mirak | linuxstb preglow a scratch turn table on the ipod |
17:22:26 | mirak | a virtual scratch turn table |
17:22:46 | mirak | szouick chou szouick |
17:23:17 | mirak | hum not preglow, markun |
17:29:49 | mirak | ping |
17:33:06 | | Join muesli_- [0] (i=muesli_t@Bc143.b.pppool.de) |
17:33:51 | lamed | guys, can recorders do f1 + on button? |
17:34:32 | | Join _FireFly_ [0] (n=FireFly@p54A448D0.dip.t-dialin.net) |
17:35:35 | lamed | someone? |
17:37:40 | Weazel_ | what you mean? |
17:37:41 | lamed | wasn't i clear with my question? - can I bind BUTTON_F1 | BUTTON_ON for the recorder? |
17:40:55 | linuxstb | lamed: apps/viewer.c does it, so I guess the answer is yes. |
17:41:25 | lamed | lazy me.. tt |
17:47:03 | preglow | mirak: hah |
17:47:08 | preglow | mirak: that's a bloody _GREAT_ idea |
17:48:03 | lamed | may i ask a db question? |
17:48:38 | preglow | just ask |
17:50:01 | | Quit YouCeyE ("Leaving") |
17:50:26 | lamed | with the current db volume system, does increasing the volume by one, increase the output strength by 1 decibel? |
17:54:38 | preglow | yes |
17:54:42 | preglow | relative to the previous level |
17:54:51 | lamed | so what did it actually did before? |
17:55:00 | preglow | something more arbitrary |
17:55:13 | preglow | i'm not completely certain |
17:55:19 | lamed | could it 'devide' a db? |
17:55:23 | preglow | yes |
17:55:29 | lamed | would the hardware alow that? -cool |
17:55:31 | perplexity | So in theory.. at 0db with flat eq it should not clip.. _ever_ ? |
17:55:40 | preglow | lamed: the hardware allows finer adjustments than one db |
17:55:40 | lamed | i should clip |
17:55:48 | preglow | perplexity: correct |
17:56:00 | preglow | perplexity: the only clipping will clipping that is already in the audio |
17:56:12 | perplexity | Ok then.. the natural extension of that says that at -10dB with 10dB Bass gain it should not clip ? |
17:56:12 | preglow | insert 'be' after 'will'æ |
17:56:19 | preglow | correct |
17:56:25 | perplexity | Ok.. it does.. |
17:56:35 | preglow | but be aware that it may clip _before_ entering the hardware |
17:56:40 | lamed | preglow: so, by what you said now, file audio level could not exceed 0 db right? |
17:56:51 | perplexity | and these are clean mp3's/ogg's that play nicely if I crank the vol another 3db down |
17:56:57 | preglow | lamed: no, it can't, but it will very often try |
17:57:04 | preglow | lamed: resulting in clipping in the decoder, which is a different matter |
17:57:08 | preglow | lamed: which can be fixed by replaygaimn |
17:57:16 | | Quit einhirn (Read error: 110 (Connection timed out)) |
17:57:32 | preglow | perplexity: yes, but you'd need a software gain control for that |
17:57:42 | preglow | currently, the only way to fix it is by using replaygain |
17:57:51 | lamed | could a different decorder do it right - without clipping? |
17:57:56 | preglow | no |
17:58:09 | preglow | you would have to 1) replaygain, or 2) gain the audio down _before_ encoding |
17:58:51 | perplexity | Umm.. ok.. hang on.. what I meant was the track in question is nicely balanced and plays with no distortion if I run it at -13dB with 10dB bass boost.. but with -10dB and 10dB bass boost it clips.. this is a software clip? Where is the eq applied on a h3x0 ? |
17:58:57 | lamed | ah.. so you mean there is a limitation on the file... which will cause the waveform to be corrupted |
17:59:15 | preglow | yes |
17:59:40 | preglow | perplexity: no, it wont clip at -10db and 10db bass boost |
17:59:43 | preglow | perplexity: it will _just_ not clip |
17:59:50 | lamed | and to a different matter: I'm in a hurry, i've made a pitch screen fix. who can accept it... fast please i'm late for a bus |
17:59:51 | preglow | perplexity: but that's only the eq we're talking about |
18:00 |
18:00:00 | preglow | lamed: just put in somewhere |
18:00:01 | preglow | patch tracker |
18:00:03 | preglow | or dcc it to me |
18:00:07 | perplexity | Ok.. well it is distorting in some way.. |
18:00:11 | lamed | how do i dcc? |
18:00:23 | preglow | lamed: can't you put it in the patch tracker? |
18:00:51 | lamed | preglow: it's down. what's your mailbox...fast... |
18:00:57 | preglow | mail it to preglow@gmail.com |
18:01:28 | perplexity | I guess it's possible my cassette converter is low enough impedance that it's causing the output stage on the headphone amp to clip.. |
18:01:36 | _FireFly_ | sf isn't really down but slow |
18:03:07 | lamed | it's sent cya alll I"m sooo late.... |
18:03:43 | preglow | not everyday i receive a file named pitch.patch :P |
18:03:51 | _FireFly_ | lol |
18:03:54 | _FireFly_ | nice name |
18:04:13 | _FireFly_ | it sounds like plitsch-platsch if you speak it ;) |
18:04:19 | preglow | hahah, yes |
18:06:48 | | Join San [0] (n=sanitari@212.2.174.33) |
18:08:30 | | Quit lamed ("CGI:IRC (Ping timeout)") |
18:08:58 | | Join Febs [0] (n=40326e83@labb.contactor.se) |
18:10:50 | | Join muesli- [0] (i=muesli_t@Bbc73.b.pppool.de) |
18:11:14 | | Join Acksaw [0] (i=Acksaw@spc1-stok5-4-0-cust5.bagu.broadband.ntl.com) |
18:11:15 | mirak | hem I am a bit stuck on how to integrate the source code to rockbox |
18:11:24 | Acksaw | Hey |
18:11:25 | mirak | about the make etcetera |
18:11:53 | perplexity | Look at the way the other codecs do it mirak.. it's not terribly difficult |
18:12:30 | mirak | I have some lacunes with make |
18:12:47 | mirak | I will try |
18:16:21 | linuxstb | preglow: Are you going to commit your button driver to CVS soon, or can I have a patch? I've optimistically started work on the audio driver... |
18:17:15 | preglow | ahhh |
18:17:18 | preglow | i'll work on it now |
18:17:21 | preglow | hahaha |
18:17:28 | preglow | the blind guy who reviewed us is back |
18:17:31 | preglow | now with a dead unit |
18:21:52 | lostlogi1x | perplexity: any luck with that replacement of the imdct in vorbis? |
18:22:01 | | Nick lostlogi1x is now known as lostlogicx (n=lostlogi@node-4024215a.mdw.onnet.us.uu.net) |
18:22:01 | DBUG | Enqueued KICK lostlogicx |
18:22:58 | perplexity | Have got it working.. but I'm actually busy learning about the math behind mdct and fft at the moment so I can get serious about optimising.. so I'm away from the code and nose down in the books |
18:23:09 | mirak | is flac usable actually ? |
18:24:10 | preglow | mirak: usable how? |
18:24:12 | linuxstb | Of course. |
18:24:22 | preglow | the format itself is decent, and rockbox support is pretty good |
18:24:40 | lostlogicx | perplexity: neat −− way over my head. |
18:24:42 | mirak | preglow: usable in term of power |
18:24:47 | preglow | mirak: in term of battery, you mean? |
18:24:49 | preglow | mirak: if so: yes |
18:24:51 | linuxstb | You can get about 12-13 hours playback with FLAC |
18:24:56 | mirak | preglow: in term of cpu |
18:24:58 | mirak | but seems yes |
18:25:00 | preglow | mirak: i actually believe flac will keep my player going longer than ogg |
18:25:11 | linuxstb | That's a h140 with a standard battery and "flac -8" encoded files. |
18:25:19 | mirak | ok |
18:25:24 | | Quit muesli_- (Read error: 110 (Connection timed out)) |
18:25:30 | perplexity | it's way over my head at the moment also lostlogicx, i've had to go back to all my math and relearn a lot of it.. don't use it you lose it, and i've not used it in 15 years |
18:25:42 | preglow | haha |
18:25:55 | preglow | the clever part is having interests such as these while you learn it |
18:25:59 | mirak | perplexity: I have lost it in six months |
18:26:03 | preglow | it even made me apply myself in school |
18:26:09 | preglow | which did not happen often |
18:26:11 | perplexity | indeed preglow :) |
18:26:39 | perplexity | I have changed my minor at university (I'm studying part time) to include some heavier math courses.. I need to sharpen the old brain again |
18:27:03 | mirak | you are retired ? |
18:27:25 | perplexity | not even close.. only 31 |
18:27:47 | mirak | and you did fft in high school ??? |
18:28:02 | mirak | not even, in schoo |
18:28:04 | perplexity | yep.. year 12 math and physics.. |
18:28:04 | mirak | school |
18:28:22 | mirak | huh ! where do you live ? |
18:28:23 | preglow | perplexity: it really is worthwhile if you get to apply it |
18:28:33 | preglow | math isn't that hard, you just need to practice |
18:28:35 | perplexity | I'm living in Dubai now, but I'm Australian |
18:28:52 | perplexity | indeed preglow, and you need an interest to make you want to learn.. rockbox has done that nicely |
18:29:12 | preglow | yup |
18:29:36 | mirak | perplexity: so how old where you exactly when you did fourier ? |
18:29:51 | mirak | were |
18:29:56 | perplexity | err.. about 17 |
18:30:13 | perplexity | but it was for my final year physics project, so it's not something the whole school studied |
18:31:08 | mirak | that's pretty much advanced indeed for 17 |
18:31:17 | perplexity | I was bored :) |
18:32:17 | perplexity | mirak back at that time I only understood a little of the math, it was more application of the algorithms.. now I'm learning the math in depth |
18:32:42 | preglow | i learnt about ffts and stuff around then |
18:32:45 | preglow | but it was on my spare time |
18:32:59 | preglow | took me a while before i truly understood it, though |
18:33:09 | perplexity | We had an entire 6 months free time to do our final project, so I had heaps of time to learn |
18:33:11 | | Quit muesli- (Read error: 104 (Connection reset by peer)) |
18:34:10 | perplexity | I don't claim to understand anything at the moment, but the picture is slowly coming into focus.. more time and contemplation over a scotch required yet |
18:35:38 | | Part Polo_o |
18:36:19 | perplexity | Ok, I'm crook as a dog, so gonna have an early night.. later all :) |
18:36:23 | | Quit perplexity ("*pop*") |
18:37:46 | | Quit Acksaw () |
18:38:34 | mirak | hem what's the difference between shared and static library ? |
18:38:46 | preglow | shared libraries are located in separate files |
18:39:02 | preglow | so they don't occupy space in each program that uses them |
18:39:40 | mirak | in the case of rockbox it's a static library ? |
18:39:55 | preglow | yes |
18:40:10 | preglow | no point in implementing shared libs on a platform with just one application :-) |
18:40:15 | preglow | shared libraries are bit more inefficient |
18:41:00 | mirak | hem I see no configure files in the codecs folders, what's the approach used to "configure" |
18:41:25 | preglow | hmm? |
18:41:33 | preglow | there's just one configure, and that's for all of rockbox |
18:41:50 | mirak | I have the codec source folder of xvid |
18:41:55 | linuxstb | mirak: You need to remove all that autoconf bloat |
18:42:25 | mirak | it's all in a buildir, it should be easy |
18:42:38 | mirak | however recreating something for it to compile ... |
18:43:00 | linuxstb | You should probably run configure once to get a config.h file, and then manually change that config.h file for Rockbox. You should also rename it to something like xvid_config.h |
18:43:22 | linuxstb | (to avoid conflicts with Rockbox's own config.h) |
18:43:31 | mirak | ok |
18:43:47 | amiconn | w00t! Nextup now offers ScanSoft RealSpeak voices :-) |
18:44:40 | amiconn | These are really good quality, and are available for a lot more languages that AT&T |
18:45:24 | amiconn | *than |
18:46:17 | | Join DrumRBoy|Away [0] (n=Drumrboy@ool-44c20ff1.dyn.optonline.net) |
18:49:55 | markun | mirak: I would prefer ffmpeg over xvid because ffmpeg has asm optimisations for ARM |
18:50:27 | mirak | ffmpeg is a bit big |
18:51:13 | mirak | wait |
18:52:02 | markun | you don't need all of it, only the parts relevant to mpeg-4 |
18:52:28 | mirak | markun: yes but stripping it is an extra job I am not even sure to be able to do |
18:53:05 | mirak | I think that ffmpeg uses just an interface to xvidcore |
18:53:57 | linuxstb | markun: I'm sure I've asked this before, but does Toshiba's firmware play any video on the gigabeat? |
18:54:16 | markun | no, it doesn't |
18:54:33 | | Quit Kohlrabi ("Leaving") |
18:54:45 | | Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-131-040.pools.arcor-ip.net) |
18:55:38 | mirak | markun: where is the code of the codec ? |
18:55:51 | mirak | I have ffmpeg I started to look at it |
18:56:03 | mirak | then I focused on xvidcore |
18:56:29 | markun | mirak: I'm looking at this file now: http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/mpegvideo.c?rev=1.491&content-type=text/x-cvsweb-markup&cvsroot=FFMpeg |
18:56:51 | linuxstb | Does xvidcore just decode video frames? Or does it deal with the avi (or whatever) container and the demultiplexing? |
18:58:13 | | Quit San (Read error: 110 (Connection timed out)) |
19:00 |
19:02:32 | | Quit Febs ("CGI:IRC (EOF)") |
19:02:33 | mirak | only the xvid stream I think |
19:02:52 | preglow | bah, this takes forever |
19:02:57 | preglow | i should probably just make you a patch |
19:03:21 | | Join Mmmm [0] (n=mscarrat@cpc4-hem13-3-1-cust63.lutn.cable.ntl.com) |
19:03:22 | mirak | a patch for xvid ? preglow ? |
19:03:27 | preglow | talking to linuxstb |
19:03:34 | mirak | ok |
19:03:43 | mirak | it was a bit arch |
19:03:48 | mirak | lol |
19:04:03 | Mmmm | Firefly: you know that patch I tested yesterday? |
19:04:05 | | Quit drumrboy (Read error: 110 (Connection timed out)) |
19:04:32 | mirak | markun: don't know what to say, I only see an encoder |
19:04:37 | mirak | markun: in that file |
19:04:49 | markun | mirak: yes, most code if for encoding |
19:05:22 | mirak | markun: well anyway the hardest part is probably to write a xvid.c file for rockbox |
19:05:38 | mirak | I guess the codecs can be used similarly |
19:06:59 | | Part XavierGr |
19:08:44 | _FireFly_ | Mmmm: yepp |
19:09:45 | Mmmm | Well... I've been using it all day and it has actually fixed my skipping ogg problem!!! :o |
19:09:52 | mirak | markun: xvidcore is easier to understand, I don't know about you |
19:10:00 | _FireFly_ | Mmmm: really ?? |
19:10:42 | _FireFly_ | have you synced with the latest cvs when testing this patch ?? |
19:11:54 | Mmmm | Yes!! Its funny how i said that all you had to do was fix that, and all along you already had! Havent synced yet. |
19:12:17 | _FireFly_ | a nice sideeffect :) |
19:12:56 | Mmmm | It certainly is.. hee hee... I cant believe it! |
19:13:20 | _FireFly_ | i only want to fix the image-flicker and now it seams that it also fix a skipping problem with oggs ;) |
19:13:45 | Mmmm | I suppose it must have taken a bit of load off the processor eh? You're a genius... |
19:13:48 | _FireFly_ | s/want/wanted |
19:14:01 | markun | mirak: good luck, I have to go now |
19:14:03 | _FireFly_ | Mmmm: yeah it seams so |
19:14:35 | _FireFly_ | if i had cvs-write rights i think i would commit it :) |
19:14:58 | *** | Saving seen data "./dancer.seen" |
19:15:14 | Mmmm | It should be done! Noone else seemed to have the same problem as me though.. |
19:16:01 | _FireFly_ | now it seams this patch has 3 advantages 1. it solves the image-flicker-problem(at least for the h1xx remote-lcd) 2. reduces the code-size about 84 Bytes 3. it solves a skipping-problem with ogg-files |
19:16:53 | Mmmm | You would think that any self respecting dev would commit something like that in a shot eh? ;) |
19:17:44 | | Join Acksaw [0] (i=Acksaw@spc1-stok5-4-0-cust5.bagu.broadband.ntl.com) |
19:17:56 | Acksaw | is muesli here? |
19:18:08 | _FireFly_ | no |
19:18:22 | _FireFly_ | currently not or he has changes is nick in the chan |
19:19:47 | Mmmm | Although, firefly, I must admit that i hadnt tested before i applied that patch, It could have been the previous flicker commit! |
19:20:15 | Mmmm | So I will test that now.... |
19:20:37 | _FireFly_ | Mmmm: this patch is the simplified version of the two patcher |
19:20:44 | _FireFly_ | patches |
19:21:50 | _FireFly_ | the first one had solved the flicker-problem but introduce a louder remote-ticking-noise on "infected" h1xx-devices |
19:22:17 | Mmmm | Yes.. What I mean is that the unsimplified version may have already fixed the skipping problem. |
19:22:20 | _FireFly_ | the second one had solved the introduces louder ticking-noice from the first patch |
19:22:43 | _FireFly_ | Mmmm: could be |
19:23:02 | | Join rh [0] (n=chatzill@p5493344A.dip0.t-ipconnect.de) |
19:23:08 | preglow | linuxstb: you doing a proper audio driver? |
19:23:26 | Mmmm | 3 patches yes? 1st increased ticking, 2nd is in cvs 3'rd i tested. i'm talking about 2'nd :) |
19:24:07 | Acksaw | anyone here good with pc hardware. |
19:24:08 | Acksaw | ? |
19:24:13 | _FireFly_ | 1st gots commited then the louder ticking was discovered then i made the second one which gots also commited |
19:24:43 | Mmmm | That's what i thought :D |
19:24:51 | | Quit Cassandra (" HydraIRC -> http://www.hydrairc.com <- Go on, try it!") |
19:24:58 | Mmmm | hee hee.. do you know what i mean? |
19:27:02 | rh | anybody here who knows the status of the fm-radion on h3xx? |
19:30:33 | | Join linuxstb_ [0] (n=5343d4aa@labb.contactor.se) |
19:30:46 | linuxstb_ | preglow: There's no point doing anything else. |
19:33:25 | preglow | well, you were talking about a dummy driver |
19:34:34 | linuxstb_ | I'll probably get to that stage first. |
19:34:54 | preglow | ok |
19:36:32 | | Quit rh ("Chatzilla 0.9.69 [Firefox 1.5/2005111116]") |
19:38:16 | preglow | ahh, sixth day of non-stop rain |
19:38:37 | preglow | at least i can stay inside without any second thoughts |
19:38:39 | _FireFly_ | what ?? really 60 days |
19:38:52 | Mmmm | Firefly: ok, tested and it seems that the version already in cvs (patch2) has fixed the problem...and that's not all. I was having difficulty seeking in oggs too and that is also fixed! |
19:38:53 | _FireFly_ | ups |
19:38:54 | preglow | sixth <- |
19:39:05 | _FireFly_ | preglow: yeah |
19:40:31 | _FireFly_ | preglow: i have sixth mixedup with sixty |
19:40:39 | preglow | so i see |
19:40:53 | _FireFly_ | sometime i*m reading to fast |
19:41:01 | _FireFly_ | sometimes |
19:41:19 | _FireFly_ | s/to/too |
19:42:30 | _FireFly_ | Mmmm: also with the simplified version ?? |
19:43:32 | Mmmm | Yep, simplified version from a users point of view is identical. |
19:43:44 | _FireFly_ | ok |
19:43:50 | _FireFly_ | good to hear :) |
19:46:46 | | Join Strath [0] (n=mike@dpc674681214.direcpc.com) |
19:46:47 | Mmmm | I've gotta go now...tons of thanks firefly... Now, how can I add to the playlist on the fly with the remote... hmmmm.. :D |
19:47:27 | _FireFly_ | Mmmm: long press play on the remote is the same as long press select(joystick) |
19:47:48 | | Quit StrathAFK (Read error: 104 (Connection reset by peer)) |
19:47:54 | Mmmm | WOW... heh heh...silly me! cheers ;) |
19:48:48 | | Quit Mmmm ("DINNER TIME!!") |
19:49:33 | | Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU) |
19:52:06 | | Join RotAtoR [0] (n=e@12-210-82-91.client.insightBB.com) |
19:52:06 | | Quit zeero (Read error: 110 (Connection timed out)) |
19:55:51 | preglow | RotAtoR: yo, plase work on prettier gems in bejeweled :-) |
19:56:09 | preglow | RotAtoR: gweled has svg format graphics, so should be a breeze to make custom size jewel bitmaps |
19:56:56 | Moos | really good idea |
19:59:46 | wubbla | anyone using mp3gain? |
20:00 |
20:00:03 | wubbla | would you guys recommend to use this tool? |
20:00:13 | Moos | sorry, foobar2k here |
20:02:01 | | Join petur [0] (i=petur@d54C1B62E.access.telenet.be) |
20:05:44 | PaulJ | wubbla: do you want to change the volume of the mp3s directly or do you only want to add rplaygaintags? |
20:07:41 | wubbla | PaulJ: i'd prefer replaygain tags (as it doesn't change the files and it's reversible AFAIK)... |
20:08:17 | RotAtoR | preglow: I'm looking at that right now :) |
20:08:19 | wubbla | and as rockbox does support replaygain, there shouldn't be any point in changing the mp3s directly, right? |
20:08:35 | _FireFly_ | yepp |
20:08:45 | RotAtoR | and looking at getting bejeweled working well on that *&#%$ ipod click wheel |
20:09:06 | PaulJ | then i would suggest to use foobar2000, because mp3gain adds the replaygaininfo to apev2 tags and rockbox wouldnt recognize them |
20:09:08 | RotAtoR | just finished exams, so now I have a little time :D |
20:09:48 | wubbla | PaulJ: you're sure about that? |
20:10:47 | Moos | PaulJ: with last version of mp3gain, it add tag to APEv2, and doesn't suported yet for mp3's in Rockbox |
20:10:55 | Moos | oops wubbla :) |
20:11:16 | PaulJ | i'm using version 1.2.4 |
20:11:37 | PaulJ | the helpfile says "MP3Gain stores "Analysis" and "Undo" information in special tags inside the mp3 file itself. These tags are in the APEv2 format." |
20:12:11 | Moos | yeah and don't apev2 tag for mp3 yet |
20:12:18 | wubbla | PaulJ: ok, that's an argument :-) |
20:12:19 | Moos | in Rockbox |
20:13:09 | wubbla | PaulJ: then i'll look into foobar2000's replaygain support... |
20:15:02 | wubbla | PaulJ: can you point me to a howto? |
20:15:27 | | Quit DJDD_ (Read error: 104 (Connection reset by peer)) |
20:16:10 | RotAtoR | hmm, does anyone know of a good tool to convert an svg graphic into a raster graphic in windows? |
20:17:09 | PaulJ | http://www.foobar2000.org/ |
20:17:32 | wubbla | ;-) |
20:18:08 | dpassen1 | wubbla: http://www.iriver.us/showthread.php?t=26025 |
20:19:11 | wubbla | dpassen1: wow! thanks! |
20:22:31 | | Quit Acksaw (Read error: 110 (Connection timed out)) |
20:29:46 | | Join AnInternetUser [0] (i=oups@ny-lancastercadent4g1-3d-b-34.buf.adelphia.net) |
20:30:27 | AnInternetUser | hello can anyone explain exactly what ata error 11 is? |
20:30:55 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
20:35:45 | preglow | linuxstb_: if i'm stalling you, i can make you a patch |
20:36:00 | preglow | might not finish it today either |
20:36:23 | preglow | i've broken it now, but i kept the old tree around so i can make you a patch |
20:37:25 | | Join xmixahlx [0] (n=xmixahlx@64.122.111.98) |
20:37:59 | preglow | i never made a patch from cvs before, is it just a matter of doing a cvs diff ? |
20:38:11 | AnInternetUser | can anyone explain the difference between ata error 11 and 32? |
20:38:21 | _FireFly_ | preglow: cvs diff -u > file :) |
20:38:23 | _FireFly_ | -u for unified diff |
20:38:31 | preglow | i've got -u as default |
20:38:50 | _FireFly_ | ok |
20:40:24 | | Join San [0] (n=sanitari@212.2.183.33) |
20:41:22 | preglow | linuxstb_: www.pvv.org/~thomj/rockbox/ipodkeys.patch |
20:41:45 | RotAtoR | hmm, it looks like rgb565 bitmaps are byte swapped between iriver and ipod? |
20:41:47 | linuxstb_ | preglow: Thanks. |
20:41:56 | linuxstb_ | RotAtoR: Yes :) |
20:41:59 | preglow | just keep the patch around so you can undo it |
20:42:07 | RotAtoR | so is there a good way to determine which to use? |
20:42:17 | RotAtoR | in code, that is |
20:42:18 | linuxstb_ | LCD_PIXELFORMAT |
20:42:25 | RotAtoR | ahh, ok, thanks |
20:42:34 | _FireFly_ | does it define RGB or GBR ?? |
20:42:35 | linuxstb_ | RGB565 and RGB565_BYTESWAPPED (I think - check lcd.h) |
20:42:43 | _FireFly_ | or so :) |
20:42:47 | RotAtoR | thanks :) |
20:42:57 | linuxstb_ | It's not GBR |
20:43:06 | preglow | BGR, yes? |
20:43:07 | _FireFly_ | hmm |
20:43:18 | _FireFly_ | ups yepp |
20:43:21 | amiconn | Not BGR either |
20:43:30 | _FireFly_ | whats then ?? |
20:43:38 | linuxstb_ | RGB565 byte swapped |
20:43:41 | linuxstb_ | :) |
20:43:44 | amiconn | It's more like G3B5R5G3 |
20:44:02 | preglow | the purdiest format in the world |
20:44:06 | RotAtoR | haha, ;) |
20:44:12 | preglow | makes jesus cry |
20:44:21 | | Quit AnInternetUser () |
20:44:23 | _FireFly_ | amiconn: ah right it isn't RGB888 |
20:44:25 | | Join hshah [0] (n=hshah@shahassociates.plus.com) |
20:44:27 | linuxstb_ | All to save us some byte-swapping when updating the LCD. |
20:44:40 | preglow | i say it's worth it |
20:44:55 | preglow | esp since we don't have a byte swap instruction |
20:45:04 | hshah | is it just me or have the forums been down for a few days? |
20:45:13 | linuxstb_ | I agree - it makes RotAtoR's life harder though. |
20:45:15 | preglow | hshah: they're up now, depending on your iså |
20:45:15 | _FireFly_ | hshah: it was shorly up |
20:45:21 | preglow | isp |
20:45:40 | petur | Anybody around that knows what read_hw_mask() does? |
20:45:40 | hshah | ok - thanks |
20:46:02 | petur | except mask = *(short *)0x020000fc; |
20:46:05 | hshah | now... can anyone commit my wps for me - TiMiD was going to do it... but hes like disappeared off the face of the Earth... |
20:46:20 | amiconn | petur: read_hw_mask() is archos only |
20:46:28 | petur | ugh |
20:47:30 | RotAtoR | all these various bitmap types and screen sizes are making the bejeweled code almost 50% different bitmap definitions |
20:47:39 | RotAtoR | :p |
20:47:42 | Bagder | hehe |
20:47:45 | amiconn | It reads a certain byte in ROM that tells us about subtle hardware differences |
20:47:52 | preglow | can't you just use a macro per value to make the compiler bitswap for you? |
20:47:55 | petur | got to read that code that inits the radio 3 times - it's not at all clear what it tries to do to the hardware :( |
20:48:35 | petur | oh... it skips it completely ;) |
20:48:38 | linuxstb_ | preglow: I was thinking that - it would mean adding a new output format to bmp2rb (or merging the two existing 16-bit formats) |
20:48:48 | RotAtoR | preglow: hmm, i'm not sure how i'd go about doing that |
20:48:54 | preglow | like '#define _(x) dothebitswap(x) \n short mycolourtable[] = { _(0xvalue1), _(0xvalue2), ... } |
20:49:35 | preglow | what would also work is just building the bitmap headers at compile time |
20:49:43 | preglow | from bitmaps |
20:49:55 | | Join Lear [0] (n=chatzill@h73n11c1o285.bredband.skanova.com) |
20:49:57 | Bagder | that's actually a rather good idea |
20:49:57 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
20:49:57 | * | linuxstb_ prods Bagder |
20:50:09 | RotAtoR | preglow: too fancy for me :) |
20:50:24 | Bagder | since the lcd variations are gonna add up even more in the future |
20:50:30 | preglow | yup |
20:50:37 | preglow | you'll still have various bitmaps, though |
20:50:40 | preglow | since bitmap size will change |
20:50:46 | Bagder | true |
20:50:52 | preglow | but yeah, colour wise we'll be fine |
20:50:59 | linuxstb_ | We will hopefully get another 2-bit greyscale format as well soon with the greyscale ipods |
20:51:26 | preglow | but stuff like differing formats for the same dimension and rough display type will work |
20:52:20 | linuxstb_ | But does anyone still have the original bitmaps that have been used everywhere? It would mean generating the bmp files for the existing bitmaps |
20:52:27 | preglow | and if implemented properly in the build system, it'll be prettier than what we do now anyway |
20:52:55 | preglow | linuxstb_: if not, it's not worse than just making new bmps from the headers |
20:53:59 | wubbla | hmm... |
20:54:22 | wubbla | replaygain doesn't seem to work for me.... :'-( |
20:54:33 | * | preglow observes that button_tick() seems to take care of REPEAT |
20:54:45 | preglow | wubbla: have you enabled it? |
20:55:12 | wubbla | preglow: i enabled it in the settings menu |
20:55:19 | preglow | good, then what format do you use? |
20:55:25 | wubbla | preglow: mp3 |
20:55:31 | preglow | do we support replaygain for mp3? |
20:55:40 | wubbla | preglow: i think so...?! |
20:55:50 | dpassen1 | preglow: yes, if written in an ID3v2 tag |
20:55:55 | preglow | well, is it? |
20:56:02 | wubbla | i hope so |
20:56:10 | | Join PcHeRo [0] (n=548ccde3@labb.contactor.se) |
20:56:16 | dpassen1 | does replaygain info appear in Show ID3 Info |
20:56:43 | PcHeRo | anybody know something about doom on h120?? |
20:56:53 | preglow | PcHeRo: i know it doesn't exist |
20:56:53 | wubbla | dpassen1: track/album gain is there |
20:57:02 | amiconn | preglow: Yes it does (for ages ;) ) |
20:57:02 | preglow | then it should work |
20:57:15 | Bagder | http://www.rockbox.org/doom/ |
20:57:18 | Bagder | ;-P |
20:57:25 | preglow | that's archos! |
20:57:28 | markun | We could just add the APEv2 tag support, very easy, but somehow I think some people in here will not like that. |
20:57:47 | dpassen1 | markun: with unicode supported, it seems that APEv2 tag support should be added |
20:57:53 | _FireFly_ | markun: why ? |
20:57:54 | preglow | markun: well, it screws up the tag priority |
20:58:07 | _FireFly_ | ah right |
20:58:36 | _FireFly_ | an comprimise would be to only add apev2 support for replay-gain |
20:58:40 | preglow | i like apev2, but i think we should not encourage use of it with mp3 |
20:58:46 | _FireFly_ | for mp3-files |
20:58:47 | wubbla | isn't the pre-amp option used to increase the perceived "volume"? |
20:58:54 | markun | If people add apev2 tags they should have the highest priority I think |
20:58:55 | preglow | wubbla: well, yes... |
20:59:11 | wubbla | preglow: this setting doesn't work for me at all |
20:59:17 | preglow | wubbla: then replaygain is not enabled |
20:59:22 | dpassen1 | i'm not even sure why there is an option for ID3 tag priority to be honest |
20:59:28 | wubbla | preglow: 0dB and 12dB gives no difference... |
20:59:30 | preglow | wubbla: either because you haven't enabled the option, or because rockbox does not use it |
20:59:31 | PcHeRo | is it difficult to write the archos code of doom to the h120 code |
20:59:39 | preglow | PcHeRo: it's a hoax... |
20:59:53 | PcHeRo | what? |
20:59:53 | preglow | it even says so on the page |
20:59:58 | preglow | This is an April Fools joke. |
21:00 |
21:00:07 | _FireFly_ | ;) |
21:00:09 | preglow | on a red background |
21:00:18 | wubbla | maybe it's the "prevent clipping" setting that makes problems? |
21:00:22 | wubbla | no idea |
21:00:45 | wubbla | maybe a reboot helps :-D |
21:00:47 | _FireFly_ | wubbla: if you don't know in the latest build prevent clipping is gone |
21:01:00 | dpassen1 | there is a different prevent clipping in the replaygain options menu |
21:01:02 | PcHeRo | ohh lol |
21:01:11 | markun | _FireFly_: not for replaygain |
21:01:19 | _FireFly_ | markun: yepp i know |
21:01:20 | | Quit linuxstb_ ("CGI:IRC") |
21:01:32 | _FireFly_ | but the other is gone :) |
21:01:46 | wubbla | replaygain type is set to album gain |
21:01:56 | preglow | wubbla: so track and album gain is displayed in id3 info? |
21:02:00 | preglow | wubbla: what values do you see? |
21:02:03 | wubbla | preglow: yes |
21:02:24 | | Quit San (Read error: 110 (Connection timed out)) |
21:02:41 | wubbla | preglow: track: -0.58 / album: -0.44 |
21:04:08 | wubbla | all i want is to increase volume, as i simply cannot hear anything at all at -40dB volume setting... |
21:04:19 | PcHeRo | http://img205.imageshack.us/img205/4237/fich6rq.jpg |
21:04:21 | dpassen1 | so raise the volume, -40 is very very low |
21:04:30 | preglow | if you want to _increase_ volume, replaygain is not the way to go |
21:04:35 | preglow | replaygain will most often decrease it |
21:04:42 | preglow | unless you manually use the preamp |
21:04:53 | wubbla | preglow: i intended to use the pre-amp option |
21:05:06 | wubbla | so that all my music plays at the same volume level... |
21:05:48 | * | preglow summons Lear |
21:05:53 | preglow | Lear: there you are! |
21:05:57 | Lear | Indeed. |
21:06:05 | preglow | so, what's up with this mp3 replaygain thing? |
21:06:14 | preglow | Lear: and how are the tremor opts going? |
21:06:17 | Lear | what about it? I use it all the time... |
21:06:27 | preglow | wubbla says he can't get it to work |
21:06:34 | preglow | even though track and album gain are parsed |
21:06:45 | wubbla | Lear: basically the pre-amp options doesn't seem to work for me... |
21:06:48 | _FireFly_ | wubbla: why do you have the volume to a such low level (-40 db) ?? |
21:06:50 | PaulJ | on my h320 replaygain works with mp3, but i have never used the preamp option |
21:06:56 | preglow | if preamp doesn't work, that means replgaygain doesn't work |
21:07:08 | Lear | preglow: For the small thing I tested, I hadn't checked the which cases were executed most often, so my code wasn't that fast... |
21:07:21 | wubbla | i might add that i'm using a h320... |
21:07:33 | Lear | But I think I can remove 1-2 percentage points of boost... :) |
21:07:55 | Lear | I don't use pre-amp myself, so let me check that... |
21:08:00 | amiconn | [20:57:17] <Bagder> http://www.rockbox.org/doom/ <== At least the archos can show the intro video of Doom 3, as .rvf :-P |
21:08:17 | Bagder | yeps |
21:08:21 | Bagder | and a neat video it is |
21:08:21 | amiconn | (That was not yet possible when this joke was made) |
21:08:30 | dpassen1 | to test replaygain settings, do you need to restart playback? reboot? or should it take place when the buffer is refilled? |
21:08:36 | Bagder | it would have made a more realistic joke |
21:08:41 | Lear | Nope, nothing of the sort. |
21:08:56 | wubbla | i've already rebooted... |
21:08:58 | Lear | dpassen1: you only need to exit the menu.. |
21:09:07 | dpassen1 | so it should take place immediately |
21:09:41 | Lear | There's a small delay due to buffering, so after exiting one level in the menu, it can take a few seconds. |
21:10:09 | | Join solexx__ [0] (n=jrschulz@d127033.adsl.hansenet.de) |
21:10:41 | * | RotAtoR puts on evil music and begins working with 100's of lines of code of bitmap definitions >:D |
21:10:46 | wubbla | Lear: so the pre-amp does work for you? |
21:11:07 | | Join Rob2222 [0] (n=Miranda@ACB71591.ipt.aol.com) |
21:11:13 | preglow | linuxstb: does the patch apply? i've got to go real soon |
21:11:43 | | Join Mmmm [0] (n=mscarrat@cpc4-hem13-3-1-cust63.lutn.cable.ntl.com) |
21:11:56 | _FireFly_ | btw what about my simplified version of the image-flicker-patch |
21:11:57 | PaulJ | preamp seems to work on my h320 |
21:11:59 | Lear | wubbla: yes, pre-amp works fine. |
21:12:17 | linuxstb | preglow: Yes, it applied perfectly. I can't compile at the moment because of my audio changes though. |
21:12:54 | wubbla | hum. :'-( |
21:13:26 | _FireFly_ | wubbla: maybe you could upload one of your mp3's so that other can test it |
21:13:29 | * | amiconn has an idea how to solve the delay problem for EQ and other DSP effects |
21:13:48 | _FireFly_ | to check if it is maybe an problem with the files |
21:13:50 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
21:13:51 | PaulJ | wubbla: what value did you set the preamp |
21:14:23 | wubbla | PaulJ: even 12dB didn't change anythin... |
21:14:34 | * | Lear wonders what amiconn is smoking this time ;) |
21:14:43 | PaulJ | ok, this should be audible |
21:14:48 | wubbla | _FireFly_: will do that... |
21:15:00 | *** | Saving seen data "./dancer.seen" |
21:16:06 | preglow | amiconn: spill it! |
21:17:10 | amiconn | Well, the large delays will only occur with crossfade enabled, right? Without crossfade, the PCM buffer is only half a second of audio |
21:17:21 | preglow | it's far too long without crossfade as well |
21:17:34 | preglow | longer than half a second |
21:17:36 | amiconn | So we could do the following with sufficiently fast codecs: |
21:18:02 | Lear | wubbla: pre-amp is only applied for files with replaygain and if replaygain is enabled. |
21:18:30 | wubbla | Lear: yes, i'm aware of that |
21:18:31 | amiconn | - Keep the buffer level roughly at half a second during the track. Only fill it completely a short time before track change |
21:18:41 | linuxstb | preglow: Your patch runs fine, thanks. |
21:19:23 | preglow | amiconn: i don't like it, the cpu spike protection vanishes |
21:19:23 | | Quit PcHeRo ("CGI:IRC (EOF)") |
21:19:47 | preglow | ahh |
21:19:58 | preglow | i don't like the inconsistency either |
21:20:08 | preglow | people will wonder why the hell changes are fast some times and not other times |
21:20:41 | preglow | amiconn: and what if someone skips a track=? |
21:20:52 | preglow | amiconn: the entire buffer will have to be filled before rockbox can comply |
21:21:13 | amiconn | Hmm, does crossfade also work when skipping tracks? |
21:21:16 | preglow | yes |
21:21:18 | preglow | afaik |
21:21:23 | amiconn | I didn't think it does |
21:21:29 | preglow | i'm not sure |
21:21:32 | preglow | i never use crossfade |
21:21:32 | * | amiconn never used crossfade |
21:21:32 | | Quit solexx_ (Read error: 110 (Connection timed out)) |
21:22:34 | preglow | btw |
21:22:45 | preglow | i think the voice ui shouldn't interact with audio buffering like it does now |
21:22:56 | preglow | it should probably just mix it's changes right at the beginning of the buffer |
21:22:59 | preglow | its |
21:23:27 | amiconn | voice UI needs really low latency |
21:23:27 | preglow | if you do a long string of commands now, all of them spoken in a row |
21:23:33 | preglow | pretty unusable |
21:23:40 | preglow | but ok |
21:23:42 | preglow | i really need to run |
21:23:44 | preglow | later |
21:25:01 | amiconn | On archos, switching to a new menu item preempts the old clip and immediately plays the new one. This doesn't work on iriver yet |
21:25:14 | | Join zeero [0] (n=nick@fw.cerisent.com) |
21:25:54 | mirak | if I want a static lib out of a codec how do I proceed ? |
21:25:55 | wubbla | maybe i should also paste my rockbox config-file? |
21:26:13 | wubbla | −−> http://pastebin.com/464199 |
21:26:23 | wubbla | Lear: please check my config... |
21:26:46 | _FireFly_ | wubbla: if its an config problem then try to reset the settings and enable only replay-gain |
21:27:12 | mirak | I don't understand the compile chain |
21:27:58 | mirak | I have run a configure with a generic target to see how look like the configurated sources. Only a file called platform.in gets created |
21:28:32 | mirak | now from that file I get defines that I should set in a .h file right ? |
21:28:51 | linuxstb | Are you talking about the xvidcore build system, or Rockbox? |
21:29:00 | Lear | wubbla: looks good. Volume is low, but not that low (depending on headphones...). |
21:29:06 | mirak | xvid part |
21:29:24 | mirak | linuxstb: in each codec there is a make file. I adapted that make file to xvid |
21:29:35 | | Join Rob2222 [0] (n=Miranda@ACB71591.ipt.aol.com) |
21:29:37 | wubbla | Lear: this is a mp3 with added replaygain tags: http://rapidshare.de/files/9179114/03._Crack_Rock_Steady.mp3.html |
21:29:48 | | Join Benacool [0] (i=Benacool@toronto-HSE-ppp4101375.sympatico.ca) |
21:29:49 | mirak | now I don't get how exactly the xvid sources are build |
21:30:13 | mirak | linuxstb: the static lib is created from the rockbox interface file should be xvid.c |
21:30:15 | linuxstb | The first thing I would do is to take the xvidcore library, and one of the example programs, and try to compile it as a standalone program outside of both Rockbox and the xvidcore build system. |
21:30:24 | | Join nathanh [0] (n=wosjowj@220-245-222-198-act-pppoe.tpgi.com.au) |
21:30:28 | mirak | linuxstb: I did that |
21:30:39 | mirak | but it failed |
21:30:39 | mirak | lol |
21:30:57 | mirak | I will focus on that |
21:31:01 | linuxstb | :) Do you mean you tried to do that but failed? |
21:31:09 | mirak | yes |
21:31:44 | mirak | in fact I did something like gcc -I path_to_xvidlib exemple.c |
21:31:52 | mirak | and got loads of errors |
21:31:55 | mirak | then I went to bed |
21:32:04 | mirak | it was yesterday I think |
21:32:35 | dpassen1 | wubbla: mp3 is fine |
21:35:18 | wubbla | dpassen1: pre-amp does work for you? |
21:35:45 | dpassen1 | ill check, but im on a 120 |
21:35:53 | mirak | linuxstb: there is a problem with the width variable |
21:35:56 | Mmmm | Does anyone know the DNS for the forums? I think i'm going to edit my hosts file, its just too painful otherwise! |
21:36:01 | mirak | it's not declared |
21:36:17 | PaulJ | wubbla: did you go back to the wps after changing the preamp? |
21:36:27 | wubbla | PaulJ: yes |
21:36:47 | | Join saratoga [0] (n=80c4c198@labb.contactor.se) |
21:37:38 | linuxstb | mirak: What width variable are you talking about? |
21:37:59 | mirak | linuxstb: you have the code ? |
21:38:23 | mirak | linuxstb: line 577 in xvid_decraw.c |
21:38:36 | dpassen1 | replaygain and the preamp definitely work here |
21:38:52 | linuxstb | mirak: No, I don't have the code, sorry. |
21:38:56 | mirak | linuxstb: it's not declared it must be something else |
21:39:31 | _FireFly_ | mirak: do you have some errors which say that he can't find some *.h files ?? |
21:42:12 | mirak | no I fixed the width error, I think they didn't used the good variable |
21:42:24 | mirak | that's strange |
21:42:25 | Mmmm | Ahh tis ok, found the DNS: 72.29.70.124 |
21:42:54 | mirak | now I got undefined reference to some methods |
21:43:04 | wubbla | grrr.... :-/ |
21:43:23 | _FireFly_ | mirak: do you have given the compile which libs you should link ?? |
21:43:24 | mirak | my build like is just gcc -I ../src/ xvid_decraw.c with ../src/ pointing to the codec source |
21:43:33 | mirak | _FireFly_: I am clueless for that |
21:43:54 | wubbla | is there any h300 user able to confirm that the replaygain's pre-amp option does work? |
21:43:58 | mirak | _FireFly_: I said him what to include, I am not sure it must be done like that |
21:44:02 | dpassen1 | wubbla: test with a file with a more pronounced replaygain |
21:44:19 | wubbla | dpassen1: what do you mean? |
21:44:27 | PaulJ | wubbla: on my h320 the preamp works with your file too |
21:44:45 | dpassen1 | nevermind, i thought you were testing with a -0.xx replaygained file |
21:44:46 | wubbla | PaulJ: you're using latest CVS? |
21:44:53 | mirak | _FireFly_: my goal is to use to not use external libs |
21:45:00 | mirak | to not use |
21:45:08 | linuxstb | mirak: Have you written your own Makefile? |
21:45:12 | _FireFly_ | mirak: i think you should learn how to use libs (static or dynamic) |
21:45:19 | mirak | linuxstb: not yet, I just try to build the exemple |
21:45:44 | _FireFly_ | mirak: i think the example-code from the xvid-core needs the lib |
21:46:18 | Mmmm | Wubbla: do you have prevent clipping on? If so have you tried turning it off? |
21:46:43 | _FireFly_ | i think he should also try a newer build |
21:46:43 | PaulJ | wubbla: i'm using a version from yesterday. i have applied the brightness patch, but this shoult not affect replaygain |
21:47:05 | wubbla | PaulJ: can you upload your rockbox.iriver as well as the .rockbox folder (in a zip/rar/whatelse archive preferably) to rapidshare.de? |
21:47:08 | _FireFly_ | because the overall prevent-clipping option is gone in the newer builds |
21:47:22 | mirak | _FireFly_: so I need xvid-core-dev or something like that with the headers ? |
21:47:35 | _FireFly_ | mirak: i think do you have the sources |
21:47:43 | mirak | I have the sources yes |
21:47:44 | _FireFly_ | -do |
21:47:55 | _FireFly_ | then compile it which will generate the lib |
21:48:14 | mirak | -do ? |
21:48:25 | mirak | oh sorry :) |
21:48:25 | _FireFly_ | and then with this lib and the headers you can compile the example-programm |
21:48:35 | mirak | I tough it was gcc option ;) |
21:48:44 | _FireFly_ | gcc is used :) |
21:49:02 | _FireFly_ | but i think the sources you have will generate a lib which can be used in other programms |
21:49:18 | | Join Cassandra [0] (i=Cassandr@elmyra.coraline.org) |
21:49:47 | mirak | _FireFly_: but why can't I just build a static binary with the lib just as includes ? |
21:50:47 | nathanh | lib as includes? |
21:51:04 | _FireFly_ | mirak: you can but you must either generate a static-lib or include the sources to you build |
21:51:21 | mirak | _FireFly_: I want to do that |
21:51:26 | _FireFly_ | mirak: i think you should realy learn how to use libs |
21:51:31 | mirak | ^^ |
21:51:32 | Mmmm | Wubbla: if you have prevent clippping on (in the replaygain menu) and your track is clipping, then I think the preamp won't do anything. |
21:51:53 | PaulJ | wubbla: http://www.stud.uni-goettingen.de/~s291827/test/rockbox.zip |
21:52:03 | wubbla | PaulJ: thank you so much! |
21:52:14 | nathanh | mirak: read this -> http://www.iecc.com/linker/ <- its an awesome book, free copy online, that will teach you all you need to do so as to do what you want |
21:52:26 | _FireFly_ | mirak: normaly there is a configure-script(when under linux/*nix) in the sources |
21:52:28 | mirak | thank you nathanh |
21:52:29 | PaulJ | wubbla: the colours are also changed |
21:52:33 | nathanh | i bought the book because i liked it so much |
21:56:24 | mirak | what I don't get is why from the moment it includes the main header file of the codec, why doesn't it find all the other methods |
21:56:48 | mirak | xvid.c file reference a bunch of .h files |
21:57:02 | _FireFly_ | mirak: because you need also the compiled code of the functions |
21:57:08 | mirak | how to just make the exemple programme be aware of that ? |
21:57:29 | _FireFly_ | mirak: is there a configure-script in the sources |
21:57:33 | _FireFly_ | ? |
21:57:38 | wubbla | yay! |
21:57:40 | mirak | _FireFly_: yes |
21:57:45 | _FireFly_ | then run it |
21:57:47 | wubbla | PaulJ: with your build pre-amp works! |
21:57:52 | wubbla | hmmm |
21:57:56 | wubbla | PaulJ: thanks! |
21:58:03 | PaulJ | wubbla:strange |
21:58:03 | _FireFly_ | wubbla: then try a newer build :) |
21:58:21 | RotAtoR | weeee! http://img246.imageshack.us/img246/5940/newjewels6ut.png |
21:58:25 | _FireFly_ | i think the problem was that he had used a old one |
21:58:26 | mirak | _FireFly_: I must also put xvid.c on the gcc line somethig like that ? |
21:58:30 | wubbla | _FireFly_: i compiled the latest cvs version on my own |
21:58:31 | _FireFly_ | a old build |
21:58:40 | Maxime | great RotAtoR |
21:58:52 | nathanh | rot: nice |
21:59:01 | _FireFly_ | mirak: the configure-script will create a makefile |
21:59:09 | mirak | yes |
21:59:12 | _FireFly_ | after the script has ended simply run make |
21:59:30 | _FireFly_ | then i guess you will get a lib |
22:00 |
22:00:23 | nathanh | xvid lib uses malloc, its not going to work without major mods |
22:00:37 | nathanh | its also a huge memory hog |
22:00:51 | _FireFly_ | nathanh: as many codes for non embedded systems |
22:01:25 | _FireFly_ | does dynamic memory allocation |
22:02:28 | _FireFly_ | wubbla: if you had run the latest build then why did you had an prevent-clipping option outside the replaygain-setting menu ?? |
22:02:44 | _FireFly_ | or i miss something |
22:02:59 | wubbla | _FireFly_: i used the clipping option in the replaygain menu... |
22:03:48 | _FireFly_ | wubbla: you had said something different |
22:03:58 | mirak | _FireFly_: I have built it |
22:04:02 | mirak | the lib |
22:04:23 | mirak | nathanh: yes we are aware of that |
22:04:25 | _FireFly_ | :) |
22:04:48 | mirak | nathanh: I am at least. the succes of this operation is very uncertain |
22:05:14 | mirak | but I am learning new stuffs, that's fine |
22:05:25 | wubbla | Replaygain scan status (9/12749) |
22:05:26 | wubbla | lol |
22:05:27 | _FireFly_ | mirak: yeah many new stuff :) |
22:05:31 | wubbla | that might take a while :-D |
22:05:36 | Cassandra | Theoretically there's no reason why you couldn't include a malloc implementation within a plugin. |
22:05:57 | mirak | _FireFly_: ok so as far as I understand, now ld needs to know that libxvid exist to be able to feed the exemple with it ? |
22:06:06 | _FireFly_ | yepp |
22:06:31 | mirak | Cassandra: I have read the code, and we could put the buffer static I think we will see |
22:06:35 | _FireFly_ | the gcc option for this is -l(lower L) and the name of the lib without the lib-prefix and the .so/.a suffix |
22:07:00 | _FireFly_ | and with -L you give the search patch |
22:07:03 | _FireFly_ | for libs |
22:07:22 | mirak | ok so with -L I am not obliged to install the lib |
22:07:56 | _FireFly_ | gcc -I ../src/ -L ../src -lxvid xvid_decraw.c |
22:08:21 | _FireFly_ | maybe the libxvid is in a subdir of ../src |
22:08:31 | _FireFly_ | then you need to change it accordingly |
22:08:31 | DrumRBoy|Away | this is so cool... i didnt realize USB was supported in RB now... awesome |
22:08:45 | _FireFly_ | mirak: yepp |
22:08:47 | mirak | _FireFly_: yep it's in the builddir |
22:08:58 | _FireFly_ | mirak: is the lib an *.so or *.a file ?? |
22:09:13 | mirak | so |
22:10:23 | _FireFly_ | hmm then you have to install the lib your create an run-script which adds the path to the lib-loder-search path or compile the lib as a static one (*.a) |
22:10:32 | _FireFly_ | the last would i prefer |
22:11:26 | amiconn | There is no shared library support in rockbox, so static lib is the only option |
22:11:27 | _FireFly_ | is in the output from configure −−help any line which has static lib(or similar) |
22:11:30 | mirak | but with that, I will able to run the exemple even without the xvidlib installed ? |
22:11:53 | _FireFly_ | mirak: yepp because static libs are linked into the programm |
22:11:59 | mirak | ok |
22:12:12 | _FireFly_ | -> the size grows is bigger then when using dynamic libs |
22:12:18 | _FireFly_ | -grows |
22:12:58 | _FireFly_ | mirak: it seams that you have to tell configure to make static-libs instead of dynamic |
22:13:16 | _FireFly_ | there is normaly an option/parameter for this |
22:14:25 | _FireFly_ | amiconn: have you yet found some time for the remote-setting patch ?? |
22:15:25 | petur | anybody familiar with the soft-I2C written for iRiver? |
22:15:37 | mirak | _FireFly_: can't find that option |
22:16:04 | _FireFly_ | can you post somewhere the output of configure −−help ?? |
22:16:13 | | Quit nathanh ("Quit") |
22:17:25 | petur | hmmmm... If somebody told me the radio on the H1xx works, I wouldn't believe him... |
22:17:36 | _FireFly_ | petur: why ß? |
22:18:14 | petur | the soft I2C getack() looks wrong... and that's where it hangs on H3xx |
22:18:27 | petur | But it's the same code as the H1xx |
22:18:38 | petur | So I would expect it to be ok |
22:18:49 | _FireFly_ | petur: really ? |
22:18:54 | | Quit ender` (" cd /pub && get beer") |
22:19:02 | _FireFly_ | maybe there is something different |
22:19:09 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
22:20:06 | petur | getack does the same wait loop as ack, meaning it's generating SCL |
22:20:21 | petur | the other soft I2C implementations don't do that at all... |
22:20:54 | _FireFly_ | petur: maybe the hardware differs in that case |
22:21:18 | mirak | _FireFly_: http://paste.ubuntu-nl.org/5764 |
22:21:24 | _FireFly_ | so that the code for the h1xx doesn't use the right output/input-pins |
22:23:35 | petur | _FireFly_: you mean the radio is connected to other pins? I already changed that, unless Linus measured it wrong (but he double-checked) |
22:24:03 | petur | I'm gonna change it and see what it brings :D |
22:24:18 | * | petur hopes it brings radio |
22:24:59 | _FireFly_ | mirak: try configure −−enable-static |
22:25:17 | | Join jlo [0] (n=jl@atm91-1-82-227-1-35.fbx.proxad.net) |
22:25:27 | jlo | hello all |
22:25:44 | _FireFly_ | petur: if LinusN say that the pins are the same then it that should right |
22:26:12 | _FireFly_ | jlo: hi |
22:26:37 | petur | _FireFly_: he said the pins mentioned in the wiki are correct - they differ from the H1xx |
22:26:37 | | Join ender` [0] (i=ychat@84.52.165.220) |
22:27:28 | _FireFly_ | petur: or so but maybe the pins must be interchanged |
22:27:38 | petur | ? |
22:27:44 | mirak | _FireFly_: ok I have the .a file |
22:27:59 | _FireFly_ | also the .so file ?? |
22:28:12 | mirak | yes both |
22:28:26 | _FireFly_ | if so then delete the .so file or move it |
22:28:33 | amiconn | petur: The comments tells you why the loop is repeatedly setting SCL high and switching to input again |
22:28:40 | _FireFly_ | because the linker will use the .so file if he find it |
22:28:56 | mirak | ok then ? |
22:28:59 | | Quit hshah (Read error: 110 (Connection timed out)) |
22:29:03 | amiconn | -s |
22:29:25 | _FireFly_ | mirak: then this should work : gcc -I ../src/ -L ../src -lxvid xvid_decraw.c |
22:29:27 | petur | right |
22:29:36 | * | petur learns to read comments |
22:29:38 | _FireFly_ | amiconn: what about my question ?? |
22:30:29 | _FireFly_ | mirak: only the path for the -L parameter must you set it to the right parth in which the .a file is |
22:31:12 | petur | well, I'm stuck there: it never sees SCL as high :( |
22:31:57 | mirak | :( |
22:32:11 | mirak | gcc -I ../src/ -L ../build/generic/\=build/ -lxvidcore xvid_decraw.c |
22:32:26 | petur | eureka |
22:32:33 | petur | :( |
22:32:38 | mirak | in the make file he uses -lxvidcore |
22:32:42 | petur | this is bad |
22:33:05 | mirak | /tmp/ccQfGPHD.o: dans la fonction « dec_init »: |
22:33:06 | mirak | xvid_decraw.c:(.text+0x13a9): référence indéfinie vers « xvid_global » |
22:33:06 | _FireFly_ | mirak: what is the name of the .a file ?? |
22:33:23 | mirak | libxvidcore.a |
22:33:26 | petur | no it isn't (wrong pin description) - nothing happened... |
22:33:43 | _FireFly_ | mirak: then it should be -lxvidcore |
22:34:01 | mirak | I use that it fails with the above error |
22:34:16 | _FireFly_ | mirak: i didn't understadn frensh ;) |
22:34:32 | mirak | référence indéfinie vers −−-> undefined reference to |
22:34:50 | _FireFly_ | hmm |
22:35:08 | _FireFly_ | then something else is missing |
22:36:08 | _FireFly_ | mirak: do you find an function-definition or a var-definition with the name xvid_global |
22:36:16 | _FireFly_ | in the sources do you have |
22:36:38 | _FireFly_ | amiconn: ?? |
22:36:48 | amiconn | No, sorry :( |
22:36:56 | _FireFly_ | ok |
22:37:18 | _FireFly_ | also no comments in my gentoo-dev-ml-thread |
22:37:36 | _FireFly_ | nobody has any comments about this it seams :) |
22:37:40 | _FireFly_ | or no time |
22:39:10 | mirak | extern int xvid_global(void *handle, int opt, void *param1, void *param2); |
22:39:15 | mirak | it's in the code |
22:39:42 | mirak | lib is not loaded I get the same error when not using -L |
22:39:54 | | Join nathanh [0] (n=wosjowj@220-245-222-198-act-pppoe.tpgi.com.au) |
22:40:02 | jlo | is somebody working on spdif recording (H1xx) ? : recording.c seems not far from |
22:40:29 | _FireFly_ | mirak: does he say that he can't find the lib ?? |
22:40:43 | mirak | I past you the output |
22:41:38 | mirak | _FireFly_: http://paste.ubuntu-nl.org/5766 |
22:43:02 | mirak | LANG=en grep -n xvid_global libxvidcore.a |
22:43:02 | mirak | Binary file libxvidcore.a matches |
22:43:09 | mirak | it's in it ^^ |
22:43:41 | _FireFly_ | mirak: yeah but the gcc doesn't try to link it or doesn't say that i can't find the lib |
22:44:10 | _FireFly_ | try this -llibxvidcore.a |
22:44:51 | | Join San [0] (n=sanitari@213-202-157-201.bas503.dsl.esat.net) |
22:44:56 | petur | right... this I2C thing calls for measurement on the signals. I'll mail Linus |
22:45:06 | mirak | /usr/bin/ld: cannot find -llibxvidcore.a |
22:45:20 | _FireFly_ | have you set the -L parameter ?? |
22:45:46 | mirak | LANG=en gcc -I ../src/ -L ../build/generic/\=build/ -llibxvidcore.a xvid_decraw.c |
22:45:47 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
22:45:56 | mirak | that's the command |
22:46:23 | _FireFly_ | maybe he has problems that the last subdirdir starts with an '=' |
22:46:48 | _FireFly_ | try to copy it to the same location as the source-file and set -L ./ |
22:48:44 | mirak | :( |
22:52:18 | | Quit Slasheri (kornbluth.freenode.net irc.freenode.net) |
22:52:18 | NSplit | kornbluth.freenode.net irc.freenode.net |
22:56:29 | Mmmm | \quit |
22:56:34 | | Quit Mmmm () |
22:57:58 | | Quit Lear ("Chatzilla 0.9.68.5.1 [Firefox 1.5/undefined]") |
22:58:22 | _FireFly_ | mirak: do you have xvid installed in your system ?? |
22:58:30 | mirak | probably |
22:59:02 | _FireFly_ | i think this defines are also needed: -DARCH_IS_IA32 -DARCH_IS_32BIT -DARCH_IS_LITTLE_ENDIAN -fPIC |
22:59:29 | _FireFly_ | these are from the Makefile-output in the example-dir |
22:59:54 | _FireFly_ | then it should at least compile then -lxvidcore |
23:00 |
23:00:08 | _FireFly_ | with -lxvidcore |
23:00:17 | mirak | I use this defines where ? |
23:00:21 | NHeal | kornbluth.freenode.net irc.freenode.net |
23:00:21 | NJoin | Slasheri [0] (i=miipekk@ihme.org) |
23:00:41 | _FireFly_ | similar to the -l -L parameters |
23:00:54 | _FireFly_ | gcc -DARCH_IS_IA32 -DARCH_IS_32BIT -DARCH_IS_LITTLE_ENDIAN -fPIC ...... |
23:01:17 | mirak | ok |
23:01:55 | mirak | still not |
23:02:04 | mirak | LANG=en gcc -I ../src/ -L ./ -lxvidcore -DARCH_IS_IA32 -DARCH_IS_32BIT -DARCH_IS_LITTLE_ENDIAN -fPIC xvid_decraw.c |
23:02:07 | mirak | I about to give up |
23:02:11 | mirak | :-/ |
23:02:32 | _FireFly_ | -lc -lm are missing |
23:02:57 | | Join Midgey34 [0] (n=Midgey34@c-24-11-55-125.hsd1.mi.comcast.net) |
23:03:16 | mirak | LANG=en gcc -I ../src/ -L ./ -lxvidcore -lc -lm -DARCH_IS_IA32 -DARCH_IS_32BIT -DARCH_IS_LITTLE_ENDIAN -fPIC xvid_decraw.c |
23:03:24 | mirak | bouhhhh :'( |
23:03:30 | _FireFly_ | hmm strange |
23:03:33 | Bagder | the -ls are only needed when linking, not mere compiling |
23:04:08 | _FireFly_ | Bagder: yepp but he compiles and links with one cmd-line |
23:04:19 | Bagder | ah, right |
23:04:22 | _FireFly_ | ;) |
23:04:22 | Bagder | no -c |
23:04:42 | * | Bagder shuts up |
23:04:48 | _FireFly_ | mirak: have you tried to run make in the example dir ?? |
23:04:53 | _FireFly_ | does this works ?? |
23:05:02 | mirak | it didn't worked |
23:05:15 | mirak | gcc -o xvid_encraw xvid_encraw.o -lc -lm -lxvidcore |
23:05:15 | mirak | /usr/bin/ld: ne peut trouver -lxvidcore |
23:05:47 | mirak | but since the lib is not installed |
23:05:51 | mirak | the dev lib at least |
23:06:13 | _FireFly_ | edit the Makefile and add to the LDFLAGS-var the -L./ parameter |
23:06:16 | | Join Febs [0] (n=40326e83@labb.contactor.se) |
23:07:06 | mirak | _FireFly_: you are a god |
23:07:09 | mirak | it worked |
23:07:15 | mirak | \o/ |
23:07:26 | _FireFly_ | btw have you tried this ?? : LANG=en gcc -I ../src/ -L ./ -lc -lm -lxvidcore -DARCH_IS_IA32 -DARCH_IS_32BIT -DARCH_IS_LITTLE_ENDIAN -fPIC xvid_decraw.c |
23:07:39 | _FireFly_ | the order of the -l parameters are importend |
23:09:23 | mirak | _FireFly_: ope |
23:09:27 | mirak | nope it doesn't work |
23:10:31 | _FireFly_ | strange because it is the same line |
23:11:01 | _FireFly_ | i have to go cu |
23:11:15 | _FireFly_ | and a good night :) |
23:11:16 | mirak | bye thank you |
23:11:24 | _FireFly_ | np |
23:11:27 | | Quit _FireFly_ ("Leaving") |
23:13:49 | mirak | gcc -o xvid_decraw xvid_decraw.o -lc -lm -lxvidcore -L./ |
23:13:53 | mirak | this line alone works |
23:15:02 | *** | Saving seen data "./dancer.seen" |
23:21:13 | | Join webguest84 [0] (n=3efe2012@labb.contactor.se) |
23:21:36 | | Quit Mark__ ("Leaving") |
23:24:08 | | Join Rob2222 [0] (n=Miranda@ACB71591.ipt.aol.com) |
23:24:58 | mirak | nope it doesn't a .o was left |
23:30:26 | jlo | good night |
23:30:28 | | Quit jlo () |
23:34:27 | | Part webguest84 |
23:37:13 | | Join tvelocity [0] (n=tony@84.254.9.197) |
23:40:33 | petur | no use waiting for Linus here, I'm off to bed. Goodnight! |
23:40:45 | | Quit petur ("here today, gone tomorrow") |
23:40:55 | | Quit nathanh ("Quit") |
23:44:47 | | Join linuxstb_ [0] (n=5343d4aa@labb.contactor.se) |
23:46:39 | linuxstb_ | mirak: You may find this a good place to start: http://www.davechapman.f2s.com/rockbox/xvidtest.tgz |
23:47:00 | linuxstb_ | I've stripped xvidcore to the bare minimum and written my own simple Makefile |
23:47:50 | linuxstb_ | It's going to take a lot of work to get that working in Rockbox though. |
23:49:08 | mirak | you stole my job ! |
23:49:09 | mirak | lol |
23:49:12 | mirak | :D |
23:49:45 | linuxstb_ | No, I don't want that job |
23:50:26 | dwihno | an xvid playback test thing? |
23:51:03 | linuxstb_ | Just the xvid library with a (PC based) test app |
23:52:02 | dwihno | ah, okay... |
23:52:08 | dwihno | Imagine xvid playback on target :) |
23:52:23 | linuxstb_ | Maybe on the gigabeat... |
23:52:32 | Bagder | x5 plays xvid |
23:52:37 | Bagder | 13 fps |
23:52:51 | linuxstb_ | Not with xvidcore I expect |
23:53:07 | dwihno | Bagder: stock firmware, I presume? |
23:53:15 | Bagder | dwihno: indeed |
23:53:47 | dwihno | Is any of the CPUs fast enough for decoding of lo-res vids? |
23:53:54 | mirak | when I see the cube running on the H300 I suspect the screen to have to much latency over 10 fps |
23:54:07 | | Join webguest46 [0] (n=3e4f4094@labb.contactor.se) |
23:54:09 | mirak | but if that's the same screen than ipod video |
23:54:21 | mirak | maybe it's ok |
23:54:44 | linuxstb_ | The h300 isn't the same as the video ipod. |
23:55:10 | webguest46 | http://img246.imageshack.us/img246/5940/newjewels6ut.png looks really good! |
23:55:26 | dwihno | Ah, stupid me didn't consider screen latency |
23:56:24 | mirak | webguest46: that's on what device ? |
23:57:00 | webguest46 | h3x0 |
23:57:10 | webguest46 | RotAtoR posted that earlier on |
23:57:25 | mirak | wow |
23:57:33 | mirak | it's on current build ? |
23:57:56 | webguest46 | No |