Google Groups

Re: [discuss-webrtc] Re: Audio input default 8Khz breaks peerconnection factory


Henrik Andreassson May 4, 2012 12:19 PM
Posted in group: discuss-webrtc
Windows (Vista and above) and Max OS X allows the user to set a preferred sample rate as "native" rate. Are you saying that we should simply ignore this setting and assume that the user did not know what he was doing when he/she selected a certain rate? If so, what other types of user settings should be ignored; mute, volume levels etc.? If a user has asked for 8kHz as input rate, then the best rate to work with is 8kHz. There is not much we can do about that and the user will have to live with the consequences. On some platforms, it is possible to use an alternative sample rate than the native rate but that has other negative effects.

Again, WebRTC shall work for 8kHz on all platforms but it will not function at its full capacity.

On Fri, May 4, 2012 at 7:54 PM, ak <star...@gmail.com> wrote:
On reading your comments again it seems you are saying it is in the
interest of the user to set a higher sampling rate to enjoy webRTC in
its broader context.

My experience is getting users to understand let alone modify such
technicalities is a non starter.

Surely WebRTC can attempt to address Audio at an acceptable rate
(44.1Khz) rather than simply accept the current rate set and take
remedial action (step down the list) if that fails which is highly
unlikely.

On May 4, 9:59 am, ak <starlo...@gmail.com> wrote:
> Henrik
>
> Thank you for your prompt response.
> Can you qualify: "As a bonus, you will be able to enjoy much better
> audio than plain old G.711"
>
> How exactly does one enjoy better audio when interconnecting with the
> PSTN which is limited to 8Khz audio? WebRTC browser to browser is not
> the only use case.
>
> On May 4, 12:15 am, Henrik Andreasson <henr...@webrtc.org> wrote:
>
>
>
>
>
>
>
> > There is no strong technical reason not to support 8kHz input sampling rate
> > and I will ensure that it is added when other more important tasks are
> > finalized. However, it does "cripple" the performance since you exclude all
> > usage of proper wideband codecs and it might also be difficult for a user
> > to figure out that he/she is actually missing the chance of
> > experiencing wideband. But yes, I do agree that things should not crash
> > when 8kHz is used; that is not acceptable.
>
> > I have tried WebRTC in Chrome on 10.7 machines as well but was not able to
> > find any that was locked down to 8kHz input rate.
>
> > Until a patch has landed, I would recommend that you try to resolve the
> > issue on your side since it can't be an exepected behavior to ignore user
> > settings. As a bonus, you will be able to enjoy much better audio than
> > plain old G.711.
>
> > On Fri, May 4, 2012 at 7:18 AM, ak <starlo...@gmail.com> wrote:
> > > Henrik
>
> > > Appreciate your commenting on the fact that webRTC
>
> > > 1. supports the G711 (8Khz) codec and yet
> > > 2. fails to support an Audio Input Device set to that same 8Khz
> > > sampling?
>
> > > > > > > > > > For playout we support
> > > > > > > > > > {96000, 44100,48000} and for recording we support
> > > > > > > > > > {96000,48000,44100,32000,16000}.
>
> > > Is there any technical reason that precludes webRTC from supporting
> > > 8Khz recording?
>
> > > A.
>
> > > On Apr 24, 10:48 am, ak <starlo...@gmail.com> wrote:
> > > > Henrik
>
> > > > Thank you for those validating references. I am sure you would agree
> > > > its a non starter to get users involved in Audio Sampling Rate issues.
> > > > Let alone that the INIT error in webRTC goes unreported.
>
> > > > Could we lean on your generosity and expertise to simply allow webRTC
> > > > to accept8KhzInput.
>
> > > > That is what G711 reduces to anyway.
>
> > > > Parfavor
>
> > > > On Apr 24, 1:26 am, Henrik Andreasson <henr...@webrtc.org> wrote:
>
> > > > > I am unable to dive deeper into the details on this topic at this
> > > stage but
> > > > > it is evident that the input audio issue on OS X 10.x are well known.
> > > See
> > > > > the links below for more details.
>
> > > > >http://forums.macrumors.com/showthread.php?t=1312982https://discussio.
> > > ..
>
> > > > > With the current WebRTC design; it is up to the user to set a
> > > suitable, and
> > > > > supported, rate for input and output.
>
> > > > > On Tue, Apr 24, 2012 at 1:23 AM, ak <starlo...@gmail.com> wrote:
> > > > > > Thank you for your prompt response and audio tut.
>
> > > > > > What other option is there for G711 (8Khz) when interworking with the
> > > > > > PSTN? Practically no gateway out there suports broader band on the
> > > > > > interconnect and transcoding from iSAC still results in lower quality
> > > > > > audio since the limiting factor is on the legacy PSTN side.
>
> > > > > > Also what I am asking is why webRTC cannot simply attempt opening the
> > > > > > device at a supported rate? Surely 16Khz would be a good starting
> > > > > > point?
>
> > > > > > Would that be a simple fix versus supporting8Khzdirectly and what
> > > > > > kind of expectation could we have for an ETA on resolving this? Our
> > > > > > application is stalled because clearly one cannot get users to mess
> > > > > > with Audio Driver Settings.
>
> > > > > > A.
>
> > > > > > On Apr 23, 11:42 am, Henrik Andreasson <henr...@webrtc.org> wrote:
> > > > > > > Thanks for the detailed input. I'll ensure that we handle this
> > > scenario
> > > > > > in
> > > > > > > a better way than today.
> > > > > > > It is a rather surprising behavior if I may say so.
>
> > > > > > > See more detailed answer inlined below:
>
> > > > > > > On Mon, Apr 23, 2012 at 7:46 PM, ak <starlo...@gmail.com> wrote:
> > > > > > > > Henrik
>
> > > > > > > > Yes exactly what is happening. Leaving the Audio Midi Setup
> > > utility
> > > > > > > > open and restarting with the "Reopen windows on login" option
> > > checked
> > > > > > > > one can actually see the sampling rate switch back (from say
> > > 44.1Khz
> > > > > > > > manually set) to8Khz.
>
> > > > > > > > Have tested 5 different Mac OS X Lion machines (Macbooks ... Mac
> > > > > > > > Air ... OS X 10.6.8 ... 10.7.3) and all exhibiting the same
> > > behavior.
>
> > > > > > > > Bizarre.
>
> > > > > > > > Also forgive my limited understanding regarding Audio/Codecs
> > > however
> > > > > > > > my questions:
>
> > > > > > > > 1. Surely webRTC (or any app) can request I/O at any supported
> > > rate?
> > > > > > > > Why is webRTC simply accepting the default and failing to INIT
> > > because
> > > > > > > > the default is not on the webRTC list when the device clearly
> > > does
> > > > > > > > support the higher standard sampling rates (16 32 4.11 48 88.2
> > > 96)?
>
> > > > > > > The exact answer varies depending on the platform but in short;
> > > you can't
> > > > > > > set any possible sample rate (e.g. 192kHz) and expect it to work
> > > today.
> > > > > >  In
> > > > > > > your list above, 88.2 is not supported.
>
> > > > > > > > 2. On using narrowband speech (G711 @8Khz) the System Audio OUT
> > > shows
> > > > > > > > 44.1Khz. What is the difference between the hardware and codec
> > > rate?
> > > > > > > > Where does the sampling rate conversion happen? Is that a
> > > function of
> > > > > > > > the device driver itself?
>
> > > > > > > WebRTC does the resampling and adjust the sample rate after
> > > decoding to
> > > > > > > match the audio layer.
> > > > > > > WebRTC queries the audio layer for its native rate and adjusts
> > > > > > accordingly
> > > > > > > to match it. This statement holds for most native rates.
>
> > > > > > > > 3. Surely such a "critical" INIT error should bubble up to the
> > > UI?
> > > > > > > > Does getUserMedia return the error? All the demo apps simply
> > > hang.
>
> > > > > > > The current implementation does not feed this type of error up to
> > > the UI
> > > > > > > today, or to getUserMedia.
> > > > > > > I will ensure that the demo application does not hang.
>
> > > > > > > > Lastly while8Khzwould degrade performance using G711 is at the
> > > lower
> > > > > > > > sampling spectrum anyway and right now there is no performance :)
>
> > > > > > > The default codec selected in WebRTC is iSAC 16kHz.  There is a
> > > clear QoS
> > > > > > > improvement between iSAC and G.711. Your perceived QoS will be
> > > > > > > reduced substantially if8kHzis used as capture rate.
>
> > > > > > > > A.
>
> > > > > > > > On Apr 23, 12:03 am, Henrik Andreasson <henr...@webrtc.org>
> > > wrote:
> > > > > > > > > I am a bit confused here. Are you saying that the format you
> > > set for
> > > > > > the
> > > > > > > > > microphone is overwritten by the OS at each restart? Does the
> > > same
> > > > > > thing
> > > > > > > > > happen for a USB headset?
>
> > > > > > > > > WebRTC requires at least  16kHz sample rate to support e.g.
> > > iSAC
> > > > > > which
> > > > > > > > is a
> > > > > > > > > wideband (fs=16kHz) speech codec. Allowing8kHzwill reduce the
> > > > > > > > performance
> > > > > > > > > substantially.
>
> > > > > > > > > On Mon, Apr 23, 2012 at 12:21 AM, ak <starlo...@gmail.com>
> > > wrote:
> > > > > > > > > > FYI Issue Tracker #437:
>
> > > > > > > > > > Currently we fail to initialize if either the playout or
> > > recording
> > > > > > > > > > side uses a non-supported sampling rate. For playout we
> > > support
> > > > > > > > > > {96000, 44100,48000} and for recording we support
> > > > > > > > > > {96000,48000,44100,32000,16000}.
>
> > > > > > > > > > On Apr 22, 3:15 pm, ak <starlo...@gmail.com> wrote:
> > > > > > > > > > > Hi
>
> > > > > > > > > > > Mac OS X Lion appears to default the built in audio device
> > > > > > sampling
> > > > > > > > to
> > > > > > > > > > >8Khzand this breaks the peerconnection factory. Even if one
> > > > > > manually
> > > > > > > > > > > sets the sampling to a supported rate (eg: 44.1Khz) on
> > > > > > restarting the
> > > > > > > > > > > Mac the system resets it back to8Khz.
>
> > > > > > > > > > > There are no other applications accessing audio on System
> > > > > > Restart.
>
> > > > > > > > > > > Is there any reason8KHzsampling rate is not included in
> > > your
> > > > > > Input
> > > > > > > > > > > Device Selection?
> > > > > > > > > > > Without it webRTC is dysfunctional in OS X Lion.
>
> > > > > > > > > > > Thanks.
> > > > > > > > > > > A
>
> > > > > > [1457:-1397779776:15521853857370:VERBOSE3:webrtcvoiceengine.cc(321)]
> > > > > > > > > > > WebRtcVoiceEngine::Init
>
> > > > > > [1457:-1397779776:15521853936044:VERBOSE2:webrtcvoiceengine.cc(341)]
> > > > > > > > > > > Init() failed, err=10028
>
> > > > > > [1457:-1397779776:15521853955435:VERBOSE1:webrtcvoiceengine.cc(326)]
> > > > > > > > > > > WebRtcVoiceEngine::Init failed
>
> > > > > > [1457:-1397779776:15521853967846:VERBOSE3:webrtcvoiceengine.cc(414)]
> > > > > > > > > > > WebRtcVoiceEngine::Terminate
>
> > > > > > [1457:-1397779776:15521864488484:VERBOSE3:webrtcvideoengine.cc(383)]
> > > > > > > > > > > WebRtcVideoEngine::~WebRtcVideoEngine
>
> > > [1457:-1397779776:15521875309974:ERROR:media_stream_impl.cc(469)]
> > > > > > > > > > > Could not create PeerConnection factory