--- Log for 23.03.112 Server: leguin.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 2 days and 23 hours ago 00.06.26 # on those that have them, does Rockbox have any support for DSP? If not, is the design of RB conducive to adding support? 00.07.07 Quit LambdaCalculus37 (Quit: This computer has gone to sleep) 00.08.10 # diginet: could you be more specific? 00.08.56 # well, for example some of the SoCS used in various players have DSPs, like TMS320 and DSP56k, does Rockbox have any support for utilizing those? 00.09.26 # and if not, is there a non-hackish way to add support? (not asking for someone to do it, just curious) 00.09.59 # The way I understand it, one major problem with hardware DSP is compiler support 00.10.12 # diginet: we use DSP in TMS320 in some way. Don't know the details though 00.11.06 # As far as I know we only use DSPs if things like audio or video are wired through them so we have no choice 00.11.37 Quit lebellium (Quit: ChatZilla 0.9.88.1 [Firefox 12.0/20120314195616]) 00.12.59 # yeah, free compiler are main blockers anyway 00.14.28 # generally speaking, rockbox doesn't need to "support" a DSP 00.14.37 # if you can program it, you can run whatever you want on it 00.14.46 # regardless of what we support 00.15.25 # a programmable DSP is just a CPU, so you can do whatever you want on it 00.17.22 # Heh, a2a dma engine on rk27xx is sooo inefficient. That partially explains poor sd performance. With dumb 4x ldr + stmia I get over 4 times better throughput for aligned access. 00.22.49 Quit Scromple (Ping timeout: 246 seconds) 00.22.56 Join Scromple [0] (~Simon@119.225.209.134) 00.23.20 # have you tried a battery bench with the new memory timings? 00.23.56 # saratoga: I have desoldered battery. 00.24.00 # ha 00.24.18 # but test_mem shows only tiny difference anyway 00.26.52 Join Llorean1 [0] (~DarkkOne@99-32-78-58.lightspeed.hstntx.sbcglobal.net) 00.26.52 Quit leavittx_ (Remote host closed the connection) 00.28.26 Quit Llorean (Ping timeout: 260 seconds) 00.31.37 Quit wodz (Quit: Leaving) 00.32.55 *** Saving seen data "./dancer.seen" 00.36.55 Join Llorean [0] (~DarkkOne@99-32-78-58.lightspeed.hstntx.sbcglobal.net) 00.37.31 Quit Llorean1 (Ping timeout: 246 seconds) 00.44.52 Quit bertrik (Ping timeout: 246 seconds) 00.46.33 Join factor [0] (~factor@74.195.96.67) 00.47.29 Quit TomColler (Remote host closed the connection) 01.04.32 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 01.04.32 Quit bertrik (Changing host) 01.04.32 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 01.04.36 Quit z180 (Ping timeout: 260 seconds) 01.05.31 Quit bertrik (Client Quit) 01.07.20 Quit Llorean (Changing host) 01.07.20 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 01.33.21 Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) 01.36.01 Join bitcraft_ [0] (~bitcraft@66.254.199.148) 01.36.01 Quit bitcraft (Read error: Connection reset by peer) 01.36.01 Quit bitcraft_ (Remote host closed the connection) 01.36.26 Join bitcraft [0] (~bitcraft@66.254.199.148) 01.48.13 Quit prof_wolfff (Ping timeout: 246 seconds) 02.31.57 Join [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940) 02.32.59 *** Saving seen data "./dancer.seen" 02.36.39 Join TBCOOL [0] (~tb@c-a43571d5.09-42-73746f22.cust.bredbandsbolaget.se) 02.48.46 Quit enthdegree (Ping timeout: 245 seconds) 02.54.11 Join [Saint__] [0] (~Saint]@unaffiliated/saint/x-8516940) 02.57.46 Quit [Saint_] (Ping timeout: 260 seconds) 02.59.41 Quit [Saint__] (Remote host closed the connection) 02.59.45 Quit Thra11 (Remote host closed the connection) 03.01.58 Join enthdegree [0] (~BitchX@unaffiliated/enthdegree) 03.11.34 Quit MethoS- (Ping timeout: 265 seconds) 03.33.13 Join bitcraft_ [0] (~bitcraft@66.254.199.148) 03.33.18 Quit bitcraft_ (Remote host closed the connection) 03.33.20 Quit bitcraft (Read error: Connection reset by peer) 03.33.43 Join bitcraft [0] (~bitcraft@66.254.199.148) 04.18.27 Join chattr [0] (~mike@97.100.207.201) 04.18.39 Part chattr ("gone") 04.22.29 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.22.30 Quit amiconn (Disconnected by services) 04.22.51 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.22.57 Quit TheSeven (Disconnected by services) 04.23.02 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 04.23.20 Quit pixelma (Disconnected by services) 04.23.22 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.23.24 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.26.09 Join LambdaCalculus37 [0] (~rmenes@c-68-32-226-242.hsd1.nj.comcast.net) 04.26.09 Quit LambdaCalculus37 (Changing host) 04.26.09 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) 04.33.00 *** Saving seen data "./dancer.seen" 05.00.12 Quit anewuser () 05.02.50 Join Rasdere [0] (724d6a5a@gateway/web/freenode/ip.114.77.106.90) 05.04.55 # Hey guys, I've recently installed Rockbox on a 2GB clip+ and put a 32GB SDHC card in it; how do I access the SDHC card via usb? 05.07.46 Quit LambdaCalculus37 (Quit: Fwump) 05.29.53 Join bitcraft_ [0] (~bitcraft@66.254.199.148) 05.29.53 Quit bitcraft (Read error: Connection reset by peer) 05.34.58 Quit ps-auxw (Ping timeout: 260 seconds) 05.41.51 Join ps-auxw [0] (~arneb@p4FF7FCDD.dip.t-dialin.net) 05.43.24 Quit curtism (Quit: Live Long and Prosper) 05.45.10 Join curtism [0] (~curtis@unaffiliated/programble) 05.47.12 Quit enthdegree (Read error: Connection reset by peer) 05.49.07 Quit curtism (Client Quit) 05.52.12 Join Rob2222 [0] (~Miranda@p4FFD38A6.dip.t-dialin.net) 05.53.03 Join curtism [0] (~curtis@bas11-montreal02-1128531121.dsl.bell.ca) 05.53.04 Quit curtism (Changing host) 05.53.04 Join curtism [0] (~curtis@unaffiliated/programble) 05.56.13 Quit Rob2223 (Ping timeout: 246 seconds) 05.56.52 Quit ps-auxw (Quit: leaving) 05.57.56 Join ps-auxw [0] (~arneb@p4FF7FCDD.dip.t-dialin.net) 05.58.13 Quit curtism (Quit: Live Long and Prosper) 06.01.32 Join curtism [0] (~curtis@bas11-montreal02-1128531121.dsl.bell.ca) 06.01.33 Quit curtism (Changing host) 06.01.33 Join curtism [0] (~curtis@unaffiliated/programble) 06.03.25 Join Keripo [0] (~Keripo@eng419.wireless-resnet.upenn.edu) 06.04.54 Quit nosa-j (Read error: Connection reset by peer) 06.05.41 Join nosa-j [0] (~m00k@adsl-74-235-79-36.clt.bellsouth.net) 06.06.46 Quit curtism (Quit: Live Long and Prosper) 06.07.56 Quit nosa-j (Excess Flood) 06.11.05 Join nosa-j [0] (~m00k@adsl-74-235-79-36.clt.bellsouth.net) 06.16.38 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 06.21.14 Quit bitcraft_ (Remote host closed the connection) 06.23.13 Join curtism [0] (~curtis@bas11-montreal02-1128531121.dsl.bell.ca) 06.23.14 Quit curtism (Changing host) 06.23.14 Join curtism [0] (~curtis@unaffiliated/programble) 06.25.10 Quit curtism (Client Quit) 06.25.38 Join curtism [0] (~curtis@bas11-montreal02-1128531121.dsl.bell.ca) 06.25.38 Quit curtism (Changing host) 06.25.38 Join curtism [0] (~curtis@unaffiliated/programble) 06.29.55 Quit curtism (Client Quit) 06.30.24 Join curtism [0] (~curtis@bas11-montreal02-1128531121.dsl.bell.ca) 06.30.24 Quit curtism (Changing host) 06.30.24 Join curtism [0] (~curtis@unaffiliated/programble) 06.33.01 *** Saving seen data "./dancer.seen" 06.39.56 Quit curtism (Quit: Live Long and Prosper) 06.45.50 Join curtism [0] (~curtis@bas11-montreal02-1128531121.dsl.bell.ca) 06.45.51 Quit curtism (Changing host) 06.45.51 Join curtism [0] (~curtis@unaffiliated/programble) 07.07.39 Quit Rower85 (Read error: Connection reset by peer) 07.12.07 Join PaulJam [0] (~Paule@p54BEAA31.dip.t-dialin.net) 07.25.54 Quit PaulJam (Ping timeout: 264 seconds) 07.36.15 Quit nosa-j (Excess Flood) 07.37.34 Join nosa-j [0] (~m00k@adsl-74-235-79-36.clt.bellsouth.net) 07.40.25 # Rasdere: use a current build 07.46.39 # I'm using 3.10, from what I can tell, that is the newest build 07.55.47 Join mortalis [0] (~mortalis@77.108.98.176) 07.58.38 # nope, current. not last stable 08.21.30 Join bitcraft [0] (~bitcraft@66.254.199.148) 08.25.59 Quit bitcraft (Ping timeout: 245 seconds) 08.31.08 Quit Scromple (Quit: Leaving) 08.33.03 *** Saving seen data "./dancer.seen" 08.47.08 Join XavierGr [0] (~xavier@rockbox/staff/XavierGr) 08.47.33 Join ender` [0] (~ender@foo.eternallybored.org) 09.04.37 Join LinusN [0] (~linus@giant.haxx.se) 09.20.26 Quit AlexP (Ping timeout: 246 seconds) 09.25.22 Join AlexP [0] (~alex@rockbox/staff/AlexP) 09.28.48 Quit [Saint] (Quit: Quit) 09.29.09 Join [Saint] [0] (~Saint]@101.98.158.103) 09.29.10 Quit [Saint] (Changing host) 09.29.10 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 09.51.34 Part LinusN 09.54.45 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 09.59.04 Join LinusN [0] (~linus@giant.haxx.se) 10.06.34 Quit kadoban (Ping timeout: 260 seconds) 10.07.26 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 10.15.18 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 10.16.45 Join davo [0] (~davo@adsl-68-120-231-13.dsl.irvnca.pacbell.net) 10.18.49 # tried googling and searching the rockbox forums, but only found info for making plugins, when trying to build the simulator, i'm make gives me: 'rockbox/build-dir/apps/bitmaps/native/rockboxlogo.220x68x16.o: could not read symbols: File in wrong format' collect2: ld returned 1 exit status 10.24.49 Join swilde [0] (~wilde@aktaia.intevation.org) 10.24.56 # davo: never saw such error 10.25.01 # ok 10.25.25 # i'm finding some stuff on other opensource software build logs, maybe it'll help 10.26.31 # hi *, IIRC it is possible to have more than one version of rockbox installed on a device in different directories. How does one boot one of the non default installations? 10.27.49 # swilde: you can rolo() 10.28.18 # swilde: I mean while in rockbox select in filebrowser firmware file 10.28.36 # wodz: Ah, thank you! 10.28.40 # the resource will be used from .rockbox always though 10.28.49 # *resources 10.28.51 # it seems it might have something to do with the 'export ARCH=unknown' in the Makefile, if the compiler doesn't know what arch my machine is :\ 10.29.07 # wodz: Good to know... 10.29.10 Quit [Saint] (Read error: Connection reset by peer) 10.33.04 *** Saving seen data "./dancer.seen" 10.50.54 Join lebellium [0] (~chatzilla@g231205093.adsl.alicedsl.de) 10.52.24 # mortalis: ping 10.52.34 # pong 10.53.07 # mortalis: I think I found the reason of slow sd transfers (at least one of the reason) 10.53.19 # mortalis: a2a dma engine is dead slow 10.53.59 # mortalis: dumb 4x ldr + stmia gives ~4 times performance boost for aligned access. 10.54.45 # at least on my DAP 10.55.06 # cool 10.56.54 # found out what the problem with building the simulator was, the Makefile just needed the location of arm-elf-eabi-gcc 10.56.58 # all works now 10.57.04 # thanks btw 10.57.20 # davo: you should have it in your PATH don't you :-) 10.57.42 Quit factor (Read error: Connection reset by peer) 10.58.21 # wodz: what is used in OF for sd transfers? 10.58.23 # no, i think rockbox.sh manually installed it, but it never got added to my PATH 10.58.31 # but good point, it should be there :) 10.59.17 # davo: that's definitely not it. You don't need arm-elf-eabi-gcc for the simulator 10.59.56 # That error looks like you tried to use a directory for building a simulator that had a non-sim build in it without cleaning first though 11.00.24 # well i dunno what else it could be, without it in the Makefile i was getting that build error 11.00.26 # mortalis: simple loop but I didn't checked if ms compiler do something smart with it. 11.01.01 # but i just watned to state for the record that i resolved it in case anyone had seen my post 11.01.32 # what do you think guys, should the FMS display the current preset name even in scan mode? 11.03.28 # davo, our dev script gives you a message after successful install that you should add it to your PATH 11.04.19 # ah, then that was clearly my mistake not to notice that message 11.04.28 # my bad, and thanks for pointing that out 11.05.40 Quit nosa-j (Read error: Connection reset by peer) 11.07.34 Join nosa-j [0] (~m00k@adsl-74-235-79-36.clt.bellsouth.net) 11.09.31 Quit Torne (Ping timeout: 252 seconds) 11.15.41 Join factor [0] (~factor@74.195.96.67) 11.26.07 Join Torne [0] (~torne@rockbox/developer/Torne) 11.44.08 Join [Saint] [0] (~Saint]@101.98.158.103) 11.44.08 Quit [Saint] (Changing host) 11.44.08 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 11.47.35 Join TomColler [0] (~thomas@net-93-144-140-116.cust.dsl.teletu.it) 12.25.06 Join anewuser [0] (~anewuser@186.93.168.102) 12.25.06 Quit anewuser (Changing host) 12.25.06 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 12.33.07 *** Saving seen data "./dancer.seen" 12.35.24 Join Topy44 [0] (~Topy44@f049141103.adsl.alicedsl.de) 12.37.50 Quit Topy (Ping timeout: 246 seconds) 12.41.35 Join Llorean1 [0] (~DarkkOne@99-32-78-58.lightspeed.hstntx.sbcglobal.net) 12.44.38 Quit Llorean (Ping timeout: 244 seconds) 12.49.49 Join T44 [0] (~Topy44@f049141103.adsl.alicedsl.de) 12.51.00 Quit Topy44 (Read error: Connection reset by peer) 12.51.48 # Torne: Could you take a look if http://www.pastie.org/3653943 looks correct? This snippets are going to transfer one sector of data from fixed sd module address to the memory. 12.56.15 Quit T44 (Ping timeout: 276 seconds) 12.56.46 Join Topy44 [0] (~Topy44@f049045071.adsl.alicedsl.de) 12.58.31 # er 12.58.41 # not entirely sure what that's intended to be 12.58.49 # a fixed-source memcpy? 13.01.01 # yes 13.02.08 # and you want to support efficient writes to unaligned destination buffers 13.02.30 # yes 13.05.23 # i'd honestly suggest not bothering 13.05.30 # :) 13.05.36 # and just aligning all the targets 13.06.22 # if you're always reading a sector then requiring word alignment is not exactly onerous 13.07.27 # how is alignment handled in our storage system then? 13.07.45 # badly, generally 13.07.57 # :) 13.08.13 # i would strongly support removing support for non-word-aligned storage accesses in *all* the storage drivers 13.08.19 # and fixing all the code that breaks :) 13.08.32 # eek, go for it :-) 13.08.55 # in fact, in general we want cache line aligned storage buffers where feasible 13.09.03 # so that DMA is easier 13.09.28 # anyway, i don't desperately want to sit down and poke at your asm right now to validate it 13.09.39 # ok no problem 13.09.39 # especially since i'm supposedly at work :) 13.09.49 # if you think it's worth having i may look at it later 13.09.55 # but i would generally vote that it's not :p 13.09.57 # sorry :p 13.35.35 Quit nosa-j (Excess Flood) 13.36.34 Join nosa-j [0] (~m00k@adsl-74-235-79-36.clt.bellsouth.net) 13.57.13 Quit nosa-j (Ping timeout: 260 seconds) 13.57.34 Join PaulJam [0] (~Paule@p54BEB36A.dip.t-dialin.net) 13.59.04 Join nosa-j [0] (~m00k@adsl-74-235-79-36.clt.bellsouth.net) 13.59.57 Nick Llorean1 is now known as Llorean (~DarkkOne@99-32-78-58.lightspeed.hstntx.sbcglobal.net) 14.08.01 Quit perrikwp (Read error: Connection reset by peer) 14.09.15 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 14.13.32 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 14.23.10 Quit [Saint] (Read error: Connection reset by peer) 14.24.14 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 14.24.38 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 14.33.08 *** Saving seen data "./dancer.seen" 14.46.34 Quit PaulJam (Ping timeout: 244 seconds) 15.06.18 Join TheLemonMan [0] (~LemonBoy@adsl-ull-136-252.45-151.net24.it) 15.07.44 # this might be a silly question, but how is the digital audio bitstream generally represented in DAPs? That is, at the elctronic level, how do they "get" the PCM stream to the DAC? Is it I2S? 15.10.28 # usually i2s but we have targets with memmapped interfaces 15.11.40 Join enthdegree [0] (~BitchX@unaffiliated/enthdegree) 15.11.56 # does Rockbox have to deal with the protocol, or is that handled by hardware? 15.12.06 # what you mean? 15.13.16 # hmm, I guess I'm not sure :P 15.14.00 # I've been trying to find a suitable SoC for this DIY DAP project, but none of the otherwise suitable ones have I2C 15.15.04 # The only one I could find was that SFC5200 chip in the Hx0, but I feel it's kind of old, I'm scared Freescale might discontinue it or something 15.15.23 # errr, I2S not I2C, sorry 15.16.31 # Hx0 uses scf5249/5250 this is quite different from other members of 5200 15.16.52 # There are lots of nice SoCs. 15.17.08 # sorry, I meant 5250 15.17.34 # I thought 5249/50 are discontinued 15.17.43 # I'd kind of prefer to use Coldfire, because I know more about 68k/Coldfire than ARM 15.17.48 # nope, they're still around 15.17.53 # surpsingly 15.18.25 # I wish they had faster Coldfire+ MCUs, those would be otherwise perfect, but they're too slow, only 50mhz 15.18.28 # last time I asked for sample they answered me this is discontinued line of products 15.18.32 # oh 15.18.33 # weird 15.18.51 # http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=SCF5250&nodeId=018rH3YTLCC2AB1752&tab=Buy_Parametric_Tab&fromSearch=false 15.19.17 # 5249 goes up to ~130MHz (we use 124 in boost mode) 15.20.15 # If you want to try something new, there are a few Cortex-M3 chips with external mem bus. 15.20.20 # http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MCF525X&fsrch=1&sr=8 15.20.45 # there's also those, although they're BGA. I can do most SMD stuff, not BGA though 15.21.01 # I know, I'm just not too familiar with ARM 15.21.15 # arm is quite easy 15.21.39 # are the ARM and Coldfire branches of rockbox about equal in optimization? 15.22.21 # yes 15.23.27 # I guess I should probably just go with ARM 15.23.40 Join AlexP_ [0] (~alex@rockbox/staff/AlexP) 15.23.52 # as much as I do like Coldfire 15.23.59 # I can always use CF for another project 15.24.19 Quit anewuser (Ping timeout: 265 seconds) 15.24.26 Quit AlexP (Ping timeout: 246 seconds) 15.24.36 # If you don't wan't to develop everything from the ground up look for SoC already supported in rb. 15.24.52 # ah okay, any suggestions? 15.25.12 # imx233 is quite recent 15.25.56 # s3c2440 should be possible to get also 15.28.12 # Wasn't it you to go with softcore? 15.28.20 # yeah, that was me 15.28.31 # I decided it was too hard, and impractical 15.28.40 # I didn't realize how power-hungry FPGAs are 15.29.59 # what a pitty, we will not have SPARC port :/ 15.30.33 Quit wodz (Quit: Leaving) 15.30.49 # What will we ever do without a SPARC port? 15.31.02 # hahah, not the most practical thing I suppose 15.31.17 # the i.MX233 looks good 15.32.03 Join PaulJam [0] (~Paule@p54BEDB61.dip.t-dialin.net) 15.51.10 Part LinusN 15.51.18 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 15.54.15 Quit perrikwp (Ping timeout: 244 seconds) 15.59.45 Join tjb0607_ [0] (c6ed31da@gateway/web/freenode/ip.198.237.49.218) 15.59.51 Join WalkGood [0] (~4@unaffiliated/walkgood) 16.00.03 # wow, the game boy emulator's sound engine causes tons of lag 16.01.50 Join maffe [0] (~Miranda@77-20-105-102-dynip.superkabel.de) 16.01.54 # emulation isn't exactly a CPU-friendly thing to do, and DAPs tend not to have massive CPUs 16.02.20 # most targets are several times too slow to run a gameboy properly under all circumstances 16.02.29 # yeah 16.02.41 # the sound just makes it die 16.03.00 # well, sound and graphics are what make it die (emulating the cpu is pretty trivial) 16.03.09 # but you can't generally turn the graphics off in a game :p 16.03.18 # so saving that part is not really an option :P 16.11.56 # I find it kind of funny that Doom runs faster with sound than Pokemon 16.12.17 # doom isn't emulated. 16.12.35 # even if it were, the graphics hardware in a basic PC of that era is *much* cheaper to emulate than the gameboy's 16.13.17 # because classic pc graphics hardware is a dumb 2d framebuffer (like ours!) - the gameboy's is a hardware sprite and tilemap engine with affine transforms 16.17.09 # yeah, makes sense 16.17.14 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 16.28.16 Quit enthdegree (Ping timeout: 252 seconds) 16.29.35 Quit Keripo (Quit: Leaving.) 16.29.52 Quit TheLemonMan (Quit: WeeChat 0.3.7) 16.33.10 *** Saving seen data "./dancer.seen" 16.34.53 Join bitcraft [0] (~bitcraft@66.254.199.148) 16.37.55 Quit tjb0607_ (Ping timeout: 245 seconds) 16.38.11 Join enthdegree [0] (~BitchX@unaffiliated/enthdegree) 16.42.24 Join vsrinivas [0] (U2FsdGVkX1@batman.acm.jhu.edu) 16.43.44 # hi folks! just started using Rockbox on a sansa clip, am really impressed, particularly w/ Crossfeed! 16.44.25 # am looking at bringing rockbox's crossfeed to my desktop in-fact :); the basic implementation looks fairly straightforward. 16.44.56 # has anyone tinkered with more sophisticated (fft-based?) ways of doing it? 16.45.28 # and for some other things, is there an fft in the rockbox tree? 16.46.34 Join saratoga_ [0] (980329e4@gateway/web/freenode/ip.152.3.41.228) 16.47.56 # vsrinivas: yes there are FFts available in rockbox 16.48.13 # i don't know how you would use an fft for crossfeed, I don't think it would be useful 16.49.20 # iiuc you'd want to mix some frequency bands more than others? 16.49.29 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 16.49.42 # vsrinivas: a filter is a more efficient way to do that 16.49.58 # i believe this is what the current implementation does 16.50.07 # it is; 16.53.41 # re: filter -- the filter would definitely be more efficient. but if i want a little equalizer-like-thingy to modify gains on each band, seemed more straightforward w/ fft?; 16.56.32 # it is surprising how many computrons these little mp3 players have too! 16.57.11 # EQ is generally done with filters as well 16.57.39 # FFTs are problematic because the bands are uniformly spaced and of equal size, which is usually not what you want 16.58.56 # for simple things like adjusting a band's gain, its often easier to just design a simple bandpass, apply the gain, and then mix it back in 16.59.13 # you don't require a sharp edge, so very basic filters will work 17.03.25 # fair, i was referring to modifying crossfeed gains, but that makes sense for EQ. 17.06.16 Quit maffe (Quit: IRC ist obsolet!) 17.38.45 Quit saratoga_ (Ping timeout: 245 seconds) 17.39.10 Quit Rasdere (Ping timeout: 245 seconds) 17.40.07 Quit perrikwp_ (Read error: Connection reset by peer) 17.41.22 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 17.45.07 Quit perrikwp (Read error: Connection reset by peer) 17.46.19 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 17.49.52 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 17.49.56 Quit enthdegree (Ping timeout: 248 seconds) 17.53.42 Join dhrasmus [0] (~dhrasmus@c-76-105-170-114.hsd1.or.comcast.net) 17.57.35 Quit perrikwp (Read error: Connection reset by peer) 17.58.50 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 18.19.08 Join enthdegree [0] (~BitchX@unaffiliated/enthdegree) 18.20.49 Quit fs-bluebot (Read error: Connection reset by peer) 18.20.50 Quit bluebrother (Read error: Connection reset by peer) 18.21.00 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 18.21.09 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 18.24.02 Join fs-bluebot [0] (~fs-bluebo@g231121166.adsl.alicedsl.de) 18.24.50 Join anewuser [0] (~anewuser@186.93.175.208) 18.24.50 Quit anewuser (Changing host) 18.24.50 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 18.32.49 # http://www.st.com/internet/mcu/product/252144.jsp 18.33.02 # do you guys think that might be a good candidate for a rockbox port? 18.33.11 *** Saving seen data "./dancer.seen" 18.39.51 Join stoffel [0] (~quassel@pD9E43EE1.dip.t-dialin.net) 18.56.18 # do we have new targets for 3.11? if so, please add them to the release notes 18.56.37 # i think the plan was to add the c200v2 for instance 18.56.49 # since several users have confirmed that the port is working well 18.57.02 # and the known issues have been fixed 19.03.50 # diginet: we don't currently have any thumb2 processors supported by rockbox, so porting to one might be a lot of work 19.11.34 # with the raaa changes it should be possible to disable inline asm though 19.21.03 Quit stoffel (Ping timeout: 272 seconds) 19.24.00 # saratoga, thanks! It's so bewildering trying to figure what chip is the best ot use for a given application, there's so many! 19.24.15 # i recommend one we already support 19.24.17 # what was the last iteration of ARM that wasn't thumb-2? 19.24.26 # hmmm 19.24.45 # armv4/5/6 targets are likely to be easiest, i'm not sure how much changed with thumb2 19.24.48 # well, I originally wanted to use the Coldfire in the Hx0, but I think its deprecated 19.25.51 # I wish Freescale offerred faster versions of their Coldfire+ MCUs, they're perfect save for maxing out at 50mhz 19.26.07 # i have no idea what the new cortex processors are like in terms of support,, although maybe someone here could tell you 19.26.14 # they're so far too new to be in mp3 players 19.26.19 # yeah 19.26.32 # someone earlier suggested the i.MX233 19.26.43 # is that in the Mini2440 thing, as mentioned in the Wiki? 19.26.59 # maybe, it is used in the fuze+ at least 19.28.53 # what's the newest ARM SoC that Rockbox supports with no more than minor issues? 19.34.19 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 19.34.20 Quit bertrik (Changing host) 19.34.20 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 19.34.46 # bluebrother, RockboxUtility will be able to install a clip zip on the time of the release of 3.11, right? 19.36.55 # are we releasing for the Zip? I think some stuff is still missing like a theme and such 19.38.20 # Zip is stable enough for daily use and people can always install a theme themselves 19.38.57 # yeah but we should at least have a default theme and such 19.39.03 # manual too 19.39.28 # should we hold off support in RockboxUtility for that? 19.39.32 # if its working but stuff is missing we should make it a stable target but not release IMO 19.40.36 Quit swilde (Remote host closed the connection) 19.41.27 # soon we'll have one target status per target 19.41.58 # although wasn't cabbie about ready to go? 19.42.15 # maybe we could just commit it before the release 19.43.13 # the cabbiev2 theme doesn't appear to get applied completely if it's used as a builtin theme, it works fine (for me) when selected manually 19.43.35 # that was because the font wasn't set in settings_list.c right? 19.44.33 # and I think some other problem too, the little icons in front of menu items IIRC 19.45.03 # the font at least is dead simple to fix, just add an entry here for 96x96: http://git.rockbox.org/?p=rockbox.git;a=blob;f=apps/settings_list.c;h=5acebef2a5a64581525d20eb011e75277f581d6a;hb=HEAD#l212 19.49.17 Join TheLemonMan [0] (~LemonBoy@adsl-ull-136-252.45-151.net24.it) 19.50.25 # apparently i posted a patch for the font change on teh tracker and then forgot about it 19.50.26 # did we spend like 10 times more time to discuss this font than what we need to fix it ? 19.50.52 # i think i did fix it actually, although i didn't try the fix 19.51.04 # do you have a zip ? 19.51.13 # no, but i should have compiled the sim 19.51.20 # just busy 20.01.44 # I pushed my WIP of FS#12390 to g197 and g198 20.01.45 # http://www.rockbox.org/tracker/task/12390 3Sansa Clip Zip Cabbiev2 Port (patches, new) 20.01.46 # 3Gerrit review #197 at http://gerrit.rockbox.org/r/#change,197 : FS#12390 - Sansa Clip Zip Cabbiev2 Port by Stephen Carroll by Bertrik Sikken (changes/97/197/1) 20.02.36 Quit TBCOOL (Quit: .) 20.07.58 # saratoga: is the c200v2 installable with rockbox utility? 20.08.12 Quit benedikt93 (Quit: Bye ;)) 20.08.32 # funman: what's the status on the nano2g? 20.10.14 # usb doesn't work 20.10.46 # we might as well just disable USB for 3.11 release 20.11.24 Quit anewuser () 20.12.37 # Can it reboot to OF disk mode like the PP ipods? 20.12.42 # (...used to do) 20.13.00 Join anewuser [0] (~anewuser@186.93.175.208) 20.13.01 Quit anewuser (Changing host) 20.13.01 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 20.13.34 # probably, emCore has a disk mode entry 20.14.45 # [7]: any ideas about that? 20.16.38 # gevaerts: hardware-wise its basically identical to the clip but with a color screen, so i assume it can be, although maybe we have to toggle something in the code to enable it 20.17.02 # we didn't release it before because we had some issues with the playback engine on low memory, color targets, but those were fixed a while back 20.17.47 # rbutil does have a clipv2 option in the current release 20.17.51 # sorry c200v2 option 20.18.00 # Ah, that sounds good then 20.18.44 # AlexP_: ping 20.23.23 Quit PaulJam (Ping timeout: 260 seconds) 20.23.28 Join Strife89 [0] (~Strife89@207.144.56.254) 20.33.15 *** Saving seen data "./dancer.seen" 20.38.46 Join stoffel [0] (~quassel@pD9E43EE1.dip.t-dialin.net) 20.42.53 Quit Strife89 (Quit: Quick reboot) 20.45.00 # <[7]> gevaerts, funman: it can, and I think it is actually implemented if USB is disabled 20.45.30 # OK, so if someone can test that and commit it to the 3.11 branch... 20.45.32 # <[7]> "diskmodehotstuff\x01\0\0\0" somewhere at the end of IRAM is the signature IIRC 20.46.08 Join prof_wolfff [0] (~prof_wolf@81.61.201.173.dyn.user.ono.com) 20.46.42 # <[7]> what's going on here btw? i didn't have time to follow this the last couple of months, and I probably won't have that time for the next month either... 20.46.49 # <[7]> did nano2g usb ever work with the new driver? 20.46.54 # <[7]> why not just use the old one? 20.46.58 # <[7]> what exactly did break here? 20.47.58 # If the old driver is an option, I'd definitely prefer that 20.50.01 # i don't know if the new driver works, because the old driver was broken by usb.c changes 20.52.06 # [7]: first bad commit is bfd69f2aa19 20.52.33 # a (conflicting) revert didn't work, and i don't have the patch i tried (for the revert) 20.54.09 # <[7]> gevaerts: can you give me an executive summary on the usb core changes? 20.56.20 # and yeah the old driver is a perfect option because the changes didn't add new features (and potentially regressions) 20.58.34 Join Strife89 [0] (~Strife89@207.144.56.254) 20.59.51 # [7]: usb-s3c6400x.c http://pastie.org/3656487 and usb-s3c6400x.h http://pastie.org/3656489 - both working with bfd69f2aa19^ 21.01.15 # [7]: nearly nothing, really. If you have USB_DETECT_BY_REQUEST (which was called USB_DETECT_BY_CORE before) now usb.c decides that the host is there when it sees a transfer completion, instead of usb_core.c when it saw a control transfer. If you don't have USB_DETECT_BY_REQUEST (which IIRC is the case for the nano2g) I don't think anything changed in practice at all 21.01.44 # I'd like to see the nano2g (and classic) move to USB_DETECT_BY_REQUEST, by the way 21.04.24 # i can try a patch for that, i have no idea how to implement it 21.04.43 # when other drivers were converted, I only saw code removal inside usb drivers 21.07.52 # I *think* it's just a matter of changing config.h 21.10.09 # <[7]> gevaerts: I tried to move the nano2g to that when it was introduced, and it didn't want to work at the first try 21.10.20 # <[7]> and, as usual, I didn't have much time to investigage 21.10.22 # <[7]> investigate* 21.10.36 # 3f709ead is the change for amsv1, and 82259b7a is amsv2 21.10.42 # <[7]> i probably just didn't understand correctly how this needs to be implemented 21.11.17 # <[7]> so you say bfd69f2aa19 broke it? 21.11.35 # <[7]> where can I get a diff of that? 21.11.42 # * [7] doesn't even have a git account yet 21.11.43 # git show bfd69f2aa19 21.11.54 # <[7]> let alone a clone :) 21.12.29 # http://git.rockbox.org/?p=rockbox.git;a=commitdiff;h=bfd69f2aa19 21.15.22 # <[7]> how does that one fail? 21.17.04 # <[7]> looks like what has changed is basically when the driver is being started/stopped 21.17.43 # <[7]> AFAIK the old nano2g driver reports a spurious bus reset while starting up the usb core 21.18.23 # <[7]> and the whole insert/extract magic is controlled by a thread that's polling vbus 21.18.35 # where's that thread? 21.18.54 # <[7]> in usb-s3c6400x.c, somewhere at the bottom 21.19.08 # <[7]> I suspect that it just isn't started any more because of some change 21.19.26 # i don't see specific mention of a thread 21.20.44 Quit Strife89 (Ping timeout: 272 seconds) 21.20.54 # <[7]> oh, wait, I mixed that up 21.21.13 # <[7]> in rockbox that thread is somewhere in the usb core, and is calling usb_detect() 21.21.19 # <[7]> in emcore, it's in the driver itself 21.22.41 Quit perrikwp (Read error: Connection reset by peer) 21.23.25 # http://pastie.org/3656639 -> charge only, no USB screen 21.23.53 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 21.24.28 # ah, AMS signals usb plug/unplug from isr 21.26.51 # USB_STATUS_BY_EVENT is defined -> usb_tick should poll usb_detect every tick 21.29.10 # <[7]> that might help on nano2g then 21.29.24 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 21.30.30 Quit perrikwp (Read error: Operation timed out) 21.30.35 # but no USB screen tho 21.32.18 # usb_enable(1) ain't called 21.32.19 Quit y4n (Quit: Assumption is the mother of all fuckups) 21.35.23 # usb_detect is called at boot but not anymore 21.37.00 Quit mortalis (Quit: KVIrc 4.1.1 Equilibrium http://www.kvirc.net/) 21.37.54 # ah i need to remove USB_STATUS_BY_EVENT if detection is made by polling 21.42.11 # i still get the same infinite loop with GRSTCTL & 1 == 1 21.48.29 Join kakashi_ [0] (~kakashi_@nltk/kakashi) 21.52.54 Quit domonoky (Quit: Leaving.) 21.54.21 Join Strife89 [0] (~Strife89@207.144.56.254) 21.55.30 # hi 21.55.35 # I have a sansa clip 21.55.43 # the battery seems not to work 21.55.50 # it just suddenly stopped working 21.56.03 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 21.59.03 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 22.01.13 Quit perrikwp_ (Ping timeout: 252 seconds) 22.02.47 Quit perrikwp (Read error: Connection reset by peer) 22.04.16 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 22.05.17 Part parafin ("If you don't like rock'n'roll | It's too late now") 22.06.14 # if i ignore the infinite loop, i still see charging only 22.06.29 # iiuc that means no transfers took place? 22.13.01 Quit perrikwp (Read error: Connection reset by peer) 22.13.17 # <[7]> funman: if it gets stuck at that location that definitely means that something is wrong 22.13.22 # <[7]> most likely a clock not running 22.14.16 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 22.14.39 # so what do you suggest 22.16.01 Quit kakashi_ (Ping timeout: 246 seconds) 22.16.20 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 22.16.50 Join kakashi_ [0] (~kakashi_@nltk/kakashi) 22.17.01 # <[7]> short term: revert to the old driver and figure out why that core change broke it 22.17.32 # <[7]> long term: double-check everything and bisect between a working driver and the current state 22.18.28 # <[7]> i.e. do dumps of all OTG, PHY and SYSCON registers at the point where the lockup happens both with the broken and a working driver, and look for differences 22.18.30 Quit perrikwp (Read error: Operation timed out) 22.19.33 # [7]: i mean please give a diff for 'figure out why that core change broke it 22.19.56 # or list of registers to watch 22.20.57 # <[7]> funman: is usb_detect being called regularly in bfd69f2aa19? if not, why? 22.21.59 # i don't know 22.22.09 # <[7]> add some logf() then :) 22.22.36 # i mean in my current code usb_detect works so it's not very interesting 22.23.05 # usb_reset() is called - and here the core never acks reset 22.23.36 Part WalkGood 22.23.58 # [7]: http://www.rockbox.org/irc/log-20120322#01:17:53 22.26.40 Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) 22.30.02 # <[7]> funman: I think we might be facing different bugs with those two drivers 22.30.12 # <[7]> and I figure getting the old one to work again will be easier 22.30.23 # that's what i'm doing .. 22.30.35 # all your commits that 'fix USB' since last december didn't work for me 22.30.39 # <[7]> we should fix the new one as well at some point, but if we aren't even sure whether that did ever work, we don't really have time for that now 22.30.50 # no, i don't care about the new one either 22.30.55 # i'll do that later 22.31.08 # <[7]> so IIUC bfd69f2aa19 did break the old one 22.31.18 # i pasted the old driver i'm using and i gave the exact revision in the irc log i mentioned 22.31.35 # <[7]> my next step would be trying to figure out what exactly is going on with it, i.e. *why* it actually broke, because I can't see an obvious reason 22.32.03 # <[7]> so I'd try building bfd69f2aa19 with a logf in usb_detect, to check if that one is even called. if not, that might explain the whole trouble. if it is, we'll need to dig deeper 22.33.16 *** Saving seen data "./dancer.seen" 22.33.58 # logf? i use panicf 22.34.23 # <[7]> that wouldn't help us if it's called just once 22.34.41 # <[7]> for that particular one I'd use logf and check if the log is being spammed with lots of calls to it 22.35.01 # * funman needs to see how to use logf 22.35.54 # <[7]> if nothing has changed since I used it for the last time: #define LOGF_ENABLE #include "logf.h" 22.36.08 # <[7]> select advanced, logf in configure 22.36.23 # <[7]> and add logf("whatever") calls in the code 22.37.38 # yes, it's called frequently 22.38.47 # <[7]> what's the USB failure behavior with that revision? just not detected at all? 22.38.55 # <[7]> or do you at least get a USB screen? 22.41.50 # infinite loop 22.42.01 # in usb_reset(); , so before USB screen 22.42.45 Quit dhrasmus (Quit: Leaving) 22.44.30 # <[7]> funman: er, wait... you're trying to tell me that this particular commit caused GRSTCTL & 1 to not be cleared any more? 22.45.27 # yes, that's what i'm telling 22.46.40 # <[7]> am I correct that usb_stack_enable ends up calling usb_drv_init/usb_drv_exit 22.47.29 Quit stoffel (Remote host closed the connection) 22.50.01 # <[7]> funman: it never gets past this? 22.50.01 # <[7]> while (GRSTCTL & GRSTCTL_csftrst); /* Wait for OTG to ack reset */ 22.51.17 # yes, that's what i'm telling 22.52.25 Quit XavierGr (Ping timeout: 260 seconds) 22.54.07 # <[7]> funman: can you dump the following regs immediately before asserting CSFTRST? PWRCON, PWRCONEXT, PCGCCTL, GRSTCTL, INTMSK 22.54.38 # <[7]> after that, can you check if the usb irq handler is ever called? 22.58.41 # <[7]> and the new driver shows the same behavior? 23.02.37 Quit perrikwp_ (Read error: Connection reset by peer) 23.03.51 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 23.09.29 Join z180 [0] (~chatzilla@ip-2-202-71-151.web.vodafone.de) 23.10.00 Quit enthdegree (Ping timeout: 252 seconds) 23.11.11 Join LinusN [0] (~linus@giant.haxx.se) 23.22.34 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 23.24.41 Join perrikwp__ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 23.24.58 Quit perrikwp (Ping timeout: 246 seconds) 23.26.27 Quit perrikwp_ (Read error: Operation timed out) 23.27.50 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 23.29.56 Quit Strife89 (Ping timeout: 272 seconds) 23.30.21 Quit perrikwp__ (Ping timeout: 244 seconds) 23.32.12 Quit TheLemonMan (Quit: WeeChat 0.3.7) 23.32.31 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 23.35.18 Quit perrikwp (Ping timeout: 252 seconds) 23.35.34 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 23.36.22 Quit perrikwp (Read error: Connection reset by peer) 23.37.37 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 23.38.48 Quit perrikwp_ (Ping timeout: 272 seconds) 23.40.38 Part LinusN 23.44.24 # bertrik: yes, release status is determined by the server, not Rockbox Utility 23.46.22 Quit perrikwp (Read error: Connection reset by peer) 23.47.33 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 23.48.52 Quit z180 (Ping timeout: 250 seconds) 23.49.34 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 23.52.19 Join cnutor [0] (~none@78.32.20.225) 23.52.36 Quit perrikwp (Ping timeout: 248 seconds) 23.52.45 Quit cnutor (Client Quit) 23.54.29 Part TomColler 23.56.00 Quit nosa-j (Ping timeout: 260 seconds) 23.57.04 Join nosa-j [0] (~m00k@adsl-74-235-79-134.clt.bellsouth.net)