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.
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.
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?
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.
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.