| 00:00:30 | JdGordon| | 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 | JdGordon| | it shoudlnt ever be more than that |
| 00:01:04 | kugel | constantly redrawn sounds horrid :/ |
| 00:01:29 | JdGordon| | replace todays statusbar with a wps and you have what im takling about |
| 00:08:59 | | Quit bertrik ("Leaving") |
| 00:17:00 | amiconn | 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 | amiconn | Change the latter and the update problem will start appearing on mono and vertically-packed greyscale targets |
| 00:18:49 | JdGordon| | we are talking about what? 1px error lines? |
| 00:19:27 | JdGordon| | or up to 8 even? |
| 00:19:47 | JdGordon| | 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 | amiconn | Up to 7 pixels |
| 00:22:32 | amiconn | That is, up to 8 in total at horizontal boundaries; up to 7 pixels into either viewport |
| 00:23:13 | amiconn | 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 | dfkt | are there any plans of implementing FFWD/REW with audio in rockbox? |
| 00:35:49 | BigBambi | nobody is working on it AFAIK |
| 00:36:35 | JdGordon| | its pretty much a nodo isnt it? |
| 00:36:41 | dfkt | i was looking around but didn't find any mentioning of it at all |
| 00:36:46 | dfkt | nodo? |
| 00:37:20 | BigBambi | JdGordon|: Not that I'm aware of |
| 00:37:24 | scorche|sh | something that wont be done/acceptable out of principle |
| 00:37:38 | BigBambi | I was under the impression that it is a pretty massive job |
| 00:37:47 | BigBambi | And nobody had attempted it |
| 00:37:57 | BigBambi | But I've not seen it as a NODO anywhere |
| 00:37:59 | dfkt | massive job i understand, principle i don't understand :) |
| 00:39:55 | JdGordon| | the argument against it is that if you've already heard the part you wanted its too late... |
| 00:40:08 | JdGordon| | so there is no gain over just dionging it blindly |
| 00:40:26 | BigBambi | JdGordon|: But that doesn't make it a NODO |
| 00:40:40 | JdGordon| | unless you do it like my pvr thingy which rewinds 1 or 2 sec before playing again |
| 00:40:41 | dfkt | 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 | scorche|sh | i wouldnt say it is a NODO either...it could be handy |
| 00:41:20 | | Quit midijunkie ("?(???~•~)?") |
| 00:41:47 | JdGordon| | 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 | saratoga | theres a thread about it in the forums |
| 00:42:09 | saratoga | 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 | JdGordon| | the beast could do it! |
| 00:42:38 | saratoga | 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 | dfkt | all cowons |
| 00:42:53 | dfkt | including the ancient x5 |
| 00:43:02 | saratoga | even the X5 or just the newer ones? |
| 00:43:10 | dfkt | x5, d2, s9, etc |
| 00:43:10 | saratoga | the new ones have quite fast CPUs |
| 00:43:17 | dfkt | but yes, x5 too |
| 00:43:19 | scorche|sh | the archos did it too, but.. |
| 00:43:24 | scorche|sh | archoses |
| 00:43:29 | JdGordon| | 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 | saratoga | do they speed it up or just play short clips as you go |
| 00:44:04 | exposure101 | im not seeing much info about the Gen 6 ipod, will it even install? |
| 00:44:18 | scorche|sh | the latter, i would assume |
| 00:44:21 | dfkt | saratoga, sounds the same as cd player FFWD |
| 00:44:29 | dfkt | chopped up bits |
| 00:44:36 | dfkt | but no speeding up |
| 00:44:40 | saratoga | that makes sense |
| 00:44:47 | saratoga | can they do it for Vorbis as well as MP3? |
| 00:44:51 | dfkt | yes |
| 00:44:53 | exposure101 | hows everyone? |
| 00:45:02 | saratoga | hmm so thats pretty good then |
| 00:45:12 | dfkt | flac too, iirc |
| 00:45:20 | saratoga | they either have a lot of really fast codecs or maybe its not as slow as i'd think |
| 00:45:43 | scorche|sh | 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 | saratoga | i guess it could be faked by issuing a lot of seek requests in sucession |
| 00:46:31 | scorche|sh | only thing i can find in the tracker about it: http://www.rockbox.org/tracker/task/1403 |
| 00:46:37 | dfkt | well, any hint on where you are while FFWDing is helpful |
| 00:46:41 | saratoga | most of the codecs return less then 100ms worth of audio at a time |
| 00:46:48 | exposure101 | thx scorche|sh |
| 00:47:00 | saratoga | so i guess request 200ms, then skip ahead a few seconds and so on |
| 00:47:00 | BigBambi | saratoga: the H100 OF did it too |
| 00:47:09 | saratoga | 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 |
| 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 | kugel | so |
| 01:18:53 | | Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) |
| 01:19:11 | kugel | 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 | JdGordon | kugel: ? 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:37 | CIA-38 | New commit by kugel (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 | froggyman | 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 | froggyman | 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 | kugel | 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 | kugel | 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 | kugel | it's just that it cannot be done with ticks == 0. We could of course think about removing that possibility altogether |
| 02:35:40 | Unhelpful | ticks == 0 can actually be useful, though - for example, for peppering code that hangs with splashf's ;) |
| 02:37:09 | kugel | 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 | kugel | weird binsize distribution |
| 02:46:04 | JdGordon | kugel: because you still have the same problem with the screen not getting redrawn under it |
| 02:46:40 | froggyman | anybody know why i am getting this codec failure? its seems to happen fairly frequently, too |
| 02:47:12 | JdGordon | 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 | froggyman | a couple of days ago (so it is quite recent) |
| 02:48:36 | froggyman | didnt add any patches to it, just got the pre-compiled build |
| 02:48:55 | kugel | 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 | kugel | also, that would solve issues with multiple splashes |
| 02:52:05 | kugel | 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: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:20 | Carter | Anyone else encountering errors running rockbox on 5g ipod |
| 04:31:58 | krazykit | what kind of errors? |
| 04:33:19 | Carter | I cannot run rockbox.ipod for some reason |
| 04:34:12 | cool_walking_ | What is the exact error? |
| 04:34:35 | Carter | Cannot run rockbox.ipod |
| 04:37:42 | Carter | 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 | cool_walking_ | Are you sure it isn't "Can't load rockbox.ipod: <something>"? |
| 04:41:16 | Carter | I think that is what it is |
| 04:41:45 | Unhelpful | 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 | Carter | Just reinstalled, it runs now. Thanks though, it's nice that you guys have a medium of support for your users |
| 04:46:12 | Carter | Also, can I sync with Itunes or do I have to manually drag n drop? |
| 04:46:47 | krazykit | either one |
| 04:46:57 | cool_walking_ | iTunes munts the filenames, so if you want to usefully use iTunes, you'll need to use Rockbox's database feature. |
| 04:47:30 | Carter | Alright where is that |
| 04:47:52 | cool_walking_ | It's in the manual. |
| 04:48:01 | cool_walking_ | http://rockbox.org/manual.shtml |
| 04:48:24 | Carter | Thank you. |
| 04:49:20 | | Join ved_ [0] (n=ved2@137-mi2-1.acn.waw.pl) |
| 04:49:34 | cool_walking_ | Section 4. Browsing and playing |
| 04:49:47 | | Quit vedlith (Read error: 104 (Connection reset by peer)) |
| 04:54:28 | cool_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:10 | Carter | Alright. |
| 04:56:10 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 04:56:40 | Carter | Itunes is telling me that my ipod is corrupted. |
| 04:56:55 | Carter | Should I just use manual drag n drop? |
| 04:57:26 | cool_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:39 | Carter | Alright. |
| 05:00 |
| 05:01:58 | Carter | Is there a certain folder that I must copy my music to? |
| 05:02:38 | cool_walking_ | nope. |
| 05:04:56 | cool_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:51 | CIA-38 | New commit by unhelpful (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 | CIA-38 | New commit by unhelpful (r20872): Fix red. |
| 06:00 |
| 06:19:12 | CIA-38 | New commit by unhelpful (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:12 | toffe82 | I have a strange thing on the battery bench file for the X, it start at 02:49:17 |
| 08:19:39 | toffe82 | 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 | paulk_ | 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 | paulk_ | no ? |
| 08:36:51 | paulk_ | ok, i'll try by another way, bye ! |
| 08:37:01 | | Quit paulk_ ("Ex-Chat") |
| 08:37:02 | Bagder | patience... |
| 08:37:03 | GodEater | paulk_: there is a bug in ubuntu's HAL layer which marks the sansa as an MTP device |
| 08:37:05 | GodEater | have some patience! |
| 08:37:08 | GodEater | jesus |
| 08:37:32 | GodEater | morning everybody ;) |
| 08:37:47 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 08:38:03 | Bagder | morning! |
| 08:40:31 | JdGordon | 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: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:39 | CIA-38 | New commit by unhelpful (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 | Bagder | the missing compiler in the PATH was a bonus! ;-) |
| 09:43:43 | GodEater | yes |
| 09:43:57 | GodEater | I think perhaps another screen cast showing how easy it is to build the cross compilers would be good |
| 09:43:58 | Llorean | 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 | Bagder | yeah, building cross-compilers and setup PATH etc is a good idea |
| 09:44:26 | GodEater | the commentary on the error could have been better "the path is there but it's not in the path" |
| 09:44:46 | GodEater | wouldn't make a whole lot of sense if you didn't already know what you were talking about :) |
| 09:44:46 | linuxstb | Ogg Tremor? |
| 09:44:47 | Bagder | indeed, I thought that as well when I heard myself afterwards... |
| 09:44:58 | GodEater | but on the whole - I liked it :) |
| 09:45:10 | Bagder | oh |
| 09:45:11 | GodEater | Theora presumably ;) |
| 09:45:14 | Bagder | right |
| 09:45:21 | GodEater | too many "T" words |
| 09:45:39 | Llorean | 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 | Bagder | if you come up with specific ideas I could try doing a few |
| 09:47:02 | Bagder | not that I have the best voice but... |
| 09:47:18 | GodEater | 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 | Bagder | hehe, yeah I was a little worried in general what things that could possible get revealed in all this |
| 09:48:38 | Bagder | like the quick view of some urls in my browser history |
| 09:48:51 | GodEater | well at least you didn't dive into the "Forums admin" bit and open up the "users we hate" thread :) |
| 09:49:01 | GodEater | youporn / redtube ? :) |
| 09:49:07 | Bagder | I'll add that as a separate idea ;-) |
| 09:49:26 | Bagder | "video: this is how we deal with annoying users" |
| 09:49:58 | GodEater | hahaha |
| 09:50:40 | GodEater | I wonder what other videos we should do ? |
| 09:50:50 | GodEater | "Idiot's guide to RBUtil" ? |
| 09:51:08 | Llorean | A guide to rbutil might actually be pretty useful |
| 09:51:22 | Bagder | indeed |
| 09:51:36 | Bagder | I don't think I'm the most suitable person for that though |
| 09:51:41 | Llorean | 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 | cool_walking_ | You'll eventually need docs on how to watch the videos... |
| 09:53:13 | GodEater | why ? |
| 09:53:35 | cool_walking_ | A video detailing how to use RbUtil? |
| 09:54:17 | GodEater | yes.... |
| 09:55:04 | cool_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:24 | Bagder | if the easy fails, give them the harder way? |
| 09:56:17 | cool_walking_ | What's the difference between instructions saying "click here" and instructions saying "type this here"? |
| 09:56:35 | Bagder | people are scared of command lines and text mode |
| 09:56:49 | Bagder | that'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:11 | mt- | linuxstb : ping |
| 10:41:15 | | Part Srit |
| 10:42:23 | *** | Saving seen data "./dancer.seen" |
| 10:42:25 | GodEater | mt-: it's worth asking whatever it is you want to know anyway |
| 10:42:31 | GodEater | even if linuxstb isn't currently here |
| 10:42:40 | GodEater | it's possible someone else might know :) |
| 10:43:39 | mt- | 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 | GodEater | 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: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:32 | kugel | Unhelpful: wouldn't it be faster to read/write an int at a time, not a char (in getc/putc)? |
| 11:59:52 | Unhelpful | kugel: would it? a *whole* lot of the data is bit- or byte-oriented. |
| 12:00 |
| 12:01:04 | kugel | I'm not sure, but using the native data type is generally faster |
| 12:01:29 | kugel | if you're reading many chars in a loop, reading ints will most likely be faster |
| 12:01:32 | Unhelpful | "native" being 32-bit? there are pretty much none of those. |
| 12:01:47 | Unhelpful | faster, even if i want chars? |
| 12:02:49 | kugel | why should you want chars? |
| 12:03:30 | kugel | our strcmp and strcpy read/write 32bit at a time too in their fast versions |
| 12:03:40 | Unhelpful | because of the amount of the data that *is* chars. |
| 12:04:34 | Unhelpful | 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 | kugel | I haven't looked at the jpeg code much, but - if possible - reading native should be preferred |
| 12:05:34 | Unhelpful | 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 | Unhelpful | 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 | kugel | the header is not the issue I'd think, that's neglible compared to the image data anyway, isn't it? |
| 12:06:55 | kugel | 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 | kugel | 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 | Unhelpful | 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 | kugel | I just asked, you probably know it better |
| 12:14:20 | kugel | I'm just saying that messing with chars is generally slower than using the native format |
| 12:15:11 | Unhelpful | i understand, and the decoder uses larger types after the bitstream data has been unpacked and decoded - |
| 12:15:55 | kugel | after that only scaling comes? |
| 12:16:48 | Unhelpful | no, not only scaling. it's unpack -> dequantize -> IDCT -> scale |
| 12:17:00 | kugel | using a 64bit buffer might still be faster |
| 12:17:09 | Unhelpful | next step is supporting direct-to-native output without using the scaler. |
| 12:17:24 | kugel | oh, I though "unpack -> dequantize -> IDCT" is part of decoding |
| 12:18:49 | Unhelpful | 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 | Unhelpful | 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 | Unhelpful | 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 <ID> |
| 12:26:35 | mt- | 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 | Unhelpful | some of the devs use git already :) |
| 12:27:04 | markun | mt-: you mean, if it would benefit them more than you? |
| 12:27:24 | markun | I use git, but haven't been much of a dev lately |
| 12:28:27 | mt- | 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 | kugel | Unhelpful: well, you could mask with some &-combo for that I'd think |
| 12:30:18 | markun | mt-: well, you can make them happy by committing often locally and then produce many diffs to be committed in svn |
| 12:30:22 | Unhelpful | i seem to recall there was a bit-twiddling hack for detecting the presence of a 0 byte in larger value |
| 12:31:17 | kugel | 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 | mt | markun : umm, still can't really see the difference between that and producing a diff using svn ? |
| 12:33:05 | Unhelpful | 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 | markun | mt: I guess not, as long as you make the diffs after every major change |
| 12:34:19 | Unhelpful | 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 | markun | 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 | markun | but just use svn if that works well enough :) The change to git will also cost you some time. |
| 12:36:32 | Unhelpful | 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 | kugel | yes |
| 12:38:11 | kugel | or rather, if it finds a \0, handle the rest byte-wise |
| 12:38:15 | mt | 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 | Unhelpful | 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 | Unhelpful | 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: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:53 | mt | 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 | petur | anyone with a nano care to help http://forums.rockbox.org/index.php?topic=21113.0 ? |
| 13:42:33 | Llorean | Let me see if I can find my cable. |
| 13:45:02 | pixelma | 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 | pixelma | 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 | pixelma | 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 | Llorean | There's definitely a problem with the screen. |
| 13:52:03 | Llorean | 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 | pixelma | 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:00 |
| 14:01:22 | Llorean | The stop seems to happen on the release, or so it feels |
| 14:06:02 | pixelma | 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 | pixelma | 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 | MarcGuay | 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 | MarcGuay | 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 | pixelma | if I understand correctly then no, first one is important. But the actions are slightly different there |
| 14:35:44 | pixelma | 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 | GodEater | is it possible to tell from the forum stats somewhere when the last time a thread was "read" is ? |
| 14:50:35 | Llorean | Not anywhere in the UI at least. |
| 14:51:08 | GodEater | I was just wondering if the massively misnamed "simple guide to compiling" thread still needed to be sticky |
| 14:52:17 | Llorean | Unsticky it and find out. :) |
| 14:52:39 | Llorean | 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 | GodEater | hahahahaha |
| 14:56:03 | GodEater | unstickied |
| 14:56:16 | GodEater | dropped down the forum straight away |
| 14:56:29 | GodEater | conf. call - back later |
| 14:57:42 | LambdaCalculus37 | Llorean: Should we resticky the thread, or do you really want to just retire it? |
| 14:58:19 | Llorean | Let it fall away |
| 14:58:23 | LambdaCalculus37 | Okay. |
| 14:58:30 | Llorean | 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: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:34 | MarcGuay | 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 | linuxstb | MarcGuay: Can you post some more of your code? e.g. how are all those variables you're using defined? |
| 15:33:47 | linuxstb | The filename thing can simply be rb->snprintf(str_buffer, sizeof(str_buffer), "%s/%s", drum_dir, arr_filenames[i]); |
| 15:34:02 | evilnick | Can someone move this forum thread to Plugins please? http://forums.rockbox.org/index.php?topic=21603.0 |
| 15:34:09 | MarcGuay | linuxstb: I've added the declarations to the same pastebin. |
| 15:34:40 | linuxstb | MarcGuay: No, they're here - http://pastebin.com/m38e93eab |
| 15:34:59 | MarcGuay | Oh, didn't realize it gave it a new address... |
| 15:37:09 | LambdaCalculus37 | evilnick: Sure thing. |
| 15:37:31 | LambdaCalculus37 | Never mind, BigBambi beat me. :P |
| 15:41:49 | linuxstb | 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 | evilnick | Does Rockbox ignore id3 tags in vorbis files? I assume that it does as they're non-standard |
| 15:45:02 | MarcGuay | 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 | MarcGuay | I was hoping I could reuse the same buffer so that the samples could be larger. |
| 15:46:22 | linuxstb | evilnick: Yes. |
| 15:46:40 | linuxstb | evilnick: s/non-standard/just plain wrong/ |
| 15:50:55 | evilnick | 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 | Llorean | 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 |
| 16:00:59 | linuxstb | I can't remember it ever failing to play them - I thought Rockbox always skipped id3 tags. |
| 16:01:44 | Llorean | I thought it was one of the many ways Rockbox could get stuck on a file while displaying 0:00 length |
| 16:02:12 | linuxstb | Hmm, seems it doesn't skip them. The FLAC parser does though (I wrote that...) |
| 16:02:16 | evilnick | 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 | linuxstb | 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:00 |
| 17:02:16 | MarcGuay | 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 | domonoky | 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 | domonoky | :-) |
| 17:14:41 | MarcGuay | It's the deal of a lifetime. |
| 17:15:28 | MarcGuay | domonoky: read() returns a length? |
| 17:15:45 | domonoky | yes, the length it was able to read. |
| 17:16:08 | MarcGuay | ... 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 | domonoky | also, your current code will probably break, if one of those 5 raw files are smaller then your buffer. |
| 17:16:16 | MarcGuay | (char*)int? |
| 17:17:00 | MarcGuay | would it make more sense to say rb->read(raw_file, wavbuf5, sizeof(raw_file));? |
| 17:17:11 | domonoky | no, for splash you want a string. so use snprintf() to convert into a seperate buffer, and display it. |
| 17:17:27 | MarcGuay | okay |
| 17:17:31 | MarcGuay | the love is coming, don't worry |
| 17:17:43 | MarcGuay | :) |
| 17:18:19 | domonoky | 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 | domonoky | 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 | MarcGuay | domonoky: Ideally I'd like that to be a single buffer that gets flushed and refilled whenever a button is pressed. |
| 17:22:00 | MarcGuay | 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 | domonoky | :-) |
| 17:23:30 | * | gevaerts 's ipod dock seems to work nearly perfectly with rockbox :) |
| 17:23:46 | domonoky | 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 | saratoga | 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 | saratoga | 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 | saratoga | though i think you have the right idea using seperate librm and libcook folders from the start :) |
| 17:24:39 | gevaerts | it only supports pausing though... |
| 17:25:03 | mt | 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 | MarcGuay | 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 | saratoga | 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 | toffe82 | 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 | domonoky | MarcGuay: strange. but maybe you get problems with the available plugin space. your buffers are pretty big. |
| 17:32:33 | mt | saratoga : moment of enlightment :) (they're separate now btw) |
| 17:33:13 | MarcGuay | domonoky: I was getting errors before because of that but found around where I have them works fine... |
| 17:34:38 | saratoga | 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 | saratoga | 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 | domonoky | 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 | MarcGuay | 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 | mt | 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 | domonoky | 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 | saratoga | 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 | saratoga | by wrapping the codec interface calls to go to fopen, fseek, etc |
| 17:42:50 | saratoga | right now most codecs don't have their own test programs, so we can't test them except in the sim |
| 17:44:06 | mt | 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 | linuxstb | 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 | linuxstb | already exist. |
| 17:51:50 | saratoga | linuxstb: t hose could be added to the rockbox decoders and enabled for test via the preprocessor pretty easily i think |
| 17:52:01 | saratoga | though maybe its worth keeping those test programs anyway |
| 17:52:38 | mt | linuxstb : did you see the patches ? |
| 17:53:20 | linuxstb | 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 | linuxstb | 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 | mt | linuxstb : Didn't write that for the patches :( , I thought it was only needed for the final one. |
| 17:58:25 | mt | btw, cook.c would have different revisions across patches 1 and 2. |
| 17:58:39 | linuxstb | Hmm, why? |
| 17:59:08 | linuxstb | Does that mean parts of the code are from a newer ffmpeg than cook.c ? |
| 18:00 |
| 18:01:45 | mt | 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 | linuxstb | OK. This is why I wanted those separate patches - to keep track of this stuff ;) |
| 18:04:13 | mt | you mean the README's ? :) |
| 18:04:46 | linuxstb | Yes, those as well.. ;) |
| 18:05:14 | linuxstb | But maybe just add three READMEs as a separate comment to that task. |
| 18:05:47 | linuxstb | Which ffmpeg revision was the first patch from? |
| 18:05:50 | mt | ok .. though I feel the task is starting to look a bit messy :/ |
| 18:06:12 | linuxstb | 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 | linuxstb | Trying to compile your first patch, I get lots of warnings in rm2wav.c (as well as other files). |
| 18:06:52 | mt | r18077 |
| 18:07:53 | mt | 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 | mt | some of the warnings were fixed in patch 3 though |
| 18:08:20 | linuxstb | Hmm, you shouldn't declare variables in .h files. |
| 18:08:37 | linuxstb | 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 | mt | but something like RMContext is used in cook.c, rm2wav.c and main.c |
| 18:10:13 | mt | 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 | linuxstb | 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 | linuxstb | 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 | mt | 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 | mt | linuxstb : which variables are you talking about ? |
| 18:16:07 | linuxstb | 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 | linuxstb | 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 | mt | 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 | linuxstb | mt: Then that's fine. |
| 18:20:08 | mt | 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 | linuxstb | 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 | linuxstb | But I'm wondering why main() is in cook.c, and not rm2wav.c |
| 18:21:29 | mt | Yes, in the 1st one main() was in cook.c |
| 18:22:31 | mt | 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 | linuxstb | Can you move it to rm2wav.c, as well as cleaning up the warnings in the first patch? |
| 18:23:49 | taylor_ | 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 | gevaerts | taylor_: rockbox doesn't have the concept of user-mode applications |
| 18:24:40 | taylor_ | Oh shoot, forgot, thanks. Better ask iPodLinux. |
| 18:26:07 | mt | 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 | linuxstb | mt: Starting with clean foundations for later changes. |
| 18:27:12 | linuxstb | So later changes only add new features, instead of cleaning up old code. |
| 18:27:23 | mt | Why not clean the warnings for patch 3 instead ? |
| 18:27:25 | linuxstb | Especially when it is brand new code (like rm2wav.c) |
| 18:28:29 | linuxstb | I just don't like committing code which isn't clean - warnings are bad. |
| 18:29:04 | linuxstb | 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 | mt | Are patches 1 and 2 meant to be committed ? |
| 18:30:16 | linuxstb | 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 | linuxstb | 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 | linuxstb | I wouldn't have asked you to make the patches if they weren't going to be committed. |
| 18:31:21 | linuxstb | (I'm not that evil...) |
| 18:31:35 | mt | Oh, didn't know that .. I thought they were just there to 'show history' . but ok, will work on them. |
| 18:31:40 | mt | :) |
| 18:31:59 | | Quit SirFunk__ (Read error: 110 (Connection timed out)) |
| 18:32:41 | linuxstb | 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 | mt | 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 | linuxstb | 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 | Jaykay | what was the problem about http://www.rockbox.org/tracker/task/8778 ? |
| 18:36:13 | Jaykay | the "serious issues"is annoying :) |
| 18:36:20 | | Join kugel [0] (i=kugel@rockbox/developer/kugel) |
| 18:38:19 | mt | linuxstb : uh oh, I think I'll have to replace a few files back from ffmpeg and re-edit them :) |
| 18:40:02 | linuxstb | What was the reason for changing from random.[ch] to lfg.[ch] ? |
| 18:40:31 | mt | ffmpeg declared av_random deprecated |
| 18:40:42 | mt | and the warning mentioned using lfg instead |
| 18:41:55 | linuxstb | 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 | mt | 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 | linuxstb | 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 | mt | 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 | MarcGuay | domonoky: Thanks for your help, the 2d array is much nicer! :) http://www.rockbox.org/tracker/task/10192 |
| 18:51:24 | saratoga | linuxstb: are you thinking that the fixed point cook codec might be resynced to ffmpeg eventually? |
| 18:53:38 | linuxstb | 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 | linuxstb | I'm assuming there are reasons the existing patches haven't been committed to ffmpeg... |
| 18:55:56 | mt | 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 | saratoga | linuxstb: 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:46 | saratoga | 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 | mt | 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 | linuxstb | saratoga: It's important in order to see what functional changes have been made. |
| 19:04:44 | linuxstb | The same reason we don't mix whitespace changes with normal Rockbox commits. |
| 19:04:45 | saratoga | doesn't the original patch against ffmpeg handle that? |
| 19:05:10 | linuxstb | I simply don't want to commit unnecessary changes. |
| 19:05:31 | saratoga | 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 | linuxstb | Sure, but that's for later, not step 1. |
| 19:06:33 | saratoga | 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 | saratoga | 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 | linuxstb | I see it as the opposite, don't make changes you don't need to. |
| 19:09:52 | mt | 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 | linuxstb | 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 | mt | 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 | mt | linuxstb : no warnings for rm2wav now (they were all about unused/uninitialized variables). |
| 19:17:14 | | Part seik |
| 19:18:08 | linuxstb | mt: I would probably use memset() for that - assuming it needs to be initialised. |
| 19:19:01 | mt | There were warnings about it, that's why. |
| 19:21:24 | linuxstb | 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 | mt | I was receiving warnings like this "warning: ‘obj.size’ may be used uninitialized in this .. " |
| 19:24:55 | linuxstb | Must be caused by a different gcc version, unless your code is different to libcook.patch1 ? |
| 19:25:12 | linuxstb | I'm using gcc 4.3.3 |
| 19:25:34 | mt | I'm using 4.2.4 |
| 19:27:14 | mt | could you pastebin the warnings you're receiving ? |
| 19:28:14 | | Join midijunkie [0] (n=Miranda@pD95477C2.dip0.t-ipconnect.de) |
| 19:29:19 | linuxstb | http://pastebin.ca/1416602 - that's an unmodified libcook.patch1 |
| 19:30:36 | mt | I don't receive the warnings about (ignoring the return values for read/write) |
| 19:31:06 | mt | rest of the warnings are the same as I get without those related to real_object_t |
| 19:31:18 | linuxstb | It's good practice to always check the return values of read/write for errors. |
| 19:32:03 | linuxstb | 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 | mt | 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 | mt | 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 | mt | linuxstb : when compiling apps/codecs/libffmpegFLAC/main.c, you receive the same warnings about read/write ? |
| 19:40:53 | linuxstb | mt: I did that a long time ago... ;) |
| 19:41:33 | linuxstb | Older versions of gcc didn't give that warning (as you are experiencing). |
| 19:41:55 | mt | So some warnings could be ignored :) |
| 19:43:04 | mt | The current rm2wav should give no warnings though.. |
| 19:43:20 | mt | (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 | linuxstb | mt: I'm just fixing the FLAC main.c now ;) |
| 19:47:06 | mt | " <linuxstb> In your face mt !" heh |
| 19:52:43 | CIA-38 | New commit by dave (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 | mt | linuxstb : Do you still have some time ? I'm just checking because I want to finish patch 1 tonight. |
| 20:00 |
| 20:01:58 | linuxstb | mt: Yes, I should be here all night. |
| 20:02:23 | mt | great. :) |
| 20:04:03 | archivator | 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 | linuxstb | 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 | archivator | 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 | linuxstb | 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 | MarcGuay | 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 | mt | 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 | linuxstb | 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 | linuxstb | (or implement such a mechanism...) |
| 20:42:16 | | Part taylor_ ("Leaving") |
| 20:42:33 | *** | Saving seen data "./dancer.seen" |
| 20:42:40 | linuxstb | mt: I think leaving main() in cook.c is fine for now - it's less intrusive. |
| 20:42:50 | MarcGuay | linuxstb: Thank you. |
| 20:43:45 | linuxstb | MarcGuay: Although you can access Rockbox's normal playback code - i.e. add your file to a playlist and start playback. |
| 20:44:00 | linuxstb | But I'm guessing that's not what you want? |
| 20:44:43 | MarcGuay | 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 | CIA-38 | New commit by alex (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 | pixelma | GodEater: any comments on the c200 keymap patch - as you volunteered for testing? (Llorean as well, I believe?) |
| 20:59:18 | GodEater | I liked it - no issues |
| 21:00 |
| 21:00:10 | BigBambi | pixelma: I know I say this everytime it is mentioned, but I think it should go in now :) |
| 21:00:23 | GodEater | 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 | mt | linuxstb : how is that for the readme ? http://pastebin.com/d5af4e013 |
| 21:15:56 | linuxstb | mt: "flac.c" ? |
| 21:16:22 | linuxstb | Also, you should state the SVN revision, not just the date (CVS doesn't have handy revision numbers) |
| 21:17:06 | mt | oops, missed that .. (flac.c) |
| 21:17:37 | linuxstb | 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 | mt | I've already removed them... the code didn't depend on them anyway. |
| 21:19:08 | linuxstb | 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 | CIA-38 | New commit by alex (r20877): Correct what happens when selecting Recording in the Main Menu in the manual. Fixes FS #9768 |
| 21:20:07 | mt | sorry, by 'the code' I meant the code I modified back then when I was still working on the decoder. |
| 21:21:12 | linuxstb | Also, your program shouldn't compile to "cooktest.o" - it should just be "cooktest". |
| 21:21:24 | mt | ok |
| 21:23:19 | mt | are those all the comments ? |
| 21:23:28 | linuxstb | And you can remove "INC" from the Makefile. |
| 21:24:31 | linuxstb | 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 | mt | linuxstb : in rm2wav .. I believe I should add a (C) with your name too, but what should the year be, 2007 ? |
| 21:28:33 | bertrik | 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 | amiconn | 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 | pixelma | 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 | amiconn | To be precise, loadthe codec from within the plugin |
| 21:29:59 | pixelma | BigBambi: those settings are now shown in the status bar I think |
| 21:30:36 | linuxstb | 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 | BigBambi | pixelma: yes, and I didn't change that (in that order) |
| 21:31:31 | linuxstb | amiconn: Yes, I had forgotten about test_codec.... |
| 21:31:53 | pixelma | 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 | BigBambi | pixelma: I'll do it now |
| 21:32:58 | linuxstb | mt: Or if you're asking about my (C) line, then maybe just say "2008". |
| 21:33:44 | pixelma | BigBambi: and about the newline - I though it was only \\ ? |
| 21:34:01 | BigBambi | pixelma: \\ is a new line - \\* forces a blank line |
| 21:34:26 | BigBambi | I think it looks much easier to read with some spacing :) |
| 21:34:42 | pixelma | ah, hmm... first time I saw that used though |
| 21:35:06 | BigBambi | It is in there a few times (prabably my previosu changes). According to to Google it is standard latex |
| 21:35:25 | BigBambi | And I do think it looks bad when everything is in one great big block of text with no white space |
| 21:37:29 | BigBambi | 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 | mt | linuxstb : now for the "diffing against ffmpeg" part :) |
| 21:40:18 | mt | 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 | mt | my comments look a bit messy though I know :/ |
| 21:42:02 | pixelma | 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 | BigBambi | OK, will do |
| 21:43:04 | pixelma | nice :) |
| 21:43:11 | linuxstb | mt: All of them... Hopefully there won't be much to fix. |
| 21:43:26 | BigBambi | pixelma: Then screen shots :/ |
| 21:43:34 | BigBambi | I really hate producing screen shots |
| 21:43:44 | BigBambi | It takes for fricking ever to build all the sims |
| 21:45:06 | mt | linuxstb : I forgot to mention that bitstream was taken from saratoga's wma. |
| 21:45:29 | pixelma | 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 | BigBambi | yes |
| 21:45:57 | linuxstb | mt: I've just looked at current ffmpeg, and it seems they are up to 18773 - your copy was from 18077? |
| 21:46:00 | BigBambi | I'm going to ignore that for now |
| 21:46:25 | saratoga | MT: for the static memory changes? |
| 21:46:44 | linuxstb | mt: r18079 removed the use of avrandom() in cook.c... |
| 21:47:28 | mt | linuxstb : I got the revision from version.h in ffmpeg dir. |
| 21:48:54 | mt | 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 | mt | This should go to the readme. |
| 21:50:15 | | Join SirFunk_ [0] (n=Sir@208.15.25.145) |
| 21:50:26 | CIA-38 | New commit by alex (r20878): Correct location of frequency, quality and channel settings display, and change opts. |
| 21:51:52 | linuxstb | mt: If you update your code to r18079, you don't have to worry about the use of av_random. |
| 21:52:33 | saratoga | 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 | mt | linuxstb : I don't think it's that important really. |
| 21:54:31 | mt | saratoga : I think starting from patch 3 cook could use the same bitstream files as wma |
| 21:55:10 | mt | I'll include this in a later patch. (the one which should include separate rm/cook dirs) |
| 21:55:44 | saratoga | sure, jsut somethnig to keep in mind |
| 21:55:46 | linuxstb | 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 | mt | linuxstb : sorry, what are you referring to by 'it' ? (I'm a bit tired now :) ) |
| 21:57:22 | linuxstb | 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: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 | amblin | what's currently the best supported non-hd platform/player? |
| 22:02:34 | evilnick | Best is quite subjective. What qualities are you looking for in particular? |
| 22:02:55 | amblin | stability and battery life |
| 22:03:09 | BigBambi | e200 or c200 or nano |
| 22:03:19 | amblin | nano really? |
| 22:03:24 | BigBambi | make install |
| 22:03:26 | BigBambi | dammit |
| 22:03:29 | amblin | hah |
| 22:03:34 | saratoga | the e200s are quite mature these days |
| 22:03:49 | amblin | im nearly 100% ogg, if that matters I know battery life wasn't so good on ipods |
| 22:03:52 | BigBambi | amblin: It isn't bad from what I hear, but I don't have any experience of it myself |
| 22:04:31 | evilnick | If you're after battery life then you might want to choose a less cpu-intensive codec |
| 22:04:34 | BigBambi | 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 | mt | 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 | evilnick | amblin: Personally, I can hardly ever hear the electrical noise, unless I am listening at rather quiet volumes |
| 22:05:24 | saratoga | 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 | saratoga | the sansa noise probably mainly happens with 16 ohm headphones and IEMs for what its worth |
| 22:06:16 | amblin | i like ogg for other reasons, but that isn't a discussion for this channel :-) |
| 22:06:23 | evilnick | amblin: Apologies for the misinformation about vorbis. |
| 22:06:43 | | Quit SirFunk_ (Read error: 145 (Connection timed out)) |
| 22:06:53 | amblin | so any e2** series? |
| 22:07:07 | BigBambi | yes, but v1 only |
| 22:07:10 | evilnick | saratoga: Is that an ARM-related thing? I could have sworn that vorbis was significantly more difficult to decode |
| 22:07:25 | Jaykay | amblin: v1 is rare and expensive, v2 isn't supported |
| 22:07:29 | BigBambi | amblin: And you can only tell for sure if it is v1 by looking at the original firmware version |
| 22:07:37 | BigBambi | Jaykay: not so much |
| 22:07:44 | BigBambi | Jaykay: It is just difficult to tell |
| 22:07:47 | Chex | Jaykay: tigerdirect.ca still sells v1 e280s |
| 22:07:49 | amblin | ok let me rephrase, best suppored and available to buy |
| 22:07:53 | Chex | I just bought one a month ago |
| 22:08:12 | BigBambi | amblin: No supported targets are still available new |
| 22:08:20 | amblin | ah |
| 22:08:38 | amblin | that isn't a good situation sniff |
| 22:09:20 | linuxstb | 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 | Jaykay | 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 | mt | OK .. will do that. |
| 22:10:41 | | Quit calman__ (Client Quit) |
| 22:10:47 | saratoga | evilnick: I've heard people say that, but Vorbis isn't much different then most other lossy codecs |
| 22:10:56 | saratoga | i think its actually a little less cpu intensive then mp3 for instance |
| 22:10:56 | Jaykay | chex: are both e280 there v1? |
| 22:11:06 | amblin | jaykay where? |
| 22:11:16 | Jaykay | tigerdirect.com |
| 22:12:05 | | Quit calman_ (Read error: 104 (Connection reset by peer)) |
| 22:12:10 | Jaykay | amblin: if you can make sure they're v1 buy them |
| 22:12:17 | Jaykay | (on of them :) ) |
| 22:12:17 | | Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-2116087ca5f779ca) |
| 22:12:21 | Jaykay | one... |
| 22:13:48 | Chex | Jaykay: Im pretty sure, the one I ordered was |
| 22:16:33 | pixelma | BigBambi: the c200 suffers the same issue re. electrical noise |
| 22:17:00 | BigBambi | pixelma: OK, that's good to know - I haven't used my c200 enough to notice :) |
| 22:17:59 | amblin | what's the outlook for rockbox on new hardware in the future? |
| 22:18:58 | pixelma | 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 | amblin | are sansa devices sans rockbox, mass storage? |
| 22:28:39 | | Quit Sedgewick (Connection timed out) |
| 22:30:31 | linuxstb | amblin: Yes, you can select mass-storage or MTP. |
| 22:35:43 | amblin | 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 | mt | linuxstb : I think I could create the patch now. Do you want to check on anything before I create it ? |
| 22:44:27 | linuxstb | 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 | mt | linuxstb : pastebin ? |
| 22:45:09 | | Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) |
| 22:45:15 | linuxstb | 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 | CIA-38 | New commit by alex (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 | mt | 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 | BigBambi | 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 | linuxstb | mt: Just use pastebin then. |
| 22:56:55 | | Join Strife89 [0] (n=michael@204.116.244.200) |
| 23:00 |
| 23:00:56 | mt | 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 | linuxstb | 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 | mt | linuxstb : which do you prefer of the both ? I don't have a particular preference. |
| 23:05:59 | linuxstb | 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 | amiconn | 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 | linuxstb | mt: Email |
| 23:06:15 | BigBambi | linuxstb: OK, thanks |
| 23:06:18 | | Join MarcGuay_ [0] (n=chatzill@ip216-239-68-5.vif.net) |
| 23:06:47 | amiconn | Not sure how it compares today; I only have two albums in vorbis |
| 23:08:12 | CIA-38 | New commit by alex (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 | linuxstb | mt: Patch received - I've put it here: linuxstb.cream.org/rockbox/libcook.patch1">http://linuxstb.cream.org/rockbox/libcook.patch1 |
| 23:22:22 | CIA-38 | New commit by alex (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 | mt | linuxstb : ok. thanks. |
| 23:25:03 | linuxstb | 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 | mt | 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 | linuxstb | 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 | mt | 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 | BigBambi | 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 | BigBambi | 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 | linuxstb | 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") |
icon identifies that the person is a core developer (has commit access).