Colin Guthrie wrote on 20.06.2011 16:35:
> If no timing information has been recieved yet this call will return
> PA_ERR_NODATA. For more details see pa_stream_get_timing_info().
> </quote>
>
> So I think this is valid in the initial stages - i.e. until the buffer
> playback has actually started.
>
> Otherwise such a return value could indicate a corrupted read or write
> index.
Maybe I misunderstand something, but I thought that if I create and
start a stream that does not automatically update the timing info (ie
PA_STREAM_AUTO_TIMING_UPDATE flag is not set) and I never call
pa_stream_update_timing_info, than any call to
pa_stream_get_timing_info or pa_stream_get_latency should always return
PA_ERR_NODATA? At least that is what the doxygen documentation for
pa_stream_get_timing_info says...
>
>> Otherwise, I'm not sure if the reported data is really wrong. If I use
>> the periodic measurements the reported latencies won't go below 70-100ms
>> here. This seems quite much, even for an onboard sound, doesn't it?
>
> How are you trying to reduce the latencies? By changing your buffer
> metrics? Mine can go down to ~16ms ish quite happily here for some
> clients (from observation rather than anything more scientific)
Well the code that creates the stream looks something like this:
pa_buffer_attr battr = {(uint32_t) -1, (uint32_t) -1, (uint32_t) -1,
(uint32_t) -1, (uint32_t) -1};
pa_stream_flags_t streamflags = PA_STREAM_FAIL_ON_SUSPEND |
PA_STREAM_ADJUST_LATENCY |
PA_STREAM_INTERPOLATE_TIMING |
PA_STREAM_AUTO_TIMING_UPDATE;
battr.tlength = pa_usec_to_bytes( latency * 1000, &sspec );
// latency is the requested latency in milliseconds
pa_stream_connect_playback(stream, 0, &battr, streamflags, 0, 0);
No matter how small I set the latency variable, measured latencies never
go below 70ms.
>
> Col
>
