Re: ALSA - pnp OS bios option

Re: ALSA - pnp OS bios option

[Clemens Ladisch]

Nick Warne wrote:
> 00:0f.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1
>
> If I turn OFF PNP OS, when I boot, 'alsactl restore' (run from
> rc.local) squinnies:
>
> Set_Control:894 Name mismatch ... Control #47
> 896: Index mismatch (0/0) for Control #47
> 1008: Bad control.47.value

This usually happens when you use a different driver version that has
different mixer controls so that the saved state in /etc/asound.state
doesn't match.

I don't know why the "PNP OS" setting should affect which mixer
controls are available.  What are the differences in /etc/asound.state
after "alsactl store" in both cases?


Clemens



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [Alsa-devel] Re: ALSA - pnp OS bios option

[Takashi Iwai]

At Tue, 10 Jan 2006 10:01:33 +0100,
Clemens Ladisch wrote:
> 
> Nick Warne wrote:
> > 00:0f.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1
> >
> > If I turn OFF PNP OS, when I boot, 'alsactl restore' (run from
> > rc.local) squinnies:
> >
> > Set_Control:894 Name mismatch ... Control #47
> > 896: Index mismatch (0/0) for Control #47
> > 1008: Bad control.47.value
> 
> This usually happens when you use a different driver version that has
> different mixer controls so that the saved state in /etc/asound.state
> doesn't match.

Use -F option for alsactl in your init script.


Takashi

Re: [Alsa-devel] Re: ALSA - pnp OS bios option

[Nick Warne]

On Tuesday 10 January 2006 11:27, Takashi Iwai wrote:

> > > Set_Control:894 Name mismatch ... Control #47
> > > 896: Index mismatch (0/0) for Control #47
> > > 1008: Bad control.47.value
> >
> > This usually happens when you use a different driver version that has
> > different mixer controls so that the saved state in /etc/asound.state
> > doesn't match.
>
> Use -F option for alsactl in your init script.

I see - specify the asound.state file to use.

So bios pnp OS ON/OFF both use different alsa drivers (or parts _of_ the 
driver) then - which in turn require different asound.state files?

Nick
-- 
"Person who say it cannot be done should not interrupt person doing it."
-Chinese Proverb

Re: Re: ALSA - pnp OS bios option

[Takashi Iwai]

At Tue, 10 Jan 2006 17:59:20 +0000,
Nick Warne wrote:
> 
> On Tuesday 10 January 2006 11:27, Takashi Iwai wrote:
> 
> > > > Set_Control:894 Name mismatch ... Control #47
> > > > 896: Index mismatch (0/0) for Control #47
> > > > 1008: Bad control.47.value
> > >
> > > This usually happens when you use a different driver version that has
> > > different mixer controls so that the saved state in /etc/asound.state
> > > doesn't match.
> >
> > Use -F option for alsactl in your init script.
> 
> I see - specify the asound.state file to use.
> 
> So bios pnp OS ON/OFF both use different alsa drivers (or parts _of_ the 
> driver) then - which in turn require different asound.state files?

No, I meant -F (a capical F), which means to force to set up the
controls even the number id mismatches.  This avoid the errors like
above.  (The default behavior of alsactl is a bit too strict.)

But, anyway, it's better to do the following:

- Boot with PnP ON, run "alsactl -f state-with-pnp store"
- Boot with PnP OFF, run "alsactl -f state-wo-pnp store"

then compare these two files.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: ALSA - pnp OS bios option

[Nick Warne]

On Tuesday 10 January 2006 18:12, Takashi Iwai wrote:

> > So bios pnp OS ON/OFF both use different alsa drivers (or parts _of_ the
> > driver) then - which in turn require different asound.state files?
>
> No, I meant -F (a capical F), which means to force to set up the
> controls even the number id mismatches.  This avoid the errors like
> above.  (The default behavior of alsactl is a bit too strict.)
>
> But, anyway, it's better to do the following:
>
> - Boot with PnP ON, run "alsactl -f state-with-pnp store"
> - Boot with PnP OFF, run "alsactl -f state-wo-pnp store"
>
> then compare these two files.

OK, sorry for a delay in reply - I haven't rebooted since last mail.

I have something _really_ peculiar ongoing on here (ignoring PnP - this isn't 
my issue now, I feel).

Info (lspci):
00:0f.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)
00:0f.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 
07)


This morning I built and installed 2.6.15.4.  On reboot, I got control errors 
again ('alsactl restore' is run from rc.local):


Sorting SB Live! sound (alsactl restore)...
alsactl: set_control:894: warning: name mismatch (Sigmatel Surround Playback 
Volume/Sigmatel Surround Playback Switch) for control #47
alsactl: set_control:896: warning: index mismatch (0/0) for control #47
alsactl: set_control:1008: bad control.47.value index


Ummm.  At the command line, same errors also.  So I deleted /etc/asound.state 
and reconfigured alsamixer from scratch.  Then following 'alsactl store', 
'alsactl restore' completes without issue (i.e. works clean).

If I then reboot, the same damn control #47 errors happen again.  It's as if 
something changes my asound.state file at boot time time?

Ideas?  This is driving me potty.

