Possible bug example patch, using nonRealTime and sfRecord~


    Mar 19 2007 | 3:21 pm
    Hi again!
    Hopefully now someone will recognize this, so that I may be able to get around this problem and continue work on my project...
    I had previously posted about a problem I've found, that may be a bug. I have now managed to recreate it in as simple a patch as possible, and so I paste it below. Attached to this post you will also find two zipped wav's to illustrate the phenomenon.
    What I noticed was that, when trying to record the audio output of attached patch using the nonRealTime audio driver and sfRecord~, the audio output was considerably faster than when compared to that of using a real-time driver, such as mme. Even stranger, the speed-up is inversely related to the “Signal Vector Size” parameter of the DSP Status window, when using the nonRealTime driver.
    So the smaller the signal vector size, the greater the speed-up. Also note that the speed up is not simply like when playing back an audio file faster, where the pitch also goes up. In this case, pitch stays constant.
    When creating the example patch to illustrate this phenomenon, I narrowed it down to identifying the object causing it, as the “jit.3m”. When bypassing it, the audio output in nonrealtime mode is in the correct speed, independently of what value the signal vector size is set to. Unfortunately, in the actual patch that I first observed this issue, I cannot see any way of achieving the same results without using the jit.3m object.
    Instructions for recreating phenomenon using example patch:
    1. Make sure the “track2.mov” file from the jitter tutorials is in the same folder as the patch, or drop it in the drop region. Then start the metro to get video playback. It will work with any movie, but this is the one I used.
    2. After listening to the output using the real-time audio driver, switch to the NonRealTime driver in the DSP Status window, also setting the signal vector size to something small, like 32 or 64, so that the speed up is considerable.
    3. Make sure the drop down in the middle is set to its default value, “Directly”.
    4. Make sure audio output is enabled, then click on the “open” message connected to the sfRecord~ object, enter a filename, and then click the toggle next to it to start recording; click it again after a minute or two to stop, and listen to the output. You will notice the speed up I mentioned.
    5. If you want to verify that this is somehow caused by the jit.3m, select the drop-down option “through counter”. Now the (different) audio output in non real-time mode is in the correct speed compare to when in real time.
    Is this a bug, or is there something I’ve done wrong that you know of?
    Thanks,
    Ilias B.
    Example patch:
    --------------------------------------
    max v2;
    --------------------------------------
    Hope you can help!
    Thanks,
    Ilias B.

    • Mar 20 2007 | 10:20 pm
      On 19.03.2007, at 16:21, Ilias Bergstrom wrote:
      > Is this a bug, or is there something I’ve done wrong that you
      > know of?
      Hi Ilias,
      its not a bug. What happens is you have 3 timing sources in your patch:
      MSP running steady at you sample rate, metro outputting a bang every
      time the scheduler thinks 40 ms have passed, and quicktime, playing the
      movie all by itself, unaware of you current audio driver. Even if metro
      and the audio clock sync with interupt on in nonrealtime (no idea, but
      I wouldn't rely on it), quicktime still plays by itself, the bang only
      lets jit.qt.mov output the current frame.
      What you want to do is follow the illustrated wisdom of maoist jitter
      minister of information nesa:
      http://jit.playground.googlepages.com/onemetro.jpg
      Use one source for timing, in this case train~, as you want to sync to
      MSP, and use it to count through the movie frames "manually". See
      patch.
      And please don't make so many new threads, it's confusing me ;)
      Good luck, g.
      PS: See how posting a patch helps, Stefan? ;P
      max v2;
    • Mar 20 2007 | 10:33 pm
      grg,
      Wow!
      Clearly you went through a lot of effort to debug my patch, thank you for that!
      To show that my computer science degree is just the first step towards understanding computers :)
      Even better you even explain why it happens, and reading it now it makes perfect sense.
      The reason for the multiple posting was partly because I couldn't rename my older posts, I'll make sure I give them a good name from the start next time :)
      Regards,
      Ilias B.
    • Mar 21 2007 | 12:23 pm
      grg,
      I have to thank you once more :)
      I transferred your example to my "real" project, and it works like a charm!
      I especially like the clever, sample accurate record start & stop timing that you set up :P
      Greetings,
      Ilias B.