Re: [alsa-devel] Timer instability
At Wed, 25 Feb 2009 16:56:47 +0000, Clive Messer wrote:
On Wednesday 25 Feb 2009 16:39:28 you wrote:
At Wed, 25 Feb 2009 16:24:18 +0000,
Clive Messer wrote:
On Wednesday 25 Feb 2009 15:51:33 you wrote:
At Wed, 25 Feb 2009 15:11:44 +0000,
Clive Messer wrote:
36192 36191 100068 3 0 0 1 2 36195 36194 100090 2 0 0 1 2 36198 36198 100113 1 0 0 1 2 36207 36206 63854 2816 1600 0 1 3 36212 36211 63854 2815 1601 4 1 3 36216 36216 63854 2814 1602 4 1 3 36221 36220 63854 2813 1603 4 1 3 36225 36225 101224 4460 -44 4 1 3
This is pretty weird. Is this behavior always reproducible?
Nope. I get different results every time I run it.
What shows with the patch below to alsa-lib?
Here's one (attached) I just did with the new patch that shows the crazy high numbers again. hwsync: 2080(0), 6496(0) 70758 70758 47142 0 4416 0 0 3 hwsync: 1472(0), 6496(0) 70763 70762 104573379136040 4971973988617026976 -4971973988617022560 4 1 3
The problem is that hwptr goes backward here. But it didn't happen in this hwsync call but sometime before that.
Could you try the patch below instead? This will track all sync_ptr calls.
Takashi
diff --git a/src/pcm/pcm_hw.c b/src/pcm/pcm_hw.c index e9ce092..ad8d4a5 100644 --- a/src/pcm/pcm_hw.c +++ b/src/pcm/pcm_hw.c @@ -131,6 +131,10 @@ struct timespec snd_pcm_hw_fast_tstamp(snd_pcm_t *pcm) static int sync_ptr1(snd_pcm_hw_t *hw, unsigned int flags) { int err;
- long old_hwptr, new_hwptr;
- long old_applptr, new_applptr;
- old_hwptr = *pcm->hw.ptr;
- old_applptr = *pcm->appl.ptr; hw->sync_ptr->flags = flags; err = ioctl((hw)->fd, SNDRV_PCM_IOCTL_SYNC_PTR, (hw)->sync_ptr); if (err < 0) {
@@ -138,6 +142,11 @@ static int sync_ptr1(snd_pcm_hw_t *hw, unsigned int flags) SYSMSG("SNDRV_PCM_IOCTL_SYNC_PTR failed"); return err; }
- new_hwptr = *pcm->hw.ptr;
- new_applptr = *pcm->appl.ptr;
- printf("sync_ptr1: %ld(%ld), %ld(%ld)\n",
new_hwptr, new_hwptr - old_hwptr,new_applptr, new_applptr - old_applptr);}
Sorry Takashi,
I'm not a coder so I only know that it wont compile because there isn't a pcm variable passed into that function - it's snd_pcm_hw_t *hw.
Oops, sorry, pasted a wrong version. Here it is.
thanks,
Takashi --- diff --git a/src/pcm/pcm_hw.c b/src/pcm/pcm_hw.c index e9ce092..5211d1c 100644 --- a/src/pcm/pcm_hw.c +++ b/src/pcm/pcm_hw.c @@ -131,6 +131,10 @@ struct timespec snd_pcm_hw_fast_tstamp(snd_pcm_t *pcm) static int sync_ptr1(snd_pcm_hw_t *hw, unsigned int flags) { int err; + long old_hwptr, new_hwptr; + long old_applptr, new_applptr; + old_hwptr = hw->sync_ptr->s.status.hw_ptr; + old_applptr = hw->sync_ptr->c.control.appl_ptr; hw->sync_ptr->flags = flags; err = ioctl((hw)->fd, SNDRV_PCM_IOCTL_SYNC_PTR, (hw)->sync_ptr); if (err < 0) { @@ -138,6 +142,11 @@ static int sync_ptr1(snd_pcm_hw_t *hw, unsigned int flags) SYSMSG("SNDRV_PCM_IOCTL_SYNC_PTR failed"); return err; } + new_hwptr = hw->sync_ptr->s.status.hw_ptr; + new_applptr = hw->sync_ptr->c.control.appl_ptr; + printf("sync_ptr1: %ld(%ld), %ld(%ld)\n", + new_hwptr, new_hwptr - old_hwptr, + new_applptr, new_applptr - old_applptr); return 0; }
On Wednesday 25 Feb 2009 16:59:48 Takashi Iwai wrote:
Oops, sorry, pasted a wrong version. Here it is.
thanks,
Takashi
diff --git a/src/pcm/pcm_hw.c b/src/pcm/pcm_hw.c index e9ce092..5211d1c 100644 --- a/src/pcm/pcm_hw.c +++ b/src/pcm/pcm_hw.c @@ -131,6 +131,10 @@ struct timespec snd_pcm_hw_fast_tstamp(snd_pcm_t *pcm) static int sync_ptr1(snd_pcm_hw_t *hw, unsigned int flags) { int err; + long old_hwptr, new_hwptr; + long old_applptr, new_applptr; + old_hwptr = hw->sync_ptr->s.status.hw_ptr; + old_applptr = hw->sync_ptr->c.control.appl_ptr; hw->sync_ptr->flags = flags; err = ioctl((hw)->fd, SNDRV_PCM_IOCTL_SYNC_PTR, (hw)->sync_ptr); if (err < 0) { @@ -138,6 +142,11 @@ static int sync_ptr1(snd_pcm_hw_t *hw, unsigned int flags) SYSMSG("SNDRV_PCM_IOCTL_SYNC_PTR failed"); return err; } + new_hwptr = hw->sync_ptr->s.status.hw_ptr; + new_applptr = hw->sync_ptr->c.control.appl_ptr; + printf("sync_ptr1: %ld(%ld), %ld(%ld)\n", + new_hwptr, new_hwptr - old_hwptr, + new_applptr, new_applptr - old_applptr); return 0; }
Takashi,
Applied, but I'm not getting any "sync_ptr1: .... " logging on stdout. Any ideas?
Regards
Clive
At Wed, 25 Feb 2009 17:36:24 +0000, Clive Messer wrote:
On Wednesday 25 Feb 2009 16:59:48 Takashi Iwai wrote:
Oops, sorry, pasted a wrong version. Here it is.
thanks,
Takashi
diff --git a/src/pcm/pcm_hw.c b/src/pcm/pcm_hw.c index e9ce092..5211d1c 100644 --- a/src/pcm/pcm_hw.c +++ b/src/pcm/pcm_hw.c @@ -131,6 +131,10 @@ struct timespec snd_pcm_hw_fast_tstamp(snd_pcm_t *pcm) static int sync_ptr1(snd_pcm_hw_t *hw, unsigned int flags) { int err; + long old_hwptr, new_hwptr; + long old_applptr, new_applptr; + old_hwptr = hw->sync_ptr->s.status.hw_ptr; + old_applptr = hw->sync_ptr->c.control.appl_ptr; hw->sync_ptr->flags = flags; err = ioctl((hw)->fd, SNDRV_PCM_IOCTL_SYNC_PTR, (hw)->sync_ptr); if (err < 0) { @@ -138,6 +142,11 @@ static int sync_ptr1(snd_pcm_hw_t *hw, unsigned int flags) SYSMSG("SNDRV_PCM_IOCTL_SYNC_PTR failed"); return err; } + new_hwptr = hw->sync_ptr->s.status.hw_ptr; + new_applptr = hw->sync_ptr->c.control.appl_ptr; + printf("sync_ptr1: %ld(%ld), %ld(%ld)\n", + new_hwptr, new_hwptr - old_hwptr, + new_applptr, new_applptr - old_applptr); return 0; }
Takashi,
Applied, but I'm not getting any "sync_ptr1: .... " logging on stdout. Any ideas?
Did you run against the config with sync_ptr?
Takashi
On Wednesday 25 Feb 2009 18:13:47 you wrote:
At Wed, 25 Feb 2009 17:36:24 +0000,
Applied, but I'm not getting any "sync_ptr1: .... " logging on stdout. Any ideas?
Did you run against the config with sync_ptr?
No, that'll explain it. DOH!!! ;-)
Regards
Clive
On Wednesday 25 Feb 2009 18:13:47 Takashi Iwai wrote:
diff --git a/src/pcm/pcm_hw.c b/src/pcm/pcm_hw.c index e9ce092..5211d1c 100644 --- a/src/pcm/pcm_hw.c +++ b/src/pcm/pcm_hw.c @@ -131,6 +131,10 @@ struct timespec snd_pcm_hw_fast_tstamp(snd_pcm_t *pcm) static int sync_ptr1(snd_pcm_hw_t *hw, unsigned int flags) { int err; + long old_hwptr, new_hwptr; + long old_applptr, new_applptr; + old_hwptr = hw->sync_ptr->s.status.hw_ptr; + old_applptr = hw->sync_ptr->c.control.appl_ptr; hw->sync_ptr->flags = flags; err = ioctl((hw)->fd, SNDRV_PCM_IOCTL_SYNC_PTR, (hw)->sync_ptr); if (err < 0) { @@ -138,6 +142,11 @@ static int sync_ptr1(snd_pcm_hw_t *hw, unsigned int flags) SYSMSG("SNDRV_PCM_IOCTL_SYNC_PTR failed"); return err; } + new_hwptr = hw->sync_ptr->s.status.hw_ptr; + new_applptr = hw->sync_ptr->c.control.appl_ptr; + printf("sync_ptr1: %ld(%ld), %ld(%ld)\n", + new_hwptr, new_hwptr - old_hwptr, + new_applptr, new_applptr - old_applptr); return 0; }
With sync_ptr I cannot reproduce the very large numbers. Here's a typical log. (Attached).
Regards
Clive
At Wed, 25 Feb 2009 18:34:31 +0000, Clive Messer wrote:
On Wednesday 25 Feb 2009 18:13:47 Takashi Iwai wrote:
diff --git a/src/pcm/pcm_hw.c b/src/pcm/pcm_hw.c index e9ce092..5211d1c 100644 --- a/src/pcm/pcm_hw.c +++ b/src/pcm/pcm_hw.c @@ -131,6 +131,10 @@ struct timespec snd_pcm_hw_fast_tstamp(snd_pcm_t *pcm) static int sync_ptr1(snd_pcm_hw_t *hw, unsigned int flags) { int err; + long old_hwptr, new_hwptr; + long old_applptr, new_applptr; + old_hwptr = hw->sync_ptr->s.status.hw_ptr; + old_applptr = hw->sync_ptr->c.control.appl_ptr; hw->sync_ptr->flags = flags; err = ioctl((hw)->fd, SNDRV_PCM_IOCTL_SYNC_PTR, (hw)->sync_ptr); if (err < 0) { @@ -138,6 +142,11 @@ static int sync_ptr1(snd_pcm_hw_t *hw, unsigned int flags) SYSMSG("SNDRV_PCM_IOCTL_SYNC_PTR failed"); return err; } + new_hwptr = hw->sync_ptr->s.status.hw_ptr; + new_applptr = hw->sync_ptr->c.control.appl_ptr; + printf("sync_ptr1: %ld(%ld), %ld(%ld)\n", + new_hwptr, new_hwptr - old_hwptr, + new_applptr, new_applptr - old_applptr); return 0; }
With sync_ptr I cannot reproduce the very large numbers. Here's a typical log. (Attached).
Hrm, but still an unexpected jump is found.
If you build the driver with CONFIG_SND_PCM_XRUN_DEBUG=y, you must have /proc/asound/card0/pcm0p/xrun_debug. Echo 1 to this (as root) echo 1 > /proc/asound/card0/pcm0p/xrun_debug and try the program, see whether any debug message appears. If any message appears, it means basically an unstable hardware.
Also, the below is a patch I tried to clean up and improve the handling. Give it a try (and do echo 1 above for testing).
thanks,
Takashi ---
At Tue, 03 Mar 2009 17:05:31 +0100, I wrote:
At Wed, 25 Feb 2009 18:34:31 +0000, Clive Messer wrote:
On Wednesday 25 Feb 2009 18:13:47 Takashi Iwai wrote:
diff --git a/src/pcm/pcm_hw.c b/src/pcm/pcm_hw.c index e9ce092..5211d1c 100644 --- a/src/pcm/pcm_hw.c +++ b/src/pcm/pcm_hw.c @@ -131,6 +131,10 @@ struct timespec snd_pcm_hw_fast_tstamp(snd_pcm_t *pcm) static int sync_ptr1(snd_pcm_hw_t *hw, unsigned int flags) { int err; + long old_hwptr, new_hwptr; + long old_applptr, new_applptr; + old_hwptr = hw->sync_ptr->s.status.hw_ptr; + old_applptr = hw->sync_ptr->c.control.appl_ptr; hw->sync_ptr->flags = flags; err = ioctl((hw)->fd, SNDRV_PCM_IOCTL_SYNC_PTR, (hw)->sync_ptr); if (err < 0) { @@ -138,6 +142,11 @@ static int sync_ptr1(snd_pcm_hw_t *hw, unsigned int flags) SYSMSG("SNDRV_PCM_IOCTL_SYNC_PTR failed"); return err; } + new_hwptr = hw->sync_ptr->s.status.hw_ptr; + new_applptr = hw->sync_ptr->c.control.appl_ptr; + printf("sync_ptr1: %ld(%ld), %ld(%ld)\n", + new_hwptr, new_hwptr - old_hwptr, + new_applptr, new_applptr - old_applptr); return 0; }
With sync_ptr I cannot reproduce the very large numbers. Here's a typical log. (Attached).
Hrm, but still an unexpected jump is found.
If you build the driver with CONFIG_SND_PCM_XRUN_DEBUG=y, you must have /proc/asound/card0/pcm0p/xrun_debug. Echo 1 to this (as root) echo 1 > /proc/asound/card0/pcm0p/xrun_debug and try the program, see whether any debug message appears. If any message appears, it means basically an unstable hardware.
Also, the below is a patch I tried to clean up and improve the handling. Give it a try (and do echo 1 above for testing).
BTW, the original test program is very hard to see what's wrong because it spews out way too many lines. The below is a filtered-out version.
It prints only unexpected jumps of avail values (the threshold is set 100 blindly). The output is like below:
% ./alsa-time-test hw 21720872 (4987) delta 216 avail 216 delay 4200 21943118 (65) delta 208 avail 208 delay 4208 23752310 (3) delta 232 avail 232 delay 4184 23761847 (5972) delta 264 avail 264 delay 4152
The first column is the usec from the program start, the next value in parentheses is the time-step from the last time of status changes, the delta is the increase of avail, and the rest are raw values.
If a too large delta appears in a short time-step, something is wrong. If it appears in a large time-step, it's simply a wrong responsiveness (aka system latency).
Takashi
On Tuesday 03 Mar 2009 17:41:22 Takashi Iwai wrote:
Hrm, but still an unexpected jump is found.
If you build the driver with CONFIG_SND_PCM_XRUN_DEBUG=y, you must have /proc/asound/card0/pcm0p/xrun_debug. Echo 1 to this (as root) echo 1 > /proc/asound/card0/pcm0p/xrun_debug and try the program, see whether any debug message appears. If any message appears, it means basically an unstable hardware.
Also, the below is a patch I tried to clean up and improve the handling. Give it a try (and do echo 1 above for testing).
BTW, the original test program is very hard to see what's wrong because it spews out way too many lines. The below is a filtered-out version.
It prints only unexpected jumps of avail values (the threshold is set 100 blindly). The output is like below:
% ./alsa-time-test hw 21720872 (4987) delta 216 avail 216 delay 4200 21943118 (65) delta 208 avail 208 delay 4208 23752310 (3) delta 232 avail 232 delay 4184 23761847 (5972) delta 264 avail 264 delay 4152
The first column is the usec from the program start, the next value in parentheses is the time-step from the last time of status changes, the delta is the increase of avail, and the rest are raw values.
If a too large delta appears in a short time-step, something is wrong. If it appears in a large time-step, it's simply a wrong responsiveness (aka system latency).
Hello Takashi/Lennart,
Sorry, I have been busy for a few days. I patched my kernel (kernel-2.6.29-0.53.rc7.fc10.x86_64) with your pcm_lib.c patch and 'echo 1 > /proc/asound/card0/pcm0p/xrun_debug'.
I have done several runs with the new alsa-time-test.c code. Typically I get a bunch of kernel dmesg when I start the alsa-time-test program but not afterwards. Just a reminder - I'm running this on fast hardware - X58 / Core i7 920 - the machine is not loaded at all, so latency should be very low. snd_hda_intel - ' 00-00: AD198x Analog : AD198x Analog : playback 1 : capture 3'.
Here is an example run .....
hw_ptr skipping! (pos=2096, delta=2096, period=1472) hw_ptr skipping! (pos=2096, delta=2096, period=1472) hw_ptr skipping! (pos=3600, delta=3600, period=1472) hw_ptr skipping! (pos=3600, delta=3600, period=1472) hw_ptr skipping! (pos=3600, delta=3600, period=1472) hw_ptr skipping! (pos=3600, delta=3600, period=1472) hw_ptr skipping! (pos=3600, delta=3600, period=1472) hw_ptr skipping! (pos=3600, delta=3600, period=1472)
9901323 (2632) delta 111 avail 117 delay 4299 19901290 (2599) delta 112 avail 112 delay 4304 29901285 (3) delta 112 avail 112 delay 4304 39901315 (2624) delta 120 avail 120 delay 4296 49901317 (2626) delta 112 avail 112 delay 4304 59901317 (2625) delta 112 avail 112 delay 4304 69901323 (2632) delta 118 avail 118 delay 4298 79901391 (3) delta 120 avail 120 delay 4296 89901327 (2634) delta 112 avail 112 delay 4304 99901283 (2591) delta 120 avail 120 delay 4296 109901334 (2642) delta 120 avail 120 delay 4296 119901320 (2627) delta 112 avail 112 delay 4304
Regards
Clive
At Mon, 9 Mar 2009 11:13:21 +0000, Clive Messer wrote:
On Tuesday 03 Mar 2009 17:41:22 Takashi Iwai wrote:
Hrm, but still an unexpected jump is found.
If you build the driver with CONFIG_SND_PCM_XRUN_DEBUG=y, you must have /proc/asound/card0/pcm0p/xrun_debug. Echo 1 to this (as root) echo 1 > /proc/asound/card0/pcm0p/xrun_debug and try the program, see whether any debug message appears. If any message appears, it means basically an unstable hardware.
Also, the below is a patch I tried to clean up and improve the handling. Give it a try (and do echo 1 above for testing).
BTW, the original test program is very hard to see what's wrong because it spews out way too many lines. The below is a filtered-out version.
It prints only unexpected jumps of avail values (the threshold is set 100 blindly). The output is like below:
% ./alsa-time-test hw 21720872 (4987) delta 216 avail 216 delay 4200 21943118 (65) delta 208 avail 208 delay 4208 23752310 (3) delta 232 avail 232 delay 4184 23761847 (5972) delta 264 avail 264 delay 4152
The first column is the usec from the program start, the next value in parentheses is the time-step from the last time of status changes, the delta is the increase of avail, and the rest are raw values.
If a too large delta appears in a short time-step, something is wrong. If it appears in a large time-step, it's simply a wrong responsiveness (aka system latency).
Hello Takashi/Lennart,
Sorry, I have been busy for a few days. I patched my kernel (kernel-2.6.29-0.53.rc7.fc10.x86_64) with your pcm_lib.c patch and 'echo 1 > /proc/asound/card0/pcm0p/xrun_debug'.
I have done several runs with the new alsa-time-test.c code. Typically I get a bunch of kernel dmesg when I start the alsa-time-test program but not afterwards. Just a reminder - I'm running this on fast hardware - X58 / Core i7 920 - the machine is not loaded at all, so latency should be very low. snd_hda_intel - ' 00-00: AD198x Analog : AD198x Analog : playback 1 : capture 3'.
Here is an example run .....
hw_ptr skipping! (pos=2096, delta=2096, period=1472) hw_ptr skipping! (pos=2096, delta=2096, period=1472) hw_ptr skipping! (pos=3600, delta=3600, period=1472) hw_ptr skipping! (pos=3600, delta=3600, period=1472) hw_ptr skipping! (pos=3600, delta=3600, period=1472) hw_ptr skipping! (pos=3600, delta=3600, period=1472) hw_ptr skipping! (pos=3600, delta=3600, period=1472) hw_ptr skipping! (pos=3600, delta=3600, period=1472)
Thanks. This implies that the position pointer once reads zero then the next value gets screwed up. It shows the DMA pointer read is pretty unreliable on your hardware. It's obviously bad for PA because the DMA pointer is the only trusted information for glitch-free. For the traditional method, this isn't usually so critical, though.
9901323 (2632) delta 111 avail 117 delay 4299 19901290 (2599) delta 112 avail 112 delay 4304 29901285 (3) delta 112 avail 112 delay 4304 39901315 (2624) delta 120 avail 120 delay 4296 49901317 (2626) delta 112 avail 112 delay 4304 59901317 (2625) delta 112 avail 112 delay 4304 69901323 (2632) delta 118 avail 118 delay 4298 79901391 (3) delta 120 avail 120 delay 4296 89901327 (2634) delta 112 avail 112 delay 4304 99901283 (2591) delta 120 avail 120 delay 4296 109901334 (2642) delta 120 avail 120 delay 4296 119901320 (2627) delta 112 avail 112 delay 4304
These outputs look fairly OK. The latency is about 2.5 ms and it's about 110 samples. That us, as long as the outputs look like above, your system is working fine with my patch.
Let me know if any other cases are found.
thanks,
Takashi
At Mon, 09 Mar 2009 12:20:51 +0100, I wrote:
At Mon, 9 Mar 2009 11:13:21 +0000, Clive Messer wrote:
On Tuesday 03 Mar 2009 17:41:22 Takashi Iwai wrote:
Hrm, but still an unexpected jump is found.
If you build the driver with CONFIG_SND_PCM_XRUN_DEBUG=y, you must have /proc/asound/card0/pcm0p/xrun_debug. Echo 1 to this (as root) echo 1 > /proc/asound/card0/pcm0p/xrun_debug and try the program, see whether any debug message appears. If any message appears, it means basically an unstable hardware.
Also, the below is a patch I tried to clean up and improve the handling. Give it a try (and do echo 1 above for testing).
BTW, the original test program is very hard to see what's wrong because it spews out way too many lines. The below is a filtered-out version.
It prints only unexpected jumps of avail values (the threshold is set 100 blindly). The output is like below:
% ./alsa-time-test hw 21720872 (4987) delta 216 avail 216 delay 4200 21943118 (65) delta 208 avail 208 delay 4208 23752310 (3) delta 232 avail 232 delay 4184 23761847 (5972) delta 264 avail 264 delay 4152
The first column is the usec from the program start, the next value in parentheses is the time-step from the last time of status changes, the delta is the increase of avail, and the rest are raw values.
If a too large delta appears in a short time-step, something is wrong. If it appears in a large time-step, it's simply a wrong responsiveness (aka system latency).
Hello Takashi/Lennart,
Sorry, I have been busy for a few days. I patched my kernel (kernel-2.6.29-0.53.rc7.fc10.x86_64) with your pcm_lib.c patch and 'echo 1 > /proc/asound/card0/pcm0p/xrun_debug'.
I have done several runs with the new alsa-time-test.c code. Typically I get a bunch of kernel dmesg when I start the alsa-time-test program but not afterwards. Just a reminder - I'm running this on fast hardware - X58 / Core i7 920 - the machine is not loaded at all, so latency should be very low. snd_hda_intel - ' 00-00: AD198x Analog : AD198x Analog : playback 1 : capture 3'.
Here is an example run .....
hw_ptr skipping! (pos=2096, delta=2096, period=1472) hw_ptr skipping! (pos=2096, delta=2096, period=1472) hw_ptr skipping! (pos=3600, delta=3600, period=1472) hw_ptr skipping! (pos=3600, delta=3600, period=1472) hw_ptr skipping! (pos=3600, delta=3600, period=1472) hw_ptr skipping! (pos=3600, delta=3600, period=1472) hw_ptr skipping! (pos=3600, delta=3600, period=1472) hw_ptr skipping! (pos=3600, delta=3600, period=1472)
Thanks. This implies that the position pointer once reads zero then the next value gets screwed up. It shows the DMA pointer read is pretty unreliable on your hardware. It's obviously bad for PA because the DMA pointer is the only trusted information for glitch-free. For the traditional method, this isn't usually so critical, though.
9901323 (2632) delta 111 avail 117 delay 4299 19901290 (2599) delta 112 avail 112 delay 4304 29901285 (3) delta 112 avail 112 delay 4304 39901315 (2624) delta 120 avail 120 delay 4296 49901317 (2626) delta 112 avail 112 delay 4304 59901317 (2625) delta 112 avail 112 delay 4304 69901323 (2632) delta 118 avail 118 delay 4298 79901391 (3) delta 120 avail 120 delay 4296 89901327 (2634) delta 112 avail 112 delay 4304 99901283 (2591) delta 120 avail 120 delay 4296 109901334 (2642) delta 120 avail 120 delay 4296 119901320 (2627) delta 112 avail 112 delay 4304
These outputs look fairly OK. The latency is about 2.5 ms and it's about 110 samples. That us, as long as the outputs look like above, your system is working fine with my patch.
As the patch seems working with other tests, too, I merged it (with a slight clean-up) into sound git tree now.
Takashi
participants (2)
-
Clive Messer -
Takashi Iwai