Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2009-05-08

00:00:30JdGordon|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:49JdGordon|it shoudlnt ever be more than that
00:01:04kugelconstantly redrawn sounds horrid :/
00:01:29JdGordon|replace todays statusbar with a wps and you have what im takling about
00:08:59 Quit bertrik ("Leaving")
00:17:00amiconnThe 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:30amiconnChange the latter and the update problem will start appearing on mono and vertically-packed greyscale targets
00:18:49JdGordon|we are talking about what? 1px error lines?
00:19:27JdGordon|or up to 8 even?
00:19:47JdGordon|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:55amiconnUp to 7 pixels
00:22:32amiconnThat is, up to 8 in total at horizontal boundaries; up to 7 pixels into either viewport
00:23:13amiconnSame 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:27dfktare there any plans of implementing FFWD/REW with audio in rockbox?
00:35:49BigBambinobody is working on it AFAIK
00:36:35JdGordon|its pretty much a nodo isnt it?
00:36:41dfkti was looking around but didn't find any mentioning of it at all
00:36:46dfktnodo?
00:37:20BigBambiJdGordon|: Not that I'm aware of
00:37:24scorche|shsomething that wont be done/acceptable out of principle
00:37:38BigBambiI was under the impression that it is a pretty massive job
00:37:47BigBambiAnd nobody had attempted it
00:37:57BigBambiBut I've not seen it as a NODO anywhere
00:37:59dfktmassive job i understand, principle i don't understand :)
00:39:55JdGordon|the argument against it is that if you've already heard the part you wanted its too late...
00:40:08JdGordon|so there is no gain over just dionging it blindly
00:40:26BigBambiJdGordon|: But that doesn't make it a NODO
00:40:40JdGordon|unless you do it like my pvr thingy which rewinds 1 or 2 sec before playing again
00:40:41dfkti was just FFWDing a 90 minute mixtape, and it would really come in handy to hear when the next track starts
00:41:18scorche|shi wouldnt say it is a NODO either...it could be handy
00:41:20 Quit midijunkie ("?(???~~)?")
00:41:47JdGordon|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:53saratogatheres a thread about it in the forums
00:42:09saratogai 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:36JdGordon|the beast could do it!
00:42:38saratogaare 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:46dfktall cowons
00:42:53dfktincluding the ancient x5
00:43:02saratogaeven the X5 or just the newer ones?
00:43:10dfktx5, d2, s9, etc
00:43:10saratogathe new ones have quite fast CPUs
00:43:17dfktbut yes, x5 too
00:43:19scorche|shthe archos did it too, but..
00:43:24scorche|sharchoses
00:43:29JdGordon|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:00saratogado they speed it up or just play short clips as you go
00:44:04exposure101im not seeing much info about the Gen 6 ipod, will it even install?
00:44:18scorche|shthe latter, i would assume
00:44:21dfktsaratoga, sounds the same as cd player FFWD
00:44:29dfktchopped up bits
00:44:36dfktbut no speeding up
00:44:40saratogathat makes sense
00:44:47saratogacan they do it for Vorbis as well as MP3?
00:44:51dfktyes
00:44:53exposure101hows everyone?
00:45:02saratogahmm so thats pretty good then
00:45:12dfktflac too, iirc
00:45:20saratogathey either have a lot of really fast codecs or maybe its not as slow as i'd think
00:45:43scorche|shexposure101: 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:04saratogai guess it could be faked by issuing a lot of seek requests in sucession
00:46:31scorche|shonly thing i can find in the tracker about it: http://www.rockbox.org/tracker/task/1403
00:46:37dfktwell, any hint on where you are while FFWDing is helpful
00:46:41saratogamost of the codecs return less then 100ms worth of audio at a time
00:46:48exposure101thx scorche|sh
00:47:00saratogaso i guess request 200ms, then skip ahead a few seconds and so on
00:47:00BigBambisaratoga: the H100 OF did it too
00:47:09saratogaany 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
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:19kugelso
01:18:53 Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37)
01:19:11kugelhow 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:41JdGordonkugel: ? both cases should be the same regarding redrawing...
02:00
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:37CIA-38New 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:33froggymanOn 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:07froggymanany 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:25kugelJdGordon: 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:58kugelWhy 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:47kugelit's just that it cannot be done with ticks == 0. We could of course think about removing that possibility altogether
02:35:40Unhelpfulticks == 0 can actually be useful, though - for example, for peppering code that hangs with splashf's ;)
02:37:09kugelUnhelpful: 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:54kugelweird binsize distribution
02:46:04JdGordonkugel: because you still have the same problem with the screen not getting redrawn under it
02:46:40froggymananybody know why i am getting this codec failure? its seems to happen fairly frequently, too
02:47:12JdGordonfroggyman: 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:10froggymana couple of days ago (so it is quite recent)
02:48:36froggymandidnt add any patches to it, just got the pre-compiled build
02:48:55kugelJdGordon: 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:56kugelalso, that would solve issues with multiple splashes
02:52:05kugelin 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:00
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:00
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:20CarterAnyone else encountering errors running rockbox on 5g ipod
04:31:58krazykitwhat kind of errors?
04:33:19CarterI cannot run rockbox.ipod for some reason
04:34:12cool_walking_What is the exact error?
04:34:35CarterCannot run rockbox.ipod
04:37:42CarterI used Rockbox Utility to install
04:39:56 Join intrados [0] (n=intrados@cpe-71-67-129-220.woh.res.rr.com)
04:40:09cool_walking_Are you sure it isn't "Can't load rockbox.ipod: <something>"?
04:41:16CarterI think that is what it is
04:41:45Unhelpfulknowing 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:40CarterJust reinstalled, it runs now. Thanks though, it's nice that you guys have a medium of support for your users
04:46:12CarterAlso, can I sync with Itunes or do I have to manually drag n drop?
04:46:47krazykiteither one
04:46:57cool_walking_iTunes munts the filenames, so if you want to usefully use iTunes, you'll need to use Rockbox's database feature.
04:47:30CarterAlright where is that
04:47:52cool_walking_It's in the manual.
04:48:01cool_walking_http://rockbox.org/manual.shtml
04:48:24CarterThank you.
04:49:20 Join ved_ [0] (n=ved2@137-mi2-1.acn.waw.pl)
04:49:34cool_walking_Section 4. Browsing and playing
04:49:47 Quit vedlith (Read error: 104 (Connection reset by peer))
04:54:28cool_walking_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:10CarterAlright.
04:56:10 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
04:56:40CarterItunes is telling me that my ipod is corrupted.
04:56:55CarterShould I just use manual drag n drop?
04:57:26cool_walking_You can, but you will only be able to play music copied with that method with Rockbox, not with the Apple firmware.
04:57:39CarterAlright.
05:00
05:01:58CarterIs there a certain folder that I must copy my music to?
05:02:38cool_walking_nope.
05:04:56cool_walking_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:51CIA-38New 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:52CIA-38New commit by 03unhelpful (r20872): Fix red.
06:00
06:19:12CIA-38New 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:00
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:00
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:12toffe82I have a strange thing on the battery bench file for the X, it start at 02:49:17
08:19:39toffe82and 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:45paulk_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:04paulk_no ?
08:36:51paulk_ok, i'll try by another way, bye !
08:37:01 Quit paulk_ ("Ex-Chat")
08:37:02Bagderpatience...
08:37:03GodEaterpaulk_: there is a bug in ubuntu's HAL layer which marks the sansa as an MTP device
08:37:05GodEaterhave some patience!
08:37:08GodEaterjesus
08:37:32GodEatermorning everybody ;)
08:37:47 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl)
08:38:03Bagdermorning!
08:40:31JdGordonarg, 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:00
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:39CIA-38New 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:29Bagderthe missing compiler in the PATH was a bonus! ;-)
09:43:43GodEateryes
09:43:57GodEaterI think perhaps another screen cast showing how easy it is to build the cross compilers would be good
09:43:58LloreanVideos 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:22Bagderyeah, building cross-compilers and setup PATH etc is a good idea
09:44:26GodEaterthe commentary on the error could have been better "the path is there but it's not in the path"
09:44:46GodEaterwouldn't make a whole lot of sense if you didn't already know what you were talking about :)
09:44:46linuxstbOgg Tremor?
09:44:47Bagderindeed, I thought that as well when I heard myself afterwards...
09:44:58GodEaterbut on the whole - I liked it :)
09:45:10Bagderoh
09:45:11GodEaterTheora presumably ;)
09:45:14Bagderright
09:45:21GodEatertoo many "T" words
09:45:39LloreanI 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:45Bagderif you come up with specific ideas I could try doing a few
09:47:02Bagdernot that I have the best voice but...
09:47:18GodEateryou'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:26Bagderhehe, yeah I was a little worried in general what things that could possible get revealed in all this
09:48:38Bagderlike the quick view of some urls in my browser history
09:48:51GodEaterwell at least you didn't dive into the "Forums admin" bit and open up the "users we hate" thread :)
09:49:01GodEateryouporn / redtube ? :)
09:49:07BagderI'll add that as a separate idea ;-)
09:49:26Bagder"video: this is how we deal with annoying users"
09:49:58GodEaterhahaha
09:50:40GodEaterI wonder what other videos we should do ?
09:50:50GodEater"Idiot's guide to RBUtil" ?
09:51:08LloreanA guide to rbutil might actually be pretty useful
09:51:22Bagderindeed
09:51:36BagderI don't think I'm the most suitable person for that though
09:51:41LloreanSpecifically, 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:36cool_walking_You'll eventually need docs on how to watch the videos...
09:53:13GodEaterwhy ?
09:53:35cool_walking_A video detailing how to use RbUtil?
09:54:17GodEateryes....
09:55:04cool_walking_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:24Bagderif the easy fails, give them the harder way?
09:56:17cool_walking_What's the difference between instructions saying "click here" and instructions saying "type this here"?
09:56:35Bagderpeople are scared of command lines and text mode
09:56:49Bagderthat's one big diff
10:00
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:11mt-linuxstb : ping
10:41:15 Part Srit
10:42:23***Saving seen data "./dancer.seen"
10:42:25GodEatermt-: it's worth asking whatever it is you want to know anyway
10:42:31GodEatereven if linuxstb isn't currently here
10:42:40GodEaterit's possible someone else might know :)
10:43:39mt-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:02GodEaterwell 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:00
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:32kugelUnhelpful: wouldn't it be faster to read/write an int at a time, not a char (in getc/putc)?
11:59:52Unhelpfulkugel: would it? a *whole* lot of the data is bit- or byte-oriented.
12:00
12:01:04kugelI'm not sure, but using the native data type is generally faster
12:01:29kugelif you're reading many chars in a loop, reading ints will most likely be faster
12:01:32Unhelpful"native" being 32-bit? there are pretty much none of those.
12:01:47Unhelpfulfaster, even if i want chars?
12:02:49kugelwhy should you want chars?
12:03:30kugelour strcmp and strcpy read/write 32bit at a time too in their fast versions
12:03:40Unhelpfulbecause of the amount of the data that *is* chars.
12:04:34Unhelpfulthe 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:41kugelI haven't looked at the jpeg code much, but - if possible - reading native should be preferred
12:05:34Unhelpfuland 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:22Unhelpfulpretty 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:37kugelthe header is not the issue I'd think, that's neglible compared to the image data anyway, isn't it?
12:06:55kugelit 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:49kugelour fast strcmp reads longs at a time too
12:10:49 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de)
12:11:45Unhelpfulkugel: 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:59kugelI just asked, you probably know it better
12:14:20kugelI'm just saying that messing with chars is generally slower than using the native format
12:15:11Unhelpfuli understand, and the decoder uses larger types after the bitstream data has been unpacked and decoded -
12:15:55kugelafter that only scaling comes?
12:16:48Unhelpfulno, not only scaling. it's unpack -> dequantize -> IDCT -> scale
12:17:00kugelusing a 64bit buffer might still be faster
12:17:09Unhelpfulnext step is supporting direct-to-native output without using the scaler.
12:17:24kugeloh, I though "unpack -> dequantize -> IDCT" is part of decoding
12:18:49Unhelpfulbasically, 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:22Unhelpfulso, 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:33Unhelpfulalso, 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 <ID>
12:26:35mt-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:04Unhelpfulsome of the devs use git already :)
12:27:04markunmt-: you mean, if it would benefit them more than you?
12:27:24markunI use git, but haven't been much of a dev lately
12:28:27mt-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:17kugelUnhelpful: well, you could mask with some &-combo for that I'd think
12:30:18markunmt-: well, you can make them happy by committing often locally and then produce many diffs to be committed in svn
12:30:22Unhelpfuli seem to recall there was a bit-twiddling hack for detecting the presence of a 0 byte in larger value
12:31:17kugelthat's what done in strcmp
12:31:32 Nick mt- is now known as mt (n=MTee@41.233.143.197)
12:32:45mtmarkun : umm, still can't really see the difference between that and producing a diff using svn ?
12:33:05Unhelpfulyou'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:20markunmt: I guess not, as long as you make the diffs after every major change
12:34:19Unhelpfuli 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:19markunmt: 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:06markunbut just use svn if that works well enough :) The change to git will also cost you some time.
12:36:32Unhelpfuli 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:46kugelyes
12:38:11kugelor rather, if it finds a \0, handle the rest byte-wise
12:38:15mtsvn 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:02Unhelpfulthe 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:19Unhelpfulalso, 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:00
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:53mtafter 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:46peturanyone with a nano care to help http://forums.rockbox.org/index.php?topic=21113.0 ?
13:42:33LloreanLet me see if I can find my cable.
13:45:02pixelmaI 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:44pixelmanot 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:21pixelmaah, 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:48LloreanThere's definitely a problem with the screen.
13:52:03LloreanTap 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:39pixelmaone 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:00
14:01:22LloreanThe stop seems to happen on the release, or so it feels
14:06:02pixelmaI 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:35pixelmabutton_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:17MarcGuayGetting 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:01MarcGuayDo the buttons defined in ther NEXTLIST override the previous ones?
14:33:43 Join schrottplatz [0] (n=max@f053225125.adsl.alicedsl.de)
14:34:34pixelmaif I understand correctly then no, first one is important. But the actions are slightly different there
14:35:44pixelmaif 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:09GodEateris it possible to tell from the forum stats somewhere when the last time a thread was "read" is ?
14:50:35LloreanNot anywhere in the UI at least.
14:51:08GodEaterI was just wondering if the massively misnamed "simple guide to compiling" thread still needed to be sticky
14:52:17LloreanUnsticky it and find out. :)
14:52:39LloreanI 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:00GodEaterhahahahaha
14:56:03GodEaterunstickied
14:56:16GodEaterdropped down the forum straight away
14:56:29GodEaterconf. call - back later
14:57:42LambdaCalculus37Llorean: Should we resticky the thread, or do you really want to just retire it?
14:58:19LloreanLet it fall away
14:58:23LambdaCalculus37Okay.
14:58:30LloreanJust 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:00
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:34MarcGuayCould 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:09linuxstbMarcGuay: Can you post some more of your code? e.g. how are all those variables you're using defined?
15:33:47linuxstbThe filename thing can simply be rb->snprintf(str_buffer, sizeof(str_buffer), "%s/%s", drum_dir, arr_filenames[i]);
15:34:02evilnickCan someone move this forum thread to Plugins please? http://forums.rockbox.org/index.php?topic=21603.0
15:34:09MarcGuaylinuxstb: I've added the declarations to the same pastebin.
15:34:40linuxstbMarcGuay: No, they're here - http://pastebin.com/m38e93eab
15:34:59MarcGuayOh, didn't realize it gave it a new address...
15:37:09LambdaCalculus37evilnick: Sure thing.
15:37:31LambdaCalculus37Never mind, BigBambi beat me. :P
15:41:49linuxstbMarcGuay: 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:00evilnickDoes Rockbox ignore id3 tags in vorbis files? I assume that it does as they're non-standard
15:45:02MarcGuaylinuxstb: 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:34MarcGuayI was hoping I could reuse the same buffer so that the samples could be larger.
15:46:22linuxstbevilnick: Yes.
15:46:40linuxstbevilnick: s/non-standard/just plain wrong/
15:50:55evilnicklinuxstb: 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:38NSplitlindbohm.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:47NHeallindbohm.freenode.net irc.freenode.net
15:57:47NJoinpabs [0] (n=pabs@xor.pablotron.org)
15:58:41NJointrisiak [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:11Lloreanlinuxstb: 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
16:00:59linuxstbI can't remember it ever failing to play them - I thought Rockbox always skipped id3 tags.
16:01:44LloreanI thought it was one of the many ways Rockbox could get stuck on a file while displaying 0:00 length
16:02:12linuxstbHmm, seems it doesn't skip them. The FLAC parser does though (I wrote that...)
16:02:16evilnickIt 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:44linuxstbLooking 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:45NJoinBagder [241] (n=daniel@rockbox/developer/bagder)
16:10:12NJoinsoap [50] (n=soap@rockbox/staff/soap)
16:17:09 Join itcheg [0] (i=41d59de2@gateway/web/ajax/mibbit.com/x-aa1ecf7a2c3ee134)
16:20:12NJoinZambezi [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:00
17:02:16MarcGuayIf 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:51NSplitlindbohm.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:18domonokymaybe 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:17domonoky:-)
17:14:41MarcGuayIt's the deal of a lifetime.
17:15:28MarcGuaydomonoky: read() returns a length?
17:15:45domonokyyes, the length it was able to read.
17:16:08MarcGuay... and I hate to ask a simple C question but to cast that int to a string so i can splash it?
17:16:16domonokyalso, your current code will probably break, if one of those 5 raw files are smaller then your buffer.
17:16:16MarcGuay(char*)int?
17:17:00MarcGuaywould it make more sense to say rb->read(raw_file, wavbuf5, sizeof(raw_file));?
17:17:11domonokyno, for splash you want a string. so use snprintf() to convert into a seperate buffer, and display it.
17:17:27MarcGuayokay
17:17:31MarcGuaythe love is coming, don't worry
17:17:43MarcGuay:)
17:18:19domonokyand 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:43domonokyanother 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:39MarcGuaydomonoky: Ideally I'd like that to be a single buffer that gets flushed and refilled whenever a button is pressed.
17:22:00MarcGuayBut that was crashing so I'm trying to get back to where I was yesterday before I fudged it all up.
17:22:22domonoky:-)
17:23:30*gevaerts 's ipod dock seems to work nearly perfectly with rockbox :)
17:23:46domonokyfor 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:49saratogaMT: 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:15saratogainitially a good goal might be to simply get decoding working, then work on seperating all of the rm components cleanly from cook
17:24:29saratogathough i think you have the right idea using seperate librm and libcook folders from the start :)
17:24:39gevaertsit only supports pausing though...
17:25:03mtsaratoga : 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:10MarcGuaydomonoky: 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:37saratogai 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:10toffe82the 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:05domonokyMarcGuay: strange. but maybe you get problems with the available plugin space. your buffers are pretty big.
17:32:33mtsaratoga : moment of enlightment :) (they're separate now btw)
17:33:13MarcGuaydomonoky: I was getting errors before because of that but found around where I have them works fine...
17:34:38saratogaMT: 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:01saratogathis way people could more easily port them to other programs, and of course we'd have a much easier time testing
17:35:12domonokyMarcGuay: 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:12MarcGuaydomonoky: 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:53mtsaratoga : 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:58domonokyMarcGuay: 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:10saratogaMT: 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:26saratogaby wrapping the codec interface calls to go to fopen, fseek, etc
17:42:50saratogaright now most codecs don't have their own test programs, so we can't test them except in the sim
17:44:06mtah ok
17:47:10NHeallindbohm.freenode.net irc.freenode.net
17:47:10NJoinZambezi [0] (i=Zulu@bnc.dotbnc.se)
17:51:06linuxstbsaratoga: 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:06linuxstbalready exist.
17:51:50saratogalinuxstb: t hose could be added to the rockbox decoders and enabled for test via the preprocessor pretty easily i think
17:52:01saratogathough maybe its worth keeping those test programs anyway
17:52:38mtlinuxstb : did you see the patches ?
17:53:20linuxstbmt: 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:16linuxstbmt: 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:50mtlinuxstb : Didn't write that for the patches :( , I thought it was only needed for the final one.
17:58:25mtbtw, cook.c would have different revisions across patches 1 and 2.
17:58:39linuxstbHmm, why?
17:59:08linuxstbDoes that mean parts of the code are from a newer ffmpeg than cook.c ?
18:00
18:01:45mtcurrently 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:27linuxstbOK. This is why I wanted those separate patches - to keep track of this stuff ;)
18:04:13mtyou mean the README's ? :)
18:04:46linuxstbYes, those as well.. ;)
18:05:14linuxstbBut maybe just add three READMEs as a separate comment to that task.
18:05:47linuxstbWhich ffmpeg revision was the first patch from?
18:05:50mtok .. though I feel the task is starting to look a bit messy :/
18:06:12linuxstbWell, hopefully we can close it soon...
18:06:32 Quit Zambezi (lindbohm.freenode.net irc.freenode.net)
18:06:32NSplitlindbohm.freenode.net irc.freenode.net
18:06:43linuxstbTrying to compile your first patch, I get lots of warnings in rm2wav.c (as well as other files).
18:06:52mtr18077
18:07:53mtyes .. 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:16mtsome of the warnings were fixed in patch 3 though
18:08:20linuxstbHmm, you shouldn't declare variables in .h files.
18:08:37linuxstbIt 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:45mtbut something like RMContext is used in cook.c, rm2wav.c and main.c
18:10:13mtalso 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:06linuxstbmt: 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:09linuxstbmt: 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:01mtI 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:04mtlinuxstb : which variables are you talking about ?
18:16:07linuxstbYes, I think it's OK when interfacing with existing code. So maybe those are OK.
18:16:28NHeallindbohm.freenode.net irc.freenode.net
18:16:28NJoinZambezi [0] (i=Zulu@bnc.dotbnc.se)
18:16:51linuxstbmt: 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:55mtlinuxstb : 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:03linuxstbmt: Then that's fine.
18:20:08mtI'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:56linuxstbmt: 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:22linuxstbBut I'm wondering why main() is in cook.c, and not rm2wav.c
18:21:29mtYes, in the 1st one main() was in cook.c
18:22:31mtlinuxstb : 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:31linuxstbCan you move it to rm2wav.c, as well as cleaning up the warnings in the first patch?
18:23:49taylor_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:16gevaertstaylor_: rockbox doesn't have the concept of user-mode applications
18:24:40taylor_Oh shoot, forgot, thanks. Better ask iPodLinux.
18:26:07mtlinuxstb : ok. But what is the benefit of that ? (cleaning up all the warnings in the first patch, and I'm just asking :) )
18:26:34linuxstbmt: Starting with clean foundations for later changes.
18:27:12linuxstbSo later changes only add new features, instead of cleaning up old code.
18:27:23mtWhy not clean the warnings for patch 3 instead ?
18:27:25linuxstbEspecially when it is brand new code (like rm2wav.c)
18:28:29linuxstbI just don't like committing code which isn't clean - warnings are bad.
18:29:04linuxstbBut 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:14mtAre patches 1 and 2 meant to be committed ?
18:30:16linuxstbIt'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:39linuxstbmt: Yes, I want to commit patch 1 first, then ask you to make a "patch 2" against what is in SVN.
18:31:10linuxstbI wouldn't have asked you to make the patches if they weren't going to be committed.
18:31:21linuxstb(I'm not that evil...)
18:31:35mtOh, didn't know that .. I thought they were just there to 'show history' . but ok, will work on them.
18:31:40mt:)
18:31:59 Quit SirFunk__ (Read error: 110 (Connection timed out))
18:32:41linuxstbYes, 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:07mtOK .. 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:25linuxstbSomething 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:03Jaykaywhat was the problem about http://www.rockbox.org/tracker/task/8778 ?
18:36:13Jaykaythe "serious issues"is annoying :)
18:36:20 Join kugel [0] (i=kugel@rockbox/developer/kugel)
18:38:19mtlinuxstb : uh oh, I think I'll have to replace a few files back from ffmpeg and re-edit them :)
18:40:02linuxstbWhat was the reason for changing from random.[ch] to lfg.[ch] ?
18:40:31mtffmpeg declared av_random deprecated
18:40:42mtand the warning mentioned using lfg instead
18:41:55linuxstbRockbox has its own PRNG, so maybe the real codec can use that, if needed?
18:42:29***Saving seen data "./dancer.seen"
18:43:25mtin 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:56linuxstbSo 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:29mtI 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:09MarcGuaydomonoky: Thanks for your help, the 2d array is much nicer! :) http://www.rockbox.org/tracker/task/10192
18:51:24saratogalinuxstb: are you thinking that the fixed point cook codec might be resynced to ffmpeg eventually?
18:53:38linuxstbsaratoga: 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:31linuxstbI'm assuming there are reasons the existing patches haven't been committed to ffmpeg...
18:55:56mtAlso 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:56saratogalinuxstb: then is it very important for us to stay close to ffmpeg's variables and whitespace?
19:00
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:46saratogaMT: 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:58mtlinuxstb : 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:30linuxstbsaratoga: It's important in order to see what functional changes have been made.
19:04:44linuxstbThe same reason we don't mix whitespace changes with normal Rockbox commits.
19:04:45saratogadoesn't the original patch against ffmpeg handle that?
19:05:10linuxstbI simply don't want to commit unnecessary changes.
19:05:31saratogai'd like to see all the ffmpeg baggage removed even if the codec ends up quite different from the original ffmpeg one
19:06:01linuxstbSure, but that's for later, not step 1.
19:06:33saratogaperhaps but I don't think its important to go out of our way to avoid changing things at this step either
19:07:38saratogai 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:43linuxstbI see it as the opposite, don't make changes you don't need to.
19:09:52mtbut 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:00linuxstbI 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:58mtwhen 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:06mtlinuxstb : no warnings for rm2wav now (they were all about unused/uninitialized variables).
19:17:14 Part seik
19:18:08linuxstbmt: I would probably use memset() for that - assuming it needs to be initialised.
19:19:01mtThere were warnings about it, that's why.
19:21:24linuxstbAre 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:34mtI was receiving warnings like this "warning: ‘obj.size’ may be used uninitialized in this .. "
19:24:55linuxstbMust be caused by a different gcc version, unless your code is different to libcook.patch1 ?
19:25:12linuxstbI'm using gcc 4.3.3
19:25:34mtI'm using 4.2.4
19:27:14mtcould you pastebin the warnings you're receiving ?
19:28:14 Join midijunkie [0] (n=Miranda@pD95477C2.dip0.t-ipconnect.de)
19:29:19linuxstbhttp://pastebin.ca/1416602 - that's an unmodified libcook.patch1
19:30:36mtI don't receive the warnings about (ignoring the return values for read/write)
19:31:06mtrest of the warnings are the same as I get without those related to real_object_t
19:31:18linuxstbIt's good practice to always check the return values of read/write for errors.
19:32:03linuxstbBut 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:50mtnow 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:44mtso 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:27mtlinuxstb : when compiling apps/codecs/libffmpegFLAC/main.c, you receive the same warnings about read/write ?
19:40:53linuxstbmt: I did that a long time ago... ;)
19:41:33linuxstbOlder versions of gcc didn't give that warning (as you are experiencing).
19:41:55mtSo some warnings could be ignored :)
19:43:04mtThe current rm2wav should give no warnings though..
19:43:20mt(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:56linuxstbmt: I'm just fixing the FLAC main.c now ;)
19:47:06mt" <linuxstb> In your face mt !" heh
19:52:43CIA-38New 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:46mtlinuxstb : Do you still have some time ? I'm just checking because I want to finish patch 1 tonight.
20:00
20:01:58linuxstbmt: Yes, I should be here all night.
20:02:23mtgreat. :)
20:04:03archivatorIs 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:10linuxstbarchivator: 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:43archivatorlinuxstb: 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:41linuxstbarchivator: 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:21MarcGuayIf 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:25mtlinuxstb : 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:02linuxstbMarcGuay: 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:16linuxstb(or implement such a mechanism...)
20:42:16 Part taylor_ ("Leaving")
20:42:33***Saving seen data "./dancer.seen"
20:42:40linuxstbmt: I think leaving main() in cook.c is fine for now - it's less intrusive.
20:42:50MarcGuaylinuxstb: Thank you.
20:43:45linuxstbMarcGuay: Although you can access Rockbox's normal playback code - i.e. add your file to a playlist and start playback.
20:44:00linuxstbBut I'm guessing that's not what you want?
20:44:43MarcGuaylinuxstb: 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:26CIA-38New 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:27pixelmaGodEater: any comments on the c200 keymap patch - as you volunteered for testing? (Llorean as well, I believe?)
20:59:18GodEaterI liked it - no issues
21:00
21:00:10BigBambipixelma: I know I say this everytime it is mentioned, but I think it should go in now :)
21:00:23GodEaterme 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:25mtlinuxstb : how is that for the readme ? http://pastebin.com/d5af4e013
21:15:56linuxstbmt: "flac.c" ?
21:16:22linuxstbAlso, you should state the SVN revision, not just the date (CVS doesn't have handy revision numbers)
21:17:06mtoops, missed that .. (flac.c)
21:17:37linuxstbI 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:48mtI've already removed them... the code didn't depend on them anyway.
21:19:08linuxstbSo 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:51CIA-38New commit by 03alex (r20877): Correct what happens when selecting Recording in the Main Menu in the manual. Fixes FS #9768
21:20:07mtsorry, by 'the code' I meant the code I modified back then when I was still working on the decoder.
21:21:12linuxstbAlso, your program shouldn't compile to "cooktest.o" - it should just be "cooktest".
21:21:24mtok
21:23:19mtare those all the comments ?
21:23:28linuxstbAnd you can remove "INC" from the Makefile.
21:24:31linuxstbYou 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:30mtlinuxstb : in rm2wav .. I believe I should add a (C) with your name too, but what should the year be, 2007 ?
21:28:33bertrikhow does the wps get it's data to display (progress, current song playing, etc.) Is there an easily identifiable interface for this?
21:29:14amiconnlinuxstb, MarcGuay: Or use the same mechanism as test_codec: provide the codec api from your plugin and load the codec from it
21:29:33pixelmaBigBambi: 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:43amiconnTo be precise, loadthe codec from within the plugin
21:29:59pixelmaBigBambi: those settings are now shown in the status bar I think
21:30:36linuxstbmt: 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:05BigBambipixelma: yes, and I didn't change that (in that order)
21:31:31linuxstbamiconn: Yes, I had forgotten about test_codec....
21:31:53pixelmaBigBambi: I guessed, but it drew my attention... something to "fix"
21:32:08 Quit HellDragon (Read error: 54 (Connection reset by peer))
21:32:29BigBambipixelma: I'll do it now
21:32:58linuxstbmt: Or if you're asking about my (C) line, then maybe just say "2008".
21:33:44pixelmaBigBambi: and about the newline - I though it was only \\ ?
21:34:01BigBambipixelma: \\ is a new line - \\* forces a blank line
21:34:26BigBambiI think it looks much easier to read with some spacing :)
21:34:42pixelmaah, hmm... first time I saw that used though
21:35:06BigBambiIt is in there a few times (prabably my previosu changes). According to to Google it is standard latex
21:35:25BigBambiAnd I do think it looks bad when everything is in one great big block of text with no white space
21:37:29BigBambipixelma: 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:04mtlinuxstb : now for the "diffing against ffmpeg" part :)
21:40:18mtare 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:50mtmy comments look a bit messy though I know :/
21:42:02pixelmaBigBambi: 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:12BigBambiOK, will do
21:43:04pixelmanice :)
21:43:11linuxstbmt: All of them... Hopefully there won't be much to fix.
21:43:26BigBambipixelma: Then screen shots :/
21:43:34BigBambiI really hate producing screen shots
21:43:44BigBambiIt takes for fricking ever to build all the sims
21:45:06mtlinuxstb : I forgot to mention that bitstream was taken from saratoga's wma.
21:45:29pixelmauh, 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:53BigBambiyes
21:45:57linuxstbmt: I've just looked at current ffmpeg, and it seems they are up to 18773 - your copy was from 18077?
21:46:00BigBambiI'm going to ignore that for now
21:46:25saratogaMT: for the static memory changes?
21:46:44linuxstbmt: r18079 removed the use of avrandom() in cook.c...
21:47:28mtlinuxstb : I got the revision from version.h in ffmpeg dir.
21:48:54mtsaratoga : 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:56mtThis should go to the readme.
21:50:15 Join SirFunk_ [0] (n=Sir@208.15.25.145)
21:50:26CIA-38New commit by 03alex (r20878): Correct location of frequency, quality and channel settings display, and change opts.
21:51:52linuxstbmt: If you update your code to r18079, you don't have to worry about the use of av_random.
21:52:33saratogaeventually 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:26mtlinuxstb : I don't think it's that important really.
21:54:31mtsaratoga : I think starting from patch 3 cook could use the same bitstream files as wma
21:55:10mtI'll include this in a later patch. (the one which should include separate rm/cook dirs)
21:55:44saratogasure, jsut somethnig to keep in mind
21:55:46linuxstbmt: 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:40mtlinuxstb : sorry, what are you referring to by 'it' ? (I'm a bit tired now :) )
21:57:22linuxstbmt: 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: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:00amblinwhat's currently the best supported non-hd platform/player?
22:02:34evilnickBest is quite subjective. What qualities are you looking for in particular?
22:02:55amblinstability and battery life
22:03:09BigBambie200 or c200 or nano
22:03:19amblinnano really?
22:03:24BigBambimake install
22:03:26BigBambidammit
22:03:29amblinhah
22:03:34saratogathe e200s are quite mature these days
22:03:49amblinim nearly 100% ogg, if that matters I know battery life wasn't so good on ipods
22:03:52BigBambiamblin: It isn't bad from what I hear, but I don't have any experience of it myself
22:04:31evilnickIf you're after battery life then you might want to choose a less cpu-intensive codec
22:04:34BigBambiamblin: 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:52mtlinuxstb : 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:19evilnickamblin: Personally, I can hardly ever hear the electrical noise, unless I am listening at rather quiet volumes
22:05:24saratogaevilnick: 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:46saratogathe sansa noise probably mainly happens with 16 ohm headphones and IEMs for what its worth
22:06:16amblini like ogg for other reasons, but that isn't a discussion for this channel :-)
22:06:23evilnickamblin: Apologies for the misinformation about vorbis.
22:06:43 Quit SirFunk_ (Read error: 145 (Connection timed out))
22:06:53amblinso any e2** series?
22:07:07BigBambiyes, but v1 only
22:07:10evilnicksaratoga: Is that an ARM-related thing? I could have sworn that vorbis was significantly more difficult to decode
22:07:25Jaykayamblin: v1 is rare and expensive, v2 isn't supported
22:07:29BigBambiamblin: And you can only tell for sure if it is v1 by looking at the original firmware version
22:07:37BigBambiJaykay: not so much
22:07:44BigBambiJaykay: It is just difficult to tell
22:07:47ChexJaykay: tigerdirect.ca still sells v1 e280s
22:07:49amblinok let me rephrase, best suppored and available to buy
22:07:53ChexI just bought one a month ago
22:08:12BigBambiamblin: No supported targets are still available new
22:08:20amblinah
22:08:38amblinthat isn't a good situation sniff
22:09:20linuxstbmt: 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:44Jaykaywtf? 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:13mtOK .. will do that.
22:10:41 Quit calman__ (Client Quit)
22:10:47saratogaevilnick: I've heard people say that, but Vorbis isn't much different then most other lossy codecs
22:10:56saratogai think its actually a little less cpu intensive then mp3 for instance
22:10:56Jaykaychex: are both e280 there v1?
22:11:06amblinjaykay where?
22:11:16Jaykaytigerdirect.com
22:12:05 Quit calman_ (Read error: 104 (Connection reset by peer))
22:12:10Jaykayamblin: if you can make sure they're v1 buy them
22:12:17Jaykay(on of them :) )
22:12:17 Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-2116087ca5f779ca)
22:12:21Jaykayone...
22:13:48ChexJaykay: Im pretty sure, the one I ordered was
22:16:33pixelmaBigBambi: the c200 suffers the same issue re. electrical noise
22:17:00BigBambipixelma: OK, that's good to know - I haven't used my c200 enough to notice :)
22:17:59amblinwhat's the outlook for rockbox on new hardware in the future?
22:18:58pixelmawell, 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:53amblinare sansa devices sans rockbox, mass storage?
22:28:39 Quit Sedgewick (Connection timed out)
22:30:31linuxstbamblin: Yes, you can select mass-storage or MTP.
22:35:43amblinthanks 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:46mtlinuxstb : I think I could create the patch now. Do you want to check on anything before I create it ?
22:44:27linuxstbmt: 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:55mtlinuxstb : pastebin ?
22:45:09 Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37)
22:45:15linuxstbYes, 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:37CIA-38New 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:49mtlinuxstb : 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:59BigBambihmmm, I seem to have added keywords to those files by mistake. Does this matter, and if so, how to I remove them?
22:52:17linuxstbmt: Just use pastebin then.
22:56:55 Join Strife89 [0] (n=michael@204.116.244.200)
23:00
23:00:56mtlinuxstb : 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:00linuxstbmt: 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:01mtlinuxstb : which do you prefer of the both ? I don't have a particular preference.
23:05:59linuxstbBigBambi: 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:03amiconnsaratoga: 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:12linuxstbmt: Email
23:06:15BigBambilinuxstb: OK, thanks
23:06:18 Join MarcGuay_ [0] (n=chatzill@ip216-239-68-5.vif.net)
23:06:47amiconnNot sure how it compares today; I only have two albums in vorbis
23:08:12CIA-38New 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:18linuxstbmt: Patch received - I've put it here: linuxstb.cream.org/rockbox/libcook.patch1">http://linuxstb.cream.org/rockbox/libcook.patch1
23:22:22CIA-38New 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:02mtlinuxstb : ok. thanks.
23:25:03linuxstbmt: 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:28mtlinuxstb : 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:54linuxstbmt: 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:21mtgreat, 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:24BigBambiWhen 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:52BigBambiand 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:40linuxstbmt: 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")

Previous day | Next day