| 00:00:17 | | Quit TheSeven (Ping timeout: 248 seconds) |
| 00:00:46 | pamaury | archivator: recording doesn't work, it does nothing "apart from print 'waiting ...'" and I have a hard at exiting it normally, pressing each button ten times before getting back to main menu |
| 00:01:48 | amiconn | pamaury: fat_size reports in KB exactly for the reason to avoid 64 bit integers. |
| 00:02:19 | pamaury | amiconn: yeah I understood that finally :) |
| 00:02:51 | archivator | pamaury: well then, I'm out of ideas. :( |
| 00:03:51 | pamaury | it's strange that is locks this way. Why is there a waiting splash ? |
| 00:04:46 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 00:05:11 | | Quit stripwax (Client Quit) |
| 00:05:14 | pamaury | funman: if you are really interested, I *think* the database was due caused by some broken audio files that was incomplete (ie an mtp transfer broke and only a part of the file was actually written) |
| 00:05:52 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 00:06:02 | | Quit amiconn (Disconnected by services) |
| 00:06:04 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 00:06:18 | | Quit pixelma (Disconnected by services) |
| 00:06:20 | | Join pixelma2 [0] (quassel@rockbox/staff/pixelma) |
| 00:06:26 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 00:06:42 | | Nick pixelma2 is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 00:07:02 | | Quit CGL (Quit: Saliendo) |
| 00:08:25 | archivator | pamaury: I'm pretty sure the splash was the cause of the slowness with the previous patch. |
| 00:08:43 | pamaury | but you didn't remove it |
| 00:09:15 | archivator | I just reached that conclusion :) |
| 00:09:35 | pixelma | wodz: http://i.imgur.com/FcLIq.png |
| 00:09:37 | pamaury | ah, then I can try to remove it if it makes sense |
| 00:09:58 | archivator | pamaury: not with what I last gave you. Give me a sec |
| 00:10:03 | pamaury | ok |
| 00:10:32 | funman | pamaury: without a way to reproduce the crash i'm not very interested in proof reading parsers |
| 00:10:48 | *** | Saving seen data "./dancer.seen" |
| 00:10:58 | pamaury | Think twice because i will go to bed soon, so that's your last attempt |
| 00:11:19 | pamaury | funman: I can try to break another MTP transfer for sure if you want :) |
| 00:11:26 | pamaury | *for you |
| 00:11:56 | pamaury | it could also be that the file was not broken and was just weird |
| 00:12:06 | * | pamaury checks |
| 00:12:09 | pixelma | wodz: it's also included automatically, no menu backdrop and no specific icons though (it still works without them - using the inbuilt icons and the M3 also doesn't have that. You'll notice when the sim starts as an short error message) |
| 00:12:54 | pixelma | it's really a mixture of small H10 and M3 port |
| 00:13:02 | | Quit BlakeJohnson86 (Read error: Operation timed out) |
| 00:13:24 | | Quit ender` (Quit: "Religion is the opiate of the masses." -- Karl Marx -*- "Winners don't do drugs." -- The FBI) |
| 00:13:31 | archivator | pamaury: try this please: http://pastebin.com/KiYW9by4 :) |
| 00:14:51 | | Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) |
| 00:15:11 | * | bluebroth3r spots an old stash where he wanted to libify ipodpatcher for rbutil |
| 00:15:18 | bluebroth3r | I should pick that up again ... |
| 00:15:50 | pamaury | funman: I just checked and indeed, it was because the file was incomplete, I can't reproduce it with the complete file |
| 00:16:11 | pamaury | archivator: it works \o/ |
| 00:16:50 | | Quit robin0800 (Remote host closed the connection) |
| 00:16:59 | archivator | bluebroth3r: I have a script that pops up a window with all my forgotten stashes in my session just for cases like yours! :) |
| 00:17:25 | archivator | pamaury: slowly or normally? |
| 00:17:29 | pamaury | normally |
| 00:17:32 | pamaury | like a charm |
| 00:17:33 | archivator | good. |
| 00:17:38 | | Quit jgarvey (Quit: Leaving) |
| 00:17:40 | archivator | All the modes? |
| 00:18:02 | pamaury | no, I was about to say that only lines mode work correctly, other mode don't display anything |
| 00:18:41 | pamaury | hum false, spectogram works, only bars doesn't, but switch between them is not reliable |
| 00:19:32 | archivator | bars is a bit unreliable as it is, don't worry about it. |
| 00:19:54 | pamaury | bars doesn't work in playback for me |
| 00:20:13 | archivator | What do you mean switching is not reliable? Takes time to react or doesn't work at all? |
| 00:20:26 | pamaury | takes time to react, sometimes it gets ignored |
| 00:20:35 | archivator | yeah, something's very broken with bars and logarithmic scaling, I haven't gotten around to fixing it yet. |
| 00:20:41 | | Quit petur (Quit: Leaving) |
| 00:21:38 | pamaury | lines and spectorgram modes are cool so it's not a real issue, at least it works for recording |
| 00:22:21 | archivator | Yeah, gonna add some documentation to the source code and post it on FS. |
| 00:22:27 | pamaury | ok |
| 00:23:29 | wodz | pixelma: cool |
| 00:23:32 | | Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) |
| 00:23:39 | | Quit pamaury (Quit: Page closed) |
| 00:24:21 | | Quit robin0800 (Remote host closed the connection) |
| 00:24:28 | | Quit bmbl (Quit: Bye!) |
| 00:24:51 | archivator | Does anyone know what the return value of the recording callback indicates? |
| 00:26:08 | | Quit komputes (Quit: I haven't slept for ten days, because that would be too long.) |
| 00:26:20 | funman | archivator: pcm_more_callback_type2 ? |
| 00:27:05 | archivator | funman: I think that's the one. It's an int, really. The callback takes a status as an argument and has an int return value which I can't figure out. |
| 00:27:20 | wodz | time to sleep() |
| 00:27:36 | | Quit wodz (Quit: Leaving) |
| 00:27:51 | | Quit lpereira (Quit: Leaving.) |
| 00:28:06 | funman | i just know that if it's < 0 recording is finished |
| 00:28:59 | archivator | If it's what wodz says, then that's awesome. I only need a way to measure how long a single transform takes and pump as much data as possible. |
| 00:29:05 | | Quit Schmo (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 00:29:37 | funman | -1 : /* Flush recorded data to disk and stop recording */ |
| 00:29:54 | funman | apps/pcm_record.c : pcm_rec_have_more() |
| 00:30:07 | funman | so in fact it's a boolean |
| 00:30:21 | funman | -1 : stop, >= 0 : continue |
| 00:30:45 | | Quit pixelma_ (Quit: -=+) |
| 00:30:47 | | Quit phanboy4 (Quit: Leaving) |
| 00:30:47 | funman | < 0 && != -1 : room for further error codes which will probably never be added |
| 00:31:09 | archivator | funman: what makes you think so? If it's time to sleep(), -1 would indicate end of recording, yes, but any positive value can be used as # ticks. |
| 00:31:12 | | Join mikroflops_ [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) |
| 00:31:33 | funman | archivator: i guess wodz didn't answer to you but just meant he was tired ;) |
| 00:31:46 | archivator | funman: or, he did a double entendre. |
| 00:31:51 | | Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) |
| 00:31:56 | funman | archivator: read pcm_rec_have_more(), there's only 2 return values |
| 00:32:30 | archivator | funman: I've read that whole file. It still doesn't make it clear. |
| 00:32:33 | funman | btw, pcm_record_more() is present in the plugin API but never used? |
| 00:32:46 | | Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 00:32:54 | archivator | funman: correct. The pitch_detector author has a note about not knowing how to use it :) |
| 00:33:02 | funman | oh ok |
| 00:34:04 | funman | archivator: well pcm_rec_have_more is only used once as the callback argument to the only call (not including the one call in pitch_detector) of pcm_record_data() |
| 00:34:37 | | Join Strife89 [0] (~michael@168.16.232.201) |
| 00:34:50 | | Quit mikroflops (Ping timeout: 246 seconds) |
| 00:34:55 | | Part Strife89 |
| 00:35:24 | funman | so it's only used in the recording interrupt context of each target driver, and grep show all these drivers just use: if (callback(...) < 0) { stop recording } |
| 00:35:33 | | Quit robin0800 (Remote host closed the connection) |
| 00:35:54 | funman | if you want to extend the return value you'd need to modify each recording driver |
| 00:35:56 | | Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) |
| 00:36:14 | archivator | funman: sounds about right. What bothers me though is whether I can call record_more from outside the callback. |
| 00:37:08 | | Quit robin0800 (Remote host closed the connection) |
| 00:37:31 | archivator | As far as I can tell, I can't, which means that for my needs, I'll need 2 buffers to swap between. Which will result in about 8KB more stack requirements :( |
| 00:37:44 | funman | archivator: if recording is stopped before you should be able to |
| 00:37:56 | | Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) |
| 00:38:02 | | Join Strife1989 [0] (~michael@168.16.232.201) |
| 00:38:10 | funman | pcm_record_more resets the recording context |
| 00:38:12 | archivator | funman: define "stopped". return -1 stopped or pcm_stop_recording stopped? |
| 00:38:16 | | Part Strife1989 |
| 00:39:23 | archivator | sorry to bother with this stuff, btw, it just goes a bit over my head (I can understand it but you're probably more comfortable with it than I am) :) |
| 00:39:29 | archivator | bother you* |
| 00:39:53 | funman | well i'm not very familiar with recording, i just implemented a target driver with appreciable amounts of copy/pasting from other drivers |
| 00:40:36 | archivator | I don't think anyone is familiar with recording. I'll write a wiki page about it after all this. |
| 00:41:06 | * | jhMikeS is familiar with recording (in case in matters) (and a bit drunk, if that matters) |
| 00:41:23 | funman | pcm_record_more(start, size) sets the recording context of the driver: it will record size bytes and store them at buffer start |
| 00:41:59 | funman | it is called from the interrupt context because at this point the buffer is full so it asks you for where to put the next data to be recorded, or if it must just stop recording |
| 00:42:12 | | Quit einhirn (Read error: Connection reset by peer) |
| 00:42:30 | funman | provided you don't mind to discard the recording which was in progress you should be free to call pcm_record_more() yourself |
| 00:42:52 | archivator | so basically, returning -1, i.e. stopping the recording and then calling pcm_record_more somewhere else should work? |
| 00:42:59 | | Part hobbs ("Leaving") |
| 00:43:47 | jhMikeS | archivator: if you want to start another transfer of data from your ISR, call pcm_record_more with the size and buffer from it |
| 00:44:24 | funman | archivator: instead of returning -1 and later call pcm_record_more(), why not call it immediately and return 0 ? |
| 00:45:00 | archivator | funman: because there's work to be done on the data in the buffer and that would mean I'll need double buffering. |
| 00:45:01 | funman | jhMikeS: btw did you spot my removal of pcm_mute() yesterday? |
| 00:45:22 | archivator | jhMikeS: that's the point, I want to resume the recording from outside the callback. |
| 00:45:24 | jhMikeS | funman: no. hadn't been around. I was considering the same action |
| 00:45:44 | funman | archivator: hm ok, but then you'd lose some data i think |
| 00:46:02 | jhMikeS | archivator: then just stop it and start again. there is no pause as it wouldn't make much sense. |
| 00:46:09 | archivator | funman: I don't mind. I lose tons of data in playback mode as well. |
| 00:46:50 | archivator | jhMikeS: that's what I was doing. I assume there isn't much overhead from constantly calling pcm_stop_recording? |
| 00:47:00 | jhMikeS | archivator: otherwise, you can just keep it going and ignore what the data it returns until you want to do something with it |
| 00:47:21 | archivator | funman: to be precise, I don't "lose" it, it just never shows up in the buffers I'm accessing. |
| 00:47:58 | jhMikeS | archivator: wait till the callback is called, then the data is ready |
| 00:48:40 | jhMikeS | basically it's start (w/params) -> hardware fills buffer -> interrupt (say to do more or just return < 0 to end it) |
| 00:48:48 | archivator | jhMikeS: right, that's what I was doing - calling pcm_stop_playback in the callback. And then record_data after I was done processing the buffer. |
| 00:50:07 | jhMikeS | archivator: there's really no need for that and will likely result in data breaks. |
| 00:51:08 | archivator | jhMikeS: then just return -1 until I'm ready to get new data? Hm, that would make things a tad more complex .. |
| 00:52:26 | jhMikeS | why the need to stop it? the core recording just keeps it going but just doesn't advance the queue if "paused". |
| 00:53:13 | archivator | jhMikeS: no need per se, that's the way pitch_detector is doing it and I just copied it. |
| 00:53:56 | jhMikeS | archivator: I recall that. it rather nasty and plain incorrect |
| 00:54:28 | | Quit funman (Quit: free(random());) |
| 00:54:34 | jhMikeS | see apps/recorder/pcm_record.c line 247 for the core's callback function. |
| 00:55:30 | archivator | jhMikeS: I've had that open for a day now, doesn't help me much since it's not how my workflow goes. |
| 00:56:10 | b0hoon | AlexP: ping |
| 00:56:20 | AlexP | hello |
| 00:56:31 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 00:56:34 | jhMikeS | archivator: perhaps, but that's how the interface works. I suppose workflow has to work with that. :) |
| 00:56:58 | | Quit stripwax (Quit: http://miranda-im.org) |
| 00:57:09 | b0hoon | AlexP: hi, would you like to look at the manual for the vibe 500, please? |
| 00:57:25 | archivator | jhMikeS: let's recap - if I return -1 from the callback, the buffer won't be used by the core. If I return 0, the buffer will be used. In both case (whether I can accept new data or not), I should call record_more from the callback. Correct? |
| 00:57:28 | | Quit DataGhost (Ping timeout: 245 seconds) |
| 00:57:38 | AlexP | b0hoon: Sure, anything in particular? |
| 00:57:41 | b0hoon | AlexP: only section 3.1.1 and 3.1.3 |
| 00:58:06 | b0hoon | AlexP: is everything ok with the lanquage... |
| 00:58:25 | archivator | jhMikeS: There's a very easy fix to my problem, really, but it's a memory tradeoff I'm not prepared to make. |
| 00:58:36 | AlexP | b0hoon: Just looking now |
| 00:58:40 | jhMikeS | archivator: if you return -1 any new buffer will be ignore and recording will stop |
| 00:59:02 | archivator | jhMikeS: then how is that different from calling pcm_stop_recording? |
| 00:59:14 | jhMikeS | archivator: no need to call record_more if you plan on returning < 0 |
| 00:59:35 | CIA-5 | New commit by pixelma (r25744): Cabbiev2 port for the mpio HD20's 128x128 greyscale screen - mixing the same size colour version with the same width greyscale version (code could be ... |
| 00:59:56 | jhMikeS | archivator: not technically different. but if you need a continuous, unglitched flow of data, stoping and restarting is not the way to do. |
| 01:00 |
| 01:00:17 | archivator | jhMikeS: I don't need a continuous flow of data since I have nowhere to put it :) |
| 01:01:10 | kugel | pixelma: ping |
| 01:01:29 | archivator | jhMikeS: I would really rather not increase the stack usage (it's large enough as it is) and I don't see another way of doing with the situation. |
| 01:02:02 | CIA-5 | New commit by pixelma (r25745): Cabbiev2: make the playlist position and playing time info actually show up as planned in the 128x128 colour port. |
| 01:02:31 | pixelma | kugel: pong |
| 01:02:44 | jhMikeS | archivator: hrm. Prepared to pastebin anything? I don't fully understand what's so unique here. |
| 01:02:53 | kugel | pixelma: did you try the pla patch on your other targets? |
| 01:03:17 | | Quit robin0800 (Remote host closed the connection) |
| 01:03:41 | archivator | jhMikeS: this is the latest patch: http://pastebin.com/KiYW9by4 |
| 01:03:54 | AlexP | b0hoon: A couple of small changes to 3.1.1: http://pastebin.com/VQkSi9wz |
| 01:04:12 | pixelma | kugel: sorry, forgot |
| 01:04:14 | archivator | what's different is that there's nothing to stop the core from changing the buffer *while I'm doing the transform on it* |
| 01:04:16 | AlexP | b0hoon: Question, does the scroll pad only scroll, or would just up and down be more accurate descriptions? |
| 01:04:26 | AlexP | b0hoon: Looking at the second bit now |
| 01:04:41 | | Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) |
| 01:05:24 | pixelma | kugel: the patch is broken currently (at least I got a conflict when updating), probably because of the mpio port additions |
| 01:05:52 | b0hoon | AlexP: the scroll pad only scroll and sets the parameters like volume etc. |
| 01:06:12 | kugel | pixelma: tbh, I'd really like to get it in before I'm too busy for gsoc and especially before 3.6 |
| 01:06:25 | AlexP | b0hoon: 3.1.3 - "Rockbox has a dual-boot feature where it is possible to load the original firmware from the file /System/OF.mi4. To boot into the original firmware press Power normally without holding it. Immediately after the backlight turns on press and hold the OK button." |
| 01:06:47 | | Quit robin0800 (Remote host closed the connection) |
| 01:07:16 | AlexP | b0hoon: That isn't just scrolling then - perhaps "Sliding a finger up or down the scroll pad acts as Up and Down respectively." |
| 01:07:36 | AlexP | b0hoon: Also, note in that sentence in my pastebin I missed out "acts" and s/or/and/ |
| 01:08:04 | b0hoon | AlexP: ok, thank you, i'm reading pastebin now... |
| 01:08:05 | jhMikeS | archivator: I'm not sure what that means. the core won't change the buffer unless you do it. Transforming one buffer while recording to another would be the best policy. If the transform isn't complete at the time you get the int, just give recording the same buffer again. |
| 01:08:43 | pixelma | kugel: yes, that would be nice. I'll really try testing tomorrow feel free to remind me in the evening |
| 01:09:16 | | Quit BlakeJohnson86 (Quit: Leaving.) |
| 01:09:31 | | Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 01:09:41 | AlexP | 3.1.3 is perhaps better as "Rockbox has a dual-boot feature where it is possible to load the original firmware from the file /System/OF.mi4. To boot into the original firmware press Power normally without holding it and then immediately after the backlight turns on press and hold the OK button." |
| 01:10:16 | archivator | jhMikeS: not "change" as in change the pointer but "change" as in record new data to the buffer I'm currently transforming. And yes, double buffering is indeed the best solution but would mean another 8KB of stack I'm not prepared to sacrifice :) |
| 01:10:17 | kugel | pixelma: what I'd like is to confirm it on your and mine targets, and then find a solution for the manual which is a bit more intelligent (maybe separate pla_+ opts). I worked on a perl script to autoconvert keymaps but there are complications I'm likely unable to solve in the next weeks |
| 01:10:33 | kugel | pla_* |
| 01:11:16 | jhMikeS | archivator: stack? wth would *stack* be used for such a thing? |
| 01:11:32 | pixelma | manual I can still follow, but what do you mean with "separate pla and opts"? |
| 01:11:42 | pixelma | kugel: ^ |
| 01:12:04 | kugel | jhMikeS: is there anything that'd prevent our own thread engine disallow to run onder an actual OS? |
| 01:12:13 | archivator | jhMikeS: ah, but it is :). the input, output and plot arrays are all on the stack. |
| 01:12:15 | kugel | I only thought of *_irq so far |
| 01:12:58 | jhMikeS | archivator: and this is necessary? esp. in a plugin? |
| 01:13:17 | archivator | jhMikeS: in any case, I think I have it all clear now. I think the callback needs a new return value - something to signify "I can't take the data now but ask me again later" :) |
| 01:13:21 | linuxstb | AlexP: How about something like "press and release Power and then immediately after the backlight turns on, press the OK button and keep it pressed until the original firmware starts." |
| 01:13:33 | b0hoon | AlexP: if it goes about the Scrool Down or Scroll Up i did it like in case of ipod video because it acts the same way (the difference is only in a shape of touch region) |
| 01:13:33 | kugel | pixelma: currently all manual keymaps are created manually, aren't they? I thought maybe a target would define its pla_* buttons which would then be used for the plugins that use pla too |
| 01:13:36 | jhMikeS | kugel: the IRQ is just a faked out thing using mutex and those other things (which the names escape me atm). |
| 01:14:05 | AlexP | linuxstb: That is good too (b0hoon use that version) :) |
| 01:14:23 | jhMikeS | archivator: if you can't, it will need restarting. not sure why the insistence upon the stack though. will that patch into the current fft? |
| 01:14:28 | archivator | jhMikeS: well, the output array can be eliminated if I use an in-place transform but yeah, pretty much necessary. It works, no one's complaining, so I can't think of any reason to change beside "purity" and that's debatable :) |
| 01:14:31 | AlexP | b0hoon: OK, if the ipods say scroll then I guess use that (we can have a discussion about that later) :) |
| 01:14:34 | b0hoon | linuxstb: yeah, it is good too |
| 01:15:04 | pixelma | kugel: so you mean the pluginlib actions as actions in the keymap files (as cora actions too)? |
| 01:15:19 | kugel | I simply thought this this evening: if I'd port to android, why worry about a 3rd party thread library when we ported our to arm already? but I don't really know how much our engine depends on having OS like control (disabling irq, supervisor mode, etc...) |
| 01:15:22 | * | Hillshum swaps a 'a' out for an 'e' |
| 01:15:22 | jhMikeS | archivator: it sure puts some drivers throught alot of other setup that could sap cycles away |
| 01:15:24 | kugel | jhMikeS: ^ |
| 01:15:38 | archivator | jhMikeS: do you mean "fft" as in the plugin or the routines used by the codecs? :) If the latter, then no, the plugin uses its own transform library. Basically, no reason to change that either, since the bottleneck in playback mode is the availability of PCM data, not the transform speed |
| 01:15:58 | kugel | pixelma: yea. because eventually I'd like to convert a number of plugins to pla, mostly demos which often only have an exit action |
| 01:16:12 | jhMikeS | archivator: I meant the plugin, since it looks like a patch for the fft demo |
| 01:16:20 | b0hoon | linuxstb, AlexP: thanks a lot :) |
| 01:16:33 | AlexP | no worries :) |
| 01:16:40 | archivator | jhMikeS: ah, yes, it is indeed a patch for the demo (which I'm trying to enhance with recording support) |
| 01:16:50 | pixelma | kugel: that could work a bit better now if there aren't that many anymore and only one context, I don't believe autogeneration will work for all the plugins though, there are just too many possibilites |
| 01:17:19 | jhMikeS | kugel: did I miss something? the fakey irq stuff is implemeneted with OS objects, basically as a scheme to lock out preemptive threads not part of the rockbox pool, as they do act as interrupts in principle. |
| 01:17:38 | kugel | in fact, only generation works awesome, but only if context arent' ch |
| 01:17:46 | kugel | chained to other ones |
| 01:18:28 | * | archivator looks back and sees that he meant "unnecessary" three comments ago. |
| 01:18:42 | archivator | or not, I can't read anymore. |
| 01:18:43 | kugel | jhMikeS: you may missed that I got accepted fo rockbox as an application for gsoc, but other than that no |
| 01:19:17 | kugel | I'm currently exploring alternatives to SDL, and if we could use our own code on platforms we already run on as an OS |
| 01:19:36 | jhMikeS | kugel: \o/ congrats (you said accepted (can't seem to read well atm)? \o/ |
| 01:20:00 | kugel | jhMikeS: high five! :) |
| 01:20:07 | jhMikeS | kugel: so in effect we write our own SDL? LOL |
| 01:21:11 | kugel | I sometimes get the feeling we'd end up so, which is why I'm trying to think of possibilities to re-use our existing code, but not as an OS but as an app |
| 01:21:13 | pixelma | kugel: I thought some plugins with only exit use core actions? I seem to have seen some plugin descriptions in the manual use the equivalent of core actions |
| 01:21:47 | | Quit archivator (Quit: nothing to say) |
| 01:22:10 | kugel | jhMikeS: I basically ported gnu pth (a cooperative thread library) to replace (preemptive) sdl threads. that works well under x86 for example, but I don't see an advantage over our own threads |
| 01:22:38 | kugel | so if I were to port to an ARM based smartphone I'd rather use our threads than pth even if we don't run as on OS ourself |
| 01:23:23 | kugel | pixelma: some also have #ifdef BUTTON_OFF ... #elif BUTTON_POWER .... #endif (I hope you get what I mean) |
| 01:24:48 | kugel | jhMikeS: I'm just not sure how our threads rely on the fact that we're an OS (i.e. run under supervisor mode) and so on |
| 01:24:50 | | Quit mt_ (Read error: Operation timed out) |
| 01:25:59 | jhMikeS | kugel: nothing does uses privileged access. afaik basic threading should be available to an app. |
| 01:27:23 | | Part b0hoon ("GTG. Bye.") |
| 01:27:28 | | Nick bgs100 is now known as bgs000 (57o9@unaffiliated/bgs100) |
| 01:27:53 | RadicalR | Hmmm, I guess I broke the fuzev2. |
| 01:28:06 | RadicalR | It's trying to load the firmware and gives me "file not found" |
| 01:29:14 | jhMikeS | kugel: also, our own threads in the context of sim, are really just an app. |
| 01:29:42 | | Nick bgs000 is now known as bgs100 (57o9@unaffiliated/bgs100) |
| 01:30:15 | | Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) |
| 01:32:01 | | Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) |
| 01:32:04 | | Quit JdGordon (Ping timeout: 268 seconds) |
| 01:32:39 | kugel | jhMikeS: I'll try to set up an test app which links "rockboxthreads.so", be prepared to answer questions :) |
| 01:33:02 | kugel | fortunately I have a real arm target which also runs linux |
| 01:33:05 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
| 01:33:18 | kugel | however, unfortunately it can't run the simulator :( |
| 01:34:26 | | Join CaptainKewl [0] (jds@207-237-106-60.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 01:34:35 | kugel | (it seems to get killed by the OOM killer) |
| 01:35:06 | | Join CaptainKwel [0] (jds@207-237-106-60.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 01:35:14 | jhMikeS | it sounds out of the scope of what I know about threads as an app (which is limited to sim) |
| 01:36:20 | kugel | jhMikeS: another related question, do you see any possible to handle struct thread entry as an opaque object outside of thread.c? my current pth port needs to handle cases where kernel.c references thread_entry members for no real reason (thread.c isn't linked, while kernel.c is) |
| 01:37:32 | jhMikeS | just declare it as struct thread_entry; without a name outside of thread.c? |
| 01:37:44 | kugel | anyway, if not it shouldn't matter too much. I doubt my project is going to fail due to threads |
| 01:38:26 | kugel | jhMikeS: kernel.c referneces actualy members, like bqb not just the thread_entry struct |
| 01:38:42 | kugel | -y |
| 01:39:14 | | Part toffe82 |
| 01:39:45 | jhMikeS | ah right, so how could it be opaque to it other than to add calls? they're rather intimate. |
| 01:39:45 | | Quit CaptainKewl (Ping timeout: 276 seconds) |
| 01:40:53 | kugel | jhMikeS: that was my question to you :P |
| 01:41:12 | | Join CaptainKewl [0] (jds@207-237-106-60.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 01:41:26 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
| 01:41:43 | kugel | I thought maybe kernel.c relies on knowing too much and that could be fixed with something more sophisticated that adding API calls |
| 01:42:00 | jhMikeS | kugel: erm, a nested structure that is publicly declared? seems like alot of trouble for something that's really part of the same thing. |
| 01:42:12 | kugel | because API calls only mean I replace dummy members with stubs |
| 01:45:21 | | Quit CaptainKwel (Ping timeout: 276 seconds) |
| 01:49:04 | jhMikeS | kugel: I suppose you could pass the object information to block_thread(_w_tmo). it needs to know the queue and the corelock object. |
| 01:51:05 | kugel | heh, that sounds like'd end up in some fakish OOP :p |
| 01:51:29 | kugel | like it'd* |
| 01:52:27 | CIA-5 | New commit by funman (r25746): fix r25741: the 2nd delay needs to be present when the CPU is boosted |
| 01:53:13 | kugel | funman: .... :) |
| 01:53:51 | jhMikeS | kugel: hehe. some stuff was done to keep the overhead down. the scheduler needs some info to be able to properly remove a thread from an object and do it efficiently, either for inheritance or for implicit wakeup (timeout). |
| 01:54:04 | kugel | funman: something is wrong if udelay(1) is not enough to cover a 500-busy-wait |
| 01:54:37 | kugel | a udelay(1) should be equivaltent to an (75-100)-busy-wait |
| 01:55:36 | jhMikeS | udelay(1) might not delay at all though, since the timer could advance at any time. basically, it means "wait until next count". |
| 01:56:05 | kugel | the commit messages says udelay(1) was too long though |
| 01:56:31 | jhMikeS | then you're screwed :) better use delay loops! |
| 01:56:52 | kugel | well, it worked on my unit |
| 01:57:17 | kugel | I actually counted cycles :/ |
| 01:57:43 | | Quit liar (Quit: Verlassend) |
| 01:57:57 | kugel | the problem is that simple delay loops are really bad if the boosted and non-boosted freq differ too much |
| 01:58:44 | jhMikeS | on cf, some bitbang drivers adjust that in set_cpu_frequency. |
| 01:59:37 | jhMikeS | oh, the ds2411 one just checks it upon entry, but that's not really performance-critical |
| 01:59:44 | kugel | we could do that, but a) that part is not stable on as3525v2 yet, and b) the timer should be fairly detiministic |
| 02:00 |
| 02:00:52 | jhMikeS | faster timer? udelay(1) is right at the quantum level if it counts usecs. |
| 02:01:05 | kugel | funman: did you consider udelay(2) already? |
| 02:01:34 | kugel | jhMikeS: right, that's why I don't understand udelay(1) is too short |
| 02:01:35 | | Quit DerPapst (Quit: Leaving.) |
| 02:02:39 | kugel | I counted cycles, each busy wait was ~13 loop worth (because the loop variable was volatile too). that means 13*500*(1/240MHz) time for the whole delay. way more that 1us |
| 02:02:46 | jhMikeS | udelay(2) would delay anywhere from 1 to 2. the beasts keypad driver has to guarantee a delay and uses udelay(2) to do that, but then it's not too critical. |
| 02:03:16 | kugel | 13 cycles* |
| 02:03:37 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 02:04:30 | kugel | the main problem is I think that handling the case that the udelay is called from a tick task. i.. in the moment it jumps from 0 to its reload value, isn't quite trivial |
| 02:04:43 | kugel | s/i../i.e./ |
| 02:05:36 | kugel | argh, I don't have time for AMS hacking :'( |
| 02:06:44 | * | kugel is sure funman only came back because he read the logs :D |
| 02:06:51 | funman | kugel: i was under the assumption that you used udelay(1) because the real delay would be less than 1µs but in fact it's several µs, so why did you reduce to 1 ? |
| 02:06:58 | funman | of course :p |
| 02:07:36 | kugel | funman: actually, because it worked. I tested basically all buttons under boosted. that was before your fix of course |
| 02:08:46 | kugel | yes, 500 should be more than a single usec, but it worked for some reason |
| 02:09:11 | kugel | which is why it makes me crazy you say udelay(1) is too long |
| 02:09:20 | funman | you're right |
| 02:09:54 | * | jhMikeS hasn't had any AMS fun so far. mx31 hacking is trouble enough at times. :\ |
| 02:10:22 | | Join Rob2223 [0] (~Miranda@p4FDCA503.dip.t-dialin.net) |
| 02:10:23 | funman | the 1st loop is 104µs at 40MHz and the 2nd loop is 50µs |
| 02:10:51 | *** | Saving seen data "./dancer.seen" |
| 02:11:05 | kugel | funman: I looked at the asm output, the fact that the loop variable was volatile added like 6-7 addtional cycles to each loop (1 str, 2 ldr), so the delays in the button driver were really huge |
| 02:11:07 | | Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) |
| 02:11:09 | funman | so 1.5% of the CPU time is spent there |
| 02:12:07 | kugel | jhMikeS: it affects several targets, which is exciting :) |
| 02:12:39 | kugel | funman: I can imagine it was too *short*, but not really that it was too long |
| 02:12:55 | jhMikeS | and the timer counts at the right frequency? |
| 02:13:06 | funman | yes timer is ok |
| 02:13:18 | kugel | yes, 1.5% of the cpu time is really major, so I thought some freq independant udelay was a good thing to do |
| 02:13:48 | funman | kugel: 1st delay: udelay(10); and 2nd : udelay(5) is ok for me (both when boosted & unboosted) |
| 02:13:53 | kugel | which you basically reverted now :) |
| 02:13:54 | | Quit Rob2222 (Ping timeout: 248 seconds) |
| 02:14:00 | jhMikeS | funman: that sounds a might peculiar. does the timer wrap really quickly? |
| 02:14:25 | funman | kugel: if the delay was volatile then it's ~twice more: 3% (@#!) perhaps we'll have a bit better performance now |
| 02:14:38 | funman | jhMikeS: well it wraps HZ times per second |
| 02:15:20 | kugel | could it be that it is at 0 only for a *really* short time, and that it reloads TIMERx_LOAD immediately? |
| 02:15:20 | funman | kugel: http://pastie.org/938363 should be the last in the series |
| 02:15:49 | kugel | so that we should rather assume it goes from TIMERx_PERIOD to 1, instead of from TIMERx_PERIOD to 0? |
| 02:15:58 | funman | hm i don't know, let's see what the datasheet says |
| 02:16:21 | funman | An interrupt is generated when the full 32-bit counter reaches zero, and is only cleared when the TimerXClear location is written to. A register holds |
| 02:16:24 | funman | the value until the interrupt is cleared. The most significant carry bit of the counter detects the counter reaching zero. |
| 02:16:42 | kugel | funman: the delay variable in current svn isn't volatile anymore, is it? |
| 02:16:43 | jhMikeS | funman: sounds like the could mess things up. |
| 02:16:58 | funman | kugel: nope it isn't |
| 02:17:21 | funman | it doesn't say if the counter stays at 0 or if it's immediately reloaded |
| 02:18:41 | funman | jhMikeS: it could mess up things but only if you call the udelay() with 1µs, so it's not a big deal as the precision is 1.5µs |
| 02:18:51 | kugel | so it stays at 0 until the interrupt is acked? |
| 02:19:18 | funman | no because we ack the interrupt only after all the tick tasks have returned |
| 02:19:23 | kugel | that'd mean udelay would end up in an infinite loop though, because the int is acked after call_tick_tasks() |
| 02:19:32 | funman | if it stayed at 0 udelay() would just lock up |
| 02:19:42 | kugel | :) |
| 02:19:57 | kugel | you're too slow :P |
| 02:20:05 | funman | :( |
| 02:20:46 | funman | ok for that last patch ? |
| 02:20:59 | | Quit CaptainKewl (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) |
| 02:21:51 | * | jhMikeS did see odd behavior on the beast if the int wasn't acked immediately before calling tick tasks (just sayin' it's not unprecedented). |
| 02:21:51 | funman | also did you see the forum comment where fuzev2 scrollwheel acceleration looks infinite ? |
| 02:23:28 | CIA-5 | New commit by funman (r25747): Fuzev2: revert r25741 and r25746 ... |
| 02:23:34 | kugel | funman: no |
| 02:24:05 | funman | 1st post of page 108 |
| 02:24:21 | kugel | funman: I did calculate those udelays with 25 and 13 at the very beginning, but 1 and 1 seemed to work anyhow |
| 02:24:59 | funman | perhaps they where most longer only some times, but with 100 runs per second one would work and the backligth would go off |
| 02:25:17 | funman | (before my fix) |
| 02:25:24 | kugel | in the fuzev1 you can scroll 500 items with 2 rotations... |
| 02:25:41 | funman | well it's ok then |
| 02:26:25 | kugel | I found that a bug in my patch caused the unpredictable accel which I fixed. now it feels basically like on the e200v1 |
| 02:26:27 | funman | too fast for me but it's consistent so no prob? |
| 02:26:40 | kugel | it used to worse, didn't it? |
| 02:26:56 | kugel | fuzev1 is definetely accelerating faster in my experience |
| 02:27:12 | funman | i can't tell since my fuzev1's wheel is a bit stuck so not freely moving :p |
| 02:27:29 | funman | (someone put it apart and probably didn't remount it properly) |
| 02:27:45 | kugel | revert to before my udelay commit and you get the very same behavior on the fuzev2 |
| 02:28:18 | | Quit pixelma (Disconnected by services) |
| 02:28:18 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 02:28:30 | | Quit amiconn (Disconnected by services) |
| 02:28:32 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 02:28:38 | funman | so now what's left: sd write and fixing cpufreq ? |
| 02:28:40 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 02:28:54 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 02:29:13 | funman | ah no FM is still missing on the fuze |
| 02:29:30 | funman | (and usb) |
| 02:30:31 | saratoga | funman: i saw your post about boosting |
| 02:30:33 | kugel | yea, and the strange backlight off after exiting plugins |
| 02:30:41 | saratoga | i thought you set it to 20 or 30 MHz unboosted? |
| 02:30:55 | kugel | I think the sw backlight fading isn't entirely correct yet but I have no proof |
| 02:31:17 | funman | saratoga: 24MHz , but in the first days of the port we left it at 120MHz (default boot setting) iirc |
| 02:31:36 | funman | kugel: i think it's related to settings + read-only |
| 02:31:41 | saratoga | well 24MHz would be really nice, the codecs on the clip+ are amazingly fast |
| 02:31:54 | saratoga | for best runtime we'll want ~20MHz, maybe lower since the screen is so small |
| 02:32:28 | funman | saratoga: 24 is the minimum with pll@384MHz |
| 02:32:48 | saratoga | i think I tested flac at around 10MHz realtime decoding :) |
| 02:33:35 | funman | reversing the PLL bits should be possible with lots of try and measure |
| 02:34:43 | funman | saratoga: with a custom build disabling cpufreq switching and fixing the clock at 24MHz is easy |
| 02:35:17 | saratoga | probably not worth trying for a 15MHz clock then |
| 02:35:20 | funman | i still don't know what happens: most of the crashes reported in the forum happen in set_cpu_frequency() function |
| 02:36:21 | saratoga | the D2 uses the same arm core and manages <10MHz flac decoding without using IRAM |
| 02:36:22 | funman | hmm no the PLLA is at 240MHz |
| 02:36:31 | funman | so we could go down to 15 |
| 02:36:33 | saratoga | though that sort of begs the question why they don't just use IRAM :) |
| 02:36:37 | saratoga | oh cool |
| 02:36:47 | saratoga | is there any voltage scaling going on too? |
| 02:36:52 | funman | nope |
| 02:37:07 | saratoga | so no harm if we spend more time boosted then |
| 02:37:16 | funman | the problem i think is that pclk is derived from fclk so you must modify CGU_PROC and CGU_PERI together |
| 02:37:41 | funman | i suppose weird things happen with memory if pclk is too high/too low |
| 02:38:25 | funman | i'll try again tomorrow to use more steps to make sure pclk stays in a good range |
| 02:38:50 | funman | i had tried to stress boosting/unboosting but it didn't cause crashes faster |
| 02:39:23 | funman | perhaps putting set_cpu_frequency() in uncached memory would force memory accesses while switching |
| 02:39:46 | | Join CaptainKewl [0] (~jason@207-237-106-60.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 02:40:16 | funman | FlynDice: i'm ready to sacrifice small animals if it makes you see the light and understand what happens in our sd driver :) |
| 02:43:39 | funman | saratoga: no news from tremor guys, monty seems more busy trolling than answering to patches :( |
| 02:43:56 | saratoga | ha |
| 02:44:15 | saratoga | well i was hoping one more person would try the patch to make sure stripwax's weird issue on his player was just his distro's fault |
| 02:50:17 | funman | perhaps you could get some testers in #vorbis ? |
| 02:50:54 | | Quit funman (Quit: free(random());) |
| 02:51:03 | soap | I'm not an old-school Archos person, so I don't personally know the whole sordid history of how Rockbox became THE place for atapwd, but our link to it has been reported as down. |
| 02:51:17 | soap | Is there a desire to host it, or direct to a current host for it? |
| 02:52:50 | | Quit Rondom (Ping timeout: 260 seconds) |
| 02:52:58 | soap | ArchosUnlock.exe is also no longer hosted where the ancient http://www.rockbox.org/lock.html page points. |
| 02:55:50 | Llorean | soap: If I recall, Rockbox used to have a bug that could accidentally lock the HD in the devices (I wasn't around then either, I think I just read about it) but it hasn't happened in ages, so the tool is basically now unnecessary |
| 02:55:54 | Llorean | But we turn up in searches despite that. |
| 02:56:48 | Llorean | It seems like that page should just be moved into the wiki, and then deprecated. |
| 03:00 |
| 03:02:01 | soap | Ok. I was primarily curious if Rockbox no longer hosted it because of IP issues or other. If because of IP issues I figured the least I could do was fix the link. |
| 03:08:34 | Llorean | I bet it just got lost along the way, and nobody particularly cared. |
| 03:15:38 | | Quit mt (Read error: Connection reset by peer) |
| 03:17:40 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 03:26:45 | | Quit pjm0616 (Ping timeout: 276 seconds) |
| 03:39:58 | | Quit kugel (Ping timeout: 246 seconds) |
| 03:44:50 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 03:44:57 | soap | saratoga, I believe you can edit posts and Febs has not been active for 8 months. |
| 03:45:08 | saratoga | i can't edit his post |
| 03:45:38 | saratoga | i just have delete |
| 03:45:47 | soap | Ok, then do you mind saving me a trip out to the garage to get a DAP and confirm chrisjj is correct and his wording is also correct? |
| 03:45:48 | saratoga | i think i can only edit people of equal or lesser forums rank |
| 03:45:49 | Llorean | Global Mods are kinda "special" I think, in that their posts can't be edited except by Admins or other global mods. |
| 03:45:57 | saratoga | yes his wording is mostly correct |
| 03:46:14 | soap | grumble grumble mostly grumble grumble. |
| 03:46:16 | Llorean | soap: "System -> Rockbox Info" |
| 03:46:16 | saratoga | although its actuall "system -> Rockbox Info" then under the "version" label |
| 03:46:31 | saratoga | so version is whats written next to it, not the menu label like it says now |
| 03:48:19 | soap | fixed |
| 03:48:36 | soap | (I guess I could have downloaded a sim) |
| 03:52:39 | | Quit n1s (Ping timeout: 268 seconds) |
| 03:59:10 | | Nick bgs100 is now known as bgs000 (57o9@unaffiliated/bgs100) |
| 04:00 |
| 04:08:44 | | Join Barahir [0] (~jonathan@gssn-5f754dc1.pool.mediaWays.net) |
| 04:10:52 | *** | Saving seen data "./dancer.seen" |
| 04:12:06 | | Quit Barahir_ (Ping timeout: 260 seconds) |
| 04:14:03 | | Join alexanderpirdy [0] (~alexander@c-71-192-98-150.hsd1.ma.comcast.net) |
| 04:14:46 | | Quit adnyxo (Ping timeout: 246 seconds) |
| 04:15:18 | | Quit Unhelpful (Read error: Connection reset by peer) |
| 04:24:13 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
| 04:24:34 | | Join Unhelpful [0] (~quassel@71.173.205.32) |
| 04:24:35 | | Quit Unhelpful (Changing host) |
| 04:24:35 | | Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) |
| 04:25:03 | alexanderpirdy | Hi, I am looking for a the status of getting rockbox to work on sansa fuze v2, I am looking right now at the 108 page forum post, but is there an overview or something somewhere? |
| 04:27:57 | | Quit pixelma (Disconnected by services) |
| 04:27:58 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 04:28:11 | | Quit amiconn (Disconnected by services) |
| 04:28:13 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 04:28:20 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 04:28:35 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 04:31:20 | saratoga | alexanderpirdy: status link on the front page |
| 04:35:16 | | Join CGL [0] (~CGL@190.207.188.162) |
| 04:39:59 | | Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) |
| 04:40:34 | | Join mazdac [0] (~chatzilla@adue90.neoplus.adsl.tpnet.pl) |
| 04:42:49 | alexanderpirdy | saratoga: Thanks, but is there a simple way to get a more detailed understanding? For example what does unusable really mean? Is it at the point of development yet where it is just buggy, but not device risking? |
| 04:43:13 | saratoga | alexanderpirdy: i think you didn't click the link |
| 04:51:32 | | Quit anewuser (Quit: http://xrl.us/NitroQueer What do you know...THE WORLD'S first NTRQ (that's for NES/FAMICOM) tracking compo. Have powerpak? Try it out! Otherwise ROM IMAGE.) |
| 04:55:52 | alexanderpirdy | saratoga: wow sorry I missed that must have been three times, my apologies |
| 04:56:19 | saratoga | no problem |
| 05:00 |
| 05:08:40 | alexanderpirdy | saratoga: Thanks again, a lot of useful stuff there. Is there a way to get a sense of the chances of bricking? Or is it pretty random? |
| 05:09:26 | saratoga | i don't think anyone has ever bricked their player installing a build |
| 05:10:19 | Llorean | alexanderpirdy: Generally, when there's a realistic risk of bricking your player, there will be something in large red letters telling you either how to avoid it, or that you shouldn't do it yet because of the risk |
| 05:15:04 | alexanderpirdy | I was not thinking of installing a build, but one that is currently labled unusable which does have the big red warning... |
| 05:16:33 | saratoga | then don't install it |
| 05:18:48 | alexanderpirdy | I was just wondering if there was some way to asses the risk of damage. I know that one is there, and would be interested in trying to move the port forward. So if I were to purchase a cheap used one on ebay to test, what do you think the chances are? |
| 05:19:19 | alexanderpirdy | I understand that it is risky and not recommended for just regular use |
| 05:21:17 | Llorean | I don't see a big red warning. |
| 05:21:35 | Llorean | I see the general 'there's always a risk of bricking your devices' in red (which is also there for the *stable* ones, you'll note) but nothing beyond that. |
| 05:22:10 | saratoga | if you're asking questions like these you should wait for a stable release |
| 05:22:15 | saratoga | come back in a few months |
| 05:23:20 | alexanderpirdy | Llorean: http://www.rockbox.org/wiki/SansaAMS under unusable? Is that not the big red warning in the disclaimer section? |
| 05:24:13 | Llorean | alexanderpirdy: Didn't I specifically reference that warning which is also there for the stable ones? |
| 05:26:12 | alexanderpirdy | Llorean: I couldn't tell if this is the one you were referencing or if there was a more prominent one, sorry. |
| 05:27:12 | Llorean | Basically, any Rockbox install on certain targets contains a small risk of bricking. |
| 05:27:12 | alexanderpirdy | saratoga: I was thinking that I would just wait for a stable release, but would like to contribute to the project and even just understand more about it, and figured that it would be best to focus on a model that I have personal interest in getting to work. |
| 05:27:28 | | Join saratoga_ [0] (~9803c20d@gateway/web/freenode/x-looxmfmtvqpovgba) |
| 05:27:30 | Llorean | But the very, very, very first goal in development is to remove the possibility of bricks so that further development can be more experimental / safe |
| 05:28:19 | saratoga_ | alexanderpirdy: if you're having this much trouble with the wiki i'm not too confident in you'll be able to help much |
| 05:30:26 | alexanderpirdy | saratoga: I understand your point of view and I apologize for hastily asking questions |
| 05:34:23 | saratoga_ | that alt-f4 thing in the forums is pretty dumb |
| 05:34:35 | saratoga_ | improbably so |
| 05:36:29 | Llorean | I still have no clue what he was trying to ask about documentation earlier. |
| 05:37:38 | | Quit panni_ (Read error: Connection reset by peer) |
| 05:37:55 | saratoga_ | he was asking if theres some group of people he could talk with about boring semi-rockbox related things |
| 05:38:16 | | Quit Horscht (Quit: Verlassend) |
| 05:38:34 | krazykit` | ah, the user-ml then ;) |
| 05:39:11 | saratoga_ | no the purpose of the user list is to let other people know that you have an email account |
| 05:41:27 | | Quit komputes (Quit: I haven't slept for ten days, because that would be too long.) |
| 05:51:33 | alexanderpirdy | saratoga_: Llorean: thanks again for the help, talk to you later... |
| 05:51:46 | | Part alexanderpirdy |
| 06:00 |
| 06:07:53 | | Join RandomInsano [0] (~Edwin@wnpgmb0806w-ad07-62-231.dynamic.mts.net) |
| 06:10:54 | *** | Saving seen data "./dancer.seen" |
| 06:24:43 | | Join JDGAFFLIN [0] (~jessedula@68-28-137-229.pools.spcsdns.net) |
| 06:25:45 | | Quit JDGAFFLIN (Client Quit) |
| 06:32:54 | | Part RandomInsano |
| 06:35:58 | | Quit shai (Quit: Leaving) |
| 06:36:23 | | Quit CaptainKewl (Remote host closed the connection) |
| 06:59:23 | | Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) |
| 07:00 |
| 07:01:31 | | Join w1ll14m [0] (~w1ll14m@84-104-80-54.cable.quicknet.nl) |
| 07:08:07 | | Join einhirn [0] (~Miranda@p5485A4CA.dip0.t-ipconnect.de) |
| 07:21:39 | | Quit w1ll14m (Ping timeout: 246 seconds) |
| 07:22:40 | | Quit saratoga_ (Quit: Page closed) |
| 07:29:17 | | Quit einhirn (Read error: Connection reset by peer) |
| 07:35:44 | | Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) |
| 07:39:32 | pixelma | has someone else noticed the statusbar missing in the USB screen or flickering in recent builds (saw the former with early USB on my Ondio and the latter with USB screen simulation in an mpio sim)? |
| 07:40:03 | pixelma | that's the builtin bar, not an sbs |
| 07:44:40 | Llorean | I've noticed the status bar flickering when I insert a lot of tracks. |
| 07:44:43 | Llorean | It flickers as the splash updates |
| 07:46:38 | | Join RandomInsano [0] (~Edwin@wnpgmb0806w-ad07-62-231.dynamic.mts.net) |
| 07:47:20 | | Part RandomInsano |
| 07:48:58 | | Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) |
| 07:49:06 | pixelma | you mean inserting into the playlist? For some reason I read that as "adding tracks through the PC" first (I was focused on USB and still a bit sleepy ;) ) |
| 07:54:47 | | Quit CGL (Quit: Me juiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii) |
| 07:55:05 | Llorean | Yes, inserting through the playlist |
| 07:55:20 | Llorean | Instead of turning on and off shuffle for spoken word vs music, I usually just "insert shuffled" my music folder |
| 07:55:31 | Llorean | Which is ~1700 tracks or so |
| 08:00 |
| 08:04:12 | | Quit sinthetek (Ping timeout: 240 seconds) |
| 08:05:33 | | Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek) |
| 08:10:56 | *** | Saving seen data "./dancer.seen" |
| 08:23:36 | | Quit krazykit` (Ping timeout: 240 seconds) |
| 08:24:46 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:38:21 | | Quit jordan` (Quit: Coyote finally caught me) |
| 08:41:52 | | Join jordan` [0] (~jordan@jem75-13-78-235-252-137.fbx.proxad.net) |
| 08:42:17 | | Quit jordan` (Remote host closed the connection) |
| 08:42:50 | | Join jordan` [0] (~jordan@jem75-13-78-235-252-137.fbx.proxad.net) |
| 08:45:14 | | Join flydutch [0] (~flydutch@host24-146-dynamic.15-87-r.retail.telecomitalia.it) |
| 08:55:46 | | Join XSPR [0] (~chatzilla@p3028-ipbf409niigatani.niigata.ocn.ne.jp) |
| 08:56:36 | | Join pjm0616 [0] (~user@61.250.113.98) |
| 08:57:13 | XSPR | there is a RockBoy plugin for the gameboy handheld |
| 08:57:51 | XSPR | does anyone know of a server/channel for gameboy dev? (homebrew development) |
| 08:59:48 | | Quit _arbingordon (Quit: `) |
| 09:00 |
| 09:02:30 | | Part XSPR |
| 09:05:55 | JdGordon | Llorean: pixelma: bar flickering is an anoying known issue |
| 09:07:10 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 09:10:49 | pixelma | any ways to fix it? |
| 09:11:31 | | Join crculver [0] (~crculver@user-24-96-81-14.knology.net) |
| 09:13:58 | JdGordon | no |
| 09:14:06 | JdGordon | no good fixes anyway |
| 09:14:16 | | Quit Boldfilter (Quit: Boldfilter) |
| 09:16:53 | | Quit evilnick (Read error: Connection reset by peer) |
| 09:17:31 | | Join Zagor [0] (~bjst@46.35.227.87.static.tab.siw.siwnet.net) |
| 09:17:31 | | Quit Zagor (Changing host) |
| 09:17:31 | | Join Zagor [0] (~bjst@rockbox/developer/Zagor) |
| 09:17:58 | crculver | Daily build is broken for a second time this week. |
| 09:18:08 | crculver | (For iPod Video 32GB, that is) |
| 09:18:20 | crculver | What kind of big changes are going on? |
| 09:19:00 | crculver | Whoops, I spoke too soon. Looks like disk corruption on my end |
| 09:20:19 | | Join LinusN [0] (~linus@rockbox/developer/LinusN) |
| 09:26:24 | | Join DerPapst [0] (~Alexander@p5099d40e.dip0.t-ipconnect.de) |
| 09:26:51 | pixelma | JdGordon: can you explain in a few words what's going on with the status bar? It doesn't make for a good impression and in the early USB screen it would be nice being able to see disk access |
| 09:27:11 | pixelma | I mean the flickering with "it" |
| 09:28:33 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 09:31:19 | | Join lifeless__ [0] (~lifeless@188.18.101.226) |
| 09:31:30 | | Join shai_ [0] (~Shai@l192-117-110-233.cable.actcom.net.il) |
| 09:31:35 | | Quit Zagor (*.net *.split) |
| 09:31:35 | | Quit shai (*.net *.split) |
| 09:31:36 | | Quit phanboy4 (*.net *.split) |
| 09:31:36 | | Quit Unhelpful (*.net *.split) |
| 09:31:36 | | Quit BHSPitMonkey (*.net *.split) |
| 09:31:36 | | Quit n17ikh (*.net *.split) |
| 09:31:36 | | Quit Rob2223 (*.net *.split) |
| 09:31:36 | | Quit BlakeJohnson86 (*.net *.split) |
| 09:31:36 | | Quit lifeless_ (*.net *.split) |
| 09:31:36 | | Quit Farthen (*.net *.split) |
| 09:31:36 | | Quit FlynDice (*.net *.split) |
| 09:31:36 | | Quit xavieran (*.net *.split) |
| 09:31:36 | | Quit gevaerts (*.net *.split) |
| 09:31:36 | | Quit yosafbridge (*.net *.split) |
| 09:31:36 | | Quit advcomp2019_ (*.net *.split) |
| 09:31:36 | | Quit dionoea (*.net *.split) |
| 09:31:36 | | Quit Torne (*.net *.split) |
| 09:32:01 | | Nick shai_ is now known as shai (~Shai@l192-117-110-233.cable.actcom.net.il) |
| 09:34:05 | | Join solexx [0] (~jrschulz@e176099109.adsl.alicedsl.de) |
| 09:34:41 | crculver | Hmm, I'm not sure where the problem is. I get checksum errors on rockbox.ipod on boot. |
| 09:35:10 | JdGordon | pixelma: the splash screen disables the theme (which causes a full screen clear when it is reeneabled) |
| 09:35:17 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 09:35:25 | JdGordon | if we dont do that we run the risk of parts being left over after the splash is cleared |
| 09:35:58 | JdGordon | although I'm starting to think that we shuold just put the splash inside the ui viewport and ignore it if there isnt enough room (and byu ignore I mean clip) |
| 09:36:51 | | Quit solexx_ (Ping timeout: 260 seconds) |
| 09:36:51 | | Quit Llorean (Read error: Connection reset by peer) |
| 09:37:33 | | Join Zagor [0] (~bjst@rockbox/developer/Zagor) |
| 09:37:33 | | Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) |
| 09:37:33 | | Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) |
| 09:37:33 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
| 09:37:33 | | Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) |
| 09:37:33 | | Join Rob2223 [0] (~Miranda@p4FDCA503.dip.t-dialin.net) |
| 09:37:33 | | Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 09:37:33 | | Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) |
| 09:37:33 | | Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) |
| 09:37:33 | | Join xavieran [0] (~xavieran@ppp118-209-61-181.lns20.mel4.internode.on.net) |
| 09:37:33 | | Join gevaerts [0] (~fg@rockbox/developer/gevaerts) |
| 09:37:33 | | Join yosafbridge [0] (~yosafbrid@li14-39.members.linode.com) |
| 09:37:33 | | Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) |
| 09:37:33 | | Join dionoea [0] (~dionoea@videolan/developer/dionoea) |
| 09:37:33 | | Join Torne [0] (torne@rockbox/developer/Torne) |
| 09:39:47 | | Join wodz [0] (~wodz@chello087206240004.chello.pl) |
| 09:40:10 | wodz | amiconn: ping |
| 09:46:45 | | Join CGL [0] (~CGL@190.207.188.162) |
| 09:49:32 | | Quit flydutch (Ping timeout: 258 seconds) |
| 09:51:15 | | Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 10:00 |
| 10:04:54 | linuxstb | crculver: What are the two checksum values being displayed? |
| 10:06:07 | crculver | linuxstb, I think the problem is on my end. I installed a build from a few days ago and it still doesn't boot |
| 10:06:32 | linuxstb | crculver: OK, I'll ignore you then ;) |
| 10:07:17 | crculver | Incidentally, after I followed the reformatting instructions at http://www.rockbox.org/wiki/IpodConversionToFAT32, dosfsck no longer works on this drive. |
| 10:08:11 | | Join flydutch [0] (~flydutch@host24-146-dynamic.15-87-r.retail.telecomitalia.it) |
| 10:08:34 | crculver | $ dosfsck /dev/sdc2 |
| 10:08:36 | crculver | dosfsck 3.0.9, 31 Jan 2010, FAT32, LFN |
| 10:08:36 | crculver | Seek to 79883917312:Invalid argument |
| 10:09:04 | crculver | So if I can't run dosfsck, I can't repair whatever problem I have on this drive. I'd hate to reformat. |
| 10:09:10 | linuxstb | Do you have an 80GB ipod? |
| 10:09:49 | crculver | 30GB |
| 10:10:38 | crculver | I can mount the iPod just fine, I just can't fsck it. |
| 10:10:47 | JdGordon | pixelma: S_a_i_n_t: FS #11226 |
| 10:10:59 | *** | Saving seen data "./dancer.seen" |
| 10:11:35 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 10:12:24 | JdGordon | kugel: you probably want to test 11226 also |
| 10:13:07 | kugel | didn't we reject that idea before? |
| 10:13:36 | JdGordon | it is the lesser of two craps |
| 10:14:08 | kugel | I think there should be a proper solution for splashes |
| 10:14:28 | JdGordon | ok, lesser of 3 bads then |
| 10:19:00 | | Quit CGL (Quit: Nos leemos !) |
| 10:20:41 | | Join hebz0rl [0] (~hebz0rl@dslb-088-065-051-241.pools.arcor-ip.net) |
| 10:21:26 | linuxstb | crculver: Are you sure you used the correct MBR for your ipod? Are you using Linux? |
| 10:22:31 | crculver | linuxstb, Yes and yes |
| 10:24:57 | | Quit wodz (Quit: Leaving) |
| 10:28:27 | | Quit phanboy4 (Ping timeout: 265 seconds) |
| 10:32:03 | linuxstb | crculver: What does "fdisk -l /dev/sdX" show (where sdX is your ipod, and -l is the letter "ell"). Please post the output to http://pastebin.com |
| 10:38:39 | crculver | linuxstb, http://pastebin.com/EzTv5DvX |
| 10:40:24 | | Quit avacore^ (Read error: Operation timed out) |
| 10:41:25 | | Join avacore [0] (nobody@1008ds1-rdo.0.fullrate.dk) |
| 10:41:40 | linuxstb | crculver: Can you remember what command you used to format the disk? |
| 10:42:16 | crculver | linuxstb, Whatever the instructions are at http://www.rockbox.org/wiki/IpodConversionToFAT32 |
| 10:42:20 | crculver | This was about six weeks ago |
| 10:43:16 | linuxstb | Ah, so it's been working fine for about six weeks, but has stopped now? |
| 10:43:47 | crculver | linuxstb, This is the first issue I've had with it. |
| 10:43:57 | crculver | linuxstb, I haven't tried to run dosfsck on it until now |
| 10:46:01 | | Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) |
| 10:52:59 | pamaury | What do you think of MTP ? Which state it should reach before being commitable ? Are there issues that should be fixed/discussed before ? |
| 10:56:31 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
| 11:00 |
| 11:06:12 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 11:07:38 | linuxstb | pamaury: It can be committed without being enabled. I guess it would make sense to aim to enable it shortly after the next release.l |
| 11:09:32 | pamaury | Ok, thanks for your opinion. I need other people opinion on it before going on :) |
| 11:11:36 | | Quit elcan (Ping timeout: 276 seconds) |
| 11:14:36 | | Quit n1s (Ping timeout: 260 seconds) |
| 11:15:42 | | Join elcan [0] (user36@pr0.us) |
| 11:20:35 | | Join liar [0] (~liar@213.162.70.70) |
| 11:21:12 | JdGordon | kugel: (I'd rather an argument now than post commit). the reason the idea was rejected was because it might not look good depending on the ui viewport (so it wont be screen centred). it is quite unlikely that people care that much and would rather not have things flickering and lots of extra full screen clears |
| 11:22:05 | JdGordon | whatever we do it will bs bad for someone (and doing a special clearing for splashes is really the worst option) |
| 11:23:31 | kugel | no, it was rejected because a splash is "off the UI" so it should not be theme dependant |
| 11:24:09 | kugel | it wasn't for aesthetic reasons |
| 11:25:24 | JdGordon | then even more so it was a bad rejection |
| 11:25:45 | kugel | I agree with that though |
| 11:26:35 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 11:33:51 | amiconn | *imo* MTP is completely unnecessary, but that's just my personal opinion |
| 11:37:25 | n1s | well, the big advantage over UMS is that the database can be update at copy time so no scanning for added files needed, not that i use the database :) |
| 11:37:53 | gevaerts | playback should also be able to continue |
| 11:39:22 | n1s | right |
| 11:39:33 | n1s | but who uses that :P |
| 11:41:37 | amiconn | In my experience UMS is significantly faster than MTP |
| 11:42:01 | gevaerts | We'll have to see if that's fundamental :) |
| 11:45:26 | | Join arbingordon [0] (~w@unaffiliated/arbingordon) |
| 11:47:07 | n1s | amiconn: also nice apps can tellyou you are trying to transfer unsupported media and offer to transcode for you, and other useful things :) |
| 11:47:13 | pamaury | UMS is faster than MTP because the main purpose of MTP is not to transfer files at high speed. And my current implementation doesn't do double buffering so transfers will be slow but there is only a question of implementation, it can probably be made as fast as UMS |
| 11:47:59 | n1s | pamaury: why isn't the purpose of MTP to be fast? |
| 11:48:47 | pamaury | otherwise it would have been better designed :) |
| 11:49:12 | * | pamaury feels like trolling |
| 11:49:34 | n1s | i mean it is a *transfer* protocol ;) |
| 11:49:58 | n1s | pamaury: i don't blame you unless you designed it! |
| 11:50:11 | pamaury | no I didn't :) |
| 11:53:23 | JdGordon | pamaury: do you need/want testing with win7? |
| 11:53:30 | JdGordon | I think i saw a call for testing yesterday? |
| 11:53:58 | pamaury | Yesterday someone test it under win7 but of course you can test it, I also fixed several bug yesterday :) |
| 11:54:12 | JdGordon | I |
| 11:54:17 | JdGordon | I've never used mtp before though |
| 11:55:22 | pamaury | With the current implementation state, it mostly a matter of plugging it and checking if you can browse the file system. You can also run windows media player to see if it correctly list your media files. Which target are you using ? |
| 11:56:12 | JdGordon | I have a few to play with... any sansa and a few others.. which would you like? |
| 11:56:28 | pamaury | e200 because I already have a build :) |
| 11:56:38 | linuxstb | pamaury: How closely is MTP tied to the database? i.e. do you need to have enabled the database to use MTP? |
| 11:57:19 | pamaury | no, if you disable databse, it will relies on metadata parses, and even with databse enable, it will rely on them for files that are not in the database |
| 11:58:24 | pamaury | JdGordon: so is a e200 build ok ? |
| 11:59:09 | linuxstb | pamaury: OK, that sounds nice. |
| 12:00 |
| 12:00:36 | pamaury | However the current doesn't add files to the databse when there are created, this is one of the numerously missing features :) |
| 12:00:50 | JdGordon | pamaury: v1 or v2? |
| 12:00:55 | pamaury | v1 |
| 12:01:00 | JdGordon | cheers |
| 12:01:05 | linuxstb | pamaury: Isn't that the main reason someone would want to use MTP? ;) |
| 12:02:00 | pamaury | yes but implementing all the rest already takes lots of lines of code that are much more complicated :) This one should be easy to add |
| 12:04:42 | JdGordon | nuts, my e200v1 is fubar... no rockbox and bootloader cant load OF |
| 12:04:58 | pamaury | http://www.mediafire.com/?omtmitotmaz for a e200 build |
| 12:05:02 | JdGordon | pamaury: can you do a fuzev1 build? |
| 12:05:06 | pamaury | yes |
| 12:05:16 | pamaury | but you'll have to wait a few more minutes |
| 12:05:29 | JdGordon | ill build it faster here then :) |
| 12:05:34 | JdGordon | whats te fs number?/ |
| 12:06:29 | JdGordon | bah, git :( |
| 12:06:56 | JdGordon | ok do me a build please :) |
| 12:07:02 | pamaury | What is the git number ? |
| 12:07:40 | pamaury | there is my repo here if you want: pamaury/rockbox">http://github.com/pamaury/rockbox |
| 12:08:35 | kugel | JdGordon: fuzev1 doesn't have usb support |
| 12:08:36 | | Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) |
| 12:09:01 | | Quit BHSPitMonkey (Quit: Ex-Chat) |
| 12:09:24 | JdGordon | oh ruddy hell... :p |
| 12:09:32 | pamaury | if it doesn't have usb, mtp might be difficult to test :) |
| 12:10:01 | pamaury | another target perhaps ? |
| 12:10:02 | JdGordon | e200v2? |
| 12:10:15 | JdGordon | ipod vid (32mb), or mini2g |
| 12:10:27 | pamaury | ok, tell me one which has usb support ;) |
| 12:10:40 | JdGordon | kugel: does e200v2 have usb? |
| 12:10:45 | kugel | no |
| 12:10:49 | JdGordon | ok, either of the ipods |
| 12:11:04 | *** | Saving seen data "./dancer.seen" |
| 12:11:17 | pamaury | ok ipod video |
| 12:12:00 | pamaury | fuck, compile error :( |
| 12:15:11 | pamaury | I found a fix, I need to fix my MTP code, my code assumes multi volume in some place apparently, I'm building it with multi volume support |
| 12:15:32 | | Join bignose [0] (~bignose@eth595.vic.adsl.internode.on.net) |
| 12:15:52 | | Join krazykit [0] (~kkit@adsl-70-236-64-96.dsl.ipltin.ameritech.net) |
| 12:16:17 | bignose | when shopping for a Sansa Fuze, how can I tell which models will work with Rockbox stably and which won't? |
| 12:16:35 | bignose | the “v1†and “v2†terminology doesn't seem to be part of the model names. |
| 12:17:39 | Torne | You can't reliably, without turning it on and checking the firmware version |
| 12:18:09 | pamaury | JdGordon: http://www.mediafire.com/?nmhqyzzonqn |
| 12:18:41 | | Join bgs1001 [0] (znc@57o9.org) |
| 12:18:41 | | Quit bgs1001 (Excess Flood) |
| 12:18:49 | | Join Hadaka_ [0] (~naked@naked.iki.fi) |
| 12:18:53 | bignose | hmm. that makes it rather difficult to shop for one on eBay. |
| 12:19:13 | Torne | unfortunately yes |
| 12:19:18 | Torne | you could try asking hte sellers what the firmware version is |
| 12:19:53 | bignose | okay, thanks for the answer. |
| 12:20:44 | | Join bgs1001 [0] (znc@57o9.org) |
| 12:21:29 | JdGordon | pamaury: do I need to enable it or anything on the ipod? |
| 12:22:05 | | Part bignose |
| 12:22:14 | pamaury | yes, you need to enable it in debug menu: there is a "Enable MTP" entry. Then hold Select (I'm don't know the button on ipod) while plugging the cable |
| 12:22:49 | | Join jordan`` [0] (~jordan@jem75-13-78-235-252-137.fbx.proxad.net) |
| 12:23:12 | JdGordon | thats a bit yuck :p |
| 12:23:53 | pamaury | True but we need to think of a way to select between UMS and MTP and other drivers as well |
| 12:24:07 | | Quit jordan` (*.net *.split) |
| 12:24:08 | | Quit bgs000 (*.net *.split) |
| 12:24:08 | | Quit Hadaka (*.net *.split) |
| 12:24:09 | | Nick Hadaka_ is now known as Hadaka (~naked@naked.iki.fi) |
| 12:24:09 | JdGordon | comes up as "rockbox media player" |
| 12:24:14 | JdGordon | wow, disk access is slow |
| 12:24:38 | pamaury | on first plug, the host usually read the entire disk so it's extremely slow, I can't do anyting about that |
| 12:24:47 | pamaury | *-first |
| 12:25:04 | JdGordon | i was commenting on the speed the folders show up in explorer |
| 12:25:11 | JdGordon | WM11 seems to handle it fine |
| 12:25:31 | pamaury | ok |
| 12:25:33 | JdGordon | title is filename? |
| 12:25:59 | pamaury | I think so because there is to "title" metadata in MTP |
| 12:27:09 | pamaury | Could you also check if the reported volume size and free size is correct ? I fixed that yesterday normally |
| 12:27:29 | JdGordon | 26.8/55.7 sounds about right |
| 12:27:45 | JdGordon | same as rockbox reports in the info screen |
| 12:29:09 | pamaury | so it is working properly ? |
| 12:30:21 | JdGordon | wmp might have just crashed... |
| 12:31:23 | JdGordon | ignore that |
| 12:31:28 | JdGordon | yeah, looks like its working |
| 12:36:52 | | Part LinusN |
| 12:39:03 | | Quit kenguest (Read error: Connection reset by peer) |
| 12:39:09 | | Join kenguest [0] (~radagast@lir.talideon.com) |
| 12:40:46 | | Quit pamaury (Ping timeout: 264 seconds) |
| 12:44:12 | | Join mikroflops [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) |
| 12:48:20 | | Quit mikroflops_ (Ping timeout: 276 seconds) |
| 12:48:32 | | Join lpereira [0] (~lucien@did75-8-82-226-27-213.fbx.proxad.net) |
| 12:54:55 | | Quit n1s (Ping timeout: 260 seconds) |
| 12:56:52 | | Quit kugel (Ping timeout: 246 seconds) |
| 13:00 |
| 13:07:38 | | Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) |
| 13:10:50 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 13:18:26 | | Join LinusN [0] (~linus@rockbox/developer/LinusN) |
| 13:19:11 | | Join junkY_San [0] (~junkY@client115.amh.kn.studentenwohnheim-bw.de) |
| 13:20:07 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 13:21:22 | | Quit junkY_San (Client Quit) |
| 13:22:26 | | Quit Zagor (Ping timeout: 265 seconds) |
| 13:23:06 | | Join Zagor [0] (~bjst@rockbox/developer/Zagor) |
| 13:31:08 | | Quit n17ikh (Ping timeout: 265 seconds) |
| 13:35:15 | | Join watto [0] (~watto@193.203.81.165) |
| 13:36:02 | | Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) |
| 13:39:18 | | Quit arbingordon (Read error: Connection reset by peer) |
| 13:40:18 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 13:47:31 | | Join arbingordon [0] (~w@unaffiliated/arbingordon) |
| 13:53:48 | | Quit arbingordon (Quit: `) |
| 13:54:13 | | Join arbingordon [0] (~w@unaffiliated/arbingordon) |
| 14:00 |
| 14:04:07 | | Quit robin0800 (Remote host closed the connection) |
| 14:10:24 | | Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) |
| 14:11:08 | *** | Saving seen data "./dancer.seen" |
| 14:11:40 | | Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) |
| 14:12:35 | rasher | Is SoundCodecs the canonical list of supported codecs? |
| 14:21:21 | | Join Curtman [0] (~curt@S010600248c269238.wp.shawcable.net) |
| 14:34:20 | JdGordon | prob not |
| 14:34:44 | JdGordon | pamaury: how close do you reckon MTP is? do you want help for the settings? |
| 14:34:52 | JdGordon | using a button and the debug menu sort of sucks :p |
| 14:35:46 | pamaury | clearly :) For the settings, I just need a clear way to select between UMS and MTP. More generally, I think it would be nice to have a way to select usb drivers in a very versatile way but that can be advanced setting. |
| 14:36:38 | JdGordon | We have to choose pretty quickly which driver to start right? there is no way we could pop up a menu on connect? |
| 14:37:08 | pamaury | As the "hold a button" usb mode already exists, I think there could a setting for each usb mode: normal mode and "hold" mode. In each mode one could choose between UMS,MTP,battery,... |
| 14:37:20 | pamaury | Popping a menu on each connect is annoying no ? |
| 14:39:21 | JdGordon | not when there are more than 2 possible modes |
| 14:39:29 | JdGordon | and with a timeout it could be very usable |
| 14:40:01 | JdGordon | I think someone (probably gevaerts) said that the host needs to know the drivers (or something) pretty quickly after connect so a menu wouldnt work |
| 14:40:32 | pamaury | normally, the host ask for descriptors and the usb spec imposes a maximum response time iirc |
| 14:41:46 | | Quit esperegu (Ping timeout: 276 seconds) |
| 14:43:01 | pamaury | So it probably has to be a setting |
| 14:44:05 | JdGordon | 2 "settings"... 1) "usb mode on connect" (persistant), and 2) "usb mode on next connection" (non persistant) |
| 14:44:17 | JdGordon | maybe one more for "usb mode on connect+button" |
| 14:44:54 | | Quit Battousai (Remote host closed the connection) |
| 14:45:12 | pamaury | why one for persistant and one non persistant ? |
| 14:48:27 | JdGordon | because I might only want battery this time and usually mtp or msc |
| 14:49:11 | JdGordon | anyone absolutly against making the splash the same width as the last splash if the last one was recent enough and bigger than this one? |
| 14:49:17 | JdGordon | so it doesnt look so crap |
| 14:49:52 | | Quit DerPapst (Ping timeout: 276 seconds) |
| 14:51:49 | | Quit anewuser (Quit: http://xrl.us/NitroQueer What do you know...THE WORLD'S first NTRQ (that's for NES/FAMICOM) tracking compo. Have powerpak? Try it out! Otherwise ROM IMAGE.) |
| 14:53:28 | | Join Battousai [0] (~bryan@gentoo/developer/battousai) |
| 14:53:39 | pamaury | Why not, imo, the "connect+button" setting is really useful. This way you can have usb and mtp both accessible without changing the settings. And it's already useful for debugging |
| 14:53:52 | | Quit ved (Ping timeout: 276 seconds) |
| 14:54:44 | | Join webguest57 [0] (~47c5fef0@giant.haxx.se) |
| 14:54:56 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 14:55:07 | | Join ved [0] (~ved3@ddsbox.co.cc) |
| 14:56:50 | JdGordon | that only gives you the choice of 2 options |
| 14:57:04 | | Quit liar (Quit: Verlassend) |
| 14:57:07 | pamaury | why ? |
| 14:57:19 | JdGordon | connect and no button, connect and button |
| 14:57:38 | | Join Luca_S [0] (~5d3fc54b@giant.haxx.se) |
| 14:57:46 | pamaury | yes, and what is the problem ? |
| 14:58:12 | JdGordon | we will have 3 possible options |
| 14:58:41 | JdGordon | although I guess battery and MTP would work the same (or close enough) anyway? |
| 14:58:45 | JdGordon | i.e you can still listen to music |
| 14:59:15 | Luca_S | IIRC nokia phones show a menu when connected asking which mode to use, and no timeout, plus a setting for a default option suppressing the menu - I don't know if it's standard, but it would be pretty neat |
| 15:00 |
| 15:00:01 | gevaerts | It's horribly annoying |
| 15:00:09 | JdGordon | it doesnt have to be |
| 15:00:12 | pamaury | You can do this by delaying the PHY enabling, that is you don't enable the usb core on plug |
| 15:02:36 | | Quit Unhelpful (Remote host closed the connection) |
| 15:03:06 | pamaury | And it could probably be neatly implementing using the usb ack thing (a variant of it) |
| 15:04:41 | JdGordon | so have 2 options, 1 for connect and 1 for connect+button (although I personally think that combo sucks), and have a "menu" option as a posible value for both |
| 15:05:24 | pamaury | sounds ok to me |
| 15:06:00 | * | pamaury points to gevaerts for confirmation abou feasability and usability |
| 15:06:52 | * | gevaerts points back. Menus are GUI things! |
| 15:07:05 | JdGordon | git clone pamaury/rockbox.git">http://github.com/pamaury/rockbox.git right? |
| 15:07:43 | pamaury | I think so, although I never cloned a github repo and I'm not a git expert, it seems ok |
| 15:09:02 | | Quit webguest57 (Quit: CGI:IRC) |
| 15:10:53 | | Quit avn (Read error: Connection reset by peer) |
| 15:11:18 | | Join Schmogel [0] (~Miranda@p3EE22D52.dip0.t-ipconnect.de) |
| 15:11:49 | | Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) |
| 15:16:33 | | Join Unhelpful [0] (~quassel@71.173.205.32) |
| 15:16:34 | | Quit Unhelpful (Changing host) |
| 15:16:34 | | Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) |
| 15:22:12 | | Quit JohannesSM64 (Ping timeout: 268 seconds) |
| 15:22:17 | | Quit hebz0rl (Quit: Ex-Chat) |
| 15:28:44 | | Join DerPapst [0] (~Alexander@dslb-088-069-129-098.pools.arcor-ip.net) |
| 15:30:44 | | Join hebz0rl [0] (~hebz0rl@dslb-088-065-051-241.pools.arcor-ip.net) |
| 15:39:52 | | Join JohannesSM64 [0] (~johannes@cm-84.215.75.42.getinternet.no) |
| 15:40:22 | | Quit Unhelpful (Remote host closed the connection) |
| 15:43:51 | | Join CGL [0] (~CGL@190.207.188.162) |
| 15:47:59 | | Quit kugel (Quit: exit(0);) |
| 15:48:09 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 15:48:55 | | Join Unhelpful [0] (~quassel@71.173.205.32) |
| 15:48:56 | | Quit Unhelpful (Changing host) |
| 15:48:56 | | Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) |
| 15:52:05 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 15:56:16 | | Quit Unhelpful (Read error: Connection reset by peer) |
| 15:56:29 | | Quit pamaury (Quit: Quitte) |
| 15:57:50 | | Quit mazdac (Ping timeout: 260 seconds) |
| 15:58:29 | | Quit JohannesSM64 (Ping timeout: 264 seconds) |
| 16:00 |
| 16:01:49 | | Quit n17ikh (Remote host closed the connection) |
| 16:04:13 | | Quit Luca_S (Quit: CGI:IRC) |
| 16:04:23 | | Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) |
| 16:04:57 | | Join Unhelpful [0] (~quassel@71.173.205.32) |
| 16:04:57 | | Quit Unhelpful (Changing host) |
| 16:04:57 | | Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) |
| 16:07:42 | | Part LinusN |
| 16:11:09 | *** | Saving seen data "./dancer.seen" |
| 16:11:52 | | Join mazdac [0] (~chatzilla@adtz206.neoplus.adsl.tpnet.pl) |
| 16:14:22 | | Part mazdac |
| 16:17:50 | | Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) |
| 16:25:31 | | Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) |
| 16:28:48 | | Join archivator [0] (~archivato@stu0279.keble.ox.ac.uk) |
| 16:32:31 | | Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) |
| 16:47:09 | archivator | I have a dilemma - in its current state, fft does not have a proper log function for 64-bit numbers and just clips them to 32-bits. Very ugly, but it works. I can't find a fast 64-bit log function but I can estimate log2 of a 64-bit number by finding the position of the highest bit. Do you think that's acceptable or is it too hacky? |
| 16:49:24 | | Join esperegu [0] (~quassel@145.116.15.244) |
| 16:49:24 | | Quit esperegu (Remote host closed the connection) |
| 16:52:45 | kugel | archivator: counting leading zeros should give a good estimate |
| 16:53:21 | kugel | but 64bit numbers make it a bit more complex yes :) |
| 16:54:09 | | Quit JohannesSM64 (Read error: Operation timed out) |
| 16:56:50 | archivator | Nope, just tried it, doesn't work. The resolution to small for a good plot :( |
| 16:59:01 | kugel | I don't understand |
| 17:00 |
| 17:00:29 | kugel | can't you split up the 64bit number into 2 32bit ones? if the higher 32bit is zero, then log2() of the lower 32bit one, else 32+log2() of the higher one |
| 17:01:45 | archivator | kugel: check your math, what you're suggesting needs a factorization into two 32-bit numbers, not just a split (i.e., sum) |
| 17:02:34 | kugel | sum? |
| 17:02:59 | kugel | it'd still be an estimate only, but it should be more accurate than clz only |
| 17:03:03 | archivator | well (higher 32 bits << 32) + lower 32-bits. |
| 17:04:04 | kugel | right, so log2(x) approx 32+log2(x>>32) (which is what I said before) |
| 17:04:30 | | Join toffe82 [0] (~chatzilla@12.169.218.14) |
| 17:04:55 | archivator | yeah, approx. being the key word :) I was opting for an once and for all perfect solution :) |
| 17:05:19 | archivator | Although, the leading zeroes was an approximation as well.. |
| 17:07:20 | kugel | and if the higher 32bit are zero it should be pretty accurate |
| 17:08:23 | archivator | kugel: yes, it will be. I wonder, though, whether there's a fast way to factorize a 64-bit number into 2 32-bit numbers.. |
| 17:08:24 | | Join JohannesSM64 [0] (~johannes@cm-84.215.75.42.getinternet.no) |
| 17:08:54 | archivator | Since we're not looking for prime factors or anything, there has got to be an easy solution. |
| 17:09:00 | saratoga | why do you need 64 bit numbers at all in an fft? |
| 17:09:07 | kugel | int a = (int)x; int b = (int)(x>>32)? |
| 17:09:19 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 17:09:33 | archivator | saratoga: not in the fft, in the plot. The magnitude is >> 32-bit. |
| 17:09:53 | saratoga | i don't understand why? |
| 17:10:05 | kugel | if (b) y = 32+log2(b); else y = log2(a); |
| 17:10:05 | archivator | saratoga: accuracy, mainly. |
| 17:10:07 | saratoga | if you're processing 16 bit data, why do you need > 32 bit display resolution |
| 17:10:46 | archivator | kugel: I got it the first time, thanks :) |
| 17:11:11 | kugel | I don't get what you mean with "I wonder, though, whether there's a fast way to factorize a 64-bit number into 2 32-bit numbers.." |
| 17:11:48 | | Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) |
| 17:11:53 | Torne | well, there is, kinda. take a wild guess at the square root :) |
| 17:12:02 | archivator | saratoga: well, the components of the result are 32-bit numbers (16-bit fractional part). To calculate the magnitude, we need the sqrt(re*re+im*im). The inner sum is clearly > 32-bits, considering the fractional part |
| 17:12:25 | saratoga | only if you're not doing it right . . . |
| 17:12:35 | archivator | saratoga: enlighten me, please |
| 17:12:44 | archivator | I've been toying with this for a long time |
| 17:13:06 | saratoga | sqrt(re>>16*re>>16+im>>16*im>>16) |
| 17:13:17 | archivator | kugel: consider x (64-bit) = a * b (a, b - 32-bit). Then log(x) = log(a*b) = log(a) + log(b). And it's accurate. |
| 17:13:19 | saratoga | or use a fixed point multiply if you need more precision |
| 17:13:39 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
| 17:13:43 | saratoga | that'll do 32x32=64<<32 |
| 17:14:39 | | Quit Unhelpful (Remote host closed the connection) |
| 17:14:41 | saratoga | doing sqrt(re*re+im*im) with 64 bit ints would in some cases result in >> double precision accuracy when in fact that inputs are probably only accurate to a few decimal places |
| 17:15:19 | archivator | saratoga: I *am* using fixed-point multiply. And obviously the results of that sum don't fit in 32 bits. |
| 17:15:46 | kugel | archivator: ah ok, I got it |
| 17:15:49 | saratoga | then shift them until they do |
| 17:15:52 | archivator | I guess I *could* reduce the accuracy a bit, though.. |
| 17:17:45 | | Quit antil33t () |
| 17:19:13 | saratoga | basically when doing fixed point math, you shouldn't use bigger variable types to prevent overflow, but only to increase precision |
| 17:19:40 | saratoga | overflow should be avoided by shifting, and if you shift too much that rounding error becomes a problem then you use a bigger variable |
| 17:20:07 | | Quit n1s (Ping timeout: 276 seconds) |
| 17:20:07 | saratoga | but in practice computing a magnitude will only incur < 1 bit rounding error, so its not an issue here |
| 17:22:24 | archivator | saratoga: right. Let me get this straight. The results are s15.16. The magnitude is s31.16 (shift right 16 after multiply). Are you suggesting I discard the fractional part completely, so that it fits in 32 bits? |
| 17:22:42 | archivator | well, actually, the magnitude is always positive but the question stands. |
| 17:23:56 | saratoga | yes |
| 17:25:02 | archivator | Hm, let's see if that solves anything. |
| 17:30:02 | | Join Unhelpful [0] (~quassel@71.173.205.32) |
| 17:30:03 | | Quit Unhelpful (Changing host) |
| 17:30:03 | | Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) |
| 17:32:54 | | Quit MethoS- (Read error: Connection reset by peer) |
| 17:33:00 | saratoga | the final product is still accurate to 32 bits, and since the input data probably only ~ 16 bits, the rounding error is about 100 dB below the signal level |
| 17:33:03 | | Quit lpereira (Quit: Leaving.) |
| 17:33:08 | | Quit shaggy-h (Ping timeout: 240 seconds) |
| 17:36:11 | | Quit TillW (Quit: this concludes our broadcast day) |
| 17:38:31 | archivator | saratoga: what amazes me is that the magnitude doesn't seem to exceed 13 bits. But I have absolutely no idea where that bound comes from. |
| 17:38:54 | | Join funman [0] (~fun@182.174.86-79.rev.gaoland.net) |
| 17:38:55 | | Quit funman (Changing host) |
| 17:38:55 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 17:39:12 | saratoga | try it with a pure sin wave |
| 17:39:25 | | Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) |
| 17:39:50 | funman | dfkt: ping |
| 17:42:08 | | Join lnwlf [0] (~lnwlf@c-69-142-159-164.hsd1.pa.comcast.net) |
| 17:42:16 | | Join esperegu [0] (~quassel@145.116.15.244) |
| 17:43:31 | archivator | saratoga: well, larger than 14, smaller than 32 - maximum value I'm getting fits in 29 bits |
| 17:44:01 | saratoga | assuming your sin wave was full scale, then you can probably rescale the input to get more accuracy |
| 17:44:27 | saratoga | input to your magnitude calculation I mean |
| 17:45:12 | * | kugel wonders if accuracy is really an issue |
| 17:46:01 | saratoga | no probably not |
| 17:46:14 | kugel | in the end the accuracy is thrown away by the fact that you can only work with full pixels |
| 17:46:45 | lnwlf | winxp mounts my sansa fuze as a device under the 'other' category, rather than as a removable disk. the install util requires a letter mount. is there a work-around for this or should i be patching the install util to allow full mountpoint listings? |
| 17:46:48 | saratoga | its not really thrown away, since really what you care about is how well you can handle low signal levels |
| 17:47:17 | * | archivator feels like someone should write this plugin :( |
| 17:48:34 | saratoga | work on the codecs, you pick this up really fast when you can try things and listen to the result |
| 17:48:55 | FlynDice | lnwlf: make sure you're in msc mode, not auto or mtp |
| 17:49:38 | archivator | saratoga: one day, when I'm brave enough :) |
| 17:50:42 | AlexP | lnwlf: The manual tells you to do this (and why) |
| 17:50:53 | AlexP | lnwlf: er, I mean and how |
| 17:51:07 | archivator | Aaaaand, I just proved the sim is still broken. Gah. |
| 17:52:45 | lnwlf | flyndice: that did it. i read the install section of the manual and this wasn't mentioned; i clearly should've read further. |
| 17:53:08 | AlexP | lnwlf: It is mentioned it things to do before installing, no? |
| 17:53:29 | funman | i think the confusion between MTP and MSC is the top problem of users, according to the sandisk sansa forums |
| 17:54:07 | AlexP | It is the very first thing in the install chapter "Before Starting" |
| 17:54:11 | lnwlf | alex: no, it isn't. 'before starting' just says you need to know the letter mount |
| 17:54:18 | funman | i hope the confusion is not ported to rockbox along with MTP |
| 17:54:35 | AlexP | lnwlf: OK, it should do - other manuals do |
| 17:54:39 | AlexP | I'll fix it |
| 17:54:45 | lnwlf | cheers |
| 17:54:58 | AlexP | lnwlf: Could you tell me how you get there in the Sansa firmware? |
| 17:54:59 | lnwlf | it's obvious now that i think about it |
| 17:55:00 | funman | mpegplayer is broken on sansa AMSv2 (works fine on fuzev1) |
| 17:55:35 | funman | AlexP: settings->system->USB mode (translated from french) |
| 17:55:41 | AlexP | Thanks |
| 17:55:43 | lnwlf | alexp: main menu->settings->system settings->usb mode->msc |
| 17:55:51 | AlexP | Thanks 2 :) |
| 17:55:57 | saratoga | yeah i guess a lot of people might not realize a drive letter means MSC |
| 17:56:01 | archivator | Could someone please re-open FS #10816, the bug is still there |
| 17:56:51 | | Join Ste___ [0] (~562e14c1@giant.haxx.se) |
| 17:57:05 | saratoga | sure |
| 17:57:09 | lnwlf | saratoga: if people are in a hurry and haven't gone through the settings of their player or don't remember, they wouldn't know there was a usb mode selection at all |
| 17:58:02 | saratoga | reopened |
| 17:58:36 | Ste___ | pamaury: i read the logs about MTP, you need testers ? i have a H3xx and windows Vista ? |
| 17:59:14 | archivator | saratoga: thanks, I'll post some screenshots for proof. |
| 17:59:18 | Ste___ | dunno how to use git tho |
| 17:59:38 | saratoga | you can't use mtp on that player |
| 17:59:51 | kugel | archivator: do you know if it's codec dependant? |
| 17:59:55 | | Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) |
| 18:00 |
| 18:00:00 | Ste___ | saratoga, why not ? |
| 18:00:08 | saratoga | no software usb |
| 18:00:16 | Ste___ | isn't there ? |
| 18:00:19 | FlynDice | re: small animals, Careful PETA is watching... I was hoping sacrificing a small DAP would have pleased the SD Gods but it's starting to appear that it was dying before I killed it.... |
| 18:00:19 | kugel | archivator: I can try it with my alsa-lib sim work, maybe it's an SDL problem |
| 18:00:21 | Ste___ | i've used it before |
| 18:00:42 | saratoga | MTP? |
| 18:00:43 | * | FlynDice gazes in ranma's general direction and searches for signs of life... |
| 18:01:08 | archivator | kugel: shouldn't be. I've seen it with flac and wav already. Also, fft uses the buffer used to calculate volume peaks and that's codec-independent.. |
| 18:01:09 | FlynDice | ^^ was aimed at funman... |
| 18:01:18 | Ste___ | no usb |
| 18:01:29 | funman | FlynDice: :/ |
| 18:01:31 | saratoga | great, get back to me when you've tried MTP . . . |
| 18:01:37 | Ste___ | but with pamaurys latest work i was hoping ytop use mtp |
| 18:02:58 | CIA-5 | New commit by alex (r25748): Add that you need to be in MSC mode to the fuze manual. |
| 18:03:11 | AlexP | lnwlf: There you go :) |
| 18:03:18 | lnwlf | alexp: cheers |
| 18:03:24 | AlexP | Thanks for reporting |
| 18:04:10 | funman | AlexP: it's not only the fuze, but all sansa ams |
| 18:04:12 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
| 18:04:18 | AlexP | funman: Others already have it |
| 18:04:28 | funman | oh, can't it be a {sansaams} option ? |
| 18:04:38 | AlexP | But the location of the menu item is apparently different |
| 18:04:50 | FlynDice | it shouldn't be |
| 18:04:51 | AlexP | Or rather the menu item in the manual currently is different |
| 18:04:56 | AlexP | This might be wrong :) |
| 18:05:13 | lnwlf | does the firmware i provide for the install have to match the version on the device? what is that firmware image used for? |
| 18:05:35 | | Quit petur (Quit: FIN) |
| 18:05:48 | FlynDice | lnwlf: no, it needs to be recognized by mkamsboot though |
| 18:06:21 | kugel | lnwlf: we inject our code into it, so that the OF updater will install our bootloader for us |
| 18:06:25 | gevaerts | Ste___: the h200 has a hardware USB-ATA bridge |
| 18:06:28 | AlexP | FlynDice, funman: The manual currently has e200v2,clipv1,clipv2,clipplus using Settings -> USB mode not Settings -> System settings -> USB mode. Is this wrong? |
| 18:06:29 | gevaerts | h300 |
| 18:06:43 | | Join fyrestorm [0] (~nnscript@static-71-249-251-152.nycmny.east.verizon.net) |
| 18:07:02 | funman | AlexP: right, the correct path is the one mentioned today, for all models |
| 18:07:12 | AlexP | OK, I'll change it. |
| 18:07:27 | | Quit Topy44 (Ping timeout: 276 seconds) |
| 18:07:29 | Ste___ | gevaerts which means ? |
| 18:08:21 | gevaerts | which means it handles MSC in hardware, and we can't change usb behaviour |
| 18:08:23 | linuxstb | Ste___: It means no MTP on the h300. |
| 18:08:47 | FlynDice | AlexP: Settings -> System settings -> USB mode-> MSC is what I just observed on clip+ |
| 18:08:56 | Ste___ | :o( |
| 18:09:04 | pixelma | reminds me |
| 18:09:06 | | Join Topy44 [0] (~topy@my.fastsh.it) |
| 18:09:52 | | Quit lifeless__ (Ping timeout: 264 seconds) |
| 18:10:04 | | Join lifeless_ [0] (~lifeless@188.18.74.20) |
| 18:10:08 | AlexP | FlynDice, funman: I'll make all sansaAMS Settings -> System settings -> USB mode and leave old Sansa as Settings -> USB mode |
| 18:10:55 | funman | is the e200v2 menu different from e200v1 ? i don't think so |
| 18:11:02 | AlexP | Anyone have an old Sansa to hand to check? |
| 18:11:10 | AlexP | The old ones might be wrong too :) |
| 18:11:11 | *** | Saving seen data "./dancer.seen" |
| 18:11:15 | * | FlynDice is checking e200v2 right now |
| 18:11:26 | funman | i guess the entry assumed the user was already in the settings menu |
| 18:12:09 | AlexP | Then it got the name of System settings wrong |
| 18:12:46 | FlynDice | hmmm e200v2 is Settings-> USB Mode-> MSC |
| 18:12:54 | AlexP | Bum |
| 18:13:15 | AlexP | So the old ones are OK along with the e200v2 |
| 18:13:26 | AlexP | and the clips + fuze are different? |
| 18:13:32 | * | kugel checks e200v1 |
| 18:13:48 | kugel | same as e200v2 |
| 18:13:59 | funman | clipv2/clipv1 are the same as e200v2 |
| 18:14:30 | AlexP | So just clip+, fuze that are different |
| 18:17:00 | CIA-5 | New commit by alex (r25749): Correct path to set MSC mode in the OF for the Clip+ |
| 18:17:41 | funman | kugel: r25491 broke mpegplayer on fuzev2 :/ |
| 18:18:44 | ranma | FlynDice: Dunno if you saw it yesterday, but I got the JTAG working. However internal storage is borked, the internal sd card does not initialize properly. |
| 18:19:31 | | Join lifeless__ [0] (~lifeless@90.151.222.231) |
| 18:19:33 | | Nick lnwlf is now known as lnwlf-away (~lnwlf@c-69-142-159-164.hsd1.pa.comcast.net) |
| 18:21:43 | funman | kugel: ah you forgot PLUGIN_USE_IRAM |
| 18:23:08 | | Quit lifeless_ (Ping timeout: 258 seconds) |
| 18:23:24 | kugel | oops |
| 18:24:01 | funman | it's weird that it doesn't use the same condition than *_ATTR .. |
| 18:24:34 | funman | ah no.. it must be set in the build, not only in plugins i htink |
| 18:25:16 | dfkt | funman: pong |
| 18:25:50 | CIA-5 | New commit by funman (r25750): as3525v2: do not use IRAM for plugins |
| 18:26:02 | funman | dfkt: the last messages on the ABI clip+ thread are interesting |
| 18:26:27 | dfkt | the new bootloader working with new builds, but giving blank screen with old ones? |
| 18:26:47 | funman | yes, because the code for CPU frequency isn't the same |
| 18:26:49 | FlynDice | ranma: Yes I saw that and was disappointed.... I was hoping that I screwed it up trying to recover it with dd but it appears it was hardware failure after all :(. Thanks for giving it a shot. Perhaps JdGordon can use your photos to get his bricked unit hooked up. |
| 18:27:14 | funman | so both old & new builds assume that the bootloader has left the settings in some state |
| 18:27:26 | funman | can you tell me an old revision which doesn't work with the new bootloader ? |
| 18:27:54 | dfkt | i've been running r25407 more or less 'stable' so far |
| 18:28:25 | | Join TopyMobile [0] (~topy@f054208033.adsl.alicedsl.de) |
| 18:29:23 | kugel | funman: it looks like I broke some microsds (see forum thread) |
| 18:29:36 | | Join merbanan [0] (~banan@c-94-255-217-199.cust.bredband2.com) |
| 18:29:44 | dfkt | funman: meaning, that one doesn't work on the new bootloader, but works fine on the old one |
| 18:30:04 | kugel | probably a miscalculation in the mci_delay to udelay conversion |
| 18:30:08 | funman | dfkt: oki, i'll see if i can make a sense of it |
| 18:30:33 | dfkt | good luck :) |
| 18:31:51 | funman | dfkt: btw you know we have a 'stable' 1.0 bootloader for clip+ ? |
| 18:32:09 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 18:32:17 | dfkt | nope, didn't know |
| 18:32:32 | dfkt | how to get it? :) |
| 18:32:35 | | Join lpereira [0] (~lucien@112.46.70-86.rev.gaoland.net) |
| 18:32:38 | funman | old bootloader + current revision works fine for me :o |
| 18:32:39 | | Part avar |
| 18:33:01 | funman | dfkt: http://www.rockbox.org/wiki/SansaAMS#Installation_for_Stable_e200v2_F => clip+ |
| 18:33:34 | dfkt | oh nice! |
| 18:33:47 | * | dfkt installs r25747 |
| 18:34:15 | funman | hm that's intended, the only not working combination is new bootloader + old revision |
| 18:34:48 | dfkt | newer revisions crashed within seconds of playback for me (on the new bootloader) |
| 18:35:27 | dfkt | last one i tried was r25737 - crashed after a few seconds of mp3 playback |
| 18:35:32 | funman | possibly, boost the CPU (debug menu -> cpu frequency) and it should be better |
| 18:35:42 | dfkt | thanks, will try that |
| 18:36:15 | funman | r25407 is a few revisions before dynamic cpufreq |
| 18:37:06 | Ste___ | I've bene using r25388 for weeks now with no problems |
| 18:37:19 | Ste___ | s/bene/been |
| 18:37:48 | Ste___ | other than the write one of course |
| 18:38:22 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 18:38:52 | | Join Luca_S [0] (~5d3fc54b@giant.haxx.se) |
| 18:40:32 | Luca_S | so, if FlynDice's clip+ had an hardware failure, it is actually possible that the code for sd writing works and just hasn't been noticed? |
| 18:41:13 | Luca_S | (I can distinctly hear the sound of nails on glass, but hope is cheap :) ) |
| 18:41:23 | Schmogel | didnt two clip+ brick? |
| 18:41:50 | | Quit LambdaCalculus37 (Quit: Fwump) |
| 18:42:38 | funman | Luca_S: i don't see the link between the two |
| 18:45:45 | dfkt | funman: running great for ~3 minutes with bootloader v1.0, current revision, and boost at 1 :) |
| 18:46:35 | funman | bootloader 1.0 is more or less the same than the first one you posted |
| 18:46:42 | funman | except it says '1.0' :) |
| 18:48:18 | Ste___ | is that the 1.0-rc ? |
| 18:49:01 | funman | Ste___: no |
| 18:49:19 | Ste___ | is there any difference apart from the text string ? |
| 18:49:34 | ranma | FlynDice: I haven't given up on it completely yet though. I'd like to poke the NAND directly or at least use a logic analyzer to trace it's accesses maybe. But that'll likely have to wait until I'm back in germany. I'm assuming it's normal NAND and the SD controller half of this thing is in the SoC. |
| 18:49:57 | funman | Ste___: does it matter? |
| 18:50:32 | Ste___ | not really. |
| 18:50:34 | | Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) |
| 18:50:42 | funman | ranma: afaik it's the ONFI 48 pin layout |
| 18:51:40 | | Quit jnss (Remote host closed the connection) |
| 18:52:15 | ranma | Luca_S: Well there is the small possibility that something caused the NAND controller to corrupt it's FTL. I'd like to have tried an 'erase all' command, but since it fails initialization quite early that's apparently not an option. |
| 18:53:22 | ranma | If I talk to the NAND directly and dump it's contents, maybe I can see if it is corrupted or not. |
| 18:54:23 | ranma | Or first use a logic analyzer to see if the communication between SoC and the NAND works correctly. |
| 18:55:34 | Luca_S | a logic analyzer is something like this? http://www.codeproject.com/KB/system/17ChannelLogicAnalyzer.aspx |
| 18:56:10 | | Quit ender` (Quit: It's all fun and games until someone loses an eye. Then it's fun and games you can't see.) |
| 18:57:00 | Luca_S | sorry, disregard my previous sentence. |
| 18:57:05 | | Join Lear [0] (chatzilla@rockbox/developer/lear) |
| 18:57:17 | ranma | Luca_S: In principle, yes. Parallel port might be a bit slow for this purpose though ;) |
| 18:58:47 | | Quit flydutch (Quit: /* empty */) |
| 18:59:06 | | Quit Ste___ (Quit: CGI:IRC) |
| 18:59:44 | | Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) |
| 19:00 |
| 19:00:17 | | Quit merbanan (Read error: Operation timed out) |
| 19:00:58 | | Join w1ll14m [0] (~w1ll14m@84-104-80-54.cable.quicknet.nl) |
| 19:03:24 | | Join DataGhost [0] (~dataghost@192-18-ftth.onsnetstudenten.nl) |
| 19:03:24 | | Quit DataGhost (Changing host) |
| 19:03:24 | | Join DataGhost [0] (~dataghost@unaffiliated/dataghost) |
| 19:09:40 | funman | so.. r25416 is the first revision which works with the new bootloader. unfortunately for users it's also using adjustable cpu freq |
| 19:10:12 | funman | the difference with previous not working r25415 is that CGU_PROC sets fclk to be 24MHz just before clearing CGU_PERI divider; so pclk doesn't go too high |
| 19:10:37 | funman | note that there is no delay at all after modifying CGU_PROC so I assume fclk change is instant |
| 19:16:26 | funman | is casting an int to a function pointer not possible ? |
| 19:18:17 | kugel | it should work but it's of course highly discouraged, int and pointers don't have the same size on some platforms |
| 19:19:36 | funman | of course i was using intptr_t |
| 19:19:39 | | Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) |
| 19:20:10 | funman | UNCACHED_ADDR(function) gives error: cast specifies function type |
| 19:20:46 | | Quit DerPapst (Quit: Leaving.) |
| 19:21:03 | archivator | saratoga: can I please get your opinion on this: http://pastebin.com/hqv5z0PA ? Is that what you were describing? |
| 19:21:12 | funman | anyway putting set_cpu_frequency in uncached memory doesnt' cause faster crashes |
| 19:21:21 | gevaerts | funman: UNCACHED_ADDR for a function? Why? |
| 19:21:43 | funman | gevaerts: to force loads from memory when this function is running |
| 19:22:50 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 19:23:19 | archivator | saratoga: sorry, that while should be an if, really. |
| 19:23:21 | | Quit stripwax (Client Quit) |
| 19:23:22 | | Part watto |
| 19:23:39 | archivator | and I guess tmp should be unsigned.. |
| 19:23:58 | funman | archivator: shouldn't you just test if bit 31 is set ? |
| 19:24:55 | archivator | funman: which one is faster cycle-wise? |
| 19:25:46 | | Quit Luca_S (Quit: CGI:IRC (EOF)) |
| 19:25:55 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 19:26:11 | kugel | depends on what gcc is doing... |
| 19:26:46 | funman | AND can be one instruction, but otoh there is a condition for testing positive/negative |
| 19:26:59 | | Join [1]w1ll14m [0] (~w1ll14m@84-104-80-54.cable.quicknet.nl) |
| 19:26:59 | funman | hum ... if set_cpu_frequency() is uncached it crashes much less |
| 19:27:28 | kugel | but still crashes? |
| 19:27:39 | funman | no i shut it down befoer |
| 19:27:50 | funman | http://pastie.org/939487 <- can you try this on Clipv2/Clip+/Fuzev2 ? |
| 19:29:01 | kugel | why do you think reading from mem solves the problems? |
| 19:29:09 | | Quit w1ll14m (Ping timeout: 248 seconds) |
| 19:29:09 | | Nick [1]w1ll14m is now known as w1ll14m (~w1ll14m@84-104-80-54.cable.quicknet.nl) |
| 19:29:17 | funman | no idea, i was expecting it would crash faster in fact ;) |
| 19:29:35 | funman | crashes are still random, a deterministic way to reproduce them would help in debugging |
| 19:29:46 | | Join Horscht [0] (~Horscht2@xbmc/user/horscht) |
| 19:29:56 | kugel | are irqs disabled during freq changing? |
| 19:30:02 | funman | my supposition was that pclk was not stable |
| 19:30:08 | kugel | ah, yes the paste shows it |
| 19:30:11 | funman | yes, we do that on purpose |
| 19:30:16 | | Quit phanboy4 (Read error: Connection reset by peer) |
| 19:30:40 | funman | my supposition was that pclk was not stable, and that memory loads would return garbage, but would work if the whole function was in cache |
| 19:31:55 | funman | or at least the part which is executed after pclk is changed |
| 19:32:25 | funman | i have a ~1 hour song playing, if it finishes i'll say there are no crashes if the function is uncached |
| 19:33:23 | funman | caches are internal to the CPU and do not rely on peripheral bus, right? |
| 19:39:00 | | Join Kitr88 [0] (~Kitar_st@BSN-182-24-153.dial-up.dsl.siol.net) |
| 19:39:06 | funman | disabling only the icache still crashes |
| 19:39:34 | | Join TillW [0] (~Till@h92-net09.simres.netcampus.ca) |
| 19:42:08 | | Quit Kitar|st (Ping timeout: 246 seconds) |
| 19:42:45 | funman | disabling only the dcache still crashes |
| 19:43:08 | | Quit Kitr88 (Ping timeout: 240 seconds) |
| 19:44:20 | funman | disabling both still crashes :o |
| 19:46:02 | | Join Transformer [0] (~Transform@ool-4a59e397.dyn.optonline.net) |
| 19:47:20 | saratoga | archivator: I would use actual fixed point multiply routines like the codecs use |
| 19:47:24 | | Part Transformer |
| 19:47:25 | | Quit JohannesSM64 (Ping timeout: 246 seconds) |
| 19:47:28 | saratoga | rather then just doing integer multiplies |
| 19:48:36 | archivator | saratoga: I was mistaken, those are not fixed-point numbers. |
| 19:49:02 | | Join Kitar|st [0] (Kitar_st@BSN-182-54-58.dial-up.dsl.siol.net) |
| 19:49:05 | archivator | It doesn't make sense to have the results of an fft have fractional parts, does it? |
| 19:49:41 | | Quit Lear (Quit: ChatZilla 0.9.86 [Firefox 3.6.4/20100413172113]) |
| 19:49:42 | saratoga | why not? |
| 19:50:52 | archivator | saratoga: I would imagine that a fractional result can always be expressed as two integer results of different magnitudes (it *is* a sum of waves, after all). |
| 19:51:51 | saratoga | http://pastebin.com/jRYQN1Wu |
| 19:51:59 | saratoga | thats how you should compute the magnitude |
| 19:52:22 | saratoga | well on arm, grab the c and coldfire verisons as well from wma |
| 19:52:39 | saratoga | i don't really get what you're saying about fractional parts |
| 19:52:52 | archivator | saratoga: I have no idea what that does but if you say so, that's how I'll do it. |
| 19:52:55 | saratoga | the output of the fft is just binary, you can ascribe whatever number system you like to it |
| 19:53:10 | saratoga | integer, fractional, etc are all the same thing |
| 19:53:30 | archivator | saratoga: well, yes. I was thinking about it from a mathematical point of view. Anyway, thanks a lot for your help. |
| 19:53:48 | archivator | I'm afraid I have to go now but I'll soon post a patch on FS with your suggestions. |
| 19:54:22 | saratoga | it does (int32_t) x * (int32_t) y = (int64_t)(z<<32) where z is initially 64 bit |
| 19:54:40 | saratoga | theres actually no way to say that explicitly in c, but thats roughly the idea |
| 19:55:13 | saratoga | (int32_t) x * (int32_t) y = (int32_t)(z<<32) |
| 19:55:17 | saratoga | sorry thats what it should read |
| 19:55:30 | saratoga | all the types are 32 bit but the shift is done in 64 bit precision |
| 20:00 |
| 20:00:22 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 20:01:37 | | Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) |
| 20:01:41 | funman | ok i got a crash with my first patch.. but it took much longer |
| 20:02:01 | funman | if others can confirm it crashes much less often then perhaps we can learn something |
| 20:02:52 | funman | can you try http://pastie.org/939487 on as3525v2 and NOT force cpu boosting ? |
| 20:05:14 | ThomasAH | funman: current svn + http://pastie.org/939487 on clip+? I can test it later today |
| 20:06:24 | | Quit esperegu (Read error: Connection reset by peer) |
| 20:07:34 | | Join esperegu [0] (~quassel@145.116.15.244) |
| 20:10:37 | kugel | funman: might the micro delays be to short or too ling? |
| 20:10:40 | kugel | too* |
| 20:10:59 | funman | ThomasAH: yep |
| 20:11:14 | *** | Saving seen data "./dancer.seen" |
| 20:11:20 | funman | kugel: i don't see why they would be too long (the only effect would be to slow down the function), too short: it's possible |
| 20:12:07 | funman | the delay after setting CGU_PROC could be removed though (according to what i said earlier |
| 20:12:30 | kugel | why set CGU_PERI after CGU_PROC? the comment suggests it could be too high. I'd think CGU_PREI should be set before |
| 20:13:30 | funman | kugel: because if we're doing unboosted->boosted; the pclk divider will be higher |
| 20:14:08 | kugel | I'm looking at the ->unboosted case |
| 20:14:51 | kugel | it might also worth returning for boosted->boosted and unboosted->unboosted calls |
| 20:14:52 | funman | there we will use a lower pclk divider |
| 20:15:05 | funman | i think it's handled by cpu_boost() already |
| 20:15:06 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
| 20:15:20 | kugel | no idea |
| 20:15:33 | funman | if we change cgu_peri first, we'll apply a low divider to a high fclk => high pclk |
| 20:16:02 | kugel | ah, so the comment is a bit confusing |
| 20:16:15 | funman | what should it be ? |
| 20:16:51 | kugel | did you check the disassembly whether the registers are changed atomically? |
| 20:17:30 | kugel | hm, I guess that's the only way on ARM anyway |
| 20:19:00 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 20:24:11 | | Join Boldfilter [0] (~Boldfilte@adsl-82-151-224.jax.bellsouth.net) |
| 20:25:13 | | Quit n1s (Quit: Lämnar) |
| 20:26:54 | | Join Luca_S [0] (~5711b744@giant.haxx.se) |
| 20:27:21 | Luca_S | usually flipping the EQ presets hangs the player quickly... |
| 20:28:07 | | Quit TopyMobile (Ping timeout: 240 seconds) |
| 20:28:37 | | Quit JohannesSM64 (Max SendQ exceeded) |
| 20:29:06 | funman | just tried 2 times and it worked |
| 20:29:28 | funman | note, perhaps the crash i had wasn't related to cpufreq (screen went black, although i have backlight timeout set to 0) |
| 20:30:37 | | Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) |
| 20:31:05 | | Quit JohannesSM64 (Max SendQ exceeded) |
| 20:31:58 | | Join Strife89 [0] (~michael@168.16.237.214) |
| 20:32:23 | | Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) |
| 20:32:50 | | Quit JohannesSM64 (Max SendQ exceeded) |
| 20:32:57 | | Join DerPapst [0] (~Alexander@p4FE8FD1C.dip.t-dialin.net) |
| 20:34:03 | | Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) |
| 20:34:19 | Luca_S | whoa, today's version no longer loses backlight when exiting plugins - great work :D |
| 20:34:55 | kugel | no problem! :) |
| 20:35:21 | kugel | good we never figured out the cause, no we didn't even figure out the fix :P |
| 20:36:52 | funman | i've put a clip+ build with the patch on http://http//rafael.carre.perso.sfr.fr/rockbox-r25750M-100428-clipplus.zip (and i posted the link on ABI) |
| 20:36:57 | funman | -http:// |
| 20:42:12 | | Quit TheSeven (Ping timeout: 248 seconds) |
| 20:42:42 | | Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) |
| 20:46:04 | | Quit Luca_S (Quit: CGI:IRC (EOF)) |
| 20:50:12 | funman | still running .. quite good ! |
| 21:00 |
| 21:05:03 | archivator | saratoga: you sure about that fixmul32 business? The output from kiss_fft is almost entirely in the lower 16 bits of .i and .r and it gets truncated to 0. (since fixmul32 is basically (int32_t) (((int64_t) x * y) >> 16) for the sim). |
| 21:05:24 | funman | kugel: you checked if the new mci_delay() was correct (not too fast)? |
| 21:06:20 | archivator | Those are not fixed-point numbers, they're whole integers, almost exclusively < 2^16. There's absolutely no point in all the shifting around.. |
| 21:06:38 | | Join Transformer [0] (~Transform@ool-4a59e397.dyn.optonline.net) |
| 21:07:26 | | Part Transformer |
| 21:07:59 | kugel | funman: I calculated 4*65000*(1/250MHz) |
| 21:09:37 | funman | sounds right |
| 21:09:45 | kugel | it might be off a bit, but my own microsd worked so I thought it would be fine |
| 21:09:47 | funman | it's longer when unboosted though |
| 21:10:23 | | Join komputes_ubuntu [0] (~komputes@ubuntu/member/komputes) |
| 21:11:27 | saratoga | archivator: for what test signal? |
| 21:11:59 | archivator | saratoga: for any test signal. Including the 1 kHz sine wave I used before. |
| 21:13:07 | | Quit komputes (Ping timeout: 240 seconds) |
| 21:13:14 | archivator | Remember how I said there's 29-bit upper bound on the magnitude? Yeah, that was with the straight multiplication (meaning, the individual components fit in 14 bits) |
| 21:13:15 | saratoga | well the amplitude should be a lot different for a sin then for other signals |
| 21:13:40 | archivator | saratoga: true but that's empirical evidence, I'm not guessing here. |
| 21:13:52 | saratoga | I don't follow you |
| 21:14:48 | archivator | using tmp = output[i].r * output[i].r + output[i].i * output[i].i will give you at most 29 bits. Meaning, output[i].r and output[i].i can be at most 14 bits. |
| 21:15:04 | saratoga | for a sin right? |
| 21:15:06 | archivator | That's experimental evidence, I'm not sure what causes it. |
| 21:15:14 | archivator | for anything, including a sine wave. |
| 21:15:36 | saratoga | you tested it with a sin right? because testing anything but a sin or cos will not give you a useful result here . . . |
| 21:16:05 | archivator | I did. That's where it peaks at 29 bits. |
| 21:16:26 | saratoga | ok so it sounds like you're using a 16 bit FFT, or have not scaled some of the values in the fft correctly |
| 21:16:58 | archivator | well, the data I'm giving it is indeed 16 bits. So, it makes sense that the results are in the same bounds, doesn't it? |
| 21:17:06 | | Quit lpereira (Quit: Leaving.) |
| 21:17:45 | | Join DataGhost_ [0] (~dataghost@192-18-ftth.onsnetstudenten.nl) |
| 21:17:45 | | Quit DataGhost (Disconnected by services) |
| 21:17:46 | | Nick DataGhost_ is now known as DataGhost (~dataghost@192-18-ftth.onsnetstudenten.nl) |
| 21:18:40 | | Join lpereira [0] (~lucien@112.46.70-86.rev.gaoland.net) |
| 21:19:23 | saratoga | your FFT operates on 32 bit data |
| 21:19:28 | saratoga | how are you feeding it 16 bit data? |
| 21:20:29 | saratoga | looking at your makefile, you define "FIXED_POINT=16" |
| 21:21:07 | | Quit DataGhost (Client Quit) |
| 21:21:34 | archivator | I might have been doing it wrong (though I swear it works!). Okay, I'll shift the input data and see what happens. |
| 21:22:50 | ThomasAH | now at the laptop and building the patched svn ... |
| 21:23:11 | saratoga | what precision are the trig constants in? |
| 21:26:41 | archivator | saratoga: calculated at runtime. Never got around to pre-calculating them. 16-bit fractional part. |
| 21:28:27 | saratoga | so 16 bit |
| 21:29:51 | saratoga | (x)->r = ( Q_MUL(SAMP_MAX << 16, cos >> 15, 16) ) >> 16; |
| 21:30:09 | saratoga | SAMP_MAX << 16 is 0xFFFFFFFF |
| 21:30:39 | saratoga | cos is a 32 bit value corrisponding to all the values between -1 and 1 |
| 21:30:51 | saratoga | so it truncates that to 16 bit |
| 21:31:12 | saratoga | then multiplies it times the 32 bit value to get the original 32 bit value back, except with 65536 times the rounding error |
| 21:31:29 | saratoga | then truncates that a second time down to 16 bit |
| 21:31:43 | saratoga | conclusion: this fft is not a good fft |
| 21:31:48 | | Quit Zagor (Quit: Clint excited) |
| 21:32:26 | archivator | I only replaced the sin/cos functions with the rockbox, the transformations were in the original.. |
| 21:32:40 | archivator | rockbox version* |
| 21:33:45 | archivator | in any case, what do you propose? |
| 21:34:31 | | Join DataGhost [0] (~dataghost@unaffiliated/dataghost) |
| 21:34:37 | archivator | How do I use the codecs library for real-valued input? |
| 21:35:04 | saratoga | well the guts of the thing are kind of brain dead since it can only do efficient fixed point math on 16 bit precision variables |
| 21:35:30 | saratoga | if 16 bit precision is good enough, just use that |
| 21:35:57 | archivator | saratoga: it's a demo, not a codec. Of course it's good enough! :) |
| 21:36:15 | saratoga | then quit complaining about only getting 16 bit precision results |
| 21:36:27 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 21:37:16 | archivator | I'm not complaining about the 16 bits of precision, I was complaining about the overflow issues. Which seem to be alright now. |
| 21:44:51 | ThomasAH | funman: my first impression is that it works great now ... I have voice clips enabled and often had crashes when navigating through folders and changing volume. |
| 21:46:22 | funman | 'had' refer to patched build or unpatched builds? |
| 21:49:32 | ThomasAH | funman: 'had' refered to 256xx + cherry-picked patch to allow lower volume |
| 21:50:16 | ThomasAH | funman: with newer unpatched svn revisions I had so many crashes that I always downgraded immediately |
| 21:50:55 | funman | ok |
| 21:52:04 | ThomasAH | funman: but now with r25750 + your patch it works great as far as I can see now ... even switching to radio, back to ogg files, while playing starting plugins (cube, fft, fractals, vu_meter) |
| 21:52:04 | | Quit RadicalR (Ping timeout: 245 seconds) |
| 21:52:29 | ThomasAH | funman: and while moving through the menus the voice clips playing |
| 21:52:38 | funman | please torture it as much as you can, so we can be sure this workaround the crashes |
| 21:52:52 | ThomasAH | funman: will do :) |
| 21:52:56 | funman | then we can go to the next step: understand why it does so :) |
| 21:53:21 | ThomasAH | :) |
| 21:53:31 | funman | perhaps the answer would just be longer delays |
| 21:54:35 | | Quit JohannesSM64 (Quit: WeeChat 0.3.2-dev) |
| 21:54:55 | | Join angelwolf71885 [0] (~chatzilla@cpe-173-171-133-36.tampabay.res.rr.com) |
| 21:55:16 | ThomasAH | ok, off to bed, listening to some music or audio book :) |
| 21:56:01 | | Quit angelwolf71885 (Client Quit) |
| 21:56:28 | | Join angelwolf71885 [0] (~chatzilla@cpe-173-171-133-36.tampabay.res.rr.com) |
| 21:58:06 | | Quit angelwolf71885 (Client Quit) |
| 21:59:13 | | Quit funman (Quit: free(random());) |
| 22:00 |
| 22:00:01 | FlynDice | funman: Longer udelay value seems to clear up most of my uSD clip+ issues, Got about an hour crash free with your uncached boost patch also. |
| 22:00:31 | | Join RadicalR [0] (~radicalr@c-69-255-49-110.hsd1.va.comcast.net) |
| 22:03:19 | kugel | err, I think I made a mistake with my udelay logic |
| 22:04:36 | | Join RadicalR2 [0] (~radicalr@c-69-255-49-110.hsd1.va.comcast.net) |
| 22:04:37 | | Quit RadicalR (Read error: Connection reset by peer) |
| 22:04:48 | | Quit Strife89 (Quit: See y'all.) |
| 22:05:12 | kugel | uhm yes |
| 22:05:55 | FlynDice | well, I'll see your mistake and raise you a uSD test mistake, disregard the uSd issues comment above. It works better but there's still some problems. |
| 22:05:56 | kugel | the udelay to timer changes convertion needs to be with 3/2, not 2/3 |
| 22:11:16 | *** | Saving seen data "./dancer.seen" |
| 22:13:20 | | Nick advcomp2019_ is now known as advcomp2019 (~advcomp20@unaffiliated/advcomp2019) |
| 22:17:48 | kugel | FlynDice: try that please http://pastie.org/939819 |
| 22:18:16 | FlynDice | sure |
| 22:18:20 | | Quit ender` (Quit: I'd kill for a Nobel Peace Prize.) |
| 22:21:21 | kugel | udelay is off pretty badly |
| 22:25:35 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 22:27:36 | | Join [1]w1ll14m [0] (~w1ll14m@84-104-80-54.cable.quicknet.nl) |
| 22:29:14 | | Part domonoky |
| 22:30:25 | | Quit w1ll14m (Read error: Operation timed out) |
| 22:30:25 | | Nick [1]w1ll14m is now known as w1ll14m (~w1ll14m@84-104-80-54.cable.quicknet.nl) |
| 22:35:52 | archivator | saratoga: Thanks for all the help, btw. I learned a lot today :) |
| 22:38:27 | | Quit lpereira (Quit: Leaving.) |
| 22:47:41 | FlynDice | kugel: Nothing observable changes with that patch if I don't make any modifications. If I try to increase the delay to increase mci_delay it panics with "udelay(): 10000 too high!". |
| 22:50:12 | FlynDice | If you do get this udelay() sorted out I would think it would be better to use tailored udelay(value) than a standard mci_delay() wouldn't it? |
| 22:50:39 | | Join dantje_ [0] (~dvg@HSI-KBW-095-208-155-207.hsi5.kabel-badenwuerttemberg.de) |
| 22:51:00 | CIA-5 | New commit by wodz (r25751): HD200 - fix compile warning in debug_menu.c |
| 22:51:20 | | Join wodz [0] (~wodz@chello087206240004.chello.pl) |
| 22:52:21 | wodz | amiconn: ping |
| 22:54:25 | saratoga | no problem |
| 22:54:31 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 22:55:29 | CIA-5 | New commit by b0hoon (r25752): Packard Bell Vibe: language corrections in the manual, thanks to: AlexP, linuxstb. |
| 22:57:17 | wodz | hmm I have no luck today to have a chat with amiconn :-/ |
| 22:59:19 | kugel | FlynDice: probably |
| 22:59:31 | kugel | the udelay should work with that change. can you try 5000? |
| 22:59:41 | FlynDice | sure |
| 23:00 |
| 23:00:28 | | Quit esperegu (Read error: Connection reset by peer) |
| 23:00:52 | | Join phanboy4 [0] (~benji@gate-20.spsu.edu) |
| 23:01:06 | | Join shai_ [0] (~Shai@l192-117-110-233.cable.actcom.net.il) |
| 23:01:11 | | Quit phanboy4 (Client Quit) |
| 23:01:17 | | Quit Battousai (Read error: Operation timed out) |
| 23:01:17 | | Quit shai (Read error: Connection reset by peer) |
| 23:01:33 | | Quit dantje_ (Quit: Ex-Chat) |
| 23:02:52 | | Join Battousai [0] (~bryan@gentoo/developer/battousai) |
| 23:06:09 | FlynDice | kugel: I don't get the panic using 5000 but it doesn't make anything work any better. |
| 23:07:03 | FlynDice | back later |
| 23:07:55 | | Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) |
| 23:11:36 | | Quit efyx (Remote host closed the connection) |
| 23:22:40 | | Join bmbl [0] (~Miranda@dsl18-47.pool.bitel.net) |
| 23:22:40 | | Quit bmbl (Changing host) |
| 23:22:40 | | Join bmbl [0] (~Miranda@unaffiliated/bmbl) |
| 23:24:50 | kugel | 5000 is really a huge delay, it should be much longer than the old mci_delay() |
| 23:28:46 | | Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) |
| 23:30:05 | | Quit pamaury (Quit: Page closed) |
| 23:30:18 | | Quit evilnick_B (Quit: Page closed) |
| 23:34:09 | | Quit robin0800 (Remote host closed the connection) |
| 23:37:16 | | Quit Schmogel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 23:37:31 | | Quit CGL (Quit: Saliendo) |
| 23:40:14 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 23:47:18 | | Quit RadicalR2 (Ping timeout: 265 seconds) |
| 23:47:25 | | Quit bmbl (Quit: Bye!) |
| 23:47:27 | archivator | I think FS #11219 is complete, anyone mind looking into it/committing it? |
| 23:47:57 | | Join RadicalR [0] (~radicalr@c-69-255-49-110.hsd1.va.comcast.net) |
| 23:52:37 | | Quit RadicalR (Ping timeout: 265 seconds) |
| 23:52:38 | | Quit S_a_i_n_t (Read error: Connection reset by peer) |
| 23:53:30 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.1.192) |
| 23:54:02 | kugel | archivator: does it fix any existing problem? |
| 23:56:01 | | Join RadicalR [0] (~radicalr@c-69-255-49-110.hsd1.va.comcast.net) |
| 23:56:49 | | Quit kugel (Remote host closed the connection) |
| 23:57:45 | | Quit jgarvey (Quit: Leaving) |
| 23:58:56 | | Quit stripwax (Quit: http://miranda-im.org) |
icon identifies that the person is a core developer (has commit access).