[alsa-devel] snd_pcm_hw_params_set_format fails with invalid argument
Fedora 7 upgraded alsa to 1.0.14 from RC3. I was going to test the default device sound for my prior problem (as requested by Takashi weeks ago). Unfortunately when I try to run my app it won't start. The snd_pcm_hw_params_set_format fails when I try to use it as follows.
err = snd_pcm_hw_params_set_access (alsa_dev, hw_params, ND_PCM_ACCESS_RW_INTERLEAVED); if (err < 0) { fprintf (stderr, "cannot set access type (%s)\n", snd_strerror (err)) ; goto catch_error ; } ;
err = snd_pcm_hw_params_set_format (alsa_dev, hw_params, SND_PCM_FORMAT_FLOAT64_LE); //err = snd_pcm_hw_params_set_format (alsa_dev, hw_params, SND_PCM_FORMAT_S32_LE); if (err < 0) { fprintf (stderr, "cannot set sample format (%s)\n", snd_strerror (err)) ; goto catch_error ; } ;
cannot set sample format (Invalid argument)
It compiles cleanly. When I replace the SND_PCM_FORMAT_FLOAT64_LE with the S32_LE, it sets it, but of course the sound is garbage as it is still receiving doubles.
This code worked fine under RC3. Is there some change that occurred in the step from 1.0.14.rc3 to 1.0.14 that would explain the above and suggest a fix?
Thank you.
$ uname -r 2.6.22.1-41.fc7
$ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.14 (Thu May 31 09:03:25 2007 UTC).
$ ls /proc/asound/card0 ice1724 id oss_mixer pcm0c pcm0p pcm1p pcm2p
On Fri, 3 Aug 2007 11:20:49 -0700 stan stanl@cox.net wrote:
Fedora 7 upgraded alsa to 1.0.14 from RC3. I was going to test the default device sound for my prior problem (as requested by Takashi weeks ago). Unfortunately when I try to run my app it won't start. The snd_pcm_hw_params_set_format fails when I try to use it as follows.
err = snd_pcm_hw_params_set_access (alsa_dev, hw_params, ND_PCM_ACCESS_RW_INTERLEAVED); if (err < 0) { fprintf (stderr, "cannot set access type (%s)\n", snd_strerror (err)) ; goto catch_error ; } ;
err = snd_pcm_hw_params_set_format (alsa_dev, hw_params, SND_PCM_FORMAT_FLOAT64_LE); //err = snd_pcm_hw_params_set_format (alsa_dev, hw_params, SND_PCM_FORMAT_S32_LE); if (err < 0) { fprintf (stderr, "cannot set sample format (%s)\n", snd_strerror (err)) ; goto catch_error ; } ;
cannot set sample format (Invalid argument)
It compiles cleanly. When I replace the SND_PCM_FORMAT_FLOAT64_LE with the S32_LE, it sets it, but of course the sound is garbage as it is still receiving doubles.
This code worked fine under RC3. Is there some change that occurred in the step from 1.0.14.rc3 to 1.0.14 that would explain the above and suggest a fix?
Used gdb to look at what was happening here. It seems to succeed in the alsa lib but a return value gets translated from 1 to -22.
int _snd_pcm_hw_param_set(snd_pcm_hw_params_t *params, snd_pcm_hw_param_t var, unsigned int val, int dir) { int changed; if (hw_is_mask(var)) { snd_mask_t *m = hw_param_mask(params, var); if (val == 0 && dir < 0) { changed = -EINVAL; snd_mask_none(m); } else { if (dir > 0) val++; else if (dir < 0) val--; changed = snd_mask_refine_set(hw_param_mask(params, var), val); } <-- returns 1, change occurred ... if (changed) { <-- this branch is taken params->cmask |= 1 << var; params->rmask |= 1 << var; } return changed; <-- changed is still 1 at this point }
In the function below, which calls the function above, gdb tells me the return value, err, has been optimized away when I try to check it. When I check the return value in the calling program for the function below it is -22.
int snd_pcm_hw_param_set(snd_pcm_t *pcm, snd_pcm_hw_params_t *params, snd_set_mode_t mode, snd_pcm_hw_param_t var, unsigned int val, int dir) { snd_pcm_hw_params_t save; int err; switch (mode) { case SND_CHANGE: break; case SND_TRY: save = *params; <-- takes this branch break; case SND_TEST: save = *params; params = &save; break; default: assert(0); return -EINVAL; }
err is optimized away in the code below, but must be less than zero as it takes the _fail branch. The return value from the function above is 1 so it shouldn't be taking the fail branch.
err = _snd_pcm_hw_param_set(params, var, val, dir); if (err < 0) goto _fail;
When I ignore the return value in my program from within gdb, everything runs, but the sound is incorrect (static). And I get a garbage value back.
Format (3157552) <-- actual value set by alsa-lib Format (3157552) differs from requested (16) <-- this is SND_PCM_FORMAT_FLOAT64
When I ignore the return value in my program with optimization (O2) turned on, everything runs but the sound is incorrect (static). The value that comes back is different though.
Format (0) <-- actual value set by alsa-lib Format (0) differs from requested (16) <-- this is SND_PCM_FORMAT_FLOAT64
I find it hard to believe that this is a compiler optimization error. It seems like the stack is becoming corrupted for just one call. All other calls succeed.
Has anyone a suggestion of where the error might be or a possible workaround? Could invalid values in the ICE1724 driver cause this?
Thank you.
$ uname -r 2.6.22.1-41.fc7
$ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.14 (Thu May 31 09:03:25 2007 UTC).
$ ls /proc/asound/card0 ice1724 id oss_mixer pcm0c pcm0p pcm1p pcm2p
I downloaded the hg alsa-lib snapshot of July 14, 2007, compiled it, (on Fedora 7 you will have to make a link to compile, cd /usr/include ln -s python2.5 python) and linked my program against it. It works again so the issue has been fixed in the latest version of alsa lib. Any estimate of when this version will be released for public consumption? My app is dead in the water with the current version of alsa, so anyone trying to use it will have a terrible user experience. :-( I want to give some indication of when people can expect it to start working again. In the meantime I'll create instructions on how to install the hg version to usr/local and change the library linking.
Thanks.
On Sun, 5 Aug 2007 13:10:41 -0700 stan stanl@cox.net wrote:
On Fri, 3 Aug 2007 11:20:49 -0700 stan stanl@cox.net wrote:
Fedora 7 upgraded alsa to 1.0.14 from RC3. I was going to test the default device sound for my prior problem (as requested by Takashi weeks ago). Unfortunately when I try to run my app it won't start. The snd_pcm_hw_params_set_format fails when I try to use it as follows.
err = snd_pcm_hw_params_set_access (alsa_dev, hw_params, ND_PCM_ACCESS_RW_INTERLEAVED); if (err < 0) { fprintf (stderr, "cannot set access type (%s)\n", snd_strerror (err)) ; goto catch_error ; } ;
err = snd_pcm_hw_params_set_format (alsa_dev, hw_params, SND_PCM_FORMAT_FLOAT64_LE); //err = snd_pcm_hw_params_set_format (alsa_dev, hw_params, SND_PCM_FORMAT_S32_LE); if (err < 0) { fprintf (stderr, "cannot set sample format (%s)\n", snd_strerror (err)) ; goto catch_error ; } ;
cannot set sample format (Invalid argument)
It compiles cleanly. When I replace the SND_PCM_FORMAT_FLOAT64_LE with the S32_LE, it sets it, but of course the sound is garbage as it is still receiving doubles.
This code worked fine under RC3. Is there some change that occurred in the step from 1.0.14.rc3 to 1.0.14 that would explain the above and suggest a fix?
Used gdb to look at what was happening here. It seems to succeed in the alsa lib but a return value gets translated from 1 to -22.
int _snd_pcm_hw_param_set(snd_pcm_hw_params_t *params, snd_pcm_hw_param_t var, unsigned int val, int dir) { int changed; if (hw_is_mask(var)) { snd_mask_t *m = hw_param_mask(params, var); if (val == 0 && dir < 0) { changed = -EINVAL; snd_mask_none(m); } else { if (dir > 0) val++; else if (dir < 0) val--; changed = snd_mask_refine_set(hw_param_mask(params, var), val); } <-- returns 1, change occurred ... if (changed) { <-- this branch is taken params->cmask |= 1 << var; params->rmask |= 1 << var; } return changed; <-- changed is still 1 at this point }
In the function below, which calls the function above, gdb tells me the return value, err, has been optimized away when I try to check it. When I check the return value in the calling program for the function below it is -22.
int snd_pcm_hw_param_set(snd_pcm_t *pcm, snd_pcm_hw_params_t *params, snd_set_mode_t mode, snd_pcm_hw_param_t var, unsigned int val, int dir) { snd_pcm_hw_params_t save; int err; switch (mode) { case SND_CHANGE: break; case SND_TRY: save = *params; <-- takes this branch break; case SND_TEST: save = *params; params = &save; break; default: assert(0); return -EINVAL; }
err is optimized away in the code below, but must be less than zero as it takes the _fail branch. The return value from the function above is 1 so it shouldn't be taking the fail branch.
err = _snd_pcm_hw_param_set(params, var, val, dir); if (err < 0) goto _fail;
When I ignore the return value in my program from within gdb, everything runs, but the sound is incorrect (static). And I get a garbage value back.
Format (3157552) <-- actual value set by alsa-lib Format (3157552) differs from requested (16) <-- this is SND_PCM_FORMAT_FLOAT64
When I ignore the return value in my program with optimization (O2) turned on, everything runs but the sound is incorrect (static). The value that comes back is different though.
Format (0) <-- actual value set by alsa-lib Format (0) differs from requested (16) <-- this is SND_PCM_FORMAT_FLOAT64
I find it hard to believe that this is a compiler optimization error. It seems like the stack is becoming corrupted for just one call. All other calls succeed.
Has anyone a suggestion of where the error might be or a possible workaround? Could invalid values in the ICE1724 driver cause this?
Thank you.
$ uname -r 2.6.22.1-41.fc7
$ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.14 (Thu May 31 09:03:25 2007 UTC).
$ ls /proc/asound/card0 ice1724 id oss_mixer pcm0c pcm0p pcm1p pcm2p
On Mon, 6 Aug 2007 09:04:57 -0700 stan stanl@cox.net wrote:
I downloaded the hg alsa-lib snapshot of July 14, 2007, compiled it, (on Fedora 7 you will have to make a link to compile, cd /usr/include ln -s python2.5 python) and linked my program against it. It works again so the issue has been fixed in the latest version of alsa lib. Any estimate of when this version will be released for public consumption? My app is dead in the water with the current version of alsa, so anyone trying to use it will have a terrible user experience. :-( I want to give some indication of when people can expect it to start working again. In the meantime I'll create instructions on how to install the hg version to usr/local and change the library linking.
Thanks.
For anyone interested, these are the formats that fail in 1.0.14 final
Value of last format 43 test of sample format 14 failed (Invalid argument) test of sample format 15 failed (Invalid argument) test of sample format 16 failed (Invalid argument) test of sample format 17 failed (Invalid argument) test of sample format 18 failed (Invalid argument) test of sample format 19 failed (Invalid argument) test of sample format 23 failed (Invalid argument) test of sample format 24 failed (Invalid argument) test of sample format 25 failed (Invalid argument) test of sample format 26 failed (Invalid argument) test of sample format 27 failed (Invalid argument) test of sample format 28 failed (Invalid argument) test of sample format 29 failed (Invalid argument) test of sample format 30 failed (Invalid argument) test of sample format 31 failed (Invalid argument) Format returned (0)
and these are the formats that fail in the hg version.
Value of last format 43 test of sample format 18 failed (Invalid argument) test of sample format 19 failed (Invalid argument) test of sample format 23 failed (Invalid argument) test of sample format 24 failed (Invalid argument) test of sample format 25 failed (Invalid argument) test of sample format 26 failed (Invalid argument) test of sample format 27 failed (Invalid argument) test of sample format 28 failed (Invalid argument) test of sample format 29 failed (Invalid argument) test of sample format 30 failed (Invalid argument) test of sample format 31 failed (Invalid argument) Format returned (16)
Because I am using format 16 (FLOAT64_LE), it now works. Because FLOAT64_BE is 17, it probably will still fail, but I have no way of checking. Sun? PowerPC?
Section of format enum from pcm.h
/** Float 32 bit Little Endian, Range -1.0 to 1.0 */ SND_PCM_FORMAT_FLOAT_LE, /** Float 32 bit Big Endian, Range -1.0 to 1.0 */ SND_PCM_FORMAT_FLOAT_BE, /** Float 64 bit Little Endian, Range -1.0 to 1.0 */ #16 SND_PCM_FORMAT_FLOAT64_LE, /** Float 64 bit Big Endian, Range -1.0 to 1.0 */ SND_PCM_FORMAT_FLOAT64_BE, /** IEC-958 Little Endian */ SND_PCM_FORMAT_IEC958_SUBFRAME_LE, /** IEC-958 Big Endian */ SND_PCM_FORMAT_IEC958_SUBFRAME_BE, /** Mu-Law */ SND_PCM_FORMAT_MU_LAW, /** A-Law */ SND_PCM_FORMAT_A_LAW, /** Ima-ADPCM */ SND_PCM_FORMAT_IMA_ADPCM, /** MPEG */ SND_PCM_FORMAT_MPEG, /** GSM */ SND_PCM_FORMAT_GSM, /** Special */ SND_PCM_FORMAT_SPECIAL = 31, /** Signed 24bit Little Endian in 3bytes format */ SND_PCM_FORMAT_S24_3LE = 32,
On Sun, 5 Aug 2007 13:10:41 -0700 stan stanl@cox.net wrote:
On Fri, 3 Aug 2007 11:20:49 -0700 stan stanl@cox.net wrote:
Fedora 7 upgraded alsa to 1.0.14 from RC3. I was going to test the default device sound for my prior problem (as requested by Takashi weeks ago). Unfortunately when I try to run my app it won't start. The snd_pcm_hw_params_set_format fails when I try to use it as follows.
err = snd_pcm_hw_params_set_access (alsa_dev, hw_params, ND_PCM_ACCESS_RW_INTERLEAVED); if (err < 0) { fprintf (stderr, "cannot set access type (%s)\n", snd_strerror (err)) ; goto catch_error ; } ;
err = snd_pcm_hw_params_set_format (alsa_dev, hw_params, SND_PCM_FORMAT_FLOAT64_LE); //err = snd_pcm_hw_params_set_format (alsa_dev, hw_params, SND_PCM_FORMAT_S32_LE); if (err < 0) { fprintf (stderr, "cannot set sample format (%s)\n", snd_strerror (err)) ; goto catch_error ; } ;
cannot set sample format (Invalid argument)
It compiles cleanly. When I replace the SND_PCM_FORMAT_FLOAT64_LE with the S32_LE, it sets it, but of course the sound is garbage as it is still receiving doubles.
This code worked fine under RC3. Is there some change that occurred in the step from 1.0.14.rc3 to 1.0.14 that would explain the above and suggest a fix?
Used gdb to look at what was happening here. It seems to succeed in the alsa lib but a return value gets translated from 1 to -22.
int _snd_pcm_hw_param_set(snd_pcm_hw_params_t *params, snd_pcm_hw_param_t var, unsigned int val, int dir) { int changed; if (hw_is_mask(var)) { snd_mask_t *m = hw_param_mask(params, var); if (val == 0 && dir < 0) { changed = -EINVAL; snd_mask_none(m); } else { if (dir > 0) val++; else if (dir < 0) val--; changed = snd_mask_refine_set(hw_param_mask(params, var), val); } <-- returns 1, change occurred ... if (changed) { <-- this branch is taken params->cmask |= 1 << var; params->rmask |= 1 << var; } return changed; <-- changed is still 1 at this point }
In the function below, which calls the function above, gdb tells me the return value, err, has been optimized away when I try to check it. When I check the return value in the calling program for the function below it is -22.
int snd_pcm_hw_param_set(snd_pcm_t *pcm, snd_pcm_hw_params_t *params, snd_set_mode_t mode, snd_pcm_hw_param_t var, unsigned int val, int dir) { snd_pcm_hw_params_t save; int err; switch (mode) { case SND_CHANGE: break; case SND_TRY: save = *params; <-- takes this branch break; case SND_TEST: save = *params; params = &save; break; default: assert(0); return -EINVAL; }
err is optimized away in the code below, but must be less than zero as it takes the _fail branch. The return value from the function above is 1 so it shouldn't be taking the fail branch.
err = _snd_pcm_hw_param_set(params, var, val, dir); if (err < 0) goto _fail;
When I ignore the return value in my program from within gdb, everything runs, but the sound is incorrect (static). And I get a garbage value back.
Format (3157552) <-- actual value set by alsa-lib Format (3157552) differs from requested (16) <-- this is SND_PCM_FORMAT_FLOAT64
When I ignore the return value in my program with optimization (O2) turned on, everything runs but the sound is incorrect (static). The value that comes back is different though.
Format (0) <-- actual value set by alsa-lib Format (0) differs from requested (16) <-- this is SND_PCM_FORMAT_FLOAT64
I find it hard to believe that this is a compiler optimization error. It seems like the stack is becoming corrupted for just one call. All other calls succeed.
Has anyone a suggestion of where the error might be or a possible workaround? Could invalid values in the ICE1724 driver cause this?
Thank you.
$ uname -r 2.6.22.1-41.fc7
$ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.14 (Thu May 31 09:03:25 2007 UTC).
$ ls /proc/asound/card0 ice1724 id oss_mixer pcm0c pcm0p pcm1p pcm2p
At Mon, 6 Aug 2007 09:22:01 -0700, stan wrote:
On Mon, 6 Aug 2007 09:04:57 -0700 stan stanl@cox.net wrote:
I downloaded the hg alsa-lib snapshot of July 14, 2007, compiled it, (on Fedora 7 you will have to make a link to compile, cd /usr/include ln -s python2.5 python) and linked my program against it. It works again so the issue has been fixed in the latest version of alsa lib. Any estimate of when this version will be released for public consumption? My app is dead in the water with the current version of alsa, so anyone trying to use it will have a terrible user experience. :-( I want to give some indication of when people can expect it to start working again. In the meantime I'll create instructions on how to install the hg version to usr/local and change the library linking.
Thanks.
For anyone interested, these are the formats that fail in 1.0.14 final
Value of last format 43 test of sample format 14 failed (Invalid argument) test of sample format 15 failed (Invalid argument) test of sample format 16 failed (Invalid argument) test of sample format 17 failed (Invalid argument) test of sample format 18 failed (Invalid argument) test of sample format 19 failed (Invalid argument) test of sample format 23 failed (Invalid argument) test of sample format 24 failed (Invalid argument) test of sample format 25 failed (Invalid argument) test of sample format 26 failed (Invalid argument) test of sample format 27 failed (Invalid argument) test of sample format 28 failed (Invalid argument) test of sample format 29 failed (Invalid argument) test of sample format 30 failed (Invalid argument) test of sample format 31 failed (Invalid argument) Format returned (0)
and these are the formats that fail in the hg version.
Value of last format 43 test of sample format 18 failed (Invalid argument) test of sample format 19 failed (Invalid argument) test of sample format 23 failed (Invalid argument) test of sample format 24 failed (Invalid argument) test of sample format 25 failed (Invalid argument) test of sample format 26 failed (Invalid argument) test of sample format 27 failed (Invalid argument) test of sample format 28 failed (Invalid argument) test of sample format 29 failed (Invalid argument) test of sample format 30 failed (Invalid argument) test of sample format 31 failed (Invalid argument) Format returned (16)
Could you give me the simple test case for checking the same thing on my system?
thanks,
Takashi
participants (2)
-
stan
-
Takashi Iwai