On Wednesday 20 May 2015 07:36, Takashi Iwai wrote:
At Tue, 19 May 2015 20:22:50 +0100,
Alan Horstmann wrote:
On Tuesday 19 May 2015 13:01, Takashi Iwai wrote:
At Fri, 1 May 2015 08:36:47 +0100, Alan Horstmann wrote:
A minimal self-contained demo program ('test-format') has been developed and is attached, that demonstrates the issue 100% on the reporters machine (HDA-Intel, 6-ch I believe). The output is:
root@Xeon:/home/patest# ./test-format Testing device front Num channels 6 Testing rate: 22050 Result:...Invalid Sample Rate Testing rate: 32000 Result:...Invalid Sample Rate test-format: pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err
= 0' failed.
Testing rate: 44100 Aborted
Alsa-info is at:
http://www.alsa-project.org/db/?f=19dfeee29f73007e61a00a8fabe3c958f7c b8e8 7
This apparently happens with or without Pulseaudio running, with just the single 44100 rate, and also with surround devices. Also, on all current Debian and Ubuntu - we have focused on Jessie.
I do not have a machine with similar hardware, so cannot duplicate the results.
Any comments, ideas etc would be appreciated.
I also can't reproduce this. So this must be pretty specific to the setup.
Could you give the exact condition to trigger the problem? Also, this happens certainly with the latest alsa-lib?
Thanks for taking a look. Just compiling and running that test program, on the reporter's machine, which has some sort of multi-channel HDA-Intel, is 100% reproducible. The Alsa-lib must be the one provided by Debian Jessie (which was released 25.4.2015); 1.0.28 I think. Does the Alsa-info give enough details - I can ask any specific questions.
However, Raymond seems to have some ideas of a possible cause, in connection with arbitrary period size and softvol; is that plausible?
Possibly, but I wonder why I couldn't see it when I tried with different module options.
In anyway, the fix would be simple, the patch like below. Could you check whether it actually fixes your issue?
I've had a positive confirmation that the patch removing the asserts does fix the 'crash' in the reporter's system. So instead it is simply a failure of the snd_pcm_hw_params() call, which ultimately can be handled in the users code.
I do wonder (as does Raymond) why this fails. Is 6-chans expected to fail on 'front'? In particular the earlier setting of channels/rate/format does not fail? Perhaps I will ask for RULES_DEBUG enabled?
Regards
Alan