| 00:00:55 | webguest46 | which one of the links is it? |
| 00:01:23 | Bagder | depends on what you need to know, ie where you're at now |
| 00:02:51 | webguest46 | well, i want to change the bootloader to be able to load different firmwares. Like center button for firmware.mi4 and up for anoterfirmware.mi4. Do you understand this? |
| 00:03:08 | Bagder | we do, I doubt you do |
| 00:03:33 | Bagder | get the code, edit it, compile it, install it, use it |
| 00:03:44 | justlistenin | Goodluck with bootloader guy and thanks for the info on the sansa usb. See yall later and as always, good work on all of it and thank you for all your work! |
| 00:03:50 | | Join kubrick [0] (n=repulse@unaffiliated/funky) |
| 00:04:07 | safetydan | good lord... I had no idea #rockbox-community was so... offtopic |
| 00:04:08 | | Quit einhirn (Read error: 104 (Connection reset by peer)) |
| 00:05:06 | n1s | safetydan: the only thing that's offtopic in there is actual rockbox talk ;) |
| 00:05:43 | safetydan | n1s, so true |
| 00:06:12 | BigBambi | safetydan: It isn't normally this fractious |
| 00:07:49 | safetydan | anyway, if someone with an iPod Video has some time, could they take a look at FS #7440? I'd really like to get that committed, but I can't test it. |
| 00:08:34 | | Join TradeJack [0] (n=aurum@ool-182f7087.dyn.optonline.net) |
| 00:10:27 | webguest46 | i opened it in a text editor but when i open the file, it is all symbols and other things. Can someone give me an exact link to the directions |
| 00:10:28 | | Quit justlistenin ("CGI:IRC (EOF)") |
| 00:11:01 | Bagder | webguest46: 1 get the code, 2 edit it, 3 compile it, 4 install it, 5 use it |
| 00:11:10 | Bagder | did you get the code? |
| 00:11:17 | webguest46 | where do i get it |
| 00:11:19 | Bagder | did you install a dev environment? |
| 00:11:23 | webguest46 | no |
| 00:11:53 | PaulJam | webguest46: can you program in C? |
| 00:11:55 | Bagder | those docs pages describe all those steps |
| 00:12:44 | webguest46 | PaulJam: no Badger: i'll look at all of them |
| 00:13:25 | Bagder | you need to do your requested changes by editing C code, you know that right? |
| 00:13:30 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 00:13:47 | PaulJam | webguest46: you need to modify rockbox' sourcecode which is written in C, so a basic knowledge of that would be good. |
| 00:14:51 | n1s | 6 ..., 7 profit! |
| 00:16:45 | | Join Soap_ [0] (n=Soap@rrcs-70-61-25-246.central.biz.rr.com) |
| 00:16:47 | amiconn | safetydan: I'll do a quick check. Btw, I think the code in wm8758.c can be simplified a bit further by using a register shadow variable |
| 00:17:42 | amiconn | safetydan: Umm, failed hunk in playback.c |
| 00:18:45 | amiconn | Probably easy to fix... /me looks |
| 00:18:50 | | Join bluebrother [0] (i=KQMq7E9p@rockbox/staff/bluebrother) |
| 00:19:03 | *** | Saving seen data "./dancer.seen" |
| 00:19:14 | safetydan | amiconn, darn it. Actually I think that last patch is stuffed. It's got conflict markers in the lang file changes. |
| 00:19:28 | | Quit n1s () |
| 00:20:03 | amiconn | umm, true |
| 00:20:07 | * | amiconn reverts patch |
| 00:20:40 | safetydan | amiconn, do you have an example of a register shadow variable? |
| 00:21:18 | amiconn | Just store what you wrote to the wm last time, and use &~ and | to mask in the new setting |
| 00:21:21 | bertrik | safetydan: I saw some in the as3514.c code |
| 00:21:38 | amiconn | This way you don't need 2 variables per register to store the current settings |
| 00:21:42 | webguest46 | I want to use the multibl for my sansa e200r. I have the bootloader patched and i am dual-booting with rockbox. Is there any way to get this to work on mine? Link: http://e200.digerati1338.googlepages.com/multibl |
| 00:21:47 | safetydan | amiconn, ah right |
| 00:22:24 | BigBambi | Could an op briefly pop into community please? |
| 00:24:17 | Llorean | webguest46: Contact whoever created it, we don't provide support for other peoples' software. |
| 00:25:41 | webguest46 | alright |
| 00:29:05 | | Quit Zagor ("Client exiting") |
| 00:30:29 | | Quit _pill (Read error: 110 (Connection timed out)) |
| 00:30:58 | | Join Zagor [0] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) |
| 00:32:09 | | Quit webguest46 ("CGI:IRC (EOF)") |
| 00:33:28 | | Join pill [0] (i=pill@sloth.shellfx.net) |
| 00:33:51 | | Quit bertrik ("bye") |
| 00:34:00 | | Quit qweru (Remote closed the connection) |
| 00:34:14 | Zagor | [sda] 2006529 512-byte hardware sectors (1027 MB) |
| 00:34:27 | Zagor | better :) |
| 00:35:02 | linuxstb | That looks like progress ;) |
| 00:35:17 | linuxstb | Assuming you didn't just type it... |
| 00:35:23 | Zagor | haha |
| 00:36:02 | midgey | \o/ |
| 00:36:51 | PaulJam | so how far are we from mouse support for doom on h300? |
| 00:37:10 | preglow | how good news? :> |
| 00:37:18 | Zagor | PaulJam: hehe. a bit. |
| 00:37:36 | | Quit ender` (" There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy") |
| 00:39:55 | preglow | Zagor: so, you'd say your initial time estimate on this thing was a bit off, then? :P |
| 00:40:14 | Zagor | haha, yeah a tiny bit... |
| 00:41:57 | jhMikeS | preglow: I take it the little kernel thingy was "a flyspray task for [me]"? |
| 00:41:59 | Zagor | I thought the usb and mass-storage protocols would be the hard parts, since we got docs for the controller. i was very wrong. |
| 00:42:52 | | Quit syn4pse ("Time wasted on IRC: 3 hours 30 minutes 9 seconds") |
| 00:43:46 | bluebrother | Zagor: nice to see the progress. Too bad I'll be offline for some unknown period starting tomorrow :( |
| 00:44:45 | Zagor | well it's not like i will be committing this tomorrow |
| 00:46:11 | preglow | jhMikeS: yeap |
| 00:46:17 | preglow | jhMikeS: btw, you're familiar with recording codecs, yea? |
| 00:50:29 | | Quit Daniel_S ("CGI:IRC") |
| 00:51:16 | | Quit pill ("changing servers") |
| 00:51:17 | jhMikeS | preglow: we have recording? :P |
| 00:51:34 | preglow | jhMikeS: well, encoder codecs |
| 00:51:42 | preglow | encoders :> |
| 00:51:43 | | Join pill [0] (i=pill@sloth.shellfx.net) |
| 00:51:46 | * | jhMikeS just kids of course |
| 00:51:55 | preglow | jhMikeS: it shouldn't too hard to make an encoder plugin, should it? loading encoders ala test_codec |
| 00:52:15 | jhMikeS | no. just do as pcm_record.c does |
| 00:52:19 | preglow | it's kind of silly having both mp3_encoder.c and mp3_enc.c |
| 00:52:26 | preglow | mp3_encoder doesn't even work as well as mp3_enc |
| 00:52:28 | jhMikeS | They need moderately more init though |
| 00:52:42 | | Quit ompaul (Client Quit) |
| 00:53:08 | preglow | jhMikeS: hmm, would modifying the core to pass data from disk to encoders need much changing? |
| 00:53:08 | jhMikeS | I guess that was from before codec recording? |
| 00:53:14 | preglow | yeah |
| 00:53:31 | jhMikeS | why mod the core? |
| 00:53:42 | preglow | just thinking it'd be silly to duplicate all the code again |
| 00:54:03 | preglow | all the encoder plugin handling code would be pretty much duplicated in the encoder plug |
| 00:54:22 | jhMikeS | to transcode? you certainly don't need to duplicate everything. I did put it together so you could just implement the intefaces. |
| 00:54:41 | preglow | mok |
| 00:54:56 | jhMikeS | just spit pcm samples at it |
| 00:55:22 | jhMikeS | and give it an output. most of the code is for realtime handling of them. |
| 00:56:02 | | Quit roolku () |
| 00:56:17 | preglow | i'm also starting to toy a bit with the idea of speex encoding |
| 00:56:18 | preglow | hrmr |
| 00:56:31 | | Quit obo ("bye") |
| 00:56:35 | preglow | that'll mean tons of asm |
| 00:56:55 | Llorean | You'd think speex would be designed for just this sort of situation. |
| 00:57:59 | preglow | well, it is |
| 00:58:08 | Llorean | Just, not enough for our purposes? |
| 00:58:12 | preglow | how? |
| 00:58:25 | preglow | encoders aren't cheap, they all need optimizing |
| 00:58:39 | jhMikeS | preglow: realtime speex recording? :) |
| 00:58:47 | preglow | jhMikeS: that would be the thing, yes |
| 00:58:55 | Llorean | I certainly wouldn't mind realtime some-sort-of-voice-codec recording. |
| 00:59:15 | preglow | i think coldfire should be able to do wb recording with a ton of asm |
| 00:59:15 | Llorean | Does the Sansa have working recording yet? |
| 00:59:27 | preglow | portalplayer can do nb encoding |
| 00:59:37 | preglow | gigabeat, uwb, heh |
| 01:00 |
| 01:00:00 | preglow | but it'll need a fair deal of asm and some float -> fixed point |
| 01:00:21 | linuxstb | The gigabeat can't record though... |
| 01:00:32 | Llorean | linuxstb: Yet. :-P |
| 01:00:39 | jhMikeS | btw, you really just need to implement the callbacks implemented by pcm_record.c in a transcode plugin but much more simply |
| 01:00:54 | Llorean | I'm sure one day, in the far future, someone will implement it via the USB hosting. |
| 01:02:23 | markun | Llorean: or with the i2s signals on the dock connector |
| 01:02:24 | jhMikeS | could have it in short order on the SW side of things. |
| 01:05:26 | * | preglow goes to bed |
| 01:05:29 | preglow | nightie |
| 01:06:33 | | Quit Zagor ("bed time") |
| 01:11:43 | | Quit midgey () |
| 01:15:26 | | Quit bluebrother ("nite") |
| 01:17:06 | | Quit PaulJam (".") |
| 01:21:11 | | Join midgey [0] (n=tjross@westquad-188-19.reshall.umich.edu) |
| 01:23:16 | | Quit jhMikeS (Nick collision from services.) |
| 01:23:22 | | Join jhMikeS [0] (n=jethead7@rockbox/developer/jhMikeS) |
| 01:23:53 | | Join atsea-39 [0] (i=atsea-@gateway/tor/x-40174253f69b664a) |
| 01:33:14 | | Quit spiorf (Remote closed the connection) |
| 01:35:20 | DerPapst | 'nite all |
| 01:35:22 | | Quit DerPapst ("So Long And Thanks For All The Fish!") |
| 01:36:15 | | Join Ebert [0] (n=EbErT@adsl-215-134-136.aep.bellsouth.net) |
| 01:43:31 | amiconn | jhMikeS: Hmm, I just found the timeout api in kernel.c - is this dualcore safe? |
| 01:44:26 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 01:44:43 | | Part TradeJack |
| 01:46:55 | amiconn | jhMikeS: I noticed that it's currently used on e200 and c200... |
| 01:47:25 | amiconn | Might be a nice solution for the bcm update handling on ipod video |
| 01:48:46 | jhMikeS | amiconn: it's not yet and always runs on the tick. some corelock stuff would make it so. |
| 01:49:11 | jhMikeS | it's used as the SD insert debouncer |
| 01:50:13 | amiconn | ah |
| 01:51:45 | | Join J3TC- [0] (n=jetc123@pool-72-76-179-145.nwrknj.east.verizon.net) |
| 01:51:49 | amiconn | Always running on the tick is a non-issue. But I need to make sure that I don't end up writing to the bcm from both cores at once, 'cause that might confuse it ;) |
| 01:52:39 | amiconn | I can't use mutexes here, 'cause an isr function must never lock |
| 01:52:58 | amiconn | I would need some kind of asymmetrical mutex |
| 01:53:40 | amiconn | The normal update would block only in the unlikely case of being called while the isr function is halfway through |
| 01:53:48 | jhMikeS | use the spinlock with set_irq_level around it or just the corelock |
| 01:54:08 | amiconn | (can only ever happen if lcd_update() is called from the COP, which is unlikely by itself) |
| 01:54:42 | amiconn | But the isr function must never lock - it would have to simply return if the lock is 'closed' |
| 01:54:53 | jhMikeS | if no task switch is desired. spinlock with without task switch is the best bet. no set_irq_level is need if it's not dual-use |
| 01:55:25 | jhMikeS | use corelock_try_lock |
| 01:55:36 | amiconn | It's not two threads locking. It's one thread (whichever that is - most of the time main), and a 'tick' task |
| 01:56:34 | jhMikeS | queues handle this through set_irq_level(HIGHEST_IRQ_LEVEL), corelock_lock(), corelock_unlock(), set_irq_level(oldlevel) |
| 01:56:47 | amiconn | The thread could switch tasks while waiting, but that's not necessary. The isr function will be rather short & fast |
| 01:58:15 | jhMikeS | the event queue construct should be what's needed for that |
| 01:58:35 | jhMikeS | without blocking calls of course |
| 02:00 |
| 02:01:46 | | Quit J3TC- (Read error: 104 (Connection reset by peer)) |
| 02:02:08 | amiconn | Hrrrmmm. If only I would understand this core locking business :( |
| 02:02:22 | | Join J3TC- [0] (n=jetc123@pool-72-76-179-145.nwrknj.east.verizon.net) |
| 02:03:04 | jhMikeS | keep one core spinning while the other core completes the section and unlocks. the sections are very short. |
| 02:03:39 | amiconn | There are now mutexes, spinlocks, semaphores, and events. And the corelock itself |
| 02:03:53 | amiconn | There used to be only _really_ simple mutexes.... :\ |
| 02:04:41 | jhMikeS | they're still simple in single core once preprocessed. I guess look at the sim version. |
| 02:06:07 | | Quit kubrick ("leaving") |
| 02:11:40 | | Quit pill (Read error: 110 (Connection timed out)) |
| 02:18:39 | | Part pixelma |
| 02:19:06 | *** | Saving seen data "./dancer.seen" |
| 02:19:26 | | Join flacoste [0] (i=francis@canonical/launchpad/flacoste) |
| 02:19:52 | flacoste | hi anyone here to help me with the bootloader install on a Sansa E280? |
| 02:20:19 | flacoste | sanspatcher says that it doesn't recognise any E200 or C200 |
| 02:25:57 | | Join toffe82 [0] (i=chatzill@static-71-160-73-186.lsanca.dsl-w.verizon.net) |
| 02:28:26 | krazykit | flacoste, 1) are you sure it's not an e280r (has rhapsody in the menu) and 2) is it in MSC mode? |
| 02:28:58 | flacoste | krazykit: it is not a e280r and yes it is in MSC mode |
| 02:29:13 | flacoste | krazykit: is it possible that the partition type isn't right |
| 02:29:24 | flacoste | I found the following: http://www.rockbox.org/tracker/task/6984?histring=sansapatch |
| 02:29:30 | flacoste | is this still an issue? |
| 02:30:48 | krazykit | not sure, to be honest. |
| 02:30:57 | flacoste | probably not anyway |
| 02:31:10 | flacoste | i checked using fdisk and the first partition is indeed W95 FAT32 |
| 02:31:20 | flacoste | and the other one is OS/2 hidden C: driver |
| 02:31:36 | krazykit | that sounds about right. |
| 02:31:54 | flacoste | anything thing that I can try with sanpatcher to give more debug info? |
| 02:32:42 | krazykit | sansapatcher doesn't appear to have a verbose object |
| 02:32:47 | flacoste | hmm, weird |
| 02:32:54 | flacoste | it now seems to work? |
| 02:33:08 | flacoste | i just run sansapatcher −−list and it recognises the device |
| 02:34:14 | krazykit | but just running it does not work, or does it? |
| 02:34:42 | flacoste | well, it says that it installed succesfully |
| 02:34:57 | flacoste | but on reboot i still boot in the original Sansa OS |
| 02:35:52 | | Part Strath |
| 02:35:54 | krazykit | try having sansapatcher uninstall the rockbox bootloader, then reinstall it |
| 02:36:07 | krazykit | and when it reboots, you DO have the usb cable out, right? |
| 02:36:20 | flacoste | i did |
| 02:36:26 | flacoste | i uninstalled |
| 02:36:36 | flacoste | should I unplug or reboot after uninstallation? |
| 02:36:40 | flacoste | before reinstalling I mean |
| 02:36:57 | rasher | flacoste: Did you install Rockbox itself? (downloading and unzipping rockbox.zip) |
| 02:36:57 | flacoste | the device screen still says 'Connected' |
| 02:37:46 | flacoste | rasher: i think i did |
| 02:38:08 | rasher | flacoste: If you didn't, the bootloader will load the sansa firmware. |
| 02:38:10 | flacoste | rasher: but on which partition does it go? |
| 02:38:22 | flacoste | rasher: i installed it on the Sansa data partition |
| 02:38:24 | rasher | flacoste: The one that's visible in explorer. The larger one |
| 02:38:34 | flacoste | the one with PICTURES, videos and all |
| 02:38:40 | krazykit | yes |
| 02:39:08 | flacoste | $ ls /media/Sansa\ e280/.rockbox/ |
| 02:39:19 | flacoste | i then get backdrops, codecs... |
| 02:39:23 | flacoste | so I guess that's ok |
| 02:39:36 | rasher | Looks correct |
| 02:39:43 | * | flacoste will now try reinstalling the bootloader |
| 02:40:15 | flacoste | how long should I wait before rebooting? |
| 02:40:22 | flacoste | the screen still says 'Writing' |
| 02:40:31 | krazykit | as long as you unmount it, it's fine |
| 02:41:40 | flacoste | seems to have worked this time!!! |
| 02:41:45 | flacoste | thanks a lot for the hand holding! |
| 02:42:07 | | Join a11313 [0] (n=a11313@CPE-69-23-137-242.wi.res.rr.com) |
| 02:42:24 | a11313 | hello everyone |
| 02:42:29 | flacoste | anyone of you knows if the USB issue is going to be fixed? |
| 02:42:45 | krazykit | flacoste, it's being worked on. |
| 02:43:28 | | Nick lukaswayne9 is now known as lt (n=lukas@c-68-84-69-12.hsd1.nj.comcast.net) |
| 02:43:38 | a11313 | are all sansa e200 mp3 players supported by rockbox, particularly the 8gig one? |
| 02:43:47 | | Nick lt is now known as lt_smooth420 (n=lukas@c-68-84-69-12.hsd1.nj.comcast.net) |
| 02:44:01 | flacoste | a11313: i just installed it on an e280! |
| 02:44:04 | krazykit | a11313, yes, "e200" refers to the whole line of e2x0 players |
| 02:44:56 | a11313 | okay, just making sure the newer one would be like the second/third gene ipod nanos |
| 02:45:37 | a11313 | also, is there a toolchain available for compiling rockbox for the sansa e2x0's? |
| 02:45:50 | scorche | we use arm-elf-gcc |
| 02:46:12 | a11313 | okay, think I got that toolchain already for ipodlinux binaries, so that's good news for me :) |
| 02:46:16 | scorche | the easiest way to install it is to use rockboxdev.sh, which is a script located in our tools directory in svn |
| 02:46:31 | scorche | well, make sure it is the version we recommend to use |
| 02:46:39 | Llorean | a11313: We recommend a very specific version, and I believe iPodLinux compiles on a much, much older version. |
| 02:46:41 | rasher | a11313: No. ipodlinux uses an ancient version of gcc I believe. Be sure to check that. |
| 02:47:02 | a11313 | hehe alright, that works for me too |
| 02:49:32 | | Quit kugel ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") |
| 02:51:45 | | Join homielowe [0] (n=chatzill@d207-81-67-190.bchsia.telus.net) |
| 03:00 |
| 03:20:52 | Llorean | jhMikeS: I really don't like the idea of you just saying "I'll revert it afterward". The patch has been in the tracker for quite some time, and seems well liked by all but a few... |
| 03:22:04 | * | Llorean wishes people would've just tried using that keymap for a month, as he suggested, rather than rejecting it outright. |
| 03:23:48 | | Quit RoC_MasterMind ("Leaving") |
| 03:24:48 | Llorean | I don't want to start a reversion war, but I loathe the existing map, irregardless of whether or not it's similar to other targets. It lumps "Stop" on the Play/Pause button on a target that has far more than enough buttons to give it one of its own, puts the menu on the Power button meaning if you press "Menu" for a little too long on accident you shut down, and makes the context menu harder than necessary to use by keeping it off Select. |
| 03:24:56 | jhMikeS | Llorean: Just poking you. :) I also think I said "change". |
| 03:27:15 | Llorean | Anyway, off to dinner. I'm not committing 'till Saturday, and I'm still open to other ideas for a replacement keymap that addresses problems. I picked one like the other targets mostly because it covered those (which I think is kinda how the original keymap came about: it works) but if another one makes it easier to use too, I wouldn't mind. |
| 03:27:39 | jhMikeS | play/pause/stop on one button is very consistent with other such devices I think. The only confusion on e200 I experienced was the use of short press for the context menu instead of long. |
| 03:27:52 | jhMikeS | That one still gets me. |
| 03:27:59 | Llorean | Many of my targets have a short press for stop |
| 03:28:04 | Llorean | In fact, the only two that don't are the e200 and the iPod |
| 03:28:07 | Llorean | The iPod with very good reason |
| 03:28:19 | * | Llorean delays dinner slightly |
| 03:28:30 | | Join tarsius [0] (i=a807e59b@gateway/web/cgi-irc/labb.contactor.se/x-4c9cb7992ba5d591) |
| 03:28:47 | jhMikeS | x5 uses the a long play for stop. short for pause. short to play if stopped. |
| 03:29:09 | karashata | H10 uses long play to stop as well |
| 03:29:24 | Llorean | The stop button is Power on H100, and the power is stop on Gigabeat. On the archos "Off" is stop |
| 03:29:40 | jhMikeS | yes. I knew what to do with all those because of that consistency. |
| 03:29:50 | Llorean | The only ones that don't use Off and Stop on the same button are ones where we have two few buttons, or "off" or "stop" doesn't have a unique button, I think |
| 03:30:03 | Llorean | too, rather than two |
| 03:30:05 | tarsius | hello. i'm setting up a Rockbox dev environment in cygwin and i'm attempting to compile usbutils so I can run "lsusb" |
| 03:30:05 | jhMikeS | On h100 it's also explicitly a stop button |
| 03:30:08 | alienbiker99 | isnt stop |
| 03:30:15 | alienbiker99 | nevermind, jhMikeS just said it |
| 03:30:22 | Llorean | jhMikeS: Yes, and on the Gigabeat and Archos it's explicitly a Power or Off button |
| 03:30:43 | Llorean | It seems a rather logical marriage, though. |
| 03:30:51 | jhMikeS | Gigabeat make no sense to me :). Thankfully the labels aren't readily readable. |
| 03:30:55 | Llorean | Especially since we use "Off" or "Stop" to cancel in many screens |
| 03:31:16 | tarsius | is there a difference between the way gcc in cygwin deals with the include path versus a gcc in a true linux environment? |
| 03:31:48 | Llorean | Also, assuming for the sake of argument "Menu" was definitely not going to be on the power button, what's the harm in putting stop on its own button? |
| 03:31:51 | jhMikeS | The e200 recording screen is consistent with x5 layout. Other than a scrollwheel, e200 and x5 are pretty much identical button wise. (x5 has a rec button though). |
| 03:32:20 | jhMikeS | Oh, right e200 has a rec button (but I forget it's there most of the time) |
| 03:32:24 | rasher | As does the e200 |
| 03:33:11 | krazykit | tarsius, no, your shell should work the same way in cygwin as in native linux |
| 03:33:27 | Llorean | But really, I don't see how the current map is "better" than my proposed one, unless you feel the problems I've cited with it don't matter. And honestly, you're welcome to, but I think that they can all be fixed without choosing a "bad" map. |
| 03:33:31 | rasher | It's really not a terribly convenient button, and I think it should be avoided at all costs to assign any actions to it. |
| 03:33:41 | jhMikeS | I guess I use rec to play solitaire but that's all I seem to use it for |
| 03:33:51 | tarsius | krazykit: i ask because I have no INCLUDE or C_INCLUDE_PATH env variables, etc |
| 03:34:15 | * | Llorean thinks the "Power" button is very inconvenient for one-handed operation on Sansa, too. |
| 03:34:19 | jhMikeS | It does record on the rec screen, but so does play but that's a common assignment anyway |
| 03:34:59 | krazykit | tarsius, not sure why you'd need them to compile rockbox? |
| 03:35:03 | tarsius | krazykit: and the reason I'm trying to figure out where this is stored is because it appears my /usr/include/limits.h has a constant defined that is omitted in some other version of gcc |
| 03:35:06 | * | jhMikeS never had a problem in his "right-handed mode". |
| 03:35:38 | Llorean | jhMikeS: Left handed, the Power button is underneath my thumb and requires a rather sharp bend. |
| 03:35:42 | krazykit | jhMikeS, it's kind of inconvenient left-handed though |
| 03:35:57 | jhMikeS | e200 is kinda bad left handed. the thumb strains to reach "Menu"/Power then |
| 03:36:15 | tarsius | krazykit: OH, to clarify... I'm not trying to cross-compile... I need a x86 version of lsusb so I can check to see that my Sansa c140 is connected in "recovery mode" |
| 03:36:34 | Llorean | jhMikeS: That's one of the things I addressed with my new button map. |
| 03:36:43 | jhMikeS | I use whatever hand works best on a target. |
| 03:36:44 | Llorean | Menu on "Down" isn't ideal, but it's still nicer. |
| 03:36:58 | JdGordon | I still dont see why we cant make it an option so everyone can be happy |
| 03:36:58 | krazykit | tarsius, are you sure usbutils will even compile in cygwin? they might be the place to ask for something like that |
| 03:37:09 | tarsius | krazykit: ... as per directions for using the tcctool to upload test firmware to a TCC77x-based device |
| 03:37:26 | Llorean | JdGordon: "No keymap options" isn't my policy, and I'm not going to arbitrarily break that one. |
| 03:37:39 | jhMikeS | Most devices are righty-optimized with the physical layout. |
| 03:37:39 | krazykit | ah, see, i'm not really familiar enough with cygwin, as i use linux primarily |
| 03:38:11 | Llorean | jhMikeS: Oddly enough, the only one of mine that physically is rightly oriented is the Archos. |
| 03:38:15 | tarsius | krazykit: i will check, but as for now, i've done extensive searching and haven't found out what's wrong. what i could really use is a tip as to how to override the gcc default include path |
| 03:38:30 | Llorean | All the others are symmetrical enough, and in the case of the Sansa it's the keymap rather than the buttons themselves that really favours righties. |
| 03:38:48 | krazykit | tarsius, does specifying INCLUDE="/your/path" gcc not do it? |
| 03:39:12 | tarsius | krazykit: ...because if i simply use -I/usr/include, gcc eliminates it "because it's repeated" and keeps the original order |
| 03:39:13 | jhMikeS | you know, I think buttons are more physically reachable on everything I have using righty-mode. |
| 03:39:44 | tarsius | krazykit: i believe i tried that variable as well as many other possibilities... let me try again right now |
| 03:39:51 | Llorean | jhMikeS: Odd, I think the Gigabeat and H100 are much more usable lefty, just because my fingers wrap to the side buttons very nicely |
| 03:39:53 | jhMikeS | nope, jukebox doesn't matter |
| 03:40:47 | tarsius | krazykit: it did not work |
| 03:40:56 | jhMikeS | thumb operation is optimized I guess. the rec buttons are often placed to use fingers. |
| 03:41:32 | jhMikeS | 3g doesn't matter...but that's apple's hyperergonomics |
| 03:41:54 | tarsius | krazykit: thanks anyway for your help |
| 03:42:46 | * | Llorean leaves for real, will read the logs |
| 03:43:25 | | Join xys [0] (n=xys@63-224-211-9.spkn.qwest.net) |
| 03:43:32 | * | jhMikeS won't sit here talking to the virtual breeze then :) |
| 03:44:11 | * | JdGordon is still here...! |
| 03:45:08 | | Quit xys (Connection reset by peer) |
| 03:46:21 | | Part tarsius |
| 04:00 |
| 04:01:21 | | Join Myphton [0] (i=477e0498@gateway/web/cgi-irc/labb.contactor.se/x-a6798ec8b3decc33) |
| 04:03:01 | Myphton | connect |
| 04:03:57 | | Quit Myphton (Client Quit) |
| 04:04:06 | | Join Myphton [0] (i=477e0498@gateway/web/cgi-irc/labb.contactor.se/x-ad59fed9dd7d0494) |
| 04:05:06 | Myphton | hey guys, is there anyone who can help me install the rock box bootloader manually on my iPod Mini? |
| 04:05:27 | Myphton | the rbutil wont install the bootloader, v1.0.2 |
| 04:06:45 | homielowe | Myphton: http://download.rockbox.org/manual/rockbox-ipodmini2g/rockbox-build.html |
| 04:07:02 | | Join ramon8 [0] (i=DontFuCk@71.146.171.23) |
| 04:08:17 | Myphton | thanks a lot =) |
| 04:09:00 | homielowe | Myphon: Your welcome ;) |
| 04:10:07 | Myphton | lol, now i got another problem |
| 04:10:38 | Myphton | the ipodpatcher.exe cannot install the bootloader. it cant detect my ipod |
| 04:11:29 | Myphton | any solution? |
| 04:12:55 | safetydan | Myphton: have you searched the forums? |
| 04:14:55 | Myphton | i never have any luck in them. i could take another look. is there any way of having the file just being purely the bootloader though? and just install it by putting it in the directory it needs to be in, with in the rockbox directory? |
| 04:17:10 | krazykit | that isn't how the bootloader works. if ipodpatcher.exe doesn't work, it's better to figure out WHY it isn't working |
| 04:17:43 | | Join webguest39 [0] (i=4ca81f01@gateway/web/cgi-irc/labb.contactor.se/x-bae5901653938e50) |
| 04:18:06 | safetydan | Myphton: I'm not familiar with the ipod installation process, but does it require that your ipod be in disk mode? |
| 04:18:06 | webguest39 | Hey Guys |
| 04:19:09 | *** | Saving seen data "./dancer.seen" |
| 04:20:49 | | Join Mouser_X [0] (i=cf9bb003@gateway/web/cgi-irc/ircatwork.com/x-3f4b3669faf5e99b) |
| 04:22:06 | | Quit Soap_ (Read error: 110 (Connection timed out)) |
| 04:24:06 | Myphton | its in disk mode yes. |
| 04:24:14 | | Quit Myphton ("CGI:IRC") |
| 04:26:49 | | Quit miepchen^schlaf (Read error: 110 (Connection timed out)) |
| 04:26:58 | | Join miepchen^schlaf [0] (n=hihi@p54BF683A.dip.t-dialin.net) |
| 04:28:00 | Mouser_X | How does Rockbox handle large MP3s? I was listening to a 136 MB (1:56.53) MP3 yesterday, and my Gigabeat died... It was a freshly charged battery that morning. Normally, I can get at *least* 12 hours off of one charge, but yesterday, it lasted about 6 hours... |
| 04:28:18 | safetydan | Mouser_X, how recent is your build? |
| 04:28:34 | Llorean | Large MP3s should be no different than lots of small ones... |
| 04:28:50 | safetydan | generally it should do the right thing and read in the mp3 as it needs it |
| 04:29:12 | Mouser_X | safetydan: It's from shortly after MoB stuff was fixed, so that transitioning between difference codecs worked. |
| 04:29:47 | Mouser_X | I would have tested on a new build, but my laptop no longer has internet access (where the build system is installed). |
| 04:30:03 | webguest39 | how do you install the Evil G's build for the themes? www.rockbox-themes.org |
| 04:30:03 | Llorean | Why didn't you just download a build? |
| 04:30:29 | Mouser_X | Llorean: I use FS #7331 and 5241 |
| 04:30:39 | Mouser_X | (GBS and MOD codecs) |
| 04:30:48 | Llorean | Mouser_X: And here's the bit where I remind you that you NEED to be testing with official builds. |
| 04:31:27 | Llorean | Especially since you'd have been downloading a new build just for testing that bug... |
| 04:32:18 | Mouser_X | I suppose so... |
| 04:32:22 | safetydan | Mouser_X, exact SVN revisions are needed since mob is actively under development |
| 04:32:27 | Llorean | webguest39: See the "unsupported builds" section of the forum. And remember, they're not supported. |
| 04:33:32 | webguest39 | Ok. its unsupported? that means that it might mess my ipod up? |
| 04:34:11 | Llorean | It just means "we don't provide support for it." |
| 04:34:14 | Llorean | It's not our software. |
| 04:34:35 | | Join psycho_maniac [0] (i=psycho_m@ppp553.hk.centurytel.net) |
| 04:34:48 | Mouser_X | safetydan: Rockbox (the one currently on my Gigabeat) says "Version: r15330m-071027" |
| 04:35:11 | Mouser_X | However, I will probably download a new build (unpatched), and try it again tomarrow. |
| 04:35:28 | Mouser_X | (I have 2 more 130+ MB MP3s I'd like to go through.) |
| 04:35:31 | webguest39 | Oh ok thank you Llorean. Your like the only person that helps me. Thats Exactly why i love you. |
| 04:36:16 | psycho_maniac | what does the M mean? i have that also on my patched build. just curious |
| 04:36:25 | krazykit | it means Modified |
| 04:36:42 | Mouser_X | Interesting. |
| 04:37:19 | * | karashata has seen M occasionally show up on the official builds too |
| 04:37:24 | | Quit z35 (Read error: 110 (Connection timed out)) |
| 04:37:38 | Mouser_X | I've never bothered looking. |
| 04:38:08 | psycho_maniac | i dont notice much either. |
| 04:38:33 | | Quit midgey (Read error: 104 (Connection reset by peer)) |
| 04:38:48 | webguest39 | Are the unoffical builds only for the 5g? |
| 04:39:06 | | Join xys [0] (n=xys@63-224-211-9.spkn.qwest.net) |
| 04:41:14 | psycho_maniac | unofficial builds are for anyplayer you want as you can make them yourself |
| 04:41:34 | | Quit Thundercloud (Remote closed the connection) |
| 04:42:17 | | Quit TotallyInfected () |
| 04:42:50 | webguest39 | Oh. But i dont really know how to make them myself. I have a 80 gig ipod vid 5.5g. will one of the builds work? yes im a newb. thats is why im asking all these questions |
| 04:43:18 | | Join TotallyInfected [0] (n=ebola@pool-141-151-2-130.phlapa.east.verizon.net) |
| 04:43:41 | safetydan | Mouser_X, so it's 50 changes behind the latest then |
| 04:44:37 | psycho_maniac | any build will work if its made for your player. people make them on the rockbox forums |
| 04:44:54 | Mouser_X | Guess so. I've just put the newest one on right now. |
| 04:45:48 | safetydan | Mouser_X: there's been several buffer related fixes since the build you were using |
| 04:46:33 | Mouser_X | Yes, I noticed. Hopefully they make a difference for tomorrow. |
| 04:47:32 | webguest39 | oh ok thank you. im looking at a build in the forums. its the evilg fusion build. but it says its 60 gig. can i still use it on my ipod? and its my generation |
| 04:49:25 | | Join JdGordon1924 [0] (n=Miranda@c210-49-113-143.smelb1.vic.optusnet.com.au) |
| 04:50:19 | | Quit JdGordon1924 (Client Quit) |
| 04:51:18 | | Quit webguest39 ("CGI:IRC (EOF)") |
| 04:52:20 | | Join ATravelil [0] (n=ATG@pool-71-254-21-189.clppva.east.verizon.net) |
| 05:00 |
| 05:05:17 | | Quit ATravelingGeek (Network is unreachable) |
| 05:05:17 | | Nick ATravelil is now known as ATravelingGeek (n=ATG@pool-71-254-21-189.clppva.east.verizon.net) |
| 05:08:59 | | Quit xys ("ã•ã‚ˆã†ãªã‚‰") |
| 05:15:24 | | Quit bb (Nick collision from services.) |
| 05:15:29 | | Join bb_ [0] (n=bb@unaffiliated/bb) |
| 05:27:29 | | Quit flacoste (Remote closed the connection) |
| 05:44:35 | | Quit BHSPitMonkey (Remote closed the connection) |
| 05:45:26 | | Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) |
| 05:49:43 | | Join ptw419 [0] (i=ptw419@66-90-157-228.dyn.grandenetworks.net) |
| 05:53:53 | | Join advcomp2019_ [0] (n=advcomp2@unaffiliated/advcomp2019) |
| 05:54:11 | | Quit advcomp2019 (Nick collision from services.) |
| 05:54:13 | | Nick advcomp2019_ is now known as advcomp2019 (n=advcomp2@unaffiliated/advcomp2019) |
| 05:54:59 | | Quit jhMikeS (Nick collision from services.) |
| 05:55:05 | | Join jhMikeS [0] (n=jethead7@rockbox/developer/jhMikeS) |
| 06:00 |
| 06:01:46 | | Quit a11313 ("Java user signed off") |
| 06:07:58 | | Quit tedr0ck (Read error: 104 (Connection reset by peer)) |
| 06:14:37 | | Quit TotallyInfected () |
| 06:18:37 | | Quit DogBoy ("Leaving") |
| 06:19:10 | *** | Saving seen data "./dancer.seen" |
| 06:24:34 | | Join colin_ [0] (n=colin@host-155-47-107-208.midco.net) |
| 06:32:28 | | Quit alienbiker99 (Read error: 110 (Connection timed out)) |
| 06:32:42 | | Join alienbiker99 [0] (n=alienbik@ool-44c126d4.dyn.optonline.net) |
| 06:33:52 | | Quit keanu (Read error: 110 (Connection timed out)) |
| 06:35:03 | | Quit Mouser_X ("CGI:IRC (EOF)") |
| 06:35:24 | | Join TotallyInfected [0] (n=ebola@pool-141-151-2-130.phlapa.east.verizon.net) |
| 06:41:42 | | Join Mouser_X [0] (i=cf9bb003@gateway/web/cgi-irc/ircatwork.com/x-245cabf60c646409) |
| 06:45:33 | | Join keanu [0] (n=keanu@unaffiliated/keanu) |
| 06:45:37 | | Quit lazka (Remote closed the connection) |
| 06:58:45 | | Quit karashata ("Leaving.") |
| 07:00 |
| 07:03:48 | | Join SirFunk [0] (n=Sir@206-159-155-246.netsync.net) |
| 07:10:32 | | Join bluey [0] (n=bluey@dslb-088-073-068-148.pools.arcor-ip.net) |
| 07:11:33 | lostlogic | gah, I hate to admit this to myself because I've been telling people for a long time that ogg q7 or q8 is hard to distinguish from lossless... but I can definitely distinguish :( |
| 07:12:48 | | Quit ptw419 (Read error: 110 (Connection timed out)) |
| 07:12:52 | | Quit bluey (Client Quit) |
| 07:14:49 | Llorean | Is it just on a specific track though? |
| 07:15:06 | Llorean | With some samples, it can be really easy to distinguish. |
| 07:16:03 | * | scorche wonders why lostlogic isnt in -community ;) |
| 07:18:33 | lostlogic | Llorean: it was the intro to a Three Days Grace that I compared because it has a hard and transient-ful sound to it |
| 07:18:50 | lostlogic | it got boomy and washed out in the lossy version |
| 07:19:07 | lostlogic | scorche: my attention is limitted enough ;) |
| 07:19:09 | | Quit billytwowilly (Read error: 110 (Connection timed out)) |
| 07:19:15 | scorche | pfft! |
| 07:20:06 | | Join billytwowilly [0] (n=chris@S01060016b649355d.ed.shawcable.net) |
| 07:27:08 | | Join colin__ [0] (n=colin@host-155-47-107-208.midco.net) |
| 07:29:20 | | Part toffe82 |
| 07:30:37 | | Quit colin_ (Read error: 110 (Connection timed out)) |
| 07:31:10 | | Quit Isolinear () |
| 07:32:18 | | Quit psycho_maniac (" HydraIRC -> http://www.hydrairc.com <- \o/") |
| 07:35:06 | | Join colin_ [0] (n=colin@host-155-47-107-208.midco.net) |
| 07:35:18 | | Part colin_ |
| 07:35:59 | | Join Shaid` [0] (i=shaid@203-214-44-134.dyn.iinet.net.au) |
| 07:36:33 | | Join DogBoy [0] (n=john@66-101-59-100-static.dsl.oplink.net) |
| 07:42:33 | | Join xys [0] (n=xys@74.85.75.145) |
| 07:43:48 | xys | hi, I've noticed that during mp3 playback, my 5g ipod takes less energy to run compared to ogg files. is this because of the codecs? |
| 07:44:43 | lostlogic | xys: in short, yes |
| 07:45:10 | lostlogic | how are you comparing energy? |
| 07:45:12 | lostlogic | battery life? |
| 07:45:16 | xys | yes |
| 07:45:30 | lostlogic | both file size and decoding cpu cycles will impact total battery performance on a file |
| 07:47:23 | | Quit colin__ () |
| 07:47:30 | xys | I talked to people from ipodlinux today and found out that the second processor is used to handle all the DMA stuff so even if we got two cores running, it wouldn't help the battery life. Is this also true for rockbox? |
| 07:48:27 | lostlogic | as far as I know, we only use the second core in mpegplayer at this point. from what amiconn and others have told me though, we also would not see a big change in battery life from using it more. |
| 07:50:21 | xys | so I guess lengthening the ipod's battery life depends on how the hard drive gets handled now |
| 07:50:40 | Llorean | That's a rather strange leap. |
| 07:50:45 | | Quit Shaid (Read error: 110 (Connection timed out)) |
| 07:50:46 | | Nick Shaid` is now known as Shaid (i=shaid@203-214-44-134.dyn.iinet.net.au) |
| 07:51:42 | amiconn | lostlogic: It would help a bit, but the real power suckers are those I mentioned |
| 07:52:06 | amiconn | Using both cores is of course still desirable |
| 07:53:04 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 07:58:18 | xys | I also saw something about a power management unit (Philips PCF50607 PMU), but is that just for connecting between the board and the battery? |
| 08:00 |
| 08:01:56 | | Quit lt_smooth420 (Remote closed the connection) |
| 08:09:50 | | Quit FOAD (Read error: 110 (Connection timed out)) |
| 08:09:50 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 08:12:29 | | Join hannesd_ [0] (n=light@gate-hannes-tdsl.imos.net) |
| 08:16:36 | | Quit xys ("ã•ã‚ˆã†ãªã‚‰") |
| 08:16:41 | | Join bertrik [0] (n=Bertrik_@031-020-045-062.dynamic.caiway.nl) |
| 08:16:50 | | Quit BigBambi (Remote closed the connection) |
| 08:19:14 | *** | Saving seen data "./dancer.seen" |
| 08:22:10 | | Join Dolphin91 [0] (i=423a97a1@gateway/web/cgi-irc/labb.contactor.se/x-80230e8dad70173c) |
| 08:22:13 | Dolphin91 | hello |
| 08:23:02 | Dolphin91 | I'm setting up a separate noob help site, and I'm testing apache server, tell me if http://169.254.11.119 works. |
| 08:23:34 | * | JdGordon thinks Dolphin91 is lost |
| 08:23:41 | * | Mouser_X agrees. |
| 08:24:00 | Mouser_X | This is *not* #apache-test |
| 08:24:02 | Dolphin91 | Why? |
| 08:24:08 | Dolphin91 | oh |
| 08:24:11 | Dolphin91 | sorry |
| 08:24:13 | Mouser_X | This is #rockbox. |
| 08:24:16 | Dolphin91 | ok |
| 08:24:20 | | Quit Dolphin91 (Client Quit) |
| 08:24:30 | Mouser_X | *minus "." |
| 08:24:59 | | Join Rob222241 [0] (n=Miranda@p54B13FAB.dip.t-dialin.net) |
| 08:26:35 | | Quit hannesd (Read error: 110 (Connection timed out)) |
| 08:26:36 | | Nick hannesd_ is now known as hannesd (n=light@gate-hannes-tdsl.imos.net) |
| 08:40:52 | | Quit Ebert () |
| 08:41:27 | | Quit Rob2222 (Read error: 110 (Connection timed out)) |
| 08:47:39 | | Quit Mouser_X ("CGI:IRC 0.5.9 (2006/06/06)") |
| 08:48:56 | | Join colin_ [0] (n=colin@host-155-47-107-208.midco.net) |
| 08:49:24 | | Join Isolinear [0] (n=A@c-76-105-254-119.hsd1.or.comcast.net) |
| 09:00 |
| 09:04:27 | | Join ivan`` [0] (n=ivan`@adsl-71-142-217-66.dsl.scrm01.pacbell.net) |
| 09:04:48 | | Quit colin_ ("http://suffering.no-ip.org/itunescatalog/index.php") |
| 09:08:34 | | Quit bertrik (Read error: 104 (Connection reset by peer)) |
| 09:09:00 | | Quit ivan` (Nick collision from services.) |
| 09:09:03 | | Nick ivan`` is now known as ivan` (n=ivan`@adsl-71-142-217-66.dsl.scrm01.pacbell.net) |
| 09:10:35 | | Join Zagor_ [0] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) |
| 09:11:47 | | Join safetydan_ [0] (n=safetyda@rockbox/developer/safetydan) |
| 09:12:56 | | Nick Zagor_ is now known as Zagor (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) |
| 09:13:17 | | Join pixelma [0] (i=pixelma@rockbox/staff/pixelma) |
| 09:15:57 | | Join petur [0] (n=petur@rockbox/developer/petur) |
| 09:17:42 | | Quit ramon8 (Read error: 110 (Connection timed out)) |
| 09:25:10 | | Quit joshin (Read error: 110 (Connection timed out)) |
| 09:27:39 | | Join pill [0] (i=pill@sloth.shellfx.net) |
| 09:47:08 | | Join ddalton [0] (n=Daniel@124-168-105-67.dyn.iinet.net.au) |
| 09:47:28 | | Part ddalton |
| 09:54:51 | | Join pondlife [0] (n=Steve@rockbox/developer/pondlife) |
| 09:56:47 | | Join davina [0] (n=davina@cpc1-sout6-0-0-cust616.sotn.cable.ntl.com) |
| 09:57:15 | | Part ivan` |
| 10:00 |
| 10:02:09 | | Quit TotallyInfected () |
| 10:15:40 | pondlife | Nico_P: When you get in, you might want to commit http://www.rockbox.org/tracker/task/8053 |
| 10:19:16 | *** | Saving seen data "./dancer.seen" |
| 10:27:22 | Bagder | the c200 version is downloaded roughly as much as the h10 |
| 10:27:46 | Bagder | and roughly has much as the h120 |
| 10:27:52 | Bagder | as much |
| 10:28:03 | Bagder | 2700-2800 times so far in october |
| 10:29:23 | Bagder | both ipod video versions => 32000 times |
| 10:29:53 | pondlife | Could you put running stats on the site somewhere? |
| 10:30:03 | pondlife | Past 30 days total maybe? |
| 10:30:35 | Bagder | hm, yes that would be cool but will take some scripting |
| 10:30:55 | linuxstb | Which downloads are these - the current builds? |
| 10:31:10 | Bagder | yes, current only, based on build.rockbox.org logs |
| 10:32:12 | JRoT | badger what are the satts for the sansa E series |
| 10:32:19 | Bagder | ~18000 |
| 10:32:25 | JRoT | :D |
| 10:32:26 | linuxstb | Can you tell how many were via rbutil? |
| 10:32:57 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 10:33:43 | Bagder | good question |
| 10:35:51 | Bagder | I can't see any user-agent in the logs that seems to indicate rbutil |
| 10:37:26 | | Join Thundercloud [0] (n=thunderc@resnet01.nat.lancs.ac.uk) |
| 10:38:12 | amiconn | Imho it might also be interesting to see total downloads per target, split into release + daily + current |
| 10:39:04 | Bagder | I don't have daily logs since they're spread out on three servers I don't admin myself |
| 10:40:00 | Bagder | rockbox 2.5 for the player: 246 times |
| 10:40:12 | Bagder | for the recorder: 137 |
| 10:40:28 | amiconn | Hmm, and current builds for those? |
| 10:40:33 | Bagder | the installer 1914 times |
| 10:40:50 | * | amiconn thinks we should remove the 2.5 release |
| 10:41:09 | Bagder | current player 800 downloads |
| 10:41:23 | Bagder | current recorder 670 + recorder8mb 350 |
| 10:41:35 | amiconn | It's very outdated compared to current, has quite a number of known bugs etc |
| 10:41:49 | | Join LinusN [0] (i=linus@gateway/web/cgi-irc/labb.contactor.se/x-77475ee3c86d3aee) |
| 10:45:34 | safetydan_ | If I haven't posted this before, this is an awesome collection bit twiddling hacks http://graphics.stanford.edu/~seander/bithacks.html |
| 10:58:00 | | Join joshin [0] (n=joshin@VDSL-130-13-9-67.PHNX.QWEST.NET) |
| 10:58:23 | | Quit Thundercloud (Remote closed the connection) |
| 11:00 |
| 11:01:38 | | Join Weiss [0] (i=taw27@pip.srcf.societies.cam.ac.uk) |
| 11:05:08 | | Join ender` [0] (i=krneki@84-255-206-8.static.t-2.net) |
| 11:07:32 | | Quit Bagder (Read error: 110 (Connection timed out)) |
| 11:08:55 | | Join Bagder [0] (n=daniel@rockbox/developer/bagder) |
| 11:11:02 | | Quit Zagor ("Client exiting") |
| 11:11:21 | | Join Zagor [0] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) |
| 11:11:52 | | Join Shaid` [0] (i=shaid@203-214-44-134.dyn.iinet.net.au) |
| 11:12:28 | | Nick bb_ is now known as bb (n=bb@unaffiliated/bb) |
| 11:23:36 | | Join spiorf [0] (n=spiorf@host13-223-dynamic.1-79-r.retail.telecomitalia.it) |
| 11:30:26 | | Quit Shaid (Read error: 110 (Connection timed out)) |
| 11:30:27 | | Nick Shaid` is now known as Shaid (i=shaid@203-214-44-134.dyn.iinet.net.au) |
| 11:30:44 | | Quit in-jane (Read error: 104 (Connection reset by peer)) |
| 11:30:55 | | Join in-jane [0] (i=jane@ulko.kuori.org) |
| 11:31:22 | | Join Thundercloud [0] (n=thunderc@resnet02.nat.lancs.ac.uk) |
| 11:32:26 | | Join stewball [0] (n=WTFOMGBB@91.106.247.206) |
| 11:34:42 | | Quit safetydan (Read error: 110 (Connection timed out)) |
| 11:35:20 | | Join Daniel_S [0] (i=57b0e104@gateway/web/cgi-irc/labb.contactor.se/x-3f217d9357099867) |
| 11:36:42 | | Quit J3TC- (Read error: 113 (No route to host)) |
| 11:38:56 | | Quit pixelma (" "reboot"") |
| 11:44:29 | | Join pixelma [0] (i=pixelma@rockbox/staff/pixelma) |
| 11:47:27 | | Join barrywardell [0] (n=barrywar@dhcp-892b9b55.ucd.ie) |
| 11:47:54 | | Join advcomp2019_ [0] (n=advcomp2@unaffiliated/advcomp2019) |
| 11:49:59 | | Join Bagder_ [0] (n=daniel@1-1-5-26a.hud.sth.bostream.se) |
| 12:00 |
| 12:00:08 | | Quit Thundercloud (Remote closed the connection) |
| 12:00:55 | | Join crashd [0] (i=foobar@lostnode.org) |
| 12:02:10 | | Join moos [0] (i=moos@m147.net81-66-159.noos.fr) |
| 12:03:15 | | Join AlexC [0] (n=AlexC@dragnet2034196172.dragnet.com.au) |
| 12:05:36 | | Quit advcomp2019 (Read error: 110 (Connection timed out)) |
| 12:05:53 | pondlife | Hmm, who's Alessio Lenzi on IRC? |
| 12:06:32 | pondlife | That last commit seems rather arbitrary to me, I'd like to know the logic behind it. |
| 12:06:56 | pondlife | I mean the reordering of the info screen. |
| 12:07:27 | | Quit Bagder (Read error: 110 (Connection timed out)) |
| 12:11:57 | | Join Thundercloud [0] (n=thunderc@resnet02.nat.lancs.ac.uk) |
| 12:14:22 | pixelma | I doubt that he ever was around here, can't remember someone (or some nick) I could relate to him at least |
| 12:14:55 | linuxstb | Nor me... His SVN username is lenzone10 and I don't recognise that. |
| 12:15:41 | pondlife | Not a biggie, but I would like to understand why the new order is better |
| 12:16:10 | pondlife | I preferred it with version at the top for some reason |
| 12:16:16 | | Nick parafin|away is now known as parafin (i=parafin@paraf.in) |
| 12:16:41 | pixelma | haven't updated so far, what is now on top? |
| 12:17:07 | linuxstb | Battery |
| 12:17:09 | pondlife | Battery |
| 12:18:11 | linuxstb | Is it just that blind users want an easy way to hear the battery status? |
| 12:19:20 | *** | Saving seen data "./dancer.seen" |
| 12:19:51 | pondlife | Well that saves them 3 keypresses for that... |
| 12:20:20 | Zagor | he was approved jun 6 for updating the italian lang file |
| 12:20:27 | preglow | lenzi is the italian lang file maintainer |
| 12:20:36 | preglow | yes... |
| 12:21:19 | Zagor | reordering menus without discussion is a bit outside that, I'd say |
| 12:23:39 | preglow | indeed |
| 12:24:03 | preglow | any ui changes should be discussed unless you're clearly some kind of ui genious :> |
| 12:24:19 | pixelma | yeah, it surprised me that he committed something else and that he didn't ask about the reordering (or posted a patch to the tracker) before - or even showed up in IRC |
| 12:24:55 | pondlife | On another topic, could the MajorChanges wiki be linked from the home page again, or was that removed deliberately? |
| 12:25:11 | pondlife | (or is it there, and I missed it?) |
| 12:26:09 | Zagor | no it's not there. I'll add a link somewhere near the "project news" box |
| 12:26:46 | pondlife | Maybe a little link, like the "Last four weeks" one? |
| 12:27:31 | pondlife | Although I think I'd prefer it to the "news" anyway... |
| 12:28:12 | Zagor | yeah maybe we should replace the news box with content from MajorChanges. |
| 12:28:13 | * | pondlife is stirring up trouble everywhere today... |
| 12:28:39 | pondlife | They should be merged really |
| 12:29:10 | rasher | Zagor: it's not terribly difficult to parse the raw MajorChanges page. I do it for rasher.dk/rockbox/majorchanges.php">http://rasher.dk/rockbox/majorchanges.php |
| 12:31:22 | markun | Zagor: ptw419 is planning to read the OTG registers, but needs to charge his player first |
| 12:31:29 | markun | (Gigabeat S) |
| 12:31:36 | Zagor | ah, nice! |
| 12:31:43 | | Join c0utta [0] (i=3aa0a089@gateway/web/cgi-irc/labb.contactor.se/x-32e9be1926fe1d3f) |
| 12:35:49 | | Join J3TC- [0] (n=jetc123@dhcp76-117.njit.edu) |
| 12:35:51 | | Quit safetydan_ ("Leaving") |
| 12:39:18 | | Quit Daniel_S ("CGI:IRC (EOF)") |
| 12:41:59 | | Join joop [0] (n=jetc123@dhcp76-117.njit.edu) |
| 12:42:05 | | Quit J3TC- (Nick collision from services.) |
| 12:42:08 | | Nick joop is now known as J3TC- (n=jetc123@dhcp76-117.njit.edu) |
| 12:42:54 | linuxstb | Speaking of the info screen, I'm just looking at it on my Gigabeat, and the time is displayed in the info screen, but the time isn't set - it's −−:−− in the status bar... |
| 12:43:17 | linuxstb | It also only updates when something else causes a screen refresh, not every second as I would expect. |
| 12:44:28 | pixelma | if I remember correctly there were a few reports (in the forums) of time vanishing in the statusbar on Gigabeats |
| 12:45:08 | pondlife | I've seen that on my H340 |
| 12:45:36 | pondlife | I may have been testing the wake-up alarm patch at the time |
| 12:45:44 | pondlife | But it never recurred. |
| 12:46:05 | linuxstb | I'm not complaining that it's −−:−− in the status bar, but that it's shown in the info screen - the Gigabeat loses time whenever you power-cycle with the battery switch, and I never bother to reset it. |
| 12:46:51 | linuxstb | It seems the status bar code calls valid_time(), and displays −−:−− if invalid, but the info screen doesn't. |
| 12:47:19 | pondlife | I assumed it was a flat battery issue, but maybe it's a bug in the H300 wake-up alarm patch... |
| 12:47:38 | markun | linuxstb: I've also seen the time go to −−:−− without a power-cycle |
| 12:47:57 | markun | but don't know what triggered it |
| 12:47:58 | pondlife | markun: Which target? |
| 12:48:03 | markun | Gigabeat F40 |
| 12:49:03 | amiconn | i2c problems, perhaps |
| 12:49:26 | linuxstb | On yet another subject, does anyone agree that it seems odd for the credits screen to be hidden behind "Version" in the system menu? Couldn't we just rename "Version" to "Credits"? |
| 12:50:55 | pondlife | Why is version in two places...? |
| 12:51:05 | pondlife | Info + Version/Credits |
| 12:51:23 | pondlife | Rockbox Info could be renamed System Info, mayeb |
| 12:51:31 | linuxstb | I was thinking the same. I would be happy to remove the splash screen from the credits. |
| 12:51:32 | | Quit spiorf (Remote closed the connection) |
| 12:52:01 | pondlife | Does credits need to be in the menu? Why not just as a plugin? |
| 12:52:13 | linuxstb | I think it deserves a menu item. |
| 12:52:52 | pondlife | Llorean: Did you make any progress on the menu revision project? |
| 12:52:57 | | Join The-Compiler [0] (i=The-Comp@143-48.77-83.cust.bluewin.ch) |
| 12:53:39 | pondlife | I get annoyed by the two "System" entries (in main and General Settings)... |
| 12:53:54 | pondlife | Only very mildly annoyed, I should add... |
| 12:54:17 | The-Compiler | Hi |
| 12:54:19 | linuxstb | BTW, now that the info screen is a list, could the fsinfo update only be made if you press select on the Free: line? |
| 12:54:37 | pondlife | Good idea. Not with RIGHT at all |
| 12:54:50 | linuxstb | Or maybe made a more obvious feature elsewhere... |
| 12:55:04 | pondlife | In a plugin? |
| 12:55:06 | linuxstb | It feels like an easter egg at the moment... |
| 12:55:52 | pondlife | If we could split the debug menu into "Software" and "Hardware" info, then perhaps the hardware stuff could all go into a plugin and out of the core? |
| 12:56:56 | | Quit barrywardell () |
| 12:57:12 | pondlife | That wouldn't need the plugin API bloating, hopefully. |
| 12:57:33 | | Quit J3TC- (".•«UPP»•.") |
| 12:59:33 | pondlife | What's the H300 button for USB charge (and not connect)? Used to be REC, didn't it? |
| 13:00 |
| 13:06:32 | | Join ramon8 [0] (i=DontFuCk@adsl-71-146-141-50.dsl.pltn13.sbcglobal.net) |
| 13:15:54 | amiconn | A-B |
| 13:16:06 | amiconn | And hardware debug outside the core doesn't make sense imo |
| 13:19:12 | preglow | why not? |
| 13:19:34 | pondlife | I was thinking it might be a sensible way to save binsize, but I suppose you need a working plugin loader first. |
| 13:19:47 | pondlife | It's hardly used often by most users. |
| 13:20:12 | preglow | this is a pure developer thing, of no use to users, as opposed to the other stuff in the debug menu |
| 13:20:19 | preglow | so i see no point in putting it in the core |
| 13:20:24 | amiconn | If something isn't working and you need the debug stuff, it is very possible that disk loading doesn't work, i.e. plugins can't be loaded |
| 13:21:29 | preglow | you're not going to start probing io pins when something doesn't work |
| 13:21:33 | | Quit AlexC (Read error: 110 (Connection timed out)) |
| 13:21:42 | preglow | this seems like an re thing to me |
| 13:21:46 | amiconn | And it's already useful when trying to narrow down why something doesn't work on a particular box owned by a user |
| 13:22:11 | preglow | amiconn: i'm not saying our debug screen stuff should go in a plugin, but this gpio tweaking thing is a ok as a plug, i think |
| 13:22:17 | amiconn | I mean especially ports debug |
| 13:22:37 | preglow | it doesn't work for the kind of debugging we want users to do anyway |
| 13:24:07 | amiconn | ? |
| 13:24:57 | | Join donutman25 [0] (n=chatzill@65.75.87.48) |
| 13:45:53 | | Join Daniel_S [0] (i=57b0e104@gateway/web/cgi-irc/labb.contactor.se/x-50d9163fb50c644e) |
| 13:45:54 | | Quit Daniel_S (Client Quit) |
| 13:48:32 | | Join Nico_P [0] (n=nicolas@rockbox/developer/NicoP) |
| 13:50:53 | | Join J3TC- [0] (n=jetc123@dhcp73-1.njit.edu) |
| 13:53:00 | Zagor | hmm.. my build is now freezing on boot while showing the logo, before any of my code ever runs. anyone got suggestions what to look for? |
| 13:54:10 | J3TC- | What patches did you put? |
| 13:54:40 | Zagor | no patches, only my own usb work |
| 14:00 |
| 14:01:53 | pixelma | would wild guessing do you any good? |
| 14:05:59 | | Join MajorC [0] (i=redeem@host183-38.bornet.net) |
| 14:08:29 | | Join webguest24 [0] (i=5b4ca45d@gateway/web/cgi-irc/labb.contactor.se/x-8aec1597b15210f5) |
| 14:09:31 | | Quit webguest24 (Client Quit) |
| 14:11:28 | preglow | Zagor: well, if your code is the only difference... |
| 14:11:36 | preglow | my builds certainly aren't freezing |
| 14:14:12 | | Join Buschel [0] (n=abc@p54A3F728.dip.t-dialin.net) |
| 14:14:38 | JdGordon | amiconn: i've started the info list thing twice now but keep stopping for some reason... ill hopefully have it done tomorow... (might need some nagging actually..) |
| 14:18:58 | Zagor | pixelma: it's boring to guess alone :) |
| 14:19:23 | *** | Saving seen data "./dancer.seen" |
| 14:19:47 | * | pondlife nags JdGordon |
| 14:19:58 | pondlife | Not that I know what you're doing... :) |
| 14:25:29 | JdGordon | :) |
| 14:25:39 | pixelma | Zagor: maybe it's some check if it should reboot to OF? And in case it currently freezes on an SVN build for you too, I got another guess... |
| 14:27:31 | Zagor | thanks for guessing with me :) but I grabbed my senses and stared adding lcd_puts() in the boot, so I've found it now. it turns out my usb_core_exit was called in the boot. |
| 14:29:07 | pixelma | heh! Glad you found it :) |
| 14:31:34 | Zagor | ouch! kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000 |
| 14:34:44 | | Quit J3TC- (Read error: 110 (Connection timed out)) |
| 14:38:11 | | Join nicktastic [0] (n=nick@unaffiliated/nicktastic) |
| 14:38:52 | | Join mf0102 [0] (n=michi@85.127.180.92) |
| 14:40:56 | | Quit Zagor ("Linux usb oops, need to reboot") |
| 14:42:10 | Nico_P | pondlife: I'm about to commit FS #8053 |
| 14:42:27 | Nico_P | looks all good to me |
| 14:42:42 | pondlife | What was last_track used for before MoB? |
| 14:42:54 | Nico_P | apprently, nothing |
| 14:42:55 | pondlife | I thought it might have been misplaced by accident |
| 14:43:00 | pondlife | Ah, ok |
| 14:43:07 | Nico_P | I didn't touch that code with MoB |
| 14:43:21 | pondlife | Nice when the code gets readable enough to spot these things :) |
| 14:44:02 | JdGordon | Nico_P: is it using the ata callbacks to rebuffer? |
| 14:44:29 | Nico_P | JdGordon: what is? this commit isn't the same thing if that's what you're asking |
| 14:44:45 | JdGordon | Mob... |
| 14:44:49 | JdGordon | not that commit |
| 14:46:18 | Nico_P | JdGordon: no, it's not |
| 14:46:27 | JdGordon | ... it should |
| 14:46:39 | JdGordon | its not because of the ata_is_Active() problem with flash tagrtes? |
| 14:46:56 | | Join webguest26 [0] (i=5b4ca45d@gateway/web/cgi-irc/labb.contactor.se/x-de2f58cf89c3c43c) |
| 14:47:04 | Nico_P | yeah there was a problem because of that, but I fixed it |
| 14:47:20 | Nico_P | what do the ata idle callbacks do on flash targets? |
| 14:47:42 | JdGordon | they work.. but the ata_is_Active() call is always false |
| 14:47:52 | amiconn | pondlife: last_track was used for the old tagdb, which was replaced by Slasheri's tagcache later on |
| 14:48:42 | | Quit webguest26 (Client Quit) |
| 14:51:26 | | Join vnl [0] (n=nitin@122.167.19.214) |
| 14:52:00 | | Part vnl |
| 14:57:01 | | Join Zagor [0] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) |
| 14:58:02 | pondlife | Nico_P: Looks like http://www.rockbox.org/tracker/task/8037 is only a problem on flash-based players. |
| 14:58:39 | Nico_P | yeah, problem is I don't have one :( |
| 14:58:57 | pondlife | Perhaps you shouldn't be checking ata_is_active() at all on them? Or maybe it should spoof and return true? |
| 14:59:20 | pondlife | i.e. no cost of spinup means treat it as always active |
| 14:59:21 | Nico_P | I've changed that |
| 14:59:26 | pondlife | Ah, ok |
| 15:00 |
| 15:00:13 | Nico_P | it's still there but there's another check |
| 15:00:38 | pondlife | Does this codec change fall into the Q_BUFFER_HANDLE case? |
| 15:00:59 | Nico_P | I think so |
| 15:01:51 | Nico_P | maybe a sim could be made to behave the same... |
| 15:02:21 | pondlife | Yep, change your #define to be 0, not 1 |
| 15:02:29 | | Join fuome [0] (i=c27f0812@gateway/web/cgi-irc/labb.contactor.se/x-4ecbbaff1fa52e88) |
| 15:02:50 | Nico_P | is that he only relevant difference between flash and HDD? |
| 15:03:12 | pondlife | In buffering.c, I can't see anything else.... |
| 15:03:15 | fuome | Zagor: I'd say it's clearly the crappy kernel code. Not being able to handle such a simple thing as NULL :-))) |
| 15:03:27 | preglow | green delta \o/ |
| 15:03:33 | | Join scorche|w [0] (n=8dc5049d@rockbox/administrator/scorche) |
| 15:04:05 | preglow | Nico_P: btw, how is album art going? any work? |
| 15:04:08 | Nico_P | pondlife: playing an OGG from a different dir just worked |
| 15:04:22 | Nico_P | preglow: not yet. I plan on doing cuesheet before |
| 15:04:24 | LinusN | preglow: what is the status of speex nowadays regarding performance? |
| 15:04:26 | preglow | cool |
| 15:04:40 | Nico_P | and before that I wan to bring MoB bugs down to a minimum |
| 15:05:00 | preglow | LinusN: depends on target, it's faster on coldfire than on arm. right now my test track decodes at 410++% realtime, 32khz, 40~ kbps |
| 15:05:24 | * | Nico_P tries a sansa sim |
| 15:05:25 | LinusN | preglow: any chance of running it with minimal iram usage? |
| 15:05:30 | preglow | Nico_P: all very understandable :P |
| 15:05:35 | amiconn | pondlife: ata_disk_is_active() works correctly on Ondio (but atm that's not relevant to MoB) |
| 15:05:35 | preglow | LinusN: it already uses minimal iram |
| 15:05:45 | LinusN | i.e as a static voice codec to avoid codec swapping |
| 15:06:00 | amiconn | Anyway, no app layer code should check that directly, but rather use the ata callbacks |
| 15:06:08 | preglow | that'd require only wb mode (16 khz), which decodes at around 600%+ |
| 15:06:22 | LinusN | would be awfully nice |
| 15:06:29 | preglow | lemme see how much iram we'd need to maintain that figure |
| 15:06:40 | JdGordon | amiconn: the problem is with async callbacks.. i.e when the callback signals a thread to use the disk |
| 15:08:10 | amiconn | Nico_P: Speaking about MoB bugs - did you see my report regarding playlist position in wps? |
| 15:08:14 | Nico_P | amiconn: how big do you think the benefit of MoB would be on HWCODEC? |
| 15:08:28 | Nico_P | amiconn: I don't think so, when was it? |
| 15:09:01 | | Join japc [0] (n=japc@194.65.5.235) |
| 15:09:44 | preglow | LinusN: it currently uses 11kb iram for all decoder state structs and const data, that can be shaved further down for wb mode only |
| 15:09:48 | preglow | gimme a sec |
| 15:09:55 | | Join in-jane_ [0] (i=jane@ulko.kuori.org) |
| 15:10:57 | Nico_P | amiconn: ah, "the playlist position advances too early"? |
| 15:11:02 | amiconn | yes |
| 15:11:10 | amiconn | Just found that you're aware of that bug |
| 15:11:21 | Nico_P | I know about that. I even tried to fix it, but it broke auto change dir |
| 15:12:10 | Nico_P | the problem is that we have to call playlist_next at the codec track change time, and not the pcm track change time |
| 15:12:42 | preglow | LinusN: 10kb for all needed decoder states in iram, plus const data, how much do we have for the purpose? |
| 15:12:59 | LinusN | i think we can afford 10k |
| 15:13:40 | preglow | LinusN: it's also need some kb of fast stack, though, but i guess we already have that? |
| 15:14:00 | LinusN | i believe so |
| 15:14:37 | preglow | speex allocates all temp stuff from stack, even the variably sized bits |
| 15:14:38 | | Nick Bagder_ is now known as Bagder (n=daniel@1-1-5-26a.hud.sth.bostream.se) |
| 15:14:43 | LinusN | i see |
| 15:15:10 | | Join kugel [0] (i=kugel@unaffiliated/kugel) |
| 15:15:14 | LinusN | i think a static speex codec would be a blessing to reduce complexity in playback.c |
| 15:15:25 | preglow | i don't think i disagree, no... |
| 15:16:14 | | Join in-jane__ [0] (i=jane@ulko.kuori.org) |
| 15:16:41 | amiconn | There is one problem though: switching to speex for voice will break *all* current voice files for swcodec targets *and* the talk clips |
| 15:16:51 | LinusN | amiconn: so? |
| 15:16:54 | preglow | big woop, we're in development |
| 15:17:04 | preglow | if we can improve something, we do so |
| 15:17:12 | jmspeex | preglow: There's actually three options for allocating temp stuff |
| 15:17:23 | preglow | jmspeex: oh, hi! didn't see you here :) |
| 15:17:31 | jmspeex | hi :-) |
| 15:17:33 | | Quit scorche|w ("CGI:IRC (EOF)") |
| 15:17:37 | preglow | jmspeex: yeah, but the varsize stack thing is the best for us |
| 15:18:00 | preglow | alloca would work too, but i like variable-size arrays more |
| 15:18:34 | amiconn | LinusN: Big fat warning is due for blind users, plus the tools to generate voice files and clips need to be adapted to use speexenc for swcodec, but continue using lame for hwcodec |
| 15:18:39 | | Join scorche|w [0] (n=8dc5049d@st.iptel.by) |
| 15:18:51 | jmspeex | preglow: yes of course, C99 are always best −− when you're fortunate enough to have a non-braindead compiler. |
| 15:19:03 | preglow | jmspeex: yep, and we use gcc for absolutely everything |
| 15:19:10 | preglow | jmspeex: that's not saying gcc isn't braindead, of course... |
| 15:19:22 | LinusN | amiconn: of course, but i don't see any real problems with that |
| 15:19:37 | preglow | if we can rid of that nasty codec swapping, we should do it |
| 15:19:45 | preglow | and speex is perfect for a static voice codec, it's small in both code and data |
| 15:19:50 | preglow | also very fast when optimized |
| 15:19:52 | jmspeex | preglow: what format are you currently encoding in? |
| 15:20:13 | preglow | jmspeex: uwb mono vbr, if you're talking about my speex test file |
| 15:20:14 | jmspeex | what codec swapping? |
| 15:20:30 | LinusN | jmspeex: we can only have one codec in memory |
| 15:20:38 | jmspeex | preglow: no, I meant current version of rockbox |
| 15:20:45 | preglow | jmspeex: low bitrate mp3 |
| 15:21:07 | preglow | jmspeex: for legacy reasons, mostly |
| 15:21:09 | jmspeex | LinusN: memory is *that* small? (how small?) |
| 15:21:23 | | Quit in-jane__ (Remote closed the connection) |
| 15:21:26 | LinusN | the static (fast) ram is the scarce resource |
| 15:21:28 | preglow | jmspeex: our first targets had hardware decoders and very little ram |
| 15:21:29 | | Join in-jane__ [0] (i=jane@ulko.kuori.org) |
| 15:21:39 | | Quit in-jane (Read error: 110 (Connection timed out)) |
| 15:22:04 | | Join spiorf [0] (n=spiorf@host216-206-dynamic.14-87-r.retail.telecomitalia.it) |
| 15:22:22 | preglow | jmspeex: it's also partly for legacy reasons, our codecs are stored like plugins on disk, but they're statically linked, so have to be put in the same memory address always |
| 15:22:24 | jmspeex | At least Speex should cause too much pressure on memory. |
| 15:22:31 | | Quit in-jane_ (Read error: 104 (Connection reset by peer)) |
| 15:22:36 | jmspeex | preglow: I assume you're disabling the stdio part of Speex, right? |
| 15:22:41 | preglow | LinusN: just tried 16khz vbr file of good quality, 640% realtime |
| 15:22:49 | LinusN | kewl |
| 15:22:52 | preglow | jmspeex: we wrap most things, yes |
| 15:23:06 | preglow | jmspeex: but our libspeex really isn't modified much at all |
| 15:23:36 | jmspeex | preglow: well, you can disable all the stdio part by adding two comments in os_support.h |
| 15:23:39 | preglow | amiconn: what bitrate do our mp3 talk clips usually end up on? |
| 15:23:54 | amiconn | It's all up to the user |
| 15:24:00 | jmspeex | You can also override the memory allocator from the same file |
| 15:24:07 | preglow | jmspeex: yup, already do it |
| 15:24:15 | preglow | jmspeex: but we don't use dynamic memory alloc anyway |
| 15:24:18 | amiconn | There is just an upper limit for the size of the .talk files |
| 15:24:27 | preglow | amiconn: ok, got a typical value? |
| 15:25:03 | amiconn | nope |
| 15:25:06 | jmspeex | preglow: yes, that's what I meant (replace the calloc() by a fixed allocator). You're aware that memory needs to be cleared, right? |
| 15:25:26 | preglow | jmspeex: not really, but it is anyway |
| 15:25:53 | preglow | jmspeex: everything that is allocated with speex_alloc, i allocate statically from iram, which is cleared |
| 15:25:55 | jmspeex | preglow: well, you need to make sure, other bad things will happen. |
| 15:27:01 | | Quit fuome ("CGI:IRC") |
| 15:27:11 | preglow | LinusN: quite a bit of const data is in iram, i see, we can probably remove what isn't needed for the speex modes we won't use |
| 15:27:48 | LinusN | preglow: goodie |
| 15:29:54 | | Join J3TC- [0] (n=jetc123@dhcp73-1.njit.edu) |
| 15:30:58 | linuxstb | preglow: Have you tested the effect of iram on PP? |
| 15:31:02 | preglow | linuxstb: no |
| 15:31:13 | preglow | linuxstb: my speex work has been pretty focused around coldfire, lately |
| 15:31:17 | preglow | primarily because emac is so much fun :P |
| 15:32:14 | linuxstb | That 410% for your test track is Coldfire/ |
| 15:32:15 | linuxstb | ? |
| 15:32:19 | preglow | yeah |
| 15:32:24 | jmspeex | preglow: If you have a wideband VBR file, pretty much all the modes are possible |
| 15:32:39 | preglow | jmspeex: not the uwb one |
| 15:33:01 | jmspeex | preglow: uwb has no impacct at all on the code/codebook size |
| 15:33:13 | amiconn | preglow: Just keep in mind that on PP5002, iram is much more important than on PP502x |
| 15:33:26 | preglow | linuxstb: testing for pp now, the track is 435% realtime on iriver |
| 15:33:28 | amiconn | (still not as important as on cf for data though) |
| 15:33:34 | jmspeex | uwb is a second wideband layer, so it uses exactly the same code and codebook |
| 15:33:35 | preglow | amiconn: well, pretty much everything is in iram |
| 15:34:12 | preglow | jmspeex: yep, but i can allocate less meemory for decoder state structs, thanks to smaller frames |
| 15:34:33 | preglow | jmspeex: btw, is much of the const data encoder only? |
| 15:35:32 | jmspeex | preglow: No, the const data is used by both the encoder and decoder. |
| 15:37:02 | pondlife | If we scrap the codec swapping, could the voice code be completely moved out of playback.c (maybe into talk.c, or a new SWCODEC voice.c). |
| 15:37:33 | | Join AEX [0] (i=4fb22e20@gateway/web/cgi-irc/labb.contactor.se/x-0f5c1a8e3ef2af2f) |
| 15:37:45 | pondlife | And, is it likely that speex-format voice files will be smaller than MP3 for a similar quality? |
| 15:38:02 | preglow | dunno, 13kbps files sound decent here |
| 15:38:15 | preglow | this is why i was wondering what bitrate the mp3 clips usually are |
| 15:38:23 | jmspeex | pondlife: At low bit-rate, Speex will sound *much* better than MP3 for voice. |
| 15:38:48 | pondlife | jmspeex: From your nick, I'm guessing you may be biased ;) |
| 15:38:59 | preglow | haha |
| 15:39:02 | preglow | he's kind of the speex creator |
| 15:39:16 | AEX | help please i have a question, is it possible playing GB Roms and listen to music at the same time?(e200 Device) |
| 15:39:22 | preglow | and by "kind of" i mean "certainly" |
| 15:39:35 | jmspeex | pondlife: Yes, but the difference is so big that even the MP3 creators would have to agree with me. Seriously. |
| 15:39:45 | pondlife | Great |
| 15:40:10 | jmspeex | If you compare Speex with Vorbis on voice, the "cross-over" bit-rate is around 32 kbps. and Vorbis is much better than MP3. |
| 15:40:20 | AEX | someone? |
| 15:40:28 | scorche|w | AEX: no |
| 15:41:07 | | Quit AEX (Client Quit) |
| 15:41:40 | pondlife | preglow: No idea if it's typical, but my MP3 .talk files are 24kbps |
| 15:41:50 | LinusN | it is hardly surprising that a celp codec outperforms mp3 with voice data |
| 15:42:01 | preglow | not really, no... |
| 15:42:19 | pondlife | So speex should mean more audio buffer and simpler code, basically |
| 15:42:28 | pondlife | Sounds good to me |
| 15:42:40 | preglow | linuxstb: same track decodes at 147% on nano, but i haven't given that much asm attention yet either |
| 15:42:43 | LinusN | i see very few drawbacks |
| 15:42:47 | preglow | the qmf_synth optimization needs firm stroking there |
| 15:43:51 | preglow | the 630% track decodes at 292% on nano |
| 15:44:01 | preglow | and that's more like voice file quality |
| 15:44:13 | donutman25 | hey devs could this help you with the improvements on the sansa e200? http://pastebin.ca/756456 |
| 15:45:17 | LinusN | the only drawback i can think of would be that the core would contain a voice codec even if you don't use the voice |
| 15:45:40 | preglow | well, at least it won't be very big :) |
| 15:45:43 | LinusN | could be a real psychological burden for the binary-size freaks |
| 15:45:53 | preglow | we'll trim it down as far as it can go |
| 15:46:22 | LinusN | personally, i couldn't care less, since the playback code would be so much better |
| 15:46:29 | preglow | yep |
| 15:46:30 | Zagor | donutman25: uh, is that the output of "strings file.mi4"? |
| 15:46:34 | pondlife | Anyway it could be linked to a different address, then loaded dynamically if needed? |
| 15:46:43 | preglow | pondlife: we'd still need the swapping, then |
| 15:46:44 | LinusN | pondlife: let's not go there |
| 15:46:49 | preglow | easy is good |
| 15:46:52 | preglow | and this solution is easy |
| 15:46:55 | pondlife | Indeed |
| 15:47:10 | LinusN | the playback code needs simplicity |
| 15:47:13 | donutman25 | Zagor: I think so |
| 15:48:23 | Zagor | donutman25: then, no, that does not help |
| 15:49:24 | donutman25 | Zagor: sorry for wasting your time then |
| 15:49:32 | preglow | jmspeex: you're not planning on doing any decoder-only build options, are you? |
| 15:50:00 | jmspeex | preglow: Why would I? It wouldn't change the footprint much. |
| 15:50:29 | preglow | it does change it a bit, i've got the encoder parts #if 0ed out of sb_celp and nb_celp, and it shaved off 20k or something |
| 15:50:39 | preglow | but no, i do get your point |
| 15:50:50 | jmspeex | preglow: I have however reorganised the files such that if you only use narrowband and link statically, the wideband stuff gets removed. |
| 15:51:13 | preglow | yeah, noticed while syncing |
| 15:51:16 | LinusN | preglow: how is the footprint today? |
| 15:51:36 | jmspeex | preglow: 20k??? I really doubt it. What's the total size? |
| 15:51:38 | preglow | .codec file is around 68k for coldfire |
| 15:51:46 | preglow | that excludes bss data |
| 15:51:52 | LinusN | hehe, that's quite small |
| 15:51:59 | preglow | it can be made smaller still |
| 15:52:39 | LinusN | the smaller the better, of course |
| 15:52:40 | preglow | there are some floats here and there to be removed, that'd remove the float emulation overhead |
| 15:53:01 | jmspeex | preglow: a wideband x86-64/Linux executable is about 80k (including everything). I'm surprised your binary is that large |
| 15:53:22 | preglow | jmspeex: for arm it's even larger, 80kb++ |
| 15:53:30 | preglow | and this is after stripping the encoder stuff |
| 15:53:34 | amiconn | preglow: If speex is only 147% realtime on PP502x, it may well be too slow on PP5002 |
| 15:53:36 | jmspeex | something's odd. |
| 15:53:56 | preglow | amiconn: that's for a uwb file, we'll be using wb (16khz), for which my last perfomance figure applies |
| 15:54:21 | jmspeex | amiconn: if you're desperate for decoding speed, there's a bunch of shortcuts that are sure to bring the complexity down to an acceptable level |
| 15:54:21 | preglow | amiconn: also, after i optimize a couple of vital functions, it'll be faster |
| 15:55:09 | LinusN | this looks really promising |
| 15:55:32 | preglow | LinusN: anyway, i'd be more than interested in helping in on the codec side of things |
| 15:55:35 | jmspeex | preglow, amiconn: You're aware that any nb/wb/uwb file can be transparently decoded as if it was in a different mode? Also the enhancer can be turned off −− at a cost in quality. |
| 15:55:48 | preglow | jmspeex: the enhancer is on by default? |
| 15:56:05 | * | amiconn wonders how iFP will cope with a statically linked voice codec (be it speex or mad) :> |
| 15:56:10 | jmspeex | preglow: yes. And try to keep it on if you can because it does help |
| 15:56:13 | * | LinusN doesn't care |
| 15:57:04 | preglow | the ifp isn't exactly the target that has the biggest following |
| 15:57:14 | preglow | jmspeex: i don't think it'll be a problem |
| 15:57:15 | LinusN | i don't think ifp should stop progress on all the other targets |
| 15:57:24 | linuxstb | Couldn't we make voice support optional via a #define? |
| 15:57:26 | preglow | jmspeex: speex is already more than fast enough on coldfire, and will soon be so on arm too |
| 15:57:46 | amiconn | LinusN: I didn't say that... |
| 15:57:48 | LinusN | linuxstb: that is an option |
| 15:58:01 | LinusN | amiconn: i know |
| 15:58:59 | LinusN | a static voice codec would make life a lot easier |
| 15:59:12 | | Quit JdGordon (Remote closed the connection) |
| 16:00 |
| 16:02:08 | preglow | stripped out vbr stuff, 63kb now |
| 16:03:26 | LinusN | how does that affect the size of the encoded data? |
| 16:04:01 | | Quit Zagor (Remote closed the connection) |
| 16:04:28 | preglow | we're not encoding |
| 16:04:30 | | Join lee-qid [0] (n=liqid@p54966AD9.dip.t-dialin.net) |
| 16:04:35 | preglow | i'm talking in the decoder binary here |
| 16:04:48 | preglow | libspeex is both encoder and decoder, i'm just stripping out the encoder stuff |
| 16:05:06 | preglow | decoder doesn't need any vbr stuff, since all bit allocation has already been done on the encoder part |
| 16:05:55 | LinusN | aha |
| 16:06:35 | | Quit J3TC- (Read error: 110 (Connection timed out)) |
| 16:07:06 | | Join J3TC- [0] (n=jetc123@dhcp73-1.njit.edu) |
| 16:08:05 | amiconn | preglow: How demanding would a speex encoder be? |
| 16:08:40 | preglow | amiconn: i've talked to jmspeex about it, he expects an nb (8khz) encoder would work on an ipod cpu given enough optimizing |
| 16:08:57 | preglow | amiconn: and from what i have seen doing decoder optimizing, i'd expect a wb encoder to work on coldfire after a load of optimizing |
| 16:09:05 | | Join tarsius [0] (i=a807e9a0@gateway/web/cgi-irc/labb.contactor.se/x-e15848c70b01ac30) |
| 16:09:12 | preglow | but that's something of a guess |
| 16:09:54 | jmspeex | preglow: I'm sure a coldfire can encode wb |
| 16:10:03 | | Join jgarvey [0] (n=jgarvey@cpe-024-163-032-204.nc.res.rr.com) |
| 16:10:14 | preglow | LinusN: aha, also, we wouldn't need the ogg framing code, which means size is further cut |
| 16:10:23 | jmspeex | preglow: or at least for 20.6 kbps (higher bit-rates are more expensive) |
| 16:10:24 | LinusN | nice |
| 16:10:47 | tarsius | is linuxstd here? |
| 16:10:55 | * | preglow points to linuxstb |
| 16:11:04 | tarsius | whoops |
| 16:11:08 | tarsius | that's what i meant |
| 16:11:32 | tarsius | is he at the keyboard right now? |
| 16:11:38 | preglow | ask |
| 16:12:58 | tarsius | linuxstb? are you there? |
| 16:13:42 | | Join karashata [0] (n=Kimi@pool2-138.adsl.user.start.ca) |
| 16:14:19 | preglow | jmspeex: anyway, if we are going to link speex statically to rockbox, i will probably do an #ifdef ENCODER_DISABLED thing |
| 16:14:26 | preglow | every kb counts |
| 16:14:51 | markun | tarsius: if you stay connected he will reply eventually |
| 16:15:04 | tarsius | thanks |
| 16:15:12 | LinusN | preglow: absolutely, and also to clearly show what code is actually used |
| 16:17:45 | preglow | LinusN: anyway, i won't have time today |
| 16:17:56 | LinusN | no rush |
| 16:18:34 | jmspeex | preglow: You might also want to get rid of the packet loss code and possibly other things. |
| 16:19:10 | jmspeex | even the VBR code (it's not used on decode, even for VBR files) |
| 16:19:24 | *** | Saving seen data "./dancer.seen" |
| 16:19:44 | preglow | jmspeex: i'll go through it with a fine-toothed comb :) |
| 16:22:13 | markun | preglow: how big is the codec now? |
| 16:23:08 | preglow | 63k on coldfire, but i stopped working on it for now |
| 16:28:00 | | Quit kugel ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") |
| 16:35:34 | | Join linuxstb_ [0] (n=chatzill@i-83-67-212-170.freedom2surf.net) |
| 16:35:34 | | Join kugel [0] (i=kugel@unaffiliated/kugel) |
| 16:35:56 | linuxstb_ | tarsius: I'm here now. |
| 16:36:49 | tarsius | hi linuxstb. I have a cygwin environment set up, i've checked out rockbox code from svn, but what i was trying to do is run lsusb to see if my player is attached... |
| 16:37:09 | linuxstb_ | lsusb is a Linux app - I doubt it will work in cygwin. |
| 16:37:17 | tarsius | linuxstb_: would you happen to know if usbutils is even .... oh okay |
| 16:38:31 | tarsius | linuxstb_: that's what i needed to hear. i'm now attempting to compile tcctool, but i see i need to change the path to the libusb source |
| 16:40:07 | | Join kubrick [0] (n=repulse@84.123.26.175.dyn.user.ono.com) |
| 16:40:08 | | Quit karashata (Read error: 110 (Connection timed out)) |
| 16:41:02 | | Join karashata [0] (n=Kimi@pool2-131.adsl.user.start.ca) |
| 16:41:29 | | Quit ramon8 (Read error: 104 (Connection reset by peer)) |
| 16:41:47 | kubrick | what chost should I use for an amd64 on a x86 installation? |
| 16:42:31 | | Part LinusN |
| 16:42:51 | preglow | jmspeex: what is this non-standard 4.8 kbps mode, really? |
| 16:43:31 | kubrick | oops, that wasn't for here |
| 16:44:51 | linuxstb_ | tarsius: Which libusb source have you got? Do you have linuxb-win32? |
| 16:45:22 | linuxstb_ | I mean libusb-win32 |
| 16:45:41 | tarsius | libusb-win32-0.1.12.1-2, as installed by the Cygwin installer |
| 16:46:21 | | Quit kubrick ("leaving") |
| 16:50:33 | | Quit scorche|w ("CGI:IRC (EOF)") |
| 16:54:00 | | Join barrywardell [0] (n=barrywar@dhcp-892b9b55.ucd.ie) |
| 16:54:09 | | Join scorche|w [0] (n=8dc5049d@rockbox/administrator/scorche) |
| 16:56:22 | | Quit linuxstb_ ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") |
| 16:57:58 | linuxstb | tarsius: Have you read the install instructions for e200rpatcher on WIndows? The USB code in e200rpatcher is almost identical to tcctool - http://www.rockbox.org/twiki/bin/view/Main/SansaE200RInstallation |
| 17:00 |
| 17:00:19 | | Join desowin [0] (n=desowin@hdp186.internetdsl.tpnet.pl) |
| 17:02:27 | tarsius | linuxstb: sorry, but I can't discern what info in the e200rpatcher page is relevant for me at this time |
| 17:02:46 | tarsius | linuxstb: i haven't compiled the tcctool yet |
| 17:02:50 | | Part pondlife ("Gone") |
| 17:05:45 | linuxstb | tarsius: The relevant info is the Windows installer section in step 1. |
| 17:06:18 | linuxstb | Basically the "manufac-driver.zip" file - you will need to do something similar for tcctool. I expect it's just as simple as changing the USB IDs. |
| 17:06:53 | linuxstb | I could build tcctool.exe for you if you wanted. |
| 17:07:07 | tarsius | linuxstb: i think i've just about got it |
| 17:07:50 | linuxstb | Well, I have a .exe if you want it. |
| 17:08:12 | tarsius | linuxstb: okay, i'd really appreciate that |
| 17:12:30 | | Quit J3TC- (Read error: 110 (Connection timed out)) |
| 17:14:46 | Buschel | could someone just close FS #8014? after some discussion this patch will not be accepted as valid solution. |
| 17:15:42 | | Quit jhulst ("Konversation terminated!") |
| 17:15:55 | scorche|w | query scorche |
| 17:15:59 | scorche|w | whoops |
| 17:16:20 | linuxstb | tarsius: http://www.davechapman.f2s.com/rockbox/tcctool-win32.zip |
| 17:16:47 | linuxstb | tarsius: That also includes what I think should be a correct libusb device driver for the D2. |
| 17:17:39 | linuxstb | tarsius: BTW, do you have a Cowon D2? I've forgotten now... |
| 17:18:11 | tarsius | linuxstb: many, many thanks. I'm working on the Sansa c100 port |
| 17:18:32 | linuxstb | Forget that file then... |
| 17:18:35 | linuxstb | Give me a moment. |
| 17:18:58 | | Join J3TC- [0] (n=jetc123@dhcp73-1.njit.edu) |
| 17:19:11 | linuxstb | OK, it should be fine now - same URL. |
| 17:19:13 | tarsius | linuxstb: ... but I recently bought a Sansa e250 "that doesn't start" off of eBay... I'm gambling that it may be recoverable |
| 17:19:18 | tarsius | okay |
| 17:24:29 | | Join ChrisWa [0] (i=chriswa@colargol.tihlde.org) |
| 17:24:57 | Buschel | thanks for closing |
| 17:26:24 | | Join Frazz [0] (n=Fraser@thelawsons.plus.com) |
| 17:26:32 | ChrisWa | hi. just tried aacPlus v2 on the 4g iPod Photo and it skips about every second. Is it just too slow? I read on the codec status page that AAC should be realtime on ipod now, but that probably doesnt count for aacPlus v2? |
| 17:26:47 | linuxstb | Exactly. |
| 17:26:55 | ChrisWa | :) |
| 17:36:29 | | Join bistouri [0] (i=c2c7fca1@gateway/web/cgi-irc/labb.contactor.se/x-258811c7446668f9) |
| 17:36:37 | bistouri | hi |
| 17:38:48 | bistouri | i'm searching for a way to test unofficial Sandisk firmwares modded "on the fly" (ie, without replacing bootloader and without re use Sansapatcher each time i try a new firmware) |
| 17:39:21 | bistouri | Where does Rockbox search for official firmware after boot on Sansa targets ? |
| 17:40:01 | linuxstb | It first looks in the firmware partition (the OF is kept there, but moved, if you install with Sansapatcher). Then it looks for OF.mi4/OF.bin in the System directory. |
| 17:40:28 | bistouri | linuxstb: many thanks |
| 17:40:29 | | Join bluebrother [0] (n=Dom@rockbox/staff/bluebrother) |
| 17:41:18 | linuxstb | tarsius: Any luck? |
| 17:44:35 | bistouri | linuxstb: it's curious, Sansapatcher has been applied but i don't find it in SYSTEM dir. let's grep|less :) |
| 17:44:49 | bistouri | don't find OF.* |
| 17:44:59 | linuxstb | It's not put there by Sansapatcher. |
| 17:45:26 | linuxstb | Sansapatcher replaces the OF in the firmware partition with the Rockbox bootloader, and then stores a copy of the OF in an unused part of the firmware partition. |
| 17:45:41 | | Quit ChrisWa ("leaving") |
| 17:46:16 | | Join Ebert [0] (n=EbErT@adsl-215-134-136.aep.bellsouth.net) |
| 17:46:33 | bistouri | linuxstb:thanks. i suppose i t means i'll have to apply SP each time, never mind |
| 17:47:06 | linuxstb | No. If you install the Rockbox bootloader manually, then there won't be a copy of the OF in the firmware partition, so the bootloader will look for OF.mi4 |
| 17:47:39 | | Quit kugel (Connection reset by peer) |
| 17:47:53 | | Join kugel [0] (n=kugel@e178122194.adsl.alicedsl.de) |
| 17:49:20 | | Join illissius- [0] (n=illissiu@91.83.17.14.pool.invitel.hu) |
| 17:51:35 | | Nick advcomp2019_ is now known as advcomp2019 (n=advcomp2@unaffiliated/advcomp2019) |
| 17:52:41 | | Nick EnterUse1Name is now known as EnterUserName (n=dave@ip-218.55.99.216.dsl-cust.ca.inter.net) |
| 17:56:27 | | Quit bistouri ("CGI:IRC") |
| 17:58:44 | | Join pondlife [0] (n=Steve@rockbox/developer/pondlife) |
| 17:59:33 | | Join Domonoky [0] (n=Domonoky@85.179.88.200) |
| 18:00 |
| 18:01:39 | tarsius | linuxstb: sorry, i was on the phone... but CRAP... i left my usb cable at home |
| 18:01:46 | | Quit Domonoky (Client Quit) |
| 18:02:26 | tarsius | what a bummer... |
| 18:02:45 | amiconn | Buschel: I did some tests. Of the update config parameters, only the rectangle itself is actually needed. And reading 0x1fc is indeed unnecessary. Leaving it out even seems to *improve* stability, akthough I need to do further testing regarding that |
| 18:03:52 | | Quit bluebrother ("Verlassend") |
| 18:04:04 | Buschel | amiconn: good to see similar results from your side. |
| 18:06:22 | | Join Domonoky [0] (n=Domonoky@85.179.88.200) |
| 18:06:27 | amiconn | I'll start implementing my idea tonight - first step is writing to the bcm while internal update is running |
| 18:07:06 | | Quit Domonoky (Client Quit) |
| 18:07:11 | | Quit illissius` (Read error: 110 (Connection timed out)) |
| 18:07:46 | Buschel | i am curious about your results :o) |
| 18:09:27 | | Part tarsius |
| 18:16:47 | | Part wookey_ |
| 18:17:41 | | Join Domonoky [0] (n=Domonoky@e179088200.adsl.alicedsl.de) |
| 18:19:29 | *** | Saving seen data "./dancer.seen" |
| 18:20:21 | | Nick Domonoky is now known as testy (n=Domonoky@e179088200.adsl.alicedsl.de) |
| 18:20:56 | | Nick testy is now known as ta (n=Domonoky@e179088200.adsl.alicedsl.de) |
| 18:20:58 | | Quit ta (Client Quit) |
| 18:24:41 | | Join Rondom [0] (n=Rondom@p57A96540.dip.t-dialin.net) |
| 18:25:54 | | Quit homielowe (Read error: 110 (Connection timed out)) |
| 18:26:09 | | Join Domonoky [0] (n=Domonoky@e179088200.adsl.alicedsl.de) |
| 18:27:05 | | Join TotallyInfected [0] (n=ebola@pool-141-151-72-127.phlapa.east.verizon.net) |
| 18:31:30 | | Join Lear [0] (i=chatzill@rockbox/developer/lear) |
| 18:33:59 | | Join rzr\ [0] (n=hcmf-nor@c7A63BF51.dhcp.bluecom.no) |
| 18:34:56 | | Quit petur ("work->home") |
| 18:35:00 | rzr\ | Good evening everyone. Quick question: Can I reset the database on my player just by deleting the database_*.tcd files in the /.rockbox directory? |
| 18:35:04 | | Join tarsius [0] (i=a807e9a0@gateway/web/cgi-irc/labb.contactor.se/x-9b0f3057c1d1c863) |
| 18:36:34 | | Join colin_ [0] (n=colin@host-155-47-107-208.midco.net) |
| 18:36:50 | | Quit colin_ (Client Quit) |
| 18:37:35 | tarsius | linuxstb: I found my cable(!) and tried running tcctool with my Sansa c140 in recovery mode, loading the original firmware... but I got "[ERR] Short read." |
| 18:38:57 | | Join bertrik [0] (n=Bertrik_@031-020-045-062.dynamic.caiway.nl) |
| 18:39:30 | | Quit barrywardell () |
| 18:39:36 | | Join linuxstb_ [0] (n=chatzill@i-83-67-212-170.freedom2surf.net) |
| 18:39:54 | | Quit J3TC- (".•«UPP»•.") |
| 18:40:35 | | Join barrywardell [0] (n=barrywar@dhcp-892b9b55.ucd.ie) |
| 18:40:50 | tarsius | linuxstb_: I found my cable(!) and tried running tcctool with my Sansa c140 in recovery mode, loading the original firmware... but I got "[ERR] Short read." |
| 18:40:56 | | Part Llorean |
| 18:41:28 | linuxstb_ | tarsius: No need to repeat - I read your message in the logs. |
| 18:41:33 | | Join lee-qid_ [0] (n=liqid@p54966D9D.dip.t-dialin.net) |
| 18:41:38 | linuxstb_ | I think I know the problem, and am fixing now. |
| 18:42:17 | Lear | Any rbutil hacker around? I could try to make it detect a Sansa properly, if I got a pointer or two... |
| 18:42:27 | Lear | (On Windows, that is...) |
| 18:42:58 | linuxstb_ | tarsius: Updated version uploaded - same URL (do you need the URL again?) |
| 18:43:05 | | Quit Thundercloud (Remote closed the connection) |
| 18:43:11 | tarsius | yes please |
| 18:43:18 | linuxstb_ | Lear: Sansapatcher works, but rbutil doesn't? |
| 18:43:26 | Lear | Yep. |
| 18:43:54 | linuxstb_ | tarsius: http://www.davechapman.f2s.com/rockbox/tcctool-win32.zip |
| 18:45:11 | Domonoky | lear... me is here :-) |
| 18:45:17 | bertrik | rbutil can't autodetect a sansa e200, other than that, it works |
| 18:45:18 | linuxstb_ | Lear: You could try adding printfs in rbutil/sansapatcher.c, to see what's going on - the sansa_scan() function. |
| 18:45:31 | linuxstb_ | I mean rbutil/sansapatcher/sansapatcher.c |
| 18:46:22 | | Join nanok [0] (n=nanok@194.145.183.75) |
| 18:46:33 | Lear | Sounds like a plan. Btw, is the QT dev environment hard to setup on Cygwin? |
| 18:46:35 | nanok | hello |
| 18:47:02 | Domonoky | Lear: i use mingw and not cygwin for rbutil on windows.. |
| 18:47:23 | Domonoky | mingw is included in the qt installer for windows.. |
| 18:47:26 | linuxstb_ | Lear: You could also compile the standalone sansapatcher, to see what it _should_ be doing. You'll need the c200 and e200 bootloaders in the sansapatcher directory to build it. |
| 18:48:17 | | Join J3TC- [0] (n=jetc123@dhcp75-23.njit.edu) |
| 18:48:33 | * | linuxstb_ wonders if he's the only person without a Sansa now... |
| 18:48:43 | nanok | linuxstb_: :) |
| 18:48:45 | amiconn | linuxstb: You're not |
| 18:48:58 | * | karashata doesn't have one either |
| 18:49:21 | Domonoky | Lear: to see the console with rbutil on windows, you have to add "CONFIG += console" into the rbutil.pro file |
| 18:49:23 | tarsius | linuxstb: haha... well i just ran tcctool and I got "[ERR] Could not find any USB busses." |
| 18:49:58 | tarsius | linuxstb: is there further installation procedure for libusb beyond the Cygwin automatic installer? |
| 18:50:03 | linuxstb_ | tarsius: So you installed the driver I included in the zip file? |
| 18:50:06 | nanok | i'm afrais i'm hear for similar problems: any howto out there for building from source (preferably on linux) |
| 18:50:17 | nanok | for the sansa, if it makes a difference |
| 18:50:37 | linuxstb_ | tarsius: i.e. when you attached your c100 for the first time, Windows should have prompted you for a driver, and you needed to point it to that folder. |
| 18:50:56 | tarsius | linuxstb: okay, i'll change the driver |
| 18:51:15 | Lear | Domonoky: So I just run the QT installer then? Do you then build from Cygwin? |
| 18:51:16 | linuxstb_ | I've no idea what cygwin is doing with libusb - you don't need it. |
| 18:51:35 | nanok | pondlife: trying to help out with the log you require.. |
| 18:51:49 | tarsius | linuxstb: installing... |
| 18:52:36 | Domonoky | Lear: i use the qt installer, this also installs mingw if you want, and the there is an entry for a console with the paths setup in the Qt startmenü entry.. so no cygwin fro rbutil.. |
| 18:52:59 | | Quit desowin ("use linux") |
| 18:53:12 | | Part rzr\ |
| 18:53:42 | | Quit idnar (Nick collision from services.) |
| 18:53:45 | | Join idnar_ [0] (n=mithrand@unaffiliated/idnar) |
| 18:54:09 | nanok | i have noticed something else with todays build, but i am not sure yet: using dithering consistently generates nasty artifacts, for quite a few tracks, which, iirc, weren;t there with the older builds |
| 18:54:17 | Lear | Domonoky: Thanks, good to know, even if I'll give Cygwin a try anyway. :) |
| 18:54:24 | nanok | but i have yet to test with an older one and see if my recolections are not wrong |
| 18:54:40 | nanok | anybody else noticed something similar? |
| 18:54:45 | Lear | There were recently changes to fix problems like that... |
| 18:54:49 | nanok | (this, again, is happening on the sansa) |
| 18:54:50 | Domonoky | Lear: feel free to try it in cygwin, i dont know how good this works.. :-) |
| 18:55:33 | | Nick idnar_ is now known as idnar (n=mithrand@unaffiliated/idnar) |
| 18:58:26 | tarsius | linuxstb: it appears to have worked! ... but it went directly into its usb transfer mode, so i put a battery in, pulled out the cable, and it continued playing an mp3 i was listening to before |
| 18:59:02 | | Quit lee-qid (Read error: 110 (Connection timed out)) |
| 19:00 |
| 19:00:38 | pondlife | nanok: I'm not familiar with the Linux setup, but did you look on the wiki? |
| 19:01:20 | tarsius | linuxstb: as a test, i held down the keys normally required for a different test mode, uploaded the firmware with tcctool, and I was taken directly to that test mode. excellent :) |
| 19:01:34 | linuxstb_ | tarsius: Glad it's working ;) |
| 19:01:37 | tarsius | linuxstb: my hat's off to you |
| 19:03:24 | nanok | pondlife: give me a hint, what/where to look for, i am sure i will find something, i just am not familiar with the structure of the rockbox viki, i am new here ;) |
| 19:03:35 | nanok | pondlife: like a keyword or something |
| 19:03:44 | bertrik | nanok, i can help you with getting a logf |
| 19:04:08 | nanok | bertrik: great |
| 19:04:14 | pondlife | nanok: http://www.rockbox.org/twiki/bin/view/Main/SimpleGuideToCompiling |
| 19:04:23 | bertrik | nanok: i also noticed some very subtle ticks about a week ago, but haven't noticed them recently |
| 19:04:34 | | Quit donutman25 (Read error: 104 (Connection reset by peer)) |
| 19:04:44 | nanok | bertrik: btw, did you allready get one for your sansa? iirc you managed to get the reproducing reciepe in the first place |
| 19:05:12 | | Quit stewball (Read error: 113 (No route to host)) |
| 19:05:20 | nanok | bertrik: i have only noticed them today, with this mornings build. they were not subtle.. |
| 19:05:21 | pondlife | nanok: And http://www.rockbox.org/twiki/bin/view/Main/DevelopmentGuide |
| 19:05:21 | bertrik | yes, I have one, I'll get another from the latest build and put it up with the bug report |
| 19:06:10 | nanok | bertrik: okay, than i'll let you to it for now, and meanwhile read the lnk pondlife gave me, and try to find more about this dithering issue |
| 19:06:27 | pondlife | That second link is probably a better overview |
| 19:06:50 | Lear | Domonoky: Recognize "cannot find -lqtmaind"? |
| 19:07:03 | Lear | Maybe I don't have a debug build of Qt installed then... |
| 19:07:04 | | Join ilgufo [0] (n=matteo@host230-159-dynamic.58-82-r.retail.telecomitalia.it) |
| 19:07:20 | Domonoky | Lear: correct.. |
| 19:07:27 | nanok | pondlife: both sound like "must-read"'s |
| 19:07:36 | Domonoky | you can build the debug libs.. but it takes a long while.. |
| 19:07:42 | pondlife | Probably, but beware occaisional out-of-date info! |
| 19:07:44 | Lear | Btw, silly Qt installer. Qt can't be installed in a path with spaces, but MinGW can... |
| 19:09:14 | nanok | Lear: spaces in paths are like dvd players with widescreen in a car for the driver: nobody in their right mind should ever think about using them |
| 19:09:18 | nanok | :) |
| 19:10:10 | Lear | Well, don't blame me, I just want to install everything in the same place (i.e., in "Program Files"). :) |
| 19:10:10 | rasher | nanok: why on earth not? Its the 21st century.. |
| 19:10:51 | nanok | rasher: well, the same reason for "don;t drink and drive", but usually the effects of drinking are not so bad |
| 19:10:54 | nanok | :) |
| 19:11:22 | rasher | I don't see any argument against spaces in paths except "broken software might not work" |
| 19:11:46 | nanok | rasher: which reminds me: if it's the 21st century, why the fuck can i have a dvd player in my car (which is anything but completely useless) but can;t have such a basic feature like a damn HUD |
| 19:11:52 | nanok | (head up display) |
| 19:12:04 | krazykit | does the hud run rockbox? |
| 19:12:11 | rasher | nanok: well that's not even remotely on topic.. |
| 19:12:11 | * | pondlife coughs |
| 19:12:21 | nanok | krazykit: i think it might be hacked to, if we would have one |
| 19:12:32 | nanok | rasher: correct |
| 19:12:52 | pondlife | Anyone here seeing the FLAC problems reported on the forum... I thought Nico_P had talked about it, but I can't see a Flyspray report. |
| 19:13:17 | Lear | Hrm, forgot to add "CONFIG += console" first, so I added it, ran qmake, make clean and make, still no console output, it seems. Suggestions? |
| 19:13:27 | nanok | back on topic: i am almost sure there is no issue with dithering in the oldest build i have. i have allready tried several tracks i noticed it on today with the latest build |
| 19:14:49 | preglow | 51428 \o/ |
| 19:15:37 | pondlife | preglow: I thought you'd just hit a red-build high score.. ;) |
| 19:17:13 | nanok | i also have some rather stupid questions: one would be: would it be possible to power down the lcd also, as an option, when powering down the light? is it allready happening? would it make sense for power consumption? how about shuting down the gpu temporarly (some, like the sansa, i think actually have one), while the backlight is on, and disabling any rendering related to the display that would otherwise be needed, to save power? |
| 19:17:13 | preglow | nah, just spending time shrinking the speex codec :) |
| 19:17:23 | Lear | Bah, debug output is for wimps. Got it working. :) |
| 19:17:31 | linuxstb_ | preglow: That's the .codec size? |
| 19:18:04 | linuxstb_ | preglow: It's still going to be a very red delta... |
| 19:19:53 | nanok | the point is that,on target with a colour lcd, you can't see shit anyway, when the backlight is off, no matter what you do (unlike older black/white 0/1 type lcd's) |
| 19:20:39 | linuxstb_ | You can on some colour LCDs (all colour ipods for example). |
| 19:20:44 | | Join colin_ [0] (n=colin@host-155-47-107-208.midco.net) |
| 19:22:13 | nanok | linuxstb_: hm, yes, now that you mention it, i did see phones which are vaguely readable without the backlight. but the sansa seems completely black to me, without the backlight |
| 19:22:19 | Lear | linuxstb_: Where can I find the needed .mi4 files (need to test sansapatcher too)? |
| 19:22:51 | linuxstb_ | http://download.rockbox.org/bootloader/sandisk-sansa/c200/firmware.mi4 and http://download.rockbox.org/bootloader/sandisk-sansa/e200/PP5022.mi4 |
| 19:23:33 | linuxstb_ | Lear: So rbutil is working for you now? |
| 19:23:50 | | Join Zagor [0] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) |
| 19:23:58 | | Quit tarsius ("CGI:IRC (Ping timeout)") |
| 19:24:19 | Lear | Thanks. Yes, just did an install. All looked well at least, haven't rebooted just yet. :) |
| 19:24:31 | linuxstb_ | What was the problem? |
| 19:25:29 | preglow | linuxstb_: another 2k5 is spent in floating point code we should gut out |
| 19:25:34 | preglow | and there's probably more here i have overlooked |
| 19:25:59 | linuxstb_ | Is this the regular codec you're stripping, or the intended voice codec for the core? |
| 19:27:17 | | Quit Zagor (Client Quit) |
| 19:27:21 | preglow | the same work applies to them both, pretty much |
| 19:27:36 | | Join tarsius [0] (i=a807e9a0@gateway/web/cgi-irc/labb.contactor.se/x-56e7a4f5bdcb2e78) |
| 19:31:40 | preglow | but yeah, linking an entire codec does imply some overhead in size |
| 19:31:46 | preglow | but i expect to be able to shave off more than this too |
| 19:32:30 | tarsius | linuxstb_: fun fact you probably already know: fw uploaded by tcctool is executed without checking the CRC |
| 19:32:58 | tarsius | linuxstb_: i hex-edited a string in my fw, uploaded it, and verified the change |
| 19:33:11 | preglow | linuxstb_: also, seems removing oggframing.c helps a fair deal |
| 19:36:03 | | Quit japc (Remote closed the connection) |
| 19:36:09 | | Join linuxstb__ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
| 19:36:16 | | Join nanok_ [0] (n=nanok@194.145.183.75) |
| 19:36:55 | nanok_ | pff |
| 19:37:00 | nanok_ | sorry for the lag |
| 19:37:28 | | Quit nanok (Read error: 104 (Connection reset by peer)) |
| 19:39:24 | | Join linuxstb___ [0] (n=chatzill@i-83-67-212-170.freedom2surf.net) |
| 19:39:45 | | Quit linuxstb_ (Nick collision from services.) |
| 19:39:50 | | Quit linuxstb (Nick collision from services.) |
| 19:39:51 | | Nick linuxstb___ is now known as linuxstb (n=chatzill@i-83-67-212-170.freedom2surf.net) |
| 19:40:53 | | Join agm3nt [0] (i=nat-107@nat.n3t.pl) |
| 19:40:58 | linuxstb | tarsius: Yes, I knew the usb boot mode skips the crc check. Do you know we can calculate the CRCs though? |
| 19:41:30 | | Join BigBambi [0] (n=alex@rockbox/staff/BigBambi) |
| 19:41:52 | | Join bluey [0] (n=bluey@dslb-088-074-014-151.pools.arcor-ip.net) |
| 19:45:28 | | Join ompaul [0] (n=ompaul@gnewsense/friend/ompaul) |
| 19:45:29 | nanok_ | pondlife: about one of your questions: with the ogg's in a different dir, but with one of them being set as next to play (by rockbox, not by me), so allready partialy buffered i guess, the behaviour is still the same when i skip to it |
| 19:46:12 | nanok_ | now let me try the same, but with no manual skip, just leting rockbox get to that song |
| 19:46:41 | nanok_ | (after some ffwd ofcourse :) ) |
| 19:47:03 | preglow | linuxstb: down to 61880 on arm, so yeah, it's gonna be a delta... |
| 19:47:43 | tarsius | linuxstb: telechips.h, right? |
| 19:47:45 | | Join Thundercloud [0] (n=thunderc@resnet05.nat.lancs.ac.uk) |
| 19:48:02 | | Quit colin_ () |
| 19:49:00 | nanok_ | pondlife: okay, happens with normal play also |
| 19:49:05 | preglow | god, gcc is so retarded at generating code |
| 19:49:56 | linuxstb | Have you tried -Os ? |
| 19:50:20 | linuxstb | tarsius: telechips.c is the main code... |
| 19:51:21 | | Quit bluey ("Leaving") |
| 19:51:44 | | Join obo [0] (n=obo@rockbox/developer/obo) |
| 19:52:19 | nanok_ | pondlife: same behaviour with the mp3 in the same dir, and the ogg prebuffered (as "next song") |
| 19:52:23 | pondlife | nanok_: So it doesn't matter if it's buffered or not. |
| 19:52:36 | pondlife | Hmm, is it absolutely any mp3/ogg? |
| 19:52:44 | nanok_ | i will write it on the flyspray |
| 19:52:52 | pondlife | Or maybe a particular bitrate/filesize? |
| 19:52:52 | nanok_ | pondlife: yes, it seems to be irrelevant |
| 19:53:01 | nanok_ | oh, btw, i think i have some wma also (yuk) |
| 19:53:06 | nanok_ | let me try that too |
| 19:53:18 | tarsius | linuxstb: okay |
| 19:54:14 | | Join tedrock [0] (n=tedrock@d235-156-104.home1.cgocable.net) |
| 19:56:22 | | Quit pondlife ("Read error: 110 (Connection slimed out)") |
| 19:57:39 | | Join colin_ [0] (n=colin@host-155-47-107-208.midco.net) |
| 19:58:09 | nanok_ | hm, interesting, does not happen when switching from wma to ogg, only from mp3 |
| 19:58:34 | nanok_ | i have to find some flac's also, i can;t find the damn cd's i had with flacs |
| 19:58:37 | | Nick nanok_ is now known as nanok (n=nanok@194.145.183.75) |
| 19:59:14 | * | preglow has his nano usb-lock on him again and looks forward to zagor's work... |
| 20:00 |
| 20:02:12 | MajorC | ive never understood this third person talk |
| 20:02:48 | * | karashata wonders if MajorC knows about the /me command |
| 20:03:27 | MajorC | lol |
| 20:03:29 | MajorC | =) |
| 20:03:42 | karashata | thought that might help clear that one up a bit |
| 20:04:01 | preglow | as usual, arm assembler yields laughable speedups compared to coldfire |
| 20:04:36 | MajorC | well, ive been on irc since '96, so i know the fundamentals. However, i never understood the use of it. |
| 20:05:17 | * | karashata thinks it's primarily used for actions, though he could be wrong |
| 20:05:39 | parafin | it's called ctcp action |
| 20:05:46 | parafin | so it's for actions by definition |
| 20:06:43 | karashata | ah, nifty |
| 20:07:04 | karashata | anyway, enough of this before we get prodded at for being off-topic |
| 20:08:00 | MajorC | would be nice with an off topic channel for the rockbox community. |
| 20:08:08 | karashata | there is |
| 20:08:12 | preglow | #rockbox-community |
| 20:08:14 | karashata | #rockbox-community |
| 20:08:17 | pixelma | see topic |
| 20:08:19 | MajorC | LOL |
| 20:08:20 | * | karashata chuckles |
| 20:08:30 | amiconn | preglow: For the ape filters, asm helped quite a bit on arm7 too... |
| 20:09:23 | amiconn | Not for the stuff involving multiplication (there I could only save the 25% I mentioned yesterday), but for the vector addition / subtraction |
| 20:09:38 | preglow | amiconn: exactly, and speex is tons of multiplies :/ |
| 20:11:47 | amiconn | Btw, in the ape scalarproduct() I tried switching factors, because it looks like one of the factors is often pretty small, and I thought early termination would help. |
| 20:11:54 | amiconn | It didn't have any effect... |
| 20:12:12 | nanok | so, can anybody confirm "cliping" especially on base, with dithering enabled, on the 31/10 build? i am not sure if ti makes sense to spam the flyspray with it |
| 20:12:29 | nanok | (i want to install this build back though and test again, to make sure) |
| 20:13:01 | preglow | amiconn: we should do some tests on early termination to see if the effects are as documented |
| 20:14:07 | | Quit Buschel () |
| 20:14:18 | * | nanok feels small and insignificant, amongst developers |
| 20:14:23 | nanok | :) |
| 20:14:54 | * | karashata just haunts the channel, isn't a dev at all |
| 20:15:55 | preglow | nanok: most people here aren't |
| 20:16:07 | | Quit Frazz ("Leaving") |
| 20:17:07 | * | preglow needs a clever -32767..32767 clip on arm |
| 20:17:15 | nanok | preglow: yes, but i feel humble when preglow and amiconn talk about early termination. only typing "early termination" send shivers down my spine |
| 20:17:34 | nanok | <scared>what the hell is that</scared> |
| 20:18:09 | | Join Arathis [0] (n=doerk@p508A3A97.dip.t-dialin.net) |
| 20:18:10 | nanok | is it like.. premature termination? |
| 20:18:12 | nanok | :-P |
| 20:18:14 | amiconn | It's a feature of the arm multiplication instruction |
| 20:18:18 | nanok | okay, enough offtpic |
| 20:18:40 | nanok | amiconn: yeah, i got that. and i also have a very vague idea what it might be about |
| 20:18:54 | nanok | it's actually quite interesting to listen |
| 20:19:03 | nanok | (so i might as well shut the hell up ;) ) |
| 20:19:20 | | Join stewball [0] (n=WTFOMGBB@91.106.247.206) |
| 20:19:31 | *** | Saving seen data "./dancer.seen" |
| 20:20:17 | preglow | rhrmr |
| 20:20:20 | preglow | annoying arm |
| 20:21:51 | preglow | linuxstb: btw, it would probably be more informative to label files meant for sansa/ipod as arm4.x, not arm7.x |
| 20:22:20 | amiconn | Then that would have to be armv4 |
| 20:22:28 | | Part tarsius |
| 20:22:30 | amiconn | But it would be less specific |
| 20:22:40 | preglow | you don't need any more specific than that |
| 20:22:45 | amiconn | E.g. the ape filter optimisation only applies to arm7 |
| 20:22:58 | preglow | beh, i guess arm9tdmi is also armv4 |
| 20:23:07 | amiconn | The gigabeat is arm9 (arm920t) which is also armv4 |
| 20:23:16 | preglow | ok,then |
| 20:23:17 | preglow | ignore that |
| 20:23:19 | amiconn | But the arm940 is v5 |
| 20:23:23 | amiconn | Weird, eh? |
| 20:23:56 | preglow | it is |
| 20:23:59 | preglow | i always have to look that up |
| 20:24:01 | preglow | unable to remember |
| 20:24:22 | preglow | amiconn: anywho, there aren't any more clever ways to extract the lower halfword from a register by first lsl 16, then asr 16, no? |
| 20:25:03 | nanok | ahhhm |
| 20:25:07 | nanok | this is nice.. |
| 20:25:15 | * | nanok bricked the sansa. again |
| 20:25:27 | nanok | out come the screwdrivers |
| 20:25:33 | * | karashata wonders how |
| 20:25:34 | linuxstb | You can't brick something twice... |
| 20:25:56 | nanok | linuxstb: well, you know, that unbrickable state of bricking |
| 20:26:04 | amiconn | preglow: Not for signed, no. For unsigned you could use a mask |
| 20:26:22 | nanok | but, somebody here (i think you?) was right: holding the power bottun long enough does power off |
| 20:26:41 | nanok | damn, my screwdrivers where crying for some action :-P |
| 20:27:23 | preglow | amiconn: what i wouldn't give for armv5... |
| 20:27:25 | amiconn | preglow: This is the reason why I don't use int16 in mandelbrot on arm for the low zoom levels, unlike on coldfire and SH1 |
| 20:27:28 | nanok | after getting the player in that state (ogg after mp3), i tryed to switch to radio. this confuses it completely it seems |
| 20:27:44 | amiconn | preglow: Bah, where would all the optimisation fun go then?? ;) |
| 20:27:45 | nanok | karashata: in case you were still wondering |
| 20:27:48 | | Quit colin_ ("http://suffering.no-ip.org/itunescatalog/index.php") |
| 20:28:06 | karashata | nanok: ahh... |
| 20:28:09 | preglow | SMULxy and SMLALxy are exactly what we want |
| 20:28:32 | * | karashata wonders when FM radio will work for H10 players |
| 20:28:35 | preglow | amiconn: for some reason i think optimizing is so much more fun when i don't have to work around a lack of good instructions :P |
| 20:28:52 | amiconn | preglow: Btw, even arm11 still has that slow multiplier |
| 20:29:12 | amiconn | (of course at a higher cpu clock, and a bit more clever pipelining) |
| 20:30:00 | nanok | karashata: it is still a work in progress on the sansa also, it seems. at least the auto-scan stuff needs some brushing up |
| 20:30:08 | nanok | but it does work, as far as i can tell |
| 20:30:08 | preglow | amiconn: what armv is arm11? |
| 20:30:09 | | Join criznach [0] (n=criznach@host-69-145-134-192.grf-mt.client.bresnan.net) |
| 20:30:13 | amiconn | v6 iirc |
| 20:30:21 | preglow | amiconn: then it has some very nice dsp instructions which can be used instead |
| 20:30:39 | amiconn | Each instruction set of our various target archs has its pros and cons |
| 20:30:45 | preglow | amiconn: like i don't need the full 32x32 caps of mul and mla now, i want 16x16 muls, v5 has that, and v6 has it even better |
| 20:30:58 | preglow | amiconn: v6 can even do packed muls |
| 20:31:08 | | Quit rasher (calvino.freenode.net irc.freenode.net) |
| 20:31:08 | NSplit | calvino.freenode.net irc.freenode.net |
| 20:31:10 | preglow | this shit would FLY with that |
| 20:31:14 | karashata | I'm curious as to why it's not working for the H10 at all yet, apparently its the same chip as for the other iriver players that have FM radio support working on them |
| 20:31:16 | amiconn | Arm loves to shift but hates to multiply. On coldfire it's the opposite, and also on SH1, which hates shifting even more than cf |
| 20:31:18 | preglow | but anyway, we won't get armv6 soon |
| 20:31:33 | preglow | amiconn: i think it's so weird to hate shifting as much as sh1 does... |
| 20:31:36 | preglow | shifting is really common |
| 20:31:42 | preglow | and barrel shifters are so cheap... |
| 20:32:51 | amiconn | karashata: It's the same radio chip, but the hookup is of course different, and that is the problem here |
| 20:33:01 | karashata | ahhhh, okay... |
| 20:33:26 | preglow | just look at pentium4, a big, big part of why that sucked so much is they stopped using fast shifts |
| 20:33:26 | karashata | so accessing the chip doesn't work the same then |
| 20:33:32 | amiconn | The other irivers are coldfire, the H10 is portalplayer |
| 20:33:45 | | Quit barrywardell () |
| 20:34:22 | * | amiconn has almost no idea about x86 asm |
| 20:34:29 | | Join rasher [0] (n=rasher@62.79.64.148.adsl.hs.tiscali.dk) |
| 20:34:35 | karashata | is there any possibility that the work on the Sansas might help with the H10 players later, or it the chip on the Sansas too different? |
| 20:35:02 | amiconn | The radio chip in the sansa is quite different |
| 20:35:19 | preglow | amiconn: mul r1, r2, r1 is safe, right? |
| 20:35:30 | * | preglow finds his arm arm |
| 20:36:03 | amiconn | There is some recent research about the H10 radio hookup done by przemhb |
| 20:36:03 | | Quit agm3nt (Read error: 104 (Connection reset by peer)) |
| 20:36:14 | preglow | yeah, seems like the last register is latched on account of the early termination |
| 20:36:32 | amiconn | Unfortunately I did not have the time to look into it - concentrating on lcd stuff atm |
| 20:37:05 | preglow | amiconn: ldmia takes 2+n cycles? |
| 20:37:10 | amiconn | yes |
| 20:37:13 | preglow | good |
| 20:37:21 | preglow | i'm doing some burst reading 16 bit stuff |
| 20:37:27 | preglow | well, burst/block |
| 20:42:56 | | Join petur [0] (n=petur@d54C2B5CE.access.telenet.be) |
| 20:46:05 | | Join BiptoN [0] (i=4ce7cff3@gateway/web/cgi-irc/labb.contactor.se/x-d997dba7e6f5e831) |
| 20:47:51 | | Join bytie [0] (n=bytie@p548CB572.dip0.t-ipconnect.de) |
| 20:48:35 | | Quit bytie (Read error: 104 (Connection reset by peer)) |
| 20:51:02 | BiptoN | hello, i am looking to make a wiki page or what not for a new port |
| 20:51:07 | | Join flacoste [0] (i=francis@canonical/launchpad/flacoste) |
| 20:51:08 | BiptoN | i think i need write permission |
| 20:51:50 | flacoste | hello, i'm a new rockbox user (installed on a e280 using yesteday's daily build) |
| 20:51:52 | | Join webguest17 [0] (i=4a469ecd@gateway/web/cgi-irc/labb.contactor.se/x-47641dd069dfba05) |
| 20:52:19 | flacoste | i add problems navigating the files I uploaded (using the Sansa OS since USB doesn't work) |
| 20:52:21 | webguest17 | does sansapatcher work on e200r? |
| 20:53:00 | flacoste | webguest17: no, see http://www.rockbox.org/twiki/bin/view/Main/SansaE200RInstallation |
| 20:53:21 | flacoste | i first put files in the Sansa music directory |
| 20:53:31 | nanok | about the dithering and cliping: it seems it's a combination of dithering and crosfeed usage. with more conservative crossfeed settings (more attenuation on bttt cross and direct), it seems okay.. |
| 20:53:38 | flacoste | for some weird reason, that directory didn't show in the File viewer |
| 20:53:50 | nanok | so i think i will play more with it before i call it a "fly" |
| 20:53:52 | flacoste | and the database never finished building |
| 20:53:58 | petur | BiptoN: wiki name? |
| 20:54:10 | Domonoky | flacoste: just change the fileview in rockbox to all, and you will see hidden folders.. :-) |
| 20:54:29 | karashata | flacoste: the directory may be hidden, try changing the file view in Rockbox to "all" instead of "supported" |
| 20:54:36 | flacoste | Domonoky: ok, music is a special 'hidden' folder |
| 20:54:53 | flacoste | but anyway, I moved the files under root and I can now browse them |
| 20:55:02 | nanok | flacoste: the "permanent" solution is to move the music to something the of won;t hide everytime |
| 20:55:09 | flacoste | but the database contains like 10 duplicates of every song |
| 20:55:10 | nanok | untill we have usb support, at least.. |
| 20:55:38 | flacoste | i rebuild many times since I never was able to access the files from the DB view |
| 20:55:42 | * | petur prods BiptoN awake |
| 20:55:44 | flacoste | so that may have cause this duplication |
| 20:55:52 | * | karashata suggests keeping the music in the root folder, as long as your folder structure is decent |
| 20:55:53 | | Quit alienbiker99 ("( www.nnscript.de :: NoNameScript 4.02 :: www.XLhost.de )") |
| 20:55:58 | flacoste | Is there some way to reset the DB? |
| 20:56:10 | flacoste | I tried both 'Initialize database' and 'Update now' but nothing changed |
| 20:56:15 | nanok | flacoste: re-initialize? |
| 20:56:19 | nanok | hm |
| 20:56:26 | Domonoky | flacoste: you could try to delete all *.tcd files in the rockbox dir, and reinit the db.. |
| 20:56:40 | karashata | would deleting the database files in the .rockbox folder help? |
| 20:56:45 | flacoste | Domonoky: ok, that's what I was wondering, which files I should delete |
| 20:56:55 | flacoste | so *.tcd files are the DB |
| 20:56:59 | | Quit crashd ("leaving") |
| 20:56:59 | flacoste | i'll nuke them, thanks |
| 20:57:00 | Domonoky | jup |
| 20:58:41 | | Join crashd [0] (i=foobar@lostnode.org) |
| 20:58:50 | BiptoN | petur: wiki name ? how bout Microtrack 24/96? |
| 20:59:03 | petur | BiptoN: your wikiname |
| 20:59:13 | petur | did you already register? |
| 20:59:22 | | Join webguest38 [0] (i=4396db20@gateway/web/cgi-irc/labb.contactor.se/x-d897331d861bffec) |
| 20:59:29 | petur | FirstnameLastname style only |
| 20:59:43 | webguest38 | howdy |
| 21:00 |
| 21:00:08 | webguest38 | anyone online |
| 21:00:11 | webguest38 | ? |
| 21:00:23 | BiptoN | petur: i have an account for the fand what not, is that different |
| 21:00:44 | petur | eh? |
| 21:00:45 | | Quit webguest38 (Client Quit) |
| 21:00:52 | | Join webguest38 [0] (i=4396db20@gateway/web/cgi-irc/labb.contactor.se/x-05e9bafe7f2bb4b1) |
| 21:01:05 | | Quit webguest38 (Client Quit) |
| 21:01:15 | petur | BiptoN: you need to register on the wiki and give me that name so I can give it write access |
| 21:01:33 | petur | BiptoN: http://www.rockbox.org/twiki/bin/view/TWiki/TWikiRegistration |
| 21:02:01 | BiptoN | ok |
| 21:03:45 | preglow | if this piece of asm works on the first try... |
| 21:04:01 | BiptoN | petur: JasonLyons |
| 21:05:08 | petur | BiptoN: done |
| 21:06:27 | | Quit webguest17 ("CGI:IRC (EOF)") |
| 21:06:35 | BiptoN | thank you |
| 21:06:49 | | Join Zagor [0] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) |
| 21:07:21 | preglow | it didn't... |
| 21:08:02 | karashata | preglow: have you ever had a piece of asm work for you on the first try? |
| 21:08:03 | * | petur hands preglow a beer anyway ;) |
| 21:09:14 | * | jhMikeS wonders what preglow is doing |
| 21:09:27 | * | preglow thanks petur with tears in his eyes |
| 21:09:30 | preglow | jhMikeS: iir_mem16 for arm |
| 21:09:41 | jhMikeS | which codec? |
| 21:09:56 | | Quit J3TC- (Read error: 110 (Connection timed out)) |
| 21:09:57 | preglow | speex |
| 21:10:25 | preglow | jhMikeS: there's been talk of using speex as a statically linked voice codec, and i thought i'd just go ahead and optimize for arm to see how well suited it is for all platforms |
| 21:10:38 | preglow | it's nice on coldfire, but not so fast on arm right now |
| 21:11:13 | | Quit BiptoN ("CGI:IRC (EOF)") |
| 21:11:37 | jhMikeS | should a statically linked codec be as general as the loadable one? |
| 21:11:49 | preglow | depends what you mean |
| 21:12:30 | jhMikeS | if anything can be removed if voice format could be restricted somehow (and I'd love to not have swapping) |
| 21:12:51 | preglow | jhMikeS: yes, sure, i'm currently stripping it as far as i can |
| 21:13:29 | preglow | it's still sizable, though, around 50kb for coldfire |
| 21:13:43 | preglow | but, that's including main codec handling, ogg container handling plus floating point code |
| 21:13:57 | preglow | i believe it should be doable to get it down to around 35-40kb |
| 21:14:05 | NHeal | (timeout) calvino.freenode.net irc.freenode.net |
| 21:14:07 | preglow | jhMikeS: and yes, the whole point is to not have to swap |
| 21:14:49 | nanok | hm, nice. i switched from bass/treble to equalizer (some preset), to check again if power consumption is indeed much higher (i think it is, right?) |
| 21:14:56 | jhMikeS | hmmm...any way to lease buffer space and make it not take memory at all times if one doesn't use voice? |
| 21:15:16 | nanok | the battery level went (as reported) in about 10 minutes from some 47% to 48% something |
| 21:15:19 | nanok | :) |
| 21:15:52 | scorche|w | nanok: battery reporting is not that precise |
| 21:16:14 | preglow | ok, now speex sounds like something close to morse code... |
| 21:16:16 | nanok | at this rate, i will have to put some small high intensity led or something, to not overcharge it while not plugged in :-P |
| 21:16:25 | nanok | scorche|w: yeah, i know ;) |
| 21:16:36 | jhMikeS | preglow: well, that might do just as well :) |
| 21:16:43 | preglow | jhMikeS: really cheap voice codec :P |
| 21:17:05 | preglow | nanok: it should be a fair deal higher, yes, depending on platform |
| 21:17:12 | scorche|w | well, that really doesnt prove anything then...you will need to do a full bettery bench |
| 21:17:54 | preglow | jhMikeS: what, you mean unloading the codec from ram when not in use? i don't think we're going to miss 40kb much on swcodec |
| 21:17:58 | nanok | preglow: at first, when i used eq with corssfeed and dithering (all the good stuff ;) ), it scared me. i think it was not more than five hours |
| 21:19:07 | nanok | but lately, with some decent, "honest" usage, i seem to come close to 16hrs in theory (i get about 8hrs, and have more than 50 percent reported. but this, ofcourse, can mean anything, i will not know till i drain it) |
| 21:19:15 | Domonoky | does somebody know if it would be possible to provide the features file alongside the voice files on the rockbox servers ? ( the it would be possible to let rbutil generate voicefiles) ?? |
| 21:19:19 | nanok | however it is surely much more than my first impressions |
| 21:19:19 | preglow | nanok: what player do you have? |
| 21:19:27 | nanok | preglow: sansa e200 |
| 21:19:36 | preglow | nanok: it shouldn't cause it to drop to 5 hours |
| 21:19:46 | preglow | but eq + cf + dithering will max your cpu very nicely, yes |
| 21:19:56 | jhMikeS | preglow: meh...still 40K I'd rather have back. anyway, will it run on CF sans IRAM? |
| 21:19:58 | nanok | i understand getting up to 16h wit rockbox on this one is quite an achievment (but doable) |
| 21:20:13 | preglow | jhMikeS: it will do so, but it'd be better to give it some, it really doesn't require much iram |
| 21:20:31 | preglow | jhMikeS: i did a quickndirty hack and had it down to 9kb iram |
| 21:20:37 | preglow | probably can shave more |
| 21:20:39 | | Quit criznach ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") |
| 21:20:46 | preglow | as a matter of fact, it's probably less now i've stripped some stuff out |
| 21:20:49 | nanok | preglow: yes, i should think so indeed. but crossfeed i really need, i love it. i think it is my favourite feature so far |
| 21:20:51 | jhMikeS | preglow: then some IRAM will need to be dedicated to it if swapping is no longer done. |
| 21:21:04 | nanok | but eq, most of the time, i think i can do without |
| 21:21:06 | preglow | nanok: crossfeed is cheaper than a full eq |
| 21:21:16 | preglow | jhMikeS: i think we have free iram lying around as it is |
| 21:21:24 | nanok | preglow: that's what i noticed also, yes |
| 21:21:36 | preglow | nanok: yeah, crossfeed is perhaps two eq bands or something |
| 21:21:44 | jhMikeS | preglow: last time I tried some free IRAM in DSP, I ran out :) |
| 21:21:49 | preglow | the equivalent of |
| 21:22:11 | preglow | jhMikeS: mreally. well, it'll run without, but it'll be plenty slower, of course |
| 21:22:13 | jhMikeS | just added some functions...hardly 9k. |
| 21:22:23 | nanok | preglow: but i want to play more with this during the following days, and see if i can come up with some empirical guide. i noticed people ask sometimes on the list, and it was hard for me to find info about it at first |
| 21:22:37 | preglow | nanok: well, i coded all those features, so feel free to ask |
| 21:22:48 | nanok | maybe it would be nice to have some "wuick and dirty power-related hints" |
| 21:23:08 | nanok | preglow: aahm :). great to meet the maker ;) |
| 21:23:13 | jhMikeS | preglow: then we can use a speex format that's cheaper to decode, no? |
| 21:24:02 | | Quit amiconn (Nick collision from services.) |
| 21:24:06 | preglow | jhMikeS: deed, i plan to |
| 21:24:11 | | Join amiconn [0] (n=jens@rockbox/developer/amiconn) |
| 21:24:21 | preglow | jhMikeS: there's a choice of nb, wb and uwb (8khz, 16khz and 32khz), we'll go wb |
| 21:24:38 | preglow | nanok: anyway, what would be helpful would be a full benchmark with and without all those things |
| 21:24:44 | jhMikeS | hmmm...without swapping, speech could work in all plugins potentially...unless they want that IRAM as well. |
| 21:24:44 | | Quit The-Compiler (Read error: 104 (Connection reset by peer)) |
| 21:24:46 | preglow | so at least one can easily see what the worst case usage is |
| 21:24:57 | nanok | preglow: like a battery bench out file? |
| 21:25:11 | preglow | nanok: there's a plugin for it |
| 21:25:16 | nanok | preglow: yeah, why not, |
| 21:25:28 | nanok | preglow: i know, i have to play with it |
| 21:25:34 | preglow | nanok: you start the plug, exit it, then just leave the player running, playing a set of files until it shuts down |
| 21:25:52 | preglow | nanok: just make sure the testing conditions are known, like be sure to use only files of the same codec, at near the same bitrate |
| 21:26:18 | * | jhMikeS doesn't understand the e200 battery life issues and has never been able to drain his e200 over a few days use |
| 21:26:44 | nanok | preglow: aham, i get the point |
| 21:26:50 | amiconn | jhMikeS: The speech codec iram would be core iram, nothing to do with plugin/codec iram |
| 21:27:16 | preglow | jhMikeS: anyway, i guess you should know if getting rid of the codec swap would simplify playback.c noticably |
| 21:27:18 | jhMikeS | but it could be made available is what I'm saying |
| 21:27:49 | jhMikeS | preglow: I'd love that...and you bet it would |
| 21:27:51 | Lear | nanok: battery time reporting on sansa is far from precise, but you perhaps know that already... |
| 21:28:07 | nanok | i have to think about how to do this, because i was planning to do the non-informal one at work (which is doable, no problem), but the problem i am now addicted to it. and during the night i have no choice but to charge the damn thing |
| 21:28:18 | nanok | addiction is a tricky thing |
| 21:28:19 | jhMikeS | would also make multithreaded codecs much simpler since no thread parking need be done |
| 21:28:34 | pixelma | battery bench doesn't log anything currently on Sansa |
| 21:28:45 | Lear | It does, with a small patch. |
| 21:28:45 | nanok | why the hell didn;t they just fit an aa battery compartment to it. what;s wrong wit everybody these days, with this liion stuff :) |
| 21:29:28 | nanok | Lear: so the suplied plugin with the "current" builds will not log? |
| 21:29:44 | nanok | i haven't had a chance to play with it yet |
| 21:29:55 | preglow | jhMikeS: well, then i'd very much surprised if any better candidate for a statically linked voice codec than speex will show up, it's meant for voice, gives nice files at low bitrate, is small both code and data wise, and has the potential to be very fast |
| 21:29:58 | pixelma | Lear: there was a short discussion about it on Saturday IIRC with JdGordon. He wanted to look into the "correct" fix |
| 21:30:05 | Lear | No, apparently not (I read up on it on the wiki and applied the patch before trying it). |
| 21:30:42 | amiconn | Lear: You mean a hack. The proper solution would be using the ata callbacks in battery_bench |
| 21:31:07 | preglow | amiconn: right, arm is little endian, the first word will be in the lower part of a register....... |
| 21:31:12 | nanok | Lear: patch to the source tree, or on the "binary" build |
| 21:31:15 | Lear | amiconn: Yes, the patch was a hack, only good for flash targets. |
| 21:31:16 | jhMikeS | preglow: chop chop then. I'd rather have swapping gone than have to concoct some weird interface to swap a dual-core SPC codec...and I really want to commit that. |
| 21:31:25 | preglow | jhMikeS: am on it |
| 21:31:26 | Lear | nanok: Source patch. |
| 21:31:29 | scorche|w | nanok: li-ion is a superior technology in most all aspects... |
| 21:31:29 | karashata | nanok: presumably Li-ion batteries can provide better battery-life times than standard AAs |
| 21:31:47 | karashata | not to mention what scorche|w said |
| 21:32:02 | nanok | karashata: for the same weight, sure |
| 21:32:18 | scorche|w | per charge, yes...the only area they lose to Ni-MH really is amount of cycles total |
| 21:32:41 | nanok | well, the point is "portbility". i like standard stuff, it means i am completely independent. but nevermind, this is a holly war |
| 21:32:51 | * | karashata nods slightly |
| 21:33:21 | preglow | argh, i need a real beer |
| 21:33:35 | | Part chandlerc ("Leaving") |
| 21:33:35 | nanok | sufice to say: liion is not "standardized" (didn;t get into aa like nimh did) probably because it would be too bloody dangerous to do so (bllow-up kind of dangerous) |
| 21:34:13 | amiconn | Hrrmm, lcd_yuv_blit() needs some more work with my idea how to speed up bcm operation... |
| 21:34:21 | * | karashata has never had issues with Li-ion or Li-poly batteries "blowing up" on him, thankfully |
| 21:34:33 | nanok | scorche|w: indeed. and these days, the number of cycles is not so important anymore |
| 21:34:49 | scorche|w | nanok: hrm?...what "standardized" are you referring to? |
| 21:34:49 | nanok | with rechargeables being so cheap (even liion ones) |
| 21:34:56 | scorche|w | and actually, lets move this to -community... |
| 21:35:06 | jhMikeS | preglow: maybe I should change the codec malloc crud and dump the huge malloc buffer. that's 10x the size of a core speex decoder. |
| 21:35:16 | nanok | scorche|w: i mean like stuff you can find anywhere(think "gas station") and can replace on the go |
| 21:35:50 | scorche|w | i can find a power outlet more places than i can buy a battery |
| 21:35:56 | scorche|w | but as i said, lets move to -community ;) |
| 21:36:08 | nanok | stuff you can recharge with many different chargers, stuff you use in many other appliances without any modifications |
| 21:36:12 | preglow | jhMikeS: i've had a look, and the only two decoders that seriously rely on malloc right now are faad and tremor |
| 21:36:20 | | Join MournBlade [0] (n=me@ip68-1-89-124.pn.at.cox.net) |
| 21:36:30 | nanok | scorche|w: indeed :). and this is also flame material, so no point to go on here ;) |
| 21:36:31 | preglow | jhMikeS: the rest use mallocs either for seek table or container handling, and not many do even that |
| 21:36:47 | * | scorche|w sighs |
| 21:37:08 | jhMikeS | preglow: I think tremor was updated to use the slack space by tomal |
| 21:37:30 | preglow | faad should be easy to convert to static alloc |
| 21:37:39 | preglow | tremor will be the hardest, vorbis is designed not to have limits |
| 21:38:02 | jhMikeS | it has a cumtom implementation that allows free to work |
| 21:38:33 | preglow | what the hell, that is one of the most disappointing speedups ever |
| 21:38:49 | preglow | i bloody HATE asm optimizing for arm, you never know if you're throwing your time out the window until you've done it |
| 21:39:29 | | Quit ilgufo ("So Long, and Thanks For All the Fish - http://gufo.wordpress.com") |
| 21:39:50 | | Quit MajorC () |
| 21:39:53 | amiconn | Yay, my method works! :) |
| 21:39:55 | jhMikeS | regardless of what may be said about ARM7, it seems to matter re: load stalls there too. |
| 21:39:59 | amiconn | 56.5fps @80MHz |
| 21:40:20 | amiconn | That's till not the best way, just a quick test... |
| 21:40:21 | | Quit scorche|w ("CGI:IRC (EOF)") |
| 21:40:57 | | Join scorche|w [0] (n=8dc5049d@rockbox/administrator/scorche) |
| 21:43:11 | jhMikeS | preglow: and I know what you mean about ARM. most of the IDCT speedup for video came from dropping multiplication...not from asm. |
| 21:43:54 | jhMikeS | and even that wasn't drastic like you'd see with emac |
| 21:44:24 | preglow | brb, need to see a trailer park boys ep :V |
| 21:44:30 | preglow | can't drop muls here anyway |
| 21:45:10 | jhMikeS | yeah, I know, bugger |
| 21:49:19 | | Join GeekK [0] (n=opera@195-241-211-240.dsl.ip.tiscali.nl) |
| 21:49:57 | GeekK | hello |
| 21:50:11 | * | GeekK proud X5L newbie owner ;-) |
| 21:52:23 | Lear | jhMikeS: Malloc buf isn't always enough for Tremor, so I don't see how the slack space would be enough... |
| 21:53:01 | | Part GeekK |
| 21:53:18 | linuxstb | Are the memory requirements known in advance of decoding, or is it a frame-by-frame thing? |
| 21:53:29 | | Join [g2] [0] (n=tom@cpe-076-182-082-021.nc.res.rr.com) |
| 21:54:12 | nanok | oh, btw, speaking about insects.. |
| 21:54:32 | [g2] | anyone playing with the 3g nanos ? |
| 21:54:41 | amiconn | Lear: tomal got Tremor working somehow on iFP... |
| 21:54:48 | nanok | that mp3 stopping to play "randomly"bug is still here, in the build i just downloaded 1/2h ago or so |
| 21:55:16 | jhMikeS | Lear: then I guess that is a problem. I got the impression is was more than sufficient. |
| 21:55:19 | linuxstb | [g2]: No-one has mentioned that they are. |
| 21:55:32 | amiconn | Isn't this variant called tremor-lowmem? :> |
| 21:55:40 | nanok | and btw btw: is there a place one can get older "current" builds? |
| 21:55:48 | [g2] | linuxstb: The apple video nanos |
| 21:56:02 | Zagor | oh ffs, kernel oops again :( |
| 21:56:02 | jhMikeS | amiconn: he just implemented a stack for temp memory that is full descending |
| 21:56:12 | linuxstb | [g2]: Yes, I know what the 3g nanos are... |
| 21:56:30 | linuxstb | Zagor: Byeeee... |
| 21:56:36 | | Quit Zagor ("here we go again") |
| 21:56:49 | [g2] | linuxstb: oh... sorry... THX |
| 21:57:05 | nanok | linuxstb: linux kernel, i take it? .. |
| 21:57:48 | karashata | nanok: there's a link to the daily builds page on the current build page |
| 21:57:59 | karashata | and from there you can get archived daily builds for your player |
| 21:58:31 | nanok | karashata: must have missed it, let me check |
| 21:58:38 | | Join Genre9mp3 [0] (n=yngwiejo@88.218.17.216) |
| 21:58:50 | nanok | karashata: aaaah |
| 21:58:52 | | Quit ompaul (Client Quit) |
| 21:58:54 | nanok | got it, thanks :) |
| 21:58:56 | nanok | silly me |
| 21:58:58 | karashata | you're welcome |
| 21:59:27 | Lear | linuxstb: For tremor, it comes from the codebooks (in the file), so they should be possible to calculate up front. Might need a fair bit of code though. |
| 21:59:31 | karashata | is okay, I think they're trying to hide them in plain sight because they like to push using the most current build |
| 21:59:31 | nanok | karashata: i actually went there at first, to get the fonts, as documented |
| 21:59:32 | jhMikeS | I think libmpeg2 may need a similar thing since libmpeg2_reset won't work correctly atm (it needs to free YUV buffers and the FB) |
| 21:59:54 | linuxstb | Lear: I was just wondering if it could be allocated on the audio buffer... |
| 21:59:58 | karashata | nanok: the fonts are actually available under the "extras" link on the side nav menu too |
| 21:59:58 | Lear | amiconn: Yes, there is. Got it running on coldfire, but it was real slow. |
| 22:00 |
| 22:00:16 | linuxstb | But that wouldn't help low-mem targets... |
| 22:01:03 | | Join Zagor [0] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) |
| 22:01:34 | Lear | amiconn: Still needs to allocate something like 70-100 kB or so. |
| 22:03:03 | amiconn | It thought we were already using -lowmem |
| 22:04:17 | amiconn | *I |
| 22:05:24 | jhMikeS | why can't MoB allocate these buffers for certain codecs and not others anyway? |
| 22:05:25 | | Join Domonoky_ [0] (n=Domonoky@e180246213.adsl.alicedsl.de) |
| 22:06:05 | amiconn | Would be a waste (if I understand your idea correctly) |
| 22:06:34 | | Quit freqmod_nx (Remote closed the connection) |
| 22:07:10 | | Quit spiorf (Remote closed the connection) |
| 22:07:25 | jhMikeS | Why? Is the slack space enough for the two big malloc users? |
| 22:08:01 | preglow | amiconn: i don't think we're using low-mem |
| 22:08:16 | preglow | jhMikeS: malloc buffer isn't enough? that's insane, then there's a memory leak |
| 22:08:54 | amiconn | jhMikeS: Think about 10 small tracks in the buffer, each having a buffer allocated, even though only one of the buffers will be in use at any time |
| 22:08:55 | jhMikeS | I think Lear was implying slack space wasn't enough. |
| 22:09:15 | amiconn | That's waste more space than the malloc buffer |
| 22:09:33 | | Join freqmod_nx [0] (i=freqmod@dhcp208-90.ed.ntnu.no) |
| 22:09:35 | jhMikeS | amiconn: one codec _type_...one buffer. not an buffer instance for each track. |
| 22:09:36 | | Join barrywardell [0] (n=barrywar@89-125-27-10.dhcp-ripwave.irishbroadband.ie) |
| 22:09:43 | amiconn | How different is tremor-lowmem from ordinary tremor? |
| 22:09:48 | Lear | Yes, it isn't. But only for old beta 4 encoded files. And leaks aplenty there are, as in the codec world, free is a nop... :) |
| 22:10:37 | amiconn | jhMikeS: And how would that work? The buffer from a track already flushed can no longer be used... |
| 22:10:43 | * | jhMikeS considers a real moveable memory allocator |
| 22:10:46 | linuxstb | Would anyone complain if we dropped support for beta4 files? |
| 22:10:52 | amiconn | eurgh |
| 22:10:56 | jhMikeS | amiconn: some special handling |
| 22:11:26 | Lear | amiconn: Short story (as well as I can describe it anyway): don't do a full codebook decode on init, then do the remaining decoding as needed (repeatedly). |
| 22:11:33 | jhMikeS | why shouldn't they have one where free works and compacts it too? |
| 22:11:36 | | Quit nicktastic ("Leaving") |
| 22:12:15 | Lear | There's a bug on the tracker about some files not working. |
| 22:12:21 | | Quit barrywardell (Client Quit) |
| 22:13:00 | amiconn | Lear: Afaik, the Tremor version in rockbox svn already received quite some optimisation. I wonder whether (most of) these optimisations could be applied to -lowmem |
| 22:13:17 | jhMikeS | amiconn: I think something other than association with "track" would need to exist. |
| 22:13:23 | preglow | linuxstb: you mean floor0? |
| 22:13:48 | Lear | I did copy most of them (that were done at the time). At least involving inline asm in in header files. |
| 22:14:04 | amiconn | Tremor is one of the monster codecs. The other one is aac |
| 22:14:08 | linuxstb | preglow: I mean whatever Lear meant... i.e. these memory-guzzling vorbis files. |
| 22:14:22 | preglow | why do they guzzle memory? |
| 22:14:29 | preglow | apart from the sheer fun involved |
| 22:16:56 | Lear | I suspect the slowness came from table chasing. In "normal" Tremor, a codebook lookup is basically one table lookup. In -lowmem, the same operation involves several lookups, in different tables. |
| 22:19:35 | *** | Saving seen data "./dancer.seen" |
| 22:20:22 | | Nick parafin is now known as parafin|away (i=parafin@paraf.in) |
| 22:21:15 | | Quit Genre9mp3 ("I don't suffer from Rockbox psychosis. I enjoy every minute of it.") |
| 22:22:09 | preglow | amiconn: what would be the fastest way of doing a speex style symmetric clip in arm code? |
| 22:23:38 | amiconn | I think on arm it might be possible to use 2 comparisons and play with the condition bits |
| 22:23:46 | | Quit Domonoky (Read error: 110 (Connection timed out)) |
| 22:23:48 | amiconn | That would save the offseting |
| 22:24:30 | amiconn | And the 32767 would be needed just once when using both cmp and cmn |
| 22:24:37 | preglow | yes, i do that now |
| 22:24:59 | preglow | currently i load 32767 to a reg, do a cmp, high clip with the same constant, cmn, but then i need to generate -32767 |
| 22:25:11 | preglow | i'd like to do it with no branches :/ |
| 22:25:27 | | Join jac0b [0] (n=jac0b@user-1120o4e.dsl.mindspring.com) |
| 22:26:07 | jac0b | has anyone had a issue with MOB. I think I am having a problem with it. |
| 22:26:31 | jac0b | if I skip a couple track my harddrive just spins forever |
| 22:26:52 | jac0b | and the wps won't show the correct song info |
| 22:26:57 | amiconn | preglow: I think the symmetric clip should be just 4 instructions (no branch) on arm if you have the 32767 preloaded in a register |
| 22:27:01 | jac0b | I have to restart for it to stop |
| 22:28:09 | preglow | amiconn: i just figured it out |
| 22:28:12 | preglow | amiconn: using rsc |
| 22:28:49 | preglow | amiconn: cmp rx, rconst \n movgt rx, rconst \n cmn rx, rconst \n rcslt rx, rconst, #0 |
| 22:28:52 | preglow | amiconn: that should do it |
| 22:29:14 | preglow | rsc, btw |
| 22:29:36 | amiconn | I'd think you need rsblt |
| 22:29:39 | jac0b | has anyone had that problem? |
| 22:30:08 | amiconn | rsc is with carry - and you don't know what it's set to |
| 22:30:54 | preglow | amiconn: yes, of course rsb... |
| 22:32:16 | preglow | i don't need to worry about sp being wrong on arm, right? unless i call something, of course |
| 22:32:43 | | Part jac0b |
| 22:33:14 | amiconn | I think you could - but I never count on that |
| 22:33:27 | preglow | i intend to if i can, that's one extra register |
| 22:34:31 | | Quit Zagor ("Client exiting") |
| 22:37:22 | bertrik | amiconn: do you have some time to walk through some playback.c weirdness with me? |
| 22:39:32 | | Quit Ebert () |
| 22:41:25 | bertrik | i have a feeling that the recent sansa e200 playback problems could be caused by something in playback.c |
| 22:42:20 | bertrik | the way that function audio_clear_track_entries is called looks wrong, at least it violates the principle of least surprise |
| 22:43:28 | bertrik | it walks through the track entries from the write pointer to the read pointer and unbuffers all tracks in between |
| 22:45:09 | bertrik | however in at least three places, the write pointer is assigned with the value of the read pointer *before* calling audio_clear_track_entries, causing *all* entries to be unbuffered |
| 22:47:20 | amiconn | I am no playback.c expert at all |
| 22:47:28 | Lear | bertrik: Nico_P or lostlogic would be better to discuss that with, I think. |
| 22:47:33 | amiconn | And I am still busy with lcd stuff |
| 22:48:37 | bertrik | ok, lostlogic can you have a look with me? |
| 22:49:48 | | Part [g2] |
| 22:50:40 | | Quit jgarvey ("Leaving") |
| 22:54:16 | | Join spiorf [0] (n=spiorf@host216-206-dynamic.14-87-r.retail.telecomitalia.it) |
| 22:57:29 | | Join safetydan [0] (n=safetyda@rockbox/developer/safetydan) |
| 22:58:44 | amiconn | linuxstb: Btw, as you mentioned the brightness test function - there's also a hdd power test function in the rom... |
| 22:59:09 | amiconn | That one isn't reachable from diag mode, I guess it's available via the debug shell |
| 23:00 |
| 23:03:54 | flacoste | ls |
| 23:05:48 | | Quit flacoste (Remote closed the connection) |
| 23:06:16 | preglow | amiconn: brightness test? as in lcd? |
| 23:06:33 | | Join qweru [0] (n=kvirc@bb-87-80-66-156.ukonline.co.uk) |
| 23:06:44 | amiconn | yes |
| 23:06:45 | preglow | amiconn: that information would be very interesting.... |
| 23:07:00 | preglow | amiconn: debug shell? do we know how to get there? |
| 23:07:09 | amiconn | I think it's serial |
| 23:07:22 | amiconn | Not sure how to enter it |
| 23:07:47 | amiconn | It's just stuff I found while disassembling the whole G5.5 rom |
| 23:09:46 | jmspeex | preglow: The 4.8 kbps mode is something I wrote specifically for UT2004, but it has bit-rot since then. It's not in the spec, so you shouldn't worry about it. |
| 23:10:56 | preglow | jmspeex: ut2k4 used such a low bitrate mode? talking network play then, i assume? |
| 23:11:23 | preglow | amiconn: are you disassembling those functions? if not, i'd be very interested in hearing which offset it's at |
| 23:11:57 | amiconn | I already disassembled them (raw), but don't understand yet what they do |
| 23:12:32 | amiconn | Tey do a lot of calculation with their parameters, then fiddle both with the gpio port range (calculated addresses), and 0x70000080 |
| 23:12:52 | amiconn | Hrrm, and I have a bug in my fast lcd update :\ |
| 23:12:59 | jmspeex | preglow: Yes, it's for player comm |
| 23:13:26 | preglow | amiconn: i'd love to not have to use pwm for backlight fading |
| 23:13:45 | preglow | jmspeex: why did you include that mode in the official code if it's only for ut2k4? |
| 23:14:12 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 23:15:36 | jmspeex | preglow: It's disabled by default, but I thought some people could find it useful as well (there's nothing UT-specific) |
| 23:15:48 | preglow | jmspeex: ahh, i didn't notice that |
| 23:16:28 | preglow | jmspeex: anywho, i've spread #ifndef SPEEX_DECODER_ONLY around tons of places now, it's not pretty, but i've managed to shave off quite a bit of code size |
| 23:16:51 | jmspeex | how much code have you shaved off? |
| 23:17:45 | | Quit TotallyInfected () |
| 23:17:47 | preglow | doing a comparison right now |
| 23:18:20 | jmspeex | preglow: So you've disabled the analysis/quantisation functions in ltp.c, quant_lsp.c, lsp.c, vq.c, ...? |
| 23:18:27 | amiconn | #ifndef SPEEX_DECODER_ONLY looks weird. Negating a non-feature |
| 23:18:46 | amiconn | Why not #ifdef SPEEX_ENCODER ? |
| 23:18:59 | preglow | jmspeex: from 85020 bytes to 50896 on boldfire |
| 23:19:01 | preglow | coldfire... |
| 23:19:50 | preglow | jmspeex: in other words, hardly worth the bother on anything but limited embedded targets |
| 23:19:54 | jmspeex | I thought it was a new range of CPUs :-) |
| 23:20:04 | preglow | jmspeex: it's trademarked as per right now! :D |
| 23:20:18 | | Quit stewball (Read error: 110 (Connection timed out)) |
| 23:20:34 | jmspeex | haha |
| 23:20:52 | preglow | jmspeex: but anyway, if we're linking this baby statically in the core, i want it to be as small as possible |
| 23:21:11 | preglow | jmspeex: oh, and btw, i just optimized iir_mem16 for arm, decent speedup for order 8, small for order 10 |
| 23:21:32 | jmspeex | why the difference? registers? |
| 23:21:46 | preglow | yep, for order 8 i keep all the mem[] array in registers |
| 23:21:51 | jmspeex | did you use DF1 or DF2T? |
| 23:21:56 | preglow | df2ty |
| 23:22:11 | jmspeex | starting from my assembly code? |
| 23:22:11 | preglow | it's kinda hard to use straight df1 since mem[] and y[] aren't the same size |
| 23:22:23 | preglow | no, i did it from scratch, didn't see any asm code for that |
| 23:22:37 | jmspeex | preglow: well, if you use df1, you don't use mem[] at all. |
| 23:23:08 | jmspeex | preglow: well, there was iir_mem2() in filters_arm.h |
| 23:23:17 | preglow | jmspeex: well, i'd need to use it at the start of the sequence |
| 23:23:22 | preglow | jmspeex: but that's a very decent point |
| 23:23:33 | jmspeex | what do you mean? |
| 23:23:47 | | Quit petur ("Zzzzz") |
| 23:23:53 | preglow | jmspeex: i assume you mean i'd just use y[i - 1], y[i - 2] etc for memory, right? |
| 23:24:12 | jmspeex | yes |
| 23:24:20 | preglow | jmspeex: in that case, i'd still need some place to store the previous frame's contents at the start of the next frame |
| 23:24:26 | preglow | i just assume that place would be mem[] |
| 23:24:37 | jmspeex | yes |
| 23:24:56 | jmspeex | preglow: didn't you do exactly that for coldfire (using my implementation in filters_bfin.h)? |
| 23:25:03 | | Join TotallyInfected [0] (n=ebola@pool-141-151-72-127.phlapa.east.verizon.net) |
| 23:25:04 | preglow | nopes |
| 23:25:08 | preglow | but i really should have |
| 23:25:08 | | Join Soap_ [0] (n=Soap@rrcs-70-61-25-246.central.biz.rr.com) |
| 23:25:20 | preglow | coldfire is made for that stuff |
| 23:25:23 | jmspeex | so you did the coldfire code in df1 form? |
| 23:25:28 | preglow | tdf2, yes |
| 23:25:35 | jmspeex | sorry, I meant df2t |
| 23:25:45 | preglow | yeah, i did |
| 23:25:58 | preglow | and i probably really should stop doing that |
| 23:26:05 | jmspeex | If your chip has a MAC, then df1 should really be faster |
| 23:26:09 | preglow | exactly |
| 23:26:35 | preglow | but anyway, what constraints will the output have? an all-pole filter kinda makes me worry about overflow |
| 23:26:42 | jmspeex | I need to cleanup the df1 C code... |
| 23:26:58 | preglow | i guess it's not a problem since the output is within limits for the tdf2 case anyway |
| 23:26:59 | jmspeex | what do you mean? |
| 23:27:14 | | Quit Soap (Nick collision from services.) |
| 23:27:19 | | Nick Soap_ is now known as Soap (n=Soap@rrcs-70-61-25-246.central.biz.rr.com) |
| 23:27:23 | preglow | forget it, i'm being stupid |
| 23:27:44 | | Join Soap_ [0] (n=Soap@rockbox/staff/soap) |
| 23:27:58 | jmspeex | Yes, the output has the same limits. I think the mem[] range is actually a factor of 2 off (don't remember which way), but it's OK. |
| 23:28:26 | jmspeex | (i.e. IIRC you couldn't mix DF1 with DF2T using the same memory) |
| 23:28:35 | preglow | nope, you can't |
| 23:28:42 | preglow | tdf2 is canonical, df1 isn't |
| 23:29:06 | | Quit Soap (Client Quit) |
| 23:29:15 | preglow | btw, i listened to an nb file without the actual lpc stage due to an error, sounded surprisingly good |
| 23:29:19 | jmspeex | preglow: I mean reusing the memory. And actually, in float I can. |
| 23:29:34 | jmspeex | yuk! |
| 23:29:42 | jmspeex | You probably had a high bit-rate |
| 23:29:50 | preglow | yeah, q8 vbr |
| 23:30:00 | preglow | did it sounds good thanks to the residual? |
| 23:30:07 | jmspeex | yes |
| 23:30:16 | preglow | it had plenty of articulation in it, and afaik, the codebook itself has little of that |
| 23:30:41 | jmspeex | theoretically, if you increase the bit-rate enough, you can reconstruct perfectly, even without LPC. Practically, that's just silly |
| 23:31:06 | preglow | well, sure, you'd pretty much be making a fancy variable length code wav codec :) |
| 23:31:06 | jmspeex | which codebook, what articulation? |
| 23:31:58 | jmspeex | basically, LPC is just there to easily reduce the signal's power with very few bits. |
| 23:31:59 | preglow | by articulation i mean i could actually discern what was said, vowels and all |
| 23:32:14 | jmspeex | of course, it would just have sounded a bit more "flat" |
| 23:32:26 | preglow | i thought the lpc filter basically modelled all the formants and stuff |
| 23:33:01 | jmspeex | did you disable on the decoder side or the encoder side? |
| 23:33:08 | preglow | decoder |
| 23:33:30 | preglow | happened when i was optimizing iir_mem16, i left the order 10 case a pure ""return; |
| 23:33:33 | jmspeex | then you lost part of the formants, but your ear probably compensated for that |
| 23:34:07 | jmspeex | preglow: BTW, it's worth checking that your implementation is bit-exact with mine −− or at least know where the differences are. |
| 23:34:19 | preglow | coldfire is bit-exact |
| 23:34:24 | preglow | arm isn't far enough along that i've bothered |
| 23:34:27 | preglow | working on qmf_synth now |
| 23:34:32 | jmspeex | good (it's easy to subtly sccrew things up) |
| 23:34:42 | preglow | yeah, i know, i actually had an error i noticed this way |
| 23:35:00 | preglow | i know of only one difference now, and that is the clipping in qmf_synth on coldfire |
| 23:35:10 | preglow | getting that for free was just too tempting, so it clips at -32768 |
| 23:35:18 | preglow | i have tested with several badly clipping files, and the result is good |
| 23:36:03 | * | Domonoky_ find it really nice to see codec authors involved with rockbox work.. :-) |
| 23:36:14 | preglow | Domonoky_: me too |
| 23:36:15 | preglow | :) |
| 23:36:19 | scorche|w | i am happy too :) |
| 23:36:22 | rasher | That's two.. |
| 23:36:25 | jmspeex | preglow: on ARM you can just use two comparison/conditional move pairs, overhead should be negligible. |
| 23:36:31 | | Join Soap [0] (n=Soap@rrcs-70-61-25-246.central.biz.rr.com) |
| 23:36:48 | preglow | jmspeex: i use cmp \n movgt \n cmp \m rsblt for clipping on arm |
| 23:36:48 | scorche|w | jmspeex: were you invited, or just found your own way in here? |
| 23:37:05 | jmspeex | preglow: Make sure it's still OK for uwb because then the output of qmf_synth will go in another qmf_synth |
| 23:37:22 | preglow | jmspeex: know, i've tested all three modes |
| 23:37:42 | jmspeex | scorche|w: Just found my way after talking to preglow |
| 23:37:55 | scorche|w | ah...nice :) |
| 23:37:55 | preglow | jmspeex: however, qmf_synth never negates the input it gets, so it should be fine unless any of the coefs are -32768, which they aren't, afaik |
| 23:38:12 | jmspeex | preglow: probably OK, then. |
| 23:38:52 | jmspeex | preglow: Maybe I should start hunting for NEG16 macros... |
| 23:39:20 | preglow | jmspeex: btw, you probably know this, but there are some small leftover float code here and there |
| 23:39:30 | preglow | jmspeex: are any of these problematic, or have you just not gotten around to fixing them? |
| 23:39:41 | jmspeex | preglow: where? |
| 23:39:52 | jmspeex | I'm aware of a few, but maybe I missed something as well. |
| 23:40:00 | preglow | let's see if i can find some again |
| 23:40:15 | jmspeex | There's a few things in initialisation, which I haven't been bothered with (will use a const table when I do) |
| 23:40:40 | preglow | bw_lpc(QCONST16(0.93f,15), st->interp_qlpc, lpc, st->lpcSize); |
| 23:40:45 | preglow | arhg, forget that |
| 23:40:47 | jmspeex | Then VBR and stereo code. The rest should be fine |
| 23:40:50 | preglow | coffee-vision |
| 23:41:43 | preglow | might have been i saw it in an EPIC_48K ifdef as well, i thought that was enabled, for some reason... |
| 23:41:44 | jmspeex | what else? |
| 23:42:04 | preglow | ahh |
| 23:42:05 | preglow | ol_pitch_coef=GAIN_SCALING*0.066667*quant; |
| 23:42:07 | preglow | that, for example |
| 23:42:13 | preglow | will be floating point code when assembled, afaik |
| 23:42:48 | jmspeex | yes, need to fix that. |
| 23:43:21 | preglow | i'll probably do the stereo thing sooner or later |
| 23:44:27 | safetydan | yay stereo! I think that's the most noticeable problem with speex in Rockbox |
| 23:44:48 | preglow | should be easy enough too, unless i'm missing something |
| 23:44:50 | jmspeex | safetydan: you really use stereo in rockbox. |
| 23:44:58 | jmspeex | ? |
| 23:45:08 | jmspeex | preglow: yes, it's very simple (and very crappy) |
| 23:45:31 | jmspeex | all it does is adjust the volume −− and it's not even that good at that. |
| 23:45:32 | preglow | just iir smoothed intensity stereo? |
| 23:45:52 | preglow | i wouldn't care much about stereo for speech anyway |
| 23:46:10 | jmspeex | pretty much. Plus, without sub-bands like decent intensity stereo implementations. |
| 23:46:31 | jmspeex | preglow: any other float stuff? |
| 23:47:02 | preglow | jmspeex: looking around now |
| 23:47:03 | * | amiconn found the problem in his faast G5 lcd update :) |
| 23:47:05 | safetydan | jmspeex: no, but it's about the only thing that doesn't work in speex decoding |
| 23:47:31 | amiconn | The BCM just doesn't like writing to unaligned addresses. It ignores those writes |
| 23:47:43 | jmspeex | safetydan: stereo is easily disabled if you can't decode it. In fact, if you ignore it, it goes away :-) |
| 23:47:45 | amiconn | Rounding to even x and width, and it works like a charm :) |
| 23:50:39 | | Join linuxstb_ [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 23:52:12 | | Quit linuxstb (Read error: 113 (No route to host)) |
| 23:53:33 | preglow | amiconn: these binutils people don't impress me with their bug-fixing speed yet either... |
| 23:54:06 | preglow | jmspeex: can't find any more, i'll let you know when i start looking for them for real |
| 23:54:25 | preglow | jmspeex: it's pretty easy to see when you've gotten rid of all, since our speex codec will shrink by 3.5kb then... |
| 23:54:39 | | Quit scorche|w ("CGI:IRC") |
| 23:55:07 | amiconn | preglow: Yeah. I received nothing apart from the 2 mails confirming my report and the attachment. |
| 23:55:38 | preglow | amiconn: i'll find someone on irc and bug them soon |
| 23:55:49 | preglow | there's bound to be some binutils people in the gcc channel |
| 23:57:08 | | Join kcbanner [0] (n=kcbanner@216.232.247.159) |
| 23:57:09 | kcbanner | Hey all |
| 23:57:17 | kcbanner | a friend of mine has a sansa e200, with rockbox on it |
| 23:57:26 | kcbanner | only problem is it doesn't detect and show up as a usb drive in windows |
| 23:57:30 | kcbanner | when rockbox is booted. |
| 23:57:52 | kcbanner | is there a common issue for this? |
| 23:57:57 | Domonoky_ | kcbanner: he should use the sansa firmware for usb until rockbox has usb .-) |
| 23:58:05 | kcbanner | OOoohhh :P |
| 23:58:14 | kcbanner | so thats not a feature yet :P |
| 23:58:27 | kcbanner | sansa has no usb support with rockbox? |
| 23:58:35 | preglow | cowrecked |
| 23:58:36 | Domonoky_ | not on mp3 players which have software usb |
| 23:58:40 | preglow | but it's being worked on |
| 23:59:00 | | Quit Soap (Read error: 104 (Connection reset by peer)) |
icon identifies that the person is a core developer (has commit access).