[Bug 11673] Streaming audio data from a microphone over a WebSocket
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11673 Ian 'Hixie' Hickson changed: What|Removed |Added CC||public-webapps@w3.org Component|other Hixie drafts (editor: |WebSocket API (editor: Ian |Ian Hickson)|Hickson) Product|HTML WG |WebAppsWG Summary|[device] Streaming audio|Streaming audio data from a |data from a microphone over |microphone over a WebSocket |a WebSocket | QAContact|public-html-bugzi...@w3.org |member-webapi-...@w3.org --- Comment #4 from Ian 'Hixie' Hickson 2011-03-15 06:02:48 UTC --- Moving this to WebSockets. This will likely not be supported for some time. In the meantime, a server could just implement PeerConnection if you're willing to do unreliable audio over UDP (as opposed to reliable but potentially high-latency audio over TCP). -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
RE: publish Last Call Working Draft of Web Workers; deadline March 7
Drew Wilson (atwil...@google.com) wrote: > I think this alternate lifetime model is practically unimplementable in a > world where > workers and pages live in multiple processes. The reason is that the linkage > between > nodes in your graph depends on reachability of ports which can't really be > established > simultaneously across processes - I think you end up with cycles in the graph > that can't > easily be resolved. It sounds like we agree that this alternate lifetime model (based on graph reachability) is not desirable and should not be specified. -- > I guess I don't understand the implementability concerns that would lead to > adopting #2. > Your example below seems largely identical to: > > Document creates two workers, W1 and W2 > Document creates a MessageChannel and gives one port to each worker > Document removes all references to the worker objects, so those two ports are > the only > thing keeping W1 and W2 alive. > > I don't understand why we would treat this case differently than your case > (where a third > worker actually performs the creation). Yes, these are effectively the same, except with "terminate" I expressly instruct the worker to close, rather than relying on the GC > Let me provide a useful real-life example: > > 1) Document creates worker W1 and immediately drops its reference to it so > it is no longer reachable. W1 is still protected because it has not run its > initial script yet. > 2) In its startup script, W1 creates two workers, W2 and W3, and immediately > drops references to them. W1 is permissible, but no longer protected, and > could be closed at any time. > 3) W2 and W3 run their startup script to do some quick processing, and when > complete they will upload the results to the server. > 4) Since W1 is no longer protected, the system could close it, so let's say > W1 gets closed now. > > With the spec as it currently stands, W2 and W3 would continue to run as > long as the parent document stays alive, and they would complete their > processing and submit the results to the server. > With your suggested change, W1 would close, and that would cascade to W2 and > W3, cancelling their operation. So developers would be forced to find a way > to keep W1 alive for the duration of the execution of W2 and W3 to prevent > them from being prematurely closed, either by timers, or by holding > references to resources (like protected workers W2 and W3) that they don't > need. > > So I'm not certain that the lifetime specification you describe has the > desired behavior in the case of fire-and-forget workers (workers that don't > need to interact with their parents). Correct. The model I describe would terminate the nested workers W2 and W3 when W1 was closed. Approach #2 could be altered to accommodate this scenario. Rather than running the "terminate a worker" algorithm which would effectively kill the operation-in-progress in W2 and W3, the worker would simply set the close flag on all of its owned workers to "true". Per the spec, this would allow the workers to finish any pending tasks they had queued up, but not allow any new work to be added, and they would terminate after that. I simulated this in Opera 11 to see how they handled it by having Document D create a W1 (in a fire-and-forget model as you describe). In W1's initial script it fires-and-forgets W2, but then expressly calls "close()" on itself. W2's initial script is to start an XHR GET request for another resource, then at readyState4 it sets a timeout to XHR another file and so on four times over about ten seconds. Using a network monitoring tool, I observe that W2 is downloaded, but no XHR request is ever made. When I remove the explicit "close()" call, then all four resources are requested from W2 (it stayed alive). My conclusion is that Opera has a hybrid model where express "close()" or "terminate()" calls will cascade-close the nested workers, but otherwise (in fire-and-forget cases at least) the worker is either 1) not closed at all because no GC happens or 2) orphaned and continues to run as per spec. I can't really tell either way without knowing when the system decides to close W1. In general I acknowledge that fire-and-forget scenarios are important-enough that they should be supported (as they are supported in Opera today). Perhaps this negates the need to pursue alternate approach #2?
Re: API for matrix manipulation
Comments or is something already being worked on ? There are already 2 such classes: SVGMatrix and CSSMatrix. The former is an affine transformation matrix (commonly misnamed a "2x3 matrix") and the latter is a 3D homogeneous transformation matrix (commonly correctly named a "4x4 matrix"). Are those classes in their current implementations thread-safe ? Could a Web Worker easily do matrix calculations with them ? I would guess a basic physics engine in a worker would be a nice use case. And what about making something that is generic enough for both SVG and CSS, or even full blown algebra ? And then specify bindings of implicit conversions from those DOM classes into a basic ES matrix (if you would like to call it that) ?
Re: API for matrix manipulation
On Mar 14, 2011, at 12:19 PM, Lars Knudsen wrote: > Hi, > > related to this: Is there any work ongoing to tie these (or more generic > vector / matrix) classes to OpenCL / WebCL for faster computation across CPUs > and GPUs? On WebKit I've experimented with an API to copy a CSSMatrix to an Float32Array, which can be directly uploaded to the GPU. It's surprising how much more efficient this was than copying the 16 floating point values out of the CSSMatrix using JS. But I've hesitated proposing such an API while WebGL and Typed Arrays were still in draft. Now that they're not, maybe it's time to discuss it. I've also experimented with API in CSSMatrix to do in-place operations, rather than creating a new CSSMatrix to hold the results. This too was a big win, mostly I think because you get rid of all the churn of creating and collecting CSSMatrix objects. - ~Chris cmar...@apple.com
Re: API for matrix manipulation
On Mar 14, 2011, at 7:56 AM, João Eiras wrote:
> Hi.
>
> Given that a number of API are being developed that require complex
> matricial calculations (transforms, device orientation, web gl), I
> would suggest that perhaps an API with a big number of common
> calculations could be made available ? And a proper way to represent
> them. Perhaps, the best way to add this would be to extend the Math
> object with things like.
>
> Math.mAdd(m1, m2)
> Math.mSub(m1, m2)
> Math.mMult(m1, m2)
> Math.mDiv(m1, m2)
> Math.mInverse(m1)
> Math.mGaussianReduce(m1)
> Math.mRank(m1)
> Math.mRank(m1)
>
> Being the matrix an array like object like (could even be one of those
> fast arrays like ArrayBuffer).
>
> # {
> # w: ,
> # h: ,
> # length:
> # 0: ...,
> # 1: ...,
> # 2: ...
> # (...)
> # }
>
> Comments or is something already being worked on ?
There are already 2 such classes: SVGMatrix and CSSMatrix. The former is an
affine transformation matrix (commonly misnamed a "2x3 matrix") and the latter
is a 3D homogeneous transformation matrix (commonly correctly named a "4x4
matrix").
We added CSSMatrix to the CSS Transform Spec to give us the same functionality
as SVG Matrix, but for 3D transforms. Therefore both of these classes are
pretty light on their operators. It might be useful to discuss "one matrix to
rule them all", which could be used in place of the current classes and with
more functionality. But it's important not to go too far down this path, or
you'll end up defining classes for Points, Lines, Planes, Bounding Boxes and
View Volumes with dozens of functions. Down that path lies madness.
I think the current spec handles the more complex (inverse and multiply) and
more commonly used (scale, rotate, translate) functions. I'm not sure what
adding and subtracting 2 matrices means, and division is handled by inverse and
multiply. The others seem pretty domain specific for a general class. And
remember you can (and many people have) created JS libraries to add funcrtions
to the built-in matrix classes. I wrote one:
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/demos/webkit/resources/J3DIMath.js
which uses CSSMatrix if it exists and uses JS otherwise. It exposed some
interesting deficiencies in the current CSSMatrix class. There are several bugs
on WebKit to address these and other issues of matrix efficiency and
functionality: 23799, 28850, 50633, 52488. Perhaps it would be useful to open
these (or similar) bugs on the w3c bug system?
That's where I believe we are on the Matrix front.
-
~Chris
cmar...@apple.com
Re: API for matrix manipulation
On 3/14/11 10:56 AM, João Eiras wrote: Math.mAdd(m1, m2) Math.mSub(m1, m2) Math.mMult(m1, m2) Presumably throwing on size mismatches? Math.mDiv(m1, m2) I don't think we should add this. Matrix "division" is a pretty fuzzy concept with non-square matrices. And if you stick to square matrices, it's easy to clearly do whatever you're trying to do with inverses. Math.mInverse(m1) Presumably throwing for non-square matrices? Math.mGaussianReduce(m1) This could be "fun" to define. Are you actually talking about Gaussian elimination, or Gauss-Jordan? For either one the output is not uniquely defined (at least not if you might want to make it fast), last I checked -Boris
API for matrix manipulation
Hi.
Given that a number of API are being developed that require complex
matricial calculations (transforms, device orientation, web gl), I
would suggest that perhaps an API with a big number of common
calculations could be made available ? And a proper way to represent
them. Perhaps, the best way to add this would be to extend the Math
object with things like.
Math.mAdd(m1, m2)
Math.mSub(m1, m2)
Math.mMult(m1, m2)
Math.mDiv(m1, m2)
Math.mInverse(m1)
Math.mGaussianReduce(m1)
Math.mRank(m1)
Math.mRank(m1)
Being the matrix an array like object like (could even be one of those
fast arrays like ArrayBuffer).
# {
# w: ,
# h: ,
# length:
# 0: ...,
# 1: ...,
# 2: ...
# (...)
# }
Comments or is something already being worked on ?
Thank you.
