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-03-10

00:01:29 Join alexbobp [0] (~alex@66.112.249.238)
00:03:30 Quit Tomis (Ping timeout: 245 seconds)
00:06:51 Join Tomis [0] (~Tomis@70.134.89.113)
00:07:14amiconnkugel: I wonder whether eabi gcc stumbles upon the packed structs
00:08:33kugelshort enums, rather
00:08:36kugelI think I found 1 problem
00:10:40kugeldoom seems to be accessing enums over pointers, which is always bad on eabi
00:10:55 Quit DataGhost (Ping timeout: 260 seconds)
00:11:02 Quit bertrik (Ping timeout: 265 seconds)
00:11:50gevaertsif that's true, I'd consider eabi to be broken
00:12:27pamauryI have a patch that get rid of the parent_dir structure in dir_uncached, I'll commit it tomorrow because I can't do it from here. Wasn't it you, kugel, the one who pointed out this fact ? It should save 28KiB on 512B/sector targets and around 80KiB on 2K/sector one(s?)
00:12:34amiconnAccessing enums via pointers isn't bad
00:13:15amiconnIt's just that programmers need to learn that each enum is a different type, which is not compatible with another enum
00:13:26kugelright
00:14:21kugelpamaury: no, I think you confuse me. I saw a different chance for saving but you fixed that already (IIRC)
00:14:26amiconnIirc I've read today that there is a gcc option (for arm eabi) to tell gcc to not use short enums. I wonder whether we should use that
00:14:52kugel-fno-short-enums
00:14:58kugelI'm not sure if that's the way to go
00:15:10pamaurykugel: ok, my mistake then. I'll have to check the logs to see who told that to me :)
00:15:26 Join moos [0] (moos@rockbox/staff/moos)
00:15:31amiconnI would prefer to avoid it if possible. But it might turn out to be impossible
00:16:13kugelamiconn: shouldn't we rather make the enums in question (if we really need to access them over pointer without knowing if it's the enum or not) __attribute__((aligned(4))) ?
00:16:21amiconnIs doom still actively maintained? There might be upstream fixes if so
00:16:36amiconnThat won't help
00:16:45pamauryamiconn: it was you, see ^
00:17:05amiconnIt would help to avoid crashes, but it will still not work right
00:17:05 Quit domonoky (Read error: Connection reset by peer)
00:18:22kugelwell, it now appears only doom is problematic. we can fix doom or be lazy. or is there any other place we're short enums are problematic?
00:19:12bluebrotherpixelma: nice to hear. I agree that rbutil shouldn't freeze with a wrong tts configuration −− do you have the old configuration still around? Did the configuration dialog show a "settings ok" for the tts settings?
00:19:33bluebrotherso this basically leaves the issue as "something is wrong with rbspeex on ppc".
00:19:45 Quit ender` (Quit: How long a minute is depends on which side of the bathroom door you are on.-- Theory of relativity)
00:20:34Unhelpfulkugel, amiconn: there is nothing whatsoever wrong with enum access via pointer on eabi if it's via a pointer to the correct enumtype.
00:20:45Unhelpfulunless there's a bug, anyway, ;)
00:20:49bluebrotherAlexP: can you check the output of pkg-config −−silence-errors −−libs speex speexdsp
00:21:12kugeldoom has one case where it's accessed over an int pointer
00:21:13Unhelpfulkugel: i did a lot of short enum fixes to get doom and mpegplayer compiling without warnings for them
00:21:13amiconn[00:13:16] <amiconn> It's just that programmers need to learn that each enum is a different type, which is not compatible with another enum
00:21:28AlexPbluebrother: "-lspeex -lspeexdsp"
00:21:39Unhelpfulkugel: then you need to fix that - either store enum values in an int, or use a pointer to the correct type.
00:21:44bluebrotherAlexP: can you check the version of libspeex?
00:22:13AlexP1.5.0 I think
00:22:14kugelUnhelpful: sure. but the latter isn't possible. couldn't the pointer be changed to a char * one?
00:23:06Unhelpfulkugel: but that breaks on long-enum builds. an enum-valued int is preferable if you simply must access via int*
00:23:23AlexPbluebrother: I looked at /usr/lib/libspeex.so for that
00:23:28kugelthe doom devs were clever to cast the enum address to void*, otherwise the e200 crash would've been revealed by "186: warning: initialization from incompatible pointer type" :D
00:23:33bluebrotherAlexP: huh? The speex website says that the most recent (unstable) release is 1.2rc1
00:23:48Unhelpfulamiconn: sorry, had missed that bit... also twasn't you said that would make eabi broken.
00:24:07AlexPbluebrother: ah right, speexdec gives 1.2rc1
00:24:14scorcheif anyone has any opinions or refinements for http://www.rockbox.org/wiki/GSoCOrgApp2010 , please feel free to go at it.
00:24:24AlexPbluebrother: I'm not sure how to get the library version directly?
00:24:49bluebrotherAlexP: no idea, I use my package manager for that ;-)
00:25:06AlexPspeex (which provides it all) is at 1.2rc1
00:25:08bluebrotherbut this is strange, 1.2rc1 should provide the required symbols in libspeex.so
00:25:08scorchesame goes for http://www.rockbox.org/wiki/GSoCApplicationTemplate2010 and http://www.rockbox.org/wiki/SummerOfCode2010 of course
00:25:35*bluebrother should consider setting up arch on a vm to try
00:25:43AlexPhehe :)
00:26:56bluebrotherneed to get some sleep for tonight. Will check that later. Please ping me if I forget about it.
00:27:05AlexPsure, thanks for looking :)
00:28:03amiconnkugel: Why can't you use the correct type?
00:28:47 Quit Schmogel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
00:28:58kugelit's accessed via int* in a generic struct (default_t)
00:29:51kugelit's a bit like our globa_settings struct
00:30:28 Quit Hillshum (Ping timeout: 265 seconds)
00:31:06 Quit dfkt_ (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.)
00:31:49 Quit endlesswonder ()
00:33:14 Quit pamaury (Quit: Page closed)
00:33:42 Quit froggyman (Read error: Connection reset by peer)
00:41:45 Quit CaptainKewllllll (Quit: Page closed)
00:43:30 Join Hillshum [0] (~hillshum@75-165-226-200.slkc.qwest.net)
00:44:27CIA-5New commit by 03amiconn (r25098): Coldfire targets: tiny optimisation.
00:51:12amiconnkugel: Where does that access happen?
00:52:00kugelm_misc.c:857
00:54:21Mode"#rockbox +o scorche" by ChanServ (ChanServ@services.)
00:54:56kugelthat casting to (void*) hides problems..
00:56:28 Join froggyman [0] (~sopgenort@pool-72-69-220-42.chi01.dsl-w.verizon.net)
00:56:34Topic"Please read before speaking: http://www.rockbox.org/wiki/IrcGuidelines | Please direct offtopic/social chat to #rockbox-community | This channel is logged at http://www.rockbox.org/irc | Rockbox is planning on applying for Google Summer of Code again - let's get working on the ideas list, etc" by scorche (~scorche@rockbox/administrator/scorche)
00:56:42Mode"#rockbox -o scorche" by ChanServ (ChanServ@services.)
00:59:03***Saving seen data "./dancer.seen"
00:59:30amiconnAh, default_compatibility_level and precache
00:59:50amiconnThe latter is a bool, but that will also cause problems if bools are byte-sized
01:00
01:00:01kugelisn't the same issue with bools in theory?
01:00:46kugelthe problem was exposed by the fact that default_compatibility_level comes directly after compatibility_level, which makes the address of default_compatibility_level unaligned
01:01:13kugelthere are even more
01:02:56 Join Tomis2 [0] (~Tomis@70.134.80.128)
01:05:20 Quit Tomis (Ping timeout: 248 seconds)
01:05:21 Nick Tomis2 is now known as Tomis (~Tomis@70.134.80.128)
01:06:02amiconnHmm, iiuc attribute((mode(word))) for the enums and bools in question *might* help
01:08:19kugelI have a patch which makes all dangerous variables int, but if I can hold it back if we want to go for that
01:08:46 Join earHurts01 [0] (~94814734@giant.haxx.se)
01:10:34earHurts01xxx
01:10:43earHurts01In a rockbox function, is it safe to allocate, say, 1500 bytes on the stack?
01:10:46amiconnAnother option would be to extend the enum in default_s to know all the various enum types, and change M_LoadDefaults to apply them accordingly
01:10:51earHurts01eg. char buffer[1024]; int otherstuff; int morestuff;
01:11:21amiconnI wonder why they have separate fields for the location pointer
01:12:11TheSevengevaerts: around?
01:12:13 Quit Farthen (Ping timeout: 276 seconds)
01:12:38 Quit advcomp2019 (Read error: Connection reset by peer)
01:12:41kugelwell, the enum in default_s is not used for casting to the appropriate pointer
01:12:45TheSevenah, damn
01:13:04TheSevenanyone else around who knows how rockbox handles usb mass storage transfers?
01:15:48amiconnkugel: It isn't, but it could be
01:17:45amiconnearHurts01: Depends on what else is on the stack, and in which thread you're doing this
01:20:17earHurts01assume I'm only calling file functions (lseek, read, write) and I'm in the main thread.
01:21:17earHurts01(is there a potable way to determine how much stack space is available in the current thread?)
01:22:07 Quit froggyman (Ping timeout: 245 seconds)
01:30:12earHurts01In docs/API, it says write() is not supported?
01:30:30earHurts01 int write(int fildes, const void *buf, size_t nbyte); NOT CURRENTLY SUPPORTED.
01:30:33 Join froggyman [0] (~sopgenort@pool-72-69-220-42.chi01.dsl-w.verizon.net)
01:30:34earHurts01????
01:31:42Unhelpfulamiconn: i've not seen that attribute... i had looked to see if perhaps unpacked might be recognized as doing that sort of thing to enum types.
01:34:05saratogaearHurts01: IIRC the main thread stack is several KB so thats probably safe
01:36:30earHurts01thanks
01:38:24kugelunfortunately, doom has more problems
01:40:33kugelZ_ChangeTag() is called with a NULL pointer, which leads to 0xFFFFFFF0 being written to. that freeezes on the e200, and causes a data abort on the fuze
01:42:13kugelthat happens when selecting the difficulty in freedoom.wad
01:43:19 Part froggyman
01:46:18 Quit banzairun (Quit: CGI:IRC (EOF))
01:49:01kugelit must be another short enum problem. doom functions fine with -fno-short-enums
01:54:35kugel__attribute__((mode(word))) makes an enum indeed 4byte wide
01:57:40earHurts01does rockbox have an int32 type?
01:59:47earHurts01ah, yes, in inttypes.h
02:00
02:03:29 Quit Stephen__ (Quit: Leaving)
02:14:01 Part toffe82
02:27:56 Quit Lss (Ping timeout: 264 seconds)
02:36:05 Join noob1 [0] (~ad15ebf0@giant.haxx.se)
02:37:23 Quit jd (Read error: Connection reset by peer)
02:37:38 Join jd [0] (~jd@modemcable207.134-202-24.mc.videotron.ca)
02:37:39 Quit jd (Changing host)
02:37:39 Join jd [0] (~jd@Wikipedia/HellDragon)
02:39:59 Join dys [0] (~andreas@krlh-5f72dafd.pool.mediaWays.net)
02:41:05 Quit noob1 (Quit: CGI:IRC (Ping timeout))
02:41:47 Quit MethoS- (Remote host closed the connection)
02:42:34 Join planetbeing__ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net)
02:44:07 Quit planetbeing_ (Ping timeout: 240 seconds)
02:47:17 Quit komputes (Read error: Connection reset by peer)
02:48:14kugelha! -fshort-enums to simulate eabi problems on the sim! :)
02:50:45 Quit Tomis (Quit: Tomis)
02:59:06***Saving seen data "./dancer.seen"
03:00
03:00:22 Quit alexbobp (Remote host closed the connection)
03:01:57 Join Tomis [0] (~Tomis@70.134.80.128)
03:02:31 Quit karashata (Quit: The fluffy dragon has left completely!)
03:08:06 Join karashata [0] (~karashata@74-220-162-11.wightman.ca)
03:09:20 Join toffe82 [0] (~chatzilla@ppp-71-138-16-137.dsl.frs2ca.pacbell.net)
03:22:14 Quit tmzt (Ping timeout: 245 seconds)
03:23:25 Join kimi-sharamin [0] (~karashata@74-220-162-11.wightman.ca)
03:23:36 Quit karashata (Read error: Connection reset by peer)
03:33:00 Join noob1 [0] (~ad15ebf0@giant.haxx.se)
03:35:44 Quit Sajber^ (Quit: Leaving.)
03:37:12 Quit kugel (Remote host closed the connection)
03:43:19 Quit Adnyxo (Ping timeout: 252 seconds)
03:47:53 Quit saratoga (Quit: Page closed)
04:00
04:00:45CIA-5New commit by 03theseven (r25099): iPod Nano 2G FTL performance enhancements. Still not quite as fast as the OFW, but way better than before.
04:01:04CIA-5New commit by 03theseven (r25100): Detect iPod Nano 2G charging state correctly
04:01:17 Nick kimi-sharamin is now known as karashata (~karashata@74-220-162-11.wightman.ca)
04:01:23 Join froggyman [0] (~sopgenort@pool-72-69-220-42.chi01.dsl-w.verizon.net)
04:05:18 Join chrisb [0] (~chrisb@pool-71-175-246-16.phlapa.east.verizon.net)
04:08:00 Quit anewuser ()
04:11:41CIA-5New commit by 03theseven (r25101): Fix bootloader red
04:16:47 Quit DaCapn (Read error: Operation timed out)
04:17:50froggymanis the most current, in depth list of players? http://www.rockbox.org/wiki/DeviceChart
04:17:55froggymanor is there a newer one?
04:19:00CIA-5New commit by 03theseven (r25102): Add the raw battery voltage to the Nano2G battery debug screen
04:19:57CIA-5New commit by 03theseven (r25103): Some Nano2G define corrections / updates
04:20:48 Join krazykit` [0] (~kkit@ppp-70-225-142-162.dsl.ipltin.ameritech.net)
04:20:50CIA-5New commit by 03theseven (r25104): Disable HID on Nano2G for now - it's causing some instability that needs to be debugged
04:21:28 Join jobec_ [0] (paulus@viherharakka.cs.tut.fi)
04:21:31 Join stavrob [0] (~sam@78-105-125-218.zone3.bethere.co.uk)
04:25:00 Join tmzt [0] (~tmzt@adsl-76-244-159-241.dsl.akrnoh.sbcglobal.net)
04:25:37 Quit krazykit (*.net *.split)
04:25:37 Quit Connor (*.net *.split)
04:25:37 Quit stavrob_ (*.net *.split)
04:25:37 Quit yosafbridge (*.net *.split)
04:25:37 Quit YPSY (*.net *.split)
04:25:37 Quit jobec (*.net *.split)
04:25:37 Quit soap (*.net *.split)
04:25:41 Quit karashata (Quit: The fluffy dragon has left completely!)
04:28:02 Join krazykit [0] (~kkit@ppp-70-225-142-162.dsl.ipltin.ameritech.net)
04:28:02 Join Connor [0] (~Connor@ip72-204-35-60.fv.ks.cox.net)
04:28:02 Join stavrob_ [0] (~sam@78-105-125-218.zone3.bethere.co.uk)
04:28:02 Join YPSY [0] (~ypsy@geekpadawan.de)
04:28:02 Join jobec [0] (paulus@viherharakka.cs.tut.fi)
04:28:02 Join soap [0] (~soap@rockbox/staff/soap)
04:28:38 Join yosafbridge [0] (~yosafbrid@li14-39.members.linode.com)
04:28:46 Quit krazykit (Ping timeout: 277 seconds)
04:28:46 Quit stavrob_ (Ping timeout: 277 seconds)
04:28:46 Quit jobec (Ping timeout: 277 seconds)
04:37:40 Quit mc2739 (Ping timeout: 245 seconds)
04:38:18 Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de ))
04:39:33 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739)
04:39:56 Quit TheSeven (Disconnected by services)
04:40:09 Join The_Seven [0] (~theseven@rockbox/developer/TheSeven)
04:40:18 Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven)
04:42:19froggymanis the most current, in depth list of players? http://www.rockbox.org/wiki/DeviceChart or is there a newer one?
04:48:57krazykit`it's missing the nano2g and a couple of scarcer targets
04:49:38krazykit`er, and the AMS sansas
04:50:57 Join saratoga_lab [0] (~9803c255@gateway/web/freenode/x-jxukfravxprarxsy)
04:51:06saratoga_labfroggyman: the current_status wiki page is probably a lot better
04:51:09LloreanThe most up to date list of targers is /tools/configure
04:51:13Llorean*targets
04:51:25LloreanJust see what you can build for, and there you go. :)
04:52:01*Llorean wonders if all the lowmem work that was done for the Clip might make the iFP a more realistic potential target again.
04:52:41froggymanLlorean: i'm looking for a player to buy, and wanted to get a HW comparison page, like the device chart
04:52:43 Join Barahir_ [0] (~jonathan@gssn-5f75443b.pool.mediaWays.net)
04:52:47*froggyman will look around
04:53:28 Quit noob1 (Quit: CGI:IRC (EOF))
04:53:38Hillshumfroggyman: The Buyer's Guide wiki page? Don't know how uptodate that is
04:54:32 Quit dys (Ping timeout: 276 seconds)
04:54:50saratoga_labLlorean: probably not, the Clip has 2.3x the RAM
04:54:59 Join dys [0] (~andreas@krlh-5f72e2f8.pool.mediaWays.net)
04:55:09saratoga_labat least i think the ifp was a 1 MB swcodec target
04:55:13LloreanYeah
04:55:19LloreanAt one point Rockbox was actually playing music on it though
04:55:51LloreanIf it can be made to compile again, I imagine a lot more of the codecs will fit in the buffer than did back then
04:55:59saratoga_labwe're probably bloated way past that :)
04:56:00 Quit Barahir (Ping timeout: 256 seconds)
04:56:20saratoga_labi guess it depends how much of the core you can ifdef out
04:56:33LloreanProbably strip it down to more or less what the Recorder gets
04:56:49LloreanAnd since it's flash, it doesn't need much buffer.
04:57:36JdGordonwait, did it ever play music? I thought it didnt
04:57:49saratoga_labit could play vorbis at one point I think
04:57:54saratoga_labjust not very well
04:58:15saratoga_laband probably only a subset of vorbis encoding options
04:58:18LloreanJdGordon: It did in the "ladies and gentlemen, we have sound" sense, but not the "it could have been considered 'unstable' by today's standards" sense, I think
04:58:52LloreanA lot of our old ARM Vorbis optimizations came from trying to get it realtime on the iFP, which is why Vorbis was decent when we got iPod support
04:59:05LloreanSince it's some 60mhz Panasonic CPU
04:59:09***Saving seen data "./dancer.seen"
05:00
05:02:49saratoga_labwow the ifp emulator tomal wrote worked as a GDB stub
05:03:52LloreanWould that be a starting place for the ARM emulator summer of code project idea?
05:04:43saratoga_labyeah that or Toni's emulator
05:04:47saratoga_labor skyeye
05:04:50saratoga_labany would work
05:05:18saratoga_labapparently the ifp had an 8MB NOR ROM memory mapped, so i guess playback would be pretty easy if you figured out how to flash that
05:05:35saratoga_labjust put the binary in ROM and you'd have plenty of RAM
05:05:39Llorean8MB ROM and 1MB RAM?
05:05:43LloreanOr is it 8 megabit?
05:05:44saratoga_labyeah
05:06:01saratoga_labah mbit
05:06:09saratoga_labbut still big enough
05:06:13LloreanYeah
05:06:44*chrisb embedded among the embedded
05:08:05 Quit planetbeing (Ping timeout: 245 seconds)
05:08:06 Nick planetbeing__ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net)
05:09:57 Quit foaly_ (Ping timeout: 276 seconds)
05:12:30 Part froggyman
05:24:56 Join toffe82_ [0] (~chatzilla@ppp-71-130-77-69.dsl.frs2ca.pacbell.net)
05:26:18 Quit toffe82 (Ping timeout: 245 seconds)
05:31:31 Quit Horscht (Quit: Verlassend)
05:32:45 Quit JdGordon (Ping timeout: 264 seconds)
05:33:57 Quit Marctraider (Ping timeout: 264 seconds)
05:35:52 Join alexbobp [0] (~alex@66.112.249.238)
05:38:52 Join Marctraider [0] (~marctraid@82-170-60-93.ip.telfort.nl)
05:43:15 Join grndslm [0] (~grndslm@174-126-14-4.cpe.cableone.net)
05:43:44 Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net)
05:44:02 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
05:45:03 Quit planetbeing (Ping timeout: 276 seconds)
05:45:03 Nick planetbeing_ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net)
05:50:06 Quit CGL (Quit: Saliendo)
05:52:17 Join CGL [0] (~CGL@190.79.151.231)
05:57:43 Join Rob2222 [0] (~Miranda@p4FDCA39D.dip.t-dialin.net)
05:59:00 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon)
05:59:18 Quit saratoga_lab (Quit: Page closed)
06:00
06:01:13 Quit earHurts01 (Quit: CGI:IRC (EOF))
06:01:28 Quit Rob2223 (Ping timeout: 265 seconds)
06:03:27 Join FOAD_ [0] (~dok@dinah.blub.net)
06:04:47 Quit FOAD (Read error: Operation timed out)
06:04:47 Nick FOAD_ is now known as FOAD (~dok@dinah.blub.net)
06:18:38 Join Eq-547-682-357 [0] (~chatzilla@pool-96-231-22-103.washdc.fios.verizon.net)
06:19:06Eq-547-682-357Quick question
06:19:28Eq-547-682-357I'm using rockbox after ages
06:19:42Eq-547-682-357Where should I drag and drop my files on the drive?
06:19:55HillshumAfter ages?
06:19:56Eq-547-682-357Is it inside the .rockbox folder or outside?
06:20:02HillshumWhat files?
06:20:06Eq-547-682-357Music files
06:20:11Eq-547-682-357yeah broke my old ipod
06:20:16Eq-547-682-357got a new one
06:21:35HillshumYou can put the files anywhere
06:21:47Eq-547-682-357Ah
06:21:51Eq-547-682-357kk
06:22:00HillshumProbably best to keep them in a folder dedicated to music, outside the .rockbox folder
06:22:25Eq-547-682-357That's what I was thinking..I was wondering if the files won't be detected if it was outside the .rockbox folder
06:22:28Eq-547-682-357danke danke
06:24:14 Quit Torne (Ping timeout: 276 seconds)
06:24:17 Join Torne [0] (torne@rockbox/developer/Torne)
06:28:12HillshumThe database will ignore them if inside the .rockbox folder
06:33:02 Quit leavittx (Read error: Operation timed out)
06:36:08 Quit Hillshum (Ping timeout: 240 seconds)
06:37:28 Part Eq-547-682-357
06:43:31 Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net)
06:46:02 Join webguest [0] (~be1b4534@giant.haxx.se)
06:46:09 Quit planetbeing (Ping timeout: 276 seconds)
06:46:10 Nick planetbeing_ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net)
06:47:32 Quit webguest (Client Quit)
06:48:55 Join leavittx [0] (~leavittx@89.221.199.187)
06:50:40 Join Hillshum [0] (~hillshum@75-165-226-200.slkc.qwest.net)
06:52:39 Quit toffe82_ (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158])
06:52:55 Join toffe82 [0] (~chatzilla@ppp-71-130-77-69.dsl.frs2ca.pacbell.net)
06:53:27 Quit toffe82 (Client Quit)
06:55:42pixelmabluebrother: I don't think I have the non-working configuration around still but I'll try to reproduce. Your summary is slightly wrong and has one thing I can't answer... rbspeex/RbUtil doesn't work correctly on the 10.4 boxes I tried - that means both PPC and Intel. It works correctly on a 10.5 Intel but I can't tell anything about a 10.5 PPC as there is none available where I'm at
06:57:48Tomisi have a 10.5 ppc pixelma, the bootload installer is broken for nano 2g, the rockbox installer seams towork fine though
06:58:41pixelmawith installer you mean the Rockbox Utility?
06:59:01Tomisyes
06:59:11***Saving seen data "./dancer.seen"
06:59:46pixelmadid you ever try to generate voice files or talk clips for your target?
07:00
07:00:10Tomisnope
07:00:52pixelmaI'm not sure though if bluebrother's work for using the inbuilt Apple TTS is already in SVN but maybe you can ask him and help out testing later
07:02:13pixelmathat's what I was testing. With 10.4 I only get talk files that play but aren't recognisable, on the 10.5 Intel box everything was fine
07:02:24Tomisapple TTS to file can be operated from the shell via applescript
07:03:05 Quit arbingordon (Read error: Connection reset by peer)
07:03:29 Join arbingordon [0] (~w@c-71-226-248-30.hsd1.pa.comcast.net)
07:07:21pixelmanot sure how he uses it but the goal is to access it from the Utility to make files that can be used with Rockbox's voice system. That means they need to be transcoded to MP3 for the hardwarecodec (Archos) targets, which works and uses an external lame encoder - and a special speex file for the other swcodec targets which doesn't work completely and is using rbspeex (a Rockbox tool)
07:08:17pixelmathe latter seems to be the culprit on 10.4 as I also get noise when encoding and decoding files with a stansalone rbspeex
07:08:26pixelmastandalone too
07:10:56Tomisyea i think apple's TTS to file outputs .aiff
07:14:17pixelmawith the Utility you also get an easy to use UI - browse to the files/directories you want to have talk files for and let it "generate talk files" or just let it generate a voice file for your target
07:18:45 Join Farthen [0] (~chatzilla@e179233050.adsl.alicedsl.de)
07:21:50 Quit liar (Ping timeout: 245 seconds)
07:43:18 Quit arbingordon (Quit: `)
07:43:41 Join arbingordon [0] (~w@c-71-226-248-30.hsd1.pa.comcast.net)
07:45:55pixelmaTomis: how did you install the bootloader then?
07:46:15Tomisused iLoader
07:59:38 Quit MagusG (Ping timeout: 252 seconds)
08:00
08:00:10 Quit Tomis (Ping timeout: 245 seconds)
08:00:11 Join Tomis [0] (~Tomis@70.134.66.208)
08:13:57 Join Buschel [0] (~ab@p54A3EBC1.dip.t-dialin.net)
08:22:39 Join nosa- [0] (~nosa-@adsl-235-26-159.clt.bellsouth.net)
08:23:53nosa-hello there there is a port for the nano 2g and i was wondering if the same tools can be used on the 4th gen cronomatic?
08:31:57 Join ender` [0] (krneki@foo.eternallybored.org)
08:31:58Tomishttp://build.rockbox.org/ nosa-
08:32:30Tomisthat's the "current build" link at the top left of the rockbox website
08:33:30nosa-ahh ok
08:41:03 Join Regika [0] (~Shawnboy1@adsl-75-19-46-151.dsl.irvnca.sbcglobal.net)
08:41:19RegikaAnyone here?
08:43:46 Quit Regika (Client Quit)
08:44:53 Join flydutch [0] (~flydutch@host83-164-dynamic.15-87-r.retail.telecomitalia.it)
08:47:53 Join Zagor [0] (~bjst@rockbox/developer/Zagor)
08:49:43 Quit Buschel ()
08:59:14***Saving seen data "./dancer.seen"
09:00
09:03:32 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
09:05:05 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk)
09:08:25 Join LinusN [0] (~linus@rockbox/developer/LinusN)
09:15:35 Quit stripwax (Quit: http://miranda-im.org)
09:17:24 Quit chaos (Ping timeout: 260 seconds)
09:19:25 Part LinusN
09:19:44 Quit einhirn (Ping timeout: 260 seconds)
09:21:19 Join petur [0] (~petur@rockbox/developer/petur)
09:22:07 Join part_ [0] (~part@atari.org)
09:24:16 Quit part (Ping timeout: 256 seconds)
09:24:16 Quit JdGordon (Ping timeout: 256 seconds)
09:24:21 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon)
09:24:37 Quit planetbeing (Quit: planetbeing)
09:27:59 Join chaos [0] (~chaos@gentoo/user/ch4os)
09:29:21 Quit ps-auxw (Ping timeout: 248 seconds)
09:31:15 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
09:32:54 Join HellDragon_ [0] (~jd@modemcable207.134-202-24.mc.videotron.ca)
09:32:55 Quit HellDragon_ (Changing host)
09:32:55 Join HellDragon_ [0] (~jd@Wikipedia/HellDragon)
09:33:46 Join liar [0] (~liar@213162066173.public.t-mobile.at)
09:33:57 Quit einhirn (Read error: Connection reset by peer)
09:35:26 Quit jd (Ping timeout: 258 seconds)
09:35:53 Join jd [0] (~jd@modemcable207.134-202-24.mc.videotron.ca)
09:35:53 Quit jd (Changing host)
09:35:53 Join jd [0] (~jd@Wikipedia/HellDragon)
09:36:13 Quit liar (Read error: Connection reset by peer)
09:36:23 Join liar [0] (~liar@213142127112.public.telering.at)
09:36:40 Join ps-auxw [0] (~arneb@p4FF7F603.dip.t-dialin.net)
09:36:49 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
09:38:15*scorche hands everyone a cup of coffee and funnels attention towards efforts to make us more appealing for GSoC
09:38:53 Quit HellDragon_ (Ping timeout: 258 seconds)
09:39:32 Join DerPapst [0] (~DerPapst@p5099d40e.dip0.t-ipconnect.de)
09:42:18 Join pamaury [0] (~pamaury@sphinx.lix.polytechnique.fr)
09:42:19 Quit pamaury (Client Quit)
09:42:22 Join pamaury [0] (~pamaury@sphinx.lix.polytechnique.fr)
09:45:47 Quit jd (Read error: Connection reset by peer)
09:46:14 Join jd [0] (~jd@modemcable207.134-202-24.mc.videotron.ca)
09:46:14 Quit jd (Changing host)
09:46:15 Join jd [0] (~jd@Wikipedia/HellDragon)
09:50:23 Quit einhirn (Ping timeout: 258 seconds)
09:51:53 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
09:55:42 Join Sajber^ [0] (~Sajber^@92-29.anonymous.at.anonine.com)
09:56:30CIA-5New commit by 03pamaury (r25105): Get rid of the parent_dir field in dir_uncached.c by using the same FAT trick as in dircache. This should save ~20KB on 512B/sector targets and ~80KB ...
09:58:50 Quit einhirn (Read error: Connection reset by peer)
10:00
10:01:11 Quit pamaury (Changing host)
10:01:12 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
10:01:24 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
10:05:25 Join nimak [0] (~nima@adsl-75-45-227-30.dsl.sfldmi.sbcglobal.net)
10:06:36 Quit nima (Read error: Connection reset by peer)
10:07:40pamaurybuild server doesn't work ?
10:13:28 Quit GodEater (Read error: Operation timed out)
10:17:37Zagorpamaury: checking...
10:18:18Zagorsomething happened with the network. "Ending round due to lack of clients"
10:18:30ZagorI'll restart the round
10:19:01 Join efyx_ [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net)
10:21:10Zagorhmm, something is broken
10:22:04 Join mt [0] (~mtee@rockbox/developer/mt)
10:23:49mtI was wondering if we could add completing the new website to the gsoc ideas list, or building a whole new design ?
10:25:06gevaertsmt: in principle, yes. I'm afraid that the website rework will attract lots of people with very questionable ability though
10:26:52pamauryDid you give up the loadable usb driver idea ? It was in last gsoc, no ?
10:27:09 Quit einhirn (Ping timeout: 276 seconds)
10:28:02gevaertsI'd still like that, but it depends (in my mind at least) on address-independent plugin loading
10:28:10gevaertsOtherwise it doesn't really fix anything
10:28:29pamauryindeed
10:28:42pamauryor it depends on relocations
10:29:40gevaertsAdding a coff or elf loader or getting elf2flt to work for rockbox might be a fun project though
10:29:57pamaurywhat is elf2flt ?
10:30:06*gevaerts doesn't really know how much work those would be
10:30:19gevaertshttp://www.uclinux.org/bFLT/
10:30:34mtgevaerts : Yes, I thought it would do just that, but they could be filtered with a good qualifying task.
10:30:52pamauryLoading it is not too difficult but the "problem" is that usually symbols are resolved at load time so you must have an expensive sym->addr table
10:31:00pamauryBut this table can be put in a file I guess
10:31:51gevaertsmt: maybe. I'm not convinced though
10:32:45mtI'm not really into web development to know how much coding would be needed for it to qualify as a coding project though.
10:33:07pixelmaand I'm also not convinced by the "new" design
10:33:55pamaurygevaerts: interesting, perhaps there is something to do then, instead of reinventing the wheel. Does this file format supports all kind of relocations that one can find with ARM, coldfire, ... ?
10:33:58mtpixelma: You mean the idea itself ? Or the specific new design that was started on the forums ?
10:34:18gevaertspamaury: I haven;t investigated it very much yet
10:34:26pixelmathe latter
10:35:35pamaurygevaerts: if had time, I would like to investigate but I already have several projects running :) I don't know if it requires lots of work or not. One day perhaps
10:36:48pixelmaand I was even looking at the code and it looked like it needed a lot of cleanup - many many "hardcoded" things (fontsizes etc.)
10:37:40 Quit Marctraider (Ping timeout: 260 seconds)
10:38:15 Join Marctraider [0] (~marctraid@82-170-60-93.ip.telfort.nl)
10:38:37mtIf a new design qualifies as a gsoc project in the first place, the task could be to start a whole new design, and we could make it clear that building upon the one in the forums is unacceptable. Provided enough people here agree on that of course.
10:39:45mtI haven't looked at that design's code to judge. But hardcoded stuff like that is definitely not good. At least imo. :)
10:48:10linuxstbmt: I don't think our website could be categorised as a coding project... The majority of the work will be the design and reorganising the content.
10:48:50linuxstbPlus of course dealing with everyone complaining about it and trying to reach a concensus...
10:49:02pamaurywhich is not coding...
10:49:27pamaurybut happens in any coding task also :)
10:49:51linuxstbThat's true... ;)
10:51:06mtAlthough a consensus on how a specific driver works entails much less hassle than that regarding the website. :)
10:51:53pamauryIndeed, you just have to be obscure enough to have the others say wait&see.
10:52:01pamaury;-)
10:52:39mtlinuxstb: I wasn't sure about how much coding is required. But if it's mainly design, then yes it wouldn't qualify for gsoc.
10:53:32mtpamaury: Should work .. :)
10:54:28 Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net)
10:57:32 Join LinusN [0] (~linus@rockbox/developer/LinusN)
10:59:16***Saving seen data "./dancer.seen"
11:00
11:00:34 Join hebz0rl [0] (~hebz0rl@dslb-088-065-214-184.pools.arcor-ip.net)
11:02:23 Join patgodo [0] (~chatzilla@f053042201.adsl.alicedsl.de)
11:02:59 Part patgodo
11:04:28 Quit pamaury (Remote host closed the connection)
11:06:54 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
11:10:33 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
11:16:01 Join Tuplis [0] (~jani@adsl-77-109-221-158.kymp.net)
11:18:25pamaurynice green delta, hope I didn't break anything :)
11:25:04pamaurygevaerts: I just had a look at bFLT but I'm not sure it's adapted to what we would dream of. There are several ways to do things of course but say we want to allow a usb driver (or anything else) to access any function of the core without having a rb-like structure growing exponentially, we need to support dynamic symbols and this bFLT doesn't have it.
11:26:34gevaertspamaury: I don't see a need to drop the rb-like structure
11:32:20pamaurygevaerts: That's just a thought. A rb-like structure has the advantage that there is only one copy of it. But it has some drawbacks: it can be huge if you want to support all possible functions and every time you need access to a function/field, you need to add functions to it. Whereas it you use a symbol table (that you can load at load time and then drop in some way), you have one table per plugin (greater ram usage) but it's transparent.
11:33:05pamauryOf course, the the symbol table approach requires more work so more code so increase binsize :)
11:36:48gevaertsthe symbol table approach would also need the full table somewhere
11:37:05gevaertsrb doesn't need a copy per plugin
11:37:06pamauryYou can store it in a file
11:37:11 Quit einhirn (Read error: Connection reset by peer)
11:37:46gevaertsThe code to handle that will be bigger than just having the table
11:38:02pamauryperhaps :)
11:39:20gevaertsAnyway, the issue of whether or not to also make iram relocatable (and/or optional...) and how to do that is going to be a lot more important I think
11:40:04pamaurymake iram relocatable ?
11:40:06 Join MethoS- [0] (~clemens@134.102.106.250)
11:40:34 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
11:41:14gevaertsOne of the main reasons for all this is to allow multiple plugins at the same time. If such plugins use iram, their iram use needs to be managed
11:42:05pamauryyes. currently, how do plugins use iram ? There is a reserved region no ?
11:42:11gevaertsyes
11:42:54gevaertsWe also have to be careful with relocation and iram. We don't want to slow down iram use
11:44:28pamauryI don't see the problem. The goal of relocations is to avoid indirection, so iram accessed shouldn't be slowed down by relocations.
11:48:46pamauryAnyway, multiple plugins means managing iram and also the place where plugins are loaded (audio buffer ?)
11:49:13gevaertsYes, it means a lot of things :)
11:50:16pamauryis the audio buffer contiguous or does it support being split ?
11:50:26pamaury(I mean the part used for buffering)
11:50:45 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019)
11:53:19mtpamaury : This might help - http://www.rockbox.org/mail/archive/rockbox-dev-archive-2009-07/0166.shtml
11:53:30 Quit advcomp2019 (Ping timeout: 245 seconds)
11:55:03CIA-5New commit by 03uchida (r25106): unify the wave/wave64 parser.
11:56:19 Join lasser [0] (~chatzilla@p57B58FCA.dip0.t-ipconnect.de)
11:57:53 Quit lasser (Client Quit)
12:00
12:04:02 Join Kitr88 [0] (Kitr88@BSN-182-27-115.dial-up.dsl.siol.net)
12:06:22 Quit Kitar|st (Ping timeout: 265 seconds)
12:12:11 Join watto [0] (~watto@193.203.81.165)
12:15:29 Nick jobec_ is now known as jobec (paulus@viherharakka.cs.tut.fi)
12:19:19CIA-5New commit by 03uchida (r25107): Oops. forget static.
12:24:28gevaertsZagor: builds seem to have stopped again
12:24:42Zagoryes, I'm tweaking it
12:29:04 Join robin0800 [0] (~quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com)
12:39:17 Join dfkt [0] (dfkt@unaffiliated/dfkt)
12:52:10 Quit CGL (Ping timeout: 240 seconds)
12:52:53TheSevengevaerts: how do ums transfers in rockbox work? i read something about write double buffering in the code, so can the host really send the next transfer while the last one is still being processed by the storage apis?
12:53:10 Quit watto (Ping timeout: 240 seconds)
12:53:43TheSevenI'm trying to do USB profiling on nano2g to figure out what's causing it to be still way slower than the apple firmware, even with the recent performance tweaks
12:56:48 Nick krazykit` is now known as krazykit (~kkit@ppp-70-225-142-162.dsl.ipltin.ameritech.net)
12:58:11 Quit perfectdrug (Read error: Connection reset by peer)
12:59:20***Saving seen data "./dancer.seen"
13:00
13:06:43 Join punkt [0] (~c2723e48@giant.haxx.se)
13:11:52 Part LinusN
13:15:05 Join LinusN [0] (~linus@rockbox/developer/LinusN)
13:15:11 Part LinusN
13:16:57 Join n1s [0] (~n1s@rockbox/developer/n1s)
13:33:43 Join notlistening [0] (~tom@iatech-adsl.demon.co.uk)
13:34:21notlisteningRight a question on GSoC how big and technical do the projects need to be?
13:35:27 Quit grndslm (Quit: Leaving)
13:35:30linuxstbthree months full-time work...
13:35:42linuxstb(or maybe two months, I forget...)
13:36:30notlisteningI just had an idea about voice tagging of the recordings you can make with rockbox. Not a massive amount of work but a viable feature non the less?
13:37:03notlisteningnot two months works i guess
13:37:19gevaertsTheSeven: let me check the details...
13:37:23notlisteninglol maybe for me
13:38:38TheSevengevaerts: I've done some profiling now, and it seems like the FTL is busy about 88% of the time, which looks quite ok
13:40:23TheSevenwhat is disturbing me a bit is that it is using CPU 54% of the time (and thus waiting for the hardware only 46% of the time)
13:40:37gevaertsTheSeven: you might want to play with WRITE_BUFFER_SIZE in usb_storage.c
13:40:58TheSeveni already set that to 64K to prevent that 24K/24K/8K splitting
13:41:25TheSevenhaven't measured the impact of that
13:41:50 Quit mt (Ping timeout: 240 seconds)
13:41:58TheSevenlet me check
13:42:18gevaertsThe "problem" is that 64K is also the usual USB transfer size, so you can't really buffer more and still guarantee the same reliability
13:42:20TheSevenhm, NAND is only active 64% of the FTL busy time
13:45:05gevaertsTheSeven: you might want to look at FS #10239. Unfortunately I suspect that it doesn't apply cleanly anymore...
13:45:11TheSeven24k vs. 64k => 16% performance difference
13:45:30TheSeventhat buffer is allocated from the audio buffer anyways, isn't it?
13:45:44AlexPgevaerts: do you think the whole re-locatable plugins/pebbles/type thing is enough for GSOC?
13:46:04gevaertsAlexP: I don't know. I have some doubts
13:46:20 Join AsusFreak [0] (~c1003c16@giant.haxx.se)
13:46:31AlexPAs it'd be a nice thing to have - maybe we could flesh it out a bit
13:47:01gevaertsTheSeven: on everything except imx31 and tcc, yes. The different values aren't for RAM reasons, just performance :)
13:47:44gevaertsIf your natural IO size is 64k, by all means keep it at 64k. The only problem with that is of course that it's not necessarily 64k-aligned
13:48:28TheSevenit was at 24k before, but 64k is significantly better
13:48:36TheSeveni think this needs to be moved to the device config
13:49:09TheSeveni'll do the "ifndef define" variant in usb_storage.c probably
13:49:55TheSevena fun fact is that, while the ftl is busy 88% of the time at 64k, it is busy 95% of the time at 24k, but overall performance is 16% worse
13:50:09 Join Strife89 [0] (~michael@adsl-154-14-228.mcn.bellsouth.net)
13:51:01TheSevennand busy only 40% of the time
13:51:20gevaertsYou might also want to try reverting r24333. I don;t think anything could actually go wrong before that one, the thing just needs to be redone properly
13:51:30TheSevenoverall CPU usage during FTL activity is still 53%
13:52:30TheSevendidn't we commit that patch to make usb work at all on nano2g?
13:53:06gevaertsno, that's something else
13:53:18TheSevenhowever, i think those measurements show that the slowdown is clearly coming from the FTL, not the USB handling
13:54:22gevaertsyes, but r24333 causes a 5% to 10% slowdown on PP, so if you're chasing the OF performance, it will count
13:54:39pamauryTheSeven: if you have doubt about usb performance, just trash the incoming data and never call the ftl. This way, you'll have the raw usb speed...
13:54:41TheSevenwe're more than 50% behind that right now
13:55:08TheSeven(even though we're already 200% better than yesterday)
13:56:52gevaertsAlexP: if you add "... and make it work using the audio buffer", you might get closer
13:58:09 Quit Strife89 (Ping timeout: 248 seconds)
13:59:12pamaurygevaerts: it's also possible (at a huge cost) to do it without touching too much the audio code: just put the plugins at the beginning of the audio buffer and when a plugins exist, you can move all the others and because there are relocable, you just apply reloc one more time ;) So in fact, you don't have fragmentation issue but that's horrible :)
13:59:39pamauryThere is only one tricky point with the stack data however :(
14:00
14:00:57gevaertspamaury: by then the plugin might have pointers all over the place, located in malloced buffers, and pointing to potentially anywhere
14:01:05gevaertsSo I think you can't :)
14:01:53pamauryYes I know, it's just that the idea is brilliant isn't :) You can have the plugin have a special "rockbox_deciced_to_move_you_so_updateyou_pointers_using_this_delta" function :)
14:02:22 Join jgarvey [0] (~jgarvey@cpe-065-190-069-073.nc.res.rr.com)
14:04:04pamauryAnyway, even if it was doable, that's way too horrible. The audio buffer code has to be rewritten to handle relocatable plugins
14:04:42*gevaerts points out that *all* of this has been talked about during the past month or so :)
14:04:55TorneIt sounds like a reasonable project idea to me :)
14:07:18 Quit Zagor (Ping timeout: 265 seconds)
14:08:42 Join Zagor [0] (~bjst@rockbox/developer/Zagor)
14:09:08 Quit Hillshum (Ping timeout: 260 seconds)
14:11:45 Join anewuser [0] (anewuser@unaffiliated/anewuser)
14:14:30 Join kugel [0] (~kugel@rockbox/developer/kugel)
14:15:33kugelgevaerts: shouldn't we add "relocatable and multiple plugins" to the ideas list?
14:16:16gevaertsFeel free
14:17:04pixelmareminds me of localised plugins... :(
14:18:41 Join Zarggg_ [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com)
14:19:02 Quit Zarggg (Read error: Connection reset by peer)
14:22:02 Quit punkt (Quit: CGI:IRC)
14:22:11*TheSeven wonders where those sudden poweroffs are coming from
14:22:28*kugel would also like to see some sort of buflib in the core
14:23:38kugelallocating the big buffers and resize/move them if needed
14:25:27 Join Schmogel [0] (~Miranda@p3EE21EA2.dip0.t-ipconnect.de)
14:25:28 Join Hillshum [0] (~hillshum@75-165-243-59.slkc.qwest.net)
14:26:48 Quit Zarggg_ (Read error: Connection reset by peer)
14:27:00 Join froggymana [0] (~187b533e@giant.haxx.se)
14:28:26 Join Zarggg [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com)
14:33:56 Quit evilnick (Read error: Connection reset by peer)
14:34:19 Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net)
14:43:31 Join stoffel [0] (~quassel@p57B4C424.dip.t-dialin.net)
14:45:07 Join mt [0] (~mtee@rockbox/developer/mt)
14:46:33*TheSeven is confused
14:46:39TheSeven8 seconds vanishing into nowhere!
14:48:17 Quit Marctraider (Ping timeout: 248 seconds)
14:49:13 Join Marctraider [0] (~marctraid@82-170-60-93.ip.telfort.nl)
14:50:21 Quit n1s (Quit: Lmnar)
14:51:44TheSevenargh!
14:52:19TheSevenwhy does rockbox just *power off instantly* without shutting down sometimes if i hit the play button (for like half a second) while connected to USB?
14:52:48 Quit Zarggg (Read error: Connection reset by peer)
14:52:50 Join Zarggg_ [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com)
14:54:08 Nick Zarggg_ is now known as Zarggg (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com)
14:56:47 Quit moos (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158])
14:59:22***Saving seen data "./dancer.seen"
15:00
15:01:45 Quit liar (Ping timeout: 256 seconds)
15:10:36 Quit chrisb (Remote host closed the connection)
15:19:44 Join petur2 [0] (~petur@rockbox/developer/petur)
15:20:06 Quit petur (Disconnected by services)
15:20:11 Nick petur2 is now known as petur (~petur@rockbox/developer/petur)
15:28:45 Join CGL [0] (~CGL@190.79.151.231)
15:36:50 Quit mc2739 (Quit: leaving)
15:41:16 Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick)
15:43:09 Join watto [0] (~watto@193.203.81.165)
15:55:37 Quit froggymana (Quit: CGI:IRC (EOF))
15:59:53 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739)
16:00
16:01:33AsusFreakHi. I'm just doing some experiments with %Tl in my AF_Black theme. Whenever I start my Cowon D2 and "start in screen: wps" is activated %?Tl2<%Vdj|> indicates that the touchscreen is pressed (why?) and the 2 second delay does not work to reset the flag. Only by pressing the touchscreen once the clock begins to run and after 2 seconds the flag goes to 0.So the normal way starting in the WPS screen should be that this Touchscreen Pressed flag %TI is set t
16:02:09 Join chrisb [0] (~chrisb@pool-71-175-246-16.phlapa.east.verizon.net)
16:02:33 Join petur2 [0] (~petur@rockbox/developer/petur)
16:02:46 Quit petur (Disconnected by services)
16:02:52 Nick petur2 is now known as petur (~petur@rockbox/developer/petur)
16:03:25*linuxstb wonders about the "clean up the radio code" SoC proposal - isn't that more like something for MrSomeone ?
16:03:29 Quit Marctraider (Ping timeout: 240 seconds)
16:04:31 Join Marctraider [0] (~marctraid@82-170-60-93.ip.telfort.nl)
16:08:03 Join petur2 [0] (~petur@rockbox/developer/petur)
16:08:14 Quit petur (Disconnected by services)
16:08:16 Nick petur2 is now known as petur (~petur@rockbox/developer/petur)
16:08:22kugelneither list is a personal wishlist
16:09:09kugelbut the radio related code definitely needs a overhaul, the apps/ and the firmware/ part are a pure mess
16:11:54mtWhat about the multi-codec architecture for the video player ? Why isn't it there ?
16:12:30Zagorit is
16:12:50Zagor"Multi-codec architecture for mpegplayer"
16:12:58mtah .. just seen it. I was looking at the "codecs" section
16:13:01mtmy bad.
16:18:10 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37)
16:22:33Unhelpfulpamaury, gevaerts: one idea tossed around before was to use an rb-like structure, with plugin relocations specified by index. the same mechanisms used now to version the plugins and API would be used to make sure plugins don't break. but yes, we'd need to add core functions to it by hand - i'm not sure this is a bad thing as it makes us think about whether we should. ;)
16:24:22linuxstbkugel: But do you think a radio code rework is worthy of a SoC project?
16:24:34kugelnot sure, probably not
16:27:23 Quit Seed (Quit: cu, Andre)
16:27:27pamauryUnhelpful: I don't understand the "with plugin relocations specified by index" and the rest... :)
16:28:41Unhelpfulpamaury: when generating the final linked plugin we'd match relocations by symbol to the named members of the struct, and write out their offsets in the relocation table.
16:28:55Unhelpfulyes-this-means-coding-relocation-ourselves :/
16:30:54pamauryOk, I think I understand what you mean :) But the main problem is not relocation anyway, it's the use of the audio buffer I think
16:33:43Torne<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
16:33:47Torneoops
16:33:49Tornesorry
16:35:47kugelTorne: I wondered why the plugin&codec buffer isn't simply moved/linked before the main binary for unified ipodvideo 32MB and 64MB builds?
16:36:01Tornekugel: we discussed it before
16:36:10Torneit's possible, but would require fiddling with the bootloader
16:36:35Tornerelocatable loading solves lots of other problems as well; if we're gonna do that it's not worht the effort to relocate the buffers
16:36:59kugeldo we really want relocatable codecs?
16:37:18Tornewhy not?
16:37:46kugelfrom what I gathered, PIC costs a lot of performance and code size,
16:37:52TornePIC is not involved
16:38:00Tornethere is zero performance cost
16:38:11Torneand no runtime size cost (only a disk cost for the relocs)
16:38:36Tornerelocatable doesn't mean position independant; position independant code *doesn't* require relocation :)
16:39:12kugelthe main binary could memmove itself as well, bootloader fiddling is not needed
16:39:20Torneyes. we discussed all this.
16:39:28Tornemany months ago ;)
16:39:34kugelI'm just thinking it's easier for now ;)
16:40:01TorneI really don't think it is, personally
16:40:11Tornebut hey
16:40:39kugelwell, the idea is added to the GSoC list, let's hope we find someone ;)
16:40:42Tornebuilding the plugins as relocatable is the slightly fiddly part; actually loading them and applying relocs is incredibly easy
16:40:59Torneit only really gets hard if you consider loading into audiobuffer
16:41:04Tornewhich is something that can be done later
16:41:48kugelsure, for a start it would be nice to battery_bench while playing bubbles :)
16:42:06Torneright, but you could do that by just dividing up plugin_buffer
16:42:18Torneif you don't expect full generality it's not difficult
16:43:49 Join toffe82 [0] (~chatzilla@12.169.218.14)
16:44:00*kugel tries to imagine how it would be done without PIC
16:44:41Tornewithout PIC is the normal way..
16:44:43TornePIC is a special case
16:45:07Torneyou build an elf binary just as we do now, but link with -r to keep all the relocations
16:45:53Tornethen you feed it to elf2flt to turn it into a simpler format, still with the relocations
16:46:02Tornewhen you load it you just go to each reloc entry and add the right offset
16:46:10Tornethen throw the relocation data away
16:46:51Tornethe resulting assembly code is identical to if you just ran it through objdump with the right target address
16:47:06Torneit's slightly complicated by things like iram, but that's the basic idea.
16:47:25Tornethe conversion step is not technically required, either, but we probably don't want to implement an elf loader.
16:48:43kugelah, cool. I didn't know about -r
16:49:06Torneall PIC does to this process is make it so that there are less relocations
16:49:18Torneyou end up hving all the code refer to a global offset table
16:49:23Torneand then you just need one big mass of relocs in th etable.
16:49:33Tornethis means you can share more pages between processes that map the same library
16:49:36Tornebut we don't care about that.
16:50:24kugeljust port ld and objdump (and strip?) to rockbox. done :P
16:50:26Torneso yeah. the process is trivial. the actual details of integrating it into our build process are not entirely trivial, or gevaerts or I would've done it by now :)
16:50:26 Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-diwnibizbgpenzyc)
16:51:10Tornei'm in favour of using the bFLT image format from uClinux because I *think* it just barely meets our requirements, it's incredibly trivial to load (basically a ~5 line for loop) and there's already the elf2flt tool that does the conversion
16:52:33 Quit notlistening (Quit: Ex-Chat)
16:59:26***Saving seen data "./dancer.seen"
16:59:31pamauryyes, but there is the iram issue, no ?
17:00
17:02:33Torneit should be fine
17:02:44 Quit petur (Quit: *plop*)
17:02:53Tornebut the exact linker script required to make it work would need writing :)
17:03:42gevaertsTorne: with bFLT?
17:03:50Torneyah
17:03:56Torneas long as you don't expect things to be able to share iram
17:04:11pamauryyou're cheating :)
17:04:19Torneput the iram addresses int he linker script, which is fine as long as they don't overlap 0->pluginsize
17:04:24Tornethen strip the relocs for them
17:04:30Tornewill probably work.
17:04:36*gevaerts *does* expect things to share iram! :)
17:04:46Tornewell, then no :)
17:05:21pamaurywe can still implement something like alloc_iram and free_iram so the linker script is still works
17:05:35pamaury*-is
17:05:57pamauryAnyway, if you share iram you have to manage it so it has to be dynamical
17:06:04gevaertsiram also has code
17:06:08Tornepamaury: No, we can't implement that
17:06:14pamaurywhy ?
17:06:17TorneWe can't share iram unless we also know how to relocate references to iram
17:06:19pamauryAh, code :)
17:06:22Tornewhich is not possible in bFLT without modification
17:06:29Tornebecause it only has three sections
17:06:50pamauryIndeed, if you share iram code, that's impossible with bFLT
17:07:13Tornedo we care, though?
17:07:27Tornewhat's the need for it?
17:07:54pamauryis putting code in iram actually a gain ?
17:08:09kugelcould we prepend some 0xFFF to the reloc entry to show it's for iram?
17:08:13Torneit doesn't matter if you put code in iram..
17:08:24Tornekugel: only if we wrote our own tool
17:08:32Tornepamaury: you can't *refer to addresses in iram at all*
17:08:52Torneit would be impossible to use iram for anything except malloc-like behaviour as you said
17:08:58kugelTorne: if we do that we can just as well add iram sections
17:09:05Torneyou can't store any code or any variables there, unless it's a fixed location or you can relocate it
17:09:10TheSevenby pipelining that, we could actually get 80% more performance yet again
17:09:13 Join patgodo [0] (~chatzilla@g229063126.adsl.alicedsl.de)
17:09:35Tornekugel: yes
17:09:46kugelalthough prepending 0xfff wouldn't involve changing the "standard" header
17:09:53TheSevenhm,,,
17:09:54gevaertsTheSeven: don't very large nand transfers also imply delayed errors?
17:10:01pamauryThen let's add an iram section to bFLT, that shouldn't be too hard
17:10:01Tornekugel: but again this may be difficult, because the way that bFLT works means you can't really do that :)
17:10:06Tornepamaury: yes it will be
17:10:19TheSevenwell, i get 64k writes from the usb stack, so i could at least write 64k blocks without further delaying them
17:10:28TorneThe format discards the relocation data, and only keeps the relocation site addresses
17:10:33TheSevenit would be a little to handle bad blocks in that case though
17:10:38TorneIt relies on the fact that you have linked the binary to be placed at addresses starting at 0
17:10:41TheSevenit can be done, it's just a bit complex
17:11:04Tornewhich means that the values ld stores in the actual reloc sites are the offsets from the start
17:11:04TheSeventhis would mean merging quite a bit of VFL code into the FTL
17:11:20Torneand thus you only need to know where each reloc is, and you just add the same base address to all of them.
17:11:26*Unhelpful still thinks buflib could be adapted to solve *most* of the allocation problems... but multiple plugins using iram at the same time that codecs use it will be messy no matter what.
17:11:35TheSevenright now, i'm writing in 8K steps, and i could almost do 2 of those in parallel
17:11:42kugelyea, I read through bFLT, and it looks like we need to modify it anyway if we want to work with iram
17:11:43Unhelpfulin particular APE is now deliberately using all of iram :)
17:11:49Tornealso yeah
17:11:59Tornein general, on platforms where iram is faster then most codecs should probably be using all of it, no?
17:12:02TheSevenwell, actually this means merging both nand and vfl code into the ftl
17:12:24Torneany time ther eis space there is probably something that can go in iram that will make it faster..
17:12:27UnhelpfulTorne: only when they reasonably can. and i could limit the size of the APE divider reciprocal table...
17:12:49TorneUnhelpful: yes, but I doubt we are likely to reach the point where there's nothing that could reasonably be put in there very often
17:13:19*Unhelpful thinks keeping "stop playback for plugin iram" is reasonable.
17:13:25pamauryThen why bother ? Just manage iram in a malloc/free way, that solves all the linker problems and it adds two lines to the codec...
17:13:33Tornepamaury: but it makes the code that uses iram slower!
17:13:42TorneIt doesn't just add two lines
17:14:09TorneIf you link your code to directly refer to symbols in .iram then that's equally quick to access as if it were in .text
17:14:13Torne(or .data)
17:14:18 Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.0.152)
17:14:22kugelUnhelpful: do you think porting buflib to the core to manage most of the big buffers is a worthy gsoc project? I thought about adding it to the ideas list
17:14:27Tornebut if you indirect via a pointer returned by a malloc-like then you are now slower
17:14:40Tornepamaury: for there to be any point you need ot be able to put symbols in iram
17:14:45Tornenot just store data in iram.
17:15:05pamauryTorne: indeed; then use elf :)
17:15:11Torneand this is only possible if the linker handles it, either the compile-time linker or the runtime linking loader
17:15:43saratogadoes anyone care if we just enable line out for the fuze all the time? we do this on the ipods and e200v1 already
17:15:50pamaurydoes elf support all the necessary features for what we want ?
17:15:53Tornesaratoga: someone is working on having us *not* do that for ipod
17:16:00 Quit S_a_i_n_t (Ping timeout: 276 seconds)
17:16:03saratogayes I know
17:16:03Tornepamaury: of course, otherwise we couldn't use ELF to link plugins in the first place ;)
17:16:12Tornepamaury: think about it ;)
17:16:16TorneBut an ELF loader is big and slow and hard
17:16:38Tornethe point of using bFLT is that it's incredibly trivial to load and someone else already wrote the conversion tool
17:17:39kugelTorne: blft version 2 has the type bitfield, maybe we could simply change the bits from .text, .data, and .bss to .iram and .ram (and .unused(or .init if you want)), and still apply the logic version 4 uses
17:18:28Torneoh wait
17:18:59Tornepardon me, i'm dumb
17:19:01Torneyou don't need to do that
17:19:38Torneif you're going to hack it anyway just add the extra fields to the header
17:20:06Torneoh no, double wait
17:20:09Torne:)
17:20:23kugelyou wouldn't need to hack it the converter, only the loader, it's up to use how we interpret .text, .data, and .bss
17:20:26TorneYou might still have a problem, either way
17:20:43Tornethe problem is that iram sections have a different LMA and VMA
17:20:57Tornebecause they're loaded to one place then copied to another
17:21:15kugelLMA/VMA?
17:21:24Torneload address and run address, if you like :)
17:21:31pamauryIs it too difficult to hack bFLT to add a new section ? I would require to tweak the converter but loading would still be easy
17:21:43pamaury*s/I/it
17:21:58Tornepamaury: no, it's not, i realised i was making a mistake :)
17:22:02Tornebut it still might be a problem
17:22:03TheSevenrecursively locking a mutex from the same thread is safe, isn't it?
17:22:19 Quit jd (Read error: Connection reset by peer)
17:22:32pamaurywhich problem ?
17:22:37 Join jd [0] (~jd@modemcable207.134-202-24.mc.videotron.ca)
17:22:38 Quit jd (Changing host)
17:22:38 Join jd [0] (~jd@Wikipedia/HellDragon)
17:22:43Tornepamaury: what I just said
17:23:03kugelTorne: version 4 uses the logic that .bss follows .data. we can even fo further and assume .data after .text (the remark about code in rom doesn't apply for us). we really only need to distinguish between iram and ram. or am I overlooking something?
17:23:10Torne.iram is linked AT(iramcopy) which is the address immediately after .data
17:23:25Tornebut it's linked to run at PLUGIN_IRAM
17:23:53Tornei.e. the place it's stored in the program load image is not the same as the address it is relocated for.
17:24:01dionoeaTheSeven: that would deadlock
17:24:10 Part patgodo
17:24:20pamauryTorne: yes but at reloc time you can distinguish between those two types of reloc, no ?
17:24:23dionoea(at least in general, I don't know if/how rockbox mutexes work)
17:24:27TorneThey are not types of relocation
17:24:31 Quit Marctraider (Ping timeout: 246 seconds)
17:24:35TorneThere is nothing to be done at load time
17:24:36pamauryYes but look at the adress
17:24:43TorneThe problem is at link time..
17:24:44 Join Marctraider [0] (~marctraid@82-170-60-93.ip.telfort.nl)
17:25:32pamaurylink everything as if it was .text then .data then .bss then .iram and when a reloc address fall in iram apply a different reloc delta
17:25:59TheSevenshould we put implementing a usb transfer cache (like a hard drive that has a cache) on mr. someone's todo list?
17:26:35kugeldo we want that?
17:26:42TheSeventhat's the question
17:26:54kugelusb transfer caches only annoyed me so far
17:26:58gevaertsTheSeven: for write, I have one...
17:27:09kugellinux had that not too long ago, but it disappeared again
17:27:24TheSevenit could help speeding up usb transfers, and i don't see any disadvantages besides it being quite some work and some binsize hit
17:27:38gevaertsFS #10239 does most of that
17:28:02TheSevenkugel: actually every dumb usb external hard drive is doing it
17:28:58kugelcaches on the device side aren't as bad as ones on the OS side, I guess
17:29:07TheSevengevaerts: I will try that one when i have the NAND at the maximum possible speed
17:29:33TheSevenkugel: caches on the OS side aren't bad either as long as they are implemented in a sane way
17:30:38kugela new day, a new nano2g-sktov :)
17:31:08TheSevenreally?
17:31:19kugelfs#11090
17:32:06*TheSeven likes to quote gevaerts who said that a non-512 sector size would be opening a can of worms... i'd rather say a can of stkov's ;-)
17:32:17TheSevenactually it were exactly 2 worms and a dozen stkovs
17:32:29 Quit robin0800 (Ping timeout: 256 seconds)
17:32:39TheSevenbut that one isn't nice
17:32:44TheSevena *shutdown stkov*!?
17:33:01TheSevenand the thread name seems to have been damaged by it. bugger.
17:33:16TheSevencan't we place the task information stuff *above* the stack to prevent that?
17:34:46kugelisn't it just a matter of swapping the "const char thread_name[] =" and "char thread_stack[]" lines?
17:35:36kugelwow, finally someone with a clue answered on my gcc bug
17:36:56TheSevenkugel: no, it's a matter of moving the stack in app.lds
17:37:32kugelonly the main thread stack is there, isn't it?
17:37:45TheSevenyes, but i bet that this one is the problem here ;-)
17:38:03kugeland the main thread name is in the .data section, unlikely to be next to the stack
17:38:10TheSeven(which on the other hand would increase the probability of a stkov actually overwriting code, which might be even worse as not even the panic message would be shown any more)
17:38:26TheSevenisn't it in idata?
17:38:41kugelno idea, depends on the target
17:38:59UnhelpfulTorne: i don't really know how big a project needs to be for gsoc. i have a rough idea of what needs to be done, but i tend to put off implementing this sort of thing because i hate problems that are mostly organizational :/
17:39:02kugelI'm just saying that the main thread stack & name is completely different to other threads
17:39:25TheSevenhow, how can that kind of crash happen then?
17:39:54saratogaupdated my tremor mdct patch, but it still gives static output
17:40:50kugelstkov is detecting by checking the stack end for 0xdeadbeef. anything that's before the stack end is potentially overwritten
17:41:11TheSevenhm, but how can a stack hit that area?
17:41:16Unhelpfulfor core the idea i had was that each buflib object would have a pointer to a function with a specific signature that could handle anything needed to relocate the buffer... for buffer_alloc objects this would mostly mean updating a pointer to the space, and any pointers into it. for codecs we'd need to pause any COP threads before doing that...
17:41:18kugelso, the thread name has to be before the stack in order to be overwritten
17:41:31TheSevenor actually a pointer to it
17:41:44kugeland that's unlikely for the main thread, unless the main thread name is at the very end of .data
17:41:52TheSevendamn, this is another case for post-mortem debugging :-/
17:42:58TheSevenif it would have happened over here, i'd just do a memdump
17:43:56*TheSeven is about to grab another 56K of ramsize for the FTL
17:44:57Tornepamaury: i don't think you understand what i mean. i'm not sure how big a problem it is, but you aren't addressing it :)
17:45:00TheSevenwell, that's still almost compensated by yesterday's green :-)
17:45:47pamauryarg, TheSeven you're eating all ramsize i'm freeing ;)
17:46:09TheSevenyes, you'll need to run after those useless LFN sector buffers to fully compensate it ;-)
17:46:22Unhelpfulwe could either explicitly shove objects we don't want to move frequently to the front of the buffer, or just let them migrate there gradually as things below them are freed.
17:46:22 Quit AsusFreak (Quit: CGI:IRC (EOF))
17:47:00TheSevenbut it everything works as expected, i'll finally reach a 1000% speedup for nand transfers with this, compared to what rockbox did yesterday
17:47:12Tornepamaury: actually, the problem is preserving the correct location for the symbols that tell you where the data for the iram sections *really is*
17:47:14kugelTheSeven: it looks like all stacks have the name after the stack or passed it directly in the create_thread() call
17:47:29pamauryTheSeven: are there useless buffers in the FAT code ?
17:47:29Tornepamaury: it's work-around-able, but the linker script might grow hairy legs as a result :)
17:48:20UnhelpfulTorne: might it help to use FLT only as a starting point? perhaps add more sections?
17:48:26TheSevenpamaury: we talked about that excessive count of sector buffers in dirent structs some days ago
17:48:47TorneUnhelpful: i think it's easiest to just not bother to begin with, tbh :)
17:49:09pamauryTheSeven: not sure but indeed, 3 sectors of caching per fat_dir seems a lot to me
17:49:27UnhelpfulTorne: FLT? or specifically being able to relocate multiple iram users?
17:49:32TheSevenone sector + 512 bytes would be sufficient if one would do a little rework on the LFN reading code
17:49:34Tornebeing able to relocate iram
17:49:43 Join Adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net)
17:49:48TheSevenand it wouldn't even reduce performance
17:49:58UnhelpfulTorne: fair enough, i can agree to that. :)
17:50:06pamauryTheSeven: why one sector + 512 bytes (the 512-byte i mean)
17:50:13TorneUnhelpful: it's not infeasible to do it by some method, anway.
17:50:20Tornepamaury: we painstakingly worked this out the other day :)
17:50:28 Quit anewuser (Ping timeout: 245 seconds)
17:50:31TheSevenbuffer for the actual file name, as we need to get that out of the preceding sectors before we overwrite them in the sector buffer
17:50:40kugelUnhelpful: seen my question?
17:50:56TorneUnhelpful: i just don't think worrying about what that method should be right now is worth the effort
17:50:59TheSevensearch the IRC logs of the last days for dozens of occurrences of "LFN" for details
17:51:13Unhelpfulkugel: yes, and answered, but i mistakenly directed the answer at Torne. been sick, sorry. :/
17:51:19pamauryTheSeven: ok, I'll have a look at the log and at the code, see if there is something to do
17:51:36UnhelpfulTorne: almost everything that uses iram expects exclusive audio access anyway, right?
17:51:42TorneUnhelpful: everything, afaik
17:51:45TheSeventhat would get us rid of another 3.5K per dirent on nano2g
17:52:34pamauryAnd perhaps reduce binsize, iirc the function handling LFN is monstruous, if only it can be simplified !
17:52:54kugelUnhelpful: I think it involves a lot of rewriting in the code that would use buflib (i.e. adding get_data() where needed, making it offset based), so it would qualify as a project IMO
17:53:22TorneUnhelpful: beatbox, doom, midi, mpegplayer, pacbox, pdbox, rockboy, zxbox
17:53:38TorneUnhelpful: pretty sure those all steal the sound
17:53:42Unhelpfulthen i say forget about it for now. you don't need to run doom and mpegplayer at the same time. i think for iram we should support only one user, and possibly the option to swap iram users out to dram so that we can "background" an iram-using app.
17:54:03kugelTorne: most of them produce their own sound anyway :p
17:54:17Tornekugel: well, as i said, as far as i can see they *all* do
17:54:20 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
17:54:30 Join anewuser [0] (anewuser@unaffiliated/anewuser)
17:54:32Tornewhich means that right now there is no sensible reason to want to run more than one at once or to run one at the same time as playback
17:54:49kugeldoesn't greylib grab iram as well?
17:54:55Tornekugel: only if you tell it to
17:54:55Unhelpfulkugel: only optionally.
17:54:59kugelok :)
17:55:06Tornekugel: which only the plugins that are using iram anyway do
17:55:52kugel1 iram user at a time seems like a sensible thing to do then
17:56:10Tornein which case, with fingers crossed, it shouldn't be *too* difficult to do
17:56:21Tornejust a matter of rewriting the linker scripts to produce what elf2flt expects
17:56:26kugelwe shouldn't have so high requirements anyway, otherwise it's not getting done
17:56:28Tornemaybe adding in a bit of strip to remove relocs we don't want it to see
17:56:41Tornewell, if we are doing *just* that, then I doubt it's a SoC project, though :)
17:57:06kugelI think it is
17:57:07Tornejust poking the linker scripts until elf2flt produces the right output, and implementing a tiny loader, shouldn't take very long at all
17:57:20pamauryand bugfixing ? ;)
17:57:21Torneif you want to load into audiobuffer then that's a whole different can of worms..
17:57:41UnhelpfulTorne: save the reloc info and reloc on move? :)
17:57:58TorneUnhelpful: i recall someone in scrollback earlier telling you why that was stupid ;)
17:58:07Torneso i shall refrain from repeating it ;)
17:58:25AlexPbluebrother: Well spotted - I've removed that and banned it
17:58:26Unhelpfulwas it you? ;)
17:58:31Torneno
17:58:33pamauryI think I proposed that just for fun :)
17:58:37Tornealso they may have been telling gevaerts
18:00
18:03:31 Join komputes [0] (~komputes@ubuntu/member/komputes)
18:06:32 Quit pamaury (Quit: Quitte)
18:12:41kugelgevaerts: you didn't do the *promised* test codec runs, did you? ;)
18:14:24gevaertskugel: I did *all* promised test code runs!
18:14:38kugelok, I get it :p
18:14:42gevaertsUnfortunately I didn't have time for the ones that I didn't promise
18:15:20kugelI think you have plenty time, doom needs to be fixed badly
18:29:08 Join mitk [0] (~mitk@chello089078013146.chello.pl)
18:31:05mitkHi, can an dev take a look at FS #11082 - Polish character set for 08-Atadore font? It's simple commit.
18:31:15 Join tvelocity [0] (~tony@weg38-1-82-237-37-150.fbx.proxad.net)
18:31:51UnhelpfulTorne: actually, re: the idea of swapping out iram, why not handle plugins that way as well? not letting multiple plugins actually *run*, but suspending the plugin state when leaving its interface?
18:34:15UnhelpfulTorne: so "there might be pointers to malloc'd buffers" is the main reason not to really relocate a plugin's data? :)
18:35:19 Join Strife89 [0] (~michael@adsl-068-213-037-174.sip.mcn.bellsouth.net)
18:35:54pixelmabluebrother: what parameters does RbUtil's voice file generation use for Archos voices (I mean speed etc.). The one I generated now with default settings and German (with the Infovox demo on Mac) is way too large
18:37:27Unhelpfulbut yes, a move_this_buffer callback might be much too ugly for plugins, compared to one for moving the current codec's data buffer or moving a buffer used for skin or font data
18:37:44*pixelma also searches for a list of parameters and its syntax to pass some options to RbUtil
18:42:23 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury)
18:43:14 Join JdGordon1 [0] (~jonno@c-76-104-153-69.hsd1.wa.comcast.net)
18:43:15 Quit JdGordon (Read error: Connection reset by peer)
18:43:50TorneUnhelpful: there might be pointers to other things, too
18:43:58TorneUnhelpful: to symbols in .idata, or whatever
18:44:07Tornepointers aren't always to dynamically allocated memory
18:44:17 Quit Strife89 (Quit: Short lunch, leaving the restaraunt.)
18:44:24 Quit saratoga (Quit: Page closed)
18:44:43UnhelpfulTorne: so a relocation function would have to know which pointers must be updated... yes, i don't think we want to do this in general :)
18:46:03Unhelpfulwhat about giving plugins a "suspend" option - they exit with a specific exit code after calling setjmp, or similar, and the buffer is kept?
18:46:14 Join stuckey [0] (~stuckey@95-89-146-97-dynip.superkabel.de)
18:46:24stuckeyHi
18:47:00Unhelpfulagain, the idea here is that there's a resource (the GUI) that they can't share anyway
18:48:19 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky)
18:50:14Tornewell yah, there's any number of possible things we might later want
18:54:32Unhelpfuli mean as an alternative to "real" plugin multitasking
18:56:11 Quit tvelocity (Quit: Αποχώρησε)
18:56:39JdGordon1kugel: any news on the skin resising patch?
18:57:51 Quit stuckey (Remote host closed the connection)
18:58:47pixelmahmm... "speed" seems to be a TTS option I know of SAPI on Windows but there is a "Pitch" setting in the MacOS' VoiceOver setup bit it seems RbUtil ignores that (at least in the test)
18:58:49 Join tvelocity [0] (~tony@weg38-1-82-237-37-150.fbx.proxad.net)
18:59:29***Saving seen data "./dancer.seen"
19:00
19:02:01 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl)
19:05:56 Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-neumvkadhqicdywb)
19:06:19pixelmas/bit/but
19:06:23bluebrotherpixelma: the OS X TTS implementation in rbutil doesn't allow adjusting pitch or voice (yet). That's one of the things I've got on my todo list for implementing next.
19:07:11bluebrotheras I'm not setting a value it should take the default. No idea if that means its using the system value (I guess so) or the default value of the voice
19:08:02pixelmasystem value should give me an effect if I change it in thte VoiceOver setup, no?
19:08:51bluebrothernot sure about voice over. In 10.6 the voice setting is different than the voice over setting.
19:09:25domonokysapi also has a pitch option, only the sapi script doesnt export it to rbutil. (but the opensapi patch in the tracker does it).
19:09:52pixelmamy question was also related to the encoder options (sample rate etc.). I see I can pass some myself but am curious what is used (for lame) and also their names as I don't know the names off the top of my head :\ )
19:10:31pixelmaall three voice files I created are more than twice the size they are a allowed (about 3.3 MB each)
19:11:04pixelmaI tried English, German and Swedish. There is not much difference between the three
19:11:15bluebrothernot sure about mp3 voices, but rbspeex resamples its wav input to 16kHz
19:11:37bluebrothermost voices on OS X seem to be 22kHz.
19:14:07pixelmaI know I set 11kHz for the SAPI voices... would already explain (and gain) a lot. Not sure but I think I remember there is some must have (sample rate or similar) for Archos voices but don't remember exactly and the talk files worked at least
19:15:46 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
19:16:06domonokythe buildsystem use the following lame options: −−resample 12 -t -m m -h -V 9.999 -S -B 64 −−vbr-new"
19:16:32domonokydont know if rbutil uses any lame options if you dont enter it.
19:16:59bluebrotherpixelma: on 10.6 I've got Systemeinstellungen / Sprache and Systemeinstellungen / Bedienungshilfen. The latter is for configuring VoiceOver which can have a different voice selected.
19:18:53bluebrotherdomonoky: as far as I can see it does not.
19:19:40 Quit stoffel (Ping timeout: 246 seconds)
19:20:32 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk)
19:20:52saratogastripwax: ping
19:21:18 Quit stripwax (Client Quit)
19:22:39 Nick JdGordon1 is now known as JdGordon (~jonno@c-76-104-153-69.hsd1.wa.comcast.net)
19:23:09pixelmabluebrother: did you read the logs of today's morning?
19:23:13 Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net)
19:23:27*pixelma got to leave now though before shops close - back later
19:23:41 Quit DerPapst (Quit: Leaving.)
19:26:55bluebrotherpixelma: not yet −− will check them
19:27:08 Quit LambdaCalculus37 (Ping timeout: 240 seconds)
19:27:17 Join Horscht [0] (~Horscht2@xbmc/user/horscht)
19:27:42 Quit Horscht (Client Quit)
19:29:34 Quit mt (Quit: ChatZilla 0.9.86 [Firefox 3.5.8/20100202165920])
19:32:22 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37)
19:37:27 Join mt [0] (~mtee@rockbox/developer/mt)
19:39:28mitkbertrik: ping
19:40:22 Join bmbl [0] (~Miranda@unaffiliated/bmbl)
19:41:57 Join sansafuze_v2-FAN [0] (~5b045847@giant.haxx.se)
19:43:06sansafuze_v2-FANhallo, i´m wondering, when a stable version for the sansa fuze v2 is presented. waiting for it with tears in my eyes....
19:43:09 Join petur [0] (~petur@rockbox/developer/petur)
19:44:15saratogawhen its done
19:44:54AlexPbest get a hanky then
19:45:46domonokysansafuze_v2-FAN: just try the current build, it pretty stable.
19:46:03*domonoky shuts up fuze v2 ! :-/
19:46:11 Quit sansafuze_v2-FAN (Client Quit)
19:46:16domonokywe dont even have a unstable build for that
19:46:19kugelJdGordon: I had strange behavior with my last patch, but I didn't look into it further
19:46:44kugelstrange behavior as in the wps was going crazy (displaying wrong images)
19:46:47JdGordonstrange how? data aborts?
19:47:09JdGordonI'm getting wierd behaviour also
19:48:45 Quit Hillshum (Ping timeout: 276 seconds)
19:50:14 Join Strife89 [0] (~michael@168.16.237.214)
19:50:34mitkAny chance to commit FS #11082? It's only adding charset to font.
19:52:33 Join DerPapst [0] (~DerPapst@p4FE8FD73.dip.t-dialin.net)
19:55:20 Join Horscht [0] (~Horscht2@xbmc/user/horscht)
19:55:50mtmitk: Sorry you haven't received a response, but people are probably busy now. I'd do it but I'm very busy too atm.
19:56:53mtI might be able look at it in 2-3 days if no one beats me to it.
19:58:00mitkmt: Thanks. I will wait then.
19:59:12 Quit petur (Quit: plop)
19:59:33bertrikI could do it too, but I don't know much about fonts
20:00
20:02:57bertrikthe patch adds some characters but also changes the name of some, like "capital C, cedilla" to "Ccedilla" for example
20:03:07mitkbertrik: You already commited my 2 charset adds to Nimbus 12 and 13. It's same kind of stuff so pls don't worry ;) It's tested.
20:04:05mitkbertrik: These changes are inline with other fonts like Nimbus. These changes were made by FontForge, not by me.
20:05:08mitkAtadore has different names than other fonts in Rockbox. Nedore for example too.
20:11:12 Quit Marctraider (Ping timeout: 264 seconds)
20:11:50mitkSorry. Nedore have same names like Nimbus. Atadore has different. After patch Atadore names will be inline with Nimbus an other fonts
20:11:52 Join Marctraider [0] (~marctraid@82-170-60-93.ip.telfort.nl)
20:12:05amiconnpamaury: Putting code in iram is essential for performance critical stuff on e.g. PP5002
20:12:14mitk*and
20:12:30amiconnBut then, plugins using iram do so for performance reasons, and also have to stop playback
20:13:09amiconnSo imo it's not necessary to implement iram relocation. Just don't allow loading two plugins using iram at the same time by convention
20:14:57 Join Stephen__ [0] (~S@86.45.50.221)
20:29:17amiconndomonoky: rbutil should at least default to the same 'lame' options as the build system if it is supposed to create an even remotely sane voice file for hwcodec
20:29:36Stephen__JdGordon, ping
20:29:46JdGordonpong
20:30:03Stephen__whats the syntax for a conditonal %Lt ?
20:30:19domonokyamiconn: true.
20:31:07JdGordon%?Lt<no title|title> i tihnk
20:31:13JdGordonor the other way around :)
20:31:24Stephen__Ah right that's what I thougth
20:31:28Stephen__thought*
20:31:29JdGordonor %?Lt<title>
20:31:47 Quit mitk (Quit: Leaving)
20:32:04Stephen__thanks
20:32:17 Join Limarus [0] (~limarus@77-253-37-223.adsl.inetia.pl)
20:33:12 Quit Limarus (Read error: Connection reset by peer)
20:33:37 Join Limarus [0] (~limarus@77-253-37-223.adsl.inetia.pl)
20:34:33Limarus#Hi :)
20:35:17LimarusAnyone noticed that build r25107 is not able to download?
20:36:43 Part Limarus
20:38:09 Quit Marctraider (Ping timeout: 276 seconds)
20:38:18 Join Marctraider [0] (~marctraid@82-170-60-93.ip.telfort.nl)
20:38:31 Quit CGL (Remote host closed the connection)
20:40:38 Join CGL [0] (~CGL@190.79.151.231)
20:48:30 Join Limarus [0] (~limarus@77-253-37-223.adsl.inetia.pl)
20:48:36 Part Limarus
20:50:00 Join Limar [0] (~4dfd25df@giant.haxx.se)
20:50:41 Quit Battousai (Ping timeout: 276 seconds)
20:52:01 Join webguest78 [0] (~4dfd25df@giant.haxx.se)
20:52:18webguest78is anyone here?
20:52:46pixelmaZagor reported build system quirks before
20:53:17 Quit CGL (Ping timeout: 276 seconds)
20:54:14 Part watto
20:54:26 Join Battousai [0] (~bryan@gentoo/developer/battousai)
20:55:02 Quit Limar (Quit: CGI:IRC (Ping timeout))
20:55:42webguest78anyone know why build r25107 is not in current build page?
20:56:06webguest78so I can't download it ?
20:57:32pixelmathere seem to be issues with the build system currently
20:58:27 Join Buschel [0] (~ab@p54A3CDC7.dip.t-dialin.net)
20:59:32***Saving seen data "./dancer.seen"
20:59:38 Quit chrisb (Ping timeout: 245 seconds)
20:59:44 Quit Battousai (Read error: Operation timed out)
21:00
21:01:46 Join mitk [0] (~mitk@chello089078013146.chello.pl)
21:01:51 Join Battousai [0] (~bryan@gentoo/developer/battousai)
21:01:59webguest78oh, thank you ;)
21:03:17 Quit webguest78 (Quit: CGI:IRC (EOF))
21:04:12 Quit mitk (Client Quit)
21:07:41 Quit pixelma (Disconnected by services)
21:07:42 Join pixelma_ [0] (quassel@rockbox/staff/pixelma)
21:07:44 Quit amiconn (Disconnected by services)
21:07:46 Join amiconn_ [0] (quassel@rockbox/developer/amiconn)
21:07:59 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma)
21:08:12 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn)
21:10:37Stephen__JdGordon, updated my clipart theme to include list title finally. \o/
21:11:21JdGordonwooo!
21:11:51 Quit anewuser ()
21:11:56Stephen__looks much better now
21:12:09 Quit iq (Remote host closed the connection)
21:16:40*TheSeven is getting seriously annoyed by those sudden poweroffs
21:23:45MarctraiderTheSeven: what iPod do you have anyway?
21:25:33 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de)
21:26:24 Join CGL [0] (~CGL@190.79.151.231)
21:28:22TheSevennano 2g and 4g
21:28:37Marctraiderhas it something to do with the 2G rockbox implentation?
21:28:40Marctraideror is it on your 4g
21:29:37FarthenMarctraider: there is no nano 4g rb implementation
21:30:08 Quit Battousai (Ping timeout: 240 seconds)
21:31:05 Join karashata [0] (~karashata@74-220-162-11.wightman.ca)
21:34:11 Join Battousai [0] (~bryan@gentoo/developer/battousai)
21:36:39 Quit Battousai (Read error: Connection reset by peer)
21:37:56 Join Battousai [0] (~bryan@gentoo/developer/battousai)
21:40:37 Quit Battousai (Remote host closed the connection)
21:40:51 Join Battousai [0] (~bryan@gentoo/developer/battousai)
21:41:48 Join froggyman [0] (~sopgenort@pool-72-69-220-42.chi01.dsl-w.verizon.net)
21:43:37 Join planetbeing__ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net)
21:45:24 Quit planetbeing_ (Ping timeout: 264 seconds)
21:45:25 Join grndslm [0] (~grndslm@174-126-14-4.cpe.cableone.net)
21:46:38 Quit bluebrother (Disconnected by services)
21:46:39 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother)
21:48:17 Join domonoky1 [0] (~Domonoky@g229174127.adsl.alicedsl.de)
21:50:11 Quit domonoky (Read error: Connection reset by peer)
21:50:48 Quit JdGordon (Ping timeout: 240 seconds)
21:53:04 Quit Buschel (Ping timeout: 276 seconds)
21:56:38 Quit shaggy-h (Ping timeout: 240 seconds)
21:57:42 Quit Strife89 (Quit: I need a funny quit slogan. :P)
22:00
22:00:10 Quit liar (Ping timeout: 245 seconds)
22:02:10 Quit chaos (Read error: Operation timed out)
22:02:37 Join chaos [0] (~chaos@gentoo/user/ch4os)
22:07:42 Join DataGhost [0] (~dataghost@192-18-ftth.onsnetstudenten.nl)
22:07:42 Quit DataGhost (Changing host)
22:07:42 Join DataGhost [0] (~dataghost@unaffiliated/dataghost)
22:08:15 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
22:15:57 Quit tvelocity (Quit: Αποχώρησε)
22:21:54 Quit Zagor (Quit: Clint excited)
22:23:55MarctraiderFarthen: i see
22:23:59Marctraiderso its the 2G :o
22:27:21 Join chrisb [0] (~chrisb@pool-71-175-246-16.phlapa.east.verizon.net)
22:31:42bluebroth3rTomis: if you want to test it, my current OS X TTS work is in svn, and binaries are around at http://tinyurl.com/rbutil-dev . This uses the Speech Synthesis Manager, not "say" as this allows more adjustments. Also, the aiff -> wav issue has been solved. Using say would also raise the additional issue of dealing with compressed aiff (at least on 10.6)
22:34:28 Join _arbingordon [0] (~w@c-71-226-248-30.hsd1.pa.comcast.net)
22:34:28 Join Llorean1 [0] (~DarkkOne@adsl-99-158-46-229.dsl.hstntx.sbcglobal.net)
22:34:36 Quit Kohlrabi (Read error: Operation timed out)
22:34:38 Join Kohlrabi [0] (~Kohlrabi@frustum.nosebud.de)
22:35:48 Quit Llorean (Ping timeout: 240 seconds)
22:36:48 Quit arbingordon (Ping timeout: 240 seconds)
22:39:15CIA-5New commit by 03amiconn (r25108): Move (small) data into DRAM on PP5020, it's ~4.5% faster that way. Closes about half of the performance gap towards PP5022. The (relatively large) ...
22:40:45 Nick Llorean1 is now known as Llorean (~DarkkOne@adsl-99-158-46-229.dsl.hstntx.sbcglobal.net)
22:40:52 Quit Llorean (Changing host)
22:40:52 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean)
22:43:38 Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net)
22:45:06 Quit efyx_ (Remote host closed the connection)
22:46:17 Quit planetbeing__ (Ping timeout: 265 seconds)
22:47:08 Quit n17ikh (Ping timeout: 260 seconds)
22:47:16 Join jmslew [0] (~jmslew@84.36.5.111)
22:52:09 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com)
22:53:09 Join Tomis2 [0] (~Tomis@70.134.66.208)
22:53:29 Quit Tomis (Read error: Connection reset by peer)
22:53:29 Nick Tomis2 is now known as Tomis (~Tomis@70.134.66.208)
22:54:43 Quit planetbeing_ (Quit: planetbeing_)
22:56:15 Join planetbeing_ [0] (~planetbei@32.153.242.114)
22:58:00 Quit _arbingordon (Ping timeout: 264 seconds)
22:59:36***Saving seen data "./dancer.seen"
23:00
23:00:01 Quit planetbeing (Ping timeout: 248 seconds)
23:00:02 Nick planetbeing_ is now known as planetbeing (~planetbei@32.153.242.114)
23:04:15 Join archivator [0] (~archivato@stu0279.keble.ox.ac.uk)
23:05:39 Quit Zarggg (Quit: Zarggg)
23:05:56 Quit Tomis (Quit: Tomis)
23:09:44 Join kugel_ [0] (~kugel@e178125097.adsl.alicedsl.de)
23:09:47 Quit evilnick_B (Quit: Page closed)
23:09:54 Quit kugel (Disconnected by services)
23:09:58 Nick kugel_ is now known as kugel (~kugel@e178125097.adsl.alicedsl.de)
23:10:04 Quit kugel (Changing host)
23:10:04 Join kugel [0] (~kugel@rockbox/developer/kugel)
23:10:23 Quit FOAD (Ping timeout: 260 seconds)
23:12:11 Join FOAD [0] (~dok@dinah.blub.net)
23:17:31 Quit Sajber^ (Read error: Connection reset by peer)
23:23:55 Join planetbeing_ [0] (~planetbei@32.153.242.114)
23:25:16 Quit hebz0rl (Quit: Ex-Chat)
23:30:08 Join Tomis [0] (~Tomis@70.134.66.208)
23:33:29 Quit TMM (Quit: Ex-Chat)
23:34:18 Join sinthetek [0] (~sinthetek@cpe-071-076-249-163.triad.res.rr.com)
23:34:19 Quit planetbeing_ (Read error: Connection reset by peer)
23:35:44 Join planetbeing_ [0] (~planetbei@32.153.242.114)
23:38:36 Quit Farthen (Quit: help)
23:40:27 Quit kugel (Remote host closed the connection)
23:40:38 Join TMM [0] (~hp@pdpc/supporter/professional/TMM)
23:41:51 Part TMM
23:41:57 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk)
23:42:34 Quit planetbeing_ (Quit: planetbeing_)
23:46:39 Part Altreus
23:49:21 Quit bertrik (Quit: De groeten)
23:50:14 Quit pamaury (Quit: Page closed)
23:50:36 Join planetbeing_ [0] (~planetbei@198.107.160.116)
23:52:53 Join anewuser [0] (anewuser@unaffiliated/anewuser)
23:56:39 Join Zarggg [0] (~zarggg@2001:0:4137:9e74:0:fbf1:beb1:ba3d)

Previous day | Next day