Re: [pulseaudio-discuss] [PATCH] Change the default fragment size to 5 ms
On Ubuntu, since before my time, this has been the default: default-fragments = 8 default-fragment-size-msec = 10 ...so 8 x 10 = 80 ms. If you end up with 5 x 4 = 20 ms, I think that's a bit too short/sensitive, we should then increase the number of periods to 16 or at least 8 in the same go, so you'll end up with something above 50 ms in total. I think this could help against underruns caused by inoptimal scheduling. Unfortunately, what seems to matter (contrary to my initial mail) is the total buffer size, which needs to be less than 34 ms. I don't know where this magic number comes from. 4 fragments 5 ms each = works 4 fragments 8 ms each = works 4 fragments 9 ms each = does not work 2 fragments 16 ms each = works 3 fragments 16 ms each = does not work 3 fragments 11 ms each = works 3 fragments 12 ms each = does not work 2 fragments 17 ms each = does not work 6 fragments 5 ms each = works 7 fragments 5 ms each = does not work -- At this exrteme low latency, rewind become un necessary since your ear won't distinguish this small difference ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Change the default fragment size to 5 ms
24.10.2014 01:44, Andrew Eikum wrote: On Fri, Oct 24, 2014 at 12:38:16AM +0600, Alexander E. Patrakov wrote: 24.10.2014 00:08, Andrew Eikum wrote: I have a patch in-hand which improves the current driver significantly, but it isn't enough to fix the USB devices problem. If someone wants to review the winealsa driver with the patch applied and discuss solutions, let me know. I'd love to get this problem solved. If you send me the patch, I promise to have a look at it. But, see my other reply why there cannot be a full solution within the ALSA API. I've attached the patch here. It's been a while since I've worked on this, so I'm fuzzy on the details. It should apply on any recent Wine version, including today's. I have looked at the patch, but have not tested it. I cannot say just by reading the code whether this is an improvement. I think that the most important thing here is the removal of the keep no more than 3 ALSA periods logic. Still, the patch was useful as it forced me to look at the buffering logic in Wine. There's a comment above alsa_write_data() describing how the buffer is laid out and what the offsets point to. alsa_write_data() is where we actually send data to ALSA. AudioClient_Stop() and _Start() are where the stream is rewound and paused. AudioClient_Initialize() is where the device setup occurs. AudioClock_GetPosition() returns the number of played frames. Note that we explicitly toggle handle_underrun to TRUE in make_handle_underrun_config(). Toggling this off does seem to have an impact on USB devices. The underruns aren't fixed in either setting, but it's worth playing with. As I said, the underruns happen because the pulse plugin provides incorrect information about the actual period size to Wine. If I remember correctly, the problem with USB devices is that snd_pcm_avail_update() updates too infrequently. To keep low latency, we set up a buffer size of four ALSA periods (about 40ms, I think). But, snd_pcm_avail_update() updates less frequently than that, so we constantly hit underruns. Some Windows applications behave very badly with large latencies. I think the issue was more complicated than that, but I've forgotten the details in the meantime... AFAICS we can confirm or disprove this by logging last_period_time. I believe disabling BATCH mode on USB devices fixes everything with this patch applied, but I presume there was a reason it was introduced in the first place (see PA bug 66962). I could be wrong here, I never totally understood the issue. That bug is exactly what I am talking about. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Change the default fragment size to 5 ms
23.10.2014 09:05, Raymond Yau wrote: Is it feasible to add an alternative parameter in fragment size since some soc driver does not support disable period wakep but dma brust sizes require 8 frames ? https://bugs.freedesktop.org/show_bug.cgi?id=84585 This bug report is so dirty that I cannot make any sense out of it. And anyway, this would be a different patch. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Change the default fragment size to 5 ms
22.10.2014 22:21, I wrote: 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! I hereby withdraw the patch, as on IRC I see that Arun said: I'm not too happy with changing that. It would affect CPU on systems that don't care about Wine. and I really really don't want to work around bad clients in PA. (despite the fact that I am also bitten by this bug) ... Want to start a BrokenClients page? (note: due to the cannot know reason, I still disagree that it is a client-side problem) -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Change the default fragment size to 5 ms
On 23 October 2014 22:46, Alexander E. Patrakov patra...@gmail.com wrote: 22.10.2014 22:21, I wrote: 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! I hereby withdraw the patch, as on IRC I see that Arun said: I'm not too happy with changing that. It would affect CPU on systems that don't care about Wine. and I really really don't want to work around bad clients in PA. (despite the fact that I am also bitten by this bug) ... Want to start a BrokenClients page? (note: due to the cannot know reason, I still disagree that it is a client-side problem) I've not looked at the Wine code for this, but I wonder if we can guess this by looking at the minreq/tlength values that are returned. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Change the default fragment size to 5 ms
On Thu, Oct 23, 2014 at 10:57:18PM +0530, Arun Raghavan wrote: On 23 October 2014 22:46, Alexander E. Patrakov patra...@gmail.com wrote: 22.10.2014 22:21, I wrote: 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! I hereby withdraw the patch, as on IRC I see that Arun said: I'm not too happy with changing that. It would affect CPU on systems that don't care about Wine. and I really really don't want to work around bad clients in PA. (despite the fact that I am also bitten by this bug) ... Want to start a BrokenClients page? It's true that Wine's audio doesn't get much work these days, though in my defense :) it's a time issue, not a willingness issue. I have spent literally weeks trying to understand and work around the timing issues that cause problems with USB devices accessed with the PulseAudio ALSA plugin. I plan to continue working on it, but business priorities lay elsewhere at the moment and I've already spent loads of time on it. (note: due to the cannot know reason, I still disagree that it is a client-side problem) I've not looked at the Wine code for this, but I wonder if we can guess this by looking at the minreq/tlength values that are returned. I'd love to work with an ALSA/PA expert to come up with a solution, either by fixing Wine or coming up with a new ALSA API to provide the info we need. I have a patch in-hand which improves the current driver significantly, but it isn't enough to fix the USB devices problem. If someone wants to review the winealsa driver with the patch applied and discuss solutions, let me know. I'd love to get this problem solved. Andrew ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Change the default fragment size to 5 ms
24.10.2014 00:08, Andrew Eikum wrote: On Thu, Oct 23, 2014 at 10:57:18PM +0530, Arun Raghavan wrote: On 23 October 2014 22:46, Alexander E. Patrakov patra...@gmail.com wrote: 22.10.2014 22:21, I wrote: 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! I hereby withdraw the patch, as on IRC I see that Arun said: I'm not too happy with changing that. It would affect CPU on systems that don't care about Wine. and I really really don't want to work around bad clients in PA. (despite the fact that I am also bitten by this bug) ... Want to start a BrokenClients page? It's true that Wine's audio doesn't get much work these days, though in my defense :) it's a time issue, not a willingness issue. I have spent literally weeks trying to understand and work around the timing issues that cause problems with USB devices accessed with the PulseAudio ALSA plugin. I plan to continue working on it, but business priorities lay elsewhere at the moment and I've already spent loads of time on it. (note: due to the cannot know reason, I still disagree that it is a client-side problem) I've not looked at the Wine code for this, but I wonder if we can guess this by looking at the minreq/tlength values that are returned. I'd love to work with an ALSA/PA expert to come up with a solution, either by fixing Wine or coming up with a new ALSA API to provide the info we need. I have a patch in-hand which improves the current driver significantly, but it isn't enough to fix the USB devices problem. If someone wants to review the winealsa driver with the patch applied and discuss solutions, let me know. I'd love to get this problem solved. If you send me the patch, I promise to have a look at it. But, see my other reply why there cannot be a full solution within the ALSA API. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Change the default fragment size to 5 ms
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 patra...@gmail.com
---
man/pulse-daemon.conf.5.xml.in | 4 ++--
src/daemon/daemon-conf.c | 2 +-
src/daemon/daemon.conf.in | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/man/pulse-daemon.conf.5.xml.in b/man/
pulse-daemon.conf.5.xml.in
index 8bd076d..ff54435 100644
--- a/man/pulse-daemon.conf.5.xml.in
+++ b/man/pulse-daemon.conf.5.xml.in
@@ -463,8 +463,8 @@ USA.
/option
option
poptdefault-fragment-size-msec=/optThe duration of a
- single fragment. Defaults to 25ms (i.e. the total buffer is thus
- 100ms long)./p
+ single fragment. Defaults to 5ms (i.e. the total buffer is thus
+ 20ms long)./p
/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
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Change the default fragment size to 5 ms
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 It is the hardware limitation affect the low latency, this mean that pulseaudio have to select the maximum of lowest latency of all the sinks / sources as default latency 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. On devices that can use tsched, there is no problem. diff --git a/man/pulse-daemon.conf.5.xml.inb/man/ pulse-daemon.conf.5.xml.in index 8bd076d..ff54435 100644 --- a/man/pulse-daemon.conf.5.xml.in +++ b/man/pulse-daemon.conf.5.xml.in @@ -463,8 +463,8 @@ USA. /option option poptdefault-fragment-size-msec=/optThe duration of a - single fragment. Defaults to 25ms (i.e. the total buffer is thus - 100ms long)./p + single fragment. Defaults to 5ms (i.e. the total buffer is thus + 20ms long)./p /option Is it feasible to add an alternative parameter in fragment size since some soc driver does not support disable period wakep but dma brust sizes require 8 frames ? https://bugs.freedesktop.org/show_bug.cgi?id=84585 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
