--- Log for 10.03.110 Server: kornbluth.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 8 days and 21 hours ago 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 # kugel: I wonder whether eabi gcc stumbles upon the packed structs 00.08.33 # short enums, rather 00.08.36 # I think I found 1 problem 00.10.40 # 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 # if that's true, I'd consider eabi to be broken 00.12.27 # 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 # Accessing enums via pointers isn't bad 00.13.15 # 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 # right 00.14.21 # pamaury: no, I think you confuse me. I saw a different chance for saving but you fixed that already (IIRC) 00.14.26 # 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 # -fno-short-enums 00.14.58 # I'm not sure if that's the way to go 00.15.10 # 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 # I would prefer to avoid it if possible. But it might turn out to be impossible 00.16.13 # 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 # Is doom still actively maintained? There might be upstream fixes if so 00.16.36 # That won't help 00.16.45 # amiconn: it was you, see ^ 00.17.05 # 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 # 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 # 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 # 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 # 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 # unless there's a bug, anyway, ;) 00.20.49 # AlexP: can you check the output of pkg-config --silence-errors --libs speex speexdsp 00.21.12 # doom has one case where it's accessed over an int pointer 00.21.13 # kugel: i did a lot of short enum fixes to get doom and mpegplayer compiling without warnings for them 00.21.13 # [00:13:16] 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 # bluebrother: "-lspeex -lspeexdsp" 00.21.39 # 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 # AlexP: can you check the version of libspeex? 00.22.13 # 1.5.0 I think 00.22.14 # Unhelpful: sure. but the latter isn't possible. couldn't the pointer be changed to a char * one? 00.23.06 # kugel: but that breaks on long-enum builds. an enum-valued int is preferable if you simply must access via int* 00.23.23 # bluebrother: I looked at /usr/lib/libspeex.so for that 00.23.28 # 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 # AlexP: huh? The speex website says that the most recent (unstable) release is 1.2rc1 00.23.48 # amiconn: sorry, had missed that bit... also twasn't you said that would make eabi broken. 00.24.07 # bluebrother: ah right, speexdec gives 1.2rc1 00.24.14 # if anyone has any opinions or refinements for http://www.rockbox.org/wiki/GSoCOrgApp2010 , please feel free to go at it. 00.24.24 # bluebrother: I'm not sure how to get the library version directly? 00.24.49 # AlexP: no idea, I use my package manager for that ;-) 00.25.06 # speex (which provides it all) is at 1.2rc1 00.25.08 # but this is strange, 1.2rc1 should provide the required symbols in libspeex.so 00.25.08 # 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 # hehe :) 00.26.56 # need to get some sleep for tonight. Will check that later. Please ping me if I forget about it. 00.27.05 # sure, thanks for looking :) 00.28.03 # 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 # it's accessed via int* in a generic struct (default_t) 00.29.51 # 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 # New commit by 03amiconn (r25098): Coldfire targets: tiny optimisation. 00.51.12 # kugel: Where does that access happen? 00.52.00 # m_misc.c:857 00.54.21 Mode "#rockbox +o scorche" by ChanServ (ChanServ@services.) 00.54.56 # 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 # Ah, default_compatibility_level and precache 00.59.50 # The latter is a bool, but that will also cause problems if bools are byte-sized 01.00.01 # isn't the same issue with bools in theory? 01.00.46 # 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 # 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 # Hmm, iiuc attribute((mode(word))) for the enums and bools in question *might* help 01.08.19 # 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 # xxx 01.10.43 # In a rockbox function, is it safe to allocate, say, 1500 bytes on the stack? 01.10.46 # 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 # eg. char buffer[1024]; int otherstuff; int morestuff; 01.11.21 # I wonder why they have separate fields for the location pointer 01.12.11 # 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 # well, the enum in default_s is not used for casting to the appropriate pointer 01.12.45 # ah, damn 01.13.04 # anyone else around who knows how rockbox handles usb mass storage transfers? 01.15.48 # kugel: It isn't, but it could be 01.17.45 # earHurts01: Depends on what else is on the stack, and in which thread you're doing this 01.20.17 # assume I'm only calling file functions (lseek, read, write) and I'm in the main thread. 01.21.17 # (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 # In docs/API, it says write() is not supported? 01.30.30 # 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 # ???? 01.31.42 # 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 # earHurts01: IIRC the main thread stack is several KB so thats probably safe 01.36.30 # thanks 01.38.24 # unfortunately, doom has more problems 01.40.33 # 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 # 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 # it must be another short enum problem. doom functions fine with -fno-short-enums 01.54.35 # __attribute__((mode(word))) makes an enum indeed 4byte wide 01.57.40 # does rockbox have an int32 type? 01.59.47 # ah, yes, in inttypes.h 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 # 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.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.45 # New commit by 03theseven (r25099): iPod Nano 2G FTL performance enhancements. Still not quite as fast as the OFW, but way better than before. 04.01.04 # New commit by 03theseven (r25100): Detect iPod Nano 2G charging state correctly 04.01.17 Nick kimi-sharamin is now known as karashata (~karashata@74-220-162-11.wightman.ca) 04.01.23 Join froggyman [0] (~sopgenort@pool-72-69-220-42.chi01.dsl-w.verizon.net) 04.05.18 Join chrisb [0] (~chrisb@pool-71-175-246-16.phlapa.east.verizon.net) 04.08.00 Quit anewuser () 04.11.41 # New commit by 03theseven (r25101): Fix bootloader red 04.16.47 Quit DaCapn (Read error: Operation timed out) 04.17.50 # is the most current, in depth list of players? http://www.rockbox.org/wiki/DeviceChart 04.17.55 # or is there a newer one? 04.19.00 # New commit by 03theseven (r25102): Add the raw battery voltage to the Nano2G battery debug screen 04.19.57 # New commit by 03theseven (r25103): Some Nano2G define corrections / updates 04.20.48 Join krazykit` [0] (~kkit@ppp-70-225-142-162.dsl.ipltin.ameritech.net) 04.20.50 # New commit by 03theseven (r25104): Disable HID on Nano2G for now - it's causing some instability that needs to be debugged 04.21.28 Join jobec_ [0] (paulus@viherharakka.cs.tut.fi) 04.21.31 Join stavrob [0] (~sam@78-105-125-218.zone3.bethere.co.uk) 04.25.00 Join tmzt [0] (~tmzt@adsl-76-244-159-241.dsl.akrnoh.sbcglobal.net) 04.25.37 Quit krazykit (*.net *.split) 04.25.37 Quit Connor (*.net *.split) 04.25.37 Quit stavrob_ (*.net *.split) 04.25.37 Quit yosafbridge (*.net *.split) 04.25.37 Quit YPSY (*.net *.split) 04.25.37 Quit jobec (*.net *.split) 04.25.37 Quit soap (*.net *.split) 04.25.41 Quit karashata (Quit: The fluffy dragon has left completely!) 04.28.02 Join krazykit [0] (~kkit@ppp-70-225-142-162.dsl.ipltin.ameritech.net) 04.28.02 Join Connor [0] (~Connor@ip72-204-35-60.fv.ks.cox.net) 04.28.02 Join stavrob_ [0] (~sam@78-105-125-218.zone3.bethere.co.uk) 04.28.02 Join YPSY [0] (~ypsy@geekpadawan.de) 04.28.02 Join jobec [0] (paulus@viherharakka.cs.tut.fi) 04.28.02 Join soap [0] (~soap@rockbox/staff/soap) 04.28.38 Join yosafbridge [0] (~yosafbrid@li14-39.members.linode.com) 04.28.46 Quit krazykit (Ping timeout: 277 seconds) 04.28.46 Quit stavrob_ (Ping timeout: 277 seconds) 04.28.46 Quit jobec (Ping timeout: 277 seconds) 04.37.40 Quit mc2739 (Ping timeout: 245 seconds) 04.38.18 Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 04.39.33 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 04.39.56 Quit TheSeven (Disconnected by services) 04.40.09 Join The_Seven [0] (~theseven@rockbox/developer/TheSeven) 04.40.18 Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven) 04.42.19 # is the most current, in depth list of players? http://www.rockbox.org/wiki/DeviceChart or is there a newer one? 04.48.57 # it's missing the nano2g and a couple of scarcer targets 04.49.38 # er, and the AMS sansas 04.50.57 Join saratoga_lab [0] (~9803c255@gateway/web/freenode/x-jxukfravxprarxsy) 04.51.06 # froggyman: the current_status wiki page is probably a lot better 04.51.09 # The most up to date list of targers is /tools/configure 04.51.13 # *targets 04.51.25 # 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 # 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 # 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 # 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 # at least i think the ifp was a 1 MB swcodec target 04.55.13 # Yeah 04.55.19 # At one point Rockbox was actually playing music on it though 04.55.51 # 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 # we're probably bloated way past that :) 04.56.00 Quit Barahir (Ping timeout: 256 seconds) 04.56.20 # i guess it depends how much of the core you can ifdef out 04.56.33 # Probably strip it down to more or less what the Recorder gets 04.56.49 # And since it's flash, it doesn't need much buffer. 04.57.36 # wait, did it ever play music? I thought it didnt 04.57.49 # it could play vorbis at one point I think 04.57.54 # just not very well 04.58.15 # and probably only a subset of vorbis encoding options 04.58.18 # 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 # 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 # Since it's some 60mhz Panasonic CPU 04.59.09 *** Saving seen data "./dancer.seen" 05.02.49 # wow the ifp emulator tomal wrote worked as a GDB stub 05.03.52 # Would that be a starting place for the ARM emulator summer of code project idea? 05.04.43 # yeah that or Toni's emulator 05.04.47 # or skyeye 05.04.50 # any would work 05.05.18 # 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 # just put the binary in ROM and you'd have plenty of RAM 05.05.39 # 8MB ROM and 1MB RAM? 05.05.43 # Or is it 8 megabit? 05.05.44 # yeah 05.06.01 # ah mbit 05.06.09 # but still big enough 05.06.13 # 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.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 # Quick question 06.19.28 # I'm using rockbox after ages 06.19.42 # Where should I drag and drop my files on the drive? 06.19.55 # After ages? 06.19.56 # Is it inside the .rockbox folder or outside? 06.20.02 # What files? 06.20.06 # Music files 06.20.11 # yeah broke my old ipod 06.20.16 # got a new one 06.21.35 # You can put the files anywhere 06.21.47 # Ah 06.21.51 # kk 06.22.00 # Probably best to keep them in a folder dedicated to music, outside the .rockbox folder 06.22.25 # 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 # danke danke 06.24.14 Quit Torne (Ping timeout: 276 seconds) 06.24.17 Join Torne [0] (torne@rockbox/developer/Torne) 06.28.12 # 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 # 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 # 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 # with installer you mean the Rockbox Utility? 06.59.01 # yes 06.59.11 *** Saving seen data "./dancer.seen" 06.59.46 # did you ever try to generate voice files or talk clips for your target? 07.00.10 # nope 07.00.52 # 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 # 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 # 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 # 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 # 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 # standalone too 07.10.56 # yea i think apple's TTS to file outputs .aiff 07.14.17 # 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 # Tomis: how did you install the bootloader then? 07.46.15 # used iLoader 07.59.38 Quit MagusG (Ping timeout: 252 seconds) 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 # 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 # http://build.rockbox.org/ nosa- 08.32.30 # that's the "current build" link at the top left of the rockbox website 08.33.30 # ahh ok 08.41.03 Join Regika [0] (~Shawnboy1@adsl-75-19-46-151.dsl.irvnca.sbcglobal.net) 08.41.19 # 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.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 # New commit by 03pamaury (r25105): Get rid of the parent_dir field in dir_uncached.c by using the same FAT trick as in dircache. This should save ~20KB on 512B/sector targets and ~80KB ... 09.58.50 Quit einhirn (Read error: Connection reset by peer) 10.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 # build server doesn't work ? 10.13.28 Quit GodEater (Read error: Operation timed out) 10.17.37 # pamaury: checking... 10.18.18 # something happened with the network. "Ending round due to lack of clients" 10.18.30 # I'll restart the round 10.19.01 Join efyx_ [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 10.21.10 # hmm, something is broken 10.22.04 Join mt [0] (~mtee@rockbox/developer/mt) 10.23.49 # 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 # mt: in principle, yes. I'm afraid that the website rework will attract lots of people with very questionable ability though 10.26.52 # 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 # I'd still like that, but it depends (in my mind at least) on address-independent plugin loading 10.28.10 # Otherwise it doesn't really fix anything 10.28.29 # indeed 10.28.42 # or it depends on relocations 10.29.40 # Adding a coff or elf loader or getting elf2flt to work for rockbox might be a fun project though 10.29.57 # what is elf2flt ? 10.30.06 # * gevaerts doesn't really know how much work those would be 10.30.19 # http://www.uclinux.org/bFLT/ 10.30.34 # gevaerts : Yes, I thought it would do just that, but they could be filtered with a good qualifying task. 10.30.52 # 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 # But this table can be put in a file I guess 10.31.51 # mt: maybe. I'm not convinced though 10.32.45 # 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 # and I'm also not convinced by the "new" design 10.33.55 # 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 # pixelma: You mean the idea itself ? Or the specific new design that was started on the forums ? 10.34.18 # pamaury: I haven;t investigated it very much yet 10.34.26 # the latter 10.35.35 # 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 # 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 # 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 # 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 # 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 # Plus of course dealing with everyone complaining about it and trying to reach a concensus... 10.49.02 # which is not coding... 10.49.27 # but happens in any coding task also :) 10.49.51 # That's true... ;) 10.51.06 # Although a consensus on how a specific driver works entails much less hassle than that regarding the website. :) 10.51.53 # Indeed, you just have to be obscure enough to have the others say wait&see. 10.52.01 # ;-) 10.52.39 # 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 # 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.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 # nice green delta, hope I didn't break anything :) 11.25.04 # 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 # pamaury: I don't see a need to drop the rb-like structure 11.32.20 # 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 # Of course, the the symbol table approach requires more work so more code so increase binsize :) 11.36.48 # the symbol table approach would also need the full table somewhere 11.37.05 # rb doesn't need a copy per plugin 11.37.06 # You can store it in a file 11.37.11 Quit einhirn (Read error: Connection reset by peer) 11.37.46 # The code to handle that will be bigger than just having the table 11.38.02 # perhaps :) 11.39.20 # 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 # 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 # 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 # yes. currently, how do plugins use iram ? There is a reserved region no ? 11.42.11 # yes 11.42.54 # We also have to be careful with relocation and iram. We don't want to slow down iram use 11.44.28 # 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 # Anyway, multiple plugins means managing iram and also the place where plugins are loaded (audio buffer ?) 11.49.13 # Yes, it means a lot of things :) 11.50.16 # is the audio buffer contiguous or does it support being split ? 11.50.26 # (I mean the part used for buffering) 11.50.45 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) 11.53.19 # 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 # New commit by 03uchida (r25106): unify the wave/wave64 parser. 11.56.19 Join lasser [0] (~chatzilla@p57B58FCA.dip0.t-ipconnect.de) 11.57.53 Quit lasser (Client Quit) 12.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 # New commit by 03uchida (r25107): Oops. forget static. 12.24.28 # Zagor: builds seem to have stopped again 12.24.42 # 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 # 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 # 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.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 # 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 # three months full-time work... 13.35.42 # (or maybe two months, I forget...) 13.36.30 # 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 # not two months works i guess 13.37.19 # TheSeven: let me check the details... 13.37.23 # lol maybe for me 13.38.38 # 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 # 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 # TheSeven: you might want to play with WRITE_BUFFER_SIZE in usb_storage.c 13.40.58 # i already set that to 64K to prevent that 24K/24K/8K splitting 13.41.25 # haven't measured the impact of that 13.41.50 Quit mt (Ping timeout: 240 seconds) 13.41.58 # let me check 13.42.18 # 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 # hm, NAND is only active 64% of the FTL busy time 13.45.05 # TheSeven: you might want to look at FS#10239. Unfortunately I suspect that it doesn't apply cleanly anymore... 13.45.11 # 24k vs. 64k => 16% performance difference 13.45.30 # that buffer is allocated from the audio buffer anyways, isn't it? 13.45.44 # gevaerts: do you think the whole re-locatable plugins/pebbles/type thing is enough for GSOC? 13.46.04 # AlexP: I don't know. I have some doubts 13.46.20 Join AsusFreak [0] (~c1003c16@giant.haxx.se) 13.46.31 # As it'd be a nice thing to have - maybe we could flesh it out a bit 13.47.01 # TheSeven: on everything except imx31 and tcc, yes. The different values aren't for RAM reasons, just performance :) 13.47.44 # 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 # it was at 24k before, but 64k is significantly better 13.48.36 # i think this needs to be moved to the device config 13.49.09 # i'll do the "ifndef define" variant in usb_storage.c probably 13.49.55 # 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 # nand busy only 40% of the time 13.51.20 # 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 # overall CPU usage during FTL activity is still 53% 13.52.30 # didn't we commit that patch to make usb work at all on nano2g? 13.53.06 # no, that's something else 13.53.18 # however, i think those measurements show that the slowdown is clearly coming from the FTL, not the USB handling 13.54.22 # 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 # 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 # we're more than 50% behind that right now 13.55.08 # (even though we're already 200% better than yesterday) 13.56.52 # 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 # 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 # There is only one tricky point with the stack data however :( 14.00.57 # pamaury: by then the plugin might have pointers all over the place, located in malloced buffers, and pointing to potentially anywhere 14.01.05 # So I think you can't :) 14.01.53 # 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 # 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 # 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 # gevaerts: shouldn't we add "relocatable and multiple plugins" to the ideas list? 14.16.16 # Feel free 14.17.04 # 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 # 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 # 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 # argh! 14.52.19 # 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.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.01.33 # 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 # neither list is a personal wishlist 16.09.09 # but the radio related code definitely needs a overhaul, the apps/ and the firmware/ part are a pure mess 16.11.54 # What about the multi-codec architecture for the video player ? Why isn't it there ? 16.12.30 # it is 16.12.50 # "Multi-codec architecture for mpegplayer" 16.12.58 # ah .. just seen it. I was looking at the "codecs" section 16.13.01 # my bad. 16.18.10 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) 16.22.33 # 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 # kugel: But do you think a radio code rework is worthy of a SoC project? 16.24.34 # not sure, probably not 16.27.23 Quit Seed (Quit: cu, Andre) 16.27.27 # Unhelpful: I don't understand the "with plugin relocations specified by index" and the rest... :) 16.28.41 # 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 # yes-this-means-coding-relocation-ourselves :/ 16.30.54 # 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 # 16.33.47 # oops 16.33.49 # sorry 16.35.47 # 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 # kugel: we discussed it before 16.36.10 # it's possible, but would require fiddling with the bootloader 16.36.35 # 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 # do we really want relocatable codecs? 16.37.18 # why not? 16.37.46 # from what I gathered, PIC costs a lot of performance and code size, 16.37.52 # PIC is not involved 16.38.00 # there is zero performance cost 16.38.11 # and no runtime size cost (only a disk cost for the relocs) 16.38.36 # relocatable doesn't mean position independant; position independant code *doesn't* require relocation :) 16.39.12 # the main binary could memmove itself as well, bootloader fiddling is not needed 16.39.20 # yes. we discussed all this. 16.39.28 # many months ago ;) 16.39.34 # I'm just thinking it's easier for now ;) 16.40.01 # I really don't think it is, personally 16.40.11 # but hey 16.40.39 # well, the idea is added to the GSoC list, let's hope we find someone ;) 16.40.42 # building the plugins as relocatable is the slightly fiddly part; actually loading them and applying relocs is incredibly easy 16.40.59 # it only really gets hard if you consider loading into audiobuffer 16.41.04 # which is something that can be done later 16.41.48 # sure, for a start it would be nice to battery_bench while playing bubbles :) 16.42.06 # right, but you could do that by just dividing up plugin_buffer 16.42.18 # 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 # without PIC is the normal way.. 16.44.43 # PIC is a special case 16.45.07 # you build an elf binary just as we do now, but link with -r to keep all the relocations 16.45.53 # then you feed it to elf2flt to turn it into a simpler format, still with the relocations 16.46.02 # when you load it you just go to each reloc entry and add the right offset 16.46.10 # then throw the relocation data away 16.46.51 # the resulting assembly code is identical to if you just ran it through objdump with the right target address 16.47.06 # it's slightly complicated by things like iram, but that's the basic idea. 16.47.25 # the conversion step is not technically required, either, but we probably don't want to implement an elf loader. 16.48.43 # ah, cool. I didn't know about -r 16.49.06 # all PIC does to this process is make it so that there are less relocations 16.49.18 # you end up hving all the code refer to a global offset table 16.49.23 # and then you just need one big mass of relocs in th etable. 16.49.33 # this means you can share more pages between processes that map the same library 16.49.36 # but we don't care about that. 16.50.24 # just port ld and objdump (and strip?) to rockbox. done :P 16.50.26 # 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 # 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 # yes, but there is the iram issue, no ? 17.02.33 # it should be fine 17.02.44 Quit petur (Quit: *plop*) 17.02.53 # but the exact linker script required to make it work would need writing :) 17.03.42 # Torne: with bFLT? 17.03.50 # yah 17.03.56 # as long as you don't expect things to be able to share iram 17.04.11 # you're cheating :) 17.04.19 # put the iram addresses int he linker script, which is fine as long as they don't overlap 0->pluginsize 17.04.24 # then strip the relocs for them 17.04.30 # will probably work. 17.04.36 # * gevaerts *does* expect things to share iram! :) 17.04.46 # well, then no :) 17.05.21 # we can still implement something like alloc_iram and free_iram so the linker script is still works 17.05.35 # *-is 17.05.57 # Anyway, if you share iram you have to manage it so it has to be dynamical 17.06.04 # iram also has code 17.06.08 # pamaury: No, we can't implement that 17.06.14 # why ? 17.06.17 # We can't share iram unless we also know how to relocate references to iram 17.06.19 # Ah, code :) 17.06.22 # which is not possible in bFLT without modification 17.06.29 # because it only has three sections 17.06.50 # Indeed, if you share iram code, that's impossible with bFLT 17.07.13 # do we care, though? 17.07.27 # what's the need for it? 17.07.54 # is putting code in iram actually a gain ? 17.08.09 # could we prepend some 0xFFF to the reloc entry to show it's for iram? 17.08.13 # it doesn't matter if you put code in iram.. 17.08.24 # kugel: only if we wrote our own tool 17.08.32 # pamaury: you can't *refer to addresses in iram at all* 17.08.52 # it would be impossible to use iram for anything except malloc-like behaviour as you said 17.08.58 # Torne: if we do that we can just as well add iram sections 17.09.05 # you can't store any code or any variables there, unless it's a fixed location or you can relocate it 17.09.10 # 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 # kugel: yes 17.09.46 # although prepending 0xfff wouldn't involve changing the "standard" header 17.09.53 # hm,,, 17.09.54 # TheSeven: don't very large nand transfers also imply delayed errors? 17.10.01 # Then let's add an iram section to bFLT, that shouldn't be too hard 17.10.01 # kugel: but again this may be difficult, because the way that bFLT works means you can't really do that :) 17.10.06 # pamaury: yes it will be 17.10.19 # well, i get 64k writes from the usb stack, so i could at least write 64k blocks without further delaying them 17.10.28 # The format discards the relocation data, and only keeps the relocation site addresses 17.10.33 # it would be a little to handle bad blocks in that case though 17.10.38 # It relies on the fact that you have linked the binary to be placed at addresses starting at 0 17.10.41 # it can be done, it's just a bit complex 17.11.04 # which means that the values ld stores in the actual reloc sites are the offsets from the start 17.11.04 # this would mean merging quite a bit of VFL code into the FTL 17.11.20 # 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 # right now, i'm writing in 8K steps, and i could almost do 2 of those in parallel 17.11.42 # 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 # in particular APE is now deliberately using all of iram :) 17.11.49 # also yeah 17.11.59 # in general, on platforms where iram is faster then most codecs should probably be using all of it, no? 17.12.02 # well, actually this means merging both nand and vfl code into the ftl 17.12.24 # any time ther eis space there is probably something that can go in iram that will make it faster.. 17.12.27 # Torne: only when they reasonably can. and i could limit the size of the APE divider reciprocal table... 17.12.49 # 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 # 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 # pamaury: but it makes the code that uses iram slower! 17.13.42 # It doesn't just add two lines 17.14.09 # 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 # (or .data) 17.14.18 Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.0.152) 17.14.22 # 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 # but if you indirect via a pointer returned by a malloc-like then you are now slower 17.14.40 # pamaury: for there to be any point you need ot be able to put symbols in iram 17.14.45 # not just store data in iram. 17.15.05 # Torne: indeed; then use elf :) 17.15.11 # and this is only possible if the linker handles it, either the compile-time linker or the runtime linking loader 17.15.43 # 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 # does elf support all the necessary features for what we want ? 17.15.53 # 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 # yes I know 17.16.03 # pamaury: of course, otherwise we couldn't use ELF to link plugins in the first place ;) 17.16.12 # pamaury: think about it ;) 17.16.16 # But an ELF loader is big and slow and hard 17.16.38 # the point of using bFLT is that it's incredibly trivial to load and someone else already wrote the conversion tool 17.17.39 # 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 # oh wait 17.18.59 # pardon me, i'm dumb 17.19.01 # you don't need to do that 17.19.38 # if you're going to hack it anyway just add the extra fields to the header 17.20.06 # oh no, double wait 17.20.09 # :) 17.20.23 # 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 # You might still have a problem, either way 17.20.43 # the problem is that iram sections have a different LMA and VMA 17.20.57 # because they're loaded to one place then copied to another 17.21.15 # LMA/VMA? 17.21.24 # load address and run address, if you like :) 17.21.31 # 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 # *s/I/it 17.21.58 # pamaury: no, it's not, i realised i was making a mistake :) 17.22.02 # but it still might be a problem 17.22.03 # 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 # 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 # pamaury: what I just said 17.23.03 # 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 # .iram is linked AT(iramcopy) which is the address immediately after .data 17.23.25 # but it's linked to run at PLUGIN_IRAM 17.23.53 # 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 # TheSeven: that would deadlock 17.24.10 Part patgodo 17.24.20 # Torne: yes but at reloc time you can distinguish between those two types of reloc, no ? 17.24.23 # (at least in general, I don't know if/how rockbox mutexes work) 17.24.27 # They are not types of relocation 17.24.31 Quit Marctraider (Ping timeout: 246 seconds) 17.24.35 # There is nothing to be done at load time 17.24.36 # Yes but look at the adress 17.24.43 # The problem is at link time.. 17.24.44 Join Marctraider [0] (~marctraid@82-170-60-93.ip.telfort.nl) 17.25.32 # 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 # 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 # do we want that? 17.26.42 # that's the question 17.26.54 # usb transfer caches only annoyed me so far 17.26.58 # TheSeven: for write, I have one... 17.27.09 # linux had that not too long ago, but it disappeared again 17.27.24 # 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 # FS#10239 does most of that 17.28.02 # kugel: actually every dumb usb external hard drive is doing it 17.28.58 # caches on the device side aren't as bad as ones on the OS side, I guess 17.29.07 # gevaerts: I will try that one when i have the NAND at the maximum possible speed 17.29.33 # kugel: caches on the OS side aren't bad either as long as they are implemented in a sane way 17.30.38 # a new day, a new nano2g-sktov :) 17.31.08 # really? 17.31.19 # 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 # actually it were exactly 2 worms and a dozen stkovs 17.32.29 Quit robin0800 (Ping timeout: 256 seconds) 17.32.39 # but that one isn't nice 17.32.44 # a *shutdown stkov*!? 17.33.01 # and the thread name seems to have been damaged by it. bugger. 17.33.16 # can't we place the task information stuff *above* the stack to prevent that? 17.34.46 # isn't it just a matter of swapping the "const char thread_name[] =" and "char thread_stack[]" lines? 17.35.36 # wow, finally someone with a clue answered on my gcc bug 17.36.56 # kugel: no, it's a matter of moving the stack in app.lds 17.37.32 # only the main thread stack is there, isn't it? 17.37.45 # yes, but i bet that this one is the problem here ;-) 17.38.03 # and the main thread name is in the .data section, unlikely to be next to the stack 17.38.10 # (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 # isn't it in idata? 17.38.41 # no idea, depends on the target 17.38.59 # 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 # I'm just saying that the main thread stack & name is completely different to other threads 17.39.25 # how, how can that kind of crash happen then? 17.39.54 # updated my tremor mdct patch, but it still gives static output 17.40.50 # stkov is detecting by checking the stack end for 0xdeadbeef. anything that's before the stack end is potentially overwritten 17.41.11 # hm, but how can a stack hit that area? 17.41.16 # 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 # so, the thread name has to be before the stack in order to be overwritten 17.41.31 # or actually a pointer to it 17.41.44 # and that's unlikely for the main thread, unless the main thread name is at the very end of .data 17.41.52 # damn, this is another case for post-mortem debugging :-/ 17.42.58 # 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 # 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 # well, that's still almost compensated by yesterday's green :-) 17.45.47 # arg, TheSeven you're eating all ramsize i'm freeing ;) 17.46.09 # yes, you'll need to run after those useless LFN sector buffers to fully compensate it ;-) 17.46.22 # 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 # 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 # 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 # TheSeven: it looks like all stacks have the name after the stack or passed it directly in the create_thread() call 17.47.29 # TheSeven: are there useless buffers in the FAT code ? 17.47.29 # pamaury: it's work-around-able, but the linker script might grow hairy legs as a result :) 17.48.20 # Torne: might it help to use FLT only as a starting point? perhaps add more sections? 17.48.26 # pamaury: we talked about that excessive count of sector buffers in dirent structs some days ago 17.48.47 # Unhelpful: i think it's easiest to just not bother to begin with, tbh :) 17.49.09 # TheSeven: not sure but indeed, 3 sectors of caching per fat_dir seems a lot to me 17.49.27 # Torne: FLT? or specifically being able to relocate multiple iram users? 17.49.32 # one sector + 512 bytes would be sufficient if one would do a little rework on the LFN reading code 17.49.34 # being able to relocate iram 17.49.43 Join Adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 17.49.48 # and it wouldn't even reduce performance 17.49.58 # Torne: fair enough, i can agree to that. :) 17.50.06 # TheSeven: why one sector + 512 bytes (the 512-byte i mean) 17.50.13 # Unhelpful: it's not infeasible to do it by some method, anway. 17.50.20 # pamaury: we painstakingly worked this out the other day :) 17.50.28 Quit anewuser (Ping timeout: 245 seconds) 17.50.31 # 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 # Unhelpful: seen my question? 17.50.56 # Unhelpful: i just don't think worrying about what that method should be right now is worth the effort 17.50.59 # search the IRC logs of the last days for dozens of occurrences of "LFN" for details 17.51.13 # kugel: yes, and answered, but i mistakenly directed the answer at Torne. been sick, sorry. :/ 17.51.19 # TheSeven: ok, I'll have a look at the log and at the code, see if there is something to do 17.51.36 # Torne: almost everything that uses iram expects exclusive audio access anyway, right? 17.51.42 # Unhelpful: everything, afaik 17.51.45 # that would get us rid of another 3.5K per dirent on nano2g 17.52.34 # And perhaps reduce binsize, iirc the function handling LFN is monstruous, if only it can be simplified ! 17.52.54 # 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 # Unhelpful: beatbox, doom, midi, mpegplayer, pacbox, pdbox, rockboy, zxbox 17.53.38 # Unhelpful: pretty sure those all steal the sound 17.53.42 # 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 # Torne: most of them produce their own sound anyway :p 17.54.17 # 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 # 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 # doesn't greylib grab iram as well? 17.54.55 # kugel: only if you tell it to 17.54.55 # kugel: only optionally. 17.54.59 # ok :) 17.55.06 # kugel: which only the plugins that are using iram anyway do 17.55.52 # 1 iram user at a time seems like a sensible thing to do then 17.56.10 # in which case, with fingers crossed, it shouldn't be *too* difficult to do 17.56.21 # just a matter of rewriting the linker scripts to produce what elf2flt expects 17.56.26 # we shouldn't have so high requirements anyway, otherwise it's not getting done 17.56.28 # maybe adding in a bit of strip to remove relocs we don't want it to see 17.56.41 # well, if we are doing *just* that, then I doubt it's a SoC project, though :) 17.57.06 # I think it is 17.57.07 # 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 # and bugfixing ? ;) 17.57.21 # if you want to load into audiobuffer then that's a whole different can of worms.. 17.57.41 # Torne: save the reloc info and reloc on move? :) 17.57.58 # Unhelpful: i recall someone in scrollback earlier telling you why that was stupid ;) 17.58.07 # so i shall refrain from repeating it ;) 17.58.25 # bluebrother: Well spotted - I've removed that and banned it 17.58.26 # was it you? ;) 17.58.31 # no 17.58.33 # I think I proposed that just for fun :) 17.58.37 # also they may have been telling gevaerts 18.03.31 Join komputes [0] (~komputes@ubuntu/member/komputes) 18.06.32 Quit pamaury (Quit: Quitte) 18.12.41 # gevaerts: you didn't do the *promised* test codec runs, did you? ;) 18.14.24 # kugel: I did *all* promised test code runs! 18.14.38 # ok, I get it :p 18.14.42 # Unfortunately I didn't have time for the ones that I didn't promise 18.15.20 # 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 # 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 # 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 # 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 # 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 # 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 # Unhelpful: there might be pointers to other things, too 18.43.58 # Unhelpful: to symbols in .idata, or whatever 18.44.07 # 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 # 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 # 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 # Hi 18.47.00 # 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 # well yah, there's any number of possible things we might later want 18.54.32 # i mean as an alternative to "real" plugin multitasking 18.56.11 Quit tvelocity (Quit: Αποχώρησε) 18.56.39 # kugel: any news on the skin resising patch? 18.57.51 Quit stuckey (Remote host closed the connection) 18.58.47 # 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.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 # s/bit/but 19.06.23 # 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 # 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 # system value should give me an effect if I change it in thte VoiceOver setup, no? 19.08.51 # not sure about voice over. In 10.6 the voice setting is different than the voice over setting. 19.09.25 # 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 # 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 # all three voice files I created are more than twice the size they are a allowed (about 3.3 MB each) 19.11.04 # I tried English, German and Swedish. There is not much difference between the three 19.11.15 # not sure about mp3 voices, but rbspeex resamples its wav input to 16kHz 19.11.37 # most voices on OS X seem to be 22kHz. 19.14.07 # 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 # the buildsystem use the following lame options: --resample 12 -t -m m -h -V 9.999 -S -B 64 --vbr-new" 19.16.32 # dont know if rbutil uses any lame options if you dont enter it. 19.16.59 # 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 # 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 # 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 # 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 # 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 # 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 # 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 # when its done 19.44.54 # best get a hanky then 19.45.46 # 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 # we dont even have a unstable build for that 19.46.19 # JdGordon: I had strange behavior with my last patch, but I didn't look into it further 19.46.44 # strange behavior as in the wps was going crazy (displaying wrong images) 19.46.47 # strange how? data aborts? 19.47.09 # 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 # 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 # 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 # I might be able look at it in 2-3 days if no one beats me to it. 19.58.00 # mt: Thanks. I will wait then. 19.59.12 Quit petur (Quit: plop) 19.59.33 # I could do it too, but I don't know much about fonts 20.02.57 # the patch adds some characters but also changes the name of some, like "capital C, cedilla" to "Ccedilla" for example 20.03.07 # 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 # bertrik: These changes are inline with other fonts like Nimbus. These changes were made by FontForge, not by me. 20.05.08 # 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 # 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 # pamaury: Putting code in iram is essential for performance critical stuff on e.g. PP5002 20.12.14 # *and 20.12.30 # But then, plugins using iram do so for performance reasons, and also have to stop playback 20.13.09 # 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 # 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 # JdGordon, ping 20.29.46 # pong 20.30.03 # whats the syntax for a conditonal %Lt ? 20.30.19 # amiconn: true. 20.31.07 # %?Lt i tihnk 20.31.13 # or the other way around :) 20.31.24 # Ah right that's what I thougth 20.31.28 # thought* 20.31.29 # or %?Lt 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.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.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 03amiconn (r25108): Move (small) data into DRAM on PP5020, it's ~4.5% faster that way. Closes about half of the performance gap towards PP5022. The (relatively large) ... 22.40.45 Nick Llorean1 is now known as Llorean (~DarkkOne@adsl-99-158-46-229.dsl.hstntx.sbcglobal.net) 22.40.52 Quit Llorean (Changing host) 22.40.52 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 22.43.38 Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 22.45.06 Quit efyx_ (Remote host closed the connection) 22.46.17 Quit planetbeing__ (Ping timeout: 265 seconds) 22.47.08 Quit n17ikh (Ping timeout: 260 seconds) 22.47.16 Join jmslew [0] (~jmslew@84.36.5.111) 22.52.09 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 22.53.09 Join Tomis2 [0] (~Tomis@70.134.66.208) 22.53.29 Quit Tomis (Read error: Connection reset by peer) 22.53.29 Nick Tomis2 is now known as Tomis (~Tomis@70.134.66.208) 22.54.43 Quit planetbeing_ (Quit: planetbeing_) 22.56.15 Join planetbeing_ [0] (~planetbei@32.153.242.114) 22.58.00 Quit _arbingordon (Ping timeout: 264 seconds) 22.59.36 *** Saving seen data "./dancer.seen" 23.00.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)