[alsa-devel] [PATCH - dmix v3 0/1] pcm: dmix: Align slave_hw_ptr to slave period boundary

[Takashi Iwai]

On Tue, 06 Nov 2018 17:15:31 +0100,
Timo Wischer wrote:
> 
> On 11/6/18 15:27, Takashi Iwai wrote:
> > I guess that the biggest issue is the understanding of PCM period
> > wakeup; let me cite the description of a part of your patch:
> >
> >   "But since 3 snd_pcm_period_elapsed(), 3 periods should be available
> >    and it should have been able to write.
> >    If rsnd_pointer during the start was 0x120 which is 3 periods
> >    then 0x248 - 0x120 =  128 it could go on with write."
> >
> > This assumption can't be applied.
> >
> > However, the current implementation of dmix is designed to achieve the
> > lowest latency by putting the data at the exact position being played
> > back now.  This, of course, doesn't guarantee the period wakeup = one
> > period free to fill like the above.  So it's the design choice.
> >
> > The current code has a workaround for the case of nperiods <= 2, by
> > setting the initial slave_appl_ptr to the next period start.  This
> > guarantees that the period wakeup = one period to be filled.  But its
> > cost is the start latency; the playback doesn't start immediately but
> > wait until the next period start.
> >
> >
> > Takashi
> 
> Thanks for this explanation. That helps me to understand.
> 
> Now, I am thinking about a solution to align the slave_hw_ptr and
> slave_appl_ptr to the slave_period (round down) only on start up.
> So we keep this low latency. (At start up it is the same behavior as
> known from old sound drivers)
> 
> As known from the past in worst case it will drop up to slave_period-1 
> frames.
> If the application uses big periods and the drop is not acceptable a
> small slave_period using the var_period feature could be configured.
> But I think it is also not acceptable for an application which is
> using really big periods to wait sometimes one period longer.

Well, which case is acceptable and which isn't -- we can't define it
in our side so easily.  This really depends on how the application is
written and how the hardware setup is.

For example, imagine to play a very short beep sound with dmix.
Dropping samples (at most period-1 size) may result in silence, and
that's not acceptable.

> There is always a higher probability of an under run whenever a poll()
> wakeup will not result in a write.
> For example on systems with high load this could be an issue.
> 
> If you are anyway not happy with this solution may be we can think
> about an option to disable this feature
> like "min_drop_on_start true"
> But then we also should describe the drawbacks of this option like
> * Delay of snd_pcm_wait() up to 2*periods
> * Higher probability of Xruns

This probably depends on how many periods are present on the buffer.
For the standard PC onboard sounds, 16 periods are used as default,
and that's enough for avoiding xruns for normal applications.

I guess we may provide an option for choosing one of the following
modes:

- current default mode;
  no latency, but wakeup may be delayed, and may require 2*periods

- appl_ptr round up to the next period;
  the current workaround for periods <= 2.
  This imposes the start latency.

- round down to the current period start;
  No latency, but will drop a few samples at start.

... and ideally, provide a mode "auto" for choosing the appropriate
one depending on the situation by a smart guess.


thanks,

Takashi