Dummy output Pulseaudio after update

[krznv]

I did a distro upgrade from stable buster to testing.
Before, Pulseaudio worked fine with Jack.
Now, after the update, the only output device in Audio tab of Settings, is Dummy output.

I've tried the GRUB fixes in other threads about the same issue on Mint I think, they were supposed to work but did not.

Running pulseaudio --kill
Gives me a Jack sink for output (without starting qjackctl), so the sound works after that,
The problem is it wasn't like that before, it was normal pulse output and Jack only kicked in when I started qjackctl.

What output can I post to give more insight into the problem? Alsamixer is fine.

[krznv]

The first fix from here https://www.linuxuprising.com/2018/06/f ... ue-in.html

Code: Select all

echo "options snd-hda-intel model=generic" | sudo tee -a /etc/modprobe.d/alsa-base.conf

Gave the correct sound devices, but the output was high pitched noise.

[sgosnell]

Are you certain you have the correct firmware for your soundcard?

[MagicPoulp]

There is a pulse / alsa wiki for debian. It says how to reset pulse.
See the chapter "Missing playback devices or audio capture"
https://wiki.debian.org/PulseAudio

If you move to testing, lots of things need to be fixed. Like the firmare-linux from testing, the kernel from testing, etc.

You probably should reinstall stable. If you need a package from testing, build it from source it is simple to do. Or even simpler, use a debootstrap chroot for running debian testing in a local folder. Using a chroot is probably the best choice to build from source since you do not get many build deps on your system, and then you can install the built package on your real system.

For example, to get java 8, I built it in a chroot running stable. Then I copied and installed the .deb on the real system.

[krznv]

Are you certain you have the correct firmware for your soundcard?

Not sure, how do I check?

There is a pulse / alsa wiki for debian. It says how to reset pulse.
See the chapter "Missing playback devices or audio capture"
https://wiki.debian.org/PulseAudio

If you move to testing, lots of things need to be fixed. Like the firmare-linux from testing, the kernel from testing, etc.

You probably should reinstall stable. If you need a package from testing, build it from source it is simple to do. Or even simpler, use a debootstrap chroot for running debian testing in a local folder. Using a chroot is probably the best choice to build from source since you do not get many build deps on your system, and then you can install the built package on your real system.

For example, to get java 8, I built it in a chroot running stable. Then I copied and installed the .deb on the real system.

Okay so I think it's really great that I can run testing as the updated packages mean it's worth it. Stable is fine for certain situations but I prefer having the newer versions.

I removed the config files and reset the systemd service, all it gives me is another Jack sink, not how it should be.

You said many things need to be fixed after update. I have the new kernel (RT patch), I didn't notice many breaks by the update.

[MagicPoulp]

When saying things have to be fixed when using something else than stable, I was talking about a specific scenario in my experience. I took a kernel from buster-backports, but not the firmwares from backports. THey are not connected because they are in the non-free repository. And then I had strange warnings for initrams installs.

For me it is a fundamental principle that if you want to use debian, you must stick to stable as much as possible. It is very important. Installing a package directly from testing is forbidden in my new way of using debian.

Your argument to upgrade to testing to get newer package versions is not valid. because you can also get newer versions if you build the packages from source. And you can have your own lab with testing inside a chroot.

First you don't have a fresh install ationof testing. But an upgrade, which is very different. Lots of configs may look strange because the upgrade did not dare change things.

[krznv]

I agree installing testing would be better.

Either way there are many cases of this error online, it's just that none of the fixes works for me, I can't waste time reinstalling debian.

[MagicPoulp]

You probably should try to uninstall with --purge pulseaudio pulseaudio-utils
and then reinstall.

then do this to reset pulseaudio from the debian and archi wiki:

Code: Select all

sudo rm -r ~/.config/pulse /tmp/pulse-*
pulseaudio --kill
pulseaudio --start
sudo alsamixer
unmute and add stuff
sudo alsactl store


I did not convince you 100% since you want to reinstall testing and not stable. Testing is not really a distribution. its quality varies a lot depending on how far is the next debian release...
https://wiki.debian.org/DebianUnstable# ... d_users.3F

It is fixable without reinstalling. Here is some inspiration. But the time spent debugging would be better spent following good methodologies (reinstalling, stick to stable, cherry pick newer packages and not the whole testing, learn a fundamental thing that is a chroot and source building, etc)

You probably should set up apt sources to get non-free stuff. Then install firmware-linux -t testing (from testing), the meta package. Maybe there are more firmwares for your sound card and motherboard, debian has many firmwares packages in the doc. If I remember one, there some for sound card manufacturers. THen you need a good kernel, probably the one from testing. Get the linux-image-amd64 (probably the kernel package for you). Then do a reset of alsa/pulse as the debian doc I linked to says.


Then after a reboot, read carefully the dmesg kernel logs to see errors. Check for more errors in /var/log.

WHen you stop and start pulseaudio, check the logs (cehck the doc, maybe in syslog or messages).

if you sudo alsamixer, with F4 and arrow keys, there are lots of things you can activate. Often, unmuting can solve a n issue. Then there are comman lines in alsa to unmute.

THen try to identify the output device. Debug it etc.

the arch wiki has lots of tricks to try, that are often very relevant for debian.

https://wiki.debian.org/PulseAudio
https://wiki.archlinux.org/index.php/Pu ... o/Examples

[sgosnell]

You can find the soundcard you have with

Code: Select all

 lspci | grep Audio

then apt search for "firmware OEM", replaceing OEM with the name of the sound card manufacturer. You certainly should have firmware-misc-nonfree installed as well.

[krznv]

You can find the soundcard you have with

Code: Select all

 lspci | grep Audio

then apt search for "firmware OEM", replaceing OEM with the name of the sound card manufacturer. You certainly should have firmware-misc-nonfree installed as well.

The firmware-intel-sound and firmware-misc-nonfree are installed.

[MagicPoulp]

firmware-linux is a meta-package for firmware-misc-nonfree and a other.
But it does not contain all. For example the realtek one is missing. But you can find it in the list below. realtek is a common sound system manufacturer.

here is the list of firmwares for Testing from the debian doc.
1. doc
https://wiki.debian.org/Firmware
2. the list
http://cdimage.debian.org/cdimage/unoff ... g/current/

You do not need to download the zip file, you can install via apt get. The url with the zip is just to get the name, unless you are good to search via apt search.

[krznv]

You probably should try to uninstall with --purge pulseaudio pulseaudio-utils
and then reinstall.

then do this to reset pulseaudio from the debian and archi wiki:

Code: Select all

sudo rm -r ~/.config/pulse /tmp/pulse-*
pulseaudio --kill
pulseaudio --start
sudo alsamixer
unmute and add stuff
sudo alsactl store


Doing this step-by-step then restarting solved the issue and it works as it did before, now.

Sorry if I wasted your time but having a solution to this is worth it I think. Using Debian testing is the way to go for me.

[MagicPoulp]

Interesting.

Actually Testing will freeze in february. So testing is 90% next-stable
In theory people use testing and if they find bugs, they report them to debian maintainers.

What I said before was wrong. It is fine to use testing. What I myself did wrong in the past was to mix stable with packages from testing.