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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
