| 00:01:04 | bricks | hello, the 3.6 firmware for sansa clip v1 is giving me a 404 error. |
| 00:02:33 | bricks | Is there a mirror somewhere, or should I just go for the current build (I'm doing a new install)? |
| 00:04:40 | ender` | when 3.6 was released, clip wasn't considered stable yet, so the build doesn't actually exist - use the current build instead |
| 00:04:58 | bricks | cool, thanks |
| 00:07:16 | | Quit MagusG (Ping timeout: 265 seconds) |
| 00:07:33 | | Quit Staphylo (Quit: Bye les gens =)) |
| 00:11:19 | | Quit bricks (Quit: CGI:IRC 0.5.9 (2006/06/06)) |
| 00:13:14 | | Quit jgarvey (Quit: Leaving) |
| 00:14:18 | wodz | pixelma: (for logs) I uploaded new version of the patch to FS #11641. This time it should apply cleanly. |
| 00:19:10 | | Quit liar (Ping timeout: 240 seconds) |
| 00:20:37 | | Quit wodz (Quit: Leaving) |
| 00:23:05 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 00:29:45 | | Join drizztbsd_ [0] (~quassel@82.84.100.107) |
| 00:31:00 | | Join drizztbsd__ [0] (~quassel@dynamic-adsl-78-12-185-162.clienti.tiscali.it) |
| 00:33:01 | | Quit drizztbsd (Ping timeout: 272 seconds) |
| 00:34:55 | | Quit drizztbsd_ (Ping timeout: 272 seconds) |
| 00:35:17 | | Quit domonoky1 (Read error: Connection reset by peer) |
| 01:00 |
| 01:01:16 | | Quit ender` (Quit: printk("; corrupted filesystem mounted read/write - your computer will explode within 20 seconds ... but you wanted it so!\n"); -- /usr/src/linux/fs/hpfs/super.c) |
| 01:03:47 | | Join Strife89TX [0] (~cstrife89@adsl-80-164-93.mcn.bellsouth.net) |
| 01:05:15 | | Join Topy [0] (~Topy44@g228134251.adsl.alicedsl.de) |
| 01:05:24 | saratoga_ | we should release 3.7 so people stop asking about 3.6 on the clip! |
| 01:08:27 | | Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) |
| 01:08:31 | | Quit T44 (Ping timeout: 245 seconds) |
| 01:14:51 | | Quit kugel (Ping timeout: 240 seconds) |
| 01:21:41 | | Quit esperegu (Read error: Connection reset by peer) |
| 01:22:19 | | Join edboyer93 [0] (eboyer93@pool-71-185-65-59.phlapa.fios.verizon.net) |
| 01:31:58 | | Join freedrull [0] (~freedrull@freedrull.xen.prgmr.com) |
| 01:35:41 | | Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) |
| 01:40:09 | | Quit Nausicaa (Ping timeout: 272 seconds) |
| 01:47:55 | | Part freedrull |
| 01:49:22 | | Quit DerPapst (Quit: Leaving.) |
| 01:52:38 | *** | Saving seen data "./dancer.seen" |
| 02:00 |
| 02:04:35 | | Quit t0rc (Ping timeout: 276 seconds) |
| 02:06:09 | | Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) |
| 02:06:56 | | Join shai__ [0] (~Shai@l192-117-110-233.cable.actcom.net.il) |
| 02:09:27 | | Quit _s1gma (Quit: Leaving) |
| 02:09:52 | | Join JdGordon [0] (7bf38c1f@gateway/web/freenode/ip.123.243.140.31) |
| 02:10:33 | | Quit shai_ (Ping timeout: 272 seconds) |
| 02:16:22 | | Quit mt (Remote host closed the connection) |
| 02:20:38 | | Join ntryon [0] (~ntryon@42.interlockroc.net) |
| 02:21:13 | | Join ntryon_ [0] (~ntryon@42.interlockroc.net) |
| 02:25:35 | | Quit ntryon (Ping timeout: 265 seconds) |
| 02:27:18 | | Join Barahir [0] (~jonathan@frnk-590f7d14.pool.mediaWays.net) |
| 02:33:28 | | Join Tux2 [0] (~Tux2@174-29-227-211.hlrn.qwest.net) |
| 02:38:54 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
| 02:46:28 | JdGordon | from last nights buffering talk... I'm scared to think what would happen to the skin engine if it went to handle allocations instead of simple pointers |
| 02:47:24 | JdGordon | the whole thing is linked trees, pointers to alloced arrrays, pointers to structs.. if even the block could move around it would be a nightmare |
| 02:48:16 | JdGordon | but if the initial block could be compacted once we know how much has been used, and guarenteed to not be moved (without an exensive reload) then it might be ok |
| 02:48:31 | JdGordon | ^ saratoga_, Torne, Unhelpful |
| 02:49:26 | | Quit stripwax (Read error: Connection reset by peer) |
| 02:50:14 | | Quit simonrvn (Read error: Connection reset by peer) |
| 02:50:46 | Unhelpful | @Torne: yes, i realize that special cases could potentially be expensive, my expectation was that they would also be very rarely *used*. the idea is that this sort of thing only happens on things like skin change, maybe a user changes one of the resizeable buffers that we can currently only size on boot, etc. |
| 02:51:29 | Unhelpful | if there's a playback stall it won't surprise anybody much as it immediately follows a user interaction - the same thing already happens if you change to a theme w/ different AA size, and i have seen almost no complaint about it. |
| 02:59:06 | | Quit t0rc (Quit: Give someone code, help them with one project. Teach someone to code, help them rule the world.) |
| 02:59:19 | | Quit factor (Ping timeout: 272 seconds) |
| 03:00 |
| 03:00:24 | | Quit Ramsey[LC] (Remote host closed the connection) |
| 03:00:53 | | Join Ramsey[LC] [0] (~RamseyLC]@71.158.161.74) |
| 03:05:15 | | Join clone4crw [0] (~Calvin@97-86-227-168.dhcp.roch.mn.charter.com) |
| 03:06:01 | | Quit Judas_PhD (Quit: This is a quitting message) |
| 03:15:36 | | Quit Xerion (Read error: Connection reset by peer) |
| 03:32:25 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 03:32:29 | | Quit komputes (Remote host closed the connection) |
| 03:44:35 | | Join Nausicaa [0] (~Nausicaa@c-71-239-58-153.hsd1.il.comcast.net) |
| 03:50:05 | | Join Strife89 [0] (~Strife89@adsl-80-164-93.mcn.bellsouth.net) |
| 03:52:41 | *** | Saving seen data "./dancer.seen" |
| 03:56:58 | | Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) |
| 04:00 |
| 04:14:01 | | Quit engwan_ (Ping timeout: 276 seconds) |
| 04:14:59 | | Quit clone4crw (Quit: leaving) |
| 04:15:36 | | Join simonrvn [0] (simon@209.214-ppp.3menatwork.com) |
| 04:21:59 | | Quit amiconn (Disconnected by services) |
| 04:21:59 | | Quit pixelma (Disconnected by services) |
| 04:22:00 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 04:22:00 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 04:22:16 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 04:22:17 | | Quit Strife89 (Quit: Leaving) |
| 04:22:20 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 04:25:44 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 04:30:34 | | Join clone4crw [0] (~calvin@97-86-227-168.dhcp.roch.mn.charter.com) |
| 04:36:51 | | Join engwan_ [0] (~engwan@112.202.22.199) |
| 04:40:34 | | Quit Barahir (Read error: Operation timed out) |
| 04:45:01 | | Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 04:56:55 | | Quit engwan_ (Ping timeout: 255 seconds) |
| 04:57:34 | | Quit t0rc (Quit: Give someone code, help them with one project. Teach someone to code, help them rule the world.) |
| 04:59:08 | | Join Keripo [0] (~Keripo@dhcp0101.kin.resnet.group.upenn.edu) |
| 04:59:44 | | Part Keripo |
| 05:00 |
| 05:01:57 | | Join MagusG [0] (magusg@c-71-59-57-46.hsd1.ga.comcast.net) |
| 05:14:30 | | Quit MethoS- (Read error: Connection reset by peer) |
| 05:27:16 | | Join Barahir [0] (~jonathan@frnk-590ffacd.pool.mediaWays.net) |
| 05:30:43 | | Join froggyman [0] (~seth@unaffiliated/froggyman) |
| 05:32:05 | | Quit ntryon_ (Ping timeout: 265 seconds) |
| 05:33:52 | | Quit ps-auxw (Ping timeout: 245 seconds) |
| 05:41:03 | | Join factor [0] (~factor@74.196.132.161) |
| 05:45:32 | | Join ps-auxw [0] (~arneb@p4FF7EF43.dip.t-dialin.net) |
| 05:46:16 | | Quit edboyer93 () |
| 05:46:25 | | Quit clone4crw (Ping timeout: 255 seconds) |
| 05:52:44 | *** | Saving seen data "./dancer.seen" |
| 06:00 |
| 06:11:11 | | Quit Horscht (Quit: Verlassend) |
| 06:18:53 | | Quit bluebrother (Ping timeout: 265 seconds) |
| 06:20:13 | | Join bluebrother [0] (~dom@f053154024.adsl.alicedsl.de) |
| 06:20:13 | | Quit bluebrother (Changing host) |
| 06:20:13 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 06:44:11 | | Quit Tux2 (Quit: I can't stay forever... but I will be back!) |
| 06:53:06 | | Quit Nausicaa (Ping timeout: 252 seconds) |
| 07:00 |
| 07:02:03 | | Join powell14ski_ [0] (~powell14s@c-174-51-160-240.hsd1.co.comcast.net) |
| 07:05:51 | | Quit krazykit (Quit: awe yeeeeeee) |
| 07:12:21 | | Quit togetic (Ping timeout: 252 seconds) |
| 07:33:40 | | Join Staphylo [0] (~Bullet@AMontsouris-159-1-51-172.w92-128.abo.wanadoo.fr) |
| 07:39:51 | | Quit Judas_PhD (Quit: This is a quitting message) |
| 07:47:06 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 07:52:47 | *** | Saving seen data "./dancer.seen" |
| 08:00 |
| 08:01:21 | | Quit anewuser (Ping timeout: 272 seconds) |
| 08:10:19 | | Quit Staphylo (Quit: Bye les gens =)) |
| 08:45:43 | | Join einhirn [0] (~Miranda@wlanstaff083.rz.tu-clausthal.de) |
| 08:46:01 | | Quit einhirn (Client Quit) |
| 08:50:32 | | Join einhirn [0] (Miranda@wlanstaff083.rz.tu-clausthal.de) |
| 08:55:33 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:56:01 | | Join einhirn_ [0] (Miranda@wlanstaff083.rz.tu-clausthal.de) |
| 08:59:18 | | Join LinusN [0] (~linus@rockbox/developer/LinusN) |
| 08:59:22 | | Quit einhirn (Ping timeout: 240 seconds) |
| 09:00 |
| 09:01:16 | | Quit einhirn_ (Ping timeout: 240 seconds) |
| 09:03:31 | | Quit GodEater (Read error: Operation timed out) |
| 09:07:05 | | Join GodEater [0] (~bibble@rockbox/staff/GodEater) |
| 09:08:08 | | Join esperegu [0] (~quassel@145.116.15.244) |
| 09:11:42 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 09:11:42 | * | pixelma wonders about the number of reports (in the forum) of problems with installation, seemingly bootloader installation, on PP Ipods |
| 09:12:15 | pixelma | I believe there are 4 since yesterday |
| 09:18:09 | | Quit Judas_PhD (Quit: This is a quitting message) |
| 09:22:23 | | Join GibbaTheHutt [0] (~moo@78-105-152-175.zone3.bethere.co.uk) |
| 09:28:31 | | Join einhirn [0] (Miranda@vpn10.rz.tu-clausthal.de) |
| 09:28:31 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 09:28:31 | | Quit bertrik (Changing host) |
| 09:28:31 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 09:30:24 | | Quit einhirn (Read error: Connection reset by peer) |
| 09:30:34 | | Join swilde [0] (~wilde@aktaia.intevation.org) |
| 09:39:57 | | Quit JdGordon (Ping timeout: 252 seconds) |
| 09:43:12 | | Join wodz [0] (~wodz@chello087206240131.chello.pl) |
| 09:44:45 | wodz | pixelma: could you try FS #11641 on Your Ondio? It *should* apply cleanly |
| 09:46:35 | uberushaximus | So I mentioned this yesterday or the day before but I'm having a weird problem on the last few revisions with the clipv1 |
| 09:48:11 | | Join einhirn [0] (Miranda@vpn10.rz.tu-clausthal.de) |
| 09:49:06 | uberushaximus | on newer operating systems with identical hardware (think windows 7 or ubuntu don't work vista/xp do) I get "*PANIC* SD Xfer read err:0x8 Disk0" |
| 09:49:27 | | Quit einhirn (Client Quit) |
| 09:49:42 | | Join einhirn [0] (Miranda@vpn10.rz.tu-clausthal.de) |
| 09:50:01 | uberushaximus | and by "don't work" I mean "the error is reproducible" |
| 09:50:55 | uberushaximus | the build I installed ~2-3 days ago didn't have any problem |
| 09:52:48 | *** | Saving seen data "./dancer.seen" |
| 09:53:16 | wodz | try bisecting |
| 09:53:49 | wodz | 2-3 days means only a couple commits |
| 09:57:48 | | Join Rob2222 [0] (~Miranda@pD9FE2992.dip.t-dialin.net) |
| 09:59:27 | | Join utanapischti [0] (~username@p4FF2D005.dip.t-dialin.net) |
| 10:00 |
| 10:01:18 | | Quit Rob2223 (Ping timeout: 252 seconds) |
| 10:03:28 | | Quit sasquatch (Ping timeout: 245 seconds) |
| 10:05:02 | gevaerts | uberushaximus: that's *really* weird. That panic is in the SD code. That really shouldn't be influenced by the OS you use... |
| 10:06:49 | gevaerts | I also don't see anything in the svn log during the last two weeks that looks even vaguely related |
| 10:11:07 | | Quit antil33t (Read error: Connection reset by peer) |
| 10:11:16 | | Join antil33t [0] (~Mudkips@124-197-51-80.callplus.net.nz) |
| 10:15:28 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 10:19:11 | AlexP | wodz: Sorry, I was asleep last night - I can test tonight |
| 10:19:45 | wodz | ok, thx |
| 10:22:26 | | Quit Guest30770 (Quit: Leaving.) |
| 10:23:47 | | Join {phoenix} [0] (~dirk@p57AA4269.dip.t-dialin.net) |
| 10:24:36 | bug2000 | Silly question, why I don't wish to be trolled for asking, but as I've noticed, Rockbox has a 3 month release cycle. I'd like to know if there is anything extremily wrong or lots of belated bug fixes which delay the release or there is just no apperant reason or what so ever. |
| 10:26:37 | gevaerts | There's a combination of things going on I'd say |
| 10:27:00 | pixelma | in my experience the changes to the skin engine still aren't settled, e.g. you can experience screen cuorruption sometimes and in different ways on at least the targets with monochrome screens |
| 10:27:37 | gevaerts | (a) someone has to take the initiative to start the release process, and nobody has yet, and (b) several people (I'm one of them) feel that the recent skin changes aren't stable enough yet |
| 10:27:50 | gevaerts | Possibly (a) is caused by (b) |
| 10:28:29 | bug2000 | I see, well, I can't help with that, I only use one spesific skin on a spesific device. |
| 10:28:30 | | Quit Judas_PhD (Quit: This is a quitting message) |
| 10:37:23 | | Join DerPapst [0] (~Alexander@dslb-088-069-157-050.pools.arcor-ip.net) |
| 10:40:31 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 10:53:41 | bug2000 | http://download.rockbox.org/daily/fonts/rockbox-fonts.zip −− Seem to be 9/2009 is that right? |
| 10:54:01 | bug2000 | 23-Sep-2009 |
| 10:54:42 | gevaerts | sounds very possible |
| 10:55:05 | | Quit wodz (Quit: Leaving) |
| 10:55:28 | bug2000 | gevaerts: Except it seems the normal rockbox build got newer font files in it. |
| 10:58:40 | bug2000 | gevaerts: Also, according to rasher.dk, rockfont.bdf supports Hebrew, yet with either of the files [latest / fonts build] Hebrew isn't working correctly. |
| 10:59:10 | gevaerts | rasher's page is auto-generated as far as I know |
| 10:59:19 | * | gevaerts isn't a font specialist |
| 11:00 |
| 11:05:35 | Torne | Unhelpful: if the special cases are very rarely used that makes them even *more* expensive in terms of binsize, code complexity and space for potential bugs to hide :) |
| 11:06:25 | Unhelpful | Torne: i suppose. very cheap in terms of run time, and not hard to test as we already have lists of things we can't change without reboot right now. ;) |
| 11:08:11 | Torne | but we don't test stuff particularly methodically a lot of the time. :) |
| 11:08:44 | Torne | i am just, mostly, waving my paw a bit and assuming that a special purpose malloc can be made to work fine :) |
| 11:08:54 | Torne | i have the vaguest of vague ideas about what that would be |
| 11:08:58 | Torne | i may well be wrong :) |
| 11:09:25 | Unhelpful | could just say "we have a real malloc, only for MMU devices" ;P |
| 11:11:04 | Torne | there's not really a significnat benefit to the MMU here |
| 11:11:13 | Torne | unless you promote all allocations to multiples of 4kb |
| 11:11:15 | Torne | which would suck |
| 11:11:23 | Torne | and we'd need to start having actual pagetables :) |
| 11:12:18 | Unhelpful | Torne: wouldn't a benefit w/ an MMU be that we could compact and remap existing allocations, while still using the classic malloc pointer interface instead of some sort of handle-based thing? |
| 11:13:01 | Torne | but you can't. |
| 11:13:16 | Torne | you can sort of half do it in a very limited way for chunks of 4kb, at the cost of loads of overhead and extra memory used |
| 11:13:29 | Torne | virtual memory is not all that ;) |
| 11:14:03 | Unhelpful | heh |
| 11:15:03 | * | Torne thinks a useful thing to do, at this point, would be to throw some logf's in there so someone can look and see how many buffer_allocs there actually are and what sizes they are and why they exist |
| 11:15:55 | Torne | maybe later ;) |
| 11:16:37 | bug2000 | gevaerts: Where can I get the real latest 8-rockfont.fnt? |
| 11:16:56 | Unhelpful | Torne: useful things? is that how development works? |
| 11:17:35 | Torne | heh |
| 11:18:43 | Torne | occasionally :) |
| 11:20:05 | Unhelpful | it's more fun to debate how best to implement things i believe to be gross misfeatures :) |
| 11:21:35 | | Join Zagor [0] (~bjst@rockbox/developer/Zagor) |
| 11:32:31 | | Quit Strife89TX (Quit: Leaving) |
| 11:52:50 | *** | Saving seen data "./dancer.seen" |
| 11:53:23 | | Join einhirn_ [0] (Miranda@wlanstaff083.rz.tu-clausthal.de) |
| 11:56:48 | | Quit einhirn (Ping timeout: 240 seconds) |
| 12:00 |
| 12:05:43 | | Join Barahir_ [0] (~jonathan@frnk-590f4cfe.pool.mediaWays.net) |
| 12:07:42 | | Join wodz [0] (~5f303f8a@giant.haxx.se) |
| 12:08:48 | | Quit Barahir (Ping timeout: 240 seconds) |
| 12:09:03 | AlexP | gevaerts: Yes, I'm quite happy to do the release stuff, but have been waiting as I picked up that people weren't entirely happy with the state of some things |
| 12:10:57 | Torne | like what? |
| 12:11:06 | Torne | (not questioning you, just curious) |
| 12:11:23 | AlexP | mainly skin stuff |
| 12:11:45 | AlexP | I only mean unhappy as in some bugs need squashing :) |
| 12:11:57 | AlexP | But I may well have got the wrong end of the stick |
| 12:15:25 | gevaerts | Torne: until one or two weeks ago there were regular crash reports on the forums. Things have been improving since then, but there are still issues for some people |
| 12:16:14 | Torne | hm |
| 12:16:24 | Torne | i'm concerned about the recent spate of people having issues installing on ipod |
| 12:16:44 | Torne | but maybe it's just a coincidence and they all have knackered drives :) |
| 12:17:09 | Llorean | Several of them seem to be 1st gen Nanos, right? |
| 12:17:26 | Torne | i think so |
| 12:17:39 | Torne | there was also one guy reporting the "buttons don't work after hold" thing on ipodvideo |
| 12:17:46 | Torne | which we thought we fixed ages ago |
| 12:18:00 | Torne | but then a couple of people complained it still happened on the mini |
| 12:18:10 | Torne | hadn't heard anyone mention it on any other model until now |
| 12:18:43 | gevaerts | I wonder if this is just a sign of a new large group of people discovering rockbox |
| 12:18:53 | gevaerts | We have been in the news in some circles recently |
| 12:18:54 | Torne | possibly. |
| 12:19:13 | Torne | oh, it's a good job nwe didn't do anything to host the psgroove thing it seems |
| 12:19:21 | Torne | since sony are now suing the crap out of eveyrone who is |
| 12:19:41 | pixelma | ah, I wanted to look up when the fix got committed exactly, because the guy with the buttons not working after hold said he would be using r3.6 |
| 12:19:49 | Torne | pixelma: i'm pretty sure it was long before 3.6 |
| 12:19:53 | pixelma | as in "release" |
| 12:19:55 | Torne | lemme check, it's on my watchlist |
| 12:20:32 | Llorean | What skin change seems to have caused all the instability? |
| 12:20:36 | pixelma | there are also these instability issues on some Fuzes |
| 12:20:54 | gevaerts | Llorean: basically the entire skin handling was rewritten since 3.6 |
| 12:21:06 | pixelma | Llorean: there were quite a few in quick succession :\ |
| 12:21:18 | gevaerts | Some instability is not really unexpected in those conditions |
| 12:21:41 | Llorean | gevaerts: True. I was just curious if it was done right after 3.6, or like... within the last month or so. |
| 12:21:54 | Llorean | I mean it seems like 3 months ought to be enough time to get stability at least reasonably recovered. |
| 12:22:03 | Torne | the fix for the wheel thing was committed in july 2009 so it should be in 3.6 |
| 12:22:14 | gevaerts | Llorean: part of it was gsoc |
| 12:22:20 | Torne | unless subsequent changes to the wheel driver (nano2g being merged with it) broke it again :) |
| 12:24:20 | * | Llorean will try to dig up his 1G Nano tomorrow. |
| 12:24:43 | Torne | yeah i should actually update my ipodvideo and test it for a bit |
| 12:25:05 | Llorean | Though if I recall mine tended to be one of the ones that didn't show issues the last few times we had "only some players have this problem" types of issues too. |
| 12:25:37 | * | Llorean does wish Rockbox were releasing more consistently. |
| 12:27:17 | Torne | I'm still pondering if we should maybe provide *both* shutdown workarounds as alternatives |
| 12:32:54 | | Quit petur (Quit: *plop*) |
| 12:37:10 | Llorean | Torne: What are they? How? |
| 12:37:45 | Torne | Llorean: currently the ipods clear the latter part of IRAM on shutdown to try and make startup not fail |
| 12:37:56 | Torne | this doesn't seem to work for everyone, but it has no negative effect i'm aware of |
| 12:38:16 | Torne | the older workaround of shutting down by rebooting to the OF made lots of people's players behave weirdly but fixes the problem for more people |
| 12:39:37 | Llorean | Except those it makes behave weirdly? |
| 12:40:07 | Torne | no, some of those people are the same people :) |
| 12:40:26 | Llorean | Well new weird behavior doesn't really make it a "fix" does it? |
| 12:41:06 | * | Torne shrugs :) |
| 12:42:22 | | Join timc [0] (~tim@112.166.15.141) |
| 12:42:25 | | Nick timc is now known as Guest75106 (~tim@112.166.15.141) |
| 12:46:54 | | Part LinusN |
| 12:47:06 | | Join LinusN [0] (~linus@rockbox/developer/LinusN) |
| 12:48:05 | | Part LinusN |
| 12:49:25 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 12:50:32 | | Join LinusN [0] (~linus@rockbox/developer/LinusN) |
| 12:54:49 | | Part LinusN |
| 12:55:03 | | Part Zagor |
| 12:55:12 | | Join Zagor [0] (~bjst@rockbox/developer/Zagor) |
| 13:00 |
| 13:00:18 | | Quit Hadaka (Ping timeout: 240 seconds) |
| 13:02:38 | Llorean | gevaerts: Another possibility is that the psgroove build of Rockbox has other unexpected bugs for whatever reason, and that's why these people are having additional difficulties? |
| 13:03:20 | gevaerts | Llorean: I'd hope they try a standard build first |
| 13:03:40 | Llorean | Hah. One can hope for anything, I suppose. |
| 13:10:07 | | Join LinusN [0] (~linus@rockbox/developer/LinusN) |
| 13:10:20 | | Join Hadaka [0] (~naked@naked.iki.fi) |
| 13:21:29 | | Part LinusN |
| 13:25:55 | | Join teru [0] (~teru@KD059133111160.ppp.dion.ne.jp) |
| 13:35:16 | | Join krazykit [0] (~kkit@24-148-89-52.frg-bsr1.chi-frg.il.cable.rcn.com) |
| 13:36:53 | | Quit wodz (Quit: CGI:IRC (Ping timeout)) |
| 13:50:12 | | Join wodz [0] (~5f303f8a@giant.haxx.se) |
| 13:50:24 | wodz | teru: ping |
| 13:50:41 | teru | wodz: pong |
| 13:51:07 | wodz | I updated patch for png plugin |
| 13:51:33 | teru | I saw it. |
| 13:51:39 | wodz | I refactored code so decoder is selfstanding and do not depend on global vars |
| 13:51:58 | wodz | I have fixes for mrobe scaling in my tree also |
| 13:52:54 | *** | Saving seen data "./dancer.seen" |
| 13:53:03 | wodz | I fixed simple_resize_bitmap() and realy do not wan't to touch smooth_resize_bitmap() |
| 13:56:07 | wodz | what is the point of different draw_image_rect() separate for every format? |
| 13:56:15 | wodz | teru:^ |
| 13:56:58 | teru | jpeg doesn't create native bitmap. |
| 13:57:23 | wodz | I see |
| 13:59:12 | teru | wodz: I tried v2 patch on my gigabeat but I only get "Invalid CRC". I guess *(uint32_t *)(in + N) doesn't work but not sure. |
| 13:59:21 | | Join n1s [0] (~n1s@nl118-174-240.student.uu.se) |
| 13:59:21 | | Quit n1s (Changing host) |
| 13:59:21 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 13:59:47 | wodz | do we look for magic values to determine decoder or we simply relay on file extension? |
| 14:00 |
| 14:00:07 | teru | just only file extention. |
| 14:03:54 | wodz | strange |
| 14:04:23 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 14:06:38 | wodz | teru: could You prove this by changing *(uint32_t *)(in + N) to in[N]<<24 | in[N+1]<<16|in[N+2]<<8|in[N+3] and see if this passes CRC check? |
| 14:09:01 | teru | I'll try. |
| 14:09:50 | n1s | wodz: most pc's are little endian so testing that in the sim on a pc should work |
| 14:09:59 | wodz | it works on sim |
| 14:10:37 | | Quit einhirn_ (Ping timeout: 240 seconds) |
| 14:10:41 | n1s | (also casting a char pointer to a larger type and dereferencing it can cause data aborts on arm) |
| 14:10:49 | n1s | if the char pointer is not aligned |
| 14:11:52 | wodz | this is probably the case :/ |
| 14:12:48 | n1s | teru: what gigabeat is that? |
| 14:13:05 | teru | gigebeat X30 |
| 14:13:44 | n1s | then it would throw an exception on a misalinged access which it isn't doing if it complains about invalid crc |
| 14:15:20 | gevaerts | Doesn't the gigabeat F/X have some unusual behaviour with unaligned accesses? |
| 14:15:56 | n1s | oh, i thought any of our arm's other than the beast aborted |
| 14:16:14 | wodz | anyway I'll change back to byte-by-byte png interpretation |
| 14:16:18 | n1s | if it doesn't abort it probably gives back rotated data or something |
| 14:17:09 | | Quit bertrik (Read error: Connection timed out) |
| 14:17:12 | n1s | wodz: there are functions for reading from a char array and translating into integer of chosen endianness in many places in rockbox |
| 14:17:42 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 14:17:45 | gevaerts | I know my F usually freezes with code that makes other ARM DAPs give data aborts |
| 14:18:20 | n1s | hmm, i think that is configurable for at least some cores, maybe it's just turned off for some reason on the f/x? |
| 14:19:30 | wodz | ? I am aware of betoh16(), betoh32() and little endian variants but this takes value as argument not ptr to array |
| 14:20:44 | n1s | for example apps/metadata/metadata_common.c get_(long|short)_(be|le) |
| 14:21:38 | wodz | are they any faster than 'get-byte-shift' stuff? |
| 14:22:02 | Torne | what processor is the gigabeat f? |
| 14:22:03 | n1s | no, they do exactly that but since you seem to have trouble tested functions could be nice |
| 14:22:17 | n1s | Torne: arm9tdmi |
| 14:22:30 | Torne | maybe their bootcode enables unaligned |
| 14:23:20 | Torne | hm, except a tdmi wouldn't have the register |
| 14:23:49 | | Quit wodz (Quit: CGI:IRC) |
| 14:27:20 | teru | changed betoh32(*(uint32_t) (X)) to (((uint32_t) (X)[0] << 24) | ((uint32_t) (X)[1] << 16) |((uint32_t) (X)[2] << 8)|((uint32_t) (X)[3])) and it worked. |
| 14:27:36 | Torne | Oh right, yes :) |
| 14:27:46 | Torne | ARMs without CP15 don't genreate alignment faults |
| 14:27:51 | Torne | they just return rotated data, always |
| 14:28:10 | Torne | so ARM7TDMI and ARM9TDMI will just fuck up |
| 14:28:34 | Torne | ARMs with CP15 default to generating alignment faults, but it can be turned off (until ARMv7 where it defaults to allowing them) |
| 14:29:26 | Torne | n1s: the beast probably aborts, ARMv6 still doesn't allow it by default even though it does the right thing |
| 14:31:39 | n1s | Torne: according to this http://svn.rockbox.org/viewvc.cgi/trunk/firmware/target/arm/imx31/crt0.S?r1=17458&r2=17495 strict alignment is disabled, not that i know why though |
| 14:32:32 | Torne | it probably shouldn't be |
| 14:32:49 | Torne | unless we have ARMv6 specific code which is using it specifically |
| 14:33:19 | n1s | is a misaligned long load faster than individual byte loads on v6? |
| 14:33:26 | Torne | not if it's not cached |
| 14:33:27 | Torne | unaligned cache fills are slower and it only works for LDR, not LDM (or LDREX/etc) |
| 14:33:48 | Torne | i forget the exact cycle timing of doing the load unaligned |
| 14:34:08 | Torne | but generally the code would have to be *really* heavily dependent on accessing unaligned data for it to be faster to not fix it |
| 14:34:30 | n1s | we do use unaligned loads explicitely on coldfire in some place(s) as it's faster there |
| 14:34:50 | Torne | well, the core->cache interface only knows aligned accesses |
| 14:35:02 | Torne | so the unaligned accesses are emulated on core by rotates and stuff |
| 14:36:02 | Torne | if we do actually do it anywhere i'd be curious to see benchmarks |
| 14:36:03 | n1s | hmm, the case i remember is bitstream reading in codecs so if it fetches subsequent memory to the cache probably doesn't hurt |
| 14:36:16 | Torne | n1s: well the cache->core transfer is more expensive too, is my point |
| 14:36:21 | Torne | it's not just potentially having to bring in more cachelines. |
| 14:36:22 | n1s | ah |
| 14:37:07 | * | Torne shrugs |
| 14:37:23 | Torne | since we run on armv5 there must be an aligned versoin of any code that does it too |
| 14:37:27 | Torne | so it would be easy to bench :) |
| 14:37:32 | Torne | well, easysh |
| 14:37:50 | n1s | i could bench on my beast, although test_codec runs are abit skewed i think, since when the core is running at full speed memory accesses will be relatively slower |
| 14:38:04 | | Join Jaykay [0] (~chatzilla@p5DC56D49.dip.t-dialin.net) |
| 14:38:08 | Torne | It was always traditional to leave it disabled so that you didn't accidentally write code that wouldn't work on ARMv5 |
| 14:38:15 | n1s | unless i misunderstood all that |
| 14:38:19 | Torne | but ARM themselves now allow it by default in v7 |
| 14:38:25 | Torne | so, who knows :) |
| 14:38:32 | * | n1s tests |
| 14:39:49 | Torne | also i guess the armv5 and armv6 versions of a given bit of code are not necessarily comparable anyway |
| 14:42:35 | | Nick drizztbsd__ is now known as drizztbsd (~quassel@dynamic-adsl-78-12-185-162.clienti.tiscali.it) |
| 14:54:51 | n1s | hmm, usb inside rockbox is super screwy on my beast |
| 14:55:12 | n1s | keeps disconnecting and reconnecting and then died with a black screen and shut off |
| 14:55:29 | n1s | bootloader usb is still stable as a rock |
| 14:58:24 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 14:58:42 | | Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) |
| 14:59:35 | n1s | Torne: doing a straing long load + byteswap instead of 4 individual byteloads in the ffmpeg bitstream reading code speeds up flac decoding by 3.5% on the beast |
| 14:59:49 | n1s | s/straing/straight/ |
| 15:00 |
| 15:00:00 | Torne | Heh |
| 15:00:07 | Torne | well, ok then |
| 15:00:33 | n1s | so now the flac 8 test file decodes in 3.56s instead of 3.69 :) |
| 15:00:34 | Torne | i assume it's already hidden behind a macro |
| 15:00:39 | n1s | yep |
| 15:00:57 | Torne | is it already ifdef'ed for v6, then, or are you adding that? |
| 15:01:58 | | Part Zagor |
| 15:02:17 | n1s | i'd have to add that, it's just #ifdef for coldfire ATM |
| 15:02:57 | Torne | well, sounds worthwhile :) |
| 15:04:23 | n1s | it could even be generalized into htobe32(*(const uint32_t*)(x)) as htobe will not do anything on coldfire |
| 15:06:19 | n1s | there's also ROCKBOX_STRICT_ALIGN which is defined for all ARM cpus (as well as sh and mips) but this is checked in only one place |
| 15:07:15 | n1s | in, dircache.c |
| 15:15:55 | | Join {-phoenix-} [0] (~dirk@p57AA5117.dip.t-dialin.net) |
| 15:19:50 | | Join evilnick_B [0] (0c140464@rockbox/staff/evilnick) |
| 15:20:05 | CIA-81 | New commit by nls (r28183): ARMv6 supports unaligned memory accesses and they are enabled on our only ARMv6 target so we might as well use them. Speeds up decoding of a flac8 ... |
| 15:20:17 | | Quit {phoenix} (Ping timeout: 272 seconds) |
| 15:21:00 | n1s | hmm, my checkin seems to have hung |
| 15:21:58 | CIA-81 | r28183 build result: All green |
| 15:23:26 | CIA-81 | New commit by teru (r28184): explicitly set img->using_preloaded_icons in parse_image_load() and don't rely on parse_image_display(). |
| 15:23:28 | n1s | the command still hasn't returned... |
| 15:24:03 | | Join einhirn [0] (Miranda@vpn10.rz.tu-clausthal.de) |
| 15:25:04 | CIA-81 | r28184 build result: All green |
| 15:47:08 | amiconn | gevaerts: At least on SH the C string "Game" needs 8 bytes |
| 15:50:10 | n1s | amiconn: because of alignment or something else? |
| 15:50:24 | n1s | btw, no sh targets have these codecs anyway |
| 15:52:58 | *** | Saving seen data "./dancer.seen" |
| 15:55:54 | amiconn | Yes. For some reason, sh-elf-gcc aligns all strings at 4 byte boundaries |
| 15:56:36 | amiconn | We would save quite a bit of binsize if we could change that. Unfortunately I never found out whether that's possible |
| 15:57:30 | n1s | that seems stupid if the alignment isn't required by something |
| 15:59:32 | amiconn | It *may* be required by gcc's inline string/mem copying stuff |
| 16:00 |
| 16:15:51 | | Join Nausicaa [0] (~Nausicaa@c-71-239-58-153.hsd1.il.comcast.net) |
| 16:16:21 | | Quit antil33t () |
| 16:19:25 | | Join sudoman [0] (d8ecfce7@gateway/web/freenode/ip.216.236.252.231) |
| 16:36:43 | | Quit {-phoenix-} (Remote host closed the connection) |
| 16:37:19 | amiconn | [14:27:45] <Torne> ARMs without CP15 don't genreate alignment faults <== At least that's not true for PP |
| 16:38:35 | | Join engwan_ [0] (~engwan@112.202.22.199) |
| 16:38:54 | | Join kevku [0] (~kevku@arch.tunnel.ipv6.estpak.ee) |
| 16:39:01 | amiconn | [14:55:11] <n1s> keeps disconnecting and reconnecting and then died with a black screen and shut off |
| 16:39:19 | amiconn | ^ that's probably due to USB charging. I do have the same problem when using my hub |
| 16:39:40 | amiconn | My hub does proper overcurrent shutdown, and the charging code draws more than what's allowed |
| 16:39:52 | n1s | amiconn: ah, i'll test disabling that |
| 16:40:36 | Torne | amiconn: the cache cell probably does it as an external abort |
| 16:41:17 | n1s | amiconn: that was it, thanks |
| 16:41:17 | Torne | amiconn: there's no such thing as an alignment fault without CP15, anyway; all aborts are external. they might still be caused by wrong alignment, but it's up to the external device |
| 16:44:04 | | Join HeWhoMustNotBeNa [0] (~pbbbhhttt@119.153.38.29) |
| 16:44:54 | HeWhoMustNotBeNa | awfully quiet in here isnt it? |
| 16:46:22 | GodEater | always |
| 16:46:38 | Torne | nobody talked for almost sixty whole seconds |
| 16:46:47 | HeWhoMustNotBeNa | lol |
| 16:47:19 | Llorean | n1s: So, bringing the sample rate topic in here. |
| 16:47:25 | HeWhoMustNotBeNa | its a conspiracy against me, a conspiracy of silence |
| 16:47:30 | Llorean | A setting for "preferred sample rate" that resamples everything to it? |
| 16:47:39 | amiconn | Torne: Okay, regardless of how it's generated, PP fires data abort on unaligned accesses |
| 16:48:04 | * | Llorean would prefer, then, if there was also an option of "native" that disabled features incompatible with native sample rates, but played things back at their native ones, too, possibly |
| 16:48:08 | Torne | right, but htat's unrelated to whether any other ARM does |
| 16:48:14 | Torne | because it's external. |
| 16:48:16 | n1s | Llorean: i'm no expert but that's the approach i think seemed the most feasible from previous discussions on the subject |
| 16:48:22 | amiconn | n1s: It's kinda funny that my laptop doesn't do overcurrent shutdown, but my external (powered) hub does |
| 16:48:27 | Torne | a normal ARM7TDMI wouldn't. |
| 16:48:34 | HeWhoMustNotBeNa | hey guys, what are the chances of getting flamed (or worse) for asking a truly noob question in here |
| 16:48:56 | amiconn | I usually connect the charger in order to avoid the effect. It also doesn't happen if the beast is fully charged |
| 16:49:19 | n1s | amiconn: i used the frontside ports on my computer... i wonder why our usb charging does this, shouldn't it negotiate the current? |
| 16:49:29 | | Join togetic [0] (~togetic@unaffiliated/ibuffy) |
| 16:49:35 | amiconn | It does, but somehow the calculation seems to be off |
| 16:49:42 | GodEater | HeWhoMustNotBeNa: virtually none, provided you're polite about it :) |
| 16:50:06 | amiconn | I.e. it calculates how much the charger is allowed to draw for a certain amount of total current, but that calculation is a bit off |
| 16:50:18 | HeWhoMustNotBeNa | i should be able to accomplish that I think, being polite that is |
| 16:50:19 | Llorean | HeWhoMustNotBeNa: Though, if it's *truly* noob-ey, you might check the manual first to avoid being referred to it. |
| 16:51:03 | HeWhoMustNotBeNa | Llorean, i am trying to read as much as possible.....but my 3 year old daughter wants me to vacate the pc so time is of the essence |
| 16:51:28 | n1s | Llorean: it's not only a problem of dsp things but switching the actual DAC to a new samplerate needs, to be done and at an exact time and this switching introduces glitches AFAIU |
| 16:52:12 | HeWhoMustNotBeNa | is it safe / advisable to use the rockbox utility to install rockbox for a noob like me? |
| 16:52:24 | Llorean | n1s: If you don't care about gapless, couldn't you let the PCM buffer empty of 44.1 content, switch, then start decoding 48 content? |
| 16:52:42 | Llorean | HeWhoMustNotBeNa: Rockbox Utility is intended to be very safe. |
| 16:53:09 | n1s | Llorean: probably |
| 16:53:13 | HeWhoMustNotBeNa | excellent. thanks Llorean |
| 16:53:38 | Torne | Llorean: yeah, that'd be the easiest way |
| 16:53:40 | Llorean | n1s: I'd say that sort of thing is reasonable enough for people who want multiple sample rates mixed. |
| 16:54:05 | Llorean | I'd *suspect* that at least within a single album they'll always be the same sample rate, and that's (to my experience at least) where gapless is generally important. |
| 16:54:46 | n1s | Llorean: i'm cynical so i expect people will complain whatever we do :) |
| 16:55:00 | Llorean | You could also just not bother fixing any of the DSP stuff to work with 48khz, and just require people to use resampling if they want DSP, since that affects audio quality anyway. :-P |
| 16:55:11 | HeWhoMustNotBeNa | Llorean, i was reading different instructions elsewhere and there are 2 files for the installation there 1. Rockbox ipod nano 1g 2. ipod patcher 1g nano |
| 16:55:28 | Torne | HeWhoMustNotBeNa: that's to do it manually; just use the utility |
| 16:55:33 | Llorean | HeWhoMustNotBeNa: Just use our manual. Other instructions aren't supported. |
| 16:55:34 | HeWhoMustNotBeNa | if I use the utility would, it have the ptcher builtin? |
| 16:56:19 | HeWhoMustNotBeNa | Llorean, many thanks.....i had to read those instructions as I want to port psgroove on the nano later |
| 16:56:23 | Torne | the utility downloads everything it needs automatically |
| 16:57:01 | HeWhoMustNotBeNa | then I would like to thank all the people who have made this utility |
| 16:57:16 | HeWhoMustNotBeNa | i shall go the utility way now |
| 16:57:19 | Llorean | HeWhoMustNotBeNa: The psgroove patch isn't really supported. You can get help installing normal Rockbox in here (which is dead simple on the Nano and pretty much automated) but for help with the psgroove stuff you should contact its author. |
| 16:57:51 | HeWhoMustNotBeNa | i know Llorean, i wasnt going to ask about psgroove in here in the first place |
| 16:58:14 | HeWhoMustNotBeNa | i'm very thankful for all of your help.....i shall bother you guys again if i run into any problems |
| 16:58:22 | | Quit einhirn (Ping timeout: 265 seconds) |
| 17:00 |
| 17:01:46 | | Join Xerion [0] (~xerion@541907CA.cm-5-2a.dynamic.ziggo.nl) |
| 17:02:29 | | Quit teru (Quit: Quit) |
| 17:14:42 | soap | Would not an interim solution be to keep the all-44 playback and introduce an "audiophile grade" resampler and tell the audiophools to stuff themselves if they think 48->44 is bad because "it is not integral"? |
| 17:15:53 | evilnick_B | Isn't it that a better resampler is too expensive in terms of cpu cycles? |
| 17:16:02 | Llorean | Would adding a higher quality resampler be easier than enabling native playback in a "no DSP, no crossfade, no gapless" way? |
| 17:16:19 | soap | the expense is only born by those who choose to use it. |
| 17:16:49 | soap | Llorean, I would think a higher quality resampler would be /preferable/ to "no DSP, etc" |
| 17:16:57 | Llorean | evilnick_B: Yeah, it's like saying "aren't the constant spinups of FLAC too expensive on disk targets?", people can deal with it if that's what they really want. |
| 17:17:20 | Llorean | soap: Which DSP are we really talking about here? How many of them are things "audiophiles" are actually going to turn on? |
| 17:17:53 | Llorean | I'm not talking about disabling them entirely, just disabling them when someone switches from "resample everything to 44.1" to "native playback" |
| 17:19:19 | | Quit AlexP (Remote host closed the connection) |
| 17:19:36 | soap | I don't care which DSP is affected. If we consider DVD audio rips there is a source of legit 48K material which should not be burdened by either forceable PC-side resampling or lack-of-DSP. A good resampler should have identical perceptual quality to native 48k, so I don't see the advantage of native 48k playback if it would be burdensome on the rest of the Rockbox audio chain. |
| 17:20:23 | soap | (and when I say "I don't care" I mean "I don't think it matters") |
| 17:20:44 | Llorean | People aren't going to stop asking for native support just because there's a good resampler. |
| 17:21:12 | Llorean | What's better? Saying "no, you can't have it" or "you can have it, but when you're using it some other features may not be available"? |
| 17:21:28 | soap | people aren't going to stop asking for all sorts of indefensible things. |
| 17:21:40 | | Join AlexP [0] (~alex@rockbox/staff/AlexP) |
| 17:21:47 | Llorean | But this is one that could not only be provided, but falls into the category of "better making use of the hardware's features" |
| 17:22:11 | soap | If you could tell them "Rockbox's resampler is just as good as native 48k" (which you can't now)... |
| 17:22:53 | soap | but a better resampler serves more people than native 48k on the hardware which can do 48k. |
| 17:23:14 | saratoga_ | i think native 48k is probably not that hard to do |
| 17:23:18 | Llorean | How bad is our resampler? |
| 17:23:22 | saratoga_ | really bad |
| 17:23:27 | soap | it allows all the crazy sampling rates, and supports all the (powerful enough) software decoding targets. |
| 17:23:33 | Llorean | For 48->44.1 is it noticeable? |
| 17:23:35 | saratoga_ | most of the stuff will work with 48k more or less, since its so close to 44.1k |
| 17:23:48 | bertrik | Llorean, saratoga_ why do you think it's really bad? Has anyone ever measured it? |
| 17:23:52 | saratoga_ | could probably use the EQ as is and just shift the center frequency values a couple percent |
| 17:24:00 | saratoga_ | bertrik: its linear interpolation |
| 17:24:04 | Llorean | bertrik: I don't know how bad it is, that's why I'm asking. I've just been told it's bad. |
| 17:24:30 | bertrik | saratoga_, so, that doesn't have to be so bad |
| 17:24:45 | Llorean | Is linear interpolation really that bad a way to resample audio? I don't know much about it, but it seems it'd be semi-reasonable. |
| 17:24:56 | saratoga_ | theres only one way to do linear interpolation, so it pretty much has to be bad |
| 17:25:52 | saratoga_ | give me a sec, i'll make a plot |
| 17:25:56 | saratoga_ | i've got matlab open |
| 17:28:12 | bertrik | It would be nice to have some hard data on the various methods (and their computational impact) |
| 17:29:07 | HeWhoMustNotBeNa | Llorean, it worked...i have rockbox on my nano now.........many thanks |
| 17:29:30 | HeWhoMustNotBeNa | but how do i switch between rockbox and the default os? |
| 17:29:41 | gevaerts | That's described in the manual |
| 17:30:03 | HeWhoMustNotBeNa | there now |
| 17:30:58 | saratoga_ | bertrik: at FS/3, resampling via linear interpolation down by 20% results in an aliased copy of the signal thats attenuated by 7dB relative to the peak |
| 17:31:15 | saratoga_ | source peak i mean |
| 17:32:29 | HeWhoMustNotBeNa | i havent used this thing for ages and i forgot what the select button was |
| 17:32:30 | HeWhoMustNotBeNa | oops |
| 17:32:34 | | Quit tchan (Quit: WeeChat 0.3.3-dev) |
| 17:32:36 | sudoman | i'm looking at rockbox/firmware/target/arm/ipod/button-clickwheel.c line 357: "static bool hold_button = false;". is that correct? and does it have anything to do with this: http://www.rockbox.org/tracker/task/5230 ? |
| 17:33:18 | gevaerts | sudoman: how can a variable declaration on its own be incorrect? |
| 17:34:07 | Llorean | saratoga_: We're primarily talking about 48->44.1 though |
| 17:34:13 | HeWhoMustNotBeNa | gevaerts, it says shutting down and then it restarts :( |
| 17:34:20 | HeWhoMustNotBeNa | or Llorean for that matter |
| 17:34:22 | saratoga_ | 48/44.1 |
| 17:34:26 | saratoga_ | opps |
| 17:34:38 | saratoga_ | i'll try 9% |
| 17:35:14 | pixelma | Llorean: I could make out an additional hiss when playing back a really bad quality 11.025kHz file in swcodec Rockbox compared to it being played back in foobar2000 but that's an extreme example (and since it was bad quality to start with...) |
| 17:35:16 | bertrik | saratoga_, the signal is a 16 kHz sine I assume? |
| 17:35:31 | sudoman | gevaerts: well i'm not very experienced in this, but in context, it looks like the the test: "if (hold_button)" is only being performed if the "hold_button" in the previous test is true, but it should be peformed if there's any difference to "hold_button_old" |
| 17:36:12 | sudoman | why is "hold_button_old" automatically false? what if it was on before? |
| 17:36:25 | sudoman | * what if it was on hold? |
| 17:37:17 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
| 17:37:59 | Llorean | pixelma: I'm kinda surprised that upsampling from a fraction of 44.1 causes noticeable sound problems. |
| 17:38:08 | * | Llorean doesn't know why he would expect it not to though, just does. |
| 17:39:51 | | Join bmbl [0] (~Miranda@unaffiliated/bmbl) |
| 17:40:04 | saratoga_ | bertrik: http://duke.edu/~mgg6/pics/10khztone_resample48to441.png |
| 17:40:08 | pixelma | oh, just looked it up... it's even an 8kHz mono file |
| 17:40:21 | sudoman | gevaerts: what do you think? |
| 17:41:48 | saratoga_ | bass frequency obviously work a lot better, higher ones a lot worse |
| 17:43:06 | pixelma | I believe preglow also had a distinct opinion about our resampler ;) |
| 17:43:39 | pixelma | just thinking he could add some facts to the discussion |
| 17:43:40 | saratoga_ | didn't he write it? |
| 17:44:47 | bertrik | saratoga_, I'm not sure how to interpret that. Isn't the blue peak at around 1050 the same as the red peak at around 1250 the same, except resampled? |
| 17:45:12 | saratoga_ | bertrik: yes, when you resample the size of each frequency bin changes, so the FFT peaks won't line up |
| 17:45:20 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 17:45:50 | bertrik | The next highest blue peak is about 25 dB down |
| 17:46:29 | saratoga_ | thats not very good |
| 17:47:02 | bertrik | I agree, but far from the 7 dB you mentioned earlier :) |
| 17:47:27 | HeWhoMustNotBeNa | thanks for all your help guys!!! |
| 17:47:33 | HeWhoMustNotBeNa | bye from Pakistan |
| 17:47:36 | | Quit HeWhoMustNotBeNa () |
| 17:48:55 | | Join Staphylo [0] (~Bullet@AMontsouris-159-1-51-172.w92-128.abo.wanadoo.fr) |
| 17:50:29 | saratoga_ | bertrik: like I said it depends on frequency |
| 17:50:41 | saratoga_ | so as you decrease the test tone frequency you will decrease the aliasing |
| 17:51:33 | saratoga_ | and unfortunately as you increase the frequency it aliases into lower frequencies |
| 17:52:42 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
| 17:53:00 | *** | Saving seen data "./dancer.seen" |
| 17:53:16 | bertrik | Is this 9% frequency change, or 20% ? |
| 17:53:55 | saratoga_ | 9% |
| 17:54:01 | saratoga_ | do you have matlab? i can give you the code |
| 17:54:03 | saratoga_ | its just 2 lines long |
| 17:54:13 | bertrik | no, I don't |
| 17:54:27 | saratoga_ | ah ok |
| 17:55:00 | saratoga_ | well heres what i did: http://pastebin.com/0qWR3T55 |
| 17:55:05 | saratoga_ | should give you an idea what you're looking |
| 17:56:16 | saratoga_ | the basic problem here is that linear interpolation takes quiet high frequency noises and turns them into (perceptually louder) mid frequency noises |
| 17:57:59 | n1s | how much more complex are better resampling algos? |
| 17:58:34 | n1s | linear needs, like a an add and a shift per sample, right? |
| 17:59:18 | gevaerts | sudoman: yes, isn't that what happens? |
| 18:00 |
| 18:00:40 | bertrik | n1s, it uses a multiply for each input sample plus some adding |
| 18:01:18 | n1s | bertrik, oh |
| 18:01:49 | saratoga_ | its only a shift if you're resamplilng by a factor of 2 :) |
| 18:03:08 | | Join hebz0rl [0] (~hebz0rl@dslb-088-067-199-113.pools.arcor-ip.net) |
| 18:03:26 | sudoman | gevaerts: it looks like "if (hold_button)" on line 368 won't be tested if hold_button is false because it is nested by the previous condition wich assumes that hold_button_old is false. so if the hold button is turned off then the input won't be unlocked. |
| 18:04:26 | n1s | right, i wasn't thinking :) |
| 18:04:31 | sudoman | gevaerts: maybe line 368 shouldn't be nested by line 364 |
| 18:04:44 | saratoga_ | cubic interpolation would be the next simplest thing, i think it needs something like a dozen multiplies per output sample |
| 18:04:45 | bertrik | Has anyone currently online ever done an ams sansa recovery? |
| 18:05:10 | gevaerts | sudoman: "which assumes that hold_button_old is false"? Where does it do that? |
| 18:05:11 | saratoga_ | though maybe non-polynomial resampling would be more efficient |
| 18:05:32 | gevaerts | sudoman: except for the first time after boot |
| 18:05:37 | saratoga_ | i really don't know much about the various algorithms other then linear < cubic spline < sinc |
| 18:05:46 | bertrik | Probably somebody has already designed 48->44.1 khz algorithms |
| 18:05:51 | sudoman | "hold_button_old = hold_button; hold_button = button_hold();" right above |
| 18:06:09 | gevaerts | sudoman: That sets hold_button_old to whatever hold_button is, not false |
| 18:06:26 | sudoman | oops, i meant: " static bool hold_button = false; bool hold_button_old; /* normal buttons */ hold_button_old = hold_button;" |
| 18:06:29 | saratoga_ | yeah theres hundreds on PC, but most of them use 50-100MHz on an Intel machine since they insist on having >120dB accuacry or something stupid |
| 18:07:17 | gevaerts | sudoman: did you miss the "static" there? |
| 18:07:24 | n1s | saratoga_: "like a dozen multiplies per output sample" assuming 44.1kHz output in stereo would mean about 1 million multiplies per second, which *should* be doable |
| 18:07:27 | bertrik | What accuracy would be considered reasonable for rockbox, something like 60 dB? |
| 18:07:56 | saratoga_ | i'm not sure |
| 18:08:01 | sudoman | noob question: what does static do? |
| 18:08:12 | n1s | it makes the variable static |
| 18:08:27 | saratoga_ | i guess we should probably run the rockbox resampler (on the Sim) through RMAA and see what that says |
| 18:08:31 | n1s | (it survives after the function exits) |
| 18:08:56 | | Quit n1s (Quit: Lämnar) |
| 18:09:00 | sudoman | oh, so it only runs once? |
| 18:09:06 | gevaerts | it |
| 18:09:11 | gevaerts | 's only initialised once, yes |
| 18:09:24 | saratoga_ | i wonder if its just easier to support 48kHz though |
| 18:09:29 | sudoman | ok, ic sorry for the confusion |
| 18:09:53 | saratoga_ | i think the EQ wouldn't care at all since its only a 9% difference, so unless you want a 20kHz EQ band its going to be the same coefficients anyway |
| 18:10:30 | saratoga_ | probably just a matter of fishing out all those nasty built in assumptions about how long a sample lasts in the PCM system |
| 18:11:22 | bertrik | AFAIU, the sample frequency is important basically only in apps/dsp.c where we now have NATIVE_FREQUENCY, so we could make NATIVE_FREQUENCY a variable instead of a constant |
| 18:12:29 | saratoga_ | apply_crossfeed would need slightly different delay constants, but i doubt anyones going to notice |
| 18:12:44 | bertrik | ah, yes indeed |
| 18:13:46 | saratoga_ | we should probably ask Blue_Dude |
| 18:13:53 | saratoga_ | he was the last person to really work on the PCM code |
| 18:14:04 | saratoga_ | but i don't see anything in there thats all that tied to the exact value of sample rate |
| 18:14:46 | saratoga_ | EQ will fail badly if you try to use it on say 32kHz audio, but its probably reasonable to just disable it for really low sample rates or else force resampling in that case |
| 18:16:18 | saratoga_ | cross fade could be tricker to deal with, since i'm not sure how easy it is to see what the sample rate of a track is before you start playing it |
| 18:22:50 | | Join [sko] [0] (~sko]@p57A98798.dip0.t-ipconnect.de) |
| 18:30:07 | | Quit kevku (Remote host closed the connection) |
| 18:37:32 | | Join kevku [0] (~kevku@2001:7d0:0:f000::135d) |
| 18:38:48 | | Join _s1gma [0] (~d.d.derp@77.107.164.131) |
| 18:38:55 | | Quit togetic (Ping timeout: 245 seconds) |
| 18:39:30 | saratoga_ | www.hpl.hp.com/techreports/2002/HPL-2002-159.pdf |
| 18:39:38 | saratoga_ | "fast" FIR based resampler on ARM |
| 18:39:53 | saratoga_ | although at 13 taps I'm not sure if its fast in the sense we think of :) |
| 18:39:54 | | Join Jerom [0] (~jerome@95.171.137.111) |
| 18:41:39 | saratoga_ | looking online, a lot of arm stuff seems to use hermite splines for interpolation, which is basically just fitting a 3 order polynomial to the input data and then reading out the value at the output sample positions |
| 18:43:23 | | Quit swilde (Quit: ERC Version 5.3 (IRC client for Emacs)) |
| 18:44:29 | | Join togetic [0] (~togetic@unaffiliated/ibuffy) |
| 18:51:42 | | Join {phoenix} [0] (~dirk@p57AA5117.dip.t-dialin.net) |
| 18:52:44 | | Quit sudoman () |
| 18:58:27 | | Quit komputes (Quit: I haven't slept for ten days, because that would be too long.) |
| 18:58:29 | | Join crow [0] (~crowmo@chello080108001109.35.11.vie.surfer.at) |
| 19:00 |
| 19:11:05 | | Quit yorick (Read error: Operation timed out) |
| 19:13:08 | | Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) |
| 19:13:18 | | Quit DerPapst (Quit: Leaving.) |
| 19:13:30 | | Join yorick [0] (yorick@unaffiliated/yorick) |
| 19:24:15 | | Quit kevku (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/) |
| 19:24:23 | | Join leachim6 [0] (~leachim6@rrcs-97-78-139-149.se.biz.rr.com) |
| 19:24:27 | leachim6 | hey |
| 19:24:35 | leachim6 | does USB mode work at all in rockbox on the Fuze2? |
| 19:24:50 | leachim6 | like, wile using rockbox, can I plug in the cable to have it charge in the car? |
| 19:24:53 | leachim6 | no data, just charging |
| 19:25:13 | | Join Maggux [0] (~quassel@krlh-4d0350fa.pool.mediaWays.net) |
| 19:27:40 | leachim6 | nevermind, I got my answer. |
| 19:28:35 | | Quit bmbl (Quit: Bye!) |
| 19:34:53 | | Join Horscht [0] (~Horscht@p4FD4EF13.dip.t-dialin.net) |
| 19:34:53 | | Quit Horscht (Changing host) |
| 19:34:53 | | Join Horscht [0] (~Horscht@xbmc/user/horscht) |
| 19:38:28 | | Join Buschel [0] (~chatzilla@p54A3BBE7.dip.t-dialin.net) |
| 19:40:09 | Buschel | liar: you there? |
| 19:45:29 | | Quit crow (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) |
| 19:47:36 | | Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) |
| 19:48:04 | | Join crow [0] (~crowmo@chello080108001109.35.11.vie.surfer.at) |
| 19:53:04 | *** | Saving seen data "./dancer.seen" |
| 19:57:30 | Buschel | liar: (for the logs) from your nano2g patch I understood that you own an LCD type (2) ILI9320. it would be great if you could test FS #11646. this patch was already verified on LCD type (7) and needs test on the LCD type that you own. |
| 19:59:01 | crow | seems that patch I was missing for my nano 2g :D |
| 19:59:12 | | Quit Jerom (Ping timeout: 252 seconds) |
| 20:00 |
| 20:01:16 | Buschel | crow: do you own an nano2 2g with ILI9320 ? |
| 20:02:27 | | Join hadoukenx [0] (83d2648b@gateway/web/freenode/ip.131.210.100.139) |
| 20:08:34 | hadoukenx | I've searched the forum and know that most accessories are unable to interact with rockbox, but is rockbox capable of interpreting input signals over its serial port currently? |
| 20:09:08 | bertrik | hadoukenx, that depends on the target |
| 20:09:16 | bertrik | the specific player I mean |
| 20:09:17 | hadoukenx | sorry, sansa specifically |
| 20:09:27 | hadoukenx | c200 or e200 series |
| 20:09:56 | hadoukenx | v2 for both |
| 20:10:17 | bertrik | I think we have don't even have a serial driver for the sansas |
| 20:10:27 | crow | Buschel hmm how to know that? |
| 20:11:17 | bertrik | I don't know if there is currently anything known about the protocol used for sansa accessories |
| 20:11:29 | | Join kevku [0] (~kevku@arch.tunnel.ipv6.estpak.ee) |
| 20:12:49 | | Quit kevku (Client Quit) |
| 20:12:50 | Buschel | crow: just go to the debug menu, enter the battery debug screen's second screen (right-scrolling the nano's wheel) and there it is |
| 20:12:52 | amiconn | saratoga_ (and others): There's another problem wrt native 48kHz (and other sample rates) support: Not all targets can do that |
| 20:13:42 | amiconn | I.e. most targets can do several sample rates, but no target can do all 9 (or 12, if you allow up to 96kHz) standard rates |
| 20:13:59 | | Join Jerom [0] (~jerome@ks27625.kimsufi.com) |
| 20:14:25 | amiconn | Most notably, coldfire can only do 11.025, 22.05, 44.1, 88.2 |
| 20:14:39 | amiconn | So we still need a good resampler |
| 20:15:35 | | Join kevku [0] (~kevku@arch.tunnel.ipv6.estpak.ee) |
| 20:15:48 | amiconn | preglow wanted to look into this, as he asked for a recording of the iriver H1x0 OF resampling result for 48 -> 44.1 about 4 weeks ago |
| 20:16:00 | amiconn | Unfortunately he seems to have disappeared again :\ |
| 20:16:58 | | Join wodz [0] (~wodz@chello087206240131.chello.pl) |
| 20:18:58 | | Join DerPapst [0] (~Alexander@p5797CBDC.dip.t-dialin.net) |
| 20:25:19 | | Quit leachim6 (Ping timeout: 255 seconds) |
| 20:31:50 | pixelma | he posted in the forum today or yesterday ;) |
| 20:32:04 | pixelma | but about recording for D2 |
| 20:33:50 | crow | Buschel when i go to Debug Menu i see battery 4.104V ; 4.104-4.118V (5mV) |
| 20:34:05 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
| 20:34:05 | Buschel | crow: now scroll to the right |
| 20:34:18 | Buschel | crow: you will see another screen with lots of text then |
| 20:36:58 | crow | Buschel yea i see that screen, which option do i am looking for |
| 20:37:25 | Buschel | crow: LCD type |
| 20:38:56 | crow | Buschel dont see that option. |
| 20:39:02 | Buschel | crow: must be either ILI9320 or LDS176 |
| 20:39:50 | crow | Buschel LDS176 :) |
| 20:40:12 | crow | Buschel it was under Debug Menu> View HW info :) |
| 20:40:30 | Buschel | crow: good news for you, bad news for me... good = my patch will work for you, bad = still need a tester with the other type |
| 20:40:59 | crow | Buschel type: 1, (7) LDS176 |
| 20:41:14 | Buschel | crow: really? damn, my memory (brain, not RAM ;-) is tricking me |
| 20:41:34 | crow | Buschel well i am with rockbox just fev daysso i will not see much on battery drain.. |
| 20:42:00 | | Quit hadoukenx (Quit: Page closed) |
| 20:43:16 | Buschel | crow: with the patch your LCD should make this wheeeee sound anymore |
| 20:43:34 | Buschel | crow: of course "should _not_ make..." |
| 20:48:05 | | Quit CGL (Remote host closed the connection) |
| 20:52:41 | crow | Buschel didnt sow that jet :) |
| 20:57:22 | Buschel | crow: then you're a lucky one :) |
| 20:58:28 | crow | Buschel well as i wrote, i have rockbox just fev days.. |
| 20:58:31 | | Part Guest75106 ("Leaving.") |
| 20:58:51 | crow | installed with rockbox installed which picked up for my nano 2g latest rockbox version |
| 21:00 |
| 21:07:13 | | Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) |
| 21:13:54 | | Join webguest76 [0] (~56164ee6@giant.haxx.se) |
| 21:15:10 | | Quit webguest76 (Client Quit) |
| 21:24:32 | | Join kinky [0] (~kinky@brmn-4db711ea.pool.mediaWays.net) |
| 21:24:38 | kinky | greetings |
| 21:24:48 | | Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) |
| 21:26:46 | kinky | I've installed the rockbox daily build (r28184-100929) about an hour ago, and now I realise that the sound output is "wobbering". Every 1-2 seconds, the sound is going down and high again, it's really annoying. On the OF, the problem is nonexistant. |
| 21:27:30 | saratoga_ | what device do you have |
| 21:27:53 | kinky | saratoga_: a sandisk clip+ |
| 21:28:07 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 21:28:14 | | Quit stripwax (Client Quit) |
| 21:29:07 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 21:29:26 | | Quit stripwax (Client Quit) |
| 21:33:48 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 21:37:43 | kinky | so, should I replace my .rockbox folder with an older version? maybe this one? : http://download.rockbox.org/daily/sansaclipplus/rockbox-sansaclipplus-20100927.zip |
| 21:39:16 | | Quit togetic (Quit: WeeChat 0.3.0) |
| 21:39:31 | | Quit anewuser () |
| 21:40:02 | evilnick_B | kinky: It'd be much more use to check recent changes to svn that affect your target/playback and revert to a build before any likely change happened |
| 21:41:07 | evilnick_B | The Daily builds are just whichever svn revision happens to be checked in each day at a certain time. i.e. they're not special. |
| 21:42:18 | * | gevaerts suggests waiting for a developer who's familiar with the clip+ |
| 21:42:24 | | Join panni_ [0] (hannes@ip-178-203-81-220.unitymediagroup.de) |
| 21:42:33 | kinky | evilnick_B: I will look around a lil bit in the repo, regarding major changes |
| 21:42:44 | kinky | got my clip+ just yesterday :o |
| 21:46:54 | | Quit [sko] (Quit: Leaving.) |
| 21:53:05 | | Quit stripwax (Ping timeout: 245 seconds) |
| 21:53:08 | *** | Saving seen data "./dancer.seen" |
| 21:55:34 | | Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) |
| 22:00 |
| 22:00:59 | Maggux | Are there anywhere more levels for Bubbles? or just the 7 |
| 22:04:06 | soap | amiconn, can I assume the iRiver H3x0 OF resampling would be equivelent to the H1x0 OF resampling? |
| 22:04:21 | amiconn | I don't know |
| 22:04:46 | amiconn | The reason why preglow asked for the H1x0 output is that it can be recorded digitally |
| 22:04:46 | | Join simonrvn_ [0] (simon@64.235.201.43) |
| 22:04:53 | soap | I could record a loop of the RMAA test sweeps as resampled by the H3x0 if that would be of any service. |
| 22:04:58 | soap | ahh |
| 22:05:03 | * | amiconn did this using his archos recorder and the wavrecord plugin |
| 22:05:25 | amiconn | As well as an optical->coax s/pdif converter |
| 22:06:49 | | Join al4711 [0] (~al@ursaminor.bursik.net) |
| 22:07:21 | | Quit al4711 (Client Quit) |
| 22:07:50 | | Quit simonrvn (Ping timeout: 240 seconds) |
| 22:07:50 | | Nick simonrvn_ is now known as simonrvn (simon@64.235.201.43) |
| 22:07:52 | | Join al4711 [0] (~al@ursaminor.bursik.net) |
| 22:09:28 | kinky | evilnick_B: took a look at the svn, nothing worth mentioning regarding my case there |
| 22:09:54 | evilnick_B | kinky: What does "wobbering" mean? |
| 22:10:22 | kinky | evilnick_B: the sound-level falls and rises every 1-2 seconds |
| 22:10:50 | kinky | but not on every song, just some of them |
| 22:11:45 | kinky | well, I think I'll stay with this version until weekend and then try the newest one |
| 22:11:53 | evilnick_B | Is it the same songs each time? Or does one song sometimes do it and then sometimes not? |
| 22:12:08 | evilnick_B | Basically, can you rule out there being an error in those music files themselves? |
| 22:12:10 | kinky | evilnick_B: happens on the same songs everytime |
| 22:12:17 | | Quit Nausicaa (Read error: Connection reset by peer) |
| 22:12:27 | kinky | evilnick_B: on the OF, the problem is nonexistant |
| 22:12:39 | kinky | so it should be no file related issue |
| 22:13:05 | gevaerts | Which codec is this? |
| 22:13:06 | kinky | checked the same song on both RB and OF |
| 22:13:10 | evilnick_B | That doesn't matter. If you can find out what the affected files have in common then it'll help a developer to reproduce the issue and hopefully fix it |
| 22:13:37 | gevaerts | And does it happen with different codecs? |
| 22:13:41 | al4711 | Today I wanted to install rockbox on my IPod Classic 6st Generation but the RockboxUtility told me that this device is not supported. I'am willing to help to run rockbox on this device. I have tried to find some hint in the faq where I can start, I hope you can give me a hint. Thanks |
| 22:14:16 | saratoga_ | al4711: check out the NewPort wiki page |
| 22:15:11 | al4711 | thanks |
| 22:16:38 | gevaerts | al4711: possibly for the classic http://www.freemyipod.org/wiki/Main_Page can help, or the people in #freemyipod |
| 22:16:55 | evilnick_B | al4711: A word of warning, unless you have experience in coding/cracking encryption or a vast amount of spare time then it'll be an uphill struggle. |
| 22:17:06 | evilnick_B | Actually, it will be anyway even if you do have those skills |
| 22:17:52 | kinky | evilnick_B: seems like they're all mp3's with variable bitrate, 128kbps (v1) |
| 22:18:23 | al4711 | Sorry, but I'am not sure if I understand you right evilnick_B. Do you mean the 6st Generation is in someway encrypted?! |
| 22:18:55 | saratoga_ | it was, but someone cracked the encryption a year or two ago |
| 22:19:17 | al4711 | Do you think it is possible to replace the current IPod SW with rockbox on this device? |
| 22:19:29 | saratoga_ | yes of course its possible |
| 22:19:30 | al4711 | Ah ok I will google for this issue |
| 22:19:35 | al4711 | ;-) |
| 22:19:38 | evilnick_B | Anything is possible, but it's a very difficult and time-consuming job |
| 22:19:42 | saratoga_ | did you read the wikipage? |
| 22:19:55 | al4711 | I'am started |
| 22:20:08 | saratoga_ | well stop wasting time |
| 22:20:20 | | Join edboyer93 [0] (eboyer93@pool-71-185-65-59.phlapa.fios.verizon.net) |
| 22:20:30 | evilnick_B | kinky: Your best bet would be to post on the forum/bug-tracker and attach a file that doesn't work if at all possible |
| 22:20:56 | saratoga_ | or try one of the files in the sim |
| 22:21:14 | kinky | evilnick_B: will do that tomorrow, need sleep now :o |
| 22:21:15 | al4711 | What do you mean?! |
| 22:21:30 | saratoga_ | what does who mean? |
| 22:21:50 | al4711 | I refer to 'saratoga_: well stop wasting time' |
| 22:23:11 | saratoga_ | stop wasting our time because you haven't bothered to read up on whats involved |
| 22:24:41 | AlexP | somewhat harsh |
| 22:24:53 | al4711 | Ok I have seen that it is a lot more then just write some code ;-( . You need also to dig into the HW. Thanks for the hint to the NewPort page I think I will follow your advise. |
| 22:25:17 | | Quit esperegu (Read error: Connection reset by peer) |
| 22:25:48 | | Part kinky |
| 22:27:17 | saratoga_ | somewhat more direct |
| 22:27:25 | saratoga_ | the less harsh version was less understandable |
| 22:27:33 | saratoga_ | ;) |
| 22:27:35 | al4711 | I'am sure there are some guys from time to time to want to port rockbox and after reading what does this means the knowledge or the time consuming the most guys quickly rethink about this idea |
| 22:27:44 | al4711 | now I'am one of this guys ;-) |
| 22:27:52 | saratoga_ | yeah someone does this every day or two |
| 22:28:15 | al4711 | I will try to find a device on which rockbox works stable. |
| 22:29:25 | al4711 | maybe there should be a new faq entry 'how can I port rockbox to my device' or something similar |
| 22:29:38 | AlexP | There is, it is the NewPort wiki page |
| 22:30:05 | al4711 | I have overread this point in the FAQ sorry |
| 22:38:10 | CIA-81 | New commit by wodz (r28185): fix bitmap scallers smooth_resize_bitmap() and simple_resize_bitmap() to properly handle LCD_STRIDEFORMAT == VERTICAL_STRIDE case |
| 22:38:18 | CIA-81 | New commit by wodz (r28186): imageviewer bmp - drop special case for grey bitmap scaller |
| 22:39:51 | CIA-81 | r28185 build result: All green |
| 22:40:17 | al4711 | thanks for the talk and rockbox. good luck. by aleks |
| 22:41:37 | CIA-81 | r28186 build result: 51 errors, 0 warnings (wodz committed) |
| 22:41:48 | wodz | grrr |
| 22:44:37 | pixelma | all monochrome targets |
| 22:44:52 | | Quit al4711 (Quit: Bye all ;-)) |
| 22:45:01 | pixelma | Maggux: I believe there are 99 or 100 levels in bubbles |
| 22:45:49 | wodz | hmm but grep -rn _simple_resize_bitmap * gives me no hits |
| 22:47:04 | | Join insp_ [0] (~chatzilla@customer-217.241.livas.lv) |
| 22:47:15 | pixelma | http://build.rockbox.org/shownewlog.cgi?rev=28186;type=mrobe100sim#prob1 says "apps/plugins/imageviewer/bmp/bmp.c:285: undefined reference to `simple_resize_bitmap'" without the _ |
| 22:47:28 | | Quit Jaykay (Quit: ChatZilla 0.9.86 [Firefox 4.0b6/20100914073604]) |
| 22:48:32 | wodz | http://build.rockbox.org/shownewlog.cgi?rev=28186;type=archosfmrecorder has _ |
| 22:51:32 | pixelma | interesting |
| 22:51:37 | wodz | hmm I don't understand this error |
| 22:52:16 | Torne | isn't the leading _ just part of the C ABI on some platforms? |
| 22:53:04 | Torne | or in fact in the spec :) |
| 22:54:52 | gevaerts | simple_resize_bitmap() seems to be within #if LCD_DEPTH > 1 |
| 22:55:40 | | Quit crow (Remote host closed the connection) |
| 22:56:09 | gevaerts | wodz: moving that #endif up a bit makes things link |
| 22:58:29 | gevaerts | It probably should still be tested then of course |
| 22:59:30 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 22:59:33 | | Quit evilnick_B (Quit: Page closed) |
| 23:00 |
| 23:00:04 | wodz | but look at http://svn.rockbox.org/viewvc.cgi/trunk/apps/plugins/lib/pluginlib_bmp.c?r1=25843&r2=28185 |
| 23:00:21 | wodz | I don't change #if #endif order |
| 23:03:42 | wodz | now I understand |
| 23:03:57 | gevaerts | You removed grey_resize_bitmap, so things now use simple_resize_bitmap |
| 23:04:42 | wodz | yes but I changed simple_resize_bitmap to work in that case. I missed that it won't be compiled at all on monochrome |
| 23:05:22 | gevaerts | yes |
| 23:05:36 | | Quit stripwax (Ping timeout: 245 seconds) |
| 23:06:27 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 23:06:57 | Jerom | are the strncat and strncpy functions not implemented because you guys don't care about buffer overflow or you are doing it some other way ? |
| 23:07:01 | | Quit GibbaTheHutt (Ping timeout: 276 seconds) |
| 23:07:47 | gevaerts | It was felt that strlcat and strlcpy offer better semantics |
| 23:08:17 | gevaerts | The difference may be subtle, but the l variants are often what people meant anyway |
| 23:08:51 | gevaerts | If you want the n semantics, use memcpy |
| 23:09:05 | CIA-81 | New commit by wodz (r28187): fix red ... |
| 23:10:15 | Jerom | didn't know these functions exist, thanks. I feel like an idiot now :p |
| 23:10:38 | gevaerts | They're not universally available |
| 23:10:42 | CIA-81 | r28187 build result: All green |
| 23:11:26 | gevaerts | So people don't always know about them |
| 23:12:06 | | Join GibbaTheHutt [0] (~moo@78-105-152-175.zone3.bethere.co.uk) |
| 23:13:57 | | Quit stripwax (Ping timeout: 265 seconds) |
| 23:17:29 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 23:25:38 | | Join clone4crw [0] (~calvin@97-86-227-168.dhcp.roch.mn.charter.com) |
| 23:32:28 | | Quit Maggux (Remote host closed the connection) |
| 23:32:52 | | Quit Buschel (Quit: ChatZilla 0.9.86 [Firefox 3.6.10/20100914125854]) |
| 23:33:43 | | Quit panni_ (Read error: Connection reset by peer) |
| 23:33:49 | saratoga_ | did sandisk ever contact anyone about a Fuze+? |
| 23:34:04 | | Join panni_ [0] (hannes@ip-178-203-81-220.unitymediagroup.de) |
| 23:43:57 | | Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) |
| 23:48:00 | | Quit jgarvey (Quit: Leaving) |
| 23:48:24 | | Quit domonoky (Read error: Connection reset by peer) |
| 23:53:10 | *** | Saving seen data "./dancer.seen" |
| 23:56:45 | | Quit bertrik (Quit: sleeo) |
| 23:57:57 | | Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) |
icon identifies that the person is a core developer (has commit access).