| 00:01:39 | | Quit bgs000 (Remote host closed the connection) |
| 00:03:19 | | Quit BHSPitMonkey (Quit: Ex-Chat) |
| 00:03:20 | | Quit bmbl (Ping timeout: 252 seconds) |
| 00:03:25 | | Join M3DLG [0] (~M3DLG@bb-87-81-252-83.ukonline.co.uk) |
| 00:08:11 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.3.82) |
| 00:17:05 | | Quit linuxstb (Ping timeout: 252 seconds) |
| 00:25:01 | | Join geertvdijk [0] (~geert@5ED780FA.cable.ziggo.nl) |
| 00:30:56 | saratoga | why doesn't the clipv2 define PLUGIN_USE_IRAM? |
| 00:32:47 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 00:32:56 | | Quit hebz0rl (Ping timeout: 260 seconds) |
| 00:39:02 | | Quit petur (Remote host closed the connection) |
| 00:44:20 | | Quit geertvdijk (Ping timeout: 276 seconds) |
| 00:46:02 | | Join yawny [0] (user36@pr0.us) |
| 00:47:52 | | Quit S_a_i_n_t (Ping timeout: 260 seconds) |
| 00:49:15 | | Join kisak_ [0] (~kisak@c-98-235-209-218.hsd1.pa.comcast.net) |
| 00:53:12 | | Quit halmi_ (Quit: halmi_) |
| 00:53:54 | | Quit adnyxo (*.net *.split) |
| 00:53:54 | | Quit elcan (*.net *.split) |
| 00:53:54 | | Quit kisak (*.net *.split) |
| 00:59:34 | | Join GeekShad0w [0] (~Antoine@204.150.204-77.rev.gaoland.net) |
| 00:59:42 | | Quit mirak (*.net *.split) |
| 00:59:42 | | Quit mikroflops_ (*.net *.split) |
| 00:59:42 | | Quit solexx (*.net *.split) |
| 00:59:42 | | Quit AlexP (*.net *.split) |
| 00:59:42 | | Quit arun (*.net *.split) |
| 00:59:42 | | Quit jordan` (*.net *.split) |
| 00:59:42 | | Quit mapi (*.net *.split) |
| 00:59:55 | | Quit ender` (Quit: Be wary of strong drink. It can make you shoot at tax collectors and miss. -- Robert A. Heinlein) |
| 01:00 |
| 01:00:32 | | Join mirak [0] (~mirak@85-171-108-160.rev.numericable.fr) |
| 01:00:32 | | Join mikroflops_ [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) |
| 01:00:32 | | Join solexx [0] (~jrschulz@e176110245.adsl.alicedsl.de) |
| 01:00:32 | | Join AlexP [0] (~ap@rockbox/staff/AlexP) |
| 01:00:32 | | Join arun [0] (~arun@unaffiliated/sindian) |
| 01:00:32 | | Join jordan` [0] (~jordan@jem75-13-78-235-252-137.fbx.proxad.net) |
| 01:00:32 | | Join mapi [0] (~mapi@KHP222006067242.ppp-bb.dion.ne.jp) |
| 01:00:37 | | Quit mirak (*.net *.split) |
| 01:00:37 | | Quit mikroflops_ (*.net *.split) |
| 01:00:37 | | Quit solexx (*.net *.split) |
| 01:00:37 | | Quit AlexP (*.net *.split) |
| 01:00:37 | | Quit arun (*.net *.split) |
| 01:00:38 | | Quit jordan` (*.net *.split) |
| 01:00:38 | | Quit mapi (*.net *.split) |
| 01:00:41 | | Join mikroflops [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) |
| 01:00:57 | | Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) |
| 01:00:57 | | Quit GeekShadow (Read error: Connection reset by peer) |
| 01:01:10 | | Join mirak [0] (~mirak@85-171-108-160.rev.numericable.fr) |
| 01:01:10 | | Join mikroflops_ [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) |
| 01:01:10 | | Join solexx [0] (~jrschulz@e176110245.adsl.alicedsl.de) |
| 01:01:10 | | Join AlexP [0] (~ap@rockbox/staff/AlexP) |
| 01:01:10 | | Join arun [0] (~arun@unaffiliated/sindian) |
| 01:01:10 | | Join jordan` [0] (~jordan@jem75-13-78-235-252-137.fbx.proxad.net) |
| 01:01:10 | | Join mapi [0] (~mapi@KHP222006067242.ppp-bb.dion.ne.jp) |
| 01:01:36 | | Part domonoky1 |
| 01:02:20 | | Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) |
| 01:03:13 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 01:05:29 | | Quit mikroflops_ (Ping timeout: 276 seconds) |
| 01:05:58 | | Quit linuxstb (Ping timeout: 246 seconds) |
| 01:06:51 | | Join m1ss1onto [0] (~62f86d07@giant.haxx.se) |
| 01:07:01 | | Quit m1ss1onto (Client Quit) |
| 01:12:31 | | Quit kyraxyg (Quit: CGI:IRC) |
| 01:35:47 | | Quit pamaury (Quit: Page closed) |
| 01:43:19 | | Quit Schmogel (Ping timeout: 245 seconds) |
| 01:45:24 | | Quit anewuser (Quit: for SELL 2 by the price of 1 now!) |
| 01:47:25 | *** | Saving seen data "./dancer.seen" |
| 01:48:28 | | Join hebz0rl [0] (~hebz0rl@dslb-094-217-139-252.pools.arcor-ip.net) |
| 02:00 |
| 02:03:51 | | Quit GeekShad0w (Quit: The cake is a lie !) |
| 02:13:50 | | Quit DerPapst (Quit: Leaving.) |
| 02:23:49 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 02:23:50 | | Quit bertrik (Changing host) |
| 02:23:50 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 02:26:04 | | Join Rob2223 [0] (~Miranda@p4FDC9227.dip.t-dialin.net) |
| 02:27:40 | | Quit hebz0rl (Quit: Ex-Chat) |
| 02:29:44 | | Quit Rob2222 (Ping timeout: 268 seconds) |
| 02:49:21 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
| 02:52:21 | soap | Unhelpful? http://forums.rockbox.org/index.php?topic=24738.msg166539#new |
| 02:53:29 | Unhelpful | interesting. i am not aware of anything the jpeg viewer *should* decode that the core loader does not :| |
| 02:54:01 | soap | IF, if (I don't know Macs) he had a "hidden" file extension...? |
| 02:54:12 | soap | (something easy to do in Windows) |
| 02:54:43 | Unhelpful | but that should be trouble for both, shouldn't it? |
| 02:54:47 | Llorean | I dunno |
| 02:54:54 | Llorean | cover.jpg.jpg would open fine in jpeg viewer |
| 02:54:57 | * | soap looks at Unhelpful to answer Unhelpful's question |
| 02:55:05 | soap | but cover.jpg.png? |
| 02:55:21 | Llorean | Don't we have a .png viewer? |
| 02:55:28 | soap | poor example then |
| 02:55:31 | Llorean | So that'd open in the png viewer but not work as album art |
| 02:55:35 | soap | cover.jpg.llorean |
| 02:55:51 | Unhelpful | no, great example! cover.jpg.png would open if you view it, but not as album art |
| 02:55:52 | Llorean | cover.jpeg.somethingelse wouldn't do anything in Rockbox I believe |
| 02:56:12 | Llorean | Both cover.jpg.jpg and cover.jpg.png could present the behavior he's seeing, I think |
| 02:56:21 | soap | that's what I was uncertain of, Llorean, IF the viewer would open it but the AA search would fail. |
| 02:56:23 | Unhelpful | how would cover.jpg.jpg? |
| 02:56:33 | Unhelpful | ohhhh... because AA search fails. |
| 02:56:39 | Llorean | Yup |
| 02:56:58 | Unhelpful | but wouldn't the RB file browser show the double extension? |
| 02:57:05 | soap | so back to the other implied question. Can Mac OS hide "true" extensions? |
| 02:57:14 | * | Unhelpful thinks trying to load it in the sim is the best idea. |
| 02:57:16 | Llorean | Unhelpful: I would assume so. Can Rockbox be set not to show extensions at all though? |
| 02:57:35 | saratoga | have him do an ls from the terminal |
| 02:58:08 | Llorean | Unhelpful: In "supported" you don't see extensions. |
| 02:58:17 | Unhelpful | Llorean: if so that's a potential problem - windows "hide common extensions" option has been an exploit target in the past because people don't think it odd that one file happens to show an extension, so they open file.jpg.exe |
| 02:58:24 | Llorean | So he would see "cover.jpg.jpg" as "cover.jpg" I assume |
| 02:58:51 | * | Unhelpful would say that *something* breaking AA search is the most likely cause here |
| 02:58:53 | Llorean | But his OSX browser window looks like it's showing extensions just fine. |
| 02:59:45 | soap | Llorean, rockbox has multiple "ways" not to show extensions at all. |
| 02:59:48 | Llorean | I'd also ask him how he synced his music |
| 03:00 |
| 03:00:00 | Llorean | Since the folder is 'iTunes Music" and he refers to removing the AA in iTunes |
| 03:00:08 | Llorean | Is it possible he used iTunes to sync it? |
| 03:00:15 | soap | I don't see how he synced his music to be an issue. |
| 03:00:26 | soap | IF that directory structure is of his device as I asked. |
| 03:00:31 | Llorean | It's not |
| 03:00:45 | Unhelpful | a less likely cause imo would be a loader bug... i don't think i've seen one in many many months |
| 03:00:46 | soap | then we know nothing. ;) |
| 03:00:56 | Llorean | At least, on the left bar I don't see anything that indicates a device is attached |
| 03:01:06 | Llorean | Unless "iDisk" is his iPod |
| 03:01:35 | soap | looking at it again I think that is a "shared" device - NAS? |
| 03:01:37 | Llorean | It looks like a network share or something, since it says "shared folder" but I don't know anything about OSX really |
| 03:01:46 | soap | ditto |
| 03:03:21 | soap | Simplest answer is that he doesn't have on his iPod what he thinks he has on his iPod. |
| 03:04:04 | soap | and since Llorean rightfully pointed out that the screenshot does not appear to be of the ipod itself we need to verify that fist. Thanks for chewing the fat on the other possibilities, though, Unhelpful. |
| 03:04:33 | Unhelpful | "the user is always wrong" ; |
| 03:04:53 | Llorean | "the user is likely to not realize you need *exactly* what you asked for, not 'approximately'" |
| 03:05:03 | Unhelpful | or that :) |
| 03:05:06 | Llorean | Though it's good to know other ways AA could be broken but not look like it (hidden extensions is a good one) |
| 03:05:28 | pixelma | looks like the Itunes content on his Mac which I've seen stored in nice "usual" subfolders on Macs at work |
| 03:06:37 | | Quit efyx (Remote host closed the connection) |
| 03:14:02 | soap | ahh, my post of desperation. "What version of Rockbox are you running?" |
| 03:15:51 | | Quit Llorean (Quit: Leaving.) |
| 03:15:53 | JdGordon1 | has anyone tried the fm skinning patch? |
| 03:18:48 | | Quit bertrik (Quit: sleep) |
| 03:19:18 | | Join Llorean [0] (~DarkkOne@adsl-99-158-45-131.dsl.hstntx.sbcglobal.net) |
| 03:19:26 | | Quit Llorean (Changing host) |
| 03:19:26 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
| 03:26:13 | | Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) |
| 03:27:17 | Blue_Dude | Any last words, wishes, comments, complaints, gripes or other assorted feedback on FS #11250. |
| 03:27:21 | Blue_Dude | ?? |
| 03:29:29 | JdGordon1 | Blue_Dude: hey, something I completly forgot about untill after I DC'ed on friday... the origoinal icon patch should have sat longer and been made more public only because it broke all themes with icons (I know its irrevlvant now but still...) |
| 03:30:19 | Blue_Dude | It did? The icons were referenced by enum. Confused why this would make themes not work. |
| 03:31:01 | JdGordon1 | it could also explain the large bump... the icon system loads a bmp strip and decides how big each is by height/enum_size |
| 03:31:17 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 03:32:13 | Blue_Dude | Hrm. That's odd. |
| 03:32:29 | JdGordon1 | so adding an icon wouldnt actually break anything, it would make each icon slightly shorter looking crap |
| 03:33:02 | Blue_Dude | I saw that behavior. It was fixed by reinstalling the new tango bmps. |
| 03:33:18 | JdGordon1 | yes, but that would only fix that icon set |
| 03:33:41 | JdGordon1 | as for 11250, I think it should also be settablee from a butotn press |
| 03:33:41 | Blue_Dude | Well yeah. A clean build would make the problem go away though. |
| 03:33:52 | JdGordon1 | only for themes using that icons set |
| 03:34:35 | Blue_Dude | Still confused. I changed all the icon sets to add the new icon. A fresh install would have fixed it. |
| 03:34:57 | Blue_Dude | Unless there are custom icon sets out there. Can't help those. |
| 03:35:28 | * | Blue_Dude frets about that. |
| 03:35:36 | Blue_Dude | Don't matter now though. |
| 03:36:57 | Blue_Dude | JdGordon1: I'm kinda looking forward to dumping all the menu code. You get the same functionality but the bin size is close to 1000 bytes less. |
| 03:37:55 | Blue_Dude | Anyone reproduce the wav resume bug? It crashes the player. |
| 03:38:17 | Blue_Dude | I'm going to have to report this... |
| 03:38:36 | JdGordon1 | It seems to me that one of the biggest benefits to the hotkey stuff is being able to really quyickly change it... having to find the menu sucks |
| 03:39:28 | Llorean | JdGordon1: What are the values for the list you regularly change it between? |
| 03:39:57 | JdGordon1 | I've personally never used it... |
| 03:40:12 | Llorean | So, why do you think it's something users would change frequently then? |
| 03:40:34 | Blue_Dude | Bug report is at FS #11255. |
| 03:41:09 | Llorean | Blue_Dude: Which players have you reproduced that on (and I doubt it's a 3.4 bug?) |
| 03:41:53 | Blue_Dude | Hey, JdGordon, put the hotkey setting on the quickscreen. }:-) |
| 03:42:14 | Blue_Dude | Llorean: e200. It's very recent, last couple of days. |
| 03:42:20 | Blue_Dude | Codec changes. |
| 03:42:31 | Llorean | Blue_Dude: you marked it as a 3.4 bug in the tracker, so you probably want to change that. |
| 03:42:46 | JdGordon1 | not all the playlist options are available tot he hotkeys right? |
| 03:42:56 | Blue_Dude | I've been off the net so I couldn't do a reversion check to pin down the exact revision. |
| 03:43:06 | Blue_Dude | k |
| 03:43:10 | Llorean | Blue_Dude: Does the size of the .wav file or anything matter? Can I just grab one a few seconds long from somewhere to reproduce with? |
| 03:43:35 | Llorean | Or channels, sample rate, etc. |
| 03:45:00 | Blue_Dude | I don't know. All I know is that it dumps in the middle of trying to set up. You can see the debug info in the sim, and it doesn't complete its load. |
| 03:45:45 | Blue_Dude | We had resume problems the last time the codec was updated too. |
| 03:45:48 | Llorean | Well the more information you can include in the bug report (for example, that it's reproduceable in the sim) the better. |
| 03:46:33 | Blue_Dude | k |
| 03:47:17 | Blue_Dude | I'll report the bug and leave it to the experts to nail down. If they can't reproduce, then I'll get more involved. |
| 03:47:27 | *** | Saving seen data "./dancer.seen" |
| 03:47:51 | Blue_Dude | I think I left simple enough instructions to reproduce. |
| 03:49:00 | Blue_Dude | JdGordon: Sorry, missed your comment. No, I'm not changing functionality yet. So far only Playlist Insert is coded. |
| 03:49:34 | Llorean | Blue_Dude: It's better to include as much useful information up front, so that when they're around to test it doesn't matter whether you're around or not. |
| 03:49:44 | | Nick JdGordon1 is now known as JdGordon (~jonno@123-243-140-31.static.tpgi.com.au) |
| 03:49:46 | Llorean | If they come to test, and need to ask something, they may not be able to do any more until you get back |
| 03:50:35 | Blue_Dude | That's pretty simple to change though, if you're interested. It would even be in order, since Playlist Insert is listed last in the enum. |
| 03:51:17 | Llorean | Blue_Dude: For example, I can't reproduce on my Gigabeats with a 16-bit 44.1khz WAV file |
| 03:51:28 | Blue_Dude | Llorean: nope, I'm done troubleshooting. If there are questions later, I'll answer them. I'll be very surprised if they can't reproduce it though. |
| 03:51:42 | Llorean | Well, be surprised. |
| 03:51:44 | Llorean | I can't reproduce. |
| 03:51:47 | Blue_Dude | OK, build a e200 sim and check it out. |
| 03:51:49 | Llorean | Current SVN as of 3 minutes ago. |
| 03:52:00 | Blue_Dude | Use a nice long one. |
| 03:52:09 | | Join chjurk [0] (~chjurk@2001:6f8:1c00:1fa::2) |
| 03:52:11 | Llorean | Why didn't you provide that info in the report then? |
| 03:52:19 | Blue_Dude | I did say e200 sim. |
| 03:52:25 | Llorean | You marked the report SWCODEC |
| 03:52:30 | | Part chjurk |
| 03:52:43 | Blue_Dude | Yep. Codec issue. SWCODEC. Follows. |
| 03:52:53 | Llorean | No, you marked the *player type* as sw-codec |
| 03:53:00 | Llorean | That means you think it occurs on all software codec players |
| 03:53:01 | Blue_Dude | Yes, so I did. |
| 03:53:21 | Blue_Dude | I think it's a reasonable probability. I didn't try them all out. |
| 03:53:26 | Llorean | Well, it doesn't. |
| 03:53:40 | Blue_Dude | OK, take ownership and fix it. |
| 03:54:13 | Llorean | Blue_Dude: Why don't you provide more details for how to reproduce it? |
| 03:54:20 | Llorean | Nobody can fix it if they can't reproduce it. |
| 03:54:27 | Llorean | You may have a problem wav file? |
| 03:54:55 | Blue_Dude | The wav file is a year old. I've been using it for testing for the last nine months. |
| 03:55:10 | Llorean | Yes, and maybe something about that type of .wav is broken, rather than all ones |
| 03:55:18 | Llorean | So knowing it sample rate, channels, bit rate, and other details could help |
| 03:55:19 | Blue_Dude | It crashes under those circumstances with a clean build. |
| 03:55:32 | Llorean | Not all .wav files are identical. There are many differences between them. |
| 03:55:41 | Blue_Dude | 16 bit 44.1 kHz, stereo. Plain vanilla. |
| 03:55:50 | Blue_Dude | I mean, really. |
| 03:56:19 | Llorean | Well, I can't read minds so I can't know thats what you're doing, and you were being oddly reluctant about refusing to state the properties of the file until now. |
| 03:56:35 | Llorean | Maybe attach a short .wav file sample to the task of one that definitely crashes with current SVN to make testing easier? |
| 03:57:28 | Blue_Dude | This is a total waste of my time. I've had an extremely long day. I'm going to commit my patch and go to bed. Take or leave the bug report. At this point I just don't care. |
| 03:57:38 | Llorean | Blue_Dude: Does it happen on players, or just the sim? |
| 03:57:56 | Llorean | Blue_Dude: Seriously, it's a waste of your time to *investigate a bug only you can currently reproduce*? |
| 03:59:00 | Blue_Dude | Yes, it is. It is not my bug. I just was the first to notice it. |
| 03:59:01 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 03:59:40 | Llorean | Blue_Dude: And so you refuse to answer even basic questions about the conditions? |
| 03:59:50 | Blue_Dude | 'Night. |
| 03:59:52 | | Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) |
| 03:59:53 | saratoga | usually codec problems impact all players, unless theres endianness or ASM involved |
| 04:00 |
| 04:00:13 | Llorean | saratoga: It doesn't happen on my Gigabeat S with current SVN |
| 04:00:22 | Llorean | Which is why I was trying to find out more. If it's SIM only that could be telling |
| 04:00:25 | JdGordon | it wont usually cross to hwcodec though |
| 04:00:25 | saratoga | i doubt the wav codec has any ASM, but it could be endian specific |
| 04:00:32 | saratoga | although x86 and arm are the same |
| 04:00:59 | Llorean | saratoga: Of course, it would also help (as I said) to know the details of the file being used. =/ |
| 04:02:07 | | Join Barahir_ [0] (~jonathan@frnk-590f4fdf.pool.mediaWays.net) |
| 04:02:49 | | Quit xavieran (Ping timeout: 246 seconds) |
| 04:03:22 | CIA-5 | New commit by Blue_Dude (r25905): FS #11250: Hotkey setting method changed to menu item vs button pres in context menu. Manuals updated to match. |
| 04:04:56 | | Quit saratoga (Ping timeout: 252 seconds) |
| 04:05:15 | | Quit Barahir (Ping timeout: 240 seconds) |
| 04:06:03 | | Quit amiconn (Disconnected by services) |
| 04:06:04 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 04:06:05 | | Quit pixelma (Disconnected by services) |
| 04:06:05 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 04:06:25 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 04:06:26 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 04:07:43 | | Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-hpopepfvtzdfbnnj) |
| 04:07:45 | CIA-5 | New commit by Blue_Dude (r25906): Fix red |
| 04:12:27 | | Quit linuxstb (Ping timeout: 248 seconds) |
| 04:14:16 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 04:16:05 | | Join ncfi1013 [0] (~ncfi1013@cpe-76-184-6-218.tx.res.rr.com) |
| 04:17:19 | ncfi1013 | does rockbox work on the ipod nano video 4th gen? |
| 04:18:07 | n1s | no |
| 04:18:44 | | Quit adnyxo (Ping timeout: 240 seconds) |
| 04:20:31 | ncfi1013 | http://graphics.dyscern.com/gr/images/nw/apple_ipod_video_nano_4g_black.jpg |
| 04:20:58 | JdGordon | OH... THAT ipod video nano 4g.... |
| 04:21:00 | JdGordon | still no |
| 04:21:01 | | Join kramer3d [0] (~kramer@unaffiliated/kramer3d) |
| 04:21:07 | ncfi1013 | just in case there is some confusion i found an image of what im talking about |
| 04:21:13 | Llorean | ncfi1013: The list of supported players is on the front page of the website. |
| 04:22:11 | ncfi1013 | is there any support for ipod in question in lucid? still running koala. |
| 04:22:21 | saratoga | ncfi1013: go ask the ubuntu people |
| 04:24:17 | | Join xavieran [0] (~xavieran@ppp118-209-75-190.lns20.mel4.internode.on.net) |
| 04:31:17 | | Join Zarggg_ [0] (~zarggg@2001:0:4137:9e76:0:fbf3:beb1:ba3d) |
| 04:34:04 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.2.6) |
| 04:34:50 | | Quit Zarggg (Ping timeout: 248 seconds) |
| 04:42:11 | | Join Curulan [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
| 04:46:08 | | Quit Zarggg_ (Ping timeout: 268 seconds) |
| 04:57:02 | | Join dys` [0] (~andreas@krlh-5f72fa37.pool.mediaWays.net) |
| 04:57:14 | | Quit xavieran (Ping timeout: 248 seconds) |
| 04:57:44 | | Quit linuxstb (Ping timeout: 240 seconds) |
| 04:58:12 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 04:59:26 | | Quit dys (Ping timeout: 276 seconds) |
| 05:00 |
| 05:00:49 | | Quit Barahir_ (Read error: Operation timed out) |
| 05:19:13 | | Join xavieran [0] (~xavieran@ppp118-209-75-190.lns20.mel4.internode.on.net) |
| 05:19:35 | | Quit linuxstb (Ping timeout: 276 seconds) |
| 05:20:05 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 05:47:30 | *** | Saving seen data "./dancer.seen" |
| 05:51:56 | | Quit fyre^OS (Read error: Connection reset by peer) |
| 06:00 |
| 06:00:43 | | Quit linuxstb (Ping timeout: 246 seconds) |
| 06:08:16 | | Join FlynDice [0] (~FlynDice@74.10.105.233) |
| 06:15:35 | | Quit FlynDice (Quit: Gotta go fly!) |
| 06:15:52 | | Join FlynDice [0] (~FlynDice@74.10.105.233) |
| 06:32:38 | | Nick dys` is now known as dys (~andreas@krlh-5f72fa37.pool.mediaWays.net) |
| 06:35:05 | FlynDice | Would someone explain the significance of having one's copywrite in the rockbox header attached to the beginning of each file. I am not particularly interested in claiming any credit for work I've done but if there is a legal significance for the rockbox project and I should be doing this I would like to know that! |
| 06:37:14 | S_a_i_n_t | FlynDice: I've often wondered about that myself, I *think* it has just become popular convention to put ones stam on something... |
| 06:37:18 | S_a_i_n_t | *stamp |
| 06:38:41 | saratoga | FlynDice: i think its just convention, we need to give copyright to someone, and since there is no Rockbox entity, we give it to whowever made the file |
| 06:39:18 | | Quit kramer3d (Ping timeout: 265 seconds) |
| 06:41:31 | FlynDice | saratoga: Thanks, So there's no legal issues to be concerned with if I don't bother with it is what I gather. |
| 06:46:17 | * | S_a_i_n_t adds a simple comment to the newest "hey, how can I remove DRM from my crippled Rhapsody files?" guy on the RB forums. |
| 06:53:09 | * | JdGordon thinks the backdrop size calculation is wrong... |
| 06:53:17 | JdGordon | #define LCD_BACKDROP_BYTES (LCD_FBHEIGHT*LCD_FBWIDTH*sizeof(fb_data)) |
| 06:53:44 | S_a_i_n_t | and, for the lamens of the group? |
| 06:56:46 | | Join mianos [0] (~mrfish@124-168-146-31.dyn.iinet.net.au) |
| 06:59:15 | saratoga | so if buschel's test_mem changes are correct, I get that IRAM on the Clipv2 is about 2x as fast as DRAM when unboosted, and 3x as fast when boosted |
| 06:59:34 | saratoga | clipv1 results don't look right to me, but they claim that DRAM is faster then IRAM |
| 07:00 |
| 07:02:09 | | Join Barahir [0] (~jonathan@frnk-590f6b41.pool.mediaWays.net) |
| 07:05:49 | | Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.2.95) |
| 07:07:36 | | Quit S_a_i_n_t (Ping timeout: 246 seconds) |
| 07:13:36 | | Nick S_a_i_n_t_ is now known as S_a_i_n_t (S_a_i_n_t@203.184.2.95) |
| 07:18:02 | | Quit S_a_i_n_t (Ping timeout: 248 seconds) |
| 07:26:19 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.2.132) |
| 07:27:14 | | Quit Horscht (Ping timeout: 240 seconds) |
| 07:28:22 | | Quit mirak (Quit: Ex-Chat) |
| 07:29:24 | | Join Horscht [0] (~Horscht2@xbmc/user/horscht) |
| 07:32:54 | | Quit FlynDice (Read error: Connection reset by peer) |
| 07:39:29 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 07:47:32 | *** | Saving seen data "./dancer.seen" |
| 07:47:32 | | Join esperegu [0] (~quassel@145.116.15.244) |
| 07:49:03 | JdGordon | amiconn: does that #define above look correct? |
| 07:54:59 | amiconn | Yes it does |
| 07:57:13 | JdGordon | trying to figure out why the skin buffer is apparnelty not big enough on grey targets |
| 07:58:00 | | Quit esperegu (Ping timeout: 246 seconds) |
| 07:59:03 | funman | any trick to make the clip+ crash really fast? i'm tweaking the equ settings but it takes 2 minutes or so |
| 08:00 |
| 08:00:21 | S_a_i_n_t | I would have thought you'd be the best one for advice when it came to crashing sansas ;) |
| 08:00:51 | funman | i would like to |
| 08:00:53 | ThomasAH | funman: enabling voice menus and voice clips and browsing through menus and songs |
| 08:01:14 | funman | i need to install voice files though ? |
| 08:04:17 | funman | nevermind I found it |
| 08:06:47 | funman | i have a langs/english.voice, language set to english, voice menus enabled (by default anyway) but nothign is spoken |
| 08:07:03 | | Join robin0800 [0] (~quassel@general-ld-216.t-mobile.co.uk) |
| 08:07:39 | funman | hm i got the clipv1 file though, perhaps that matters |
| 08:08:32 | | Join esperegu [0] (~quassel@145.116.15.244) |
| 08:09:14 | | Quit Boldfilter (Quit: Boldfilter) |
| 08:12:32 | funman | thanks it works! |
| 08:13:28 | funman | it crashes 3 instructions after returning from set_cpu_frequency(), but loading the content of given address show it's correct |
| 08:16:03 | funman | ThomasAH: what is the biggest number of items you could ever hear before it crashed? |
| 08:16:20 | S_a_i_n_t | heh, this is new...instructions on RB-IRC for "how do I *crash* my clip" as opposed to "how can I make it more stable" ;) |
| 08:16:46 | funman | S_a_i_n_t: it really is "how can i reproduce crashes and test possible bugfix" |
| 08:17:40 | S_a_i_n_t | Frankly, I'm surprised it was so easy to do. |
| 08:18:11 | S_a_i_n_t | you could have just gone back to few 1000 revisions :) |
| 08:18:19 | funman | hm? |
| 08:18:20 | S_a_i_n_t | s/to/a/ |
| 08:18:58 | S_a_i_n_t | It was a remark on how greatly the stability has increased of late. |
| 08:19:13 | * | funman doesn't agree |
| 08:19:29 | S_a_i_n_t | you *don't* think they're more stable? |
| 08:19:37 | funman | no |
| 08:20:08 | | Quit robin0800 (Remote host closed the connection) |
| 08:22:34 | funman | file context menu isn't voiced correctly it seems |
| 08:23:34 | | Join FlynDice [0] (~FlynDice@74.10.105.233) |
| 08:25:04 | JdGordon | amiconn: so "LCD_HEIGHT*LCD_WIDTH*LCD_DEPTH/8" is wrong? |
| 08:25:16 | JdGordon | or that will give a less accurate size? |
| 08:26:58 | amiconn | It is wrong on targets where depth < 8 and the width or height (depending on pixel packing) is not an integer multiple of the pixel block size |
| 08:27:03 | funman | ThomasAH: hm first time I tried it crashes on the 3rd item and now I just listened to at least 30 items and it still works (using the same code) |
| 08:27:10 | amiconn | Afaik we only have two such targets - the twi Minis |
| 08:27:24 | amiconn | s/twi/two/ |
| 08:27:33 | JdGordon | it will give a value too small or too big? |
| 08:27:38 | amiconn | Too small |
| 08:27:55 | JdGordon | cheers, tat could explain things |
| 08:28:19 | amiconn | You're testing on mini? |
| 08:28:41 | JdGordon | yeah |
| 08:29:08 | JdGordon | but the issue is that fm skins just wont load because there isnt enough room, when there should b |
| 08:29:35 | S_a_i_n_t | what happened to resizable skin-buffer? |
| 08:29:43 | * | S_a_i_n_t looks for kugel. |
| 08:30:44 | amiconn | The mini should load fm skins? |
| 08:30:51 | JdGordon | no |
| 08:31:44 | CIA-5 | New commit by jdgordon (r25907): use a better value for the needed skin buffer size |
| 08:31:59 | JdGordon | that might make it possible for it to load fonts though |
| 08:32:25 | amiconn | Hmm, other targets shouldn't have problems with that backdrop buffer size definition... |
| 08:33:32 | JdGordon | right now its set to grab 2 full depth screens + 1 backdrop per skinnable screen (2 now) |
| 08:33:35 | amiconn | The old definition was short by 55 bytes on mini (half a byte per line) |
| 08:33:55 | JdGordon | ok, so not enough o make a difference |
| 08:34:43 | JdGordon | the old way used too much on mono screens apparently? |
| 08:36:02 | JdGordon | it bumpbed the buffer from 22KB to 31KB on the mini |
| 08:36:13 | CIA-5 | New commit by jdgordon (r25908): fix red |
| 08:37:25 | amiconn | Umm, mono doesn't support backdrops... |
| 08:38:30 | amiconn | So probably LCD_BACKDROP_BYTES is set to 0 for them |
| 08:39:13 | amiconn | However, some mono themes may use a fullscreen pseudo-backdrop. I'm not sure though - my wps'es don't use any bitmaps |
| 08:41:05 | JdGordon | haha yeah woops |
| 08:43:06 | CIA-5 | New commit by jdgordon (r25909): mono targets dont support backdrops so dont use that #define |
| 08:43:20 | S_a_i_n_t | WPS'es without .bmps (or at least one animation for that matter) make S_a_i_n_t cry... |
| 08:44:58 | amiconn | i only ever made own wps'es for the archoses |
| 08:45:03 | | Quit CaptainKewl (Remote host closed the connection) |
| 08:45:21 | amiconn | I use the bitmap archos one on a few other targets, on the others I just use the builtin one |
| 08:45:42 | amiconn | (builtin default, *not* cabbie) |
| 08:45:48 | S_a_i_n_t | I guess I should start branching out into themeing for targets I don't own. |
| 08:45:53 | * | amiconn can't stand cabbie for more than a few minutes |
| 08:47:05 | S_a_i_n_t | nor can I, I made my own Cabbie (guess you'd call it CabbieV5 going by the other " V's " on the themesite which I find tolerable...but I still don't really like it. |
| 08:47:15 | * | S_a_i_n_t isn't a big fan of yellow. |
| 08:47:30 | | Quit esperegu (Quit: No Ping reply in 180 seconds.) |
| 08:47:35 | funman | you have a clip though? ;) |
| 08:47:52 | JdGordon | My only gripe with cabbie on the smaller screens is too much text together so its hard to see what is what... unless I use my multifont version |
| 08:47:55 | | Join esperegu [0] (~quassel@145.116.15.244) |
| 08:48:12 | S_a_i_n_t | JdGordon: Same. |
| 08:48:20 | amiconn | My biggest gripe with cabbie is that it's bright-text-on-black |
| 08:48:26 | S_a_i_n_t | My cabbie manages to make it look "decent" IMO |
| 08:48:56 | S_a_i_n_t | funman: for about a week, I'm *really* not a fan of that screen. |
| 08:49:04 | S_a_i_n_t | I got rid of it pretty quickly. |
| 08:49:06 | amiconn | Well, /me rates functionality >> design |
| 08:49:24 | S_a_i_n_t | sure, but it's possible to have both. |
| 08:49:35 | S_a_i_n_t | especially on "large screen" targets. |
| 08:49:53 | saratoga | the combination of small and lots of text in cabbie on the clip makes it really hard to use while running in my experience, otherwise i like it |
| 08:49:58 | S_a_i_n_t | One of the reasons I like themeing the Nano so much is trying to find balance between the two. |
| 08:50:23 | amiconn | I have more relevant information with builtin status bar + builtin wps than with cabbie. And bright-text-on-black makes my eyes bleed after a few minutes |
| 08:52:15 | CIA-5 | New commit by jdgordon (r25910): revert those last few... |
| 08:53:29 | amiconn | High resolution battery status and high resolution volume (~15 steps each), to name just two |
| 08:54:17 | S_a_i_n_t | it's possible to put "progressbar logic" in battery/volume now...so, the resolution is WAY higher than the builtin whatever. |
| 08:54:19 | JdGordon | 15 steps is hardly high res |
| 08:54:32 | JdGordon | 15 pixels is hardly high anything |
| 08:54:38 | * | S_a_i_n_t agrees with this. |
| 08:55:28 | amiconn | Well, iirc cabbie only has 4 battery levels |
| 08:55:40 | JdGordon | that sounds wrong |
| 08:55:41 | S_a_i_n_t | progressbar style battery/volume looks *so* sexy...and saves a LOT of skin buffer. |
| 08:55:49 | JdGordon | and it should be using the bar style now anyway :) |
| 08:55:54 | amiconn | And volume in the builtin status bar changes to numeric during adjustment |
| 08:55:57 | S_a_i_n_t | best thing for the wps/sbs since...the last really good thing ;) |
| 08:56:40 | amiconn | I also have time (on targets with rtc - not so much to actually get the time, but rather to easily notice when the rtc is off) and disk activity |
| 08:57:16 | S_a_i_n_t | the built in bar is just so....ugly, for lack of a better word. |
| 08:57:40 | funman | ThomasAH: how does http://pastie.org/952230 work for you ? |
| 08:57:42 | S_a_i_n_t | I have all those things in my .sbs, but *prettier* ;) |
| 08:57:56 | amiconn | The builtin bar is completely sufficient on most of my targets. |
| 08:58:54 | S_a_i_n_t | sufficient, sure. Ugly, sure. ;) |
| 08:59:00 | amiconn | My largets screen targets are 220x176 (H300 and iPod Color) - and there it's a bit small |
| 08:59:03 | S_a_i_n_t | totally subjective I guess. |
| 08:59:39 | S_a_i_n_t | I *could* make you an .sbs that looks exactly like the built-in bar but larger? |
| 08:59:51 | S_a_i_n_t | and uses better logic for drawing battery/vol etc. |
| 09:00 |
| 09:00:00 | * | amiconn forgot the beast, but that's not much wider anyway |
| 09:00:01 | S_a_i_n_t | it's an option...and I wouldn;t mind. |
| 09:00:21 | amiconn | If it is larger... it wouldn't fit on the archos screen |
| 09:00:28 | amiconn | That's in fact where it comes from |
| 09:00:40 | S_a_i_n_t | I couldn't do it immediately, but I'm sure more people than you would get a kick out of it. |
| 09:00:43 | n1s | the default bar is *tiny* on the beast |
| 09:00:56 | JdGordon | and miniscule on the mr500 :) |
| 09:01:16 | * | S_a_i_n_t wonders how it looks on the mini2440 ;) |
| 09:02:27 | amiconn | n1s: Tiny yes, but still recognisable |
| 09:02:34 | * | amiconn doesn't use the beast much |
| 09:03:21 | * | Llorean thinks the default bar looks fine on the beast, but wouldn't want it much smaller than that |
| 09:03:27 | ThomasAH | funman: I'll try it later today ... currently in familiy interrupt |
| 09:03:33 | amiconn | I have 4 targets (among 15) I use most. They're all non-colour, and quite old. I still prefer them for the sound quality, flexibility, and readability without backlight |
| 09:03:49 | funman | ThomasAH: can't you disable interrupts? .. oops that only work with computers .. ;) |
| 09:03:59 | n1s | sure but it's a bit hard to read :) |
| 09:04:01 | amiconn | Iriver H180, Archos Recorder, Mini G2, Archos Player (in that order) |
| 09:04:39 | ThomasAH | funman: works with family, too, but probably triggers a NMI by the police :) |
| 09:05:27 | n1s | amiconn: of my 3 targets, the beast sounds the best by far IMO |
| 09:05:38 | n1s | (h300, c200, beast |
| 09:05:45 | n1s | ) |
| 09:05:49 | ThomasAH | funman: and away again ... (additionally I have a patch for the clip* manual in preparation) |
| 09:06:04 | funman | cool! |
| 09:06:04 | amiconn | I'd expect the H300 to sound better than the beast overall... a bit noisier though |
| 09:06:24 | amiconn | The c200 audio codec is crappy though |
| 09:06:37 | Llorean | The noise on the H100 is pretty terrible in quiet conditions, if the H300 is the same, I wouldn't put it up against the Beast. |
| 09:06:56 | Llorean | The c200/e200 shouldn't even really be talked about when discussing sound quality. :) |
| 09:07:23 | amiconn | Well, the UDA1380 has a bit of background hiss. Imo it still sounds better than those WM* codecs overall |
| 09:07:40 | amiconn | That's subjective of course |
| 09:08:04 | n1s | yeah |
| 09:08:22 | Llorean | When I'm in conditions I can't hear the hiss, I love my H100. |
| 09:08:45 | JdGordon | get tinitus and then the codec really wont matter much :) |
| 09:08:54 | Llorean | But the lack of it gives me the perception that the Gigabeast sounds "cleaner" |
| 09:09:28 | n1s | i don't use the h300 at all basically, since it is about twice the size of the beast (and i think the beast sounds better) |
| 09:10:09 | CIA-5 | New commit by uchida (r25911): wave/wave64 LIST chunk parser ... |
| 09:11:11 | n1s | i like the size and battery time of the c200 though |
| 09:11:43 | n1s | how are the clip + or v2 with battery time and sound quality? |
| 09:12:02 | funman | hum i notice weird battery indicator when charging with the OF on clipv2 |
| 09:12:13 | Llorean | n1s: Great sound quality (to me at least) |
| 09:12:13 | funman | n1s: battery time is very good (next to 20 hours) |
| 09:12:23 | Llorean | Er, regular clip |
| 09:12:24 | funman | there is some hiss though |
| 09:12:25 | Llorean | Not clip+ |
| 09:12:30 | * | Llorean assumes the clip+ is at least comparable. |
| 09:12:41 | funman | (with rockbox) |
| 09:13:01 | Llorean | I didn't notice a hiss like the iRivers have on my Clip at least. |
| 09:13:04 | funman | clipv1 battery is awful although it just got better (a bit below 8 hours for mp3) |
| 09:13:05 | * | Llorean didn't look for it either, though |
| 09:14:00 | | Join ucchan [0] (~ucchan@softbank126102048040.bbtec.net) |
| 09:15:07 | JdGordon | ucchan: Hi |
| 09:15:45 | ucchan | Hi JdGordon |
| 09:16:10 | JdGordon | I had a hard time understanding your reply to the embedded AA task |
| 09:16:49 | JdGordon | is there any reason why you dont try allocating enough buffer for the image, and if the buffer is full then just fail and try next time? |
| 09:17:35 | saratoga | ucchan: are you uchida? |
| 09:18:37 | n1s | funman: both the v2 and the + have card slots, right? |
| 09:18:46 | JdGordon | only the + |
| 09:18:54 | saratoga | fuze and + do, not the clip |
| 09:18:57 | n1s | ah |
| 09:19:03 | ucchan | image data size is big (10 -32 kB), then there is possible which the buffer is filled. |
| 09:19:28 | JdGordon | yes, but regular AA has that problem also |
| 09:19:29 | funman | clipv2 is to clipv1 what fuzev2 is to fuzev1, something like what e200v2 is to e200v1 |
| 09:19:31 | ucchan | then I gave up that dthe data does not store in it |
| 09:20:13 | funman | same case, different shit |
| 09:20:27 | saratoga | ucchan: heres the tta patch I made ages ago |
| 09:20:29 | saratoga | http://duke.edu/~mgg6/rockbox/tta.patch |
| 09:20:39 | saratoga | ignore the change to vorbis, its just junk |
| 09:20:41 | ucchan | And, the codec buffer is not used too much effectively. |
| 09:20:50 | saratoga | unfortunately, its not anywhere near working |
| 09:21:00 | saratoga | decodes one frame and then crashes I think |
| 09:22:44 | ucchan | saratoga, Is the performance enough? |
| 09:22:59 | saratoga | ucchan: i don't know, but the format is very simple, so I think it should be fast |
| 09:23:29 | saratoga | ucchan: ffmpeg took the same decoder source and improved it further: http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavcodec/tta.c;h=4bdfd73fbd706c28a335a274a7772870177318bd;hb=HEAD |
| 09:23:46 | | Quit wincent_balin (Quit: Verlassend) |
| 09:23:48 | saratoga | if you want to port TTA, starting with their code instead of that patch might be a good idea :) |
| 09:23:54 | ucchan | I checked my tta codec is slow (base on original tta hardware player's). for iPod, about 104 % |
| 09:24:11 | saratoga | you already ported it? |
| 09:24:12 | ucchan | sorry more less 95 -100 % |
| 09:24:45 | ucchan | My local environment. |
| 09:24:54 | saratoga | i'm sure it can be optimized |
| 09:25:14 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 09:25:16 | saratoga | gcc is likely to make a big mess of the filter |
| 09:25:32 | saratoga | rewriting it in assembly will probably help a lot on the ipod |
| 09:26:09 | ucchan | But I optimized decode logic, then my codec's speed is 130 % - 140% |
| 09:26:32 | saratoga | are you ready to commit it? |
| 09:29:20 | ucchan | I check only iPod. then I will send the tracker |
| 09:29:38 | saratoga | sounds good |
| 09:30:05 | ucchan | please wait for a moment... |
| 09:30:21 | saratoga | for codecs we require that they compile on all targets, but they don't have to work correctly right away (sometimes its months or years before they work on all devices ) |
| 09:31:39 | ucchan | There might be some problems because I am compiling only on iPod. |
| 09:34:22 | n1s | if it works on an arm target it should work fine on all arm and probably cf too |
| 09:34:43 | n1s | unless there are endianess issues of course |
| 09:39:45 | ucchan | tta original decoder, because the endian is considered, it might be unquestionable(may be...). |
| 09:39:56 | CIA-5 | New commit by funman (r25912): Update current usage for Fuzev1/e200v2/Clipv1 |
| 09:40:08 | | Join solexx_ [0] (~jrschulz@e176097029.adsl.alicedsl.de) |
| 09:41:50 | funman | clipv2 crashed in 7 minutes playing mp3 |
| 09:42:27 | saratoga | i had a crash every 20 minutes so with mine today |
| 09:42:46 | funman | i hoped i had the right fix :( |
| 09:43:33 | saratoga | sorry not today, friday |
| 09:43:37 | | Quit solexx (Ping timeout: 276 seconds) |
| 09:44:34 | funman | yesterday I listened to flac from µSD on Clip+ and it crashed with CPU boosted |
| 09:45:38 | saratoga | it took us years before the last disk issues were fixed on the e200v1 |
| 09:47:34 | *** | Saving seen data "./dancer.seen" |
| 09:48:41 | JdGordon | were the (random) clip playback issues ever fixed? |
| 09:48:56 | funman | according to the poll i made in the forum no |
| 09:51:01 | saratoga | JdGordon: for plain mp3 with nothign special going on its basically stable, but turn on too many features or skip through playlists and it'll crash |
| 09:51:21 | saratoga | or at least it'll deadlock |
| 09:51:35 | funman | recording errors (on fuzev2 at least) happen because we don't read from the fifo fast enough |
| 09:52:06 | funman | pcm playing + recording at the same time should be impossible afaik, i'm not sure why i didn't use DMA |
| 09:52:56 | | Join bmbl [0] (~Miranda@unaffiliated/bmbl) |
| 09:55:00 | | Quit pjm0616 (Read error: Connection reset by peer) |
| 10:00 |
| 10:02:13 | funman | ah i remember i couldn't get it to work at all |
| 10:02:21 | | Quit aberet (Ping timeout: 260 seconds) |
| 10:02:30 | funman | fred bauer helped a lot here |
| 10:06:40 | | Join stoffel [0] (~quassel@p57B4C3D9.dip.t-dialin.net) |
| 10:12:55 | funman | clip+ crashed too .. sigh |
| 10:13:11 | | Join komputes_ubuntu [0] (~komputes@ubuntu/member/komputes) |
| 10:16:17 | | Join Luca_S [0] (~5711b744@giant.haxx.se) |
| 10:20:01 | | Quit Curulan (Quit: Curulan) |
| 10:20:12 | | Quit CGL (Quit: Soy spammero http://wiki.n00b2hack.com.ve ---- \m/ d(>.<)b \m/) |
| 10:23:14 | | Join Zarggg [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
| 10:25:32 | | Quit Kitar|st (Ping timeout: 264 seconds) |
| 10:28:58 | ucchan | delay in sending, I send the tta codec the tracker (FS #11256) please confirm it |
| 10:30:23 | | Join Kitar|st [0] (~Kitar_st@BSN-182-71-75.dial-up.dsl.siol.net) |
| 10:31:59 | | Quit rvvs89 (Ping timeout: 246 seconds) |
| 10:32:00 | | Quit esperegu (Remote host closed the connection) |
| 10:32:37 | | Join rvvs89 [0] (ivo@bright-snat.ucc.asn.au) |
| 10:37:12 | | Join esperegu [0] (~quassel@145.116.15.244) |
| 10:37:45 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 10:40:18 | | Quit bmbl (Ping timeout: 252 seconds) |
| 10:41:59 | | Join bmbl [0] (~Miranda@unaffiliated/bmbl) |
| 10:42:39 | | Join pjm0616 [0] (~user@61.250.113.98) |
| 10:44:01 | | Join stoffel_ [0] (~quassel@p57B4C8E4.dip.t-dialin.net) |
| 10:44:29 | | Quit Luca_S (Quit: CGI:IRC) |
| 10:44:33 | | Quit stoffel (Ping timeout: 246 seconds) |
| 11:00 |
| 11:02:07 | | Quit dys (Ping timeout: 276 seconds) |
| 11:05:23 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 11:08:37 | | Quit komputes_ubuntu (Ping timeout: 276 seconds) |
| 11:09:23 | | Join dfkt [0] (~dfkt@unaffiliated/dfkt) |
| 11:12:17 | | Join Buschel [0] (~ab@p54A3B823.dip.t-dialin.net) |
| 11:27:40 | | Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) |
| 11:31:19 | | Quit petur (Quit: Leaving) |
| 11:31:32 | Buschel | saratoga: on an iPod 5.5G 24/100 MHz -> DRAM: 12-16/60-70 MB/s IRAM: 50/200. when taking the asm into account the measured IRAM speed is exactly what is expected when IRAM access has zero wait state. |
| 11:35:11 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 11:38:07 | | Join komputes_ubuntu [0] (~komputes@ubuntu/member/komputes) |
| 11:46:42 | | Join Schmogel [0] (~Miranda@p3EE22857.dip0.t-ipconnect.de) |
| 11:47:25 | funman | hm i have recording working with DMA but it sounds really bad |
| 11:47:36 | *** | Saving seen data "./dancer.seen" |
| 11:48:09 | funman | looking in audacity I see a bar at X frequency, where X is really close to the frequency of the DMA callback |
| 11:48:30 | | Quit freddy_ (Ping timeout: 252 seconds) |
| 11:49:09 | bertrik | Maybe some off-by-one error (just guessing). |
| 11:49:27 | funman | off-by-one-sample would hardly be hearable i think |
| 11:49:28 | bertrik | Can you post a wav somewhere? |
| 11:49:56 | funman | yes, what source material could I use? |
| 11:50:00 | | Quit Buschel (Ping timeout: 260 seconds) |
| 11:50:47 | bertrik | if there is one extra sample per block, it would give a frequency component at the inverse of the block size |
| 11:51:12 | bertrik | funman, can you sing? :P |
| 11:58:13 | funman | patch: http://pastie.org/952282 flac: http://rafael.carre.perso.sfr.fr/money.flac |
| 12:00 |
| 12:00:01 | funman | i only tested fuzev2 though |
| 12:00:31 | | Join freddy_ [0] (~freddy@p3E9E1D87.dip0.t-ipconnect.de) |
| 12:00:44 | | Quit antil33t (Ping timeout: 260 seconds) |
| 12:02:04 | funman | frequency looks alright |
| 12:02:38 | bertrik | yeah, but it's heavily quantized somehow |
| 12:04:54 | funman | quantized? |
| 12:05:56 | | Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) |
| 12:06:04 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
| 12:06:50 | bertrik | yes, it looks like there are only 8 levels for the audio signal |
| 12:07:06 | bertrik | (I'm looking at the flac in audacity) |
| 12:07:51 | funman | ok |
| 12:08:24 | funman | i2sin is set for 14 bits per sample, but samples should be transferred as 32 bits (16 bits + 16 bits) |
| 12:08:47 | funman | there is a 24 bits mode (32bits + 32bits) but i think rockbox expects 16 bits per sample PCM |
| 12:10:00 | funman | i talked about a problem with recording on ABI forum and noted rockbox recording had few levels, so perhaps this problem exists with current recording ? |
| 12:19:05 | | Join Jaykay [0] (~chatzilla@p5DC57141.dip.t-dialin.net) |
| 12:20:09 | | Quit shai (Quit: Leaving) |
| 12:20:39 | funman | bertrik: i put the patch on FS #11257 |
| 12:20:47 | | Join DerPapst [0] (~Alexander@p5797C680.dip.t-dialin.net) |
| 12:21:26 | bertrik | thanks |
| 12:22:15 | funman | http://www.anythingbutipod.com/forum/showthread.php?t=54060 <- discussion about recording problems in OF and rockbox |
| 12:27:28 | | Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) |
| 12:35:11 | | Join loveless [0] (~loveless@188-195-101-189-dynip.superkabel.de) |
| 12:35:42 | | Quit shaggy-h (Ping timeout: 240 seconds) |
| 12:38:39 | | Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 12:39:50 | loveless | anyone around here familiar with the usb code of the e200rpatcher? I am trying to use it for a different platform, but switching from PP502x to PP6100 seems to have broken the host usb code −− despite the fact that it should be completely identical. I can't seem to find out why this could be tha case. |
| 12:43:06 | loveless | any ideas on how to proceed with debugging this one? I don't want to waste any more time with my brute-force grep -r approach |
| 12:44:12 | JdGordon | e200rpatcher is just used to remove the upgrade blocker |
| 12:45:35 | gevaerts | JdGordon: it uploads code, which I assume is the point here |
| 12:45:59 | loveless | the problem is: the code builds fine but the host's usb_find_busses() or usb_find_deviced() (have seen any hanging) throw timeouts and i/o errors. |
| 12:47:12 | loveless | gavaerts: yes, I only use it for loading test code. but I am at a point where it felt right to get the code tree to switch to the correct platform |
| 12:48:52 | loveless | JdGordon: it worked fine for the pp6100 view as long as I was using the pp520x target. |
| 12:50:06 | JdGordon | ah fair enough |
| 12:50:34 | | Join Buschel [0] (~ab@p54A3D223.dip.t-dialin.net) |
| 12:53:34 | | Join wodz [0] (~wodz@chello087206240004.chello.pl) |
| 12:55:56 | | Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) |
| 12:57:50 | ucchan | oh, come back jdGordon. |
| 12:57:59 | JdGordon | hi |
| 12:59:11 | JdGordon | AlexP: ping? |
| 12:59:16 | JdGordon | pixelma: ping |
| 13:00 |
| 13:01:15 | ucchan | As for embeded aa, Is the big size memory stored in the file buffer, and is it safe ? (buffering.c's source is difficult little..) |
| 13:02:28 | JdGordon | ucchan: I'm probably not the best person to talk to, I just found it odd that you were relying on the codec buffer. I would think that it should act like regular AA which is just copied onto the buffer if there is enough room |
| 13:02:30 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 13:02:40 | JdGordon | talking to Unhelpful would probably be best |
| 13:03:10 | | Quit Rob2223 (Quit: Rob2223) |
| 13:03:20 | | Join Rob2222 [0] (~Miranda@p4FDC9227.dip.t-dialin.net) |
| 13:07:06 | funman | bertrik: about battery life, i find it strange that the clipv1/fuzev1/e200v2 do not have the same power usage |
| 13:07:29 | funman | this is also true between different clips |
| 13:07:45 | bertrik | is there really a big difference? |
| 13:07:47 | funman | perhaps we forgot to initialize some register and it is left in an undetermined, device-specific stage |
| 13:07:59 | funman | my clip doesn't go past 8 hours |
| 13:08:51 | funman | i was thinking of ascodec registers, did we check if we explicitely write to each of them ? |
| 13:09:05 | bertrik | weird, maybe sandisk changed components |
| 13:09:05 | ucchan | jdGordon: understand |
| 13:09:34 | funman | bertrik: you think there should be a sane reset value ? |
| 13:09:49 | bertrik | also I think we're not completely sure about the clips' battery capacity anyway, I tried to extrapolate it from other batteries based on the type number |
| 13:10:43 | bertrik | funman, I think we haven't checked yet if we write them all |
| 13:10:56 | funman | ah you think there would be different capacities to explain the difference between 2 clips? |
| 13:11:28 | bertrik | funman, yes that would be a possibiltiy (just a guess for now) |
| 13:13:41 | | Join mikroflops_ [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) |
| 13:17:35 | | Quit mikroflops (Ping timeout: 240 seconds) |
| 13:18:00 | | Quit esperegu (Ping timeout: 240 seconds) |
| 13:20:35 | | Join esperegu [0] (~quassel@145.116.15.244) |
| 13:23:29 | wodz | funman: You made some comment to my ML post about performance problems with MPIO. Could You be more specific about idea with second timer? |
| 13:24:06 | funman | if the kernel tick is not fast enough you could experience general slowness |
| 13:25:08 | funman | perhaps an easy measurement would be to modify the HZ variable and see how speed scale (measure with test_codec) |
| 13:25:18 | funman | the HZ constant* |
| 13:25:32 | | Quit esperegu (Ping timeout: 246 seconds) |
| 13:25:47 | wodz | sorry I don't understand |
| 13:26:17 | funman | the CPU is interrupted HZ (= 100) times per second |
| 13:26:35 | funman | until the tick has been executed, nothing else is executed |
| 13:26:56 | wodz | yes |
| 13:26:58 | funman | if the tick is executing for 0.01 second, then 100 times 0.01 = 1 second, so not other code can run |
| 13:27:09 | funman | hopefully the tick is executing for much less than 0.01 second |
| 13:27:39 | funman | but if it is 0.005 second, then the speed of other code will feel very slow, just like if the CPU was twice as slow |
| 13:28:40 | funman | does it make sense? |
| 13:28:47 | wodz | in general yes |
| 13:29:15 | funman | try changing HZ in kernel.h to 50 for example |
| 13:29:43 | ucchan | I will quit soon. (dinner, etc). tommorow, I wil login. |
| 13:29:59 | funman | good bye ucchan |
| 13:30:03 | ucchan | Please write the question to me in the tracker. |
| 13:30:16 | | Quit ucchan (Quit: Leaving...) |
| 13:30:54 | funman | wodz: if you see noticeable speed change, next step is find the part which takes a lot of time in the kernel tick |
| 13:31:06 | wodz | yes now I get it |
| 13:33:08 | wodz | kugel: ping |
| 13:34:29 | kugel | wodz: pong |
| 13:35:27 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 13:35:58 | | Join esperegu [0] (~quassel@145.116.15.244) |
| 13:36:16 | wodz | kugel: I experince errors from ALSA when running sim |
| 13:38:23 | | Quit funman (Quit: brb, travelling at ++c m.s^-2) |
| 13:40:12 | mt | wodz, kugel : I receive these errors in the sim : |
| 13:40:14 | mt | ALSA lib conf.c:2742:(snd_config_hooks) id of field i is not and integer |
| 13:40:15 | mt | ALSA lib conf.c:3079:(snd_config_update_r) hooks failed, removing configuration |
| 13:40:27 | wodz | me too |
| 13:40:41 | kugel | since when? |
| 13:40:50 | kugel | I have no idea what these errors mean |
| 13:42:22 | mt | I'll try to narrow it down to a particular commit (but will be slow because I'm on a VM currently) |
| 13:43:09 | wodz | mt: we can split bisection to find out |
| 13:43:51 | kugel | teamwork! :) |
| 13:46:54 | topik | too bad i just missed funman. for the logs sir, please look at http://forums.rockbox.org/index.php?topic=14064.msg166565#msg166565 |
| 13:46:55 | mt | wodz: Great, thanks. I'll look how slow/fast it goes first though and tell you .. |
| 13:47:27 | | Part mianos |
| 13:47:33 | | Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) |
| 13:47:37 | *** | Saving seen data "./dancer.seen" |
| 13:49:23 | mt | wodz: Forgot that I only have svn on my VM :( .. I'll try svn-bisect |
| 13:58:39 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 14:00 |
| 14:03:37 | kugel | linuxstb: ping |
| 14:10:21 | pixelma | JdGordon: yes? |
| 14:10:34 | JdGordon | do you remember issues with the fm skin patch? |
| 14:12:30 | JdGordon | I'm resyncing with the intention of commiting soon |
| 14:12:51 | pixelma | not since you fixed the issue with unknown presets but I haven't played around with it since. And well the difference to the current radio screen, especially the peakmeters/prerecording time on hwcodec |
| 14:14:11 | JdGordon | well, I dont have a hwcodec+ radio target, so unless someone steps up.... |
| 14:15:04 | pixelma | the "peakmeter on its own line" thing is there in the WPS too |
| 14:15:38 | mt | wodz : I guess we should start bisect from r25700 |
| 14:16:30 | wodz | mt: ok I can look at this after dinner :-) |
| 14:16:51 | JdGordon | what is it supposed to look like? |
| 14:17:11 | mt | wodz: ok. I'll bisect a little now. :) |
| 14:18:28 | pixelma | I can do the rest but the ability to put the peakmeter inside conditionals is something that would need to be coded. JdGordon: on hwcodec the fm screen shows a peakmeter which is replaced by the prerecording time (actually counting up) if you have that set |
| 14:19:16 | JdGordon | ok, well work around the fact that pm cant be in a conditional for the time being and make the screen fit |
| 14:26:38 | | Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) |
| 14:26:44 | | Join pamaury_ [0] (~c2c7a50a@rockbox/developer/pamaury) |
| 14:27:08 | Blue_Dude | Updated the bug report at FS #11255: wav file resume crashes the player. |
| 14:27:33 | pixelma | I find the info important though... hopefully there is another place to put it |
| 14:29:25 | pixelma | Blue_Dude: metadata inpure wav files? |
| 14:29:41 | | Quit pamaury (Ping timeout: 252 seconds) |
| 14:30:01 | Blue_Dude | The wav file is old. It certainly didn't crash the player before. |
| 14:30:02 | pixelma | I also had one and it crashed the player but I know metadata is not standard in PCM wave |
| 14:30:29 | Blue_Dude | Seems to me that codecs ought to tolerate metadata, not crash. |
| 14:30:34 | n1s | wodz: was the clock set up taken from the OF? |
| 14:31:10 | pixelma | I agree a crash is not nice, the least it should do is reject the file |
| 14:31:48 | pixelma | if it's unable to play it for whatever reason |
| 14:32:09 | pixelma | Blue_Dude: thanks for the hotkey menu cleanup by the way :) |
| 14:32:32 | Blue_Dude | You're welcome. |
| 14:33:40 | * | JdGordon thinks the peak meter handling is braindead compared to the newer stuff :p |
| 14:34:39 | | Join arbingordon [0] (~w@unaffiliated/arbingordon) |
| 14:38:58 | Blue_Dude | Yeah, I created a version of the wav with the same audio content but no metadata and it doesn't crash. Something happened in the last week or so to not tolerate metadata. |
| 14:40:10 | JdGordon | haha sweet! peakmeter working in conditionals was simple |
| 14:40:53 | JdGordon | needs some proper testing though... any takers? |
| 14:41:31 | pixelma | Blue_Dude: the one that crashed for me was ages ago but I guess since metadata in wave is not standard that there can be differences depending on how it was tagged exactly |
| 14:41:58 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 14:42:08 | pixelma | JdGordon: I would but my laptop is currently busy with music encoding |
| 14:42:19 | JdGordon | can i give you a build then? |
| 14:42:21 | Blue_Dude | I didn't even know it had metadata in it. |
| 14:42:53 | Blue_Dude | I'm doing a binary compare of the two files to find out what's going on. |
| 14:42:57 | pixelma | JdGordon: yeah, I think a c200 build would be easiest (as that one is standard) |
| 14:43:34 | JdGordon | you dont need the whole zip if you are running pretty close to svn |
| 14:43:41 | JdGordon | so do i need to do the whole zip? |
| 14:44:32 | pixelma | you can do OndioFM too (would be nice if you could do a backlight build - set in the advanced build options) |
| 14:45:17 | pixelma | maybe the latter is more interesting and I shouldn't need the whole zip there, only the ajbrec.ajz |
| 14:45:52 | JdGordon | http://jdgordon.info/rockbox/rockbox-c200.zip |
| 14:46:25 | JdGordon | this is just peakmeters in conditionals, no fm skin patch |
| 14:46:52 | pixelma | understood, I will just set up a simple test.wps |
| 14:46:52 | n1s | Blue_Dude: uchida added some wav metadata parsing recently, could be the cause, the sim is usually easier to debug for this type of bugs |
| 14:47:31 | | Quit Schmogel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 14:47:48 | Blue_Dude | n1s: understood. First I need to find out what's different between the two files, then maybe I can find out what the parser is choking on. |
| 14:48:08 | | Quit Buschel (Ping timeout: 248 seconds) |
| 14:48:28 | pixelma | maybe bisecting for the commit that breaks it could also help |
| 14:48:47 | JdGordon | http://jdgordon.info/rockbox/ajbrec.ajz < ondiofm+backlihgt |
| 14:49:23 | Blue_Dude | Hm. Two bytes difference... Weird. |
| 14:49:52 | Blue_Dude | I mean, that's really weird. |
| 14:50:30 | kugel | Blue_Dude: how's your mixer patch going? |
| 14:50:34 | Blue_Dude | Off to the hex editor I go. |
| 14:50:37 | pixelma | JdGordon: downloaded |
| 14:50:54 | n1s | id guess r25898 or r25911 |
| 14:50:56 | Blue_Dude | kugel: Delayed by wav bugs and hotkey patches. :) |
| 14:51:08 | Blue_Dude | Other than that, not bad. |
| 14:53:06 | pixelma | JdGordon: I'm just reminded as I see it again that the statusbar in the early USB screen vanished in recent builds |
| 14:53:25 | JdGordon | put it on FS |
| 14:56:26 | Blue_Dude | JdGordon: is the "old" statusbar supposed to appear for splash screens? I got that in the WPS screen before I took out the hotkey splash. |
| 14:57:16 | JdGordon | oh hmm... yeah it could now if your wps disables the theme |
| 14:57:42 | Blue_Dude | I've been using cabbie, which does disable the status bar. |
| 14:57:57 | JdGordon | no, ignore that |
| 14:58:00 | pixelma | it shouldn't |
| 14:58:32 | JdGordon | Blue_Dude: where do you see this splash? |
| 14:58:32 | Blue_Dude | The splash is gone so I can't reproduce, but pixelma's comment reminded me of it. |
| 14:58:52 | JdGordon | if it was shown by the menu then it would show it |
| 14:58:58 | Blue_Dude | I got it when the "Hotkey Not Set" splash came up. |
| 14:59:10 | Blue_Dude | In the WPS. |
| 14:59:22 | JdGordon | which was called after the wps reenables the theme, so yeah expetced |
| 14:59:34 | JdGordon | simple-ish to fix but if its not an issue anymore |
| 14:59:35 | JdGordon | ... |
| 14:59:37 | Blue_Dude | OK, just seemed odd. |
| 15:00 |
| 15:00:01 | Blue_Dude | I'm not sure there are any other splashes in the WPS. |
| 15:00:54 | pixelma | JdGordon: pm in the conditional seems to work on both - the c200 and the Ondio - tested with a simple test.wps that just shows pm on hold and nothing when unlocked |
| 15:01:13 | JdGordon | thats how i tested on sim also.. ok good |
| 15:02:01 | CIA-5 | New commit by jdgordon (r25913): slightly rework peakmeter handling to make it cleaner and be able to be used in conditionals |
| 15:02:03 | pixelma | one thing to look out for might be scrolling lines elsewhere |
| 15:02:40 | | Quit MethoS- (Remote host closed the connection) |
| 15:03:55 | wodz | nls: clock setup You mean setup of timer to perform system tick? |
| 15:04:58 | JdGordon | pixelma: do you tihnk you can do the hardcoded fms in the next few days now that is fixed? |
| 15:05:29 | pixelma | I think so, when an updated patch is available |
| 15:07:10 | JdGordon | the one i uploaded 20min ago works |
| 15:07:20 | pixelma | scrolling lines alongside such a conditional peakmeter work by the way. I just remembered there were some problems before with %pm in conditional viewports for a while before which is why I tested |
| 15:07:44 | pixelma | ok, will have a look |
| 15:07:54 | JdGordon | do you remember the FS# for that bug? |
| 15:08:04 | JdGordon | I remember it haunting me and not being able to figure it out |
| 15:08:11 | Blue_Dude | OK, here's what I have on the wav file. The one that behaves only contains audio chunks. The one that doesn't contains a metadata chunk at the end. Other than the metadata chunk they are identical, except for two bytes in the header. Those two bytes are the low end bytes of a four byte integer describing the total chunk size of the wav file. My guess is that for some reason, the parser... |
| 15:08:13 | Blue_Dude | ...is not ignoring the metadata but somehow trying to read it as an audio subchunk. |
| 15:09:01 | pixelma | JdGordon: the peakmeter in conditional viewports is fixed but I don't remember the FS# for it |
| 15:09:12 | JdGordon | it was fixed? ok cool |
| 15:09:13 | Blue_Dude | IOW, the parser assumes that if a subchunk exists in the total count, it must be audio. |
| 15:09:18 | loveless | are any arm-elf toolchain wizards awake, yet? |
| 15:10:27 | pixelma | JdGordon: need to test again but I saw it in one of my WPSs and think it was fixed. I can easily test though |
| 15:11:11 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 15:12:04 | loveless | need some help with bootloader.bin on -mcpu=arm1176jz-s. seems to produce broken boot/installer images |
| 15:14:49 | pixelma | JdGordon: the WPS that was affected seems to work fine now (r25710 on my M5... so slightly old but I don't think it's broken again) |
| 15:14:52 | Blue_Dude | Anyway, the bug report is updated again, and I have to go to work. Again. Later! |
| 15:14:57 | | Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) |
| 15:14:58 | pixelma | though you never know |
| 15:18:14 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 15:19:12 | | Join Llorean1 [0] (~DarkkOne@adsl-99-158-45-131.dsl.hstntx.sbcglobal.net) |
| 15:19:59 | | Quit M3DLG (Quit: RAGE QUIT) |
| 15:21:48 | | Quit ncfi1013 (Quit: Leaving) |
| 15:22:47 | | Quit antil33t (Read error: Connection reset by peer) |
| 15:22:53 | | Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) |
| 15:23:11 | | Quit Llorean (Ping timeout: 240 seconds) |
| 15:28:22 | loveless | okay, rechecked with same code, same setup and the only difference being -ma |
| 15:28:22 | loveless | ls |
| 15:28:30 | loveless | whoops |
| 15:29:22 | | Quit komputes_ubuntu (Quit: I haven't slept for ten days, because that would be too long.) |
| 15:29:39 | | Join komputes_ubuntu [0] (~komputes@ubuntu/member/komputes) |
| 15:29:51 | loveless | ... with the only difference being -mcpu=arm7tdmi vs. -mcpu=arm1176jz-s |
| 15:30:16 | | Quit stoffel_ (Remote host closed the connection) |
| 15:30:58 | mt | wodz, kugel : bisect results in r25850 being the commit that caused the error in audio playback in the sim. |
| 15:34:19 | | Join M3DLG [0] (~M3DLG@bb-87-81-252-83.ukonline.co.uk) |
| 15:41:17 | | Quit kugel (Remote host closed the connection) |
| 15:42:00 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 15:43:29 | | Quit petur (Ping timeout: 268 seconds) |
| 15:45:54 | | Quit arbingordon (Quit: `) |
| 15:46:39 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 15:47:17 | mt | Anyone having audio working fine in the sim with current svn ? |
| 15:47:38 | *** | Saving seen data "./dancer.seen" |
| 15:47:52 | kugel | mt: can you play audio at all? |
| 15:49:45 | | Quit Jaykay (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) |
| 15:50:03 | mt | kugel : you mean outside the sim ? |
| 15:50:13 | kugel | no, in the sim |
| 15:50:22 | kugel | I have no problem playing audio |
| 15:50:50 | mt | Then it could be something in my drivers, I'll check |
| 15:50:53 | | Quit bluebrother (Disconnected by services) |
| 15:50:55 | | Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) |
| 15:52:44 | kugel | mt: I meant: does it refuse to play entirely or does the error appear after some minutes?? |
| 15:52:44 | mt | kugel: I can't play audio at all in the sim |
| 15:52:54 | mt | No entirely |
| 15:53:27 | mt | Example : Once you select a file for playback, it crashes |
| 15:53:49 | gevaerts | mt: various codecs? |
| 15:54:17 | kugel | hm, something is not alright here too. it skips sometimes |
| 15:54:34 | mt | gevaerts: No, I tried one file and plugin alarm clock |
| 15:55:34 | wodz | mt,kugel: my bisecting ends up at r25850 also |
| 15:57:02 | wodz | I didn't updated system for quite some time so this is not system side error |
| 16:00 |
| 16:05:00 | kugel | wodz, mt: try http://pastie.org/952449 please (make sure you re-create the Makefile) |
| 16:05:22 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 16:05:52 | kugel | it solves the skipping for me |
| 16:07:57 | * | wodz compiling |
| 16:09:03 | mt | I'm compiling now too, but will probably be slower than wodz |
| 16:09:42 | wodz | no it didn't help |
| 16:13:27 | mt | kugel: fails here too. |
| 16:14:16 | | Join arbingordon [0] (~w@unaffiliated/arbingordon) |
| 16:17:37 | CIA-5 | New commit by kugel (r25914): Remove -U_GNU_SOURCE again (was added in r25850). It turns out SDL doesn't work properly with it. The reason I added it for doesn't exist anymore (or, ... |
| 16:18:07 | kugel | mt: unfortunately, I don't have the slightest idea what could cause that |
| 16:18:19 | kugel | the commit didn't really make any code changes |
| 16:19:24 | mt | Maybe the problem is with my system then ... I'll see |
| 16:19:32 | AlexP | JdGordon: Yo |
| 16:20:23 | | Join Jaykay [0] (~chatzilla@p5DC57141.dip.t-dialin.net) |
| 16:24:51 | * | kugel googles the error and finds http://www.rockbox.org/wiki/UiSimulator#3_Run_UIsimulator |
| 16:27:28 | kugel | and also a mailing thread from 2006 where the same problem occurs |
| 16:28:55 | wodz | kugel: but befor r25850 I didn't get this errors and sim worked ok |
| 16:30:24 | | Join hellelujah [0] (~59a10eb2@giant.haxx.se) |
| 16:30:30 | JdGordon | AlexP: hey, been a while :) trying to get back into the fms patch and get it commited.. remember any issues? and which target were you testing on that needed a good buffer bump? |
| 16:31:08 | AlexP | I can't remember any specific ones - the H140 needed a large buffer bump (I think principally due to multifont) |
| 16:31:18 | AlexP | And yes, it has been a little while :) |
| 16:31:18 | | Quit hellelujah (Client Quit) |
| 16:35:19 | kugel | wodz: I believe you |
| 16:35:40 | JdGordon | with cabbie there its 17KB free so as long as the backdrop image is reused that should be plenty, for the time being anyway |
| 16:35:52 | kugel | the issue came up in past apparently, I wonder if it was fixed or just disappeared |
| 16:35:54 | JdGordon | we really need to come up with a more flexible buffer stratergy |
| 16:37:29 | | Join hellelujah [0] (~59a10eb2@gateway/web/freenode/x-krxkundxvdlwyxry) |
| 16:38:22 | hellelujah | Hi. Would iPod nano 4th gen ever be supported? |
| 16:38:39 | bluebroth3r | if someone does the work, then yes. |
| 16:38:41 | wodz | hellelujah: You are free to port :-) |
| 16:39:03 | hellelujah | If I could... |
| 16:39:10 | kugel | Bagder: can you remember how you resolved that issue? |
| 16:39:12 | hellelujah | Not enough skill. |
| 16:39:20 | hellelujah | Thanks. |
| 16:39:24 | kugel | Bagder: I'm refering to http://www.rockbox.org/mail/archive/rockbox-archive-2005-07/0212.shtml |
| 16:39:27 | | Part hellelujah |
| 16:40:56 | JdGordon | kugel: tried looking at the old x11 code in svn? |
| 16:41:26 | kugel | no |
| 16:46:54 | | Join Xerion [0] (~xerion@82-170-197-160.ip.telfort.nl) |
| 16:47:22 | JdGordon | not really expecting this to go anywhere, but how would people feel about chaning the skin language to use [] for paramterised tags? %V[a|b|c...|] ? and also getting rid of "extra stuff" on tags (i.e %Xda would change to %Xd[a]) |
| 16:47:42 | JdGordon | I think we could make the parser much simpler if we did that, and it should make it more readbale |
| 16:48:56 | kugel | JdGordon: I had that idea before, and I'm all for it |
| 16:48:58 | JdGordon | those changes could be done in a script for all existing themes |
| 16:49:21 | kugel | I think I even posted it here ;) |
| 16:50:26 | bluebroth3r | JdGordon: without knowing any details it sounds good :) |
| 16:51:06 | JdGordon | who is doing the theme editor gsoc? |
| 16:52:31 | | Quit n1s (Read error: Connection timed out) |
| 16:53:48 | bluebroth3r | JdGordon: bieber is the student, I'm mentoring. |
| 16:54:51 | bluebroth3r | IIRC he was already asked about such a change and considered it a pretty easy change for the editor |
| 17:00 |
| 17:01:56 | | Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) |
| 17:05:43 | pixelma | JdGordon: I'd like the too and if it makes the parser simpler then the better |
| 17:06:05 | wodz | may I ask to look at FS #11254? |
| 17:06:15 | JdGordon | the ; tag could cause problems |
| 17:06:34 | JdGordon | I wonder if there is any way we could get away from the line based system we have now? |
| 17:06:35 | pixelma | because of the %t? |
| 17:07:01 | JdGordon | no, because it is not really a tag |
| 17:07:21 | JdGordon | %t would become %t[number] |
| 17:07:33 | JdGordon | i.e tags with any args would HAVE to have the []'s |
| 17:11:39 | | Quit esperegu (Ping timeout: 246 seconds) |
| 17:12:21 | | Join esperegu [0] (~quassel@145.116.15.244) |
| 17:15:28 | | Quit TheSeven (Ping timeout: 246 seconds) |
| 17:15:34 | | Quit komputes_ubuntu (Ping timeout: 240 seconds) |
| 17:17:34 | kugel | JdGordon: I would prefer () though |
| 17:17:41 | | Quit antil33t (Read error: Connection reset by peer) |
| 17:17:48 | | Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) |
| 17:17:51 | JdGordon | either work for me |
| 17:17:58 | | Quit esperegu (Read error: Connection reset by peer) |
| 17:18:45 | | Join esperegu [0] (~quassel@145.116.15.244) |
| 17:20:22 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 17:20:49 | kugel | mt, wodz: sound is also fine on my laptop |
| 17:21:54 | | Join wincent [0] (~wincent@g227130094.adsl.alicedsl.de) |
| 17:22:03 | | Quit wincent (Changing host) |
| 17:22:03 | | Join wincent [0] (~wincent@rockbox/developer/wincent) |
| 17:23:57 | bluebroth3r | how about using {}? ;-) |
| 17:25:01 | wodz | kugel: I glanced at r25850 patch and I don't see any reason why it changes anything but apparently it does |
| 17:27:33 | kugel | mt: you say you compile under a vm? |
| 17:27:46 | kugel | VBox? which distro? |
| 17:27:49 | pixelma | bluebroth3r: wouldn't be that bad as I use () and [] sometimes just like that in the WPS or tags, but don't do so with {} |
| 17:28:19 | pixelma | it also gives a tex touch ;) |
| 17:28:47 | | Quit evilnick (Ping timeout: 245 seconds) |
| 17:29:44 | * | kugel goes trying to repro it in a vm |
| 17:29:46 | | Quit kugel (Remote host closed the connection) |
| 17:30:23 | bluebroth3r | pixelma: I wasn't completely serious, I don't care much about it. However, having some opening-closing-braces sounds like a good idea to me. IMO a clash with literals shouldn't happen because a tag always starts with a % |
| 17:32:45 | * | gevaerts prefers <> |
| 17:32:57 | pixelma | thought so, but for reading the .wps file {} would look a bit more like "code" to *me* |
| 17:33:09 | | Join robin0800 [0] (~quassel@149.254.180.235) |
| 17:33:10 | pixelma | gevaerts: clashes a bit with conditionals |
| 17:33:23 | gevaerts | pixelma: then conditionals should be changed! |
| 17:33:46 | pixelma | of course |
| 17:34:14 | | Join komputes_ubuntu [0] (~komputes@ubuntu/member/komputes) |
| 17:37:36 | mt | kugel: yeah virtualbox .. ubuntu but a quite old version .. (8.04 I think) |
| 17:38:26 | mt | yeah 8.04 |
| 17:39:36 | wodz | mt: that's curiose I use (x)ubuntu 8.04 also |
| 17:39:45 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 17:40:09 | mt | wodz: I wanted to ask you about your distro but I totally disregarded that |
| 17:41:01 | wodz | tomorrow I can check on some debian and newer ubuntu |
| 17:41:31 | mt | kugel: I think it's leaning more & more towards being a system error rather than being a rockbox bug. |
| 17:42:04 | wodz | mt: not quite - sim used to work and at r25850 stopped |
| 17:44:47 | mt | wodz: While searching for the errors, there was some link about a bug with alsa in 9.10 (didn't open it so not quite sure of the content) .. but anyway I just think that the possibility is higher now that it's something with our systems, imho. |
| 17:46:10 | wodz | mt: It *may be* combination patch & system but we should be sure about that and moreover this shouldn't happen :-) |
| 17:46:51 | CIA-5 | New commit by alle (r25915): Manual: Bookmarking update (FS #11227 by Magnus Holmgren) |
| 17:47:16 | wodz | and I use this system daily with a few SDL apps and I don't have any problems |
| 17:47:40 | *** | Saving seen data "./dancer.seen" |
| 17:51:41 | | Join wincent_balin [0] (~wincent@g227130094.adsl.alicedsl.de) |
| 17:51:44 | | Quit wincent (Ping timeout: 268 seconds) |
| 17:52:22 | | Quit wincent_balin (Changing host) |
| 17:52:22 | | Join wincent_balin [0] (~wincent@rockbox/developer/wincent) |
| 17:54:17 | | Quit wincent_balin (Client Quit) |
| 17:54:47 | | Join wincent_balin [0] (~wincent@g227130094.adsl.alicedsl.de) |
| 17:54:50 | | Quit robin0800 (Remote host closed the connection) |
| 17:55:47 | | Quit wincent_balin (Client Quit) |
| 17:56:16 | mt | wodz: what I meant was that the patch _might_ have exposed a bug in the system, because quickly skimming through it, I can't really find a change that has a direct relation with that error. |
| 17:56:51 | | Join wincent [0] (~wincent@g227130094.adsl.alicedsl.de) |
| 17:57:11 | | Quit wincent (Changing host) |
| 17:57:11 | | Join wincent [0] (~wincent@rockbox/developer/wincent) |
| 17:58:52 | | Join ansuz [0] (~ansuz@c-98-219-218-216.hsd1.pa.comcast.net) |
| 18:00 |
| 18:00:25 | CIA-5 | New commit by alle (r25916): Use typographic quotation marks |
| 18:08:10 | | Join Schmogel [0] (~Miranda@p3EE22857.dip0.t-ipconnect.de) |
| 18:09:32 | kugel | mt: "success" I get the error in a vm |
| 18:09:46 | mt | Same distro ? |
| 18:10:00 | kugel | no, debian as of sept 2009 or so |
| 18:10:17 | | Join Buschel [0] (~ab@p54A3C547.dip.t-dialin.net) |
| 18:10:45 | kugel | I'll try if updating helps. but I need to backup the old image so that I don't lose my repro system |
| 18:10:47 | | Join flatrose [0] (~flatrose@ppp91-77-234-156.pppoe.mtu-net.ru) |
| 18:19:07 | | Join domonoky1 [0] (~Domonoky@g229247058.adsl.alicedsl.de) |
| 18:19:54 | | Quit domonoky (Ping timeout: 246 seconds) |
| 18:24:42 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 18:31:41 | | Join CaptainKewl [0] (~jason@207-237-106-60.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 18:48:38 | | Quit komputes_ubuntu (Ping timeout: 248 seconds) |
| 18:50:38 | | Join komputes_ubuntu [0] (~komputes@ubuntu/member/komputes) |
| 18:52:31 | flatrose | Is there a way to overclock iPod 5.5G's processor to 100mHz(+) using rockbox? I know it will drin more power but the heat would keep my HDD spinning at -30 next winter. |
| 18:53:44 | kugel | flatrose: yes, ask Buschel for details |
| 18:54:45 | | Quit wincent (Ping timeout: 240 seconds) |
| 18:55:12 | | Join wincent [0] (~wincent@f055124017.adsl.alicedsl.de) |
| 18:55:27 | soap | flatrose, infact, search flyspray for all patches by Buschel and you'll quickly find it. |
| 18:55:46 | soap | though many iPods appear unstable above rated speed. |
| 18:59:08 | bieber | I was away when the tag syntax topic came up a little while ago, but I'd like to chime in and say that it would make things really immensely simpler to parse, and I'm all for it |
| 19:00 |
| 19:00:17 | | Quit komputes_ubuntu (Ping timeout: 264 seconds) |
| 19:01:22 | | Nick Llorean1 is now known as Llorean (~DarkkOne@adsl-99-158-45-131.dsl.hstntx.sbcglobal.net) |
| 19:01:26 | | Quit Llorean (Changing host) |
| 19:01:26 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
| 19:10:59 | | Quit esperegu (Ping timeout: 240 seconds) |
| 19:11:44 | | Join komputes_ubuntu [0] (~komputes@ubuntu/member/komputes) |
| 19:11:46 | | Join hpmaniac [0] (~4eac8a83@giant.haxx.se) |
| 19:11:48 | bieber | And as for ;'s, my suggestion would be to replace them with an actual tag that has multiple parts, like the conditionals, which should also be a lot easier to parse than what we have now |
| 19:12:28 | bieber | But I don't know how the theme engine handles parsing and rendering, so it may be easier for that the way it is now... |
| 19:12:30 | hpmaniac | hi there |
| 19:13:00 | | Nick kisak_ is now known as kisak (~kisak@c-98-235-209-218.hsd1.pa.comcast.net) |
| 19:13:20 | | Quit hpmaniac (Client Quit) |
| 19:13:59 | | Quit mt (Ping timeout: 240 seconds) |
| 19:18:12 | flatrose | thanks for the answers, guys! |
| 19:20:27 | | Join mt [0] (~mtee@rockbox/developer/mt) |
| 19:21:25 | pixelma | bieber: can you give more details about this suggestion? JdGordon recently suggested a %t5<1st part|2nd part|etc.> and I didn't like it at all. It's not easier to read and is less flexible than what we have now. With this every subline has the same timeout while you can have different timeouts now |
| 19:21:55 | pixelma | it's even harder to read when there are conditionals in each subline |
| 19:22:40 | bieber | Perhaps enclose each subline in its own tag that can optionally include its own time value, the way HTML has <ul>/<ol> and <li>? |
| 19:23:54 | Llorean | bieber: I think the current sublines can be pretty readable - you always know that after a semicolon you're on a new on. If you had multiple characters doesn't it just make each transition more cluttery? |
| 19:24:04 | Llorean | *new one |
| 19:24:12 | bieber | Probably |
| 19:24:19 | pixelma | I don't know. From a user's perspective ; with optional %t are quite readable |
| 19:24:27 | Llorean | An explicit tag would just mean that instead of semicolons, we have %nL or something |
| 19:24:58 | bieber | I'm really not sure what the best way to approach it is. Adding explicit delimiters for every line will make it less readable, but easier to parse |
| 19:25:24 | pixelma | with the exception that you need to write %; if you want to just display a ; in your WPS |
| 19:26:17 | bieber | Perhaps allowing newlines between lines would help readability? |
| 19:26:20 | Llorean | bieber: I think what would make many WPSes easier to parse for the reader is if they used the commented line break (assuming that still works) to put sublines on multiple lines. |
| 19:26:43 | Llorean | bieber: You used to be able to end a line with a # to "comment out" the newline, so that you could write more of it on a second line. |
| 19:26:52 | pixelma | bieber: you could already do that by "commenting out" the line-ending |
| 19:27:04 | bieber | Okay |
| 19:27:07 | pixelma | not used much though |
| 19:27:34 | bieber | If you can use newlines, it shouldn't be bad to read/write |
| 19:28:48 | Llorean | I don't know if that feature's well documented / documented at all, though |
| 19:28:50 | bieber | Perhaps something like %Ms{ %Mi{line|optionaltime} %Mi{line|optionaltime}}, depending on the names/delimiters that get chosen for the tags |
| 19:29:35 | bieber | Llorean: The CustomWPS wiki entry I've been working off of does say that a comment includes its newline, but it doesn't point out that you can use that feature to break up tags into multiple lines. Perhaps I should add that to the page? |
| 19:29:36 | | Join esperegu [0] (~quassel@145.116.15.244) |
| 19:30:04 | | Join saratoga_ [0] (~463f90ed@gateway/web/freenode/x-lzxwguthctscjalg) |
| 19:30:43 | Llorean | bieber: What tag would you be breaking into multiple lines? |
| 19:30:55 | Llorean | Tags can never span sublines, so when you create a subline you're not breaking up a tag. |
| 19:31:42 | bieber | Well, if we enclosed the sublines in a container tag. Although in general, you _could_ split a tag's options across multiple lines with commented newlines, right? |
| 19:32:02 | pixelma | maybe the timeout tag can be the sign "start a new subline here"? Although that takes away the possibility to put the %t anywhere in the subline and you wouldn't be able to leave it out and let it use the default time (2s IIRC) |
| 19:32:25 | Buschel | flatrose: http://www.pastebin.org/213928 will set the clock to 100MHz max, 24MHz default, and will boost while GUI activity |
| 19:32:35 | Llorean | bieber: Why are you back at putting sublines in a container tag again? That seems like it would generate a lot of additional {} and clutter? |
| 19:33:21 | pixelma | it would be nice to put the %t inside conditionals again BTW which was possible before the tokenizer |
| 19:33:59 | bieber | Well, it would add two additional braces ;) It's just an option that would make parsing a little bit easier, whether to include it for readability is another issue |
| 19:34:01 | Llorean | pixelma: So depending on which condition was true, the line had variable possible display times? |
| 19:34:29 | | Quit esperegu (Ping timeout: 264 seconds) |
| 19:34:42 | pixelma | yes, you could even surpress it this way. If I recall there is still an example with %t0 somewhere in the Wiki |
| 19:36:19 | * | Llorean thinks that would be very nice to have back |
| 19:37:09 | saratoga_ | anyone want to look at the license in FS #11256 and guess if the lib is GPL safe or not? |
| 19:37:48 | saratoga_ | theres actually two nearly identical versions of the TTA decoder floating around, one LGPL, one that license, so i guess if not it could be fixed |
| 19:39:25 | | Join archivator [0] (~archivato@stu0279.keble.ox.ac.uk) |
| 19:40:05 | bieber | In any case, I'm going to build a generic tag-parsing function for libwps, so once it's decided whether to add delimiters, they'll be easy to implement |
| 19:40:21 | | Join Strife89 [0] (~Strife89@adsl-80-151-128.mcn.bellsouth.net) |
| 19:44:28 | | Join esperegu [0] (~quassel@145.116.15.244) |
| 19:45:10 | saratoga_ | skimming that license, the only real restriction added is that you have to maintain the copyright notice, and that you cannot use the authors name without his permission, which appears to be GPL ok since the GPL allows a copyright notice and doesn't grant you the right to the author's name |
| 19:45:16 | saratoga_ | but i have no real idea |
| 19:45:17 | | Join lpereira [0] (~lucien@112.46.70-86.rev.gaoland.net) |
| 19:45:31 | stripwax | Buschel - is that the same as, or different from, the fs# patch? |
| 19:45:33 | saratoga_ | why couldn't uchida just use the explicitly gpl source download :( |
| 19:46:07 | kugel | bieber: did you decide whether to reuse the existing code or not already? |
| 19:47:00 | | Quit archivator (Ping timeout: 246 seconds) |
| 19:47:28 | kugel | saratoga: that's bsd afaict, should be gpl safe |
| 19:47:30 | Llorean | saratoga_: If you have to maintain the copyright notice, but you can't use the author's name without permission, doesn't that restrict your ability to use the code (since that includes the copyright notice and thus the name?) |
| 19:47:43 | *** | Saving seen data "./dancer.seen" |
| 19:49:08 | saratoga_ | "Neither the name of the True Audio Software nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission." |
| 19:49:40 | saratoga_ | kugel is right that is the BSD license |
| 19:49:48 | | Quit esperegu (Ping timeout: 246 seconds) |
| 19:50:11 | saratoga_ | or rather "BSD-new" |
| 19:50:16 | saratoga_ | according to wikipedia |
| 19:50:48 | kugel | it's possible though that the last clause bites with gpl |
| 19:51:53 | saratoga_ | the last clause is strange since trademarks are implicitly reserved anyway, though maybe theres some country out there where they needed this |
| 19:52:18 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 19:52:46 | saratoga_ | FSF says its GPL friendly, so good enough for me |
| 19:54:20 | | Join esperegu [0] (~quassel@145.116.15.244) |
| 19:54:48 | | Quit TheSeven (Ping timeout: 265 seconds) |
| 19:59:22 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 20:00 |
| 20:02:24 | | Quit loveless (Quit: loveless) |
| 20:06:04 | | Quit petur (Quit: *plop*) |
| 20:06:52 | | Join archivator [0] (~archivato@stu0279.keble.ox.ac.uk) |
| 20:08:26 | | Join kyraxyg [0] (~4eb5065e@giant.haxx.se) |
| 20:11:40 | Bagder | kugel: iirc, that x11 asound experiments of mine never got anywhere, we dropped it and later proceeded with the SDL way |
| 20:20:26 | | Join kugel_ [0] (~kugel@e178062057.adsl.alicedsl.de) |
| 20:20:26 | | Quit kugel_ (Client Quit) |
| 20:22:19 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 20:26:58 | | Quit esperegu (Ping timeout: 240 seconds) |
| 20:33:33 | CIA-5 | New commit by alle (r25917): Use typographic quotation marks −− correct more places |
| 20:33:42 | | Join esperegu [0] (~quassel@145.116.15.244) |
| 20:39:45 | | Quit saratoga_ (Quit: Page closed) |
| 20:40:17 | | Join CGL [0] (~CGL@190.79.143.119) |
| 20:40:58 | | Quit mt (Ping timeout: 240 seconds) |
| 20:44:01 | Buschel | stripwax: no. the patch I've just pastebin'ed is a 100MHz-version of the FS-version. not all iPods run stable >=100MHz. |
| 20:48:55 | | Quit MethoS- (Remote host closed the connection) |
| 20:48:59 | | Quit komputes_ubuntu (Ping timeout: 246 seconds) |
| 20:51:45 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 20:53:27 | | Join mt [0] (~mtee@rockbox/developer/mt) |
| 21:00 |
| 21:01:50 | | Join TechnoKat [0] (~TechnoCat@c-98-223-163-190.hsd1.in.comcast.net) |
| 21:03:33 | stripwax | Buschel : gotcha |
| 21:05:20 | | Quit kyraxyg (Quit: CGI:IRC) |
| 21:06:29 | Buschel | anything speaking against submitting FS #11253 ? |
| 21:07:12 | wodz | it's ok for me |
| 21:08:19 | wodz | speaking of test_mem it would be nice to post results from different targets on wiki (like for test_disk, batery_bench, test_codec, test_fps...) |
| 21:08:21 | | Quit wincent (Ping timeout: 240 seconds) |
| 21:10:40 | n1s | we should add ams for coldfire as well, gcc pretty much never generates movem instructions except for stack stuff in pro and epilogs |
| 21:10:46 | n1s | s/ams/asm/ |
| 21:11:24 | amiconn | What for, specifically? |
| 21:12:08 | n1s | if we want to get closer to the bandwidth thoroughput of the ram |
| 21:12:33 | amiconn | wodz: Btw, did you see my optimisation for ata-as-coldfire.S? It could be ported to hd200 - I just didn't want to do that as I can't test it |
| 21:13:01 | amiconn | It doesn't noticeably improve speed - it saves a few instructions though |
| 21:13:15 | wodz | amiconn: yes I saw this |
| 21:13:17 | amiconn | n1s: Does the test use memcpy() / memmove() |
| 21:13:20 | amiconn | ? |
| 21:13:43 | n1s | amiconn: no, that is probably a better ide |
| 21:13:45 | n1s | a |
| 21:14:04 | amiconn | I didn't check - those functions are asm monsters on coldfire, utilizing movem in as many alignment cases as possible |
| 21:14:16 | * | amiconn wrote them |
| 21:14:38 | amiconn | They're in iram as well (it's not *that* important though) |
| 21:14:48 | Buschel | amiconn: the plugin test write and read seperately |
| 21:15:25 | kugel | Buschel: the patch looks good if you ask me |
| 21:15:40 | amiconn | Wouldn't it make more sense to bench the mem*() functions? |
| 21:15:57 | amiconn | Btw, that's what my old test_mem.rock did (which never made it to svn) |
| 21:15:58 | n1s | hmm, that read case looks like gcc could DSE all but one of the loads since they store into the same var in the loop... |
| 21:16:25 | * | amiconn just remembered what it did... |
| 21:16:57 | wodz | amiconn: could You please look at optimized writes in ata-as-hd200.S? I can't track down where is the problem with byte swaps. |
| 21:17:18 | amiconn | Is there still a problem? I thought it would be working now |
| 21:17:35 | wodz | amiconn: could I also ask You to run current test_mem on CF target? |
| 21:18:00 | wodz | amiconn: optimized writes makes test_disk fail |
| 21:18:25 | | Join ischeria1 [0] (~ischeriad@p5B0A1524.dip0.t-ipconnect.de) |
| 21:18:40 | wodz | but I finally squashed bug and greylib is working on HD200 :-) |
| 21:19:23 | ischeria1 | hello. are here any developers familiar with the iriver story (ebook reader)? |
| 21:19:37 | * | kugel has a suspicion re sim audio problem |
| 21:20:28 | amiconn | meh |
| 21:21:04 | amiconn | Whenever I'm looking at some arbitrary asm in rockbox, I find something that's not optimal :\ |
| 21:21:26 | amiconn | No matter whether it was originally written by me |
| 21:23:28 | CIA-5 | New commit by Buschel (r25918): Submit FS #11253. Rework of test_mem plugin to bench DRAM and IRAM. Also add ARM assembler and change the result format. |
| 21:24:30 | kugel | wodz, mt: try this one: http://pastie.org/952773 it works for me |
| 21:24:41 | * | Buschel waits for red to come... |
| 21:25:10 | stripwax | amiconn - any of mine? |
| 21:25:33 | amiconn | No idea. This time it's coldfire strlen - that's written by n1s |
| 21:26:44 | n1s | amiconn: i know about that, i actually have a half finished version somewhere that loads words at a time and use the magic test trick to check the whole word for nullbytes |
| 21:26:52 | amiconn | wodz: Btw, as I see you replaced jeq by beq in ata-as-mpio.S: There are two versions of beq, beq.s and beq.w |
| 21:27:09 | n1s | just haven't had time to finish and bench it |
| 21:27:17 | amiconn | The former is shorter (no extension word) than the latter, but it's limited in branch distance |
| 21:27:53 | AlexP | ischeria1: I doubt it - this is the first time anyone hs mentioned it |
| 21:28:18 | | Nick ischeria1 is now known as ischeriad (~ischeriad@p5B0A1524.dip0.t-ipconnect.de) |
| 21:28:23 | amiconn | If you write just beq, the assembler will always choose beq.w - that's what the jeq pseudo-instruction is for: it makes the assembler use the shortest possible version for the branch distance |
| 21:28:45 | n1s | well didn't have time before i left it on my desktop at home, but will try to finish it in a few days |
| 21:29:01 | amiconn | n1s: Reading a byte at a time might be elegant - but it's sloooooow when going through dram |
| 21:29:43 | n1s | well, i remember it benched faster than gcc's mess at least but yes, it's hardly optimal |
| 21:30:39 | ischeriad | AlexP: not long ago, iriver released the sources for the story firmware. I do not know if there are any independent developers yet and where to find them |
| 21:30:51 | n1s | as i said, i will try to finish my new version when u get home in a few days |
| 21:31:04 | n1s | s/ u/ i/ |
| 21:31:14 | AlexP | ischeriad: Not here at any rate :) I'd try to find owners sites or the like |
| 21:31:14 | | Quit bertrik (Quit: De groeten) |
| 21:33:58 | | Quit mt (Ping timeout: 240 seconds) |
| 21:34:16 | | Quit n1s (Quit: Lämnar) |
| 21:34:34 | ischeriad | AlexP: alright |
| 21:36:26 | | Join mt [0] (~mtee@rockbox/developer/mt) |
| 21:37:34 | wodz | kugel: I get corrupt patch at line 21 |
| 21:37:40 | | Quit GeekShadow (Quit: The cake is a lie !) |
| 21:38:40 | wodz | ok newline was missing |
| 21:41:18 | | Quit mt (Ping timeout: 240 seconds) |
| 21:42:11 | | Quit TechnoKat (Quit: Leaving) |
| 21:42:57 | wodz | kugel: this patch works for me |
| 21:43:11 | kugel | awesome |
| 21:45:56 | amiconn | wodz: Hmm, I can't spot an obvious problem in the hd200 ata write :\ |
| 21:46:17 | kugel | wodz: what system are you on, btw? |
| 21:46:29 | wodz | kugel: (x)ubuntu 8.04 |
| 21:46:37 | amiconn | However, you can optimize the swaps wherever only 16 bits are needed. No need to fiddle with the mask... fewer instructions |
| 21:46:53 | kugel | wodz: hm, mt too, maybe it's fixed in newer kernels |
| 21:47:12 | kugel | it seems to work for kernels newer than 2.6.30 |
| 21:47:18 | | Join mt [0] (~mtee@rockbox/developer/mt) |
| 21:47:41 | wodz | kugel: I can test this tomorrow on (x)ubuntu 9.04 and on some debian |
| 21:47:45 | mt | kugel: Worked for me ! |
| 21:47:47 | *** | Saving seen data "./dancer.seen" |
| 21:48:38 | wodz | amiconn: I am aware of this but as this function fail I tried to eliminate as much irregularities as possible to narrow down the problem |
| 21:48:46 | amiconn | yeah |
| 21:48:47 | mt | kugel: Are you going to commit it ? |
| 21:48:55 | | Join evilnick|ipad [0] (~evilnick@ool-457bccf5.dyn.optonline.net) |
| 21:48:58 | kugel | trying to, yes :) |
| 21:49:04 | mt | :) |
| 21:49:11 | kugel | this vm is a pain |
| 21:52:00 | amiconn | wodz: Hmm, asm optimised reading works? |
| 21:52:34 | wodz | amiconn: yes |
| 21:53:24 | amiconn | Now that is odd |
| 21:54:04 | amiconn | To me it looks like there is a problem in unaligned read. Need to check thoroughly... |
| 21:55:18 | wodz | amiconn: optimised read + general write pass test_disk test |
| 21:56:06 | | Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) |
| 21:58:22 | CIA-5 | New commit by Blue_Dude (r25919): Fix wav metadata bug, also fix typos and some const police |
| 21:58:43 | Blue_Dude | :) |
| 21:58:57 | | Join ender [0] (krneki@foo.eternallybored.org) |
| 22:00 |
| 22:00:18 | | Quit ender` (Ping timeout: 240 seconds) |
| 22:00:53 | | Quit kugel (Quit: exit(0);) |
| 22:02:53 | | Nick ender is now known as ender` (krneki@foo.eternallybored.org) |
| 22:03:48 | amiconn | wodz: Yet there *is* a problem in unaligned read if there is no single 16 bit word to be handled after the first byte |
| 22:04:09 | amiconn | It will write the first byte twice, omitting the actual second byte |
| 22:04:17 | amiconn | (write to memory of course) |
| 22:05:43 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 22:07:17 | CIA-5 | New commit by kugel (r25920): Undo a change of r25850 which broke SDL audio on some (older kernels?) systems. |
| 22:10:41 | kugel | so, hopefully all my latest bugs are squashed out now so I can move on with raaa :) |
| 22:14:42 | amiconn | wodz: What I mean is that %d2 is only pre-swapped when entering longword/line loops if there is an initial byte+word |
| 22:15:22 | gevaerts | kugel: you can always move on and fix bugs later when they're found :) |
| 22:15:38 | mt | kugel: Fixing that specific bug will let me go on with my project too. :) |
| 22:15:42 | amiconn | If there's just a byte and not a word, it's not pre-swapped, hence the first move.l to RAM will have the topmost byte wrong |
| 22:16:09 | * | amiconn wonders whether C writing makes up for that read bug so that test_disk works overall |
| 22:16:35 | | Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) |
| 22:17:13 | amiconn | wodz: Can you test with both C reading and writing? Also, can you compare md5sums of audio files calculated using the md5sum plugin with md5sums calculated on PC? |
| 22:17:31 | amiconn | Also, are there audible glitches when playing music? |
| 22:17:57 | amiconn | I doubt that though since buffering aligns these days |
| 22:18:10 | amiconn | Hmm, md5sum will probably do the same |
| 22:20:05 | | Quit FlynDice (Ping timeout: 264 seconds) |
| 22:20:21 | amiconn | A similar problem exists for the final word in the unaligned read: If there is one, the leftover byte from the last longword is wrong, since it is swapped twice |
| 22:23:44 | * | amiconn wonders why MPIO didn't use the (dead simple) hardware swap like iriver and cowon |
| 22:24:01 | kugel | gevaerts: I'll start the target tree work. The discussion on the ml wasn't quite a discussion but it confirmed my plams |
| 22:24:04 | kugel | plans* |
| 22:25:03 | gevaerts | kugel: yes, I think it's clear that people either agree or don't care much, which is good enough |
| 22:25:35 | | Quit flatrose (Ping timeout: 265 seconds) |
| 22:25:37 | kugel | alright, fine |
| 22:26:11 | amiconn | It's just that the ata data lines are connected the "wrong" way - that's why iriver & iaudio have their commands & status words defined different than the rest |
| 22:27:21 | gevaerts | kugel: to be honest, I prefer this to a long flamewar :) |
| 22:27:47 | kugel | me too :) |
| 22:32:50 | amiconn | Hmm. It's strange though. The C versions are looking 100% correct - so I don't understand why optimized reading on MPIO doesn't cause problems, but optimized writing does |
| 22:32:57 | amiconn | I'd expect the opposite |
| 22:33:01 | | Quit anewuser (Quit: for SELL 2 by the price of 1 now!) |
| 22:35:15 | | Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) |
| 22:35:27 | amiconn | AH wait - the writing *does* have problems - even more serious ones |
| 22:36:21 | amiconn | Combining the words before byte-swapping combines the wrong bytes - and that happens throughout in the unaligned case, not just at the beginning and end |
| 22:36:35 | amiconn | wodz ^^ |
| 22:37:58 | amiconn | eh, or not... |
| 22:38:06 | * | amiconn is confused |
| 22:39:22 | amiconn | The unaligned read bug does hold though |
| 22:39:42 | | Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) |
| 22:39:57 | domonoky1 | hi archivator, hows you project going ? :-) |
| 22:42:48 | | Quit Schmogel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 22:43:00 | | Nick domonoky1 is now known as domonoky (~Domonoky@g229247058.adsl.alicedsl.de) |
| 22:43:17 | | Quit domonoky (Changing host) |
| 22:43:17 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
| 22:43:23 | Blue_Dude | Can anyone think why mp3_play_data, mp3_play_pause, mp3_play_stop, and mp3_is_playing functions in the plugin API are disallowed for the simulator? |
| 22:43:26 | | Quit evilnick|ipad (Remote host closed the connection) |
| 22:44:03 | kugel | Blue_Dude: are they for hwcodec? |
| 22:44:32 | Blue_Dude | Strangely enough, no. They go to voice_thread. |
| 22:44:47 | Blue_Dude | But only for swcodec. |
| 22:46:25 | archivator | domonoky: well, I *almost* got it to compile for target but I've stopped working on that aspect for the time being (it's a bit beyond my area of expertise) and am doing fixed-point conversion, using the sim. It's going.. but rather slowly (it's a mess, to put it very, very mildly). |
| 22:46:50 | | Join FlynDice [0] (~FlynDice@74.10.105.233) |
| 22:47:03 | domonoky | archivator: would be good ot post patches about that, so others can see it too. |
| 22:47:08 | kugel | it's not expected to be easy :) |
| 22:47:27 | kugel | gevaerts: time for a first status report I'd say |
| 22:48:09 | * | domonoky also would like to remind all students here of the weekly status report in the mailing list... |
| 22:48:10 | archivator | domonoky: will do, soon. Want to have something more, though. |
| 22:48:40 | gevaerts | kugel: yes indeed :) |
| 22:49:50 | Blue_Dude | The hwcodec version is in mp3_playback.c. I don't see why the sim is specifically carved out. |
| 22:50:21 | domonoky | archivator: especially when you get stuck, post patches on the tracker, and ask for fresh looks at it here or in the mailinglist.. |
| 22:51:44 | archivator | domonoky: I'm not really "stuck", it's just hard to grasp all that's going on in flite. I've started drawing diagrams (!), even.. |
| 22:51:55 | Blue_Dude | I wanted to point plugins to mp3_play_data for sound effects. That's kinda hard to test if the sim doesn't compile them. |
| 22:53:10 | domonoky | archivator: if you have those diagrams, maybe it would be good to put it into the wiki with descriptions :-) |
| 22:53:59 | archivator | domonoky: huh, never though of making them public. Might do something proper, then. My handwriting is horrendous :) |
| 22:55:33 | | Quit freddy_ (Ping timeout: 265 seconds) |
| 22:57:06 | domonoky | you dont need to make them public, but if you need them to understand flite, maybe it would be helpfull for others too :-) |
| 22:58:05 | | Join krabador [0] (~ubuntu@host68-37-dynamic.31-79-r.retail.telecomitalia.it) |
| 22:58:38 | mt | Status updates now ? I thought we did those after the official start of the coding period |
| 22:59:09 | | Quit wodz (Quit: Leaving) |
| 22:59:11 | kugel | I don't see a reason to wait with them |
| 23:00 |
| 23:00:23 | mt | I wanted to send a mail before though .. but thought I should wait. Will probably send something in the next few days then. |
| 23:00:47 | gevaerts | mt: for students with an extended coding period (due to schedule conflicts), I think the extended period is what matters, not the official period |
| 23:03:33 | CIA-5 | New commit by Buschel (r25921): Add non-breaking spaces to mA, mAh, MB and GB. Add playertype for iPod Video when describing the different variants. |
| 23:03:55 | | Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) |
| 23:08:01 | | Join freddy_ [0] (~freddy@p3E9E004D.dip0.t-ipconnect.de) |
| 23:08:49 | | Quit esperegu (Remote host closed the connection) |
| 23:16:15 | | Quit Jaykay (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) |
| 23:18:26 | | Quit Buschel (Ping timeout: 246 seconds) |
| 23:18:40 | | Join hebz0rl [0] (~hebz0rl@dslb-088-065-053-186.pools.arcor-ip.net) |
| 23:23:30 | | Quit pamaury_ (Ping timeout: 252 seconds) |
| 23:23:59 | | Quit FlynDice (Remote host closed the connection) |
| 23:26:55 | mt | saratoga, linuxstb : The asf parser seems to be parsing wma pro files correctly now .. I'm thinking of committing that, with a wmapro.codec that would just not play for now. |
| 23:27:09 | | Quit Xerion (Quit: ) |
| 23:27:13 | saratoga | great |
| 23:27:48 | mt | not much changes at all really .. ASF is being nice till now. :) |
| 23:29:02 | | Quit archivator (Quit: Leaving) |
| 23:34:13 | | Quit petur (Quit: Zzzzz) |
| 23:40:08 | saratoga | Bagder: could you add this new test file: http://duke.edu/~mgg6/true_audio.tta |
| 23:41:30 | Bagder | saratoga: done! |
| 23:41:33 | saratoga | thanks |
| 23:42:10 | CIA-5 | New commit by mt (r25922): nomsg |
| 23:42:26 | mt | oops |
| 23:43:47 | mt | Should I revert that and recommit it with a proper message ? |
| 23:44:17 | | Quit lpereira (Quit: Leaving.) |
| 23:45:42 | | Quit domonoky (Read error: Connection reset by peer) |
| 23:47:51 | *** | Saving seen data "./dancer.seen" |
| 23:49:55 | gevaerts | mt: IIRC Bagder or Zagor can fix that |
| 23:50:14 | | Quit hebz0rl (Ping timeout: 246 seconds) |
| 23:50:42 | | Join hebz0rl [0] (~hebz0rl@dslb-088-065-053-186.pools.arcor-ip.net) |
| 23:50:45 | mt | gevaerts: Thanks .. I really hope so |
| 23:52:38 | CIA-5 | New commit by mt (r25923): Fix ffmpeg revision number in libwmapro/README.rockbox |
| 23:54:22 | saratoga | i guess I should make some WMA Pro test files too |
| 23:54:29 | mt | Bagder: Can I send you the correct commit message for r25922 so you could fix it ? |
| 23:55:02 | Llorean | jhMikeS: Does the auto-speed whatever that the GigabeatS does respect plugins that ask to be boosted? |
icon identifies that the person is a core developer (has commit access).