--- Log for 06.10.104  Server: burroughs.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 1 day and 23 hours ago

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.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.52.37 ***     Saving seen data "./dancer.seen"
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.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.14.00 Quit    midk (Remote closed the connection)
05.15.51 Join    midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com)
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.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.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.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.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.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.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.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.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.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.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.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.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.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.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.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