[alsa-devel] Problems with safe API and snd-cs46xx
tiwai at suse.de
Wed Sep 9 14:35:02 CEST 2009
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 18.104.22.168 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
> 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.
More information about the Alsa-devel