Hi,

Michael Trimarchi wrote:
Hi,

Andy Green wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| On Sat, Jan 31, 2009 at 11:33 AM, Andy Green <[email protected]>
| (cut)
|> It seems 2.6.29 has impacted this because otherwise we did not meddle
|> with this area.
|
| Do you think we need to try a newer version of alsa in the rootfs?
| I've read alsa has been changing.

I don't think it's that simple.  I saw there are changes pending off
alsa list from Mark Brown including one that Michael took care about
already (NULL regigstration lookups we saw).

I fear we have to dig into the thing enough to understand why the mixer
controls have gone away.

Either it's intentional and wm8753 driver changed to no longer expose
them, or it's accidental and then we are not setting the state of those
hardware elements any more down at the chip with aslactl.
I don't check a lot, but that controls exist, or now the access to them report an error to the alsa library? When alsa library do the cycle to read the config
file and fails, abort all other control registration and inizialization.
The best thing is to have a compiled version of amixer for freerunnner. Anyone can
provide one or I must add some code in android init mixer to dump the list.

What will give results is build an older version, and add printks to see
where and when these now missing mixer controls get registered.  Then go
back to HEAD and follow the same path until it differs, then we know the
issue.

I do a test with the older version and all seems to be equal. I recompile test control.c and report the same structure. The filesystem is the same, the widget element too. I will
check for mixer name that I removed, can you check too?
If the dump is the same the problem is that the controls never exist. Maybe the list is the same but the name are different a little bit. The only thing that is different is how are composed the
long name:

       /* check client and interface hw capabilities */
- sprintf(new_name, "%s %s-%s-%d", dai_link->stream_name, codec_dai->name,
-               get_dai_name(cpu_dai->type), num);
+ sprintf(new_name, "%s %s-%d", dai_link->stream_name, codec_dai->name,
+               num);

 ret = snd_pcm_new(codec->card, new_name, codec->pcm_devs++, playback,
               capture, &pcm);

But I think is related to the capture/playback device. The only big change seems the registration
of the controls. The amixer dump gives us the answer I think.

Michael

Reply via email to