Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2010-12-27

00:04:06 Quit wodz (Quit: Leaving)
00:07:45 Quit jfc^2 (Read error: Connection reset by peer)
00:08:21 Join jfc^2 [0] (~john@dpc6682208002.direcpc.com)
00:21:57 Quit BHSPitMonkey (Read error: Operation timed out)
00:27:58 Quit sinthetek (Ping timeout: 265 seconds)
00:29:17 Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek)
00:29:59 Join Keripo1 [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com)
00:30:57TheSevendoes it matter if a PCM driver only accepts even sample counts?
00:31:08TheSeven(and ignores the last sample if the count is uneven)
00:31:19 Quit Keripo (Ping timeout: 240 seconds)
00:37:09 Quit Buschel (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014])
00:37:44 Quit GeekShadow (Read error: Connection reset by peer)
00:39:20 Quit ender` (Quit: If God had intended us to go around naked, He would have made us that way. -- Olum's Observation)
00:40:47 Join bug2000 [0] (~bug@194.90.37.54)
00:40:47 Quit bug2000 (Changing host)
00:40:47 Join bug2000 [0] (~bug@unaffiliated/bug2000)
00:41:25 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow)
00:41:44 Quit Guest35485 (Ping timeout: 276 seconds)
00:48:46 Quit bertrik (Quit: :tiuQ)
01:00
01:05:06 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey)
01:13:25 Quit kadoban (Ping timeout: 272 seconds)
01:13:56 Join Guest2921 [0] (~hannes@p5B25F2A4.dip.t-dialin.net)
01:15:46 Quit Guest2921 (Client Quit)
01:18:18 Quit pamaury (Remote host closed the connection)
01:21:13 Quit Keripo1 (Ping timeout: 255 seconds)
01:22:06 Quit sinthetek (Ping timeout: 265 seconds)
01:24:11 Join JdGordon| [0] (~jonno@123-243-140-31.static.tpgi.com.au)
01:24:11 Quit JdGordon| (Changing host)
01:24:11 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon)
01:24:12 Join sinthetek [0] (~sinthetek@cpe-174-111-239-037.triad.res.rr.com)
01:24:12 Quit sinthetek (Changing host)
01:24:12 Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek)
01:25:03 Quit BHSPitMonkey (Ping timeout: 240 seconds)
01:37:05 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com)
01:38:05 Join Feisar [0] (jljhook@irkki.fi)
01:38:35 Nick Feisar is now known as Guest65787 (jljhook@irkki.fi)
01:42:02 Quit stoffel (Ping timeout: 240 seconds)
01:43:12 Join eWill [0] (~chatzilla@adsl-76-235-39-45.dsl.dytnoh.sbcglobal.net)
01:43:46eWillis it safe to insert/remove the microSD card when RB is on?
01:48:22 Quit Guest65787 (Ping timeout: 240 seconds)
01:48:44 Join kop316 [0] (~41280421@giant.haxx.se)
01:49:12***Saving seen data "./dancer.seen"
01:49:27kop316Good evening, I was filing a bug in Rockbox, and it suggested to come onto here to discuss it.
01:50:23[Saint]eWill: Yes.
01:51:19kop316I have a sansa fuze v2.
01:51:24kop316 When I save a playlist under "Playlists -> Save Current Playlist", the playlist does not automatically appear in "Playlists -> View Catalog"
01:51:31kop316When I look to find where it saved, I found Rockbox saves playlists under the / directory. "View Catalog" looks under /Playlists and lists the playlists there.
01:52:11kop316So I think to fix it, one must change the default save location of "Playlists -> Save Current Playlist" from the / folder to the /Playlists folder.
01:53:08kop316I have not filed this as a bug yet, but I would like to make sure this is a bug before filing it
01:55:05kop316This occures in version 3.7.1
01:55:31TorneThat's not a bug, but intended behaviour
01:55:41Tornethe catalog is just a directory, not anything special
01:56:48Torneplaylists created directly from directories are saved next to the directory they relate to.
01:56:57Torneplaylists don't have to be under the playlist folder to work
01:56:58Torneif you want them to be there, move them
01:59:06 Quit sinthetek (Ping timeout: 255 seconds)
02:00
02:00:12 Join sinthetek [0] (~sinthetek@cpe-174-111-239-037.triad.res.rr.com)
02:00:12 Quit sinthetek (Changing host)
02:00:12 Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek)
02:00:26*TheSeven made his ipod output an awful noise!
02:00:50 Quit kop316 (Quit: CGI:IRC (EOF))
02:01:12[Saint]success!
02:01:15 Quit ej0rge (Remote host closed the connection)
02:02:58TheSeven[Saint]: not quite
02:03:15*TheSeven feels lucky he didn't have the earphones in his ears when that started
02:03:34TheSevenit was annoying enough with them lying on the desk
02:15:59 Quit GeekShadow (Quit: The cake is a lie !)
02:17:00 Join JesusFreak316 [0] (~JesusFrea@pool-173-65-105-252.tampfl.fios.verizon.net)
02:22:19 Quit JdGordon| (Ping timeout: 240 seconds)
02:25:16 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey)
02:26:43 Quit BHSPitMonkey (Read error: Connection reset by peer)
02:32:32 Nick JesusFreak316 is now known as JesusFreak316_wa (~JesusFrea@pool-173-65-105-252.tampfl.fios.verizon.net)
02:32:53 Nick JesusFreak316_wa is now known as JF316_watching_T (~JesusFrea@pool-173-65-105-252.tampfl.fios.verizon.net)
02:33:14 Nick JF316_watching_T is now known as JF316_WatchingTV (~JesusFrea@pool-173-65-105-252.tampfl.fios.verizon.net)
02:44:53 Join The_Pwny [0] (~IceChat7@203-219-63-40.tpgi.com.au)
03:00
03:15:59 Quit DerPapst1 (Quit: Leaving.)
03:16:36 Join DerPapst [0] (~Alexander@91-66-226-46-dynip.superkabel.de)
03:20:39 Quit DerPapst (Ping timeout: 240 seconds)
03:32:05 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net)
03:49:17***Saving seen data "./dancer.seen"
04:00
04:19:06 Join shai_ [0] (~Shai@l192-117-110-233.cable.actcom.net.il)
04:22:35 Quit shai (Ping timeout: 240 seconds)
04:29:04 Quit Barahir_ (Ping timeout: 265 seconds)
04:30:41 Join Barahir [0] (~jonathan@frnk-4d009a26.pool.mediaWays.net)
04:30:50 Quit literal (Quit: leaving)
04:33:35 Join r0b- [0] (~nnscript@76.235.186.180)
04:35:23 Join literal [0] (hinrik@w.nix.is)
04:40:17 Quit Keripo (Ping timeout: 264 seconds)
04:43:51 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com)
04:53:24 Join jroysdon [0] (~jroysdon@Ox.roysdon.org)
04:53:41jroysdonAnyone have an quick pointers for using the installer on Fedora 14? I'm getting a permission denied error
04:54:19TeruFSXsudo.
04:54:51TeruFSX(That is, just run the installer with sudo)
04:56:16jroysdongotcha
04:57:18 Quit amiconn (Disconnected by services)
04:57:20 Join amiconn_ [0] (quassel@rockbox/developer/amiconn)
04:57:25 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn)
04:57:36 Quit pixelma (Disconnected by services)
04:57:37jroysdonI have an older bootloader from like 2 years ago. Should I reinstall it as part of my install (it is prompting me)?
04:57:38 Join pixelma_ [0] (quassel@rockbox/staff/pixelma)
04:57:40 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma)
05:00
05:01:03 Quit TheSeven (Ping timeout: 260 seconds)
05:01:38Lloreanjroysdon: It's generally not beneficial to run an out of date bootloader, and when the installer can update it for you there's usually no reason not to update it.
05:03:34jroysdonyup, figured I might as well
05:04:59 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven)
05:05:34jroysdona bit faster, yay
05:10:17 Quit mortalscan (Ping timeout: 255 seconds)
05:10:26jroysdonwow, usb keypad multimedia mode rocks... nice little quick remote
05:11:04jroysdonare their other modes and how to trigger? hmm, time to look at the manual
05:11:41jroysdonoh, and how do I get artwork for all of my albums such that rockbox will know it? rhythmbox downloads it all for me in Gnome (Fedora 14)
05:12:47TeruFSXCheck out http://www.rockbox.org/wiki/AlbumArt. They give some utilities that export album art to files that Rockbox can use.
05:14:28jroysdoncool, thanks
05:17:47 Quit guymann (Ping timeout: 240 seconds)
05:18:59 Quit JF316_WatchingTV (Ping timeout: 240 seconds)
05:22:21jroysdonThis seems to work well enough: http://unrealvoodoo.org/hiteck/projects/albumart/
05:38:51 Quit sinthetek (Ping timeout: 246 seconds)
05:46:10 Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek)
05:47:57 Quit sinthetek (Read error: Connection reset by peer)
05:48:16 Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek)
05:49:18***Saving seen data "./dancer.seen"
05:54:01 Join fyrestorm [0] (~nnscript@cpe-69-203-144-35.si.res.rr.com)
06:00
06:16:53 Join JdGordon| [0] (~jonno@123-243-140-31.static.tpgi.com.au)
06:16:53 Quit JdGordon| (Changing host)
06:16:53 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon)
06:26:14 Quit sinthetek (Ping timeout: 240 seconds)
06:50:26 Quit Keripo (Quit: Leaving.)
06:54:29 Part jroysdon ("Leaving")
06:57:24 Join Feisar [0] (jljhook@irkki.fi)
06:57:40 Nick Feisar is now known as Guest64136 (jljhook@irkki.fi)
07:00
07:02:09 Quit Guest64136 (Ping timeout: 260 seconds)
07:03:38 Quit Dreamxtreme (Quit: IRC is just multiplayer notepad)
07:07:25[Saint]Huh...weird.
07:07:45[Saint]Fuze V1's wheel light seems to depend on the LCD in some way.
07:07:57[Saint]It appears to not function if the LCD isn't present.
07:19:52 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey)
07:49:22***Saving seen data "./dancer.seen"
07:54:59 Quit froggyman (Ping timeout: 265 seconds)
07:58:42 Join Feisar [0] (jljhook@irkki.fi)
07:59:09 Nick Feisar is now known as Guest89014 (jljhook@irkki.fi)
08:00
08:03:49 Quit Guest89014 (Ping timeout: 276 seconds)
08:11:18 Join JdGord [0] (~jonno@114.75.104.10)
08:20:38 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl)
08:20:38 Quit bertrik (Changing host)
08:20:38 Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
08:25:37 Join mystica555_ [0] (~mike@c-75-70-179-25.hsd1.co.comcast.net)
08:35:04 Join Dreamxtreme [0] (~Dre@92.30.58.174)
08:45:07 Join LinusN [0] (~linus@giant.haxx.se)
08:45:07 Quit LinusN (Changing host)
08:45:07 Join LinusN [0] (~linus@rockbox/developer/LinusN)
08:53:04 Join ender` [0] (krneki@foo.eternallybored.org)
08:53:34 Quit antil33t (Read error: Connection reset by peer)
08:55:54 Join antil33t [0] (~Mudkips@124-197-51-80.callplus.net.nz)
08:59:53 Join Feisar [0] (jljhook@irkki.fi)
09:00
09:00:19 Nick Feisar is now known as Guest4567 (jljhook@irkki.fi)
09:04:51JdGordon|[Saint]: Teru's patch is actually correct, i tihnk
09:05:01JdGordon|you see it correct because you only use one-lcd targets
09:05:57[Saint]Ah...right. I just couldn't see what it was actually fixing.
09:06:15 Join n1s [0] (~n1s@rockbox/developer/n1s)
09:06:23[Saint]I didn't think it unusual for the false case to never appear.
09:07:10 Quit antil33t (Ping timeout: 240 seconds)
09:31:03 Quit JdGord (Quit: Bye)
09:37:41CIA-7New commit by nls (r28907): Fix FS #11838. Escape special char that broke manual builds and generated incomplete output.
09:39:59CIA-7r28907 build result: All green
09:40:59bertrikI'm struggling with AMSv2 sd card controller driver
09:41:24bertrikSome commands just seem to always fail, not even giving back a card response
09:48:59 Quit JdGordon| (Ping timeout: 276 seconds)
09:49:15bertrikHowever the sd command (CMD7) that seems to fail based on sd controller status, does seem to have effect on the card
09:49:26***Saving seen data "./dancer.seen"
09:52:36 Join jordan` [0] (~jordan@jem75-13-78-235-252-137.fbx.proxad.net)
10:00
10:16:32bertrikHm, it could make sense that there is no card response on sd CMD7 when it is used to *de*select an sd card, but I can find anything explicit about this in the spec
10:16:45bertrik*can't
10:19:16 Join kevku [0] (~kevku@2001:7d0:0:f000::135d)
10:19:41 Quit The_Pwny (Ping timeout: 276 seconds)
10:22:28 Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz)
10:23:42 Join stoffel [0] (~quassel@p57B4BFCC.dip.t-dialin.net)
10:38:47 Quit jfox570 (Quit: Leaving)
10:41:12 Join DerPapst [0] (~Alexander@91-66-226-46-dynip.superkabel.de)
10:41:37 Join pamaury [0] (~quassel@cez63-2-88-164-98-172.fbx.proxad.net)
10:41:37 Quit pamaury (Changing host)
10:41:37 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
10:46:17 Join T44 [0] (~Topy44@f048205004.adsl.alicedsl.de)
10:49:36CIA-7New commit by nls (r28908): Fix profiling on coldfire with newer Gcc. ...
10:49:48 Quit Topy44 (Ping timeout: 240 seconds)
10:51:32CIA-7r28908 build result: All green
10:57:04 Join thomasjfox [0] (~thomasjfo@dslb-088-065-026-072.pools.arcor-ip.net)
11:00
11:00:08 Part Llorean
11:05:13CIA-7New commit by jethead71 (r28909): Certain data accesses in the kernel should have volatile semantics to be correct and not rely on the whims of the compiler. Change queue clearing to ...
11:06:56 Quit YPSY (Quit: ZNC - http://znc.sourceforge.net)
11:07:27CIA-7r28909 build result: All green
11:07:56 Quit T44 (Read error: Connection reset by peer)
11:08:06 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean)
11:08:41jhMikeSn1s: might that not go better in thread_coldfire.c ? (I've been trying to maitain directly inline asm out of thread.c)
11:09:57n1ssure, just wrap it in an inline function?
11:10:20jhMikeSyeah
11:12:26 Join Ypsy [0] (~ypsy@geekpadawan.de)
11:12:34 Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de)
11:15:12 Join user890104 [0] (~Venci@2001:0:5ef5:73b8:2c55:34c:2b16:10ec)
11:16:57 Quit thomasjfox (Read error: Operation timed out)
11:17:08 Quit BHSPitMonkey (Remote host closed the connection)
11:19:40n1sjhMikeS: this ok http://pastebin.ca/2030407 ?
11:21:43jhMikeSlooks alright, thanks
11:21:52n1sno problem
11:22:41CIA-7New commit by nls (r28910): Move codfire inline asm into cpu specific file.
11:22:48 Nick Guest4567 is now known as feisar- (jljhook@irkki.fi)
11:22:56 Join thomasjfox [0] (~thomasjfo@dslb-088-065-026-072.pools.arcor-ip.net)
11:23:03 Quit feisar- (Quit: leaving)
11:23:17 Join feisar- [0] (jljhook@irkki.fi)
11:23:25 Nick feisar- is now known as feisar (jljhook@irkki.fi)
11:24:02 Nick feisar is now known as Guest9592 (jljhook@irkki.fi)
11:24:48CIA-7r28910 build result: All green
11:45:18 Join kugel [0] (~kugel@rockbox/developer/kugel)
11:46:06thomasjfoxhey kugel
11:46:25thomasjfoxJust wanted to thank you for your help the other night
11:46:26kugelthomasjfox: hey
11:46:33CIA-7New commit by nls (r28911): Fix warning about using static vars in non static inline functions with gcc 4.5.
11:46:39kugelyou're welcome :)
11:47:03thomasjfoxI was able to sort out the gstreamer issue by the help of #gstreamer :)
11:48:29CIA-7r28911 build result: All green
11:48:46kugelgreat
11:49:30***Saving seen data "./dancer.seen"
11:52:33kugeln1s: gcc switch soon?
11:54:07n1skugel: hopefully, ill send a mail to the list later today
11:54:36kugelare you planning for 4.5.x? is it better than 4.4.x?
11:54:47n1syes
11:55:03kugelboth? :)
11:56:17n1syeah, 4.4 had some weird bug that caused it to access the stack with halfword accesses in some cases that seems fixed in 4.5, but speedwise they were about the same 4.5 might be a little faster and is producing smaller code
11:57:55kugelah sounds good
11:59:18kugeljhMikeS: arm-eabi has a preprocessor define (re: your question from a few days ago)
12:00
12:03:21 Join casainho [0] (~chatzilla@pal-213-228-181-14.netvisao.pt)
12:08:48jhMikeSkugel: happen to know it off hand?
12:09:19kugeljhMikeS: __ARM_EABI__
12:09:30kugelbut we shouldn't write code with the old compiler in mind
12:10:30jhMikeSI wasn't but I did want to test without eabi, unless −−no-eabi is going to be dropped anyway?
12:10:53kugeldunno, but I think it should
12:11:36jhMikeSa careful look at the asm output file was far faster than worrying about that anyway, lol
12:11:42kugelwe don't actually know if the code still works under the old one
12:17:32jhMikeSit wouldn't compile or link as-is anyway, not for the beast. beyond that, no idea
12:24:09 Part LinusN
12:26:47 Join user890104_ [0] (Venci@venci-notebook-lan.ipv6.6bez10.info)
12:28:30 Quit user890104 (Ping timeout: 272 seconds)
12:32:06 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow)
12:36:52 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93)
12:39:16 Nick user890104_ is now known as user890104 (Venci@venci-notebook-lan.ipv6.6bez10.info)
12:45:15 Quit stoffel (Ping timeout: 255 seconds)
12:49:14 Nick shai_ is now known as shai (~Shai@l192-117-110-233.cable.actcom.net.il)
12:52:17thomasjfoxkugel: I currently test the native threads code again.
12:52:27thomasjfoxI still get a hang on app shutdown
12:53:13thomasjfoxOne thread is stuck in tick_timer() -> sim_enter_irq_handler()
12:54:04thomasjfoxIt's waiting for interrupt re-enable
12:56:42kugelthomasjfox: do you reach sim_kernel_shutdown()?
12:56:55 Join JdGord [0] (~jonno@114.75.104.10)
12:57:07thomasjfoxIIRC it gets called. Let me check
12:57:42thomasjfoxYes
12:58:02thomasjfoxI have a printf() before the end of the sdl event thread routine
12:58:17kugelthat calls disable_irq(), but removes the timer in the next line
12:58:32kugelcan sdl remove threads that are waiting on a cond?
12:59:16thomasjfoxGood question. Probably with KillThread, though that's the big hammer method and unclean
12:59:55kugelit's a timer thread, it doesn't have a clean way to exit anyway
13:00
13:00:08kugelyou could try moving the disable_irq call down
13:01:53thomasjfoxOk. Though this will only move the problem as we might still enter the timer routine at the same time as RemoveTimer() gets called
13:02:49kugelI'd expect sdl is able to handle this case internally
13:02:52thomasjfoxIn fact, I think moving disable_irq down won't help, but I'll try it anway
13:04:13kugelalternatively you can move the do_exit = true up and check it in the timer callback (if it returns 0 it's deactivated
13:05:00thomasjfoxStill hangs with disable_irq() moved down
13:05:24*n1s sent his mail to the list now so dust off your coldfire targets and give the test builds a try
13:05:55kugelSDL_RemoveTimer also has a return value which might be interesting to check
13:14:27 Quit DerPapst (Read error: Connection reset by peer)
13:14:53thomasjfoxkugel: The timer exits fine now. Now it's hanging at another place
13:15:02 Join DerPapst [0] (~Alexander@91-66-226-46-dynip.superkabel.de)
13:15:07*kugel wonders why the tick timer returns 1
13:15:12kugelshouldn't it return 10?
13:15:19kugelor rather, interval
13:15:19thomasjfoxcodec_pcmbuf_insert_callback() -> sleep -> switch_thread() -> wait_for_interrupt()
13:17:39kugelhm, wait_for_interrupt() handles the case where you exit while the wait, but not the otherone I think
13:18:04 Join LinusN [0] (~linus@rockbox/developer/LinusN)
13:19:14 Quit casainho (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101206121845])
13:19:40thomasjfoxkugel: You are right, it should return interval.
13:20:19kugelI wasn't aware that the sim runs on an 1ms tick
13:20:45kugeljhMikeS: any idea about that?
13:21:11thomasjfoxThe minimum resolution for SDL timers is 10ms
13:21:28thomasjfoxIf you schedule for 16ms, it will be called after 20ms
13:22:16jhMikeSkugel: about? the thread thing?
13:22:31 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon)
13:22:35kugelthe return value of tick_timer for sdl
13:24:29jhMikeSonly the check for NULL in the code
13:25:15kugelwhat?
13:26:07jhMikeSare you talking about tick_timer_id in kernel-sdl.c?
13:27:24thomasjfoxHe meant the return value of tick_timer()
13:28:02thomasjfoxThe return value of "1" will re-schedule the timer from 10ms to 1ms
13:28:52*jhMikeS just needs a relevant filename
13:29:02thomasjfoxkernel-sdl.c
13:29:35jhMikeSok, the return value of the handler hehe
13:29:41kugelany periodic timer should just return interval IIUC
13:30:28thomasjfoxAlso re-scheduling to 1ms won't work anyway as the maximum resolution is in 10ms steps according to the SDL_SetTimer manual
13:30:42jhMikeSjust says it's the next interval
13:30:56jhMikeSmake it random milliseconds if you like :)
13:32:52kugelTheSeven: for AddTimer() it says it's platform dependant but at least 10ms
13:33:00*jhMikeS asks that you keep in mind that sometimes it's been years since he's really examined certain code, so he might be clueless for a bit
13:35:06jhMikeSthomasjfox: http://sdl.beuc.net/sdl.wiki/SDL_AddTimer says it's the smallest granularity you should normally expect since its system dependent
13:35:23kugel"If the returned value from the callback is the same as the one passed in, the timer continues at the same rate. If the returned value from the callback is 0, the timer is cancelled. "
13:35:37kugelwe pass 10 to AddTiemr()
13:35:55*TheSeven assumes that was a false positive
13:36:57kugelthomasjfox: for the deadlock in wait_for_interupt() you could try duplicating the the if (do_exit) so that it's also checked before SDL_CondWait()
13:37:27kugelI'll investigate the timer thing in the meantime
13:38:19kugelTheSeven: that wasn't meant for you, sorry
13:39:05 Quit Guest9592 (Ping timeout: 276 seconds)
13:40:57thomasjfoxkugel: That did the trick
13:44:12 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
13:45:07kugel1 or interval makes no difference on my machine
13:45:36thomasjfoxkugel: On the n900 neither
13:45:42 Nick evilnick_ is now known as evilnick (~evilnick@cpe-24-193-43-185.nyc.res.rr.com)
13:45:51 Quit evilnick (Changing host)
13:45:51 Join evilnick [0] (~evilnick@rockbox/staff/evilnick)
13:47:29 Quit bluebroth3r (Ping timeout: 250 seconds)
13:48:55jhMikeSit still uses sdl for the android app?
13:49:18kugelthe android app never used sdl
13:49:32CIA-7New commit by kugel (r28912): Return interval in the SDL timer callback as it should happen in periodic timers. ...
13:49:34***Saving seen data "./dancer.seen"
13:49:46kugelthomasjfox: does exit work now?
13:49:50thomasjfoxyes
13:50:01kugelif you can give me the fixes I can update my ucontext_thread branch :)
13:50:05jhMikeSI'm just seeing "wait_for_interrupt" then talk about SDL_CondWait(), so I'm confused :)
13:50:09thomasjfoxTried five times - all fine
13:50:42kugeljhMikeS: that's for the sdl port, using our threading library
13:51:34jhMikeSworking on using thread.c instead is what you mean?
13:51:35CIA-7r28912 build result: All green
13:51:54kugeljhMikeS: yeps
13:52:39jhMikeSthe fewer of those the better indeed
13:53:16 Join stoffel [0] (~quassel@p57B4BFCC.dip.t-dialin.net)
13:53:19 Quit parafin (Remote host closed the connection)
13:53:53thomasjfoxkugel: http://pastebin.com/SYty6gw6
13:53:58 Join parafin [0] (parafin@paraf.in)
13:54:53thomasjfoxkugel: Please verify the disable_irq() is at the right spot
13:56:50kugelis the osso thread down at this point?
13:57:18thomasjfoxYes
13:58:15kugeli think the disable_irq() call isn't even needed, all "interrupts" will fail after the sim_thread_cond is destroyed, whether they're waiting on it or not
13:59:04jhMikeSkugel: will it simulate more than 1 core too?
13:59:22kugelno
13:59:33kugelwe don't simulate it currently, do we?
14:00
14:00:02*TheSeven starts swearing at his ipod once again
14:00:24jhMikeSkugel: no, but I was thinking it would basically be two pools of threads and a "core lock" would just be a mutex or sem
14:01:06TheSevenseems to be some kind of misfiring DMA interrupts this time
14:01:07jhMikeSN pools for N cores, more generally
14:01:24kugelyou could still do it using thread.c
14:01:59kugelyou just need sdl threads for each core instead of a single one which runs all rockbox threads
14:02:46jhMikeSkugel: that too
14:02:47kugelalthough I'm not sure how useful that is. aren't threads only quasi-parallel?
14:03:17jhMikeSonly if the host system is single-core, but that's pretty uncommon now
14:04:04JdGordon|do we really need to simulate dual cores?
14:04:36jhMikeSwhy not? it's cool :)
14:05:12JdGordon|seems like an unnecesary complication
14:05:50jhMikeSexistence is unnecessary complication :P
14:06:41bertrikTheSeven, isn't the n-th time (n > 2) where interrupts are doing suspicious things on the s5l870x?
14:07:11TheSeventhis time, the things are more suspicious than usual
14:07:11bertrikmaybe the s5l870x interrupt system in general should be more thoroughly reviewed
14:07:32TheSeventhe s5l8702 interrupt handling is completely different to the 8701
14:08:28TheSeventhe weird thing is that a DMA core 0 channel 1 IRQ fires each time another IRQ fires (for example USB), but not when it should
14:08:39TheSeveni.e. if there are no other IRQs, it doesn't fire at all
14:13:12bertrikmaybe a HW bug?
14:15:12kugelthomasjfox: I should probably get around committing my ucontext_thread work to svn
14:15:58 Join mortalscan [0] (~mortalsca@109.169.55.155)
14:16:00thomasjfoxnice!
14:16:31thomasjfoxbtw: what's the reason rockbox doesn't explicitly enable gcc optimizations?
14:16:43kugelno idea
14:16:51kugelwe do it for codecs, but not for the core
14:18:48thomasjfoxRegarding the ucontext_thread commit to svn, it would be nice if the native threads / SDL threads implementation are switchable
14:19:03thomasjfoxthe sdl threads are very good for debugging deadlocks
14:19:04kugelthey are in that branch
14:19:14thomasjfoxperfect
14:20:45kugelbut I need the other load/store context implementation, ucontext isn't available on some platforms (deprecated in POSIX)
14:22:03 Quit JdGord (Quit: Bye)
14:22:32 Quit YPSY (*.net *.split)
14:22:32 Quit Llorean (*.net *.split)
14:22:33 Quit bertrik (*.net *.split)
14:22:34 Quit jfc^2 (*.net *.split)
14:22:34 Quit tmzt (*.net *.split)
14:22:38 Quit soap (*.net *.split)
14:22:40 Quit FOAD (*.net *.split)
14:22:42 Quit preglow (*.net *.split)
14:22:42 Quit Stummi (*.net *.split)
14:22:42 Quit bzed (*.net *.split)
14:22:43jhMikeSI recall looking into that and saying "f-it" because of dodgey availability and such
14:23:28kugelthere's a solution with sig[alt]stack which I implemented in a test application. according to gnu pth that should work on all unix/posix platforms
14:23:44jhMikeShow does sdl assist in deadlock debugging over other stuff? maybe something could be done there.
14:25:34kugelthinking about it, it should make no difference. the non-rockbox threads are still sdl threads (gdb has some handy thread debug utils), but the rockbox threads, no matter of if they are sdl threads or not, are all in switch_thread() (except running one)
14:27:22 Join YPSY [0] (~ypsy@geekpadawan.de)
14:27:22 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean)
14:27:22 Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
14:27:22 Join jfc^2 [0] (~john@dpc6682208002.direcpc.com)
14:27:22 Join tmzt [0] (~tmzt@76.211.0.152)
14:27:22 Join soap [0] (~soap@rockbox/staff/soap)
14:27:22 Join FOAD [0] (~dok@83.161.135.61)
14:27:22 Join preglow [0] (thomj@tvilling2.pvv.ntnu.no)
14:27:22 Join Stummi [0] (Stummi@rockbox/developer/Stummi)
14:27:22 Join bzed [0] (~bzed@devel.recluse.de)
14:27:32jhMikeSbut not in the same switch_thread call, so really, the return address could say where it is
14:27:40TheSevenbertrik: found part of the issue: cache coherency o.0
14:29:14 Quit bertrik (Quit: :tiuQ)
14:29:33 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl)
14:29:33 Quit bertrik (Changing host)
14:29:33 Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
14:29:40*jhMikeS hugs cache coherency
14:30:03kugelgdb can print the backtrace for each for sdl/pthreads
14:33:37 Quit JdGordon| (Ping timeout: 260 seconds)
14:34:12 Quit thegeek (Read error: Connection reset by peer)
14:34:22 Join thegeek [0] (~nnscript@132.108.34.95.customer.cdi.no)
14:35:27 Join afk [0] (~Dre@92.30.58.174)
14:35:37 Join feisar [0] (jljhook@irkki.fi)
14:36:50 Join Kitar|st [0] (~Kitarist@89.142.65.55)
14:37:53 Quit niekie (Remote host closed the connection)
14:38:00*jhMikeS wonders why taking out 3 functions and implementing one to substitute for one of the three is causing binsize to go up :\
14:38:15 Join niekie [0] (~niek@CAcert/Assurer/niekie)
14:38:56 Quit Dreamxtreme (Ping timeout: 260 seconds)
14:40:07 Nick feisar is now known as Guest20588 (jljhook@irkki.fi)
14:53:02kugel:(
14:53:11kugelmy code crashes unless I run it in gdb
14:53:16thomasjfox:o)
14:54:52thomasjfoxkugel: Regarding the __ASSEMBLER__ fix. You said you want to wrap it into some kind of ASMFLAGS and only activate it for the sdl-app.
14:55:01thomasjfoxI think it should always be active
14:57:44kugeli didn't say it should only be active for the sdl app
14:58:06thomasjfoxoh. Then I got you wrong :)
14:59:53kugelhah, my code crashes in 75% of the time, another 20% of the it freezes, the remaing 5% it works correctly :(
14:59:56 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com)
15:00
15:00:46thomasjfoxkugel: valgrind might help
15:02:03kugelwhen it freezes it's even impossible to break in gdb
15:04:00kugelbut that's possibly because I block sigint
15:05:28 Join moos [0] (moos@rockbox/staff/moos)
15:06:46n1skugel, thomasjfox we do enable gcc optimizations for the core in native builds, but not for the sim so that is probably why the app builds don't
15:07:41n1sthe codec makefiles override the core setting and don't account for sim builds, only cpu type
15:08:07 Quit Guest20588 (Read error: Operation timed out)
15:08:18n1susually with a special case for either arm or coldfire and a default case for the other
15:08:40n1sso sim will always take the default case
15:08:54n1sand apps unless they define the cpu thing in the make system
15:16:37kugelcan I block other threads (globally, without a mutex)?
15:17:27kugelconcurrently modifying the signal mask is a bit fishy
15:20:59thomasjfoxn1s: Should #define CPU_ARM be enough? That's what I already do
15:22:05thomasjfoxkugel: I'm not aware of a global thread block mechanism
15:24:34 Quit mystica555_ (Ping timeout: 255 seconds)
15:29:21n1sthomasjfox: your top makefile needs to set the CPU var iirc
15:30:23 Quit [Saint] (Quit: I'm only going to Heaven if it feels like Hell, I'm only going to Heaven if it tastes like caramel...)
15:32:05kugelsometimes sigsuspend() doesn't return :(
15:32:13 Quit eWill (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014])
15:33:28thomasjfox"If the action is to terminate the process then sigsuspend() will never return. If the action is to execute a signal-catching function, then sigsuspend() will return after the signal-catching function returns"
15:34:00n1sah, i was wrong, sims set the makefile CPU var the same as targets but the app sets it to "hosted"
15:34:49 Join [Saint] [0] (S_a_i_n_t@203.184.0.95)
15:34:55thomasjfoxn1s: also simcc() in tools/configure filters out "-O"
15:36:54thomasjfoxandroidcc() doesn't ;)
15:41:37[Saint]Hmmm, there's something that annoys me about pictureflow WPS integration but it's beyond my ability to fix it. I dislike how if you launch playback with the database, and then open pictureflow using thw WPS hotkey and select a different track (actually, you don't even need to select a different track) and return to the WPS if you then (or sometime thereafter) stop playback from the WPS it launches pictureflow again. :/
15:42:41jhMikeS[Saint]: once you enter pictureflow, it never goes away, and every press to browse files ends up back in pf :)
15:43:28[Saint]IMO, if playback was started with pictureflow initially then that would be desired behaviour, but if playback is launched from the DB it should return to the DB on stop even if pictureflow has been launched from the WPS afterward in the same play session.
15:44:49[Saint]and yes, the behaviour you describe jhMikeS I have experienced also...it's fucking annoying but far beyond my ability to fix.
15:45:00 Join japc [0] (~japc@194.65.5.235)
15:45:56LloreanWouldn't the desired behaviour be for stop to take you to either wherever "follow playlist" brings you if that's enabled, and wherever you last returned to the WPS from otherwise (which isn't necessarily where you started playback from). I don't see where you started playback mattering except for the first time you leave the WPS, since then it's where you last entered the WPS from.
15:45:57jhMikeSWhen it comes to that stuff, I put JdGordon on the spot since it's not my area of greatest familiarity either
15:48:06jhMikeSin that case, it's where you entered the WPS from always
15:49:35***Saving seen data "./dancer.seen"
15:49:55kugelthomasjfox: right, but in my case I wait for a single signal, all others are blocked, and I installed a signal handler for that signal
15:50:53[Saint]well, yeah...what I'm saying is that if you launch playback with the DB then if you then stop playback (even if you've used pictureflow WPS integration at some point after launching playback from the DB) it should either return to the database menu or whereever "follow playlist" takes you if it's enabled. And that if you launch playback by starting the pictureflow plugin manually, and then stop playnack in the WPS, it should return you to pictureflow.
15:52:16[Saint]the way it works now with pictureflow integration (especially with follow playlist enabled) is f*%$*ng crazy.
15:52:30LloreanI think that if you start in DB, then go to the WPS, then to pictureflow, add tracks via pictureflow, then go from PF directly to the WPS, it's reasonable to end up in PF when you stop playback.
15:52:38jhMikeS[Saint]: makes sense, I was just saying all those seem to amount to "go back to how you got there last time"
15:52:44LloreanIf you instead go from PF to the DB *then *back to the WPS, then I'd expect to end up in the DB after playback stops
15:53:16kugelthomasjfox: I think sigsuspend isn't reliable in a multi threaded environment
15:54:24LloreanUnless it's like... impossible to go from PF->DB without passing through the WPS if you've launched it from the WPS (which sounds like a different sort of problem)
15:54:32[Saint]Llorean: with your first statement, yes. that is entirely reasonable, except currently, even if you went to the database after adding tracks from pictureflow, and added tracks from the database *then* stopped playback in the WPS it will dump you in pictureflow on stop. :/
15:54:49Llorean[Saint]: Yes, that sounds like a bug.
15:54:55thomasjfoxkugel: http://www.linuxquestions.org/questions/programming-9/sigsuspend-problem-429245/
15:55:36Llorean[Saint]: Your description made it sound like you were going DB->WPS->PF->WPS then ending up in PF and being surprised, which doesn't seem unreasonable to me. But if it does what you've just said, that's definitely bad.
15:56:23[Saint]"if pictureflow opens in the current playback session, regardless of where playback was started it assumes you want to go back to the pictureflow when playback stops." is the easiest way I can describe it I think.
15:57:20LloreanI'd say "if picturefulow opens in the current playback session, regardless of where you most recently entered the WPS from it assumes you want to go back to pictureflow when playback stops"
15:57:41[Saint]ah, yes...that is more clear.
15:57:44LloreanI wouldn't talk about where playback started since that ends up a bit confusing.
15:58:21LloreanIf you do DB->WPS->PF->WPS->DB->WPS then hit "select" does it take you to PF or DB? Basically, is it only on stop, or every time you try to exit the WPS?
15:58:55[Saint]It's not too much of an annoyance, just a small thing. I don't use pictureflow much because I have too many albums for it to be practical.
15:59:10[Saint]Llorean: Only on stop through the WPS I believe.
15:59:57LloreanThat seems weird. I'd expect the "user hit select" and "music stopped" logic for where to return you to be exactly identical (except possibly in the case of follow playback, since I'm not sure where I'd expect to be at the end of my playlist)
16:00
16:06:12 Join feisar [0] (jljhook@irkki.fi)
16:06:38 Nick feisar is now known as Guest49597 (jljhook@irkki.fi)
16:07:11 Join reppart [0] (~Trapper@203-158-41-76.dyn.iinet.net.au)
16:07:32 Part LinusN
16:09:38kugelthomasjfox: I also think my signal is delivered before sigsuspend
16:23:05 Quit reppart (Quit: cya on the dark side of the moon.)
16:30:15 Quit Guest49597 (Ping timeout: 265 seconds)
16:30:41kugelhm, seems to work now
16:33:42kugelgrml, SIGALRM seems to work, but SIGUSR1 doesn't
16:38:59kugelright, the same code with SIGALRM always works, but crashes half of the time with SIGUSRx
16:45:14 Quit anewuser (Ping timeout: 240 seconds)
16:47:49 Join anewuser [0] (anewuser@unaffiliated/anewuser)
16:48:48 Quit tchan (Quit: WeeChat 0.3.3-dev)
16:49:46 Join TheSphinX^ [0] (~cold@p54A5B62E.dip.t-dialin.net)
16:51:32*Strife89 wonders if there's a quicker way back to the WPS on the Clip+ then [Home] -> Main Menu
16:51:56 Quit kevku (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/)
16:52:24 Join kevku [0] (~kevku@2001:7d0:0:f000::135d)
16:53:13*pixelma wonders if Strife89 took a look into the manual
16:53:24*Strife89 did
16:53:38Strife89Double-checked, even
16:55:49 Quit GodEater (Read error: Operation timed out)
16:55:53pixelmaaccording to http://download.rockbox.org/daily/manual/rockbox-sansaclipplus/rockbox-buildch4.html#x7-400004.1.1 Home+Select (I can only rely on this info though, don't have a Clip myself)
16:55:55 Join GodEater [0] (~bibble@rockbox/staff/GodEater)
16:56:09pixelmaand if I understand correctly what you want
16:56:36 Join blast007 [0] (~blast007@bzflag/developer/Blast)
16:56:40Strife89Ah, that does it.
16:57:10Strife89I figured it'd be somewhere in getting started, since the key combo can be used in a lot of places.
16:57:24 Quit japc (Quit: Ex-Chat)
16:57:39Strife89Thanks.
16:57:43 Quit mortalscan (Ping timeout: 264 seconds)
16:57:56kugel\o/
16:58:53kugelI assume SDL was using SIGUSRx, pthread_kill works better than plain kill
16:59:35 Join tchan [0] (~tchan@lunar-linux/developer/tchan)
17:00
17:01:49*TheSeven *hates* loud white noise
17:02:30 Quit stoffel (Ping timeout: 250 seconds)
17:04:38thomasjfoxkugel: I pushed a change to the maemo-rb repo named "Only disable optimizations for non-app builds". Might be worth upstreaming.
17:04:55kugelI'll have a look
17:05:03thomasjfoxrepo.or.cz's web interface is down so I can't provide a URL
17:05:09TheSevenLadies and Gentlemen...
17:05:18kugelthough I don't know why we don't set it for sim builds
17:05:37thomasjfoxit's better to debug?
17:05:46kugelI'm using git as well. I've cloned your repo long ago :p
17:07:28*TheSeven wonders if he should write a main, as it's not really rockbox code yet :)
17:07:34TheSevenlinuxstb: ping
17:14:59 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201)
17:15:04kugelTheSeven: I think you should
17:15:23TheSevens/main/mail/ (wtf)
17:16:14TheSeventhis beast seems to need big-endian PCM data... is that a problem for our architecture?
17:16:26TheSevenif yes, i can just let the DMA controller do the swapping
17:20:10TheSevenok, the DMA swapping seems to work
17:21:53 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com)
17:24:06TheSevenoh yeah, and no spurious IRQs any more
17:24:22kugelgevaerts: I've integrated my threading (via sigaltstack) into rockbox, that should even work with glibc on the n900
17:24:33 Join mgue [0] (~mgue@pD95E6EDA.dip.t-dialin.net)
17:26:38 Join feisar [0] (jljhook@irkki.fi)
17:27:04 Nick feisar is now known as Guest66425 (jljhook@irkki.fi)
17:27:07gevaertskugel: nice
17:28:00kugelshould I drop the swapcontext() one?
17:28:46gevaertsNot sure. In the end we don't want seventeen threading options of course...
17:29:09 Join froggyman [0] (~seth@98.115.0.7)
17:29:09 Quit froggyman (Changing host)
17:29:09 Join froggyman [0] (~seth@unaffiliated/froggyman)
17:29:10gevaertsswapcontext is the one that only works on uninteresting CPUs, right?
17:29:31kugelx86 and x86_64? yea
17:30:30kugelthomasjfox: re: your sdl lcd speed up
17:31:12kugelthe sdl wiki says zoom function uses a static buffer and is not thread safe. I suggest protecting the updates with a mutex
17:31:55thomasjfoxis lcd_update called from places at the same time?
17:32:22kugelthe scrolling engine also does updates
17:32:22gevaertskugel: x86 and x86_64 would make that sim-only in the short to medium term I guess. Better drop it I'd say
17:33:14 Quit benedikt93 (Quit: Bye ;))
17:33:14thomasjfoxI thought about moving the update code to an own thread, so we can slow down updates to once a second if the app is not in input focus
17:33:14kugelah no, should be no problem since we do cooperative threads
17:33:14kugelI assume there'll be no switch_thread() call from within that zoom function
17:33:14thomasjfoxso every lcd_udpate call just sets an "please-update-me" thread
17:33:19thomasjfoxno switch_thread :)
17:33:44thomasjfoxplease-update-me flag of course
17:34:18kugelI believe if you're not in the wps (and there's no scrolling line) lcd updates happen only once a second
17:34:34thomasjfoxalso we could limit the framerate to f.e. 25 FPS. No need for 80FPS lcd updates in the wps...
17:34:52kugelthe wps does 5 fps IIRC
17:35:05gevaertsIt does more for peakmeters
17:35:09kugelupto 25 with scrolling lines or a peakmeter
17:35:26thomasjfoxLast time I counted is was way more than 60...
17:36:53kugelthat would be strange
17:37:04thomasjfoxkugel: Cherry-pick commit 337285899e335e3d2140ba36d01c013302a6ef0f and 05fa91a5af3fd5fd00a24ea36e7e0b7ee3501e06 for the -D__ASSEMBLER__ fix
17:37:29thomasjfoxLet me put it this way: lcd_update() was called that often
17:37:57thomasjfoxI'll put the counter back in there, just a sec
17:38:33kugelgevaerts: I'll drop it, but won't delete my ucontext_thread branch so the code isn't lost
17:39:42 Quit mc2739 (Read error: Connection reset by peer)
17:39:45 Join mc2739_ [0] (~mc2739@rockbox/developer/mc2739)
17:42:58 Nick mc2739_ is now known as mc2739 (~mc2739@rockbox/developer/mc2739)
17:44:15 Join mortalscan [0] (~mortalsca@109.169.55.155)
17:45:44 Quit Guest66425 (Read error: Operation timed out)
17:49:36***Saving seen data "./dancer.seen"
17:51:10thomasjfoxkugel: wps does ~44 lcd_update() calls per second, most of them are fullscreen ones
17:51:45 Quit froggyman (Quit: Ex-Chat)
17:55:09[Saint]is there scrolling text?
17:55:17[Saint]or a peak meter?
17:55:35[Saint]if not, that seems quite wrong.
17:56:34thomasjfoxpeak meter
17:56:43[Saint]that will explain it then.
17:57:18[Saint]the peak meter needs the screen to update that frequently...it can even go quite a bit faster I believe.
17:57:31thomasjfoxstill worth limiting :)
17:58:07[Saint]Not really.
17:58:30thomasjfoxIt pushed the n900 CPU to the max
17:58:46thomasjfoxFullscreen updates are very expensive
17:58:55[Saint]animations need to be able to call an apdate at least every .1second I believe.
17:59:12[Saint]well, it is possible to do so.
17:59:20TheSevenbut why should a peak meter do fullscreen updates?
17:59:48thomasjfoxThe SDL lcd_update() routine is quite "clever": lcd_update_rect(0, 0, LCD_WIDTH, LCD_HEIGHT);
17:59:53[Saint]as I don't think viewports can be updated independantly.
18:00
18:00:04[Saint]TheSeven: ^
18:00:20[Saint]I believe that is the case, I may be quite wrong though.
18:00:25TheSevensounds like something that could be improved...
18:01:03[Saint]I think the screen updates as much as it needs to depending on the elements it's displaying.
18:01:46thomasjfoxLots of code just calls lcd_update() and not lcd_update_rect()
18:01:46[Saint]peak meters, scrolling text, and animations using sublines and bitmaps can cause quite a few updates.
18:04:40 Join Kitr88 [0] (Kitarist@BSN-182-93-224.dial-up.dsl.siol.net)
18:06:17TheSevenlinuxstb: the audio code i used: http://pastie.org/1408942
18:07:11 Quit Kitar|st (Ping timeout: 240 seconds)
18:07:45 Join Kitar|st [0] (~Kitarist@BSN-210-247-230.dial-up.dsl.siol.net)
18:08:51 Quit Kitr88 (Ping timeout: 240 seconds)
18:09:19 Join Kitr88 [0] (Kitarist@BSN-182-108-152.dial-up.dsl.siol.net)
18:09:41kugelthomasjfox: the peakmeter will look at low fps
18:09:47kugel+bad
18:10:00kugelI suggest you port cabbiev2 without peakmeter :)
18:10:52thomasjfoxThat would also make gevaerts happy ;)
18:11:07 Quit BlakeJohnson86 (Read error: Connection reset by peer)
18:11:13*gevaerts is *always* happy
18:11:34TheSevencabbiev2 has a peakmeter?
18:11:35 Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net)
18:11:38*TheSeven has never seen one
18:11:42TheSevenjust on some targets?
18:11:54 Quit Kitar|st (Ping timeout: 240 seconds)
18:11:57TeruFSXthe default theme has a peak meter, I think
18:12:06TeruFSXactually I know it does.
18:13:26kugelTheSeven: it doesn't
18:14:00kugelthomasjfox: I pushed new ucontext_thread work, I will probably commit it in this form
18:15:08thomasjfoxkugel: What's the git url? The web interface is still down. Will add a new git remote...
18:15:10kugelyou'd need to adjust simcc() to leave or set thread_support to ASSEMBLER_THREADS in configure
18:15:42 Quit robin0800 (Remote host closed the connection)
18:16:10kugelhm, url = git+ssh://repo.or.cz/srv/git/kugel-rb.git is in my .git/config
18:16:25kugeldon't know if you can pull from it without my ssh key :)
18:16:37thomasjfoxforget my request
18:16:44kugelgit://repo.or.cz/kugel-rb.git should work
18:16:48thomasjfoxI just need to change my URL from maemo-rb to kugel-rb :)
18:17:09kugelright, I just found that out too :P
18:18:23thomasjfoxI'll just give the new code a spin
18:20:10[Saint]is anyone able to build me an SVN bootloader for V1 Fuze?
18:20:14[Saint]please.
18:23:49thomasjfoxkugel: Is the "ignoring REUC extension" intentional?
18:24:16kugelwhat's the REUC extention?
18:25:34thomasjfoxI have no idea
18:25:53kugelwhat are you refering to?
18:26:23thomasjfoxI see at the top of "make reconf" after merging the ucontext_thread branch into "maemo-port"
18:27:49thomasjfoxkugel: The new code runs fine so far. Add the ASSEMBLER_THREADS define is next
18:28:03CIA-7New commit by kugel (r28913): Redo r28026 so that all .S files get the __ASSEMBLER__ define. ...
18:28:15kugelare you using the asm or sigaltstack threads now?
18:28:28kugelit defaults to sigaltstack without any changes
18:28:35thomasjfoxI guess signalstack
18:28:44thomasjfoxAtleast gdb interrupt a lot at SIGUSR1 :)
18:29:03thomasjfoxLet me try ASSEMBLER_THREADS
18:29:06kugelhm, can that be fixed?
18:29:16 Join casainho [0] (~chatzilla@2.81.133.218)
18:29:39thomasjfoxtell this to gdb: "handle SIGUSR1 nostop"
18:30:20kugeli mean without needing gdb commands
18:30:39gevaertsSure. Don't run it in gdb :)
18:31:08kugelpth also uses SIGUSR1 without gdb acting up
18:32:34CIA-7r28913 build result: All green
18:34:11kugelcontext switchting is now almost equally cheap with or without the asm; in the sigaltstack way a switch is just a set/longjmp and that's no different from what the asm does
18:34:38thomasjfoxkugel: "thread_support" gets initialized to "ASSEMBLER_THREADS" in tools/configure
18:35:11kugelyes, but simcc changes it
18:35:21kugeli mean it defaults to sigaltstack in sdl builds, sorry
18:37:57 Quit GeekShadow (Quit: The cake is a lie !)
18:39:38kugelthomasjfox: great that you confirmed sigaltstack thread works on the n900 :)
18:39:52 Join WonTu [0] (~WonTu@p57B54176.dip.t-dialin.net)
18:40:06 Part WonTu
18:40:38thomasjfoxkugel: ASSEMBLER_THREADS works, too. Good work!
18:41:00thomasjfoxhmm
18:41:14thomasjfoxthe thread_support detection in simcc() is at the end of the file
18:41:57thomasjfoxThis will need another maemo detection section. Or could we do the thread "model" detection earlier?
18:42:21kugelgdb only breaks for unhandled signals, right?
18:42:43kugelperhaps it doesn't see that I unignore SIGUSR1 with sigsuspend()
18:44:03 Join feisar [0] (jljhook@irkki.fi)
18:44:29 Nick feisar is now known as Guest81152 (jljhook@irkki.fi)
18:44:31thomasjfoxgdb breaks for some signals by default
18:45:59kugelit's annoying
18:48:09 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow)
18:50:55thomasjfoxkugel: Ups, I was too fast with the ASSEMBLER_THREADS: I did a "make reconf" and forgot the make call
18:51:02thomasjfoxASSEMBLER_THREAD current hang on startup
18:51:35kugeldid you make other changes?
18:51:40thomasjfoxnope
18:51:44thomasjfoxno to the threading
18:52:00thomasjfoxlet me give you a "backtrace":
18:52:41thomasjfoxthread 1: scroll_thread -> sleep -> switch_thread -> make_context -> set_irq_level(level=1) -> SDL_mutex
18:53:05thomasjfoxthread 2: tick_timer -> sim_enter_irq_handler()
18:53:07thomasjfoxthread 3
18:53:29kugelmake_context() is sigaltstack threads
18:53:33thomasjfoxthread 3: gui_message_loop -> sim_enter_irq_handler
18:54:33thomasjfoxI just harcoded thread_support="ASSEMBLER_THREADS" in simcc
18:54:39thomasjfoxLet me do a clean rebuild
18:54:53kugelis that my plain branch without changes for maemo?
18:54:55 Join Rob2222 [0] (~Miranda@p4FFF28AB.dip.t-dialin.net)
18:55:22thomasjfoxit's my maemo-port branch + your plain branch
18:55:36thomasjfoxI keep the native arm threads code in a separate branch
18:55:46 Join stoffel [0] (~quassel@p57B4BFCC.dip.t-dialin.net)
18:55:53thomasjfox(which I just rebase on top of maemo-port)
18:57:33thomasjfoxhmm. Either the merge is messed up or "thread-arm.c" is not in there
18:58:09thomasjfoxThis file exists: target/arm/thread-arm.c
18:58:48thomasjfoxI guess the include path is not correct yet
19:00
19:00:23 Quit Guest81152 (Ping timeout: 240 seconds)
19:00:24kugelyou need thread-maemo-arm.c or so
19:00:52kugelgive me a second, I'll push another commit
19:02:47kugeldone
19:03:10kugelI moved thread-android-arm.c, it should be automagically picked up for the maemo port now
19:06:28thomasjfoxthread_arm.c, line 95: warning: implict declaraction of function wait_for_interrupt
19:07:24thomasjfoxBesides that it runs :)
19:07:26kugeladd the prototype to system-sdl.h
19:09:09thomasjfoxAs you said earlier, performance wise there is no noticable difference between the sigaltstack and assembler threads
19:10:07 Join komputes [0] (~komputes@ubuntu/member/komputes)
19:10:07kugelthe stack sizes are larger with sigaltstack, as some of the stack is used by the OS for delivering the signal so asm is still prefered
19:11:38thomasjfoxok
19:11:45gevaertsWhat sort of size difference is that?
19:12:01 Join Kitar|st [0] (~Kitarist@BSN-143-98-26.dial-up.dsl.siol.net)
19:13:19kugel2k
19:13:44gevaertsper stack I assume
19:13:47kugelyep
19:14:10gevaertsSo about 20 to 30k for the entire thing
19:14:39thomasjfoxI gotta go
19:14:40thomasjfoxCu
19:14:49*gevaerts waves
19:15:06 Quit thomasjfox (Remote host closed the connection)
19:15:50 Quit Kitr88 (Ping timeout: 240 seconds)
19:18:47 Quit moos (*.net *.split)
19:18:48 Quit blast007 (*.net *.split)
19:18:48 Quit YPSY (*.net *.split)
19:18:48 Quit Llorean (*.net *.split)
19:18:49 Quit jfc^2 (*.net *.split)
19:18:49 Quit tmzt (*.net *.split)
19:18:53 Quit soap (*.net *.split)
19:18:55 Quit FOAD (*.net *.split)
19:18:57 Quit preglow (*.net *.split)
19:18:58 Quit Stummi (*.net *.split)
19:18:58 Quit bzed (*.net *.split)
19:19:22B4gderTheSeven: congrats on the classic progress! nice work!
19:20:04kugelgevaerts: I need to go higher with the stack, I/O needs a lot more on my system
19:20:58kugelbut the OS needs 2k to deliver the signal. the rest is ours
19:21:05gevaertskugel: to be honest, I wonder if for the application on a memory-managed system we shouldn't do the usual thing and just use multi-megabyte stacks
19:21:21 Quit Kitar|st (Ping timeout: 265 seconds)
19:21:27gevaertsAs long as you don't use the space they don't actually get allocated anyway, and we *never* have problems
19:21:35kugelstatic allocations aren't managed are they?
19:21:45 Quit evilnick (Quit: Leaving)
19:22:04TheSeventhey are, but managing them doesn't help much due to typically scattered access patterns
19:22:07gevaertsI'm pretty sure bss will behave the same
19:22:19TheSevenso if you have a huge static buffer, it won't be allocated until it's used
19:22:28TheSevenbut if it's lots of small crap, that won't work
19:22:31kugelthe sdl app crashed due to static allocations on my mini2440
19:22:32 Join blast007 [0] (~blast007@bzflag/developer/Blast)
19:22:46gevaertsWe'd have to disable the stack filling for usage checking of course
19:23:09TheSevendo we zero bss explicitly on memory-managed systems?
19:23:15TheSevenif yes, that will probably kill the management :)
19:23:25kugelthe bss is always zero'd
19:23:35gevaertsright
19:24:02gevaertsThat does complicate things a bit
19:24:23gevaertsmalloc()ing the stacks is of course easy, but that means extra code and #ifdefs
19:24:54kugelnot a fan :)
19:24:56TheSevendoes malloc also do lazy allocation?
19:25:11gevaertsmalloc() doesn't care
19:25:36TheSeveni.e. malloc is just an address space thing, that doesn't care about the mapping?
19:26:53gevaertsAs far as I understand, it will either use brk() to increase the heap, which I think is a pure address space thing, or mmap some more address space, which also is pure address space. Of course malloc metadata is real
19:28:07gevaerts(on linux)
19:29:02 Join toffe82 [0] (~chatzilla@adsl-71-154-235-169.dsl.frs2ca.sbcglobal.net)
19:29:15 Join evilnick [0] (~evilnick@rockbox/staff/evilnick)
19:30:49 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com)
19:34:50kugelhmm, gcc 3.4.6 for arm doesn't even support eabi, right? I'm surprised rockbox works with that compiler
19:38:08 Join Kitar|st [0] (~Kitarist@BSN-143-98-26.dial-up.dsl.siol.net)
19:39:40 Join moos [0] (moos@rockbox/staff/moos)
19:40:49 Join froggyman [0] (~seth@98.115.0.7)
19:40:50 Quit froggyman (Changing host)
19:40:50 Join froggyman [0] (~seth@unaffiliated/froggyman)
19:42:52 Quit Kitar|st (Ping timeout: 240 seconds)
19:46:20 Join jfc^2 [0] (~john@dpc6682208002.direcpc.com)
19:47:57 Join Llorean [0] (~DarkkOne@99-68-45-56.lightspeed.hstntx.sbcglobal.net)
19:48:36 Join bzed [0] (~bzed@devel.recluse.de)
19:49:40***Saving seen data "./dancer.seen"
19:49:42 Join Stummi [0] (Stummi@rockbox/developer/Stummi)
19:49:47 Join Kitar|st [0] (Kitarist@BSN-143-67-70.dial-up.dsl.siol.net)
19:51:08 Join preglow [0] (thomj@tvilling2.pvv.ntnu.no)
19:51:13 Join FOAD [0] (~dok@83.161.135.61)
19:51:30 Join tmzt [0] (~tmzt@76.211.0.152)
19:56:14 Join CaptainKewl [0] (~captainke@ool-45738e17.dyn.optonline.net)
19:57:34 Join feisar [0] (jljhook@irkki.fi)
19:58:00 Nick feisar is now known as Guest64565 (jljhook@irkki.fi)
20:00
20:00:02 Join Horscht [0] (~Horschti@xbmc/user/horscht)
20:04:06 Join soap [0] (~soap@cpe-76-181-78-156.columbus.res.rr.com)
20:04:06 Quit soap (Changing host)
20:04:06 Join soap [0] (~soap@rockbox/staff/soap)
20:07:24 Join YPSY [0] (~ypsy@geekpadawan.de)
20:08:05 Quit stoffel (Ping timeout: 255 seconds)
20:13:54 Quit Guest64565 (Ping timeout: 246 seconds)
20:14:11 Quit CaptainKewl (Quit: ( www.nnscript.com :: NoNameScript 4.21 :: www.esnation.com ))
20:14:55 Quit froggyman (Read error: Connection reset by peer)
20:15:12 Join froggyman [0] (~seth@unaffiliated/froggyman)
20:40:51 Quit moos (Ping timeout: 246 seconds)
20:44:22n1shmm, i wonder how we could manage a toolchain switch in the buildsystem
20:44:39 Join moos [0] (~moos@rockbox/staff/moos)
20:45:38n1scould the buildmaster check the version of the compiler and only hand out builds to clients with the correct version?
20:47:02 Join toffe82_ [0] (~chatzilla@adsl-71-154-235-169.dsl.frs2ca.sbcglobal.net)
20:48:09 Quit toffe82 (Ping timeout: 260 seconds)
20:50:44kugeln1s: that should be no problem
20:51:01 Quit froggyman (Remote host closed the connection)
20:51:14n1sok, so we just need to do that and have a little coordination
20:51:41 Join froggyman [0] (~seth@unaffiliated/froggyman)
21:00
21:05:49 Join leBMD [0] (~chatzilla@ip68-97-25-113.ok.ok.cox.net)
21:05:55leBMDHowdy, guys
21:07:04leBMDSo, I'm pretty sure that convincing my mom to play freedoom on her Sansa Clip was the best idea I've ever had.
21:07:35n1sglad to hear it
21:08:14leBMDafter a while of staring at the blue and orange static, you seem to enter a zen-like state in which you can actually tell some of what's going on.
21:10:14[Saint]It's torture, pure torture.
21:10:38[Saint]I guess it's kinda cool if you've not seen it running on a colour target with a decent screen.
21:10:47 Join feisar [0] (jljhook@irkki.fi)
21:11:10n1sor even a geyscale target
21:11:13 Nick feisar is now known as Guest71305 (jljhook@irkki.fi)
21:11:47leBMDI've got a Fuze, so the comparison is hilarious.
21:16:09 Join thomasjfox [0] (~thomasjfo@dslb-088-065-026-072.pools.arcor-ip.net)
21:20:36bertrikwe have doom on the clip just to show that it can, not to actually play it (private opinion, may not reflect other rockbox developers')
21:21:09[Saint]bertrik: Yes, I've always seen it as more of a novelt than anything else.
21:21:46leBMDor an amazing zen experience. That's what I use it for.
21:22:03leBMDOh, btw, pictureflow actually doesn't look half bad!
21:22:24 Quit Guest71305 (Ping timeout: 240 seconds)
21:27:55 Quit toffe82_ (Read error: Connection reset by peer)
21:28:22 Join toffe82 [0] (~chatzilla@adsl-75-23-149-20.dsl.frs2ca.sbcglobal.net)
21:42:56leBMDmy mom and I just compared mp3 players, and I'm pretty sure that clip rockdoom is far superior to fuze rockdoom.
21:49:44***Saving seen data "./dancer.seen"
21:52:22 Quit froggyman (Quit: Ex-Chat)
22:00
22:01:24 Quit toffe82 (Read error: Connection reset by peer)
22:02:04 Join toffe82 [0] (~chatzilla@adsl-71-132-80-172.dsl.sntc01.pacbell.net)
22:04:50 Quit Llorean (Changing host)
22:04:50 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean)
22:07:40 Quit leBMD (Quit: yeah seeya)
22:09:19 Quit toffe82 (Ping timeout: 250 seconds)
22:10:09 Join toffe82 [0] (~chatzilla@adsl-75-37-119-209.dsl.frs2ca.sbcglobal.net)
22:12:35 Join toffe82_ [0] (~chatzilla@adsl-75-37-119-128.dsl.frs2ca.sbcglobal.net)
22:14:31 Quit toffe82 (Ping timeout: 250 seconds)
22:17:48 Quit toffe82_ (Ping timeout: 246 seconds)
22:19:20 Join feisar [0] (jljhook@irkki.fi)
22:19:47 Nick feisar is now known as Guest39623 (jljhook@irkki.fi)
22:20:24 Join Topy44 [0] (~Topy44@89.207.248.177)
22:22:28 Join toffe82_ [0] (~chatzilla@ppp-69-238-94-168.dsl.frs2ca.pacbell.net)
22:24:19 Quit Guest39623 (Ping timeout: 276 seconds)
22:24:34 Join toffe82 [0] (~chatzilla@adsl-71-154-235-222.dsl.frs2ca.sbcglobal.net)
22:25:04soapBuschel, I'm back now.
22:25:17soapI'll test this evening.
22:27:43 Quit toffe82_ (Ping timeout: 276 seconds)
22:28:02kugelthomasjfox: you remvoed the SDL_LockSurface calls. was there a reason for this?
22:28:25thomasjfoxno need for them if we don't manipulate surface->pixels
22:28:36 Join toffe82_ [0] (~chatzilla@70.235.225.25)
22:29:03kugelwould it be faster if we did?
22:29:36thomasjfoxThen you would have to implement the "zooming" done SDL_FillRectangle manually
22:29:42thomasjfoxdone by
22:30:10 Quit toffe82 (Ping timeout: 276 seconds)
22:30:54 Join toffe82 [0] (~chatzilla@70.235.225.25)
22:34:06 Quit toffe82_ (Ping timeout: 240 seconds)
22:34:39 Join toffe82_ [0] (~chatzilla@adsl-71-132-87-202.dsl.sntc01.pacbell.net)
22:34:39 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93)
22:37:16 Join toffe82__ [0] (~chatzilla@adsl-70-235-227-125.dsl.frs2ca.sbcglobal.net)
22:37:23 Join Buschel [0] (~chatzilla@p54B67E1E.dip.t-dialin.net)
22:37:46 Quit toffe82 (Ping timeout: 240 seconds)
22:38:28Buschelsoap: good to see you're back :)
22:39:12 Quit toffe82_ (Ping timeout: 255 seconds)
22:39:53 Join toffe82 [0] (~chatzilla@adsl-70-235-227-125.dsl.frs2ca.sbcglobal.net)
22:43:10 Quit toffe82__ (Ping timeout: 276 seconds)
22:45:04 Join toffe82_ [0] (~chatzilla@adsl-71-154-232-139.dsl.frs2ca.sbcglobal.net)
22:47:12 Quit toffe82 (Ping timeout: 246 seconds)
22:48:23 Join GeekShad0w [0] (~Antoine@93.21.159.10)
22:48:44 Quit r0b- (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com ))
22:48:52 Join Keripo1 [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com)
22:49:19 Quit fyrestorm (Quit: lamers envy me like they envy bill g -- main boot xp, just the way it should be!)
22:51:01 Join toffe82 [0] (~chatzilla@adsl-71-154-232-139.dsl.frs2ca.sbcglobal.net)
22:51:44 Quit Keripo (Ping timeout: 272 seconds)
22:53:30 Join toffe82__ [0] (~chatzilla@adsl-75-37-119-236.dsl.frs2ca.sbcglobal.net)
22:54:12 Quit toffe82_ (Ping timeout: 246 seconds)
22:56:18 Join Greek_o_nikos [0] (~linuxaiz@178.128.220.24)
22:56:42 Part Greek_o_nikos ("Leaving.")
22:56:50 Quit toffe82 (Ping timeout: 276 seconds)
22:59:44thomasjfoxkugel: checkwps doesn't build for the SDL/maemo target
22:59:50thomasjfoxIt's missing the system-sdl.h
23:00
23:00:20thomasjfox$t_cpu in tools/configure is empty for "checkwps" and therefore the include paths to the SDL target don't get included
23:04:26 Join toffe82 [0] (~chatzilla@adsl-70-235-227-88.dsl.frs2ca.sbcglobal.net)
23:04:29kugelit's nasty that checkwps needs sdl bits at all
23:04:39 Quit bertrik (Ping timeout: 240 seconds)
23:05:18thomasjfoxSeems related to PLATFORM_SDL defines
23:05:47kugelIIRC it mainly needs uisimulator/common/io.c
23:07:15thomasjfoxThis one sucks in thread-sdl.h & co
23:07:52 Quit toffe82__ (Ping timeout: 276 seconds)
23:08:19*thomasjfox is pleased to see the cabbie 320x480 theme hacked into 800x480 on his N900
23:08:39CIA-7New commit by kugel (r28914): Vastly increase speed of SDL screen updates for RGB565. ...
23:09:43kugelthomasjfox: I guess it kind of works?
23:10:39CIA-7r28914 build result: All green
23:10:41thomasjfoxI had to adjust the image size in gimp and fill the backdrop with a gradient
23:10:56 Join FlynDice [0] (~FlynDice@64.134.130.0)
23:11:59 Join JdGord [0] (~jonno@114.75.104.10)
23:12:26thomasjfoxkugel: Good you fixed unused parameter warnings. I didn't want to send another patch update for this minor thing.
23:13:02kugelno problem
23:13:08*thomasjfox wonders how the build the new ThemeEditor
23:13:43thomasjfoxcd utils/themeeditor ; qmake results in lots of error messages
23:14:54kugelthomasjfox: I'm excited to see your work live tomorrow :)
23:14:57 Join toffe82_ [0] (~chatzilla@adsl-70-235-227-88.dsl.frs2ca.sbcglobal.net)
23:15:23gevaertsthomasjfox: builds fine here
23:15:25 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl)
23:15:26 Quit bertrik (Changing host)
23:15:26 Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
23:15:48kugeli just need to be nice to gevaerts :p
23:15:56thomasjfoxgevaerts: Which qt version do yo run? x86 or x86_64?
23:16:20gevaertsthomasjfox: x86_64 on debian unstable
23:16:38gevaertsqt 4.6.3 apparently
23:17:19thomasjfoxI'm also on 4.6.3 / x86_64
23:17:50 Quit toffe82 (Ping timeout: 240 seconds)
23:17:53gevaertsWhat does qmake −−version say?
23:19:17thomasjfoxOk, I have to run qmake-qt4
23:19:26thomasjfoxqmake defaults to qt 3.x
23:20:39 Join feisar [0] (jljhook@irkki.fi)
23:21:06 Nick feisar is now known as Guest10180 (jljhook@irkki.fi)
23:21:56FlynDicebertrik: re: SD CMD7 response when deselecting card. See page 49 of SD Spec section 4.7.4. I think this means you only get an R1b response from the card if you are selecting it and no response if deselecting.
23:25:00 Quit Guest10180 (Ping timeout: 246 seconds)
23:25:03bertrikthanks
23:27:04 Quit FlynDice (Remote host closed the connection)
23:31:23 Quit komputes (Quit: I haven't slept for ten days, because that would be too long.)
23:37:29 Quit [Saint] (Quit: I'm only going to Heaven if it feels like Hell, I'm only going to Heaven if it tastes like caramel...)
23:38:13thomasjfoxgevaerts: Do you also own a Nokia N8xx device?
23:38:24gevaertsno
23:38:37kugelthomasjfox: maybe I'm bored tomorrow and can have a look at cabbie. no promise though
23:38:41gevaertsI've seen one :)
23:38:50thomasjfox:)
23:39:05thomasjfoxkugel: That would be nice!
23:39:30thomasjfoxWould be nice to get a CPU usage for that
23:40:02kugelthomasjfox: it's questionable if it even runs, considering the old gcc which has no eabi
23:40:54gevaertsIs eabi really relevant?
23:40:54thomasjfoxkugel: It builds just fine. Let me try what happens when I just copy the binard to the n900
23:42:02the_KyleOops. I think I found a bug in the Speex codec. I'm not sure if it's long files or another problem.
23:42:28kugelgevaerts: I don't know for sure
23:43:04 Join [Saint] [0] (S_a_i_n_t@203.184.4.230)
23:43:18the_KyleResuming playback after a shutdown causes a false start for about 2 seconds followed by a second start in the right place.
23:43:43*thomasjfox runs the n8xx binary on his n900
23:44:05the_KyleThe files are CD's of an audio book ripped to Speex.
23:45:59thomasjfoxok, the n8xx binary justs works. Including battery readout.
23:46:30thomasjfoxAudio output sounds like an Aphex Twin track though...
23:46:46 Quit JdGord (Quit: Bye)
23:47:04Buschelsoap: I have added 5 test patches to FS #11830. v02 has already been tested by you. this way you can easily refer to a version and the results
23:47:07 Join toffe82 [0] (~chatzilla@adsl-71-154-235-207.dsl.frs2ca.sbcglobal.net)
23:47:50 Quit toffe82_ (Ping timeout: 261 seconds)
23:49:48***Saving seen data "./dancer.seen"
23:50:13 Join toffe82_ [0] (~chatzilla@ppp-71-130-76-15.dsl.frs2ca.pacbell.net)
23:50:48 Quit toffe82 (Read error: Connection reset by peer)
23:51:20 Quit mortalscan (Ping timeout: 260 seconds)
23:51:59TheSevenlinuxstb: ping
23:55:58 Quit mgue (Quit: Lost terminal)
23:57:18 Quit AndyI (Remote host closed the connection)
23:57:41 Join AndyI [0] (~pasha_int@212.14.211.236)

Previous day | Next day