Possible bug example patch, using nonRealTime and sfRecord~ and jit.3m

Mar 20, 2007 at 5:03pm

Possible bug example patch, using nonRealTime and sfRecord~ and jit.3m

Greetings!

Note that I’ve also posted this in the Max/MSP forum. I wasn’t sure which would be most relevant, so I chose to bost in both.

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;
#N vpatcher 385 40 1190 952;
#P origin 19 -163;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P message 278 282 18 9109513 16;
#P message 27 366 14 9109513 2;
#P number 27 423 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P user umenu 27 396 100 9109543 1 64 412 1;
#X add silent;
#X add through counter;
#X add directly;
#P newex 130 464 42 9109513 switch 2;
#P newex 85 118 62 9109513 prepend read;
#P newex 278 441 37 9109513 / 200.;
#P slider 278 303 15 128 0 1;
#P newex 130 489 27 9109513 * 5;
#P window setfont “Proportional Serif” 10.;
#P comment 136 511 55 9175050 Frequency;
#P window setfont “Fixedwidth Serif” 10.;
#P newex 130 553 80 9240586 cycle~ 1000.;
#P flonum 130 525 62 10 0 0 0 141 0 0 0 221 221 221 222 222 222 0 0 0;
#P window setfont “Sans Serif” 9.;
#P newex 222 431 27 9109513 + 55;
#N counter 0 55 75;
#X flags 0 0;
#P newobj 146 431 73 9109513 counter 0 55 75;
#P newex 190 364 70 9109513 unpack 0 0 0 0;
#P newex 176 340 53 9109513 jit.3m;
#P number 210 394 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 53 590 15 0;
#P message 72 590 28 9109513 open;
#P window setfont “Fixedwidth Serif” 10.;
#P newex 53 658 74 9240586 sfrecord~ 1;
#B color 5;
#P user ezdac~ 138 690 182 723 0;
#P window setfont “Sans Serif” 9.;
#P newex 148 594 38 9109513 *~ 0.05;
#P window setfont “Fixedwidth Serif” 10.;
#P newex 90 150 53 9240586 loadbang;
#P user jit.pwindow 19 249 82 62 0 1 0 0 1 0;
#P window setfont “Sans Serif” 9.;
#P newex 14 49 45 9109513 metro 40;
#P toggle 14 28 15 0;
#P window setfont “Fixedwidth Serif” 10.;
#P newex 20 228 80 9240586 jit.qt.movie;
#P window setfont “Sans Serif” 9.;
#P message 57 197 77 9109513 read track2.mov;
#P user dropfile 85 45 141 105 0;
#P user panel 83 43 61 66;
#X brgb 191 191 191;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P comment 83 27 100 9109513 Drop region for files;
#P window linecount 34;
#P comment 318 50 236 9109513 Instructions for recreating phenomenon: 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.;
#P connect 6 0 7 0;
#P fasten 7 0 5 0 19 220 25 220;
#P fasten 26 0 5 0 90 141 25 141;
#P fasten 4 0 5 0 62 220 25 220;
#P connect 5 0 8 0;
#P fasten 9 0 30 0 95 193 137 193 137 351 32 351;
#P connect 30 0 28 0;
#P connect 28 0 29 0;
#P fasten 10 0 12 0 153 636 113 636 113 650 58 650;
#P connect 14 0 12 0;
#P connect 13 0 12 0;
#P fasten 9 0 4 0 95 179 62 179;
#P connect 3 0 26 0;
#P fasten 29 0 27 0 32 451 135 451;
#P connect 27 0 23 0;
#P connect 23 0 20 0;
#P connect 20 0 21 0;
#P fasten 10 0 11 0 153 651 143 651;
#P connect 15 0 18 0;
#P connect 18 0 27 1;
#P connect 21 0 10 0;
#P fasten 19 0 27 2 227 457 167 457;
#P fasten 10 0 11 1 153 651 177 651;
#P fasten 8 0 16 0 25 335 181 335;
#P fasten 25 0 10 1 283 582 181 582;
#P connect 16 1 17 0;
#P connect 17 1 15 0;
#P connect 15 0 19 0;
#P fasten 9 0 31 0 95 185 283 185;
#P connect 31 0 24 0;
#P connect 24 0 25 0;
#P pop;

————————————–

Hope you can help!

Thanks,
Ilias B.

#30936

You must be logged in to reply to this topic.