< Back to IRCAM Forum

Mubu.record~ stops after a while with large buffers. Bug?

MuBu
#1

Hi all,

First of all: Happy New Year!!!

I tried to track an issue down, that has bothered me for some time, where after I would walk away from my setup for a while, it stopped working. I use a fairly large MuBu buffer (1800 - 3600 seconds) and while audio kept working just fine, mubu.record stopped after a (non-fixed) time. I loop the recording and the issue might not show up for a few hours as well.

I tried to see if there were some hidden messages entering my tracks but that was not the case. What I do see is that the recording first becomes erratic and then it stops altogether. Sometimes it also spontaneously starts again. I recorded the intervals that were not equal to the vector length (256 samples at 44.1 khz or 5.8 ms), the first indication of an impending stop and the attached file is what I get before the recording stops altogether. There are a few stops in the file. Sometimes the recording started spontaneously again.

Stopping and starting the audio mostly helps, but not always it seems. I also see that it restarts sometimes spontaneously. What always seems to work is creating a new audio object or connecting/disconnecting a totally unrelated audio object, (the noise~ to *~ audio connection in the example works for example) that can even be in a different patcher.

A small test patch that I created experienced the same issue as the mubu.record~ in my main patch. Both the test patch and the main patch experience the issue at about (but not exactly) the same time and when starting one of them again through one of the above methods, both mubu.record~ objects (in unrelated patches) restart or stop erratic behaviour.

So I used this knowledge to make a workaround for the issue (see attached patch). It is probably not the most elegant way to do it, but it works. Still though this seems to be a MuBu bug?

Best, Hans.

Using MAX 8.1.5 (is updating already possible?)
MacOSX 10.14.6
Macbrook pro 2019 8-core

MUBU_tracking data for Forumnet.rtf (75.3 KB)
MuBu


