| 00:00:06 | LambdaCalculus37 | toffe82: For the SA9200, plugin keymaps. |
| 00:00:13 | LambdaCalculus37 | For the HDD6330, the touchpad driver. |
| 00:00:20 | LambdaCalculus37 | For both, an easy install method. |
| 00:00:29 | toffe82 | and the 1830 ? |
| 00:03:04 | | Quit n1s ("Lämnar") |
| 00:03:28 | LambdaCalculus37 | toffe82: Install method as well IIRC. |
| 00:03:34 | | Join martian67 [0] (i=lol3@d198-166-20-240.abhsia.telus.net) |
| 00:03:40 | LambdaCalculus37 | The HDD1x30 works well for the most part. |
| 00:04:35 | toffe82 | it would be nis to have them going in the unstable port |
| 00:04:47 | toffe82 | nice ... :) |
| 00:07:11 | LambdaCalculus37 | toffe82: Yes, I agree. |
| 00:07:47 | funman | regarding Sansa AMS, is there anything preventing Fuze & e200v2 at least (and Clip/m200v4/c200v2 when fs#10605 gets committed) to be part of the next release? |
| 00:07:49 | LambdaCalculus37 | Would anyone object to bumping the GoGear HDD1x30 series up from "Unusable" to "Unstable"? |
| 00:08:02 | LambdaCalculus37 | funman: No USB stack. |
| 00:08:51 | funman | that didn't prevent ipod & e200v1/c200v1 to be supported? |
| 00:09:08 | LambdaCalculus37 | That's true. |
| 00:09:43 | LambdaCalculus37 | toffe82: There's no install method in rbutil yet for the HDD1x30 models, either. |
| 00:10:26 | | Quit p3tur ("Zzzzz") |
| 00:10:44 | funman | and while USB support in rockbox would be nice, that doesn't prevent daily use (i use my fuze daily) |
| 00:10:44 | gevaerts | pamaury: what exactly should I test on the gigabeat S OF? |
| 00:13:44 | toffe82 | LambdaCalculus37: the install procedure is on the wiki for all the gogear ? all uptodate ? |
| 00:14:11 | gevaerts | funman: "daily use" is what gets you into unstable :) |
| 00:14:55 | LambdaCalculus37 | toffe82: For the SA9200, that's the current install procedure. |
| 00:15:08 | LambdaCalculus37 | For the HDD1x30 and the HDD6330, we need to add it. |
| 00:15:18 | funman | no, ports in unstable "run, but are incomplete, less usable or have problems that limit them to advanced users" |
| 00:15:39 | gevaerts | oh certainly, but they are usable for daily use |
| 00:15:54 | funman | i believe rockbox "runs well", "is supported by the installer", and the manual should be complete though i didn't check in details |
| 00:15:58 | gevaerts | I don't object to having them in the release though |
| 00:16:55 | LambdaCalculus37 | toffe82: Did you ever send me an extracted firmware update fileset for the MEG50JS or the MEG201? |
| 00:17:07 | | Part ercani |
| 00:17:47 | gevaerts | funman: I'm not sure about the clip though. The release should be in about a month, is that enough time to be confident that it works well? |
| 00:18:13 | funman | no idea |
| 00:18:34 | | Quit petur (Remote closed the connection) |
| 00:19:17 | gevaerts | we'll see |
| 00:21:57 | toffe82 | LambdaCalculus37: I don't remember |
| 00:34:01 | * | LambdaCalculus37 extracts the firmware updates |
| 00:34:50 | saratoga | funman: I'm going to make the clip unstable tomorrow |
| 00:35:05 | saratoga | IMO the Fuze and e200v2 can become stable too |
| 00:35:12 | saratoga | should I change all of them tomorrow? |
| 00:40:24 | funman | shoudln't we wait for the release ? |
| 00:41:30 | LambdaCalculus37 | toffe82: It looks like I may be able to get some very useful information out of the Gigabeat MEG201 and MEG50JS in terms of flash ROM if I can just cat /dev/from into an external file and read it. |
| 00:45:06 | | Quit bertrik ("De groeten") |
| 00:45:12 | * | toffe82 lets LambdaCalculus37 do this.... |
| 00:46:36 | kugel | saratoga: the clip has still a mostly unusable keymap IMO |
| 00:48:23 | JdGordon | no it doesnt... |
| 00:49:58 | kugel | it does |
| 00:50:09 | | Join MethoS- [0] (n=clemens@134.102.106.250) |
| 00:50:15 | kugel | I think you can't even exit some plugins |
| 00:57:12 | | Quit funman ("free(random());") |
| 00:57:42 | kugel | I think the clip shouldn't be stable already, it wasn't even unstable yet |
| 00:58:07 | kugel | nobody can really tell if it's sufficient for stable because it was basically impossible to use it on a every day basis |
| 00:59:12 | LambdaCalculus37 | HA... minix filesystem is used on the MEG201. :) |
| 01:00 |
| 01:00:25 | JdGordon | its not useable becasue its only 2GB :) |
| 01:02:30 | | Join CaptainKwel [0] (n=jason@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) |
| 01:05:56 | | Quit dmb (Read error: 113 (No route to host)) |
| 01:18:13 | *** | Saving seen data "./dancer.seen" |
| 01:22:52 | | Quit sbhsu (Read error: 60 (Operation timed out)) |
| 01:24:47 | Unhelpful | hrm, what's the "right" way with strict aliasing to address alias an array of char w/ an array of some other type? :/ |
| 01:25:11 | Torne | isn't the point that you don't do that? |
| 01:27:37 | Torne | also char* is allowed to alias points of any size, no? |
| 01:28:01 | Unhelpful | Torne: the point is that you make sure the compiler *knows* when you do such things... usually via unions and the like. or that's what i though? the example here is that the bmp reader reads raw file data into a buffer, and then decodes it a pixel at a time into the same buffer |
| 01:28:27 | Torne | if you use a union that's not aliasing :) |
| 01:28:32 | Torne | but, yes, i see wht you mean |
| 01:28:40 | Torne | char* is allowed to alias other pointer types, though |
| 01:28:49 | Torne | so it shouldn't be a problem? |
| 01:31:45 | Unhelpful | and yet it seems to be... the read buffer is cast to uint8_rgb* and then bmp.c:825 throws an aliasing warning |
| 01:32:35 | Torne | uint8_rgb is presumably a typedef for unsigned char though.. i'm not sure if that counts |
| 01:32:51 | Torne | i'm not sure tbh :) |
| 01:33:13 | Unhelpful | um, no, it's a struct. the issue might be that the dereferenced value is "passed" to an inline function. i'm not sure. |
| 01:34:38 | Torne | fun. |
| 01:35:51 | | Quit toffe82 ("ChatZilla 0.9.85 [Firefox 3.5.5/20091102152451]") |
| 01:36:00 | | Quit parafin (Read error: 60 (Operation timed out)) |
| 01:36:04 | | Join Rob2223 [0] (n=Miranda@p4FDCCD33.dip.t-dialin.net) |
| 01:37:56 | | Join parafin [0] (i=parafin@paraf.in) |
| 01:38:24 | Unhelpful | the color case passes the buffer to output_row_8_native, which seems to have no problem casting the received char * to struct uint8_rgb * and addressing it. i'm guessing either 1) a distinction is being made between array and char 2) the inline function is an issue |
| 01:39:45 | Torne | well try uninlining it? |
| 01:39:49 | Torne | just to see? |
| 01:41:53 | Unhelpful | well, i was thinking not so much "it's inline" as "struct-as-argument" |
| 01:42:10 | | Join rodion09 [0] (n=8d231d31@giant.haxx.se) |
| 01:42:29 | Unhelpful | which is probably not nice to do even for a <int-sized struct |
| 01:43:09 | | Quit Rob2222 (Read error: 60 (Operation timed out)) |
| 01:45:34 | | Quit liar (Read error: 113 (No route to host)) |
| 01:45:52 | Unhelpful | very strange. the compiler does *not* complain about using the aliased pointer to access the struct members, so that they can be packed to native format. it *does* complain about passing the struct, *or* the aliased pointer to it, as an argument to brightness(). perhaps rewriting it as a macro? |
| 01:47:16 | Unhelpful | if i pass it as a pointer, the alias warnings trigger on bmp.h for the access within brightness |
| 01:52:04 | * | Unhelpful will try putting an anon union into bmp_args of a char array or a struct uint8_rgb array... surely if they're in a union then gcc "knows" they alias each other? |
| 01:55:57 | | Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) |
| 01:57:32 | Unhelpful | the unionized buffer works even if i don't ever *use* the uint8_rgb[] member. a bit weird. |
| 01:58:10 | Torne | you know -Wstrict-aliasing isn't perfect, right? :) |
| 01:58:26 | Torne | it cannot detect all possible cases of unacceptable aliasing |
| 01:58:30 | Unhelpful | although i *could* replace all of the (uint8_rgb*)ba.buf now with ba.pbuf. i'm not sure if that would be more or less readable than it is now. |
| 01:58:34 | Torne | otherwise there would be no need to have a warning |
| 01:58:47 | Torne | gcc could just not optimise around things it knows are aliased badly :) |
| 01:59:09 | Torne | sadly the gcc authors expect you to actually be sure whether what you are doign is okay :) |
| 01:59:13 | | Quit rodion09 ("CGI:IRC (EOF)") |
| 01:59:18 | Torne | the warnings are just a partial crutch |
| 01:59:40 | Unhelpful | Torne: of course it's not perfect. but n1s saw some things improve in speed on 4.4 with -fstrict-aliasing, and so i thought i might have a go at cleaning up the warnings that causes |
| 01:59:58 | Torne | Indeed, the strict aliasing optimisations do help |
| 02:00 |
| 02:00:13 | Torne | i'm just saying that you probably should be sure ;) |
| 02:01:14 | Unhelpful | it's in-place conversion of a buffer from one format to another... is there a more correct way to do it? |
| 02:01:31 | Unhelpful | also, i think the union is pretty much guaranteed to be safe, isn't it? |
| 02:02:01 | kugel | is that the only aliasing problem in the core? |
| 02:02:40 | Unhelpful | it's not the only one gcc warns for :) |
| 02:03:40 | Unhelpful | since i have a pbuf member now that is explicitly "buf, but as struct uint8_rgb[]", should i be using that? the structure definition makes it quite obvious what types buf and pbuf are, and that they alias each other. |
| 02:12:56 | | Quit GeekShado_ (Read error: 110 (Connection timed out)) |
| 02:22:32 | * | Unhelpful has no idea how to fix the ones in kernel.c :/ |
| 02:22:34 | | Quit HBK (Read error: 54 (Connection reset by peer)) |
| 02:23:43 | | Quit kugel ("exit(0);") |
| 02:25:11 | | Join phanboy4 [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net) |
| 02:26:07 | | Join HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) |
| 02:27:18 | | Quit Omlet ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") |
| 02:34:57 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 02:40:40 | | Join bughunter21 [0] (n=bughunte@ip4da4427e.direct-adsl.nl) |
| 02:40:40 | | Quit bughunter2 (Nick collision from services.) |
| 02:40:51 | | Nick bughunter21 is now known as bughunter2 (n=bughunte@ip4da4427e.direct-adsl.nl) |
| 02:41:35 | | Join darkhamm [0] (n=darkhamm@host235-156-dynamic.6-87-r.retail.telecomitalia.it) |
| 02:42:34 | | Join pamaury [0] (n=pamaury@88-123-144-76.rev.libertysurf.net) |
| 02:43:07 | | Join toffe82 [0] (n=chatzill@adsl-75-12-169-103.dsl.frs2ca.sbcglobal.net) |
| 02:46:14 | | Quit hebz0rl () |
| 02:48:33 | darkhamm | will rockbox play more lossless audio codecs' |
| 02:48:37 | darkhamm | like tta? |
| 02:50:09 | Torne | if someone implements it |
| 02:51:50 | Unhelpful | it already supports wavpack, monkey's audio (but only on the fastest hardware), flac, and apple lossless. do you *really* need tta? |
| 02:52:34 | | Quit pamaury ("exit(*(int *)0 / 0);") |
| 02:53:54 | | Join webguest30 [0] (n=62524b71@83.168.254.42) |
| 02:53:57 | | Join pamaury [0] (n=pamaury@88-123-144-76.rev.libertysurf.net) |
| 02:54:02 | | Quit webguest30 (Client Quit) |
| 02:54:19 | | Quit pamaury (Client Quit) |
| 02:55:16 | darkhamm | Unhelpful, not, i'm only interesting to lossless support |
| 02:55:35 | darkhamm | i only look that tta have very little encoding times |
| 02:56:01 | Unhelpful | you could work on supporting it. for lossless generally decoding time and compression ratio are more important than encoding times. |
| 02:57:49 | LambdaCalculus37 | Unhelpful: There's always some nut out there who has a weird, obscure format. ;) |
| 02:57:57 | darkhamm | Unhelpful, yes i became curious browsing http://true-audio.com/TTA_Lossless_Audio_Codec_-_Performance_Comparison |
| 02:59:09 | darkhamm | and at highest level , flac (my favorite) have the longest time |
| 02:59:19 | Unhelpful | LambdaCalculus37: tbh the only one we *don't* support that i'd like to see is tak, and that only if the author ever gets around to releasing source. winning on encode time *and* compression ratio vs many common codecs, with decode times competitive with flac? sounds good. |
| 03:00 |
| 03:00:43 | Unhelpful | darkhamm: encode time is not really where you should be looking, unless you're comparing codecs that are on fairly even footing with regard to decode time and compression ratio. |
| 03:01:45 | Unhelpful | also, high-compression encode in flac has gotten *much* faster since 1.1.0. |
| 03:03:08 | | Join fyre^OS [0] (n=nnscript@cpe-69-203-150-85.si.res.rr.com) |
| 03:03:37 | | Join HellDragon_ [0] (n=jd@modemcable207.134-202-24.mc.videotron.ca) |
| 03:04:13 | | Join toffe82_ [0] (n=chatzill@75.12.169.103) |
| 03:04:56 | Unhelpful | i believe flac-1.1.4 incorporated the work done on flake for estimating/solving for parameters that used to be brute-force-searched in high modes |
| 03:05:45 | | Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) |
| 03:05:45 | | Quit pixelma (Nick collision from services.) |
| 03:05:51 | | Quit toffe82 (lindbohm.freenode.net irc.freenode.net) |
| 03:05:51 | NSplit | lindbohm.freenode.net irc.freenode.net |
| 03:05:51 | | Quit hd (lindbohm.freenode.net irc.freenode.net) |
| 03:05:51 | | Quit fyrestorm (lindbohm.freenode.net irc.freenode.net) |
| 03:05:51 | | Quit AaronM (lindbohm.freenode.net irc.freenode.net) |
| 03:05:51 | | Quit freqmod_qu (lindbohm.freenode.net irc.freenode.net) |
| 03:05:51 | | Quit jasio_ (lindbohm.freenode.net irc.freenode.net) |
| 03:05:51 | | Quit rasher (lindbohm.freenode.net irc.freenode.net) |
| 03:05:51 | | Quit Utchybann (lindbohm.freenode.net irc.freenode.net) |
| 03:05:56 | | Nick toffe82_ is now known as toffe82 (n=chatzill@75.12.169.103) |
| 03:06:04 | NHeal | lindbohm.freenode.net irc.freenode.net |
| 03:06:04 | NJoin | freqmod_qu [0] (n=quassel@dhcp208-92.ed.ntnu.no) |
| 03:06:04 | | Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) |
| 03:08:21 | | Join rasher [0] (n=rasher@0x5550f5a3.adsl.cybercity.dk) |
| 03:08:29 | | Quit toffe82 (Killed by sagan.freenode.net (Nick collision)) |
| 03:08:31 | | Join jasio [0] (n=yann@86.28.167.135) |
| 03:08:31 | NJoin | toffe82 [0] (n=chatzill@adsl-75-12-169-103.dsl.frs2ca.sbcglobal.net) |
| 03:08:31 | | Join hd [0] (n=jd@Wikipedia/HellDragon) |
| 03:08:31 | NJoin | fyrestorm [0] (n=nnscript@cpe-69-203-150-85.si.res.rr.com) |
| 03:08:31 | NJoin | AaronM [0] (n=Aaron@adsl-4-252-44.mem.bellsouth.net) |
| 03:08:31 | NJoin | jasio_ [0] (n=yann@cpc2-rdng20-2-0-cust902.15-3.cable.virginmedia.com) |
| 03:08:31 | NJoin | Utchybann [0] (n=lolo@ede67-1-81-56-102-26.fbx.proxad.net) |
| 03:09:03 | | Quit jasio_ (Read error: 104 (Connection reset by peer)) |
| 03:09:13 | | Quit hd (SendQ exceeded) |
| 03:09:13 | | Join toffe82_ [0] (n=chatzill@adsl-75-12-169-103.dsl.frs2ca.sbcglobal.net) |
| 03:12:27 | LambdaCalculus37 | Unhelpful: And there's OptimFROG, although that's proprietary. |
| 03:13:23 | Unhelpful | so's tak. "i need to clean it up, fix some issues, and rewrite in c or c++ before i open the source", as though a community effort couldn't make all of that *easier* |
| 03:16:36 | | Quit CaptainKwel (Read error: 54 (Connection reset by peer)) |
| 03:18:16 | *** | Saving seen data "./dancer.seen" |
| 03:18:40 | | Join sbhsu [0] (n=a6530466@Zion.dorm.au.edu.tw) |
| 03:23:03 | | Quit toffe82 (Connection timed out) |
| 03:23:30 | | Quit fyrestorm (Connection timed out) |
| 03:25:31 | LambdaCalculus37 | Unhelpful: Hey, community effort helped us out a lot. :) |
| 03:25:41 | | Quit Thundercloud (Remote closed the connection) |
| 03:28:34 | | Join CaptainKewl [0] (i=jds@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) |
| 03:28:34 | | Quit CaptainKewl (Client Quit) |
| 03:28:55 | | Join CaptainKewl [0] (i=jds@207.237.172.77) |
| 03:32:44 | | Quit darkhamm ("Sto andando via") |
| 03:35:21 | | Quit LambdaCalculus37 ("cd ~") |
| 03:56:51 | | Quit Res1 (Read error: 60 (Operation timed out)) |
| 04:00 |
| 04:04:15 | | Part Llorean |
| 04:06:32 | | Quit tchan ("WeeChat 0.3.1-dev") |
| 04:08:09 | | Quit Rondom (Nick collision from services.) |
| 04:08:19 | | Join Rondom [0] (n=Rondom@dslb-084-057-160-034.pools.arcor-ip.net) |
| 04:10:35 | | Join Res1 [0] (n=Res@user-0c6s6gs.cable.mindspring.com) |
| 04:10:41 | | Quit TheSeven (Nick collision from services.) |
| 04:10:48 | | Join The_Seven [0] (n=theseven@rockbox/developer/TheSeven) |
| 04:11:00 | | Nick The_Seven is now known as TheSeven (n=theseven@rockbox/developer/TheSeven) |
| 04:19:27 | | Join faemir [0] (n=faemir@78.33.109.163) |
| 04:22:38 | | Join Llorean [0] (n=DarkkOne@76.202.17.167) |
| 04:31:26 | | Quit jasio (lindbohm.freenode.net irc.freenode.net) |
| 04:31:26 | NSplit | lindbohm.freenode.net irc.freenode.net |
| 04:31:26 | | Quit Utchybann (lindbohm.freenode.net irc.freenode.net) |
| 04:31:26 | | Quit AaronM (lindbohm.freenode.net irc.freenode.net) |
| 04:32:29 | | Join lovingHDTV [0] (n=IceChat7@cpe-66-68-44-125.austin.res.rr.com) |
| 04:32:51 | lovingHDTV | Anyone know if there is a hearing aid type plugin? |
| 04:35:28 | NHeal | lindbohm.freenode.net irc.freenode.net |
| 04:35:28 | NJoin | jasio [0] (n=yann@86.28.167.135) |
| 04:35:28 | NJoin | AaronM [0] (n=Aaron@adsl-4-252-44.mem.bellsouth.net) |
| 04:35:28 | NJoin | Utchybann [0] (n=lolo@ede67-1-81-56-102-26.fbx.proxad.net) |
| 04:35:35 | | Join jasio_ [0] (n=yann@86.28.167.135) |
| 04:35:56 | | Quit GeekShadow ("The cake is a lie !") |
| 04:40:59 | | Quit kugel (Remote closed the connection) |
| 04:43:29 | | Join KBH [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) |
| 04:45:48 | | Quit HBK (Read error: 60 (Operation timed out)) |
| 04:45:48 | | Nick KBH is now known as HBK (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) |
| 04:46:33 | | Quit jasio (Read error: 110 (Connection timed out)) |
| 04:54:12 | | Join BiptoN [0] (n=4cad70c0@83.168.254.42) |
| 05:00 |
| 05:00:54 | | Quit BiptoN ("CGI:IRC (EOF)") |
| 05:01:06 | | Join bipton [0] (n=4cad70c0@giant.haxx.se) |
| 05:01:34 | bipton | . |
| 05:01:52 | bipton | anyone here use the svn ipodpatcher today? |
| 05:05:37 | | Join tmzt_ [0] (n=tmzt@adsl-76-244-155-63.dsl.akrnoh.sbcglobal.net) |
| 05:06:41 | | Join tchan [0] (n=tchan@lunar-linux/developer/tchan) |
| 05:10:41 | | Join tmzt__ [0] (n=tmzt@adsl-76-244-155-63.dsl.akrnoh.sbcglobal.net) |
| 05:16:00 | | Quit tmzt (Read error: 110 (Connection timed out)) |
| 05:18:19 | *** | Saving seen data "./dancer.seen" |
| 05:22:47 | | Quit tmzt_ (Read error: 110 (Connection timed out)) |
| 05:38:23 | bipton | no one...? |
| 05:45:56 | * | Unhelpful doesn't even own an ipod :) |
| 05:48:43 | Unhelpful | n1s: i've got my beast results from running different -O levels. the tuned-level times for beast are probably the best for any target i've looked at so far. ape is ~4% slower at best, vorbis as much as 1.7% slower, but in the .1-.5% range for most bitrates, and everything else is faster after tuning |
| 05:49:07 | | Join webguest43 [0] (n=dee1773c@83.168.254.42) |
| 05:50:00 | Unhelpful | mpc by ~5.5%, flac by ~16%, wma by ~8%, and aac-he by ~12% are the most impressive numbers. clearly 4.4.2 knows how to work armv6 better than 4.0.3 :) |
| 05:52:04 | Unhelpful | vorbis and ape were the losers on beaft also, though neither by more than 1.25%. and the gains were not as large, either, except the m4a samples |
| 05:53:20 | webguest43 | Does anyone know whether bockbox bootloader supports eabi? |
| 05:54:56 | Unhelpful | i doubt anybody has tried |
| 05:55:10 | | Quit mt (Read error: 104 (Connection reset by peer)) |
| 05:55:38 | | Join mt [0] (n=mtee@41.233.146.83) |
| 05:55:58 | Unhelpful | but the bootloader is essentially a stripped-down version of rockbox, so it likely works properly |
| 06:00 |
| 06:06:47 | | Quit tchan ("WeeChat 0.3.1-dev") |
| 06:07:33 | | Quit bipton ("CGI:IRC") |
| 06:07:44 | webguest43 | i see. |
| 06:08:48 | | Quit webguest43 ("CGI:IRC (EOF)") |
| 06:09:19 | Unhelpful | results from tuning work so far are here: http://www.looking-glass.us/~chshrcat/rockbox/eabi_tests/ |
| 06:09:29 | Unhelpful | the lesson: arm7tdim sucks :) |
| 06:18:28 | | Join tchan [0] (n=tchan@lunar-linux/developer/tchan) |
| 06:26:02 | | Quit panni_ (Read error: 131 (Connection reset by peer)) |
| 06:49:32 | | Join FOAD_ [0] (n=dok@82.93.10.238) |
| 06:49:44 | | Quit bluebrother (Nick collision from services.) |
| 06:49:47 | | Join bluebroth3r [0] (n=dom@rockbox/developer/bluebrother) |
| 06:52:04 | | Quit jasio_ (lindbohm.freenode.net irc.freenode.net) |
| 06:52:04 | NSplit | lindbohm.freenode.net irc.freenode.net |
| 06:52:04 | | Quit Utchybann (lindbohm.freenode.net irc.freenode.net) |
| 06:52:04 | | Quit AaronM (lindbohm.freenode.net irc.freenode.net) |
| 06:57:36 | | Quit FOAD (Read error: 145 (Connection timed out)) |
| 06:57:36 | | Nick FOAD_ is now known as FOAD (n=dok@82.93.10.238) |
| 07:00 |
| 07:05:16 | NHeal | lindbohm.freenode.net irc.freenode.net |
| 07:05:16 | NJoin | jasio_ [0] (n=yann@86.28.167.135) |
| 07:05:16 | NJoin | AaronM [0] (n=Aaron@adsl-4-252-44.mem.bellsouth.net) |
| 07:05:16 | NJoin | Utchybann [0] (n=lolo@ede67-1-81-56-102-26.fbx.proxad.net) |
| 07:05:55 | | Quit Utchybann (Read error: 104 (Connection reset by peer)) |
| 07:06:04 | | Join AaronMcD [0] (n=Aaron@adsl-4-252-44.mem.bellsouth.net) |
| 07:06:05 | | Join Utchybann [0] (n=lolo@ede67-1-81-56-102-26.fbx.proxad.net) |
| 07:06:18 | | Quit AaronM (Connection reset by peer) |
| 07:06:45 | | Quit jasio_ (Read error: 110 (Connection timed out)) |
| 07:10:24 | | Join jasio [0] (n=yann@cpc2-rdng20-2-0-cust902.15-3.cable.virginmedia.com) |
| 07:13:40 | | Join AlexC [0] (n=AlexC@unaffiliated/alexc) |
| 07:13:57 | | Join shai [0] (n=Shai@l192-117-110-233.cable.actcom.net.il) |
| 07:14:05 | AlexC | Hello |
| 07:15:21 | AlexC | Recently nearly all of the new music i put onto my ipod doesn't play on rockbox and causes rockbox to stop playing all music until reboot |
| 07:15:33 | AlexC | also my apple firmware doesn't work |
| 07:15:51 | AlexC | If i format it will that fix anything? |
| 07:17:05 | sinthetek | i am no expert, AlexC, but i would think it's at least possible some sort of fs errors could cause problems so fs repair or format may help |
| 07:17:30 | sinthetek | no idea on apple firmware (i use rockbox on a different dap myself) |
| 07:18:22 | *** | Saving seen data "./dancer.seen" |
| 07:21:20 | * | AlexC nods |
| 07:21:28 | AlexC | yeah it's a bit of a pain |
| 07:25:40 | | Quit CaptainKewl (Read error: 145 (Connection timed out)) |
| 07:48:02 | | Join Horschti [0] (n=Horscht2@xbmc/user/horscht) |
| 07:56:29 | | Quit Horscht (Read error: 145 (Connection timed out)) |
| 08:00 |
| 08:03:26 | | Join dmb [0] (n=Dmb@unaffiliated/dmb) |
| 08:14:04 | | Part toffe82_ |
| 08:15:22 | | Quit AaronMcD ("Emo Time In My Corner... //_-") |
| 08:16:21 | | Quit MethoS- (Remote closed the connection) |
| 08:27:52 | | Quit Tomis () |
| 08:37:54 | | Quit phanboy4 ("Leaving") |
| 08:47:49 | | Join ecognito [0] (n=ecognito@ppp118-209-67-70.lns20.mel4.internode.on.net) |
| 08:54:07 | | Join Rob2222 [0] (n=Miranda@p4FDCFDA1.dip.t-dialin.net) |
| 09:00 |
| 09:00:08 | | Join pondlife [50] (n=Steve@rockbox/developer/pondlife) |
| 09:06:23 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 09:11:52 | | Quit Rob2223 (Read error: 110 (Connection timed out)) |
| 09:15:13 | | Quit pondlife ("Leaving.") |
| 09:17:51 | | Quit AlexC (Remote closed the connection) |
| 09:18:25 | *** | Saving seen data "./dancer.seen" |
| 09:20:46 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 09:22:02 | | Join flydutch [0] (n=flydutch@host119-166-dynamic.8-87-r.retail.telecomitalia.it) |
| 09:26:43 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 09:42:24 | | Join ender` [0] (i=krneki@84.255.206.8) |
| 09:49:13 | n1s | Unhelpful: nice testing, seems to be about the same results i got, i didn't test all the O levels though, it looka like a clear win for both the beast and the gigabeat f and while the sansa has more losses they are not very big |
| 09:51:26 | * | amiconn thinks that the value of a speedup/slowdown depends on how fast that codec was to begin with |
| 09:52:38 | amiconn | A speedup in a codec with is already fast (like flac) is worth nothing if it means a slowdown in a slow codec (like e.g. aac) |
| 09:55:05 | n1s | amiconn: true, but more than flac are faster, on sansa flac, alac, aac, wv and mp3 are faster |
| 09:55:49 | n1s | while vorbis, wma, mpc, ac3 and ape are slower |
| 09:56:35 | n1s | Unhelpful: could you post your patch to easily swithc the codec compilation options? it might come in handy in the future |
| 10:00 |
| 10:00:30 | n1s | Unhelpful: btw, i only get aliasing warnings in the zxbox plugin |
| 10:01:33 | n1s | if it turns out fixing those warnings is tricky maybe we should just turn it on for codes as you suggested |
| 10:02:46 | | Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) |
| 10:03:37 | n1s | amiconn: although the comparison is a bit unfair since i don't think anyone has set the optimal compiler optimization level for most of our codecs in svn |
| 10:04:03 | n1s | so a bunch of them use the core optimization settings |
| 10:04:20 | amiconn | It seems that especially wavpack optimisation is hosed in svn |
| 10:05:15 | n1s | flac, faad and cook also build with the core optimization setting |
| 10:06:17 | | Join Enok [0] (n=53e34bb1@giant.haxx.se) |
| 10:06:32 | n1s | wavpack is using O2 so that might be a real compiler improvement |
| 10:06:56 | | Quit Enok (Client Quit) |
| 10:08:08 | n1s | and it only sees the big improvement for arm7 |
| 10:20:51 | Unhelpful | n1s: when compiling with the new eabi compiler, and using -fstrict-aliasing in the makefile? interesting, i get several issues in core and a few of the plugins are *covered* in them |
| 10:21:43 | Unhelpful | most codecs and/or decoder libraries they use don't really touch -O |
| 10:22:35 | n1s | Unhelpful: i just removed the -fnostrict-aliasing from the makefile but yeah, only zxbox, which target are you building for? |
| 10:25:01 | Unhelpful | beast. i replaced it with a -fstrict-aliasing... it looks like that changes the default warning settings for aliasing as well |
| 10:27:21 | n1s | ooh |
| 10:27:35 | Unhelpful | it looks as if -fstrict-aliasing sets -Wstrict-aliasing, which is equivalent to setting -Wstrict-aliasing=3 ; this is the highest level, which does more detailed aliasing analysis and should, per the manual, have "very few false positives and few false negatives" |
| 10:29:51 | Unhelpful | probably we should at least *try* to resolve warnings regarding aliasing. as you saw with test_codec, strict aliasing can allow the compiler to be a bit more successful in optimization. |
| 10:32:50 | Unhelpful | it would be nice to have a "checksum directory" option in test_codec that could be used to verify that optimization changes and such don't impact codec output... obviously it's no help when somebody makes algorithmic changes, but compiler flags *shouldn't* change results, at least not in fixed-point codecs... |
| 10:35:42 | | Join stoffel [0] (n=quassel@p57B4DBA9.dip.t-dialin.net) |
| 10:36:00 | n1s | should be easy to implement really |
| 10:36:23 | n1s | we have the write wav functionality and can md5sum the wavs |
| 10:36:36 | | Quit ender` (" The most important lesson we can learn from history is the inability of humans to learn lessons from history. -- Aldous Hux") |
| 10:38:42 | | Join DerPapst [0] (n=DerPapst@91.64.221.175) |
| 10:39:09 | Unhelpful | i don't think that write wav can process a whole directory... aside from that it would also be more efficient to checksum the decoded data in memory. and if we're checking for errors rather than guarding against malicious alteration of data, md5 might be a fair bit of overkill. the jhash algorithm that i added to pluginlib and never got to using would probably be fine :) |
| 10:49:05 | | Quit Utchybann ("I like core dumps") |
| 10:57:44 | amiconn | Unhelpful: Rockbox already has crc32. Maybe that is sufficient |
| 10:58:13 | Unhelpful | that probably is, too... |
| 11:00 |
| 11:04:32 | | Quit ecognito ("I read it on the Internet so it MUST be true!") |
| 11:18:29 | *** | Saving seen data "./dancer.seen" |
| 11:26:47 | | Join hebz0rl [0] (n=hebz0rl@dslb-088-065-218-202.pools.arcor-ip.net) |
| 11:37:08 | | Join ender [0] (i=krneki@84.255.206.8) |
| 11:38:42 | | Quit shai (lindbohm.freenode.net irc.freenode.net) |
| 11:38:42 | NSplit | lindbohm.freenode.net irc.freenode.net |
| 11:38:42 | | Quit jasio (lindbohm.freenode.net irc.freenode.net) |
| 11:38:46 | | Join shai_ [0] (n=Shai@l192-117-110-233.cable.actcom.net.il) |
| 11:43:39 | | Quit Kopfgeldjaeger (Read error: 104 (Connection reset by peer)) |
| 11:43:41 | Unhelpful | n1s: patch to force -O level on *all* codecs. this includes anything that has a tuned -O level already - those are gone w/ this patch. :) |
| 11:46:56 | | Join Kopfgeldjaeger [0] (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de) |
| 11:49:40 | n1s | Unhelpful: aha, still usefull though (can it set other switches than O levels?) |
| 11:51:12 | Unhelpful | you could add some other switch in codecs.make, *but* i didn't remove overrides for anything else from the sub-makefiles |
| 11:52:46 | n1s | so you just added the switches to codecs.make and removed the overrides? |
| 11:54:14 | | Join pamaury [0] (n=pamaury@88-123-144-76.rev.libertysurf.net) |
| 11:54:43 | Unhelpful | that's all, yes. also, i can see why we do this where there's more than one -O we might add based on target etc, but why do we *always* seem to use filter-flags when in some cases subst would do? |
| 11:57:45 | | Quit hebz0rl () |
| 11:58:14 | n1s | what do you think about fixing the aliasing warnings? i'm not very sure how to fix the trickier ones but won't work on it if you are already or think it isn't worth it |
| 11:59:43 | Unhelpful | i'm not sure *either*. i think it would be best to start with enabling it for codecs and tackling any there. |
| 12:00 |
| 12:00:53 | n1s | btw, casting the pointers to (void*) "fixes" the warnings in kernel.c, not sure about that though |
| 12:01:31 | n1s | (void*)arr == NULL |
| 12:03:07 | n1s | well, any explicit cast seems to do it which makes me wonder even more |
| 12:04:36 | Unhelpful | don' t know. the solution i used for bmp.c can't work everywhere... in fact, it can only work for aliased members of structs :/ |
| 12:05:18 | Unhelpful | as nice global anonymous unions for creating variables that explicitly alias each other |
| 12:06:05 | NHeal | lindbohm.freenode.net irc.freenode.net |
| 12:06:05 | NJoin | jasio [0] (n=yann@cpc2-rdng20-2-0-cust902.15-3.cable.virginmedia.com) |
| 12:09:38 | n1s | afaik void pointers alias everything so this should be legal, but maybe casting to struct timeout* is nicer |
| 12:12:18 | Unhelpful | i didn't look very closely at those... i was honestly a bit confused as to what was going on, it looked like the array of structs, including their various members, was addressed as an array of void*... |
| 12:12:55 | n1s | yes, i think it's doing that |
| 12:15:25 | * | Unhelpful couldn't figure out how manipulating it in that way could be valid, since the code doesn't even know which struct member it's touching... |
| 12:15:32 | | Quit BHSPitLappy ("Ex-Chat") |
| 12:17:25 | n1s | afaict it only messes with the array of struct pointers and is addressing those as void |
| 12:20:17 | Unhelpful | ...*oh*. it's an array of struct *, not of struct? :) |
| 12:27:22 | n1s | in fact uisng struct timeout** pointers and casting to void** in the function calls fixes the warnings and seems nicer to me |
| 12:27:45 | n1s | i wonder of a good way of testing this |
| 12:28:11 | Unhelpful | you mean, testing whether it's valid? |
| 12:29:14 | Unhelpful | apparently for types you can use the may_alias attribute |
| 12:30:15 | Unhelpful | in fact, i wonder if that might be a cleaner fix for bmp.c |
| 12:30:27 | | Join liar [0] (n=liar@83.175.83.185) |
| 12:31:07 | | Quit mt (Read error: 104 (Connection reset by peer)) |
| 12:31:37 | | Join mt [0] (n=mtee@rockbox/developer/mt) |
| 12:32:10 | | Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) |
| 12:38:15 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 12:40:00 | | Quit yosafbridge ("Coyote finally caught me") |
| 12:40:16 | | Join yosafbridge [0] (n=yosafbri@64.71.152.39) |
| 12:47:15 | | Quit FOAD (Read error: 145 (Connection timed out)) |
| 12:47:17 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 12:52:17 | | Join Grahack [0] (n=chri@ACaen-156-1-132-28.w86-220.abo.wanadoo.fr) |
| 13:00 |
| 13:07:17 | n1s | yeah i mean teting if it actually works |
| 13:14:40 | | Quit Kopfgeldjaeger (Read error: 60 (Operation timed out)) |
| 13:15:28 | | Join petur [0] (n=petur@84.198.249.178) |
| 13:18:29 | | Join Kopfgeldjaeger [0] (n=nicolai@212.40.172.92) |
| 13:18:31 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 13:18:32 | *** | Saving seen data "./dancer.seen" |
| 13:30:25 | | Join hebz0rl [0] (n=hebz0rl@dslb-088-065-218-202.pools.arcor-ip.net) |
| 13:32:31 | | Quit stoffel (Remote closed the connection) |
| 13:35:29 | | Quit FOAD (Read error: 110 (Connection timed out)) |
| 13:35:29 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 13:45:06 | | Quit n1s ("Lämnar") |
| 13:47:13 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 13:48:04 | n1s | of the codecs, mod, spc and the mp3 encoder gives aliasing warnings |
| 13:48:14 | | Join bimbel [0] (n=Miranda@unaffiliated/bmbl) |
| 13:48:43 | * | petur wonders if JdGordon is looking into the recording statusbar issue or was merely hinting somebody should fix it |
| 13:49:58 | | Join fdinel [0] (n=Miranda@modemcable235.127-131-66.mc.videotron.ca) |
| 13:50:18 | | Quit seani_ ("Leaving") |
| 13:55:28 | | Nick Tuplanolla is now known as Tuplis (n=jani@unaffiliated/tuplanolla) |
| 13:55:31 | n1s | hmm, spc is accessing a char array as uint16 so that's no surprise, just need to dig up a test file and this should be easy to fix |
| 14:00 |
| 14:03:40 | | Join Omlet [0] (i=omlet05@241.107-240-81.adsl-dyn.isp.belgacom.be) |
| 14:05:23 | | Quit bmbl (Connection timed out) |
| 14:10:07 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
| 14:11:29 | | Quit lovingHDTV (Read error: 110 (Connection timed out)) |
| 14:11:57 | | Quit Bob_C (Remote closed the connection) |
| 14:12:08 | | Quit flydutch ("/* empty */") |
| 14:40:28 | | Quit Thundercloud (Remote closed the connection) |
| 14:44:43 | | Join pondlife [50] (n=Steve@rockbox/developer/pondlife) |
| 14:52:01 | | Part pondlife |
| 15:00 |
| 15:03:05 | pamaury | gevaerts: here ? |
| 15:05:16 | Ctcp | Ping from gevaerts!n=fg@rockbox/developer/gevaerts |
| 15:05:36 | * | gevaerts hears beeping |
| 15:06:44 | | Join CaptainKewl [0] (i=jds@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) |
| 15:07:45 | gevaerts | pamaury: yes |
| 15:10:25 | pamaury | gevaerts: I really don't have time now but I saw on the logs that you asked me something after I quit irc. This was about what you should test on your device: you should try to get the string descriptor at 0xee and then send a get compat id and get extended property reequest and dump the answer |
| 15:10:34 | | Join oblib [0] (n=oblib@6-131-13-204.erd.cust.wirelessbeehive.com) |
| 15:10:53 | gevaerts | ok. I'll try to look for that |
| 15:11:06 | gevaerts | can any of the mtp tools help with it? |
| 15:11:53 | oblib | Hi, I've finally gotten around to updating my rockbox build (it's been at least a year), and my make is failing. It says "make: *** No rule to make target `/home/mythtv/stuff/sources/rockbox/rockbox/build/id3.h', needed by `/home/mythtv/stuff/sources/rockbox/rockbox/build/apps/bookmark.o'. Stop." Anyone know how to fix this? |
| 15:12:57 | pamaury | yes and no, the mtp-detect tools does it but if your device if know, it won't even probe the descriptor. So I advise you to pick the code of "probe_descriptor" in "usb_glue.c" of libmtp, that just a few lines and it does the job |
| 15:13:02 | pamaury | I have to leave |
| 15:13:11 | gevaerts | ok |
| 15:15:09 | | Quit Horschti ("Verlassend") |
| 15:18:04 | | Join cowgarden [0] (n=qgar10@94.221.226.14) |
| 15:18:32 | | Join Horscht [0] (n=Horscht2@xbmc/user/horscht) |
| 15:18:36 | *** | Saving seen data "./dancer.seen" |
| 15:19:08 | | Quit antil33t (Read error: 131 (Connection reset by peer)) |
| 15:19:21 | | Join antil33t [0] (n=Mudkips@203.184.54.232) |
| 15:23:38 | gevaerts | oblib: is the build directory empty before starting? |
| 15:23:43 | oblib | yep |
| 15:23:54 | | Quit parafin (Read error: 60 (Operation timed out)) |
| 15:25:55 | gevaerts | and the tree is clean? |
| 15:26:44 | oblib | by tree to do you mean the source directories? No, I've just done an svn update and I've got a couple of custom changes |
| 15:27:20 | | Join parafin [0] (i=parafin@paraf.in) |
| 15:27:23 | oblib | If I can't figure it out, I'll do a clean svn directory and add my changes back in, but that's last resort |
| 15:27:50 | gevaerts | there have been a lot of changes during the past year, including a complete overhaul of the makefiles |
| 15:32:24 | | Join Topy [0] (n=Topy44@f048116094.adsl.alicedsl.de) |
| 15:34:23 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 15:34:31 | oblib | Would there be an easy way to just delete all the makefiles. It looks like they mostly end it .make ... |
| 15:35:47 | oblib | s/it/in/ |
| 15:37:55 | | Join SchwarzerRiese [0] (n=kraenk_f@xdsl-78-34-139-212.netcologne.de) |
| 15:38:23 | gevaerts | why? |
| 15:39:18 | oblib | If I got rid of them and then did 'svn update' that could fix the problem without redoing the whole tree |
| 15:39:59 | gevaerts | just run svn revert on them then |
| 15:40:14 | oblib | on just the make files? |
| 15:40:35 | oblib | svn diff doesn't think there are any diffs besides my source changes |
| 15:41:18 | gevaerts | well there most be something relevant that changed |
| 15:42:47 | gevaerts | check if svn stat shows files that shouldn't be there |
| 15:44:42 | | Quit fyre^OS ("lamers envy me like they envy bill g -- main boot xp, just the way it should be!") |
| 15:44:58 | | Join fyrestorm [0] (n=nnscript@cpe-69-203-150-85.si.res.rr.com) |
| 15:46:01 | | Part SchwarzerRiese |
| 15:48:02 | gevaerts | pamaury: usb_control_msg() returns -32 when asking for the extended property descriptor |
| 15:50:40 | | Quit T44 (Read error: 110 (Connection timed out)) |
| 15:51:05 | | Quit hebz0rl (Read error: 104 (Connection reset by peer)) |
| 15:52:10 | | Join pondlife [50] (n=Steve@rockbox/developer/pondlife) |
| 15:53:38 | | Part pondlife |
| 15:55:58 | | Join watto [0] (n=watto@188-221-185-113.zone12.bethere.co.uk) |
| 16:00 |
| 16:01:48 | oblib | svn had skipped over apps/codecs.c codecs.h and playback.c |
| 16:01:59 | oblib | turns out those are sort of important... |
| 16:02:12 | oblib | Thanks for your help gevaerts |
| 16:06:11 | oblib | build completed successfully |
| 16:06:13 | | Quit oblib ("Leaving") |
| 16:09:13 | | Quit bimbel ("Bye!") |
| 16:11:06 | | Join GeekShado_ [0] (n=Antoine@233.98.197-77.rev.gaoland.net) |
| 16:14:15 | | Quit GeekShadow (Read error: 60 (Operation timed out)) |
| 16:14:35 | | Join Thundercloud [0] (i=thunderc@81.187.69.84) |
| 16:18:24 | | Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) |
| 16:24:03 | | Quit GeekShado_ (Read error: 60 (Operation timed out)) |
| 16:39:54 | | Join solexx_ [0] (n=jrschulz@e176118018.adsl.alicedsl.de) |
| 16:41:33 | | Quit solexx (Read error: 60 (Operation timed out)) |
| 16:46:13 | | Quit mc2739 (Read error: 104 (Connection reset by peer)) |
| 16:46:25 | | Join mc2739 [0] (n=mc2739@rockbox/developer/mc2739) |
| 17:00 |
| 17:12:20 | n1s | hmm, no, the trickery in spc is much worse than i thought |
| 17:13:56 | n1s | casting the address of a member of an array to a struct pointer and then doing indexed addressing on that pointer... |
| 17:14:58 | | Quit shai_ ("Leaving") |
| 17:15:25 | | Join shai [0] (n=Shai@l192-117-110-233.cable.actcom.net.il) |
| 17:18:38 | *** | Saving seen data "./dancer.seen" |
| 17:21:27 | | Join flydutch [0] (n=flydutch@host119-166-dynamic.8-87-r.retail.telecomitalia.it) |
| 17:29:39 | n1s | ugh, it's even casting a pointer to an array inside a struct to a struct pointer and does indexedaddressing on that struct pointer. And then accesses this char array as a uin16_t so double aliasing breakages in a single line :) |
| 17:30:06 | n1s | s/dadd/d add/ |
| 17:30:22 | * | gevaerts doesn't loke horror stories at this time of day |
| 17:30:47 | n1s | sorry |
| 17:32:13 | gevaerts | not your fault :) |
| 17:34:05 | | Join stoffel [0] (n=quassel@p57B4DBA9.dip.t-dialin.net) |
| 17:37:44 | | Join toffe82 [0] (n=chatzill@adsl-70-137-198-13.dsl.frs2ca.sbcglobal.net) |
| 17:42:17 | saratoga | so make the ClipV1 unstable and the fuze/e200v2 stable today? |
| 17:43:14 | saratoga | i wonder if the c200v2 now works? |
| 17:43:28 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 17:43:55 | gevaerts | saratoga: how about committing your work first? ;) |
| 17:44:00 | kugel | saratoga: can the fuze wait until the display glitches are sorted out? |
| 17:44:12 | kugel | it just needs bertrik's patch committed |
| 17:45:19 | saratoga | kugel: and the e200v2? |
| 17:45:35 | kugel | I don't know if that one has the glitches too |
| 17:46:12 | saratoga | ok i'll leave both alone for today |
| 17:47:05 | pixelma | saratoga: I tested the 1a patch a bit on my M5 which is coldfire and has an HD (but only playing a single album). Seemed to work fine as far as I could see - I don't use feature like "gather runtime data" which I think caused trouble when there were small bugs in buffering causing disk spinup at every track change (haven't tested for that yet) |
| 17:47:37 | saratoga | pixelma: I've also been running in on my gigabeat F without issue |
| 17:48:05 | saratoga | the only change i'm not sure about is the one in playback.c and blue dude and matsch both seemed to think it was reasonably safe |
| 17:48:14 | gevaerts | If there are issues left, committing now will increase the chances to find them before the next release |
| 17:56:38 | | Join Utchybann [0] (n=lolo@81.56.102.26) |
| 17:57:12 | n1s | hmm, using memcpy seems to be the only way to avoid these warnings in spc without some pretty intrusive changes |
| 17:57:36 | n1s | or maybe creating a big ass union... |
| 17:59:30 | | Quit Grahack (Success) |
| 18:00 |
| 18:00:41 | CIA-80 | New commit by saratoga (r23680): Commit FS #10605 - stable playback on low memory swcodec targets by Matthias Schneider. Should allow stable playback on targets with less then 4MB of ... |
| 18:01:29 | | Join Grahack [0] (n=chri@ACaen-156-1-132-28.w86-220.abo.wanadoo.fr) |
| 18:02:56 | saratoga | does anyone have a c200v2? |
| 18:03:48 | CIA-80 | New commit by saratoga (r23681): Update the website to promote clipv1 from unusable to unstable. |
| 18:05:01 | | Join AlacerFox [0] (i=Fox@ppp121-45-152-213.lns10.adl6.internode.on.net) |
| 18:05:22 | saratoga | Bagder, Zagor: would either of you mind uploading this bootloader for the Clip: http://duke.edu/~mgg6/rockbox/bootloader-clip.sansa and then updating the front page? |
| 18:06:28 | saratoga | wow all that and no binsize increase |
| 18:06:40 | | Join Sajber^ [0] (n=Sajber@c-5a3771d5.012-155-73746f22.cust.bredbandsbolaget.se) |
| 18:07:12 | gevaerts | not even a yellow! |
| 18:07:53 | saratoga | i tested it on the sims and a lot of targets first |
| 18:08:15 | saratoga | i kept expecting it to fail |
| 18:09:29 | | Join funman [0] (n=fun@rockbox/developer/funman) |
| 18:09:53 | saratoga | funman: congrats |
| 18:11:17 | | Join bluebrother^ [0] (n=dom@rockbox/developer/bluebrother) |
| 18:11:25 | kugel | what for? |
| 18:11:54 | saratoga | he basically started the clip port |
| 18:12:16 | saratoga | and now 1.5 years later its basically working |
| 18:13:07 | funman | i think it really started on the clip 1 year before i first browsed the forum |
| 18:13:29 | | Quit Thundercloud (Remote closed the connection) |
| 18:13:38 | funman | i'm just a drop in the ocean, which happened to have a lot of free time at the right point in time |
| 18:13:56 | funman | but i'm very happy it reaches an usable point ;) (just downloaded the current build) |
| 18:14:07 | | Join Blue_Dude [0] (n=chatzill@rockbox/developer/Blue-Dude) |
| 18:14:12 | Blue_Dude | Congratulations! |
| 18:15:17 | kugel | ah yea of course, good work! :) |
| 18:16:09 | funman | ah it reminds me FM radio still doesn't work on the Clip |
| 18:16:19 | gevaerts | funman: you *downloaded* a build? |
| 18:16:36 | | Quit dmb ("Leaving") |
| 18:17:31 | funman | sure, why ? |
| 18:18:08 | funman | i don't work much on rockbox these days, downloading is faster than building from scratch |
| 18:18:18 | gevaerts | I know. Just teasing |
| 18:20:25 | n1s | yay, got rid of the warnings with some amazing union hack :) |
| 18:20:36 | n1s | no idea if it works though :) |
| 18:20:58 | | Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.5.5/20091102152451]") |
| 18:21:10 | funman | by the way it seems there is some similarities between the USB chip used in sansa AMS and the chip used in nano2g |
| 18:21:44 | saratoga | funman: any interest in cleaning up and committing your clipv2 work? |
| 18:22:49 | pamaury | gevaerts: re, on which target(s) did you try it ? |
| 18:23:01 | gevaerts | pamaury: gigabeat S, OF |
| 18:23:18 | funman | saratoga: not sure if it will help someone figure out how to transfer data from SD |
| 18:23:34 | gevaerts | so I guess not implementing those descriptors is fine |
| 18:24:16 | pamaury | yes, I guess the guys of libmtp and gPhoto2 implement it without really testing it. |
| 18:24:21 | saratoga | funman: i realize that but getting the code in svn would still be nice so that it doesn't rot |
| 18:24:38 | saratoga | sooner or later we'll get someone interested |
| 18:24:53 | saratoga | anyway, time for lunch |
| 18:25:23 | Llorean | saratoga: Does the clip require the new bootloader for fixed playback, or just a current build? |
| 18:25:45 | funman | Llorean: jut current build |
| 18:25:50 | AlexP | I'm fixing the manual for the clip install instructions - for the difference between clip and clipv2, is it a case of OF version number to tell the difference? And if so, what are the versions? |
| 18:26:02 | funman | my clip bootloader is r21285 |
| 18:26:34 | funman | AlexP: v1 begin with 01. and v2 with 02. |
| 18:26:47 | AlexP | funman: Thanks |
| 18:28:15 | Llorean | funman: My bootloader is 19385. So a bit older. |
| 18:28:44 | Llorean | Hm |
| 18:28:49 | | Quit DerPapst ("Leaving.") |
| 18:28:49 | funman | Llorean: at some point it was needed to update the bootloader (perhaps when data cache was enabled, not sure), else it would lock up |
| 18:28:51 | Llorean | 19385 doesn't seem to be able to boot a current build. |
| 18:29:04 | Llorean | I guess mine's from before that point. |
| 18:29:16 | funman | oh we'll need a released bootloader and activate rbutil support |
| 18:32:08 | Llorean | saratoga's build a bootloader, I think. |
| 18:32:09 | | Quit cowgarden (Read error: 131 (Connection reset by peer)) |
| 18:32:50 | AlexP | funman: For the AMS Sansas, is the bootloader on "disk" or "flash" (ignoring that the disk is flash) |
| 18:33:36 | funman | it's on flash (not visible on the disk) |
| 18:33:49 | AlexP | cheers |
| 18:36:38 | Llorean | Do clip+ work too, or just the clip for now? |
| 18:36:56 | funman | only clipv1 (clipv2 has lcd/buttons, clip+ nothing) |
| 18:37:39 | Llorean | Oh. I thought I remembered someone having something running on the +. Thanks. |
| 18:37:40 | funman | the sansa ams forum thread will be 2 years old in 8 days :o) |
| 18:38:02 | kugel | it is on flash? I thought it was on the hidden firmware area of the "disk" |
| 18:38:31 | funman | kugel: well the disk is flash :) |
| 18:38:46 | kugel | "ignoring that the disk is flash" still applies |
| 18:39:04 | * | kugel was just following AlexP's convention |
| 18:39:26 | AlexP | Disk in that case then I think |
| 18:39:48 | AlexP | This is for the manual incidently |
| 18:40:00 | AlexP | I assume that the bootloader download location will be bootloader/sandisk-sansa/clip/bootloader-clip.sansa ? |
| 18:40:21 | kugel | we hope so :p |
| 18:40:48 | AlexP | and that mkamsboot on the download server will be updated to deal with it (if it doesn't already)? |
| 18:40:59 | gevaerts | kugel: I'd assume that flash means "an area you can't reach directly from rbutil" in this case |
| 18:41:06 | funman | AlexP: mkamsboot already works |
| 18:41:21 | AlexP | great |
| 18:41:29 | funman | or from a formatting tool / file browser |
| 18:43:04 | AlexP | What is the clip OF .bin called? |
| 18:43:11 | | Join Lss [0] (n=Lss@59.189.92.205) |
| 18:43:28 | Llorean | m300a.bin |
| 18:43:40 | AlexP | ta |
| 18:43:48 | | Quit stoffel (Remote closed the connection) |
| 18:44:12 | | Quit kugel (Read error: 131 (Connection reset by peer)) |
| 18:45:30 | | Quit Omlet (Read error: 113 (No route to host)) |
| 18:47:18 | | Quit Lss (Read error: 131 (Connection reset by peer)) |
| 18:47:27 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 18:48:31 | Llorean | Should http://build.rockbox.org/data/rockbox-clip.zip be an actual current build of Rockbox for clip? |
| 18:52:02 | AlexP | funman: Does rbutil support the clip yet? |
| 18:52:43 | gevaerts | Llorean: http://build.rockbox.org/data/rockbox-sansaclip.zip is the one you want I think |
| 18:52:51 | funman | no |
| 18:52:56 | Llorean | The -clip one should probably be deleted then |
| 18:53:20 | bluebrother^ | AlexP: rbutil has preliminary support for the clip in svn, but it's disabled for releases |
| 18:53:32 | AlexP | OK, cheers |
| 18:53:53 | bluebrother^ | no idea what state that support is in, though. But if mkamsboot is doing the job I'd guess it's pretty much done |
| 18:54:13 | * | bluebrother^ thinks that a target support table on the rbutil wiki page might make sense |
| 18:54:17 | funman | bluebrother^: just like fuze/e200v2, i think only the "disabled" line needs to be removed from rbutil.ini |
| 18:56:10 | funman | and add "(Unstable)" to the model name |
| 18:56:28 | funman | by the way, m200v4 and c200v2 could go into unstable as well (if they are tested) |
| 18:56:29 | Llorean | Am I to understand that in SVN Rockbox you actually have to edit a text file to get numerical volume now because of the SBS stuff? |
| 18:58:03 | kugel | Llorean: no |
| 18:58:10 | CIA-80 | New commit by alex (r23682): Update Sansa Clip install instructions in the manual. |
| 18:58:20 | Llorean | kugel: Where's the setting for it then? |
| 18:58:27 | kugel | theme settings |
| 18:58:53 | kugel | in status/scroll bar settings |
| 18:59:12 | Llorean | Ah, that's where status/scroll bar settings are now. okay. |
| 19:00 |
| 19:00:44 | | Quit GeekShadow (Read error: 131 (Connection reset by peer)) |
| 19:01:24 | Llorean | Thanks |
| 19:02:01 | | Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) |
| 19:02:07 | | Join Omlet [0] (i=omlet05@81.240.107.241) |
| 19:02:38 | | Join kugel__ [0] (n=kugel@e178121045.adsl.alicedsl.de) |
| 19:02:52 | | Quit kugel (Nick collision from services.) |
| 19:02:58 | | Nick kugel__ is now known as kugel (n=kugel@e178121045.adsl.alicedsl.de) |
| 19:04:31 | AlexP | er, the clip doesn't have a recovery mode does it? |
| 19:04:32 | funman | AlexP: well the option HAVE_RB_BL_ON_DISK shouldn't not be used on Sansa AMS |
| 19:04:38 | funman | no it doesn't |
| 19:04:38 | AlexP | eh? |
| 19:04:44 | AlexP | shouldn't not? |
| 19:04:48 | funman | the rockbox bootloader is not on disk |
| 19:05:07 | AlexP | disk here means the drive, not hard disk vs flash disk |
| 19:05:13 | funman | where disk means the mass storage visible over usb |
| 19:05:21 | AlexP | it is on a flash chip then? |
| 19:05:39 | funman | it is on the same flash chip than the mass storage, but it's not visible from USB |
| 19:05:56 | kugel | did someone try if the buffering fix helped on the c200v2? |
| 19:06:25 | CIA-80 | New commit by alex (r23683): The Clip has no recovery mode. |
| 19:06:33 | | Join dmb [0] (n=Dmb@unaffiliated/dmb) |
| 19:07:11 | AlexP | funman: OK, I'll swap it |
| 19:07:21 | funman | hum this option is not clear |
| 19:07:32 | AlexP | It seems a semantic argument to me |
| 19:07:57 | AlexP | funman: If you read the actual text of the manual, is it incorrect? (ignoring what the option is called) |
| 19:07:58 | funman | what's the difference between _ON_DISK and _ON_FLASH ? |
| 19:09:25 | funman | i believe it's incorrect |
| 19:09:55 | funman | it says there is the OF bootloader, which loads the rockbox bootloader, which loads rockbox |
| 19:10:34 | kugel | isn't that technically true? |
| 19:10:47 | funman | the rockbox bootloader loads the OF |
| 19:10:57 | funman | there's no "OF bootloader" |
| 19:11:14 | AlexP | So the very first thing that runs is the RB bootloader? |
| 19:11:20 | AlexP | There is nothing before that? |
| 19:11:23 | kugel | don't we patch the OF to load our bootloader? |
| 19:11:51 | AlexP | I think it should be IN_FLASH anyway |
| 19:12:10 | funman | i think it's closer to reality yes |
| 19:12:34 | AlexP | OK, I'll change that |
| 19:12:36 | funman | \opt{HAVE_RB_BL_IN_FLASH}{Unlike the \playerman{} firmware, which runs |
| 19:12:36 | funman | entirely from flash memory,} |
| 19:12:47 | funman | hm that's true |
| 19:12:56 | AlexP | OK |
| 19:13:07 | kugel | IIRC that's the same procedure as on h100, so it should read what the h100 manual read |
| 19:13:29 | | Join Lss [0] (n=Lss@cm205.delta92.maxonline.com.sg) |
| 19:13:32 | funman | AlexP: hum actually your last commit is wrong |
| 19:13:51 | AlexP | I asked and you said there was no recovery mode |
| 19:13:51 | funman | the *n*opt should include e200v2/clip/fuze because they don't have a recovery mode like e200v1 |
| 19:14:03 | AlexP | oh, woops |
| 19:14:06 | | Join AaronM [0] (n=Aaron@adsl-4-241-124.mem.bellsouth.net) |
| 19:14:06 | funman | yes there is no recovery mode, so clip should be in nopt, like fuze |
| 19:14:14 | | Quit amiconn (Nick collision from services.) |
| 19:14:17 | | Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) |
| 19:14:20 | | Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) |
| 19:14:20 | | Quit pixelma (Nick collision from services.) |
| 19:14:36 | | Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) |
| 19:14:37 | AlexP | SansaAMS in fact |
| 19:14:37 | | Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) |
| 19:15:43 | CIA-80 | New commit by alex (r23684): No SansaAMS have a recovery mode, and set the Rockbox bootloader to be in flash. |
| 19:15:43 | saratoga | i bet the c200v2 works now, but who has one? |
| 19:16:05 | gevaerts | bertrik has one IIRC |
| 19:17:22 | | Join panni_ [0] (i=hannes@ip-95-222-21-143.unitymediagroup.de) |
| 19:18:41 | *** | Saving seen data "./dancer.seen" |
| 19:20:54 | kugel | clip playback works great it seems :) |
| 19:21:05 | saratoga | yeah my playback counter is at 70 hours |
| 19:24:10 | | Quit Lss (Read error: 104 (Connection reset by peer)) |
| 19:31:06 | | Quit funman ("free(random());") |
| 19:34:02 | | Quit flydutch ("/* empty */") |
| 19:41:28 | | Quit toffe82 (Read error: 104 (Connection reset by peer)) |
| 19:41:47 | saratoga | we haven't been updating MajorChanges with recent improvements to the WPS, statusbar, etc |
| 19:42:39 | kugel | browsing and playing music in/from pictureflow on the clip is ... strange :P |
| 19:43:15 | saratoga | should pf be enabled? |
| 19:43:20 | kugel | it is |
| 19:43:38 | gevaerts | why not? |
| 19:43:38 | saratoga | maybe it should be disabled |
| 19:43:40 | bertrik | it looks a bit weird because of the yellow/cyan split, but it does work |
| 19:43:47 | kugel | there was no major improvement in the wps/area, mostly introducing and fixing of small bugs |
| 19:43:55 | gevaerts | saratoga: it's enabled on the archoses... |
| 19:43:58 | saratoga | i thought we had translated strings now |
| 19:44:15 | kugel | that's older an in MajorChanges already |
| 19:44:19 | kugel | and* |
| 19:44:30 | saratoga | oh must have missed it |
| 19:45:47 | pixelma | it even looks better on the Archoses (because of the clip's flickery OLED) |
| 19:46:09 | pixelma | at least that's what I remember from DevCon ;) |
| 19:47:00 | kugel | I seem to remember the same ;) |
| 19:47:53 | | Quit Torne (Read error: 60 (Operation timed out)) |
| 19:48:03 | | Join Torne [0] (i=torne@81.171.46.118) |
| 19:48:58 | saratoga | bertrik: do you have a c200v2? |
| 19:49:13 | bertrik | saratoga, yes |
| 19:49:25 | saratoga | could you try current svn on it and tell me if it works? |
| 19:49:31 | bertrik | ok |
| 19:50:24 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
| 19:54:36 | CIA-80 | New commit by bluebrother (r23685): Use f_frsize when calculating the free disk space from the block count. Fixes wrong value on implementations with f_bsize != f_frsize. |
| 19:55:34 | kugel | bertrik: how about committing the dbop patch (the one before the latest one)? |
| 19:56:17 | kugel | if needed, we can still work on improving it in SVN. but fixing the sporadic lcd glitches makes it worth having in on its own |
| 19:58:44 | | Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) |
| 20:00 |
| 20:00:21 | bertrik | yes, I think we can commit parts of the DBOP stuff |
| 20:01:10 | | Part AlacerFox |
| 20:03:32 | kugel | "parts"? |
| 20:09:10 | | Quit GeekShadow (Read error: 54 (Connection reset by peer)) |
| 20:11:39 | kugel | bertrik: ^ |
| 20:22:59 | | Quit faemir (Read error: 104 (Connection reset by peer)) |
| 20:24:16 | n1s | yay, mod codec aliasing warnings were easy to fix |
| 20:25:19 | saratoga | what are aliasing warnings ? |
| 20:27:20 | saratoga | or i guess more directly why would the compiler need to warn about them |
| 20:28:26 | kugel | I think aliasing is actually illegal as of C99 |
| 20:28:51 | n1s | saratoga: because they prevent the compiler from doing some of it's optimizations (and are not valid C actually) |
| 20:28:52 | Llorean | saratoga: I don't find the Clip keymap too bad for the most part |
| 20:29:11 | kugel | (where aliasing: having different types of pointer pointing to the same address) |
| 20:29:15 | saratoga | Llorean: me neither but i haven't tried the plugins |
| 20:29:48 | | Join Omlet05 [0] (i=omlet05@152.151-200-80.adsl-dyn.isp.belgacom.be) |
| 20:29:52 | Llorean | Ah, might want to specify that you mean the plugins then, so we don't get a flood of "here's how to make it more like the OF" posts. |
| 20:30:56 | saratoga | i added a don |
| 20:31:09 | saratoga | 't talk about the OF clause to the forum rules so that i can just delete those posts :) |
| 20:34:30 | kugel | mc2739: ping |
| 20:34:45 | kugel | saratoga: you have on e200v2 right? |
| 20:34:50 | saratoga | kugel: yes |
| 20:35:34 | saratoga | is the clip radio broken for everyone or only some players? |
| 20:36:17 | | Quit watto (Read error: 60 (Operation timed out)) |
| 20:36:23 | Unhelpful | n1s: you're working on this then? i hadn't started on codecs, and i don't expect much rockbox time until wednesday anyway. |
| 20:36:32 | gevaerts | 18:16 < funman> ah it reminds me FM radio still doesn't work on the Clip |
| 20:36:40 | gevaerts | so I guess all |
| 20:36:51 | | Quit Omlet (Read error: 145 (Connection timed out)) |
| 20:36:55 | saratoga | the wiki page said that they do until i changed it today |
| 20:37:00 | saratoga | so did we break it at some point? |
| 20:37:26 | kugel | no idea, it doesn't work on mine as well |
| 20:37:27 | n1s | Unhelpful: yeah, trying to at least, mod was easy, psc seems fixed but i'm not really sure, looking at mp3_enc now, those were the only ones i got warnings from |
| 20:37:45 | | Quit Omlet05 (Read error: 60 (Operation timed out)) |
| 20:37:46 | n1s | s/psc/spc/ |
| 20:38:45 | kugel | saratoga: can you test fs10603 a bit? the patch from 10 oct, with and without the patch funman uploaded right after? |
| 20:38:49 | kugel | I guess it's out of date though |
| 20:39:10 | kugel | it's in question whether the increased polling rate is actually useful for the e200v2 |
| 20:41:13 | saratoga | kugel: was that file removed? |
| 20:41:41 | kugel | uhm no |
| 20:41:53 | kugel | http://www.rockbox.org/tracker/task/10603#comment32851 |
| 20:41:56 | saratoga | dbop-as3525.c |
| 20:43:05 | kugel | that never existed in svn |
| 20:44:30 | saratoga | sorry wrong oct 10 patch |
| 20:46:28 | kugel | it's probably out of sync |
| 20:46:47 | n1s | Unhelpful: looks like i got the warnings in mp3_enc too so i'll test a bit and probably post a patch tomorrow |
| 20:47:57 | n1s | got them fixed, that is |
| 20:53:32 | saratoga | kugel: it seems to break the wheel unless i synced it badly |
| 20:53:35 | | Join phanboy4 [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net) |
| 20:54:48 | kugel | you mean it doesn't work at all? |
| 20:54:54 | saratoga | kugel: correct |
| 20:55:00 | saratoga | it doesn't even bring the backlight back on |
| 20:55:12 | kugel | I assume you sync'd it badly then :) |
| 20:55:22 | saratoga | well you're welcome to try yourself :) |
| 20:55:36 | saratoga | i just deleted the fuze changes and synced debugmenu by hand |
| 20:56:02 | saratoga | was lcd-fuze.c important? |
| 20:56:21 | kugel | that were the only conflicts? |
| 20:56:29 | saratoga | yes |
| 20:56:37 | kugel | then it really doesn't work |
| 20:57:00 | kugel | I'll try to post a working patch |
| 20:57:08 | saratoga | ok i'll test it when you do |
| 21:00 |
| 21:03:09 | | Join PSPdemon [0] (n=PSPdemon@c-66-177-37-36.hsd1.fl.comcast.net) |
| 21:10:35 | * | B4gder added committer #86 |
| 21:10:47 | gevaerts | \☺/ |
| 21:11:11 | * | petur stares at classic_statusbar.sbs |
| 21:11:47 | petur | JdGordon can fix it himself |
| 21:13:56 | * | bluebroth3r wonders why there's a point in having a separate statusbar anyway |
| 21:14:24 | bluebroth3r | if it's considered a skin then the skin could contain that. Making the statusbar simply a viewport |
| 21:15:04 | gevaerts | bluebroth3r: |
| 21:15:08 | gevaerts | "the skin"? |
| 21:16:37 | bluebroth3r | well, we now have a skin buffer and thus some kind of skin engine, right? |
| 21:16:42 | | Quit linuxstb (Read error: 148 (No route to host)) |
| 21:16:46 | | Nick bluebroth3r is now known as bluebrother (n=dom@rockbox/developer/bluebrother) |
| 21:17:31 | bluebrother | which means we're moving towards full skinnability. At least that's my impression. |
| 21:18:08 | | Join toffe82 [0] (n=chatzill@ppp-71-140-90-88.dsl.frs2ca.pacbell.net) |
| 21:18:44 | *** | Saving seen data "./dancer.seen" |
| 21:18:45 | gevaerts | maybe, but we're a *long* way from that |
| 21:18:54 | PSPdemon | :( |
| 21:19:33 | PSPdemon | i almost want picture flow included in the browser ( as in a view option instead of a demo rock ) |
| 21:20:35 | bluebrother | that's possible, but wouldn't considering the non-wps screens a skin (which currently can only get adjusted in parts, which right now is the statusbar) the first start? |
| 21:21:22 | kugel | saratoga: I hope that one works http://pastie.org/pastes/709141 |
| 21:21:46 | gevaerts | bluebrother: does that differ so much from what's happening? |
| 21:23:24 | kugel | bluebrother: the classic sb is on the way out anyway |
| 21:23:29 | kugel | there's a task about it |
| 21:24:06 | bluebrother | well, it's kinda the other way round: coming from the skin view would mean that we have a skin, which defines two viewports: the statusbar, and a main one (which can't get changed). As far as I understand the current attempt is to add a single viewport that can get changed and is this customizable viewport |
| 21:24:32 | * | bluebrother stresses that he really likes the old statusbar. Just in case JdGordon wonders again if anybody would want to use that at all |
| 21:26:27 | kugel | bluebrother: not a single viewport |
| 21:28:30 | | Join sh90 [0] (i=cpu98@222.108.66.77) |
| 21:28:30 | kugel | what you mean is implemented (too, kind of) |
| 21:32:12 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 21:32:36 | | Quit bertrik ("De groeten") |
| 21:36:39 | | Join Reiska666 [0] (n=reiska66@a91-153-219-249.elisa-laajakaista.fi) |
| 21:37:24 | | Part Reiska666 |
| 21:38:53 | pixelma | petur: I'm looking into making the classic_statusbar.sbs more classic anyways, maybe I spot something about the recording frequencies |
| 21:42:37 | petur | thanks |
| 21:43:30 | petur | I've never liked WPS files and this sbs stuff can go the same way |
| 21:45:39 | Unhelpful | n1s: excellent. i'll look into using the best -O settings from the benchmark runs. armv5 behaved enough like armv6 that i expect i can just treat them the same, and select slighly differently for armv4 |
| 21:46:19 | Unhelpful | though i should probably re-run after your patch to see if strict aliasing interacts differently with different levels |
| 21:46:28 | kugel | you have an armv5? |
| 21:47:08 | Unhelpful | kugel: beaft is, isn't it? i had krazykit run tests. |
| 21:47:23 | kugel | gigabeaft is v4 |
| 21:47:26 | | Quit Horscht ("Verlassend") |
| 21:47:52 | Unhelpful | bah! ok. it behaves *quite* differently from e200. |
| 21:48:03 | Unhelpful | (with regard to -O results) |
| 21:48:08 | kugel | I think only (some of) the telechips are v5 |
| 21:48:46 | kugel | that can have various other reasons, like caches and iram |
| 21:52:46 | n1s | Unhelpful: beaft is arm9 though so it has a different pipeline to the arm7 IIRC even if it's still v4 |
| 21:53:02 | Torne | Yah |
| 21:53:24 | Torne | v4/v5 is not that important, i wouldn't think |
| 21:53:35 | Torne | the changed instructions are generally not something a compiler generates (DSP and the like) |
| 21:53:51 | Torne | the differences ebtween arm7/9/11 will dominate |
| 21:58:28 | | Join Horscht [0] (n=Horscht2@xbmc/user/horscht) |
| 22:00 |
| 22:01:03 | Unhelpful | is the pipeline closer to the beast's arm11 pipeline in some way? the changes for best -O levels for codecs for them are *very* similar. |
| 22:01:21 | Torne | arm9 is more like arm11 than it is like arm7, yes |
| 22:01:27 | saratoga | the gigabeat F chip is the same as the AMS core |
| 22:01:41 | saratoga | 5 stage classic risc with seperate I and D caches |
| 22:01:47 | saratoga | but the same multiplier as ARM7 |
| 22:02:22 | | Join Tomis [0] (n=Tomis@70.134.100.227) |
| 22:02:28 | saratoga | nothing will scale like PP because it has 128KB of actual SRAM built into the core itself and not just hung off some slow peripheral bus |
| 22:02:32 | Torne | ARM9 has branch prediction, which makes a lot of difference :) |
| 22:02:49 | Torne | ARM7 just stalls because it's thick |
| 22:02:58 | saratoga | arm7tdmi has negligible pipelineing which is like good branch prediction only better :) |
| 22:03:20 | | Quit Thundercloud (Remote closed the connection) |
| 22:03:40 | Torne | saratoga: you still get a one stage stall, no? |
| 22:03:53 | Torne | which affects cache |
| 22:04:01 | saratoga | yeah i think its 1 clock worth of stall |
| 22:04:06 | Torne | assuming you have something bizarre like PP which has a cache. |
| 22:04:53 | | Join Tomis2 [0] (n=Tomis@70.134.87.26) |
| 22:04:57 | Torne | it won't be a one *clock* stall unless you are executing from cache :) |
| 22:05:02 | saratoga | kugel: no difference, still no wheel |
| 22:05:31 | kugel | strange |
| 22:06:34 | saratoga | basically nothing will ever be as fast as PP unless it can have a very fast memory system and probably a 1 clock MULL instruction |
| 22:06:57 | saratoga | per clock that is |
| 22:07:23 | saratoga | so probably the TCC chips with SRAM and ARMv5E and the beast if your code sticks in cache well |
| 22:07:57 | Torne | if you were particularly brave you could experiment with writing codecs to use TCM :) |
| 22:08:06 | Torne | instead of relying on cache behaviour |
| 22:08:47 | saratoga | actually some of those TCC chips look fantastic, Coldfire like multiplier performance with PP memory + cache memory and ARM9 clock speeds |
| 22:09:08 | Torne | we already fiddle a bit like that to do iram at all |
| 22:09:19 | saratoga | for which target? |
| 22:09:24 | Torne | on any target, i mean |
| 22:09:32 | Torne | using TCM is the same principle |
| 22:09:38 | Torne | there's just gonna be less |
| 22:09:42 | saratoga | i also always wanted to try one of those ARM7E cores where you get the ARM7TDMI pipeline but the ARMv6 DSP unit |
| 22:10:11 | saratoga | Torne: isn't that what we already do with IRAM? |
| 22:10:21 | Torne | saratoga: ..yes. that's what i said. |
| 22:10:38 | Torne | instead/aswell of using IRAM you could shove code/data into TCM on ARM11 |
| 22:10:54 | Torne | eliminating any dependency on cache behaviour |
| 22:10:57 | saratoga | TCM is the beast's IRAM? |
| 22:11:15 | Torne | no, TCM is when you disable automatic cache management and have the L1 cache available in the memory map |
| 22:11:22 | Torne | to use as regular instruction/data memory |
| 22:11:29 | saratoga | 16KB IIRC? |
| 22:11:37 | Torne | probably |
| 22:11:48 | Torne | you can use both though |
| 22:11:59 | Torne | instruction cache becomes ITCM, data cache becomes DTCM |
| 22:12:15 | saratoga | i doubt its worthwhile for most codecs |
| 22:12:28 | Torne | probably not |
| 22:12:58 | saratoga | it might be useful in mp3 for putting some of the mdct and synthesis coefficients into TCM since they're so small |
| 22:13:01 | Torne | (ITCM is hilarious; memory you can execute but not read) |
| 22:13:21 | saratoga | thats actually really common on DSP systems |
| 22:13:31 | Torne | yah, it just is kinda odd to have on ARM |
| 22:13:33 | saratoga | i think theres better ways to make libmad not suck |
| 22:13:45 | Unhelpful | how best to distingush between arm7 vs arm9+ in the makefile, then? there are actually codecs for which -O3 works better on beast and beaft, and it's pretty much always a huge loser on arm7... |
| 22:13:57 | saratoga | it badly needs a complete code review |
| 22:14:05 | Torne | probably. it's only really worth looking at if you can demonstrate you are being hurt by cache misses |
| 22:14:20 | saratoga | Unhelpful: I would just check for NOT PP |
| 22:14:22 | Torne | which reminds me, do we have the perfctrs on beast? |
| 22:14:43 | Unhelpful | Torne: it has clock and clock/64 counters, which we don't use |
| 22:14:59 | Unhelpful | as well as counters for things like branch prediction misses iirc |
| 22:15:00 | Torne | Unhelpful: ARM11 can count memory accesses, cache misses, etc, i mean. |
| 22:15:01 | Torne | yes |
| 22:15:03 | Torne | that |
| 22:15:15 | Torne | That's very useful for analysis ;) |
| 22:15:34 | Unhelpful | it is, i suppose, but we've only the one arm11 target :/ |
| 22:15:48 | Torne | it's partially there on some ARM9s also |
| 22:15:49 | Unhelpful | ie its optimizations won't be of very broad use |
| 22:15:50 | Torne | just not documented |
| 22:16:09 | CIA-80 | New commit by mc2739 (r23686): FS #10796 - Clip - prevent power switch activation when coming out of hold |
| 22:16:13 | Torne | the ARMv5 debug/perfctr system is *almost* the same as what's in the ARMv6 ARM |
| 22:16:29 | Torne | ARM just weren't ready to commit to it at the time I think, so they left it as a private detail for their debugger |
| 22:17:22 | Unhelpful | even cycle counters can be pretty useful, especially as we have such a low-resolution system timer (for speed benchmarks) |
| 22:17:33 | Torne | that's true. |
| 22:18:24 | saratoga | optimizing most of our targets isn't that hard once you know the DRAM and IRAM access times as well as the latency on the multiplier |
| 22:18:51 | saratoga | it just comes down to load/store/mul as little as possible |
| 22:19:53 | saratoga | that said a plugin for testing mul, DRAM, and IRAM access times in clocks would be very useful |
| 22:20:05 | n1s | Unhelpful: i think TheSeven said the nano4g is arm11 too so we *might* get another one |
| 22:20:37 | saratoga | maybe also for cache associativity and cacheline size |
| 22:20:45 | | Quit Tomis (Connection timed out) |
| 22:20:45 | | Nick Tomis2 is now known as Tomis (n=Tomis@70.134.87.26) |
| 22:21:07 | Torne | cacheline size would be very good to know for sure on some platforms ;) |
| 22:21:27 | saratoga | well its a pretty trivial plugin to write if you're bored :) |
| 22:21:39 | | Quit fdinel (Read error: 104 (Connection reset by peer)) |
| 22:21:44 | saratoga | i once hacked one together for PP but never got around to making it really useful and since lost the code |
| 22:21:53 | Torne | oh? ;) |
| 22:22:03 | Torne | is the cacheline size on pp502x definately 16 bytes? :) |
| 22:22:16 | saratoga | IIRC yes, theres a document from MrH explaining it |
| 22:22:19 | saratoga | he did some extensive testing |
| 22:22:26 | saratoga | or else is one of the PP designers |
| 22:22:34 | Torne | yah, i saw that |
| 22:23:06 | Torne | someone just threw me a bit by claiming that their ipod stopped being unstable with dma when they switched it to 32 |
| 22:23:24 | Torne | but it turned out not to really be reproducible:) |
| 22:23:34 | saratoga | well theres a lot PP revisions floating around, including two different caches, so its possible they changed it at some point |
| 22:23:43 | saratoga | MrH only claimed that for the PP5024 |
| 22:24:43 | Torne | well, i believed it becuase it's fairly typical for arm at that time |
| 22:24:52 | Torne | the XScales all have 16-byte cachelines as well |
| 22:25:11 | mc2739 | kugel: pong |
| 22:25:17 | saratoga | its a pretty obvious size to use given the bus widths and clock speeds |
| 22:25:38 | Torne | yup |
| 22:25:41 | saratoga | for AMS i wonder about the memory, funman's measurements suggested some really odd timings, and we have some ability to tweak the internal clocks |
| 22:26:10 | * | Torne should actually unify ata_{read,write}_sectors and see if that makes his ipod stable |
| 22:26:33 | Torne | i've had the DMA patch on for ages and it *normally* works fine but I can get it to die by doing certain things while the player is maybe being shaken a bit |
| 22:26:37 | saratoga | not to mention theres some differences between the AMS targets using internal DRAM and those using external DRAM |
| 22:26:45 | Torne | which suggests it's probably write failures not being retried that causes it |
| 22:26:50 | Torne | rather than anything wrong with dma |
| 22:26:52 | Torne | but it's hard to prove ;) |
| 22:28:08 | saratoga | do they make line out cables for the gigabeat F that I can order? |
| 22:29:12 | saratoga | or maybe I can use the cables that came with my S on the F? |
| 22:29:38 | gevaerts | my homebuilt F lineout cable didn't work with my S |
| 22:29:57 | gevaerts | that doesn't prove much of course |
| 22:30:22 | saratoga | i've got a bunch of F and S boxes lying around, i should dig through and see if any came with cables |
| 22:31:03 | toffe82 | saratoga: no line out cable available |
| 22:31:20 | saratoga | the internet shows line out cables coming with the S |
| 22:31:41 | toffe82 | ? |
| 22:31:48 | saratoga | http://www.engadget.com/media/2006/06/p1010855.jpg |
| 22:31:51 | toffe82 | through the headphone plug |
| 22:31:58 | * | n1s didn't get one with his S afahr |
| 22:32:08 | gevaerts | saratoga: I believe there's someone who can sell you a compatible connector :) |
| 22:32:27 | saratoga | oh you're right |
| 22:32:35 | saratoga | does anything connect to the dock? |
| 22:32:51 | * | toffe82 try to finish the break out board for the plug , but can't...... |
| 22:33:05 | Torne | hm, my poll is not going so well |
| 22:33:14 | Torne | absolutely nobody has voted for any player other than the Video |
| 22:33:23 | n1s | Torne: ? |
| 22:33:43 | Torne | anyone here have a PP ipod, other than the video, that they use enough to have noticed whether it has the startup bug? :) |
| 22:33:46 | Torne | http://forums.rockbox.org/index.php?topic=23187.0 |
| 22:33:55 | saratoga | did toshiba even make a dock cable? |
| 22:34:22 | Llorean | Torne: I haven't seen it in Rockbox on my Nano, but I *think* I've seen it once when I let the OF sleep long enough to fully shut down. |
| 22:34:30 | kugel | mc2739: we noticed that the dbop doesn't work on the e200v2 anymore (I know the latest one didn't, but the one before also didn't work already= |
| 22:34:42 | Torne | Llorean: that's unfortunately not a data point i can do a lot with ;) |
| 22:35:16 | Llorean | Another useless data point - off the top of my head I only explicitly remember bug reports regarding this problem on 5Gs |
| 22:35:40 | Llorean | I *may* remember one instance of it being reported on a Mini, but I'm not certain. The bug may be exclusive to the PP5021/22 |
| 22:36:00 | toffe82 | saratoga: therei a dock for the F and X but not for the S |
| 22:36:18 | saratoga | toffe82: seen this thing: http://www.toshibadirect.com/td/b2c/adet.to?poid=393209 |
| 22:36:19 | Torne | people on the FS have reported that it happens on 4g color, and on mini |
| 22:36:24 | Torne | and that the workaround fixes it |
| 22:36:28 | saratoga | looks like it has access to the line out pins |
| 22:36:32 | Torne | The workaround is only for 502x anyway |
| 22:36:47 | n1s | Torne: sorry, can't help you there, my only fully working ipod is the nano4g |
| 22:37:04 | Torne | n1s: yah, it's ok. i hoped actual users might respond, and some have, but only for video |
| 22:37:38 | toffe82 | saratoga: the U doesn't have a dock connector, just usb and headphone |
| 22:38:21 | saratoga | toffe82: that device has a dock connector and an AUX in port |
| 22:38:27 | saratoga | presumably the aux in is for the U |
| 22:38:58 | toffe82 | the T doesn't have dock connectoer too |
| 22:40:10 | saratoga | whats actually on the F dock? |
| 22:40:16 | saratoga | just a USB port? |
| 22:40:31 | gevaerts | USB (host and device), line out, and power |
| 22:40:45 | toffe82 | :) |
| 22:41:41 | mc2739 | kugel: dbop_buttons3.patch did not work on e200v2, the last patch I tested before that was dbop_buttons.patch (sync after r22863 by funman) |
| 22:42:17 | saratoga | gevaerts: it has line out??? |
| 22:42:31 | gevaerts | yes |
| 22:42:32 | toffe82 | on the dock yes |
| 22:42:36 | | Quit petur ("Zzzz") |
| 22:42:38 | saratoga | bah thats what i basked before |
| 22:42:51 | toffe82 | no , you ask for a cable :) |
| 22:42:55 | saratoga | HAVE_TAGCACHE is actually for the database |
| 22:43:00 | saratoga | well wire + dock = cable |
| 22:43:07 | saratoga | and wires are easy to find |
| 22:43:09 | toffe82 | there is the line out on the dock connector for the F S and X |
| 22:43:32 | saratoga | sorry, HAVE_TAGCACHE actually enables the database, correct? |
| 22:43:50 | gevaerts | saratoga: well yes, but when I needed a cable, it was because a dock wasn't suitable for that situation :) |
| 22:44:26 | CIA-80 | New commit by mc2739 (r23687): FS #10781 - Scrolling doesn't stop when entering USB screen from WPS |
| 22:54:23 | | Part freqmod_qu ("http://quassel-irc.org - Chat komfortabelt. Hvor som helst.") |
| 22:55:30 | | Quit Grahack ("Leaving.") |
| 22:58:53 | linuxstb | saratoga: Did you tag your Clip bootloader build in SVN? |
| 23:00 |
| 23:00:00 | amiconn | saratoga: Regarding differentiation, there is a specific ARM7TDMI macro |
| 23:00:17 | saratoga | linuxstb: its already tagged in SVN, I just checked it out and compiled |
| 23:00:41 | saratoga | amiconn: ok then thats obviously better then checking for PP |
| 23:01:19 | saratoga | we tagged all the AMS 1.0 bootloaders at the same time, even for the ones that weren't released |
| 23:01:21 | linuxstb | saratoga: Hmm, weird... |
| 23:02:31 | saratoga | on AMS the bootloader does so little its unlikely they'll be a reason to change them soon, at least not until we want to have bootloader USB or else completely rework the clocks |
| 23:03:00 | | Quit bluebrother^ ("Computer has gone to sleep") |
| 23:03:25 | saratoga | actually putting up c200v2 and m200v4 bootloaders now might make sense |
| 23:03:41 | saratoga | save us trouble later |
| 23:04:17 | amiconn | saratoga: CPU_ARM7TDMI to be precise. Check with #ifdef |
| 23:04:45 | saratoga | I suspect Unhelpful will need that more then me |
| 23:04:46 | * | amiconn introduced it for the libdemac predictor |
| 23:04:48 | linuxstb | saratoga: Yes, that's what I meant by weird. If bootloaders are tagged and working, we may as well make them available. |
| 23:04:55 | saratoga | ok i'll compile them |
| 23:05:05 | linuxstb | (even if there are other problems preventing them being "unstable") |
| 23:05:45 | saratoga | the c200v2 is probably ready to be released, we're just waiting on someone to try it and make sure nothing else is broken |
| 23:06:00 | saratoga | the m200v4 apparently has some issues |
| 23:07:36 | kugel | mc2739: not the correct fix IMO |
| 23:07:46 | saratoga | linuxstb: http://duke.edu/~mgg6/rockbox/bootloaders/ |
| 23:08:15 | linuxstb | saratoga: Thanks, but I don't have the power.... |
| 23:08:17 | * | linuxstb pings B4gder |
| 23:08:48 | * | B4gder crawls out of his cave and blinks in the light |
| 23:09:17 | mc2739 | kugel: why? |
| 23:10:02 | | Join bekabug [0] (n=bekabug@internal.etherion.net) |
| 23:10:59 | B4gder | c200v2, clip and m200v4 bootloaders uploaded to the download server |
| 23:11:20 | * | linuxstb pushes B4gder back into the dark |
| 23:11:38 | | Quit bekabug (Client Quit) |
| 23:13:00 | kugel | mc2739: well, clear_display does more than just stop scrolling |
| 23:13:08 | | Part froggyman |
| 23:13:24 | kugel | screen.stop_scroll() does only stop scrolling on the whole screen |
| 23:14:06 | Unhelpful | amiconn: is that macro available in makefiles? that's where i'd be setting the CFLAGS... |
| 23:14:11 | kugel | but nevertheless, I try to "deprecate" stopping scrolling on the whole display. because that also stops scrolling on unrelated screen parts (sbs for example) |
| 23:14:31 | amiconn | Unhelpful: Probably not. It's set in config.h |
| 23:15:25 | mc2739 | kugel: so, if you do not wish to stop scrolling, what other options are available? |
| 23:16:07 | kugel | the prefered way is to call scroll_stop for a certain viewport |
| 23:17:12 | kugel | that only stops scrolling in that viewport, but it has the complication that the passed viewport has to be the one that was active (via lcd_set_viewport()) when puts_scroll() was called |
| 23:17:22 | Unhelpful | i was going to start putting my tuning results into the codecs makefiles. i'll leave existing tunings unchanged on non-ARM targets, and maybe also if we're not using the new gcc, for codecs that already set -O for ARM. |
| 23:17:32 | kugel | furthermore, I think the leaving screen should stop scrolling |
| 23:18:48 | *** | Saving seen data "./dancer.seen" |
| 23:19:11 | Unhelpful | looking at the generated makefiles we have CPU=arm. perhaps we could also define CPU_ARM7TDMI in the makefile when configure is run? |
| 23:20:06 | Unhelpful | what exactly does GCCNUM represent? i can't really see how setting it to 404 for 4.4.2 EABI relates to... anything? |
| 23:20:35 | B4gder | major + minor * 100 |
| 23:20:41 | B4gder | uh, the other way |
| 23:20:42 | amiconn | It represents gcc main version and sub-version |
| 23:20:45 | B4gder | major *100 + minor |
| 23:21:09 | Torne | ata_read_sectors says "wait at least 400ns before writing command and reading status" then has five asm nops. this is slightly worrying. :) |
| 23:21:21 | Torne | is that really okay? :) |
| 23:21:28 | Torne | (also ata_write_sectors *doesn't* have this) :) |
| 23:22:16 | kugel | I assume a udelay(1) would be more appropriate, or is the extra 600ns something to worry about? |
| 23:23:25 | gevaerts | Torne: you mean not all CPUs take the same time to execute a nop? |
| 23:23:26 | Torne | well, i was more worried about hte hfact that this delay is missing in write |
| 23:23:32 | Torne | also that |
| 23:23:32 | Torne | :) |
| 23:23:43 | kugel | 5 nops are 625ns, so it doesn't seem to hurt |
| 23:24:04 | kugel | (assuming 1 nop = 1 cycle) |
| 23:24:08 | amiconn | Then it's very likely not necessary. The 400ns -> 5 nops is from SH1 running at 12MHz |
| 23:24:19 | amiconn | The ata specs should tell you |
| 23:24:41 | kugel | ah no, 62.5 actually |
| 23:25:03 | saratoga | Ba4gder: can you also update the website? |
| 23:25:50 | B4gder | done! |
| 23:27:02 | Torne | spec says writes also should have a 400ns delay, or possibly an entire PIO transfer cycle, dependingon crazy state stuff i don't really understand :) |
| 23:27:34 | Torne | i was gonna go with the assumption that it wouldn't hurt to have writes also wait, but "5 nops" seems a bit arbitrary ;) |
| 23:28:26 | saratoga | B4gder: hmm I screwed up, can you make that say "Clip v1" |
| 23:28:33 | gevaerts | indeed. Better make it 50 :) |
| 23:28:54 | saratoga | or maybe "Clip v1 (not v2 or Clip+)" |
| 23:29:32 | B4gder | ok, me fix |
| 23:29:48 | saratoga | i suppose I should clean up that useful logf to disk patch and commit it |
| 23:30:18 | CIA-80 | New commit by bagder (r23688): clarify which clip |
| 23:30:30 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
| 23:30:56 | | Quit tchan ("WeeChat 0.3.1-dev") |
| 23:31:50 | | Join tchan [0] (n=tchan@lunar-linux/developer/tchan) |
| 23:32:46 | Unhelpful | ah... ok, so i think if there's an existing tuned -O option for arm (and it differs from my and krazykit's benchmark results), i should select based on gccnum. |
| 23:33:05 | linuxstb | B4gder: You seem unsure whether to write "v" or "V"... ;) |
| 23:33:12 | B4gder | hehe, yes I am... |
| 23:33:13 | Unhelpful | i'm working on being able to add a TDMI and an ARM... level? version? to distinguish between 7/9/11 etc |
| 23:33:13 | Ctcp | Ping from gevaerts!n=fg@rockbox/developer/gevaerts |
| 23:33:22 | | Join bekabug [0] (n=bekabug@internal.etherion.net) |
| 23:33:37 | B4gder | but I wasn't the first one I see |
| 23:33:46 | linuxstb | B4gder: Indeed not. There is also "Recorder V2". |
| 23:33:58 | B4gder | and e200 v2 vs Fuze V1 |
| 23:34:20 | Unhelpful | perhaps ARM_CORE would be most descriptive? |
| 23:34:23 | B4gder | a healthy mix! ;-) |
| 23:34:55 | kugel | Unhelpful: how about keeping it simple :) |
| 23:35:09 | Unhelpful | kugel: and that would be? |
| 23:35:16 | kugel | what speed difference are we talking about ? |
| 23:36:25 | | Quit saratoga ("Page closed") |
| 23:36:31 | pixelma | JdGordon: what's the %?Rh tag in the classic_Statusbar.sbs (it looks to me that it could be an "if hwcodec recording tag" but couldn't find it on CustomWPS and you committed an extra sbs for the Archoses) |
| 23:36:59 | Unhelpful | kugel: there's a chart ;) |
| 23:37:53 | kugel | I mean, which codec(s) need another O level on arm7 than on arm9/11? |
| 23:39:28 | Unhelpful | ape, ac3... aache, but that's the same codec as other aac levels, right? |
| 23:39:37 | PSPdemon | why does it seem that my gigabeat s is running better than my sansa e200 >_> |
| 23:39:51 | PSPdemon | oh wait wrong place to say that.... |
| 23:40:04 | * | PSPdemon runs to #rockbox-communitt |
| 23:40:14 | PSPdemon | commmunity* |
| 23:42:41 | | Join saratoga [0] (i=9803c6dd@gateway/web/freenode/x-cdngvbdqeewpovpa) |
| 23:53:49 | saratoga | do we have a graphic for the clip on the download page? |
| 23:55:41 | * | PSPdemon could make one |
| 23:55:43 | Unhelpful | kugel: i think it might be worth adding the mechanism. it's not like every single codec needs to care, the bulk can just be if CPU==ARM and not go any further |
| 23:55:58 | | Join Omlet [0] (i=omlet05@235.29-65-87.adsl-dyn.isp.belgacom.be) |
icon identifies that the person is a core developer (has commit access).