Serialosc causing OS level interrupt/glitching?

  • Having this weird problem with my soundcard (doesn't happen with built in audio) where changing pages is freaking out the OS and causing audio interrupts. I've tested it on two computers (latest Mavericks, Max, and serialosc on everything) with the same soundcard (MOTU microbook II, latest drivers/firmware) and it's consistent.

    Here's a video showing what's happening. It's a patch with serialosc parsing (the setup window from The Party Van), and just the demosound patch. No heavy lifting at all.

    http://www.rodrigoconstanzo.com/monome/glitch.zip

  • I tested some more and it seemed like sending osc messages to serialosc was causing the problem. I fixed it by adding a [defer] just before serialosc. Weird.

  • hey rodrigo - this is super weird!

    i'm curious what's changed on your system? is this a new soundcard, or have you just updated OS or max?

    i'm not quite sure how much processing happens when you 'change page' but perhaps you could try gating the led output (rather than the press altogether). if the glitching continues it pretty much rules out a USB bus throughput issue.

    it looks to me more like max just struggling to process everything in time rather than the OS interrupting the audio. the UDP objects are high-priority in max and i've experienced problems in the past where triggering a UI update at high-priority caused audio glitches (eg. turning on reverb in mlrv used to glitch because i triggered it via the GUI button. now the gate is triggered directly and the GUI update with a deferlow).

    it does seem strange that there's not really anything going in the patch though!?

  • Same soundcard as always. I did update soundcard firmware/driver, but I don't remember when that happened in relation to the problems. It's only in the last gig that I noticed this noise.

    It's not a massive amount of messages, it's just 64 messages (dumping a matrixctrl to the monome). I've been wanting/meaning to build a better page storage/loading section (that only draws what's different) but haven't gotten around to it yet.

    I didn't realize UDP was high priority. For now defer is working, though I should build a better paging/redrawer.

  • does it still happen if you send the OSC messages to something other than serialosc?

  • Hmm, if I send to a different udpsend port, it doesn't glitch. (glitches on 12002 but not on 12003)

  • That's where the first inlet is heading to (in the latest serialosc.maxpat).

    [updsend localhost 17812] appears to have the device type info associated with it.

  • Sorry to bump this, but in using it in performance now it looks like the "add deferlow" is adding LED lag now....

    hmm.