Problem with M-AUDIO FW410(snd-bebob) on 4.13 kernel

[chm-von-tla]

I'm on Arch Linux and for the module to compile I have to remove the <target/target_core_base.h> and <target/target_core_backed.h> from backport.h because the headers package for arch doesn't include those. backport.h.4.9.txt On 4.13 I also change the <linux/sched/signal.h> to <linux/signal.h>. backport.h.4.13.txt After doing that it gets compiled correctly.

As detailed here for my sound card to work the bootloader must load the firmware during boot up. The sound card also stops working randomly, so it must be reloaded again when that happens.

Following the above steps everything worked perfectly, both on the 4.12 kernel and the 4.9 lts kernel. It booted up correctly and it reset itself after a crash. But on the 4.13 kernel, while my sound card works after boot up it will not reset itself after it crashes. These are my dmesg logs: dmesg-grep-firewire.txt dmesg-grep-bebob.txt I assume the crash happened right at 3733.744; everything worked fine until then

[takaswie]

Hi,

At first, v4.13 kernel is the latest stable and there are few differences from master of this repository. Therefore, you don't necessarily compile and install sources from this repository. It's an easy way to use in-kernel module for your purpose.

[ 3733.744647] snd-bebob fw1.0: Detect discontinuity of CIP: 68 70

This line means that your device transfer packets with discontinuous index number. ALSA BeBoB driver set XRUN state to runtime of running PCM substream. Userspace applications stops playing typically.

If you still get the same situation when using in-kernel module, it seems to be an issue on device itself or driver. Else, it will be some issue in compilation or master code. Please try in-kernel module.

[chm-von-tla]

I don't think that my sound card is faulty. Others report the same issue with this model(example). The same thing also happeded for years when I was using the proprietary drivers on windows, the sound card would stop working and I would have to restart the windows audio service for it to work again. What I gathered from the link above is that my PCI firewire adapter may have a problem, but I cannot verify this at the moment.

Anyway, I'll use the in-kernel module for 4.13 and I'll get back to you

[chm-von-tla]

The in-kernel module seems to work. Thank you!

[puzzlled]

Hi, I'm running Netrunner rolling, which is basically a Manjaro system with KDE updates as I understand it. Since Manjaro is a derivative of Arch I thought the FW410 would work but I've tried numerous versions of the Manjaro kernels and none of them do. The firmware doesn't load and the following error is produced from dmesg.

[25219.826085] firewire_core 0000:03:00.0: rediscovered device fw0 [25219.826096] firewire_core 0000:03:00.0: phy config: new root=ffc1, gap_count=5 [25222.998659] firewire_core 0000:03:00.0: created device fw1: GUID 000d6c01109dc17a, S400 [25223.074782] snd-bebob fw1.0: Failed to send a cue to load firmware [25223.074801] snd-bebob: probe of fw1.0 failed with error -5

I get the same basic faliure, 'Failed to send a cue to load firmware', if I boot the machine with the FW410 connected or if I hot plug it. I've also had the FW410 working in Windows 7 and then did a reboot and the firmware seemed to stay loaded because the light stayed solid throughout the process. It was all good until I logged in and then it seemed to try to reload the firmware and the light started flashing again.

Can you give me any pointers as to what might be missing? The module tries to load the firmware but isn't successful so how can I go about troubleshooting what's going on? It doesn't seem to be Manjaro specific because I think I had the same problem with OpenSUSE and Ubuntu Studio.

I'd really like to be able to use this hardware and knowing that it's working fine for someone with a stock kernel is both encouraging and frustrating as I can't seem to get past this point and there is very limited current information to be found on using the FW410 in Linux.

Thanks in advance for any help.

[chm-von-tla]

I don't know if this is any way relevant to your problem but I sometimes have problems with settings set in windows through the m-audio control panel. Try resetting your device settings in windows, rebooting into linux and then configuring your device through ffado-mixer

[alepeccioli]

I also have the same problem, since the 4.10 kernel my m-audio 410 does not boot with a 64-bit kernel, I can only boot the 386 kernel. I have already tested several distros linux and all with the same problem.

[alepeccioli]

I was wrong, the last version of the kernel that I was able to boot into m-audio 410 in 64 bits was version 4.4. In the later versions only using: https://github.com/cladisch/linux-firewire-utils to boot the card.

[puzzlled]

**Thanks for the feedback folks. I did try the device reset under Windows but it didn't make a difference in Linux. It's still in the flashing light state and gives the following output.

ffado-test ListDevices === 1394 PORT 0 === Node id GUID VendorId ModelId Vendor - Model 0 0x000d6c01109dc17a 0x00000D6C 0x00010058 M-AUDIO - FW Bootloader no message buffer overruns**

So it's still sitting at the bootloader stage.

