| 00:02:21 | fml | amiconn: OK, thanks! |
| 00:05:37 | | Quit ChickeNES (Quit: Computer has gone to sleep.) |
| 00:18:04 | | Quit liar (Quit: hallowed are the ori!) |
| 00:21:51 | fml | Hrm... I'm stuck with asm. In the func "channels_process_sound_chan_custom" (dsp_arm.S) I'd like to replace the lines 113-114 with an if statement (if x == 0 do something else do something else). But it's in a loop. How would I implement it in the most efficient way? |
| 00:22:31 | fml | I'm trying to implement stereo channel swapping via negative stereo width. |
| 00:25:38 | | Quit wodz (Ping timeout: 260 seconds) |
| 00:28:00 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
| 00:28:25 | | Quit krazykit (Read error: Connection reset by peer) |
| 00:30:45 | pixelma | that still sounds odd to me |
| 00:31:06 | | Join krazykit [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) |
| 00:34:39 | | Quit bertrik (Quit: :tiuQ) |
| 00:34:45 | fml | pixelma: he-he, nice word play :-) |
| 00:35:35 | fml | It would not require an additional setting |
| 00:35:52 | fml | I mostly consider it a programming exercise |
| 00:36:19 | kugel | fml: is x the result of an earler computation? |
| 00:36:42 | kugel | some insns like add can update the flag register according to the result |
| 00:37:50 | kugel | then, if the if case or else case is not too long you can use conditional opcodes (e.g. addeq will only execute if the zero flag is set) |
| 00:38:27 | kugel | but IIRC these still cost a cycle so for long squences a branch might be better |
| 00:39:43 | kugel | those lines are stmia insns, are you sure you want to replace them? |
| 00:41:24 | pixelma | fml: and then you have to run through all the intermediate values to go from +100% to -100% stereo width? |
| 00:42:08 | kugel | btw, I don't see a reason to not use bool in asm. semantics don't change for 1, 8 or 32 bit bools (you just test zero or non-zero) |
| 00:42:37 | kugel | (pointer to bools is a different matter) |
| 00:42:55 | kugel | amiconn: we generate asm_defs.h for these issues IIRC |
| 00:46:26 | fml | kugel: I want to leave the logic as it is now and just store the results swapped at the end if the appropriate flag (a global va) is set |
| 00:47:52 | fml | pixelma: yes, you'd (and me too) have to go through all the values. Another setting would be worse IMO since stereo with already has two settings ("custom width" and the width itself) where it should just have one |
| 00:48:19 | kugel | fml: perhaps it's better to duplicate the function for better speed (and call the appropriate one from C) |
| 00:48:44 | kugel | test_codec can tell |
| 00:51:05 | fml | kugel: maybe. But it would still be a func call more. But the branch would not be in a loop −−> more speed. Hm... |
| 00:51:24 | kugel | a func call more? |
| 00:51:29 | pixelma | fml: I would see channel swapping as a setting above stereo width, in the "Channel Configuration" maybe - together with stereo, mono etc. |
| 00:52:09 | pixelma | *or in the |
| 00:52:46 | kugel | fml: another problem is that you overwrite the flag register which breaks the bgt line below |
| 00:53:10 | fml | that too :-/ |
| 00:54:52 | kugel | http://pastie.org/1848966 could work |
| 00:55:39 | sideral | Does the Wiki have a "watch" function that sends email when a topic was changed? |
| 00:58:45 | | Join L-Strife89 [0] (~Strife89@168.16.236.126) |
| 00:58:59 | fml | kugel: thanks, but I'll better just leave it. pixelma is right in her thoughts about the best placement of the setting, but then it would be a new one −− something I wouldn't want to introduce |
| 01:00 |
| 01:02:11 | Llorean | I'm not sure we need a new setting. |
| 01:02:39 | Llorean | In the place where you choose "Stereo, Mono, Custom" it would make more sense to me "Stereo, Mono, Reversed" and have both Stereo and Reverse respect whatever the width is set at. |
| 01:03:19 | * | Llorean doesn't like that it's entirely non-obvious that stereo width doesn't go into effect until you set another setting. |
| 01:04:00 | fml | Llorean: "Reversed" is also stereo. |
| 01:04:35 | Llorean | This is true, so maybe "Reversed Stereo" |
| 01:04:48 | fml | Yes |
| 01:04:52 | Llorean | I was just thinking it might be a good short way to put it, since I think the "stereo" is still well implied. |
| 01:04:56 | pixelma | that would still mean you have to set a negative stereo width with the downside of the intermediate values |
| 01:05:06 | Llorean | pixelma: No. |
| 01:05:09 | amiconn | What about reversed custom? |
| 01:05:15 | | Quit pamaury (Remote host closed the connection) |
| 01:05:24 | Llorean | If you choose "Reverse" then 100% stereo width is what would be -100% with "custom" now. |
| 01:05:50 | fml | Except that it does not exist yet ;-) |
| 01:05:51 | Llorean | amiconn: That's my point. Drop "custom" entirely and have both "Stereo" and "Reversed" respect the custom setting, with Reversed acting like a -1 multiplier on it (relative to Stereo) |
| 01:06:14 | Llorean | So if you want what we might call -50%, you choose 50% width, "reversed" |
| 01:06:47 | amiconn | Well, "Stereo" is still an optimisation over "Custom" set to 100% |
| 01:06:49 | Llorean | Perhaps "swapped" |
| 01:07:11 | Llorean | amiconn: Would it be possible to special case 100% width to use the optimized path without having to have a separate setting, though? |
| 01:07:17 | amiconn | Also "Custom" set to 0% equals Mono (exepct also with slightly more cpu load) |
| 01:07:47 | amiconn | We could forbid 0% for "Stereo" though |
| 01:08:15 | pixelma | the "custom" as it is now has the advantage of easy enabling or disabling of something else than pure stereo or mono |
| 01:08:16 | fml | amiconn: that could also be optimized internally, i.e. if width=0 then set the function to the mono one. |
| 01:09:03 | fml | amiconn: i.e. at the time when the setting is set, not at the time of the actual dsp processing |
| 01:10:22 | | Quit fml (Remote host closed the connection) |
| 01:10:36 | | Quit sideral (Quit: Leaving.) |
| 01:10:59 | | Join ChickeNES [0] (~ChickeNES@128.135.100.102) |
| 01:34:05 | | Join T44 [0] (~Topy44@f049102130.adsl.alicedsl.de) |
| 01:35:56 | | Quit dfkt_ (Read error: Connection reset by peer) |
| 01:35:56 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 01:37:49 | | Quit Topy44 (Ping timeout: 250 seconds) |
| 01:58:07 | *** | Saving seen data "./dancer.seen" |
| 02:00 |
| 02:11:45 | | Quit L-Strife89 (Quit: Leaving) |
| 02:12:08 | | Join L-Strife89 [0] (~Strife89@168.16.236.126) |
| 02:27:26 | | Quit dfkt (Read error: Connection reset by peer) |
| 02:27:27 | | Join dfkt_ [0] (dfkt@unaffiliated/dfkt) |
| 02:28:23 | | Quit ender` (Quit: That men do not learn very much from the lessons of history is the most important of all the lessons of history. -- Aldous Huxley) |
| 02:31:15 | | Quit n1s (Remote host closed the connection) |
| 02:31:43 | | Quit jordan` (Ping timeout: 246 seconds) |
| 02:37:19 | | Join jordan` [0] (~gromit@ALagny-154-1-26-60.w83-112.abo.wanadoo.fr) |
| 02:53:23 | | Join Evilnick__ [0] (~Evilnick@ool-18bcf602.dyn.optonline.net) |
| 02:57:32 | | Quit Evilnick_ (Ping timeout: 250 seconds) |
| 03:00 |
| 03:02:27 | | Quit simonlnu (Quit: bbialw) |
| 03:04:35 | | Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com) |
| 03:05:38 | | Join leBMD [0] (~chatzilla@67-2-166-138.slkc.qwest.net) |
| 03:06:12 | leBMD | Hey guys, I'm having an issue with my mp3 player |
| 03:06:40 | leBMD | I just updated to 3.8.1 on my fuze v2, and now it's an "unrecognized device" in Windows. |
| 03:07:00 | leBMD | ... |
| 03:07:07 | leBMD | never mind, it's working now |
| 03:07:15 | leBMD | I love it when things fix themselves! XD |
| 03:12:35 | | Quit dfkt_ (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) |
| 03:35:32 | | Quit leBMD (Quit: ChatZilla 0.9.86.1 [Firefox 3.6.15/20110303024726]) |
| 03:41:58 | | Join simonlnu [0] (simon@unaffiliated/simonrvn) |
| 03:46:30 | | Quit L-Strife89 (Ping timeout: 250 seconds) |
| 03:52:37 | | Quit robin0800 (Quit: Leaving) |
| 03:58:08 | *** | Saving seen data "./dancer.seen" |
| 04:00 |
| 04:04:46 | | Join L-Strife89 [0] (~Strife89@168.16.226.187) |
| 04:26:33 | | Quit amiconn (Disconnected by services) |
| 04:26:35 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 04:26:35 | | Quit pixelma (Disconnected by services) |
| 04:26:37 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 04:26:39 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 04:26:43 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 04:27:41 | | Quit BHSPitMonkey (Ping timeout: 246 seconds) |
| 04:29:15 | | Quit Judas_PhD (Quit: This is a quitting message) |
| 04:29:17 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
| 04:33:17 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 04:34:14 | | Join kugel_ [0] (~kugel@rockbox/developer/kugel) |
| 04:35:34 | | Quit kugel (Read error: Operation timed out) |
| 04:37:34 | | Quit GeekShadow (Quit: The cake is a lie !) |
| 04:48:49 | | Join JesusFreak316 [0] (~JesusFrea@pool-173-65-69-98.tampfl.fios.verizon.net) |
| 05:00 |
| 05:03:04 | | Quit Judas_PhD (Quit: This is a quitting message) |
| 05:08:41 | [Saint] | JdGordon: http://forums.rockbox.org/index.php/topic,27874.msg180685.html#msg180685 <−− This might be interesting... |
| 05:08:56 | [Saint] | (more FLAC+iPod Video stuttering issues) |
| 05:19:06 | | Join Rob2222 [0] (~Miranda@p4FFF04DA.dip.t-dialin.net) |
| 05:22:38 | | Quit Rob2223 (Ping timeout: 246 seconds) |
| 05:44:07 | | Quit BHSPitMonkey (Remote host closed the connection) |
| 05:58:11 | *** | Saving seen data "./dancer.seen" |
| 06:00 |
| 06:02:09 | | Join Horschti [0] (~Horscht@xbmc/user/horscht) |
| 06:05:37 | | Quit Horscht (Ping timeout: 240 seconds) |
| 06:10:14 | | Quit yosafbridge (Quit: ERC Version 5.3 (IRC client for Emacs)) |
| 06:11:06 | | Join yosafbridge [0] (~yosafbrid@li125-242.members.linode.com) |
| 06:21:13 | [Saint] | Hmmm...weird. Why is it that Playlist−−>Insert counts up (0~100) when inserting tracks, but Insert Shuffled counts down (100~0)? |
| 06:22:35 | [Saint] | Also, the suggested key to quit (play/pause on iPod) on the splash while inserting tracks seems to be wrong... |
| 06:23:13 | [Saint] | It says Play/Pause to cancel but so far the only thing I've found that cancels it on my Color is Prev |
| 06:23:37 | | Quit shai_ (Ping timeout: 240 seconds) |
| 06:29:10 | | Quit Llorean (Read error: Connection reset by peer) |
| 06:29:22 | | Quit Evilnick__ (Read error: Connection reset by peer) |
| 06:29:38 | | Quit JesusFreak316 (Read error: Connection reset by peer) |
| 06:29:58 | | Join Evilnick__ [0] (~Evilnick@ool-18bcf602.dyn.optonline.net) |
| 06:30:55 | | Join Llorean [0] (~DarkkOne@99-68-45-56.lightspeed.hstntx.sbcglobal.net) |
| 06:31:09 | | Quit Llorean (Changing host) |
| 06:31:09 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
| 06:40:44 | | Quit [Saint] (Quit: I'm only going to Heaven if it feels like Hell, I'm only going to Heaven if it tastes like caramel...) |
| 07:00 |
| 07:00:45 | | Join Horscht [0] (~Horscht@xbmc/user/horscht) |
| 07:03:04 | | Quit Horschti (Ping timeout: 246 seconds) |
| 07:26:16 | | Join Ijon_Tichy [0] (~username@46.115.10.141) |
| 07:58:13 | *** | Saving seen data "./dancer.seen" |
| 08:00 |
| 08:06:17 | | Quit L-Strife89 (Quit: Leaving) |
| 08:12:27 | | Quit wtachi (Quit: &) |
| 08:31:46 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
| 08:49:00 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 09:00 |
| 09:01:52 | | Quit BHSPitMonkey (Remote host closed the connection) |
| 09:10:56 | | Join ChickeNE_ [0] (~ChickeNES@192.5.85.36) |
| 09:11:24 | | Join sideral [0] (~sideral@213.165.85.248) |
| 09:11:24 | | Quit sideral (Changing host) |
| 09:11:24 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
| 09:12:39 | | Quit ChickeNES (Ping timeout: 240 seconds) |
| 09:14:20 | | Join Lizking| [0] (~lizking98@adsl-71-134-235-203.dsl.pltn13.pacbell.net) |
| 09:19:32 | | Join stoffel [0] (~quassel@p57B4A1D9.dip.t-dialin.net) |
| 09:21:45 | Lizking| | does anyone know what microSDCH sizes rockbox supports on a sansa200 v1? |
| 09:22:00 | Lizking| | i tried looking in the manual/wiki, but there doesn't seem to be a straight answer anywhere |
| 09:22:18 | Lizking| | and google searching mostly brings up results from before rockbox supported SDHC at all |
| 09:31:38 | pixelma | if it is a plain SDHC card, why should there be differences depending on its actual capacity? |
| 09:32:35 | bluebroth3r | Rockbox supports SDHC up to 32GiB. |
| 09:32:56 | bluebroth3r | but that is simply because SDHC is specified with a maximum size of 32GiB, not of something implementation specific |
| 09:33:19 | * | bluebroth3r doesn't understand that limitation in the SDHC spec |
| 09:34:44 | Lizking| | oh i see |
| 09:34:56 | Lizking| | when I saw 'MicroSDHC card driver DONE - Functional as of 22 August 2007. Feel free to test various capacities and tell us your results! ' on the wiki |
| 09:35:05 | Lizking| | i took that to mean that some capacities would work but some might not |
| 09:35:09 | | Quit pixelma (Disconnected by services) |
| 09:35:10 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 09:35:22 | | Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) |
| 09:35:32 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 09:35:39 | bluebroth3r | well, cards are different and behave different. |
| 09:35:55 | | Quit amiconn (Disconnected by services) |
| 09:35:55 | Lizking| | that's true |
| 09:35:56 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 09:36:14 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 09:36:33 | bluebroth3r | depending on the speed supported by your card and probably other factors there could be bugs that make one card work and another not work |
| 09:37:14 | bluebroth3r | though I guess that especially the e200v1 shouldn't have such issues anymore since it's almost 4 years now |
| 09:41:41 | Lizking| | hmm |
| 09:41:44 | Lizking| | well, thanks |
| 09:41:57 | Lizking| | I guess I'll order a 32GB card and hope for the best |
| 09:42:24 | Lizking| | I didn't expect to fill up the 4GB player mem + 8GB SDHC I had laying around so fast |
| 09:42:32 | Lizking| | even without lossless formats |
| 09:42:45 | | Part Lizking| |
| 09:52:36 | | Quit amiconn (Remote host closed the connection) |
| 09:52:37 | | Quit pixelma (Read error: Connection reset by peer) |
| 09:55:04 | | Join amiconn [0] (quassel@rockbox/developer/amiconn) |
| 09:55:26 | | Join pixelma [0] (quassel@rockbox/staff/pixelma) |
| 09:58:17 | *** | Saving seen data "./dancer.seen" |
| 10:00 |
| 10:05:01 | | Quit sideral (Quit: Leaving.) |
| 10:10:20 | | Quit factor (Ping timeout: 258 seconds) |
| 10:11:23 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 10:13:42 | | Join sideral [0] (~sideral@213.165.85.248) |
| 10:13:42 | | Quit sideral (Changing host) |
| 10:13:42 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
| 10:16:26 | | Quit sideral (Client Quit) |
| 10:34:46 | | Join TheLemonMan [0] (~lem0n@ppp-237-129.98-62.inwind.it) |
| 10:41:19 | * | bertrik wonders what to think of http://www.rockbox.org/tracker/task/12036 |
| 10:41:26 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 10:46:49 | | Nick kugel_ is now known as kugel (~kugel@rockbox/developer/kugel) |
| 10:53:16 | | Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) |
| 10:53:51 | bluebroth3r | I agree that the current categories are a bit inconsistent. Either have a category for each player or make player "groups" with the SoC / CPU / whatever |
| 10:54:52 | | Quit antil33t (Client Quit) |
| 10:54:52 | bluebroth3r | but I see drawbacks for both those attempts. Optimally we would have some player field that allows selecting multiple players. Then we could easily have a task assigned to like fuze and e200 but not c200 |
| 10:55:00 | bluebroth3r | (assuming such a case does happen) |
| 10:55:32 | bluebroth3r | or have the reporter report it for his player and add the others later to the list after someone confirmed that it's specific to maybe the SoC and not the specific player |
| 10:56:03 | | Join pamaury [0] (~quassel@cez63-2-88-164-98-172.fbx.proxad.net) |
| 10:56:03 | | Quit pamaury (Changing host) |
| 10:56:03 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 10:58:10 | Llorean | bluebroth3r: Yeah, I feel similarly. In some cases it makes a lot of sense to generalize on a player category, but it'd be nice to have a way for them to specify the player too in an easily sortable way. |
| 10:58:33 | bluebroth3r | maybe this is something to discuss at DevCon? |
| 10:58:56 | | Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) |
| 10:59:00 | Llorean | I'm guessing it's more a limitation of flyspray than anything? |
| 10:59:17 | bluebroth3r | don't know. Haven't looked into FS development since ages. |
| 10:59:30 | Llorean | I would bet that if someone was willing to put in the work, nobody would really object to player categories, with a sub-field of specific player. |
| 10:59:45 | bluebroth3r | Though there is another thing I'd like to see: markup support in FS. This is supported by FS itself, it just has to be turned on |
| 11:00 |
| 11:00:45 | bluebroth3r | hmm, last official release is 2 years old? :/ |
| 11:15:59 | CIA-87 | New commit by bertrik (r29796): FS #12085 - Correction of iap.c to avoid sending useless data to an accessory, and allow larger playlists names, by Ophir Lojkine |
| 11:16:51 | | Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) |
| 11:19:22 | bertrik | hi wodz, you pinged me? |
| 11:20:18 | pamaury | the IRC page on the website doesn't list the 28 and 29 of april |
| 11:20:25 | CIA-87 | r29796 build result: All green |
| 11:20:45 | bertrik | pamaury, it does for me |
| 11:21:12 | | Quit GodEater (Ping timeout: 248 seconds) |
| 11:21:19 | bluebroth3r | pamaury: for me as well |
| 11:21:37 | pamaury | him you right, my browser used his cache even after refreshing the page :-/ |
| 11:27:36 | | Quit stoffel (Ping timeout: 248 seconds) |
| 11:30:41 | | Join Jerom1 [0] (~jerome@95.171.148.84) |
| 11:31:25 | | Join DerPapst [0] (~Alexander@p57916828.dip.t-dialin.net) |
| 11:34:10 | | Join GodEater [0] (~bibble@5ad61f62.bb.sky.com) |
| 11:34:10 | | Quit GodEater (Changing host) |
| 11:34:10 | | Join GodEater [0] (~bibble@rockbox/staff/GodEater) |
| 11:36:42 | | Join Peddy [0] (~apc@unaffiliated/peddy) |
| 11:37:12 | Peddy | what file in ~/.rockbox does the rockbox bootlogo compile to? |
| 11:39:03 | bluebroth3r | the logo isn't in /.rockbox |
| 11:39:44 | Peddy | oh? I mean the logo that is presented after the bootlogo (by default they're the same) |
| 11:40:13 | bluebroth3r | then I don't know what you mean. There is no logo displayed after startup |
| 11:40:51 | bluebroth3r | the default theme has a backdrop that includes a grey "Rockbox" text but that's not exactly the Rockbox logo ... |
| 11:41:25 | Peddy | OK, the logo that initially appears is part of the bootloader, right? |
| 11:41:40 | bertrik | bluebroth3r, when turning on my clip+, I see a logo + bootloader version, then a logo + rockbox version |
| 11:42:10 | | Join Stummi [0] (~Stummi@rockbox/developer/Stummi) |
| 11:42:14 | Peddy | bertrik, yeah, that's the one I'm referring to. One is stored in bootloader, and one is stored in ~/.rockbox somewhere |
| 11:42:29 | pixelma | then someone decided to put on logo in the bootloader |
| 11:42:36 | pixelma | one logo |
| 11:42:41 | bertrik | Peddy, it could be compiled into the main rockbox firmware file |
| 11:43:10 | Peddy | bertrik, is that entitled rockbox.sansa (for sansa)? |
| 11:43:13 | pixelma | on all my targets the bootloader version info is just presented as simple text |
| 11:43:23 | bertrik | Peddy, yes. |
| 11:43:42 | pixelma | depends on your Sansa... |
| 11:43:42 | bertrik | I think Peddy is right, running the sansa file also shows the logo |
| 11:43:53 | Peddy | bertrik, thank you. I'll have a look at it now and report back |
| 11:44:19 | bluebroth3r | rockbox.sansa is the firmware file |
| 11:45:06 | bluebroth3r | the backdrop is depending on the theme. For cabbie it's /.rockbox/backgrops/cabbiev2.bmp |
| 11:45:43 | bertrik | What does the backdrop have to do with this? the logo is shown once at startup of the .sansa file |
| 11:45:50 | pixelma | the portalplayer ones use rockbox.mi4 |
| 11:46:05 | Peddy | bluebroth3r, that's right, I'm only concerned about boot logo, not backdrop right now :) |
| 11:46:29 | bluebroth3r | bertrik: it still isn't clear to me if Peddy was after the backdrop or the logo during bootup. I _thought_ he's after the backdrop |
| 11:47:10 | bluebroth3r | but what's the point in changing the boot logo? You see both (but usually don't notice the switch between bootloader and Rockbox) so you would need to change it in two places. |
| 11:47:53 | Peddy | bluebroth3r, I want a different logo for fun, and it must be both compiled into rockbox.sansa and the bootloader for uniformity |
| 11:48:12 | bluebroth3r | well, yes. |
| 11:48:38 | Peddy | is it necessary to run rockboxdev.sh and configure again, after making changes to source code? or can I just make? |
| 11:48:55 | bluebroth3r | if you have set up the toolchain you don't need to build that again. |
| 11:49:02 | bertrik | just can just make |
| 11:49:05 | bluebroth3r | but you need to build it at least once ;-) |
| 11:49:18 | Peddy | thanks :) |
| 11:49:23 | bluebroth3r | (preferrably by using rockboxdev.sh but you can also build it yourself) |
| 11:50:50 | Peddy | for some reason rockbox.sansa isn't present in the rockbox.zip I compile? why could this be? |
| 11:51:10 | bluebroth3r | it should be present, below .rockbox |
| 11:51:26 | bluebroth3r | did you make && make zip? |
| 11:51:57 | Peddy | below .rockbox, as in above it, or inside it? |
| 11:52:07 | Peddy | yeah, I did :/ everything else seems to be present |
| 11:52:11 | bluebroth3r | path in the zip file is .rockbox/rockbox.sansa |
| 11:52:28 | Peddy | yeah, it's definitely not there. bizarre. I will configure again |
| 11:52:36 | bertrik | You're probably just overlooking it |
| 11:52:43 | | Quit ender` (Quit: The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.) |
| 11:52:44 | Peddy | (takes ages on my machine, which is why I didn't do it in the first place) |
| 11:52:46 | bluebroth3r | what player are you using? It's rockbox.mi4 on e200v1 |
| 11:52:54 | Peddy | sansa fuze |
| 11:53:03 | Peddy | it's present on the device itself, I can see it now, but |
| 11:53:09 | bluebroth3r | hmm, not sure about the fuze |
| 11:53:13 | Peddy | not in the build folder |
| 11:53:20 | Peddy | yeah, it's entitled rockbox.sansa |
| 11:53:24 | bluebroth3r | in any case you should see a file rockbox.<something> :) |
| 11:53:37 | Peddy | rockbox-info.txt |
| 11:53:42 | Peddy | and |
| 11:53:42 | Peddy | bootloader-fuzev2.sansa |
| 11:54:16 | Peddy | I did make clean |
| 11:54:26 | bertrik | I suggest to use two separate build directories for the normal and the bootloader build |
| 11:54:54 | Peddy | oh man, you're right :/ when i was "making" the makefile was configured for the bootloader |
| 11:54:55 | bluebroth3r | you _usually_ don't need to do that when changing the code. |
| 11:54:56 | | Quit Buganini (Read error: Operation timed out) |
| 11:55:03 | Peddy | not the normal build |
| 11:55:04 | Peddy | thanks! |
| 11:55:20 | bluebroth3r | I strongly suggest separate build directories. I have a whole bunch of them ;-) |
| 11:56:27 | Peddy | thanks all :) rockbox community is best community |
| 11:58:20 | *** | Saving seen data "./dancer.seen" |
| 12:00 |
| 12:01:48 | Peddy | my laptop doubles as a pizza reheating device, when compiling! |
| 12:03:58 | | Join Buganini [0] (~buganini@2001:288:c237:0:dead:beef:cafe:babe) |
| 12:04:53 | * | bertrik considers rewriting iap_getc as a proper finite state machine, so iap large packets can be supported more easily |
| 12:09:23 | bertrik | I'm not really sure whether to use a uint32_t or an unsigned long when I want to do something with a 32-bit unsigned number |
| 12:09:54 | pamaury | that doesn't make any difference |
| 12:10:02 | bertrik | I'd like to use uint32_t, but just using unsigned long appears to be very common in rockbox code |
| 12:10:04 | pamaury | the day we'll have a 64-bit DAP, we are dead :) |
| 12:10:33 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
| 12:10:42 | pamaury | I would say uint32_t is much nicer |
| 12:14:26 | kugelp | pamaury: i don't think we would be dead. all the generic code runs on 64bit already |
| 12:14:51 | pamaury | the problem is about types |
| 12:15:26 | kugelp | whether long is 64bit or not |
| 12:16:35 | pamaury | anyway, a 64-biy DAP is not for tomorrow :) |
| 12:18:17 | | Quit Utchy (Ping timeout: 276 seconds) |
| 12:18:54 | | Join Utchy [0] (~Utchy@rps6752.ovh.net) |
| 12:20:08 | | Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 12:36:03 | bertrik | working on iap is a bit tricky because much of it seems to have been written without any specification at all, so it might break easily ... |
| 12:40:11 | CIA-87 | New commit by bertrik (r29797): iap: update handling of IdentifyDeviceLingoes command and fix RF tuner detection code |
| 12:43:12 | CIA-87 | r29797 build result: 18 errors, 50 warnings (bertrik committed) |
| 12:46:08 | bertrik | amiconn, there's something weird with your build client |
| 12:53:14 | | Join Lear [0] (chatzilla@141.191.216.81.static.g-hn.siw.siwnet.net) |
| 12:54:13 | | Join DerPapst1 [0] (~Alexander@p57954670.dip.t-dialin.net) |
| 12:54:31 | amiconn | bertrik: Perhaps it's the new gcc triggering a few extra warnings? |
| 12:55:22 | amiconn | The red lines must be an interpretation problem of the colouring script |
| 12:55:33 | | Quit DerPapst (Ping timeout: 240 seconds) |
| 12:56:46 | * | amiconn wonders whether the sdl application compiles for mingw these days |
| 13:00 |
| 13:00:45 | CIA-87 | New commit by learman (r29798): Don't (partially) apply changes to max entries in the file browser immediately. The setting affects a buffer that is allocated during boot, so code ... |
| 13:04:45 | CIA-87 | r29798 build result: 18 errors, 50 warnings (learman committed) |
| 13:04:56 | Lear | Woops... :/ |
| 13:05:51 | Lear | Ah, not my stuff. |
| 13:06:16 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 13:08:07 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 13:10:58 | Lear | Btw, are manuals rebuilt daily? |
| 13:11:53 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 13:13:13 | amiconn | Afaik they are |
| 13:18:51 | | Join stoffel [0] (~quassel@p57B4A1D9.dip.t-dialin.net) |
| 13:21:37 | | Quit wodz (Read error: Operation timed out) |
| 13:41:52 | | Join user890104 [0] (~Venci@2001:0:5ef5:79fd:2048:19e4:2b16:10ec) |
| 13:42:33 | | Join sideral [0] (~sideral@213.165.85.248) |
| 13:42:33 | | Quit sideral (Changing host) |
| 13:42:33 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
| 13:51:09 | | Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) |
| 13:54:31 | | Join silbo [0] (~quassel@193.40.244.204) |
| 13:58:23 | *** | Saving seen data "./dancer.seen" |
| 13:58:24 | | Quit liar (Ping timeout: 258 seconds) |
| 13:59:05 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 14:00 |
| 14:04:25 | | Quit stoffel (Ping timeout: 276 seconds) |
| 14:07:33 | | Join user890104_ [0] (~Venci@2001:0:5ef5:73b8:10f4:3a4f:2b16:10ec) |
| 14:08:45 | | Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) |
| 14:09:13 | | Quit Lear (Quit: ChatZilla 0.9.86.1 [Firefox 4.0.1/20110413222027]) |
| 14:10:07 | | Quit user890104 (Disconnected by services) |
| 14:10:16 | | Quit user890104_ (Client Quit) |
| 14:10:22 | | Join user890104 [0] (Venci@venci-notebook-lan.ipv6.6bez10.info) |
| 14:13:48 | wodz | bertrik: ping |
| 14:18:14 | | Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) |
| 14:40:20 | | Join factor [0] (~factor@r74-195-188-223.msk1cmtc01.mskgok.ok.dh.suddenlink.net) |
| 14:51:43 | | Quit factor (Read error: Connection reset by peer) |
| 14:52:15 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 14:54:33 | | Quit Peddy (Ping timeout: 252 seconds) |
| 15:00 |
| 15:05:09 | | Join Highlander [0] (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) |
| 15:07:20 | | Quit Highlander (Client Quit) |
| 15:09:52 | | Join factor [0] (~factor@r74-195-188-223.msk1cmtc01.mskgok.ok.dh.suddenlink.net) |
| 15:19:18 | | Quit krazykit (Remote host closed the connection) |
| 15:25:37 | | Quit merbanan (Ping timeout: 240 seconds) |
| 15:29:56 | | Join wakko222 [0] (~wakko222@175.sub-97-185-134.myvzw.com) |
| 15:34:33 | | Quit wodz (Quit: Leaving) |
| 15:42:00 | wakko222 | Sansa Fuze v2, Current Rockbox stable. I can't seem to play speex files. I select the file, choose play and it jumps past all of my speex files to the next playable file. Any ideas? |
| 15:43:49 | JdGordon | only speex? |
| 15:45:14 | wakko222 | not sure, mp3, flac, and ogg work fine. Only speex gives me this problem. The format of the speex files say they are ogg/speex. |
| 15:49:50 | wakko222 | Never mind, i downloaded the speex files again, copied them over and they play now. Don't know why they didn't before as I could play them on my computer |
| 15:50:31 | | Part wakko222 ("Leaving") |
| 15:53:14 | | Join slooopy [0] (~sloo@95-90-30-123-dynip.superkabel.de) |
| 15:53:49 | jhMikeS | speex could be a bit dodgey right now after updating the way codecs work but then that doesn't do a good job explaining what just happened :\ |
| 15:56:01 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 15:56:54 | jhMikeS | it was a bit of an awkward codec to change over |
| 15:58:25 | *** | Saving seen data "./dancer.seen" |
| 15:59:49 | * | jhMikeS looking at it again wonders if he actually forgot to finish up with that...I mean, look at line 569 in speex.c...wtf? lol |
| 16:00 |
| 16:01:14 | | Join FoH [0] (~foh@98.83.123.68) |
| 16:02:11 | bertrik | hm, yes, that needs a comment :) /* make really sure */ |
| 16:02:51 | jhMikeS | 'tis paranoia run amok! |
| 16:04:44 | FoH | Power returned at 2:21 CDT. |
| 16:15:26 | * | jhMikeS definitely overlooked it. it never sets the return to CODEC_OK. :p |
| 16:16:03 | jhMikeS | not the the engine cares anymore...codec "failure" just treats it like a skip |
| 16:23:51 | | Join drguildo [0] (drguildo@lolwat.drguildo.com) |
| 16:24:56 | drguildo | when i plug my sansa clip+ in to my pc, it doesn't appear as a drive unless it's first turned off first (and that seems to be because it seems to somehow activate the original firmware). does anyone know why? |
| 16:27:37 | sideral | drguildo: It's a known issue, check out http://www.rockbox.org/wiki/SansaAMS#AMSv2_issues_40Fuzev2_44_Clipv2_44_Clip_43_41: |
| 16:28:15 | drguildo | erm |
| 16:28:20 | drguildo | isn't that a "critical bug"? |
| 16:29:34 | drguildo | that release builds aren't meant to have |
| 16:29:39 | sideral | No. OF USB remains fully functional |
| 16:30:43 | drguildo | oh ok |
| 16:30:48 | drguildo | thanks for your help |
| 16:30:51 | drguildo | bye |
| 16:30:57 | | Quit drguildo () |
| 16:35:19 | | Quit Jerom1 (Quit: Leaving.) |
| 16:38:06 | amiconn | jhMikeS: Do you have an idea why pictureflow on CF produces various graphical artifacts? (iirc you implemented the image scaler) |
| 16:38:53 | amiconn | Maybe it has to do with the new gcc - I didn't check yet whether it uses emac itself (which would mean we have to check and adapt all coldfire asm...) |
| 16:41:03 | amiconn | Actually one of the glitches also affects ARM. It's related to scaling jpeg with saturated colours |
| 16:41:22 | bertrik | I thought Unhelpful did the jpeg scaling thing |
| 16:41:25 | jhMikeS | amiconn: no idea. I didn't implement the image scaler either. (who said that?) |
| 16:41:39 | amiconn | Then I did not rc... |
| 16:42:07 | jhMikeS | there are bugs in eabi with armv4 |
| 16:42:27 | jhMikeS | playback.c makes note of one that I should probably report |
| 16:42:28 | amiconn | The saturated colour glitch affects all (colour) targets |
| 16:42:36 | amiconn | Seeing it right now on the beast |
| 16:42:58 | jhMikeS | I haven't witnessed anything myself |
| 16:43:05 | bertrik | can you reproduce it on a sim? |
| 16:43:19 | amiconn | I should probably try |
| 16:43:59 | amiconn | The cover in question is mainly yellow. Luminance is kept properly, but colour becomes complementary (cyan) |
| 16:44:05 | jhMikeS | I did do some YUV stuff for the jpeg viewer long, long ago but don't know if they're in any way connected to each other like that |
| 16:44:12 | amiconn | That suggests an overflow of some sort |
| 16:44:22 | | Quit silbo (Remote host closed the connection) |
| 16:45:39 | amiconn | Hmm, in another size it becomes magenta - and it also happens in the image viewer |
| 16:46:46 | | Quit antil33t (Read error: Connection reset by peer) |
| 16:46:59 | | Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) |
| 16:49:55 | amiconn | It also happens in the sim, but not with any pc-based viewer I tried (windows image viewer, irfan view, ms paint, gimp) |
| 16:50:23 | jhMikeS | does it happen with the various halftonings too? |
| 16:50:40 | amiconn | ? |
| 16:51:20 | jhMikeS | the dither set to off, ordered or diffusion |
| 16:51:35 | amiconn | Since it affects all architectures (including sim) and all zoom levels, I guess the problem is in our jpeg decoder itself |
| 16:51:40 | amiconn | What dither? |
| 16:51:47 | | Quit sideral (Quit: Leaving.) |
| 16:51:48 | jhMikeS | in the image viewer |
| 16:52:48 | amiconn | Oh, didn't even know that option... |
| 16:54:21 | amiconn | Yes it happens with all of them, but "diffusion" looks worse than the other (as if the pixels which should alternate between similar colours use quite different colours) |
| 16:54:25 | * | jhMikeS sort of wonders why he made it an option (except diffusion is a bit slower) |
| 16:55:05 | jhMikeS | I guess it might oscillate strangely if the colors aren't right |
| 16:55:31 | jhMikeS | how about grayscale only view? |
| 16:58:35 | amiconn | That's mostly okay, but in the large version of the image the first macroblock row has a different brightness |
| 16:59:25 | amiconn | Greyscale mode has a bug on its own that which I just noticed: it only works with dithering (ordered or diffusion). If dithering is off and greyscale is on, you get a black screen |
| 17:00 |
| 17:00:31 | jhMikeS | one file that Buschel supplied has album art that bombs in the middle of decoding (and leaves the remaining blocks as a solid color) but displays fine elewhere |
| 17:01:54 | jhMikeS | amiconn: hmmm...pretty sure that worked fine before :\ |
| 17:02:18 | amiconn | I have several other album art images which look quite broken on CF now, but only one that decodes with wrong colours on all rockbox architectures |
| 17:02:56 | amiconn | The CF specific decoding problem seems to be new, the false-colour problem is long standing |
| 17:03:27 | pixelma | jhMikeS: I think I heard the "resume starts from beginning of track instead of the actual resume point" listening to flac on my M5 but it seems I can't reproduce but while trying to I notice that there are short disk accesses shortly before and after track changes even though no rebuffering is happening if I believe the "view buffering thread" screen. I have to admit though that this is only what my WPS is showing me using the virtual LED tag since |
| 17:03:27 | pixelma | my M5 got an SSD... |
| 17:03:32 | jhMikeS | yep, totally black if Y only, no dither :\ |
| 17:04:12 | amiconn | The false-colour image is actually a synthetic image. I know that's not the content jpeg is intended for, but it compresses very well without noticeable artifacts |
| 17:04:39 | amiconn | 1400x1400 pixels in just 50 KB |
| 17:05:44 | | Quit GeekShadow (Remote host closed the connection) |
| 17:05:47 | jhMikeS | pixelma: is that something that has been happening with flac? |
| 17:07:53 | pixelma | testing with flac, yes. If you want to know if this was happening with the old playback engine... I have no idea |
| 17:09:06 | | Quit antil33t (Read error: Connection reset by peer) |
| 17:09:12 | pixelma | hmm, seems "gather runtime data" is enabled and I remember similar bugs with that before. I didn't even remember, I probably enabled it for testing purposes |
| 17:09:16 | | Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) |
| 17:10:24 | jhMikeS | you're more than 15 seconds into the file? |
| 17:10:56 | * | pixelma hates the current wasteful text viewer, wasting a full line between text and page number |
| 17:11:23 | | Join ChickeNES [0] (~ChickeNES@128.135.100.102) |
| 17:11:40 | jhMikeS | it appears that should affect resume without autoresume though |
| 17:11:45 | jhMikeS | *shouldn't |
| 17:11:59 | pixelma | jhMikeS: it happens on every track change if I just listen |
| 17:12:59 | pixelma | no matter when a rebuffer happened even if it was just a few seconds before the track change |
| 17:13:36 | | Quit ChickeNE_ (Read error: Operation timed out) |
| 17:13:52 | jhMikeS | this is with autoresume? I'd expect them to start at the begginning normally, not resume |
| 17:14:23 | pixelma | autoresume is disabled |
| 17:14:35 | pixelma | and I don't follow |
| 17:15:13 | jhMikeS | if you're just letting them play, they should start at the beginng, if you mean "resume playback", then only the first should resume |
| 17:15:26 | pixelma | my question was more about the disk access since I can't reproduce the resume bug at will |
| 17:15:44 | pixelma | huh? |
| 17:15:54 | jhMikeS | you said, "resume starts from beginning of track instead of the actual resume point" |
| 17:16:28 | pixelma | I mean resuming in the sense of "stop playback" and resume later by chosing "Now playing" or the resume button |
| 17:16:33 | jhMikeS | ok, subject changed and I failed to notice :) |
| 17:17:04 | pixelma | nothing with autoresume, just the "normal" manual resume |
| 17:17:12 | jhMikeS | ok |
| 17:17:34 | jhMikeS | you're wondering about "mysterious disk access" |
| 17:18:08 | pixelma | yes, about disk accessses right before and after the track change even when not necessary for buffering |
| 17:19:15 | pixelma | stupid text viewer even wastes a line at the bottom if I turn the footer off :\ |
| 17:21:17 | jhMikeS | there are a number of possibilities that come to mind right off the top of my head 1) I hope it's not reloading the codec when it shouldn't have to 2) buffering didn't actually finish buffering the data it should have 3) one track fills to an incomplete load of the next track |
| 17:22:37 | pixelma | jhMikeS: the disk access might have to do with "gather runtime data" though it shouldn't spin up the disk just for this and just use the next spinup but I remember bugs like this creeping in a few times for this. And I really can't tell you if it was there before the new playback engine |
| 17:22:53 | jhMikeS | 3) is easy to see, since the handle count will run short (you expect 6 handles for two tracks but only get 5, for instance) until the next track starts |
| 17:23:37 | jhMikeS | disk access happens with autoresume too (every time it switches tracks) |
| 17:24:02 | pixelma | that's turned off |
| 17:24:15 | jhMikeS | right, but maybe it does that same for runtime gathering |
| 17:24:30 | pixelma | maybe |
| 17:24:55 | pixelma | I thought it shouldn't though |
| 17:25:10 | jhMikeS | all those tagcache_update_numeric calls in tagtree_track_finish_event might just write trought to disk |
| 17:25:53 | jhMikeS | runtime and autoresume are both handled in that spot |
| 17:26:55 | pixelma | watching the buffering screen didn't show something interesting it seems, usefl just empties till the watermark and then gets refilled. Since the M5 only has 16MB RAM (and actually less) there aren't many tracks and handles involved while using flac... |
| 17:29:05 | pixelma | isn't writing on each track change undesirable on HD targets? |
| 17:31:47 | jhMikeS | indeed, but it seem the tagcache_update_numeric calls tend to do that |
| 17:35:13 | pixelma | jhMikeS: yes, disabling "gather runtime data" made the disk accesses go away |
| 17:35:53 | bertrik | maybe it should do that in the ata idle callback |
| 17:36:16 | pixelma | so it probably doesn't have to do with the new playback engine |
| 17:37:37 | | Quit Judas_PhD (Quit: This is a quitting message) |
| 17:38:18 | pixelma | bertrik: I remember that this got reported and "fixed" a few times already. There is (was?) an active H300 user (PaulJam) that used this feature and reported it after some changes here and some changes there. It seems to come back every now and then |
| 17:39:21 | pixelma | or maybe the design isn't correct from the start |
| 17:45:45 | | Join stoffel [0] (~quassel@p57B4C22F.dip.t-dialin.net) |
| 17:49:27 | | Join u42p [0] (~v35b@d020066.adsl.hansenet.de) |
| 17:50:11 | jhMikeS | speex is definitely a bit messed up...gtg now though |
| 17:54:46 | | Quit jhMikeS (Ping timeout: 248 seconds) |
| 17:58:28 | *** | Saving seen data "./dancer.seen" |
| 17:59:07 | | Quit dfkt (Read error: Connection reset by peer) |
| 17:59:08 | | Join dfkt_ [0] (dfkt@unaffiliated/dfkt) |
| 18:00 |
| 18:10:03 | | Join Strife89-iPAQ [0] (~Strife89@207.144.201.128) |
| 18:12:33 | | Join user890104_ [0] (~Venci@6bez10.info) |
| 18:13:19 | | Quit user890104 (Read error: No route to host) |
| 18:15:01 | | Quit Buganini (Quit: leaving) |
| 18:16:27 | | Quit Strife89-iPAQ (Remote host closed the connection) |
| 18:17:24 | | Join Buganini [0] (~buganini@2001:288:c237:0:dead:beef:cafe:babe) |
| 18:18:07 | | Join L-Strife89 [0] (~Strife89@207.144.201.128) |
| 18:27:01 | | Join mudd1 [0] (~cmertes@ip-78-94-202-227.unitymediagroup.de) |
| 18:44:01 | | Join LambdaCalculus37 [0] (~rmenes@c-68-36-232-73.hsd1.nj.comcast.net) |
| 18:44:01 | | Quit LambdaCalculus37 (Changing host) |
| 18:44:01 | | Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) |
| 19:00 |
| 19:09:56 | | Quit Stummi (Quit: Bye!) |
| 19:15:35 | | Quit stoffel (Ping timeout: 260 seconds) |
| 19:17:58 | | Join wtachi [0] (~wtachi@cpe-065-190-001-228.nc.res.rr.com) |
| 19:25:58 | | Quit MethoS- (Remote host closed the connection) |
| 19:27:45 | | Join GeekShadow [0] (~Antoine@93.21.160.159) |
| 19:27:45 | | Quit GeekShadow (Changing host) |
| 19:27:45 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 19:35:01 | | Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) |
| 19:36:12 | | Join stoffel [0] (~quassel@p57B4C22F.dip.t-dialin.net) |
| 19:42:26 | pamaury | why some target use -mlong-calls and some not ? |
| 19:45:49 | saratoga | pamaury: IIRC it depends on the memory map for each device and how close IRAM and DRAM are |
| 19:46:12 | saratoga | if IRAM and DRAM are close enough then a long call is not needed |
| 19:46:15 | pamaury | so it's defined for target for which IRAM and DRAM are not within 64MB ? |
| 19:46:17 | bertrik | I don't quite remember, for AMS sansa we used the memory mapping unit to move memory areas closer together so the code could use short calls instead of long ones and save a lot on binsize that way |
| 19:46:44 | pamaury | hum, indeed that's nice |
| 19:47:05 | saratoga | which devices still use it? PP? |
| 19:47:39 | pamaury | so I should use it if there is a huge gap between iram and dram (before using a mmu based solution) * |
| 19:47:42 | pamaury | ? |
| 19:47:49 | | Quit mc2739 (Ping timeout: 248 seconds) |
| 19:48:03 | saratoga | yeah i think you'll need it if you want to put functions in IRAM |
| 19:48:28 | saratoga | otherwise I don't think the compiler is smart enough to figure out how call between I and D RAM |
| 19:48:46 | pamaury | actually, I don't understand why the configure script don't put in on the command line :-/ |
| 19:48:51 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 19:48:58 | pamaury | anyway, I need to leave, thanks |
| 19:50:32 | saratoga | Unhelpfulfunman: EABI causes all calls to be short calls. if a short call is out of range at link time, a long jump to the proper address is inserted near it, and the short call is redirected there. |
| 19:50:47 | saratoga | so actually maybe i'm remembering the pre-EABI situation |
| 19:52:02 | | Quit LambdaCalculus37 (Quit: This computer has gone to sleep) |
| 19:56:34 | | Quit saratoga (Quit: Page closed) |
| 19:58:31 | *** | Saving seen data "./dancer.seen" |
| 19:59:23 | | Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) |
| 20:00 |
| 20:00:45 | wodz | any idea why CMD7 doesn't return error but does not put sd card into TRAN state? |
| 20:02:58 | | Quit stoffel (Remote host closed the connection) |
| 20:03:24 | bertrik | wodz, are you providing the proper rca? |
| 20:05:19 | bertrik | and how do you know it's not in TRAN state? |
| 20:09:46 | | Join Buschel [0] (~chatzilla@p54A3A231.dip.t-dialin.net) |
| 20:12:51 | | Quit L-Strife89 (Quit: Leaving) |
| 20:20:05 | | Quit dfkt_ (Read error: Connection reset by peer) |
| 20:20:06 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 20:20:23 | | Quit TheLemonMan (Quit: Destructor called) |
| 20:21:23 | CIA-87 | New commit by bertrik (r29799): iap: introduce functions (put_u32 and get_u32) to convert a uint32_t to a byte array and vice versa |
| 20:23:22 | | Quit Llorean (Ping timeout: 260 seconds) |
| 20:25:41 | linuxstb | bertrik: I guess it's not too important, but get_u32 exists in metadata_common.c (get_long_le). |
| 20:26:10 | CIA-87 | r29799 build result: 18 errors, 72 warnings (bertrik committed) |
| 20:27:34 | | Part u42p ("Leaving") |
| 20:29:58 | bertrik | maybe we should put it in a more central place |
| 20:53:08 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 21:00 |
| 21:15:02 | | Quit mudd1 (Remote host closed the connection) |
| 21:15:54 | wodz | bertrik: yes I am providing rca obtained in CMD3 (and I checked it isn't 0). sd_wait_for_tran_state() timeouts and status indicate that the card is in idle state. |
| 21:16:37 | bertrik | odd, I do remember that we use a huge timeout on the AMS sansas (5 seconds IIRC) |
| 21:16:46 | bertrik | timeout waiting for the tran state |
| 21:16:50 | wodz | I do have the same |
| 21:17:26 | bertrik | is this a real sd card or is it some kind of internal sd emulation? |
| 21:17:38 | wodz | real |
| 21:17:46 | bertrik | for the clipv1 we had to mess with bank switching using a proprietary sd command |
| 21:18:09 | bertrik | wodz, does the other stuff like getting the cid and the csd work? |
| 21:18:15 | wodz | yes |
| 21:18:53 | wodz | hmm, maybe the problem is that I setup CMD7 with R1 response while it should be R1b? |
| 21:18:55 | bertrik | then it's probably some silly mistake in your code that you need to take some distance from and look at later ... :) |
| 21:19:36 | wodz | what is max sd clk? 25 or 50 MHz? |
| 21:20:06 | bertrik | I suppose you have the sd physical layer simplified spec, right? |
| 21:20:16 | wodz | yes |
| 21:20:34 | bertrik | 25 MHz unless you switched it into high-speed mode (and the card supports that) |
| 21:20:46 | bertrik | and only 400 kHz until after CMD3 IIRC |
| 21:21:08 | wodz | I am aware of slow clk during identification |
| 21:22:55 | wodz | hmm OF also setup CMD7 with R1 response so this should not make any difference |
| 21:23:19 | bertrik | are you absolutely sure about the RCA? maybe you parsed it wrong or something silly like that? |
| 21:24:11 | bertrik | or confusing a long and a short response somewhere? |
| 21:24:24 | | Quit zenlunatic (Read error: Operation timed out) |
| 21:25:21 | bertrik | are you using the same initialisation order as (for example) the AMSv2 driver? |
| 21:25:54 | wodz | bertrik: yes I used AMSv2 as template |
| 21:27:18 | bertrik | are you getting an error in the R1 response in one of the commands perhaps (I think we don't even check for these in the AMSv2 driver)? |
| 21:27:45 | wodz | I do check errors |
| 21:28:19 | | Quit Ijon_Tichy (Ping timeout: 252 seconds) |
| 21:28:42 | bertrik | I think it must be something simple and silly then :| |
| 21:29:03 | bertrik | can you paste your code somewhere? |
| 21:29:15 | wodz | isn't RCA simply the response to CMD3? |
| 21:30:13 | wodz | anyway I tested that issuing CMD3 second time retuns different number |
| 21:30:54 | bertrik | yes |
| 21:36:29 | wodz | bertrik: http://www.pastie.org/1851421 |
| 21:37:37 | | Quit Judas_PhD (Ping timeout: 246 seconds) |
| 21:41:56 | bertrik | I don't see anything obviously wrong |
| 21:42:29 | bertrik | maybe the SD_RES words should be the other way around (although I don't think so) |
| 21:42:59 | bertrik | like SD_RES0 should go to response[0], SDRES1 to response[1] etc |
| 21:45:39 | bertrik | Have you tried the sd_wait_for_tran_state directly after the SD_SELECT command? |
| 21:46:17 | bluebroth3r | ok, any last concerns / issues with Rockbox Utility? Otherwise I'll start rolling 1.2.9 in like half an hour or so |
| 21:46:35 | bertrik | You could do everything at 400 kHz for now and not switch speeds yet until it works at 400 kHz. |
| 21:49:03 | | Join Ijon_Tichy [0] (~username@46.115.1.34) |
| 21:51:29 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 21:53:31 | | Join zenlunatic [0] (~justin@c-68-48-40-231.hsd1.md.comcast.net) |
| 21:56:14 | | Join Xerion_ [0] (~xerion@5419A078.cm-5-2c.dynamic.ziggo.nl) |
| 21:58:32 | | Quit Xerion (Ping timeout: 240 seconds) |
| 21:58:32 | | Nick Xerion_ is now known as Xerion (~xerion@5419A078.cm-5-2c.dynamic.ziggo.nl) |
| 21:58:35 | *** | Saving seen data "./dancer.seen" |
| 22:00 |
| 22:02:17 | | Join sylvain [0] (~sylvain@113.243.100-84.rev.gaoland.net) |
| 22:02:26 | sylvain | hi |
| 22:02:30 | | Nick sylvain is now known as Guest99880 (~sylvain@113.243.100-84.rev.gaoland.net) |
| 22:02:44 | Guest99880 | I'd need some advice to edit a theme, may someone help me ? |
| 22:02:48 | | Nick Guest99880 is now known as sylvvv (~sylvain@113.243.100-84.rev.gaoland.net) |
| 22:03:01 | * | bluebroth3r wonders if sylvvv can't decide on his name |
| 22:03:32 | sylvvv | well first it said my name was registered and therefore gave me a "guest" nick so I changed it |
| 22:04:05 | bluebroth3r | ah, so NickServ did that. Didn't notice that. Anyway. |
| 22:04:24 | bluebroth3r | If you have a question just ask. If someone who can help you is around (s)he will speak up. |
| 22:04:35 | bluebroth3r | otherwise it's hard to know if someone can help you ;-) |
| 22:05:45 | sylvvv | I need some help in modifying a theme ("plans") to suit my needs better |
| 22:06:19 | sylvvv | wait one second, I'm gonna write here the code that works, and tell where it gets wrong when I modify it further |
| 22:06:26 | sylvvv | *hold on |
| 22:08:15 | sylvvv | ok |
| 22:08:22 | sylvvv | this code works well : |
| 22:08:24 | sylvvv | %we |
| 22:08:24 | sylvvv | %X(bg.bmp) |
| 22:08:24 | sylvvv | %Cl(212,91,100,100) |
| 22:08:24 | DBUG | Enqueued KICK sylvvv |
| 22:08:24 | sylvvv | %pb(9,194,310,16,pb.bmp) |
| 22:08:24 | sylvvv | %s%ac%?ia<%ia|%?d(2)<%d(2)|>> |
| 22:08:25 | *** | Alert Mode level 1 |
| 22:08:25 | sylvvv | %s%ac%?it<%it|%fn> %?in<%(%in%)|> |
| 22:08:27 | sylvvv | %s%ac%?id<%id|%?d(1)<%d(1)|>> %?iy<%(%iy%)|> |
| 22:08:29 | sylvvv | %ac%?ig<%ig - |> Codec : %fc %(%?fb<%fbkbps|>%) |
| 22:08:31 | sylvvv | %acPlaylist %(%pp/%pe%) |
| 22:08:33 | sylvvv | %al Prev : |
| 22:08:35 | sylvvv | %al Current : |
| 22:08:37 | sylvvv | %al Next : %Ia - %It (%Id, %Fc) |
| 22:08:39 | sylvvv | %?C<%Vd(a)%Cd|%Vd(b)> |
| 22:08:41 | sylvvv | %al [ %pc %ac%pt %ar-%pr ] |
| 22:08:41 | bluebroth3r | sylvvv: please use a pastebin |
| 22:09:09 | sylvvv | http://pastebin.com/cCLEWFUF |
| 22:09:23 | sylvvv | so, this code works for the WPS :) |
| 22:09:38 | sylvvv | but |
| 22:09:48 | bluebroth3r | ok. I'm not too familiar with the theme syntax but I can give it a look |
| 22:10:07 | sylvvv | thanks |
| 22:10:45 | sylvvv | then I want to modify it to have the informations about the next songs in the playlist displayed instead of the current code (Prev/Current/next) |
| 22:11:03 | sylvvv | For that I need to insert this tag : %Vp |
| 22:11:10 | sylvvv | http://www.rockbox.org/wiki/CustomWPS |
| 22:11:55 | sylvvv | so I also need a "viewport" tag - and that's when I write it that the stuff gets mad |
| 22:14:44 | bluebroth3r | hmm. I guess I can't help much here. |
| 22:15:13 | bluebroth3r | but have you tried using the Theme Editor? It might help since it can display viewports and tag errors |
| 22:17:50 | sylvvv | ah ? no, didn't heard of it, what is it ? |
| 22:18:26 | *** | Alert Mode OFF |
| 22:18:45 | bluebroth3r | it's been a project in last years GSoC. Unfortunately it's a bit outdated these days but still quite useful (IMO :) |
| 22:18:48 | bluebroth3r | see http://www.rockbox.org/wiki/ThemeEditor |
| 22:19:31 | bluebroth3r | there are pre-built binaries for Windows and OS X available |
| 22:21:06 | wodz | bertrik: RCA is 16bits right? shouldn't bits 0:15 get masked out from response? |
| 22:22:03 | sylvvv | tranks |
| 22:22:44 | bertrik | wodz, hm yes maybe |
| 22:23:35 | bertrik | the AMSv2 sd controller receives 32-bit response, but I don't know exactly it it aligned with the 48-bit response from the card |
| 22:25:21 | CIA-87 | New commit by bluebrother (r29800): Rockbox Utility deployment: insert revision into OS X' Info.plist too. |
| 22:25:28 | CIA-87 | New commit by bluebrother (r29801): Rockbox Utility: bump version to 1.2.9. |
| 22:28:57 | CIA-87 | r29800 build result: 21 errors, 72 warnings (bluebrother committed) |
| 22:29:48 | bluebroth3r | great :( |
| 22:31:06 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 22:31:06 | * | bluebroth3r wonders where those false positives are coming from |
| 22:33:35 | CIA-87 | r29801 build result: All green |
| 22:33:41 | CIA-87 | New commit by bluebrother (r29802): Tag Rockbox Utility 1.2.9 release. |
| 22:34:15 | Buschel | amicoonn's build machine uses GCC 4.6x which outputs more warnings |
| 22:34:52 | bluebroth3r | I wouldn't expect the build server to catch those as errors though |
| 22:35:57 | Buschel | that's true |
| 22:37:04 | sylvvv | http://forums.rockbox.org/index.php/topic,27891.0.html |
| 22:37:06 | sylvvv | well |
| 22:37:43 | sylvvv | I eventually posted a thread on the forums, I hope I'll have a good answer. Thanks for your help ! |
| 22:38:36 | | Quit slooopy (Ping timeout: 240 seconds) |
| 22:47:09 | pixelma | sylvvv: if you only want the next song's information and not even further ones you don't need %Vp just the next song tags (%ia becomes %Ia etc., there's a note about that on CustomWPS and/or the manual) |
| 22:48:01 | sylvvv | pixelma: yes I know that but I'd like information about later songs as well ;) |
| 22:51:26 | pixelma | ok, misunderstood then. If your trouble is with the actual viewport definition then maybe also state what you tried, I don't know what info you actually need |
| 22:51:52 | | Quit Buschel (Quit: ChatZilla 0.9.86.1 [Firefox 3.6.16/20110319135224]) |
| 22:52:38 | | Join DogsHaveBeards2 [0] (~chatzilla@c-98-240-215-182.hsd1.mn.comcast.net) |
| 22:53:09 | | Quit sylvvv (Quit: Quitte) |
| 22:53:37 | DogsHaveBeards2 | Hello, I had a question regarding hardware. |
| 22:53:53 | | Join ebmoll [0] (~5ed83297@giant.haxx.se) |
| 22:53:59 | DogsHaveBeards2 | What is the highest capacity player that can run rockbox currently? |
| 22:57:54 | n17ikh | probably something like the 5.5 gen ipod video with a new hard drive in it |
| 23:00 |
| 23:00:02 | DogsHaveBeards2 | how much would a new HDD cost? |
| 23:00:26 | DogsHaveBeards2 | A solid state is unnecessary. |
| 23:00:49 | | Join bluebrother [0] (~dom@g224239115.adsl.alicedsl.de) |
| 23:00:49 | | Quit bluebrother (Changing host) |
| 23:00:49 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 23:04:31 | | Quit bluebroth3r (Ping timeout: 276 seconds) |
| 23:08:51 | * | bluebrother already found the first bug after releasing 1.2.9 :( |
| 23:09:20 | CIA-87 | New commit by bluebrother (r29803): Rockbox Utility: fix some names missing from the CREDITS. ... |
| 23:09:22 | | Join LambdaCalculus37 [0] (~rmenes@c-68-36-232-73.hsd1.nj.comcast.net) |
| 23:09:22 | | Quit LambdaCalculus37 (Changing host) |
| 23:09:22 | | Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) |
| 23:09:35 | | Quit efyx (Remote host closed the connection) |
| 23:10:15 | | Quit DogsHaveBeards2 (Quit: ChatZilla 0.9.86.1 [Firefox 4.0/20110318052756]) |
| 23:13:34 | | Quit Battousai (Quit: Leaving) |
| 23:13:41 | CIA-87 | r29803 build result: 18 errors, 50 warnings (bluebrother committed) |
| 23:13:48 | | Join Battousai [0] (~bryan@2001:470:8830::80) |
| 23:13:51 | | Quit Battousai (Client Quit) |
| 23:14:15 | | Join silbo [0] (~quassel@193.40.244.204) |
| 23:16:49 | | Quit ebmoll (Quit: CGI:IRC (EOF)) |
| 23:20:16 | | Quit wtachi (Quit: &) |
| 23:23:14 | bluebrother | B4gder: can you move Rockbox Utility 1.2.9 to the download server? Binaries are at http://www.alice-dsl.net/dominik.riebeling/rockbox/rbutil-releases/1.2.9/ |
| 23:23:40 | B4gder | ok! |
| 23:24:28 | | Join Keripo [0] (~Keripo@eng319.wireless-resnet.upenn.edu) |
| 23:25:58 | B4gder | done! |
| 23:26:27 | B4gder | and as there's no mirrors atm, they're already available! |
| 23:32:36 | | Join saratoga [0] (9803c6dd@gateway/web/freenode/ip.152.3.198.221) |
| 23:32:50 | saratoga | Bagder: can you change catagories on flyspray? |
| 23:32:56 | bluebrother | B4gder: nice, thanks! |
| 23:33:11 | B4gder | saratoga: yes I can |
| 23:33:13 | saratoga | an AMSv1 category would be nice (oddly we have AMSv2) |
| 23:33:31 | bluebrother | is it possible to have multi-select categories in FS? |
| 23:33:37 | wodz | bertrik: any other ideas? the card changes states as described in spec up to the moment when it should enter tran state. Changing SD clock doesn't change anything. RCA is correct as far as I can tell. After CMD7 the card is still in STBY state and issuing CMD7 again timeouts. |
| 23:34:04 | bluebrother | oh, and can we get wiki markup in FS? I consider that really useful and FS itself does support some basic markup |
| 23:36:00 | B4gder | saratoga: added now |
| 23:36:05 | saratoga | thanks |
| 23:38:15 | bluebrother | B4gder: any thoughts on wiki markup in FS? |
| 23:38:38 | B4gder | that'd be nice |
| 23:38:45 | B4gder | it is nice in trac |
| 23:38:48 | bluebrother | can you enable it then? ;-) |
| 23:38:58 | B4gder | I doubt I can |
| 23:39:23 | bluebrother | I tried this some time ago with a local installation. It's rather easy, you need to switch to a different template IIRC |
| 23:39:27 | B4gder | there's no such option |
| 23:39:37 | B4gder | template... |
| 23:39:50 | B4gder | I don't even know they have "templates" |
| 23:39:53 | bluebrother | let me see if I find that installation |
| 23:40:44 | B4gder | why on earth is that an option and not just enabled ? |
| 23:40:59 | | Quit LambdaCalculus37 (Quit: This computer has gone to sleep) |
| 23:41:09 | bluebrother | no idea. I don't see a point in having it disabled by default either |
| 23:42:01 | bluebrother | but the best thing in this regard is the Jira installation we have at work. Some queues support markup in comments but not in the issue description. Seems also to be a strange default. |
| 23:45:18 | bluebrother | B4gder: ah, here it is: "If you want to enable dokuwiki syntax, edit flyspray.conf.php. Change the operand of the syntax_plugin statement to âdokuwikiâ." |
| 23:45:34 | bluebrother | (at the bottom of http://flyspray.org/manual:installation) |
| 23:45:42 | | Quit benedikt93 (Quit: Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.) |
| 23:45:54 | B4gder | I'll leave that for Zagor, he's the one who's done the fiddling with the installation and on-disk stuff |
| 23:46:00 | | Quit sinthetek (Ping timeout: 250 seconds) |
| 23:46:11 | bluebrother | ok. Would be nice to get that soon :) |
| 23:47:54 | wodz | have anyone looked up for hotels for DevCon? |
| 23:48:55 | | Join sinthetek [0] (~sinthetek@cpe-174-111-021-024.triad.res.rr.com) |
| 23:48:55 | | Quit sinthetek (Changing host) |
| 23:48:55 | | Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek) |
| 23:49:11 | B4gder | there's been activities for hotels but I don't think its been successful yet |
| 23:55:24 | bluebrother | hmm, Firefox 4 doesn't support the update thingy for the irc reader anymore? |
| 23:55:34 | B4gder | correct |
| 23:55:50 | B4gder | it needs to be made in another way to work |
| 23:55:57 | | Nick user890104_ is now known as user890104 (~Venci@6bez10.info) |
| 23:55:59 | bluebrother | urgh |
| 23:56:36 | bluebrother | I guess that means some AJAX stuff? |
| 23:57:01 | B4gder | yes I believe so... :-/ |
| 23:58:09 | bluebrother | that would require something on the server too, right? |
| 23:58:36 | *** | Saving seen data "./dancer.seen" |
| 23:58:37 | B4gder | probably |
| 23:58:45 | B4gder | I haven't really investigated it |
| 23:58:53 | | Join krazykit [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) |
icon identifies that the person is a core developer (has commit access).