| 00:03:58 | | Join webguest [0] (~be2baae7@www.haxx.se) |
| 00:04:08 | webguest | yo |
| 00:04:47 | bluebrother | yeah |
| 00:06:14 | | Quit webguest (Client Quit) |
| 00:06:56 | bluebrother | amazingly long visit |
| 00:11:41 | TheSeven | jhMikeS: I just don't get any clicking sound at all while USB is connected |
| 00:12:04 | TheSeven | how did you manage to get one? |
| 00:12:39 | jhMikeS | TheSeven: Just turn on keyclick. Connect USB storage. Press some keys. |
| 00:13:41 | TheSeven | that's what I did. no sound at all. |
| 00:14:32 | jhMikeS | I'd guess that means there is some interference between PCM and USB storage on that target afterall. |
| 00:15:03 | TheSeven | well, yeah, but I'd guess at a higher level |
| 00:16:15 | jhMikeS | most likely, unless some later action by the driver is culprit, one that isn't hit unless storage is fully running |
| 00:17:20 | * | TheSeven just triggered a usb lockup without playing any audio |
| 00:26:02 | JdGordon| | TheSeven: are you nuking oyur .rockbox dir every reinstall? |
| 00:30:18 | TheSeven | JdGordon|: not on every reinstall, but often enough |
| 00:31:28 | | Join ageis [0] (~kevin@c-76-127-201-198.hsd1.ma.comcast.net) |
| 00:32:54 | JdGordon| | why? |
| 00:33:48 | | Join Keripo [0] (~Keripo@vpl477.wlan.library.upenn.edu) |
| 00:34:34 | TheSeven | emcore install/uninstall/update testing, FTL testing, ... |
| 00:35:18 | JdGordon| | ok, fair enough |
| 00:35:24 | TheSeven | => lots of reformatting going on |
| 00:35:37 | TheSeven | jhMikeS: http://srouter.dyndns.info/rbbuild/nano2g-app/rockbox.ipod |
| 00:35:42 | JdGordon| | you might want to just change the default value in settings_list.c for the show files setting if that annoys you |
| 00:35:45 | TheSeven | does that build click on your ipod while USB is connected? |
| 00:36:52 | jhMikeS | TheSeven: I can't test that. The only iPod is have is a 3g with a pp5002 |
| 00:37:29 | TheSeven | ah, so "Just FYI: Keyclick while USB is connect seems to be fine on the targets I own. I suppose it should be expected to work." refers to non-nano2g devices, which explains a lot |
| 00:37:45 | JdGordon| | jhMikeS: thats a hard disk target right? any chance you could test a patch for me? |
| 00:38:55 | jhMikeS | TheSeven: that's what I meant. I did mention in that task that I didn't have the apropriate hardware :) |
| 00:39:08 | jhMikeS | JdGordon|: sure, specifically on that one? |
| 00:39:13 | | Join Reimu_Hakurei [0] (~znc@2607:f358:1:fed5:22:0:8c2c:6b65) |
| 00:39:59 | JdGordon| | jhMikeS: yes, I'm trying to see if i managed to speed up .cfg loading |
| 00:40:09 | JdGordon| | do you want me to build for oyu? |
| 00:40:32 | jhMikeS | would probably be faster if you did |
| 00:42:10 | jhMikeS | it seems to be badly in need of a charge too :\ |
| 00:43:25 | TheSeven | jhMikeS: making sure usb_core_control_request will never get called also helps |
| 00:43:56 | TheSeven | so the USB interrupt handling code doesn't seem to be directly involved here |
| 00:44:11 | TheSeven | possibly a high rate of interrupts during lots of USB traffic? |
| 00:44:40 | | Quit Reimu_Hakurei (Quit: Baibai.) |
| 00:45:38 | jhMikeS | why should that be an issue though? a measly 173 ints/sec from PCM? |
| 00:47:32 | TheSeven | commenting out the call to usb_core_transfer_complete in the IN EP IRQ handler doesn't help! |
| 00:47:37 | jhMikeS | the fact it doesn't start at all once storage is active should be telling |
| 00:48:11 | TheSeven | so receiving a control request (but not passing it to our code) doesn't cause the crash, but sending the response does! |
| 00:48:26 | JdGordon| | jhMikeS: jdgordon.info/rockbox/rockbox-3g-patched.zip">http://jdgordon.info/rockbox/rockbox-3g-patched.zip and http://jdgordon.info/rockbox/rockbox-3g-patched2.zip on both please note the number that gets splashed at boot, and also try manually loading a cfg (preferably a full one saved from the setting menu) and not the number again |
| 00:48:39 | * | TheSeven double checks |
| 00:49:00 | jhMikeS | JdGordon|: oh, now it's TWO tests :) |
| 00:49:29 | TheSeven | the behavior is consistent so far... |
| 00:49:33 | JdGordon| | 4 technially :) 2 builds |
| 00:49:58 | TheSeven | btw, one more thing that I dislike: keyclick repeat |
| 00:50:14 | jhMikeS | TheSeven: well, turn it off! :) |
| 00:50:26 | JdGordon| | keyclick repeat needs to be fixed to only beep the first repeat |
| 00:50:41 | TheSeven | you have the option to either just get a single click when scrolling around in a list (doesn't make any sense to me), or getting a really nasty sound when trying to e.g. power off the ipod |
| 00:50:47 | TheSeven | or enter charging mode |
| 00:50:57 | jhMikeS | I disagree if that involved the wheel or something where hearing every step is important |
| 00:51:36 | TheSeven | yeah, i want to hear every step of the wheel, but not every typematic-like event of a button that's being held down |
| 00:51:48 | TheSeven | and that's apparently not possible currently |
| 00:51:51 | jhMikeS | JdGordon|: should I test the unmodified build too or just the provided ones? |
| 00:52:04 | JdGordon| | just the provided 2 |
| 00:52:15 | JdGordon| | the second one with svn with the splash added to get a baseline number |
| 00:52:19 | JdGordon| | TheSeven: sure it is |
| 00:52:22 | | Quit ageis (Quit: XChat 2.8.8 Linux 3.0.0-1-686-pae [i686/2.99GHz]) |
| 00:52:33 | TheSeven | how? |
| 00:52:37 | * | jhMikeS doesn't even know if newer builds still run on that target at all |
| 00:53:51 | JdGordon| | TheSeven: keyclick happens in action.c so just check the button value |
| 00:54:08 | | Join Reimu_Hakurei [0] (~znc@reimuhakurei.net) |
| 00:54:40 | TheSeven | JdGordon|: I meant with the current code, from a user's perspective |
| 00:55:03 | TheSeven | the options we're currently providing just don't make sense for clickwheel-based targets |
| 00:55:14 | | Quit lebellium (Quit: ChatZilla 0.9.87 [Firefox 8.0/20111102223350]) |
| 00:55:16 | JdGordon| | 100% agree |
| 00:55:39 | JdGordon| | i dont see why we need a setting for it though |
| 00:56:18 | TheSeven | i'd be perfectly fine with a sane default behavior, but we should at least provide a setting for a sane behavior, and not just the two useless options :) |
| 00:56:56 | JdGordon| | It shouldnt be hard to fix the repeat behaviour to be not moronic :) |
| 00:57:00 | jhMikeS | arg, wtf. hope I don't have to reboot. it seem to be having trouble connecting on the firewire |
| 00:58:02 | jhMikeS | guess I'd better |
| 00:59:46 | TheSeven | eeeek |
| 00:59:59 | TheSeven | messing with the usb send code made it end up with an ATA error 1 while connecting to USB |
| 01:00 |
| 01:00:24 | TheSeven | JdGordon|: I'd actually consider this a release blocker |
| 01:00:51 | jhMikeS | I guess it was a problem of having too much crap open :\ |
| 01:01:10 | JdGordon| | TheSeven: its not new since 3.9 so good luck! :) |
| 01:01:36 | TheSeven | hm, I never realized it was *that* broken |
| 01:02:26 | TheSeven | possibly because I usually have the hw keyclick patch applied which seems to fix the most annoying parts of it |
| 01:02:59 | JdGordon| | hwclick is just as bad |
| 01:04:54 | CIA-22 | New commit by theseven (r30905): usb-s3c6400x.c: Remove an unused variable |
| 01:05:49 | jhMikeS | well, I get a "0" at boot with "patched" |
| 01:06:58 | CIA-22 | r30905 build result: All green |
| 01:07:06 | jhMikeS | with patched2 a "1" |
| 01:07:39 | JdGordon| | jhMikeS: did you try loading a .cfg manually also? |
| 01:07:55 | JdGordon| | and i guess your config.cfg is pretty empty? |
| 01:09:04 | jhMikeS | it probably is pretty empty. so far, I can't do anything manually since the batt is so low it shuts down and I don't think there's a "charging only" mode on 3g :\ |
| 01:09:19 | JdGordon| | ah nuts |
| 01:10:12 | jhMikeS | could try x5 or h10 5GB, or gigabeat F/S, H100 as well |
| 01:10:20 | *** | Saving seen data "./dancer.seen" |
| 01:10:38 | jhMikeS | the battery on my 20GB H10 is completely useless now |
| 01:10:39 | TheSeven | *PANIC* Stack underflow... viewport manager |
| 01:10:44 | JdGordon| | anything with a hard disk would be great :) |
| 01:10:55 | JdGordon| | TheSeven: good one! how'd you manage that? |
| 01:11:13 | TheSeven | some combination of unplugging USB while holding the power buttion |
| 01:11:16 | JdGordon| | TheSeven: wanna try http://pastebin.com/E4EUkWRm ? |
| 01:11:20 | TheSeven | er, play button, attempting to power it off |
| 01:11:32 | jhMikeS | JdGordon|: well, take your pick from the list...I haven't the patches anyway |
| 01:11:55 | jhMikeS | H100/x5 would probably show it best |
| 01:12:01 | JdGordon| | jhMikeS: the patch changes read_line() to fast_readline() and does some other smartness to hopefuly speed cfg loading up |
| 01:12:04 | JdGordon| | ok |
| 01:13:00 | jhMikeS | you know, I don't get why the e260 battery seems practically new after so many years but everyone else's seem to go flat in just a few |
| 01:13:02 | JdGordon| | I dont have the coldfire gcc :( |
| 01:13:23 | jhMikeS | ok, the gigbeat f? It has a fairly slow hard drive |
| 01:13:53 | * | TheSeven could test on a classic with a crippled hard drive |
| 01:14:07 | JdGordon| | how abot i put the patches online? :) |
| 01:14:36 | jhMikeS | go ahead. I though you had like some 6000 core machine or something :) |
| 01:14:55 | TheSeven | jhMikeS: is mixer_reset() irq-safe? |
| 01:14:57 | JdGordon| | yeah, but really slow internet |
| 01:15:11 | JdGordon| | I tried installed sh-elf earlier in the week and gave up after na hour of downloading |
| 01:15:23 | jhMikeS | TheSeven: I don't believe it is |
| 01:16:07 | * | TheSeven tries to move that around to find the spot that needs to happen before it to trigger the crash |
| 01:16:20 | jhMikeS | none of the weightier mixer routines were meant to be |
| 01:16:41 | JdGordon| | jhMikeS: jdgordon.info/rockbox/smart_settings2.diff">http://jdgordon.info/rockbox/smart_settings2.diff is the first one |
| 01:16:52 | JdGordon| | please manually load a .cfg from the browser/menus also |
| 01:16:58 | TheSeven | now this is odd |
| 01:17:33 | TheSeven | i made usb_drv_send call mixer_reset() on its first invocation |
| 01:17:44 | TheSeven | and it seems to completely fix the issue |
| 01:18:00 | TheSeven | even if i try it multiple times |
| 01:18:53 | JdGordon| | jhMikeS: and jdgordon.info/rockbox/smart_settings1.diff">http://jdgordon.info/rockbox/smart_settings1.diff is the other one |
| 01:18:53 | jhMikeS | JdGordon|: and the second? |
| 01:18:57 | jhMikeS | hrm |
| 01:19:12 | TheSeven | this is driving me nuts... |
| 01:20:40 | * | TheSeven has a suspicion |
| 01:25:34 | TheSeven | hm, nope, seems like purely random behavior |
| 01:26:59 | | Quit keyb_gr (Ping timeout: 240 seconds) |
| 01:27:35 | TheSeven | this smells more and more like memory corruption |
| 01:28:17 | | Quit BHSPitMonkey (Read error: Connection reset by peer) |
| 01:29:09 | jhMikeS | cache line stuff maybe? |
| 01:29:52 | TheSeven | nah, much worsse stuff |
| 01:29:58 | TheSeven | worse* |
| 01:30:27 | TheSeven | adding an udelay() in the usb code caused the lcd to slowly fade to white when plugging USB |
| 01:31:16 | jhMikeS | try adding things of specific sizes, like nops |
| 01:33:40 | TheSeven | these really odd things aren't reproducible |
| 01:34:26 | jhMikeS | so, it's not every time with a specific mod? |
| 01:34:45 | TheSeven | adding this code into usb_drv_send fixes it, even for multiple usb connections: |
| 01:34:46 | TheSeven | if (!hit) mixer_reset(); |
| 01:34:46 | TheSeven | hit = true; |
| 01:35:15 | TheSeven | adding the same code into usb_drv_init fixes it only for the first connection |
| 01:35:29 | TheSeven | now what the hell does that mean? |
| 01:36:05 | TheSeven | logical conclusion: the "hit" variable is being zeroed by something in between |
| 01:36:15 | TheSeven | it's probably close to a USB transfer buffer in memory |
| 01:36:23 | | Join Sethman [0] (~4348622d@www.haxx.se) |
| 01:36:31 | jhMikeS | transfer buffer is cache aligned? |
| 01:38:22 | | Quit Sethman (Client Quit) |
| 01:38:31 | pamaury | does this usb problem only happen on the nano2g ? |
| 01:38:58 | TheSeven | apparently |
| 01:39:15 | TheSeven | transfer buffer is USB_DEVBSS_ATTR, whatever that means |
| 01:40:22 | jhMikeS | that just allows each target to allocate it as what is best for it |
| 01:40:29 | TheSeven | ok, i think i have evidence of memory corruption |
| 01:40:29 | pamaury | I seem to remember that we were very suspicious about memory corruption on the clip+ with the same usb controller |
| 01:40:39 | TheSeven | moving the "hit" variable to iram breaks it |
| 01:41:10 | TheSeven | pamaury: you mean that vector corruption bug? |
| 01:41:36 | TheSeven | i think we got rid of that by pointing its dma address registers into nowhere when doing zero-byte transactions |
| 01:42:03 | TheSeven | firmware/export/config/ipodnano2g.h:#define USB_DEVBSS_ATTR __attribute__((aligned(16))) |
| 01:42:08 | TheSeven | that seems to be safe |
| 01:42:09 | pamaury | no, memory close to transfer buffers, like if the dma was writing more than needed |
| 01:42:32 | TheSeven | which would be kinda similar to "dma writing something when 0 bytes are needed" |
| 01:42:33 | pamaury | (which can be the case, it can write up to 3 bytes more iirc) |
| 01:43:02 | pamaury | (or more if doing burst ?) |
| 01:43:27 | jhMikeS | try making the buffer bigger (just to check)? |
| 01:44:33 | JdGordon| | TheSeven: I tihink I've fixed keyclick |
| 01:45:18 | JdGordon| | yep :) |
| 01:45:48 | pamaury | Perhaps you can try to disable dma bursts for this controller ? I think there are a register bits for this usb controller |
| 01:47:08 | TheSeven | uh oh, I think I know what's going on |
| 01:47:24 | jhMikeS | JdGordon|: (on GigF) Settings1: boot - 0, load - 1 |
| 01:48:01 | TheSeven | jhMikeS: http://pastie.org/2817928 |
| 01:48:01 | TheSeven | gotcha! |
| 01:48:13 | TheSeven | that explains the usb to pcm relationship |
| 01:48:25 | TheSeven | ctrlreq is probably overflowing |
| 01:49:01 | JdGordon| | TheSeven: I merged my fix with fs#5111 if you want it |
| 01:49:02 | fs-bluebot | http://www.rockbox.org/tracker/task/5111 Ipod piezo driver (patches, unconfirmed) |
| 01:51:39 | | Join chrooted_mother [0] (~Burninato@ool-18bc6682.dyn.optonline.net) |
| 01:51:53 | jhMikeS | hrm...same reading with the second patch |
| 01:51:55 | chrooted_mother | I just installed rockbox on my Nano 2G. Thanks guys! |
| 01:52:01 | JdGordon| | jhMikeS: damn, ok thanks |
| 01:52:34 | jhMikeS | maybe i should make a ridiculous config? can I dump even non-defaults somewhere? |
| 01:52:49 | chrooted_mother | using the current build as well. any cool tricks besides playing doom? |
| 01:52:49 | jhMikeS | er defaults + non-defauls |
| 01:53:16 | | Quit domonoky (Read error: Connection reset by peer) |
| 01:53:21 | | Quit bertrik (Read error: Operation timed out) |
| 01:53:23 | JdGordon| | jhMikeS: settings2.diff the values dont matter, dumping a default config and loading it should give a pretty close to 0 time on 1 and large on 2 |
| 01:53:57 | jhMikeS | I'll try the settings dumper output |
| 01:54:16 | JdGordon| | no, jsut save a config |
| 01:55:05 | JdGordon| | anyway, that patch wont reload the themes (causing a audio restart) if it doesnt change so its worth doing anyway |
| 01:55:16 | JdGordon| | I'm surprised that readline isnt slower than fast_readline houhg |
| 01:55:36 | JdGordon| | is there disk block caching? |
| 01:55:39 | | Quit Keripo (Quit: Leaving.) |
| 01:56:08 | pamaury | TheSeven: indeed, 0 bytes of padding seems dangerous with this controller :) |
| 01:56:12 | | Quit n1s (Quit: Ex-Chat) |
| 01:56:21 | jhMikeS | TheSeven: wait, what am I supposed to spot? |
| 01:56:27 | CIA-22 | New commit by theseven (r30906): usb-s3c6400x.c: Fix memory corruption bug (closes FS #12310) |
| 01:57:24 | jhMikeS | guess I'll see in a second |
| 01:57:46 | pamaury | TheSeven: that's a rather hacky fix ! ;) |
| 01:57:54 | TheSeven | jhMikeS: the PCM driver's global variables were trashed by a memory corruption bug in the USB code |
| 01:57:59 | CIA-22 | r30906 build result: All green |
| 01:58:30 | TheSeven | pamaury: well, that was the least hacky variant that I could think of :) |
| 01:59:05 | funman | TheSeven: can you add a comment about that 64 bytes? |
| 01:59:05 | pamaury | it would be interesting to understand why it "overflows" and of how much |
| 01:59:24 | pamaury | and see if it can be fixed |
| 01:59:36 | TheSeven | pamaury: it technically doesn't overflow |
| 01:59:54 | TheSeven | the maximum size for a USB control request is 64 bytes |
| 02:00 |
| 02:00:03 | jhMikeS | JdGordon|: according to the 3g, the more modded version was faster |
| 02:00:10 | TheSeven | we only use the first 8 bytes because we don't support any commands that need more |
| 02:00:32 | pamaury | ah, the dma is setuped to received 64-bytes ?! |
| 02:00:42 | TheSeven | so our struct only contains those 8 header bytes, but those can in theory be followed by payload data |
| 02:00:42 | TheSeven | yep |
| 02:00:48 | TheSeven | and windows probably sends some "write descriptor" or something command |
| 02:01:30 | TheSeven | so the proper fix would probably to add the missing bytes to the struct itself, but I don't really want to touch that before 3.10 |
| 02:02:16 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
| 02:04:20 | TheSeven | jhMikeS: thanks for making that nasty bug surface :) |
| 02:04:49 | TheSeven | this could have (or even did?) caused much more subtle and intermittent trouble |
| 02:05:55 | * | jhMikeS was always considered a trouble-maker, but never knew it would be so valuable later in life :) |
| 02:06:03 | pamaury | it might have, and might have caused some bugs on the clip+ too (for those who tried the usb patch) |
| 02:07:38 | JdGordon| | jhMikeS: great, though not really a difference worht worrying about? |
| 02:07:43 | JdGordon| | that number is ticks |
| 02:07:55 | funman | pamaury: tell me you'll fix AMSv2 USB soon :) |
| 02:08:58 | pamaury | not sure, we might have made some progress with the OF voltage settings that bertrik found and I'm still puzzled by the fact that with sd inserted it works reliably where is fails randomly without |
| 02:09:18 | pamaury | this "bug" could explain some things but not all |
| 02:09:21 | jhMikeS | JdGordon|: loading that the big cfg only took two ticks on the F, not like anyone would notice. one config loader that should be better is the one used by plugins. it makes mpegplayer slow to switch between files. |
| 02:11:54 | jhMikeS | it always has to save the last resume but the disk thrashes around while it does it |
| 02:12:48 | funman | pamaury: do you test with windows or linux? |
| 02:13:04 | pamaury | I tested with both |
| 02:13:06 | JdGordon| | thats completly different code though isnt it? |
| 02:13:30 | jhMikeS | JdGordon|: in the plugin lib iirc |
| 02:14:43 | pamaury | with windows is always less reliable and does some lockup on enumeration quite often (that might have to do with this bug); but with linux it usually doesn't work unless you have sd inserted (in my case and last time I tried) |
| 02:16:16 | jhMikeS | JdGordon|: it uses readline/parseline to read but fdprintf to write |
| 02:19:11 | JdGordon| | it reads and writes at the same time? |
| 02:24:18 | | Join Keripo [0] (~Keripo@eng140.wireless-resnet.upenn.edu) |
| 02:26:54 | jhMikeS | if modifying a line |
| 02:27:25 | jhMikeS | for some reason, the settings dumper config failed to properly load as a cfg (should it?) |
| 02:28:20 | jhMikeS | it loaded but some settings like the backlight brightness were some crazy value |
| 02:30:06 | jhMikeS | ha, I see, it give mix/max/step but doesn't actually provide values |
| 02:30:22 | JdGordon| | i dont tihn it is supposed to write something loadable |
| 02:30:33 | JdGordon| | anyway, im heading out to enjoy the day |
| 02:34:12 | jhMikeS | TheSeven: It's curious that dblbuf is nothing more than char aligned in the PCM driver |
| 02:36:43 | pamaury | TheSeven: do you plan to add a comment about the 64-bytes in the usb driver ? |
| 02:49:15 | CIA-22 | New commit by pamaury (r30907): sbtools: rename to imxtools, move imx_hid_recovery to imxtools/sbloader, fix tools to correctly handle/free memory, properly return error codes |
| 02:50:49 | CIA-22 | r30907 build result: All green |
| 02:51:36 | jhMikeS | are the imxtools for all imx? |
| 02:53:54 | pamaury | I think so, although they don't handle things of the more advanced ones |
| 02:54:23 | pamaury | At least they should handle the imx2y and imx5y for which I'm pretty sure it's the same format |
| 02:55:30 | pamaury | based on the freescale sbloader, that should work on mx23/28, mx50/6x |
| 02:56:19 | | Quit GeekShadow (Remote host closed the connection) |
| 02:57:23 | | Quit Reimu_Hakurei (Ping timeout: 240 seconds) |
| 03:00 |
| 03:01:27 | | Quit pamaury (Remote host closed the connection) |
| 03:04:27 | | Quit chrooted_mother (Ping timeout: 240 seconds) |
| 03:10:22 | *** | Saving seen data "./dancer.seen" |
| 03:11:20 | | Join chrooted_mother [0] (~Burninato@ool-18bc6682.dyn.optonline.net) |
| 03:38:48 | chrooted_mother | what can rockbox do? i installed it and I know about the codecs, I use FLAC and needed to read flac on my ipod |
| 03:38:53 | chrooted_mother | but are there any cool tricks? |
| 04:00 |
| 04:01:44 | | Join guymann [0] (~charles@66-159-172-106.adsl.snet.net) |
| 04:06:20 | | Quit TheSeven (Disconnected by services) |
| 04:06:46 | | Join [7] [0] (~TheSeven@rockbox/developer/TheSeven) |
| 04:11:57 | | Join ageis [0] (~kevin@c-76-127-201-198.hsd1.ma.comcast.net) |
| 04:17:15 | | Quit amiconn (Disconnected by services) |
| 04:17:16 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 04:17:21 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 04:18:15 | | Quit pixelma (Disconnected by services) |
| 04:18:17 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 04:18:19 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 04:28:00 | | Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) |
| 05:00 |
| 05:01:04 | | Join Reimu_Hakurei [0] (~znc@reimuhakurei.net) |
| 05:01:43 | | Quit robin0800 (Quit: Leaving) |
| 05:10:23 | *** | Saving seen data "./dancer.seen" |
| 05:21:00 | | Join Rob2223 [0] (~Miranda@p4FFF1DA0.dip.t-dialin.net) |
| 05:24:32 | | Quit Rob2222 (Ping timeout: 245 seconds) |
| 05:27:11 | | Join Rubyiris [0] (~44e63f63@www.haxx.se) |
| 05:33:06 | | Join robin0800 [0] (~robin0800@149.254.60.157) |
| 05:33:31 | Rubyiris | circa-2009), Rockbox has been reporting the wrong battery life, and my battery life has dropped significantly. Less than that of the original Sansa firmware. |
| 05:33:41 | Rubyiris | :\ |
| 05:36:04 | | Quit chrooted_mother (Ping timeout: 240 seconds) |
| 05:43:38 | | Quit Rubyiris (Quit: CGI:IRC (Ping timeout)) |
| 05:51:26 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
| 06:00 |
| 06:07:04 | | Quit zchs (Ping timeout: 252 seconds) |
| 06:25:44 | | Join zchs [0] (~zchs@ool-ad02eb3f.dyn.optonline.net) |
| 06:34:55 | | Quit robin0800 (Quit: Leaving) |
| 07:00 |
| 07:10:27 | *** | Saving seen data "./dancer.seen" |
| 07:25:29 | | Quit BHSPitMonkey (Remote host closed the connection) |
| 08:00 |
| 08:23:05 | | Quit ageis (Quit: laters) |
| 08:31:17 | | Join Horschti [0] (~Horscht@xbmc/user/horscht) |
| 08:34:45 | | Quit Horscht (Ping timeout: 260 seconds) |
| 08:40:53 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 08:40:53 | | Quit bertrik (Changing host) |
| 08:40:53 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 09:00 |
| 09:04:06 | | Quit Keripo (Read error: Connection reset by peer) |
| 09:04:48 | | Join Keripo [0] (~Keripo@eng140.wireless-resnet.upenn.edu) |
| 09:06:48 | | Join stoffel [0] (~quassel@p57B4A9F2.dip.t-dialin.net) |
| 09:10:30 | *** | Saving seen data "./dancer.seen" |
| 09:28:56 | | Join n1s [0] (~n1s@nl118-175-223.student.uu.se) |
| 09:28:57 | | Quit n1s (Changing host) |
| 09:28:57 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 09:32:35 | | Nick Guest45092 is now known as froggyman (~seth@50.105.149.180) |
| 09:32:43 | | Quit froggyman (Changing host) |
| 09:32:43 | | Join froggyman [0] (~seth@unaffiliated/froggyman) |
| 09:59:59 | | Quit [Saint] (Read error: Connection reset by peer) |
| 10:00 |
| 10:00:14 | | Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) |
| 10:10:44 | | Quit [Saint] (Read error: Connection reset by peer) |
| 10:10:47 | | Join [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940) |
| 10:12:12 | | Join caramou1 [0] (~Adium@184.218.20.81.dynamic.adsl.abo.nordnet.fr) |
| 10:24:18 | | Join Stummi [0] (~Stummi@rockbox/developer/Stummi) |
| 10:27:53 | | Quit [Saint_] (Remote host closed the connection) |
| 10:32:56 | | Join chrooted_mother [0] (~Burninato@ool-18bc6682.dyn.optonline.net) |
| 10:35:57 | | Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) |
| 10:49:53 | | Join ender` [0] (~ender@foo.eternallybored.org) |
| 10:53:43 | | Quit bluebrother (Disconnected by services) |
| 10:53:45 | | Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) |
| 10:55:40 | | Quit fs-bluebot (Ping timeout: 240 seconds) |
| 10:57:20 | | Join fs-bluebot [0] (~fs-bluebo@g231122010.adsl.alicedsl.de) |
| 11:00 |
| 11:01:34 | | Quit mystica555 (Quit: Ekkusu Chatto) |
| 11:06:38 | kugel | alright, I think I've fixed voice |
| 11:07:25 | [Saint] | What actually broke it? |
| 11:09:00 | kugel | [7]: "unsigned char data[sizeof(struct usb_ctrlrequest)]" would also work wouldn't it? |
| 11:10:27 | kugel | [Saint]: several negligences |
| 11:10:31 | *** | Saving seen data "./dancer.seen" |
| 11:11:25 | [Saint] | Oh, fancy that, in Rockbox too of all places ;) |
| 11:11:30 | JdGordon| | kugel: why not just make data a sturct usb_ctrlrequest* ? |
| 11:12:04 | | Quit chrooted_mother (Ping timeout: 240 seconds) |
| 11:16:15 | | Join TheLemonMan [0] (~LemonBoy@ppp-3-26.26-151.libero.it) |
| 11:19:27 | kugel | JdGordon|: that was before |
| 11:19:36 | kugel | that caused memory corruption |
| 11:19:54 | JdGordon| | why? |
| 11:19:58 | JdGordon| | where is the naughty code? |
| 11:20:17 | JdGordon| | is this more bad pointer arithmatic? |
| 11:20:32 | kugel | see r30906 |
| 11:21:06 | [Saint] | There's no such thing as a bad pointer, just good pointers with a bad upbringing. |
| 11:21:40 | kugel | amiconn: ping |
| 11:21:42 | JdGordon| | what am I looking at? |
| 11:21:55 | JdGordon| | is this completly unrelated to buflib? |
| 11:22:17 | kugel | totally |
| 11:23:42 | JdGordon| | oh ok |
| 11:31:41 | kugel | english.voice is getting really close to audio buffer size on hwcodec, on the sim at least |
| 11:32:21 | kugel | only 10k room |
| 11:33:00 | JdGordon| | doesnt it keep a seek table if its too big so the whole file isnt loaded? |
| 11:33:13 | kugel | not on this one |
| 11:33:34 | kugel | well it does on all targets |
| 11:33:43 | JdGordon| | seriously time to consider forking hwcodec |
| 11:33:43 | kugel | the voice file has a seek table |
| 11:34:03 | kugel | but only on lowmem swcodec the case where a voicefile doesnt fit is actually handled |
| 11:34:24 | JdGordon| | wow, really? |
| 11:34:33 | JdGordon| | I thught that was there specifically for hwcodec? |
| 11:34:56 | kugel | you thought wrong :) |
| 11:38:15 | | Join chrooted_mother [0] (~Burninato@ool-18bc6682.dyn.optonline.net) |
| 11:43:33 | | Join Buschel [0] (~chatzilla@p54A3B871.dip.t-dialin.net) |
| 11:44:02 | Buschel | jhMikeS, [7]: thanks for fixing the nano2g USB issue −− works as expected now |
| 11:45:23 | [7] | kugel: no, that wouldn't work, because the size of that struct being too small is the root cause of the problem :) |
| 11:46:19 | [7] | jhMikeS: why should the dblbuf be more than char aligned? |
| 11:47:23 | Buschel | but: I again see unexpected re-buffer activities on the nano2g. use case: buffering is finished, then skipp to the next song. often I see flash read-accesses even though everything has been buffered −− those rtead-accesses have a short duration (so, they do not re-fresh the full buffer) |
| 11:47:50 | [7] | that's probably another bug :) |
| 11:50:14 | kugel | [7]: ah ok, I thought it was an alignment problem |
| 11:50:38 | Buschel | [7]: yes, looks like FS #12309 strikes back |
| 11:50:38 | fs-bluebot | http://www.rockbox.org/tracker/task/12309 font buflib: mass storage activity when skipping buffered tracks? (bugs, closed) |
| 11:52:03 | [7] | kugel: the proper fix for this would probably adding 56 payload bytes to the struct - or possibly renaming the struct to usb_ctrlreq_header or something, and wrapping that into another struct which will get used in this place |
| 11:55:50 | [7] | Buschel: can't reproduce that with the couple of testing mp3s that are currently on my nano2g |
| 11:59:26 | bertrik | tbh, I see lots of little weird stuff (including mass storage activity when I don't expected), but in the past week I've been using mostly the clip zip, which is so new that I guess I can't really report bugs (although I strongly suspect these are general bugs, not target-specific ones) |
| 12:00 |
| 12:02:12 | * | user890104 sees [7]'s nickname and remembers about FS #12233 |
| 12:02:12 | fs-bluebot | http://www.rockbox.org/tracker/task/12233 iPod 6G/Classic: LCD not displaying rockbox correctly if using emCORE >= r746 (patches, unconfirmed) |
| 12:03:01 | [7] | aw right.... |
| 12:03:15 | [7] | another thing that needs to go in before 3.10 |
| 12:04:21 | [Saint] | It does? |
| 12:04:31 | [Saint] | Is the classic being promoted? |
| 12:06:39 | user890104 | [7]: is the so-called "usbfix" in the svn, or it was merged in your changes from last night? |
| 12:07:58 | [7] | [Saint]: I don't think so, but I want to have a somewhat consistently working state in the 3.10 branch |
| 12:08:01 | Buschel | bertrik: I could not reprodcue this on my iPod Video as well. somehow I suspect this is depending on the theme |
| 12:08:56 | [Saint] | Well...theme affecting the core in ANY way is a bug for sure. |
| 12:09:02 | Buschel | unneeded rebuffering or flash/disk access will reduce the battery runtime −− especially for the HDD targets where the spinup takes a lot of power |
| 12:09:14 | [Saint] | And not technically possible, as I understand it. |
| 12:09:39 | [7] | user890104: I'm a bit hesitant about the usbfix |
| 12:10:01 | Buschel | [Saint]: we had issues with the font cache that resulted in rebuffering and disk spin up |
| 12:10:16 | [7] | there are reports of a regression (that I can't reproduce) in flyspray, and I don't want to take that risk |
| 12:10:58 | [7] | Buschel: your theme on nano2g => can't reproduce |
| 12:11:08 | Buschel | arghh |
| 12:11:21 | [7] | possibly the metadata of the files being played is related here? (assuming it's a font cache issue) |
| 12:11:29 | Buschel | hmm, you are using enmbedded album art? |
| 12:11:32 | [Saint] | Buschel: there was a specific theme that managed to screw up playback order a whole ago too iirc. |
| 12:11:40 | | Quit chrooted_mother (Ping timeout: 240 seconds) |
| 12:11:50 | [Saint] | *while ago |
| 12:11:50 | [7] | Buschel: yes |
| 12:12:00 | Buschel | ok, me too |
| 12:12:27 | [7] | i have just 4 aac files on my ipod right now |
| 12:12:27 | JdGordon| | [Saint]: ah yes, there was some truly wierd shit happening back then. I dont remember what the fix was |
| 12:12:59 | [Saint] | gevaerts found it I think. |
| 12:13:07 | [Saint] | Both the bug and the fix. |
| 12:15:19 | | Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) |
| 12:15:32 | | Quit pamaury (Changing host) |
| 12:15:32 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 12:15:39 | [Saint] | Buschel: have you tried stripping the tags from your test files? |
| 12:15:51 | [Saint] | (Just a thought) |
| 12:17:45 | Buschel | [Saint]: no, I am trying to bisect now |
| 12:18:21 | * | Buschel thinks we have too many regressions these days |
| 12:18:27 | caramou1 | Hello, can someone add me (OlivierKaloudoff) to WikiUsersGroup (changed from CaraMou to OlivierKaloudoff as requested), would like to update a broken link for Sony port |
| 12:18:37 | JdGordon| | fire the QA team! |
| 12:20:17 | [7] | caramou1: looks like you're in that group |
| 12:20:32 | [7] | so someone apparently beat me to it :) |
| 12:21:41 | [Saint] | caramou1: I did that for you days ago... |
| 12:22:26 | [Saint] | First as CaraMou, then as your actual name when it was discovered that it wasn't your real name. |
| 12:23:30 | caramou1 | something must be wrong then, cause I still get this message "Access check on Main.SonyNWA808Port failed. Action "CHANGE": access not allowed on web." |
| 12:23:56 | caramou1 | trying to purge my browser settings |
| 12:24:51 | [7] | caramou1: fixed |
| 12:24:51 | [7] | there was a typo :) |
| 12:24:52 | | Join Poodlemastah [0] (~root@h-241-205.a218.priv.bahnhof.se) |
| 12:25:32 | | Quit Poodlemastah (Client Quit) |
| 12:25:48 | [Saint] | [7]: oh...whoops, what did I mess up? I was fairly confident I did I straight c/p |
| 12:26:19 | [7] | s/OlivierKaloudouff/OlivierKaloudoff/ |
| 12:26:42 | [7] | pretty subtle |
| 12:26:53 | caramou1 | sniff still the same .. Still appers as OlivierKaloudouff in WikiUsersGroup |
| 12:27:16 | [7] | sure? (cache?) |
| 12:27:32 | caramou1 | great ! perfect, thank you |
| 12:30:16 | | Join Poodlemastah [0] (~LOLE@h-241-205.a218.priv.bahnhof.se) |
| 12:33:58 | Buschel | [7]: the rebuffer is *not* happening anymore when I have dircache switched on |
| 12:34:23 | | Quit Poodlemastah (Remote host closed the connection) |
| 12:34:41 | [7] | that means that it's unlikely to be said font cache bug hitting back :) |
| 12:35:22 | CIA-22 | New commit by theseven (r30908): iPod Classic: Set LCD controller configuration register during initialization and don't rely on the bootloader doing that (closes FS #12233) |
| 12:35:51 | Buschel | true, but the effect looks similar |
| 12:36:56 | kugel | err, voice is even exceeding the audiobuffer already |
| 12:37:09 | CIA-22 | r30908 build result: All green |
| 12:37:16 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 12:37:40 | [Saint] | kugel: on which target(s?) |
| 12:37:44 | kugel | hwcodec (sim) |
| 12:37:55 | [7] | now that's odd: getting "All green here" before svn ci even terminates :) |
| 12:38:01 | kugel | english.voice is 1.7MB, audiobuffer is less than 1.5MB |
| 12:38:02 | [Saint] | Time to fork hwcodec :p |
| 12:38:31 | [7] | [Saint]: and while we're at it, fork charcell as well :) |
| 12:38:41 | kugel | that's automatic |
| 12:39:14 | [Saint] | All the charcells are hwcodec, no? |
| 12:39:18 | kugel | seriously, forking hwcodec/charcell/sh would allow for a *massive* cleanup, since much of the old and ugly code is just for those |
| 12:43:07 | user890104 | [7]: while you're at it: FS #12209 |
| 12:43:07 | fs-bluebot | http://www.rockbox.org/tracker/task/12209 iPod 6g/classic usb product id (patches, unconfirmed) |
| 12:43:44 | [Saint] | Were...is that a release required fix? |
| 12:44:00 | [Saint] | *s/were/errr / |
| 12:44:24 | [Saint] | Silly me thought we were in a freeze. |
| 12:46:12 | kugel | amiconn: how to handle this? |
| 12:46:49 | kugel | [Saint]: no but it also doesnt affect a release target |
| 12:47:29 | [Saint] | I didn't think that mattered. |
| 12:49:35 | JdGordon| | there is a forum thread which has turned to discusison about forking |
| 12:49:49 | JdGordon| | it should have happened around 3.6~ |
| 12:49:55 | JdGordon| | or earlier even |
| 12:50:11 | kugel | [Saint]: non-release targets aren't affected by freeze, see recent clip zip work |
| 12:52:15 | | Quit liar (Quit: hallowed are the ori!) |
| 12:52:41 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 13:00 |
| 13:01:39 | CIA-22 | New commit by kugel (r30909): Fix broken voice when .talk files are used and voice buffer calculation. |
| 13:01:44 | CIA-22 | New commit by kugel (r30910): hwcodec: fix shrink_callback resuming playback wrongly, and add checks ... |
| 13:01:52 | [Saint] | Dragged from community: |
| 13:02:37 | [Saint] | JdGordon|: wouldn't the line height patch thing detecting the fallback case be the "right" way to do this? |
| 13:02:49 | * | JdGordon| thinks he needs to bite the bullet and rework the skin engine to only deal with offsets and a single buflib alloc, which grabs the full thing and resizes after load |
| 13:03:04 | CIA-22 | r30909 build result: 0 errors, 198 warnings (kugel committed) |
| 13:03:11 | JdGordon| | [Saint]: I said ignore it because I'd fix that in the code |
| 13:03:46 | [Saint] | Aha. |
| 13:04:00 | JdGordon| | which is also why I said one specific screen size |
| 13:04:24 | JdGordon| | I'm more interested in what can't be done currently than getting it perfect |
| 13:04:27 | | Quit Keripo (Quit: Leaving.) |
| 13:04:27 | CIA-22 | r30910 build result: 0 errors, 209 warnings (kugel committed) |
| 13:05:15 | [Saint] | Right. I'm with you now. What about icons? If the user theme fails to load, isn't it safe to assume that cabbie wont be there too? |
| 13:05:33 | [Saint] | Well...hmmm. no. |
| 13:05:41 | JdGordon| | do it as cabbie.sbs :) |
| 13:05:58 | JdGordon| | so its not so much the fallback as a flly loaded skin |
| 13:06:21 | CIA-22 | New commit by theseven (r30911): Commit FS #12209 by Vencislav Atanasov: iPod 6g/classic usb product id |
| 13:06:43 | [Saint] | That just made me think...why do we go to the fallback if the user theme fails, as opposed to trying cabbie (if the user theme isn't cabbie) |
| 13:06:56 | | Join GeekShadow [0] (~antoine@63.87.193.77.rev.sfr.net) |
| 13:07:12 | JdGordon| | cabbie isnt hardcoded |
| 13:07:35 | CIA-22 | New commit by kugel (r30912): Fix warning and typos. |
| 13:07:45 | [Saint] | Right...but can't it check if all of cabbie is present and able to be loaded? |
| 13:07:50 | CIA-22 | r30911 build result: 0 errors, 209 warnings (theseven committed) |
| 13:08:06 | JdGordon| | sure, maybe |
| 13:08:46 | [Saint] | If *that* fails...were definitely in trouble, so use the fallback :) |
| 13:08:56 | JdGordon| | also, I tihnk the viewport tag is going to need some extension to to relative alignment to other viewports |
| 13:09:11 | JdGordon| | and then magic to resize to X lines |
| 13:09:24 | JdGordon| | maybe not |
| 13:09:32 | CIA-22 | r30912 build result: All green |
| 13:09:35 | kugel | someone needs to check voice on hwcodec, before 3.10 preferably |
| 13:10:00 | [Saint] | I've nfi how far he got, or with what, but I know zagor has a skin resizong branch... |
| 13:10:34 | *** | Saving seen data "./dancer.seen" |
| 13:10:44 | JdGordon| | not so much skin resizing as screen resizing iiuc |
| 13:11:04 | JdGordon| | and svn branches suck ass, so wait for git to start looking into it :) |
| 13:11:12 | JdGordon| | fingers crosses is Soon :) |
| 13:11:27 | kugel | with proper git-svn setup they're git branches :) |
| 13:11:33 | [Saint] | Right...or, relative positioning. Something, anyway :) |
| 13:12:07 | JdGordon| | but yeah, if you could start cabbie.sbs (and put it on github please) then I'd be really greatful |
| 13:12:33 | * | JdGordon| would love to nuke apps/gui/bitmap/list.c and make the list skin handling code nicer |
| 13:12:42 | JdGordon| | nicer, less crash prone, better |
| 13:13:22 | JdGordon| | then once the entire ui is drawn by the skinengine, rip it out and use something better :) sdl perhaps! |
| 13:13:33 | JdGordon| | (I kid) |
| 13:13:39 | JdGordon| | (or do I?) |
| 13:15:01 | JdGordon| | kugel: is there any management on things calling core_alloc_max()? |
| 13:15:15 | kugel | no |
| 13:15:55 | kugel | you don't get anything with _maximum() if something else has the maximum |
| 13:16:29 | JdGordon| | I tink what I want to do is for each skin, alloc the entire buffer, load the skin file, shrink the buffer to the used size, then move onto the next one |
| 13:16:37 | JdGordon| | so obviously playback would have to be shutdown |
| 13:16:52 | kugel | but you can do audio_buffer_available() and ask for a specific size in which case the shrink callback will be used |
| 13:17:20 | JdGordon| | maybe, maybe not... I want to move everything to offsets so could even load into the plugin buffer perhaps and memmove to a handle |
| 13:17:40 | JdGordon| | this is going to be a massive branch :/ |
| 13:18:11 | kugel | it affects just a handful files no? |
| 13:19:16 | * | [7] wonders which openid provider he did use to register in gerrit |
| 13:19:18 | JdGordon| | sure, but those files are huge |
| 13:19:39 | JdGordon| | and we arent talking about single lines to change, there are probably hundreds of pointers that need fixing |
| 13:19:57 | amiconn | JdGordon|: Partial voice file is out of question on anything disk based. It could (and maybe should) be used on the Ondios though |
| 13:20:09 | JdGordon| | amiconn: oh? why? |
| 13:20:24 | amiconn | Battery usage and response time |
| 13:21:02 | JdGordon| | expand? |
| 13:21:30 | amiconn | kugel: If the voice file is that large, the parameters need to be adjusted. 1.7MB would have been too large even years ago |
| 13:21:49 | amiconn | JdGordon|: What do you mean? |
| 13:22:21 | amiconn | My own voice files are much smaller |
| 13:22:21 | JdGordon| | why would they increase? |
| 13:22:48 | JdGordon| | when the voice file isnt kept in memory the whole time anyway you have to do a open() and seek() already no? |
| 13:22:53 | amiconn | If you're browsing the menu it would (nearly) constantly access the disk to buffer more clips |
| 13:24:38 | amiconn | Also if you stopped browsing for a while, spinup time would cause a huge delay |
| 13:24:58 | amiconn | That delay already exists for .talk clips and is rather annoying, but unavoidable for them |
| 13:25:52 | amiconn | On hdd swcodec the voice file is only loaded once at boot (for hdd hwcodec it happens once each time you stop playback) |
| 13:26:18 | JdGordon| | opk |
| 13:26:49 | | Join caramou [0] (~Adium@184.218.20.81.dynamic.adsl.abo.nordnet.fr) |
| 13:27:18 | amiconn | For flash based stuff partial loading is nice because you don't need to keep an eye on voice file size, the extra battery consumption is much smaller, and there is no spinup delay |
| 13:27:32 | amiconn | Btw, there's some optimisation potential in that code |
| 13:28:18 | amiconn | The partial load caches 64 clips, and it allocates a buffer of 64 * max_clip_size for this. It finds the max clip size from the table in the header |
| 13:29:03 | | Quit caramou1 (Ping timeout: 258 seconds) |
| 13:29:03 | amiconn | But max_clip_size is a waste, because in the worst case it would cache the 64 largest clips - which most likely are smaller than 64 * the largest one |
| 13:29:46 | amiconn | If we change the voice file format a bit so that it includes a field for the necessary buffer size, the code would become (slightly) smaller *and* it would allocate less ram |
| 13:31:37 | | Join fyre^OS [0] (~nnscript@cpe-24-90-84-81.nyc.res.rr.com) |
| 13:34:24 | | Quit fyrestorm (Ping timeout: 258 seconds) |
| 13:36:43 | JdGordon| | is useing offsets any slower/worse than using pointers directly? |
| 13:37:02 | JdGordon| | I suppose it is irrelevant if we want a long term solution to skin buffers though |
| 13:49:56 | JdGordon| | how do we feel about these macros and typedef to replace every pointer in the skin engine? http://pastebin.com/MWtg9v75 |
| 13:50:48 | JdGordon| | struct foo *bar = SKINOFFSETTOPTR(skin_base, skin_base.bar, struct foo*) |
| 13:52:12 | amiconn | kugel: From a quick test it seems that voice is fixed now on swcodec (tested H1x0, mini2g and Color) |
| 13:52:25 | amiconn | Hwcodec still doesn't play .talk clips |
| 13:52:52 | amiconn | Furthermore I already hd two occasions for the MMC directory vanishing |
| 13:53:02 | amiconn | s/hd/had/ |
| 13:53:38 | amiconn | (testing on Ondio FM) |
| 14:00 |
| 14:07:28 | | Join ewloni [0] (~polo@ABordeaux-553-1-37-92.w92-162.abo.wanadoo.fr) |
| 14:07:43 | kugel | amiconn: check how big the voice file and the audio buffer is |
| 14:08:08 | amiconn | Audio buffer is 1.23 MB, voice file is 1.15 MB |
| 14:08:41 | kugel | close one |
| 14:08:47 | kugel | perhaps .talk doesnt fit? |
| 14:09:05 | amiconn | The it wouldn't talk anything, would it? |
| 14:09:20 | kugel | voice and talk is loaded separately |
| 14:09:44 | amiconn | The effect atm is that rockbox pretends the .talk clips aren't there. It spells all folders |
| 14:10:18 | amiconn | I just tried VOICE_PARTIAL_LOAD on Ondio. It works, but even then .talk clips don't |
| 14:11:13 | kugel | that still allocates the entire voicefile size |
| 14:11:19 | amiconn | nope |
| 14:11:34 | kugel | ah that was PROGRESSIVE_LOAD |
| 14:11:38 | amiconn | yep |
| 14:11:55 | amiconn | Since partial load works on Ondio, we can drop the separate progressive load |
| 14:12:25 | | Quit Xerion (Read error: Connection reset by peer) |
| 14:12:45 | amiconn | That was introduced way before swcodec, and was designed that way to keep it more similar to full load while avoiding the long load time of the entire voice file (since Ondio storage access is slow) |
| 14:13:43 | amiconn | Partial load does basically the same, with the additional benefit of not needing to take much care about voice file size |
| 14:15:04 | kugel | amiconn: does that work http://pastie.org/2820209 ? |
| 14:15:25 | amiconn | The disadvantages are more storage accesses when browsing around a lot (because it throws away clips) and a slight binsize increase (~400 bytes) |
| 14:15:51 | kugel | hwcodec needs to be PARTIAL_LOAD sooner or later, binsize and/or english.lang is going to get smaller |
| 14:18:00 | [Saint] | Is *not going to get smaller? |
| 14:18:49 | amiconn | kugel: For hdd based targets partial load is out of question |
| 14:20:44 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
| 14:21:14 | * | JdGordon| is very releived to realise that converting the skin engine to offsets isnt actually a difficult task, just huge |
| 14:22:31 | amiconn | kugel: Seems to work; I've done a simplified implementation though |
| 14:23:02 | amiconn | Please don't commit, I'll clean up my partial load patch (maily fixing comments and cleaning up the ifdefs) then commit at once |
| 14:23:15 | kugel | okay :) |
| 14:26:23 | | Join keyb_gr [0] (~chatzilla@p4FF023A0.dip.t-dialin.net) |
| 14:27:32 | | Quit zchs (Ping timeout: 260 seconds) |
| 14:27:35 | CIA-22 | New commit by pamaury (r30913): fuze+: scramble bootloader file |
| 14:28:34 | | Join zchs [0] (~zchs@ool-ad02eb3f.dyn.optonline.net) |
| 14:28:39 | | Join lebellium [0] (~chatzilla@91-65-137-216-dynip.superkabel.de) |
| 14:28:44 | pamaury | I'm now close to have a working a mkimxboot, hopefully just a few lines of code before it's ready |
| 14:29:14 | CIA-22 | r30913 build result: All green |
| 14:30:11 | CIA-22 | New commit by pamaury (r30914): imx233: don't include debug-imx233.c in bootloader |
| 14:30:14 | CIA-22 | New commit by pamaury (r30915): elftosb: add static |
| 14:31:50 | CIA-22 | r30914 build result: All green |
| 14:33:45 | CIA-22 | r30915 build result: All green |
| 14:39:26 | | Join y4n [0] (y4n@unaffiliated/y4ndexx) |
| 14:44:10 | | Quit sinthetek (Ping timeout: 258 seconds) |
| 14:48:32 | | Quit zchs (Ping timeout: 260 seconds) |
| 14:48:45 | | Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) |
| 14:48:55 | | Join zchs [0] (~zchs@ool-ad02eb3f.dyn.optonline.net) |
| 14:58:18 | CIA-22 | New commit by amiconn (r30916): Voice related fixes and cleaup ... |
| 14:59:50 | CIA-22 | r30916 build result: All green |
| 15:00 |
| 15:00:08 | kugel | amiconn: is all mmc so slow or why do you use mmc instead of ondio for the define? |
| 15:00:56 | amiconn | I kept it as it was. Using target specific ifdefs in apps/ is (or at least was) frowned upon |
| 15:01:04 | | Quit Buschel (Ping timeout: 260 seconds) |
| 15:01:36 | amiconn | MMC isn't that slow in general, it just happens that the Ondios are the only targets with STORAGE_MMC |
| 15:03:51 | amiconn | (Standard) MMC uses a transfer clock of 20 MHz and an 1 bit interface (very similar to standard SD which uses 26 MHz and an 1 bit interface) |
| 15:04:46 | amiconn | The problem on the Ondios is that MMC is hooked up to the CPU's SPI, and the highest possible clock is CPUCLK/4, i.e. 3 MHz |
| 15:04:59 | | Join Horscht [0] (~Horscht@p57B57C96.dip.t-dialin.net) |
| 15:05:00 | | Quit Horscht (Changing host) |
| 15:05:00 | | Join Horscht [0] (~Horscht@xbmc/user/horscht) |
| 15:05:21 | amiconn | 3 Mbps is 375 KBps |
| 15:06:44 | amiconn | The driver is actually quite efficient, i.e. we get very close to this theoretical limit, but that still means a complete voice file would take ~4 seconds to load |
| 15:07:08 | [Saint] | ...wow. |
| 15:07:35 | | Quit Horschti (Ping timeout: 258 seconds) |
| 15:07:52 | | Quit Horscht (Read error: Connection reset by peer) |
| 15:07:52 | [Saint] | Both the ondio users in the world will be impressed if that was sped up someway... ;) |
| 15:08:59 | | Join Horscht [0] (~Horscht@p57B57C96.dip.t-dialin.net) |
| 15:09:00 | | Quit Horscht (Changing host) |
| 15:09:00 | | Join Horscht [0] (~Horscht@xbmc/user/horscht) |
| 15:09:13 | amiconn | ehum... |
| 15:09:26 | [Saint] | I wonder if it would be sane to load voice files in batches based on the current screen? |
| 15:09:55 | amiconn | kugel: It seems using a target specific define is actually better. See Fuze+ delta... it's certainly not wanted to do partial load there, is it? |
| 15:10:29 | amiconn | (meaning Fuze+ had progressive load before) |
| 15:10:37 | *** | Saving seen data "./dancer.seen" |
| 15:15:40 | | Join sinthetek [0] (~sinthetek@cpe-174-111-026-094.triad.res.rr.com) |
| 15:15:41 | | Quit sinthetek (Changing host) |
| 15:15:41 | | Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek) |
| 15:17:00 | | Nick [sanyi] is now known as [Sanyi] (~sanyi@unaffiliated/alexanderc) |
| 15:25:34 | CIA-22 | New commit by amiconn (r30917): Make usage of TALK_PARTIAL_LOAD actually Ondio specific. MMC is not always slow. |
| 15:26:47 | amiconn | Hmm, the commit seems to hang here?! |
| 15:27:06 | bluebrother^ | it will return. Give it a while :) |
| 15:27:18 | bluebrother^ | it's been happening for me sometimes lately |
| 15:27:20 | CIA-22 | r30917 build result: All green |
| 15:27:34 | bluebrother^ | (though annoyingly sometimes even the build server was faster) |
| 15:28:09 | amiconn | Yes, that is the case right now |
| 15:28:33 | | Join Xerion [0] (~xerion@5419A766.cm-5-2c.dynamic.ziggo.nl) |
| 15:28:39 | amiconn | Oh it returned |
| 15:37:04 | bertrik | pamaury, did you figure out if the fuze+ has a GPIO to indicate reception of an RDS packet? |
| 15:40:33 | | Join Guest5141 [0] (~Guest5141@app22.chatmosphere.org) |
| 15:41:44 | | Quit Guest5141 (Client Quit) |
| 15:44:01 | | Quit Horscht (Ping timeout: 260 seconds) |
| 15:46:30 | | Join Horscht [0] (~Horscht@p57B57C96.dip.t-dialin.net) |
| 15:46:31 | | Quit Horscht (Changing host) |
| 15:46:31 | | Join Horscht [0] (~Horscht@xbmc/user/horscht) |
| 15:48:00 | | Quit Horscht (Client Quit) |
| 15:52:16 | [Saint] | kugel: s/freeze/release/? |
| 15:52:42 | [Saint] | (Wrt: mailing list) |
| 15:53:25 | | Part ewloni ("WeeChat 0.3.6") |
| 15:58:31 | | Quit caramou (Quit: Leaving.) |
| 15:59:45 | | Join Horscht [0] (~Horscht@p57B57C96.dip.t-dialin.net) |
| 15:59:45 | | Quit Horscht (Changing host) |
| 15:59:45 | | Join Horscht [0] (~Horscht@xbmc/user/horscht) |
| 16:00 |
| 16:36:57 | | Join chkktri_ [0] (chikakitaa@ip-78-139-196-175.danet.in) |
| 16:36:58 | | Quit chkktri (Read error: Connection reset by peer) |
| 16:47:20 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
| 16:48:07 | kugelp | [Saint]: a/freeze/branch/ actually |
| 16:49:07 | [Saint] | *almost* the same ;) I just certianly didn't think you meant to say freeze. |
| 16:53:24 | | Part Llorean |
| 17:00 |
| 17:10:41 | *** | Saving seen data "./dancer.seen" |
| 17:18:25 | funman | hm what happens if i write to rockbox-committers with a different address from the one i'm subscribed? |
| 17:18:54 | funman | my mail is silently discarded and i should send it again with the right From: address? |
| 17:19:54 | Bagder | yes |
| 17:20:12 | Bagder | but we saw your mail |
| 17:20:27 | funman | hm weird |
| 17:20:48 | funman | perhaps anyone can reply to a mail sent to the list? |
| 17:21:41 | | Nick [Sanyi] is now known as [sanyi] (~sanyi@unaffiliated/alexanderc) |
| 17:25:09 | Bagder | llorean did ~10 hours ago |
| 17:29:46 | [Saint] | He's (technically) a committee. |
| 17:29:51 | [Saint] | *er |
| 17:30:08 | [Saint] | Yeah...colour me shocked too :p |
| 17:30:51 | [Saint] | (Note: humour) |
| 17:35:59 | [Saint] | The committers list is a bit weird, though. As there's some very non-active (past) commiters on it, and some rather recently active (current) commiters that aren't. |
| 17:37:02 | funman | it's only used to mention RSB (re)election and propose new committers |
| 17:38:10 | | Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) |
| 17:41:01 | Bagder | [Saint]: we invite _all_ committers to it |
| 17:41:21 | Bagder | if someone isn't on it, that's his/hers decision/fault |
| 17:41:39 | pamaury | bertrik: no, I haven't looked at it, I'm working on mkimxboot right now but I can give it a try if you have some code |
| 17:54:54 | | Join hilbert [0] (~hilbert@adsl-89-217-41-10.adslplus.ch) |
| 17:55:53 | gevaerts | [Saint]: I only reproduced it |
| 17:59:16 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 18:00 |
| 18:00:29 | | Join thomasjfox [0] (~thomasjfo@dslb-088-065-031-164.pools.arcor-ip.net) |
| 18:00:31 | | Quit thomasjfox (Changing host) |
| 18:00:31 | | Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) |
| 18:17:36 | | Quit liar (Remote host closed the connection) |
| 18:23:58 | | Join nosa [0] (~m00k@adsl-74-235-79-106.clt.bellsouth.net) |
| 18:25:31 | | Quit nosa-j (Ping timeout: 252 seconds) |
| 18:25:31 | | Nick nosa is now known as nosa-j (~m00k@adsl-74-235-79-106.clt.bellsouth.net) |
| 18:27:18 | | Join mystica555 [0] (~Mike@71-211-218-103.hlrn.qwest.net) |
| 18:31:31 | | Join Thra11 [0] (~thrall@174.112.113.87.dyn.plus.net) |
| 18:36:37 | n1s | [7]: seems r30905 included the usbfix patch, was that intentional? |
| 18:39:08 | | Join Buschel [0] (~chatzilla@p54B6688C.dip.t-dialin.net) |
| 18:39:15 | [7] | ouch |
| 18:40:16 | [7] | i did actually check the diff of the following commit, but apparently didn't realize I had a months-old local change when committing that cleanup for a warning that only existed because of that local change :/ |
| 18:40:58 | [7] | when are we going to branch? I'd like to commit that to the trunk, but not to the release branch for now |
| 18:41:15 | [7] | should I go for reverting it in the branch or reverting it now and then recommitting it once we've branched? |
| 18:41:41 | n1s | i've been uncertain of haow to go forward with the usb patch since people reported less reliable usb on nano2g |
| 18:42:05 | [7] | I've never been able to get hold of one of the people affected by that |
| 18:42:35 | [Saint] | My transfer speeds dropped dramatically with an early version of it. |
| 18:42:48 | [7] | can you try with current svn head vs. r30904? |
| 18:43:14 | [7] | current head has the patch applied, r30904 doesn't |
| 18:43:42 | [Saint] | I can, yep. Not immediately though. |
| 18:46:18 | [Saint] | Android has seen my nanos don't get a lot of love these days. |
| 18:47:22 | funman | [7]: please add a comment for the char [64] added in r30906 |
| 18:48:26 | | Join The_Seeker [0] (~seeker@5ac8990f.bb.sky.com) |
| 18:51:18 | | Quit domonoky (Quit: Leaving.) |
| 19:00 |
| 19:00:58 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
| 19:10:20 | | Quit The_Seeker (Quit: The_Seeker) |
| 19:10:45 | *** | Saving seen data "./dancer.seen" |
| 19:27:31 | | Quit n1s (Ping timeout: 244 seconds) |
| 19:27:56 | | Quit Buschel (Ping timeout: 260 seconds) |
| 19:33:44 | * | jhMikeS wants to destroy that autoscan nag on the FM screen (and it not remembering the scan/preset setting between entries into the screen) |
| 19:33:59 | | Quit ReimuHakurei (Quit: Leaving...) |
| 19:33:59 | | Nick Reimu_Hakurei is now known as ReimuHakurei (~znc@reimuhakurei.net) |
| 19:35:06 | | Join n1s [0] (~n1s@nl118-175-223.student.uu.se) |
| 19:35:07 | | Quit n1s (Changing host) |
| 19:35:07 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 19:35:19 | [Saint] | jhMikeS: I seem to recall the fms recalled the scan/preset selection in the past. |
| 19:36:39 | jhMikeS | When? |
| 19:36:52 | [Saint] | It definitely *should*. |
| 19:37:11 | | Quit stoffel (Remote host closed the connection) |
| 19:37:32 | jhMikeS | It keeps jumping me back to preset |
| 19:39:14 | [Saint] | I've only played with it in the sim, which may give a different result. But I recall it working as intended. This was some many moons ago though, and my recollection may by broken. |
| 19:39:46 | * | jhMikeS always remembers it being sucky and naggy |
| 19:40:20 | [Saint] | I certainly remember wanting to strangle that nag screen. |
| 19:40:52 | * | pamaury has always been unsatisfied by the fm screen, it never worked the intuitive way for, and never remember my last freq |
| 19:40:58 | jhMikeS | "hello tuner enthusiast, who you like to purchase some presets today? if you act now, you get two for the nag of one." |
| 19:42:32 | * | [Saint] always thought the FM frequency should be saved as a config setting. |
| 19:43:04 | jhMikeS | the frequency is saved, but my refusal to scan is not, nor is my preferred tuning method |
| 19:46:28 | | Join ReimuHak_ [0] (~reimu@wireless.sit-co.net) |
| 19:48:14 | jhMikeS | This RDS stuff probably needs to mind error correction if it doesn't already since it gets corrupt strings at times |
| 19:49:45 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
| 19:50:10 | pamaury | jhMikeS: the si7043 chip already does error correction I think, but clearly if the chip doesn't do it, one absolutely needs to do it |
| 19:50:37 | pamaury | *si4703 |
| 19:51:04 | jhMikeS | so maby the 4701 doesn't? sometimes I see oddball garbage chars |
| 19:51:13 | | Join The_Seeker [0] (~seeker@5ac8990f.bb.sky.com) |
| 19:51:28 | pamaury | jhMikeS: 470x doesn't do RDS when x<3 |
| 19:51:37 | jhMikeS | Why's it working? |
| 19:51:46 | pamaury | and we don't have rds support |
| 19:52:00 | jhMikeS | I modded the patch to work on gigabeat S |
| 19:52:19 | pamaury | which patch ? |
| 19:52:19 | jhMikeS | FS #12370 |
| 19:52:20 | fs-bluebot | http://www.rockbox.org/tracker/task/12370 RDS support for Si4701/Si4703 (Sansa Clip Zip proof-of-concept) (patches, new) |
| 19:52:50 | pamaury | are you sure you have si4701 ? |
| 19:53:55 | jhMikeS | Maybe I should double-check that. |
| 19:54:01 | pamaury | bertrik: I think you need to discard rds packets with too much errors corrected |
| 19:54:03 | | Join Buschel [0] (~chatzilla@p54B6688C.dip.t-dialin.net) |
| 19:54:12 | pamaury | that's written somewhere in the datasheet |
| 19:55:05 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
| 19:55:06 | jhMikeS | There is a contradiction in the datasheet, showing lack of regs/bits yet showing supporting RDS features |
| 19:58:23 | jhMikeS | showing up as 4702 in the regs...wtf. Probably I misremembered? |
| 19:58:26 | pamaury | jhMikeS: perhaps try something like this: in si4700_rds_read_raw, read register 0xA and if bits 9:10=0b11, then discard packet |
| 19:58:46 | | Quit ReimuHak_ (Quit: Leaving...) |
| 19:58:57 | | Join ReimuHak_ [0] (~reimu@wireless.sit-co.net) |
| 19:59:06 | pamaury | even then, the si4702 is not supposed to have rds support :-/ |
| 20:00 |
| 20:00:30 | | Join GermanMushroom [0] (~c@s5146db6a.adsl.wanadoo.nl) |
| 20:02:37 | jhMikeS | even the hardware info shows 4701 and I believe even the IC physically showed that on two boards |
| 20:02:38 | | Quit Thra11 (Ping timeout: 248 seconds) |
| 20:02:59 | jhMikeS | so, it's chips with different firmware apparently |
| 20:04:14 | jhMikeS | regardless of theory, it's reading it :) |
| 20:04:58 | [Saint] | Nice discovery. |
| 20:05:00 | pamaury | interesting, it means some other chips might have rds |
| 20:05:25 | pamaury | jhMikeS: can you try what I suggested for rds, to see if the weird characters go away |
| 20:06:18 | jhMikeS | sure |
| 20:06:43 | * | jhMikeS wonders if it was a different model that failed certain test and was sold as "4701' |
| 20:07:49 | jhMikeS | hmmm...we're not using "verbose mode" |
| 20:08:12 | pamaury | jhMikeS: when reading register 0xA, you want to read it and not use the masked value probably |
| 20:08:36 | pamaury | (stating the obvious but we never know :)) |
| 20:09:05 | [Saint] | Find another gigabeat s owner? Should be pretty easy to tell if you got a random substituted chip then. |
| 20:09:37 | jhMikeS | pamaury: well, it said "verbose mode only" |
| 20:09:55 | jhMikeS | [Saint]: don't know any except here :) |
| 20:10:13 | jhMikeS | so, they should come here, rather that I go to them :) |
| 20:10:36 | pamaury | hum true, then perhaps you need to enable it, let me reread it |
| 20:10:44 | [Saint] | Well...I meant via here, not irl :) |
| 20:12:02 | pamaury | but the datasheet suggest that in non-verbose mode an invalid block is not notifie |
| 20:12:03 | pamaury | d |
| 20:13:19 | | Part The_Seeker |
| 20:13:36 | pamaury | you can always have a try at enabling verbose mode and see what happen when checking for errors |
| 20:16:13 | bertrik | 4701 and 4703 support RDS, 4700 and 4702 do not |
| 20:16:19 | | Join Thra11 [0] (~thrall@87.114.138.255) |
| 20:18:55 | * | jhMikeS enabling and compiling |
| 20:22:16 | jhMikeS | not seeing bad chars right away. it's not a constant problem but occasionally they show |
| 20:23:26 | bertrik | right now, missing any packet in a message, means missing the entire message |
| 20:23:53 | bertrik | but either is not a big problem IMO |
| 20:24:32 | jhMikeS | yeah, I am seeing bad packets and having it rejecting but now caught a few bad chars forcing the reception to be weak |
| 20:25:29 | jhMikeS | are you saying it should wait for the next loop to try again? |
| 20:26:34 | bertrik | at first I thought I'd just wait until all characters were received, even when not in order, but in practice station change the station name and radiotext very quickly |
| 20:27:17 | bertrik | so I'd get a half old/half new string |
| 20:28:11 | bertrik | The spec states specifically that stations should not change the station name, but in practice many of the commercial stations cycle traffic info in the station name. |
| 20:29:46 | jhMikeS | it's not that. I some plainly garbage strings. |
| 20:30:06 | jhMikeS | little boxes and odd chars |
| 20:31:28 | bertrik | I haven't seen bad characters so far, maybe that's a difference between si4701 and si4703 |
| 20:31:47 | jhMikeS | it happens when reception is near the threshold for RDS |
| 20:32:16 | jhMikeS | the verbose mode info seems to be available |
| 20:32:34 | bertrik | I thought we wouldn't need it |
| 20:32:44 | bertrik | but I have no objection to enabling it |
| 20:33:31 | bertrik | hm, garbage characters in the strings mean that the segment field survived in all packets, but that the text field did not |
| 20:35:44 | bertrik | Just thinking freely, but I think we could nicely do "album art" based on the PI code, since the PI code should be specific to the station, and even stay the same on different frequencies of the same station. |
| 20:37:20 | | Join robin0800 [0] (~robin0800@genkt-050-207.t-mobile.co.uk) |
| 20:39:33 | jhMikeS | I'm not really seeing any improvement with verbose mode |
| 20:41:26 | CIA-22 | New commit by pamaury (r30918): imxtools: add const and set pointer to NULL on free to avoid double free |
| 20:41:30 | CIA-22 | New commit by pamaury (r30919): imxtools: add function to free instruction |
| 20:42:15 | pamaury | jhMikeS: perhaps the chip doesn't do error correction correctly ?! ;) |
| 20:42:36 | bertrik | jhMikeS, you're using an si4701, right? I don't see the verbose mode stuff in the si4701 datasheet (but it could still be there anyway) |
| 20:43:16 | CIA-22 | r30918 build result: All green |
| 20:43:36 | pamaury | bertrik: is the si4701 datasheet available on the internet ? I can only find the 4703 one |
| 20:44:04 | CIA-22 | New commit by pamaury (r30920): Introduce mkimxboot to build bootloader images for the i.MX (only the fuze+ currently). Still not integrated in rbutil |
| 20:44:07 | | Quit GermanMushroom (Ping timeout: 252 seconds) |
| 20:45:00 | CIA-22 | r30919 build result: All green |
| 20:45:24 | bertrik | pamaury, google for si4700-B15rev1_0 |
| 20:45:29 | jhMikeS | well, it is in fact showing up as 4701. I read again and bit 9 is set. |
| 20:45:42 | pamaury | thanks |
| 20:46:28 | CIA-22 | r30920 build result: All green |
| 20:46:38 | jhMikeS | 3 bits were allocated away from FIRMWARE and moved to REV beween 0/1 and 2/3 |
| 20:47:08 | | Quit y4n (Quit: PANTS OFF!) |
| 20:47:14 | bertrik | yes, I noticed that, I inferred that bit 9 was the indicator for RDS or not |
| 20:47:33 | bertrik | perhaps a slightly dirty hack :) |
| 20:48:14 | jhMikeS | or a clean one :) |
| 20:48:21 | | Quit robin0800 (Ping timeout: 253 seconds) |
| 20:51:12 | jhMikeS | bsi4700-b15rev1_0 appears like it's some preliminary junk, partly missing things for 4701 |
| 20:53:44 | | Join robin0800 [0] (~robin0800@genkt-057-079.t-mobile.co.uk) |
| 20:55:01 | jhMikeS | maybe sometimes it just plain can't detect errors? what range of characters is legal in a string? |
| 20:55:16 | | Join GermanMushroom [0] (~c@s5146db6a.adsl.wanadoo.nl) |
| 20:55:40 | bertrik | the si4702/03 datasheet mentions something about a RDS high performance mode flag RDSPRF 06h[9]=1 |
| 20:55:53 | bertrik | it's not mentioned later in the register description though |
| 20:56:22 | bertrik | actually, I think there can be a few encoding, I just assumed plain ASCII for now |
| 21:00 |
| 21:01:15 | pamaury | jhMikeS: error detection is always possible normally |
| 21:01:27 | pamaury | at least knowing if what you've got is correct or not |
| 21:01:47 | | Quit robin0800 (Ping timeout: 258 seconds) |
| 21:07:01 | | Join robin0800 [0] (~robin0800@149.254.61.225) |
| 21:09:28 | jhMikeS | is it possible the parser is putting together bits that don't belong next to one another? |
| 21:10:49 | *** | Saving seen data "./dancer.seen" |
| 21:11:30 | | Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) |
| 21:11:38 | pamaury | hum in fact, it's possible that some invalid data is considered valid but this is extremely unlikely |
| 21:13:41 | bluebrother^ | ok guys, I'm going to release Rockbox Utility 1.2.11 unless someone speaks up in the next couple of minutes. |
| 21:13:41 | | Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) |
| 21:13:46 | jhMikeS | since I don't have a freak tuner afterall, something else seems to be going. it says it does all the error handling. |
| 21:14:29 | saratoga | bertrik: higher PCLK did decrease runtime on the clip+, from about 17 hours to 15 hours |
| 21:14:39 | saratoga | next i'll try higher PCLK and lower FCLK |
| 21:15:27 | bertrik | bluebrother^, let me check clip zip support again please |
| 21:16:18 | bluebrother^ | bertrik: sure. |
| 21:16:26 | jhMikeS | maybe weird things are being encoded here and ascii isn't a valid assumption |
| 21:18:41 | bertrik | bluebrother^, ok, it's detecting the clip zip correctly (when "disabled" targets are enabled) |
| 21:22:34 | bertrik | jhMikeS, it's supposed to patch only packets together if they come in the right sequence, if not, it should start waiting for the first packet of a new message |
| 21:23:24 | bertrik | Could you just remove the existing rds_event without side effects? It was already there from the ipod fm remote tuner, so I didn't want to touch it too much. |
| 21:23:52 | bertrik | or perhaps I don't understand how it's supposed to work |
| 21:24:35 | jhMikeS | bertrik: it doesn't seem the radio screen updates if it's not there :\ |
| 21:25:05 | bluebrother^ | bertrik: ok, so I'm going to push the release then. |
| 21:25:12 | jhMikeS | I also have a suspicion polling the buffers without an "ok" from the parser probably leads to this |
| 21:26:28 | n1s | i thought we already knew the beasts tuner was capable of rds and someone did a dirty proof of concept a while ago |
| 21:26:38 | jhMikeS | hmmm...ah, seems it waits before placing data there |
| 21:27:14 | | Quit robin0800 (Ping timeout: 256 seconds) |
| 21:27:19 | jhMikeS | n1s: I probably wasn't here. I remeber seeing the registers in action, but that was it. |
| 21:29:49 | n1s | yeah i saw that too when hacking on the driver but i think someone whipped up something that decoded the messages in the debug menu or something, i might have dreamt that though, anyways, not important |
| 21:33:16 | n1s | hah, i think i wasn't entirely wrong |
| 21:34:24 | bertrik | I did make something in the past and looked at it together with AlexP on his beast, but I didn't have an RDS capable target myself |
| 21:34:50 | n1s | bertrik: yes, i fond that in the logs |
| 21:34:53 | n1s | found |
| 21:34:59 | n1s | february 2009 :( |
| 21:35:08 | n1s | s/(/)/ |
| 21:35:36 | | Quit Farthen (Excess Flood) |
| 21:36:18 | n1s | i think i was planning on looking into it but never got around to it, i don't use the radio and here rds is only used for stupid ads anyway |
| 21:36:22 | | Join Farthen [0] (~Farthen@2a01:4f8:101:2a4:0:bc28:b2e1:9) |
| 21:36:28 | CIA-22 | New commit by bluebrother (r30921): Rockbox Utility: bump version to 1.2.11. |
| 21:36:59 | pamaury | are we releasing a new version of rbutil ? |
| 21:37:09 | bluebrother^ | pamaury: yes |
| 21:37:19 | * | bluebrother^ spots yet another copy of bin2c |
| 21:37:34 | bluebrother^ | I need to get that cleanup finished I was working on months ago |
| 21:38:02 | pamaury | yes I introduced a copy of bin2c but realized a few minute ago there was one in tools/ |
| 21:38:09 | CIA-22 | r30921 build result: All green |
| 21:38:59 | bluebrother^ | I wanted to merge bin2c with ipod2c, and we have some bin2c versions that aren't identical (the mkamsboot version behaves differently) |
| 21:39:19 | pamaury | differently in which way ? (I copied this one) |
| 21:40:57 | CIA-22 | New commit by pamaury (r30922): mkimxboot: fix bootloader load address, replace call by jump on final call to have a clean boot |
| 21:41:02 | bluebrother^ | the mkamsboot version can process multiple input files, while others can't. |
| 21:41:19 | pamaury | ah yes |
| 21:41:59 | | Join [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940) |
| 21:42:26 | CIA-22 | r30922 build result: All green |
| 21:42:44 | bluebrother^ | nothing that couldn't be combined via a few command line arguments. |
| 21:42:55 | bluebrother^ | and the ipodpatcher variant adds a different header iirc. |
| 21:43:07 | | Join [Saint__] [0] (~Saint]@unaffiliated/saint/x-8516940) |
| 21:45:01 | | Quit [Saint] (Ping timeout: 252 seconds) |
| 21:45:32 | | Quit Buschel (Ping timeout: 259 seconds) |
| 21:46:11 | CIA-22 | New commit by bluebrother (r30923): Tag Rockbox Utility 1.2.11 release. |
| 21:46:30 | | Quit [Saint_] (Ping timeout: 256 seconds) |
| 21:49:24 | | Join robin0800 [0] (~robin0800@149.254.60.167) |
| 21:50:30 | bertrik | jhMikeS, one tricky thing is that the si4700_detect function is called before si4700_init, so the mutex is not initialised yet during si4700_detect |
| 21:53:35 | jhMikeS | oops, that's bad :) |
| 21:55:40 | | Join kugel_ [0] (~kugel@rockbox/developer/kugel) |
| 21:55:41 | | Quit kugel (Remote host closed the connection) |
| 21:55:42 | | Nick kugel_ is now known as kugelp (~kugel@rockbox/developer/kugel) |
| 21:55:57 | bertrik | it's needed for the clip+ which can have either an rda5802 or a si4702 fm tuner, and the difference is detected by reading the device id |
| 22:00 |
| 22:03:01 | pamaury | Zoiah: ping |
| 22:03:01 | | Quit robin0800 (Quit: Leaving) |
| 22:03:10 | | Quit Thra11 (Ping timeout: 252 seconds) |
| 22:04:06 | jhMikeS | where's the code for that? |
| 22:04:46 | pamaury | I've finally put the instructions to build the Fuze+ bootloader on the wiki |
| 22:06:11 | | Quit [Saint__] (Read error: Connection reset by peer) |
| 22:06:15 | | Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) |
| 22:06:48 | jhMikeS | nvm, got it |
| 22:07:24 | | Quit kugelp (Remote host closed the connection) |
| 22:09:07 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 22:09:09 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
| 22:09:42 | | Quit guymann (Ping timeout: 276 seconds) |
| 22:10:20 | | Quit TheLemonMan (Quit: WeeChat 0.3.6) |
| 22:11:01 | | Join guymann [0] (~charles@66-159-172-106.adsl.snet.net) |
| 22:11:36 | jhMikeS | I think RADIO_EVENT will have to sneak back in for now too |
| 22:12:05 | Torne | Doh, we have a new committer since i last caught git up from svn |
| 22:15:40 | | Quit thomasjfox (Remote host closed the connection) |
| 22:16:18 | jhMikeS | really, perhaps radio events should use the event system much like playback does |
| 22:17:46 | | Part Zagor |
| 22:20:04 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 22:22:21 | | Quit hilbert (Quit: Computer has gone to sleep.) |
| 22:22:28 | saratoga | pamaury: since the install for the Fuze+ is so similar to AMS, maybe it would make sense to make mkimxboot use the mkamsboot? |
| 22:22:50 | pamaury | so similar ? |
| 22:22:59 | | Join hilbert [0] (~hilbert@adsl-89-217-41-10.adslplus.ch) |
| 22:23:23 | pamaury | the only similar part is putting a file at the root of the fs |
| 22:23:34 | saratoga | well similar from a users stand point |
| 22:23:57 | pamaury | yes but that's not the job of mkamsboot |
| 22:24:04 | pamaury | that's the job of the code in rbutil |
| 22:24:25 | saratoga | ok |
| 22:25:05 | | Quit benedikt93 (Quit: Bye ;)) |
| 22:25:05 | pamaury | the problem is that this installation method is really specific to the fuze+, I know if at least one other imx233 target which doesn't work the same way so it would make sense to integrate the Fuze+ with the AMS ones perhaps |
| 22:27:29 | | Quit GermanMushroom (Ping timeout: 260 seconds) |
| 22:28:08 | saratoga | are you ready to release a bootloader? |
| 22:29:11 | saratoga | did anyone test FS #12352 on a D2 (non-plus)? |
| 22:29:12 | fs-bluebot | http://www.rockbox.org/tracker/task/12352 Charger detection for newer Cowon D2+ (pcf50635 equipped) (patches, unconfirmed) |
| 22:29:23 | saratoga | assuming nothing breaks i'd like to commit it |
| 22:29:37 | pamaury | I would prefer to wait for some other people to test it |
| 22:31:26 | Torne | argh, how on earth do we have 97 different file extensions in our tree :) |
| 22:32:39 | [Saint] | C/c H/c WPS/wps BMP/bmp etc? |
| 22:32:54 | Torne | Nope |
| 22:32:57 | Torne | actually different ones |
| 22:32:58 | Torne | :) |
| 22:33:03 | [Saint] | Then...wow. |
| 22:33:48 | * | Torne is having fun with .gitattributes |
| 22:36:32 | * | jhMikeS considers statically initialized objects like pthreads has |
| 22:40:04 | | Join Teasp00n [0] (~troy@125-236-228-222.adsl.xtra.co.nz) |
| 22:45:31 | | Quit ReimuHak_ (Quit: Leaving...) |
| 22:45:47 | | Join ReimuHak_ [0] (~reimu@wireless.sit-co.net) |
| 22:50:14 | | Quit Stummi (Quit: Bye!) |
| 22:50:44 | JdGordon| | are we still in freeze? |
| 22:51:07 | bluebrother^ | according to the topic, yes |
| 22:51:57 | JdGordon| | next release we chain alexp to an internet connection so it doesnt drag out :) |
| 22:53:27 | gevaerts | I'm not sure if he can really be blamed for this :) |
| 22:56:07 | bluebrother^ | Bagder: can you move Rockbox Utility 1.2.11 to the download server? http://www.alice-dsl.net/dominik.riebeling/rockbox/rbutil-releases/1.2.11/ |
| 22:56:21 | [Saint] | Sure he can! He probably won't deserve it, but we can still blame him. |
| 22:57:55 | jhMikeS | radio screen fails to update RDS lines automatically (because there's no UPDATE_ALL in ACTION_NONE upon a radio event) |
| 23:00 |
| 23:00:14 | JdGordon| | are the rds tags marked dynamic in libs/skin_parser/tag_table.c? |
| 23:00:21 | jhMikeS | no idea |
| 23:00:38 | jhMikeS | I can certainly look though :) |
| 23:01:06 | JdGordon| | yes they are |
| 23:01:22 | jhMikeS | not working though :\ |
| 23:01:35 | JdGordon| | someone really needs to rewrite the fm screen code :) |
| 23:03:15 | jhMikeS | mono/stereo status updates |
| 23:04:41 | jhMikeS | I wonder why its getting that ok but not the RDS |
| 23:08:21 | jhMikeS | I'm not sure but I think the Canadian station might be making more bad data than the US ones! |
| 23:08:37 | | Join metaphys [0] (~56206037@www.haxx.se) |
| 23:09:14 | jhMikeS | s/station/stations/ |
| 23:09:19 | | Quit metaphys (Client Quit) |
| 23:09:19 | bertrik | maybe they use more weird french characters!? |
| 23:09:30 | jhMikeS | might be |
| 23:09:49 | | Join metaphys [0] (~56206037@www.haxx.se) |
| 23:10:04 | jhMikeS | I don't have any other RDS tuners on hand to check em |
| 23:10:53 | *** | Saving seen data "./dancer.seen" |
| 23:12:55 | lebellium | Oh I see the word French :D |
| 23:14:24 | | Nick GeekShadow is now known as antoine_t (~antoine@63.87.193.77.rev.sfr.net) |
| 23:15:26 | jhMikeS | why is the f'ing skin not updating that ?!? |
| 23:16:38 | jhMikeS | ok, I totally wiped everything and rebuilt again and it looks like it's doing it now :\ |
| 23:18:03 | Bagder | bluebrother^: done now good sir! |
| 23:18:49 | jhMikeS | nope, still not quite right. clicking vol or whatever makes it show it before it's ready, but otherwise it waits for a full line |
| 23:20:30 | jhMikeS | In the first line, I usually see text fragments that end up in the second line |
| 23:21:18 | Torne | heh. this line ending nonsense is very entertaining |
| 23:21:29 | Torne | we have 7560 .c files and only 1431 of them have svn:eol-style set |
| 23:21:35 | Torne | and 35 of those are set *wrong* |
| 23:21:53 | jhMikeS | "JoviWant"/"or[]Mliv" :) not "Bon Jovi - Wanted Dead or alive" |
| 23:23:08 | funman | Torne: not again! |
| 23:23:21 | Torne | funman: yeah, i'm working out how to make git fix this all for us |
| 23:23:32 | funman | ignore that crap |
| 23:23:44 | jhMikeS | whuuuu? something git can't fix? |
| 23:23:45 | funman | make the 2 or 3 windows files use \r\n and the rest \n |
| 23:23:52 | Torne | funman: that's what i'm doing |
| 23:23:58 | Torne | it's just kinda fiddly |
| 23:25:58 | Torne | funman: the files which actually have wrong contents (which is quite a few) need to be changed. the actual svn metadata is not important as it will go away when we convert |
| 23:26:50 | | Join Scromple [0] (~Simon@115-64-195-104.static.tpgi.com.au) |
| 23:27:10 | | Quit n1s (Quit: Ex-Chat) |
| 23:28:07 | bluebrother^ | Bagder: thanks! |
| 23:33:36 | bertrik | jhMikeS, your rds v2 patch works for me. I get the impression that it takes a bit longer to receive the radiotext message |
| 23:34:14 | | Quit metaphys (Quit: CGI:IRC (EOF)) |
| 23:34:38 | jhMikeS | bertrik: not sure why it would take longer |
| 23:36:00 | bertrik | maybe the fmradio mutexes give more opportunity to switch away and not allow the RDS data to be read quickly enough |
| 23:44:26 | jhMikeS | what are the time constraints on that? they'll only switch away if contended |
| 23:44:35 | CIA-22 | New commit by torne (r30924): Bulk convert all DOS line endings to UNIX. ... |
| 23:44:41 | Torne | hooray |
| 23:45:40 | Torne | yes, i am a scumbag :) |
| 23:45:42 | jhMikeS | thing is, it could get quite a delay if in fact the thread that reads it isn't the current one |
| 23:45:48 | Torne | sorry for ruining all your blames :p |
| 23:46:18 | CIA-22 | r30924 build result: All green |
| 23:46:19 | gevaerts | Torne: *ruin*? svn blame will now point to you for everything! |
| 23:46:28 | Torne | Sure, but I'll ignore you :) |
| 23:46:40 | Torne | I can just assume all accusations that i've touched something are false now |
| 23:46:43 | Torne | Even if I really have :P |
| 23:47:05 | bertrik | jhMikeS, packets come in at about 11.5 packets/s, so I guess about 88 ms |
| 23:49:38 | | Quit liar (Remote host closed the connection) |
| 23:50:07 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 23:50:24 | jhMikeS | event with the bitbanging, the packets could be read in the ISR and queued to the thread for parsing |
| 23:51:14 | jhMikeS | I did up the thread priority, which should let it run asap (it should hardly ever be scheduled at that rate) |
| 23:52:22 | CIA-22 | New commit by torne (r30925): Convert one more file from DOS to UNIX. ... |
| 23:52:53 | Torne | right. now everything is UNIX apart from certain windows-specific files that are never edited by humans anyway (visual studio projects, and the cat/inf files for some device drivers) |
| 23:53:16 | | Quit lebellium (Quit: ChatZilla 0.9.87 [Firefox 8.0/20111102223350]) |
| 23:53:52 | CIA-22 | r30925 build result: All green |
| 23:54:56 | funman | Torne: git blame -w |
| 23:55:04 | Torne | funman: Indeed |
| 23:55:20 | Torne | But svn is too stupid to do that |
| 23:55:28 | Torne | so it won't work until we switch to git :) |
| 23:55:49 | JdGordon| | which is soon right? :) |
| 23:55:53 | Torne | Working on it! |
| 23:55:55 | Torne | This is one of the steps :p |
| 23:55:56 | | Nick JdGordon| is now known as JdGordon (~jonno@rockbox/developer/JdGordon) |
| 23:56:07 | Torne | Haven't had as much time to work on it these alst couple days as i'd hoped, personal stuff came up |
| 23:56:11 | Torne | but have done some things :) |
| 23:56:18 | | Join Keripo [0] (~Keripo@eng416.wireless-resnet.upenn.edu) |
| 23:56:51 | | Join metaphys [0] (~56206037@www.haxx.se) |
icon identifies that the person is a core developer (has commit access).