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

[Takashi Iwai]

At Wed, 9 Sep 2009 13:29:02 +0100,
Sophie Hamilton wrote:
> 
> 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.

This should work in both version since the relevant code hasn't been
change for very long time.

> 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. :/

Yes, likely.  The app like openal is usually more sensible regarding
latency, so "safe API" described there wasn't appropriate at all.

> 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.

Or, openal is using OSS?  You can see
/proc/asound/card0/pcm0p/hw_params whether it's OSS emulation mode or
not.  In OSS mode, OSS parameters are shown there in addition.

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

Thanks, that's enough for now.
I pushed the patch to alsa-lib git tree now.


Takashi