[alsa-devel] Problems with safe API and snd-cs46xx

[Sophie Hamilton]

On 9/9/09, Takashi Iwai <tiwai at suse.de> wrote:
> It turned out that the hw_params determination is done rather inside
>  the alsa-lib beforehand.
>
>  Try the patch below.  This will give you larger buffer size with
>  audacious.  (And it will work without the driver changes.)
>
>  For any apps that require the old behavior, I added the check of
>  $LIBASOUND_COMPAT variable.

Since this patch is for alsa-lib and not for the kernel, this forced
me to check what version I was currently using, which turned out to be
1.0.20. (specifically, media-libs/alsa-lib-1.0.20-r1) 1.0.21 hadn't
yet been keyworded on my architecture (x86) as stable.

So for my first test, I forced 1.0.21 to install anyway, then made
sure the 2.6.30.5 kernel I was using was unpatched, then rebooted to
test whether the upgrade to 1.0.21 (unpatched) would have made any
difference anyway. It didn't; the sound was the same as it was before.

Then, I copied the alsa-lib ebuild to a local Gentoo repository and
modified it to apply your patch. (I don't know what tricks Gentoo
might have up its sleeve for components as core as this, so I didn't
feel comfortable taking the raw source. It shouldn't made a
difference, but if you'd prefer me to try, I can see what I can do. I
can't promise that any problems would be necessarily from this,
though.) I compiled and installed the new patched 1.0.21, and
rebooted.

I can confirm now that Audacious does indeed play correctly where it
didn't before. However, using mplayer with the "-ao openal" switch
still doesn't play correctly - in fact, it sounds the same as before -
so it looks like OpenAL is actually doing things slightly differently
than I thought. :/

As a final test, I removed the patch from alsa-lib and re-patched the
kernel with my patch to change the minimum period size to 64 for
cs46xx, so that I could check whether it would still work with the new
alsa-lib 1.0.21 (rather than the 1.0.20 that I was using before). It
does indeed work, in both Audacious and OpenAL.

So... I'm not sure what's up with OpenAL in this case. Is there
anything more I can do to help?

 - Sophie.