Linux Has A New Firewire IEEE-1394 Maintainer - Intends To Maintain Support To 2029

[Grinness]

Well I use Firewire extensively for music home recordings: a Focusrite Sapphire 14 hooked up on a R9 5900x
With Jack2 and FFADO (firewire, no pipewire) driver I obtain recordings delay (loop latency) of 162 frames at almost any sample rate/buffer size (currently running 48000Hz, buffer size 128, n of buffers 3 with a block latency of 2.7ms ) with no XRUNS when recording and/or mixing -- something a USB (2) audio device can only dream about

I will stick to it until it blows up (hopefully later than 2029)

[dammarin]

Why not just get a PCIe card? Those are pretty cheap.

Yes, well, obviously, but I mostly use a laptop now.

[schmidtbag]

Yes, well, obviously, but I mostly use a laptop now.

If you care enough, there are Thunderbolt to PCIe adapters.

[stormcrow]

Firewire always provided faster file transfer than USB back when I used it 7-8 years ago. It also used less system resources. However, the Linux driver would lock-up the system periodically. So while it was the better interface, I ended up migrating to USB for the stability. None of my systems still have a Firewire interface, and I got rid of all the Firewire cables a couple of years ago.

The irony being USB historically isn't always very stable either. I occasionally get USB hiccups transferring large files over USB in Linux whether I'm using the AMD motherboard interfaces or the add-on card I have (gives me an extra 3.2 "C" port). There's something wonky with the USB xhci driver with particularly long data transfers that results in very slow data transfers the interface won't recover from on my system. Have to unplug and plug the devices back in to reset the bus and driver. Works fine in Windows doing the same thing and same hardware. Don't know if it's more USB hardware wonkiness or what because it's happening on both the built in USB hubs and the add-on card which are two different brand chip sets.

Edit to add: I can reliably trigger it after a couple of GB transferring from one USB device hanging on the motherboard USB hub and the other on the add-on card so it's not just some random cosmic ray glitch.

[WebMac]

i've heard of a single person that cheats on games with them on windows lmao

How can you cheat with them?

[dreamcat4]

recently i had a umc404hd usb audio interface. however it had multiple drawbacks and also simply not enough channels

so 12 months ago i upgraded to firewire. and it is really the best. thanks to Takashi Sakamoto he has already provided all of the necessary support to run on the latest and greatest kernels, alsa and pipewire audio stack. and really i am lacking for 0 here.

now you might consider thunderbolt to be superior. but it is many times more expensive to get a thunderbolt interface. maybe 10x. but theres more...

speaking from an r2r perspective this firewire equipment is from an era where the equipment was designed to be repairable. as in: you can really repair pretty much anything on these barring a too-damaged pcb. contrast that with any modern interfaces made in recent years - they are far harder to repar with a lot of bga ics and hidden trace / buried vias. i also can get the full datasheets on all the ics. which again no longer possible on modern equipment

so what i am saying here is that the longevity of the hardware extends far beyond that 2029 date. i really can and will absolutely want to continue using it. the audio is not ever going to require better hardware. really it isn't. so i do hope to see you all here in 2029. not that i am capable of standing in for Takashi. he is far more accomplished maintainer than myself. however in my incidental interactions i can say he is an absolute pleasure to work with. for anybody else with the desires to assist / contribute on these firewire code

it also becomes a future question how to actually campaign against code removal once there is no longer an official maintainer. or what other solutions to keep it going.

btw:

in terms of laptop usage yes entirely possible using a $70 thunderbolt to nvme adapter. and then plugging into that a $10 pci-e firewire card via a $4 m.2 to pcie x4 adapter. so is still far cheaper than using a true thunderbolt audio interfaces. just requires a bit of diying to make an appropriate enclosure to keep robust and securely together all those (3) adapter pcbs. plus perhaps some additional low voltage 12v dc supply or whatever. depending on the powering requirements

in terms of destruction of firewire devices (which i have been informed pretty much only ever occurs during hot pluging). this is due to excessive play / tolerances in the physical firewire connector. such that you can insert the connector at an angle that is 'angled enough' to cross over the power vcc+ pin onto an adjacent data pin... which then overloads the sensitive differential data input of the firewire inteerface chip. thus blowing it up. (most likely an on sillicon fet amplifier).

a simple and pretty decent solution is possible if your target device(s) are in fact all independantly powered by their own power. and not being powered through the firewire cable itself. so what is needed is to go to the computer host side of things. the firewire port on your pc. that is what is actually supplying the vcc+ power rail (usually 12v or higher) onto the cable in the first place. so you need to go find on the pcb traces leading to the power vcc+ pin on the firewire port. and then simply just desolder it or cut it and permanmently disconnect it ...forever! this is actually fairly simple and easy process, to identify which pin from the pinout of a firewire port. just be sure not to mirror the pins by looking at the cable pinout vs the port pinout. because they will be mirror images of each other. doubly check the vcc+ pin on the pcb traces. or with a multimeter to be sure and confirm. i.e. use multiple of different **type** of methods to identify the pin to cut.

this will 'safe' your firewire equipment, to have no further worries. firewire protocol only needs its 2 pairs of differential data lines to carry a very sensitive and small differential signal. the vcc+ pin is not actually used for any part of the firewire data protocol. therefore not required and not used at all for independently powered target devices. removing this risk (when you can do it) is indeed worthwhile step. to avoid accidentally blowing up equipment. and to be able to do the live hotplugging without any such concern

[stormcrow]

How can you cheat with them?

I was wondering that too. I can't figure out how a DAC allows someone to cheat on a game.

[thepreacher]

I was wondering that too. I can't figure out how a DAC allows someone to cheat on a game.

Probably via DMA. It was one criticism of FireWire back in the day.

[NotMine999]

I have to complement Takashi Sakamoto for being open and honest about his plans for this driver.

Just wait...in 2026 we will start to hear the whining start when Takashi Sakamoto posts the first notice that the driver's lifetime ends in 2029.

And wait for all the "Sturm und Drang" in 2029 when the driver is officially removed due to lack of maintainership.

Plenty of time to locate an excellent popcorn machine and popcorn kernel supplier.

[dreamcat4]

the guy is great. absolutely fantastic level and quality and support for these. just know my firewire hardware can go another 20 years easy...

the thing is for legaxy CPUs, lets say: something like a 386 or 486 (or older PPC). Those no longer are that useful anymore. But the actual technological requirements for Pro audio... it's not going to change we can be pretty certain of. You might get slightly better DACs, Preamps in the latest and greatest Thunderbolt ones. But it's incremental.

Its a bit like saying we will evolve better human years in the next decade. But if anything... my human ears will degrade a whole lot more by that time. Much more. They will just get progressively worse over time.

I do however agree that there is a good case to be made for dropping most of the NON pro audio firewire equipment. Things like the storage or cameras. Since those are all so well obsoleted by now.