At Wed, 25 Feb 2009 11:08:50 +0100,
I wrote:
>
> At Tue, 24 Feb 2009 21:37:20 +0100,
> I wrote:
> >
> > > stop_threshold is completely irrelevant to the problems discussed
> > > here.
> >
> > OK, but let me continue that tomorrow or later.
>
> Running it with five sound cards (two HD-audio, emu10k1, CMI8738, and
> envy24HT) overnight with tail -500, but nothing appears on my
> machines.
>
> All outputs look OK: the first three columns are almost same values,
> avail is a few (< 10), delay is about the buffer size.
>
> How can you trigger the problem so easily?
Could you check the raw hwptr and applptr values surrounding the error
time, e.g. with the patch to alsa-lib below?
If it's really hwsync that makes values unstable, we have to see the
value skips there...
Takashi
---
diff --git a/src/pcm/pcm_hw.c b/src/pcm/pcm_hw.c
index e9ce092..6dd1633 100644
--- a/src/pcm/pcm_hw.c
+++ b/src/pcm/pcm_hw.c
@@ -545,11 +545,20 @@ static int snd_pcm_hw_hwsync(snd_pcm_t *pcm)
if (err < 0)
return err;
} else {
+ long old_hwptr, old_applptr;
+ long new_hwptr, new_applptr;
+ old_hwptr = *pcm->hw.ptr;
+ old_applptr = *pcm->appl.ptr;
if (ioctl(fd, SNDRV_PCM_IOCTL_HWSYNC) < 0) {
err = -errno;
SYSMSG("SNDRV_PCM_IOCTL_HWSYNC failed");
return err;
}
+ new_hwptr = *pcm->hw.ptr;
+ new_applptr = *pcm->appl.ptr;
+ printf("hwsync: %ld(%ld), %ld(%ld)\n",
+ new_hwptr, new_hwptr - old_hwptr,
+ new_applptr, new_applptr - old_applptr);
}
} else {
snd_pcm_sframes_t delay;
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
