pw-jack

[GMaq]

I've been wondering why we need pavucontrol to set profile in PW too. From a post at reddit this was suggested:

Put something like:

Code: Select all

monitor.alsa.rules = [
  {
    matches = [
      {
        node.name = "YOUR_DEVICE_NAME_AS_SHOWN_BY_'wpctl status'"
      }
    ]
    actions = {
      update-props = {
        device.profile = "pro-audio"
      }
    }
  }
]

in

~/.config/wireplumber/wireplumber.conf.d/51-set-profile.conf

I can't test it as I don't have a "Pro Audio" sound card.
Note also from Pipewire FAQ section on the Pro Audio profile:

This profile is meant to be used on audio cards with:

Code: Select all

More than 8 channels for input or output. Channel assignment is probably wrong for these cards.
Cards with many instruments connected to each input. It makes sense to handle each channel as a separate unrelated stream.
Output Cards with many unrelated outputs, like speakers on the first 2 channels, headphones on the second channel-pair, additional speakers on the other channels.

For consumer cards with stereo or surround configurations, it does not make sense to use this Profile.

That does work, that's essentially what I did before I read that you can simply select it in pavucontrol.. AV Linux comes with a lua_example.txt file pre-populated in ~/.config/wireplumber/ just in case:

Code: Select all

#Setting up a device not recognized correctly for the PipeWire "Pro Audio" profile.

1. Get your Device ID from 'wpctl status' (Focusrite Clarett used as example).

$ wpctl status
Audio
 ├─ Devices:
 │     107. Clarett+ 2Pre                       [alsa]

2. Get your ALSA Device name.

$ wpctl inspect 107 | grep device.name
  * device.name = "alsa_card.usb-Focusrite_Clarett__2Pre_00004281-00"

3. In this folder create a text file called "51-my-alsa-config.lua" with this content and place your ALSA Device name where indicated.

table.insert(alsa_monitor.rules, {
	matches = {
		-- ORed
		{
			{ "device.name", "matches", "< Place ALSA Device name here between quotes>" },
		},
	},
	apply_properties = {
		["device.profile"] = "pro-audio",
	},
})

[Impostor]

But this thread demonstrates that on a huge mainstream Distro even someone well versed with Pro Audio work can be stymied pretty quickly by the incomplete state that PipeWire arrives in.

Yeah, I find it on par with the 'hassle' of setting up Jack+Pulse for pro-audio. Including obsolesence of online info (maybe pw is even worse in this regard somehow, being still a w.i.p.).

But I don't mind some tinkering..

[Impostor]

If you have a multi-i/o interface your next hurdle will be to assign a "Pro Audio" profile to it with PulseAudio Volume Control so it is not seen as a surround device.. :wink:

Does doing that have any additional benefits (for my onboard audio chip) apart from channel grouping?

Edit: I guess @sunrat already answered that in the negative.

[GMaq]

If you have a multi-i/o interface your next hurdle will be to assign a "Pro Audio" profile to it with PulseAudio Volume Control so it is not seen as a surround device..

Does doing that have any additional benefits (for my onboard audio chip) apart from channel grouping?

I very well could be wrong but I vaguely recall that also kicks in IRQ scheduling for the Pro Audio device.. But the effectiveness probably depends on the presence of rtirq-init and the 'threadirqs' boot parameter. If anyone knows more about this, please share..

*From the 0.3.81 release notes:

!RQ based scheduling in ALSA was improved and enabled by default for
Pro-Audio profile. It will also link the pcms together to get lower
latency. This now matches what JACK does and results in equal latency
for Pro-Audio profiles.

[novalix]

Yeah, I find it on par with the 'hassle' of setting up Jack+Pulse for pro-audio. Including obsolesence of online info (maybe pw is even worse in this regard somehow, being still a w.i.p.).

As you can see in the neighbouring thread.

[Audiojunkie]

Lol,

You're giving me a deja-vu... I had to do all that stuff for AV Linux plus add a custom metadata tool, PipeWire is a pretty abrupt stop to use for Pro Audio, many big mainstream Distros have no idea what's needed...

If you have a multi-i/o interface your next hurdle will be to assign a "Pro Audio" profile to it with PulseAudio Volume Control so it is not seen as a surround device..

I guess I've been lucky in a way.... Fedora has been my distro of choice for quite a while, and since they (Red Hat developers) pretty much invented Pipewire, everything is implemented correctly in the OS. It will take time, but I'm confident that the other distros will get things correct and configured properly by default.

Personally, once configured, all I have to do to start an app is click on its launcher icon.

[Audiojunkie]

If you have a multi-i/o interface your next hurdle will be to assign a "Pro Audio" profile to it with PulseAudio Volume Control so it is not seen as a surround device..

Does doing that have any additional benefits (for my onboard audio chip) apart from channel grouping?

I very well could be wrong but I vaguely recall that also kicks in IRQ scheduling for the Pro Audio device.. But the effectiveness probably depends on the presence of rtirq-init and the 'threadirqs' boot parameter. If anyone knows more about this, please share..

*From the 0.3.81 release notes:

