Using FireWire on a Raspberry Pi(jeffgeerling.com)
jeffgeerling.com
Using FireWire on a Raspberry Pi
https://www.jeffgeerling.com/blog/2026/firewire-on-a-raspberry-pi/
57 comments
I archived all my MiniDV tapes using a cheap firewire card and dvgrab on Linux, it can be set to automatically split noncontinous clips into different files for easy viewing. It's very straightforward to use and can be done unattended.
Just thinking back 10 years ago when I was arching all my DV tapes on my Dad's old G5... I did it all by hand through Final Cut Express. It would've been sooo much easier had I known about dvgrab back then!
I'd heard a few horror stories about people doing it on Windows and Mac, with bad compatibility and annoying software. With dvgrab it's super simple.
DVIO [0] and WinDV [1] would be the closest equivalents to dvgrab on Windows. Both are super easy to use (especially the former).
For HD DV tapes there's also HDVSplit [2].
[0] https://www.videohelp.com/software/DVIO
[1] https://www.videohelp.com/software/WinDV
[2] https://www.videohelp.com/software/HDVSplit
For HD DV tapes there's also HDVSplit [2].
[0] https://www.videohelp.com/software/DVIO
[1] https://www.videohelp.com/software/WinDV
[2] https://www.videohelp.com/software/HDVSplit
Also ripped all my old MiniDV tapes a decade ago or so. (I don't remember it being tedious.) (I recall about 12GB for each 60min tape, FWIW.)
I've known for some time now not to trust media formats to remain easy to access as time goes on. Floppy disks, ZIP disks, SCSI…
So nice the home movies are now in the cloud (and on USB drives as additional backup).
I've known for some time now not to trust media formats to remain easy to access as time goes on. Floppy disks, ZIP disks, SCSI…
So nice the home movies are now in the cloud (and on USB drives as additional backup).
Firewire support was removed from the Linux kernel so I had to switch to Mint Linux to accomplish the same thing
> Firewire support was removed from the Linux kernel
This is very much incorrect. Maybe the subsystem wasn't built into a custom kernel you're using?
edit: google says improvements through 2026, support through 2029
This is very much incorrect. Maybe the subsystem wasn't built into a custom kernel you're using?
edit: google says improvements through 2026, support through 2029
Many distros (including Raspberry Pi OS) don't enable `CONFIG_FIREWIRE_OHCI` in the kernel, so support isn't built-in, unless you build your own kernel.
But yes, it will be supported through 2029, and then after that, it could remain in the kernel longer, there's no mandate to remove it if I'm reading the maintenance status correctly: https://ieee1394.docs.kernel.org/en/latest/#maintenance-sche...
> [After 2029, it] would be possibly removed from Linux operating system any day
But yes, it will be supported through 2029, and then after that, it could remain in the kernel longer, there's no mandate to remove it if I'm reading the maintenance status correctly: https://ieee1394.docs.kernel.org/en/latest/#maintenance-sche...
> [After 2029, it] would be possibly removed from Linux operating system any day
Right, that matches my understanding. After 2029, It'll stick around as long as it continues to compile. If it fails to compile it would get dropped instead of updated as there's no maintainer.
This was around 2020 or 2021. I had an old laptop with a firewire port which was already running Ubuntu. I couldn't make it work. That's when I found that the support was removed from the kernel, and that's what led me to Linux Mint. I bought a new SSD and installed Linux Mint, and I was able to import my video tapes with no further issue.
An Ubuntu support page says eth1394 has been removed from the kernel since version 2.6.22.
Edit: This was a VERY old laptop. I think it has a 32 bit processor. Maybe that confounded the issue.
An Ubuntu support page says eth1394 has been removed from the kernel since version 2.6.22.
Edit: This was a VERY old laptop. I think it has a 32 bit processor. Maybe that confounded the issue.
> An Ubuntu support page says eth1394 has been removed from the kernel since version 2.6.22.
that doesn't really mean what you think it means, since they removed that module to replace it with a more standard module. and in addition, the presence or lack of eth1394 wouldn't affect a camera or fire interface in any meaningful way
that doesn't really mean what you think it means, since they removed that module to replace it with a more standard module. and in addition, the presence or lack of eth1394 wouldn't affect a camera or fire interface in any meaningful way
file interface*
This is an awesome project.
I have a long-in-the-tooth investment in Fireware audio devices (Presonus) in my studio - 19” rack interfaces with 10 I/O’s, as well as the StudioMix mixer with 20 or so .. I’ve been keeping an aging iMac around to use all of this with and it still just plain works, but having the option to replace it with an rPi is really appealing. The system is mostly used for tracking, so having REAPER on the rPi, connected to all that FireWire gear, just seems such a nice idea…
I wonder what the load will be like, though? Can the latest rPi with PCI hat and Firwire interface handle 40 channels of audio over FireWire, I wonder? I know the issue would mostly be SD-card write speeds and so on .. maybe this disqualifies the rPi - but certainly there are other ARM-based SBC’s that this same technique could be applied to ..
I have a long-in-the-tooth investment in Fireware audio devices (Presonus) in my studio - 19” rack interfaces with 10 I/O’s, as well as the StudioMix mixer with 20 or so .. I’ve been keeping an aging iMac around to use all of this with and it still just plain works, but having the option to replace it with an rPi is really appealing. The system is mostly used for tracking, so having REAPER on the rPi, connected to all that FireWire gear, just seems such a nice idea…
I wonder what the load will be like, though? Can the latest rPi with PCI hat and Firwire interface handle 40 channels of audio over FireWire, I wonder? I know the issue would mostly be SD-card write speeds and so on .. maybe this disqualifies the rPi - but certainly there are other ARM-based SBC’s that this same technique could be applied to ..
Audio shouldn't be a big problem for the Pi unless you're pumping it through tons of heavy filters. The Pi 5's CPU can hold its own against 2010-2015 era iMacs, and a good microSD card easily holds 40-50 MB/sec writes.
For better performance, I'd plug in a USB SSD (USB 3.0 can put through 300 MB/sec or more), or even use built in Ethernet, good for writing 100 MB/sec out to a NAS or another networked computer.
For better performance, I'd plug in a USB SSD (USB 3.0 can put through 300 MB/sec or more), or even use built in Ethernet, good for writing 100 MB/sec out to a NAS or another networked computer.
Is there a reason you couldn't use the USB audio and MIDI gadget drivers to pass through FireWire audio interfaces as class-compliant USB devices?
You could even use a virtual MIDI interface as a convenient way to control features beyond those supported by the USB audio class, along the lines of
https://github.com/michaelforney/oscmix/wiki/Protocol
You could even use a virtual MIDI interface as a convenient way to control features beyond those supported by the USB audio class, along the lines of
https://github.com/michaelforney/oscmix/wiki/Protocol
Do you have any preferred SD card brands and models? Speedy and durable cards suitable for RPi
I used to buy SanDisk Ultra (if I didn't need speed), Samsung Pro+ (if I did), or SanDisk Industrial (if I needed more reliability... not sure how big a difference it makes but I've never had one fail).
But since Raspberry Pi launched their own microSD cards, I've been buying them. They haven't failed me yet and are pretty fast.
But since Raspberry Pi launched their own microSD cards, I've been buying them. They haven't failed me yet and are pretty fast.
The Industrial lineup is dog slow though. That's the trade for SLC.
For cheap yet snappy cards, I have been using Kingston Canvas Go Plus with great success. When used in a Raspberry Pi 5, I personally don't feel any lag. A couple of them are serving 7/24/365 in my RPi5 systems without any problems for more than 2 years.
I don't hammer them with I/O though. For heavy writes, I'd consider Sandisk's higher tier cards (esp. Extreme Pro), which I use in my cameras and never managed to break one.
I don't hammer them with I/O though. For heavy writes, I'd consider Sandisk's higher tier cards (esp. Extreme Pro), which I use in my cameras and never managed to break one.
Fwiw, it is also possible to make a Pi boot from usb.
If you want to use the RPi instead of fixing the RPi becoming a new hobby, the preference is to avoid SD cards and write to USB SSD/network as OP recommended.
I have a Focusrite Saffire that has lots of nice, quiet preamps and ADC channels. I managed to get an old Mac to connect over FireWire and using the Focusrite Control app, I configured the routing to map all the analog inputs to ADAT. That works great but it's always at the wrong sample rate, and I can't change that without getting the old Mac out. Maybe I'll look into one of these rPi shields too. Anyone got any reverse engineering tips for the control protocol?!
The control protocol might be MIDI Sysex .. once you get Linux wired up to your FireWire interface you can wireguard the interfaces and see if you recognize SYSEX packets ..
Out of curiosity, what version of the OS is that iMac running? Using it as essentially dedicated piece of audio equipment instead of a daily driver would be fine by me. I've done it with the 2012 cheese grater MacPros running 10.6 for eternity essentially as a dedicated video capture device. It just happens to look like a computer, but it remains in use for one singular purpose. No more updates. No WAN access.
I looked it up, it’s 10.3. So, very, very long in the tooth - no longer supported, and even homebrew has given up on it.
So it is essentially just an appliance for the purpose of streaming FireWire audio to disk for use on other systems .. and in that capacity it serves well. But I think I’d like to replace it with a raspberry Pi ..
So it is essentially just an appliance for the purpose of streaming FireWire audio to disk for use on other systems .. and in that capacity it serves well. But I think I’d like to replace it with a raspberry Pi ..
Yeah, that's pretty much the life of the MacPros I described. The equipment is well paid for, and are only profit makers. They require no IT time. They require no maintenance. To replace them with anything else will cost money, and time retraining muscle memory on how to operate new device. Plus, all of the quirks of the new device would need to be caught/learned and workflows updated to include these.
Sometimes, the devil you know...
Sometimes, the devil you know...
It’s an ancient iMac from 2011, so whatever is the last supported version from Apple .. it never gets updates. (Don’t have it handy at the moment to find the exact version, sorry..)
Yeah, its just a dedicated DAW in the rig, used only for recording multiple tracks for later transfer to other modern machines for further work ..
Yeah, its just a dedicated DAW in the rig, used only for recording multiple tracks for later transfer to other modern machines for further work ..
Replacement doesn't have to be a raspberryPI.
Delightful that this still works. It would be interesting to go through the kernel tree and see how much maintenance goes into Firewire related code. Other than pulling data off of old devices, I wonder how many people are out there still using Firewire.
There's still a thriving (albeit small) community of skateboarders, retro enthusiasts, and even some AV pros who have FireWire equipment in active use.
In the kernel, the last commit in the IEEE 1394 area was a month or so ago—it's not 'active' maintenance, but its definitely being maintained, and is quite stable in my testing. (Thanks a ton to the current maintainer, who's going to go through the 3 year process of sunsetting full kernel support, and coordinating that with external projects!)
In the kernel, the last commit in the IEEE 1394 area was a month or so ago—it's not 'active' maintenance, but its definitely being maintained, and is quite stable in my testing. (Thanks a ton to the current maintainer, who's going to go through the 3 year process of sunsetting full kernel support, and coordinating that with external projects!)
Why sunset it, though? There’s still floppy, atapi, and zip support.
Every Apple device from the late 90s to 2012 had FireWire. Most Sony PCs from the late 90s to 2009. Google estimates that at over 100M systems with FireWire. There were 50M Zip drives, in comparison.
I know I should probably move on, but I have a lot of FireWire block devices and video equipment. The disk/disc drives can be moved to USB, but the video equipment cannot.
Every Apple device from the late 90s to 2012 had FireWire. Most Sony PCs from the late 90s to 2009. Google estimates that at over 100M systems with FireWire. There were 50M Zip drives, in comparison.
I know I should probably move on, but I have a lot of FireWire block devices and video equipment. The disk/disc drives can be moved to USB, but the video equipment cannot.
People moved from "good to have" to "better to throw it out because it's unmaintained so it's not secure".
And floppy support is needed for cloud-init, heh.
And floppy support is needed for cloud-init, heh.
By "people" you mean the corporate interests.
That’s actually pretty cool, I’m surprised there’s skateboarders that still use VX1000s or whatever instead of moving on to GoPros etc
Older cameras have a certain "look" that can be hard to manually reproduce. I've been considering getting an older digital (maybe DV) camcorder for exactly that reason, I find that "look" very charming, and it makes it look more like what I associate with a "home video"
There is an industry of capturing old tape formats to digital files. One place I was at had tape decks of every format form 3/4" U-matic all the way to HDCAM-SR with everything in between. The DV type decks were studio that had SDI outs, but from time to time, we'd have someone with a tape that just would not work in anything we had, except one of the employee's personal camera. We'd connect it to a firewire port on the front of a Mac, and keep on truckin'
The F-35 uses firewire [0].
[0]https://ntrs.nasa.gov/api/citations/20060009084/downloads/20...
[0]https://ntrs.nasa.gov/api/citations/20060009084/downloads/20...
Firewire user here! I have an old-but-very-functional rack mixer (Presonus) that will cost £700+ to replace, _plus_ I have to configure and set up the new one. I have a 2007 Macbook Pro that I keep around just for interfacing with it.
Same: a single StudioMix mixer with 2x FP10’s in the racks. This setup is just so lovely and functional I don’t want to upgrade it really, it just plain works. I have an old iMac as the DAW for the job, but the idea of replacing it with an ARM-based system, if it works, is so very appealing…
It's actively being maintained by Takashi Sakamoto. Here's the commit for Linux 7.0-rc1.
https://github.com/torvalds/linux/commit/0d6dd4738dbcc32b60c...
https://github.com/torvalds/linux/commit/0d6dd4738dbcc32b60c...
TIL Linux does eventually drop support for old hardware.
It's more about maintainability than age.
Some ancient hardware which is still actively being used and which has plenty of maintainers willing to keep it up-to-date will stick around.
A driver of only a few years old with roughly zero drivers, no maintainers, and which forms an obstacle for other work? That'll be gone very quickly.
Some ancient hardware which is still actively being used and which has plenty of maintainers willing to keep it up-to-date will stick around.
A driver of only a few years old with roughly zero drivers, no maintainers, and which forms an obstacle for other work? That'll be gone very quickly.
I'm still sad that Linux dropped support for i486 and early-i586 CPUs.
And more disappointed that distributions especially Debian the "universal operating system" has dropped support for i586 already (and is dropping support for i686)
Open-source doesn't have the same pressures of commercial software from Apple or Microsoft. I really love the idea of obsessive, perfectionism approach of providing indefinite hardware support to obscure old hardware (but especially once-popular old hardware), with adequate automated testing suites to test ancient hardware.
Maybe with agentic AI coding we'll be able to expand support windows, and even bring back hardware support for older hardware.
And more disappointed that distributions especially Debian the "universal operating system" has dropped support for i586 already (and is dropping support for i686)
Open-source doesn't have the same pressures of commercial software from Apple or Microsoft. I really love the idea of obsessive, perfectionism approach of providing indefinite hardware support to obscure old hardware (but especially once-popular old hardware), with adequate automated testing suites to test ancient hardware.
Maybe with agentic AI coding we'll be able to expand support windows, and even bring back hardware support for older hardware.
> Open-source doesn't have the same pressures of commercial software from Apple or Microsoft.
Open source has a pressure that's often even more difficult to overcome: limited spare time from volunteer maintainers. Volunteers are usually drawn from the pool of users. There aren't many i586 users left, so the pool of volunteers is small enough that there's no one able or willing to maintain Debian for it.
If you're that disappointed, step up to maintain the i586 port! If you're unable or unwilling to do so, then you have your answer, generalized across all i586 enthusiasts, as to why they dropped support.
Open source has a pressure that's often even more difficult to overcome: limited spare time from volunteer maintainers. Volunteers are usually drawn from the pool of users. There aren't many i586 users left, so the pool of volunteers is small enough that there's no one able or willing to maintain Debian for it.
If you're that disappointed, step up to maintain the i586 port! If you're unable or unwilling to do so, then you have your answer, generalized across all i586 enthusiasts, as to why they dropped support.
Open-source doesn't have the same pressures of commercial software from Apple or Microsoft
Look at who contributes to the Linux kernel. We'd never have "secure" boot or any of that hostile lockdown stuff if it wasn't tainted with commercial interests pushing their agenda.
Look at who contributes to the Linux kernel. We'd never have "secure" boot or any of that hostile lockdown stuff if it wasn't tainted with commercial interests pushing their agenda.
> We'd never have "secure" boot or any of that hostile lockdown stuff if it wasn't tainted with commercial interests pushing their agenda.
To be fair, there is value to be had in reasonably trustworthy cryptography and computing. As long as you can enroll your own certificates in the secure-boot trustchain, you can have a device where you can be reasonably certain that, even assuming an evil-maid attack, as long as your computer is powered down, it is protected against a wide, wide class of attacks.
And for some people, that matters. Even in the US, greetings go out to ICE.
To be fair, there is value to be had in reasonably trustworthy cryptography and computing. As long as you can enroll your own certificates in the secure-boot trustchain, you can have a device where you can be reasonably certain that, even assuming an evil-maid attack, as long as your computer is powered down, it is protected against a wide, wide class of attacks.
And for some people, that matters. Even in the US, greetings go out to ICE.
Real question though: who's gonna run a CI farm of old hardware? That sounds not-cheap and commercially untenable.
I imagine you don't need to; you can emulate i586 on x86_64, and it would probably be performant enough.
But I suspect that's not really the hurdle: none of the existing Debian developers care enough about it to maintain it, and no one who cares about it enough about it is willing to maintain it.
But I suspect that's not really the hurdle: none of the existing Debian developers care enough about it to maintain it, and no one who cares about it enough about it is willing to maintain it.
Wouldn’t this be an unreliable CI though? I assume i586 and i686 cycle accurate emulators are hard to come by?
NetBSD?
NetBSD has the same problem that the major Linux distros do, it's just expressed differently. Instead of dropping support like the Linux distros do, they will keep cross-compiling for old and obscure platforms even if nobody cares enough about them to test them. Then major breakages will start to appear that make the ports unusable (crash on boot, no video, no keyboard input, etc) and they go unnoticed for years because these ports have no actual real-world users. The only benefit I can think of for the project being set up this way is that it makes some nostalgic Gen X'ers happy when they pull up the NetBSD site and go "oh I could run a supported OS on my 68k Mac/Next Cube/Windows CE handheld/whatever, that's neat" and then they go about the rest of their day without actually doing that.
Posted a few days ago: https://news.ycombinator.com/item?id=47509902
Have similar needs. Found an old OWC Mercury Elite HDD that uses FireWire but no longer have old Mac G4
If the job is a one-time transfer to get files from old media to new media, is there any reason not to use an old Linux kernel on (non-RPi) compatible hardware that had IEEE 1394 enabled by default instead of compiling a new kernel for RPi with IEEE 1394 enabled
If the job is a one-time transfer to get files from old media to new media, is there any reason not to use an old Linux kernel on (non-RPi) compatible hardware that had IEEE 1394 enabled by default instead of compiling a new kernel for RPi with IEEE 1394 enabled
Nice setup. I keep a FireWire card in my PC for digitizing VHS tapes using a Canon HV20 and a VCR.
I need to sit down and finish the project (and sooner than later with VHS media breaking down).
> Linux will likely drop support for IEEE 1394 in 2029
Good to know!
> Linux will likely drop support for IEEE 1394 in 2029
Good to know!
Usb to firewire adapter cords do exist and work fine. they are about 5-15$