fetch() not exposed in AudioWorkletGlobalScope untestable: Impossible to verify blocking the worklet (rendering) thread

[guest271314]

[audioworklet] Expose fetch() in AudioWorkletGlobalScope. #1439 https://github.com/WebAudio/web-audio-api/issues/1439 includes several assumptions re the potential for fetch() or XMLHttpRequest() to block the Worklet rendering thread. (See also Is defining fetch() in AudioWorkletGlobalScope an implementer choice?

73 https://github.com/WebAudio/web-audio-api-v2/issues/73).

However, it does not appear that any tests were actually performed to verify the assumptions made therein.

Find a way to expose fetch() in AudioWorkletGlobalScope (AudioWorkletProcessor) to test and verify the theory, based on scientific evidence, rather than assumptions, that using fetch() in the AudioWorkletGlobalScope blocks the Worklet ("real-time" audio signal processing) rendering thread - or not.

[guest271314]

cc @hoch @padenot @rtoy @karlt

[jdm]

These seems like the wrong repository for this. If fetch is not currently exposed in those global scopes, we can't write tests about its behaviour.

[guest271314]

@jdm There are assumptions made in the linked issues that cannot be verified. From perspective here, this repository is precisely for the purpose of testing and verifiying technical assumptions or theories.

See OP at

Find a way to expose fetch() in AudioWorkletGlobalScope (AudioWorkletProcessor) to test and verify the theory, based on scientific evidence, rather than assumptions

Are you suggesting that the matter is settled? That assumptions not based on verifiable scientific results must be accepted simply because there is no current means to test the theories?

Closing this issue appears to be premature.

[guest271314]

@jdm

If fetch is not currently exposed in those global scopes, we can't write tests about its behaviour.

There are ways to test the assumptions and theories made. One way is to use WebAssembly to define fetch() in AudioWorkletGlobalScope. However, that is probably not the only way to perform the tests. Thus, this issue specifically asks to find a way to construct the tests. Methods that are not exposed in a particular scope by default could later be exposed based on results of tests, rather than assumptions which preclude such tests from even occurring due to predisposed notions of what could potentially occur, rather than fact-based analysis of actual results.

What repository do you suggest filing the issue at if not Web Platform Tests, where the purpose of the entire repository is testing?

[jdm]

The purpose of this repository is testing implementations against the specifications. For an issue with a specification where a decision was made and you wish to revisit that decision, continuing to discuss it in the repository for that specification makes more sense than filing a new issue in the testing repository about how to verify the claims from the original issue.

[guest271314]

@jdm

continuing to discuss it in the repository for that specification makes more sense than filing a new issue in the testing repository about how to verify the claims from the original issue.

Already did that. Linked at OP.

Am not satisfied with the reasoning presented by authors of the specification.

Specifically, there is no evidence presented other than assumptions - without any accompanying tests providing supporting basis for the assumptions made.

If Salk were to have stopped research due to the conjecture of fellow scientists, detractors, or even errors, omissions or failures after initial deployment, the polio vaccine produced by his approaches would not have reached the masses that desparately needed such temerity to proceed in the face of "leading" scientists doubting them in every way.

Once a claim is made the only course of action is verifying the claim independently, by any means. That is the basis of the scientific method. Not for the claimaints to reproduce the theory, but for scientists and researchers other than the claimants to reproduce the theory

Now watch. Um, this how science works. One researcher comes up with a result. And that is not the truth. No, no. A scientific emergent truth is not the result of one experiment. What has to happen is somebody else has to verify it. Preferably a competitor. Preferably someone who doesn't want you to be correct.

• Neil deGrasse Tyson, May 3, 2017 at 92nd Street Y

Thus, it is precisely when an assumption is questioned directly to the official body, and the answer provided lacks supporting evidence, that the ansswer must be found to the claims made, in spite and independent of the official body, if that body decided to not produce such evidence that supports an assumption. Even if evidencce was presented by the official body which supported their theories - in this case no such evidence appears to exist - that is also precisely where individuals and institutions - other than the publishing body ("Preferably someone who doesn't want you to be correct") - must apply the scientific method to reproduce the theory, or the theory objectively is null and void. Otherwise, individuals and institutions would be relying on mere theories and conjecture for any and all domains of human activity: The official narrative says so, therefore it must be true, which is unacceptable; does not by fiat, force, or decree make the claim scientifically true. Some might accept such conclusions, not all.

It would make sense for individuals and institutions that have theories of what will occur when X happens, and have the capability to do so, vet their own concerns and rely on objective results, rather than assumptions. Unless mistaken, that has not occurred re fetch() potential for blocking "real-time" audio process signaling. Perhaps it was convenient to simply assume an outcome, given a prediposed design-concept of not exposing I/O, or exclusivity of a particular initial use case for AudioWorklet conceived. However, a self-imposed limitation on a given theory does not preclude individuals and institutions other than the authors of the disclosure from exploring claims made in the controlling document and antecedent discussions.

Am currently attempting to https://github.com/rustwasm/wasm-bindgen/tree/master/examples/fetch. Will proceed trying to verify the concerns re networking and/or filesystem I/O blocking audio signal processing and once get that approach running, and any other approaches to expose fetch() or equivalent in AudioWorkletGlobalScope am able to get working, will publish the results, without rancor.

[jdm]

I have no comment on whether the change you want makes sense or not, and I have no comment on how that decision was made. This is the wrong repository to continue discussing that, however.