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).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2015-01-06

00:01:09 Quit AlexP (Read error: Connection reset by peer)
00:12:26 Quit amayer (Quit: Leaving)
00:36:55***Saving seen data "./dancer.seen"
00:38:30 Quit bertrik (Remote host closed the connection)
00:59:34 Join AlexP [0] (~alex@rockbox/staff/AlexP)
01:01:06*[Saint] is getting slightly sick of GCRaistlin
01:01:17[Saint]...I should just leave the damn thread alone, lol.
01:02:09[Saint]I'm sure its unintentional, well, at least I'd like to hope its unintentional, but the sir and/or madam seems to know _exactly_ how to press my buttons.
01:04:17 Quit RiD (Quit: A good plan today is better than a perfect plan tomorrow.)
01:12:27*sobukus confused about fixedpoint.c
01:12:28sobukuslong fp16_log(int x)
01:12:42sobukusThe comment says it assumes that int at least 32 bits.
01:12:56sobukusSo why bother with long return value instead of int?
01:13:14sobukusIs that true on all targets? int == long?
01:18:48 Quit sakax (Ping timeout: 264 seconds)
01:33:20 Quit AlexP (Remote host closed the connection)
01:38:38 Join michaelni_ [0] (
01:41:20 Quit michaelni (Ping timeout: 265 seconds)
02:24:31sobukusGreat, now my metronome works using fixed point math in the simulator, but is broken on the real device.
02:30:37sobukusIt works after moving a cast to long into place where an int is present.
02:30:50sobukusWhatever ...
02:31:11[Franklin]sobukus: people use long because they're too lazy to write long long :P
02:34:07sobukusIs long long 64 bit on the sansas?
02:34:12fs-bluebot3Gerrit review #64 at : 3Remove svn id. by Torne Wuff
02:34:50[Franklin]sobukus: best use (u)int64_t
02:35:29sobukusI had (long)(60*unsigned_int_value_1024)<<16 and changed that to ((long)60*unsigned_int_value_1024)<<16 ...
02:35:50sobukusThat fixed the whole thing.
02:35:56sobukusOn the device.
02:36:01[Franklin]casting in C can be very nasty...
02:36:26sobukusCan you explain to me then, why lib/fixedpoint/fixedpoint.c assumes that int is 32 bits?
02:36:42sobukuslong fp16_log(int x) <−− that doesn't make sense to me
02:36:48[Franklin]I believe that it assumes that it is at /least/ 32 bits
02:36:57***Saving seen data "./dancer.seen"
02:37:03[Franklin]sobukus: just assume like you did before that sizeof(int) == sizeof(long)
02:37:36sobukusOK, then ... so what is 60*1024 vs (long)60*1024 on the Clip+?
02:37:43sobukusWhy is that differnt?
02:37:55[Franklin]I don't know
02:39:28sobukusHm ... 60*1024 is over 2**15 ... so when shifted by 16 bits it might flip out in an signed value
02:40:00[Franklin]61440 to be exact
02:40:02sobukusSo 60*(unsigned int)1024 -> signed int value 32 bits
02:40:16[Franklin]60 is signed I believe
02:40:36[Franklin]I guess it's best to use the right suffixes where needed
02:40:43sobukus(60*(unsigned int)1024)<<16 could be implementation defined, then
02:40:43[Franklin]or just casts
02:40:51[Franklin]yes, exactly
02:41:18sobukusToo bad that the simulator build defines it differntly than the hardware build.
02:41:39sobukusSo I don't want (long), but something unsigned ... long just happens to be ... 64 bits?!
02:41:40[Franklin]sobukus: the simulator is but an SDL application with a rockbox-ish API
02:42:06[Franklin]so if your host is 64 bits, so is the "emulated" device
02:42:13sobukusAre the sizes of the types on the devices in those config headers, too?
02:42:51sobukusI'm talking about the device. On the device, it works with the (long)60. I don't quite understand why, assuming long is 32 bits.
02:43:14sobukusI guess the arm toolchain has those definitions ...
02:43:24[Franklin]yeah, I think so too
02:45:25sobukusAnyhow, with fixed-point math I doubled the error to 0.4 s after 120 s playing time.
02:46:38[Franklin]as opposed to what?
02:46:40sobukusWas between 0.13 and 0.2 s before.
02:46:44sobukusWith floating point math.
02:47:51[Franklin]I doubt that (a anyone will use the metronome for more than a minute and (b nobody cares ;)
02:47:57[Franklin]it's fine
02:48:18sobukusThis is 61 bars of 4/4 meter with smoothly changing tempo from 150 to 90 bpm.
02:48:39sobukusSo, I guess it should be better for simple applications.
02:49:09sobukus[Franklin]: And, you're massively wrong about using it for more than a minute. The whole point of my enhancements is being able to play complex tracks with tempo and meter changes.
02:49:44sobukusI need that as a tool to keep time playing those tracks my band has composed.
02:49:53[Franklin]Maybe floating-point math would be better to reduce the round-off error
02:49:57sobukusSo, I'll use it for hours;-)
02:50:11[Franklin]round-off is likely what's causing the errors
02:51:20sobukusMaybe it would be smaller with better units.
02:51:33sobukusI'm using actual bpm now, with values around 100.
02:51:35[Franklin]I think floating-point math would be best for this then
02:51:49sobukusIf I'd switch to beats per second, the numbers look nicer.
02:52:13sobukusBut that might be irrelevant for fixed point, actually.
02:52:31[Franklin]you could even use double-precision numbers if need be
02:52:55sobukusAbout 1 ms per beat I have to accept using the timer thing, that explains 0.2 s easily.
02:53:10sobukusI could of course increase timer resolution first.
02:53:38 Quit ZincAlloy (Quit: Leaving.)
02:54:14sobukus[Franklin]: Too bad that I spent all the time getting the fixed point stuff going.
02:55:39[Franklin]sobukus: for the faster targets (CPU_FREQ > 100000000 maybe), you should be able to use floating-point numbers
02:56:14sobukus[Franklin]: Well, I already said that the Clip+ seems to have no issue with floating point.
02:56:39sobukusIt seemed to work well. I just followed the advice and thought that it might be less cpu-intensive.
02:57:07[Franklin]the clip is actually a very powerful player
02:57:19[Franklin]~250MHz IIRC
02:59:30sobukusYes, it can play Doom!
02:59:58sobukuswith that funky dithering so that you actually see something on a monochrome display
03:08:09 Quit [Franklin] (Remote host closed the connection)
03:11:15 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs)
03:46:13sobukusGn... even the TIMER_FREQ values are different in UI simulator and hardware.
04:18:20[Saint]well, this stands to reason.
04:18:52sobukusDoes it? I see 1000000 vs. 1500000.
04:37:01***Saving seen data "./dancer.seen"
05:16:56 Quit TheSeven (Ping timeout: 244 seconds)
05:18:36 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
05:51:36 Quit krabador (Quit: Take the time.)
05:58:29 Quit Strife89 (Ping timeout: 265 seconds)
06:37:02***Saving seen data "./dancer.seen"
08:37:06***No seen item changed, no save performed.
08:58:20 Join petur [0] (5bb7304d@rockbox/developer/petur)
08:59:33 Quit alucryd (Remote host closed the connection)
09:01:11 Join alucryd [0] (~quassel@archlinux/trusteduser/alucryd)
09:14:42 Join einhirn [0] (
09:38:15 Quit petur (Ping timeout: 246 seconds)
09:44:54 Join petur [0] (5bb7304d@rockbox/developer/petur)
09:49:18 Quit kugel (Ping timeout: 255 seconds)
09:49:22 Join kugel__ [0] (
09:49:27 Quit kugel__ (Changing host)
09:49:27 Join kugel__ [0] (~kugel@rockbox/developer/kugel)
09:51:00 Join edhelas [0] (~edhelas@
10:14:37 Join ender` [0] (
10:18:48 Join AlexP [0] (~alex@rockbox/staff/AlexP)
10:37:09***Saving seen data "./dancer.seen"
10:38:52 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
10:45:17 Nick kugel__ is now known as kugel (~kugel@rockbox/developer/kugel)
10:45:58kugelsobukus: depending on the range of numbers you need, fixed point math can be more accurate
10:46:30kugelhowever you need to chose the fractional bits wisely
10:51:32kugel0.4s after 120s for your (i assume) s15.16 split sounds like a lot, i don't think it is caused by the fp math itself
10:54:05kugelyou could also change your scheme to measure in (fractions of) minutes and increase the fractional part to perhaps 20 bits or more
10:55:24 Quit AlexP (Remote host closed the connection)
11:20:21 Part XavierGr
11:23:29sobukuskugel: Your're right that the math doesn't seem to be the problem. I get wildly differing results by changing the timer setup.
11:36:22 Quit Provel (Quit: Provel)
11:44:55sobukusActually, in another test, with 64 beats of 125 ms each (8 seconds in all), the Rockbox metronome is off by 310 ms, 60 ms, 10 ms, 45 ms for timer freq division by 100, 250, 500, 1000, 2000.
11:45:24sobukus10 ms after 64 beats with a timer resolution of about 1.5 ms is not that bad.
11:46:32sobukusit would be nice to work against the quantization error. Increasing the number of timer interrupts worsens the result again. I think I'll try some compensation scheme.
11:48:55 Join maruk1 [0] (
12:28:36 Quit einhirn (Ping timeout: 245 seconds)
12:32:50 Join xorly [0] (
12:37:12***Saving seen data "./dancer.seen"
12:57:01 Join lorenzo92 [0] (
13:21:26 Join AlexP [0] (~alex@rockbox/staff/AlexP)
13:26:25sobukusThis is interesting. Someone got an idea how much clock drift should there be when comparing a synthetic PCM file with the result of playing that file on a Sansa Clip+ and recording on the laptop?
13:27:17sobukusI get 5 ms difference in 16 s playing time ... is that reasonable as combined time drift from Sansa and Laptop clock drift?
13:28:27sobukusThis would mean something along 48015 Hz instead of 48000 Hz audio clock. Is reality that bad?
13:38:47sobukusHm, I read that this might well be.
13:38:59sobukusAnd that this might even not be a bad value.
13:42:32gevaertsYou can probably work out the expected drift from the PLL settings
13:43:43sobukusI'm eliminating the pc sound card now and am comparing the pre-created PCM and the metronome playback both from the Clip+.
13:45:21sobukusThere, I still see that the metronome is laggin a bit. Interestingly, it is best with really low timer rate (every 13 ms or so) plus roundoff compensation (carrying the rounding error and using it on the next round).
13:45:55sobukusI wonder why high timer resolution results in drift so quickly.
13:46:20sobukusIf the callback is triggered from an interrupt ... the interrupt itself is lagging behind?!
13:47:54sobukusShould timing be worse with 1 ms intervals when compared to 10 ms?
13:57:01sobukusgevaerts: I can keep the metronome varying between 20 ms off < 1 ms off with a timer division of 29 (34 ms interval) and rounding compensation.
13:57:42sobukusI am seriuously wondering how I should determin a good timer interval. It seems to detoriate massively if it is too high.
13:58:02sobukusBut 20 ms random error, even if it evens out in the mean, is jerky.
14:03:24sobukusSo I have to compromise between being accurate in overall duration (drift) or accurate in keeping lengths of beats the same (rounding compensation introducing jumps of a few ms).
14:05:26sobukusWith 1 ms timer, the overall drift over 32 beats @ 120 bpm is 40 ms ... 119.7 bpm instead of 120.
14:06:29sobukusIt's 10 ms with 1.5 ms timer interval.
14:06:59sobukusSame with 13 ms timer interval and rounding compensation, but that sounds jumpy.,
14:07:30gevaertsI'm not a musician, but a low drift seems acceptable to me. The jitter sounds a lot more annoying
14:09:51maraz119.7 instead of 120 is unacceptable for doing any serious work.
14:10:11marazI guess nobody would use a rockbox metronome for recording, though.
14:10:35sobukusmaraz: Well, I guess 119.7 would be no issue for live performance.
14:10:51sobukusFor recording, you have to get the metronome from the same clock that does the recording, no way around that.
14:10:59marazif everyone syncs to it, fine
14:12:05sobukusI mean, if you intend to play using an external metronome, regardless how good, and then expect the beats to exactly match the klick track on the DAW / workstation, you will be disapointed anyway.
14:13:37sobukusmaraz: But I get it that I should find a middle ground there, with acceptable drift and low jittering (if that's the correct term here, actually).
14:15:19 Join einhirn [0] (
14:15:42sobukusIn the end ... there might be a SW_CODEC-only metronome that actually produces a PCM stream with sample-accurate timing between beats. That will just be subject to the unavoidable clock drift of the DAC.
14:17:22sobukusBut if I could calculate and compensate for the drift with high timer resolution ... but then, I have no idea why it's present at all. The CPU should have enough cycles.
14:21:15gevaertssobukus: are you using the old method of having the interrupt handler set a flag?
14:22:30gevaertsBecause then if you go (far?) under 10ms, you might start noticing interference between the scheduler tick and your timer
14:22:50gevaertsWell, for some values of interference that technically aren't interference but something else :)
14:26:36sobukusgevaerts: Oh, interesting. Given that the metronome originally was written in 2004, I assume it uses any old method there is.
14:26:55sobukus rb->timer_register(1, NULL, TIMER_FREQ/timerfreq_div, timer_callback IF_COP(, CPU));
14:28:13sobukusDoesn't look flaggy ... is this the current way?
14:32:07gevaertssobukus: but what does timer_callback() do?
14:32:08sobukusgevaerts: But your 10 ms boundary seems to fit. I am lagging behind for 1 ms, 2 ms, still with 10 ms, but less.
14:32:42sobukusgevaerts: It counts how often it is called and triggers action after a certain number of calls.
14:34:10gevaertssobukus: it still does the need_to_play = true;
14:35:34gevaertsAnd that's checked in the plugin's main loop, which yields. I'm assuming the scheduler's normal 10ms tick might have something to say there
14:35:44sobukusHm. That's the SWCODEC difference ...
14:36:07sobukusOh, right, that's nasty. but Should it introduce drift?
14:36:21gevaertslong-term drift, I shouldn't think so
14:36:28gevaertsShort-term jitter, sure
14:36:35sobukusBut it explains why 10 ms offset is about the best I get.
14:36:46gevaertsUnless you somehow compensate...
14:37:10sobukusSo, is there a way to trigger playback from the timer callback?
14:37:14sobukuswith SWCODEC?
14:37:15***No seen item changed, no save performed.
14:37:37gevaertsI don't think so
14:38:45gevaertsOne thing that might be possible is to introduce between 0 and 10ms of silence before the sound, depending on where you are when you play the sound (you can keep a high resolution timer from within timer_callback() to measure this)
14:39:08sobukusDo you understand why I get much larger drift with timer resolution of 1 ms? It's 43 ms instead of 10 ms over 16 s.
14:39:17gevaertsYou'd add 10ms latency to the entire thing that way, but I don't really see an issue with that
14:40:34sobukusOne issue there is: display indication and sound would be subtly out of sync
14:40:50gevaerts10ms is too low for that to be visible I think
14:41:09gevaertsBut if not, you could compensate the display bit too :)
14:41:29sobukusI don't see how.
14:41:44sobukusWith the sound, I can stuff in PCM samples in sample-accurate fashion.
14:42:22gevaertsBy the way, I'm not convinced that draw_display() from the timer callback is safe
14:43:07lorenzo92indeed, it adds delay, considerably I guess
14:43:08pamauryI think it's quite unsafe because timer callbacks may be called in interrupt context
14:44:08sobukusI can understand that ... does that also apply for HWCODEC?
14:44:17sobukusSince there, playing MP3 from the timer is OK.
14:45:51lorenzo92it depends on the operation, refreshing a display takes some time, especially on targets without DMA
14:46:34sobukuslorenzo92: you mean, doing that stuff in the callback will indeed cause drift? I get it that it's a bad idea generally, but I wonder if that should cause the long-term drift.
14:47:17gevaertsIf it causes you to miss a tick every now and then, maybe?
14:47:47sobukusSo timer callbacks are not enqueued. There's an interrupt firing and if you're not ready to catch it it is gone. Right?
14:47:55sobukusThen I understand it well.
14:48:53gevaertsYes. For timers, the only thing between your callback and the hardware is a thin abstraction layer to present a unified API
14:49:50sobukusThen I'm surprised it worked so well so far! ;-)
14:50:11lorenzo92sobukus: yes, it might add delay. To be honest it depends on the implementation details, but definitely yes
14:50:21sobukusI should get rid of the drift, but will have the scheduler interval messing with steadyness.
14:50:33sobukusThanks for clearing that up.
14:50:46lorenzo92np ;) let us know
14:56:36 Join tory [0] (981a1ad5@gateway/web/freenode/ip.
14:56:36sobukusOK, with 1000 timerdiv, it's down to 16 ms instead of 32 ms over 16 s.
14:56:46sobukusAfter removing the display clearing in the callback.
14:57:01sobukusOK, with 1000 timerdiv, it's down to 16 ms instead of 43 ms over 16 s. <−− typo, 43 it was
14:59:42 Quit cmhobbs (Remote host closed the connection)
15:01:13sobukuslorenzo92: no effect with 500 division, still around 10 ms drift over 16 s
15:01:41sobukusAnd it's really accumulating drift, it's 5 ms after 8 s.
15:02:06sobukusThe main loop doesn't seem to introduce much timing error.
15:02:22sobukusOr ... perhaps it does and I see the drift go down after some time.
15:04:26kugeltimers are usually independant of how long the ISR runs
15:04:57kugelso heavy could shouldn't cause problem as long as it fits within a cycle
15:05:13kugeldrawing to the display is still not safe from the callback
15:07:15 Quit tory (Ping timeout: 246 seconds)
15:13:24sobukusWell, also without the drawing, I confirm that I have a continued drift. I have 50 ms difference after 70 seconds.
15:17:25gevaertsDrift compared to what? Wall clock, or DAC sample clock?
15:17:28gevaertsOr both?
15:18:59sobukusDrift compared to playing a generated PCM file (WAV) from the Sansa.
15:19:31sobukusgevaerts: I'm assuming that I should not get drift relative to the Sansa's own audio clock.
15:20:42gevaertsI'm not sure
15:21:18gevaertsYou're assuming 44100 (or 48000 maybe) samples per local clock second, I assume?
15:22:47sobukusi'm not assuming anything there.
15:23:13sobukus1. I play the WAV file on the Sansa (happens to be 48000 kHz), record on laptop with 48 kHz
15:23:32sobukus2. I play metronome (happens to be at 44.1 kHz ...), record on laptop with 48 kHz
15:23:48sobukusIf the sansa clock is really bad at 44.1 kHz, that would explain it, too.
15:24:11gevaerts;a=commit;h=b73d15e9c6175ac48b2280b089a40f0554d15d6f is the most recent thing I find
15:24:18sobukusIs there a relation between timer and rb->pcm_set_frequency(SAMPR_44);
15:24:44sobukusWow. 1.1 % was it?
15:24:53gevaertsSo at 44.1kHz I'd expect 0.04% error
15:25:42gevaertsi.e. 28ms for 70s
15:26:00gevaertsThat's in the same order as what you're seeing
15:26:05funmanI think this table is related:;a=blob;f=firmware/target/arm/as3525/pcm-as3525.c;h=eb22fc201630dfad184879f93fd5116b8cf27da6;hb=HEAD#l196
15:26:20sobukusHm, that matches the difference between the WAV file re-recorded from the sansa compared to the original WAV file.
15:26:32sobukusat 48 kHz
15:27:00sobukus0.03 % error there
15:29:28sobukusSo ... I'm trying what the metronome does when clocked at 48 KHz ...
15:30:16gevaertsThese variations are going to be SoC-dependent of course
15:30:43sobukusWhat I'm aiming for is to be at as drifty as the audio clock, not more ...
15:31:19*gevaerts nods
15:33:36funmanopinion on ?
15:33:43sobukusOK, I can confirm that the metronome still drifts compared to WAV playback when both are at 48 kHz.
15:33:47funmanhere is the gcc output:
15:34:27gevaertssobukus: did you set playback to 48kHz, or did it resample?
15:35:21gevaertsfunman: looks correct at first sight
15:36:15funmangevaerts: should I submit it to gerrit for review?
15:38:25sobukusgevaerts: I just did rb->pcm_set_frequency(SAMPR_48); , playing the pcm sound at a slightly higher pitch
15:40:25sobukusIs there experience with possible long-term drift of timers with other applications?
15:45:30gevaertsfunman: maybe for a day or so
15:45:37gevaertsNot too long, if you need it :)
15:46:19sobukus <−− the PLL discussion ... is it now the case that there is a different PLL used for CPU than for audio?
15:47:44sobukusAm I seeing drift between PLLA and PLLB?
15:47:50gevaertssobukus: I'd recommend asking bertrik about this later today
15:47:59gevaertsHe probably knows
15:48:14gevaertsAlthough I suspect funman might also know some of this :)
15:48:38funmansobukus: which player is it?
15:49:46sobukusSansa Clip+
15:50:13sobukus /* on AMSv2 we can enable PLLB for MCLK to increase PCM sample rate accuracy */ <−− that seems to apply here
15:51:57sobukusI see 0.07 % difference in runtime ... that would match PLLA vs. PLLB, I presume.
15:53:25sobukus_plus_ additional drift from choosing too small timer intervals
15:55:34sobukusIs the scheduler interval always around 10 ms?
15:56:30sobukusIf so, I can just, like use 1/250 (4 ms) for the timer and be done with it ... nothing to gain by increasing resolution.
16:04:28 Quit edhelas (Quit: Quitte)
16:10:30sobukusgevaerts: I can sleep for some milliseconds (or fractions of) using rb->sleep()?
16:10:36*sobukus looking for the definition of HZ
16:10:59sobukusWhat's the resolution of that one?
16:11:40gevaerts10ms, assuming no other active threads
16:12:10sobukusOK. So meaningless for syncing display to an audio shift < 10 ms.
16:12:54sobukusWell, if one agrees that display can be out of sync by 10 ms ... then being out of sync by 10 ms overall must be acceptable.
16:13:23sobukusThe tick sound itself is about 36 ms long ...
16:13:35 Quit JanC (Read error: Connection reset by peer)
16:14:01sobukus14:38 < gevaerts> One thing that might be possible is to introduce between 0 and 10ms of silence
16:14:11sobukus^^ regarding that ... I guess it wouldn't be worth it
16:15:15sobukusIf the metronome for now was fine enough for me regarding the timing itself, then it should still work as it did before. I'm just improving the long-term drift for tempi that don't divide well by the timer period.
16:15:32gevaertsI don't know. I have no idea how noticeable that is for a trained musician
16:15:33sobukusTo the limit the hardware allows, apparently;-)
16:16:13sobukusgevaerts: Is there a minimal time delay rb->yield() will introduce or does that totally depend on the situation on the device?
16:16:50gevaertsI wouldn't assume too much about that
16:17:10sobukusSo, I wouldn't even know what maximum time to compensate for with delaying audio.
16:17:15gevaertsYou'll be pushed to the next tick, but depending on other things that might be very soon
16:18:09pamaurygevaerts: no objection to g#1098 and its dependencies ? You reviwers the 2 or 3 first patches, the last ones are mostly trivial but we never know
16:18:13fs-bluebot3Gerrit review #1098 at : 3usb: make usb_release_exclusive_storage private by Amaury Pouly
16:18:26gevaertspamaury: go ahead
16:22:21funmanwhy was my g#1123 not picked up by fs-bluebot ?
16:25:44pamaurygevaerts: who is admit on gerrit ?
16:26:36gevaertspamaury: people->list groups->administrators :)
16:27:27pamaurydamn, is any of them on the channel ?
16:28:06pamaurynope :(
16:28:11gevaertsYou can always try hunting for them in other channels
16:29:46 Join JanC [0] (~janc@lugwv/member/JanC)
16:31:10pamauryI'm sent an email
16:32:31 Join saratoga [0] (123e11e0@gateway/web/freenode/ip.
16:32:56saratogasobukus: we're probably going to switch the AMSv2 PLLs to use the A for both audio and CPU (that includes the Clip+)
16:33:09saratogaafter that you won't see drift between the audio and timer clocks most likely
16:33:19saratogasince they'll be phase locked
16:33:33sobukussaratoga: But isn't then the accuracy of the audio frequency bad again?
16:33:34sobukusOr do you mean PLL B?
16:33:35saratogaalthough you will still see the constant pitch error due to PLL dividers
16:33:53saratogano, we're going to run the CPU off the frequency the audio needs
16:34:39saratogathe only reason PLLB was ever used was that originally the reverse engineered PLL settings werent' correct for 44.1k audio (i believe this was sandisk's fault)
16:34:48sobukusOK, sorry for being thick: How will the audio freq. error be in the new setup? 0.04 % or 0.14 % ... ?
16:34:49sobukusOr better?
16:34:57saratogaso the CPU and audio ended up needing two slightly different clocks, hence two PLLs were used
16:35:06saratogathe audio frequency won't change at all
16:35:22saratogabut the CPU frequency will change to be related to the audio frequency by a rational number
16:35:43saratogato within some small number of picoseconds
16:35:48sobukusAh. That sounds nice.
16:36:22sobukusSo we're back to one PLL, improving battery life, even?
16:37:16***Saving seen data "./dancer.seen"
16:38:01sobukus"clip+ show abnormally high battery runtime after changing it," I like that phrase;-)
16:38:34sobukusThat patch sounds like a win-win-win situation, if the too-low voltage stuff is sorted out!
16:39:33 Join amayer [0] (
16:39:38saratogayeah it needs a bit of work, especially on the fuzev1
16:39:40saratogaerr v2
16:40:04sobukusI guess Rockbox is a major reason why the Sansa Clips are still selling,.
16:40:34sobukusI was amazed to still find the Clip+ in stores last year. And it still rocks ... thanks to Rockbox!
16:43:14saratogaits a neat piece of hardware
16:44:10 Nick eeeeeta is now known as pets (~eeeeeta@gateway/tor-sasl/eeeeeta)
16:44:15 Nick pets is now known as eeeeeta (~eeeeeta@gateway/tor-sasl/eeeeeta)
16:45:14funmansaratoga: do you remember what is as3515? #define AS3515_USB_UTIL 0x17 /* only in as3515 */
16:45:29saratogatype for as3517?
16:45:45saratogaor was it 15
16:46:32funmanseems amsv1 only though
16:46:39funmanso probably not interesting
16:47:08saratogaah ok
16:51:31*sobukus notes that the metrnonme is strangely slow in the UI simulator now, but works fine on the hardware
16:52:29lorenzo92stash@{1}: WIP on master: bce72e6 buflib: Switch from term "cookie" to "metadata"
16:52:31lorenzo92stash@{2}: WIP on master: 812406f Limit "struct dircache_runinfo" to file scope
16:52:35lorenzo92is that supposed to be there?
16:55:20lorenzo92hmm I'm now unsure if stashes are always local only ^^
16:56:28funmanlorenzo92: yes, local only
16:56:50lorenzo92thanks, then I simply don't remember about what I did :P
17:03:34 Join N0Lif3 [0] (
17:09:40 Join edhelas [0] (~edhelas@
17:11:12 Join pystar89 [0] (
17:19:13 Join tory [0] (981a1ad5@gateway/web/freenode/ip.
17:22:08 Quit amayer (Quit: Leaving)
17:27:08 Quit petur (Quit: Page closed)
17:27:46 Join amayer [0] (
17:29:25N0Lif3I have a pair of earbuds that have a button on the cable. When I'm listening to music on my android phone, this button on the earbuds works as a Pause/Play button. I tried using this button while listening to music on my rockbox firmware Sansa Clip+ and it does nothing. Is there a way to program this button in rockbox to do something?
17:30:23N0Lif3They're Skullcandy Titan earbuds, I tried googling "skullcandy titan rockbox" and don't see a relevant answer
17:32:25gevaertsI don't think the sansas have the necessary GPIOs on the headphone socket for that, but I'm not sure
17:32:45 Join Strife89 [0] (
17:34:28 Quit foolsh (Ping timeout: 265 seconds)
17:36:09N0Lif3I'm not familiar with the concept of GPIOs, but I think this explains why my android phone KNOWS when I plug in or remove headphones from it. Like, when I plug in headphones it'll automatically adjust the volume and display a message saying it's to protect my ears and my podcast app will automatically pause the podcast playing if I remove the headphones
17:36:29toryRB does that too ;)
17:36:36 Quit tory (Quit: Page closed)
17:38:36gevaertsNot on all devices...
17:41:18lorenzo92actually, buttons are not only GPIO stuff. Android devices (at least my gnex) does ADC on the 4 pin (oh, I actually don't remember the pin nummer)
17:41:31 Quit AlexP (Remote host closed the connection)
17:42:07lorenzo92so, buttons are connected via different resistors, and pressing them makes the resistance to change, thus a corresponding voltage is read. Put some hysteresis and debouncing and that's it ;)
17:43:11lorenzo92NOLif3: definitely, a simple present / not present is handled by a single GPIO
17:44:11lorenzo92to understand better, you can practically think of a GPIO as being a binary value. ~0volts (+/- a certain degree) is 0, and 3.3v/5v is 1
17:46:28saratogathe sandisk devices don't have any logic for communicating or detecting headphones
17:46:49saratogaexcept IIRC they can detect if headphones are inserted (but not removed)
17:48:11 Quit pamaury (Remote host closed the connection)
17:48:17 Quit edhelas (Ping timeout: 256 seconds)
17:48:22lorenzo92saratoga: that sounds strange. insertion only? hmm
17:48:36saratogayeah beats me
17:48:43saratogaits what the docs say
17:50:30lorenzo92perhaps they are using the GPIO that is offered by wmcodec, and it does not interrupt for the removal, who knows ;)
17:51:05saratogaits handled by the DAC chip directly, for whatever reason it can only generate an interrupt on insert IIRC
17:51:51 Join pamaury [0] (
17:51:51 Quit pamaury (Changing host)
17:51:51 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
17:52:28 Quit pamaury (Remote host closed the connection)
17:52:31 Join foolsh [0] (
17:54:27lorenzo92saratoga: right, was wondering the same
18:00:52N0Lif3surely rockbox has been ported to devices that do have all this functionality that you guys have mentioned. Is there a way to check and see if the button on my earbuds can be bound to a command in rockbox?
18:01:21N0Lif3and then I could try it out and report back if the button did anything or not
18:05:12 Quit foolsh (Ping timeout: 244 seconds)
18:11:04 Join foolsh [0] (
18:11:40 Join ZincAlloy [0] (
18:12:12 Join bertrik [0] (~quassel@rockbox/developer/bertrik)
18:12:37lorenzo92NOLif3: erhm, if the hardware support is missing, then no
18:14:07lorenzo92(if I correctly get the question)
18:21:38 Quit Strife89 (Ping timeout: 264 seconds)
18:23:34 Join edhelas [0] (
18:26:05 Join desowin [0] (
18:30:30 Quit edhelas (Quit: Quitte)
18:30:50 Join edhelas [0] (
18:31:16 Quit edhelas (Remote host closed the connection)
18:31:20 Join edhelas_ [0] (
18:31:20 Quit edhelas_ (Client Quit)
18:31:50 Join edhelas [0] (
18:33:23 Join AlexP [0] (~alex@rockbox/staff/AlexP)
18:35:27 Quit maruk1 (Quit: Leaving.)
18:37:19***Saving seen data "./dancer.seen"
18:40:51saratogascorche: any idea if its safe to ban sleezy email hosts from "registering" rather then just banning them outright?
18:41:04saratogai know if I ban * it bans existing users
18:41:20saratogabut if I just block them from registering that leaves existing users alone right?
18:41:41 Join pmarty [0] (1f0b95e1@gateway/web/freenode/ip.
18:48:34 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier.
18:48:44 Quit pmarty (Quit: Page closed)
18:51:57 Join pmarty [0] (1f0b95e1@gateway/web/freenode/ip.
18:54:10 Quit dfkt (Remote host closed the connection)
18:55:27 Join dfkt [0] (dfkt@unaffiliated/dfkt)
18:57:03pmartyHello, folks! I need to restore an 6g "classic" ipod under linux (original fw, not rb). I partitioned the drive with a single partition (since there's no firmware to load from disk) and formatted it with mkdosfs. the drive is 4K/4K physical/logical sector size.
18:57:34pmartybut it tells me to connect it to iTunes
18:58:04*sobukus deciding to let the metronome accuracy settle now around 2 ms max fluctuation with unavoidable drift
18:58:21pmartydo I need to put some files on the filesystem?
18:58:46*sobukus doesn't know anyting 'bout ipods
19:03:49pmartyare ipods /that/ sensitive to mbr layout that you guys ship dedicated ones?
19:04:03gevaertsI'm not entirely sure, but as far as I know nobody worked out an itunes-less way to restore the classic
19:04:26gevaertspmarty: many partitioning tools make it hard to make a partition with type 0
19:08:47pmartyyes, there might be some magic involved
19:09:03pmartybut 5g did restore by itself with an empty filesystem
19:09:52gevaertsYes, 5g and earlier are fairly easy
19:12:19 Quit bertrik (Remote host closed the connection)
19:14:31 Quit edhelas (Ping timeout: 265 seconds)
19:27:05 Join RiD [0] (
19:31:05 Join krabador [0] (~krabador_@unaffiliated/krabador)
19:37:07 Join lebellium [0] (
19:37:14scorche|shsaratoga: that sounds like it would be safe enough - go ahead and test if you can
19:38:53saratogacan you check afterwards if existing users are banned ?
19:38:59saratogai don't have access to taht
19:41:10scorche|shi'd think it'd be fine to just test it with gmail (or something else you have access to) real quick - the forums aren't *that* busy these days, no?
19:41:26 Quit AlexP (Ping timeout: 264 seconds)
19:41:37scorche|sh...can quickly see if an existing account you control is banned and see if you can register a new one
19:41:42scorche|shor mailinator or something
19:42:22scorche|shmailinator would likely be easier to try than gmail ;)
19:44:37 Join AlexP [0] (~alex@rockbox/staff/AlexP)
19:45:30saratogaok i'll try now
19:51:12 Quit pmarty (Quit: Page closed)
19:57:32saratogascorche|sh: yes it works as expected
19:58:05saratogaany chance that we could change the message it shows though ("sorry you are not allied to register") to something more specific ("Please register using a different email host")?
19:58:28scorche|shpotentially - i cant look at it at the moment though
19:58:38scorche|shcould you email me and then i can remember to look at that when i get home?
19:58:54saratogai'd like to ban a few spammy web mail hosts but i'd hate to block out a legit user
19:59:24saratogayour gmail ok?
20:01:30 Join stoyan [0] (~io-headqu@
20:11:23 Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
20:13:39 Quit AlexP (Read error: Connection reset by peer)
20:13:55 Join AlexP [0] (~alex@rockbox/staff/AlexP)
20:37:20***Saving seen data "./dancer.seen"
20:54:29 Quit AlexP (Read error: Connection reset by peer)
20:54:39 Join AlexP [0] (~alex@rockbox/staff/AlexP)
20:57:57 Quit bertrik (Ping timeout: 265 seconds)
20:59:21 Join petur [0] (
20:59:27 Quit petur (Changing host)
20:59:27 Join petur [0] (~petur@rockbox/developer/petur)
20:59:40 Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
21:02:43 Quit stoyan (Quit: ChatZilla [XULRunner 35.0/20141229214612])
21:10:15 Quit AlexP (Read error: Connection reset by peer)
21:10:35 Join AlexP [0] (~alex@rockbox/staff/AlexP)
21:32:05 Quit AlexP (Read error: Connection reset by peer)
21:32:35 Join AlexP [0] (~alex@rockbox/staff/AlexP)
21:37:50 Quit bertrik (Ping timeout: 264 seconds)
21:39:27 Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
21:56:05 Quit lorenzo92 (Ping timeout: 245 seconds)
22:15:47 Join ZincAlloy1 [0] (
22:18:37 Quit ZincAlloy (Ping timeout: 264 seconds)
22:37:23***Saving seen data "./dancer.seen"
22:42:31 Quit petur (Remote host closed the connection)
22:42:49 Join dfkt_ [0] (~dfkt@unaffiliated/dfkt)
22:42:58 Quit dfkt (Disconnected by services)
22:43:14 Nick dfkt_ is now known as dfkt (~dfkt@unaffiliated/dfkt)
22:49:17 Quit bertrik (Quit: Lost terminal)
22:54:42 Join dfkt_ [0] (dfkt@unaffiliated/dfkt)
22:54:51 Quit dfkt (Disconnected by services)
22:55:03 Join ZincAlloy [0] (
22:55:06 Nick dfkt_ is now known as dfkt (dfkt@unaffiliated/dfkt)
22:55:25 Join [Franklin] [0] (
22:55:44 Quit [Franklin] (Changing host)
22:55:44 Join [Franklin] [0] (~franklin@unaffiliated/franklin)
22:55:55 Join dfkt_ [0] (dfkt@unaffiliated/dfkt)
22:56:50 Join ZincAlloy2 [0] (
22:58:40 Quit ZincAlloy1 (Ping timeout: 244 seconds)
22:59:45 Quit dfkt (Ping timeout: 265 seconds)
23:00:13 Quit dfkt_ (Ping timeout: 244 seconds)
23:00:24 Join dfkt [0] (dfkt@unaffiliated/dfkt)
23:00:51 Quit ZincAlloy (Ping timeout: 240 seconds)
23:03:18 Quit krabador (Quit: Take the time.)
23:03:20 Join ZincAlloy [0] (
23:03:21 Quit ZincAlloy2 (Ping timeout: 240 seconds)
23:06:36 Join ZincAlloy1 [0] (
23:08:56 Quit ZincAlloy (Ping timeout: 265 seconds)
23:10:44 Quit Galois (Ping timeout: 250 seconds)
23:13:39 Join dfkt_ [0] (~dfkt@unaffiliated/dfkt)
23:13:48 Quit amayer (Quit: Leaving)
23:14:41 Quit dfkt (Ping timeout: 244 seconds)
23:14:50 Quit fs-bluebot (Ping timeout: 245 seconds)
23:15:51 Quit bluebrother (Ping timeout: 240 seconds)
23:15:59 Join fs-bluebot [0] (
23:17:54 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
23:18:07 Quit dfkt_ (Ping timeout: 265 seconds)
23:18:57 Join Galois [0] (
23:23:48 Join Strife89 [0] (
23:34:32[Franklin]do I OR or add the drawmodes to mix them together?
23:39:30gevaertsIt doesn't really matter (they're all non-overlapping one-bit things), but normally you use the bitwise operators for this sort of thing
23:39:36[Franklin]ah, ok
23:39:58gevaertsSo, or, and, xor, not, and not plus or minus
23:40:10gevaertsAnd definitely not * or / :)
23:40:32[Franklin]well, I got my scrolling road sim working :)
23:40:41gevaertsSame with bitshifting vs dividing/multiplying with powers of two
23:41:20gevaertsIf you care about the bits, you use bit-oriented operators
23:52:17 Quit lebellium (Quit: ChatZilla [Firefox 35.0/20141229214612])

Previous day | Next day