Discussion:
[Portaudio] Portaudio Digest, Vol 36, Issue 3
Olivier S.
2018-06-18 16:22:11 UTC
Permalink
I pass paFramesPerBufferUnspecified for framesPerBuffer:

"The special value paFramesPerBufferUnspecified (0) may be used to request
that the stream callback will receive an optimal (and possibly varying)
number of frames based on host requirements and the requested latency
settings."

Olivier
Date: Tue, 19 Jun 2018 01:02:33 +1000
Subject: Re: [Portaudio] (no subject)
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Olivier,
That still sounds wrong. What value are you passing for framesPerBuffer?
Ross.
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
------------------------------
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
End of Portaudio Digest, Vol 36, Issue 3
****************************************
Ross Bencina
2018-06-30 05:58:07 UTC
Permalink
Hello Olivier,

It remains unclear what you're trying to do.

It sounds to me like you are passing paFramesPerBufferUnspecified as
framesPerBuffer, but then trying to use suggestedLatency to get a fixed
buffer size. Is that correct?

If so, that is not correct use of the API. The suggestedLatency
parameters should never be used to try to get a specific callback buffer
size. They are just hints.

To get a specific buffer size, pass a specific value to framesPerBuffer,
or use one of the host-api-specific interfaces for controlling buffer size.

That said, there may still be a bug, but you would need to demonstrate
the bug with framesPerBuffer set to some value other than
paFramesPerBufferUnspecified.

Ross.
Post by Olivier S.
"The special value paFramesPerBufferUnspecified (0) may be used to
request that the stream callback will receive an optimal (and possibly
varying) number of frames based on host requirements and the requested
latency settings."
Olivier
Date: Tue, 19 Jun 2018 01:02:33 +1000
Subject: Re: [Portaudio] (no subject)
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Olivier,
That still sounds wrong. What value are you passing for framesPerBuffer?
Ross.
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
<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>
<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
<https://lists.columbia.edu/mailman/listinfo/portaudio>
------------------------------
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
<https://lists.columbia.edu/mailman/listinfo/portaudio>
End of Portaudio Digest, Vol 36, Issue 3
****************************************
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Loading...