what's up with the metro timebase?

  • ok, so i know there's been a few thread about the relationship between Bees and Lines in terms of their timebase relationships, but i'm also scratching my head around the internal Bees system (and this might explain why I've had such a nightmare trying to get Bees and Lines to talk to each other nicely.

    If I set the Metro period to 1000 (or even 1024 as i think someone suggested somewhere)
    then it should be 1000ms between each tick right?
    Well it's really not... can someone else confirm this is not just on my unit (can't see why it would be)
    screenshot attached, this is STEP triggering the drumsyn on each step with a period of 1000 (top waveform) and 1024 (bottom waveform)


  • for METRO, it really is supposed to be literal milliseconds. so yeah, that's not what i expect to see at all!

    bees has a "heartbeat" timer that runs at 1000hz. METRO and similar just count the appropriate number of ticks. ultimately, this main 1khz timer is set up in the lowest-level avr32 initialization routine. the exact timing of it is a kludge.

    weirdly, it kind of looks like you're seeing a more "correct" behavior, where maybe the kludge is not necessary. i'm pasting it here; this is the end of the function init_tc() in aleph/avr32_lib/src/init.c:

    //------- ------------------

    // set timer compare trigger.
    // we want it to overflow and generate an interrupt every 1 ms
    // so (1 / fPBA / 128) * RC = 0.001
    // so RC = fPBA / 128 / 1000
    // tc_write_rc(tc, APP_TC_CHANNEL, (FPBA_HZ / 128000));
    ///// FIXME: kludge because the timing is slow somehow...
    ///// this constant is experimentally determined...
    tc_write_rc(tc, APP_TC_CHANNEL, (FPBA_HZ / 149707));

    //------- -----------------

    if you can, it would be a good exercise to change those lines to the should-have-been-correct, commented-out version. (on my prototype unit, the kludged form gives 1ms ticks within a clock cycle, that's why it's there. best i can do.)

    the number 1024 = 1s comes from a totally different context. that is the relationship between bees "control voltage," which is 16-bit signed integer, and timing parameters in aleph-lines. this is a totally arbitrary relationship that is currently simple and linear, but it's definitely a sub-optimal compromise: poor resolution, poor range, confusing.

  • ok!
    first i need to get my linux toolchain working!
    this maybe a total newbie dumb question but when it says in the readme "move/rename this directory however you like and make sure the binaries are in your $PATH" what does that mean?
    should I type this line as is
    echo "PATH="\$PATH:~/avr32-gnu-toolchain/bin" >> ~/.bashrc

    or am i supposed to replace $PATH with a pointer to the directory i've put the binaries in?

  • I did a test just assigning a metro tick to gate0 in drumsyn. period set to 1024. not sure how many milliseconds it actually is, but everything lines up nicely.

  • What do you mean lines up? Is it actually triggering at 1024ms intervals?

  • sorry I got confused! I thought you were show it drift out of time. looks like mine is the same as yours. about 0:00:0:8x in the live timeline.

  • @duncan_speakman:

    $PATH is a linux environment environment variable that tells linux where to find binaries.

    use a text editor and add
    (or whatever is the right location)
    to the end of your .bashrc.

    also make sure the atmel headers are installed correctly, or you will get a bunch of undefined errors on compilation.

    still curious if the unit i swapped with you behaves differently... that would be revealing and weird since it would indicate a discrepancy in the physical speed of the master clock, or maybe in the physical speed of some peripheral.

    since the too-slow clock is regular (right?) i tend to think that it's a miscalulation in the clock speed / timer count. if it was irregular that might indicate too much time taken somewhere else.

  • wait whoa... i just actually looked at the picture. METRO is putting out ticks every 0.7s with period=1000? this is nothing like any of my experiences.

  • ah, now i can't remember which unit i did the test with!! (when was your gig?) - i'm back home this weekend, i'll run another measurement

  • @duncan_speakman

    ok, i measured it with the proto i'm currently using for development. indeed, i get a similar discrepancy, though the numbers are different. i'm seeing a period ratio of 0.865 (observed / nominal.)

    i guess the kluge i described above is really wrong. we must have fixed something way back in development. or maybe it was never supposed to end up in the release firwamre in the first place. i honestly can't remember. apologies!

    the change i suggested above brings it much closer, to 0.987. this is the theoretically correct TC reload value, so maybe we should go with it, since my measurement method is surely not 100% accurate and there might be hardware variance. (!)

    thanks for keeping on me about this!

    attaching two builds, tagged by the TC reload value. ( well, it's really a divisor of the core clock, if you're going to run the numbers.)

    _128000 is the nominally correct one, which i'm observing to be just slightly fast.

    _126336 is what i observe to be most accurate - within 1sample per 4s, and i'm not set up at the moment to take more accurate measurements. i'm provisionally putting this in the dev branch.

    please, anyone: let me know what you observe on running these.

  • thanks for the tweaking! I'll load these up today and let you know results

  • hi all

    i thought i should probably add some more figures/images here for comparing.

    using dysn with a metro running straight into the gate, i get similar results to @zebra (around 0.85) with the metro set at 1000ms.

    I've also attached a zoomed image of the waveforms that appears to show the timing being a bit out when running the metro at 1000ms, compared with 2000ms (whether its of any use or not?).

    @zebra if i can work out what to do with the files you've attached i'll test and report back as well, but i expect duncan will beat me to it.


  • ah sorry, it's going to have to be tomorrow or wednesday for me now, totally snowed under

  • ok, figured out what to do with the files and have tested.

    126336 seems to be the most accurate of the two files (0.992ms with metro at 1000ms).

    128000 runs a little slower (0.980 with metro at 1000ms).

    images attached to show the results.

    949 x 510 - 54K
    1162 x 519 - 62K
    1240 x 571 - 62K
    1279 x 582 - 68K
  • ok, thanks! so that's still 10ms off.

    btw, i'm measuring it like so: metro toggles o/c amplitude of single high-pitched (~2khz) oscillator in waves, with amplitude slew set to 0. i'm cutting the beginning of the "note" to the closest sample to the first zero-crossing in the resultant waveform.

    doing this i get within 1sample over 4s, so not quite what you're seeing. i'll check it again. it's just a question of tuning that divisor amount to something that everyone is most happy with.

  • out of curiosity I've just tried what I'm guessing your method is/was, which gives a long note followed by equal silence?
    (toggling on/off osc0_dac0 in waves, reduced slews to 0 with a ~2khz oscillator, metro period at 1000).

    for me, this produces a note length of roughly 0.973ms, which appears to be slower than when i test with dsyn, strangely.

    heres another image to show the difference. the top waveform is from dsyn, the lower one is waves.

    thanks for looking into this zebra.

    1663 x 1012 - 124K
  • ugh, that is super strange...

    you mean to say that the metro is faster with waves, since the period is shorter, right?

    i realized last night that it's dumb to cut to zero-crossings since the osc isn't reset on "note on." derp, sorry

    i gotta do other things but will continue to ponder this. there has to be an explanation.

    one thing i'll do is add some statements to count the number of processor cycles between metro callbacks. maybe there is jitter for some reason.

    there could also conceivably be observed jitter in the time of DSP repsonse to param chnages. this would be measured in frames though, not milliseconds; probably < 1frame. consider: the modules have different DSP loads. the param change won't be processed until audio frame processing is done. what really happens is that the param change isn't even sent until DSP signals it's ready for one (frame complete, idling.) it's all a little ad-hoc and i do want to get in there and rework it.

    in the meantime i'll slow the whole show down a little more on avr32 if that seems appropriate.

    i'm curious if anyone with a monome modular is seeing similar results. in those, the timer code is essentially identical, but of course the work they're doing on refresh is different (and simpler.)

  • i've scoped the timing of the modules during development and they're right on-- but keep in mind that it's not the same chip and runs actually slower than the aleph AVR32.

    perhaps we should try a test in mix, to reduce complexity.

  • System complexity is same. Best baseline measurement would be setting tc callback to flip gpio on 1ms interval in aleph/utils/avr32_blank, watch on scope. If this seems measurably different from behavior using lib+app framework... Then something else is up with delay propagated from inter-CPU comms.