Discussion:
(no subject)
(too old to reply)
Olivier S.
2018-06-17 17:49:39 UTC
Permalink
Hi Ross,

The rounding does make a difference on macOS: if the value is floored, then
we get one frame less than we could expect according to the doc.

Here is the commit where I document the bug in my application, where I
needed a buffer size that was a multiple of 16, and how I took it into
account by adding an epsilon to the suggested latency I passed to the api
(else, I would get one frame less):

https://github.com/OlivierSohn/cpp.audio/commit/ca0ba602bb142620b7395d681d3ac05c5761a9a0

I agree with you that on some implementations, other factors are to be
taken into account to compute the final size. However, if here we floor
instead of ceil, there is no way we get the information back later, and the
implementation doesn't do what the spec says.

Olivier


Date: Sun, 17 Jun 2018 18:09:25 +1000
From: Ross Bencina <rossb-***@audiomulch.com>
To: Portaudio Mailing List <***@music.columbia.edu>
Subject: Re: [Portaudio] [Doc] Suggested latency interpretation
Message-ID: <70157c22-d08e-54ef-09f5-***@audiomulch.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Olivier,

In principle I agree that the documentation should be aligned with the
implementations. However I'm not sure that there is a problem. You cite
UInt32 suggestedLatencyFrames = inputParameters->suggestedLatency *
sampleRate

In general, this value is used as input to additional heuristics that
take framesPerBuffer and native API buffer size parameters into account
and *then* round-up. So the truncation in the above line makes little or
no difference to the final rounding-up.

In other words "suggestedLatencyFrames" is not typically the "next
practical value" that the documentation is referring to.

Ross.
Hello,
https://app.assembla.com/spaces/portaudio/tickets/realtime_list?ticket=276
I write this mail because I opened the ticket as an anonymous user, so
if needed I can clarify /discuss the issue.
Thanks,
Olivier
Ross Bencina
2018-06-18 15:02:33 UTC
Permalink
Hi Olivier,

That still sounds wrong. What value are you passing for framesPerBuffer?

Ross.
Post by Olivier S.
Hi Ross,
The rounding does make a difference on macOS: if the value is floored,
then we get one frame less than we could expect according to the doc.
Here is the commit where I document the bug in my application, where I
needed a buffer size that was a multiple of 16, and how I took it into
account by adding an epsilon to the suggested latency I passed to the
https://github.com/OlivierSohn/cpp.audio/commit/ca0ba602bb142620b7395d681d3ac05c5761a9a0
I agree with you that on some implementations, other factors are to be
taken into account to compute the final size. However, if here we floor
instead of ceil, there is no way we get the information back later, and
the implementation doesn't do what the spec says.
Olivier
Date: Sun, 17 Jun 2018 18:09:25 +1000
Subject: Re: [Portaudio] [Doc] Suggested latency interpretation
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Olivier,
In principle I agree that the documentation should be aligned with the
implementations. However I'm not sure that there is a problem. You cite
 > UInt32 suggestedLatencyFrames = inputParameters->suggestedLatency *
sampleRate
In general, this value is used as input to additional heuristics that
take framesPerBuffer and native API buffer size parameters into account
and *then* round-up. So the truncation in the above line makes little or
no difference to the final rounding-up.
In other words "suggestedLatencyFrames" is not typically the "next
practical value" that the documentation is referring to.
Ross.
Hello,
https://app.assembla.com/spaces/portaudio/tickets/realtime_list?ticket=276
<https://app.assembla.com/spaces/portaudio/tickets/realtime_list?ticket=276>
I write this mail because I opened the ticket as an anonymous user, so
if needed I can clarify /discuss the issue.
Thanks,
Olivier
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Loading...