'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/]
