[alsa-devel] No state is present for card CMI8738
Since alsa-user is rather ... errr ... silent, I dare to repost the same question here.
I've seen that Alsa likes the Terratec cards, however since they're also based on the CMI chipset, and at least /my/ onboard CMI chipset here sucks badly I wonder what low cost card I can use?
I hope somebody can give me a clue, *t
PS: Mic input is barely loud enough with my onboard sound. Mic boost has no effect.
-- ----------------------------------------------------------- Tomas Pospisek http://sourcepole.com - Linux & Open Source Solutions -----------------------------------------------------------
---------- Forwarded message ---------- Date: Mon, 14 May 2007 14:39:36 +0200 (CEST) From: Tomas Pospisek's Mailing Lists tpo2@sourcepole.ch To: alsa-user@lists.sourceforge.net Subject: [Alsa-user] No state is present for card CMI8738
The following is my problem:
$ alsactl -f .alsavoip restore No state is present for card CMI8738
I see this "sometimes". Sometimes the above works and sometimes it returns with that error message.
It needs to be noted that I am suspending to ram. Nevertheless, the behaveour is not consistent in between "s2ram"s and I don't know whether that has anything to do with it either.
It also needs to be noted that alsamixer *never* has any problems accessing the card. But even after changing the card settings with alsamixer, alsactl will keep on repeating that error message.
* $ lspci 00:0d.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)
* alsa userspace is at 1.0.13 * kernel is Debian's 2.6.18-4-686
Further, minor problems:
* After waking up from suspend the card looses its microphone settings - that is - "Mic Capture" is allway reset to zero.
* Further on the choice to hide the microphone setting "Mic Capture" in alsamixer behind F5 irritates me a bit - there are *a lot* of very obscure settings (such as "IEC958 5V" - huh?), that are displayed by default.
What's up with that error above? What does it mean? Is there any way I can fix or circumvent it? Anybody a hint? *t
-- ----------------------------------------------------------- Tomas Pospisek http://sourcepole.com - Linux & Open Source Solutions -----------------------------------------------------------
------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Since I got no feedback neither here nor on the users list, may I ask why?
* is it that nobody knows the answer to my question? * or is it because the question is stupid (as in: read the FAQ, the wiki, the archive and use google (all of which did not help me btw.))
? *t
On Wed, 14 May 2007, Tomas Pospisek's Mailing Lists wrote [modified for clarity]:
[...]
---------- Forwarded message ---------- Date: Mon, 14 May 2007 14:39:36 +0200 (CEST) From: Tomas Pospisek's Mailing Lists tpo2@sourcepole.ch To: alsa-user@lists.sourceforge.net Subject: [Alsa-user] No state is present for card CMI8738
The following is my problem:
$ alsactl -f .alsavoip restore No state is present for card CMI8738
I see this "sometimes". Sometimes the above works and sometimes it returns with that error message.
I happen to be suspending to ram regulary. Nevertheless, the behaveour is not consistent in between "s2ram"s and I don't know whether that has anything to do with it either.
It also needs to be noted that alsamixer *never* has any problems accessing the card. But even after changing the card settings with alsamixer, alsactl will keep on repeating that error message.
$ lspci 00:0d.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)
alsa userspace is at 1.0.13
kernel is Debian's 2.6.18-4-686
Further, minor problems:
After waking up from suspend the card looses its microphone settings - that is - "Mic Capture" is allway reset to zero.
Further on the choice to hide the microphone setting "Mic Capture" in alsamixer behind F5 irritates me a bit - there are *a lot* of very obscure settings (such as "IEC958 5V" - huh?), that are displayed by default.
I've seen that Alsa likes the Terratec cards, however since they're also based on the CMI chipset, and at least /my/ onboard CMI chipset here sucks badly I wonder what low cost card (other than CMI based ones) are recommended?
Mic input is barely loud enough with my onboard sound. Mic boost has no effect.
What's up with that error above? What does it mean? Is there any way I can fix or circumvent it? Anybody a hint? *t
-- ----------------------------------------------------------- Tomas Pospisek http://sourcepole.com - Linux & Open Source Solutions -----------------------------------------------------------
At Fri, 18 May 2007 16:42:51 +0200 (CEST), Tomas Pospisek's Mailing Lists wrote:
Since I got no feedback neither here nor on the users list, may I ask why?
- is it that nobody knows the answer to my question?
- or is it because the question is stupid (as in: read the FAQ, the wiki, the archive and use google (all of which did not help me btw.))
Because you pasted the whole things below your signature. I didn't read texts below the signature because they are usually quoted texts.
Regarding the alsactl problem. When alsactl returns 'no state is present', then it's not necessarily a driver problem but could be rather a system problem. At least, you have to figure out what is the cause. For example, check /proc/asound/cards whether the driver is really loaded when you call alsactl.
Takashi
On Mon, 21 May 2007, Takashi Iwai wrote:
At Fri, 18 May 2007 16:42:51 +0200 (CEST), Tomas Pospisek's Mailing Lists wrote:
Since I got no feedback neither here nor on the users list, may I ask why?
- is it that nobody knows the answer to my question?
- or is it because the question is stupid (as in: read the FAQ, the wiki, the archive and use google (all of which did not help me btw.))
Because you pasted the whole things below your signature. I didn't read texts below the signature because they are usually quoted texts.
Thanks a lot for your reply and sorry for that.
Regarding the alsactl problem. When alsactl returns 'no state is present', then it's not necessarily a driver problem but could be rather a system problem. At least, you have to figure out what is the cause. For example, check /proc/asound/cards whether the driver is really loaded when you call alsactl.
Well, actually I figured out one cause of the problem, namely that alsactl wasn't able to access the configuration file. My dumb, but nevertheless, alsactl could be way clearer about telling the user what's wrong.
I suggest the attached patches to improve the comprehensibility of alsactl's (error-)behaveour.
Description of patches:
* diff_display_error_on_failing_open_in_load_state: Tells the user that it was not able to open the config file with the precise error message.
* diff_more_explicit_open_w_error_message: Include more explicit error message when open config file in write mode (this is for the "names" command)
* diff_more_explicit_open_w_error_message2 same as last patch, this time for the store command
Other little patches:
* diff_missing_space_in_help: adds a space in the help text between "restore" and "<card>" and indents the rest of the text accordingly to fit
* diff4_display_help_for_names_command: shortly explain the "names" command in the help text
*t
-- ----------------------------------------------------------- Tomas Pospisek http://sourcepole.com - Linux & Open Source Solutions -----------------------------------------------------------
At Tue, 22 May 2007 23:02:29 +0200 (CEST), Tomas Pospisek's Mailing Lists wrote:
Regarding the alsactl problem. When alsactl returns 'no state is present', then it's not necessarily a driver problem but could be rather a system problem. At least, you have to figure out what is the cause. For example, check /proc/asound/cards whether the driver is really loaded when you call alsactl.
Well, actually I figured out one cause of the problem, namely that alsactl wasn't able to access the configuration file. My dumb, but nevertheless, alsactl could be way clearer about telling the user what's wrong.
Glad to hear it's no real bug :)
I suggest the attached patches to improve the comprehensibility of alsactl's (error-)behaveour.
Description of patches:
diff_display_error_on_failing_open_in_load_state: Tells the user that it was not able to open the config file with the precise error message.
diff_more_explicit_open_w_error_message: Include more explicit error message when open config file in write mode (this is for the "names" command)
diff_more_explicit_open_w_error_message2 same as last patch, this time for the store command
Other little patches:
diff_missing_space_in_help: adds a space in the help text between "restore" and "<card>" and indents the rest of the text accordingly to fit
diff4_display_help_for_names_command: shortly explain the "names" command in the help text
Thanks for patches. I applied them to HG tree with minor fixes:
- fix indentation in diff_display_error_on_failing_open_in_load_state - added "(DEPRECATED)" to help text in diff4_display_help_for_names_command (names command is deprecated and provided just for compatibility)
Please check the latest tree if it's OK for you.
Takashi
participants (2)
-
Takashi Iwai -
Tomas Pospisek's Mailing Lists