Dear Mr. Sakamoto,
sorry for the late reply.
I was aware of the fact that you maintain the Linux Firewire subsystem, but I didn't know about the deprecation notice, so thanks for sending it.
So if I understand correctly, 2029 will be the last year when Firewire functionality is supported by Linux? Does this mean that Firewire functionality is going to be removed altogether after that?
Back to our devices - our firmware doesn't support TCAT protocol extension unfortunately. That's why I had to write this patch in the first place: only 44.1kHz and 48kHz could be selected.
About AVC, I had noticed your 'snd-firewire-ctl-services' project before. I also compiled it and played with it, but since I was able to re-use our old kernel-space AVC code with relatively little effort, I am currently working on that option. Nevertheless, I would be glad to assist you and making Weiss devices supported by 'snd-firewire-ctl-services'. Is there something else that you would need, apart from the configuration ROMs? And also what is the preferred way for sending you the ROMs? Should I open a pull request on your 'am-config-roms' repository on GitHub?
Kind regards, Michele Perrone
On 31/07/23 16:06, Takashi Sakamoto wrote:
Hi Mr. Michele,
On Mon, Jul 31, 2023 at 10:09:14AM +0200, Michele Perrone wrote:
Dear Mr. Sakamoto,
thank you very much for the prompt feedback, and also for your contributions to the Linux audio Firewire stack during the last decade.
Thanks. Nowadays I also maintain Linux FireWire subsystem itself[1][2][3].
We at Weiss Engineering would like to improve Linux support for our Firewire devices in order to extend their lifetimes. We have also occasionally received requests for Linux compatibility from some customers.
This is also motivated by the fact that the old DICE Apple driver, which was originally developed by TCAT, is not maintained anymore and does not work on Apple Silicon computers. Therefore, we would like to give the alternative of running our devices on Linux if the customers decide to do.
I know that no driver for 1394 OHCI hardware itself is included in recent MacOS anymore, regardless of hardware (x86_64/arm64). Your customer has no choice when continuing using their Weiss products.
We are also working on a update for our old music archive network player (MAN301), which uses a DICE chip to interface with its DAC; so it seemed only fair that owners of all Weiss devices based on DICE benefited from this.
That sounds great... However, let me note that the maintenance of Linux FireWire subsystem will be end in 2029, 6 years later (see the first reference link).
Sorry for mistakes 1, 2, and 3 (you can tell it's my first kernel patch). And I indeed forgot to include the snd_dice_detect_weiss_formats() prototype into the patch submittal.
About the 4th issue, yes, the 'category_id' is still correct [1].
Okay. ALSA dice driver has the mechanism to check category_id field against known values, while the check is skipped for explicit device entries which the patch adds. So this is just from my curiosity (I forgot the mechanism in the last message).
About the 5th issue, you are right both about the wrong tx/rx direction and the absence of isochronous packets from the device. I checked the DICE firmware code for the INT202 and we are indeed sending isochronous packets from the device. Therefore, the correct stream formats should look like this:
+/* Weiss INT202: 192kHz unidirectional 2-channel digital Firewire interface */ +static const struct dice_weiss_spec int202 = { + .tx_pcm_chs = {{2, 2, 2}, {0, 0, 0} }, + .rx_pcm_chs = {{2, 2, 2}, {0, 0, 0} }, + .has_midi = false +};
I tested this configuration with XLR and RCA outputs, and it works correctly.
Good. I revised the patch and force-pushed to the remote repository (747ddada9f4f).
Sorry for the mistake, I don't have a deep knowledge about the old DICE firmware because I've started working at Weiss Engineering only recently.
You would have more resources about DICE chipset, and get more helps from your colleague than me. No worry about it, I guess.
The rest of my concern is that TCAT protocol extension (EAP) support. In the extension, software can retrieve all of available stream format from the target device without switching mode of transmission frequency. If the device supports EAP, we do not necessarily to add hard-coded stream formats (please refer to the device entry with 'snd_dice_detect_extension_formats()'). I would like you to check specification of each Weiss product whether EAP is supported or not.
About the configuration ROMs, that shouldn't be an issue; let me get back to you as soon as I speak with my colleague, Rolf Anderegg. He has worked on our DICE devices in the past but he's on vacation right now.
Once connecting device to IEEE 1394 bus, the content of configuration ROM is exposed in sysfs node of Linux system. You can make a file to contain it by redirecting the output to the file, like:
$ cat /sys/bus/firewire/devices/fw1/config_rom > rom.img
Yet another topic is AVC support. We used to have support for it for the DICE driver in the 3.x kernel, and we are in the process of re-adapting that code. But this should be probably discussed in a separate e-mail.
Okay. For your information, I write user space program names as 'snd-dice-ctl-service' as the part of 'snd-firewire-ctl-services'[4]. At present, it has no support for Weiss products[5], so I'm pleased if getting any help in your side.
[1] https://git.kernel.org/torvalds/c/f3948874c340 [2] https://www.phoronix.com/news/Linux-Firewire-New-Maintainer [3] https://www.phoronix.com/news/Linux-6.5-Firewire [4] https://github.com/alsa-project/snd-firewire-ctl-services [5] https://docs.rs/firewire-dice-protocols/0.2.0/firewire_dice_protocols/
Thanks
Takashi Sakamoto