| Message ID | s5h4mn7u54s.wl-tiwai@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
> > > > 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=19dfeee29f73007e61a00a8fabe3c958f7cb8e8 > > > >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? > http://music.columbia.edu/pipermail/portaudio/2015-May/016773.html i7 test # ./test-format Testing device front Num channels 6 Testing rate: 22050 Result:...Invalid Sample Rate Testing rate: 32000 Result:...Invalid Sample Rate Testing rate: 44100 Result:...Unexpected Result??? Testing rate: 48000 Result:...Unexpected Result??? Testing rate: 96000 Result:...Unexpected Result??? i7 test # uname -r 3.13.0-sabayon Your program should show snd_strerror(err) instead of Unexpected Result ??? It is strange that it fail at 48000Hz and 96000Hz What is snd_hda_prealloc_size used by 3.13.0-sabayon ? You need to define RULES_DEBUG in pcm_params.c to provide debug output
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
At Thu, 21 May 2015 16:56:04 +0100, Alan Horstmann wrote: > > 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. OK, I pushed the fix to git repo now. > 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? Likely the alignment issue: 6 channels can't fit always with 128 byte constraint that are required by some hardware chips. Takashi
On Thursday 21 May 2015 18:26, Takashi Iwai wrote: > At Thu, 21 May 2015 16:56:04 +0100, > > Alan Horstmann wrote: > > On Wednesday 20 May 2015 07:36, Takashi Iwai wrote: <snip> > > > 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. > > OK, I pushed the fix to git repo now. Is this something that should go to stable so it is more likely to be backported to slower moving distros, eg Debian Jessie, or is that not how it works? > > 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? > > Likely the alignment issue: 6 channels can't fit always with 128 byte > constraint that are required by some hardware chips. Hmm, it is only an issue with the pcms like front, surround though, not hw? Regards Alan
At Thu, 21 May 2015 19:10:30 +0100, Alan Horstmann wrote: > > On Thursday 21 May 2015 18:26, Takashi Iwai wrote: > > At Thu, 21 May 2015 16:56:04 +0100, > > > > Alan Horstmann wrote: > > > On Wednesday 20 May 2015 07:36, Takashi Iwai wrote: > > <snip> > > > > > 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. > > > > OK, I pushed the fix to git repo now. > > Is this something that should go to stable so it is more likely to be > backported to slower moving distros, eg Debian Jessie, or is that not how it > works? It'll be included in the next alsa-lib release. > > > 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? > > > > Likely the alignment issue: 6 channels can't fit always with 128 byte > > constraint that are required by some hardware chips. > > Hmm, it is only an issue with the pcms like front, surround though, not hw? hw might have the same alignment problem, but it hasn't hit assert(). The faulty assert() was only in the code path for plugins. Takashi
> 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? > > period_max is only 32 , this mean that some combination are not possible
diff --git a/src/pcm/pcm_params.c b/src/pcm/pcm_params.c index 6e57904e445b..1d667a583151 100644 --- a/src/pcm/pcm_params.c +++ b/src/pcm/pcm_params.c @@ -2244,9 +2244,11 @@ int snd_pcm_hw_params_slave(snd_pcm_t *pcm, snd_pcm_hw_params_t *params, snd_pcm_hw_params_t slave_params; int err; err = sprepare(pcm, &slave_params); - assert(err >= 0); + if (err < 0) + return err; err = schange(pcm, params, &slave_params); - assert(err >= 0); + if (err < 0) + return err; err = sparams(pcm, &slave_params); if (err < 0) cchange(pcm, params, &slave_params);