It would be great if the pulseaudio package had a ~amd64 that would track a higher pulseaudio version than stable, specifically 13.99.2. The reason for this is that all the recent Renoir based AMD laptops have issues with pulseaudio 13 due to it not handling the dmic array which is detected as a separate card (hda-intel/realtek does regular audio, asoc/acp does dmic array). Pulseaudio 13.99.2 has fixes for that, allowing a Gentoo user to use Gentoo and the microphone on these kinds of laptops.
Is there any movement on this? It really should be a trivial issue to enable for users. Gentoo usually prides itself on user choice and having the latest versions of software (optionally) available! This is one of the only packages that does not have a ~amd64 higher-version'ed variant.
(In reply to Rubin Simons from comment #1) > Is there any movement on this? It really should be a trivial issue to enable > for users. Gentoo usually prides itself on user choice and having the latest > versions of software (optionally) available! This is one of the only > packages that does not have a ~amd64 higher-version'ed variant. Nobody had the time to do it yet, I guess. It's not always trivial to bump to a new version, no.
This will need some news item or USE flag handling for the GNOME routing reset, in addition to exposing some new options (gstreamer) and hopefully using meson. If autotools is used, then there's the bashism fixes from Poly-C as well.
Hi Regarding meson build, I just fixed one of missing pieces, meson oss-output option to enable/disable OSS support in pulseaudio. Change is merged to upstream master now https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/423 While testing meson build I'm not sure how to implement support for elogind use flag. Also locale part does not seem to respect my selection and installs every translation available. Otherwise I seem to have working pulseaudio-14.0 built with meson. I can upload my changes here or submit a patch (where?) if that would help to move forward with pulseaudio update to 14.0 and/or to switch to meson build.
Regarding GNOME routing reset, I personally would consider this a minor issue and would vote for news item only.
Regarding meson build there is an issue with CANONICAL_HOST changing from x86_64-pc-linux-gnu with autotools to x86_64 with meson. This should be dealt with otherwise this effectively resets user configuration, since configuration database files are stored in ~/.config/pulse/xxx-yyy.${CANONICAL_HOST}.gdbm
The routing issue is probably considered less minor for those who use or have used GNOME. My current thinking has been along the way of a local USE flag with appropriate description (not a USE=gnome) and a news item with the news item possibly timed for stabling time only. Meanwhile we don't want to reset everything for everyone unconditionally either. Which that CANONICAL_HOST change would effectively do as well, making the route reset stuff moot, I believe. So we shouldn't let that happen (good catch btw), or if we do, it'd be at least a conscious decision with perhaps a different worded news item, and then I believe no need to worry about the routing reset, as it would effectively do that anyhow (as I believe the routing is saved in those gdbm files). Do you have any upstream references for the CANONICAL_HOST stuff with meson? Feel free to attach your ebuild here.
Just filed new issue upstream describing issue with migration to meson produced binaries https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1062
Created attachment 675550 [details] pulseaudio-14.0.ebuild from 13.0-r1 with minor patch adjustment This is a starting point to have pulseaudio 14.0 ebuild as a copy of 13.0-r1 ebuild with minor modification to disable flat volumes patch where just a single hunk is left unapplied. Signed-off-by: Igor V. Kovalenko <igor.v.kovalenko@gmail.com>
Created attachment 675553 [details, diff] adjusted flat volumes patch for pulseaudio-14.0 Remaining hunk of flat volumes patch for pulseaudio-14.0 Signed-off-by: Igor V. Kovalenko <igor.v.kovalenko@gmail.com>
Created attachment 675559 [details, diff] patch to convert pulseaudio-14.0 to meson build This would convert pulseaudio-14.0 ebuild to meson. Needs accompanying backport patch from upstream merge request (!423) to restore optional OSS output for 'oss' use flag. Signed-off-by: Igor V. Kovalenko <igor.v.kovalenko@gmail.com>
Created attachment 675562 [details, diff] accompanying patch for meson build to restore optional processing of OSS output for 'oss' use flag
Comment on attachment 675562 [details, diff] accompanying patch for meson build to restore optional processing of OSS output for 'oss' use flag This is the change merged to upstream master https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/423
Submitted patch to allow overriding CANONICAL_HOST string https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/424
(In reply to Igor V. Kovalenko from comment #14) > Submitted patch to allow overriding CANONICAL_HOST string > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/424 Submitted another patch to allow backwards-compatible database file names. https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/425
Changes in 14.2 release: * Support upto 8 mixer channels on ALSA devices * Handle ALSA jacks with the same name but different index values * Switch to plugged-in headset when mic availability is unknown * Fix a potential segfault in the Bluetooth oFono HFP backend * Fix a problem with module-ladspa-sink when avoid-resampling=true * Update to the NEWS file for 14.0 (and 14.1) * Fix database names containing canonical host for meson builds For packagers who have switched to meson, the last item should be particularly relevant. These changes were already in 14.1 but they broke unplug event handling and fixed that with 14.2
+1 for updating. I use Acer Swift 3 (SF314-42) laptop with AMD Renoir, and my problem is that both HDMI and analog HDA cards have the same hardware card name, and HDMI has lower pci address, so pulseaudio does not see the analog card at all. I use the two following upstream patches in /etc/portage/patches as a workaround: c8f065250dde966825f171ff817f7301f423a42e ucm: add possibility to skip the UCM card completely c1a7e3c59d5e2dcb6ca95c66d74c0ca7a45395d9 alsa-ucm: use ucm2 name for the direct card index open They are parts of https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/305 and https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/213 respectively. Both patches already present in v13.99.2. ...or I will wait patiently for 14.x.
If meson is too much to deal with now, just use good old autotools?
Meson build should not be an issue with pulseaudio-14.2 already, all changes I attached here are merged upstream. The only questionable part is elogind integration, I do not use it so have no idea how to handle that in ebuild.
I notice your Meson ebuild has the ARM NEON line commented out. This is handled automatically by Meson's unstable-simd module. Unfortunately this appears to be automagic. Regarding elogind, there doesn't seem to be a simple solution. They've unfortunately lumped the various systemd-related features into one so you cannot say you only want the logind module. Even if they hadn't, there's currently no way to override the pkg-config lookup like there was with Autotools. See https://github.com/mesonbuild/meson/issues/5192. The first part needs to be resolved with upstream and if we're going that far, we may as well get them to support elogind as well.
(In reply to James Le Cuirot from comment #20) > I notice your Meson ebuild has the ARM NEON line commented out. This is > handled automatically by Meson's unstable-simd module. Unfortunately this > appears to be automagic. I do not have experience with pulseaudio on arm hardware so if this is a real issue probably need help looking into this. > Regarding elogind, there doesn't seem to be a simple solution. They've > unfortunately lumped the various systemd-related features into one so you > cannot say you only want the logind module. Even if they hadn't, there's > currently no way to override the pkg-config lookup like there was with > Autotools. See https://github.com/mesonbuild/meson/issues/5192. The first > part needs to be resolved with upstream and if we're going that far, we may > as well get them to support elogind as well. Should work if I add elogind feature to pulseaudio which would just enable module-systemd-login linked with libelogind if that is available. This will produce the same module binary as with autotools, I will be able to test if that builds but cannot do runtime test.
(In reply to Igor V. Kovalenko from comment #21) > I do not have experience with pulseaudio on arm hardware so if this is a > real issue probably need help looking into this. I think we can live with it. It should probably be addressed in Meson rather than PulseAudio anyway. > Should work if I add elogind feature to pulseaudio which would just enable > module-systemd-login linked with libelogind if that is available. This will > produce the same module binary as with autotools, I will be able to test if > that builds but cannot do runtime test. That would be much appreciated, thanks. I'm happy to test too.
(In reply to James Le Cuirot from comment #22) > > Should work if I add elogind feature ... > That would be much appreciated, thanks. I'm happy to test too. Please have a look at this change https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/502 Took some time to test as I'm on systemd :) but it works for me. If accepted, for Meson-based ebuild there will be this trivial change to have elogind supported: --- a/media-sound/pulseaudio/pulseaudio-14.0.ebuild +++ b/media-sound/pulseaudio/pulseaudio-14.0.ebuild @@ -197,6 +197,7 @@ multilib_src_configure() { $(meson_feature dbus) $(meson_feature X x11) $(meson_feature systemd) + $(meson_feature elogind) $(meson_use ipv6)
Is there a ready-to-test 14.2 ebuild, or should I just take the 14.0 candidate attachment from this bug and rename it?
(In reply to Leho Kraav (:macmaN @lkraav) from comment #24) > Is there a ready-to-test 14.2 ebuild, or should I just take the 14.0 > candidate attachment from this bug and rename it? Yes please use the existing attachments. If you would take the proposed ebuild and apply gentoo-pulseaudio-14.0-to-meson.patch then end result should work to build pulseaudio-14.0 and would only miss two things: - keywords changes from portage happened after end of November 2020 - most recent $(meson_feature elogind) change we just discussed I did not tested changing version to 14.2 but that should just work.
Wanted to clarify that if it is desired to stick to autotools build, the only real change to ebuild is cleaned up pulseaudio-14.0-disable-flat-volumes.patch otherwise current portage ebuild can be copied as is and should work with version change to 14.2
I will try to get something in to main tree this weekend based on the contributions posted here, potentially package.masked until we figure out the news item stuff for https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/14.0/#compile-timeoptiontoforgetpre-14.0streamrouting
Sorry, ended up busy with various security bumps and stablings. If someone feels confident about the meson build being good, and the configuration/routing files being the same now as they were with autotools, I don't mind if someone adds some package.masked in tree for now. The mask reasoning can just say "Pending news item about potential routing reset need for some setups" or whatever, with a reference to this bug here. Otherwise there's hopefully the upcoming weekend, as far as my active work is concerned on this...
Renaming the ebuild to 14.2 and using the patches except the oss one, I get an error about needing at least one echo canceller. However, I do have webrtc-aec enabled, and it does show up in the USE line at the top of build.log, but the actual meson setup line has it disabled. Might I have a problem with eclasses needing updating? (I see some other set USE flags where the item seems to still be disabled in the build.) I'll be glad to post logs, but am hoping someone might point to a likely local misconfiguration.
Created attachment 688098 [details] build.log I've attached the log from a failed build. It is essentially the same for 14.0, 14.1, and 14.2. I also see 'WARNING: Unknown options: "oss-output, tcpwrap"', but that is already after the "meson setup" line, which has many items =disabled that should really be enabled.
(In reply to Jack from comment #30) > Created attachment 688098 [details] > build.log > > I've attached the log from a failed build. It is essentially the same for > 14.0, 14.1, and 14.2. I also see 'WARNING: Unknown options: "oss-output, > tcpwrap"', but that is already after the "meson setup" line, which has many > items =disabled that should really be enabled. Hi Jack, you miss the patch for oss-output option which explains unknown option oss-output. I'm not sure about rest of errors though. It builds successfully on my system - is it because I have full multilib here and webrtc-aec is installed for both 32bit and 64bit?
(In reply to Mart Raudsepp from comment #27) > I will try to get something in to main tree this weekend based on the > contributions posted here, potentially package.masked until we figure out > the news item stuff for > https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/14.0/#compile- > timeoptiontoforgetpre-14.0streamrouting Hi Mart, I think it may make sense to stick to autotools for now, so only adjusted flat volumes patch for pulseaudio-14.0 is needed. Does not look like Meson build is easy change, I probably got multilib_native_usex wrong and my testing is limited to default multilib profile. If Meson build would still be more preferable option, please let me know - I can prepare a patch backporting all meson changes from pulseaudio master for 14.2 sources and update the meson conversion patch.
In reply to comment 31: I do have a multilib system, but webrtc is only installed 64 bit. However, I think all those other errors are meson related In reply to comment 32: reverting the meson patch, pulseaudio-14.2 installed fine. I would like to see meson used eventually, but it's certainly not critical in the short term. You may be right about something wrong with your use of multilib_native_usex, but I see pa_meson_multilib_native_use_enable and _feature, so I don't know if it's a different problem, or I just don't follow the unwinding of those functions to the actual meson setup line.
Looks like autotools support was dropped at upstream: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/commit/f4bce0bb9808a9abd667e71d72f71bd5bd9e198e
The flat volumes patch is not needed since version 14.0: https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/14.0/#flatvolumesarenowdisabledbydefault. Any special reason why this isn't updated yet? Renaming the ebuild from ::gentoo and dropping the patch worked fine.
Created attachment 691818 [details] pulseaudio-9999 ebuild This combines everything(sans oss) in here to a 9999 PA ebuild In master you are getting HFP support and soon mSBC too.
(In reply to Joakim Tjernlund from comment #36) > Created attachment 691818 [details] > pulseaudio-9999 ebuild > > This combines everything(sans oss) in here to a 9999 PA ebuild > > In master you are getting HFP support and soon mSBC too. Note the addition of: -D modlibexecdir="${EPREFIX}"/"usr/$(get_libdir)/pulseaudio-${PV}"
Created attachment 691821 [details] pulseaudio-9999 , now with working oss USE flag
Regarding latest 9999 ebuild: 1. There is requirement to have noise cancelation implementation, so >webrtc-aec? ( >=media-libs/webrtc-audio-processing-0.2[${MULTILIB_USEDEP}] ) Also there must be webrtc-aec or adrian-aec use flag. Or no use flag at all. 2. There is bluez5-gstreamer flag and gstreamer deps. Looks like they are missing
(In reply to Alexey Shevchuck from comment #39) > Regarding latest 9999 ebuild: > 1. There is requirement to have noise cancelation implementation, so > >webrtc-aec? ( >=media-libs/webrtc-audio-processing-0.2[${MULTILIB_USEDEP}] ) New req. for PA master? Easy to add though > > Also there must be webrtc-aec or adrian-aec use flag. Or no use flag at all. There is webrtc-aec USE flag > > 2. There is bluez5-gstreamer flag and gstreamer deps. Looks like they are > missing gstreamer is not my cup of tea, someone else needs to work this out.
(In reply to Igor V. Kovalenko from comment #32) [....] > Does not look like Meson build is easy change, I probably got > multilib_native_usex wrong and my testing is limited to default multilib > profile. > If Meson build would still be more preferable option, please let me know - I > can prepare a patch backporting all meson changes from pulseaudio master for > 14.2 sources and update the meson conversion patch. You are right about the multilib_native_... they aren't right, in that you do want all those pieces enabled in both libs, not only the native one. You also need to add [${MULTILIB_USEDEP}] to sbc and possibly some other deps. I'll post the version that worked for me, and also seems to give me a working HSP (more testing needed to fully confirm.)
Created attachment 693108 [details] updated 9999 ebuild Modified version of the 9999 ebuild that works for me.
Note I modified pa_meson_multilib_native_use_enable() and _feature() but I suspect there is a cleaner way to have the same effect.
(In reply to Jack from comment #43) > Note I modified pa_meson_multilib_native_use_enable() and _feature() but I > suspect there is a cleaner way to have the same effect. If I understand ebuild machinery correctly, then libsndfile, libcap, tcpd, dbus, sbc, libasyncns and systemd dependencies should only be required with profile native ABI - these are for daemon process use only. Not sure if it is worth trying to clean these up at this point though?
You may be right, in which case both your original and my modified versions of those two functions are necessary (possibly better implemented) and use the appropriate one for each use flag. For me, all those initial failures were for necessary things (USE flag set) still getting disabled or false on the 32 bit build. I haven't used it very much yet, but the version I built with the ebuild I attached is working fine so far. Building those pieces into the 32 bit build may take extra compile cycles, but as long as the compile doesn't fail, I don't see what could be hurt by it. Hopefully others will test this so any problems will surface sooner rather than later.
Renaming attached 14.0 ebuild to 14.2 and commenting out the patch from it, works on 64bit, don't know about 32bit
When trying to emerge pulseaudio-9999 I'm getting: Run-time dependency soxr found: NO (tried pkgconfig) ../pulseaudio-9999/meson.build:588:0: ERROR: Dependency "soxr" not found, tried pkgconfig If I disable sox support with USE="-soxr" I'm getting: Run-time dependency fftw3f found: NO (tried pkgconfig) ../pulseaudio-9999/meson.build:645:0: ERROR: Dependency "fftw3f" not found, tried pkgconfig This continues with other libraries If I disable this feature as well... Packages media-libs/soxr-0.1.3-r1 and sci-libs/fftw-3.3.9 are installed and pulseaudio-13.0-r1 works fine with these USE flags set.
which ebuild are you using? It sound like you used the original one posted - which disabled things in the 32 bit build which seem to be necessary. Is the 32 or 64 bit build failing, and what is the actual meson line used? Does it match your command line in terms of what is disabled/enabled?
In order to get a Meson based ebuild for a newer version into the Gentoo tree, I have opened a draft PR that's based on the version posted by Joakim Tjernlund in comment 38 which, I believe, is based on previous work by Igor V. Kovalenko and possibly others. To that extent it would be very helpful to have formal sign-off to indicate compliance with Gentoo's Certificate of Origin (GLEP 76) from everyone whose work contributed to the creation of that ebuild. Of course everyone is welcome to provide feedback but please be considerate of the fact that it's still an early draft of a massive do-over. ;) https://github.com/gentoo/gentoo/pull/20388
(In reply to Niklāvs Koļesņikovs from comment #49) > In order to get a Meson based ebuild for a newer version into the Gentoo > tree, I have opened a draft PR that's based on the version posted by Joakim > Tjernlund in comment 38 which, I believe, is based on previous work by Igor > V. Kovalenko and possibly others. To that extent it would be very helpful to > have formal sign-off to indicate compliance with Gentoo's Certificate of > Origin (GLEP 76) from everyone whose work contributed to the creation of > that ebuild. > > Of course everyone is welcome to provide feedback but please be considerate > of the fact that it's still an early draft of a massive do-over. ;) > https://github.com/gentoo/gentoo/pull/20388 I'll happily add my sign-off but where? Would it suffice to be in a comment to PR 20388 or here?
(In reply to Igor V. Kovalenko from comment #50) > (In reply to Niklāvs Koļesņikovs from comment #49) > > In order to get a Meson based ebuild for a newer version into the Gentoo > > tree, I have opened a draft PR that's based on the version posted by Joakim > > Tjernlund in comment 38 which, I believe, is based on previous work by Igor > > V. Kovalenko and possibly others. To that extent it would be very helpful to > > have formal sign-off to indicate compliance with Gentoo's Certificate of > > Origin (GLEP 76) from everyone whose work contributed to the creation of > > that ebuild. > > > > Of course everyone is welcome to provide feedback but please be considerate > > of the fact that it's still an early draft of a massive do-over. ;) > > https://github.com/gentoo/gentoo/pull/20388 > > I'll happily add my sign-off but where? Would it suffice to be in a comment > to PR 20388 or here? I think here will do, you added your stuff here. Anyway here is mine SOF: Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
(In reply to Joakim Tjernlund from comment #51) > (In reply to Igor V. Kovalenko from comment #50) > > (In reply to Niklāvs Koļesņikovs from comment #49) > > > In order to get a Meson based ebuild for a newer version into the Gentoo > > > tree, I have opened a draft PR that's based on the version posted by Joakim > > > Tjernlund in comment 38 which, I believe, is based on previous work by Igor > > > V. Kovalenko and possibly others. To that extent it would be very helpful to > > > have formal sign-off to indicate compliance with Gentoo's Certificate of > > > Origin (GLEP 76) from everyone whose work contributed to the creation of > > > that ebuild. > > > > > > Of course everyone is welcome to provide feedback but please be considerate > > > of the fact that it's still an early draft of a massive do-over. ;) > > > https://github.com/gentoo/gentoo/pull/20388 > > > > I'll happily add my sign-off but where? Would it suffice to be in a comment > > to PR 20388 or here? > > I think here will do, you added your stuff here. > Anyway here is mine SOF: > Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com> Here is mine for all relevant changes here: Signed-off-by: Igor V. Kovalenko <igor.v.kovalenko@gmail.com>
Yes, I believe a sign-off here is sufficient. I have done a rebase to reword the first commit's message and will force push the overwritten branch later today. Thank you for your quick response as well as doing the work in the first place.
Created attachment 700008 [details] Build log for pulseaudio-9999-r2.ebuild missing 32-bit libraries
(In reply to Jack from comment #48) > which ebuild are you using? It sound like you used the original one posted > - which disabled things in the 32 bit build which seem to be necessary. Is > the 32 or 64 bit build failing, and what is the actual meson line used? > Does it match your command line in terms of what is disabled/enabled? Sorry, I've attached the full log. It is the latest pulseaudio-9999-r2.ebuild. If I enable 'abi_x86_32' for the affected libraries it works: media-libs/soxr abi_x86_32 sci-libs/fftw abi_x86_32 media-libs/webrtc-audio-processing abi_x86_32 pulseaudio ebuild should complain about missing abi_x86_32 for dependencies, shouldn't it? I wonder why these weren't needed for pulseaudio-13.
I have provisionally added the media-libs/soxr, sci-libs/fftw and media-libs/webrtc-audio-processing to require matching ABI. An investigation into PA multilib support is yet to come. Also seeing how tcpd and OSS support are commented out in 14.2, I will likely switch to a snapshot of the current git main branch, so that patching of the build system is not needed. Alternatively oss and tcpd USE flags should be dropped for 14.2.
I also had to manually upgrade to pulseaudio 14.2 or kernel drivers using sof-firmware wouldn't work. Thankfully a blog mentioned pulseaudio had to be upgraded from an overlay for sof-firmware to work or it'd be harder to find out what prevented sof-firmware kernel drivers to work.
(In reply to Andrea from comment #57) > I also had to manually upgrade to pulseaudio 14.2 or kernel drivers using > sof-firmware wouldn't work. > > Thankfully a blog mentioned pulseaudio had to be upgraded from an overlay > for sof-firmware to work or it'd be harder to find out what prevented > sof-firmware kernel drivers to work. https://github.com/perfect7gentleman/pg_overlay/blob/master/media-sound/pulseaudio/pulseaudio-14.2.ebuild
(In reply to Andrea from comment #57) > I also had to manually upgrade to pulseaudio 14.2 or kernel drivers using > sof-firmware wouldn't work. > > Thankfully a blog mentioned pulseaudio had to be upgraded from an overlay > for sof-firmware to work or it'd be harder to find out what prevented > sof-firmware kernel drivers to work. FYI, if you need bluetooth you should use PA master. Gentoo is lagging behind significantly for both PA and gstreamer, not sure why though.
Joakim, you of all people should know that the PR is actually packaging less than a week old snapshot, so it very much has the goods from git master in it. ;) And as a shameless plug, here's the link for the third time: https://github.com/gentoo/gentoo/pull/20388
(In reply to Niklāvs Koļesņikovs from comment #60) > Joakim, you of all people should know that the PR is actually packaging less > than a week old snapshot, so it very much has the goods from git master in > it. ;) I see that, what I meant PA in Gentoo is old and your PR does not actually count as in Gentoo tree :)
(In reply to Joakim Tjernlund from comment #59) > (In reply to Andrea from comment #57) > > I also had to manually upgrade to pulseaudio 14.2 or kernel drivers using > > sof-firmware wouldn't work. > > > > Thankfully a blog mentioned pulseaudio had to be upgraded from an overlay > > for sof-firmware to work or it'd be harder to find out what prevented > > sof-firmware kernel drivers to work. > > FYI, if you need bluetooth you should use PA master. > > Gentoo is lagging behind significantly for both PA and gstreamer, not sure > why though. Right, thanks for the headsup.. I noticed the BT issue shortly later. Since I couldn't solve this quick, my next favorite solution, is to switch to pipewire to fix it. I have to spend any extra time doing non trivial stuff to make laptop audio+BT work seamlessly, I'd rather spend it on pipewire where the sof-firmware dmic and BT already seem to work fine. keyword: media-video/pipewire ~amd64 use: media-video/pipewire pipewire-alsa whatever set "autospawn = no" in /etc/pulse/client.conf added "/usr/bin/pipewire &" to /etc/xdg/plasma-workspace/env/10-agent-startup.sh and "pkill pipewire" to /etc/xdg/plasma-workspace/shutdown/10-agent-shutdown.sh (I didn't test the pkill yet... this thing is a bit rough..)
(In reply to Andrea from comment #62) > added "/usr/bin/pipewire &" to > /etc/xdg/plasma-workspace/env/10-agent-startup.sh and "pkill pipewire" to > /etc/xdg/plasma-workspace/shutdown/10-agent-shutdown.sh > > (I didn't test the pkill yet... this thing is a bit rough..) As a quick heads up, the 0.3.26 ebuild, when -systemd USE flag is set, installs /etc/xdg/autostart/pipewire.desktop file. It only works for XDG compliant desktops but Plasma is of those, so you do not need to hook into the agent scripts. In fact, doing that is likely to run pipewire twice. For some weird reason no one has complained yet but maybe you hit the jackpot. ;) You can either ask for assistance on https://www.gentoo.org/get-involved/irc-channels/ or, if you have enough information on what is going wrong, open a new bug against the offending package (most likely media-video/pipewire in your case). The later is especially important if it works without modifications on your part (i.e. with unmodified agent scripts).
(In reply to Niklāvs Koļesņikovs from comment #63) > As a quick heads up, the 0.3.26 ebuild, when -systemd USE flag is set, > installs /etc/xdg/autostart/pipewire.desktop file. It only works for XDG > compliant desktops but Plasma is of those, so you do not need to hook into > the agent scripts. In fact, doing that is likely to run pipewire twice. For > some weird reason no one has complained yet but maybe you hit the jackpot. ;) The double startup was certainly superfluous, but it worked anyway because it's equivalent to logout/login. /usr/libexec/pipewire-launcher does: pkill -u "${USER}" -x pipewire 1>/dev/null 2>&1 exec /usr/bin/pipewire > You can either ask for assistance on > https://www.gentoo.org/get-involved/irc-channels/ or, if you have enough > information on what is going wrong, open a new bug against the offending > package (most likely media-video/pipewire in your case). The later is > especially important if it works without modifications on your part (i.e. > with unmodified agent scripts). It works without modifications with a single user, the question I guess is what happens with multiple users, and why the pkill isn't moved in the shutdown/ instead. It's not a practical short term problem though.
This PulseAudio bug isn't really the right place for this, so I'll just say that you'll need to open a new PipeWire bug if you need to switch users on OpenRC and have them access audio hardware. ;)
Hi, we got first release candidate towards 15.0 now https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/tags/v14.99.1 Among the long list of good stuff it will now be possible to build client-only part with -Ddaemon=false. Could be a good starting point for people already working on making transition easier in future. Do we still have anything missing from 9999 ebuild, and what's the latest? There are already too many files attached here :)
The latest is on GitHub and has had IUSE=+daemon for weeks now. ;) BTW, good job on getting the daemon-less build option merged, Igor. I'll see to updating the PR to 14.99.1 later today and hopefully that will also resolve the issue with one of the tests failing with the current snapshot (discovered earlier today; looks like the test itself is broken but I didn't have time to examine it properly or read the git log to see if it's already fixed or if it caught a genuine bug). Here's the link once again: https://github.com/gentoo/gentoo/pull/20388
(In reply to Niklāvs Koļesņikovs from comment #67) >.. > Here's the link once again: https://github.com/gentoo/gentoo/pull/20388 Thanks! I just submitted a fix to remove libltdl requriement for client-only build https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/557 Alas I only noticed that libltdl is still needed while looking through the pull request. If there are any other issues like this feel free to submit a bug report upstream :)
Created attachment 709728 [details] Configure fails with USE="-doc" and if doxygen is not installed There is a problem during configure with USE="-doc" and doxygen not being installed. It seems doxygen is wanted regardless. ../pulseaudio-14.2/doxygen/meson.build:3: WARNING: The variable(s) 'srcdir' in the input file 'doxygen/doxygen.conf.in' are not present in the given configuration data. Program doxygen found: NO ../pulseaudio-14.2/doxygen/meson.build:9:0: ERROR: Program 'doxygen' not found This does not happen with pulseaudio-13*.
(In reply to Mikkl from comment #69) > Created attachment 709728 [details] > Configure fails with USE="-doc" and if doxygen is not installed > It can be done with simple patch or sed. ! use doc && sed -i /doxygen/d/ meson.build
Doxygen dependency can now be disabled via passing -Ddoxygen=false https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/558
https://github.com/gentoo/gentoo/commit/6c66f69d5e76fc323e084652a1f317a8a9eafa63 https://github.com/gentoo/gentoo/commit/69a2b86a55bdff4f4e9bb3d309f8e7aab477b353 Unkeyworded for now.
> Unkeyworded for now. Built it and seems to work beautiful Installed versions: 14.99.2_pre^t(13:42:02 21.06.2021)(X alsa alsa-plugin asyncns bluetooth daemon dbus gdbm glib gstreamer gtk native-headset orc ssl systemd udev webrtc-aec -doc -elogind -equalizer -forget-missing -ipv6 -jack -lirc -ofono-headset -oss -selinux -sox -system-wide -tcpd -test -zeroconf ABI_MIPS="-n32 -n64 -o32" ABI_S390="-32 -64" ABI_X86="64 -32 -x32")
Keyworded and upgraded to this three days ago. Everything seems to be working fine so far in KDE Plasma.
Just wanted to add on a quick note: I emerged the newest Ebuild to support my Astro A50 Gen4 Headset's advanced features. Everything works very fine after keywording it. Thank you all for the great work!
Keywords restored via https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=004d373f6e7dd5fafa1edb534307132e035d2a92
