On Thu, 24 Jan 2002, Maarten de Boer wrote:
>> 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.
> Isn't this very strange? I thought that capture and playback on the
> ens1371 use the same clock.
Actually not that suprising. Hw always deals with analog values, and
nothing is really exact there. And usually it's just a question of being
close enough. And if you can be close enough with less money, that's the
way it's done most of the time. So you get compromises.
>> ./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
> Okay, obviously this should not work. If capture and playback rates are indeed
> different, and thus the periods, distortion should occur after a while. So
> the fact that it does work seems to indicate that the
Even on cards where you can set an exact rate value in the hw registers,
the actual speed might still be slightly different. It's also possible
that the rate varies a bit (and usually does). It all depends on the
quality of the components and design (although this is really _not_ my
area of expertise :)).
If the rates (as set by the ens1371 driver) really were 44099.814 and
44100.952, it would take 7.5mins for the playback stream to catch the
capture stream (./latency -m 512 -M 512 -> period=256frames,
buffer=512frames). Now I've run the tests for nearly an hour without
distorted audio or xruns, so the figures don't match.
I suspect the ens1371 has been tested specifically for 44.1kHz operation,
so it just works. This makes sense as 44.1kHz is a very common frequency.
It would be interesting to write a small test app that tries to measure
the soundcard speed, ie. measure how much wall-clock time it takes for the
soundcard to produce certain amount of samples and compare it to the
nominal sample rate.
> snd_pcm_hw_params_set_rate_near does not work correctly. I hope Jaroslav
> can look into this.
The closest available frequencies to 44.1kHz are:
playback: 44099.945 and 44100.036
capture: 44099.814 and 44101.051
Now the question is, which values should the driver choose when
snd_pcm_hw_params_set_rate_near(44100) is issued...
With current drivers, "./latency -r 44099" results in combination
p=44099.945 and c=44099.814, while "./latency -r 44100" gives you
p=44100.952 and c=44099.814. Now the curious thing is that with '-r
44099', the streams do run at different speeds and result is garbled
audio.
On the other hand with '-r 44100', full-duplex seems to work relatively
well. Even though nominally running at different speeds
(44100.952-44099.814=1.138frames/sec), they won't drift much apart.
Oh well, I'll try to testing with the driver code. Quite an interesting
problem anyways. Are there many other cards with similar funky adc/dac
clock rates?
--
http://www.eca.cx
Audio software for Linux!
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
