Hi all,
As Fedora 34 try to use PipeWire by default to replace PulseAudio (https://fedoraproject.org/wiki/Changes/DefaultPipeWire), I think Ubuntu should consider the switch also. I wanted to try pipewire (0.3.15) on Ubuntu 21.04 (dev) without luck, because all documentation is for Fedora, and I can’t make it default, btw there’s a newer package (0.3.18) from pipewire. Can somebody help me how can I try it on Ubuntu? What are the necessary steps?
Marked of ‘Low Importance’. I do hope Ubuntu gets serious about Wayland, soon.
Sounds like the desktop team has no choice soon: “GNOME Shell will start depending on it in the next release and this is what is going to pull it in main.” (https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/1802533/comments/30)
Wayland has no way of doing color management. It would be crazy to move to it while that’s not done. Basically it would mean that anyone doing any graphics, video or vfx work would have to move to another distro.
I’d rather hope that Canonical gets involved there to move things faster because they don’t know what they are doing at all and are learning as they go. None of them are color management experts, most of them haven’t ever made an icc profile.
Just look at this thread:
https://discuss.pixls.us/t/wayland-color-management/10804/509
I would like to propose, if i may, that Canonical contacts and gives backing to Graeme W. Gill, the developer of Argyll CMS to make and propose a proper spec and to develop the implementation. He is pretty much the only color management expert who happens to be a developer and who happens to be into Linux. And is Argyll CMS is pretty much the only color management system that we have on Linux today thanks to him.
Let us not adopt something half baked. This has to be solved first.
Basic LUTs are good enough for MOST people using GNU/Linux — and quite frankly there aren’t many pros using Linux for Colour Correction. Linux is mostly used in Render Farms, right? So it’s an edge case and I wouldn’t want this to hold up XWayland/Wayland adoption. Most people doing colour correction these days are on MacOS using Adobe Products.
Pros aren’t using Linux for color correction. They do work that requires color correctness. For example all VFX industry, a portion of movie industry, web design, app design. Do you remember when designers of Adwaita told us it was grey but we could see it was purple? Well, they were early adopters of Wayland and there you go.
If this is not done properly it will impact a lot of people jobs.
Snap, deb, rpm etc numbers are not public, but Gimp Flatpak was downloaded over quarter of a million times.
All of those people need color management.
Add to those all the Blender, Inkscape, Darktable, Rawtherapee, Scribus users etc.
That’s only the FOSS software. How about you pay 9k USD for Nuke license and then find out that Wayland doesn’t have a proper color management. Or how about Houdini, DaVinci Resolve, BorisFX users?
What about the game developers? Unreal, Unity, Godot, CRYENGINE?
People and companies are taking the effort to bring their software to Linux to take advantage of it. Is Wayland going to drive them all away and bring us to square 0?
Countless hours volunteered and paid are being pored into the development of software for Linux for which color management is a critical component. It needs to be done and it needs to be done properly before mass adoption period.
Color management in Wayland has to be at least at the MacOS level before mass adoption. Otherwise it’s better for X to stay and we just skip Wayland because color management will get implemented in Wayland one way or another but if it’s not specd out properly now then it will be hacked later when devs realize they’ve messed up. I don’t like the current Wayland one bit atm. Devs are learning as they go and are refusing to listen to experts in the field which is such a shame because they won’t pay the price, users will.
I’m using Wayland and familiar with LUTs and colour correction having done colour reprodo professionally before retirement. I see no issues, but then I’m not doing professional work. Wouldn’t profiling the monitor be satisfactory? That’s all I would do if I was going to go back to work doing reproduction. If I correct images for white/greyscale they look good on other monitors using other OSes. And I haven’t even profiled my monitor with hardware!
No
Author: Graeme W. Gill
Date: 7th December 2020
Version: 1.0
This is general, but is writen in the context of adding modern color management
to the Wayland protocol.
R. Requirement
J. Justification/explanation
P. Priority
S. Current status within desktop application programming environments:
M = Supported by Microsoft Windows
A = Supported by Apple OS X
X = Supported by X11 based systems.
R: Applications need to know display pixels colorspace, and
be able to do color transforms into this colorspace for
display on that display device.
Practically this means reference and access to an ICC profile
that defines the colorspace of each display/pixel.
P: Mandatory
X: Some key applications deal with a wide range of source colorspaces,
and their core job is to accurately render these for display.
Sources are as diverse as other RGB colorspaces, CMYK and
higher number of colorant print spaces, named colors, device independent
color specifications, etc. Sources are not necessarily defined by ICC profiles.
(See for instance how PostScript, PDF and XPS allow colors to be defined.)
Accuracy of processing and correct gamut limitation/mapping handling
is only possible with a direct conversion between the native
source colorspace and the display colorspace. Existing application
code assumes this capability is available, and these complex applications
are not trivial to re-write or re-target.
S: M, A, X
R: Applications need to be able to upload & set the profile
that defines a displays colorspace.
P: Mandatory
X: Without this only the grossest problems of non-color managed displays
can be dealt with. Manufacturer supplied profiles are at best generic,
and often misleading when derived from (say) EDID information.
Color sensitive uses of computer systems require calibration and profiling
their specific display in a state of specific adjustment, and
require verification and re-calibration/profiling on a regular basis.
Applications used for calibration and profiling are normal applications
that expect to target the same devlopment environment and API’s as
any other color managed application to be able to do their job.
Like other complex and highly technical applications they are not trivial
to create, maintain or port to new environments.
S: M, A, X
R: System wide default color management. There should be a default source
colorspace that the system will color convert to the display colorspace
if the application doesn’t want to handle the color conversion itself.
P: Desirable
X: Many application writers do not have the necessary knowledge
to deal with color management, and the extra complexity needed
in rendering with color management cannot be justified for many
applications. This capability also allows for applications to work
sucessfully in the face of unanticipated changes in display
characteristics such as wide gamut, HDR etc.
S: A
R: System will honour defacto standard display calibration curves included
in display ICC profiles. Maximum HW precision will be used.
P: Mandatory
X: Although some displays have a capability of setting white point
and brightness progromatically, this is not true for all displays
and is not published, standardized or available via a standard API.
Using graphic card 1D LUTs allows universal and standardized setting of
these key display characteristics, and this is assumed by most
existing display ICC profiles and color management tools.
Additionally it is typicall that frame buffers have a more limited
resolution that the final output of graphics cards/display adapters
(i.e. 8 bit per component frame buffers typically have 10 bit outputs
after 1D lookup tables, 10 bit frame buffers have 12/14 bit 1D LUTs etc.),
and it is desirable to use this to ensure that the more limited precision
of the frame buffer is fully utilized by using the higher precision of
the 1D LUTs to perceptually even the quantization steps out.
S: M, A, X
R: Application is able to set and get display calibration curves
P: Mandatory
X: Display calibration and verification support. See explanation above in 2).
S: M, A, X
R: Application is able to display a rectangular window of pixels
on a chosen display and set un-managed pixel values.
P: Mandatory
X: Display calibration and profiling support. See explanation above in 2).
S: M, A, X
R: Commonly used profiles be readily available to applications
P: Desirable
X: Ties in with 3), as profiles are neede by the system for implementation,
and this allows an application to determine what default system color management
is actually doing.
S: none
R: Support for easy intermixing HDR and SDR displays. This means supplementing
the display and source spaces profile information with HDR profile and handling
details.
P: Highly desirable
X: ICC profiles don’t have complete enough information to convenienly specify
HDR <-> SDR transformations.
S: none
R: Support global display modifications within the color managed context
for the purposes of applications such as “blue shift” or equivalent.
P: Desirable
X: People use and enjoy such application, and these typically rely on the
availablility of per channel lookp curves in the graphics hardware to do
crude global display modifications. A way of accomodating this while working
harmonously with color management is desirable.
S: A
How did the conversation shifted from pipewire to Wayland’s CM problems? 
Pipewire is not just about Wayland. It’s the way GNOME will use to provide screencast/grab/sharing on every session, but it’s actually more.
It’s also about audio: a more customizable and efficient alternative to pulseaudio.
About video streams and sandboxed app. The way I understand it is: now a sandboxed version of Zoom to access the camera needs access to /dev/videoN and so this app will be granted access to /dev and this will hinder most of the sandboxing motivation. While, using pipewire, xdg-portal and xdg-app, the GNOME/Red Hat goals are to allow the app to access a pipewire stream after the user agreed. I might be wrong but this is my understanding of what the plan is.
Moreover, when proper pipewire session managers exists, we might have virtual webcam in userspace without using kernel stuff like v4l2-loopback.
I’m all for PipeWire. I can’t wait for it to be the default in Ubuntu, after proper testing that is but I hear people saying it’s very stable already.
I’m very interested about PipeWire as a modern replace for PulseAudio. Should we document some way to install and test to verify if PipeWire can replace PulseAudio in +1 release?
Yes please, that would be a great idea 
Will it be available in the main?
I was thinking we might have to switch from PulseAudio to PipeWire in future because only PipeWire had landed support for modern higher quality Bluetooth audio. But a quick check seems to suggest PulseAudio is catching up. Maybe expect to see it in PulseAudio v15?
I like how PipeWire replaces both PulseAudio and Jack and would allow for much better experience with audio applications like Ardour. Currently if you have Ardour opened it takes the audio server and you can’t play any sound from any other app while it’s running even if it’s not playing any sound.
PipeWire solves that issue so it might be worth considering it.
That’s one of the reasons for sound servers like PulseAudio existing. If you still have any apps taking over the audio hardware then report a bug. They need to be compiled with PulseAudio support instead of accessing ALSA directly.
You’d have terrible latency issues with PulseAudio on the apps like Ardour. So it was really just alsa or jack for them. But now PipeWire caters to both the PulseAudio and Jack use cases so yeeee!
Low latency audio out of the box is what I’m hoping for
I know some people even do low latency kernels but hey, can’t win them all at one time 
Low latency kernels are not lower latency for everything, so you should do your own testing. For example, when working on measuring graphics latency a few years ago I found ‘low-latency’ kernels actually gave higher latency in those tests.
I use the Ubuntu kernel. I’ve found Ardour works great on alsa and Jack. It’s just that with PipeWire it should be perfect out of the box. No alsa take over and no messing (or messing up) with Jack and all of that. I may like tinkering very much but in the end I just wanna do my work without being bothered by stuff like this
Funny enough I get a huge latency problem if I install AMDGPU-PRO and I have no idea what’s up with that. But that’s a different issue, I’m just saying for anyone who might be reading and wondering why they have latency issues and this might be it.
Hopefully, that MR has been delayed by an avalanche of drama on what’s otherwise sorely needed. My bluetooth headset doesn’t work right when the mike is in use to the point I’m having to use the laptop’s mike instead.