5

I've just done a dist upgrade on my Debian SID computer, and the sound disappeared.

I can play an audio file in root, but not as a normal user. I've checked that I'm in the "audio" group. I've checked to see if anything is muted by running alsamixer, but all line is up and running.

Here are the Audio output I have on the computer:

$ lspci | grep Audio 00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 05) 01:00.1 Audio device: NVIDIA Corporation GK107 HDMI Audio Controller (rev a1)

I have an unplugged HDMI output (the NVIDIA controller). My audio headers are plugged on my Intel controller. I can see this driver when I run alsamixer, but only see the HDMI output from my graphics card in the pavucontrol output devices.

enter image description here

When listing my audio sinks, I only get one null device:

$ pacmd list-sinks 1 sink(s) available. * index: 2 name: <auto_null> driver: <module-null-sink.c> flags: DECIBEL_VOLUME LATENCY FLAT_VOLUME DYNAMIC_LATENCY state: IDLE suspend cause: priority: 1000 volume: front-left: 56362 / 86% / -3,93 dB, front-right: 55706 / 85% / -4,23 dB balance -0,01 base volume: 65536 / 100% / 0,00 dB volume steps: 65537 muted: no current latency: 5,63 ms max request: 6 KiB max rewind: 6 KiB monitor source: 2 sample spec: s16le 2ch 44100Hz channel map: front-left,front-right Stéréo used by: 0 linked by: 1 configured latency: 40,00 ms; range is 0,50 .. 2000,00 ms module: 20 properties: device.description = "Sortie factice" device.class = "abstract" device.icon_name = "audio-card"

I don't really understand deeply how the sound system works in Debian, but I think I understand that my normal user does not have the right to access the Intel chip. From here, I'm stuck and can't really find out what to do...

EDIT:

I managed to get back the sound by disabling auto-mute in alsamixer. This settings has been somehow change during the system update.

But after a reboot, the problem came back, but the auto-mute was still off.

Thanks to dirkt answer, I think I have found the source of this issue: When running aplay -L as normal user and root user, I noticed some differences:

$ aplay -L default Playback/recording through the PulseAudio sound server sysdefault:CARD=PCH HDA Intel PCH, ALC887-VD Analog Default Audio Device $ sudo aplay -L  default:CARD=PCH HDA Intel PCH, ALC887-VD Analog Default Audio Device sysdefault:CARD=PCH HDA Intel PCH, ALC887-VD Analog Default Audio Device

It seems that the default card is not the same when running as simple user. I could have some sound when selecting sysdefault instead of default card as normal user.

$ aplay -D sysdefault sound.wav

But now, I'm a bit stuck. I think I've pinpoint the source of the issue, but cannot find out how to solve it...

Improve this question
2
  • 1
    Restore from backup and file a bug with the distro maintainer. Commented Jun 26, 2018 at 21:34
  • 1
    I had the same symptoms after upgrading to buster and it appeared timidity was holding alsa (that's basically what I understand). Uninstalling timidity restored the sound. Commented May 10, 2019 at 15:19

5 Answers 5

Reset to default
8

I solved this issue for me by running:

sudo apt-get remove --purge timidity

Please make sure this will only remove timidity and timidity-daemon. As far as I understand the daemon grabs some resources on startup and prevents the other services from finding the sound cards. I think timidity has something to do with MIDI files so make sure you do not need this when uninstalling the packages and make sure that you know what you uninstall.

Hope this resolves the issue for some users. You might want to reinstall timidity in the future when the above mentioned issues are resolved.

Improve this answer
3

Brief overview of sound: The sound hardware is managed by kernel drivers (formerly a part of ALSA), ALSA provides libraries to access the kernel drivers (this is what you see with alsamixer), and Pulseaudio runs on top of ALSA. One reason for that is that without extra effort, ALSA devices can only be used by a single program, while Pulseaudio allows multiple programs to use the hardware by providing a transport layer.

No sink with Pulseaudio means Pulseaudio failed to grab the ALSA device(s), possibly because (1) permissions are wrong, (2) something else is already using them, (3) something totally different went wrong.

So the first step is to stop Pulseaudio, then use aplay -L to see your ALSA devices, and try aplay -D ... audio_file.wav to see if you can access the device directly. Depending on the result of that the next step is either to look what is blocking the device (something else has started earlier and is using it), or to find out why Pulseaudio isn't using the ALSA devices (e.g. load module-alsa-card directly with pacmd, look at the error message/log entries). How to stop Pulseaudio depends on how you started it, possibly with systemd, possibly via your Desktop system login.

Inspecting the command line of running processes with ps axu etc. may give hints about the points mentioned above, and will also make sure Pulseaudio has been stopped properly, and is not restarting itself.

Improve this answer
2
  • This helped me find out the source of the problem. Thanks. I've edited my question to reflect advances in this issue. Commented Jul 2, 2018 at 9:53
  • 2
    Spot on. There is indeed an issue with Timidity that gets triggered when upgrading to Buster. bugs.debian.org/cgi-bin/bugreport.cgi?bug=901148 Commented May 14, 2019 at 7:35
2

Problem solved: after the upgrade, I don't know why, the output was in automute. I just had to change it in alsamixer.

Sometimes, digging deep is not needed.

Improve this answer
2
  • 1
    Since you said you checked if anything was muted, this was hard to guess from your question... Commented Jul 2, 2018 at 9:55
  • I understand. But while checking this I missed the auto-mute option that I did not know about. Commented Jul 2, 2018 at 11:14
1

As it works with "root" user, maybe is it just a problem of group membership and your login name is not (yet) member of the group "audio".

On my debian buster "ben" user is member of group "audio" :

ben@debian:~$ cat /etc/group | grep "ben" tty:x:5:ben dialout:x:20:ben cdrom:x:24:ben floppy:x:25:ben sudo:x:27:ben audio:x:29:pulse,ben dip:x:30:ben video:x:44:ben plugdev:x:46:ben netdev:x:109:ben bluetooth:x:113:ben scanner:x:117:saned,ben ben:x:1000: docker:x:130:ben wireshark:x:131:ben ben@debian:~$

You could also use the command to make sure (check in /etc/group)

useradd -G audio <your username>

And finally, re-open a session in order for the change to be effective !

Improve this answer
1
  • This question was five and a half years old and concerns software that will hit its final EOL of even its extended long term support in a few months, and already had a perfectly good and accepted answer. We appreciate your enthusiasm and willingness to share your knowledge, but please refrain from necromancy like this unless the question is 1) about something that could still be an issue and 2) doesn't have an accepted answer yet. Commented Jan 29, 2024 at 9:51
0

Actually the problem comes from the fact you've got PulseAudio AND a NVidia GPU w/ the blob.

The solution consists in preventing PulseAudio from starting by inserting garbage in /etc/pulse/daemon.conf (just a single letter at the end of the file). Then you will only be able to set the volue through AlsaMixer but at least sound will be back.

I've raised ticket #918522 about this issue. Feel free to contribute.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.