| 00:00:02 | iRiverMan | hiya |
| 00:00:33 | LinusN | yo |
| 00:00:33 | iRiverMan | When will the first iriver rockbox be released as im very keen to test it? |
| 00:00:41 | LinusN | iRiverMan: sometime next year i guess |
| 00:00:43 | amiconn | LinusN: Do the recorder v2/fm models have spdif out? |
| 00:00:55 | iRiverMan | :-( |
| 00:01:03 | LinusN | amiconn: i believe so |
| 00:01:10 | iRiverMan | amiconn spdif in but not out |
| 00:01:12 | LinusN | or is it s/pdif in? |
| 00:01:19 | iRiverMan | the iriver has optical spdif in and out |
| 00:02:00 | iRiverMan | on seperate sockets |
| 00:02:14 | LinusN | yup, nice indeed |
| 00:03:04 | iRiverMan | but the optical out on a hifi CD player is a different connector. a Toslink |
| 00:03:11 | amiconn | LinusN: A similar define would be handy for excluding spdif from the recording source choices if the input is not present (Ondio FM) |
| 00:03:16 | iRiverMan | so u need an optical lead with different plugs at both ends |
| 00:03:27 | LinusN | amiconn: yes |
| 00:04:05 | iRiverMan | if i was to record to WAV via the optical in on the iriver i would get a perfect CD copy? |
| 00:04:38 | LinusN | i believe so |
| 00:04:53 | amiconn | iRiverMan: I think so, however, the original firmware may prohibit this (SCMS bit) |
| 00:04:57 | iRiverMan | im sure the RIAA is gonna suire river |
| 00:05:07 | iRiverMan | sue iriver |
| 00:05:07 | iRiverMan | lol |
| 00:05:36 | iRiverMan | yea but the iriver is NOT sdmi complaiant |
| 00:06:25 | iRiverMan | one thhing i like about the iriver's remote lcd is that it is a bitmap LCD, not character cell LCD |
| 00:06:43 | amiconn | It isn't? Strange, I thought all consumer equipment is required to implement it |
| 00:07:13 | iRiverMan | yea but iriver isn't a well known brand like Sony |
| 00:07:16 | iRiverMan | or Creative Labs |
| 00:07:37 | iRiverMan | or iPod |
| 00:08:37 | iRiverMan | or Archos |
| 00:08:39 | iRiverMan | lol |
| 00:09:15 | amiconn | Rockbox doesn't play by the rules as well. You can record such bitstreams on the jb recorder |
| 00:09:47 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 00:10:07 | iRiverMan | oh boy |
| 00:10:34 | iRiverMan | the rio karma man is here |
| 00:10:43 | | Join LMN8R [0] (~chatzilla@cohenjor.user.msu.edu) |
| 00:10:57 | midk | looks like we've got an iriver fanboy |
| 00:11:26 | iRiverMan | yep |
| 00:11:33 | iRiverMan | bought an iriver last weekend |
| 00:11:37 | iRiverMan | ihp-120 |
| 00:11:39 | LMN8R | Hey guys, I was looking over at the forums and know how much you hate stupid questions (with good reason), so I just wanted to thank you for your hard work, and good luck with the project! |
| 00:13:01 | iRiverMan | the rio karma is the butt-ugliest mp3 player i have ever seen |
| 00:14:26 | | Join webguest07 [0] (~c7e73180@labb.contactor.se) |
| 00:14:36 | midk | just by the way.. i don't care too much for the rio karma since about a year ago.. it was nice when it came out though |
| 00:15:26 | webguest07 | hello |
| 00:15:29 | iRiverMan | yea but compared to today's mp3 players it looks too plastiky and 80's looking |
| 00:16:12 | iRiverMan | usb2 is wisked |
| 00:16:13 | iRiverMan | wicked |
| 00:16:19 | midk | mm.. everyone's got their own opinions |
| 00:16:24 | iRiverMan | lol |
| 00:16:33 | midk | it's not beautiful, no way, but it's not horrible either |
| 00:16:58 | iRiverMan | well i suppose it looks slightly better than an ipod |
| 00:17:17 | | Quit LMN8R ("Chatzilla 0.9.65 [Mozilla rv:1.7.3/20040913]") |
| 00:18:13 | webguest07 | I just got an ata -1 error on my archos jukebox. |
| 00:18:24 | webguest07 | looks like it was just a low battery though. |
| 00:18:25 | iRiverMan | still miss my archos |
| 00:18:34 | iRiverMan | i ripped it apart after it died |
| 00:18:38 | iRiverMan | wanted to keep the hd |
| 00:19:02 | webguest07 | The styling is a bit clunky. |
| 00:20:32 | iRiverMan | no it isn't |
| 00:20:51 | webguest07 | No? |
| 00:21:06 | webguest07 | I only got it to run rockbox. |
| 00:21:09 | iRiverMan | it feels like one of those luxury cigar cases |
| 00:21:33 | iRiverMan | has an all-metal body |
| 00:21:44 | webguest07 | I think it looks like wannabe hi-tech. |
| 00:21:54 | iRiverMan | I wonder if a crossfader is possible on the iriver |
| 00:24:02 | webguest07 | does that imply processing 4 channels simultaniously, plus adding pairs together? |
| 00:24:03 | iRiverMan | ? |
| 00:24:13 | iRiverMan | what u mean? |
| 00:24:22 | webguest07 | left and right |
| 00:24:29 | webguest07 | two tracks |
| 00:24:45 | webguest07 | then mixing 2 lefts 2 rights |
| 00:24:54 | iRiverMan | i just meen crossfading |
| 00:24:55 | webguest07 | during the fade |
| 00:25:05 | iRiverMan | fade out one song and fade in the next at the same time |
| 00:25:17 | midk | iRiverMan, that's what webguest07 is talking about |
| 00:25:29 | webguest07 | so during the crossfade, both tracks are being decoded |
| 00:25:30 | midk | you have to have two tracks playing in order to hear them both |
| 00:25:42 | midk | and it's not possible |
| 00:26:03 | iRiverMan | ok |
| 00:26:07 | amiconn | midk: Why shouldn't it be possible on the iRiver? |
| 00:26:16 | webguest07 | you can fade out track one, and then fade in track two, much easier. |
| 00:26:16 | iRiverMan | i asked because i think everything is done via software on the iriver |
| 00:26:22 | midk | amiconn, you'd need two mp3 decoders |
| 00:26:29 | midk | amiconn, why isn't it possible on the Archos then? |
| 00:26:45 | amiconn | The iRiver uses software decoding, so it should be possible to have as many decoders as you want as long as there is enough CPU power |
| 00:26:55 | midk | amiconn, well good luck |
| 00:28:07 | webguest07 | About low battery conditions on archos... |
| 00:28:40 | webguest07 | Am i right that wierd things happen during low battery voltage? |
| 00:28:56 | webguest07 | ata errors |
| 00:29:08 | webguest07 | I saw one report of a fail to charge. |
| 00:29:29 | webguest07 | couldn't rockbox detect low voltages? |
| 00:29:49 | webguest07 | flash the backlight, refuse to spin up HD until charged? |
| 00:30:03 | webguest07 | rather than just freak out? |
| 00:30:36 | webguest07 | I assume it's the HD that really sucks a lot of juice. |
| 00:31:08 | iRiverMan | yea |
| 00:31:12 | iRiverMan | only 2mb buffer |
| 00:31:15 | webguest07 | So, by delaying HD spinup attempts, there'd be time to communicate to the user. |
| 00:31:21 | LinusN | webguest07: low voltage is only one factor |
| 00:31:40 | webguest07 | what else? |
| 00:31:46 | LinusN | bad batteries |
| 00:31:50 | LinusN | bad battery connection |
| 00:31:52 | iRiverMan | linus will mp3pro be supported on the iriver/ |
| 00:31:57 | webguest07 | bad in what sense? |
| 00:32:03 | LinusN | iRiverMan: hardly' |
| 00:32:07 | webguest07 | diminished capacity? |
| 00:32:14 | LinusN | bad battery == worn out |
| 00:32:39 | webguest07 | does the discharge curve change shape over the lifetime? |
| 00:33:03 | LinusN | a bad battery may show good voltage unloaded, but will fail to deliver any current |
| 00:33:14 | webguest07 | ahhh. |
| 00:33:33 | webguest07 | no way to load test, other than spinup attempts... |
| 00:33:39 | LinusN | exactly |
| 00:34:01 | webguest07 | can rockbox see the voltage falling during spinup, and abort? |
| 00:34:24 | webguest07 | or is that a single step "spin up" |
| 00:34:24 | amiconn | Rockbox could monitor the voltage while hd is spinning versus the voltage while the hd is not spinning. |
| 00:35:07 | webguest07 | would you see the drop during songplay, by comparing each buffer fill voltage? |
| 00:35:27 | amiconn | In fact, this might give a more realistic estimation of the battery status than the absolute voltage. |
| 00:35:47 | webguest07 | watch for too steep a slope to the graph of voltages? |
| 00:36:43 | webguest07 | do nimh batts have a "cliff shaped" discharge curve, like nicd? |
| 00:36:54 | webguest07 | or is it more gradual? |
| 00:36:54 | amiconn | For instance, I replaced the stock archos cells by higher capacity ones. Although rockbox runs longer with these, it displays the remaining capacity significantly lower than it actually is. |
| 00:37:55 | webguest07 | If you could spot the steep part of the curve coming up, and log the "drive spin" time, |
| 00:38:11 | webguest07 | you could "learn" the run time. |
| 00:38:31 | amiconn | No, I mean monitoring the voltage difference between spinning and not spinning hd |
| 00:38:45 | webguest07 | over multiple charge/discharge cycles. |
| 00:39:04 | amiconn | This difference gets higher towards the end of discharge, because the internal resistance of the cells increases |
| 00:39:06 | webguest07 | amiconn: why not compare consecutive spinup events? |
| 00:39:44 | webguest07 | wouldn't the loaded voltage drop? |
| 00:40:08 | webguest07 | or is loaded vs unloaded more accurate? |
| 00:41:20 | amiconn | I think loaded vs. unloaded might be more accurate, because the absolute voltage in various charge states may differ between different cell types |
| 00:41:41 | webguest07 | I'd just like to see something cleaner than an unplanned shutoff during a copy operation, followed by a disk error. |
| 00:42:35 | webguest07 | I wouldn't imagine you'd use absolute voltages, just deltas from previous spinups. |
| 00:43:27 | amiconn | Those deltas might be not very helpful, because the time between spinups may differ vastly (different bitrate playback, no playback, user interaction...) |
| 00:43:28 | webguest07 | If the slope between consecutive spinups is too steep, the battery must be near discharged. |
| 00:43:56 | LinusN | if we were to implement a "safe" battery level handling, you would experience a lot shorter battery life |
| 00:43:57 | iRiverMan | Can anyone recommend top quality earbud earphones? |
| 00:43:58 | webguest07 | amiconn: you're right, that'd only be valid during a track |
| 00:44:11 | LinusN | iRiverMan: i have Sony EX-70 |
| 00:44:12 | webguest07 | assuming no pause. |
| 00:44:28 | iRiverMan | any others? |
| 00:44:55 | amiconn | iRiverMan: Sennheiser MX400 |
| 00:45:20 | webguest07 | LinusN: does that imply that there's a lot of play time available even after voltage begins falling off? |
| 00:45:40 | iRiverMan | i think i would prefer the Sennheiser brand |
| 00:45:43 | iRiverMan | whats their website? |
| 00:46:18 | LinusN | webguest07: yes |
| 00:46:33 | LinusN | you sikmply can't know |
| 00:47:13 | LinusN | either you play safe, and turn off way too early, or you run to the bitter end |
| 00:47:27 | amiconn | iRiverMan: http://www.sennheiser.com/sennheiser/icm_eng.nsf (assuming you prefer English) |
| 00:48:28 | amiconn | LinusN: the delta-v approach might be relatively good, because it measures the internal resistance of the cells. |
| 00:48:29 | webguest07 | No way to plot a curve at all? Even during a single session, with no pauses? |
| 00:48:45 | amiconn | This way we'd also catch a bad cell |
| 00:48:53 | webguest07 | Or just too much work? |
| 00:49:15 | amiconn | webguest07: You can look at the voltage curve, in the debug menu |
| 00:49:40 | amiconn | (This curve is for hd not spinning) |
| 00:50:04 | webguest07 | amiconn: you guys are SO cool. That's a feature you'd never get from a corporate product. |
| 00:51:31 | amiconn | LinusN: I'd like to introduce a new header file, in order to be able to add MMC debug function(s) |
| 00:52:35 | *** | Saving seen data "./dancer.seen" |
| 00:53:25 | amiconn | Should I call this ata_mmc.h (to be consistent with the driver file name) or mmc.h (to make clear that it is only useful for mmc based systems)? |
| 00:55:26 | webguest07 | What is the update rate on the battery curve? |
| 00:55:40 | amiconn | Once per minute iirc |
| 00:56:31 | webguest07 | Looks like I can't be connected via usb while it's onscreen. |
| 00:57:12 | amiconn | Nope. Most debug menu items don't react on USB connection |
| 00:58:04 | webguest07 | My low battery shutdown happened in the middle of copying some files off the unit. |
| 00:58:31 | amiconn | The (rough) battery status display is active while on USB, so there is at least something to watch the batteries |
| 00:58:39 | | Quit iRiverMan ("CGI:IRC (EOF)") |
| 00:59:23 | webguest07 | BTW, i love the backlight fades :) |
| 01:00 |
| 01:01:12 | webguest07 | I had another minor issue. |
| 01:01:21 | webguest07 | Relating to resume. |
| 01:01:46 | webguest07 | Volume levels on resume, to be specific. |
| 01:02:58 | webguest07 | Would it be possible to *not* resume at a high volume if the unit has been inactive for >1hour, or something like that? |
| 01:04:29 | amiconn | Imho it is unlikely that such a feature will get implemented, because if it would, it would have to be made configurable. |
| 01:04:58 | webguest07 | Maybe do a slow fade back to the level, then? |
| 01:05:32 | amiconn | I would have switched it off most of the time, since I often use my jukebox output as a line out, and I certainly do *not* want to lower the level |
| 01:05:33 | webguest07 | Over a couple of seconds |
| 01:05:44 | amiconn | Fade in/out is already there |
| 01:06:12 | webguest07 | for a mid-track resume? |
| 01:06:31 | webguest07 | maybe i just need an updated build. |
| 01:07:03 | amiconn | Dunno if it does fade for mid-track resume, since I don't use it either. I find it somewhat irritating |
| 01:07:17 | webguest07 | I had my box cranked up driving at night. |
| 01:07:39 | webguest07 | Scared/startled myself in the morning. :) |
| 01:07:58 | amiconn | LinusN: Did you get my question? |
| 01:08:21 | webguest07 | It didn't sount THAT loud the night before :) |
| 01:09:45 | amiconn | webguest07: I use different .cfg files (car use, earphone, connected to home hifi) and load these before resuming when needed. |
| 01:10:05 | amiconn | I have resume set to "ask" |
| 01:13:03 | LinusN | amiconn: the file name? |
| 01:13:07 | amiconn | yes |
| 01:13:37 | LinusN | i think ata_mmc.h would be fine, but i trust your judgement |
| 01:13:49 | amiconn | Or, if it makes sense at all. Currently this would contain a typedef struct, and one function |
| 01:22:07 | webguest07 | amiconn: I need an "am, no coffee .cfg" and a "pm, need sleep .cfg" selected via RTC . (kidding). |
| 01:22:44 | amiconn | ;) |
| 01:26:01 | LinusN | time to sleep |
| 01:26:06 | LinusN | nite all |
| 01:26:10 | | Part LinusN |
| 01:26:11 | amiconn | nite Linus |
| 01:26:29 | amiconn | That was quick... |
| 01:32:54 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 01:33:14 | LinusN | first iriver LED blink program has now executed!!!!!!! |
| 01:33:19 | LinusN | nite |
| 01:33:22 | | Part LinusN |
| 01:36:28 | webguest07 | amiconn: thanks for the interesting conversation. |
| 01:36:54 | webguest07 | It's nice to be able to discuss with developers. |
| 01:37:17 | webguest07 | I like to understand a bit how things work. |
| 01:37:48 | amiconn | Np. |
| 01:38:19 | webguest07 | It's 7:30 here, I guess I'm going to get some food. |
| 01:38:30 | webguest07 | bye. |
| 01:38:47 | | Quit webguest07 ("CGI:IRC 0.5.4 (2004/01/29)") |
| 02:00 |
| 02:52:37 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:06:26 | | Join amiconn_ [0] (~jens@pD9E7F0DC.dip.t-dialin.net) |
| 03:24:34 | | Quit amiconn (Read error: 110 (Connection timed out)) |
| 03:28:37 | | Quit mecraw ("Trillian (http://www.ceruleanstudios.com)") |
| 03:43:01 | | Quit amiconn_ (Read error: 110 (Connection timed out)) |
| 04:00 |
| 04:19:18 | | Quit Sebulba02 ("fluxbox") |
| 04:25:41 | | Join Sebulba02 [0] (~Sebulba02@Darth-Sebulba04.active.supporter.pdpc) |
| 04:52:40 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:14:00 | | Quit midk (Remote closed the connection) |
| 05:15:51 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 06:00 |
| 06:01:41 | | Quit midk (Read error: 104 (Connection reset by peer)) |
| 06:02:02 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 06:30:36 | | Quit scott666 ("i'll be back...eventually...") |
| 06:45:01 | | Quit midk ("just STOP it arspy") |
| 06:46:49 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 06:52:44 | *** | Saving seen data "./dancer.seen" |
| 06:53:18 | | Quit midk ("just STOP it arspy") |
| 06:53:25 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 06:58:44 | | Join kramerica [0] (~lkd@hsdbsk207-195-113-154.sasknet.sk.ca) |
| 07:00 |
| 07:02:32 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 07:06:11 | midk | LinusN, congratulations on the led-flashing program! |
| 07:06:16 | midk | any progress since? :) |
| 07:06:25 | midk | wow, that's quite something.. |
| 07:08:32 | LinusN | i went to bed right after |
| 07:09:39 | midk | oh, morning in that case :) |
| 07:48:42 | | Quit midk ("just STOP it arspy") |
| 07:48:43 | | Quit kramerica (Read error: 104 (Connection reset by peer)) |
| 07:49:19 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 07:55:43 | | Quit midk ("just STOP it arspy") |
| 07:58:46 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 08:00 |
| 08:01:12 | | Join [IDC]Dragon [0] (~idc-drago@pD95124C3.dip.t-dialin.net) |
| 08:01:55 | * | [IDC]Dragon saw that LinusN had success in flashing the iriver! ;-) |
| 08:02:49 | | Quit AciD (Remote closed the connection) |
| 08:02:56 | * | midk sees that LinusN is away (meeting) |
| 08:02:57 | midk | :) |
| 08:03:05 | * | midk sees it is time for bed, nite all |
| 08:03:22 | [IDC]Dragon | see you! |
| 08:06:48 | | Join plok [0] (s336156@student.uq.edu.au) |
| 08:11:07 | | Join Chronic007 [0] (~Miranda@24.30.163.142) |
| 08:11:29 | Chronic007 | hey all |
| 08:12:01 | * | plok is away - Automatically set away. - messages will be saved. |
| 08:15:19 | LinusN | [IDC]Dragon: i haven't flashed it... |
| 08:15:33 | LinusN | i just ran the program with the debugger |
| 08:15:41 | LinusN | i cheated :-) |
| 08:16:13 | [IDC]Dragon | that was just a joke: LED flashing vs. ROM flashing |
| 08:16:34 | * | LinusN was too tired to get it |
| 08:17:27 | Chronic007 | Love having your technical chat in the background while I do homework....: -) |
| 08:18:29 | Chronic007 | it always proves to be so interesting |
| 08:18:43 | Chronic007 | we'll back to work..... |
| 08:33:12 | | Join amiconn [0] (~jens@pD9E7F0DC.dip.t-dialin.net) |
| 08:35:26 | [IDC]Dragon | morning Jens |
| 08:36:06 | amiconn | Good morning Jörg |
| 08:36:31 | amiconn | Morning all |
| 08:38:11 | [IDC]Dragon | my USB card was shipped yesterday, best case I'll get it today |
| 08:38:36 | [IDC]Dragon | then I'dbe ready for some HD and partition swapping |
| 08:40:28 | | Join Zagor [242] (~bjst@labb.contactor.se) |
| 08:47:44 | [IDC]Dragon | Zagor: how about removing unused stuff from the fat bpb struct? |
| 08:48:13 | [IDC]Dragon | we're copying some info there which is unused |
| 08:48:29 | Zagor | go ahead |
| 08:48:59 | [IDC]Dragon | ok, I thought maybe you liked it there for debugging or such |
| 08:49:38 | Zagor | nah, it was just left there because I wasn't sure in the beginning which parts the driver would use. and then I never cleaned up. |
| 08:49:53 | [IDC]Dragon | ok |
| 08:50:13 | LinusN | Zagor: i ran my first iriver blink program last night |
| 08:50:24 | amiconn | [IDC]Dragon: Same decision I have to do with the CSD data from the MMCs. Some items are not needed for operation, but may be interesting for debugging/survey/whatever |
| 08:50:31 | dwihno | Great work, Linus! |
| 08:50:43 | Zagor | LinusN: wohoo! |
| 08:51:02 | LinusN | major backlight blinking |
| 08:51:04 | dwihno | First step - enable LCD; next: port RLD code ;) |
| 08:51:17 | dwihno | led, that is |
| 08:52:47 | *** | Saving seen data "./dancer.seen" |
| 08:54:23 | LinusN | should we move all data sheets to wiki? |
| 08:54:50 | LinusN | the archos sheets are on the web server, and the iriver sheets are in wiki |
| 08:55:07 | LinusN | i want all sheets on the same place |
| 08:55:31 | Zagor | then move them to wiki |
| 08:55:57 | LinusN | ok |
| 08:56:41 | [IDC]Dragon | amiconn; then I suggest the same: put them in for now, clean up later |
| 09:00 |
| 09:14:41 | | Join kurzhaarrocker [0] (~knoppix@p508776B8.dip0.t-ipconnect.de) |
| 09:15:27 | kurzhaarrocker | Moin. Are there any news about the recording bug(s)? |
| 09:16:30 | Zagor | you mean the spdif recording issue? |
| 09:16:33 | LinusN | kurzhaarrocker: nope, i have sent a test version to Paul |
| 09:17:04 | kurzhaarrocker | Zagor: I meant corrupt frames / stuttering recordings. |
| 09:17:09 | kurzhaarrocker | :( LinusN |
| 09:17:41 | Zagor | the latest theory is that this never worked, we just didn't have frame checksums enabled back when it appeared to work |
| 09:19:58 | kurzhaarrocker | What happens with frames whose checksums don't match? |
| 09:20:29 | Zagor | we save them in the file, and then it's up to the player to decide what to do with them |
| 09:20:48 | kurzhaarrocker | ok. That's what I'd have guessed. :) |
| 09:21:22 | LinusN | the MAS mutes bad frames, leding to stuttering sound |
| 09:21:37 | LinusN | short silent "glitches" |
| 09:23:27 | kurzhaarrocker | Do they occur regularily or only occasionally? I have a recording that has signal / silence changes at ~2 Hz or so. |
| 09:26:18 | LinusN | kurzhaarrocker: they occur when the MAS decodes a frame with bad CRC |
| 09:26:32 | LinusN | how often that happens depends on how many crc errors thare are in the file |
| 09:26:54 | LinusN | and your file happens to have it at those intervals |
| 09:27:31 | kurzhaarrocker | ok so there is no 'typical pattern' of those glitches. |
| 09:27:35 | LinusN | we don't see a pattern when it happens and how often |
| 09:30:02 | Bagder | congrats on the blink LinusN! |
| 09:31:16 | LinusN | thx |
| 09:42:10 | | Join Headie [0] (~hehe@fsto6.sto.sema.se) |
| 09:43:01 | [IDC]Dragon | bbl |
| 09:43:05 | | Quit [IDC]Dragon () |
| 09:44:05 | | Part kurzhaarrocker |
| 09:44:19 | LinusN | Bagder: was really fun to finally write, compile and run code on the iriver |
| 09:44:52 | Bagder | I can imagine that |
| 09:45:18 | Zagor | those little things are the gems of the whole project |
| 09:46:04 | Bagder | you guys know if I can make tabs visible with emacs in c-mode? |
| 09:46:19 | Bagder | I've searched, but found nada |
| 09:46:27 | LinusN | i have no idea |
| 09:46:29 | Zagor | no idea |
| 09:46:37 | Zagor | i usually ask you :) |
| 09:46:46 | Bagder | :-) |
| 09:47:15 | Bagder | I just get so annoyed when tabs sneak in |
| 09:47:26 | Bagder | I would like to notice them better |
| 09:47:36 | Zagor | yeah |
| 09:47:56 | Bagder | (defun curl-code-cleanup () |
| 09:47:56 | Bagder | "no docs" |
| 09:47:56 | Bagder | (interactive) |
| 09:48:00 | Bagder | (untabify (point-min) (point-max)) |
| 09:48:00 | Bagder | (delete-trailing-whitespace) |
| 09:48:00 | Bagder | ) |
| 09:48:01 | Zagor | it's probably possible to tweak the c-mode a bit, so it acts like makefile-mode in showing tabs |
| 09:48:32 | Zagor | happy lisping... |
| 09:49:00 | Bagder | this function actually works ;-) |
| 09:49:09 | Bagder | (define-key c-mode-base-map "\M-m" 'curl-code-cleanup) |
| 09:49:22 | Bagder | now meta-m cleans up |
| 09:50:46 | LinusN | nice |
| 09:54:18 | | Part LinusN |
| 09:54:28 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 09:55:56 | | Part LinusN |
| 09:56:06 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 09:58:02 | | Join amiconn_ [0] (~jens@pD95D194F.dip.t-dialin.net) |
| 09:58:05 | | Part LinusN |
| 09:58:15 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 09:58:20 | Zagor | bouncy bouncy |
| 09:58:47 | LinusN | shitty tunnel |
| 10:00 |
| 10:15:52 | | Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) |
| 10:16:32 | | Quit amiconn (Read error: 110 (Connection timed out)) |
| 10:16:33 | | Nick amiconn_ is now known as amiconn (~jens@pD95D194F.dip.t-dialin.net) |
| 10:21:43 | | Join webguest82 [0] (~c40ff482@labb.contactor.se) |
| 10:23:08 | | Quit webguest82 (Client Quit) |
| 10:32:29 | * | Bagder admits to be using a UI-based tool for id3 editing |
| 10:33:30 | Zagor | which one? |
| 10:33:34 | Bagder | easytag |
| 10:33:46 | Zagor | i use that one too |
| 10:33:47 | Bagder | pretty nice |
| 10:34:06 | Zagor | yeah, i just wish there were some more keyboard shortcuts |
| 10:40:43 | LinusN | we have officially ditched the Neo port, right? |
| 10:40:51 | Bagder | yes |
| 10:41:04 | LinusN | then i'll clean up app.lds a little |
| 10:41:05 | Bagder | I think so |
| 10:41:12 | Zagor | yes |
| 10:47:51 | [IDC]Dragon | amiconn: r u there? |
| 10:52:02 | amiconn | yes, sort of |
| 10:52:49 | *** | Saving seen data "./dancer.seen" |
| 10:57:30 | [IDC]Dragon | how do you see the chances of getting a little pause into the voice file, for spelling spaces? |
| 10:58:10 | [IDC]Dragon | This would be a special case to the script |
| 10:59:10 | amiconn | Yes. I did already think of building more "knowledge" into the script in order to strip the leading and trailing silence only from those clips that need it (spelling chars, numbers) |
| 10:59:54 | [IDC]Dragon | you tolerant wavtrim already does that...? |
| 11:00 |
| 11:00:00 | [IDC]Dragon | your |
| 11:00:09 | amiconn | This would help to avoid unwanted clicks at the end |
| 11:00:34 | amiconn | The modified wavtrim strip silence even it is not absolute silence. |
| 11:01:22 | [IDC]Dragon | you mean, it should do a quick fade in/out in such cases? |
| 11:01:24 | amiconn | The decision whether to strip at all must be done in the script |
| 11:02:59 | amiconn | No, ordinary phrases shouldn't be stripped at all |
| 11:03:08 | [IDC]Dragon | OK, I'll add a voice ID for space, then it's up to the script whether this is used or not. Absent clips are just skipped, so no change in behaviour |
| 11:03:42 | | Join ashridah [0] (ashridah@220-253-121-20.VIC.netspace.net.au) |
| 11:04:40 | amiconn | [IDC]Dragon: Btw, what are you trying to do with that space? |
| 11:05:14 | [IDC]Dragon | just improve the spelling, right now words are "merged" |
| 11:05:26 | amiconn | Ah ok. |
| 11:10:08 | [IDC]Dragon | and I'm close to implement patch 978765 |
| 11:10:23 | [IDC]Dragon | (filename clips) |
| 11:11:09 | [IDC]Dragon | I'll remove the dir talk on enter then nobody seems to use it |
| 11:11:34 | amiconn | I agree that "on enter" doesn't make much sense |
| 11:11:42 | [IDC]Dragon | and rename "while hovering" to "name clip" or something |
| 11:12:08 | [IDC]Dragon | the "on enter" came from the original talkbox patch |
| 11:13:53 | [IDC]Dragon | some interesting corner cases: |
| 11:13:57 | amiconn | (filename clips) This would add a lot of files. I like the idea to put the clips into an id3v2 tag though |
| 11:14:22 | [IDC]Dragon | what happens if a file is called _dirname |
| 11:15:17 | [IDC]Dragon | what happens if hovering over a filname clip file |
| 11:15:41 | [IDC]Dragon | can a clip file be "voiced" by adding another .talk |
| 11:16:40 | amiconn | If you really want to do it that way, a clip file should voice itself, possibly preceded or followed by "clip" to indicate that this is the clip file |
| 11:17:14 | [IDC]Dragon | I don't like custom id3v2 tags |
| 11:17:51 | [IDC]Dragon | they apply only to mp3 files, and the files get changed in a proprietary way, good for nothing else |
| 11:18:44 | [IDC]Dragon | if every application adds their poop to a file, you carry all that crap around |
| 11:19:33 | [IDC]Dragon | with extra files, it's in the responsibility of the user, he decides on how much |
| 11:19:43 | amiconn | Yes, but on the other hand filename clips in a file clutter the directory with many additional files |
| 11:20:45 | amiconn | Plus, you get the problem to add a clip for a clip for a clip... unless you handle the special case and let a clip voice itself. |
| 11:21:22 | amiconn | The _dirname case wouldn't be a problem if dir and file clips get different extensions |
| 11:24:29 | [IDC]Dragon | nah, I don't like to confuse with another extension |
| 11:25:06 | [IDC]Dragon | the _dirname file case is exotic enough to ignore it, as long as we don't crash |
| 11:25:31 | [IDC]Dragon | and the script has to take care not to voice .talk files |
| 11:28:35 | | Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 11:39:14 | amiconn | [IDC]Dragon: If you implement filename clips, wouldn't there be a spinup each time you move the cursor in the browser, for the clip file lookup? |
| 11:56:39 | [IDC]Dragon | amiconn: like currently with directories, yes |
| 11:58:52 | [IDC]Dragon | lunch time |
| 12:00 |
| 12:08:12 | amiconn | Spinup for every file is bad. The clip file names could be cached in the dir buffer even if thy are not displayed, so there is no spinup if a clip file is not present. |
| 12:08:39 | amiconn | Of course this requires reworking the dir buffering (not displaying some cached filenames) |
| 12:21:54 | | Join webguest78 [0] (~d96ee3e8@labb.contactor.se) |
| 12:29:56 | | Quit webguest78 ("CGI:IRC") |
| 12:52:50 | *** | Saving seen data "./dancer.seen" |
| 12:54:59 | amiconn | [IDC]Dragon: A better approach (imho). Cache for every displayed file whether a clip file exists. This needs only one byte per entry |
| 12:55:16 | | Part Chronic007 |
| 12:59:52 | [IDC]Dragon | back again |
| 13:00 |
| 13:01:22 | [IDC]Dragon | amiconn: now I get you, I thought you meant spinups to actually play the clip |
| 13:18:08 | | Quit AciD (Read error: 104 (Connection reset by peer)) |
| 13:23:04 | amiconn | [IDC]Dragon: That spinup is of course unavoidable... |
| 13:28:50 | [IDC]Dragon | for a second I thougth you want to cache that |
| 13:30:59 | | Part Zagor |
| 13:31:42 | [IDC]Dragon | we have some free bits in entry.attr |
| 13:33:21 | [IDC]Dragon | so I could optimize, let's ask if the 3 swedes would like it ;-) |
| 13:36:08 | [IDC]Dragon | one of them just left :-( |
| 13:37:56 | LinusN | [IDC]Dragon: what's your idea with the attr field? |
| 13:38:42 | [IDC]Dragon | to have a bit for associated voice clip present or not |
| 13:39:39 | [IDC]Dragon | actually, attr is a short, followed by a 32 bit member, so 16 bits are wasted |
| 13:40:19 | [IDC]Dragon | plenty of space for whatever |
| 13:43:51 | LinusN | so the dir loader would check for corresponding clip files, set the attr bit in the struct, and maybe hide the clip file in the listing |
| 13:46:19 | [IDC]Dragon | I'm not sure yet how to build the file list with that flag, avoiding a search per found .talk file, but something like that, yes |
| 13:47:26 | LinusN | sounds ok to me |
| 13:49:20 | [IDC]Dragon | the association is the problem, or we have to consider the extra search time the price to pay for filename voicing |
| 13:50:37 | [IDC]Dragon | if the user deletes a file, should we delete the .talk file as well? (I'd say yes) |
| 13:51:23 | [IDC]Dragon | this was easier with a dir, because the file is inside |
| 13:55:22 | LinusN | i gnerally don't like the idea to delete another file in the process, but the .talk file is useless without the corresponding file |
| 13:55:41 | LinusN | so i think we could safely delete it as well |
| 13:58:37 | | Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 14:00 |
| 14:01:56 | amiconn | [IDC]Dragon: I thought you wanted to do the chunked .voice loading first. While the voice ui works fine on the Ondio, the load delay is a bit annoying. |
| 14:02:20 | | Join elinenbe [0] (~elinenbe_@65.115.46.225) |
| 14:07:18 | [IDC]Dragon | amiconn: I haven't talked about the order of things yet ;-) |
| 14:08:55 | [IDC]Dragon | the filename .talk patch is easy, leaving the tag bit apart for now, and helps a wider user base |
| 14:09:27 | [IDC]Dragon | sure the ondio needs a revision for its voice UI |
| 14:09:49 | [IDC]Dragon | mostly it needs a FAT16 fix |
| 14:09:58 | amiconn | Yes. |
| 14:10:25 | [IDC]Dragon | my USB board hasn't arrived yet |
| 14:11:16 | amiconn | I think the chunked .voice loading is not that difficult as well. First load only the table containing clip positions and lengths. The size of this table is known. Then load the clip by a seek and a read before voicing it |
| 14:14:25 | amiconn | I would be glad to help with the fat16 issue, doing some diagnostic output |
| 14:16:03 | [IDC]Dragon | no, "chunked voice" (sounds funny) should be easy, seek, read, play |
| 14:16:51 | [IDC]Dragon | for fat16, you're most welcome to hunt, sure |
| 14:18:01 | amiconn | As you were not around yesterday evening, I preferred to work on the MMC driver in the meantime |
| 14:18:30 | [IDC]Dragon | I worked on our house |
| 14:18:41 | [IDC]Dragon | any MMC news? |
| 14:19:45 | amiconn | Debug menu item is almost done, and I improved the parameter reading from CSD on init. For this, I borrowed your bit extracting function from settings.c |
| 14:20:11 | amiconn | Had to adapt it a bit, since I need the bits counted from MSB to LSB |
| 14:20:50 | [IDC]Dragon | it's always nice see my code reused :-) |
| 14:21:23 | [IDC]Dragon | do you have items overlapping byte/word boundaries? |
| 14:21:28 | amiconn | There was actually a bug in the timeout calculation (didn't influence behaviour, but could have for some MMCs |
| 14:21:49 | amiconn | (overlapping) yes, the CSD layout is rather weird |
| 14:22:18 | [IDC]Dragon | because, that's what this bit extractor is really for, masking aligned values is trivial |
| 14:23:04 | [IDC]Dragon | actually, it is even overpowered for the settings code, because there we don't exploit the random access |
| 14:23:38 | [IDC]Dragon | if th values are just read/written in a row, simpler shift register code could be used |
| 14:23:43 | amiconn | even byte aligned values aren't always trivial, e.g. there is a long that is not long aligned |
| 14:31:55 | amiconn | I don't need all values, so I don't read the values in a row |
| 14:37:00 | | Quit LinusN (burroughs.freenode.net irc.freenode.net) |
| 14:37:00 | NSplit | burroughs.freenode.net irc.freenode.net |
| 14:37:00 | | Quit mbr (burroughs.freenode.net irc.freenode.net) |
| 14:37:00 | | Quit Ka_ (burroughs.freenode.net irc.freenode.net) |
| 14:37:00 | | Quit Hadaka (burroughs.freenode.net irc.freenode.net) |
| 14:37:48 | | Join willows_m [0] (~willows_m@audiophile.demon.co.uk) |
| 14:37:53 | NHeal | burroughs.freenode.net irc.freenode.net |
| 14:37:53 | NJoin | mbr [0] (~mb@stz-softwaretechnik.com) |
| 14:37:53 | NJoin | Hadaka [0] (naked@naked.iki.fi) |
| 14:37:53 | NJoin | Ka_ [0] (~tkirk@pcp261180pcs.howard01.md.comcast.net) |
| 14:48:19 | NJoin | LinusN [0] (~linus@labb.contactor.se) |
| 14:51:14 | | Quit midk ("just STOP it arspy") |
| 14:52:53 | *** | Saving seen data "./dancer.seen" |
| 14:53:55 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 14:55:28 | | Quit midk (Client Quit) |
| 14:55:33 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 14:58:05 | | Quit midk (Client Quit) |
| 14:58:10 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 14:58:49 | | Quit midk (Client Quit) |
| 15:00 |
| 15:00:00 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 15:10:17 | | Quit willows_m (Read error: 110 (Connection timed out)) |
| 15:27:00 | * | Bagder detects an active LinusN |
| 15:29:54 | * | elinenbe detects an idle Bagder and LinusN |
| 15:40:52 | Bagder | "non constant or forward reference address expression for section .mp3end" |
| 15:41:10 | Bagder | LinusN: you read? |
| 15:41:57 | * | Bagder can't link |
| 15:42:05 | Bagder | building recorder |
| 15:43:47 | Bagder | time to feed a little girl! |
| 15:44:42 | | Join methangas [0] (methangas@0x50a461b8.virnxx10.adsl-dhcp.tele.dk) |
| 15:48:35 | LinusN | Bagder: fixed |
| 15:48:39 | elinenbe | LinusN: do the CVS changes mean anything big going on? |
| 15:48:50 | LinusN | elinenbe: not really |
| 15:49:01 | elinenbe | just getting ready? |
| 15:49:12 | LinusN | yeah, preparations |
| 15:51:03 | LinusN | gotta go now |
| 15:51:06 | LinusN | cu folks |
| 15:51:47 | | Part LinusN |
| 15:54:12 | | Quit elinenbe (" HydraIRC -> http://www.hydrairc.com <- The dawn of a new age") |
| 16:00 |
| 16:12:58 | | Join R3nTiL [0] (~zorroz@224-250-30-217.kgts.ru) |
| 16:15:13 | | Quit R3nTiL (Client Quit) |
| 16:21:28 | | Join mattzz [0] (~mattzz@c159065.adsl.hansenet.de) |
| 16:27:48 | | Quit mattzz ("Client exiting") |
| 16:37:06 | | Join mecraw [0] (~lmarlow@69.2.235.2) |
| 16:52:56 | *** | Saving seen data "./dancer.seen" |
| 17:00 |
| 17:19:47 | | Quit ashridah ("crapicus! 1:20am. sleep. SLEEEEEEEP") |
| 17:23:22 | | Quit AciD (Read error: 110 (Connection timed out)) |
| 17:28:16 | | Join gromit``` [0] (~gromit@ALagny-151-2-10-68.w82-121.abo.wanadoo.fr) |
| 17:36:46 | | Quit gromit`` (Read error: 60 (Operation timed out)) |
| 17:37:26 | amiconn | Bagder: Linus' latest changes caused >1200 warnings for the win32 simulator builds... |
| 17:50:05 | * | [IDC]Dragon browses on how that looks |
| 17:51:25 | [IDC]Dragon | impressive! |
| 17:51:57 | [IDC]Dragon | how many digits would fit into that column? |
| 17:52:41 | amiconn | It seems that all plugins have problems with the cpu include, but only for Win32 sim |
| 18:00 |
| 18:16:57 | | Join _aLF [0] (Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net) |
| 18:16:58 | _aLF | hi |
| 18:46:42 | | Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 18:50:16 | [IDC]Dragon | bye! |
| 18:50:19 | | Quit [IDC]Dragon ("CGI:IRC") |
| 18:52:59 | *** | Saving seen data "./dancer.seen" |
| 18:57:22 | | Join JackShadow [0] (~tim@suprimo-250.ping.de) |
| 20:00 |
| 20:22:39 | | Quit Headie (Read error: 110 (Connection timed out)) |
| 20:44:37 | | Join PRVSaosn [0] (PRV@AMontsouris-152-2-4-116.w82-123.abo.wanadoo.fr) |
| 20:44:42 | PRVSaosn | hi all |
| 20:44:53 | PRVSaosn | can suggest a good chan about iriver ? |
| 20:53:03 | *** | Saving seen data "./dancer.seen" |
| 20:57:32 | | Join Headie [0] (~hehe@fsto6.sto.sema.se) |
| 22:00 |
| 22:05:53 | | Join marc77 [0] (~marc@pub212004076150.hfc.datazug.ch) |
| 22:21:50 | | Join IRCMonkey [0] (~chatzilla@adsl-63-201-35-117.dsl.snfc21.pacbell.net) |
| 22:22:16 | | Join [IDC]Dragon [0] (~idc-drago@pD9FF80B1.dip.t-dialin.net) |
| 22:23:45 | | Quit IRCMonkey (Client Quit) |
| 22:24:57 | | Quit marc77 (Read error: 104 (Connection reset by peer)) |
| 22:25:00 | | Join marc77 [0] (~marc@pub212004076150.hfc.datazug.ch) |
| 22:33:48 | | Join scott666 [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
| 22:43:45 | amiconn | hi again Jörg |
| 22:45:26 | [IDC]Dragon | hello to Berlin |
| 22:46:17 | amiconn | I just committed my latest MMC enhancements, including debug menu info |
| 22:46:45 | [IDC]Dragon | oh, have to grab that |
| 22:47:12 | amiconn | Any news concerning FAT16 probs, or still searching? |
| 22:47:31 | amiconn | In that case I'll switch to FAT16 as well.. |
| 22:47:31 | [IDC]Dragon | not searching yet |
| 22:47:44 | [IDC]Dragon | first I need that USB board |
| 22:48:41 | amiconn | I can do target tests, and if we compare with the test code, maybe this will shed some light on the problem... |
| 22:49:35 | amiconn | Btw: Don't you have USB already? I can't imagine that... |
| 22:50:21 | [IDC]Dragon | sure I have USB(2), but it's unreliable |
| 22:50:31 | amiconn | Ah. |
| 22:50:42 | [IDC]Dragon | no good for larger transfers |
| 22:51:25 | amiconn | If you have some ideas what to try, but need the larger recorder screen, I could do some tests on the recorder as well, although this would require swapping HDs |
| 22:52:04 | [IDC]Dragon | let's try to avoid that for now |
| 22:52:26 | [IDC]Dragon | although I'll have to swap disks, too |
| 22:52:26 | amiconn | I still have my old 20 GB disk laying around in my cabinet. |
| 22:52:57 | amiconn | The only diff is that I have no serial mod (yet), hence no gdb |
| 22:52:59 | [IDC]Dragon | get a USB enclosure for it |
| 22:53:05 | *** | Saving seen data "./dancer.seen" |
| 22:54:12 | | Quit methangas (" Like VS.net's GUI? Then try HydraIRC -> http://www.hydrairc.com <-") |
| 22:54:26 | amiconn | I don't really need another one, as I have my recorder... |
| 22:55:25 | amiconn | I could sell it on eBay, or put it into the Studio (which has only 10 GB atm, and it's a Hitachi RLOD disk) |
| 22:56:18 | [IDC]Dragon | the 10 GB ones are also RLOD? |
| 22:56:38 | amiconn | Iirc the whole Hitachi DK23DA series is |
| 22:58:10 | amiconn | Although I didn't get a single RLOD yet, but ay be due to one of these facts: (1) I didn't use it much yet (2) I don't move it significantly while using it (3) Iirc there are no reports of RLOD on players (??) |
| 23:00 |
| 23:07:13 | PRVSaosn | please ? someone can suggest a good chan about iriver ? |
| 23:15:28 | amiconn | [IDC]Dragon: The problems seems to come from next_write_cluster() |
| 23:16:20 | * | [IDC]Dragon looks... |
| 23:17:14 | amiconn | The first file cluster is 26. At the cluster boundary, the next cluster returned is -8 |
| 23:18:00 | amiconn | Tracing... |
| 23:24:12 | amiconn | Next level: get_next_cluster() ... |
| 23:25:18 | [IDC]Dragon | not next_write_cluster()? |
| 23:25:26 | [IDC]Dragon | tracing the reads will drive you crazy |
| 23:25:26 | PRVSaosn | Dragon ? ami ? |
| 23:25:56 | | Quit JackShadow ("Verlassend") |
| 23:25:58 | amiconn | [IDC]Dragon: next_write_cluster() in turn calls get_next_cluster() which returns the -8 |
| 23:26:17 | amiconn | Tracing back the bad value... |
| 23:26:55 | amiconn | I have a suspicion, though it's strange why it works with the test code then... |
| 23:26:56 | [IDC]Dragon | for overwriting an existing file, yes |
| 23:28:42 | amiconn | It does also use it for extending an existing file |
| 23:29:23 | amiconn | ...which is true for all opened files from the 2nd cluster on |
| 23:37:06 | amiconn | [IDC]Dragon: Woohoo, found the reason! |
| 23:37:38 | amiconn | There are actually 2 problems: |
| 23:37:44 | [IDC]Dragon | ohhh |
| 23:38:21 | [IDC]Dragon | c'mon, tell me |
| 23:38:51 | amiconn | (1) The return value of read_fat_entry is signed, which is no problem for FAT32, since the value is ANDed with 0x0fffffff, so it'Äs always positive |
| 23:39:52 | amiconn | However, this ANDing is not done for the FAT16 case, and the return value gets sign-extended from short, so gets negative. Adding & 0xffff fixes this problem |
| 23:40:27 | [IDC]Dragon | better make it unsigned |
| 23:40:29 | amiconn | (2) (At least) with FAT16, the EOF mark is not only FFFF, but may be any value between FFF8 and FFFF. |
| 23:40:52 | [IDC]Dragon | FFF8 usually |
| 23:41:07 | amiconn | Yes, and that doesn't get detected as EOF |
| 23:41:49 | amiconn | Ah, I was wrong, so forget the 2nd problem |
| 23:42:05 | [IDC]Dragon | OK ;-) |
| 23:43:20 | amiconn | Where is SWAB16 defined? |
| 23:43:48 | [IDC]Dragon | system.h |
| 23:45:07 | amiconn | Ah. Btw, this explains why the bug doesn't occur with the test code: The test code runs on x86, which is little endian. For little endian, SWAB16 does nothing... |
| 23:45:38 | [IDC]Dragon | I was suspecting an endian porting issue |
| 23:45:58 | [IDC]Dragon | but not with tricky signed/unsigned |
| 23:46:23 | amiconn | You got the endianess right in this case, but SWAB16 returns short on SH1, which gets sign-extended... |
| 23:47:08 | [IDC]Dragon | I don't think these macros should be signed |
| 23:47:12 | amiconn | Maybe casting the SWAB16 return value to (unsigned short) is the best solution |
| 23:48:37 | amiconn | [IDC]Dragon: Should we dare to change them to unsigned? Maybe this will break other places in rockbox |
| 23:49:02 | [IDC]Dragon | it's "only" used in fat and ata |
| 23:49:25 | amiconn | There are SWAB16, SWAW32 and SWAB32... |
| 23:50:55 | [IDC]Dragon | same for SWAB32, but SWAW32 is unused |
| 23:51:37 | amiconn | Ok, let's change them to unsigned and see what will break.. |
| 23:51:57 | [IDC]Dragon | very daring tonight, are we? |
| 23:52:21 | [IDC]Dragon | it makes no sense to have a signed swap, imho |
| 23:55:00 | [IDC]Dragon | try on your scratch disk first, please |
| 23:55:11 | amiconn | I'll do so |
| 23:55:23 | [IDC]Dragon | ;-) |
| 23:55:25 | amiconn | Perhaps I should also test FAT32... |
| 23:55:49 | [IDC]Dragon | better yes |
| 23:58:46 | [IDC]Dragon | and with PREFER_C_READING, because then the ata code does SWAB16 |
icon identifies that the person is a core developer (has commit access).