Re: V2 of DTMF - the "Object Oriented" approach

On 18 November 2012 17:21, Harald Alvestrand <harald@alvestrand.no> wrote:
> On 11/16/2012 05:28 PM, Martin Thomson wrote:
>>
>> Looks good.  A few comments.
>>
>> s/ontonechange/ontone/
>
> The reason for calling it "ontonechange" was that I'm also proposing to call
> it at tone end.

On consideration, with the below in mind, I don't think that an end
tone is necessary.

>> I think that we agreed that all tones would be of a known length, so
>> there is no need to event on tone end.
>
> I don't remember such an agreement.

We discussed this at some point in the past (the Stockholm interim,
perhaps?).  The conclusion I recall was to avoid the mode where
indeterminate length tones are sent and to always have definite
length.  That may be a consequence of a faulty brain, which is a
distinct possibility, but I'd still argue for the same outcome.

In any case, if you fire tone events when they start and include the
length, then you have no need for an 'end' signal.  You might like a
way to see what tones are remaining though.

> The length is part of the parameters. If the tone insertion and JS timers
> were both completely predictable, there would be no need for a callback at
> all.

The timing of the actual send does not need to be affected by
perturbations on the main JavaScript thread.  That said, knowing when
tones play out is useful.

I tend to think that events are more useful on receipt, but we decided
not to implement a DTMF receiver.

> Having the callback has the advantage that the feedback signal and the tone
> playout can't get out of sync; this applies as much at the end of the tone
> sequene as at intermediate steps.

They will get out of sequence, unless your JavaScript is written with
much more discipline than I've seen demonstrated.

> Are you proposing that the buffer is a FIFO? I'd thought that the buffer
> would be a string that was reset on a new tone. FIFO's fine with me (but
> then we need an "abort" call too).

FIFO doesn't necessarily imply abort, but I didn't consider that
consequence.  In the interests of simplicity, let's say that the
string, which replaces the existing string will suffice.  If you want
varying lengths, then you can use the existing.

Note: given that there are definite length tones with a minimum
spacing, changing the string will not cause the first tone to be
played immediately.  The browser will have to wait until the current
tone finishes and for the requested spacing.  If there is a scheduled
task, that task isn't cancelled, it is used to fire the first tone
from the new string.

on insertDTMF:
   1. If the associated MediaStreamTrack is not connected to the
associated PeerConnection, return.
   2. If canInsertDTMF is false, return.
   3. replace the string of tones
   4. if there is no task scheduled for playing tones, start the
process below asynchronously
... continue as above

Received on Monday, 19 November 2012 18:24:38 UTC