Kevin Mescher wrote: > > The application sent data synchronously to the audio device, and used the > sample count (accessed via Solaris' info.play.samples) to determine > where to > put the marker on its waveform display. It was pretty simple, and the > logic > went: The equivalent of info.play.samples is pa_stream_get_time(). Note the comments about it though: /** 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_MONOTONOUS. 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'. \since 0.6 */ > > if there are less than 1000 samples remaining to be played (samples sent - > the value of info.play.samples), send more data. > Now this is a bad model. 1000 samples is just 23 ms at 44100 Hz, a delay that is easily achievable on a network. Rgds -- Pierre Ossman OpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20070213/e0153a6b/attachment.pgp>
