[alsa-devel] nforce ac97 plays too fast
Hello.
Trying to get a software amplification to work with NForce CK804 AC'97, I've found out that whatever the asound.conf I write, the sound starts playing much faster than it should. After some debugging, I've found out the following: - The card (or the driver) only supports 48000KHz. - The program (any, because libao and artsd suffer from that) is trying to set some rate with snd_pcm_hw_params_set_rate_near(), and that succeeds, but the returned rate is 48000, while the requested is, say, 22050. No wonder it then plays with the wrong speed. Of course the program can check the returned rate, but it sets the "direction" parameter to 0, which should mean "take exactly that value". I've looked into an alsa-tutorial, and the examples there do not check the returned rate too - dir==0 should be enough.
Looking into the sources, it seems the culprit is the snd_interval_refine_min/max(), which do not care about the (i->min > min && !openmin) case at all.
The question is: is setting dir=0 (or even NULL, since it is a pointer) enough to set the exact rate? And if so - how snd_interval_refine_min() should handle the (i->min > min && !openmin) case? Or if not - what does the dir==0 mean and why it is not adjusted to the proper value on return, when the rate is changed? (i.e. the rate parameter changes from 22050 to 48000, but the dir parameter remains 0, doesn't change)
With the default configuration the rate is proper, but I find it annoying that altering asound.conf in pretty much any way gets the wrong results.
On 9/29/07, Stas Sergeev stsp@aknet.ru wrote:
Hello.
Trying to get a software amplification to work with NForce CK804 AC'97, I've found out that whatever the asound.conf I write, the sound starts playing much faster than it should. After some debugging, I've found out the following:
- The card (or the driver) only supports
48000KHz.
- The program (any, because libao and artsd
suffer from that) is trying to set some rate with snd_pcm_hw_params_set_rate_near(), and that succeeds, but the returned rate is 48000, while the requested is, say, 22050. No wonder it then plays with the wrong speed. Of course the program can check the returned rate, but it sets the "direction" parameter to 0, which should mean "take exactly that value". I've looked into an alsa-tutorial, and the examples there do not check the returned rate too - dir==0 should be enough.
What ALSA tutorial are you looking at? All the ones I am familiar with state that you must check the returned rate. Direction is just a hint.
http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.h...
For example:
http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html#a1... http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2latency_8c-example.htm... http://www.suse.de/~mana/alsa090_howto.html
Lee
Hello.
Lee Revell wrote:
What ALSA tutorial are you looking at?
This one: http://equalarea.com/paul/alsa-audio.html But now I noticed that it passes the rate as an integer, not as a pointer, so it might be somehow outdated... Nevertheless, libao doesn't check, which is a problem.
Direction is just a hint. http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.h...
It says: --- target/chosen exact value is <,=,> val following dir (-1,0,1) --- Cannot parse, what does this mean? Does this mean that dir is only set by the call, and its initial value does not matter? But it doesn't seem to be the case either. No matter what value I set the dir to, the rate is being set to 48000, and the dir is set to 0. Is this really an expected result? If the initial value of dir is not counted and the new value is always 0, then why this parameter is needed at all?
For example:
Yes, they seem to check the rate. But then I don't understand what does this "dir" stand for... And I guess the libao developers had the same question. :)
participants (2)
-
Lee Revell
-
Stas Sergeev