should au latency propagate through the graph?
should au latency propagate through the graph?
- Subject: should au latency propagate through the graph?
- From: Brian Whitman <email@hidden>
- Date: Thu, 13 Apr 2006 14:20:56 -0400
We've got:
scheduled sound player -> mixer input 0
mixer output 0 -> aufc/tmpt
mixer output 1 -> end mixer input 0
aufc/tmpt -> end mixer input 1
end mixer -> output
i.e. a generator split into a "effect chain--" one path going right
to a mixer then output, one path going through an effect then to the
mixer then output. The user/code can turn up and down the "effect
send" by changing the end mixer's input gains.
a) Is this the way to implement such an effect bus, or are there more
specialized methods?
b) If we use aufc/tmpt as the effect, there's obviously a latency
involved. If I play this graph with both effect and "dry" mixers
turned up, I can hear that the clean version is some latency ahead of
the effected version. Shouldn't the latency of the effect AU somehow
inform the other AUs to wait before rendering? Or do I manually have
to add a sample delay to the dry version before feeding it to the mixer?
If so, looking at the list archives I see there was a known issue
with aufc/tmpt latency reporting. Has this been fixed?
c) Is there a better way to "bypass" an effect? Setting the aufc/tmpt
rate at 1.0 still incurs the same CPU wrath as if it were "working."
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden