http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #69 from Jörg Höhle hoehle@users.sourceforge.net 2011-12-03 14:28:02 CST ---
isn't the only reason to add the silence is to workaround the "pcm is not starting unless at least one [ALSA] period of data had been pumped out"?
I now see three. 1 help start up; 2. trailing samples not heard, comment #63; 3. play 100Hz beeps when app fills 5ms at every 10ms event, comment #55.
Taking into account silent frames [...] is pretty simple.
With either lead-in or trailing only silence, not in the 100Hz scenario.
How the things actually are can only be determined by reverse-engineering
How can you conclude this? Look at how much we've found out simply by printing GetPosition & GetCurrentPadding and writing tests. Writing tests teaches a lot. Have a look at the blackbox game inside Emacs. Type Esc-x blackbox Return and ^H f blackbox Return. Or google the file "blackbox.el" and read the documentation string inside the Lisp stuff :-)
Back to bugs, one can derive the requirement set_hw_params_period_max 20ms based your appDB comment when one uses my pseudo code from comment #58 given ALSA's insistence on being fed a full period before doing anything. 10ms lead-in and 10ms prefill will then ensure ALSA starts. However, 20ms is too large for sustained sound as it means that ALSA is fed a full 20ms period only around the time of ALSA underrun. Rage's scenario really needs set_hw_params_period_time_max 10ms to work reliably -- unless latency is artificially increased (by maintaining GetCurrentPadding e.g. 50ms lower than required using a silence lead of same size). The device could even adapt dynamically and reduce the period from e.g. 100ms downto 10ms should an underrun occur. Daydreaming?