00:00:14 | J3TC- | Compiled fine with no problems and it's playing music fine and the plugins work fine too |
00:00:27 | | Quit ompaul (Client Quit) |
00:01:08 | CiNc028 | ill take your advice. because this is the first time im dealing with an ipod. |
00:07:06 | | Join lee-qid [0] (n=liqid@p549646F5.dip.t-dialin.net) |
00:07:39 | | Quit davina ("xchat on Ubuntu 7.04") |
00:10:22 | | Quit lee-qid (Client Quit) |
00:11:07 | | Quit desowin ("use linux") |
00:11:57 | lostlogic | J3TC-: thanks :) I'll be posting a more intrusive one shortly :-P |
00:13:25 | | Quit cooz ("zzz") |
00:13:51 | J3TC- | Cool, don't know what your patch does but good work ;) |
00:15:34 | lostlogic | J3TC-: just trying to clean up some potential and real bugs in MoB wihle Nico_P isn't looking :) |
00:15:58 | J3TC- | Lol, ninja-like |
00:16:00 | J3TC- | :3 |
00:16:40 | | Join defsquad [0] (i=cfcba0fe@gateway/web/cgi-irc/labb.contactor.se/x-d435225854a7f7e7) |
00:17:41 | | Quit CiNc028 () |
00:18:16 | | Quit defsquad (Client Quit) |
00:18:25 | | Quit Arathis ("Bye, bye") |
00:18:39 | | Join pauljam [0] (n=pauljam@vpn-3013.gwdg.de) |
00:19:18 | pauljam | do i have to run rockboxdev.sh as root? |
00:19:50 | Bagder | it depends on what paths you use |
00:20:45 | | Quit hcs (Read error: 104 (Connection reset by peer)) |
00:21:12 | | Join hcs [0] (n=agashlin@rockbox/contributor/hcs) |
00:23:16 | | Join defsquad [0] (i=cfcba0fe@gateway/web/cgi-irc/labb.contactor.se/x-117465afa8db8b14) |
00:24:01 | rasher | pauljam: if you modify it's paths it's entirely possible to run as any user. By default it needs root (or some rather strange peculiar permissions) |
00:26:07 | BigBambi | ls |
00:26:15 | BigBambi | oops, wrong window :) |
00:30:02 | | Join pauljam_ [0] (n=pauljam@vpn-3013.gwdg.de) |
00:30:03 | BigBambi | iPod hardware bods - are there any hardware restrictions on key combinations (such as on the H1x0 you can only have play + something) |
00:30:39 | | Quit defsquad ("CGI:IRC") |
00:30:48 | | Quit pauljam (Read error: 113 (No route to host)) |
00:32:38 | | Quit pauljam_ (Client Quit) |
00:33:38 | | Join PaulJam [0] (n=pauljam@vpn-3013.gwdg.de) |
00:35:12 | | Join saratoga [0] (i=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-c573027b09bc0d78) |
00:42:26 | przemhb | bye |
00:42:31 | | Part przemhb |
00:43:02 | | Quit matsl ("Riece/3.1.2 XEmacs/21.5-b28 (fuki, linux)") |
00:43:18 | | Quit spiorf (Remote closed the connection) |
00:46:40 | | Join Zagor_ [0] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) |
00:46:49 | | Part hcs |
00:47:51 | | Nick Zagor_ is now known as Zagor (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) |
00:51:54 | | Part linuxstb |
00:53:07 | toffe82 | Zagor: what do you need to know on the gigabeat S ? |
00:53:47 | | Quit amiconn (Nick collision from services.) |
00:53:53 | | Join amiconn [0] (n=jens@rockbox/developer/amiconn) |
00:54:23 | Zagor | toffe82: the contents of memory address 0x43F88000, 0x43F88120 and 0x43F88124 would be interesting. all are 32-bit words. |
00:56:14 | toffe82 | Zagor: how can I read them ? |
00:56:55 | Zagor | you need to modify the source to read them and output them on the screen or in a file. |
00:57:06 | toffe82 | Zagor: :) |
00:58:05 | toffe82 | Zagor: what are they suppose to contain ? the config of the usb ? |
00:58:18 | Zagor | yes, the module version and some parameters |
00:58:21 | JRoT | Zagor any progress with the usb speed of writing on the sansa? |
00:58:23 | | Quit Thundercloud (Read error: 104 (Connection reset by peer)) |
00:59:24 | Zagor | JRoT: no, I'm a bit stuck at the moment trying to find information that can help me proceed |
00:59:57 | toffe82 | Zagor: ther is a download with some source code for usb on coldfire on the freescale site, perhaps it can be of some inspiration |
01:00 |
01:00:16 | toffe82 | http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=CMX_USB-Lite&nodeId=0162468rH3YTLC6807&fpsp=1&tab=Design_Tools_Tab |
01:00:26 | toffe82 | the coldfire_usb_lite_cmx |
01:00:27 | Zagor | everything is worth a look at this point... |
01:00:36 | | Quit scorche|w ("CGI:IRC (EOF)") |
01:01:10 | Zagor | meh, is anyone registered there? |
01:01:42 | | Quit mf0102 ("Verlassend") |
01:02:14 | Zagor | haha, apparently I already am... |
01:03:33 | toffe82 | if you don't want to register, I can send it to you |
01:04:25 | | Quit ender` (" I love deadlines. I especially like the whooshing sound they make as they go flying by. -- Douglas Adams") |
01:05:19 | Zagor | I'd appreciate that. their password recovery function just bounces me to their front page |
01:06:11 | Zagor | ah, now it worked |
01:12:14 | | Quit PaulJam (".") |
01:13:45 | | Quit criznach ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") |
01:13:53 | | Join sd [0] (n=sd@81.201.60.183) |
01:14:26 | | Join keanu|afk [0] (n=keanu@unaffiliated/keanu) |
01:14:37 | lostlogic | Llorean: did you happen to catch when Nico_P was expecting to be back online? |
01:14:52 | | Quit keanu (Nick collision from services.) |
01:15:01 | | Nick keanu|afk is now known as keanu (n=keanu@unaffiliated/keanu) |
01:15:22 | sd | hello there |
01:15:24 | | Join karashata [0] (n=Kimi@pool2-220.adsl.user.start.ca) |
01:15:36 | | Join PaulJam [0] (n=pauljam@vpn-3013.gwdg.de) |
01:15:43 | PaulJam | i have tried the rockboxdev.sh script, but it seems as if something went wrong, can someone help me? http://pastebin.com/mae9c0a7 |
01:15:56 | sd | just wondering if someone happened to see STMP35XX_Player_SDK_2.510-RC2.rar file somewhere around |
01:16:03 | sd | (tried google, very hard) |
01:16:49 | Zagor | PaulJam: looks like your native gcc is broken |
01:17:04 | *** | Saving seen data "./dancer.seen" |
01:17:08 | Zagor | *** The command 'gcc -o conftest -g -O2 conftest.c' failed. |
01:17:32 | rasher | PaulJam: is this on linux or cygwin? |
01:17:40 | rasher | I'm pretty sure rockboxdev.sh doesn't work on cygwin |
01:18:20 | | Quit donutman25 ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") |
01:18:29 | PaulJam | this is on linux (ubuntu 7.10)i just installed it a few hours ago |
01:18:51 | saratoga | type which gcc and see what happens |
01:19:13 | PaulJam | /usr/bin/gcc |
01:19:52 | bluebrother | you're missing crt1.o. On my box that's part of the glibc-devel package |
01:21:07 | rasher | PaulJam: apt-get install build-essential |
01:21:09 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
01:21:52 | PaulJam | ah, i see bild-essential is not installed. |
01:22:57 | JRoT | I'm going to sleep it 1:23am here atm, good luck with coding especially you Zagor! |
01:23:08 | | Nick JRoT is now known as JRoT|Sleep (n=JRoT@ip4da03737.direct-adsl.nl) |
01:23:32 | rasher | Zagor: perhaps ac has hints about usb? |
01:24:54 | Zagor | rasher: I doubt it. my problems are in things he hadn't started implementing yet |
01:24:56 | PaulJam | i have now installed build essential, is there a way to skip the downloading part from rockboxdev.sh? |
01:25:25 | keanu | PaulJam, comment out the lines? ;) |
01:25:25 | bluebrother | I think the script only downloads the tarballs if they are missing |
01:29:25 | | Part toffe82 |
01:31:25 | saratoga | Zagor: what is your current trouble? |
01:32:13 | PaulJam | looks like it is compiling now, thanks for the help |
01:32:33 | Zagor | saratoga: I don't understand the relation between on-bus packet size and the size of the transactions I send to the controller. as far as I understand from the docs, they should not be related. but they are. |
01:34:09 | saratoga | is it possible to implement rudimentary UMS support without dealing with this problem? |
01:34:36 | Zagor | not reliably. |
01:35:53 | | Quit Toxicity999 (Remote closed the connection) |
01:36:04 | | Join midkay_ [0] (n=midkay@c-24-19-236-139.hsd1.mn.comcast.net) |
01:36:30 | | Join Toxicity999 [0] (n=bryan@unaffiliated/Toxicity999) |
01:37:41 | | Join advcomp2019_ [0] (n=advcomp2@unaffiliated/advcomp2019) |
01:40:36 | | Quit advcomp2019 (Nick collision from services.) |
01:40:38 | | Nick advcomp2019_ is now known as advcomp2019 (n=advcomp2@unaffiliated/advcomp2019) |
01:42:49 | lostlogic | Llorean: you said you'd explicitly gotten a data abort when hitting the buffering info screen during buffering, right? I know why. |
01:42:55 | lostlogic | at least mostly. |
01:45:48 | | Quit saratoga ("CGI:IRC (EOF)") |
01:46:27 | jhMikeS | lostlogic: I tend to take the approach that if I don't know why exactly, then I plain don't know. It's only a guess then. :) |
01:47:07 | lostlogic | well I know the proximate cause for sure :-P I just may not entirely know the root cause |
01:47:20 | | Quit PaulJam (".") |
01:48:21 | jhMikeS | I usually take that as a hint to keep staring instead of coding :p |
01:53:52 | | Quit midkay (Read error: 110 (Connection timed out)) |
01:53:59 | | Nick midkay_ is now known as midkay (n=midkay@c-24-19-236-139.hsd1.mn.comcast.net) |
01:54:21 | | Quit Toxicity999 (Remote closed the connection) |
01:54:58 | | Join Toxicity999 [0] (n=bryan@unaffiliated/Toxicity999) |
01:55:48 | | Quit bluebrother ("Lost terminal") |
01:56:48 | | Join RoC_MasterMind [0] (n=Free@c-66-177-39-225.hsd1.fl.comcast.net) |
02:00 |
02:00:45 | | Quit Zagor ("Client exiting") |
02:01:58 | | Quit rotator () |
02:03:49 | jhMikeS | Something else weird happens in the sim at least. If you back up in the buffer debug screen enough so it has to refill, it never stops reading metadata. |
02:04:25 | lostlogic | jhMikeS: oh good (sorta) I've had that happen with my changes and thought I'd caused it. |
02:04:40 | lostlogic | jhMikeS: want to look at the patch I'm working on? |
02:05:17 | lostlogic | http://test.lostlogicx.comtransfer/rockbox/20071026_buffering_adjustments2.patch |
02:07:58 | jhMikeS | sure. I'm making some coffee atm but will brb. |
02:08:33 | lostlogic | the data aborts are caused by a bad poitner getting into the linked list somehow, still havent found where that bad pointer gets in −− my latest test was to make things volatile to see if it might just ahve been a half-set poitner |
02:15:05 | lostlogic | hmm, I think I finally made enough of the right things volatile to have a noticeable improvement. |
02:16:13 | jhMikeS | why would volatile help anything? does something loop on something that gets changed externally? I don't recall seeing such things. |
02:16:42 | lostlogic | waht actually made a difference was making the next poiners within the loop volatile |
02:17:11 | jhMikeS | huh? |
02:17:14 | lostlogic | there are lots of times when the next poitners (and the three poitners into the list) are accessed and they could be modified on another thread, |
02:17:17 | jhMikeS | (can't get to patch btw) |
02:17:53 | lostlogic | my bad //test.lostlogicx.comtransfer/rockbox/20071026_buffering_adjustments2.patch |
02:17:59 | lostlogic | gah, I still suck |
02:18:01 | lostlogic | http://test.lostlogicx.com/transfer/rockbox/20071026_buffering_adjustments2.patch |
02:18:28 | jhMikeS | then the list operations need locking. |
02:18:49 | lostlogic | all list modifications are locked |
02:18:56 | lostlogic | but not all list reads can practically be |
02:19:11 | lostlogic | and so a locked write and an unlocked read are where it goes kaboom |
02:19:20 | | Join midgey [0] (n=tjross@westquad-188-65.reshall.umich.edu) |
02:20:22 | | Quit thegeek (Read error: 104 (Connection reset by peer)) |
02:20:23 | jhMikeS | sure...volatile is still a race condition there. the scheduler locks lists (usually by exchanging a busy value into the pointer), read or write. it must. |
02:21:10 | jhMikeS | I guess I need to look more closely to tell for sure myself anyway. I'm not too intimiate with this code yet. |
02:21:16 | lostlogic | yeah, I know it's still a race condition, but I'm so far at a loss on how to solve it. The reads are very frequent so any locking I can think of would come at too great of a cost |
02:21:38 | | Join thegeek [0] (i=thegeek@s220b.studby.ntnu.no) |
02:21:41 | | Part pixelma |
02:22:17 | jhMikeS | how often is the readin? |
02:22:20 | jhMikeS | -g |
02:23:01 | | Join Nico_P [0] (n=nicolas@rockbox/developer/NicoP) |
02:23:02 | lostlogic | every single call to the buffering API _potentially_ reads throught he list and at least reads from a list entry. |
02:23:40 | lostlogic | I guess one way to improve it would be to cache a whole entry off-list for the always-read part and lock around all actual list access. |
02:24:26 | lostlogic | still not sure what si up with the forever spinning |
02:24:37 | jhMikeS | I'm mean are we talking 100,000 accesses/sec or 10,000 or 100? |
02:26:32 | lostlogic | depends on the codec −− each data request from the codec is a potential list access |
02:26:45 | lostlogic | so I think that puts it in the 100s range though |
02:27:09 | | Join Mouser_X [0] (n=someone@207.155.176.3) |
02:27:45 | jhMikeS | bah, wouldn't think twice about mutexes then. Heck, full turnarounds on queue_send (which is rather elaborate) are just microseconds. |
02:28:08 | lostlogic | hmm, OK −− I'll work on it. |
02:28:22 | Nico_P | lostlogic: I feel stupid for making the mistake you fixed in your commit :p |
02:28:30 | lostlogic | Nico_P: :-P |
02:28:40 | * | Nico_P starts reading the logs |
02:28:53 | jhMikeS | If a mutex isn't locked, it's a very cheap op. Those queue_send benchmarks involved the full block/wake routines. |
02:28:55 | lostlogic | I'm planning to abuse your code soundly with my next one, whenever I get it owrking acceptably |
02:29:17 | Nico_P | lostlogic: what are you going to fo? |
02:29:19 | | Quit zicho (Remote closed the connection) |
02:29:19 | lostlogic | jhMikeS: that's a good poitn, so my objective is to avoid it becoming a contested lock |
02:29:24 | Nico_P | s/fo/do |
02:29:44 | jhMikeS | even that's just a few uS and will happen infrequently |
02:29:58 | lostlogic | the big change that I have written already and which I'll sort out fromt he rest and have you review is reworking move_handle and add_handle to better ensure contiguous allocations for those things which need them. |
02:31:22 | Nico_P | sounds nice |
02:31:55 | | Quit zardos ("CGI:IRC") |
02:33:57 | lostlogic | Nico_P: http://test.lostlogicx.com/transfer/rockbox/20071026_move_and_add_handle_contiguous.patch |
02:34:29 | lostlogic | it includes one additional call to update_data_counters and some const-ificatin of things that aren't modified just for tightness-sake too. |
02:34:51 | lostlogic | Nico_P: I _don't think_ it makes anything worse and it improves certain cases for me |
02:34:59 | lostlogic | but please let me know if I've broken anything for you. |
02:35:08 | lostlogic | or if you see problems in the code |
02:36:47 | Nico_P | looking now, but I'm sleepy ;) |
02:37:22 | lostlogic | Nico_P: *nod* I'm not in a rush to commit, I'm going to be working on what mike and I were just talking about in the hopse of getting some mor complete fixage to go with it |
02:37:36 | jhMikeS | lostlogic: speed me up here: what lines are you referring to exactly? |
02:37:53 | jhMikeS | (patched lines) |
02:38:49 | lostlogic | the data aborts happen on the m->filerem > 0 check in fill_buffer() and find_handle on the m && m->id != handle_id check |
02:39:03 | lostlogic | which are both places where the LL is being iterated outside of a lock |
02:39:27 | lostlogic | ermh wait, I lied... one of those is in a lock, now I'm confused again |
02:39:55 | Nico_P | lostlogic: I think I got SID related segafaults in the sim with m && m->id != handle_id... m was totally bogus |
02:40:30 | Nico_P | hmm actually that may have been after a bit of hackery... |
02:40:32 | lostlogic | Nico_P: yeah −− which I'm still trying to figure out how it gets bogus since all of the handle variables are only written to inside of locks |
02:41:14 | lostlogic | ugh, I must be missing something. |
02:42:31 | Mouser_X | Nico_P: I saw someone earlier (hours ago, now) say that there were problems transitioning between NSFs and MP3s (or SPCs and MP3s). Did this get fixed? |
02:42:38 | | Join zerdik [0] (n=zerdik@pool-68-237-46-24.ny325.east.verizon.net) |
02:42:51 | Nico_P | Mouser_X: I haven't had time to investigate enough, so no |
02:42:54 | lostlogic | Mouser_X: check with the commit that I just did −− that could impact codec changes. |
02:43:09 | Nico_P | yes, very true... what a dumb mistake |
02:43:17 | Nico_P | I'm so lucky it actually worked at times |
02:43:31 | Nico_P | or maybe if it hadn't I would've seen the mistake |
02:44:29 | jhMikeS | are lists linked in a FIFO order? |
02:44:29 | lostlogic | I think the current problem may still relate to move_handle and add handle's placement of the struct and its data, now that I'm playing with it more −− I'll hafta keep analzying both my and the previous versions of that code |
02:44:36 | Nico_P | Mouser_X: expect some instability though... we can't solve all bugs within minutes, especially not the poor guys I dropped the bomb on |
02:44:40 | lostlogic | jhMikeS: should be yes. |
02:44:50 | lostlogic | jhMikeS: but it's not a strict contract |
02:45:06 | Mouser_X | Nico_P: You need not worry. I was simply wondering. I haven't updated yet. |
02:45:17 | Mouser_X | (The new stuff breaks some patches I want.) |
02:45:41 | Mouser_X | (^ This does not surprise me, but it is somewhat disappointing.) |
02:45:41 | lostlogic | Mouser_X: :( update −− the more the testing the more the better :0 |
02:46:15 | | Join donutman25 [0] (n=chatzill@65.75.87.48) |
02:46:59 | * | jhMikeS has his finger on the concurrency alarm button but isn't sure what he's seeing yet |
02:47:14 | Mouser_X | I like my GBS and MOD files though (7331 and 5241). When I build with those patches, I get errors, and it fails. |
02:47:28 | Nico_P | lostlogic: it's very possible your commit fixed FS #8027 |
02:47:50 | lostlogic | jhMikeS: I also just realized that I've been analyzing this code as though it's running in a preemptive system, but in our system the traps are smaller, in theory |
02:48:12 | lostlogic | Nico_P: that's what I was hoping, but I didn't have that explicit problem so cuoldn't test ;) |
02:48:14 | Nico_P | lostlogic: it doesn't hurt to think preemptive IIUC |
02:48:25 | jhMikeS | lostlogic: I made the suggestion of using a linear buffer with 64-bit nonwrapping values which would make the ringbuffer stuff unnescessary and simplify stuff. |
02:48:35 | zerdik | i have an archos v1 recorder, a 250gb ata hdd, and i read the bigdisk wiki entry. did i understand correctly that i could use the drive with 2 125GB partitions (only one updatable by usb). Has anyone actually ever done this with a 250GB hdd? |
02:49:03 | lostlogic | jhMikeS: I don't follow −− how would it be addressed when a codec needs X amount of contiguous data?? |
02:49:04 | Nico_P | jhMikeS: I've been thinking about that, but what happens when the counter wraps? |
02:49:10 | jhMikeS | lostlogic: until an unexpected yield happens somewhere. then that is a preemption. |
02:49:22 | lostlogic | jhMikeS: yeah |
02:49:29 | jhMikeS | Nico_P: a 64-bit counter won't wrap in your lifetime |
02:49:46 | Nico_P | hehe, all right :) |
02:49:53 | preglow | we're talking preemption, hooray! |
02:49:56 | jhMikeS | simple adds and subtracts are really efficient with that |
02:50:26 | Nico_P | jhMikeS: so that would rid us of the RIINGBUF_* macros? |
02:50:33 | jhMikeS | Using a non-wrapping 64-bit counter on a pcm buffer takes around 3,300,000 years to wrap |
02:50:59 | karashata | Nico_P, and whoever else is working on the MoB stuff related to swapping codecs: SPC to MP3 gives an unidentified instruction at 000FAB5C (0) |
02:51:07 | jhMikeS | Nico_P: yeah, and you can normalize them occasionally too |
02:51:09 | * | lostlogic still doesn't get how the addressing works, sigh |
02:51:14 | karashata | most recent build, fyi |
02:51:16 | scorche | zerdik: that depends on how you define "GB"... |
02:51:23 | Nico_P | karashata: still, I aw going to ask you for an update on the tracker? |
02:51:35 | lostlogic | karashata: aww :( |
02:51:56 | zerdik | scorche: the commercial way, i guess, not GiB.. |
02:52:03 | lostlogic | I was afraid my commit wouldn't work, the fact is that even without that request the buffer should eventually have satisfied the needed data |
02:52:04 | karashata | looks like the data aborts are gone, I'll do some more tests and post the results on the tracker |
02:52:38 | Nico_P | karashata: r15324 may have fixed them |
02:53:04 | keanu | i'm trying to build a windows version of the uisimulator on linux, but mingw32 isn't installed (no root available) - which source code package should I use? |
02:53:16 | karashata | nope, actually, second attempt gave me a data abort at 000831C (0) and a UI at 000FAF20 (0) |
02:53:29 | Nico_P | jhMikeS: why are you going to press the concurrency alarm button? |
02:53:54 | preglow | why does codec swap sometimes hang depending on codec? |
02:53:59 | lostlogic | karashata: do you know how to map that down to a function from the build you're running? if so that would be useful (although I can look at it and make a decent guess as to where it is) |
02:54:07 | keanu | just follow the process at http://www.libsdl.org/extras/win32/cross/README.txt? |
02:54:08 | preglow | sounds like something that should have happened also prior to MoB to me |
02:54:34 | lostlogic | preglow: yeah, I can't figure out how which codec the changes is matters. |
02:54:47 | preglow | lostlogic: so the issue is some codec does something nasty? |
02:55:02 | | Quit Mouser_X (Nick collision from services.) |
02:55:07 | jhMikeS | Nico_P: don't know yet...my thread sense is tingling a bit though :) |
02:55:12 | preglow | from the playback.c side of things, a codec should be a codec |
02:55:36 | lostlogic | preglow: hmm, could be that the new buffer doesn't like switching if all bytes of a previous file weren't raed, but that doesn't really make sense to me |
02:55:45 | karashata | lostlogic: no idea, I'm trying to switch between files with different codecs from the file browser if that helps, though |
02:55:50 | preglow | *shrugs* |
02:55:57 | | Join Mouser_X [0] (n=someone@207.155.176.3) |
02:55:57 | preglow | playback.c has always been magic to me :) |
02:56:22 | preglow | i still keep to low-level stuff, mostly |
02:56:38 | lostlogic | preglow: yeah, it's a good thing we all have different skills ;) |
02:56:46 | jhMikeS | Nico_P: I was thinking....bytes_in/bytes_out (not wrapped, 64-bit). head/tail (32-bit, always wrapped). tail moves as much as bytes_in, head as much as bytes_out. |
02:57:20 | scorche | zerdik: yes, that should be fine |
02:57:24 | | Quit Mouser_X (Read error: 104 (Connection reset by peer)) |
02:57:30 | preglow | i don't know what the hell i qualify as, my most recent undertaking had me looking at a one line bug for four fucking hours |
02:57:30 | Nico_P | jhMikeS: why both? |
02:57:37 | preglow | i guess that qualifies me as a retard :P |
02:57:44 | lostlogic | :-D |
02:58:06 | preglow | but it is a fast piece of code, though |
02:58:14 | keanu | anyone have tips for how to compiling mingw32 for uisimulator? |
02:58:22 | lostlogic | that's alright, a typo earlier this week _almost_ caused amazon to stop shipping stuff. |
02:58:28 | preglow | :D |
02:58:28 | jhMikeS | Nico_P: it requires it, but checks are easy. buffer full when = bytes_in - bytes_out = bufsize, empty when bytes_in == bytes_out. the head/tail alleviate the need for division. |
02:58:28 | preglow | haha |
02:58:56 | preglow | lostlogic: god help me the day my actions can affect companies of that size |
02:59:11 | lostlogic | :-P |
02:59:19 | preglow | god help you too, hopefully |
02:59:26 | preglow | you'll need it if i end up someplace like that |
02:59:31 | lostlogic | hahaha, indeed indeed |
02:59:39 | Nico_P | jhMikeS: sounds good |
02:59:42 | zerdik | scorche: can the folder structure of the two partitions overlap? or do all folder names need to exist uniquely on one of the partitions only? |
02:59:50 | * | Nico_P has a lot on his plate for tomorrow |
03:00 |
03:00:16 | Nico_P | lostlogic: what time is it at your place? |
03:00:29 | preglow | 03:00 here :/ |
03:00:44 | lostlogic | 6pm |
03:00:46 | Nico_P | preglow: same here... way past bed time |
03:00:51 | preglow | i just got home |
03:00:54 | lostlogic | I'm about to go to my home and cnotinue staring at this |
03:01:20 | Nico_P | lostlogic: maybe mail me a patch then... unless you're confident enough to commit ;) |
03:01:22 | preglow | just the right time to go hunting for another beer |
03:01:31 | lostlogic | Nico_P: yeah, we'll see which way it goes |
03:01:33 | jhMikeS | Nico_P: with the window, checks for whether data is availabe in the buffer or not are just trivial as heck and it never can alias. |
03:01:41 | lostlogic | I'll be on some this weekend to talk about it |
03:01:50 | | Quit kugel (Read error: 110 (Connection timed out)) |
03:01:55 | Nico_P | jhMikeS: yeah I liked how it was done in the kernel for queues |
03:02:12 | scorche | zerdik: i would imagine it would be fine, but you might want to test before believing me wholly :) |
03:02:18 | Nico_P | lostlogic: cool. I should be too, but mostly in the daytime, and I'm GMT+1 |
03:02:27 | preglow | Nico_P: exactly where? |
03:02:34 | Nico_P | preglow: Paris |
03:02:43 | preglow | ahh, right, that would be the same as here |
03:02:47 | jhMikeS | Nico_P: of course it has the luxury of int power of 2 sizes. :) |
03:02:51 | lostlogic | yeah, our daytime overlap is even smaller now that I'm in Seattle than it was when I was in Chicago |
03:03:16 | * | preglow has no idea where in the us either are :> |
03:03:20 | karashata | this isn't looking good |
03:03:39 | karashata | seems like things almost got worse for the ones that weren't working before... |
03:03:41 | Nico_P | lostlogic: OTOH that can mean almost all day bug fixing ;) |
03:03:50 | jhMikeS | preglow: in texas :p |
03:04:01 | lostlogic | preglow: Chicago is 1/3 from East to West and 1/3 from North to South, Seattle is in the North West corner |
03:04:12 | lostlogic | Nico_P: indeed :) |
03:04:19 | preglow | i thought it was the other way around :P |
03:04:36 | preglow | then again, i always sucked in a major way in anything even relating to geography |
03:04:54 | preglow | i've never even been to the us |
03:04:55 | Nico_P | jhMikeS: I didn't understand the power of 2 comment...? |
03:05:00 | lostlogic | preglow: I do too, anywhere I haven't driven/motorbiked to I don't know where it is |
03:05:13 | preglow | lostlogic: exactly my position as well |
03:05:28 | | Join Mouser_X [0] (n=someone@207.155.176.3) |
03:05:39 | lostlogic | alright, I go home now, will hopefully get a patch worked up tonight that solves my personal data aborts. 'night to you GMT+1ers |
03:05:46 | preglow | lostlogic: it's the same thing with geography as anything else with me, if i haven't had a practical use for the information, i don't remember it |
03:05:53 | lostlogic | preglow: yep. |
03:06:01 | jhMikeS | Nico_P: can just wrap with logical-and (mask) so doesn't need the other wrapped pointers to avoid modular division. |
03:06:08 | | Quit einhirn (Read error: 104 (Connection reset by peer)) |
03:06:27 | preglow | lostlogic: gnight anyway |
03:06:35 | Nico_P | jhMikeS: ok, I thought it might be that... quite elegant :) |
03:06:41 | preglow | i need smokes |
03:07:17 | jhMikeS | smokes, beer |
03:07:57 | jhMikeS | Nico_P: it was always like that |
03:08:23 | Nico_P | jhMikeS: I don't look at kernel.c much... |
03:09:15 | preglow | have beer, can't find any smokes yet :/ |
03:09:18 | jhMikeS | Nico_P: I think I live there nowadays...never officially changed my address though |
03:09:36 | jhMikeS | beer without smokes is like smokes without beer :p |
03:09:37 | preglow | and it's too bloody cold outside for 7-11 |
03:10:35 | preglow | hahah, i DID find my pipe and tobacco :P |
03:10:47 | keanu | rasher, around? |
03:11:02 | jhMikeS | "tobacco" D |
03:11:09 | preglow | haha, it actually is tobacco |
03:11:17 | preglow | whisky flavoured and everything |
03:11:44 | Nico_P | lostlogic: if you commit (or even send me patches), it could be good to split things like the const changes from the rest... Maybe also separate comment changes |
03:12:44 | preglow | jhMikeS: also, it's bloody dry as hell :P |
03:13:02 | jhMikeS | hmmm...whiskey...and xanax...a mild sleep helper :p |
03:13:09 | | Quit Mouser_X (Read error: 104 (Connection reset by peer)) |
03:13:38 | preglow | i think those two combined would be more than just a mild sleep helper for me, yea |
03:13:41 | preglow | heh |
03:14:20 | | Join Mouser_X [0] (n=someone@207.155.176.3) |
03:17:04 | markun | nighty guys |
03:17:08 | *** | Saving seen data "./dancer.seen" |
03:17:17 | jhMikeS | preglow: I think this is the first time in awhile I've seen you actually have beer. Seems you can't get 'em both together. (of course this _is_ all relevent and on-topic) |
03:17:42 | jhMikeS | g'night markun |
03:17:48 | preglow | jhMikeS: what, both talk about beer _and_ have one? :P |
03:18:03 | preglow | markun: nightie |
03:18:12 | jhMikeS | and have a smoke too |
03:18:19 | markun | nah, I quit :) |
03:18:25 | preglow | oh, me too |
03:18:27 | markun | but I had 0.5 liter of Grolsch |
03:18:29 | preglow | can't help it when i drink |
03:18:53 | preglow | i'm bloody smoking a year and a half old tobacco, yes, this is an emergency |
03:19:07 | jhMikeS | Quitting's for quitters |
03:20:24 | karashata | okay, tests are all done, comment is on FS #8027 |
03:20:27 | preglow | i tend to quit smoking when i'm working out as well, the two of them are kind of mutually exclusive :P |
03:20:50 | * | jhMikeS would prefer tobacco awareness concentrate on where to get discount cartons |
03:20:54 | karashata | looks like the same codecs are having issues, the ones that worked still work so you guys haven't broken anything new |
03:21:07 | preglow | jhMikeS: you probably have nothing to complain about, how much is a pack for you? |
03:21:23 | jhMikeS | preglow: depends. locally, about $5 |
03:21:49 | preglow | jhMikeS: 11$ here, minimum |
03:23:03 | markun | preglow: luckily a dollar is not very expensive these days :) |
03:23:04 | preglow | the usual routine is, if someone complains about prices and isn't from norway, i have a really good case when i tell them to stop bitching :D |
03:23:05 | jhMikeS | oh, don't get me on politics here now (tax objector, small-government type here). |
03:23:32 | preglow | markun: anything from the us is pretty much free these days, yeah :P |
03:23:35 | preglow | hooray deficit! |
03:23:54 | jhMikeS | meh |
03:24:45 | preglow | luckily, i'm on norway, so anything i order from outside the country is taxed to pieces at the border |
03:25:54 | preglow | in/on/asl |
03:26:11 | jhMikeS | well, start diggin a secret tunnel to the us. then you can workout and get smokes. |
03:26:29 | preglow | without being short of breath? hooray! :D |
03:27:18 | preglow | only kind of tunnel i've made in my life has been through snow, so i don't know if i'm up to it, though |
03:27:43 | jhMikeS | breath is overrated...moderation is key |
03:28:29 | preglow | still doesn't keep me from being a bad tunneller :) |
03:28:36 | scorche | preglow: no ssh? |
03:28:38 | scorche | ;) |
03:28:40 | preglow | hahaha |
03:28:46 | preglow | no, no ssh |
03:28:48 | preglow | i'm not paranoid |
03:28:59 | preglow | i only talk shit anyway, whoever wants to read can do so |
03:29:00 | keanu | ok, since rasher's idle - i'm trying to compile a sim on linux and zip it up, like on rasher's site. however, the zip turns out to be nearly 9 megs, without rockboxui added. what's causing the size to be do high? |
03:29:05 | keanu | *be so high |
03:29:13 | preglow | keanu: unzip it and see |
03:29:33 | preglow | i'm in windows right now so can't check out |
03:31:22 | keanu | preglow, 18 megs of plugins/viewers, 4.2 megs of codecs, and wps, docs, langs, and the other directories are under 1 meg each |
03:32:13 | preglow | keanu: well, that all sounds like data that should be there |
03:32:23 | preglow | maybe rockbox is just bloated and huge :) |
03:32:31 | keanu | preglow, yes, but rasher's is a mere 2 megs ;) |
03:32:52 | preglow | perhaps you need to strip the debug symbols |
03:33:13 | jhMikeS | enormous...well, the sim is a big bytier than the fw |
03:34:11 | keanu | how do i strip debug symbols? |
03:34:19 | * | keanu hasn't messed with sims a whole lot |
03:34:37 | jhMikeS | can't you just build a fully-optimized sim without debug symbols? |
03:34:43 | * | Nico_P is off to bed |
03:34:54 | preglow | keanu: don't use -g when you compile, or use the strip command afterwards |
03:34:58 | preglow | bear in mind this is just a guess |
03:35:07 | | Quit Nico_P (Remote closed the connection) |
03:35:16 | jhMikeS | what about -O levels? never seen it run that way. |
03:35:24 | preglow | i've never checked out if the sim is huge |
03:35:25 | keanu | preglow, i didn't use -g - just make and make zip |
03:35:32 | preglow | jhMikeS: -O and -g can be active at the same time |
03:35:40 | preglow | keanu: -g might be part of the default build |
03:35:46 | preglow | you don't need to pass it, might be in the makefile |
03:35:50 | keanu | preglow, ah, ok |
03:35:53 | jhMikeS | sure but then code reording can mess up the debugging |
03:36:05 | preglow | yup, but plain -O usually fares pretty well with it |
03:36:17 | jhMikeS | does it reference souce? |
03:36:19 | jhMikeS | *source |
03:36:43 | preglow | -g does that, has nothing to do with -O |
03:37:14 | preglow | use -g and -O, and you'll see ton of "value optimized away" in gdb |
03:37:35 | | Join squeaky [0] (n=snowbird@adsl-71-134-227-112.dsl.pltn13.pacbell.net) |
03:37:44 | preglow | another beer, sir |
03:37:51 | jhMikeS | sure. I don't see those, so I've never run a truely optimized sim then, eh? |
03:37:59 | keanu | preglow, so don't use either to keep sizes down? |
03:38:00 | preglow | *shrug* |
03:38:12 | preglow | i don't know if i've got it from the sim or other software, i just know i've seen it a lot |
03:38:39 | preglow | keanu: just use -O anyway, and sim builds do that, i'm quite sure, but you might need to "strip" afterwards |
03:38:50 | * | jhMikeS tries -O3 and no -g :p |
03:38:51 | preglow | keanu: i'd just wait for rasher, were i you, i can't check this out right now |
03:39:00 | keanu | preglow, ok, thanks |
03:39:06 | preglow | jhMikeS: gdb is rather unhelpful with no -g ... |
03:39:06 | keanu | any idea when he'll be back? |
03:39:19 | preglow | keanu: well, chances are good he'll be here tomorrow |
03:39:24 | preglow | but no idea |
03:39:26 | keanu | ok, thanks |
03:39:33 | jhMikeS | preglow: if you want a build to use as an actual player, who wants -g? (you said you wanted that) |
03:39:53 | preglow | jhMikeS: -g just means debug symbols, it doesn't mean "fuck up code and make it slow" |
03:40:16 | preglow | but no, if you have no interest in debugging, don't use it |
03:40:30 | jhMikeS | uisdl.c throws a warning about picture_surface possibly not being inited |
03:40:40 | preglow | never seen that before |
03:41:22 | preglow | but as far as i know, -O3 and -g just means you get a bigger exe with debug info that doesn't get loaded at runtime anyway |
03:41:23 | jhMikeS | It did with -O3, but not without optimization (or maybe it's the -g) |
03:42:21 | jhMikeS | rockboxui is 2890KB for the gigabeatf still |
03:42:34 | preglow | after strip? |
03:42:38 | preglow | that's insane |
03:42:39 | * | maxkelley has a few pinouts for the large connector on the c200.. |
03:42:45 | jhMikeS | wait...I think I need full rebuid :p |
03:43:02 | maxkelley | perhaps this weekend, I will solder wires to the connector and find out the rest. |
03:43:22 | preglow | maxkelley: what's it used for |
03:43:22 | preglow | + |
03:43:24 | preglow | ? <- |
03:43:39 | maxkelley | preglow: usb, hopefully audio, power, etc. |
03:44:02 | maxkelley | sansa doesn't manufacture any accessories that use it, however.. :P |
03:44:15 | maxkelley | hopefully there's a line-in. |
03:44:20 | preglow | heh |
03:44:26 | preglow | does e200 have the same thing' |
03:44:32 | maxkelley | er, s/sandisk/sansa |
03:44:34 | maxkelley | I think so. |
03:44:35 | preglow | ok, i can't hit the correct buttons, it's official |
03:44:45 | maxkelley | heh |
03:44:52 | * | preglow gets more beer |
03:44:55 | jhMikeS | preglow: ah, 720KB now |
03:45:03 | preglow | jhMikeS: sounds mor elike it |
03:45:11 | keanu | preglow, taking out -g worked |
03:45:22 | keanu | preglow, down to 2.3M without rockboxui in it |
03:45:49 | preglow | keanu: sounds about right, then |
03:46:00 | keanu | preglow, thanks |
03:46:03 | * | jhMikeS proceeds with the full build (-O3, no -g) |
03:46:12 | preglow | keanu: no problem |
03:46:19 | keanu | jhMikeS, replacing -g with -03? |
03:46:27 | jhMikeS | keanu, yep |
03:46:32 | preglow | -Osomething should still be there |
03:46:47 | jhMikeS | now I see the warnings that show up on the build table popping up |
03:47:02 | preglow | all two of them? :> |
03:47:15 | jhMikeS | the type-punning one came up |
03:47:51 | jhMikeS | wma.c has signed/unsigned type in conditional expression (I always get that though) |
03:47:53 | preglow | i've had that for a while, i just figured that was me being 64 bit |
03:47:54 | keanu | jhMikeS, oh...-O3, not -03 ;) |
03:48:06 | jhMikeS | Oh-three :) |
03:48:09 | preglow | 0O0O0O0 |
03:48:18 | maxkelley | i'm not sure having the pinouts of the connector will be beneficial if people don't solder their own cable :P |
03:48:33 | preglow | maxkelley: why doesn't sansa do any periphs for it? |
03:48:43 | preglow | they just make a connector, then sod off? |
03:48:53 | keanu | jhMikeS, ok, where exactly in the makefile does that go? |
03:49:00 | * | keanu doesn't mess with makefiles much |
03:49:05 | maxkelley | I think there's a few 3rd-party. |
03:49:06 | maxkelley | bbl |
03:49:08 | jhMikeS | keanu: GCCOPTS |
03:49:12 | preglow | then you need to get a new hobby, heh |
03:49:16 | keanu | jhMikeS, ok, thanks |
03:49:40 | | Part squeaky ("Leaving") |
03:50:08 | * | jhMikeS now wonders if any other makefiles add -g for sim? |
03:50:32 | preglow | why care? it's something people who distribute sims should wonder about |
03:50:43 | preglow | sims are a developer thing, really, where you want -g |
03:50:52 | jhMikeS | because I'll know something I didn't 10 minutes ago? |
03:51:00 | preglow | then go ahead :) |
03:51:04 | keanu | heh |
03:51:06 | jhMikeS | :p |
03:51:54 | jhMikeS | also let's me get alternate timings on threading code just to check |
03:52:19 | zerdik | you can always strip the debugging symbols off the binary later, same result as compiling without -g |
03:53:54 | jhMikeS | 6*1 or .5*12 :P |
03:54:05 | preglow | zerdik: xactly |
03:54:30 | preglow | hrm |
03:54:43 | preglow | i think we should get rid of the malloc buffer the next few days |
03:54:47 | karashata | hmmm... I don't know if this is related to the MoB commit or not, but, after playing through 9 FLAC files my player stopped playing and returned to the file browser |
03:54:52 | preglow | then fix the codecs that stop working |
03:55:07 | preglow | they should be few |
03:55:11 | preglow | tremor and aac, really |
03:56:18 | jhMikeS | do any actually use up much of that? can the slack space after the codec be used? |
03:56:25 | preglow | jhMikeS: exactly |
03:56:32 | preglow | jhMikeS: we should use that as malloc space |
03:56:50 | jhMikeS | and it gets swapped automatically too then |
03:56:51 | preglow | jhMikeS: i've just had a run over all the codecs, and of all of them only aac and vorbis use malloc much |
03:57:17 | preglow | jhMikeS: the two-three others that use malloc only do so for the container or seek tables |
03:57:26 | preglow | jhMikeS: both of which fit nicely in the rest of the codec buffer |
03:58:02 | preglow | jhMikeS: really, most codecs need really tender treatment to rid them of all dynamic allocation |
03:58:08 | lostlogic | anyone know if buffer_len is guaranteed to be aligned to 4 bytes? |
03:58:08 | jhMikeS | well, if the codec buffer needs to grow a little, I guess that wouldn't hurt. cerainly the whole 500KB wouldn't have to go over. |
03:58:14 | preglow | jhMikeS: i suspect vorbis will be the hardest, that was made to not have limits |
03:58:45 | preglow | jhMikeS: if we use 512kb for codec and codec data, i'd count that as a bug |
03:59:02 | preglow | unless the codec creators are insane |
03:59:40 | jhMikeS | 512KB for mallocbuf, 512KB for executeable |
03:59:56 | preglow | even aac is designed to run well on embedded targets, and that's pretty complex for an audio codec |
04:00 |
04:00:08 | preglow | should fit well within 512kb, code an data combined |
04:00:26 | jhMikeS | data=mallocbuf in your terms? |
04:00:31 | preglow | jhMikeS: aye |
04:00:36 | preglow | too bad we're stuck with faad for a decoder |
04:01:05 | jhMikeS | that's for aac? |
04:01:08 | preglow | yep |
04:01:18 | preglow | it's pretty much the only codec i wish we didn't hacve |
04:01:19 | preglow | have <- |
04:01:21 | jhMikeS | does anyone use that? |
04:01:25 | preglow | i think so |
04:01:56 | preglow | it's slow as shit on both coldfire and arm |
04:02:00 | | Quit zerdik ("Disconnecting") |
04:02:12 | preglow | i had a couple of attempts at it, ended up just doing simple emac opts |
04:02:23 | jhMikeS | can't say I ever have...hrm. wma is pretty nice...no seeking yet. mostly it's just high-br mp3 for me. |
04:02:45 | preglow | seeking isn't a big deal, saratoga will have it going nicely once he has time for it |
04:02:58 | jhMikeS | vorbis for stuff that needs perfect gapless |
04:02:58 | preglow | i use vorbis, mostly |
04:03:15 | preglow | if not for vorbis, i'd use mp3, or possibly musepack |
04:03:48 | preglow | i'm pretty much fine with all of them, mp3 gapless is good enough for me |
04:04:47 | preglow | my test gapless album still doesn't sound good enough, but it doesn't in foobar either, so i stopped trying |
04:04:50 | jhMikeS | It's rarely perfect no matter what the encoder does. Lot's of stuff needs it that way where tracks run together. |
04:05:07 | preglow | it can't be perfect, pure and simple |
04:05:24 | preglow | the old-fashioned lame gapless way is still the best, but that's imperfect too |
04:06:28 | jhMikeS | No clicks ever with vorbis (of couse none with FLAC, WAV, WV etc. by definition) |
04:07:25 | preglow | encoders assume they know nothing about data around track transitions, that breaks perfect gapless right there |
04:07:45 | preglow | to encode lossy tracks nicely around track boundaries, you need to know what follows after the boundary |
04:07:48 | jhMikeS | Gapless was the whole reason I ever found this rockbox thing in the first place. I hated "The Wall" with huge gaps on x5 and read "rockbox" in the iAudio forums. |
04:07:57 | preglow | that's what the old lame gapless method did right |
04:08:03 | preglow | jhMikeS: me too.... |
04:08:36 | preglow | jhMikeS: i was pissed off iriver didn't do gapless right, found rockbox, waited for it, and planned to code dsp plugins on it when it came around |
04:08:48 | preglow | i'm still planning to do that...... |
04:09:37 | preglow | i listen to a lot of electronic music, and every other album has gapless transitions, it pisses me off when i get bloody gaps |
04:09:59 | jhMikeS | I had no idea and didn't even plan on developing right away. Just a spur of the moment thing to see what I could do with the LCD on x5 (and a laughable effort looking back on it) |
04:10:09 | preglow | :D |
04:10:43 | jhMikeS | I had absolutely no idea what I was doing and never programmed hardware before. |
04:10:44 | preglow | what programming experience do you have, anyway? as of right now, you seem 10x more skilled than me |
04:10:55 | | Join TMM [0] (n=hp@ip565b35da.direct-adsl.nl) |
04:10:58 | preglow | really, now... |
04:11:07 | jhMikeS | I just did some personal apps for windows to help myself |
04:11:12 | preglow | haha |
04:11:19 | preglow | you pretty much count as a natural, then :P |
04:11:34 | jhMikeS | rockbox was totally incomprehensible to me at first |
04:12:37 | | Quit mirak (Remote closed the connection) |
04:12:40 | preglow | i don't really remember what is was to me |
04:12:41 | jhMikeS | I still use the apps too :). Now I hate programming PC software. |
04:12:52 | preglow | i always tend to focus on really small areas of anything |
04:13:06 | preglow | large parts of rockbox probably are incomprehensible to me today |
04:13:30 | preglow | if it involves making a gui, i don't like it ... |
04:13:46 | jhMikeS | Me too. I just haven't gotten into them all...impossible anyway. I'd rather focus and do a thorough job. |
04:13:52 | preglow | agreed |
04:14:34 | preglow | but, no, i usually don't think too much about it, if it works, i'm sucked into it automatically |
04:14:40 | jhMikeS | I'll do gui if I feel free to get creative. |
04:14:43 | lostlogic | jhMikeS: your patience and thoroughness are rather impressive |
04:14:54 | preglow | three cheers to that |
04:15:24 | lostlogic | I'm kinda fast and loose with my code, I read something until I can feel what it does and then modify it until it does what I think it should, much more art than science most of the time. |
04:15:32 | preglow | i'd have given by a tenth on the way to the dual core stuff |
04:15:43 | preglow | if not earlier |
04:15:44 | jhMikeS | lostlogic: thanks. some things require absolute detail orientation or don't mess with it. |
04:15:57 | lostlogic | jhMikeS: yep, and I leave those to you and Jens |
04:16:37 | jhMikeS | I do find threading rather fascinating and just _had_ to have DC work because...well, it's just cool to have. :) |
04:16:44 | preglow | i can plan high-level stuff fine, but not code it |
04:16:48 | lostlogic | hah |
04:16:54 | preglow | so i'll just stick to coding low-level stuff |
04:17:23 | lostlogic | I'm afraid they wouldn't pay me if I couldn't write webapps and web services. |
04:17:26 | jhMikeS | the kernel is highlevel? it's huge and detailed...a big pita but a fun one. |
04:17:43 | preglow | jhMikeS: i wouldn't say it's high-level, no... |
04:19:21 | jhMikeS | oy, web programming is just ... well, I just dislike scripting languages or HTML or Java or anything that keeps me away too far away from the architecture. |
04:19:37 | preglow | heh |
04:19:41 | preglow | i can enjoy that just fine too |
04:19:49 | lostlogic | jhMikeS: yeah, I'm not a huge fan myself, but java programming seems to pay the bills rather well, so I've learned to do decently with it |
04:20:01 | preglow | as long as i'm really interested in whatever i'm trying to do, i'm fine |
04:20:08 | preglow | but i guess that goes without saying |
04:20:09 | jhMikeS | I like C++ alot though |
04:20:19 | preglow | c++ is ok |
04:20:28 | preglow | the language i like the most is perl :> |
04:20:32 | preglow | perl and assembler |
04:21:03 | jhMikeS | I know why now I don't see much video software in C but C++ instead |
04:21:04 | preglow | on the oppositive parts of the expresiveness scale |
04:21:14 | preglow | and excuse my spelling, i'm nearing toasted right now |
04:21:17 | lostlogic | perl is a lot of fun, I wish I had more opportunity to play with it |
04:21:45 | jhMikeS | I haven't messed with that too much except to get some rb scripts to do what I needed atm |
04:21:59 | preglow | perl is fun, that's what i love about it |
04:22:20 | preglow | you can code it profesionally for year, and it'll still surprise you |
04:22:32 | lostlogic | yeah :) |
04:22:36 | preglow | which is what makes it fun |
04:22:59 | preglow | but that fun still doesn't keep you from being productive, whatever the python people might make you believe :P |
04:23:42 | scorche | hmph! |
04:24:15 | jhMikeS | lostlogic: re: the "more art than science". I'll always be sure to the best of my ability the logic only allows the conditions I want the system to have. |
04:25:44 | jhMikeS | preglow: what do you use perl for in general? for web stuff I can pass. It must be good for something else I might like. |
04:26:01 | | Quit miepchen^schlaf (Read error: 110 (Connection timed out)) |
04:26:05 | | Join miepchen^schlaf [0] (n=hihi@p54BF52EC.dip.t-dialin.net) |
04:26:21 | preglow | jhMikeS: right now, i'd use perl for web stuff any day, but i used to use it for network services in general |
04:26:28 | preglow | now, i just use it for any scripting task i have |
04:26:57 | jhMikeS | now, network stuff (not webpages) _is_ interesting and something I haven't touched on nearly enough |
04:27:58 | preglow | i learned perl doing services for some people i knew in uni doing counter-strike service |
04:28:00 | jhMikeS | but it's more like routing, packets and synchronization that I like...I guess sort of threading in a distributed way *shrug* |
04:28:06 | preglow | s/service/server/ |
04:28:18 | preglow | making fake rcon admin servers, stats stuff |
04:29:00 | preglow | i just kept using it after that for anything net related |
04:29:23 | preglow | i've always been in programming for the fun, which is why perl struck so nicely with me, i think |
04:29:51 | preglow | python fucking bored me to death |
04:30:02 | preglow | and i only use c/c++ because it's so efficient |
04:30:27 | scorche | what bored you about python? |
04:30:29 | jhMikeS | the higher-level scripting stuff just feels, well, strange. I guess I initiated myself in the C64 days so maybe that's it. |
04:30:51 | preglow | scorche: the whole "this is the only way you'll ever code this" kind of thing |
04:31:04 | preglow | scorche: python kind of only has one approved way to do stuff |
04:31:24 | jhMikeS | I never had a look at python at all...now I feel like I shouldn't bother |
04:31:29 | preglow | scorche: with perl, everyone loves the way you can do stuff a ton of ways. you'll find a ten modules to do the same thing in different ways |
04:31:43 | scorche | ah...i can see that...that is partly why i think it is good for beginning programmers too....it teaches very good habits |
04:31:46 | preglow | jhMikeS: i got into coding with c64 too |
04:32:12 | | Join webguest71 [0] (i=48927114@gateway/web/cgi-irc/labb.contactor.se/x-6d557ed74af4b35c) |
04:32:19 | webguest71 | howdy guys |
04:32:20 | preglow | jhMikeS: not really conciously. my first real coding was qbasic on dos, but i only did that because i recognized basic from c64 |
04:33:20 | preglow | jhMikeS: i didn't really touch real 6502 assembly until i was in uni 6-7 years ago, a real flashback, that was :P |
04:33:41 | jhMikeS | I liked 6502 asm myself over basic |
04:33:51 | preglow | today, i do as well |
04:33:59 | | Quit webguest71 (Client Quit) |
04:34:14 | preglow | back then i had no idea what asm was |
04:34:20 | jhMikeS | The first basic I did was in 5th grade...on Apple II :P |
04:34:29 | preglow | my route was basic->pascal->[asm]->c->c++ |
04:34:46 | preglow | with smaller stuff inbetween |
04:35:25 | | Join saratoga\ [0] (i=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-007dbd7f14731055) |
04:35:26 | jhMikeS | basic->6502 asm->pascal->c->c++-><various asm> |
04:35:35 | preglow | heh, yeah |
04:35:46 | preglow | "various asm" fits nicely at the end for me as well |
04:35:53 | preglow | being rockbox' fault, primarly |
04:36:07 | jhMikeS | there wasn't much else available to start at the time but basic |
04:36:26 | jhMikeS | yes, rb is to blame for much of it |
04:36:41 | preglow | never would have known m68k and arm if not for rockbox |
04:37:15 | jhMikeS | me not likely either....ARM definitely not. |
04:37:22 | preglow | nah |
04:37:26 | preglow | i always wanted to learn 68k |
04:37:29 | preglow | but never had an amiga |
04:38:03 | jhMikeS | We're it not for RB, I don't think I'd really know what most stuff is. |
04:38:34 | preglow | heh |
04:38:50 | preglow | i got in rockbox for dsp, really |
04:38:58 | preglow | and that's what i still do |
04:39:02 | preglow | but asm is a bit part of that |
04:39:07 | jhMikeS | I have to have a reason to learn it...an outcome that must be met |
04:39:14 | preglow | yeah, same here |
04:39:41 | preglow | it's the same with everything i do, if i have a good goal to learn something, i learn it |
04:39:45 | preglow | and pretty well too |
04:40:26 | preglow | but it's strictly pragmatic, very rooted in what i'm currently trying to achieve |
04:41:44 | preglow | always had good fun with that in uni, tons of nice stuff to learn i really didn't need to know |
04:41:46 | jhMikeS | It reduces the set of what's to know and channels it...otherwise the universe is too vast and I don't know what to know. |
04:42:04 | preglow | heh, yeah |
04:44:55 | preglow | on that note, arm really should have dedicated dsp stuff like coldfire does :/ |
04:45:29 | preglow | i gave optimizing the same speex stuff i have done for cf the last on cf a go on arm today |
04:45:35 | jhMikeS | it does...if it's added on :) |
04:45:36 | preglow | not as easy :/ |
04:45:56 | preglow | having four accumulators separate from the ordinary register set is nice |
04:46:01 | saratoga\ | i think arm v5 or 6 has DSP stuff |
04:46:08 | saratoga\ | i blame PP for what we have |
04:46:13 | preglow | saratoga\: it does, but still using ordinary registers |
04:46:23 | karashata | eek... |
04:46:34 | jhMikeS | having accumulators as the regular regs has advantages too...when output must feed input |
04:46:44 | karashata | got a data about when trying to switch tracks after the player stopped playing in the middle of a track |
04:46:45 | preglow | that qmf_synth() thing i did for speex was really an optimal use of coldfire |
04:46:48 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
04:46:58 | karashata | and an unidentified instruction as well |
04:47:20 | jhMikeS | if ARM didn't have that icky slow booth multiplier or would at least do something for single-cycle throughput, it would work nicely |
04:47:21 | karashata | I think I'm switching back to the build I have before the MoB commit, seems a little unstable still |
04:47:52 | preglow | jhMikeS: yeah, and portalplayer not replacing that speaks volumes as to how skilled they are |
04:48:09 | preglow | jhMikeS: i almost hope they have some hidden cop instruction doing macs fast for them somewhere |
04:48:36 | preglow | however, i didn't find any doing disassemblies :/ |
04:49:29 | preglow | really, smlal and smull would be "ok", at least, if they weren't so bloody slow |
04:49:33 | jhMikeS | the core is the core...they probably had ARM wire it to the C0EDBABEs, DEADBEEEs and CACAD0D0 and called it PortalPlayer |
04:49:38 | saratoga\ | the faster arm cores are nice, the high end stuff they're doing even has OOOE |
04:49:56 | saratoga\ | though that largely negates the need to optimize for anything we'd do |
04:50:18 | preglow | saratoga\: yeah, but that's very migh higher end than we'll see in some time, i'll wager :D |
04:50:27 | preglow | eh |
04:50:32 | preglow | s/might/much/ |
04:50:32 | saratoga\ | the way toshiba is going i'm not sure |
04:50:46 | jhMikeS | preglow: nope, I disassembled the whole OF and only smull and smlal |
04:51:03 | saratoga\ | also, what is the latency on a smull for PP anyway? |
04:51:06 | saratoga\ | 5 clocks? |
04:51:11 | preglow | jhMikeS: yeah, i even found a complete equivalent of our eq_filter, only slower |
04:51:17 | preglow | saratoga\: depends on the operands |
04:51:25 | preglow | saratoga\: anything from 3 cycles to 6, i think |
04:51:41 | saratoga\ | 6 is for a 32x32 with no add? |
04:51:50 | preglow | saratoga\: for smlal, 2 to 5 for smull |
04:51:53 | jhMikeS | use shift+add whenever you can on ARM |
04:52:38 | saratoga\ | using the other complex multiply formula for mdcts would probably be worthwhile then |
04:52:52 | jhMikeS | add/sub/rsb rn, rm, rs, lsl #x _is_ the other mla |
04:52:56 | preglow | saratoga\: important thing to know if they use the booth multiplier scheme with early termination, for each byte in your second multiplier operand that a zero, you save a cycle |
04:52:57 | saratoga\ | i think its two complex muls a sample, and you can save one smull on each |
04:53:28 | preglow | ok, i can't type straight without considerable attention anymore |
04:53:40 | saratoga\ | preglow: the manual says that, but I couldn't detect a difference if I ANDed with FFFF0000 before multiplying |
04:53:53 | saratoga\ | though maybe i was doing something wrong |
04:53:53 | preglow | saratoga\: then that's seriously weird |
04:53:56 | jhMikeS | preglow: It varies alot, one other ARM implementation isn't just bytewise but bitwise and all negative values take full time |
04:54:56 | saratoga\ | for a while i was going to have multiple small lookup tables for each trig table that would be 16 bit each, but carefully scaled so that rounding could be controled |
04:55:06 | preglow | saratoga\: anyway, colour me surprised if portalplayer altered that arm core at all before using it |
04:55:11 | saratoga\ | but it didn't seem like doing the shorter multiply was faster |
04:55:19 | saratoga\ | though maybe i was doing something wrong |
04:55:31 | jhMikeS | 16-bit contants might very well have short shift+add sequences |
04:55:40 | preglow | jhMikeS: if constant, yes |
04:55:49 | preglow | but you don't often see that |
04:56:15 | saratoga\ | well the trig tables are constant, but theres too many to do that i think |
04:56:27 | preglow | we would have to hard code every imdct |
04:56:33 | preglow | then we could do shift-adds |
04:56:37 | | Join Guerin [0] (n=lewis@121-73-1-241.cable.telstraclear.net) |
04:56:43 | Guerin | hey kids |
04:56:47 | preglow | perfectly feasible, but i'm too damned lazy |
04:56:50 | preglow | Guerin: hi, dad |
04:57:05 | saratoga\ | i wonder if the exploded code size would make it worthwhile |
04:57:07 | Guerin | i just installed rockbox on my iaudio x5L, which I rebuilt from cannibalised parts, and it works a treat |
04:57:21 | preglow | saratoga\: with cache, it's always hard to say |
04:57:24 | Guerin | so whoever's involved in making it does an awesome job; cheers |
04:57:31 | preglow | Guerin: good for you |
04:57:32 | | Quit saratoga\ ("CGI:IRC (EOF)") |
04:57:33 | | Join saratoga [0] (i=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-8e2adf8c38282888) |
04:57:36 | preglow | obviously, also for us |
04:57:40 | preglow | hooray! \o/ |
04:57:42 | Guerin | indeed |
04:57:44 | jhMikeS | us kids like treats |
04:58:15 | preglow | Guerin: why cannibalize? |
04:58:47 | saratoga | oh yeah, i found a paper arguing that our MDCT implementation has suboptimal rounding accumulation and performance when used for fixed point, so maybe the tremor one really is faster |
04:58:49 | Guerin | preglow: i plugged my old one into a AC->USB power supply which burnt out the IDE controller |
04:59:00 | preglow | Guerin: and it still works? :P |
04:59:03 | jhMikeS | it's like the toffe82 gigabeats...take a bunch of busted ones and make one good one/ |
04:59:11 | preglow | haha |
04:59:25 | Guerin | bought a standard x5 on the interwebs, for cheap because it had a dead battery, and spliced the two together with my trust soldering iron |
04:59:35 | preglow | right, i thought you rebuilt the rockbox, not the iaudio |
04:59:44 | Guerin | heh, nope |
04:59:46 | jhMikeS | Guerin: do you happen to have a good x5 battery on hand? |
04:59:48 | Guerin | rockbox Just Worked |
04:59:50 | preglow | like i said, typing correctly takes considerable attentionm |
04:59:52 | preglow | don't expect much |
05:00 |
05:00:34 | Guerin | jhMikeS: i still had the battery out of the x5l, which is ~3x the capacity of the standard one. so I just put the drive and battery into the new unit and it's all good |
05:01:04 | jhMikeS | you did say the standard one had a dead batt which is sad...but I was hoping... |
05:01:20 | Guerin | you're in need of an iaudio x5 battery? |
05:04:05 | jhMikeS | Guerin: yes...a compatible one with the correct charge voltage on 4.2V |
05:04:05 | jhMikeS | s/on/of/ |
05:04:05 | Guerin | i have such a battery - but you can get an OEM one quite easily |
05:04:05 | jhMikeS | I will not send it back to Cowon. They killed it in the first place when they fixed the joystick, then killed the USB, then killed the batt |
05:04:05 | Guerin | the busted x5 i bought second hand came with an OEM 1100mAh battery which I don't need |
05:04:05 | Guerin | i wouldn't ever bother sending one of these back for service |
05:04:05 | DBUG | Enqueued KICK jhMikeS |
05:04:05 | jhMikeS | it was warranty so no charge to me |
05:04:16 | jhMikeS | the 1000mAh batt will fit a standard x5? |
05:04:20 | jhMikeS | *1100 |
05:04:28 | Guerin | jhMikeS: the guy i bought the part off got his OEM battery on ebay for $12.99 - you can change them quite trivially with a soldering iron |
05:04:49 | Guerin | yes, it's a replacement part |
05:04:57 | Guerin | identical in all respects |
05:05:06 | jhMikeS | I know that...that's easy. If the charge voltage isn't right you'll overcharge and destroy it anyway. |
05:05:52 | jhMikeS | so it's actually a new battery that fits?...woohoo? I'm in the US. is that a problem? |
05:05:59 | Guerin | part # PPCW0504; the same as the one I removed. not 4.2v, though - the part I took out is 3.7v |
05:06:43 | Guerin | the guy i bought this one off got it from a canadian seller |
05:06:46 | Guerin | so no problem there |
05:06:51 | jhMikeS | that's nominal voltage |
05:07:07 | Guerin | not peak, right. |
05:07:20 | jhMikeS | 4.2V full-charge is what's important since that's what the software expects |
05:07:55 | Guerin | mine weighs in at a shade under 4v at full charge |
05:08:09 | Guerin | and that's the x5l battery which is a standard one and a much larger one connected in series |
05:08:12 | jhMikeS | well, perhaps it adapts then |
05:08:24 | Guerin | the adapter i burnt it out on was 6vdc |
05:08:49 | Guerin | which it says is what it takes - but i was foolish to use it with a non-standard charger anyway |
05:08:57 | | Quit saratoga (Read error: 113 (No route to host)) |
05:09:31 | | Quit midgey () |
05:09:38 | jhMikeS | ac = bad for charging circuits |
05:10:10 | Guerin | yeah |
05:10:48 | Guerin | anyway, the part is made by Cameron Sino - CS-SFm3SL is their catalogue number for the battery, in addition to the part # above |
05:12:54 | | Join Wofl [0] (n=nils@ip68-97-21-133.ok.ok.cox.net) |
05:13:00 | Wofl | hey guys |
05:13:12 | Wofl | anyone know of a script i can use on my linux box |
05:13:24 | Wofl | to create the database there, instead of the slow ipod |
05:15:19 | | Join bb [0] (n=bb@unaffiliated/bb) |
05:17:09 | *** | Saving seen data "./dancer.seen" |
05:27:34 | | Quit bb_ (Read error: 110 (Connection timed out)) |
05:27:34 | Guerin | so yeah; cheers to your rockbox devs - you're doing good things for the world ;) |
05:27:40 | | Quit Guerin ("leaving") |
05:36:19 | | Quit Wofl ("Konversation terminated!") |
05:43:52 | jhMikeS | hrm...guess I should be able to use the x5 again...hopefully |
05:45:46 | | Join mrkiko [0] (n=mrkiko@adsl-ull-55-206.42-151.net24.it) |
05:45:54 | mrkiko | Hi all! |
06:00 |
06:11:25 | | Quit kkurbjun (Read error: 110 (Connection timed out)) |
06:12:25 | | Quit TMM (calvino.freenode.net irc.freenode.net) |
06:12:25 | NSplit | calvino.freenode.net irc.freenode.net |
06:12:25 | | Quit [omni] (calvino.freenode.net irc.freenode.net) |
06:12:25 | | Quit tedrock (calvino.freenode.net irc.freenode.net) |
06:12:49 | lostlogic | found a minor bug, but I doubt it's the source of our troubles. mutex_init() called multix on the same mutex |
06:14:44 | jhMikeS | I was just looking at that. I think certain things should have a one-time system startup init. |
06:14:52 | | Quit RoC_MasterMind ("Leaving") |
06:15:20 | | Join midkay_ [0] (n=midkay@c-24-19-236-139.hsd1.mn.comcast.net) |
06:17:36 | lostlogic | done and done ;) |
06:17:41 | jhMikeS | thread/queue/mutex should be done there. sync objects should exist before the thread too. |
06:17:56 | lostlogic | hmm, hmm, didn't do that |
06:18:49 | jhMikeS | that's very important |
06:19:33 | lostlogic | fixed |
06:20:31 | lostlogic | still haven't figured out how an invalid pointer makes its way into the linked list though :( |
06:22:19 | lostlogic | oh shoot, I think that what I just committed data aborts instantly |
06:22:32 | lostlogic | didn't notice because I'd gotten so used to aborts. |
06:23:33 | jhMikeS | you can do CREATE_THREAD_SUSPENDED and use thread_thaw which will allow it to start running when it's ok for it to do so. |
06:23:49 | | Quit mrkiko ("HI ALL!") |
06:23:54 | jhMikeS | make that CREATE_THREAD_FROZEN |
06:25:02 | | Join TiMiD[FD] [0] (n=TiMiD@ntoska208050.oska.nt.ftth.ppp.infoweb.ne.jp) |
06:25:05 | TiMiD[FD] | hi |
06:25:42 | lostlogic | jhMikeS: is thread_thaw ok to call on a thread that isn't frozen? |
06:25:53 | jhMikeS | lostlogic: it will have no effect on it |
06:26:10 | lostlogic | awesome. |
06:26:14 | TiMiD[FD] | is someone getting problems with the new buffering engine ? |
06:27:10 | jhMikeS | I don't have a thread_freeze in there yet but that's rather dangerous (and harder on DC because of the possiblity of a core switch). |
06:27:15 | TiMiD[FD] | sometimes the displayed trackname looks like a memory dump |
06:27:18 | TiMiD[FD] | ... |
06:27:32 | jhMikeS | TiMiD[FD]: yes, there are troubles |
06:27:43 | TiMiD[FD] | ok |
06:29:25 | NHeal | calvino.freenode.net irc.freenode.net |
06:29:25 | NJoin | TMM [0] (n=hp@ip565b35da.direct-adsl.nl) |
06:29:25 | NJoin | tedrock [0] (n=tedrock@d235-156-104.home1.cgocable.net) |
06:31:17 | lostlogic | jhMikeS: not much of a usecase for thread_freeze I wouldn't think... |
06:32:00 | | Quit midkay (Read error: 110 (Connection timed out)) |
06:32:30 | | Quit tedrock (calvino.freenode.net irc.freenode.net) |
06:32:30 | | Quit TMM (calvino.freenode.net irc.freenode.net) |
06:32:56 | jhMikeS | I did have one for using it to stop a thread easily (stealing codec stack safely). But then a protocol could be made for a thread to agree to block and avoid stack use somehow. |
06:33:59 | NJoin | TMM [0] (n=hp@ip565b35da.direct-adsl.nl) |
06:33:59 | NJoin | tedrock [0] (n=tedrock@d235-156-104.home1.cgocable.net) |
06:35:26 | jhMikeS | A thread can wait on itself to exit, so perhaps that's a nice way |
06:37:04 | | Quit tedrock (calvino.freenode.net irc.freenode.net) |
06:37:04 | | Quit TMM (calvino.freenode.net irc.freenode.net) |
06:39:08 | | Join Spiritsoulx [0] (n=eyes_of_@24.86.181.152) |
06:39:23 | Spiritsoulx | Anyone know how I can view Chinese .txt files? |
06:39:47 | | Join TotallyInfected [0] (n=ebola@151.197.209.246) |
06:39:55 | lostlogic | jhMikeS: I think that can_add_handle might have been part of our concurrency problem, but I'm still having trouble with it not stopping buffering when the buffer is full. |
06:40:30 | lostlogic | (I reworked can_add_handle so that I could move the write part of a can_ function into add_handle0 |
06:41:51 | NJoin | TMM [0] (n=hp@ip565b35da.direct-adsl.nl) |
06:41:56 | Spiritsoulx | Anyone know how I can view Chinese .txt files? |
06:43:05 | lostlogic | I haven't seen a data abort in ... minutes... |
06:43:05 | NJoin | tedrock [0] (n=tedrock@d235-156-104.home1.cgocable.net) |
06:43:44 | jhMikeS | minutes :) |
06:43:56 | lostlogic | hey, it used to only take me seconds of fiddling with skips to get one :) |
06:44:11 | TiMiD[FD] | Spiritsoulx: open them with a text editor ... |
06:44:16 | jhMikeS | I could do codec failures reliably with rapid skipping |
06:44:23 | lostlogic | seems like rebuffers or resumes don't like to stop buffering, but I think that's actually a separate bug. |
06:45:26 | lostlogic | haven't gotten one of those in a while either ;) |
06:45:51 | lostlogic | both of these things were what I _figured_ I'd be fixing by the work I started... 14 hours ago... |
06:46:11 | jhMikeS | does the buffering thread really need USB awareness? |
06:46:28 | lostlogic | all threads must ack USB or it doesn't work |
06:46:30 | J3TC- | Hrmm |
06:46:34 | lostlogic | it's somewhere in the dev docs |
06:46:37 | jhMikeS | only with public queues |
06:46:57 | lostlogic | oh... then maybe not... |
06:46:58 | jhMikeS | registered if you prefer |
06:47:02 | lostlogic | *nod* |
06:47:09 | TiMiD[FD] | after some time of playback, the hdd starts spinning and working and only stops when I stop the audio playback |
06:47:10 | lostlogic | then maybe not. |
06:47:13 | J3TC- | Album art, bmp resize and/or custom line patch gets me the *PANIC* stkov audio error |
06:47:20 | lostlogic | TiMiD[FD]: yes, I just mentioned that bug... |
06:47:27 | jhMikeS | only playback needs to be stopped. voice and codec shouldn't need them either. I already have a patch for that. |
06:47:27 | lostlogic | TiMiD[FD]: it's next on my list unless someone else gets to it first |
06:47:49 | lostlogic | jhMikeS: gotcha, would sure look nicer if you applied said patch. |
06:48:09 | | Quit tedrock (calvino.freenode.net irc.freenode.net) |
06:48:25 | lostlogic | ok, I'm going to commit this ball-o-wax because I can't seem to data abort it any more (thank god) and we'll see what kind of fallout I get. |
06:48:26 | TiMiD[FD] | are you theguy who wrote the new buffering code ? |
06:49:15 | lostlogic | TiMiD[FD]: no, that was Nico_P |
06:49:17 | jhMikeS | basically it just changed regsiter from true to false and removed the usb awareness. Getting sys messages with a stolen stack is obviously not wanted esp. when done in a non-dev plugin. |
06:49:32 | lostlogic | I'm the guy who lurves the playback system and comes to fix weird bugs when other people do massive rewrites :-D |
06:49:36 | TiMiD[FD] | ok |
06:50:23 | TiMiD[FD] | I was wondering why when you select a track from filebrowser that is already in buffer, the file is rebuffered again |
06:50:25 | lostlogic | jhMikeS: I'm feelin' dumb, but what do you mean by the latter sentence? |
06:50:38 | NJoin | tedrock [0] (n=tedrock@d235-156-104.home1.cgocable.net) |
06:50:47 | lostlogic | TiMiD[FD]: because that code path creates a new playlist, which invalidates the whole buffer |
06:50:53 | jhMikeS | mpegplayer steals the codec thread stack now to save IRAM. that's fine, but if you plug something *boom* |
06:50:55 | TiMiD[FD] | ok |
06:51:04 | lostlogic | jhMikeS: ooohhh, I gotcha. |
06:51:15 | TiMiD[FD] | so the playlist creation code empties the buffer |
06:51:31 | lostlogic | TiMiD[FD]: yeah, because in _general_ a new playlist means that no songs are going to overlap |
06:52:09 | lostlogic | I think we might need a warning posted somewhere about this disk perpetual spinning bug, it's going to cause major battery life trouble for people. |
06:52:20 | lostlogic | specially since I'm probably not going to get it fixed tonight. |
06:52:28 | TiMiD[FD] | oh... |
06:53:03 | TiMiD[FD] | it awoke me last night ... my player was burning hot |
06:53:31 | TiMiD[FD] | fall asleep with it on my stomach) |
06:53:48 | | Join [omni] [0] (n=omni@216.168.29.21) |
06:53:49 | *** | Server message 505: 'logbot :Private messages from unregistered users are currently blocked due to spam problems, but you can always message a staffer. Please register! ( http://freenode.net/faq.shtml#privmsg )' |
06:54:11 | lostlogic | TiMiD[FD]: yeah :( that's the other concern −− temperature. |
06:54:25 | lostlogic | I'm looking at it, but my bed time is approaching, so no promises ;) |
06:54:43 | jhMikeS | lostlogic: well...I'm too tired to commit anything but here's it before MoB: http://www.pastebin.ca/751252 |
06:55:41 | | Join psycho_maniac [0] (i=psycho_m@ppp053.hk.centurytel.net) |
06:56:43 | TiMiD[FD] | what causes thebug ? |
06:57:20 | TiMiD[FD] | the buffering engine that tries to fill the buffer until it's full, but the buffer getting swallowed by the pcm engine ? |
06:57:44 | psycho_maniac | is there anybody in here that uses patch 7738? i think it might be just be but i noticed a lot of disk activity now. i am using a current build and i dont see the same disk activity |
06:57:56 | | Join plus_M [0] (n=nyoro@71-220-25-114.mpls.qwest.net) |
06:58:36 | plus_M | Does rockbox support the viewing of jpg files? |
06:59:18 | | Quit Mouser_X (Read error: 110 (Connection timed out)) |
07:00 |
07:00:02 | | Join SirFunk_ [0] (n=Sir@206-159-155-246.netsync.net) |
07:00:03 | psycho_maniac | yes, as long as there not progressive scan pictures. |
07:00:18 | lostlogic | TiMiD[FD]: no, it's not actually buffering, it just somehow forgets to shut down the disk afaics |
07:00:53 | TiMiD[FD] | hmm but there seems to be activity on the disk when the bug occurs |
07:01:05 | TiMiD[FD] | (redlight blinking) |
07:01:13 | lostlogic | jhMikeS: nice and simple, definitely worth committing when you are awake ;) |
07:01:25 | | Quit SirFunk_ (Client Quit) |
07:01:27 | plus_M | Because the file browser does not show the jpg files |
07:01:34 | lostlogic | TiMiD[FD]: hmm, good to know −− mine just seems to be hanging out there. |
07:01:49 | lostlogic | I think there's already a flyspray for this out there... |
07:01:50 | jhMikeS | always good to bugfix by deleting things :) |
07:01:50 | TiMiD[FD] | it's not like a real disk activity though |
07:01:53 | lostlogic | Llorean: you around? |
07:01:56 | psycho_maniac | what do you have rockbox set to view? |
07:02:10 | plus_M | Well I haven't exactly edited its configuration |
07:02:26 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
07:02:26 | * | jhMikeS wonders about supporting progressive JPEG when the opportunity comes up |
07:02:39 | plus_M | I get the feeling that you're going to say "can't help you", but I'm using an unsupported build because the official one hanged |
07:03:07 | TiMiD[FD] | I'm gonna retest it |
07:03:23 | | Quit [omni] (calvino.freenode.net irc.freenode.net) |
07:03:23 | NSplit | calvino.freenode.net irc.freenode.net |
07:03:23 | | Quit tedrock (calvino.freenode.net irc.freenode.net) |
07:03:33 | TiMiD[FD] | fore some reasons it always does it on the bee gees album I have |
07:03:54 | TiMiD[FD] | I only have to rewind to the beginning of the playing song and it occurs |
07:04:56 | psycho_maniac | yes. only the default build is officially supported. sorry. |
07:04:59 | jhMikeS | Data abort at 0xDEADBEEE9EE5? |
07:07:10 | TiMiD[FD] | lostlogic: so yes the hdd light blinks but the heads doesn't move |
07:07:28 | | Quit TotallyInfected (Read error: 104 (Connection reset by peer)) |
07:07:48 | NHeal | calvino.freenode.net irc.freenode.net |
07:07:48 | NJoin | tedrock [0] (n=tedrock@d235-156-104.home1.cgocable.net) |
07:07:51 | | Join TotallyInfected [0] (n=ebola@pool-151-197-209-246.phil.east.verizon.net) |
07:09:12 | * | psycho_maniac misses the hd light |
07:09:51 | | Join [omni] [0] (n=omni@bestII.com) |
07:09:52 | *** | Server message 505: 'logbot :Private messages from unregistered users are currently blocked due to spam problems, but you can always message a staffer. Please register! ( http://freenode.net/faq.shtml#privmsg )' |
07:10:01 | lostlogic | jhMikeS: something new with my commit??? |
07:11:22 | jhMikeS | no, just a joke about the bee gees and data aborts :) |
07:13:28 | | Quit Spiritsoulx () |
07:14:12 | | Part plus_M ("Leaving") |
07:14:32 | TiMiD[FD] | lol |
07:14:37 | TiMiD[FD] | didn't noticed ^^ |
07:17:13 | *** | Saving seen data "./dancer.seen" |
07:18:19 | | Quit [omni] (calvino.freenode.net irc.freenode.net) |
07:18:33 | karashata | hey, the most recent build isn't crashing anymore! |
07:19:04 | karashata | though apparently skipping through 8 or 9 tracks does kill the playback until it's stopped and restarted... |
07:19:30 | karashata | should say, skipping through 8 or 9 tracks in quick succession, while the buffer's still trying to catch up |
07:20:10 | TiMiD[FD] | I for one will revert to the friday's svn to listen to my BEE6EE5 |
07:20:48 | | Join atsea-32 [0] (i=atsea-@gateway/tor/x-4417f4f8b0096f7d) |
07:21:38 | karashata | I'd have to do more actual testing to make sure everything works, but a quick swap from mp3 to nsfe didn't crash the player, so I'm guessing they're better now |
07:21:50 | karashata | swapping back worked too |
07:24:52 | NJoin | [omni] [0] (n=omni@bestII.com) |
07:24:53 | *** | Server message 505: 'logbot :Private messages from unregistered users are currently blocked due to spam problems, but you can always message a staffer. Please register! ( http://freenode.net/faq.shtml#privmsg )' |
07:34:50 | | Join bertrik [0] (n=Bertrik_@031-020-045-062.dynamic.caiway.nl) |
07:36:42 | | Join midgey [0] (n=tjross@westquad-188-65.reshall.umich.edu) |
07:37:19 | | Join [1]psycho_maniac [0] (i=psycho_m@ppp053.hk.centurytel.net) |
07:37:34 | | Quit psycho_maniac (Nick collision from services.) |
07:37:35 | | Nick [1]psycho_maniac is now known as psycho_maniac (i=psycho_m@ppp053.hk.centurytel.net) |
07:41:03 | | Quit [omni] (calvino.freenode.net irc.freenode.net) |
07:41:03 | NSplit | calvino.freenode.net irc.freenode.net |
07:44:01 | | Join Mouser_X [0] (n=someone@207.155.176.3) |
07:47:23 | NHeal | calvino.freenode.net irc.freenode.net |
07:47:23 | NJoin | [omni] [0] (n=omni@bestII.com) |
07:51:48 | | Quit [omni] (Read error: 104 (Connection reset by peer)) |
07:52:57 | psycho_maniac | i never realized that in order to use the dual processors on the ipods you had to update the bootloader. till i was looking at the "MajorChanges" wiki page and read that. it never said this on the main page i dont think when this was changed. |
07:54:37 | | Quit bertrik ("bye") |
07:56:04 | Mouser_X | psycho_maniac: I thought it did... |
07:56:04 | scorche | dual *cores* ;) |
07:57:00 | | Quit gromit` (Read error: 110 (Connection timed out)) |
07:57:26 | scorche | and which date are you looking at? |
07:58:15 | | Quit Mouser_X (Read error: 104 (Connection reset by peer)) |
07:59:04 | psycho_maniac | 16 Oct 01:25 |
08:00 |
08:00:33 | | Join kubiix [0] (n=Miranda@mos-81-27-201-28.karneval.cz) |
08:00:42 | | Quit midgey () |
08:00:45 | | Join Mouser_X [0] (n=someone@207.155.176.3) |
08:01:37 | psycho_maniac | that one is on the svn commits. and then this one ( 2007-03-04: ) is on the MajorChanges wiki page and said to update bootloader. |
08:02:08 | | Join mrkiko [0] (n=mrkiko@host177-100-static.32-88-b.business.telecomitalia.it) |
08:09:09 | | Quit Mouser_X (Read error: 104 (Connection reset by peer)) |
08:09:40 | | Join Mouser_X [0] (n=someone@207.155.176.3) |
08:11:20 | | Join [omni] [0] (n=omni@bestII.com) |
08:17:35 | | Quit Mouser_X (Nick collision from services.) |
08:17:50 | | Join Mouser_X [0] (n=someone@207.155.176.3) |
08:26:51 | | Quit hnakioeck (Remote closed the connection) |
08:28:30 | | Join inakimhnh [0] (i=0@86.122.116.44) |
08:29:45 | | Quit Mouser_X (Nick collision from services.) |
08:30:05 | | Join Mouser_X [0] (n=someone@207.155.176.3) |
08:33:20 | | Join Rob222241 [0] (n=Miranda@p54B172AB.dip.t-dialin.net) |
08:33:35 | | Join [0] (i=d9e1f773@gateway/web/cgi-irc/labb.contactor.se/x-172d303ba348744e) |
08:37:17 | | Part |
08:37:30 | scorche | did we mistakenly activate the ipod heater? |
08:38:11 | Mouser_X | If so, I'd say it's a good feature, what with winter coming up and all. |
08:38:19 | Mouser_X | :P |
08:38:38 | scorche | depends what hemisphere you are in... |
08:38:55 | Mouser_X | Yes, I'm aware of that. |
08:39:17 | * | scorche was just flexing his pedantic muscle |
08:40:20 | Mouser_X | Well, I'm in the hemisphere where it's getting colder. I figured that the guys in the other hemisphere activated the heater out of kindness for us... |
08:43:47 | | Quit TiMiD[FD] (Read error: 110 (Connection timed out)) |
08:48:02 | * | karashata hasn't had any hard drive issues with the latest build, yet... |
08:49:09 | * | Mouser_X hasn't use the latest build. |
08:49:15 | Mouser_X | *used |
08:49:44 | Mouser_X | I'm currently attempting to build it (with patches.) |
08:50:06 | Mouser_X | (I actually expect it to fail when it hits the GBS patch...) |
08:50:48 | karashata | unless the patches have been brought up-to-date, I wouldn't be surprised if it failed |
08:51:30 | Mouser_X | Indeed. |
08:51:36 | | Quit Rob2222 (Read error: 110 (Connection timed out)) |
08:51:47 | | Join pixelma [0] (i=pixelma@rockbox/staff/pixelma) |
08:51:48 | Mouser_X | The GBS patch succeeded, but it was offset by -55 lines. |
08:52:02 | | Join ompaul [0] (n=ompaul@gnewsense/friend/ompaul) |
08:54:32 | karashata | good to hear it worked for ya |
08:56:49 | Mouser_X | I didn't mean it compiled. I meant it patched successfully. The build process hasn't gotten that far. |
08:57:04 | Mouser_X | (It's very slow on my craptop. 1.5 hours or more.) |
08:58:41 | karashata | ohhh, nvm then... |
08:58:47 | karashata | hope it works for you though |
08:59:04 | amiconn | Mouser_X: YOu're using cygwin? |
08:59:37 | Mouser_X | Yes. I've already been told that I should install Linux on my craptop. I probably should, but I don't currently have enough free space. |
09:00 |
09:00:18 | amiconn | I guess you have a virus scanner installed. On my laptop it makes a big difference when I disable the virus scanner while building rockbox |
09:00:42 | * | karashata wants to put Gentoo on his laptop, but doesn't have the space |
09:00:43 | amiconn | Something like 30 minutes -> 12 minutes for a full swcodec build |
09:00:44 | Mouser_X | No, I uninstalled the virus scanner because it made things *FAR* worse... |
09:01:13 | Mouser_X | (I only had it on here for a day or 2. Perhaps a week or 2 ago.) |
09:01:45 | amiconn | Wow, and then it still needs >1 hour? |
09:01:55 | Mouser_X | My craptop is about 200 mhz. |
09:01:56 | * | amiconn wonders about the hw specs of that laptop |
09:02:03 | amiconn | oh |
09:02:08 | Mouser_X | (It was free.) |
09:10:01 | Mouser_X | The MOD patch compiled successfully (I just saw it copy the mod.codec file). |
09:10:11 | Mouser_X | That patch is from before the MoB commit. |
09:10:27 | | Quit miepchen^schlaf (Read error: 104 (Connection reset by peer)) |
09:17:09 | Mouser_X | Well I'm surprised. |
09:17:15 | *** | Saving seen data "./dancer.seen" |
09:17:30 | karashata | oh? |
09:17:33 | Mouser_X | GBS compiled successfully. That patch is from June or July. |
09:17:54 | karashata | they fixed the MoB stuff (or whatever) to make the patches work again? |
09:18:10 | karashata | isn't that nice, heh |
09:18:39 | Mouser_X | No. I'm using the GBS and MOD patches are available on the tracker. Neither of them have been updated since the MoB commit (GBS hasn't been updated since June or July, probably earlier.) |
09:18:52 | Mouser_X | Oh, I misunderstood what you said. |
09:19:01 | karashata | yeah, ya did... |
09:19:26 | karashata | basically, what work they've done to the MoB stuff seems to have allowed the patches to work again |
09:19:38 | karashata | as well as fixing the data abort issues I was having |
09:19:54 | Mouser_X | Maybe they did fix the MoB stuff. I have 2 svn's for Rockbox. One from shortly after MoB, and one from a few minutes (hours now) ago. The one from shortly after MoB failed when it hit the GBS codec. |
09:20:10 | karashata | and I still haven't run into that "hard drive spinning constantly" issue some of the people seem to have |
09:20:41 | karashata | the r15324 commit didn't work when I tested it |
09:21:02 | karashata | still had the same issues as the r15314 I had been using previous to that one |
09:21:12 | karashata | r15330 is working beautifully for me |
09:22:44 | karashata | about my only problem now, is I only have space for maybe two or three more songs |
09:22:53 | Mouser_X | heh. |
09:23:13 | karashata | 12.2 MB free |
09:23:19 | karashata | out of 18.6 GB |
09:23:45 | Mouser_X | That's a pretty tight fit there... |
09:23:51 | karashata | yeah |
09:24:05 | karashata | that's every single piece of music in my library, though |
09:24:17 | Mouser_X | Impressive... Most, impressive. |
09:24:27 | Mouser_X | (/vader voice) |
09:24:35 | * | karashata chuckles |
09:25:30 | karashata | any more music and I'll either have to start weeding stuff out that I don't listen to much anymore, start getting picky with what I have on the mp3 player, or look into putting a bigger drive in it |
09:29:25 | | Join Rob2222 [0] (n=Miranda@p54B16176.dip.t-dialin.net) |
09:31:54 | | Quit psycho_maniac (" I love my HydraIRC -> http://www.hydrairc.com <-") |
09:37:05 | Mouser_X | The light has gone out on my wireless adapter, but I still *seem* to be connected. |
09:37:39 | Mouser_X | Crud, wrong channel, sorry. |
09:38:25 | Mouser_X | (My touchpad is far too sensitive...) |
09:41:58 | | Join freki [0] (n=thedorn@dslb-088-072-245-176.pools.arcor-ip.net) |
09:43:17 | | Join psycho_maniac [0] (i=psycho_m@ppp053.hk.centurytel.net) |
09:46:42 | | Join mrkiko_ [0] (n=mrkiko@host177-100-static.32-88-b.business.telecomitalia.it) |
09:47:41 | | Quit Rob222241 (Read error: 110 (Connection timed out)) |
09:52:34 | | Join Thundercloud [0] (n=thunderc@resnet16.nat.lancs.ac.uk) |
09:59:16 | | Quit mrkiko (Read error: 110 (Connection timed out)) |
10:00 |
10:05:00 | | Join linuxstb [0] (n=chatzill@i-83-67-212-170.freedom2surf.net) |
10:05:58 | | Part linuxstb |
10:07:55 | | Join stripwax [0] (n=Miranda@i-83-67-214-206.freedom2surf.net) |
10:08:09 | | Join pepie34 [0] (n=pepie34@cop60-1-82-240-26-92.fbx.proxad.net) |
10:08:19 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
10:08:41 | | Nick midkay_ is now known as midkay (n=midkay@c-24-19-236-139.hsd1.mn.comcast.net) |
10:14:11 | | Join zicho [0] (n=martin@c-6a98e355.68-7-64736c14.cust.bredbandsbolaget.se) |
10:18:26 | | Quit Mouser_X (Nick collision from services.) |
10:18:40 | | Join Mouser_X [0] (n=someone@207.155.176.3) |
10:23:08 | Mouser_X | amiconn: Rockbox finished compiling. I'm making the ZIP now. While you might not care, I just thought I'd point it out, as an illustration of how long it takes RB to build on my craptop. |
10:24:20 | | Join Lear [0] (i=chatzill@rockbox/developer/lear) |
10:29:21 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
10:29:29 | | Join Rob2222 [0] (n=Miranda@p54B16176.dip.t-dialin.net) |
10:34:55 | | Quit Mouser_X (Read error: 104 (Connection reset by peer)) |
10:36:39 | | Join Mouser_X [0] (n=someone@207.155.176.3) |
10:37:14 | | Nick parafin|away is now known as parafin (i=parafin@parafin.dialup.corbina.ru) |
10:38:37 | | Part egolost |
10:53:21 | | Quit psycho_maniac (" HydraIRC -> http://www.hydrairc.com <- In tests, 0x09 out of 0x0A l33t h4x0rz prefer it :)") |
10:53:51 | | Join nanok [0] (n=nanok@194.145.183.75) |
10:54:00 | nanok | hey there |
10:54:11 | nanok | i'm finally back |
10:54:15 | * | nanok rockboxed |
10:54:31 | nanok | i jost dropped by to say "wow!" |
10:54:32 | nanok | :) |
10:54:54 | nanok | hm |
10:54:58 | | Nick nanok is now known as nnk (n=nanok@194.145.183.75) |
11:00 |
11:00:32 | | Quit pepie34 ("Ex-Chat") |
11:06:07 | | Join AlexC [0] (n=AlexC@dragnet2034196123.dragnet.com.au) |
11:11:56 | | Join desowin [0] (n=desowin@hdp186.internetdsl.tpnet.pl) |
11:12:50 | nnk | seem to have a strange problem |
11:13:20 | nnk | sometimes, when i try to play an ogg, the player refuses to play |
11:13:40 | nnk | after that, it refuses to play anything, even other formats |
11:13:51 | AlexC | sounds like a bug |
11:13:59 | nnk | a reboot seems to solve the problem |
11:14:02 | AlexC | not that i know anything at all about anything |
11:14:11 | | Nick JRoT|Sleep is now known as JRoT (n=JRoT@ip4da03737.direct-adsl.nl) |
11:14:21 | nnk | but interestingly enough, the reboot is allways very sllow (the shutdown, more precisely) |
11:15:05 | nnk | as opposed to the usual 2-4 seconds to shutdown, it takes around 30s i think (never counted though, but it's long) |
11:15:44 | nnk | something might be wrong with the ogg's, but still.. |
11:16:02 | nnk | doesn;t sound like.. uhm.. normal behaviour |
11:16:03 | nnk | :) |
11:17:18 | *** | Saving seen data "./dancer.seen" |
11:22:04 | AlexC | no it doesn't |
11:22:04 | | Part mrkiko_ |
11:22:04 | AlexC | do the oggs play on computer? |
11:22:04 | AlexC | nnk |
11:22:06 | nnk | AlexC: yes |
11:22:14 | nnk | they do, never had a prolem with them |
11:22:19 | AlexC | are they complete? |
11:22:26 | nnk | they play fine on the player also, after a reboot :) |
11:22:29 | AlexC | are they smooth? |
11:22:34 | | Part pixelma |
11:22:39 | nnk | yes, they are anithing but perfect :) |
11:22:47 | nnk | anything |
11:22:48 | nnk | sorry |
11:23:12 | AlexC | are you on the latest version of rockbox? |
11:23:23 | nnk | yup, the daily build of yesterday |
11:23:32 | | Quit TotallyInfected () |
11:23:39 | AlexC | hmmm] |
11:23:49 | nnk | i should think (i just got my player yesterday, first thing was to rockbox it ;) ) |
11:24:09 | nnk | the player is a sansa e200 (vanilla not r) |
11:24:22 | AlexC | i'm not an admin or programmer or anything so i don't think i can help you |
11:24:40 | AlexC | have you searched docs? |
11:24:48 | Mouser_X | nnk: Try a new build (not the daily build, something newer). |
11:24:50 | nnk | AlexC: no worries, it's good to answer some questions about it, at least one feels listned to |
11:24:53 | nnk | :) |
11:25:07 | AlexC | :) |
11:25:18 | nnk | Mouser_X: newer than the yesterday one? |
11:25:32 | Mouser_X | There was a recent commit that might have fixed your problem. I doubt it's in the daily builds yet. |
11:25:36 | nnk | Mouser_X: i'm afraid you lost me here. is that possible? or you mean a custom build |
11:25:40 | Mouser_X | You'd need a current build. |
11:25:45 | nnk | aahm |
11:26:01 | nnk | sorry, that must be my lack of knowledge of the project |
11:26:06 | nnk | i think i meant current |
11:26:17 | Mouser_X | Daily builds are a "snapshot" of the current build. The current builds are as new as you can possibly get. |
11:26:19 | nnk | let me check where i downloaded from, but i think current is the right word |
11:27:08 | Mouser_X | Well, get a newer one. The commit that I'm refering to happened about 4-8 hours ago (due to time differences, I'm not quite sure). |
11:28:02 | nnk | the link was |
11:28:03 | nnk | http://build.rockbox.org/dist/build-sansae200/rockbox.zip |
11:28:22 | | Join Bagder_ [0] (n=daniel@1-1-5-26a.hud.sth.bostream.se) |
11:28:29 | nnk | Mouser_X: than it doesn;t matter which i have, it is not that one for sure |
11:28:37 | nnk | Mouser_X: thanks a lot |
11:28:41 | nnk | i will try |
11:28:54 | nnk | i also discovered another possible bug |
11:29:22 | linuxstb | Soap: Are you around? |
11:29:40 | nnk | due to the fact i don't know how to plugin the player in the usb _and_ listen to music, i kind of...tryed trial and error |
11:29:58 | nnk | at some point i tyed by holding down the context menu and plugging in |
11:30:16 | | Quit freki (Read error: 110 (Connection timed out)) |
11:30:17 | nnk | it bricked it :). had to take out the screwdrivers, take the battery out, to reboot |
11:31:04 | nnk | i finally discovered it was the select button (the one in the middle of the wheel, on the sansa e200) |
11:31:33 | nnk | btw, i couldn't find that in docs, maybe i didn;t look hard enough |
11:31:43 | nnk | (i usually use grep to look really hard :) ) |
11:31:50 | Mouser_X | There is a manual. That sort of stuff should be in there. |
11:32:01 | linuxstb | Holding the power button for about 15 seconds is a hardware power-off, that should have worked. |
11:32:08 | nnk | Mouser_X: i did look, ofcourse |
11:32:09 | * | Mouser_X actually reads that stuff. |
11:32:19 | nnk | linuxstb: noope |
11:32:22 | Mouser_X | I don't have grep. |
11:32:53 | nnk | Mouser_X: linux freaks do. don't worry about it ;), unix talk |
11:33:35 | linuxstb | nnk: Sorry, it's MENU, not power... |
11:33:37 | nnk | maybe i should try to download the full manual instead of browsing online (hm, why didn;t i think of that before? ) |
11:33:51 | nnk | linuxstb: it's the same on the sansa, i think, right? |
11:33:57 | Mouser_X | I don't what grep is. I also know I don't have it. |
11:34:21 | | Join AlexC__ [0] (n=AlexC@dragnet2034196105.dragnet.com.au) |
11:34:23 | Mouser_X | *I know what grep is. |
11:34:37 | Mouser_X | (Wow, crappy typo.) |
11:34:40 | linuxstb | nnk: I'm talking about the Sansa - holding MENU for about 15 seconds should always power-off according to what I've read (I don't own one). |
11:34:41 | nnk | Mouser_X: you would love it :). us unix admins couldn't live without it |
11:34:59 | | Join davina [0] (n=davina@cpc1-sout6-0-0-cust616.sotn.cable.ntl.com) |
11:35:04 | nnk | linuxstb: well, in that case it didn't, i did try |
11:35:16 | nnk | Mouser_X: ahm, okay :) |
11:35:22 | | Join przemhb [0] (n=przemhb@fan115.internetdsl.tpnet.pl) |
11:35:38 | | Quit AlexC (Nick collision from services.) |
11:35:46 | nnk | Mouser_X: than how can you live without it? :-P |
11:35:59 | | Quit AlexC__ (Client Quit) |
11:36:03 | | Quit midkay ("Leaving") |
11:36:14 | | Join AlexC [0] (n=AlexC@dragnet2034196105.dragnet.com.au) |
11:37:45 | Mouser_X | I know *what* it is. I've never used, or seen, it. |
11:38:27 | nnk | Mouser_X: it's okay, it was a joke (with a taste of flame in it ;) ) |
11:38:53 | scorche | it is the power button |
11:39:12 | nnk | Mouser_X: anyway, thanks for the tip. i will try the latest current, and see if it still breaks |
11:39:30 | nnk | and report back here |
11:40:05 | scorche | the power button says menu, but we call it "power" ;) |
11:40:13 | | Join midkay [0] (n=midkay@c-24-19-236-139.hsd1.mn.comcast.net) |
11:40:25 | scorche | (to avoid confusion with the submenu button) |
11:40:50 | nnk | anyway, other than that it is bloody amazing. i barely saw the original firmware, and couldn't care less. and it does sound great (i was afraid the sansa won't be that great..) |
11:41:32 | nnk | scorche: agreed, it has the power icon on it, the menu underneath. it is power :) |
11:41:41 | Mouser_X | IMHO, the Gigabeat and the Sansa players are among the best targets. |
11:43:55 | nnk | Mouser_X: the sansa also have another advantage: they are comparatively cheap, and easy to get (not rare) |
11:44:10 | nnk | the only thing that bugs me is the rechargeable battery |
11:44:49 | | Quit Bagder (Read error: 110 (Connection timed out)) |
11:44:53 | nnk | allways hated that. but having rockbox on it was too cool to pass (i'm fed up with transcoding to mp3, finding small bugs i know will never be addressed, and so on) |
11:46:48 | Mouser_X | The Gigabeat isn't *that* rare, nor *that* expensive. The Sansa is cheaper, but the Gigabeat has more storage, and faster CPU. |
11:47:45 | nnk | Mouser_X: interesting, i don;t even know the gigabeat, found out about them first on the rockbox site |
11:49:06 | nnk | which should be a note to producers. also, i must say i only ever bought the sansa because it is rockbox-certified ;), i would have never even considered it otherwise, regardless the features |
11:49:20 | Mouser_X | Very true. |
11:51:57 | nnk | they should concentrate on making ecelent hardware, for a better price, and support the people who actually know how to do it, for the firmware. i almost can;t believe it, but the rockbox team really did something amazing: it made the best firmware i have ever seen or heard about on closed platforms (except the first, the archos, if i understand correctly, kudos to them) |
11:52:51 | nnk | i still have a hard time processing this simple truth, allthough i have been running opensource software for quite a few years now (exclusively ;) ) |
11:53:05 | | Join bluebrother [0] (i=0787FPe0@rockbox/staff/bluebrother) |
11:53:17 | nnk | which reminds me: i am finally trully free, even my player is opensource :) |
11:53:57 | AlexC | w00t |
11:54:03 | AlexC | your bootloader isn't |
11:54:17 | AlexC | or is it? |
11:54:44 | AlexC | what about the bios on your computer? |
11:54:47 | | Join PaulJam [0] (n=pauljam@vpn-3040.gwdg.de) |
11:55:25 | nnk | AlexC: yes, yes. i was thinking about that |
11:55:25 | | Join JdGordon [0] (n=jonno@c210-49-113-143.smelb1.vic.optusnet.com.au) |
11:55:33 | nnk | why do you have to say it out loud.. |
11:56:34 | nnk | my computer is a thinkpad, i couldn't really envisage open bios for it. not in the imediate future at least (i do know there is an open-bios project for x86, but thinkpads are.. too different) |
11:57:38 | nnk | AlexC: my bootloader on the sansa is the rockbox one, if i understand correctly (it is fortunately not a rhapsody-crap one, so i guess the bootloader was replaced completely, am i right?) |
11:58:51 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
11:59:32 | * | AlexC shrugs |
12:00 |
12:01:54 | | Quit AlexC ("Ex-Chat") |
12:05:27 | | Join midkay_ [0] (n=midkay@c-24-19-236-139.hsd1.wa.comcast.net) |
12:09:08 | | Join rep|icant_ [0] (n=rep|ican@adsl-074-183-167-249.sip.bhm.bellsouth.net) |
12:11:56 | | Join pepie34 [0] (n=pepie34@cop60-1-82-240-26-92.fbx.proxad.net) |
12:12:50 | | Join midkay__ [0] (n=midkay@c-24-19-236-139.hsd1.mn.comcast.net) |
12:13:00 | | Quit midkay (Nick collision from services.) |
12:13:02 | | Nick midkay__ is now known as midkay (n=midkay@c-24-19-236-139.hsd1.mn.comcast.net) |
12:13:52 | | Join lee-qid [0] (n=liqid@p54967C17.dip.t-dialin.net) |
12:16:42 | | Quit rep|icant (Read error: 110 (Connection timed out)) |
12:19:33 | | Join puzzles [0] (n=dan@xmms2/developer/puzzles) |
12:21:51 | nnk | oki |
12:21:58 | nnk | current build installed |
12:22:09 | nnk | seems to work fine. we'll see if it still locks |
12:23:17 | nnk | btw, another question (probably sansa e200 port specific): it seems to not charge above 75 percent |
12:23:39 | nnk | it was plugged in all night.. |
12:23:53 | nnk | is that ..uhm.. normal? |
12:23:57 | nnk | like, a feature? :) |
12:27:16 | puzzles | i just asked in #ipod-linux, but maybe someone in here can help. anyone know where i can read up on the state of 6g ipods? is there some hacking going on? does it look completely unfeasible? |
12:27:21 | nnk | also: is the estimated time remaining allready "reliable" on the sansa? or should i not take note of it (tipically, i get anestimation of about 5hours, which maybe isn't so surprising, considering the battery is actually at 75percent) |
12:27:46 | bluebrother | puzzles: for Rockbox development on the 6G check the New Ports forums. And nobody is working on it. |
12:27:49 | | Join Benoitb [0] (n=Benoitb@86.76.66.53) |
12:27:50 | nnk | puzzles: afaik, ipod-linux and rockboxare separate projects |
12:28:15 | puzzles | bluebrother: thanks |
12:28:21 | bluebrother | nnk: the runtime estimate is wrong on all newer targets because it hasn't been calibrated. |
12:28:34 | nnk | puzzles: so whatever the status in rockbox, the status in ipod-linux might be different |
12:28:57 | nnk | bluebrother: okay, i thought something like that might be the case |
12:29:08 | puzzles | nnk: rockbox based its code off of the ipod-linux team's hacking efforts and code |
12:29:13 | nnk | bluebrother: what does it take to be calibrated? can the users help? |
12:29:31 | | Quit midkay_ (Read error: 110 (Connection timed out)) |
12:29:39 | bluebrother | nnk: no idea. But I don't think it would make sense to do that before the power consumption issues are fixed. |
12:29:53 | nnk | puzzles: probably, i do not know much about it. it was just a point to take into consideration (i do know they colaborate sometimes) |
12:30:12 | nnk | bluebrother: good point, i was meaning to ask |
12:30:29 | nnk | is there an open discussion about that? what is the progress? |
12:30:49 | | Quit PaulJam (".") |
12:31:05 | | Quit Mouser_X (Read error: 110 (Connection timed out)) |
12:31:09 | | Join Arathis [0] (n=doerk@p508A6620.dip.t-dialin.net) |
12:31:21 | bluebrother | I don't think there is any progress. The major issue with the hardware specs being unknown remains |
12:31:26 | bluebrother | (and makes it quite hard) |
12:31:40 | linuxstb | nnk: No Rockbox developers own a 6G, and as far as I know, no-one outside the Rockbox project has made it known to us that they are working on a port. |
12:31:46 | nnk | i assume if rockbox hasn;t bettered the original firmware by now, there must be something very wrong/ something "in the way" |
12:32:08 | * | amiconn wonders whether he should commit his broadcom driver improvements |
12:32:17 | amiconn | I mean in their current state |
12:32:39 | nnk | bluebrother: :( |
12:32:40 | bluebrother | what does it do? |
12:32:52 | amiconn | No major breakthrough in fps as measured by test_fps, but the transfer in lcd_update_rect got considerably faster |
12:33:14 | nnk | bluebrother: sandisk should give something back and at least give the specs and maybe a helping hand with some code |
12:33:19 | amiconn | The problem is that test_fps sends back_to_back, and the broadcom then always needs its 14ms for internal operation |
12:33:31 | linuxstb | amiconn: Then it sounds good. Less time spent in lcd_update_rect must be a good thing. |
12:33:34 | nnk | rockbox is allready selling theyr players, so i don;t think it's such a big deal to ask |
12:33:42 | bluebrother | nnk: I guess they simply aren't allowed to do. But they didn't help the project too much anyway |
12:34:06 | nnk | bluebrother: yes, i know. there was an..attempt at helping |
12:34:08 | nnk | so to speak |
12:34:09 | | Join rep|icant [0] (n=rep|ican@adsl-074-183-167-249.sip.bhm.bellsouth.net) |
12:34:21 | amiconn | I did tests without the "finishup" wait, and then got 100fps fullscreen when boosted (but of course some updates weren't performed in the broadcom |
12:34:27 | linuxstb | nnk: IIUC, someone in their marketing department sent us some free hardware, but all attempts at getting technical help have been refused. |
12:34:41 | bluebrother | nnk: ask this sandisk, maybe it helps ;-) Unfortunately we can't do much about it here. |
12:34:57 | nnk | maybe they are bound by some contracts with the providers of the pieces of hardware they are using.. |
12:34:58 | * | amiconn should measure the transfer speed without finishup and the old code |
12:35:24 | amiconn | Oh, and I cut out quite some cruft from lcd-ipod.c |
12:35:28 | amiconn | Saves almost 400 bytes |
12:35:40 | puzzles | heh |
12:35:44 | puzzles | that was fruitless |
12:35:48 | amiconn | And I introduced register names |
12:35:51 | nnk | bluebrother: i would. but i would like to not do it n vain. i am allready thinking about the idea |
12:36:02 | * | bluebrother considered buying a sansa yesterday |
12:36:03 | amiconn | ..instead of the annoying outw() / inw() |
12:36:22 | nnk | as i said: i only bought the sansa because of rockbox, no other reason, none. and i bet i am not the only one |
12:37:13 | | Join moos [0] (i=moos@m147.net81-66-159.noos.fr) |
12:37:22 | puzzles | that's why i want to buy an ipod |
12:37:32 | puzzles | i can't stand apple otherwise :) |
12:38:02 | puzzles | and if there was any effort in porting the 6g, i would probably join in, but i'm not seeing much |
12:38:22 | * | amiconn would really like that 160GB of disk space |
12:38:26 | nnk | puzzles: why not the 6G e200? i would say it is a valid option |
12:38:31 | puzzles | amiconn: bingo. ;) |
12:39:22 | puzzles | nnk: see amiconn's remark |
12:39:49 | nnk | puzzles: i'm afraid i don't get it |
12:40:04 | puzzles | i need to have all my music on the player or it's not worth it |
12:40:10 | nnk | puzzles: hmm.. 6g doesn;t stand for 6GB? |
12:40:18 | amiconn | Imho the e200 is too bulky for a flash target. If I'd want to buy a flash target supported by rockbox today, I'd choose the c200 |
12:40:54 | | Join pixelma [0] (i=pixelma@rockbox/staff/pixelma) |
12:41:00 | puzzles | nnk: what does it stand for then? the largest size e200 i see is 8GB |
12:41:30 | nnk | amiconn: that is a good point. but the batterry is even smaller, and it is reported to sound worse than the e200 (allthough it might only be the firmware, rockbox might sound almost the same) |
12:41:36 | karashata | nnk: 6th generation iPod, otherwise known as the iPod Classic |
12:41:46 | nnk | karashata: i got it now ;) |
12:41:54 | puzzles | oh, haha |
12:42:13 | nnk | puzzles: i missread your question |
12:42:18 | pixelma | bluebrother: re. rbutil and c200 - I tried the latest one available (v. 1.0.2) on XP and it didn't auto-detect my c250 |
12:42:28 | puzzles | nnk: and i misunderstood your misunderstanding :) |
12:42:28 | nnk | puzzles: maybe you could consider an hdd-based cowon or iriver |
12:42:34 | | Quit rep|icant_ (Read error: 110 (Connection timed out)) |
12:42:55 | nnk | i hear they are excelent, and some of them are rockbox-certified :) (i get a kick out of saying this :-D ) |
12:43:07 | puzzles | i'm unimpressed with iriver, especially the storage space |
12:43:09 | amiconn | linuxstb: The transfer speed increase is just ~5% ... :| |
12:43:18 | puzzles | i don't mind a 5.5g ipod |
12:43:37 | * | amiconn likes his iriver H180 most :) |
12:43:39 | puzzles | but i would just like to know about the 6g status |
12:44:16 | puzzles | and this is what i've found so far: http://forums.rockbox.org/index.php?topic=13355.0 :P |
12:44:43 | linuxstb | puzzles: That's the status, at least as far as Rockbox is concerned... |
12:44:46 | nnk | puzzles: the iriver is quite impressive, imho, especially in their attitude to their users (i don;t know about their attitude to rockbox though), and the fact that they allways provide very good sound quality and features |
12:45:06 | puzzles | linuxstb: what is? that post isn't even english |
12:46:15 | puzzles | nnk: yeah, that is nice, but the devices themselves look clunky and seem to only offer up to 40GB |
12:46:31 | nnk | puzzles: that, i don't know |
12:47:03 | karashata | puzzles: to put it simple, there isn't a port being looked into currently for the 6g iPod, because the hardware is different from the older iPods, and the firmware is more than likely encrypted as well |
12:47:06 | bluebrother | pixelma: :( I guess sansapatcher recognizes it just fine? |
12:47:11 | nnk | also look at cowon, they are just as good as iriver lately, as far as i could tell (great sound out of the box, great support, good build allround) |
12:47:18 | | Quit BigBambi (Read error: 104 (Connection reset by peer)) |
12:47:39 | amiconn | linuxstb: In fact the speedup is higher when not boosted. +4.8% @80MHz, +5.8% @30MHz |
12:47:50 | puzzles | karashata: ok, but i'm not really looking for a port so much as a hacking effort |
12:48:27 | karashata | ah, well, as far as Rockbox is concerned, there isn't one yet |
12:48:58 | pixelma | bluebrother: yes, I could use sansapatcher without a problem. |
12:49:48 | linuxstb | amiconn: Every little helps... |
12:50:24 | nnk | amiconn: are you talking about eth or wifi? |
12:51:23 | nnk | amiconn: to be honest, either way i came to hate broadcom. and not because of throughput, but because they never seem to work right |
12:51:34 | amiconn | nnk: iPod Video. |
12:51:36 | nnk | amiconn: but maybe you are not even talking about pc hardware? |
12:51:41 | nnk | amiconn: ok :) |
12:51:44 | amiconn | BCM2722 |
12:51:57 | nnk | amiconn: i am young at this |
12:52:15 | nnk | player with wifi. damn. i only had sigmatel-base dplayers so far |
12:52:21 | nnk | :) |
12:52:26 | bluebrother | pixelma: sorry, got to leave for weekend. |
12:52:28 | amiconn | From what I understand so far, our write function transfers the pixel data into an internal buffer of the BCM (it has 1.25MB IRAM according to the product brief). Setting the control reg to 0x31 then triggers some internal update of the bcm, which always takes 14ms (in the mode we have it running, whatever that is) |
12:52:51 | bluebrother | I'll see if I get an idea about this sansapatcher thing |
12:52:54 | pixelma | bluebrother: don't know if it means something but rbutil finds the correct drive but doesn't recognise it as c200 |
12:52:54 | nnk | i was quite happy with them also. they only have one problem: no rockbox (or opensource firmware, in general) |
12:53:12 | amiconn | I am not sure yet why the bcm has 2 alternate sets of registers |
12:53:16 | | Quit bluebrother ("weekend") |
12:53:47 | | Join ender` [0] (i=krneki@84-255-206-8.static.t-2.net) |
12:53:53 | amiconn | I can use the alternate set just fine, but when mixing them (e.g. set it up via alternate and then send data via primary) it locks up |
12:54:29 | amiconn | I also tried using them in an alternating fashion, but that doesn't speed up things at all |
12:54:48 | amiconn | Probably because the internal buffer addresses we're writing to are still the same |
12:55:10 | amiconn | The bcm also has a programmable pll - but that's probably set up by the bcm firmware itself |
12:55:55 | amiconn | linuxstb: How is the firmware partition laid out, and do you know about the internal structure of the bcm firmware blob? |
12:56:11 | pixelma | JdGordon: thanks for the answer (at least one) :) |
12:56:42 | amiconn | And finally, does the filename VMCS.BIN ring any bell (written as on FAT, i.e. "VMCS BIN")? |
12:57:36 | JdGordon | pixelma: the one you were expecting? |
12:57:48 | nnk | pixelma: so you patched.installed the bootloader, but are stuck at installing rockbox itself, because the rbutil doesn't recognize the c200? |
12:58:20 | pixelma | nnk: no, I have it installed. Was just a test report to bluebrother. |
12:58:34 | nnk | pixelma: oh, okay |
12:59:10 | nnk | pixelma: btw, how does the c200 sound? i was in two minds about getting the c or the e |
12:59:45 | pixelma | there shouldn't be huge differences between the two in sound |
12:59:49 | nnk | finally got the e (mainly because of the cardslot support, and being unsure if e doesn;t really sound a bit better) |
13:00 |
13:00:24 | nnk | yeah, maybe the reports i heard were based on some first firmware from sandisk, and the hw itself is just as good |
13:01:14 | nnk | anyway, if it sounds anything like the e, with rockbox, it is surely more than suitable ;) |
13:01:16 | amiconn | The c200 also supports microsd |
13:01:32 | pixelma | but not in Rockbox yet... |
13:01:36 | nnk | amiconn: ahm, i might have old info than |
13:01:54 | amiconn | (not with rockbox yet - but that should not be too difficult to fix) |
13:02:05 | nnk | amiconn: yes, i was talking about rockbox. who cares about the original firmware? :) |
13:02:41 | | Quit homielowe (Read error: 110 (Connection timed out)) |
13:04:01 | * | nnk dreams of a day when the original firmware is just a demo "this is the player, it actually works. now go ahead and install rockbox" |
13:04:08 | linuxstb | amiconn: It's a FAT16 image. |
13:04:08 | nnk | :) |
13:04:41 | stripwax | amiconn - when you set the control reg for the primary set, and then send the next frame via the alternate set (without waiting first), does it lock up? or is that what you meant by doing it in an alternating fashion and it didn't speed anything up |
13:04:58 | stripwax | nnk - heh |
13:05:37 | amiconn | stripwax: Without waiting it just does't accecpt the frame, although I didn't try alternating + no wait yet |
13:05:40 | nnk | stripwax: well, you can;t blame a man for dreaming |
13:05:44 | nnk | :) |
13:06:19 | stripwax | amiconn - wondering if it's a double-buffer implementation |
13:06:40 | nnk | x86 won, de facto, because the specs were open. it's a historical fact. why the hell don;t they just all wake up and smell the roses? |
13:07:06 | stripwax | what did it 'win' ? |
13:07:33 | amiconn | stripwax: That's what I am thinking, but then there must also be an alternate buffer address... You obviously must not fiddle with the buffer that's currently being processed... |
13:07:41 | pixelma | JdGordon: not completely, but hopefully this will lead to a discussion. I remember one short but very fast discussion here and I thought that the mailing list was the better place (because it isn't so fast and people have more time to think before answering) |
13:08:22 | stripwax | amiconn - not necessarily, maybe writes to the 'same' buffer address get mapped to an alternate buffer inside the bcm depending which set you used |
13:09:07 | amiconn | Nope. If that were the case, using alternate + waiting would be faster, but it isn't |
13:09:37 | | Join Rondom [0] (n=Rondom@p57A95776.dip.t-dialin.net) |
13:10:46 | stripwax | only if the flag we're waiting on is 'this buffer is write-locked' rather than 'one of the buffers is write-locked', I guess. |
13:11:10 | stripwax | of course, I'm guessing |
13:11:20 | amiconn | It is 'this buffer is write locked', I'm pretty sure |
13:11:35 | amiconn | We need to know the second buffer address |
13:11:54 | amiconn | But it might be that the boot-up bcm firmware doesn't actually have 2 buffers |
13:12:01 | stripwax | ah. true. |
13:12:16 | amiconn | That's why I'm interested in the on-disk version |
13:12:23 | stripwax | gotcha |
13:12:27 | * | stripwax is up to speed now |
13:12:45 | amiconn | Unfortunately all this videocore stuff seems to be secret :( |
13:13:31 | stripwax | What is the fps of the flash-based lcd diagnostic mode? |
13:13:39 | stripwax | wondering if that sets up dual buffers or not |
13:13:46 | nnk | stripwax: well, you could say it won the "shittiest architecture which is also the most popular worldwide" award :) |
13:13:57 | nnk | but it is, i think, the most widespread |
13:14:04 | | Quit pepie34 ("Ex-Chat") |
13:14:26 | stripwax | 'most widespread what' though? there's an awful lot of non-x86 embedded controllers out there |
13:14:35 | | Join BigBambi [0] (n=alex@rockbox/staff/BigBambi) |
13:14:45 | * | stripwax plays with Select+Left |
13:14:59 | nnk | stripwax: i am talking about personal computers man, not embedded. in embeded stuff, probably x86 is the black-sheep |
13:15:24 | stripwax | nnk - oh, thought we were talking about mp3 players |
13:15:51 | pixelma | nnk: that is off-topic here ;) |
13:16:11 | nnk | stripwax: neah, i don;t know enough about embeded to dare to say anything about which arch is most widespread, and even so,i am quite sure x86 is on the bottom of the list |
13:16:43 | nnk | pixelma: yeah, you could say. i was just making a comparison: history shows open-specs hw is lucrative |
13:16:46 | nnk | but nevermind |
13:16:52 | * | amiconn gone |
13:17:19 | *** | Saving seen data "./dancer.seen" |
13:20:02 | | Join PaulJam [0] (n=pauljam@vpn-3039.gwdg.de) |
13:29:07 | | Join Nico_P [0] (n=nicolas@rockbox/developer/NicoP) |
13:30:38 | | Join lazka [0] (n=lazka@85-125-223-96.dynamic.xdsl-line.inode.at) |
13:38:42 | linuxstb | nnk: ARM seems to be pretty dominant, at least in DAPs. |
13:41:09 | | Quit Lear ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") |
13:41:11 | | Join rep|icant_ [0] (n=rep|ican@adsl-074-183-167-249.sip.bhm.bellsouth.net) |
13:41:12 | nnk | linuxstb: yes, i think so also |
13:41:29 | | Join Lambuntu [0] (n=bleh@wbr-2310.student.iastate.edu) |
13:41:31 | | Join illissius` [0] (n=illissiu@91.83.30.233.pool.invitel.hu) |
13:43:26 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
13:46:57 | | Quit rep|icant (Read error: 110 (Connection timed out)) |
13:50:20 | | Join tarsius [0] (i=a807e5e5@gateway/web/cgi-irc/labb.contactor.se/x-56b5750bb2967c4b) |
13:51:13 | tarsius | hello |
13:53:08 | linuxstb | tarsius: Hi, I've just read your forum post about the C100. |
13:54:09 | tarsius | haha, i saw your tcctool update 4mins after you committed it |
13:55:20 | tarsius | so it's nice to speak with you. i hope this port works out. |
13:55:54 | linuxstb | tarsius: I've just updated tcctool with the value from your USB log - thanks for that. |
13:56:04 | tarsius | my pleasure |
13:57:53 | tarsius | i take it the rest of the USB log is unnecessary now? |
13:58:38 | linuxstb | I would expect tcctool to work now on the c100, but you could keep it just in case it doesn't. |
14:00 |
14:00:03 | tarsius | so i'm actually interested in eventually seeing if the c100's can be hacked to control electronics. |
14:00:42 | linuxstb | What do you mean, use the c100 to control external devices? |
14:01:19 | tarsius | I didn't realize how fast it's clocked... there's an ARM7 in the Gameboy Advance running at 16.8MHz |
14:01:21 | tarsius | yes |
14:03:09 | linuxstb | Are you familiar with ARM assembly? |
14:03:17 | tarsius | yes |
14:04:11 | linuxstb | The first thing I would do is to hunt through your original firmware for an LCD driver. |
14:04:24 | tarsius | okay |
14:06:00 | tarsius | are there any particular "give aways" to look for? any particular patterns apparent when the processor is dealing with LCD? |
14:07:11 | tarsius | also, I was thinking the the "production test" code within the firmware will be quite useful... |
14:07:45 | linuxstb | I'm hoping to commit my code sometime today for my Logik DAX DAB/MP3 player - this includes an LCD driver, so you could search your original firmware for code which is accessing the same bits in the registers. |
14:07:49 | tarsius | ...it initiates at power-on when the user holds down two buttons |
14:08:02 | tarsius | oh good |
14:08:15 | PaulJam | i noticed, that with a recent build the next track info is often not available, and i was wondering if that is going to stay that way or if it is just a temporary issue with the MoB.. |
14:09:24 | karashata | PaulJam: I'm not noticing it, next track info is showing up fine for me |
14:09:31 | karashata | what build are you using? |
14:09:31 | tarsius | and there are a bunch of strings associated with the production test that will be dead giveaways for how the c100 deals with each of its "peripherals" |
14:09:41 | tarsius | and there are a bunch of strings associated with the production test that will be dead giveaways for how the c100 deals with each of its "peripherals" |
14:09:47 | linuxstb | tarsius: Do you know the resolution of your LCD? |
14:10:13 | | Join Arathis2 [0] (n=doerk@p508A6790.dip.t-dialin.net) |
14:10:15 | | Quit Arathis (Read error: 110 (Connection timed out)) |
14:11:08 | | Quit thegeek ("( www.nnscript.de :: NoNameScript 4.1 :: www.regroup-esports.com )") |
14:11:42 | PaulJam | karashata: i use r15331 on a h300. it seems as if the next track info isn't available when the next track isn't already in the buffer. |
14:12:09 | | Part Benoitb ("Kopete 0.12.5 : http://kopete.kde.org") |
14:12:45 | karashata | the next track info isn't available when the next track isn't buffered, is that what you're saying..? |
14:12:48 | linuxstb | tarsius: You may also want to try the ARM disassembler in Rockbox SVN (utils/disassembler/arm/) - it gives similar output to objdump, but with with some useful improvements. |
14:13:59 | | Quit Toxicity999 ("Leaving") |
14:14:04 | tarsius | linuxstb: i don't have the resolution but i'm checking.... and thanks for the tip about the disassembler. i don't have a real dev environment set up yet, I just used devkitARM because i've used it before |
14:14:19 | | Join Toxicity999 [0] (n=bryan@unaffiliated/Toxicity999) |
14:14:20 | PaulJam | karashata: yes. i think before MoB the next track info was stored separately, so it showed up even if the track wasn't already buffered. |
14:15:11 | | Quit Rondom ("Ex-Chat") |
14:15:12 | karashata | not that I'm aware of, the next track needed to at least be partially buffered in order for the track information to be known AFAIK |
14:15:50 | linuxstb | tarsius: There is lots of info in the Rockbox wiki about setting up a development environment. But your first problem will be getting tcctool to work... You can probably get it working in Windows if you're willing to investigate libusb |
14:16:40 | karashata | PaulJam: I haven't noticed any lack of next track information showing up as long as there are tracks in the buffer after the current one, and it may take a few seconds for the next track info to show up whether or not you're using a MoB build |
14:17:19 | karashata | I actually find the next track info shows up faster with the recent builds |
14:17:29 | PaulJam | well, at least with older builds i never noticed missing next track info. |
14:17:51 | tarsius | linuxstb: in your opinion, wouldn't it be easier to install linux so i'm on the same page as everyone else? |
14:18:36 | linuxstb | tarsius: The USB code in tcctool is almost identical to the "e200rpatcher" tool which talks to the e200r in usb-boot mode. There are instructions on getting e200rpatcher working with Windows here - http://www.rockbox.org/twiki/bin/view/Main/SansaE200RInstallation |
14:18:45 | karashata | heh, and as I switch to a WPS theme I have that shows the next track info all the time instead of swapping with the current track, I discover I'm on the last track on the playlist... |
14:19:07 | tarsius | linuxstb: cool, thanks |
14:20:12 | karashata | PaulJam: checking from the beginning of a playlist... the next track info shows up right away for me |
14:20:32 | | Join thegeek [0] (i=thegeek@s220b.studby.ntnu.no) |
14:20:50 | tarsius | linuxstb: well this site says the resolution is 128x64, but i'll try to find something more reliable http://www.bizrate.co.uk/mp3_mediaplayers/sandisk-sansa-c150-2gb-mp3-player−−pid462698027/information.html |
14:20:51 | linuxstb | tarsius: Yes, Linux will probably be easier - compiling Rockbox requires a Unix-like environment (Linux, Mac OS X etc) and on Windows you have the choice of Cygwin, or Linux-in-vmware (or colinux). |
14:21:09 | PaulJam | karashata: well, at the beginning of the playlist it is very likely that the next track is in the buffer |
14:21:20 | linuxstb | tarsius: Is it a colour LCD? |
14:21:28 | tarsius | linuxstb: yes |
14:21:39 | linuxstb | OK, my device is also 128x64, but mono. |
14:22:18 | karashata | PaulJam: kay... skipping ahead seven or eight tracks (making it need to buffer the new tracks) I still get the tag data, so I'm not sure what you mean by it not showing up... |
14:22:25 | | Join hcs [0] (n=agashlin@rockbox/contributor/hcs) |
14:23:20 | Nico_P | karashata, PaulJam: when you skip to the last buffered track, the next track info won't be available until a rebuffer occurs |
14:23:29 | tarsius | linuxstb: this is the device i'm working with: http://www.anythingbutipod.com/archives/2006/03/sandisk-sansa-c100-series-review.php what is yours? |
14:23:32 | PaulJam | karashata: what about the track that plays right before it needs to rebuffer |
14:23:53 | linuxstb | tarsius: http://www.davechapman.f2s.com/logik/ |
14:24:05 | Nico_P | karashata: have lostlogic's changes solved the data aborts? |
14:24:28 | karashata | Nico_P: yes, they aren't an issue anymore |
14:25:16 | tarsius | linuxstb: so what do you think about the prospects of controlling custom electronics with the c100 via a plugin in rockbox? |
14:25:19 | Nico_P | cool :) I'll close the tracker entry then |
14:25:25 | karashata | okay |
14:25:40 | Nico_P | karashata: I suppose recent builds are more enjoyable for you now... |
14:25:52 | karashata | perhaps |
14:26:06 | Nico_P | do you have any other issues? |
14:26:14 | linuxstb | tarsius: It should be possible - does the C150 have any obvious I/O ports you might be able to use? |
14:26:25 | karashata | can't think of anything right now, everything seems smooth enough |
14:27:01 | | Quit nenolod ("<emode\away> omg it's almost meep o'clock, the harmonies of the universe are summoning me to the squirrel tree, bbl :)))))") |
14:27:14 | tarsius | linuxstb: it has an entire "ipod-style" (but sansa specific) propriatary i/o port and a line of accessories... |
14:27:52 | linuxstb | tarsius: Then it would seem very possible. |
14:27:53 | Nico_P | jhMikeS: I don't understand your commit dealing with the queues... what will happen when tue user plugs the USB in? |
14:27:58 | jhMikeS | Nico_P: I noticed even on gigabeat update timing on plugins like oscilloscope tends to run rough now instead of smoothly. Something not yielding enough? |
14:28:32 | jhMikeS | Nico_P: threads are not obligated to response to USB. the audio thread stops them. the queues are private and so don't receive system broadcasts. |
14:28:34 | tarsius | linuxstb: which means to me, if we can get any access to the pins, then it would be simple to sacrifice a cable or accessory just for the connector |
14:28:37 | Nico_P | jhMikeS: is this all the time, or only when buffering? |
14:28:50 | jhMikeS | Nico_P: all the time |
14:29:16 | Nico_P | maybe the buffering thread doesn't yield enough |
14:29:22 | tarsius | linuxstb: also, it might be possible to solder wires directly to the PCB if theres issues with the pins available on the connector |
14:30:16 | Nico_P | jhMikeS: what does the audio thread do on usb plug? |
14:30:41 | | Quit karashata ("Leaving.") |
14:30:48 | jhMikeS | stops playback, waits for voice to be current then force stops voice |
14:31:22 | jhMikeS | I don't think the buffering thread should need a registered queue either. Shouldn't the playback stop stop the buffer thread? |
14:31:40 | Nico_P | jhMikeS: oh sorry I thought the deletions were from audio_thread |
14:32:02 | jhMikeS | :) that wouldn't go over well |
14:32:13 | Nico_P | that's why I was worried :) |
14:32:13 | | Quit ompaul (Read error: 113 (No route to host)) |
14:32:19 | | Join ompaulafk [0] (n=ompaul@gnewsense/friend/ompaul) |
14:32:39 | * | jhMikeS verifies commit message |
14:33:00 | tarsius | linuxstb: so i saw there's a link to a Telechips design doc for the tcc76x (i think) series on the website... was this legally obtained? |
14:33:17 | jhMikeS | "Make voice and codec queues private..." |
14:33:19 | Nico_P | jhMikeS: I didn't read it carefully enough, it's fine |
14:33:25 | jhMikeS | :p |
14:33:32 | | Part pixelma |
14:34:42 | | Quit BigBambi (Remote closed the connection) |
14:34:59 | | Nick ompaulafk is now known as ompaul (n=ompaul@gnewsense/friend/ompaul) |
14:35:12 | Nico_P | jhMikeS: yeah maybe the audio thread could stop the buffering thread |
14:35:59 | Nico_P | where are the codec and voice thread actually stopped? |
14:36:01 | jhMikeS | maybe this stuff was only needed when threading control was less developed? hmmm |
14:36:24 | jhMikeS | audio_stop_playback, voice_stop |
14:37:18 | jhMikeS | SYS_USB_CONNECTED does those from the audio thread |
14:38:44 | Nico_P | hmm so do the threads get removed, or simply suspended? |
14:38:55 | linuxstb | tarsius: I don't know how it was obtained, but someone emailed the link to the rockbox-devel mailing list. Our understanding is that we're not breaking any laws by using the information in it. |
14:39:47 | jhMikeS | Nico_P: they just go wait on their queues |
14:39:49 | tarsius | linuxstb: hmmm... that worries me. i don't think i'll read it. have you looked through it? |
14:40:45 | jhMikeS | no other threads command them (pcmrec does but that stops on connect too) so they can't be started from outside |
14:41:08 | jhMikeS | they also uses inifinte waits when not running |
14:42:10 | | Join PaulJam_ [0] (i=PaulJam_@vpn-3088.gwdg.de) |
14:42:28 | Nico_P | jhMikeS: If the buffering thread was made to behave similarly there could be problems if other threads than the audio thread use it, couldn't there? |
14:42:34 | | Quit PaulJam (Nick collision from services.) |
14:42:46 | jhMikeS | like which? |
14:42:48 | | Nick PaulJam_ is now known as PaulJam (i=PaulJam_@vpn-3088.gwdg.de) |
14:42:57 | Nico_P | I don't know, a plugin |
14:43:09 | jhMikeS | it will use it directly or through playback? |
14:43:36 | Nico_P | directly I expect |
14:44:43 | jhMikeS | so the buffer functions could be added to the plugin api and used. in that case, it probably should if the audio thread won't be in exclusive control of it. |
14:44:49 | tarsius | Uh oh... the sun is rising. I need to get back to my coffin before I crumble into a pile of ashes... |
14:44:56 | tarsius | bye everyone |
14:45:25 | Nico_P | jhMikeS: yeah, I don't think the audio thread can be assumed as being the only user |
14:45:48 | linuxstb | tarsius: Yes. There is nothing in the document stating that the information is confidential, only that the document itself can not be redistributed without Telechip's permission. |
14:46:07 | linuxstb | tarsius: Which country (i.e. timezone) are you in? |
14:46:33 | | Join Rondom [0] (n=Rondom@p57A95776.dip.t-dialin.net) |
14:46:33 | jhMikeS | must be near me by a few hrs if the sun is rising |
14:46:46 | tarsius | tarsius: GMT-5? I think... i'm in Texas, USA, so it's 7:46AM |
14:46:54 | | Quit ender` (" Never say "Oooops" ... always say "Ahhh, interesting..."") |
14:47:17 | nnk | linuxstb: i hear his kind os originating in transilvanya, in some obscurea country in the east of europe |
14:47:38 | nnk | but they can now be found almost allover the world, it seems |
14:48:01 | | Join zardos [0] (i=53e279b4@gateway/web/cgi-irc/labb.contactor.se/x-265504bb03e9da51) |
14:49:15 | tarsius | linuxstb:well i saw the statement on the first page of the TCC doc that said something like "You may not distribute, blah, blah blah, STORE, blah, blah ... this document without the written consent.... blah blah" |
14:49:27 | zardos | hi! do annyone know why i cant compile the simulator in the VMware debian thinki ? I can compile a Normal build but not a simulator :/ |
14:49:43 | tarsius | I figured they were trying to be all-encompassing... |
14:49:52 | | Join ender` [0] (i=krneki@84-255-206-8.static.t-2.net) |
14:51:07 | | Join Robin0800 [0] (n=Robin080@cpc3-brig8-0-0-cust132.brig.cable.ntl.com) |
14:51:47 | tarsius | linuxstb: oh, one more thing! i didn't see the Logik DAX anywhere on the list of devices or newports... are you in the early stages of porting it right now? |
14:52:06 | stripwax | zardos - do you get any kind of error message? |
14:52:12 | linuxstb | tarsius: Yes, I'm in the very early stages - no code is commited to SVN yet. |
14:52:20 | stripwax | if so maybe that can help us figure out why you can't compile a sim |
14:52:50 | linuxstb | tarsius: Someone else (TMM) is working on a port to another Telechips device (iaudio 7), but he's less advanced than me - he's still at the stage of figuring out the LCD. |
14:53:13 | tarsius | oh okay |
14:53:37 | tarsius | good luck. i'll be talking with you soon, i'm sure |
14:53:40 | tarsius | bye |
14:54:06 | | Part tarsius |
14:54:08 | zardos | stripwax ok, but its stranke caus it is an untuthced build :/ |
14:54:26 | stripwax | zardos - i can't understand that? |
14:55:35 | stripwax | linuxstb - flashsplit bootloader-video.bin returns almost immediately but doesn't seem to do anything nor print anything. is that expected? |
14:55:45 | zardos | :D Strange caus it is an untouched buid* |
14:56:26 | stripwax | zardos - that doesn't help. what does "can't compile" mean? have you tried and failed? if so, what failed and what was the error? |
14:57:01 | zardos | am doing a recompile now, u will get the errors soon |
14:57:18 | linuxstb | stripwax: What is the "bootloader-video.bin" file? |
14:57:59 | stripwax | linuxstb - ah, not the flash bin obviously, my bad. sorry |
14:58:10 | * | stripwax tries on the right file this time |
14:59:03 | | Join ilgufo [0] (n=matteo@host113-184-dynamic.4-87-r.retail.telecomitalia.it) |
14:59:54 | | Join miepchen^schlaf [0] (n=hihi@p54BF52EC.dip.t-dialin.net) |
15:00 |
15:00:27 | linuxstb | stripwax: Working? |
15:00:37 | | Nick Arathis2 is now known as Arathis (n=doerk@p508A6790.dip.t-dialin.net) |
15:01:33 | zardos | anny who, i'w, modefyed ereader a bit, added some code and made it a viewer, so if some one is interested an a TTS engin for rockbox that reads the textfles u "open with" give me a pm :) |
15:02:00 | linuxstb | ereader is a TTS application? |
15:02:07 | stripwax | linuxstb - perfect - yep, thanks |
15:02:50 | zardos | yes |
15:03:21 | linuxstb | zardos: Do you have a link to the original source code? |
15:05:51 | zardos | sorry, it name is espeak and a versone the only reads test.txt is up on rockbox |
15:07:13 | linuxstb | OK, so you've just extended that plugin to be a viewer? |
15:08:40 | zardos | for now, but am working on it right now, to add some neat functions |
15:09:12 | zardos | its better id it reads all files and not just text.txt ;) |
15:09:21 | zardos | if* |
15:10:17 | | Join mrkiko [0] (n=mrkiko@77.240.229.242) |
15:10:37 | * | mrkiko is participating to the LINUX DAY! |
15:11:43 | linuxstb | zardos: You're aware of the licensing problem that may well prevent it being used in Rockbox? |
15:17:20 | *** | Saving seen data "./dancer.seen" |
15:20:15 | zardos | yes, thats why i only do it for myself, but if some one here is interested in it i dont see the problem of sharing, but mayby all people here know how to code :D |
15:20:49 | | Part przemhb |
15:22:35 | stripwax | if it's in the tracker is that a licensing problem? |
15:22:57 | markun | zardos: I'm interested in it |
15:23:20 | markun | do you plan to add 'seeking' support? |
15:25:50 | markun | linuxstb: I'm not starting to wonder how the LGPL API file is supposed to work.. |
15:26:42 | stripwax | Nico_P - was just trying the sim now that mob is in, and it seems that files are opened multiple times (e.g. i select a track on that album, and the diag shows that the tracks of the album are opened four or five times each). is that expected? |
15:26:43 | markun | wouldn't the file become GPL when it's linked to the rest of rockbox? |
15:27:04 | stripwax | and also continually while playing back |
15:27:04 | | Quit hcs ("Leaving.") |
15:27:43 | Nico_P | stripwax: opening multiple times is expected although it should be reduced... the loop during playback is a bug |
15:28:18 | stripwax | ok. on device does that bug keep the disk spinning? |
15:28:37 | Nico_P | no, I'm pretty sure it's specific to the sim |
15:28:43 | stripwax | cool |
15:29:05 | Nico_P | (because on the sim, ata_disk_is_active is always true) |
15:29:28 | stripwax | but if the file's buffered it shouldn't need to do anything |
15:29:35 | jhMikeS | Nico_P: I've had something come up on gigabeat that may be related. The disk would never spin down. |
15:29:41 | Nico_P | oh? |
15:29:45 | | Join Arathis2 [0] (n=doerk@p508A6856.dip.t-dialin.net) |
15:29:59 | jhMikeS | I'll see if I can trigger it the same way. |
15:30:28 | * | Nico_P has been reviewing lostlogic's big commit and it looks pretty solid |
15:30:42 | puzzles | looks like i'll buy an ipod video and rockbox it |
15:30:57 | markun | puzzles: why the ipod video? |
15:31:05 | puzzles | capacity |
15:31:26 | puzzles | bang for buck, too |
15:31:37 | markun | how much? |
15:31:42 | puzzles | quality for quid? :) |
15:31:47 | stripwax | :) |
15:32:00 | puzzles | found a refurb 80GB for $220 USD |
15:32:01 | markun | puzzles: price and space |
15:32:12 | markun | sounds good |
15:32:35 | markun | as you would pay the same for 2 Gigabeat F40's |
15:32:35 | puzzles | iriver and iaudio run up to 40GB :( |
15:32:46 | puzzles | hehe |
15:32:50 | jhMikeS | hmmm...can't trigger it at will but if it happened once it's still a bug. that's a race condition type behavior imo. |
15:33:26 | markun | puzzles: the iaudio X5 had a 60GB version too, right? |
15:33:31 | puzzles | i would prefer an ipod classic 160gb, but my poorness and the fact that it's unsupported by anything (and nobody's working on that) means i think the video is a better choice |
15:33:39 | markun | (as do the Gigabeat F and X) |
15:33:42 | puzzles | markun: if it did i didn't see it |
15:34:09 | markun | puzzles: http://www.cowonamerica.com/products/iaudio/x5/info_features.html |
15:34:30 | puzzles | too small for me anyway :) |
15:34:57 | markun | puzzles: if we ever figure out how to reduce the power consumtion, the ipod video becomes a great player |
15:35:13 | puzzles | dan@bean:~$ du -chs /media/music/ |
15:35:13 | puzzles | 81G /media/music/ |
15:35:21 | puzzles | yeah that would be nice |
15:35:47 | markun | and maybe even figure out video decoding with the Broadcom |
15:35:59 | puzzles | do you guys pretty much know what's causing the high power consumption? |
15:36:11 | markun | maybe amiconn has some ideas? |
15:36:15 | puzzles | i saw that cpu throttling wasn't quite finished and the codecs aren't optimized |
15:36:37 | markun | well, that's no problem on the other ARM based players |
15:37:07 | stripwax | ata power? |
15:37:12 | puzzles | how significant is the power consumption anyway? |
15:37:27 | J3TC- | Hopefully the new commits in the svn would help the album art/bmp resize work again |
15:37:33 | | Quit Rondom ("Ex-Chat") |
15:37:51 | stripwax | anyone working on rewriting the albumart patch for mob? :) |
15:39:54 | J3TC- | Lol...well, hopefully it doesn't have to be a patch and be natively supported ;) |
15:40:26 | jhMikeS | Nico_P: Don't know if anyone said anything, but trying to do rapid skipping while buffering seems to make playback abort. |
15:40:56 | Nico_P | jhMikeS: data abort or just stall? |
15:41:21 | Nico_P | stripwax: I'll enventually do it unless somone comes up with a satisfactory patch |
15:41:25 | stripwax | linuxstb - what's the distinction between diagmode.bin and diagmode.ipod? |
15:41:29 | jhMikeS | it just stops |
15:41:32 | Nico_P | hmm |
15:41:33 | | Join BigBambi [0] (n=alex@rockbox/staff/BigBambi) |
15:42:15 | jhMikeS | some magenta on the WPS then it quits. you need to just keep doing forward/backward rapidly (yes fw too) |
15:42:19 | stripwax | is the .bin just the raw and the .ipod has some headers wrapped around? |
15:42:28 | Robin0800 | jhMikeS seems latest commits stop crash but playback aborts and the ipod goes to the file menue screen |
15:42:39 | jhMikeS | though I'll say playback isn't trashed |
15:42:41 | | Join pepie34 [0] (n=pepie34@cop60-1-82-240-26-92.fbx.proxad.net) |
15:42:47 | | Quit mrkiko (Read error: 104 (Connection reset by peer)) |
15:43:03 | Nico_P | jhMikeS: what target. |
15:43:04 | Nico_P | ? |
15:43:07 | jhMikeS | Gigabeat |
15:43:13 | Nico_P | ok |
15:44:19 | Nico_P | jhMikeS: what kind of tracks too, mp3? |
15:44:19 | jhMikeS | I happen to be using that one alot right now and it's easy to put in skip requests really quickly. I don't think this would be specific to target. |
15:44:27 | jhMikeS | anything I tried |
15:44:32 | Nico_P | ok I'll try |
15:45:21 | jhMikeS | If WPS gets stuck becuase it has to buffer, keep pounding on skip |
15:47:04 | | Quit Arathis (Read error: 110 (Connection timed out)) |
15:47:44 | markun | linuxstb: should the clix2 also work with tcctool? |
15:47:58 | jhMikeS | It occurs to me you could embed kernel objects in place in the buffer in the handles. Just a weird thought for fine-grain locks. |
15:48:03 | stripwax | linuxstb - another q (sorry) - do you know the address at which execution starts for these four flash images? |
15:49:56 | | Nick Bagder_ is now known as Bagder (n=daniel@1-1-5-26a.hud.sth.bostream.se) |
15:51:43 | Nico_P | jhMikeS: like having a mutex in each handle? |
15:52:11 | jhMikeS | You could. If a handle is ready for release, nothing should be waiting there using it right? |
15:53:08 | Nico_P | in the current situation? |
15:53:46 | jhMikeS | yeah, if something can use it after it's been freed, then that's a bug |
15:54:19 | Nico_P | indeed. are mutexes cheap? |
15:55:12 | jhMikeS | They are if not already locked (for cycles). Not large in size. I'm think about a way to keep each handle protected individually instead of locking the entire buffer system at once. |
15:56:17 | Nico_P | jhMikeS: but it means we can't buffer a handle which is being read, doesn't it? |
15:56:22 | jhMikeS | The scheduler does that sort of thing already so processors don't interfere unless they must sync on some shared resource |
15:56:54 | | Join darkless [0] (n=darkless@x1-6-00-1a-92-ea-71-14.k201.webspeed.dk) |
15:57:04 | jhMikeS | not sure why that would be a problem if that's a valid state. |
15:58:38 | Nico_P | I'm not sure I see how the mutex would be used... lock it when it's read and attempt to lock it to close it? |
15:58:40 | | Join Zagor [0] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) |
15:58:49 | Nico_P | to close the handle, that is |
16:00 |
16:00:50 | jhMikeS | Open/close should be global lock and access to the handle itself local? Careful design for simultaneous read/write. |
16:01:51 | Nico_P | I'm not following you... |
16:01:59 | jhMikeS | I'm just thinking theres some semantic difference between accessing the data and accessing the handle itself. I still haven't been into this too deeply because of my attention to other code. |
16:02:48 | Nico_P | oh now I see... well I think reading and accessing the handle are quite the same |
16:03:17 | Nico_P | all those things are done by the user thread, whereas writing the handl data is done by the buffering thread |
16:03:18 | jhMikeS | hmmm...I'm thinking of them are sort of meta-metadata |
16:03:32 | stripwax | In the ipod video diag mode firmware there's a reference to "HDD on off test", which doesn't appear to be an accessible test on the device. wonder what it does, |
16:04:23 | jhMikeS | ...as a distinct object giving acces to buffered data |
16:05:20 | Nico_P | jhMikeS: yes, but what kind of access would they regulate, ie when would they be locked and unlocked? |
16:05:22 | jhMikeS | btw, can't the path be the last member so that it's optional? |
16:06:06 | Nico_P | jhMikeS: hmm nice idea |
16:06:21 | jhMikeS | char path []; :) |
16:07:07 | Nico_P | then we'd need pathlen, wouldn't we? |
16:07:50 | jhMikeS | sure, but that's nothing. use a union{} with something else that is only for non-paths? |
16:08:41 | | Quit jhMikeS (Nick collision from services.) |
16:08:47 | | Join jhMikeS [0] (n=jethead7@rockbox/developer/jhMikeS) |
16:10:30 | | Join ToHellWithGA [0] (n=ryan@d16-124.rt2-bras.clm.centurytel.net) |
16:10:32 | | Quit JdGordon ("Konversation terminated!") |
16:12:31 | | Quit jhMikeS (Nick collision from services.) |
16:12:31 | | Quit pepie34 ("Ex-Chat") |
16:12:54 | | Join jhMikeS [0] (n=jethead7@rockbox/developer/jhMikeS) |
16:14:44 | J3TC- | If I do svn checkout svn://svn.rockbox.org/rockbox/trunk -r {2007-10-25} rockbox...is the MOB already implemented then? |
16:14:57 | jhMikeS | Nico_P: seems to be quite a bit of file-only stuff there. I suppose the type member could tell what sort of data stucture should follow. (just thinking about squeezing every byte with little complication) |
16:15:18 | Nico_P | J3TC-: better do checkout a particular revision... but are you having that much problems? |
16:15:36 | J3TC- | Well, I'd like to have album art >_> |
16:15:40 | Nico_P | ah |
16:16:20 | J3TC- | How do you get the particular revision? |
16:16:44 | Nico_P | J3TC-: svn co <url> -r <rev> |
16:17:26 | J3TC- | Thanks :3 |
16:17:28 | Nico_P | jhMikeS: you mean what kind of data struct will be after the memory handle, eg a struct mp3entry |
16:17:31 | Nico_P | ? |
16:18:13 | | Join rep|icant [0] (n=rep|ican@adsl-074-183-167-249.sip.bhm.bellsouth.net) |
16:18:27 | jhMikeS | sort of, if it's not a file type, then only the min is allocated (no file data members) |
16:19:09 | Nico_P | oh, so within the struct memory_handle? |
16:19:33 | Nico_P | have it laid out differently depending on the type? |
16:19:49 | | Join Rondom [0] (n=Rondom@p57A95776.dip.t-dialin.net) |
16:20:01 | jhMikeS | struct memory_handle could contain only things every handle must have. if the type hold file data then it should be a struct memory_handle_file. |
16:21:14 | lostlogic | *yawn* |
16:21:17 | jhMikeS | both structures could have the same initial members so only a typecast is needed. and of couse for files you can store just enough string space for the actual path (+padding). |
16:21:22 | lostlogic | jhMikeS: do you sleep? |
16:21:33 | jhMikeS | I did...now I'm up again :) |
16:22:40 | lostlogic | :) |
16:22:41 | jhMikeS | it could be struct memory_file_handle { struct memory_handle hdr; .... other stuff }; no real cost to it all |
16:23:49 | Nico_P | hmm yeah quite a good idea... probably easier to manage than just having a pointer to the path too |
16:24:02 | lostlogic | Nico_P: well it only took me 10 forking hours but I nailed tha main bug to the wall −− any idea about why the disk would refuse to spin down after buffering? |
16:24:15 | | Quit rep|icant_ (Read error: 110 (Connection timed out)) |
16:24:26 | Nico_P | lostlogic: I'm looking at that now... or something related (in the sim) |
16:24:46 | Nico_P | lostlogic: I read your diff and it looks good |
16:25:43 | jhMikeS | Nico_P: you mean store MAX_PATH always? Doesn't make sense to me. Actually a size member for the struct would make sense. The path would be NULL-terminated still. |
16:26:05 | lostlogic | Nico_P: :) the only thing that I was thinking might be the issue for the disk spinning is that the ata_sleep on exit from fill_buffer is conditional so maybe it doesn't always get called when it should. |
16:26:29 | Nico_P | jhMikeS: yeah I was thinking that... for a file, would the waste be that big? |
16:26:50 | | Quit Toxicity999 ("Leaving") |
16:27:00 | Nico_P | lostlogic: if it's not called then the disk will still eventually spin down. there must be another problem |
16:27:02 | jhMikeS | We do alot of files that don't use even close to MAX_PATH, no? |
16:27:11 | lostlogic | Nico_P: gotcha. |
16:27:21 | | Quit lazka ("I'm off now") |
16:27:29 | Nico_P | lostlogic: do you know how to repro the disk spinning forever issue? |
16:27:33 | jhMikeS | lostlogic: when it happened on gigabeat, the disk led was also stuck on |
16:27:40 | Nico_P | jhMikeS: yeah maybe but maxpath isn't that big |
16:27:47 | lostlogic | jhMikeS: oh yeah, same here. |
16:28:00 | lostlogic | so it's not just spinning, it thinks it's reading something. |
16:28:35 | Nico_P | lostlogic: I think I have it basically reproduced on the sim but it might not be the same issue. here the low buffer callbacks are called on a loop |
16:28:45 | jhMikeS | Nico_P: code for skipping a variable size should be smaller than one handle. |
16:28:56 | Nico_P | which means audio_fill_file_buffer is too, which causes constant disk activity |
16:29:30 | lostlogic | Nico_P: that's actually what it 'feels' like is happening, so I think you've likely found the proximate cause. |
16:29:39 | Nico_P | jhMikeS: ok, I'll do it :) after I fix what i'm on... I'll also investigate per-handle mutexes |
16:29:43 | | Quit PaulJam (".") |
16:30:05 | Nico_P | lostlogic: I have a reliable way of reproducing, so I hope to fix it soon |
16:30:18 | lostlogic | cool. |
16:30:33 | jhMikeS | Nico_P: the local mutexes seem radical though. that's just me being way-out-there with ideas atm. :) |
16:31:34 | | Quit ToHellWithGA ("You know you'll miss me a lot.") |
16:32:21 | | Join gromit` [0] (n=gromit@ras75-5-82-234-244-69.fbx.proxad.net) |
16:32:46 | | Quit ilgufo ("So Long, and Thanks For All the Fish - http://gufo.wordpress.com") |
16:32:56 | * | jhMikeS wonders about magic type values the denote discarded handles. perhaps the high-3 bytes of the type should me a majic number too |
16:33:05 | jhMikeS | majick :P |
16:33:06 | | Quit gromit` (Client Quit) |
16:33:28 | | Join gromit` [0] (n=gromit@ras75-5-82-234-244-69.fbx.proxad.net) |
16:35:47 | jhMikeS | 0xF0CK0FFF <= invalid handle magic? |
16:35:52 | Nico_P | :p |
16:36:03 | lostlogic | what's wrong with DEADBEEF :-P |
16:36:23 | Nico_P | especlially as K isn't hex :p |
16:36:43 | lostlogic | I notice things not :-P |
16:36:53 | lostlogic | (and they trust me to coode!) |
16:37:31 | jhMikeS | if could K doesn't work, but I'm just awakening |
16:37:37 | jhMikeS | course |
16:37:57 | puzzles | 0xF0CC0FF |
16:38:29 | jhMikeS | aha...yes...one more 0xF0CC0FFF :) |
16:38:37 | | Join mirak [0] (n=mirak@m94.net81-66-75.noos.fr) |
16:39:47 | puzzles | ah, oops :) |
16:40:10 | puzzles | 0xB00BCAFE |
16:40:55 | | Join ilgufo [0] (n=matteo@host113-184-dynamic.4-87-r.retail.telecomitalia.it) |
16:41:41 | puzzles | ok, i ordered an ipod video, maybe i can get hacking on that power consumption problem :) |
16:42:28 | jhMikeS | 0xDEADDEAC <== Portal Player can generate this (dead duck) |
16:42:54 | puzzles | how about a dead dac? |
16:43:27 | jhMikeS | hope not! |
16:43:33 | preglow | 0x12BABE |
16:43:39 | preglow | i get 0xdeadbeee all the time |
16:44:23 | jhMikeS | I've seen 0xdeaddeac once only...and with current SVN? oh, right nano. :p |
16:45:06 | * | preglow vanishes |
16:45:07 | jhMikeS | the threading code uses 0x8a905617 |
16:50:18 | jhMikeS | 0x1215705 <= try that one :) |
16:51:21 | | Join spiorf [0] (n=spiorf@host212-228-dynamic.11-79-r.retail.telecomitalia.it) |
16:52:34 | stripwax | I guess another ipod 5g power issue is that we don't power off the wheel when the hold switch is on (right?) |
16:53:15 | | Quit davina ("xchat on Ubuntu 7.04") |
16:53:54 | * | jhMikeS though the only real power sucking wheel was the 1g opto-mechanical one |
16:55:11 | | Join midgey [0] (n=tjross@westquad-188-65.reshall.umich.edu) |
16:55:40 | | Quit midgey (Client Quit) |
16:56:21 | stripwax | ah, could be. though I thought I saw a patch/commit for something on 2g/3g a bit ago |
16:57:01 | Soap | Llorean: Did you catch this quote from 14 hours ago? "<pongg> ok. i thought that the unofficial builds are used like for "beta testing" and ones theyre ok you get the patches to the official one" |
16:57:28 | Llorean | Soap: I *think* I responded that it's actually better to test one patch at a time. |
16:57:45 | Llorean | I know I thought it, but I might've been busy and ended up not typing it. |
16:57:52 | Soap | It makes me think that perhaps we should maybe make a more explicit disclaimer for the Unsupported Builds forum, explaining not just the rules, but also the /intent/ of the board? |
16:58:37 | Llorean | I suspect that users of the builds aren't likely to read the rules anyway, but I don't see any harm in clarifying things |
16:59:03 | Llorean | If you aren't posting a new build, the posting guidelines there won't matter too much to you. |
17:00 |
17:00:21 | | Join PaulJam [0] (i=PaulJam_@vpn-3012.gwdg.de) |
17:00:25 | stripwax | #define DEV_OPTO 0x00010000 #define DEV_PIEZO 0x00010000 <−− is that a typo in firmware/export/pp5020.h (they're not both on the same dev enable line are they?) |
17:00:48 | Soap | Llorean: Oh - you said exactly that - and I wasn't trying to critique your response to him at all. You nailed it. I was just using that quote as an example of how perhaps people are coming to the forums, reading little of the documentation, and going straight to the "candy" builds (perhaps on the recomendation of others) and failing to understand the process. |
17:01:28 | Soap | You know I'm a strong proponent of _not_ hand-holding. You know I agree with you 100% that the documentation _is_ there, and you can lead a horse to water but you can't make it drink. |
17:02:51 | stripwax | guess neither are used so doesn't matter |
17:03:01 | Soap | I guess that quote triggered a thought in me that perhaps there is a (sizeable?) percentage of the new-user population who comes in, not through the front door, but through the "Unsupported Builds" forum, and perhaps we should put up a specific "Welcome Sign" @ that side door to address the unique "needs" of that population. |
17:05:25 | Soap | from the main page of forums.rockbox.org, the description for the Unsupported Builds forum is great. Except, perhaps, the very first line "For 'experimental' builds." |
17:05:51 | | Quit Arathis2 ("Bye, bye") |
17:06:50 | | Join Klevi [0] (n=Owner@ool-435682a7.dyn.optonline.net) |
17:07:06 | | Join midgey [0] (n=tjross@westquad-188-65.reshall.umich.edu) |
17:07:08 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
17:07:14 | jhMikeS | stripwax: perhaps a model-dependent thing? |
17:07:15 | | Join Rob2222 [0] (n=Miranda@p54B16176.dip.t-dialin.net) |
17:07:57 | Klevi | Hi again, just dropping a word to say I haven't forgotten you guys =) I'm just waiting for my new sansa to come in the mail before i go messing with something i can't use currently lol. |
17:08:19 | Soap | For aren't these really individual's "hobby" builds? Has a single patch ever worked its way from scratch, through the tracker, through an unsupported build, and into trunk? Has useful work been done through the forum? Or is it mearly a back corner where people tinker and play while waiting for the hard work to be done elsewhere? |
17:08:57 | | Nick parafin is now known as parafin|away (i=parafin@parafin.dialup.corbina.ru) |
17:09:09 | | Quit Klevi (Client Quit) |
17:10:08 | Llorean | Soap: A second sticky containing this: http://pastebin.ca/751561 ? |
17:11:58 | | Quit JETC- (".•«UPP»•.") |
17:12:33 | Soap | Llorean: that "sticky" is very well worded, covers the subject perfectly (esp. line 9), and probably will get ignored. ;) Maybe part of me just wishes there was a big enough clue stick. |
17:13:06 | | Join petur [0] (n=petur@d54C6FBFB.access.telenet.be) |
17:13:20 | krazykit | maybe if the stickies were in giant rainbow text wrapped in <blink> tags |
17:13:25 | | Join TotallyInfected [0] (n=ebola@pool-151-197-169-182.phil.east.verizon.net) |
17:13:37 | Llorean | Soap: There's not much more I can do, sadly. What should I replace the word "experimental" with? |
17:14:03 | Soap | from the main forums page there is a visible description for each of the sub boards, but when you are on the sub board index page you can't see said descriptive text. Is there a way to change that? |
17:14:22 | Llorean | No built in way that I've seen |
17:14:48 | Soap | Llorean: I know. :( Do you think as well that the word "experimental" might have been what lead pongg astray? |
17:15:17 | Llorean | It's possible. |
17:15:19 | | Join linuxstb_ [0] (n=chatzill@i-83-67-212-170.freedom2surf.net) |
17:15:37 | Llorean | But I can't really think of a better way to put it without reiterating "Unsupported" |
17:17:05 | linuxstb_ | stripwax: I'm around now - do you still have questions? |
17:17:23 | *** | Saving seen data "./dancer.seen" |
17:18:22 | stripwax | linuxstb - I do .. do you happen to know where execution starts in these images extracted from the flash? |
17:18:47 | | Join kkurbjun [0] (n=kkurbjun@c-67-166-49-171.hsd1.co.comcast.net) |
17:18:50 | Soap | They are amateur builds, play builds, hobby builds, fun builds, splinter, distraction, impatient, learning (for the patch workers), candy builds. I don't think they are 'experimental' builds for anyone expect, perhaps, the actual builder. Maybe it is just the culture, not the environment, but...my brain isn't working as well as I wish. |
17:19:50 | linuxstb_ | stripwax: IIRC, they're copied to SDRAM, which is initially mapped to 0x10000000 |
17:20:15 | Soap | To me - and maybe I'm crazy - (ok, scratch the 'maybe') "experimental" implies (to me at least) some sort of controled testing and developement, much as pongg appears to have assumed. |
17:20:57 | Soap | maybe Soap is making a mountain out of a molehill, Llorean. :( |
17:21:29 | stripwax | linuxstb - hm, the start of the image doesn't look like executable code.. Is there a wiki page for the retailos boot process? |
17:21:32 | Llorean | I think you're right, people can draw implications from "experimental" |
17:21:35 | Nico_P | lostlogic: I think I've found an elegant solution |
17:22:24 | Llorean | Soap: Change "for experimental" to "for modified and officially unsupportable"? |
17:23:08 | Soap | that is a fish-slap across the face of a line. ;) |
17:23:10 | linuxstb_ | stripwax: Which file are you looking at? |
17:23:15 | jhMikeS | Nico_P: you found the disk spin/forever metadata cause? |
17:23:25 | stripwax | linuxstb - diagmode.bin |
17:23:27 | Soap | and makes the primary issue with them #1, IMHO. |
17:24:00 | Nico_P | jhMikeS: yes... it was a loop caused by the fact the low buffer callback is registrered in the function that gets called by it |
17:24:17 | linuxstb_ | stripwax: It looks fine to me - are you seeing something like this? http://www.pastebin.ca/751569 |
17:24:33 | Nico_P | and another probably related problem of flooding the audio queue with fill buffer messages |
17:24:40 | Nico_P | in a loop too |
17:25:12 | lostlogic | Nico_P: cool |
17:25:17 | lostlogic | (that you've found it) |
17:25:32 | | Quit BigBambi (Remote closed the connection) |
17:25:55 | linuxstb_ | markun: Yes, if someone can determine the appropriate message (like someone did for the C100 - see that New Port thread), then tcctool should work on any TCC77x or TCC7801 device. |
17:26:10 | lostlogic | Nico_P: I think the old system had some methods of throttling messages getting dumped on the queue so that a message to fill the buffer wouldn't interrupt an ongoing buffer fill, does the new one? |
17:26:19 | Nico_P | lostlogic: now I regitser the low buffer callback in audio_check_new_track |
17:26:23 | linuxstb_ | markun: (assuming there is a way to enter usb boot mode - most devices seem to have a keypress mapped to that) |
17:26:30 | stripwax | linuxstb - ah, I am now. I guess I'd overwritten disasm.txt with the code from logo.bin earlier. sorry (again) |
17:26:33 | lostlogic | *nod* |
17:26:56 | Nico_P | lostlogic: no, and that's a problem |
17:27:23 | Llorean | Soap: Too much then, or just right? I can leave out the "officially unsupportable" bit |
17:27:32 | lostlogic | gotcha −− well I'm not sure how much I'll be around today but I'll look at it eventually if you haven't |
17:27:56 | linuxstb_ | stripwax: np. The first 8 instructions are the exception vectors. The first is the rest vector, and hence the entry point into the firmware. It's likely that the code remaps RAM from 0x10000000 to 0x0 at some point early in the initialisation. |
17:28:04 | Nico_P | lostlogic: I don't rememver seeing anything like that though... are you sure it was still there? |
17:28:07 | | Join JETC- [0] (n=jetc123@pool-72-76-179-145.nwrknj.east.verizon.net) |
17:28:19 | stripwax | linuxstb - that would make sense |
17:28:22 | stripwax | cheers |
17:28:36 | lostlogic | Nico_P: not positive, I also can't remember if it was on the enqueue or the dequeue side of the queue that it was prevented |
17:30:23 | * | jhMikeS likes elaborate while() loops like that :) |
17:31:07 | | Join MethoS- [0] (n=clemens@pD955E1FD.dip.t-dialin.net) |
17:31:33 | Soap | Llorean: on your last question perhaps some more feedback from others? I'm not trying to speak as if I have all the answers. I'll just sit back now and enjoy the lost logic, Nico P, linux stb, amicon, preeglow, jhmike S show. I love their discussions. (trying not to highlight any of them). |
17:32:12 | jhMikeS | lol |
17:33:24 | jhMikeS | IRC is just performance art |
17:33:35 | | Join BigBambi [0] (n=alex@rockbox/staff/BigBambi) |
17:33:57 | Soap | I mean it's great. It's like when your parents read you a bedtime story. You try to follow along in the text of the book, looking over their shoulder and learning to decipher all those letters as they tell a great story. |
17:35:18 | Nico_P | Soap: I feel like that too for some discussions :p |
17:35:41 | Llorean | That's what I've been doing the last couple days too. |
17:36:00 | Nico_P | lostlogic: I committed the fix |
17:36:05 | Nico_P | or "fix" |
17:37:21 | Nico_P | oops my commit message has a hole |
17:38:03 | Llorean | Alright guys, so I'm going on a long drive later today. My audiobook player is using a pre-MoB build because I was testing on a different one. |
17:38:21 | Llorean | Safe to upgrade at this point, or should I be playing it safe for this mission-critical deployment? |
17:39:00 | Nico_P | Llorean: do you have time to make sure thee is now breakage for your particular usage pattern? |
17:39:17 | Nico_P | s/now/no |
17:39:35 | Llorean | Nico_P: There wasn't any before, for *my* usage pattern. Heh. |
17:39:50 | Llorean | I was apparently the only person not getting any data aborts from that first MoB commit. |
17:40:05 | Nico_P | I wasn't either... |
17:40:35 | Nico_P | I must subconscioulsy know what will break my code and avoid doing it |
17:41:02 | jhMikeS | I never got data aborts, just wierd happenings |
17:41:05 | | Quit Zagor ("Client exiting") |
17:41:05 | | Join Toxicity999 [0] (n=bryan@unaffiliated/Toxicity999) |
17:42:03 | jhMikeS | But I've used only a Gigabeat over the last week or so and no runs on any other targets yet |
17:42:24 | * | Nico_P got his hands on his H300 today |
17:43:03 | | Quit ilgufo ("So Long, and Thanks For All the Fish - http://gufo.wordpress.com") |
17:45:35 | | Quit PaulJam (Read error: 104 (Connection reset by peer)) |
17:51:58 | Nico_P | jhMikeS: are you able to make sure the forever spin issue isn't happening anymore? |
17:52:01 | Llorean | Looking at the new buffer debug screen, I'm noticing it quite often doesn't even fill half the buffer... |
17:52:33 | Llorean | In fact it seems to only buffer at most 3 tracks. |
17:54:21 | kkurbjun | hey guys, I think I'm seeing a stack overflow on the mrobe, if I change list.c and remove char entry_buffer[MAX_PATH]; from line 315 and pull it out of the gui_list_draw_smart function (put it on line 171) I start seeing all the menu's correct, once I do that I can see that the main stack is only 57% used though so I'm wondering if it's reasonable to expect that having that buffer in the stack could consume that much extra stack. |
17:55:03 | Nico_P | Llorean: how big are the tracks? are you skipping during the initial buffering phase, |
17:55:04 | Nico_P | ? |
17:55:08 | kkurbjun | Also, does anyone see any problems with moving that buffer outside of the function |
17:56:00 | Llorean | Nico_P: Varying sizes from 2 mb to maybe 24 mb, MP3 and FLAC. I'll press "down" until the buffer empties, then release and watch, and it'll most frequently buffer 3 tracks, six handles, filling approximately 1/3 to 2/3 of the buffer but leaving a very large portion open |
17:56:52 | kkurbjun | another question is does the stack usage reflect only the current usage, or does it show the max usage? |
17:56:53 | Nico_P | Llorean: even for the "alloc" value? |
17:56:59 | Llorean | Nico_P: Yes |
17:57:32 | Nico_P | are you sure you're not reaching the end of the playlist? |
17:57:49 | Llorean | Quite |
17:57:54 | Llorean | There are a few thousand entries left in it. :) |
17:58:05 | Nico_P | oh ok... sorry for asking but I had to make sure |
17:59:12 | Llorean | Hmmm |
17:59:39 | Llorean | Okay, to reproduce, wait until all buffering stops, and then press whatever is next track on the player you have at hand, in the buffer debug screen, until it says Tracks and Handles are 0 |
17:59:41 | Llorean | Then release |
17:59:50 | Llorean | As far as I can see, in that situation it buffers only 3 tracks |
18:00 |
18:00:06 | Llorean | Meanwhile, if you let a track end normally and trigger a rebuffer, it buffers fully. |
18:00:57 | Nico_P | oh yes I only got two tracks buffered |
18:01:19 | Llorean | I'd almost assume this was intentional behaviour: If a user skips a lot, don't fill the whole buffer until they demonstrate they're done skipping. :) |
18:01:36 | Nico_P | haha unfortunately I don't think the code is that smart |
18:02:01 | linuxstb_ | kkurbjun: It shows the max usage - i.e. how much of the stack is still filled with 0xdeadbeef |
18:02:16 | stripwax | Llorean - that's a great idea :) |
18:02:40 | Nico_P | Llorean: It may be a side effect of my latest commit. if you interrupt the adding tracks loop, it might not restart |
18:02:49 | Llorean | Nico_P: That could very well be it |
18:02:58 | kkurbjun | linuxstb, I wouldn't expect that buffer to consume that much extra stack then.. |
18:03:03 | lostlogic | Nico_P: I see how that would loop −− might want to use queue_peek to see if the next message on the queue is already a fill and if not still send it and maybe also use peek to consume extra messages on the queue... I think we might have had some kind of queue coallescing to prevent many duplicate messages from queuing up −− do we still haev that? |
18:03:11 | Llorean | Since in most cases, when I'm down to a portion of one track, it's already attempting to add tracks when I skip again from 1 track to 0 tracks in the buffer |
18:03:14 | | Quit atsea-32 (Remote closed the connection) |
18:03:23 | Nico_P | lostlogic: we don't have queue_peeek yet I don't think |
18:03:33 | Nico_P | but yeah that's a way to do it |
18:03:33 | kkurbjun | I don't see any recursive calls on that function |
18:03:49 | lostlogic | I thought I wrote it... or maybe I did and then used a different method *sigh* senile. |
18:04:06 | linuxstb_ | kkurbjun: No, it doesn't make sense to me either... |
18:04:09 | jhMikeS | Nico_P: you committed? |
18:04:13 | Nico_P | lostlogic: jhMikeS gave one to me a few days back but I didn't use it |
18:04:27 | Nico_P | jhMikeS: yes, and could we have your queue_peek again? |
18:04:43 | jhMikeS | just the basic one? the sim needs the irq stuff now |
18:05:18 | * | jhMikeS retypes it really quick |
18:05:44 | kkurbjun | :), maybe the iram that I'm using for the stack isn't as large as I thought |
18:06:01 | | Quit midgey () |
18:06:29 | | Join midgey [0] (n=tjross@westquad-188-65.reshall.umich.edu) |
18:08:07 | kkurbjun | linuxstb, do you know how stack overflows are detected? |
18:08:36 | jhMikeS | http://www.pastebin.ca/751636 |
18:08:38 | linuxstb_ | kkurbjun: No, grep in firmware/ for "deadbeef" |
18:09:00 | | Quit MethoS- (Remote closed the connection) |
18:10:28 | | Join df__ [0] (n=df@82-35-32-150.cable.ubr01.camd.blueyonder.co.uk) |
18:11:15 | | Join dave [0] (n=dave@dberg-desktop.student.umd.edu) |
18:11:53 | Nico_P | jhMikeS: thanks |
18:12:05 | kkurbjun | linuxstb, thanks for answering that, it turns out the iram is smaller than I thought |
18:13:23 | | Join toffe82 [0] (n=chatzill@adsl-71-132-81-54.dsl.sntc01.pacbell.net) |
18:14:16 | dave | I'm trying to build rockbox with an Ubuntu-based distro, and it's telling me I need arm-elf-gcc. How do I go about getting it? |
18:14:50 | dave | I have gcc and binutils already, I figured it would be in there... |
18:15:39 | jhMikeS | Nico_P: an improvment: http://www.pastebin.ca/751643 |
18:15:48 | Nico_P | dave: run tools/rockboxdev.sh |
18:15:57 | nnk | apt-cache search arm gcc |
18:16:02 | nnk | dave: |
18:16:29 | Nico_P | jhMikeS: can I use it in the sim too? |
18:16:40 | FOAD | http://www.anythingbutipod.com/forum/showthread.php?p=176622 |
18:17:06 | | Join ilgufo [0] (n=matteo@host113-184-dynamic.4-87-r.retail.telecomitalia.it) |
18:17:13 | jhMikeS | Nico_P: just take out the corelock business |
18:17:19 | Nico_P | ok |
18:20:35 | jhMikeS | if you want a removal option sometimes and not others, just increment read conditionally |
18:21:30 | jhMikeS | but that sort of makes it queue_wait_w_tmo(q, 0) anyway ... maybe pointless then |
18:21:56 | | Quit mirak (Remote closed the connection) |
18:22:50 | Nico_P | jhMikeS: is queue_wait() ok for removing the message I just saw with peek() ? |
18:23:40 | | Join Buschel [0] (n=abc@p54A3FFBC.dip.t-dialin.net) |
18:26:34 | | Join rotator [0] (n=e@rockbox/developer/rotator) |
18:26:51 | jhMikeS | sure as long as nothing would empty it from the outside |
18:27:09 | Nico_P | so wait_w_tmo is safer? |
18:28:24 | jhMikeS | no difference really if you design to not allow removal outside the thread's control |
18:29:12 | dave | so now that I apparently have what I need, I have to put the rockbox directory in the path of the compiler? |
18:29:37 | jhMikeS | I just use queue_empty and queue_wait in mpegplayer and it does the job just fine |
18:30:07 | stripwax | dave create a directory called "build" directly under rockbox, then from there run ../tools/configure |
18:30:24 | Nico_P | jhMikeS: you don't need to know which message is there? |
18:30:39 | stripwax | then just make. you shouldn't need to put the rockbox directory in the path of the compiler yourself |
18:31:03 | jhMikeS | I know when I pull it. the thread state says what happens to it next. |
18:31:07 | dave | yes, did that, but it's still giving me "the compiler you must use is not in your path!" |
18:31:42 | Nico_P | dave: you need to use tools/rockboxdev.sh to build the cross-compiler and then add the path it was installed in to your PATH |
18:31:53 | Nico_P | the script tells you what to add |
18:32:19 | Nico_P | dave: oh, didn't see your last message. you just need to change your PATH |
18:32:52 | dave | so I don't have to move the rockbox folder? |
18:33:22 | | Quit advcomp2019 ("Leaving") |
18:34:14 | | Quit zicho ("*.net *.split") |
18:34:31 | | Join zicho [0] (n=martin@c-6a98e355.68-7-64736c14.cust.bredbandsbolaget.se) |
18:35:20 | Nico_P | dave: you shouldn't need to |
18:36:06 | dave | so, changing my PATH consists of changing the directory to /usr/local/arm-elf/bin? |
18:36:26 | dave | I'm not totally sure what changing the PATH means |
18:36:37 | Nico_P | dave: PATH is an environment variable in linux |
18:36:44 | Nico_P | type echo $PATH in a terminal |
18:37:16 | Nico_P | when you enter a command, the shell searches the directories in your PATH to find a corresponding binary |
18:37:47 | dave | ah, I see...so how do you change this guy? |
18:38:32 | dave | I see 7 different directories, I assume I'm just adding another one |
18:38:37 | Nico_P | easiest is to add a line in your .bashrc, "export PATH=<some path>:$PATH" |
18:38:55 | Nico_P | were <some path> was given to you by rockboxdev.sh |
18:39:23 | Nico_P | for me it's /usr/local/arm-elf/bin/arm-elf-gcc |
18:39:45 | Nico_P | err actually it's /usr/local/arm-elf/bin |
18:40:23 | dave | aw sweet, there we go |
18:40:57 | Nico_P | dave: to see which binary is executed by a command, type e.g. "which arm-elf-gcc" |
18:41:00 | dave | (Borat voice) very nice |
18:41:18 | Nico_P | great success! |
18:41:25 | dave | haha |
18:42:08 | dave | wow, I guess it's no surprise it compiles faster than Windows running VMware |
18:42:31 | Nico_P | no it's not... you can also use ccache to speed things up even more |
18:42:49 | dave | how do you do that? |
18:43:41 | | Quit Rondom ("Ex-Chat") |
18:45:13 | Nico_P | sudo aptitude install ccache, then reconfigure your build and you should see "using ccache" in the configure output. that's all |
18:45:37 | dave | cool, found it in the synaptic pacakge manager |
18:45:41 | dave | package* |
18:45:47 | Nico_P | you'll see the difference when doing things like make; make clean; make... the second make call will be super fast |
18:46:58 | dave | I'm quite new to Linux, and doing stuff on this level is certainly still way over my head |
18:48:02 | dave | I'm not a big fan of programming, it's kind of a love-hate relationship for me...love in this situation and hate in almost any other |
18:48:24 | | Join illissius- [0] (n=illissiu@91.83.22.50.pool.invitel.hu) |
18:48:49 | Nico_P | linux takes some getting used to, but once you're a bit used to it you progress fast... I speak from experience |
18:49:39 | dave | what distro do you use? |
18:49:42 | | Join Segadude [0] (n=sega@cpe-24-24-88-117.stny.res.rr.com) |
18:50:03 | Nico_P | kubuntu |
18:50:17 | ompaul | its a pretty distro agnostic function |
18:50:37 | Segadude | Is there a way to play NES games on rockbox? |
18:50:42 | | Join kugel [0] (i=kugel@unaffiliated/kugel) |
18:50:44 | ompaul | dave, what you want is an editor that you feel happy with |
18:51:55 | Nico_P | jhMikeS: is it possible that what I'm doing could muck up a queue_send call? |
18:52:14 | dave | I'm running Linux Mint, simply because it comes preinstalled with a lot of stuff |
18:52:33 | stripwax | Segadude - there's this http://www.rockbox.org/tracker/task/2911?histring=nes |
18:52:45 | dave | like Amarok, though it uses the Gnome desktop environment |
18:52:55 | dave | I could never get KDE to work in Ubuntu |
18:53:16 | markun | linuxstb_: didn't find anything about a boot mode for the clix2 so far |
18:53:23 | dave | anyway, this is a discussion for the community channel, so thanks for your help, Nico_P |
18:53:44 | Nico_P | you're welcome ;) |
18:53:47 | jhMikeS | Nico_P: that depends. peeking won't |
18:53:54 | | Quit dave ("Ex-Chat") |
18:53:57 | Nico_P | and waiting? |
18:54:08 | Nico_P | (with tmo) |
18:54:21 | linuxstb_ | markun: It will most likely be called "recovery mode" by iriver. But yes, it's possible there is no way to access it - my DAB player doesn't have it (afaik) without doing a hardware mod. |
18:54:24 | Segadude | cool thanks! |
18:54:28 | jhMikeS | waiting will reply to the last thread waiting for reply |
18:55:15 | Nico_P | jhMikeS: then that's my problem :/ |
18:55:45 | jhMikeS | Reply is automatic if you wait again. It must flush out any thread that hasn't gotten a reponse. |
18:56:11 | Nico_P | jhMikeS: then I need to remove a message from the top of the queue without answering |
18:57:22 | Nico_P | basically my wait() call is in audio_fill_file_buffer which gets called by audio_check_new_track, which is supposed to reply to the codec thread. the problem is that my wait call replies to the codec thread, which believes an error has occured and stops playback |
18:57:30 | jhMikeS | you must answer at some point. the automatic answer is to the previous message you pulled. |
18:57:37 | | Quit petur ("*real life*") |
18:58:18 | Nico_P | jhMikeS: the answer is supposed to be done later on |
18:59:25 | jhMikeS | so, if queue_reply hasn't been called for a message (if sent) by the time you wait again, it goes auto. |
19:00 |
19:00:02 | jhMikeS | hmmm....so you want to pull a message, delay, then wait again without answering to the first? |
19:00:54 | jhMikeS | delay == do other stuff in between |
19:00:58 | jhMikeS | ? |
19:02:01 | Nico_P | I want to pull a message without replying, do stuff, then reply |
19:02:14 | jhMikeS | but you might handle other messages in between? |
19:02:23 | | Quit Buschel () |
19:02:40 | | Quit stripwax ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
19:02:44 | Nico_P | only one type |
19:03:15 | jhMikeS | queues can't work that way no matter. senders are released in fifo order and must be. |
19:03:31 | Nico_P | makes sense |
19:04:36 | jhMikeS | you need to use an automatic event I think and signal the thread it should wait through the return value. Threads will be released in FIFO order from the event when you pulse it. |
19:05:57 | | Quit illissius` (Read error: 110 (Connection timed out)) |
19:08:28 | Nico_P | jhMikeS: I think I found a satisfactory enough solution |
19:08:54 | jhMikeS | as in? |
19:09:28 | Nico_P | I don't remove the message but still use queue_peek to avoid posting duplicate 'fill buffer' messages |
19:10:04 | jhMikeS | on who's end...the senders? |
19:10:29 | | Quit SirFunk (Remote closed the connection) |
19:10:42 | Nico_P | I'll pastebin a patch |
19:11:12 | Nico_P | (it's related to my latest commit) |
19:11:15 | jhMikeS | I'm just trying to come up with a 100% atomic approach |
19:11:32 | Nico_P | http://pastebin.com/m7f6d36bb |
19:12:38 | lostlogic | Nico_P: just fyi, I'm really impressed with how smoothly the MoB commit has gone... specially knowing how hard it is to get right from my own attempts. |
19:12:54 | Nico_P | before my commit I would unconditionally post Q_AUDIO_FILL_BUFFER if the queue wasn't empty. after my commit, I would never do it |
19:13:31 | Nico_P | lostlogic: thanks :) I was a bit disappointed with the number of bugs left... I'm thankful you were there |
19:14:12 | lostlogic | Nico_P: there will always be bugs with a big commit, but your code was easy enough to understand and work on that they weren't nearly as hard to find as a lot of the bugs in the old system ended up being, that's a big positive for any piece of code. |
19:15:12 | jhMikeS | Nico_P: got a diff I can just make a patch from? It's missing stuff. I want to look at context. |
19:15:19 | Nico_P | :) |
19:16:55 | jhMikeS | Well, look at the queue head from the posting end isn't really safe. |
19:17:27 | *** | Saving seen data "./dancer.seen" |
19:17:43 | Nico_P | jhMikeS: just a sec |
19:17:47 | lostlogic | jhMikeS: is it not safe like dangerous or not safe like not necessarily correct? This is a heuristic use, there's no need for it to always be right as long as it's never dangerous |
19:17:57 | jhMikeS | There are some exceptions but those require the lock held |
19:18:33 | jhMikeS | it _could_ possibly miss posting a message |
19:19:09 | | Quit miepchen^schlaf (Read error: 110 (Connection timed out)) |
19:19:26 | lostlogic | what do you mean miss posting? how can a r/o operation cause the queue to break? |
19:19:35 | | Join miepchen^schlaf [0] (n=hihi@p54BF52EC.dip.t-dialin.net) |
19:21:10 | jhMikeS | once you've left the lock, it's no longer r/o. the message you detected could be gone by the queue_post. |
19:22:18 | lostlogic | oh sure, that's fine though, the worst case of that is that we bounce out of the loop an extra time or stay in the loop one iteration too long, not bad cases |
19:22:59 | lostlogic | peeking should never be used in a make or brake, that's obvious, neither even shoudl queue_empty() they are both just heuristic optimizations |
19:23:13 | lostlogic | s/brake/break/ |
19:23:17 | jhMikeS | Like I said, I'm not fully down with everything that's been done. Maybe a bounce makes no difference in this case. |
19:24:04 | jhMikeS | but queue_empty is a polling mechanism synced with the thread that in effect owns the queue...that's very different |
19:24:38 | jhMikeS | for the wheel drivers and such it's just fine there. it really depends on the particulars. |
19:25:18 | * | sd chokes and passes out after trying to get dsp56k gcc working for a day long |
19:25:46 | Nico_P | jhMikeS: http://pastebin.com/m696c644b |
19:25:48 | | Quit Xerion (Read error: 104 (Connection reset by peer)) |
19:25:59 | Nico_P | there's a bit of noise |
19:27:21 | | Quit darkless ("Leaving") |
19:29:09 | lostlogic | Nico_P: I think that there was a consuming loop in the old audio_thread that would eat any duplicate fill messages before starting fill to make sure it wouldn't just jump right back out of the filling loop |
19:29:50 | Nico_P | lostlogic: the problem here is that consuming a message will reply to the codec thread |
19:30:05 | | Join DrMoos [0] (i=moos@m147.net81-66-159.noos.fr) |
19:30:09 | lostlogic | ahhh *nod* |
19:30:18 | Nico_P | which has sent a check new track message |
19:30:36 | jhMikeS | Nico_P: what format is that? It still says "only garbage" |
19:31:01 | jhMikeS | woops git I see |
19:31:15 | Nico_P | jhMikeS: trying a better one |
19:31:27 | | Quit moos (Read error: 104 (Connection reset by peer)) |
19:32:43 | jhMikeS | what if something generates other messages and the head no longer has a Q_AUDIO_FILL_BUFFER there? won't it behave similarly? |
19:33:04 | Nico_P | jhMikeS: http://www.pastebin.ca/751726 |
19:33:17 | | Join darkless [0] (n=darkless@x1-6-00-1a-92-ea-71-14.k201.webspeed.dk) |
19:34:30 | Nico_P | jhMikeS: similarly to what? |
19:35:11 | BigBambi | ipod chaps - are there any hardware restrictions on ipod button combinations (video in particular) |
19:35:13 | jhMikeS | you'll post another one |
19:36:46 | Nico_P | is there another way? |
19:37:43 | lostlogic | BigBambi: yes, there are −− I think only select and menu can be combined with other buttons, but I coudl be wrong on the specifics |
19:38:10 | BigBambi | OK, cheers. I'm used to the retrictions on H1x0 but not iPods |
19:38:33 | jhMikeS | ugh, that still won't apply in playback.c and mines clean |
19:39:01 | jhMikeS | wait you said you committed something...guess I should up first |
19:39:12 | Nico_P | yes, it changes the same area |
19:39:14 | jhMikeS | ah better |
19:39:47 | | Join cooz [0] (n=grzyzrul@pc178-100.ghnet.pl) |
19:41:48 | | Join japc [0] (n=japc@bl7-250-122.dsl.telepac.pt) |
19:41:57 | jhMikeS | ah, ok, it is on the audio thread |
19:42:01 | Nico_P | yes |
19:42:48 | jhMikeS | context makes all the difference :) |
19:43:03 | | Join bistouri [0] (i=58a10615@gateway/web/cgi-irc/labb.contactor.se/x-7ef373c64a40fdaf) |
19:43:39 | | Nick DrMoos is now known as moos (i=moos@m147.net81-66-159.noos.fr) |
19:43:42 | bistouri | (sansa target) Hello, are there known problems with latest sansapatcher ? |
19:44:10 | | Join jaczehack [0] (i=d572f7c4@gateway/web/cgi-irc/labb.contactor.se/x-90e7f1ce7e5ce25f) |
19:45:21 | linuxstb_ | bistouri: I don't think so. Are you having a problem? |
19:45:36 | Nico_P | Llorean: I have a fix for the issue you reported |
19:47:15 | | Join rep|icant_ [0] (n=rep|ican@adsl-074-183-167-249.sip.bhm.bellsouth.net) |
19:47:35 | bistouri | linuxstb_: not me but a guy who just installed rockbox from my forum |
19:48:00 | Nico_P | jhMikeS: so, ok to commit? |
19:48:21 | jhMikeS | I took some similar approaches to mpegplayer initially but abandoned them since it makes the code more complex and has the danger of unexpected order. If a buffering state is registered, the state can tell it to go back. Some other message may change the state to something that shouldn't buffer. |
19:48:22 | | Quit bistouri ("CGI:IRC (EOF)") |
19:48:29 | | Join webguest13 [0] (i=58a10615@gateway/web/cgi-irc/labb.contactor.se/x-a51d930a458d2658) |
19:48:30 | | Quit webguest13 (Client Quit) |
19:48:34 | | Quit Segadude ("Quitting!") |
19:48:39 | | Join bistouri [0] (i=58a10615@gateway/web/cgi-irc/labb.contactor.se/x-96a217cf633b3ea3) |
19:48:58 | bistouri | linuxstb_: i'll ask him wich version of sansapatcher he used |
19:50:31 | Nico_P | jhMikeS: I've been thinking of the state machine approach and might try to implement it, but I'm not sure it'll be worth it |
19:50:57 | Nico_P | ie I'll try to implement it if I decide it's worth it ;) |
19:51:24 | Nico_P | the audio and buffering thread don't have much different states |
19:54:13 | jhMikeS | I think all those bools could become a single state int. the stuff in mpegplayer dinguishes media state from thread state though. |
19:55:14 | | Quit rep|icant (Read error: 113 (No route to host)) |
19:55:49 | Nico_P | jhMikeS: the bools describe a different state there |
19:56:36 | | Quit nnk ("hibernate") |
19:56:51 | Nico_P | in the scope of the changes I'm about to commit, the state is simply "adding tracks" or "not adding tracks" |
19:57:02 | | Join [fab] [0] (n=fab@refuse.xs4all.nl) |
19:57:08 | Nico_P | and it is completely independant of playing or paused |
19:57:51 | jhMikeS | yes and mpegplayer buffers while paused too |
19:59:40 | jhMikeS | it's tripped by sending a play command with data (force buffering) to true. it continues until it reaches some other state then polls as long as it's in state running. |
20:00 |
20:00:08 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
20:03:35 | | Join bertrik [0] (n=Bertrik_@031-020-045-062.dynamic.caiway.nl) |
20:05:17 | Nico_P | jhMikeS: I'll commit this for now and seriously consider the state approach. you're starting to convice me :) |
20:05:39 | Nico_P | jhMikeS: it's ok if I commit queue_peek? |
20:06:43 | jhMikeS | sure |
20:08:27 | jhMikeS | one difference is the buffering is fully background there except for some initial filling done in the stream manager but that could be moved |
20:08:49 | Nico_P | there == in mpegplayer? |
20:10:08 | jhMikeS | yeah. it sort of forces me to find simple things because of multiple streams. |
20:12:48 | jhMikeS | right now I'm doing the flat window thing (which I implemented before but never committed) |
20:15:53 | | Quit Lambuntu (Remote closed the connection) |
20:21:27 | | Quit andrewg867 (Read error: 110 (Connection timed out)) |
20:23:53 | | Join hannesd_ [0] (n=light@gate-hannes-tdsl.imos.net) |
20:25:23 | markun | jhMikeS: do you recognize any ARM code in here? http://130.89.160.166/rockbox/U20CLIX.RAW |
20:25:57 | | Join atsea-32 [0] (i=atsea-@gateway/tor/x-958c15fc4a62882a) |
20:26:25 | jhMikeS | did you try objdump? |
20:27:57 | markun | yes, trying it with various options |
20:28:39 | linuxstb_ | Did you try big-endian? |
20:29:47 | markun | big, little and both also with thumb |
20:30:06 | markun | maybe I need to set an offset |
20:30:34 | markun | the file starts with U20CLIX, so it looks like ifp_decode did it's job |
20:31:03 | jhMikeS | It looks armish...I see what appears to be little functions with a bunch of data-ish stuff nearby...just at 3E2720 for example |
20:32:51 | jhMikeS | but that could be any risc-type processor...the bytes seem not so arm-ish |
20:33:11 | linuxstb_ | markun: Is that supposed to have a Telechips CPU? |
20:33:16 | markun | yes |
20:33:20 | markun | arm6, right? |
20:33:49 | jhMikeS | alot of thumb code? I recognize the non-thumb more easily. |
20:34:06 | linuxstb_ | I'm not sure about the TCC7801 - I think it has dual cores - a 926 and 946 |
20:34:32 | | Quit zardos ("CGI:IRC") |
20:35:14 | markun | jhMikeS: I didn't say it contained thumb code, just trying a few things |
20:35:53 | jhMikeS | I'm looking at bytes and normal you'd see a lot of Ex xx xx xx for intstruction code |
20:37:12 | | Quit bistouri ("CGI:IRC (EOF)") |
20:37:39 | | Quit hannesd (Read error: 110 (Connection timed out)) |
20:37:39 | | Nick hannesd_ is now known as hannesd (n=light@gate-hannes-tdsl.imos.net) |
20:38:35 | linuxstb_ | markun: Where did you get that file from? You said you had to use ifpdecode? |
20:38:51 | markun | http://www.iriver.com/support/down_view.asp?idx=843 |
20:40:43 | | Join andrewg867 [0] (n=andrew@stjhnf0124w-142163117028.pppoe-dynamic.nl.aliant.net) |
20:41:51 | | Quit scorche (Read error: 104 (Connection reset by peer)) |
20:42:36 | markun | quite a lot of 0000 0000 0000 ... at the end, not sure what it could tell us |
20:42:38 | linuxstb_ | markun: Have you found confirmation anywhere that's it's Telechips? I've seen a few references, but no photos... |
20:43:15 | | Join scorche [0] (i=Blah@rockbox/administrator/scorche) |
20:43:52 | | Part df__ |
20:46:04 | linuxstb_ | markun: Yes, it definitely seems telechips tcc7801 - http://www.pantip.com/tech/gadget/topic/TM2365234/TM2365234.html |
20:46:28 | jhMikeS | if it's arm, it looks like it might be BE. did you try that? |
20:47:53 | linuxstb_ | He said he did. |
20:48:20 | jhMikeS | oh, woops |
20:49:17 | | Quit jaczehack ("CGI:IRC") |
20:50:57 | jhMikeS | oooh...that's not arm or not plaintext. I'm looking at a dump of rb for gigabeat now and the pattern is very different |
20:53:43 | | Join n1s [0] (n=nils@nl104-209-90.student.uu.se) |
20:54:29 | jhMikeS | unless you know already but it's interesting to look at it this way anyhow. is that a bl or fw? |
20:54:45 | linuxstb_ | Based on the size, I would hope it's the fw... |
20:55:19 | jhMikeS | true...I just wonder what they'll put in bl these days |
20:55:20 | linuxstb_ | I'm not sure how someone could write an 11MB bootloader ;) |
20:55:28 | markun | I could imagine that it's double encrypted |
20:55:49 | markun | 1 time the standard iriver method which is decrypted by the flash util |
20:56:01 | jhMikeS | It hardly looks uniformly random |
20:56:07 | markun | true |
20:58:12 | | Join Reinhart [0] (i=8259a53a@gateway/web/cgi-irc/labb.contactor.se/x-ba924d7b3cee6a6a) |
21:00 |
21:00:34 | jhMikeS | It's a dead ringer in appearance for a SH hex dump though |
21:02:59 | | Nick [fab] is now known as fab|afk (n=fab@refuse.xs4all.nl) |
21:03:03 | markun | what about i386? :) |
21:03:58 | jhMikeS | want a sample from rb SH fw? it looks the same. |
21:03:59 | linuxstb_ | markun: Are you interested in the clix2? |
21:04:23 | markun | not really :) |
21:04:54 | markun | but it's a nice puzzle |
21:07:03 | linuxstb_ | It's definitely different to all other telechips devices I've seen... |
21:07:59 | linuxstb_ | The D2 also has the same tcc7801, but uses the same firmware format as the tcc77x devices - which is described on the TelechipsInfo wiki page. |
21:11:00 | | Join criznach [0] (n=criznach@host-69-145-134-192.grf-mt.client.bresnan.net) |
21:11:32 | | Quit HellDragon (Client Quit) |
21:17:02 | | Nick fab|afk is now known as [fab] (n=fab@refuse.xs4all.nl) |
21:17:31 | *** | Saving seen data "./dancer.seen" |
21:17:49 | | Quit _pill (Read error: 110 (Connection timed out)) |
21:18:49 | | Quit BigBambi (Remote closed the connection) |
21:23:14 | | Join Riggs-away [0] (n=Riggs@88-106-235-69.dynamic.dsl.as9105.com) |
21:23:31 | | Join drstrange [0] (i=c86c0ee1@gateway/web/cgi-irc/labb.contactor.se/x-3285a8420e8d72a1) |
21:24:06 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
21:25:47 | drstrange | hey |
21:26:26 | | Nick Riggs-away is now known as Minax (n=Riggs@88-106-235-69.dynamic.dsl.as9105.com) |
21:28:53 | Minax | yo |
21:29:18 | drstrange | is it possible to create landscape based wps screens? |
21:29:42 | krazykit | drstrange, short answer, no |
21:30:00 | krazykit | assuming you're on a portrait target, of course |
21:30:16 | | Join mirak [0] (n=mirak@m94.net81-66-75.noos.fr) |
21:30:38 | drstrange | thank you |
21:30:42 | | Quit ilgufo (Nick collision from services.) |
21:30:45 | | Join gufo [0] (n=matteo@host113-184-dynamic.4-87-r.retail.telecomitalia.it) |
21:30:56 | drstrange | i am on a potrait target |
21:32:50 | Minax | it there a way to get to play GBA roms on rockbox? or will it be too memory hoggin? |
21:33:02 | drstrange | memory hogging |
21:33:41 | Minax | has it been tried? |
21:33:51 | drstrange | can someone explain what cpu frequency refers to |
21:34:23 | Soap | linuxstb: you asked for me 11 hours ago? |
21:34:41 | drstrange | is the 8-digit value shown a representation of Mhz? |
21:35:05 | linuxstb_ | Soap: Yes, I was going to ask you to test something on your C100, but it seems tarsius is on top of things. |
21:35:30 | Soap | ok |
21:36:09 | linuxstb_ | Soap: Do you use Windows or Linux? |
21:36:25 | | Quit drstrange ("CGI:IRC") |
21:41:08 | Soap | linuxstb: if you see tarsius before I do - I /believe/ I have read that the ipod adapter will fit into a C100 with a little bit of shaving on the mating pins. I also believe that the pin-pitch is the same between the two adapters. IF all this is correct AND tarsius wants some plugs (so he doesn't have to strip Sansa cables) I am willing to send him one or two. |
21:43:25 | | Part Llorean |
21:44:15 | | Join HellDragon [0] (n=Nocebo@unaffiliated/helldragon) |
21:46:16 | linuxstb_ | Soap: OK. I think we're a long way from them being useful to him though... |
21:47:20 | | Join Bam1 [0] (i=the@c-69-249-243-110.hsd1.pa.comcast.net) |
21:49:34 | Soap | linuxstb_: I use both. |
21:49:54 | Soap | Windows and CoLinux on my desktop, and linux on my laptop. |
21:51:07 | linuxstb_ | If you wanted, you could test tcctool (on your laptop - it needs native Linux) with the c100. |
21:53:38 | linuxstb_ | You just need to get the latest version of utils/tcctool/ from SVN, type "make" in that directory (you need libusb), put your c100 in recovery mode, and then type "./tcctool -d c100 player.rom", where player.rom is the firmware upgrade file. for your c100. |
21:54:03 | linuxstb_ | It should load the firmware file to RAM and execute it - it won't update the firmware. |
21:54:31 | | Quit hannesd (Read error: 110 (Connection timed out)) |
21:56:00 | Bam1 | Hey, i downloaded Winff 2.91, then i opened the presets with Dev-c++, selected all and pasted in the new presets. I then saved. After that i doubled clicked on the shortcut on my desktop and i received an error. |
21:56:11 | Bam1 | "access violation" |
21:56:37 | Bam1 | Press ok to ignore / press cancel to kill the program |
21:57:07 | Bam1 | if i hit ok it gives me a runtime error thing, if i hit cancel, it cancels |
21:57:24 | | Quit midkay ("Leaving") |
21:58:02 | Soap | It sounds like from what you said that WinFF is crashing upon launch - not upon the starting of ffmpeg? |
21:58:12 | Bam1 | correct |
21:58:16 | | Join rep|icant [0] (n=rep|ican@adsl-074-183-167-249.sip.bhm.bellsouth.net) |
21:58:41 | Soap | ok, did WinFF crash /before/ you edited the presets xml file? |
21:58:47 | Bam1 | Nope |
21:59:04 | Bam1 | ( i opened it before i did the presets =P) |
21:59:22 | Soap | one sec |
21:59:39 | Bam1 | Erm, maybe when i copied and pasted i copied to much or too little? |
22:00 |
22:00:12 | Bam1 | oh! i downloaded 0.291, not 0.29 (because there was no 0.29) do you think that could be a problem? |
22:00:19 | Soap | Well, I do think the evidence clearly points to the editing of the presets file going poorly. ;) |
22:01:22 | Soap | to avoid any potential cut-paste errors, why not simply go back to the wiki page: http://www.rockbox.org/twiki/bin/view/Main/PluginMpegplayer#How_to_encode_files |
22:01:35 | Soap | and right-click the presets.xml link and do a "save as" |
22:01:52 | Bam1 | oh i c |
22:02:04 | Bam1 | will do |
22:02:52 | Bam1 | woot in a can! |
22:02:53 | Bam1 | it worked |
22:03:03 | * | Bam1 hugs soap |
22:03:04 | Bam1 | thanks! |
22:04:00 | Bam1 | can i put videos on it? |
22:04:09 | Bam1 | i mean movies |
22:04:11 | Bam1 | lol |
22:05:21 | linuxstb_ | Isn't that the point? |
22:05:31 | Bam1 | well yes |
22:05:36 | Bam1 | but i think i read somewhere |
22:05:43 | Bam1 | that it cant handel, videos longer then 10 minutes |
22:05:47 | markun | linuxstb_: do you have an example of some TCC encrypted file? |
22:05:59 | linuxstb_ | markun: Sure, but they're not encrypted. |
22:06:05 | markun | ah |
22:06:18 | | Quit rep|icant_ (Read error: 110 (Connection timed out)) |
22:07:30 | linuxstb_ | Did you see the TelechipsInfo wiki page? |
22:07:40 | markun | no, I'll look at it |
22:07:46 | Soap | Bam1: What I am /assuming/ you are refering to is an OLD issue with Mpegplayer not being able to rebuffer, and thus having playback runtime limited by the amount of data it could initially buffer. |
22:08:06 | Soap | There is no such issue at this point in time. |
22:09:48 | Bam1 | sweet |
22:09:54 | Bam1 | simpsons movie on my ipod! |
22:10:37 | | Join homielowe [0] (n=chatzill@d207-81-67-190.bchsia.telus.net) |
22:11:43 | Bam1 | how long would a 351mb video take to convert with WinFF? |
22:12:03 | cooz | i encoded lately one episode of 40min tv show, plays like a charm |
22:12:33 | cooz | to 128x80 res on 3200xp cpu about 10min |
22:12:37 | Bam1 | i downloaded the simpsons movie and now im converting that o.0 |
22:12:48 | Bam1 | or encoding |
22:12:49 | Bam1 | i mean |
22:13:22 | Bam1 | argh i think this will take a while |
22:13:40 | Bam1 | 40kb out of 351kb |
22:13:41 | Bam1 | o.0 |
22:15:14 | Bam1 | peace guys |
22:15:16 | Bam1 | thanks! |
22:15:18 | | Quit Bam1 () |
22:16:22 | linuxstb_ | markun: PM |
22:20:56 | | Quit amiconn (Nick collision from services.) |
22:21:03 | | Join amiconn [0] (n=jens@rockbox/developer/amiconn) |
22:21:35 | | Join Zagor [0] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) |
22:23:26 | | Quit gufo (Client Quit) |
22:25:46 | | Join BigBambi [0] (n=alex@rockbox/staff/BigBambi) |
22:26:20 | | Quit HellDragon (Client Quit) |
22:26:21 | | Join davina [0] (n=davina@cpc1-sout6-0-0-cust616.sotn.cable.ntl.com) |
22:27:57 | | Join Bam1 [0] (i=the@c-69-249-243-110.hsd1.pa.comcast.net) |
22:28:02 | Bam1 | yeah my video |
22:28:06 | Bam1 | turned out horribly |
22:28:24 | Bam1 | the sounds great, but the video (when i played it from my desktop, not the ipod) looks all choppedup |
22:29:25 | Bam1 | nvm i think it was just that i played it from the desktop |
22:29:41 | Bam1 | yup its all good now lol sorry |
22:29:45 | * | Bam1 is embarresed |
22:29:45 | Soap | Bam1: Ok, early on I was tolerant of the conversation which was only marginally on-topic. Currently this has nothing to do with Rockbox and everything to do with video-encoding - which is more of a doom9.org question. |
22:29:55 | | Quit Bam1 (Client Quit) |
22:36:12 | amiconn | markun: The ipod video is a pretty sucky target even if we get the power issue solved |
22:36:17 | Minax | so has a plugin for playing gba roms been attempted? |
22:36:41 | amiconn | (unless someone finds *all* the secrets about the bcm2722) |
22:37:04 | amiconn | The poor PP really struggles with the bare amount of pixels |
22:37:49 | | Quit kubiix (Read error: 104 (Connection reset by peer)) |
22:39:21 | amiconn | Just the YUV -> RGB conversion maxes out at ~27fps fullscreen when neglecting the broadcom finishup wait. That's just the conversion, without any video decoding running, at 80MHz |
22:40:14 | amiconn | About 30 cpu cycles per pixel - that's already pretty efficient |
22:41:02 | | Quit homielowe (Read error: 110 (Connection timed out)) |
22:41:24 | n1s | Minax: no and most of our targets wouldn't be able to handle it |
22:43:21 | Minax | ah well |
22:43:55 | * | amiconn wonders what's up with the UI freeze on G5 :\ |
22:45:27 | | Join HellDragon [0] (n=Nocebo@unaffiliated/helldragon) |
22:46:44 | n1s | amiconn: is there any advantage to running many mac instructions following each other? as compared to running say 4 and doing something else and running 4 more? |
22:47:25 | amiconn | That doesn't matter as long as you take care of the latency when fetching the result |
22:47:54 | n1s | ok, and that latency is just from accessing the acc registers, right? |
22:48:01 | amiconn | yes |
22:48:44 | amiconn | You should put 2 instructions (or one taking 2 or more machine cycles) between the last mac instruction and the move.l/movclr.l from %accX |
22:48:46 | * | n1s is trying to turn tremor mdct into asm |
22:50:29 | amiconn | The ape filter is a perfect example of a looong streak of mac instructions. It runs nothing but mac instructions (with parallel load) in sequence, only interrupted by loop control every 16 instructions, for the whole filter depth, which can be 16, 32, 64, 256 or 1280 samples |
22:50:39 | n1s | the beginning is looking quite good, with mdct_butterfly_8/16/32 done speed increased from 319->326 %realtime |
22:51:14 | amiconn | With mac it's often better to run a straight idct (without butterflies) afaiu |
22:51:29 | | Quit Reinhart ("CGI:IRC (Ping timeout)") |
22:51:31 | n1s | amiconn: I've been looking at that and a lot of other rockbox coldfire asm to see how things are done generally |
22:51:40 | amiconn | Not sure about 1d - this is not exactly my main area.... |
22:52:55 | n1s | amiconn: I've mostly been turning c into asm not so much making another implementation |
22:55:24 | | Quit atsea-32 (Remote closed the connection) |
22:56:54 | | Quit Minax () |
22:59:51 | Zagor | what frequency are we running the sansas during usb mode? what do we know about the pp usb controller clocking? could it be that it needs to run a certain speed to get the correct bus timings? |
23:00 |
23:00:40 | Robin0800 | with latest svn ipod video is boosted all the time very poor battery life more buffering problems? |
23:02:15 | | Quit criznach ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") |
23:05:00 | Robin0800 | any one ? confirm this problem |
23:08:49 | | Quit ompaul (Client Quit) |
23:09:53 | rasher | keanu: Just strip the binaries after building. See the UiSimuator wiki page for details (at the bottom) |
23:17:34 | *** | Saving seen data "./dancer.seen" |
23:20:47 | | Quit jhulst ("Konversation terminated!") |
23:22:23 | | Quit merbanan (Read error: 110 (Connection timed out)) |
23:26:02 | | Quit Nico_P (Remote closed the connection) |
23:26:10 | | Join karashata [0] (n=Kimi@pool1-094.adsl.user.start.ca) |
23:28:07 | | Quit davina ("xchat on Ubuntu 7.04") |
23:30:40 | | Join davina [0] (n=davina@cpc1-sout6-0-0-cust616.sotn.cable.ntl.com) |
23:35:25 | | Quit Siku () |
23:36:28 | Soap | Should there be a post in the "Announcements" section of the forums regarding MoB - and if so, should there be a call for bug-hunting? Or should the existing pratice of bug submission be continued? |
23:36:38 | | Quit desowin ("use linux") |
23:37:14 | amiconn | hmpf |
23:37:27 | amiconn | jhMikeS: Do you have any idea what 0x70000080 might be? |
23:37:53 | | Join petur [0] (n=petur@d54C6FBFB.access.telenet.be) |
23:38:15 | n1s | Soap: as the intention is/was that there should be no user-visible change except in a few cases i don't think it is necessary |
23:38:59 | n1s | also I think declaring bug-hunting season open will result in a flood of duplicates... :-/ |
23:41:13 | bertrik | I've seen some weirdness, like rockbox freezing completely and playback stopping spontaneously after the mob commit, but I cannot really pinpoint it |
23:41:46 | n1s | bertrik: even after all the fixes committed today? |
23:42:16 | bertrik | yes, i svn updated a few hours ago |
23:42:16 | | Join Siku [0] (n=Siku@f303b.w3.tontut.fi) |
23:43:17 | n1s | there was a report for spontaneous stopping iirc but it's closed now... |
23:44:20 | bertrik | also I'm hearing subtle ticks in playback every 20 seconds or so, that I didn't hear before |
23:44:41 | n1s | bertrik: which player? |
23:44:46 | bertrik | sansa e200 |
23:45:15 | n1s | sounds weird, are you sure they weren't there before? |
23:46:30 | bertrik | not completely sure, it's very subtle |
23:46:52 | | Join homielowe [0] (n=chatzill@d207-81-67-190.bchsia.telus.net) |
23:47:40 | amiconn | Hmm, that looks interesting. The OF broadcom transfer calls a special subroutine when the transfer is >= 256 byte, and that routine in turn calls flush_cache. Maybe they use DMA... |
23:50:17 | jhMikeS | amiconn: I think that looked like some pin config or something. |
23:50:46 | amiconn | The G5 OF resets a number of bits in it in a function dealing with the bcm |
23:51:14 | n1s | bertrik: I would put it in the tracker with as much detail as possible, like which codecs it happens with, maybe captured output from the player where the tick can be heard and also compared with output before the bug was introduced etc |
23:51:20 | amiconn | Not sure yet how if and how that part is called... |
23:51:47 | bertrik | ok, I'll have a closer look, tomorrow |
23:52:19 | | Join _pill [0] (i=pill@sloth.shellfx.net) |
23:52:27 | jhMikeS | actually, it's used in the e200 lcd driver as the chip reset |
23:52:32 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
23:53:28 | amiconn | Aha, hmm... |
23:53:33 | jhMikeS | I think 0x70000020 was the thing that looked like a pin config reg (from comparing the H10 ADC setup with e200 et al.0 |
23:53:55 | | Join SirFunk [0] (n=Sir@206-159-155-246.netsync.net) |
23:56:28 | | Join kri [0] (n=kripso@90-227-132-15-no18.tbcn.telia.com) |
23:58:10 | kri | hello |
23:58:24 | | Join hcs [0] (n=agashlin@rockbox/contributor/hcs) |
23:58:47 | | Part [fab] ("Konversation terminated!") |
23:58:53 | kri | can't get 'rockbox' to work on my ipod video 80 gb. :( |