-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarification: insertDTMF replaces the current tone buffer #1338
Conversation
webrtc.html
Outdated
<p>Since <code>insertDTMF</code> replaces the tone | ||
buffer, in order to add to the DTMF tones to be played, | ||
it is necessary to append additional tones to the | ||
tone buffer. Calling <code><a data-for= |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: "in order to add to the DTMF tones being played, it is necessary to call insertDTMF
with a string containing both the remaining tones (stored in toneBuffer
) and the new tones appended together."
LGTM. |
it is necessary to call <code>insertDTMF</code> with a | ||
string containing both the remaining tones (stored in | ||
<code>toneBuffer</code>) and the new tones appended | ||
together. Calling <code><a data-for= |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this actually safe? A tone could be sent in between toneBuffer
being read and insertDTMF
being called with the additional tones, resulting in one being sent twice.
Is it too late to change this behavior? I wonder how many applications are actually reliant on it, or what the intention was.
EDIT: Nevermind. toneBuffer
is only drained from a queued "playout task" so this is safe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we have playout tasks and is on main loop this should be safe.
Fix for Issue #1260