[alsa-devel] [PATCH 1/4] ALSA: x86: Don't pass SNDRV_PCM_INFO_BATCH flag

[Takashi Iwai]

On Sat, 04 Feb 2017 00:13:49 +0100,
Pierre-Louis Bossart wrote:
> 
> 
> 
> On 02/03/2017 02:13 PM, Takashi Iwai wrote:
> > On Fri, 03 Feb 2017 20:39:49 +0100,
> > Pierre-Louis Bossart wrote:
> >> On 2/3/17 10:43 AM, Takashi Iwai wrote:
> >>> The PCM engine on LPE audio isn't like a batch-style process, but
> >>> rather it deals with the standard ring buffer.  Passing the BATCH info
> >>> flag is inappropriate.
> >> Humm, this is controversial. There are 4 DMA descriptors and getting a
> >> precise position in the stream is not straightforward.
> > Well, as far as I've tested, it is.  The buffer length register keeps
> > the remaining bytes, and you can easily read out and compute the
> > current position in fairly exact manner.  Even the old driver has that
> > information -- the patch David added does it.
> Yes, and I don't think anyone on the Intel side quite understood what
> David did there. The code didn't seem quite right.

The David's code should be mostly OK.  It just reads the length buffer
register that keeps the remaining bytes on the current BD.

The only doubtful part in the original code is the handling when it
reads zero or -1 from the length register.  It tries to ignore for a
couple of times.  The zero read-back may actually happen at any time,
and actually it means that we've missed one irq handling.  OTOH, a
negative value must not happen, and it means some serious hardware
issue, and we should stop streaming at this point.

> >> Rewind is also
> >> not supported so if you remove the BATCH flag you will push PulseAudio
> >> into doing timer-based scheduling and rewinds that probably don't
> >> work.
> > I don't think there is much difference regarding this.
> > Please check the buffer manage description in my previous post
> We've never tested the hardware in those configurations so I'd like a
> bit more time to double check how well this might work. None of us has
> a clear view of how much buffering and pre-fetch is done by the DMA
> engine so if you rewind 'too much' you may be out of luck.

Right, that's unclear part, especially for me without any hardware
datasheet ;)


> > In anyway, it'd be appreciated if you can test on your hardware.
> > I could test only on a single machine.
> I can test more but only in 10 days from now so if we could delay this
> patch a bit it'd be better.

OK, I can postpone this change and keep BATCH and DOUBLE.


thanks,

Takashi