- Arch-proaudio - lists.archlinux.org

What replaces pulseaudio-jack when you go to pipewire? Why do the apps keep disappearing?
by Sean Snell 23 Apr '24

23 Apr '24

Hi, I'm in the process of moving from Pulseaudio/Jack to pipewire and I chose to go with wireplumber if that matters. So far most of this makes sense, I have the new patch bay app qpwgraph working as well as my previously used patchbay app Carla, which also seems like it could still be useful. My sound devices appear to be recognized. The first and most pressing question: When running Gnome, how do I get control of the basic system sound levels back? When using Pulse I'd install pulseaudio-jack and I'd get a Sink and a Source that I'd select in Gnome's settings and that's it, I now have my PC sound routable through Jack. With pipewire all of the apps just seem to do what they want and appear and disappear at random. What can I do to replicate the stability previously given by pulseaudio-jack? The other question I had was about the appear/disappear concept... How do I make the apps persistent so they don't just keep disconnecting/reconnecting where they want by default? When I patch the apps somewhere I need them to stick around, or at least repatch themselves when I need them. Let's use VLC as an example, once VLC is done playing sound the app disappears from the list. Same with Chrome and Firefox; once the noises stop the apps vanish from the patchbay. How can I make them persistent? Thanks for any help I can get with this! Sean

1 0

x42 plugins issue with Kushview Element
by Albert Graef 14 Dec '23

14 Dec '23

