Requests for current-next (15.0-->15.1)

glennmcc · 04-14-2024, 08:26 AM

Quote:

Originally Posted by alex14641

Can we have bluetooth audio w/o PA or WP?

My dentures are white, not blue.

But anyways.... it seems that BT audio is possible with 'bluez-alsa

https://bbs.archlinux.org/viewtopic.php?id=265641

garpu · 04-14-2024, 08:27 AM

Quote:

Originally Posted by glennmcc

For many years we had only alsa.

Then pulseaudio was added to the mix.

Then pipewire was added to the mix.

Then wireplumber was added to the mix.

Is it time to KISS by switching back to just alsa ?

wireplumber is part of pipewire, and pipewire is a hell of a lot better than pulseaudio, it's not even a fair comparison, at least for the audio work I do. Hell, it's replaced alsa + jack for me. At this point, I'd have to go kicking and screaming back to using alsa and jack.

kgha · 04-14-2024, 08:51 AM

A kernel bug (regression) at lest since 6.6.23 (and in 6.7 and 6.8 series) causes a bluetooth malfunction affecting blueman, see
https://bugzilla.kernel.org/show_bug.cgi?id=218680

Apparently the commit "81526f2920bf8a03b670dbc2d45f35f204344d55" is the culprit. Would a patched kernel be possible? Or should we wait for a fix in next release?

Patch available here: https://lore.kernel.org/all/20240404...4622@changeid/

alex14641 · 04-14-2024, 09:13 AM

Quote:

Originally Posted by glennmcc

My dentures are white, not blue.

But anyways.... it seems that BT audio is possible with 'bluez-alsa

https://bbs.archlinux.org/viewtopic.php?id=265641

I played with bluea-alsa a while back: it had no PA bridge like pipewire-pulse, so it was a little tricky make sound work with everything.

pghvlaans · 04-14-2024, 10:27 AM

Quote:

Originally Posted by henca

IMHO such a selection dialog would be slightly annoying for all those users installing Slackware on something else than a laptop with synaptics hardware.

That's a good point. Maybe just make libinput the default in that case, unless there's incompatible hardware floating around.

marav · 04-14-2024, 10:44 AM

elogind

There is a duplicate in the SlackBuild

Code:

  -Dpamlibdir=/lib${LIBDIRSUFFIX}/security \
  -Dudevrulesdir="/lib/udev/rules.d" \
  -Ddocdir="/usr/doc/$PKGNAM-$VERSION" \
  -Dhtmldir="/usr/doc/$PKGNAM-$VERSION/html" \
  -Dmandir="/usr/man" \
  -Dman=enabled \
  -Dhtml=disabled \
  -Dbashcompletiondir="/usr/share/bash-completion/completions" \
  -Dnobody-user=nobody \
  -Dnobody-group=nogroup \
  -Dpam=enabled \
  -Dpamlibdir="/lib${LIBDIRSUFFIX}/security" \

Also, during the build we have

Code:

build mode                     : developer

Is this something we want?
If not, we should use:

Code:

-Dmode=release

volkerdi · 04-14-2024, 12:07 PM

Quote:

Originally Posted by glennmcc

For many years we had only alsa.

Then pulseaudio was added to the mix.

Then pipewire was added to the mix.

Then wireplumber was added to the mix.

Is it time to KISS by switching back to just alsa ?

No, but I'm in no hurry whatsoever to move to pipewire as default until it works as good for *most users* as pulseaudio does now.

Example: I like to fire up a machine, log in on a virtual console, and fire up mocp as my music server. Doesn't work with pipewire.

As it is now, I don't think there's too much burden in enabling pipewire on Slackware. Use it if you like.

rizitis · 04-14-2024, 12:36 PM

Quote:

Originally Posted by volkerdi

No, but I'm in no hurry whatsoever to move to pipewire as default until it works as good for *most users* as pulseaudio does now.

Example: I like to fire up a machine, log in on a virtual console, and fire up mocp as my music server. Doesn't work with pipewire.

As it is now, I don't think there's too much burden in enabling pipewire on Slackware. Use it if you like.

I m just wondering if you remove this line "SoundDriver = PULSEAUDIO:JACK:ALSA:OSS" from .moc/config is it working?
edit :or put ALSA in first place?

glennmcc · 04-14-2024, 12:59 PM

Sheesh... did no-one see that 'wink'

?

LOL

