| 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:14 | amiconn | kugel: I wonder whether eabi gcc stumbles upon the packed structs |
| 00:08:33 | kugel | short enums, rather |
| 00:08:36 | kugel | I think I found 1 problem |
| 00:10:40 | kugel | doom 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:50 | gevaerts | if that's true, I'd consider eabi to be broken |
| 00:12:27 | pamaury | I 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:34 | amiconn | Accessing enums via pointers isn't bad |
| 00:13:15 | amiconn | It's just that programmers need to learn that each enum is a different type, which is not compatible with another enum |
| 00:13:26 | kugel | right |
| 00:14:21 | kugel | pamaury: no, I think you confuse me. I saw a different chance for saving but you fixed that already (IIRC) |
| 00:14:26 | amiconn | Iirc 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:52 | kugel | -fno-short-enums |
| 00:14:58 | kugel | I'm not sure if that's the way to go |
| 00:15:10 | pamaury | kugel: 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:31 | amiconn | I would prefer to avoid it if possible. But it might turn out to be impossible |
| 00:16:13 | kugel | amiconn: 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:21 | amiconn | Is doom still actively maintained? There might be upstream fixes if so |
| 00:16:36 | amiconn | That won't help |
| 00:16:45 | pamaury | amiconn: it was you, see ^ |
| 00:17:05 | amiconn | It 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:22 | kugel | well, 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:12 | bluebrother | pixelma: 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:33 | bluebrother | so 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:34 | Unhelpful | kugel, 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:45 | Unhelpful | unless there's a bug, anyway, ;) |
| 00:20:49 | bluebrother | AlexP: can you check the output of pkg-config −−silence-errors −−libs speex speexdsp |
| 00:21:12 | kugel | doom has one case where it's accessed over an int pointer |
| 00:21:13 | Unhelpful | kugel: i did a lot of short enum fixes to get doom and mpegplayer compiling without warnings for them |
| 00:21:13 | amiconn | [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:28 | AlexP | bluebrother: "-lspeex -lspeexdsp" |
| 00:21:39 | Unhelpful | kugel: then you need to fix that - either store enum values in an int, or use a pointer to the correct type. |
| 00:21:44 | bluebrother | AlexP: can you check the version of libspeex? |
| 00:22:13 | AlexP | 1.5.0 I think |
| 00:22:14 | kugel | Unhelpful: sure. but the latter isn't possible. couldn't the pointer be changed to a char * one? |
| 00:23:06 | Unhelpful | kugel: but that breaks on long-enum builds. an enum-valued int is preferable if you simply must access via int* |
| 00:23:23 | AlexP | bluebrother: I looked at /usr/lib/libspeex.so for that |
| 00:23:28 | kugel | the 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:33 | bluebrother | AlexP: huh? The speex website says that the most recent (unstable) release is 1.2rc1 |
| 00:23:48 | Unhelpful | amiconn: sorry, had missed that bit... also twasn't you said that would make eabi broken. |
| 00:24:07 | AlexP | bluebrother: ah right, speexdec gives 1.2rc1 |
| 00:24:14 | scorche | if anyone has any opinions or refinements for http://www.rockbox.org/wiki/GSoCOrgApp2010 , please feel free to go at it. |
| 00:24:24 | AlexP | bluebrother: I'm not sure how to get the library version directly? |
| 00:24:49 | bluebrother | AlexP: no idea, I use my package manager for that ;-) |
| 00:25:06 | AlexP | speex (which provides it all) is at 1.2rc1 |
| 00:25:08 | bluebrother | but this is strange, 1.2rc1 should provide the required symbols in libspeex.so |
| 00:25:08 | scorche | same 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:43 | AlexP | hehe :) |
| 00:26:56 | bluebrother | need to get some sleep for tonight. Will check that later. Please ping me if I forget about it. |
| 00:27:05 | AlexP | sure, thanks for looking :) |
| 00:28:03 | amiconn | kugel: 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:58 | kugel | it's accessed via int* in a generic struct (default_t) |
| 00:29:51 | kugel | it'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:27 | CIA-5 | New commit by amiconn (r25098): Coldfire targets: tiny optimisation. |
| 00:51:12 | amiconn | kugel: Where does that access happen? |
| 00:52:00 | kugel | m_misc.c:857 |
| 00:54:21 | Mode | "#rockbox +o scorche" by ChanServ (ChanServ@services.) |
| 00:54:56 | kugel | that casting to (void*) hides problems.. |
| 00:56:28 | | Join froggyman [0] (~sopgenort@pool-72-69-220-42.chi01.dsl-w.verizon.net) |
| 00:56:34 | Topic | "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:42 | Mode | "#rockbox -o scorche" by ChanServ (ChanServ@services.) |
| 00:59:03 | *** | Saving seen data "./dancer.seen" |
| 00:59:30 | amiconn | Ah, default_compatibility_level and precache |
| 00:59:50 | amiconn | The latter is a bool, but that will also cause problems if bools are byte-sized |
| 01:00 |
| 01:00:01 | kugel | isn't the same issue with bools in theory? |
| 01:00:46 | kugel | the 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:13 | kugel | there 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:02 | amiconn | Hmm, iiuc attribute((mode(word))) for the enums and bools in question *might* help |
| 01:08:19 | kugel | I 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:34 | earHurts01 | xxx |
| 01:10:43 | earHurts01 | In a rockbox function, is it safe to allocate, say, 1500 bytes on the stack? |
| 01:10:46 | amiconn | Another 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:51 | earHurts01 | eg. char buffer[1024]; int otherstuff; int morestuff; |
| 01:11:21 | amiconn | I wonder why they have separate fields for the location pointer |
| 01:12:11 | TheSeven | gevaerts: around? |
| 01:12:13 | | Quit Farthen (Ping timeout: 276 seconds) |
| 01:12:38 | | Quit advcomp2019 (Read error: Connection reset by peer) |
| 01:12:41 | kugel | well, the enum in default_s is not used for casting to the appropriate pointer |
| 01:12:45 | TheSeven | ah, damn |
| 01:13:04 | TheSeven | anyone else around who knows how rockbox handles usb mass storage transfers? |
| 01:15:48 | amiconn | kugel: It isn't, but it could be |
| 01:17:45 | amiconn | earHurts01: Depends on what else is on the stack, and in which thread you're doing this |
| 01:20:17 | earHurts01 | assume I'm only calling file functions (lseek, read, write) and I'm in the main thread. |
| 01:21:17 | earHurts01 | (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:12 | earHurts01 | In docs/API, it says write() is not supported? |
| 01:30:30 | earHurts01 | 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:34 | earHurts01 | ???? |
| 01:31:42 | Unhelpful | amiconn: 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:05 | saratoga | earHurts01: IIRC the main thread stack is several KB so thats probably safe |
| 01:36:30 | earHurts01 | thanks |
| 01:38:24 | kugel | unfortunately, doom has more problems |
| 01:40:33 | kugel | Z_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:13 | kugel | that happens when selecting the difficulty in freedoom.wad |
| 01:43:19 | | Part froggyman |
| 01:46:18 | | Quit banzairun (Quit: CGI:IRC (EOF)) |
| 01:49:01 | kugel | it must be another short enum problem. doom functions fine with -fno-short-enums |
| 01:54:35 | kugel | __attribute__((mode(word))) makes an enum indeed 4byte wide |
| 01:57:40 | earHurts01 | does rockbox have an int32 type? |
| 01:59:47 | earHurts01 | ah, 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:14 | kugel | ha! -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:45 | CIA-5 | New commit by theseven (r25099): iPod Nano 2G FTL performance enhancements. Still not quite as fast as the OFW, but way better than before. |
| 04:01:04 | CIA-5 | New commit by theseven (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:41 | CIA-5 | New commit by theseven (r25101): Fix bootloader red |
| 04:16:47 | | Quit DaCapn (Read error: Operation timed out) |
| 04:17:50 | froggyman | is the most current, in depth list of players? http://www.rockbox.org/wiki/DeviceChart |
| 04:17:55 | froggyman | or is there a newer one? |
| 04:19:00 | CIA-5 | New commit by theseven (r25102): Add the raw battery voltage to the Nano2G battery debug screen |
| 04:19:57 | CIA-5 | New commit by theseven (r25103): Some Nano2G define corrections / updates |
| 04:20:48 | | Join krazykit` [0] (~kkit@ppp-70-225-142-162.dsl.ipltin.ameritech.net) |
| 04:20:50 | CIA-5 | New commit by theseven (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:19 | froggyman | is the most current, in depth list of players? http://www.rockbox.org/wiki/DeviceChart or is there a newer one? |
| 04:48:57 | krazykit` | it's missing the nano2g and a couple of scarcer targets |
| 04:49:38 | krazykit` | er, and the AMS sansas |
| 04:50:57 | | Join saratoga_lab [0] (~9803c255@gateway/web/freenode/x-jxukfravxprarxsy) |
| 04:51:06 | saratoga_lab | froggyman: the current_status wiki page is probably a lot better |
| 04:51:09 | Llorean | The most up to date list of targers is /tools/configure |
| 04:51:13 | Llorean | *targets |
| 04:51:25 | Llorean | Just 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:41 | froggyman | Llorean: 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:38 | Hillshum | froggyman: The Buyer's Guide wiki page? Don't know how uptodate that is |
| 04:54:32 | | Quit dys (Ping timeout: 276 seconds) |
| 04:54:50 | saratoga_lab | Llorean: probably not, the Clip has 2.3x the RAM |
| 04:54:59 | | Join dys [0] (~andreas@krlh-5f72e2f8.pool.mediaWays.net) |
| 04:55:09 | saratoga_lab | at least i think the ifp was a 1 MB swcodec target |
| 04:55:13 | Llorean | Yeah |
| 04:55:19 | Llorean | At one point Rockbox was actually playing music on it though |
| 04:55:51 | Llorean | If 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:59 | saratoga_lab | we're probably bloated way past that :) |
| 04:56:00 | | Quit Barahir (Ping timeout: 256 seconds) |
| 04:56:20 | saratoga_lab | i guess it depends how much of the core you can ifdef out |
| 04:56:33 | Llorean | Probably strip it down to more or less what the Recorder gets |
| 04:56:49 | Llorean | And since it's flash, it doesn't need much buffer. |
| 04:57:36 | JdGordon | wait, did it ever play music? I thought it didnt |
| 04:57:49 | saratoga_lab | it could play vorbis at one point I think |
| 04:57:54 | saratoga_lab | just not very well |
| 04:58:15 | saratoga_lab | and probably only a subset of vorbis encoding options |
| 04:58:18 | Llorean | JdGordon: 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:52 | Llorean | A 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:05 | Llorean | Since it's some 60mhz Panasonic CPU |
| 04:59:09 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:02:49 | saratoga_lab | wow the ifp emulator tomal wrote worked as a GDB stub |
| 05:03:52 | Llorean | Would that be a starting place for the ARM emulator summer of code project idea? |
| 05:04:43 | saratoga_lab | yeah that or Toni's emulator |
| 05:04:47 | saratoga_lab | or skyeye |
| 05:04:50 | saratoga_lab | any would work |
| 05:05:18 | saratoga_lab | apparently 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:35 | saratoga_lab | just put the binary in ROM and you'd have plenty of RAM |
| 05:05:39 | Llorean | 8MB ROM and 1MB RAM? |
| 05:05:43 | Llorean | Or is it 8 megabit? |
| 05:05:44 | saratoga_lab | yeah |
| 05:06:01 | saratoga_lab | ah mbit |
| 05:06:09 | saratoga_lab | but still big enough |
| 05:06:13 | Llorean | Yeah |
| 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:06 | Eq-547-682-357 | Quick question |
| 06:19:28 | Eq-547-682-357 | I'm using rockbox after ages |
| 06:19:42 | Eq-547-682-357 | Where should I drag and drop my files on the drive? |
| 06:19:55 | Hillshum | After ages? |
| 06:19:56 | Eq-547-682-357 | Is it inside the .rockbox folder or outside? |
| 06:20:02 | Hillshum | What files? |
| 06:20:06 | Eq-547-682-357 | Music files |
| 06:20:11 | Eq-547-682-357 | yeah broke my old ipod |
| 06:20:16 | Eq-547-682-357 | got a new one |
| 06:21:35 | Hillshum | You can put the files anywhere |
| 06:21:47 | Eq-547-682-357 | Ah |
| 06:21:51 | Eq-547-682-357 | kk |
| 06:22:00 | Hillshum | Probably best to keep them in a folder dedicated to music, outside the .rockbox folder |
| 06:22:25 | Eq-547-682-357 | That's what I was thinking..I was wondering if the files won't be detected if it was outside the .rockbox folder |
| 06:22:28 | Eq-547-682-357 | danke danke |
| 06:24:14 | | Quit Torne (Ping timeout: 276 seconds) |
| 06:24:17 | | Join Torne [0] (torne@rockbox/developer/Torne) |
| 06:28:12 | Hillshum | The 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:42 | pixelma | bluebrother: 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:48 | Tomis | i have a 10.5 ppc pixelma, the bootload installer is broken for nano 2g, the rockbox installer seams towork fine though |
| 06:58:41 | pixelma | with installer you mean the Rockbox Utility? |
| 06:59:01 | Tomis | yes |
| 06:59:11 | *** | Saving seen data "./dancer.seen" |
| 06:59:46 | pixelma | did you ever try to generate voice files or talk clips for your target? |
| 07:00 |
| 07:00:10 | Tomis | nope |
| 07:00:52 | pixelma | I'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:13 | pixelma | that'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:24 | Tomis | apple 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:21 | pixelma | not 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:17 | pixelma | the 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:26 | pixelma | standalone too |
| 07:10:56 | Tomis | yea i think apple's TTS to file outputs .aiff |
| 07:14:17 | pixelma | with 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:55 | pixelma | Tomis: how did you install the bootloader then? |
| 07:46:15 | Tomis | used 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:53 | nosa- | 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:58 | Tomis | http://build.rockbox.org/ nosa- |
| 08:32:30 | Tomis | that's the "current build" link at the top left of the rockbox website |
| 08:33:30 | nosa- | ahh ok |
| 08:41:03 | | Join Regika [0] (~Shawnboy1@adsl-75-19-46-151.dsl.irvnca.sbcglobal.net) |
| 08:41:19 | Regika | Anyone 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:30 | CIA-5 | New commit by pamaury (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:40 | pamaury | build server doesn't work ? |
| 10:13:28 | | Quit GodEater (Read error: Operation timed out) |
| 10:17:37 | Zagor | pamaury: checking... |
| 10:18:18 | Zagor | something happened with the network. "Ending round due to lack of clients" |
| 10:18:30 | Zagor | I'll restart the round |
| 10:19:01 | | Join efyx_ [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 10:21:10 | Zagor | hmm, something is broken |
| 10:22:04 | | Join mt [0] (~mtee@rockbox/developer/mt) |
| 10:23:49 | mt | I was wondering if we could add completing the new website to the gsoc ideas list, or building a whole new design ? |
| 10:25:06 | gevaerts | mt: in principle, yes. I'm afraid that the website rework will attract lots of people with very questionable ability though |
| 10:26:52 | pamaury | Did 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:02 | gevaerts | I'd still like that, but it depends (in my mind at least) on address-independent plugin loading |
| 10:28:10 | gevaerts | Otherwise it doesn't really fix anything |
| 10:28:29 | pamaury | indeed |
| 10:28:42 | pamaury | or it depends on relocations |
| 10:29:40 | gevaerts | Adding a coff or elf loader or getting elf2flt to work for rockbox might be a fun project though |
| 10:29:57 | pamaury | what is elf2flt ? |
| 10:30:06 | * | gevaerts doesn't really know how much work those would be |
| 10:30:19 | gevaerts | http://www.uclinux.org/bFLT/ |
| 10:30:34 | mt | gevaerts : Yes, I thought it would do just that, but they could be filtered with a good qualifying task. |
| 10:30:52 | pamaury | Loading 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:00 | pamaury | But this table can be put in a file I guess |
| 10:31:51 | gevaerts | mt: maybe. I'm not convinced though |
| 10:32:45 | mt | I'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:07 | pixelma | and I'm also not convinced by the "new" design |
| 10:33:55 | pamaury | gevaerts: 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:58 | mt | pixelma: You mean the idea itself ? Or the specific new design that was started on the forums ? |
| 10:34:18 | gevaerts | pamaury: I haven;t investigated it very much yet |
| 10:34:26 | pixelma | the latter |
| 10:35:35 | pamaury | gevaerts: 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:48 | pixelma | and 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:37 | mt | If 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:45 | mt | I haven't looked at that design's code to judge. But hardcoded stuff like that is definitely not good. At least imo. :) |
| 10:48:10 | linuxstb | mt: 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:50 | linuxstb | Plus of course dealing with everyone complaining about it and trying to reach a concensus... |
| 10:49:02 | pamaury | which is not coding... |
| 10:49:27 | pamaury | but happens in any coding task also :) |
| 10:49:51 | linuxstb | That's true... ;) |
| 10:51:06 | mt | Although a consensus on how a specific driver works entails much less hassle than that regarding the website. :) |
| 10:51:53 | pamaury | Indeed, you just have to be obscure enough to have the others say wait&see. |
| 10:52:01 | pamaury | ;-) |
| 10:52:39 | mt | linuxstb: 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:32 | mt | pamaury: 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:25 | pamaury | nice green delta, hope I didn't break anything :) |
| 11:25:04 | pamaury | gevaerts: 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:34 | gevaerts | pamaury: I don't see a need to drop the rb-like structure |
| 11:32:20 | pamaury | gevaerts: 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:05 | pamaury | Of course, the the symbol table approach requires more work so more code so increase binsize :) |
| 11:36:48 | gevaerts | the symbol table approach would also need the full table somewhere |
| 11:37:05 | gevaerts | rb doesn't need a copy per plugin |
| 11:37:06 | pamaury | You can store it in a file |
| 11:37:11 | | Quit einhirn (Read error: Connection reset by peer) |
| 11:37:46 | gevaerts | The code to handle that will be bigger than just having the table |
| 11:38:02 | pamaury | perhaps :) |
| 11:39:20 | gevaerts | Anyway, 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:04 | pamaury | make 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:14 | gevaerts | One 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:05 | pamaury | yes. currently, how do plugins use iram ? There is a reserved region no ? |
| 11:42:11 | gevaerts | yes |
| 11:42:54 | gevaerts | We also have to be careful with relocation and iram. We don't want to slow down iram use |
| 11:44:28 | pamaury | I 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:46 | pamaury | Anyway, multiple plugins means managing iram and also the place where plugins are loaded (audio buffer ?) |
| 11:49:13 | gevaerts | Yes, it means a lot of things :) |
| 11:50:16 | pamaury | is the audio buffer contiguous or does it support being split ? |
| 11:50:26 | pamaury | (I mean the part used for buffering) |
| 11:50:45 | | Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) |
| 11:53:19 | mt | pamaury : 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:03 | CIA-5 | New commit by uchida (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:19 | CIA-5 | New commit by uchida (r25107): Oops. forget static. |
| 12:24:28 | gevaerts | Zagor: builds seem to have stopped again |
| 12:24:42 | Zagor | yes, 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:53 | TheSeven | gevaerts: 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:43 | TheSeven | I'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:21 | notlistening | Right a question on GSoC how big and technical do the projects need to be? |
| 13:35:27 | | Quit grndslm (Quit: Leaving) |
| 13:35:30 | linuxstb | three months full-time work... |
| 13:35:42 | linuxstb | (or maybe two months, I forget...) |
| 13:36:30 | notlistening | I 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:03 | notlistening | not two months works i guess |
| 13:37:19 | gevaerts | TheSeven: let me check the details... |
| 13:37:23 | notlistening | lol maybe for me |
| 13:38:38 | TheSeven | gevaerts: 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:23 | TheSeven | what 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:37 | gevaerts | TheSeven: you might want to play with WRITE_BUFFER_SIZE in usb_storage.c |
| 13:40:58 | TheSeven | i already set that to 64K to prevent that 24K/24K/8K splitting |
| 13:41:25 | TheSeven | haven't measured the impact of that |
| 13:41:50 | | Quit mt (Ping timeout: 240 seconds) |
| 13:41:58 | TheSeven | let me check |
| 13:42:18 | gevaerts | The "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:20 | TheSeven | hm, NAND is only active 64% of the FTL busy time |
| 13:45:05 | gevaerts | TheSeven: you might want to look at FS #10239. Unfortunately I suspect that it doesn't apply cleanly anymore... |
| 13:45:11 | TheSeven | 24k vs. 64k => 16% performance difference |
| 13:45:30 | TheSeven | that buffer is allocated from the audio buffer anyways, isn't it? |
| 13:45:44 | AlexP | gevaerts: do you think the whole re-locatable plugins/pebbles/type thing is enough for GSOC? |
| 13:46:04 | gevaerts | AlexP: I don't know. I have some doubts |
| 13:46:20 | | Join AsusFreak [0] (~c1003c16@giant.haxx.se) |
| 13:46:31 | AlexP | As it'd be a nice thing to have - maybe we could flesh it out a bit |
| 13:47:01 | gevaerts | TheSeven: on everything except imx31 and tcc, yes. The different values aren't for RAM reasons, just performance :) |
| 13:47:44 | gevaerts | If 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:28 | TheSeven | it was at 24k before, but 64k is significantly better |
| 13:48:36 | TheSeven | i think this needs to be moved to the device config |
| 13:49:09 | TheSeven | i'll do the "ifndef define" variant in usb_storage.c probably |
| 13:49:55 | TheSeven | a 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:01 | TheSeven | nand busy only 40% of the time |
| 13:51:20 | gevaerts | You 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:30 | TheSeven | overall CPU usage during FTL activity is still 53% |
| 13:52:30 | TheSeven | didn't we commit that patch to make usb work at all on nano2g? |
| 13:53:06 | gevaerts | no, that's something else |
| 13:53:18 | TheSeven | however, i think those measurements show that the slowdown is clearly coming from the FTL, not the USB handling |
| 13:54:22 | gevaerts | yes, but r24333 causes a 5% to 10% slowdown on PP, so if you're chasing the OF performance, it will count |
| 13:54:39 | pamaury | TheSeven: 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:41 | TheSeven | we're more than 50% behind that right now |
| 13:55:08 | TheSeven | (even though we're already 200% better than yesterday) |
| 13:56:52 | gevaerts | AlexP: 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:12 | pamaury | gevaerts: 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:39 | pamaury | There is only one tricky point with the stack data however :( |
| 14:00 |
| 14:00:57 | gevaerts | pamaury: by then the plugin might have pointers all over the place, located in malloced buffers, and pointing to potentially anywhere |
| 14:01:05 | gevaerts | So I think you can't :) |
| 14:01:53 | pamaury | Yes 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:04 | pamaury | Anyway, 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:55 | Torne | It 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:33 | kugel | gevaerts: shouldn't we add "relocatable and multiple plugins" to the ideas list? |
| 14:16:16 | gevaerts | Feel free |
| 14:17:04 | pixelma | reminds 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:38 | kugel | allocating 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:39 | TheSeven | 8 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:44 | TheSeven | argh! |
| 14:52:19 | TheSeven | why 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:33 | AsusFreak | Hi. 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:22 | kugel | neither list is a personal wishlist |
| 16:09:09 | kugel | but the radio related code definitely needs a overhaul, the apps/ and the firmware/ part are a pure mess |
| 16:11:54 | mt | What about the multi-codec architecture for the video player ? Why isn't it there ? |
| 16:12:30 | Zagor | it is |
| 16:12:50 | Zagor | "Multi-codec architecture for mpegplayer" |
| 16:12:58 | mt | ah .. just seen it. I was looking at the "codecs" section |
| 16:13:01 | mt | my bad. |
| 16:18:10 | | Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) |
| 16:22:33 | Unhelpful | pamaury, 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:22 | linuxstb | kugel: But do you think a radio code rework is worthy of a SoC project? |
| 16:24:34 | kugel | not sure, probably not |
| 16:27:23 | | Quit Seed (Quit: cu, Andre) |
| 16:27:27 | pamaury | Unhelpful: I don't understand the "with plugin relocations specified by index" and the rest... :) |
| 16:28:41 | Unhelpful | pamaury: 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:55 | Unhelpful | yes-this-means-coding-relocation-ourselves :/ |
| 16:30:54 | pamaury | Ok, 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:43 | Torne | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> |
| 16:33:47 | Torne | oops |
| 16:33:49 | Torne | sorry |
| 16:35:47 | kugel | Torne: 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:01 | Torne | kugel: we discussed it before |
| 16:36:10 | Torne | it's possible, but would require fiddling with the bootloader |
| 16:36:35 | Torne | relocatable 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:59 | kugel | do we really want relocatable codecs? |
| 16:37:18 | Torne | why not? |
| 16:37:46 | kugel | from what I gathered, PIC costs a lot of performance and code size, |
| 16:37:52 | Torne | PIC is not involved |
| 16:38:00 | Torne | there is zero performance cost |
| 16:38:11 | Torne | and no runtime size cost (only a disk cost for the relocs) |
| 16:38:36 | Torne | relocatable doesn't mean position independant; position independant code *doesn't* require relocation :) |
| 16:39:12 | kugel | the main binary could memmove itself as well, bootloader fiddling is not needed |
| 16:39:20 | Torne | yes. we discussed all this. |
| 16:39:28 | Torne | many months ago ;) |
| 16:39:34 | kugel | I'm just thinking it's easier for now ;) |
| 16:40:01 | Torne | I really don't think it is, personally |
| 16:40:11 | Torne | but hey |
| 16:40:39 | kugel | well, the idea is added to the GSoC list, let's hope we find someone ;) |
| 16:40:42 | Torne | building the plugins as relocatable is the slightly fiddly part; actually loading them and applying relocs is incredibly easy |
| 16:40:59 | Torne | it only really gets hard if you consider loading into audiobuffer |
| 16:41:04 | Torne | which is something that can be done later |
| 16:41:48 | kugel | sure, for a start it would be nice to battery_bench while playing bubbles :) |
| 16:42:06 | Torne | right, but you could do that by just dividing up plugin_buffer |
| 16:42:18 | Torne | if 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:41 | Torne | without PIC is the normal way.. |
| 16:44:43 | Torne | PIC is a special case |
| 16:45:07 | Torne | you build an elf binary just as we do now, but link with -r to keep all the relocations |
| 16:45:53 | Torne | then you feed it to elf2flt to turn it into a simpler format, still with the relocations |
| 16:46:02 | Torne | when you load it you just go to each reloc entry and add the right offset |
| 16:46:10 | Torne | then throw the relocation data away |
| 16:46:51 | Torne | the resulting assembly code is identical to if you just ran it through objdump with the right target address |
| 16:47:06 | Torne | it's slightly complicated by things like iram, but that's the basic idea. |
| 16:47:25 | Torne | the conversion step is not technically required, either, but we probably don't want to implement an elf loader. |
| 16:48:43 | kugel | ah, cool. I didn't know about -r |
| 16:49:06 | Torne | all PIC does to this process is make it so that there are less relocations |
| 16:49:18 | Torne | you end up hving all the code refer to a global offset table |
| 16:49:23 | Torne | and then you just need one big mass of relocs in th etable. |
| 16:49:33 | Torne | this means you can share more pages between processes that map the same library |
| 16:49:36 | Torne | but we don't care about that. |
| 16:50:24 | kugel | just port ld and objdump (and strip?) to rockbox. done :P |
| 16:50:26 | Torne | so 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:10 | Torne | i'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:31 | pamaury | yes, but there is the iram issue, no ? |
| 17:00 |
| 17:02:33 | Torne | it should be fine |
| 17:02:44 | | Quit petur (Quit: *plop*) |
| 17:02:53 | Torne | but the exact linker script required to make it work would need writing :) |
| 17:03:42 | gevaerts | Torne: with bFLT? |
| 17:03:50 | Torne | yah |
| 17:03:56 | Torne | as long as you don't expect things to be able to share iram |
| 17:04:11 | pamaury | you're cheating :) |
| 17:04:19 | Torne | put the iram addresses int he linker script, which is fine as long as they don't overlap 0->pluginsize |
| 17:04:24 | Torne | then strip the relocs for them |
| 17:04:30 | Torne | will probably work. |
| 17:04:36 | * | gevaerts *does* expect things to share iram! :) |
| 17:04:46 | Torne | well, then no :) |
| 17:05:21 | pamaury | we can still implement something like alloc_iram and free_iram so the linker script is still works |
| 17:05:35 | pamaury | *-is |
| 17:05:57 | pamaury | Anyway, if you share iram you have to manage it so it has to be dynamical |
| 17:06:04 | gevaerts | iram also has code |
| 17:06:08 | Torne | pamaury: No, we can't implement that |
| 17:06:14 | pamaury | why ? |
| 17:06:17 | Torne | We can't share iram unless we also know how to relocate references to iram |
| 17:06:19 | pamaury | Ah, code :) |
| 17:06:22 | Torne | which is not possible in bFLT without modification |
| 17:06:29 | Torne | because it only has three sections |
| 17:06:50 | pamaury | Indeed, if you share iram code, that's impossible with bFLT |
| 17:07:13 | Torne | do we care, though? |
| 17:07:27 | Torne | what's the need for it? |
| 17:07:54 | pamaury | is putting code in iram actually a gain ? |
| 17:08:09 | kugel | could we prepend some 0xFFF to the reloc entry to show it's for iram? |
| 17:08:13 | Torne | it doesn't matter if you put code in iram.. |
| 17:08:24 | Torne | kugel: only if we wrote our own tool |
| 17:08:32 | Torne | pamaury: you can't *refer to addresses in iram at all* |
| 17:08:52 | Torne | it would be impossible to use iram for anything except malloc-like behaviour as you said |
| 17:08:58 | kugel | Torne: if we do that we can just as well add iram sections |
| 17:09:05 | Torne | you can't store any code or any variables there, unless it's a fixed location or you can relocate it |
| 17:09:10 | TheSeven | by pipelining that, we could actually get 80% more performance yet again |
| 17:09:13 | | Join patgodo [0] (~chatzilla@g229063126.adsl.alicedsl.de) |
| 17:09:35 | Torne | kugel: yes |
| 17:09:46 | kugel | although prepending 0xfff wouldn't involve changing the "standard" header |
| 17:09:53 | TheSeven | hm,,, |
| 17:09:54 | gevaerts | TheSeven: don't very large nand transfers also imply delayed errors? |
| 17:10:01 | pamaury | Then let's add an iram section to bFLT, that shouldn't be too hard |
| 17:10:01 | Torne | kugel: but again this may be difficult, because the way that bFLT works means you can't really do that :) |
| 17:10:06 | Torne | pamaury: yes it will be |
| 17:10:19 | TheSeven | well, i get 64k writes from the usb stack, so i could at least write 64k blocks without further delaying them |
| 17:10:28 | Torne | The format discards the relocation data, and only keeps the relocation site addresses |
| 17:10:33 | TheSeven | it would be a little to handle bad blocks in that case though |
| 17:10:38 | Torne | It relies on the fact that you have linked the binary to be placed at addresses starting at 0 |
| 17:10:41 | TheSeven | it can be done, it's just a bit complex |
| 17:11:04 | Torne | which means that the values ld stores in the actual reloc sites are the offsets from the start |
| 17:11:04 | TheSeven | this would mean merging quite a bit of VFL code into the FTL |
| 17:11:20 | Torne | and 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:35 | TheSeven | right now, i'm writing in 8K steps, and i could almost do 2 of those in parallel |
| 17:11:42 | kugel | yea, I read through bFLT, and it looks like we need to modify it anyway if we want to work with iram |
| 17:11:43 | Unhelpful | in particular APE is now deliberately using all of iram :) |
| 17:11:49 | Torne | also yeah |
| 17:11:59 | Torne | in general, on platforms where iram is faster then most codecs should probably be using all of it, no? |
| 17:12:02 | TheSeven | well, actually this means merging both nand and vfl code into the ftl |
| 17:12:24 | Torne | any time ther eis space there is probably something that can go in iram that will make it faster.. |
| 17:12:27 | Unhelpful | Torne: only when they reasonably can. and i could limit the size of the APE divider reciprocal table... |
| 17:12:49 | Torne | Unhelpful: 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:25 | pamaury | Then 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:33 | Torne | pamaury: but it makes the code that uses iram slower! |
| 17:13:42 | Torne | It doesn't just add two lines |
| 17:14:09 | Torne | If 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:13 | Torne | (or .data) |
| 17:14:18 | | Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.0.152) |
| 17:14:22 | kugel | Unhelpful: 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:27 | Torne | but if you indirect via a pointer returned by a malloc-like then you are now slower |
| 17:14:40 | Torne | pamaury: for there to be any point you need ot be able to put symbols in iram |
| 17:14:45 | Torne | not just store data in iram. |
| 17:15:05 | pamaury | Torne: indeed; then use elf :) |
| 17:15:11 | Torne | and this is only possible if the linker handles it, either the compile-time linker or the runtime linking loader |
| 17:15:43 | saratoga | does 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:50 | pamaury | does elf support all the necessary features for what we want ? |
| 17:15:53 | Torne | saratoga: 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:03 | saratoga | yes I know |
| 17:16:03 | Torne | pamaury: of course, otherwise we couldn't use ELF to link plugins in the first place ;) |
| 17:16:12 | Torne | pamaury: think about it ;) |
| 17:16:16 | Torne | But an ELF loader is big and slow and hard |
| 17:16:38 | Torne | the point of using bFLT is that it's incredibly trivial to load and someone else already wrote the conversion tool |
| 17:17:39 | kugel | Torne: 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:28 | Torne | oh wait |
| 17:18:59 | Torne | pardon me, i'm dumb |
| 17:19:01 | Torne | you don't need to do that |
| 17:19:38 | Torne | if you're going to hack it anyway just add the extra fields to the header |
| 17:20:06 | Torne | oh no, double wait |
| 17:20:09 | Torne | :) |
| 17:20:23 | kugel | you 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:26 | Torne | You might still have a problem, either way |
| 17:20:43 | Torne | the problem is that iram sections have a different LMA and VMA |
| 17:20:57 | Torne | because they're loaded to one place then copied to another |
| 17:21:15 | kugel | LMA/VMA? |
| 17:21:24 | Torne | load address and run address, if you like :) |
| 17:21:31 | pamaury | Is 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:43 | pamaury | *s/I/it |
| 17:21:58 | Torne | pamaury: no, it's not, i realised i was making a mistake :) |
| 17:22:02 | Torne | but it still might be a problem |
| 17:22:03 | TheSeven | recursively 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:32 | pamaury | which 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:43 | Torne | pamaury: what I just said |
| 17:23:03 | kugel | Torne: 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:10 | Torne | .iram is linked AT(iramcopy) which is the address immediately after .data |
| 17:23:25 | Torne | but it's linked to run at PLUGIN_IRAM |
| 17:23:53 | Torne | i.e. the place it's stored in the program load image is not the same as the address it is relocated for. |
| 17:24:01 | dionoea | TheSeven: that would deadlock |
| 17:24:10 | | Part patgodo |
| 17:24:20 | pamaury | Torne: yes but at reloc time you can distinguish between those two types of reloc, no ? |
| 17:24:23 | dionoea | (at least in general, I don't know if/how rockbox mutexes work) |
| 17:24:27 | Torne | They are not types of relocation |
| 17:24:31 | | Quit Marctraider (Ping timeout: 246 seconds) |
| 17:24:35 | Torne | There is nothing to be done at load time |
| 17:24:36 | pamaury | Yes but look at the adress |
| 17:24:43 | Torne | The problem is at link time.. |
| 17:24:44 | | Join Marctraider [0] (~marctraid@82-170-60-93.ip.telfort.nl) |
| 17:25:32 | pamaury | link 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:59 | TheSeven | should we put implementing a usb transfer cache (like a hard drive that has a cache) on mr. someone's todo list? |
| 17:26:35 | kugel | do we want that? |
| 17:26:42 | TheSeven | that's the question |
| 17:26:54 | kugel | usb transfer caches only annoyed me so far |
| 17:26:58 | gevaerts | TheSeven: for write, I have one... |
| 17:27:09 | kugel | linux had that not too long ago, but it disappeared again |
| 17:27:24 | TheSeven | it 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:38 | gevaerts | FS #10239 does most of that |
| 17:28:02 | TheSeven | kugel: actually every dumb usb external hard drive is doing it |
| 17:28:58 | kugel | caches on the device side aren't as bad as ones on the OS side, I guess |
| 17:29:07 | TheSeven | gevaerts: I will try that one when i have the NAND at the maximum possible speed |
| 17:29:33 | TheSeven | kugel: caches on the OS side aren't bad either as long as they are implemented in a sane way |
| 17:30:38 | kugel | a new day, a new nano2g-sktov :) |
| 17:31:08 | TheSeven | really? |
| 17:31:19 | kugel | fs#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:17 | TheSeven | actually it were exactly 2 worms and a dozen stkovs |
| 17:32:29 | | Quit robin0800 (Ping timeout: 256 seconds) |
| 17:32:39 | TheSeven | but that one isn't nice |
| 17:32:44 | TheSeven | a *shutdown stkov*!? |
| 17:33:01 | TheSeven | and the thread name seems to have been damaged by it. bugger. |
| 17:33:16 | TheSeven | can't we place the task information stuff *above* the stack to prevent that? |
| 17:34:46 | kugel | isn't it just a matter of swapping the "const char thread_name[] =" and "char thread_stack[]" lines? |
| 17:35:36 | kugel | wow, finally someone with a clue answered on my gcc bug |
| 17:36:56 | TheSeven | kugel: no, it's a matter of moving the stack in app.lds |
| 17:37:32 | kugel | only the main thread stack is there, isn't it? |
| 17:37:45 | TheSeven | yes, but i bet that this one is the problem here ;-) |
| 17:38:03 | kugel | and the main thread name is in the .data section, unlikely to be next to the stack |
| 17:38:10 | TheSeven | (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:26 | TheSeven | isn't it in idata? |
| 17:38:41 | kugel | no idea, depends on the target |
| 17:38:59 | Unhelpful | Torne: 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:02 | kugel | I'm just saying that the main thread stack & name is completely different to other threads |
| 17:39:25 | TheSeven | how, how can that kind of crash happen then? |
| 17:39:54 | saratoga | updated my tremor mdct patch, but it still gives static output |
| 17:40:50 | kugel | stkov is detecting by checking the stack end for 0xdeadbeef. anything that's before the stack end is potentially overwritten |
| 17:41:11 | TheSeven | hm, but how can a stack hit that area? |
| 17:41:16 | Unhelpful | for 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:18 | kugel | so, the thread name has to be before the stack in order to be overwritten |
| 17:41:31 | TheSeven | or actually a pointer to it |
| 17:41:44 | kugel | and that's unlikely for the main thread, unless the main thread name is at the very end of .data |
| 17:41:52 | TheSeven | damn, this is another case for post-mortem debugging :-/ |
| 17:42:58 | TheSeven | if 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:57 | Torne | pamaury: 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:00 | TheSeven | well, that's still almost compensated by yesterday's green :-) |
| 17:45:47 | pamaury | arg, TheSeven you're eating all ramsize i'm freeing ;) |
| 17:46:09 | TheSeven | yes, you'll need to run after those useless LFN sector buffers to fully compensate it ;-) |
| 17:46:22 | Unhelpful | we 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:00 | TheSeven | but 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:12 | Torne | pamaury: 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:14 | kugel | TheSeven: it looks like all stacks have the name after the stack or passed it directly in the create_thread() call |
| 17:47:29 | pamaury | TheSeven: are there useless buffers in the FAT code ? |
| 17:47:29 | Torne | pamaury: it's work-around-able, but the linker script might grow hairy legs as a result :) |
| 17:48:20 | Unhelpful | Torne: might it help to use FLT only as a starting point? perhaps add more sections? |
| 17:48:26 | TheSeven | pamaury: we talked about that excessive count of sector buffers in dirent structs some days ago |
| 17:48:47 | Torne | Unhelpful: i think it's easiest to just not bother to begin with, tbh :) |
| 17:49:09 | pamaury | TheSeven: not sure but indeed, 3 sectors of caching per fat_dir seems a lot to me |
| 17:49:27 | Unhelpful | Torne: FLT? or specifically being able to relocate multiple iram users? |
| 17:49:32 | TheSeven | one sector + 512 bytes would be sufficient if one would do a little rework on the LFN reading code |
| 17:49:34 | Torne | being able to relocate iram |
| 17:49:43 | | Join Adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) |
| 17:49:48 | TheSeven | and it wouldn't even reduce performance |
| 17:49:58 | Unhelpful | Torne: fair enough, i can agree to that. :) |
| 17:50:06 | pamaury | TheSeven: why one sector + 512 bytes (the 512-byte i mean) |
| 17:50:13 | Torne | Unhelpful: it's not infeasible to do it by some method, anway. |
| 17:50:20 | Torne | pamaury: we painstakingly worked this out the other day :) |
| 17:50:28 | | Quit anewuser (Ping timeout: 245 seconds) |
| 17:50:31 | TheSeven | buffer 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:40 | kugel | Unhelpful: seen my question? |
| 17:50:56 | Torne | Unhelpful: i just don't think worrying about what that method should be right now is worth the effort |
| 17:50:59 | TheSeven | search the IRC logs of the last days for dozens of occurrences of "LFN" for details |
| 17:51:13 | Unhelpful | kugel: yes, and answered, but i mistakenly directed the answer at Torne. been sick, sorry. :/ |
| 17:51:19 | pamaury | TheSeven: ok, I'll have a look at the log and at the code, see if there is something to do |
| 17:51:36 | Unhelpful | Torne: almost everything that uses iram expects exclusive audio access anyway, right? |
| 17:51:42 | Torne | Unhelpful: everything, afaik |
| 17:51:45 | TheSeven | that would get us rid of another 3.5K per dirent on nano2g |
| 17:52:34 | pamaury | And perhaps reduce binsize, iirc the function handling LFN is monstruous, if only it can be simplified ! |
| 17:52:54 | kugel | Unhelpful: 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:22 | Torne | Unhelpful: beatbox, doom, midi, mpegplayer, pacbox, pdbox, rockboy, zxbox |
| 17:53:38 | Torne | Unhelpful: pretty sure those all steal the sound |
| 17:53:42 | Unhelpful | then 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:03 | kugel | Torne: most of them produce their own sound anyway :p |
| 17:54:17 | Torne | kugel: 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:32 | Torne | which 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:49 | kugel | doesn't greylib grab iram as well? |
| 17:54:55 | Torne | kugel: only if you tell it to |
| 17:54:55 | Unhelpful | kugel: only optionally. |
| 17:54:59 | kugel | ok :) |
| 17:55:06 | Torne | kugel: which only the plugins that are using iram anyway do |
| 17:55:52 | kugel | 1 iram user at a time seems like a sensible thing to do then |
| 17:56:10 | Torne | in which case, with fingers crossed, it shouldn't be *too* difficult to do |
| 17:56:21 | Torne | just a matter of rewriting the linker scripts to produce what elf2flt expects |
| 17:56:26 | kugel | we shouldn't have so high requirements anyway, otherwise it's not getting done |
| 17:56:28 | Torne | maybe adding in a bit of strip to remove relocs we don't want it to see |
| 17:56:41 | Torne | well, if we are doing *just* that, then I doubt it's a SoC project, though :) |
| 17:57:06 | kugel | I think it is |
| 17:57:07 | Torne | just poking the linker scripts until elf2flt produces the right output, and implementing a tiny loader, shouldn't take very long at all |
| 17:57:20 | pamaury | and bugfixing ? ;) |
| 17:57:21 | Torne | if you want to load into audiobuffer then that's a whole different can of worms.. |
| 17:57:41 | Unhelpful | Torne: save the reloc info and reloc on move? :) |
| 17:57:58 | Torne | Unhelpful: i recall someone in scrollback earlier telling you why that was stupid ;) |
| 17:58:07 | Torne | so i shall refrain from repeating it ;) |
| 17:58:25 | AlexP | bluebrother: Well spotted - I've removed that and banned it |
| 17:58:26 | Unhelpful | was it you? ;) |
| 17:58:31 | Torne | no |
| 17:58:33 | pamaury | I think I proposed that just for fun :) |
| 17:58:37 | Torne | also 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:41 | kugel | gevaerts: you didn't do the *promised* test codec runs, did you? ;) |
| 18:14:24 | gevaerts | kugel: I did *all* promised test code runs! |
| 18:14:38 | kugel | ok, I get it :p |
| 18:14:42 | gevaerts | Unfortunately I didn't have time for the ones that I didn't promise |
| 18:15:20 | kugel | I think you have plenty time, doom needs to be fixed badly |
| 18:29:08 | | Join mitk [0] (~mitk@chello089078013146.chello.pl) |
| 18:31:05 | mitk | Hi, 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:51 | Unhelpful | Torne: 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:15 | Unhelpful | Torne: 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:54 | pixelma | bluebrother: 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:27 | Unhelpful | but 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:50 | Torne | Unhelpful: there might be pointers to other things, too |
| 18:43:58 | Torne | Unhelpful: to symbols in .idata, or whatever |
| 18:44:07 | Torne | pointers 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:43 | Unhelpful | Torne: 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:03 | Unhelpful | what 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:24 | stuckey | Hi |
| 18:47:00 | Unhelpful | again, 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:14 | Torne | well yah, there's any number of possible things we might later want |
| 18:54:32 | Unhelpful | i mean as an alternative to "real" plugin multitasking |
| 18:56:11 | | Quit tvelocity (Quit: Αποχώρησε) |
| 18:56:39 | JdGordon1 | kugel: any news on the skin resising patch? |
| 18:57:51 | | Quit stuckey (Remote host closed the connection) |
| 18:58:47 | pixelma | hmm... "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:19 | pixelma | s/bit/but |
| 19:06:23 | bluebrother | pixelma: 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:11 | bluebrother | as 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:02 | pixelma | system value should give me an effect if I change it in thte VoiceOver setup, no? |
| 19:08:51 | bluebrother | not sure about voice over. In 10.6 the voice setting is different than the voice over setting. |
| 19:09:25 | domonoky | sapi 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:52 | pixelma | my 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:31 | pixelma | all three voice files I created are more than twice the size they are a allowed (about 3.3 MB each) |
| 19:11:04 | pixelma | I tried English, German and Swedish. There is not much difference between the three |
| 19:11:15 | bluebrother | not sure about mp3 voices, but rbspeex resamples its wav input to 16kHz |
| 19:11:37 | bluebrother | most voices on OS X seem to be 22kHz. |
| 19:14:07 | pixelma | I 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:06 | domonoky | the buildsystem use the following lame options: −−resample 12 -t -m m -h -V 9.999 -S -B 64 −−vbr-new" |
| 19:16:32 | domonoky | dont know if rbutil uses any lame options if you dont enter it. |
| 19:16:59 | bluebrother | pixelma: 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:53 | bluebrother | domonoky: 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:52 | saratoga | stripwax: 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:09 | pixelma | bluebrother: 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:55 | bluebrother | pixelma: 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:28 | mitk | bertrik: ping |
| 19:40:22 | | Join bmbl [0] (~Miranda@unaffiliated/bmbl) |
| 19:41:57 | | Join sansafuze_v2-FAN [0] (~5b045847@giant.haxx.se) |
| 19:43:06 | sansafuze_v2-FAN | hallo, 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:15 | saratoga | when its done |
| 19:44:54 | AlexP | best get a hanky then |
| 19:45:46 | domonoky | sansafuze_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:16 | domonoky | we dont even have a unstable build for that |
| 19:46:19 | kugel | JdGordon: I had strange behavior with my last patch, but I didn't look into it further |
| 19:46:44 | kugel | strange behavior as in the wps was going crazy (displaying wrong images) |
| 19:46:47 | JdGordon | strange how? data aborts? |
| 19:47:09 | JdGordon | I'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:34 | mitk | Any 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:50 | mt | mitk: 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:53 | mt | I might be able look at it in 2-3 days if no one beats me to it. |
| 19:58:00 | mitk | mt: Thanks. I will wait then. |
| 19:59:12 | | Quit petur (Quit: plop) |
| 19:59:33 | bertrik | I could do it too, but I don't know much about fonts |
| 20:00 |
| 20:02:57 | bertrik | the patch adds some characters but also changes the name of some, like "capital C, cedilla" to "Ccedilla" for example |
| 20:03:07 | mitk | bertrik: 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:05 | mitk | bertrik: These changes are inline with other fonts like Nimbus. These changes were made by FontForge, not by me. |
| 20:05:08 | mitk | Atadore has different names than other fonts in Rockbox. Nedore for example too. |
| 20:11:12 | | Quit Marctraider (Ping timeout: 264 seconds) |
| 20:11:50 | mitk | Sorry. 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:05 | amiconn | pamaury: Putting code in iram is essential for performance critical stuff on e.g. PP5002 |
| 20:12:14 | mitk | *and |
| 20:12:30 | amiconn | But then, plugins using iram do so for performance reasons, and also have to stop playback |
| 20:13:09 | amiconn | So 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:17 | amiconn | domonoky: 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:36 | Stephen__ | JdGordon, ping |
| 20:29:46 | JdGordon | pong |
| 20:30:03 | Stephen__ | whats the syntax for a conditonal %Lt ? |
| 20:30:19 | domonoky | amiconn: true. |
| 20:31:07 | JdGordon | %?Lt<no title|title> i tihnk |
| 20:31:13 | JdGordon | or the other way around :) |
| 20:31:24 | Stephen__ | Ah right that's what I thougth |
| 20:31:28 | Stephen__ | thought* |
| 20:31:29 | JdGordon | or %?Lt<title> |
| 20:31:47 | | Quit mitk (Quit: Leaving) |
| 20:32:04 | Stephen__ | 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:33 | Limarus | #Hi :) |
| 20:35:17 | Limarus | Anyone 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:18 | webguest78 | is anyone here? |
| 20:52:46 | pixelma | Zagor 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:42 | webguest78 | anyone know why build r25107 is not in current build page? |
| 20:56:06 | webguest78 | so I can't download it ? |
| 20:57:32 | pixelma | there 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:59 | webguest78 | oh, 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:37 | Stephen__ | JdGordon, updated my clipart theme to include list title finally. \o/ |
| 21:11:21 | JdGordon | wooo! |
| 21:11:51 | | Quit anewuser () |
| 21:11:56 | Stephen__ | 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:45 | Marctraider | TheSeven: 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:22 | TheSeven | nano 2g and 4g |
| 21:28:37 | Marctraider | has it something to do with the 2G rockbox implentation? |
| 21:28:40 | Marctraider | or is it on your 4g |
| 21:29:37 | Farthen | Marctraider: 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:55 | Marctraider | Farthen: i see |
| 22:23:59 | Marctraider | so its the 2G :o |
| 22:27:21 | | Join chrisb [0] (~chrisb@pool-71-175-246-16.phlapa.east.verizon.net) |
| 22:31:42 | bluebroth3r | Tomis: 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:15 | CIA-5 | New commit by amiconn (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) |
icon identifies that the person is a core developer (has commit access).