On Tuesday, 28 April 2020 19:29:18 BST Mark Knecht wrote:
> On Tue, Apr 28, 2020 at 8:11 AM Peter Humphrey <pe...@prh.myzen.co.uk>
> wrote:
> > On Tuesday, 28 April 2020 15:21:09 BST Mark Knecht wrote:

> Ah, so now we have more clues about what's going on. KDE supplies
> pulseaudio. AFAIK it's part of the KDE installation on other distros. I'm
> running Kubuntu LTS, not Gentoo, so I have pulseaudio because it's what the
> Kubuntu guys give me. You have a USE flag that __YOU__ took responsibility
> for turning off. (I'm not clear from this discussion what packages have a
> pulseaudio flag - multiple packages I assume?

I don't think pa is part of KDE, unless you install it along with systemd.  
Otherwise, KDE's phonon can be installed with the pulseaudio USE flag enabled, 
in which case pa is dragged in.

  media-libs/phonon
     Available versions:  
            4.11.1-r1   [debug designer gstreamer pulseaudio +vlc]
     Installed versions:  4.11.1-r1(10:37:13 04/12/19)(vlc -debug -designer -
gstreamer -pulseaudio)
     Homepage:            https://phonon.kde.org/
     Description:         KDE multimedia abstraction library


> Or your choice to disable USE flags has removed some of the 'features' of
> KDE. Again, I'm using completely updated stable Kubuntu LTS for my
> day-to-day systems so there are clearly differences. However I suggest here
> that the reason there is no multimedia under audio in system settings may
> be because you haven't included the pulseaudio USE flag.

I think with openrc the pulseaudio USE flag is optional, but haven't looked 
into the profile to see what it enables.


> If Alsa under the hood is doing everything you need then let's drop the
> pulseaudio part. pulseaudio is conceptually just a mixer.

Yes, and if some application requires pulseaudio, I think the apulse package 
provides a partial implementation of the PulseAudio API and libraries for alsa 
to use instead its own dmix, dsnoop, and plug plugins in place of pulseaudio.


> Have you blacklisted the snd_hda_intel driver, at least as a test? If so,
> do you only see the USB card and the snd_usb_driver in /proc/asound? If so
> do you have sound from the USB device?

With a broken sound card which will never work again, blacklisting the 
snd_hda_intel driver is a 'sound' strategy (sorry, couldn't resist the pun).


> I have nothing against creating an asound.conf file, if you want to, but I
> don't have any recent experience with doing that. However it should allow
> you to set your USB device as default if it's done correctly but in this
> test configuration with blacklisted snd_hda_intel drivers I don't think
> it's necessary and cannot see how it improves anything yet.
> 
> Mark

Right, an asound.conf file is just a way of configuring alsa itself to select 
an audio card as a primary device, rather than disabling a device at a kernel 
driver level.  Both approaches will work equally, although blacklisting a 
driver means it will be disabled for any other audio devices which may need it 
in the future.

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to