Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1939749 - portaudio detects JACK devices as having 0 channels in/out if they have regex tokens in their name
Summary: portaudio detects JACK devices as having 0 channels in/out if they have regex...
Alias: None
Product: Fedora
Classification: Fedora
Component: portaudio
Version: 33
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Hans de Goede
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2021-03-16 23:39 UTC by Be
Modified: 2021-03-30 00:15 UTC (History)
4 users (show)

Fixed In Version: portaudio-19-34.fc35 portaudio-19-34.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-03-22 17:29:07 UTC
Type: Bug

Attachments (Terms of Use)
patch to fix the bug in portaudio (10.34 KB, application/mbox)
2021-03-16 23:39 UTC, Be
no flags Details

Description Be 2021-03-16 23:39:44 UTC
Created attachment 1763857 [details]
patch to fix the bug in portaudio

Description of problem:
PortAudio detects JACK devices as having 0 channels in/out if they have regex tokens in their name. It was uncommon to encounter this situation before because jackd simply calls the audio interface "system". However PipeWire uses the device name from ALSA for the JACK port names. If this contains any special regex characters, PortAudio's BuildDeviceList function would find the device but determine it has 0 input channels and 0 output channels. In my case, I have an RME Babyface Pro which puts its serial number in parentheses:

$ aplay -l
card 0: Pro70785713 [Babyface Pro (70785713)], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

PipeWire may also insert additional regex tokens in the strings it uses for JACK device names, which sometimes include parentheses.

Version-Release number of selected component (if applicable):

How reproducible:
every time

Steps to Reproduce:
1. Install and run PipeWire
2. Connect an audio interface with a regex token (any of \()[]{}*+?|$^. ) in its name, or a device for which PipeWire puts parentheses in its JACK device name
3. Use a PortAudio application such as Mixxx or Audacity with the JACK PortAudio backend

Actual results:
The PortAudio application cannot use the audio device because it detects 0 channels for input and output.

Expected results:
The PortAudio application can use the audio device through PipeWire's reimplementation of the JACK API.

Additional info:
I opened a pull request upstream to fix this:
However the PortAudio maintainers have repeatedly refused to include this patch in their upcoming release which will be the first release in years. They are refusing to give any specific reason why they are not merging the patch now, despite numerous downstream developers and end users emphasizing how important it is to merge this patch so PipeWire works when it is turned on by default in Fedora 34.

Comment 1 Be 2021-03-16 23:52:13 UTC
One of the PortAudio maintainers just posted to the mailing list saying this patch may be included in their upcoming release. If so, I think updating to the new upstream release would be better than carrying this patch in Fedora.

Comment 2 Be 2021-03-19 18:38:54 UTC
The bug fix was merged and the PortAudio maintainers have made another release candidate. The only remaining questions before they make the 19.7 release are on Windows.

Comment 3 Be 2021-03-19 18:51:11 UTC
Is there a chance to get an updated PortAudio package into Fedora 34 stable before the final freeze on April 6?

Comment 4 Hans de Goede 2021-03-19 19:33:42 UTC
(In reply to Be from comment #3)
> Is there a chance to get an updated PortAudio package into Fedora 34 stable
> before the final freeze on April 6?

I'll take care of getting either the fix added to the existing packages, or updating to the release-candidate sometime during the coming week.

Comment 5 Be 2021-03-19 19:36:29 UTC
Great, thank you. I will post here as soon as the final PortAudio 19.7 release is published.

Comment 6 Hans de Goede 2021-03-22 15:52:45 UTC
So our current portaudio is quite old, it is based on the pa_stable_v19_20140130.tgz tarbal, which is ancient.

Also we have a patch which adds some extra API which audacity needs which does not apply cleanly to the latest release (I did not check to see how much work porting it is).

So all in all, also given that we are already post beta, I believe that for Fedora 34 it would be better to just add the patch necessary for this and otherwise stick with the old version.

So I'm preparing a portaudio-19-34 update doing that now.


It would be nice if we can upgrade to a later upstream version in rawhide, but I don't really have any time to work on portaudio. So a pull-req at with a (tested please) update would be very much welcome.

Or if you are already a Fedora packager I would definitely welcome a co-maintainer for portaudio.

Comment 7 Hans de Goede 2021-03-22 17:26:14 UTC
BTW for the patch I used the cleanup version which was merged upstream instead of the original patch attached here.

Comment 8 Fedora Update System 2021-03-22 17:29:07 UTC
FEDORA-2021-82a2775129 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 9 Be 2021-03-22 18:16:25 UTC
Thank you. I think that is a reasonable decision for Fedora 34. I don't think it should be your responsibility to send the patches Audacity needs upstream to PortAudio. I suggest contacting the Audacity maintainers and encouraging them to open a pull request for upstream PortAudio. If their changes get integrated into the subsequent PortAudio 19.8 release, then Fedora could drop the patches and just use upstream PortAudio.

I am not a Fedora package maintainer already, but one of the other Mixxx maintainers is a maintainer for the mixxx RPM Fusion package so he might be interested in helping with the Fedora portaudio package.

Comment 10 Be 2021-03-22 18:24:11 UTC
Looking at the portaudio patch for Audacity I'm wondering if it's really needed. It adds two extensions to the PortAudio OSS backend. Does anyone actually use OSS on Linux anymore? IIUC it is still used on BSD but that's not relevant for Fedora.

Comment 11 Uwe Klotz 2021-03-22 19:33:49 UTC
Hi all. By overhauling and now maintaining our RPM Fusion package I gained some experience on how to package for Fedora. Though I am not considering myself an expert in the field and I haven't contributed to the main repos yet.

Aligning the package with the current upstream version would definitely be a desirable objective. Good to know that pull requests aiming in this direction are welcome.

Comment 12 Fedora Update System 2021-03-22 21:58:15 UTC
FEDORA-2021-6e4c2901ae has been submitted as an update to Fedora 34.

Comment 13 Hans de Goede 2021-03-22 22:00:02 UTC
Uwe, if you can provide a pull-req to get portaudio rebased to a newer version that would be great, thanks.

I'll also send an email to the Fedora devel list that the portaudio pkg could use a new maintainer or a co-maintainer. I'll put you and Be in the Bcc of the email.

Comment 14 Fedora Update System 2021-03-23 02:01:50 UTC
FEDORA-2021-6e4c2901ae has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-6e4c2901ae`
You can provide feedback for this update here:

See also for more information on how to test updates.

Comment 15 Fedora Update System 2021-03-30 00:15:55 UTC
FEDORA-2021-6e4c2901ae has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.