[pulseaudio-discuss] Async API - need some help

[Colin Guthrie]

'Twas brillig, and Zeno Endemann at 20/06/11 14:18 did gyre and gimble:
> Tanu Kaskinen wrote on 19.06.2011 12:18:
>>> Should I file a bug report for the latency thing?
>>
>> Yes, please.
> 
> I investigated this a little bit more. First of all, if there is no data
> available, it seems that pa_stream_get_latency returns -PA_ERR_NODATA
> (notice the sign). This should be trivial to fix.

Here is what the doxygen docs say about the PA_ERR_NODATA return value
(it's the same for get_latency).

Pay particular attention to the last paragraph.

<quote>

int pa_stream_get_time 	( 	pa_stream *  	s,
		pa_usec_t *  	r_usec
	) 		

Return the current playback/recording time.

This is based on the data in the timing info structure returned by
pa_stream_get_timing_info().

This function will usually only return new data if a timing info update
has been recieved. Only if timing interpolation has been requested
(PA_STREAM_INTERPOLATE_TIMING) the data from the last timing update is
used for an estimation of the current playback/recording time based on
the local time that passed since the timing info structure has been
acquired.

The time value returned by this function is guaranteed to increase
monotonically. (that means: the returned value is always greater or
equal to the value returned on the last call). This behaviour can be
disabled by using PA_STREAM_NOT_MONOTONIC. This may be desirable to deal
better with bad estimations of transport latencies, but may have strange
effects if the application is not able to deal with time going 'backwards'.

The time interpolator activated by PA_STREAM_INTERPOLATE_TIMING favours
'smooth' time graphs over accurate ones to improve the smoothness of UI
operations that are tied to the audio clock. If accuracy is more
important to you you might need to estimate your timing based on the
data from pa_stream_get_timing_info() yourself or not work with
interpolated timing at all and instead always query on the server side
for the most up to date timing with pa_stream_update_timing_info().

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.



> 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)

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]