----------begin_max5_patcher----------
1787.3oc6Ys0aaaCE9YmeEDt6oAWCdUW1dIsX.ECXcXC6g8PQQ.sMsqZjkDj
nxRWQ6u8wKR1xoxxzwToc.MAPRlhRmy24F+NTe7pISWjeunZJ3m.uALYxGuZ
xDyP5Alz76IS2xueYJuxLsoaEUU7Mhoyr2SJtWZFGEA0+Mu8FIqLCmu38OOJ
tcvr5sIYoBo4Ug2OXdsrcTTyn1gjenPX0toSAus4VEb4x2kjs4lRwRo8tHRv
b3L.NBpOEGa9AdND7V8i7oqtReXliPLS7OJ09KP3O949vFwGXqJYSFOcPDRH
LCnBs.MdNy+HrnLISB90JI+CuHM4NQe3E2KdQ8hW3wgCNlpwAkFpOEENFNrr
7jJQuNMzY.Be3zHwVvNFnrpPHVklrEfToe8.VF7oJ6iBwdvYtnVJyy5AHz3A
8ZE7R9VgTTdiHiuHUzM.zQPtfmswEfRZRBosG8p+DbqPTbr7OZnex+ZcYXyo
P3nDYJRAr4QPZ79U.5.EL8bhLwC5zlchHzvHieiYvY3nTs44fdW7CwP9H+ac
ZNW5BDQ3wa8AIXMXceXjbFAk3gg3L2wZyp8iCVWIVKJSy+m9xA8xxGCBPZf0
MFZNwFkENrq1ezBMP+TngYWNf.MmBPiARJGrjINh1KTf92eghM3KHZbVAjv9
puBXafIhMdq.JAKz+2mA3bXeRN0JFGb1EPSQ10LuHu6wZfpZYYRgDrRnTVAH
MYs307aEk8EPO98S0f3lrVDlMlP1FFnjMvD89Yv02wKyTgxCZEPAiuUHzvam
Prg4rQgkj7cIUFY2OJo9Xo0SxOp0eGPL0u5PPp4Yp3209xd1uqecGn1fo+r9
vy9S8QQ1J6Hds4av.av.5HVoQhiEl8EVIOlTnjVd4JvOf5AngidHuEg1EvXW
11nHy2rIs2EjG6UwT7ZbgpLd7VBaa8h54VO4mAIYE0xUbIWJpj.d8pj79HbM
nUYcdlrJ4eMHDoqCMT9udx55ml28KJS3oSezUFvDiwBAMMJhX1L.3WcyEN5a
S6U3Sk4RVxWdaeFKL35J91hTQoZP6PfqUuVs4vTEsBbcQoP0fC3Chp1WdZRl
x9WmI6Rc5fEhBubCN4QZvOkQmnXlEDCIA10HfPhpiPDwRdgE1xZ6fUyVcikz
wMborLQw41tO3S14JlL8NQ4h7JKjLCYbedzIdn6quhB3wuUyH5bJINHNrw1g
o5VqMlNDpWh.NX5DaWHV0ozsZj6U0zy3oqSREcU2Aq328la4EEewsKE1X8cu
0c2QqnapSNbrLdgNqvFjB2El9D3pOd95njtRHe6lshra.2t7Sz3jeZdaFC0C
9.WFURO9gdxp75xks.ocCmA6UpUJOVRFWln5Me+jzePjNSRsBlhPrNlq2vGW
EsgQ6oksVAQ9V15uNxoEMwNoKRRlc.tC.5WTstgKyfxbAUVE5RkEC5fnzKmd
wRxoHzGnN6hRPOAQnHxnHahKh13wQWZbCwgHzcAWWjnHXWBa7gjnNkKD6KLg
OElf9RRmzQE3CIwbv505Lur5iQtji0pOWlnboRRaJ+kkQE7TIIcKhmVR9QTN
HIeTvOzkD2nwnlqKRldZpPVRYJl7JtaUMOsQlJhzuO2L8nYleljY+ogxphm+
cIsymYFgWp3UJUDDqKsLSuOvtEJS2lqDblk5uBzJzpDYk7CoOjH3dRsZV2+k
hTdc0MuVjUa42p+Ff75T4gVlEaT8ZjtLO0pdc4i1RDdp8ts8VratuA.miioH
TjxNMmnH.iCLWotfw5T9p4YPsODkQigX8ToA3PJybUDlvH5qfO3wv6kEDEak
.LNBRsWoFBojU2Gimsw1WENrSOQEk4E4ks9X0iFua90x7Mk7UIBaCHvCXeOq
IvpTcWiY2XSZroaUFzj1moaf3NmwuXs5ptOeYd5JvejqawHYHWR2tYTsWf1u
aKdRUdM82NW42SuSuoo6IfFWOnCIa+bGDmbbeGbdDy+H7QXog++DoOG4Qu4d
34RkgcYM8mnSBCngFbShnDjwVPePx5iLG2Ya9ipxPSAfN1o0710OP91CxuOz
kf0u6O7SA42uXg64KweOc4I18baUZhhvyeqYCMjepChL631AG7TJ5V98A5sH
c.0fubo5cef40PGJhDiQFabXiMtak2EaNt5Cmy1MO8dtZl4MIYZJlhVYXlW6
A+BXy1q5nkWEepnsgiMQPJVeTyUZNcHeqVG7Al6WwNCqk+RZiBT+ENq2qFHy
MLRS3cVuW8Dl4dITfOL6vMuncK1cN5x3y5ztfByJc1iQV1OwwKSqECyhpmzb
BRWtVqVA6Tv3lJ39VAeUoPjc1ZnsXBQ+m9JTPjpcKupb0aWHJekhU7YqaZCE
zDIyTEJYF6Hpaj74qf1lwMe9JsFVUzPYy7Utt5SW8evysteC
-----------end_max5_patcher-----------
#2

Hi Hans, happy new year to you, too!
Thanks for starting it with this challenging riddle =-)

Can you please clarify these few things:

  • “it stopped working”
  • “mubu.record” but there is only mubu.record~ in the patch
  • “I loop the recording”
  • “recording first becomes erratic”
  • Your workaround patch has track audio2, but both mubu.record~ record into track audio.
  • Did you check with @progressoutput index, to avoid float math rounding errors?
  • Are you on the latest Mubu version 1.9.15?

