I’m pretty new and inexperienced with openSUSE, so any advice is appreciated.

If you need more info, please include where I can get that info if possible, since I’m not good at terminal commands etc.

________________

Possibly related issue: Since first installing openSUSE a few months ago, I’ve had rare issues with audio suddenly no longer working on my headphones. The device would stay connected, just no audio.

That bug was very rare (haven’t had it happen in weeks). It also only appeared in-between audio sources. (I.e. listen to one YouTube video, pause or close it, try to play another, that second one no longer has audio.)

As mentioned, it happened rarely enough that I just disconnected/reconnected the device if it happened and went on with my day.

Could you check whether it's a kernel regression, e.g. booting the older kernels that was supposed to work and verify that it's still working?

Might it be the same bug as bsc#1213972?

The culprit commit was identified in the upstream discussion, and I'm building a test kernel with the reverted patch in OBS home:tiwai:bsc1214208.
Please check this test kernel once after the build finishes (takes an hour or so) and report back.

(In reply to Takashi Iwai from comment #2)
> Could you check whether it's a kernel regression, e.g. booting the older
> kernels that was supposed to work and verify that it's still working?

I’ve booted into the pre-zypper snapshot from Aug 5th. It seems to work as expected. Is that what you meant by kernel regression?

(This includes the months-old bug where stopping and restarting audio (Pausing videos/switching videos) a couple of times leads to no longer having audio sometimes, but that isn’t really what this thread is about, I think.)


>Might it be the same bug as bsc#1213972?

While I’ve no idea whether they are related, this Bluetooth audio bug appeared on a later kernel version. I’m pretty sure the snapshot I’m using atm said I’m already on kernel 6.4, and the bug is not present.


>OBS home:tiwai:bsc1214208
>Please check this test kernel once after the build finishes (takes an hour or so) and report back.

How do I do that?

(In reply to slumberbottom from comment #4)
> (In reply to Takashi Iwai from comment #2)
> > Could you check whether it's a kernel regression, e.g. booting the older
> > kernels that was supposed to work and verify that it's still working?
> 
> I’ve booted into the pre-zypper snapshot from Aug 5th. It seems to work as
> expected. Is that what you meant by kernel regression?

Not really.  At best, boot the latest system with the old kernel without rollback, just by selecting at GRUB menu.  Usually the rollback brings also other changes back, not only the kernel, too.

> (This includes the months-old bug where stopping and restarting audio
> (Pausing videos/switching videos) a couple of times leads to no longer
> having audio sometimes, but that isn’t really what this thread is about, I
> think.)
> 
> 
> >Might it be the same bug as bsc#1213972?
> 
> While I’ve no idea whether they are related, this Bluetooth audio bug
> appeared on a later kernel version. I’m pretty sure the snapshot I’m using
> atm said I’m already on kernel 6.4, and the bug is not present.
> 
> 
> >OBS home:tiwai:bsc1214208
> >Please check this test kernel once after the build finishes (takes an hour or so) and report back.
> 
> How do I do that?

Get kernel-default.rpm from
  http://download.opensuse.org/repositories/home:/tiwai:/bsc1214208/standard/
install it via zypper install and boot / test with it.

Note that it's an unofficial build, and you'd need to turn off Secure Boot if it's enabled.

(In reply to Takashi Iwai from comment #5)

> Not really.  At best, boot the latest system with the old kernel without
> rollback, just by selecting at GRUB menu.  Usually the rollback brings also
> other changes back, not only the kernel, too.

I searched for the option to choose old kernels during boot, and while I might have found a menu that switches between my current kernel and my most recent kernel, I didn’t find any way to choose an older one.

Trying to find documentation on this online, I’m sorry to say everything I found was too technical (and often long-winded and seemingly only tangentially related) for me to trust myself with messing around with any of it.

Do you know simple and safe instructions for how to add an old kernel and boot that? I’m not very tech-savvy for a long-term Linux user. 

(As a related aside, I switched to openSUSE because it was recommended after I specifically asked for a distro that just works, and where I wouldn’t have to worry about updates breaking anything. This does somewhat affect my attitude towards this situation, since I’m quite close to just reinstalling with another distribution instead.)

> > >OBS home:tiwai:bsc1214208
> > >Please check this test kernel once after the build finishes (takes an hour or so) and report back.
> > 
> > How do I do that?
> 
> Get kernel-default.rpm from
>   http://download.opensuse.org/repositories/home:/tiwai:/bsc1214208/standard/
> install it via zypper install and boot / test with it.
> 
> Note that it's an unofficial build, and you'd need to turn off Secure Boot
> if it's enabled.

I’ve downloaded "kernel-default-6.4.9-1.1.g4e1041f.x86_64.rpm" for now, if that is the one you mean? What do I do with it?

Or did you mean any of the other files that included "kerne-default" in the name?
	
kernel-default-devel-6.4.9-1.1.g4e1041f.x86_64.rpm
	
kernel-default-livepatch-devel-6.4.9-1.1.g4e1041f.x86_64.rpm
	
kernel-default-vdso-6.4.9-1.1.g4e1041f.x86_64.rpm

kernel-default-6.4.9-1.1.g4e1041f.nosrc.rpm

To clarify, my searches keep sending me to 

https://documentation.suse.com/sles/12-SP5/html/SLES-all/cha-tuning-multikernel.html and https://documentation.suse.com/sles/15-SP4/html/SLES-all/cha-mod.html

Which aren’t for Tumbleweed, doesn’t quite tell me how to add a downloaded kernel as a boot option (which is what I want, I think?), seems like it might seriously break something if I mess up anywhere, and comes with several warnings.

Same for most other guides I find. A bunch of results on building your own kernel, some for adding TW Kernels to Leap, but I haven’t found any clear instructions on downloading a kernel and then booting with it.

Based on the replies here: https://forums.opensuse.org/t/how-to-run-custom-kernel/125725/23

Would the correct command be:

rpm -i http://download.opensuse.org/repositories/home:/tiwai:/bsc1214208/standard/x86_64/kernel-default-6.4.9-1.1.g4e1041f.x86_64.rpm

Then reboot? How do I get back to the normal kernel afterwards? Is this likely to break anything? Should I update my backup immediately beforehand? Where does "zypper install" come into play here?

The openSUSE supports multi-versioned installation of kernel packages, i.e. you can install multiple kernel packages on the same system as default.

First of all, adjust /etc/zypp/zypp.conf to allow more packages to be installed in parallel.  Edit /etc/zypp/zypp.conf and modify the line defining multiversion.kernels, e.g.

  multiversion.kernels = latest,latest-1,latest-2,latest-3,running

For installing a kernel package, you can use just "zypper install"; sometimes you need to pass "--oldpackage" option in addition:

  % zypper install --oldpackage kernel-defualt-xxx.rpm

It'll build an initrd automatically.  Then reboot.

Now at the first GRUB menu, choose "Advanced options for openSUSE..." via cursor-down and RETURN keys.  At the next screen, all installed kernels are shown (twice for each version), and choose the one without "(recovery mode)" by cursor key, and RETURN key to boot with it.

Once after testing the kernel, you can uninstall it, too.
Run "rpm -q kernel-default" and delete the unwanted one via "zypper remove", e.g.

  % rpm -q kernel-default
  kernel-default-6.4.2-xxxx
  kernel-default-6.4.4-xxxx
  kernel-default-6.4.8-xxxx

  % zypper remove kernel-default-6.4.4-xxxx

(In reply to slumberbottom from comment #6)

> I’ve downloaded "kernel-default-6.4.9-1.1.g4e1041f.x86_64.rpm" for now, if
> that is the one you mean? What do I do with it?

Install only kernel-default-6.4.*.rpm.
 
> Or did you mean any of the other files that included "kerne-default" in the
> name?
> 	
> kernel-default-devel-6.4.9-1.1.g4e1041f.x86_64.rpm
> 	
> kernel-default-livepatch-devel-6.4.9-1.1.g4e1041f.x86_64.rpm
> 	
> kernel-default-vdso-6.4.9-1.1.g4e1041f.x86_64.rpm

All others aren't needed.

(In reply to Takashi Iwai from comment #10)
> (In reply to slumberbottom from comment #6)
> 
> > I’ve downloaded "kernel-default-6.4.9-1.1.g4e1041f.x86_64.rpm" for now, if
> > that is the one you mean? What do I do with it?
> 
> Install only kernel-default-6.4.*.rpm.
> 

I’m currently writing from that kernel. The bug is still present. 
Any further ideas? Any diagnostics I can do for narrowing down the error?


Sorry for the late reply. This is both the busiest time of the year so far for me, and I constantly need this laptop for stuff, so I usually don’t want to mess with it even if I’m backing everything up regularly.

As asked in comment 2, we need to know whether it's a kernel regression.
Try the older kernels found in my OBS projects e.g. home:tiwai:kernel:6.2, home:tiwai:kernel:6.1, ...
  http://download.opensuse.org/repositories/home:/tiwai:/kernel:/6.2/standard/

(In reply to Takashi Iwai from comment #12)
> As asked in comment 2, we need to know whether it's a kernel regression.
> Try the older kernels found in my OBS projects e.g. home:tiwai:kernel:6.2,
> home:tiwai:kernel:6.1, ...
>  
> http://download.opensuse.org/repositories/home:/tiwai:/kernel:/6.2/standard/

Right, forgot that part.

Using kernel-default-6.2.12-1.1.geb3255d.x86_64.rpm, the bug is _not_ present. Bluetooth headphones work as expected.

Further, they connect automatically again, which stopped happening at some point with my updated kernel. On the new kernel, they still make the connecting-to-computer sound, but they are not actually connected until I click on them in the Bluetooth widget.

OK, that's good to know.  How about 6.3.x kernel?

(In reply to Takashi Iwai from comment #14)
> OK, that's good to know.  How about 6.3.x kernel?


Currently booted into kernel-default-6.3.9-1.1.g0df701d.x86_64.rpm. Same experience as from 6.2. Headphones connected automatically and work fine.

(In reply to Takashi Iwai from comment #14)
> OK, that's good to know.  How about 6.3.x kernel?

Update: After using it for a while, one bug occured:

I tried to adjust the volume using the volume buttons on the keyboard. This suddenly no longer worked. Even going into the volume widget didn’t work. Instead, the volume stays the same and the slider immediately snaps back to 26% when I let it go. 

Using the keyboard, the same seems to be the case. Volume down displays 21% on the screen, volume up displays 31%. The volume stays the same.

After disconnecting the headset and turning Bluetooth off and on again, I now have three visually identical "Headset (Pixel Buds A-Series)" entries in the widget. The first is selected and stuck at 26%. The third one actually determines the volume despite not being marked as the current output device.

Trying to select the third entry as the actual output, both it and the first entry are selected together. No other behaviour changes.

----

This bug only appeared after more than an hour of listening to various audio.


This bug is very similar to bug 2) in my initial post. However, in bug 2), I could switch the output devices manually in the widget and the volume buttons worked again for a while afterwards, as I recall. I could be mistaken, though, and the rest is very much the same.

Another update:

I just noticed that I not only have 4 entries in the widget for the Air Buds, as mentioned before, but also 4 entries for HDMI/Display Port, which is referring to the monitor I have.

This is curious because that monitor is connected through a DP cable to a hub which is connected to my laptop through USB-C. Therefore, this might be unrelated to Bluetooth.

My headphones connected through the audio jack work fine.

Those same headphones through the audio jack of my hub don’t work.

(In reply to Takashi Iwai from comment #12)
> As asked in comment 2, we need to know whether it's a kernel regression.
> Try the older kernels found in my OBS projects e.g. home:tiwai:kernel:6.2,
> home:tiwai:kernel:6.1, ...
>  
> http://download.opensuse.org/repositories/home:/tiwai:/kernel:/6.2/standard/

I’m trying kernel 6.2 again. The same bugs are present as in 6.3. I assume that I did not notice this when I tested it for ~2 hours the first time because I did not connect then disconnect the headphones there.

I assume that this means that this bug is probably not caused by the kernel? After all, it only started occurring recently for me.

(In reply to slumberbottom from comment #18)
> (In reply to Takashi Iwai from comment #12)
> > As asked in comment 2, we need to know whether it's a kernel regression.
> > Try the older kernels found in my OBS projects e.g. home:tiwai:kernel:6.2,
> > home:tiwai:kernel:6.1, ...
> >  
> > http://download.opensuse.org/repositories/home:/tiwai:/kernel:/6.2/standard/
> 
> I’m trying kernel 6.2 again. The same bugs are present as in 6.3. I assume
> that I did not notice this when I tested it for ~2 hours the first time
> because I did not connect then disconnect the headphones there.
> 
> I assume that this means that this bug is probably not caused by the kernel?
> After all, it only started occurring recently for me.

It's possible.  Did you get the bluetooth stack update such as bluez package recently?  Check the zypper log.

If it's about bluez or such package, you may try to downgrade them from TW history repo, too:
  http://download.opensuse.org/history/

(In reply to slumberbottom from comment #16)

> After disconnecting the headset and turning Bluetooth off and on again, I
> now have three visually identical "Headset (Pixel Buds A-Series)" entries in
> the widget.

The device duplication looks like this bug:
https://bugzilla.opensuse.org/show_bug.cgi?id=1214374

Thanks, that must be!

Then TW will receive the fix soon later.  You can try the packages in OBS multimedia:libs beforehand, too.

(In reply to Bálint Tóth from comment #20)
> (In reply to slumberbottom from comment #16)
> 
> > After disconnecting the headset and turning Bluetooth off and on again, I
> > now have three visually identical "Headset (Pixel Buds A-Series)" entries in
> > the widget.
> 
> The device duplication looks like this bug:
> https://bugzilla.opensuse.org/show_bug.cgi?id=1214374

It does indeed. Thank you very much for pointing it out. Seems like the fix should be out soon, so I’ll just wait for that.

Seems I simply got two bugs at close to the same time. Hopefully, at least one will be fixed soon.

Let's close.

(In reply to Takashi Iwai from comment #23)
> Let's close.

What do you mean? At least for me, the Bluetooth issue, which was the main I made this report, is still there. Is there an update somewhere?

Yes, the pipewire fix is already on its way to TW (or already included).
Make this as dup to be more obvious.

*** This bug has been marked as a duplicate of bug 1214374 ***

(In reply to Takashi Iwai from comment #25)
> Yes, the pipewire fix is already on its way to TW (or already included).
> Make this as dup to be more obvious.
> 
> *** This bug has been marked as a duplicate of bug 1214374 ***

Just to be clear, the issues are supposed to fixed by this point, aren’t they? 

It’s been almost two weeks since your comment. I’ve last updated everything via sudo zypper dup within the last 24h, and Bluetooth is still entirely unusable due to cutting off repeatedly.

I’ll be changing out SUSE for another distro regardless now what I’ll finally have some time soonish, but I’d feel better if I could actually see the bug fixed on my system beforehand.

Check whether the rpm changelog of pipewire and related packages, and verify whether the bug 1214374 is mentioned there.