[alsa-devel] Assert in pcm_params.c
Hi,
The following assert is being hit in pcm_params.c:
"pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0' failed."
This is from a developer using Portaudio in his own application; I have yet to ascertain full details, but it is trying successive sample rates to see which are valid.
Does this point to a flaw in the configuration or possibly a bug in Alsa-lib or can it occur just as a result of misuse of the Alsa API?
Regards
Alan
Hi,
The following assert is being hit in pcm_params.c:
"pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0'
failed."
This is from a developer using Portaudio in his own application; I have
yet to
ascertain full details, but it is trying successive sample rates to see
which
are valid.
Does this point to a flaw in the configuration or possibly a bug in
Alsa-lib
or can it occur just as a result of misuse of the Alsa API?
http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.h...
Only snd_pcm_hw_params_test_rate() can be call multiple times, Verify if a rate is available inside a configuration space for a PCM.
Those snd_pcm_hw_params_ser_rate* functions restrict the configuration space to one rate and can be called once only
On Saturday 18 April 2015 09:54, Raymond Yau wrote:
Hi,
The following assert is being hit in pcm_params.c:
"pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0'> failed."
This is from a developer using Portaudio in his own application; I have yet to ascertain full details, but it is trying successive sample rates to see which are valid.
Does this point to a flaw in the configuration or possibly a bug in Alsa-lib or can it occur just as a result of misuse of the Alsa API?
http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params. html
Only snd_pcm_hw_params_test_rate() can be call multiple times, Verify if a rate is available inside a configuration space for a PCM.
Those snd_pcm_hw_params_ser_rate* functions restrict the configuration space to one rate and can be called once only
The stream is being opened and closed at each attempt.
Regards
Alan
Hi,
The following assert is being hit in pcm_params.c:
"pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0'> failed."
This is from a developer using Portaudio in his own application; I
have
yet to ascertain full details, but it is trying successive sample
rates to
see which are valid.
Does this point to a flaw in the configuration or possibly a bug in Alsa-lib or can it occur just as a result of misuse of the Alsa API?
http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.
html
Only snd_pcm_hw_params_test_rate() can be call multiple times, Verify if a rate is available inside a configuration space for a PCM.
Those snd_pcm_hw_params_ser_rate* functions restrict the configuration space to one rate and can be called once only
The stream is being opened and closed at each attempt.
Seem Delta 44 does not support 2,4,6 or 8 channels
aplay --dump-hw-params -Dhw:CARD=M44 any.wav
Do both channel min and channel max > 8 ?
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/pci/...
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/pci/...
rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_8000_48000, .rate_min = 4000, .rate_max = 48000,
If the driver really support any rate between 4000Hz and 48000Hz, the list of supported rates has 48000-4000+1 entries
On Monday 20 April 2015 08:08, you wrote:
Hi,
The following assert is being hit in pcm_params.c:
"pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0'> failed."
This is from a developer using Portaudio in his own application; I
<snip>
Does this point to a flaw in the configuration or possibly a bug in Alsa-lib or can it occur just as a result of misuse of the Alsa API?
http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.
Only snd_pcm_hw_params_test_rate() can be call multiple times, Verify if a rate is available inside a configuration space for a PCM.
Those snd_pcm_hw_params_ser_rate* functions restrict the configuration space to one rate and can be called once only
The stream is being opened and closed at each attempt.
Seem Delta 44 does not support 2,4,6 or 8 channels
This issue is not on Delta44, but an Intel motherboard. But I would not expect to hit an assert in Alsa-lib whatever we do, surely?
Regards
Alan
Hi,
The following assert is being hit in pcm_params.c:
"pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >=
0'>
failed."
This is from a developer using Portaudio in his own application; I
<snip> > > > > Does this point to a flaw in the configuration or possibly a bug
in
Alsa-lib or can it occur just as a result of misuse of the Alsa
API?
http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.
Only snd_pcm_hw_params_test_rate() can be call multiple times, Verify if a rate is available inside a configuration space for a
PCM.
Those snd_pcm_hw_params_ser_rate* functions restrict the
configuration
space to one rate and can be called once only
The stream is being opened and closed at each attempt.
Seem Delta 44 does not support 2,4,6 or 8 channels
This issue is not on Delta44, but an Intel motherboard. But I would not expect to hit an assert in Alsa-lib whatever we do, surely?
call to Pa_IsFormatSupported(NULL, &outputParameters, samprate ); will
cause a crasch for a certain samprate. The Linrad log file is like this: TESTING PORTAUDIO DEVICE 10 FOR Rx output
id=10 device=front hostapi=ALSA max_input_chan=0 max_output_chan=6 Testing 0 8000.000000 err=-9997 Invalid sample rate Testing 1 9600.000000 err=-9997 Invalid sample rate Testing 2 11025.000000 err=-9997 Invalid sample rate Testing 3 12000.000000 err=-9997 Invalid sample rate Testing 4 16000.000000 err=-9997 Invalid sample rate Testing 5 22050.000000 err=-9997 Invalid sample rate Testing 6 24000.000000 err=-9997 Invalid sample rate Testing 7 32000.000000 err=-9997 Invalid sample rate Testing 8 44100.000000
9600,12000 are not in Table 56. Defined Sample Rates of HDA specification
http://git.kernel.org/cgit/linux/kernel/git/tiwai/hda-emu.git/tree/codecs/ad...
Most 6 channels audio are at 48000Hz, but some application upmix stereo 44100Hz to 6 channels
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pc...
From the HDA spec it appears that the buffers written to the BDL and
sent to a codec must be 128 byte aligned (section 4.5.1). The alignment was not happening especially when playing 6 channels.
Do you mean the driver still have this alignment when playing 6 channel ? I
On Saturday 18 April 2015 09:08, I wrote:
The following assert is being hit in pcm_params.c:
"pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0' failed."
This is from a developer using Portaudio in his own application; I have yet to ascertain full details, but it is trying successive sample rates to see which are valid.
Further info: this occurs with an Intel motherboard/soundcard, attempting to open and config the stream at 44100 using front, surround or hdmi pcm, having previously opened and tried at a lower, not-supported samplerate, and closed. AFAIK other pcms work OK.
The assert is hit with all current Debian and Ubuntu distros, for example Debian 8 (jessie) 32 bit: kernel 3.16.0-4-686-pae (Alsa 1.0.28) but is not seen with Fedora 20 or OpenSuse 12.1 (do they have asserts off?).
Does this point to a flaw in the configuration or possibly a bug in Alsa-lib or can it occur just as a result of misuse of the Alsa API?
I will try to conceive some more tests. How can we debug this further?
Regards
Alan
The following assert is being hit in pcm_params.c:
"pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0'
failed."
This is from a developer using Portaudio in his own application; I have
yet
to ascertain full details, but it is trying successive sample rates to
see
which are valid.
Further info: this occurs with an Intel motherboard/soundcard, attempting
to
open and config the stream at 44100 using front, surround or hdmi pcm,
having
previously opened and tried at a lower, not-supported samplerate, and
closed.
AFAIK other pcms work
call to Pa_IsFormatSupported(NULL, &outputParameters, samprate ); will cause a crasch for a certain samprate. The Linrad log file is like this: TESTING PORTAUDIO DEVICE 10 FOR Rx output
id=10 device=front hostapi=ALSA max_input_chan=0 max_output_chan=6 Testing 0 8000.000000 err=-9997 Invalid sample rate Testing 1 9600.000000 err=-9997 Invalid sample rate Testing 2 11025.000000 err=-9997 Invalid sample rate Testing 3 12000.000000 err=-9997 Invalid sample rate Testing 4 16000.000000 err=-9997 Invalid sample rate Testing 5 22050.000000 err=-9997 Invalid sample rate Testing 6 24000.000000 err=-9997 Invalid sample rate Testing 7 32000.000000 err=-9997 Invalid sample rate Testing 8 44100.000000
This means that the call to Pa_IsFormatSupported did not return when samprate=44100.
The terminal window (stderr) shows this: root <at> Xeon:/home/dsp# ./xlinrad64 ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.HDA-Intel.pcm.rear.0:CARD=0' ALSA lib conf.c:4259:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib conf.c:4738:(snd_config_expand) Evaluate error: No such file or directory ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM rear ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.HDA-Intel.pcm.center_lfe.0:CARD=0' ALSA lib conf.c:4259:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib conf.c:4738:(snd_config_expand) Evaluate error: No such file or directory ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM center_lfe ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.HDA-Intel.pcm.side.0:CARD=0' ALSA lib conf.c:4259:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib conf.c:4738:(snd_config_expand) Evaluate error: No such file or directory ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM side ALSA lib pcm_route.c:947:(find_matching_chmap) Found no matching channel map ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused
Cannot connect to server socket err = No such file or directory Cannot connect to server request channel jack server is not running or cannot be started xlinrad64: pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0' failed. Aborted
Most likely bug in those user defined devices
Do portaudio hardcode "rear" device ?
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/conf/cards/HDA-Inte...
Not all hda codecs support 44100Hz
Which hda codec?
The assert is hit with all current Debian and Ubuntu distros, for example Debian 8 (jessie) 32 bit: kernel 3.16.0-4-686-pae (Alsa 1.0.28) but is not seen with Fedora 20 or OpenSuse 12.1 (do they have asserts
off?).
Does this point to a flaw in the configuration or possibly a bug in Alsa-lib or can it occur just as a result of misuse of the Alsa API?
I will try to conceive some more tests. How can we debug this further Regards
Output of alsa-info.sh
and those customised devices in asoundrc
On Monday 20 April 2015 12:17, Alan Horstmann wrote:
On Saturday 18 April 2015 09:08, Alan Horstmann wrote:
The following assert is being hit in pcm_params.c:
"pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0' failed."
This is from a developer using Portaudio in his own application; I have yet to ascertain full details, but it is trying successive sample rates to see which are valid.
Further info: this occurs with an Intel motherboard/soundcard, attempting to open and config the stream at 44100 using front, surround or hdmi pcm, having previously opened and tried at a lower, not-supported samplerate, and closed. AFAIK other pcms work OK.
The assert is hit with all current Debian and Ubuntu distros, for example Debian 8 (jessie) 32 bit: kernel 3.16.0-4-686-pae (Alsa 1.0.28) but is not seen with Fedora 20 or OpenSuse 12.1 (do they have asserts off?).
Does this point to a flaw in the configuration or possibly a bug in Alsa-lib or can it occur just as a result of misuse of the Alsa API?
I will try to conceive some more tests. How can we debug this further?
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=19dfeee29f73007e61a00a8fabe3c958f7cb8e87
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.
Regards
Alan
The following assert is being hit in pcm_params.c:
"pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0' failed."
This is from a developer using Portaudio in his own application; I
have
yet to ascertain full details, but it is trying successive sample
rates
to see which are valid.
Further info: this occurs with an Intel motherboard/soundcard,
attempting
to open and config the stream at 44100 using front, surround or hdmi
pcm,
having previously opened and tried at a lower, not-supported samplerate, and closed. AFAIK other pcms work OK.
The assert is hit with all current Debian and Ubuntu distros, for
example
Debian 8 (jessie) 32 bit: kernel 3.16.0-4-686-pae (Alsa 1.0.28)but is not seen with Fedora 20 or OpenSuse 12.1 (do they have asserts off?).
Does this point to a flaw in the configuration or possibly a bug in Alsa-lib or can it occur just as a result of misuse of the Alsa API?
I will try to conceive some more tests. How can we debug this further?
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=19dfeee29f73007e61a00a8fabe3c958f7cb8e87
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.
Cannot reproduce the assert
But the only plugin associated with front device is softvol
Do the assert still occur with hw device ?(without softvol plugin)
You need to provide debug output by define RULES_DEBUG in pcm_params.c
What value do the distribution use for hda prealloc max size ?
snd_pcm_hw_params() may fail with invalid argument even when pa_isFormataupported return true
The following assert is being hit in pcm_params.c:
"pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0' failed."
This is from a developer using Portaudio in his own application; I have yet to ascertain full details, but it is trying successive sample rates to see which are valid.
Further info: this occurs with an Intel motherboard/soundcard, attempting to open and config the stream at 44100 using front, surround or hdmi pcm, having previously opened and tried at a lower, not-supported samplerate, and closed. AFAIK other pcms work OK.
The assert is hit with all current Debian and Ubuntu distros, for example Debian 8 (jessie) 32 bit: kernel 3.16.0-4-686-pae (Alsa 1.0.28) but is not seen with Fedora 20 or OpenSuse 12.1 (do they have asserts off?).
Does this point to a flaw in the configuration or possibly a bug in Alsa-lib or can it occur just as a result of misuse of the Alsa API?
I will try to conceive some more tests. How can we debug this further?
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=19dfeee29f73007e61a00a8fabe3c958f7cb8e87
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.
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pc...
seem assert only occur when hda controller support arbitrary period size (align_buffer_size=0) and softvol plugin ,
your program return invalid argument -22 without softvol plugin
At Fri, 1 May 2015 08:36:47 +0100, Alan Horstmann wrote:
On Monday 20 April 2015 12:17, Alan Horstmann wrote:
On Saturday 18 April 2015 09:08, Alan Horstmann wrote:
The following assert is being hit in pcm_params.c:
"pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0' failed."
This is from a developer using Portaudio in his own application; I have yet to ascertain full details, but it is trying successive sample rates to see which are valid.
Further info: this occurs with an Intel motherboard/soundcard, attempting to open and config the stream at 44100 using front, surround or hdmi pcm, having previously opened and tried at a lower, not-supported samplerate, and closed. AFAIK other pcms work OK.
The assert is hit with all current Debian and Ubuntu distros, for example Debian 8 (jessie) 32 bit: kernel 3.16.0-4-686-pae (Alsa 1.0.28) but is not seen with Fedora 20 or OpenSuse 12.1 (do they have asserts off?).
Does this point to a flaw in the configuration or possibly a bug in Alsa-lib or can it occur just as a result of misuse of the Alsa API?
I will try to conceive some more tests. How can we debug this further?
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=19dfeee29f73007e61a00a8fabe3c958f7cb8e87
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,
Takashi
The following assert is being hit in pcm_params.c:
"pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0' failed."
This is from a developer using Portaudio in his own application; I
have
yet to ascertain full details, but it is trying successive sample
rates
to see which are valid.
Further info: this occurs with an Intel motherboard/soundcard,
attempting
to open and config the stream at 44100 using front, surround or hdmi
pcm,
having previously opened and tried at a lower, not-supported
samplerate,
and closed. AFAIK other pcms work OK.
The assert is hit with all current Debian and Ubuntu distros, for
example
Debian 8 (jessie) 32 bit: kernel 3.16.0-4-686-pae (Alsa 1.0.28)but is not seen with Fedora 20 or OpenSuse 12.1 (do they have asserts off?).
Does this point to a flaw in the configuration or possibly a bug in Alsa-lib or can it occur just as a result of misuse of the Alsa API?
I will try to conceive some more tests. How can we debug this
further?
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=19dfeee29f73007e61a00a8fabe3c958f7cb8e87
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?
It can be reproduced by modify snd-dummy to use azx_pcm_hw
6 channels and softvol similar to hda controller which support arbitrary period size
snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_BUFFER_BYTES, 4);
snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 4);
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pc...
Slave can return err when call schange
snd_pcm_hw_params_t slave_params; int err; err = sprepare(pcm, &slave_params); assert(err >= 0); 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); return err;
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=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?
Regards
Alan
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
00:1b.0 0403: 8086:269a (rev 09) Subsystem: 8086:0419
{ PCI_DEVICE(0x8086, 0x269a), .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_INTEL_ICH },
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pc...
#define AZX_DCAPS_INTEL_ICH \ (AZX_DCAPS_OLD_SSYNC | AZX_DCAPS_NO_ALIGN_BUFSIZE)
Only AZX_DCAPS_INTEL_ICH use AZX_DCAPS_NO_ALIGN_BUFSIZE
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.
snd_hda_prealloc_size may affect the result
when your program let alsa lib to determine those buffer size, period and period size , snd_pcm_hw_params return error on 6 channels for some hda controllers
Your program return error when using "hw" instead of assert when using "front" with 6 channels
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=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?
thanks,
Takashi
--- 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);
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
participants (3)
-
Alan Horstmann -
Raymond Yau -
Takashi Iwai