http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #98 from Jörg Höhle hoehle@users.sourceforge.net 2011-12-17 18:14:52 CST --- Please always post the actual ALSA periods so we know the values. 1024 is huge as I've rarely seen buffers over 2s, that would imply a 2ms period -- possible (I've seen 1ms) but I'd expect set_period_near 10ms not to yield 2ms. Also, please say whether you used set_period or set_buffer, as I'm slowly getting confused. Have you been using plug:dmix, PA with handle_underrun or another device?
I tested with min(1x)
I didn't mean alone. I intended to mean min+near, as in set_period_near(10ms) set_buffer_min(2*mmdev_period) else return PERIOD_ERROR set_buffer_near(4*mmdev_period) (or set_periods(4) which means 4xalsa_period) There's also set_..._first
Given the EAGAIN behaviour and period size chunking behaviour, I'm not sure ALSA supports using buffer = 2 periods, unlike the ping pong game that mmdevapi and winmm like to play.
Also, I'm wondering why we should insist on such tiny buffers. 100ms should be equally fine from an audio POV. I'm still thinking about the lead-in idea from comment #58, esp. since we must not forget about bug #29056, "ALSA won't start without a full period".
I've not yet thought about the theoretical lower limits
That's what we need. No trial & error. What's going to happen when period_near returns > 10ms? e.g. 11 or 50ms? What when period_near returns < 10ms? e.g. 1 or 9 ms?
set buffer_near(3xperiod)?
Here the buffer is exactly 3 times the ALSA period length, and has underruns.
set buffer_near(4xperiod)?
Here it's about 10 times the period length, and no underruns.
3/4->3/10 Weird!