You may remember the Pipewire coverage we ran a couple weeks ago, and the TODO item to fix up Firewire device support with Pipewire. It turns out that this is an important feature for kernel hackers, too, because the Alsa changes just got pulled into the 5.14 kernel, and included is the needed Firewire audio work. Shout-out to [Marcan] for pointing out this changeset. Yes, that’s the same as [Hector Martin], the hacker bringing Linux to the M1, who also discovered M1racles. We’ve covered some of his work before.
It turns out that some Firewire audio devices expect timing information in the delivery stream to match the proper playback time for the audio contained in the stream. A naive driver ends up sending packets of sound to the Firewire device that wanted to be played before the packet arrives. No wonder the devices didn’t work correctly. I’m running a 5.14 development kernel, and so far my Focusrite Saffire Pro40 has been running marvelously, where previous kernels quickly turned its audio into a crackling mess.
There is another fix that’s notable for Pipewire users, a reduction in latency for USB audio devices. That one turned out to be not-quite-correct, leading to a hang in the kernel on Torvald’s machine. It’s been reverted until the problem can be corrected, but hopefully this one will land for 5.14 as well. (Edit: The patch was cleaned up, and has been pulled for 5.14. Via Phoronix.) Let us know if you’d like to see more kernel development updates!
Very good comments, especially for me who works with a Firewire interface… Keep us posted. Thanks!
Agreed. I don’t mind reading some Linux articles on HAD. Really interesting updates on the audio subsystem.
Why is MacOS so far ahead? Don’t they merge in improvements into the kernel?
MacOS is based on BSD unix; not on Linux. Therefore:
1: Apple is under no obligation to merge anything back into the parent OS (BSD Unix).
2: Kernel improvements in MacOS or BSD are extremely unlikely to work in a Linux kernel.
MacOS isn’t really even BSD but rather something that is a couple of major forks removed from BSD. https://en.wikipedia.org/wiki/XNU
If you want a general purpose Unix or Linux computer run Unix or Linux. If you want an expensive appliance get a Mac.
My “expensive appliance” runs macOS, windows and Linux all at the same time if I want.
I don’t have to grumble about systemd or pulseaudio or Wayland not working right. I don’t have to try five different Linux distributions on my computer to find the one that actually supports it. I don’t have to hunt down obscure patches to get VMware to work. I don’t have to install a bunch of obsolete crap just to turn the caps lock into control. I don’t have to suffer with a crappy video card (have you shopped for video cards lately?) Yes I just built up a new Linux box and what a time sink it was.
All this stuff makes Linux machines very expensive in terms of my time.
Oh please. We all know that Apple is going to lock down OSX to only allow installations from their app store soon just like all their pocket sized appliance OS. And most users won’t care b/c the only thing they know to do with their Mac anyway is run whatever they traded their right-kidney to Adobe for. (The left one went to Apple)
Why would you want to use Wayland? Oh.. you like appliances right.. I suppose Wayland is a good choice for you then. I prefer having remote display and compose key support.
Speaking of compose key it’s just a simple line in an /etc/X11/xorg.conf file to change which key it is. I suppose you could probably change your control key the same way but why would you?
Oh that’s right, Macs have funky keyboards that don’t match the standards the rest of the world agreed on decades ago.
So what buttons do you remap to get right-click, middle click and a scrollwheel on a single button Mac mouse?
Did you really spend a bunch of time trying to get vmware going? Is that hard now? I wouldn’t know, haven’t used it in years. It’s too easy to just type “emerge virtualbox” and have all my virtualization needs taken care of, no fuss.
Well, maybe your time isn’t worth very much if you’re using so much of it to figure out how to perform these very mundane and simple tasks?
All these arguments from newbies about how hard it is to do something in Linux are so cliche. Here’s a Mac OS one I spun off the top of my head based off a job that required me to use Mac:
“I’ve had to re-familiarize myself with Mac OS X for a job the last couple years and I’ve gotta say–what a pain in the tookus! The OS doesn’t even come with a usable package manager to install mundane and simple programs. Want to avoid repeatedly spending multiple whole seconds dragging windows across the screen with a *mouse*? Get ready to grant accessibility permissions and open that security tab in system preferences! Oh *that* binary package doesn’t work on *this* version of Mac OS?”
Learning Linux will both increase the value of your time and allow you to avoid spending money on expensive appliances since it can run on most commodity (and not) hardware.
Though the caveat always is, if you simply don’t like learning new things then I’m just trying to talk to a wall.
“. We all know that Apple is going to lock down OSX to only allow installations from their app store soon just like all their pocket sized appliance OS.”
What’s this “we” business, paleface? Do you really think they are going to shut out node.js and rust development? Stop you from porting gcc? macOS is a software development platform. If they did what you say then software development would not be possible.
“Speaking of compose key it’s just a simple line in an /etc/X11/xorg.conf file to change which key it is. ”
No, not when Wayland is running.
“Why would you want to use Wayland?”
Because I write code for a living and I need to run what my customers run. They want Ubuntu. It’s not my choice but there it is. At least I don’t have to deal with Solaris anymore.
“So what buttons do you remap to get right-click, middle click and a scrollwheel on a single button Mac mouse?”
I plug in a mouse with those features and they all work great. Middle button works in macOS just as it does in x windows.
Yeah so I’ve got this AMD Ryzen motherboard and Linux doesn’t support most of the sensors on it, even with the latest kernel, so I have screaming fans and no way to turn them down. RHEL doesn’t support its ECC RAM, you need a really new kernel for that. RHEL also doesn’t play nice with my PCIe SS drives, only Ubuntu 20.04 and fedora will work with them. Linux is usually great but setting up a new machine is always a challenge.
“so I’ve got this AMD Ryzen motherboard and Linux doesn’t support most of the sensors on it, ”
MacOS does?
*Your mileage may vary
You can put yourself in situations that are less likely to have problems, not running bleeding edge hardware, not running high DPI displays etc. Apple devices can also have issues, how often are you told to hold off from the latest mac OS version while it gets patched or while software support catches up? How often does your mac crash when using thunderbolt devices? Not common but a colleague’s consistently hitting that. How often do you need third party possibly paid software to fix some missing feature like per-app volume controls?
It’s personal preference for sure but I have yet to see an OS that requires absolutely no care and attention from the user.
They don’t use the Linux-kernel, so whatever patches they submit to their own kernel are rather irrelevant; they can’t just be applied as-is to Linux.
They also support less hardware, which means all MacOS has to do is work for a small selection of ‘legal’ setups.
Just like RHEL and its derivatives. Try booting up Rocky Linux on a new AMD box, lots of hardware is just not supported. With Linux you have to run a bleeding edge distribution to run on new hardware.
Very true, though Apple takes it to even greater extremes, dumping old hardware earlier than Linux tends to, and having less supported hardware in the first place.
Which is not at all a dig at Apple – my annoyance with them comes from the massive Apple tax, and some of their other software practices…
I don’t care about old hardware. When it goes off maintenance contract it’s dead to me. I need computers that work reliably.
I am happy to pay the apple tax, it really does pay for itself and there is always good resale value, unlike PC clones that depreciate faster than a rusty car.
I really can’t see how it can ‘pay for itself’, and wouldn’t say Linux or BSD for that matter are any worse for reliable, if anything I’d say they are better even with new hardware – just don’t pick the wrong distro or flavour of that distro, stay just behind the rolling release super cutting edge stuff..
But if Apple does all you need, and you are happy to pay the tax and put up with their other failings it doesn’t bother me you use it, heck If I had the money to spare and any need of thin portable type stuff I might consider an Apple device, despite my loathing for many things they do – still way way better than M$ as an OS provider, and some few things for creatives are still better on Apple – or at least much easier to setup (as less supported hardware means you don’t have to do any setup – it should have the correct defaults 99.99999% of the time).
But I like my portables rugged and cheap – so I use old Toughbooks with Linux, even the elder stateman of my collection with its early core-2-duo still runs really nicely for everything but video, but who needs HD video in the workshop computer, it just needs music to keep you sane and a web browser that works well enough to let you look up whatever you may need..
“Apple takes it to even greater extremes, dumping old hardware earlier than Linux tends to, ”
WTF are you talking about? Apple pushes out firmware updates for machines that are 10+ *YEARS* old. I defy you to name a single PC manufacturer that provides BIOS updates for hardware that old.
Windows 7 wouldn’t install on on hardware from 1999. Windows 10 won’t install on hardware from 2005, yet I had absolutely NO problem installing a fresh copy of Catalina to a brand new SSD from an existing Mojave install. No patching necessary. There’s 10 *YEARS* between hardware release and OS release. Your claims are completely untrue.
“and having less supported hardware in the first place.”
OSX supports 100% of the machines it was intended to run on, plus a plethora of hardware it was not.
“my annoyance with them comes from the massive Apple tax”
Which is a myth, endlessly parroted by people without a clue. I bet you can’t find a feature for feature parallel PC that doesn’t cost as much or more. I’ve done this dozens of times, and not ONE person has been able to come up with anything. They ALWAYS offer up some low rent wannabe that doesn’t come close to matching specs.
It turns out high end hardware costs more than bottom of the barrel plastic clamshell crap.
As pointed out, they are different codebases (so nothing to “merge”), but also… it’s not really ahead.
The Linux kernel regularly beats its Apple counterpart in both computing and IO intensive tasks. That has been the case for at least the last decade.
Hardware compatibility for consumer devices has always been painful in Linux, often because there is not enough market share for vendors to care.
Apple developed a comprehensive audio stack called CoreAudio that’s been in use since OS X 10.3. It’s more than just the kernel code, and everything is designed to work together in a way that linux simply doesn’t have. There was a huge market for pro audio software on classic Mac OS, and Apple had a lot of pressure to get it right.
https://developer.apple.com/library/archive/documentation/MusicAudio/Conceptual/CoreAudioOverview/WhatisCoreAudio/WhatisCoreAudio.html#//apple_ref/doc/uid/TP40003577-CH3-SW1
Linux has a great audio stack (jacks and pulse audio) and Mac os can’t hold a candle to what pro audio is on windows. only Mac fanboys claim that you can do anything audio better on Mac os.
I have heard stupid BS from apple fanboys that latency is supposed to be better, for which there is not factual proof to be found
Being stuck in apple vendor lock-in apps is a really bad move, apple makes you bleed for their hardware, because of course everything they make only works with their own overpriced hardware.that is how they make their record profits on the back of their users.
Jack is great, but PulseAudio is a hot mess of a train wreck. Thankfully Pipewire is set to replace it completely by replacing PA and Jack but still offering their APIs for seamless interoperability.
“Mac os can’t hold a candle to what pro audio is on windows.”
You mean like when Windows gets cranky in the middle of a session and requires a reboot, then FORCES you to apply updates for 40 minutes while your client is getting PISSED that he’s paying hourly? Yeah, *REALLY* “professional”.
“Being stuck in apple vendor lock-in apps is a really bad move”
Wut? What “lock-in”? I can (and DO) run whatever the hell I want, from ANY source I want.
“apple makes you bleed for their hardware”
Riiiiight. Show me a PC with the *EXACT* same or *BETTER* specifications that costs less. $50 says whatever you come up with won’t match up.
“everything they make only works with their own overpriced hardware.”
What does that even mean? Their hardware only works with their hardware? They’re a HARDWARE company. Their products has *better* be interoperable. More than I can say about the endless incompatible crap Microsoft puts out.
I remember a friend calling me for help when he upgraded to Vista, and all his peripherals stopped working. Turns out Microsoft changed the API to their USB stack, and NONE of the manufacturers of his peripherals were releasing updated drivers. His scanner, card reader, and audio interface instantly became JUNK, only being a couple years old.
Then Microsoft did this again, and I got bit by it at work. I had a fleet of about 10 Windows 7 machines, dedicated to running some rather expensive neuroscience recording equipment. then Windows 10 came out, and Microsoft, in their infinite wisdom, kept *FORCING* upgrades on our Windows 7 machines. There was absolutely *NO* way to disable it. You could only defer the upgrade for a week or so.
I played whack-a-mole with these machines endlessly. I’d come in, and Windows 10 would be installed, and I’d have to spend *HOURS* rolling it back. I thought I had finally beat it when I went on vacation.
When I returned, they had *ALL* updated themselves to Windows 10. Worst of all, they weren’t rolled back to 7 within 30 days, so the ability to revert was LOST forever.
Windows 10 came with a new USB stack, which was incompatible with the software to run our equipment. It brought our research to a GRINDING halt for some time. Some researchers chose to scrap perfectly good hardware (at about $15K a pop) and go with what I think is an inferior system. The rest have to suffer with running Windows 7 in a VM on top of Windows 10, which comes with it’s own, endless set of problems. Mainly Windows 10 randomly disconnecting the device from Virtual Box in the middle of recording. The only fix requires rebooting the host system, then booting the VM. Easily wastes 10 minutes EVERY time it happens.
“that is how they make their record profits on the back of their users.”
Actually, Apple made most of it’s money from iTunes sales. Hardware is barely a blip for them, but then again, I wouldn’t expect anyone as misinformed as you to know that.
Interesting…
Thanks again to Marcan, highly recommend his YouTube channel.
Millions of functional, professional quality audio interfaces have been scrapped during the transition away from Firewire. Apple dropped the port, then manufacturers stopped updating drivers.
Meanwhile, the same devices will keep working with reverse-engineered drivers for as long as anyone wants them to.
Wait… they still make Firewire devices?!
A few are still being sold, but there are a bunch of them floating around with really high quality components, still quite capable. Ebay is full of killer Firewire equipment for next-to-nothing. A bunch of studios are still running their firewire stuff, too. If Pipewire is going to tempt pro users, it really has to have good support for that equipment.
This is awesome news! I have a focusrite sapphire pro 14 that I simply had to stop using due to incompatibilites with linux. Hope now it’ll have a place on my desk again.
Nice!
I have a couple of Saffire interfaces (LE and Pro 26, different controller ICs I think), will have to try this out.
IMHO multichannel Thunderbolt interfaces are still too expensive, and AFAIK USB (although I’ve never tried a “prosumer” USB interface, so take this with a grain of salt) is inferior when it comes to achieving proper low roundtrip latency (for some that might not matter, for my use it does). So FireWire support still matters in my world.
By the way, there’s a “low latency performance database” on Gearspace, but it’s Windows only. Something similar for Linux would be amazing, buying an audio interface for Linux is a bit haphazard and/or research intensive.
A DB like that would have to rely on user submissions though (unless some heroic Linux user with access to a vast number of interfaces steps up to the plate, highly unlikely), so not sure how to deal with the practicalities and maintenance required. I don’t think I’m the right person to set it up unfortunately (I have a long track record of unfinished projects…). Will have a think and maybe start on something anyway, just for kicks.
I know such a database has existed in the past, but I don’t think any of them are up-to-date. Actually, that sounds like something that would be great as part of the pipewire wiki: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/home
I was thinking the DB might need it’s own home (or maybe the linuxaudio.org wiki is a good place), as I don’t think it should be pipewire-specific. Actually, some input validation is probably necessary to block spam and incomplete/unhelpful data.
In my mind, to be truly useful it would have to include lots of info (so the results are comparable and repeatable, the devil is in the details in Linux audio).
The hard part is probably going to be building and maintaining a cross-distribution script/program to collect relevant metadata (device make/model, kernel version, system configuration, backend driver, etc) and to some extent writing instructions how to set up the measurements (loopback/cable connection etc) that almost any user would be able to follow.
The “QuickScan” script is probably a good starting point, or could be used as-is to gather most of the relevant info before running the measurements.
Maybe using one of the newfangled application packaging systems (snap/flatpack/appimage) could work, but I doubt it, configuring a single system for low latency is hard enough (even though it’s much easier nowadays).
It’s an interesting problem though, will have to think more about this… Sorry for the stream of consciousness reply, this escalated quickly in my mind :) It’s probably best to start small and add stuff down the line.
Trying to record the latency itself? hmmm. I guess the way that work would be to make sure the measurement is taken with the same settings in the Pipewire config files, then use jack_iodelay to measure. It would be interesting to see how that would differ… *gets distracted by testing some interfaces*
Yep like that, plus automating runs with decreasing buffer sizes (this might be tricky, restarting jack can be hit and miss) until there are xruns, to find the lower limit of the system. (Comparing measurements with physical/software loopback to get the converter delay for nerd points.)
I think a DB with results like that would be very useful for those that aim for really low latencies (for whatever reason). Both as a sort of consumer/buyers guide and the script for checking if their own setup is performing as well as the hardware allows (provided there is other data to compare to).
Thinking about it, I’ll probably build a simple script for my own use anyway (setting up a new DAW soon, and tweaking the latency is still a lot of hassle, writing a script for it is defintely more fun). Might as well share whatever I cobble together. Outputing to a sane report file format should be relatively easy (famous last words).
My web dev skills are definitely rusty, but importing, validating and plonking the data into a DB, with some simple pages to display it shouldn’t be out of reach.
Thanks to your inspiration, I pulled up jack_iodelay on my own Saffire Pro40, and yikes. I get something like 60 ms of extra latency on its output ports.
Yep 60 ms sounds high (can’t reply on your last reply it seems). I haven’t measured my interfaces yet (way past bedtime here now) but I think the Pro 26 I have should have similar construction, will give it a try tomorrow and see what I get. BTW, I found a script via linuxaudio.org that automates the measurements (uses jack_delay though): git://rg42.org/latentor
(posting from phone so not sure if the URL is valid)
For reference, I’m getting these numbers on jackdbus 1.9.17 (Debian Bullseye 5.10.0-6-rt-amd64 on Core i5-2405S):
Saffire LE: 436.323 frames 9.090 ms total roundtrip latency
extra loopback latency: 244 frames
Saffire Pro 26: 354.715 frames 7.390 ms total roundtrip latency
extra loopback latency: 162 frames
Nothing but the interface changed between the measurements. I think I’m using asynchronous mode (one effective extra buffer IIUC).
Caveat, the system has been tweaked a bit for low-latency (rtirq, hpet etc), but I haven’t gone into every nook and cranny to get the absolute best performance (running Gnome and ondemand governor for example). 48k sample rate, 2*64 buffers.
I may get the odd xrun now and then I think, so 128*2 buffers is probably a more reasonable setting. Haven’t done any serious audio work on this system in quite a while, and fiddled around a bit with the settings since then, so it might need some more tweaking to get it (mostly) xrun-free.
(I’m trying out pipewire with jack as backend on this system, but haven’t set it up properly, just hacked haphazardly at the config a bit until it connected to jack by default (blacklisted the integrated HDA audio).)
Make sure you run jackd in realtime mode.
Doesn’t jackd just run on top of ALSA?
Many FireWire interfaces have required Ffado drivers to work properly, they’re separate from Alsa. The article is about how that might not be necessary anymore (for Dice II devices at least IIUC). Jackd can use Alsa as well though.
Realtime in jackd is a setting independent of backend driver AFAIK.
In time Pipewire might be a viable option for serious audio work (low stable latency is a requirement for many uses). I’m not convinced yet, but worth trying to see how it works in practice.
Been using Pipewire for almost 4 months, and it’s already lightyears ahead of Pulse and Jack. Pipewire supports PA and jack APIs natively, so it’s a seamless, drop-in replacement. Seriously, all the jankiness disappeared when I installed it.
You still have to tune settings a bit to chase the XRUNs away, but this kernel patch supposedly eliminates that. As I understand it, there was some incongruity between the way the ALSA and Firewire layers kept clocks in sync, which is now fixed in 5.14.
Also, the Ffado code was rolled into ALSA some time back in 2019, so you’re actually running older, less capable code if you’re still running Ffado directly, especially if it’s from a distro package.