[alsa-devel] "alsactl store" fails to save Echo Gina3G mixer
Greetings,
I have two PCI sound cards in my PC: 1. Sound Blaster Audigy 2 ZS Gold (primary card) 2. Echo Gina3G
If I save the mixer for the Audigy 2 via:
alsactl -f ~/asound0.state store 0
...the Audigy 2's mixer is properly saved.
However, when I try to save the Gina3G mixer:
alsactl -f ~/asound1.state store 1
...I get the following error:
alsactl: control.c:2513: snd_ctl_elem_value_get_integer: Assertion `idx < sizeof(obj->value.integer.value) / sizeof(obj->value.integer.value[0])' failed. Aborted
I have tried to find any info on this error online, but to no avail. Does anybody know what is going on here?
** My System ** OS: KDE Neon 5.10.5 64-bit (Plasma Desktop 5.10.5, KDE Frameworks 5.37.0, Qt 5.9.1) Linux Kernel: 4.10.0.32-generic Motherboard: ASRock X58 Extreme3 (Intel X58 chipset) CPU: Intel Core i7 930 (2.8 GHz quad-core) RAM: 12GB DDR3 Video: NVIDIA GeForce GTX 970 w/ 4GB RAM (PCI Express) Sound Card #1: Sound Blaster Audigy 2 ZS Gold Sound Card #2: Echo Gina3G NVIDIA video driver: 375.66
Hi,
On Aug 29 2017 00:34, S. Christian Collins wrote:
However, when I try to save the Gina3G mixer:
alsactl -f ~/asound1.state store 1
...I get the following error:
alsactl: control.c:2513: snd_ctl_elem_value_get_integer: Assertion `idx < sizeof(obj->value.integer.value) / sizeof(obj->value.integer.value[0])' failed. Aborted
I have tried to find any info on this error online, but to no avail. Does anybody know what is going on here?
The value of 'sizeof(obj->value.integer.value) / sizeof(obj->value.integer.value[0])' has fixed value (=128), therefore the value of 'idx' is greater than 128, against expectation.
Would you get output from below command line for your Gina 3G?
$ amixer scontrols
And typically state data is stored into '/var/lib/alsa/asound.state' as a default. For my information, could you disclose it if possible?
Regards
Takashi Sakamoto
On 08/28/2017 10:33 PM, Takashi Sakamoto wrote:
Would you get output from below command line for your Gina 3G?
$ amixer scontrols
The output of "amixer -c 1 scontrols" is attached to this e-mail as "scontrols.txt".
And typically state data is stored into '/var/lib/alsa/asound.state' as a default. For my information, could you disclose it if possible?
Yes, it is also attached to this e-mail. The asound.state file was last modified on March 26th. I remember that I used to not get the error when using "alsactl store", so perhaps an update caused this issue to appear around that time?
-~Chris
On Aug 29 2017 12:46, S. Christian Collins wrote:
On 08/28/2017 10:33 PM, Takashi Sakamoto wrote:
Would you get output from below command line for your Gina 3G?
$ amixer scontrols
The output of "amixer -c 1 scontrols" is attached to this e-mail as "scontrols.txt".
And typically state data is stored into '/var/lib/alsa/asound.state' as a default. For my information, could you disclose it if possible?
Yes, it is also attached to this e-mail. The asound.state file was last modified on March 26th. I remember that I used to not get the error when using "alsactl store", so perhaps an update caused this issue to appear around that time?
$ alsactl -f ~/asound1.state store 1 (alsa-utils:alsactl/alsactl.c) main() (alsa-utils:alsactl/state.c) ->save_state() ->get_controls() ->get_control() snd_ctl_elem_info(info) count = snd_ctl_elem_info_get_count(info) for (i = 0; i < count; i++) snd_ctl_elem_value_get_integer(ctl, i)
I guess that 'snd-echo3g.ko' returns value greater than 128 in a call graph of 'snd_ctl_elem_info_get_count()', then a call of 'snd_ctl_elem_value_get_integer()' hits an assertion in the function.
A patch mentioned by Mark Hills (a commit 275353bb684e 'ALSA: echoaudio: purge contradictions between dimension matrix members and total number of members') is fairly valid in a logical design of ALSA control protocol/interface. In detail, please refer to my post[1].
Some of ALSA drivers for PCI cards produced by Echo Audio potentially have problems which I mentioned in the post. They can cause buffer-over-run over 'struct snd_ctl_elem_value.value' in user space. The drivers should be going to fix.
I wrote a small program to validate dimension information for your card[2]. Would you please execute it? Like:
$ gcc -o ./test ./alsa-ctl-dimen-check.c $ ./test /dev/snd/controlC[0-9]
An argument is required for a path of special file for ALSA control character device for your sound card.
[1] [alsa-devel] [PATCH 0/3] ALSA: add dimension information validator http://mailman.alsa-project.org/pipermail/alsa-devel/2016-June/109811.html [2] alsa-ctl-dimen-check.c https://gist.github.com/takaswie/cd670ee88b7fd25c68780610ad8ad54f
Regards
Takashi Sakamoto
I have attached the output of the alsa-ctl-dimen-check program.
-~Chris
On 08/30/2017 10:50 PM, Takashi Sakamoto wrote:
$ alsactl -f ~/asound1.state store 1 (alsa-utils:alsactl/alsactl.c) main() (alsa-utils:alsactl/state.c) ->save_state() ->get_controls() ->get_control() snd_ctl_elem_info(info) count = snd_ctl_elem_info_get_count(info) for (i = 0; i < count; i++) snd_ctl_elem_value_get_integer(ctl, i)
I guess that 'snd-echo3g.ko' returns value greater than 128 in a call graph of 'snd_ctl_elem_info_get_count()', then a call of 'snd_ctl_elem_value_get_integer()' hits an assertion in the function.
A patch mentioned by Mark Hills (a commit 275353bb684e 'ALSA: echoaudio: purge contradictions between dimension matrix members and total number of members') is fairly valid in a logical design of ALSA control protocol/interface. In detail, please refer to my post[1].
Some of ALSA drivers for PCI cards produced by Echo Audio potentially have problems which I mentioned in the post. They can cause buffer-over-run over 'struct snd_ctl_elem_value.value' in user space. The drivers should be going to fix.
I wrote a small program to validate dimension information for your card[2]. Would you please execute it? Like:
$ gcc -o ./test ./alsa-ctl-dimen-check.c $ ./test /dev/snd/controlC[0-9]
An argument is required for a path of special file for ALSA control character device for your sound card.
[1] [alsa-devel] [PATCH 0/3] ALSA: add dimension information validator http://mailman.alsa-project.org/pipermail/alsa-devel/2016-June/109811.html [2] alsa-ctl-dimen-check.c https://gist.github.com/takaswie/cd670ee88b7fd25c68780610ad8ad54f
Regards
Takashi Sakamoto
On Thu, 31 Aug 2017, Takashi Sakamoto wrote:
On Aug 29 2017 12:46, S. Christian Collins wrote:
On 08/28/2017 10:33 PM, Takashi Sakamoto wrote:
Would you get output from below command line for your Gina 3G?
$ amixer scontrols
The output of "amixer -c 1 scontrols" is attached to this e-mail as "scontrols.txt".
And typically state data is stored into '/var/lib/alsa/asound.state' as a default. For my information, could you disclose it if possible?
Yes, it is also attached to this e-mail. The asound.state file was last modified on March 26th. I remember that I used to not get the error when using "alsactl store", so perhaps an update caused this issue to appear around that time?
$ alsactl -f ~/asound1.state store 1 (alsa-utils:alsactl/alsactl.c) main() (alsa-utils:alsactl/state.c) ->save_state() ->get_controls() ->get_control() snd_ctl_elem_info(info) count = snd_ctl_elem_info_get_count(info) for (i = 0; i < count; i++) snd_ctl_elem_value_get_integer(ctl, i)
I guess that 'snd-echo3g.ko' returns value greater than 128 in a call graph of 'snd_ctl_elem_info_get_count()', then a call of 'snd_ctl_elem_value_get_integer()' hits an assertion in the function.
This sounds familiar -- would you like to compare to my post earlier in the year (for Layla):
http://mailman.alsa-project.org/pipermail/alsa-devel/2017-March/119125.html
In this post I made a misdiagnosis that it was related to my move to a 64-bit userland. When I found I could revert a patch it looks like it was coincidence.
A patch mentioned by Mark Hills (a commit 275353bb684e 'ALSA: echoaudio: purge contradictions between dimension matrix members and total number of members') is fairly valid in a logical design of ALSA control protocol/interface. In detail, please refer to my post[1].
Some of ALSA drivers for PCI cards produced by Echo Audio potentially have problems which I mentioned in the post. They can cause buffer-over-run over 'struct snd_ctl_elem_value.value' in user space. The drivers should be going to fix.
I wrote a small program to validate dimension information for your card[2]. Would you please execute it? Like:
$ gcc -o ./test ./alsa-ctl-dimen-check.c $ ./test /dev/snd/controlC[0-9]
In case it's useful, I've also attached the output for my Layla 3G.
This is with the patch reverted as that's the kernel currently in use. If it would be helpful for me to build another kernel, I can do that.
Takashi, is there anything else you would like me to do to help with this issue? Should it perhaps be filed on the bug tracker so it doesn't get lost in this list?
-~Chris
On 09/04/2017 03:23 PM, Mark Hills wrote:
On Thu, 31 Aug 2017, Takashi Sakamoto wrote:
On Aug 29 2017 12:46, S. Christian Collins wrote:
On 08/28/2017 10:33 PM, Takashi Sakamoto wrote:
Would you get output from below command line for your Gina 3G?
$ amixer scontrols
The output of "amixer -c 1 scontrols" is attached to this e-mail as "scontrols.txt".
And typically state data is stored into '/var/lib/alsa/asound.state' as a default. For my information, could you disclose it if possible?
Yes, it is also attached to this e-mail. The asound.state file was last modified on March 26th. I remember that I used to not get the error when using "alsactl store", so perhaps an update caused this issue to appear around that time?
$ alsactl -f ~/asound1.state store 1 (alsa-utils:alsactl/alsactl.c) main() (alsa-utils:alsactl/state.c) ->save_state() ->get_controls() ->get_control() snd_ctl_elem_info(info) count = snd_ctl_elem_info_get_count(info) for (i = 0; i < count; i++) snd_ctl_elem_value_get_integer(ctl, i)
I guess that 'snd-echo3g.ko' returns value greater than 128 in a call graph of 'snd_ctl_elem_info_get_count()', then a call of 'snd_ctl_elem_value_get_integer()' hits an assertion in the function.
This sounds familiar -- would you like to compare to my post earlier in the year (for Layla):
http://mailman.alsa-project.org/pipermail/alsa-devel/2017-March/119125.html
In this post I made a misdiagnosis that it was related to my move to a 64-bit userland. When I found I could revert a patch it looks like it was coincidence.
A patch mentioned by Mark Hills (a commit 275353bb684e 'ALSA: echoaudio: purge contradictions between dimension matrix members and total number of members') is fairly valid in a logical design of ALSA control protocol/interface. In detail, please refer to my post[1].
Some of ALSA drivers for PCI cards produced by Echo Audio potentially have problems which I mentioned in the post. They can cause buffer-over-run over 'struct snd_ctl_elem_value.value' in user space. The drivers should be going to fix.
I wrote a small program to validate dimension information for your card[2]. Would you please execute it? Like:
$ gcc -o ./test ./alsa-ctl-dimen-check.c $ ./test /dev/snd/controlC[0-9]
In case it's useful, I've also attached the output for my Layla 3G.
This is with the patch reverted as that's the kernel currently in use. If it would be helpful for me to build another kernel, I can do that.
Hi,
On Sep 14 2017 22:40, S. Christian Collins wrote:
Takashi, is there anything else you would like me to do to help with this issue? Should it perhaps be filed on the bug tracker so it doesn't get lost in this list?
Sorry to be late for reaction, but we're on merge window for v4.14 and I keep my time for unexpected accidents such as this[1]. I'd like to postpone this discussion after closing the window, a few days later.
[1] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-September/125474.h...
Thanks for your patience.
Takashi Sakamoto
Hi S. Christian and Mark,
On Sep 15 2017 14:21, Takashi Sakamoto wrote:
On Sep 14 2017 22:40, S. Christian Collins wrote:
Takashi, is there anything else you would like me to do to help with this issue? Should it perhaps be filed on the bug tracker so it doesn't get lost in this list?
Sorry to be late for reaction, but we're on merge window for v4.14 and I keep my time for unexpected accidents such as this[1]. I'd like to postpone this discussion after closing the window, a few days later.
[1] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-September/125474.h...
First of all, I apologize for the inconvenience. It's my fault. Yesterday a maintainer of this subsystem applies my patch[1] to revert the issued commit. It will also be applied to stable/longterm kernels. If you use one of the maintained kernels in any distribution such as Fedora, you may get solved driver enough later.
However, current echoaudio drivers have an issue in a point of ALSA control interface, as I noted to the patch. For this issue, I'm preparing for my proposal in Audio miniconference 2017[2]. If the 'echomixer' program is going to be modified according to our decision, I'll request you to test my patches, perhaps. I'm happy to get your helps for the testing in future.
Thanks for your report for this issue, and patience.
[1] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-October/126030.htm... [2] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-October/126033.htm...
Takashi Sakamoto
I will be happy to help you test, when that time comes.
Best Regards,
-~Chris
On 10/02/2017 08:53 PM, Takashi Sakamoto wrote:
Hi S. Christian and Mark,
On Sep 15 2017 14:21, Takashi Sakamoto wrote:
On Sep 14 2017 22:40, S. Christian Collins wrote:
Takashi, is there anything else you would like me to do to help with this issue? Should it perhaps be filed on the bug tracker so it doesn't get lost in this list?
Sorry to be late for reaction, but we're on merge window for v4.14 and I keep my time for unexpected accidents such as this[1]. I'd like to postpone this discussion after closing the window, a few days later.
[1] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-September/125474.h...
First of all, I apologize for the inconvenience. It's my fault. Yesterday a maintainer of this subsystem applies my patch[1] to revert the issued commit. It will also be applied to stable/longterm kernels. If you use one of the maintained kernels in any distribution such as Fedora, you may get solved driver enough later.
However, current echoaudio drivers have an issue in a point of ALSA control interface, as I noted to the patch. For this issue, I'm preparing for my proposal in Audio miniconference 2017[2]. If the 'echomixer' program is going to be modified according to our decision, I'll request you to test my patches, perhaps. I'm happy to get your helps for the testing in future.
Thanks for your report for this issue, and patience.
[1] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-October/126030.htm... [2] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-October/126033.htm...
Takashi Sakamoto
On Tue, 29 Aug 2017, Takashi Sakamoto wrote:
On Aug 29 2017 00:34, S. Christian Collins wrote:
However, when I try to save the Gina3G mixer:
alsactl -f ~/asound1.state store 1
...I get the following error:
alsactl: control.c:2513: snd_ctl_elem_value_get_integer: Assertion `idx < sizeof(obj->value.integer.value) / sizeof(obj->value.integer.value[0])' failed. Aborted
I have tried to find any info on this error online, but to no avail. Does anybody know what is going on here?
The value of 'sizeof(obj->value.integer.value) / sizeof(obj->value.integer.value[0])' has fixed value (=128), therefore the value of 'idx' is greater than 128, against expectation.
Would you get output from below command line for your Gina 3G?
$ amixer scontrols
And typically state data is stored into '/var/lib/alsa/asound.state' as a default. For my information, could you disclose it if possible?
I think you're suffering the same problem I am with my Echo Layla 3G. Does 'echomixer' work?
For some time now I have been running with commit 275353bb6 (copied below) reverted.
I did my most recent tests on kernel 4.10.3, resulting in the revert of that commit. I with the reverted commit. I recall that alsactl, alsamier were also affected.
I have been intending to make a 'proper' report to the list, or even investigate more myself. But priorities did not permit that yet. I also wasn't able to find information on what these fields actually mean. As far as I could tell, some of these attributes are unique to the echo3g and echomixer.
Thanks
On 08/29/2017 03:36 PM, Mark Hills wrote:
I think you're suffering the same problem I am with my Echo Layla 3G. Does 'echomixer' work?
Yes, 'echomixer' works fine for me. I have to launch it on occasion to properly set my audio output level (just launching it restores the correct level). I didn't have to do this in the past, so I'm guessing it's probably related to the problem with 'alsactl store' not working anymore for the card.
I have been intending to make a 'proper' report to the list, or even investigate more myself. But priorities did not permit that yet. I also wasn't able to find information on what these fields actually mean. As far as I could tell, some of these attributes are unique to the echo3g and echomixer.
Yeah, I've never seen a mixer quite like this one. Using 'alsamixer' to adjust my Echo3G is almost pointless, since it is impossible to tell what is what.
-~Chris
participants (3)
-
Mark Hills -
S. Christian Collins -
Takashi Sakamoto