Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2010-03-08

00:01:02Buschelpixelma: i have a son, but he is too young for DAPs... my wife will see the trick ;)
00:01:25gevaertsBut will she see it in time? :)
00:01:49Buschelhehe :)
00:02:17*Buschel guesses that gevaerts also tried this trick
00:02:33Buschelsuccessful?
00:02:48kugeldoing things like IRAM_48K, IRAM_80K, IRAM_128K etc sounds horrid IMO
00:03:00 Join Rob2222 [0] (~Miranda@p4FDCA85A.dip.t-dialin.net)
00:03:10CIA-5New commit by 03amiconn (r25066): rockbox.dev.sh ...
00:03:18Buschelgevaerts: in fact i treid to buy a nano2g via ebay. she spotted it and was "Not amused"
00:03:28Buschel*tried
00:03:33gevaertsBuschel: sorry, no wife and no children here :)
00:03:59Buschelwell, other problems then... but enough of OT :o)
00:04:40moosBuschel: sure that our Rockbox's fund could help here; bug Zagor or Bagder about it, and well done for musepack sv8 by the way
00:04:55 Quit ender` (Quit: The best way to accelerate a Macintosh is at 9.8m/sec²)
00:05:13amiconnkugel: That doesn't make much sense. IRAM usage does not just depend on IRAM size, but on various other factors
00:05:22 Join dfkt_ [0] (dfkt@unaffiliated/dfkt)
00:05:30moosBuschel: sure that we all for that you get coldifire target at least
00:05:36moos:)
00:06:18 Quit Rob2223 (Ping timeout: 245 seconds)
00:06:25kugelamiconn: sure, but I think we want something maintainable. we can probably inject target specific defines at some places; but if we consider too much we end up worse
00:06:27 Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk)
00:06:34*Buschel is fine with his iPod 5.5G
00:06:39Buschelworks like charm
00:06:52amiconnkugel: Imo this can only be done per codec. There is no general rule
00:06:56 Quit Farthen (Ping timeout: 264 seconds)
00:06:57moosBuschel: testing purpose of course :)
00:07:20Buschel:o)
00:07:33moosa coldfire target would have to be in the rescue kit ;)
00:07:38kugelmy suggestion would be a huge improvement over the current situation nevertheless
00:08:03Buschelkugel: i am of the same opinion.
00:08:22amiconnI would expect it to either have neglectibe effect, or change performance of numerous codecs for the worse
00:08:25kugelr25064 speaks for itself
00:09:13 Quit dfkt (Ping timeout: 245 seconds)
00:09:17Buschelyep. and if you search for such defines in the codec path, you will find lots more of such CPU-specific definitions.
00:09:34kugelany example where anything other than iram size is considered in the current code?
00:09:44amiconnYes
00:10:04amiconnPP5002 vs. PP5020
00:10:27kugelcan I see a link to that code?
00:10:30amiconnOn PP5002 all performance critical stuff (including code) should be in IRAM, while on PP5020 this would be a bad idea
00:10:32TheSevenhmm. "filetype array full". what does this mean?
00:10:41amiconnlibdemac is an example
00:11:09amiconnSoon PP5020 will get even more special handling in order to improve performance
00:11:13kugelanother example? that libdemac change was very recent (as the findings w.r.t to PP5020 iram is)
00:11:13Buschelmusepack does something similar for ICODE, but not for IBSS and ICONST
00:11:27amiconnNo it wasn't
00:11:59amiconnThe changes related to those findings are not yet committed
00:12:15kugelis there another example in the current code?
00:12:30amiconnThere probably is - I'm not sure
00:12:31TheSevenand what the heck does #define HAVE_USB_HID_MOUSE do?
00:12:48amiconnBuschel said musepack also does it
00:12:49Buschelif we could exchange the "#ifdef'ing CPU" with "#ifdef'ing IRAM_SIZE" we could still define different behaviour for code, constants and variables
00:12:58kugelanyway, if we know special stuff, we can add special handling. new targets should not need explicit action for code which mostly considers iram size only
00:14:31amiconnPP5002 specific ICODE handling in libdemac was committed in October 2008
00:14:37 Quit shaggy-h (Ping timeout: 240 seconds)
00:15:28kugelah I confused it with a different coomit
00:15:47amiconnThere's another reason why just IRAM size isn't sufficient: Code will have different size on different architectures
00:15:51Buschelmusepack -> mpcdec.h, line 60-68, does also not use icode for all targets with large iram
00:16:15amiconnThat also applies to data in some cases (e.g. libdemac filter buffers on ARMv4 are twice the size as on other targets)
00:17:21Buschelamiconn: that is correct. but we could still exchange the #if CPU"-worms with a simple "#if IRAM_CODEC_80K" and keep the hand made optimizations (like we do now)
00:17:48amiconnThere are beginnings of target specific IRAM handling in the config/*.h files
00:18:31amiconnThe #if CPU worms can be limited to one centralised .h file per codec, I think
00:19:15 Quit dfkt_ (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.)
00:19:50Buschelamiconn: yes, that has been done already. but we have such worms _per codec_. with each new target or iram configuration change you need to check all codecs...
00:21:48saratogaI liked the idea of putting the defines in the codeclib just because its much easier to change them there then editing all the config files everytime we change things
00:22:01Buschelexactly
00:22:16saratogawe used to have some of them in the config files (for vorbis) and it was kind of a mess
00:22:49kugelI think #defines on a per soc basis in the target tree are more promising
00:23:00saratogaI had imaged having all IRAM targets define the 48k level, the >=128k targets define the 80k level and the 192k targets define the 128k level
00:23:47saratogai suppose the 48k check isn't even needed
00:23:54kugelwhy do you want to define specific levels? defining the precise number is trivial, and you can still check for the levels in the codec code
00:23:56saratogaso really they'll just be a check for 80 and 128k
00:24:17saratogabecause it makes it easier to optimize if you have fewer differences between targets
00:24:26kugelhow?
00:24:40saratogayou don't have to keep compiling more and more targets when you change things to see if everything links
00:24:56kugelhow's #ifdef IRAM_80K easier than #if IRAM >= 80k?
00:25:06saratogaoh i see what you mean
00:25:26saratogai don't really think thats different then what i'm suggesting
00:26:09*Buschel better seeks for his bed
00:26:19kugeladding more levels will be much more easier though (if needed), and it looks less obscure. and the numbers are already available (just look at the lot of defines in plugin.lds)
00:26:28Buschelgotta get up early tomorrow. see you!
00:26:51saratogalevels above 128k probably won't help much, 128k is enough IRAM for all the codecs I've looked at
00:27:02 Quit Buschel ()
00:28:22kugelsaratoga: but I can imagine we could want some steps between 80k and 128k for more fine-grained optimisation
00:29:00saratogayeah if we ever got oddball IRAM sizes maybe
00:29:17pixelmanow I don't know what I should test on my M5 :\
00:29:34saratogapixelma: see if WMA, Vorbis or MPC files still work
00:29:48saratogamost likely though if it compiles and links there is no problem
00:30:01kugeland the core too, that commit changed both core and codecs
00:30:06saratogasince i think the linker is smart enough to realize if you try to allocate more memory then you have
00:30:21saratogawell yeah but if audio plays the core is fine I think :)
00:30:22kugelI think so too
00:30:22pixelmawork at all, or as quick as before, or ?
00:30:30saratogawork at all
00:30:47saratogayou'd probably crash immediately if the memory is double allocated or something like that
00:31:10kugelsaratoga: I can also imagine that the current 128k level is just 128k because the targets happened to have that, and that much code actually needs less (like 100k)
00:31:31saratogayeah its pretty rare to use all the IRAM available in a codec
00:31:49saratogasince usually theres at least some left over due to needing 32KB to put the next best buffer in IRAM and only having 16KB
00:32:41soapany plugins able to break because of the IRAM "move"?
00:32:51saratogabut i've never really seen a convincing case for giving core more IRAM, usually some is needed for things like DMA, stack, or whatever, and anymore just gives you a couple percent faster LCD updates that make no real difference to battery life or UI
00:33:10saratogasoap: i think they'll all have more IRAM, so hopefully nothing breaks
00:33:23 Quit merbanan (Ping timeout: 245 seconds)
00:33:49saratogaon most targets during playback it seems like the UI uses less then 3 MHz under normal use
00:33:54saratogasorry core, not UI
00:33:57saratogathat can use more obviously
00:34:25saratogamaybe DSP could use some, but I think it already uses IRAM if a codec passes it PCM data in an IRAM buffer
00:34:59soapsaratoga, more - but possibility of shifting across the DMA accessible line?
00:35:14saratogaah yeah
00:35:28saratogai don't know anything about that
00:35:34saratogai didn't even know any plugins could use DMA
00:35:46 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon)
00:37:49soapdon't know if they can. I was just curious and brought it up out of curiosity in regards to pixelma's query.
00:38:09 Quit komputes (Read error: Connection reset by peer)
00:42:24 Part Zacam
00:44:24 Quit saratoga (Changing host)
00:44:24 Join saratoga [0] (~9803c6dd@rockbox/developer/saratoga)
00:45:26 Quit efyx_ (Remote host closed the connection)
00:48:10 Quit bertrik (Ping timeout: 265 seconds)
00:53:05 Join komputes [0] (~komputes@ubuntu/member/komputes)
00:56:00 Part froggyman
00:56:52soapTheSeven, creposucre started his discussion on iPod accessories in the FS (#10623) task thread on March 1st of this year, I believe the IRC talk about why /not/ to do it followed shortly - but I haven't looked back through the logs.
00:57:59***Saving seen data "./dancer.seen"
00:58:20 Quit JdGordon (Ping timeout: 240 seconds)
00:58:58soapThough on the 28th of Feb, buschel was saying he knew of no way to detect accessories - so perhaps one side's argument was uninformed?
00:59:28soap(and if there is anyone obsessed with turning things off to save 0.5ma, it's buschel) ;)
01:00
01:02:50TheSevencan anyone tell me what "filetype array full" is supposed to tell me?
01:02:57TheSevenit appears as a splash during boot
01:10:01amiconnIt means that the filetype array is full...
01:10:39TheSevenwhy does that happen?
01:10:39amiconnI.e. there are more filetypes defined (built-in + config file) than filetypes.c is prepared to handle
01:13:00TheSevenhm, interesting. does it also happen on other targets right now?
01:13:05 Quit Sajber^ (Quit: Leaving.)
01:14:09amiconnI don't know. It doesn't happen here on the targets I'm using often, but then I'm not running the very latest builds
01:15:57amiconnIt is quite normal for this error to not appear on all targets at the same time
01:16:22amiconnIt all depends on the supported file types, which differ somewhat between targets
01:22:07 Join CGL [0] (~CGL@190.207.198.83)
01:22:09 Quit MethoS- (Remote host closed the connection)
01:27:12 Quit Schmogel (Read error: Connection reset by peer)
01:33:44saratogaTheSeven: I do not get it with my e200v1, which should support the same file types as your nano afaik
01:35:17TheSevenbesides .ipod/.ipodx (crypt_firmware plugin)
01:35:47 Quit xavieran (Quit: ➤➤➤➤➤➤ UniCode shall rein forever! ➤➤➤➤➤➤)
01:36:18S_a_i_n_t_which doesn't work..... :[
01:36:57saratogaok then i better test on hte nano
01:40:04saratogahow long should rolo on the nano2G take?
01:40:32 Quit n17ikh ()
01:40:41S_a_i_n_t_crypt_firmware throws a *Panic* Stkov main...but it still does this even when the stack is at 0x8000 (default is 0x2000)
01:40:57S_a_i_n_t_rolo should take ~10seconds or so
01:41:00S_a_i_n_t_less even.
01:41:08saratogahmm then its probably frozen
01:41:58 Quit liar (Ping timeout: 252 seconds)
01:42:19saratogaTheSeven: with stock SVN I get no message on startup
01:42:29saratogaalthough I did crash rolo trying to update using rockbox USB mode
01:42:53kugelS_a_i_n_t_: it should take 2s or so, rather :)
01:45:07 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com)
01:45:48S_a_i_n_t_kegul: yes it *should* (;P) but I find sometimes it can take as long as 10 seconds or so.
01:45:57S_a_i_n_t_I haven't yet found what makes it vary
01:52:19TheSevensaratoga, S_a_i_n_t_: rolo on nano2g can take up to a minute, depending on the FTL state
01:52:44TheSevenas long as it's saying "Flushing storage buffers" it's probably working fine
01:52:57TheSevenit shouldn't say "executing" for more than a second though
01:52:57saratogait did give me a "clearing buffers" message, then sat at executing for roughly a minute or two
01:53:24saratogai ejected the disk in windows but didn't stop the USB device, is that a bad idea?
01:53:30TheSevenif it freezes at "executing" (which it is doing quite often) it's safe to reset - the FTL is unmounted at that point
02:00
02:00:40*TheSeven is working on nano2g battery calibration
02:01:04TheSevendid anyone figure out the nano2g charge completion gpio? (is there even one?)
02:08:16CIA-5New commit by 03amiconn (r25067): The GCC patch for building sh-elf-gcc now also fixes 'tr' arguments so that a dumb 'tr' can handle them. Needed for building sh-elf-gcc on ...
02:09:40amiconnBagder/ Zagor: The website needs updating (/gcc dir)
02:11:18 Quit gevaerts (Ping timeout: 256 seconds)
02:11:29 Join tari [0] (~adam@2610:130:115:b00:223:54ff:fea4:a5fb)
02:12:48 Join gevaerts [0] (~fg@rockbox/developer/gevaerts)
02:16:07 Quit n17ikh (Read error: Connection reset by peer)
02:18:27 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37)
02:19:43TheSevencompensating the battery readings for the inner resistance seems to work quite well and give *way* more accurate measurements during charging
02:20:16saratogaTheSeven: what do you mean?
02:20:32TheSeveninner resistance of the nano2g battery seems to be ~800 milliohms
02:20:46 Part LambdaCalculus37
02:21:12TheSeveni changed the battery reading code to also take the battery current into account and compensate the voltage drop across the inner resistance
02:21:56saratogainteresting idea
02:22:06saratogai guess that works because you've got an annmeter?
02:22:28TheSevenyes, i have a current ADC
02:23:10 Quit DerPapst (Quit: Leaving.)
02:23:10 Quit kaniini (Read error: Connection reset by peer)
02:23:12 Join kaniini [0] (~kaniini65@dyn75-70.yok.fi)
02:23:25TheSeven(a regular ADC measuring the voltage drop across a 160 milliohm shunt)
02:24:05 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com)
02:27:15kugelamiconn: why aren't the sh/m68k patches in upstream? did anyone sent it to them?
02:28:06kugelor is upstream fixed and we just use too old versions?
02:28:55kugelsaratoga: I can't download your parse_testcodec.pl.txt
02:30:09saratogakugel: it seems you have to be logged in as me to download it for some reason
02:30:13saratogai think the wiki is broken
02:30:41saratogakugel: http://pastebin.com/SjcxpruE
02:35:05 Quit Casainho (Ping timeout: 276 seconds)
02:35:33 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37)
02:36:56 Quit CGL (*.net *.split)
02:36:56 Quit simabeis (*.net *.split)
02:36:56 Quit krazykit (*.net *.split)
02:36:57 Quit lyngaas (*.net *.split)
02:36:57 Quit maraz (*.net *.split)
02:36:57 Quit rvvs89 (*.net *.split)
02:36:57 Quit rasher (*.net *.split)
02:38:26 Join CGL [0] (~CGL@190.207.198.83)
02:38:26 Join simabeis [0] (~simabeis@lobmenschen.de)
02:38:26 Join krazykit [0] (~kkit@adsl-76-252-13-109.dsl.ipltin.sbcglobal.net)
02:38:26 Join lyngaas [0] (~staale@19.81-167-149.customer.lyse.net)
02:38:26 Join maraz [0] (maraz@kapsi.fi)
02:38:26 Join rvvs89 [0] (robotnik@pdpc/supporter/base/rvvs89)
02:38:26 Join rasher [0] (~rasher@rockbox/developer/rasher)
02:39:34kugelsaratoga: the ape case doesn't work :(
02:39:42saratogabah
02:39:51saratogai don't think i t tested it since ape is so slow
02:40:47kugelI can't explain why, though
02:44:14kugelm/ape/ should match ape_c*
02:44:31saratogapastebin the input file
02:44:40 Quit scorche (Ping timeout: 252 seconds)
02:45:16 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean)
02:45:34saratogawhos alt account is matt0001 anyway
02:45:46 Quit planetbeing (Ping timeout: 252 seconds)
02:45:47 Nick planetbeing__ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net)
02:49:11 Join scorche [0] (~scorche@rockbox/administrator/scorche)
02:51:37 Join KennethFechter [0] (~4b21413f@giant.haxx.se)
02:53:10kugel$oldkey is empty after a52_stereo_192.ac3
02:53:37KennethFechterI am new to the rockbox wiki, and would like to request write permission. I don't know if this is necessary to create a new page for a port. I would like to contribute to a port for the Sony NWZ-728 and other NWZ players. I know there is a page on the walkman NWA, but this player is different
02:53:37kugelalright, got it working
02:53:43KennethFechterbrb
02:57:43saratogaKennethFechter: done
02:58:00saratogaKennethFechter: have you found out anything about that player?
02:58:01***Saving seen data "./dancer.seen"
03:00
03:07:37kugelsaratoga: I think so too (re wiki broken)
03:08:37kugelhttp://www.rockbox.org/wiki/bin/viewfile/Main/CodecPerformanceComparison?filename=parse_testcodec.pl.txt works
03:09:35kugelsaratoga: I uploaded latest eabi test codec results
03:09:52saratogacool
03:10:40 Quit Adnyxo (Ping timeout: 248 seconds)
03:13:41saratogakugel: maybe the EABI results shouldn't go under "current results" since they're not SVN results
03:13:44saratogaits a bit confusing
03:13:48saratogamaybe add an EABI heading?
03:14:57kugelsaratoga: they sure are svn results
03:15:03kugeljust a different compilre
03:15:19saratogawell i mean not the official build
03:15:35saratogalots of people looking at the results are probably just users who aren't aware of EABI
03:15:57kugelwell, feel free to make it more obvious if you like
03:16:24kugelI don't think lots of *users* are looking at it, understanding the numbers anyway
03:17:09kugelalso, I really doubt the difference to the default toolchain is caused by eabi. I think it's mostly a matter of the compiler version
03:19:12TheSevenkugel: we should do another test_codec run on nano2g and see if there is any difference to the last eabi one, which was done *before* i fixed the -mlong-calls thing
03:20:04Lloreankugel: People read that page all the time.
03:20:19LloreanThey don't understand the numbers, in most cases, but often users *think* they do
03:20:27LloreanAnd it should be accurate where those numbers come from
03:20:34kugelit is
03:21:09saratogai'll clean it up a little
03:21:17saratogaIMO the wiki should be as accessible as possible to users
03:22:24LloreanI think, at least, that non-SVN information should always be under a separate heading than SVN information wherever possible
03:22:33 Join Adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net)
03:22:36LloreanUsers should always be able to immediately be able to tell what pertains to what they're actually downloading
03:25:12Unhelpfulsaratoga: apparently 4.4 is known to have some integer performance regressions - this was mentioned in a review of compilers for ARM as being a problem with one of the specialized gcc-based compilers as well as with gcc itself
03:25:33saratogayeah its a bit slower
03:25:44*kugel maintains that this is SVN information
03:25:52saratogabut really pretty close, mostly because we leave so little performance critical code up to GCC :)
03:26:01KennethFechterback
03:26:06KennethFechterim looking it up right now
03:26:15KennethFechteralso, i have to log off real quick
03:26:44kugelwell, not really svn, since I haven't committed the rockboxdev.sh/configure changes for gcc 4.4.3 and binutils 2.20.1 yet :)
03:27:02saratogathere, now with nice CF and PP headings, and one for eabi
03:27:13Lloreankugel: It's not really SVN information unless the results come from the svn build provided by our build servers...
03:27:32kugelno results can come from the build servers
03:27:49kugeluntil we ship test_codec in current builds
03:27:52LloreanThey can come from a build as close as possible to what they provide.
03:28:05saratoganot true, I compile my test_codec on a build server :)
03:28:37saratogawhats teh nano2Gs cpu again? i don't see it on the wiki
03:28:49kugelarm940t
03:29:26saratoga Samsung S5L8701
03:30:01saratoganow we just need gigabeat and ams scores (once test_codec is updated for the later)
03:31:32 Quit KennethFechter (Quit: CGI:IRC (Ping timeout))
03:34:00 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon)
03:36:16*S_a_i_n_t_ wonders how to tell configure to use the eabi toolchain he just built...
03:36:21S_a_i_n_t_Anyone?
03:38:38 Quit bzed (Read error: Connection reset by peer)
03:38:40 Join bzed [0] (~bzed@devel.recluse.de)
03:39:05krazykitS_a_i_n_t_, checked the logs? i'm sure Unhelpful mentioned his changes at some point
03:39:48 Quit Adnyxo (Ping timeout: 260 seconds)
03:43:30S_a_i_n_t_I haven't no...I was kinda hoping for "Sure, just do 'configure -this' "
03:44:03kugelahh, codesourcery almost works without changes
03:44:12kugelof course it needs the patch we also apply to gcc
03:44:35 Quit komputes (Ping timeout: 265 seconds)
03:45:02saratogakugel: nice
03:45:06saratogai'm very interested in how it performs
03:52:07 Quit rasher (Ping timeout: 240 seconds)
03:52:10 Join rasher [0] (~rasher@0x5550f5a3.adsl.cybercity.dk)
03:52:11 Quit rasher (Changing host)
03:52:11 Join rasher [0] (~rasher@rockbox/developer/rasher)
03:53:32kugelsaratoga: some plugins needs disabling. binsize seems to be almost the same as in an eabi build
03:54:16kugeldoom's bss doesn't fit by 37k apparently!
03:54:58 Join chrisb [0] (~chrisb@pool-98-111-169-188.phlapa.east.verizon.net)
03:55:08 Join noob1 [0] (~ad15ebf0@giant.haxx.se)
03:55:17*chrisb ordered his sansa e250 from tigerdirect
03:55:49noob1Is anyone available to help me get my 240gb ipod working with rockbox?
03:57:45kugelsaratoga: fingers crossed, but I don't expect a huge difference seeing it's based on the gcc 4.4.x branch
03:58:31S_a_i_n_t_noob1: First off, what model/generation is your iPod?
03:58:51noob1ipod video 5th gen 60gb upgraded to 240gb w/ the apricorn kit
03:59:12 Join Guest76488 [0] (~sopgenort@pool-72-69-220-42.chi01.dsl-w.verizon.net)
04:00
04:00:10 Nick Guest76488 is now known as froggyman (~sopgenort@pool-72-69-220-42.chi01.dsl-w.verizon.net)
04:00:14 Join komputes [0] (~komputes@ubuntu/member/komputes)
04:01:46noob1@s_a_i_n_t: according to the many posts... all i have to do is reconfigure the .h file to have compat. w/ large disks. I am limited when it comes to compiling etc.. and I don't even know where to begin. I tried searching for the bootloader-ipodvideo.ipod file to install, but the post i found was 2 years old and the link is already dead.
04:02:23S_a_i_n_t_so...do you *have* a build environment set up?
04:02:37noob1No i do not.
04:02:42S_a_i_n_t_aha...
04:03:23UnhelpfulS_a_i_n_t_: configure −−eabi?
04:05:26kugelS_a_i_n_t_: if you had checked the help of configure you would have known
04:05:30S_a_i_n_t_a "bigdisk" build only needs the PHYS_SECTOR redifined and HAVE_LBA48 added....correct?
04:05:56 Quit karashata (Quit: The fluffy dragon has left completely!)
04:07:53 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
04:08:41noob1I believe so S.a.i.n.t
04:09:57noob1I think I may have stumbled on a page that has the files already compiled.
04:09:59S_a_i_n_t_I was kinda asking a dev..but hey, I'll give it a whirl and see if it compiles. If it does, I'll DCC you the build.
04:10:58noob1i think http://forums.rockbox.org/index.php?topic=22188.0 has the right files.
04:13:42S_a_i_n_t_Bah....it's easier for me to make the 2/3 changes to me own tree...it's compiling now.
04:13:47S_a_i_n_t_cross your fingers :D
04:14:21noob1hmm I don't think DCC works on web client does it?
04:14:21noob1lol
04:14:22 Join karashata [0] (~karashata@74-220-162-11.wightman.ca)
04:15:03 Quit Rob2222 (Ping timeout: 245 seconds)
04:17:35S_a_i_n_t_noob1: forgot to ask...is it 32MB or 64MB?
04:18:02S_a_i_n_t_if it's 64, I'll stop now and recompile.
04:18:26noob1You know, I believe it is 64
04:18:27noob1lol
04:18:29noob1so you can stop
04:18:34noob1Don't recompile
04:18:42noob1let me try and reboot the iPod, it should work w/ the file I found
04:18:57noob1I really appreciate your help, after 5 hours of searchign finally found something that worked lol
04:18:57S_a_i_n_t_you can't just add a patch to a build...
04:19:02S_a_i_n_t_it needs to be compiled.
04:19:10noob1it booted up though
04:19:33saratogathat build is oldish, so you might as well use your own if you've compiled it
04:19:43S_a_i_n_t_did you just grab one of the ancient build for the unsupported page?
04:20:02saratogawhy is the source zip for that build 75MB
04:20:09saratogawhat the heck did he put in there
04:20:28S_a_i_n_t_heaps of shit...I think Doom, etc..
04:20:29noob1http://forums.rockbox.org/index.php?topic=22188.0 | r23166_ipod_5G_64Mb_bigHDD.zip
04:20:33noob1is what i downloaded
04:20:40saratogadownloading it now just to see
04:22:33noob1Will that work or am I like 32074723094 builds back
04:22:56S_a_i_n_t_it'll work....but you'll miss a WHOLE HEAP of new stuff
04:23:02S_a_i_n_t_that build is ancient
04:23:11noob1oh
04:23:16noob1okay, i'll take yours then
04:23:17S_a_i_n_t_may as well wait for the build I'm compiling now to finish.
04:23:18noob1<3
04:24:17noob1I'm going to have to digg into the build environment sometime soon here. It's not too hard is it?
04:24:46saratogahttp://pastebin.com/dVr6CmtN
04:24:55saratogaheres teh actual patch for big disk from that build
04:24:58saratogaits like 2 lines
04:25:22saratoganoob1: no its not very difficult, its trivial if you've already got linux, a little harder if you have to use a virtualmachine or cygwin
04:25:53noob1I have Fedora on my laptop, Just finally getting a class on it starting this monday
04:26:05S_a_i_n_t_Cygwin may or may not be easier...as there are prebuilt cross-compilers.
04:26:08noob1So i'm hoping that'll make it easier
04:26:15saratogathen you just checkout rockbox svn, and run tools/configure
04:26:26saratogait'll build the cross compilers
04:26:29noob1Okay, i'll look into that
04:26:32S_a_i_n_t_but building the cross-compilers is trivial also.
04:26:45saratogafinally you have to add arm-elf-gcc to your PATH either using the export command or editing your startup script
04:27:09saratogathe wiki has step by step guides for ubuntu, should be the same for your distro
04:27:11noob1I take it that all of this info you guys are spilling out to me is in the wiki
04:27:14noob1yup
04:28:07noob1I'l figure it out, in the mean time i'll take your modification lol as I kinda want my ipod working tomorrow for my flac files. Gonna be a boring day in the datacenter
04:28:44S_a_i_n_t_well, I'll PM you the link to where I've uploaded the build when it finishes.
04:28:57S_a_i_n_t_If you need to leave, PM me your email or something.
04:29:05noob1I'll be here
04:29:09S_a_i_n_t_cool.
04:30:47noob1I find it funny that I can set up hardware and program them, but when it comes to software i'm so lost
04:31:55S_a_i_n_t_No-ones born win C/C++ embedded :P
04:32:22noob1Linus Torvald would disagree
04:32:22noob1:P
04:33:16 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey)
04:39:08 Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net)
04:42:06 Quit planetbeing (Ping timeout: 265 seconds)
04:42:07 Nick planetbeing_ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net)
04:42:31 Quit TheSeven (Disconnected by services)
04:42:43 Join The_Seven [0] (~theseven@rockbox/developer/TheSeven)
04:42:53 Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven)
04:50:02 Quit Llorean (Quit: Leaving.)
04:51:54chrisbcan rockbox display video on the sansa e250?
04:53:49kugelsaratoga: should I compare the codesourcery results to the eabi build, or to the default?
04:53:52advcomp2019yes look at the mpeg player wiki
04:54:24 Join Barahir_ [0] (~jonathan@gssn-5f754beb.pool.mediaWays.net)
04:55:57 Quit Barahir (Read error: Operation timed out)
04:58:05***Saving seen data "./dancer.seen"
04:58:39 Quit planetbeing (Quit: planetbeing)
05:00
05:00:19 Quit karashata (Quit: The fluffy dragon has left completely!)
05:02:23saratogakugel: default I think
05:02:40kugelgood, I just did so :)
05:02:46kugelI updated the wiki
05:03:18kugelthe results are puzzeling though
05:04:07kugelah wait, I mixed something up
05:06:12chrisbadvcomp2019: yes, the info on pluginmpegplayer is there
05:06:20kugel:'(
05:06:29chrisbadvcomp2019: and the sansa e200 performance is surprisingly good
05:08:21saratogakugel: fwiw this site recommends the 2009q1 build, which is still gcc4.3: http://hardwarebug.org/2009/08/05/arm-compiler-shoot-out/
05:09:10 Join Llorean [0] (~DarkkOne@adsl-99-158-46-229.dsl.hstntx.sbcglobal.net)
05:09:10 Quit Llorean (Changing host)
05:09:10 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean)
05:09:27saratogathough i guess the 4.4 version is probably better given our experience with gcc versions so far
05:11:10kugelok,, now my results make more sense
05:11:23kugelit appears cs is even worse than plain gcc
05:11:45kugelsaratoga: IIRC we've made tests with 4.3
05:11:51kugelsome codecs didn't work at all
05:11:53saratogayeah i think they were a little worse
05:11:56chrisbhow can the mpeg performance on sansa e200 be better than the iPods?
05:12:04saratogasmaller screen
05:12:33saratogaplus the e200v1 screen is really fast for some reason
05:13:28kugeldma behind the scenes
05:14:18kugelthe lcd controller polls from a separate framebuffer automagically. lcd_update() and friends merely do a memcpy to that framebuffer, that's why it appears to fast
05:14:22chrisbscreens have the same pixel count
05:15:48scorche|shipods have many different sized screens...perhaps you should clarify which one
05:16:51saratogascorche|sh: can you give bohoon dev rights on the forum
05:18:07scorche|shwhen i get home, sure...though if he sent me a pm or email, i would perhaps get to these things much sooner
05:18:16saratogahe probably doesn't know
05:18:30saratogachrisb: assuming you mean the ipod photo, its probably just due to the screen speed
05:19:35 Quit Strife89 (Quit: To bed!)
05:19:40scorche|shsaratoga: well, arent i mentioned twice in the commit access mail? ;0
05:19:53saratogayeah thats true
05:19:54*scorche|sh glares at his right parens key
05:20:04saratogabut this is the guy who didn't even contact us until he had the port basically finished
05:20:30kugelsaratoga: I can do a test tomorrow, but you could do it yourself as well :)
05:20:46kugeljust download their package, and at it to PATH. it's fairly trivial
05:20:51 Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net)
05:20:56saratogakugel: yeah but i'm lazy and should be working
05:21:02saratogai've basically lost faith in newer gcc though
05:21:29saratogaat this point we're pretty close to ASM'ing everything that matters on ARM anyway
05:21:55kugelwell, looking at the results, we would've probably switched if flac wasn't so bad
05:22:23chrisbthe sansa seems to be a bargain product with premium performance
05:22:24kugelyou shouldn't forget the binsize decrease 4.4.x gives (a few K alone, about 60k on PP due to long calls removed=
05:23:11 Quit planetbeing (Client Quit)
05:24:11 Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net)
05:24:18kugelthe major codecs are better or the same, actually
05:25:34kugelit's really only flac which is so sad. the rest is fine
05:26:03 Quit saratoga (Ping timeout: 252 seconds)
05:26:50kugelI would eventually switch right now, flac is fast enough anyway
05:29:06 Quit anewuser ()
05:29:57 Quit planetbeing (Quit: planetbeing)
05:30:06 Join wind [0] (~74030e7e@giant.haxx.se)
05:32:00windI wonder how to make a english-Chinese dictionary.
05:34:21 Quit kugel (Remote host closed the connection)
05:36:43 Join teru [0] (~teru@KD059133108225.ppp.dion.ne.jp)
05:40:50 Quit Horscht (Quit: Verlassend)
05:40:56chrisbwind: that problem has been solved
05:46:07 Part froggyman
05:49:31 Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net)
05:53:14chrisbis there any limit on the size of the SD card that sansa e200 rockbox can address?
05:53:33chrisbthere seems to be a limit in the native firmware
05:54:23S_a_i_n_t_The OF does not govern any of rockbox's behaviour
05:56:26windchrisb:Sorry,I saw it just now.You say it had been solved,what's the meaning?
05:56:53chrisbwind: longman's english-chines dictionary exists
05:57:15windCan I download?
05:57:18 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.2.183)
05:57:52windCould you give me a website?
05:58:48 Quit S_a_i_n_t_ (Ping timeout: 245 seconds)
05:59:14 Join S_A_I_N_T__ [0] (S_a_i_n_t@203.184.2.3)
06:00
06:00:19chrisbwind: i don't think that is available for download
06:00:26 Quit S_a_i_n_t (Disconnected by services)
06:00:35chrisbhttp://sourceforge.net/projects/mengdict/
06:00:43 Nick S_A_I_N_T__ is now known as S_a_i_n_t (S_a_i_n_t@203.184.2.3)
06:00:49windThanks
06:01:02windI will try
06:01:28chrisbhttp://cgibin.erols.com/mandarintools/cedict.html
06:02:00windOh,no.it's a Chinese to English electronic dictionary
06:02:25windI just want a English to Chinese one.
06:03:00windThank you all the same.
06:07:42 Quit LambdaCalculus37 (Quit: Fwump)
06:13:37S_a_i_n_twind: I believe (with some effort on your behalf) it is possible to use dict.rock to create a language X/language Y dictionary
06:13:52S_a_i_n_ttry the plugins page on the wiki
06:22:08windS_a_i_n_t:I am doing it,but it's too large.
06:23:23S_a_i_n_tyes, I know...the wordnet files are pretty big.
06:23:44S_a_i_n_tStardict is even bigger...the .dict file is 4.5 million lines.
06:26:02windI have read the plugin page.But still confused.
06:27:23windI think I have to chang the codes of dict.c to make it easy.
06:31:19 Quit noob1 (Quit: CGI:IRC)
06:31:22 Join noob1 [0] (~ad15ebf0@giant.haxx.se)
06:39:24 Quit CaptainKewl (Read error: Connection reset by peer)
06:51:15 Join CaptainKewl [0] (~jason@207.237.107.203)
06:54:45 Quit JdGordon (Ping timeout: 245 seconds)
06:58:06***Saving seen data "./dancer.seen"
07:00
07:01:45 Quit wind (Quit: CGI:IRC (Ping timeout))
07:04:13 Quit chrisb (Ping timeout: 245 seconds)
07:07:55 Quit noob1 (Quit: CGI:IRC)
07:10:45 Quit Tomis (Quit: Tomis)
07:11:02 Join Tomis [0] (~Tomis@70.134.89.66)
07:14:32 Join CaptainKewllllll [0] (~quassel@207.237.107.203)
07:15:53 Quit CaptainKewllllll (Remote host closed the connection)
07:29:43 Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-soovbmllihzmnrkj)
07:44:01 Join Zagor [0] (~bjst@46.35.227.87.static.tab.siw.siwnet.net)
07:44:01 Quit Zagor (Changing host)
07:44:01 Join Zagor [0] (~bjst@rockbox/developer/Zagor)
07:46:38 Quit mt (Ping timeout: 252 seconds)
07:57:18 Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk)
08:00
08:00:20 Join mt [0] (~mtee@rockbox/developer/mt)
08:04:47 Quit CaptainKewl (Remote host closed the connection)
08:08:20 Join FlynDice [0] (~FlynDice@wsip-98-191-154-2.oc.oc.cox.net)
08:10:07 Quit FlynDice (Remote host closed the connection)
08:10:15 Join FlynDice [0] (~FlynDice@wsip-98-191-154-2.oc.oc.cox.net)
08:13:36 Quit mt (Ping timeout: 248 seconds)
08:21:06 Join ender` [0] (krneki@foo.eternallybored.org)
08:24:52 Quit Llorean (Read error: Connection reset by peer)
08:27:48 Join stoffel [0] (~quassel@p57B4C7BB.dip.t-dialin.net)
08:28:20 Join mt [0] (~mtee@rockbox/developer/mt)
08:28:30 Join stooo [0] (~sto@f050226099.adsl.alicedsl.de)
08:28:41 Quit FlynDice (Ping timeout: 276 seconds)
08:29:14 Quit stooo (Client Quit)
08:29:55 Join patgodo [0] (~chatzilla@g225081210.adsl.alicedsl.de)
08:55:23 Join petur [0] (~petur@rockbox/developer/petur)
08:58:09***Saving seen data "./dancer.seen"
09:00
09:00:19 Quit arbingordon (Ping timeout: 260 seconds)
09:00:58 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
09:02:50 Part patgodo
09:06:28 Join FlynDice [0] (~FlynDice@wsip-98-191-154-2.oc.oc.cox.net)
09:09:38 Quit n17ikh (Ping timeout: 276 seconds)
09:14:56 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com)
09:15:12 Join LinusN [0] (~linus@rockbox/developer/LinusN)
09:19:32 Join gill0r_ [0] (~gill0r@f050132026.adsl.alicedsl.de)
09:23:06 Quit gill0r (Ping timeout: 256 seconds)
09:35:27 Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net)
09:35:42 Quit planetbeing (Quit: planetbeing)
09:35:42 Nick planetbeing_ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net)
09:40:24 Join MethoS- [0] (~clemens@134.102.106.250)
09:46:36 Join Rob2222 [0] (~Miranda@p4FDCB621.dip.t-dialin.net)
10:00
10:05:46amiconnS_a_i_n_t: For most disks with hlarge physical sectors it's better to *remove* MAX_PHYS_SECTOR_SIZE
10:06:10amiconnOnly disks with silly firmware need this workaround
10:11:03 Join DerPapst [0] (~DerPapst@p4FE8F3B2.dip.t-dialin.net)
10:28:13 Join pamaury [0] (~pamaury@sphinx.lix.polytechnique.fr)
10:31:35 Join xavieran [0] (~xavieran@ppp118-209-114-195.lns20.mel4.internode.on.net)
10:36:24 Quit FlynDice (Remote host closed the connection)
10:36:49 Quit DerPapst (Quit: Leaving.)
10:37:52S_a_i_n_tAh well...bit late for that now. I assume the build is working, as the guy I built it for seems pretty happy.
10:38:35 Quit pamaury (Quit: Quitte)
10:39:37 Join pamaury [0] (~pamaury@sphinx.lix.polytechnique.fr)
10:44:26 Quit pamaury (Client Quit)
10:49:39 Join pamaury [0] (~pamaury@sphinx.lix.polytechnique.fr)
10:58:13***Saving seen data "./dancer.seen"
11:00
11:00:54S_a_i_n_tWhat're the chances of the theme site being able to use the .7z extension? My latest theme is half the size of the zip on the themesite when its in 7z format (which I keep all my themes in locally) and the 7z versions I keep include the fonts as well yet are still ~50% of the size of the zip (without fonts)...
11:04:28 Quit BHSPitMonkey (Remote host closed the connection)
11:09:09rasherS_a_i_n_t: unlikely to happen anytime soon. Would require quite a few changes on the themesite and in rbutil, and the gains are minimal
11:11:18amiconnS_a_i_n_t: It also works if you increase MAX_PHYS_SECTOR_SIZE, but performance is worse than if you remove it
11:11:43*S_a_i_n_t did not know this...
11:12:00amiconnMAX_PHYS_SECTOR_SIZE is only necessary if the drive's firmware is unable to split and join large sectors itself. If it does, it does so better than rockbox
11:12:21S_a_i_n_tI did ask, but I needed to knock it up pretty quickly...(as even when you're helping people, they get impatient).
11:12:57amiconnThis is why it was added - the original hdd of the 80GB iPod Video is unable to do this itself
11:13:18 Quit mt (Ping timeout: 240 seconds)
11:14:15amiconnThe proper solution would be probing, but that needs to be done by someone with an 80GB G5.5, preferably also having access to one of the larger disks which handle things themselvs
11:15:46 Join mt [0] (~mtee@rockbox/developer/mt)
11:21:42 Join mischasworld [0] (~quassel@g227018115.adsl.alicedsl.de)
11:32:05 Join Hellfish [0] (~chatzilla@lo-2-vpn8.matrix.farlep.net)
11:32:33 Quit Hellfish (Client Quit)
11:33:23 Join m3dlg [0] (~m3dlg@bb-87-81-252-83.ukonline.co.uk)
11:39:28 Join efyx_ [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net)
11:42:24 Quit m3dlg (Ping timeout: 264 seconds)
11:42:59 Quit doomcup (Ping timeout: 264 seconds)
11:49:18*amiconn points Zagor to http://www.rockbox.org/irc/log-20100308#02:09:40
11:49:26 Join doomcup [0] (~doomcup@c-24-22-223-47.hsd1.wa.comcast.net)
11:54:42Zagorhmm, I wonder why the front page stopped updating
11:54:47 Join Sajber^ [0] (~Sajber^@93-73.anonymous.at.anonine.com)
11:54:58 Quit stoffel (Ping timeout: 240 seconds)
11:55:28 Quit Sajber^ (Read error: Connection reset by peer)
11:55:28Zagoroh, it didn't
11:55:49Zagoramiconn: /gcc updated
11:55:53 Join Sajber^ [0] (~Sajber^@93-73.anonymous.at.anonine.com)
11:58:37 Quit shaggy-h (Ping timeout: 240 seconds)
11:59:19amiconnThanks
12:00
12:00:21 Quit Battousai (Read error: Operation timed out)
12:02:05 Join DerPapst [0] (~DerPapst@p5099d40e.dip0.t-ipconnect.de)
12:03:36 Join Battousai [0] (~bryan@gentoo/developer/battousai)
12:05:27 Quit Tomis (Quit: Tomis)
12:07:09 Join dfkt [0] (dfkt@unaffiliated/dfkt)
12:08:42 Quit mischasworld (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
12:14:25 Join robin0800 [0] (~quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com)
12:17:03 Join stoffel [0] (~quassel@p57B4C7BB.dip.t-dialin.net)
12:17:28 Join m3dlg [0] (~m3dlg@212.183.140.6)
12:27:59 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow)
12:41:29 Quit teru (Quit: Quit)
12:42:04 Quit m3dlg (Quit: RAGE QUIT)
12:54:37 Quit moos (Ping timeout: 252 seconds)
12:57:27 Quit Kitar|st ()
12:58:17***Saving seen data "./dancer.seen"
12:59:01 Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk)
13:00
13:03:45 Join Casainho [0] (~chatzilla@87.196.54.156)
13:05:53 Join perfectdrug_ [0] (~marko@p5B0EC53B.dip.t-dialin.net)
13:08:12 Join Kitar|st [0] (Kitr88@89.142.235.223)
13:08:31CIA-5New commit by 03nls (r25068): Use the same output func for wav writing and checksum calculation, simplifying the code and possibly speeding up checksum calculation slightly
13:08:52 Quit stoffel (Ping timeout: 246 seconds)
13:09:37 Quit perfectdrug (Ping timeout: 245 seconds)
13:11:43 Quit tari (Quit: Leaving)
13:11:58 Join gibbon_ [0] (gibbon_@not.a.servant4you.org)
13:27:58 Join stoffel [0] (~quassel@p57B4C7BB.dip.t-dialin.net)
13:31:34 Quit gill0r_ (Remote host closed the connection)
13:42:12 Join n1s [0] (~n1s@rockbox/developer/n1s)
13:47:36 Join Farthen [0] (~chatzilla@e179232245.adsl.alicedsl.de)
13:50:38 Quit n1s (Ping timeout: 265 seconds)
13:55:06 Quit GeekShadow (Ping timeout: 256 seconds)
13:55:20 Quit Farthen (Ping timeout: 260 seconds)
14:00
14:00:08 Join ecio [0] (~ecio@244-108.202-68.tampabay.res.rr.com)
14:00:25CIA-5New commit by 03pamaury (r25069): - Fix the control_handler selection in usb_core when a request in sent to an endpoint (use endpoint dir and not EP_CONTROL !) ...
14:02:15 Quit ecio1 (Ping timeout: 260 seconds)
14:04:50 Part flyback
14:07:44 Join Adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net)
14:09:19 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow)
14:09:22 Join anewuser [0] (anewuser@unaffiliated/anewuser)
14:18:46 Quit stoffel (Remote host closed the connection)
14:20:11TheSevenpamaury: could that be related to the hid trouble we're seeing?
14:20:32 Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.0.33)
14:21:24 Quit S_a_i_n_t (Ping timeout: 258 seconds)
14:26:25 Join nima [0] (~nima@adsl-75-45-230-107.dsl.sfldmi.sbcglobal.net)
14:29:16 Quit nimak (Ping timeout: 268 seconds)
14:29:50 Join Schmogel [0] (~Miranda@p3EE21F1B.dip0.t-ipconnect.de)
14:31:49pamaurydon't think so but you can check
14:32:11pamaurythis is more a sanity check and this is needed for a (possibly) upcoming usbaudio driver
14:32:45pamaurywhat is the hid trouble ? You mean hid during ums transfer has some trouble ?
14:46:02 Join froggymana [0] (~187b533e@giant.haxx.se)
14:56:28 Quit ecio (Ping timeout: 260 seconds)
14:57:18 Join pixelma_ [0] (quassel@rockbox/staff/pixelma)
14:57:19 Quit pixelma (Disconnected by services)
14:57:22 Quit amiconn (Disconnected by services)
14:57:24 Join amiconn_ [0] (quassel@rockbox/developer/amiconn)
14:57:36 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma)
14:57:50 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn)
14:58:01 Nick perfectdrug_ is now known as perfectdrug (~marko@p5B0EC53B.dip.t-dialin.net)
14:58:20***Saving seen data "./dancer.seen"
15:00
15:02:26 Quit gibbon_ (Quit: Lost terminal)
15:05:35 Join gibbon_ [0] (gibbon_@not.a.servant4you.org)
15:06:05 Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick)
15:10:18TheSevenpamaury: HID also has trouble during enumeration, which windows usually works around in some way, but it causes massive trouble on linux
15:11:39pamauryreally ? which troubles ? I'm not sure I ran into those problems
15:16:25 Quit DerPapst (Read error: Connection reset by peer)
15:18:18 Join DerPapst [0] (~DerPapst@p5099d40e.dip0.t-ipconnect.de)
15:19:03TheSeventhey could also be nano2g driver problems...
15:19:17TheSeveni can't test right now as I'm running a battery bench
15:19:18 Join jgarvey [0] (~jgarvey@cpe-065-190-069-073.nc.res.rr.com)
15:20:04TheSevenbtw. what's the opinion on storage speedups that cause high additional memory usage?
15:20:31 Quit jgarvey (Client Quit)
15:20:45TheSeven(depending on the kind of optimization this may be in the range of 8KB to 1MB)
15:21:06ZagorTheSeven: usb storage or rockbox use storage?
15:21:10TheSevenboth
15:21:19pamauryhow ?
15:21:31linuxguy3how do i differentiate between a fuze v1 and v2
15:21:34linuxguy3without opening it
15:21:50Tornefirmware version 1.x is a fuze v1, firmware 2.x is a fuze v2
15:21:52TheSevenparallelizing reads/writes to different banks in the NAND driver and FTL
15:21:53 Quit robin0800 (Remote host closed the connection)
15:22:06TheSevenand possibly memory-buffering scattered page commits
15:22:12ZagorTheSeven: more usb speed is always good. do we have any use case where we'd notice in rockbox use?
15:22:36TheSevenprobably not, but only doing it part of the time won't work well
15:22:59TheSeven(if you're planning to steal the additional memory from the audio buffer :-) )
15:24:31Zagorsince this is for flash targets, I can't see why not. it's not like we'll be spinning up the drive more often.
15:27:06 Join ecio [0] (~ecio@adsl-065-081-069-051.sip.mco.bellsouth.net)
15:27:24linuxguy3Torne: thx
15:47:18 Join kugel [0] (~kugel@rockbox/developer/kugel)
15:48:02 Quit Casainho (Read error: Operation timed out)
15:49:13CIA-5New commit by 03kugel (r25070): Update rockboxdev.sh/configure for arm-elf-eabi-gcc 4.4.3 and binutils 2.20.1. ...
15:50:33kugelTheSeven: good question! I also have a patch for sansa ams which increases transfer speed at the expense of ram usage
15:51:54kugelI would like to invite everybody to answer to my proposal on the mailing list! :)
15:52:43*linuxstb only uses FLAC.... ;)
15:52:52linuxstbWhat's "a good deal slower" ?
15:53:17*linuxstb should probably rtfw
15:53:53 Quit froggymana (Quit: CGI:IRC)
15:54:16Zagorkugel: commit first, then discuss?
15:55:11kugelZagor: hehe, no :) I just updated what has already been there (you can since a while select an optional eabi toolchain in rockboxdev.sh/configure)
15:55:21kugelmy mail is about changing our default toolchaib
15:55:26kugelchain*
15:55:40Zagorah
15:55:51linuxstbkugel: I was also confused by your commit message - it sounded like you had changed it to use arm-elf-eabi, rather than change the version for arm-elf-eabi...
15:55:54 Join knine [0] (~kaniini65@dyn75-70.yok.fi)
15:56:11Zagorkugel: it sounds good to me. what does "a good deal slower" for flac mean more specifically?
15:56:21linuxstbZagor: IIUC, about 10% slower
15:56:30kugelI linked to the wiki page, didn't I? :)
15:56:41Zagoroh, you did :)
15:56:46linuxstb"about 10% slower" is less to type than "a good deal slower"...
15:57:02kugelmore 8-9%, but it's still a good deal
15:57:32kugelbut I'm inclined to believe that due to the massive ram usage win, flac will still be a netto win w.r.t to battery runtime
15:57:34linuxstb"a good deal" is subjective.
15:57:43Zagorat 593% realtime, we can live with it
15:57:52kugelflac is so fast, this 10% don't really matter. it runs unboosted on all targets anyway
15:58:11linuxstbBut anyway, I think you should go ahead as well - now is a good time as we've just done a release. So it gives a while for any bugs to be found.
15:58:32kugelbut 60k more ram may have an influence on the battery runtime, especially on typically large flac files
15:59:23 Quit kaniini (Ping timeout: 260 seconds)
15:59:28Zagorkugel: just out of curiosity, what distros ship cross compilers?
15:59:34*kugel probably should've linked to http://www.rockbox.org/wiki/CodecPerformanceComparison#EABI_New_gcc_results directly
15:59:40linuxstbkugel: Have you tested the AMS dualboot code with the eabi toolchain?
16:00
16:00:31kugelno, not really. but is there really a chance that different code is generated in pure assembly?
16:01:17*linuxstb trusts nothing when it comes to gcc
16:01:30kugelyea, but this isn't gcc. it's gas :)
16:01:30 Part LinusN
16:01:54kugelit's possible that the flac speed drop comes from a gcc decision to not inline some functions. if we spot those we might be able to recover flac
16:03:02 Quit linuxguy3 (Ping timeout: 276 seconds)
16:03:33 Join linuxguy3 [0] (~timj@adsl-75-57-163-104.dsl.emhril.sbcglobal.net)
16:03:45mc2739kugel: I would be happy to test on my e200v2 if you can build a bootloader and mkamsboot for me. If there is a problem, the e200v2 is recoverable and I have recovered it in the past.
16:05:28TheSevenerm, actually you could just build the code with both toolchains and compare the resulting binary. if it's only assembly code, it should be identical
16:05:45kugelZagor: I was under the impression that at least debian has a crosscompiler .deb, but I can't find it right now.
16:05:57kugelTheSeven: that's my thinking too
16:06:13kugelmc2739: ok, give me a few seconds :)
16:10:17 Join merbanan [0] (~banan@c-94-255-221-92.cust.bredband2.com)
16:14:03amiconnTheSeven: Speeding up things by caching should *imo* only be done if it doesn't reduce reliability
16:14:08kugelthe size and md5sum of the dualboot binaries is the same, at least
16:14:25kugelnrv2e_d8.arm-bin is different, though (2 byte smaller)
16:14:52TheSevenamiconn: it's just using bigger internal buffers to speed up multi-page writes by writing 4 pages at once
16:15:01amiconnA sudden poweroff is dangerous if you do write caching
16:15:42TheSeven(and possibly buffer a whole flash block in memory during copying operations, if that yields enough speed gain to justify the memory usage)
16:16:17TheSevena sudden poweroff will have the same effects without that kind of caching
16:16:40TheSeven(and it should be 100% recoverable by nandfsck)
16:16:43amiconnThat's why the scatter/gather buffer to support 512-byte accesses on the MK8011GAH (ipod G5.5) always writes immediately
16:17:31TheSevenit won't write 4 times if it's told to write a contiguous 2KB block though, huh?
16:17:41kugelerm, my system doesn't have 'cc' :/
16:17:43 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
16:17:52TheSevenmake CC=gcc
16:18:25TheSeven(at least if the makefile is somewhat sane)
16:18:26kugelsure but I should have cc :)
16:18:51amiconnTheSeven: Physical sectors are 1K on that disk. If you write sequentially using 512 byte blocks, the rockbox code will read 1KB, replace first half, write 1KB, read the same 1KB again, replace second half, write 1KB again
16:19:26TheSeveneven if that's done in a single write call?
16:19:39amiconnno
16:19:59amiconnBut some code in rockbox uses 512 byte buffers
16:20:10TheSevensome code, but probably not USB transfers
16:20:19TheSevenactually, to buffer those, i wouldn't need any additional memory
16:20:20amiconnNo, those *nver* do
16:20:44TheSeventhe place where i need the memory is for internal copying-around operations in the FTL
16:20:44amiconnSince the G5.5 presents 2048 byte sectors on the wire, it will never happen
16:21:46amiconnWhat's especially nasty about sector gathering is that the disk firmware doesn't expect a subsequent write to the *same* sector, so that causes an internal seek
16:22:39amiconnRockbox doesn't write too often, so I don't think it's a problem. And large writes (e.g. when copying files) aren't affected
16:23:20amiconnThis could be solved by caching, but only if we limit the cache-dirty time
16:23:23TheSevenand exactly these could be sped up by a factor of up to 4 depending on the flash on nano2g
16:23:47 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.167)
16:24:39amiconnThat would require the ata thread to do the cache flush, but two threads are writing at the same time, i.e. that requires careful locking
16:25:35 Quit S_a_i_n_t_ (Ping timeout: 264 seconds)
16:26:01amiconnWhat amount of ram are we talking about on the Nano G2?
16:26:30TheSevendepending on the way we do it, it'll be from 8K to 1M
16:27:40TheSeven8K should already yield a significant speedup
16:31:23linuxstbkugel: nrv2e_d8.arm-bin is thumb code, so probably the eabi toolchain doesn't pad it to a multiple of 4 bytes. I can't remember, but it's possible that may cause an issue (e.g. if mkamsboot assumes it is a multiple of 4 bytes)
16:31:50kugelyea, you're right. it's lacking 2 bytes of zero padding
16:32:11amiconnHow much ram does the Nano G2 have, again? It's not listed on http://www.rockbox.org/wiki/DeviceChart
16:32:56Torneamiconn: it still seems like it woul dbe nicer to have fat support large sectors
16:33:19amiconnFAT does support large sectors, that's not the problem
16:33:49TheSeven32MB
16:34:04Tornehrm?
16:34:32TheSevenTorne: the problem only exists if the FAT sector size is smaller than the disk minimum-write unit
16:34:35linuxstbkugel: And I think this will cause a problem - mkamsboot builds the image backwards, starting with the ucl unpack function. So if that's not a multiple of 4, all the earlier data will be unaligned.
16:34:50TorneTheSeven: yes, but that's fine on 5.5g isn't it?
16:35:11TheSeventhat should be fine, as long as you don't use weird disks that need 4K writes
16:35:30Tornemy point is that if our FAT code supports large sectors you can just format the disk with 4k sectors
16:35:39Torneand then you don't need the read/modify/write code, no?
16:35:45Tornei thought we didn't have the code to do that
16:35:47amiconnThe disks with 4K physical sectors known so far have proper partial sector handling
16:35:51Tornewell whatever size
16:35:53kugelis there an gas statement to enforce padding?
16:35:57linuxstbkugel: Possibly the easiest fix is to change bin2c to pad to a multiple of 4 bytes.
16:35:58TheSeven.align
16:36:14Torneand even if the disk *does* have proper partial sector handling it's still better to format it with larger sectors and obey that in the fat code, no? will be faster.
16:36:14TheSeventhis is a 2^n value, so you'll probably want to do .align 2
16:36:24Torneam i missing something?
16:36:31TheSevenOF support?
16:36:56kugelit's 8 bytes bigger now with .aign 4 at the end
16:37:05TheSeven[16:35]<TheSeven>this is a 2^n value, so you'll probably want to do .align 2
16:37:12amiconnTheSeven: I think that on a flash target with such a large amount of RAM, you should really spend that extra ram to improve speed
16:37:19amiconnEspecially if it's just 8KB
16:37:36TorneTheSeven: I was assuming that the OF's fat implementation doesn't mind large sector sizes either
16:37:39TheSevenyes, i'll do the 8K one for sure, but I'm not sure if the 1M one makes sense
16:37:51TorneTheSeven: since even quite obscure fat implementations i've seen get it right
16:38:07Tornein fact i was assuming that itunes, if it had any sense, would format the player with larger sectors anyway
16:38:18*TheSeven is paranoid about apple fat implementations since he spotted that hex bug yesterday
16:38:33kugelTheSeven: thanks, I didn't see that remark. the zero padding is now a nop, it should be fine I guess?
16:38:38linuxstbkugel: I think it's safer/cleaner to make bin2c handle the alignment.
16:38:43amiconnTorne: It has to, since it has no choice if the disk is presented as having 2K sectors via usb
16:38:53Torneamiconn: er
16:38:55linuxstbOr at least, it should check that all input files are a multiple of 4.
16:38:58Torneamiconn: i think we're talking cross purposes
16:39:13Torneamiconn: i am talking about the BPB of the FAT filesystem actually listing ht esector size as being whatever the disk's real sector size is
16:39:20 Join toffe82 [0] (~chatzilla@12.169.218.14)
16:39:22Tornei.e. clusters being in multiples of 1024 bytes or whatever, instead of 512 bytes
16:39:29TheSeven*does* the apple OF use 2K sectors via USB?
16:39:41Tornethat has nothing to with USB, unless i'm very much misundertanding
16:39:54amiconnTheSeven: On the iPod Video G5.5 - yes. On all older ipods - no
16:40:21TheSevenTorne: if the USB driver presents the device to the host as having 2K blocks, the host just can
16:40:30TheSevencan't go below that with it's fat sector size
16:40:37amiconnTorne: It has very much to do with it. Windows cannot handle a fat partition when the logical sector size differs from the physical sector size (as presented via usb or other interface)
16:40:57Torne..er, but that's fine, no?
16:41:02amiconnOn linux you can use 2^n multiples, but not fractions
16:41:07Tornemy point was that we want it to be that big..
16:41:16TheSevenamiconn: even if it's bigger?
16:41:17Torneso if it is already that big, and our fat code handles it being tha tbig..
16:41:26Tornethen why do we need the code in the ata driver to handle it?
16:41:30TheSeventhen we'll need to stick with the of values if we want to be compatible
16:41:43Tornewe shouldn't be generating unaligned accesses anyway, surely
16:42:07TheSevenTorne: because changing that opens a can of stkov's
16:42:21amiconnTorne: Again, our fat code handles large *logical* sector sizes
16:42:32amiconnThat has nothing to do with access sizes.
16:42:33TheSevenwe're currently trying to clean that out on the nano2g, which actually *does* present 2K-sectors to the FAT code
16:43:20Torneamiconn: Yes, that was what I was asking. Why don't we use the sector size as the access size? that's what it's for. are there really that many places where it's on the stack? (this seems odd)
16:43:36amiconnThere are several reasons
16:43:49amiconnStack usage, and ram usage
16:44:17TheSevenand some hardwired 512 values at some places, which are hopyfully all caught by now
16:44:38amiconnWhen support for the G5.5 was added, the first approach was to increase the buffers. This resulted in great instability (probably stack overflows)
16:44:44Torneisn't there just one buffer in the fat code?
16:44:45linuxstbAre people still reporting stack overflows on the Nano2G?
16:44:52TheSevenyes
16:45:03TheSevenpictureflow, rockboy and some game are still stkov'ing
16:45:20linuxstbWhat about dircache or the database?
16:45:27TheSeventhose apparently work fine
16:45:31amiconnTorne: No. Every file descriptor has a several buffers for various purposes.
16:45:42TheSeven(dircache was fixed to not have sector buffers on the stack by pamaury some weeks ago)
16:45:49 Join CaptainKewllllll [0] (~2669ecc2@gateway/web/freenode/x-fyxcglrbqvywkrui)
16:46:08linuxstbTheSeven: Ah OK. I didn't notice that dircache fix.
16:46:51*pixelma is somehow reminded of the broken "properties" on coldfire
16:46:59Torneamiconn: hm, ok, so that's one per fd looking at file.c
16:47:11Torneanyway, yes
16:47:44TheSevenah, and battery bench is also stkov'ing with the default stack size, for whatever reason
16:47:46Tornei just don't see why there is a need for them to be on the stack ever, or that we need so many of them that having them in .data would be unreasonable..
16:47:58kugellinuxstb: alright. I get identical dualboot output now
16:48:41pamaurylinuxstb: r24708
16:49:46kugellinuxstb: I verified that the bin2c change still produces the same output with the old toolchain. should I just commit that regardless?
16:50:22linuxstbkugel: Yes, I think so - it's a sensible thing to check.
16:50:28amiconnTorne: That's for files. Check dir_uncached.h and fat.h how many buffers *one* open dir needs: It's 6 sector-sized buffers
16:50:50linuxstbkugel: So are you padding in bin2c or giving an error if the size isn't a multiple of 4?
16:50:52kugelhttp://pastie.org/859675 is the diff
16:50:57kugelthe former
16:52:22linuxstbYou could just use a memset instead of the for() loop... And your "/* Append 0" comment isn't closed.
16:53:07kugelit is with the next line, but I didn't mean to add a comment there anyway
16:53:54Torneamiconn: ok i have to ask, why do we cache three sectors per dirent?
16:54:00Tornethat seems like a weird number
16:54:28kugelI didn't think of memset :)
16:55:45amiconnI think it has to do with the maximum number of slots a longname entry can occupy
16:57:45Torneamiconn: Aha
16:58:01TorneIn which case, that's not as bad as you claim
16:58:09amiconnhmm?
16:58:19Torneit's three because you might need 640 bytes for a LFN entry
16:58:23***Saving seen data "./dancer.seen"
16:58:32Tornei guess 672 with the actuall 8.3 entry as well
16:58:39Torneif your sector size is 2048 then you only need one :)
16:58:42Torneer, two
16:58:46amiconnYes, so you could reduce it to two with 1K or larger sectors
16:59:06amiconnBut you can't go below two regardless how large the sectors are
16:59:24amiconn...since an entry can always cross a sector boundary
16:59:54Tornewell yeah
17:00
17:00:25amiconnBut supporting larger sectors in the fat code natively does not only require making the sectors larger, it also requires making the logical sector size dynamic
17:01:12Torneyeah
17:01:14Tornei realise
17:01:19Tornei just can't help but think that'd be better..
17:01:26amiconnThe rockbox binary is the same for G5 (with 512 byte logical sectors) and G5.5 (with 2048 byte logical sectors)
17:01:58Torne(also you really don't need to keep 3 sectors *around* per directory)
17:02:12Torneyou need to have enough sectors to read a LFN for one call to getnext()
17:02:19Tornebut there's only really any point in caching the last one
17:02:29amiconnAnd you still need partial sector support in the ata driver, because a fat with 512 byte logical sectors must be handled even if the disk has 4K physical sectors
17:02:42Torneso you could do it with one sector per open dir, and two sectors globally
17:02:50Torne(i think)
17:04:08TheSevenyou just revealed a huge waste of memory on the nano2g :-)
17:05:06amiconnThe current way of supporting large logical sectors is quite simple. Just multiply all sector counts in the bpb by (sector_size/512)
17:05:10CIA-5New commit by 03kugel (r25071): Make bin2c ensure that the generated C arrays are 32bit aligned. Building nrv2e_d8 with the eabi toolchain breaks this assumption
17:05:13CIA-5New commit by 03kugel (r25072): Make it easier to change the toolchain in the dualboot Makefile.
17:05:18amiconn-> You can keep using 512 byte sectors and everything works
17:05:19TorneTheSeven: I guess, if I'm right :)
17:05:47amiconnThe only hackish thing that still remains is the method to find the partition (in disk.c)
17:06:27Tornethe code in fat_getnext wants to be able to read the whole LFN so it needs to have enough for the 672-byte entry to span the maximum number of sectors, but when you're reading the entries in order you can only ever need to go forwards
17:06:45Torneeither the last sector you read into the cache contains the next entry, or no sector in the cache does, surely
17:07:03 Quit merbanan (Ping timeout: 260 seconds)
17:07:15amiconnIirc the longname entries are stored in reverse order
17:08:09Torneyes
17:08:17TheSevenwhich is even better, as we'll know the size of them when reading the first one
17:08:19Torneit's the lfn entries in reverse order, then the 8.3 entry
17:08:24kugelany idea what "warning: section `.bss' type changed to PROGBITS" means?
17:08:51Torneamiconn: but the entries for a given file are always contiguous
17:09:02amiconnYes, they have to
17:09:12Torneamiconn: so to read the next entry you at most need to start from the entry after the last file
17:09:25Torneand thus you won't ever re-use the data in the first two sectors of the cache.
17:10:06TheSevenkugel: yes, it means that the bss will be included in the output file, for whatever reason
17:10:19amiconnYou first need to find the shortname entry, then go backwards
17:10:52 Join kugel_ [0] (~kugel@e178065160.adsl.alicedsl.de)
17:10:53Torneamiconn: yes, and?
17:11:03 Quit kugel (Disconnected by services)
17:11:05Tornei'm not saying you need less memory total *in fat_getnext*
17:11:06 Nick kugel_ is now known as kugel (~kugel@e178065160.adsl.alicedsl.de)
17:11:08amiconnYou will need up to two sectors before the one containing the shortname
17:11:08Tornejust over the whole system
17:11:11 Quit kugel (Changing host)
17:11:11 Join kugel [0] (~kugel@rockbox/developer/kugel)
17:11:19Tornefat_getnext needs to have 672+change bytes of data
17:11:27Tornebut you don't need to keep all of it between invocations
17:11:27amiconn(with 512 byte sectors)
17:11:29TheSevenamiconn: actually, can't we just keep a 672 byte buffer, read the sectors and copy everything belonging to the lfn into that buffer, and then doing the further work on that lfn buffer instead of the raw sector buffer?
17:11:51Torneamiconn: My point is you can make do with one sector of cache per dir, no matter the sector size
17:12:05Torneamiconn: and one global buffer big enough for the extra sectors you need while inside fat_getnext
17:12:11Tornewhich is less memory overall
17:12:12amiconnI didn't write this code - it's mostly LinusN's work it seems
17:12:26Tornei wasn't asserting you did :)
17:12:38Torneit's slightly more complicated to do it that way, maybe
17:12:43Tornebut maybe not really
17:12:54amiconnYou'll hit the disk quite a bit more often with that scheme, if there's more than one dir open
17:13:08Tornei don't see how..
17:13:16 Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.0.1)
17:13:29Tornewhen you go into fat_getnext you start by looking at the one-sector cache for that dir
17:13:35Torneif that's not enough you read one or two more sectors into the lgobal buffer
17:13:46Tornewhen you are done you memcpy() the last sector into the cache
17:13:56Torneit does the memcpy() anyway
17:14:08amiconnIf you have one global buffer, and then two threads read one dir each, the global buffer contents would have to go back & forth between the two dirs
17:14:26Tornehm? no, the global buffer only ever sees new sectors
17:14:33Torneyou never re-read the same sectors unless you restart iterating over the dir
17:14:33 Quit S_a_i_n_t (Ping timeout: 246 seconds)
17:14:38Torneexactly the same as now
17:15:29*amiconn somehow can't follow
17:15:45Torneonly the first sector of the *current* cache is reused between calls, ever
17:15:59Torneat the end of fat_getnext() it memcpy's the sector it read up to over th ebeginning
17:16:18TheSevenTorne: it can be further optimized to one sector per dir and 640 bytes globally
17:16:36amiconnhmm
17:16:54 Join chrisb [0] (~chrisb@pool-98-111-153-193.phlapa.east.verizon.net)
17:17:19 Quit kugel (Ping timeout: 260 seconds)
17:17:35chrisbfrom ffmpeg's perspective, is ogg basically just flac now?
17:17:53TheSevenyou'd just read the dir sequentially using as single sector buffer (which won't cause more disk reads), and if you hit lfn stuff, just copy it into the 640 byte buffer until you hit the short entry, and then use the 64 byte buffer to analyze the rest of the entry
17:18:04amiconnI wonder why dir_uncached.c needs another fat_dir structure for the parent dir
17:18:28chrisbffmpeg -i <file.flv> -vn -ac 2 -ar 44100 filename.ogg gives a flac file in an ogg container
17:21:01*amiconn also wonders whether a global lru sector buffer for both dir and file access would be better
17:21:16amiconnThis could then be tuned for lowmem and bigmem targets independently
17:22:11TheSevenlru? you mean mru?
17:22:40 Join kugel [0] (~kugel@e178080201.adsl.alicedsl.de)
17:22:41 Quit kugel (Changing host)
17:22:41 Join kugel [0] (~kugel@rockbox/developer/kugel)
17:23:00kugelTheSeven: it seems there's a bit of initialized data in it (e.g. current_tick = 0). .ibss is causing it
17:23:02TheSevenwell, that way we could get rid of everything besides one sector buffer and one 640 byte buffer on lowmem
17:23:10kugelif I move .ibss to .data it doesn't show the warning
17:23:33TheSevenisn't there .idata or something for that purpose?
17:25:47amiconnTorne: Hmm, one global buffer won't work in a multithreaded environment, even with cooperative threading, as used in rockbox
17:26:05TheSevenwhy not?
17:26:18TheSeventhere must be locking for the mru buffer of course
17:26:20amiconnWhat if two threads are reading dirs at the same time?
17:26:32amiconnDisk access yields on many targets
17:26:54TheSeventhe other threads wanting to read will be blocked
17:27:05amiconnYes, a global mru cache would need locking
17:27:24TheSevenand yes, this *will* cause thrashing, but well, it's a speed vs. memory tradeoff
17:27:28amiconnThis could be done per entry, so other threads would not need to be blocked
17:28:03amiconnBut even the current scheme can be improved. Instead of using 3 sector buffers per dir, just use one plus a 640 byte buffer
17:28:32linuxstbchrisb: This is #rockbox... ;)
17:28:44TheSevenhow many of those dir structs are there usually?
17:28:58TheSeventhis means a 3.4K mem gain for *each* of them on nano2g
17:28:59 Quit kugel (Ping timeout: 260 seconds)
17:30:21amiconnMAX_OPEN_DIRS ones, with is either 8 or 12
17:30:42amiconnOh, and each has *two* fat_dir entries
17:31:13amiconnFor the dir itself and its parent, which I'm not sure why it's necessary
17:31:25 Join Omlet [0] (omlet05@162.154-200-80.adsl-dyn.isp.belgacom.be)
17:31:49 Join kugel [0] (~kugel@rockbox/developer/kugel)
17:31:58kugelTheSeven: yes
17:32:17pamauryamiconn: dir_uncached.c needs it to update the entry when metadata change but in reality it's not strictly needed. I thought I commit to change this, perhaps I forgot
17:32:25pamauryOr perhaps I ran into a problem doing this
17:34:11pamauryOh no sorry, this is the only in file.c, the I don't see why parent_dir is needed :)
17:35:02 Join jgarvey [0] (~jgarvey@cpe-065-190-069-073.nc.res.rr.com)
17:36:07TheSevenso this would be an *80K ramsize gain!*
17:36:21pamauryAh yes, I remember. It's needed because fat_opendir needs the parent_dir and the output fat_dir but in reality this is overkill, there is too much information, it could probably be improved
17:36:24Torneok, so i am at least partly right? :)
17:36:33Tornesorry, had to step out ;)
17:36:48pamaurylet me check if I fixed that in one of my numerous branch :)
17:36:50 Join kugel_ [0] (~kugel@e178100011.adsl.alicedsl.de)
17:36:55 Quit kugel (Ping timeout: 260 seconds)
17:37:04 Nick kugel_ is now known as kugel (~kugel@e178100011.adsl.alicedsl.de)
17:37:09 Quit kugel (Changing host)
17:37:09 Join kugel [0] (~kugel@rockbox/developer/kugel)
17:37:20chrisblinuxstb: where should i ask?
17:37:24kugelTheSeven: yes
17:37:53TheSevenchrisb: if you just want to rant about it: #rockbox-community, or if you want real help, maybe #ffmpeg or something
17:38:22chrisbthanks
17:38:56pamauryhum, no. You're right to raise the problem, normally the "hack" I used in dircache:sab_process_dir should apply. I'll have a look
17:39:25 Join bmbl [0] (~Miranda@unaffiliated/bmbl)
17:39:45Torneamiconn: anyway, yeah, i did think we really shouldn't need that many sector sized buffers ;)
17:40:13*TheSeven would still like to figure out where the ones on the stack are coming from
17:43:06*amiconn needs to find out why a sim build on opensolaris produces a broken make.dep
17:43:23kugelTheSeven: I think I could work around by deactivating iram usage in the bootloader. the sections land in the same memory region anyway as per boot.lds. but I would like to get it right
17:44:15TheSeventhere should be an .idata section that should be handled like .icode, but with a writable flag
17:44:25kugelthere is such a section
17:44:43 Join kh [0] (~89840307@giant.haxx.se)
17:44:52kugelthat' sour boot.lds http://pastie.org/859773
17:45:00TheSevenhm, would it be feasible to enforce that calls to the storage apis *have* to use cacheline-aligned buffers?
17:45:10TorneTheSeven: no
17:45:14TorneTheSeven: well sort of
17:45:22TorneTheSeven: I was looking at doing that but I haven't really gotten far.
17:45:41TorneTheSeven: It's done for buffering now where possible if you define the alignment requirement in the config
17:45:55TorneI didn't get around to making sure the fat/etc buffers are aligned by the mask yet
17:45:57TheSevenok, then I'll use a hack that will use 2K more ramsize and non-cacheline-aligned reads/writes will be *slow*
17:46:17Tornebut yeah i don't think we can ever realistically get to the point where *all* calls are cacheline aligned
17:46:46TheSevenso this would be most important for the USB stuff, which probably needs to have cacheline-aligned buffers anyways for the USB BMA
17:46:48TheSevenDMA*
17:46:52 Quit komputes (Ping timeout: 256 seconds)
17:47:03TornePretty sure the USB buffers are aligned to a very large size
17:47:05Torneway more than 32 bytes
17:47:16Tornethey always use DMA on PP502x, at least
17:47:38gevaertson PP they are aligned to 32 bytes
17:47:41TheSevenTorne: commit a panicf with a stacktrace when they aren't aligned :-P I'm pretty sure they would be gone rather fast (or possibly your commit)
17:47:44Tornehaha
17:47:53TorneTheSeven: well, that was more or less what i was going to do on my local build
17:47:58Torneand go around shoving references to STORAGE_ALIGN in there
17:48:02Torneuntil everything i tried worked.
17:49:01 Join kugel_ [0] (~kugel@e178118040.adsl.alicedsl.de)
17:49:07 Quit kugel (Disconnected by services)
17:49:12amiconnAren't usb buffers aligned to 4K on PP502x?
17:49:14 Nick kugel_ is now known as kugel (~kugel@e178118040.adsl.alicedsl.de)
17:49:19 Quit kugel (Changing host)
17:49:19 Join kugel [0] (~kugel@rockbox/developer/kugel)
17:49:40gevaertsno
17:49:49TorneTheSeven: anyway, yeah, if you want to align more stuff that'd be great, but requiring that it's aligned is probably a nonstarter
17:50:08TorneTheSeven: since that includes every bit of app code which happens to read/write more than a sector
17:50:15TheSeveni'll require it in a way that non-aligned things are 4 times slower
17:50:19kugelTheSeven: boot.lds lacks the NOLOAD directives
17:50:22gevaertsThere's one data structure that's aligned to 4K for the USB controller, but not the data buffers
17:50:22 Quit kh (Quit: CGI:IRC (EOF))
17:50:31kugeladding it seems to help
17:53:03gevaertsAs far as the ARC controller is concerned, you don't actually need to align data at all, but not aligning leads to cache issues
17:54:53pamaurywhich structures should be aligned ?
17:55:46linuxstbTheSeven: Are you planning to incorporate your norloader work into Rockbox, or is it strictly iloader?
17:56:02TheSevenpamaury: everything that gets passed to storage_read and storage_write
17:56:33TheSevenlinuxstb: I'm not entirely sure about that, because it currently depends on quite a lot of non-rockbox stuff
17:56:34Torneif anyone else does do somet alignment stuff, btw, please use STORAGE_ALIGN_MASK :)
17:56:47Torneso that the existing code we did for pp502x can be used
17:57:10gevaertspamaury: as far as the ARC controller is concerned, transfer descriptors need to be 32-byte aligned, and the queue head array has to be 4k aligned
17:57:11Tornebuffering is mostly aligned to that mask already, if you define it, it's just only defined on pp502x
17:57:18TheSevenwe would need to have some well-tested recovery code (i'm currently using ibugger for that), and we need to deal with things like diskmode and diagmode
17:57:29gevaertsoh, 2k actually
17:57:32pamaurygevaerts: yes I know those restrictions
17:57:48TheSeven(or have our own "diskmode" in-flash rockbox, which i wouldn't like right now because USB isn't stable yet)
17:58:23TheSevenand of course nandfsck... which i wouldn't really want to include in rockbox for ramsize reasons (it needs 2MB or something of heap)
17:59:19TheSeventorne: which define do you mean?
17:59:32TheSevenah, spotted it :-)
17:59:54 Quit kugel (Ping timeout: 258 seconds)
18:00
18:00:18TheSevenlinuxstb: i don't really see how we could include norloader into rockbox's design
18:01:11 Quit petur (Quit: work->home)
18:01:18linuxstbTheSeven: Wouldn't it just be a separate application in bootloader/ ? i.e. it would use the Rockbox firmware code and then add stuff itself.
18:02:05linuxstbComplicated stuff could go into firmware/ and then only be used by norloader, and not the main Rockbox build.
18:02:43TheSevenactually, norloader should be standalone and not use things from the rockbox tree for safety reasons, as it's only some basic hardware setup that we won't need to do anywhere else and because of the bricking risk
18:03:00TheSevenyou could compare that to AMS dualboot
18:03:50 Join Omlet05 [0] (~omlet05@221.154-200-80.adsl-dyn.isp.belgacom.be)
18:03:56TheSeven(the norloader binary is actually <4K, plus recovery image and crypto headers = 8,8K)
18:04:20TheSevenand it shouldn't ever need to be changed
18:04:36linuxstbOK, so that's fine then - just a standalone app somewhere.
18:04:47TheSevenyes, like it currently is
18:05:02 Quit Omlet (Ping timeout: 245 seconds)
18:05:04TheSevenwe could possibly make the rockbox bootloader boot from flash, but for that we should add things like allowing to enter disk mode
18:05:27 Join komputes [0] (~komputes@ubuntu/member/komputes)
18:06:11linuxstbTheSeven: Yes, but it's not in Rockbox SVN, or documented in the Rockbox wiki. I guess that was my original question.
18:07:12TheSeventhen there's the question of a sane installation process for whatever solution you prefer
18:08:10TheSeveni've written a standalone installer for norloader/iloader/whatever else you want, which is quite flexible (you can also make it do things like creating other files in the file system - actually it could install a full rockbox)
18:08:42 Join kugel [0] (~kugel@rockbox/developer/kugel)
18:08:50kugelmc2739: sent
18:09:10TheSevenwe couldn't implement that functionality as a rockbox plugin, but we could of course go for some easier solution that just flashes an image to the nor
18:09:36linuxstbWhy couldn't that be a plugin?
18:09:48TheSevenbecause of it's size
18:10:07 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky)
18:10:22linuxstbThe size of what?
18:10:23TheSevenit needs about 16MB of malloc space for libucl
18:10:32linuxstbThat's fine.
18:10:49kugelno problem unless you want music playing while it's running :)
18:10:53linuxstbPlugins can grab the 28MB or so audio buffer.
18:11:18TheSevenactually we could also decide to not compress the images at all - which could still fit into the flash, depending on what we want to do with it
18:11:38TheSevenand honestly, the iloader-installer is just overkill for the application you're thinking of
18:11:43 Quit pamaury (Quit: Quitte)
18:12:23TheSevenit's for advanced users that want to get the absolute maximum out of their ipods, both in terms of space and functionality
18:12:29kugelhaha, something is strange with the bootloaders and eabi
18:12:35TheSeven(and who are comfortable with some data loss risk)
18:12:47kugelit just wanted to create a 788597788 bytes bootloader.bin
18:12:55 Join Omlet [0] (omlet05@191.150-242-81.adsl-dyn.isp.belgacom.be)
18:13:04TheSevenwhich target?
18:13:10kugele200v1 this time
18:13:32TheSevencould it be possible that it's IRAM is at 0x2f00xxxx or 0x2f01xxxx?
18:14:35 Quit GeekShadow (Read error: Connection reset by peer)
18:14:57kugelcould be :)
18:15:00TheSevenif you "just" want to install a rockbox bootloader into the nor and keep the firmware partition, a more trivial solution can be found
18:15:26 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean)
18:15:27 Quit Omlet05 (Ping timeout: 246 seconds)
18:16:11TheSevenkugel: did you get what i mean?
18:16:21kugelyes :)
18:16:44linuxstbTheSeven: I think I'm still a bit confused - there seems to be lots of ways to do this... Maybe we would just want to support the two extremes - i.e. the current method of installation, and a "wipe all Apple code completely and remove the firmware partition" method for people that only want to use Rockbox.
18:16:58kugelNOLOAD helps here as well
18:17:24 Quit kugel (Read error: Connection reset by peer)
18:17:54TheSevenlinuxstb: that would still be 3 options: rockbox bootloader via firmware partition, rockbox bootloader via nor, and iloader via nor
18:18:32TheSeveniloader's advantage is the configurable menu, for people that like it
18:18:57amiconnTorne: Actually you could even reduce the lfn buffer to 512 bytes if you pre-decode the entries
18:19:05TheSeven(and it doesn't lose the OF either)
18:19:31TheSeventhe rockbox via nor way could also wipe all the apple stuff completely, or try to be compatible
18:19:33 Join kugel [0] (~kugel@rockbox/developer/kugel)
18:19:45TheSevenbut honestly I don't see any advantages of the rockbox bootloader over iloader
18:19:53 Join Omlet05 [0] (omlet05@157.99-240-81.adsl-dyn.isp.belgacom.be)
18:20:34kugelis there a reason the boot.lds files don't have NOLOAD for bss/stack? other than historical reasons of course :)
18:21:12linuxstbWell, "Rockbox" as a project never supports third-party bootloaders. So you should make the rockbox bootloader do what iloader can do. As long as it can be configured (and I would argue by default) to boot straight into Rockbox, I would be happy with a configurable bootloader.
18:21:36TheSevenlinuxstb: other people aren't, for whatever reason
18:22:29linuxstbTheSeven: Let them speak up then...
18:22:34 Quit Omlet (Ping timeout: 256 seconds)
18:22:51gevaertsSpeaking of bootloaders, why is there a mini2440 rockbox bootloader at all?
18:22:59TheSevenactually, i'm not even sure if I want the "rockbox project" to support that, as it probably will always be a highly-experimental bleeding-ede thing
18:23:19TheSevengevaerts: because "Rockbox" as a project never supports third-party bootloaders, be it u-boot or not :-P
18:23:33TheSevenbleeding-edge, even
18:23:53gevaertsTheSeven: u-boot comes factory-installed, and rockbox does work with various factory-flashed bootloaders :)
18:24:40TorneBeing able to support booting with u-boot is probably useful, tbh :)
18:25:04TheSevenis there even a way to not support that? :-P
18:25:16TorneTheSeven: Sure..
18:25:34Torneu-boot doens't promise to load you anywhere in particular, for a start
18:25:49TheSevenyou can tell it to do it, though
18:25:52 Join einhirn [0] (~Miranda@p5485A43E.dip0.t-ipconnect.de)
18:26:07Torneno, you can tell the user to do it
18:26:14TheSevenor the config file ;-)
18:26:21Torne..confwhat? :)
18:26:42*TheSeven is confused
18:26:52Torneu-boot doesn't have a config file
18:27:07TheSevenit does on the beagle board at least
18:27:23TheSevenlinuxstb: the question is whether we need the norloader => rb bootloader option, i.e. if anyone would want to use that
18:27:24Torneit doesn't on the vast majority of targets
18:27:35Torneits environment is stored in binary in flash
18:27:36TheSeventhen fix it :-)
18:27:44Torneon many targets it doesn't have *filesystem* support
18:27:56Tornemost copies of u-boot can't access anything but flash/serial/ethernet
18:28:04TheSevenwell, then tell the environment to load rockbox at a certain address
18:28:19Torneyes, my point is that's the user's job
18:28:20Torneyou can't do it
18:28:45Torneif you want to support being loaded by u-boot in the general case you need to behave like linux kernels do ;)
18:28:51TheSevenwell, it's also the users job to copy rockbox into the flash...
18:29:12TheSevenso that's just one additional command to setup the environment accordingly
18:29:30TheSevenit's also a matter of copy'n'paste, so...
18:29:39Torneer
18:29:43*gevaerts 's main point is that he thinks that an installation procedure that starts with "remove u-boot" is silly
18:29:45 Join Omlet [0] (omlet05@19.105-244-81.adsl-dyn.isp.belgacom.be)
18:29:45Tornebut linux doesn't generally need any config at all
18:29:57Torneat least not on systems with a filesystem
18:30:01Torneyou drop uImage on the card, it boots it
18:30:25TheSevenyes, but on those systems you should also be able to drop a uboot config on the card
18:30:36Torneno
18:30:40Tornethat's not automatic, sorry :)
18:30:49Tornei don't know if the config file thing is even in mainline
18:30:53Tornenot last time i checked
18:30:56*TheSeven considers uboot stupid then => thus it will need to be removed :-P
18:31:00Tornei think that is a beagle-specific hack
18:31:28Tornethe default place to load linux to on ARM is, er, 64kb fro mthe bottom of ram?
18:31:30Tornemaybe 128kb? i forget
18:31:32TheSevenwhat about making a uImage that removes uboot and replaces it with somethign sane? :-P
18:31:42Torneto make room for the atags to be at start of ram plus 0x200
18:31:46gevaertsSpeaking of beagles, has nobody ported rockbox to them yet?
18:31:56Tornegevaerts: i pondered doing an omap3 port
18:32:03Tornebut haven't seen a particular motivation to care
18:32:13Tornei don't have a beagle but i have other omap3 devices which are baiscally identical
18:32:37TheSevenhm, it doesn't fit well to that board, no proper means of input and the like
18:32:47 Quit Omlet05 (Ping timeout: 264 seconds)
18:32:52Torneit doesn't fit well to mini2440 either :)
18:32:56TheSevenjust a single button, and of course usb host to support a usb keyboard
18:33:05TheSeventhe mini has a touchscreen at least, and several user buttons
18:33:06Tornebut pandora, perhaps
18:33:12Tornewhich is another omap3.
18:33:24Torneor the overo, for people who desperately want to make their own mp3 player
18:33:31 Join JdGordon [0] (~18168145@gateway/web/freenode/x-ovaiklpdgkjwshjt)
18:33:33gevaertsn900? You'd need a phone stack for people not to complain though
18:33:34Tornethe overo on a pinto-th breakout is small enough to make a pocket flash player :)
18:34:05Tornei am still not entirely sure why casainho is using mini2440 and not something much smaller :)
18:34:30TheSevenwell, apparently he wants to switch to Cortex M-series now
18:34:36TheSevenM3 IIRC, thumb-only :-/
18:34:40Tornenothing wrong with that
18:34:44TorneM3 should be powerful enough
18:34:50Torneyou will jus thave to fix whatever doesn't compile for thumb2
18:35:05TheSevenand *all* of the asm code
18:35:16Tornewell that too :)
18:35:24Tornethumb2 is not bad though
18:35:35TheSevenand the reason for the M3 is obviously the packaging
18:35:43gevaertsThat's been done four times already, so it is possible :)
18:36:07TheSevenand i'm not sure if those "solderable" packages he likes will have enough pins to satisfy his needs
18:36:14Tornehe probably misses the point that available M3 SoCs probably don't have sufficient caching abilities
18:36:30TorneI dunno the full scope of what there is out there, but most of the ones i know of only have L1 cache in a limited amount
18:36:39TheSevenand I can't really follow why he is going for 2MB of SDRAM for price reasons, instead of at least 4MB
18:36:39Torneand thus accessing sdram will be fairly shit
18:37:13 Join Omlet05 [0] (omlet05@203.4-65-87.adsl-dyn.isp.belgacom.be)
18:37:37Tornebut yeah, the pandora is a vague possibility
18:37:57Torneif we had a decent port to that we *might* be able to go for 100+hr battery life, too
18:38:02Tornewhich might impress people ;)
18:38:49Tornewe might want to redo all the codecs to use NEON tho ;)
18:39:00JdGordonnope, our support still sucks enough that 100hr batt life wont change peoples minds
18:39:10TorneJdGordon: hehe
18:39:22Tornethe pandora's battery is just *massive* compared to the power consumption o fthe omap
18:39:36 Quit Omlet (Read error: Connection reset by peer)
18:39:42Torneadvantage of being a relatively large handheld, i guess
18:39:50Torneanyway time i went.
18:40:19TheSevenhow much capacity does it have btw?
18:44:53 Quit Omlet05 (Ping timeout: 276 seconds)
18:49:08CIA-5New commit by 03kugel (r25073): Correct search&replace error.
18:51:16*domonoky sees gevaerts complaining about the mini2440 install. if you dont like it, improve it ! :-)
18:51:31JdGordongevaerts: oh you got one?
18:51:47gevaertsdomonoky: I'm not complaining! I'm just questioning the sanity of whoever designed it! ;)
18:51:57gevaertsJdGordon: no
18:52:09 Join Omlet [0] (omlet05@241.164-244-81.adsl-dyn.isp.belgacom.be)
18:52:12TheSevenwe like to moan about things we don't use ;-)
18:52:25JdGordonrighto :)
18:52:42domonokygevaerts: :-) it probably was just the easiest way. using the bootloader to get the initial drivers working is easier, then a full build.
18:53:24TheSevenactually, this is a *devboard*, not a supported target...
18:53:53gevaertsdomonoky: well yes, but throwing u-boot out removes a lot of flexibility. It's perfectly possible to use a "bootloader" as a minimal bootstrap port and never use it to actually load boots
18:54:15kugelmy invitation for my proposal on the dev ml is still valid :)
18:54:36kugelZagor: if we switch, how would updating the build clients work?
18:54:37domonokygevaerts: you dont need u-boot on the mini2440. just flip a switch and boot linux/windows or something else from flash.
18:55:31domonokyand i think doesnt even come with u-boot, but some different bootloader thingy which needs serial + usb to operate with :-)
18:55:48kugelideally it should be trivial to restore uboot as well, using the tools on the shipped dvd
18:56:10domonokyon mini2440 rockbox is on sdcard. the nand flash is untouched and still able to boot the preinstalled linux.
18:56:12gevaertskugel: some build clients should have the eabi toolchain before the switch, after that it's just a different toolchain that's tested for by the server
18:56:21kugeldomonoky: yes. do we actually remove uboot? wasn't it supervivi?
18:56:40JdGordonyes, supervivi
18:56:42kugelgevaerts: but do we want a new target, or reuse the existing arm one?
18:56:45JdGordonwhich is important to keep :p
18:56:50domonokysupervivi is the name, that lives in nor, and gets overwritten by our bootloader
18:56:51gevaertsAs far as the build system is concerned, you don't have to switch all targets at the same time
18:58:04gevaertskugel: hm, if we reuse the existing one we might have interesting issues, but changing target names every time we update a compiler also doesn't sound like a good idea
18:58:24***Saving seen data "./dancer.seen"
18:58:37kugelwell, we could add a version number so it's a bit less ugly :)
18:58:55gevaertsYes, maybe we should do somethin like that
18:59:23TheSevenhm, before we switch to eabi, mr. someone should finally go after that stupid yellow!
19:00
19:00:43 Join Seed [0] (~ben@bzq-84-108-232-45.cablep.bezeqint.net)
19:01:15 Join shai_ [0] (~Shai@l192-117-110-233.cable.actcom.net.il)
19:02:36kugelr25071 was an interesting revision for the c200v2 :)
19:04:12 Quit shai (Ping timeout: 245 seconds)
19:14:33 Join arbingordon [0] (~w@c-71-226-248-30.hsd1.pa.comcast.net)
19:15:09 Quit Omlet (Ping timeout: 245 seconds)
19:19:10 Join Omlet [0] (omlet05@198.3-65-87.adsl-dyn.isp.belgacom.be)
19:21:55 Quit arbingordon (Quit: `)
19:24:01 Quit DerPapst (Quit: Leaving.)
19:24:18 Join pamaury [0] (~c2c7a50a@gateway/web/freenode/x-uvogbzafnafatpea)
19:26:18 Join Horscht [0] (~Horscht2@xbmc/user/horscht)
19:27:16 Quit anewuser ()
19:27:37 Quit CGL (Ping timeout: 240 seconds)
19:29:17 Nick shai_ is now known as shai (~Shai@l192-117-110-233.cable.actcom.net.il)
19:30:15 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
19:32:43 Quit einhirn (Read error: Connection reset by peer)
19:34:30 Join gill0r [0] (~gill0r@f050132026.adsl.alicedsl.de)
19:37:00 Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net)
19:38:55Lloreankugel: Some iRivers do run ARM cpus.
19:39:11LloreanThe H10 is PortalPlayer based.
19:39:56 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl)
19:40:47kugelLlorean: yes, I forgot about this one sorry. but IIRC know alex wallis has h100 so I assumed he meant that one
19:41:44LloreanYeah, but it's better not to post statements like "they don't run ARM cpus" when someone just asks about "iRivers". It leaves misleading information in the archives.
19:42:29LloreanAnyone looking through the archives for information may not know he's most likely asking about an H100.
19:43:47kugelas I said, I completely forgot about the h10
19:44:34 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de)
19:50:33pixelmadomonoky, bluebroth3r: got the rbspeexenc and dec now, what should I do with them now?
19:51:02 Join DerPapst [0] (~DerPapst@p4FE8EBD6.dip.t-dialin.net)
19:51:54domonokytry to encode and then decode again on one of the generated wav files, and see it had the problem too
19:52:44domonokypixelma: did you try to generate talk files with filte/espeak/etc on these macs ?
19:53:39 Quit jd (Read error: Connection reset by peer)
19:53:55 Join jd [0] (~jd@modemcable207.134-202-24.mc.videotron.ca)
19:53:56 Quit jd (Changing host)
19:53:56 Join jd [0] (~jd@Wikipedia/HellDragon)
20:00
20:00:20pixelmadomonoky: can you help me a bit on how to use them, I'm a commandline newbie (maybe privately though)? And if I should try Intel MacOS 10.4 first I got to switch computers and join through a webclient...
20:00:59 Join funman [0] (~fun@rockbox/developer/funman)
20:03:01domonokylets start with pp :-)
20:03:53Zagorkugel: that's a good question. the distributed build system doesn't manage the compilers, so we somehow need to make everyone upgrade manually.
20:04:09pixelmadomonoky: well, I got no intermediate files from there but I could try with the others (or some other wav)
20:04:31pixelmatalk generation hangs completely there...
20:04:49 Join stoffel [0] (~quassel@p57B4C7BB.dip.t-dialin.net)
20:04:51pixelmahmm... reminds me to also try espeak or so
20:06:29domonokyrbspeexdec just takes the in and output filenames as parameters. rbspeexenc should work with just input and outputfilename too (using default options).
20:07:19domonokylets try with some different wav files, and see what works. Just remember which result used which wav file :-)
20:08:36 Join petur [0] (~peter@d54C6F9B2.access.telenet.be)
20:08:37 Quit petur (Changing host)
20:08:37 Join petur [0] (~peter@rockbox/developer/petur)
20:08:48domonokya quick test with espeak or similar would be also good. if it works, we know that rbspeex is fine, and you dont need to test it :-)
20:12:41pixelmaI need to find an espeak binary for 10.4 (PPC) first :\
20:12:59pixelmaor flite
20:13:43 Join flydutch [0] (~flydutch@host83-164-dynamic.15-87-r.retail.telecomitalia.it)
20:14:41 Quit stoffel (Remote host closed the connection)
20:18:11domonokyespeak provides mac 10.4 binarys. if you are lucky they are built universally.
20:18:44Zagoran easy fix is to update rbclient to check the gcc version
20:19:01pixelmadomonoky: didn't find a binary yet
20:19:17domonokyhttp://espeak.sourceforge.net/download.html ?
20:21:09Zagorbtw, emdebian.org builds cross-compiler debs. such as: http://www.emdebian.org/toolchains/search.php?package=gcc-4.4-arm-linux-gnueabi&arch=&distro=sid
20:21:45Zagortheir binutils is version "2.20-5" though. I don't know if that includes the fixes from 2.20.1.
20:22:38 Join tvelocity [0] (~tony@weg38-1-82-237-37-150.fbx.proxad.net)
20:23:34 Quit ecio (Quit: Leaving)
20:25:14 Join anewuser [0] (anewuser@unaffiliated/anewuser)
20:25:21funmanpacakges.debian.org usually give the patches applied (on the right of the page), but I don't see it on your link
20:27:06Zagoremdebian.org != debian.org
20:28:10Zagorwell, it's part of debian but they don't have the same full web system
20:40:24kugelbecause their webserver is an embedded system! ;)
20:41:55JdGordonemdebian is annoying :/ .. it doent just work
20:46:57 Quit tvelocity (Read error: Operation timed out)
20:47:02 Join moos [0] (moos@rockbox/staff/moos)
20:50:02 Quit pamaury (Ping timeout: 252 seconds)
20:50:11 Quit n17ikh (Ping timeout: 260 seconds)
20:52:40 Join MaadMan [0] (~MaadMan@188-194-48-219-dynip.superkabel.de)
20:56:44 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com)
20:57:30 Join Tomis [0] (~Tomis@70.134.101.40)
20:58:27***Saving seen data "./dancer.seen"
21:00
21:05:35chrisbhow long should a first install take? 1 minute, 5 minutes, 15 minutes? target is sansa e200
21:06:56 Quit amiconn (Disconnected by services)
21:06:57 Join amiconn_ [0] (quassel@rockbox/developer/amiconn)
21:07:00 Quit pixelma (Disconnected by services)
21:07:01 Join pixelma_ [0] (quassel@rockbox/staff/pixelma)
21:07:15 Quit MaadMan (Quit: Verlassend)
21:07:18 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma)
21:07:24 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn)
21:07:42 Join MaadMan [0] (~MaadMan@188-194-48-219-dynip.superkabel.de)
21:08:33Zagorchrisb: a minute tops
21:09:27 Join DataGhost [0] (~dataghost@unaffiliated/dataghost)
21:09:58LloreanZagor: Unless your download is really, really slow.
21:10:21Lloreanchrisb: But the installation part should be very quick, it's just unzipping and copying a couple megs of files pretty much
21:12:48 Quit Tomis (Ping timeout: 248 seconds)
21:14:28 Join Buschel [0] (~ab@p54A3BBBC.dip.t-dialin.net)
21:16:32 Join Tomis [0] (~Tomis@70.134.80.2)
21:28:17 Join Lear [0] (chatzilla@rockbox/developer/lear)
21:29:02LearBushel: You've noticed that ReplayGain for MPC doesn't show up in the track info screen?
21:29:36LearI have a fix for that...
21:29:44Buschelfix it :o)
21:30:01Buscheland: no, i haven't noticed
21:30:27LearOk, will apply it later (haven't tested it yet).
21:30:43Buschelcan you post the patch somewhere?
21:31:48LearSure (I can commit it myself though).
21:32:04pixelmaaha, bluebroth3r: rbspeexenc is at least executed on the 10.5 Mac
21:32:09kugellooks like nobody is against the gcc update, so I suggest we start asking the build clients to get eabi toolchains ready so that we can switch over in a few days or week
21:32:32pixelmasame file I tested on the 10.4 Intel Mac
21:32:33 Join p3tur [0] (~petur@rockbox/developer/petur)
21:32:37bluebroth3rpixelma: nice. A ! in the folder name shouldn't matter but not really sure about this.
21:33:10LearBuschel: http://pastie.org/860155
21:33:44pixelmabluebroth3r: well, if it works on 10.5 then I assume it's fine. So it looks like you still have a non-working crosscompiled binary
21:34:10pixelmaIIUC... going to try the PPC too once more
21:34:33BuschelLear: hmm, just checked. it shows. but only, if present...
21:34:42BuschelLear: with svn that is
21:35:39linuxstbbluebroth3r: Are you able to compile rbspeex* on ppc? Can you add a #warning into the endian-ness check in apps/codecs/libspeex/speex_header.c ? (around line 52)
21:35:46linuxstb(unless you've already checked that...)
21:37:05LearBuschel: Didn't show for me (on target). But the patch is silly. I'd forgotten what parse_replaygain_int did. It was a couple of years ago, so... :)
21:37:16pixelmathe files I test are crosscompiled on a later OSX (and Intel) so it could all come from that fact
21:38:00bluebroth3rlinuxstb: haven't checked that, will try
21:38:10LearThe files in question have ReplayGain, according to Foobar though.
21:38:11 Join karashata [0] (~karashata@74-220-162-11.wightman.ca)
21:38:17BuschelLear: just checked a file (that definately has replay gain data) on pc sim. this works fine.
21:39:20 Join planetbeing__ [0] (~planetbei@166.134.250.66)
21:39:32 Quit planetbeing (Read error: Connection reset by peer)
21:39:35 Nick planetbeing__ is now known as planetbeing (~planetbei@166.134.250.66)
21:40:49 Join planetbeing__ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net)
21:41:18bertrikI'll update my build client to advertise eabi build capability
21:41:29bluebroth3rlinuxstb: my #warning gets hit (directly after the #elif line) when building for ppc
21:41:47chrisbZagor: thanks
21:42:06chrisbLlorean: thanks
21:43:10 Quit planetbeing_ (Ping timeout: 252 seconds)
21:47:18 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk)
21:48:30 Join froggyman [0] (~sopgenort@pool-72-69-220-42.chi01.dsl-w.verizon.net)
21:50:25*chrisb realizes he was doing the complete install with extras, etc.
21:50:51bertrikwhat should I put in the archlist parameter to advertise arm-elf-eabi build capability?
21:51:08moosLear; Buschel: I remenber to have encountred this "no replaygain info" on the tag browser bug on the past. But that was few years ago too :) IIRC rockbox didn't like much mixed ape+id3 tags for mpcs
21:52:25funmanbertrik: i think Zagor said earlier that the buildsystem doesn't recognize different gcc versions. I don't know if the buildsystem has a way to append −−eabi to configure arguments though
21:53:17Zagorthe system doesn't support alternative compilers, or options, for each target
21:54:29Buschelmoos: the current implementation jsut checks the mpc header itself. mpc has generic replay gain support...
21:56:45moosBuschel: this was ages ago (rockbow wise). You didn't meet rockbox yet, then ther was few bugs and messes you fixed since (plus all the cool optimisations you made since too :)
21:57:33 Join Stephen__ [0] (~S@86.45.50.221)
21:59:27moosif the tag contained apev2 info and id3 infos, that caused tag reading problems. This time I did fixed my tags for the musepack albums I have :) And that was preglow that was working on this front this time
21:59:40moosdon't tried since
22:00
22:00:34BuschelLear reports this bug on a sv8 file with a replay gain tag. i will need to debug this... my (single) tagged sv8 file works fine
22:01:34linuxstbTo "go live" with eabi, could we simply change ARG_ARM_EABI in tools/configure to default to 1?
22:01:41*moos bets that Lear will find/fix himself :)
22:02:43kugellinuxstb: basically, yes
22:02:48*Buschel just recognizes he already has 3 sv8 with working replay gain tags
22:02:52*linuxstb wonders why those ARG_* variables are defaulted to the empty string, and not 0 (for the 1/0 options)
22:03:49 Join Tomis2 [0] (~Tomis@70.134.100.226)
22:04:20kugelthe PP bootloader need some changes which are safe AFAICS. the stack/bss sections aren't marked with NOLOAD, and the new ld wants to put those into the binary for that reason
22:04:52moosBuschel: could be particular circumstences, let's him find himself, since he seems to have the culprit file :)
22:05:27 Quit Tomis (Ping timeout: 245 seconds)
22:05:27 Nick Tomis2 is now known as Tomis (~Tomis@70.134.100.226)
22:06:48funmanhas there been reports of filesystem corruption on e200v1/c200v1 these days ?
22:07:01 Join JdGordon1 [0] (~jonno@c-71-231-54-21.hsd1.wa.comcast.net)
22:07:26SeedBuschel: hi
22:07:46 Quit JdGordon (Ping timeout: 252 seconds)
22:08:27BuschelSeed: hi :o)
22:08:47 Quit mikroflops (Ping timeout: 264 seconds)
22:09:31 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com)
22:09:35JdGordon1anyone getting lots of data aborts recently?
22:09:44linuxstbkugel: Why "basically" ?
22:10:22kugelnothing verifies if the compiler is really eabi-capable. that's all
22:10:52kugelbut it throws the usual warning if the compiler is not gcc 4.4.3, so I don't think that's a problem
22:11:36saratogafunman: not in a very long while that I've seen
22:11:38linuxstbkugel: But doesn't the compiler have the name arm-elf-eabi-gcc ?
22:12:07saratogastripwax: seen my email about back porting the new mdct to Tremor?
22:13:08stripwaxsaratoga - not yet, but that's just down to busy-ness. let me go take a look..
22:13:45stripwaxoh, I did see a mail where you said something like 'stripwax and I need to figure out what's up with the bitrev' - but that didn't actually mean a whole lot to me :)
22:13:53saratogastripwax: basically we have permission from Lorenm (the split-radix ffmpeg porter) to relicense his code as BSD
22:14:20saratogaAFAIK once the bitrev stuff is figured out we can simply remove the init code for computing the bitrev table and then the entire mdct will be BSD licensed
22:14:22stripwaxok cool
22:14:31saratogai tried truncating the bitrev table but it did not work
22:14:40saratogai thought you had some idea how to do that correctly?
22:14:54funmansaratoga: i noticed sd_read_sectors() doesn't switch banks properly when a read request overlap on 2 banks
22:15:01 Quit JdGordon1 (Ping timeout: 276 seconds)
22:15:15stripwaxso as long as the bitrev table is big enough then we're good to go .. and it's currently statically created so not sure what's left to do .. ?
22:15:27stripwaxi.e. I thought we had no more init code
22:15:36saratogawell ideally i wanted to get it to the right size before we removed the init code (currently ifdef'ed out)
22:15:42saratogabut i suppose thats not really necessary
22:16:07saratogafunman: well I haven't heard any complaint but i suppose the occasional audio file ending up with a garbled bit in the middle might never be reported
22:16:30stripwaxif you want to half the size of the table, you need to right shift every element by one bit; etc
22:16:38kugellinuxstb: yes, configure forces the prefix to be "arm-elf-eabi-", so I guess it's not a problem at all
22:17:30kugelfunman: I saw this too recently. but it's been like that for ages I believe
22:17:32saratogastripwax: also since you wrote so much of the code, would you mind comparing the few bits that aren't written by us or Tremor to ffmpeg's logs and be sure that they're Loren's?
22:17:32funmansaratoga: sd_write_sectors() should be affected in the same way
22:17:33saratogahttp://git.ffmpeg.org/?p=ffmpeg;a=history;f=libavcodec/mdct.c;h=87908d3d667a35dbb74ff0189682e28e1c7f1320;hb=HEAD
22:17:40saratogahttp://git.ffmpeg.org/?p=ffmpeg;a=history;f=libavcodec/fft.c;h=facc6e05d968b2f44c398ab7afdb0b97c5b6196a;hb=HEAD
22:17:46saratogashouldn't take more then a few minutes
22:17:56saratogai listed everythign I could find in the email but a second pair of eyes would be nice
22:18:03kugelfunman: there have been reports in the past, but not anymore since some other fixes in that are
22:18:06kugelarea
22:18:06saratogalast thing I want is to overlook a few lines of LGPL'ed code
22:19:10funmankugel: iirc those fixes were related to usb ?
22:19:22saratogathere were ones for the SD driver, mostly concerning delays
22:19:30funmansaratoga: LGPL code in rockbox would be ok ?
22:19:31kugelno, the problems were exposed by usb. but the problem was in the storage driver
22:19:36saratogaalso i wonder if the function names need to be changed? its not clear to me if the LGPL covers the name of the functions if the code inside is changed
22:19:49 Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.)
22:20:14funmansaratoga: see recent threads on ffmpeg-devel ML about this problem (it's about variable names mentioned in specifications, but it's the same for function names)
22:20:36saratogafunman: i read those but IMO a function declaration is somewhat longer then a single character variable name
22:20:59funmanfunction prototypes aren't copyrightable IMO
22:21:03saratogai wonder if its worth changing just so that people don't carelessly assume we have relicensed the whole ffmpeg code
22:21:09saratogaok that makes sense
22:21:28funmanit defines the data it operates on, not how it operates
22:22:02saratogaits not even the prototype actually, since we don't use those, just the names
22:22:10saratogaso its even more ok
22:22:54kugelsaratoga: willing to test an eabi bootlaoder on your e200v2?
22:23:03saratogastripwax: anyway if you could take a quick look and let me know if I've missed anything that would be great, then we can remove teh LGPL notices on the code and switch to BSD headers
22:23:20saratogakugel: maybe, i've never actually tried unbricking one
22:23:31saratogamaybe getting someone whos unbricked before to try it would be better
22:23:39kugelok, we can wait for mc2739, he said he was prepared for unbricking
22:24:18saratogai guess maybe putting dual rockbox/GPL and BSD headers would be nicer, that way its clear that its our code but we're letting others use it under bsd if they want
22:24:57kugelis tremor bsd or why do we need bsd?
22:26:07kugelfunman: was there a reason our boot.lds doesn't have NOLOAD for stack/bss or was that due to c&p?
22:27:51stripwaxsaratoga - ok (but a bit confused) - we're talking about just giving the ffmpeg ifft/imdct (under bsd) to upstream Tremor, or also about putting our changes into upstream ffmpeg (latter seems much harder on the face of it and maybe not as desirable)
22:28:51kugelwhy should it be undesirable=
22:29:01funmankugel: c&p (or another shameful reason)
22:29:01 Quit anewuser ()
22:29:21Buschelpixelma: did you encounter any issues when testing your m5 (or x5?) with the new iram config?
22:29:57funmansaratoga: dual BSD/GPL licensing ? I would just put BSD licensing with a rockbox ASCII header, but the choice is yours of course
22:30:17stripwaxkugel - ffmpeg has a bunch of flexibility that tremor imdct does not - I don't think we'd want to remove flexibility from upstream ffmepg - but hard to add our changes to upstream ffmpeg without a lot of effort/rewriting I think
22:30:33stripwax^tremor imdct^tremor imdct and rockbox's ffmpeg-derived imdct
22:31:57linuxstbfunman: I would agree. Dual BSD/GPL seems a bit pointless (unless I've missed something...)
22:32:01kugelsaratoga: you can also add that the rockbox header must not be removed if you insist on showing that it is our code :)
22:33:54funmanthen that becomes BSD 3 clauses?
22:34:47 Quit Zagor (Quit: Clint excited)
22:35:36kugelbsd has 4 originally, IIRC
22:37:53kugelstripwax: is that ^ the new s/x/y/? :)
22:38:48pixelmaBuschel: haven't tested my M5 yet
22:39:12stripwaxkugel - yeah
22:39:12Buschelok, give me a sign, if something goes wrong
22:40:40saratogapure BSD with rockbox header also seems fine to me
22:40:52saratogakugel: yes Tremor is BSD to encourage companies to support Vorbis
22:41:24saratogai don't see much point in porting our changes upstream to ffmpeg right now, they have no support for fixed point codecs and some of our changes will be undesirable to them regardless
22:44:33kugelI thought they wanted to maintain 1 fixed point and 1 floating point code path per codec?
22:44:57saratogathey didn't seem very serious about it when we talked to them
22:45:02saratogaso for now I think thats not happening
22:45:27funmankugel: IMO not necessarily, there are fixed-point only codecs in the tree i think
22:47:11kugelat some point someone will make a librbcodec anyway which will beat ffmpeg :)
22:47:30kugelhm, maybe not :)
22:47:51 Quit efyx_ (Remote host closed the connection)
22:48:06Stephen__any theme admins about ?
22:48:14 Quit planetbeing__ (Quit: planetbeing__)
22:48:20kugelStephen__: yes
22:48:51Stephen__can you tell thru checkwps whatsa wrong with the nanos electricbarsofcolour ? theres a user on the forum asking about it
22:49:13kugelnot without compiling it myself
22:49:17S_a_i_n_t_I have a theory on that theme...."its ugly" :P
22:49:32Stephen__I have an idea whats wrong but not sure
22:49:38Stephen__I like that theme :op
22:50:09S_a_i_n_t_<bias>nah...Symmetry is the best Nano theme ever</bias>
22:50:11S_a_i_n_t_:D
22:51:20Stephen__nope not what i thought was wrong anyway
22:52:33pixelmatried removing the 0|0| in the backdrop tag? Not sure if it breaks something but it's at least not necessary
22:52:58Stephen__just noticed my e200 theme of same is broke too.
22:53:13S_a_i_n_t_backdrop shoulldn't have any positioning tags...that could well be it.
22:53:15 Join TMM [0] (~hp@pdpc/supporter/professional/TMM)
22:53:33S_a_i_n_t_*shouldn't even..
22:54:39 Join pamaury [0] (~c2c7a50a@gateway/web/freenode/x-wlaaqorjquxlykkg)
22:54:44Stephen__will check now just about to update my one
22:58:30***Saving seen data "./dancer.seen"
22:58:31 Join kugel_ [0] (~kugel@e178077210.adsl.alicedsl.de)
22:58:35 Quit froggyman (Read error: Connection reset by peer)
22:59:02Stephen__nope that's not it
22:59:11 Join froggyman [0] (~sopgenort@pool-72-69-220-42.chi01.dsl-w.verizon.net)
23:00
23:00:11 Join JdGordon [0] (~jonno@m0e0e36d0.tmodns.net)
23:02:06 Quit kugel (Ping timeout: 265 seconds)
23:03:07 Quit kugel_ (Ping timeout: 260 seconds)
23:10:57 Quit Omlet (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com ))
23:11:06Stephen__time to set p a new sim and test
23:13:38 Quit pamaury (Quit: Page closed)
23:15:25 Join planetbeing_ [0] (~planetbei@32.154.30.76)
23:15:35 Join kugel [0] (~kugel@e178085094.adsl.alicedsl.de)
23:15:39 Join planetbeing__ [0] (~planetbei@32.154.30.76)
23:15:48 Quit kugel (Changing host)
23:15:48 Join kugel [0] (~kugel@rockbox/developer/kugel)
23:16:12 Join arbingordon [0] (~w@c-71-226-248-30.hsd1.pa.comcast.net)
23:18:26 Quit JdGordon (Quit: Bye)
23:18:29 Quit planetbeing (Ping timeout: 245 seconds)
23:18:29 Nick planetbeing_ is now known as planetbeing (~planetbei@32.154.30.76)
23:21:08Stephen__whats the command for building the sim without plugins again ?
23:21:42linuxstb"make help"
23:21:54linuxstb(I expect "make bin" would do that)
23:23:16 Quit nima (Read error: Connection reset by peer)
23:26:07 Quit evilnick_B (Quit: Page closed)
23:28:08 Join nima [0] (~nima@adsl-75-45-227-18.dsl.sfldmi.sbcglobal.net)
23:30:13CIA-5New commit by 03peter (r25074): change histogram display principle to scrolling and simplify the code a bit
23:32:06kugelStephen__: you're going to need codecs to see the wps though
23:32:32Stephen__true. then jus without plugins. i know theres a && in there
23:33:08kugelmake bin && make codecs
23:33:34kugeldon't forget make install at the end
23:34:25Stephen__thanks kugel
23:37:42 Quit bmbl (Quit: Bye!)
23:38:00LloreanMore forum spam, user kar22
23:38:28CIA-5New commit by 03Domonoky (r25075): fix automatic upgrade of db. store checkwps output in db. display it as mouseover on the "doesnt work on x build".
23:39:18CIA-5New commit by 03Buschel (r25076): Fix musepack sv8 metadata parser. Thanks to Magnus Holmgren for spotting.
23:39:22pixelmato recap: I was testing rbspeexenc on different Macs and the binaries ran perfectly on an Intel running MacOS 10.5 - could not be executed on an Intel MacOS 10.4 and the PPC binaries worked on such a Mac with 10.4 but produced noise. Any ideas?
23:40:57kugelUnhelpful: you seemed to be interested in a newer gcc as well. any opinion to my proposal on the ml?
23:41:13domonokythe intel binarys are probably built against a 10.5 sdk, the ppc issue is interesting.
23:41:45linuxstbpixelma: Could you test decoding a .spx file on the opposite architecture to the one it was created on (PPC vs Intel) ? i.e. is encoding broken, or decoding, or both?
23:41:55domonokypixelma: does it produce noise with any test wav ? or only those generated by rbutil (on intel mac) .
23:41:58pixelmaoriginally I tested bluebrother's RbUtil which makes use of the Apple TTS which again ran perfectly on the 10.5 Intel, worked correctly with the 10.4 Intel but only for MP3 voice targets - it produced sound but just noise for a speex voice target, and hung completely on the 10.4 PPC
23:42:18CIA-5New commit by 03peter (r25077): fix yellow
23:42:44moosBuschel: well done! You finally found it
23:43:13Buschelwell, in fact Lear and I found and fixed it the same time :)
23:43:35 Quit p3tur (Remote host closed the connection)
23:43:47moosohoh goos syncronisation then
23:43:51moosgood
23:44:19pixelmadomonoky: I just tested the wav generated by "Test TTS" but that sounded correctly when listening to with Rockbox
23:44:44 Quit Lear (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158])
23:44:59domonokypixelma: it might still be in a wav format rbspeex doesnt like.
23:45:04pixelma(generated by the 10.4 Intel which is probably correct if voice generation for MP3 voice works there
23:45:47domonokyfor mp3 lame compresses the generated wav file, which probably supports more wav formats then rbspeex.
23:46:08 Quit petur (Quit: Zzzz)
23:47:04pixelmaok, I'll try to test tomorrow with a different wav
23:48:48Stephen__domonoky, thank you so much for r25075! makes life very much easier!
23:49:01pixelmalinuxstb: I tested the 10.5 Intel intermediate speex with rbspeexdec on the PPC and it produced noise too, file size was the same for the resulting wav in all tests (the noise sounded slightly different from the PPC > PPC noise)
23:49:32pixelmadomonoky: but why would it work correctly on the 10.5 Intel?
23:49:33Buschelgood night!
23:49:35 Quit Buschel ()
23:52:47domonokypixelma: everthing works on 10.5 intel ? so this testwav encoded/decoded with rbspeex on this mac is fine ?
23:53:04pixelmayes
23:53:07 Join anewuser [0] (anewuser@unaffiliated/anewuser)
23:55:39 Quit bertrik (Quit: De groeten)
23:55:54domonokystrange, if we have noise on 10.4 intel and 10.4 ppc it cant be endianess issues..
23:57:11domonokyand if it works on 10.5 it looks like some sdk issue, but thats pretty unlikely for a software like rbspeex... :-/
23:57:17pixelmawel in 10.4l we have noise in rbspeexenc on PPC and non-working state on Intel, and RbUtil is the different way around

Previous day | Next day