At Thu, 08 Nov 2007 11:27:42 +0300, Stas Sergeev wrote: > > Hello. > > Takashi Iwai wrote: > >> OK then. The race will have to wait > >> till I get to it hard and (in case > >> there really is) produce a patch. > > Yeah, a testcase is required to reproduce the bug anyway. > No, the race doesn't have a test-case - > it gives underruns only when I rapidly > switch the consoles... Anyway, let's > wait till I get to it. The latency via console-switching is a long known problem in the kernel. It's likely irrelevant with the sound system itself. > > Well, I object it - as far as I know (through hundreds of SUSE > > package I've been maintaining), most of them write the period_size > > data at once. Writing arbitrary size is rather minor. > OK, thanks for info - I'll see about > enlarging my test-suit. > > >> mpg123: > >> ogg123: > > Both are for libao. > Hmm, my mpg123 is not from libao, only > ogg123 is. And mpg123 doesn't suffer an > underruns therefore, but it is affected > by a few other problems I mentioned. Ah, OK, I thought it'g mpg321. OK, I forgot about mpg123 supporting ALSA. > > The normal apps are more careful about the write timing and sync with > > GUI. So they tend to write the data at the time poll permits, instead > > of dumb write sequence relying on blocking mode. Maybe this is the > > key to get or avoid the bug. > OK, I'll try aplay later and post back. > > > The difference seems to be whether you do simply writei() sequences > > without checks which causes partial writes and eventually triggers the > > hack. > No, its not that simple. Or at least in > my theory. :) The rounding error I was > pointing into, causes the following: > - the app writes a full period. > - the rate plugin converts it to the > slave period, which has a different > size. > - because of the rounding errors, that > slave period is not filled properly - > it is either slightly underfilled, or > overfilled (and the subsequent period is > started). That triggers the hack. > Does this look realistic or not? Not really. It checks appl_ptr of the client, not hw_ptr. appl_ptr is what app writes. So, as long as app writes only the period size, the hack isn't triggered. > > As mentioned, many apps do check the available spaces before > > write, so the partial write doesn't happen practically. > I don't think this will help, but I'll > check with aplay later. > > > No, what I meant is that the app should check always the return value > > of the write properly. Even in the blocking mode, write *may* return > > without writing the whole data. Well, it's off-topic right now. > I know that, but I can't follow the > logic. If write returns earlier, then > the app will have to do the partial > write next time, so you loose the > alignment. So by saying that, you > basically say that the arbitrary writes > are unavoidable, and so I can't follow > the logic. The app can wait via poll until the period size becomes available. In that way, partial write can be avoided practically. > > I'm not satisfied because I have no testcase to reproduce the > > practical bug. The patch looks fine, but I cannot test it because the > > serious bug doesn't occur to me. OK? That's why I claim a testcase. > I'll try to help with that, but I don't > think this will be successfull (and > you should try my asound.conf first). > But we always can ask someone else > with the problem to test the patch, > right? I don't think there is a shortage > of such people - google makes me to beleive > so. Sorry, no, testing the patch with specific apps alone isn't enough in this case. If the problem persists only with two-period cases, the real fix is to change the hw_refine in rate plugin not to allow periods <= 2 for unaligned sample rates, because two periods don't work anyway. Then a non-working configuration wouldn't be allowed instead of jerky sounds. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
