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!
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.
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
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.
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.
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 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?!
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.
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.
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
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
57 comments
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
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
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
CONFIG_FIREWIRE_OHCIin 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
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
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 ..
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.
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
But since Raspberry Pi launched their own microSD cards, I've been buying them. They haven't failed me yet and are pretty fast.
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.
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
> Linux will likely drop support for IEEE 1394 in 2029
Good to know!