Re: Specifying the audio buffer size

+1

On Fri, May 22, 2015, 2:04 PM Peter Thatcher <pthatcher@google.com> wrote:

> FYI, having read through this thread and being I assigned the task of
> finding a resolution, I put in as the proposed resolution for LC-3022 (
> https://www.w3.org/2006/02/lc-comments-tracker/47318/WD-mediacapture-streams-20150414/3022)
> the following:
>
>
> Add the following to the spec:
>
> enum SupportedAudioConstraints {
>     "latency"
> };
>
> dictionary MediaTrackConstraintSet {
>   ConstrainDouble latency;  // seconds
> };
>
>
> I think this represents the consensus on this thread.
>
> On Fri, May 15, 2015 at 6:12 AM, Joe Berkovitz <joe@noteflight.com> wrote:
>
>> A few points with respect to the recent additions to this thread:
>>
>> 1. Use seconds. Otherwise constraint queries will return results that are
>> not comparable in terms of user experience, due to sample rate differences
>> between devices. I already pointed out that sample rates in other parts of
>> an audio application may not be equal to the native sample rate of a device.
>>
>> 2. I agree that something like minimum or "typical" latency is of more
>> interest than a maximum or guarantee. The idea is for applications to
>> understand that a particular device may have high latency that is imposed
>> by the stack, not that it might have some unknown potential for high
>> latency.
>>
>> 3. Some devices may impose latency that has nothing to do with buffering
>> in the UA stack or its host OS, but are external in nature. For instance
>> remote-cast audio output devices like Chromecast and AppleTV have a very
>> long lag. I don't see that it makes sense to think of such latency in terms
>> of sample frames. That isn't like the latency values one sees in, say, ASIO
>> driver configuration (which are typically expressed in terms of buffer
>> size, but only because they reflect a world entirely internal to the
>> driver).
>>
>> ...Joe
>>
>>
>> On Fri, May 15, 2015 at 6:33 AM, Harald Alvestrand <harald@alvestrand.no>
>> wrote:
>>
>>> Interesting - I'd completely forgotten about sampleRate and sampleSize.
>>>
>>> sampleSize is in bits and defined only on linear-sampling devices, so
>>> it's likely to be 8, 16 or 24.
>>>
>>> sampleRate is usually 8000, 16000, 44100 or 48000 (192000 at the
>>> extreme).
>>>
>>> So both these refer to a single audio sample; latency and sampleCount
>>> would be completely equivalent:
>>>
>>>   latency = sampleCount / sampleRate
>>>   sampleCount = latency * sampleRate
>>>
>>> But if the user specifies sampleCount without specifying sampleRate, he
>>> might get a completely different latency from what he wanted; it seems
>>> unlikely that the user's tolerance for latency would increase with worse
>>> sound quality.
>>>
>>> What does the user care about?
>>>
>>> Den 14. mai 2015 03:41, skrev Jonathan Raoult:
>>> > Sorry guys I just jumped in this thread.
>>> >
>>> > I'm very interested in this discussion specially on the low latency
>>> > side. I recently hit the "optimum buffer size for everyone" wall with
>>> > getUserMedia  and I would need something to adjust latency on capable
>>> > platform at least.
>>> >
>>> > What I noticed in music creation softwares (and other audio API as
>>> well)
>>> > is the use of frame count as input to adjust latency. Then the result
>>> in
>>> > ms calculated but only for display purposes. It would fit well with
>>> > sampleRate and sampleSize from MediaTrackSettings which are already low
>>> > level enough for the user to infer the latency in ms. It also have the
>>> > advantage of being precise, there not rounding or calculation to make
>>> > for the implementation.
>>> >
>>> > So to come back to the example, something like that is another
>>> solution:
>>> >
>>> > { sampleCount: { max: 20 } }
>>> >
>>> > Jonathan
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>
>>
>> --
>> .            .       .    .  . ...Joe
>>
>> *Joe Berkovitz*
>> President
>>
>> *Noteflight LLC*
>> 49R Day Street / Somerville, MA 02144 / USA
>> phone: +1 978 314 6271
>> www.noteflight.com
>> "Your music, everywhere"
>>
>
>