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