--- Log for 02.01.111 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 2 days and 19 hours ago 00.00.01 # generally just because two SD cards are packaged the same doesn't mean they're the same internally 00.00.32 # sorrowly :) 00.01.03 # I already even tried to dd the image of the working card to the unrecognized 00.01.08 # no success 00.02.41 # probably just a bug in our controller driver that only occurs with some cards 00.02.58 # Hi everyone! I have just made a post about the vibe 300 in the forum, take a look if you're interested in a new port. 00.05.38 # i really doubt anyone here is interested 00.05.57 # Hi everyone! 00.05.57 # I've owned a Packard Bell Vibe 300 for aroud 4 years (It was a christmas gift), the first thing I made when it was given to me was to take a look around here for a port, but there was none :'( 00.06.27 # crap, this irc client, I pasted all that without wanting 00.06.47 # So who might have info to help me develop a new port? 00.08.22 # have you seen this: http://www.rockbox.org/twiki/bin/view/Main/NewPort 00.09.15 # I'm reading it right now, its quite light on technical details 00.09.35 # yeah, you pretty much have to figure those our yourself 00.10.30 # thomasjfox, I appear to have forgotten the root password of my N810! 00.10.36 # The thing is, having the same portalplayer chip as some supported players it might be more or less easy 00.10.46 # soap: trustno1? 00.10.52 # i guess a good first step would be to figure out how to recover from a bad flash 00.11.17 # then dig through the firmware file and see if you can figure out which GPIO pins go where 00.11.32 # wah_wah_69: it's going to be easier than some ports, yes 00.11.39 # I don't know this even is flashable, it has an mi4 file in the sytem directory 00.11.47 # then try to blink the lights on or something 00.12.10 # soap: On the n900 it usually works by "sudo gainroot" or "root" in the terminal 00.13.09 # yes thats the "normal" PP method, the H10 and i think Phillips players use that 00.13.37 # oh, thomasjfox, I set a root password years ago. But my "default" root password isn't working. 00.13.56 # comparing to this page for the H10 might be interesting: http://www.rockbox.org/wiki/IriverH10PortDevInfo 00.13.59 # soap: Can you open a normal user terminal? 00.14.00 # Also the mr100, the samsungs, and I think the vibe500 00.14.15 # thomasjfox, yes 00.14.33 # Try if you have the "root" or "sudo gainroot" stuff installed. Then you don't need the password 00.14.37 # Well, some of them use a different filename, but that's not very important 00.15.20 # thanks saratoga! I should have found thank link myself. 00.15.29 # thomasjfox, "Enable RD mode to gain root privileges" 00.15.49 # install the rootsh package from maemo.org 00.15.53 # then sudo gainroot 00.16.14 # you can't become root without installing something or turning on R&D mode with flasher, but that has other sideeffects 00.16.47 # wah_wah_69: also this page: http://www.rockbox.org/wiki/SamsungYH92xPort 00.18.19 # does it also have a .ROM file in the system folder? if so that may contain the recovery code if you flash a bad .mi4 file 00.18.24 # Torne, yea that's what google is telling me. I would have sworn I went through all this ages ago. 00.18.45 Quit TheSeven (Disconnected by services) 00.18.46 Join [7] [0] (~TheSeven@rockbox/developer/TheSeven) 00.20.13 # saratoga, yes it has a file called pp5020.mi4 in the system directory 00.20.38 # gevaerts: I found something out about the pulseaudio CPU usage 00.20.48 # I wish someone would make a port for the Insignia Pilot 00.21.03 # The protection for the speakers just kicks in at a certain global volume level 00.21.13 # Tim_Elliott: New Year's wishes should be made in December 00.21.19 # So CPU is about 7% lower if I keep the volume below that 00.21.22 # Not on demand.. blah.. interested owners.. blah.. etc. etc. 00.21.31 # thomasjfox: interestin 00.21.31 Quit feisar- (Ping timeout: 276 seconds) 00.21.33 # g 00.21.37 # it boots as USB mass storage just by plugging an usb cable, so it might be easy to recover 00.21.43 Quit bertrik (Quit: CGI:IRC) 00.22.43 # gevaerts: Maybe we should set an initial volume on application startup just a bit below that level 00.23.41 Quit kugel (Remote host closed the connection) 00.23.44 *** Saving seen data "./dancer.seen" 00.23.47 # thomasjfox: can you detect speakers vs headphones, and then set a limit in rockbox a fraction below that when on speakers? 00.24.03 # As it'd make no difference to the max, but save a load of power by the sounds of it 00.24.13 # Alexp: Should be possible 00.24.26 # thomasjfox, big issue is that rockbox doesn't show up as a running application, 00.24.47 # thomasjfox: do we want to touch the global volume at all? 00.25.02 # gevaerts: Maybe just once? 00.25.18 # soap: But you are able to run it? 00.25.23 Quit tuxifier (Remote host closed the connection) 00.25.23 # I know I'd be annoyed if apps all think they should set the volume for me 00.25.24 # saratoga, it has some other files but none are called *.rom, there's a sysinfo.ini file which contains some info, is seems to have been generated by the firmware updater, this line is the one that references the bootloader: Bootloader=BL_pp6005_5020_color.rom 00.25.53 # gevaerts: We could make it a platform based option 00.26.14 # thomasjfox, I have no music on my N810, but elsewise it runs fine. I'll load some music when I find a micro cable 00.26.35 # thomasjfox: the way I see it, rockbox is an *application* on maemo. It shouldn't try to take over the system in any way 00.26.41 # soap: hehe, you really haven't used it in a long time 00.27.06 # gevaerts: Hmm. On the other hand is saves quite some CPU 00.27.12 # I use it every day, but it is an appliance to me. 00.27.18 # Yes, but it's not CPU *we* are wasting 00.27.45 # everything I need is installed (fbreader, claws mail, ssh) and that's all I do. 00.28.19 # gevaerts: What if we make this a platform option and only set the volume if 1. it's on speakers and 2. it's above the limit (=don't touch lower volumes) 00.28.24 Quit BlakeJohnson86 (Quit: Leaving.) 00.28.55 # thomasjfox: well, to put it simply, if I installed an audio player that did that, I'd report it as a bug 00.29.08 # gevaerts: It should be configurable of course 00.30.15 # I don't like the idea much either - but it's a cheap way to save CPU :) 00.31.44 Quit Keripo (Quit: Leaving.) 00.31.45 Quit ender` (Quit: Information travels more surely to those with a lesser need to know.) 00.32.51 Quit Buschel (Ping timeout: 265 seconds) 00.37.41 Join factor [0] (~factor@75.108.68.114) 00.39.12 Quit chattr (Ping timeout: 240 seconds) 00.41.43 Join chattr [0] (~mike@244.87.189.72.cfl.res.rr.com) 00.42.56 # soap: Can you just download a mp3 of the net for testing? Here's a free track: http://simonv.com/music/mp3/SIMON_V-Stand_by_V.mp3 00.43.42 # soap: Would be nice to get some CPU load info when the display is on/off 00.45.52 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 00.49.49 Join froggyman [0] (~seth@unaffiliated/froggyman) 00.50.51 Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 00.51.39 Quit GuySoft (Ping timeout: 246 seconds) 00.53.30 Quit thomasjfox (Remote host closed the connection) 00.53.38 Join Strife89 [0] (~Strife89@adsl-80-182-157.mcn.bellsouth.net) 00.54.58 Quit Tim_Elliott (Ping timeout: 272 seconds) 00.58.31 Join GuySoft [0] (~guysoft@bzq-109-64-46-137.red.bezeqint.net) 01.00.33 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 01.04.16 Quit GuySoft (Ping timeout: 276 seconds) 01.05.01 Join eRivas [0] (~je@190.150.0.99) 01.05.50 # is it possible to have a volume icon that will display volume level only when it is changed? 01.07.05 Join mikroflops_ [0] (~yogurt@h-34-71.A238.priv.bahnhof.se) 01.07.06 # yes 01.08.02 # at least i'm pretty sure it is, take a look ath the CustomWPS page for the details 01.08.37 # in the manual? 01.09.09 # the wiki is probably better but the manual has the wps tags too 01.10.00 # ok, I've already taken a look at the tags, what I don't understand is how to handle the events, since the numeric display won't be always visible 01.10.12 Quit mikroflops (Ping timeout: 246 seconds) 01.10.37 # umm, you should be able to do it 01.10.41 # let me have a quick look 01.11.15 Part domonoky 01.12.18 # eRivas: you can do %?if(%bl, >, 90) 01.12.40 # 90 is the % level which you want to define as "close enough to fully charged" 01.12.58 # oh woops... changed not charged 01.13.03 # no, you cant do that 01.13.16 # I saw something like that in the failsafe theme 01.13.31 # you can do it for volume, not battery 01.13.43 # yeah, volume I said 01.13.57 # wtf? i'm still asleep here :p 01.14.20 # hahaha, so an if is the way to go? 01.14.39 Quit kadoban (Ping timeout: 240 seconds) 01.14.53 # no, there is a actual tag for volume changing 01.15.22 # %?mv<%pv> is what you want 01.15.45 # ok, the wiki has more of this? 01.15.48 Join GuySoft [0] (guy@bzq-79-179-5-239.red.bezeqint.net) 01.16.29 # http://www.rockbox.org/wiki/Main/CustomWPS#Increasing_47Decreasing_Volume 01.16.58 # excellent, thanks a lot 01.17.13 Join feisar- [0] (jljhook@irkki.fi) 01.18.09 # so, if %mv is true, show numbers, else, show icon? 01.19.29 # that gets more complicated 01.19.30 Quit antil33t (Read error: Connection reset by peer) 01.19.58 # %?mv<%pv|%pv(stuff to make it a bar)> or you can do a icon strip also 01.21.30 # yes, I already have the strip 01.22.49 # current code: 01.22.50 # %?pv<%xd(da)|%xd(db)|%xd(db)|%xd(dc)|%xd(dc)|%xd(dd)|%xd(dd)> 01.22.52 Join Rob2222 [0] (~Miranda@p4FFF03A1.dip.t-dialin.net) 01.23.01 # with volume icon declared as d 01.25.08 Join webguest91 [0] (~48802c70@giant.haxx.se) 01.27.25 Quit webguest91 (Client Quit) 01.27.49 Join webguest94 [0] (~48802c70@giant.haxx.se) 01.27.54 Quit webguest94 (Client Quit) 01.35.23 Quit n1s (Quit: Lämnar) 01.37.52 Join markun [0] (~markun@5ED33C2C.cm-7-4a.dynamic.ziggo.nl) 01.37.52 Quit markun (Changing host) 01.37.52 Join markun [0] (~markun@rockbox/developer/markun) 01.46.20 # when I declare and image to be preloaded, I can specify coordinates, are these coordinates relative to the viewport containing the image or are they absolute? 01.46.30 Join Keripo1 [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 01.48.26 Quit Keripo (Ping timeout: 250 seconds) 01.50.46 Join DerPapst [0] (~Alexander@91-66-226-46-dynip.superkabel.de) 02.01.22 # eRivas: viewport 02.02.43 # and can I use math operations, I'm thinking of displaying vol as positive integers, as opposed to the true -dB approach 02.02.53 Quit feisar- (Read error: Operation timed out) 02.03.18 # so if min vol is -81 dB, I would like to do %pv+81 02.04.23 # no 02.05.03 Quit mortalscan (Ping timeout: 240 seconds) 02.06.13 Quit froggyman (Ping timeout: 260 seconds) 02.08.40 Join AndyI [0] (~pasha_int@212.14.211.84) 02.10.20 Join antil33t [0] (~Mudkips@124-197-51-80.callplus.net.nz) 02.11.16 Quit antil33t (Client Quit) 02.11.38 Join antil33t [0] (~Mudkips@124-197-51-80.callplus.net.nz) 02.15.32 Join JesusFreak316_ [0] (~JesusFrea@pool-173-65-105-252.tampfl.fios.verizon.net) 02.23.47 *** Saving seen data "./dancer.seen" 02.26.17 # <[7]> oh my. 02.26.41 # <[7]> do i understand correctly that the ATA layer doesn't handle splitting too-large transfers for non-lba48 drives? 02.28.06 Quit JesusFreak316_ (Remote host closed the connection) 02.42.28 # * [7] spots a rockbox main menu on his ipod classic's LCD :) 02.42.48 # \☺/ 02.42.56 # Congratulations! 02.43.05 # * [7] needs to figure out why the clickwheel doesn't work :/ 02.43.30 # <[7]> might be as trivial as me forgetting to unmask an IRQ 02.45.11 # * [7] was right :) 02.45.31 # * [7] browses folders on the disk 02.46.51 # <[7]> four more things that need to be looked into rather soon: 02.47.00 # <[7]> - enable caches 02.47.10 # <[7]> - make codecs/plugins compile 02.47.20 # <[7]> - implement ata dma 02.47.37 # <[7]> - figure out why Buschel's LCD code doesn't work 02.59.20 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 03.00.57 Join feisar- [0] (jljhook@irkki.fi) 03.02.35 Join einarin [0] (~johnny@207-224-41-189.hlrn.qwest.net) 03.05.22 Quit feisar- (Ping timeout: 246 seconds) 03.05.37 # is there someone around who could help me with the Sansa AMS recovery mode? 03.11.28 # einarin: maybe, but i've never tried it myself 03.14.49 Quit timccc (Ping timeout: 246 seconds) 03.16.06 # I would like to suggest new strings available for translation: in, of 03.16.18 Join jduley [0] (~ca24b342@giant.haxx.se) 03.17.26 Quit DerPapst (Quit: Leaving.) 03.19.01 # * [7] spots a nice cabbiev2 backdrop :) 03.19.36 # <[7]> plugins fail with "incompatible model", whatever that means 03.20.06 Join mortalscan [0] (~mortalsca@173-166-0-166-newengland.hfc.comcastbusiness.net) 03.20.46 # they check to make sure they're compiled for the right target ID IIRC 03.21.00 # <[7]> yeah, but why doesn't it recognize it's own id? 03.21.07 Join timccc [0] (~timccc@112.166.15.141) 03.21.11 # <[7]> i.e. where did i forget to change it? 03.21.32 # i think you have to set it in configure and maybe the target.h file 03.21.35 # not sure though 03.23.23 # saratoga: Hi, has anyone looked at fixing pause/unpause squeak on the clip+ FS#11812? 03.23.32 # no i don't think so 03.23.38 # i just noticed it recently actually 03.23.55 # it doesn't happen with my usual headphones so i'm not too concerned ;) 03.24.39 Quit mortalscan (Ping timeout: 240 seconds) 03.25.11 # I just heard from another person who experiences it so was wondering if it was something worth fixing 03.26.30 # its worth fixing 03.26.44 # if someone posts a patch i'll confirm and then commit it 03.30.53 # ok I wouldn't have a clue where to start with a patch so it won't be me. Do you think it happens on all AMSv2 devices as that other guy had it on his Fuze v2? 03.31.13 # Thomasjfox, I promise to be less apathetic towards Rockbox on the N810 tomorrow if you highlight me. 03.32.56 # <[7]> hm, the target id in the plugins seems to be correct 03.33.03 # <[7]> where's the target id that the loader checks? 03.36.13 # you should probably ask kugel or someone in the morning 03.36.19 # plugins aren't the most important thing anyway 03.36.34 # <[7]> but codecs are :) 03.36.43 # hmm yes good point 03.37.10 # * [7] wonders if it will reach 10% realtime in its current state 03.38.10 # [7]: codecs.c 03.38.12 # around line 200 03.38.49 # <[7]> i spotted it in the plugin code in the meantime, and both values are 0x47, so it must be something else 03.39.01 # oh you said model, not version 03.39.04 # heh i have no idea 03.39.10 # i'm actually a little surprised we check for that 03.41.03 # [7]: it compares TARGET_ID as defined in teh codec to TARGET_ID as defined in the main binary 03.41.47 # <[7]> it's probably the load address that's making it fail 03.41.58 # yeah i don't see anyway they could be different 03.49.18 # New commit by 03saratoga (r28942): Commit part of FS#11748 by Michael Hohmuth. Adds support for automatically resuming any song that is not played to completion at any point later in ... 03.50.02 Join froggyman [0] (~seth@unaffiliated/froggyman) 03.50.07 # <[7]> yeah, was indeed a linker script problem 03.50.29 # saratoga: on the sansaAMSunbrick page, it says to dd orig_image.bin to the device, but they don't say what orig_image is or how to make one 03.51.56 # einarin: its just a copy of the front of the NAND chip from a working player 03.51.56 # r28942 build result: 46 errors, 0 warnings (saratoga committed) 03.51.59 # bah 03.52.21 # <[7]> hm, i'd really like to get that port into SVN, but it requires those ATA changes that haven't been tested on other targets 03.52.34 # damn archos! 03.54.39 Quit froggyman (Ping timeout: 240 seconds) 03.57.05 # huh i don't understand why archos is different here 03.57.24 # how do I use the %Re tag, just insert it or specify alternatives? 03.58.13 Quit GuySoft (Ping timeout: 260 seconds) 03.59.12 Join GuySoft [0] (guy@bzq-79-179-5-239.red.bezeqint.net) 04.00.26 Quit xavieran (Ping timeout: 255 seconds) 04.01.04 Quit [7] (Disconnected by services) 04.01.05 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.01.51 Join feisar- [0] (jljhook@irkki.fi) 04.05.57 # woah! 04.06.05 # we're getting closer 04.06.14 # * TheSeven needs to fix audio tomorrow 04.06.38 # it plays back the first second correctly, and then it goes nuts 04.06.44 # ok i have no idea whats going on, how can an extern variable in tagcache.c to playback.c work on SWCODEC but not on HWCODEC? 04.06.54 Quit feisar- (Ping timeout: 265 seconds) 04.07.05 # USB seems to work apart from it exposing a wrong sector size 04.08.46 # wait 04.09.01 # HWCODEC uses playback.c right? 04.10.00 # * TheSeven falls asleep... it's 4AM again 04.13.25 Join xavieran [0] (~xavieran@ppp118-209-79-106.lns20.mel4.internode.on.net) 04.13.30 # ugh this is going to be hard to fix without talking to a HWCODEC person 04.15.17 # saratoga: wassup? 04.15.39 # i didn't realize HWCODEC works completely different then SWCODEC for handling track changes 04.16.08 # i can make it compile, but i have no idea if this automatic resume feature will even work as implemented on HWCODEC 04.16.15 # and i have no device to try it on 04.16.40 # ahem... we should fork hwcodec out and drop it 04.16.44 # yes 04.16.48 # but anyway 04.17.10 # how limited is HWCODEC? i thought it just used a DSP but was otherwise pretty similar in terms of buffering and playback, but it looks like that is not the case 04.17.25 # does it make sense to support resume on it? 04.18.25 # I assume so 04.19.11 # anyone got a HWCODEC player handy to test something? 04.19.21 # Massive assumption, but I dont tihnk the hwcodecs would sell very well if they couldnt resume mid track :p 04.19.46 # or can I do this in the sim (does the sim even work work for HWCODEC)? 04.19.51 Quit jduley (Quit: CGI:IRC) 04.19.57 # sim is not simulated for hwcodec at all 04.20.05 # s/sim/playback/ 04.20.06 # amazing 04.20.13 Join Barahir_ [0] (~jonathan@frnk-590f4df5.pool.mediaWays.net) 04.20.25 # who actually has one of these devices 04.20.51 # RockboxTesting ... 04.21.15 # I have an ajbr but not with me, and most of the hwcodec owners are *difficult* to get to test things 04.21.29 # yes the wiki suggests you 04.21.41 Quit Barahir (Read error: Operation timed out) 04.21.58 # can I use playlist name - %pn - as a condition for an if? 04.22.06 # Llorean LambdaCalculus379 04.22.09 # one of you be online 04.22.14 # eRivas: yes 04.22.19 # ok 04.22.30 # saratoga: #ifdef if out.. doesnt it require the db anyway which isnt on the lowmem targets? 04.22.34 # or am i confusing things? 04.23.04 # the player has the database 04.23.42 # eRivas: what sort of check do you want to do with it? I *think* %?pn is true when you play from a m3u (and maybe directory) and false when its a dynamic playlist 04.23.48 *** Saving seen data "./dancer.seen" 04.24.24 # JdGordon|: %?pn<%pn> 04.24.33 # yeah that would prob work 04.24.39 # thanks 04.26.38 # saratoga: two options, 1) #ifdef it out and leave it untill someone can test, 2) make it compile and wait for complaints/verification that it works 04.26.51 # JdGordon|: how do I use the %Re tag, just insert it or specify alternatives? 04.27.00 # if i understand mpeg.c correctly, its not going to work as currently implemented 04.27.05 # the danger with 2) is what happened to me, 6+months before finding out it is broken 04.28.33 # what the hell does hwcodec actually include then 04.28.44 # eRivas: like all tags, it depends what you want... %Re will show some text, %?Re gives you more control 04.28.45 # i just realized i don't know if i've ever looked at a rockbox source file it uses before now 04.29.23 # JdGordon|: it's just that I insterted it alone and will only show aiff, other encoders will not be shown 04.29.35 # JdGordon|: so I guess I must specify my text 04.31.51 Quit kadoban (Quit: bye) 04.32.07 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 04.39.36 Join fyrestorm [0] (~nnscript@cpe-69-203-144-35.si.res.rr.com) 04.39.46 Quit kadoban (Ping timeout: 265 seconds) 04.43.16 Quit GuySoft (Ping timeout: 264 seconds) 04.44.13 Quit JdGordon| (Ping timeout: 260 seconds) 04.49.23 Quit pixelma (Disconnected by services) 04.49.24 # New commit by 03saratoga (r28943): Blind commit a 'fix' for automatic resume on HWCODEC since I don't understand HWCODEC and have no way to test builds for it. For now just disable it. ... 04.49.26 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.49.28 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.50.50 Quit amiconn (Disconnected by services) 04.50.51 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.50.54 # r28943 build result: All green 04.51.08 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.51.10 # fuck still wastes 100 bytes on HWCODEC 04.51.38 # amiconn: (for the logs) can you comment on how this should be fixed in FS#11748? 05.01.31 Quit factor (Ping timeout: 265 seconds) 05.03.05 Join feisar- [0] (jljhook@irkki.fi) 05.03.10 Quit TheSeven (Ping timeout: 240 seconds) 05.07.43 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 05.14.37 # is there a radio token to indicate radio muted? 05.14.59 Join factor [0] (~factor@75.108.68.114) 05.16.41 # saratoga: thanks 05.17.06 Quit Rob2222 (Ping timeout: 272 seconds) 05.17.42 Quit wah_wah_69 (Ping timeout: 276 seconds) 05.49.42 Quit einarin (Ping timeout: 276 seconds) 05.51.00 Join wah_wah_69 [0] (~io@212.225.156.123) 05.51.18 Join einarin [0] (~johnny@207-224-41-189.hlrn.qwest.net) 05.57.33 Quit MethoS- (Remote host closed the connection) 06.01.06 Join fyre^OS [0] (~nnscript@cpe-69-203-144-35.si.res.rr.com) 06.03.34 Quit eRivas (Quit: Saliendo) 06.04.52 Quit fyrestorm (Ping timeout: 264 seconds) 06.07.50 Join JdGordon| [0] (~jonno@124-149-188-197.dyn.iinet.net.au) 06.07.50 Quit JdGordon| (Changing host) 06.07.50 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 06.09.13 Quit einarin (Quit: leaving) 06.11.42 Quit wah_wah_69 (Read error: Connection reset by peer) 06.14.08 Quit parafin (Ping timeout: 276 seconds) 06.20.15 # * JdGordon| wonders if hwcodec can be simulated on swcodec by setting up a virtual MAS 06.23.36 Join binaryhermit [0] (~binaryher@adsl-70-131-127-225.dsl.emhril.sbcglobal.net) 06.23.52 *** Saving seen data "./dancer.seen" 06.24.34 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 06.26.00 Join binaryhermit_ [0] (~binaryher@adsl-99-135-145-17.dsl.emhril.sbcglobal.net) 06.26.13 Quit binaryhermit_ (Read error: Connection reset by peer) 06.28.35 Quit factor (Ping timeout: 240 seconds) 06.30.04 Quit binaryhermit (Ping timeout: 264 seconds) 06.48.38 Quit JdGordon| (Quit: Lost terminal) 06.49.29 Join JdGordon| [0] (~jonno@124-149-188-197.dyn.iinet.net.au) 06.49.29 Quit JdGordon| (Changing host) 06.49.29 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 07.09.28 Join GuySoft [0] (guy@bzq-109-67-22-249.red.bezeqint.net) 07.16.12 Quit Keripo1 (Quit: Leaving.) 07.45.33 Join leavittx__ [0] (~lev@MS-159-112.dyn-ip.SPb.SkyLink.RU) 07.46.39 Join Thopter [0] (~AbuMaia@208.123.144.34) 07.49.10 Quit leavittx_ (Ping timeout: 276 seconds) 07.50.42 # I'm new to Rockbox, having installed it via the Rockbox Utility on my Clip+ 8GB earlier today. I found a language quiz patch that I would like to install, but I'm not sure how to go about doing that. All the info I've read about adding patches talks about using diff files, but this patch is provided as a .c file. Can someone point me to some instructions somewhere that could get me through? 07.52.48 Join Horschti [0] (~Horschti@xbmc/user/horscht) 07.57.07 Quit Horscht (Ping timeout: 276 seconds) 08.01.01 Quit xavieran (Ping timeout: 276 seconds) 08.05.00 Join froggyman [0] (~seth@unaffiliated/froggyman) 08.11.49 Join parafin [0] (parafin@paraf.in) 08.13.03 Quit JdGordon| (Quit: Lost terminal) 08.13.49 Join xavieran [0] (~xavieran@ppp118-209-79-106.lns20.mel4.internode.on.net) 08.23.54 *** Saving seen data "./dancer.seen" 08.26.14 Join saratoga_ [0] (9803c22e@gateway/web/freenode/ip.152.3.194.46) 08.31.53 Join mortalscan [0] (~mortalsca@173-166-0-166-newengland.hfc.comcastbusiness.net) 08.39.09 Quit user890104 (Ping timeout: 272 seconds) 08.40.04 Join user890104 [0] (~Venci@6bez10.info) 08.48.41 Quit antil33t () 08.53.00 Join JdGordon [0] (7c95bcc5@gateway/web/freenode/ip.124.149.188.197) 09.08.30 Quit fyre^OS (Quit: Ur skills' fireproof like a wooden panel -- U got feds talking leet on your IRC channel!) 09.11.29 Join [Saint] [0] (S_a_i_n_t@203.184.3.36) 09.36.29 Quit JdGordon (Ping timeout: 265 seconds) 09.46.23 Join bmbl [0] (~bmbl@unaffiliated/bmbl) 10.00.25 Quit xavieran (Ping timeout: 246 seconds) 10.14.36 Join xavieran [0] (~xavieran@ppp118-209-79-106.lns20.mel4.internode.on.net) 10.16.44 # TheSeven: DMA for LCD updates still has advantages even if the main thread needs to be blocked until completion: Other threads can run meanwhile (e.g. codec) 10.17.47 Quit mortalscan (Ping timeout: 240 seconds) 10.23.15 Quit BHSPitMonkey (Remote host closed the connection) 10.23.57 *** Saving seen data "./dancer.seen" 10.33.31 # saratoga: Hwcodec does not use playback.c at all. It has its own (considerably less complex) playback engine, in mpeg.c 10.34.12 Join icarusfactor [0] (~factor@75.108.68.114) 10.35.14 Quit icarusfactor (Remote host closed the connection) 10.35.37 Join icarusfactor [0] (~factor@75.108.68.114) 10.38.12 Join factor_ [0] (~factor@75.108.68.114) 10.38.17 Join n1s [0] (~n1s@rockbox/developer/n1s) 10.38.57 # * pixelma doesn't think she is "difficult to test things" 10.39.04 # +get to 10.39.16 Nick icarusfactor is now known as factor (~factor@75.108.68.114) 10.39.40 # the only thing about testing on the Ondio is that putting on test builds takes ages (if I need everything) 10.39.53 Quit factor_ (Read error: Connection reset by peer) 10.42.45 Join ender` [0] (krneki@foo.eternallybored.org) 10.53.30 # <[Saint]> It's amazing enough you even *have* the Ondio 10.53.38 # <[Saint]> let alone more than one. 10.54.38 # huh, I only have one Ondio. And it's a nice player with better sound quality than the other players I have 10.55.17 # <[Saint]> Oh...sorry. I thought you had two. And yeah, they're not a bad player at all. I've only ever seen one "in the wild" though. 11.00.05 # amiconn: so basically if we want to have this work, I'd have to figure out how mpeg.c works then tie it into that playback engine at the right spots? 11.03.21 # saratoga_: does this feature need the database in RAM or only the database? 11.04.06 # its about the automatic resume feature 11.04.30 # yes, but your commit message mentions that it is tied to the database 11.04.43 # it requires some changes to playback.c (basically to actually set the resume positions) 11.05.35 Join stoffel [0] (~quassel@p57B4B791.dip.t-dialin.net) 11.05.36 # it stores stuff in the database yeah, but the problem is actually getting track changes to use that information on HWCODEC 11.06.47 # it's just that if it needs the database in RAM then it's not worth looking into integrating it into hwcodec since those targets are lowmem so don't have the option to load the database into RAM (just that part isn't available there), that's al 11.06.49 # l 11.07.10 # i don't think it needs to be in RAM 11.09.39 # I remember that gather runtime data needed a few fixes to get to work properly on hwcodec but made to work in the end 11.16.22 Join fml [0] (~5df3c93d@giant.haxx.se) 11.16.50 Join pamaury [0] (~quassel@dhcp-129-228.residence.ens-lyon.fr) 11.16.50 Quit pamaury (Changing host) 11.16.50 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.16.56 # Hello. There is a typo in the last commit. In settings.h, the comment for the new settingis wrong (copy-paste?). 11.17.26 # ...but I can't fix it now. 11.17.31 Quit fml (Client Quit) 11.17.44 # Imo multi-resume is a rather esoteric feature. I fail to see a use case... 11.18.40 # something with podcasts and/or audiobooks 11.18.55 # For automatic multi-resume, that is. Doing it manually has been possible for years already, using bookmarks 11.21.00 # Bookmarks have the further advantage that they don't require the database, while the new multi-resume seems to 11.24.13 # <[Saint]> unfortunate;y, this conversation has been had before...I would have preferred to see functionality of bookmarking increased if it actually needed it. 11.24.21 # <[Saint]> *unfortunately 11.25.36 Join kevku [0] (~kevku@2001:7d0:0:f000::135d) 11.27.40 # indeed, and I didn't really see a consensus or at least something close in the thread 11.27.58 # I was even a bit surprised to see the commit now 11.29.01 # <[Saint]> As was I, I thought it was still very much "up in the air". 11.29.38 # amiconn: The problem is the current bookmarking feature doesn't work with the database. 11.30.06 # To me, the reasonable solution would've been to fix bookmarking to work with the database, and then add a "if a bookmark is present when file is played, automatically resume the most recent bookmark" option. 11.31.16 # <[Saint]> the impression I got was "yeah, but...that's too hard, and I already did this". 11.31.36 # I don't complain too loud becaus I didn't take part of the discussion on the ml but I felt that all I wanted to say has been said (I mostly agree/d with Llorean) and the thread had already become so long :\ 11.31.47 # *part in 11.32.37 # [Saint]: I don't like the idea that a less ideal solution should be used because a good one hasn't completed yet - they're hard to remove later, and it just leads to a pile of half-features interacting in weird ways. 11.32.39 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 11.32.57 # But I think I'm in the minority of preferring to have things wait until a "good" solution to a problem comes along. 11.33.13 # * Llorean still feels Rockbox has gotten progressively buggy for a while now. 11.33.18 # I think the same way 11.34.21 # <[Saint]> I've sat back, because the last time I got truly empassioned about something I thought was totally the wrong direction to head in...it fel on deaf ears. 11.34.31 # <[Saint]> As lons as it has an off button, fine with me. 11.34.46 # <[Saint]> *long 11.35.48 Join Topy44 [0] (~Topy44@f048144099.adsl.alicedsl.de) 11.36.29 Quit Topy (Read error: Connection reset by peer) 11.37.42 Join JdGordon| [0] (~jonno@124-149-188-197.dyn.iinet.net.au) 11.37.42 Quit JdGordon| (Changing host) 11.37.42 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 11.38.11 # imo the really buggy stuff is in playback.c, and this doesn't seriously impact that one way 11.38.39 # since the changes are pretty trivial and don't impact how playback.c works unless you enable automatic resume 11.39.08 # but the point of "implemented half-baked feature" still stands, IMO 11.39.08 # otherwise you just 'else' into the old case 11.39.17 # i don't think so 11.39.24 # its not obvious to me how you could implement this better 11.44.12 # Fix bookmarking instead of adding a new feature? It serves basically the same purpose. 11.47.06 # from my point of view bookmarking is essentially an even worse implementation of a less useful feature 11.47.36 # while having a manual way to set resume points could be useful, its a pretty silly way to do things when you can quite easily do it automatically 11.48.08 # in the long term i just assumed we'd get rid of book marking and allow a way to manually set resume points in the database if people thought it was useful enough 11.48.33 # why is it less useful? And from a user's point of view, I prefer the bookmarking implementation since it doesn't need the database 11.48.53 # You'd be losing a lot of functionality if you took away having multiple bookmarks in a single file. 11.49.05 # I don't know what you mean with automatic and manual there 11.50.10 # <[Saint]> is there not already automatic bookmarking? 11.50.16 # you prefer it because it doesn't do things the correct way? 11.50.18 # <[Saint]> didn't Torne work on that? 11.50.33 # [Saint]: Yes. But there's not automatic resume of bookmarks (unless I missed that being added) and bookmarks don't work with the database. 11.50.39 # from a users point of view how is that a preference? 11.51.07 # saratoga_: what is the "correct" way? Not relying on another feature I need to explicitely enable if I don't use it? 11.51.32 # the database is the correct way to store metadata about tracks 11.52.00 # its literally what a database does 11.52.35 # resume points aren't metadata in my eyes, it's a playback/playlist thing 11.53.13 # playback data about a specific file thats unrelated to the current state of the playback engine is metadata 11.54.16 # Playback state isn't really metadata in my eyes either. 11.55.09 # Also the database is for storing it for search purposes. It's not like we're going to say "we're removing ID3 tags, files should store all their info in the database" or "we're removing support for external album art, it needs to be scanned and entered into the database" 11.55.17 # The only functionality that should require the database is searching/using the database. 11.55.28 # no 11.55.35 # thats stupid 11.55.51 # anything that involves storing data persistantly should use the database 11.55.59 # Why? 11.56.04 # because thats what its for 11.56.11 # Not really. 11.56.27 # It was originally "tagcache" and I think the name gives a pretty clear reason for its being in existence. 11.56.27 Quit stripwax (Quit: http://miranda-im.org) 11.56.31 Quit bluebrother (Disconnected by services) 11.56.32 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 11.56.49 # so what? 11.57.11 # So, my reason's just as good as yours. You've decided its intent is "all persistent data" but that wasn't, at least, its original intent. 11.57.24 # And I don't think there's been a discussion that its intent has changed, has there? 11.57.37 # why is a resume point persistent? And I also think about bookmarking as related to the playlist and not to a certain file that happens to be affected 11.57.44 # first of all, the database already stores more then just tags 11.58.16 # saratoga_: What, file ratings? 11.58.27 # run time stats as well 11.58.30 # I would fight tooth and nail against removing bookmarking and forcing the database 11.58.42 # Ratings are something that traditionally goes into tags, only we don't support writing to tags. 11.58.48 # I don't object to this feature, but do not force the database on us 11.59.05 # Run time stats are necessary for database searches since that's something you can query it for. 11.59.17 # like, say resume information? 11.59.46 # You can query for resume information? What, are you going to search for "files I've got resume points in at longer than 4 minutes in"? 11.59.54 # bookmarks can e.g. be easily copied between players 12.00.00 # "i've got a file, does it have a resume point?" 12.00.19 # "I've got a file, does it have album art" 12.00.26 # Clearly album art needs to be using the database only too, now 12.00.44 # no because we have to buffer album art 12.01.26 # look i'm not doubting that you can duplicate everything that a sane data storage system does with a mess of files on the hard disk, i'm just saying doing that for no reason is ridiculous 12.01.49 # Resume points without database isn't "no reason" 12.01.55 # no reason? 12.02.02 # there are obviously a few targets where memory is so tight we can't do things sensibly, but they're fewer and fewer every day 12.02.08 # Resume point are something people have been using, as bookmarks, without the database for *years* in Rockbox. 12.02.18 # There's no reason to add it to the database other than a desire to force users to lose existing functionality 12.02.24 # "without the database" is not a reason 12.02.31 # literally 12.02.43 # it doesn't explain anything 12.02.44 # What's the reason *for* adding it other than "I think it belongs there"? 12.02.55 # I don't really see the point in this discussion, it looks like it is going to get committed anyway 12.03.02 # its already committed 12.03.06 # exactly 12.03.14 # So why discuss if it is ignored 12.03.18 # AlexP: Yes, but now he's advocating removing bookmarks. 12.03.19 Quit factor (Ping timeout: 255 seconds) 12.03.27 # That hasn't happened yet. 12.03.34 # Llorean: I'm not worried about that, I'd just revert it 12.03.36 # i'm not removing bookmarks because i don't care 12.03.50 # i'm just pointing how ridiculous people are about the database 12.03.58 # In your opinion 12.03.59 # avoiding it is an end in and of itself 12.04.10 # not one person has so far mentioned why they don't want to use it 12.04.16 # saratoga_: Bookmarking a single file shouldn't depend on having enough disk space for the whole database. 12.04.18 # isn't that a little funny to you guys? 12.04.22 # Loss of lots of RAM 12.04.23 # A bookmark is tiny, the database isn't necessarily 12.04.31 # how much RAM? 12.04.36 # 2 MB 12.04.40 # If there were a way to store it in the database without initializing it with tag data, sure, that's different. 12.04.46 # 2MB for how many tracks? 12.04.52 # Loads of small ones 12.05.12 # how many? 12.05.43 # saratoga_: forcing people to use the database because you think it's sane seems to be another end in and of its self. 12.05.45 # I can't remember exactly, my player isn't to hand. 15k ish IIRC although that is a guess 12.05.50 # Why make them use it for a feature that doesn't *require* it? 12.06.00 # Database searches require it, obviously, by their nature. Bookmarks don't. 12.06.18 # forcing people to use rockbox features that are implemented well is a goal of mine yes 12.06.26 # I can move bookmarks between players 12.06.29 # you're complaining that i want to improve things 12.06.32 # How to do that with the db 12.06.32 # well played 12.06.37 # saratoga_: That's not an improvement. 12.06.47 # your technical opinion? 12.06.49 # "We'd like to force you to use an unnecessary amount of disk space for information that's a few bytes. " 12.07.07 # Why should a user be force to cache all of their files' metadata just to store a resume point? 12.07.22 # That's inefficiency at its fines. 12.07.24 # t 12.07.24 # i'm not saying they should 12.07.26 # anyway, as I say I don't object to this particular feature too much, it is bookmarking I care about 12.07.34 # saratoga_: You said they should be forced to use the database for resume points. 12.07.37 # yes 12.07.38 # That's what the database *is* 12.07.43 # it doesn't have to be 12.07.58 # Well you didn't say you were talking about a hypothetical future database that follows rules known only to you. 12.08.06 # Being able to have only those files with resume points added to the database would be very nice 12.08.08 # We all assumed you were talking about the real database that exists right now. 12.08.21 # add them one by one as resume points get added 12.08.23 # As I said, I wouldn't object if the database could be restricted to only holding the resume data. 12.08.29 # obviously i'm not since the database i'm talking about includes bookmarks . . . 12.08.44 # saratoga_: Sorry, "the database we have plus the feature you explicitly mentioned adding to it" 12.08.58 # We can't read your mind, so we obviously can't know about features you *haven't* spoken of. 12.09.08 # well if we're talking about how we want things to be i don't see why we should assume limitations we have now 12.09.21 # you could ask me 12.09.28 # ! 12.09.48 # That makes no sense. I shouldn't have to ask you about every possible permutation. If you're discussing one possibility you should describe it, not assume people can read your mind and know what you intend. 12.10.09 # err, what? 12.10.10 # If you say "I think the database should be the only place to keep resume points" it's pretty reasonable that someone will think you mean the *current* database, not some other one you've got in your head. 12.10.33 Join DerPapst [0] (~Alexander@91-66-226-46-dynip.superkabel.de) 12.10.39 # no thats not reasonable since i'm talking about improving the database! 12.10.46 # Especially when someone has already mentioned they'd be okay with it if it didn't have to include all the metadata, and you ignore that for five minutes without saying "yes, like that" 12.11.51 # honestly no one even mentioned memory use until the very end of this argument, so i don't know why i should assume thats what you're concerned about 12.12.01 # saratoga_: It's perfectly reasonable to think, when someone refers to the database, that they're referring to it as it exists, plus anything they've explicitly mentioned, because someone with the intent of having a constructive conversation would mention other changes they have. ESPECIALLY when they might mitigate some of the objections people brought up. 12.12.06 Join factor [0] (~factor@75.108.68.114) 12.12.58 # saratoga_: (5:04:39 AM) Llorean: If there were a way to store it in the database without initializing it with tag data, sure, that's different. <-- Seems that even without the mention of "memory" this should've at least prompted a "they might be interested in this idea" 12.13.11 # i think its perfectly reason for people who have a problem with a specific aspect of something (e.g. having a database in memory) to actually mention that instead of complaining about nothing in particular 12.13.32 # saratoga_: You can't discuss a feature without being at the same place about it, so are there any other changes you're holding in your mind that might affect this image of the database you have? 12.14.20 # yeah but i haven't hashed them out yet 12.14.54 # i was thinking of a system where you either just index all the files but don't cache the tags, or better yet don't index anything until its actually played 12.15.13 # so it behaves sort of like a cache on low memory targets 12.15.16 # How about never index anything, if the user doesn't want to have it indexed? 12.15.43 # As I said, I wouldn't mind if all my bookmarks or runtime stats were stored, but I don't want to waste disk space creating a searchable database I'll never use. 12.24.00 *** Saving seen data "./dancer.seen" 12.28.32 Join Buschel [0] (~chatzilla@p54A3B908.dip.t-dialin.net) 12.30.19 # [Saint]: ping 12.30.43 # <[Saint]> yo. 12.31.06 Join MethoS- [0] (~clemens@134.102.106.250) 12.31.14 # * TheSeven wonders if the iPod Classic port should go into SVN or FlySpray 12.31.34 # the problem is that it might break other targets that I don't have and thus can't test on 12.31.34 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 12.31.41 # (due to the ATA changes) 12.31.44 # still need verification for some patches on the iPod color. do you have access to it? 12.31.45 # <[Saint]> which ones? 12.32.08 # <[Saint]> Bushmills: Ah, yes. Which patches. 12.32.09 # TheSeven: if it possibly brakes other targets I would not submit to svn 12.32.48 # Buschel: on the other hand, nobody seems to be willing to test that part right now 12.32.57 # so this thing might be stuck in flyspray forever 12.33.31 # if it breaks, it breaks completely (no disk access possible at all), so it will be apparent 12.33.36 # TheSeven: Send a mail to the dev list saying here it is on fs, please test as it might break x, y, z - if nobody tests it'll go in in a week 12.33.36 # and probably trivial to fix 12.34.18 # I'm happy to test later on today 12.34.32 # * TheSeven needs to figure out which targets might be affected 12.34.54 # [Saint]: FS#11843 v16, and FS#11820 (will provide a test patch later) 12.34.54 # basically everything that's doing ATA byte swapping, and we should also test the bigendian targets 12.36.03 # TheSeven: why not submit the Classic port except this breaking change in one step and the ATA stuff in a second submit to be able to roll it back easily? 12.36.26 # because the classic port can't work without the changes 12.36.31 # [Saint]: also, can you check which lcd_type your color has? this is available in the debug menu 12.37.15 # and i don't think it will need a rollback. if anything, it will need a few more #ifdefs swapping bytes 12.37.28 # <[Saint]> Buschel: The OFs or RBs? 12.37.33 # RB's 12.37.33 # <[Saint]> (debug menu) 12.38.17 # <[Saint]> LCD type: 1 12.38.31 # <[Saint]> (for both, incedentally) 12.38.55 # hmm, interesting. both reach ~52 fps RGB full screen, right? 12.39.16 # <[Saint]> it was something like that. 12.39.33 # the nano 1G also uses lcd_type 1 12.40.15 # <[Saint]> quite a difference in screen size though ;) 12.40.59 # [Saint]: yes, but the throughput in MB/s is still 2.5x faster nano1g vs. color 12.41.19 # [Saint]: short test regarding FS#11820 -> http://pastie.org/1423126 12.43.33 # amiconn: do you still have access to the iPod photo which you used to measure LCD speed (see LcdFrateRate wiki) 12.44.34 # [Saint]: if FS#11843 v16 works for you, I am interested in RGB/YUV speed boosted/unboosted. I would like to submit if it works fine 12.45.21 # <[Saint]> Ok, I'm patching now. Then building, , testing. :) 12.45.46 # so, you are able to build again :) 12.46.14 # <[Saint]> Yes, I figured out my CygWin gremlin. 12.51.15 # <[Saint]> rockboxdev.sh was trying to delete the build dir while it was still in it...the code for it was fine, I added a pause and prompt for manual resume and it worked fine. 12.52.01 # <[Saint]> without it, it was ignoring a "cd" for some reason, seems to work on other systems though. 12.52.11 # <[Saint]> *cd .. 12.58.21 Quit saratoga_ (Quit: Page closed) 13.01.13 Quit JdGordon| (Quit: Lost terminal) 13.04.07 # saratoga: One main point about the database in rockbox is that it's optional. Atm I don't need bookmarks or automatic resume points, because I neither listen to audio books nor podcasts 13.05.36 # But if I ever start doing that, I much prefer a way that doesn't require me to use the database, which I don't use regularly either 13.06.55 # I have it enabled for pictureflow to work, but that's only for occasional, show-off. In >99.9% of all cases I start playback from the file browser 13.08.02 # * [Saint] only has the DB enables so he can occasionally show someone pictureflow/wps integration. 13.08.23 # <[Saint]> *enabled 13.08.39 # * amiconn never even tried pf/ wps integration 13.09.29 # <[Saint]> kinda cool. But just for "eye candy". 13.09.52 # Rockbox has a lot of feature I have no use for... 13.10.20 # At least most of them aren't duplicating functionality.. this latest one does though :( 13.10.52 # <[Saint]> It's only by the coincidence I use the DB for pictureflow that it doesn't really affect me. I understand there are many that don't use the DB. 13.13.41 # [Saint]: still building? 13.19.16 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 13.19.32 Quit leavittx__ (Ping timeout: 276 seconds) 13.19.36 # speaking of testing, could anyone with a coldfire target that's not h300 or hd300 test the testbuilds i linked in my mail to the ml last week? And it would be cool if someone could test building the new toolchain on cygwin too 13.19.58 Quit Judas_PhD (Client Quit) 13.21.56 # hmm, what do I need for the toolchain? 13.22.17 # do, I need to build it myself? 13.22.20 # -, 13.23.23 # n1s: could you provide an M5 build with FM enabled (in advanced options)? 13.23.37 # pixelma: sure 13.24.56 # pixelma: it would be good if someone tested building the toolchain on cygwin 13.26.12 # I'm not sure I know everything that's involved for doing so (except taking time... ;) ) 13.28.16 # i have a patch so anyone who wants to test building just needs to apply it and run rockboxdev.sh 13.29.11 # (the tools patch in FS#7832) 13.30.10 # pixelma: http://dl.dropbox.com/u/17484767/rockbox-m5-fm.zip 13.32.40 # I'm mostly worried about target specific drivers breaking as everything seems to work fine on my h300 13.34.58 # ok, I'll have a look at sound etc. and recording and have an eye on the RTC. The radio is basically the same as the H300's AFAIK but you'll get half an X5 test with this too ;) 13.35.36 # great 13.36.16 Join bluebrother [0] (~dom@g226069187.adsl.alicedsl.de) 13.36.16 Quit bluebrother (Changing host) 13.36.16 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 13.38.02 # TheSeven i have a 3rd gen on the way if you need help to test anything 13.39.22 Quit bluebroth3r (Ping timeout: 272 seconds) 13.45.52 Join T44 [0] (~Topy44@f048048039.adsl.alicedsl.de) 13.48.44 # n1s: There's something in your 'rockboxdev.sh' patch that doesn't belong there 13.48.54 # 'make' -> 'make -j4' 13.49.00 Quit Topy44 (Ping timeout: 240 seconds) 13.49.47 Join Ogham [0] (~Ogham@unaffiliated/ogham) 13.50.48 # Can anyone throw any light on bug FS#11812 ? Does this have the potential to damage low impedance IEM's? 13.51.31 # * amiconn isn't sure which of the diff files in fs #7832 are needed to get the whole thing 13.53.34 # n1s: playback works (flac and wav tested), sound settings seems to work (bass, treble tested which are in software with this DAC), voice works, FM seems to be working correctly, recording works (tested with the built-in mic), the RTC doesn't show any problems. Anything else to test? 13.54.40 # * amiconn could test h100 if he knew what's needed 13.55.25 # n1s: oh - buttons work, mpegplayer works 13.57.27 # Buschel: Sure, since it's mine. But I don't have it with me atm 14.15.29 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 14.18.25 # amiconn: only the last 2, the codec tuning one isn't actually necessary though 14.18.46 # so just the patch for configure and rockboxdev.sh 14.19.19 # amiconn: fine, could you just test (function, speed) FS#11843 v16 and check what lcd_type you have? you could place this info in flyspray 14.19.56 # pixelma: sounds good, if you have a remote, testing that might be interesting 14.20.13 # * Buschel wonders where [Saint] is, he seems to have vanished... 14.20.48 # n1s: don't have one yet, though B4gder wanted to send me one sometime 14.20.51 # amiconn: since it seems to work well for all tested players so far, things specific for the h100 would be most interesting, and the remote if you have one, since i don't 14.21.07 # I do have a remote 14.21.40 # The H100 and the M3 have some drivers which the later coldfire targets don't have 14.21.58 # and, yes i forgot to remove that make -j4 change as well as the commented out code since i wasn't sure if we wanted to keep support for the old toolchain in the script so that patch isn't quite finished 14.22.32 # These targets do not have the PCF5060x, but separate ADCs instead. Especially the M3 one is rather picky about timings (and slow...) 14.23.05 # it would be great if you could test that 14.23.20 # pixelma: ok, thanks for testing :) 14.23.45 # you're welcome :) 14.24.03 *** Saving seen data "./dancer.seen" 14.25.28 # Could it be that mp3 decoding got a bit faster or somesuch? I have the impression that mpegplayer works better (my videos I wanted to encode again because of choppy playback due to a bit higher bitrate look better and I wondered why) 14.30.59 # mp3 decoding got about 3% faster but i don't think that would be noticable in mpegplayer 14.31.52 # * amiconn is trying to build the new toolchain on cygwin 14.32.29 # amiconn: cool :) 14.33.03 # Will take a while, even though I've disable the on-access AV for this 14.33.07 # *disabled 14.33.51 # maybe for other reasons then, anyway - it looks like I don't have to encode these videos again :) 14.34.02 # pixelma: nice 14.34.33 # amiconn: do you remember why the old toolchain needs a patch to disable some multilib? 14.34.39 # yes 14.35.10 # The disabled multilib fails to build on various systems. Those need the patch 14.36.09 # do you know if it is needed for the new toolchain? (i guess your build will fail if that's the case) 14.37.05 # How should I know? There's just one way to find out... 14.37.50 # yeah 14.38.20 # guess we also need some testers for the toolchain on Mac too, IIRC they also show weird behaviour sometimes 14.38.50 # is any active dev using macOS ? 14.39.01 # n1s: Do you use linux x86_64? 14.39.06 # yes 14.39.18 # So it's probably not needed anymore. 14.39.27 # Lambda has one I think (and JdGordon had access to one but I don't know if this is the case anymore) 14.39.37 # no, the 64 bit patch isn't needed anymore 14.40.13 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 14.40.50 # Ah, that was another patch 14.41.09 # yes 14.44.08 # oh, i just remembered that the patched rockboxdev.sh only builds coldfire multilibs 14.45.00 # so that particualr problem will probably not show up 14.45.08 # <[Saint]> did something with the speex encoder change recently...ish? 14.45.22 # <[Saint]> I can't seem to build voice files on CygWin 14.46.08 # n1s: Maybe it would be a good idea anyway to disable all multilibs we don't use. It would speed up tollchain building, and the resulting toolchain would need less disk space. 14.46.48 # yes, that is true 14.47.22 # It would mean additional work if we add a target that needs them though 14.47.25 # <[Saint]> http://pastebin.com/8bkEEdPS is what bash has to say about the whole voice building fiasco, fwiw. 14.47.57 # Same applies to the SH multilibs btw - we only use sh1 14.48.40 # amiconn: the --with-arch=cf config option makes it build only the coldfire multilibs, not the other m68k ones so maybe that's good enough? 14.49.03 # aha 14.49.08 # Let's see 14.51.38 # only 8 different multilibs are built and they take about a half megabyte of space each 14.53.58 # the old toolchain built 10 14.55.28 # [Saint]: does FS#11843 work for you? 14.55.56 Join stsquad` [0] (~user@nat18.sesnet.co.uk) 14.56.21 # n1s: 14.56.22 # configure: error: in `/tmp/rbdev-build/build-binutils/ld': 14.56.22 # configure: error: C compiler cannot create executables 14.59.48 # hmm 15.00.14 # i have to go for a while but will look at that later 15.00.38 # Happened after running for 25 minutes 15.03.19 Quit [Saint] (Ping timeout: 255 seconds) 15.09.24 Quit sasquatch (Ping timeout: 240 seconds) 15.11.44 Join [Saint] [0] (S_a_i_n_t@203.184.0.102) 15.13.41 # <[Saint]> Buschel: very, very weird behaviour. 15.14.31 # <[Saint]> the top of the screen is being drawn again oer the bottom of the screen. 15.14.52 # <[Saint]> which dissappears momentarily whilst scrolling. 15.16.19 # YUV is working fine? 15.16.42 # <[Saint]> how am I to establish that? 15.16.59 # play a movie or use test_fps 15.17.35 # <[Saint]> yes. 15.19.20 # <[Saint]> the boot splash and the menus are garbled in the same way, a split about two thirds down the screen where the top of the screen is drawn overtop. 15.19.44 # I am checking right now 15.22.05 # can you backtrace which patch-version introduced this? you'll just need to re-build rockbox.ipod 15.22.50 # seems like the RGB screen update is broken 15.24.00 Quit MethoS- (Remote host closed the connection) 15.24.08 # (which is funny as it did not change as much as YUV) 15.25.56 Join sasquatch [0] (~username@46.114.82.65) 15.37.22 Part stsquad` ("ERC Version 5.3 (IRC client for Emacs)") 15.39.58 Quit GodEater (Read error: Operation timed out) 15.42.43 # * Buschel cannot recognize the fault in the code... :/ 15.46.48 # amiconn: that error seems vague, is there anything interesting in the config.log ? 15.49.55 # that the binutils build fails is interesting since it's the same version that we use for arm-elf now 15.50.05 # eh, arm-eabi-elf 15.54.24 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 15.55.06 Join kugel [0] (~kugel@rockbox/developer/kugel) 15.55.52 Quit kadoban (Read error: Operation timed out) 15.56.36 # [Saint]: are you still there? 15.58.23 Join mystica555_ [0] (~mike@c-75-70-179-25.hsd1.co.comcast.net) 16.00.07 # [Saint]: yeah, I think I have it :) 16.03.49 # [Saint]: as the full screen lcd update needs to loop twice to update your screen, I need to correct the address within the framebuffer after the first run. this is not needed for the nano1g. 16.08.51 # damn, that DMA buffering logic is driving me nuts 16.09.43 Join GodEater [0] (~bibble@rockbox/staff/GodEater) 16.10.28 # [Saint]: updated FS#11843 v17 16.12.31 # [Saint], soap: if I am not wrong the swapping in the LCD driver is not really needed. I will provide a patch for testing as soon as v17 (or any neccessery bugfix for this) has been submitted 16.15.34 # hmm, i have no idea what could cause that cygwin failure, maybe i should set up a cygwin environment to test in myself :/ 16.17.12 # apparently a new binutils release has been made but i can't find any info on what they have fixed in it, only added features 16.24.06 *** Saving seen data "./dancer.seen" 16.28.19 Quit mystica555_ (Ping timeout: 264 seconds) 16.34.14 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 16.34.24 Quit Buschel (Ping timeout: 276 seconds) 16.35.06 # urgh 16.35.14 # that bugger doesn't even manage MP3 realtime 16.36.05 # IIUC it's an ARM9e running at 216MHz 16.36.18 # caches should be enabled 16.36.34 # from the skipping behavior i'd say 80% realtime 16.37.02 # that sounds too slow for that core/freq even with caches disabled 16.37.41 # with caches disabled the UI was lagging 16.38.26 # what's the best way to figure out the real clock? 16.38.49 # let it iterate a thousand times through a loop of a thousand nops and measure the time? 16.39.39 # i can't think of another way of doing it without knowing how it's configured 16.40.30 # the rest of the UI is responding quite fast, and games like chopper run fluently 16.44.07 # n1s: 10.000 iterations of 1.000 nops took 52.319µs 16.44.45 # so if there would be zero overhead, that would be ~191MHz 16.45.10 # it must be something different... 16.45.32 # if caches are disabled and memory is slow enough to cause mp3 to not be realtime i'd guess the overhead would be significant 16.46.11 # can you run test_codec ? 16.46.47 # an do less demanding codecs play fine, like flac or just a wav for example? 16.47.37 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 16.53.32 # TheSeven: 10M instructions in 52µs? 16.54.55 # that's a lot more than 191MHz 16.55.13 # huh? 16.55.32 # 52ms (i used . as a thousands separator) 16.55.43 # oh 16.56.14 # well, this is assuming that the usec timer counts usecs of course :) 16.56.31 # you don't use . as thousands seperator in english :) 16.58.01 # well, but then it would have been 10 instructions in 52µs 16.58.36 # true 16.59.06 # and the usec timer seems to be sane 17.00.01 # 5'229'780µs for 1'000'000'000 instructions took like 5 seconds, so that's fine 17.00.07 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 17.00.11 Join mortalscan [0] (~mortalsca@173-166-0-166-newengland.hfc.comcastbusiness.net) 17.00.29 # (191.212632MHz) 17.01.23 # does rockbox do cpu time accounting for the individual threads? 17.01.44 # maybe there's just some CPU hog? 17.03.18 # * TheSeven compiles a build with test plugins 17.03.50 # the Os stacks (IIRC) debug screen shows someinfo about the threads but not the cpu time i think 17.04.35 # gevaerts: any idea why rockbox usb exposes 512 byte sectors on a drive with 4096 bytes per physical sector, formatted as a superfloppy fat32 file system with 4096 bytes per sector? 17.05.07 # the file system works fine in rockbox, so that ipod video hack layer must be functioning 17.19.09 # n1s: flac plays fine 17.19.27 # but the playback progress bar is jumping like crazy 17.19.48 # probably due to a problem with pcm_get_bytes_waiting 17.19.48 # weird 17.29.36 # TheSeven: does usb msc supports something else than 512 bytes per sectors ? 17.29.51 # I don't remember but I'm not sure 17.30.18 # the whole flac file (27MB) would fit easily into RAM, and there's also 27MB allocated in the buffering debug screen 17.30.26 # the pcm buffer is always around half full 17.30.47 # pamaury: certainly 17.31.45 # real is always in the 50000-70000 range, usefl is 20000-40000 17.31.56 # so we're indeed facing a problem on the disk side of things? 17.32.12 # the ATA driver is still PIO only for now 17.32.46 # if the disk is the bottleneck wouldn't mp3 work better than flac? 17.33.30 Join liar [0] (~liar@188-22-211-66.adsl.highway.telekom.at) 17.33.56 # if disk accesses are eating lots of CPU, the MP3 codec might push the bandwidth further down 17.34.34 # and the scheduler efficiency might also suffer at a more balanced codec/disk load 17.34.41 # from* 17.34.49 # yeah, but the mp3 file will be much smaller than flac, anyway, what numbers do you get from test_disk? 17.35.14 # let me check 17.35.43 # create: 6 files per second 17.36.07 # open: 10568 files, dirscan: 487371, delete: 5 17.36.31 # create/write/read 512,a: 16/16/783 kB/s 17.36.46 # create/write/read 512,u: 16/16/715 kB/s 17.37.06 # create/write/read 4096,a: 924/936/789 kB/s 17.37.20 # create/write/read 4096,: 935/947/781 kB/s 17.37.30 # that was 4096,u 17.37.45 # create/write/read 1048576,a: 961/979/812 kB/s 17.37.58 # create/write/read 1048576,u: 943/956/807 kB/s 17.38.05 # that looks like a definite bottleneck 17.38.22 # however read performance seems to be ok, even for sub-sector accesses 17.39.32 # right, shouldnt' be bad enough to cause stuttering for mp3 17.39.40 Quit liar (Read error: Operation timed out) 17.40.09 # hm, maybe disk accesses are over-yielding? 17.40.44 # see http://www.rockbox.org/wiki/DiskSpeed for a speed comparison 17.41.15 # TheSeven: iirc a thread should yield about once each tick or so if not sleeping 17.42.22 # hm, disk accesses are certainly yielding way more 17.42.35 # there will be several calls to yield() after each access 17.45.13 Quit sasquatch (Ping timeout: 240 seconds) 17.45.41 Join sasquatch [0] (~username@2.210.213.240) 17.46.28 # * TheSeven needs to reformat the disk 17.53.02 # hm, after i replaced some yields that aren't present on other devices with busy waiting the buffering screen results for flac are a tiny bit better, but still way off normal 17.53.24 # mp3 is still stuttering 17.55.37 # is it only stuttering during buffering or the whole time? 17.56.08 # it never manages to buffer more than ~40KB 17.57.21 # flac manages to read ~300KB ahead once and then also starts rebuffering like every second 17.58.19 # * TheSeven wonders if there are some tunables he could play with 18.02.16 Join Buschel [0] (~chatzilla@p54A3B3F6.dip.t-dialin.net) 18.02.27 # hm, the disk can barely keep up with flac apparently 18.03.02 # if i remove all yields from the ata driver, it manages to read up to ~2MB ahead 18.03.13 # what was it you needed someone to test to be able to commit your work? 18.03.26 # in complex areas of the song the usefl value drops badly 18.03.46 # it has barely ~1MB of usable data after a total of ~20MB played 18.04.10 # n1s: disk access on all big-endian or ata-swapped-words targets 18.04.39 # i can test on my h300, i'ts big endian, i have no idea if it swaps words though 18.04.39 # first rebuffering at ~25 of ~27MB played this time 18.05.24 # and MP3 is worse than before, even though it manages to buffer a bit more data now (this time the codec seems to be starving, not the disk) 18.05.57 # no rebuffering so far, ~500KB readahead accumulated during the first ~3MB 18.06.00 # where can i find the patch? 18.08.05 # n1s: http://pastie.org/1423647 18.08.28 # anything special or just any reading/writing? 18.08.36 # if it fails, nothing will work at all 18.08.57 # ok 18.09.10 # hm, mp3 even fails after it has finished buffering (at ~90% of the track) 18.12.42 # how does the ATA driver tell the low level driver which PIO mode it should use? 18.16.19 # TheSeven: something is definitely broken, menu and filebrowser text is scrambled 18.16.30 # damn 18.16.58 # but it managed to mount the volume? 18.17.11 # looks like it 18.17.19 # that's interesting 18.18.07 # Torne: do i understand correctly that rockbox always uses PIO0? 18.24.08 # apparently now 18.24.09 *** Saving seen data "./dancer.seen" 18.24.11 # not* 18.30.00 # TheSeven: think i found one bug in your patch 18.31.19 # IIUC it handles all coldfires the same even though some do the swap words thing 18.31.50 Join Kitar|st [0] (~Kitarist@BSN-182-77-193.dial-up.dsl.siol.net) 18.32.42 # so one would need more #ifdef'ing in firmware/target/coldfire/ata-target.h? 18.32.54 # yes, i think so 18.33.00 # MPIO is handled by a different file 18.33.20 # oh, i missed that then 18.37.25 Quit feisar- (Ping timeout: 240 seconds) 18.41.47 Quit kevku (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/) 18.42.06 # TheSeven: removing the swap16 from ata.c:1141 fixes it 18.42.26 Join kevku [0] (~kevku@arch.tunnel.ipv6.estpak.ee) 18.43.53 # hm, but that seems to be needed on other targets 18.44.28 # which raises the question which targets need it and which don't 18.46.15 # that seems odd since before the patch only big endian targets that don't swap words had this swap (and now that ATA_IN16 already swaps for those targets that extra swap was just swapping back) 18.48.14 # IIUC an extra swap there would cause wildly different settings to be used by the ata driver 18.51.35 Quit Llorean (Quit: Leaving.) 18.55.24 # it works fine on my ipod classic - but maybe that's specific to that platform 18.56.57 # * pixelma curses mpegplayer debug output in a sim for a file which only plays without audio in Rockbox but works fine in VLC 18.57.21 # there's so much info that I can't even see what actually happens :\ 18.57.39 # can you see which audio codec is used? 18.58.53 # maybe that's a hint: audio: mad_header_decode failed:forbidden bitrate value ? 18.59.42 # what does vlc tell you? 18.59.51 # hmm, a dump of the ata identify info with svn is different from one with the patch and my change 19.01.02 # how different? 19.01.29 # the video is a music video where I had to transcode the video part but it has mpg audio, so I thought I could do without transcoding - it's 22.05 kHz though and 48 kb/s. Is mpegplayer not able to resample? 19.02.23 # TheSeven: i just md5sumed them, checking it out now 19.04.50 Join y4n [0] (y4n@unaffiliated/y4ndexx) 19.05.10 # pixelma: I don't know... but good question 19.05.35 # TheSeven: 2 bytes differ 19.05.40 # pixelma: which layer is it? 19.06.17 # n1s: Nothing interesting in there. config.log has been touched the last time at 14:32 (build started at 14:30), the build error happened 14:55 19.06.20 # Hello. It is weird how with a certain loud album I can hear volume fluctuating during listening, on a rockbox'd clip+. Compressor is off... no such issues when listening in foobar2000 for example. 19.06.35 # envy - Recitation (2010) 19.07.16 # amiconn: ah, ok, i set up cygwin on my netbook to try and figure it out 19.07.58 # Umm, on a netbook it will probably take *very* long (assuming netbook == atom) 19.08.33 # yes 19.08.34 # Buschel: VLC stats tell me that there are also "lost buffers" (? losely translated back from its German UI) right at the start. I don't know what that means though 19.08.47 # I'll try something else 19.09.17 # TheSeven: in fact 4 bytes differ 19.09.17 # in the audio part 19.09.54 # but that means the swap is wrong for h300 at least 19.09.56 # pixelma: Can you upload this somewhere? 19.10.40 # is it normal that the pcm buffer never gets filled more than ~60%? 19.11.12 Join feisar- [0] (jljhook@irkki.fi) 19.11.28 # TheSeven: There's an easy way to find out whether buffering is causing the slowdown: Start playback, then press pause immediately, and wait until the disk stops. Only unpause after that 19.11.36 # pixelma: what happens if you simply comment line 167 in libmad/frame.c ? 19.12.24 # linuxstb: I first wanted to try if my transcoding program does something weird - I also cut the file because it has parts I'm not intersted in at the beginning and the end. I'll try without the cutting 19.12.45 # even when it's finished buffering CPU usage is way too high 19.12.54 # it's fine in test_codec though 19.13.52 # I have ATA DMA up and running now - it manages to read about twice as fast as it plays for FLAC now 19.14.27 # Buschel: layer 3 19.15.19 # MP3 still isn't realtime 19.15.53 # TheSeven: what is the DRAM / SRAM speed like? 19.16.15 Quit feisar- (Ping timeout: 276 seconds) 19.16.23 # no idea 19.16.34 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 19.16.42 # but the test_codec results seem to be sane 19.16.44 # can you check with test_mem? 19.16.49 # http://pastie.org/1423556 19.17.19 # all >100MB/s 19.17.23 # looks good. are the decoding times correct? 19.17.27 Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) 19.17.41 # they should be, at least roughly 19.17.43 # "all >100 MB/s" is too high imho 19.17.50 # amiconn: my build failed with some libiconv error 19.17.58 Join WonTu [0] (~WonTu@p57B572F3.dip.t-dialin.net) 19.18.04 # the tick might be off by a few percent, but not terribly much 19.18.12 Part WonTu 19.18.30 # if so, the memory bandwidth would be surprisingly high 19.18.38 # n1s: Btw, the binutils build errored while building gprof 19.19.22 # gprof has a separate config.log, but I can't find anything interesting in there either 19.19.27 # DRAM cnt: 2048 size: 64MB, read: 104.9MB/s (610ms), write: 220.6MB/s (290ms), memset: 220.6MB/s (290ms), memcpy: 133.3MB/s (480ms) 19.20.17 # IRAM cnt: 2048 size: 64MB, read: 128.0MB/s (500ms), write: 182.8MB/s (350ms), memset: 182.8MB/s (350ms), memcpy: 152.3MB/s (420ms) 19.20.59 # 108 iterations so far 19.21.17 # linuxstb: a file produced without the cuts works 19.22.10 # ~2.2 seconds per iteration, so the msec values seem to be sane 19.22.15 # these numbers are quite high. I like to see the IRAM speed reaching the speed of the PP5022. 19.22.47 # * TheSeven wonders how to leave this plugin 19.22.56 # skip left 19.23.08 # doesn't do anything 19.23.18 # wait a while 19.23.38 # otherwise press Menu + Select for while ;) 19.23.40 # no reaction even after several iterations 19.23.44 Join feisar- [0] (jljhook@irkki.fi) 19.23.45 # hm, that's what i'm about to do 19.24.46 # * amiconn retries the build, in order to exclude random failure 19.25.11 # amiconn: i'm rerunning my build too 19.25.52 # any other ideas what might be causing playback to eat cpu like shit? 19.26.08 # dsp stuff 19.26.21 # * TheSeven doesn't think there is dsp stuff enabled 19.26.26 # did you try to run test_codec including dsp 19.26.28 # ? 19.26.31 # the PCM driver should only cause one IRQ per ~9000 samples, if the chunks passed by the pcm buffer are that big 19.26.42 # TheSeven: does the port define CPU_ARM and ARM_ARCH? 19.26.48 # it is copying all pcm data from a to b 19.27.22 # n1s: i'd think so, as the test_codec results seem to be reasonable 19.27.50 # right 19.28.11 # test_codec with DSP is also several hundred percents realtime, even for MP3 19.28.17 # ok 19.28.19 Quit feisar- (Ping timeout: 264 seconds) 19.28.26 # 430.70% to be exact 19.28.33 # 44.5MHz 19.29.18 # (320kbit/s) 19.29.32 Join feisar- [0] (jljhook@irkki.fi) 19.29.43 # flac: 1032.30%, 18.56MHz 19.30.16 # * TheSeven tries test_disk again 19.30.57 # still only 16KB/s for 512 byte writes 19.31.12 # 512 byte reads are at ~1.5MB/s 19.32.09 # writes are about twice as fast as reads for bigger chunk sizes, weird... hm, write caching... 19.32.30 # anyway, this shouldn't be the bottleneck any more 19.32.47 # reads are ~1.6MB/s independent of the size 19.33.17 # that's way slower than i'd expect, but should still be sufficient for playback 19.33.33 Quit feisar- (Ping timeout: 240 seconds) 19.33.41 # so this could be: 19.33.55 # - some kind of fight between threads 19.34.02 # - some buffering/playback issue 19.34.05 # - the pcm driver 19.34.17 # any other ideas what could be the culprit that doesn't influence test_codec? 19.34.58 # pixelma: My guess is that the mp3 frames are cut, meaning the audio stream doesn't start on a frame boundary. That may or may not be legal, but I would expect vlc to be a lot more tolerant of such things than mpegplayer. 19.35.04 # is PCM-WAV significantly faster than FLAC? 19.35.09 # if yes I might try that 19.35.32 # TheSeven: it should be 19.36.03 # straight 16 bit 44.1kHz pcm needs basically no processing at all 19.36.25 # *if* it does no processing at all 19.36.36 # linuxstb: sounds likely. I wonder if mpegplayer should also tolerate this or not. Of course you can't take care of every corner case, I just pity that it looks like I'll have to transcode the audio 19.37.07 # maybe there are better transcoders though which can handle this correctly 19.37.46 # and cut on frame borders 19.38.14 # 2.38MHz, 8039.57% realtime 19.40.03 # and guess what? it's stuttering! 19.40.39 # so the two "extremes" wav and mp3 are stuttering, while flac works. what the hell? 19.41.07 # the UI is barely responsive while playing the WAV file 19.41.19 Join feisar- [0] (jljhook@irkki.fi) 19.42.59 # pixelma: Do you have access to mplayer? You can use that to dump the audio stream (mplayer -dumpaudio -dumpfile audio.mp3 file.mpg) 19.45.00 # wav even stutters after buffering completed 19.45.07 # apparently every time the wps updates 19.45.42 # the screen update? 19.45.48 # maybe 19.46.01 # and if buffering hasn't completed, it just reads one little chunk from the disk once a second, judging from the disk's noise 19.46.05 # how much fps do you get via test_fps? 19.46.06 # TheSeven: does the lcd update disable interrupts for too long or something 19.46.13 # it shouldn't 19.46.57 # what happens if you play a file while being in the main menu? 19.47.10 # amiconn: my binutils build now completed... the error i got before went away when i installed libiconv but it looked different from your error 19.47.29 # test_fps data aborts at yuv 19.47.42 # rgb is 25 full / 100 quarter 19.49.02 # 25fps is awfully slow 19.49.33 # afaik wps did 5 fps (full screen). so, this would equal 20% of the cpu time during playback. if the 5-fps-full-screen assumption is still valid 19.49.36 # this is still non-optimized C code, and the LCD is rather big (320x240x16bits) 19.50.26 Quit kugel (Remote host closed the connection) 19.50.56 # judging from the stuttering and lcd contents it's just doing a single frame per second (cabbiev2) 19.51.25 # and the stuttering doesn't change if i go to the main menu 19.52.14 # then the screen update are not the problem. main menu is not drawn cyclic 19.54.53 # hmm, the gmp/mpfr kluge in rockboxdev.sh needs to be updated for 4.5 as it needs mpc too 19.54.56 # and if flac plays fine, i can't see any reason why wav shoudln't, if it's not buffering 19.55.23 # n1s: binutils build worked here too. weird. 19.56.18 # * TheSeven is running out of ideas 19.58.10 Join GeekShad0w [0] (~Antoine@93.21.168.55) 20.00.15 # [Saint]: you there? 20.00.39 Quit GeekShadow (Ping timeout: 272 seconds) 20.02.28 Join GeekSh4dow [0] (~Antoine@93.21.167.104) 20.03.49 Quit GeekShad0w (Ping timeout: 240 seconds) 20.06.00 # hm, our bigendian targets are all the archos, iriver, iaudio, mpio and meizu players, and additionally the yp-s3? 20.06.05 # which of those have ata? 20.06.20 # ata_swap_words targets seem to be only archos and mpio 20.07.36 # n1s: does that mean that that your iriver is one of those identify-swap-needed targets (bigendian but not ata_swap_words) 20.09.36 # i think so, yes 20.10.09 # that's a bit confusing... 20.11.56 # so on iriver, the read is already swapping, and that's sufficient 20.13.08 # on mpio the read normally isn't swapped, but ata_swap_words is defined 20.13.23 # so the identify info won't be swapped at all 20.13.35 # so removing the additional swap would handle that as well 20.14.16 # the same holds true for archos 20.14.35 # meizu doesn't have ata-based players afaik, and the yp-s3 is flash-based as well 20.15.04 # iaudio seems to work like iriver 20.16.20 # none of the littleendian targets have ata_swap_words, so they never swap anything 20.16.34 # sounds like that swap16 should be removed, as the ipod classic is the only one needing it 20.17.00 # so the ipod classic is actually a littleendian ata_swap_words target? 20.17.11 Quit jfc^2 (Read error: No route to host) 20.17.35 Join jfc^2 [0] (~john@dpc6682208002.direcpc.com) 20.18.50 # ata_swap_words doesn't seem to affect data transfers on bigendian platforms 20.20.00 # so the data endian swap actually happens for all bigendian targets 20.20.32 # which means my patch is broken on mpio and archos 20.21.51 # little endian targets should never need ata swap because ata is also little endian 20.22.12 # Big endian targets do need it, unless there's some hardware swap mechanism 20.22.42 # it seems like there is a little endian target with a hardware swap mechanism :/ 20.23.09 # That's weird 20.23.15 # the identify words i'm getting on the ipod classic are big endian 20.24.05 # linuxstb: I made something which I think is the audio dump with the transcoder I use but I'm not sure if it really leaves the stream "in peace" 20.24.11 *** Saving seen data "./dancer.seen" 20.26.58 Quit GuySoft (Ping timeout: 248 seconds) 20.27.16 Quit bmbl (Quit: Verlassend) 20.29.31 # amiconn: any idea why the data endianness is swapped on all bigendian targets, but the identify endianness only on iriver and iaudio? 20.29.36 # or am i misunderstanding something? 20.30.07 # are some OFs writing data with wrong endianness, and we want to be compatible with that? 20.30.41 # not that it would make any sense... 20.32.57 Quit stoffel (Ping timeout: 276 seconds) 20.38.35 # pixelma: I don't know if it's your transcoder, but that audio stream has an ID3 tag at the start. That would confuse mpegplayer... 20.39.03 # I wondered why there even is one in the file 20.39.29 # found it too when playing the dumped mp3 in foobar 20.40.44 # are you sure it's a tag? I wonder why an uncut file would play if the transcoder would add it always 20.40.51 Quit Buschel (Ping timeout: 240 seconds) 20.42.51 # pixelma: Yes, looking at it in a hex editor shows it begins with the string "ID3" 20.44.00 # amiconn: if your statement above is correct, this comment would be very confusing: 20.44.01 # this info differently that normal sector data */ 20.44.09 # /* the IDENTIFY words are already swapped, so we need to treat 20.44.09 # this info differently that normal sector data */ 20.44.23 Quit GeekSh4dow (Quit: The cake is a lie !) 20.44.43 # hmm, the mpc lib isn't available from the same mirrors we get gmp and mpfr 20.44.51 # TheSeven: its grammar is confusing anyway ;) 20.45.29 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 20.46.55 # oh, this is getting even more confusing: 20.47.09 # what about the strings in the identify info? which byte order do those have? 20.47.45 # if i swap the byte order, the strings look right in the hexedit 20.48.09 # what does this mean for the endianness of the rest? 20.54.57 # also, if I undestand page 114 of ATA8-ACS right, ata isn't hardwired to 512 bytes per sector 20.56.50 # or rather pages 23, 113 and 114 20.57.26 # hahaha 20.57.30 # this sounds like where I came into Rockbox 21.01.07 Join Buschel [0] (~chatzilla@p54A3B3F6.dip.t-dialin.net) 21.09.25 Part y4n 21.10.20 Quit balintx (Remote host closed the connection) 21.13.24 Quit factor (Quit: Leaving) 21.14.18 Join factor [0] (~factor@75.108.68.114) 21.14.22 Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) 21.17.23 Quit factor (Read error: Connection reset by peer) 21.17.38 Join factor [0] (~factor@75.108.68.114) 21.22.10 # I'm new to Rockbox, having installed it via the Rockbox Utility on my Clip+ 8GB earlier today. I found a language quiz patch that I would like to install, but I'm not sure how to go about doing that. All the info I've read about adding patches talks about using diff files, but this patch is provided as a .c file. Can someone point me to some instructions somewhere that could get me through? 21.28.54 # Thopter: can you compile rockbox? 21.29.31 # Buschel: with a decent set of instructions to get me started, sure 21.30.14 # Thopter: then you should first walk through this http://www.rockbox.org/wiki/HowToCompile 21.32.54 # Buschel: Ok, that looks straightforward enough. What do I do with this .c patch file? 21.33.24 # is this a patch or a new plugin? 21.33.32 # it's a plugin 21.34.35 Join simonrvn_ [0] (simon@197.159-ppp.3menatwork.com) 21.34.37 # is it in the tracker somewhere (I am talking of flyspray)? 21.35.07 # flyspray 2896 21.35.47 # <[Saint]> anyone tried building convttf lately? I have a binary already compiled...so I can still use aliased fonts, but trying to build convttf fails quite dramatically. 21.36.48 # Thopter: it's a diff file. this patch does not apply anymore? 21.37.08 # I downloaded the .zip file, inside was a .c 21.37.21 # Thopter: check the diff file below 21.37.32 Quit simonrvn (Ping timeout: 240 seconds) 21.37.32 Nick simonrvn_ is now known as simonrvn (simon@197.159-ppp.3menatwork.com) 21.38.16 # <[Saint]> Buschel: Sorry about last night, I had a really bad headache and went to bed. Building with latest LCD patch now. 21.38.46 # [Saint]: no prob, I hope your feeling ok now :) 21.38.56 # you're 21.39.06 # Buschel: ah, I see. The fellow's instructions aren't very clear to me though. 21.40.14 # Thopter: what is not clear? 21.41.08 # given that reaction, something that should be clear. guess I'll go read some more 21.42.40 # Thopter: you should set up and development environment and downlad the source. then compile without any patch and see whether this is working. if so, you may apply the patch (as described in flyspray) and rebuild. 21.43.25 # ... yeah, I need to read up some more on this. Thanks for the assistance 21.43.27 # Can anyone throw any light on bug FS#11812 ? Does this have the potential to damage low impedance IEM's? 21.43.48 # Thopter: you're welcome 21.44.44 # Ogham: i doubt that it will destroy them thermally 21.44.55 # any chance this plugin (2896) might make it into the program someday? 21.45.14 # loud noise should be worse for them 21.45.21 # * TheSeven killed a pair that way recently 21.46.20 # <[Saint]> it could, potentially tear the speaker cone if the sample it paused on was incredibly loud, and the volume was very high. 21.46.51 # Thopter: I don't think so. It is in flyspray since ages without being included to official builds. 21.46.52 # * TheSeven doubts it will tear it more than playing back that sample without pausing 21.47.33 # btw. i'm sure other targets have the same problem 21.47.34 # so I'll have to do this for every update. Oh well, first time is always the hardest 21.47.57 # <[Saint]> Thopter: I'd be quite surprised if it applies cleanly. 21.48.01 # <[Saint]> Or, at all. 21.48.13 # because it's old? 21.48.14 # <[Saint]> it is ~4 years old. 21.48.25 # Owch, apparently the clip+ has been measured putting out 240mV whilst paused, do you think that would be enough to damage 16 Ohm Impedance IEM's? 21.48.56 # [Saint], Thopter: one step after the other. imho the patch itself is quite simple. so, it should be easily adaptable to the current code 21.49.33 # <[Saint]> Oh yes, it's certainly able to be applied. 21.49.37 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 21.49.55 # <[Saint]> It just depends on the level of effort one is prepared to go to to get it to do so. 21.50.03 # <[Saint]> And the knowledge of the person doing so. 21.50.11 # Ogham: that would be ~4 milliwatts of power 21.51.48 # Thopter, [Saint]: a plugin that old will not build due to the plugin header changes 21.52.17 # easily fixed though, just delete the old header macro in the plugin .c file 21.53.09 # TheSeven: I'm not too hot on my basic physics! But that doesn't seem like much power.. do you think it would cause issues if it was constant for a long duration? 21.53.45 # <[Saint]> check the specs of your IEMs 21.53.52 # i think the only impact a long duration can have is heat. and 4 milliwatts of heat shouldn't be an issue. 21.54.51 # it might be possible that that voltage is sufficient to bend the membrane excessively, but it won't make a difference if that's applied for a second or an hour in that case 21.58.29 Quit feisar- (Ping timeout: 240 seconds) 21.59.36 # TheSeven: Ah, ok.. and if 240mV applied during playback does not cause an issue, then I am I correct in assuming that it shouldn't cause an issue if applied constantly whilst the device is paused? 21.59.57 # i didn't say that 22.00.27 # Buschel, what do you want tested? [Saint] you testing too? 22.00.28 # if alternating voltages follow each other in rapid succession, the membrane won't be bent as far as when a constant voltage is applied 22.00.54 # <[Saint]> soap: Yessir, building now. 22.01.13 # so 1/50th second vs. 1 second makes a difference, while 1 second vs. 1 hour probably won't 22.01.29 # personally i'd expect them to survive that though 22.01.42 # Ah, that makes sense.. 22.02.18 # If they were to be damaged in the manner what is the likely outcome? An instantly recognisable difference in sound quality, or a slow degredation? 22.02.21 # [Saint], soap: if the latest patch works for you both I will submit. afterwards I have some further changes to verify ;) 22.03.20 # * [Saint] isn't sure if this discussion is still on topic or not. 22.05.06 # define "latest". That's really the question I was getting at. Are you going to commit the last one I tested, and want to verify the changes in the most recent FS patch, or is the most recent FS patch the one you want to commit and thus needs my testing? 22.05.33 # TheSeven: I'm assuming you use SECTOR_SIZE=512? 22.05.40 # yes 22.05.45 # And you have MAX_LOG_SECTOR_SIZE defined to something 22.06.24 # soap: v17 (=latest) needs to be tested by Saint. as this (hopefully) fixes some issues he had on his iPod color 22.06.24 # #define MAX_LOG_SECTOR_SIZE 4096 22.06.24 # #define MAX_PHYS_SECTOR_SIZE 4096 22.06.35 # ok 22.07.25 # soap: afterwards I will make further changes I would like to have tested by you both 22.07.52 # The problem is that usb_storage use disk_sector_multiplier, which is detected by disk.c based on which "actual" sector sizes it manages to mount partitions with 22.08.15 # For superfloppy mode it never sets it 22.08.30 # aha, sounds like that should be fixed :) 22.08.49 # so, not to beat a dead horse Buschel, to be perfectly clear v17 does not need testing by soap. 22.08.57 # Presumably disk_mount() could set disk_sector_multiplier for superfloppy mode based on the fat bpb_bytspersec field 22.09.11 # Yup sorry to be off-topic! I'll shut-up now, I'm just really worried about damaging my hardware due to this bug! 22.09.11 Quit Thopter (Quit: Sayonara) 22.09.48 # soap: yes, v17 does not to be tested by you. 22.10.17 # So last question.. if this bug was going to cause damage to my IEM's would it be instantly recognisable or a slow degredation? 22.10.30 # * Ogham promises not to ask any more questions! :) 22.10.41 # <[Saint]> Well, at the end of the day the no warranty/guarantee is pretty specific. 22.10.54 # <[Saint]> And, that question is almost impossible to answer. 22.10.56 # * TheSeven thinks nobody knows a definitive answer to that, besides the manufacturer maybe 22.11.26 # Ogham, IF IF it were to cause damage it would likely be through voicecoil overheating and eventual fuzing. 22.11.40 # IF IF IF IF 22.11.44 # gevaerts: so the fat code relies on bpb_bytspersec anyway? 22.12.03 # [Saint]: still compiling? 22.12.06 # I guess so 22.12.19 # soap: voicecoil overheating won't happen at that wattage, i would be more concerned about mechanical membrane damage 22.12.37 # <[Saint]> Yes, sorry. I needed to clean my build dir so it's taking longer than normal. 22.12.42 # <[Saint]> Buschel: ^ 22.12.55 # that voltage is too low as a percentage of "expected" to see much distention, no? 22.13.00 Quit factor (Ping timeout: 246 seconds) 22.13.55 # I mean, if a 10v rail to rail headphone amp won't bend the membrane too much why would 1/4v? 22.16.15 # a 10v rail to rail headphone amp? i doubt one will use such a thing at 16 ohms impedance 22.16.48 Quit saratoga (Quit: Page closed) 22.17.05 # i'm pretty sure that one *can* damage 16ohms inears at 1V 22.17.59 # 10V at 16 ohms would be 6 watts. that will certainly kill the voice coil. 22.18.24 Join AlexP_mob [0] (~ap@rockbox/staff/AlexP) 22.19.54 # TheSeven: http://pastebin.com/SKp6KYVb (compiles, but untested apart from that) 22.20.25 # * TheSeven will throw that into his tree :) 22.23.44 # TheSeven: actually, it might be interesting to see what the OF does with a plain standard 512 byte sector drive 22.24.08 # If it also treats that as 4K, it might be better to use a fixed value 22.24.12 *** Saving seen data "./dancer.seen" 22.24.20 # Thanks very much for your time all, one last thing then.. taking the no guarantee/warranty as a given - would you all be happy to continue usingexpensive IEM''s with rockbox in this situation? 22.24.54 # <[Saint]> I use a pair of Sennheiser IE8s 22.25.00 # * gevaerts considers using expensive IEMs to be proof of insanity, so he wouldn't use them, including in this situation 22.25.09 # <[Saint]> ;) 22.25.34 # True.. I wish I had bought cheaper ones I would not be so concerned about now! 22.25.35 # gevaerts: i seriously doubt we can set sector_size to 4k without major ata rework 22.25.53 # TheSeven: not sector_size, no, but hardcode disk_sector_multiplier 22.26.04 # [Saint]: Do you use them on a Clip+ with this firmware bug? 22.26.19 # hardcoding that won't buy us much 22.26.38 # (except from rejecting partitioning that the OF wouldn't like) 22.26.44 # The way things work now is that we actually have to trust data on the disk (partition table, FAT bootsector,...) to tell us how to interpret that same data 22.27.07 # <[Saint]> No, but at the end of the day I think you're being a little bit over cautious. A meteorite could plummet to earth and smash your IEMs, things break. 22.27.23 # That is a bit silly 22.27.47 # <[Saint]> That was kind of the point. 22.27.48 # You can't avoid that, you can this 22.27.55 # Ogham: have you considered contacting the manufacturer of your IEMs? They're much more likely to know 22.28.07 # We can really only guess 22.28.28 # Saint no, I meant your point was silly 22.28.49 # <[Saint]> I realise that. 22.28.53 # If the things are really expensive, I'd assume they do have a support service that can be reached :) 22.29.33 # gevaerts: I think I better had.. that or switch back to OF and hope that I have not already caused considerable damage! 22.29.40 # Ogham: you could just put a decoupling capacitor in between) 22.29.45 # Are you sure the OF doesn't do this? 22.30.01 # gevaerts: definately, its a rockbox issue 22.30.16 # Sure, but that's not what I asked 22.30.25 # TheSeven: I guess I could try that.. again I am a little restricted by my lack of technical knowhow! 22.30.48 # The fact that rockbox has a bug does not prove anything about the OF 22.31.05 # <[Saint]> The forum suggests it's rather hit and miss, and dependant on the IEMs. 22.31.16 # <[Saint]> As I understand it, not all are experiencing this. 22.31.31 # gevaerts: Well, the mV was measured as 0 when the player was paused and using OF 22.31.37 # ok 22.31.45 # Tested multiple times, I presume 22.32.24 # I mean, with this sort of bug, the value you get is more or less unpredictable and will be zero every now and then 22.32.30 # gevaerts: Yes, people suggested possible problems with the tests such as no load, and the tests were repeated 22.33.41 # <[Saint]> Buschel: success...stand by for FPS results. 22.33.50 # \o/ 22.35.00 # [Saint]: well, the voltage is always there on a meter, but different IEM's vary in if they hear a squeak when the player is paused/resumed 22.37.10 # <[Saint]> LCD 1/1: 19.4, 1/4: 77.1 LCD YUV 1/1: 17.4, 1/4: 70.0 @30MHz ; LCD 1/1: 51.7, 1/4: 206.0 LCD YUV 1/1: 46.7, 1/4: 187.0 @80MHz 22.37.14 # <[Saint]> Buschel: ^ 22.38.54 # TheSeven: A, that's a detail I forgot. For some reason identify data is big endian, unlike normal ata data 22.39.00 # Well, I think I better switch back to the OF for the time being.. I'm not convinced that my IEM's are safe, I just hope they are not already damaged too much! 22.39.11 # Thanks again all, sorry to get off-topic here! 22.39.25 # amiconn: ah? i had the opposite impression when looking at the code 22.40.16 # So if you want the 16 bit ints to be little endian, you need to byte-swap - but then strings are in the wrong order 22.40.50 # Actually, that's probably the reason why it's big endian 22.41.21 # * TheSeven is completely confused now 22.42.18 # <[Saint]> Buschel: Where is the patch for the LCD shotdown artefacts I'm getting on iPod Colour? It's not on the tracker. 22.43.05 # amiconn: apparently, on little-endian targets, identify and data is handled the same way, while on big endian targets they're handled differently 22.43.19 # New commit by 03Buschel (r28944): Submit FS#11843 v17. Integrate YUV-blitting of nano 2G to nano1G/color LCD driver. Additionally refactor RGB and YUV screen updates to use same code ... 22.43.38 # <[Saint]> oh...found it. 22.43.52 # <[Saint]> Oh, wait...nope :/ 22.43.55 Join GuySoft [0] (guy@bzq-79-179-40-185.red.bezeqint.net) 22.44.25 # <[Saint]> Buschel: Do you have the wait you added to LCD in a patch form? 22.45.57 # <[Saint]> aha, found it in the logs...sorry Buschel. 22.46.02 # <[Saint]> I'll test that now. 22.47.50 Quit Judas_PhD (Ping timeout: 240 seconds) 22.55.20 Join feisar- [0] (jljhook@irkki.fi) 22.58.42 # soap, [Saint]: can you now check this patch? -> http://pastie.org/1424222 22.58.48 # (I call it v18) 22.59.28 # <[Saint]> what does this one do? 23.00.10 # it removes some (from my understanding unneeded) special handling 23.00.14 # in the LCD driver 23.00.30 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 23.01.01 # patch against current svn? 23.01.12 # duh, yes 23.02.48 Quit feisar- (Ping timeout: 265 seconds) 23.03.02 Join feisar- [0] (jljhook@irkki.fi) 23.03.42 Join Keripo1 [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 23.04.20 Quit Keripo (Ping timeout: 264 seconds) 23.09.25 # <[Saint]> Buschel: The screen artefact patch doesn't work. 23.09.47 # <[Saint]> It just displays a full white screen before the horrible vertical lines now :/ 23.09.48 # ok, was a quick shot.. 23.09.50 # <[Saint]> Sorry. 23.10.14 # <[Saint]> It disturbs me how long the artefacts last for. 23.10.20 Quit bertrik (Ping timeout: 255 seconds) 23.10.36 # <[Saint]> I would swear that it wasn't being powered down properly, as sometimes they can last on screen for over 5 minutes. 23.13.54 # * [Saint] has nice boot-splash and USB icons for his iPod Colours now. 23.15.44 # * TheSeven thinks he's caught all the corner cases of that ATA patch now 23.16.05 # does anyone want to (re-)test it before i commit it? 23.16.32 # sure 23.19.51 # n1s: http://pastie.org/1424257 23.20.47 # Buschel, no speed changes no regression in quality on Nano 1G. 23.21.18 # soap: good. let's hope Saint will report the same. 23.22.12 # <[Saint]> It will be a while before I can test this latest increment, but...fingers crossed, yes. 23.22.16 # soap: btw, could you update the LcdFrameRate wiki or give me the detailed numbers for all measurements (YUV/RGB/boosted/unboosted)? 23.22.26 # on it 23.22.40 # [Saint]: shall I upload a binary for you? 23.22.51 # <[Saint]> Buschel: I will do the same for the Colour when I've finished the test. 23.23.29 # <[Saint]> Buschel: It's building now, it's just a timing thing. I have to run out the door for about an hour shortly. 23.23.40 # ok 23.24.26 Quit TheSeven () 23.24.32 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 23.24.37 # TheSeven: This isn't easy to understand. Afaiu the different handling of identify and plain data on big endia is because we want plain data in original order, but identify data in target endianess 23.26.05 # So on little endian no swap is required for both, while on big endian targets with hardware swap support we need to swap identify but not data, and on big endian without hardware swap support we need to swap data but not identify 23.26.37 # yeah, i think i got it 23.27.20 # and the ipod classic is different again: the data register is swapped, but not the control registers 23.27.24 # don't ask me why 23.27.26 # Actually hardware swap support just means ata buffer lines 0..7 are connected to lines 8..15 of the data bus and vice versa 23.28.35 Quit Judas_PhD (Quit: This is a quitting message) 23.28.38 # New commit by 03theseven (r28945): Fix an ugly-looking comment 23.28.38 # r28945 build result: All green 23.28.54 # now that was a fast build :) 23.29.45 # New commit by 03theseven (r28946): Autodetect sector size on superfloppy volumes based on the FAT32 BPB (kudos to Frank Gevaerts) 23.29.51 # That's the reason why the check_registers patterns are defined differently for the coldfire irivers 23.30.06 # hm, no, on coldfire everything is swapped 23.30.09 # not just the data register 23.30.11 # soap: the RGB fps was not affected at all? 23.30.31 # Maybe the classic runs in big endian arm mode (is that possible on the SoC?)? 23.30.43 # Buschel, hasn't been affected for quite a while. 23.30.49 # I'll double check. 23.30.53 # sheesh! ;) 23.31.02 # nope, it's the ata core that's crazy 23.31.18 # everything else doesn't do that kind of bullshit 23.31.21 # soap: Saint reported slight speedup for 1/4 screen RGB 23.31.39 # apple seems to have worked around it by swapping things in software as well 23.31.57 Join Rob2222 [0] (~Miranda@p4FFF3774.dip.t-dialin.net) 23.32.01 # r28946 build result: All green 23.32.25 # Buschel, yea, but all the numbers make more sense if we discount [Saint]'s findings! ;) 23.32.29 # n1s: did you try the patch? 23.32.59 # TheSeven: sorry, got stuck in a test disk run, didn't think it took this long 23.33.13 # with or without the patch? 23.33.21 # without 23.33.25 # damn :/ 23.33.35 # paperclipped it now 23.33.46 # soap: yes, true ;) 23.33.49 Quit benedikt93 (Quit: Bye ;)) 23.33.54 # <[Saint]> Buschel: And what's wrong with my findings? ;) 23.34.05 # TheSeven: no problem, it's just that the write and veryfy takes forever 23.34.57 # [Saint]: nothing, I better have findings before a submit than after :) 23.35.23 Join advcomp2019_ [0] (~advcomp20@97-114-234-88.sxcy.qwest.net) 23.35.23 Quit advcomp2019_ (Changing host) 23.35.23 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) 23.35.54 Quit pamaury (Remote host closed the connection) 23.36.16 Join DerPapst1 [0] (~Alexander@91-66-226-46-dynip.superkabel.de) 23.39.01 Quit DerPapst (Ping timeout: 276 seconds) 23.39.01 Quit advcomp2019 (Ping timeout: 276 seconds) 23.39.30 # * TheSeven wants to get that port pushed into SVN as he won't have much time next week 23.39.40 Quit Bushmills (Ping timeout: 276 seconds) 23.41.54 # New commit by 03alle (r28947): Fix typo in the comment 23.44.04 # r28947 build result: All green 23.44.04 # New commit by 03alle (r28948): Don't load the keyboard layout '-.kbd' (partial fix for FS#11847) 23.44.52 Quit Llorean (*.net *.split) 23.44.53 Quit kadoban (*.net *.split) 23.44.53 Quit mortalscan (*.net *.split) 23.44.53 Quit efyx (*.net *.split) 23.44.53 Quit domonoky (*.net *.split) 23.44.53 Quit chattr (*.net *.split) 23.44.53 Quit Xerion (*.net *.split) 23.44.53 Quit B4gder (*.net *.split) 23.44.53 Quit Farthen (*.net *.split) 23.44.53 Quit niekie (*.net *.split) 23.44.53 Quit tempname (*.net *.split) 23.44.54 Quit Stummi (*.net *.split) 23.44.54 Quit mc2739 (*.net *.split) 23.44.54 Quit jordan` (*.net *.split) 23.44.54 Quit linuxstb (*.net *.split) 23.44.54 Quit n17ikh (*.net *.split) 23.44.54 Quit dionoea (*.net *.split) 23.44.58 Quit AlexP_mob (*.net *.split) 23.44.58 Quit n1s (*.net *.split) 23.44.58 Quit mikroflops_ (*.net *.split) 23.44.59 Quit elcan (*.net *.split) 23.44.59 Quit simabeis (*.net *.split) 23.44.59 Quit soap (*.net *.split) 23.44.59 Quit parafin (*.net *.split) 23.44.59 Quit bug2000 (*.net *.split) 23.46.02 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 23.46.03 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 23.46.03 Join mortalscan [0] (~mortalsca@173-166-0-166-newengland.hfc.comcastbusiness.net) 23.46.03 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 23.46.03 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 23.46.03 Join chattr [0] (~mike@244.87.189.72.cfl.res.rr.com) 23.46.03 Join Xerion [0] (~xerion@5419A4D7.cm-5-2c.dynamic.ziggo.nl) 23.46.03 Join B4gder [0] (~daniel@rockbox/developer/bagder) 23.46.03 Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) 23.46.03 Join niekie [0] (quasselcor@CAcert/Assurer/niekie) 23.46.03 Join tempname [0] (generic@server1.unitedservers.de) 23.46.03 Join Stummi [0] (Stummi@rockbox/developer/Stummi) 23.46.03 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 23.46.03 Join jordan` [0] (~jordan@jem75-13-78-235-252-137.fbx.proxad.net) 23.46.03 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 23.46.03 Join n17ikh [0] (~n17ikh@c-68-59-25-51.hsd1.sc.comcast.net) 23.46.03 Join dionoea [0] (~dionoea@videolan/developer/dionoea) 23.46.16 # r28948 build result: All green 23.46.40 Join parafin [0] (parafin@paraf.in) 23.46.40 Join bug2000 [0] (~bug@unaffiliated/bug2000) 23.46.57 Join AlexP_mob [0] (~ap@rockbox/staff/AlexP) 23.46.57 Join n1s [0] (~n1s@rockbox/developer/n1s) 23.46.57 Join mikroflops_ [0] (~yogurt@h-34-71.A238.priv.bahnhof.se) 23.46.57 Join elcan [0] (user36@pr0.us) 23.46.57 Join simabeis [0] (~simabeis@lobmenschen.de) 23.46.57 Join soap [0] (~soap@rockbox/staff/soap) 23.48.44 # New commit by 03alle (r28949): Don't load the colours file if it's set to '' (partial fix for FS#11847) 23.50.11 # r28949 build result: All green 23.50.38 Quit kadoban (Ping timeout: 240 seconds) 23.51.07 # * TheSeven eagerly awaits testing results 23.51.34 # TheSeven: seems to work fine on my h300 23.51.36 Join Bushmills [0] (~Bushmills@scarydevilmonastery.net) 23.51.42 Quit elcan (Ping timeout: 246 seconds) 23.52.01 # New commit by 03theseven (r28950): Rework ATA driver to get rid of lots of target-specific constants and allow for non-memory-mapped task file registers. 23.53.14 Quit thegeek (Read error: Connection reset by peer) 23.53.29 Join thegeek [0] (~nnscript@132.108.34.95.customer.cdi.no) 23.54.00 # r28950 build result: 20 errors, 8 warnings (theseven committed) 23.54.06 # arrrrrrrrrrrrrrr 23.54.34 Quit scorche (Disconnected by services) 23.54.43 Join kugel [0] (~kugel@rockbox/developer/kugel) 23.54.44 Join scorche` [0] (~scorche@rockbox/administrator/scorche) 23.54.46 Quit timccc (*.net *.split) 23.54.46 Quit Sajber^ (*.net *.split) 23.54.46 Quit Q__ (*.net *.split) 23.54.46 Quit rvvs89 (*.net *.split) 23.54.46 Quit pikytcus (*.net *.split) 23.54.46 Quit scorche|1h (*.net *.split) 23.54.46 Quit fred_2 (*.net *.split) 23.54.46 Quit knittl (*.net *.split) 23.54.46 Quit Hadaka (*.net *.split) 23.54.46 Quit zu_ (*.net *.split) 23.54.46 Quit Utchy (*.net *.split) 23.54.46 Quit AlexP_mob (*.net *.split) 23.54.47 Quit n1s (*.net *.split) 23.54.47 Quit mikroflops_ (*.net *.split) 23.54.47 Quit simabeis (*.net *.split) 23.54.47 Quit soap (*.net *.split) 23.57.33 Join evilnick [0] (~evilnick@ool-18bcf602.dyn.optonline.net) 23.57.39 Quit tempname (Quit: Serverwechsel) 23.57.46 Quit evilnick (Changing host) 23.57.46 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 23.57.59 Join factor [0] (~factor@75.108.68.114) 23.58.11 Join scorche|sh [0] (~scorche@squisch.net) 23.58.14 Join Naked [0] (~naked@naked.iki.fi) 23.58.17 Join pikytcus [0] (~bigd@failbox.co.cc) 23.58.22 Nick Naked is now known as Hadaka (~naked@naked.iki.fi) 23.58.32 # TheSeven: the ata_init() change looks suspicious 23.58.45 # good night 23.58.46 Join rvvs89 [0] (rvvs89@mussel.ucc.gu.uwa.edu.au) 23.58.49 Quit Buschel (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014])