Subject: [rtcweb] Irrelevant comments on draft-ietf-rtcweb-audio

From: Cullen Jennings <[email-masked]>
Date: Sun, 22 Mar 2015 10:38:07 -0400

Two small things ...

The draft has 

   the clients SHOULD ensure that
   the speaker-to-microphone gain is below unity at all frequencies to
   avoid instability

I have no idea how the average browser could implement that. If it's not implementable, we might want to remove it. 

I think I know what you are trying to get at with 

   For
   clients that do not control the audio capture and playback hardware,
   it is RECOMMENDED to support echo cancellation between devices
   running at slightly different sampling rates, such as when a webcam
   is used for microphone.

but I'm not really sure what that paragraph means. It might need a bit of clarification. They can't run a different rates for a long time with some Q overflowing or underflowing so somewhere the rates are normalized. And I'm not sure that client control or not changes this - even if the client controls them, they can still be based off different clock sources. 

But that said, if there is no desire to change these I don't care because I don't think changing the two above points will impact implementations in any real way.

---

From: Jean-Marc Valin <[email-masked]>
Date: Sun, 22 Mar 2015 13:35:03 -0400

Hi Cullen,

Thanks for the feedback. See below.

On 22/03/15 10:38 AM, Cullen Jennings wrote:
> The draft has
> 
> the clients SHOULD ensure that the speaker-to-microphone gain is 
> below unity at all frequencies to avoid instability
> 
> I have no idea how the average browser could implement that. If
> it's not implementable, we might want to remove it.

I guess this would have been best phrased using the 6919 SHOULD
CONSIDER, but I agree that it's probably not too practical (you can do
it, but it'd be about the same complexity as a simple echo canceller).

> For clients that do not control the audio capture and playback 
> hardware, it is RECOMMENDED to support echo cancellation between 
> devices running at slightly different sampling rates, such as when
> a webcam is used for microphone.
> 
> but I'm not really sure what that paragraph means. It might need a 
> bit of clarification. They can't run a different rates for a long 
> time with some Q overflowing or underflowing so somewhere the
> rates are normalized. And I'm not sure that client control or not
> changes this - even if the client controls them, they can still be
> based off different clock sources.

What I'm trying to say here is that unless you actually designed the
capture/playback hardware (e.g. when you design a phone yourself),
then you may be stuck with the capture and playback running on
different clocks. That's a very common situation on PCs and while the
jitter buffer will usually cope relatively easily (unless the clock
drift is very large), a basic echo canceller will not. So the
recommendation is that if you're in this situation (and every browser
is), you should use an echo canceller that's able to cope with clock
drift.

> But that said, if there is no desire to change these I don't care 
> because I don't think changing the two above points will impact 
> implementations in any real way.

Well, I have no objection to removing the first one. About the second
one, I don't mind whether it's SHOULD, MAY, SHOULD CONSIDER or OUGHT
TO, but I'd like to keep some text that acts as "best practice to
avoid bad echo problems".

Cheers,

	Jean-Marc