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@xxxxxxx> wrote:
> On Fri, 3 Aug 2007 11:20:49 -0700
> stan <stanl@xxxxxxx> 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
> >
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
