Re: Help needed with a sync-problem

Hi Chris, all.

On 3 Aug 2012, at 23:54, "Chris Rogers" <crogers@google.com> wrote:

> This is the way that a real-time audio thread interacting with a main thread (which can have its own delays such as garbage collection) must be.  It's a law of physics.

Notwithstanding the main bit of this discussion - figuring out whether/how to change the architecture to solve this issue, would it be possible to document it better in the draft spec?

At the moment, the spec only says
g Lower numbers for bufferSize will result in a lower (better) latency.h which is correct but it does not really explain:
* why/how the JSAudioNode introduces a delay
* why/how this can be a problem in e.g asymetric graphs, when e.g phase is important.

Our team ran into the issue with the JS Node early in our exploration, and we really struggled to understand what was happening. Had it been well documented, I think we would have happily found a way to balance our graph (blank js node, or delay node) and not think twice about it. Especially if the remedy was well documented.

I would be curious to know how many developers are likely to ever use custom nodes (not sure our group is particularly representative - I suspect maybe 20%?), how many of those will ever run into the delay issue (20%?) and how many of those would find it unacceptable to have to balance their graph (20% again?)c 

Obviously, I don't want to flippantly cast out Peter's use case as an edge case; likewise, I welcome our trying to solve what is, indeed, an annoying limitation of the model on which we are working. 

I am, however, concerned that we may be agonising over an extremely complicated solution to an issue touching perhaps 1% of our prospective user base.

-- 
Olivier

http://www.bbc.co.uk/

This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
					

Received on Monday, 6 August 2012 13:53:02 UTC