>> >> Of course, this only applies to ALSA devices that can't use tsched, as >> well as to OSS on more exotic platforms. >> >> This is needed for compatibility with Wine games that use DirectSound8 >> on distributions such as Arch Linux who don't accept the unofficial >> winepulse patch. The reason is that Wine DirectSound8 emulation requests >> a period of 10 ms and expects it to work for the purposes of timing. And >> in fact, it cannot know (via ALSA API) that it is not going to work! >> >> A known malware-free test application is Foobar2000 version 1.2. Later >> versions no longer use DirectSound. >> >> This issue is not going to be fixed on the Wine side, because the audio >> subsystem in Wine is not really maintained, and the maintainer has >> already privately expressed some negative thoughts about the state of >> the linux audio ecosystem in general. >> >> The correct solution (at least from the "isolate the clients from >> hardware limitations as thoroughly as possible" viewpoint) would be to >> consume audio from sink inputs using a timer if the actual sink does not >> provide sufficiently small minreq. In other words, adapt tsched to BATCH >> cards and drop non-tsched. But that's a whole project. So, as a stopgap >> solution for running Wine games on e.g. USB audio (which is a topic that >> pops up regularly on #pulseaudio IRC channel), let's reduce the default >> fragment size to a value suitable for unpatched Wine. >> >> Regarding the value: on my system, for mp3 playback through Foobar2000, >> 8ms fragments work, 9ms fragments result in constant underruns. >> >> Wine wiki recommends 5ms. > > > Maybe it should be made clearer that the actual periods may differ slightly from the default settings due to hardware constraints or rounding issues, e.g. with your 5ms setting at 44100 Hz the period of 220.5 samples is going to be rounded.... > > >> >> On devices that can use tsched, there is no problem. >> >> Signed-off-by: Alexander E. Patrakov <<a href="mailto:patrakov@gmail.com">patrakov@gmail.com</a>> >> --- >> man/<a href="http://pulse-daemon.conf.5.xml.in">pulse-daemon.conf.5.xml.in</a> | 4 ++-- >> src/daemon/daemon-conf.c | 2 +- >> src/daemon/<a href="http://daemon.conf.in">daemon.conf.in</a> | 2 +- >> 3 files changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/man/<a href="http://pulse-daemon.conf.5.xml.in">pulse-daemon.conf.5.xml.in</a> b/man/<a href="http://pulse-daemon.conf.5.xml.in">pulse-daemon.conf.5.xml.in</a> >> index 8bd076d..ff54435 100644 >> --- a/man/<a href="http://pulse-daemon.conf.5.xml.in">pulse-daemon.conf.5.xml.in</a> >> +++ b/man/<a href="http://pulse-daemon.conf.5.xml.in">pulse-daemon.conf.5.xml.in</a> >> @@ -463,8 +463,8 @@ USA. >> </option> >> <option> >> <opt>default-fragment-size-msec=</opt>The duration of a >> - single fragment. Defaults to 25ms (i.e. the total buffer is thus >> - 100ms long). >> + single fragment. Defaults to 5ms (i.e. the total buffer is thus >> + 20ms long). >> </option> >> >> </section> >> diff --git a/src/daemon/daemon-conf.c b/src/daemon/daemon-conf.c >> index b7a85aa..6dc15cf 100644 >> --- a/src/daemon/daemon-conf.c >> +++ b/src/daemon/daemon-conf.c >> @@ -96,7 +96,7 @@ static const pa_daemon_conf default_conf = { >> .lock_memory = false, >> .deferred_volume = true, >> .default_n_fragments = 4, >> - .default_fragment_size_msec = 25, >> + .default_fragment_size_msec = 5, > > > I've never understood why 4 fragments would be needed. Use 2 fragments and 10ms periods... For drivers can report hwptr only on period boundary, you cannot perform any rewind safely when using two periods This mean read/write must also in period size too Even when driver can report hwptr position in every dma brust transfer, the hwptr position still have an uncertainity of dma brust size