On Wed, 2016-03-23 at 11:34 +0100, Georg Chini wrote: > On 23.03.2016 11:04, Tanu Kaskinen wrote: > > > > On Tue, 2016-03-22 at 12:57 +0100, Georg Chini wrote: > > > > > > On 22.03.2016 12:51, Tanu Kaskinen wrote: > > > > > > > > On Tue, 2016-03-22 at 12:33 +0100, Georg Chini wrote: > > > > > > > > > > On 22.03.2016 12:20, Tanu Kaskinen wrote: > > > > > > > > > > > > On Tue, 2016-03-22 at 10:11 +0100, 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. > > > > > > I don't understand why the startup delay would limit the minimum > > > > > > latency once the stream is flowing. Imagine a sound card that is > > > > > > powered by a nuclear power plant. I don't know how long it takes to > > > > > > start a nuclear power plant, but let's say it takes a couple of days. > > > > > > Now the sound card startup delay is a couple of days, but there's no > > > > > > reason that the audio latency has to be a couple of days once the power > > > > > > plant is running. Where would all that audio be buffered anyway? > > > > > > > > > > > Hi Tanu, > > > > > > > > > > you are wrong. > > > > I don't believe you :) > > > Look at the code of alsa-sink. It never drops samples. The only way to > > > compensate > > > for the startup delay would be to drop audio as long as the sink is not > > > yet playing, > > > but that is not done. I could try to implement that however and then you > > > would be > > > right, but with the current code at least for the alsa-sink the startup > > > delay will persist. > > The sink isn't responsible for dropping samples in any case. The > > connection between the start delay and the runtime latency just doesn't > > exist at the sink level. > Again, sorry, but you are wrong. The startup delay does not vanish > magically. I can only point you to the code. I have been working with it > for a couple of month now and I know what I am saying. What happens > for USB devices with timer based scheduling is the following: > > 1) First audio data is written to the card Ok, now the buffer is full. > 2) snd_pcm_start() is called > 3) More data is written to the card How is this possible? If the hardware hasn't consumed any audio yet, we won't write anything, because the buffer is full. If the hardware has consumed something, but nothing has come out of the speakers yet, then the hardware has the consumed audio buffered somewhere. > 4) The reported delay of the card goes up exactly by the amount that was > written > 5) This repeats a couple of times If nothing is still coming out of speakers, this indicates that the hardware reports the latency wrong, or our smoother is messing up the latency reports. AFAIK, if the hardware has a 10 ms buffer, that should be always included in what snd_pcm_delay reports. If it reports something less, it's a driver bug. > 6) The card starts playing after 10 -15ms > 7) Now there is some difference between the delay and the amount of data > written -- Tanu
