On Fri, 2015-11-27 at 05:57 +0100, Georg Chini wrote: > On 27.11.2015 04:46, Tanu Kaskinen wrote: > > On Thu, 2015-11-26 at 20:36 +0100, Georg Chini wrote: > > > On 26.11.2015 18:47, Tanu Kaskinen wrote: > > > > On Thu, 2015-11-26 at 08:41 +0100, Georg Chini wrote: > > > > > On 26.11.2015 01:49, Tanu Kaskinen wrote: > > > > > > And what does this have to do with increasing the latency on underruns? > > > > > > If you get an underrun, then you know buffer_latency is too low, so you > > > > > > bump it up by 5 ms (if I recall your earlier email correctly), causing > > > > > > the configured total latency to go up by 5 ms as well. As far as I can > > > > > > see, the measured latency is not needed for anything in this operation. > > > > > > > > > > > > ---- > > > > > > > > > > > > Using your example (usb sound card with 4 * 5 ms sink and source > > > > > > buffers), my algorithm combined with the alsa source optimization > > > > > > yields the following results: > > > > > > > > > > > > configured sink latency = 20 ms > > > > > > configured source latency = 20 ms > > > > > > maximum source buffer fill level = 5 ms > > > > > > buffer_latency = 0 ms > > > > > > target latency = 25 ms > > > > > > > > > > > > So you see that the results aren't necessarily overly conservative. > > > > > That's different from what you proposed above, but sounds > > > > > like a reasonable approach. The calculation would be slightly > > > > > different because I defined buffer_latency = 5 ms on the > > > > > command line. So the result would be 30 ms, which is more > > > > > sensible. First we already know that the 25 ms won't work. > > > > > Second, the goal of the calculation was to find a working > > > > > target latency using the configured buffer_latency, so you > > > > > can't ignore it. > > > > > My calculation leads to around 27.5 ms instead of your 30 ms, > > > > > so the two values are near enough to each other and your > > > > > proposal has the advantage of being constant. > > > > > > > > > > I will replace the average sum by > > > > > 0.25 * configured_source_latency + configured_sink_latency. > > > > > in the next version if my tests with that value are successful. > > > > Do you mean that you're going to use 0.25 as the multiplier regardless > > > > of the number of fragments? > > > > > > > > Previously I've been saying that in the general case the target latency > > > > should be "configured source latency + buffer_latency + configured sink > > > > latency". To generalize the alsa source exception, I'll use the > > > > following definition instead from now on: "target latency = maximum > > > > source buffer fill level + buffer_latency + maximum sink buffer fill > > > > level". Usually the maximum fill levels have to be assumed to be the > > > > same as the configured latencies, but in the interrupt-driven alsa > > > > source case the maximum fill level is known to be "configured source > > > > latency / fragments". > > > OK, now I finally got you. That has taken quite a bit, sorry. > > Yay! Thanks for not getting too frustrated to continue the discussion. > > > > > Let me summarize: > > > > > > - The minimum achievable latency is maximum source fill + maximum sink fill > > > - The sink maximum fill level is always 100%, regardless of the device type > > > - The source maximum fill level depends on device type > > > Â Â Â Â Â # For interrupt driven alsa sources it is one default-fragment-size > > > Â Â Â Â Â # For timer-based alsa devices it is 50% of the configured latency > > > Â Â Â Â Â # For the general case it is unknown and may be 100% > > > > > > Do we have an agreement so far? > > Where does that 50% come from for timer-based sources? The timer logic > > works so that the source sleeps until the buffer is (almost) full. > > The 50% comes from our discussion why I only see 1/3 of the > configured latency for source + sink when I configure both to > be 1/3. There you said the maximum source buffer fill level would > be 50%. I thought you referred to a more or less general case > because that is what I see not only for batch cards but for HDA > as well. It also matches with with my experience (and with some > quick experiments I did yesterday when I understood what you > meant). I don't remember saying that the maximum buffer fill level would be 50%. I said that the maximum *measured* buffer fill level is 50%, I guess you're referring to that. When the "get latency" message is processed, the source first pushes out all data in the buffer if the fill level is above 50%, and only then measures the latency, which is why you never see values above 50% in the measurements. -- Tanu