!RQ based scheduling in ALSA was improved and enabled by default for
Pro-Audio profile. It will also link the pcms together to get lower
latency. This now matches what JACK does and results in equal latency
for Pro-Audio profiles.

You are correct.

[Impostor]

In principle, I'm getting the same performance as with Jack now, sort of, afaicd.

One big issue for me is that Jack Transport doesn't work correctly yet. Tempo syncing seems to work ok, but it specifically goes haywire with playhead relocations in the transport master.

I guess this deserves a new thread.
viewtopic.php?t=27480

[Impostor]

I've copied jack.conf and pipewire.conf from /usr/share/pipewire/ to ~/.config/pipewire/

and edited/added/uncommented these in jack.conf:

Code: Select all

node.lock-quantum  = true
node.force-quantum = 256
node.force-rate    = 1/48000

Quantum size 256 coincides with Jack's 128/2 buffer I presume?

and these in pipewire.conf:

Code: Select all

default.clock.allowed-rates = [ 44100 48000 ]
default.clock.quantum       = 1024

since I don't need firefox' or audacious' audio resampled to 48000 Hz, and latency is irrelevant *).

I guess that's all the necessary configuration for now.

*)On the other hand, I prefer using a mixer like jack_mixer to put all audio through, before sending it to the output. Since jack_mixer is a jack application, and must mix 44100 and 48000 Hz, I guess it will upsample all 44100 signals anyway.

Anyone know of a pipewire mixer equivalent to jack-mixer?

[sunrat]

If you have a multi-i/o interface your next hurdle will be to assign a "Pro Audio" profile to it with PulseAudio Volume Control so it is not seen as a surround device..

Does doing that have any additional benefits (for my onboard audio chip) apart from channel grouping?

Edit: I guess @sunrat already answered that in the negative.

There's a topic in which I explained my hassle with Pro Audio profile - Mixbus10/Pipewire freeze after export
Basically my M-Audio 2496 card uses Envy 24 chip which has 10 channels but only 2 active which caused Ardour/Mixbus to freeze after export using Pro Audio, but not with Analog Duplex. I can't test if Pro Audio would work with a 2 channel chip.

[glowrak guy]

When a handfull of coders attempt corporate level projects, in ever-changing beta-level distros, it's going to be rife with omissions, quirks, issues, blunders, and the 'ease of use' factor will insure that linux musicians will be counted by hundreds, rather than millions, for the foreseeable future.

I uninstall every bit of pipewire that a package-manager will allow, and GMaq's pajackconnect, and Rui's qjackctl are all I need for full hardware/software connectivity, and trouble free recording/mixing/mastering.

I know nothing (shout out to Sergeant Schulz) about pipewire and NLE video in linux, a topic that might be worth hosting here, seeing that audio and video are often joined at the hip, several linux editors exist, and linux Reaper has some video capability etc etc
Mi dos centavos

[glowrak guy]

As to "corporate level projects"...I've been in a room in a huge corporate campus, of a software house little-known to the average man-on-the-street, that had three huge wipe-boards, several large tables, dozens of chairs, and bewildering code yet to be wiped, in some cases. There were dozens of such rooms in mulltiple three story buildings, and a sprawling parking lot teaming with commuting coders working different shifts.

Rather than biting off more than they can chew, they apply the assets needed for efficient success. While consumer linux is in a very different realm, it's still important to avoid early adaptation of things unsuited for the primary tasks. If someone wants to see linux grow as a platform, it's important to keep things simple and effective. Someone new to computer-based media production, or from a win/mac background, reading this topic, will likely reconsider their interest. Happily, there are great coders in linux, who wisely avoid attempting too much too soon, and still release regular updates and new tools that work out of the box. etc.

[RyanH]

As to "corporate level projects"...I've been in a room in a huge corporate campus, of a software house little-known to the average man-on-the-street, that had three huge wipe-boards, several large tables, dozens of chairs, and bewildering code yet to be wiped, in some cases. There were dozens of such rooms in mulltiple three story buildings, and a sprawling parking lot teaming with commuting coders working different shifts.

Rather than biting off more than they can chew, they apply the assets needed for efficient success. While consumer linux is in a very different realm, it's still important to avoid early adaptation of things unsuited for the primary tasks. If someone wants to see linux grow as a platform, it's important to keep things simple and effective. Someone new to computer-based media production, or from a win/mac background, reading this topic, will likely reconsider their interest. Happily, there are great coders in linux, who wisely avoid attempting too much too soon, and still release regular updates and new tools that work out of the box. etc.

I'm not new to computer-based media production and have been using Linux for that purpose for nearly a decade, and this thread makes me want to cry. I just want to be able to use my stuff as I have been.

[Largos]

I will never understand why people who don't use something, don't know anything about it and don't want to do either feel the need to talk FUD about it.

[Impostor]

I will never understand why people who don't use something, don't know anything about it and don't want to do either feel the need to talk FUD about it.

I do kind of understand his point though. Unifying consumer audio, pro audio, and video streaming into a single framework seems a massive undertaking. And now that more and more distro's ship pipewire o.o.t.b., the issue reports will likely skyrocket. It may take a large team of devs/contributors to keep up with all that. I don't know if the pipewire team is financially compensated by the major distro's for their work, but I certainly hope so!