Hello.
Takashi Iwai wrote:
But still not exactly sure whether it's the same as you've got. It's no good testcase after all, you see?
OK, I'll see what can be done about a test-case. But it can't be made immediately. Maybe this week-end.
You didn't set the slave period_size and periods properly in your configuration. This defines periods=2 eventually.
That's what the program did, I simply have not made an override.
It works casually until a certain point. But XRUN shall happen, as I explained. So, the patch helps well but not cures completely as long as you use that configuration.
Well, do we agree that at least on the hardware that allows an arbitrary fragment sizes, it fixes the problem completely? If so, then IMHO this is already very good.
Sigh. A bug is a bug. I know. But, the problem is that the configuration still doesn't work.
It will likely to work with most cards, right? But I don't have Ye Olde SB16 to test...
This is utterly another problem, rather than the real-time response issue. Because the realtime responsiveness is important for two period case, slight difference of period/buffer size or its wakeup condition influences greatly on the behavior.
As I said, I can reproduce the underrun even after setting 3 periods. This is very suspicious. I need to check for a race.
Yeah, but it's the case of partial writes again, i.e. when apps cannot write a full period size. When apps check its availability via poll, the hack isn't triggered.
But how then it happens that it fixes the portaudio problems? By the way, I still don't see what's the difference. When the poll returns, there is usually a period_size free on slave. But does it mean that the app can write the full period? What if the rate plugin converts the full period of app to the full period of HW + 4 extra bytes? In this case, even after poll, the write may block because of these 4 extra bytes, and then the partial write will happen. Or what am I missing?