| 00:01:48 | | Quit wodz (Quit: Leaving) |
| 00:02:08 | lebellium | from my understanding, there are no more Archos users among the active devs |
| 00:03:38 | lebellium | or they just keep a very old build because they think it's not worth upgrading anymore |
| 00:04:25 | saratoga_ | well it'd be nice to fork at the next release then |
| 00:04:29 | lebellium | but we still add some useful features on old players sometimes. Quite recently the Ondio FM got soft key lock |
| 00:05:45 | [Saint] | There's no reason to not go back and add features that won;t increase the binsize by any considerable amount. |
| 00:05:57 | [Saint] | ...but, there will also be no obligation for anyone to do so. |
| 00:06:27 | [Saint] | I'm all for forking out HW codec/charcell and applying only bugfixes and trivial features to that branch. |
| 00:07:13 | [Saint] | Leaving us the other targets to play with, without fear of breaking ancient, highly restrictive ports, would be very nice. |
| 00:07:55 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 00:08:25 | [Saint] | I *don't*, however, want to see them get forked out and then left to rot for all eternity...that would be a huge shame. |
| 00:09:16 | [Saint] | But in saying that, they've been kept on the brink of brokenness, only being massaged back into line occasionally for an age...so, I'm not sure if anything is really lost. |
| 00:14:54 | [Saint] | ...being perfectly honest, I think its something we all want, and don't want, simultaneously. No one wants to be the one to push the button, no one wants to be the one that is effectively killing ~13 years of Rockbox history. |
| 00:15:29 | [Saint] | But, in reality, perhaps euthanasia is better than dying of old age and neglect. |
| 00:15:42 | [Saint] | Gah...its a sad affair. |
| 00:17:09 | lebellium | hard decision to take so that means we're probably still be discussing that next year :) |
| 00:18:05 | [Saint] | I think I may have nailed it with "No one wants to be the one to push the button, no one wants to be the one that is effectively killing ~13 years of Rockbox history." |
| 00:18:34 | [Saint] | ...that's how I feel about it, at least. I imagine at least a few others feel similarly. |
| 00:19:29 | [Saint] | There would be a certain beauty, and cleanliness about it, if one of "The Originals" did it. |
| 00:19:47 | [Saint] | LinusN/Bagder/Zagor |
| 00:19:54 | n1s | Current builds of these ports don't see much use so they are already bit-rotting |
| 00:20:06 | [Saint] | Do we *know* that? |
| 00:20:12 | [Saint] | Or do we just have no reports? |
| 00:20:19 | lebellium | that's what I was saying above |
| 00:20:25 | lebellium | there are no download stats AFAIK |
| 00:20:31 | saratoga_ | bagder can probably get the download stats |
| 00:20:34 | saratoga_ | hes posted them before |
| 00:20:41 | [Saint] | That would be interesting. |
| 00:20:59 | [Saint] | (I wonder if it can also filter unique downloads) |
| 00:21:10 | n1s | [Saint]: last time o saw stats the archos builds were pretty low |
| 00:21:47 | [Saint] | Right. I wasn't necessarily saying you were wrong. I just didn't know if we know it for a fact, or if we just all felt that way. |
| 00:22:35 | saratoga_ | http://daniel.haxx.se/blog/2008/05/15/rockbox-downloads-april-2008/ |
| 00:22:39 | saratoga_ | for reference |
| 00:22:52 | kugel | that's almost six years ago :) |
| 00:22:56 | * | [Saint] doesn't see thos enumbers increasing. |
| 00:23:09 | [Saint] | It actually built then too. :) |
| 00:23:48 | n1s | yeah the downloads are sure to have dropped since the recorder stopped building... |
| 00:24:07 | * | [Saint] decides we should make the RSB do it |
| 00:24:25 | [Saint] | (do we actually have one, technically, or is it still the last lot since we didn;t renominate?) |
| 00:24:28 | saratoga_ | could still check releases |
| 00:24:53 | AlexP | I'd probably drop them at this point |
| 00:24:59 | n1s | but seriously, the low numbers + few reports from users + the fact that the majority of added features are not relevant/available on hwcodec |
| 00:25:11 | saratoga_ | can the build system handle two branches by the way? |
| 00:25:16 | AlexP | [Saint]: I guess it is still the last lot until the next election, whenever that might be |
| 00:25:21 | n1s | um, make the case as imo |
| 00:25:29 | [Saint] | AlexP: right, thanks. |
| 00:25:49 | AlexP | Which I think might include me now I think about it |
| 00:26:16 | [Saint] | ...sad as it may be, it does seem we've reached a consensus. We're all thinking the same way, well, almost. |
| 00:26:23 | AlexP | Unless there has been an election I didn't notice :) |
| 00:26:33 | saratoga_ | in terms of developers, who is actually dealing with hwcodec the most? personally none of this has much impact on me since the codecs dont' even build for hwcodec |
| 00:26:34 | [Saint] | But I think it would be best to go to the ML to let users have a say, and inform them. |
| 00:26:49 | saratoga_ | i guess kugel, jdgordon because of the theme engine and buffering |
| 00:26:51 | AlexP | saratoga_: I'm not sure anyone is |
| 00:26:55 | lebellium | I need to get a FM recorder and get g#497 merged before any support drop |
| 00:26:57 | fs-bluebot | Gerrit review #497 at http://gerrit.rockbox.org/r/497 : by Jean-Louis Biasini (changes/97/497/3) |
| 00:27:01 | [Saint] | Amiconn? |
| 00:27:09 | [Saint] | (2~3 years ago...) |
| 00:27:10 | AlexP | And those that are it isreally just if it inadvertently breaks |
| 00:27:18 | AlexP | And by breaks I mean doesn't build |
| 00:27:22 | AlexP | Not works :) |
| 00:27:39 | saratoga_ | g#497 can probably go in |
| 00:27:40 | fs-bluebot | Gerrit review #497 at http://gerrit.rockbox.org/r/497 : Add FM softlock to the fm recorder. by Jean-Louis Biasini (changes/97/497/3) |
| 00:27:49 | saratoga_ | unless theres some problem i'm not aware of? |
| 00:27:59 | [Saint] | How would we approach this, we we to handle it in the most transparent way possible? |
| 00:28:06 | [Saint] | *were we |
| 00:28:53 | lebellium | saratoga: I tested it for Ondio FM and it got merged. I guess Jean-Louis was just waiting for someone to test |
| 00:29:01 | [Saint] | I think once the descision has been made that that's the course of action that would inevitable follow, we would need to give the users and less active developers a chance to have a say? |
| 00:29:08 | [Saint] | Via the forum/ML? |
| 00:29:26 | AlexP | I don't think users et much of a say tbh |
| 00:29:27 | saratoga_ | lebellium: assuming it works fine, i can commit it now |
| 00:29:42 | [Saint] | AlexP: neither do I...but, we need to make them think they do. |
| 00:29:44 | n1s | [Saint]: i'd say bring it to the dev ml let it take enough time for people to think and reply and then perhaps let the rsb decide if no consensus is reached on the ml |
| 00:29:45 | [Saint] | :) |
| 00:29:52 | AlexP | But if you would like to try and reach a decision, the dev mailing list would be a good start |
| 00:30:01 | lebellium | saratoga: it works fine for Ondio FM but I can't say for FM recorder, although I don't see any reason why it would be different |
| 00:30:28 | AlexP | [Saint]: heh :) I don't see the point though, the odd person who uses it will say no, nobody else will care, and it won't influence any decision |
| 00:30:34 | AlexP | wrt the user ml that is |
| 00:30:59 | [Saint] | AlexP: n1s: I think the decision has been made already, and has been for some time, its just finalizing it really. |
| 00:31:04 | saratoga_ | actually can someone else push 497? i'm not near a machine with git in case it breaks something |
| 00:31:09 | [Saint] | I honestly don;t think any active dev is going to oppose this. |
| 00:31:58 | n1s | [Saint]: then reaching a consensus on the ml should be easy |
| 00:32:41 | [Saint] | AlexP: n1s: The main reason I thought it would at least be nice to include users in this decision is the vain hope I have that it might inspire someone to take up maintaining the branch once its forked. |
| 00:32:48 | AlexP | hah |
| 00:32:54 | [Saint] | ...I mean, you never know, and I feel I'd have to try before I put this to bed. |
| 00:33:02 | AlexP | Be my guest :) |
| 00:33:04 | [Saint] | However unlikely it is. |
| 00:33:32 | * | [Saint] is /sometimes/ an optimist, when it suits. :) |
| 00:34:04 | n1s | [Saint]: _optimist_ |
| 00:34:20 | [Saint] | Heh. |
| 00:35:00 | n1s | but sure, i wouldn't expect any constructive discussion but if you're willing... |
| 00:35:44 | | Quit ender` (Quit: I will not use any plan in which the final step is horribly complicated, e.g. "Align the 12 Stones of Power on the sacred altar then activate the medallion at the moment of total eclipse." Instead it will be more along the lines of "Push the button." --) |
| 00:36:26 | [Saint] | Wow...there's a quit message and a half. |
| 00:39:30 | | Quit kugel (Ping timeout: 260 seconds) |
| 00:49:33 | | Quit n1s (Quit: Ex-Chat) |
| 00:56:25 | *** | Saving seen data "./dancer.seen" |
| 01:00 |
| 01:15:40 | | Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 27.0/20140116125114]) |
| 01:23:18 | toehser | What is in the way of making Archos FM Recorder work? I have one I can either troubleshoot with or loan out. Not quite sure I want to permanently part with it, but I'm glad to ship it away for an extended period if it is really useful for development (and anyone cares...). Or I can use it to try to help fix the issues, if someone wants to help get me up to speed. Why would the HWCODEC be an issue, wouldn't the code for that "just keep working"? |
| 01:24:34 | gevaerts | toehser: the FM recorder is fine, it's the recorder that's troublesome |
| 01:25:09 | gevaerts | It's easy to get building again for a while, just find another feature to drop, but that's not a proper solution |
| 01:25:16 | toehser | I thought the FM Recorder was just the Recorder with the Tuner enabled? What was the FM Recorder minus FM called then? |
| 01:26:17 | gevaerts | The issue is that it's too big for the ROM bootloader, which can be solved by moving over to a bootloader / main firmware model like basically every other target |
| 01:26:39 | gevaerts | That shouldn't be *too* hard to do, but someone has to be motivated enough to do the work |
| 01:27:15 | toehser | I see, I'm thinking of the "Recorder 20". |
| 01:28:07 | [Saint] | Is there a bricking risk involved, gevaerts? If so, is there a recovery method? |
| 01:28:25 | gevaerts | No. It's about loading from disk |
| 01:28:39 | gevaerts | The other issue is that HWCODEC has a rather different playback engine which can cause issues sometimes, and which annoys people |
| 01:28:44 | toehser | So, it means writing a new bootloader for something that no-one uses... I see the problem. |
| 01:29:50 | toehser | If you fork it, it is dead, might as well just declare a version that is the 'last archos version', nobody is going to be fixing and working on it if you fork it... I agree with that. |
| 01:29:52 | gevaerts | And then of course there are things like a possible future new plugin loader that would allow neat stuff, which does include CPU architecture specific bits, where again Archos is different |
| 01:30:10 | gevaerts | And of course there's the Player with its charcell screen :) |
| 01:33:35 | gevaerts | toehser: I very much doubt if shipping devices to people will help here. People who care about the old Archoses usually have a few of them lying around |
| 02:00 |
| 02:01:58 | | Join nosa-j [0] (~m00k@66.233.224.206) |
| 02:06:24 | saratoga | should i keep closing fs tasks for AMS usb bugs or just let people keep making them |
| 02:06:31 | saratoga | i guess in theory they may be different issues |
| 02:26:23 | [Saint] | IS it known to be resolved now? |
| 02:26:42 | [Saint] | "the main one", that is. Themes randomly totally fucking USB. |
| 02:27:55 | * | JdGordon wouldnt shed a tear if we dropped charcell |
| 02:30:45 | [Saint] | You've been pretty impassioned on the subject in the past, perhaps you want to be the one to bring it up formally on the ML then? :) |
| 02:35:07 | saratoga_ | i don't think usb is fixed, but we already have a bunch of tasks open for it |
| 02:35:18 | [Saint] | ah, right. |
| 02:35:49 | [Saint] | we actually need to be thinking about freezing, RC builds, and a release. |
| 02:36:03 | [Saint] | We need AMS testers for git HEAD. |
| 02:36:21 | [Saint] | Specifically people that saw the theme/USB shennanigans. |
| 02:56:26 | *** | Saving seen data "./dancer.seen" |
| 02:58:49 | | Quit saratoga_ (Quit: Page closed) |
| 03:00 |
| 03:06:06 | | Quit Rower (Quit: Hmmm...) |
| 03:10:31 | | Join Strife89 [0] (~Strife89@adsl-98-80-237-249.mcn.bellsouth.net) |
| 03:47:35 | PurlingNayuki | Anyway git HEAD works fine on my AMSs. |
| 03:50:08 | [Saint] | PurlingNayuki: Don;t you use a unix host OS, though? |
| 03:50:35 | [Saint] | (It seems to be Windows specifically that has issues) |
| 03:54:16 | PurlingNayuki | I have Windows for games, Debian for working and study, and had OSX for music stuffs. |
| 03:55:51 | | Join draba [0] (~draba@s1106232.xgsspn.imtp.tachikawa.spmode.ne.jp) |
| 03:57:47 | toehser | USB to the internal storage seems to work fine for me now, but I've seen what seems like more issues to the card, I'll try that some... |
| 04:00 |
| 04:03:04 | [Saint] | I guess we just need to hear from lebellium, then. |
| 04:04:01 | [Saint] | His "samsunglike" theme is apparently an almost guaranteed way to scre up USB on AMS. |
| 04:04:10 | [Saint] | *screw up |
| 04:13:55 | PurlingNayuki | Why there's no lang APIs for plugins? |
| 04:42:57 | | Quit amiconn (Disconnected by services) |
| 04:42:57 | | Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) |
| 04:42:57 | | Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) |
| 04:42:57 | | Quit pixelma (Disconnected by services) |
| 04:42:58 | | Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) |
| 04:43:01 | | Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) |
| 04:50:38 | | Quit draba (Ping timeout: 264 seconds) |
| 04:54:34 | | Quit Strife89 (Ping timeout: 246 seconds) |
| 04:54:35 | | Join bitz [0] (~spencer@c-71-56-150-252.hsd1.wa.comcast.net) |
| 04:54:51 | | Quit bitz (Client Quit) |
| 04:56:27 | *** | Saving seen data "./dancer.seen" |
| 04:58:15 | | Join X2000 [0] (~spencer@c-71-56-150-252.hsd1.wa.comcast.net) |
| 05:00 |
| 05:04:58 | X2000 | Question: I'm running Liniux and am trying to build Rockbox form source. I can generate a makefile but every time I try to build it I get an error saying that a file called lang.h cannot be found. Google hasn't turned up any helpful results and I can't find the file anywhere in the Rockbox soure direcotry. Where do I get lang.h from? |
| 05:07:54 | [Saint] | Are you sure you meet the build requirements? That may cause odd issues I imagine. |
| 05:07:58 | [Saint] | one sec. |
| 05:08:14 | [Saint] | Apart from a base system, all we need should be "automake bison build-essential ccache flex libc6-dev libgmp3-dev libmpfr-dev libsdl1.2-dev libtool texinfo" |
| 05:09:02 | [Saint] | that's for binaries/simulator, manuals need slightly more. |
| 05:09:14 | X2000 | Yeah I already went through and installed all those while trying to run rockboxdev.sh |
| 05:09:49 | [Saint] | WHat target are you trying to build for? |
| 05:10:04 | X2000 | ipod video |
| 05:13:38 | [Saint] | working fine here. |
| 05:14:35 | [Saint] | WHat do you mean "while /trying/ to run rockboxdev.sh"? |
| 05:15:00 | [Saint] | That part is kinda critical, you need the armeabi toolchain, there's no avoiding it. It needs to suceed. |
| 05:15:57 | [Saint] | Also, is this a clean working checkout? |
| 05:16:22 | [Saint] | (if there are patches applied, which? can you build without them, have you checked?) |
| 05:16:36 | X2000 | every time I tried to run it, it would say cnnot run without (package), I installed the package it asked for and repeated until it ran sucesfully |
| 05:17:51 | [Saint] | massaging a base system until a toolchain builds doesn;t necessarily mean you have all required components to build Rockbox binaries proper. |
| 05:18:12 | X2000 | I'm trying to start work on a plugin I have in mind. right now I'm just trying to build an unmodified version of the source form git |
| 05:18:34 | [Saint] | If you haven't done so expressly, I would recommend "sudo apt-get install automake bison build-essential ccache flex libc6-dev libgmp3-dev libmpfr-dev libsdl1.2-dev libtool texinfo" |
| 05:19:00 | [Saint] | Or pacman, or yum, or aptitude...whatever floats your boat. |
| 05:19:28 | X2000 | thank you apperently build essential wasn't installed. I'll try it now. |
| 05:20:26 | X2000 | nope same error |
| 05:21:09 | [Saint] | make veryclean in the build directory, then reconfigure and try again. |
| 05:21:41 | [Saint] | that is the command "make veryclean", and then rerunning configure for the target. |
| 05:22:15 | X2000 | seems to be working. Thank you so much |
| 05:22:22 | [Saint] | Not a problem. |
| 05:25:20 | PurlingNayuki | Is FS #12074 fine to commit? Though we can't detect lineout, it's still possible to let users to choose. |
| 05:25:20 | fs-bluebot | http://www.rockbox.org/tracker/task/12074 Add setting to enable/disable lineout on Sansa Fuze V2 (patches, unconfirmed) |
| 05:25:44 | | Part X2000 ("Konversation terminated!") |
| 05:28:04 | [Saint] | Comment by MichaelGiacomelli (saratoga) - Monday, 03 December 2012, 15:49 GMT |
| 05:28:04 | [Saint] | Hi Rawl, |
| 05:28:04 | [Saint] | We won't be including this in the main build until someone reverse engineers the mechanism for detecting if a line out dock is connected. |
| 05:28:42 | [Saint] | The setting hijacked here also isn't appropriate. |
| 05:28:59 | [Saint] | That setting is used to *power off* the lineout feature, not to switch to or from it. |
| 05:38:20 | PurlingNayuki | ..Oops |
| 05:38:30 | PurlingNayuki | New settings? |
| 05:38:42 | PurlingNayuki | Should a new setting be added? |
| 05:39:19 | [Saint] | Argh. Its hard to tell, but the last two lines there are from myself, no from the comment. |
| 05:39:22 | PurlingNayuki | Why auto detect is needed to add this to main build? |
| 05:39:51 | toehser | I haven't gotten a USB related failure for a long time... maybe it is fixed. |
| 05:40:04 | [Saint] | Anyway, I'm not sure that would help matters. As using a new setting doesn't seem to help the fact that there was opposition to this until such time as the line out state could be detected. |
| 05:41:07 | [Saint] | Autodetecting of the lineout state is the way its handled on every other target we can use the lineout on, as far as I know. |
| 05:41:45 | [Saint] | ANd the only lineout related setting is for disabling lineout completely (potentially saving battery). |
| 05:42:35 | [Saint] | It would seem weird to handle it different for one particular target. And it would inevitably lead to situations where the user forgets which output is enabled and wonders why one or the other won't work. |
| 05:42:36 | PurlingNayuki | Currently we set the AMS lineout to powered off IIUC. |
| 05:43:16 | PurlingNayuki | Nope. They set this themselves so they will remember. |
| 05:43:22 | PurlingNayuki | Just like volume cap. |
| 05:43:29 | [Saint] | Unfortunately, that's not how users work. |
| 05:43:58 | [Saint] | At least the volume cap provides some form of visual hint due to the reduced maximum volume. |
| 05:44:50 | toehser | Why doesn't "backdrop: -" in the theme cfg file always clear the backdrop from a previous theme? Is there some other way to clear it? |
| 05:44:50 | [Saint] | You could certainly try to get this patch included (with a new setting), but I think it would just hit the same wall as it did initially. |
| 05:45:22 | [Saint] | toehser: it _should_. |
| 05:45:28 | [Saint] | Not doing so is a bug. |
| 05:45:31 | toehser | doesn't though |
| 05:45:34 | toehser | reproducable |
| 05:45:53 | [Saint] | You know what to do. :) |
| 05:47:37 | | Join danielf [0] (~danielf@c-71-202-175-244.hsd1.ca.comcast.net) |
| 05:50:18 | | Quit danielf (Client Quit) |
| 05:50:38 | | Join danielf [0] (~danielf@c-71-202-175-244.hsd1.ca.comcast.net) |
| 05:50:56 | | Nick danielf is now known as qsylalyn (~danielf@c-71-202-175-244.hsd1.ca.comcast.net) |
| 05:53:54 | | Quit qsylalyn (Client Quit) |
| 05:54:59 | | Quit TheSeven (Disconnected by services) |
| 05:55:13 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
| 06:00 |
| 06:00:44 | toehser | k. I filed a bug. Weird thing: Load cabbiev2 theme, then tomsway2: backdrop cleared. Load 3_eyed_jack theme, then tomsway2: backdrop not cleared. |
| 06:14:52 | toehser | For that matter, load 3_eyed_jack, then load cabbiev2, backdrop stays 3_eyed_jack. |
| 06:39:43 | | Join leftright [0] (c5e01404@gateway/web/freenode/ip.197.224.20.4) |
| 06:40:49 | leftright | H140: Bug; latest dev build still exhibits the following bug, FS #12769 - rb 3.12 |
| 06:40:50 | fs-bluebot | http://www.rockbox.org/tracker/task/12769 rb 3.12 - iriver H140 bootloader crash: 1st boot fails, Reset pin, 2nd boot Successful. Repeatable. (bugs, unconfirmed) |
| 06:54:55 | PurlingNayuki | [Saint]: Reset lineout after reboot should be fine to users. |
| 06:55:23 | PurlingNayuki | If they find no phone output most of they will try rebooting first. |
| 06:55:39 | [Saint] | I'm not sure we have any user settings that are gleefully ignored on a reboot. |
| 06:55:48 | [Saint] | That seems..rather disgusting. |
| 06:56:14 | [Saint] | Well, not just ignored, *reset*. |
| 06:56:28 | *** | Saving seen data "./dancer.seen" |
| 06:56:56 | [Saint] | Nothing should ever do that in our current system, and I don't think anything does, because its kinda hideous. |
| 06:58:25 | [Saint] | This is why it kinda needs to detect the lineout state, so it "Just Works". |
| 07:00 |
| 07:13:06 | | Quit leftright (Quit: Page closed) |
| 07:24:34 | PurlingNayuki | Actually there is. |
| 07:24:59 | PurlingNayuki | Sleep timer does that in fact, they will be reset on every boot. |
| 07:54:13 | | Nick SuperBrainAK is now known as DormantBrain (~andy@2001:470:8:a61::5f92:59a1) |
| 07:55:23 | | Join Gallomimia_ [0] (~gallomimi@99.199.8.77) |
| 08:00 |
| 08:05:36 | | Join draba [0] (~draba@s1106097.xgsspn.imtp.tachikawa.spmode.ne.jp) |
| 08:24:34 | | Join Unhelpful_ [0] (~quassel@rockbox/developer/Unhelpful) |
| 08:24:40 | | Join KiwiCAM_ [0] (~quassel@121.99.184.8) |
| 08:24:50 | | Join Mir_ [0] (~Mir@pool-71-109-219-225.lsanca.dsl-w.verizon.net) |
| 08:25:53 | | Quit zoktar (Ping timeout: 264 seconds) |
| 08:25:53 | | Quit albb0920 (Ping timeout: 264 seconds) |
| 08:25:53 | | Quit ladyblink (Ping timeout: 264 seconds) |
| 08:25:53 | | Quit gelraen (Ping timeout: 264 seconds) |
| 08:25:54 | | Quit Mir (Ping timeout: 264 seconds) |
| 08:25:54 | | Quit pystar89 (Ping timeout: 264 seconds) |
| 08:25:54 | | Quit ranmachan (Ping timeout: 264 seconds) |
| 08:25:59 | | Join gelraen [0] (~imax@lab.biomed.kiev.ua) |
| 08:26:01 | | Join zoktar [0] (~zoktar@78-72-44-158-no186.tbcn.telia.com) |
| 08:26:02 | | Quit kiwicam (Ping timeout: 264 seconds) |
| 08:26:03 | | Quit Unhelpful (Ping timeout: 264 seconds) |
| 08:26:03 | | Quit froggyman (Ping timeout: 264 seconds) |
| 08:26:03 | | Quit zoktar (Changing host) |
| 08:26:03 | | Join zoktar [0] (~zoktar@unaffiliated/zoktar) |
| 08:26:10 | | Join ranmachan [0] (ranma@kagami.uguu.de) |
| 08:26:13 | | Nick Mir_ is now known as Mir (~Mir@pool-71-109-219-225.lsanca.dsl-w.verizon.net) |
| 08:26:46 | | Join ladyblink [0] (bassgeisha@selectah.drop.that.bass.aikyou.bassgeisha.com) |
| 08:32:15 | | Join froggyman [0] (~frogs@unaffiliated/froggyman) |
| 08:45:03 | | Join albb0920 [0] (~albb0920@140.115.83.1) |
| 08:45:39 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 08:48:41 | | Join danielf [0] (~danielf@c-71-202-175-244.hsd1.ca.comcast.net) |
| 08:48:58 | amiconn | gevaerts: While moving over to a bootloader model as such isn't difficult, it's a bit more involved to make it work for both flashed and non-flashed install, and to make sure the flash image transition is safe |
| 08:50:36 | amiconn | That means each model should be thoroughly tested. I do have access to Player, Recorder, Ondio SP and Ondio FM, but not FM Recorder and Recorder v2. The last two are identical apart from the model flag though, so having access to either one should be sufficient |
| 08:51:43 | amiconn | In theory, one should also test with bootrom and non-bootrom variants, but I never came across one of the latter |
| 08:51:58 | amiconn | [IDC]Dragon did, but he's not been around for years |
| 08:52:23 | | Quit danielf (Client Quit) |
| 08:52:43 | | Join danielf [0] (~qsylalyn@c-71-202-175-244.hsd1.ca.comcast.net) |
| 08:53:08 | | Nick danielf is now known as qsylalyn (~qsylalyn@c-71-202-175-244.hsd1.ca.comcast.net) |
| 08:55:35 | | Quit [Saint] (Remote host closed the connection) |
| 08:56:30 | *** | Saving seen data "./dancer.seen" |
| 08:57:15 | | Quit qsylalyn (Client Quit) |
| 08:57:33 | | Join qsylalyn [0] (~qsylalyn@c-71-202-175-244.hsd1.ca.comcast.net) |
| 08:57:42 | | Join [Saint] [0] (~saint@rockbox/staff/saint) |
| 09:00 |
| 09:08:58 | | Quit qsylalyn () |
| 09:09:11 | | Join pretty_function [0] (~sigBART@123.252.214.163) |
| 09:09:13 | | Join qsylalyn [0] (~qsylalyn@c-71-202-175-244.hsd1.ca.comcast.net) |
| 09:10:15 | | Quit qsylalyn (Remote host closed the connection) |
| 09:10:26 | PurlingNayuki | Anyway to upgrade Clip zip's firmware from 01.20.21 to 01.20.21? |
| 09:10:49 | | Join qsylalyn [0] (~qsylalyn@c-71-202-175-244.hsd1.ca.comcast.net) |
| 09:11:23 | [Saint] | PurlingNayuki: Why would you? |
| 09:11:56 | PurlingNayuki | I modified the bootloader a little to adapt my using habit |
| 09:12:41 | PurlingNayuki | I was on 01.20.21 already before and I use the same version to patch bootloader, rename it to clzpa.bin and put it in the root |
| 09:13:09 | PurlingNayuki | But after disconnect the USB it just goes to update database, no firmware upgrading. |
| 09:14:34 | | Join rela [0] (~x@pdpc/supporter/active/rela) |
| 09:15:23 | * | PurlingNayuki is trying to flash the OF back and rockbox it again. |
| 09:16:45 | [Saint] | As far as I am aware, the firmware shouldn;t care if it is updating to the same, or lesser, version. |
| 09:17:09 | PurlingNayuki | Oops I know the reason why |
| 09:17:41 | PurlingNayuki | Stupid me, the file name should be clpza rather than clzpa |
| 09:30:25 | | Quit qsylalyn () |
| 09:39:51 | | Join sprout_n1w [0] (~Rob@180.168.176.99) |
| 09:43:50 | | Quit Gallomimia_ (Read error: Connection reset by peer) |
| 09:44:37 | | Join Gallomimia_ [0] (~gallomimi@99.199.8.77) |
| 10:00 |
| 10:01:10 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 10:06:01 | | Quit sprout_n1w (Quit: leaving) |
| 10:19:47 | | Quit [Saint] (Remote host closed the connection) |
| 10:21:49 | | Join [Saint] [0] (~saint@rockbox/staff/saint) |
| 10:29:08 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 10:32:45 | | Join pystar89 [0] (~pystar89@ip-109-90-154-150.unitymediagroup.de) |
| 10:44:07 | Baranko | updated my usb ticket |
| 10:44:23 | Baranko | connecting clip+ while turned off - sansa connects as usb1.0 ) |
| 10:44:38 | Baranko | linux case. |
| 10:44:47 | Baranko | win7 all fine with it. |
| 10:53:31 | | Quit rela (Read error: Connection reset by peer) |
| 10:56:34 | *** | Saving seen data "./dancer.seen" |
| 10:58:37 | | Quit draba (Ping timeout: 252 seconds) |
| 11:00 |
| 11:04:48 | | Quit pretty_function (Remote host closed the connection) |
| 11:26:47 | | Join Rower [0] (husvagn@90-230-142-55-no41.tbcn.telia.com) |
| 12:00 |
| 12:13:24 | | Quit Gallomimia_ (Quit: Gallomimia_) |
| 12:19:31 | gevaerts | Baranko: for the record, full speed is still usb 2.0, and there are *very* few 1.0 devices around (1.1 is much more common) :) |
| 12:21:24 | [Saint] | I don't think I remember the last time I saw 1.0 in the wild. |
| 12:21:32 | [Saint] | (in use) |
| 12:21:45 | copper | [Saint]: mice and keyboards |
| 12:23:53 | [Saint] | Not mine, that's certain. |
| 12:24:04 | gevaerts | copper: 1.*0*? |
| 12:24:06 | gevaerts | 1.1, sure |
| 12:24:25 | [Saint] | even that's fading out. |
| 12:24:42 | copper | ah |
| 12:24:58 | gevaerts | 1.1 was basically a bugfix release. There's not been any good reason to ever use 1.0 since 1.1 was released |
| 12:26:19 | gevaerts | And the step from 1.1 to 2.0 for low and full speed devices is also reasonably small. You need to change the version number, and I think you may need an extra descriptor, but that's more or less it |
| 12:26:43 | | Join rela [0] (~x@pdpc/supporter/active/rela) |
| 12:27:02 | [Saint] | Its quite confusing at first. |
| 12:27:08 | gevaerts | Of course, for a mouse or something like that, that might mean having to update firmware that's been fine since 1998 and isn't actually broken, so why bother? :) |
| 12:28:48 | gevaerts | [Saint]: it's fairly straightforward now, but once we have superspeed devices we'll have to explain that while full speed *is* usb 2.0, high speed is not USB 3.0 :) |
| 12:30:21 | [Saint] | "full speed" was rather short sighted, I guess. :) |
| 12:30:49 | gevaerts | so was high speed, for that matter :) |
| 12:30:57 | bertrik | there's plenty of room beyond full speed, like super, hyper, ultra, etc. :) |
| 12:31:09 | gevaerts | "Fuller speed" and "Fullest speed" would have been better |
| 12:31:10 | [Saint] | über |
| 12:31:40 | copper | well |
| 12:31:56 | copper | since we're currently at "super speed", I assume USB 4.0 will be "mega speed" |
| 12:32:15 | [Saint] | we could shorten it to ÜSB |
| 12:32:18 | gevaerts | copper: we can't know! |
| 12:32:29 | copper | [Saint]: haha, nice |
| 12:32:33 | gevaerts | It may be mega speed, or it may be super speed *or* mega speed! |
| 12:32:36 | copper | I would totally vote for that |
| 12:32:58 | gevaerts | We don't know if they'll refer to the 3.0/2.0 specs for lower speeds or include them in the 4.0 spec |
| 12:33:39 | [Saint] | "fuller than full speed but not quite the fullest speed" |
| 12:33:56 | [Saint] | ...has a ring to it. |
| 12:50:09 | | Join leftright [0] (c5e01404@gateway/web/freenode/ip.197.224.20.4) |
| 12:51:47 | leftright | hi. Is mr. Someone perhaps reviewing this bug FS #12769. if not please update the falsh web page stating that flash only works up to v3.8 |
| 12:53:13 | leftright | thats on the H1xx series |
| 12:53:53 | | Quit leftright (Client Quit) |
| 12:56:38 | *** | Saving seen data "./dancer.seen" |
| 13:00 |
| 13:03:07 | | Join mortalis [0] (~mortalis@77.108.98.176) |
| 13:08:43 | [Saint] | Oh. That was cute. |
| 13:09:12 | | Quit rela (Read error: Connection reset by peer) |
| 13:09:47 | [Saint] | I think it might take a /wee/ bit longer than expected. |
| 13:21:30 | | Join arcolight [0] (5c6414a3@gateway/web/freenode/ip.92.100.20.163) |
| 13:27:00 | arcolight | Hello. I have a question about rockbox utility and packaging for Debian. I've read on official site, that there are no official packages for different linux distributions. I'm using Debian stable and I want to install rbutil as package. If i want to creaqte deb-package, should I create build scripts and send them to developers or they don't interested in this and I should only created package and post them on official site? |
| 13:27:23 | arcolight | Sorry for my English, it's not my native language. |
| 13:30:17 | | Join juda [0] (~brakha@2a01:e34:ee9a:fc30:5ceb:3c55:afaf:953f) |
| 13:30:25 | juda | bonjour |
| 13:30:50 | juda | j'aurais voulu avoir plus d'information sur rockbox et mon lecteur mp3 |
| 13:31:33 | juda | et si c'est possible d'effectuer le changement, comment on fait sur linux? |
| 13:34:06 | copper | juda: do you speak english? |
| 13:34:24 | juda | okay |
| 13:34:39 | copper | what is your MP3 player? |
| 13:34:58 | juda | memup |
| 13:35:29 | | Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) |
| 13:35:30 | copper | it's not supported by Rockbox, sorry |
| 13:35:58 | juda | okay |
| 13:38:13 | | Part arcolight |
| 13:38:50 | | Join arcolight [0] (~arcolight@ppp92-100-20-163.pppoe.avangarddsl.ru) |
| 13:41:07 | [Saint] | arcolight: as long as you conform to the license requirements, you can do whatever you want. |
| 13:55:08 | | Join eyfour [0] (~eyfour@176.76.202.84.customer.cdi.no) |
| 13:58:20 | | Quit eyfour (Client Quit) |
| 13:58:26 | | Quit arcolight (Quit: Konversation terminated!) |
| 13:59:33 | | Join arcolight [0] (~arcolight@ppp92-100-20-163.pppoe.avangarddsl.ru) |
| 14:00 |
| 14:02:51 | | Join eyfour [0] (~eyfour@176.76.202.84.customer.cdi.no) |
| 14:03:11 | | Part eyfour |
| 14:13:21 | | Quit ikeboy (Quit: ikeboy) |
| 14:13:53 | | Part arcolight ("Konversation terminated!") |
| 14:24:03 | | Join y4n [0] (~y4n@unaffiliated/y4ndexx) |
| 14:26:16 | Baranko | gevaerts: at all, i don't remember which of them right |
| 14:26:37 | Baranko | i see that speed musch differs and dmesg shows that now it's only full speed |
| 14:26:49 | Baranko | and want's to be connected to high speed |
| 14:29:01 | | Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) |
| 14:33:07 | | Join lebellium [0] (~chatzilla@194.240-65-87.adsl-dyn.isp.belgacom.be) |
| 14:36:05 | | Quit ikeboy (Quit: ikeboy) |
| 14:45:57 | | Join Strife89 [0] (~Strife89@adsl-98-80-237-249.mcn.bellsouth.net) |
| 14:49:41 | [Saint] | I can create the same effect by connecting an iPod Video while the disk is spinning. |
| 14:56:41 | *** | Saving seen data "./dancer.seen" |
| 15:00 |
| 15:17:18 | | Quit lebellium (Ping timeout: 252 seconds) |
| 15:21:24 | | Join lebellium [0] (~chatzilla@194.240-65-87.adsl-dyn.isp.belgacom.be) |
| 15:41:51 | | Quit Strife89 (Ping timeout: 252 seconds) |
| 15:52:29 | | Part juda ("Quitte") |
| 16:00 |
| 16:05:11 | | Join kugel [0] (~kugel@91-64-116-250-dynip.superkabel.de) |
| 16:05:11 | | Quit kugel (Changing host) |
| 16:05:11 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 16:14:50 | kugel | does anyone know speex? |
| 16:19:05 | copper | It's a speech oriented audio codec, but that's not important right now. |
| 16:31:46 | kugel | copper: right |
| 16:31:56 | kugel | I've got a question on how to use it |
| 16:56:44 | *** | Saving seen data "./dancer.seen" |
| 17:00 |
| 17:10:08 | | Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 27.0/20140116125114]) |
| 17:11:01 | | Join lebellium [0] (~chatzilla@194.240-65-87.adsl-dyn.isp.belgacom.be) |
| 17:25:43 | Baranko | Looks like i found some dependencies. But as for me it looks very strange, |
| 17:25:43 | Baranko | Using linux box. |
| 17:25:44 | Baranko | If i insert card transcend 4gb 6 class and copy 3gb data into internal memory of player (sd memory mounted too, but not used) all goes fine. |
| 17:25:44 | DBUG | Enqueued KICK Baranko |
| 17:25:44 | Baranko | If i insert card transcend 32gb 10 class and copy 3gb data into internal memory of player (sd memory mounted too, but not used) all goes bad, sansa disconnects, hangs etc. |
| 17:26:10 | Baranko | don't know how it could be, but i reproduce it right here right now. |
| 17:35:54 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 18:00 |
| 18:04:29 | | Join krabador_ [0] (~krabador@host139-190-dynamic.41-79-r.retail.telecomitalia.it) |
| 18:04:46 | | Quit krabador (Ping timeout: 260 seconds) |
| 18:08:23 | | Quit krabador_ (Client Quit) |
| 18:10:24 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 18:11:21 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 18:16:39 | | Quit krabador (Quit: Sto andando via) |
| 18:17:46 | | Quit Baranko (Quit: Ухожу я от вас) |
| 18:23:34 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 18:30:06 | | Quit ParkerR (Ping timeout: 240 seconds) |
| 18:30:06 | | Quit habys (Ping timeout: 240 seconds) |
| 18:30:07 | | Quit Karrde (Remote host closed the connection) |
| 18:30:08 | | Join ParkerR [0] (ParkerR@withg.org) |
| 18:30:51 | | Quit ParkerR (Changing host) |
| 18:30:51 | | Join ParkerR [0] (ParkerR@unaffiliated/parkerr) |
| 18:35:06 | | Quit krnlyng (Ping timeout: 260 seconds) |
| 18:40:50 | | Join habys [0] (~luke@50.73.79.113) |
| 18:50:19 | | Join krabador_ [0] (~krabador@host246-184-dynamic.20-87-r.retail.telecomitalia.it) |
| 18:50:58 | | Quit mortalis (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) |
| 18:51:26 | | Quit krabador (Ping timeout: 260 seconds) |
| 18:56:48 | *** | Saving seen data "./dancer.seen" |
| 18:59:52 | | Quit uwe_ (Ping timeout: 252 seconds) |
| 19:00 |
| 19:00:45 | copper | HEAD no longer reads APEv2 tags (example file: https://outpost.fr/tmp/e5G.mpc ) |
| 19:00:51 | | Quit krabador_ (Quit: Sto andando via) |
| 19:01:12 | copper | well, sim doesn't read them |
| 19:01:16 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 19:01:56 | copper | and my actual Fuze+ craps out when trying to play some MPC files (playback stops) |
| 19:02:04 | copper | I've checked the integrity of my files |
| 19:10:41 | copper | hmmm |
| 19:10:52 | copper | the sims definitely don't read APEv2 tags |
| 19:10:56 | | Join uwe_ [0] (~uwe_@dslb-088-066-160-105.pools.arcor-ip.net) |
| 19:10:56 | copper | my Fuze+ does |
| 19:11:04 | copper | I'm trying to reproduce the playback issue |
| 19:13:44 | | Quit Rower (Ping timeout: 272 seconds) |
| 19:13:50 | copper | damn it |
| 19:13:57 | copper | works fine from the internal storage |
| 19:20:27 | copper | meh |
| 19:20:37 | copper | can't reproduce it either from the microsdxc card |
| 19:20:44 | copper | database fuck up maybe |
| 19:31:33 | | Quit krabador (Quit: Sto andando via) |
| 19:36:37 | | Join W00fer [0] (~W00fer@a80-101-149-96.adsl.xs4all.nl) |
| 19:37:01 | W00fer | Hello, someone here working on RK27XX port? I have some information I can share |
| 19:42:11 | copper | yup, database fuckup again |
| 19:42:28 | copper | and when the database is fucked up, "initializing" it from Rockbox doesn't help |
| 19:42:45 | copper | I know something's wrong when initializing the database takes a lot longer than usual |
| 19:42:51 | | Nick DormantBrain is now known as SuperBrainAK (~andy@2001:470:8:a61::5f92:59a1) |
| 19:42:57 | copper | the fix is to delete it completely and THEN initialize it |
| 19:43:05 | copper | delete the database files I mean |
| 19:47:05 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 19:57:24 | | Join Strife89 [0] (~Strife89@adsl-98-80-237-249.mcn.bellsouth.net) |
| 19:58:59 | | Join krnlyng [0] (~liar@83.175.90.24) |
| 20:00 |
| 20:19:19 | | Quit APLU (Ping timeout: 252 seconds) |
| 20:20:36 | | Quit uwe_ (Ping timeout: 272 seconds) |
| 20:25:40 | | Join Karrde [0] (alucard@karrde.kiserai.net) |
| 20:32:10 | | Join APLU [0] (~mulx@2a01:e34:ee29:12b0::10) |
| 20:33:20 | bertrik | n1s: looking forward to your opus improvements :) |
| 20:33:49 | | Quit Strife89 (Ping timeout: 264 seconds) |
| 20:34:26 | n1s | bertrik: i haven't really done anything this time around, just imported jmspeex' optimizations, so far |
| 20:35:02 | n1s | i think saratoga is planning to write some arm asm for the fft which should speed it up quite a bit i think |
| 20:36:58 | saratoga | yeah i have some asm working nicely for the pre-1.1 code |
| 20:37:08 | saratoga | its broken on the current git though, and i haven't had time to figure out why |
| 20:37:28 | saratoga | just simple stuff to help me remember armv4 :) |
| 20:37:42 | chrisjj | Is theer a way to erase the databse from the RB menus? |
| 20:38:19 | saratoga | yeah, the initialize database option erases and then rebuilds it from scratch i believe |
| 20:40:18 | chrisjj | Thanks. |
| 20:41:28 | saratoga | on a side note, i wonder if parts of the mdct could be shared between opus and our core mdct lib |
| 20:41:45 | saratoga | normally we can't use the mdct lib because opus uses non-power-of-2 transforms |
| 20:42:01 | saratoga | but i guesss the rotation code, which is actually fairly slow, could be made to work with both |
| 20:42:03 | | Join uwe_ [0] (~uwe_@dslb-088-066-160-105.pools.arcor-ip.net) |
| 20:42:08 | copper | saratoga: like I said, "initialize" doesn't always work as expected |
| 20:42:22 | copper | no idea why |
| 20:42:52 | copper | I've had that database re-initialization bug for a long time |
| 20:43:39 | copper | it's hard to reproduce, because one first has to cause the DAP to crap out when connected via USB |
| 20:43:53 | copper | and then I don't know what kind of "crapping out" causes the database bug |
| 20:44:27 | copper | does "initialize" really, physically delete all database files before rebuilding it? |
| 20:54:51 | saratoga | i'm not familiar with the code so i don't know for sure |
| 20:56:43 | copper | it calls remove() on database_idx.tcd and database_N.tcd |
| 20:56:51 | *** | Saving seen data "./dancer.seen" |
| 20:57:00 | copper | it doesn't seem to do anything with database.log, not sure that's relevant |
| 20:57:17 | copper | doesn't touch database.ignore either |
| 20:57:21 | saratoga | the database.log is only made if you ahve that debug option enabled |
| 20:57:30 | saratoga | database.ignore just tells the database not to scan that folder |
| 20:57:42 | saratoga | IIRC |
| 20:57:58 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 20:57:58 | * | gevaerts nods |
| 20:58:13 | gevaerts | database.ignore is not at all part of the database |
| 20:58:34 | pamaury | W00fer: I did some work on rk27xx but the main dev is wodz |
| 20:58:35 | gevaerts | Removing it on database cleanup would be a rather serious bug |
| 20:58:51 | gevaerts | It's similar to .nomedia on android and the like |
| 20:58:53 | pamaury | W00fer: he usually reads the logs |
| 20:59:00 | copper | then I don't know what's wrong |
| 21:00 |
| 21:03:03 | saratoga | perhaps a rebuild while the device is running triggers some bug that doesn't happen when its first booted? |
| 21:03:11 | saratoga | memory corruption perhaps? |
| 21:04:02 | copper | hmmm, I'm pretty sure I do reboot first, then connect via USB, then erase the files, unplug, reboot, initialize |
| 21:04:08 | copper | (so yeah) |
| 21:04:40 | copper | er |
| 21:04:50 | copper | I mean, I do all that, to make sure I don't run into the bug |
| 21:05:20 | copper | next time I'll try to think of making a copy of the screwy database files |
| 21:05:38 | copper | and upload them for one of you guys to analyze |
| 21:06:54 | copper | saratoga: does the main symptom ring any bells? "Initialize" that adds files a lot slower than normal. |
| 21:07:07 | copper | like 10 times slower |
| 21:07:21 | saratoga | no idea |
| 21:07:26 | saratoga | i don't know anything about the database |
| 21:11:46 | | Quit y4n (Quit: only amiga makes it possible) |
| 21:20:29 | | Quit APLU (Ping timeout: 272 seconds) |
| 21:24:40 | | Join APLU [0] (~mulx@2a01:e34:ee29:12b0::10) |
| 21:42:09 | kugel | saratoga, n1s: do you know a bit about speex? |
| 21:53:28 | * | [Saint] kinda expects saratoga to, for some reason. |
| 21:54:16 | | Join wodz [0] (~wodz@87-207-223-0.dynamic.chello.pl) |
| 21:54:28 | wodz | W00fer: yes? |
| 21:58:51 | saratoga | kugel: not really, preglow did most of the work on it when i first joined the project |
| 21:58:54 | saratoga | what did you want to know |
| 21:59:19 | kugel | saratoga: I want to feed talk clips in chunks to the speex decoder |
| 21:59:57 | saratoga | sorry i don't know much about that |
| 22:00 |
| 22:00:04 | saratoga | you want me to ask preglow ? |
| 22:01:27 | kugel | sure |
| 22:01:59 | kugel | I guess I need to align the chunks to frame/packet size but I don't know how to do that |
| 22:02:14 | saratoga | what are you ultimately hoping to do? |
| 22:02:58 | kugel | have the talk clips on buflib and copy the to-be-decoded data to a small static memory area |
| 22:03:33 | saratoga | where are tehy now? |
| 22:03:53 | kugel | on the audio buffer together with buffered audio data |
| 22:05:30 | kugel | a) I would like to decouple this and b) the clip cache scheme for lowmem is very inefficient |
| 22:06:13 | | Quit lebellium (Ping timeout: 264 seconds) |
| 22:06:48 | kugel | well, actually I pushed the part that decouples it |
| 22:07:37 | kugel | but to improve b) I would like to allocate clips individually with buflib (now there is one large alloc for all clips & thumbnails) |
| 22:10:03 | wodz | gevaerts: The guy is right about hd300 recovery after flashing bad bootloader. There are some catches but generally if the code doesn't crash too early it is possible to recover this way. |
| 22:10:48 | [Saint] | If its not a guaranteed method, though, gevaerts was right to say what he did. |
| 22:11:10 | | Join lebellium [0] (~chatzilla@194.240-65-87.adsl-dyn.isp.belgacom.be) |
| 22:11:42 | wodz | [Saint]: bootloader must be screwed in very sever way for this to not work |
| 22:12:16 | [Saint] | Right. But as long as its not a guaranteed method, its just as dangerous as the AMS recovery wiki page in my eyes. |
| 22:12:23 | wodz | [Saint]: I recovered like dozen times bootloader on MPIOs that way |
| 22:13:06 | wodz | [Saint]: Basically you have nothing to lose if you flash bad bootloader. The only alternative is to reflash with BDM |
| 22:14:44 | wodz | well, you can do hardcore things like swaping nor flash also :-) |
| 22:14:46 | [Saint] | Maybe I parsed it differently, but I read it as a Buzfeed post: "Find one weird HW recovery trick the MP3 fatcats DON'T WANT YOU TO KNOW!" |
| 22:15:05 | [Saint] | It just...I dunno, it made it seem like recovery was always trivial, and we just didn;t know it yet. |
| 22:15:18 | [Saint] | I think gevaerts was right to add some caution to it. |
| 22:17:04 | wodz | Yes and no. It *should* be documented as it allows to easily recover in most situations. No because I didn't know it is possible until I f*** up the bootloader on BDM enabled device and observed what is actually happening |
| 22:18:10 | [Saint] | I would have absolutely no problem with the information being added to the wiki if it came with a similar warning as the AMS unbrick page. |
| 22:18:17 | wodz | and it works ONLY because of checks in rockbox bootloader |
| 22:18:49 | W00fer | wodz hi |
| 22:18:51 | [Saint] | ie. "Not an exact science, may not work at all, the best advice is to flash known good code" |
| 22:19:01 | wodz | W00fer: hi |
| 22:19:03 | [Saint] | At your own risk, etc. |
| 22:19:12 | W00fer | i have bought a rk2706 player |
| 22:19:19 | W00fer | and extracted the firmware partition |
| 22:19:29 | W00fer | so if you are interested |
| 22:19:47 | W00fer | i'm doing now some inquiry about the characteristics of the firmware |
| 22:20:16 | W00fer | but i need some help as well to progress further |
| 22:20:33 | wodz | [Saint]: Do we encourage people to try random bootloaders or we STATE LOUD TO STICK WITH TESTED BUIKD== |
| 22:20:46 | wodz | s/BUIKD==/BUILD/ |
| 22:21:05 | W00fer | pamaury thanks |
| 22:21:11 | wodz | W00fer: What you want to know? |
| 22:21:23 | W00fer | i have seen your work on the tracker and read the logs where you stated rk27xx questions |
| 22:21:47 | W00fer | maybe it's better over pm wodz |
| 22:21:55 | | Join BobJonkman1 [0] (~BobJonkma@206-248-137-186.dsl.teksavvy.com) |
| 22:22:14 | wodz | W00fer: we usually keep discussion public |
| 22:22:15 | [Saint] | wodz: ...I, I'm not even sure why you're asking me that. |
| 22:22:38 | [Saint] | I thought for sure my intentions there are clear. |
| 22:23:36 | W00fer | okay then i'll try to ask it |
| 22:23:43 | W00fer | here |
| 22:23:51 | W00fer | would you like to have my firmware? |
| 22:23:55 | W00fer | for development |
| 22:24:03 | W00fer | questions |
| 22:24:15 | wodz | W00fer: I am not particularly interested. |
| 22:24:49 | W00fer | 1: how to update the firmware, as i have read that just overwriting the firmware partition and rebooting boots back to old 'stock' firmware |
| 22:25:07 | | Join Soukyuu [0] (~Soukyuu@p57B0DF79.dip0.t-ipconnect.de) |
| 22:25:09 | W00fer | 2: how to test rockbox safe, without messing with official firmware (it has SD slot) |
| 22:25:47 | W00fer | 3: is there anything i can do to post some info about my device so touchscreen controllers can be investigated? I have seen on the wiki that no info was present on chipsets of rk27xx players |
| 22:25:55 | W00fer | without opening that is |
| 22:26:27 | W00fer | 4: are there any safe scsi commands that do not brick my player for testing. I have some limited linux experience |
| 22:27:32 | W00fer | anyway: i tried some investigating with rk27 device manager and it identifies properly. Because i don't know C, nor make i cannot decompile/decompress rk27boot.bin as I have seen on various sites |
| 22:27:47 | W00fer | it's version 16.24, which is newer than on most information available |
| 22:27:51 | wodz | W00fer: The easiest way to test rockbox (or anything else) is to force the player into RKDFU mode and use rk27load to send arbitrary binary to the device. Unfortunately usually this involves opening the device. There is custom scsi command which in theory should force dfu mode but I it doesn't work on my device. |
| 22:28:09 | W00fer | uhm |
| 22:28:17 | W00fer | I have external RESET button |
| 22:28:29 | W00fer | if i press that with connecting |
| 22:28:34 | W00fer | does it set DFU mode? |
| 22:28:48 | W00fer | i have now the following: |
| 22:29:48 | wodz | W00fer: Don't know. You need to check. It should present itself as VID:PID 0x71b:0x3201 |
| 22:29:54 | W00fer | https://copy.com/2vxUhpfNVQFl |
| 22:30:00 | W00fer | i have 3203 |
| 22:30:08 | W00fer | but |
| 22:30:22 | W00fer | that is in normal mode, so not when service partition is opened. |
| 22:30:30 | W00fer | see screenshot |
| 22:31:11 | wodz | in rkdfu mode you don't get any drive |
| 22:31:16 | W00fer | ah |
| 22:31:38 | W00fer | any idea how to send the scsi command from windows? |
| 22:31:56 | W00fer | and how to proceed further? |
| 22:32:12 | W00fer | and does the binary overwrite the original firmware? |
| 22:32:33 | wodz | You can force this mode by shorting data pins of nand chip with some metal object and turning on in this state. This causes flash read fault and brings you rom rk dfu mode. |
| 22:32:56 | wodz | W00fer: sorry, I have 0 experience with windows |
| 22:33:17 | W00fer | hmmm |
| 22:33:23 | W00fer | the scsi command sounds better |
| 22:33:38 | W00fer | than opening a glued device |
| 22:34:29 | wodz | If scsi command works than good for you. The procedure with nand I outlined is bullet proof. |
| 22:34:40 | W00fer | where is it? |
| 22:34:45 | W00fer | the command? |
| 22:34:59 | W00fer | i can try it from ubuntu |
| 22:35:26 | wodz | http://git.rockbox.org/?p=rockbox.git;a=tree;f=utils/rk27utils/rkusbtool;h=ea7ba95a4fd42292ab050cc5bb20befc08ce6e59;hb=cc64d9eb3bb74e987093d59c6a4af4b7bc76076d |
| 22:35:42 | W00fer | that is a .c file |
| 22:35:53 | W00fer | how am i supposed to run that? |
| 22:35:53 | | Quit bluebrother (Read error: Connection reset by peer) |
| 22:36:17 | wodz | you need to compile |
| 22:36:27 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 22:36:36 | W00fer | yeah without knowledge of the whole toolchain |
| 22:36:41 | W00fer | never compiled software myself |
| 22:38:44 | | Quit fs-bluebot (Ping timeout: 248 seconds) |
| 22:39:51 | | Join thomj [0] (~thomj@2001:840:4243:3::100) |
| 22:39:54 | BobJonkman1 | Hi all: I have a Sansa Fuze+ that used to run Rockbox fine. But now it won't boot, either Rockbox or the original firmware (VolDown+Power). Just plugging in USB shows "Boot version: 1.0" on the screen and I can access storage just fine, and I can still save files which remain after unplugging-replugging (so it's not the dead internal storage problem). Reset (hold Power for 20sec) doesn't do anything. Recovery mode (VolUp+USB plugin |
| 22:39:57 | | Nick thomj is now known as preglow (~thomj@2001:840:4243:3::100) |
| 22:40:05 | | Join fs-bluebot [0] (~fs-bluebo@g224236191.adsl.alicedsl.de) |
| 22:41:08 | [Saint] | BobJonkman1: have you tried simply copying an unmodified firmware image to the root of starage and then ejecting? |
| 22:41:15 | [Saint] | *storage, even |
| 22:41:36 | BobJonkman1 | [Saint]: "starage" sound like it would be a cool thing to have |
| 22:42:10 | BobJonkman1 | [Saint]: Haven't tried copying manually, but there's a firmware.sb file in the root now. Hang on, will try again. |
| 22:44:26 | [Saint] | Using a unix-like OS, it is possible to force the decive into a low level SoC based recovery mode and pass a firmware image to it to execute. |
| 22:44:27 | preglow | kugel: i don't quite understand what you're trying to do wrt speex |
| 22:44:54 | wodz | W00fer: The upgrade process, outlined in manual you emailed me, uses special type of .rkw file. It is not the same as the BASE.RKW you have in SYSTEM folder on hidden drive. |
| 22:44:59 | [Saint] | From there, you /may/ be able to restore the device using its own repair/format capabilities in the OF. |
| 22:45:11 | [Saint] | see: http://www.rockbox.org/wiki/SansaFuzePlus#Recovery_mode |
| 22:45:25 | [Saint] | But someone will almost certainly have to walk you through it. |
| 22:45:27 | pamaury | BobJonkman1: is the battery completely discharged ? Maybe that why you can't boot |
| 22:45:31 | BobJonkman1 | [Saint]: Nope, the Fuze+ still won't boot with a fresh firmware.sb in root |
| 22:45:42 | [Saint] | BobJonkman1: pamaury is the man to talk to here. |
| 22:45:49 | kugel | let's say I have a voice clip of 1.5K. I want to copy the first 1K to a spare area and decode from that. Then I want to copy the rest (0.5K) to the same spare area and deocde the remaining bytes |
| 22:45:49 | pamaury | try to plug the device in OF USB mode (hold volume down when plugging usb) |
| 22:45:52 | [Saint] | You;re very lucky he's here. :) |
| 22:45:53 | kugel | preglow: ^ |
| 22:46:07 | BobJonkman1 | pamaury: Possible. It's been plugged in for hours, so possibly the battery isn't holding a charge |
| 22:46:09 | W00fer | ah you are the same guy of the e-mail |
| 22:46:14 | W00fer | didn't knew that |
| 22:46:25 | pamaury | BobJonkman1: bootloader 1.0 of Rockbox doesn't charge, only version 2.0 does |
| 22:46:28 | preglow | kugel: sure, sounds sane :> |
| 22:46:42 | W00fer | yup that .rkw file is the one I don't have |
| 22:46:43 | pamaury | you should probably update to the newest bootloader |
| 22:47:12 | kugel | preglow: I don't know how to do that properly :) |
| 22:47:29 | W00fer | any way I can assemble a .rkw from that hidden partition myself? |
| 22:47:41 | kugel | with the naive implementation the decoder errors out on the second chunk |
| 22:47:42 | preglow | kugel: well, as long as your buffer size is always larger than the minimum speex frame size, it should just be a matter of copying and decoding |
| 22:47:56 | preglow | if i remember correctly, we do variable size frames by default, tho |
| 22:48:07 | BobJonkman1 | pamaury: Hmmm... How to charge it then? Use an external power adapter instead of the computer's USB? |
| 22:48:31 | [Saint] | [10:45:51] <pamaury> try to plug the device in OF USB mode (hold volume down when plugging usb) |
| 22:48:55 | wodz | W00fer: In theory yes. I didn't try however. I am not aware of any tool to do this so you would need to write one first. |
| 22:48:57 | gevaerts | wodz: hmmm, I somehow read that as h300, not hd300. Feel free to delete my comment (I can't right now) |
| 22:49:17 | [Saint] | Oh...holy crap. |
| 22:49:22 | [Saint] | I did the same thing. |
| 22:49:27 | [Saint] | wodz: gevaerts: ^ |
| 22:49:35 | [Saint] | (sorry wodz :'( ) |
| 22:49:40 | BobJonkman1 | pamaury, [Saint]: Plugged in with VolDown, nothing happens. |
| 22:49:53 | wodz | gevaerts: you read it right BUT the mode works the same. |
| 22:50:10 | wodz | gevaerts: Its just how coldfire bootloaders work |
| 22:50:15 | [Saint] | Ah. |
| 22:50:25 | W00fer | wodz do you have any experience with the rk27 sdk? |
| 22:50:27 | kugel | preglow: what I'm seeing is that the decoder attempts to deocde the whole buffer regardless of frame/packet size (1024 bytes) and sets the overflow bit |
| 22:50:31 | W00fer | since it is available |
| 22:50:33 | BobJonkman1 | pamaury [Saint]: Ah, a few seconds later it shows the "Boot version: 1.0" screen, and connects as storage device |
| 22:50:57 | pamaury | BobJonkman1: are you running Linux or Windows ? |
| 22:51:02 | kugel | reading some docs I think that's because we don't insert terminators into the talk clips so it must decode the clip at once? |
| 22:51:07 | BobJonkman1 | pamaury: Linux |
| 22:51:13 | [Saint] | I totally forgot about the 1.0 bootloader not charging |
| 22:51:23 | preglow | kugel: maybe it does :> i think mike sevakis had to deal with most of that side of things |
| 22:51:25 | * | [Saint] should probably stick to the devices he knows well |
| 22:51:26 | wodz | W00fer: I know it quite well but never attempted to actually build the code. I use it as a reference only (as a last resort) |
| 22:52:02 | W00fer | hmm |
| 22:52:07 | pamaury | BobJonkman1: 32 or 64-bit ? |
| 22:52:09 | n1s | kugel: sorry i don't really know anything relevant about it |
| 22:52:18 | W00fer | doesn't bring me much further after all |
| 22:52:25 | W00fer | still my question holds |
| 22:52:30 | W00fer | if i can set it in DFU moe |
| 22:52:31 | W00fer | mode |
| 22:52:43 | W00fer | am I able to safely run the rockbox code? |
| 22:53:09 | W00fer | there are reports that rk27 platform is "virtually unbrickable" |
| 22:53:17 | BobJonkman1 | pamaury: 64bit (Linux Mint 16, Petra, uname -a is "Linux zelazny 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux" |
| 22:53:23 | W00fer | but I don't want to take the chance |
| 22:54:05 | wodz | W00fer: You can try with the tool I pointed you out. You can safely run code in dfu mode. The platform is unbrickable in the sense that the worst you can end up is rom dfu mode :-) |
| 22:54:29 | pamaury | BobJonkman1: download https://www.dropbox.com/s/rc2gl8t3lm67gwd/sbloader_64 and https://www.dropbox.com/s/ya6k3sz46chhstd/firmware_fuzep_rb_v2.sb |
| 22:55:07 | W00fer | yeah |
| 22:55:17 | W00fer | but how to get out of dfu mode? |
| 22:55:22 | pamaury | when you are done, plug the device in recovery mode (by holding volume up), then (probably as root) run ./sbloader_64 <path to firmware_fuzep_rb_v2.sb> |
| 22:55:43 | pamaury | if it works correctly, it should show rockbox USB bootloader mode, but showing "2.0" instead and it should charge |
| 22:55:45 | kugel | preglow: :'( |
| 22:55:54 | wodz | W00fer: But the truth is that THERE IS NO ROCKBOX for your device. You would need to write drivers. |
| 22:56:18 | W00fer | hmm |
| 22:56:24 | wodz | W00fer: If you are lucky this will be tiny part probably but still. |
| 22:56:32 | W00fer | i suspected otherwise since the changelog |
| 22:56:39 | W00fer | and the status page |
| 22:56:45 | W00fer | with 100% greens |
| 22:56:49 | wodz | which status page? |
| 22:56:53 | *** | Saving seen data "./dancer.seen" |
| 22:56:58 | wodz | rk27generic? |
| 22:57:18 | preglow | kugel: where does the code decoding out of the audio buffer live these days? :) |
| 22:57:29 | wodz | this is for reference design (RM970 and clones) |
| 22:57:40 | W00fer | http://www.rockbox.org/wiki/Rockchip27xxPort |
| 22:58:11 | W00fer | maybe mine is a ramos clone |
| 22:58:12 | W00fer | after all |
| 22:58:24 | wodz | rm970 is not touchscreen |
| 22:58:25 | kugel | preglow: in talk.c it calls mp3_play_data(). this passes the (entire) voice clip to voice_thread.c |
| 22:59:00 | W00fer | touchscreen is just an add on |
| 22:59:05 | W00fer | extra chip |
| 22:59:10 | wodz | W00fer: You could reuse most of the code but I bet there are device specific part. |
| 22:59:14 | kugel | in voice_thread.c it initializes the deocder and sets the speex buffer to the one from mp3_play_data() |
| 22:59:32 | W00fer | is there any active rk27 development? |
| 23:00 |
| 23:00:11 | BobJonkman1 | pamaury: OK, downloaded. |
| 23:00:25 | wodz | W00fer: That depends what you mean by active. I play with the hardware from time to time but my spare time is limited. |
| 23:00:45 | pamaury | BobJonkman1: then run it as I explained |
| 23:00:54 | W00fer | are you the only developer for that platform? |
| 23:01:02 | | Join saratoga_ [0] (123e1c65@gateway/web/freenode/ip.18.62.28.101) |
| 23:01:09 | wodz | W00fer: basically yes. |
| 23:01:16 | BobJonkman1 | pamaury: OK, here goes. Thanx in advance! |
| 23:01:34 | preglow | kugel: code seems to assume all the data is contained in the bit buffer |
| 23:01:51 | W00fer | too bad, i would like to contribute as much as I can |
| 23:01:52 | saratoga_ | W00fer: if you're not into c programming, basically none of this matters to you since you won't be able to port anything to your device |
| 23:01:58 | preglow | kugel: which is assumed to be one contiguous area of mem |
| 23:02:16 | kugel | and what can I do to change this assumption? |
| 23:02:24 | W00fer | saratoga_ thanks for the comment |
| 23:02:25 | W00fer | but |
| 23:02:32 | preglow | kugel: havin a look now |
| 23:02:39 | W00fer | i'm just more than dumb end user |
| 23:03:15 | W00fer | i would like to contribute, sure I'll understand that you can't learn me do C in a day. But I know people that can, but don't have any rockbox experience |
| 23:04:01 | saratoga_ | i'd probably start with something much simpler if you want to learn c |
| 23:04:16 | W00fer | starts with, what can i do to help. |
| 23:04:18 | saratoga_ | most people learn to walk before they run |
| 23:04:33 | W00fer | i'm not talking coding, thank you |
| 23:04:41 | wodz | W00fer: The port for your device is doable but YOU need to take care of porting. I can share my knowledge about the platform but I don't have time to hack yet another random player. |
| 23:05:15 | W00fer | there is no "generic" rk27 build that i can execute to test and report results? |
| 23:05:22 | wodz | no |
| 23:05:39 | wodz | well, there is but I doubt it will work |
| 23:05:44 | W00fer | why |
| 23:05:55 | W00fer | because of touchscreen okay |
| 23:05:59 | saratoga_ | W00fer: i think you're a little confused about how porting works |
| 23:06:00 | kugel | preglow: cool |
| 23:06:09 | saratoga_ | you have to reverse engineer your device, then write device drivers for it |
| 23:06:15 | W00fer | i know that |
| 23:06:21 | saratoga_ | theres nothing to test until you've done that |
| 23:06:29 | | Quit toehser (Read error: Connection reset by peer) |
| 23:06:43 | W00fer | but since the platform is the same, and drivers are there (although from rm970) |
| 23:06:48 | kugel | preglow: as I said, I'm assuming we must include more terminators at encoding to make it not having to decode the whole buffer at once |
| 23:06:57 | kugel | but I may be wrong, I know nothing about speex |
| 23:07:18 | | Quit n1s (Quit: Ex-Chat) |
| 23:07:23 | preglow | naw, shouldn't need to do anything at encode |
| 23:07:30 | BobJonkman1 | pamaury: OK, result: "Cannot probe transfer size". I've read the sbloader −−help; is transfer size the filesize of the .sb file? |
| 23:07:59 | pamaury | no, did you run it as root ? |
| 23:08:03 | W00fer | but yeah, it might not work, but we didn't test it. Let's just say i think that rk27xxport on rockbox wiki then needs a name change to rm970port |
| 23:08:13 | W00fer | not to confuse people with rk27xx platform players |
| 23:08:13 | BobJonkman1 | pamaury: Yes, from a root shell |
| 23:08:18 | kugel | preglow: when I pass only part of the buffer the decoder returns with 0 at some point with the overflow bit set |
| 23:08:28 | kugel | and bits.charPtr is set to the last byte |
| 23:08:32 | pamaury | hum, then try to specify the transfer size: it should be 1024 |
| 23:08:34 | W00fer | as it only works on that specific player |
| 23:08:42 | pamaury | iirc the option is "-x 1024" |
| 23:08:54 | wodz | W00fer: The rk27xx part is universal (more or less) but then there are 1000000 ways to hook up additional hardware. Different ways to connect buttons, different lcd controllers, etc |
| 23:08:59 | BobJonkman1 | pamaury: OK, will do. |
| 23:09:43 | W00fer | so why is it being reported then as universal platform, as only 1 player will work and most probably none of the other players |
| 23:10:07 | W00fer | and never will |
| 23:10:11 | BobJonkman1 | pamaury: Aha! Response: "Status passed", and the device rebooted. Still says "Boot version: 1.0" tho |
| 23:12:36 | wodz | W00fer: Sorry but you don't understand the basics of electronic design then. You start from generic (reference) design and add your stuff. This port is for this generic part. Some manufacturers do pure generics, some change software only and some change something in design. |
| 23:13:06 | wodz | even rk SDK has many conditionals |
| 23:13:18 | pamaury | BobJonkman1: hum, ok if you don't mind, I will prepare a special firmware to recover from very low battery for tomorrow and we can retry tomorrow ? |
| 23:13:23 | W00fer | yeah and i'm enthusiastic to see if from that reference design i can generate some information for you to develop further :) |
| 23:13:32 | BobJonkman1 | pamaury: That would be wonderful. |
| 23:13:40 | W00fer | and i do understand that you don't want to develop for some random player |
| 23:13:49 | wodz | W00fer: No you can't. |
| 23:14:18 | saratoga_ | W00fer: like i said before, if you're not going to do the work yourself, don't worry about this and just go buy a supported player |
| 23:14:26 | W00fer | i already have |
| 23:14:57 | W00fer | i just expected a bit more support for someone who is trying to help |
| 23:15:02 | wodz | W00fer: Don't take it personal, maybe your player is nice and dandy but I don't have interest in spending my time on this. |
| 23:15:26 | saratoga_ | W00fer: if you're not working on it, then you should not expect anything at all |
| 23:15:27 | wodz | W00fer: I can share the knowledge which will save you something like few hundred hours of work that is |
| 23:16:34 | W00fer | if you are not actively developing the platform, and i will have to do device specific porting on my own its a waste of time (even for my friends who do know C). |
| 23:16:58 | W00fer | i was just curious about the active state of development |
| 23:17:06 | saratoga_ | talking to you is a waste of time, send whoever you know that wants to work on this in |
| 23:17:16 | saratoga_ | then let them discuss what they need to know |
| 23:17:40 | W00fer | why are you even participating sara, didn't knew i asked |
| 23:18:08 | W00fer | thanks wodz |
| 23:18:10 | wodz | W00fer: you are rude, to speak mildly |
| 23:19:30 | W00fer | hmm i asked quite politely, just some simple questions. |
| 23:19:57 | wodz | W00fer: No, you insist to do the work for you. That is quite different |
| 23:20:38 | W00fer | i just wanted to know how to execute rockbox and send the reports, i never asked for a full player support. |
| 23:20:54 | W00fer | or end user ready version |
| 23:21:06 | saratoga_ | W00fer: didn't we say that you can't ? what is the problem |
| 23:21:25 | wodz | There is NO enduser version for your player. I stated this already |
| 23:21:44 | W00fer | it sounds weird to me that nobody is interested in debugging information for their own benefit |
| 23:21:48 | W00fer | but that's my mistake then |
| 23:22:02 | W00fer | sorry bout that |
| 23:22:02 | saratoga_ | there is no information you can provide that would be beneficial |
| 23:22:07 | wodz | W00fer: And I said how to run custom code. |
| 23:22:16 | W00fer | ok |
| 23:23:20 | W00fer | good luck then |
| 23:23:36 | saratoga_ | anyway, this argument is pointless |
| 23:23:42 | saratoga_ | lets get back on topic |
| 23:24:08 | W00fer | thanks for the help saratoga |
| 23:24:12 | W00fer | appreciate it |
| 23:25:13 | | Part W00fer |
| 23:26:10 | [Saint] | Some people... |
| 23:27:11 | [Saint] | Do we somehow come off to the public as being professional or something? |
| 23:27:37 | | Quit krabador (Quit: Sto andando via) |
| 23:27:51 | [Saint] | Errr...I mean, do you think somehow people are getting the impression that this is anything more than a community hobby project? |
| 23:27:55 | BobJonkman1 | Wow... And here I'm swept off my feet by the level of support *I'm* getting. |
| 23:28:35 | [Saint] | BobJonkman1: We do try and make it painless where possible. |
| 23:28:52 | [Saint] | Its a LOT easier when those seeking support are calm and rational, though. |
| 23:28:53 | wodz | [Saint]: The guy was simply clueless how embedded developments works |
| 23:29:00 | saratoga_ | its that awkward problem of needing to know a lot before you can even comprehend how little you really know about software |
| 23:29:18 | BobJonkman1 | [Saint]: I've always been exceptionally impressed by the support provided on FAIF projects |
| 23:29:36 | saratoga_ | people think that since they can use a computer that they're most of the way to being an experienced embedded engineer |
| 23:29:46 | saratoga_ | and get upset when told otherwise |
| 23:29:49 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 23:30:55 | [Saint] | The thing that seemed to push that user over the edge was the suggestion that no one is actually interested in doing this work for him/her and that if s/he wanted it to happen, they were the best candidate for the job. |
| 23:31:06 | wodz | saratoga_: well they *are* on the way to be experienced embedded engineer. It just something like 1000 hours of learning |
| 23:31:20 | [Saint] | Hehehehe |
| 23:31:41 | BobJonkman1 | A few months ago I was on the #ownCloud channel asking for support, preparing to make a SoftwareFreedomDay presentation on ownCloud. I got to speak to a developer in that channel too, who was actually just a few km from where I was. He actually came to my SFD presentation and helped present! Try to get that level of involvement from commercial projects |
| 23:32:19 | | Join W00fer [0] (~W00fer@a80-101-149-96.adsl.xs4all.nl) |
| 23:32:20 | [Saint] | BobJonkman1: A huge part of it revolves around people doing what they love. |
| 23:32:29 | W00fer | too bad u guys talk about me when i was away |
| 23:32:32 | [Saint] | It isn't hard to be passionate about a topic you enjoy. |
| 23:32:33 | * | BobJonkman1 wishes he had better coding chops to make contributions |
| 23:32:35 | W00fer | but i can read logs |
| 23:32:45 | Soukyuu | Short question; the bootloader linked for creative zen on the wiki page is betav2, i see a link to betav3 on the forum thread, should i be updating or was that only something to test a specific issue? |
| 23:32:50 | wodz | I didn't know much about C or electronics not speaking about asm and reverse engineering when I started |
| 23:32:51 | [Saint] | W00fer: Its not a secret club |
| 23:33:36 | W00fer | nope it isn't |
| 23:33:42 | [Saint] | Soukyuu: Dvelopment thread trumps wiki. |
| 23:33:57 | Soukyuu | [Saint], thanks |
| 23:34:23 | saratoga_ | i started out knowing how to design processors in verilog and built a few MIPS ones, but still read assembly at a rate of like 3 opcodes a minute after like 8 years on this project |
| 23:34:38 | Soukyuu | is the hierarchy irc > forum thread > wiki? |
| 23:35:17 | saratoga_ | usually whatever is newer |
| 23:35:24 | [Saint] | IRC is where we would prefer you to seek support/advice, but the forums are no less accurate or less likely to get a response. |
| 23:35:42 | | Quit pamaury (Ping timeout: 260 seconds) |
| 23:36:01 | [Saint] | The wiki can be potentially misleading, as there's no obligation for anyone to keep the information contained within current. |
| 23:36:14 | W00fer | yeah i experienced that |
| 23:36:15 | W00fer | now |
| 23:36:26 | [Saint] | So there can be ancient contradictory documentation mixed amongst the latest current documentation. |
| 23:36:51 | W00fer | if it was accurate, i would have never asked this question as i thought that it was accurate for the platform. |
| 23:36:58 | W00fer | but fine with that |
| 23:37:19 | preglow | kugel: yeah, the decoder pretty much requires the entire frame to be present in the bit buffer |
| 23:37:40 | [Saint] | There's nothing misleading about the Rockchip page(s) I'm aware of. |
| 23:37:55 | preglow | kugel: i can't really tell you too much about this, and i doubt mike could either |
| 23:38:15 | kugel | i found the decoder returns quite a few times before the clip is fully decoded, so it does actually decode in chunks |
| 23:38:19 | preglow | kugel: you basically have to keep feeding the decoder a bit buffer of more than the biggest frame speex does, then keep track of how much it eats |
| 23:38:29 | wodz | W00fer: It is accurate for the platform. There are drivers for timers, lcdif, pll, cache and whatsever. That doesn't mean you can take arbitrary player build around rk27xx SoC and expect everything to be supported |
| 23:38:29 | preglow | kugel: oh sure |
| 23:38:46 | preglow | kugel: what we do now is pass it all the data at once, and feed it the same bit buffer until speex itself says it's done |
| 23:38:55 | preglow | kugel: speex itself knows perfectly well how big its frames are |
| 23:39:00 | W00fer | then it should display that it is a platform, different than a port |
| 23:39:10 | W00fer | for end user hardware |
| 23:39:13 | W00fer | it is in the same list |
| 23:39:37 | preglow | kugel: the main speex.c codec we have does this, but it has some ogg framing that hides the raw details |
| 23:39:44 | W00fer | in my opinion |
| 23:40:07 | preglow | kugel: but it too has chunks of multiple speex frames delimited at the proper boundaries |
| 23:40:16 | saratoga_ | W00fer: no offense, but you're not qualified to have an opinion here |
| 23:40:23 | kugel | yea I looked at that, the main codec seems to have more information that the voice clips offer |
| 23:40:39 | W00fer | i do take it as an offense, sorry bout that |
| 23:40:51 | preglow | kugel: ah, there's one main gotcha here |
| 23:40:59 | preglow | kugel: we never flush the bit buffer to byte align it |
| 23:41:12 | [Saint] | The Rockchip wiki is very clear about it being for the SoC itself. |
| 23:41:31 | [Saint] | It doesn't state it will "Just WOrk" on any arbitrary rk device. |
| 23:41:58 | W00fer | saint, where is that it only is for that soc? |
| 23:42:18 | W00fer | must have misread then |
| 23:42:52 | [Saint] | That page is only documenting the SoC variants. |
| 23:43:02 | [Saint] | No other hardware is mentioned. |
| 23:43:24 | W00fer | http://www.rockbox.org/wiki/TargetStatus#New_Platforms_Currently_Under_Development |
| 23:43:29 | [Saint] | It is possible to run arbirary code on these devices, but that is very far from a fully supported port. |
| 23:43:34 | W00fer | yeah |
| 23:44:25 | W00fer | and i asked thus, how i can run that arbitrary code to experiment :) |
| 23:44:39 | [Saint] | And wodz told you. |
| 23:45:20 | kugel | preglow: how can you do that? |
| 23:45:23 | preglow | kugel: that can be worked around without breaking the files we already have, but it's going to mean you have to manually bit align every time you reorder the buffer of data you give speex |
| 23:46:05 | [Saint] | Ah, slight apology, I thought you were referring to the Rockchip SoC wiki page. |
| 23:46:08 | kugel | couldnt you stash bits.bitPtr and re-use the last byte? |
| 23:46:14 | [Saint] | ...but that doesn;t really change much. |
| 23:46:30 | W00fer | yeah |
| 23:46:31 | preglow | kugel: probably, yeah |
| 23:46:35 | W00fer | it states players |
| 23:46:37 | W00fer | pandora, onda |
| 23:46:45 | preglow | kugel: yeah, almost certainly |
| 23:46:45 | W00fer | ipod |
| 23:47:24 | [Saint] | iPo...huh? There's no Rockchip iPods. |
| 23:47:35 | W00fer | target list |
| 23:48:41 | W00fer | but okay, back on topic |
| 23:49:01 | preglow | kugel: so, basically either learn how to read speex frame sizes to ensure you have a whole one, or base yourself on the max frame size, so you know speex will never run out of data |
| 23:49:20 | preglow | kugel: and fixup the bit buffer when you notice you haven't got enough anymore |
| 23:49:37 | preglow | copying from pcmbuf |
| 23:52:31 | kugel | well, the maximum frame size seems easy: I read it's 20ms of audio, so as a simplification the max. frame size is 20ms of pcm data |
| 23:52:50 | preglow | yeah, but drastically less in speex form |
| 23:53:36 | preglow | afaik, speex frames are fixed size, speex in vbr mode will choose from a list of frame sizes it can make for a given frame of pcm audio |
| 23:53:40 | kugel | right but it's still small enough to not be a problem. I'm considering a 1K buffer which should be more than sufficient |
| 23:53:54 | preglow | 1k is almost certainly more than you'll need, yeah |
| 23:54:01 | | Quit foolsh (Read error: Connection reset by peer) |
| 23:54:10 | kugel | I'm off now, thanks for your help |
| 23:54:16 | preglow | no worries |
| 23:58:25 | saratoga_ | preglow: any interest in working on codecs these days? |
| 23:58:38 | | Quit kugel (Ping timeout: 252 seconds) |
| 23:58:42 | preglow | saratoga_: always, depends on the codec, but no time atm or for the next months |
| 23:58:47 | | Join toehser [0] (~tom@Connqueror.Toms.NET) |
| 23:58:48 | saratoga_ | yeah same here |
| 23:58:54 | saratoga_ | any interest in Opus? |
| 23:59:00 | preglow | yeah |
icon identifies that the person is a core developer (has commit access).