--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
So should we revisit the debate in that intent before proceeding with this one?
We discussed this with Raymond on IRC yesterday and came to conclusion that the intended functionality does not actually depend on the latency hint implementation, because the data for both outputTimeStamp and outputLatency is fetched directly from the platform API (e.g. WASAPI IAudioClock::GetPosition on Windows) and this should work fine with any latency requirements provided by the user.
On Wed, May 18, 2016 at 7:26 AM, Mikhail Pozdnyakov <mikhail.p...@intel.com> wrote:We discussed this with Raymond on IRC yesterday and came to conclusion that the intended functionality does not actually depend on the latency hint implementation, because the data for both outputTimeStamp and outputLatency is fetched directly from the platform API (e.g. WASAPI IAudioClock::GetPosition on Windows) and this should work fine with any latency requirements provided by the user.To be clear, we agreed that the baseLatency (from the buffering/latency hint) doesn't affect the time stamp much. The double buffering needs to be accounted for, but the latency hint doesn't introduce any additional delay that would be propagated to the timestamps especially contextTime.Well, I think that's true. We haven't implemented it yet, so this is really just my best guess based on what we actually do today (without the latency hint).I did not look into the platform API stuff. Are there equivalent APIs for the other platforms? If not, is that going to be a problem to implement this for all six platforms you said this would be implemented for?
On Wednesday, May 18, 2016 at 6:46:19 PM UTC+3, Raymond Toy wrote:On Wed, May 18, 2016 at 7:26 AM, Mikhail Pozdnyakov <mikhail.p...@intel.com> wrote:We discussed this with Raymond on IRC yesterday and came to conclusion that the intended functionality does not actually depend on the latency hint implementation, because the data for both outputTimeStamp and outputLatency is fetched directly from the platform API (e.g. WASAPI IAudioClock::GetPosition on Windows) and this should work fine with any latency requirements provided by the user.To be clear, we agreed that the baseLatency (from the buffering/latency hint) doesn't affect the time stamp much. The double buffering needs to be accounted for, but the latency hint doesn't introduce any additional delay that would be propagated to the timestamps especially contextTime.Well, I think that's true. We haven't implemented it yet, so this is really just my best guess based on what we actually do today (without the latency hint).I did not look into the platform API stuff. Are there equivalent APIs for the other platforms? If not, is that going to be a problem to implement this for all six platforms you said this would be implemented for?
I believe all the major platforms offer API equivalents so that it should be possible to implement the intended functionality for them.
I've also pointed it out the issue tracker and the PR. We have confusing variables in two different places. I feel like we're improvising new features as we go because of the flaws in original API. If we have to introduce this feature, I think we can do that in a cleaner and nicer way.The following is what's planned in the intent:AudioDestinationNode.outputTimeStamp.contextTimeAudioDestinationNode.outputTimeStamp.performanceTimeAudioDestinationNode.outputLatencyCurrently we have (or fimly decided):AudioContext.currentTimeAudioContext.baseLatencyIn the original discussion, Mikhail argued the destination node having the time and the latency information is the right design, but I believe otherwise. The destination node is the final gate of audiograph, not the driving engine of audio rendering process. Somehow Blink implements the rendering mechanism inside of the destination node, but it does not mean the API design must follow how it is implemented. Conceptually the destination node is a passive element just like any other node. It is not responsible for advancing time or calculating the expected latency.