[alsa-devel] PulseAudio and SNDRV_PCM_INFO_BATCH

[Takashi Iwai]

At Wed, 17 Jun 2015 10:27:08 +0200,
Lars-Peter Clausen wrote:
> 
> On 06/16/2015 04:33 AM, Raymond Yau wrote:
> >
> >  >> DMA_RESIDUE_GRANULARITY_DESCRIPTOR
> >  >> DMA_RESIDUE_GRANULARITY_SEGMENT
> >  >> DMA_RESIDUE_GRANULARITY_BURST
> >  >>
> >  >> Can this be regard as bad, normal and good accuracy ?
> >  >
> >  >
> >  > DMA_RESIDUE_GRANULARITY_DESCRIPTOR is more like completely and utterly
> > useless. It means the driver can only tell whether the descriptor has
> > finished or not, in a cyclic transfer the descriptor will never finish so
> > the driver will always report the same. Currently we fall back to counting
> > the number of period completion callbacks we get in this mode. This is
> > slightly prone to race conditions since it is legal to coalesce two
> > completion callbacks if a second one is scheduled before the first has run.
> > This will only happen with a very high system load, but it can happen.
> > Luckily most DMA drivers that are used for audio do support
> > DMA_RESIDUE_GRANULARITY_SEGMENT now and there is a deprecation plan,
> > including eventually stopping to support them altogether, for drivers that
> > only support DMA_RESIDUE_GRANULARITY_DESCRIPTOR.
> >  >
> >  >
> >  > DMA_RESIDUE_GRANULARITY_SEGMENT means the hardware/driver can report the
> > pointer position with a period precession. In this case the BATCH flag will
> > be set for the PCM.
> >  >
> >  > DMA_RESIDUE_GRANULARITY_BURST means it can report the position with a
> > granularity of a few samples. Typically half the audio FIFO size.
> >  >
> >  >
> >
> > Residue is updated after each transferred
> > *  burst. This is typically only supported if the hardware has a progress
> > *  register of some sort (E.g. a register with the current read/write address
> > *  or a register with the amount of bursts/beats/bytes that have been
> > *  transferred or still need to be transferred).
> >
> > The pointer callback of both snd-hda-intel and snd-oxygen are reading from
> > hardware register
> >
> > Do this mezn that only those driver which pointer callback read from
> > hardware register are suitable for timer schedluing ?
> 
> Yes, more or less, but not exclusively. The pointer callback needs to a have 
> a low enough precession for timer based scheduling to work. Where the 
> threshold is where it starts and stops to work is a bit hard to say. Period 
> based resolution is not good enough, a few samples based resolution is very 
> good. USB seems to be somewhere in the middle between those two, the 
> resolution is better then a full period, but more than just a few samples. 
> But it seems to be good enough for the timer based scheduling algorithm to 
> work. It still gets disabled for USB though since the USB driver stets the 
> BATCH flag.
> 
> The main issue is that there is currently no method for a driver to 
> advertise the exact pointer granularity to userspace applications. There is 
> either BATCH flag not set which means very good accuracy or BATCH flag set 
> which means very bad accuracy. USB which does not have a very good accuracy, 
> but still a reasonably good accuracy, is somewhere in the middle between 
> those two extremes.

Well, USB-audio has another problem.  USB-audio uses the intermediate
audio ring buffer, and the samples are copied to each URB buffer.  At
each packet complete, the driver copies the rest of sample chunk
again, and advances the hwptr when the packets.  So, the hwptr of
USB-audio is in advance of the actual sample position.  But we provide
the runtime delay information for user-space to correct to the more
accurate sample position.  So far, so good.

A missing piece in this picture is, however, the position of the
not-yet-queued samples in ring buffer.  Basically you can rewrite /
rewind the sample at most this point, but not farther -- such
in-flight samples can't be modified any longer.  This can be seen a
kind of hardware fifo with a pretty big and non-continuously variable
size during operation.

In that sense, get_fifo() looks like a candidate for giving such
information, indeed.  But reviving the old (and rather bad working)
API appears dangerous to me.  I'd prefer creating a new API function
instead, if any.

BTW, because of its design like above, a large (or no) period size
doesn't help for saving power at all with USB-audio.  This should be
considered before the further discussion...


Takashi