I definitely agree Edward. For a good user experience a 3rd party _must_
know this information. I don't want to apply our apo on every stream.
That's what we are forced to do now. The apo processing we are employing
requires a significant amount of resources. Knowing the specific
application would allow us to seamlessly integrate.
On Wed, Apr 28, 2021, 11:48 AM <edwabr123@xxxxxxxxx> wrote:
The Lync and other specs are constructed to provide signal optimal for
voice processing algorithms such as AEC, Noise canceling etc. Other streams
may have or sometimes need to have enhancements such as multiband
compression, surround, voice clarity, virtual bass, etc. So, it’s not
‘cheating’ but complying to different requirements of different modes.
I don’t see a danger to have info on the stream source to be able to apply
an appropriate processing unless you want a single processing mode for
*From:* wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx>
*On Behalf Of *Tim Roberts
*Sent:* Wednesday, April 28, 2021 9:40 AM
*Subject:* [wdmaudiodev] Re: [EXTERNAL] Detecting the app that sent the
audio stream in an APO
I support this request since voice apps need a specific processing applied
in APO to be compliant with e.g. Lync spec.
But at what point does that cross the line into cheating? The Lync specs
were (presumably) carefully constructed to provide an optimal signal for
video conferencing. So, wouldn't you want to do that processing for every
video conferencing app?
It seems to me a dangerous slippery slope to have "Zoom" mode and "Skype"
mode and "Lync" mode and "Teams" mode and "WHQL" mode.
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.