[alsa-devel] [PATCH 1/4] ALSA: x86: Don't pass SNDRV_PCM_INFO_BATCH flag
Takashi Iwai
tiwai at suse.de
Mon Feb 6 22:51:50 CET 2017
On Mon, 06 Feb 2017 22:27:28 +0100,
Pierre-Louis Bossart wrote:
>
> On 2/6/17 1:01 PM, Takashi Iwai wrote:
> > On Sat, 04 Feb 2017 08:57:08 +0100,
> > Takashi Iwai wrote:
> >>
> >>>> 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.
> >
> > I've tested more intensively, and this seems working well, so far.
> > Hopefully the DMA FIFO or fetch timing doesn't play a big role.
>
> As I mentioned in the other email, the FIFO can be up to 512 bytes so
> beware. And it makes sense to limit the period size to 1024 bytes
> minimum.
Yes, I've examined this minimum by some trial-and-error, so it be set
now.
> > BTW, with the combination of this and the latest my PCM rewrite patch,
> > a more interesting experiment can be done: extend to (a kind of)
> > no-period-wakeup mode. Of course, it doesn't work like HD-audio, as
> > we can't the ring buffer persistently on LPE audio but have to refresh
> > the buffer descriptors. But the refresh of BDs is also done at PCM
> > pointer callback, so it would work as is. For supporting the case
> > period=1, though, another trick is needed: namely, we set up 4 BDs
> > pointing to the same address, so that it won't go out to underrun.'
>
> Both the pseudo-no-period-wakeup and single period should work but I
> am not sure how useful this is.
The practical gain would be fairly small, I suppose. But it'd be nice
to have such a platform as a reference implementation.
Takashi
More information about the Alsa-devel
mailing list