00:17:39 | | Nick _orange_ is now known as orange_away (~mdw@orange.active.supporter.pdpc) |
00:18:10 | | Join pfavr [0] (pfavr@t2o902p46.telia.com) |
00:19:36 | | Join Naked [0] (naked@naked.iki.fi) |
00:24:47 | | Quit pfavr ("ChatZilla 0.9.52B [Mozilla rv:1.6/1]") |
00:33:25 | | Quit Hadaka (Read error: 111 (Connection refused)) |
00:40:31 | | Quit apemanttt (Read error: 110 (Connection timed out)) |
00:42:47 | | Quit Naked (Remote closed the connection) |
00:43:45 | Masskiller | does anyone know how i can like......test my usb to see if it's working |
00:44:13 | Masskiller | because when i plug it into windows it says "usb device malfunctioned", now i have it apart and my dad (an electrician) is going to do whatever i tell him |
00:44:14 | Masskiller | lol |
00:54:33 | | Join track [0] (~74d57721@ACBFE3D1.ipt.aol.com) |
00:54:36 | | Quit track (Client Quit) |
00:59:59 | | Join top_bloke [0] (~ekolb_pot@dsc01-chc-il-209-109-240-127.rasserver.net) |
01:00 |
01:02:55 | | Join Naked [0] (naked@naked.iki.fi) |
01:04:52 | | Nick Naked is now known as Hadaka (naked@naked.iki.fi) |
01:06:18 | | Quit AciD ("www.acid.ht.st") |
01:32:11 | | Quit Nibbler (Read error: 54 (Connection reset by peer)) |
01:36:19 | | Join wake [0] (~wake@69.158.0.45) |
01:43:42 | *** | Saving seen data "./dancer.seen" |
01:53:21 | | Join apemanttt [0] (apemanttt@64.213.222.81) |
02:00 |
02:10:41 | | Join monkey666 [0] (monkey@1Cust36.tnt1.mount-vernon.wa.da.uu.net) |
02:18:02 | | Quit monkey666 () |
02:32:02 | | Part amiconn |
02:35:03 | | Quit apemanttt (Read error: 110 (Connection timed out)) |
02:45:18 | | Quit Masskiller () |
03:00 |
03:01:05 | | Quit mecraw_ ("Trillian (http://www.ceruleanstudios.com)") |
03:17:03 | | Join Nibbler [0] (~nibbler@port-212-202-73-124.reverse.qsc.de) |
03:21:36 | | Quit scott666 ("i'll be back...eventually...") |
03:29:39 | | Nick orange_away is now known as _orange_ (~mdw@orange.active.supporter.pdpc) |
03:43:43 | *** | Saving seen data "./dancer.seen" |
03:53:58 | | Join apemanttt [0] (apemanttt@64.213.222.81) |
04:00 |
04:05:18 | | Join diddystar5 [0] (lee@IC62.library.oregonstate.edu) |
04:27:59 | | Quit Nibbler (Read error: 54 (Connection reset by peer)) |
04:43:35 | | Quit top_bloke (Read error: 54 (Connection reset by peer)) |
04:50:44 | | Quit apemanttt (Read error: 110 (Connection timed out)) |
04:57:24 | | Quit wake ("leaving") |
05:00 |
05:04:36 | | Join scott666 [0] (scott666@c-24-245-58-245.mn.client2.attbi.com) |
05:42:24 | | Part diddystar5 ("Leaving") |
05:43:45 | *** | Saving seen data "./dancer.seen" |
05:44:03 | | Quit Ka__ (Read error: 113 (No route to host)) |
05:45:02 | | Join Ka__ [0] (~tkirk@65.216.194.2) |
06:00 |
06:05:42 | | Join Nibbler [0] (~nibbler@port-212-202-73-124.reverse.qsc.de) |
06:05:42 | | Join apemanttt [0] (apemanttt@64.213.222.81) |
06:21:20 | | Quit Nibbler (Read error: 54 (Connection reset by peer)) |
06:31:33 | | Quit apemanttt (Read error: 60 (Operation timed out)) |
07:00 |
07:26:33 | | Join amiconn [0] (~jens@pD95D1B52.dip.t-dialin.net) |
07:32:47 | | Quit elinenbe (" WOW! This IRC Client ownz! HydraIRC -> http://www.hydrairc.com <-") |
07:43:49 | *** | Saving seen data "./dancer.seen" |
07:47:14 | | Nick _orange_ is now known as orange_away (~mdw@orange.active.supporter.pdpc) |
08:00 |
08:05:08 | | Join amiconn_ [0] (~jens@pD9E7EFC4.dip.t-dialin.net) |
08:05:58 | | Join Nibbler [0] (~nibbler@port-212-202-73-124.reverse.qsc.de) |
08:06:24 | | Join apemanttt [0] (apemanttt@64.213.222.81) |
08:22:47 | | Quit amiconn (Read error: 110 (Connection timed out)) |
08:22:48 | | Nick amiconn_ is now known as amiconn (~jens@pD9E7EFC4.dip.t-dialin.net) |
08:24:13 | | Join LinusN [200] (~linus@labb.contactor.se) |
08:24:55 | LinusN | amiconn: your pc clock seems to be set in the future |
08:26:02 | amiconn | What? |
08:26:13 | LinusN | your emails are dated in the future |
08:26:53 | LinusN | i worked hard on the recording yesterday |
08:27:54 | amiconn | Hmm, my two computer clocks (on the PC as well as the amiga) are perfectly in sync with the official time (via NTP). |
08:28:09 | LinusN | weird |
08:28:34 | LinusN | maybe it's a DST thing? |
08:28:51 | amiconn | Oops, I just foud the reason: my emailer didn't notice the dst change |
08:29:12 | LinusN | ah |
08:30:52 | amiconn | I've already tested your recording improvements and noticed no more partial first frame :) |
08:32:23 | amiconn | Apparently the proper setting of the monitoring bit in mpeg_set_recording_options() fixed the need of the additional sleep() at the start of reacording. |
08:32:50 | | Quit apemanttt (Read error: 60 (Operation timed out)) |
08:33:22 | amiconn | As the CRC setting is now fixed as well, the recordings can be checked with mp3utility without requiring patching. |
08:34:14 | LinusN | nice |
08:34:16 | amiconn | With that I found that you try to fix this with first setting the mas to "pause" doesn't help here :( |
08:34:40 | LinusN | no, but i kept it anyway |
08:34:49 | amiconn | Hmm, "this" should read "incomplete last frame". |
08:35:01 | LinusN | i can't find a way to make the mas "spit out" the last part of the frame |
08:36:40 | amiconn | Perhaps it doesn't do that whatever way you choose to stop the recording. It isn't only that the last <30 bytes are missing. It seems the mas stops at an arbitrary position. |
08:37:17 | LinusN | yup |
08:37:32 | LinusN | i think it stops when i write to 7f1 |
08:38:11 | amiconn | So, the only way to get always complete frames in the file would be to search for the last frame header in memory on every save and save only up to that (but not including it). |
08:38:12 | LinusN | i made some nice logic analyzer recordings yesterday |
08:38:37 | amiconn | Did you check how the Archos fw does the recording? |
08:40:57 | LinusN | nope |
08:41:50 | amiconn | Btw: Your pause_recording() comes in handy for the recent feature request on the ml to have a "pause recording" feature. |
08:41:51 | LinusN | as far as i can see, the timing is perfect |
08:41:55 | LinusN | yes |
08:42:22 | LinusN | my next experiment is to pause and resume, and see if a frame is corrupted |
08:42:43 | amiconn | Perhaps we could remap the "new file" function to the "on" button and put "pause recording" where it would belong. |
08:43:08 | | Join matsl [0] (~matsl@dhcp102.contactor.se) |
08:43:48 | LinusN | yup |
08:44:01 | amiconn | I would suggest to combine the pause_recording and resume_recording functions the same way the mp3_play_pause works since the only difference is the line that sets/resets the bit. |
08:46:14 | amiconn | Another thing that I want to know is if the "5 cycles until the data is read" in the recording loop are really necessary. If I read the data sheet correctly, the mas already put the data on its outpur when it asserts rtw, so it should work to read immediately. |
08:46:29 | amiconn | *output |
08:50:39 | LinusN | i tried that once |
08:51:20 | amiconn | What happened then? |
08:51:56 | LinusN | some frames were corrupted occasionally |
08:55:01 | amiconn | Hmm. I think it shouldn't be necessary to wait 5 cycles, but if we do this, it may be necessary to wait until the mas deasserts rtw again (contrary to your comment) because we may be reading "too fast" if we don't. |
08:55:53 | amiconn | I will try this myself when I do the assembler loop, perhaps this evening. |
08:57:49 | amiconn | Btw: the C loop waits 14(!) clocks until it reads the data (according to the disassembly) |
08:57:51 | LinusN | it always takes 20ns for the mas to release prtw |
08:58:31 | LinusN | in my analyzer trace |
08:58:34 | amiconn | Ok, shouldn't be necessary then and could also be left out from drain_dma_buffer() |
08:58:40 | LinusN | but the data sheet says something else... |
09:00 |
09:00:14 | LinusN | so you may be right |
09:00:26 | amiconn | Hmm, according to the data sheet it sould take 90..260 ns |
09:00:30 | LinusN | yup |
09:00:51 | LinusN | we should probably wait for it, since it *may* take longer |
09:01:05 | LinusN | that could be the occasional corrupt frame |
09:01:58 | LinusN | the mas doesn't set EOD until the dma buffer is full (30 bytes) |
09:02:37 | LinusN | i have never seen a partial dma transfer |
09:03:17 | LinusN | and the silly mas sent EOD high when starting the recording, before the first frame has been encoded |
09:03:26 | LinusN | s/sent/sets/ |
09:04:11 | LinusN | and if you set PR at that point, the mas never replies |
09:04:57 | LinusN | i have also tried to set PR when EOD is low, but the mas ignores it |
09:05:54 | LinusN | you want to see the analyzer output? |
09:06:27 | amiconn | Yes, that would be interesting to compare with what the data sheet tells us. |
09:06:33 | LinusN | hang on |
09:07:10 | amiconn | I will try the two modifications (don't wait 5 cycles and wait for deassertion of prtw at the end) with my assembler loop. |
09:10:03 | | Join GDE-DeadMeat [0] (Gatekeeper@c-24-12-232-226.client.comcast.net) |
09:10:06 | GDE-DeadMeat | hey peeps |
09:10:23 | GDE-DeadMeat | does anyone here use an archos w/ their linux box? |
09:12:42 | dwihno | Analyser :O |
09:12:42 | LinusN | i do |
09:12:45 | dwihno | Everybody? :) |
09:13:30 | GDE-DeadMeat | do I need to do anything else, other than adding ISD200 and scsi disk support in the kernel? |
09:14:34 | LinusN | you have a studio? |
09:15:26 | GDE-DeadMeat | I have the jukebox 5000 |
09:15:38 | GDE-DeadMeat | picked it up cheap on e-bay |
09:17:26 | LinusN | ok, so it's not a recorder with isd300 |
09:17:40 | LinusN | you need scsi, isd200 and usb-storage |
09:17:59 | LinusN | preferably as modules |
09:19:16 | GDE-DeadMeat | is there a problem w/ compiling them into the kernel, rather than running modules? |
09:19:22 | GDE-DeadMeat | I perfer to run monolithic kernels. |
09:19:46 | LinusN | some people have reported problems |
09:20:15 | LinusN | like having to have the jukebox attached at boot to be able to recognize it later |
09:20:33 | LinusN | which kernel version? |
09:20:34 | GDE-DeadMeat | hrm... ok |
09:21:10 | | Quit matsl (Remote closed the connection) |
09:21:21 | | Nick amiconn is now known as amiconn|away (~jens@pD9E7EFC4.dip.t-dialin.net) |
09:22:45 | | Join AciD` [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
09:23:06 | dwihno | I wonder why they didn't make the ISD-200 adhere to the mass storage specification |
09:23:19 | GDE-DeadMeat | ok... generic scsi support, usb HD usb-storage support, and isd200? |
09:27:59 | | Join monkey666 [0] (monkey@1Cust57.tnt1.mount-vernon.wa.da.uu.net) |
09:29:09 | LinusN | looks good |
09:29:33 | LinusN | dwihno: maybe there was no mass-storage spec when they designed the chip? |
09:33:06 | GDE-DeadMeat | man... the kernel takes to damn long to compile in X |
09:33:07 | GDE-DeadMeat | :-( |
09:38:29 | monkey666 | i have a question about text to mp3... is there anyway faster than textaloud mp3 to convert text files into wavs or mp3s? |
09:38:48 | monkey666 | say using lang2wav and the lame encoder? |
09:40:30 | | Quit GDE-DeadMeat ("KVIrc 3.0.0-beta2 "T-Rex"") |
09:43:17 | LinusN | i have no idea, never tried it |
09:43:50 | *** | Saving seen data "./dancer.seen" |
09:51:19 | | Join GDE-DeadMeat [0] (Gatekeeper@c-24-12-232-226.client.comcast.net) |
09:51:25 | GDE-DeadMeat | ok... something is wrong. Please help |
09:51:29 | LinusN | ok |
09:51:53 | GDE-DeadMeat | I try to mount the Jukebox and I get a message saying that sda1 does not exist. |
09:52:50 | LinusN | /var/log/messages? |
09:54:13 | GDE-DeadMeat | looking |
09:54:14 | GDE-DeadMeat | just sec |
09:54:16 | GDE-DeadMeat | huge log |
09:56:16 | GDE-DeadMeat | what kinda message should I be looking for? |
09:57:24 | | Join amiconn [0] (~jens@pD9E7F146.dip.t-dialin.net) |
10:00 |
10:02:36 | LinusN | you should look for messages regarding USB |
10:03:36 | LinusN | like "kernel: Initializing USB Mass Storage driver..." |
10:05:59 | LinusN | should be last in the log |
10:06:09 | LinusN | or near the end at least |
10:07:06 | | Join apemanttt [0] (apemanttt@64.213.222.81) |
10:08:26 | GDE-DeadMeat | yeah |
10:09:24 | GDE-DeadMeat | registered new hid usb.c |
10:13:18 | LinusN | ok |
10:14:03 | LinusN | nothing else? |
10:14:34 | LinusN | do you have anything else connected to the usb bus? |
10:14:41 | GDE-DeadMeat | no, not right now. |
10:14:57 | | Quit amiconn|away (Read error: 110 (Connection timed out)) |
10:14:57 | | Nick amiconn is now known as amiconn|away (~jens@pD9E7F146.dip.t-dialin.net) |
10:19:28 | GDE-DeadMeat | something other than generic scsi support perhaps? |
10:21:54 | LinusN | what scsi options did you select in the kernel config? |
10:24:51 | GDE-DeadMeat | SCSI disk support |
10:25:03 | GDE-DeadMeat | SCSI generic Support |
10:25:16 | GDE-DeadMeat | and that's it |
10:25:19 | LinusN | sounds ok |
10:25:26 | LinusN | and the usb options? |
10:25:55 | GDE-DeadMeat | USB device filesystem |
10:26:15 | GDE-DeadMeat | EHCI HCD (USB 2.0) support |
10:26:21 | GDE-DeadMeat | OHCI HCD support |
10:26:28 | GDE-DeadMeat | UHCI HCD support |
10:26:33 | GDE-DeadMeat | USB Printer Support |
10:26:39 | GDE-DeadMeat | USB mass storage support |
10:26:50 | GDE-DeadMeat | ISD-200 USB/ATA Bridge support |
10:27:08 | GDE-DeadMeat | USB HID support |
10:27:12 | GDE-DeadMeat | and that's all for USB |
10:28:18 | LinusN | looks ok to me |
10:28:38 | LinusN | but you should see things in /var/log/messages when you insert the usb plug |
10:28:57 | LinusN | do tail -f /var/log/messages when you insert it |
10:29:15 | LinusN | which kernel version is this? |
10:29:32 | GDE-DeadMeat | 2.6.3-r1 |
10:30:25 | LinusN | pretty new stuff then |
10:30:52 | dwihno | LinusN: Perhaps! :D |
10:31:06 | GDE-DeadMeat | GRRRRRR |
10:31:10 | LinusN | ? |
10:31:16 | GDE-DeadMeat | it's times like this when I miss my moron box |
10:31:22 | GDE-DeadMeat | (read windows box) |
10:31:50 | GDE-DeadMeat | brb... gonna just reboot my damn machine |
10:31:51 | GDE-DeadMeat | :-( |
10:32:24 | | Quit GDE-DeadMeat ("KVIrc 3.0.0-beta2 "T-Rex"") |
10:34:50 | | Join GDE-DeadMeat [0] (Gatekeeper@c-24-12-232-226.client.comcast.net) |
10:35:26 | GDE-DeadMeat | same message: mount: special device /dev/sda1 does not exist. |
10:40:02 | LinusN | do you know if the usb device is even recognized by the kernel? |
10:41:02 | GDE-DeadMeat | no |
10:41:19 | GDE-DeadMeat | I thought that it should have been if I compiled in the isd-200 driver |
10:41:32 | GDE-DeadMeat | I don't really know much about USB in linux. |
10:41:46 | GDE-DeadMeat | never had a need to use usb devices until I completely left windows 2 months ago. |
10:46:20 | LinusN | i don't know about 2.6, but my 2.4.21 kernel writes a lot in the /var/log/messages log |
10:47:00 | LinusN | btw, are the device file structure the same in 2.6? |
10:47:34 | LinusN | i mean is it really /dev/sda1 or is it /dev/scsi/sda1 or something? |
10:47:52 | GDE-DeadMeat | dev/scsi/sda1 I believe |
10:48:26 | LinusN | find out where it is and mount with the correct device |
10:49:33 | GDE-DeadMeat | I searched /dev/scsi and /dev/usb but have found nothing |
10:50:59 | LinusN | how about /proc/usb? |
10:52:58 | GDE-DeadMeat | checking |
10:53:26 | GDE-DeadMeat | hrm... no such file or directory |
10:55:05 | LinusN | proc/bus/usb? |
10:55:58 | GDE-DeadMeat | there's nothing there |
10:59:41 | | Quit AciD` (Read error: 104 (Connection reset by peer)) |
11:00 |
11:03:20 | LinusN | then the usb driver didn't find the jukebox |
11:03:44 | LinusN | there must be something in the log |
11:04:34 | LinusN | amiconn|away: http://linus.haxx.se/recording/ |
11:07:45 | | Join HuwSy [0] (Huw@pc179106.eeng.liv.ac.uk) |
11:14:46 | | Part HuwSy |
11:24:25 | | Quit monkey666 (Read error: 113 (No route to host)) |
11:31:03 | | Quit GDE-DeadMeat ("KVIrc 3.0.0-beta2 "T-Rex"") |
11:43:51 | *** | Saving seen data "./dancer.seen" |
11:44:28 | | Part LinusN |
11:44:38 | | Join LinusN [200] (~linus@labb.contactor.se) |
11:55:27 | | Join GDE-DeadMeat [0] (Gatekeeper@c-24-12-232-226.client.comcast.net) |
11:55:46 | GDE-DeadMeat | LinusN: I wanted to say thank you. I finally got the Archos connected. |
11:56:02 | | Part LinusN |
11:56:06 | GDE-DeadMeat | I just compiled all scsi drivers and a lot of usb drivers. |
11:56:18 | | Join LinusN [200] (~linus@labb.contactor.se) |
11:56:21 | LinusN | you did? |
11:56:25 | GDE-DeadMeat | yeah |
11:56:26 | LinusN | what was wrong? |
11:56:32 | GDE-DeadMeat | I'm not sure |
11:56:48 | GDE-DeadMeat | I just added a bunch of USB support and scsi support |
11:57:02 | GDE-DeadMeat | I'll track down what the deal is later. |
11:57:05 | GDE-DeadMeat | :-/ |
11:57:13 | LinusN | nice that you got it working anyway |
11:57:27 | GDE-DeadMeat | yeah... taht's basically what I had to do w/ my nic card as well. |
11:57:36 | GDE-DeadMeat | I have all of the tulip drivers included. |
11:58:40 | GDE-DeadMeat | I don't supose you know which tulip driver a LNE100Tx uses? |
11:58:44 | GDE-DeadMeat | :-) |
11:59:19 | GDE-DeadMeat | someone in #gentoo was saying something about compiling everything as a module... and then letting hotplug decided which modules to use. |
12:00 |
12:06:28 | LinusN | i thought there was only one tulip driver |
12:06:56 | GDE-DeadMeat | no |
12:07:07 | | Quit apemanttt (Read error: 110 (Connection timed out)) |
12:09:11 | GDE-DeadMeat | omg... I just figured out what my issue was. |
12:09:45 | GDE-DeadMeat | for USB support I had UHCI compiled; what I needed was OHCI, which is the controller that my XP333-R mobo uses. |
12:09:53 | LinusN | ah |
12:11:04 | GDE-DeadMeat | gonna check... brb |
12:11:08 | | Quit GDE-DeadMeat ("KVIrc 3.0.0-beta2 "T-Rex"") |
12:13:24 | | Join GDE-DeadMeat [0] (Gatekeeper@c-24-12-232-226.client.comcast.net) |
12:13:34 | GDE-DeadMeat | SHAAAABOOOOOOOOOOIIIIIIIIIIIEEEEEEEEEEEE! |
12:13:36 | GDE-DeadMeat | I was right |
12:14:23 | GDE-DeadMeat | Linus, I would like to apologize for pestering you when I had not fully diagnosed my own situation. |
12:29:08 | LinusN | np |
12:29:31 | GDE-DeadMeat | I'm so happy |
12:29:38 | GDE-DeadMeat | but I think it's time to pass out. |
12:31:11 | LinusN | :-) |
12:59:23 | | Join AciD` [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
13:00 |
13:00:04 | | Quit GDE-DeadMeat ("KVIrc 3.0.0-beta2 "T-Rex"") |
13:08:51 | | Join c0utta [0] (~c0utta@187.cust48.nsw.dsl.ozemail.com.au) |
13:19:27 | | Quit AciD` (Read error: 104 (Connection reset by peer)) |
13:24:39 | | Join methangas [0] (methangas@0x50a432ba.virnxx10.adsl-dhcp.tele.dk) |
13:28:00 | | Part LinusN |
13:28:28 | | Join LinusN [200] (~linus@labb.contactor.se) |
13:31:29 | | Join apemanttt [0] (apemanttt@64.213.222.81) |
13:43:53 | *** | Saving seen data "./dancer.seen" |
14:00 |
14:26:14 | c0utta | u there linus ? |
14:26:20 | | Join grov_inf [0] (~Miranda@pD9045BE7.dip.t-dialin.net) |
14:29:22 | | Join uski [0] (~moo@2001:7a8:3bb9:0:0:0:0:b00b) |
14:29:56 | | Part grov_inf |
14:44:00 | LinusN | c0utta: busy |
14:47:42 | c0utta | k |
14:49:32 | | Quit apemanttt (Read error: 110 (Connection timed out)) |
15:00 |
15:19:07 | | Join AciD` [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
15:26:27 | | Quit AciD` (Read error: 54 (Connection reset by peer)) |
15:32:08 | | Join apemanttt [0] (apemanttt@64.213.222.81) |
15:35:31 | | Join matsl [0] (~matsl@1-1-4-2a.mal.sth.bostream.se) |
15:43:57 | *** | Saving seen data "./dancer.seen" |
16:00 |
16:28:43 | | Quit matsl (Remote closed the connection) |
16:51:53 | | Quit apemanttt (Read error: 110 (Connection timed out)) |
16:56:04 | | Nick orange_away is now known as _orange_ (~mdw@orange.active.supporter.pdpc) |
17:00 |
17:11:38 | | Join Galik [0] (~galik@195.137.1.152) |
17:28:11 | | Join AciD` [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
17:29:47 | | Part LinusN |
17:30:34 | | Join LinusN [200] (~linus@labb.contactor.se) |
17:35:57 | | Join apemanttt [0] (apemanttt@64.213.222.81) |
17:43:58 | *** | Saving seen data "./dancer.seen" |
17:45:16 | | Quit Galik ("Client exiting") |
18:00 |
18:14:00 | | Nick amiconn|away is now known as amiconn (~jens@pD9E7F146.dip.t-dialin.net) |
18:22:00 | dwihno | LinusN: Are you around? I got findings for you! |
18:25:10 | uski | what does the word "findings" mean ? |
18:26:56 | dwihno | Well. |
18:27:06 | dwihno | I've found a couple of things, so I call them findings :) |
18:34:45 | | Join mecraw_ [0] (~mecraw@69.2.235.2) |
18:37:13 | | Quit apemanttt (Read error: 110 (Connection timed out)) |
18:43:26 | LinusN | dwihno: me busy, but tell me anyway |
18:44:27 | dwihno | LinusN: Okay. So this is how it is. The RLD occurs when I'm bicycling and the unit is bouncing up and down |
18:44:44 | dwihno | The led stays lit, as if there is a disk read pending |
18:44:46 | dwihno | it does not spin down the disk |
18:44:57 | dwihno | I enter the debug menu and watch the mpeg thread |
18:45:09 | dwihno | as long as the led is lit, nothing happens |
18:45:33 | dwihno | after some kind of timeout (a couple of minutes) the unit leaves RLD state |
18:45:39 | uski | ok ;) |
18:46:05 | dwihno | When it does so, the mpeg thread start ticking again (with no sound) |
18:46:20 | dwihno | when the lower watermark is reached, the music starts playing again |
18:46:30 | dwihno | the funny thing is, I was listening to track 3 when it happened |
18:46:36 | dwihno | when it left the rld state, it was at track 9 |
18:46:41 | dwihno | (No, I did not use shuffle) |
18:46:52 | dwihno | Do you need the disk to debug more throughly? |
19:00 |
19:43:59 | *** | Saving seen data "./dancer.seen" |
19:44:22 | LinusN | i don't think so, i have one myselkf |
19:45:06 | dwihno | ah. |
19:45:23 | dwihno | well, is my description detailed enough to tell you anything? |
19:45:30 | dwihno | should I run debug enabled builds? |
19:45:35 | dwihno | I really want to squash this bug |
19:45:41 | | Join apemanttt [0] (apemanttt@64.213.222.81) |
19:45:47 | LinusN | dwihno: the silent play? |
19:45:54 | dwihno | RLD + silent play |
19:46:04 | | Quit AciD` (Read error: 104 (Connection reset by peer)) |
19:46:04 | LinusN | i don't think rld can be fixed |
19:46:09 | dwihno | you don't? |
19:46:21 | dwihno | But it returns from the rld state after a while. |
19:46:31 | dwihno | That is what has been confusing me... |
19:47:12 | dwihno | It is a disk thing? |
19:49:06 | LinusN | yes |
19:49:35 | dwihno | You're 100% certain? |
19:49:53 | dwihno | Don't you dare say yes now :) |
19:51:08 | LinusN | well, since you have to shake it, and rld happens on both firmwares...i really think so |
19:51:36 | amiconn | dwihno, LinusN: I did some googling a couple of days ago if there were firmware issues with these dreaded Hitachi DK23CA and DK23DA series. |
19:51:54 | LinusN | did you find anything? |
19:53:10 | amiconn | Both series have the same issue with the original drive firmware. At first look these seem not to be too serious: The disks unload the disk heads very quick if they are not accessed. |
19:53:37 | dwihno | hm |
19:53:50 | dwihno | I'll check my model. Wait. |
19:55:14 | dwihno | Model: HITACHI_DK23EA-60 |
19:55:21 | dwihno | Firmware 00K2A0A2 |
19:55:36 | dwihno | 0, 1, 2, 3, 4 PIO modes |
19:55:47 | dwihno | 240/120ns cycle times (what the heck is that btw?) |
19:55:54 | dwihno | IORDY support: yes |
19:56:23 | dwihno | amiconn: So my DK23EA is also affected. Damn :) |
19:58:42 | amiconn | Just googled for DK23EA and found that it may have the same problem. Head unload times for DK23CA and DK23DA with original firmware are said to be as low as only 3 secs. |
19:59:11 | dwihno | head unload times? |
19:59:48 | dwihno | Perhaps it's time to upgrade :D |
20:00 |
20:00:16 | amiconn | It means that if the drive is not accessed for this time, it unloads the disk heads (moves them away from the data area on the platters to a special parking position). |
20:01:15 | amiconn | This serves 2 purposes: (1) protect the heads and platters from incidentally touching each other (head crash) and (2) save power. |
20:01:41 | dwihno | ah |
20:02:13 | dwihno | http://www.komplett.se/k/ki.asp?sku=122159&cks=PRL |
20:02:18 | dwihno | yum yum |
20:03:26 | amiconn | I would suggest that you try to find a firmware update for your drive that works on an ordinary PC (I was only able to find updates that work only on specific laptop models). |
20:04:06 | dwihno | hm |
20:04:16 | dwihno | Firmware updates? |
20:04:27 | dwihno | Do you think that might solve the problem? |
20:04:33 | amiconn | Additionally you would need an adapter to connect the 2.5" hd to the 3.5" connector. And it would be wise to backup the data, just in case. |
20:04:59 | amiconn | It might help with your problem, but I can't say for sure. |
20:05:50 | dwihno | ah. |
20:08:07 | amiconn | For your link to a new hd: This would also be my hd model of choice for an upgrade. It also belongs (now) to Hitachi but is actually developed by IBM. |
20:08:43 | dwihno | Do you think it has the same problem? |
20:09:15 | amiconn | My current hd is an IBM and I did not observe any of the hd problems (rld, fs corruption if using assembler optimized disk code). |
20:09:58 | amiconn | No, since it is not a model of the series developed by Hitachi in the first place. |
20:11:02 | dwihno | ahh. |
20:11:21 | dwihno | The previous disk was an IBM as well |
20:11:24 | dwihno | Worked flawless. |
20:11:35 | dwihno | It was after the disk upgrade I started experiencing RLD's |
20:14:01 | amiconn | If you want to upgrade, please consider that each hd series made by the now united "Hitachi Global Storage Technologies" has two names. |
20:16:38 | amiconn | What I would consider "good ones" have the family name "Travelstar 80GN" and model numbers like "IC25NxxxATMR04" |
20:18:13 | amiconn | Of course you could try devices from other manufacturers; I know that [IDC]Dragon uses a Fujitsu drive and it seems to work perfectly. |
20:18:19 | dwihno | Indeed. |
20:18:41 | dwihno | I have been using IBM disks for 4 years, and they have worked quite good! |
20:18:52 | amiconn | There are problems reported with using Toshiba drives though |
20:19:47 | dwihno | Tell me about your personal disk experiences. |
20:22:05 | amiconn | For laptop drives I only know about IBM and Hitachi myself (my laptop happens to have a Hitach HD) and had no problems so far. |
20:22:35 | amiconn | (Except that I learned from the Rockbox ml that Hitachi disks apparently have problems with the Archos) |
20:22:38 | dwihno | I never noticed what disk my laptop has. |
20:22:56 | dwihno | Perhaps fujitsu |
20:23:30 | amiconn | WIndows XP? Look in device manager under "Drives" |
20:26:10 | LinusN | amiconn: http://linus.haxx.se/recording/ |
20:27:12 | amiconn | LinusN: Thank you, I already found it in the irc log (sorry couldn't access my PC from outside today - DynDNS update problem). |
20:29:20 | amiconn | Looks interesting btw. Could you tell me the "PR high to PR low" time as well? Furthermore it would have been of interest to see the mas parallel output lines. (sure this would have been more complicated to get) |
20:40:03 | amiconn | Am I blind? the PR high to PR low is clearly written on that page... sorry. |
20:42:02 | | Join cjnr11 [0] (dfd@bobillot-5-82-224-193-23.fbx.proxad.net) |
20:42:06 | | Part cjnr11 |
20:43:44 | dwihno | amiconn: my laptop is at home - I'm not there :) |
20:46:50 | dwihno | amiconn: is a lower-rpm drive to prefer when using it in the archos? |
20:48:59 | amiconn | Yes, because it saves battery power and is more quiet. Faster drives would help nothing with read speed, the Archos CPU simply cant read as fast as every modern laptop hd could deliver the data. |
20:49:26 | amiconn | 4200 rpm drives are the lowest you can get now. |
20:52:08 | dwihno | aha. |
20:52:19 | dwihno | So let's get the disk I showed you earlier then :) |
20:56:55 | amiconn | I think that would be a good one, but I also think that it is a bit expensive. SEK 2,297 ~ EUR 249 |
20:57:37 | dwihno | Well. |
20:57:47 | dwihno | There's a swedish saying |
20:57:51 | dwihno | "Kronan är rund för att rulla" |
20:58:01 | dwihno | Basically saying, money is for spending :) |
20:58:44 | amiconn | Yes, but I could buy the same disk model for only EUR 173 here in Germany. |
20:58:49 | dwihno | Whoa |
20:59:02 | dwihno | Germany rules! :D |
20:59:20 | dwihno | Dschörmany |
20:59:27 | dwihno | Excluding taxes? |
21:00 |
21:00:08 | amiconn | This is including 16% VAT for Germany. |
21:00:40 | dwihno | aah |
21:00:45 | dwihno | Sweden has 25% VAT |
21:00:55 | dwihno | There's a swedish saying |
21:01:00 | dwihno | Sverige är ett U-land ;) |
21:02:44 | amiconn | recalculation to 25% VAT would yield EUR 186.68. |
21:02:53 | dwihno | Still a great price |
21:03:04 | dwihno | I should order from Germany then (since they are in the EU and all) |
21:04:26 | amiconn | Hmm, couldn't figure out if this particular web shop delivers to Sweden... |
21:04:50 | scott666 | pricewatch has em for as low as $190, but most if not all the companies are american |
21:05:49 | | Quit adi|home (Remote closed the connection) |
21:05:55 | dwihno | I'll check the swedish pricerunner |
21:08:02 | dwihno | Got the URL for the german site? |
21:10:25 | amiconn | http://www.schottenland.de/jump.php?action=dpcl&value=6052947 |
21:10:39 | dwihno | Schottenland? :) |
21:11:14 | amiconn | (This is a redirector to Mix computer) |
21:13:04 | amiconn | Yes, bcause that German price watch site I'm using is called "Hardwareschotte". Schotte = Scotsman, which are said to be stingy. |
21:13:39 | dwihno | cool |
21:14:47 | dwihno | Time to do something useful |
21:14:50 | dwihno | Have a nice evening. |
21:14:52 | dwihno | Thanks for the input. |
21:15:08 | amiconn | np. |
21:35:55 | | Nick amiconn is now known as amiconn|code (~jens@pD9E7F146.dip.t-dialin.net) |
21:44:01 | *** | Saving seen data "./dancer.seen" |
21:45:27 | | Join AciD` [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
21:47:57 | | Join track [0] (74d57721@ACBC9C4B.ipt.aol.com) |
21:48:03 | track | hi boys |
21:51:13 | | Join [IDC]Dragon [0] (~idc-drago@pD9E34CE7.dip.t-dialin.net) |
21:51:22 | amiconn|code | Hi Jörg |
21:51:38 | [IDC]Dragon | Hi everybody |
21:55:14 | track | hi |
21:55:20 | uski | hi [IDC]Dragon |
21:55:20 | uski | waza |
21:55:50 | [IDC]Dragon | hi there |
21:56:40 | [IDC]Dragon | I've just released my latest "baby", see the group |
22:00 |
22:00:39 | | Quit apemanttt (Read error: 110 (Connection timed out)) |
22:05:06 | uski | blah ? |
22:05:06 | uski | ANOTHER thingy for rockbox ? |
22:05:41 | [IDC]Dragon | why not? are youfed up with it? |
22:13:48 | | Join cjnr112 [0] (dfd@bobillot-5-82-224-193-23.fbx.proxad.net) |
22:13:52 | | Part cjnr112 |
22:17:59 | uski | blah |
22:17:59 | uski | if rockbox was sold hey gotta pay you a percentage on sales lol |
22:52:59 | amiconn|code | LinusN, [IDC]Dragon: I just completed my new recording loop in assembler; first tests show that it works. |
22:52:59 | | Quit track (Read error: 104 (Connection reset by peer)) |
22:53:25 | [IDC]Dragon | nice! |
22:53:27 | amiconn|code | Atm I started a longer test recording to see if I get any corrupted frames (this has no 5-clock waiting) |
22:54:15 | | Nick amiconn|code is now known as amiconn (~jens@pD9E7F146.dip.t-dialin.net) |
22:54:19 | [IDC]Dragon | are you doing this xor thing? |
22:55:01 | amiconn | Yes, already did it in C and it works perfectly, saves ~180 bytes of code (more than half of which are in IRAM) |
22:55:10 | [IDC]Dragon | before entering the loop, you should set the port to the idle state depending on mask, to be sure. |
22:55:36 | [IDC]Dragon | Else once wrong, always wrong. |
22:55:59 | amiconn | Yes, I do this already in mpeg_int() where the variable inverted_pr would have been set before. |
22:56:09 | amiconn | *mpeg_init() |
22:56:28 | [IDC]Dragon | but that's executed only once? |
22:57:20 | amiconn | Yep, but it's sufficient. I don't really expect a port to change its value by accident the same way that I don't expect this from any DRAM cell. |
22:57:44 | [IDC]Dragon | it's because ports are shared. |
22:58:03 | [IDC]Dragon | one mistake somewhere else could drive you crazy. |
22:59:00 | [IDC]Dragon | Just set it at the start of rec_tick(), depending on inverted_pr |
22:59:56 | amiconn | Hmm, but then I would have to re-introduce that variable... |
23:00 |
23:01:32 | [IDC]Dragon | so what? |
23:02:04 | amiconn | Hmm, I think I will do that, just to add some security. |
23:02:13 | [IDC]Dragon | thanks |
23:08:25 | LinusN | if you do that, we won't find the bug that would cause the port to change |
23:09:02 | amiconn | LinusN: What "that" do you mean? |
23:09:07 | [IDC]Dragon | going for high risk? |
23:09:37 | LinusN | if you set it at the start of rec_tick instead of mpeg_init |
23:09:53 | LinusN | if there is a bug that changes the port, we want to find it |
23:10:02 | [IDC]Dragon | other idea: do a "panic" if you find the wrong level (our kind of assertion) |
23:10:17 | amiconn | This woud vote for _not_ setting it at the start of rec_tick. |
23:10:44 | LinusN | i can go for either way |
23:11:35 | amiconn | Hmm, the thing is if I put the initial setting at the beginning of the it wouldn't help to secure it. |
23:12:14 | amiconn | In the current implementation, if PR has the wrong value this is "magically fixed" by setting it active, since then it would not change value (1st time). |
23:12:27 | | Quit scott666 ("i'll be back...eventually...") |
23:13:00 | [IDC]Dragon | sorry, I didn't mean to start a lengthy discussion. |
23:13:08 | amiconn | If i set it to inactive initially and then activate/deactivate with xor, we could miss the first byte if PR was accidentally active before. |
23:13:59 | LinusN | still i don't like defensive coding to defend me from my own mistakes |
23:14:08 | LinusN | in runtime |
23:14:59 | | Join scott666 [0] (scott666@c-24-245-58-245.mn.client2.attbi.com) |
23:15:29 | | Join apemanttt [0] (apemanttt@64.213.222.81) |
23:19:35 | | Quit AciD` (Connection timed out) |
23:28:14 | amiconn | LinusN: What do you think about check PR for inactive state at the end of init_recording() and panicing if it's active? |
23:37:13 | | Quit scott666 ("i'll be back...eventually...") |
23:40:54 | LinusN | if you feel that it's necessary... |
23:41:34 | [IDC]Dragon | OK, don't, sorry to have started this. |
23:43:08 | LinusN | :-) |
23:44:05 | *** | Saving seen data "./dancer.seen" |
23:46:21 | LinusN | gotta sleep, cu around |
23:46:33 | [IDC]Dragon | bye |
23:46:36 | amiconn | bye |
23:46:59 | | Part LinusN |
23:57:26 | amiconn | 1 hr test recording is now complete: no corrupt frames (except that the last frame is truncated, as usual). Even Wmplayer likes the file. |