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 2010-09-28

00:02:04 Quit bmbl (Quit: Bye!)
00:05:29 Quit anewuser (Ping timeout: 264 seconds)
00:09:40 Join Topy44 [0] (~Topy44@e179096164.adsl.alicedsl.de)
00:13:41 Quit Staphylo (Quit: Bye les gens =))
00:17:00 Join leachim6 [0] (~leachim6@rrcs-97-78-139-149.se.biz.rr.com)
00:17:15 Join krabador [0] (~krabador@host73-20-dynamic.251-95-r.retail.telecomitalia.it)
00:17:26 Nick leachim6 is now known as Guest54663 (~leachim6@rrcs-97-78-139-149.se.biz.rr.com)
00:24:40 Quit ender` (Quit: That men do not learn very much from the lessons of history is the most important of all the lessons of history.-- Aldous Huxley)
00:27:07 Quit krabador (Ping timeout: 272 seconds)
00:27:08 Quit Guest54663 (Quit: This computer has gone to sleep)
00:27:41 Quit TheSeven (Remote host closed the connection)
00:30:02 Join Jerom [0] (~heidi@95.171.137.111)
00:31:01 Quit Jerom1 (Ping timeout: 252 seconds)
00:31:17 Quit crow (Remote host closed the connection)
00:33:08 Join anewuser [0] (anewuser@unaffiliated/anewuser)
00:38:12 Join krabador [0] (~krabador@host73-20-dynamic.251-95-r.retail.telecomitalia.it)
00:38:56 Quit {phoenix} (Remote host closed the connection)
00:47:40 Join soap__ [0] (~soap@cpe-76-181-78-156.columbus.res.rr.com)
00:51:24 Quit soap (Ping timeout: 265 seconds)
00:51:49 Join soap [0] (~soap@nl-l1.connectionvpn.com)
00:51:49 Quit soap (Changing host)
00:51:50 Join soap [0] (~soap@rockbox/staff/soap)
00:52:38 Quit soap__ (Ping timeout: 255 seconds)
01:00
01:04:02 Quit Jerom (Read error: Connection reset by peer)
01:04:56 Join T44 [0] (~Topy44@f054209063.adsl.alicedsl.de)
01:08:16 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon)
01:08:31 Quit Topy44 (Ping timeout: 245 seconds)
01:13:22 Quit factor (Ping timeout: 252 seconds)
01:13:36 Quit simonrvn (Read error: Operation timed out)
01:15:00 Join factor [0] (~factor@74.197.182.72)
01:20:41 Quit JdGordon (Quit: Leaving.)
01:24:46 Quit bzed (*.net *.split)
01:24:46 Quit xnyhps (*.net *.split)
01:24:46 Quit crwl (*.net *.split)
01:24:46 Quit Knuckle (*.net *.split)
01:27:53 Quit factor (Quit: Leaving)
01:28:54 Join factor [0] (~factor@74.197.182.72)
01:28:56 Join bzed [0] (~bzed@devel.recluse.de)
01:28:56 Join xnyhps [0] (~xnyhps@xnyhps.nl)
01:28:56 Join crwl [0] (~crwlll@dsl-jklbrasgw1-fe10fb00-173.dhcp.inet.fi)
01:28:56 Join Knuckle [0] (Knuckle@knuckle.student.utwente.nl)
01:30:24 Quit yorick (Read error: Operation timed out)
01:31:01 Join yorick [0] (~yorick@unaffiliated/yorick)
01:31:22 Part toffe82
01:34:16 Quit factor (Ping timeout: 252 seconds)
01:34:50 Quit dfkt (Quit: -= SysReset 2.53=- Sic gorgiamus allos subjectatos nunc.)
01:42:35 Join Kitr88 [0] (~Kitarist@BSN-182-69-12.dial-up.dsl.siol.net)
01:44:22 Quit Kitar|st (Ping timeout: 245 seconds)
01:45:28 Join simonrvn [0] (~simon@197.112-ppp.3menatwork.com)
01:46:49 Quit fyre^OS (Read error: Connection reset by peer)
01:47:05 Quit Kitr88 (Ping timeout: 255 seconds)
01:50:31 Join maffe [0] (~Miranda@77-21-228-126-dynip.superkabel.de)
01:52:02***Saving seen data "./dancer.seen"
01:52:15 Quit maffe (Client Quit)
01:52:16 Join Kitar|st [0] (Kitarist@BSN-182-114-205.dial-up.dsl.siol.net)
01:52:51 Join factor [0] (~factor@74.197.182.72)
02:00
02:07:06 Join Kitr88 [0] (~Kitarist@BSN-182-69-12.dial-up.dsl.siol.net)
02:10:17 Quit Kitar|st (Ping timeout: 240 seconds)
02:13:44 Join JdGordon| [0] (~jonno@vl10.gw.ok-labs.com)
02:13:45 Quit JdGordon| (Changing host)
02:13:45 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon)
02:14:13 Quit s1gma_ (Quit: Leaving)
02:15:08 Quit mc2739 (Quit: leaving)
02:16:32 Quit Kitr88 (Ping timeout: 276 seconds)
02:20:23 Join Kitar|st [0] (Kitarist@BSN-182-110-156.dial-up.dsl.siol.net)
02:20:50 Quit piotrekm (Quit: piotrekm)
02:20:57 Join mc2739 [0] (~mc2739@71.20.73.59)
02:20:58 Quit mc2739 (Changing host)
02:20:58 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739)
02:21:47 Join Kitr88 [0] (~Kitarist@BSN-182-69-12.dial-up.dsl.siol.net)
02:24:03 Join fyrestorm [0] (~nnscript@cpe-68-173-233-99.nyc.res.rr.com)
02:24:53 Quit Kitar|st (Ping timeout: 252 seconds)
02:25:47 Quit DerPapst (Quit: Leaving.)
02:25:51 Quit Kitr88 (Ping timeout: 240 seconds)
02:31:32 Join Kitar|st [0] (Kitarist@BSN-182-142-146.dial-up.dsl.siol.net)
02:34:03 Join Kitr88 [0] (~Kitarist@BSN-182-69-12.dial-up.dsl.siol.net)
02:36:17 Quit stripwax (Read error: Connection reset by peer)
02:36:18 Quit Kitar|st (Ping timeout: 265 seconds)
02:37:24 Join Guest54663 [0] (~leachim6@rrcs-97-78-139-149.se.biz.rr.com)
02:38:30 Quit Kitr88 (Ping timeout: 264 seconds)
02:40:39 Quit Rob2223 (Quit: Rob2223)
02:41:07 Join Rob2222 [0] (~Miranda@pD9FE2C73.dip.t-dialin.net)
02:43:02 Join Kitar|st [0] (~Kitarist@BSN-182-69-12.dial-up.dsl.siol.net)
02:47:11 Quit Kitar|st (Ping timeout: 240 seconds)
02:47:32 Join Kitar|st [0] (~Kitarist@BSN-182-69-12.dial-up.dsl.siol.net)
02:51:09 Join saratoga [0] (9803c22e@gateway/web/freenode/ip.152.3.194.46)
02:51:34saratogafunman: (for the logs) have you seen this? http://forums.rockbox.org/index.php?topic=25809.msg172412
02:51:44saratogaapparently r28000 breaks playback on at least a few fuzes
02:52:11 Quit krabador (Quit: Sto andando via)
02:52:26 Quit Kitar|st (Ping timeout: 276 seconds)
02:57:04 Quit simonrvn (Read error: Operation timed out)
02:58:00 Join Kitar|st [0] (Kitarist@BSN-182-111-143.dial-up.dsl.siol.net)
02:59:47 Quit togetic (Ping timeout: 245 seconds)
03:00
03:04:31 Join Nausicaa [0] (~Nausicaa@c-71-239-58-153.hsd1.il.comcast.net)
03:06:32 Join simonrvn [0] (simon@70.35.167.123)
03:13:44 Join Adublaptop [0] (~Aldubuc@67.201.160.156)
03:13:59 Quit leavittx (Ping timeout: 240 seconds)
03:14:54 Join leavittx [0] (~leavittx@89.221.199.187)
03:21:01 Quit factor (Read error: Connection reset by peer)
03:21:19 Join factor [0] (~factor@74.197.182.72)
03:32:36 Quit Guest54663 (Quit: Leaving)
03:46:24 Quit saratoga (Quit: Page closed)
03:52:06***Saving seen data "./dancer.seen"
04:00
04:05:33 Quit factor (Quit: Leaving)
04:05:37 Join factor [0] (~factor@74.197.182.72)
04:07:39 Quit engwan_ (Ping timeout: 252 seconds)
04:23:03 Quit amiconn (Disconnected by services)
04:23:03 Quit pixelma (Disconnected by services)
04:23:04 Join pixelma_ [0] (quassel@rockbox/staff/pixelma)
04:23:04 Join amiconn_ [0] (quassel@rockbox/developer/amiconn)
04:23:20 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma)
04:23:24 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn)
04:41:18 Join Barahir [0] (~jonathan@frnk-590fd8cf.pool.mediaWays.net)
04:42:06 Quit Barahir_ (Read error: Operation timed out)
04:43:07 Quit anewuser ()
04:51:42 Part Adublaptop
04:56:11 Join JdGord [0] (~jdg@vl10.gw.ok-labs.com)
05:00
05:16:51 Quit JdGord (Quit: Bye)
05:17:31 Quit BlakeJohnson86 (Remote host closed the connection)
05:18:09 Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net)
05:20:30 Join kramer3d [0] (~kramer@residents-ReservedNAT-129-174-190-10.residents.gmu.edu)
05:20:30 Quit kramer3d (Changing host)
05:20:30 Join kramer3d [0] (~kramer@unaffiliated/kramer3d)
05:20:37 Quit fdinel (Read error: Connection reset by peer)
05:33:27 Quit ps-auxw (Ping timeout: 245 seconds)
05:39:13 Quit Horscht (Quit: Verlassend)
05:42:37 Join robin0800 [0] (~robin0800@genld-224-240.t-mobile.co.uk)
05:45:09 Join ps-auxw [0] (~arneb@p4FF7F0F2.dip.t-dialin.net)
05:52:10***Saving seen data "./dancer.seen"
05:52:12 Quit krazykit (Ping timeout: 245 seconds)
05:56:51 Quit BlakeJohnson86 (Remote host closed the connection)
05:57:23 Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net)
06:00
06:01:31 Quit clone4crw (Ping timeout: 276 seconds)
06:06:56 Quit jfc^3 (Read error: Connection reset by peer)
06:07:28 Join jfc^3 [0] (~john@dpc6682208002.direcpc.com)
06:12:17 Quit robin0800 (Ping timeout: 240 seconds)
06:14:45 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
06:16:06 Quit bluebroth3r (Read error: Operation timed out)
06:34:59 Quit antil33t ()
06:35:12 Join antil33t [0] (~Mudkips@124-197-51-80.callplus.net.nz)
06:38:55 Quit kramer3d (Ping timeout: 252 seconds)
06:41:21 Quit Dreamxtreme_ (Read error: Connection reset by peer)
06:42:53 Join kramer3d [0] (~kramer@unaffiliated/kramer3d)
06:46:56 Join Dreamxtreme [0] (~Dreamxtre@92.30.99.91)
06:53:39 Join japc [0] (~japc@bl21-184-138.dsl.telepac.pt)
06:59:45 Quit simonrvn (Remote host closed the connection)
07:00
07:01:48 Join simonrvn [0] (simon@70.35.167.123)
07:33:37 Quit simonrvn (Disconnected by services)
07:33:52 Join simonrvn [0] (simon@70.35.167.123)
07:38:15 Join Maggux [0] (~quassel@krlh-4d0346f6.pool.mediaWays.net)
07:47:40 Quit Judas_PhD (Quit: This is a quitting message)
07:48:57 Join esperegu [0] (~quassel@145.116.15.244)
07:50:06 Quit lestatar (Ping timeout: 240 seconds)
07:50:13 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
07:51:15 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com)
07:52:13***Saving seen data "./dancer.seen"
07:53:30 Quit Zambezi (Read error: Connection timed out)
08:00
08:09:59 Join Zagor [0] (~bjst@rockbox/developer/Zagor)
08:10:40 Quit Nausicaa (Ping timeout: 272 seconds)
08:15:59 Join Zambezi [0] (Zulu@80.67.9.2)
08:25:48 Quit Judas_PhD (Quit: This is a quitting message)
08:48:26 Quit kramer3d (Ping timeout: 276 seconds)
08:49:58 Quit factor (Read error: Connection reset by peer)
08:50:32 Quit Maggux (Remote host closed the connection)
08:50:44 Join ender` [0] (krneki@foo.eternallybored.org)
08:52:09 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl)
08:52:09 Quit bertrik (Changing host)
08:52:09 Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
08:55:58 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com)
08:57:31 Quit japc (Ping timeout: 240 seconds)
08:57:58 Join japc [0] (~misant@bl21-184-138.dsl.telepac.pt)
09:00
09:03:58 Quit JdGordon| (Quit: leaving)
09:07:37 Join factor [0] (~factor@74.197.182.72)
09:14:09 Join petur [0] (~petur@rockbox/developer/petur)
09:25:45 Join Nausicaa [0] (~Nausicaa@c-71-239-58-153.hsd1.il.comcast.net)
09:33:40 Join swilde [0] (~wilde@aktaia.intevation.org)
09:37:08 Join JdGordon [0] (3a6da948@gateway/web/freenode/ip.58.109.169.72)
09:47:44 Quit uberushaximus (Read error: Connection reset by peer)
09:47:48 Join uberushaximus [0] (uberushax@left.4dead.org)
09:52:11 Quit Knuckle (Read error: Connection reset by peer)
09:52:17***Saving seen data "./dancer.seen"
09:52:27 Join Knuckle [0] (Knuckle@2001:610:1908:8000:996f:c095:54f9:9b10)
09:53:57 Join bzed_ [0] (~bzed@devel.recluse.de)
09:54:18 Nick bzed_ is now known as Guest36841 (~bzed@devel.recluse.de)
09:55:59 Quit bzed (Ping timeout: 276 seconds)
09:55:59 Quit xnyhps (Ping timeout: 276 seconds)
09:55:59 Nick Guest36841 is now known as bzed (~bzed@devel.recluse.de)
09:57:05 Join xnyhps [0] (~xnyhps@xnyhps.nl)
09:58:42 Join Rob2223 [0] (~Miranda@pD9FE2954.dip.t-dialin.net)
09:59:03 Quit sasquatch (Quit: WeeChat 0.3.2)
09:59:29 Join sasquatch [0] (~username@p4FF2D230.dip.t-dialin.net)
10:00
10:02:41 Quit Rob2222 (Ping timeout: 276 seconds)
10:04:24 Quit jfc^3 (Ping timeout: 265 seconds)
10:10:01 Join Jaykay [0] (~chatzilla@p5DC57301.dip.t-dialin.net)
10:17:53 Join b0hoon [0] (~quassel@62.87.184.82)
10:18:21 Join lestatar [0] (~chatzilla@cpe-72-229-41-214.nyc.res.rr.com)
10:25:31 Quit JdGordon (Ping timeout: 252 seconds)
10:35:09 Join DerPapst [0] (~Alexander@dslb-088-069-130-074.pools.arcor-ip.net)
10:38:46 Join supercollider [0] (~5edf0cc1@giant.haxx.se)
10:38:54supercolliderhello everyone
10:41:44 Quit supercollider (Client Quit)
10:50:10 Join {phoenix} [0] (~dirk@p57AA3A2C.dip.t-dialin.net)
10:53:01 Join Knuckle` [0] (Knuckle@knuckle.student.utwente.nl)
10:56:27 Quit Knuckle (Ping timeout: 240 seconds)
10:59:30 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven)
11:00
11:03:31 Quit Nausicaa (Ping timeout: 240 seconds)
11:13:35 Quit feisar- (Ping timeout: 255 seconds)
11:25:14 Join einhirn_ [0] (Miranda@wlanstaff083.rz.tu-clausthal.de)
11:25:30 Quit Jaykay (Quit: ChatZilla 0.9.86 [Firefox 4.0b6/20100914073604])
11:32:04 Quit japc (Ping timeout: 272 seconds)
11:33:06 Join japc [0] (~misant@bl21-184-138.dsl.telepac.pt)
11:37:14 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
11:37:29 Quit TheSeven (Disconnected by services)
11:37:30 Join The_Seven [0] (~TheSeven@rockbox/developer/TheSeven)
11:38:04 Nick The_Seven is now known as TheSeven (~TheSeven@rockbox/developer/TheSeven)
11:39:13 Quit einhirn_ (Read error: Connection reset by peer)
11:39:27 Join einhirn [0] (Miranda@wlanstaff083.rz.tu-clausthal.de)
11:51:28 Quit einhirn (Read error: Connection reset by peer)
11:52:19***Saving seen data "./dancer.seen"
12:00
12:04:17 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net)
12:06:18 Quit japc (Ping timeout: 240 seconds)
12:06:52 Join feisar- [0] (jljhook@irkki.fi)
12:07:52 Quit {phoenix} (Remote host closed the connection)
12:10:13 Join {phoenix} [0] (~dirk@p57AA3A2C.dip.t-dialin.net)
12:22:12 Join einhirn [0] (Miranda@wlanstaff083.rz.tu-clausthal.de)
12:25:24 Join MethoS- [0] (~clemens@134.102.106.250)
12:40:12 Quit einhirn (Read error: Connection reset by peer)
12:44:45 Join Jaykay [0] (~chatzilla@p5DC57301.dip.t-dialin.net)
12:48:00 Join drizztbsd [0] (~quassel@dynamic-adsl-78-12-156-134.clienti.tiscali.it)
13:00
13:22:45 Quit factor (Ping timeout: 255 seconds)
13:31:22 Quit mikroflops (Quit: "Skrik det egna rotmosnamnet i latin, låt stanna den nakna ankan ned, annat stål -- nita liten man som Tor, ange Ted Kirks!")
13:43:58 Join einhirn [0] (Miranda@vpn10.rz.tu-clausthal.de)
13:52:22***Saving seen data "./dancer.seen"
14:00
14:00:48 Quit einhirn (Read error: Connection reset by peer)
14:11:55 Join krazykit [0] (~kkit@24-148-89-52.frg-bsr1.chi-frg.il.cable.rcn.com)
14:14:00 Join user890104 [0] (Venci@Venci-Notebook-LAN.ipv6.6bez10.info)
14:14:59 Join factor [0] (~factor@74.197.182.72)
14:20:39 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
14:43:49 Join anewuser [0] (anewuser@unaffiliated/anewuser)
14:44:54 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net)
14:53:21 Join dfkt [0] (dfkt@unaffiliated/dfkt)
14:59:47 Join evinick_B [0] (0c140464@rockbox/staff/evilnick)
15:00
15:00:12 Nick evinick_B is now known as evilnick_B (0c140464@rockbox/staff/evilnick)
15:06:46 Join mikroflops [0] (~yogurt@h-34-59.A238.priv.bahnhof.se)
15:09:25 Join engwan_ [0] (~engwan@112.202.22.199)
15:10:39 Join alecsandru [0] (~Alex@109.96.196.211)
15:12:04 Join JdGordon [0] (7bf38c1f@gateway/web/freenode/ip.123.243.140.31)
15:13:40JdGordondoes anyone object to me commiting this auto configure script thingy? and what would a good name for it be?
15:14:13JdGordonhttp://pastebin.com/PRSM8BNM
15:15:50 Join {-phoenix-} [0] (~dirk@p57AA4269.dip.t-dialin.net)
15:15:56 Quit alecsandru (Quit: Ralph )
15:18:31JdGordon^ that will guess the configure options for paths like e200-sim or sim/e200, or just e200 (and boot also)
15:18:41JdGordonany other styles that people might use can be added
15:20:05 Quit {phoenix} (Ping timeout: 272 seconds)
15:20:11LloreanSo it looks for key terms in the path and uses that to determine the most likely target?
15:23:39JdGordonit looks at most 2 levels up the path, and guesses the target based on that (and the target shortname list)
15:25:00LloreanSounds pretty reasonable to me, I guess.
15:25:50JdGordonim using autoconf as the name here seen as our configure isnt really configure either.... a better name would be nice though
15:28:52 Join teru [0] (~teru@p8067-ipad01koufu.yamanashi.ocn.ne.jp)
15:28:52 Quit dfkt (Read error: Connection reset by peer)
15:29:02 Join dfkt [0] (dfkt@chello062178002170.1.11.univie.teleweb.at)
15:29:17 Quit dfkt (Changing host)
15:29:17 Join dfkt [0] (dfkt@unaffiliated/dfkt)
15:30:01 Join togetic [0] (~togetic@unaffiliated/ibuffy)
15:30:40 Quit togetic (Client Quit)
15:30:51 Join togetic [0] (~togetic@unaffiliated/ibuffy)
15:34:19 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky)
15:37:12 Quit antil33t (Read error: Connection reset by peer)
15:37:22 Join antil33t [0] (~Mudkips@124-197-51-80.callplus.net.nz)
15:37:43 Quit Judas_PhD (Quit: This is a quitting message)
15:40:42 Quit anewuser ()
15:43:28 Join einhirn [0] (Miranda@wlanstaff083.rz.tu-clausthal.de)
15:43:41 Join olgagirl [0] (~olgagirl@212-198-248-35.rev.numericable.fr)
15:44:08 Quit olgagirl (Client Quit)
15:44:12 Quit einhirn (Client Quit)
15:44:31 Join einhirn [0] (Miranda@wlanstaff083.rz.tu-clausthal.de)
15:44:59CIA-81New commit by 03jdgordon (r28180): Add a simple script to try to run configure with the correct target name/type based on the build directory name. ...
15:45:45 Quit teru (Quit: Quit)
15:46:49CIA-81r28180 build result: All green
15:47:47 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com)
15:48:09 Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com)
15:52:25***Saving seen data "./dancer.seen"
15:57:44 Join anewuser [0] (anewuser@unaffiliated/anewuser)
16:00
16:04:20 Quit JdGordon (Ping timeout: 252 seconds)
16:05:42 Join Strife89TX [0] (~cstrife89@207.144.201.128)
16:07:24 Join n1s [0] (~n1s@nl118-174-240.student.uu.se)
16:07:24 Quit n1s (Changing host)
16:07:25 Join n1s [0] (~n1s@rockbox/developer/n1s)
16:12:11 Quit Dreamxtreme (Quit: Going!)
16:13:52 Join saratoga [0] (9803c22e@gateway/web/freenode/ip.152.3.194.46)
16:14:30saratogawhy do we have a setting to configure how much memory is allocated to playlists, couldn't that be dynamically allocated on the audio buffer as needed?
16:16:27gevaertsWouldn't that require stopping playback to insert a track?
16:17:25saratogathe buffering system seems to be able to allocate new buffers for things like JPEGs without stopping playback
16:19:32 Quit einhirn (Read error: Connection reset by peer)
16:19:41gevaertsSure, but it's also allowed to throw those buffers away with little or no warning, and (in theory) to move them around
16:21:00saratogacan it really drop anything its buffered anytime? how does that work with album art
16:21:15saratogaor does the art get decoded to something not on the audio buffer?
16:21:43gevaertsanytime is a bit strong, but it gets dropped at least on "stop"
16:22:03gevaertsI think it's decoded to a the wps buffer. Ask Unhelpful for details :)
16:23:18gevaertsThere's been talk over the years of making buffering a bit more usable for this sort of thing, but nothing real has been done yet
16:25:20pixelmajust as a side-note, you are talking about swcodec buffering
16:25:47gevaertsyes
16:26:12gevaertsAlthough I still don't really understand why swcodec and hwcodec are different
16:29:21Unhelpfuldoes hwcodec maybe use less space per buffer object for metadata? because the per-buffer-object header on swcodec iirc is quite large.
16:29:34saratogalooking at buffering.c they look the same, theres no HWCODEC anywhere in the file
16:29:42saratogaalthough playback.c is much different
16:33:12pixelmaplayback engines are different, the hwcodec doesn't load codec IIUC. I believe unification was wanted but became harder with the big difference of MoB. I don't think there is a technical reason for it
16:34:40pixelmaas in "it is impossible to do" I mean
16:35:02LloreanI seem to recall talk about unifying them in the past.
16:37:59saratogaloading the codec isn't much different on swcodec, you can disable it with one line of code
16:38:17saratogathen it doesn't get buffered, but rather just loads the .codec file on track change, spinning up if needed
16:38:42n1shwcodec could actually benefit from that as it could then have wav playback as a codec
16:39:14n1sthis has been discussed many times though and i think most people agree it would be good but noone wants to do it
16:39:34saratogawell its hard to be motivated to work on a 10 year old mp3 player
16:39:48n1syes
16:40:09n1seven harder for a 10 year old player you don't even have
16:40:14saratogathat too
16:40:42saratogai really need to find time to understand more about how buffering works
16:41:23saratogaif Nico is ever around again i'm going to bug him until he explains it to me
16:42:54Unhelpfulthe comments seem to suggest it's a linked-list. the only complicated part afaik is that audio buffers are allowed to wrap around the end of the buffer area
16:46:40Unhelpfuliirc the linked-list headers have a rather large chunk of other data in them, too, though.
16:47:41*Unhelpful reads up further
16:49:28Unhelpfulaiui generally the buffer is in playback order, we can "insert" AA because it's "next to" the track with which it's associated. when i looked it also appeared we buffered tracks multiple times if they were in the playlist multiple times. same for AA, which seems pretty wasteful for targets that might use large color AA, and if your AA is all actually per-album.
16:54:25 Quit b0hoon (Quit: Back to work.)
17:00
17:02:00 Quit mikroflops (Quit: "Skrik det egna rotmosnamnet i latin, låt stanna den nakna ankan ned, annat stål -- nita liten man som Tor, ange Ted Kirks!")
17:11:22 Join Dreamxtreme [0] (~Dreamxtre@92.30.99.91)
17:15:34 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201)
17:15:49 Join _s1gma [0] (~d.d.derp@77.107.164.131)
17:18:53 Join Nausicaa [0] (~Nausicaa@c-71-239-58-153.hsd1.il.comcast.net)
17:21:27 Quit _s1gma (Quit: Leaving)
17:21:48 Join _s1gma [0] (~d.d.derp@77.107.164.131)
17:22:09 Quit {-phoenix-} (Read error: Connection reset by peer)
17:23:36 Quit TheSeven (Ping timeout: 272 seconds)
17:24:38 Join Strife89DS [0] (~nds@207.144.201.128)
17:25:32 Quit Strife89TX (Quit: Switching apps.)
17:26:43 Part Zagor
17:26:44 Quit antil33t (Read error: Connection reset by peer)
17:26:55 Join antil33t [0] (~Mudkips@124-197-51-80.callplus.net.nz)
17:33:52TorneUnhelpful: we could be clever and not bother to buffer it if it's identical, yes, and just make a note to keep the current image in the wps buffer. it would just need someone to *do* it.
17:34:13TorneUnhelpful: it'd only be much of a benefit when people's album art is big, though
17:34:47Tornehm, actually i forget whether it buffers the source file or the decoded image
17:35:15 Join phixxor [0] (~Patrick@pool-74-96-229-3.washdc.fios.verizon.net)
17:36:52 Join mikroflops [0] (~yogurt@h-34-59.A238.priv.bahnhof.se)
17:37:11phixxorok I know you are going to laugh at me
17:37:38phixxorbut do any audio players work well with rockbox? I've searched google, the wiki, and the manual, but I don't see anything about it
17:38:09 Quit anewuser ()
17:38:12phixxoras ipods are to itunes, rockbox is to ___ ?
17:38:17n1syes, the ones in the "stable" category on the front page
17:38:32phixxorthat's not what I meant, sorry about being ambiguous
17:38:43phixxornot portable audioplayers, computer audio players
17:39:03n1sah, then you have to define "work well" too
17:39:08LloreanRockbox doesn't really need a PC side app for anything.
17:39:14gevaertsAll audio managers that behave sensibly will work well with rockbox :)
17:39:23phixxorthrough MTC I assume?
17:39:31phixxoror whatever it is
17:39:35LloreanDepends on whether you mean MTP or MSC
17:39:41phixxoryeah :P which is it?
17:40:02phixxorMTP is the one audio mangers use, I think
17:40:04LloreanWell, Rockbox presents itself as MSC, but MTP is an abbreviation for something vaguely similar.
17:40:08UnhelpfulTorne: decoded and converted to screen format.
17:40:26Unhelpfulso 4bpp on greyscale, 16bpp on color
17:40:43UnhelpfulLlorean: Media Transport Protocol i think
17:41:04TorneUnhelpful: that's not super big, but it's not tiny
17:41:09LloreanUnhelpful: Transfer, I thought
17:41:10phixxorBy "work well" all I mean is I'll be able to put playlists from my computer to rockbox easier than dragging files and folders, and making the playlist on the dap
17:41:14UnhelpfulLlorean: might be :)
17:41:22LloreanUnhelpful: I just meant by "vaguely similar" that it's also used for getting songs onto gadgets.
17:41:25Tornephixxor: you should already be able to make playlists just by dragging and dropping them
17:41:45phixxordragging what onto where?
17:41:49Torneplaylist files
17:42:07Lloreanphixxor: Rockbox works with standard M3U playlists.
17:42:09n1sphixxor: if you have the same dir structure on computer and DAP, your playlist should work in rockbox if they are m3u
17:42:11Torneif a playlist on the PC refers, to, say, e:\mp3\foo\bar.mp3
17:42:18UnhelpfulLlorean: extremely dissimilar in terms of how it works, though... MTP is metadata-aware and object-oriented. MSC isn't even really aware of files as objects.
17:42:24Tornethen that playlist will work on Rockbox even if the structure on the player is just \foo\bar.mp3
17:42:32TorneRockbox automatically strips directories fromt he front of the path until it matches
17:42:52LloreanUnhelpful: That's why I said "vaguely similar" :) He abbreviated MTC and I could see him possibly meaning either MTP or MSC with that when discussing DAPs.
17:42:54Torneso any media player tha tmakes standard m3u format playlists (virtually everything except itunes) should just work fine
17:43:14UnhelpfulTorne: also scaled to their presentation dimensions, though, so if you have high-res jpeg AA the buffered AA might be smaller.
17:43:22TorneUnhelpful: that was what i was getting at
17:43:34TorneUnhelpful: the benefit is going tobe the same for everyone on a given player regardless of what their album art is like
17:43:47Tornewell, a given theme
17:43:58phixxorOk that is really good to hear about m3u playlists :) −− but if I put a playlist file in rockbox, but the songs aren't on the dap yet, I'll have to track down each song. My dap only has 10GB of space
17:44:24Torneright. so yes, lots of media player programs will do that
17:44:28phixxorSo it would be really cool if I could add a playlist to rockbox, and then the audio manager program copies the needed songs
17:44:31Tornethere is nothing special about a rockbox device compared to anything else
17:44:35phixxorsweet :) I'm looking for one on mac
17:44:46Torneanything that works with a normal non-ipod mp3 player will just work
17:44:49Tornethere are literally thousands
17:45:00*Unhelpful only sees consolidating track data as a benefit if you queue lots of small tracks and frequently repeat them.
17:45:14Unhelpfulso if i wanted an hour of white noise i guess. :P
17:45:19TorneUnhelpful: track data is less interesting, yeah
17:45:46 Quit Kitar|st (Ping timeout: 272 seconds)
17:45:54 Join saratoga_ [0] (9803c6dd@gateway/web/freenode/ip.152.3.198.221)
17:45:58phixxorright now, all I know of on mac are: itunes, cog, vlc, and possibly songbird, except I heard it's not being developed anymore
17:47:17Tornesongbird is still being developed afaik
17:47:29phixxoroh, awesome :D
17:47:51phixxorI'll try that then. Thanks a lot for your help!
17:48:01n1syeah, they just dropped the official linux support
17:48:51 Join Barahir_ [0] (~jonathan@frnk-590f7c32.pool.mediaWays.net)
17:49:04phixxoroh that's what it was :(
17:50:09UnhelpfulTorne: when i've thought about this, my thinking has been that buffer could be a compactible list of objects w/ minimal headers, and things like tracks, etc, could add their own headers *inside* the buffer objects they use.
17:50:36Unhelpfulthis would make it more useful as a general allocator too, because things that aren't tracks are unlikely to store a filename etc
17:50:53Torneit's still not veyr useful as a general allocator, though, because of its ringbufferness
17:50:58Unhelpfuleither a linked list as it is now, or list+index like buflib uses.
17:51:13Unhelpfulwell, if it's compactible you could actually get rid of all the wraparound-handling code, no?
17:51:28Tornei don't mean the wraparound specifically
17:51:34Tornei mean the fact that it always allocates at the end
17:51:48Tornefor a wrapping value of "end"
17:51:52 Quit Barahir (Ping timeout: 276 seconds)
17:52:00saratoga_you could also just request space from the front of the ring, and shrink the size of the buffer
17:52:06Unhelpfuloh. well, yes, but compaction does some good for that as well, since we can make all free space be at the "end"
17:52:08Tornei.e. you can't allocate anything on it whose lifetime is not between the lifetimes of the adjacent things
17:52:18Tornesaratoga_: only for one thing
17:52:26Tornesaratoga_: that doesn't extend to multiple things wanting to do allocations
17:52:28***Saving seen data "./dancer.seen"
17:52:30saratoga_why not?
17:52:46Tornebecause once you get three things allocated that way and then the middle one goes away you have a hole
17:52:46saratoga_each one just shrinks the buffer more, and creates a new "start"
17:52:57Unhelpfula tricky problem for compaction is that codecs may save pointers into their current buffer. :/
17:52:59Tornefragmentation increases over time
17:53:06Tornethen you die
17:53:08saratoga_sure, but you can compact things
17:53:11UnhelpfulTorne: hence the need for compaction. :)
17:53:19Tornebut generally you *can't* compact things
17:53:24Unhelpfulsaratoga_: i don't think the bufer *does* right now.
17:53:42Tornebecause codecs can use pointers to anywhere in their buffer
17:53:46Torneand so on
17:54:20*Torne would, if we were going to go this way, seriously just implement the doug lea malloc().
17:54:23Torne:)
17:54:28Tornerather than worrying about compaction
17:54:34saratoga_AFAIK it can flush things and move them around now
17:54:39 Quit phixxor (Quit: Leaving)
17:54:45saratoga_i don't think we want malloc on the buffer
17:54:45Tornesaratoga_: only up to the point that the codec has advanced the buffer pointer to
17:55:00Tornewell no, we've always said we don't
17:55:05Unhelpfuli don't think it can move them around all that much.
17:55:10Torneit doesn't move the data
17:55:12Torneit only moves the buffer heads
17:55:14saratoga_can't it just dump everything, zero the whole buffer, and rebuffer if things change?
17:55:24Torneyes, more or less.
17:55:24saratoga_i vaguely remember there was some case were that happened, but i forget what it might be
17:55:26Unhelpfulsaratoga_: that's a very costly sort of compaction. ;)
17:55:35UnhelpfulAA size change forces rebuffer.
17:55:41saratoga_sure but how often do you change the max playlist size?
17:55:52 Join crow [0] (~crowmo@chello080108001109.35.11.vie.surfer.at)
17:55:55Tornesaratoga_: the problem is, as i said, if there is *more than one* of these things
17:55:57saratoga_probably once per boot, hopefully before audio starts playing :)
17:56:01Torneif there's several things that can be changed in size..
17:56:12saratoga_dump the whole buffer everytime and start from scratch?
17:56:20TorneYou don't just have to dump the buffer, then
17:56:27Torneyou would have to be able to dump all the things that can change size *too*
17:56:32Tornebecause they might need to mvoe as well
17:56:40Torneyou'd effectively have to redo every single dynamic allocation
17:56:40saratoga_what do you mean change in size?
17:56:52Torneif you change the max playlist size, there might not be room to extend it inplace
17:56:59Tornebecause something else that's configurable might be occupying th enext ram
17:57:02 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net)
17:57:03Torneeven if you dump the whole buffer that won't go away
17:57:11saratoga_i assume everytime you changed the playlist size it would dump the whole buffer and reallocate everything
17:57:21TorneBut the things that use buffer_alloc() are *not in the buffer*
17:57:25Tornethey cannot be reallocated at all, at present
17:57:28Torneyou don't even know what they are
17:57:34Torneat runtime, i mean :)
17:57:43Tornethat memory is all permanently excised
17:57:58Torneso yes, for *one thing* you can easily make it resizable: buffer_alloc it last and then rebuffer when you change it
17:58:13Tornebut when N things can be resized, even throwing away the contents of the buffer isn't sufficent to do that
17:58:29Torneyou would need to, say, be able to throw away and recreate dircache, or tagcache, or whatever else might be in the way
17:58:48saratoga_don't you only have to dump the buffer on free?
17:59:07Torneno, see my earlier example
17:59:11Torneyou buffer_alloc() three things
17:59:14n1sthat sounds like it would need some kind of callback system to first save what needs to be saved and then rebuild after reallocation
17:59:15 Join Staphylo [0] (~Bullet@AMontsouris-159-1-51-172.w92-128.abo.wanadoo.fr)
17:59:15Tornethen you want to make the seocnd one bigger
17:59:20Tornehow do you do that?
17:59:28Torneyou need to throw away the third buffer_alloc'ed thing to make room.
17:59:34saratoga_ah i see what you mean
17:59:37Torneor else leave a hole that can never be reclaimed
17:59:56TorneSo yeah, at this point you may as well give up and implement a decent low fragmentation malloc
18:00
18:00:07Torneand just use it for everything
18:00:23saratoga_so whats the alternative, put them in the ring buffer like audio tracks?
18:00:33TorneNo, you can't do that either, because you'd have to skip over them
18:00:40Tornethey'd be like, er, humps in the road on the ring
18:00:52Torneand that's malloc again.
18:00:54Torne:)
18:01:03saratoga_why is skipping over them a problem?
18:01:16Tornebecause the metadata to keep track of that is exactly the same metadata you need to implement malloc
18:01:23Torneso you might as well stop being a ring buffer and just be malloc.
18:01:51saratoga_i don't follow you
18:01:52Tornei'm not arguing that this is impossible, just that i don't think there is a tradeoff *inbetween* what we have now, and just a full dynamic allocator
18:02:08Torneif you allow N things to be allocated and resized
18:02:10 Part barfster
18:02:14 Quit DerPapst (Ping timeout: 272 seconds)
18:02:18Tornethen the ring buffer may, in the worst case, need to jump over N seperate blocks of memory as it goes along
18:02:23Torneso you need to keep track of that data
18:02:31Torneand that data is exactly the same data that a malloc would keep and use.
18:02:32saratoga_i think it already does this?
18:02:39Tornewhat?
18:02:41Torneno it doesn't
18:02:43saratoga_since buffered objects currently can have different sizes
18:02:51TorneIt keeps track of a single linked lits of objects
18:03:02Tornewhich are in memory order, modulo wraparound
18:03:06saratoga_we've already got a buffering API on the ring buffer that allows allocing and freeing randomly sized objects
18:03:09Torneand it only ever frees from the start and allocates on the end
18:03:15n1show does a real malloc help though? it would still need to kill playback on new allocs if they don't fit in any other hole
18:03:44Tornen1s: yes, but that will probably neve rhappen
18:03:52Tornebecause a decent malloc is good at fragmentation avoidance
18:04:07Tornesaratoga_: it doesn't allow allocing and freeing them in a random *order*
18:04:13Tornesaratoga_: they can only be freed in playback order
18:04:29Torneso it works fine for codecs, tracks, album art, etc, which are accessed and disposed of in playback order.
18:04:31n1sTorne: in you previos use case it would i think, unless we modify the adio buffer to be discontigouos in some way
18:04:32saratoga_i think it does allow freeing them in random order, it just doesn't actually overwrite them until it gets around the ring IIRC
18:04:43Tornen1s: you wouldn't have an audio buffer
18:04:48Torneyou would just malloc cells for audio data as well
18:04:56Torneand not be a ring buffer at all
18:05:29Torneyou just need a clever trick in malloc to be able to request a range of sizes :)
18:05:36Torne"give me between 256kb and 32MB of memory"
18:05:40n1sTorne: but if you malloc the audio buffer how will it know what to kill once it runs OOM? (using all free memory for buffering is preferrable)
18:06:20Tornen1s: you ask the audio buffering system to free some up
18:06:30Torneor just keep track yourself of what is there
18:06:35Tornei'm not suggesting implementing this
18:06:58saratoga_isn't the advantage of the ring buffer that fragmentation doesn't become a problem because theres no assumption that sequentially buffered bytes are sequential in RAM? if you went to malloc you would loose that
18:06:59Tornei'm just noting that 1) it's a feasible thing and 2) what you're suggesting becomes this, if it was actually implemented so that it worked
18:06:59n1swell, it could probably work
18:07:23Tornei don't personally have a problem with buffer_alloc'ed stuff being fixed size until reboot.
18:08:10n1sthe actual reboot is a bit overkill, just redoing the allocations and buffering data again should do
18:08:23Tornewell yes, but currently we don't have a way of redoing the allocations
18:08:32Torneand supporting that is very close to just restarting
18:08:38Tornei guess you don't need to restart the actual hardware
18:08:51Tornebut a huge proportion of the stuff done at boot time is allocating and then populating those buffers
18:08:54Tornedircache, tagcache, etc.
18:09:18Tornenot having a buffer_free() is what makes our current system reasonable at all :)
18:09:19n1sthe gigabeast in dualboot config takes fricking ages just to boot :(
18:09:58n1sTorne: i meant more like a buffer_throw_everything_away_and_start_over()
18:10:53Tornen1s: yes, i know
18:11:17Tornethe max playlist size is the one that started this discussion, right?
18:11:28n1si think so
18:11:29Tornehow many things are there that you really care about being able to change without rebooting? I can see that one :)
18:11:41n1smax files in browser too
18:11:49saratoga_i just wondered why we even have such an odd setting
18:11:51n1sand the databse if it's in ram i think
18:12:01Torneheh
18:12:04Tornei guess the dircache too technically
18:12:11Tornesince we currently allocate, what, 10% more space
18:12:18saratoga_i mean i realize its hard to predict, but asking the user to guess how many files they're going to put in a playlist is odd, particularly given how the database works
18:12:22Torneso if you add more than 1/10 the number of files during usb the dircache breaks
18:12:33n1ssaratoga_: it's to save ram on the ram starved players, it makes little sense on anything with 8MB or more
18:12:50 Join wodz [0] (~wodz@chello087206240131.chello.pl)
18:12:54Tornetbh i kinda have the outline of a hybrid malloc-and-buffering system in my hea dnow
18:12:57Tornedamn you all
18:12:58 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven)
18:12:59n1salso it's from way before the database
18:13:06saratoga_no i understand that, I'm just saying it seems like a poor design choice on our part
18:13:33n1ssaratoga: what do you propose instead?
18:13:34wodzdo we have bitmap scaling function but working on bitmap in native lcd format?
18:13:44saratoga_i'm a developer and i don't even have a good handle on how many files i need in a playlist to have the database work well with my files :)
18:14:08Tornefor malloc I guess what you'd do is have two tiers of allocation, and maintain the second tier as a ring
18:14:27Tornethen wheneve ryou needed to do a "real" alloc that didn't fit in free memory you can murder the last buffer handle in the ring
18:14:37Torneand when a codec starts using a buffer handle you lock it down as a real allocation
18:14:40Torneor similar :)
18:15:01n1sTorne: sounds reasonable to me
18:15:06Torneyou could use quite a stupid actual malloc algorithm because all the blocks will be pretty big
18:15:12Tornewe still wouldn't want to do the malloc(4) type thing
18:15:35Tornewell, i guess you could for some stuff, not quite that small
18:15:37Tornebut, say
18:15:45Tornei don't think there's any reason the dircache has to be a contiguous block of ram really
18:15:59Torneso you could possibly modify some of those systems to be expandible without needing realloc()
18:16:22Tornethis is all getting into very controversial territory ;)
18:16:36n1sand if you don't need to alloc the extra 10% you also save memory
18:16:40Torneindeed
18:16:53Tornethough again, you wouldn't want to do it incrementally really
18:16:54saratoga_i love seeing things like "#if MEM > 8" in buffering.c
18:17:03saratoga_fills me with confidence that the code is working correctly
18:17:06Torneyou'd want to allocate another big lump after USB
18:17:24Torneyou can always allocate too much and then prune it.
18:17:55Tornefragmentation is much easier to control while you're doing coarse grained cooperative multitasking
18:17:58Torne:)
18:18:12Tornesince nobody comes in and uses gaps you create temporarily
18:19:45Tornebah, now i'm tempted to try and work out how to do this. damn you all.
18:21:52saratoga_i still like the idea of just sticking things on the audio buffer like files, and accessing them via the buffering API so they can be reallocated
18:22:07saratoga_err relocated, not reallocated
18:22:51Tornei don't see how that's possible with the cod ebeing anything like it is at the moment
18:23:14saratoga_because the data might be deleted on the buffer?
18:23:42Tornebecause of the strict ordering on the buffer. currently you'd need to move it every time the buffer wraps...
18:24:00Torneevery time you free the thing before it, you'd want to reallocate and move it to the end
18:24:12Tornewhich would be.. often, on devices with small ram
18:25:14saratoga_the difference here verses an audio file being that the entire object would need to be contiguous, and not just accessed via small chunks like the codecs do?
18:25:35Tornethe difference is it's long-lived
18:26:03Torneif you load a playlist of 5000 tracks then the playlist buffer needs to sit there with that data in it for hundreds of complete cycles around the buffer
18:26:27Tornemaintaining that in the circular buffering system, i can't see how you'd do it that doesn't involve shuffling it around hundreds of times, once each time you cycle
18:26:42saratoga_whereas audio files would just be deleted and thus don't need to be moved?
18:27:01Torneindeed
18:27:21TorneNothing currently in the audio buffer has a lifetime greater than one cycle around the buffer, by definition
18:27:33Tornesometimes things' lifetimes are less, if they get freed early
18:28:02 Join {phoenix} [0] (~dirk@p57AA4269.dip.t-dialin.net)
18:28:07saratoga_if repeat is on they do
18:28:13TorneNo they don't
18:28:17TorneWe had this discussion several time sbefore
18:28:23Torneif you turn repeat on, then the track data gets buffered multiple times
18:28:33saratoga_i'm pretty sure we don't rebuffer if the entire playlist fits in the buffer and its looping
18:28:36TorneYes we do.
18:28:50TorneIt buffers the playlist over and over until ram is full
18:28:55Torneeven if that's just one track
18:29:00Tornethen when it plays all that it does it again
18:29:16Tornei've had this discussion with people before, because i also assumed it worked sensibly
18:29:19Tornebut it doesn't.
18:29:28saratoga_then why does everyone say you need to have a folder with more files then the audio buffer size when doing a battery bench?
18:29:37TorneBecause they also think the same wrong but obvious assumption
18:30:13Torneyou can play a single track on repeat and you'll get the same battery bench results, in reality
18:30:38TorneIf you cripple the audio buffer size and then just try it, watching the buffering screen, you'll see it do it
18:30:43Torneand feel the disk spin up each time
18:30:43Torne:)
18:31:26Torneso yes, currently *no* handle lasts for more than one cycle aorund the buffer.
18:31:57Tornethe algorithm for managing the free space is really trivial; it's just the space between the end of the last handle and the beginning of the first.
18:32:08Torneif htat's not enough room it tries to move the first handle up to the current read position
18:32:15Tornebut that only works if the codec has moved the read pointer up far enough
18:33:07Torneanyway. someone please correct me if i've said anything untrue here :) I am reasonably sure i understand more or less how it works but not certain ;)
18:33:13Tornei'm heading off for now.
18:34:40saratoga_hmm
18:34:52saratoga_i tried testing, but eventually it stopped changing tracks
18:34:58saratoga_and then threw a divide by 0 error
18:35:01saratoga_good game buffering system
18:36:17saratoga_IMO no one should be allowed to change anything about how the buffering system works from now on without also rigging up some way to run it on a PC with a simple test driver
18:37:16gevaertssaratoga_: we're not allowed to fix bugs? :)
18:37:57saratogadepends
18:38:04saratogamost fixes we've tried recently just broke other things
18:38:22saratogae.g. the clip playback fixes I tried that lead to our rockbox 3.5.1 release
18:42:50 Join Jerom [0] (~jerome@95.171.137.111)
18:43:54 Join anewuser [0] (anewuser@unaffiliated/anewuser)
18:44:02 Quit engwan_ (Ping timeout: 272 seconds)
18:51:52 Quit swilde (Quit: ERC Version 5.3 (IRC client for Emacs))
18:52:20 Quit Strife89DS (Quit: Packing up.)
18:56:10 Quit Stummi (Quit: ZNC - http://znc.sourceforge.net)
18:56:21 Join engwan_ [0] (~engwan@112.202.22.199)
18:59:34 Join Stummi [0] (stummi@doppeldenk.org)
19:00
19:03:21Unhelpfulmy idea for a compactible buffer had pretty much boiled down to some kind of hack for codecs to be forced to reload their pointers, plus "everything else is only allowed to use the handle" ;)
19:11:56gevaertsFor some reason I prefer that idea
19:19:16 Quit dfkt (Read error: Connection reset by peer)
19:19:22 Join dfkt [0] (dfkt@unaffiliated/dfkt)
19:31:55 Join sudoman [0] (c05041e7@gateway/web/freenode/ip.192.80.65.231)
19:33:06 Quit saratoga (Quit: Page closed)
19:33:31 Quit Nausicaa (Quit: Leaving)
19:38:04sudomancould anyone please take a peek at FS #5230 ?
19:43:34 Join bmbl [0] (~Miranda@unaffiliated/bmbl)
19:44:12 Join Gibble [0] (~Gibble@78-105-152-175.zone3.bethere.co.uk)
19:46:03 Quit Gibble (Client Quit)
19:52:29***Saving seen data "./dancer.seen"
19:55:46preglowandroid rockbox sometimes just stops playback and refuses to start playing again, known bug?
20:00
20:00:35 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
20:09:08 Join Buschel [0] (~chatzilla@p54A3B2D2.dip.t-dialin.net)
20:09:12 Join guest [0] (411dfb31@gateway/web/freenode/ip.65.29.251.49)
20:14:19 Join Horscht [0] (~Horscht@xbmc/user/horscht)
20:17:07Unhelpfulgevaerts: because it's not malloc? ;)
20:17:47 Quit guest (Quit: Page closed)
20:18:23Unhelpfulwe have a number of things that could use a dynamic allocator, some of them have been held back because of the lack of one, or have to rely on hacks for one in pluginlib or codeclib. and for things where allocations may be long-lived i think a handle allocator that *can* compact will be superior to a pointer allocator that *can't*.
20:18:25 Join webguest03 [0] (~5b12d44f@giant.haxx.se)
20:19:10Unhelpfulwe could have malloc and compaction on targets w/ an MMU if we wanted to, but i think there's something worthwhile in a single API that can work as well on any target
20:19:28gevaertsUnhelpful: actually, not entirely. With this scheme I can *see* that it won't die of fragmentation
20:20:00gevaertsWhile with a "standard" malloc, I have to believe Torne when he says that he thinks it won't :)
20:23:15gevaertsAnd frankly I don't believe there's a malloc implementation that avoids fragmentation. There may be some that reduce it, or postpone it, but in the end it will still go horribly wrong
20:23:25 Quit webguest03 (Quit: CGI:IRC (Ping timeout))
20:28:51 Join CGL [0] (~CGL@190.77.217.134)
20:31:07 Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de)
20:31:23 Quit sudoman (Quit: Page closed)
20:32:35 Join kugel [0] (~kugel@46.115.51.168)
20:32:37 Join sudoman [0] (d8ecfce7@gateway/web/freenode/ip.216.236.252.231)
20:32:37 Quit kugel (Changing host)
20:32:37 Join kugel [0] (~kugel@rockbox/developer/kugel)
20:33:00 Join kazaik [0] (~kazaik@pool-71-166-21-14.bltmmd.east.verizon.net)
20:33:56 Join webguest55 [0] (~5b12d44f@giant.haxx.se)
20:36:54 Quit webguest55 (Client Quit)
20:41:46 Quit Jerom (Quit: Leaving.)
20:42:41 Quit fyrestorm (Quit: Ur skills' fireproof like a wooden panel -- U got feds talking leet on your IRC channel!)
20:42:45 Join Jerom [0] (~heidi@95.171.137.111)
20:42:58 Quit jgarvey (Ping timeout: 276 seconds)
20:43:23 Join jgarvey [0] (~jgarvey@65.190.66.89)
20:54:45 Quit sudoman (Ping timeout: 252 seconds)
20:54:48Tornegevaerts: well handles is fine for the things that don't mind having stuff compacted under them, if you don't mind the overhead of *doing* it..
20:55:14Tornegevaerts: i just don't think a malloc that handles maybe two or three dozen large blocks is likely to be a huge fragmentation issue
20:55:24Tornea complexity and codesize issue, quite possibly
20:55:29Tornewhich is why i'm not really advocating it
20:56:09gevaertsTorne: if you look at current buffer_alloc() behaviour, you'll see more than two or three dozen large blocks
20:56:22gevaertsThere are some large blocks, yes, but also lots of small ones
20:56:25Tornei wasn't going to turn those into allocations
20:56:39Torneoh, hm
20:56:40Torneno, sorry, yeah
20:56:46Tornewell maybe some of those are small, yes
20:56:59Tornebut if there's no reason for them to change size at runtime then you don't care
20:57:08Torne:)
20:57:23Torneand are there really that many? i didn't think so..
20:57:31gevaertsI'd have to check again
20:57:46*Torne updates his upstream branch and waits for the description change to break his repository
20:58:04Tornehaha silly git people, bzr-svn doesn't care
20:58:11gevaertsBut anyway, I actually suspect lots of those *do* want to change size
20:58:12Torneactually. :)
20:58:34Tornehmm
20:59:05gevaertsWell, maybe not the small ones, but the amount of them might want to change :)
21:00
21:00:02gevaertsWe have several settable limits arbitrary, and some non-settable ones. I'd say those are the majority of the buffer_alloc()s
21:00:13gevaertsThose are either too large or too small
21:00:45Tornethere are 39
21:00:55Tornein total in the tree
21:01:05Tornei suspect not all of them are used on a given build
21:01:13Tornethat's not a lot, tbh
21:01:35 Join [sko] [0] (~sko]@p57A9BA55.dip0.t-ipconnect.de)
21:01:38gevaertsOne of the dircache ones isn't just called once
21:01:44Tornesure.
21:01:50Tornebut that's uninteresting in total then
21:02:09Torneif you can tack on more chunks like that already you don't need to resize it with any other implemnetation either
21:02:14Torneso it doesn't cause fragmentation of memory
21:02:30Torneanything that needs to grow but *doesn't need a contiguous chunk of ram* is awesome
21:02:37Torneespecially if there's also no reason for it to shrink
21:02:44gevaertstrue
21:04:45Tornesome of these can be optimised quite a bit by using the whole cooperative-multitasking thing
21:04:53Tornee.g. filetypes.c buffer_allocs a bunch of strings for extensions
21:05:17Tornebut nothing else is going otbe touching the buffer at that time, so you can just steal a bigger bit then truncate it when you're done and then it's one.
21:06:07Tornesorry, i'm doing a very bad job of not really advocating this
21:06:12gevaerts:)
21:06:20Torneit just seems like less of a horrible hack than the other suggestions earlier
21:07:13gevaertsI suspect that whichever way we pick, the first thing to do would be to make playback handle requests for freeing some memory
21:08:00 Join sudoman [0] (c05041e7@gateway/web/freenode/ip.192.80.65.231)
21:08:18Torneyou need some way for it to be aware that you want to throw away some of its buffer handles
21:08:21Torneyes :)
21:09:15gevaertsAnd of course teaching things to handle noncontiguous memory would be a bonus
21:09:36TorneYeah, there are probably other things that could be noncontiguous without adding particular overhead
21:09:52Tornethings which are just arrays because it's easier rather than because there's any actual size/speed benefit
21:10:50 Quit kugel (Ping timeout: 265 seconds)
21:10:53Torne*those* things could be made to grow without needing any new stuff
21:11:04Tornejust kill playback, buffer_alloc a new chunk, and then rebuffer
21:11:26Torneonly the things that really need to stay contiguous are a problem
21:14:09 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net)
21:18:02 Join domonoky1 [0] (~Domonoky@agsb-d9bdb7bf.pool.mediaWays.net)
21:19:33 Quit domonoky (Read error: Connection reset by peer)
21:19:58UnhelpfulTorne: the buflib implementation has *fairly* low overhead for new handle fetches, pretty much it's one more indirection than storing the pointer to the memory. it does this by keeping the handles in a table at the end of the allocation buffer. and yes, that can mean some fragmentation in the handles table if you, say, allocate a few hundred handles and free all but the last one. but handles only cost 4B each and it will reuse all of those
21:19:58Unhelpful free handles before growing the handle table any more.
21:20:24TorneUnhelpful: the overhead is mostly in "not being able to store pointers to shit" though
21:20:43Tornenot in the handle lookup
21:20:49Torneyou have to do offset math everywhere
21:21:58gevaertsEither that or have a compaction pointer recalculation callback
21:22:05gevaertsWhich will probably be buggy :)
21:22:10UnhelpfulTorne: yes. an idea i had for dealing w/ that is having things register a "move my block" callback. this would only be used for things using buffer_alloc now, ie things that we already expect not to change often. and any time compaction is run all such blocks would be moved to the bottom of the buffer so that allocations don't move them later.
21:23:11Torneright, if you keep tacking on magic handling and special cases you can make it work at great runtime cost, yes :)
21:37:11 Join phixxor [0] (~Patrick@pool-74-96-229-3.washdc.fios.verizon.net)
21:37:31phixxorjust so you know, songbird is really buggy on mac :(
21:37:59phixxorso don't recommend to use it with rockbox
21:39:37CIA-81New commit by 03torne (r28181): id3 parser: add id3v2.2 TPA tag for "part of set" as iTunes appears to use it
21:40:33*Torne fixes that guy's disc number parsing.
21:41:15Torne(in theory)
21:41:26CIA-81r28181 build result: All green
21:43:17 Quit powell14ski_ (Quit: powell14ski_)
21:44:10Tornehm, there's also only one entry for composer in there
21:46:19CIA-81New commit by 03torne (r28182): id3 parser: also add id3v2.2 TCM tag for "composer" since that's the only other tag not in there in 2.2 and 2.3 versions
21:46:27*Torne sticks that in there too. I'm sure someone will come back now and say i've broken tag parsing for something or other
21:46:59 Join giovanni_ [0] (~giovanni@93.37.244.180)
21:47:04pixelmahuh?
21:47:37n1sTorne: as long as you are just breaking id3, no prob ;)
21:47:47Tornewell i'd hope so ;)
21:48:13CIA-81r28182 build result: All green
21:52:33***Saving seen data "./dancer.seen"
21:55:18 Quit Buschel (Quit: ChatZilla 0.9.86 [Firefox 3.6.10/20100914125854])
21:59:19 Quit t0rc (Ping timeout: 240 seconds)
21:59:53 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201)
22:00
22:00:44 Join mt [0] (~mtee@rockbox/developer/mt)
22:02:59n1sheh metadata.c also calls id3_get_num_genre(36) i 3 places to set the genre to "Game" for some game soundtrack formats
22:03:40gevaertsProbably to make sure that string isn't duplicated
22:03:49n1si'd guess id3->genre_string = "Game"; is actually cheaper than id3->genre_string = id3_get_num_genre(36); in most situations
22:04:11n1swhat is the matter with duplicating the string, really
22:04:27gevaertsRight. It's only five bytes for the string
22:04:40 Join bug2000 [0] (~bug@unaffiliated/bug2000)
22:06:03bug2000saratoga_: May I bother you?
22:06:07n1ssince the uses are in the same function gcc should just use one constant string and set these poiners to that but all in all the savings would be small :)
22:07:00 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk)
22:08:42n1sbtw, shouldn't those genre strings be translated? :)
22:09:50 Join drizztbsd_ [0] (~quassel@82.84.121.151)
22:10:42 Quit drizztbsd (Ping timeout: 250 seconds)
22:13:39saratoga_bug2000: maybe
22:13:56gevaertsn1s: you're wrong :)
22:14:16gevaertsid3->genre_string = "Game"; is the same on arm, and more expensive on coldfire
22:14:17n1sgevaerts: ah, alright :)
22:14:21bug2000saratoga_: Just wanted to let you know that I finally had the time to check and update the bug report. Sorry for taking so long.
22:14:33saratoga_what bug report?
22:14:34n1sgevaerts: oh, about that
22:15:18gevaertsYes. I don't care about translating those strings
22:15:42bug2000saratoga_: The one with the Car AC adapter.
22:15:53saratoga_got a link?
22:15:53bug2000saratoga_: See? Took me so long to answer that you forgot %_%
22:15:57bug2000http://www.rockbox.org/tracker/task/11633]
22:15:57 Join drizztbsd [0] (~quassel@dynamic-adsl-78-12-183-116.clienti.tiscali.it)
22:16:01bug2000http://www.rockbox.org/tracker/task/11633
22:16:37saratoga_ok closed
22:16:50 Quit drizztbsd_ (Ping timeout: 272 seconds)
22:16:59saratoga_FWIW thats probably a ground a loop or similar between your car battery and your car stereo
22:17:17saratoga_or else a faulty AC adapter
22:17:26bug2000I checked it with 2 adapters.
22:17:38gevaertsAnd dropping that "genres" table would gain 2112 bytes
22:17:40bug2000So the car is a ted messed up?
22:18:00saratoga_the stereo may not be properly wired then, but I can't say
22:18:20bug2000I still find it weird, but who am I to know.
22:18:33*bug2000 feels a bit bad after opening 2 false bugs.
22:18:36saratoga_ground loops are very common with amplifiers
22:18:44bug2000I don't even know what it means.
22:18:48saratoga_thats why you get it with the car's amp but not your headphones
22:19:48bug2000I see, sorry for opening false bugs.
22:19:54bug2000I really love the project.
22:21:14 Part froggyman ("Bye")
22:21:59saratoga_no problem
22:23:47 Quit bmbl (Quit: Bye!)
22:28:02 Quit bertrik (Quit: :tiuQ)
22:31:20 Join Nausicaa [0] (~Nausicaa@c-71-239-58-153.hsd1.il.comcast.net)
22:33:46 Quit Jaykay (Ping timeout: 252 seconds)
22:34:55phixxorhow can I force reboot if rockbox is frozen?
22:37:18sudomanphixxor: what model?
22:37:42 Quit [sko] (Quit: Leaving.)
22:37:51phixxorclip+ but I got it to reboot. Hold down the power button for about 30 seconds
22:37:52sudomanyou can also check the manual
22:37:59 Quit n1s (Quit: Lmnar)
22:38:05sudomanthat's a long time :)
22:38:37phixxorthat's why I thought I was doing it wrong at first
22:46:47 Quit phixxor (Quit: Leaving)
22:49:05 Quit t0rc (Quit: Give someone code, help them with one project. Teach someone to code, help them rule the world.)
22:51:56 Quit simabeis (Quit: Lost terminal)
22:53:05 Quit dfkt (Quit: -= SysReset 2.53=- Sic gorgiamus allos subjectatos nunc.)
22:53:56 Quit sudoman (Ping timeout: 252 seconds)
22:54:23 Join stooo [0] (~sto@f051078134.adsl.alicedsl.de)
23:00
23:00:26 Quit pamaury (Remote host closed the connection)
23:00:39 Quit evilnick_B (Quit: Page closed)
23:02:20 Join Mindwin [0] (~mindwin@187-19-179-94.pool.ukrtel.net)
23:02:53 Join DerPapst [0] (~Alexander@p5797C6C6.dip.t-dialin.net)
23:03:09Mindwinhi, a want to share FM stations list for Kharkov/Ukraine
23:03:31Mindwinfor Rockbox.org
23:04:47Mindwini mean - http://www.rockbox.org/wiki/FmPresetsEurope
23:05:19gevaertsDid you register yourself on the wiki?
23:06:43Mindwinthere is a registration? i did not found it
23:06:46Mindwinhttp://files.myopera.com/MindWin/111/Ukraine-Kharkov-radio-stations-29-09-2010.fmr
23:06:58 Quit komputes (Remote host closed the connection)
23:08:00Mindwinfound )
23:08:47 Quit stooo (Ping timeout: 265 seconds)
23:09:58 Quit anewuser ()
23:12:15 Quit crow (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com ))
23:12:53MindwinAccess Denied
23:12:53MindwinAttention
23:12:53MindwinAccess check on Main.FmPresetsEurope failed. Action "CHANGE": access not allowed on web.
23:12:53DBUGEnqueued KICK Mindwin
23:12:53MindwinIf you recently registered here, have you asked to be added to the WikiUsersGroup yet? You cannot edit anything until you are. Ask, in IRC preferrably, an existing user to add you. This is done for spam reasons.
23:13:26AlexPWhat is your wikiname?
23:13:44MindwinYuryAntonov
23:14:49AlexPOK, done. No spamming now! :)
23:15:04MindwinAlexP: sure :)
23:15:47 Join kugel [0] (~kugel@46.115.51.168)
23:15:49 Quit kugel (Changing host)
23:15:49 Join kugel [0] (~kugel@rockbox/developer/kugel)
23:20:46 Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca)
23:21:35 Join clone4crw [0] (~calvin@97-86-227-168.dhcp.roch.mn.charter.com)
23:22:17 Join sudoman [0] (d8ecfce7@gateway/web/freenode/ip.216.236.252.231)
23:23:56 Join simabeis [0] (~simabeis@lobmenschen.de)
23:27:14 Join Barahir [0] (~jonathan@frnk-590fd4d5.pool.mediaWays.net)
23:27:36 Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de)
23:29:57 Quit Barahir_ (Read error: Operation timed out)
23:33:26wodzAlexP: would You mind testing new version of png viewer patch?
23:33:33 Quit giovanni_ (Quit: Sto andando via)
23:35:52 Quit clone4crw (Remote host closed the connection)
23:36:48Mindwinon my clip+ some .MPC (SV8) failed to play
23:36:59 Quit Barahir (Ping timeout: 240 seconds)
23:37:32Mindwini will test it again and give more information
23:41:09 Part Mindwin
23:45:39 Quit {phoenix} (Read error: Connection reset by peer)
23:47:57 Quit sudoman (Quit: Page closed)
23:50:58 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net)
23:52:37***Saving seen data "./dancer.seen"
23:55:44 Join bricks [0] (~43c9ffc8@giant.haxx.se)
23:55:56 Quit Jerom (Read error: Connection reset by peer)

Previous day | Next day