I have a Dell XPS 13 (2015) with Broadwell hardware. I am on Arch Linux x86_64, latest version of Pulseaudio and pavucontrol. When I power on my laptop, microphone is not working. In order to enable it I have to use that instructions (https://wiki.archlinux.org/index.php/Dell_XPS_13_(9343)#Enabling_the_microphone). Issue n.1: Why my microphone is not working "automatically" ? As you note, there are two ways in order to achieve the goal; the second one is using `pavucontrol`, simply switching the two entries in the menu (full instructions here again: https://wiki.archlinux.org/index.php/Dell_XPS_13_(9343)#Enabling_the_microphone) Issue n.2: Why I have to switch twice in order to get the working microphone ? If you need further information I am here
Issue n.3: Why are settings not saved automatically across reboot ?
(In reply to mattia.b89 from comment #0) > I have a Dell XPS 13 (2015) with Broadwell hardware. > I am on Arch Linux x86_64, latest version of Pulseaudio and pavucontrol. > > When I power on my laptop, microphone is not working. > In order to enable it I have to use that instructions > (https://wiki.archlinux.org/index.php/ > Dell_XPS_13_(9343)#Enabling_the_microphone). > > Issue n.1: Why my microphone is not working "automatically" ? The wiki page says that the issue is fixed in kernel version 4.5.3. It sounds like the problem is simply a bad default value in the kernel driver. I think the reason why switching the port in pavucontrol fixes this is that pulseaudio reads the current Mic state when it first starts up, but when you change the port, the old Mic state is ignored. > As you note, there are two ways in order to achieve the goal; the second one > is using `pavucontrol`, simply switching the two entries in the menu (full > instructions here again: > https://wiki.archlinux.org/index.php/ > Dell_XPS_13_(9343)#Enabling_the_microphone) > > Issue n.2: Why I have to switch twice in order to get the working microphone > ? I'm not sure what you mean by "twice". The instructions tell you to switch first to an external mic port, and since you don't have an external mic connected, the first switch can't possibly make the mic work. The second switch is needed to enable the internal mic again. (In reply to mattia.b89 from comment #1) > Issue n.3: Why are settings not saved automatically across reboot ? I don't know. Either the volume restoring isn't working in pulseaudio, or something alters the alsa mixer state during reboot while pulseaudio is running (if alsa mixer volume changes when pulseaudio is running and pulseaudio didn't initiate the change, pulseaudio will assume that the user changed the volume and pulseaudio should remember the new volume). To check whether pulseaudio's volume restoring works, you can stop pulseaudio, change the alsa mixer volume and restart pulseaudio without rebooting. Pulseaudio should return the volume to what it was at the time pulseaudio was shut down. To stop pulseaudio: systemctl --user disable pulseaudio.socket systemctl --user stop pulseaudio.socket pulseaudio.service To restart pulseaudio: systemctl --user enable pulseaudio.socket systemctl --user start pulseaudio.socket pulseaudio.service If the volume restoring seems to be working fine when not rebooting, then I may not be able to help much. You could try disabling the alsa-state and alsa-restore services if you have them. I don't think they're needed when using pulseaudio. sudo systemctl disable alsa-state alsa-restore
I agree with you, kernel doesn't enable it on boot. This is the first point to underline, and likely switching this behaviour will solve the issue... Second thing I need to specify is that I haven't the `alsa-utils` package installed in my system, thus I don't have any alsa service
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/332.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.