volkerdi · 04-14-2024, 01:02 PM

Quote:

Originally Posted by glennmcc

Sheesh... did no-one see that 'wink'

?

LOL

Of course not

DryFalls · 04-14-2024, 01:04 PM

I can confirm that rolling back (both) polkit to polkit-123-x86_64-2 and elogind to elogind-252.23-x86_64-2 fixes the problems resuming networkmanager/nmapplet/networking after suspend. Maybe we could do this until the boys upstairs can sort themselves out.

df

volkerdi · 04-14-2024, 01:18 PM

Quote:

Originally Posted by DryFalls

I can confirm that rolling back (both) polkit to polkit-123-x86_64-2 and elogind to elogind-252.23-x86_64-2 fixes the problems resuming networkmanager/nmapplet/networking after suspend. Maybe we could do this until the boys upstairs can sort themselves out.

df

We'll do something soon. At this point I'm pretty sure that the elogind 255 branch isn't really stable enough yet. I moved to that because I thought we needed it to finally be able to upgrade libgudev, but it turns out they'd solved that issue a while ago (but I don't recall seeing anything about it in the NEWS, etc). So there really isn't any feature that we need from the 255 branch.

ZhaoLin1457 · 04-14-2024, 01:19 PM

Quote:

Originally Posted by volkerdi

No, but I'm in no hurry whatsoever to move to pipewire as default until it works as good for *most users* as pulseaudio does now.

Example: I like to fire up a machine, log in on a virtual console, and fire up mocp as my music server. Doesn't work with pipewire.

As it is now, I don't think there's too much burden in enabling pipewire on Slackware. Use it if you like.

So, using an elegant way you say: NEVER.

Because you condition the adoption of PipeWire as default, by a capability that is specific to PulseAudio: its autostart.

As far as I know, no, PipeWire is not supposed to autostart. And considering that PipeWire daemons are built to be precisely controlled by a service supervisor, and in a precise order, I don't think they will ever have this autostart capability.

If we give up this autostart ability, nothing stops a user from using PipeWire in a Linux console by adding the following snippet to ~/.profile:

Code:

/usr/bin/daemon -rB --pidfiles=~/.run --name=pipewire /usr/bin/pipewire
/usr/bin/daemon -rB --pidfiles=~/.run --name=wireplumber /usr/bin/wireplumber
/usr/bin/daemon -rB --pidfiles=~/.run --name=pipewire-pulse /usr/bin/pipewire-pulse

I never tried with mocp, but after logging in, it works perfectly to watch movies using MPlayer, with the following command:

Code:

mplayer -vo fbdev2 -ao pulse -quiet "/path/to/coolmovie.mkv"

Also, a Wayland/Plasma6 session that is launched with startkwayland (and that uses PipeWire intensively) works perfectly. And after closing this Plasma6 session, I can continue to watch movies correctly in MPlayer, in a Linux console.

To be honest, the big difference between PulseAudio and PipeWire would not be this "autostart" , but PulseAudio's autostop.

Because you could very well put the 3 commands in a script from /etc/profile, and every time, when logging in, the PipeWire daemons start automatically.

But in the case of PipeWire, the first user who logs in will block the audio card in his seat. Whereas PulseAudio daemon will "autostop" when not in use under that particular user, so it will release the audio card. This solves at least partially the sharing of audio cards between different users.

glennmcc · 04-14-2024, 02:35 PM

n/bluez-5.74-x86_64-1.txz: Upgraded.

KEWL.

Now, can we get bluez-alsa so that we're on the way to going back to what everyone just LOVED to have "fun" with ?

Referring to that "gem" of a time when 'extra' contained the 'pure alsa system'.

ZhaoLin1457 · 04-14-2024, 02:44 PM

Quote:

Originally Posted by glennmcc

n/bluez-5.74-x86_64-1.txz: Upgraded.

KEWL.

Now, can we get bluez-alsa so that we're on the way to going back to what everyone just LOVED to have "fun" with ?

Referring to that "gem" of a time when 'extra' contained the 'pure alsa system'.

A handful of ALSA purists can be hardly defined as "everyone" . Let's thank the god of Slackware that that project died because it unnecessarily consumed the valuable time of the Slackware team.

Personally, I remember with horror the time when only ALSA was available and I had to play with alsamixer to activate the headphones and the eternal battles with HDMI that used to became the default when I didn't need it, but didn't work when I wanted it. No, I don't regret those times.