On 28.03.2016 16:16, Pierre-Louis Bossart wrote: > On 3/22/16 4:11 AM, Georg Chini wrote: >> Hi, >> >> when a sink is started, there is some delay before the first sample is >> really played. >> This delay is a constant part of the sink latency that will be always >> present, so the >> minimum sink latency cannot go below that start delay. >> Would it be acceptable to adjust the latency range for the device after >> each unsuspend >> to reflect that? >> USB devices (those I have access to) for example have a startup delay in >> the range of >> 10ms, but have a latency range that starts at 0.5ms which does not make >> a lot of sense >> in my opinion. >> The startup delay is not constant, so the minimum possible latency would >> vary. >> >> On the source side the startup delay is not relevant since it does not >> delay the signal. > > Sorry I missed this thread last week. > At the risk of being pedantic, maybe you should consider two different > concepts. > - cold latency: the time it takes for the audio device to render the > first sample when first opened > - continuous latency: the time it takes to hear a sample after it's > written to the ring buffer. > Yes, but it looks like the alsa USB driver assumes that a sample can be heard immediately after it left the buffer, which is not true. So there is some additional continuous latency that is not reported. This is visible as a "startup delay" - the time between the moment the first sample is written to the buffer and the moment when it is reported that the first chunk of audio has been played. > The cold latency is mostly what happens in the .prepare step at the > driver level. It's very hard to estimate by software since you can't > observe the analog output. It can also vary depending on platform states. Well, I can observe the analog output. In my setup I have an oscilloscope connected to input and output of the loopback, that is why I detected the difference between configured and real latency at all. > The ALSA driver tells you however when it started pushing samples out > after the .prepare step, the status.trigger_time value tells you what > your starting point should be. All the smoothers should start from > this value, not from the time you started pushing the samples in the sink. The observable latency is the time that it takes from pushing a sample into the sink to the moment it reaches the analog output. This is the same time for the first sample as for all following samples, see above. For the smoother itself you can use any arbitrary chosen time after the trigger_time as starting point, you only have to remember the number of frames that have already been played at that time. I experimented with using the start time supplied by the driver and could not see a significant advantage over the first approach. > The latency specified by PulseAudio is only related to the continuous > latency - the total buffering. There is no need to take the startup > delay into account as long as you use the trigger_time as your t0. > Some devices don't report trigger_time accurately but in the case of > USB there were patches to fix this last year, look for the subject > "ALSA: usb: update trigger timestamp on first non-zero URB submitted" The trigger_time tells you, when the first audio is submitted to the USB bus, but not when it really reaches the speakers. There is all that USB processing in between.