About 1.5 years ago I had it working on an old laptop (2005 vintage) but going from memory I had to issue a command in the terminal (I can't remember what though but I think it was dbus related) and then open ffado-mixer and after some fiddling it would get the card working. I think I needed to have ffado-mixer open or the card would shut down, but I can't be sure about that. This was on an install of Ubuntu Studio that would have been current at the time. Around the start of the new year I could get it working somewhat in OpenSUSE Tumbleweed if I rebooted from Windows, so it couldn't load the firmware but it could use the device if it was already loaded. At present I'm using Netrunner, which is based on Manjaro and uses the Manjaro kernels.

I might have to try the linux-firewire-utils route if I can remember how to set my system up so that I can compile things. It's been a long, long time.

From what I understand all that's needed is for the magic number to be sent to the device and then it will load the firmware from internal memory. From the digging I've done it would seem like takaswie has done the work to make this unit operate like a standard ALSA device and that would be great but I'm guessing something subtle changed with the kernel and now it's broken. Obviously the best solution is for the current module to be fixed and if there's any information that I can supply to help with that then let me know.

[puzzlled]

So after resetting the device to defaults (sample rate 44.1kHz, buffer 256) in Windows things have improved somewhat. Now if I reboot from Windows the device will work in Linux, even when logging into the desktop. Sound seems good and I didn't test all the inputs and outputs yet but it seems to function normally. At least now it's usable with this workaround. It still won't load the firmware from a cold boot into Linux though.

[puzzlled]

A further update. I had a need to be in Windows today so I took the opportunity to set the FW410 to a sample rate of 48kHz and a buffer of 128 samples. When rebooting into Netrunner it still works so those are valid settings for Plasma. I also borrowed a power adapter and connected it so that the firmware is maintained in active memory even if the PC is powered off. This means that as long as the FW410 stays powered on I don't have to boot into Windows to load the firmware, but it's not a long term solution and only a short term workaround.

[takaswie]

Sorry to be late to catch your issue due to my release work for new major version of libhinawa.

In upstream kernel, I committed support for M-Audio FireWire 410 at a commit 9076c22ddd9d ('ALSA: bebob: Add support for M-Audio usual Firewire series')[1]. I own some models produced by M-Audio with DM1000 ASIC and BeBoB v1 firmwares and use them as test devices for my continuous work to the latest kernel version.

• Ozonic
• FireWire Solo
• FireWire Audiophile
• FireWire 410

I've confirmed all of them are available in recent kernel, including waking them up successfully to loading firmwares if needed. Thus I can't reproduce your issue https://github.com/takaswie/snd-firewire-improve/issues/21#issuecomment-401889524.

Just powered on, FireWire 410 is wake up with bootloader firmware. In this time, the unit is detected on IEEE 1394 bus with vendor ID of 0x0007f5 and model ID with 0x010058. Then, when receiving some bytes by asynchronous transaction on IEEE 1394 bus, the bootloader loads another firmware and generate bus reset.

$ ./firewire-request /dev/fw1 write 0xFFFFC8021000 010000000000110100000000 (firewire-request is a part of linux-firewire-utils[2])

Then, the unit is detected with vendor ID of 0x000007f5 and model ID of 0x00010046.

ALSA bebob driver is programed to handle these procedure, but you see -EIO (error -5). In my opinion, your trial corresponds to bus reset on IEEE 1394 bus during the transaction and the transaction is canceled by transaction layer on the unit and Linux FireWire subsystem according to IEEE 1394 specification.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=9076c22ddd9d29a30426f0367dec2b40e12536de [2] https://github.com/cladisch/linux-firewire-utils

[puzzlled]

Thank you for your comprehensive reply. Because this error seems to be fairly consistent across numerous distributions (Ubuntu, OpenSUSE, Manjaro) can you suggest where things might have broken between the official kernel and these distributions? It sounds like you're saying that it's not a bebob issue but a problem with the firewire protocol so how is what you're using different than what is in the distros? My apologies if I'm not understanding what you're saying correctly. I have a thread open on Manjaro about this matter and some experienced people there are trying to help me.

https://forum.manjaro.org/t/firewire-m-audio-410-driver-wont-load-firmware/51165

Perhaps I'll ask them to read your posting here. As an aside, I was able to use my device for a while as I mentioned above but then it eventually died. I looked in dmesg and found that I was getting the same discontinuity error that the user above was. Perhaps this is just an unstable piece of hardware? That would be unfortunate because it's quite useful when it works. Thanks again for your help.

[takaswie]

can you suggest where things might have broken between the official kernel and these distributions?

Hm. As I said, I've never re-generate this issue in recent kernels, thus no suggestions I have.

IEEE 1394 has a feature called as 'bus reset'. This occurs when new devices are connected to the bus and new units are detected. During bus reset, all of asynchronous transactions are discarded by physical/link layer of IEEE 1394 components. It's responsible for software to retry the transaction. At present, ALSA bebob driver is not programmed for the retries.

[takaswie]

Hi,

Hm. As I said, I've never re-generate this issue in recent kernels, thus no suggestions I have.

I regenerate this issue with Linux kernel v4.16 or later. Please refer to #22 and sorry to bring inconvenience to you.