Nick
-- 
"Person who say it cannot be done should not interrupt person doing it."
-Chinese Proverb


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: [Alsa-devel] Re: ALSA - pnp OS bios option

[Nick]

> Ummm.  At the command line, same errors also.  So I deleted /etc/asound.state
> and reconfigured alsamixer from scratch.  Then following 'alsactl store',
> 'alsactl restore' completes without issue (i.e. works clean).
>
> If I then reboot, the same damn control #47 errors happen again.  It's as if
> something changes my asound.state file at boot time time?
>
> Ideas?  This is driving me potty.
>

OK, talking to myself (testing, testing, 1-2-3) - I have resolved this
issue after spending 2 hours trying to get my Mic to work again in
Teamspeak (why is there _so_ many frigging mixers
(alsamixer/amixer/aumix/kmix/arts) that all seem to do different
things...

I updated alsa-lib and alsa-utils to1.0.11rc3/rc2   This fixed my issues.

Now the question - there have been a lot of alsa changes (since my
alsa-tools was built Slack 10) - do we need to keep the alsa tools and
stuff current too?

Nick

Re: Re: ALSA - pnp OS bios option

[Lee Revell]

On Sat, 2006-02-11 at 10:54 +0000, Nick Warne wrote:
> Sorting SB Live! sound (alsactl restore)...
> alsactl: set_control:894: warning: name mismatch (Sigmatel Surround
> Playback 
> Volume/Sigmatel Surround Playback Switch) for control #47
> alsactl: set_control:896: warning: index mismatch (0/0) for control
> #47
> alsactl: set_control:1008: bad control.47.value index
> 
> 

Harmless

> Ummm.  At the command line, same errors also.  So I
> deleted /etc/asound.state 
> and reconfigured alsamixer from scratch.  Then following 'alsactl
> store', 
> 'alsactl restore' completes without issue (i.e. works clean).
> 
> If I then reboot, the same damn control #47 errors happen again.  It's
> as if 
> something changes my asound.state file at boot time time?
> 

Probably you have two different alsactl's installed, one that's
hardcoded to save the state in /etc/asound.state, and a distro version
that wants to save it in /var/lib/whatever.  It sounds like one is being
run at boot and a different one at shutdown.



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Re: ALSA - pnp OS bios option

[Lee Revell]

On Sat, 2006-02-11 at 13:56 +0000, Nick wrote:
> > Ummm.  At the command line, same errors also.  So I deleted /etc/asound.state
> > and reconfigured alsamixer from scratch.  Then following 'alsactl store',
> > 'alsactl restore' completes without issue (i.e. works clean).
> >
> > If I then reboot, the same damn control #47 errors happen again.  It's as if
> > something changes my asound.state file at boot time time?
> >
> > Ideas?  This is driving me potty.
> >
> 
> OK, talking to myself (testing, testing, 1-2-3) - I have resolved this
> issue after spending 2 hours trying to get my Mic to work again in
> Teamspeak (why is there _so_ many frigging mixers
> (alsamixer/amixer/aumix/kmix/arts) that all seem to do different
> things...

Because people keep writing half-assed mixers, rather than fixing the
existing ones, and distros inexplicably include 5 of them.  Half the
mixers out there only speak OSS, and distros ship them anyway.

Lee



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: [Alsa-devel] Re: ALSA - pnp OS bios option

[Lee Revell]

On Sat, 2006-02-11 at 13:56 +0000, Nick wrote:
> Now the question - there have been a lot of alsa changes (since my
> alsa-tools was built Slack 10) - do we need to keep the alsa tools and
> stuff current too? 

Yes - kernel upgrades should depend on alsa-lib upgrades (many distros
seem to get this wrong).  This should be fixed in the future, but it's
been this way for some time.

Lee

Re: Re: ALSA - pnp OS bios option

[Nick Warne]

On Saturday 11 February 2006 19:44, Lee Revell wrote:
> > If I then reboot, the same damn control #47 errors happen again.  It's
> > as if
> > something changes my asound.state file at boot time time?
>
> Probably you have two different alsactl's installed, one that's
> hardcoded to save the state in /etc/asound.state, and a distro version
> that wants to save it in /var/lib/whatever.  It sounds like one is being
> run at boot and a different one at shutdown.

First thing I thought of - Slackware is a 'clean, straight' distro though, and 
the only asound.state file I had was in /etc/ and only one alsactl in 
default /usr/sbin

On Saturday 11 February 2006 22:07, Lee Revell wrote:
> > do we need to keep the alsa tools and
> > stuff current too?
>
> Yes - kernel upgrades should depend on alsa-lib upgrades (many distros
> seem to get this wrong).  This should be fixed in the future, but it's
> been this way for some time.

Well, it appears to have fixed the issues I had.  Several reboots since and no 
problems now.

Looking back, originally I had a 2.4.x kernel - I have since upgraded to 2.6.x 
series, plus built a lot of new tools and such from source - all except alsa 
stuff, of course - so it does make sense and I kick myself for not thinking 
about this in the beginning.  One to remember.

Thanks,

Nick
-- 
"Person who say it cannot be done should not interrupt person doing it."
-Chinese Proverb


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642