#rockbox 2010-09-28

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).

#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:34	saratoga	funman: (for the logs) have you seen this? http://forums.rockbox.org/index.php?topic=25809.msg172412
02:51:44	saratoga	apparently 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:54	supercollider	hello 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:40	JdGordon	does anyone object to me commiting this auto configure script thingy? and what would a good name for it be?
15:14:13	JdGordon	http://pastebin.com/PRSM8BNM
15:15:50		Join {-phoenix-} [0] (~dirk@p57AA4269.dip.t-dialin.net)
15:15:56		Quit alecsandru (Quit: � Ralph �)
15:18:31	JdGordon	^ that will guess the configure options for paths like e200-sim or sim/e200, or just e200 (and boot also)
15:18:41	JdGordon	any other styles that people might use can be added
15:20:05		Quit {phoenix} (Ping timeout: 272 seconds)
15:20:11	Llorean	So it looks for key terms in the path and uses that to determine the most likely target?
15:23:39	JdGordon	it looks at most 2 levels up the path, and guesses the target based on that (and the target shortname list)
15:25:00	Llorean	Sounds pretty reasonable to me, I guess.
15:25:50	JdGordon	im 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:59	CIA-81	New commit by jdgordon (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:49	CIA-81	r28180 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:30	saratoga	why 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:27	gevaerts	Wouldn't that require stopping playback to insert a track?
16:17:25	saratoga	the 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:41	gevaerts	Sure, but it's also allowed to throw those buffers away with little or no warning, and (in theory) to move them around
16:21:00	saratoga	can it really drop anything its buffered anytime? how does that work with album art
16:21:15	saratoga	or does the art get decoded to something not on the audio buffer?
16:21:43	gevaerts	anytime is a bit strong, but it gets dropped at least on "stop"
16:22:03	gevaerts	I think it's decoded to a the wps buffer. Ask Unhelpful for details :)
16:23:18	gevaerts	There'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:20	pixelma	just as a side-note, you are talking about swcodec buffering
16:25:47	gevaerts	yes
16:26:12	gevaerts	Although I still don't really understand why swcodec and hwcodec are different
16:29:21	Unhelpful	does hwcodec maybe use less space per buffer object for metadata? because the per-buffer-object header on swcodec iirc is quite large.
16:29:34	saratoga	looking at buffering.c they look the same, theres no HWCODEC anywhere in the file
16:29:42	saratoga	although playback.c is much different
16:33:12	pixelma	playback 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:40	pixelma	as in "it is impossible to do" I mean
16:35:02	Llorean	I seem to recall talk about unifying them in the past.
16:37:59	saratoga	loading the codec isn't much different on swcodec, you can disable it with one line of code
16:38:17	saratoga	then it doesn't get buffered, but rather just loads the .codec file on track change, spinning up if needed
16:38:42	n1s	hwcodec could actually benefit from that as it could then have wav playback as a codec
16:39:14	n1s	this has been discussed many times though and i think most people agree it would be good but noone wants to do it
16:39:34	saratoga	well its hard to be motivated to work on a 10 year old mp3 player
16:39:48	n1s	yes
16:40:09	n1s	even harder for a 10 year old player you don't even have
16:40:14	saratoga	that too
16:40:42	saratoga	i really need to find time to understand more about how buffering works
16:41:23	saratoga	if Nico is ever around again i'm going to bug him until he explains it to me
16:42:54	Unhelpful	the 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:40	Unhelpful	iirc 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:28	Unhelpful	aiui 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:52	Torne	Unhelpful: 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:13	Torne	Unhelpful: it'd only be much of a benefit when people's album art is big, though
17:34:47	Torne	hm, 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:11	phixxor	ok I know you are going to laugh at me
17:37:38	phixxor	but 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:12	phixxor	as ipods are to itunes, rockbox is to ___ ?
17:38:17	n1s	yes, the ones in the "stable" category on the front page
17:38:32	phixxor	that's not what I meant, sorry about being ambiguous
17:38:43	phixxor	not portable audioplayers, computer audio players
17:39:03	n1s	ah, then you have to define "work well" too
17:39:08	Llorean	Rockbox doesn't really need a PC side app for anything.
17:39:14	gevaerts	All audio managers that behave sensibly will work well with rockbox :)
17:39:23	phixxor	through MTC I assume?
17:39:31	phixxor	or whatever it is
17:39:35	Llorean	Depends on whether you mean MTP or MSC
17:39:41	phixxor	yeah :P which is it?
17:40:02	phixxor	MTP is the one audio mangers use, I think
17:40:04	Llorean	Well, Rockbox presents itself as MSC, but MTP is an abbreviation for something vaguely similar.
17:40:08	Unhelpful	Torne: decoded and converted to screen format.
17:40:26	Unhelpful	so 4bpp on greyscale, 16bpp on color
17:40:43	Unhelpful	Llorean: Media Transport Protocol i think
17:41:04	Torne	Unhelpful: that's not super big, but it's not tiny
17:41:09	Llorean	Unhelpful: Transfer, I thought
17:41:10	phixxor	By "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:14	Unhelpful	Llorean: might be :)
17:41:22	Llorean	Unhelpful: I just meant by "vaguely similar" that it's also used for getting songs onto gadgets.
17:41:25	Torne	phixxor: you should already be able to make playlists just by dragging and dropping them
17:41:45	phixxor	dragging what onto where?
17:41:49	Torne	playlist files
17:42:07	Llorean	phixxor: Rockbox works with standard M3U playlists.
17:42:09	n1s	phixxor: if you have the same dir structure on computer and DAP, your playlist should work in rockbox if they are m3u
17:42:11	Torne	if a playlist on the PC refers, to, say, e:\mp3\foo\bar.mp3
17:42:18	Unhelpful	Llorean: 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:24	Torne	then that playlist will work on Rockbox even if the structure on the player is just \foo\bar.mp3
17:42:32	Torne	Rockbox automatically strips directories fromt he front of the path until it matches
17:42:52	Llorean	Unhelpful: 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:54	Torne	so any media player tha tmakes standard m3u format playlists (virtually everything except itunes) should just work fine
17:43:14	Unhelpful	Torne: also scaled to their presentation dimensions, though, so if you have high-res jpeg AA the buffered AA might be smaller.
17:43:22	Torne	Unhelpful: that was what i was getting at
17:43:34	Torne	Unhelpful: the benefit is going tobe the same for everyone on a given player regardless of what their album art is like
17:43:47	Torne	well, a given theme
17:43:58	phixxor	Ok 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:24	Torne	right. so yes, lots of media player programs will do that
17:44:28	phixxor	So 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:31	Torne	there is nothing special about a rockbox device compared to anything else
17:44:35	phixxor	sweet :) I'm looking for one on mac
17:44:46	Torne	anything that works with a normal non-ipod mp3 player will just work
17:44:49	Torne	there 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:14	Unhelpful	so if i wanted an hour of white noise i guess. :P
17:45:19	Torne	Unhelpful: 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:58	phixxor	right 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:17	Torne	songbird is still being developed afaik
17:47:29	phixxor	oh, awesome :D
17:47:51	phixxor	I'll try that then. Thanks a lot for your help!
17:48:01	n1s	yeah, they just dropped the official linux support
17:48:51		Join Barahir_ [0] (~jonathan@frnk-590f7c32.pool.mediaWays.net)
17:49:04	phixxor	oh that's what it was :(
17:50:09	Unhelpful	Torne: 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:36	Unhelpful	this 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:53	Torne	it's still not veyr useful as a general allocator, though, because of its ringbufferness
17:50:58	Unhelpful	either a linked list as it is now, or list+index like buflib uses.
17:51:13	Unhelpful	well, if it's compactible you could actually get rid of all the wraparound-handling code, no?
17:51:28	Torne	i don't mean the wraparound specifically
17:51:34	Torne	i mean the fact that it always allocates at the end
17:51:48	Torne	for a wrapping value of "end"
17:51:52		Quit Barahir (Ping timeout: 276 seconds)
17:52:00	saratoga_	you could also just request space from the front of the ring, and shrink the size of the buffer
17:52:06	Unhelpful	oh. well, yes, but compaction does some good for that as well, since we can make all free space be at the "end"
17:52:08	Torne	i.e. you can't allocate anything on it whose lifetime is not between the lifetimes of the adjacent things
17:52:18	Torne	saratoga_: only for one thing
17:52:26	Torne	saratoga_: that doesn't extend to multiple things wanting to do allocations
17:52:28	***	Saving seen data "./dancer.seen"
17:52:30	saratoga_	why not?
17:52:46	Torne	because once you get three things allocated that way and then the middle one goes away you have a hole
17:52:46	saratoga_	each one just shrinks the buffer more, and creates a new "start"
17:52:57	Unhelpful	a tricky problem for compaction is that codecs may save pointers into their current buffer. :/
17:52:59	Torne	fragmentation increases over time
17:53:06	Torne	then you die
17:53:08	saratoga_	sure, but you can compact things
17:53:11	Unhelpful	Torne: hence the need for compaction. :)
17:53:19	Torne	but generally you can't compact things
17:53:24	Unhelpful	saratoga_: i don't think the bufer does right now.
17:53:42	Torne	because codecs can use pointers to anywhere in their buffer
17:53:46	Torne	and so on
17:54:20	*	Torne would, if we were going to go this way, seriously just implement the doug lea malloc().
17:54:23	Torne	:)
17:54:28	Torne	rather than worrying about compaction
17:54:34	saratoga_	AFAIK it can flush things and move them around now
17:54:39		Quit phixxor (Quit: Leaving)
17:54:45	saratoga_	i don't think we want malloc on the buffer
17:54:45	Torne	saratoga_: only up to the point that the codec has advanced the buffer pointer to
17:55:00	Torne	well no, we've always said we don't
17:55:05	Unhelpful	i don't think it can move them around all that much.
17:55:10	Torne	it doesn't move the data
17:55:12	Torne	it only moves the buffer heads
17:55:14	saratoga_	can't it just dump everything, zero the whole buffer, and rebuffer if things change?
17:55:24	Torne	yes, more or less.
17:55:24	saratoga_	i vaguely remember there was some case were that happened, but i forget what it might be
17:55:26	Unhelpful	saratoga_: that's a very costly sort of compaction. ;)
17:55:35	Unhelpful	AA size change forces rebuffer.
17:55:41	saratoga_	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:55	Torne	saratoga_: the problem is, as i said, if there is more than one of these things
17:55:57	saratoga_	probably once per boot, hopefully before audio starts playing :)
17:56:01	Torne	if there's several things that can be changed in size..
17:56:12	saratoga_	dump the whole buffer everytime and start from scratch?
17:56:20	Torne	You don't just have to dump the buffer, then
17:56:27	Torne	you would have to be able to dump all the things that can change size too
17:56:32	Torne	because they might need to mvoe as well
17:56:40	Torne	you'd effectively have to redo every single dynamic allocation
17:56:40	saratoga_	what do you mean change in size?
17:56:52	Torne	if you change the max playlist size, there might not be room to extend it inplace
17:56:59	Torne	because 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:03	Torne	even if you dump the whole buffer that won't go away
17:57:11	saratoga_	i assume everytime you changed the playlist size it would dump the whole buffer and reallocate everything
17:57:21	Torne	But the things that use buffer_alloc() are not in the buffer
17:57:25	Torne	they cannot be reallocated at all, at present
17:57:28	Torne	you don't even know what they are
17:57:34	Torne	at runtime, i mean :)
17:57:43	Torne	that memory is all permanently excised
17:57:58	Torne	so yes, for one thing you can easily make it resizable: buffer_alloc it last and then rebuffer when you change it
17:58:13	Torne	but when N things can be resized, even throwing away the contents of the buffer isn't sufficent to do that
17:58:29	Torne	you would need to, say, be able to throw away and recreate dircache, or tagcache, or whatever else might be in the way
17:58:48	saratoga_	don't you only have to dump the buffer on free?
17:59:07	Torne	no, see my earlier example
17:59:11	Torne	you buffer_alloc() three things
17:59:14	n1s	that 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:15	Torne	then you want to make the seocnd one bigger
17:59:20	Torne	how do you do that?
17:59:28	Torne	you need to throw away the third buffer_alloc'ed thing to make room.
17:59:34	saratoga_	ah i see what you mean
17:59:37	Torne	or else leave a hole that can never be reclaimed
17:59:56	Torne	So yeah, at this point you may as well give up and implement a decent low fragmentation malloc
18:00
18:00:07	Torne	and just use it for everything
18:00:23	saratoga_	so whats the alternative, put them in the ring buffer like audio tracks?
18:00:33	Torne	No, you can't do that either, because you'd have to skip over them
18:00:40	Torne	they'd be like, er, humps in the road on the ring
18:00:52	Torne	and that's malloc again.
18:00:54	Torne	:)
18:01:03	saratoga_	why is skipping over them a problem?
18:01:16	Torne	because the metadata to keep track of that is exactly the same metadata you need to implement malloc
18:01:23	Torne	so you might as well stop being a ring buffer and just be malloc.
18:01:51	saratoga_	i don't follow you
18:01:52	Torne	i'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:08	Torne	if 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:18	Torne	then the ring buffer may, in the worst case, need to jump over N seperate blocks of memory as it goes along
18:02:23	Torne	so you need to keep track of that data
18:02:31	Torne	and that data is exactly the same data that a malloc would keep and use.
18:02:32	saratoga_	i think it already does this?
18:02:39	Torne	what?
18:02:41	Torne	no it doesn't
18:02:43	saratoga_	since buffered objects currently can have different sizes
18:02:51	Torne	It keeps track of a single linked lits of objects
18:03:02	Torne	which are in memory order, modulo wraparound
18:03:06	saratoga_	we've already got a buffering API on the ring buffer that allows allocing and freeing randomly sized objects
18:03:09	Torne	and it only ever frees from the start and allocates on the end
18:03:15	n1s	how 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:44	Torne	n1s: yes, but that will probably neve rhappen
18:03:52	Torne	because a decent malloc is good at fragmentation avoidance
18:04:07	Torne	saratoga_: it doesn't allow allocing and freeing them in a random order
18:04:13	Torne	saratoga_: they can only be freed in playback order
18:04:29	Torne	so it works fine for codecs, tracks, album art, etc, which are accessed and disposed of in playback order.
18:04:31	n1s	Torne: in you previos use case it would i think, unless we modify the adio buffer to be discontigouos in some way
18:04:32	saratoga_	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:43	Torne	n1s: you wouldn't have an audio buffer
18:04:48	Torne	you would just malloc cells for audio data as well
18:04:56	Torne	and not be a ring buffer at all
18:05:29	Torne	you just need a clever trick in malloc to be able to request a range of sizes :)
18:05:36	Torne	"give me between 256kb and 32MB of memory"
18:05:40	n1s	Torne: 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:20	Torne	n1s: you ask the audio buffering system to free some up
18:06:30	Torne	or just keep track yourself of what is there
18:06:35	Torne	i'm not suggesting implementing this
18:06:58	saratoga_	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:59	Torne	i'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:59	n1s	well, it could probably work
18:07:23	Torne	i don't personally have a problem with buffer_alloc'ed stuff being fixed size until reboot.
18:08:10	n1s	the actual reboot is a bit overkill, just redoing the allocations and buffering data again should do
18:08:23	Torne	well yes, but currently we don't have a way of redoing the allocations
18:08:32	Torne	and supporting that is very close to just restarting
18:08:38	Torne	i guess you don't need to restart the actual hardware
18:08:51	Torne	but a huge proportion of the stuff done at boot time is allocating and then populating those buffers
18:08:54	Torne	dircache, tagcache, etc.
18:09:18	Torne	not having a buffer_free() is what makes our current system reasonable at all :)
18:09:19	n1s	the gigabeast in dualboot config takes fricking ages just to boot :(
18:09:58	n1s	Torne: i meant more like a buffer_throw_everything_away_and_start_over()
18:10:53	Torne	n1s: yes, i know
18:11:17	Torne	the max playlist size is the one that started this discussion, right?
18:11:28	n1s	i think so
18:11:29	Torne	how many things are there that you really care about being able to change without rebooting? I can see that one :)
18:11:41	n1s	max files in browser too
18:11:49	saratoga_	i just wondered why we even have such an odd setting
18:11:51	n1s	and the databse if it's in ram i think
18:12:01	Torne	heh
18:12:04	Torne	i guess the dircache too technically
18:12:11	Torne	since we currently allocate, what, 10% more space
18:12:18	saratoga_	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:22	Torne	so if you add more than 1/10 the number of files during usb the dircache breaks
18:12:33	n1s	saratoga_: 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:54	Torne	tbh i kinda have the outline of a hybrid malloc-and-buffering system in my hea dnow
18:12:57	Torne	damn you all
18:12:58		Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven)
18:12:59	n1s	also it's from way before the database
18:13:06	saratoga_	no i understand that, I'm just saying it seems like a poor design choice on our part
18:13:33	n1s	saratoga: what do you propose instead?
18:13:34	wodz	do we have bitmap scaling function but working on bitmap in native lcd format?
18:13:44	saratoga_	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:08	Torne	for malloc I guess what you'd do is have two tiers of allocation, and maintain the second tier as a ring
18:14:27	Torne	then 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:37	Torne	and when a codec starts using a buffer handle you lock it down as a real allocation
18:14:40	Torne	or similar :)
18:15:01	n1s	Torne: sounds reasonable to me
18:15:06	Torne	you could use quite a stupid actual malloc algorithm because all the blocks will be pretty big
18:15:12	Torne	we still wouldn't want to do the malloc(4) type thing
18:15:35	Torne	well, i guess you could for some stuff, not quite that small
18:15:37	Torne	but, say
18:15:45	Torne	i don't think there's any reason the dircache has to be a contiguous block of ram really
18:15:59	Torne	so you could possibly modify some of those systems to be expandible without needing realloc()
18:16:22	Torne	this is all getting into very controversial territory ;)
18:16:36	n1s	and if you don't need to alloc the extra 10% you also save memory
18:16:40	Torne	indeed
18:16:53	Torne	though again, you wouldn't want to do it incrementally really
18:16:54	saratoga_	i love seeing things like "#if MEM > 8" in buffering.c
18:17:03	saratoga_	fills me with confidence that the code is working correctly
18:17:06	Torne	you'd want to allocate another big lump after USB
18:17:24	Torne	you can always allocate too much and then prune it.
18:17:55	Torne	fragmentation is much easier to control while you're doing coarse grained cooperative multitasking
18:17:58	Torne	:)
18:18:12	Torne	since nobody comes in and uses gaps you create temporarily
18:19:45	Torne	bah, now i'm tempted to try and work out how to do this. damn you all.
18:21:52	saratoga_	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:07	saratoga_	err relocated, not reallocated
18:22:51	Torne	i don't see how that's possible with the cod ebeing anything like it is at the moment
18:23:14	saratoga_	because the data might be deleted on the buffer?
18:23:42	Torne	because of the strict ordering on the buffer. currently you'd need to move it every time the buffer wraps...
18:24:00	Torne	every time you free the thing before it, you'd want to reallocate and move it to the end
18:24:12	Torne	which would be.. often, on devices with small ram
18:25:14	saratoga_	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:35	Torne	the difference is it's long-lived
18:26:03	Torne	if 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:27	Torne	maintaining 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:42	saratoga_	whereas audio files would just be deleted and thus don't need to be moved?
18:27:01	Torne	indeed
18:27:21	Torne	Nothing currently in the audio buffer has a lifetime greater than one cycle around the buffer, by definition
18:27:33	Torne	sometimes things' lifetimes are less, if they get freed early
18:28:02		Join {phoenix} [0] (~dirk@p57AA4269.dip.t-dialin.net)
18:28:07	saratoga_	if repeat is on they do
18:28:13	Torne	No they don't
18:28:17	Torne	We had this discussion several time sbefore
18:28:23	Torne	if you turn repeat on, then the track data gets buffered multiple times
18:28:33	saratoga_	i'm pretty sure we don't rebuffer if the entire playlist fits in the buffer and its looping
18:28:36	Torne	Yes we do.
18:28:50	Torne	It buffers the playlist over and over until ram is full
18:28:55	Torne	even if that's just one track
18:29:00	Torne	then when it plays all that it does it again
18:29:16	Torne	i've had this discussion with people before, because i also assumed it worked sensibly
18:29:19	Torne	but it doesn't.
18:29:28	saratoga_	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:37	Torne	Because they also think the same wrong but obvious assumption
18:30:13	Torne	you can play a single track on repeat and you'll get the same battery bench results, in reality
18:30:38	Torne	If you cripple the audio buffer size and then just try it, watching the buffering screen, you'll see it do it
18:30:43	Torne	and feel the disk spin up each time
18:30:43	Torne	:)
18:31:26	Torne	so yes, currently no handle lasts for more than one cycle aorund the buffer.
18:31:57	Torne	the 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:08	Torne	if htat's not enough room it tries to move the first handle up to the current read position
18:32:15	Torne	but that only works if the codec has moved the read pointer up far enough
18:33:07	Torne	anyway. 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:13	Torne	i'm heading off for now.
18:34:40	saratoga_	hmm
18:34:52	saratoga_	i tried testing, but eventually it stopped changing tracks
18:34:58	saratoga_	and then threw a divide by 0 error
18:35:01	saratoga_	good game buffering system
18:36:17	saratoga_	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:16	gevaerts	saratoga_: we're not allowed to fix bugs? :)
18:37:57	saratoga	depends
18:38:04	saratoga	most fixes we've tried recently just broke other things
18:38:22	saratoga	e.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:21	Unhelpful	my 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:56	gevaerts	For 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:04	sudoman	could 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:46	preglow	android 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:07	Unhelpful	gevaerts: because it's not malloc? ;)
20:17:47		Quit guest (Quit: Page closed)
20:18:23	Unhelpful	we 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:10	Unhelpful	we 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:28	gevaerts	Unhelpful: actually, not entirely. With this scheme I can see that it won't die of fragmentation
20:20:00	gevaerts	While with a "standard" malloc, I have to believe Torne when he says that he thinks it won't :)
20:23:15	gevaerts	And 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:48	Torne	gevaerts: 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:14	Torne	gevaerts: 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:24	Torne	a complexity and codesize issue, quite possibly
20:55:29	Torne	which is why i'm not really advocating it
20:56:09	gevaerts	Torne: if you look at current buffer_alloc() behaviour, you'll see more than two or three dozen large blocks
20:56:22	gevaerts	There are some large blocks, yes, but also lots of small ones
20:56:25	Torne	i wasn't going to turn those into allocations
20:56:39	Torne	oh, hm
20:56:40	Torne	no, sorry, yeah
20:56:46	Torne	well maybe some of those are small, yes
20:56:59	Torne	but if there's no reason for them to change size at runtime then you don't care
20:57:08	Torne	:)
20:57:23	Torne	and are there really that many? i didn't think so..
20:57:31	gevaerts	I'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:04	Torne	haha silly git people, bzr-svn doesn't care
20:58:11	gevaerts	But anyway, I actually suspect lots of those do want to change size
20:58:12	Torne	actually. :)
20:58:34	Torne	hmm
20:59:05	gevaerts	Well, maybe not the small ones, but the amount of them might want to change :)
21:00
21:00:02	gevaerts	We have several settable limits arbitrary, and some non-settable ones. I'd say those are the majority of the buffer_alloc()s
21:00:13	gevaerts	Those are either too large or too small
21:00:45	Torne	there are 39
21:00:55	Torne	in total in the tree
21:01:05	Torne	i suspect not all of them are used on a given build
21:01:13	Torne	that's not a lot, tbh
21:01:35		Join [sko] [0] (~sko]@p57A9BA55.dip0.t-ipconnect.de)
21:01:38	gevaerts	One of the dircache ones isn't just called once
21:01:44	Torne	sure.
21:01:50	Torne	but that's uninteresting in total then
21:02:09	Torne	if you can tack on more chunks like that already you don't need to resize it with any other implemnetation either
21:02:14	Torne	so it doesn't cause fragmentation of memory
21:02:30	Torne	anything that needs to grow but doesn't need a contiguous chunk of ram is awesome
21:02:37	Torne	especially if there's also no reason for it to shrink
21:02:44	gevaerts	true
21:04:45	Torne	some of these can be optimised quite a bit by using the whole cooperative-multitasking thing
21:04:53	Torne	e.g. filetypes.c buffer_allocs a bunch of strings for extensions
21:05:17	Torne	but 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:07	Torne	sorry, i'm doing a very bad job of not really advocating this
21:06:12	gevaerts	:)
21:06:20	Torne	it just seems like less of a horrible hack than the other suggestions earlier
21:07:13	gevaerts	I 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:18	Torne	you need some way for it to be aware that you want to throw away some of its buffer handles
21:08:21	Torne	yes :)
21:09:15	gevaerts	And of course teaching things to handle noncontiguous memory would be a bonus
21:09:36	Torne	Yeah, there are probably other things that could be noncontiguous without adding particular overhead
21:09:52	Torne	things 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:53	Torne	those things could be made to grow without needing any new stuff
21:11:04	Torne	just kill playback, buffer_alloc a new chunk, and then rebuffer
21:11:26	Torne	only 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:58	Unhelpful	Torne: 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:58	Unhelpful	free handles before growing the handle table any more.
21:20:24	Torne	Unhelpful: the overhead is mostly in "not being able to store pointers to shit" though
21:20:43	Torne	not in the handle lookup
21:20:49	Torne	you have to do offset math everywhere
21:21:58	gevaerts	Either that or have a compaction pointer recalculation callback
21:22:05	gevaerts	Which will probably be buggy :)
21:22:10	Unhelpful	Torne: 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:11	Torne	right, 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:31	phixxor	just so you know, songbird is really buggy on mac :(
21:37:59	phixxor	so don't recommend to use it with rockbox
21:39:37	CIA-81	New commit by torne (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:15	Torne	(in theory)
21:41:26	CIA-81	r28181 build result: All green
21:43:17		Quit powell14ski_ (Quit: powell14ski_)
21:44:10	Torne	hm, there's also only one entry for composer in there
21:46:19	CIA-81	New commit by torne (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:04	pixelma	huh?
21:47:37	n1s	Torne: as long as you are just breaking id3, no prob ;)
21:47:47	Torne	well i'd hope so ;)
21:48:13	CIA-81	r28182 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:59	n1s	heh 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:40	gevaerts	Probably to make sure that string isn't duplicated
22:03:49	n1s	i'd guess id3->genre_string = "Game"; is actually cheaper than id3->genre_string = id3_get_num_genre(36); in most situations
22:04:11	n1s	what is the matter with duplicating the string, really
22:04:27	gevaerts	Right. It's only five bytes for the string
22:04:40		Join bug2000 [0] (~bug@unaffiliated/bug2000)
22:06:03	bug2000	saratoga_: May I bother you?
22:06:07	n1s	since 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:42	n1s	btw, 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:39	saratoga_	bug2000: maybe
22:13:56	gevaerts	n1s: you're wrong :)
22:14:16	gevaerts	id3->genre_string = "Game"; is the same on arm, and more expensive on coldfire
22:14:17	n1s	gevaerts: ah, alright :)
22:14:21	bug2000	saratoga_: 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:33	saratoga_	what bug report?
22:14:34	n1s	gevaerts: oh, about that
22:15:18	gevaerts	Yes. I don't care about translating those strings
22:15:42	bug2000	saratoga_: The one with the Car AC adapter.
22:15:53	saratoga_	got a link?
22:15:53	bug2000	saratoga_: See? Took me so long to answer that you forgot %_%
22:15:57	bug2000	http://www.rockbox.org/tracker/task/11633]
22:15:57		Join drizztbsd [0] (~quassel@dynamic-adsl-78-12-183-116.clienti.tiscali.it)
22:16:01	bug2000	http://www.rockbox.org/tracker/task/11633
22:16:37	saratoga_	ok closed
22:16:50		Quit drizztbsd_ (Ping timeout: 272 seconds)
22:16:59	saratoga_	FWIW thats probably a ground a loop or similar between your car battery and your car stereo
22:17:17	saratoga_	or else a faulty AC adapter
22:17:26	bug2000	I checked it with 2 adapters.
22:17:38	gevaerts	And dropping that "genres" table would gain 2112 bytes
22:17:40	bug2000	So the car is a ted messed up?
22:18:00	saratoga_	the stereo may not be properly wired then, but I can't say
22:18:20	bug2000	I 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:36	saratoga_	ground loops are very common with amplifiers
22:18:44	bug2000	I don't even know what it means.
22:18:48	saratoga_	thats why you get it with the car's amp but not your headphones
22:19:48	bug2000	I see, sorry for opening false bugs.
22:19:54	bug2000	I really love the project.
22:21:14		Part froggyman ("Bye")
22:21:59	saratoga_	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:55	phixxor	how can I force reboot if rockbox is frozen?
22:37:18	sudoman	phixxor: what model?
22:37:42		Quit [sko] (Quit: Leaving.)
22:37:51	phixxor	clip+ but I got it to reboot. Hold down the power button for about 30 seconds
22:37:52	sudoman	you can also check the manual
22:37:59		Quit n1s (Quit: L�mnar)
22:38:05	sudoman	that's a long time :)
22:38:37	phixxor	that'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:09	Mindwin	hi, a want to share FM stations list for Kharkov/Ukraine
23:03:31	Mindwin	for Rockbox.org
23:04:47	Mindwin	i mean - http://www.rockbox.org/wiki/FmPresetsEurope
23:05:19	gevaerts	Did you register yourself on the wiki?
23:06:43	Mindwin	there is a registration? i did not found it
23:06:46	Mindwin	http://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:00	Mindwin	found )
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:53	Mindwin	Access Denied
23:12:53	Mindwin	Attention
23:12:53	Mindwin	Access check on Main.FmPresetsEurope failed. Action "CHANGE": access not allowed on web.
23:12:53	DBUG	Enqueued KICK Mindwin
23:12:53	Mindwin	If 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:26	AlexP	What is your wikiname?
23:13:44	Mindwin	YuryAntonov
23:14:49	AlexP	OK, done. No spamming now! :)
23:15:04	Mindwin	AlexP: 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:26	wodz	AlexP: 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:48	Mindwin	on my clip+ some .MPC (SV8) failed to play
23:36:59		Quit Barahir (Ping timeout: 240 seconds)
23:37:32	Mindwin	i 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