Bug #578

AudioGraph with multiple sinks process multiple times

Added by Trond Lossius about 9 years ago. Updated about 6 years ago.

Status:ClosedStart date:2010-08-14
Priority:UrgentDue date:
Assignee:-% Done:

0%

Category:-Spent time:-
Target version:(Jamoma Platform) - CNMAT 2012 workshop
Branch:master OS:

Description

Nils has stumbled onto a problem that seems fairly significant: N sinks in a graph (e.g. multiple jcom.unpack≈ objects in Max) cause the entire graph to process N times. He spotted this in a patcher with two jcom.unpack≈ objects that was (seemingly mysteriously) playing back a soundfile a double-speed. I've also now observed the problem in the debugger.

If we have one sink driving the graph then there can be multiple connections to an outlet. The 'preprocess' method is called to reset object status and the 'process' method is called M times and everything is fine. The problem with multiple sink objects is that 'preprocess' is called for each sink, which resets the status flags and processing happens afresh.

It isn't particularly clear to me how to address this.

Here are a couple of potentially bad ideas:

1. We could introduce some sort of asynchronicity to the process. This means that there would be something akind to a deferlow that would somehow be set every time and we would have to rely on buffering previous samples or something. I guess this might introduce latency? I don't like this idea at all, but maybe some other idea can come from it.

2. We could try to run all of our processing on its own thread and then somehow any/all sinks in a patcher would communicate to this thread with some kind of synchronization and everything would be okay? It's probably pretty obvious that I'm just making all of this up...

3. Maybe there is a way that, in Max at least, we could have multiple sinks (e.g. jcom.unpack≈ objects) and they would all know about each other. The problem here is that these objects don't know anything about the objects that they do, or don't, have in common when they pull. Somehow they would need to figure this out so that only one object can send the 'preprocess' call to reset the status flag.

Of these three options, I like 3 the best, though I don't have a clear idea on how to do it. There is the nagging issue of what to do when we are in a different environment with multiple sink objects. For example, imagine a Ruby app that has both a dac≈ and a soundfile.recorder≈ and a level meter. How do we deal with this then?

best,
Tim

History

#1 Updated by Trond Lossius about 9 years ago

I have set up a wiki page for nailing down a solution here.

#2 Updated by Nils Peters almost 8 years ago

  • Target version set to Kansas City Workshop Sprint 2011

#3 Updated by Trond Lossius almost 7 years ago

  • Target version changed from Kansas City Workshop Sprint 2011 to CNMAT 2012 workshop

#4 Updated by Trond Lossius almost 7 years ago

I've added an integration test named redundantProcessingWithMultipleSources.test.maxpat to AudioGraph that illustrates this problem.

#5 Updated by Trond Lossius about 6 years ago

  • Status changed from New to Closed

Moved to GitHub

Also available in: Atom PDF