| 00:15:44 | *** | Saving seen data "./dancer.seen" |
| 00:26:26 | | Quit Moos (Read error: 104 (Connection reset by peer)) |
| 00:43:19 | | Quit Paul_The_Nerd ("Chatzilla 0.9.68a [Firefox 1.0.7/20050915]") |
| 00:57:30 | | Quit ender` (Read error: 113 (No route to host)) |
| 01:00 |
| 01:04:04 | | Nick _CoCoLUS is now known as CoCoLUS (n=coco@h081217139221.dyn.cm.kabsi.at) |
| 01:26:56 | | Join Strath [0] (n=mike@dpc674681214.direcpc.com) |
| 01:27:23 | | Quit dpassen1 () |
| 01:36:14 | | Quit zeekoe (Remote closed the connection) |
| 01:41:53 | | Quit DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 01:56:31 | | Join fuzzie [0] (i=fuzzie@anthracite.warpedgames.com) |
| 02:00 |
| 02:15:46 | *** | Saving seen data "./dancer.seen" |
| 02:36:28 | | Quit _aLF ("Leaving") |
| 02:43:30 | | Quit t0mas (Read error: 104 (Connection reset by peer)) |
| 02:47:15 | | Join t0mas [0] (n=Tomas@unaffiliated/t0mas) |
| 03:00 |
| 03:04:01 | * | fuzzie makes a note to never trust other people's code to be right, ever |
| 03:14:01 | | Join courtc_ [0] (n=court@adsl-158-37-64.asm.bellsouth.net) |
| 03:14:07 | | Quit courtc_ (Read error: 104 (Connection reset by peer)) |
| 03:15:31 | | Quit tvelocity ("Leaving") |
| 03:24:39 | | Join tvelocity [0] (n=tony@ipa112.2.tellas.gr) |
| 03:28:33 | | Join bagawk [0] (i=1000@unaffiliated/bagawk) |
| 03:28:57 | | Quit goa (Read error: 110 (Connection timed out)) |
| 03:47:37 | | Join goa [0] (i=hd@gate-hannes-tdsl.imos.net) |
| 04:00 |
| 04:03:06 | | Quit bagawk ("Leaving") |
| 04:05:17 | | Join QT_ [0] (i=as@madwifi/users/area51) |
| 04:05:24 | | Quit cYmen ("zZz") |
| 04:15:47 | *** | Saving seen data "./dancer.seen" |
| 04:15:51 | | Quit QT (Read error: 110 (Connection timed out)) |
| 04:27:08 | | Quit tvelocity ("Leaving") |
| 04:27:08 | | Quit goa (Read error: 110 (Connection timed out)) |
| 04:32:26 | | Join Coldtoast [0] (n=edan@ppp111-114.lns1.hba1.internode.on.net) |
| 04:34:50 | Coldtoast | hi. any chance you can have, like, a crash counter so every time Rockbox crashes on he same file, it ups the counter by 1 when Resume On Startup is enabled? I have an .mp4 on my player and when Rockbox tries to play it, it crashes and Rockbox has to be reset but cos I have Resume On Startup enabled, it keeps trying to play the file and crashes with an illegal instruction and has to reset |
| 04:35:01 | Coldtoast | so it's a constsnt crash-boot loop |
| 04:38:41 | | Join goa [0] (i=hd@gate-hannes-tdsl.imos.net) |
| 04:40:43 | | Part Coldtoast |
| 04:40:49 | | Quit rasher (Remote closed the connection) |
| 04:52:38 | | Quit JoeBorn ("open.neurostechnology.com") |
| 04:53:07 | | Join ashridah [0] (i=ashridah@220-253-121-135.VIC.netspace.net.au) |
| 04:59:43 | | Quit Strath (Read error: 104 (Connection reset by peer)) |
| 05:00 |
| 05:03:22 | | Join Strath [0] (n=mike@dpc674681214.direcpc.com) |
| 05:13:09 | | Quit Sucka ("a bird in the bush is worth two in your house") |
| 05:21:13 | fuzzie | Right, I got AAC decoding working without the mp4ff code. |
| 05:21:16 | fuzzie | I am vaguely proud of myself. |
| 05:21:23 | fuzzie | Next step, try it on an actual H120. |
| 05:46:11 | | Join webguest78 [0] (n=477540a8@labb.contactor.se) |
| 05:47:01 | | Join Ismo [0] (i=laitinei@huippu.net) |
| 05:53:40 | fuzzie | it fails on a bunch of files, which seems to be a known faad2 issue, argh. |
| 05:54:32 | fuzzie | but it is playing some of my other albums wonderfully, not even with the hiccups i normally get from the simulator. |
| 05:54:40 | fuzzie | [this still isn't on a H120 :P] |
| 05:54:46 | fuzzie | sleep now, i guess. |
| 05:59:21 | | Part webguest78 |
| 06:00 |
| 06:15:51 | *** | Saving seen data "./dancer.seen" |
| 06:58:31 | | Join amiconn_ [0] (n=jens@p54BD5FAE.dip.t-dialin.net) |
| 07:00 |
| 07:16:58 | | Quit amiconn (Read error: 110 (Connection timed out)) |
| 07:16:58 | | Nick amiconn_ is now known as amiconn (n=jens@p54BD5FAE.dip.t-dialin.net) |
| 07:36:13 | | Quit Rob- (Read error: 110 (Connection timed out)) |
| 07:42:19 | | Join Xombie [0] (n=LLPGuest@static-203-87-56-214.qld.chariot.net.au) |
| 07:42:37 | | Part Xombie |
| 07:59:50 | | Join LinusN [0] (n=linus@labb.contactor.se) |
| 08:00 |
| 08:15:53 | *** | Saving seen data "./dancer.seen" |
| 08:25:53 | | Join ender` [0] (i=ychat@84.52.165.220) |
| 08:34:02 | | Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) |
| 08:34:55 | linuxstb_ | Coldtoast: I'm guessing you mean ".m4a", and not ".mp4". If this is the case, are you using the very latest build? |
| 08:35:47 | linuxstb_ | fuzzie: Congratulations on the AAC decoder. Please post the code somewhere. |
| 08:46:52 | | Join Vladoman_ [0] (n=Vladoman@p54A7FE60.dip.t-dialin.net) |
| 08:47:04 | | Join ender1 [0] (i=ychat@84.52.165.220) |
| 08:53:26 | | Quit ender` (Nick collision from services.) |
| 08:53:30 | | Nick ender1 is now known as ender` (i=ychat@84.52.165.220) |
| 08:56:22 | linuxstb_ | rasher: Thanks for the metadata.c fix. |
| 08:57:16 | | Part Vladoman_ |
| 09:00 |
| 09:00:27 | | Quit Vladoman (Read error: 110 (Connection timed out)) |
| 09:00:59 | | Join B4gder [0] (n=daniel@213.115.255.230) |
| 09:02:20 | | Join Vladoman [0] (n=vladimir@p54A7FE60.dip.t-dialin.net) |
| 09:12:05 | | Join Paul_The_Nerd [0] (n=paulthen@cpe-66-68-93-2.austin.res.rr.com) |
| 09:25:22 | | Part Vladoman |
| 09:36:47 | | Quit Paul_The_Nerd (Read error: 110 (Connection timed out)) |
| 09:41:53 | | Join Vladoman [0] (n=Vladoman@p54A7FE60.dip.t-dialin.net) |
| 10:00 |
| 10:03:26 | | Part stamppot ("Kopete 0.10.2 : http://kopete.kde.org") |
| 10:07:11 | | Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
| 10:13:05 | | Quit gromit` (Remote closed the connection) |
| 10:15:01 | | Join gromit` [0] (n=gromit`@ras75-5-82-234-244-69.fbx.proxad.net) |
| 10:15:56 | *** | Saving seen data "./dancer.seen" |
| 10:16:11 | | Join [IDC]Dragon [0] (n=d90a3255@labb.contactor.se) |
| 10:37:56 | | Nick QT_ is now known as QT (i=as@madwifi/users/area51) |
| 11:00 |
| 11:16:10 | | Quit paugh ("Leaving") |
| 11:16:23 | | Quit ashridah (Read error: 110 (Connection timed out)) |
| 11:23:37 | | Quit lImbus (" word") |
| 11:32:55 | | Join preglow [0] (n=thomjoha@hekta.edt.aft.hist.no) |
| 11:33:54 | * | linuxstb_ curses Debian for not compiling things with SSL |
| 11:37:25 | preglow | woot, aac! |
| 11:37:44 | linuxstb_ | preglow: Yes, but only in the Sim. I'm very curious to see how fast it is on the H1x0 |
| 11:38:10 | linuxstb_ | I'm expecting it to be very slow - given how slow libmad was to start with. |
| 11:40:02 | | Join rasher [0] (n=jonas@62.79.64.148.adsl.hs.tiscali.dk) |
| 11:40:04 | preglow | oh, yes |
| 11:40:16 | preglow | so faad has problems with some files? |
| 11:40:17 | preglow | excellent |
| 11:40:53 | linuxstb_ | Maybe the problems were fixed with later versions. Also, only part of the librariy has been integer-ised. |
| 11:40:56 | preglow | but hmm |
| 11:41:08 | preglow | any more codecs that are way too bad, apart from mpc? |
| 11:41:17 | | Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
| 11:41:42 | linuxstb_ | How is Tremor working? I don't use it. |
| 11:42:08 | preglow | tremor is doing pretty well |
| 11:42:56 | preglow | i dont want to touch it before i can measure the improvements |
| 11:43:00 | linuxstb_ | Have most of the optimisations been through good use of the IRAM or the EMAC? I'm thinking about the work needed to be done on the ipod (which also has 96KB of IRAM) |
| 11:43:18 | preglow | most has been done with both emac and iram |
| 11:44:12 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 11:44:55 | preglow | one of the last obvious places to optimise would be to replace the imdct, but that too might give too subtle results for me to do it before i can measure properly |
| 11:45:16 | preglow | i think i'll just have a quick go a doing some iram work on libmusepack |
| 11:45:21 | preglow | the math i wont touch |
| 11:46:05 | linuxstb_ | ALAC was working about the same speed as musepack before I optimised the IRAM usage. |
| 11:46:19 | preglow | i can get musepack going realtime easily with iram |
| 11:46:24 | linuxstb_ | Does MPC use any iram at the moment? |
| 11:46:27 | preglow | yes |
| 11:46:32 | preglow | for the filter bank |
| 11:46:37 | preglow | problem is the main struct is too large for iram |
| 11:51:00 | preglow | the data struct uses all the available iram in just one field... |
| 11:59:33 | linuxstb_ | Is the iriver charger connector positive on the inside and negative on the outside? |
| 11:59:43 | linuxstb_ | (I've confused my Nokia and iriver chargers again) |
| 11:59:47 | HCl | oi. |
| 11:59:50 | HCl | careful. |
| 12:00 |
| 12:00:02 | linuxstb_ | That's why I'm asking :) |
| 12:00:14 | HCl | i'm at college so i can't check. |
| 12:00:23 | HCl | doesn't it say on the iriver unit itself? |
| 12:00:34 | | Join ashridah [0] (i=ashridah@220-253-120-3.VIC.netspace.net.au) |
| 12:00:38 | rasher | Hang on |
| 12:00:40 | HCl | why don't you simply throw the one labeled nokia away? |
| 12:01:08 | rasher | centerpositive |
| 12:01:15 | amiconn | linuxstb_: http://www.rockbox.org/twiki/bin/view/Main/DeviceChart#iriver_units "Charger spec 5V 2A center +" |
| 12:01:31 | HCl | yea, it does say it on the unit itself |
| 12:01:38 | HCl | indeed, center positive |
| 12:02:21 | preglow | i think they look pretty different |
| 12:02:25 | linuxstb_ | Thanks both of you. Yes, the unit itelf identifies the polarity, so I've found the right charger. |
| 12:02:27 | preglow | never managed to confuse them |
| 12:02:50 | linuxstb_ | preglow: I've also lost my Nokia charger. I was 99% sure I had the right charger, but wanted to double-check. |
| 12:03:03 | linuxstb_ | I must start labelling my chargers. |
| 12:03:20 | rasher | I keep them seperate. Iriver charger always connected to the same plug, nokia charger moving around. |
| 12:03:51 | ashridah | i keep them in separate rooms |
| 12:04:08 | rasher | well, I don't have seperate rooms |
| 12:04:08 | preglow | arghh |
| 12:04:13 | rasher | apart from the kitchen. |
| 12:04:20 | preglow | libmusepack is so incredibly memory hungry |
| 12:05:53 | preglow | for such a simple codec |
| 12:09:43 | linuxstb_ | preglow: A simple possible optimisation - could the loop in mpc.c that copies the data from sample_buffer to output_buf do the conversion in-place? |
| 12:10:19 | linuxstb_ | And then call pcmbuf_insert directly on sample_buffer. |
| 12:10:53 | preglow | well, should definitely be possible |
| 12:10:56 | preglow | i'll try |
| 12:11:13 | linuxstb_ | That's one change I made for ALAC. It seemed to give a noticable improvement. |
| 12:11:28 | preglow | oy, what the hell |
| 12:11:31 | preglow | it converts to 16 bit numbers! |
| 12:11:34 | preglow | that's not right |
| 12:11:42 | linuxstb_ | :) |
| 12:12:01 | linuxstb_ | So you should remove that conversion completely? |
| 12:12:02 | preglow | i'll whip me up some food before trying here, stomach's growling at me |
| 12:12:05 | preglow | oh yes, i shall |
| 12:15:04 | | Join Greek-Boy [0] (n=grb@193.220.82.245) |
| 12:15:54 | | Part Greek-Boy |
| 12:15:59 | *** | Saving seen data "./dancer.seen" |
| 12:27:30 | rasher | (mostly) Good news about aac |
| 12:28:23 | | Join uncledrax [0] (i=uncledra@ppp115-181.static.internode.on.net) |
| 12:31:27 | linuxstb_ | I'm curious to know which AAC files do and don't work. e.g. do "standard" 128kbps iTunes-encoded files work? |
| 12:33:04 | preglow | god knows, i'd love some juicy details |
| 12:33:24 | linuxstb_ | .. and a copy of the source. |
| 12:33:59 | linuxstb_ | We still need to sort out the problem of two codecs using .m4a |
| 12:34:36 | linuxstb_ | But I'm happy to rename my alac files to .alac if we can't think of an easy solution. |
| 12:34:37 | B4gder | oh my goodness... |
| 12:34:37 | preglow | oh yes |
| 12:34:47 | * | B4gder visits MR for the first time in a week or so |
| 12:35:01 | * | preglow hands B4gder a pair of dark sunglasses |
| 12:35:05 | linuxstb_ | B4gder: "Horrific" is the adjective normally applied. |
| 12:35:28 | B4gder | yes |
| 12:35:33 | B4gder | when expressing it in a mild way |
| 12:35:38 | linuxstb_ | But I think you can revert back to the old style if you log in. |
| 12:35:56 | B4gder | aha |
| 12:36:14 | LinusN | yes you can |
| 12:36:58 | LinusN | there is a "quick style chooser" in the bottom left corner, select "test" from there |
| 12:49:43 | amiconn | Zagor: The daily installer builds are still broken... |
| 13:00 |
| 13:00:06 | | Join thegeek [0] (n=thegeek@s057b.studby.ntnu.no) |
| 13:00:42 | elinenbe | LinusN: an unrelated quick question... have you had any time to work on the H300 series? |
| 13:00:48 | LinusN | no |
| 13:02:12 | elinenbe | thanks... just wondering. |
| 13:02:20 | elinenbe | good luck when you do get a chance. |
| 13:02:24 | LinusN | thx |
| 13:02:29 | elinenbe | I know it takes a good amount of time. |
| 13:22:30 | | Join tucoz [0] (n=81b17b04@labb.contactor.se) |
| 13:23:11 | preglow | my oh my, the codec sources need cleaning |
| 13:25:26 | tucoz | Just a small question. Radio plays when connected to usb (which is ok), but when disconnected it stops. Is this the wanted behaviour? It is the irver port I am talking about. |
| 13:25:27 | | Quit uncledrax (Read error: 104 (Connection reset by peer)) |
| 13:26:23 | tucoz | I mean it _keeps_ playing when connected. |
| 13:28:00 | LinusN | we haven't really thought that much about the desired behaviour in that case |
| 13:28:17 | LinusN | it works the same on the archos though |
| 13:28:43 | rasher | in my eyes it'd make sense to either a) stop playback on insert or b) not stop ot at all |
| 13:28:58 | LinusN | i agree |
| 13:30:09 | tucoz | Well, it does b) now, but it is the disconnect that is not really doing what I expect :) |
| 13:31:07 | rasher | Well I meant, b) stop it on neither insert nor remove |
| 13:31:52 | tucoz | then we agree |
| 13:33:18 | tucoz | If I wanted that behaviour (b). Is this done by checking the status of SYS_USB_DISCONNECTED in radio.c? |
| 13:37:36 | LinusN | add this after line 478 in radio.c: |
| 13:37:38 | LinusN | keep_playing = true; |
| 13:38:04 | tucoz | ok, thanks :) |
| 13:38:15 | LinusN | it will still leave the radio screen though |
| 13:38:24 | rasher | Does this also work if you're not in the radio screen? |
| 13:39:04 | LinusN | iirc, if you leave the radio screen with the radio playing, it will keep on playing even after exiting usb mode |
| 13:39:15 | rasher | ah, okay |
| 13:40:02 | LinusN | in fact, there is no need to leave the radio screen when leaving usb mode |
| 13:40:30 | rasher | indeed, it does keep playing |
| 13:40:35 | LinusN | but the general rockbox behaviour has always been to go back to the browser |
| 13:40:39 | preglow | linuxstb_: hmm, i might need to shift the numbers some anyway, i don't think there's enough dynamic headroom left in musepacks original format to allow for a big replaygain without clipping |
| 13:46:32 | tucoz | btw, did you see that someone got mp3 encoding working? Antonius Hellman iirc. |
| 13:46:44 | preglow | yes, i noticed |
| 13:46:50 | preglow | which encoder was he talking about? |
| 13:46:52 | preglow | shine or the other one? |
| 13:46:55 | rasher | shine, I think |
| 13:46:58 | rasher | that's how I read it at least |
| 13:47:11 | preglow | well, then i think he should commit it :) |
| 13:48:05 | tucoz | I think so too. For HQ recordings, people would use wavpack, and for other stuff, like lectures one could use mp3 as he said the quality is so so. |
| 13:48:26 | rasher | How about speex encoding - any idea how complex that is? |
| 13:48:30 | preglow | hmm |
| 13:48:32 | preglow | i think it might work |
| 13:49:06 | tucoz | It is floating point still |
| 13:49:17 | rasher | figure |
| 13:49:18 | preglow | no |
| 13:49:20 | rasher | s |
| 13:49:20 | preglow | it's not |
| 13:49:27 | rasher | ah. hurray, then |
| 13:49:28 | preglow | just parts of it |
| 13:49:31 | tucoz | it isn't, I checked last week |
| 13:49:39 | preglow | i think a complete encoder or decoder can be compiled in fixed point mode |
| 13:49:44 | preglow | at least i managed to have the decoder compile |
| 13:49:45 | tucoz | and then it was still floating point |
| 13:49:57 | preglow | tucoz: you're talking about the stable or the dev branch? |
| 13:50:12 | preglow | they've even ported it to blackfin, and that's impossible without fixed point support |
| 13:50:26 | tucoz | stable I guess, I just saw that they needed help with the fixed point version |
| 13:50:28 | preglow | that's even 16 bit fixed point |
| 13:50:32 | preglow | stable has no fixed point support |
| 13:50:32 | preglow | dev has |
| 13:50:57 | rasher | So speex on iriver is very possible? Encoding might be? |
| 13:51:02 | preglow | yes, i'd say so |
| 13:51:14 | preglow | decoding should certainly work, unless speex is more complex than i'm aware of |
| 13:51:22 | tucoz | I understood that they are working on fixed point. Didn't realize they were quite there yet though. |
| 13:52:16 | preglow | only one way to find out! |
| 13:54:25 | tucoz | hehe, you go ahead. I didn't even manage to get it to compile under rockbox. |
| 13:55:01 | preglow | perhaps |
| 13:57:20 | preglow | if(pcm_channels)*pcm_channels=pcm; |
| 13:57:28 | preglow | people using that little whitespace needs to use more whitespace :> |
| 13:57:44 | rasher | Clearly |
| 13:58:06 | preglow | this isn't c64 |
| 13:58:08 | rasher | Maybe his space key was broken |
| 13:58:24 | preglow | i've been there, i just started pasting spaces instead |
| 13:58:25 | preglow | ;) |
| 14:00 |
| 14:00:00 | * | preglow pokes Slasheri |
| 14:03:38 | tucoz | ah, now my radio is following plan b) |
| 14:03:53 | rasher | COMMIT |
| 14:03:57 | LinusN | does it leave the fm screen? |
| 14:04:02 | tucoz | no |
| 14:04:12 | LinusN | good |
| 14:04:17 | tucoz | It returns to fm screen when unplugged |
| 14:04:30 | paugh | preglow: any progress with flac? |
| 14:04:45 | LinusN | tucoz: then we need top decide what to do with the presets |
| 14:04:51 | LinusN | s/top/to/ |
| 14:04:59 | tucoz | hmm, what do you mean? |
| 14:05:16 | preglow | paugh: nothing more than what i did some weeks ago, no |
| 14:05:17 | LinusN | what if you entered usb mode to change the preset file? |
| 14:05:18 | tucoz | ah, if someone updates the preset file |
| 14:05:22 | tucoz | :) |
| 14:05:26 | amiconn | tucoz: Hopefully that doesn't interfere with the recording handling... |
| 14:05:43 | LinusN | amiconn: it won't enter usb mode if recording |
| 14:05:52 | tucoz | No, that is checked before |
| 14:05:55 | paugh | preglow, okies |
| 14:05:59 | tucoz | entering usb-mode |
| 14:06:52 | preglow | paugh: i wont to any more non-obvious optimising until i can measure my improvements, which wont be until either i or someone more clever makes a wav writer |
| 14:06:58 | preglow | s/to/do/ |
| 14:07:15 | tucoz | I just need to know what done=true does in the radio. done means done with the radio right? |
| 14:07:26 | tucoz | radio screen that is |
| 14:07:46 | LinusN | tucoz: line 277 |
| 14:08:05 | LinusN | done=true leaves the loop |
| 14:08:25 | tucoz | I get it |
| 14:08:30 | tucoz | I am lazy |
| 14:09:46 | LinusN | you could add this after usb mode: |
| 14:10:02 | LinusN | presets_loaded = false; |
| 14:10:07 | LinusN | load_presets(); |
| 14:10:31 | Slasheri | preglow: hi |
| 14:10:39 | LinusN | that will reload the presets |
| 14:11:35 | preglow | Slasheri: had any time for preparing some commits yet? :) |
| 14:11:41 | tucoz | ok, cool |
| 14:11:46 | preglow | i'm anxious to try your buffering |
| 14:12:02 | rasher | I'm anxious to try recording |
| 14:12:42 | Slasheri | preglow: not yet and currently i am little sick :/ |
| 14:13:01 | Slasheri | preglow: but i will prepare the dir cache for review on this week |
| 14:13:18 | tucoz | The buffering came to mind when I read about the remote handling. Threaded or not. Won't buffering cause problems or issues if the remote is in another thread? |
| 14:13:29 | preglow | why should it? |
| 14:13:46 | tucoz | I don't know |
| 14:14:07 | preglow | Slasheri: and why does pcmbuf_insert take char * when pcmbuf_insert_split takes void * ? |
| 14:14:18 | preglow | historical reasons? ;) |
| 14:14:38 | tucoz | that is why I am asking. I do not know how the buffering works. |
| 14:15:09 | tucoz | I meant caching of course |
| 14:15:17 | Slasheri | preglow: Hmm, yes. Or maybe the reason was that the samples may be 16 or 32 bits that are passed to that function |
| 14:15:25 | | Join Rori [0] (i=MO-Pants@deadman3000.plus.com) |
| 14:15:30 | Rori | LOL @ http://www.theregister.co.uk/2005/09/27/ipod_nano_more_scratching/ |
| 14:15:31 | Slasheri | So using char or short wouldn't be right either |
| 14:16:03 | *** | Saving seen data "./dancer.seen" |
| 14:16:48 | Rori | BTW I saw the new Sony 20GB player the other day. Small and swish looking and can take a knock or two as demonstrated by them dropping it onto the counter several times. |
| 14:16:58 | Slasheri | but yes, char* might be better |
| 14:17:21 | Rori | Shame the screen is not full colour and no gapless though |
| 14:18:21 | tucoz | Rori: sounds like a demonstration in the lines of infomersials where they cut tin boxes with their fantastic knives. |
| 14:19:10 | rasher | Hmm.. http://ihpos.blogspot.com/ interesting |
| 14:19:12 | tucoz | But I do like the looks of Sony's mp3 players |
| 14:19:25 | preglow | what? |
| 14:19:29 | preglow | isn't interleaved audio supported yet? |
| 14:19:53 | preglow | oh yes |
| 14:20:19 | tucoz | rasher: fun |
| 14:23:23 | preglow | hah |
| 14:23:25 | | Join [0x00] [0] (i=ThE@p549BC4BF.dip.t-dialin.net) |
| 14:26:12 | * | B4gder bugs his friend to covert his sudoku site to a .ss generating one |
| 14:26:15 | B4gder | convert |
| 14:26:20 | | Part [0x00] |
| 14:29:11 | linuxstb_ | B4gder: What does it produce at the moment? |
| 14:29:18 | B4gder | html |
| 14:29:26 | linuxstb_ | Ah. We don't want to parse that. |
| 14:29:30 | B4gder | nope |
| 14:29:43 | B4gder | it should be very easy for him to make .ss as well |
| 14:30:25 | preglow | linuxstb_: well, it's ALMOST realtime now |
| 14:30:33 | preglow | but i've done something wrong |
| 14:30:36 | preglow | sounds pretty bad |
| 14:32:17 | tucoz | maybe a bad patch, but it works. Returns to radio-screen on usb disconnect. also handles changes in the preset file. http://www.ii.uib.no/~martina/radio_patch.diff |
| 14:32:46 | Rori | hey guys what is wrong with the bass and treble controls? if I turn bass up the treble gets quieter and if I turn up treble the bass ends just drops. no additional bass or treble on either control. |
| 14:33:34 | rasher | you probably have the volume way up? |
| 14:33:37 | Rori | it's better with both off |
| 14:33:45 | Rori | I have it 100% yeah heh |
| 14:33:52 | preglow | Rori: if the volume is at 100 and you use the eq, the main volume will be lowered automatically to avoid clipping |
| 14:34:19 | rasher | http://www.rockbox.org/twiki/bin/view/Main/IriverFAQ#Why_doesn_t_Rockbox_play_as_loud |
| 14:34:51 | Rori | yeah noticed pre-amp does not work either when at 100% |
| 14:35:08 | rasher | how could it? |
| 14:35:18 | rasher | well, except for clipping |
| 14:35:27 | preglow | works for me |
| 14:35:51 | LinusN | tucoz: no need to set screen_freeze twice |
| 14:35:52 | preglow | 100% volume and 12db preamp, sounded really, really bad |
| 14:36:05 | tucoz | LinusN: oh, ok |
| 14:36:27 | rasher | LinusN: how do you feel about the "enable/disable statusbar wps tags"? |
| 14:36:41 | LinusN | i think it's a good idea |
| 14:36:57 | LinusN | but i'm not sure i like the way it is implemented |
| 14:37:09 | LinusN | i haven't looked at the latest patch though |
| 14:37:14 | preglow | Slasheri: is 32 bit interleaved stereo audio supported by pcmbuf_insert? |
| 14:37:19 | rasher | He didn't change a lot |
| 14:37:25 | preglow | Slasheri: to my untrained eye it doesn't look like it's handled at all |
| 14:37:33 | rasher | LinusN: Pretty much just fix the bug I pointed out |
| 14:37:50 | LinusN | ok |
| 14:38:02 | LinusN | i'll have another look one of those days |
| 14:38:25 | Slasheri | preglow: yes should be when dsp is enabled |
| 14:38:49 | LinusN | tucoz: you don't need to set keep_playing=true since you don't leave the radio screen |
| 14:39:45 | tucoz | hehe |
| 14:40:13 | tucoz | Look what I know. Then it's easier than I thought. |
| 14:40:34 | tucoz | Now I understand the code, didn't 5 minutes ago |
| 14:40:57 | tucoz | and also no need to freeze the screen either |
| 14:41:01 | LinusN | nope |
| 14:43:17 | preglow | Slasheri: and conversion from arbitrary sample depths are handled correctly? |
| 14:43:37 | Slasheri | preglow: yes, that's handled by the dsp |
| 14:43:38 | tucoz | Then, is this ok? http://www.ii.uib.no/~martina/radio_patch.diff |
| 14:44:11 | rasher | By the way, m4a supports per-sample samplerate - can the dsp handle that? |
| 14:44:17 | LinusN | tucoz: looks ok |
| 14:44:20 | rasher | (lord knows why you'd do that though) |
| 14:44:48 | preglow | per sample sample rate? |
| 14:44:52 | preglow | that doesn't make sense |
| 14:45:12 | rasher | eh.. frame? |
| 14:45:23 | preglow | like in mp3, then? |
| 14:45:27 | preglow | if so, yes, we already handle that |
| 14:45:27 | Slasheri | rasher: that depends but should be possible |
| 14:45:33 | rasher | Okay. |
| 14:46:00 | linuxstb_ | preglow: How do we handle that? |
| 14:46:25 | preglow | mpa.c line 236 |
| 14:47:37 | linuxstb_ | OK. But is the track duration calculated correctly? |
| 14:47:52 | preglow | well, afaik, that is handled by id3 data |
| 14:47:56 | preglow | so it's out of our hands |
| 14:48:32 | preglow | or in the case of frame counts from xing headers or the like, no, it's probably not |
| 14:48:36 | linuxstb_ | Or even the current location in the file - that's normally calculated by dividing by samplerate. |
| 14:48:41 | preglow | we'd need to keep a running estimate thebn |
| 14:48:46 | preglow | yes |
| 14:48:55 | preglow | and i don't think we should do anything more complicated than that |
| 14:49:07 | preglow | switching sample rate in the middle of a file doesn't make sense |
| 14:49:11 | preglow | we just make sure we handle it gracefully |
| 14:49:15 | linuxstb_ | mpa.c should probably be changed to keep the current position indicator in ms, not samples. |
| 14:49:38 | preglow | in which case you will quickly run into precision problems |
| 14:49:52 | linuxstb_ | I thought each frame was an integer number of ms in duration? |
| 14:49:54 | preglow | unless you let it be a 64 bit fixed point int or something |
| 14:50:17 | preglow | no, not as far as i know |
| 14:50:37 | preglow | in fact, i can pretty much guarantee it's not |
| 14:51:12 | linuxstb_ | Maybe it's just MP2 then - I don't really use MP3. |
| 14:51:31 | preglow | Slasheri: length passed to the insert functions is bytes per channel, yes? |
| 14:51:42 | LinusN | iirc, 26.12ms for a 44.1kHz layer3 frame |
| 14:51:43 | preglow | i can pretty much guarantee it's not the case there either |
| 14:51:50 | preglow | LinusN: that's correct |
| 14:51:56 | preglow | LinusN: and even that's an approximation |
| 14:52:09 | preglow | linuxstb_: the number of samples per frame is independent of sample rate |
| 14:52:13 | Slasheri | preglow: yes i think so :) |
| 14:52:34 | preglow | linuxstb_: for some combinations it's bound to be a non-integer |
| 14:52:48 | linuxstb_ | Ignore me then. I only have 48KHz layer 2 files, which I think are exactly 24ms per frame. |
| 14:53:17 | preglow | linuxstb_: that is correct |
| 14:53:46 | preglow | but not for 44100 which is far more common |
| 14:56:26 | Slasheri | LinusN: btw, if i would like to have a global HAVE_DIRCACHE define is firmware/export/config-h100.h (and h120) the right place to put that? |
| 14:57:38 | | Join webguest02 [0] (n=5106d7e1@labb.contactor.se) |
| 14:58:25 | tucoz | added patch to the tracker |
| 14:58:55 | | Quit webguest02 (Client Quit) |
| 14:59:52 | | Part tucoz |
| 15:00 |
| 15:00:25 | LinusN | Slasheri: yes, or define it based on the ram size |
| 15:00:33 | | Join tucoz [0] (n=81b17b04@labb.contactor.se) |
| 15:00:58 | Slasheri | ok, good |
| 15:01:07 | LinusN | #if MEM > 8 |
| 15:01:08 | rasher | The latter sounds more reasonable |
| 15:01:16 | LinusN | #define HAVE_DIRCACHE |
| 15:01:17 | LinusN | #endif |
| 15:01:26 | LinusN | or sth like that |
| 15:01:32 | Slasheri | what is then the right file to put that define? |
| 15:01:43 | B4gder | config.h probably |
| 15:01:48 | Slasheri | ah, yes :) |
| 15:01:50 | LinusN | config.h, after including the various special config files |
| 15:01:59 | | Part tucoz |
| 15:02:11 | preglow | argh |
| 15:02:17 | preglow | the right channel is all noise whatever i do |
| 15:02:35 | LinusN | gotta go, cu all |
| 15:02:38 | | Part LinusN |
| 15:03:06 | Slasheri | preglow: hmm.. what are you trying to do? |
| 15:03:41 | | Join tucoz [0] (n=martin@hornved.ii.uib.no) |
| 15:05:24 | preglow | Slasheri: mpc.c was converting the numbers to 16 bits before passing to pcmbuf_insert, i'm making it pass the native format instead |
| 15:05:31 | preglow | Slasheri: which seems to be 32 bit interleaved stereo |
| 15:05:38 | | Quit tucoz (Client Quit) |
| 15:05:50 | Slasheri | ah, that sounds nice |
| 15:06:10 | preglow | the left channel is music at the original tempo, but at half pitch and the right channel is pure high amplitude noise |
| 15:06:35 | Slasheri | do you think it could be then possible to play some mpc files realtime? |
| 15:06:48 | preglow | no, but it's not far away |
| 15:06:53 | Slasheri | preglow: have you set up the dsp correctly? |
| 15:06:56 | Slasheri | ok :) |
| 15:07:00 | preglow | wanna have a look at the source? |
| 15:07:05 | Slasheri | hmm, maybe |
| 15:07:44 | preglow | http://www.pvv.ntnu.no/~thomj/rockbox/mpc.c |
| 15:07:46 | preglow | i think i have |
| 15:07:48 | | Join uncledrax [0] (i=uncledra@ppp115-181.static.internode.on.net) |
| 15:10:05 | Slasheri | hard to say but there might be some bugs in the dsp code if you really have interleaved stereo (i think that's still untested) |
| 15:10:32 | preglow | yes, so do i |
| 15:11:57 | linuxstb_ | Don't shoot me for asking this, but when the tag database was being designed, was using the ITunes database format considered? |
| 15:12:25 | linuxstb_ | I'm not just thinking about Rockbox on the ipod - but there are lots of tools available to manipulate such databases. |
| 15:12:27 | preglow | is the format even described anywhere? |
| 15:12:31 | preglow | ahh, ok |
| 15:12:37 | linuxstb_ | http://ipodlinux.org/ITunesDB |
| 15:12:57 | linuxstb_ | Plus all the open source tools that use it - e.g. gtkpod |
| 15:13:02 | B4gder | linuxstb_: we wanted a slim and mean format for less capable devices too |
| 15:13:15 | B4gder | the itunes db doesn't seem to match that criteria |
| 15:13:28 | linuxstb_ | That's all I was asking - so you did look at it? |
| 15:13:34 | B4gder | yes, briefly |
| 15:14:10 | linuxstb_ | A file browser interface is pointless on an ipod that's been populated by itunes - filenames are hashed. |
| 15:14:19 | B4gder | ugha |
| 15:14:25 | Slasheri | linuxstb_: i would like to sync the rockbox with amarok's database |
| 15:14:27 | linuxstb_ | e.g. F01/IUEQ.m4a |
| 15:15:59 | linuxstb_ | And directory "F01" doesn't relate to an album - it's just an arbitrary way of splitting the files into directory. |
| 15:16:08 | preglow | ahahaha |
| 15:16:29 | linuxstb_ | So it seems each file is given a 7 character hash, the first 3 are the directory name, the last 4 are the filename. |
| 15:16:51 | linuxstb_ | The metadata is still in the .m4a file though. |
| 15:17:09 | rasher | obfuscation at its finest |
| 15:17:21 | rasher | "no sire, you can't move files off your ipod" |
| 15:17:27 | rasher | "See, they're not there!" |
| 15:18:44 | linuxstb_ | All the music files and the iTunesDB are stored in a directory called "iPod_Control". This has the system/hidden bits set on FAT32 so Windows users can't normally see it. |
| 15:21:27 | linuxstb_ | Any ideas for how Rockbox could support such a scheme? |
| 15:22:03 | rasher | Reading the db, I guess |
| 15:22:43 | rasher | I don't see how else you'd use such a player |
| 15:24:00 | rasher | can't itunes be told not to mangle filenames though? |
| 15:24:13 | rasher | I was under the impression that you could use it for regular ums players as well |
| 15:24:33 | | Quit B4gder ("time to say moo") |
| 15:25:21 | linuxstb_ | rasher; I don't think you can tell anything to iTunes. Maybe other tools like gtkpod could. |
| 15:26:11 | rasher | I'm pretty sure you can use iTunes with other players |
| 15:26:17 | rasher | in some way or other |
| 15:26:28 | rasher | I'd expect it not to mangle filenames in that case |
| 15:29:45 | * | preglow curses people who use interleaved data |
| 15:31:15 | linuxstb_ | rasher: I would be surprised if you could use iTunes with other players. |
| 15:31:40 | rasher | well, I'll try |
| 15:32:00 | linuxstb_ | iTunes stored the files on your PC in a sensible Artist/Album/NN-TrackName.m4a structure. But not when you use it to sync files to the ipod. |
| 15:32:10 | linuxstb_ | s/stored/stores/ |
| 15:32:22 | rasher | But that's because they know the ipod to read the music db thing |
| 15:35:25 | | Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
| 15:35:34 | linuxstb | http://www.dapreview.net/comment.php?comment.news.2204 - the "BadApple" plugin |
| 15:36:00 | linuxstb | So it seems that standard itunes can't do that. |
| 15:36:05 | rasher | Ah |
| 15:36:10 | rasher | wellthen |
| 15:36:19 | linuxstb | http://www.badfruit.com/faq.html |
| 15:36:24 | linuxstb | Explains it all. |
| 15:37:13 | preglow | deinterleaver code looks ok to me |
| 15:37:36 | linuxstb | Seems that BadApple only syncs MP3 files to generic players - it ignores other formats :( |
| 15:37:39 | rasher | Maybe that's what people have been talking about, and I just thought it was something iTunes could do |
| 15:39:24 | Vladoman | Hi, I just built the Iriver X11 simulator, when I start it I get something like: We open the real file 'archos/.rockbox/codecs/mpa.codec', |
| 15:39:29 | | Join ]RowaN[ [0] (n=5689067b@labb.contactor.se) |
| 15:39:38 | Vladoman | does that mean I need to create this folder and put a codec there? |
| 15:39:46 | ]RowaN[ | guys is the iriver hd in fat32 or ntfs format? |
| 15:39:52 | linuxstb | Vladoman: Did you do a "make install" |
| 15:39:53 | rasher | ]RowaN[: fat32 |
| 15:39:56 | Vladoman | nope |
| 15:39:59 | ]RowaN[ | bugger |
| 15:40:02 | rasher | Why? |
| 15:40:31 | ]RowaN[ | i was going to get a "usbextreme" bootdisc for my playstation2.. it lets u run games from a usb hd, but has to be ntfs aparently |
| 15:40:44 | linuxstb | Vladoman: Then type "make install" from your build directory :). |
| 15:41:00 | linuxstb | That will update the archos/.rockbox/ directory. |
| 15:41:16 | Vladoman | I just did, it crashes now with: Floating point exception./rockboxui |
| 15:41:26 | Vladoman | when I tryx to play an MP3 file |
| 15:41:30 | Vladoman | *try |
| 15:41:41 | linuxstb | Is this the X11 or win32 simulator? |
| 15:41:57 | Vladoman | X11 |
| 15:42:02 | | Join tvelocity [0] (n=tony@ipa112.2.tellas.gr) |
| 15:42:36 | linuxstb | Under Linux or Cygwin (or something else?) |
| 15:42:49 | Vladoman | pure Linux |
| 15:42:59 | linuxstb | OK, let me test it as well. |
| 15:43:03 | Vladoman | thx |
| 15:43:12 | Vladoman | it's 2.5 |
| 15:44:05 | linuxstb | Forgot to ask - which target are you simulating? |
| 15:44:10 | ]RowaN[ | if i formatted my river to ntfs.. ? it would no longer boot? |
| 15:44:22 | rasher | ]RowaN[: no |
| 15:44:29 | linuxstb | ]RowaN[: Yes, neither Rockbox or the iRiver firmware will recognise it. |
| 15:44:52 | Vladoman | iriver H120/H140 |
| 15:45:12 | linuxstb | Vladoman: OK, compiling now. |
| 15:46:40 | | Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 15:49:23 | linuxstb | Vladoman: Works fine for me under Linux (Debian). |
| 15:50:14 | Vladoman | :-( |
| 15:50:33 | linuxstb | I don't know what to suggest apart from starting again with a clean cvs checkout and a clean build directory. |
| 15:51:53 | Vladoman | I'm running it in DDD now |
| 15:52:11 | | Quit linuxstb_ (Read error: 110 (Connection timed out)) |
| 15:52:18 | Vladoman | Program received signal SIGFPE, Arithmetic exception. |
| 15:52:19 | Vladoman | [Switching to Thread 16384 (LWP 17764)] |
| 15:52:19 | Vladoman | 0x0806620b in peak_meter_draw (x=0, y=56, width=160, height=8) at recorder/peakmeter.c:847 |
| 15:52:39 | rasher | TiMiD[despair]: patching |
| 15:53:15 | Vladoman | look like it is this line: |
| 15:53:17 | Vladoman | db_scale_lcd_coord[i] = |
| 15:53:17 | Vladoman | (i * (MAX_PEAK / 10) - peak_meter_range_min) * |
| 15:53:17 | Vladoman | meterwidth / pm_range; |
| 15:55:08 | Vladoman | Gotcha, it works if I disable the peakmeter! |
| 15:55:37 | linuxstb | That's strange - the WPS in my simulator contains a (non-working) peakmeter. |
| 15:55:57 | linuxstb | i.e. the peakmeter displays, but doesn't work. |
| 15:56:27 | Vladoman | maybe pm_range has a random value and mine is 0? |
| 15:56:39 | linuxstb | Vladoman: Possibly. |
| 15:57:41 | Vladoman | now, if I knew the keys to use... |
| 15:59:23 | rasher | TiMiD[despair]: Good job! |
| 15:59:30 | * | rasher browses on his remote |
| 16:00 |
| 16:00:32 | rasher | Quite cool |
| 16:00:58 | preglow | xavier patch? |
| 16:01:03 | rasher | no |
| 16:01:07 | rasher | TiMiD patch |
| 16:01:11 | | Join webguest41 [0] (n=cf6bcafe@labb.contactor.se) |
| 16:01:16 | amiconn | Vladoman: (1) even if pm_range is zero, you shouldn't get a floating point exception |
| 16:01:17 | | Quit webguest41 (Client Quit) |
| 16:01:25 | amiconn | Rockbox doesn't use floating point |
| 16:01:26 | rasher | http://forums.rockbox.org/index.php?topic=1549.msg9597 |
| 16:01:54 | amiconn | (2) The keyboad layout is printed to the console you started the simulator from |
| 16:02:19 | Vladoman | thx, me = blind :-) |
| 16:03:53 | | Quit uncledrax () |
| 16:05:13 | rasher | I so need to add this to my patched-up build |
| 16:05:17 | * | [IDC]Dragon unlurks |
| 16:05:58 | [IDC]Dragon | amiconn, last time I didn't manage to d/l your gcc |
| 16:06:43 | amiconn | Yeah, probably because the file wasn't called as announced here. There was a stray dot in the filename |
| 16:07:05 | [IDC]Dragon | do you still have it? |
| 16:07:20 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
| 16:08:01 | amiconn | No, I would need to zip it again, and my apache isn't running atm |
| 16:08:11 | | Quit rasher (Remote closed the connection) |
| 16:08:28 | ]RowaN[ | ah now i read that usbextreme requires fat32, NOT ntfs |
| 16:08:59 | [IDC]Dragon | no hurry |
| 16:09:26 | [IDC]Dragon | I'd just like to compile a bootbox with 2.5 someday |
| 16:09:46 | | Join rasher [0] (n=jonas@62.79.64.148.adsl.hs.tiscali.dk) |
| 16:10:37 | Vladoman | amiconn: I just added a "return" in peak_meter_draw() and then the crash disappeared |
| 16:11:41 | | Join XavierGr [0] (n=XavierGr@ppp41-adsl-111.ath.forthnet.gr) |
| 16:13:16 | rasher | TiMiD[despair]: oi, just got an IllInstr after plugging usb with your patch(es) |
| 16:13:26 | rasher | TiMiD[despair]: while in wps |
| 16:15:43 | preglow | mpc is now aaaaaaalmost 100% realtime for this standard encoded file i have |
| 16:16:04 | *** | Saving seen data "./dancer.seen" |
| 16:16:14 | preglow | too bad the sound doesn't sound like shit |
| 16:18:38 | preglow | i mean it sounds like a bag of shit |
| 16:18:47 | preglow | to use the new terminology |
| 16:19:14 | rasher | wait. |
| 16:19:20 | * | rasher is confused |
| 16:19:57 | rasher | I thought firefly on the forums was timid, for some reason... but that is not the case, is it? |
| 16:20:39 | preglow | *shrugagge* |
| 16:22:10 | rasher | Anyway, this remote support *looks* right |
| 16:22:16 | rasher | from the user's viewpoint |
| 16:22:46 | rasher | menus and filetree is displayed correctly |
| 16:23:46 | * | amiconn is confused |
| 16:24:35 | preglow | but i gotta go |
| 16:24:36 | preglow | later |
| 16:26:09 | rasher | amiconn: about what? |
| 16:26:40 | amiconn | Confusion solved, I just didn't remember how to login to cvs with a different user name that my local one |
| 16:26:48 | amiconn | s/that/than/ |
| 16:27:16 | ]RowaN[ | offtopic: does anyone know if theres a gfx card which can output (im talking TV-out) resolutions lower than 640x480? |
| 16:30:01 | | Quit linuxstb (Read error: 110 (Connection timed out)) |
| 16:30:18 | amiconn | Vladoman: I'm just trying to build the h120 x11 sim under linux |
| 16:44:54 | | Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
| 16:47:09 | amiconn | I don't receive a floating point exception here |
| 16:48:15 | | Quit XavierGr () |
| 16:48:49 | rasher | I have a rockbox with remote support build if anyone wants to test and don't want to apply the patches: http://rasher.dk/rockbox/rockbox-remote.zip |
| 16:49:14 | rasher | This is the patch from http://forums.rockbox.org/index.php?topic=1549.0 |
| 16:51:30 | linuxstb | rasher: Have you tested the patch with the remote unplugged? |
| 16:52:35 | rasher | Not yet |
| 16:52:56 | rasher | a quick test doesn't show any problems |
| 16:53:14 | rasher | (ie. remove remote, change menus, replug) |
| 16:53:34 | ashridah | rasher: it apply against currnt cvs HEAD? |
| 16:53:47 | linuxstb | It seems a _very_ large patch. (160KB) |
| 16:54:10 | rasher | ashridah: It depends on two other patches - included in the package |
| 16:54:24 | rasher | This is not my work by the way, if anyone was under this impression |
| 16:54:48 | rasher | (the author posted the forum thread) |
| 16:55:04 | rasher | linuxstb: it touches a lot of files |
| 16:55:45 | rasher | It even patches rolo, so I get "Rolo loading" on the remote |
| 16:55:45 | | Quit tvelocity ("Leaving") |
| 16:56:59 | rasher | I think this is the sort of patch that should be acted upon quite quickly |
| 16:57:07 | rasher | or it'll end up being impossible |
| 16:57:40 | rasher | TiMiD[despair]: I was confusing you for a forum poster |
| 16:58:16 | linuxstb | My first impression after a brief look at the patch is that it just seems to duplicate everything done on the mail display to the remote - thereby doubling the amount of code. |
| 16:58:23 | linuxstb | s/mail/main/ |
| 16:58:42 | linuxstb | But I'm not sure how much that can be avoided. |
| 16:59:11 | rasher | Should be possible to avoid in some places with the inclusion of a list-widget I guess |
| 16:59:25 | TiMiD[despair] | re |
| 16:59:29 | linuxstb | Some functions will need to be made more general - and called twice (once for main LCD, once for remote). |
| 17:00 |
| 17:00:06 | ashridah | whoa |
| 17:00:08 | rasher | Anyway, this is at least better than XavierGr's patch, since it correctly takes screen size into account |
| 17:00:09 | ashridah | it works. |
| 17:00:24 | rasher | But, I haven't looked at the source, to be honest. |
| 17:00:42 | Vladoman | amiconn: thx for the help, it's not really important. |
| 17:00:43 | * | ashridah is just happy to not have to take out his player to poke at it |
| 17:01:10 | TiMiD[despair] | if you don't accept this patch, I'm working on a totally different approach |
| 17:01:18 | rasher | TiMiD[despair]: oh, it *was* you? |
| 17:01:23 | rasher | or wasn't |
| 17:01:24 | TiMiD[despair] | nope |
| 17:01:24 | rasher | haha |
| 17:01:28 | rasher | I get it now. |
| 17:01:32 | * | rasher is unconfused. |
| 17:01:42 | TiMiD[despair] | I didn't posted this patch |
| 17:01:57 | rasher | I think your approach (the list-widget) is more likely to be accepted |
| 17:02:01 | TiMiD[despair] | (Copy-paste code is boring :p) |
| 17:02:06 | TiMiD[despair] | well |
| 17:02:17 | TiMiD[despair] | mine it's working pretty good :p |
| 17:02:21 | rasher | But of course, some places will have to be fixed like this patch is doing |
| 17:02:33 | rasher | So those parts of this patch can be used |
| 17:02:34 | TiMiD[despair] | you can display synchronized lists on both display in 3 lines :) |
| 17:02:47 | ashridah | the scrolling settings don't seem to have an immediate effect on the remote |
| 17:02:57 | TiMiD[despair] | you can also hot-switch from a display to another |
| 17:03:28 | TiMiD[despair] | but it need more work (and it would involve to modify more deeply the existing code) |
| 17:03:47 | | Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
| 17:04:02 | ashridah | has issues drawing the marker when scrolling through the file list as well |
| 17:04:02 | | Quit ]RowaN[ ("CGI:IRC (EOF)") |
| 17:04:18 | TiMiD[despair] | by the way I have a question |
| 17:04:32 | rasher | Any places that aren't menus or filetrees though, will benefit from this patch even if we want to go with TiMiD[despair]'s approach |
| 17:04:49 | rasher | I think I'll try to split those parts out from this patch |
| 17:04:57 | TiMiD[despair] | the lcd_putc on the player takes an 'unsigned short' for the character to display |
| 17:05:07 | rasher | ie. stuff like error messages and such |
| 17:05:38 | TiMiD[despair] | but to display the cursor, the value is '#define CURSOR_CHAR 0x92' |
| 17:05:49 | TiMiD[despair] | and 0x92>127, so wtf ?? |
| 17:07:14 | ashridah | isn't a short 16 bits long? |
| 17:07:38 | TiMiD[despair] | rasher: I intend to uste the same 'gui list' code in both menus and filetree (since it's possible that one day menus have icons too ...) |
| 17:07:46 | TiMiD[despair] | ouch |
| 17:07:52 | TiMiD[despair] | you are right :) |
| 17:08:14 | ashridah | and if it's unsigned, 0x92 wouldn't be a problem for an 8 bit datatype |
| 17:08:37 | rasher | TiMiD[despair]: makes sense |
| 17:08:43 | TiMiD[despair] | the problem is that when I try to display a char > 127, it doesn't work |
| 17:08:56 | TiMiD[despair] | 17:07 < ashridah> isn't a short 16 bits long? |
| 17:09:00 | TiMiD[despair] | shit |
| 17:09:06 | TiMiD[despair] | lcd_putc(0, 1, 65426 '0xff92') |
| 17:09:31 | * | rasher stares at 4800 lines of patch |
| 17:09:49 | TiMiD[despair] | that's what I get after calling screen->putc(x, y, icon); (which is a pointer to lcd_putc) |
| 17:10:02 | ashridah | rasher: heh, that's what you get when you have a month long freeze :) |
| 17:10:15 | TiMiD[despair] | when icon=CURSOR_CHAR (0x92) |
| 17:10:16 | rasher | ashridah: No, that's just the remote-patch |
| 17:10:37 | linuxstb_ | rasher: Does it use the same wps file for both the remote and the player? |
| 17:10:46 | rasher | linuxstb: the remote wps is hardcoded |
| 17:10:50 | | Nick TiMiD[despair] is now known as TiMiD (n=TiMiD[FD@asgard.valombre.net) |
| 17:10:52 | ashridah | rasher: i know, but given that it wasn't able to be piece-wise merged... (if you wanted to merge it) because of the freeze... :) |
| 17:11:07 | rasher | Ah, like that |
| 17:11:14 | rasher | I guess it would be nice to have it split up |
| 17:11:29 | rasher | like "this patch adds filetree browsing on the remote" |
| 17:11:42 | rasher | "this one adds debug menu" |
| 17:11:44 | rasher | and so on |
| 17:12:11 | rasher | I wonder if there are any patch-editing gui tools |
| 17:12:20 | TiMiD | rasher: kdiff :) |
| 17:12:52 | rasher | Figures |
| 17:13:06 | rasher | With me using ubuntu/gnome |
| 17:13:42 | rasher | anyway, I think I'll just cut'n'paste a lot |
| 17:18:03 | | Quit linuxstb (Read error: 110 (Connection timed out)) |
| 17:21:19 | linuxstb_ | There seem to be lots of places in the code where a call to lcd_?? is followed by an identical call to lcd_remote_?? |
| 17:22:32 | rasher | I don't see how that can be avoided |
| 17:23:08 | linuxstb_ | By having one function do both. |
| 17:23:21 | rasher | oh, an identical function |
| 17:23:37 | rasher | identical call* |
| 17:24:06 | linuxstb_ | Yes, the identical parameters. Not quite sure why that works, but it seems to be quite widespread in the patch. |
| 17:24:13 | | Join Moos [0] (i=DrMoos@m50.net81-66-159.noos.fr) |
| 17:24:30 | rasher | why wouldn't it work? |
| 17:25:28 | | Quit xen` (Read error: 110 (Connection timed out)) |
| 17:25:33 | TiMiD | since all lcd_ and lcd_remote have the same prototype, you can do a fn pointer that will call one or the other depending on your need |
| 17:25:52 | TiMiD | (that's how I decided to handle it) |
| 17:27:12 | TiMiD | with this approach you can handle as may screens as you want :) |
| 17:37:31 | | Join muesli- [0] (i=muesli_t@hmln-d9b8efb8.pool.mediaWays.net) |
| 17:38:13 | rasher | Say, how likely is it that some guy will be called "Rubber Glove"? |
| 17:57:55 | | Quit paugh ("Leaving") |
| 18:00 |
| 18:03:17 | | Quit ashridah ("Leaving") |
| 18:05:13 | | Quit muesli- (Read error: 113 (No route to host)) |
| 18:05:33 | | Join muesli- [0] (i=muesli_t@Bc1f5.b.pppool.de) |
| 18:10:05 | | Quit DangerousDan (Read error: 110 (Connection timed out)) |
| 18:16:05 | *** | Saving seen data "./dancer.seen" |
| 18:16:57 | | Nick Lynx_ is now known as Lynx_awy (n=lynx@tina-10-4.genetik.uni-koeln.de) |
| 18:18:53 | | Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.umbc.edu) |
| 18:28:59 | | Quit muesli- (Read error: 110 (Connection timed out)) |
| 18:30:54 | fuzzie | status of AAC: libfaad ICEs when crosscompiling. more soon! |
| 18:30:57 | fuzzie | i mean, gr. :P |
| 18:31:19 | Moos | congrates :) |
| 18:38:37 | | Join Sucka [0] (n=NNSCRIPT@host81-156-209-15.range81-156.btcentralplus.com) |
| 18:38:51 | | Quit [IDC]Dragon ("CGI:IRC") |
| 18:44:49 | | Join tvelocity [0] (n=tony@ipa112.2.tellas.gr) |
| 18:52:07 | | Join webguest47 [0] (n=53afb0c2@labb.contactor.se) |
| 18:57:10 | | Join Lear [0] (n=chatzill@h36n10c1o285.bredband.skanova.com) |
| 19:00 |
| 19:07:35 | rasher | Good work on the gcc4 changes |
| 19:08:02 | rasher | Any ideas if it's noticably faster? |
| 19:08:13 | rasher | I guess it's hard to tell without a wav writer |
| 19:08:17 | fuzzie | gcc4 changes? |
| 19:08:20 | fuzzie | does it work with gcc4, now? |
| 19:08:30 | fuzzie | it seems silly trying to workaround ICEs if it does |
| 19:08:35 | | Join muesli- [0] (i=muesli_t@Bc1e3.b.pppool.de) |
| 19:09:05 | rasher | Lear has done changes to make iriver compile with gcc4 |
| 19:09:14 | fuzzie | checked in? |
| 19:09:15 | Lear | I haven't really tested yet. Could play a Q10 ogg without skipping, that had had problems before, but it was a while ago I tested that. I was planning to check that file again with a GCC3 build. |
| 19:09:43 | Lear | I haven't encountered ICE:s at least... |
| 19:10:04 | rasher | fuzzie: that is assuming that faad builds with gcc4-m68k |
| 19:10:14 | rasher | which may not be the case |
| 19:10:19 | fuzzie | well, it seems worth a try |
| 19:10:23 | rasher | sure |
| 19:10:24 | Lear | rasher: you working on that port? |
| 19:10:28 | rasher | No, fuzzie is |
| 19:10:31 | fuzzie | it sure works with gcc4 x86/ppc |
| 19:10:32 | Lear | Ah. |
| 19:10:38 | fuzzie | even though that means nothing |
| 19:10:44 | rasher | I just test, since fuzzie doesn't have an iriver |
| 19:10:47 | fuzzie | my recent experiences with non-rockbox m68k toolchains have been < * |
| 19:11:05 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
| 19:11:16 | fuzzie | eg, half of debian failing to compile |
| 19:11:19 | rasher | Gcc4 for anything that isn't x86 seems half-baked |
| 19:11:35 | rasher | But if it builds rockbox, it's worth a try |
| 19:11:46 | rasher | Can be made to build rockbox, that is |
| 19:11:46 | fuzzie | so, is this stuff checked in? |
| 19:11:52 | rasher | No |
| 19:12:35 | rasher | Not a lot of changes to be done, really |
| 19:15:55 | | Join linuxstb [0] (n=5343d4aa@labb.contactor.se) |
| 19:16:14 | linuxstb | fuzzie: Which version of libfaad are you using? |
| 19:16:25 | fuzzie | the one you handed me |
| 19:16:42 | rasher | linuxstb: which gcc do you use |
| 19:16:44 | fuzzie | the errors i was encountering might be issues with it being an older version or issues with me not initialising it properly right now |
| 19:17:01 | linuxstb | The version I gave you compiles fine with 3.4.4 |
| 19:17:10 | fuzzie | with an iRiver target? |
| 19:17:16 | rasher | Weird. That's what I use. |
| 19:17:38 | rasher | And I got the ICE |
| 19:17:58 | linuxstb | I'm using the CVS binutils from August 2005. |
| 19:18:13 | rasher | 2.16 |
| 19:18:17 | linuxstb | GNU assembler 2.16.91 20050813 |
| 19:18:41 | fuzzie | i guess i need to build a cvs version then |
| 19:19:07 | linuxstb | fuzzie: Did you change anything in the config.h ? |
| 19:19:21 | fuzzie | nope |
| 19:19:27 | fuzzie | it looked okay as it was? |
| 19:19:38 | fuzzie | http://shodan.warpedgames.com/~fuzzie/libfaad.txt is all i've changed to make it build |
| 19:19:51 | linuxstb | Which file does the ICE appear in? |
| 19:20:06 | fuzzie | sbr_dec.c:611: internal compiler error: in reload_cse_simplify_operands, at post reload.c:391 |
| 19:20:39 | | Join webguest92 [0] (n=45e5fb5d@labb.contactor.se) |
| 19:21:08 | linuxstb | Do you want me to try and compile it? |
| 19:21:48 | * | rasher builds a snapshot binutils |
| 19:22:06 | | Quit pike (Read error: 110 (Connection timed out)) |
| 19:22:58 | fuzzie | might be an idea. need to finish dinner/rl life stuff first, on the laptop right now |
| 19:25:47 | fuzzie | there isn't very much code of mine involved .. most of the actual work so far has been working out why the metadata of all my files failed [hence the read_uint32be fix] :/ |
| 19:26:09 | linuxstb | fuzzie: Thanks for that. |
| 19:26:23 | rasher | Yeah, wasn't my fix |
| 19:26:24 | linuxstb | I obviously never tested that function. |
| 19:26:57 | fuzzie | rasher: well, you wrote it.. |
| 19:27:14 | rasher | Writing it was the easy part |
| 19:27:17 | linuxstb | fuzzie: Do you deal with ALAC files, or have you disabled ALAC? |
| 19:27:31 | fuzzie | at the moment, i just changed alac to .alac |
| 19:27:42 | linuxstb | Fair enough. |
| 19:28:19 | linuxstb | I only own one AAC file, so I guess I will do the opposite - until we fix it properly. |
| 19:29:42 | | Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
| 19:29:42 | | Quit paugh (Client Quit) |
| 19:29:51 | | Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
| 19:29:59 | fuzzie | it ought to be simple to add detection to probe_file_format in a very inefficient manner |
| 19:30:22 | linuxstb | probe_file_format isn't allowed to spin the disk up.... |
| 19:30:27 | fuzzie | ah |
| 19:30:33 | fuzzie | i was about to ask if that'd be possible. |
| 19:31:02 | amiconn | rasher: binutils version shouldn't have any effect on ICEs |
| 19:31:14 | * | amiconn received 3 nice CDs today :) |
| 19:31:19 | fuzzie | the disk has to be spun up to examine the files, so i'm not sure how to handle that [merge alac/faad codecs to do different things depending on filetype?] |
| 19:31:25 | fuzzie | oh, also, is increasing CODEC_SIZE a problem? |
| 19:31:30 | amiconn | Expect some shiny new voice files sonn :) |
| 19:31:32 | amiconn | *soon |
| 19:31:39 | fuzzie | because i'm pretty sure libfaad is going to exceed the limit. |
| 19:31:58 | fuzzie | it apparently works on iriver, but i don't know the possible consequences |
| 19:32:25 | linuxstb | I would say to increase it for now, and that is something to look at when we start optimising it. |
| 19:33:05 | | Quit muesli- (Read error: 110 (Connection timed out)) |
| 19:33:16 | amiconn | File type detection either has to be done at buffering time, i.e. as part of the metadata handling, |
| 19:33:23 | | Join |Lupin| [0] (n=Lupin@l03m-212-195-112-196.d2.club-internet.fr) |
| 19:33:37 | linuxstb | I think the real fix for the ".m4a" problem is to call get_metadata() at a different point in time - i.e. before the codec is loaded, at the same time as buffering the file. |
| 19:33:50 | |Lupin| | Hello, there. |
| 19:33:50 | amiconn | Otherwise all files with the same extension would need to be handled by one (multiformat) codec |
| 19:33:54 | linuxstb | get_metadata() can then set the codec type. |
| 19:34:09 | fuzzie | sounds reasonable, if it can be done |
| 19:34:19 | amiconn | I.e. a combined alac/aac codec for .m4a, a combined vorbis/speex codec for .ogg etc |
| 19:34:35 | rasher | vorbis/speex/flac |
| 19:34:35 | linuxstb | I don't see why not - but I don't know the playback.c code well enough. |
| 19:34:47 | amiconn | I think this would soon become unmaintainable, if not impossible |
| 19:34:56 | amiconn | rasher: Ah yes, forgot about flac |
| 19:35:03 | linuxstb | Combining codecs will cause headaches when trying to use IRAM efficiently. |
| 19:35:12 | amiconn | Funny thing would be a universal .wav codec... |
| 19:35:13 | linuxstb | preglow already wants to split the libmad codec |
| 19:35:23 | linuxstb | (I think) |
| 19:35:25 | amiconn | linuxstb: Yes I know |
| 19:35:44 | amiconn | That's why I'd prefer the first method (detection as part of the metadata handling) |
| 19:35:53 | fuzzie | i think that's the only realistic option |
| 19:36:00 | |Lupin| | I' sorry if this is the wrong place, but I'm wondering if someone here could suggest a good mp3 player / recorder for a blind person ? |
| 19:36:23 | t0mas | iriver H1x0 ? |
| 19:36:38 | linuxstb | Do you want a hard disk or flash based player? |
| 19:36:40 | | Join muesli- [0] (i=muesli_t@Bc0a6.b.pppool.de) |
| 19:37:19 | |Lupin| | linuxstb: Well, I have no idea of the consequences of such a choice... |
| 19:37:58 | |Lupin| | What I know is I'm looking for a very good quality recording, with a big capacity ifpossible. |
| 19:38:47 | linuxstb | If you want big capacity, then it will have to be a hard disk based player. They are larger and more fragile than flash players. |
| 19:39:18 | linuxstb | The iriver H1x0 is a good choice - if you installed Rockbox onto it. |
| 19:39:33 | | Join vorbisgain [0] (n=9353a9a1@usal.ssl-connection.com) |
| 19:39:35 | |Lupin| | ahah, I see. Thanks. What'sthemaximal capacity one can expect with a flash-based player ? |
| 19:40:05 | |Lupin| | linuxstb: and with rockbox it can speao, right ? |
| 19:40:07 | vorbisgain | hello all, is here some vorbis developer or someone in charge of the project? |
| 19:40:24 | linuxstb | Typically no more than 1GB or 2GB. But flash players are getting larger every week. |
| 19:40:56 | amiconn | ...and some flash players are extendable with memory cards |
| 19:41:26 | linuxstb | But price per gigabyte is much cheaper for hard disks. |
| 19:42:01 | |Lupin| | ok, thanks. |
| 19:42:23 | vorbisgain | two questions: first, how can I contact the rockbox staff? anyone knows? |
| 19:42:25 | linuxstb | And yes, the iriver H1x0 can speak when using Rockbox. But Rockbox is still in beta status for the iriver. |
| 19:42:52 | vorbisgain | second question: H340 doesn't understand replayagain tags, do you know a way to apply the gain to the data? |
| 19:42:52 | rasher | vorbisgain: What do you want? There's no "rockbox staff" as such |
| 19:43:16 | linuxstb | All the rockbox developers read the IRC logs, and some are around at the moment. |
| 19:43:24 | vorbisgain | rasher: I know there is no "staff" but well, I could perhaps offer help some way |
| 19:43:49 | vorbisgain | I have seen there is dire need of electronics for decoding hardware |
| 19:44:01 | vorbisgain | sorry, electronic engineers |
| 19:44:02 | vorbisgain | :) |
| 19:44:09 | |Lupin| | What's about the iRiver H340-SE ? Is itsupported by rockbox ? |
| 19:44:23 | amiconn | Not yet |
| 19:44:25 | vorbisgain | no, H340 is not supported |
| 19:44:36 | rasher | |Lupin|: Not right now, but it is planned. It will probably happen faster than the h1x0 port |
| 19:44:36 | vorbisgain | well, I am teacher in a polytecnic school |
| 19:44:52 | Moos | ohh :) |
| 19:44:54 | vorbisgain | I could have students do their projects on something |
| 19:45:05 | vorbisgain | they are electronics students |
| 19:45:16 | vorbisgain | and they MUST do a final project |
| 19:45:23 | vorbisgain | why not for rockbox :) |
| 19:45:32 | Moos | hehe |
| 19:45:42 | | Quit webguest92 ("CGI:IRC") |
| 19:45:42 | linuxstb | They could disassemble MP3 players and draw schemetics and locate documentation for the chips.... |
| 19:46:03 | linuxstb | ... and then port rockbox. |
| 19:46:07 | vorbisgain | yes, that's the problem, dissasembling means necessarily destroying them? :) |
| 19:46:25 | vorbisgain | it means money thrown to the trash |
| 19:46:27 | vorbisgain | :( |
| 19:46:59 | linuxstb | You could say it is money invested... |
| 19:47:03 | vorbisgain | ha ha |
| 19:47:22 | vorbisgain | well, I should check which student wants to "invest" :) |
| 19:47:55 | vorbisgain | up to my knowledge, rockbox is for players with a screen, isn't it? |
| 19:48:07 | vorbisgain | I mean, kind of H340 or iaudio X5 |
| 19:48:10 | linuxstb | It doesn't have to be - it has a voice UI. |
| 19:48:13 | |Lupin| | so is there one product in the iRiver series for which the support is "stable", with Hard-Drive, good microphone ? |
| 19:48:25 | linuxstb | But all targets so far have had a screen. |
| 19:48:39 | vorbisgain | a voice UI??? you can talk to rockbox? |
| 19:48:48 | Maxime` | no, but rockbox talk to you |
| 19:48:49 | rasher | vorbisgain: voice output |
| 19:48:53 | vorbisgain | ahhhhhhh |
| 19:49:06 | vorbisgain | well, my H340 has a microphone, it could be! |
| 19:49:07 | Moos | Lupin: h1xx |
| 19:50:05 | vorbisgain | dissasembling one 128M flash player is one thing (around 30euro) but a H340 is arond 400 euro, its another thing ;) |
| 19:50:24 | Moos | indeed |
| 19:50:28 | |Lupin| | It seems the only one proposed onthe website I am is the H10. If this is OK, that could be great. |
| 19:50:43 | Moos | no |
| 19:50:55 | tvelocity | why not port rockbox on the nintendo DS? :PPPpPPppp |
| 19:51:00 | Maxime` | or PSP |
| 19:51:01 | Maxime` | ^^ |
| 19:51:06 | vorbisgain | well, another question please |
| 19:51:14 | Moos | Lupin: mp in french |
| 19:51:19 | vorbisgain | I am now involved in converting flac files into vorbis for my H340 |
| 19:51:29 | tvelocity | PSP doesnt have a mic or a touch screen |
| 19:51:32 | vorbisgain | but H340 doesn't understand replayagain tags |
| 19:51:32 | tvelocity | :P |
| 19:51:51 | vorbisgain | do you know how can I appy gain to the files in linux? |
| 19:51:57 | |Lupin| | Moos: mp ? |
| 19:52:03 | rasher | I don't think there's a way to do that easily with vorbis |
| 19:52:09 | linuxstb | I know that metaflac can do it for the FLAC files. |
| 19:52:14 | Moos | Lupin: private msg |
| 19:52:31 | vorbisgain | in linux there are several tools: metaflac inserts replaygain tags |
| 19:52:44 | vorbisgain | there is a normalize tool which has a gain parameter |
| 19:52:57 | vorbisgain | and a normalize-ogg counterpart |
| 19:53:03 | vorbisgain | or a normalize for wav |
| 19:53:30 | vorbisgain | I tried normalize using the gain, and I obtained a less audible file :( |
| 19:57:59 | linuxstb | Have you read the description of the algorithm at replaygain.org? |
| 20:00 |
| 20:01:54 | vorbisgain | not the algorigthm why? |
| 20:04:28 | | Quit muesli- (Read error: 110 (Connection timed out)) |
| 20:04:53 | vorbisgain | I think I made it well, I first calculated the gains with vorbisgain, and then I applied the gain with normalize. |
| 20:05:12 | vorbisgain | I am now calculating the replaygain again, and it is near zero in album mode |
| 20:06:38 | vorbisgain | well, I think I made it, thanks anyway |
| 20:06:43 | | Part vorbisgain |
| 20:14:38 | | Quit paugh (Read error: 110 (Connection timed out)) |
| 20:15:51 | | Join XavierGr [0] (n=XavierGr@ppp41-adsl-111.ath.forthnet.gr) |
| 20:16:07 | *** | Saving seen data "./dancer.seen" |
| 20:22:13 | | Join linuxstb__ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
| 20:22:28 | | Join tucoz [0] (n=81b17b04@labb.contactor.se) |
| 20:22:55 | tucoz | Hi, how do I enable a debug build for the simulator? |
| 20:23:19 | rasher | Press S at the first question |
| 20:23:22 | rasher | or second |
| 20:23:24 | rasher | eh |
| 20:23:25 | rasher | d |
| 20:23:27 | tucoz | ok |
| 20:23:35 | tucoz | type of build |
| 20:23:39 | rasher | Developer |
| 20:23:40 | tucoz | thanks |
| 20:23:59 | tucoz | and it is logf to send stuff to that? |
| 20:24:23 | rasher | DEBUGF |
| 20:24:35 | rasher | logf works in logf builds |
| 20:24:45 | rasher | not sure what that does on sim though |
| 20:25:01 | tucoz | hmm, I think I have to take a look at an example |
| 20:26:31 | amiconn | Iirc, simulators are always debug builds, |
| 20:26:39 | amiconn | so DEBUGF() should work |
| 20:27:06 | tucoz | debugf("output") or DEBUGF("output") |
| 20:27:27 | tucoz | I have seen both by searching google for debugf site:rockbox.org |
| 20:28:24 | Lear | logf puts stuff in a buffer that can be viewed/saved from the debug menu. |
| 20:28:44 | Lear | also displayed on the remote, if the target has one (on the simulator too). |
| 20:29:10 | tucoz | ok |
| 20:29:25 | amiconn | DEBUGF() prints to the console (simulator) |
| 20:29:35 | XavierGr | Unfortunately the simulator is way too buggy. |
| 20:29:45 | tucoz | ok, great. Do I need to include debug.h for that? |
| 20:29:49 | XavierGr | Sometimes it crashes while on the real target it works |
| 20:30:05 | XavierGr | At least the windows version |
| 20:31:07 | rasher | There's no debug menu in the sim |
| 20:31:14 | rasher | that I can find |
| 20:31:31 | amiconn | yep |
| 20:31:54 | rasher | there is however a logf dump menu |
| 20:31:55 | Lear | it's directly on the info menu on the simulator. |
| 20:32:08 | Lear | provided you have a logf build... |
| 20:32:47 | tucoz | ok, when choosing a (D)ebug build in the config. Do I choose (D) or (S) then for DEBUGF output to show? |
| 20:32:55 | Lear | S |
| 20:32:56 | tucoz | in the next step |
| 20:32:58 | | Join yosemite [0] (i=sam@threepwood.dasbistro.com) |
| 20:32:59 | tucoz | ok, thanks Lear |
| 20:33:05 | Lear | For a simulator. |
| 20:33:10 | linuxstb__ | Lear: Do you have a rockbox.zip built with gcc4 that you can put somewhere for testing? |
| 20:33:11 | amiconn | rasher: There is no debug menu in the sim because all its entries don't make sense for the sim |
| 20:33:14 | Lear | For debug on target, you must have serial out... |
| 20:33:14 | | Quit linuxstb ("CGI:IRC (Ping timeout)") |
| 20:33:21 | amiconn | ...erm, for the archos sim |
| 20:33:26 | yosemite | hi, I just installed rockbox on my iriver this morning, and it now seems to have locked up hard |
| 20:33:31 | amiconn | Perhaps we should add it for iriver |
| 20:33:44 | tucoz | yosemite: what is wrong? |
| 20:33:49 | yosemite | pressing reset or play seems to have no effect |
| 20:34:09 | yosemite | it says I00: at 40d82000 |
| 20:34:17 | tucoz | try holding play for a while |
| 20:34:27 | yosemite | I believe it said illegal instruction before that |
| 20:34:38 | yosemite | ok holding |
| 20:34:55 | yosemite | how long should I hold it |
| 20:35:37 | tucoz | Until it shuts down |
| 20:35:50 | yosemite | well, it hasn't yet |
| 20:36:20 | rasher | yosemite: pressing reset will always reset |
| 20:36:22 | tucoz | like 10 seconds. if that doesnt work, insert a paperclip on the bottom |
| 20:36:28 | | Join solexx_ [0] (n=jrschulz@d164064.adsl.hansenet.de) |
| 20:36:28 | rasher | yosemite: Are you perhaps not hitting it right? |
| 20:36:28 | amiconn | 40d82000? hmm.... |
| 20:36:41 | yosemite | rasher: troll |
| 20:36:45 | rasher | yosemite: it's perfectly possible to miss the actual button inside the hole |
| 20:36:50 | rasher | yosemite: no, really! |
| 20:36:53 | tucoz | in the small hole next to the usb connector |
| 20:37:00 | yosemite | both of those don't appear to be working right |
| 20:37:08 | Lear | linuxstb__: I have a build... |
| 20:37:09 | yosemite | I'll try the reset again |
| 20:37:14 | yosemite | maybe I don't have it lined up |
| 20:37:14 | tucoz | the reset is a hardware reset |
| 20:37:32 | rasher | yosemite: use a paper-clip or something.. you'll most likely miss if using a needle or similar |
| 20:37:55 | | Quit linuxstb_ (Read error: 110 (Connection timed out)) |
| 20:37:57 | yosemite | ok, I'm using a mechanical pencil |
| 20:38:01 | yosemite | I'll find something bigger |
| 20:38:16 | rasher | Nice design choice of iriver, this. |
| 20:38:25 | | Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
| 20:38:30 | amiconn | rasher: oh yes |
| 20:38:32 | rasher | why not just have the button be *larger* than the hole, I ask |
| 20:38:42 | amiconn | I much prefer the archos method here |
| 20:38:42 | | Part tucoz |
| 20:38:59 | amiconn | (having a hardware poweroff with a long timeout) |
| 20:39:20 | rasher | Well, if they had just used a real button instead of this dinky thing |
| 20:39:31 | amiconn | No need for an extra button, just hold OFF for 10 seconds and it will power off regardless what the software is doing |
| 20:41:30 | Slasheri | Now the directory caching patch is available for a review: http://ihme.org/~miipekk/rockbox/dircache.diff |
| 20:42:11 | rasher | and me without a clean sourcetree |
| 20:42:19 | ghode|afk | any chance of a build as well? :) |
| 20:42:33 | fuzzie | rasher: it works apart from the linking? |
| 20:42:45 | rasher | fuzzie: Hm? |
| 20:43:23 | fuzzie | your tree |
| 20:43:52 | rasher | well it gets as far as the error I showed you |
| 20:44:10 | yosemite | finally |
| 20:44:24 | rasher | yosemite: See! |
| 20:44:26 | yosemite | I got it jammed in there just right apparently |
| 20:44:30 | yosemite | hmm |
| 20:44:39 | rasher | Of course, the crash is curious |
| 20:44:42 | yosemite | it booted to iriver firmware |
| 20:44:54 | rasher | It does that if it thinks something went wrong |
| 20:44:54 | yosemite | I think it was trying to crossfade an mp3 |
| 20:45:19 | yosemite | can I just reboot back into rockbox then? |
| 20:45:24 | rasher | Well that certainly works. Must be more involved than that |
| 20:45:28 | rasher | Yeah |
| 20:45:39 | yosemite | rockon |
| 20:45:41 | yosemite | thanks |
| 20:46:30 | rasher | Could be caused by the next file in the playlist being problematic |
| 20:46:42 | yosemite | yeah that was my guess |
| 20:46:48 | yosemite | I have it shuffling all files |
| 20:46:58 | yosemite | and I know some of my files are a bit damaged |
| 20:47:16 | rasher | With a bit of luck you should be able to resume the same playlist |
| 20:47:21 | rasher | and find out which is the next song |
| 20:47:24 | XavierGr | Slasheri: dircache? Sounds sweet when are we going to see this comitted? |
| 20:48:22 | | Quit solexx (Read error: 110 (Connection timed out)) |
| 20:50:56 | | Quit linuxstb__ (Read error: 110 (Connection timed out)) |
| 20:51:30 | Slasheri | XavierGr: i hope this week :) |
| 20:51:43 | Slasheri | unless somebody finds some bugs from the code |
| 20:53:19 | | Quit Maxime` (Read error: 104 (Connection reset by peer)) |
| 20:53:23 | | Join Maxime` [0] (n=flemmard@82.229.205.156) |
| 20:53:36 | | Join tucoz [0] (n=81b17b04@labb.contactor.se) |
| 20:54:17 | tucoz | Slasheri: how does it work? I select cache, it tells me to reboot, but when I check the menu after a reboot it says cache -> no |
| 20:54:54 | XavierGr | Slasheri: Sweet. Always you suprise us pleasantly. |
| 20:55:10 | Slasheri | tucoz: weird. Don't shutdown the player before you have completely exited the menus |
| 20:55:32 | Slasheri | rockbox may not save the settings if you are browsing the menu same time you shutdown the unit |
| 20:55:36 | Slasheri | XavierGr :) |
| 20:56:03 | tucoz | ok, now it's caching |
| 20:56:12 | Slasheri | tucoz: and the first boot with cache enabled will be slow but future boots are fast |
| 20:56:24 | tucoz | it took only like 3 seconds extra |
| 20:56:35 | Slasheri | hehe, nice |
| 20:56:47 | tucoz | have to wait for the disk to spin down now |
| 20:57:31 | tucoz | hehe, this is cool |
| 20:57:49 | preglow | Lear: took the cowards way out in synth_full did you? ;) |
| 20:58:18 | Lear | Yeah, didn't feel like rewriting it all to assembler, which would be one option... |
| 20:59:16 | Lear | Or do you have a better option? :) |
| 20:59:22 | tucoz | Slasheri: seems to be working great. One issue though. It tells me Boot changed, reboot now when I move out of a folder |
| 20:59:39 | XavierGr | So this patch will enable us to see a folder (say from exiting the WPS) without waiting for the disk to spin? |
| 20:59:58 | Slasheri | tucoz: oh, can you find a way to reproduce that? |
| 21:00 |
| 21:00:05 | Lear | tucoz: normal with a new build |
| 21:00:08 | tucoz | I'll try |
| 21:00:13 | tucoz | it's not a new buld |
| 21:00:14 | tucoz | build |
| 21:00:20 | Slasheri | good :) that will be definately fixed before the commit |
| 21:01:20 | XavierGr | God if this patch does what I am thinking it is "magnificent"! I was always annoyed by this little HD spin delay. |
| 21:01:40 | Slasheri | XavierGr: yes, it will remove completely the delay |
| 21:01:53 | linuxstb | Slasheri: What's the cost in terms of RAM to enable the cache? |
| 21:01:57 | tucoz | Slasheri:Ok, this is reproducable. I boot, enter some subdirectories and move back out to the root. It tells me that boot has changed |
| 21:02:02 | Slasheri | and it's much faster also |
| 21:02:24 | tucoz | Like, music->artist->album->disk1 and move back out |
| 21:02:25 | Slasheri | tucoz: interesting.. that doesn't happen on my player. But i will try to do some tests soon |
| 21:02:28 | preglow | Lear: no, no, that's the exact other option, the one i was hoping you'd take... |
| 21:02:43 | XavierGr | Sweet I am going to include this patch on my build ASAP. |
| 21:02:46 | Slasheri | linuxstb: depends on how many files you have. With quite full player it's around 400 kB |
| 21:02:48 | tucoz | I do not play anything. It is the first thing I do after a boot |
| 21:03:08 | linuxstb | How is the memory allocated then? I thought it would have to be a fixed size. |
| 21:04:38 | Slasheri | linuxstb: on first (slow) boot the required ram size is calculated + some reserve buffer for cache live updating. Future rebuilds use the previous cache size as fixed buffer and transparent cache rebuild is possible |
| 21:04:42 | tucoz | still very cool Slasheri. |
| 21:04:43 | Slasheri | back soon -> |
| 21:04:48 | Slasheri | :) |
| 21:05:32 | | Quit tucoz ("CGI:IRC 0.5.4 (2004/01/29)") |
| 21:05:43 | linuxstb | So the long delay first time you boot is to calculate the buffer size needed? |
| 21:07:05 | preglow | yes, and do some buffering, unless i'm mistaken |
| 21:07:08 | * | amiconn wonders what will happen if the reserved cache size is used up |
| 21:07:38 | * | linuxstb was wondering the same. |
| 21:07:48 | amiconn | Perhaps I should put this under stress test: a nice little plugin creatings thousands of files... |
| 21:08:31 | amiconn | I'm still not convinced at all that directory caching is a good idea |
| 21:10:10 | preglow | i'm not convinced it's the ultimate answer |
| 21:10:13 | preglow | but i know two things: |
| 21:10:27 | preglow | 2. the rest of the rockbox code wont end up more complex because of this |
| 21:10:37 | preglow | 1. lots of people, me included, will use this |
| 21:10:44 | preglow | excuse the reverse ordering |
| 21:10:56 | preglow | despite it not being perfect |
| 21:11:02 | amiconn | For one, it adds complexity |
| 21:11:31 | amiconn | Then it eats up RAM that would otherwise be used as audio file buffer |
| 21:11:47 | rasher | That's negligeble out of a 32mb buffer |
| 21:11:53 | rasher | or 30mb or whatever we end up with |
| 21:12:01 | | Quit linuxstb (Read error: 113 (No route to host)) |
| 21:12:20 | rasher | If the alternative is to keep the disk spun up the entire time, I'll sacrifice half a meg for that |
| 21:12:38 | | Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
| 21:13:08 | preglow | amiconn: it's an option, i hope |
| 21:13:25 | amiconn | Yes it is |
| 21:13:28 | preglow | amiconn: i'd happily sacrifice 400kb for my player |
| 21:13:31 | preglow | amiconn: i browse a lot |
| 21:13:34 | amiconn | The complexity stays, however |
| 21:13:59 | preglow | amiconn: how? slasheri says the rest of the code isn't touched much, and all the caching is in one file |
| 21:14:04 | amiconn | For me, it's one more option to disable immediately |
| 21:14:15 | amiconn | (like replaygain, ...) |
| 21:14:16 | preglow | amiconn: and for me it's not |
| 21:14:36 | XavierGr | yeah I agree with preglow. I think it is a great feature. |
| 21:15:09 | amiconn | I'm browsing for minutes (if at all), then playing for hours... |
| 21:15:39 | XavierGr | yes but doesn't this little dealy gets on your nerves every now and then? |
| 21:15:39 | rasher | So it's different uses. Is it hard to imagine that one of them might benefit from caching? |
| 21:15:53 | preglow | amiconn: i'm not |
| 21:15:57 | preglow | amiconn: i browse a lot |
| 21:16:00 | rasher | Or should we just use the player like you do? |
| 21:16:19 | XavierGr | I remember how thoughtfull I was to browse on the iriver firmware. |
| 21:16:37 | amiconn | rasher: certainly not |
| 21:16:42 | XavierGr | if you browse then the HD would spin up untill the buffer was reloaded again. |
| 21:17:06 | XavierGr | on the iriver firmware |
| 21:17:11 | rasher | Well, I don't see the last argument then. |
| 21:17:23 | rasher | About code-complexity, I know nothing. |
| 21:17:25 | linuxstb | Is the tag database cached in RAM? |
| 21:17:33 | amiconn | nop |
| 21:17:34 | amiconn | +e |
| 21:17:40 | XavierGr | is there a difilter for the fmr (presets files)? |
| 21:18:07 | amiconn | No, since they aren't supported for browsing |
| 21:18:39 | amiconn | But now I'll check out the newly installed voices :) |
| 21:18:50 | preglow | what new voices? |
| 21:19:12 | XavierGr | is there anyway to instruct the rockbox_browse function without the dirfilter argument? |
| 21:19:13 | amiconn | 3 shiny new at&t natural voices to generate voice files with :) |
| 21:21:07 | linuxstb | XavierGr: You mean with SHOW_ALL ? |
| 21:23:50 | XavierGr | well I mean to use a string filter for the time being. But as soon as the dirfilter argument is an integer I don't see how I can do this. |
| 21:24:22 | Slasheri | amiconn: when the reserve buffer size is consumed (i doubt this will rarely if ever happen), then the cache will be just disabled |
| 21:24:23 | XavierGr | only way is to use another SHOW_FMR filter, but I don't know how many devs will like this. |
| 21:24:44 | amiconn | Slasheri: And what will happen at the next boot then? |
| 21:24:56 | Slasheri | amiconn: a full (slow) cache rebuild |
| 21:25:56 | linuxstb | XavierGr: I don't see a problem with that. |
| 21:26:37 | amiconn | Slasheri: What will happen if the reserved cache buffer size is *almost* used up, and then the box is rebooted? |
| 21:27:25 | amiconn | Will it reserved the same amount of RAM as before, or will it adjust the size on every boot so that the reserved size is large enough? |
| 21:28:32 | |Lupin| | Sorry to interrupt, guys, but just one additional question: |
| 21:29:10 | |Lupin| | I'm about to order an iRiver H140. Once Rockbox will be installed on it, will I really be able to record voice thanks to the internal microphone ? |
| 21:29:18 | |Lupin| | And which quality of sound can I expect ? |
| 21:32:44 | Slasheri | amiconn: iirc the size allocated at next bootup will be the last cache size + reserve size |
| 21:32:53 | XavierGr | yes. record is on its infancy in rockbox but you can make voice recordings. |
| 21:33:04 | Slasheri | so there should be always free space after boot up |
| 21:33:17 | amiconn | Slasheri: Is the reserved size a constant amount of entries, or a percentage of what is already there? |
| 21:33:18 | rasher | Sounds sane |
| 21:33:45 | Slasheri | amiconn: currently it's just constant (64 KiB) |
| 21:34:21 | amiconn | How many entries is that? |
| 21:36:05 | |Lupin| | XavierGr: What do you mean by "on its infancy" ? |
| 21:36:30 | XavierGr | well on the iriver recording is not fully enabled. |
| 21:36:50 | XavierGr | you can record in wav with limited options |
| 21:36:54 | |Lupin| | XavierGr: What is missing, precisely, please ? |
| 21:37:00 | XavierGr | also you can record from the radio |
| 21:37:16 | rasher | |Lupin|: currently it only records to wav |
| 21:37:24 | Moos | Lupin: you can use the original fw for this in waiting rockbox |
| 21:37:27 | XavierGr | On archos models you can do pretty much everything. |
| 21:38:04 | XavierGr | Prerecording, timesplit and size split, quality, mp3 encoding, triggered recording e.t.c |
| 21:38:49 | |Lupin| | hmm |
| 21:39:04 | |Lupin| | Then I wonder if I really should buy an iRiver |
| 21:39:08 | |Lupin| | Since I'm blind |
| 21:39:22 | |Lupin| | I guess the original firmware might not b very useful. |
| 21:39:24 | XavierGr | Rockbox is perfect for blind users/ |
| 21:39:34 | |Lupin| | Actually I thought rockbox woul do it... |
| 21:39:47 | XavierGr | but it is a matter of time since all these will be implemented. |
| 21:39:48 | amiconn | XavierGr: Yes, but not the recording feature on iriver (yet) |
| 21:40:01 | amiconn | It's a matter of time, definitely |
| 21:40:03 | |Lupin| | XavierGr: I'm a blind user planning to use the mp3 reader mainly as a _recorder_ ... |
| 21:40:03 | rasher | |Lupin|: recording will be possible through the same interface as on the "old" archos models. But lossy encoding will probably take a while |
| 21:40:23 | Slasheri | amiconn: that depends on the filename length but it's for sure hundreds of entries |
| 21:40:23 | fuzzie | didn't someone get shine working for encoding? |
| 21:40:50 | Slasheri | night, cu -> |
| 21:40:52 | amiconn | Slasheri: A cache entry isn't constant size? |
| 21:41:01 | Slasheri | amiconn: no |
| 21:41:13 | Slasheri | amiconn: only that much space is used as necessary |
| 21:41:41 | Slasheri | the cache is basically a linked list (take a look at the code) |
| 21:41:42 | |Lupin| | So what do you guys recommend to me, inthe end ? |
| 21:41:50 | |Lupin| | (regardingThe model I should buy...) ? |
| 21:42:16 | XavierGr | I don't know but do you have any alternatives? |
| 21:42:33 | |Lupin| | XavierGr: They are limited in France. |
| 21:42:41 | XavierGr | are there any other fullfledged blind userfriendly mp3 players? |
| 21:42:52 | |Lupin| | XavierGr: But I'd rather look first at which model would be the best, and then find a placeto buy it... |
| 21:43:14 | * | amiconn found a menu option that isn't voiced :( |
| 21:43:16 | |Lupin| | XavierGr: This is precisely what I don't know... |
| 21:43:47 | |Lupin| | btw guys: I'm myself a programmer. So if I can help with improving voicesupport, I'll do so with pleasure. |
| 21:43:51 | XavierGr | amiconn do you know of mp3 players that support blind interface other than Rockbox ones? |
| 21:44:07 | amiconn | No I don't but then I'm no expert on that |
| 21:44:42 | |Lupin| | sure... |
| 21:44:50 | amiconn | I only know that rockbox is blind user friendly, and that it runs on a number of mp3 players which unfortunately aren't made anymore |
| 21:44:52 | XavierGr | I don't know either, so I think Lupin that still an iHP-100 (H-100) is your best chance |
| 21:44:59 | amiconn | eBay is an option to get one |
| 21:45:18 | rasher | |Lupin|: for Rockbox, I'd say get an iriver h1x0 and wait for the kinks to be worked out. The problem is that these players aren't produced anymore. None of the players rockbox supports are. Unfortunately. |
| 21:45:22 | XavierGr | I think Jeff on Misticriver.net has one for sale. |
| 21:45:28 | amiconn | Rockbox on archos is more mature, but iriver support is catching up |
| 21:46:21 | | Join muesli- [0] (i=muesli_t@Bc0ae.b.pppool.de) |
| 21:46:53 | amiconn | The archos recorders record directly to mp3 format, but otoh they don't support other formats than mp3 and mp2, the latter for playback only |
| 21:47:18 | amiconn | That might change in the future, I hope to get wav support running |
| 21:47:46 | amiconn | The iriver can play a whole bunch of different formats, but recording is only possible to wav format atm |
| 21:48:06 | rasher | |Lupin|: what are you planning to record? |
| 21:48:06 | amiconn | (and not in a blind friendly way, since it's still experimental) |
| 21:49:37 | |Lupin| | well |
| 21:49:42 | |Lupin| | it's to record courses |
| 21:49:44 | |Lupin| | conferences... |
| 21:49:56 | |Lupin| | yoga sessions, for instance |
| 21:50:54 | rasher | I'm guessing the shine mp3 encoder will be perfectly fine for that |
| 21:51:08 | |Lupin| | what's that please ? |
| 21:51:29 | XavierGr | this can be done currently, in wav format though and in a not so blind friendly way. |
| 21:51:58 | |Lupin| | Well, perhaps I can contribute in making this more blind-friendly ? |
| 21:52:00 | rasher | |Lupin|: Well, I was mostly talking to myself, it's the mp3 encoder software that is probably going to be used in Rockbox. It's not the best quality encoder, but for such things it'll be fine I guess |
| 21:52:37 | |Lupin| | well the encoding can certainly be done on a laptop, usinglame, say, no ? |
| 21:52:38 | Lear | preglow: almost sounds like you had tried to compile with gcc4... :) |
| 21:53:21 | rasher | |Lupin|: if recording to lossless and then using lame is fine, I see no reason why you shouldn't buy a used iriver-h1x0 |
| 21:53:35 | rasher | |Lupin|: It's just not quite ready now, but will be in the not so distant future |
| 21:54:28 | rasher | I'm starting to think that recording to high-quality mp3 might be a problem |
| 21:54:36 | |Lupin| | rasher: Ok, so let's follow this path and I'll make my bestt contribute. |
| 21:54:44 | |Lupin| | That's an exciting task... |
| 21:58:46 | yosemite | rasher: an mp3 locked it up this time, less hard than last time though |
| 21:59:04 | rasher | yosemite: is it repeatable? |
| 21:59:20 | yosemite | I'll find out in a second |
| 22:00 |
| 22:00:13 | yosemite | yep |
| 22:00:18 | yosemite | did it again |
| 22:00:59 | rasher | anything special about it? weird tags? other strangeness? |
| 22:01:01 | XavierGr | ok strange behaviour here. I call rockbox_browse to certain folder. All is fine excpet that I can't exit the browser. I call it exactly the way setting menus do and there you can exit with the left button. |
| 22:01:11 | yosemite | dunno |
| 22:01:35 | yosemite | there might be a tagging issue, I think I got the file from the interweb |
| 22:01:37 | rasher | I guess you need to get it to someone who knows stuff |
| 22:01:49 | rasher | yosemite: id3v2 -l on it? |
| 22:02:17 | rasher | I guess it could be broken in a multitude of ways |
| 22:02:23 | yosemite | hmm, no wait this was an ogg that I ripped |
| 22:02:24 | yosemite | odd |
| 22:02:39 | rasher | Slasheri: Dir cache feels great |
| 22:02:43 | yosemite | just trying to play it doesn't work either |
| 22:03:05 | rasher | Sounds terminally broken |
| 22:03:13 | Lear | yosemite: chained ogg? |
| 22:03:23 | yosemite | I dunno |
| 22:03:31 | yosemite | is there an easy way to find out? |
| 22:03:33 | rasher | ogginfo |
| 22:03:45 | Lear | wait, if you ripped it, you ought to know. :) |
| 22:04:58 | yosemite | Lear: it was a long time ago |
| 22:05:08 | | Join Bagder [0] (n=daniel@1-1-5-26a.hud.sth.bostream.se) |
| 22:05:43 | yosemite | User comments section follows... |
| 22:05:44 | yosemite | title=Korn Ring Finger |
| 22:05:44 | yosemite | artist=Captain Beefheart and His Magic Band |
| 22:05:44 | DBUG | Enqueued KICK yosemite |
| 22:05:44 | yosemite | album=Safe as Milk |
| 22:05:44 | yosemite | REPLAYGAIN_TRACK_PEAK=1.01288915 |
| 22:05:46 | yosemite | REPLAYGAIN_TRACK_GAIN=-2.53 dB |
| 22:05:47 | Lear | for it to be chained, you need to concatenate two or more oggs... |
| 22:05:55 | yosemite | there's only one stream |
| 22:05:59 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
| 22:06:04 | rasher | That looks peachy |
| 22:06:11 | rasher | Is replaygain turned on? |
| 22:06:41 | yosemite | ah I thought that was unimplemented looking at the wiki |
| 22:06:49 | rasher | And if yes, does it lock up if you turn it off |
| 22:07:11 | rasher | Where was that? (needs to be corrected) |
| 22:07:13 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 22:07:13 | * | Lear uses replaygain on oggs all the time... |
| 22:07:30 | rasher | Lear: Yeah, me too.. it was all I could think of |
| 22:08:15 | yosemite | I don't remember where I saw it now |
| 22:08:20 | yosemite | no replaygain was off |
| 22:08:34 | Lear | Well, with a copy of the file, there's at least the chance of it getting fixed... |
| 22:09:12 | Lear | If it is a problem in rockbox, and not in the file. :) |
| 22:09:26 | rasher | Rockbox shouldn't crash |
| 22:09:32 | rasher | Unless it was simply a "codec failure" |
| 22:09:38 | rasher | That's acceptable on broken files. |
| 22:09:44 | rasher | Can't do much better. |
| 22:09:51 | yosemite | you'd think it'd just skip it then right |
| 22:10:15 | rasher | How did it crash? |
| 22:10:18 | yosemite | yeah still not good |
| 22:10:31 | yosemite | well now it has the drive light on hard and nothing is happening |
| 22:10:36 | yosemite | nothing responds |
| 22:10:38 | rasher | Ah, well that's broken |
| 22:10:45 | yosemite | now, it might not be rockbox |
| 22:10:46 | rasher | I don't know who you should send it to |
| 22:10:51 | yosemite | this is an abused iriver |
| 22:10:52 | Maxime` | yosemite is your played fully chaged? |
| 22:11:02 | rasher | Ah, hm. |
| 22:11:17 | Lear | you can send the file to me... |
| 22:11:18 | yosemite | it's at 3/4 according to the little graphics bar |
| 22:11:27 | yosemite | I'm going to try something first |
| 22:11:33 | yosemite | I have a theory |
| 22:11:47 | yosemite | that this may just be my disk brokeness |
| 22:16:08 | *** | Saving seen data "./dancer.seen" |
| 22:17:26 | yosemite | hmm the iriver firmware seems to handle the file fine |
| 22:22:54 | yosemite | what is the format of the .playlist_control file? |
| 22:23:43 | yosemite | nm looks like I'm safe just nuking it |
| 22:25:39 | | Quit Moos ("Glory to Rockbox") |
| 22:30:19 | yosemite | yeah it's the file's fault |
| 22:31:53 | yosemite | Lear: http://dasbistro.com/~sam/broken-beefheart.ogg <−− here's what breaks it |
| 22:32:21 | Lear | Thanks, I'll give it a go. |
| 22:33:54 | | Quit thegeek (Read error: 104 (Connection reset by peer)) |
| 22:36:27 | | Join thegeek [0] (n=thegeek@s057b.studby.ntnu.no) |
| 22:41:47 | | Join thegeek_ [0] (n=thegeek@s057b.studby.ntnu.no) |
| 22:41:47 | | Quit thegeek (Read error: 104 (Connection reset by peer)) |
| 22:41:48 | | Quit thegeek_ (Read error: 104 (Connection reset by peer)) |
| 22:43:46 | | Quit matsl (Remote closed the connection) |
| 22:45:35 | | Quit |Lupin| ("'dnight, all") |
| 22:47:08 | Lear | Crashes the simulator at least... |
| 22:47:15 | amiconn | Wth.... |
| 22:48:40 | amiconn | Ah, no heck, just some missing voice: entries in deutsch.lang |
| 22:49:10 | | Quit muesli- (Read error: 110 (Connection timed out)) |
| 22:50:29 | Lear | Hm.. Any easy way to map a backtrace address to an address in rockbox.map for the simulator? |
| 22:51:17 | Lear | Hm... Wait, looks like that address is allocated; some addresses do match... |
| 23:00 |
| 23:00:10 | linuxstb | Lear: I think that Ogg file crashes somewhere in the Codec. get_metadata() parses the file OK. |
| 23:00:42 | Lear | Indeed. Codec setup is okay, it's in tremor, invalid access (0) in simulator... |
| 23:01:02 | Lear | And yes, simulator runs out of memory. |
| 23:01:26 | rasher | The vorbis codec doesn't work in sim (too big) |
| 23:01:30 | rasher | afaik |
| 23:01:41 | Lear | works quite well, thank you very much... :) |
| 23:01:51 | rasher | Oh.. crashed for me yesterday |
| 23:02:06 | * | Lear listens to 48 khz ogg in simulator... |
| 23:02:22 | XavierGr | hmm just created a fmr filetype is that ok? |
| 23:02:51 | XavierGr | now I must write the actual code that will initialize the radio and load the presets from the file... |
| 23:03:15 | Lear | This file is a little unusual (I think), in that it uses floor0.c... |
| 23:04:03 | rasher | old encoder? |
| 23:05:10 | rasher | We open the real file 'archos/.rockbox/codecs/vorbis.codec' |
| 23:05:10 | rasher | Segmentation fault |
| 23:05:22 | rasher | That's what happens when I try to play anything vorbis |
| 23:05:57 | Lear | Could be... Looks like the problem I see here. Tried the same file on target? |
| 23:06:11 | rasher | I don't have the file |
| 23:06:14 | rasher | this is a random vorbis file |
| 23:06:23 | Lear | that's the file I was refering to... |
| 23:06:41 | rasher | Now I'm confused. |
| 23:06:59 | fuzzie | all my vorbis files die in the simulator |
| 23:07:05 | fuzzie | but, i have no real hardware to test them on |
| 23:07:17 | fuzzie | it gets further if you increase CODEC_SIZE [because the simulator vorbis.codec exceeds the default] |
| 23:07:17 | rasher | this file _works_ on target, but not in the sim |
| 23:07:21 | fuzzie | but, still dies |
| 23:07:46 | rasher | I wonder how Lear is listenint to oggs in sim |
| 23:07:57 | Lear | Ouch, that file allocates least 400 kB, if my (very) quick calculations are right... |
| 23:09:30 | * | amiconn wonders why there are separate settings for crossfade and crossfade duration |
| 23:09:57 | rasher | How else would it work? |
| 23:10:00 | amiconn | Imho this could be simplified by having a crossfade duration of zero |
| 23:10:02 | elinenbe | hello. |
| 23:10:06 | elinenbe | quick question... |
| 23:10:12 | rasher | There are two crossfade types |
| 23:10:37 | elinenbe | does anyone here know who is responsible for this? |
| 23:10:38 | elinenbe | http://www.engadget.com/entry/1234000270060722/ |
| 23:10:50 | elinenbe | it looks good. |
| 23:10:58 | | Join Paul_The_Nerd [0] (n=paulthen@cpe-66-68-93-2.austin.res.rr.com) |
| 23:11:09 | amiconn | rasher: Ah ok. Didn't think of it as I never use crossfade... |
| 23:12:23 | rasher | One fades both in and out, the other only fades the new song in |
| 23:12:30 | rasher | and lets the current song play |
| 23:12:34 | rasher | iirc |
| 23:12:57 | Lear | Oh well, time to leave for me. Maybe "real" memory allocation functions could make this one work; need to know more about the allocs to tell... |
| 23:13:39 | elinenbe | rasher: any idea on that link? |
| 23:13:45 | rasher | Not at all |
| 23:15:20 | elinenbe | after watching the video it looks like it uses a buffer overrun error on the "get info" function for an unplayable mp3. |
| 23:15:48 | elinenbe | ... an mp3 that only has the code for the sms emulator |
| 23:16:32 | | Quit Lear ("Chatzilla 0.9.68.5.1 [Firefox 1.4/undefined]") |
| 23:17:51 | | Join muesli- [0] (i=muesli_t@pD9FCD8DE.dip0.t-ipconnect.de) |
| 23:17:59 | linuxstb | The alloca implementation seems broken for the sim - it allocates from the main memory buffer, not the stack. Or am I misunderstanding how alloca should work? |
| 23:20:33 | | Join webguest39 [0] (n=4045658a@labb.contactor.se) |
| 23:21:53 | XavierGr | hmm the patch utility of the rockbox devkit isn't working!!! |
| 23:22:11 | rasher | What's the problem? |
| 23:22:39 | XavierGr | patching file apps/filetree.c |
| 23:22:39 | XavierGr | Assertion failed: hunk, file ../patch-2.5.9-src/patch.c, line 340 |
| 23:22:39 | XavierGr | This application has requested the Runtime to terminate it in an unusual way. |
| 23:22:39 | DBUG | Enqueued KICK XavierGr |
| 23:22:39 | XavierGr | Please contact the application's support team for more information. |
| 23:22:53 | rasher | nice |
| 23:23:12 | | Quit gromit` (Read error: 104 (Connection reset by peer)) |
| 23:23:13 | XavierGr | and I got that same error with one of my patches so... |
| 23:23:33 | XavierGr | I tried other -p handlers too but then it asks for the files manually. |
| 23:24:01 | XavierGr | crap and I needed that dircache build. |
| 23:24:13 | rasher | I have one |
| 23:24:24 | | Quit webguest39 (Client Quit) |
| 23:24:25 | XavierGr | I was just going to ask you that :) |
| 23:24:25 | rasher | if you just want a clean dircache build? |
| 23:24:40 | XavierGr | yes please! |
| 23:25:27 | | Join gromit` [0] (n=gromit`@ras75-5-82-234-244-69.fbx.proxad.net) |
| 23:25:28 | rasher | http://rasher.dk/rockbox/rockbox-cache.zip |
| 23:25:55 | XavierGr | thanks rasher! :D |
| 23:29:00 | XavierGr | any option to enable it or it should work right away? |
| 23:29:28 | preglow | linuxstb: you're perfectly right |
| 23:29:33 | preglow | linuxstb: alloca allocates from the stack |
| 23:29:47 | preglow | linuxstb: freeing is automatic like that |
| 23:29:49 | XavierGr | nevermind foundit |
| 23:29:59 | preglow | linuxstb: i' |
| 23:30:18 | preglow | linuxstb: i've already noted that that is a bug, but i guess lear had a good reason for doing like it is |
| 23:30:44 | XavierGr | sweet!!! it is working! |
| 23:31:10 | XavierGr | Now I have to go... thanks rasher for the build and Slasheri for the implementation of it. |
| 23:31:12 | | Quit XavierGr () |
| 23:33:39 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 23:33:39 | * | rasher adds dircache to his list of patches |
| 23:35:11 | preglow | agreed |
| 23:35:14 | preglow | i think this is great |
| 23:35:28 | preglow | it's even frigging faster than the iriver cache |
| 23:36:03 | rasher | it boots relatively fast |
| 23:36:16 | rasher | Even when it has to rebuild, that is |
| 23:36:40 | preglow | hmmm |
| 23:36:50 | preglow | it just gave me a false positive for a rockbox.iriver change |
| 23:37:01 | rasher | Yeah, someone else had that |
| 23:37:03 | preglow | the background rebuild ran, then suddenly it asked if i wanted to reboot |
| 23:37:46 | amiconn | Talking about complexity.... |
| 23:38:01 | Paul_The_Nerd | How does dircache handle when you create a new file of any sort? |
| 23:38:08 | rasher | It updates the cache |
| 23:38:17 | rasher | At least, that's my understanding. |
| 23:38:22 | rasher | It just adds the file |
| 23:38:27 | Paul_The_Nerd | Gotcha |
| 23:38:46 | rasher | amiconn: most new code has bugs |
| 23:38:50 | Paul_The_Nerd | Also, did you ever resolve the "what happens when the cache gets close to full" question? Didn't see it in the log but I may have missed it. |
| 23:39:31 | amiconn | rasher: The thing is that it influences an area that isn't even touched by the new code, merely by doing something in the background that isn't expected |
| 23:40:41 | rasher | Paul_The_Nerd: I think the answer was that Slasheri was unsure, but pretty certain that the extra-buffer would be the same size (ie, total buffer would be larger) on next reboot |
| 23:41:13 | amiconn | Who messed up all the voice: lines in english.lang? :/ |
| 23:41:17 | preglow | i take it the cache routines consult the actual fat table when the cache isnt readily built? |
| 23:41:23 | preglow | i dont see how bugs can be triggered if this is the case |
| 23:42:10 | amiconn | Well, not all lines, but quite a number... |
| 23:42:48 | rasher | amiconn: Not me! |
| 23:43:01 | rasher | http://www.rockbox.org/viewcvs.cgi/apps/lang/english.lang?annotate=1.184 :-\ |
| 23:43:31 | rasher | oooh, the mp3 encoder as a plugin |
| 23:43:46 | preglow | where? |
| 23:43:54 | rasher | https://sourceforge.net/tracker/?func=detail&atid=439120&aid=1306244&group_id=44306 |
| 23:44:23 | amiconn | rasher: Okay, so I have to blame HCl, Lear and Slasheri |
| 23:44:42 | preglow | ahaha |
| 23:44:44 | preglow | in one file |
| 23:45:30 | rasher | heh |
| 23:45:42 | preglow | oh well, kudos to him, it's even emac optimised |
| 23:45:44 | rasher | I'm hurt that he suggests overwriting my plugin |
| 23:45:46 | preglow | in _integer_ mode, no less |
| 23:47:45 | * | rasher tries it out on iriver.wav |
| 23:47:53 | rasher | (yes, *that* one) |
| 23:48:35 | preglow | the only one |
| 23:48:40 | | Join thegeek [0] (n=thegeek@s057b.studby.ntnu.no) |
| 23:48:40 | * | ghode|afk likes the new dircache feature |
| 23:48:55 | preglow | yes, get rid of the rockbox.iriver false positive and i'm game |
| 23:49:38 | ghode|afk | do you have show all files on? |
| 23:51:51 | | Join tucoz [0] (n=50ca630c@labb.contactor.se) |
| 23:52:46 | preglow | yas |
| 23:53:30 | tucoz | I am doing something wrong. If I use fdprintf, what format should I use to get for instance 122.444:blablabla where 122 and 444 are separate integers |
| 23:54:03 | tucoz | that is integer dot integer ... |
| 23:54:35 | preglow | %d.%d ? |
| 23:54:44 | tucoz | No, I get an error then |
| 23:55:01 | tucoz | But I thought that it was that format |
| 23:55:29 | preglow | well, i think it is |
| 23:56:28 | | Quit tucoz (Client Quit) |
| 23:56:33 | | Join tucoz [0] (n=50ca630c@labb.contactor.se) |
| 23:56:55 | rasher | And again, tucoz' browser has an argument with the webclient |
| 23:57:04 | preglow | it's losing |
| 23:57:12 | preglow | badly |
| 23:57:30 | tucoz | I guess, but %d.%d:%s produces a compiler error (syntax error before ':' token) |
| 23:57:39 | preglow | _compiler_ error? |
| 23:57:53 | tucoz | yes |
| 23:57:56 | | Join arkascha [0] (n=arkascha@xdsl-213-168-119-63.netcologne.de) |
| 23:57:57 | rasher | Sounds like you have something else broken to me |
| 23:58:16 | tucoz | how? |
| 23:58:22 | preglow | gcc's been drinking again |
| 23:58:32 | preglow | let me see the actual line |
| 23:58:33 | tucoz | ah, I mean I have done something wrong. |
| 23:58:46 | tucoz | and the compiler tells me so :) |
| 23:58:53 | tucoz | recorder/radio.c:648: error: syntax error before ':' token |
icon identifies that the person is a core developer (has commit access).