--- Log for 08.05.109 Server: lindbohm.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 month and 21 days ago 00.00.30 # I'm not sure this will be such an issue though.... I tihnk when this is all finished there will be a wps-like screen constantly being redrawn, and inside that there will be a rectangle for the ui which will be drawn when needed 00.00.35 Part pyro_maniac 00.00.49 # it shoudlnt ever be more than that 00.01.04 # constantly redrawn sounds horrid :/ 00.01.29 # replace todays statusbar with a wps and you have what im takling about 00.08.59 Quit bertrik ("Leaving") 00.17.00 # The statusbar doesn't cause the problem because its width is equal to the screen width and its height is a multiple of 8 00.17.30 # Change the latter and the update problem will start appearing on mono and vertically-packed greyscale targets 00.18.49 # we are talking about what? 1px error lines? 00.19.27 # or up to 8 even? 00.19.47 # really not a big deal, the work around is to make it clear to themeres that this is posible and to be aware of the limitations 00.21.55 # Up to 7 pixels 00.22.32 # That is, up to 8 in total at horizontal boundaries; up to 7 pixels into either viewport 00.23.13 # Same applies to vertical boundaries on horizontally-packed greyscale targets (8 pixels) and to a lesser degree to some colour targets (2 pixels) 00.24.01 Quit LambdaCalculus37 (Read error: 110 (Connection timed out)) 00.25.08 Quit intrados (Connection reset by peer) 00.25.32 Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 00.27.04 Join fyrestorm [0] (n=nnscript@cpe-24-90-84-236.nyc.res.rr.com) 00.29.05 Join intrados [0] (n=intrados@cpe-71-67-129-220.woh.res.rr.com) 00.35.27 # are there any plans of implementing FFWD/REW with audio in rockbox? 00.35.49 # nobody is working on it AFAIK 00.36.35 # its pretty much a nodo isnt it? 00.36.41 # i was looking around but didn't find any mentioning of it at all 00.36.46 # nodo? 00.37.20 # JdGordon|: Not that I'm aware of 00.37.24 # something that wont be done/acceptable out of principle 00.37.38 # I was under the impression that it is a pretty massive job 00.37.47 # And nobody had attempted it 00.37.57 # But I've not seen it as a NODO anywhere 00.37.59 # massive job i understand, principle i don't understand :) 00.39.55 # the argument against it is that if you've already heard the part you wanted its too late... 00.40.08 # so there is no gain over just dionging it blindly 00.40.26 # JdGordon|: But that doesn't make it a NODO 00.40.40 # unless you do it like my pvr thingy which rewinds 1 or 2 sec before playing again 00.40.41 # i was just FFWDing a 90 minute mixtape, and it would really come in handy to hear when the next track starts 00.41.18 # i wouldnt say it is a NODO either...it could be handy 00.41.20 Quit midijunkie ("?(???~•~)?") 00.41.47 # nodo in the sense that noone had any intention of adding it... not that it would be rejected if someone did put in the effort 00.41.53 # theres a thread about it in the forums 00.42.09 # i don't think its a NODO but i think it would be quite difficult on most players given the CPU constraints 00.42.16 *** Saving seen data "./dancer.seen" 00.42.36 # the beast could do it! 00.42.38 # are there any commercial players that implement it? 00.42.38 Join exposure101 [0] (n=exposure@pool-96-255-208-93.washdc.fios.verizon.net) 00.42.46 # all cowons 00.42.53 # including the ancient x5 00.43.02 # even the X5 or just the newer ones? 00.43.10 # x5, d2, s9, etc 00.43.10 # the new ones have quite fast CPUs 00.43.17 # but yes, x5 too 00.43.19 # the archos did it too, but.. 00.43.24 # archoses 00.43.29 # well hang on... isnt there a patch to speed up playback? that could be used to do it.. assuming it can speed it up enough 00.44.00 # do they speed it up or just play short clips as you go 00.44.04 # im not seeing much info about the Gen 6 ipod, will it even install? 00.44.18 # the latter, i would assume 00.44.21 # saratoga, sounds the same as cd player FFWD 00.44.29 # chopped up bits 00.44.36 # but no speeding up 00.44.40 # that makes sense 00.44.47 # can they do it for Vorbis as well as MP3? 00.44.51 # yes 00.44.53 # hows everyone? 00.45.02 # hmm so thats pretty good then 00.45.12 # flac too, iirc 00.45.20 # they either have a lot of really fast codecs or maybe its not as slow as i'd think 00.45.43 # exposure101: no...ports dont quite work like that...each one requires a separate port for all of the hardware and any method to be able to run code 00.46.04 # i guess it could be faked by issuing a lot of seek requests in sucession 00.46.31 # only thing i can find in the tracker about it: http://www.rockbox.org/tracker/task/1403 00.46.37 # well, any hint on where you are while FFWDing is helpful 00.46.41 # most of the codecs return less then 100ms worth of audio at a time 00.46.48 # thx scorche|sh 00.47.00 # so i guess request 200ms, then skip ahead a few seconds and so on 00.47.00 # saratoga: the H100 OF did it too 00.47.09 # any PP targets? 00.47.41 Quit ender` (" Women and Cats will do as they please. Men and dogs had better get used to it. -- Robert Heinlein") 00.51.45 Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) 00.54.04 Quit LambdaCalculus37 (Client Quit) 00.54.59 Quit JdGordon| ("http://www.mibbit.com ajax IRC Client") 00.58.18 Quit lymeca (Read error: 110 (Connection timed out)) 00.59.58 Join _Auron|G1_ [0] (n=Auron@ppp-70-249-149-60.dsl.rcsntx.swbell.net) 01.00.08 Quit Thundercloud (Remote closed the connection) 01.03.48 Quit jgarvey ("Leaving") 01.10.45 Join CaptainKewl [0] (i=jds@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 01.12.34 Quit kugel (Nick collision from services.) 01.12.39 Join kugel [0] (n=kugel@rockbox/developer/kugel) 01.15.31 Quit exposure101 ("Ex-Chat") 01.16.08 Quit miepchen^schlaf () 01.17.14 Quit barrywardell (Remote closed the connection) 01.17.19 # so 01.18.53 Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) 01.19.11 # how about this: if splashf was called with ticks > 0, then draw the splash, update the viewport, clear the viewport, then update after the sleep is over (so the splash is removed). if ticks == zero, then draw splash, update and clear, but do not sleep and post to the root_menu to do a fullscreen update() 01.21.27 Quit LambdaCalculus37 (Client Quit) 01.22.08 Join fenugrec [0] (n=ABC@142-217-99-200.telebecinternet.net) 01.26.32 Quit _Auron|G1_ (Read error: 54 (Connection reset by peer)) 01.33.49 Quit bmbl ("Woah!") 01.42.06 Quit gevaerts (Read error: 60 (Operation timed out)) 01.43.17 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 01.46.23 Quit fenugrec ("Leaving") 01.47.17 Quit matsl (Read error: 110 (Connection timed out)) 01.52.41 # kugel: ? both cases should be the same regarding redrawing... 02.01.08 Quit kkurbjun (Read error: 110 (Connection timed out)) 02.04.26 Quit amiconn (Nick collision from services.) 02.04.28 Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) 02.04.29 Quit pixelma (Nick collision from services.) 02.04.29 Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) 02.04.48 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) 02.04.49 Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) 02.06.08 Join CaptainKwel [0] (n=jds@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 02.07.43 Join kkurbjun [0] (n=kkurbjun@c-24-9-80-197.hsd1.co.comcast.net) 02.08.25 Join miepchen^schlaf [0] (n=miepel@p579EC6CE.dip.t-dialin.net) 02.08.47 Part toffe82 02.11.15 Quit Seed ("cu, Andre") 02.11.24 Quit fyrestorm (Read error: 104 (Connection reset by peer)) 02.21.09 Quit CaptainKewl (Read error: 110 (Connection timed out)) 02.28.37 # New commit by 03kugel (r20870): Convert splashes to viewports for bitmap targets and only draw/update the viewport that is needed instead of the whole screen. 02.28.53 Join ParadoxG [0] (n=LewisGun@S010600110904d72e.ed.shawcable.net) 02.29.33 # On my iPod video (build is only a few days old) I keep getting messages displaying "CODEC FAILIURE" when i am playing through albums, it then skips that song and continues to the next one; they are 320kps AAC files 02.30.07 # any idea on how to fix this? oh and btw the files that are skipped can be played by them self 02.30.13 Join TheDJACR [0] (n=TDJACR@Wikipedia/Thedjatclubrock) 02.30.25 # JdGordon: I think it makes sense to remove the splash within splashf() since it has control over the viewport, and since a timeout was given 02.30.38 Quit ParadoxG (Client Quit) 02.33.58 # Why should getting rid of the dead parts created by splash() the job of the caller if it can be done within splash() too 02.34.47 # it's just that it cannot be done with ticks == 0. We could of course think about removing that possibility altogether 02.35.40 # ticks == 0 can actually be useful, though - for example, for peppering code that hangs with splashf's ;) 02.37.09 # Unhelpful: other suggestions are welcome too :) 02.38.17 Quit krazykit (Read error: 104 (Connection reset by peer)) 02.38.55 Join krazykit [0] (n=kkit@adsl-76-251-243-50.dsl.ipltin.sbcglobal.net) 02.42.17 *** Saving seen data "./dancer.seen" 02.42.52 Join krazykit` [0] (n=kkit@adsl-76-252-6-10.dsl.ipltin.sbcglobal.net) 02.43.54 # weird binsize distribution 02.46.04 # kugel: because you still have the same problem with the screen not getting redrawn under it 02.46.40 # anybody know why i am getting this codec failure? its seems to happen fairly frequently, too 02.47.12 # froggyman: how long ago did you update? 02.47.53 Quit krazykit (Nick collision from services.) 02.47.56 Nick krazykit` is now known as krazykit (n=kkit@adsl-76-252-6-10.dsl.ipltin.sbcglobal.net) 02.48.10 # a couple of days ago (so it is quite recent) 02.48.36 # didnt add any patches to it, just got the pre-compiled build 02.48.55 # JdGordon: yea. But still. The caller is responsible for refilling the parts of *his* viewport(s) overwritten by the splash, but not for cleaning up the display outside of its viewports 02.49.56 # also, that would solve issues with multiple splashes 02.52.05 # in both cases splash behaves differently, why shouldn't be dealt with its impact differently (but properly) too? 02.52.35 Join antitrons [0] (n=Mudkips@119.224.12.185) 02.52.43 Quit antil33t (Nick collision from services.) 03.21.32 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 03.21.41 Quit intrados (Remote closed the connection) 03.24.12 Quit efyx_ (Remote closed the connection) 03.25.23 Join intrados [0] (n=intrados@cpe-71-67-129-220.woh.res.rr.com) 03.27.54 Join midijunkie [0] (n=Miranda@pD95472CD.dip0.t-ipconnect.de) 03.36.00 Quit kugel ("ChatZilla 0.9.84-rdmsoft [XULRunner 1.9.0.10/2009042523]") 03.37.41 Quit midijunkie (Read error: 104 (Connection reset by peer)) 03.38.13 Quit froggyman ("CGI:IRC") 04.09.36 Join cool_walking_ [0] (i=cb3b81c3@gateway/web/ajax/mibbit.com/x-9c154450ff92b50b) 04.17.47 Quit intrados (Read error: 104 (Connection reset by peer)) 04.21.06 Nick synergist is now known as _synergis (n=christof@cant.be-arsed.co.uk) 04.25.49 Quit jmillikin (Remote closed the connection) 04.30.33 Join Carter [0] (n=chatzill@adsl-99-130-172-220.dsl.ipltin.sbcglobal.net) 04.31.20 # Anyone else encountering errors running rockbox on 5g ipod 04.31.58 # what kind of errors? 04.33.19 # I cannot run rockbox.ipod for some reason 04.34.12 # What is the exact error? 04.34.35 # Cannot run rockbox.ipod 04.37.42 # I used Rockbox Utility to install 04.39.56 Join intrados [0] (n=intrados@cpe-71-67-129-220.woh.res.rr.com) 04.40.09 # Are you sure it isn't "Can't load rockbox.ipod: "? 04.41.16 # I think that is what it is 04.41.45 # knowing what the "something" is might help us help you? 04.42.18 *** Saving seen data "./dancer.seen" 04.43.05 Quit miepchen^schlaf (Read error: 101 (Network is unreachable)) 04.43.25 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 04.44.40 # Just reinstalled, it runs now. Thanks though, it's nice that you guys have a medium of support for your users 04.46.12 # Also, can I sync with Itunes or do I have to manually drag n drop? 04.46.47 # either one 04.46.57 # iTunes munts the filenames, so if you want to usefully use iTunes, you'll need to use Rockbox's database feature. 04.47.30 # Alright where is that 04.47.52 # It's in the manual. 04.48.01 # http://rockbox.org/manual.shtml 04.48.24 # Thank you. 04.49.20 Join ved_ [0] (n=ved2@137-mi2-1.acn.waw.pl) 04.49.34 # Section 4. Browsing and playing 04.49.47 Quit vedlith (Read error: 104 (Connection reset by peer)) 04.54.28 # Carter, if you are using a "current build" (as opposed to the latest release, 3.2), you need to make sure you are in the Apple firmware's disk mode (rather than Rockbox's) in order to sync with iTunes. 04.55.10 # Alright. 04.56.10 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 04.56.40 # Itunes is telling me that my ipod is corrupted. 04.56.55 # Should I just use manual drag n drop? 04.57.26 # You can, but you will only be able to play music copied with that method with Rockbox, not with the Apple firmware. 04.57.39 # Alright. 05.01.58 # Is there a certain folder that I must copy my music to? 05.02.38 # nope. 05.04.56 # If you don't see your files, they may be hidden. Check Rockbox's "Show Files" setting ( http://download.rockbox.org/manual/rockbox-ipodvideo/rockbox-buildch8.html#x11-1370008.2 ). 05.08.08 Quit Carter ("ChatZilla 0.9.84 [Firefox 3.0.10/2009042316]") 05.18.28 Quit rvvs89 (Read error: 104 (Connection reset by peer)) 05.21.28 Quit ved_ (Read error: 104 (Connection reset by peer)) 05.46.51 # New commit by 03unhelpful (r20871): Plugin JPEG decoder for data in memory, along with test_mem_jpeg.c and bench_mem_jpeg.c plugins to test and benchmark it, and a line-length clean up ... 05.48.13 Join Horschti [0] (n=Horscht@xbmc/user/horscht) 05.48.20 Quit Horschti (Read error: 104 (Connection reset by peer)) 05.54.55 Quit Horscht (Read error: 60 (Operation timed out)) 05.55.37 Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-9734735908de6403) 05.59.52 # New commit by 03unhelpful (r20872): Fix red. 06.19.12 # New commit by 03unhelpful (r20873): Small size improvement for JPEG on ARM/Coldfire. 06.42.19 *** Saving seen data "./dancer.seen" 06.51.00 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 07.03.56 Join AndyI [0] (i=AndyI@212.14.205.32) 07.09.29 Join toffe82 [0] (n=chatzill@adsl-71-154-234-200.dsl.frs2ca.sbcglobal.net) 07.16.45 Quit rwcr (Read error: 104 (Connection reset by peer)) 07.17.51 Quit AndyIL (Read error: 110 (Connection timed out)) 07.18.38 Join rwcr [0] (n=oremanj@xenon.get-linux.org) 07.27.00 Quit CaptainKwel (Read error: 110 (Connection timed out)) 07.31.15 Quit FlynDice (Remote closed the connection) 07.33.58 Join FlynDice [0] (n=jack@c-24-19-225-90.hsd1.wa.comcast.net) 08.05.56 Join flydutch [0] (n=flydutch@host219-166-dynamic.15-87-r.retail.telecomitalia.it) 08.07.28 Join fyrestorm [0] (n=nnscript@cpe-24-90-84-236.nyc.res.rr.com) 08.10.52 Quit Rob2222 (Read error: 104 (Connection reset by peer)) 08.10.56 Join Rob2222 [0] (n=Miranda@p4FDCD123.dip.t-dialin.net) 08.18.12 # I have a strange thing on the battery bench file for the X, it start at 02:49:17 08.19.39 # and finished at 17:53:11, so the real time is 15 hour or 18 H ?? 08.21.40 Join kachna|lappy [0] (n=kachna@r4ax178.net.upc.cz) 08.27.59 Part toffe82 08.31.34 Quit kachna|lappy (Remote closed the connection) 08.31.44 Join kachna|lappy [0] (n=kachna@r4ax178.net.upc.cz) 08.31.46 Join paulk_ [0] (n=paulk@lib33-1-82-233-88-171.fbx.proxad.net) 08.32.45 # Hello ! i've got a sansa e250v1 with the USb firmware. In ubuntu 8.10 (i'm using ubuntu), it was corresclty working. in ubuntu 9.04, i can't mount the sansa, please, can you help me ??? 08.36.04 # no ? 08.36.51 # ok, i'll try by another way, bye ! 08.37.01 Quit paulk_ ("Ex-Chat") 08.37.02 # patience... 08.37.03 # paulk_: there is a bug in ubuntu's HAL layer which marks the sansa as an MTP device 08.37.05 # have some patience! 08.37.08 # jesus 08.37.32 # morning everybody ;) 08.37.47 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 08.38.03 # morning! 08.40.31 # arg, morning already? i should goto bed :( 08.40.37 Nick Guest60183 is now known as feisar- (n=jljhook@irkki.fi) 08.41.16 Nick feisar- is now known as feisar-- (n=jljhook@irkki.fi) 08.42.20 *** Saving seen data "./dancer.seen" 08.42.44 Quit faemir ("Leaving") 08.43.02 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 08.47.34 Join petur [50] (n=petur@rockbox/developer/petur) 08.49.37 Join matsl [0] (n=matsl@dhcp100.contactor.se) 08.58.13 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.58.42 Join Rob2223 [0] (n=Miranda@p4FDCD423.dip.t-dialin.net) 09.03.31 Join Zagor [242] (n=bjorn@rockbox/developer/Zagor) 09.14.02 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 09.16.55 Quit Rob2222 (Read error: 110 (Connection timed out)) 09.17.44 Quit bertrik (Remote closed the connection) 09.20.25 Quit timc (Read error: 110 (Connection timed out)) 09.21.39 # New commit by 03unhelpful (r20874): Convert Huffman decode from inline function to macro, for small code size saving on ARM and on Coldfire color, only finish DC decode on greyscale ... 09.22.35 Join timc [0] (n=aoeu@116.3.10.249) 09.23.40 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 09.34.22 Quit Lss (Read error: 104 (Connection reset by peer)) 09.35.51 # * GodEater enjoys Bagder's screencast on how to build rockbox 09.42.29 # the missing compiler in the PATH was a bonus! ;-) 09.43.43 # yes 09.43.57 # I think perhaps another screen cast showing how easy it is to build the cross compilers would be good 09.43.58 # Videos with common things that can go wrong might not be bad in general. Help reduce the general "I don't understand this error" panic 09.44.22 # yeah, building cross-compilers and setup PATH etc is a good idea 09.44.26 # the commentary on the error could have been better "the path is there but it's not in the path" 09.44.46 # wouldn't make a whole lot of sense if you didn't already know what you were talking about :) 09.44.46 # Ogg Tremor? 09.44.47 # indeed, I thought that as well when I heard myself afterwards... 09.44.58 # but on the whole - I liked it :) 09.45.10 # oh 09.45.11 # Theora presumably ;) 09.45.14 # right 09.45.21 # too many "T" words 09.45.39 # I like the idea of official videos, especially ones about processes that won't change often so we don't need to worry so much about updating 09.46.33 # * GodEater wonders who has the best speaking voice on the RB staff 09.46.45 # if you come up with specific ideas I could try doing a few 09.47.02 # not that I have the best voice but... 09.47.18 # you're perfectly understandable 09.47.59 # * GodEater also enjoyed the quick peak he got at the forums "admin" button that he never sees :) 09.48.26 # hehe, yeah I was a little worried in general what things that could possible get revealed in all this 09.48.38 # like the quick view of some urls in my browser history 09.48.51 # well at least you didn't dive into the "Forums admin" bit and open up the "users we hate" thread :) 09.49.01 # youporn / redtube ? :) 09.49.07 # I'll add that as a separate idea ;-) 09.49.26 # "video: this is how we deal with annoying users" 09.49.58 # hahaha 09.50.40 # I wonder what other videos we should do ? 09.50.50 # "Idiot's guide to RBUtil" ? 09.51.08 # A guide to rbutil might actually be pretty useful 09.51.22 # indeed 09.51.36 # I don't think I'm the most suitable person for that though 09.51.41 # Specifically, people seem to like to change things *after* autodetect detects them. Somehow it's not clear that once you've clicked it, unless it says it can't find something it's done 09.51.42 Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-5ee0fe6d329a06ef) 09.52.36 # You'll eventually need docs on how to watch the videos... 09.53.13 # why ? 09.53.35 # A video detailing how to use RbUtil? 09.54.17 # yes.... 09.55.04 # Isn't the purpose of RbUtil to be the "easy" method? If you're giving them instructions why can't they just do the manual method? 09.55.24 # if the easy fails, give them the harder way? 09.56.17 # What's the difference between instructions saying "click here" and instructions saying "type this here"? 09.56.35 # people are scared of command lines and text mode 09.56.49 # that's one big diff 10.01.18 Join kugel [0] (n=kugel@rockbox/developer/kugel) 10.04.28 Quit Thundercloud (Remote closed the connection) 10.14.58 Quit rwcr (Read error: 113 (No route to host)) 10.18.06 Quit andy` (Read error: 104 (Connection reset by peer)) 10.21.03 Join andy` [0] (i=andy@cassarossa.samfundet.no) 10.29.13 Quit timc (Read error: 110 (Connection timed out)) 10.29.40 Join seik [0] (i=seik@elsker.kanal2.net) 10.31.03 Join timc [0] (n=aoeu@118.202.225.33) 10.36.11 Join DeeboiFresh [0] (n=Stabreak@d14-69-63-235.try.wideopenwest.com) 10.37.03 Join Srit [0] (n=Srit@dslb-094-218-245-217.pools.arcor-ip.net) 10.37.39 Quit DeeboiFr3sh (Read error: 110 (Connection timed out)) 10.41.11 # linuxstb : ping 10.41.15 Part Srit 10.42.23 *** Saving seen data "./dancer.seen" 10.42.25 # mt-: it's worth asking whatever it is you want to know anyway 10.42.31 # even if linuxstb isn't currently here 10.42.40 # it's possible someone else might know :) 10.43.39 # GodEater : It's just that I wanted to know what he thought of the patches that he told me about, other than that I would've just asked :) 10.44.02 # well he'll see the question when he logs in later 10.45.26 Join advcomp2019_ [0] (n=advcomp2@unaffiliated/advcomp2019) 10.46.55 Quit cool_walking_ ("http://www.mibbit.com ajax IRC Client") 11.02.11 Quit timc (Connection timed out) 11.03.29 Quit advcomp2019 (Read error: 110 (Connection timed out)) 11.04.27 Join timc [0] (n=aoeu@119.109.106.209) 11.10.23 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 11.19.41 Quit DeeboiFresh (Read error: 104 (Connection reset by peer)) 11.21.33 Join DeeboiFresh [0] (n=Stabreak@d14-69-63-235.try.wideopenwest.com) 11.22.59 Join nibbler [0] (n=Nibbler@dialbs-088-079-172-027.static.arcor-ip.net) 11.32.32 Quit andy` (Read error: 104 (Connection reset by peer)) 11.33.43 Quit kugel (Read error: 113 (No route to host)) 11.34.31 Join kugel [0] (n=kugel@rockbox/developer/kugel) 11.34.39 Quit nibbler (Remote closed the connection) 11.36.14 Join andy` [0] (i=andy@cassarossa.samfundet.no) 11.50.57 Join petur2 [50] (n=petur@rockbox/developer/petur) 11.51.39 Quit petur (Nick collision from services.) 11.51.43 Nick petur2 is now known as petur (n=petur@rockbox/developer/petur) 11.53.40 Join Jaykay [0] (n=chatzill@p579E6B86.dip.t-dialin.net) 11.56.04 Join intrados_ [0] (n=intrados@cpe-71-67-129-220.woh.res.rr.com) 11.58.24 Quit intrados (Read error: 110 (Connection timed out)) 11.58.32 # Unhelpful: wouldn't it be faster to read/write an int at a time, not a char (in getc/putc)? 11.59.52 # kugel: would it? a *whole* lot of the data is bit- or byte-oriented. 12.01.04 # I'm not sure, but using the native data type is generally faster 12.01.29 # if you're reading many chars in a loop, reading ints will most likely be faster 12.01.32 # "native" being 32-bit? there are pretty much none of those. 12.01.47 # faster, even if i want chars? 12.02.49 # why should you want chars? 12.03.30 # our strcmp and strcpy read/write 32bit at a time too in their fast versions 12.03.40 # because of the amount of the data that *is* chars. 12.04.34 # the huffman tables and quantization tables are big blocks of characters. markers are all headed by a 0xff followed by a 1-byte marker ID. 12.04.41 # I haven't looked at the jpeg code much, but - if possible - reading native should be preferred 12.05.34 # and what i'm trying to say is that most of the header is a packed array of characters. the rest of the image is a packed stream of bits. 12.06.22 # pretty much the only 16-bit values are the marker size - on markers that have one. and i'm pretty sure there's nothing that's stored as a 32-bit value. 12.06.37 # the header is not the issue I'd think, that's neglible compared to the image data anyway, isn't it? 12.06.55 # it doesn't have to be stored as 32bit value 12.09.08 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 12.09.49 # our fast strcmp reads longs at a time too 12.10.49 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 12.11.45 # kugel: during the image decode, the data goes into a bit buffer, which may have bits in it already. if we really want to be able to read a long at a time, we'll need the bitbuffer to be 64 bits wide, so that we can 32 + whatever's in there. you really should look at what the jpeg code needs to do, i don't think there's a very good case for aligned reads of larger sizes. 12.13.59 # I just asked, you probably know it better 12.14.20 # I'm just saying that messing with chars is generally slower than using the native format 12.15.11 # i understand, and the decoder uses larger types after the bitstream data has been unpacked and decoded - 12.15.55 # after that only scaling comes? 12.16.48 # no, not only scaling. it's unpack -> dequantize -> IDCT -> scale 12.17.00 # using a 64bit buffer might still be faster 12.17.09 # next step is supporting direct-to-native output without using the scaler. 12.17.24 # oh, I though "unpack -> dequantize -> IDCT" is part of decoding 12.18.49 # basically, the image data is a series of variable-length Huffman codes. each Huffman code encodes the length of the data that follows it, and in the case of the AC coefficients, the length of the run of zeroes between coefficients. 12.22.22 # so, the Huffman codes are themselves bitstrings of arbitrary length. then you get an encoded length from the Huffman code, and you read that many bits, and sign-extend. none of these odd-length-of-bits items are byte-aligned, because that would make using them in the first place rather pointless. 12.25.33 # also, we need to be able to detect byte-aligned patterns within this stream of data. a byte-aligned 0xFF indicates a marker. a literal run of 8 1 bits, if it happens to be byte-aligned, has to be stored as FF 00. and then, if restart markers are in use, those are FF 12.26.35 # I wonder if using git would be of benefit for the mentors as it would benefit me ? 12.26.36 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 12.27.04 # some of the devs use git already :) 12.27.04 # mt-: you mean, if it would benefit them more than you? 12.27.24 # I use git, but haven't been much of a dev lately 12.28.27 # markun : not exactly .. I mean what benefit would they gain if I use git rather than svn ? (for me, branching and merging .. enough said!) 12.29.17 # Unhelpful: well, you could mask with some &-combo for that I'd think 12.30.18 # mt-: well, you can make them happy by committing often locally and then produce many diffs to be committed in svn 12.30.22 # i seem to recall there was a bit-twiddling hack for detecting the presence of a 0 byte in larger value 12.31.17 # that's what done in strcmp 12.31.32 Nick mt- is now known as mt (n=MTee@41.233.143.197) 12.32.45 # markun : umm, still can't really see the difference between that and producing a diff using svn ? 12.33.05 # you're welcome to take a shot at it. i rather think that with all the table lookups and multiplications being done that it will be hard to speed things up. 12.33.20 # mt: I guess not, as long as you make the diffs after every major change 12.34.19 # i hope that the scaler-free output will give a boost, since that's getting rid of a few extra multiplies per pixel... of course, if we want output at other than 1:8, 1:4, 1:2, or 1:1, that's no help. 12.35.19 # mt: also, with git I think it will be easier to try something out and revert to your last commit in case it's not the right way 12.36.06 # but just use svn if that works well enough :) The change to git will also cost you some time. 12.36.32 # i assume that after a has-zero test our strcmp just has to examine each byte to find the zero? 12.37.20 Quit blithe ("Lost terminal") 12.37.31 Join blithe [0] (n=blithe@blakesmith.me) 12.37.46 # yes 12.38.11 # or rather, if it finds a \0, handle the rest byte-wise 12.38.15 # svn is fine for me till now, I have yet to encounter a situation where it failed me, other than I have multiple working dirs for different 'features' .. that's why the most tempting part I see in using git is branching 12.39.02 # the real pain there might be if the *last* byte in is FF, because then i need to see the next byte, but i've got at least 32 bits in the bitbuffer :/ 12.41.19 # also, i rather fear trying to use a 64-bit buffer... how many targets have a 64-bit wide shift instruction? if they don't have one, manipulating the buffer reduces to several 32-bit wide shifts and masks and ORs that will probably be as bad as using getc. 12.42.24 *** Saving seen data "./dancer.seen" 12.57.08 Quit robin0800 (Read error: 110 (Connection timed out)) 13.24.05 Join midijunkie [0] (n=Miranda@pD95477C2.dip0.t-ipconnect.de) 13.29.58 Quit kugel (Read error: 110 (Connection timed out)) 13.35.25 Quit Jaykay ("ChatZilla 0.9.84 [Firefox 3.0.10/2009042316]") 13.37.53 # after separating rm parser and cook decoder, to use the parser (#include its header) , should I make a shared library (librm) and export it to PATH ? 13.39.49 Quit matsl (Read error: 110 (Connection timed out)) 13.40.46 # anyone with a nano care to help http://forums.rockbox.org/index.php?topic=21113.0 ? 13.42.33 # Let me see if I can find my cable. 13.45.02 # I believe I once saw in a sim (and looking at the code) that the recording screen mappings on the Ipods aren't completely working 13.45.44 # not 100% sure, but IIRC there were some actions "overlapping" or somesuch 13.46.17 Quit soap (Remote closed the connection) 13.47.42 Join soap [50] (n=soap@rockbox/staff/soap) 13.49.21 # ah, I think what I saw was that the recording screen's context menu wasn't reachable 13.49.43 # * Llorean needs to charge his nano a bit before he can test 13.49.56 # * pixelma suggests a sim 13.51.48 # There's definitely a problem with the screen. 13.52.03 # Tap of "Play" pauses recording. Medium press splits the file. Long press stops recording after splitting the file. 13.56.42 Quit midijunkie (Read error: 113 (No route to host)) 13.59.39 # one is "Play" with button repeat and "Play" as pre condition (new file) and the other (stop) is probably the standard cancel action which is "Play" with button repeat and BUTTON_NONE as pre 14.01.22 # The stop seems to happen on the release, or so it feels 14.06.02 # I wonder where that definition of ACTION_STD_CANCEL is used at all on the Ipods (there are two, the other one works with BUTTON_LEFT) 14.06.35 # button_context_standard in keymap-ipod.c 14.15.15 Join CaptainKewl [0] (i=jds@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 14.17.14 Quit Llorean (Read error: 104 (Connection reset by peer)) 14.17.34 Join Llorean [0] (n=DarkkOne@99.185.10.150) 14.19.17 # Getting rid of "__NEXTLIST(CONTEXT_STD)" at the end of recording_context would do the trick I think. This is my fault, by the way, if anyone's looking to blame someone. But if it helps, it looks like the ipods had _no_ recording screen functions before I put them there. 14.19.48 Join LambdaCalculus37 [0] (i=44a0430d@rockbox/staff/LambdaCalculus37) 14.20.01 # Do the buttons defined in ther NEXTLIST override the previous ones? 14.33.43 Join schrottplatz [0] (n=max@f053225125.adsl.alicedsl.de) 14.34.34 # if I understand correctly then no, first one is important. But the actions are slightly different there 14.35.44 # if they would be completely the same, the second one has no meaning at all 14.36.20 Join Grahack [0] (n=chri@ip-194.net-82-216-197.nantes.rev.numericable.fr) 14.42.25 *** Saving seen data "./dancer.seen" 14.49.34 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 14.50.09 # is it possible to tell from the forum stats somewhere when the last time a thread was "read" is ? 14.50.35 # Not anywhere in the UI at least. 14.51.08 # I was just wondering if the massively misnamed "simple guide to compiling" thread still needed to be sticky 14.52.17 # Unsticky it and find out. :) 14.52.39 # I wouldn't mind retiring it. 14.53.33 Quit _lifeless (Remote closed the connection) 14.53.38 Quit robin0800 (Client Quit) 14.53.52 Join _lifeless [0] (n=lifeless@188.16.125.122) 14.54.02 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 14.55.22 Quit sbhsu (Remote closed the connection) 14.55.39 Join robin0800_ [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 14.55.55 Quit robin0800_ (Client Quit) 14.56.00 # hahahahaha 14.56.03 # unstickied 14.56.16 # dropped down the forum straight away 14.56.29 # conf. call - back later 14.57.42 # Llorean: Should we resticky the thread, or do you really want to just retire it? 14.58.19 # Let it fall away 14.58.23 # Okay. 14.58.30 # Just direct people to the wiki page if it becomes necessary 14.58.30 # * LambdaCalculus37 watches it slip down 14.59.13 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 15.16.20 Join petur2 [50] (n=petur@rockbox/developer/petur) 15.16.49 Join evilnick [0] (i=0c140464@gateway/web/ajax/mibbit.com/x-923ffc3c01ce4670) 15.19.08 Join itcheg [0] (i=41d59de2@gateway/web/ajax/mibbit.com/x-880f680c9f458f32) 15.20.15 Quit petur (Nick collision from services.) 15.20.19 Nick petur2 is now known as petur (n=petur@rockbox/developer/petur) 15.20.37 Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) 15.25.29 Join {phoenix} [0] (n=dirk@p54B479D6.dip.t-dialin.net) 15.26.32 Quit SirFunk__ (Success) 15.26.35 Quit robin0800 (Success) 15.29.34 # Could someone help me debug this: http://pastebin.com/d3df57e4f. I'm trying to reuse "wavbuf1" over and over but it seems to crash when I've played too many samples, leading me to believe that memset() isn't clearing it... 15.33.09 # MarcGuay: Can you post some more of your code? e.g. how are all those variables you're using defined? 15.33.47 # The filename thing can simply be rb->snprintf(str_buffer, sizeof(str_buffer), "%s/%s", drum_dir, arr_filenames[i]); 15.34.02 # Can someone move this forum thread to Plugins please? http://forums.rockbox.org/index.php?topic=21603.0 15.34.09 # linuxstb: I've added the declarations to the same pastebin. 15.34.40 # MarcGuay: No, they're here - http://pastebin.com/m38e93eab 15.34.59 # Oh, didn't realize it gave it a new address... 15.37.09 # evilnick: Sure thing. 15.37.31 # Never mind, BigBambi beat me. :P 15.41.49 # MarcGuay: pcm_play_data() is designed to start playing a large buffer of audio, one chunk at a time. The callback function (the first parameter - NULL for you) should give the pointer to the next chunk of data to play. I'm not sure what will happen if you keep calling that function over and over again. 15.41.58 Join faemir [0] (n=faemir@88-106-242-222.dynamic.dsl.as9105.com) 15.42.00 # Does Rockbox ignore id3 tags in vorbis files? I assume that it does as they're non-standard 15.45.02 # linuxstb: The strange thing is that it works fine if I load each sample into it's own, smaller, wavbuf, like so: http://pastebin.com/d6d9ece92. 15.45.34 # I was hoping I could reuse the same buffer so that the samples could be larger. 15.46.22 # evilnick: Yes. 15.46.40 # evilnick: s/non-standard/just plain wrong/ 15.50.55 # linuxstb: Thanks. I agree, but wanted to make sure before stating it as fact. 15.53.15 Quit DataGhost (Nick collision from services.) 15.53.23 Join DataGhost [0] (i=dataghos@unaffiliated/dataghost) 15.53.29 Join advcomp2019__ [0] (n=advcomp2@unaffiliated/advcomp2019) 15.54.52 Quit gevaerts (Nick collision from services.) 15.55.02 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 15.55.13 Quit CaptainKewl (Read error: 110 (Connection timed out)) 15.55.16 Join bzed_ [0] (n=bzed@devel.recluse.de) 15.55.38 Quit soap (lindbohm.freenode.net irc.freenode.net) 15.55.38 NSplit lindbohm.freenode.net irc.freenode.net 15.55.38 Quit advcomp2019_ (lindbohm.freenode.net irc.freenode.net) 15.55.38 Quit Zambezi (lindbohm.freenode.net irc.freenode.net) 15.55.38 Quit Bagder (lindbohm.freenode.net irc.freenode.net) 15.55.38 Quit bzed (lindbohm.freenode.net irc.freenode.net) 15.55.38 Quit trisiak (lindbohm.freenode.net irc.freenode.net) 15.55.38 Quit pabs (lindbohm.freenode.net irc.freenode.net) 15.56.24 Quit intrados_ (Read error: 104 (Connection reset by peer)) 15.57.47 NHeal lindbohm.freenode.net irc.freenode.net 15.57.47 NJoin pabs [0] (n=pabs@xor.pablotron.org) 15.58.41 NJoin trisiak [0] (n=tree@chello089078243195.chello.pl) 15.58.46 Join intrados_ [0] (n=intrados@cpe-71-67-129-220.woh.res.rr.com) 15.59.11 # linuxstb: Does it properly ignore them now, or does it fail to play the files like it used to? 15.59.38 Quit intrados_ (SendQ exceeded) 16.00.59 # I can't remember it ever failing to play them - I thought Rockbox always skipped id3 tags. 16.01.44 # I thought it was one of the many ways Rockbox could get stuck on a file while displaying 0:00 length 16.02.12 # Hmm, seems it doesn't skip them. The FLAC parser does though (I wrote that...) 16.02.16 # It used to have a problem with id3 on flac files, but linuxstb fixed that years ago 16.03.29 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 16.04.44 # Looking at the code, I would expect the metadata parser to reject any ogg files with id3v2 tags - because the file doesn't start with the "OggS" magic. 16.05.32 Join intrados_ [0] (n=intrados@cpe-71-67-129-220.woh.res.rr.com) 16.06.07 Join rwcr [0] (n=oremanj@xenon.get-linux.org) 16.09.45 NJoin Bagder [241] (n=daniel@rockbox/developer/bagder) 16.10.12 NJoin soap [50] (n=soap@rockbox/staff/soap) 16.17.09 Join itcheg [0] (i=41d59de2@gateway/web/ajax/mibbit.com/x-aa1ecf7a2c3ee134) 16.20.12 NJoin Zambezi [0] (i=Zulu@bnc.dotbnc.se) 16.21.33 Quit itcheg (Client Quit) 16.31.21 Quit tvelocity (Remote closed the connection) 16.37.02 Join barrywardell [0] (n=barry@barry-workstation.ucd.ie) 16.39.28 Join suom1_ [0] (i=markus@viitamaki.net) 16.40.21 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 16.42.28 *** Saving seen data "./dancer.seen" 16.42.36 Quit barrywardell (Remote closed the connection) 16.43.20 Join itcheg [0] (i=41d59de2@gateway/web/ajax/mibbit.com/x-6bd7d9fe17be3679) 16.46.10 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 16.49.22 Quit suom1 (Read error: 110 (Connection timed out)) 16.49.22 Nick suom1_ is now known as suom1 (i=markus@viitamaki.net) 16.56.35 Quit Grahack ("Leaving.") 17.02.16 # If someone could tell me why wavbuf2 is empty and all of the others are fine, I will love them forever: http://pastebin.com/m71d89c66 17.03.16 Quit Zagor ("Don't panic") 17.03.50 Join taylor_ [0] (n=taylor@c-24-91-82-205.hsd1.ma.comcast.net) 17.05.44 Join z35 [0] (n=z35@174.131.118.250) 17.06.51 Quit Zambezi (lindbohm.freenode.net irc.freenode.net) 17.06.51 NSplit lindbohm.freenode.net irc.freenode.net 17.09.55 Part taylor_ ("Leaving") 17.11.08 Join toffe82 [0] (n=chatzill@74.0.180.178) 17.11.18 # maybe check the return values of open() and read(), to make sure the files are read correctly. 17.12.45 # * GodEater is pleased to see domonoky is keen for MarcGuay to love him forever 17.14.17 # :-) 17.14.41 # It's the deal of a lifetime. 17.15.28 # domonoky: read() returns a length? 17.15.45 # yes, the length it was able to read. 17.16.08 # ... and I hate to ask a simple C question but to cast that int to a string so i can splash it? 17.16.16 # also, your current code will probably break, if one of those 5 raw files are smaller then your buffer. 17.16.16 # (char*)int? 17.17.00 # would it make more sense to say rb->read(raw_file, wavbuf5, sizeof(raw_file));? 17.17.11 # no, for splash you want a string. so use snprintf() to convert into a seperate buffer, and display it. 17.17.27 # okay 17.17.31 # the love is coming, don't worry 17.17.43 # :) 17.18.19 # and sizeof() wont work on a filehandle. there are seperate functions to get a file length 17.20.23 Quit petur ("work->bar (beer time!)") 17.20.43 # another remark: if you make your 5 buffers into a 2dimensional array, like wavbuffer[10000][5], your code can get much smaller :-) 17.21.02 Quit FOAD ("I'll be back") 17.21.39 # domonoky: Ideally I'd like that to be a single buffer that gets flushed and refilled whenever a button is pressed. 17.22.00 # But that was crashing so I'm trying to get back to where I was yesterday before I fudged it all up. 17.22.22 # :-) 17.23.30 # * gevaerts 's ipod dock seems to work nearly perfectly with rockbox :) 17.23.46 # for the read: use "filesize = read(raw_file,wavbufx,sizeof(wavbufx));", and check filesize afterwards for -1 (error) and otherwise store the size of playback. 17.23.49 # MT: you should add a rockbox styled makefile (see one of the other codecs) and then include that in apps/codecs/codecs.make so that your library gets built 17.24.15 # initially a good goal might be to simply get decoding working, then work on seperating all of the rm components cleanly from cook 17.24.29 # though i think you have the right idea using seperate librm and libcook folders from the start :) 17.24.39 # it only supports pausing though... 17.25.03 # saratoga : I was thinking about the test program .. How could I separate them and still get the test program to work (seeing that it needs headers from both dirs) 17.25.49 Join FOAD [0] (n=dok@dinah.blub.net) 17.27.03 Nick bzed_ is now known as bzed (n=bzed@devel.recluse.de) 17.27.44 Join __lifeless [0] (n=lifeless@188.16.125.122) 17.27.51 Quit _lifeless (Read error: 113 (No route to host)) 17.28.10 # domonoky: What would you say if I told you renaming wavbuf2 to wavbuf6 fixed the problem? 17.29.23 Join stoffel_ [0] (n=sfr@p57B4E290.dip.t-dialin.net) 17.29.37 # i would put it in a subdirectory of libcook, and change the makefile to reach up a few levels (something like ../../librm/rm.h) 17.30.10 # the bench test of my gigabeat X is strange . do you know why it doesn't start at 0 ? what is the real time , 15 or 18 H 17.31.05 # MarcGuay: strange. but maybe you get problems with the available plugin space. your buffers are pretty big. 17.32.33 # saratoga : moment of enlightment :) (they're separate now btw) 17.33.13 # domonoky: I was getting errors before because of that but found around where I have them works fine... 17.34.38 # MT: eventually i wan to do away with the individual test programs for ape, cook, etc and instead replace them with a general mechanism that wraps the ci->read_filebuf, ci->advance_buffer, etc so that we can compile the exact rockbox parser outside of rockbox 17.35.01 # this way people could more easily port them to other programs, and of course we'd have a much easier time testing 17.35.12 # MarcGuay: there 512k of plugin buffer on swcodec targets. your wavebuffers alone are already 500k. 17.38.14 Join dude187 [0] (n=chris@cpe-75-187-51-53.columbus.res.rr.com) 17.40.12 # domonoky: That's all the memory that's really needed, though.. I suppose if I add anything more to the code I'd have to scale those back. 17.40.53 # saratoga : You mean modifying the test programs to use the same data structures that the codec api uses , so the parser would compile with no modifications for both rb and the test program ? 17.41.58 # MarcGuay: but if you get strange problems, its likely that you already hit the memory barrier. For bigger memory needs you should use the audiobuffer. 17.42.10 # MT: we'd get rid of the test programs entirely, and just have an option in the make file that compiles the rockbox parsers outside of rockbox 17.42.26 # by wrapping the codec interface calls to go to fopen, fseek, etc 17.42.50 # right now most codecs don't have their own test programs, so we can't test them except in the sim 17.44.06 # ah ok 17.47.10 NHeal lindbohm.freenode.net irc.freenode.net 17.47.10 NJoin Zambezi [0] (i=Zulu@bnc.dotbnc.se) 17.51.06 # saratoga: I'm not convinced by that - there's advantages to having test programs for codecs that are not linked to Rockbox. The APE test program for example includes CRC checking of the decoded frames, which isn't done in Rockbox. SImilarly, the FLAC test program could do the same thing (verify the whole-file MD5 checksum), although it doesn't. So even if you add a generic test framework, I wouldn't want to lose the specific ones that 17.51.06 # already exist. 17.51.50 # linuxstb: t hose could be added to the rockbox decoders and enabled for test via the preprocessor pretty easily i think 17.52.01 # though maybe its worth keeping those test programs anyway 17.52.38 # linuxstb : did you see the patches ? 17.53.20 # mt: Only briefly, but I should be able to look at them in detail soon (this evening). 17.53.35 Quit ender` (Read error: 104 (Connection reset by peer)) 17.55.11 Join SirFunk__ [0] (n=Sir@208-15-25-145.netsync.net) 17.56.16 # mt: But my first comment is that it needs a "README.rockbox" file for the first patch/commit, to at least say which revision of ffmpeg the code is from. 17.57.50 # linuxstb : Didn't write that for the patches :( , I thought it was only needed for the final one. 17.58.25 # btw, cook.c would have different revisions across patches 1 and 2. 17.58.39 # Hmm, why? 17.59.08 # Does that mean parts of the code are from a newer ffmpeg than cook.c ? 18.01.45 # currently no .. because all of the files (in patch 3) are either parser-related, or cook-related - which were produced by the fixed point patch - except for bitstream.[c/h] and bswap.h .. those are of a newer revision. 18.02.27 # OK. This is why I wanted those separate patches - to keep track of this stuff ;) 18.04.13 # you mean the README's ? :) 18.04.46 # Yes, those as well.. ;) 18.05.14 # But maybe just add three READMEs as a separate comment to that task. 18.05.47 # Which ffmpeg revision was the first patch from? 18.05.50 # ok .. though I feel the task is starting to look a bit messy :/ 18.06.12 # Well, hopefully we can close it soon... 18.06.32 Quit Zambezi (lindbohm.freenode.net irc.freenode.net) 18.06.32 NSplit lindbohm.freenode.net irc.freenode.net 18.06.43 # Trying to compile your first patch, I get lots of warnings in rm2wav.c (as well as other files). 18.06.52 # r18077 18.07.53 # yes .. almost all of those warnings are for unused variables (it even complains about those declared in the headers and used in .c's) .. 18.08.16 # some of the warnings were fixed in patch 3 though 18.08.20 # Hmm, you shouldn't declare variables in .h files. 18.08.37 # It would be better to remove the warnings in the first patch. 18.09.04 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 18.09.45 # but something like RMContext is used in cook.c, rm2wav.c and main.c 18.10.13 # also COOKContext (cook.c, main.c) 18.10.16 Join itcheg [0] (i=41d59de2@gateway/web/ajax/mibbit.com/x-882ce9c596772588) 18.10.28 Quit __lifeless (Read error: 60 (Operation timed out)) 18.12.06 # mt: You should also read docs/CONTRIBUTING in the Rockbox source code - e.g. you shouldn't use typedefs (for new code such as rm2wav.[ch] - you can keep what is already in ffmpeg) 18.14.09 # mt: You shouldn't declare the same variable in multiple .c files (which happens when you put it in a .h). You should only declare the type in the .h file. 18.15.01 # I read about the typedefs thing,but I saw a typedef like that in FLACContext, and I followed this style, I thought there could be exceptions or something like that. 18.15.20 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 18.16.04 # linuxstb : which variables are you talking about ? 18.16.07 # Yes, I think it's OK when interfacing with existing code. So maybe those are OK. 18.16.28 NHeal lindbohm.freenode.net irc.freenode.net 18.16.28 NJoin Zambezi [0] (i=Zulu@bnc.dotbnc.se) 18.16.51 # mt: wav_header[] is the one I saw - but you said that you were declaring variables in headers. 18.17.06 Quit Zambezi (Excess Flood) 18.18.55 # linuxstb : Other than wav_header, I'm only putting structs/function prototypes in the headers. 18.19.38 Join Zambezi [0] (i=Zulu@bnc.dotbnc.se) 18.20.03 # mt: Then that's fine. 18.20.08 # I'll move all the wav-related stuff to main.c (don't know why I didn't do that in the first place :/ ) 18.20.42 Join taylor_ [0] (n=taylor@c-24-91-82-205.hsd1.ma.comcast.net) 18.20.56 # mt: There isn't a main.c in your first patch (which is the only one I'm looking at). 18.21.17 Join archivator [0] (n=archivat@77.70.28.57) 18.21.22 # But I'm wondering why main() is in cook.c, and not rm2wav.c 18.21.29 # Yes, in the 1st one main() was in cook.c 18.22.31 # linuxstb : sorry, can't really remember the reason for which I put it there. 18.22.53 Join Jaykay [0] (n=chatzill@p579E6B86.dip.t-dialin.net) 18.23.31 # Can you move it to rm2wav.c, as well as cleaning up the warnings in the first patch? 18.23.49 # Hello all. This may sound like a weird question (has to do with RockBox) What is the approximate address where user-mode applications start running on the RockBox firmware. What I mean by this is.. for example, on computers main() would start around 0x080488fe 18.24.16 # taylor_: rockbox doesn't have the concept of user-mode applications 18.24.40 # Oh shoot, forgot, thanks. Better ask iPodLinux. 18.26.07 # linuxstb : ok. But what is the benefit of that ? (cleaning up all the warnings in the first patch, and I'm just asking :) ) 18.26.34 # mt: Starting with clean foundations for later changes. 18.27.12 # So later changes only add new features, instead of cleaning up old code. 18.27.23 # Why not clean the warnings for patch 3 instead ? 18.27.25 # Especially when it is brand new code (like rm2wav.c) 18.28.29 # I just don't like committing code which isn't clean - warnings are bad. 18.29.04 # But for parts of the patch which are ffmpeg code, we can live with them for now. It's mainly rm2wav.[ch] which should be clean on the first commit. 18.30.14 # Are patches 1 and 2 meant to be committed ? 18.30.16 # It's also a general principle in Rockbox to not commit code that has warnings (although your code is special, as it's not being built yet). 18.30.39 # mt: Yes, I want to commit patch 1 first, then ask you to make a "patch 2" against what is in SVN. 18.31.10 # I wouldn't have asked you to make the patches if they weren't going to be committed. 18.31.21 # (I'm not that evil...) 18.31.35 # Oh, didn't know that .. I thought they were just there to 'show history' . but ok, will work on them. 18.31.40 # :) 18.31.59 Quit SirFunk__ (Read error: 110 (Connection timed out)) 18.32.41 # Yes, when I talked about "show history", I meant that the history would be visible in the main Rockbox svn. 18.34.54 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 18.35.07 # OK .. so for the 1st patch to be committed : there should be no warnings in rm2wav*, main() to be moved to rm2wav and a README should be written. Is there still something missing ? 18.35.25 # Something else which is worthwhile is to do a "diff" on your files compared to the original ffmpeg ones, to ensure you've only made the minimal changes you needed (and no whitespace-only changes). I'm looking at a diff for cook.c and can see quite a few unnecessary changes. 18.36.03 # what was the problem about http://www.rockbox.org/tracker/task/8778 ? 18.36.13 # the "serious issues"is annoying :) 18.36.20 Join kugel [0] (i=kugel@rockbox/developer/kugel) 18.38.19 # linuxstb : uh oh, I think I'll have to replace a few files back from ffmpeg and re-edit them :) 18.40.02 # What was the reason for changing from random.[ch] to lfg.[ch] ? 18.40.31 # ffmpeg declared av_random deprecated 18.40.42 # and the warning mentioned using lfg instead 18.41.55 # Rockbox has its own PRNG, so maybe the real codec can use that, if needed? 18.42.29 *** Saving seen data "./dancer.seen" 18.43.25 # in the revision of cook.c in patches 2 and 3, a small cook_random() was defined, so it didn't need any of those headers. 18.43.56 # So is there a reason to change to lfg in the first patch? 18.44.10 Join _lifeless [0] (n=lifeless@188.16.105.180) 18.46.29 Join JdGordon| [0] (i=836b0070@gateway/web/ajax/mibbit.com/x-dd56d641c34fff28) 18.46.29 # I didn't know about that before I started to convert the decoder to fixed point and actually get the other cook.c revision. I just changed from random to lfg to avoid the warning. 18.47.50 Nick advcomp2019__ is now known as advcomp2019 (n=advcomp2@unaffiliated/advcomp2019) 18.50.09 # domonoky: Thanks for your help, the 2d array is much nicer! :) http://www.rockbox.org/tracker/task/10192 18.51.24 # linuxstb: are you thinking that the fixed point cook codec might be resynced to ffmpeg eventually? 18.53.38 # saratoga: I think that's up to ffmpeg developers - their code is very different to Rockbox's, and changes we make may not be ones they want. So it will probably not be easy to produce a patch they would accept... 18.55.31 # I'm assuming there are reasons the existing patches haven't been committed to ffmpeg... 18.55.56 # Also in the thread about the fixed point patch, the author of the patch mentioned that the fixed point decoder was actually slower (took ~2x the time iirc) on his desktop so it wasn't an option (although is was 25x faster for ARM ) 18.56.12 Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.10/2009042316]") 18.59.56 # linuxstb: then is it very important for us to stay close to ffmpeg's variables and whitespace? 19.00.18 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 19.00.24 Join miepchen^schlaf [0] (n=miepel@p579EC543.dip.t-dialin.net) 19.00.46 # MT: fixed point multiplies take several cycles (they're a multiply then a shift and an add), so on systems with an FPU, they're much slower 19.01.21 Join itcheg [0] (i=41d59de2@gateway/web/ajax/mibbit.com/x-6ad42971a1bebbc8) 19.02.58 # linuxstb : I had the same question as saratoga's, why do the files need to be that close to ffmpeg's ? 19.04.09 Quit bmbl ("Woah!") 19.04.30 # saratoga: It's important in order to see what functional changes have been made. 19.04.44 # The same reason we don't mix whitespace changes with normal Rockbox commits. 19.04.45 # doesn't the original patch against ffmpeg handle that? 19.05.10 # I simply don't want to commit unnecessary changes. 19.05.31 # i'd like to see all the ffmpeg baggage removed even if the codec ends up quite different from the original ffmpeg one 19.06.01 # Sure, but that's for later, not step 1. 19.06.33 # perhaps but I don't think its important to go out of our way to avoid changing things at this step either 19.07.38 # i would like to get the parser and codec working in rockbox and commit when its a functional codec as we did with wma, then clean up from there 19.07.43 # I see it as the opposite, don't make changes you don't need to. 19.09.52 # but now that there might be some files with unnecessary - though not harmful - changes, wouldn't be a waste of time to go back cleaning all of that ? 19.10.01 Part taylor_ ("Leaving") 19.11.23 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 19.12.00 # I don't think so, no. SVN commits are there forever, so it's worth doing it right from the start. And it's good practice for producing clean patches for the future. 19.13.58 # when initializing a struct to 0 (like real_object_t) is it better to memset each declaration to 0, or initialize the variables inside the struct itself ? 19.14.25 Quit krazykit (Read error: 60 (Operation timed out)) 19.14.27 Join krazykit [0] (n=kkit@76.252.6.10) 19.15.03 Quit miepchen^schlaf () 19.17.00 Quit flydutch ("/* empty */") 19.17.06 # linuxstb : no warnings for rm2wav now (they were all about unused/uninitialized variables). 19.17.14 Part seik 19.18.08 # mt: I would probably use memset() for that - assuming it needs to be initialised. 19.19.01 # There were warnings about it, that's why. 19.21.24 # Are there? I can't see any in the version I'm compiling. 19.21.41 Join Lss [0] (n=Lss@cm7.delta91.maxonline.com.sg) 19.22.34 # I was receiving warnings like this "warning: ‘obj.size’ may be used uninitialized in this .. " 19.24.55 # Must be caused by a different gcc version, unless your code is different to libcook.patch1 ? 19.25.12 # I'm using gcc 4.3.3 19.25.34 # I'm using 4.2.4 19.27.14 # could you pastebin the warnings you're receiving ? 19.28.14 Join midijunkie [0] (n=Miranda@pD95477C2.dip0.t-ipconnect.de) 19.29.19 # http://pastebin.ca/1416602 - that's an unmodified libcook.patch1 19.30.36 # I don't receive the warnings about (ignoring the return values for read/write) 19.31.06 # rest of the warnings are the same as I get without those related to real_object_t 19.31.18 # It's good practice to always check the return values of read/write for errors. 19.32.03 # But you could simply assign it to a variable (i.e. res = read(...)) and then not do anything with it for now. That should silence the warning. 19.33.50 # now I remember why main() is in cook.c , it was before I moved COOKContext and the needed function prototypes to an external cook.h 19.34.21 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 19.34.44 # so I just wrote main() there because my goal then was just to be able to transcode the files properly 19.39.11 Join miepchen^schlaf [0] (n=miepel@p579EC543.dip.t-dialin.net) 19.40.27 # linuxstb : when compiling apps/codecs/libffmpegFLAC/main.c, you receive the same warnings about read/write ? 19.40.53 # mt: I did that a long time ago... ;) 19.41.33 # Older versions of gcc didn't give that warning (as you are experiencing). 19.41.55 # So some warnings could be ignored :) 19.43.04 # The current rm2wav should give no warnings though.. 19.43.20 # (the one I'm working on for patch 1 that is ..) 19.43.42 Join taylor_ [0] (n=taylor@c-24-91-82-205.hsd1.ma.comcast.net) 19.43.52 Part taylor_ ("Leaving") 19.45.56 # mt: I'm just fixing the FLAC main.c now ;) 19.47.06 # " In your face mt !" heh 19.52.43 # New commit by 03dave (r20875): Check some previously unchecked return values in the standalone FLAC test program - fixes some warnings spotted by Mohamed Tarek El Haddad (mt). 19.54.46 # linuxstb : Do you still have some time ? I'm just checking because I want to finish patch 1 tonight. 20.01.58 # mt: Yes, I should be here all night. 20.02.23 # great. :) 20.04.03 # Is it for lack of time or interest that there isn't a dynamic range compressor in rockbox or is there something major that would stand in the way? 20.05.10 # archivator: The only issue I can think of is that it would need to be in the core, so needs to be implemented efficiently. I can't think of a reason anyone would object on principle though. 20.06.08 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 20.06.24 Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-90d316d05a2fa7d0) 20.08.08 Join pyro_maniac [0] (n=jens@91-64-227-210-dynip.superkabel.de) 20.08.43 # linuxstb: drc is not that complex a dsp filter, from what I can tell. The only slightly complicated thing is that there are attack and release times you'd need to take into account. I have virtually 0 experience with dsp in rockbox so I might not be the man for the job (though I wouldn't mind taking a stab at it). Just wanted to make sure there wasn't something big I was overlooking... 20.11.28 Join einhirn [0] (n=Miranda@p4FC625DF.dip0.t-ipconnect.de) 20.22.41 # archivator: I'm not an expert either, so maybe someone else will think of an objection/problem... 20.24.42 Join tessarakt [0] (n=jens@e180074074.adsl.alicedsl.de) 20.28.03 Join SirFunk [0] (n=Sir@208-15-25-145.netsync.net) 20.34.21 # If I wanted to play a FLAC file from a plugin where should I look first? Does it get converted to raw PCM before being played? 20.39.25 # linuxstb : considering that in patch1, COOKContext was still in cook.c , should I still move main() to rm2wav.c ? (which would require putting COOKContext, and func. prototypes into a separate cook.h) 20.40.09 Join taylor_ [0] (n=taylor@c-24-91-82-205.hsd1.ma.comcast.net) 20.42.02 # MarcGuay: There is no mechanism for plugins to use codecs. You would have to link your plugin with the FLAC decoder and do it yourself. 20.42.16 # (or implement such a mechanism...) 20.42.16 Part taylor_ ("Leaving") 20.42.33 *** Saving seen data "./dancer.seen" 20.42.40 # mt: I think leaving main() in cook.c is fine for now - it's less intrusive. 20.42.50 # linuxstb: Thank you. 20.43.45 # MarcGuay: Although you can access Rockbox's normal playback code - i.e. add your file to a playlist and start playback. 20.44.00 # But I'm guessing that's not what you want? 20.44.43 # linuxstb: I'm interested in just playing the sound file, with the possibility of playing multiple sound files simultaneously. 20.45.39 Quit bertrik (Remote closed the connection) 20.47.11 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 20.50.24 Quit {phoenix} (Remote closed the connection) 20.50.26 # New commit by 03alex (r20876): Add missing crossfade enable option - fixes FS#10170. Also re-arrange the options to match the target. 20.51.05 Quit fyrestorm (Read error: 104 (Connection reset by peer)) 20.52.54 Join calman_ [0] (n=caleb@dhcp-064-247-086-012.eg1.ohiou.edu) 20.53.01 Join {phoenix} [0] (n=dirk@p54B479D6.dip.t-dialin.net) 20.57.27 # GodEater: any comments on the c200 keymap patch - as you volunteered for testing? (Llorean as well, I believe?) 20.59.18 # I liked it - no issues 21.00.10 # pixelma: I know I say this everytime it is mentioned, but I think it should go in now :) 21.00.23 # me too 21.06.24 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 21.08.31 Quit stoffel_ ("leaving") 21.09.02 Join fyrestorm [0] (n=nnscript@cpe-24-90-84-236.nyc.res.rr.com) 21.09.30 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 21.11.25 # linuxstb : how is that for the readme ? http://pastebin.com/d5af4e013 21.15.56 # mt: "flac.c" ? 21.16.22 # Also, you should state the SVN revision, not just the date (CVS doesn't have handy revision numbers) 21.17.06 # oops, missed that .. (flac.c) 21.17.37 # I would just keep random.[ch] (unless that caused compile errors), rather than switching to lfg.[ch], especially if you are going to remove it later. But I won't argue over that... 21.18.05 Quit intrados_ (Read error: 60 (Operation timed out)) 21.18.48 # I've already removed them... the code didn't depend on them anyway. 21.19.08 # So why does the README mention them? 21.19.15 Join intrados_ [0] (n=intrados@cpe-71-67-129-220.woh.res.rr.com) 21.19.51 # New commit by 03alex (r20877): Correct what happens when selecting Recording in the Main Menu in the manual. Fixes FS#9768 21.20.07 # sorry, by 'the code' I meant the code I modified back then when I was still working on the decoder. 21.21.12 # Also, your program shouldn't compile to "cooktest.o" - it should just be "cooktest". 21.21.24 # ok 21.23.19 # are those all the comments ? 21.23.28 # And you can remove "INC" from the Makefile. 21.24.31 # You should add a (C) and license header to your own files (rm2wav.[ch]) 21.25.59 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 21.28.30 # linuxstb : in rm2wav .. I believe I should add a (C) with your name too, but what should the year be, 2007 ? 21.28.33 # how does the wps get it's data to display (progress, current song playing, etc.) Is there an easily identifiable interface for this? 21.29.14 # linuxstb, MarcGuay: Or use the same mechanism as test_codec: provide the codec api from your plugin and load the codec from it 21.29.33 # BigBambi: is this forcing a new line (your changes to recording.tex)? Also, if the last line that shows up as changed in the coloured diff in this file is describing the recording screen, I think it's not even true anymore 21.29.43 # To be precise, loadthe codec from within the plugin 21.29.59 # BigBambi: those settings are now shown in the status bar I think 21.30.36 # mt: You can just say "2007-2009". But I don't think it's that important, as the code hasn't been published until now. 21.31.05 # pixelma: yes, and I didn't change that (in that order) 21.31.31 # amiconn: Yes, I had forgotten about test_codec.... 21.31.53 # BigBambi: I guessed, but it drew my attention... something to "fix" 21.32.08 Quit HellDragon (Read error: 54 (Connection reset by peer)) 21.32.29 # pixelma: I'll do it now 21.32.58 # mt: Or if you're asking about my (C) line, then maybe just say "2008". 21.33.44 # BigBambi: and about the newline - I though it was only \\ ? 21.34.01 # pixelma: \\ is a new line - \\* forces a blank line 21.34.26 # I think it looks much easier to read with some spacing :) 21.34.42 # ah, hmm... first time I saw that used though 21.35.06 # It is in there a few times (prabably my previosu changes). According to to Google it is standard latex 21.35.25 # And I do think it looks bad when everything is in one great big block of text with no white space 21.37.29 # pixelma: For the frequency and channels stuff any objection to just changing it to be "are shown in the status bar"? 21.38.33 Join Sedgewick [0] (n=Sedgewic@net-93-145-241-177.t2.dsl.vodafone.it) 21.39.04 # linuxstb : now for the "diffing against ffmpeg" part :) 21.40.18 # are there some specific files for which you think it's absolutely necessary to do this ? (I've done avcodec.h and had no problems except one white space in line 1706) 21.40.50 # my comments look a bit messy though I know :/ 21.42.02 # BigBambi: no (and it applies to the quality setting on the mascodec too) - oh, and while you're at it, you could change those opts to the (IMO better) automatically generated ones. I believe there is a recording_hwcodec and recording_swcodec which could be used 21.42.12 # OK, will do 21.43.04 # nice :) 21.43.11 # mt: All of them... Hopefully there won't be much to fix. 21.43.26 # pixelma: Then screen shots :/ 21.43.34 # I really hate producing screen shots 21.43.44 # It takes for fricking ever to build all the sims 21.45.06 # linuxstb : I forgot to mention that bitstream was taken from saratoga's wma. 21.45.29 # uh, which reminds me that there are now different colours for some targets (e.g. Ondio "background" colour, some greyscale are now different to represent the real display's "colour" better even with targets of the same screen size etc.) ... :\ 21.45.53 # yes 21.45.57 # mt: I've just looked at current ffmpeg, and it seems they are up to 18773 - your copy was from 18077? 21.46.00 # I'm going to ignore that for now 21.46.25 # MT: for the static memory changes? 21.46.44 # mt: r18079 removed the use of avrandom() in cook.c... 21.47.28 # linuxstb : I got the revision from version.h in ffmpeg dir. 21.48.54 # saratoga : I used your bitstream files but modified them a bit (commented out av_log2 since it was still defined -in common.h iirc and changed alloc_table back to using realloc) 21.49.56 # This should go to the readme. 21.50.15 Join SirFunk_ [0] (n=Sir@208.15.25.145) 21.50.26 # New commit by 03alex (r20878): Correct location of frequency, quality and channel settings display, and change opts. 21.51.52 # mt: If you update your code to r18079, you don't have to worry about the use of av_random. 21.52.33 # eventually I'd like to have wma and cook use the same bitstream.c/h so we can optimize one and use it for both codecs 21.53.25 Join froggyman [0] (n=47ba40e2@91.191.140.131) 21.53.26 # linuxstb : I don't think it's that important really. 21.54.31 # saratoga : I think starting from patch 3 cook could use the same bitstream files as wma 21.55.10 # I'll include this in a later patch. (the one which should include separate rm/cook dirs) 21.55.44 # sure, jsut somethnig to keep in mind 21.55.46 # mt: It's also very quick to do - anything to make your patch smaller and the number of things listed in the readme is good... 21.56.37 Join HellDragon [0] (n=jd@modemcable022.187-203-24.mc.videotron.ca) 21.56.40 # linuxstb : sorry, what are you referring to by 'it' ? (I'm a bit tired now :) ) 21.57.22 # mt: Updating your files to ffmpeg's r18079 - it's just two revisions from your version. 21.59.10 Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") 22.00.22 Join amblin [0] (n=user@unaffiliated/amblin) 22.00.52 Join SirFunk__ [0] (n=Sir@208-15-25-145.netsync.net) 22.01.20 Quit SirFunk (Connection timed out) 22.02.00 # what's currently the best supported non-hd platform/player? 22.02.34 # Best is quite subjective. What qualities are you looking for in particular? 22.02.55 # stability and battery life 22.03.09 # e200 or c200 or nano 22.03.19 # nano really? 22.03.24 # make install 22.03.26 # dammit 22.03.29 # hah 22.03.34 # the e200s are quite mature these days 22.03.49 # im nearly 100% ogg, if that matters I know battery life wasn't so good on ipods 22.03.52 # amblin: It isn't bad from what I hear, but I don't have any experience of it myself 22.04.31 # If you're after battery life then you might want to choose a less cpu-intensive codec 22.04.34 # amblin: I'd have a e200 over a c200 (having got both), but the e200 can have a bit of electrical noise that you may or not hear depending on earphones 22.04.52 # linuxstb : just looked into cook.c r18079 - It's exactly the same modifications I made except that it uses random_seed() which we decided not to use (due to its crazy way of getting a random seed) and merbanan told me I could just initialize this value to any number, so I just initialized it to 1. 22.05.19 # amblin: Personally, I can hardly ever hear the electrical noise, unless I am listening at rather quiet volumes 22.05.24 # evilnick: Ogg is pretty easy on the CPU, for a long time it was one of the fastest ARM codecs aside from flac and mpc 22.05.46 # the sansa noise probably mainly happens with 16 ohm headphones and IEMs for what its worth 22.06.16 # i like ogg for other reasons, but that isn't a discussion for this channel :-) 22.06.23 # amblin: Apologies for the misinformation about vorbis. 22.06.43 Quit SirFunk_ (Read error: 145 (Connection timed out)) 22.06.53 # so any e2** series? 22.07.07 # yes, but v1 only 22.07.10 # saratoga: Is that an ARM-related thing? I could have sworn that vorbis was significantly more difficult to decode 22.07.25 # amblin: v1 is rare and expensive, v2 isn't supported 22.07.29 # amblin: And you can only tell for sure if it is v1 by looking at the original firmware version 22.07.37 # Jaykay: not so much 22.07.44 # Jaykay: It is just difficult to tell 22.07.47 # Jaykay: tigerdirect.ca still sells v1 e280s 22.07.49 # ok let me rephrase, best suppored and available to buy 22.07.53 # I just bought one a month ago 22.08.12 # amblin: No supported targets are still available new 22.08.20 # ah 22.08.38 # that isn't a good situation sniff 22.09.20 # mt: Then it shouldn't be a problem to say your versoin is based on r18079, and change the README to say what you did with the random seed. I see that r18078 was a change in nellymoserdec.c, so not applicable to you. 22.09.44 # wtf? e280 for 50$ refurbished and 68$ new 22.09.51 Join calman__ [0] (n=caleb@dhcp-064-247-085-091.eg1.ohiou.edu) 22.10.13 # OK .. will do that. 22.10.41 Quit calman__ (Client Quit) 22.10.47 # evilnick: I've heard people say that, but Vorbis isn't much different then most other lossy codecs 22.10.56 # i think its actually a little less cpu intensive then mp3 for instance 22.10.56 # chex: are both e280 there v1? 22.11.06 # jaykay where? 22.11.16 # tigerdirect.com 22.12.05 Quit calman_ (Read error: 104 (Connection reset by peer)) 22.12.10 # amblin: if you can make sure they're v1 buy them 22.12.17 # (on of them :) ) 22.12.17 Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-2116087ca5f779ca) 22.12.21 # one... 22.13.48 # Jaykay: Im pretty sure, the one I ordered was 22.16.33 # BigBambi: the c200 suffers the same issue re. electrical noise 22.17.00 # pixelma: OK, that's good to know - I haven't used my c200 enough to notice :) 22.17.59 # what's the outlook for rockbox on new hardware in the future? 22.18.58 # well, I can't compare but I can hear e.g. the reads when inserting the microSD (so nothing playing yet), also noticeable in the OF but my impression is that it's not as "loud" - would need a more objective test though 22.21.28 Quit archivator () 22.24.53 # are sansa devices sans rockbox, mass storage? 22.28.39 Quit Sedgewick (Connection timed out) 22.30.31 # amblin: Yes, you can select mass-storage or MTP. 22.35.43 # thanks for the help 22.35.46 Part amblin ("ERC Version 5.3 (IRC client for Emacs)") 22.38.31 Quit bluebrother (Nick collision from services.) 22.38.36 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 22.40.29 Join vedlith [0] (n=ved2@137-mi2-1.acn.waw.pl) 22.42.37 *** Saving seen data "./dancer.seen" 22.43.46 # linuxstb : I think I could create the patch now. Do you want to check on anything before I create it ? 22.44.27 # mt: I'm happy to look at it before you post it to flyspray 22.44.51 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 22.44.55 # linuxstb : pastebin ? 22.45.09 Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) 22.45.15 # Yes, unless you have some webspace to upload it to? 22.45.56 Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-546e89ca333ce0af) 22.46.12 Join Jaykay_ [0] (n=chatzill@p579E7E60.dip.t-dialin.net) 22.47.37 # New commit by 03alex (r20879): Add missing Calendar screenshots to the manual. Fixes FS#10036. 22.48.13 Join robin0800 [0] (n=robin080@general-kt-199.t-mobile.co.uk) 22.48.49 # linuxstb : I could upload it to the sourceforge repo, or you could pull from me (I'm not sure about that, just started using git) 22.49.59 # hmmm, I seem to have added keywords to those files by mistake. Does this matter, and if so, how to I remove them? 22.52.17 # mt: Just use pastebin then. 22.56.55 Join Strife89 [0] (n=michael@204.116.244.200) 23.00.56 # linuxstb : seems the file is large for pastebin to handle .. I keep getting an error that allowed memory size is exhausted. 23.01.48 Join robin0800_ [0] (n=robin080@general-kt-199.t-mobile.co.uk) 23.02.00 # mt: OK, then maybe commit to your svn. Or you could just email it to me. 23.02.17 Quit evilnick ("http://www.mibbit.com ajax IRC Client") 23.03.19 Quit Jaykay (Read error: 110 (Connection timed out)) 23.03.20 Quit robin0800_ (Client Quit) 23.03.55 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 23.04.03 Quit robin0800 ("Ex-Chat") 23.05.01 # linuxstb : which do you prefer of the both ? I don't have a particular preference. 23.05.59 # BigBambi: It hopefully doesn't hurt, but best to delete them - "svn propdel svn:keywords *.png" should work (I notice one other file has them) 23.06.03 # saratoga: Ogg used to be slower than mp3 quite some time ago on arm, at least on PP5002 (that was before dual-core mp3(!)) 23.06.12 # mt: Email 23.06.15 # linuxstb: OK, thanks 23.06.18 Join MarcGuay_ [0] (n=chatzill@ip216-239-68-5.vif.net) 23.06.47 # Not sure how it compares today; I only have two albums in vorbis 23.08.12 # New commit by 03alex (r20880): Remove svn keywords from image files. 23.08.23 Join robin0800 [0] (n=quassel@general-kt-199.t-mobile.co.uk) 23.10.06 Join MarcGuay__ [0] (n=chatzill@ip216-239-86-60.vif.net) 23.10.07 Quit pyro_maniac ("Leaving.") 23.13.17 Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-ea9fec2086518b81) 23.17.36 Quit Jaykay_ (Read error: 104 (Connection reset by peer)) 23.21.48 Quit MarcGuay (Read error: 110 (Connection timed out)) 23.22.17 Quit blithe ("Lost terminal") 23.22.18 # mt: Patch received - I've put it here: http://linuxstb.cream.org/rockbox/libcook.patch1 23.22.22 # New commit by 03alex (r20881): Add missing screenshots to Gigabeat S (or other 240x320 targets with recording + radio). 23.22.27 Join blithe [0] (n=blithe@blakesmith.me) 23.23.02 # linuxstb : ok. thanks. 23.25.03 # mt: You didn't fix those warnings with read/write ? Also, there are still warnings in the main() function you added to cook.c, and wav_header[] is still declared in rm2wav.h 23.26.37 Quit MarcGuay_ (Read error: 110 (Connection timed out)) 23.29.28 # linuxstb : Dear God ! I'm sure I fixed those read/write warnings, don't know how I managed to not include them in the patch -(this is one of the mistakes I told you about :/ ) .. Are you going to be here after ~20 mins ? I want to go eat something. 23.29.41 Join Makuseru [0] (n=max@163.106.40.24.aeneasdsl.com) 23.29.54 # mt: Yes, I should be around for another couple of hours. 23.30.03 Quit SirFunk__ (Read error: 110 (Connection timed out)) 23.30.13 Join MarcGuay [0] (n=chatzill@216.239.87.161) 23.30.17 Quit blithe ("Lost terminal") 23.30.21 # great, bbl then. 23.30.27 Join blithe [0] (n=blithe@blakesmith.me) 23.30.54 Join SirFunk__ [0] (n=Sir@208-15-25-145.netsync.net) 23.31.39 Quit Makuseru (Remote closed the connection) 23.35.17 Quit blithe (Client Quit) 23.35.27 Join blithe [0] (n=blithe@blakesmith.me) 23.35.32 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 23.39.41 Quit HellDragon (Read error: 104 (Connection reset by peer)) 23.40.17 Quit blithe (Client Quit) 23.40.24 # When editing english.lang (for spelling) should I change source or dest or both (and if both I assume I then need to fix all the other languages too)? 23.40.28 Join blithe [0] (n=blithe@72.14.176.144) 23.41.52 # and what about voice? 23.42.17 Quit blithe (Client Quit) 23.44.51 Quit schrottplatz ("o.O") 23.45.13 Quit bluebrother ("leaving") 23.45.28 Join blithe [0] (n=blithe@72.14.176.144) 23.45.40 # mt: A few more comments: 1) do you need to keep those commented-out lines in main() ? If it is debugging code, you could surround it by #ifdefs instead (using a suitable #define to enable). 2) You should declare packet_count to be the same type (uint32_t) as nb_packets, rather than casting it. 3) Do you need both bswap.h and libavutil/bswap.h ? 23.46.25 Quit MarcGuay__ (Read error: 110 (Connection timed out)) 23.47.26 Quit blithe (Client Quit) 23.48.09 Quit Strife89 ("Dinner is nearly here. :)") 23.50.28 Join blithe [0] (n=blithe@blakesmith.me) 23.51.32 Join HellDragon [0] (i=jd@modemcable022.187-203-24.mc.videotron.ca) 23.52.10 Join schrottplatz [0] (n=max@f053225125.adsl.alicedsl.de) 23.53.48 Quit blithe (Client Quit) 23.54.25 Join blithe [0] (n=blithe@72.14.176.144) 23.57.28 Quit LambdaCalculus37 ("Fwump") 23.58.05 Quit {phoenix} (Remote closed the connection) 23.58.10 Quit schrottplatz ("o.O")