| 00:00:23 | goa | webguest59: use bleeding edge builds? |
| 00:00:43 | webguest59 | Yes I use |
| 00:00:50 | rasher | It's a balance act. I'd go with releasing as-is, but it's amiconn's call. |
| 00:01:08 | webguest59 | but I think much to feature freeze :( |
| 00:01:21 | webguest59 | amiconn, have the release button? |
| 00:01:35 | webguest59 | the power :) |
| 00:01:54 | rasher | Well, right now it's the only bug being serioiusly worked on. I think the rest are going to be left. |
| 00:02:17 | Dan | wooooot |
| 00:02:21 | webguest59 | ok |
| 00:02:25 | Dan | h120 arrives tomorrow |
| 00:02:43 | webguest59 | but why don't release if all is good |
| 00:03:00 | rasher | Because it'd be nice to get this bug fixed first. |
| 00:03:12 | webguest59 | yes indeed |
| 00:03:37 | webguest59 | it will be fixed in the daily builds |
| 00:04:27 | webguest59 | and tell to user that there is 1 bug left, please wait the bug will be fixed in the daily builds or still one release |
| 00:04:47 | webguest59 | *new one |
| 00:05:26 | rasher | Yes. That is one solution. |
| 00:05:30 | rasher | Better would be to get it fixed. |
| 00:06:00 | webguest59 | yes but the time run fast |
| 00:06:10 | linuxstb_ | webguest59: Everyone is still hacking away at Rockbox - there will be a _lot_ of changes committed to Rockbox when the feature freeze is over. Development hasn't stopped. |
| 00:06:36 | webguest59 | in the rockbox. org Bagder's said release around 5 septembre :) |
| 00:06:52 | webguest59 | linuxstb: ok |
| 00:07:04 | Dma-Sc | bye! |
| 00:07:11 | webguest59 | ciao |
| 00:07:12 | Bagder | webguest59: that was the plan |
| 00:07:39 | webguest59 | plan have changed? |
| 00:07:55 | webguest59 | you can modify this message no |
| 00:08:02 | Bagder | the plan was to "attempt" to release it at sep 5 |
| 00:08:08 | | Quit Dma-Sc ("http://dma-sc.atari.org/") |
| 00:08:22 | webguest59 | optimistic way? |
| 00:09:14 | Bagder | not really |
| 00:09:27 | Bagder | just not many people involved in the bug fixing process |
| 00:09:37 | Bagder | and this recording bug being a lot meaner than expected |
| 00:09:38 | rasher | I'm curious if amiconn has any other ideas lined up. If not, I'm of the opinion that the release should go ahead. |
| 00:09:46 | Bagder | rasher: I am too |
| 00:09:52 | webguest59 | have you got one limit time, exemple, if the bug not fixed the X sept, october...? |
| 00:10:01 | webguest59 | release |
| 00:10:16 | rasher | webguest59: No. Time limits don't work well for stuff done on people's free time. |
| 00:11:18 | rasher | (as has been demostrated brilliantly) |
| 00:11:20 | webguest59 | yes indeed, I thought about administration way of rockox |
| 00:12:00 | webguest59 | I thanks everyone here again for all the free works done |
| 00:12:14 | webguest59 | I'm not complaining, just wondering |
| 00:12:27 | *** | Saving seen data "./dancer.seen" |
| 00:15:40 | webguest59 | rasher: for the WPS gallery wiki section, maybe you could add message in forums gallerys for the owner will can add them again to the wiki |
| 00:15:52 | webguest59 | *owners |
| 00:16:22 | rasher | I guess I should |
| 00:16:33 | webguest59 | very good effort you did everyone can thank you for this |
| 00:16:59 | webguest59 | assume a lot of hours at restored :( |
| 00:18:14 | Dan | you lot are gunna love helping me get rockbox setup tomorrow |
| 00:18:18 | Dan | cant wait |
| 00:18:20 | Dan | cya |
| 00:18:21 | Dan | LOL |
| 00:18:25 | | Quit Dan () |
| 00:22:26 | | Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
| 00:24:07 | webguest59 | bye all |
| 00:24:14 | rasher | bye |
| 00:24:25 | webguest59 | and I hope realese coming soon ;) |
| 00:24:30 | | Quit webguest59 ("CGI:IRC") |
| 00:37:58 | | Quit ender` (Read error: 113 (No route to host)) |
| 00:39:11 | rasher | Haha, good one Febs. (on the mailing list) |
| 00:43:36 | | Join thegeek_ [0] (n=thegeek@s057b.studby.ntnu.no) |
| 00:47:26 | | Quit thegeek (Read error: 113 (No route to host)) |
| 00:47:56 | | Join thegeek [0] (n=thegeek@s057b.studby.ntnu.no) |
| 00:48:43 | | Join ashridah [0] (i=ashridah@220-253-123-98.VIC.netspace.net.au) |
| 00:49:34 | | Quit Moos ("Parti") |
| 01:00 |
| 01:02:48 | preglow | about time as well |
| 01:03:31 | rasher | Long due |
| 01:05:46 | | Quit thegeek_ (Read error: 110 (Connection timed out)) |
| 01:06:12 | rasher | Interesting stuff, this Neuros talk |
| 01:06:31 | preglow | what/where? |
| 01:06:32 | Bagder | indeed |
| 01:06:50 | Bagder | preglow: in #haxx |
| 01:06:51 | rasher | #haxx, you missed by a few hours though.. still going on though |
| 01:07:09 | preglow | oh, right |
| 01:07:13 | preglow | didn't know it was today |
| 01:07:16 | rasher | There's preglow long-awaited ARM platform! |
| 01:07:19 | Bagder | log will be available |
| 01:07:38 | linuxstb_ | rasher: No, preglow's going to buy an ipod. |
| 01:08:03 | rasher | Yeah, mostly joking |
| 01:08:15 | fuzzie | mmm, rockbox on ipod. |
| 01:08:23 | linuxstb_ | rasher: Me too. |
| 01:09:04 | preglow | _200_ mhz arm9? |
| 01:09:10 | preglow | then what the flaming hell do they need the dsp for |
| 01:09:15 | Zagor | video |
| 01:10:05 | * | preglow starts on the ti toolset woes |
| 01:10:27 | Zagor | but basically the idea is to not use the DSP on the audio players |
| 01:10:54 | Bagder | they want the same CPU for several models |
| 01:11:01 | preglow | ahh, i see |
| 01:11:05 | preglow | oh well |
| 01:11:15 | preglow | adapting existing code for dsps is a nightmare anyway |
| 01:11:32 | | Join edx [0] (i=edx@p54A87B9F.dip.t-dialin.net) |
| 01:15:19 | DeepB | so... i've heard you had problems with TWiki, right? |
| 01:16:15 | rasher | We did, yeah |
| 01:16:27 | DeepB | neuros-firmware.sf.net uses TWiki also, anything i should know? |
| 01:16:43 | fuzzie | make sure you applied the early-september security patch |
| 01:16:50 | fuzzie | which is mysteriously not mentioned anywhere on their front page |
| 01:17:30 | rasher | http://twiki.org/cgi-bin/view/Codev/SecurityAlertExecuteCommandsWithRev |
| 01:17:34 | rasher | that one |
| 01:17:57 | Bagder | and check your server for alien processes |
| 01:18:33 | | Join elinenbe [0] (i=elinenbe@207-237-225-9.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 01:18:34 | Bagder | grep apache logs for "?rev=.*% HTTP" |
| 01:18:46 | Bagder | "?rev=.*%.* HTTP" even |
| 01:18:56 | elinenbe | what sort of cunt destroys a free open source project. |
| 01:19:08 | elinenbe | sorry for the language... |
| 01:19:12 | elinenbe | but what an ass. |
| 01:19:28 | fuzzie | probably someone randomly scanning for twiki installs via google or something, to be honest |
| 01:20:09 | rasher | That's my guessing too |
| 01:20:11 | Zagor | fuzzie: yes |
| 01:20:28 | rasher | I fail to understand the reasoning behind this |
| 01:20:35 | preglow | as for dsp chips and gcc support: are there any? |
| 01:20:42 | elinenbe | has Linus worked anymore on the H320? |
| 01:20:42 | preglow | i know blackfin's god gcc support |
| 01:20:51 | Zagor | preglow: not really |
| 01:20:52 | preglow | but blackfin isn't exactly a typical dsp |
| 01:21:07 | preglow | and it's 16 bit |
| 01:21:32 | preglow | to get the most out of your typical dsp chip, you need to use asm |
| 01:22:33 | DeepB | well.. it's hosted on sf.net |
| 01:22:40 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
| 01:22:46 | Bagder | DeepB: then you're probably safe |
| 01:22:52 | Bagder | you can easily check it |
| 01:23:02 | DeepB | so i don't have to worry about the server |
| 01:23:04 | Bagder | there's a sample URL in that alert |
| 01:23:10 | DeepB | but i appreciatte my data |
| 01:23:31 | Zagor | the sample url is harmless |
| 01:23:37 | fuzzie | just make sure you're patched |
| 01:23:40 | DeepB | thank you for the pointers guys, i'll check it right on |
| 01:23:48 | fuzzie | but, to be honest, you should be backing up stuff from sourceforge regularly |
| 01:24:10 | fuzzie | there's nothing to stop other sf users from damaging anything apache-writable, afaik. |
| 01:24:33 | Bagder | unless they run suexec |
| 01:25:13 | fuzzie | they didn't when i was last hosting web stuff there |
| 01:25:23 | fuzzie | [i've long since deserted them, cvs is unusable] |
| 01:25:23 | | Quit matsl (Remote closed the connection) |
| 01:25:37 | | Quit [IDC]Dragon () |
| 01:25:44 | Bagder | yes, I've abandonded them too for almost everything |
| 01:25:47 | * | Zagor has painful memories from when rockbox had cvs at sf. |
| 01:26:24 | rasher | Now someone write that SF > Bojira migration script |
| 01:26:50 | rasher | So we can ditch the patch/bug tracker |
| 01:26:55 | rasher | It's vile. |
| 01:27:39 | Zagor | I agree very much. |
| 01:27:47 | Zagor | but I've never heard of Bojira :-) |
| 01:27:51 | | Quit ashridah ("Leaving") |
| 01:27:57 | fuzzie | bojira being bugzilla :) |
| 01:28:00 | rasher | Oh, Bugzilla |
| 01:28:07 | Zagor | aaah |
| 01:28:13 | DeepB | fuzzie: i know, i'd like to get rid of that can of worms as soon as i can |
| 01:28:25 | fuzzie | hm, mojira.org doesn't point at the right pages any more |
| 01:28:44 | rasher | fuzzie: crikey |
| 01:28:48 | Bagder | http://www.rockbox.org/Neuros-chat-20050920.txt |
| 01:29:09 | fuzzie | excellent :) |
| 01:29:22 | Zagor | I'm having problems registering on their mailing list (and another sf.net list) |
| 01:29:34 | Bagder | I managed just now |
| 01:29:49 | rasher | Maybe SF is just slow. |
| 01:29:55 | rasher | Who am I kidding, SF *is* slow. |
| 01:29:56 | fuzzie | oh, right, they can turn off the power on the DSP, that's useful |
| 01:30:34 | | Quit linuxstb_ ("Leaving") |
| 01:30:36 | Zagor | rasher: slow as in four days? |
| 01:31:06 | fuzzie | sure your mail server isn't blocking them? |
| 01:31:18 | fuzzie | i signed up to the neuros442linux-main thing and it only took a few minutes |
| 01:31:18 | | Quit paugh (Excess Flood) |
| 01:31:37 | Zagor | yes. I get the confirmation mail, but when I confirm I don't get the welcome mail. |
| 01:31:54 | | Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
| 01:31:55 | Bagder | I bet they enabled the Zagor filter |
| 01:31:59 | Bagder | I use it all the time ;-) |
| 01:32:03 | Zagor | they too? gaah |
| 01:32:35 | Bagder | now, less than 5 hours to get-up time, I better sleeeeep |
| 01:32:42 | Bagder | night |
| 01:32:45 | Zagor | night |
| 01:32:45 | fuzzie | well, i've managed to get both, total time between them 3 minutes or so, so i guess they might well have done :) |
| 01:32:48 | fuzzie | night |
| 01:33:06 | Zagor | I'm feeling discriminated. ItProbably |
| 01:33:07 | rasher | I haven't got my confirmation mail yet. |
| 01:33:24 | Zagor | It's probably because I'm.... uh... tired. |
| 01:33:34 | rasher | But then, I think some server along the way to me is doing greylisting and not being very smart about it |
| 01:34:14 | * | preglow ponders the possibilities of having a proper dsp core... |
| 01:34:58 | Zagor | preglow: the possibilities are great, if you have some way of programming it. doing it all in assembler is not too fun... |
| 01:35:24 | fuzzie | depending on your idea of fun |
| 01:35:24 | preglow | i have somehow gotten used to assembler since starting to code for rockbox... |
| 01:35:30 | | Join void [0] (n=void@ool-18b89646.dyn.optonline.net) |
| 01:35:33 | Zagor | preglow: hehe |
| 01:35:38 | void | heya guys |
| 01:35:48 | void | was wondering if there's a site or area I can download wps files from? |
| 01:36:03 | void | it's for the archos recorder |
| 01:36:06 | preglow | void: you're out of luck, our wps page is broken after being hacked |
| 01:36:12 | void | gah |
| 01:36:14 | Zagor | void: http://www.rockbox.org/twiki/bin/view/Main/WpsGallery |
| 01:36:20 | rasher | Ah, for the recorder it should be up to date |
| 01:36:25 | preglow | ooh |
| 01:36:25 | rasher | or.. |
| 01:36:26 | preglow | goodness, then |
| 01:36:27 | Zagor | preglow: the WPS:es are in the text, not as attachments |
| 01:36:44 | rasher | rasher.dk/rockbox/WikiRescue/WpsGallery-r1.282%20-%2009-08.html">http://rasher.dk/rockbox/WikiRescue/WpsGallery-r1.282%20-%2009-08.html |
| 01:37:57 | rasher | That's linked at the top of the page anyway |
| 01:38:01 | void | cool thanks a ton :) |
| 01:44:09 | | Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
| 01:44:53 | | Quit hicks (Remote closed the connection) |
| 01:53:38 | preglow | hrmph |
| 01:55:39 | | Quit paugh ("Leaving") |
| 01:55:44 | | Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
| 02:00 |
| 02:07:30 | | Part stripwax |
| 02:10:21 | | Quit preglow ("leaving") |
| 02:12:32 | *** | Saving seen data "./dancer.seen" |
| 02:48:33 | | Quit tvelocity ("Leaving") |
| 02:51:41 | | Join lee_ [0] (n=lee@67-42-194-6.eugn.qwest.net) |
| 03:00 |
| 03:09:03 | | Quit ze (Read error: 104 (Connection reset by peer)) |
| 03:13:41 | | Join bitshift [0] (i=lock@CPE000c6e94cf09-CM001225d870de.cpe.net.cable.rogers.com) |
| 03:21:05 | | Join dropandho [0] (n=dropandh@cpe-24-193-36-91.nyc.res.rr.com) |
| 03:21:12 | | Part bitshift |
| 03:21:16 | dropandho | rasher- u rock |
| 03:21:20 | dropandho | thanks for all your work |
| 03:21:26 | dropandho | do you need any help? |
| 03:21:34 | rasher | I think it's mostly done |
| 03:21:39 | dropandho | wow |
| 03:21:45 | dropandho | and how much do you get paid for this?! |
| 03:21:47 | dropandho | hehe |
| 03:21:53 | rasher | The WPS gallery is left - leaving that for people to fix by themself |
| 03:22:04 | dropandho | yeah- that is a good call |
| 03:22:07 | rasher | dropandho: I've been paid one pice of excellent firmware |
| 03:22:20 | dropandho | do you wanna announce your progress on the front page |
| 03:22:25 | dropandho | hehe- i hear ya |
| 03:22:50 | rasher | Hm, maybe there should be something |
| 03:23:20 | dropandho | just so folks know whats up |
| 03:23:30 | dropandho | especially the wps people |
| 03:23:48 | rasher | I've marked the WPS page quite heavily |
| 03:23:59 | dropandho | got it |
| 03:24:26 | dropandho | maybe just about the success |
| 03:24:32 | dropandho | what is missing and what isnt? |
| 03:24:40 | dropandho | plus, you need to get props |
| 03:24:40 | dropandho | ! |
| 03:25:17 | rasher | Hah, I'll do fine without.. but let me add something.. |
| 03:25:37 | | Quit paugh ("Leaving") |
| 03:25:39 | rasher | Now I know the wiki quite well after this.. |
| 03:26:20 | dropandho | no kiddin |
| 03:26:25 | dropandho | intimately |
| 03:26:47 | dropandho | and also maybe something about if the hole was patched up |
| 03:26:52 | * | rasher checks out www |
| 03:26:55 | rasher | Oh, it was |
| 03:27:03 | dropandho | and the progress on fixing a regular backups |
| 03:27:06 | rasher | Before going online again |
| 03:27:11 | | Part DeepB |
| 03:27:15 | dropandho | i dont know...just thinking about what inquiring minds might wanna know |
| 03:27:45 | rasher | Fair enough.. I'm going to add a note |
| 03:27:49 | rasher | in.. uh.. a while, it seems |
| 03:28:53 | dropandho | fair enough |
| 03:28:57 | dropandho | so no help is needed? |
| 03:29:20 | rasher | Not outside the WPS gallery really |
| 03:29:28 | | Quit lee_ ("Leaving") |
| 03:29:35 | | Join bagawk [0] (n=lee@unaffiliated/bagawk) |
| 03:29:40 | dropandho | impressive...thanks again |
| 03:30:43 | rasher | Well, I didn't do it all alone. Probably did most of it though I guess |
| 03:31:26 | dropandho | yes, get some sleep now! |
| 03:31:35 | rasher | haha |
| 03:32:06 | dropandho | ok- have a good night |
| 03:32:13 | dropandho | thanks and take care rasher |
| 03:32:29 | rasher | night, thanks for the appreciation |
| 03:32:31 | | Quit dropandho () |
| 03:37:51 | | Join ze [0] (i=ze@ca-dstreet-cuda1-c6a-81.snbrca.adelphia.net) |
| 03:37:55 | | Quit ze (Read error: 104 (Connection reset by peer)) |
| 03:42:30 | | Join ze [0] (i=ze@ca-dstreet-cuda1-c6a-81.snbrca.adelphia.net) |
| 03:42:37 | | Quit ze (Read error: 104 (Connection reset by peer)) |
| 03:43:31 | | Join ze [0] (i=ze@ca-dstreet-cuda1-c6a-81.snbrca.adelphia.net) |
| 03:43:36 | | Quit ze (Read error: 104 (Connection reset by peer)) |
| 03:44:41 | | Join ze [0] (i=ze@ca-dstreet-cuda1-c6a-81.snbrca.adelphia.net) |
| 03:44:43 | | Quit ze (Read error: 104 (Connection reset by peer)) |
| 03:45:41 | | Join ze [0] (i=ze@ca-dstreet-cuda1-c6a-81.snbrca.adelphia.net) |
| 03:45:44 | | Quit ze (Read error: 104 (Connection reset by peer)) |
| 03:53:15 | | Join ze [0] (i=ze@ca-dstreet-cuda1-c6a-130.snbrca.adelphia.net) |
| 04:00 |
| 04:06:08 | | Join QT_ [0] (i=as@madwifi/users/area51) |
| 04:12:36 | *** | Saving seen data "./dancer.seen" |
| 04:13:31 | | Quit bagawk ("Leaving") |
| 04:16:00 | | Quit QT (Read error: 110 (Connection timed out)) |
| 04:28:07 | | Join Mirthoneist [0] (n=mirthypo@c-66-177-213-74.hsd1.fl.comcast.net) |
| 04:28:07 | | Quit Mirthoneist (Client Quit) |
| 04:30:41 | | Join Mirthoneist [0] (n=mirthypo@c-66-177-213-74.hsd1.fl.comcast.net) |
| 04:50:47 | | Quit cYmen ("zZz") |
| 05:00 |
| 05:05:40 | | Join Yono [0] (n=Yono@69-169-174-248.bflony.adelphia.net) |
| 05:07:19 | | Quit Yono ("Download Gaim: http://gaim.sourceforge.net/") |
| 05:13:39 | | Quit rasher (Remote closed the connection) |
| 05:48:57 | | Quit Mirthoneist () |
| 06:00 |
| 06:00:46 | | Join Tomas_ [0] (n=Tomas@ip503c08d1.speed.planet.nl) |
| 06:12:39 | *** | Saving seen data "./dancer.seen" |
| 06:15:33 | | Quit t0mas (Read error: 110 (Connection timed out)) |
| 06:15:33 | | Nick Tomas_ is now known as t0mas (n=Tomas@ip503c08d1.speed.planet.nl) |
| 06:20:14 | | Join cheriff [0] (n=davidm@cheriff.ken.nicta.com.au) |
| 06:20:27 | | Quit edx () |
| 06:33:33 | | Join LinusN [0] (n=linus@labb.contactor.se) |
| 06:36:53 | amiconn | Morning |
| 06:39:27 | amiconn | LinusN: Did you check http://www.rockbox.org/twiki/bin/view/Main/ReleaseTodo ? Your work done for soft poweroff and panic is missing; I just changed the xing header status |
| 06:39:59 | LinusN | didn't look, i'll fix |
| 06:43:39 | LinusN | i was thinking about the bit shift |
| 06:44:21 | LinusN | are there occasions where we disable the interrupt for a long period? i think not |
| 06:44:32 | amiconn | None that I know of |
| 06:45:01 | amiconn | This bitshifting has some really puzzling properties |
| 06:48:12 | | Quit Mxm`Pas`Bien (Read error: 104 (Connection reset by peer)) |
| 06:48:44 | | Join amiconn_ [0] (n=jens@p54BD42C2.dip.t-dialin.net) |
| 06:48:55 | | Join Maxime [0] (n=flemmard@fbx.flemmard.net) |
| 06:52:00 | | Join amiconn__ [0] (n=jens@p54BD414E.dip.t-dialin.net) |
| 06:53:32 | LinusN | amiconn_: puzzling properties? |
| 06:57:24 | | Quit amiconn (Nick collision from services.) |
| 06:57:24 | | Nick amiconn__ is now known as amiconn (n=jens@p54BD414E.dip.t-dialin.net) |
| 06:57:29 | | Quit amiconn_ (Nick collision from services.) |
| 06:58:08 | amiconn | LinusN: Yes. First, the probability of a bitshift happening depends on the transfer speed used. |
| 06:58:33 | LinusN | that suggests performance problems |
| 06:58:52 | amiconn | For the cvs C loop (and my local, slightly more optimised C loop) it happens after 2..4 hours |
| 06:59:28 | amiconn | With my highly optimised asm loop (better than what was in 2.3 and 2.4) it happens after 30 min .. 1 hour |
| 07:00 |
| 07:00:07 | amiconn | This is strange, since it would suggest that it would happen really often when the MAS is connected to a real DMA controller |
| 07:01:13 | amiconn | These time periods are rather long compared to the amount of data transferred - one shift after millions of bytes |
| 07:01:43 | amiconn | Second, the shift seems to always happen at a frame boundary, which is not necessarily a DMA block boundary |
| 07:02:09 | amiconn | (although I'm not 100% sure about the frame boundary) |
| 07:03:03 | LinusN | no, that's not easy to tell |
| 07:03:39 | LinusN | so maybe it is a reverse performance problem |
| 07:03:52 | LinusN | that the mas can't cope with out fast transfer speed |
| 07:06:26 | amiconn | Oh, and third, the probability depends on the quality setting and the recording level |
| 07:07:14 | LinusN | also suggesting a mas performance problem |
| 07:07:46 | amiconn | I derived the frame boundary rule from my simple restore method. As it's not easy to tell the exact point, I presumed it was at the frame boundary, and undid the bitshift accordingly with my tool |
| 07:08:18 | amiconn | When playing the recording, there were no audible glitches at these points |
| 07:09:06 | amiconn | I suspect archos might know some more about the mas recording init than what the datasheet says |
| 07:10:40 | amiconn | I don't think it's a simple performance problem. (1) The mas tells us when it's ready to transfer a block, by raising EOD. Why would it do that before it's really ready for transfer? |
| 07:11:21 | amiconn | (2) The bitshift isn't temporary for one block or one frame, it stays for hours until another shift happens eventually |
| 07:12:01 | amiconn | I even had one test recording sequence where the next shift brought the bit order back to normal.... |
| 07:13:00 | amiconn | It seems that the mas tends to shift forward, the most observed shift values are +1 ... +3 bits (i.e. to the right) |
| 07:13:30 | amiconn | Although I had one case of -1, I believe this really was a +7 shift |
| 07:14:35 | amiconn | ...derived from the fact that I also had one case of a +8 shift, which of course didn't destroy the recording, but there was a stray byte in the stream... |
| 07:18:02 | LinusN | so perhaps the internal transfer from the DSP to the dma buffer inside the MAS is serial |
| 07:18:43 | Bger | morning all :) |
| 07:19:15 | LinusN | morning |
| 07:24:50 | Bger | i see rasher has completed the wiki update ... |
| 07:28:47 | amiconn | LinusN: I don't know whether it's only a rumour, but didn't archos make the mas recording at 192 kbps cbr is some later product? |
| 07:29:07 | LinusN | haven't heard of it |
| 07:29:40 | amiconn | 192 kbps cbr means more load than q=7 (which goes up to 192 kbps frames, but is ~170 kbps on average) |
| 07:31:15 | LinusN | hmmm, i see we poll EOD |
| 07:31:45 | amiconn | http://www.rockbox.org/irc/rockbox-20040809.txt around 12:30 |
| 07:32:08 | LinusN | according to the data sheet, EOD might not go inactive until after 8us |
| 07:33:37 | amiconn | Yes, and that's what the timeout loop for /rtw is for |
| 07:34:04 | amiconn | As EOD might still be high when the DMA buffer is empty, we raise PR as we expect another byte |
| 07:34:14 | amiconn | A real DMA controller would do the same |
| 07:34:50 | LinusN | http://www.archos.com/download/firmware/AV300_OS_History.txt |
| 07:34:59 | LinusN | "New Feature: MP3 encoding can now be done in 192kbit/s CBR for sample rates of 32, 44.1 and 48kHz" |
| 07:35:03 | amiconn | Then we wait for /rtw to signal the next byte is ready. If it's not (after a much longer timeout than 8µs) we lower PR again |
| 07:35:42 | amiconn | The archos recording loop does the same, with an even longer timeout |
| 07:35:53 | amiconn | (which doesn't make a difference; I tried) |
| 07:37:08 | | Join B4gder [0] (n=daniel@static-213-115-255-230.sme.bredbandsbolaget.se) |
| 07:39:32 | LinusN | i suspect a real dma controller would wait for _RTW before polling EOD |
| 07:40:10 | B4gder | morning |
| 07:40:14 | LinusN | morning |
| 07:40:44 | B4gder | seen the neuros chat log? |
| 07:40:50 | LinusN | B4gder: no |
| 07:41:06 | LinusN | (i fell asleep ans missed the meeting, sorry) |
| 07:41:19 | B4gder | http://www.rockbox.org/Neuros-chat-20050920.txt |
| 07:41:49 | amiconn | LinusN: Nothing guarantees that EOD goes low before the final /rtw -> inactive transition (according to the datasheet) |
| 07:42:07 | LinusN | no? |
| 07:43:50 | amiconn | No. If we lower PR after t3, EOD might still be high because teod may be up to 8 µs |
| 07:44:06 | amiconn | Perhaps a rather unusual approach would work - keeping PR high by default (!) |
| 07:47:45 | LinusN | yes, if we lower PR after t3, EOD might still be high, but i doubt it would still be high when RTW goes up again |
| 07:49:47 | amiconn | Iirc the very old loops had that (in rockbox 2.2), but I'll do a test |
| 07:53:23 | amiconn | Test running, gotta hurry now... |
| 07:57:33 | | Join Febs [0] (n=Febs@207-172-122-81.c3-0.rdl-ubr4.trpr-rdl.pa.cable.rcn.com) |
| 08:00 |
| 08:01:16 | | Join ender` [0] (i=ychat@84.52.165.220) |
| 08:12:43 | *** | Saving seen data "./dancer.seen" |
| 08:14:53 | t0mas | Bagder? |
| 08:14:57 | B4gder | yes |
| 08:14:58 | t0mas | (and LinusN and Zagor) |
| 08:15:03 | t0mas | reading the logs about neuros... |
| 08:15:13 | LinusN | me too |
| 08:15:20 | t0mas | maybe it's a good idea to register rockbox as a company |
| 08:15:34 | t0mas | or isn't it possible to register a non-profit organisation in your country? |
| 08:15:40 | B4gder | yes it is |
| 08:15:48 | t0mas | might be a good idea to do that? |
| 08:16:07 | B4gder | perhaps, I don't think it'll change much |
| 08:16:15 | t0mas | setup a contract where you three are the owners and delegate the copyright to the writers |
| 08:16:29 | t0mas | but add a part explaining that you are the last right holders |
| 08:16:45 | B4gder | well, it doesn't work in quite that way |
| 08:17:04 | t0mas | it does if you ask everybody with cvs write access to agree to it |
| 08:17:30 | B4gder | yes, but they would have to agree to sign over their copyright to us |
| 08:17:47 | B4gder | and I don't think we need that |
| 08:17:49 | t0mas | in holland it can be done different... |
| 08:17:56 | B4gder | I doubt that |
| 08:18:20 | B4gder | each author owns their own work |
| 08:18:28 | t0mas | well... we have some system here... making it possible for all authors to have the rights, but at the same time giving 1 company the right to sell it etc... |
| 08:19:16 | t0mas | and if they do... the authors still have the copyrights on the version at that point... but the new version is free for the next company to do whatever they want with it afaik |
| 08:19:41 | B4gder | in this case, no one can forbid any company to sell rockbox |
| 08:19:56 | t0mas | (don't think it's GPL compatible... it's used in universities a lot) |
| 08:20:31 | B4gder | I don't see how we have a problem, so I don't see anything to fix ;-) |
| 08:20:47 | t0mas | well... you can't contact Ti now for example... |
| 08:20:57 | B4gder | ? |
| 08:21:04 | t0mas | as said in the logs? |
| 08:21:08 | B4gder | no one can get any sense out of TI |
| 08:21:12 | t0mas | ghehe |
| 08:21:21 | B4gder | Neuros been trying for years |
| 08:21:36 | t0mas | and for hosting contracts etc... it's 1 of you 3 who's the contractee... |
| 08:21:56 | t0mas | and afaik you have to pay taxes on the gifts to rockbox? |
| 08:22:03 | t0mas | it is that free in your country? |
| 08:22:33 | B4gder | it is free |
| 08:22:44 | B4gder | donations are |
| 08:23:18 | t0mas | ah ok |
| 08:23:29 | t0mas | that makes it a lot easier |
| 08:23:56 | t0mas | well.. maybe it's different there then... in holland we have some regulations madness... |
| 08:24:03 | t0mas | so you have to register almost anything |
| 08:38:46 | Febs | t0mas and JoeBorn raise some interesting points about the legal status of Rockbox. |
| 08:39:45 | B4gder | I don't think it is primarily a legal problem |
| 08:41:32 | B4gder | other than perhaps a question about who owns the name and the logo etc |
| 08:41:39 | Febs | Well, for example, who has authority to sign a contract on behalf of Rockbox, should a contract need to be signed? |
| 08:41:49 | B4gder | hm, no not the logo |
| 08:42:07 | Febs | Actually, the logo is a good example. Who designed the logo? |
| 08:42:16 | B4gder | the logo is owned by its creator |
| 08:42:22 | Zagor | it's pretty much the same using rockbox or linux. who signs contracts for linux? nobody does. |
| 08:42:31 | t0mas | Febs: nobody can sign anything on behalf of rockbox now |
| 08:42:37 | t0mas | because rockbox legally doesn't exist |
| 08:42:46 | B4gder | That isn't necessarily true |
| 08:42:54 | Zagor | rockbox does exist. it's just not a company. |
| 08:42:58 | t0mas | Zagor: Linus (torvalds) started some holding company for linux... |
| 08:43:01 | B4gder | an informal team exists |
| 08:43:06 | B4gder | even in the eye of the law |
| 08:43:22 | t0mas | it doesn't here... |
| 08:43:23 | t0mas | afaik |
| 08:43:37 | * | B4gder is involved in talks about exactly this in a very high-stake open source project |
| 08:43:43 | t0mas | you can register some legal entity for informal non-profit things like sportsteams etc |
| 08:44:13 | t0mas | intresting how this is done different all over europe... |
| 08:44:29 | Febs | ... and here on the other side of the pond! |
| 08:45:10 | Zagor | the point is the law isn't blind. nobody is allowed to railroad over us just because we're not a company. individuals have the same rights as companies. |
| 08:45:39 | t0mas | yes, we have... but we can't do anything (like getting a hosting contract for the website) as rockbox... |
| 08:45:51 | t0mas | that has to be done as some individual... who is responsible for it then |
| 08:45:51 | B4gder | I'd say that the biggest problem would be our international nature |
| 08:46:06 | t0mas | yeah, that is a problem I guess |
| 08:46:19 | B4gder | we'll simply don't sign contracts as "rockbox" |
| 08:46:46 | B4gder | at least, not until we have a formal org for it |
| 08:46:47 | Zagor | t0mas: I don't see that as a problem (contracts). in the end single individuals *are* responsible. |
| 08:46:55 | Zagor | we wouldn't be better off having "rockbox" responsible |
| 08:46:56 | t0mas | wait a moment |
| 08:47:03 | t0mas | client fucking up again |
| 08:47:12 | Febs | Zagor, yikes! |
| 08:47:16 | t0mas | ah, back |
| 08:47:35 | t0mas | Zagor: got to run |
| 08:47:44 | Zagor | ok |
| 08:47:47 | Febs | Do you want to be individually responsible if, for example, Rockbox bricks a large number of players? |
| 08:47:58 | Zagor | Febs: yes |
| 08:48:07 | B4gder | yes, if you sign a personal contract that you are, then sure |
| 08:48:07 | Febs | Really? |
| 08:48:20 | t0mas | (sorry... have to work now) |
| 08:48:45 | Zagor | however we put pretty strong disclaimers on the firmware that says "works for us, might not for you". |
| 08:50:56 | | Join aga [0] (i=svann@01-057.032.popsite.net) |
| 08:51:47 | aga | hey does rockbox 2.4 supposed to display a 'charging' screen when you have the charger plugged in |
| 08:52:42 | aga | i just got a used archos and am trying to determine if its got a fault |
| 08:54:10 | Zagor | aga: which model? |
| 08:54:22 | aga | jb recorder 20 |
| 08:54:45 | aga | the battery icon will have a question mark sometimes, then after a while it says 40% or so |
| 08:55:04 | Zagor | with the charger plugged, the battery icon should at least animate |
| 08:55:14 | aga | and ive changed the batteries to ones that i know are good |
| 08:55:55 | aga | ok so i have either a bad unit or a bug i guess |
| 08:56:32 | Zagor | could be a broken dc/dc regulator. that's not entirely uncommon. |
| 08:57:09 | aga | does that workaround with the F1 have anything to do with this? |
| 08:57:36 | aga | oh you mean the charger might be bad, or the connecting pin |
| 08:58:11 | Zagor | an IC in the archos. it breaks if you insert a charger with wrong polarity or such. |
| 08:59:26 | * | Febs has been thinking about Zagor's point and disclaimers and B4dger's point about personal contracts. |
| 08:59:37 | aga | i saw that faq in the forum, i guess you get the IC from archos |
| 09:00 |
| 09:00:13 | aga | anyway to quickly tell if that is the problem besides disassembling |
| 09:00:28 | Zagor | aga: it's a pretty standard part you get from an electronics shop. |
| 09:00:30 | Febs | The whole nature of an open source project raises some really interesting legal questions. |
| 09:00:43 | Febs | Perhaps more interesting to me than to you folks. |
| 09:01:09 | Bger | Febs are you a lawyer ? ;) |
| 09:01:16 | | Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) |
| 09:01:19 | B4gder | I am quite interested in the legal parts as well |
| 09:01:54 | aga | i didnt understand that 'press F1 ON' sequence then plug in the charger bit. does that relate to my problem? |
| 09:02:25 | Zagor | aga: no, that just makes you boot the archos firmware instead of rockbox |
| 09:03:12 | aga | ok thanks, ill check the faqs and see whats up |
| 09:04:05 | Zagor | Febs: start at the other end. since when are commercial software companies responsible for their bugs? microsoft software bugs causes billions of damage every year, for instance. |
| 09:05:26 | | Part aga |
| 09:06:37 | | Part cheriff |
| 09:07:58 | Bger | Zagor have you read the M$'s EULA ? |
| 09:08:12 | Zagor | I have |
| 09:08:28 | Zagor | well, a few of them. different products use difference eulas |
| 09:08:33 | Bger | yeah |
| 09:09:11 | Bger | from "diagonal" reading, afaics, they wash away their hands ... |
| 09:09:27 | Bger | about responsibility |
| 09:09:43 | Zagor | oh yes, every way they can (and some they can't) |
| 09:09:54 | Bger | :) |
| 09:10:49 | | Join aga [0] (i=svann@01-057.032.popsite.net) |
| 09:11:01 | aga | I forgot one thing |
| 09:11:32 | aga | when you boot up, are you supposed to see the firmware 1.8, *Then the rockbox logo afterwards? |
| 09:11:41 | aga | on the jb recorder 20 |
| 09:11:52 | Zagor | aga: if you are not flashed, yes |
| 09:12:15 | aga | oh ok, so that is normal, not a conflict between programs |
| 09:12:34 | Zagor | no. the archos firmware boots and then finds rockbox and loads it. |
| 09:13:12 | aga | dang, i thought that would be it |
| 09:13:19 | aga | ok |
| 09:13:25 | * | aga slogs off |
| 09:13:28 | | Quit aga (Client Quit) |
| 09:14:32 | Febs | Bger, yes. I am a lawyer. (A lawyer with insomnia at the moment.) |
| 09:14:46 | Bger | hehe :) |
| 09:14:53 | Bger | that's not good |
| 09:16:25 | Febs | Yeah, it's 3:14 AM here in the eastern U.S. |
| 09:17:41 | Febs | I'm also a working musician. |
| 09:17:57 | Bger | wow:) interesting combination |
| 09:18:19 | Febs | Yeah. Not always easy to balance. |
| 09:18:52 | Zagor | Bger: the GPL (and pretty much every other license) contains such No Warranty clauses too, however not quite as far-fetched as the MS EULAs. |
| 09:19:26 | Bger | and at least in most cases you pay for support, not for the product itself ... |
| 09:20:14 | Zagor | that's an issue too: even if authors were liable, how much warranty does your $0 buy you? |
| 09:21:09 | Zagor | requiring overreaching liability from authors would completely kill free software |
| 09:22:01 | Zagor | Can you tell I too am interested in the legal angles? ;) |
| 09:22:32 | Febs | Like I said before, many interesting questions ... |
| 09:23:51 | Febs | ... which I've been very careful not to answer. ;) |
| 09:24:04 | Zagor | hehe. you ARE a lawyer! :-D |
| 09:24:25 | Febs | :-D |
| 09:28:32 | Febs | In all seriousness, as I'm sure you can appreciate, I *do* need to be careful not to give legal advice in a public forum. |
| 09:28:39 | Zagor | absolutely |
| 09:31:43 | Zagor | Let's just say if free software liability would become an issue, Rockbox is pretty far down the list of prominent projects getting in trouble. |
| 09:32:18 | Zagor | (Heck, half the Internet would probably shut down... ) |
| 09:33:38 | | Join bobTHC [0] (n=bobTHC@62.34.136.111) |
| 09:33:44 | bobTHC | mornin' folks ! |
| 09:33:53 | Zagor | howdy |
| 09:34:25 | bobTHC | i'm fine and u ? |
| 09:34:31 | Febs | It's good night for me. Time for some sleep ... |
| 09:34:41 | Zagor | Febs: good night |
| 09:34:46 | Zagor | bobTHC: just peachy |
| 09:35:03 | bobTHC | nice ;) |
| 09:35:18 | | Quit Febs (" HydraIRC -> http://www.hydrairc.com <- Go on, try it!") |
| 09:43:16 | | Join Dma-Sc [0] (n=Dma-Sc@LAubervilliers-151-11-60-200.w193-251.abo.wanadoo.fr) |
| 10:00 |
| 10:02:39 | | Quit linuxstb_ ("Leaving") |
| 10:08:07 | HCl | *yawn* |
| 10:12:47 | *** | Saving seen data "./dancer.seen" |
| 10:26:37 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
| 10:37:27 | | Join ashridah [0] (i=ashridah@220-253-121-53.VIC.netspace.net.au) |
| 10:43:08 | Bger | joke of the day: http://www.google.com.super-fast-search.apsua.com/check.htm haha |
| 10:43:17 | Bger | don't try it in IE |
| 10:44:57 | Bger | btw, i gave up translating rockbox to bulgarian. The system font doesn't have cyrillic (cp1251) chars, so i can't do it as it should be |
| 10:45:18 | snax | apparently my system language is "undefined" |
| 10:45:31 | Bger | snax and your processor ? :) |
| 10:45:34 | snax | which I speak quite fluently, I might add |
| 10:46:16 | B4gder | your processor family is "undefined" |
| 10:46:41 | | Quit DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 10:46:42 | Bger | and it uses ActiveX for displaying explorer window |
| 10:46:47 | snax | apparently I also live in Bellevue, United States |
| 10:47:08 | snax | I must have missed it when that city (which I don't live in, by the way) became a state in the union |
| 10:47:33 | Bger | yeah |
| 10:48:40 | snax | words such as "boy" "father" and "child" were found in my system records |
| 10:48:59 | snax | scandalous |
| 11:00 |
| 11:09:09 | | Join zeekoe [0] (i=HydraIRC@prac063.ewi.utwente.nl) |
| 11:10:56 | | Join tvelocity [0] (n=tony@ipa221.7.tellas.gr) |
| 11:15:41 | | Join preglow [0] (n=thomjoha@hekta.edt.aft.hist.no) |
| 11:28:55 | | Join Moos [0] (i=DrMoos@m113.net81-66-159.noos.fr) |
| 11:38:55 | HCl | can anyone tell me whether rockbox will play audio from an mpeg2 file? |
| 11:39:48 | preglow | depends |
| 11:39:56 | preglow | mpeg2 allows for aac audio as well |
| 11:39:57 | HCl | on..? |
| 11:40:02 | preglow | and that we can't play |
| 11:40:05 | HCl | aha |
| 11:40:09 | preglow | but we can play mpeg2 layer 3 streams |
| 11:40:25 | HCl | but if i have an mpeg2 video file |
| 11:40:34 | HCl | will it take the audio stream? |
| 11:40:45 | preglow | depends on what it is |
| 11:40:53 | HCl | not quite sure, let me check |
| 11:48:03 | | Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 11:52:36 | * | HCl taps his foot while mplayer compiles |
| 12:00 |
| 12:10:10 | preglow | long-whinded, is it? |
| 12:10:57 | | Join Vladoman [0] (n=Vladoman@p54A7E1B9.dip.t-dialin.net) |
| 12:10:59 | Bger | was it on dual xeon 500 or sth similar ? |
| 12:11:28 | Vladoman | amiconn, you still there? |
| 12:11:42 | Bger | he is offline atm |
| 12:12:15 | Vladoman | anybody here working on the "bit shift" problem |
| 12:12:49 | *** | Saving seen data "./dancer.seen" |
| 12:13:11 | preglow | only hiom |
| 12:13:13 | preglow | him |
| 12:13:21 | Vladoman | k |
| 12:14:02 | Moos | why? |
| 12:14:19 | Vladoman | cause I can give some info on it |
| 12:14:34 | Bger | just shoot it |
| 12:14:42 | Moos | log ;) |
| 12:14:45 | Bger | there are irc logs, and he'll see it |
| 12:15:38 | Bger | btw, see http://irc.rockbox.org/irc/current.txt |
| 12:17:52 | | Quit zeekoe (" HydraIRC -> http://www.hydrairc.com <- Try something fresh") |
| 12:17:55 | Vladoman | yep, I just mailed him anyway |
| 12:41:12 | | Nick QT_ is now known as QT (i=as@madwifi/users/area51) |
| 12:48:47 | | Join am1conn [0] (n=c1af49c9@labb.contactor.se) |
| 12:49:29 | Bger | am1conn how was the test |
| 12:50:37 | am1conn | Still running @home, can't check atm |
| 12:51:19 | Bger | k |
| 12:51:42 | Moos | Vladoman: still here? |
| 12:59:18 | | Quit Dma-Sc ("Wow! What a great client! Bersirc 2.2 [ http://www.bersirc.org/ - Open Source IRC ]") |
| 13:00 |
| 13:11:28 | | Join linuxstb_ [0] (n=d556da1b@labb.contactor.se) |
| 13:11:56 | linuxstb_ | HCl: If you use mplayer to extract the audio from an MPEG2 file (I'm guessing it's a "program stream"), then Rockbox should play it. |
| 13:12:11 | linuxstb_ | It's most likely either MP2 or AC3 audio. Use "mplayer -dumpaudio" |
| 13:13:49 | preglow | yeah, can't say i've ever seen aac in an mpeg2 stream |
| 13:14:29 | preglow | any chance of seeing dts support in rockbox? ;) |
| 13:14:41 | LinusN | what is dts? |
| 13:14:54 | linuxstb_ | I read on misticriver that someone played DTS via the optical out on the H1x0. |
| 13:15:07 | linuxstb_ | LinusN: It's a compressed multi-channel format. |
| 13:15:12 | linuxstb_ | Similar to AC3 |
| 13:15:17 | LinusN | oh |
| 13:15:54 | linuxstb_ | "DTS in WAV" is a common format - the player treats it as a normal WAV file, and passes the bitstream to an external decoder via S/PDIF |
| 13:16:01 | preglow | well |
| 13:16:07 | preglow | to say it's similar to ac3 isn't exactly true |
| 13:16:09 | preglow | not internally, at least |
| 13:17:07 | linuxstb_ | I just meant that it's a lossy compression format designed for multi-channel audio. Is that not true? |
| 13:17:27 | preglow | oh, yes |
| 13:18:10 | preglow | but they're pretty different codecs, i don't think dts is a transform codec at all |
| 13:18:25 | preglow | whereas ac3 is more or less just an mdct and some magic |
| 13:18:44 | preglow | i think i've seen some libdts some place |
| 13:19:59 | LinusN | "mdct and some magic", pretty much covers it all :-) |
| 13:20:24 | LinusN | you really make it sound simple ;-) |
| 13:21:18 | linuxstb_ | I wouldn't know - I just treat codecs as black boxes. |
| 13:22:07 | preglow | what, 'magic' isn't a professional term? ;) |
| 13:23:42 | preglow | but no, dts is an adpcm like codec, i think |
| 13:24:07 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
| 13:31:52 | Vladoman | Moos: Yes |
| 13:32:11 | Bger | Vladoman am1conn is (was) here |
| 13:32:42 | Vladoman | thx |
| 13:33:21 | Vladoman | the MAS bit shift is a comfirmed bug (by Micronas), there is no "fix" that they know of (AFAIK) |
| 13:33:33 | preglow | oh |
| 13:33:51 | preglow | then how come the archos firmware can record for quite a while with no shift? |
| 13:34:19 | Vladoman | maybe by working around it? |
| 13:34:58 | preglow | maybe |
| 13:35:08 | preglow | a lot of factors play in, apparently |
| 13:35:15 | preglow | like transfer speed |
| 13:37:07 | Bger | maybe they're scanning the stream from mas realtime while recording (sorry if i'm talking bullsh*ts)) |
| 13:39:32 | preglow | well, they are |
| 13:39:48 | preglow | but i don't know how that helps them in detecting a shift |
| 13:39:55 | preglow | hmm |
| 13:40:07 | preglow | perhaps it is possible to detect a shift in the sync bits |
| 13:40:24 | Bger | i wonder that also |
| 13:40:28 | preglow | i wonder if the bit shift can happen anywhere in a frame or at a boundary |
| 13:40:55 | Bger | amiconn said that he observed the bitshift *only* at frame boundaries |
| 13:41:01 | Bger | see the irc logs |
| 13:42:03 | Vladoman | if the bits are shifted, the sync words would not match any more, no? |
| 13:42:38 | preglow | indeed not |
| 13:42:50 | Vladoman | so it can be detected |
| 13:43:00 | | Join tuco [0] (n=81b17b04@labb.contactor.se) |
| 13:43:03 | preglow | unless the bit shift is eight bits |
| 13:43:17 | preglow | in which case the only thing you can see is a skipped byte |
| 13:43:23 | tuco | Is this the same bit shift as amiconn is investigating? http://www.rockbox.org/twiki/pub/Main/DataSheets/mas3587f_1ais.pdf |
| 13:44:35 | Vladoman | yes, but a skipped byte can also be detected |
| 13:44:54 | preglow | yes, sure |
| 13:45:09 | preglow | the workaround they describe here isn't very nice, though |
| 13:45:13 | tuco | and the workaround described doesn't work? |
| 13:45:15 | preglow | will probably mean some lost recording time |
| 13:45:27 | tuco | ok, probably :) |
| 13:45:31 | preglow | amiconn has considered this workaround |
| 13:45:38 | preglow | don't know about the parity checking, though |
| 13:46:00 | tuco | I suppose he have. |
| 13:47:17 | Vladoman | tuoc: this SPDIF issue is known, it's not the same thing |
| 13:47:27 | tuco | Vladoman: ok |
| 13:47:51 | Bger | preglow today |
| 13:48:01 | Bger | 's log, 07.01.43 |
| 13:48:30 | Bger | 07.07.46 |
| 13:48:40 | | Join markun [0] (n=markun@bastards.student.ipv6.utwente.nl) |
| 13:50:18 | tuco | Have to say amiconn goes through this issue thoroghly |
| 13:51:11 | preglow | yes he does |
| 13:51:25 | tuco | which is good |
| 13:51:38 | | Part crash3m ("Leaving") |
| 13:53:11 | | Part tuco |
| 13:53:33 | | Quit tvelocity ("Leaving") |
| 13:57:06 | | Quit Bger ("BitchX-1.1-final -- just do it.") |
| 14:00 |
| 14:09:32 | | Join Bger [0] (n=Bager@83.222.160.88) |
| 14:12:46 | | Join [IDC]Dragon [0] (n=d90a3255@labb.contactor.se) |
| 14:12:52 | *** | Saving seen data "./dancer.seen" |
| 14:12:59 | [IDC]Dragon | Hi Vladoman ;-) |
| 14:13:14 | Vladoman | hi mighty Dragon |
| 14:26:19 | | Part Vladoman |
| 14:28:41 | | Quit am1conn ("CGI:IRC (EOF)") |
| 14:31:52 | | Quit B4gder ("time to say moo") |
| 14:33:13 | Bger | hehe good quit msg :) |
| 14:36:35 | | Part LinusN |
| 14:43:21 | [IDC]Dragon | ping |
| 14:43:26 | | Join LinusN [0] (n=linus@labb.contactor.se) |
| 14:43:42 | preglow | pong |
| 14:45:23 | | Part LinusN |
| 14:45:52 | | Join am1conn [0] (n=c1af49c9@labb.contactor.se) |
| 14:46:12 | [IDC]Dragon | Jens? |
| 14:46:17 | am1conn | yup |
| 14:46:32 | [IDC]Dragon | you got some info? ;-) |
| 14:47:01 | am1conn | Yes I did |
| 14:47:28 | am1conn | However, there's no quick way to implement that in rockbox |
| 14:48:07 | [IDC]Dragon | yes, we need Luke Framewalker |
| 14:48:13 | | Join LinusN [0] (n=linus@labb.contactor.se) |
| 14:48:32 | preglow | am1conn: have you read what i said about detecting bitshift in a frame? an hour ago or something |
| 14:48:47 | [IDC]Dragon | could do some good on playback, too (audible FF/FR) |
| 14:48:52 | LinusN | indeed |
| 14:49:29 | [IDC]Dragon | LinusN in Germany \o/ |
| 14:49:47 | LinusN | leaving tomorrow |
| 14:52:04 | | Join tvelocity [0] (n=tony@ipa221.7.tellas.gr) |
| 14:54:06 | | Join rasher [0] (n=jonas@62.79.64.148.adsl.hs.tiscali.dk) |
| 15:00 |
| 15:01:54 | Bger | rasher congrats for the work yesterday |
| 15:02:44 | rasher | Why, thanks.. there were not that many pages with big changes left |
| 15:03:34 | | Join crash3m [0] (i=crash3m@unaffiliated/crash3m) |
| 15:03:46 | Bger | hm, at least IriverInstall :) |
| 15:05:42 | rasher | Yeah, that took a while |
| 15:06:24 | preglow | trivial commit time |
| 15:06:34 | | Part crash3m ("Leaving") |
| 15:07:10 | Bger | hm, it seems that the new wiki doesn't allow to create attachments without comment |
| 15:07:23 | LinusN | yes, we're aware of that |
| 15:07:26 | LinusN | silly indeed |
| 15:07:32 | Bger | yep |
| 15:07:47 | LinusN | and the "view raw" is horrible |
| 15:07:56 | Bger | yes |
| 15:08:24 | Bger | it's horror to read bigger pages |
| 15:08:51 | rasher | Shouldn't take much to fix |
| 15:09:43 | Zagor | i'll look at both issues in a bit |
| 15:10:58 | LinusN | Zagor: it seems you'll have to change the wiki source code |
| 15:11:11 | LinusN | you did that the last time too? |
| 15:11:32 | Zagor | yes, but I'd like to avoid it this time since we're using auto-updated packages |
| 15:11:39 | Zagor | we'll see |
| 15:11:58 | LinusN | it doesn't seem to be configurable, from what i saw in the code |
| 15:16:47 | | Join atubbs [0] (n=atubbs@ool-435634a8.dyn.optonline.net) |
| 16:00 |
| 16:05:42 | | Quit am1conn ("CGI:IRC (EOF)") |
| 16:10:30 | | Join Rori [0] (i=MO-Pants@deadman3000.plus.com) |
| 16:10:35 | Rori | hi. anyone awake? |
| 16:10:56 | | Quit Moos ("Parti") |
| 16:11:07 | rasher | Could be |
| 16:11:26 | Rori | I have a couple of problems with latest builds of h120 rb |
| 16:11:39 | LinusN | no, you're lying |
| 16:11:49 | LinusN | there is noooo problem in rockbox :-) |
| 16:12:03 | * | LinusN looks away |
| 16:12:52 | Rori | 1. I get a dir buffer full error when accessing a directory with over 1000 files in it. 2. I can't get wps to display correctly anymore. It shows the bmp path and fonts don't change. Also it seems to crash on occasion |
| 16:12:54 | *** | Saving seen data "./dancer.seen" |
| 16:13:08 | Bger | Rori increase dir buffer size |
| 16:13:11 | Rori | I did |
| 16:13:14 | Rori | makes no difference |
| 16:13:17 | LinusN | 1) Adjust the "Max files in dir" setting |
| 16:13:25 | Rori | I set dir limits to 10,000 same prob |
| 16:13:28 | LinusN | you need to reboot for it to have effect |
| 16:13:39 | Rori | let me try reboot |
| 16:14:13 | Rori | that worked |
| 16:14:26 | LinusN | 2) Reset your settings and adjust the wps to the current specification |
| 16:14:47 | Rori | wuh? you mean it's all changed? |
| 16:14:51 | LinusN | the wps format has changed a bit, especially for bitmaps |
| 16:14:58 | Rori | bleh |
| 16:14:58 | Bger | LinusN iirc there were problems with max files in dir > 5000 or so |
| 16:15:06 | LinusN | Bger: really? |
| 16:15:26 | LinusN | i didn't know that |
| 16:15:31 | Bger | maybe i'm wrong, but i remember something about this |
| 16:15:32 | Rori | player crashed again |
| 16:15:50 | LinusN | crashed how? |
| 16:16:00 | HCl | hmmm |
| 16:16:04 | Rori | as in locked up solid with light on |
| 16:16:08 | LinusN | wow |
| 16:16:17 | LinusN | i suggest you reset your settings |
| 16:16:26 | HCl | preglow: my mpg has an internal mp3 stream, so rockbox would be able to play it even though its a video? |
| 16:16:45 | LinusN | HCl: probably not |
| 16:17:12 | LinusN | the mp3 decoder will bail out if it encounters many sync errors |
| 16:17:12 | HCl | who would i have to talk to to change it so you can play audiostreams from video mpeg2s |
| 16:17:24 | LinusN | HCl: yourself :-) |
| 16:17:26 | Rori | maybe the wps that now needs redoing is causing the crashes when I try to load them |
| 16:17:32 | HCl | mk |
| 16:17:40 | LinusN | Rori: yes, reset your settings |
| 16:18:32 | Rori | yeah did. I need to fix the wps now....where is the info for changing to the new commands? |
| 16:19:00 | LinusN | in the "documentation" section on rockbox.org |
| 16:19:11 | LinusN | surprisingly :-) |
| 16:19:19 | Rori | heh |
| 16:19:28 | Bger | LinusN see http://www.rockbox.org/irc/rockbox-20050801.txt , 18.12.47 |
| 16:20:08 | LinusN | it is a known problem??? |
| 16:20:24 | Bger | i just remember seeing it ... |
| 16:20:30 | LinusN | wow, i didn't know that :-) |
| 16:20:36 | Bger | :) |
| 16:20:38 | Rori | OK this is my current fave wps I fiddled with. Any idea what is wrong with it? |
| 16:20:39 | | Join Mxm`Pas`Bien [0] (n=flemmard@fbx.flemmard.net) |
| 16:20:40 | rasher | It's one of those known unknowns |
| 16:20:47 | Rori | oh crap can't paste it |
| 16:20:49 | Bger | maybe it'll be better to ask amiconn for details |
| 16:20:50 | Bger | anyway |
| 16:20:53 | Bger | i gotta go |
| 16:21:02 | Rori | %x1|wps/edan/e_logo.bmp|116|117|%x2|wps/edan/e_artalb.bmp|0|60|% |
| 16:21:20 | Rori | gimmie a clue on that line and I can adjust from there |
| 16:21:40 | Bger | btw, regarding this |
| 16:22:09 | Bger | i think it's better to search for wps images in the dir where the .wps file is |
| 16:22:35 | Bger | so you can make /.rockbox/wps1/1.bmp ... 2.bmp |
| 16:22:52 | Bger | bye |
| 16:22:53 | | Quit Bger ("BitchX: now in non-drowsy formula too!") |
| 16:23:41 | LinusN | Rori: it is no longer 1-9 for images, it's a-z |
| 16:24:06 | Rori | ah crap |
| 16:24:07 | LinusN | %x|a|pic.bmp|x|y| |
| 16:24:44 | rasher | so %x1|wps/edan/e_logo.bmp|116|117| becomes %x|wps/edan/e_logo.bmp|116|117| |
| 16:25:08 | Rori | hmm ok will give it a shot |
| 16:25:13 | LinusN | no, %x|a|wps/edan/e_logo.bmp|116|117| |
| 16:25:21 | Rori | k |
| 16:25:30 | LinusN | and %x|b for the next and so on |
| 16:27:02 | Rori | that works thx |
| 16:27:09 | Rori | damned syntax crapola |
| 16:27:23 | LinusN | sorry for that |
| 16:27:30 | Rori | heh |
| 16:28:38 | preglow | HCl: you'll need a proper mpeg stream parser |
| 16:29:03 | preglow | there isn't just one long mp3 stream in the file |
| 16:29:08 | preglow | it's segmented over the entire file |
| 16:29:08 | preglow | afaik |
| 16:30:52 | LinusN | we *could* adapt the mp3 codec to accept multiple sync errors so it skips the video data and syncs on the audio data |
| 16:31:24 | LinusN | provided it is segmented on frame boundaries... |
| 16:31:33 | LinusN | which i doubt |
| 16:32:05 | preglow | haha |
| 16:32:14 | preglow | or we could make a demuxer |
| 16:32:18 | preglow | and do the job properly |
| 16:32:30 | LinusN | sure, would be somewhat cool |
| 16:32:38 | LinusN | but how useful is it? |
| 16:32:43 | preglow | not at all, actually |
| 16:32:44 | preglow | heh |
| 16:32:46 | preglow | but would be cool |
| 16:33:24 | LinusN | in fact, one could do a demuxer as a plugin |
| 16:33:34 | LinusN | for the fun of it |
| 16:34:35 | preglow | hmm |
| 16:34:47 | preglow | it would fit into my scheme of allowing the codecs to load their own data |
| 16:35:09 | preglow | LinusN: what would be cool would be allowing plugins to load a codec |
| 16:35:20 | LinusN | absolutely |
| 16:35:30 | preglow | LinusN: then we could make a demuxer as a plugin, then just having it load a codec |
| 16:35:53 | preglow | but this is all talk on my side, i'm not too interested :) |
| 16:35:53 | LinusN | transcode.rock :-) |
| 16:35:55 | preglow | haha |
| 16:35:55 | preglow | yes |
| 16:36:00 | preglow | that would be nice |
| 16:37:53 | | Quit Maxime (Read error: 110 (Connection timed out)) |
| 16:39:58 | preglow | hmmm |
| 16:39:59 | linuxstb_ | I've written various MPEG demuxing tools (but mainly for transport streams). But it would have to be done outside the codec - we don't want to waste memory buffering video that we will just be discarding later. |
| 16:40:12 | preglow | 'course |
| 16:40:25 | linuxstb_ | But I would very much like to see Rockbox do that. |
| 16:40:28 | preglow | we'll need to allow codecs to load their own data sooner or later |
| 16:40:31 | preglow | for streaming codecs |
| 16:40:41 | preglow | and there's nothing wrong in allowing a codec to have several loaders |
| 16:40:50 | | Join leftright [0] (n=d4406110@labb.contactor.se) |
| 16:40:57 | preglow | ehh, non-streaming codecs |
| 16:41:25 | leftright | linuxstb: how's sudoku coming on ? :) |
| 16:41:40 | | Join noC|andY`fRa [0] (i=andy@dsl-084-058-141-169.arcor-ip.net) |
| 16:41:52 | linuxstb_ | leftright: It's about ready to commit - I'll have a final clean up when the feature freeze is over. |
| 16:42:04 | preglow | LinusN: is there some way to force a struct to appear as the first thing in a binary image? |
| 16:42:10 | leftright | can't wait, love the game |
| 16:42:19 | preglow | LinusN: perhaps stuffing it in a separate section on forcing that first? |
| 16:42:24 | LinusN | preglow: yes |
| 16:42:31 | LinusN | that's how |
| 16:42:40 | preglow | simple way of extending the plugins |
| 16:42:47 | preglow | and still having it be a binary image |
| 16:43:01 | LinusN | or you can force the linker to use a specific section from a specific .o file first |
| 16:43:34 | leftright | any plans to make the .cfg files more accessable ?, i.e. quick menu ? |
| 16:43:48 | LinusN | no |
| 16:43:50 | LinusN | no plans |
| 16:44:04 | leftright | thats a shame, |
| 16:44:13 | LinusN | that doesn't mean that it won't happen |
| 16:44:26 | leftright | seeing as cfg files are used frequently to change settings |
| 16:44:31 | LinusN | if a patch pops up, we might just as well commit it |
| 16:44:45 | preglow | linuxstb_: how hard is demuxing? |
| 16:44:59 | LinusN | in fact, there are very few real plans in rockbox in general |
| 16:46:38 | | Join Pieter__ [0] (i=Pieter@pieter.student.utwente.nl) |
| 16:46:48 | Pieter__ | hello |
| 16:46:54 | leftright | I need to find a bribeable coder :) |
| 16:47:13 | Pieter__ | did anyone else notice the ondio swapping the left and right channels when recording? |
| 16:47:18 | preglow | yes |
| 16:47:20 | preglow | amiconn did |
| 16:47:22 | Pieter__ | ok |
| 16:47:35 | Pieter__ | just noticed - recorded a piece where there were lightbulbs thrown on the left side |
| 16:47:40 | LinusN | it's a general archos issue |
| 16:47:42 | Pieter__ | they appeared on the right when listening back :) |
| 16:47:48 | Pieter__ | i'll just swap the channels back |
| 16:48:05 | LinusN | many archos devices have the line in channels swapped in the connector |
| 16:48:13 | preglow | good engineering |
| 16:49:01 | LinusN | especially the recv1, where the connector is soldered by hand with two wires |
| 16:49:08 | Pieter__ | eh |
| 16:49:21 | Pieter__ | guess there's no way to add a 'swap channels when recording' feature? ;) |
| 16:49:25 | preglow | nope |
| 16:49:27 | LinusN | no |
| 16:49:28 | preglow | not without hacking the mas |
| 16:49:58 | Pieter__ | hehe, thought so.. ok |
| 16:50:53 | Pieter__ | i'll just swap the channels so people will stop wondering why they hear the light bulbs on the wrong side :) |
| 16:51:20 | Pieter__ | (those things make wonderful noises when thrown at the floor ;)) |
| 16:51:37 | LinusN | gotta go, cu all |
| 16:51:39 | | Part LinusN |
| 16:52:09 | linuxstb_ | preglow: Demuxing isn't hard. Seeking in the file will be hard. |
| 16:53:02 | preglow | how's that handled, then? |
| 16:53:56 | linuxstb_ | Like VBR MP3 files I think - i.e. you guess. DVD program streams have extra seek infomation (so-called navigation packets) inserted in them. But "normal" MPEG programs streams don't. |
| 16:54:20 | preglow | bah |
| 16:54:24 | preglow | what were people thinking |
| 16:54:29 | linuxstb_ | One advantage of program streams is that audio stream is encapsulated into "PES" (packetized elementary stream) packets - each with a timestamp in the header. |
| 16:56:38 | linuxstb_ | The demuxing software I've written has just been for off-line extraction of the elementary streams - not for use in a player application. So I haven't had to worry about seeking. |
| 16:57:21 | preglow | oh well |
| 16:57:26 | preglow | all i want is a wav writer :P |
| 16:59:42 | preglow | brb |
| 16:59:42 | Pieter__ | hmm, audacity doesn't like big recordings :( |
| 16:59:49 | preglow | audacity doesn't like being used |
| 17:00 |
| 17:00:00 | Pieter__ | no, so it seems |
| 17:00:04 | Pieter__ | can't open a 2 hour mp3 file in it |
| 17:00:15 | | Quit ashridah ("sleep") |
| 17:00:22 | Pieter__ | or i can, but it takes an hour, then clicking anything produces nothing but lots of swapping :p |
| 17:02:03 | | Join webguest46 [0] (n=53afb0c2@labb.contactor.se) |
| 17:04:40 | preglow | audio editors that can't handle large files without loading them all into "ram" are pretty much unusable |
| 17:08:19 | Pieter__ | yeah, so it seems.. i haven't had the problem before, but i've never used this big files |
| 17:08:31 | Pieter__ | usually i could at least half way create a new file |
| 17:09:22 | Pieter__ | by the way, is there an easy fix for the ondio battery life problem thing? mine gets rather hot and doesn't last very long on it's batteries :( |
| 17:10:23 | | Part leftright |
| 17:19:25 | | Quit webguest46 ("CGI:IRC") |
| 17:22:09 | | Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU) |
| 17:32:14 | | Quit Rori () |
| 17:38:28 | [IDC]Dragon | Pieter__: only changing the LTC3440 helps |
| 17:39:20 | amiconn | [IDC]Dragon: Still wanting audible ff/rw? I don't care about that feature... |
| 17:39:41 | preglow | i'd love it |
| 17:40:18 | preglow | but do you think it's possible to find out whether a bit shift has occured in a frame by looking for the sync bits in the mpeg frame? |
| 17:46:05 | amiconn | The sync bits alone aren't very reliable |
| 17:46:36 | preglow | how come? |
| 17:46:37 | amiconn | We'd need to walk the data stream and check all headers |
| 17:47:01 | amiconn | We know which parameters are fixed and so we know which bits must be fixed |
| 17:47:01 | preglow | you'd need to check everything coming out of the mas, yes |
| 17:47:14 | amiconn | No, not everything |
| 17:47:25 | preglow | depends on when a bit shift error can occur |
| 17:47:50 | preglow | but the header should suffice |
| 17:48:03 | amiconn | We just have to search for the first frame header. Then we know how long that frame is and here where the next frame header should occur |
| 17:48:04 | preglow | but why isn't just the sync bits enough? they're constant |
| 17:48:32 | amiconn | Yes, but chances are high you won't notice a single bit shift by just the sync bit |
| 17:48:35 | amiconn | +s |
| 17:49:11 | [IDC]Dragon | Luke Framewalker, as I said |
| 17:49:16 | preglow | why not? |
| 17:49:22 | amiconn | Well, perhaps it would be reliable enough, but we'll need to find the first header anyway |
| 17:49:26 | preglow | they'll all be displaced |
| 17:49:40 | preglow | yes, and that's done by checking for the sync bits |
| 17:49:51 | amiconn | We have an advantage - the mas gives us the last header it decoded/encoded via i2c, so we know what to search for |
| 17:49:58 | [IDC]Dragon | my rvfmux tool has a frame walker |
| 17:50:36 | preglow | amiconn: yeah, but there's no point in looking for all that when you can save cpu in only looking for sync |
| 17:50:42 | amiconn | preglow: You can't find a header just by looking for the sync bit sequence. There are sometimes sequences of 0xFF bytes within frames |
| 17:50:59 | preglow | amiconn: that shouldn't be, that's the entire point of the sync bits |
| 17:51:09 | amiconn | It's definitely the case |
| 17:51:12 | preglow | ahh, yes |
| 17:51:17 | preglow | ff bytes are ok |
| 17:51:23 | preglow | sync bits are eleven bits |
| 17:51:27 | amiconn | Believe me, I've looked at megabytes of mp3 data with my hex editor |
| 17:51:32 | preglow | not eight |
| 17:51:41 | preglow | and can be distributed however they like among two bytes |
| 17:52:03 | preglow | as long as they're in sequence, of course |
| 17:52:07 | amiconn | If no bitshift occured, they are aligned always the same way |
| 17:52:18 | preglow | yup |
| 17:52:31 | amiconn | However, that still doesn't help because sequences of 0xff can occur within frames |
| 17:52:40 | preglow | 0xff doesn't matter, that's just eight bits |
| 17:52:54 | amiconn | *sequences* of 0xff |
| 17:53:03 | preglow | that's extremely weird |
| 17:53:13 | amiconn | It's not |
| 17:53:15 | preglow | can't possibly imagine why they bothered with sync bits if that's the case |
| 17:53:32 | preglow | do you know where in a frame those sequences are located? |
| 17:53:35 | | Join R-S-W [0] (n=R_S_W@84-245-190-38.bpool.celox.de) |
| 17:53:51 | | Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
| 17:54:19 | amiconn | That's why all mp3 tools that don't know the exact frame header in advance check for several consecutive frames (usually >=3) if they found a maybe-header whether it is really a frame header |
| 17:55:40 | | Join Sucka`away [0] (n=NNSCRIPT@81.156.157.185) |
| 17:56:23 | | Nick Sucka`away is now known as Sucka (n=NNSCRIPT@81.156.157.185) |
| 17:56:53 | amiconn | [IDC]Dragon: Any ideas how to integrate such a framewalker into the rockbox architecture? |
| 17:56:54 | preglow | well, that does indeed defeat the entire purpose of the sync bits |
| 17:57:04 | | Nick Mxm`Pas`Bien is now known as Maxime (n=flemmard@fbx.flemmard.net) |
| 17:57:08 | | Nick Maxime is now known as Maxime` (n=flemmard@fbx.flemmard.net) |
| 17:57:35 | amiconn | preglow: I opened the first arbitrary mp3 file, looked at the first frame - there's a 0xff 0xff sequence in it |
| 17:57:47 | preglow | then you'll indeed need to look for the entire header |
| 17:58:22 | Pieter__ | [IDC]Dragon: i can't do that.. oh well :P |
| 18:00 |
| 18:00:50 | preglow | amiconn: but are you going to try to fix this before 2.5? |
| 18:02:42 | amiconn | I don't think this can be implemented quick enough to justify holding back 2.5 |
| 18:04:00 | amiconn | Interesting... waiting for /RTW to become high before entering the loop again made the error occur earlier... |
| 18:04:24 | preglow | amiconn: btw, you sure that 0xff 0xff sequence isn't the sync bit sequence? |
| 18:04:33 | amiconn | Yes, definitely |
| 18:04:39 | preglow | amiconn: you'd see a 0xff 0xff sequence in all frames for quite ordinary files |
| 18:04:49 | amiconn | The sync can't be 0xff 0xff |
| 18:05:00 | amiconn | The second byte must be != 0xff |
| 18:05:10 | preglow | no, but sync bits + layer 1 + mpeg version 1 + not protected file == the two first bytes of nearly all mpeg files |
| 18:05:22 | preglow | or mpeg frames, i mean |
| 18:05:31 | amiconn | The mas only records layer 3 |
| 18:05:31 | preglow | and that equals 0xff 0xff |
| 18:05:37 | preglow | ahh, i mean layer 3, sorry |
| 18:06:21 | amiconn | Layer 3 is 01 |
| 18:06:26 | amiconn | Layer 1 is 11 |
| 18:06:29 | preglow | yes, quite |
| 18:06:30 | preglow | ignore me |
| 18:06:41 | amiconn | http://www.rockbox.org/docs/mpeghdr.html |
| 18:06:51 | preglow | i know, i'm just confused |
| 18:06:54 | preglow | i'll go attend to my baking again |
| 18:07:21 | | Quit R-S-W () |
| 18:08:02 | amiconn | Archos recorded frames always start with 0xfffa or 0xfff2 |
| 18:08:08 | amiconn | (we do enable crc protection) |
| 18:08:35 | preglow | but you don't know which part of the frame you find the 0xff 0xff sequence in? |
| 18:09:04 | amiconn | I don't know much about the internals of a frame. It was around the middle |
| 18:09:27 | preglow | hrmph |
| 18:10:52 | amiconn | This is a 192 kbps frame which is 626 bytes long. 0xffff occurs there at position 382 |
| 18:11:07 | amiconn | (position 0 being start of header) |
| 18:11:28 | * | [IDC]Dragon got back |
| 18:11:57 | [IDC]Dragon | I can confirm the mpeg audio suffers from so-called start code emulation |
| 18:12:29 | [IDC]Dragon | meaning, the payload may (by chance) look like a frame header |
| 18:12:48 | [IDC]Dragon | [17:56] <amiconn> [IDC]Dragon: Any ideas how to integrate such a framewalker into the rockbox architecture? |
| 18:12:56 | *** | Saving seen data "./dancer.seen" |
| 18:12:58 | [IDC]Dragon | perhaps as a state machine? |
| 18:13:15 | [IDC]Dragon | we're touching the bytes anyway |
| 18:13:27 | preglow | [IDC]Dragon: is this thanks to bad planning from the mpeg people or bad implementations? |
| 18:13:48 | [IDC]Dragon | the scpecification allows it |
| 18:14:05 | preglow | marvelous |
| 18:16:46 | amiconn | [IDC]Dragon: Where are we touching the recorded bytes? (except for saving them) |
| 18:17:22 | amiconn | And how do you mean as a state machine? I'm thinking about the way to integrate it. |
| 18:17:31 | amiconn | Should the mpeg thread do the check? |
| 18:17:40 | amiconn | Do we need a separate thread? |
| 18:18:40 | amiconn | And finally, for your beloved feature, the framewalker would need to run for playback as well. That won't work with the current approach of swapping the main buffer |
| 18:19:58 | [IDC]Dragon | I know |
| 18:20:03 | amiconn | Audible ff/rw will still be hard even with a frame walker. It's only simple to walk forward, backward is tedious |
| 18:20:21 | [IDC]Dragon | that, too |
| 18:20:23 | | Nick solexx_ is now known as solexx (n=jrschulz@d155158.adsl.hansenet.de) |
| 18:20:24 | amiconn | And for ff, it has to be fast enough to cope with the speed |
| 18:20:45 | [IDC]Dragon | well, Archos does it |
| 18:21:00 | amiconn | Yes, and I don't know why (for playback) |
| 18:21:17 | [IDC]Dragon | stop mobbing that feature! |
| 18:21:21 | preglow | haha |
| 18:21:23 | amiconn | I prefer silent ff/rw over unidentifiable twittering noises |
| 18:21:36 | preglow | how does archos ffrw compare to irivers? |
| 18:21:42 | preglow | iriver's audible ffrw sounds pretty nice |
| 18:21:50 | preglow | and very nice for vorbis files |
| 18:21:54 | [IDC]Dragon | the first config option I'm voting for, instead of against |
| 18:22:12 | amiconn | preglow: I never tried it |
| 18:22:23 | [IDC]Dragon | how to implement: yes, I ment the byte saving |
| 18:22:31 | [IDC]Dragon | meant |
| 18:23:13 | amiconn | I think we would need to walk directly behind the mas writing. When saving it is too late |
| 18:24:01 | amiconn | Perhaps we could even do that within the transfer isr |
| 18:24:08 | | Quit bobTHC ("Smoke Weed Every Day !") |
| 18:24:08 | amiconn | (for recording) |
| 18:25:11 | amiconn | It could also count the frames if it walks them anyway |
| 18:25:45 | amiconn | No resort to estimation from the recording time if the mas counter saturates |
| 18:26:07 | amiconn | Hmmmmm |
| 18:26:33 | [IDC]Dragon | yes, that's what I mean, process the header while grabbing the bytes off the hardware |
| 18:26:50 | [IDC]Dragon | but better have v2.5 released first |
| 18:26:55 | amiconn | There won't be a header within every DMA block |
| 18:27:12 | amiconn | we'll need a byte counter for the position within the frame |
| 18:27:13 | [IDC]Dragon | that's what the state machine is for |
| 18:29:05 | [IDC]Dragon | we'll have a performance peak during the header, else we're ust counting for the next header |
| 18:29:29 | amiconn | Today's test recording got a +1 bitshift after ~90 minutes. That's with the check for /rtw going inactive before looping |
| 18:31:02 | [IDC]Dragon | hm, my state machine code is not in rvf_mux, but in the DirectShow filter |
| 18:31:16 | [IDC]Dragon | which is closed source |
| 18:31:45 | amiconn | Is there a special reason for the directshow filter being closed source? |
| 18:31:50 | amiconn | (just wondering) |
| 18:32:04 | [IDC]Dragon | anyway, it should be much simpler for the MAS |
| 18:32:17 | [IDC]Dragon | yes, too much overlap with my work |
| 18:36:43 | amiconn | I guess that a frame walker could actually simplify many other parts of the recording engine |
| 18:37:02 | [IDC]Dragon | now we're talking ;-) |
| 18:37:08 | amiconn | Today, we search for frame boundaries when splitting etc |
| 18:37:20 | [IDC]Dragon | I gotta leave |
| 18:37:23 | amiconn | The frame walker would store the last frame boundary position |
| 18:38:30 | | Quit Bagder (Read error: 104 (Connection reset by peer)) |
| 18:38:34 | [IDC]Dragon | the state machine in essence works like this: |
| 18:38:57 | [IDC]Dragon | - you present it with an arbitrary amount of bytes |
| 18:39:12 | [IDC]Dragon | - the state decides what'll happen next |
| 18:39:38 | [IDC]Dragon | e.g. at the init state, you just memchr for an 0xFF |
| 18:39:55 | [IDC]Dragon | when found, you're in the next state |
| 18:40:08 | [IDC]Dragon | and verify byte 2 of the header |
| 18:40:30 | [IDC]Dragon | if no match, go back into scan state |
| 18:40:58 | [IDC]Dragon | then verify byte 3, processing the relevant bits |
| 18:41:25 | [IDC]Dragon | and so on, until the distance to the nect frame is known |
| 18:41:45 | [IDC]Dragon | then you're in a "skip payload" state |
| 18:41:57 | [IDC]Dragon | counting off until the next header |
| 18:42:06 | | Quit linuxstb_ ("CGI:IRC") |
| 18:43:03 | amiconn | We don't even need to search for the first header at the start of the recording. We know it must be the first thing |
| 18:43:18 | [IDC]Dragon | an extra ontop condition would be to only changed from an "unsynced" to a "synced" state when seen eg. 3 headers with the right spacing |
| 18:43:37 | amiconn | ...and if we loose sync, we need to restart recording anyway |
| 18:43:41 | [IDC]Dragon | well, that was the general case. |
| 18:43:54 | amiconn | ...meaning we do again know where our first new header must be |
| 18:43:55 | [IDC]Dragon | simplifications apply here |
| 18:44:12 | [IDC]Dragon | and we know sample rate, etc |
| 18:44:20 | [IDC]Dragon | no need to extract that |
| 18:44:29 | amiconn | We don't know the sample rate in case of s/pdif |
| 18:44:44 | [IDC]Dragon | oh |
| 18:44:55 | [IDC]Dragon | well |
| 18:45:14 | amiconn | When recording from s/pdif the mas auto-syncs to the input, and ignores the setting |
| 18:45:26 | [IDC]Dragon | perhaps we can assume it being constant |
| 18:45:41 | amiconn | We know a lot of things, and we can get the header template from the mas itself |
| 18:45:45 | [IDC]Dragon | taking that I2C header |
| 18:45:45 | amiconn | (via i2c) |
| 18:45:51 | amiconn | :) |
| 18:46:14 | [IDC]Dragon | just for a start, I woudn't use it while running |
| 18:46:28 | [IDC]Dragon | most likely it is outdated |
| 18:46:28 | amiconn | Why not? |
| 18:46:37 | amiconn | Yes, it's only a template |
| 18:46:45 | [IDC]Dragon | we don'tknow which frame it really belongs to |
| 18:46:56 | amiconn | bitrate and mode extension can change |
| 18:47:19 | [IDC]Dragon | but then a restart probably woudn't hurt |
| 18:47:39 | [IDC]Dragon | bitrate changes all the time |
| 18:47:58 | [IDC]Dragon | I rather meant sample rate |
| 18:48:13 | amiconn | Version, layer, protection, channel modecopyright, original bit, emphasis, padding and private bit are fixed |
| 18:48:36 | amiconn | Sample rate should be fixed too |
| 18:48:43 | amiconn | (within one recording) |
| 18:49:00 | amiconn | padding is simple - *all* mas encoded frames are unpadded |
| 18:49:39 | [IDC]Dragon | V said the MAS has an undocumented feature, doing CBR |
| 18:49:56 | [IDC]Dragon | but in a dumb way: it pads like crazy |
| 18:50:29 | amiconn | Yes, I read that note about the AV3x0 firmware update enabling cbr |
| 18:50:43 | amiconn | I wonder how this mode is enabled... |
| 18:50:45 | [IDC]Dragon | a waste of diskspace |
| 18:51:11 | * | [IDC]Dragon really gotta leave |
| 18:51:16 | [IDC]Dragon | cu |
| 18:51:25 | | Quit [IDC]Dragon ("CGI:IRC") |
| 19:00 |
| 19:22:03 | | Quit dpassen1 (Read error: 110 (Connection timed out)) |
| 19:23:08 | | Join Dan [0] (i=Bollocks@tredwell.plus.com) |
| 19:23:11 | Dan | hey |
| 19:23:42 | Dan | is there a max volume setting on rockbox? |
| 19:24:08 | Dan | because rockbox is a hell of allot quieter than the iriver firmware4 |
| 19:30:40 | crwl | just turn bass / treble down, rockbox doesn't limit them like iriver firmware does |
| 19:32:28 | Dan | hmm |
| 19:32:35 | Dan | still really quiet |
| 19:32:37 | Dan | :/ |
| 19:46:36 | | Join Lear [0] (n=chatzill@h36n10c1o285.bredband.skanova.com) |
| 19:48:39 | | Quit markun () |
| 20:00 |
| 20:01:04 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 20:12:52 | preglow | Dan: replaygain on? _completely_ certain bass and treble is zero? |
| 20:12:58 | *** | Saving seen data "./dancer.seen" |
| 20:19:23 | | Quit Dan (Read error: 110 (Connection timed out)) |
| 20:31:50 | | Part nibbler ("Leaving") |
| 20:33:09 | | Join tomal [0] (n=tomek@155-moo-7.acn.waw.pl) |
| 20:35:50 | | Join solexx_ [0] (n=jrschulz@d098198.adsl.hansenet.de) |
| 20:41:07 | | Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU) |
| 20:42:52 | | Join Seed [0] (i=ben@l192-117-115-168.broadband.actcom.net.il) |
| 20:47:50 | | Quit solexx (Read error: 110 (Connection timed out)) |
| 20:58:20 | | Join Yono [0] (n=Yono@69-169-174-248.bflony.adelphia.net) |
| 20:59:08 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
| 21:00 |
| 21:12:41 | | Quit tomal ("leaving") |
| 21:22:10 | | Quit Maxime` () |
| 21:25:13 | | Join Maxime [0] (n=flemmard@fbx.flemmard.net) |
| 21:32:41 | | Quit tvelocity ("Leaving") |
| 21:34:30 | | Quit Yono ("Download Gaim: http://gaim.sourceforge.net/") |
| 21:46:04 | | Quit t0mas (Read error: 104 (Connection reset by peer)) |
| 21:46:18 | | Join t0mas [0] (n=Tomas@unaffiliated/t0mas) |
| 21:47:04 | | Quit t0mas (Read error: 104 (Connection reset by peer)) |
| 21:55:50 | | Join t0mas [0] (n=Tomas@unaffiliated/t0mas) |
| 22:00 |
| 22:01:53 | | Quit t0mas (Read error: 104 (Connection reset by peer)) |
| 22:13:02 | *** | Saving seen data "./dancer.seen" |
| 22:14:03 | | Quit Lear ("Chatzilla 0.9.68.5.1 [Firefox 1.4/undefined]") |
| 22:25:34 | | Join travis [0] (n=travis@ACC20E81.ipt.aol.com) |
| 22:25:42 | travis | freenode-connect is being nosey! |
| 22:26:13 | | Quit travis (Remote closed the connection) |
| 22:27:01 | | Join travis95 [0] (n=travis95@ACC20E81.ipt.aol.com) |
| 22:27:05 | travis95 | freenode-connect is being nosey! |
| 22:27:52 | travis95 | Zagor is being nosey! |
| 22:28:06 | Zagor | with all right, since you are acting like a bot |
| 22:31:08 | | Quit travis95 (Client Quit) |
| 22:51:24 | crwl | horrible |
| 22:56:36 | | Quit dpassen1 () |
| 22:59:17 | | Quit matsl (Read error: 104 (Connection reset by peer)) |
| 23:00 |
| 23:00:51 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
| 23:16:47 | | Join unL33T [0] (n=8e9c01df@labb.contactor.se) |
| 23:17:10 | | Quit unL33T (Client Quit) |
| 23:17:22 | | Join Moos [0] (i=DrMoos@m50.net81-66-159.noos.fr) |
| 23:17:24 | | Join unL33T2 [0] (n=8e9c01df@labb.contactor.se) |
| 23:18:22 | unL33T2 | hey i have a problem when trying to use the regular iRiver firmware on my iRiver HP-120 ... anyone wanna try to help me with it =) |
| 23:19:43 | unL33T2 | basically if I select a song through the artist or album or one of the other sorted menus it just doesn't play it and just closes the menu and goes back to whatever was there before but if I go through the folder browser menu anything I select works fine.... I've tried rebuilding the database with MoodLogic a couple times ... last I'm thinking is a reformat of the player but I'd rather not as it is also my primary music storage |
| 23:20:23 | unL33T2 | rockbox still works normally but I'm still not sure if I like it better than the regular firmware so I'm still switching between both |
| 23:21:24 | Zagor | i think there was a bug in the bootloader causing something like that. are you using the latest version? |
| 23:23:30 | unL33T2 | I downloaded the 1.65 firmware from the links provided in the faq and ran the patching program ... unless the bootloader is something other than the hacked firmware... |
| 23:23:47 | unL33T2 | I'm new to using so kind of dumb |
| 23:24:08 | unL33T2 | or does the bootloader depend on the version of rockbox I have? |
| 23:25:03 | Zagor | no. but the bootloader has been updated since the bug was found. try grabbing the 1.65 firmware and patch it again. |
| 23:25:32 | amiconn | I wonder whether it would be a good idea to display the bootloader version within rockbox |
| 23:25:44 | amiconn | (somewhere in the debug menu) |
| 23:25:55 | Zagor | might be a good idea, yes |
| 23:26:00 | unL33T2 | i just downloaded and patched it two days ago |
| 23:26:12 | Zagor | unL33T2: ok, doesn't sound like that then |
| 23:26:35 | amiconn | There's an orphaned "View HW info" menu item in the iriver debug menu... |
| 23:27:01 | unL33T2 | and what should that tell me? |
| 23:27:19 | amiconn | That was directed to Zagor (and other devs) |
| 23:27:29 | unL33T2 | oh sorry :P |
| 23:28:10 | unL33T2 | hmm I just noticed that when I turn on my iriver it says H-100 series (which I think it always said) but the player is an iHP-120 ... I dunno if that is significant. |
| 23:30:39 | Zagor | you didn't use the wrong model firmware, did you? |
| 23:31:11 | unL33T2 | positive I didnt but I'll verify the filename |
| 23:31:49 | Zagor | oh, my 140 says "H-100 series" too, so don't worry |
| 23:31:56 | unL33T2 | ok |
| 23:32:27 | unL33T2 | I've tried reflashing to the stock firmware as well ... both 1.63 and 1.65 and have the same problem |
| 23:32:50 | unL33T2 | which is why i suspect that it is a problem with the database but I dont know how to fix it |
| 23:32:53 | preglow | Seed: still no news as to fixing libmpcdec for rockbox, i imagine? :P |
| 23:33:26 | amiconn | iriver firmware is dumb... it told me "low battery" when I wanted to check what it says on boot. Rockbox still runs happily... |
| 23:33:51 | unL33T2 | all my firmwares I have are all ihp_120.hex |
| 23:34:05 | preglow | well, iriver firmware has a safety check to avoid angry users... |
| 23:34:14 | * | amiconn wonders what this mpeg frame checker is doing with his ram... |
| 23:34:16 | preglow | which is perfectly understandable |
| 23:35:11 | preglow | unL33T2: what version bootloader do you have? it says so first thing when you turn the unit on |
| 23:35:24 | amiconn | preglow: I'd rather like to use the full capacity of the battery... |
| 23:35:51 | unL33T2 | "rockboot version 2" |
| 23:36:22 | unL33T2 | is there a way to pause it during boot so I can see all that info it provides? |
| 23:37:55 | amiconn | Oh, that's old... current bootloader is v5. |
| 23:38:04 | amiconn | Hmm, the wiki contains v2 - argh! |
| 23:38:04 | | Quit noC|andY`fRa (Read error: 104 (Connection reset by peer)) |
| 23:38:39 | rasher | Excellent |
| 23:38:44 | unL33T2 | that is probably where I got it |
| 23:38:48 | rasher | I have v5.. hang on |
| 23:39:00 | unL33T2 | ok thanks |
| 23:39:22 | unL33T2 | is it the same process to install it? just patch the firmware with a newer program? |
| 23:39:34 | rasher | Yes |
| 23:40:04 | | Join DrMoos [0] (i=DrMoos@m50.net81-66-159.noos.fr) |
| 23:40:06 | unL33T2 | cool |
| 23:40:09 | | Quit Moos (Read error: 104 (Connection reset by peer)) |
| 23:40:15 | preglow | amiconn: sure, but i bet iriver doesn't trust their ordinary userbase to do so |
| 23:40:29 | preglow | oh shit |
| 23:40:31 | preglow | i didn't think of that |
| 23:40:35 | | Nick DrMoos is now known as Moos (i=DrMoos@m50.net81-66-159.noos.fr) |
| 23:40:45 | amiconn | preglow: ? |
| 23:40:50 | preglow | wiki and old fwpatcher |
| 23:40:58 | preglow | which is kind of nasty |
| 23:41:26 | amiconn | Obviously google didn't like the IriverBoot page |
| 23:42:10 | preglow | v5 should work perfectly for you |
| 23:42:28 | unL33T2 | cool I just have to get it =) |
| 23:43:13 | rasher | Hrm, is the last one "20050722? |
| 23:43:16 | rasher | (v5) |
| 23:43:44 | preglow | gimme a sec |
| 23:44:09 | rasher | Hrm.. how do I delete an attachment again? |
| 23:44:46 | preglow | what the hell? |
| 23:44:53 | preglow | suddenly the bootloader uses 10 seconds to get going |
| 23:44:58 | preglow | i have to stop booting the iriver fw |
| 23:45:30 | | Join ashridah [0] (i=ashridah@220-253-122-152.VIC.netspace.net.au) |
| 23:46:09 | amiconn | rasher: By moving it to Trash/TrashAttachment, but why do you want to delete it? |
| 23:46:22 | rasher | well, what do I call the bootloader.bins ? |
| 23:46:27 | rasher | h120 / h100 |
| 23:46:41 | rasher | ccurrently there's just "bootloader.bin" |
| 23:47:35 | | Join DrMoos [0] (i=DrMoos@m50.net81-66-159.noos.fr) |
| 23:47:56 | amiconn | Ah, that problem... |
| 23:48:24 | | Quit Moos (Read error: 104 (Connection reset by peer)) |
| 23:50:41 | rasher | What do I do? |
| 23:53:01 | unL33T2 | dunno |
| 23:53:13 | rasher | I haaaave the file... where to put it? |
| 23:56:17 | unL33T2 | I dont even know what .bin files are used for .... |
| 23:56:27 | rasher | fwpatcher.exe updated |
| 23:57:39 | unL33T2 | so this link should be to the correct one: http://www.rockbox.org/twiki/pub/Main/IriverBoot/fwpatcher.exe ? |
| 23:57:40 | rasher | think I'll leave it to Linus to upload the .bins |
| 23:57:42 | rasher | yes |
icon identifies that the person is a core developer (has commit access).