--- Log for 09.05.110 Server: jordan.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 2 days and 12 hours ago 00.01.39 Quit bgs000 (Remote host closed the connection) 00.03.19 Quit BHSPitMonkey (Quit: Ex-Chat) 00.03.20 Quit bmbl (Ping timeout: 252 seconds) 00.03.25 Join M3DLG [0] (~M3DLG@bb-87-81-252-83.ukonline.co.uk) 00.08.11 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.3.82) 00.17.05 Quit linuxstb (Ping timeout: 252 seconds) 00.25.01 Join geertvdijk [0] (~geert@5ED780FA.cable.ziggo.nl) 00.30.56 # why doesn't the clipv2 define PLUGIN_USE_IRAM? 00.32.47 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 00.32.56 Quit hebz0rl (Ping timeout: 260 seconds) 00.39.02 Quit petur (Remote host closed the connection) 00.44.20 Quit geertvdijk (Ping timeout: 276 seconds) 00.46.02 Join yawny [0] (user36@pr0.us) 00.47.52 Quit S_a_i_n_t (Ping timeout: 260 seconds) 00.49.15 Join kisak_ [0] (~kisak@c-98-235-209-218.hsd1.pa.comcast.net) 00.53.12 Quit halmi_ (Quit: halmi_) 00.53.54 Quit adnyxo (*.net *.split) 00.53.54 Quit elcan (*.net *.split) 00.53.54 Quit kisak (*.net *.split) 00.59.34 Join GeekShad0w [0] (~Antoine@204.150.204-77.rev.gaoland.net) 00.59.42 Quit mirak (*.net *.split) 00.59.42 Quit mikroflops_ (*.net *.split) 00.59.42 Quit solexx (*.net *.split) 00.59.42 Quit AlexP (*.net *.split) 00.59.42 Quit arun (*.net *.split) 00.59.42 Quit jordan` (*.net *.split) 00.59.42 Quit mapi (*.net *.split) 00.59.55 Quit ender` (Quit: Be wary of strong drink. It can make you shoot at tax collectors and miss. -- Robert A. Heinlein) 01.00.32 Join mirak [0] (~mirak@85-171-108-160.rev.numericable.fr) 01.00.32 Join mikroflops_ [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) 01.00.32 Join solexx [0] (~jrschulz@e176110245.adsl.alicedsl.de) 01.00.32 Join AlexP [0] (~ap@rockbox/staff/AlexP) 01.00.32 Join arun [0] (~arun@unaffiliated/sindian) 01.00.32 Join jordan` [0] (~jordan@jem75-13-78-235-252-137.fbx.proxad.net) 01.00.32 Join mapi [0] (~mapi@KHP222006067242.ppp-bb.dion.ne.jp) 01.00.37 Quit mirak (*.net *.split) 01.00.37 Quit mikroflops_ (*.net *.split) 01.00.37 Quit solexx (*.net *.split) 01.00.37 Quit AlexP (*.net *.split) 01.00.37 Quit arun (*.net *.split) 01.00.38 Quit jordan` (*.net *.split) 01.00.38 Quit mapi (*.net *.split) 01.00.41 Join mikroflops [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) 01.00.57 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 01.00.57 Quit GeekShadow (Read error: Connection reset by peer) 01.01.10 Join mirak [0] (~mirak@85-171-108-160.rev.numericable.fr) 01.01.10 Join mikroflops_ [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) 01.01.10 Join solexx [0] (~jrschulz@e176110245.adsl.alicedsl.de) 01.01.10 Join AlexP [0] (~ap@rockbox/staff/AlexP) 01.01.10 Join arun [0] (~arun@unaffiliated/sindian) 01.01.10 Join jordan` [0] (~jordan@jem75-13-78-235-252-137.fbx.proxad.net) 01.01.10 Join mapi [0] (~mapi@KHP222006067242.ppp-bb.dion.ne.jp) 01.01.36 Part domonoky1 01.02.20 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 01.03.13 Join anewuser [0] (anewuser@unaffiliated/anewuser) 01.05.29 Quit mikroflops_ (Ping timeout: 276 seconds) 01.05.58 Quit linuxstb (Ping timeout: 246 seconds) 01.06.51 Join m1ss1onto [0] (~62f86d07@giant.haxx.se) 01.07.01 Quit m1ss1onto (Client Quit) 01.12.31 Quit kyraxyg (Quit: CGI:IRC) 01.35.47 Quit pamaury (Quit: Page closed) 01.43.19 Quit Schmogel (Ping timeout: 245 seconds) 01.45.24 Quit anewuser (Quit: for SELL 2 by the price of 1 now!) 01.47.25 *** Saving seen data "./dancer.seen" 01.48.28 Join hebz0rl [0] (~hebz0rl@dslb-094-217-139-252.pools.arcor-ip.net) 02.03.51 Quit GeekShad0w (Quit: The cake is a lie !) 02.13.50 Quit DerPapst (Quit: Leaving.) 02.23.49 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 02.23.50 Quit bertrik (Changing host) 02.23.50 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 02.26.04 Join Rob2223 [0] (~Miranda@p4FDC9227.dip.t-dialin.net) 02.27.40 Quit hebz0rl (Quit: Ex-Chat) 02.29.44 Quit Rob2222 (Ping timeout: 268 seconds) 02.49.21 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 02.52.21 # Unhelpful? http://forums.rockbox.org/index.php?topic=24738.msg166539#new 02.53.29 # interesting. i am not aware of anything the jpeg viewer *should* decode that the core loader does not :| 02.54.01 # IF, if (I don't know Macs) he had a "hidden" file extension...? 02.54.12 # (something easy to do in Windows) 02.54.43 # but that should be trouble for both, shouldn't it? 02.54.47 # I dunno 02.54.54 # cover.jpg.jpg would open fine in jpeg viewer 02.54.57 # * soap looks at Unhelpful to answer Unhelpful's question 02.55.05 # but cover.jpg.png? 02.55.21 # Don't we have a .png viewer? 02.55.28 # poor example then 02.55.31 # So that'd open in the png viewer but not work as album art 02.55.35 # cover.jpg.llorean 02.55.51 # no, great example! cover.jpg.png would open if you view it, but not as album art 02.55.52 # cover.jpeg.somethingelse wouldn't do anything in Rockbox I believe 02.56.12 # Both cover.jpg.jpg and cover.jpg.png could present the behavior he's seeing, I think 02.56.21 # that's what I was uncertain of, Llorean, IF the viewer would open it but the AA search would fail. 02.56.23 # how would cover.jpg.jpg? 02.56.33 # ohhhh... because AA search fails. 02.56.39 # Yup 02.56.58 # but wouldn't the RB file browser show the double extension? 02.57.05 # so back to the other implied question. Can Mac OS hide "true" extensions? 02.57.14 # * Unhelpful thinks trying to load it in the sim is the best idea. 02.57.16 # Unhelpful: I would assume so. Can Rockbox be set not to show extensions at all though? 02.57.35 # have him do an ls from the terminal 02.58.08 # Unhelpful: In "supported" you don't see extensions. 02.58.17 # Llorean: if so that's a potential problem - windows "hide common extensions" option has been an exploit target in the past because people don't think it odd that one file happens to show an extension, so they open file.jpg.exe 02.58.24 # So he would see "cover.jpg.jpg" as "cover.jpg" I assume 02.58.51 # * Unhelpful would say that *something* breaking AA search is the most likely cause here 02.58.53 # But his OSX browser window looks like it's showing extensions just fine. 02.59.45 # Llorean, rockbox has multiple "ways" not to show extensions at all. 02.59.48 # I'd also ask him how he synced his music 03.00.00 # Since the folder is 'iTunes Music" and he refers to removing the AA in iTunes 03.00.08 # Is it possible he used iTunes to sync it? 03.00.15 # I don't see how he synced his music to be an issue. 03.00.26 # IF that directory structure is of his device as I asked. 03.00.31 # It's not 03.00.45 # a less likely cause imo would be a loader bug... i don't think i've seen one in many many months 03.00.46 # then we know nothing. ;) 03.00.56 # At least, on the left bar I don't see anything that indicates a device is attached 03.01.06 # Unless "iDisk" is his iPod 03.01.35 # looking at it again I think that is a "shared" device - NAS? 03.01.37 # It looks like a network share or something, since it says "shared folder" but I don't know anything about OSX really 03.01.46 # ditto 03.03.21 # Simplest answer is that he doesn't have on his iPod what he thinks he has on his iPod. 03.04.04 # and since Llorean rightfully pointed out that the screenshot does not appear to be of the ipod itself we need to verify that fist. Thanks for chewing the fat on the other possibilities, though, Unhelpful. 03.04.33 # "the user is always wrong" ; 03.04.53 # "the user is likely to not realize you need *exactly* what you asked for, not 'approximately'" 03.05.03 # or that :) 03.05.06 # Though it's good to know other ways AA could be broken but not look like it (hidden extensions is a good one) 03.05.28 # looks like the Itunes content on his Mac which I've seen stored in nice "usual" subfolders on Macs at work 03.06.37 Quit efyx (Remote host closed the connection) 03.14.02 # ahh, my post of desperation. "What version of Rockbox are you running?" 03.15.51 Quit Llorean (Quit: Leaving.) 03.15.53 # has anyone tried the fm skinning patch? 03.18.48 Quit bertrik (Quit: sleep) 03.19.18 Join Llorean [0] (~DarkkOne@adsl-99-158-45-131.dsl.hstntx.sbcglobal.net) 03.19.26 Quit Llorean (Changing host) 03.19.26 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 03.26.13 Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) 03.27.17 # Any last words, wishes, comments, complaints, gripes or other assorted feedback on FS#11250. 03.27.21 # ?? 03.29.29 # Blue_Dude: hey, something I completly forgot about untill after I DC'ed on friday... the origoinal icon patch should have sat longer and been made more public only because it broke all themes with icons (I know its irrevlvant now but still...) 03.30.19 # It did? The icons were referenced by enum. Confused why this would make themes not work. 03.31.01 # it could also explain the large bump... the icon system loads a bmp strip and decides how big each is by height/enum_size 03.31.17 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 03.32.13 # Hrm. That's odd. 03.32.29 # so adding an icon wouldnt actually break anything, it would make each icon slightly shorter looking crap 03.33.02 # I saw that behavior. It was fixed by reinstalling the new tango bmps. 03.33.18 # yes, but that would only fix that icon set 03.33.41 # as for 11250, I think it should also be settablee from a butotn press 03.33.41 # Well yeah. A clean build would make the problem go away though. 03.33.52 # only for themes using that icons set 03.34.35 # Still confused. I changed all the icon sets to add the new icon. A fresh install would have fixed it. 03.34.57 # Unless there are custom icon sets out there. Can't help those. 03.35.28 # * Blue_Dude frets about that. 03.35.36 # Don't matter now though. 03.36.57 # JdGordon1: I'm kinda looking forward to dumping all the menu code. You get the same functionality but the bin size is close to 1000 bytes less. 03.37.55 # Anyone reproduce the wav resume bug? It crashes the player. 03.38.17 # I'm going to have to report this... 03.38.36 # It seems to me that one of the biggest benefits to the hotkey stuff is being able to really quyickly change it... having to find the menu sucks 03.39.28 # JdGordon1: What are the values for the list you regularly change it between? 03.39.57 # I've personally never used it... 03.40.12 # So, why do you think it's something users would change frequently then? 03.40.34 # Bug report is at FS#11255. 03.41.09 # Blue_Dude: Which players have you reproduced that on (and I doubt it's a 3.4 bug?) 03.41.53 # Hey, JdGordon, put the hotkey setting on the quickscreen. }:-) 03.42.14 # Llorean: e200. It's very recent, last couple of days. 03.42.20 # Codec changes. 03.42.31 # Blue_Dude: you marked it as a 3.4 bug in the tracker, so you probably want to change that. 03.42.46 # not all the playlist options are available tot he hotkeys right? 03.42.56 # I've been off the net so I couldn't do a reversion check to pin down the exact revision. 03.43.06 # k 03.43.10 # Blue_Dude: Does the size of the .wav file or anything matter? Can I just grab one a few seconds long from somewhere to reproduce with? 03.43.35 # Or channels, sample rate, etc. 03.45.00 # I don't know. All I know is that it dumps in the middle of trying to set up. You can see the debug info in the sim, and it doesn't complete its load. 03.45.45 # We had resume problems the last time the codec was updated too. 03.45.48 # Well the more information you can include in the bug report (for example, that it's reproduceable in the sim) the better. 03.46.33 # k 03.47.17 # I'll report the bug and leave it to the experts to nail down. If they can't reproduce, then I'll get more involved. 03.47.27 *** Saving seen data "./dancer.seen" 03.47.51 # I think I left simple enough instructions to reproduce. 03.49.00 # JdGordon: Sorry, missed your comment. No, I'm not changing functionality yet. So far only Playlist Insert is coded. 03.49.34 # Blue_Dude: It's better to include as much useful information up front, so that when they're around to test it doesn't matter whether you're around or not. 03.49.44 Nick JdGordon1 is now known as JdGordon (~jonno@123-243-140-31.static.tpgi.com.au) 03.49.46 # If they come to test, and need to ask something, they may not be able to do any more until you get back 03.50.35 # That's pretty simple to change though, if you're interested. It would even be in order, since Playlist Insert is listed last in the enum. 03.51.17 # Blue_Dude: For example, I can't reproduce on my Gigabeats with a 16-bit 44.1khz WAV file 03.51.28 # Llorean: nope, I'm done troubleshooting. If there are questions later, I'll answer them. I'll be very surprised if they can't reproduce it though. 03.51.42 # Well, be surprised. 03.51.44 # I can't reproduce. 03.51.47 # OK, build a e200 sim and check it out. 03.51.49 # Current SVN as of 3 minutes ago. 03.52.00 # Use a nice long one. 03.52.09 Join chjurk [0] (~chjurk@2001:6f8:1c00:1fa::2) 03.52.11 # Why didn't you provide that info in the report then? 03.52.19 # I did say e200 sim. 03.52.25 # You marked the report SWCODEC 03.52.30 Part chjurk 03.52.43 # Yep. Codec issue. SWCODEC. Follows. 03.52.53 # No, you marked the *player type* as sw-codec 03.53.00 # That means you think it occurs on all software codec players 03.53.01 # Yes, so I did. 03.53.21 # I think it's a reasonable probability. I didn't try them all out. 03.53.26 # Well, it doesn't. 03.53.40 # OK, take ownership and fix it. 03.54.13 # Blue_Dude: Why don't you provide more details for how to reproduce it? 03.54.20 # Nobody can fix it if they can't reproduce it. 03.54.27 # You may have a problem wav file? 03.54.55 # The wav file is a year old. I've been using it for testing for the last nine months. 03.55.10 # Yes, and maybe something about that type of .wav is broken, rather than all ones 03.55.18 # So knowing it sample rate, channels, bit rate, and other details could help 03.55.19 # It crashes under those circumstances with a clean build. 03.55.32 # Not all .wav files are identical. There are many differences between them. 03.55.41 # 16 bit 44.1 kHz, stereo. Plain vanilla. 03.55.50 # I mean, really. 03.56.19 # Well, I can't read minds so I can't know thats what you're doing, and you were being oddly reluctant about refusing to state the properties of the file until now. 03.56.35 # Maybe attach a short .wav file sample to the task of one that definitely crashes with current SVN to make testing easier? 03.57.28 # This is a total waste of my time. I've had an extremely long day. I'm going to commit my patch and go to bed. Take or leave the bug report. At this point I just don't care. 03.57.38 # Blue_Dude: Does it happen on players, or just the sim? 03.57.56 # Blue_Dude: Seriously, it's a waste of your time to *investigate a bug only you can currently reproduce*? 03.59.00 # Yes, it is. It is not my bug. I just was the first to notice it. 03.59.01 Join n1s [0] (~n1s@rockbox/developer/n1s) 03.59.40 # Blue_Dude: And so you refuse to answer even basic questions about the conditions? 03.59.50 # 'Night. 03.59.52 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 03.59.53 # usually codec problems impact all players, unless theres endianness or ASM involved 04.00.13 # saratoga: It doesn't happen on my Gigabeat S with current SVN 04.00.22 # Which is why I was trying to find out more. If it's SIM only that could be telling 04.00.25 # it wont usually cross to hwcodec though 04.00.25 # i doubt the wav codec has any ASM, but it could be endian specific 04.00.32 # although x86 and arm are the same 04.00.59 # saratoga: Of course, it would also help (as I said) to know the details of the file being used. =/ 04.02.07 Join Barahir_ [0] (~jonathan@frnk-590f4fdf.pool.mediaWays.net) 04.02.49 Quit xavieran (Ping timeout: 246 seconds) 04.03.22 # New commit by 03Blue_Dude (r25905): FS#11250: Hotkey setting method changed to menu item vs button pres in context menu. Manuals updated to match. 04.04.56 Quit saratoga (Ping timeout: 252 seconds) 04.05.15 Quit Barahir (Ping timeout: 240 seconds) 04.06.03 Quit amiconn (Disconnected by services) 04.06.04 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.06.05 Quit pixelma (Disconnected by services) 04.06.05 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.06.25 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.06.26 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.07.43 Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-hpopepfvtzdfbnnj) 04.07.45 # New commit by 03Blue_Dude (r25906): Fix red 04.12.27 Quit linuxstb (Ping timeout: 248 seconds) 04.14.16 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 04.16.05 Join ncfi1013 [0] (~ncfi1013@cpe-76-184-6-218.tx.res.rr.com) 04.17.19 # does rockbox work on the ipod nano video 4th gen? 04.18.07 # no 04.18.44 Quit adnyxo (Ping timeout: 240 seconds) 04.20.31 # http://graphics.dyscern.com/gr/images/nw/apple_ipod_video_nano_4g_black.jpg 04.20.58 # OH... THAT ipod video nano 4g.... 04.21.00 # still no 04.21.01 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 04.21.07 # just in case there is some confusion i found an image of what im talking about 04.21.13 # ncfi1013: The list of supported players is on the front page of the website. 04.22.11 # is there any support for ipod in question in lucid? still running koala. 04.22.21 # ncfi1013: go ask the ubuntu people 04.24.17 Join xavieran [0] (~xavieran@ppp118-209-75-190.lns20.mel4.internode.on.net) 04.31.17 Join Zarggg_ [0] (~zarggg@2001:0:4137:9e76:0:fbf3:beb1:ba3d) 04.34.04 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.2.6) 04.34.50 Quit Zarggg (Ping timeout: 248 seconds) 04.42.11 Join Curulan [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 04.46.08 Quit Zarggg_ (Ping timeout: 268 seconds) 04.57.02 Join dys` [0] (~andreas@krlh-5f72fa37.pool.mediaWays.net) 04.57.14 Quit xavieran (Ping timeout: 248 seconds) 04.57.44 Quit linuxstb (Ping timeout: 240 seconds) 04.58.12 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 04.59.26 Quit dys (Ping timeout: 276 seconds) 05.00.49 Quit Barahir_ (Read error: Operation timed out) 05.19.13 Join xavieran [0] (~xavieran@ppp118-209-75-190.lns20.mel4.internode.on.net) 05.19.35 Quit linuxstb (Ping timeout: 276 seconds) 05.20.05 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 05.47.30 *** Saving seen data "./dancer.seen" 05.51.56 Quit fyre^OS (Read error: Connection reset by peer) 06.00.43 Quit linuxstb (Ping timeout: 246 seconds) 06.08.16 Join FlynDice [0] (~FlynDice@74.10.105.233) 06.15.35 Quit FlynDice (Quit: Gotta go fly!) 06.15.52 Join FlynDice [0] (~FlynDice@74.10.105.233) 06.32.38 Nick dys` is now known as dys (~andreas@krlh-5f72fa37.pool.mediaWays.net) 06.35.05 # Would someone explain the significance of having one's copywrite in the rockbox header attached to the beginning of each file. I am not particularly interested in claiming any credit for work I've done but if there is a legal significance for the rockbox project and I should be doing this I would like to know that! 06.37.14 # FlynDice: I've often wondered about that myself, I *think* it has just become popular convention to put ones stam on something... 06.37.18 # *stamp 06.38.41 # FlynDice: i think its just convention, we need to give copyright to someone, and since there is no Rockbox entity, we give it to whowever made the file 06.39.18 Quit kramer3d (Ping timeout: 265 seconds) 06.41.31 # saratoga: Thanks, So there's no legal issues to be concerned with if I don't bother with it is what I gather. 06.46.17 # * S_a_i_n_t adds a simple comment to the newest "hey, how can I remove DRM from my crippled Rhapsody files?" guy on the RB forums. 06.53.09 # * JdGordon thinks the backdrop size calculation is wrong... 06.53.17 # #define LCD_BACKDROP_BYTES (LCD_FBHEIGHT*LCD_FBWIDTH*sizeof(fb_data)) 06.53.44 # and, for the lamens of the group? 06.56.46 Join mianos [0] (~mrfish@124-168-146-31.dyn.iinet.net.au) 06.59.15 # so if buschel's test_mem changes are correct, I get that IRAM on the Clipv2 is about 2x as fast as DRAM when unboosted, and 3x as fast when boosted 06.59.34 # clipv1 results don't look right to me, but they claim that DRAM is faster then IRAM 07.02.09 Join Barahir [0] (~jonathan@frnk-590f6b41.pool.mediaWays.net) 07.05.49 Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.2.95) 07.07.36 Quit S_a_i_n_t (Ping timeout: 246 seconds) 07.13.36 Nick S_a_i_n_t_ is now known as S_a_i_n_t (S_a_i_n_t@203.184.2.95) 07.18.02 Quit S_a_i_n_t (Ping timeout: 248 seconds) 07.26.19 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.2.132) 07.27.14 Quit Horscht (Ping timeout: 240 seconds) 07.28.22 Quit mirak (Quit: Ex-Chat) 07.29.24 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 07.32.54 Quit FlynDice (Read error: Connection reset by peer) 07.39.29 Join funman [0] (~fun@rockbox/developer/funman) 07.47.32 *** Saving seen data "./dancer.seen" 07.47.32 Join esperegu [0] (~quassel@145.116.15.244) 07.49.03 # amiconn: does that #define above look correct? 07.54.59 # Yes it does 07.57.13 # trying to figure out why the skin buffer is apparnelty not big enough on grey targets 07.58.00 Quit esperegu (Ping timeout: 246 seconds) 07.59.03 # any trick to make the clip+ crash really fast? i'm tweaking the equ settings but it takes 2 minutes or so 08.00.21 # I would have thought you'd be the best one for advice when it came to crashing sansas ;) 08.00.51 # i would like to 08.00.53 # funman: enabling voice menus and voice clips and browsing through menus and songs 08.01.14 # i need to install voice files though ? 08.04.17 # nevermind I found it 08.06.47 # i have a langs/english.voice, language set to english, voice menus enabled (by default anyway) but nothign is spoken 08.07.03 Join robin0800 [0] (~quassel@general-ld-216.t-mobile.co.uk) 08.07.39 # hm i got the clipv1 file though, perhaps that matters 08.08.32 Join esperegu [0] (~quassel@145.116.15.244) 08.09.14 Quit Boldfilter (Quit: Boldfilter) 08.12.32 # thanks it works! 08.13.28 # it crashes 3 instructions after returning from set_cpu_frequency(), but loading the content of given address show it's correct 08.16.03 # ThomasAH: what is the biggest number of items you could ever hear before it crashed? 08.16.20 # heh, this is new...instructions on RB-IRC for "how do I *crash* my clip" as opposed to "how can I make it more stable" ;) 08.16.46 # S_a_i_n_t: it really is "how can i reproduce crashes and test possible bugfix" 08.17.40 # Frankly, I'm surprised it was so easy to do. 08.18.11 # you could have just gone back to few 1000 revisions :) 08.18.19 # hm? 08.18.20 # s/to/a/ 08.18.58 # It was a remark on how greatly the stability has increased of late. 08.19.13 # * funman doesn't agree 08.19.29 # you *don't* think they're more stable? 08.19.37 # no 08.20.08 Quit robin0800 (Remote host closed the connection) 08.22.34 # file context menu isn't voiced correctly it seems 08.23.34 Join FlynDice [0] (~FlynDice@74.10.105.233) 08.25.04 # amiconn: so "LCD_HEIGHT*LCD_WIDTH*LCD_DEPTH/8" is wrong? 08.25.16 # or that will give a less accurate size? 08.26.58 # It is wrong on targets where depth < 8 and the width or height (depending on pixel packing) is not an integer multiple of the pixel block size 08.27.03 # ThomasAH: hm first time I tried it crashes on the 3rd item and now I just listened to at least 30 items and it still works (using the same code) 08.27.10 # Afaik we only have two such targets - the twi Minis 08.27.24 # s/twi/two/ 08.27.33 # it will give a value too small or too big? 08.27.38 # Too small 08.27.55 # cheers, tat could explain things 08.28.19 # You're testing on mini? 08.28.41 # yeah 08.29.08 # but the issue is that fm skins just wont load because there isnt enough room, when there should b 08.29.35 # what happened to resizable skin-buffer? 08.29.43 # * S_a_i_n_t looks for kugel. 08.30.44 # The mini should load fm skins? 08.30.51 # no 08.31.44 # New commit by 03jdgordon (r25907): use a better value for the needed skin buffer size 08.31.59 # that might make it possible for it to load fonts though 08.32.25 # Hmm, other targets shouldn't have problems with that backdrop buffer size definition... 08.33.32 # right now its set to grab 2 full depth screens + 1 backdrop per skinnable screen (2 now) 08.33.35 # The old definition was short by 55 bytes on mini (half a byte per line) 08.33.55 # ok, so not enough o make a difference 08.34.43 # the old way used too much on mono screens apparently? 08.36.02 # it bumpbed the buffer from 22KB to 31KB on the mini 08.36.13 # New commit by 03jdgordon (r25908): fix red 08.37.25 # Umm, mono doesn't support backdrops... 08.38.30 # So probably LCD_BACKDROP_BYTES is set to 0 for them 08.39.13 # However, some mono themes may use a fullscreen pseudo-backdrop. I'm not sure though - my wps'es don't use any bitmaps 08.41.05 # haha yeah woops 08.43.06 # New commit by 03jdgordon (r25909): mono targets dont support backdrops so dont use that #define 08.43.20 # WPS'es without .bmps (or at least one animation for that matter) make S_a_i_n_t cry... 08.44.58 # i only ever made own wps'es for the archoses 08.45.03 Quit CaptainKewl (Remote host closed the connection) 08.45.21 # I use the bitmap archos one on a few other targets, on the others I just use the builtin one 08.45.42 # (builtin default, *not* cabbie) 08.45.48 # I guess I should start branching out into themeing for targets I don't own. 08.45.53 # * amiconn can't stand cabbie for more than a few minutes 08.47.05 # nor can I, I made my own Cabbie (guess you'd call it CabbieV5 going by the other " V's " on the themesite which I find tolerable...but I still don't really like it. 08.47.15 # * S_a_i_n_t isn't a big fan of yellow. 08.47.30 Quit esperegu (Quit: No Ping reply in 180 seconds.) 08.47.35 # you have a clip though? ;) 08.47.52 # My only gripe with cabbie on the smaller screens is too much text together so its hard to see what is what... unless I use my multifont version 08.47.55 Join esperegu [0] (~quassel@145.116.15.244) 08.48.12 # JdGordon: Same. 08.48.20 # My biggest gripe with cabbie is that it's bright-text-on-black 08.48.26 # My cabbie manages to make it look "decent" IMO 08.48.56 # funman: for about a week, I'm *really* not a fan of that screen. 08.49.04 # I got rid of it pretty quickly. 08.49.06 # Well, /me rates functionality >> design 08.49.24 # sure, but it's possible to have both. 08.49.35 # especially on "large screen" targets. 08.49.53 # the combination of small and lots of text in cabbie on the clip makes it really hard to use while running in my experience, otherwise i like it 08.49.58 # One of the reasons I like themeing the Nano so much is trying to find balance between the two. 08.50.23 # I have more relevant information with builtin status bar + builtin wps than with cabbie. And bright-text-on-black makes my eyes bleed after a few minutes 08.52.15 # New commit by 03jdgordon (r25910): revert those last few... 08.53.29 # High resolution battery status and high resolution volume (~15 steps each), to name just two 08.54.17 # it's possible to put "progressbar logic" in battery/volume now...so, the resolution is WAY higher than the builtin whatever. 08.54.19 # 15 steps is hardly high res 08.54.32 # 15 pixels is hardly high anything 08.54.38 # * S_a_i_n_t agrees with this. 08.55.28 # Well, iirc cabbie only has 4 battery levels 08.55.40 # that sounds wrong 08.55.41 # progressbar style battery/volume looks *so* sexy...and saves a LOT of skin buffer. 08.55.49 # and it should be using the bar style now anyway :) 08.55.54 # And volume in the builtin status bar changes to numeric during adjustment 08.55.57 # best thing for the wps/sbs since...the last really good thing ;) 08.56.40 # I also have time (on targets with rtc - not so much to actually get the time, but rather to easily notice when the rtc is off) and disk activity 08.57.16 # the built in bar is just so....ugly, for lack of a better word. 08.57.40 # ThomasAH: how does http://pastie.org/952230 work for you ? 08.57.42 # I have all those things in my .sbs, but *prettier* ;) 08.57.56 # The builtin bar is completely sufficient on most of my targets. 08.58.54 # sufficient, sure. Ugly, sure. ;) 08.59.00 # My largets screen targets are 220x176 (H300 and iPod Color) - and there it's a bit small 08.59.03 # totally subjective I guess. 08.59.39 # I *could* make you an .sbs that looks exactly like the built-in bar but larger? 08.59.51 # and uses better logic for drawing battery/vol etc. 09.00.00 # * amiconn forgot the beast, but that's not much wider anyway 09.00.01 # it's an option...and I wouldn;t mind. 09.00.21 # If it is larger... it wouldn't fit on the archos screen 09.00.28 # That's in fact where it comes from 09.00.40 # I couldn't do it immediately, but I'm sure more people than you would get a kick out of it. 09.00.43 # the default bar is *tiny* on the beast 09.00.56 # and miniscule on the mr500 :) 09.01.16 # * S_a_i_n_t wonders how it looks on the mini2440 ;) 09.02.27 # n1s: Tiny yes, but still recognisable 09.02.34 # * amiconn doesn't use the beast much 09.03.21 # * Llorean thinks the default bar looks fine on the beast, but wouldn't want it much smaller than that 09.03.27 # funman: I'll try it later today ... currently in familiy interrupt 09.03.33 # I have 4 targets (among 15) I use most. They're all non-colour, and quite old. I still prefer them for the sound quality, flexibility, and readability without backlight 09.03.49 # ThomasAH: can't you disable interrupts? .. oops that only work with computers .. ;) 09.03.59 # sure but it's a bit hard to read :) 09.04.01 # Iriver H180, Archos Recorder, Mini G2, Archos Player (in that order) 09.04.39 # funman: works with family, too, but probably triggers a NMI by the police :) 09.05.27 # amiconn: of my 3 targets, the beast sounds the best by far IMO 09.05.38 # (h300, c200, beast 09.05.45 # ) 09.05.49 # funman: and away again ... (additionally I have a patch for the clip* manual in preparation) 09.06.04 # cool! 09.06.04 # I'd expect the H300 to sound better than the beast overall... a bit noisier though 09.06.24 # The c200 audio codec is crappy though 09.06.37 # The noise on the H100 is pretty terrible in quiet conditions, if the H300 is the same, I wouldn't put it up against the Beast. 09.06.56 # The c200/e200 shouldn't even really be talked about when discussing sound quality. :) 09.07.23 # Well, the UDA1380 has a bit of background hiss. Imo it still sounds better than those WM* codecs overall 09.07.40 # That's subjective of course 09.08.04 # yeah 09.08.22 # When I'm in conditions I can't hear the hiss, I love my H100. 09.08.45 # get tinitus and then the codec really wont matter much :) 09.08.54 # But the lack of it gives me the perception that the Gigabeast sounds "cleaner" 09.09.28 # i don't use the h300 at all basically, since it is about twice the size of the beast (and i think the beast sounds better) 09.10.09 # New commit by 03uchida (r25911): wave/wave64 LIST chunk parser ... 09.11.11 # i like the size and battery time of the c200 though 09.11.43 # how are the clip + or v2 with battery time and sound quality? 09.12.02 # hum i notice weird battery indicator when charging with the OF on clipv2 09.12.13 # n1s: Great sound quality (to me at least) 09.12.13 # n1s: battery time is very good (next to 20 hours) 09.12.23 # Er, regular clip 09.12.24 # there is some hiss though 09.12.25 # Not clip+ 09.12.30 # * Llorean assumes the clip+ is at least comparable. 09.12.41 # (with rockbox) 09.13.01 # I didn't notice a hiss like the iRivers have on my Clip at least. 09.13.04 # clipv1 battery is awful although it just got better (a bit below 8 hours for mp3) 09.13.05 # * Llorean didn't look for it either, though 09.14.00 Join ucchan [0] (~ucchan@softbank126102048040.bbtec.net) 09.15.07 # ucchan: Hi 09.15.45 # Hi JdGordon 09.16.10 # I had a hard time understanding your reply to the embedded AA task 09.16.49 # is there any reason why you dont try allocating enough buffer for the image, and if the buffer is full then just fail and try next time? 09.17.35 # ucchan: are you uchida? 09.18.37 # funman: both the v2 and the + have card slots, right? 09.18.46 # only the + 09.18.54 # fuze and + do, not the clip 09.18.57 # ah 09.19.03 # image data size is big (10 -32 kB), then there is possible which the buffer is filled. 09.19.28 # yes, but regular AA has that problem also 09.19.29 # clipv2 is to clipv1 what fuzev2 is to fuzev1, something like what e200v2 is to e200v1 09.19.31 # then I gave up that dthe data does not store in it 09.20.13 # same case, different shit 09.20.27 # ucchan: heres the tta patch I made ages ago 09.20.29 # http://duke.edu/~mgg6/rockbox/tta.patch 09.20.39 # ignore the change to vorbis, its just junk 09.20.41 # And, the codec buffer is not used too much effectively. 09.20.50 # unfortunately, its not anywhere near working 09.21.00 # decodes one frame and then crashes I think 09.22.44 # saratoga, Is the performance enough? 09.22.59 # ucchan: i don't know, but the format is very simple, so I think it should be fast 09.23.29 # ucchan: ffmpeg took the same decoder source and improved it further: http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavcodec/tta.c;h=4bdfd73fbd706c28a335a274a7772870177318bd;hb=HEAD 09.23.46 Quit wincent_balin (Quit: Verlassend) 09.23.48 # if you want to port TTA, starting with their code instead of that patch might be a good idea :) 09.23.54 # I checked my tta codec is slow (base on original tta hardware player's). for iPod, about 104 % 09.24.11 # you already ported it? 09.24.12 # sorry more less 95 -100 % 09.24.45 # My local environment. 09.24.54 # i'm sure it can be optimized 09.25.14 Join ender` [0] (krneki@foo.eternallybored.org) 09.25.16 # gcc is likely to make a big mess of the filter 09.25.32 # rewriting it in assembly will probably help a lot on the ipod 09.26.09 # But I optimized decode logic, then my codec's speed is 130 % - 140% 09.26.32 # are you ready to commit it? 09.29.20 # I check only iPod. then I will send the tracker 09.29.38 # sounds good 09.30.05 # please wait for a moment... 09.30.21 # for codecs we require that they compile on all targets, but they don't have to work correctly right away (sometimes its months or years before they work on all devices ) 09.31.39 # There might be some problems because I am compiling only on iPod. 09.34.22 # if it works on an arm target it should work fine on all arm and probably cf too 09.34.43 # unless there are endianess issues of course 09.39.45 # tta original decoder, because the endian is considered, it might be unquestionable(may be...). 09.39.56 # New commit by 03funman (r25912): Update current usage for Fuzev1/e200v2/Clipv1 09.40.08 Join solexx_ [0] (~jrschulz@e176097029.adsl.alicedsl.de) 09.41.50 # clipv2 crashed in 7 minutes playing mp3 09.42.27 # i had a crash every 20 minutes so with mine today 09.42.46 # i hoped i had the right fix :( 09.43.33 # sorry not today, friday 09.43.37 Quit solexx (Ping timeout: 276 seconds) 09.44.34 # yesterday I listened to flac from µSD on Clip+ and it crashed with CPU boosted 09.45.38 # it took us years before the last disk issues were fixed on the e200v1 09.47.34 *** Saving seen data "./dancer.seen" 09.48.41 # were the (random) clip playback issues ever fixed? 09.48.56 # according to the poll i made in the forum no 09.51.01 # JdGordon: for plain mp3 with nothign special going on its basically stable, but turn on too many features or skip through playlists and it'll crash 09.51.21 # or at least it'll deadlock 09.51.35 # recording errors (on fuzev2 at least) happen because we don't read from the fifo fast enough 09.52.06 # pcm playing + recording at the same time should be impossible afaik, i'm not sure why i didn't use DMA 09.52.56 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 09.55.00 Quit pjm0616 (Read error: Connection reset by peer) 10.02.13 # ah i remember i couldn't get it to work at all 10.02.21 Quit aberet (Ping timeout: 260 seconds) 10.02.30 # fred bauer helped a lot here 10.06.40 Join stoffel [0] (~quassel@p57B4C3D9.dip.t-dialin.net) 10.12.55 # clip+ crashed too .. sigh 10.13.11 Join komputes_ubuntu [0] (~komputes@ubuntu/member/komputes) 10.16.17 Join Luca_S [0] (~5711b744@giant.haxx.se) 10.20.01 Quit Curulan (Quit: Curulan) 10.20.12 Quit CGL (Quit: Soy spammero http://wiki.n00b2hack.com.ve ---- \m/ d(>.<)b \m/) 10.23.14 Join Zarggg [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 10.25.32 Quit Kitar|st (Ping timeout: 264 seconds) 10.28.58 # delay in sending, I send the tta codec the tracker (FS#11256) please confirm it 10.30.23 Join Kitar|st [0] (~Kitar_st@BSN-182-71-75.dial-up.dsl.siol.net) 10.31.59 Quit rvvs89 (Ping timeout: 246 seconds) 10.32.00 Quit esperegu (Remote host closed the connection) 10.32.37 Join rvvs89 [0] (ivo@bright-snat.ucc.asn.au) 10.37.12 Join esperegu [0] (~quassel@145.116.15.244) 10.37.45 Join petur [0] (~petur@rockbox/developer/petur) 10.40.18 Quit bmbl (Ping timeout: 252 seconds) 10.41.59 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 10.42.39 Join pjm0616 [0] (~user@61.250.113.98) 10.44.01 Join stoffel_ [0] (~quassel@p57B4C8E4.dip.t-dialin.net) 10.44.29 Quit Luca_S (Quit: CGI:IRC) 10.44.33 Quit stoffel (Ping timeout: 246 seconds) 11.02.07 Quit dys (Ping timeout: 276 seconds) 11.05.23 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 11.08.37 Quit komputes_ubuntu (Ping timeout: 276 seconds) 11.09.23 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 11.12.17 Join Buschel [0] (~ab@p54A3B823.dip.t-dialin.net) 11.27.40 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 11.31.19 Quit petur (Quit: Leaving) 11.31.32 # saratoga: on an iPod 5.5G 24/100 MHz -> DRAM: 12-16/60-70 MB/s IRAM: 50/200. when taking the asm into account the measured IRAM speed is exactly what is expected when IRAM access has zero wait state. 11.35.11 Join kugel [0] (~kugel@rockbox/developer/kugel) 11.38.07 Join komputes_ubuntu [0] (~komputes@ubuntu/member/komputes) 11.46.42 Join Schmogel [0] (~Miranda@p3EE22857.dip0.t-ipconnect.de) 11.47.25 # hm i have recording working with DMA but it sounds really bad 11.47.36 *** Saving seen data "./dancer.seen" 11.48.09 # looking in audacity I see a bar at X frequency, where X is really close to the frequency of the DMA callback 11.48.30 Quit freddy_ (Ping timeout: 252 seconds) 11.49.09 # Maybe some off-by-one error (just guessing). 11.49.27 # off-by-one-sample would hardly be hearable i think 11.49.28 # Can you post a wav somewhere? 11.49.56 # yes, what source material could I use? 11.50.00 Quit Buschel (Ping timeout: 260 seconds) 11.50.47 # if there is one extra sample per block, it would give a frequency component at the inverse of the block size 11.51.12 # funman, can you sing? :P 11.58.13 # patch: http://pastie.org/952282 flac: http://rafael.carre.perso.sfr.fr/money.flac 12.00.01 # i only tested fuzev2 though 12.00.31 Join freddy_ [0] (~freddy@p3E9E1D87.dip0.t-ipconnect.de) 12.00.44 Quit antil33t (Ping timeout: 260 seconds) 12.02.04 # frequency looks alright 12.02.38 # yeah, but it's heavily quantized somehow 12.04.54 # quantized? 12.05.56 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 12.06.04 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 12.06.50 # yes, it looks like there are only 8 levels for the audio signal 12.07.06 # (I'm looking at the flac in audacity) 12.07.51 # ok 12.08.24 # i2sin is set for 14 bits per sample, but samples should be transferred as 32 bits (16 bits + 16 bits) 12.08.47 # there is a 24 bits mode (32bits + 32bits) but i think rockbox expects 16 bits per sample PCM 12.10.00 # i talked about a problem with recording on ABI forum and noted rockbox recording had few levels, so perhaps this problem exists with current recording ? 12.19.05 Join Jaykay [0] (~chatzilla@p5DC57141.dip.t-dialin.net) 12.20.09 Quit shai (Quit: Leaving) 12.20.39 # bertrik: i put the patch on FS#11257 12.20.47 Join DerPapst [0] (~Alexander@p5797C680.dip.t-dialin.net) 12.21.26 # thanks 12.22.15 # http://www.anythingbutipod.com/forum/showthread.php?t=54060 <- discussion about recording problems in OF and rockbox 12.27.28 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 12.35.11 Join loveless [0] (~loveless@188-195-101-189-dynip.superkabel.de) 12.35.42 Quit shaggy-h (Ping timeout: 240 seconds) 12.38.39 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 12.39.50 # anyone around here familiar with the usb code of the e200rpatcher? I am trying to use it for a different platform, but switching from PP502x to PP6100 seems to have broken the host usb code -- despite the fact that it should be completely identical. I can't seem to find out why this could be tha case. 12.43.06 # any ideas on how to proceed with debugging this one? I don't want to waste any more time with my brute-force grep -r approach 12.44.12 # e200rpatcher is just used to remove the upgrade blocker 12.45.35 # JdGordon: it uploads code, which I assume is the point here 12.45.59 # the problem is: the code builds fine but the host's usb_find_busses() or usb_find_deviced() (have seen any hanging) throw timeouts and i/o errors. 12.47.12 # gavaerts: yes, I only use it for loading test code. but I am at a point where it felt right to get the code tree to switch to the correct platform 12.48.52 # JdGordon: it worked fine for the pp6100 view as long as I was using the pp520x target. 12.50.06 # ah fair enough 12.50.34 Join Buschel [0] (~ab@p54A3D223.dip.t-dialin.net) 12.53.34 Join wodz [0] (~wodz@chello087206240004.chello.pl) 12.55.56 Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) 12.57.50 # oh, come back jdGordon. 12.57.59 # hi 12.59.11 # AlexP: ping? 12.59.16 # pixelma: ping 13.01.15 # As for embeded aa, Is the big size memory stored in the file buffer, and is it safe ? (buffering.c's source is difficult little..) 13.02.28 # ucchan: I'm probably not the best person to talk to, I just found it odd that you were relying on the codec buffer. I would think that it should act like regular AA which is just copied onto the buffer if there is enough room 13.02.30 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 13.02.40 # talking to Unhelpful would probably be best 13.03.10 Quit Rob2223 (Quit: Rob2223) 13.03.20 Join Rob2222 [0] (~Miranda@p4FDC9227.dip.t-dialin.net) 13.07.06 # bertrik: about battery life, i find it strange that the clipv1/fuzev1/e200v2 do not have the same power usage 13.07.29 # this is also true between different clips 13.07.45 # is there really a big difference? 13.07.47 # perhaps we forgot to initialize some register and it is left in an undetermined, device-specific stage 13.07.59 # my clip doesn't go past 8 hours 13.08.51 # i was thinking of ascodec registers, did we check if we explicitely write to each of them ? 13.09.05 # weird, maybe sandisk changed components 13.09.05 # jdGordon: understand 13.09.34 # bertrik: you think there should be a sane reset value ? 13.09.49 # also I think we're not completely sure about the clips' battery capacity anyway, I tried to extrapolate it from other batteries based on the type number 13.10.43 # funman, I think we haven't checked yet if we write them all 13.10.56 # ah you think there would be different capacities to explain the difference between 2 clips? 13.11.28 # funman, yes that would be a possibiltiy (just a guess for now) 13.13.41 Join mikroflops_ [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) 13.17.35 Quit mikroflops (Ping timeout: 240 seconds) 13.18.00 Quit esperegu (Ping timeout: 240 seconds) 13.20.35 Join esperegu [0] (~quassel@145.116.15.244) 13.23.29 # funman: You made some comment to my ML post about performance problems with MPIO. Could You be more specific about idea with second timer? 13.24.06 # if the kernel tick is not fast enough you could experience general slowness 13.25.08 # perhaps an easy measurement would be to modify the HZ variable and see how speed scale (measure with test_codec) 13.25.18 # the HZ constant* 13.25.32 Quit esperegu (Ping timeout: 246 seconds) 13.25.47 # sorry I don't understand 13.26.17 # the CPU is interrupted HZ (= 100) times per second 13.26.35 # until the tick has been executed, nothing else is executed 13.26.56 # yes 13.26.58 # if the tick is executing for 0.01 second, then 100 times 0.01 = 1 second, so not other code can run 13.27.09 # hopefully the tick is executing for much less than 0.01 second 13.27.39 # but if it is 0.005 second, then the speed of other code will feel very slow, just like if the CPU was twice as slow 13.28.40 # does it make sense? 13.28.47 # in general yes 13.29.15 # try changing HZ in kernel.h to 50 for example 13.29.43 # I will quit soon. (dinner, etc). tommorow, I wil login. 13.29.59 # good bye ucchan 13.30.03 # Please write the question to me in the tracker. 13.30.16 Quit ucchan (Quit: Leaving...) 13.30.54 # wodz: if you see noticeable speed change, next step is find the part which takes a lot of time in the kernel tick 13.31.06 # yes now I get it 13.33.08 # kugel: ping 13.34.29 # wodz: pong 13.35.27 Join anewuser [0] (anewuser@unaffiliated/anewuser) 13.35.58 Join esperegu [0] (~quassel@145.116.15.244) 13.36.16 # kugel: I experince errors from ALSA when running sim 13.38.23 Quit funman (Quit: brb, travelling at ++c m.s^-2) 13.40.12 # wodz, kugel : I receive these errors in the sim : 13.40.14 # ALSA lib conf.c:2742:(snd_config_hooks) id of field i is not and integer 13.40.15 # ALSA lib conf.c:3079:(snd_config_update_r) hooks failed, removing configuration 13.40.27 # me too 13.40.41 # since when? 13.40.50 # I have no idea what these errors mean 13.42.22 # I'll try to narrow it down to a particular commit (but will be slow because I'm on a VM currently) 13.43.09 # mt: we can split bisection to find out 13.43.51 # teamwork! :) 13.46.54 # too bad i just missed funman. for the logs sir, please look at http://forums.rockbox.org/index.php?topic=14064.msg166565#msg166565 13.46.55 # wodz: Great, thanks. I'll look how slow/fast it goes first though and tell you .. 13.47.27 Part mianos 13.47.33 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 13.47.37 *** Saving seen data "./dancer.seen" 13.49.23 # wodz: Forgot that I only have svn on my VM :( .. I'll try svn-bisect 13.58.39 Join MethoS- [0] (~clemens@134.102.106.250) 14.03.37 # linuxstb: ping 14.10.21 # JdGordon: yes? 14.10.34 # do you remember issues with the fm skin patch? 14.12.30 # I'm resyncing with the intention of commiting soon 14.12.51 # not since you fixed the issue with unknown presets but I haven't played around with it since. And well the difference to the current radio screen, especially the peakmeters/prerecording time on hwcodec 14.14.11 # well, I dont have a hwcodec+ radio target, so unless someone steps up.... 14.15.04 # the "peakmeter on its own line" thing is there in the WPS too 14.15.38 # wodz : I guess we should start bisect from r25700 14.16.30 # mt: ok I can look at this after dinner :-) 14.16.51 # what is it supposed to look like? 14.17.11 # wodz: ok. I'll bisect a little now. :) 14.18.28 # I can do the rest but the ability to put the peakmeter inside conditionals is something that would need to be coded. JdGordon: on hwcodec the fm screen shows a peakmeter which is replaced by the prerecording time (actually counting up) if you have that set 14.19.16 # ok, well work around the fact that pm cant be in a conditional for the time being and make the screen fit 14.26.38 Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) 14.26.44 Join pamaury_ [0] (~c2c7a50a@rockbox/developer/pamaury) 14.27.08 # Updated the bug report at FS#11255: wav file resume crashes the player. 14.27.33 # I find the info important though... hopefully there is another place to put it 14.29.25 # Blue_Dude: metadata inpure wav files? 14.29.41 Quit pamaury (Ping timeout: 252 seconds) 14.30.01 # The wav file is old. It certainly didn't crash the player before. 14.30.02 # I also had one and it crashed the player but I know metadata is not standard in PCM wave 14.30.29 # Seems to me that codecs ought to tolerate metadata, not crash. 14.30.34 # wodz: was the clock set up taken from the OF? 14.31.10 # I agree a crash is not nice, the least it should do is reject the file 14.31.48 # if it's unable to play it for whatever reason 14.32.09 # Blue_Dude: thanks for the hotkey menu cleanup by the way :) 14.32.32 # You're welcome. 14.33.40 # * JdGordon thinks the peak meter handling is braindead compared to the newer stuff :p 14.34.39 Join arbingordon [0] (~w@unaffiliated/arbingordon) 14.38.58 # Yeah, I created a version of the wav with the same audio content but no metadata and it doesn't crash. Something happened in the last week or so to not tolerate metadata. 14.40.10 # haha sweet! peakmeter working in conditionals was simple 14.40.53 # needs some proper testing though... any takers? 14.41.31 # Blue_Dude: the one that crashed for me was ages ago but I guess since metadata in wave is not standard that there can be differences depending on how it was tagged exactly 14.41.58 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 14.42.08 # JdGordon: I would but my laptop is currently busy with music encoding 14.42.19 # can i give you a build then? 14.42.21 # I didn't even know it had metadata in it. 14.42.53 # I'm doing a binary compare of the two files to find out what's going on. 14.42.57 # JdGordon: yeah, I think a c200 build would be easiest (as that one is standard) 14.43.34 # you dont need the whole zip if you are running pretty close to svn 14.43.41 # so do i need to do the whole zip? 14.44.32 # you can do OndioFM too (would be nice if you could do a backlight build - set in the advanced build options) 14.45.17 # maybe the latter is more interesting and I shouldn't need the whole zip there, only the ajbrec.ajz 14.45.52 # http://jdgordon.info/rockbox/rockbox-c200.zip 14.46.25 # this is just peakmeters in conditionals, no fm skin patch 14.46.52 # understood, I will just set up a simple test.wps 14.46.52 # Blue_Dude: uchida added some wav metadata parsing recently, could be the cause, the sim is usually easier to debug for this type of bugs 14.47.31 Quit Schmogel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 14.47.48 # n1s: understood. First I need to find out what's different between the two files, then maybe I can find out what the parser is choking on. 14.48.08 Quit Buschel (Ping timeout: 248 seconds) 14.48.28 # maybe bisecting for the commit that breaks it could also help 14.48.47 # http://jdgordon.info/rockbox/ajbrec.ajz < ondiofm+backlihgt 14.49.23 # Hm. Two bytes difference... Weird. 14.49.52 # I mean, that's really weird. 14.50.30 # Blue_Dude: how's your mixer patch going? 14.50.34 # Off to the hex editor I go. 14.50.37 # JdGordon: downloaded 14.50.54 # id guess r25898 or r25911 14.50.56 # kugel: Delayed by wav bugs and hotkey patches. :) 14.51.08 # Other than that, not bad. 14.53.06 # JdGordon: I'm just reminded as I see it again that the statusbar in the early USB screen vanished in recent builds 14.53.25 # put it on FS 14.56.26 # JdGordon: is the "old" statusbar supposed to appear for splash screens? I got that in the WPS screen before I took out the hotkey splash. 14.57.16 # oh hmm... yeah it could now if your wps disables the theme 14.57.42 # I've been using cabbie, which does disable the status bar. 14.57.57 # no, ignore that 14.58.00 # it shouldn't 14.58.32 # Blue_Dude: where do you see this splash? 14.58.32 # The splash is gone so I can't reproduce, but pixelma's comment reminded me of it. 14.58.52 # if it was shown by the menu then it would show it 14.58.58 # I got it when the "Hotkey Not Set" splash came up. 14.59.10 # In the WPS. 14.59.22 # which was called after the wps reenables the theme, so yeah expetced 14.59.34 # simple-ish to fix but if its not an issue anymore 14.59.35 # ... 14.59.37 # OK, just seemed odd. 15.00.01 # I'm not sure there are any other splashes in the WPS. 15.00.54 # JdGordon: pm in the conditional seems to work on both - the c200 and the Ondio - tested with a simple test.wps that just shows pm on hold and nothing when unlocked 15.01.13 # thats how i tested on sim also.. ok good 15.02.01 # New commit by 03jdgordon (r25913): slightly rework peakmeter handling to make it cleaner and be able to be used in conditionals 15.02.03 # one thing to look out for might be scrolling lines elsewhere 15.02.40 Quit MethoS- (Remote host closed the connection) 15.03.55 # nls: clock setup You mean setup of timer to perform system tick? 15.04.58 # pixelma: do you tihnk you can do the hardcoded fms in the next few days now that is fixed? 15.05.29 # I think so, when an updated patch is available 15.07.10 # the one i uploaded 20min ago works 15.07.20 # scrolling lines alongside such a conditional peakmeter work by the way. I just remembered there were some problems before with %pm in conditional viewports for a while before which is why I tested 15.07.44 # ok, will have a look 15.07.54 # do you remember the FS# for that bug? 15.08.04 # I remember it haunting me and not being able to figure it out 15.08.11 # OK, here's what I have on the wav file. The one that behaves only contains audio chunks. The one that doesn't contains a metadata chunk at the end. Other than the metadata chunk they are identical, except for two bytes in the header. Those two bytes are the low end bytes of a four byte integer describing the total chunk size of the wav file. My guess is that for some reason, the parser... 15.08.13 # ...is not ignoring the metadata but somehow trying to read it as an audio subchunk. 15.09.01 # JdGordon: the peakmeter in conditional viewports is fixed but I don't remember the FS# for it 15.09.12 # it was fixed? ok cool 15.09.13 # IOW, the parser assumes that if a subchunk exists in the total count, it must be audio. 15.09.18 # are any arm-elf toolchain wizards awake, yet? 15.10.27 # JdGordon: need to test again but I saw it in one of my WPSs and think it was fixed. I can easily test though 15.11.11 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 15.12.04 # need some help with bootloader.bin on -mcpu=arm1176jz-s. seems to produce broken boot/installer images 15.14.49 # JdGordon: the WPS that was affected seems to work fine now (r25710 on my M5... so slightly old but I don't think it's broken again) 15.14.52 # Anyway, the bug report is updated again, and I have to go to work. Again. Later! 15.14.57 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 15.14.58 # though you never know 15.18.14 Join petur [0] (~petur@rockbox/developer/petur) 15.19.12 Join Llorean1 [0] (~DarkkOne@adsl-99-158-45-131.dsl.hstntx.sbcglobal.net) 15.19.59 Quit M3DLG (Quit: RAGE QUIT) 15.21.48 Quit ncfi1013 (Quit: Leaving) 15.22.47 Quit antil33t (Read error: Connection reset by peer) 15.22.53 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 15.23.11 Quit Llorean (Ping timeout: 240 seconds) 15.28.22 # okay, rechecked with same code, same setup and the only difference being -ma 15.28.22 # ls 15.28.30 # whoops 15.29.22 Quit komputes_ubuntu (Quit: I haven't slept for ten days, because that would be too long.) 15.29.39 Join komputes_ubuntu [0] (~komputes@ubuntu/member/komputes) 15.29.51 # ... with the only difference being -mcpu=arm7tdmi vs. -mcpu=arm1176jz-s 15.30.16 Quit stoffel_ (Remote host closed the connection) 15.30.58 # wodz, kugel : bisect results in r25850 being the commit that caused the error in audio playback in the sim. 15.34.19 Join M3DLG [0] (~M3DLG@bb-87-81-252-83.ukonline.co.uk) 15.41.17 Quit kugel (Remote host closed the connection) 15.42.00 Join kugel [0] (~kugel@rockbox/developer/kugel) 15.43.29 Quit petur (Ping timeout: 268 seconds) 15.45.54 Quit arbingordon (Quit: `) 15.46.39 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 15.47.17 # Anyone having audio working fine in the sim with current svn ? 15.47.38 *** Saving seen data "./dancer.seen" 15.47.52 # mt: can you play audio at all? 15.49.45 Quit Jaykay (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 15.50.03 # kugel : you mean outside the sim ? 15.50.13 # no, in the sim 15.50.22 # I have no problem playing audio 15.50.50 # Then it could be something in my drivers, I'll check 15.50.53 Quit bluebrother (Disconnected by services) 15.50.55 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 15.52.44 # mt: I meant: does it refuse to play entirely or does the error appear after some minutes?? 15.52.44 # kugel: I can't play audio at all in the sim 15.52.54 # No entirely 15.53.27 # Example : Once you select a file for playback, it crashes 15.53.49 # mt: various codecs? 15.54.17 # hm, something is not alright here too. it skips sometimes 15.54.34 # gevaerts: No, I tried one file and plugin alarm clock 15.55.34 # mt,kugel: my bisecting ends up at r25850 also 15.57.02 # I didn't updated system for quite some time so this is not system side error 16.05.00 # wodz, mt: try http://pastie.org/952449 please (make sure you re-create the Makefile) 16.05.22 Join petur [0] (~petur@rockbox/developer/petur) 16.05.52 # it solves the skipping for me 16.07.57 # * wodz compiling 16.09.03 # I'm compiling now too, but will probably be slower than wodz 16.09.42 # no it didn't help 16.13.27 # kugel: fails here too. 16.14.16 Join arbingordon [0] (~w@unaffiliated/arbingordon) 16.17.37 # New commit by 03kugel (r25914): Remove -U_GNU_SOURCE again (was added in r25850). It turns out SDL doesn't work properly with it. The reason I added it for doesn't exist anymore (or, ... 16.18.07 # mt: unfortunately, I don't have the slightest idea what could cause that 16.18.19 # the commit didn't really make any code changes 16.19.24 # Maybe the problem is with my system then ... I'll see 16.19.32 # JdGordon: Yo 16.20.23 Join Jaykay [0] (~chatzilla@p5DC57141.dip.t-dialin.net) 16.24.51 # * kugel googles the error and finds http://www.rockbox.org/wiki/UiSimulator#3_Run_UIsimulator 16.27.28 # and also a mailing thread from 2006 where the same problem occurs 16.28.55 # kugel: but befor r25850 I didn't get this errors and sim worked ok 16.30.24 Join hellelujah [0] (~59a10eb2@giant.haxx.se) 16.30.30 # AlexP: hey, been a while :) trying to get back into the fms patch and get it commited.. remember any issues? and which target were you testing on that needed a good buffer bump? 16.31.08 # I can't remember any specific ones - the H140 needed a large buffer bump (I think principally due to multifont) 16.31.18 # And yes, it has been a little while :) 16.31.18 Quit hellelujah (Client Quit) 16.35.19 # wodz: I believe you 16.35.40 # with cabbie there its 17KB free so as long as the backdrop image is reused that should be plenty, for the time being anyway 16.35.52 # the issue came up in past apparently, I wonder if it was fixed or just disappeared 16.35.54 # we really need to come up with a more flexible buffer stratergy 16.37.29 Join hellelujah [0] (~59a10eb2@gateway/web/freenode/x-krxkundxvdlwyxry) 16.38.22 # Hi. Would iPod nano 4th gen ever be supported? 16.38.39 # if someone does the work, then yes. 16.38.41 # hellelujah: You are free to port :-) 16.39.03 # If I could... 16.39.10 # Bagder: can you remember how you resolved that issue? 16.39.12 # Not enough skill. 16.39.20 # Thanks. 16.39.24 # Bagder: I'm refering to http://www.rockbox.org/mail/archive/rockbox-archive-2005-07/0212.shtml 16.39.27 Part hellelujah 16.40.56 # kugel: tried looking at the old x11 code in svn? 16.41.26 # no 16.46.54 Join Xerion [0] (~xerion@82-170-197-160.ip.telfort.nl) 16.47.22 # not really expecting this to go anywhere, but how would people feel about chaning the skin language to use [] for paramterised tags? %V[a|b|c...|] ? and also getting rid of "extra stuff" on tags (i.e %Xda would change to %Xd[a]) 16.47.42 # I think we could make the parser much simpler if we did that, and it should make it more readbale 16.48.56 # JdGordon: I had that idea before, and I'm all for it 16.48.58 # those changes could be done in a script for all existing themes 16.49.21 # I think I even posted it here ;) 16.50.26 # JdGordon: without knowing any details it sounds good :) 16.51.06 # who is doing the theme editor gsoc? 16.52.31 Quit n1s (Read error: Connection timed out) 16.53.48 # JdGordon: bieber is the student, I'm mentoring. 16.54.51 # IIRC he was already asked about such a change and considered it a pretty easy change for the editor 17.01.56 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 17.05.43 # JdGordon: I'd like the too and if it makes the parser simpler then the better 17.06.05 # may I ask to look at FS#11254? 17.06.15 # the ; tag could cause problems 17.06.34 # I wonder if there is any way we could get away from the line based system we have now? 17.06.35 # because of the %t? 17.07.01 # no, because it is not really a tag 17.07.21 # %t would become %t[number] 17.07.33 # i.e tags with any args would HAVE to have the []'s 17.11.39 Quit esperegu (Ping timeout: 246 seconds) 17.12.21 Join esperegu [0] (~quassel@145.116.15.244) 17.15.28 Quit TheSeven (Ping timeout: 246 seconds) 17.15.34 Quit komputes_ubuntu (Ping timeout: 240 seconds) 17.17.34 # JdGordon: I would prefer () though 17.17.41 Quit antil33t (Read error: Connection reset by peer) 17.17.48 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 17.17.51 # either work for me 17.17.58 Quit esperegu (Read error: Connection reset by peer) 17.18.45 Join esperegu [0] (~quassel@145.116.15.244) 17.20.22 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 17.20.49 # mt, wodz: sound is also fine on my laptop 17.21.54 Join wincent [0] (~wincent@g227130094.adsl.alicedsl.de) 17.22.03 Quit wincent (Changing host) 17.22.03 Join wincent [0] (~wincent@rockbox/developer/wincent) 17.23.57 # how about using {}? ;-) 17.25.01 # kugel: I glanced at r25850 patch and I don't see any reason why it changes anything but apparently it does 17.27.33 # mt: you say you compile under a vm? 17.27.46 # VBox? which distro? 17.27.49 # bluebroth3r: wouldn't be that bad as I use () and [] sometimes just like that in the WPS or tags, but don't do so with {} 17.28.19 # it also gives a tex touch ;) 17.28.47 Quit evilnick (Ping timeout: 245 seconds) 17.29.44 # * kugel goes trying to repro it in a vm 17.29.46 Quit kugel (Remote host closed the connection) 17.30.23 # pixelma: I wasn't completely serious, I don't care much about it. However, having some opening-closing-braces sounds like a good idea to me. IMO a clash with literals shouldn't happen because a tag always starts with a % 17.32.45 # * gevaerts prefers <> 17.32.57 # thought so, but for reading the .wps file {} would look a bit more like "code" to *me* 17.33.09 Join robin0800 [0] (~quassel@149.254.180.235) 17.33.10 # gevaerts: clashes a bit with conditionals 17.33.23 # pixelma: then conditionals should be changed! 17.33.46 # of course 17.34.14 Join komputes_ubuntu [0] (~komputes@ubuntu/member/komputes) 17.37.36 # kugel: yeah virtualbox .. ubuntu but a quite old version .. (8.04 I think) 17.38.26 # yeah 8.04 17.39.36 # mt: that's curiose I use (x)ubuntu 8.04 also 17.39.45 Join kugel [0] (~kugel@rockbox/developer/kugel) 17.40.09 # wodz: I wanted to ask you about your distro but I totally disregarded that 17.41.01 # tomorrow I can check on some debian and newer ubuntu 17.41.31 # kugel: I think it's leaning more & more towards being a system error rather than being a rockbox bug. 17.42.04 # mt: not quite - sim used to work and at r25850 stopped 17.44.47 # wodz: While searching for the errors, there was some link about a bug with alsa in 9.10 (didn't open it so not quite sure of the content) .. but anyway I just think that the possibility is higher now that it's something with our systems, imho. 17.46.10 # mt: It *may be* combination patch & system but we should be sure about that and moreover this shouldn't happen :-) 17.46.51 # New commit by 03alle (r25915): Manual: Bookmarking update (FS#11227 by Magnus Holmgren) 17.47.16 # and I use this system daily with a few SDL apps and I don't have any problems 17.47.40 *** Saving seen data "./dancer.seen" 17.51.41 Join wincent_balin [0] (~wincent@g227130094.adsl.alicedsl.de) 17.51.44 Quit wincent (Ping timeout: 268 seconds) 17.52.22 Quit wincent_balin (Changing host) 17.52.22 Join wincent_balin [0] (~wincent@rockbox/developer/wincent) 17.54.17 Quit wincent_balin (Client Quit) 17.54.47 Join wincent_balin [0] (~wincent@g227130094.adsl.alicedsl.de) 17.54.50 Quit robin0800 (Remote host closed the connection) 17.55.47 Quit wincent_balin (Client Quit) 17.56.16 # wodz: what I meant was that the patch _might_ have exposed a bug in the system, because quickly skimming through it, I can't really find a change that has a direct relation with that error. 17.56.51 Join wincent [0] (~wincent@g227130094.adsl.alicedsl.de) 17.57.11 Quit wincent (Changing host) 17.57.11 Join wincent [0] (~wincent@rockbox/developer/wincent) 17.58.52 Join ansuz [0] (~ansuz@c-98-219-218-216.hsd1.pa.comcast.net) 18.00.25 # New commit by 03alle (r25916): Use typographic quotation marks 18.08.10 Join Schmogel [0] (~Miranda@p3EE22857.dip0.t-ipconnect.de) 18.09.32 # mt: "success" I get the error in a vm 18.09.46 # Same distro ? 18.10.00 # no, debian as of sept 2009 or so 18.10.17 Join Buschel [0] (~ab@p54A3C547.dip.t-dialin.net) 18.10.45 # I'll try if updating helps. but I need to backup the old image so that I don't lose my repro system 18.10.47 Join flatrose [0] (~flatrose@ppp91-77-234-156.pppoe.mtu-net.ru) 18.19.07 Join domonoky1 [0] (~Domonoky@g229247058.adsl.alicedsl.de) 18.19.54 Quit domonoky (Ping timeout: 246 seconds) 18.24.42 Join n1s [0] (~n1s@rockbox/developer/n1s) 18.31.41 Join CaptainKewl [0] (~jason@207-237-106-60.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 18.48.38 Quit komputes_ubuntu (Ping timeout: 248 seconds) 18.50.38 Join komputes_ubuntu [0] (~komputes@ubuntu/member/komputes) 18.52.31 # Is there a way to overclock iPod 5.5G's processor to 100mHz(+) using rockbox? I know it will drin more power but the heat would keep my HDD spinning at -30 next winter. 18.53.44 # flatrose: yes, ask Buschel for details 18.54.45 Quit wincent (Ping timeout: 240 seconds) 18.55.12 Join wincent [0] (~wincent@f055124017.adsl.alicedsl.de) 18.55.27 # flatrose, infact, search flyspray for all patches by Buschel and you'll quickly find it. 18.55.46 # though many iPods appear unstable above rated speed. 18.59.08 # I was away when the tag syntax topic came up a little while ago, but I'd like to chime in and say that it would make things really immensely simpler to parse, and I'm all for it 19.00.17 Quit komputes_ubuntu (Ping timeout: 264 seconds) 19.01.22 Nick Llorean1 is now known as Llorean (~DarkkOne@adsl-99-158-45-131.dsl.hstntx.sbcglobal.net) 19.01.26 Quit Llorean (Changing host) 19.01.26 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 19.10.59 Quit esperegu (Ping timeout: 240 seconds) 19.11.44 Join komputes_ubuntu [0] (~komputes@ubuntu/member/komputes) 19.11.46 Join hpmaniac [0] (~4eac8a83@giant.haxx.se) 19.11.48 # And as for ;'s, my suggestion would be to replace them with an actual tag that has multiple parts, like the conditionals, which should also be a lot easier to parse than what we have now 19.12.28 # But I don't know how the theme engine handles parsing and rendering, so it may be easier for that the way it is now... 19.12.30 # hi there 19.13.00 Nick kisak_ is now known as kisak (~kisak@c-98-235-209-218.hsd1.pa.comcast.net) 19.13.20 Quit hpmaniac (Client Quit) 19.13.59 Quit mt (Ping timeout: 240 seconds) 19.18.12 # thanks for the answers, guys! 19.20.27 Join mt [0] (~mtee@rockbox/developer/mt) 19.21.25 # bieber: can you give more details about this suggestion? JdGordon recently suggested a %t5<1st part|2nd part|etc.> and I didn't like it at all. It's not easier to read and is less flexible than what we have now. With this every subline has the same timeout while you can have different timeouts now 19.21.55 # it's even harder to read when there are conditionals in each subline 19.22.40 # Perhaps enclose each subline in its own tag that can optionally include its own time value, the way HTML has
    /
      and
    1. ? 19.23.54 # bieber: I think the current sublines can be pretty readable - you always know that after a semicolon you're on a new on. If you had multiple characters doesn't it just make each transition more cluttery? 19.24.04 # *new one 19.24.12 # Probably 19.24.19 # I don't know. From a user's perspective ; with optional %t are quite readable 19.24.27 # An explicit tag would just mean that instead of semicolons, we have %nL or something 19.24.58 # I'm really not sure what the best way to approach it is. Adding explicit delimiters for every line will make it less readable, but easier to parse 19.25.24 # with the exception that you need to write %; if you want to just display a ; in your WPS 19.26.17 # Perhaps allowing newlines between lines would help readability? 19.26.20 # bieber: I think what would make many WPSes easier to parse for the reader is if they used the commented line break (assuming that still works) to put sublines on multiple lines. 19.26.43 # bieber: You used to be able to end a line with a # to "comment out" the newline, so that you could write more of it on a second line. 19.26.52 # bieber: you could already do that by "commenting out" the line-ending 19.27.04 # Okay 19.27.07 # not used much though 19.27.34 # If you can use newlines, it shouldn't be bad to read/write 19.28.48 # I don't know if that feature's well documented / documented at all, though 19.28.50 # Perhaps something like %Ms{ %Mi{line|optionaltime} %Mi{line|optionaltime}}, depending on the names/delimiters that get chosen for the tags 19.29.35 # Llorean: The CustomWPS wiki entry I've been working off of does say that a comment includes its newline, but it doesn't point out that you can use that feature to break up tags into multiple lines. Perhaps I should add that to the page? 19.29.36 Join esperegu [0] (~quassel@145.116.15.244) 19.30.04 Join saratoga_ [0] (~463f90ed@gateway/web/freenode/x-lzxwguthctscjalg) 19.30.43 # bieber: What tag would you be breaking into multiple lines? 19.30.55 # Tags can never span sublines, so when you create a subline you're not breaking up a tag. 19.31.42 # Well, if we enclosed the sublines in a container tag. Although in general, you _could_ split a tag's options across multiple lines with commented newlines, right? 19.32.02 # maybe the timeout tag can be the sign "start a new subline here"? Although that takes away the possibility to put the %t anywhere in the subline and you wouldn't be able to leave it out and let it use the default time (2s IIRC) 19.32.25 # flatrose: http://www.pastebin.org/213928 will set the clock to 100MHz max, 24MHz default, and will boost while GUI activity 19.32.35 # bieber: Why are you back at putting sublines in a container tag again? That seems like it would generate a lot of additional {} and clutter? 19.33.21 # it would be nice to put the %t inside conditionals again BTW which was possible before the tokenizer 19.33.59 # Well, it would add two additional braces ;) It's just an option that would make parsing a little bit easier, whether to include it for readability is another issue 19.34.01 # pixelma: So depending on which condition was true, the line had variable possible display times? 19.34.29 Quit esperegu (Ping timeout: 264 seconds) 19.34.42 # yes, you could even surpress it this way. If I recall there is still an example with %t0 somewhere in the Wiki 19.36.19 # * Llorean thinks that would be very nice to have back 19.37.09 # anyone want to look at the license in FS#11256 and guess if the lib is GPL safe or not? 19.37.48 # theres actually two nearly identical versions of the TTA decoder floating around, one LGPL, one that license, so i guess if not it could be fixed 19.39.25 Join archivator [0] (~archivato@stu0279.keble.ox.ac.uk) 19.40.05 # In any case, I'm going to build a generic tag-parsing function for libwps, so once it's decided whether to add delimiters, they'll be easy to implement 19.40.21 Join Strife89 [0] (~Strife89@adsl-80-151-128.mcn.bellsouth.net) 19.44.28 Join esperegu [0] (~quassel@145.116.15.244) 19.45.10 # skimming that license, the only real restriction added is that you have to maintain the copyright notice, and that you cannot use the authors name without his permission, which appears to be GPL ok since the GPL allows a copyright notice and doesn't grant you the right to the author's name 19.45.16 # but i have no real idea 19.45.17 Join lpereira [0] (~lucien@112.46.70-86.rev.gaoland.net) 19.45.31 # Buschel - is that the same as, or different from, the fs# patch? 19.45.33 # why couldn't uchida just use the explicitly gpl source download :( 19.46.07 # bieber: did you decide whether to reuse the existing code or not already? 19.47.00 Quit archivator (Ping timeout: 246 seconds) 19.47.28 # saratoga: that's bsd afaict, should be gpl safe 19.47.30 # saratoga_: If you have to maintain the copyright notice, but you can't use the author's name without permission, doesn't that restrict your ability to use the code (since that includes the copyright notice and thus the name?) 19.47.43 *** Saving seen data "./dancer.seen" 19.49.08 # "Neither the name of the True Audio Software nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission." 19.49.40 # kugel is right that is the BSD license 19.49.48 Quit esperegu (Ping timeout: 246 seconds) 19.50.11 # or rather "BSD-new" 19.50.16 # according to wikipedia 19.50.48 # it's possible though that the last clause bites with gpl 19.51.53 # the last clause is strange since trademarks are implicitly reserved anyway, though maybe theres some country out there where they needed this 19.52.18 Join MethoS- [0] (~clemens@134.102.106.250) 19.52.46 # FSF says its GPL friendly, so good enough for me 19.54.20 Join esperegu [0] (~quassel@145.116.15.244) 19.54.48 Quit TheSeven (Ping timeout: 265 seconds) 19.59.22 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 20.02.24 Quit loveless (Quit: loveless) 20.06.04 Quit petur (Quit: *plop*) 20.06.52 Join archivator [0] (~archivato@stu0279.keble.ox.ac.uk) 20.08.26 Join kyraxyg [0] (~4eb5065e@giant.haxx.se) 20.11.40 # kugel: iirc, that x11 asound experiments of mine never got anywhere, we dropped it and later proceeded with the SDL way 20.20.26 Join kugel_ [0] (~kugel@e178062057.adsl.alicedsl.de) 20.20.26 Quit kugel_ (Client Quit) 20.22.19 Join petur [0] (~petur@rockbox/developer/petur) 20.26.58 Quit esperegu (Ping timeout: 240 seconds) 20.33.33 # New commit by 03alle (r25917): Use typographic quotation marks -- correct more places 20.33.42 Join esperegu [0] (~quassel@145.116.15.244) 20.39.45 Quit saratoga_ (Quit: Page closed) 20.40.17 Join CGL [0] (~CGL@190.79.143.119) 20.40.58 Quit mt (Ping timeout: 240 seconds) 20.44.01 # stripwax: no. the patch I've just pastebin'ed is a 100MHz-version of the FS-version. not all iPods run stable >=100MHz. 20.48.55 Quit MethoS- (Remote host closed the connection) 20.48.59 Quit komputes_ubuntu (Ping timeout: 246 seconds) 20.51.45 Join MethoS- [0] (~clemens@134.102.106.250) 20.53.27 Join mt [0] (~mtee@rockbox/developer/mt) 21.01.50 Join TechnoKat [0] (~TechnoCat@c-98-223-163-190.hsd1.in.comcast.net) 21.03.33 # Buschel : gotcha 21.05.20 Quit kyraxyg (Quit: CGI:IRC) 21.06.29 # anything speaking against submitting FS#11253 ? 21.07.12 # it's ok for me 21.08.19 # speaking of test_mem it would be nice to post results from different targets on wiki (like for test_disk, batery_bench, test_codec, test_fps...) 21.08.21 Quit wincent (Ping timeout: 240 seconds) 21.10.40 # we should add ams for coldfire as well, gcc pretty much never generates movem instructions except for stack stuff in pro and epilogs 21.10.46 # s/ams/asm/ 21.11.24 # What for, specifically? 21.12.08 # if we want to get closer to the bandwidth thoroughput of the ram 21.12.33 # wodz: Btw, did you see my optimisation for ata-as-coldfire.S? It could be ported to hd200 - I just didn't want to do that as I can't test it 21.13.01 # It doesn't noticeably improve speed - it saves a few instructions though 21.13.15 # amiconn: yes I saw this 21.13.17 # n1s: Does the test use memcpy() / memmove() 21.13.20 # ? 21.13.43 # amiconn: no, that is probably a better ide 21.13.45 # a 21.14.04 # I didn't check - those functions are asm monsters on coldfire, utilizing movem in as many alignment cases as possible 21.14.16 # * amiconn wrote them 21.14.38 # They're in iram as well (it's not *that* important though) 21.14.48 # amiconn: the plugin test write and read seperately 21.15.25 # Buschel: the patch looks good if you ask me 21.15.40 # Wouldn't it make more sense to bench the mem*() functions? 21.15.57 # Btw, that's what my old test_mem.rock did (which never made it to svn) 21.15.58 # hmm, that read case looks like gcc could DSE all but one of the loads since they store into the same var in the loop... 21.16.25 # * amiconn just remembered what it did... 21.16.57 # amiconn: could You please look at optimized writes in ata-as-hd200.S? I can't track down where is the problem with byte swaps. 21.17.18 # Is there still a problem? I thought it would be working now 21.17.35 # amiconn: could I also ask You to run current test_mem on CF target? 21.18.00 # amiconn: optimized writes makes test_disk fail 21.18.25 Join ischeria1 [0] (~ischeriad@p5B0A1524.dip0.t-ipconnect.de) 21.18.40 # but I finally squashed bug and greylib is working on HD200 :-) 21.19.23 # hello. are here any developers familiar with the iriver story (ebook reader)? 21.19.37 # * kugel has a suspicion re sim audio problem 21.20.28 # meh 21.21.04 # Whenever I'm looking at some arbitrary asm in rockbox, I find something that's not optimal :\ 21.21.26 # No matter whether it was originally written by me 21.23.28 # New commit by 03Buschel (r25918): Submit FS#11253. Rework of test_mem plugin to bench DRAM and IRAM. Also add ARM assembler and change the result format. 21.24.30 # wodz, mt: try this one: http://pastie.org/952773 it works for me 21.24.41 # * Buschel waits for red to come... 21.25.10 # amiconn - any of mine? 21.25.33 # No idea. This time it's coldfire strlen - that's written by n1s 21.26.44 # amiconn: i know about that, i actually have a half finished version somewhere that loads words at a time and use the magic test trick to check the whole word for nullbytes 21.26.52 # wodz: Btw, as I see you replaced jeq by beq in ata-as-mpio.S: There are two versions of beq, beq.s and beq.w 21.27.09 # just haven't had time to finish and bench it 21.27.17 # The former is shorter (no extension word) than the latter, but it's limited in branch distance 21.27.53 # ischeria1: I doubt it - this is the first time anyone hs mentioned it 21.28.18 Nick ischeria1 is now known as ischeriad (~ischeriad@p5B0A1524.dip0.t-ipconnect.de) 21.28.23 # If you write just beq, the assembler will always choose beq.w - that's what the jeq pseudo-instruction is for: it makes the assembler use the shortest possible version for the branch distance 21.28.45 # well didn't have time before i left it on my desktop at home, but will try to finish it in a few days 21.29.01 # n1s: Reading a byte at a time might be elegant - but it's sloooooow when going through dram 21.29.43 # well, i remember it benched faster than gcc's mess at least but yes, it's hardly optimal 21.30.39 # AlexP: not long ago, iriver released the sources for the story firmware. I do not know if there are any independent developers yet and where to find them 21.30.51 # as i said, i will try to finish my new version when u get home in a few days 21.31.04 # s/ u/ i/ 21.31.14 # ischeriad: Not here at any rate :) I'd try to find owners sites or the like 21.31.14 Quit bertrik (Quit: De groeten) 21.33.58 Quit mt (Ping timeout: 240 seconds) 21.34.16 Quit n1s (Quit: Lämnar) 21.34.34 # AlexP: alright 21.36.26 Join mt [0] (~mtee@rockbox/developer/mt) 21.37.34 # kugel: I get corrupt patch at line 21 21.37.40 Quit GeekShadow (Quit: The cake is a lie !) 21.38.40 # ok newline was missing 21.41.18 Quit mt (Ping timeout: 240 seconds) 21.42.11 Quit TechnoKat (Quit: Leaving) 21.42.57 # kugel: this patch works for me 21.43.11 # awesome 21.45.56 # wodz: Hmm, I can't spot an obvious problem in the hd200 ata write :\ 21.46.17 # wodz: what system are you on, btw? 21.46.29 # kugel: (x)ubuntu 8.04 21.46.37 # However, you can optimize the swaps wherever only 16 bits are needed. No need to fiddle with the mask... fewer instructions 21.46.53 # wodz: hm, mt too, maybe it's fixed in newer kernels 21.47.12 # it seems to work for kernels newer than 2.6.30 21.47.18 Join mt [0] (~mtee@rockbox/developer/mt) 21.47.41 # kugel: I can test this tomorrow on (x)ubuntu 9.04 and on some debian 21.47.45 # kugel: Worked for me ! 21.47.47 *** Saving seen data "./dancer.seen" 21.48.38 # amiconn: I am aware of this but as this function fail I tried to eliminate as much irregularities as possible to narrow down the problem 21.48.46 # yeah 21.48.47 # kugel: Are you going to commit it ? 21.48.55 Join evilnick|ipad [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 21.48.58 # trying to, yes :) 21.49.04 # :) 21.49.11 # this vm is a pain 21.52.00 # wodz: Hmm, asm optimised reading works? 21.52.34 # amiconn: yes 21.53.24 # Now that is odd 21.54.04 # To me it looks like there is a problem in unaligned read. Need to check thoroughly... 21.55.18 # amiconn: optimised read + general write pass test_disk test 21.56.06 Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) 21.58.22 # New commit by 03Blue_Dude (r25919): Fix wav metadata bug, also fix typos and some const police 21.58.43 # :) 21.58.57 Join ender [0] (krneki@foo.eternallybored.org) 22.00.18 Quit ender` (Ping timeout: 240 seconds) 22.00.53 Quit kugel (Quit: exit(0);) 22.02.53 Nick ender is now known as ender` (krneki@foo.eternallybored.org) 22.03.48 # wodz: Yet there *is* a problem in unaligned read if there is no single 16 bit word to be handled after the first byte 22.04.09 # It will write the first byte twice, omitting the actual second byte 22.04.17 # (write to memory of course) 22.05.43 Join kugel [0] (~kugel@rockbox/developer/kugel) 22.07.17 # New commit by 03kugel (r25920): Undo a change of r25850 which broke SDL audio on some (older kernels?) systems. 22.10.41 # so, hopefully all my latest bugs are squashed out now so I can move on with raaa :) 22.14.42 # wodz: What I mean is that %d2 is only pre-swapped when entering longword/line loops if there is an initial byte+word 22.15.22 # kugel: you can always move on and fix bugs later when they're found :) 22.15.38 # kugel: Fixing that specific bug will let me go on with my project too. :) 22.15.42 # If there's just a byte and not a word, it's not pre-swapped, hence the first move.l to RAM will have the topmost byte wrong 22.16.09 # * amiconn wonders whether C writing makes up for that read bug so that test_disk works overall 22.16.35 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 22.17.13 # wodz: Can you test with both C reading and writing? Also, can you compare md5sums of audio files calculated using the md5sum plugin with md5sums calculated on PC? 22.17.31 # Also, are there audible glitches when playing music? 22.17.57 # I doubt that though since buffering aligns these days 22.18.10 # Hmm, md5sum will probably do the same 22.20.05 Quit FlynDice (Ping timeout: 264 seconds) 22.20.21 # A similar problem exists for the final word in the unaligned read: If there is one, the leftover byte from the last longword is wrong, since it is swapped twice 22.23.44 # * amiconn wonders why MPIO didn't use the (dead simple) hardware swap like iriver and cowon 22.24.01 # gevaerts: I'll start the target tree work. The discussion on the ml wasn't quite a discussion but it confirmed my plams 22.24.04 # plans* 22.25.03 # kugel: yes, I think it's clear that people either agree or don't care much, which is good enough 22.25.35 Quit flatrose (Ping timeout: 265 seconds) 22.25.37 # alright, fine 22.26.11 # It's just that the ata data lines are connected the "wrong" way - that's why iriver & iaudio have their commands & status words defined different than the rest 22.27.21 # kugel: to be honest, I prefer this to a long flamewar :) 22.27.47 # me too :) 22.32.50 # Hmm. It's strange though. The C versions are looking 100% correct - so I don't understand why optimized reading on MPIO doesn't cause problems, but optimized writing does 22.32.57 # I'd expect the opposite 22.33.01 Quit anewuser (Quit: for SELL 2 by the price of 1 now!) 22.35.15 Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) 22.35.27 # AH wait - the writing *does* have problems - even more serious ones 22.36.21 # Combining the words before byte-swapping combines the wrong bytes - and that happens throughout in the unaligned case, not just at the beginning and end 22.36.35 # wodz ^^ 22.37.58 # eh, or not... 22.38.06 # * amiconn is confused 22.39.22 # The unaligned read bug does hold though 22.39.42 Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) 22.39.57 # hi archivator, hows you project going ? :-) 22.42.48 Quit Schmogel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 22.43.00 Nick domonoky1 is now known as domonoky (~Domonoky@g229247058.adsl.alicedsl.de) 22.43.17 Quit domonoky (Changing host) 22.43.17 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 22.43.23 # Can anyone think why mp3_play_data, mp3_play_pause, mp3_play_stop, and mp3_is_playing functions in the plugin API are disallowed for the simulator? 22.43.26 Quit evilnick|ipad (Remote host closed the connection) 22.44.03 # Blue_Dude: are they for hwcodec? 22.44.32 # Strangely enough, no. They go to voice_thread. 22.44.47 # But only for swcodec. 22.46.25 # domonoky: well, I *almost* got it to compile for target but I've stopped working on that aspect for the time being (it's a bit beyond my area of expertise) and am doing fixed-point conversion, using the sim. It's going.. but rather slowly (it's a mess, to put it very, very mildly). 22.46.50 Join FlynDice [0] (~FlynDice@74.10.105.233) 22.47.03 # archivator: would be good ot post patches about that, so others can see it too. 22.47.08 # it's not expected to be easy :) 22.47.27 # gevaerts: time for a first status report I'd say 22.48.09 # * domonoky also would like to remind all students here of the weekly status report in the mailing list... 22.48.10 # domonoky: will do, soon. Want to have something more, though. 22.48.40 # kugel: yes indeed :) 22.49.50 # The hwcodec version is in mp3_playback.c. I don't see why the sim is specifically carved out. 22.50.21 # archivator: especially when you get stuck, post patches on the tracker, and ask for fresh looks at it here or in the mailinglist.. 22.51.44 # domonoky: I'm not really "stuck", it's just hard to grasp all that's going on in flite. I've started drawing diagrams (!), even.. 22.51.55 # I wanted to point plugins to mp3_play_data for sound effects. That's kinda hard to test if the sim doesn't compile them. 22.53.10 # archivator: if you have those diagrams, maybe it would be good to put it into the wiki with descriptions :-) 22.53.59 # domonoky: huh, never though of making them public. Might do something proper, then. My handwriting is horrendous :) 22.55.33 Quit freddy_ (Ping timeout: 265 seconds) 22.57.06 # you dont need to make them public, but if you need them to understand flite, maybe it would be helpfull for others too :-) 22.58.05 Join krabador [0] (~ubuntu@host68-37-dynamic.31-79-r.retail.telecomitalia.it) 22.58.38 # Status updates now ? I thought we did those after the official start of the coding period 22.59.09 Quit wodz (Quit: Leaving) 22.59.11 # I don't see a reason to wait with them 23.00.23 # I wanted to send a mail before though .. but thought I should wait. Will probably send something in the next few days then. 23.00.47 # mt: for students with an extended coding period (due to schedule conflicts), I think the extended period is what matters, not the official period 23.03.33 # New commit by 03Buschel (r25921): Add non-breaking spaces to mA, mAh, MB and GB. Add playertype for iPod Video when describing the different variants. 23.03.55 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 23.08.01 Join freddy_ [0] (~freddy@p3E9E004D.dip0.t-ipconnect.de) 23.08.49 Quit esperegu (Remote host closed the connection) 23.16.15 Quit Jaykay (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 23.18.26 Quit Buschel (Ping timeout: 246 seconds) 23.18.40 Join hebz0rl [0] (~hebz0rl@dslb-088-065-053-186.pools.arcor-ip.net) 23.23.30 Quit pamaury_ (Ping timeout: 252 seconds) 23.23.59 Quit FlynDice (Remote host closed the connection) 23.26.55 # saratoga, linuxstb : The asf parser seems to be parsing wma pro files correctly now .. I'm thinking of committing that, with a wmapro.codec that would just not play for now. 23.27.09 Quit Xerion (Quit: ) 23.27.13 # great 23.27.48 # not much changes at all really .. ASF is being nice till now. :) 23.29.02 Quit archivator (Quit: Leaving) 23.34.13 Quit petur (Quit: Zzzzz) 23.40.08 # Bagder: could you add this new test file: http://duke.edu/~mgg6/true_audio.tta 23.41.30 # saratoga: done! 23.41.33 # thanks 23.42.10 # New commit by 03mt (r25922): nomsg 23.42.26 # oops 23.43.47 # Should I revert that and recommit it with a proper message ? 23.44.17 Quit lpereira (Quit: Leaving.) 23.45.42 Quit domonoky (Read error: Connection reset by peer) 23.47.51 *** Saving seen data "./dancer.seen" 23.49.55 # mt: IIRC Bagder or Zagor can fix that 23.50.14 Quit hebz0rl (Ping timeout: 246 seconds) 23.50.42 Join hebz0rl [0] (~hebz0rl@dslb-088-065-053-186.pools.arcor-ip.net) 23.50.45 # gevaerts: Thanks .. I really hope so 23.52.38 # New commit by 03mt (r25923): Fix ffmpeg revision number in libwmapro/README.rockbox 23.54.22 # i guess I should make some WMA Pro test files too 23.54.29 # Bagder: Can I send you the correct commit message for r25922 so you could fix it ? 23.55.02 # jhMikeS: Does the auto-speed whatever that the GigabeatS does respect plugins that ask to be boosted?