Re: Draft Updated Charter adding Mouse Lock and Gamepad

That's one of those things that makes total sense for audio data streaming
(where you're pushing 44.1kHz x 16bit x Stereo = 176kBytes a second), but
isn't really necessary for MIDI (where even the theoretical maximum tops out
at around 1300 MIDI events/sec, and typical density is probably more like
~100 events a second, max.  A millisecond glitch in audio is also extremely
noticeable - but a millisecond lag in MIDI i/o is a lot less so (MIDI
usually has a latency in the system of 4ms or so anyway).

On Wed, Oct 5, 2011 at 5:11 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Thu, Oct 6, 2011 at 12:59 PM, Chris Wilson <cwilso@google.com> wrote:
>
>> The short version is "I want to be able to easily write code so I can do
>> noteOn(channel, key #, velocity) and handleNoteOn(channel, key #,
>> velocity)."
>>
>
>> Do ProcessedMediaStreams need to be in a worker?
>>
>
> The ProcessedMediaStream object is on the main thread. The processing
> happens in a Worker.
>
> We could also offer a processing API that happens on the main thread.
> You'll be subject to main-thread latency then, and liable to glitch.
>
> We will probably offer a main-thread API to generate a stream by injecting
> data periodically (initially audio samples, but could be other kinds of data
> too). That would be a lower-latency way to generate a stream from the main
> thread (lower latency than posting the data to a Worker which is driving a
> zero-input ProcessedMediaStream), but would also be liable to glitch if
> you're not buffering up data very far. Doing real-time things on the main
> thread is just risky :-).
>
> Rob
> --
> "If we claim to be without sin, we deceive ourselves and the truth is not
> in us. If we confess our sins, he is faithful and just and will forgive us
> our sins and purify us from all unrighteousness. If we claim we have not
> sinned, we make him out to be a liar and his word is not in us." [1 John
> 1:8-10]
>