Discussion:
Portaudio Digest, Vol 36, Issue 8
(too old to reply)
Olivier S.
2018-06-30 11:29:08 UTC
Permalink
Hi Ross,

I'll try to clarify the context:

I use paFramesPerBufferUnspecified + latency suggestion because the
portaudio doc says that if we request a fixed buffer size, there may be an
additional latency due to portaudio having an internal buffer of that size,
and I don't want to have to pay for that additional latency.

Then passing paFramesPerBufferUnspecified, I know I should expect handling
any varying buffer size in the callback, this is exactly what the callback
does.

But, I also want to optimize cache use, hence I know which buffer size
would be optimal, and I'm trying to get that buffer size using the latency
setting.

And there is a bug here because the suggested latency setting says :

"Unless the suggested latency is greater than the absolute upper limit for
the device implementations should round the suggestedLatency up to the next
practical value"

But in practice, here, when used in conjunction with
'paFramesPerBufferUnspecified',
the suggested latency setting is rounded down instead of up. And this
behaviour is not mentioned in the doc, and it can be easily fixed to be
compliant with the existing doc (like explained in the bug report below).

I updated the wording of the bug report to be more specific about the fact
that this bug is about when paFramesPerBufferUnspecified is passed :
https://app.assembla.com/spaces/portaudio/tickets/realtime_list?ticket=276

Olivier
Date: Sat, 30 Jun 2018 15:58:07 +1000
Subject: Re: [Portaudio] Portaudio Digest, Vol 36, Issue 3
Content-Type: text/plain; charset=utf-8; format=flowed
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.
"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...