| 00:02:59 | | Quit animatorgeek ("CGI:IRC") |
| 00:08:01 | | Quit intrados (Read error: 54 (Connection reset by peer)) |
| 00:10:06 | rodan | i am looking on the front page but i do not see that anywhere |
| 00:10:15 | | Join intrados [0] (n=intrados@cpe-71-67-129-220.woh.res.rr.com) |
| 00:12:36 | saratogahome | rodan: "Status for current and work-in-progress targets" |
| 00:15:59 | | Quit saratoga ("http://www.mibbit.com ajax IRC Client") |
| 00:18:15 | | Quit flydutch ("/* empty */") |
| 00:18:54 | | Quit saratogahome ("CGI:IRC (EOF)") |
| 00:19:37 | | Quit Z-mann ("CGI:IRC") |
| 00:24:25 | | Quit bluebrother ("leaving") |
| 00:25:28 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
| 00:28:20 | | Quit killan ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") |
| 00:31:48 | | Join killan [0] (n=nnscript@c-def370d5.06-397-67626721.cust.bredbandsbolaget.se) |
| 00:33:33 | | Join perfectdrug [0] (n=marko@p5B0EC49F.dip.t-dialin.net) |
| 00:37:09 | | Quit intrados (Read error: 104 (Connection reset by peer)) |
| 00:38:15 | | Join intrados [0] (n=intrados@cpe-71-67-129-220.woh.res.rr.com) |
| 00:40:40 | | Quit kugel (Nick collision from services.) |
| 00:40:48 | | Join kugel [0] (n=kugel@e178119196.adsl.alicedsl.de) |
| 00:41:00 | *** | Saving seen data "./dancer.seen" |
| 00:43:09 | | Quit petur ("Zzzz") |
| 00:44:58 | | Join funman [0] (n=fun@rockbox/developer/funman) |
| 00:45:34 | funman | Bagder / kugel (about tmp variable) this is something with memory setup, someone told me why but i don't remember |
| 00:47:04 | funman | we have to read (or write?) to a specific memory location to set some memory address columns bits |
| 00:50:22 | funman | this C code assembles into the shortest way to read, and i don't think it's disgusting. we also could use inline asm for the same effect |
| 00:52:18 | obo | Does it sound feasible for the PP6100 to have more than 12 GPIOs? I think it may have 16... |
| 00:52:58 | gevaerts | funman: I think inline asm would be better |
| 00:54:09 | funman | gevaerts: what's wrong with using (void) to avoid a warning of gcc ? |
| 00:54:20 | funman | obo: i think there is no limit .. :) |
| 00:54:32 | * | perfectdrug puts up FS #10329 SVG for the Philips GoGear HDD1620 |
| 00:55:28 | gevaerts | funman: in this case, nothing. I'm more worried about compilers suddenly starting to opimise this, and I also think an asm read is a bit more clear for this |
| 00:56:19 | gevaerts | it is volatile, but you never know... |
| 00:57:03 | | Quit srnt (Read error: 110 (Connection timed out)) |
| 00:58:27 | funman | if it's volatile we know |
| 00:58:39 | gevaerts | compilers have bugs :) |
| 00:58:41 | gevaerts | I don't think it's a big issue though |
| 00:59:19 | funman | I found a thread about this setting on http://www.embeddedrelated.com/groups/lpc2000/show/38294.php , and they seem to use the exact same code. Still didn't find the exact explanation of how it modifies SDRAM settings |
| 01:00 |
| 01:03:20 | funman | I love how using specific keywords on google always shows 10 or 20 pages, where half of them links to rockbox wiki/irc logs |
| 01:03:46 | gevaerts | Maybe the comment could be extended a bit. Saying that this is used to setup some DRAM controller things in an unknown way would still be better than what's there now |
| 01:03:52 | funman | gevaerts: i don't think it is a big issue also, but i want to fix the comment |
| 01:04:21 | funman | well i'd like to remove the unknown-ness as wel in one shot :) |
| 01:04:31 | gevaerts | indeed, why not? :) |
| 01:05:09 | gevaerts | While you're at it, maybe change the comment at (void)tmp; a bit as well, it looks a bit like it says that this particular line reads a value, which it doesn't |
| 01:05:49 | funman | this read 'programs the MODE register' |
| 01:06:14 | Mikachu | (void)*tmp; would do something, just (void)tmp; would at most read some random location in ram where gcc decided to put your variable |
| 01:06:53 | gevaerts | Mikachu: indeed, but that's not important here |
| 01:07:11 | gevaerts | The line is only there to tell gcc not to say that tmp is unused |
| 01:07:26 | gevaerts | It's the line above that that actually does the magic |
| 01:07:50 | | Quit matsl (Read error: 110 (Connection timed out)) |
| 01:11:09 | | Join hillshum [0] (n=quassel@unaffiliated/hillshum) |
| 01:11:13 | Mikachu | why not just (void)*(volatile unsigned int*)(0x3000000+0x2300*MEM); ? |
| 01:12:10 | funman | that also works |
| 01:12:55 | funman | i don't know how to load from a specific address in gcc asm() |
| 01:13:16 | funman | /tmp/ccwCQ8E4.s:352: Error: bad expression −− `ldr r4,=#805324288' |
| 01:13:20 | | Quit merbanan (Read error: 60 (Operation timed out)) |
| 01:13:32 | gevaerts | I think just leaving it as it is right now is OK, as long as the comments are a bit better |
| 01:13:43 | funman | there is an extra '#' |
| 01:14:29 | funman | see http://en.wikipedia.org/wiki/SDRAM#SDRAM_mode_register |
| 01:19:09 | funman | now i just need to find how M[9:0] / A[9:0] are mapped to the physical memory address |
| 01:21:18 | gevaerts | where is MEM defined? |
| 01:22:16 | | Quit Xerion (" ") |
| 01:22:33 | | Quit amiconn (Nick collision from services.) |
| 01:22:35 | | Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) |
| 01:22:44 | | Quit pixelma (Nick collision from services.) |
| 01:22:44 | | Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) |
| 01:22:57 | | Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) |
| 01:23:02 | | Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) |
| 01:23:19 | funman | apps/{codecs,plugins}.h , not sure where else .. |
| 01:23:58 | funman | ./tools/root.make:DEFINES = -DROCKBOX -DMEMORYSIZE=$(MEMORYSIZE) -DMEM=$(MEMORYSIZE) $(TARGET) \ |
| 01:24:04 | gevaerts | ah ok |
| 01:24:10 | | Join barrywardell [0] (n=barrywar@12.189.97.66) |
| 01:24:20 | funman | we should use MEMORYSIZE anyway ;) |
| 01:25:57 | * | gevaerts can't say he understands this already |
| 01:26:28 | funman | what? |
| 01:26:43 | gevaerts | the 0x2300*MEM bit |
| 01:27:07 | funman | it comes from reverse engineering |
| 01:29:36 | funman | perhaps 8MB and 2MB models use different settings, or they use the same settings but the column bits are not at the same position (row length=12, col length=8 for 8MB; row length=11, col length=8 for 2MB) |
| 01:29:58 | | Join vmx [0] (n=vmx@dslb-084-056-058-227.pools.arcor-ip.net) |
| 01:30:45 | gevaerts | it must be something like that, yes |
| 01:31:18 | vmx | hi. i've a sansa c240. i've transfered a whole folder, but only a few songs show up in the database. i tried several time to initialize/update th database, without any luck. is this a known problem? |
| 01:31:37 | vmx | these are ogg files btw |
| 01:32:59 | funman | this info comes from the pl172 datasheet, however the row length differ from 1 bit, but the setting is shifted 2 bits left (2MB or 8MB =(1<<2) * 2MB) |
| 01:33:13 | vmx | and i'm on latest trunk (about 1h ago) |
| 01:33:39 | Mikachu | vmx: do the files play if you go directly in to the dir with the files and play them? |
| 01:34:45 | | Quit ender` (" "There is no reason anyone would want a computer in their home." -- Ken Olson, president, chairman and founder of DEC") |
| 01:38:09 | vmx | Mikachu: no they it skips to the files that are also in the db. thanks for the hint |
| 01:38:52 | funman | try to play them on the computer and give a sample if they do |
| 01:39:43 | Mikachu | maybe they're ogg with something other than vorbis? (long shot) |
| 01:40:08 | vmx | i've ripped a cd with sound-juicer. and 4 out of 15 files work |
| 01:40:30 | vmx | the files that work a quite short, <1:30min |
| 01:42:22 | | Quit gevaerts (Nick collision from services.) |
| 01:42:31 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
| 01:42:43 | vmx | output from "file" is: Ogg data, Vorbis audio, stereo, 44100 Hz, ~160000 bps, created by: Xiph.Org libVorbis I |
| 01:43:00 | funman | for a working file ? |
| 01:43:36 | vmx | both |
| 01:44:05 | funman | try to play them on the computer |
| 01:44:42 | gevaerts | from the mounted sansa... |
| 01:44:43 | vmx | they work on my computer (i use quodlibet) |
| 01:44:48 | vmx | k |
| 01:45:08 | Mikachu | compare md5sum for the copies on the computer and the sansa |
| 01:45:09 | gevaerts | maybe something went wrong during copying |
| 01:45:16 | gevaerts | good idea |
| 01:50:03 | vmx | Mikachu: *g* i had the same idea. they have different md5sums (but same file size. i'll try to copy them again |
| 01:51:38 | gevaerts | hm.. Did you copy them using the rockbox USB code? |
| 01:52:07 | Mikachu | did you umount or just unplug? |
| 01:52:17 | CIA-37 | New commit by funman (r21282): Sansa AMS: add a comment in sdram_init(), and use inline asm to set the SDRAM mode register |
| 01:52:31 | vmx | gevaerts: nope, original fw |
| 01:52:49 | vmx | mikachu: i always unmount unsuccessfully (but i do unmount) |
| 01:52:50 | gevaerts | ok, it's not my fault then :) |
| 01:53:00 | | Quit intrados (Remote closed the connection) |
| 01:53:05 | Mikachu | vmx: what do you mean unsuccessufully? |
| 01:53:19 | vmx | mikachu: warnings |
| 01:53:25 | vmx | from dbus (i guess) |
| 01:53:28 | Mikachu | like what? |
| 01:55:18 | vmx | it worked now. sorry for the trouble guys. thanks gevaerts and mikachu |
| 01:55:38 | gevaerts | no problem. Have fun! |
| 01:55:56 | Mikachu | i would look into those umount problems |
| 01:56:29 | vmx | i always got the (also with my previously used e280) |
| 01:56:42 | Mikachu | at least run 'sync' before you unplug then |
| 01:57:50 | vmx | the error message is: "Writing data to device. There is data that needs to be wrotten to the device "Sansa c240" before it can be removed... |
| 01:58:11 | funman | doesn't look like an error message, more like an invitation to wait before unplugging the device |
| 01:58:17 | vmx | and if i try to eject it again, i get "not mounted" |
| 01:58:25 | vmx | hm, it's red :) |
| 01:59:04 | funman | ubuntu 9.04 gives me this message, but as a progress window which will disappear once data has been written |
| 01:59:43 | vmx | k, cool |
| 01:59:51 | Mikachu | speaking of umounting, does anyone know where the code 'rockbox.ipod changed, do you want to reboot?' code is? |
| 01:59:55 | Mikachu | s/code// |
| 02:00 |
| 02:01:09 | | Join Lss [0] (n=Lss@cm162.delta96.maxonline.com.sg) |
| 02:01:27 | | Quit perfectdrug () |
| 02:02:42 | | Quit funman ("leaving") |
| 02:03:36 | | Join intrados [0] (n=intrados@cpe-71-67-129-220.woh.res.rr.com) |
| 02:12:55 | vmx | when i plug in my sansa c240, it automatically starts the original firmware. i remember that i read somwhere that it has to do with the booloader, but i can't find this information anymore |
| 02:13:38 | | Quit barrywardell () |
| 02:14:37 | Sajber^ | lol |
| 02:16:07 | Unhelpful | vmx: there is a test bootloader on flyspray that you can install, which will not boot tho OF on USB insert. |
| 02:17:42 | kugel | hm, HID disabled for the release? |
| 02:19:01 | kugel | the Fixed bugs list in ReleaseNotes33 looks a bit poor still :( |
| 02:23:47 | hillshum | How can I search closed flysprat tasks? |
| 02:24:30 | kugel | use advanced search options |
| 02:30:19 | Mikachu | the release notes say "USB enabled on most remaining devices (PP5020, PP5022, and PP5024 targets).", but it doesn't link to some good page that says what targets use those chips |
| 02:30:42 | hillshum | Mikachu: like to add it yourself? |
| 02:30:50 | Mikachu | oh tricky, there was a link in the headline on the page linked to by the word USB |
| 02:32:16 | vmx | Unhelpful: thanks. though the new bootloader still reboots when i plug it in |
| 02:32:26 | | Join DarkSpectrum [0] (n=ZX@99.23.115.136) |
| 02:32:44 | hillshum | When listing the FS# fixed, should I link to that FS#? |
| 02:36:05 | Unhelpful | vmx: you installed the one from here? http://www.rockbox.org/tracker/task/9955 |
| 02:36:33 | vmx | Unhelpful: yes |
| 02:36:43 | Unhelpful | what command, exactly, did you use? |
| 02:39:45 | vmx | ./sansapatcher -a bootloaders-3.3-test/c200/firmware.mi4 |
| 02:40:25 | vmx | it was flashed, it just rebooted everytime into rockbox, recoginzed that it is plugged in and rebooted again |
| 02:41:02 | *** | Saving seen data "./dancer.seen" |
| 02:41:26 | | Quit alexbobp (Read error: 60 (Operation timed out)) |
| 02:45:19 | | Join alexbobp [0] (n=alex@ppp-70-253-78-64.dsl.austtx.swbell.net) |
| 02:49:22 | Unhelpful | weird, it worked fine on my e200 |
| 02:49:58 | * | robin0800 in ubuntu 9.10 alpha 2 the usb bug appears to be fixed |
| 02:53:21 | | Quit kugel (Read error: 110 (Connection timed out)) |
| 03:00 |
| 03:05:19 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 03:06:19 | | Quit bertrik (Read error: 113 (No route to host)) |
| 03:07:03 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
| 03:12:53 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 03:13:00 | | Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-3369a671e60bb184) |
| 03:18:06 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 03:19:19 | CIA-37 | New commit by unhelpful (r21283): Adjust AC decode such that decode *always* stops before storing an unneeded coefficient. Remove extra lines from zag[] as it should not be possible to ... |
| 03:21:50 | | Join shepherd [0] (n=4c148cbf@gateway/web/cgi-irc/labb.contactor.se/x-0a00b3920eacb6ca) |
| 03:22:20 | shepherd | hello? |
| 03:22:48 | | Quit shepherd (Client Quit) |
| 03:24:46 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 03:24:59 | | Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-ea7f683ad8d14e8e) |
| 03:28:49 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 03:29:08 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
| 03:30:57 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 03:31:22 | | Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-d4ebf8c992b47635) |
| 03:52:37 | | Quit krazykit (Read error: 113 (No route to host)) |
| 03:54:14 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 03:54:17 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 03:54:38 | | Quit fdinel (Read error: 104 (Connection reset by peer)) |
| 03:55:05 | | Join krazykit [0] (n=kkit@c-24-218-166-241.hsd1.ma.comcast.net) |
| 04:00 |
| 04:00:31 | | Quit stripwax ("http://miranda-im.org") |
| 04:06:37 | | Join tomers_ [0] (n=chatzill@bzq-84-108-58-176.cablep.bezeqint.net) |
| 04:12:15 | | Quit rodan (Read error: 60 (Operation timed out)) |
| 04:15:12 | | Quit krazykit (Read error: 113 (No route to host)) |
| 04:15:20 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 04:16:59 | | Join krazykit [0] (n=kkit@c-24-218-166-241.hsd1.ma.comcast.net) |
| 04:21:46 | | Quit stripwax ("http://miranda-im.org") |
| 04:25:43 | | Quit tomers (Read error: 110 (Connection timed out)) |
| 04:28:37 | CIA-37 | New commit by unhelpful (r21284): Remove explicit counter for rows/columns in IDCT, instead testing against a pointer calculated in store_row_jpeg. |
| 04:32:38 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 04:39:26 | | Quit stripwax ("http://miranda-im.org") |
| 04:39:34 | | Part BryanJacobs ("Leaving.") |
| 04:40:12 | | Quit vmx ("Leaving") |
| 04:41:03 | *** | Saving seen data "./dancer.seen" |
| 04:42:26 | | Quit froggyman (Read error: 113 (No route to host)) |
| 04:43:29 | | Join kamlurker [0] (n=chatzill@user-142gr2b.cable.mindspring.com) |
| 04:51:07 | kamlurker | Question regarding using Rockbox on newer Sansa products: Does it allow audio playback during fast forward? Sandisk seems to be removing this feature from newer products. Perhaps it's a hardware limitation(?) |
| 04:52:41 | hillshum | kamlurker: Newer as in AMS Sansa? |
| 04:52:47 | hillshum | *Sansas |
| 04:55:35 | kamlurker | Hmm. Not sure what AMS is. I'm thinking the Clip and eXXX series. Maybe they aren't really new but I'm using an m200(?) and those are new to me. |
| 04:57:43 | hillshum | those sansas with an Austria Microsystems prossesor, so Clip, Fuze, c200v2, e200v2, and m200v4 |
| 04:58:44 | kamlurker | Currently using the (ancient) M240 but have played with the Clip and exxx version and found that the audio is muted during fast forward. |
| 04:59:39 | kamlurker | Actually newer versions of the M240 I've purchased have eliminated this feature. |
| 05:00 |
| 05:02:18 | hillshum | I think RB doesn' play music during FF but I'm not sure |
| 05:04:55 | kamlurker | Thanks hillshum. That's too bad if it's true. I really like the feature of being able to FF through commercials and songs I don't like during podcasts, etc. |
| 05:05:09 | hillshum | Same here |
| 05:07:05 | | Quit hillshum (Read error: 104 (Connection reset by peer)) |
| 05:07:56 | Llorean | kamlurker: Well, Rockbox is a community effort, and so far nobody who's wanted it has wanted it badly enough to put forth the effort to make it work. |
| 05:10:51 | Unhelpful | would this be a reasonably easy-to-add option via a setting that turns on timestretch (with user-defined settings) during FF, instead of "really" seeking? |
| 05:12:08 | Llorean | Unhelpful: Depends on how fast time stretch can really cope with. |
| 05:12:24 | kamlurker | Llorean: Understood. I'm glad that Rockbox is has been developed for these devices. Many thanks to all involved. I was just curious about a pet feature that I find very useful. |
| 05:12:56 | | Join froggyman [0] (n=Froggyma@pool-71-186-6-182.chi01.dsl-w.verizon.net) |
| 05:13:53 | Llorean | Unhelpful: Really, it's usually not timestretched (in my experience) in such a feature. It just seeks like normal, and while playing 1/2 second or so of normal audio, then skipping to where the seek is at now, playing another 1/2 second or so, skipping to where the seek is, etc. |
| 05:14:29 | Unhelpful | ugh. that can't be nice with MDCT-based codes (which i believe is nearly all modern lossy ones?) |
| 05:14:34 | Llorean | It's either restricted to very, very slow seeking (by seeking, then playing, then seeking) or very inaccurate (seeking while playing) |
| 05:15:23 | | Quit efyx (Remote closed the connection) |
| 05:15:28 | Unhelpful | surely TDAC goes away if you lap the ends of an MDCT block with the wrong block :/ |
| 05:19:11 | Llorean | I do agree it'd help especially accessibility quite a bit, since they don't have the option to just watch the OSD to know how far forward they've gone. |
| 05:19:58 | Unhelpful | i'd be curious to see how it works out with timestretch... surely this is an option at least on beast. |
| 05:20:43 | Llorean | It'd be interesting to uncap timetstretch and see how recognizable things are at whatever the maximum speed various players can keep up with it at. |
| 05:23:49 | Unhelpful | Llorean: surely that depends on the codec... timestretch speedup with monkey's on high would challenge even the beast. ;) |
| 05:24:22 | Llorean | Well yeah, but everything tends to be calibrated around MP3 and WAV anyway. |
| 05:24:42 | Llorean | "pitch" used to go up to 200% and I doubt Monkey's ever saw that :-P |
| 05:30:26 | | Join dmb [0] (n=dmb@unaffiliated/dmb) |
| 05:45:01 | * | Llorean sees a relatively serious bug report |
| 05:45:12 | | Quit DarkSpectrum (Remote closed the connection) |
| 05:47:23 | * | Llorean would hate for 3.3 to go out with a broken mpegplayer |
| 05:47:36 | | Quit HBK (Read error: 104 (Connection reset by peer)) |
| 05:47:48 | | Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
| 05:51:48 | Llorean | Oh, nevermind. It's broken but shouldn't be in 3.3 I think |
| 05:55:19 | | Join Riku [0] (n=Lss@cm162.delta96.maxonline.com.sg) |
| 05:55:54 | | Join KBH [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
| 05:59:52 | | Quit HBK (Read error: 60 (Operation timed out)) |
| 06:00 |
| 06:02:22 | | Join tonsofpcs [0] (n=tonsofpc@cpe-74-67-71-228.stny.res.rr.com) |
| 06:03:01 | | Part tonsofpcs |
| 06:03:37 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 06:07:06 | | Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
| 06:11:18 | | Quit KBH (Read error: 60 (Operation timed out)) |
| 06:14:07 | | Quit Lss (Read error: 110 (Connection timed out)) |
| 06:20:28 | | Join webguest10 [0] (n=47b8f4e7@gateway/web/cgi-irc/labb.contactor.se/x-14bf9a63808ab574) |
| 06:22:36 | | Quit webguest10 (Client Quit) |
| 06:26:20 | | Quit froggyman (" HydraIRC -> http://www.hydrairc.com <- Chicks dig it") |
| 06:41:08 | *** | Saving seen data "./dancer.seen" |
| 06:44:26 | | Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-2fa212361290a0b3) |
| 07:00 |
| 07:01:17 | | Part toffe82 |
| 07:14:09 | | Quit HBK () |
| 07:18:58 | | Join JdGordon [0] (n=Miranda@c-67-160-44-90.hsd1.wa.comcast.net) |
| 07:39:44 | | Join daurn [0] (n=daurnima@unaffiliated/daurnimator) |
| 07:40:57 | | Join Horscht86 [0] (n=Horscht2@p4FD4E4A6.dip.t-dialin.net) |
| 07:47:06 | | Quit tomers_ (Remote closed the connection) |
| 07:55:18 | | Quit martian67 (Read error: 104 (Connection reset by peer)) |
| 07:56:50 | | Join martian67 [0] (n=martian6@about/linux/regular/martian67) |
| 07:56:50 | | Quit daurnimator (Remote closed the connection) |
| 07:59:00 | | Quit Horschti (Read error: 110 (Connection timed out)) |
| 08:00 |
| 08:00:44 | | Quit robin0800 (Remote closed the connection) |
| 08:15:38 | | Join Rob2222 [0] (n=Miranda@p4FDCD9F6.dip.t-dialin.net) |
| 08:19:13 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 08:19:29 | | Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-d386246dd24eb556) |
| 08:25:18 | | Quit kamlurker ("ChatZilla 0.9.84 [Firefox 3.0.11/2009060310]") |
| 08:33:15 | | Quit Rob2223 (Read error: 110 (Connection timed out)) |
| 08:41:12 | *** | Saving seen data "./dancer.seen" |
| 08:42:18 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 08:42:48 | | Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-4aea5c0a1453e298) |
| 09:00 |
| 09:44:35 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 09:44:45 | | Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-b9e2a814e5a21c59) |
| 09:48:01 | | Join einhirn [0] (n=Miranda@p4FC636A0.dip0.t-ipconnect.de) |
| 09:55:09 | | Join advcomp2019_ [0] (n=advcomp2@unaffiliated/advcomp2019) |
| 09:55:47 | | Quit einhirn (Read error: 104 (Connection reset by peer)) |
| 09:59:25 | | Join flydutch [0] (n=flydutch@host46-210-dynamic.15-87-r.retail.telecomitalia.it) |
| 10:00 |
| 10:13:28 | | Quit advcomp2019 (Read error: 110 (Connection timed out)) |
| 10:27:57 | | Quit flydutch ("/* empty */") |
| 10:34:03 | | Join petur [50] (n=petur@rockbox/developer/petur) |
| 10:41:14 | *** | Saving seen data "./dancer.seen" |
| 10:42:37 | | Join flydutch [0] (n=flydutch@host46-210-dynamic.15-87-r.retail.telecomitalia.it) |
| 11:00 |
| 11:01:25 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
| 11:04:58 | | Join tessarakt2 [0] (n=jens@e180076026.adsl.alicedsl.de) |
| 11:07:44 | | Join shodanX [0] (n=shodanX@jazz.informatik.uni-erlangen.de) |
| 11:08:21 | CIA-37 | New commit by peter (r21285): Update Dutch langfile |
| 11:17:07 | linuxstb | petur: Why were you asking about my BBS2? Are you looking for something similar? (I need a second, similar box...) |
| 11:17:19 | * | linuxstb switches to the right channel... |
| 11:21:04 | | Quit tessarakt (Read error: 110 (Connection timed out)) |
| 11:23:09 | | Quit ender` (Read error: 104 (Connection reset by peer)) |
| 11:25:42 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
| 11:39:55 | | Quit petur ("later") |
| 11:42:15 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 11:50:45 | | Quit jordan` (Read error: 54 (Connection reset by peer)) |
| 11:52:26 | | Join jordan` [0] (i=gromit@78.235.252.137) |
| 11:53:17 | | Quit jordan` (Read error: 104 (Connection reset by peer)) |
| 12:00 |
| 12:17:33 | | Quit Horscht86 ("Verlassend") |
| 12:27:07 | | Join Horscht [0] (n=Horscht2@xbmc/user/horscht) |
| 12:32:54 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 12:41:19 | *** | Saving seen data "./dancer.seen" |
| 12:43:32 | | Quit tessarakt2 ("Client exiting") |
| 12:43:39 | | Join tessarakt [0] (n=jens@e180076026.adsl.alicedsl.de) |
| 12:43:41 | | Quit tessarakt (Read error: 104 (Connection reset by peer)) |
| 12:46:49 | | Join merbanan [0] (n=banan@c-83-233-243-100.cust.bredband2.com) |
| 13:00 |
| 13:04:34 | | Quit merbanan ("Leaving") |
| 13:06:23 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
| 13:06:41 | | Join Rondom [0] (n=Rondom@dslb-084-057-167-190.pools.arcor-ip.net) |
| 13:11:19 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 13:46:12 | | Join tessarakt [0] (n=jens@e180076026.adsl.alicedsl.de) |
| 13:47:55 | | Quit Rondom ("Ex-Chat") |
| 13:50:44 | | Join TheSphinX^ [0] (n=cold@p54A5D8B3.dip.t-dialin.net) |
| 13:53:28 | | Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) |
| 13:54:33 | | Quit Nico_P (Remote closed the connection) |
| 13:54:44 | | Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) |
| 14:00 |
| 14:05:08 | | Quit stripwax ("http://miranda-im.org") |
| 14:05:46 | | Quit matsl (Remote closed the connection) |
| 14:13:32 | bertrik | we have some redundant redeclarations of printf-like functions in both sprintf.h and stdio.h |
| 14:16:45 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 14:39:37 | | Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) |
| 14:41:20 | *** | Saving seen data "./dancer.seen" |
| 14:53:09 | | Quit bertrik (Read error: 110 (Connection timed out)) |
| 14:56:43 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 15:00 |
| 15:11:08 | | Join efyx [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) |
| 15:13:48 | | Join funman [0] (n=fun@rockbox/developer/funman) |
| 15:33:00 | | Join nibbler_ [0] (n=Nibbler@82.113.121.121) |
| 15:33:34 | funman | going into settings>general>system>limits and setting both values to the max, my Clip has -561600 bytes of audio buffer |
| 15:34:07 | gevaerts | nice :) |
| 15:34:58 | | Quit BlakeJohnson861 (Read error: 110 (Connection timed out)) |
| 15:35:03 | funman | it seems those settings also require a reboot to be effective |
| 15:35:31 | | Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 15:39:25 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 15:40:10 | funman | how hard would it be to render the screendumps realsize in the clip manual ? |
| 15:44:27 | bertrik | realsize? you mean with the two colors and the separation bar between cyan and yellow? |
| 15:45:06 | funman | no it's already 'real-color', but i would like to avoid resizing to get good graphics |
| 15:45:59 | linuxstb | Are you talking about the PDF, or HTML (or both)? |
| 15:50:51 | linuxstb | funman: The images in the PDF look fine to me. Some zoom levels are better than others, but that's inevitable. |
| 15:53:16 | | Join kugel [0] (i=kugel@rockbox/developer/kugel) |
| 15:55:43 | funman | they are bit blurred in the pdf |
| 15:55:47 | | Quit nibbler_ (Read error: 110 (Connection timed out)) |
| 15:57:39 | | Quit funman (Read error: 60 (Operation timed out)) |
| 15:57:40 | | Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
| 15:57:55 | | Join funman [0] (n=fun@rockbox/developer/funman) |
| 15:58:22 | funman | but the html look fine (not zoomed) |
| 15:59:33 | Unhelpful | funman: and what zoom level are you using to view the pdf? |
| 15:59:35 | linuxstb | funman: At what zoom level? It depends what DPI the PDF is rendered at... |
| 16:00 |
| 16:01:07 | | Join nibbler_ [0] (n=Nibbler@82.113.121.113) |
| 16:06:14 | | Quit mcuelenaere (Read error: 110 (Connection timed out)) |
| 16:06:17 | funman | Unhelpful: 100% |
| 16:06:45 | Unhelpful | and the images are being scaled at 100%? that sounds odd... |
| 16:07:10 | funman | in platform/clip.tex : \newcommand{\screenshotsize}{3cm} |
| 16:07:26 | funman | i think this where the zoom level is set |
| 16:10:49 | linuxstb | Does that actually mean anything though? It depends what DPI your PDF viewer is considering "100%". |
| 16:11:15 | Unhelpful | which probably depends on the DPI of your display... |
| 16:11:18 | funman | in fact the image is scaled down if i compare it to the png |
| 16:11:37 | funman | hum .. i'm not sure. is pdf vector based or something ? |
| 16:12:19 | linuxstb | Yes. But obviously not the bitmaps... |
| 16:13:57 | | Quit HBK () |
| 16:14:53 | kugel | is the manual downloadable somwhere? |
| 16:15:32 | funman | kugel: i'm not sure, i have installed some latex packages to build it |
| 16:16:03 | kugel | we should probably start putting a few online (the beast's is online for a while too) |
| 16:17:13 | funman | at 100%, the manual is 24.7cm wide, on my 30.4cm, 1024pixels wide monitor |
| 16:17:20 | | Quit stripwax ("http://miranda-im.org") |
| 16:17:36 | kugel | the pics in the beats manual are scaled too here |
| 16:17:59 | funman | so the pdf is rendered with approximately 832 pixels width |
| 16:19:20 | funman | if dots are pixels, and i can calculate how much centimeters are in an inch, I can find the exact DPI, but then how is it useful ? o: |
| 16:19:21 | kugel | I'm on windows 7, so I can't choose DPI anymore, just 100%, 125% and 150% |
| 16:19:56 | funman | I'd like that the zoom was only made by pdf renderer, not by the pdf creator |
| 16:19:57 | kugel | oh wait, I found where I can set it (it's at 96) |
| 16:21:56 | Unhelpful | funman: the zoom is selected by the pdf renderer, but pdf specifies dimensions in real-world units, not pixels. there isn't much that we can do about this. |
| 16:23:40 | funman | i think the rendering hint is A4 (21x29.7cm) so perhaps we can do something here |
| 16:23:46 | kugel | in adobe, if I zoom to ~91%, the images are almost unscaled |
| 16:24:02 | funman | hum but we don't know on how much pixels this will be rendered :( |
| 16:25:22 | kugel | I too think it has something to do with the DPI. |
| 16:26:16 | | Quit tvelocity (Remote closed the connection) |
| 16:26:16 | kugel | Unhelpful: if the pdf creator targets for DIN A4, it also must target a DPI for which this DIN A4 applies, doesn't it? |
| 16:27:39 | Unhelpful | kugel: paper sizes don't have a DPI. monitors do. the bitmap does because it is a raster image and we are specifying a display size in real-world units. i don't think there is a way around this. |
| 16:28:20 | linuxstb | Perform screendumps as vector images... |
| 16:28:23 | kugel | I apparently have my monitor DPI set to "Standard", so it seems wrong that images are scaled at this setting |
| 16:29:48 | Unhelpful | kugel: the DPI of your display is a property of its physical size and its resolution. windows may call that "standard" but it is not standard across displays - mine is 115dpi, others will be something else. |
| 16:34:14 | Unhelpful | you can't make this work for everybody, not in PDF. it is a format for physical documents, and you won't get the images to be sized in monitor pixels without assuming a specific monitor DPI, which will be wrong for many users. |
| 16:38:30 | kugel | gevaerts: the samsung bootloader can do 15MB/s, Rockbox only 5MB/s (Samsung YH-925). Any chance the ata/dma patch helps? |
| 16:39:09 | gevaerts | kugel: it won't bring you to 15MB/s, but it should help, yes |
| 16:39:41 | | Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) |
| 16:41:23 | *** | Saving seen data "./dancer.seen" |
| 16:42:30 | * | kugel goes trying |
| 16:48:37 | | Quit funman ("leaving") |
| 16:50:46 | kugel | gevaerts: it seems worse! |
| 16:51:07 | kugel | only 3.8MB/s |
| 16:51:21 | gevaerts | kugel: bootloader? |
| 16:51:31 | kugel | rockbox |
| 16:51:36 | gevaerts | ok |
| 16:51:44 | kugel | I defined HAVE_ATA_DMA |
| 16:51:48 | gevaerts | change firmware/target/arm/ata-target.h |
| 16:52:01 | gevaerts | to have #define ATA_MAX_UDMA 4 |
| 16:52:32 | gevaerts | from what I understand, the patch now boosts as needed so 4 is always safe |
| 16:53:15 | | Join n00b81 [0] (n=taylor@c-24-91-82-205.hsd1.ma.comcast.net) |
| 16:55:12 | | Part n00b81 ("Leaving") |
| 16:55:30 | kugel | gevaerts: doesn't seem faster |
| 16:55:47 | gevaerts | what does test_disk say about speed? |
| 16:56:03 | kugel | hm, I don't have test_disk (no plugins yet) |
| 16:57:08 | * | gevaerts thinks that kugel doesn't have his priorities right then ;) |
| 16:57:45 | gevaerts | Anyway, as long as you have to just guess whether this is a USB speed problem or a disk speed problem, I don't think you can do much |
| 16:58:37 | linuxstb | Isn't there a ramdisk driver to test that? |
| 16:59:16 | kugel | let me hack SOURCES and SUBDIRS, I think I can manage to build test* only |
| 17:00 |
| 17:00:26 | gevaerts | yes and no. There is a ramdisk driver, and usb storage has a built-in ramdisk for testing, but both use memcpy() which is actually slower than UDMA4. Also, ramdisk size is (obviously) restricted, so it gets harder to test reliably |
| 17:01:11 | gevaerts | What I have done occasionally is just commenting out the disk accesses in usb_storage.c, but then you can only test with dd, no higher level tests... |
| 17:04:40 | kugel | test disk data aborts :( |
| 17:05:54 | | Quit antil33t () |
| 17:11:02 | | Quit nibbler_ (Read error: 110 (Connection timed out)) |
| 17:17:29 | Llorean | Does anyone here use the track skip beep, or know what its actual purpose is? |
| 17:17:30 | kugel | gevaerts: it runs now |
| 17:18:34 | kugel | read (512,a) 1576KB/s |
| 17:18:45 | kugel | create/write is much faster |
| 17:19:11 | kugel | same numbers for (512,U) |
| 17:19:15 | gevaerts | wait for the 4k aligned ones. That's what USB uses basically |
| 17:19:59 | kugel | 5MB/s create/write, read only 2MB/s :S |
| 17:21:20 | kugel | same for 1M aligned |
| 17:21:37 | gevaerts | ok. That means it's the ATA code and not the USB code that's causing slowness |
| 17:21:53 | | Quit mcuelenaere (Remote closed the connection) |
| 17:22:02 | kugel | ata code is ata-pp5020.c |
| 17:22:16 | gevaerts | if you're trying the dma patch, you can check if it's using dma in the debug menu |
| 17:22:22 | kugel | need to talk with low_light, probably |
| 17:22:22 | | Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) |
| 17:22:49 | gevaerts | yes. I can't really help with this |
| 17:23:49 | kugel | gevaerts: wrting in the verify test seems much faster (18MB/s) |
| 17:24:33 | kugel | also the plugin seems to lie here |
| 17:24:41 | kugel | although* |
| 17:27:43 | gevaerts | Does the verify test print its speed? I don't see that in the code |
| 17:28:06 | kugel | what does the first number mean then? |
| 17:28:25 | kugel | that number doesn't change much, so I thought it's speed |
| 17:28:52 | gevaerts | Which one? Is there a label with it? |
| 17:30:05 | kugel | [Wrt|Cmp] XXXXXXXKB, XXXXXXXKB left |
| 17:30:56 | kugel | maybe it is speed, but not per second :) |
| 17:31:03 | kugel | test passed, at least |
| 17:31:09 | gevaerts | the first one should be the amount already done |
| 17:31:25 | kugel | that wrong then |
| 17:32:02 | kugel | that number would be slightly redundant also |
| 17:32:42 | gevaerts | no, wait.. The size of this particular write operation, which is random, but not higher than what's left to do |
| 17:33:00 | | Join nibbler_ [0] (n=Nibbler@82.113.121.129) |
| 17:33:23 | | Nick J-23 is now known as Jurny (n=zelazko@unix.net.pl) |
| 17:33:30 | | Nick Jurny is now known as Moarc (n=zelazko@unix.net.pl) |
| 17:34:35 | kugel | gevaerts: I'm not sure if we use IRAM or CPU caches right now, might there be a slowness cause? |
| 17:34:50 | | Join barrywardell [0] (n=barrywar@12.189.97.66) |
| 17:35:01 | gevaerts | again, I don't know. I've vener looked at the ata code |
| 17:36:11 | | Quit barrywardell (Read error: 104 (Connection reset by peer)) |
| 17:36:54 | | Join barrywardell [0] (n=barrywar@12.189.97.66) |
| 17:43:06 | | Join animatorgeek [0] (n=4b53ec3e@gateway/web/cgi-irc/labb.contactor.se/x-e5739f4c417d6b60) |
| 17:43:37 | animatorgeek | Does anyone know anything about the recently-added timestretch feature? |
| 17:44:17 | | Quit timc (Read error: 110 (Connection timed out)) |
| 17:45:59 | animatorgeek | Shall I take that as a "no"? |
| 17:46:32 | animatorgeek | Maybe I'm here at a bad time in terms of actually finding people online.... |
| 17:47:09 | Mikachu | be patient |
| 17:47:38 | Mikachu | the guy who committed it, pondlife, isn't here right now though |
| 17:47:42 | Mikachu | but i think he didn't write the code |
| 17:50:16 | animatorgeek | if the irc log from when he committed is an indication, it's probably the code that someone else wrote and submitted last year |
| 17:50:42 | animatorgeek | (that is, the description sounds similar −− best for low bitrate and voice applications) |
| 17:50:56 | Mikachu | i couldn't figure out how to actually use it |
| 17:51:04 | animatorgeek | Yeah, me niether. |
| 17:51:07 | Mikachu | it looked in the code like it did something to the pitch screen but no luck |
| 17:51:16 | Llorean | It also breaks mpegplayer |
| 17:51:23 | animatorgeek | That's why I'm here. I activated it but it didn't change anything. |
| 17:51:23 | * | gevaerts has tested it |
| 17:51:53 | gevaerts | animatorgeek: you need to set the "pitchscreen" (which probably isn't the right name anymore) to the right mode |
| 17:52:02 | animatorgeek | the pitch ui is still exactly the same as before, both visually and functionally. |
| 17:52:11 | kugel | animatorgeek: activate it in the playback settings, reboot, then go to the pitch screen |
| 17:52:25 | animatorgeek | I made the change in the settings and rebooted but there's no change |
| 17:52:33 | kugel | you need to press a key to toggle through the pitchscreen modes |
| 17:52:44 | gevaerts | as documented in the manual ;) |
| 17:52:57 | animatorgeek | Ah, that was it! Thanks! |
| 17:53:33 | animatorgeek | I thought it would change to exclusive stretch mode, not toggle between the modes |
| 17:53:50 | Llorean | If the pitchscreen can be toggled, why does it need an on/off setting too? |
| 17:53:59 | animatorgeek | Sorry, I guess I didn't catch that apsect when I looked at the manual. |
| 17:54:04 | gevaerts | removing a feature? Unthinkable! |
| 17:54:10 | gevaerts | Llorean: it needs memory |
| 17:54:45 | Llorean | gevaerts: Shouldn't that be handled by restarting playback? |
| 17:54:50 | animatorgeek | I'm not clear what the disadvantage is to taking more memory. Does it reduce the ability to load apps or something? Or is it a power thing? |
| 17:55:06 | Mikachu | if less fits in the cache, you need to spin up more often |
| 17:55:14 | Llorean | animatorgeek: Any free memory is used to buffer audio. On hard disk players this can improve battery life. |
| 17:55:37 | animatorgeek | Ah, I see. I did a CFMod, though, so it'll impact me less, right? |
| 17:55:49 | Llorean | animatorgeek: "on hard disk players"... |
| 17:55:57 | Mikachu | :) |
| 17:56:06 | animatorgeek | Right :) |
| 17:56:17 | kugel | animatorgeek: he wanted to say: Yes you're right :) |
| 17:56:22 | animatorgeek | So yeah, I've got stretching working now. Awesome! |
| 17:56:27 | * | Llorean thinks time stretch should possibly be reverted for the moment, though. |
| 17:56:39 | animatorgeek | Why? |
| 17:56:40 | Mikachu | it's not on the 3.3 branch right? |
| 17:56:47 | kugel | correct |
| 17:56:52 | Llorean | Mikachu: Right, but mpegplayer is still a major feature to be broken in SVN |
| 17:57:09 | gevaerts | Llorean: maybe. I'm not sure what the implications of restarting playback for this would be |
| 17:57:11 | Mikachu | is it broken even with the option off? |
| 17:57:14 | Llorean | Yes. |
| 17:57:28 | kugel | we never claimed SVN is working code. We should wait a few days for someone to fix it |
| 17:57:40 | gevaerts | kugel: we try to.. |
| 17:57:45 | Llorean | kugel: Actually, we do claim SVN is usable code, that's why it's in the easy installer and everything |
| 17:57:52 | gevaerts | I agree that we can give it a few more days though |
| 17:58:19 | kugel | Llorean: and the installer says explicitely that a current build is not as stable? |
| 17:58:48 | Mikachu | not stable doesn't usually mean known to be broken |
| 17:59:38 | animatorgeek | So is the timestretching something that it would be appropriate to submit a bug report for? |
| 17:59:58 | Llorean | animatorgeek: For what? |
| 18:00 |
| 18:00:00 | * | gevaerts has no idea what animatorgeek means |
| 18:00:01 | kugel | yep, for mpegplayer we already have a bug report |
| 18:00:15 | Mikachu | "needs more intuitive interface"? :) |
| 18:00:37 | Llorean | But yeah, I think we shouldn't leave mpegplayer broken for more than a day or two |
| 18:00:38 | kugel | Mikachu: That's going to be closed with a RTFM note :) |
| 18:00:39 | animatorgeek | I thought I found a bug, but now I'm not so sure. |
| 18:00:42 | gevaerts | Mikachu: that would be a feature request. We don't do those |
| 18:00:51 | Llorean | Getting a new feature in isn't as important as keeping our existing features working. |
| 18:00:56 | animatorgeek | It looks like I was just misunderstanding the ui. |
| 18:01:32 | Llorean | gevaerts: I wonder if we could get that "Build" dropdown on Flyspray changed to a box where someone is asked to simply type in the revision. |
| 18:01:43 | kugel | Llorean: I'm not saying I like this situation or timestrech is more valuable, but we shouldn't get too nervous about it, particularly not with the upcoming release |
| 18:02:06 | gevaerts | Llorean: that would be useful, yes. Having bugs reported against 3.2 for features that were committed after 3.3 is a bit annoying |
| 18:02:06 | Mikachu | is roloing supposed to not save settings? |
| 18:02:24 | Llorean | gevaerts: Most people still think of everything after 3.2 but before 3.3 as "3.2" |
| 18:02:29 | * | Mikachu enables timestretch twice |
| 18:02:29 | Llorean | It's hard to correct that thought |
| 18:02:40 | kugel | gevaerts: there's a "Current build (Which?)" option selectable |
| 18:02:53 | Llorean | kugel: No, there's a "Daily build (Which?)" option |
| 18:03:16 | kugel | oh, still better than release only though |
| 18:03:24 | kugel | people are just too lazy to check all boxes, this possiblity wouldn't help |
| 18:03:28 | gevaerts | animatorgeek: do you expect you'd have misunderstood it if it weren't necessary to enable the feature in the settings? |
| 18:03:39 | animatorgeek | So yes, I take it back. There _is_ a weirdness in the timestretch ui |
| 18:03:41 | Llorean | kugel: It would if the box had to be filled in before tasks were accepted. |
| 18:03:50 | animatorgeek | No, that's not the issue. |
| 18:03:51 | | Quit fyrestorm (Read error: 104 (Connection reset by peer)) |
| 18:03:53 | Llorean | animatorgeek: It doesn't work how the manual says it does? |
| 18:04:03 | animatorgeek | I'm okay with having to activate it and all that. |
| 18:04:41 | animatorgeek | It works 99%, but the speed display doesn't accurately reflect the speed of playback when pitch gets shifted. |
| 18:05:07 | kugel | huh? |
| 18:05:27 | animatorgeek | The speed display seems to reflect how much the stream needs to be slowed or sped up to compensate for the pitch change |
| 18:05:48 | kugel | that's true |
| 18:06:01 | animatorgeek | Like I set pitch to 110% and speed automatically goes to 90% |
| 18:06:18 | animatorgeek | It's intuitively illogical. |
| 18:06:26 | kugel | you actually have two modes in that screen. changing speed with pitch correction, or without |
| 18:06:30 | | Join fyrestorm [0] (n=nnscript@cpe-24-90-81-178.nyc.res.rr.com) |
| 18:06:39 | kugel | I really recommend you to read the manual |
| 18:07:31 | animatorgeek | Clearly I didn't read the manual thoroughly. I would guess, though, that this is something that should be as intuitive as possible. |
| 18:07:35 | Mikachu | ah, my problem was that my settings weren't saved even on long play shutdown if i did it too soon after changing the setting |
| 18:07:40 | Mikachu | third time it stayed on |
| 18:08:02 | Llorean | Mikachu: What player? |
| 18:08:07 | Mikachu | is the html manual current? (here http://download.rockbox.org/manual/rockbox-ipodnano/rockbox-buildch4.html#x7-380004 ) |
| 18:08:22 | animatorgeek | h120 |
| 18:08:29 | animatorgeek | oops, that wasn't for me, was it? |
| 18:08:32 | Mikachu | the pitch section doesn't mention any keybinds for timestretch mode |
| 18:08:58 | Mikachu | Llorean: ipod nano |
| 18:09:25 | animatorgeek | What I saw when I looked at it yesterday was just one or two sentences mentioning how to activate the ability to use timestretching, but I didn't looke through it thoroughly. |
| 18:10:02 | kugel | Prev/next: [...]or modify speed (in timestretch mode) |
| 18:10:14 | kugel | I agree the description of the pitchscreen keymaping is poor |
| 18:10:22 | | Quit nibbler_ (Read error: 110 (Connection timed out)) |
| 18:10:47 | Mikachu | oh there it is, didn't see it |
| 18:11:16 | animatorgeek | Anyway, I have no problem with how the controls are currently set up. It's just that two numbers are displayed on the tmestretching screen but they seem to have different basic assumptions. |
| 18:11:39 | gevaerts | animatorgeek: the problem with "intuitive" controls is that what's intuitive for one person is horrible and impossible to use for another |
| 18:11:54 | animatorgeek | The "speed" readout accounts for stretching but the "pitch readout doesn't. |
| 18:12:20 | Mikachu | animatorgeek: i think if you increase pitch on the timestretch mode, it will lower the speed so _only_ the pitch is increased |
| 18:12:38 | animatorgeek | gevaerts: that's true. I wish there were a way to focus test this. |
| 18:12:54 | animatorgeek | Mikachu: that's true. I like that it does that. |
| 18:13:12 | kugel | Mikachu: you can also change speed only |
| 18:13:15 | Mikachu | yeah |
| 18:13:58 | animatorgeek | I just would like "pitch" to represent the actual relative pitch, and speed to represent the actual relative speed. |
| 18:14:31 | kugel | that's what's happening |
| 18:14:42 | Mikachu | no |
| 18:14:55 | animatorgeek | So I guess my beef is with how the "speed" readout displays its info. |
| 18:14:56 | kugel | you just can't change pitch without affecting playback speed (not in rockbox, at least) |
| 18:14:56 | Mikachu | when you increase the pitch, it plays at the same speed, but the speed readout says 70% or so |
| 18:15:02 | kugel | hence the timestrech compensates it |
| 18:15:11 | | Join petur [0] (n=peter@d54C6F58E.access.telenet.be) |
| 18:15:27 | Mikachu | you can't look at the interface and tell how fast it's going if you have changed the pitch |
| 18:15:32 | animatorgeek | It should be the relative speed as heard by the user, not the relative speed to the pitch-changed intermediate stream |
| 18:16:37 | animatorgeek | Am I making sense? We're talking about user interface here, which should make sense to the user, not be dictated by idiosyncracies of the archetecture. |
| 18:16:41 | kugel | Mikachu: if the pitch is at 120%, is exactly 20% faster... |
| 18:16:50 | Mikachu | kugel: not if the speed is 80% |
| 18:16:58 | Mikachu | but 120% and 80% don't make 100% |
| 18:16:59 | kugel | of course |
| 18:17:12 | Mikachu | we are saying it would be nice if the speed said what actual speed it was, regardless of pitch |
| 18:17:22 | Llorean | Mikachu: My Nano saved the setting when shutting down immediately after changing it. |
| 18:17:23 | animatorgeek | Mikachu: eactly |
| 18:17:33 | animatorgeek | exactly, that is |
| 18:17:35 | Mikachu | Llorean: maybe i somehow messed up |
| 18:18:03 | kugel | Mikachu: that's not possible becuase pitch also changes playback speed |
| 18:18:14 | animatorgeek | It _is_ possible. |
| 18:18:17 | Mikachu | kugel: of course it's possible, it's quite a simple calculation :) |
| 18:18:34 | animatorgeek | Just multiply the internal speed by the pitch percentage before you display it. |
| 18:18:47 | Mikachu | could be a third readout |
| 18:18:50 | Mikachu | "effective speed" |
| 18:18:52 | Mikachu | or so |
| 18:18:55 | kugel | I see what you want |
| 18:19:19 | kugel | but i think the number it displays is exactly the number we feed the algorithms with |
| 18:19:34 | Llorean | The "speed" is the "effective" speed |
| 18:19:36 | animatorgeek | Yes, it could be a third number, though I don't personally see a use for the speed value as it's currently displayed if we also have actual speed... |
| 18:19:43 | Llorean | The problem is "pitch" doesn't really mean anything |
| 18:19:50 | Llorean | Since the adjusted pitch should always be "100%" |
| 18:19:56 | gevaerts | Mikachu: your nano was also the one where HID didn't work, right? |
| 18:20:16 | animatorgeek | adjusted pitch will only be 100% if you've only changed the speed. |
| 18:20:29 | Mikachu | Llorean: no, if you increase pitch and speed says 80% because it compensated, if speed was the actual speed, it would mean a one minute track played in 50 seconds or so, but it will play in exactly one minute |
| 18:20:32 | * | gevaerts wonders if that nano could benefit from a chkdsk run and possibly a reinstall+new bootloader |
| 18:20:33 | animatorgeek | We're talking about the speed remaining unchanged when we change the pitch |
| 18:20:47 | Mikachu | gevaerts: maybe :) |
| 18:20:51 | Llorean | If you scroll pitch up to 200%, it will compensate the speed down to 50% for you |
| 18:21:02 | Llorean | Which results in a perceived pitch of 100%, while you have a half playback speed |
| 18:21:17 | Mikachu | that is incorrect |
| 18:21:46 | Llorean | That's just what happened when I just did it on my player... |
| 18:21:50 | animatorgeek | But why must the dislayed speed be what's used internally? It would make much more sense to the user if speed was actually what he/she hears |
| 18:22:16 | Llorean | When it says "50%" my elapsed time is moving at half the normal rate... |
| 18:22:21 | Llorean | I'm not sure what the problem is with that? |
| 18:22:37 | animatorgeek | I agree, that's what it _should_ do |
| 18:22:38 | gevaerts | Llorean: you're looking at something else then |
| 18:22:59 | Llorean | gevaerts: I'm in the pitch screen, where it says "Pitch: 200%" and "Speed: 50%" |
| 18:23:09 | Mikachu | Llorean: when i scroll pitch to 200% and speed to 50%, speed moves at normal, but the voices are smurfed |
| 18:23:24 | Mikachu | that is to say, speed moves itself to 50% when i change pitch to 200% |
| 18:23:33 | Mikachu | so it is playing at 100% effective speed |
| 18:23:37 | Mikachu | we want this number to be displayed |
| 18:23:37 | * | gevaerts goes to get a player |
| 18:24:23 | Llorean | Mikachu: But it's not playing at 100% effective speed. It's playing at 50% effective speed, of a double pitch file? |
| 18:24:28 | animatorgeek | i.e. the speed display should be of the effective speed, not the speed multiplier the algorith is using. |
| 18:24:46 | Llorean | I mean, a 100% speed file at 200% pitch completes in half the time. |
| 18:24:51 | animatorgeek | Not on mine. |
| 18:25:01 | Mikachu | Llorean: i think you're suffering from "know too much" disease :) |
| 18:25:05 | animatorgeek | Not when in timestretching more |
| 18:25:07 | animatorgeek | mode |
| 18:25:10 | Mikachu | it's playing at 100% speed with double pitch |
| 18:25:14 | Mikachu | the file has never changed |
| 18:25:20 | Mikachu | i don't care how the code works |
| 18:25:32 | animatorgeek | Unless something has changed from when I updated last night |
| 18:25:43 | Mikachu | and setting pitch below 60% in timestretch mode hangs rockbox for a minute and then it resets itself to 100% |
| 18:25:48 | * | animatorgeek and Mikachu are totally on the same page |
| 18:26:45 | animatorgeek | Mikachu: I figured that was perhaps a CPU thing |
| 18:26:48 | | Join itcheg [0] (i=62db4c46@gateway/web/ajax/mibbit.com/x-2bfd1764c0a3d1ac) |
| 18:27:19 | | Quit itcheg (Client Quit) |
| 18:27:27 | animatorgeek | Should there be some sort of limit based on the ability of the CPU to keep up? |
| 18:27:41 | animatorgeek | Sort of an AGC for timestretching? |
| 18:27:54 | Mikachu | and playback has higher priority than ui, that's why it hangs? |
| 18:28:05 | Mikachu | it goes quiet too though |
| 18:28:18 | Mikachu | or did it, i'm not sure now :) |
| 18:28:42 | gevaerts | Llorean: are you looking at the timestretch screen? |
| 18:28:58 | animatorgeek | On mine it went quiet when I went too low. I just scrolled ack up to a more reasonable number and it started playing again |
| 18:29:05 | Llorean | gevaerts: I've cleared up my misunderstanding, but I don't get why they want what's there changed |
| 18:29:43 | animatorgeek | Lemme try again. The speed display should display the relative speed that the user years. |
| 18:29:48 | Mikachu | Llorean: let's say i want to play at 80% effective speed with a higher pitch, i have to change the speed to 80% first and then change pitch, otherwise i don't know what numbers to input |
| 18:30:05 | Mikachu | if i change pitch first, the speed readout is meaningless |
| 18:30:07 | Llorean | animatorgeek: The speed should display the rate at which the file is consumed |
| 18:30:10 | Mikachu | unless i also have a pocket calculator |
| 18:30:24 | Llorean | If the file is 4:00 long, and it's going to take 8:00 to complete, speed should say 50% |
| 18:30:29 | Llorean | Independently of what pitch is set at. |
| 18:30:31 | animatorgeek | Llorean: yes, exactly. It doesn't currently, if pitch is shifted at all. |
| 18:30:34 | Mikachu | that's not what it does though |
| 18:30:38 | Mikachu | so we are actually in agreement |
| 18:30:53 | animatorgeek | Okay, cool, Everything is cleared up. |
| 18:31:11 | Mikachu | :) |
| 18:31:12 | animatorgeek | So, back to my actual original question, I guess this _is_ probably a bug.... |
| 18:31:45 | Llorean | It's not a bug |
| 18:31:47 | Llorean | It's a feature request. |
| 18:31:50 | animatorgeek | (assuming a certain understanding of the intended functionality) |
| 18:32:35 | | Quit Nico_P (Read error: 60 (Operation timed out)) |
| 18:32:48 | animatorgeek | I guess I'm not up on how the Rockbox development effort classifies this sort of thing |
| 18:33:20 | * | animatorgeek just compiled Rockbox for the first time three days ago |
| 18:33:28 | gevaerts | I'm not actually sure how this should be displayed |
| 18:33:31 | Llorean | A bug is when something isn't working how it's expected to work by the person who implemented it, independently of how the user expects it to work |
| 18:33:45 | | Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) |
| 18:34:05 | animatorgeek | Ah, I see. |
| 18:34:28 | gevaerts | Llorean: maybe pondlife intended to break mpegplayer? ;) |
| 18:34:41 | Llorean | gevaerts: Then the patch really should be reverted. :-P |
| 18:34:52 | animatorgeek | So then the question I have is: would it be presumptuous for me to go in and change this without consulting pondlife? |
| 18:34:56 | gevaerts | Llorean: why? there's no bug then! |
| 18:35:06 | Llorean | gevaerts: Yeah, but the feature is unwanted in core. |
| 18:35:40 | gevaerts | animatorgeek: committing it without talking to pondlife would be, I think. Just submitting a patch certainly isn't |
| 18:35:53 | gevaerts | Llorean: mpegplayer is a plugin :) |
| 18:36:18 | Llorean | gevaerts: Yeah, but the feature "break a subset of plugins using the playback system" is unwanted in core. :-P |
| 18:36:20 | animatorgeek | Don't I need permission or a login name or something to commit directly to SVN? |
| 18:36:26 | Mikachu | animatorgeek: obviously |
| 18:36:26 | Llorean | animatorgeek: You can't. |
| 18:36:31 | Llorean | animatorgeek: You need to post a patch. |
| 18:36:38 | animatorgeek | I thought so |
| 18:36:43 | | Quit barrywardell () |
| 18:37:37 | animatorgeek | So then my next question: On my local copy I added in a menu setting to make the morse keyboard default. |
| 18:38:08 | animatorgeek | If I want to submit a patch, do I really need to go through and compile every single build to make sure it works okay? |
| 18:38:30 | Mikachu | animatorgeek: you would submit it on the tracker and interested people would try it on their targets if you're lucky |
| 18:38:51 | gevaerts | animatorgeek: nobody compiles every single target... |
| 18:39:17 | Mikachu | it would be nice if you could send code to the build farm without committing :) (maybe only committers, but still) |
| 18:39:31 | Mikachu | you could test your commits before committing and save half the revision number space ;) |
| 18:39:35 | animatorgeek | How could it make it into the core? Is there something I can do to help that along? Or is it unlikely, since it hasn't officially been requested? |
| 18:40:15 | Llorean | animatorgeek: Make sure the patch works well, post it on the tracker, send an email to the mailing list mentioning it and that you're interested in trying to get it committed and willing to address any issues anyone has with it. |
| 18:40:28 | gevaerts | animatorgeek: the best thing you can do is to submit it, and address issues quickly |
| 18:40:53 | animatorgeek | Okay, cool. I just signed up for the dev mailing list like half an hour ago. |
| 18:40:58 | Unhelpful | Mikachu: a sort of "pre-commit" would definitely be cut down on the number of "fix red/yellow" revisions, but i don't think it's that big a deal. |
| 18:41:25 | *** | Saving seen data "./dancer.seen" |
| 18:41:58 | animatorgeek | Actually, I have another question in relation to my changes |
| 18:42:20 | Mikachu | Unhelpful: maybe if the build servers were connected to the git server instead, and there was a separate branch there you could push to |
| 18:42:30 | animatorgeek | In creating the new menu item I also added two entries to english.lang. Do I need to add those to the other language files? |
| 18:42:59 | animatorgeek | Relatedly, I saw a coment somewhere that said that the order of the language entries matters, and that things shouldn't be inserted, but rather added to the end. |
| 18:43:20 | Unhelpful | Mikachu: HM! that's an idea, but it could be messy... the git server doesn't accept commits at all, they're pulled from svn. it would also need to auto-back-out changes that cause red or yellow on that branch. |
| 18:43:23 | animatorgeek | How, then, would a patch work if something else had been subsequently added to a lang file? |
| 18:43:41 | Mikachu | Unhelpful: it could accept them in either a separate branch or a separate repo |
| 18:43:48 | Unhelpful | really, i think it would be a lot of work, for something that's not of a whole lot of use. |
| 18:43:54 | | Join fml [0] (n=4fd3db13@gateway/web/cgi-irc/labb.contactor.se/x-069e045ff3f26954) |
| 18:43:56 | Mikachu | and after it test compiled it, it would revert the commit and reset that branch to latest trunk |
| 18:44:07 | animatorgeek | Is it just something that would need to be hand-held by a person to resolve the conflict? |
| 18:44:20 | Mikachu | probably |
| 18:44:28 | Unhelpful | animatorgeek: yes, people are needed to resolve non-trivial conflicts. |
| 18:45:10 | animatorgeek | Okay, thanks. Hope I'm not being to noobish. I guess I'll try and submit my patch, then.... |
| 18:45:56 | fml | The ManualHowto wiki page tells Ubuntu/Debian users to install some tetex-xxx packages. But the package description o tetex-base (at least in Ubuntu) states: "teTeX is no longer developed upstream, and has been replaced by the TeX Live collection" Shouldn't we update the wiki? Or do tetex packages have some advantages? |
| 18:49:00 | kugel | animatorgeek, Mikachu: That sounds like a reasonable request to me |
| 18:49:15 | Mikachu | the effective speed readout? |
| 18:49:18 | kugel | yes |
| 18:49:30 | kugel | the same thing should happen on the pitch only page too then, of course |
| 18:49:50 | Mikachu | you mean if you switch to that page with a speed change in effect? |
| 18:49:54 | animatorgeek | At the moment the pitch-only page doesn't display the speed |
| 18:49:59 | Mikachu | or i guess it could always show it |
| 18:50:13 | Mikachu | with speed unchanged, pitch will always be equal to effective speed i think |
| 18:50:18 | animatorgeek | I think it would be nice if it always displayed the relative speed |
| 18:50:18 | gevaerts | indeed. Just always display "Effective speed" |
| 18:50:21 | kugel | animatorgeek: the pitch only page displays the speed. unless you changed speed-only it |
| 18:50:36 | kugel | pitch and speed are identically |
| 18:50:59 | kugel | but since you can change speed-only now, the actual speed should be shown there too |
| 18:52:41 | kugel | might get a bit tricky with calculating it, we don't have floating point numbers, so 110%*91% doesn't quite work easily |
| 18:53:29 | gevaerts | not *that* tricky. Just insert a *1000 or so somewhere |
| 18:53:33 | Mikachu | how does it find the 91% in the first place? |
| 18:54:15 | kugel | magic :) |
| 18:54:32 | animatorgeek | I'm slightly surprised there's no fixed-point library in Rockbox.... |
| 18:58:03 | Unhelpful | animatorgeek: there's a lot of fixed-point math in rockbox. it's hard to create a one-size-fits-all fixed-point "library" |
| 18:59:04 | Mikachu | not really much more you can do than a couple of defines anyway |
| 18:59:48 | Unhelpful | Mikachu: pictureflow uses truly-fixed-point coordinates, and they're a fair amount of trouble :/ |
| 19:00 |
| 19:00:37 | * | Mikachu worked on some code at work that used three different precisions for fixed-point numbers in the same function |
| 19:02:27 | Mikachu | how unwelcome would a change like this be? http://comm.it.cx/?p=rockbox-svn.git;a=commitdiff;h=fc22dcbe0c2 (i realize it needs more to not break every other target) |
| 19:02:38 | Unhelpful | that often makes *sense*, though. the jpeg decoder's IDCT functions use S.2 between the two passes, and S.13 for temporary values while calculating 1D IDCT. if they didn't scale back to S.2 between passes, then using the same S.13 multipliers would overflow. coordinate math is really one of the few places where you can avoid constant scale changes. |
| 19:02:43 | Mikachu | without it i only manage to answer yes to questions a third of the time :) |
| 19:02:57 | Mikachu | it changes yesno to use a specific key to say no, rather than any button |
| 19:03:16 | kugel | I see no reason for that |
| 19:03:30 | Mikachu | just accidentally touch the wheel and you say no |
| 19:04:25 | kugel | it probably should ignore scrollwheel actions at all |
| 19:04:44 | Mikachu | that would be good too, but i guess it would be up to me :) |
| 19:05:06 | kugel | which can be done through {ACTION_NONE, BUTTON_SCROLL_FWD, BUTTON_NONE} etc |
| 19:05:21 | kugel | it might be a bit more complicated |
| 19:05:44 | Mikachu | |REPEAT and all that too? |
| 19:05:49 | kugel | yea |
| 19:06:40 | Mikachu | what does it get for a button that isn't listed? ACTION_OTHER or what? |
| 19:08:01 | kugel | no idea |
| 19:08:25 | Unhelpful | i believe no match returns ACTION_NONE? |
| 19:08:56 | * | fml just tried the new "pitch separately from speed" screen. The fact that increasing pitch automatically reduces speed is indeed very confusing. |
| 19:09:10 | Mikachu | no, because no match results in the 'YESNO_NO' code path being taken under default:, not under case ACTION_NONE: |
| 19:09:14 | kugel | Mikachu: ACTION_NONE results in a continue (and not in a reject) |
| 19:10:04 | * | fml thinks that now, that pitch and speed are not the same, it would make sense to display bothe values regardless of the mode. |
| 19:10:22 | kugel | Unhelpful: obviously not |
| 19:10:35 | kugel | well, not obviously, apparently (I'm looking at yesno.c) |
| 19:11:01 | Unhelpful | ACTION_UNKNOWN appears to be the default return value for get_action_worker |
| 19:11:28 | kugel | Unhelpful: no match will ask the next context in list |
| 19:11:39 | Mikachu | yeah it looks like ACTION_UNKNOWN |
| 19:12:03 | kugel | anyway, explicitely assinging ACTION_NONE seems to work out fine |
| 19:12:09 | Unhelpful | kugel: but there is no next context in this case. if no match is found in the context chain, you get ACTION_UNKNOWN |
| 19:12:23 | kugel | on the e200, there's CONTEXT_STD after |
| 19:12:40 | kugel | but all ACTION_STD_* will also branch to the default: case |
| 19:12:45 | Unhelpful | indeed |
| 19:13:19 | animatorgeek | Okay, here's a UI question for you. As part of my implementation of a menu item to choose which virtual keyboard to use (more or normal) I inadvertently also made Rockbox remember which one you used last, and come up with that one next time as well. |
| 19:13:34 | animatorgeek | So the question is, is a menu item even needed? |
| 19:13:52 | animatorgeek | And if so, should it _not_ remember the last mode used? |
| 19:14:04 | kugel | I think it should |
| 19:14:09 | Mikachu | that could be an option too \) |
| 19:14:16 | kugel | not sure about the menu item, I've never seen the morse mode |
| 19:14:23 | | Join raphi [0] (n=raphi@pub082136118205.dh-hfc.datazug.ch) |
| 19:14:47 | animatorgeek | I like it better, personally, but it isn't even available on some archetectures for some reason |
| 19:15:33 | | Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) |
| 19:15:55 | * | Mikachu has a halfworking implementation of http://www.rockbox.org/tracker/5165?getfile=11678 , speaking of input |
| 19:16:31 | animatorgeek | Okay, I guess I'm going to leave it like it is −− you can change it either through the menu or with the usual key combo (play+AB on h1x0) |
| 19:16:50 | animatorgeek | (like it is in my current changes, that is) |
| 19:18:41 | | Quit fml ("CGI:IRC (EOF)") |
| 19:23:03 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
| 19:23:47 | * | Mikachu added patch to http://www.rockbox.org/tracker/task/5165 after 2½ years :) |
| 19:24:27 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 19:26:30 | | Quit Sajber^ (Read error: 104 (Connection reset by peer)) |
| 19:26:50 | | Nick Moarc is now known as DeSnajpa_IX (n=zelazko@unix.net.pl) |
| 19:27:04 | | Nick DeSnajpa_IX is now known as Moarc (n=zelazko@unix.net.pl) |
| 19:28:42 | | Nick Moarc is now known as Buka (n=zelazko@unix.net.pl) |
| 19:28:51 | | Nick Buka is now known as J-23 (n=zelazko@unix.net.pl) |
| 19:30:44 | animatorgeek | Another question. Currently KBD_MORSE_INPUT is defined in keyboard.c. To include an entry in the general settings, though, I really need to know if KBD_MORSE_INPUT is true in settings.h |
| 19:31:23 | animatorgeek | Would it be appropriate in this case to create a new header file −− perhaps keyboard.h −− to hold the KBD_MORSE_INPUT definition? |
| 19:31:56 | | Join TripLeg [0] (n=4ae644f2@gateway/web/cgi-irc/labb.contactor.se/x-5763265468a7f973) |
| 19:32:34 | TripLeg | anyone here I can complain about something on the rockbox forums? |
| 19:32:50 | TripLeg | *complain to, about the forums |
| 19:32:55 | Unhelpful | i wonder why you can't report it to a forum admin there? surely we have such a feature? |
| 19:33:30 | TripLeg | I havnt registered for the forums, and If i do, it'll be only for this one thing, so it'd be a waste |
| 19:33:45 | gevaerts | what's the problem? |
| 19:33:57 | AlexP | TripLeg: Go ahead |
| 19:35:24 | TripLeg | I've got a sanas fuze, And all the sansa fuze information is in 67 pages with of all the other sansa projects, search function keeps bringing up information and topics, but all the replies point to the 67 page discussion with ALL the sansa mp3 players... |
| 19:35:57 | AlexP | Not all of them |
| 19:36:07 | AlexP | But those in the same hardware family |
| 19:36:15 | AlexP | On which development is ongoing |
| 19:36:32 | AlexP | When it is supported, the main forums will apply |
| 19:36:49 | AlexP | As most things w.r.t. Rockbox are largely independant of the hardware |
| 19:36:51 | Unhelpful | they're developed together, as there is more than a little in common between them (they're based on the same SoC, though some peripherals differ) |
| 19:37:33 | TripLeg | ok |
| 19:37:50 | AlexP | You have found the Sansa v2 (Sansa AMS) development thread |
| 19:38:06 | TripLeg | no, havnt found that one |
| 19:38:17 | AlexP | Yeah, that is the 67 page one |
| 19:38:22 | AlexP | You have found it :) |
| 19:38:42 | TripLeg | Argh |
| 19:38:49 | AlexP | Each not yet supported target has just one thread for developers. When it is supported, users can use the main forums |
| 19:39:24 | AlexP | As Unhelpful said, many of the newer Sansa players have similar hardware, and hence are in the same development thread |
| 19:43:07 | animatorgeek | If I add a header file, do I need to do something in terms of configuration and Makefiles and such? Or will the dependencies be automatically updated? |
| 19:43:21 | | Quit stripwax ("http://miranda-im.org") |
| 19:43:54 | TripLeg | right, looks like i've got some reading ahead... |
| 19:43:58 | TripLeg | thx |
| 19:44:12 | AlexP | No probs - that thread is a little intimidating |
| 19:44:20 | AlexP | Good luck :) |
| 19:44:54 | animatorgeek | Anyone know about adding a header file? |
| 19:45:10 | | Quit TripLeg ("CGI:IRC") |
| 19:45:53 | | Quit Zarggg () |
| 19:46:24 | | Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
| 19:48:04 | linuxstb | animatorgeek: It should "just work". If you add a .c file, you need to add it to firmware/SOURCES or apps/SOURCES |
| 19:48:10 | | Join BdN3504 [0] (n=55b215d0@gateway/web/cgi-irc/labb.contactor.se/x-f5cb40a5b6d2bdc6) |
| 19:48:17 | animatorgeek | okay, thanks |
| 19:48:50 | BdN3504 | Is 50 Eur too much for a samsung YH-920? |
| 19:49:42 | animatorgeek | No idea. I'd suggest shopping around and seeing what people are paying.... |
| 19:51:04 | animatorgeek | Does anyone know where CONFIG_KEYPAD is defined? I'm having a hard time finding it.... |
| 19:51:59 | Bagder | animatorgeek: see firmware/export/config-*.h |
| 19:52:06 | Mikachu | animatorgeek: grep? :) |
| 19:52:43 | | Join timc [0] (n=aoeu@116.3.13.89) |
| 19:52:48 | animatorgeek | Thanks. It's been years since I used grep. |
| 19:53:27 | animatorgeek | windows search doesn't seem to like searching for an entire phrase.... |
| 19:53:39 | animatorgeek | But yes, I'll try that next time |
| 19:54:18 | JdGordon | anyone know rougplhy what time the discussion happened to bring up the database poll in the announcments forum? |
| 20:00 |
| 20:08:11 | gevaerts | JdGordon: http://www.rockbox.org/irc/log-20090611#13:04:06 |
| 20:14:34 | | Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
| 20:15:30 | | Nick J-23 is now known as Moarc (n=zelazko@unix.net.pl) |
| 20:16:42 | Bagder | btw, that (void) talk was clearly not about optimized code |
| 20:17:08 | Bagder | quite clearly (void) a does not result in anything when a function is O2'ed |
| 20:17:14 | JdGordon | gevaerts: : ta |
| 20:17:20 | JdGordon | I didnt go back far enough |
| 20:18:03 | Bagder | thus, I don't think replacing (void) with something else is very important |
| 20:18:17 | * | Unhelpful can't imagine (void) doing anything ever, really... |
| 20:18:31 | Bagder | Unhelpful: it does when no -O is used |
| 20:18:56 | Unhelpful | copies the parameter into another register, or something? |
| 20:19:03 | | Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) |
| 20:19:25 | Bagder | yes, but onto the stack rather in my test |
| 20:19:43 | | Join tvelocity [0] (n=tony@adsl5-44.her.forthnet.gr) |
| 20:19:47 | Bagder | hm well that's of course not strictly the (void) |
| 20:20:09 | Unhelpful | -O0 does some truly silly things :) |
| 20:20:51 | gevaerts | indeed. It's just the function init that copies it I expect |
| 20:21:00 | Bagder | http://rockbox.pastebin.com/m6ae73188 |
| 20:22:09 | Bagder | (-S -fverbose-asm output) |
| 20:24:30 | kugel | what does that function look like in C? |
| 20:24:43 | kugel | the difference between -O and non-O is surprising |
| 20:25:01 | Bagder | the function is at the top |
| 20:25:27 | kugel | oh didnt see |
| 20:26:54 | | Quit BdN3504 ("CGI:IRC (EOF)") |
| 20:28:11 | Unhelpful | ARM, right? |
| 20:28:49 | kugel | I still think we should do it |
| 20:29:35 | kugel | there are some function types for which it is common to have an unused parameter. And we can tell that by using the __attribute__((unused)) thing, so they don't have to worry about |
| 20:30:46 | gevaerts | I agree. an UNUSED macro may make things a tiny bit more readable |
| 20:30:56 | kugel | and the non-O assembly speaks for itself |
| 20:31:05 | kugel | we don't use -O on some targets |
| 20:31:21 | * | gevaerts would actually expect a warning if you use __attribute__((unused)) and then use the thing |
| 20:31:43 | | Join barrywardell [0] (n=barrywar@12.189.97.66) |
| 20:33:35 | kugel | I think that's something you experience once, plus we can put a comment above the #define |
| 20:34:35 | | Quit barrywardell (Client Quit) |
| 20:38:28 | | Quit flydutch ("/* empty */") |
| 20:38:40 | Unhelpful | why would we not use -O? -O0 generates *awful* code |
| 20:40:20 | kugel | on in-developements targets, mainly |
| 20:41:27 | *** | Saving seen data "./dancer.seen" |
| 20:41:37 | kugel | IIRC, bertrik tried -O1 or 2 for the AMSes recently, which resulted in breakage |
| 20:43:28 | Unhelpful | also, i'm not entirely sure that that code is generated *because of* (void). what happens if you use __attribute__((unused)) |
| 20:45:01 | gevaerts | It's not. The (void) thing really only makes the warning go away |
| 20:45:44 | bertrik | I can't remember exactly what happened, it was not a really systematic test. IIRC it did result in some sensitive delays to break down. |
| 20:47:20 | Unhelpful | those should probably be coded in ASM, or in their own files built without -O. you don't want the whole target built without in any case... |
| 20:49:02 | bertrik | we're now compiling for AMS with option -O, so no explicit level |
| 20:49:21 | Unhelpful | if the function call overhead would mess them up, an inline asm marked volatile should also work |
| 20:50:38 | animatorgeek | Okay, I'm having a bit of a problem. I include config.h but CONFIG_KEYPAD seems to remain undefined |
| 20:51:23 | animatorgeek | Anyone know why this might be? |
| 20:52:01 | linuxstb | animatorgeek: What target are you compiling for? |
| 20:52:31 | animatorgeek | h120 |
| 20:53:04 | animatorgeek | I'm trying to move some defines that were in keyboard.c into a new header file, keyboard.h |
| 20:53:50 | animatorgeek | but it doesn't seem to trip the conditional compile #if (CONFIG_KEYPAD == IRIVER_H100_PAD) |
| 20:54:08 | bertrik | I've often wondered how exactly gcc makes it optimisation decisions, doesn't it also need to know things about the various memories, e.g. cached or not, access time, DRAM or SRAM? |
| 20:55:00 | bertrik | but the specifics of this are probably off-topic for #rockbox ... |
| 20:55:33 | linuxstb | bertrik: That all seems more specific than just CPU type, which is all we tell gcc about the target. |
| 20:56:02 | linuxstb | animatorgeek: I would add lines such as "#warning HERE!" into the various files to debug it. |
| 20:56:08 | | Join Grahack [0] (n=chri@stc92-1-82-227-106-100.fbx.proxad.net) |
| 20:56:22 | bertrik | can we give gcc any more hints that may help it to optimise? |
| 20:56:27 | animatorgeek | I'll try that.... |
| 20:57:59 | animatorgeek | Arg. It isn't correctly detecting the dependencies. I modify keyboard.h, which is included in settings.h, but nothing recompiles. |
| 20:59:29 | linuxstb | animatorgeek: Hmm, a "make clean" will probably help... |
| 20:59:50 | animatorgeek | I think I tried that, but I'll try again. |
| 21:00 |
| 21:00:47 | Unhelpful | bertrik: i don't believe there are ways to hint that sort of thing. i had a similar problem with IDCT, gcc produces essentially optimal ARMv4 code from the C, *except* for some superfluous sign- or zero- extensions, because *i* know that the top half of certain 32-bit results is empty, but there's no way to hint *that* to gcc either. |
| 21:02:30 | bertrik | I almost forgot that we do hint with the LIKELY and UNLIKELY macros |
| 21:04:01 | Unhelpful | those use gcc builtins... i don't know of any builtins or attributes that say "this memory is slower than that" or "this value will not exceed a certain range" :/ |
| 21:04:36 | * | Unhelpful still thinks that gcc ought to offer a cast-like syntax extension or a builtin for the latter |
| 21:04:56 | Unhelpful | as to the former, we generally have to decide explicitly where things are in memory, don't we? |
| 21:08:13 | bertrik | yes, we do that in the linker script as far as I know |
| 21:09:59 | animatorgeek | Ah, I figured out the problem. There's another keyboard.h! |
| 21:10:02 | | Join saratoga [0] (i=9803c6dd@rockbox/developer/saratoga) |
| 21:11:11 | bertrik | hm, I almost thought I had identified the problem causing playback to still stop on the clip sometimes |
| 21:11:11 | saratoga | Unhelpful: (just reading the logs now) I saw you asked about TDAC for fast playback |
| 21:11:24 | saratoga | sorry for playing back while skipping quickly |
| 21:12:24 | saratoga | it actually does work ok since the TDAC only depends that you have the previous block, not that TDAC worked for the previous block, so you'd decode block N-1 (badly) then N and TDAC would work for N even though N-1 is screwed up |
| 21:12:40 | saratoga | then I guess you throw away N-1 |
| 21:13:15 | bertrik | the pl081 datasheet says to enable synchronisation logic when the peripheral generating the DMA request runs on a different clock to the SMDMAC |
| 21:13:59 | Unhelpful | saratoga: so, to get one block worth of correct data while skipping, you have to decode two, and take the overlapped area? |
| 21:13:59 | bertrik | the DMA controller is on the AHB while the I2S is on the APB so as far as I understand the synchronisation logic should be enabled |
| 21:14:14 | saratoga | Unhelpful: yeah basically |
| 21:14:35 | bertrik | I tried it out and it seemed to work quite well on an album that often stops playing for me, but it just stopped anyway ... |
| 21:14:49 | | Join gartral [0] (n=Gartral@adsl-75-33-71-189.dsl.bcvloh.sbcglobal.net) |
| 21:14:50 | gartral | is it known that there are two case styles (internal scroll wheel) for the e200s? |
| 21:15:26 | saratoga | though i bet it'd sound ok to just decode one, since blocks are so short, you'd probably just hear it blended into the click sound when you skipped |
| 21:16:27 | saratoga | Unhelpful: I've been trying to understand the huffman decoding in ffmpeg for a couple days now, would you have time to look at a code sample and tell me what you think its doing? |
| 21:17:16 | bertrik | saratoga, can I have a look too? |
| 21:17:33 | saratoga | bertrik: sure |
| 21:17:53 | animatorgeek | Bertrik: I notice that your name is in keyboard.c. Can you tell me why it's in the recorder directory? Is that for historical reasons? |
| 21:17:53 | saratoga | heres the get_vlc code from ffmpeg once i've cleaned up all the stuff we don't use, and parsed all the preprocessor defines: |
| 21:17:56 | saratoga | http://mibbit.com/pb/FPDVPB |
| 21:18:19 | | Join DarkSpectrum [0] (n=ZX@99.23.115.136) |
| 21:18:37 | saratoga | i don't understand the bits and max_depth parameters |
| 21:19:03 | saratoga | WMA in ffmpeg uses 9 and 4 for them respecitvely, though other values work too with slightly different memory and cpu requirements |
| 21:19:40 | saratoga | i don't understand why the get vlc function takes a number of bits? shouldn't it be defined by the length of the code we're looking up? |
| 21:20:43 | saratoga | here is the code that calls the vlc function: |
| 21:20:44 | saratoga | http://pastebin.ca/1460245 |
| 21:22:48 | saratoga | it makes sense to me that its stepping through the bitstream, decoding a variable length code, and then spitting out the uncompressed MDCT samples, but why it does what it does makes no sense to me |
| 21:22:51 | bertrik | saratoga, I think it peeks at some maximum amount of bits, then looks in the table (with size 1 << max_bits) what that code meant and how long the code actually was, instead of peeking at 1 bit at a time |
| 21:23:31 | linuxstb | animatorgeek: Yes, it's historical. The first two Rockbox targets were the Archos Player (character-cell LCD) and Archos Recorder (bitmap LCD) - so lots of things which are for "bitmap LCD targets" (i.e. everything apart from the Player) have found themselves in apps/recorder/ |
| 21:23:46 | linuxstb | animatorgeek: No-one has yet got around to fixing that... |
| 21:23:55 | saratoga | bertrik: you're refering to the two checks for if( n < 0) ? |
| 21:24:17 | bertrik | the table contains multiple entries of the same code |
| 21:24:42 | Unhelpful | that's a fairly common pattern for optimized huffman decoding, you create a prefix table of 1<<n entries, you read in n bits, and then you index the table. for codes smaller than n bits, the table contains multiple entries. |
| 21:25:37 | Unhelpful | generally such a table will give the length of the code, then you get the full code and look it up in a second table that contains all of the entries of a specific length |
| 21:26:12 | Unhelpful | i don't know how mpeg and wma do things, but in jpeg the huffman codewords don't encode actual values, but the length of a value that is stored in the following bits. |
| 21:26:49 | saratoga | so the bits field is just the length of the first table? |
| 21:26:53 | bertrik | saratoga, I don't really understand the n < 0 part ... this code could use a bit more comments |
| 21:27:41 | saratoga | bertrik: the original version is written in C preprocessor macros, but some of them have comments, let me see if they're any help |
| 21:29:01 | saratoga | hmm not much luck looking at them |
| 21:29:01 | Unhelpful | the n<0 might perhaps flag a particular special case |
| 21:29:16 | saratoga | it seems odd to me that theres two checks for n<0 |
| 21:29:43 | saratoga | its like theres 3 levels to the table |
| 21:31:21 | saratoga | looking at the original preprocessor version, theres a check that max_depth >1 and then max_depth > 2 as well, so perhaps this code works with up to 3 level tables |
| 21:33:39 | bertrik | animatorgeek, my name is in that file because I last touched it for redundant #include cleanups :) |
| 21:33:50 | Unhelpful | there may be more tables. there are further ways to optimize this :) |
| 21:35:38 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
| 21:36:24 | saratoga | so if I understand you correctly, it looks up the first "bits" bits in the table "table" and then uses them to look up a new index in the table, and then continues until its consumed the maximum of 22 bits? |
| 21:36:46 | | Quit TheSphinX^ ("XChat@Linux") |
| 21:36:59 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
| 21:37:05 | saratoga | which i guess would explain why using 3 levels with 7 bits per level worked for the maximum of 22 bit codes, but trying to use 6 bits with three levels failed . . . |
| 21:43:10 | | Join _lifeless [0] (n=lifeless@188.16.98.241) |
| 21:43:27 | | Quit gartral ("I am what I am because of who We All are.") |
| 21:43:59 | Unhelpful | saratoga: i'm having trouble following this particular code. the method in general works along the lines of getting the code length and smallest code value of that length on the first lookup, getting the full code and subtracting the minimum, and using that to index a second table for codes of that length, which produces the actual symbol. |
| 21:44:19 | Unhelpful | i'm not precisely sure how this scheme works... looks like two layers of length-finding? |
| 21:44:45 | | Quit _lifeless (Client Quit) |
| 21:46:51 | | Quit animatorgeek ("CGI:IRC") |
| 21:47:46 | saratoga | Unhelpful: how generic is huffman decoding? looking in ffmpeg, it looks like mjpeg uses most of the same code so I guess pretty generic? |
| 21:48:06 | bertrik | here it's just a single table that directly contains the value for the huffman code and the length of the code, I think |
| 21:49:13 | bertrik | does this code actually work, or was it reconstructed from the macros without testing? |
| 21:50:05 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 21:50:26 | Unhelpful | there's a specific sort called canonical huffman codes that have certain advantages and are therefore used rather widely. because canonical huffman codes have code values in a specific order, a list of number-of-codes for each length can be used to reconstruct the codes entirely. |
| 21:50:28 | saratoga | bertrik: it works |
| 21:53:01 | | Quit raphi ("leaving...") |
| 21:55:19 | Unhelpful | jpeg uses canonical huffman, and the code table as stored in the file is only a list of lengths. i'd expect there are differences in pre- or post- processing... some formats may encode their information directly via huffman coding, others like jpeg encode a length and then that is followed by a non-huffman-coded variable-length value |
| 21:56:33 | Unhelpful | jpeg also allows markers inside the huffman codestream. these are indicated as a byte-aligned 0xff, followed by the marker value, with a zero value indicating a literal 0xff in the bitstream |
| 21:59:23 | | Join wincent [0] (n=wincent@host-091-097-067-213.ewe-ip-backbone.de) |
| 22:00 |
| 22:00:26 | bertrik | kugel, do you see spontaneous playback stops on your fuze? |
| 22:01:57 | bertrik | I still have those on my clip, but they're hard to track down to anything specific |
| 22:04:25 | | Join gartral [0] (n=Gartral@adsl-75-33-71-189.dsl.bcvloh.sbcglobal.net) |
| 22:04:48 | gartral | has the user Blin Wanderer been told he needs to use his real name? |
| 22:05:02 | bertrik | it usually doesn't really crash and I can often restart playback |
| 22:07:46 | gevaerts | martian67: we've seen enough reports of ipods not charging properly to take them seriously. A lot of them don't actually manage to get enough current over USB to keep running while connected and transferring data |
| 22:08:08 | martian67 | hrm |
| 22:08:09 | gevaerts | this may of course depend on the exact model and battery age |
| 22:08:12 | martian67 | usb is so fickle :/ |
| 22:08:25 | gevaerts | this is *not* a usb problem :) |
| 22:08:44 | martian67 | ._. |
| 22:18:20 | saratoga | wow looking at the wma huffman codes is interesting, very few even reach level two of the table, and maybe 1 in a hundred read level 3 |
| 22:18:57 | saratoga | i guess that make sense, lossy compression should make the data highly sparse so only a few codes are needed |
| 22:23:51 | | Quit petur ("Zzzz") |
| 22:26:37 | Horscht | so, seeing as albumart is bmp/jpeg only I assume one can not use "transparencies" in any way, correct? |
| 22:27:10 | saratoga | correct |
| 22:27:15 | saratoga | they wouldn't work in rockbox anyway |
| 22:27:51 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 22:28:51 | Horscht | well, i have often seen a workaround of using magenta as a transparent color in bmps, but I pretty much assume you didn't pull that trick because it would obviously break coverart that actualy uses that color |
| 22:29:33 | gevaerts | that's done on other bitmaps, but not on AA |
| 22:29:53 | Horscht | just wanted to verify :) |
| 22:30:51 | | Quit mcuelenaere () |
| 22:31:16 | kugel | bertrik: recently or in general? |
| 22:31:28 | bertrik | recently |
| 22:31:32 | kugel | I haven't had it on for a few days, but I never experienced those on the fuze |
| 22:33:28 | Grahack | hi there, did somebody try to code a musical keyboard as a plugin? |
| 22:36:33 | bertrik | kugel, I found some oddity in the dma setup and tried to see if fixing this would fix the playback stops on my clip |
| 22:37:02 | | Join efyx__ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) |
| 22:37:05 | bertrik | but if your fuze doesn't have those, it must be something clip specific and the dma setup was probably ok anyway |
| 22:41:21 | | Join slyyx [0] (n=slyyx@142.46.8.26) |
| 22:41:28 | *** | Saving seen data "./dancer.seen" |
| 22:43:16 | kugel | bertrik: the only real difference between fuze and clip is the DRAM (obviously, but it's also set up slightly differently) and the use of the iram |
| 22:43:49 | bertrik | what's different about the use of the iram? |
| 22:44:05 | kugel | have you looked if the IRAM is too full? The whole codec buffer is there, but also some lcd and memcpy code |
| 22:44:39 | Mikachu | Grahack: if you have an ipod i have a plugin that uses the internal beeper to beep different notes depending on where you touch the wheel, but i wouldn't call it musical :) |
| 22:44:44 | bertrik | I hoped the linker would complain about that |
| 22:44:51 | kugel | I can imagine that the codec just gets overwritten at some point after executing code which is before the codec buffer |
| 22:44:59 | kugel | then stops working |
| 22:46:07 | kugel | there's a bit of code in rockbox, that doesn't listen to the ICODE/IDATA attribute defines and is always in IRAM (I noticed that when looking whether we use IRAM correctly a few weeks ago) |
| 22:46:14 | bertrik | I could check the stacks once a playback problem occurs |
| 22:46:20 | kugel | I think the frame buffer is also in IRAM on the clip |
| 22:47:05 | bertrik | hm, the codec stacks is at 92% |
| 22:47:15 | kugel | bertrik: the codec buffer is 0x48000, only 0x2000 for other stuff left |
| 22:47:32 | bertrik | but so it is on my e200... |
| 22:47:54 | kugel | huh? |
| 22:47:58 | bertrik | kugel, wow |
| 22:48:11 | | Quit efyx (Read error: 110 (Connection timed out)) |
| 22:48:32 | kugel | I never investigated that further, but I found that always suspicious |
| 22:49:13 | kugel | maybe removing #define IRAM_LCDFRAMEBUFFER IDATA_ATTR already helps |
| 22:52:21 | | Quit domonoky (Read error: 104 (Connection reset by peer)) |
| 22:55:19 | | Part Grahack |
| 23:00 |
| 23:01:50 | | Nick Moarc is now known as J-23 (n=zelazko@unix.net.pl) |
| 23:03:18 | | Quit stripwax ("http://miranda-im.org") |
| 23:03:35 | | Quit wincent (Connection timed out) |
| 23:06:52 | | Join CEQ [0] (n=CEQ@201.248.58.213) |
| 23:07:49 | CEQ | hi, i have a question...there is rockbox for the ipod nano 4th generation?? |
| 23:08:05 | Llorean | No. |
| 23:08:58 | CEQ | ok thanks |
| 23:15:39 | | Join siduhfisduhf [0] (n=4ae644f2@gateway/web/cgi-irc/labb.contactor.se/x-d075ff7e793fef7a) |
| 23:16:13 | siduhfisduhf | is rockbox the only alternitive mp3 player firmware out there? |
| 23:17:00 | Bagder | siduhfisduhf: no |
| 23:17:01 | Llorean | It's the only major one that we know of. |
| 23:17:16 | Bagder | but on the players rockbox supports, there really is no competition |
| 23:17:21 | AlexP | There is ipodlinux, but it has different goals and seems pretty dead |
| 23:17:32 | Llorean | There's also s1mp3.org's firmware |
| 23:17:38 | AlexP | And some for other players (OpenNeo?) |
| 23:17:56 | Bagder | and there's some linux on some mrobe, openneon on neos, sansalinux on sansas, etc |
| 23:18:04 | Bagder | openneo even |
| 23:18:15 | | Join amf [0] (n=amf@c-98-216-38-214.hsd1.ma.comcast.net) |
| 23:19:21 | amf | Should I be creeped out that my ipod volume control can control my main system volume when plugged into my Linux system? |
| 23:19:31 | | Join notlistening [0] (n=tom@94-195-105-95.zone9.bethere.co.uk) |
| 23:19:33 | Llorean | amf: That's the HID feature. |
| 23:19:56 | Llorean | It can also pause and skip tracks, etc, if your software supports media keys. |
| 23:20:39 | amf | I'll be, I had no idea that worked without an Apple + iTunes combo |
| 23:22:11 | AlexP | HID is a standard USB class |
| 23:22:16 | notlistening | bluebrother, does you have a schedule for the next rbutil release or is it adhoc? |
| 23:22:47 | Mikachu | the ipod could take over your computer completely and start typing rm -rf / too :) |
| 23:23:02 | AlexP | Most of the Rockbox players support this |
| 23:23:05 | Mikachu | fortunately they decided to make it control the volume instead |
| 23:23:26 | * | Llorean thinks it might be interesting to have a plugin that opens a web browser to the rbutil page. |
| 23:23:46 | AlexP | Llorean: Even more so - the manual :) |
| 23:23:56 | notlistening | thanks Llorean |
| 23:27:41 | | Quit CEQ ("Saliendo") |
| 23:31:01 | | Quit Nico_P (Remote closed the connection) |
| 23:31:51 | bluebrother | notlistening: given the HTTP 404 issues that were mentioned recently (and as far as I know are all fixed in current svn) I'd like to have a new release soon. Haven't thought / scheduled anything yet though. |
| 23:32:23 | bluebrother | but probably around the release of Rockbox 3.3 would be nice. |
| 23:32:33 | bluebrother | or even a few days before that. |
| 23:32:53 | notlistening | right thanks bluebrother |
| 23:33:39 | gevaerts | bluebrother: "a few days before 3.3" would be right now |
| 23:34:04 | bluebrother | gevaerts: right, just checked the targeted release date of 3.3 |
| 23:34:23 | bluebrother | well, releasing on tuesday would still be soon enough :) |
| 23:34:49 | notlistening | lol :) |
| 23:35:26 | notlistening | best wait for the next release to try and sneak my work in then |
| 23:36:31 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 23:43:17 | | Part amf |
| 23:44:46 | | Quit bmbl ("Woah!") |
| 23:45:07 | | Join safetydan [0] (n=deverton@rockbox/developer/safetydan) |
| 23:46:21 | | Join loyx [0] (n=pencil@ool-4354031e.dyn.optonline.net) |
| 23:50:29 | loyx | I compiled rockbox yesterday and I was surprised to see the USB function working properly in rockbox (rather then just rebooting to disk mode) with my ipod G4. However, strangely, it doesn't charge. I left it plugged into my computer all night and found my ipod with the battery and bolt picture meaning it wasn't charging. Is there a way to charge the ipod within rockbox? |
| 23:50:51 | Mikachu | loyx: how do you get from bolt picture to not charging? |
| 23:51:13 | loyx | no it charges fine, but only in disk mode |
| 23:51:24 | loyx | i thought the battery and bolt picture came from running out of batteries |
| 23:51:39 | loyx | which is what happened when i left the ipod plugged into my laptop overnight |
| 23:51:55 | | Quit tessarakt ("Client exiting") |
| 23:52:26 | loyx | i even went into the battery debug thing and plugged in the cord, and it said charger: present.. its really weird |
| 23:52:29 | gevaerts | there's a problem with ipod charging currently |
| 23:52:48 | gevaerts | FS #8802 has some details |
| 23:53:05 | loyx | ok, i'll take a look at it |
| 23:53:38 | Mikachu | loyx: so if you look at the battery % before and after having it plugged in a while, it's lower after? |
| 23:53:49 | | Quit Thundercloud (Remote closed the connection) |
| 23:53:55 | loyx | yes |
| 23:54:26 | loyx | right now i'm trying to charge it while still being able to use rockbox |
| 23:54:34 | loyx | meaning i don't get the usb symbol thing |
| 23:54:37 | | Quit slyyx (Read error: 113 (No route to host)) |
| 23:54:38 | loyx | it might make a difference |
| 23:54:47 | gevaerts | it doesn't |
| 23:54:59 | loyx | hmm |
| 23:55:02 | loyx | this is weird then |
| 23:55:04 | Mikachu | which ipod is it? is the backlight and playback off while you had it charging? |
| 23:55:46 | loyx | when i plugged it in yesterday, backlight and playback were off |
| 23:55:50 | Mikachu | and this is usb charging, not ac? |
| 23:55:53 | loyx | it was just the usb symbol on the screen |
| 23:55:54 | loyx | yes |
| 23:55:57 | Mikachu | the bug seems to be about ac only |
| 23:55:58 | loyx | i don't have an AC adapter |
| 23:56:08 | loyx | thats strange |
| 23:56:15 | Mikachu | i didn't read the comments though :P |
| 23:56:23 | loyx | i'm hoping theres a patch for it |
| 23:56:28 | | Quit bluebrother ("leaving") |
icon identifies that the person is a core developer (has commit access).