--- Log for 07.02.116 Server: sendak.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 day and 11 hours ago 00.02.01 Quit nlogex (Quit: WeeChat 1.3) 00.04.23 # question time, can i install the firmware from a 7g on a 6g? 00.04.32 # ipod classic* 00.05.26 # is there a way of specifying the arch when using tools/configure? 00.06.47 # <[Saint]> No. 00.07.23 # <[Saint]> It always assumes you're building for the host arch unless you pass crosscompile explicitly. 00.08.02 # <[Saint]> (for the non-Android hosted platforms) 00.09.21 # <[Saint]> orpheu: No. 00.12.58 # ok, thank you 00.13.28 # thanks I'm currently build for amd64, I'll see how it goes 00.13.29 # <[Saint]> HazWard: Assuming you're thinking of this for one of the SDL platforms, actually I think you could just make sure that your crosscompiled SDL instance appears first in your $PATH and it should adopt that...but don't quote me on that one. 00.14.32 # [Saint]: Unfortunately I do really understand what you saying... 00.15.02 # <[Saint]> I understand what I'm saying, and, yes, it is unfortunate. 00.17.20 # *I don't 00.18.06 # <[Saint]> There's not a hell of a lot of reason to go out of your way to build for 64bit though, fwiw. 00.18.42 # <[Saint]> $HOST_SYSTEM will happily consume a 32bit binary. 00.22.19 # It was to try the building process and see what was the result 00.24.12 # If I understand correctly I could build rockbox for my 9$ CHIP (from KickStarter) and make my own music player 00.24.55 *** Saving seen data "./dancer.seen" 00.26.24 Quit ender (Quit: You must know by now we Brits are going metric inch by inch! -- Greg Chapman) 00.27.07 # <[Saint]> If you took the path of least resistance there it would run terribly. 00.27.35 # <[Saint]> A full port would indeed be possible, but probably more work than you're intending on. 00.27.53 # <[Saint]> Running hosted on that is going to run like a bag of crap, but, it would be possible. 00.29.58 # <[Saint]> You could have a partial implementation fairly easily without all the graphics overhead by building the warble playback library and building a wrapper around it. 00.31.31 # <[Saint]> (rockbox/lib/rbcodec/test) 00.32.18 # <[Saint]> warble is a commandline standalone (partial) playback library well suited for minimal environments. 00.34.36 # <[Saint]> It has a very basic subset of features like seek, dither, volume control, play/pause, loop-by-offset, play/resume-from-offset. 00.35.57 # <[Saint]> Building a dialog wrapper for it to give it a basic user interface, or binding functions to hardware keys, would be a fun days work for the sufficiently motivated. 00.36.24 # But lose all the sound settings 00.37.06 # I was thinking about binding hardware keys, warble seems like a great tool 00.40.04 # <[Saint]> I guess I might be being needlessly harsh on the poor wee CHIP. I just don't see a host OS (and likely a DE?) and the SDL app running too effectively in 1GHz/512MB 00.41.20 # <[Saint]> And, yeah, it is pretty neat. It was a GSoC project. 00.42.46 # I could strip down the os to only have an x server running with rockbox 00.47.55 # <[Saint]> I use a little wee ODROID XU4 as an audio box, streamer, *sonic host, media share, personally. 00.51.31 # How's the power consumption? 00.54.04 # <[Saint]> Entirely insignificant. 00.54.40 # <[Saint]> It absolutely sips power at idle, and not much more at load. 00.55.25 # nice and you're using warble 00.55.30 # ? 00.57.35 # <[Saint]> No. 01.22.24 Quit ruskie (Ping timeout: 240 seconds) 01.23.24 Quit djukon (Ping timeout: 240 seconds) 01.25.20 Join djukon [0] (~djukon@50708323.static.ziggozakelijk.nl) 01.34.05 Quit petur (Quit: Leaving) 01.40.01 Quit lebellium (Quit: ChatZilla 0.9.92 [Firefox 45.0/20160204142810]) 01.44.42 Join ruskie [0] (ruskie@sourcemage/mage/ruskie) 02.05.48 Quit krabador (Quit: Take The Time) 02.09.46 Quit TheSeven (Ping timeout: 250 seconds) 02.16.08 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 02.18.28 Join rela [0] (~x@pdpc/supporter/active/rela) 02.22.11 Join narann [0] (~narann@162.222.144.162) 02.22.42 # hi all, I was just wondering, is rockbox still alive or it's a dead project? Thanks in advance! 02.23.46 # http://gerrit.rockbox.org/r/#/q/status:merged 02.24.17 # people are still updating and creating, so i say its not 02.24.52 # <[Saint]> narann: perhaps you're confusing the nature of Rockbox at its very core. 02.24.56 *** Saving seen data "./dancer.seen" 02.26.15 # <[Saint]> narann: realistically speaking Rockbox is "By Developers For Developers", there's no team of people ensuring that any and all devices get a port simply because they exist. There's no direct push to get it into the hands of the community (if you find it, and like it, great - but no one really cares if that happens). 02.26.29 # <[Saint]> It's just a bunch of people who wanted something badly enough to make it happen. 02.26.39 # Are there feature not enable by default on rockbox that I can enable when I compile the code myself? 02.26.57 # <[Saint]> No. 02.27.54 # <[Saint]> Well...depending on what you class as a "feature". There's nothing particularly useful to an end user that isn't already enabled. 02.29.20 # <[Saint]> If $feature can run on a given target and it is reasonable to do so it will be enabled for that target. 02.30.13 # <[Saint]> compile-time extras aren't particularly interesting at all for end users (debug, logf, test-plugins, etc.) 02.30.47 # my lcd seems to run at a lower fps or clock or something, i can see it refreshing at diferent speeds, is it something that is known and acepted so we can sve more battery? 02.31.05 # it happens on both my ipods, on apple it doesnt happen 02.31.32 # <[Saint]> orpheu: are you using our official builds or some unofficial clusterfuck? 02.32.04 # thanks, as the last release was in 2013 I was just wondering 02.32.05 # using the build on rock box 02.32.22 # dev build for 6g ipod 02.32.23 # me too: official build 02.32.46 # should I compile myself? 02.32.55 # <[Saint]> narann: the releases kinda stalled because there was no real point to them and not enough time, manpower, and willingness to continue them. 02.33.10 # <[Saint]> narann: if you have an officially supported device you should use the developer builds. 02.33.22 # <[Saint]> There is no reason to compile yourself. 02.33.34 # no prob. As a open source dev myself I understand 02.33.42 # that's what I was thinking 02.34.29 # <[Saint]> The releases were really only there to satisfy the needs of those who for whatever reason felt uneasy about using the developer builds, and in that time ~2013, the developer builds were at times fairly unstable. 02.34.52 # <[Saint]> These days, it is likely that for all the officially supported candidates that the devloper builds outweigh the release in stability. 02.35.30 # <[Saint]> The releases were, essentially, a verified "we know this works as expected" snapshot. 02.35.44 # ok thanks! 02.35.54 # <[Saint]> But the requirement for such a thing these days with the core as stable as it is is minimal. 02.36.11 # <[Saint]> You should have no critical issues with the development builds. 02.37.09 # I will stick with the official build for now. I don't have much time to compile it yet 02.37.26 # <[Saint]> narann: you don't need to, as I stated. 02.37.43 # As an emulator dev It could be interesting to dig into the code one day :D 02.37.45 # <[Saint]> If your device is officially supported (ie. has a release) developer builds are available to you. 02.37.58 # <[Saint]> No need to compile at all. 02.38.09 # Sansa Fuze! I want opus support! :D 02.38.19 # <[Saint]> Developer builds are available both from the main page and RBUtil. 02.38.36 # <[Saint]> Just again, for clarity, there is no reason to compile yourself and there is nothing to gain in doing so. 02.38.58 # I get it! :) Thanks! 02.39.23 # <[Saint]> http://build.rockbox.org/data/rockbox-sansafuze.zip 02.39.30 # <[Saint]> et viola. 02.40.02 # <[Saint]> Extract to the root of the device, and you're done. There is no need to reinstall the bootloader. 02.40.54 # <[Saint]> orpheu: Then, no. The only time the refresh rate is altered is in a few select plugins and if there is an EQ meter on the WPS. 02.41.31 # <[Saint]> Though it is possible that you are seeing some result of select boosting. 02.42.33 # it really looks like it refreshing too slow 02.43.01 # i wish i had a good camera so i could show you 02.44.26 # is the refresh rate something we can change? i dont mind compiling with a faster refresh rate to see if it is the cause 02.45.18 # i just need someone to tell me what values to change.. 02.46.10 # wow direct sansa fuze build thanks! 02.46.51 # <[Saint]> narann: bookmark it if you want, that url will always point to the most recent Rockbox version for your device, it is updated on every commit to the codebase. 02.57.06 # thanks 03.01.22 Join PurlingNayuki [0] (~Thunderbi@113.88.173.220) 03.06.13 Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) 03.14.41 # on the sansa fuze+, recording from the microphone is super quiet. 03.15.03 # could somebody please look at that? 03.15.08 # <[Saint]> shit microphone is shit, more news at 11. 03.15.17 # or is it a known bug 03.15.34 # so we couldnt just amp it or something? 03.15.50 # the problem is in the microphone itself? 03.17.06 # <[Saint]> As far as I am aware, yes. Cheap hardware is cheap. Good for a personal dictaphone and very little else. 03.46.46 Join rela_ [0] (~x@p200300764D4BD00005488C7A11EA1C40.dip0.t-ipconnect.de) 03.47.12 Join CrashBash-Kun [0] (~CrashBash@unaffiliated/crashbash-kun) 03.49.54 Quit rela (Ping timeout: 240 seconds) 03.57.35 Join ZincAlloy1 [0] (~Adium@p57B95626.dip0.t-ipconnect.de) 04.00.11 Quit ZincAlloy (Ping timeout: 252 seconds) 04.09.45 Quit PurlingNayuki (Ping timeout: 240 seconds) 04.21.35 Quit narann (Quit: Leaving) 04.24.58 *** Saving seen data "./dancer.seen" 04.29.43 Quit ZincAlloy1 (Quit: Leaving.) 05.10.29 Quit Rower (Ping timeout: 245 seconds) 05.18.17 Quit CrashBash-Kun (Quit: Leaving) 05.35.14 Quit TheSeven (Ping timeout: 240 seconds) 05.37.03 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 06.25.02 *** Saving seen data "./dancer.seen" 06.47.37 Quit sparetire (Quit: sparetire) 06.50.53 Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) 07.03.29 Join rela__ [0] (~x@p200300764D4BD0008805EABFB6EE1EC5.dip0.t-ipconnect.de) 07.06.44 Quit rela_ (Ping timeout: 245 seconds) 07.42.27 Join goom [0] (~go4m@cpe-66-25-153-174.satx.res.rr.com) 07.52.09 Quit amiconn (Remote host closed the connection) 07.52.09 Quit pixelma (Remote host closed the connection) 07.54.12 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 07.54.14 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 07.56.56 # jtdesigns01: did you increase gain 07.57.22 # arrow keys in recording screen, then left/right on gain slider. 07.57.29 # at least, thats wat i do on clip+ and its amazingly loud 08.07.26 Quit yuriks (Remote host closed the connection) 08.08.53 Join yuriks [0] (~quassel@opentyrian/developer/yuriks) 08.25.04 *** Saving seen data "./dancer.seen" 08.54.46 Quit Rower (Ping timeout: 264 seconds) 09.16.53 Quit rela__ (Quit: Leaving) 09.17.07 Join rela [0] (~x@pdpc/supporter/active/rela) 09.24.12 Join rela_ [0] (~x@p200300764D7A4E00C82CFA8FB67AC306.dip0.t-ipconnect.de) 09.24.16 Quit rela_ (Remote host closed the connection) 09.25.54 Quit rela (Ping timeout: 245 seconds) 09.27.27 Join PurlingNayuki [0] (~Thunderbi@14.158.32.112) 09.34.51 Quit Bray90820 (Ping timeout: 276 seconds) 09.44.50 Join Bray90820 [0] (~bray90820@173-17-46-117.client.mchsi.com) 09.49.04 Join ender` [0] (krneki@foo.eternallybored.org) 10.25.06 *** Saving seen data "./dancer.seen" 10.31.22 Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) 10.37.07 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 10.51.17 Join rela [0] (~x@pdpc/supporter/active/rela) 12.10.58 Join lebellium [0] (~chatzilla@89-93-179-187.hfc.dyn.abo.bbox.fr) 12.25.10 *** No seen item changed, no save performed. 13.07.24 Join PurlingNayuki1 [0] (~Thunderbi@14.158.32.112) 13.09.47 Quit PurlingNayuki1 (Read error: Connection reset by peer) 13.10.56 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 13.11.14 Quit PurlingNayuki (Ping timeout: 260 seconds) 13.12.16 Join PurlingNayuki [0] (~Thunderbi@14.158.32.112) 13.18.40 Quit pamaury (Ping timeout: 245 seconds) 13.32.47 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 14.11.32 Join FSanches [0] (~felipe@201-40-49-122.bsace702.dsl.brasiltelecom.net.br) 14.25.11 *** Saving seen data "./dancer.seen" 14.25.45 Join PurlingNayuki1 [0] (~Thunderbi@14.158.32.112) 14.28.54 Quit PurlingNayuki (Ping timeout: 240 seconds) 14.28.55 Nick PurlingNayuki1 is now known as PurlingNayuki (~Thunderbi@14.158.32.112) 14.48.10 Quit bluebrother (Disconnected by services) 14.48.15 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 14.48.52 Join fs-bluebot_ [0] (~fs-bluebo@xd9beb07c.dyn.telefonica.de) 14.50.45 Quit fs-bluebot (Ping timeout: 245 seconds) 15.27.25 Join FSanches1 [0] (~felipe@189-31-54-82.bsace702.dsl.brasiltelecom.net.br) 15.30.14 Quit FSanches (Ping timeout: 252 seconds) 15.35.41 Quit FSanches1 (Quit: Leaving.) 15.46.44 Quit pamaury (Ping timeout: 252 seconds) 15.50.29 Quit Rower (Ping timeout: 245 seconds) 16.15.22 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 16.23.22 # jtdesigns01: iirc 16.23.44 # I implemented mic gain for the fuze+ so you should be able to control recording gain for the recording screen 16.23.53 # but the microphone is pretty bad anyway 16.25.15 *** Saving seen data "./dancer.seen" 16.30.13 Join sparetire [0] (~sparetire@unaffiliated/sparetire) 16.36.44 Quit krnlyng (Quit: huiiiiii) 16.47.36 # Build Server message: 3New build round started. Revision 7619031, 255 builds, 25 clients. 16.50.23 Join krnlyng [0] (~liar@178.114.91.36.wireless.dyn.drei.com) 16.53.40 # Build Server message: 3Build round completed after 364 seconds. 16.53.41 # Build Server message: 3Revision 7619031 result: 0 errors 4 warnings 17.16.29 # Hum why is there such a gap between -40dB and -39dB on YP-R0? 17.16.40 # It's not as progressive as the other levels 17.19.47 # Is it because of the Samsung Audio driver? Since it's a RaaA port 17.35.16 Join petur [0] (~petur@rockbox/developer/petur) 17.45.51 Quit krnlyng (Quit: huiiiiii) 17.46.34 Join krnlyng [0] (~liar@83.175.90.24) 17.47.07 Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) 17.51.54 Join ZincAlloy [0] (~Adium@p57B95626.dip0.t-ipconnect.de) 18.01.24 Quit PurlingNayuki (Read error: Connection reset by peer) 18.02.27 Join PurlingNayuki [0] (~Thunderbi@14.158.32.203) 18.14.28 Quit feoafka (Remote host closed the connection) 18.15.13 Join athidhep [0] (afoakf@unaffiliated/athidhep) 18.17.15 Quit krnlyng (Quit: huiiiiii) 18.18.24 Quit athidhep (Client Quit) 18.25.17 *** Saving seen data "./dancer.seen" 18.43.10 Join krnlyng [0] (~liar@83.175.90.24) 18.59.57 Join wodz [0] (~wodz@89-77-223-98.dynamic.chello.pl) 19.01.06 Join krabador [0] (~krabador@unaffiliated/krabador) 19.15.29 Join Link8 [0] (~me@5ED3F691.cm-7-4d.dynamic.ziggo.nl) 19.36.18 Join FSanches [0] (~felipe@2804:7f3:8384:80c4::6) 19.38.50 Quit PurlingNayuki (Ping timeout: 256 seconds) 19.47.36 Nick suYin`OFF is now known as suYin (mysuyin@server2.shellfire.net) 19.48.30 Join foolsh [0] (~bbrown@c-98-226-50-174.hsd1.in.comcast.net) 19.51.10 Quit Rower (Ping timeout: 245 seconds) 20.03.10 Join ZincAlloy1 [0] (~Adium@p57B95626.dip0.t-ipconnect.de) 20.03.10 Quit ZincAlloy (Read error: Connection reset by peer) 20.04.50 Join Rower [0] (~husvagn@d83-183-134-99.cust.tele2.se) 20.07.02 Quit Strife89 (Ping timeout: 250 seconds) 20.07.26 Join Strife89 [0] (~quassel@adsl-98-80-220-250.mcn.bellsouth.net) 20.25.18 *** Saving seen data "./dancer.seen" 20.31.00 # Do any of you have document describing 512bit data part returned after cmd6 by SD card? 20.36.06 Join p3tur [0] (~petur@rockbox/developer/petur) 20.38.40 # wodz: wait a sec 20.39.21 # pamaury: I got this response from cmd6 and I am curious if it makes any sense 20.40.04 # pamaury: I have a feeling that I will need ability to repack OF soon :-) 20.44.34 # I'm pretty sure the spec says something about the data (at least the size) but I need to find it again, the SD spec is just horrible 20.45.08 # yes, the size is specified (512bit) but I can't find description of the format 20.45.42 # doc says only you should parse the output to be sure the card entered requested mode 20.48.42 # wodz: section 4.3.10.4 of the spec I think 20.48.54 # simplified one? 20.48.56 # (version 3.01 final, simplified part 1) 20.49.07 # * wodz looks 20.49.10 # look for " Switch Function Status" 20.50.07 # hmm, current version is 4.10 20.50.47 # yeah I'm not reading the latest one 20.51.02 # I have the 4.1, I can look at it 20.51.03 # ok, got it 20.52.44 # hmm, does it transfer MSB first or LSB first? 20.54.04 # I never remember, the spec is so annoy. I think it transfers MSB first 20.54.09 # so bit 511 is actually the first one 20.54.24 # or maybe it transfer most significant BYTE first 20.54.37 # so 511:504 is the first byte 20.54.52 # never understood why then did that 20.54.55 # *they 20.55.50 # you are looking for bits 379:376 20.55.56 # pamaury: I get this http://pastie.org/10712642 20.57.15 # if I'm not mistaken: ignore the first 16 byte: those are bits 511:384, the 17th byte (ie 0x1 in your data) corresponds to bits 383:376 20.57.36 # and since you want 379:376, that data[16] & 0xf = 1 20.57.39 # you are good ;) 20.57.57 # cool 20.58.52 # I take it that the driver is working ? 20.59.39 # by the way, the hwstub server rewrite is almost complete, I hope to push it to gerrit tonight 21.00.00 # at least to the point where it passes initialization and returns some meaningful data from the card. Didn't check sector reading yet. Need to clean up first. 21.00.36 # good to hear that :) 21.03.52 Join saratoga [0] (123e11e0@gateway/web/freenode/ip.18.62.17.224) 21.09.24 # lebellium: it uses the same driver as the clip players, so should be fixable 21.09.56 # What are practical block sizes requested from DMA in rockbox? 21.10.39 # wodz: you mean for SD ? 21.10.57 # pamaury: No in general, so also by playback 21.11.09 # Oh, for playback it's fairly small 21.11.12 # lebellium: looks like it was caused by a recent patch but hasn't been investigated much: http://www.rockbox.org/irc/log-20150201#14:46:20 21.11.36 # for storage it might be up to ~128KiB or something like that 21.11.58 # pamaury: DMA engine in atj has 16bit for size expressed in bytes so 64k max chunk. I wonder if I need to implement linking in software 21.12.03 # saratoga: oh I didn't know lorenzo already reported last year 21.12.43 # hmm, so I probably should 21.16.36 # saratoga: lorenzo hasn't been around here for 1 year now. I don't know who would fix that issue :S 21.20.59 # wodz: on imx233, for sd/mmc, I cut the transfers in pieces of 64KiB I think 21.21.05 # but for playback I don't do it 21.21.19 # (imx233 is also limited to 16bit size) 21.37.05 # pamaury: Looks like data transfers work correctly. disk_mount_all() returns 1 which means it validated filesystem as fat :-) 21.38.08 # great :) 21.38.48 # this RO driver for now though 21.42.26 Join Johnny5 [0] (4633b58f@gateway/web/freenode/ip.70.51.181.143) 21.42.34 Quit Johnny5 (Client Quit) 22.01.14 Quit FSanches (Quit: Leaving.) 22.01.45 # besides, special caracters like german umlauts don't display correctly in folder and file names on the microSD only. On the internal memory it works fine 22.02.06 # Default codepage setting has no impact here 22.02.27 # poor YP-R0, it worked better in 2013 than now :( 22.02.33 # I was wrong. DMA engine in atj has 20bits for size so ~1MB 22.03.20 # pamaury: ^ 22.03.36 # that's plenty ! 22.04.24 # Its SD block which imposes limitation. It has 16bits only 22.08.18 Quit Rower (Ping timeout: 248 seconds) 22.17.28 # kugel: ping 22.17.50 # lebellium: pong (although I doubt I'm gonna be helpful) 22.18.36 # kugel: unfortunately there was no final word/solution to this old issue: http://www.anythingbutipod.com/forum/showpost.php?p=644529&postcount=1174 22.18.48 # do you have any other idea? 22.19.03 # i think i fixed that? 22.19.33 # iirc the default mount options are now utf8 codepage 22.20.17 # I don't know if what you thought is fixed is actually not fixed or if there's still another issue causing the umlauts not to displaying on the microSD on R0 22.21.13 # the kernel doesnt support some codepages so attempting to use those doesn't succeed 22.21.19 # but utf8 should work 22.21.36 # plus, the default iso8859-1 should work for german umlauts 22.21.54 # on the internal memory it's all fine 22.22.36 # no idea, really, I'm out of the loop atm 22.22.49 # I'm sorry 22.23.42 # in the original firmware umlauts display correctly on the microSD 22.23.54 # so it shouldn't be an issue with the kernel? 22.24.07 Quit wodz (Quit: Leaving) 22.25.22 *** Saving seen data "./dancer.seen" 22.25.25 # probably not 22.26.17 # you could hook up a terminal or run "mount" and capture the output by other means to check the mount options 22.26.46 # you should be able to use the system library function anywhere 22.29.07 # unfortunately I'm not familiar with those things. That sounds like linux things while I'm using W7 22.41.02 Quit p3tur (Quit: Leaving) 22.45.47 Join ulmutul [0] (~chatzilla@x5d835000.dyn.telefonica.de) 22.49.49 Quit petur (Quit: Leaving) 22.55.36 # in system-ypr0.c there is a mention to codepage but I don't understand what it does exactly 22.55.48 # strlcat(iocharset, get_current_codepage_name_linux(), sizeof(iocharset)); 22.57.45 Quit orpheu (Quit: Page closed) 22.58.40 Join orpheu [0] (0252b710@gateway/web/freenode/ip.2.82.183.16) 23.07.13 Quit djukon (Ping timeout: 240 seconds) 23.08.55 # strangely if I create a directory direclty from Rockbox with a name like "äß" it displays correctly, even after rebooting the device 23.09.18 Join djukon [0] (~djukon@50708323.static.ziggozakelijk.nl) 23.10.59 # but this directory doesn't display properly on Windows: äß 23.17.32 # the original firmware displays the names like Windows 23.18.05 # what's the codepage used by rockbox when you create a directory from the device? 23.24.33 Quit zoktar (Ping timeout: 240 seconds) 23.25.30 # jtdesigns01,pamaury: till now I thought my Fuze+ doesn't have a microphone (or some kind of hardware failure) :-S 23.25.31 # I never dug deeper, because it's not my "main" rockbox target :) Now I tried it out: the recording indeed is _very_ quiet (no signaling on the peak meter). There's no change in the recorded signal if I change the gain setting from -100dB to around +10dB. From ~+10dB things even get worse, as the left channel at once only contains noise. 23.26.18 # hum, maybe there was a regression 23.26.25 # it definitely worked at some point 23.27.09 # Or different hardware revisions 23.28.14 # possible, but iirc everything is controlled by the soc (ie not gpio) so I wouldn't expect a hardware revision to change anything here 23.28.26 # I never opened it, the outside says: "BI1010CBWK-8GB" (if this helps) 23.30.36 # I can try Rockbox 3.13 if it helps... 23.30.45 # no idea, to be honest since my fuze+ was stolen, I didn't buy a new one and the only other one I have has an almost dead battery 23.31.12 # (I should probably buy another one) 23.31.32 # you could try to bisect, or try an older version yeah 23.33.34 Join zoktar [0] (~zoktar@78-72-46-111-no186.tbcn.telia.com) 23.33.34 Quit zoktar (Changing host) 23.33.34 Join zoktar [0] (~zoktar@unaffiliated/zoktar) 23.36.20 Quit zoktar (Read error: Connection reset by peer) 23.38.16 # who would steal a Fuze+ 23.38.20 # poor stealer \o/ 23.38.44 # well he also stole my computer, my bag and more importantly my passport, that was last summer 23.39.20 # Can't find 3.13 for Fuze+, seems like I have to compile myself... 23.42.53 # http://www.rockbox.org/wiki/UsingGit#How_do_I_bisect_using_git_63 23.43.03 # and 3.13 doesn't make much sense 23.44.17 # you can start bisecting with a more recent dev build 23.49.45 # Does anyone know which version should be working? 23.50.52 Quit lebellium (Quit: ChatZilla 0.9.92 [Firefox 45.0/20160204142810]) 23.52.16 # ulmutul: I start by compilling a commit about one year old, see if it works 23.52.25 # Ok