I’d rather look at a simple patch detecting the behaviour you mention than a, let’s say, “creative” workaround … =-) You should be aware of this possibly related Max problem that you’re deliberately creating by adding/removing a DSP object: https://cycling74.com/forums/creeping-time-offset-between-internal-clock-time-and-audio-sample-time

There are no mubu-related problems with Max > 8.1.5 that I know of, only when you use FTM’s gbr.ola~ you should hold back.

All the best!

#3

Clarification

  • “it stopped working”
    mubu.record~ stopped recording
  • “mubu.record” but there is only mubu.record~ in the patch
    Yeah, sorry it is indeed mubu.record~
  • “I loop the recording”
    In my complete patch I immediately start recording at the beginning of the buffer when I have reached the end. I’d prefer working with the ring buffer option but that does not work when I use data tracks simultaneously.
  • “recording first becomes erratic”
    Yeah, I don’t know how to describe it differently. I am looking at the output of the mubu.record~ object and the numbers that are first coming out regularly each buffer length period, then start to have other gaps that are multiples of the buffer length (hence the select object). Then after a number of seconds of this erratic behaviour with large gaps, recording stops altogether.
  • Your workaround patch has track audio2, but both mubu.record~ record into track audio.
    Oh, sorry. In the original it is two different audio tracks. I removed the second track in my second example. The issue persists.
  • Did you check with @progressoutput index, to avoid float math rounding errors?
    No, I didn’t. Good tip, but it did not change the behaviour. The patch might now be more clear to you though.
  • Are you on the latest Mubu version 1.9.15?
    Yes, I am.

As far as the workaround patch is concerned, the work around jumps into action as soon as the erratic behaviour starts. It seems that that behaviour that I am deliberately creating solves my problem… Anyway I removed the workaround so you can just open my patch and see if the behaviour that I experience is the same on your configuration.

I made it super simple started it once until it stopped recording and here you have the patch and the output.


