On Wed, 23 Jan 2002, Maarten de Boer wrote:
> When I run the alsa-lib/test/latency (CVS), like this:
[...]
> ./latency -r 44099 -m 512 -M 512 -c 1 -s 2000 -p
[...]
> after about 40 seconds, the signal gets distorted badly
> and gets worse over time. It happens independ of the
> buffer size.
I posted about this same issue some weeks ago. I had trouble getting my
ens1371 to work with jackd.
For fullduplex to work at 44.1kHz, you need to set sampling rate to 44100
with ALSA's snd_pcm_hw_params_set_rate_near() function. The closest
matching values are 44099.814 for capture and 44100.952 for playback.
To make alsa-lib's latency work, you need to make the following changes:
--cut--
diff -u -r1.28 latency.c
--- latency.c 2001/12/30 09:22:56 1.28
+++ latency.c 2002/01/23 18:38:18
@@ -85,8 +85,7 @@
return err;
}
if (err != rate) {
- printf("Rate doesn't match (requested %iHz, get %iHz)\n", rate, err);
- return -EINVAL;
+ printf("Warning! Rate doesn't match (requested %iHz, get %iHz)\n",
+rate, err);
}
return 0;
}
@@ -224,9 +223,12 @@
size = snd_pcm_hw_params_get_period_size(c_params, NULL);
if (size > *bufsize)
*bufsize = size;
- if (snd_pcm_hw_params_get_period_time(p_params, NULL) !=
- snd_pcm_hw_params_get_period_time(c_params, NULL))
- goto __again;
+
+ /* if (snd_pcm_hw_params_get_period_time(p_params, NULL) != */
+ /* snd_pcm_hw_params_get_period_time(c_params, NULL)) { */
+ /* goto __again; */
+ /* } */
+
if (snd_pcm_hw_params_get_period_size(p_params, NULL) * 2 <
snd_pcm_hw_params_get_buffer_size(p_params))
goto __again;
if (snd_pcm_hw_params_get_period_size(c_params, NULL) * 2 <
snd_pcm_hw_params_get_buffer_size(c_params))
---cut--
With these code changes, cmdline
./latency -r 44100 -m 512 -M 512 -c 1 -s 2000 -p
... runs without problems. Btw; commenting out the period check is a hack.
The returned valued seemed strange, and I have no time to debug it now...
Both ecasound and jackd also work fine with ens1371 and full-duplex
operation at 44100Hz. I've actually used my ens1371 for _lots_ of
full-duplex work (both multitrack recording and realtime effect
processing), usually at 44.1kHz and with very little problems.
> This also happens at 22050 Hz (after about 1m50), but
> does not happen at 48000, and not when I use -c 2
> (well, maybe it does after a long time, I didn't check)
Yup, same here. Running at 22.05kHz causes garbled audio after a while.
> I hope this is enough information to easily find and
> fix the bug.
I guess the safest bet is to run ens1371 at 48000Hz. I'm not sure whether
there's anything to fix in the driver code.
--
http://www.eca.cx
Audio software for Linux!
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
