[alsa-devel] Issues and/or possible bugs in alsa
Hello.
I seem to have run into a few issues with alsa.
First, when I plug my headphones into my laptop, sound continues to play out of the speakers and doesn't switch over to (or unmute) the headphones. Auto-Mute Mode is enabled in alsamixer. The same thing happens when I unplug the headphones, it doesn't switch over to the speakers. I have to do the same thing I described above, (no unmuting, I just have to turn up the volume for the speakers in alsamixer.)
Second. When I plug in these headphones, I can't use the internal microphone on this laptop, it mutes. (AFAICT) These headphones do not have a microphone built in, they're just an ordinary pair of headphones. However, I was given a workaround in #alsa on freenode. In order to use the laptop's internal microphone with my headphones plugged in, I have to do : sudo hda-verb /dev/snd/hwC1D0 0x22 SET_CONNECT_SEL 6 — it works, but it isn't really ideal.
alsa-info is here : https://gist.github.com/Yomi0/9bfc3e72588cf8a35811
The first file in that gist is alsa-info with headphones and the second is without headphones.
Third. This is just a question. Is this : https://bugs.freedesktop.org/show_bug.cgi?id=86676 actually a pulseaudio bug, or is it an issue with alsa? I'm only asking since Raymond linked something that seemed to belong to the alsa project.
Thank you.
At Tue, 24 Feb 2015 17:46:09 -0500, Yomi Ogunwumi wrote:
Hello.
I seem to have run into a few issues with alsa.
First, when I plug my headphones into my laptop, sound continues to play out of the speakers and doesn't switch over to (or unmute) the headphones. Auto-Mute Mode is enabled in alsamixer. The same thing happens when I unplug the headphones, it doesn't switch over to the speakers. I have to do the same thing I described above, (no unmuting, I just have to turn up the volume for the speakers in alsamixer.)
Second. When I plug in these headphones, I can't use the internal microphone on this laptop, it mutes. (AFAICT) These headphones do not have a microphone built in, they're just an ordinary pair of headphones. However, I was given a workaround in #alsa on freenode. In order to use the laptop's internal microphone with my headphones plugged in, I have to do : sudo hda-verb /dev/snd/hwC1D0 0x22 SET_CONNECT_SEL 6 — it works, but it isn't really ideal.
alsa-info is here : https://gist.github.com/Yomi0/9bfc3e72588cf8a35811
The first file in that gist is alsa-info with headphones and the second is without headphones.
Third. This is just a question. Is this : https://bugs.freedesktop.org/show_bug.cgi?id=86676 actually a pulseaudio bug, or is it an issue with alsa? I'm only asking since Raymond linked something that seemed to belong to the alsa project.
The alsa-info.sh output above shows the reads from the codec failed. Could you try once to disable power-saving? Set power_save=0 option to snd-hda-intel module.
Note that power_save option might be changed dynamically by the system (accessible via /sys/module/snd_hda_intel/parameters/power_save). If the problem is still seen, check the value there whether you still really have 0 or it was changed by the system.
Restricting the power-save isn't a solution but helps understanding the cause, at least.
Takashi
Sorry, I think this : *https://gist.github.com/Yomi0/9bfc3e72588cf8a35811#file-alsa-info-without-he... https://gist.github.com/Yomi0/9bfc3e72588cf8a35811#file-alsa-info-without-headphones *is what you wanted. Headphones are plugged in.
On Wed, Feb 25, 2015 at 2:58 AM, Takashi Iwai tiwai@suse.de wrote:
At Tue, 24 Feb 2015 17:46:09 -0500, Yomi Ogunwumi wrote:
Hello.
I seem to have run into a few issues with alsa.
First, when I plug my headphones into my laptop, sound continues to play out of the speakers and doesn't switch over to (or unmute) the
headphones.
Auto-Mute Mode is enabled in alsamixer. The same thing happens when I unplug the headphones, it doesn't switch over to the speakers. I have to
do
the same thing I described above, (no unmuting, I just have to turn up
the
volume for the speakers in alsamixer.)
Second. When I plug in these headphones, I can't use the internal microphone on this laptop, it mutes. (AFAICT) These headphones do not have a microphone built in, they're just an ordinary pair of headphones. However, I was given a workaround in #alsa
on
freenode. In order to use the laptop's internal microphone with my headphones plugged in, I have to do : sudo hda-verb /dev/snd/hwC1D0 0x22 SET_CONNECT_SEL 6 — it works, but it isn't really ideal.
alsa-info is here : https://gist.github.com/Yomi0/9bfc3e72588cf8a35811
The first file in that gist is alsa-info with headphones and the second
is
without headphones.
Third. This is just a question. Is this : https://bugs.freedesktop.org/show_bug.cgi?id=86676 actually a pulseaudio bug, or is it an issue with alsa? I'm only asking since Raymond linked something that seemed to belong to
the
alsa project.
The alsa-info.sh output above shows the reads from the codec failed. Could you try once to disable power-saving? Set power_save=0 option to snd-hda-intel module.
Note that power_save option might be changed dynamically by the system (accessible via /sys/module/snd_hda_intel/parameters/power_save). If the problem is still seen, check the value there whether you still really have 0 or it was changed by the system.
Restricting the power-save isn't a solution but helps understanding the cause, at least.
Takashi
This is what happens when I don't double check links and reread mail before hit send. That link in the last message does not contain the information you are looking for.
This does : https://gist.github.com/Yomi0/9bfc3e72588cf8a35811#file-alsainfo-headphones-...
• Yomi
25.02.2015 03:46, Yomi Ogunwumi wrote:
Third. This is just a question. Is this : https://bugs.freedesktop.org/show_bug.cgi?id=86676 actually a pulseaudio bug, or is it an issue with alsa? I'm only asking since Raymond linked something that seemed to belong to the alsa project.
This is a bug both in ALSA and in PulseAudio.
The ALSA part (from the user viewpoint) is that the softvol plugin does not reprocess the already-submitted but buffered samples when the volume changes. But it can't, because that would require an additional thread for monitoring the software volume changes, and such thread does not exist.
The PulseAudio part of the bug is that it does not deactivate softvols, even though it can apply volume in software itself. In October 2014, in Dusseldorf, a general agreement has been reached on the following arguments:
* ALSA has no API to definitely distinguish softvols from other controls. * ALSA has the snd_ctl_elem_info_is_user() API function that tells whether this is a userspace control. * All softvols are userspace controls. * There are other kinds of userspace controls, but they are rare. * If a control is named PCM Playback Volume and is a userspace control, then it's likely a softvol. Not bulletproof, but a good-enough heuristic. * On finding a softvol, PulseAudio should set it to 100% (so that it doesn't eat CPU) and don't touch from that point on.
But nobody has implemented this so far.
The relevant code can be placed in the src/modules/alsa/alsa-mixer.c file in PulseAudio source tree. I guess that element_probe() is a good place. If you know C programming, a contribution would be welcome.||
Dne 25.2.2015 v 09:14 Alexander E. Patrakov napsal(a):
25.02.2015 03:46, Yomi Ogunwumi wrote:
Third. This is just a question. Is this : https://bugs.freedesktop.org/show_bug.cgi?id=86676 actually a pulseaudio bug, or is it an issue with alsa? I'm only asking since Raymond linked something that seemed to belong to the alsa project.
This is a bug both in ALSA and in PulseAudio.
The ALSA part (from the user viewpoint) is that the softvol plugin does not reprocess the already-submitted but buffered samples when the volume changes. But it can't, because that would require an additional thread for monitoring the software volume changes, and such thread does not exist.
The PulseAudio part of the bug is that it does not deactivate softvols, even though it can apply volume in software itself. In October 2014, in Dusseldorf, a general agreement has been reached on the following arguments:
- ALSA has no API to definitely distinguish softvols from other controls.
- ALSA has the snd_ctl_elem_info_is_user() API function that tells
whether this is a userspace control.
- All softvols are userspace controls.
- There are other kinds of userspace controls, but they are rare.
- If a control is named PCM Playback Volume and is a userspace
control, then it's likely a softvol. Not bulletproof, but a good-enough heuristic.
- On finding a softvol, PulseAudio should set it to 100% (so that it
doesn't eat CPU) and don't touch from that point on.
But nobody has implemented this so far.
PulseAudio should open PCM with the SND_PCM_NO_SOFTVOL mode. In this case, the PCM device does not add the softvol plugin to the internal plugin chain. These mode flags was introduced a long time ago (discussed with Lennart) and I thought that PA uses it.
Jaroslav
25.02.2015 13:30, Jaroslav Kysela wrote:
Dne 25.2.2015 v 09:14 Alexander E. Patrakov napsal(a):
25.02.2015 03:46, Yomi Ogunwumi wrote:
Third. This is just a question. Is this : https://bugs.freedesktop.org/show_bug.cgi?id=86676 actually a pulseaudio bug, or is it an issue with alsa? I'm only asking since Raymond linked something that seemed to belong to the alsa project.
This is a bug both in ALSA and in PulseAudio.
The ALSA part (from the user viewpoint) is that the softvol plugin does not reprocess the already-submitted but buffered samples when the volume changes. But it can't, because that would require an additional thread for monitoring the software volume changes, and such thread does not exist.
The PulseAudio part of the bug is that it does not deactivate softvols, even though it can apply volume in software itself. In October 2014, in Dusseldorf, a general agreement has been reached on the following arguments:
- ALSA has no API to definitely distinguish softvols from other controls.
- ALSA has the snd_ctl_elem_info_is_user() API function that tells
whether this is a userspace control.
- All softvols are userspace controls.
- There are other kinds of userspace controls, but they are rare.
- If a control is named PCM Playback Volume and is a userspace
control, then it's likely a softvol. Not bulletproof, but a good-enough heuristic.
- On finding a softvol, PulseAudio should set it to 100% (so that it
doesn't eat CPU) and don't touch from that point on.
But nobody has implemented this so far.
PulseAudio should open PCM with the SND_PCM_NO_SOFTVOL mode. In this case, the PCM device does not add the softvol plugin to the internal plugin chain. These mode flags was introduced a long time ago (discussed with Lennart) and I thought that PA uses it.
Jaroslav
Well, that can be done, but the "don't attempt to control the softvol" part of the bug needs to be solved first. SND_PCM_NO_SOFTVOL by itself is not sufficient.
Iwai, I checked the value of /sys/module/snd_hda_intel/parameters/power_save with less, it is set to 0 already.
On Wed, Feb 25, 2015 at 3:36 AM, Alexander E. Patrakov patrakov@gmail.com wrote:
25.02.2015 13:30, Jaroslav Kysela wrote:
Dne 25.2.2015 v 09:14 Alexander E. Patrakov napsal(a):
25.02.2015 03:46, Yomi Ogunwumi wrote:
Third. This is just a question. Is this : https://bugs.freedesktop.org/show_bug.cgi?id=86676 actually a pulseaudio bug, or is it an issue with alsa? I'm only asking since Raymond linked something that seemed to belong to the alsa project.
This is a bug both in ALSA and in PulseAudio.
The ALSA part (from the user viewpoint) is that the softvol plugin does not reprocess the already-submitted but buffered samples when the volume changes. But it can't, because that would require an additional thread for monitoring the software volume changes, and such thread does not exist.
The PulseAudio part of the bug is that it does not deactivate softvols, even though it can apply volume in software itself. In October 2014, in Dusseldorf, a general agreement has been reached on the following arguments:
- ALSA has no API to definitely distinguish softvols from other
controls.
- ALSA has the snd_ctl_elem_info_is_user() API function that tells
whether this is a userspace control.
- All softvols are userspace controls.
- There are other kinds of userspace controls, but they are rare.
- If a control is named PCM Playback Volume and is a userspace
control, then it's likely a softvol. Not bulletproof, but a good-enough heuristic.
- On finding a softvol, PulseAudio should set it to 100% (so that it
doesn't eat CPU) and don't touch from that point on.
But nobody has implemented this so far.
PulseAudio should open PCM with the SND_PCM_NO_SOFTVOL mode. In this case, the PCM device does not add the softvol plugin to the internal plugin chain. These mode flags was introduced a long time ago (discussed with Lennart) and I thought that PA uses it.
JaroslavWell, good to know, at least.
Well, that can be done, but the "don't attempt to control the softvol" part of the bug needs to be solved first. SND_PCM_NO_SOFTVOL by itself is not sufficient.
-- Alexander E. Patrakov
Third. This is just a question. Is this : https://bugs.freedesktop.org/show_bug.cgi?id=86676 actually a pulseaudio bug, or is it an issue with alsa? I'm only asking since Raymond linked something that seemed to belong to
the
alsa project.
This is a bug both in ALSA and in PulseAudio.
The ALSA part (from the user viewpoint) is that the softvol plugin does
not reprocess the already-submitted but buffered samples when the volume changes. But it can't, because that would require an additional thread for monitoring the software volume changes, and such thread does not exist.
The PulseAudio part of the bug is that it does not deactivate softvols,
even though it can apply volume in software itself. In October 2014, in Dusseldorf, a general agreement has been reached on the following arguments:
- ALSA has no API to definitely distinguish softvols from other controls.
- ALSA has the snd_ctl_elem_info_is_user() API function that tells
whether this is a userspace control.
- All softvols are userspace controls.
- There are other kinds of userspace controls, but they are rare.
- If a control is named PCM Playback Volume and is a userspace control,
then it's likely a softvol. Not bulletproof, but a good-enough heuristic.
You can use snd_ctl_elem_info_is_use() to find out the name of those user space controls of the card and ignore those softvol "PCM playback volume" and "Digital Capture Volume" controls
- On finding a softvol, PulseAudio should set it to 100% (so that it
doesn't eat CPU) and don't touch from that point on.
But nobody has implemented this so far.
The relevant code can be placed in the src/modules/alsa/alsa-mixer.c file
in PulseAudio source tree. I guess that element_probe() is a good place. If you know C programming, a contribution would be welcome.||
state.Generic { control.1 { iface CARD name 'HDMI/DP,pcm=3 Jack' value false comment { access read type BOOLEAN count 1 } } control.2 { iface MIXER name 'IEC958 Playback Con Mask' value '0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' comment { access read type IEC958 count 1 } } control.3 { iface MIXER name 'IEC958 Playback Pro Mask' value '0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' comment { access read type IEC958 count 1 } } control.4 { iface MIXER name 'IEC958 Playback Default' value '0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' comment { access 'read write' type IEC958 count 1 } } control.5 { iface MIXER name 'IEC958 Playback Switch' value true comment { access 'read write' type BOOLEAN count 1 } } control.6 { iface PCM device 3 name ELD value '' comment { access 'read volatile' type BYTES count 0 } } control.7 { iface PCM device 3 name 'Playback Channel Map' value.0 0 value.1 0 value.2 0 value.3 0 value.4 0 value.5 0 value.6 0 value.7 0 comment { access 'read write' type INTEGER count 8 range '0 - 36' } } control.8 { iface MIXER name 'PCM Playback Volume' value.0 184 value.1 184 comment { access 'read write user' type INTEGER count 2 range '0 - 255' tlv '0000000100000008ffffec1400000014' dbmin -5100 dbmax 0 dbvalue.0 -1420 dbvalue.1 -1420 } } }
It is strange that your hdmi card have a softvol control ,
Was the softvol control created when you swap the card number by index=1,0 ?
28.02.2015 15:00, Raymond Yau wrote:
It is strange that your hdmi card have a softvol control ,
Was the softvol control created when you swap the card number by index=1,0 ?
The control was created when I used a custom asoundrc in order to test dmix on top of hdmi. Since then, I removed the customization, but there is no easy way to remove the control, as it is always saved on shutdown and restored on boot even if there is nothing in the current .asoundrc that uses it. I will remove it from the state file using a livecd, just to avoid such questions in the future.
At Sat, 28 Feb 2015 18:22:19 +0500, Alexander E. Patrakov wrote:
28.02.2015 15:00, Raymond Yau wrote:
It is strange that your hdmi card have a softvol control ,
Was the softvol control created when you swap the card number by index=1,0 ?
The control was created when I used a custom asoundrc in order to test dmix on top of hdmi. Since then, I removed the customization, but there is no easy way to remove the control, as it is always saved on shutdown and restored on boot even if there is nothing in the current .asoundrc that uses it. I will remove it from the state file using a livecd, just to avoid such questions in the future.
Right, there is no command so far for removing a user ctl element. It's relatively trivial to implement, though, e.g. in amixer or alsactl, I guess. Any taker?
Takashi
Is there anything else I need to do?
On Sat, Feb 28, 2015 at 10:13 AM, Takashi Iwai tiwai@suse.de wrote:
At Sat, 28 Feb 2015 18:22:19 +0500, Alexander E. Patrakov wrote:
28.02.2015 15:00, Raymond Yau wrote:
It is strange that your hdmi card have a softvol control ,
Was the softvol control created when you swap the card number by index=1,0 ?
The control was created when I used a custom asoundrc in order to test dmix on top of hdmi. Since then, I removed the customization, but there is no easy way to remove the control, as it is always saved on shutdown and restored on boot even if there is nothing in the current .asoundrc that uses it. I will remove it from the state file using a livecd, just to avoid such questions in the future.
Right, there is no command so far for removing a user ctl element. It's relatively trivial to implement, though, e.g. in amixer or alsactl, I guess. Any taker?
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Is there anything else I need to do?
Codec: Realtek ALC269VB Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10ec0269 Subsystem Id: 0x1179fa22 Revision Id: 0x100100 No Modem Function Group found Default PCM: N/A Default Amp-In caps: N/A Default Amp-Out caps: N/A State of AFG node 0x01: Power: setting=UNKNOWN, actual=UNKNOWN, Error, Clock-stop-OK, Setting-reset Invalid AFG subtree
Your problem seem related to power
participants (5)
-
Alexander E. Patrakov -
Jaroslav Kysela -
Raymond Yau -
Takashi Iwai -
Yomi Ogunwumi