----------begin_max5_patcher----------
1584.3oc6YsriaaCEcsmuBAMYUgiAI06tpMn.AEnAs.I.cwfBCZKZOLQRzPh
ZpSCR91ykjVxRyHYKYqY5l3ExxjT5dO2mGR+kalYuRrmUXa8yV2YMa1WtY1L
8PpAlc32yrSo6WmPKzKyNkUTP2xrmalSx1K0iWHE6pFTTJSXR4m2wLuYaaq+
4vT6nx02yy1tLmsVZlM.4t.M2x0IT8kCVckPVfpelrxTdF7B0J.4vf7XsXEq
93qc7sOtRir0KEqF7q2bi5x7qFdzb4kgOeeRS7QFO9bmN7kw9W3U9D3ESW+M
6yCAeOMD7FODPcCAzE.gMxzEJ2ziAA3GV9Jh0qvG8F2VlIK2kncSny671Hxj
YzT8D1+ZNmlbBaBNRG15fL1D+EHRDIxOLvatENrgs41DAMdEMaaSsPIpMz0s
zrak47saY4zjjVKUltDrg4rMKWKxdn4TmyrSpyLtkmwMtZ6Fu1h0BiYvogZU
v+O8XXkOeph6VUJkhrdSfLlmSjDgwNJyL1Q+Ews5Z2Qf3NLEdG8k4fOVxxWx
xnqZGb7rkfkVtpbA.GQd72r3Y6JkwTIUxJjVzxXtv5W1kK1lCg0f7gYg0Dy1
2eAm4WbbaftLDF4qMg9FKIZLVRG6thVP8DsPlNi3O8sdMHE7sY.rOYc3nfEP
tYnIBJRc+npgE57rWFdWNOSZIt+Ou+C2yK98h2J.H7Aw6gdquWbL8o+pQtHc
g5C+pe30gaMjLckn6AdYBdAaJ7gdAZvdAfD+r6CKXIVDO+SWpa943DY3J3gz
3LXz8aIt8zvcByFesEpWPBgwCAeXxElKh8d9cjPMXK9IQ37gBTha3P.ZGArX
moyO1G2VSaIEwoKi+tFa95qdQiNTMX5bjRw1sIrqMnjboLL9emfQahEWl2z0
W6BwA58ggw3QWi0smFIUKsf9.KVwnEj4RpDH8BjCMaBcVMlmYyRWwhaX5fQ1
C1TnCwFdBq4a7jV7lSlR2s6ISCbtnovdDpeq0ynTzsk71ikQ2kClWCkGTMom
Y1OvxWIJX0tUiecJoOJyoq+T2jGMPPoXUi.uUE0LXqHHTghcIKlsw5yr5sMk
vyf79xLYS9+cSz7xIahgM85fh7cvQlO9dGis7ze4NlXKmww8zYbgbm1EpURs
Y6QGXhF2pwa6WAl74qqriUmSg0QrFC9OdFUxAhcMVDxrnNicFrjbeojDYHXR
Qs75kjhRiE9LhpRetNQ4L.PgauHnCJKu+NySpn0fD+TQidADsW2nFeUhVSm6
7x1cJhXwCx4pUH7THJ7fD00hpfgX+bl.AENDOU3THIx.DTvSjioJMznGJlWb
XwZQ.8Y+nPGqFNW+Sdl4m51L.MfG3Uq2SOBMG5lIgNFk4llc68MGDqcp.h5y
LLCf.e.bfHKjeN4wcFN1mT0T98PO6xhkuikUZ5hAfZCsLQ11PrZKPEIYsHwn
dMaPU0X11LaE0i50dmEZAIxEiCAyxBGrS.wWeGbimWiXwCOCt5gb8biPD0Rc
8IAtd56BINdNp6PO5wHGkEBGYj.JJD4ZtCFBCxp4iA640P6hDzfxztbwNQdk
KEdzn50WBb4yowblgeBpU634GhixgY0l8FGrIPUJQxqdllwc0NieyX0AxsuQ
jDa8WBEkG9obIMIanNKxE0wbSjp7N2+3bxu5Yt6.qKKkx+Hp7FNcsBF52AgV
D50hU2yMBGpk9EEonmCj9Z7XwXa90U+y.20n6wPJKTmxzcVtSfuaf1d3D55f
01H2GkodgI3C1WbQkENj8+hEqR2GLjf0e3RllBxeb0pKOe4GNgtyKhlrzhOU
jvABO+shMzo7SMvpYC9MuLQ5RJcuu5DTNYVY+JBZwwFApCWQuxk7LEYQVkaR
utpKM7K1z0qAstkKUSzJzIhf090fC90oEv5iDYfVdHxEnsQhzwV.qOW8cJNc
3oVsZcdxcqXi2FOAoyg9vmf4cd2IxoCBUDdm24cuf4zWCE31YGCyKZNtrAGc
o8YM1t.fYPmmvHKyIf9ljR1oYQ0QxnCVUHWoV90JXzgZ6SsB91bFKazZnoDj
i5i5NreHrcqIU4JSWwxeKPXdz5lxPgzQxdP4LOscD2LRd7JnYy35S2VogE6N
vqUeH3270a9tRbaLU
-----------end_max5_patcher-----------

output in the max window:
IRCAMMUBURecordErraticAndThenStop.rtf (24.2 KB)

#4

Hi Hans, thanks for the clarifications. For me, everything works as expected.

The test patch only stops after 30min when the track is full, with a last partial vector of 32. Otherwise, whenever the DSP graph is changed (opening/closing/editing in another patch), progress reporting can be interrupted shortly, and then catch up with a larger delta, which is normal, but would trigger your warning.

To really see if there’s an error on your computer, record a known signal (a slow sine wave or a long ramp), and check if the signal has discontinuities.

Best.

#5

Thanks for checking that.

For checking a discontinuity I wanted to record externally so I used VB_cable (https://vb-audio.com/Cable/) to route audio from the MAX application to audacity. Only, the problem wasn’t there in this configuration…
I am still checking what it can be.

Thanks, best, Hans.

Best, Hans.