| 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:00 |
| 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:28 | sobukus | long fp16_log(int x) |
| 01:12:42 | sobukus | The comment says it assumes that int at least 32 bits. |
| 01:12:56 | sobukus | So why bother with long return value instead of int? |
| 01:13:14 | sobukus | Is 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] (~michael@chello084114129144.4.15.vie.surfer.at) |
| 01:41:20 | | Quit michaelni (Ping timeout: 265 seconds) |
| 02:00 |
| 02:24:31 | sobukus | Great, now my metronome works using fixed point math in the simulator, but is broken on the real device. |
| 02:30:37 | sobukus | It works after moving a cast to long into place where an int is present. |
| 02:30:50 | sobukus | Whatever ... |
| 02:31:11 | [Franklin] | sobukus: people use long because they're too lazy to write long long :P |
| 02:34:07 | sobukus | Is long long 64 bit on the sansas? |
| 02:34:12 | fs-bluebot | Gerrit review #64 at http://gerrit.rockbox.org/r/64 : Remove svn id. by Torne Wuff |
| 02:34:50 | [Franklin] | sobukus: best use (u)int64_t |
| 02:35:29 | sobukus | I had (long)(60*unsigned_int_value_1024)<<16 and changed that to ((long)60*unsigned_int_value_1024)<<16 ... |
| 02:35:50 | sobukus | That fixed the whole thing. |
| 02:35:56 | sobukus | On the device. |
| 02:36:01 | [Franklin] | casting in C can be very nasty... |
| 02:36:26 | sobukus | Can you explain to me then, why lib/fixedpoint/fixedpoint.c assumes that int is 32 bits? |
| 02:36:42 | sobukus | long 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:36 | sobukus | OK, then ... so what is 60*1024 vs (long)60*1024 on the Clip+? |
| 02:37:43 | sobukus | Why is that differnt? |
| 02:37:55 | [Franklin] | I don't know |
| 02:39:28 | sobukus | Hm ... 60*1024 is over 2**15 ... so when shifted by 16 bits it might flip out in an signed value |
| 02:39:44 | [Franklin] | yeah |
| 02:40:00 | [Franklin] | 61440 to be exact |
| 02:40:02 | sobukus | So 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:43 | sobukus | (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:18 | sobukus | Too bad that the simulator build defines it differntly than the hardware build. |
| 02:41:39 | sobukus | So 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:41:46 | sobukus | Yeah. |
| 02:42:06 | [Franklin] | so if your host is 64 bits, so is the "emulated" device |
| 02:42:13 | sobukus | Are the sizes of the types on the devices in those config headers, too? |
| 02:42:51 | sobukus | I'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:14 | sobukus | I guess the arm toolchain has those definitions ... |
| 02:43:24 | [Franklin] | yeah, I think so too |
| 02:45:25 | sobukus | Anyhow, with fixed-point math I doubled the error to 0.4 s after 120 s playing time. |
| 02:46:26 | [Franklin] | doubled? |
| 02:46:38 | [Franklin] | as opposed to what? |
| 02:46:40 | sobukus | Was between 0.13 and 0.2 s before. |
| 02:46:44 | sobukus | With 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:18 | sobukus | This is 61 bars of 4/4 meter with smoothly changing tempo from 150 to 90 bpm. |
| 02:48:39 | sobukus | So, I guess it should be better for simple applications. |
| 02:49:09 | sobukus | [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:44 | sobukus | I 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:57 | sobukus | So, I'll use it for hours;-) |
| 02:50:11 | [Franklin] | round-off is likely what's causing the errors |
| 02:51:20 | sobukus | Maybe it would be smaller with better units. |
| 02:51:33 | sobukus | I'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:49 | sobukus | If I'd switch to beats per second, the numbers look nicer. |
| 02:52:13 | sobukus | But that might be irrelevant for fixed point, actually. |
| 02:52:31 | [Franklin] | you could even use double-precision numbers if need be |
| 02:52:55 | sobukus | About 1 ms per beat I have to accept using the timer thing, that explains 0.2 s easily. |
| 02:53:10 | sobukus | I could of course increase timer resolution first. |
| 02:53:38 | | Quit ZincAlloy (Quit: Leaving.) |
| 02:54:14 | sobukus | [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:14 | sobukus | [Franklin]: Well, I already said that the Clip+ seems to have no issue with floating point. |
| 02:56:39 | sobukus | It 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:30 | sobukus | Yes, it can play Doom! |
| 02:59:58 | sobukus | with that funky dithering so that you actually see something on a monochrome display |
| 03:00 |
| 03:08:05 | [Franklin] | 'night |
| 03:08:09 | | Quit [Franklin] (Remote host closed the connection) |
| 03:11:15 | | Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) |
| 03:46:13 | sobukus | Gn... even the TIMER_FREQ values are different in UI simulator and hardware. |
| 04:00 |
| 04:18:20 | [Saint] | well, this stands to reason. |
| 04:18:52 | sobukus | Does it? I see 1000000 vs. 1500000. |
| 04:37:01 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 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:00 |
| 06:37:02 | *** | Saving seen data "./dancer.seen" |
| 08:00 |
| 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:00 |
| 09:01:11 | | Join alucryd [0] (~quassel@archlinux/trusteduser/alucryd) |
| 09:14:42 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
| 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] (~kugel@ip5b4084be.dynamic.kabel-deutschland.de) |
| 09:49:27 | | Quit kugel__ (Changing host) |
| 09:49:27 | | Join kugel__ [0] (~kugel@rockbox/developer/kugel) |
| 09:51:00 | | Join edhelas [0] (~edhelas@193.172.124.224) |
| 10:00 |
| 10:14:37 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 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:58 | kugel | sobukus: depending on the range of numbers you need, fixed point math can be more accurate |
| 10:46:30 | kugel | however you need to chose the fractional bits wisely |
| 10:51:32 | kugel | 0.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:05 | kugel | you 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:00 |
| 11:20:21 | | Part XavierGr |
| 11:23:29 | sobukus | kugel: 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:55 | sobukus | Actually, 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:24 | sobukus | 10 ms after 64 beats with a timer resolution of about 1.5 ms is not that bad. |
| 11:46:32 | sobukus | it 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] (~papier@titanium.v6.sdv.fr) |
| 12:00 |
| 12:28:36 | | Quit einhirn (Ping timeout: 245 seconds) |
| 12:32:50 | | Join xorly [0] (~xorly@m180.dkm.cz) |
| 12:37:12 | *** | Saving seen data "./dancer.seen" |
| 12:57:01 | | Join lorenzo92 [0] (~chatzilla@host24-106-dynamic.117-80-r.retail.telecomitalia.it) |
| 13:00 |
| 13:21:26 | | Join AlexP [0] (~alex@rockbox/staff/AlexP) |
| 13:26:25 | sobukus | This 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:17 | sobukus | I get 5 ms difference in 16 s playing time ... is that reasonable as combined time drift from Sansa and Laptop clock drift? |
| 13:28:27 | sobukus | This would mean something along 48015 Hz instead of 48000 Hz audio clock. Is reality that bad? |
| 13:38:47 | sobukus | Hm, I read that this might well be. |
| 13:38:59 | sobukus | And that this might even not be a bad value. |
| 13:42:32 | gevaerts | You can probably work out the expected drift from the PLL settings |
| 13:43:43 | sobukus | I'm eliminating the pc sound card now and am comparing the pre-created PCM and the metronome playback both from the Clip+. |
| 13:45:21 | sobukus | There, 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:55 | sobukus | I wonder why high timer resolution results in drift so quickly. |
| 13:46:20 | sobukus | If the callback is triggered from an interrupt ... the interrupt itself is lagging behind?! |
| 13:47:54 | sobukus | Should timing be worse with 1 ms intervals when compared to 10 ms? |
| 13:57:01 | sobukus | gevaerts: 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:42 | sobukus | I am seriuously wondering how I should determin a good timer interval. It seems to detoriate massively if it is too high. |
| 13:58:02 | sobukus | But 20 ms random error, even if it evens out in the mean, is jerky. |
| 14:00 |
| 14:03:24 | sobukus | So 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:26 | sobukus | With 1 ms timer, the overall drift over 32 beats @ 120 bpm is 40 ms ... 119.7 bpm instead of 120. |
| 14:06:29 | sobukus | It's 10 ms with 1.5 ms timer interval. |
| 14:06:59 | sobukus | Same with 13 ms timer interval and rounding compensation, but that sounds jumpy., |
| 14:07:30 | gevaerts | I'm not a musician, but a low drift seems acceptable to me. The jitter sounds a lot more annoying |
| 14:09:51 | maraz | 119.7 instead of 120 is unacceptable for doing any serious work. |
| 14:10:11 | maraz | I guess nobody would use a rockbox metronome for recording, though. |
| 14:10:35 | sobukus | maraz: Well, I guess 119.7 would be no issue for live performance. |
| 14:10:51 | sobukus | For recording, you have to get the metronome from the same clock that does the recording, no way around that. |
| 14:10:59 | maraz | if everyone syncs to it, fine |
| 14:11:05 | sobukus | Yes. |
| 14:12:05 | sobukus | I 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:37 | sobukus | maraz: 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] (~Miranda@bsod.rz.tu-clausthal.de) |
| 14:15:42 | sobukus | In 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:22 | sobukus | But 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:15 | gevaerts | sobukus: are you using the old method of having the interrupt handler set a flag? |
| 14:22:30 | gevaerts | Because then if you go (far?) under 10ms, you might start noticing interference between the scheduler tick and your timer |
| 14:22:50 | gevaerts | Well, for some values of interference that technically aren't interference but something else :) |
| 14:26:36 | sobukus | gevaerts: Oh, interesting. Given that the metronome originally was written in 2004, I assume it uses any old method there is. |
| 14:26:55 | sobukus | rb->timer_register(1, NULL, TIMER_FREQ/timerfreq_div, timer_callback IF_COP(, CPU)); |
| 14:28:13 | sobukus | Doesn't look flaggy ... is this the current way? |
| 14:32:07 | gevaerts | sobukus: but what does timer_callback() do? |
| 14:32:08 | sobukus | gevaerts: 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:42 | sobukus | gevaerts: It counts how often it is called and triggers action after a certain number of calls. |
| 14:34:10 | gevaerts | sobukus: it still does the need_to_play = true; |
| 14:35:34 | gevaerts | And 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:44 | sobukus | Hm. That's the SWCODEC difference ... |
| 14:36:07 | sobukus | Oh, right, that's nasty. but Should it introduce drift? |
| 14:36:21 | gevaerts | long-term drift, I shouldn't think so |
| 14:36:28 | gevaerts | Short-term jitter, sure |
| 14:36:35 | sobukus | But it explains why 10 ms offset is about the best I get. |
| 14:36:46 | gevaerts | Unless you somehow compensate... |
| 14:37:10 | sobukus | So, is there a way to trigger playback from the timer callback? |
| 14:37:14 | sobukus | with SWCODEC? |
| 14:37:15 | *** | No seen item changed, no save performed. |
| 14:37:37 | gevaerts | I don't think so |
| 14:38:45 | gevaerts | One 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:08 | sobukus | Do 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:17 | gevaerts | You'd add 10ms latency to the entire thing that way, but I don't really see an issue with that |
| 14:40:34 | sobukus | One issue there is: display indication and sound would be subtly out of sync |
| 14:40:50 | gevaerts | 10ms is too low for that to be visible I think |
| 14:41:09 | gevaerts | But if not, you could compensate the display bit too :) |
| 14:41:29 | sobukus | I don't see how. |
| 14:41:44 | sobukus | With the sound, I can stuff in PCM samples in sample-accurate fashion. |
| 14:42:22 | gevaerts | By the way, I'm not convinced that draw_display() from the timer callback is safe |
| 14:43:07 | lorenzo92 | indeed, it adds delay, considerably I guess |
| 14:43:08 | pamaury | I think it's quite unsafe because timer callbacks may be called in interrupt context |
| 14:43:20 | lorenzo92 | definitely |
| 14:44:08 | sobukus | I can understand that ... does that also apply for HWCODEC? |
| 14:44:17 | sobukus | Since there, playing MP3 from the timer is OK. |
| 14:45:51 | lorenzo92 | it depends on the operation, refreshing a display takes some time, especially on targets without DMA |
| 14:46:34 | sobukus | lorenzo92: 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:17 | gevaerts | If it causes you to miss a tick every now and then, maybe? |
| 14:47:47 | sobukus | So 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:55 | sobukus | Then I understand it well. |
| 14:48:53 | gevaerts | Yes. For timers, the only thing between your callback and the hardware is a thin abstraction layer to present a unified API |
| 14:49:50 | sobukus | Then I'm surprised it worked so well so far! ;-) |
| 14:50:11 | lorenzo92 | sobukus: yes, it might add delay. To be honest it depends on the implementation details, but definitely yes |
| 14:50:21 | sobukus | I should get rid of the drift, but will have the scheduler interval messing with steadyness. |
| 14:50:33 | sobukus | Thanks for clearing that up. |
| 14:50:46 | lorenzo92 | np ;) let us know |
| 14:56:36 | | Join tory [0] (981a1ad5@gateway/web/freenode/ip.152.26.26.213) |
| 14:56:36 | sobukus | OK, with 1000 timerdiv, it's down to 16 ms instead of 32 ms over 16 s. |
| 14:56:46 | sobukus | After removing the display clearing in the callback. |
| 14:57:01 | sobukus | OK, 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:00 |
| 15:01:13 | sobukus | lorenzo92: no effect with 500 division, still around 10 ms drift over 16 s |
| 15:01:41 | sobukus | And it's really accumulating drift, it's 5 ms after 8 s. |
| 15:02:06 | sobukus | The main loop doesn't seem to introduce much timing error. |
| 15:02:22 | sobukus | Or ... perhaps it does and I see the drift go down after some time. |
| 15:04:26 | kugel | timers are usually independant of how long the ISR runs |
| 15:04:57 | kugel | so heavy could shouldn't cause problem as long as it fits within a cycle |
| 15:05:13 | kugel | drawing to the display is still not safe from the callback |
| 15:07:15 | | Quit tory (Ping timeout: 246 seconds) |
| 15:13:24 | sobukus | Well, also without the drawing, I confirm that I have a continued drift. I have 50 ms difference after 70 seconds. |
| 15:17:25 | gevaerts | Drift compared to what? Wall clock, or DAC sample clock? |
| 15:17:28 | gevaerts | Or both? |
| 15:18:59 | sobukus | Drift compared to playing a generated PCM file (WAV) from the Sansa. |
| 15:19:31 | sobukus | gevaerts: I'm assuming that I should not get drift relative to the Sansa's own audio clock. |
| 15:20:42 | gevaerts | I'm not sure |
| 15:21:18 | gevaerts | You're assuming 44100 (or 48000 maybe) samples per local clock second, I assume? |
| 15:22:47 | sobukus | i'm not assuming anything there. |
| 15:23:13 | sobukus | 1. I play the WAV file on the Sansa (happens to be 48000 kHz), record on laptop with 48 kHz |
| 15:23:32 | sobukus | 2. I play metronome (happens to be at 44.1 kHz ...), record on laptop with 48 kHz |
| 15:23:48 | sobukus | If the sansa clock is really bad at 44.1 kHz, that would explain it, too. |
| 15:24:11 | gevaerts | http://git.rockbox.org/?p=rockbox.git;a=commit;h=b73d15e9c6175ac48b2280b089a40f0554d15d6f is the most recent thing I find |
| 15:24:18 | sobukus | Is there a relation between timer and rb->pcm_set_frequency(SAMPR_44); |
| 15:24:19 | sobukus | ? |
| 15:24:44 | sobukus | Wow. 1.1 % was it? |
| 15:24:53 | gevaerts | So at 44.1kHz I'd expect 0.04% error |
| 15:25:42 | gevaerts | i.e. 28ms for 70s |
| 15:26:00 | gevaerts | That's in the same order as what you're seeing |
| 15:26:05 | funman | I think this table is related: http://git.rockbox.org/?p=rockbox.git;a=blob;f=firmware/target/arm/as3525/pcm-as3525.c;h=eb22fc201630dfad184879f93fd5116b8cf27da6;hb=HEAD#l196 |
| 15:26:20 | sobukus | Hm, that matches the difference between the WAV file re-recorded from the sansa compared to the original WAV file. |
| 15:26:32 | sobukus | at 48 kHz |
| 15:27:00 | sobukus | 0.03 % error there |
| 15:29:28 | sobukus | So ... I'm trying what the metronome does when clocked at 48 KHz ... |
| 15:30:16 | gevaerts | These variations are going to be SoC-dependent of course |
| 15:30:43 | sobukus | What I'm aiming for is to be at as drifty as the audio clock, not more ... |
| 15:31:19 | * | gevaerts nods |
| 15:33:36 | funman | opinion on http://pastie.org/9816281 ? |
| 15:33:43 | sobukus | OK, I can confirm that the metronome still drifts compared to WAV playback when both are at 48 kHz. |
| 15:33:47 | funman | here is the gcc output: http://pastie.org/9816284 |
| 15:34:27 | gevaerts | sobukus: did you set playback to 48kHz, or did it resample? |
| 15:35:21 | gevaerts | funman: looks correct at first sight |
| 15:36:15 | funman | gevaerts: should I submit it to gerrit for review? |
| 15:38:25 | sobukus | gevaerts: I just did rb->pcm_set_frequency(SAMPR_48); , playing the pcm sound at a slightly higher pitch |
| 15:40:25 | sobukus | Is there experience with possible long-term drift of timers with other applications? |
| 15:45:30 | gevaerts | funman: maybe for a day or so |
| 15:45:37 | gevaerts | Not too long, if you need it :) |
| 15:46:19 | sobukus | http://www.rockbox.org/tracker/10906 <−− the PLL discussion ... is it now the case that there is a different PLL used for CPU than for audio? |
| 15:47:44 | sobukus | Am I seeing drift between PLLA and PLLB? |
| 15:47:50 | gevaerts | sobukus: I'd recommend asking bertrik about this later today |
| 15:47:59 | gevaerts | He probably knows |
| 15:48:14 | gevaerts | Although I suspect funman might also know some of this :) |
| 15:48:38 | funman | sobukus: which player is it? |
| 15:49:46 | sobukus | Sansa Clip+ |
| 15:50:13 | sobukus | /* on AMSv2 we can enable PLLB for MCLK to increase PCM sample rate accuracy */ <−− that seems to apply here |
| 15:50:51 | funman | yes |
| 15:51:57 | sobukus | I see 0.07 % difference in runtime ... that would match PLLA vs. PLLB, I presume. |
| 15:53:25 | sobukus | _plus_ additional drift from choosing too small timer intervals |
| 15:55:34 | sobukus | Is the scheduler interval always around 10 ms? |
| 15:55:37 | funman | g#1123 |
| 15:56:30 | sobukus | If 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:00 |
| 16:04:28 | | Quit edhelas (Quit: Quitte) |
| 16:10:30 | sobukus | gevaerts: I can sleep for some milliseconds (or fractions of) using rb->sleep()? |
| 16:10:36 | * | sobukus looking for the definition of HZ |
| 16:10:49 | gevaerts | Bo |
| 16:10:50 | gevaerts | No |
| 16:10:59 | sobukus | What's the resolution of that one? |
| 16:11:40 | gevaerts | 10ms, assuming no other active threads |
| 16:12:10 | sobukus | OK. So meaningless for syncing display to an audio shift < 10 ms. |
| 16:12:54 | sobukus | Well, 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:23 | sobukus | The tick sound itself is about 36 ms long ... |
| 16:13:35 | | Quit JanC (Read error: Connection reset by peer) |
| 16:14:01 | sobukus | 14:38 < gevaerts> One thing that might be possible is to introduce between 0 and 10ms of silence |
| 16:14:11 | sobukus | ^^ regarding that ... I guess it wouldn't be worth it |
| 16:15:15 | sobukus | If 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:32 | gevaerts | I don't know. I have no idea how noticeable that is for a trained musician |
| 16:15:33 | sobukus | To the limit the hardware allows, apparently;-) |
| 16:16:13 | sobukus | gevaerts: Is there a minimal time delay rb->yield() will introduce or does that totally depend on the situation on the device? |
| 16:16:50 | gevaerts | I wouldn't assume too much about that |
| 16:17:10 | sobukus | So, I wouldn't even know what maximum time to compensate for with delaying audio. |
| 16:17:15 | gevaerts | You'll be pushed to the next tick, but depending on other things that might be very soon |
| 16:18:09 | pamaury | gevaerts: 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:13 | fs-bluebot | Gerrit review #1098 at http://gerrit.rockbox.org/r/1098 : usb: make usb_release_exclusive_storage private by Amaury Pouly |
| 16:18:26 | gevaerts | pamaury: go ahead |
| 16:22:21 | funman | why was my g#1123 not picked up by fs-bluebot ? |
| 16:25:44 | pamaury | gevaerts: who is admit on gerrit ? |
| 16:26:36 | gevaerts | pamaury: people->list groups->administrators :) |
| 16:27:27 | pamaury | damn, is any of them on the channel ? |
| 16:28:06 | pamaury | nope :( |
| 16:28:11 | gevaerts | You can always try hunting for them in other channels |
| 16:29:46 | | Join JanC [0] (~janc@lugwv/member/JanC) |
| 16:31:10 | pamaury | I'm sent an email |
| 16:32:31 | | Join saratoga [0] (123e11e0@gateway/web/freenode/ip.18.62.17.224) |
| 16:32:56 | saratoga | sobukus: we're probably going to switch the AMSv2 PLLs to use the A for both audio and CPU (that includes the Clip+) |
| 16:33:09 | saratoga | after that you won't see drift between the audio and timer clocks most likely |
| 16:33:19 | saratoga | since they'll be phase locked |
| 16:33:33 | sobukus | saratoga: But isn't then the accuracy of the audio frequency bad again? |
| 16:33:34 | sobukus | Or do you mean PLL B? |
| 16:33:35 | saratoga | although you will still see the constant pitch error due to PLL dividers |
| 16:33:53 | saratoga | no, we're going to run the CPU off the frequency the audio needs |
| 16:34:39 | saratoga | the 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:48 | sobukus | OK, sorry for being thick: How will the audio freq. error be in the new setup? 0.04 % or 0.14 % ... ? |
| 16:34:49 | sobukus | Or better? |
| 16:34:57 | saratoga | so the CPU and audio ended up needing two slightly different clocks, hence two PLLs were used |
| 16:35:06 | saratoga | the audio frequency won't change at all |
| 16:35:22 | saratoga | but the CPU frequency will change to be related to the audio frequency by a rational number |
| 16:35:43 | saratoga | to within some small number of picoseconds |
| 16:35:48 | sobukus | Ah. That sounds nice. |
| 16:36:22 | sobukus | So we're back to one PLL, improving battery life, even? |
| 16:36:37 | saratoga | yeah |
| 16:36:40 | saratoga | see http://gerrit.rockbox.org/r/#/c/1062/ |
| 16:37:16 | *** | Saving seen data "./dancer.seen" |
| 16:38:01 | sobukus | "clip+ show abnormally high battery runtime after changing it," I like that phrase;-) |
| 16:38:34 | sobukus | That patch sounds like a win-win-win situation, if the too-low voltage stuff is sorted out! |
| 16:39:33 | | Join amayer [0] (~amayer@mail.weberadvertising.com) |
| 16:39:38 | saratoga | yeah it needs a bit of work, especially on the fuzev1 |
| 16:39:40 | saratoga | err v2 |
| 16:40:04 | sobukus | I guess Rockbox is a major reason why the Sansa Clips are still selling,. |
| 16:40:34 | sobukus | I was amazed to still find the Clip+ in stores last year. And it still rocks ... thanks to Rockbox! |
| 16:43:14 | saratoga | its 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:14 | funman | saratoga: do you remember what is as3515? #define AS3515_USB_UTIL 0x17 /* only in as3515 */ |
| 16:45:29 | saratoga | type for as3517? |
| 16:45:34 | saratoga | typo |
| 16:45:39 | saratoga | oh |
| 16:45:45 | saratoga | or was it 15 |
| 16:46:02 | funman | b9beeccbcf34ce08a191c22b2970475053938b27 |
| 16:46:32 | funman | seems amsv1 only though |
| 16:46:39 | funman | so probably not interesting |
| 16:47:08 | saratoga | ah 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:29 | lorenzo92 | stash@{1}: WIP on master: bce72e6 buflib: Switch from term "cookie" to "metadata" |
| 16:52:31 | lorenzo92 | stash@{2}: WIP on master: 812406f Limit "struct dircache_runinfo" to file scope |
| 16:52:35 | lorenzo92 | is that supposed to be there? |
| 16:55:20 | lorenzo92 | hmm I'm now unsure if stashes are always local only ^^ |
| 16:56:28 | funman | lorenzo92: yes, local only |
| 16:56:50 | lorenzo92 | thanks, then I simply don't remember about what I did :P |
| 17:00 |
| 17:03:34 | | Join N0Lif3 [0] (~IceChat9@c-76-125-38-243.hsd1.ca.comcast.net) |
| 17:09:40 | | Join edhelas [0] (~edhelas@193.172.124.224) |
| 17:11:12 | | Join pystar89 [0] (~pystar89@ip-178-203-30-225.hsi10.unitymediagroup.de) |
| 17:19:13 | | Join tory [0] (981a1ad5@gateway/web/freenode/ip.152.26.26.213) |
| 17:22:08 | | Quit amayer (Quit: Leaving) |
| 17:27:08 | | Quit petur (Quit: Page closed) |
| 17:27:46 | | Join amayer [0] (~amayer@mail.weberadvertising.com) |
| 17:29:25 | N0Lif3 | I 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:23 | N0Lif3 | They're Skullcandy Titan earbuds, I tried googling "skullcandy titan rockbox" and don't see a relevant answer |
| 17:32:25 | gevaerts | I 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] (~Strife89@adsl-98-80-237-4.mcn.bellsouth.net) |
| 17:34:28 | | Quit foolsh (Ping timeout: 265 seconds) |
| 17:36:09 | N0Lif3 | I'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:29 | tory | RB does that too ;) |
| 17:36:36 | | Quit tory (Quit: Page closed) |
| 17:38:36 | gevaerts | Not on all devices... |
| 17:41:18 | lorenzo92 | actually, 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:07 | lorenzo92 | so, 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:11 | lorenzo92 | NOLif3: definitely, a simple present / not present is handled by a single GPIO |
| 17:44:11 | lorenzo92 | to 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:28 | saratoga | the sandisk devices don't have any logic for communicating or detecting headphones |
| 17:46:49 | saratoga | except 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:22 | lorenzo92 | saratoga: that sounds strange. insertion only? hmm |
| 17:48:36 | saratoga | yeah beats me |
| 17:48:43 | saratoga | its what the docs say |
| 17:49:25 | lorenzo92 | interesting |
| 17:50:30 | lorenzo92 | perhaps they are using the GPIO that is offered by wmcodec, and it does not interrupt for the removal, who knows ;) |
| 17:51:05 | saratoga | its handled by the DAC chip directly, for whatever reason it can only generate an interrupt on insert IIRC |
| 17:51:51 | | Join pamaury [0] (~quassel@sphinx.lix.polytechnique.fr) |
| 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] (~rastlin@c-98-226-52-99.hsd1.in.comcast.net) |
| 17:54:27 | lorenzo92 | saratoga: right, was wondering the same |
| 18:00 |
| 18:00:52 | N0Lif3 | surely 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:21 | N0Lif3 | and 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] (~rastlin@c-98-226-52-99.hsd1.in.comcast.net) |
| 18:11:40 | | Join ZincAlloy [0] (~Adium@pD9EE961D.dip0.t-ipconnect.de) |
| 18:12:12 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 18:12:37 | lorenzo92 | NOLif3: erhm, if the hardware support is missing, then no |
| 18:14:07 | lorenzo92 | (if I correctly get the question) |
| 18:21:38 | | Quit Strife89 (Ping timeout: 264 seconds) |
| 18:23:34 | | Join edhelas [0] (~edhelas@77-173-17-40.ip.telfort.nl) |
| 18:26:05 | | Join desowin [0] (~desowin@dynamic-62-87-191-105.ssp.dialog.net.pl) |
| 18:30:30 | | Quit edhelas (Quit: Quitte) |
| 18:30:50 | | Join edhelas [0] (~edhelas@77-173-17-40.ip.telfort.nl) |
| 18:31:16 | | Quit edhelas (Remote host closed the connection) |
| 18:31:20 | | Join edhelas_ [0] (~edhelas@77-173-17-40.ip.telfort.nl) |
| 18:31:20 | | Quit edhelas_ (Client Quit) |
| 18:31:50 | | Join edhelas [0] (~edhelas@77-173-17-40.ip.telfort.nl) |
| 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:51 | saratoga | scorche: any idea if its safe to ban sleezy email hosts from "registering" rather then just banning them outright? |
| 18:41:04 | saratoga | i know if I ban *.host.com it bans existing users |
| 18:41:20 | saratoga | but if I just block them from registering that leaves existing users alone right? |
| 18:41:41 | | Join pmarty [0] (1f0b95e1@gateway/web/freenode/ip.31.11.149.225) |
| 18:48:34 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 18:48:44 | | Quit pmarty (Quit: Page closed) |
| 18:51:57 | | Join pmarty [0] (1f0b95e1@gateway/web/freenode/ip.31.11.149.225) |
| 18:54:10 | | Quit dfkt (Remote host closed the connection) |
| 18:55:27 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 18:57:03 | pmarty | Hello, 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:34 | pmarty | but 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:21 | pmarty | do I need to put some files on the filesystem? |
| 18:58:46 | * | sobukus doesn't know anyting 'bout ipods |
| 19:00 |
| 19:03:49 | pmarty | are ipods /that/ sensitive to mbr layout that you guys ship dedicated ones? http://www.rockbox.org/wiki/IpodConversionToFAT32 |
| 19:04:03 | gevaerts | I'm not entirely sure, but as far as I know nobody worked out an itunes-less way to restore the classic |
| 19:04:26 | gevaerts | pmarty: many partitioning tools make it hard to make a partition with type 0 |
| 19:08:47 | pmarty | yes, there might be some magic involved |
| 19:09:03 | pmarty | but 5g did restore by itself with an empty filesystem |
| 19:09:52 | gevaerts | Yes, 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] (~RiD@bl22-13-146.dsl.telepac.pt) |
| 19:31:05 | | Join krabador [0] (~krabador_@unaffiliated/krabador) |
| 19:37:07 | | Join lebellium [0] (~chatzilla@89-93-177-161.hfc.dyn.abo.bbox.fr) |
| 19:37:14 | scorche|sh | saratoga: that sounds like it would be safe enough - go ahead and test if you can |
| 19:38:53 | saratoga | can you check afterwards if existing users are banned ? |
| 19:38:59 | saratoga | i don't have access to taht |
| 19:41:10 | scorche|sh | i'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:37 | scorche|sh | ...can quickly see if an existing account you control is banned and see if you can register a new one |
| 19:41:42 | scorche|sh | or mailinator or something |
| 19:42:22 | scorche|sh | mailinator would likely be easier to try than gmail ;) |
| 19:44:37 | | Join AlexP [0] (~alex@rockbox/staff/AlexP) |
| 19:45:30 | saratoga | ok i'll try now |
| 19:51:12 | | Quit pmarty (Quit: Page closed) |
| 19:57:32 | saratoga | scorche|sh: yes it works as expected |
| 19:58:05 | saratoga | any 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:11 | saratoga | allowed |
| 19:58:28 | scorche|sh | potentially - i cant look at it at the moment though |
| 19:58:33 | saratoga | ok |
| 19:58:38 | scorche|sh | could you email me and then i can remember to look at that when i get home? |
| 19:58:54 | saratoga | i'd like to ban a few spammy web mail hosts but i'd hate to block out a legit user |
| 19:59:24 | saratoga | your gmail ok? |
| 20:00 |
| 20:00:07 | scorche|sh | yes |
| 20:01:22 | saratoga | done |
| 20:01:30 | | Join stoyan [0] (~io-headqu@82.196.0.237) |
| 20:02:00 | scorche|sh | thanks |
| 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] (~petur@78-21-48-202.access.telenet.be) |
| 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:00 |
| 21:02:43 | | Quit stoyan (Quit: ChatZilla 0.9.90.1-rdmsoft [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:00 |
| 22:15:47 | | Join ZincAlloy1 [0] (~Adium@pD9EE961D.dip0.t-ipconnect.de) |
| 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] (~Adium@pD9EE961D.dip0.t-ipconnect.de) |
| 22:55:06 | | Nick dfkt_ is now known as dfkt (dfkt@unaffiliated/dfkt) |
| 22:55:25 | | Join [Franklin] [0] (~franklin@cpe-071-071-039-006.triad.res.rr.com) |
| 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] (~Adium@pD9EE961D.dip0.t-ipconnect.de) |
| 22:58:40 | | Quit ZincAlloy1 (Ping timeout: 244 seconds) |
| 22:59:45 | | Quit dfkt (Ping timeout: 265 seconds) |
| 23:00 |
| 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] (~Adium@pD9EE961D.dip0.t-ipconnect.de) |
| 23:03:21 | | Quit ZincAlloy2 (Ping timeout: 240 seconds) |
| 23:06:36 | | Join ZincAlloy1 [0] (~Adium@pD9EE8D73.dip0.t-ipconnect.de) |
| 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] (~fs-bluebo@g224237190.adsl.alicedsl.de) |
| 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] (djao@efnet.math.uwaterloo.ca) |
| 23:23:48 | | Join Strife89 [0] (~Strife89@adsl-98-80-237-4.mcn.bellsouth.net) |
| 23:34:32 | [Franklin] | do I OR or add the drawmodes to mix them together? |
| 23:34:57 | [Franklin] | so DRMODE_BG + DRMODE_INVERSEVID or DRMODE_BG | DRMODE_INVERSEVID? |
| 23:39:30 | gevaerts | It 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:58 | gevaerts | So, or, and, xor, not, and not plus or minus |
| 23:40:10 | gevaerts | And definitely not * or / :) |
| 23:40:15 | [Franklin] | :D |
| 23:40:32 | [Franklin] | well, I got my scrolling road sim working :) |
| 23:40:41 | gevaerts | Same with bitshifting vs dividing/multiplying with powers of two |
| 23:41:20 | gevaerts | If you care about the bits, you use bit-oriented operators |
| 23:52:17 | | Quit lebellium (Quit: ChatZilla 0.9.91.1 [Firefox 35.0/20141229214612]) |
icon identifies that the person is a core developer (has commit access).