http://bugs.winehq.org/show_bug.cgi?id=28517
--- Comment #18 from Andrew Eikum aeikum@codeweavers.com 2011-10-05 09:34:32 CDT --- Created attachment 36726 --> http://bugs.winehq.org/attachment.cgi?id=36726 winealsa.drv: Don't try to control ALSA's behavior
(In reply to comment #13)
I have doubt about your patch remove snd_pcm_hw_params_set_period_time_near()
this means that you will let alsa-lib to determine the period time, buffer_size
so user have to check /usr/share/alsa/alsa.conf if they are using "hw" as "default"
defaults.pcm.minperiodtime 5000 # in us
Can you elaborate on this? I don't see the problem with letting ALSA determine its period size.
(In reply to comment #14)
Maybe it's an artefact of bugzilla's new two column diff mode, but where do you initialize mmdev_period_rt? I don't see it in http://bugs.winehq.org/attachment.cgi?id=36707&action=diff
Why do you reintroduce bufsize_frames etc. as UINT64?
These were me being clumsy. Fixed.
I see no more sw_params_set_*. while it's ok to go with defaults as far as possible, there are a few sw_params that you want to set. For instance, ALSA must either enter XRUN mode and stop or play silence upon underrun. Not setting any sw_params does not guarantee that, in particular the circular HW buffers may loop ad infinitum.
Okay, I've explicitly set start_threshold=1 and stop_threshold=alsa_bufsize_frames. These match the defaults on my system, which do what I expect. Did you have other things in mind?
Why do you care at all about ALSA's period? It can be as low as 1ms (e.g. with a 8000Hz sample I got 1ms period and 8.192ms buffer). I don't want to bear 1000 interrupts a second. Wine should ignore ALSA's period for as long as we don't use poll(alsa's_fd) and the buffer is large enough for our periodic feeder. See http://mailman.alsa-project.org/pipermail/alsa-devel/2011-August/042837.html
Yeah, good point. This also gets rid of the "two timers" business that I didn't like.
I've attached a new patch with your improvements.