Hi David, I have some issues with the gmsynth.lv2 and avldrums.lv2 packages that I'd like to report. I noticed these while testing out Kushview's latest Element version from their gitlab, but the official 0.46.6 version in extra has the same issue. The issue being that Element completely locks up when trying to instantiate these plugins. I like both the x42 plugins (which we use a lot in my courses at JGU) and Element (which I plan to use in lieu of Carla in the future, since in my experience it has better cross-platform compatibility which is important for my students running Mac or Windows on their laptops). So I hope that the issue with those two plugins can be sorted out in some way. The plugins do work fine in Ardour and Carla, which seem to be a little more accommodating. So I initially reported the issue upstream (see https://gitlab.com/kushview/element-external/-/issues/53), but quite frankly I don't think that Element is to blame here. A while back those plugins were changed to link against the system fluidsynth library instead of the bundled stripped-down version included in the upstream source, and that seems to cause the issue. The system fluidsynth library drags in a bunch of additional library dependencies that obviously cause problems with Element. Here they are (ldd /usr/lib/lv2/gmsynth.lv2/gmsynth.so): linux-vdso.so.1 (0x00007ffcbe3fd000) libfluidsynth.so.3 => /usr/lib/libfluidsynth.so.3 (0x00007f7806f48000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f7806d66000) libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00007f7806d15000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f7806bc9000) libsndfile.so.1 => /usr/lib/libsndfile.so.1 (0x00007f7806b42000) libpulse-simple.so.0 => /usr/lib/libpulse-simple.so.0 (0x00007f7806b3b000) libpulse.so.0 => /usr/lib/libpulse.so.0 (0x00007f7806ae4000) libasound.so.2 => /usr/lib/libasound.so.2 (0x00007f78069f2000) libportaudio.so.2 => /usr/lib/libportaudio.so.2 (0x00007f78069c3000) libjack.so.0 => /usr/lib/libjack.so.0 (0x00007f7806984000) libpipewire-0.3.so.0 => /usr/lib/libpipewire-0.3.so.0 (0x00007f78068a0000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x00007f780684f000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007f7806846000) libinstpatch-1.0.so.2 => /usr/lib/libinstpatch-1.0.so.2 (0x00007f780678a000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007f7806728000) libSDL2-2.0.so.0 => /usr/lib/libSDL2-2.0.so.0 (0x00007f780654d000) libreadline.so.8 => /usr/lib/libreadline.so.8 (0x00007f78064f6000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f7806200000) libm.so.6 => /usr/lib/libm.so.6 (0x00007f7806113000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f78064cf000) /usr/lib64/ld-linux-x86-64.so.2 (0x00007f780705e000) libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0 (0x00007f7806078000) libogg.so.0 => /usr/lib/libogg.so.0 (0x00007f78064c4000) libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x00007f7805fcd000) libFLAC.so.12 => /usr/lib/libFLAC.so.12 (0x00007f780647c000) libopus.so.0 => /usr/lib/libopus.so.0 (0x00007f7805f6f000) libmpg123.so.0 => /usr/lib/libmpg123.so.0 (0x00007f7805f12000) libmp3lame.so.0 => /usr/lib/libmp3lame.so.0 (0x00007f7805e9a000) libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x00007f7805e6c000) libpulsecommon-16.1.so => /usr/lib/pulseaudio/libpulsecommon-16.1.so (0x00007f7805de5000) libsystemd.so.0 => /usr/lib/libsystemd.so.0 (0x00007f7805cef000) libffi.so.8 => /usr/lib/libffi.so.8 (0x00007f7805ce4000) libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x00007f7805c6d000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f7805c42000) libasyncns.so.0 => /usr/lib/libasyncns.so.0 (0x00007f7805c38000) libcap.so.2 => /usr/lib/libcap.so.2 (0x00007f7805c2c000) libgcrypt.so.20 => /usr/lib/libgcrypt.so.20 (0x00007f7805ae3000) liblz4.so.1 => /usr/lib/liblz4.so.1 (0x00007f7805ac1000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007f7805a8e000) libzstd.so.1 => /usr/lib/libzstd.so.1 (0x00007f78059bb000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f78059b4000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f78059ac000) libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x00007f7805986000) For comparison, here are the ld libs in the version built straight from the upstream source: linux-vdso.so.1 (0x00007ffe58374000) libm.so.6 => /usr/lib/libm.so.6 (0x00007f094c46c000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f094c320000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f094c13e000) /usr/lib64/ld-linux-x86-64.so.2 (0x00007f094c639000) libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0 (0x00007f094c0a3000) I understand that in general it may be preferable to link to a system lib if available, but in this case this obviously does more harm than good. You really want your plugins to be as lean and mean as possible, and in this case they aren't. Also, Robin has just brought to my attention that the bundled source of fluidsynth is not only stripped down, but optimized for the included soundfonts (GeneralUser_LV2.sf2 in the case of gmsynth) so that they sound much better than with the stock fluidsynth, which is another reason to prefer the bundled fluidsynth. The easiest solution IMHO is to just remove the patch that links against the system fluidsynth library in these two packages; the plugins then work fine with Element as is. Talking about Element, I think that the official 0.46.6 package also needs some love. :) It doesn't build from source currently, as some of the requisite git repositories have gone missing (apparently when KV moved their source to gitlab), and the binary package doesn't appear to run all that well on a current pipewire-based system either. What I noticed on all of my Arch/Manjaro systems is that, even with the simplest of patches, I get an unacceptable latency between MIDI input and audio output, in the hundreds of milliseconds. I get none of that with any of the packages that I built myself (whether 0.46.6 or the latest 1.0.0 build 175), nor with the AppImage from Kushview's website, so the problem actually seems to be in the package from extra (which, if I'm not mistaken, was last rebuilt quite some time ago). Maybe this package just needs to have the PKGBUILD updated and rebuilt. Or you could go straight to the current Element version on gitlab (1.0.0 build 175 at the time of this writing), which is much better. Maybe you can have a look at my updated PKGBUILD for the git version at https://aur.archlinux.org/packages/element-git to see how the current version can be built from the gitlab source. No doubt this needs some more work to get it into extra, but I know that you know how to deal with that. ;-) TIA, Albert -- Dr. Albert Gr"af Computer Music Research Group, JGU Mainz, Germany Email: aggraef(a)gmail.com, web: https://agraef.github.io/

1 0

[arch-proaudio] snd with scheme
by Kenneth Flak 27 Jul '23

27 Jul '23

Hi list, I've recently started working with the snd editor (the audacity debacle gave me that last push...), and I was just wondering what the rationale is for shipping snd with ruby support, instead of the default scheme? Would it be an idea to keep the snd package in community with the scheme default, and instead create a snd-{ruby,forth} package in aur instead for those that use those? Best, Kenneth -- Roosna & Flak - Contemporary Dance & Music Web: roosnaflak.com Code: {github,gitlab}.com/kflak Mastodon: @kf@sonomu.club

3 8

Re: Arch-proaudio Digest, Vol 4, Issue 4
by eile_kerning 10 Apr '23

10 Apr '23

unsubscribe Sent from Proton Mail mobile -------- Original Message -------- On Apr 10, 2023, 04:08, wrote: > Send Arch-proaudio mailing list submissions to arch-proaudio(a)lists.archlinux.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to arch-proaudio-request(a)lists.archlinux.org You can reach the person managing the list at arch-proaudio-owner(a)lists.archlinux.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Arch-proaudio digest..." Today's Topics: 1. Problem with packages supplying dssi-host (Jeanette C.) 2. Re: Problem with packages supplying dssi-host (Christopher Arndt) 3. Re: Problem with packages supplying dssi-host (Jeanette C.) ---------------------------------------------------------------------- Message: 1 Date: Sun, 9 Apr 2023 13:58:53 +0200 (CEST) From: "Jeanette C." Subject: Problem with packages supplying dssi-host To: Arch Linux ProAudio Message-ID: Content-Type: text/plain; format=flowed; charset=US-ASCII Hey hey, I try to clean up my system and wanted to uninstall qtractor, which I can't do since it supplies dssi-host. Why is this necessary, when the dssi package supplies jack-dssi-host? Is there a workaround? Thanks and best wishes, Jeanette -- * Website: http://juliencoder.de - for summer is a state of sound * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g * Audiobombs: https://www.audiobombs.com/users/jeanette_c * GitHub: https://github.com/jeanette-c When you need someone, you just turn around and I will be there Subject: Re: Problem with packages supplying dssi-host To: arch-proaudio(a)lists.archlinux.org Message-ID: Content-Type: text/plain; charset=UTF-8; format=flowed Am 09.04.23 um 13:58 schrieb Jeanette C.: > I try to clean up my system and wanted to uninstall qtractor, which I > can't do since it supplies dssi-host. Why is this necessary, when the > dssi package supplies jack-dssi-host? Is there a workaround? The 'dssi' package should probably also provide 'dssi-host'. It hasn't been updated for a while, so the last update probably pre-dates the introduction of this provides. You could report this as a bug via the link on the package's page: https://archlinux.org/packages/community/x86_64/dssi/ Chris ------------------------------ Message: 3 Date: Sun, 9 Apr 2023 16:05:35 +0200 (CEST) From: "Jeanette C." Subject: Re: Problem with packages supplying dssi-host To: Christopher Arndt Cc: arch-proaudio(a)lists.archlinux.org Message-ID: Content-Type: text/plain; charset=US-ASCII; format=flowed Thanks Christopher. It's done. Best wishes, Jeanette Apr 9 2023, Christopher Arndt has written: > Am 09.04.23 um 13:58 schrieb Jeanette C.: >> I try to clean up my system and wanted to uninstall qtractor, which I >> can't do since it supplies dssi-host. Why is this necessary, when the >> dssi package supplies jack-dssi-host? Is there a workaround? > > The 'dssi' package should probably also provide 'dssi-host'. It hasn't been > updated for a while, so the last update probably pre-dates the introduction > of this provides. > > You could report this as a bug via the link on the package's page: > > https://archlinux.org/packages/community/x86_64/dssi/ > > > Chris > -- * Website: http://juliencoder.de - for summer is a state of sound * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g * Audiobombs: https://www.audiobombs.com/users/jeanette_c * GitHub: https://github.com/jeanette-c When you need someone, you just turn around and I will be there

1 0

Problem with packages supplying dssi-host
by Jeanette C. 09 Apr '23

09 Apr '23

Hey hey, I try to clean up my system and wanted to uninstall qtractor, which I can't do since it supplies dssi-host. Why is this necessary, when the dssi package supplies jack-dssi-host? Is there a workaround? Thanks and best wishes, Jeanette -- * Website: http://juliencoder.de - for summer is a state of sound * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g * Audiobombs: https://www.audiobombs.com/users/jeanette_c * GitHub: https://github.com/jeanette-c When you need someone, you just turn around and I will be there <3 (Britney Spears)

2 2

Tracking album 3
by Ben Bennett 25 Mar '23

25 Mar '23

Hey everyone, not sure how this email list works, but what the hell, I want to share this. Im the bassist of a metal band called Xoth. We are currently in pre-production, and im doing all of my bass tracks in Reaper on my Arch/i3 setup. I accidentally nuked my mac that I had used for the first two albums. I was a Logic Pro loyalist, but started getting sick of all the "bugs" that would occur. Like, not letting me practice over a track unless I had a midi instrument selected and armed to record. Anyways, so far so good. Its hella fast and Im having a good time recording in my rice. I'm just sending this out there to say hello and see if anyone has any tips for mixing with windows plugins. Any help or wisdom would be awesome. Thanks for reading this, check out my band if youre into this type of thing. Maybe I know some of you already! https://xoth.bandcamp.com/album/interdimensional-invocations - Ben

3 3

Strange audio artifacts with BOSS GT-1000CORE
by Mark Raynsford 14 Jan '23

14 Jan '23

Hello! I recently obtained a BOSS GT-1000CORE [0]. It has the capability to act as a 6-in/6-out USB audio interface. Thankfully, Linux seems to detect it correctly without any configuration, and I see all of the inputs and outputs that I'd expect in Pipewire: https://ataxia.io7m.com/2023/01/14/pipe.png Unfortunately, there seems to be some kind of odd distortion. This is a capture of a raw DI signal from the BOSS: https://ataxia.io7m.com/2023/01/14/noiseissue.flac There's something odd happening in the high frequency range. It almost sounds a bit like some kind of resampling artifact. The same distortion is not present if I plug headphones directly into the BOSS, so the distortion itself evidently isn't happening on the actual device (or coming out of the guitar pickups!). Does anyone know what could be causing this and/or how I could track it down? $ uname -a Linux sunflower.int.arc7.info 6.1.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 21 Dec 2022 22:27:55 +0000 x86_64 GNU/Linux [0] https://www.boss.info/uk/products/gt-1000/ -- Mark Raynsford | https://www.io7m.com

2 3

Re: Realtime kernels are now in the official repositories
by Susanne Schneider 10 Nov '22

10 Nov '22

hi David, many thanks for this! best -suse > Message: 1 > Date: Sat, 5 Nov 2022 16:20:57 +0100 > From: David Runge <dave(a)sleepmap.de> > Subject: Realtime kernels are now in the official repositories > To: Arch Linux pro-audio <arch-proaudio(a)lists.archlinux.org> > Message-ID: <Y2Z/XCIxj6cGiyl/@hmbx> > Content-Type: multipart/signed; micalg=pgp-sha512; > protocol="application/pgp-signature"; boundary="T8ODkL4cH6ueY56d" > > Hi all, > > a heads up to anyone using the realtime kernel packages (linux-rt and > linux-rt-lts) from my custom repository [1][2]. > > I have moved both to the [extra] repository today [3] and the custom > repository will be removed on 2023-01-01. > Please make sure to remove it from your /etc/pacman.conf and upgrade > your system! > > Best, > David > > [1] https://wiki.archlinux.org/title/Unofficial_user_repositories#realtime > [2] https://pkgbuild.com/~dvzrv/repos/realtime/x86_64/ > [3] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… >

2 1

Realtime kernels are now in the official repositories
by David Runge 05 Nov '22

05 Nov '22

Hi all, a heads up to anyone using the realtime kernel packages (linux-rt and linux-rt-lts) from my custom repository [1][2]. I have moved both to the [extra] repository today [3] and the custom repository will be removed on 2023-01-01. Please make sure to remove it from your /etc/pacman.conf and upgrade your system! Best, David [1] https://wiki.archlinux.org/title/Unofficial_user_repositories#realtime [2] https://pkgbuild.com/~dvzrv/repos/realtime/x86_64/ [3] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… -- https://sleepmap.de

1 0

Thinking about a shared location for JSFX packages?
by Jean-Michaël Celerier 12 Jul '22

12 Jul '22

Hello, Thanks to the open-source work of jpcima, there's now an easy way for hosts to add support to Reaper's JSFX plug-ins: https://github.com/jpcima/ysfx (package: ysfx-git) I've already added support in https://ossia.io and it's pretty fun - most likely other DAWs are going to add support over time. This makes me think that it would start to make sense about a standard folder of where to install JSFX effects, a bit like /usr/lib/vst, /usr/lib/lv2, etc. so that the users can install effects through package management (I'll try to add a few free packs that are on github), and all hosts can all scan them automatically. How about /usr/share/jsfx/<jsfx package>/ ? I'm not sure if share or lib is better for this as those aren't compiled shared objects, but scripts in the JSFX language. Cheers, Jean-Michaël ------------------------------ Jean-Michaël Celerier *cto* ossia.io | *consulting inquiries* celtera.dev | *personal* jcelerier.name t: +336 81 31 53 08

1 0