At Fri, 20 Feb 2009 21:34:17 +0100, Lennart Poettering wrote: > > On Fri, 20.02.09 08:26, Takashi Iwai (tiwai@xxxxxxx) wrote: > > > > Yes, I am. But ignore that part for now. I have now commented the use > > > of that call. Now I certainly get more POLLOUTs as expected, but the > > > real problem stays: after a few minutes _avail() will suddenly jump > > > from next to zero to more then the hwbuf size in less than 1ms without > > > any further inteference and with a buffer size of 350ms! There is > > > something really wrong with the behaviour of _avail(). > > > > > > I can reproduce this only on ens1371 for now. > > > > The ens1371 driver itself is damn simple. The pointer callback just > > returns the read value. So, it implies that it's basically a hardware > > issue. > > > > Does the patch below have any influence? > > No. It doesn't appear to have any effect whatsoever. Still, from time > to time the value returned by _avail() is off by once the buffer size, > sometimes upwards, sometimes downwards. > > Moreover I can now reproduce the same issue on snd-intel8x0, albeit it > takes more than a couple of minutes to make snd_pcm_avail() return > bogus data. > > Somehow I get the feeling the problem is not so much the inaccuracy of > the pointer the kernel reports but in what alsa-libs does ith it. Hrm... both cases the pointer calculation is relatively simple, and for "hw" PCM, the avail calculation is also very straightforward. So, my first suspect is about the pointer calculation. But, of course we should check all possibilities. Can you give a small testcase? thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
