--- Log for 14.07.109 Server: simmons.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 1 month and 11 days ago 00.00.45 # A piezo works best if you feed it its resonant frequency. Of course just for a couple of cycles if you want a click and not a beep 00.00.57 # JdGordon|: http://www.rockbox.org/mail/archive/rockbox-dev-archive-2009-06/0490.shtml 00.01.16 Quit petur ("Zzzzz") 00.02.03 # ah ok 00.02.07 # does anyone see where configure touches /tmp ? 00.02.36 # it seems to be sed failing 00.02.52 # kugel: would you mind testing before committing next time? 00.02.59 # the OF does indeed have a more tone-like quality to it 00.03.28 # testing this way was easier 00.03.31 Quit martian67 (Read error: 60 (Operation timed out)) 00.03.51 # it's a good change anyway, no matter if it fixes my issue 00.04.14 # kugel: if /tmp/ is too small for these here-documents, your system is seriously broken 00.04.41 # i.e. I tested if I didn't break configure itself. My problem really matter for te commit 00.04.47 # +didn't 00.04.59 # kugel: what's /bin/sh? bash? 00.05.01 Quit stripwax ("http://miranda-im.org") 00.05.17 # it might make sense to make the build client run with LANG=C 00.05.30 # bluebrother: yes, the next version will do that 00.05.41 # and check for "No space left on device" 00.05.49 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 00.05.51 # gevaerts: yes 00.06.17 # converting the whole Rockbox site to utf-8 might be a good thing too. Sounds like a task for MrSomeone :) 00.06.36 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 00.07.47 Quit bluebrother ("zzz") 00.10.55 # gevaerts: sed -u seems to help, although cat makes problems then 00.11.18 # but I also noticed the 1MB tmp was full also because of a failed rockboxdev.sh earlier 00.11.54 # bash seems to be broken for here-documents and $TMPDIR. That's only a few K though... 00.12.18 Quit advcomp2019 (Read error: 113 (No route to host)) 00.12.50 # alright, I just freed 0.99MB, it should be fine now :p 00.14.40 # gevaerts: using < and << should normally mean to not create a file at all, doesn't it? 00.14.50 # kugel: why don't you want a normal /tmp dir? 00.14.58 # kugel: here documents need temp files 00.15.38 # Zagor: I want, but I don't know what the ownder planned with it 00.15.47 # owner even 00.15.55 # but you run a vm? 00.16.03 # it may have a reason, and I want to try to not break the vm already 00.16.13 # yes, but that runs multiple users too 00.16.16 # kugel: it comes pre-broken 00.19.17 # New commit by 03zagor (r21850): Added MESSAGE command. Set LC_ALL to C. Wait before exiting when stalled connection. Kill builds with INT instead of KILL, to allow cleanup. 00.19.29 # 1MB is apprently plenty, I just didn't see that rockboxdev.sh didn't cleanup the failed download 00.20.21 # Zagor: and check for "No space left on device" <- and do what when that happens? 00.20.53 # permaban 00.21.40 # almost. the server ignores that client until it reconnects. the build is not marked as completed and is thus done by someone else. 00.21.59 # it also sends a message to the client console 00.23.54 Quit advcomp2019_ (Read error: 113 (No route to host)) 00.25.51 # Does anyone know how well USEC_TIMER works over clock speed changes on pp? I'm suspicious that it doesn't give consistent timings, causing curious jerkiness in pictureflow, possibly causing jerkiness in list viewers in general. Another reason I suspect this is due to the 'experimental' gui cpu boost patch making pictureflow jerkiness worse/weirder 00.27.28 # The ipod video button driver uses USEC_TIMER and I'd like to experiment with using some alternative (if there is one). I'll also see if video behaves nicer with the zero-wait-state patch 00.28.13 Quit flydutch ("/* empty */") 00.30.25 # The PP usec timer isn't affected by cpu clock changes at all (well, except when switching to the 32kHz hibernation clock, which we don't do yet) 00.31.07 # Same applies to the two programmable timers. They're all running from the base clock and need no adjustment for clock changes 00.31.58 # amiconn - Thanks as always! So bang goes that unfounded theory. 00.33.09 # (for those who are curious - the hibernation clock turns the usec timer into a sec timer) 00.36.43 # cute. out of interest, what's stopping switching to the hibernation clock (a lot of driver rework needed or is there not a lot to it?). 00.37.43 Quit jgarvey ("Leaving") 00.38.57 # All the hardware management threads need to learn how to go to hibernation mode and wake up again 00.39.52 # Other than that it's fairly easy on iPod G1 and G2, I already did it months ago using experimental code 00.40.37 # amiconn: how does this clock switch work on the older ipods? is it a gipo? 00.40.39 # I have no idea what additional measures are needed on the newer ipods which have the PCF50606 PMU 00.41.17 # exactly that switch prevents us from properly resetting the 2g nanos 00.41.56 # The old ones need to make sure backlight is off, shut down the codec via i2c, the put the sdram into self-refresh and finally switch to the 32kHz source and switch off the 24MHz base clock 00.42.04 # (bootrom tries to lock a PLL at 11GHz and wonders why that doesn't work, if you don't switch to 32kHz before resetting) 00.42.56 # The hibernation code needs to be in iram because of this. SDRAM cannot be accessed in self-refresh mode 00.43.07 # gotcha 00.43.32 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 00.44.16 # It's not gpio, but several bits in the PP clock and ram controllers 00.45.27 Quit r0b- (Read error: 110 (Connection timed out)) 00.46.31 # amiconn: i mean just switching the cpu clock source, not the other steps 00.46.31 # Yes, that's done by selecting another clock source in the clock controller 00.47.01 # ok... on the nano2, that's done by something external :-/ 00.47.35 # Well, it's an entirely different SoC 00.47.36 # and when booting, they lock the PLL at 200MHz based off the 32kHz source 00.47.51 # pixelma: did you get anywhere with testing the pla rework yet? 00.47.54 # just hoped they could have done that on the old ones, too 00.48.25 # PP has two base clocks, 32kHz and 24MHz. The programmable PLL uses the 24MHz source as its base 00.49.36 # The 24MHz source can be disabled. I think that actually disables the oscillator 00.49.48 Join evilnick_home [0] (n=evilnick@pool-173-52-144-203.nycmny.east.verizon.net) 00.50.27 # JdGordon|: do you still have a build-NNNN dir left? 00.50.41 # yes 00.50.45 # argh 00.51.02 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 00.51.10 # nice welcome message btw 00.51.46 # ok so INT doesn't work. I'll try the TMPDIR fix instead. 00.51.55 # JdGordon|: are you going to have time tonight to skim through the customlist patch? 00.51.59 # Zagor: the folder with the unlink errors are a different number than the remaing build- dir 00.52.10 # huh! 00.52.28 # yeah, that dir is from 3 days ago! 00.52.42 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 00.52.44 # Zagor: When does the score update? Before the most recent build, I got your score is x, you are fast. No builds were completed, and I just got the same score and message again. 00.53.22 # http://pastebin.com/m5ba3df37 00.54.07 # kugel: i dunno... i'll have time alsmost for sure, but motivationj and energy :( 00.54.20 Quit shotofadds ("Leaving") 00.54.21 # AlexP: the score updates at the end of each round. 00.54.58 # Zagor: So I take it that it should have changed for me, having failed to do any builds 00.55.35 # AlexP: I would have thought so, yes... 00.56.15 # ah, bug. it doesn't. fixing... 00.57.16 *** Saving seen data "./dancer.seen" 00.57.35 # gah, another bug 01.08.27 Join coney [0] (n=james@2001:470:8:8b:203:47ff:fedf:1267) 01.08.36 Quit jfc^2 (Remote closed the connection) 01.09.05 Join n00b81 [0] (n=n00b81@unaffiliated/n00b81) 01.09.23 Join martian67_ [0] (n=martian6@about/linux/regular/martian67) 01.09.36 Join jfc^2 [0] (n=john@dpc6682208002.direcpc.com) 01.10.11 Quit martian67_ (SendQ exceeded) 01.11.01 Join martian67_ [0] (n=martian6@about/linux/regular/martian67) 01.13.51 # New commit by 03zagor (r21851): Don't let children inherit mother's SIGINT handler. 01.14.11 # Zagor: Is there a reason why you used SIGINT and not SIGTERM? 01.14.24 Quit mcuelenaere () 01.14.45 # amiconn: lack of brains :-) TERM is what I really meant 01.15.32 # Now the client (probably the build child) always prints "received interrupt" 01.15.54 # yes, it's a mistake. 01.16.44 # New commit by 03zagor (r21852): Kill children with TERM instead of INT. 01.18.47 Quit martian67 (Connection timed out) 01.19.12 Join r0b- [0] (n=rob@adsl-76-235-217-188.dsl.klmzmi.sbcglobal.net) 01.21.40 # argh cook undefs debugf 01.23.31 Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 01.24.55 Quit agaffney (Read error: 110 (Connection timed out)) 01.25.52 Quit Thundercloud (Remote closed the connection) 01.28.11 Quit stripwax ("http://miranda-im.org") 01.31.20 # if I include mdct_lookup.h in two different .c files in the same codec, do the lookup tables get allocated twice? or is the linker smart enough to use the same table for both .c files? 01.35.07 # Code in a .h file? Eww. In this case you'll most probably have them allocated twice 01.36.04 # saratoga: move it in a c file maybe? 01.36.29 Join JdGordon| [0] (i=46077f47@gateway/web/freenode/x-bc6fba0f5c4d2ab0) 01.36.34 # These tables are static - the linker doesn't know they're there 01.37.12 # well thats annoying 01.37.15 # If they wouldn't be static, you would get a duplicate symbol error instead 01.37.27 # cook uses the same trig tables as the mdct lib 01.37.34 # What's the problem with the C file? 01.37.38 # so i'd like to be able to delete cooks and somehow include the mdcts 01.38.05 # without having them allocated twice 01.38.23 # mdct_lookup.c, then have extern lookup_table[] in mdct_lookup.h 01.38.25 # Move the tables to a .c file, un-static them, and keep the declarations in the .h 01.39.01 # does unstaticing them have any impact on other codecs that use the mdct library? 01.39.38 # Not unless they're also doing such a weird thing as duplicating them 01.39.46 # ok good 01.40.13 # also, I notice cook uses a lot of 16 bit constants for trig functions 01.40.13 Join Blue_Dude [0] (n=chatzill@adsl-235-206-197.mco.bellsouth.net) 01.40.31 Join Lazatar [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 01.40.33 # thats got to be slower then a full 32 bit mul right since it has to mask them? 01.40.55 # Iiuc this mdct lib is our own anyway, so we're not forced to keep wrong constructs for potential upstream syncs 01.41.15 # It depends on the architecture 01.42.57 # It also depends on how the constants are loaded 01.43.41 Quit Zagor ("Leaving") 01.44.17 # saratoga: if it's signed then it has to do sign extension I think 01.44.43 # ugh cook is such a mess . . . 01.45.14 # Hey, can someone have a look at my patch at FS#10199? It's ready for a hard look now. Thanks. 01.48.20 Quit martian67_ (Connection timed out) 01.48.23 # Blue_Dude: I think you're better off writing to the -dev list with a somewhat detailed description what it does 01.50.00 Quit kugel (Remote closed the connection) 01.50.08 Quit Lazatar (Remote closed the connection) 01.50.30 Join Lazatar [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 01.52.49 # I wrote an email three days ago and have heard squat from the -dev list. The functional description is in FS where it's supposed to be. 01.56.29 Quit Lazatar (Client Quit) 01.56.38 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 01.57.43 Quit martian67 (SendQ exceeded) 01.59.16 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 02.03.34 # Unhelpful: Regarding the offset autogeneration mechanism - there are differences between architectures 02.04.09 # ARM and MIPS use .word, m68k and SH1 use .long 02.04.27 # And there's the _ prefix for SH1 02.05.12 Join bzed_ [0] (n=bzed@devel.recluse.de) 02.05.20 Quit martian67 (SendQ exceeded) 02.07.12 Quit JdGordon| (Ping timeout: 180 seconds) 02.07.30 Quit bzed_ (Read error: 104 (Connection reset by peer)) 02.08.12 Join bzed_ [0] (n=bzed@devel.recluse.de) 02.08.25 Quit bzed (Read error: 104 (Connection reset by peer)) 02.08.28 Quit graey (Read error: 110 (Connection timed out)) 02.08.29 Nick bzed_ is now known as bzed (n=bzed@devel.recluse.de) 02.09.53 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 02.10.45 Quit martian67 (SendQ exceeded) 02.11.10 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 02.13.20 Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 02.14.27 Join agaffney [0] (n=agaffney@gentoo/developer/agaffney) 02.24.29 Join martian67_ [0] (n=martian6@about/linux/regular/martian67) 02.29.53 Part toffe82 02.34.10 Quit martian67 (Read error: 110 (Connection timed out)) 02.35.19 Join advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) 02.49.24 Quit martian67_ ("out") 02.49.28 Join martian67_ [0] (i=martian6@2001:470:b:356:0:0:0:beef) 02.49.46 Quit martian67_ (Remote closed the connection) 02.49.56 Join martian67 [0] (i=martian6@about/linux/regular/martian67) 02.51.00 Quit martian67 (SendQ exceeded) 02.52.24 Join martian67 [0] (i=martian6@about/linux/regular/martian67) 02.54.21 Quit pixelma (Read error: 60 (Operation timed out)) 02.57.18 *** Saving seen data "./dancer.seen" 03.03.16 Part wincent ("Kopete 0.12.7 : http://kopete.kde.org") 03.08.12 # I cannot believe how hard its proving for me to get rid of the stupid duplicate trig table in cook 03.08.56 Quit amiconn (Read error: 110 (Connection timed out)) 03.10.03 # saratoga: get your butt into #rockbox-commuinty :p 03.10.11 # also... dont be afraid of the del key :D 03.19.45 Join Rob2222 [0] (n=Miranda@p4FDCD702.dip.t-dialin.net) 03.36.30 Join robin0800_ [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 03.36.54 Quit scorche (Read error: 104 (Connection reset by peer)) 03.37.01 Quit Rob2223 (Read error: 110 (Connection timed out)) 03.44.51 Quit martian67 ("out") 03.44.56 Join martian67 [0] (i=martian6@about/linux/regular/martian67) 03.46.51 Quit robin0800 (Read error: 110 (Connection timed out)) 03.49.01 Join bzed_ [0] (n=bzed@devel.recluse.de) 03.49.59 Quit bzed (Read error: 104 (Connection reset by peer)) 03.50.06 Nick bzed_ is now known as bzed (n=bzed@devel.recluse.de) 03.56.03 # people on the mailing list are calling each other autistic 03.56.08 # is there anyway to filter all messages that mention top or bottom posting? 03.56.17 # maybe its time we consider getting rid of the mailing list 03.56.33 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 03.56.39 Quit martian67 (Read error: 104 (Connection reset by peer)) 03.56.58 Join martian67 [0] (i=martian6@about/linux/regular/martian67) 03.58.06 Quit robin0800_ ("DMDirc exiting") 04.06.34 Quit TheSeven (Nick collision from services.) 04.06.49 Join The_Seven [0] (n=theseven@dslb-084-056-137-169.pools.arcor-ip.net) 04.06.53 Nick The_Seven is now known as TheSeven (n=theseven@dslb-084-056-137-169.pools.arcor-ip.net) 04.07.18 Quit Sajber^ (Read error: 104 (Connection reset by peer)) 04.17.24 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 04.18.07 Quit robin0800 (Remote closed the connection) 04.28.41 Quit n00b81 ("Leaving") 04.49.37 # I agree the user mailing list has gotten out of control on this topic - can we start kicking people that continue to discuss that thread? 04.57.22 *** Saving seen data "./dancer.seen" 05.05.29 # huh... make seems not to be running the commands for a rule in their correct order 05.07.13 Quit efyx (Remote closed the connection) 05.09.24 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 05.13.42 Quit Horscht (Client Quit) 05.22.07 Join lanny` [0] (n=lanny@c-71-197-112-32.hsd1.ca.comcast.net) 05.23.50 Part lanny` 05.24.04 Quit JdGordon ("Leaving.") 05.26.12 Join JdGordon [0] (n=Miranda@c-67-160-44-90.hsd1.wa.comcast.net) 05.36.10 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 05.43.38 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 05.49.40 Quit daurn (Read error: 110 (Connection timed out)) 05.53.20 # kkurbjun: Well, it's a somewhat important question - are the list rules on topic for discussion on the list? 05.53.32 # Now certain threads of it are certainly wandering pretty far astray. 05.54.44 Part Llorean 05.55.00 Join Llorean [0] (n=DarkkOne@adsl-99-182-52-92.dsl.hstntx.sbcglobal.net) 06.04.59 Quit JdGordon (Read error: 104 (Connection reset by peer)) 06.07.38 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 06.09.18 Join Horschti [0] (n=Horscht2@xbmc/user/horscht) 06.23.40 Quit dash32 ("Verlassend") 06.27.40 Quit Horscht (Read error: 110 (Connection timed out)) 06.49.35 Join scorche [50] (n=scorche@rockbox/administrator/scorche) 06.54.18 # apparently mpg123 has an mp3 decoder with arm optimizations now 06.55.52 # hmm though it looks pretty rudimentary 06.56.10 # still its actively developed unlike libmad 06.57.24 *** Saving seen data "./dancer.seen" 07.13.02 Nick ayahuasca is now known as fortuna (i=amg@host193-123-47-78-dhcp.bshellz.net) 07.13.58 Quit scorche (Read error: 60 (Operation timed out)) 07.17.00 Join Horscht86 [0] (n=Horscht2@p4FD4E2C3.dip.t-dialin.net) 07.20.07 Join Leakydick [0] (n=h@cpe-66-27-126-189.san.res.rr.com) 07.20.19 # hi 07.22.44 # anyone feel funkiness between the 2.x builds and the 3.3 in the sansa e200 series? or is it just me? I hadn't been keeping up on a regular basis and feel like i am missing context menu, OR some keys are mismapped. 07.26.26 # huh?...there werent any 2.x builds for the sansa e200 series 07.26.52 # i guess i was referring to timeframes more than official releases 07.26.56 # maybe 1.5 yr back 07.27.20 # opressing down now acts like the power button in the 3.3 07.27.27 # returns to main menu always 07.27.33 # i dont know about 'funkiness', but a LOT has changed since then, yes...i believe we did change the keymaps a long while ago 07.28.07 # if you are a bit confused how things work now, perhaps the manual can tell you a bit more about what each button now does? 07.28.11 # thanks for your recollection and the help. im in the middle of installing cyg on this machine, just copy and paste didnt seem to work out too well for me 07.28.16 Join daurn [0] (n=daurnima@unaffiliated/daurnimator) 07.28.30 # copy and paste? 07.29.06 # i used to build RB on a 32 bit machine and had cyg installed there. i copied the dir and added paths, but it didnt take well on this 64b machine 07.29.38 # it is easy to use svn anyway... 07.29.56 # svn is what i'll use 07.30.06 # it's the build enviornment that is my first issue 07.30.22 # thought cyg would be portable app, like copy and paste to new machien and set paths 07.32.24 # this team has done some excellent work, my most favorite feature additions are the plugin architecture, the SDHC, and the unicode support 07.32.40 # now that USB charging is done, i have no need for the sansa FW 07.33.15 Join scorche [50] (n=scorche@rockbox/administrator/scorche) 07.35.00 Quit Horschti (Read error: 110 (Connection timed out)) 07.38.19 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 07.42.29 Join stoffel [0] (n=quassel@p57B4CF2D.dip.t-dialin.net) 07.42.54 # back in business... cyg is a clusterf*, it was trying to be smart and without uninstall I had to purge everything I copied over and all the registry entries that had "CYG" except a couple that matched cyg cuz it was PoliCYG... 07.44.24 # Leakydick: as a note, this channel is strictly for the discussion of rockbox related chat only...all social and offtopic chat should go somewhere else as said in the topic of this channel 07.49.08 # i was trying to be helpful for the logs 07.49.28 Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) 07.49.34 # battling cygwin for rockbox build environment 08.03.07 # windows=tehsuck 08.06.36 # oh 08.09.21 Quit r0b- (Read error: 110 (Connection timed out)) 08.18.24 Join graey [0] (n=geertvan@cc412026-a.zwoll1.ov.home.nl) 08.38.29 Part safetydan ("Leaving.") 08.44.12 # anyone know if the libgphoto2 bug is likely to affect sansas running in recovery mode too ? 08.44.23 Quit martian67 (Read error: 110 (Connection timed out)) 08.44.55 Join amiconn [0] (i=quassel@rockbox/developer/amiconn) 08.48.33 Quit daurn (Read error: 110 (Connection timed out)) 08.48.35 Join Rob2223 [0] (n=Miranda@p4FDCC04C.dip.t-dialin.net) 08.51.30 Join n1s [0] (n=n1s@rockbox/developer/n1s) 08.54.20 # GodEater: Depends entirely on if those PID/VIDs are in the list 08.57.28 *** Saving seen data "./dancer.seen" 08.58.16 # I spotted a cheap Samsung YP-S3, it seems to use a Samsung S5L8700 SoC too 09.00.35 Quit n1s (Remote closed the connection) 09.01.04 # Llorean: I realise that, I just can't reconcile the values in the xml file with what lsusb tells me 09.01.42 # The OF of YP-S3 seems to be based on VxWorks 09.01.47 # GodEater: Aaah. Dunno 09.02.02 # and I have no sansa based player with me to just try it :) 09.03.42 Quit amiconn (Remote closed the connection) 09.03.50 Join pixelma [0] (i=quassel@rockbox/staff/pixelma) 09.03.50 Join amiconn [0] (i=quassel@rockbox/developer/amiconn) 09.05.33 Quit scorche (" rawr...that is all...rawr") 09.05.51 Quit Rob2222 (Read error: 110 (Connection timed out)) 09.08.05 Join petur [50] (n=petur@rockbox/developer/petur) 09.08.56 Join n1s [0] (n=n1s@rockbox/developer/n1s) 09.14.23 # GodEater: does it not mount as storage? 09.15.00 # < GodEater> and I have no sansa based player with me to just try it :) 09.17.18 # oh 09.17.22 # that was you 09.21.15 Join miyodea [0] (n=msellers@69.150.79.63) 09.23.16 Part miyodea 09.24.51 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 09.24.53 Quit TheSeven ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 09.30.19 Quit graey (Read error: 110 (Connection timed out)) 09.31.36 Quit BHSPitMonkey ("Ex-Chat") 09.43.01 Quit Mikachu (Read error: 104 (Connection reset by peer)) 09.44.42 Join gartral [0] (n=Gartral@adsl-75-33-67-127.dsl.bcvloh.sbcglobal.net) 09.45.40 Quit Thundercloud (Remote closed the connection) 09.45.42 Quit MrDuck (Read error: 113 (No route to host)) 09.46.16 # If one has put but a bitmap and jpeg AA in a folder as cover.bmp and cover.jpg, which will be the one used? 09.46.47 # Couldn't just just test? It'd take fifteen seconds. 09.49.26 # i assume the only real way to test is put two different picures in, ona as a bmp and one as a jpg, right? 09.49.43 # that would be the easiest, yeah 09.52.15 # or a jpg with gemoetric shapes 09.53.23 # * amiconn thinks that looking at the source is easier 09.54.00 # New commit by 03learman (r21853): Remove a function accidentally added back in r21841. 09.54.08 # But in fact that is a valid question. It should be added to the manual if it isn't already 09.55.05 # I thought it was on the albumart wiki page. 10.00.03 # albumart wiki does not appear too mention which is "looked for" first 10.01.53 Join Mikachu [0] (i=Mikachu@c-83-233-200-194.cust.bredband2.com) 10.03.08 # Well why don't you fix it after your test? 10.03.48 # happily... as soon as my slow computer finishes "flattening' the jpeg i made 10.08.18 # Hmm, weird yellow 10.08.40 # Only in the new build system, and only for one sim, although other sims were also built using gcc 4.4.0 10.10.08 # what does the build system for rockboxutil look like on windows? 10.10.10 Quit n1s ("Lämnar") 10.13.27 # New commit by 03Ubuntuxer (r21854): try to make buttons in jewels more unified (part of FS#10193) 10.36.42 Join n1s [0] (n=n1s@cm-84.215.127.139.getinternet.no) 10.36.55 # amiconn: could be some sort of vendor patch *gag* 10.39.37 Join TheSeven [0] (n=theseven@p54A0D3AA.dip.t-dialin.net) 10.44.47 Join svqyqb [0] (n=svqyqb@p508DB049.dip.t-dialin.net) 10.44.54 # http://tinyurl.com/nkypfa 10.44.55 Quit svqyqb (Read error: 104 (Connection reset by peer)) 10.50.14 Join MrDuck [0] (n=kachna@r3g248.net.upc.cz) 10.51.37 # gartral: The manual answers your question - http://download.rockbox.org/manual/rockbox-h100/rockbox-buildap3.html#x18-316000C 10.54.30 Join Casainho [0] (n=chatzill@bl8-168-171.dsl.telepac.pt) 10.54.35 # linuxstb: how does it say which format is looked for first? the *only* remote indication i can see is that "Jpeg, jpg, bmp" options in the examples, which I would like to note; isn't there on the e200's manual 10.55.08 # gartral: "a list in braces means that those file extensions are tried in that order" 10.56.18 # im sorry *not in album art wiki page* 10.57.31 *** Saving seen data "./dancer.seen" 10.59.06 # is it ok just to merge the info from the manual too the wiki page? 10.59.51 Join Sajber^ [0] (n=Sajber@h-142-120.A213.priv.bahnhof.se) 11.01.14 # Maybe it would be better to delete any duplocate information from the wiki, and just refer people to "The album art appendix" in the manual. 11.01.43 # gartral: not really. We want the manual to be complete, and have the wiki for missing bits, but no duplicate information 11.04.01 # New commit by 03Ubuntuxer (r21855): Adapt manual to the changes in jewels (part of FS#10193) 11.09.40 # well thank you all 11.12.02 Join Ubuntuxer [0] (n=johannes@dslb-094-220-238-078.pools.arcor-ip.net) 11.13.32 # New commit by 03Ubuntuxer (r21856): Change buttons in pegbox for Fuze (part of FS#10193) 11.14.51 # petur: Regarding the gcc 4.4.0 warning - the code does indeed look fishy 11.15.13 # amiconn: I didn't really check the code 11.15.24 # It looks like the ! should be outside the first inner parentheses 11.15.59 # if ((!s2->lines[i]->flags & ML_TWOSIDED) || (s2->lines[i]->backsector == s1)) ... 11.16.16 # Should most probably read if (!(s2->lines[i]->flags & ML_TWOSIDED) || (s2->lines[i]->backsector == s1)) 11.17.01 # Checking flags and then turn the result into a boolean 11.20.30 Quit Casainho ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]") 11.21.56 # Ubuntuxer: I'm not sure I understand your commit message "try to make button in jewels more unified" - isn't your patch mainly a change for IPOD_3G_PAD? Also, why remove JEWELS_MENU for the h100/h300, I would have thought it would be better to add that mapping to more targets? 11.28.48 Join Lynx_ [0] (n=Lynx@xdsl-78-34-237-192.netcologne.de) 11.29.11 # amiconn: yes, it looks like that 11.31.20 Join teru [0] (n=teru@KD059133112132.ppp.dion.ne.jp) 11.38.32 Join DarkDefender [0] (n=rob@78-69-30-229-no36.tbcn.telia.com) 11.41.01 Quit Sajber^ (Read error: 104 (Connection reset by peer)) 11.41.29 # @linuxstb the patch is a part of FS#10193, so actually it makes just sense with the all the rest changes 11.43.27 # Ubuntuxer: Yes, I read FS#10193, and it doesn't help. I'm just saying that commit messages should describe what the change is, and I don't think that did. 11.44.27 # petur: Hmm, I just looked it up. ! takes precedence over &, so the current code is probably buggy. But then, prboom doesn't seem to have fixed it in their trunk 11.44.38 # Ubuntuxer: So why remove the ability for h100/h300 users to press MODE to enter the menus? 11.45.49 # I wonder when EV_DoDonut() is called - the timedemo in the shareware version doesn't 11.46.04 # because FS#10193 removes the ingame menu and makes the menu altogether 11.46.36 # Why remove the ingame menu? 11.48.15 Join _lifeless [0] (n=lifeless@188.16.125.117) 11.48.20 # the aim is to unified all menus, so it's clearer and easier for a user 11.48.22 # Ubuntuxer: Reading the code, JEWELS_MENU was just an alternative way to access the same menu that is on "long select". 11.48.56 # i know, but JEWELS_CANCEL replace it 11.49.21 Quit _lifeless (Client Quit) 11.50.44 # please test my silly huge patch, in which I included everything and you'll understand 11.51.22 # Ubuntuxer: I shouldn't need to - commits should make sense by themselves (the commit message in combination with the code) 11.53.37 # I should divide my patch..., sorry 11.56.33 Join evilnick_home1 [0] (n=evilnick@pool-173-52-144-203.nycmny.east.verizon.net) 11.56.53 # What should I do know? 12.00.32 # I think maybe you just split your patch too much - I don't think it made sense to commit those simple keymap changes by themselves, without committing the menu rework. 12.01.25 # So probably carry on with what you're doing, but be aware that each commit should make sense (and also try and describe them more fully in the commit message). 12.01.45 # ok 12.03.06 Quit __lifeless (Read error: 113 (No route to host)) 12.12.53 Join kugel [0] (n=kugel@rockbox/developer/kugel) 12.14.36 Join Sajber^ [0] (n=Sajber@81-235-177-115-no54.tbcn.telia.com) 12.16.01 # New commit by 03amiconn (r21857): Silence the gcc 4.4.0 warning by making this code look like it was probably meant to be. I'm not 100% sure this is correct - latest prboom doesn't ... 12.16.20 Quit evilnick_home (Read error: 113 (No route to host)) 12.17.45 Join graey [0] (n=geertvan@cc412026-a.zwoll1.ov.home.nl) 12.24.12 Join _zic [0] (n=user@91-165-242-32.rev.libertysurf.net) 12.25.22 # Ubuntuxer: do you mind my committing FS#10099? 12.28.55 # yes, I'll commit it soon, but please wait, 12.32.42 Quit TheSeven (Nick collision from services.) 12.33.00 Join The_Seven [0] (n=theseven@p50993c69.dip0.t-ipconnect.de) 12.33.04 Nick The_Seven is now known as TheSeven (n=theseven@p50993c69.dip0.t-ipconnect.de) 12.33.44 Join eekfonky1 [0] (n=chris@220-245-169-219.static.tpgi.com.au) 12.34.18 # Is there any ETA for rockbox to work on 2nd gen Ipod Nano? 12.34.32 # of course not :) 12.35.38 # kugel: What exactly are you asking for comments about in the dev list? I can't see a relevant patch in FS#9873, just the initial one... 12.38.58 # markun: are you answering me? 12.40.09 # eekfonky1: we NEVER give ETAs. Ever. 12.40.41 # eekfonky1: well, the port has just started 12.40.56 # markun: it has? who's working on it ? :) 12.40.56 # we can't permanently change the firmware yet 12.41.03 # GodEater: linuxstb 12.41.07 # hahahahaha 12.41.37 # linuxstb: another port ? :) 12.41.47 # NO!!!!!!!!! 12.41.52 # are there plans to release a version that will work on a 2nd gen ipod? 12.42.13 # no 12.42.17 # As has been said 12.42.18 # eekfonky1: be careful with your naming convention. We already have a port for the 2nd gen ipod. 12.42.19 # eekfonky1: there are hopes, but don't count on it any time soon 12.42.29 # eekfonky1: There are no etas, no plans 12.42.30 # eekfonky1: No explicit plans, no. If it happens, then it happens. It depends on luck and people contributing. 12.42.58 # can you direct me to the port to see if it works on my ipod? 12.43.05 # eekfonky1: There is no port 12.43.08 # eekfonky1: which ipod do you have? 12.43.11 # For the 2nd gen nano 12.43.19 # 2nd gen nano 12.43.20 # eekfonky1: I think you missed the point of my warning =/ 12.43.35 # eekfonky1: really, there is nothing to try yet 12.43.42 # ok 12.43.48 # thank you for your help 12.43.56 # eekfonky1: There is no port at all for the 2nd gen nano. The 2nd gen ipod has a port, but that is the 2nd ipod that was ever released and is many years old 12.44.51 Quit kugel (Read error: 113 (No route to host)) 12.45.13 # linuxstb: so is markun right? or is he making it up ? 12.45.28 Part eekfonky1 ("Leaving.") 12.46.09 # GodEater: Now that eekfonky1 has left.... I've added the Nano 2G to the build system, yes. It's using a similar SoC to the Meizu M3/M6, so it should be able to share that code. 12.46.12 # GodEater: http://svn.rockbox.org/viewvc.cgi?view=rev;revision=21828 12.46.29 # But I haven't actually tried running the resulting binary yet... 12.46.52 # linuxstb: but the bin2note util works, right? 12.47.03 # * linuxstb still wants to understand if the code to put the SoC into big-endian mode in crt0.S for the Meizu is needed. 12.47.29 # are we going to add the classic too ? As I understand the same exploit for the 2G Nano works on that too ? 12.47.53 # markun: Yes, I wrote that for use with TheSeven's "iBuggerLoader" (the loader for iBugger - his planned on-target debugger for the Nano2G). My program produces the same note as he released. 12.48.26 # GodEater: I don't think it works fully - that report turned out to be false... 12.48.34 # ah ha 12.49.27 # * GodEater wonders if it's worth trying to find an ipod classic from somewhere to see 12.51.43 # good god 12.51.51 # they cost a bloody fortune on ebat 12.51.52 # er 12.51.53 # ebay 12.53.06 # and it appears everyone is calling the entire bloody range "classic" now. 12.53.15 # I saw some for 140GBP - is that what you mean by a fortune? 12.55.31 # yes, I was expecting the price to have dropped a bit more than that now 12.55.48 # I can see some for <100 now 12.55.54 # but still a few hours to go 12.57.33 *** Saving seen data "./dancer.seen" 12.59.34 # linuxstb: any idea how to try to adapt the exploit to the 4g nano? 13.04.42 Quit MrDuck (Read error: 104 (Connection reset by peer)) 13.04.54 Join MrDuck [0] (n=kachna@r3g248.net.upc.cz) 13.09.09 Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) 13.12.12 # New commit by 03Ubuntuxer (r21858): Combine the two menus, improve highscore list, automatically save game, improve help text (buttons are missing yet) and clean up the code in jewels ... 13.14.31 # n1s: No, I admit to not fully understanding it. You could ask in #linux4nano-dev.... 13.15.16 # ok, thanks 13.21.32 Join efyx [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 13.22.52 Join kugel [0] (n=kugel@rockbox/developer/kugel) 13.33.38 Join adibis [0] (n=aditya@59.95.47.72) 13.34.21 # hey, I was wondering, is it possible to install rockbox on your own MP3 player. I mean, a player designed using audio codec ICs and microcontroller at home. 13.34.47 # if yes, then what are the constraints on hardware design. If there are any 13.34.53 # hmm, I'm syncing the strlcpy patch and the PA plugin introduces a ton of strncpy calls, would it be better to move strncpy to the plugin lib and leave imported code using it? 13.35.42 # adibis: you would have to port rockbox to it 13.35.46 # adibis: yes, it's possible, but you'd have to write a port 13.35.52 # there are very few constraints on design 13.36.04 # but some design choices may make the porting more or less effort 13.36.10 # depending on similarity to platforms we already support 13.36.21 # ok 13.36.42 # a microcontroller is unlikely to be sufficient, though 13.36.52 # you need a "real" processor, for some value of real 13.39.24 # New commit by 03unhelpful (r21859): Handle sh and m68k compiler's output correctly in asmdefs2file 13.40.29 Join wincent [0] (n=wincent@host-091-097-067-213.ewe-ip-backbone.de) 13.40.29 Quit Leakydick (Read error: 110 (Connection timed out)) 13.41.41 Quit adibis (Read error: 60 (Operation timed out)) 13.41.43 # eh, not PA, Pure Data, I think... 13.42.21 # so PD maybe, anyways, any oppinions? 13.44.15 Quit Ubuntuxer ("Leaving.") 13.46.44 # wincent: any oppinions? (you are the pdbox coder right?) 13.47.12 # nls: Wait, I will check the logs 13.48.33 # wincent: i'm syncing a patch that converts rockbox to use strlcpy instead of strncpy, i saw that strncpy is used a lot in pdbox so i thought i might be better to move strncpy to the pluginlib so imported code can continue to use it 13.49.03 # imported code in plugins that is 13.50.13 # nls: Is strncpy not already in plugin.h? 13.53.05 # wincent: yes, but this patch removes it as all users besides pdbox are converted to use strlcpy instead 13.53.31 # nls: What does strlcpy? 13.54.33 # wincent: safer version of strncpy. guarantees zero termination and returns the length copied so you can detect truncation 13.54.45 # it's similar to strncpy but guarantees null termination and returns the length of the source so it's basically considered to be a bit safer and less prone to cause bugs 13.55.42 # wincent: so what i'm asking is if you think pdbox sholud use it too or if it should keep using strncpy? 13.55.57 Join aditya [0] (n=aditya@59.95.46.25) 13.56.03 # What if you change the macro strncpy in wrappers.h to use rb->strlcpy? 13.56.44 # that is possible but the code might need small adjustments in some places 13.57.30 # and for clarity i think using a wrapper like that would be kind of confusing 13.57.46 # that will copy one less byte sometimes 13.57.51 # yes 13.57.57 # which shouldn't affect code which is using strncpy correctly :) 13.58.01 # but you never know 13.58.39 # wincent: how likely are future merges with upstream code into pdbox? 13.58.43 # n1s: leaving it in the pluginlib might be a good idea 13.58.49 # wincent: wrappers.h is not intended for that 13.59.06 # Torne: I have some code (not in rockbox though) that depends on the exact strncopy behaviour 13.59.09 # I think we generally want to make importing code as easy as possible 13.59.23 # Then move it to pluginlib. 13.59.31 # so you really have to check all cases, not just do a blind global search and replace 13.59.57 # wincent: ok 13.59.58 # wrappers.h is intended for code imported from core 14.00.05 # gevaerts: well, ok, you can do that if you are clever. but most people aren't :) 14.00.05 # nls: Future merges are likely. 14.00.37 # gevaerts: yeah i found a few such places in rockbox, one i code i'd written myself :) 14.00.42 # in 14.00.43 # Torne: that's just a case where gevaerts used strncopy instead of memcpy 14.00.46 # ;) 14.00.51 # strncpy* 14.00.53 # kugel: no :) 14.01.16 # kugel: you might also rely on the zero padding of strncpy which strlcpy doesn't do 14.01.55 # for strings? 14.02.13 # yah, you may be writing fixed length output data 14.02.21 # and thus need full zero padding 14.02.31 # for various possible reasons (checksums and the like?) 14.02.40 # exactly 14.02.58 # kugel: keybox does for the buffer that is used to generate the encryption/decryption key 14.03.27 # memset+strlcpy does the trick though and is more obvious 14.07.56 # New commit by 03teru (r21860): add a way to quit without saving game. ... 14.13.05 # i wonder if i should remove my changes to doom too then 14.14.37 # anything that's likely to get updated from external sources should probably be left alone, i'd think 14.14.50 # yeah 14.14.55 # memset + strlcpy are two calls, strncpy is just one. And memset()ting the whole buffer is even more wasteful 14.15.03 # glibc still doesn't have strlcpy, does it? 14.15.11 # they objected to the idea 14.15.20 # so external code is not gonna want it 14.15.52 # amiconn: yes, i know but it is clearer that you depend on the zeroing of the buffer, this example is not speed critical in any way 14.16.07 # Clearer in what way? 14.16.49 # well, IMO of course, since you explicitly zero it 14.17.18 # strncpy() also zeros explicitly - it is documented behaviour 14.17.46 # Yes, it's documented, but perhaps not well-known. So if code depends on that, a short comment to that effect wouldn't hurt. 14.18.07 # amiconn: yes i know it's documented but if a string is strncpy'ed the zero padding might just be a side effect 14.18.14 # Zagor: (logs) I just noticed that one of my clients had stopped with a "Terminated" message. I think this is the same issue as others that stopped with "Killed" earlier, only the signal changed. I suspect that the pid is sometimes wrong, or maybe the process group handling is different than we expect. This is not in a VM by the way 14.19.23 # n1s: by the same reasoning someone could call strncpy(a,"",20), and depend on the zeroing, while the string copy is just a side effect. 14.19.56 # strncpy() is defined as it is, with all parts equally important 14.20.10 # gevaerts: my point is that since the zeroing always happens it is not clear if the code depends on it 14.20.54 # n1s: in that case you assume it does until proven otherwise 14.22.31 # yes but IMO a memset+strlcpy or memcpy or whtever is quite clear in that the buffer should be zeroed. Not that this is a major point for this patch in any way, just what i think and this particular example turned up only once 14.23.19 # it's clear, yes. It's also inefficient 14.23.25 # i agree 14.24.13 # well except when you first memcpy and then memset the remaining part of the buffer 14.25.15 # and depend on people to get the numbers right? I thought you were trying to avoid bugs? 14.26.04 # i'm just saying i don't think anyone should do that unless the code is very time critical 14.26.20 # insert , where appropriate 14.26.43 # or ; 14.27.13 # n1s: You're suggesting we get rid of strncpy completely? 14.27.16 # anyway i think the patch is ready soon and will probably commit it later today 14.27.45 # * gevaerts disagrees. If there's a well defined function for something that does exactly what you need, it's wrong to use two other functions for that 14.27.54 # linuxstb: that was how i understood the original plan but as it is now i moved it to the pluginlib 14.30.17 # It does seem odd to get rid of a standard existing function, just because some people don't know what it does... 14.31.33 # one more question, where can I find information about decoding ogg? That is, I don't want to use the ready made OGG-Vorbis decoder IC for decoding the music. Maybe code it on the controller or use an FPGA/CPLD... 14.31.34 # * amiconn fully agrees with linuxstb here 14.32.00 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 14.33.54 # linuxstb: ok, so what do you think should be done then? as the patch is now only plugins use strncpy. Should i just leave strncpy in the core anyway? or should the core calls not be converted at all? 14.34.21 # ... 14.35.29 # it's on MrSomeonesTODOList. The items there *should* be out of question 14.35.52 # kugel: noone complains until you are about to commit 14.35.54 # ... 14.36.03 # aditya: what are you trying to do? 14.36.08 # n1s: Ah, so you're saying that every single use of strncpy is better replaced by strlcpy? 14.36.14 # We're not implementing the complete standard, that's no reason to keep strncpy in 14.36.29 # n1s: Or have you replaced some by memset+strlcpy? 14.36.44 # markun: there are ogg decoder ics available. I want to know if the decoding can be done on the microcontroller itself and play ogg. 14.37.01 # markun: once that is done, rockbox porting on that player will follow 14.37.04 # n1s: I don't think he's complaining (yet). 14.37.04 # n1s: Or simpler - do you have a link to the patch? ;) 14.37.10 # aditya: which player? 14.37.24 # linuxstb: a few have been replaced with memcpy IIRC, the patch is on the tracker 14.37.53 # aditya: did you read the specs? http://www.xiph.org/vorbis/doc/ 14.38.22 # linuxstb: i'll post a fresh diff 14.38.35 # markun: err.. I am thinking of building a player. 14.39.48 # aditya: and you want to do all the decoding inside an FPGA/CPLD? 14.40.29 # linuxstb: fs#10080 14.41.36 # markun: or the controller itself. 14.42.27 # markun: he wants to use a uC rather than a higher-end processor like most o four targets, i believe :) 14.42.38 # ^^ yes 14.42.49 # this is unlikely to be realistic, in my opinion 14.42.55 # Torne: can be an ARM controller also. 14.42.57 # basically the majority of the strncpys were replaced with strlcpy, a few with memcpy and *one* with memset (implicit, buffer is initialized with 0) + strlcpy 14.42.57 # it's not impossible 14.43.00 # just grab a cheap ARM9 SoC 14.43.17 # something powerful enough to run our codecs on the processor 14.47.30 Quit gevaerts (Read error: 60 (Operation timed out)) 14.49.56 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 14.50.16 # aditya: I think decoding an ogg on an FPGA/CPLD woudl be a difficult task if you are not pretty familiar with digital logic design 14.50.32 # scorche|sh: any idea how much longer your "friend" wants to sit on his twitpic hole ? 14.50.34 # you can also put microprocessors on an FPGA though which might be more realistic 14.50.42 # soft microprocessors that is 14.50.42 # oops, wrong channel 14.51.36 # kkurbjun: and maybe some separate DSP routines? 14.52.13 # with a Spartan 3 family device and a microblaze processor I think you could do quite a bit completely self contained in the FPGA, or if you wanted to go an even more open route you coulod try an opencore, but that would probably be considerably more difficult 14.52.36 # markun: you could use seperate dsp routines, but I think the microblaze would be fast enough to run rockbox comfortably 14.52.47 # without any special dsp routines 14.53.00 Quit gartral ("Why must we be chicken or sheep when we have the blood of the Fox, Wolf?") 14.53.01 # as for power consumption, an FPGA might not be the best bet though :-D 14.53.38 Quit Ridayah_ ("The Rise and Fall of the Heavens themselves is dependant upon Humanity's belief and disbelief.") 14.53.46 # and I dont' think you could get much out of a CPLD, there's not too much logic available in the ones that I've worked with 14.54.17 Join Ridayah [0] (n=ridayah@173.19.228.175) 14.54.34 # n1s: Patch looks good to me. I was just confused by your conversation with gevaerts... So the intention is to keep it for plugins, and not use it there? 14.54.36 # kkurbjun: hehe 14.55.03 # kkurbjun: so, the second option. Is it possible to have the decoder on the processor? 14.55.23 # I mean, use a software decoder. Save it to flash. Load it in ram at startup. Use it. 14.55.36 # save it to the same flash as the one with the music files. 14.55.39 # aditya: that's how rockbox does it for all targets 14.55.59 # (all flash targets which play Ogg Vorbis) 14.56.01 # markun: so, a seperate decoder IC is not needed? 14.56.06 # no 14.56.11 # aditya: yes, I think that a soft procesor would be fast enought to do the decoding 14.56.14 # it's all done in software 14.56.24 # okay, where can I get more information about that? 14.56.43 # I mean, the codec and how is it loaded for the playing of the file... 14.56.51 # linuxstb: thanks for looking, sorry fopr any confusion, yes keep it for plugins and use it in imported ones, like doom and pdbox 14.56.56 # * gevaerts finds some sillyness in the patch. It was already there before though 14.57.12 # gevaerts: please tell 14.57.15 # aditya: It's in the rockbox source 14.57.36 *** Saving seen data "./dancer.seen" 14.57.53 Join ucchan [0] (n=ucchan@FLA1Adp241.kng.mesh.ad.jp) 14.57.57 # n1s: have a look at apps/plugins/rockboy/menu.c, line 242. It does memset, and then strncpy of a constant string 14.57.59 Join daurn [0] (n=daurnima@unaffiliated/daurnimator) 14.58.09 # gevaerts: aha 14.59.22 # yeah, that's probably out of the scope for this patch 15.01.36 # aditya: the minimum 'spec' for the ports of rockbox at the moment is something like "a processor fast enough to decode mp3 in software without being fully utilised, 4-8MB of ram but ideally a lot more". We support a couple of players with hardware mp3 decoder chips which are lower spec than that, but they are very old and can't decode anything but mp3. 15.01.56 # you could port to less hardware, if you wer ecunning enough about it, but it would be a lot of work to do, most likely. 15.02.10 # n1s: that depends on what you consider to be the scope of this patch. If it is "introduce strlcpy", it isn't. If it is "clean up strncpy usage", it is 15.02.52 # ok, i'll clean that up a bit then ;) 15.03.20 # New commit by 03teru (r21861): use lib display text to display help messages (FS#10099). 15.03.50 # Torne: okay, so, say ARM11 processor with a ram chip of 8MBs connected to it... 15.03.54 # aditya: Another option if you are interested in messing around with hardware/fpga's and cplds is to find a board that has something like a virtex2 pro that has an embedded powerpc on it also 15.04.00 # Torne: will it be able to run rockbox? 15.04.02 # that would give you a ton of processing power 15.04.06 # aditya: Are you intending to play files from flash or HDD 15.04.11 # if you are going to use a hdd you want a lot more ram 15.04.14 # but from flash, 8mb is plenty 15.04.21 # Torne: flash. SD card. 15.04.21 # and an ARM9 is sufficient, an ARM11 is loads of power 15.04.27 # ok 15.04.33 # is it worth pointing out to aditya that someone is already builing their own player specifically to run Rockbox ? 15.04.38 # yah. an ARM9 SoC with 8MB ram and an SD interface would be a reasonable rockbox target 15.04.48 # an ARM11 would be more fun but probably not necessary 15.04.49 # Oh, er 15.04.54 # GodEater: I think so :) 15.04.54 # yeah, ther eis that. See the lyre project 15.05.28 # I mean, not to discourage or anything, if you really want to go your own way and stuff. But they've done a lot of work already. 15.05.43 Join LambdaCalculus37 [0] (i=44a0430d@rockbox/staff/LambdaCalculus37) 15.05.51 # GodEater: I just want to learn... 15.06.05 # cool 15.06.16 # http://lyre.sourceforge.net/ is the people doing it already. You might want to check it out anyway even if you do want to make your own thing 15.06.19 # just wanted to make sure you weren't about to repeat a lot of hard work someone else had already done ;) 15.06.25 # as many of their discussions/etc may inform your own decisions 15.06.39 # we're not about to discourage people from doing things for fun/educational purposes :) 15.06.44 # but lyre's website might still be a good resource 15.07.24 # GodEater: nah.. it's a one man project. Just something to do in final year of engineering 15.07.38 # aditya: excellent choice of project :) 15.07.53 # That sounds pretty cool, yes :) 15.07.56 # n1s: there are some more points where I disagree wth both the old and new usage, but that's probably just me (copying a constant into a fixed-size buffer) 15.08.02 # GodEater: the college project is different. This is fun/hobby project 15.08.48 # for college, I have to make an object tracker. Collect information about it's movement in space using accelerometers and gyroscopes. 15.09.05 # gevaerts: yes i've seen that in some places 15.11.37 # aditya: if you are looking for something to mess around with using something like this might be a good starting point: http://cgi.ebay.com/Samsung-S3C2440-ARM9-ARM920T-ARM-Core-Board-Design-Kit_W0QQitemZ120446764043QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item1c0b2fc40b&_trksid=p3286.c0.m14&_trkparms=65%3A12|66%3A2|39%3A1|72%3A1205|293%3A1|294%3A50 It really depends on whether you want to make something that could be provided to others t 15.12.20 # New commit by 03lenzone10 (r21862): Updated italian translation. 15.12.25 # n1s: I think strncpy should remain available though, especially to plugins and codecs (because they tend to inherit external code). If you feel strong about it, you could ue a mcrothat als prints a #warning 15.13.52 # *could use a macro that also prints a #warning 15.13.52 # It's probably worth a mention in docs/CONTRIBUTING - that we prefer strlcpy to strncpy 15.14.00 # (for new code) 15.14.01 # kkurbjun: thanks 15.14.04 # * gevaerts wonders what happened there 15.14.11 # can codecs use the pluginlib? 15.14.29 # No, but they have a codeclib... I don't see why codecs need strncpy though. 15.14.46 # linuxstb: currently none do 15.15.01 # Then I say ignore the codecs. 15.15.10 # I have to go to my music class... will come back for more details later... 15.15.13 Nick aditya is now known as adi|away (n=aditya@59.95.46.25) 15.15.27 # so moving it to the plugin lib is fine with you? 15.15.39 # or should it remain in core? 15.16.12 # I don't feel strongly... Although I'm generally in favour of changing imported code, so would be tempted to remove uses of strncpy if they can all safely be replaced with strlcpy... 15.16.13 Join funman [0] (n=fun@rockbox/developer/funman) 15.16.24 # linuxstb: they could want it in metadata reading, but I guess that's one of the areas that need lots of changes anyway 15.16.56 # gevaerts: metadata reading is in the core anyway. 15.17.18 # And yes, our metadata parsers are all written specifically for Rockbox. 15.17.27 # linuxstb: that's why I suggested the #warning. You can then use it while porting so you can concentrate on the difficult bits, but you have to get rid of it before committing 15.18.04 Quit TheSeven ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]") 15.18.09 # I don't think strncpy is even used much in metadata parsers though, as the text often needs to go through character-encoding conversion. 15.18.24 # There is a question. for flyspray, how can I add the task in "This task depends upon"? 15.19.32 # ucchan: Is this a task you created yourself? 15.21.26 # n1s: core isn't going to use imported code without heavy changes anyway, so if strncpy is strongly deprecated, I see no reason to allow it there 15.21.29 Join LiamAether [0] (n=chatzill@32-44-239-77-pool.cable.fcom.ch) 15.22.07 # n1s: Which plugins will be left which use strncpy? 15.22.15 # gevaerts: ok, so pluginlib it is 15.22.45 # linuxstb: pdbox is a heavy user and i left doom too 15.22.47 # hello 15.27.05 # n1s: Yes, looking at them now, it would seem a bit intrusive to change those... 15.27.07 # Hi, linuxstb. I would like to add to my task 15.28.16 # ucchan: When you click on "Related tasks", do you see a "Add new related task" box? 15.29.44 # No "Add new related task". 15.30.04 # Then I guess you don't have the rights to do it. What task do you want to edit? (I can do it) 15.30.12 # "Remove" button only. 15.31.25 # Because the authority which I have is not enough probably will be? 15.31.53 # I just recently updated my rockbox to 3.3. Now my custom theme is broken. Did the syntax of the wps change? 15.32.42 # LiamAether: When did you previously update? 15.33.08 # ucchan: I can make the change if you tell me what you want to do. 15.33.49 # I occasionally manually dropped the build of the daily zip in to the .rockbox directory, today I used the automated installer and that updated the bootloader too 15.37.18 # LiamAether: But yes, there have been various changes to the WPS syntax over the past year or so, but I can't remember anything in the last few months... 15.37.43 # I didn't think it would be a problem, since I used a simple text theme 15.37.45 # Did your previous updates definitely work? i.e. did you see any changes in Rockbox? 15.38.10 # I haven't noticed anything in the UI 15.39.10 # Maybe your manual updates didn't work then, and only when you used rbutil did the update actually happen... The most common problem is that the WPS parser is now stricter, so it will reject your WPS when it sees some errors, rather than just ignoring them. 15.39.47 Quit CaptainKewl (Remote closed the connection) 15.40.32 # any way to cscan the wps for errors, so I can correct them? Would be a bit tedious to compare it manually to the wiki 15.41.21 # For FS#10433, I would like to add to FS#10422, FS#10423. For other my patches (codec's patches, text viewer's patches, etc.), I want to add tasks. 15.45.29 Quit _zic ("Ухожу") 15.48.40 # ucchan: OK, I have changed 10433 15.51.28 # linuxstb thanks. 15.52.11 # And I want to edit my wiki page (YoshihisaUchida), Whom should I ask? 15.53.27 Join Lynx [0] (n=Lynx@xdsl-87-79-49-179.netcologne.de) 15.53.30 Join aaron424 [0] (n=chatzill@adsl-065-013-002-216.sip.asm.bellsouth.net) 15.53.54 Nick Lynx is now known as Guest62708 (n=Lynx@xdsl-87-79-49-179.netcologne.de) 15.55.50 # On the Wiki page, I want to manage my tasks (patch, bug, etc.). 15.56.57 # LiamAether: The sim with --debugwps will tell you about errors. There is also a checkwps utility in svn 15.57.49 Quit Lynx_ (Read error: 60 (Operation timed out)) 15.57.49 # New commit by 03nls (r21863): FS#10080 ... 15.57.49 Nick Guest62708 is now known as Lynx_ (n=Lynx@xdsl-87-79-49-179.netcologne.de) 15.59.12 Join evilnick [0] (i=0c140464@gateway/web/freenode/x-54a3aecc9e00aa88) 15.59.16 # ucchan: You can ask me! I have just given you rights to edit the wiki. 15.59.16 Join TheSeven [0] (n=theseven@dslb-084-056-137-169.pools.arcor-ip.net) 15.59.18 # AlexP: Thank you. But I don't seem to be able to find that svn. 15.59.27 # svn.rockbox.org 15.59.51 # * linuxstb proposes MrSomeone writes a "debugwps" plugin 16.00.52 # a gui based wps editor with preview would be a dream 16.03.52 # LiamAether: Do you want to post your wps somewhere? Maybe someone can help out and see the mistake immediately... 16.04.29 # Oh! thanks. I can edit my wiki page. My page is edited in an idle moment. 16.04.53 # linuxstb: Alright. I wasn't sure if it was allowed. 16.05.11 # I've found checkwps, but apparently it's sourcecode for linux 16.05.13 # Don't paste the whole thing here - just a link to it... 16.05.23 # No, it will compile fine for windows... 16.05.29 # (and OS X, and ....) 16.05.33 # of course a link 16.05.59 # who in their right mind would post an entire file to an irc channel? 16.06.18 # Not everyone is in their right mind... 16.09.57 Quit evilnick ("Page closed") 16.10.44 # n1s: \o/ 16.11.28 # linuxstb: porting checkwps shouldn't be a too tough job 16.11.48 # * n1s fixes red 16.13.01 # alright, here's my wps file: http://www.mediafire.com/download.php?f3doqkyzyvq 16.13.30 Quit LiamAether (Read error: 104 (Connection reset by peer)) 16.13.35 # kugel: BTW, what is your dev-list post about? What are you proposing to commit - the patch in FS#9873? 16.14.08 # * linuxstb thinks that perhaps FS#9873 and allowing "spare" buttons to be customised is a question for the RSB 16.15.35 Join LiamAether [0] (n=chatzill@32-44-239-77-pool.cable.fcom.ch) 16.15.35 # New commit by 03nls (r21864): Missed one strncpy call 16.15.48 # I'm sorry, Firefox crashed 16.16.14 Quit MrDuck (Success) 16.16.19 # LiamAether: You could just paste the wps code into e.g. pastebin.com 16.16.38 Join evilnick [0] (i=0c140464@gateway/web/freenode/x-8cd53085919a46cf) 16.16.48 # oh alright I try that 16.17.03 # It makes it easier for people to look at :) 16.17.16 # sorry, I didn't know about that 16.20.35 # http://yourpaste.net/2357/wps%20file 16.23.07 # make: Das Target »all« wurde wegen Fehlern nicht aktualisiert. 16.23.32 # Hmm, seems checkwps is broken again... 16.23.35 # amiconn, would it make sense to set LANG variable to "C" on your build client ? 16.25.57 Join AndyIL [0] (i=AndyI@212.14.205.32) 16.26.33 # The new build system already does this. Do you think it's worth doing this for the old system? 16.28.48 # no 16.33.09 # * linuxstb blames http://svn.rockbox.org/viewvc.cgi?view=rev&revision=19357 for breaking checkwps, but can't believe it's been broken for 7 months... 16.35.45 Part teru ("Leaving...") 16.35.58 # * gevaerts is a bit surprised by the strlcpy() delta 16.36.47 Join toffe82 [0] (n=chatzill@74.0.180.178) 16.36.57 # linuxstb: Why not? Do you know anyone who uses it? 16.37.06 Quit AndyI (Read error: 110 (Connection timed out)) 16.37.08 Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) 16.37.36 # The theme site uses it doesn't it? 16.37.48 # it's funny how I don't get half of what's discussed in here 16.37.50 # AlexP: Yes, it should do... 16.39.03 # gevaerts: Our strncpy() was optimised, strlcpy() isn't :\ 16.39.08 # LiamAether: I think the problem with your WPS is the standalone "|" character. Maybe replace that with "%|" 16.39.28 # alright I try that 16.39.45 # I still cannot manage to install the rockbox bootloader on my m250 v4 16.40.00 # That's why the delta is much smaller on SH1 - it builds using -Os, meaning __OPTIMIZE_SIZE__ is defined 16.40.19 # rasher, scorche|sh: Do you know when checkwps was last updated on the themes site? 16.41.46 # wow something that simple... 16.42.23 # linuxstb: I'm going to implement it for all (if possible) 16.42.38 # and it's not costumizable, it's fixed 16.42.49 # "it" is what exactly? 16.43.08 # the function the patch adds 16.43.36 # * linuxstb gives up... 16.43.49 # linuxstb: i.e. playlist viewer from wps (and insert-into-playlist in the filebrowser) 16.44.10 # So two new features? 16.44.18 # but I only intend to commit the first part for now 16.44.40 # is the description on the task really that unclear? 16.45.31 # No, the task is clear, but your repeated references to "it" and "the first part" are not. 16.46.12 # And the fact that the mailing list thread you replied to was a long discussion about many things, getting nowhere... 16.46.38 # so? 16.48.12 Quit ucchan ("Leaving...") 16.51.40 # linuxstb: ages ago - it doesn't compile these days 16.51.57 # linuxstb: I can check when the last time was 16.52.05 # rasher: Yes, that would be useful... 16.52.26 # I'm guessing it's r19357, which brings the entire settings struct into the wps parser... 16.53.42 # linuxstb: some on 2009-04-26, some on 2009-05-13 16.53.55 # Hmm... 16.57.37 *** Saving seen data "./dancer.seen" 16.58.44 Quit kugel (Read error: 60 (Operation timed out)) 16.58.47 # * linuxstb sees r20000 builds (almost), so that's not the problem... 17.00.50 Join Sajber^1 [0] (n=Sajber@81-235-177-115-no54.tbcn.telia.com) 17.02.23 Join Grahack [0] (n=chri@stc92-1-82-227-106-100.fbx.proxad.net) 17.02.29 # wasn't a checkwps build going to be added to the new build system? 17.02.56 # linuxstb: If you aren't too busy, would you mind looking at another wps? 17.04.43 Join Lear [0] (i=chatzill@rockbox/developer/lear) 17.06.19 # mcuelenaere: It seems a good idea 17.07.20 # http://yourpaste.net/2359/another%20wps 17.10.33 # * linuxstb bisects and now blames r20977 17.11.27 # LiamAether: I think the problem there will be (at least) the progress bar - that changed... 17.11.30 Join dash32 [0] (n=dash32@84.171.85.39) 17.12.18 # %P|pbar.bmp|? 17.13.34 Join BryanJacobs [0] (n=bryanjac@128.151.67.243) 17.14.22 # LiamAether: Yes, the %P tag doesn't exist any more - use %pb (I think - I'm not a WPS expert...) 17.14.44 # I just look %pb up on the wiki 17.15.57 Quit jfc^2 (Read error: 104 (Connection reset by peer)) 17.16.19 Join jfc^2 [0] (n=john@dpc6682208002.direcpc.com) 17.17.56 Quit Sajber^ (Success) 17.18.13 # linuxstb: Thank you. That really was the only problem. 17.20.26 Join itcheg [0] (i=4117734b@gateway/web/freenode/x-5ccff72a3f24d033) 17.24.06 Part itcheg 17.24.15 Join itcheg [0] (i=4117734b@gateway/web/freenode/x-5ccff72a3f24d033) 17.25.18 # odd that you just noticed that now, the status bar changed a year ago 17.25.58 # saratoga: I think LiamAether thought he was updating, but in fact his updates didn't work, until he used rbutil for the first time... 17.26.35 Join FOAD_ [0] (n=dok@dinah.blub.net) 17.28.28 Quit Zarggg () 17.30.47 Join pyro_maniac1 [0] (i=foobar@p57BB8E58.dip0.t-ipconnect.de) 17.30.48 # n1s: did you see the "Achievements of Mr Someone" bit on the wiki? 17.31.10 # funman: ping 17.31.36 # pong 17.32.47 # funman: i know its not the right way to ask but will there be a chance that you will have a look at the sound of the YH-920 ? 17.32.50 # gevaerts: can't say that i did 17.33.43 # pyro_maniac1: could be, but i don't see this happening in a near future, also because i know next to nothing about PortalPlayer chips 17.33.57 Quit jfc^2 (Read error: 104 (Connection reset by peer)) 17.34.04 # n1s: near the bottom on the MrSomeonesTodoList page. Usually his achievements are moved there instead of being deleted 17.34.17 # gevaerts: ah, ok, will add it 17.34.19 Join jfc^2 [0] (n=john@dpc6682208002.direcpc.com) 17.34.49 # funman: so low_light need a YH-920 to fix that? 17.35.16 # a bit weird to write "kudos " :) 17.35.43 # pyro_maniac1: i don't know if he's interested in yh920 17.36.06 # n1s: you could let MrSomeone take all the credit :) 17.37.59 Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 17.38.51 # funman: as far as i know he owns the other devices. and sound is the last missing thing to get these devices "supported" thought 17.40.36 # aren't plugins also needed for these to be supported? 17.40.47 # and battery charging 17.40.58 # and a manual 17.41.03 # and rbutil support? 17.41.21 # wasn't there a change on the devcon? 17.41.44 # there was 17.43.08 # For basic "supported" status (I don't remember if we found a good name for it), the port needs to be usable for normal day to day use. That means that if it doesn't eat your files and it usually can play them, it's probably good enough 17.43.59 # IIRC, basically the porters decide if it's good enough 17.45.35 # gevaerts: Isn't a way to install it also useful? 17.45.58 # * linuxstb wonders if the beast will ever enter "supported" status... 17.46.30 # linuxstb: the DevConEuro2009 page says "fairly stable and documented install mechanisms are required. A target would need to be useful for daily use for music listening" 17.46.43 # so yes, you need to be able to install 17.47.03 # gevaerts: Do you think that contradicts what's been on the TargetStatus page for a while? http://www.rockbox.org/twiki/bin/view/Main/TargetStatus 17.47.11 Quit FOAD (Read error: 110 (Connection timed out)) 17.47.12 Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) 17.47.52 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 17.48.05 # ehm 17.48.07 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 17.48.20 # There's one point on MrSomeonesTodoList which I did months ago... 17.49.25 # linuxstb: I'm not sure about the "three major operating systems" bit, I'd have to listen to the meeting recording again for that. The rest seems to agree 17.49.28 # Mr Someone won't be happy. You're stealing his thunder. 17.51.27 # * amiconn fixed the wiki. r19950, Feb 2009 17.51.45 Join r0b- [0] (n=rob@adsl-76-235-217-188.dsl.klmzmi.sbcglobal.net) 17.51.47 # Now just someone needs to make all those screendumps 17.52.27 # gevaerts: Well, rules can be flexible... I would expect that in most cases install tools compile easily on all three (something like mkamsboot), in which case there is no excuse to not release for all three. But if an OS X port of something more complex like beastpatcher is the only thing not done, then I wouldn't want that to prevent supported status. 17.52.54 Quit einhirn (Client Quit) 17.52.57 # linuxstb: exactly 17.53.49 # * amiconn wants beastpatcher on Amiga ;) 17.54.04 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 17.54.28 # Is your amiga running linux? 17.54.58 Quit flydutch ("/* empty */") 17.55.03 # No, it's running AmigaOS 17.56.30 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 17.56.50 Quit petur ("work->home->movies") 17.56.55 Join vedlith [0] (n=ved2@137-mi2-1.acn.waw.pl) 17.57.28 Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) 18.00.57 Quit jfc^2 (Read error: 54 (Connection reset by peer)) 18.01.18 Join jfc^2 [0] (n=john@dpc6682208002.direcpc.com) 18.01.47 Quit jfc^2 (Read error: 104 (Connection reset by peer)) 18.02.08 Join jfc^2 [0] (n=john@dpc6682208002.direcpc.com) 18.02.39 Quit jfc^2 (Read error: 104 (Connection reset by peer)) 18.02.51 Join JdGordon| [0] (i=ae91cd87@gateway/web/freenode/x-ed43fb1bbb241c10) 18.03.00 Join jfc^2 [0] (n=john@dpc6682208002.direcpc.com) 18.03.05 # linuxstb: I'd expect that about half of the in-progress ports listed on TargetStatus could be moved to "suppported, but not released" 18.03.27 Quit jfc^2 (Read error: 104 (Connection reset by peer)) 18.03.28 # With footnotes for most of them of course 18.03.38 # does that mean we are changing the meaning of unsupported? 18.03.48 Join jfc^2 [0] (n=john@dpc6682208002.direcpc.com) 18.04.07 # JdGordon|: I don't think it's ever had an official meaning... 18.04.08 # * GodEater still thinks we need a better definition of the term "supported" 18.04.17 Quit jfc^2 (Read error: 104 (Connection reset by peer)) 18.04.22 # GodEater: Isn't that what you defined at devcon? 18.04.38 Join jfc^2 [0] (n=john@dpc6682208002.direcpc.com) 18.04.39 # linuxstb: it's what I tried to define 18.04.59 # linuxstb: my impression at devcon was that we all agreed on what we meant, but we had no idea which words to use 18.05.05 Quit jfc^2 (Read error: 104 (Connection reset by peer)) 18.05.13 # we've used the term in the past to mean both "will run rockbox" and "will run rockbox and we'll provide help for it" 18.05.22 # gevaerts: Didn't anyone point to the text on TargetStatus? 18.05.25 # it's not clear in some cases which is which though 18.05.32 Join jfc^2 [0] (n=john@dpc6682208002.direcpc.com) 18.05.36 # linuxstb: didn't you listen to the meeting ? :) 18.05.39 # linuxstb: maybe 18.05.41 # GodEater: No... 18.05.59 Quit jfc^2 (Read error: 54 (Connection reset by peer)) 18.06.00 # and after petur went to all that trouble to record and edit it. tut tut. 18.06.11 # Did he ever release a two-channel version? 18.06.20 Join jfc^2 [0] (n=john@dpc6682208002.direcpc.com) 18.06.24 # can we set a ban on this jfc^2 chap until he sorts his life out ? 18.06.36 # I'm getting fed up with all the joins and parts 18.06.46 # * funman ignores joins/parts/quits on #rockbox 18.06.47 Quit jfc^2 (Read error: 54 (Connection reset by peer)) 18.07.06 # just like the irclogs, this provides better readability IMO 18.07.08 Join jfc^2 [0] (n=john@dpc6682208002.direcpc.com) 18.07.37 Quit jfc^2 (Read error: 54 (Connection reset by peer)) 18.07.57 Quit Lear ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]") 18.07.58 Join jfc^2 [0] (n=john@dpc6682208002.direcpc.com) 18.07.59 # Anyway, we decided to basically have a big set of "supported" targets, meaning "will run rockbox, but not all features might be there yet (although it will play music)", and a subset of those (name unclear) being "This will work well, most likely you won't want to use the OF for anything" 18.08.01 # GodEater: anyone with a rockbox cloak can do it... I dont know the temp ban command 18.08.11 # there isn't a temporary one 18.08.20 # or any actually 18.08.25 # hehe 18.08.41 Quit jfc^2 (Read error: 54 (Connection reset by peer)) 18.08.58 # * gevaerts may misrepresent the conclusion a bit due to bad memory, but it shouldn't be far off 18.09.02 Join jfc^2 [0] (n=john@dpc6682208002.direcpc.com) 18.09.16 # gevaerts: we can go all marketting and call them silver and gold status targets 18.09.18 # I seem to have all of my Freenode channels dropping and reconnecting. 18.09.23 # or poo for anything else 18.09.28 # I'll drop off until I this resolves. 18.09.33 # jfc^2: Thanks. 18.09.36 Part jfc^2 ("I wonder what this button over here does..") 18.10.01 # that sounds about right to me gevaerts 18.10.42 # JdGordon's suggestion isn't entirely without merit either 18.10.53 # it was proposed I think 18.10.55 # though it pains me to say it ;) 18.11.07 # :) 18.11.38 # * gevaerts thinks he'll spend some time tonight on actually make some devcon decisions a reality 18.16.09 Part pyro_maniac1 ("Leaving.") 18.17.55 Quit robin0800 (Remote closed the connection) 18.18.20 # JdGordon|: is battery life a real problem for supported status? 18.18.32 # the Sansa AMS have much less battery life than the OF, but still are very usable 18.18.39 # Licensing and GPL compatibility is such a grey area :( 18.18.51 # funman: not really 18.19.11 # but having 1/3 the OF is never nice 18.19.24 # i have some ideas but wait for SD driver stability to work on it 18.19.41 # I'd say that battery life can be important for gold, but never for silver 18.20.25 # yeah, I 18.20.27 # 'd agree 18.20.30 # instead of using precious metals, what about using other elements? (noble gases?) 18.20.53 # ignoble alkaloides! 18.21.17 # Helium (light) for started ports, up to the heaviest element for the best status? 18.21.50 # just don't use things that begin with uu 18.21.50 # no, we should use arbitrary numbers instead 18.22.05 # or, maybe the first few greek letters?! 18.22.18 # "newbie: the beast port is current only unununium status, don't use it" 18.22.47 # sholdnt you be drawing picturs BryanJacobs ? 18.22.52 # :D 18.23.17 # JdGordon: aren't I supposed to be "part of the community", playing with all the cool kids here in #rockbox? 18.23.23 # :-P 18.23.40 # * BryanJacobs is on target for being done by the pencils down date 18.23.51 # yay :) 18.24.04 # not with the pictures, those will be done sooner ^_^ 18.28.34 # amiconn: You have a GPL problem? 18.29.26 # I would still like to port XSkat to rockbox, but its license is not GPL compatible. 18.29.45 # The question is whether loading a plugin can be considered static or dynamic linking 18.30.01 # * BryanJacobs remembers the long discussion on this topic about codecs earlier 18.30.03 # We've always considered it to be... 18.30.44 # http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins 18.30.47 # linuxstb: to be, static or dynamic? 18.30.48 # Yeah, just bringing it back up because I'm reading up a bit on the linux kernel 18.31.20 # My view at least is that I want all code in Rockbox (including plugins/codecs and even "data" like themes and fonts) to be GPL'd, or a similar "libre" license... 18.31.25 # i have a mp3 which causes my clip to stop playback every time i think... is it useful? 18.31.46 # amiconn: what is the licence of xskat? 18.31.47 # JdGordon|: Is it specific to the clip? 18.31.51 # funman: To be whatever forces plugins to be GPL'd. 18.31.52 # hmm.. maybe not 18.31.58 # JdGordon|: no 18.32.20 # funman: It's a homebrew license that would be gpl compatible except for a single term 18.32.56 # The GPL doesn't allow further restrictions apart from those it imposes itself. That homebrew license doesn't allow to make XSkat clones and call them XSkat 18.33.26 # rrrrgh, like BSD-4. That's obnoxious 18.34.13 # why do people DO that? Copyright law protects you from other people stealing your logo/name, you don't need a license! 18.34.33 # people are stupid 18.34.48 Nick adi|away is now known as aditya (n=aditya@59.95.46.25) 18.35.23 # linuxstb: Yeah, but that's exactly the grey area. If loading a plugin equals dynamic linking, it is debatable whether the plugin should be considered derived work, especially if it wasn't originally written for rockbox 18.35.26 Join Ubuntuxer [0] (n=johannes@dslb-094-221-094-133.pools.arcor-ip.net) 18.36.33 # There's also the possibility of having an LGPL'd glue layer - but if that is possible, what makes that solution special? 18.36.48 # amiconn: Well, what I'm saying is that whilst the legalities are a grey area, there's also a desire (at least from me, and I hope others) to keep all of Rockbox under the GPL, or something compatible. 18.38.52 # BryanJacobs: I didn't think you could copyright a name, just trademark it? 18.39.15 # if you produce an intellectual work, you automatically hold copyright: that includes logos 18.39.31 # Yes, but a name isn't an "intellectual work"... 18.39.33 # the name could be a work but is most likely a trade name, you're right 18.39.50 # luckily, those are also automatically protected the moment you use them to do business :-) 18.40.16 # you don't NEED to register a tradement; the date of registration is just kind of like the date of a patent request, it shows when you had the idea 18.40.32 # kkurbjun: hey you there? 18.40.33 # and also puts the burden of diligence of the infringer 18.40.40 # *on the 18.42.28 Join kugel [0] (n=kugel@rockbox/developer/kugel) 18.42.34 # The xskat license appears to be intended to stop people releasing derived versions of xskat not clearly distinguished from the original. The GPL also has similar clauses, so I don't see it as incompatible in spirit... 18.42.58 # BryanJacobs: It's quite a murky situation. Given that different countries have different requirements. 18.43.38 # linuxstb: which clauses of the GPL are similar? 18.43.44 Quit JdGordon| (Ping timeout: 180 seconds) 18.43.45 Quit r0b- (Read error: 110 (Connection timed out)) 18.43.47 # BryanJacobs: 2a) 18.44.03 Quit aaron424 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060308]") 18.44.20 Quit Ubuntuxer ("Leaving.") 18.44.33 Join r0b- [0] (n=rob@adsl-76-235-217-188.dsl.klmzmi.sbcglobal.net) 18.44.50 Quit gevaerts (Nick collision from services.) 18.45.00 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 18.45.42 # but the GPL would still allow you to call the modified version "xskat" 18.46.54 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 18.46.58 # True. I'm really just talking about my personal opinion, not whether they're legally compatible license, which I would say they're probably not. 18.47.28 # I love clause 2c and how worthless it is 18.48.20 # "you must print out a copyright notice when the program starts and a disclaimer of warranty. Unless you don't feel like it, in which case you don't have to." 18.48.38 Quit LiamAether ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 18.48.58 # amiconn: Have you ever contacts the xskat author? 18.49.05 # yes 18.49.42 Join JdGordon| [0] (n=Miranda@nat/microsoft/x-21e3542d0e1a6051) 18.51.03 # amiconn: What did he say? 18.52.21 # New commit by 03Toni (r21865): Collect encoder data chunks (usually < 1kB) before writing to disk. The reduced number of ci->write() calls give a nice write speedup to the mp3 ... 18.52.43 # He doesn't want to relicense XSkat under the GPL. What is strange though is that he puts the card images under the GPL 18.53.00 # markun, anyone, I saw an inexpensive Samsung YP-S3 for sale and downloaded the firmware upgrade file to have a look at it. It contains big-endian ARM code, there's a string saying "8700" and it seems to access the same addresses for peripherals as mentioned in the s5l8700 datasheet! 18.53.20 # amiconn: you could ask for a Rockbox-specific inspection 18.53.23 # **exception 18.53.42 # Nope, as that wouldn't be GPL compatible 18.54.05 # Or a stripped-down version of the core code licensed under the GPL (basically, dual-licensing the core) 18.54.14 # BryanJacobs: it's the rockbox license that's the blocker here 18.54.35 # you could ask him for permission to call your derived version under the same name, in which case you would be reduced to GPL compatibility by voiding that extra restriction 18.54.36 # * linuxstb has had these kind of conversations with people in the past, and they've never been fruitful - people who use home-brew licenses don't seem to understand them... 18.54.36 # yeah, I suppose saying "you can only use this in Rockbox" is an extra restriction :-P 18.54.52 # The core code is what he put under this homebrew license. The X11 gui parts would need to be replaced 18.55.34 Quit Sajber^1 (Connection timed out) 18.55.41 # it sounds like the underlying problem here is that the guy is too stupid to understand his own licensing, so might as well ask him the simplist possible question 18.55.54 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 18.56.19 # No he isn't 18.56.30 # He says that his license is GPL incompatible on purpose 18.56.44 # I still have the whole conversation (in German) 18.56.48 # but if he just gave *us* the ability to call it "xskat", then it wouldn't be OK anyhow because being part of Rockbox is an extra restriction above the GPL 18.57.38 *** Saving seen data "./dancer.seen" 18.59.04 # amiconn: It sounds like there's no solution. Any kind of "hack" to Rockbox to get around the GPL would (I guess...) open up closed-source plugins... 18.59.30 # no it wont 18.59.48 # closed source plugins wont happen because the api changes too often 19.00.03 # What about releases? 19.00.07 # It's a real pity because (1) there seems to be no other open source skat engine and (2) XSkat *is* open source - just not gpl compatible 19.01.44 # how complex is xskat ? 19.01.48 # amiconn: Yes, I agree. There's also the entire emulator world, most of which has the "no commercial use" clause. Fine for us in practice, but not GPL compatible... 19.02.54 # amiconn: You just need to get the xskat author interested in Rockbox... 19.03.02 # linuxstb: I'd consider "no commercial use" a deal breaker. That's not *just* GPL-incompatible 19.03.33 # it might be nice to see a hardware player which comes with Rockbox stock 19.03.51 # and that would be excluded by "no commercial use" 19.03.57 # exactly. We don't want to forbid that 19.04.20 # Also, how about getting paid to record something? 19.04.32 # gevaerts: That's what I meant by "in practice". I really don't see anyone using Rockbox commercially... 19.04.36 # or using a Rockbox-powered device as a DJ 19.05.01 # Hmm, the XSkat author violates the GPL himself 19.05.08 # linuxstb: really? "commercial" doesn't imply big enterprises... 19.06.19 # selling a rockboxed player on ebay for example? 19.06.24 # Hmm, or not. The cardset is licensed under the GPL, but it's his own work, so he can dual license it 19.06.45 # amiconn: you actually can't violate the GPL for something you own the copyright to 19.06.52 # yea 19.07.19 # amiconn: also, whether using a cardset is linking in the GPL sense is another one of those nice grey areas 19.07.32 # it's a shame Stallman didn't make a pluggable license (I understand why he didn't, I just don't think the GPL has been the unifier he hoped for) 19.07.36 # It's built-in, as C arrays 19.07.54 # BryanJacobs: Why can't you violate the GPL on your own software? 19.08.11 # linuxstb: because you don't need the gpl as the owner 19.08.11 # real pity because (1) there seems to be no other open source skat engine and (2) XSkat *is* open source - just not gpl compatible 19.08.14 # linuxstb: because you own it :-) you can use it how you like OUTSIDE of the GPL 19.08.14 # -------------------------------------------------------------------------------------------- 19.08.17 # 19:01:44 < funman> how complex is xskat ? 19.08.33 # linuxstb: http://www.gnu.org/licenses/gpl-faq.html#DeveloperViolate 19.08.42 # amiconn: ah, interesting. Sounds non-distributable then... 19.09.15 # Well, in this case it's a dual license. Homebrew in built-in form, and GPL's in gif form 19.09.19 # BryanJacobs: Yes, but if I offer you some software under the GPL, but then refuse to give you the source, aren't I violating the GPL? 19.09.53 # linuxstb: no. You're violating a promise, but not the GPL as such 19.10.16 # linuxstb: the GPL says you must accompany redistribution with the source - not that the copy you receive MUST HAVE COME with the source code 19.10.33 # technically, the person on the giving end doesn't agree to the GPL - only the receiver does 19.10.43 Quit stoffel (Read error: 113 (No route to host)) 19.12.39 Quit r0b- (Read error: 110 (Connection timed out)) 19.12.51 # for instance, I could give you some software with a license that says "you must stab yourself in the chest in order to redistribute this code", but I don't have to stab myself to give you that license 19.12.57 # * gevaerts reads the xskat version and ends up confused 19.13.37 Quit n1s ("Lämnar") 19.14.59 Quit itcheg (Ping timeout: 180 seconds) 19.15.26 Join Sajber^ [0] (n=Sajber@81-235-177-115-no54.tbcn.telia.com) 19.15.40 # * linuxstb moves to #rockbox-community 19.15.53 # BryanJacobs: Anyway, how goes wavpack? 19.16.39 # linuxstb: working on buffering drawings right now 19.17.07 Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) 19.17.40 # have you tried FS#10434 19.17.42 # ? 19.18.11 # it works... not perfectly, but it works on target 19.20.19 Join Ubuntuxer [0] (n=johannes@dslb-094-221-080-104.pools.arcor-ip.net) 19.20.38 # BryanJacobs: No, I'll try and have a play tonight. Did you ever measure the binsize increase? 19.21.08 # linuxstb: no, take a look at the disclaimers on that patch :-) 19.21.17 # I have two HUGE buffers in there 19.21.35 # this patch isn't designed for real use... it's a proof of concept 19.21.58 # in fact, I think this will only work on targets with 64MB of RAM 19.22.45 # How big is huge? 19.23.16 # BTW, your patch contains vorbis.c for no good reason... 19.23.36 # linuxstb: oops 19.23.46 # no lines added/removed there I hope? 19.23.50 Join dys` [0] (n=andreas@krlh-5f72f02e.pool.einsundeins.de) 19.23.54 # Just a whitespace change... 19.23.57 # I probably touched some whitespace before doing an svn diff 19.23.59 # yeah 19.24.09 # one sec while I check how big the buffers are 19.24.27 # Someone wants to contribute a Fuzev2 to an interested developer (in case you have not noticed in on the Sansa AMS forum thread) 19.24.59 # Is adding secpath[] to mp3entry really needed? (there are a few copies of that in RAM, so it's a waste). 19.24.59 # two 15MB buffers 19.25.16 # funman: take it for your own 19.25.27 # linuxstb: no, I suppose not, it could be done just by having a bool there for "secondary file present" 19.25.39 # saratoga: if i accept the offer i don't think i'm going to look at it before months 19.25.48 # two 15MB buffers were large enough that I could play the "Bad Horse Chorus", my small Wavpack test file 19.25.51 Join daurnimator [0] (n=daurnima@unaffiliated/daurnimator) 19.26.05 # I would take it, but I'm also unsure if I had the time and energy to look at it soon'ish 19.26.11 # BryanJacobs: Where are those buffers added? They can't be in the codec itself... 19.26.12 # well, I most probably will have time, actually 19.26.20 # linuxstb: they are 19.26.21 # i have your fuze, ej0rge's c200v2, soap's clipv1 and all of them still have medium/major bugs i should fix 19.26.33 Nick fortuna is now known as karma (i=amg@host193-123-47-78-dhcp.bshellz.net) 19.26.39 # "static char blockbufs [2][BLOCKBUFSIZE];" 19.26.43 # BryanJacobs: So you've increased the codec buffer size from 1MB? 19.26.59 # Have you actually tested this on a real target? 19.26.59 # uhm, no 19.27.03 # sim? 19.27.09 # it works on the sim 19.27.10 # sim != real target ;) 19.27.14 # >_< 19.27.26 # * BryanJacobs needs to move the buffers into playback.c then 19.27.38 # funman: hasn't there been some work? 19.27.47 # 1MB will only be enough if I make them rings and rewrite libwavpack/unpack.c to handle smaller bits 19.27.49 # BryanJacobs: Or get rid of them - that doesn't look like a feasible solution... 19.27.50 # kugel: work on what ? 19.28.09 # fuzev2 (mkamsboot for example) 19.28.11 # the right solution is to make the hybrid-lossless code use little bits of audio instead of a whole block in a go 19.28.11 # we should probably take it until he changes his mind :) 19.28.16 # BryanJacobs: I thought the intention was to interleave the data in the main audio buffer? 19.28.26 # linuxstb: it is interleaved in the main buffer 19.28.30 Join stoffel [0] (n=quassel@p57B4CF2D.dip.t-dialin.net) 19.28.34 # with a big note *we can't promise anything* 19.28.45 # the issue is that there's no way to know how long it'll be before we can advance the buffer 19.28.51 # maybe I should just keep two ridx values 19.29.30 # see, it could be that we don't need a WVC chunk until after reading the next 100 WV chunks 19.29.48 # So how does the interleaving work? Does it pay any attention to the file itself, or just buffers X bytes from file one, then Y bytes from file two? 19.29.49 # "chunks" here being BUFFERING_DEFAULT_CHUNKSIZE bytes 19.29.57 # the latter 19.30.01 # 32k of one, 32k of the other 19.30.24 # Hmm, I would have expected you to look inside the file to interleave the data in the way it needs to be consumed by the codec. 19.30.48 # but see, that's the thing - the WVC blocks can be huge 19.30.52 # This is what I had in mind by "codec-specific" buffering. 19.30.54 # I did that research back at the beginning 19.31.04 # So you're saying that's not feasible? 19.31.11 # well, it will be for large buffers 19.31.24 # kugel: yes there is already dual boot support for fuzev2, in an external git repository 19.31.26 # but for small ones or large files we'll get a buffer full of WV 19.31.34 # or WVC, with none of the other file having room 19.31.48 # why is it not in SVN? :( 19.32.24 # hm. 19.32.28 # So do you need random access to the entire WVC block, or is it processed from start to end? 19.32.39 # MrSomeone didn't do it yet / it didn't reach the top of my TODO list ;) 19.32.39 # the latter is true in the compact decoder 19.32.54 # but I haven't rewritten the hybrid-lossless code to behave that way yet 19.33.09 # no random access is required but currently it does the whole block and CRC check in one loop 19.33.53 # if it's OK to have 1MB chunks in the buffer then I can interleave the blocks 19.34.54 # funman: I'm going to write him 19.35.09 # Isn't there code that converts a lossy .wv + .wvc into a lossless .wv? 19.35.30 # yes, there is 19.35.50 # That code could be used to do the buffering, so that the in-memory stream is plain lossless .wv 19.35.51 # it decodes the wv+wvc into PCM, then reencodes it as a lossless file 19.36.09 # Oh, I thought it could be done without going through pcm 19.36.22 # the methodologies used by the hybrid encoder are incompatibly different from those used by the normal mode 19.36.53 Quit dys (No route to host) 19.37.46 # BryanJacobs: What do you mean by "1MB chunks in the buffer" ? 19.38.06 # Hmm, that leaves interleaved buffering. I guess both the .wv and the .wvc uses packets which relate to a fixed number of samples? 19.38.11 # a Wavpack block can be 1MB in size 19.38.30 # amiconn: that's a "block", yes 19.38.39 # but the size of the block is not predictable 19.38.42 # Are blocks independent? 19.38.46 # yes, they are 19.38.48 # So you could just alternate between the .wv and .wvc blocks 19.39.00 # amiconn: thus, up to 1MB interleaving 19.39.06 # ? 19.39.10 # I thought that would be too big - if not that makes the code simpler 19.39.10 Nick Horscht86 is now known as Horscht (n=Horscht2@p4FD4E2C3.dip.t-dialin.net) 19.39.17 # a block can be 1MB in size 19.39.32 # BryanJacobs: The difference (I think) is that your loader is not parsing the data to interleave at block boundaries? 19.39.37 # that's right 19.39.37 # Ah, hmm. 19.39.56 # I'll go do that, shouldn't take long 19.40.01 # Then I think lowmem targets need to be excluded from hybrid wavpack 19.40.02 # the wavpack block header format is really simple 19.40.12 # amiconn: well, if we do it this way 19.40.22 # Or maybe they could use a different method. Just decode on load, and buffer pcm 19.40.27 # kugel: I didnt get around to looking at 8799 last night :/ nothing major has changed since the last one though yeah? 19.40.32 # amiconn: whoa! 19.40.33 # no! 19.40.43 # BryanJacobs: But I think 1MB is still too big... Can you decode (e.g.) half a block at a time? 19.40.48 # (or even less)? 19.40.51 # Less efficient than buffering the compressed data, but not that much of an issue on flash targets 19.40.52 # New commit by 03Ubuntuxer (r21866): Make the progress bar in game mode puzzle shows the level process (part of FS#10139) 19.41.02 # linuxstb: yes, I need at most 4k worth of readahead 19.41.17 # but, like I've been saying, I have to change the unpack.c code to do that 19.41.21 # it's on my to-do list 19.41.21 # BryanJacobs: Hmm, then you could interleave partial blocks 19.41.30 # amiconn: you mean like I'm doing now? 19.41.47 # there is a thought process in here, really there is... 19.41.50 # BryanJacobs: Then I think that's the way forward... 1MB is just too big. 19.42.01 # well, I'm glad we've all arrived at the same conclusion 19.42.16 # I don't know how you're doing it atm, but using 15MB static buffers doesn't sound like interleaved buffering in the main buffer 19.42.30 # JdGordon|: uhm, nothing major, yes, but I found another bug 19.42.38 # bah :p 19.42.54 # amiconn: it's interleaved in the main buffer but I need to copy some stuff out to be able to do bufadvance() in a timely fashion 19.42.57 # What's the size limit of a .wvc block? I guess less than 1MB? 19.43.05 # still 1MB 19.43.13 # wvc files are bigger than .wv 19.43.31 # Err, I meant the lossy (smaller) one of course 19.43.39 # "The blocks may contain any number of samples (well, up to 131072), either stereo or mono. Obviously, putting more samples in each block is more efficient because of reduced header overhead, but they are reasonably efficient down to even a thousand samples. I have set the max size to 1 MB for the whole block, but this is arbitrary" 19.43.50 # That sounds like APE blocks - they can be very large, so Rockbox decodes them in small chunks. 19.44.37 # I think I'm going to hit those drawings first because if the main buffering system supports multiple files this whole thing is not needed 19.44.59 # but I will make the codec do partial blocks before the summer's over 19.45.19 # oh, and mono/seeking support of course ;-) 19.45.27 # The loader needs to interlave the data in the order the decoder needs it, using rather small chunks. Otherwise this scheme won't work on lowmem targets 19.45.28 # Making the codec do partial blocks seems like something it should do anyway... 19.45.54 # linuxstb: yes, should I do that first then? I'll work on whatever, all the tasks are fun 19.45.57 # kugel: what bug you find? 19.45.57 # JdGordon|: it basically breaks font loading...:( 19.46.04 # * kugel was faster 19.46.11 # no you wasnt... 19.46.13 # amiconn: you don't know the order the decoder needs it 19.46.13 # eek 19.46.23 # why does t break font loading? 19.46.57 Join r0b- [0] (n=rob@adsl-76-235-217-188.dsl.klmzmi.sbcglobal.net) 19.47.29 Quit mcuelenaere (Remote closed the connection) 19.48.02 # no idea yet, didn't look after it. but one a ui viewport setting is in the config, the font is ignored and the font setting removed from config.cfg 19.50.23 Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) 19.53.53 # BryanJacobs: I think that should be possible once the decoder can handle partial blocks. Maybe it needs at least partial decoding during buffering to decide 19.55.36 # no, we know what size a block is from the header 19.55.50 # we just don't know in what order we'll need the stuff from the block 19.56.02 # I mean, WITHIN a block it's linear 19.56.23 # but we can't say "if WV is A, and WVC is B, then we'll need bytes in order AABBAAAABAABBBB" 19.56.59 # We can say that if we do partial decoding 19.57.22 Join itcheg [0] (i=4117734b@gateway/web/freenode/x-d4c07c19ad02d9b4) 19.57.26 # well, no: just because we HAVE accessed things in a certain way doesn't mean we'll continue to do so 19.57.37 # ? 19.57.57 # let me put it this way. 19.58.07 Join Zagor [242] (n=bjst@rockbox/developer/Zagor) 19.58.08 # I mean decoding the whole block, just not all the way to pcm. Just enough to find out in what order the decoder actually requests the data 19.58.09 # in an ideal world, the byte we need next is always next on the buffer, right? 19.58.20 Quit stoffel (Remote closed the connection) 19.58.20 # amiconn: seriously? that sounds like a bad idea 19.58.33 # we do two whole passes? 19.58.43 # New commit by 03Ubuntuxer (r21867): Replace bitmap menu with a standard menu, clean up the code and remove corrupt save game 19.58.46 # one of which happens at the time of buffering? 19.58.52 # and remember, the block is 1MB large 19.59.07 # so either we buffer it and then memcpy to rearrange it 19.59.11 # or we read it from the disk twice 19.59.45 # Not two *whole* passes. Decoding certainly consists of several stages. I would think that the first stage is enough to find out the order in which data is consumed 20.00.05 # no, it doesn't quite work that way - it's a multipass filter 20.00.20 # Ubuntuxer: why does it use the doubled main menu again? I thought teru had a way to make a menu be dynamic 20.00.21 # the output of later stages get fed back into earlier ones, let me get you a flow chart 20.01.13 # BryanJacobs: I was thinking along the same lines as amiconn - that the buffering would do some parsing and re-arranging of the data, so that it is in the order the codec needs it. The codec then wouldn't need to do that parsing again. 20.01.21 # http://wavpack.com/WavPack.pdf page 2 20.01.26 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 20.01.41 Quit stripwax (Client Quit) 20.02.19 # that parsing would be the decoding process 20.02.20 # Page 2 shows the encoder, not the decoder 20.02.28 # the decoder is that in reverse 20.02.33 # ... almost 20.02.34 Join n00b81 [0] (n=n00b81@unaffiliated/n00b81) 20.02.55 # we do multiple passes through a variadic function 20.03.08 # and then apply some correction weights 20.03.14 # and the correction weights change over time 20.03.32 Quit itcheg (Ping timeout: 180 seconds) 20.05.55 Quit tomcat_ha ("If visible identification is not possible, the pathologist may be able to take fingerprints from the body until decay sets in) 20.06.56 # I think we'd have to go most of the way through the decoding process in order to get things sorted out correctly - and remember this would all take place in the buffering thread blocking disk reads! 20.07.34 # we'd be losing the advantages of having a non-PCM buffer 20.07.54 # kugel: so do you have any idea about the locks/corruption problems on Sansa AMS ? 20.08.08 # no 20.08.18 # I see that FlynDice started reading the code, i hope he will notice something .. 20.08.19 # funman, has anyone looked if logf turns anything up? 20.08.21 # I yet to experience *any* of the reported problems 20.08.38 # bertrik: what do you think we should logf() ? 20.08.39 # funman, I assume you're talking about the lowmem ams sansas 20.08.46 # bertrik: no i am not 20.09.18 # i am talking about the filesystem corruption and deadlocks which happens when using a uSD card 20.09.23 # my fuze just seems rock solid 20.09.42 # kugel: do you use uSD cards a lot? 20.09.51 # almost exclusivly 20.10.23 # i don't know much about these, but i was told there is different categories which relate to speed 20.10.32 # perhaps we can confine the problem to specific card categories? 20.11.38 # bye all 20.11.46 # my uSD is a pretty standard sandisk one, I'm not even surprised it works so welll 20.11.50 Quit BryanJacobs ("Java user signed off") 20.11.52 # i only have one card, and rockbox debug menu reports 25Mbits/s just like the internal storage 20.12.29 # kugel: do you mean you have (heard about) problems with not-sandisk cards? 20.12.49 # also, can you tell what is a "non-standard" card? 20.14.42 # funman: it's a cheap sandisk one. and sandisk "invented" SD, so I expect them to respect the standard more than others 20.15.07 # funman: i would take his fuzev2 and then work on it if you get time 20.15.16 # if not you can always forward it to another interested developer later 20.16.24 # i don't want to be a post relay 20.16.31 # BryanJacobs (logs), linuxstb: The rockbox wavpack codec already handles partial block decoding afaics. 20.16.44 # saratoga: heh, that's what I thought too (I already messaged him) 20.16.50 # i think kugel wants to work on his fuzev2 (at least i understood so) 20.17.30 # And it also looks like there are several decoding steps. The one that actually consumes the input stream(s) seems to be words.c: get_words() 20.17.40 # I told him that we cannot promise anything (he's obviously aware of this anyway) and that we share the stuff between each other if one runs out of luck/time/energy 20.19.19 # Call chain is wavpack.c: codec_main() -> wputils.c: WavpackUnpackSamples() -> unpack.c: unpack_samples() -> words.c: get_words() 20.24.39 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 20.24.39 # Zagor: http://www.rockbox.org/irc/log-20090714#14:18:14 20.25.19 # * gevaerts could probably just have repeated that... 20.26.46 # gevaerts: great. how? 20.27.54 Quit mcuelenaere (Remote closed the connection) 20.28.54 # You mean, how did it happen? 20.30.05 # yeah, or how you go repeat it. 20.30.14 # Zagor: Btw, is it on purpose that the server disconnects the clients after each round? 20.30.25 # amiconn: no. I'm fixing that now. 20.32.00 # I don't know how to make it happen. The last line before "Terminated" was "2009-07-14 13:47:22 Completed build h300" 20.32.28 # * amiconn wonders how he could monitor the build client once it's running in the background 20.32.52 # This was for revision 21859 on client hex 20.32.59 # amiconn: screen 20.33.02 # Zagor: same thing happened here... (jakorasia) 20.33.47 # 2009-07-14 11:23:34 Completed build h10 <-- after that, terminated 20.34.11 # I don't use screen, and I would like to run it completely in the background, so that it starts running after boot without me logging on 20.34.23 # I.e. from an init script or cronjob 20.34.23 # Could it be a race where it tries to kill the process just after it has stopped by itself? 20.34.51 Quit DaCapn (Read error: 60 (Operation timed out)) 20.35.08 # My case was very near the end of a round (it got Server message: 3 builds left 22 seconds earlier if I read times right) 20.35.11 Quit r0b- (Read error: 110 (Connection timed out)) 20.36.01 # amiconn: Does the output of the build client get written to a file? 20.36.55 # amiconn: I'd run "./rbclient.sh > rbclient.out 2>&1 funman: Yes I've been reading the sd code but mainly to troubleshoot the card init problems caused by voltage scaling. 20.37.42 # Of course I would log the output to a file. That still leaves the question how to monitor whether it has crashed/exited 20.37.56 # Zagor: what will "my $pid = $builds{$id}{pid}; 20.38.09 # " put in $pid if $builds{$id} has been cleared? 20.38.25 # gevaerts: 'undef' 20.38.35 # similar to null 20.38.43 # Zagor: and if you give that to kill? Could that then send the signal to itself? 20.39.34 # gevaerts: no idea. testing it now. 20.39.44 # * gevaerts suspects that this might be the problem 20.40.28 # yup, killing undef indeeds kills yourself 20.40.32 # funman: re: sd v1 and 1<<23 for ocr register in SD_APP_OP_COND, do you have any Idea where that comes from besides ata-sd-pp.c? 20.40.35 # good catch! 20.41.51 # * gevaerts thinks that the perl documentation should have warned about this 20.42.34 # yeah 20.43.20 # most people probably don't try to kill undef 20.44.15 # yea, blame perl 20.44.28 # kugel: so are you going to take that V2 fuze? 20.44.47 # kugel: actually, in this particular case, I'm tempted :) 20.46.04 # saratoga: yes, it seems. I wrote him, that once he answers he'll be getting my address 20.46.40 Join r0b- [0] (n=rob@adsl-76-235-217-188.dsl.klmzmi.sbcglobal.net) 20.46.42 # and he just did 20.50.43 Quit jfc (Read error: 104 (Connection reset by peer)) 20.51.05 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 20.55.07 # New commit by 03zagor (r21868): Don't kill undef $pid. 20.57.41 *** Saving seen data "./dancer.seen" 20.58.44 Join webguest38 [0] (n=562d61f0@gateway/web/cgi-irc/labb.contactor.se/x-dcd1dd00b76b7dd2) 20.59.34 Join raphi [0] (n=raphi@pub082136118205.dh-hfc.datazug.ch) 21.00.33 Quit raphi (Client Quit) 21.03.33 Quit Grahack ("Leaving.") 21.04.10 Join scorche [50] (n=scorche@rockbox/administrator/scorche) 21.09.33 Join WPS [0] (n=5ce22570@gateway/web/cgi-irc/labb.contactor.se/x-550110c383cfd040) 21.10.34 # linuxstb: re fs#9873, I uploaded the one I intend to commit on the tracker 21.11.03 # hey, how do you simulate "charger plugged in" in the h10 20gb simulator? Can charging be simulated? i didn't find it on the UIsimulator wikipage. 21.12.00 # U simulates usb insertion, I assume if you hold the special button to charge-only it will simulate charg-only in the sim too 21.12.35 # scorche|sh: Do you have any intention to carry on with the AV300? Seeing it in kugel's patch, I'm wondering if that port can be killed... 21.13.08 # yea, pretty annoying to make up keycombos for dead ports 21.14.07 Nick n00b81 is now known as n00b81|away (n=n00b81@unaffiliated/n00b81) 21.14.07 # FlynDice: bit 23 set in SD_APP_OP_COND argument comes from OF disassembly 21.14.08 # i already tried that key combination but it doesn't work... 21.14.27 # does it simulate USB at least? 21.14.43 # FlynDice: it could well be some SanDisk code reused in their PP and AMS players .. 21.15.14 # yes, in a way meaning it only shows the usb sign 21.16.29 # funman: I have checked sandisk v1 spec and the linux source code and they seem to not use the 1<< 23 21.16.50 # for v1 sd 21.17.04 # FlynDice: i think this is controller-specific (voltages supported by the controller) 21.17.07 # the internal memory might needed it? 21.17.12 # need* 21.17.27 # kugel: i have seen no distinction between internal storage and microSD 21.17.32 # do you mean the as3525 or the sd controller? 21.17.59 # funman: I mean, maybe the internal does need it, but the microsd doesn't care so they just didn't special case it 21.18.06 # the sd controller embedded in the as3525, and the (identical, pl180) sd controller added by SanDisk in their players 21.18.25 # kugel: what's "it" ? 21.18.32 # the 1<<23 thing 21.18.50 # let me look again but I found that the as3525 could supply 2.0 - 3.6 21.18.53 # please check what it means exactly 21.19.08 # we have to give the cards the list of voltages we support 21.19.37 # for sdv2 cards we just say we support all voltages, and for sdv1 we only say we support the lowest voltage (bit 23 is the last bit in the voltage array) 21.20.06 # FlynDice: we can't make assumption for the sd controller attached to the internal storage since it's not in the original as3525 design 21.20.08 # could that be the problem of some clips? 21.20.11 # the 1<<23 says we support only 3.5-3.6 21.20.21 # ah, so it is the highest voltage 21.20.26 # WPS, kugel: The sim automatically simulates battery discharge and charging cycles 21.21.52 Join shotofadds [0] (n=rob@rockbox/developer/shotofadds) 21.21.55 Quit robin0800 (Remote closed the connection) 21.22.17 Nick n00b81|away is now known as n00b81 (n=n00b81@unaffiliated/n00b81) 21.24.09 # kugel: I'm at work now so cant look at the patch, what was the final outcome for 9873 regarding button choice? 21.24.18 # or there is no choice? 21.24.35 # Do people remember if the "gold" targets require rbutil support? 21.25.23 # rbutil and manual is for platinum targets 21.25.44 # hm... 21.25.53 # * gevaerts decides to listen to the recording to make sure 21.26.23 # IIRC the descision was to not have those two as blockers for releases 21.26.55 # JdGordon|: it never was about choice, not for me at least 21.27.30 # then I dont see the point of adding it 21.27.58 # I think we should have rather a tight definition of silver and gold (whatever the names will be) 21.28.07 # funman: sorry, not the as3525 but the pl180 docs say we can supply 2.0-3.6 21.28.09 # but I do 21.28.46 # kugel: I'm working on a mail to -dev that has what I remember as the consensus in it, with a list of possible candidates for addition 21.28.49 # FlynDice: makes sense then, did you test it on your uSD card(s) ? 21.29.23 # yes, but I don't have a v1 card and that would be all that it would affect... 21.29.34 # * JdGordon| once again complains about our stupid policy of abosultly no customzability in the buttons and menus 21.29.43 # FlynDice: afaik the internal storage is v1 21.29.49 Quit jfc (simmons.freenode.net irc.freenode.net) 21.29.49 NSplit simmons.freenode.net irc.freenode.net 21.29.49 Quit Ubuntuxer (simmons.freenode.net irc.freenode.net) 21.29.49 Quit at0m (simmons.freenode.net irc.freenode.net) 21.29.49 Quit yosafbridge (simmons.freenode.net irc.freenode.net) 21.29.49 Quit karma (simmons.freenode.net irc.freenode.net) 21.29.49 Quit sitwon (simmons.freenode.net irc.freenode.net) 21.29.52 NHeal simmons.freenode.net irc.freenode.net 21.29.52 NJoin karma [0] (i=amg@host193-123-47-78-dhcp.bshellz.net) 21.29.55 NJoin at0m [0] (n=at0m@94-225-90-23.access.telenet.be) 21.30.04 NJoin sitwon [0] (n=adam@pool-173-79-65-210.washdc.fios.verizon.net) 21.30.06 NJoin jfc [0] (n=john@dpc6682208002.direcpc.com) 21.30.07 NJoin yosafbridge [0] (n=yosafbri@ludios.net) 21.30.29 NJoin Ubuntuxer [0] (n=johannes@dslb-094-221-080-104.pools.arcor-ip.net) 21.30.34 # gevaerts: the D2 with SD support must be at least copper by now ;-) 21.31.08 # funman: the internal storage worked fine... but maybe that's why voltage scaling was borking the uSd cards, they were using lower voltage... 21.31.55 # shotofadds: I'd say silver :) 21.31.55 # while the internal was still using 3.5-3.6 21.32.16 # what about http://pastie.org/545879 ? 21.32.36 # gevaerts: we "just" need to get multi-driver in SVN first... 21.32.53 # indeed... 21.33.47 # funman: Is that the same patch I asked you to look at yesterday? 21.33.48 # speaking of which, could you give fs#10415 a quick once-over for sanity? I'm not entirely sure which drive number to use for things like fat_mount() during hotswap... 21.34.01 Join Sajber^1 [0] (n=Sajber@81-235-177-115-no54.tbcn.telia.com) 21.34.04 # ^that was @gevaerts 21.34.18 # FlynDice: possibly ;) 21.35.44 # yours have more comments though ;) 21.35.44 # funman: That patch works fine for me but I didn't try it with voltage scaling yet. I gotta head off to work now but i'll try experimenting with this info later. 21.36.52 # shotofadds: that sounds like tricky question... 21.36.52 # yes, I need them to keep my place, happens when you get older... they say it's the second thing to go;) 21.37.27 # gevaerts: the current behaviour appears to work flawlessly, but I'm not sure that's by design or by fluke 21.37.40 # * gevaerts hasn't touched multidriver for too long, so he doesn't know for sure 21.38.17 # FlynDice: comments can only make good 21.38.58 # shotofadds: SD as the main drive will also be fun for rbutil, since it sounds perfectly reasonable to install or update a build with a card reader :) 21.40.19 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 21.41.00 # amiconn that's not what i was asking for... i know the battery level changes constantly in the sim, but i want to simulate a charger being plugged in, so i can see if my %bp tag works right 21.41.23 # gevaerts: I like to present as many options as possible ;-) 21.41.35 # also it will be possible to still boot from NAND if there's no SD present 21.42.45 # shotofadds: I suspect the multidriver work misses something : the storage system asks the drivers how many drives they have, but it should also tell them what the drive numbers will be 21.43.55 # yes, I figured there might be a step missing and the current behaviour is "by chance". i'm not sure how that might work, though. 21.44.06 # is it really the plan to run rockbox off the SD for the long term? 21.44.23 # it's not as crazy as you might think 21.44.45 # and it depends what you call "long term"... until someone writes a read/write driver for the TCC FTL, yes. 21.46.04 Join steven [0] (n=steven@c-67-162-212-232.hsd1.mi.comcast.net) 21.46.07 # shotofadds: no it's not crazy, I booted off the microsd on my fuze also (though, just for the fun of it mainly) 21.46.13 Quit Ubuntuxer ("Leaving.") 21.46.18 # is there an easy way for me to get my album covers on rockbox? 21.46.46 # I can't see any alternative way of providing persistent settings 21.47.07 Quit robin0800 ("I didn't set up UberScript properly!") 21.47.11 # steven: It depends how they are currently stored. Are they part of the tags or in separate image files? 21.47.25 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 21.47.52 # evilnick: more than likely stored in a local folder where rythmbox puts them 21.48.09 # shotofadds: if we make *num_drives accept an parameter (e.g. int sd_num_drives(int first_drive)), and storage_init() passes num_drives to all drivers, it should work I think 21.48.39 Quit robin0800 (Client Quit) 21.48.58 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 21.49.08 # gevaerts: that sounds logical, yes. 21.49.23 # steven: If they're in separate files then copy them to the same folder as the music on the target and name them "folder.jpg" - that does assume that your music on the player is in a suitable folder structure. What player do you have? 21.49.31 # saratoga, funman: alright, he's sending it to me. Should take a month or so to arrive 21.49.49 # steven: For more info: http://www.rockbox.org/twiki/bin/view/Main/AlbumArt 21.51.49 # evilnick: ipod 5.5 21.53.10 Quit robin0800 (Client Quit) 21.53.28 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 21.53.34 Join Sajber^2 [0] (n=Sajber@81-235-177-115-no54.tbcn.telia.com) 21.53.42 # steven: Do you still use the OF for listening to music? If so, then that may cause some issues, as the OF obfuscates the filenames/folder names 21.53.55 # nope 21.54.00 Join Windlord [0] (n=Windlord@cm149.sigma105.maxonline.com.sg) 21.54.07 # I just copied the music folder with proper structering over 21.54.19 Part Windlord 21.54.20 # In that case, you should be fine with that Wiki page 21.54.23 # ie ; /The Beatles/Help!/Song.mp3 21.54.50 # do I have to copy each picture for each album manually evilnick ? 21.56.02 # steven: There are a few options. I like to keep the same folder structure on my computer so that I can copy over each "folder.jpg" file and be sure that they appear in the correct folder. 21.56.11 # (using a sync tool) 21.56.46 # why use a sync tool when the file manager can just skip duplicates if the folder structure is set up right? 21.57.56 # Because I keep .flac at home, but transcode to a lossy format for a portable player. Therefore I only want to copy the "folder.jpg" files 21.58.06 # ah I see 21.58.25 Quit Sajber^ (Success) 21.59.23 Join Sajber^ [0] (n=Sajber@81-235-177-115-no54.tbcn.telia.com) 21.59.53 Quit WPS ("CGI:IRC (EOF)") 22.00.02 Quit LambdaCalculus37 () 22.00.05 Join Windlord [0] (n=Windlord@cm149.sigma105.maxonline.com.sg) 22.00.14 # steven, I keep master copy on computer and add or subtract change tags and add replay gain then use a sync program to match this to the player 22.01.00 # quick question: Is there any channel where I can get help regarding the creation of flash skins for the cowon d2? 22.01.08 # sorry I couldn't find any and had to ask here 22.01.27 # Windlord: not that I know of. your best bet is the forum at iAudiophile.net 22.01.46 # thank you 22.02.39 # funman: One last question before I head out, do you think internal sd card is v1 because we need bank switching? 22.03.01 # FlynDice: perhaps it was cheaper to produce than sdhc cards 22.03.57 # they probably didn't even produce, but just emptying the stocks 22.03.58 # funman: but do you _know_ it is somehow or have you deduced this info? 22.04.29 # New commit by 03rob (r21869): Guard the Timeout API declarations with the correct #ifdef 22.04.44 # just deduced, i have no informations from SanDisk 22.05.17 # kugel: that makes sense, gotta go "drive the bus"... 22.05.32 Quit FlynDice (Remote closed the connection) 22.10.23 Join Sajber^3 [0] (n=Sajber@81-235-177-115-no54.tbcn.telia.com) 22.10.23 *** Alert Mode level 1 22.10.23 DBUG Sent KICK Sajber^1 to server 22.10.23 DBUG Sent KICK Sajber^2 to server 22.10.23 *** Alert Mode level 2 22.10.23 DBUG sent MODE #rockbox +b *!*n=Sajber@*.tbcn.telia.com 22.10.23 DBUG Sent KICK Sajber^ to server 22.10.23 DBUG Enqueued KICK Sajber^3 22.10.23 *** Alert Mode level 3 22.10.23 Kick (#rockbox Sajber^1 :*bang* too many joined users) by logbot!n=bjst@rockbox/bot/logbot 22.10.23 *** Alert Mode level 4 22.10.23 DBUG Q-Sent KICK Sajber^3 to server 22.10.23 Kick (#rockbox Sajber^2 :*bang* too many joined users) by logbot!n=bjst@rockbox/bot/logbot 22.10.23 *** Alert Mode level 5 22.10.23 Mode "#rockbox +b *!*n=Sajber@*.tbcn.telia.com " by logbot (n=bjst@rockbox/bot/logbot) 22.10.23 Kick (#rockbox Sajber^ :*bang* too many joined users) by logbot!n=bjst@rockbox/bot/logbot 22.10.23 *** Alert Mode level 6 22.10.24 Kick (#rockbox Sajber^3 :*bang* too many joined users) by logbot!n=bjst@rockbox/bot/logbot 22.10.24 *** Alert Mode level 7 22.13.48 # kugel: http://forums.rockbox.org/index.php?topic=22137.msg153226#msg153226 22.14.36 # funman: That was the one I meant with "the microsd one" 22.14.49 Quit webguest38 ("CGI:IRC") 22.16.27 # I believe in ku-ku, it's some sort hardware problem. Not that the hardware is broken, but that it operates at the very border (or even out of) the sd specs 22.16.51 # high-speed class 6 sounds already suspicious, although I'm not familiar with these cards in general 22.17.54 # I wonder if it would helpful to log what his cards responds to our commands 22.20.16 # How can we know the "class" of µSD cards by software ? 22.20.23 Join AndyI [0] (i=AndyI@212.14.205.32) 22.20.25 *** Alert Mode OFF 22.23.53 # funman, isn't it in the CSD (at least for v2 SD cards)? 22.25.20 # the CCC (Card Command Classes) ? The spec shows a fixed value for it 22.25.48 # it only defines which subsets of commands are available, not speed 22.28.01 # TRAN_SPEED (max. data transfer rate) only has 2 possible values (25Mbit/s and 50Mbit/s) 22.28.16 # amiconn, the codec in the iriver Hxxx (the uda1380) can also handle other sampling rates, like 12, 24, 48 kHz 22.28.30 # it is only 50Mbit/s for High-Speed 22.28.46 # Yes, but only if the necessary clock signal is available 22.28.48 # I don't have highspeed I think 22.29.09 # I ran into this when trying to re-use the uda1380 codec driver for the meizus 22.30.16 # the meizus have a separate clock signal going to the codec (MCLK), so you don't have to use the PLL in the codec to reconstruct it 22.30.22 # All our coldfire targets can only clock the i2s bus for multiples or fractions of 44.1kHz 22.30.28 # are we sure the irivers don't have this too? 22.30.46 # Yes, MCLK is locked to the xtal 22.31.19 # hm, as far as I understood, it's locked to the LRCK signal, not to a crystal 22.32.39 Quit AndyIL (Read error: 110 (Connection timed out)) 22.34.50 Join _lifeless [0] (n=lifeless@188.16.125.117) 22.34.55 Quit _lifeless (Read error: 54 (Connection reset by peer)) 22.35.26 Nick karma is now known as punyhumanright (i=amg@host193-123-47-78-dhcp.bshellz.net) 22.35.51 # amiconn, I'll have a another closer look at the uda1380 driver and the datasheet with that in mind 22.35.55 Join AndyIL [0] (i=AndyI@212.14.205.32) 22.37.01 # funman: should I worry if I get "SD bank error" once in a while (randomly and not reproducable)? 22.37.28 # JdGordon|: btw, what was the reason to not use home to go to the wps in menus/filetree? 22.37.38 # kugel: yes, did you get the status printed? 22.37.50 # kugel: home goes to menu 22.38.02 # funman: 0x10 22.38.07 # kugel: and the bank number? 22.38.08 # seen as that *is* the home 22.38.08 # bertrik: On an i2s bus, one of the devices needs to be the clock master. In theory both the codec and the cpu can be clock master, but in the coldfire targets the codec doesn't have its own clock source, so the cpu needs to be i2s clock master 22.38.25 # kugel: do you have a 4GB Fuze? 22.38.28 # JdGordon|: IIUC it could go to the main menu from the wps, and to the wps from trees 22.38.48 # home+select is wps everywhere 22.38.55 # funman: no. although I just did get the message on my clip 22.39.31 # isn't there only 1 "goto wps" action? 22.39.36 # And the MCLK is locked to the xtal, just offering a few discrete dividers 22.39.49 # amiconn, I think it's the same on the meizus, where the CPU sends the i2s bit clock AND a separate MCLK 22.40.03 # kugel: which capacity is your clip ? 22.40.05 # amiconn, so the MCLK is always the same frequency? 22.40.12 # (on the irivers I mean) 22.40.18 # 2GB, like my fuze 22.40.33 # So you can either build a coldfire target that handles 11.025/22.05/44.1/88.2kHz *or* one that handles 8/12/16/24/32/48/64/96kHz 22.40.37 # kugel: so you got this message at startup, or while operating? 22.40.56 # JdGordon|: as far as I see it, what I'm thinking should be doable (that's how the OF behaves too) 22.41.01 # Changing between these groups would require changing the main xtal 22.41.03 # at startup 22.41.32 # I wouldn't trust my clip if I didn't have it once on my fuze also 22.41.34 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 22.41.34 # * shotofadds managed to get red on the new build servers only ... looks like the ipodcolor build took place in a 'dirty' build folder. 22.41.43 # bertrik: Not the same, but derived from the same base clock just by simple dividers. No PLL for that 22.42.08 # kugel: it could do it, of course, but thats not good... the menu is a much more important quick goto screen than the WPS.. 22.43.16 # * gevaerts investigates 22.43.23 # Zagor: "1247605338 cpu seconds" ?? 22.43.29 # oh dear, my clip is so broken, it plays completely wrong radio stations 22.43.40 # amiconn, the meizu generates the MCLK simply by dividing from the 200 MHz main clock, so it's never exact (but very close) 22.43.52 # amiconn: hehe 22.44.04 # JdGordon|: really? I'm thinking the opposite is true :) 22.44.09 # Zagor: I have some left over build directories for the last few days 22.44.16 # that doesnt surprise me... you're wrong! 22.44.19 # the I2S bit clock is a divided from the MCLK clock and the LRCK is divided from the bit clock again (/32) 22.44.26 # JdGordon|: you apparently also failed to adapt the radio screen :p 22.44.31 Join B4gder [241] (n=daniel@rockbox/developer/bagder) 22.44.34 # Maybe also rm -rf a new build directory in case it was still there? 22.47.00 # Zagor: is there any thoughts about having the client say its slow instead of having the server tell the client which group its in? 22.47.11 # my laptop should not be in the fast group 22.47.34 # * kugel doesn't think that's a good idea 22.47.40 # JdGordon|: no, the idea is that the server decides based on past performance 22.47.45 # slow has to be a relative thing 22.47.46 # amiconn, what approximate frequency is the MCLK on the coldfire targets? 22.47.57 # a) the border is hard to tell, b) the border is likely going to move 22.48.16 # as far as I understood the default on the s5l8700 is 256 times the sample frequency 22.48.25 # JdGordon|: you are right on the edge. a few more builds and you'll drop down to the slow category again. 22.48.36 # ok 22.49.12 # some clients will likely be moving between the categories 22.50.28 # 11.289 MHz for 44.1 kHz audio playback for example 22.50.37 Join fyrestorm [0] (n=nnscript@cpe-24-90-84-236.nyc.res.rr.com) 22.50.58 # gevaerts: yeah the killing has been a bit buggy lately, leaving leftover dirs 22.51.39 # I suspect that it's the cause for this ipod color red. It's not a very likely occurence (1 in 5000 or so?), but I don't see any other explanation 22.52.54 Join agaffney_ [0] (n=agaffney@gentoo/developer/agaffney) 22.53.13 Quit agaffney (Read error: 60 (Operation timed out)) 22.53.13 # wow 22.53.22 Quit r0b- ("( www.nnscript.de :: NoNameScript 4.02 :: www.XLhost.de )") 22.53.47 Quit AndyI (Connection timed out) 22.54.32 # funman: arg, again 22.54.58 # sd bank -1 error: 0x2 22.55.16 # -1 means at startup 22.55.25 # 0x2 is datacrcfail 22.55.33 # startup as in boot or sd_enable? 22.55.36 # 0x10 is txunderrun .. ? 22.55.42 # that certainly wasn't at boot 22.55.42 Quit Thundercloud (Remote closed the connection) 22.56.19 # kugel: that's the only call path to sd_select_bank(-1) 22.56.20 # funman: but really wouldn't give too much to what my clip does. I'll report on my rock solid fuze rather 22.56.32 # it wasn't at boot, believe me or not 22.56.34 # oh right you mentioned your clip is broken 22.56.46 # kugel: i believe you 22.57.04 # do you believe me as well ? 22.57.37 # it seems mutually exclusive :) 22.57.45 *** Saving seen data "./dancer.seen" 22.59.40 # bertrik: The coldfire base clock is 11.2896MHz, MCLK is half of that iirc 23.00.01 # funman, you have my Clip v1 until the end of time. 23.00.10 # * amiconn might have found an unnecessary colplexity in the coldfire pcm driver 23.00.16 # *complexity 23.00.27 # of should I say "You have your Clip v1" 23.00.41 # soap: thanks! 23.02.22 # Unhelpful: Did you see my remarks regarding asm offset generation on the various architectures? 23.02.23 # amiconn, looking at the uda1380 code, it does seem to enable an internal PLL to reconstruct the clock signal rather than use an external clock 23.02.50 # it sets bit DAC_CLK in register 0 to enable the "WSPLL" 23.02.55 # And what would that help us? 23.03.16 # amiconn: yes, i "sort of" fixed it, in that it will unconditionally accept either _AD_ or AD_ as the symbol prefix, and .word or .long for the data. i don't think that ought to be a problem. 23.03.29 # It only helps for supporting different sample rates if we can feed it an *external* clock, i.e. not generated by the cpu 23.03.41 Quit steven (Remote closed the connection) 23.04.29 # In fact it does help this way - the irivers and iaudios can only play back 11/22/44/88kHz and record the same sample rates (except 88 for the UDA) from analog inputs, but the H1x0 is able to record all standard sample rates from s/pdif 23.04.45 # i think the small ambiguity should be OK, provided devs don't decide they want to name symbols _AD_ or use a different type and expect them hidden 23.05.56 # I think we should strife to use direct clocks instead of reconstructing them, unless not possible in another way of course 23.06.17 # You cannot reconstruct a clock that isn't there in some way 23.06.19 # s/pdif sample rates include 44.1 etc? 23.06.45 # I don't understand what you mean to say 23.07.11 # The iaudios support all standard rates from 8 to 96kHz for s/pdif *input*. S/pdif output is limited the same way as analog input and output 23.07.40 # The only exception is loop-through monitoring during s/pdif recording 23.08.20 # This does just output the same s/pdif signal present on the input, without any processing. The analog monitor sounds a bit funny in this case 23.09.07 # We can get the card class from the status register (sent on the data line after SD_SEND_STATUS command) 23.11.15 # Unhelpful: I'll check what gcc spits out for 'char', 'short' and 'long long' 23.12.47 # amiconn: do we really care? if we tell people to use "int", that's good enough, i'd think. the value is the point, and i doubt there's much need for >32-bit asmdef values, especially as pretty much nothing can use them as immediates. 23.13.22 # Just curiosity 23.13.59 Quit dash32 (Read error: 110 (Connection timed out)) 23.14.08 Join r0b- [0] (n=rob@adsl-76-235-217-188.dsl.klmzmi.sbcglobal.net) 23.15.55 # the current uda1380 code seems to use the MCLK only for recording, it uses the WSPLL for playback 23.16.19 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 23.18.08 # funman: playing music for 30min w/o problems on my clip now 23.21.30 # Unhelpful: All use 'byte' for char. There is potential confusion if you match both .word and .long, as coldfire uses 'word' for short. 23.22.07 # long long ends up as 2*.word or 2*.long depending on architecture 23.24.24 # New commit by 03zagor (r21870): Analyze log and store errors and warnings in the db. 23.24.46 # amiconn: i think this is mostly handled if we say "don't use AD_* names if you don't want it exported, don't use _AD* at all" 23.25.10 # B4gder: will you be running the RSB vote again this year? 23.25.18 # And don't use anything else than 'int' or 'long' 23.25.47 # right, which is what the existing asmdefs file says to use, anyway 23.26.31 # gevaerts: I guess I can, I'm just a little "off" during this week and the next, while I'm vacationing away from home 23.26.39 # New commit by 03zagor (r21871): Only build non-existing pics. 23.28.26 # B4gder: Anyone can do it of course, but there's a lot of confidentiality involved, so I guess it should be you, Linus or Zagor 23.30.53 # New commit by 03zagor (r21872): Now grabs all data from database for much faster execution. 23.30.58 Quit evilnick_home1 (Read error: 113 (No route to host)) 23.32.45 # New commit by 03zagor (r21873): Integrated head+tail printout. 23.34.30 Join CaptainKwel [0] (i=2669ecc2@gateway/web/freenode/x-785634cece0ec72e) 23.35.50 # rebuilding again now, but i'm pretty confident that stubs alone, or some other effect of passing the -meabi=4 flag to the assembler, is sufficient to break vorbis. 23.35.56 # New commit by 03zagor (r21874): Check each build log on completion. 23.37.11 # New commit by 03zagor (r21875): clientstats.pl now does its' own head+tail printout. Added mktitlepics.pl 23.39.29 Quit scorche (" rawr...that is all...rawr") 23.39.31 Quit Lynx_ (" HydraIRC -> http://www.hydrairc.com <- Go on, try it!") 23.40.14 # Unhelpful: Is that a true eabi build, or just trciking the assembler? I would expect the latter to cause problems 23.41.16 Join safetydan [0] (n=deverton@rockbox/developer/safetydan) 23.41.42 # amiconn: it doesn't cause any *other* problems that i can find. the only thing that *should* be changing in the object files is the headers, and the relocation types 23.43.52 # i've saved .elfs of both and i'm comparing... so far only addresses are different. 23.46.10 # It probably just exposes a hidden bug 23.48.11 Join MrDuck [0] (n=kachna@r4ax178.net.upc.cz) 23.52.25 # New commit by 03unhelpful (r21876): Small fix for asmdefs, make sure $var is cleared the line after it is read, so that value *must* follow label immediately. 23.54.49 Join mirak [0] (n=mirak@85-169-192-191.rev.numericable.fr) 23.55.43 Join Stephen_ [0] (n=S@86-45-97-240-dynamic.b-ras2.srl.dublin.eircom.net)