Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2010-04-28

00:00:17 Quit TheSeven (Ping timeout: 248 seconds)
00:00:46pamauryarchivator: 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:48amiconnpamaury: fat_size reports in KB exactly for the reason to avoid 64 bit integers.
00:02:19pamauryamiconn: yeah I understood that finally :)
00:02:51archivatorpamaury: well then, I'm out of ideas. :(
00:03:51pamauryit's strange that is locks this way. Why is there a waiting splash ?
00:04:46 Join stripwax [0] (
00:05:11 Quit stripwax (Client Quit)
00:05:14pamauryfunman: 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] (
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:25archivatorpamaury: I'm pretty sure the splash was the cause of the slowness with the previous patch.
00:08:43pamaurybut you didn't remove it
00:09:15archivatorI just reached that conclusion :)
00:09:37pamauryah, then I can try to remove it if it makes sense
00:09:58archivatorpamaury: not with what I last gave you. Give me a sec
00:10:32funmanpamaury: 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:58pamauryThink twice because i will go to bed soon, so that's your last attempt
00:11:19pamauryfunman: I can try to break another MTP transfer for sure if you want :)
00:11:26pamaury*for you
00:11:56pamauryit could also be that the file was not broken and was just weird
00:12:06*pamaury checks
00:12:09pixelmawodz: 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:54pixelmait'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:31archivatorpamaury: try this please: :)
00:14:51 Join robin0800 [0] (
00:15:11*bluebroth3r spots an old stash where he wanted to libify ipodpatcher for rbutil
00:15:18bluebroth3rI should pick that up again ...
00:15:50pamauryfunman: I just checked and indeed, it was because the file was incomplete, I can't reproduce it with the complete file
00:16:11pamauryarchivator: it works \o/
00:16:50 Quit robin0800 (Remote host closed the connection)
00:16:59archivatorbluebroth3r: I have a script that pops up a window with all my forgotten stashes in my session just for cases like yours! :)
00:17:25archivatorpamaury: slowly or normally?
00:17:32pamaurylike a charm
00:17:38 Quit jgarvey (Quit: Leaving)
00:17:40archivatorAll the modes?
00:18:02pamauryno, I was about to say that only lines mode work correctly, other mode don't display anything
00:18:41pamauryhum false, spectogram works, only bars doesn't, but switch between them is not reliable
00:19:32archivatorbars is a bit unreliable as it is, don't worry about it.
00:19:54pamaurybars doesn't work in playback for me
00:20:13archivatorWhat do you mean switching is not reliable? Takes time to react or doesn't work at all?
00:20:26pamaurytakes time to react, sometimes it gets ignored
00:20:35archivatoryeah, 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:38pamaurylines and spectorgram modes are cool so it's not a real issue, at least it works for recording
00:22:21archivatorYeah, gonna add some documentation to the source code and post it on FS.
00:23:29wodzpixelma: cool
00:23:32 Join robin0800 [0] (
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:51archivatorDoes 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:20funmanarchivator: pcm_more_callback_type2 ?
00:27:05archivatorfunman: 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:20wodztime to sleep()
00:27:36 Quit wodz (Quit: Leaving)
00:27:51 Quit lpereira (Quit: Leaving.)
00:28:06funmani just know that if it's < 0 recording is finished
00:28:59archivatorIf 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.
00:29:37funman-1 : /* Flush recorded data to disk and stop recording */
00:29:54funmanapps/pcm_record.c : pcm_rec_have_more()
00:30:07funmanso in fact it's a boolean
00:30:21funman-1 : stop, >= 0 : continue
00:30:45 Quit pixelma_ (Quit: -=+)
00:30:47 Quit phanboy4 (Quit: Leaving)
00:30:47funman< 0 && != -1 : room for further error codes which will probably never be added
00:31:09archivatorfunman: 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] (
00:31:33funmanarchivator: i guess wodz didn't answer to you but just meant he was tired ;)
00:31:46archivatorfunman: or, he did a double entendre.
00:31:51 Join robin0800 [0] (
00:31:56funmanarchivator: read pcm_rec_have_more(), there's only 2 return values
00:32:30archivatorfunman: I've read that whole file. It still doesn't make it clear.
00:32:33funmanbtw, pcm_record_more() is present in the plugin API but never used?
00:32:46 Join BlakeJohnson86 [0] (
00:32:54archivatorfunman: correct. The pitch_detector author has a note about not knowing how to use it :)
00:33:02funmanoh ok
00:34:04funmanarchivator: 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@
00:34:50 Quit mikroflops (Ping timeout: 246 seconds)
00:34:55 Part Strife89
00:35:24funmanso 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:54funmanif you want to extend the return value you'd need to modify each recording driver
00:35:56 Join robin0800 [0] (
00:36:14archivatorfunman: 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:31archivatorAs 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:44funmanarchivator: if recording is stopped before you should be able to
00:37:56 Join robin0800 [0] (
00:38:02 Join Strife1989 [0] (~michael@
00:38:10funmanpcm_record_more resets the recording context
00:38:12archivatorfunman: define "stopped". return -1 stopped or pcm_stop_recording stopped?
00:38:16 Part Strife1989
00:39:23archivatorsorry 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:29archivatorbother you*
00:39:53funmanwell i'm not very familiar with recording, i just implemented a target driver with appreciable amounts of copy/pasting from other drivers
00:40:36archivatorI 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:23funmanpcm_record_more(start, size) sets the recording context of the driver: it will record size bytes and store them at buffer start
00:41:59funmanit 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:30funmanprovided you don't mind to discard the recording which was in progress you should be free to call pcm_record_more() yourself
00:42:52archivatorso 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:47jhMikeSarchivator: 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:24funmanarchivator: instead of returning -1 and later call pcm_record_more(), why not call it immediately and return 0 ?
00:45:00archivatorfunman: because there's work to be done on the data in the buffer and that would mean I'll need double buffering.
00:45:01funmanjhMikeS: btw did you spot my removal of pcm_mute() yesterday?
00:45:22archivatorjhMikeS: that's the point, I want to resume the recording from outside the callback.
00:45:24jhMikeSfunman: no. hadn't been around. I was considering the same action
00:45:44funmanarchivator: hm ok, but then you'd lose some data i think
00:46:02jhMikeSarchivator: then just stop it and start again. there is no pause as it wouldn't make much sense.
00:46:09archivatorfunman: I don't mind. I lose tons of data in playback mode as well.
00:46:50archivatorjhMikeS: that's what I was doing. I assume there isn't much overhead from constantly calling pcm_stop_recording?
00:47:00jhMikeSarchivator: otherwise, you can just keep it going and ignore what the data it returns until you want to do something with it
00:47:21archivatorfunman: to be precise, I don't "lose" it, it just never shows up in the buffers I'm accessing.
00:47:58jhMikeSarchivator: wait till the callback is called, then the data is ready
00:48:40jhMikeSbasically it's start (w/params) -> hardware fills buffer -> interrupt (say to do more or just return < 0 to end it)
00:48:48archivatorjhMikeS: 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:07jhMikeSarchivator: there's really no need for that and will likely result in data breaks.
00:51:08archivatorjhMikeS: then just return -1 until I'm ready to get new data? Hm, that would make things a tad more complex ..
00:52:26jhMikeSwhy the need to stop it? the core recording just keeps it going but just doesn't advance the queue if "paused".
00:53:13archivatorjhMikeS: no need per se, that's the way pitch_detector is doing it and I just copied it.
00:53:56jhMikeSarchivator: I recall that. it rather nasty and plain incorrect
00:54:28 Quit funman (Quit: free(random());)
00:54:34jhMikeSsee apps/recorder/pcm_record.c line 247 for the core's callback function.
00:55:30archivatorjhMikeS: I've had that open for a day now, doesn't help me much since it's not how my workflow goes.
00:56:10b0hoonAlexP: ping
00:56:31 Join kugel [0] (~kugel@rockbox/developer/kugel)
00:56:34jhMikeSarchivator: perhaps, but that's how the interface works. I suppose workflow has to work with that. :)
00:56:58 Quit stripwax (Quit:
00:57:09b0hoonAlexP: hi, would you like to look at the manual for the vibe 500, please?
00:57:25archivatorjhMikeS: 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:38AlexPb0hoon: Sure, anything in particular?
00:57:41b0hoonAlexP: only section 3.1.1 and 3.1.3
00:58:06b0hoonAlexP: is everything ok with the lanquage...
00:58:25archivatorjhMikeS: There's a very easy fix to my problem, really, but it's a memory tradeoff I'm not prepared to make.
00:58:36AlexPb0hoon: Just looking now
00:58:40jhMikeSarchivator: if you return -1 any new buffer will be ignore and recording will stop
00:59:02archivatorjhMikeS: then how is that different from calling pcm_stop_recording?
00:59:14jhMikeSarchivator: no need to call record_more if you plan on returning < 0
00:59:35CIA-5New 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:56jhMikeSarchivator: not technically different. but if you need a continuous, unglitched flow of data, stoping and restarting is not the way to do.
01:00:17archivatorjhMikeS: I don't need a continuous flow of data since I have nowhere to put it :)
01:01:10kugelpixelma: ping
01:01:29archivatorjhMikeS: 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:02CIA-5New 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:31pixelmakugel: pong
01:02:44jhMikeSarchivator: hrm. Prepared to pastebin anything? I don't fully understand what's so unique here.
01:02:53kugelpixelma: did you try the pla patch on your other targets?
01:03:17 Quit robin0800 (Remote host closed the connection)
01:03:41archivatorjhMikeS: this is the latest patch:
01:03:54AlexPb0hoon: A couple of small changes to 3.1.1:
01:04:12pixelmakugel: sorry, forgot
01:04:14archivatorwhat'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:16AlexPb0hoon: Question, does the scroll pad only scroll, or would just up and down be more accurate descriptions?
01:04:26AlexPb0hoon: Looking at the second bit now
01:04:41 Join robin0800 [0] (
01:05:24pixelmakugel: the patch is broken currently (at least I got a conflict when updating), probably because of the mpio port additions
01:05:52b0hoonAlexP: the scroll pad only scroll and sets the parameters like volume etc.
01:06:12kugelpixelma: tbh, I'd really like to get it in before I'm too busy for gsoc and especially before 3.6
01:06:25AlexPb0hoon: 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:16AlexPb0hoon: That isn't just scrolling then - perhaps "Sliding a finger up or down the scroll pad acts as Up and Down respectively."
01:07:36AlexPb0hoon: Also, note in that sentence in my pastebin I missed out "acts" and s/or/and/
01:08:04b0hoonAlexP: ok, thank you, i'm reading pastebin now...
01:08:05jhMikeSarchivator: 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:43pixelmakugel: 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] (
01:09:41AlexP3.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:16archivatorjhMikeS: 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:17kugelpixelma: 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:11:16jhMikeSarchivator: stack? wth would *stack* be used for such a thing?
01:11:32pixelmamanual I can still follow, but what do you mean with "separate pla and opts"?
01:11:42pixelmakugel: ^
01:12:04kugeljhMikeS: is there anything that'd prevent our own thread engine disallow to run onder an actual OS?
01:12:13archivatorjhMikeS: ah, but it is :). the input, output and plot arrays are all on the stack.
01:12:15kugelI only thought of *_irq so far
01:12:58jhMikeSarchivator: and this is necessary? esp. in a plugin?
01:13:17archivatorjhMikeS: 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:21linuxstbAlexP: 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:33b0hoonAlexP: 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:33kugelpixelma: 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:36jhMikeSkugel: the IRQ is just a faked out thing using mutex and those other things (which the names escape me atm).
01:14:05AlexPlinuxstb: That is good too (b0hoon use that version) :)
01:14:23jhMikeSarchivator: 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:28archivatorjhMikeS: 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:31AlexPb0hoon: OK, if the ipods say scroll then I guess use that (we can have a discussion about that later) :)
01:14:34b0hoonlinuxstb: yeah, it is good too
01:15:04pixelmakugel: so you mean the pluginlib actions as actions in the keymap files (as cora actions too)?
01:15:19kugelI 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:22jhMikeSarchivator: it sure puts some drivers throught alot of other setup that could sap cycles away
01:15:24kugeljhMikeS: ^
01:15:38archivatorjhMikeS: 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:58kugelpixelma: 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:12jhMikeSarchivator: I meant the plugin, since it looks like a patch for the fft demo
01:16:20b0hoonlinuxstb, AlexP: thanks a lot :)
01:16:33AlexPno worries :)
01:16:40archivatorjhMikeS: ah, yes, it is indeed a patch for the demo (which I'm trying to enhance with recording support)
01:16:50pixelmakugel: 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:19jhMikeSkugel: 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:38kugelin fact, only generation works awesome, but only if context arent' ch
01:17:46kugelchained to other ones
01:18:28*archivator looks back and sees that he meant "unnecessary" three comments ago.
01:18:42archivatoror not, I can't read anymore.
01:18:43kugeljhMikeS: you may missed that I got accepted fo rockbox as an application for gsoc, but other than that no
01:19:17kugelI'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:36jhMikeSkugel: \o/ congrats (you said accepted (can't seem to read well atm)? \o/
01:20:00kugeljhMikeS: high five! :)
01:20:07jhMikeSkugel: so in effect we write our own SDL? LOL
01:21:11kugelI 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:13pixelmakugel: 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:10kugeljhMikeS: 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:38kugelso 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:23kugelpixelma: some also have #ifdef BUTTON_OFF ... #elif BUTTON_POWER .... #endif (I hope you get what I mean)
01:24:48kugeljhMikeS: 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:59jhMikeSkugel: 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:53RadicalRHmmm, I guess I broke the fuzev2.
01:28:06RadicalRIt's trying to load the firmware and gives me "file not found"
01:29:14jhMikeSkugel: 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__ (
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:39kugeljhMikeS: I'll try to set up an test app which links "", be prepared to answer questions :)
01:33:02kugelfortunately I have a real arm target which also runs linux
01:33:05 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon)
01:33:18kugelhowever, unfortunately it can't run the simulator :(
01:34:26 Join CaptainKewl [0] (
01:34:35kugel(it seems to get killed by the OOM killer)
01:35:06 Join CaptainKwel [0] (
01:35:14jhMikeSit sounds out of the scope of what I know about threads as an app (which is limited to sim)
01:36:20kugeljhMikeS: 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:32jhMikeSjust declare it as struct thread_entry; without a name outside of thread.c?
01:37:44kugelanyway, if not it shouldn't matter too much. I doubt my project is going to fail due to threads
01:38:26kugeljhMikeS: kernel.c referneces actualy members, like bqb not just the thread_entry struct
01:39:14 Part toffe82
01:39:45jhMikeSah 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:53kugeljhMikeS: that was my question to you :P
01:41:12 Join CaptainKewl [0] (
01:41:26 Join komputes [0] (~komputes@ubuntu/member/komputes)
01:41:43kugelI thought maybe kernel.c relies on knowing too much and that could be fixed with something more sophisticated that adding API calls
01:42:00jhMikeSkugel: 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:12kugelbecause API calls only mean I replace dummy members with stubs
01:45:21 Quit CaptainKwel (Ping timeout: 276 seconds)
01:49:04jhMikeSkugel: 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:05kugelheh, that sounds like'd end up in some fakish OOP :p
01:51:29kugellike it'd*
01:52:27CIA-5New commit by funman (r25746): fix r25741: the 2nd delay needs to be present when the CPU is boosted
01:53:13kugelfunman: .... :)
01:53:51jhMikeSkugel: 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:04kugelfunman: something is wrong if udelay(1) is not enough to cover a 500-busy-wait
01:54:37kugela udelay(1) should be equivaltent to an (75-100)-busy-wait
01:55:36jhMikeSudelay(1) might not delay at all though, since the timer could advance at any time. basically, it means "wait until next count".
01:56:05kugelthe commit messages says udelay(1) was too long though
01:56:31jhMikeSthen you're screwed :) better use delay loops!
01:56:52kugelwell, it worked on my unit
01:57:17kugelI actually counted cycles :/
01:57:43 Quit liar (Quit: Verlassend)
01:57:57kugelthe problem is that simple delay loops are really bad if the boosted and non-boosted freq differ too much
01:58:44jhMikeSon cf, some bitbang drivers adjust that in set_cpu_frequency.
01:59:37jhMikeSoh, the ds2411 one just checks it upon entry, but that's not really performance-critical
01:59:44kugelwe could do that, but a) that part is not stable on as3525v2 yet, and b) the timer should be fairly detiministic
02:00:52jhMikeSfaster timer? udelay(1) is right at the quantum level if it counts usecs.
02:01:05kugelfunman: did you consider udelay(2) already?
02:01:34kugeljhMikeS: right, that's why I don't understand udelay(1) is too short
02:01:35 Quit DerPapst (Quit: Leaving.)
02:02:39kugelI 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:46jhMikeSudelay(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:16kugel13 cycles*
02:03:37 Join funman [0] (~fun@rockbox/developer/funman)
02:04:30kugelthe 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:05:36kugelargh, 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:51funmankugel: 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:58funmanof course :p
02:07:36kugelfunman: actually, because it worked. I tested basically all buttons under boosted. that was before your fix of course
02:08:46kugelyes, 500 should be more than a single usec, but it worked for some reason
02:09:11kugelwhich is why it makes me crazy you say udelay(1) is too long
02:09:20funmanyou'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] (
02:10:23funmanthe 1st loop is 104µs at 40MHz and the 2nd loop is 50µs
02:10:51***Saving seen data "./dancer.seen"
02:11:05kugelfunman: 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] (
02:11:09funmanso 1.5% of the CPU time is spent there
02:12:07kugeljhMikeS: it affects several targets, which is exciting :)
02:12:39kugelfunman: I can imagine it was too *short*, but not really that it was too long
02:12:55jhMikeSand the timer counts at the right frequency?
02:13:06funmanyes timer is ok
02:13:18kugelyes, 1.5% of the cpu time is really major, so I thought some freq independant udelay was a good thing to do
02:13:48funmankugel: 1st delay: udelay(10); and 2nd : udelay(5) is ok for me (both when boosted & unboosted)
02:13:53kugelwhich you basically reverted now :)
02:13:54 Quit Rob2222 (Ping timeout: 248 seconds)
02:14:00jhMikeSfunman: that sounds a might peculiar. does the timer wrap really quickly?
02:14:25funmankugel: if the delay was volatile then it's ~twice more: 3% (@#!) perhaps we'll have a bit better performance now
02:14:38funmanjhMikeS: well it wraps HZ times per second
02:15:20kugelcould it be that it is at 0 only for a *really* short time, and that it reloads TIMERx_LOAD immediately?
02:15:20funmankugel: should be the last in the series
02:15:49kugelso that we should rather assume it goes from TIMERx_PERIOD to 1, instead of from TIMERx_PERIOD to 0?
02:15:58funmanhm i don't know, let's see what the datasheet says
02:16:21funmanAn 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:24funmanthe value until the interrupt is cleared. The most significant carry bit of the counter detects the counter reaching zero.
02:16:42kugelfunman: the delay variable in current svn isn't volatile anymore, is it?
02:16:43jhMikeSfunman: sounds like the could mess things up.
02:16:58funmankugel: nope it isn't
02:17:21funmanit doesn't say if the counter stays at 0 or if it's immediately reloaded
02:18:41funmanjhMikeS: 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:51kugelso it stays at 0 until the interrupt is acked?
02:19:18funmanno because we ack the interrupt only after all the tick tasks have returned
02:19:23kugelthat'd mean udelay would end up in an infinite loop though, because the int is acked after call_tick_tasks()
02:19:32funmanif it stayed at 0 udelay() would just lock up
02:19:57kugelyou're too slow :P
02:20:46funmanok for that last patch ?
02:20:59 Quit CaptainKewl (Quit: ( :: NoNameScript 4.22 :: ))
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:51funmanalso did you see the forum comment where fuzev2 scrollwheel acceleration looks infinite ?
02:23:28CIA-5New commit by funman (r25747): Fuzev2: revert r25741 and r25746 ...
02:23:34kugelfunman: no
02:24:05funman1st post of page 108
02:24:21kugelfunman: I did calculate those udelays with 25 and 13 at the very beginning, but 1 and 1 seemed to work anyhow
02:24:59funmanperhaps they where most longer only some times, but with 100 runs per second one would work and the backligth would go off
02:25:17funman(before my fix)
02:25:24kugelin the fuzev1 you can scroll 500 items with 2 rotations...
02:25:41funmanwell it's ok then
02:26:25kugelI found that a bug in my patch caused the unpredictable accel which I fixed. now it feels basically like on the e200v1
02:26:27funmantoo fast for me but it's consistent so no prob?
02:26:40kugelit used to worse, didn't it?
02:26:56kugelfuzev1 is definetely accelerating faster in my experience
02:27:12funmani can't tell since my fuzev1's wheel is a bit stuck so not freely moving :p
02:27:29funman(someone put it apart and probably didn't remount it properly)
02:27:45kugelrevert 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:38funmanso 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:13funmanah no FM is still missing on the fuze
02:29:30funman(and usb)
02:30:31saratogafunman: i saw your post about boosting
02:30:33kugelyea, and the strange backlight off after exiting plugins
02:30:41saratogai thought you set it to 20 or 30 MHz unboosted?
02:30:55kugelI think the sw backlight fading isn't entirely correct yet but I have no proof
02:31:17funmansaratoga: 24MHz , but in the first days of the port we left it at 120MHz (default boot setting) iirc
02:31:36funmankugel: i think it's related to settings + read-only
02:31:41saratogawell 24MHz would be really nice, the codecs on the clip+ are amazingly fast
02:31:54saratogafor best runtime we'll want ~20MHz, maybe lower since the screen is so small
02:32:28funmansaratoga: 24 is the minimum with pll@384MHz
02:32:48saratogai think I tested flac at around 10MHz realtime decoding :)
02:33:35funmanreversing the PLL bits should be possible with lots of try and measure
02:34:43funmansaratoga: with a custom build disabling cpufreq switching and fixing the clock at 24MHz is easy
02:35:17saratogaprobably not worth trying for a 15MHz clock then
02:35:20funmani still don't know what happens: most of the crashes reported in the forum happen in set_cpu_frequency() function
02:36:21saratogathe D2 uses the same arm core and manages <10MHz flac decoding without using IRAM
02:36:22funmanhmm no the PLLA is at 240MHz
02:36:31funmanso we could go down to 15
02:36:33saratogathough that sort of begs the question why they don't just use IRAM :)
02:36:37saratogaoh cool
02:36:47saratogais there any voltage scaling going on too?
02:37:07saratogaso no harm if we spend more time boosted then
02:37:16funmanthe problem i think is that pclk is derived from fclk so you must modify CGU_PROC and CGU_PERI together
02:37:41funmani suppose weird things happen with memory if pclk is too high/too low
02:38:25funmani'll try again tomorrow to use more steps to make sure pclk stays in a good range
02:38:50funmani had tried to stress boosting/unboosting but it didn't cause crashes faster
02:39:23funmanperhaps putting set_cpu_frequency() in uncached memory would force memory accesses while switching
02:39:46 Join CaptainKewl [0] (
02:40:16funmanFlynDice: i'm ready to sacrifice small animals if it makes you see the light and understand what happens in our sd driver :)
02:43:39funmansaratoga: no news from tremor guys, monty seems more busy trolling than answering to patches :(
02:44:15saratogawell 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:17funmanperhaps you could get some testers in #vorbis ?
02:50:54 Quit funman (Quit: free(random());)
02:51:03soapI'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:17soapIs 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:58soapArchosUnlock.exe is also no longer hosted where the ancient page points.
02:55:50Lloreansoap: 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:54LloreanBut we turn up in searches despite that.
02:56:48LloreanIt seems like that page should just be moved into the wiki, and then deprecated.
03:02:01soapOk. 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:34LloreanI 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:57soapsaratoga, I believe you can edit posts and Febs has not been active for 8 months.
03:45:08saratogai can't edit his post
03:45:38saratogai just have delete
03:45:47soapOk, 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:48saratogai think i can only edit people of equal or lesser forums rank
03:45:49LloreanGlobal Mods are kinda "special" I think, in that their posts can't be edited except by Admins or other global mods.
03:45:57saratogayes his wording is mostly correct
03:46:14soapgrumble grumble mostly grumble grumble.
03:46:16Lloreansoap: "System -> Rockbox Info"
03:46:16saratogaalthough its actuall "system -> Rockbox Info" then under the "version" label
03:46:31saratogaso version is whats written next to it, not the menu label like it says now
03:48:36soap(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:08:44 Join Barahir [0] (
04:10:52***Saving seen data "./dancer.seen"
04:12:06 Quit Barahir_ (Ping timeout: 260 seconds)
04:14:03 Join alexanderpirdy [0] (
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@
04:24:35 Quit Unhelpful (Changing host)
04:24:35 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful)
04:25:03alexanderpirdyHi, 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:20saratogaalexanderpirdy: status link on the front page
04:35:16 Join CGL [0] (~CGL@
04:39:59 Join phanboy4 [0] (
04:40:34 Join mazdac [0] (
04:42:49alexanderpirdysaratoga: 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:13saratogaalexanderpirdy: i think you didn't click the link
04:51:32 Quit anewuser (Quit: 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:52alexanderpirdysaratoga: wow sorry I missed that must have been three times, my apologies
04:56:19saratogano problem
05:08:40alexanderpirdysaratoga: 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:26saratogai don't think anyone has ever bricked their player installing a build
05:10:19Lloreanalexanderpirdy: 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:04alexanderpirdyI was not thinking of installing a build, but one that is currently labled unusable which does have the big red warning...
05:16:33saratogathen don't install it
05:18:48alexanderpirdyI 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:19alexanderpirdyI understand that it is risky and not recommended for just regular use
05:21:17LloreanI don't see a big red warning.
05:21:35LloreanI 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:10saratogaif you're asking questions like these you should wait for a stable release
05:22:15saratogacome back in a few months
05:23:20alexanderpirdyLlorean: under unusable? Is that not the big red warning in the disclaimer section?
05:24:13Lloreanalexanderpirdy: Didn't I specifically reference that warning which is also there for the stable ones?
05:26:12alexanderpirdyLlorean: I couldn't tell if this is the one you were referencing or if there was a more prominent one, sorry.
05:27:12LloreanBasically, any Rockbox install on certain targets contains a small risk of bricking.
05:27:12alexanderpirdysaratoga: 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:30LloreanBut 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:19saratoga_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:26alexanderpirdysaratoga: I understand your point of view and I apologize for hastily asking questions
05:34:23saratoga_that alt-f4 thing in the forums is pretty dumb
05:34:35saratoga_improbably so
05:36:29LloreanI 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:55saratoga_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:34krazykit`ah, the user-ml then ;)
05:39:11saratoga_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:33alexanderpirdysaratoga_: Llorean: thanks again for the help, talk to you later...
05:51:46 Part alexanderpirdy
06:07:53 Join RandomInsano [0] (
06:10:54***Saving seen data "./dancer.seen"
06:24:43 Join JDGAFFLIN [0] (
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] (
07:01:31 Join w1ll14m [0] (
07:08:07 Join einhirn [0] (
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 (
07:39:32pixelmahas 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:03pixelmathat's the builtin bar, not an sbs
07:44:40LloreanI've noticed the status bar flickering when I insert a lot of tracks.
07:44:43LloreanIt flickers as the splash updates
07:46:38 Join RandomInsano [0] (
07:47:20 Part RandomInsano
07:48:58 Nick fxb is now known as fxb__ (
07:49:06pixelmayou 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:05LloreanYes, inserting through the playlist
07:55:20LloreanInstead of turning on and off shuffle for spoken word vs music, I usually just "insert shuffled" my music folder
07:55:31LloreanWhich is ~1700 tracks or so
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] (
08:38:21 Quit jordan` (Quit: Coyote finally caught me)
08:41:52 Join jordan` [0] (
08:42:17 Quit jordan` (Remote host closed the connection)
08:42:50 Join jordan` [0] (
08:45:14 Join flydutch [0] (
08:55:46 Join XSPR [0] (
08:56:36 Join pjm0616 [0] (~user@
08:57:13XSPRthere is a RockBoy plugin for the gameboy handheld
08:57:51XSPRdoes anyone know of a server/channel for gameboy dev? (homebrew development)
08:59:48 Quit _arbingordon (Quit: `)
09:02:30 Part XSPR
09:05:55JdGordonLlorean: pixelma: bar flickering is an anoying known issue
09:07:10 Join petur [0] (~petur@rockbox/developer/petur)
09:10:49pixelmaany ways to fix it?
09:11:31 Join crculver [0] (
09:14:06JdGordonno 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] (
09:17:31 Quit Zagor (Changing host)
09:17:31 Join Zagor [0] (~bjst@rockbox/developer/Zagor)
09:17:58crculverDaily build is broken for a second time this week.
09:18:08crculver(For iPod Video 32GB, that is)
09:18:20crculverWhat kind of big changes are going on?
09:19:00crculverWhoops, 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] (
09:26:51pixelmaJdGordon: 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:11pixelmaI mean the flickering with "it"
09:28:33 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
09:31:19 Join lifeless__ [0] (~lifeless@
09:31:30 Join shai_ [0] (
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 (
09:34:05 Join solexx [0] (
09:34:41crculverHmm, I'm not sure where the problem is. I get checksum errors on rockbox.ipod on boot.
09:35:10JdGordonpixelma: 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:25JdGordonif we dont do that we run the risk of parts being left over after the splash is cleared
09:35:58JdGordonalthough 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] (
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] (
09:37:33 Join Rob2223 [0] (
09:37:33 Join BlakeJohnson86 [0] (
09:37:33 Join Farthen [0] (
09:37:33 Join FlynDice [0] (
09:37:33 Join xavieran [0] (
09:37:33 Join gevaerts [0] (~fg@rockbox/developer/gevaerts)
09:37:33 Join yosafbridge [0] (
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] (
09:40:10wodzamiconn: ping
09:46:45 Join CGL [0] (~CGL@
09:49:32 Quit flydutch (Ping timeout: 258 seconds)
09:51:15 Join efyx [0] (
10:04:54linuxstbcrculver: What are the two checksum values being displayed?
10:06:07crculverlinuxstb, 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:32linuxstbcrculver: OK, I'll ignore you then ;)
10:07:17crculverIncidentally, after I followed the reformatting instructions at, dosfsck no longer works on this drive.
10:08:11 Join flydutch [0] (
10:08:34crculver$ dosfsck /dev/sdc2
10:08:36crculverdosfsck 3.0.9, 31 Jan 2010, FAT32, LFN
10:08:36crculverSeek to 79883917312:Invalid argument
10:09:04crculverSo if I can't run dosfsck, I can't repair whatever problem I have on this drive. I'd hate to reformat.
10:09:10linuxstbDo you have an 80GB ipod?
10:10:38crculverI can mount the iPod just fine, I just can't fsck it.
10:10:47JdGordonpixelma: 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:24JdGordonkugel: you probably want to test 11226 also
10:13:07kugeldidn't we reject that idea before?
10:13:36JdGordonit is the lesser of two craps
10:14:08kugelI think there should be a proper solution for splashes
10:14:28JdGordonok, lesser of 3 bads then
10:19:00 Quit CGL (Quit: Nos leemos !)
10:20:41 Join hebz0rl [0] (
10:21:26linuxstbcrculver: Are you sure you used the correct MBR for your ipod? Are you using Linux?
10:22:31crculverlinuxstb, Yes and yes
10:24:57 Quit wodz (Quit: Leaving)
10:28:27 Quit phanboy4 (Ping timeout: 265 seconds)
10:32:03linuxstbcrculver: What does "fdisk -l /dev/sdX" show (where sdX is your ipod, and -l is the letter "ell"). Please post the output to
10:40:24 Quit avacore^ (Read error: Operation timed out)
10:41:25 Join avacore [0] (
10:41:40linuxstbcrculver: Can you remember what command you used to format the disk?
10:42:16crculverlinuxstb, Whatever the instructions are at
10:42:20crculverThis was about six weeks ago
10:43:16linuxstbAh, so it's been working fine for about six weeks, but has stopped now?
10:43:47crculverlinuxstb, This is the first issue I've had with it.
10:43:57crculverlinuxstb, I haven't tried to run dosfsck on it until now
10:46:01 Join robin0800 [0] (
10:52:59pamauryWhat 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] (
11:06:12 Join dfkt [0] (dfkt@unaffiliated/dfkt)
11:07:38linuxstbpamaury: 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:32pamauryOk, 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] (
11:20:35 Join liar [0] (~liar@
11:21:12JdGordonkugel: (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:05JdGordonwhatever we do it will bs bad for someone (and doing a special clearing for splashes is really the worst option)
11:23:31kugelno, it was rejected because a splash is "off the UI" so it should not be theme dependant
11:24:09kugelit wasn't for aesthetic reasons
11:25:24JdGordonthen even more so it was a bad rejection
11:25:45kugelI agree with that though
11:26:35 Join n1s [0] (~n1s@rockbox/developer/n1s)
11:33:51amiconn*imo* MTP is completely unnecessary, but that's just my personal opinion
11:37:25n1swell, 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:53gevaertsplayback should also be able to continue
11:39:33n1sbut who uses that :P
11:41:37amiconnIn my experience UMS is significantly faster than MTP
11:42:01gevaertsWe'll have to see if that's fundamental :)
11:45:26 Join arbingordon [0] (~w@unaffiliated/arbingordon)
11:47:07n1samiconn: also nice apps can tellyou you are trying to transfer unsupported media and offer to transcode for you, and other useful things :)
11:47:13pamauryUMS 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:59n1spamaury: why isn't the purpose of MTP to be fast?
11:48:47pamauryotherwise it would have been better designed :)
11:49:12*pamaury feels like trolling
11:49:34n1si mean it is a *transfer* protocol ;)
11:49:58n1spamaury: i don't blame you unless you designed it!
11:50:11pamauryno I didn't :)
11:53:23JdGordonpamaury: do you need/want testing with win7?
11:53:30JdGordonI think i saw a call for testing yesterday?
11:53:58pamauryYesterday someone test it under win7 but of course you can test it, I also fixed several bug yesterday :)
11:54:17JdGordonI've never used mtp before though
11:55:22pamauryWith 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:12JdGordonI have a few to play with... any sansa and a few others.. which would you like?
11:56:28pamaurye200 because I already have a build :)
11:56:38linuxstbpamaury: How closely is MTP tied to the database? i.e. do you need to have enabled the database to use MTP?
11:57:19pamauryno, 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:24pamauryJdGordon: so is a e200 build ok ?
11:59:09linuxstbpamaury: OK, that sounds nice.
12:00:36pamauryHowever the current doesn't add files to the databse when there are created, this is one of the numerously missing features :)
12:00:50JdGordonpamaury: v1 or v2?
12:01:05linuxstbpamaury: Isn't that the main reason someone would want to use MTP? ;)
12:02:00pamauryyes 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:42JdGordonnuts, my e200v1 is fubar... no rockbox and bootloader cant load OF
12:04:58pamaury for a e200 build
12:05:02JdGordonpamaury: can you do a fuzev1 build?
12:05:16pamaurybut you'll have to wait a few more minutes
12:05:29JdGordonill build it faster here then :)
12:05:34JdGordonwhats te fs number?/
12:06:29JdGordonbah, git :(
12:06:56JdGordonok do me a build please :)
12:07:02pamauryWhat is the git number ?
12:07:40pamaurythere is my repo here if you want: pamaury/rockbox">
12:08:35kugelJdGordon: fuzev1 doesn't have usb support
12:08:36 Nick fxb__ is now known as fxb (
12:09:01 Quit BHSPitMonkey (Quit: Ex-Chat)
12:09:24JdGordonoh ruddy hell... :p
12:09:32pamauryif it doesn't have usb, mtp might be difficult to test :)
12:10:01pamauryanother target perhaps ?
12:10:15JdGordonipod vid (32mb), or mini2g
12:10:27pamauryok, tell me one which has usb support ;)
12:10:40JdGordonkugel: does e200v2 have usb?
12:10:49JdGordonok, either of the ipods
12:11:04***Saving seen data "./dancer.seen"
12:11:17pamauryok ipod video
12:12:00pamauryfuck, compile error :(
12:15:11pamauryI 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] (
12:15:52 Join krazykit [0] (
12:16:17bignosewhen shopping for a Sansa Fuze, how can I tell which models will work with Rockbox stably and which won't?
12:16:35bignosethe “v1” and “v2” terminology doesn't seem to be part of the model names.
12:17:39TorneYou can't reliably, without turning it on and checking the firmware version
12:18:41 Join bgs1001 [0] (
12:18:41 Quit bgs1001 (Excess Flood)
12:18:49 Join Hadaka_ [0] (
12:18:53bignosehmm. that makes it rather difficult to shop for one on eBay.
12:19:13Torneunfortunately yes
12:19:18Torneyou could try asking hte sellers what the firmware version is
12:19:53bignoseokay, thanks for the answer.
12:20:44 Join bgs1001 [0] (
12:21:29JdGordonpamaury: do I need to enable it or anything on the ipod?
12:22:05 Part bignose
12:22:14pamauryyes, 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] (
12:23:12JdGordonthats a bit yuck :p
12:23:53pamauryTrue 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 (
12:24:09JdGordoncomes up as "rockbox media player"
12:24:14JdGordonwow, disk access is slow
12:24:38pamauryon first plug, the host usually read the entire disk so it's extremely slow, I can't do anyting about that
12:25:04JdGordoni was commenting on the speed the folders show up in explorer
12:25:11JdGordonWM11 seems to handle it fine
12:25:33JdGordontitle is filename?
12:25:59pamauryI think so because there is to "title" metadata in MTP
12:27:09pamauryCould you also check if the reported volume size and free size is correct ? I fixed that yesterday normally
12:27:29JdGordon26.8/55.7 sounds about right
12:27:45JdGordonsame as rockbox reports in the info screen
12:29:09pamauryso it is working properly ?
12:30:21JdGordonwmp might have just crashed...
12:31:23JdGordonignore that
12:31:28JdGordonyeah, 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] (
12:40:46 Quit pamaury (Ping timeout: 264 seconds)
12:44:12 Join mikroflops [0] (
12:48:20 Quit mikroflops_ (Ping timeout: 276 seconds)
12:48:32 Join lpereira [0] (
12:54:55 Quit n1s (Ping timeout: 260 seconds)
12:56:52 Quit kugel (Ping timeout: 246 seconds)
13:07:38 Join JohannesSM64 [0] (
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] (
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@
13:36:02 Join n17ikh [0] (
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:04:07 Quit robin0800 (Remote host closed the connection)
14:10:24 Join panni_ [0] (
14:11:08***Saving seen data "./dancer.seen"
14:11:40 Join adnyxo [0] (
14:12:35rasherIs SoundCodecs the canonical list of supported codecs?
14:21:21 Join Curtman [0] (
14:34:20JdGordonprob not
14:34:44JdGordonpamaury: how close do you reckon MTP is? do you want help for the settings?
14:34:52JdGordonusing a button and the debug menu sort of sucks :p
14:35:46pamauryclearly :) 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:38JdGordonWe have to choose pretty quickly which driver to start right? there is no way we could pop up a menu on connect?
14:37:08pamauryAs 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:20pamauryPopping a menu on each connect is annoying no ?
14:39:21JdGordonnot when there are more than 2 possible modes
14:39:29JdGordonand with a timeout it could be very usable
14:40:01JdGordonI 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:32pamaurynormally, 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:01pamaurySo it probably has to be a setting
14:44:05JdGordon2 "settings"... 1) "usb mode on connect" (persistant), and 2) "usb mode on next connection" (non persistant)
14:44:17JdGordonmaybe one more for "usb mode on connect+button"
14:44:54 Quit Battousai (Remote host closed the connection)
14:45:12pamaurywhy one for persistant and one non persistant ?
14:48:27JdGordonbecause I might only want battery this time and usually mtp or msc
14:49:11JdGordonanyone 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:17JdGordonso it doesnt look so crap
14:49:52 Quit DerPapst (Ping timeout: 276 seconds)
14:51:49 Quit anewuser (Quit: 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:39pamauryWhy 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] (
14:54:56 Join kugel [0] (~kugel@rockbox/developer/kugel)
14:55:07 Join ved [0] (
14:56:50JdGordonthat only gives you the choice of 2 options
14:57:04 Quit liar (Quit: Verlassend)
14:57:07pamaurywhy ?
14:57:19JdGordonconnect and no button, connect and button
14:57:38 Join Luca_S [0] (
14:57:46pamauryyes, and what is the problem ?
14:58:12JdGordonwe will have 3 possible options
14:58:41JdGordonalthough I guess battery and MTP would work the same (or close enough) anyway?
14:58:45JdGordoni.e you can still listen to music
14:59:15Luca_SIIRC 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:01gevaertsIt's horribly annoying
15:00:09JdGordonit doesnt have to be
15:00:12pamauryYou 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:06pamauryAnd it could probably be neatly implementing using the usb ack thing (a variant of it)
15:04:41JdGordonso 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:24pamaurysounds 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:05JdGordongit clone pamaury/rockbox.git"> right?
15:07:43pamauryI 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] (
15:11:49 Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick)
15:16:33 Join Unhelpful [0] (~quassel@
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] (
15:30:44 Join hebz0rl [0] (
15:39:52 Join JohannesSM64 [0] (
15:40:22 Quit Unhelpful (Remote host closed the connection)
15:43:51 Join CGL [0] (~CGL@
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@
15:48:56 Quit Unhelpful (Changing host)
15:48:56 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful)
15:52:05 Join MethoS- [0] (~clemens@
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:01:49 Quit n17ikh (Remote host closed the connection)
16:04:13 Quit Luca_S (Quit: CGI:IRC)
16:04:23 Join n17ikh [0] (
16:04:57 Join Unhelpful [0] (~quassel@
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] (
16:14:22 Part mazdac
16:17:50 Join JohannesSM64 [0] (
16:25:31 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury)
16:28:48 Join archivator [0] (
16:32:31 Join jgarvey [0] (
16:47:09archivatorI 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@
16:49:24 Quit esperegu (Remote host closed the connection)
16:52:45kugelarchivator: counting leading zeros should give a good estimate
16:53:21kugelbut 64bit numbers make it a bit more complex yes :)
16:54:09 Quit JohannesSM64 (Read error: Operation timed out)
16:56:50archivatorNope, just tried it, doesn't work. The resolution to small for a good plot :(
16:59:01kugelI don't understand
17:00:29kugelcan'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:45archivatorkugel: check your math, what you're suggesting needs a factorization into two 32-bit numbers, not just a split (i.e., sum)
17:02:59kugelit'd still be an estimate only, but it should be more accurate than clz only
17:03:03archivatorwell (higher 32 bits << 32) + lower 32-bits.
17:04:04kugelright, so log2(x) approx 32+log2(x>>32) (which is what I said before)
17:04:30 Join toffe82 [0] (~chatzilla@
17:04:55archivatoryeah, approx. being the key word :) I was opting for an once and for all perfect solution :)
17:05:19archivatorAlthough, the leading zeroes was an approximation as well..
17:07:20kugeland if the higher 32bit are zero it should be pretty accurate
17:08:23archivatorkugel: 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] (
17:08:54archivatorSince we're not looking for prime factors or anything, there has got to be an easy solution.
17:09:00saratogawhy do you need 64 bit numbers at all in an fft?
17:09:07kugelint a = (int)x; int b = (int)(x>>32)?
17:09:19 Join n1s [0] (~n1s@rockbox/developer/n1s)
17:09:33archivatorsaratoga: not in the fft, in the plot. The magnitude is >> 32-bit.
17:09:53saratogai don't understand why?
17:10:05kugelif (b) y = 32+log2(b); else y = log2(a);
17:10:05archivatorsaratoga: accuracy, mainly.
17:10:07saratogaif you're processing 16 bit data, why do you need > 32 bit display resolution
17:10:46archivatorkugel: I got it the first time, thanks :)
17:11:11kugelI 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] (
17:11:53Tornewell, there is, kinda. take a wild guess at the square root :)
17:12:02archivatorsaratoga: 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:25saratogaonly if you're not doing it right . . .
17:12:35archivatorsaratoga: enlighten me, please
17:12:44archivatorI've been toying with this for a long time
17:13:17archivatorkugel: 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:19saratogaor use a fixed point multiply if you need more precision
17:13:39 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky)
17:13:43saratogathat'll do 32x32=64<<32
17:14:39 Quit Unhelpful (Remote host closed the connection)
17:14:41saratogadoing 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:19archivatorsaratoga: I *am* using fixed-point multiply. And obviously the results of that sum don't fit in 32 bits.
17:15:46kugelarchivator: ah ok, I got it
17:15:49saratogathen shift them until they do
17:15:52archivatorI guess I *could* reduce the accuracy a bit, though..
17:17:45 Quit antil33t ()
17:19:13saratogabasically when doing fixed point math, you shouldn't use bigger variable types to prevent overflow, but only to increase precision
17:19:40saratogaoverflow 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:07saratogabut in practice computing a magnitude will only incur < 1 bit rounding error, so its not an issue here
17:22:24archivatorsaratoga: 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:42archivatorwell, actually, the magnitude is always positive but the question stands.
17:25:02archivatorHm, let's see if that solves anything.
17:30:02 Join Unhelpful [0] (~quassel@
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:00saratogathe 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:31archivatorsaratoga: 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] (
17:38:55 Quit funman (Changing host)
17:38:55 Join funman [0] (~fun@rockbox/developer/funman)
17:39:12saratogatry it with a pure sin wave
17:39:25 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37)
17:39:50funmandfkt: ping
17:42:08 Join lnwlf [0] (
17:42:16 Join esperegu [0] (~quassel@
17:43:31archivatorsaratoga: well, larger than 14, smaller than 32 - maximum value I'm getting fits in 29 bits
17:44:01saratogaassuming your sin wave was full scale, then you can probably rescale the input to get more accuracy
17:44:27saratogainput to your magnitude calculation I mean
17:45:12*kugel wonders if accuracy is really an issue
17:46:01saratogano probably not
17:46:14kugelin the end the accuracy is thrown away by the fact that you can only work with full pixels
17:46:45lnwlfwinxp 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:48saratogaits 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:34saratogawork on the codecs, you pick this up really fast when you can try things and listen to the result
17:48:55FlynDicelnwlf: make sure you're in msc mode, not auto or mtp
17:49:38archivatorsaratoga: one day, when I'm brave enough :)
17:50:42AlexPlnwlf: The manual tells you to do this (and why)
17:50:53AlexPlnwlf: er, I mean and how
17:51:07archivatorAaaaand, I just proved the sim is still broken. Gah.
17:52:45lnwlfflyndice: that did it. i read the install section of the manual and this wasn't mentioned; i clearly should've read further.
17:53:08AlexPlnwlf: It is mentioned it things to do before installing, no?
17:53:29funmani think the confusion between MTP and MSC is the top problem of users, according to the sandisk sansa forums
17:54:07AlexPIt is the very first thing in the install chapter "Before Starting"
17:54:11lnwlfalex: no, it isn't. 'before starting' just says you need to know the letter mount
17:54:18funmani hope the confusion is not ported to rockbox along with MTP
17:54:35AlexPlnwlf: OK, it should do - other manuals do
17:54:39AlexPI'll fix it
17:54:58AlexPlnwlf: Could you tell me how you get there in the Sansa firmware?
17:54:59lnwlfit's obvious now that i think about it
17:55:00funmanmpegplayer is broken on sansa AMSv2 (works fine on fuzev1)
17:55:35funmanAlexP: settings->system->USB mode (translated from french)
17:55:43lnwlfalexp: main menu->settings->system settings->usb mode->msc
17:55:51AlexPThanks 2 :)
17:55:57saratogayeah i guess a lot of people might not realize a drive letter means MSC
17:56:01archivatorCould someone please re-open FS #10816, the bug is still there
17:56:51 Join Ste___ [0] (
17:57:09lnwlfsaratoga: 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:36Ste___pamaury: i read the logs about MTP, you need testers ? i have a H3xx and windows Vista ?
17:59:14archivatorsaratoga: thanks, I'll post some screenshots for proof.
17:59:18Ste___dunno how to use git tho
17:59:38saratogayou can't use mtp on that player
17:59:51kugelarchivator: do you know if it's codec dependant?
17:59:55 Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude)
18:00:00Ste___saratoga, why not ?
18:00:08saratogano software usb
18:00:16Ste___isn't there ?
18:00:19FlynDicere: 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:19kugelarchivator: I can try it with my alsa-lib sim work, maybe it's an SDL problem
18:00:21Ste___i've used it before
18:00:43*FlynDice gazes in ranma's general direction and searches for signs of life...
18:01:08archivatorkugel: 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:09FlynDice^^ was aimed at funman...
18:01:18Ste___no usb
18:01:29funmanFlynDice: :/
18:01:31saratogagreat, get back to me when you've tried MTP . . .
18:01:37Ste___but with pamaurys latest work i was hoping ytop use mtp
18:02:58CIA-5New commit by alex (r25748): Add that you need to be in MSC mode to the fuze manual.
18:03:11AlexPlnwlf: There you go :)
18:03:18lnwlfalexp: cheers
18:03:24AlexPThanks for reporting
18:04:10funmanAlexP: it's not only the fuze, but all sansa ams
18:04:12 Join komputes [0] (~komputes@ubuntu/member/komputes)
18:04:18AlexPfunman: Others already have it
18:04:28funmanoh, can't it be a {sansaams} option ?
18:04:38AlexPBut the location of the menu item is apparently different
18:04:50FlynDiceit shouldn't be
18:04:51AlexPOr rather the menu item in the manual currently is different
18:04:56AlexPThis might be wrong :)
18:05:13lnwlfdoes 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:48FlynDicelnwlf: no, it needs to be recognized by mkamsboot though
18:06:21kugellnwlf: we inject our code into it, so that the OF updater will install our bootloader for us
18:06:25gevaertsSte___: the h200 has a hardware USB-ATA bridge
18:06:28AlexPFlynDice, funman: The manual currently has e200v2,clipv1,clipv2,clipplus using Settings -> USB mode not Settings -> System settings -> USB mode. Is this wrong?
18:06:43 Join fyrestorm [0] (
18:07:02funmanAlexP: right, the correct path is the one mentioned today, for all models
18:07:12AlexPOK, I'll change it.
18:07:27 Quit Topy44 (Ping timeout: 276 seconds)
18:07:29Ste___gevaerts which means ?
18:08:21gevaertswhich means it handles MSC in hardware, and we can't change usb behaviour
18:08:23linuxstbSte___: It means no MTP on the h300.
18:08:47FlynDiceAlexP: Settings -> System settings -> USB mode-> MSC is what I just observed on clip+
18:09:04pixelmareminds me
18:09:06 Join Topy44 [0] (
18:09:52 Quit lifeless__ (Ping timeout: 264 seconds)
18:10:04 Join lifeless_ [0] (~lifeless@
18:10:08AlexPFlynDice, funman: I'll make all sansaAMS Settings -> System settings -> USB mode and leave old Sansa as Settings -> USB mode
18:10:55funmanis the e200v2 menu different from e200v1 ? i don't think so
18:11:02AlexPAnyone have an old Sansa to hand to check?
18:11:10AlexPThe 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:26funmani guess the entry assumed the user was already in the settings menu
18:12:09AlexPThen it got the name of System settings wrong
18:12:46FlynDicehmmm e200v2 is Settings-> USB Mode-> MSC
18:13:15AlexPSo the old ones are OK along with the e200v2
18:13:26AlexPand the clips + fuze are different?
18:13:32*kugel checks e200v1
18:13:48kugelsame as e200v2
18:13:59funmanclipv2/clipv1 are the same as e200v2
18:14:30AlexPSo just clip+, fuze that are different
18:17:00CIA-5New commit by alex (r25749): Correct path to set MSC mode in the OF for the Clip+
18:17:41funmankugel: r25491 broke mpegplayer on fuzev2 :/
18:18:44ranmaFlynDice: 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@
18:19:33 Nick lnwlf is now known as lnwlf-away (
18:21:43funmankugel: ah you forgot PLUGIN_USE_IRAM
18:23:08 Quit lifeless_ (Ping timeout: 258 seconds)
18:24:01funmanit's weird that it doesn't use the same condition than *_ATTR ..
18:24:34funmanah no.. it must be set in the build, not only in plugins i htink
18:25:16dfktfunman: pong
18:25:50CIA-5New commit by funman (r25750): as3525v2: do not use IRAM for plugins
18:26:02funmandfkt: the last messages on the ABI clip+ thread are interesting
18:26:27dfktthe new bootloader working with new builds, but giving blank screen with old ones?
18:26:47funmanyes, because the code for CPU frequency isn't the same
18:26:49FlynDiceranma: 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:14funmanso both old & new builds assume that the bootloader has left the settings in some state
18:27:26funmancan you tell me an old revision which doesn't work with the new bootloader ?
18:27:54dfkti've been running r25407 more or less 'stable' so far
18:28:25 Join TopyMobile [0] (
18:29:23kugelfunman: it looks like I broke some microsds (see forum thread)
18:29:36 Join merbanan [0] (
18:29:44dfktfunman: meaning, that one doesn't work on the new bootloader, but works fine on the old one
18:30:04kugelprobably a miscalculation in the mci_delay to udelay conversion
18:30:08funmandfkt: oki, i'll see if i can make a sense of it
18:30:33dfktgood luck :)
18:31:51funmandfkt: btw you know we have a 'stable' 1.0 bootloader for clip+ ?
18:32:09 Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
18:32:17dfktnope, didn't know
18:32:32dfkthow to get it? :)
18:32:35 Join lpereira [0] (
18:32:38funmanold bootloader + current revision works fine for me :o
18:32:39 Part avar
18:33:01funmandfkt: => clip+
18:33:34dfktoh nice!
18:33:47*dfkt installs r25747
18:34:15funmanhm that's intended, the only not working combination is new bootloader + old revision
18:34:48dfktnewer revisions crashed within seconds of playback for me (on the new bootloader)
18:35:27dfktlast one i tried was r25737 - crashed after a few seconds of mp3 playback
18:35:32funmanpossibly, boost the CPU (debug menu -> cpu frequency) and it should be better
18:35:42dfktthanks, will try that
18:36:15funmanr25407 is a few revisions before dynamic cpufreq
18:37:06Ste___I've bene using r25388 for weeks now with no problems
18:37:48Ste___other than the write one of course
18:38:22 Join liar [0] (
18:38:52 Join Luca_S [0] (
18:40:32Luca_Sso, 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:13Luca_S(I can distinctly hear the sound of nails on glass, but hope is cheap :) )
18:41:23Schmogeldidnt two clip+ brick?
18:41:50 Quit LambdaCalculus37 (Quit: Fwump)
18:42:38funmanLuca_S: i don't see the link between the two
18:45:45dfktfunman: running great for ~3 minutes with bootloader v1.0, current revision, and boost at 1 :)
18:46:35funmanbootloader 1.0 is more or less the same than the first one you posted
18:46:42funmanexcept it says '1.0' :)
18:48:18Ste___is that the 1.0-rc ?
18:49:01funmanSte___: no
18:49:19Ste___is there any difference apart from the text string ?
18:49:34ranmaFlynDice: 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:57funmanSte___: does it matter?
18:50:32Ste___not really.
18:50:34 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539])
18:50:42funmanranma: afaik it's the ONFI 48 pin layout
18:51:40 Quit jnss (Remote host closed the connection)
18:52:15ranmaLuca_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:22ranmaIf I talk to the NAND directly and dump it's contents, maybe I can see if it is corrupted or not.
18:54:23ranmaOr first use a logic analyzer to see if the communication between SoC and the NAND works correctly.
18:55:34Luca_Sa logic analyzer is something like this?
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:00Luca_Ssorry, disregard my previous sentence.
18:57:05 Join Lear [0] (chatzilla@rockbox/developer/lear)
18:57:17ranmaLuca_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] (
19:00:17 Quit merbanan (Read error: Operation timed out)
19:00:58 Join w1ll14m [0] (
19:03:24 Join DataGhost [0] (
19:03:24 Quit DataGhost (Changing host)
19:03:24 Join DataGhost [0] (~dataghost@unaffiliated/dataghost)
19:09:40funmanso.. r25416 is the first revision which works with the new bootloader. unfortunately for users it's also using adjustable cpu freq
19:10:12funmanthe 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:37funmannote that there is no delay at all after modifying CGU_PROC so I assume fclk change is instant
19:16:26funmanis casting an int to a function pointer not possible ?
19:18:17kugelit should work but it's of course highly discouraged, int and pointers don't have the same size on some platforms
19:19:36funmanof course i was using intptr_t
19:19:39 Join phanboy4 [0] (
19:20:10funmanUNCACHED_ADDR(function) gives error: cast specifies function type
19:20:46 Quit DerPapst (Quit: Leaving.)
19:21:03archivatorsaratoga: can I please get your opinion on this: ? Is that what you were describing?
19:21:12funmananyway putting set_cpu_frequency in uncached memory doesnt' cause faster crashes
19:21:21gevaertsfunman: UNCACHED_ADDR for a function? Why?
19:21:43funmangevaerts: to force loads from memory when this function is running
19:22:50 Join stripwax [0] (
19:23:19archivatorsaratoga: sorry, that while should be an if, really.
19:23:21 Quit stripwax (Client Quit)
19:23:22 Part watto
19:23:39archivatorand I guess tmp should be unsigned..
19:23:58funmanarchivator: shouldn't you just test if bit 31 is set ?
19:24:55archivatorfunman: which one is faster cycle-wise?
19:25:46 Quit Luca_S (Quit: CGI:IRC (EOF))
19:25:55 Join ender` [0] (
19:26:11kugeldepends on what gcc is doing...
19:26:46funmanAND can be one instruction, but otoh there is a condition for testing positive/negative
19:26:59 Join [1]w1ll14m [0] (
19:26:59funmanhum ... if set_cpu_frequency() is uncached it crashes much less
19:27:28kugelbut still crashes?
19:27:39funmanno i shut it down befoer
19:27:50funman <- can you try this on Clipv2/Clip+/Fuzev2 ?
19:29:01kugelwhy 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 (
19:29:17funmanno idea, i was expecting it would crash faster in fact ;)
19:29:35funmancrashes 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:56kugelare irqs disabled during freq changing?
19:30:02funmanmy supposition was that pclk was not stable
19:30:08kugelah, yes the paste shows it
19:30:11funmanyes, we do that on purpose
19:30:16 Quit phanboy4 (Read error: Connection reset by peer)
19:30:40funmanmy 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:55funmanor at least the part which is executed after pclk is changed
19:32:25funmani have a ~1 hour song playing, if it finishes i'll say there are no crashes if the function is uncached
19:33:23funmancaches are internal to the CPU and do not rely on peripheral bus, right?
19:39:00 Join Kitr88 [0] (
19:39:06funmandisabling only the icache still crashes
19:39:34 Join TillW [0] (
19:42:08 Quit Kitar|st (Ping timeout: 246 seconds)
19:42:45funmandisabling only the dcache still crashes
19:43:08 Quit Kitr88 (Ping timeout: 240 seconds)
19:44:20funmandisabling both still crashes :o
19:46:02 Join Transformer [0] (
19:47:20saratogaarchivator: 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:28saratogarather then just doing integer multiplies
19:48:36archivatorsaratoga: I was mistaken, those are not fixed-point numbers.
19:49:02 Join Kitar|st [0] (
19:49:05archivatorIt 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:42saratogawhy not?
19:50:52archivatorsaratoga: 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:59saratogathats how you should compute the magnitude
19:52:22saratogawell on arm, grab the c and coldfire verisons as well from wma
19:52:39saratogai don't really get what you're saying about fractional parts
19:52:52archivatorsaratoga: I have no idea what that does but if you say so, that's how I'll do it.
19:52:55saratogathe output of the fft is just binary, you can ascribe whatever number system you like to it
19:53:10saratogainteger, fractional, etc are all the same thing
19:53:30archivatorsaratoga: well, yes. I was thinking about it from a mathematical point of view. Anyway, thanks a lot for your help.
19:53:48archivatorI'm afraid I have to go now but I'll soon post a patch on FS with your suggestions.
19:54:22saratogait does (int32_t) x * (int32_t) y = (int64_t)(z<<32) where z is initially 64 bit
19:54:40saratogatheres actually no way to say that explicitly in c, but thats roughly the idea
19:55:13saratoga(int32_t) x * (int32_t) y = (int32_t)(z<<32)
19:55:17saratogasorry thats what it should read
19:55:30saratogaall the types are 32 bit but the shift is done in 64 bit precision
20:00:22 Join n1s [0] (~n1s@rockbox/developer/n1s)
20:01:37 Join JohannesSM64 [0] (
20:01:41funmanok i got a crash with my first patch.. but it took much longer
20:02:01funmanif others can confirm it crashes much less often then perhaps we can learn something
20:02:52funmancan you try on as3525v2 and NOT force cpu boosting ?
20:05:14ThomasAHfunman: current svn + 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@
20:10:37kugelfunman: might the micro delays be to short or too ling?
20:10:59funmanThomasAH: yep
20:11:14***Saving seen data "./dancer.seen"
20:11:20funmankugel: 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:07funmanthe delay after setting CGU_PROC could be removed though (according to what i said earlier
20:12:30kugelwhy 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:30funmankugel: because if we're doing unboosted->boosted; the pclk divider will be higher
20:14:08kugelI'm looking at the ->unboosted case
20:14:51kugelit might also worth returning for boosted->boosted and unboosted->unboosted calls
20:14:52funmanthere we will use a lower pclk divider
20:15:05funmani think it's handled by cpu_boost() already
20:15:06 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean)
20:15:20kugelno idea
20:15:33funmanif we change cgu_peri first, we'll apply a low divider to a high fclk => high pclk
20:16:02kugelah, so the comment is a bit confusing
20:16:15funmanwhat should it be ?
20:16:51kugeldid you check the disassembly whether the registers are changed atomically?
20:17:30kugelhm, I guess that's the only way on ARM anyway
20:19:00 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier.
20:24:11 Join Boldfilter [0] (
20:25:13 Quit n1s (Quit: Lmnar)
20:26:54 Join Luca_S [0] (
20:27:21Luca_Susually 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:06funmanjust tried 2 times and it worked
20:29:28funmannote, 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] (
20:31:05 Quit JohannesSM64 (Max SendQ exceeded)
20:31:58 Join Strife89 [0] (~michael@
20:32:23 Join JohannesSM64 [0] (
20:32:50 Quit JohannesSM64 (Max SendQ exceeded)
20:32:57 Join DerPapst [0] (
20:34:03 Join JohannesSM64 [0] (
20:34:19Luca_Swhoa, today's version no longer loses backlight when exiting plugins - great work :D
20:34:55kugelno problem! :)
20:35:21kugelgood we never figured out the cause, no we didn't even figure out the fix :P
20:36:52funmani've put a clip+ build with the patch on http://http// (and i posted the link on ABI)
20:42:12 Quit TheSeven (Ping timeout: 248 seconds)
20:42:42 Nick fxb is now known as fxb__ (
20:46:04 Quit Luca_S (Quit: CGI:IRC (EOF))
20:50:12funmanstill running .. quite good !
21:05:03archivatorsaratoga: 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:24funmankugel: you checked if the new mci_delay() was correct (not too fast)?
21:06:20archivatorThose 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] (
21:07:26 Part Transformer
21:07:59kugelfunman: I calculated 4*65000*(1/250MHz)
21:09:37funmansounds right
21:09:45kugelit might be off a bit, but my own microsd worked so I thought it would be fine
21:09:47funmanit's longer when unboosted though
21:10:23 Join komputes_ubuntu [0] (~komputes@ubuntu/member/komputes)
21:11:27saratogaarchivator: for what test signal?
21:11:59archivatorsaratoga: for any test signal. Including the 1 kHz sine wave I used before.
21:13:07 Quit komputes (Ping timeout: 240 seconds)
21:13:14archivatorRemember 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:15saratogawell the amplitude should be a lot different for a sin then for other signals
21:13:40archivatorsaratoga: true but that's empirical evidence, I'm not guessing here.
21:13:52saratogaI don't follow you
21:14:48archivatorusing 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:04saratogafor a sin right?
21:15:06archivatorThat's experimental evidence, I'm not sure what causes it.
21:15:14archivatorfor anything, including a sine wave.
21:15:36saratogayou tested it with a sin right? because testing anything but a sin or cos will not give you a useful result here . . .
21:16:05archivatorI did. That's where it peaks at 29 bits.
21:16:26saratogaok 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:58archivatorwell, 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] (
21:17:45 Quit DataGhost (Disconnected by services)
21:17:46 Nick DataGhost_ is now known as DataGhost (
21:18:40 Join lpereira [0] (
21:19:23saratogayour FFT operates on 32 bit data
21:19:28saratogahow are you feeding it 16 bit data?
21:20:29saratogalooking at your makefile, you define "FIXED_POINT=16"
21:21:07 Quit DataGhost (Client Quit)
21:21:34archivatorI might have been doing it wrong (though I swear it works!). Okay, I'll shift the input data and see what happens.
21:22:50ThomasAHnow at the laptop and building the patched svn ...
21:23:11saratogawhat precision are the trig constants in?
21:26:41archivatorsaratoga: calculated at runtime. Never got around to pre-calculating them. 16-bit fractional part.
21:28:27saratogaso 16 bit
21:29:51saratoga(x)->r = ( Q_MUL(SAMP_MAX << 16, cos >> 15, 16) ) >> 16;
21:30:09saratogaSAMP_MAX << 16 is 0xFFFFFFFF
21:30:39saratogacos is a 32 bit value corrisponding to all the values between -1 and 1
21:30:51saratogaso it truncates that to 16 bit
21:31:12saratogathen multiplies it times the 32 bit value to get the original 32 bit value back, except with 65536 times the rounding error
21:31:29saratogathen truncates that a second time down to 16 bit
21:31:43saratogaconclusion: this fft is not a good fft
21:31:48 Quit Zagor (Quit: Clint excited)
21:32:26archivatorI only replaced the sin/cos functions with the rockbox, the transformations were in the original..
21:32:40archivatorrockbox version*
21:33:45archivatorin any case, what do you propose?
21:34:31 Join DataGhost [0] (~dataghost@unaffiliated/dataghost)
21:34:37archivatorHow do I use the codecs library for real-valued input?
21:35:04saratogawell 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:30saratogaif 16 bit precision is good enough, just use that
21:35:57archivatorsaratoga: it's a demo, not a codec. Of course it's good enough! :)
21:36:15saratogathen quit complaining about only getting 16 bit precision results
21:36:27 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven)
21:37:16archivatorI'm not complaining about the 16 bits of precision, I was complaining about the overflow issues. Which seem to be alright now.
21:44:51ThomasAHfunman: 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:22funman'had' refer to patched build or unpatched builds?
21:49:32ThomasAHfunman: 'had' refered to 256xx + cherry-picked patch to allow lower volume
21:50:16ThomasAHfunman: with newer unpatched svn revisions I had so many crashes that I always downgraded immediately
21:52:04ThomasAHfunman: 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:29ThomasAHfunman: and while moving through the menus the voice clips playing
21:52:38funmanplease torture it as much as you can, so we can be sure this workaround the crashes
21:52:52ThomasAHfunman: will do :)
21:52:56funmanthen we can go to the next step: understand why it does so :)
21:53:31funmanperhaps the answer would just be longer delays
21:54:35 Quit JohannesSM64 (Quit: WeeChat 0.3.2-dev)
21:54:55 Join angelwolf71885 [0] (
21:55:16ThomasAHok, off to bed, listening to some music or audio book :)
21:56:01 Quit angelwolf71885 (Client Quit)
21:56:28 Join angelwolf71885 [0] (
21:58:06 Quit angelwolf71885 (Client Quit)
21:59:13 Quit funman (Quit: free(random());)
22:00:01FlynDicefunman: 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] (
22:03:19kugelerr, I think I made a mistake with my udelay logic
22:04:36 Join RadicalR2 [0] (
22:04:37 Quit RadicalR (Read error: Connection reset by peer)
22:04:48 Quit Strife89 (Quit: See y'all.)
22:05:12kugeluhm yes
22:05:55FlynDicewell, 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:56kugelthe 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:48kugelFlynDice: try that please
22:18:20 Quit ender` (Quit: I'd kill for a Nobel Peace Prize.)
22:21:21kugeludelay is off pretty badly
22:25:35 Join ender` [0] (
22:27:36 Join [1]w1ll14m [0] (
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 (
22:35:52archivatorsaratoga: Thanks for all the help, btw. I learned a lot today :)
22:38:27 Quit lpereira (Quit: Leaving.)
22:47:41FlynDicekugel: 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:12FlynDiceIf 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] (
22:51:00CIA-5New commit by wodz (r25751): HD200 - fix compile warning in debug_menu.c
22:51:20 Join wodz [0] (
22:52:21wodzamiconn: ping
22:54:25saratogano problem
22:54:31 Join anewuser [0] (anewuser@unaffiliated/anewuser)
22:55:29CIA-5New commit by b0hoon (r25752): Packard Bell Vibe: language corrections in the manual, thanks to: AlexP, linuxstb.
22:57:17wodzhmm I have no luck today to have a chat with amiconn :-/
22:59:19kugelFlynDice: probably
22:59:31kugelthe udelay should work with that change. can you try 5000?
23:00:28 Quit esperegu (Read error: Connection reset by peer)
23:00:52 Join phanboy4 [0] (
23:01:06 Join shai_ [0] (
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:09FlynDicekugel: I don't get the panic using 5000 but it doesn't make anything work any better.
23:07:03FlynDiceback later
23:07:55 Nick fxb__ is now known as fxb (
23:11:36 Quit efyx (Remote host closed the connection)
23:22:40 Join bmbl [0] (
23:22:40 Quit bmbl (Changing host)
23:22:40 Join bmbl [0] (~Miranda@unaffiliated/bmbl)
23:24:50kugel5000 is really a huge delay, it should be much longer than the old mci_delay()
23:28:46 Join fdinel [0] (
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.
23:37:31 Quit CGL (Quit: Saliendo)
23:40:14 Join stripwax [0] (
23:47:18 Quit RadicalR2 (Ping timeout: 265 seconds)
23:47:25 Quit bmbl (Quit: Bye!)
23:47:27archivatorI think FS #11219 is complete, anyone mind looking into it/committing it?
23:47:57 Join RadicalR [0] (
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@
23:54:02kugelarchivator: does it fix any existing problem?
23:56:01 Join RadicalR [0] (
23:56:49 Quit kugel (Remote host closed the connection)
23:57:45 Quit jgarvey (Quit: Leaving)
23:58:56 Quit stripwax (Quit:

Previous day | Next day