Olivier S.
2018-06-18 16:22:11 UTC
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
"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.
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
****************************************
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/
ca0ba602bb142620b7395d681d3ac05c5761a9a0The 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/
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.
realtime_list?ticket=276taken 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/
https://app.assembla.com/spaces/portaudio/tickets/
<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
_______________________________________________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
****************************************