[PATCH] ALSA: dice: add stream format parameters for Weiss devices
Hard-coded stream format parameters are added for Weiss Engineering FireWire devices. When the device vendor and model match, the parameters are copied into the stream format cache. This allows for setting all supported sampling rates up to 192kHz, and consequently adjusting the number of available I/O channels. Signed-off-by: Rolf Anderegg <rolf.anderegg@weiss.ch> Signed-off-by: Michele Perrone <michele.perrone@weiss.ch> --- sound/firewire/dice/Makefile | 2 +- sound/firewire/dice/dice-weiss.c | 120 +++++++++++++++++++++++++++++++ sound/firewire/dice/dice.c | 72 +++++++++++++++++++ 3 files changed, 193 insertions(+), 1 deletion(-) create mode 100644 sound/firewire/dice/dice-weiss.c diff --git a/sound/firewire/dice/Makefile b/sound/firewire/dice/Makefile index a5f3fbf28b8c..bac8712f9014 100644 --- a/sound/firewire/dice/Makefile +++ b/sound/firewire/dice/Makefile @@ -2,5 +2,5 @@ snd-dice-objs := dice-transaction.o dice-stream.o dice-proc.o dice-midi.o \ dice-pcm.o dice-hwdep.o dice.o dice-tcelectronic.o \ dice-alesis.o dice-extension.o dice-mytek.o dice-presonus.o \ - dice-harman.o dice-focusrite.o + dice-harman.o dice-focusrite.o dice-weiss.o obj-$(CONFIG_SND_DICE) += snd-dice.o diff --git a/sound/firewire/dice/dice-weiss.c b/sound/firewire/dice/dice-weiss.c new file mode 100644 index 000000000000..ad22bfafd324 --- /dev/null +++ b/sound/firewire/dice/dice-weiss.c @@ -0,0 +1,120 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * dice-weiss.c - a part of driver for DICE based devices + * + * Copyright (c) 2023 Rolf Anderegg and Michele Perrone + */ + +#include "dice.h" + +struct dice_weiss_spec { + unsigned int tx_pcm_chs[MAX_STREAMS][SND_DICE_RATE_MODE_COUNT]; + unsigned int rx_pcm_chs[MAX_STREAMS][SND_DICE_RATE_MODE_COUNT]; + bool has_midi; +}; + +/* Weiss DAC202: 192kHz 2-channel DAC */ +static const struct dice_weiss_spec dac202 = { + .tx_pcm_chs = {{2, 2, 2}, {0, 0, 0} }, + .rx_pcm_chs = {{2, 2, 2}, {0, 0, 0} }, + .has_midi = false +}; + +/* Weiss MAN301: 192kHz 2-channel music archive network player */ +static const struct dice_weiss_spec man301 = { + .tx_pcm_chs = {{2, 2, 2}, {0, 0, 0} }, + .rx_pcm_chs = {{2, 2, 2}, {0, 0, 0} }, + .has_midi = false +}; + +/* 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 = {{0, 0, 0}, {0, 0, 0} }, + .has_midi = false +}; + +/* Weiss INT203: 192kHz bidirectional 2-channel digital Firewire interface */ +static const struct dice_weiss_spec int203 = { + .tx_pcm_chs = {{2, 2, 2}, {0, 0, 0} }, + .rx_pcm_chs = {{2, 2, 2}, {0, 0, 0} }, + .has_midi = false +}; + +/* Weiss ADC2: 192kHz A/D converter with microphone preamps and line inputs */ +static const struct dice_weiss_spec adc2 = { + .tx_pcm_chs = {{2, 2, 2}, {0, 0, 0} }, + .rx_pcm_chs = {{2, 2, 2}, {0, 0, 0} }, + .has_midi = false +}; + +/* Weiss DAC2/Minerva: 192kHz 2-channel DAC */ +static const struct dice_weiss_spec dac2_minerva = { + .tx_pcm_chs = {{2, 2, 2}, {0, 0, 0} }, + .rx_pcm_chs = {{2, 2, 2}, {0, 0, 0} }, + .has_midi = false +}; + +/* Weiss Vesta: 192kHz 2-channel Firewire to AES/EBU interface */ +static const struct dice_weiss_spec vesta = { + .tx_pcm_chs = {{2, 2, 2}, {0, 0, 0} }, + .rx_pcm_chs = {{2, 2, 2}, {0, 0, 0} }, + .has_midi = false +}; + +/* Weiss AFI1: 192kHz 24-channel Firewire to ADAT or AES/EBU interface */ +static const struct dice_weiss_spec afi1 = { + .tx_pcm_chs = {{24, 16, 8}, {0, 0, 0} }, + .rx_pcm_chs = {{24, 16, 8}, {0, 0, 0} }, + .has_midi = false +}; + +int snd_dice_detect_weiss_formats(struct snd_dice *dice) +{ + static const struct { + u32 model_id; + const struct dice_weiss_spec *spec; + } *entry, entries[] = { + {0x000007, &dac202}, + {0x000008, &dac202}, /* Maya edition: same audio I/O as DAC202 */ + {0x000006, &int202}, + {0x00000a, &int203}, + {0x00000b, &man301}, + {0x000001, &adc2}, + {0x000003, &dac2_minerva}, + {0x000002, &vesta}, + {0x000004, &afi1}, + }; + struct fw_csr_iterator it; + int key, val, model_id; + int i; + + model_id = 0; + fw_csr_iterator_init(&it, dice->unit->directory); + while (fw_csr_iterator_next(&it, &key, &val)) { + if (key == CSR_MODEL) { + model_id = val; + break; + } + } + + for (i = 0; i < ARRAY_SIZE(entries); ++i) { + entry = entries + i; + if (entry->model_id == model_id) + break; + } + if (i == ARRAY_SIZE(entries)) + return -ENODEV; + + memcpy(dice->tx_pcm_chs, entry->spec->tx_pcm_chs, + MAX_STREAMS * SND_DICE_RATE_MODE_COUNT * sizeof(unsigned int)); + memcpy(dice->rx_pcm_chs, entry->spec->rx_pcm_chs, + MAX_STREAMS * SND_DICE_RATE_MODE_COUNT * sizeof(unsigned int)); + + if (entry->spec->has_midi) { + dice->tx_midi_ports[0] = 1; + dice->rx_midi_ports[0] = 1; + } + + return 0; +} diff --git a/sound/firewire/dice/dice.c b/sound/firewire/dice/dice.c index 6c93e6e4982c..4bcd026a0b3f 100644 --- a/sound/firewire/dice/dice.c +++ b/sound/firewire/dice/dice.c @@ -396,6 +396,78 @@ static const struct ieee1394_device_id dice_id_table[] = { .match_flags = IEEE1394_MATCH_VERSION, .version = DICE_INTERFACE, }, + /* Weiss DAC202: 192kHz 2-channel DAC */ + { + .match_flags = IEEE1394_MATCH_VENDOR_ID | + IEEE1394_MATCH_MODEL_ID, + .vendor_id = OUI_WEISS, + .model_id = 0x000007, + .driver_data = (kernel_ulong_t)snd_dice_detect_weiss_formats, + }, + /* Weiss DAC202: 192kHz 2-channel DAC (Maya edition) */ + { + .match_flags = IEEE1394_MATCH_VENDOR_ID | + IEEE1394_MATCH_MODEL_ID, + .vendor_id = OUI_WEISS, + .model_id = 0x000008, + .driver_data = (kernel_ulong_t)snd_dice_detect_weiss_formats, + }, + /* Weiss MAN301: 192kHz 2-channel music archive network player */ + { + .match_flags = IEEE1394_MATCH_VENDOR_ID | + IEEE1394_MATCH_MODEL_ID, + .vendor_id = OUI_WEISS, + .model_id = 0x00000b, + .driver_data = (kernel_ulong_t)snd_dice_detect_weiss_formats, + }, + /* Weiss INT202: 192kHz unidirectional 2-channel digital Firewire interface */ + { + .match_flags = IEEE1394_MATCH_VENDOR_ID | + IEEE1394_MATCH_MODEL_ID, + .vendor_id = OUI_WEISS, + .model_id = 0x000006, + .driver_data = (kernel_ulong_t)snd_dice_detect_weiss_formats, + }, + /* Weiss INT203: 192kHz bidirectional 2-channel digital Firewire interface */ + { + .match_flags = IEEE1394_MATCH_VENDOR_ID | + IEEE1394_MATCH_MODEL_ID, + .vendor_id = OUI_WEISS, + .model_id = 0x00000a, + .driver_data = (kernel_ulong_t)snd_dice_detect_weiss_formats, + }, + /* Weiss ADC2: 192kHz A/D converter with microphone preamps and line inputs */ + { + .match_flags = IEEE1394_MATCH_VENDOR_ID | + IEEE1394_MATCH_MODEL_ID, + .vendor_id = OUI_WEISS, + .model_id = 0x000001, + .driver_data = (kernel_ulong_t)snd_dice_detect_weiss_formats, + }, + /* Weiss DAC2/Minerva: 192kHz 2-channel DAC */ + { + .match_flags = IEEE1394_MATCH_VENDOR_ID | + IEEE1394_MATCH_MODEL_ID, + .vendor_id = OUI_WEISS, + .model_id = 0x000003, + .driver_data = (kernel_ulong_t)snd_dice_detect_weiss_formats, + }, + /* Weiss Vesta: 192kHz 2-channel Firewire to AES/EBU interface */ + { + .match_flags = IEEE1394_MATCH_VENDOR_ID | + IEEE1394_MATCH_MODEL_ID, + .vendor_id = OUI_WEISS, + .model_id = 0x000002, + .driver_data = (kernel_ulong_t)snd_dice_detect_weiss_formats, + }, + /* Weiss AFI1: 192kHz 24-channel Firewire to ADAT or AES/EBU interface */ + { + .match_flags = IEEE1394_MATCH_VENDOR_ID | + IEEE1394_MATCH_MODEL_ID, + .vendor_id = OUI_WEISS, + .model_id = 0x000004, + .driver_data = (kernel_ulong_t)snd_dice_detect_weiss_formats, + }, { } }; MODULE_DEVICE_TABLE(ieee1394, dice_id_table); base-commit: 9b4469410cf9a0fcbccc92c480fd42f7c815a745 -- 2.41.0
ei, On Fri, Jul 28, 2023 at 11:16:11AM +0200, Michele Perrone wrote:
Hard-coded stream format parameters are added for Weiss Engineering FireWire devices. When the device vendor and model match, the parameters are copied into the stream format cache. This allows for setting all supported sampling rates up to 192kHz, and consequently adjusting the number of available I/O channels.
Signed-off-by: Rolf Anderegg <rolf.anderegg@weiss.ch> Signed-off-by: Michele Perrone <michele.perrone@weiss.ch> --- sound/firewire/dice/Makefile | 2 +- sound/firewire/dice/dice-weiss.c | 120 +++++++++++++++++++++++++++++++ sound/firewire/dice/dice.c | 72 +++++++++++++++++++ 3 files changed, 193 insertions(+), 1 deletion(-) create mode 100644 sound/firewire/dice/dice-weiss.c
Thanks for the patch. I've been waiting so long for such patches to support Weiss models. I welcome them. As long as reviewing, I found some format and technical issues on the patches: Format issues: 1.unexpected line break 2.tab indentations are replaced with spaces Technical issues: 3.build error due to missing snd_dice_detect_weiss_formats() * prototype of snd_dice_detect_weiss_formats() should be in dice.c 4. category_id in GUID 5.stream formats for INT202 I can correct 1st, 2nd, and 3rd issues. You can find the revised patch in the top-most of my remote repository[1]. Let me confirm the 4th issue. TCAT defines 'category_id' field in GUID value of devices. As long as I know, Weiss engineers uses 0x00 in the field[2]. Is it still correct for the devices supported in the patch? Next, let us discuss about INT202 stream formats. + +/* 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 = {{0, 0, 0}, {0, 0, 0} }, + .has_midi = false +}; (tx/rx should be device-oriented, tx = from device, rx = to device, please correct) I assume all of the DICE devices transmit isochronous packets to deliver presentation time stamp and events (= PCM frames). Then driver software utilizes the presentation time stamp and the amount of events to construct payload of isochronous packets into the device. I program ALSA dice driver based on the assumption, thus ALSA dice driver doesn't work well without receiving any isochronous packet from the device. However, the stream formats for INT202 device looks to support uni-directional operation. Weiss engineers really use DICE chipset like that? If so, I need to integrate the driver to support the case. As another topic. I make collection of configuration ROMs[3] to make better support for the devices in Linux system[4]. I'm pleased if you pick them up from your devices and dedicate them for the collection. [1] https://github.com/takaswie/sound/tree/topic/dice/weiss-support [2] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/tree/sound/f... [3] https://github.com/takaswie/am-config-roms/ [4] https://github.com/systemd/systemd/blob/main/hwdb.d/80-ieee1394-unit-functio... Thanks Takashi Sakamoto
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. 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. 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. 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]. 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. 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. 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. 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. [1]: https://github.com/torvalds/linux/commit/a471fcde8c2c4b65f110bb4210af3513ee4... Kind regards, Michele Perrone On 28/07/23 15:13, Takashi Sakamoto wrote:
ei,
On Fri, Jul 28, 2023 at 11:16:11AM +0200, Michele Perrone wrote:
Hard-coded stream format parameters are added for Weiss Engineering FireWire devices. When the device vendor and model match, the parameters are copied into the stream format cache. This allows for setting all supported sampling rates up to 192kHz, and consequently adjusting the number of available I/O channels.
Signed-off-by: Rolf Anderegg <rolf.anderegg@weiss.ch> Signed-off-by: Michele Perrone <michele.perrone@weiss.ch> --- sound/firewire/dice/Makefile | 2 +- sound/firewire/dice/dice-weiss.c | 120 +++++++++++++++++++++++++++++++ sound/firewire/dice/dice.c | 72 +++++++++++++++++++ 3 files changed, 193 insertions(+), 1 deletion(-) create mode 100644 sound/firewire/dice/dice-weiss.c Thanks for the patch. I've been waiting so long for such patches to support Weiss models. I welcome them.
As long as reviewing, I found some format and technical issues on the patches:
Format issues: 1.unexpected line break 2.tab indentations are replaced with spaces
Technical issues: 3.build error due to missing snd_dice_detect_weiss_formats() * prototype of snd_dice_detect_weiss_formats() should be in dice.c 4. category_id in GUID 5.stream formats for INT202
I can correct 1st, 2nd, and 3rd issues. You can find the revised patch in the top-most of my remote repository[1].
Let me confirm the 4th issue. TCAT defines 'category_id' field in GUID value of devices. As long as I know, Weiss engineers uses 0x00 in the field[2]. Is it still correct for the devices supported in the patch?
Next, let us discuss about INT202 stream formats.
+ +/* 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 = {{0, 0, 0}, {0, 0, 0} }, + .has_midi = false +};
(tx/rx should be device-oriented, tx = from device, rx = to device, please correct)
I assume all of the DICE devices transmit isochronous packets to deliver presentation time stamp and events (= PCM frames). Then driver software utilizes the presentation time stamp and the amount of events to construct payload of isochronous packets into the device.
I program ALSA dice driver based on the assumption, thus ALSA dice driver doesn't work well without receiving any isochronous packet from the device. However, the stream formats for INT202 device looks to support uni-directional operation. Weiss engineers really use DICE chipset like that? If so, I need to integrate the driver to support the case.
As another topic. I make collection of configuration ROMs[3] to make better support for the devices in Linux system[4]. I'm pleased if you pick them up from your devices and dedicate them for the collection.
[1] https://github.com/takaswie/sound/tree/topic/dice/weiss-support [2] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/tree/sound/f... [3] https://github.com/takaswie/am-config-roms/ [4] https://github.com/systemd/systemd/blob/main/hwdb.d/80-ieee1394-unit-functio...
Thanks
Takashi Sakamoto
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
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
Hi, On Tue, Aug 08, 2023 at 10:34:38AM +0200, Michele Perrone wrote:
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?
Let me avoid professing about it, but it is better not to continue using Linux FireWire subsystem anymore beyond the 3 years migration period.
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.
Okay. I'll post the revised version of patch to the list, then requests the maintainer of sound subsystem to apply it to his tree for v6.5-rc6.
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'.
As a policy to maintain current ALSA firewire stack, any code for control function is out of kernel land, thus your AVC function can not to be merged to Linux upstream as is. I think the most convenient way is to provide source code for the AVC function to me. Then I re-implement it by Rust language for snd-dice-ctl-service program. As long as interpreting original code, we have no license issue for the new code. But As a first step, I would like you to assist my support for DICE common controls in your models. When ALSA dice driver is loaded, it adds an procfs node to dump information by TCAT general protocol, like: $ cat /proc/asound/card2/firewire/dice sections: global: offset 10, size 90 tx: offset 100, size 142 rx: offset 242, size 282 ext_sync: offset 524, size 4 unused2: offset 0, size 0 global: owner: ffc1:000100000000 notification: 00000010 nick name: DesktopKonnekt6 clock select: internal 48000 enable: 0 status: locked 48000 ext status: 00000000 sample rate: 48000 version: 1.0.4.0 clock caps: 44100 48000 88200 96000 176400 192000 arx1 arx2 internal clock source names: Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\INTERNAL\\ ... I need the `clock caps` and `clock source names` fields to implement the common controls for your device in 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?
I don't mind which way to use. In my point of view, we need to decide license under which the file of configuration ROM image is public. I think CC0[0] is bette for our case. I'm planning to move the repository under git.kernel.org, and have talked with admin about it. The admin said that I need to declare the license of included files. I'm under re-classifying these files and not finished yet. So when you contribute the files for your models, please use CC0 by declaring in commit/request message. [0] https://creativecommons.org/publicdomain/zero/1.0/ Regards Takashi Sakamoto
Dear Mr. Sakamoto, since we are not discussing about the patch anymore, let me reply to our open threads in a separate message. On 08/08/23 17:25, Takashi Sakamoto wrote:
As a policy to maintain current ALSA firewire stack, any code for control function is out of kernel land, thus your AVC function can not to be merged to Linux upstream as is.
I think the most convenient way is to provide source code for the AVC function to me. Then I re-implement it by Rust language for snd-dice-ctl-service program. As long as interpreting original code, we have no license issue for the new code.
That is very kind of you. You can now find our current AVC code in the following public repository (branch 'avc'): https://github.com/weiss-engineering/snd-dice/tree/avc If you have questions about the code, also on the firmware side of things, feel free to ask.
But As a first step, I would like you to assist my support for DICE common controls in your models. I need the `clock caps` and `clock source names` fields to implement the common controls for your device in snd-firewire-ctl-services.
You can find the `clock caps` and `clock source names` fields for all our Firewire devices below. As I currently do not have access to our Firewire hardware except for MAN301, DAC202, and INT202, for the remaining devices I copied the fields from their latest firmware source code. -- MAN301 -- clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 aes3 wc internal clock source names: AES/EBU (XLR)\S/PDIF (RCA)\S/PDIF (TOS)\Unused\Unused\Unused\Unused\Word Clock (BNC)\Unused\Unused\Unused\Unused\Internal\\ -- DAC202 -- clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 aes3 wc arx1 internal clock source names: AES/EBU (XLR)\S/PDIF (RCA)\S/PDIF (TOSLINK)\Unused\Unused\Unused\Unused\Word Clock\Unused\Unused\Unused\Unused\Internal\\ -- INT202 -- clock caps: 44100 48000 88200 96000 176400 192000 arx1 internal clock source names: Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Internal\\ -- INT203 -- clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 arx1 internal clock source names: AES/EBU (XLR)\S/PDIF (RCA)\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Internal\\ -- ADC2 -- clock caps: 44100 48000 88200 96000 176400 192000 aes1 clock source names: AES12\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\\ -- DAC2/Minerva -- clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 aes3 arx1 internal clock source names: AES/EBU (XLR)\S/PDIF (RCA)\S/PDIF (TOSLINK)\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Internal\\ -- Vesta -- clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 aes3 arx1 internal clock source names: AES/EBU (XLR)\S/PDIF (RCA)\S/PDIF (TOSLINK)\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Internal\\ -- AFI1 -- clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 aes3 aes4 adat wc internal clock source names: AES12\AES34\AES56\AES78\Unused\ADAT\Unused\Word Clock\Unused\Unused\Unused\Unused\Internal\\
In my point of view, we need to decide license under which the file of configuration ROM image is public. I think CC0[0] is bette for our case.
I have created a pull request in takaswie/am-config-roms with three ROM images: MAN301, DAC202, INT202. I cannot extract the remaining images at the moment, because I do not have all Firewire devices available. I will add the remaining images as soon as I can get my hands on them. Kind regards, Michele Perrone
Hi, Sorry for my late reply, but I'm in short summer vacation in my country side (less connections to internet). Would you please wait for any reaction within a few days. Regards Takashi Sakamoto On Wed, Aug 16, 2023 at 03:05:36PM +0200, Michele Perrone wrote:
Dear Mr. Sakamoto,
since we are not discussing about the patch anymore, let me reply to our open threads in a separate message.
On 08/08/23 17:25, Takashi Sakamoto wrote:
As a policy to maintain current ALSA firewire stack, any code for control function is out of kernel land, thus your AVC function can not to be merged to Linux upstream as is.
I think the most convenient way is to provide source code for the AVC function to me. Then I re-implement it by Rust language for snd-dice-ctl-service program. As long as interpreting original code, we have no license issue for the new code.
That is very kind of you. You can now find our current AVC code in the following public repository (branch 'avc'): [1]https://github.com/weiss-engineering/snd-dice/tree/avc If you have questions about the code, also on the firmware side of things, feel free to ask.
But As a first step, I would like you to assist my support for DICE common controls in your models. I need the `clock caps` and `clock source names` fields to implement the common controls for your device in snd-firewire-ctl-services.
You can find the `clock caps` and `clock source names` fields for all our Firewire devices below. As I currently do not have access to our Firewire hardware except for MAN301, DAC202, and INT202, for the remaining devices I copied the fields from their latest firmware source code. -- MAN301 -- clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 aes3 wc internal clock source names: AES/EBU (XLR)\S/PDIF (RCA)\S/PDIF (TOS)\Unused\Unused\Unused\Unused\Word Clock (BNC)\Unused\Unused\Unused\Unused\Internal\\ -- DAC202 -- clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 aes3 wc arx1 internal clock source names: AES/EBU (XLR)\S/PDIF (RCA)\S/PDIF (TOSLINK)\Unused\Unused\Unused\Unused\Word Clock\Unused\Unused\Unused\Unused\Internal\\ -- INT202 -- clock caps: 44100 48000 88200 96000 176400 192000 arx1 internal clock source names: Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\U nused\Unused\Internal\\ -- INT203 -- clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 arx1 internal clock source names: AES/EBU (XLR)\S/PDIF (RCA)\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Un used\Internal\\ -- ADC2 -- clock caps: 44100 48000 88200 96000 176400 192000 aes1 clock source names: AES12\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Un used\Unused\Unused\\ -- DAC2/Minerva -- clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 aes3 arx1 internal clock source names: AES/EBU (XLR)\S/PDIF (RCA)\S/PDIF (TOSLINK)\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unuse d\Internal\\ -- Vesta -- clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 aes3 arx1 internal clock source names: AES/EBU (XLR)\S/PDIF (RCA)\S/PDIF (TOSLINK)\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unuse d\Internal\\ -- AFI1 -- clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 aes3 aes4 adat wc internal clock source names: AES12\AES34\AES56\AES78\Unused\ADAT\Unused\Word Clock\Unused\Unused\Unused\Unused\Internal\\
In my point of view, we need to decide license under which the file of configuration ROM image is public. I think CC0[0] is bette for our case.
I have created a pull request in takaswie/am-config-roms with three ROM images: MAN301, DAC202, INT202. I cannot extract the remaining images at the moment, because I do not have all Firewire devices available. I will add the remaining images as soon as I can get my hands on them.
Kind regards, Michele Perrone
参照
Dear Mr. Sakamoto, no problem at all -- have a nice vacation. Kind regards, Michele Perrone On 18/08/23 15:13, Takashi Sakamoto wrote:
Hi,
Sorry for my late reply, but I'm in short summer vacation in my country side (less connections to internet). Would you please wait for any reaction within a few days.
Regards
Takashi Sakamoto
On Wed, Aug 16, 2023 at 03:05:36PM +0200, Michele Perrone wrote:
Dear Mr. Sakamoto,
since we are not discussing about the patch anymore, let me reply to our open threads in a separate message.
On 08/08/23 17:25, Takashi Sakamoto wrote:
As a policy to maintain current ALSA firewire stack, any code for control function is out of kernel land, thus your AVC function can not to be merged to Linux upstream as is.
I think the most convenient way is to provide source code for the AVC function to me. Then I re-implement it by Rust language for snd-dice-ctl-service program. As long as interpreting original code, we have no license issue for the new code.
That is very kind of you. You can now find our current AVC code in the following public repository (branch 'avc'): [1]https://github.com/weiss-engineering/snd-dice/tree/avc If you have questions about the code, also on the firmware side of things, feel free to ask.
But As a first step, I would like you to assist my support for DICE common controls in your models. I need the `clock caps` and `clock source names` fields to implement the common controls for your device in snd-firewire-ctl-services.
You can find the `clock caps` and `clock source names` fields for all our Firewire devices below. As I currently do not have access to our Firewire hardware except for MAN301, DAC202, and INT202, for the remaining devices I copied the fields from their latest firmware source code. -- MAN301 -- clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 aes3 wc internal clock source names: AES/EBU (XLR)\S/PDIF (RCA)\S/PDIF (TOS)\Unused\Unused\Unused\Unused\Word Clock (BNC)\Unused\Unused\Unused\Unused\Internal\\ -- DAC202 -- clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 aes3 wc arx1 internal clock source names: AES/EBU (XLR)\S/PDIF (RCA)\S/PDIF (TOSLINK)\Unused\Unused\Unused\Unused\Word Clock\Unused\Unused\Unused\Unused\Internal\\ -- INT202 -- clock caps: 44100 48000 88200 96000 176400 192000 arx1 internal clock source names: Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\U nused\Unused\Internal\\ -- INT203 -- clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 arx1 internal clock source names: AES/EBU (XLR)\S/PDIF (RCA)\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Un used\Internal\\ -- ADC2 -- clock caps: 44100 48000 88200 96000 176400 192000 aes1 clock source names: AES12\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Un used\Unused\Unused\\ -- DAC2/Minerva -- clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 aes3 arx1 internal clock source names: AES/EBU (XLR)\S/PDIF (RCA)\S/PDIF (TOSLINK)\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unuse d\Internal\\ -- Vesta -- clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 aes3 arx1 internal clock source names: AES/EBU (XLR)\S/PDIF (RCA)\S/PDIF (TOSLINK)\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unused\Unuse d\Internal\\ -- AFI1 -- clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 aes3 aes4 adat wc internal clock source names: AES12\AES34\AES56\AES78\Unused\ADAT\Unused\Word Clock\Unused\Unused\Unused\Unused\Internal\\
In my point of view, we need to decide license under which the file of configuration ROM image is public. I think CC0[0] is bette for our case.
I have created a pull request in takaswie/am-config-roms with three ROM images: MAN301, DAC202, INT202. I cannot extract the remaining images at the moment, because I do not have all Firewire devices available. I will add the remaining images as soon as I can get my hands on them.
Kind regards, Michele Perrone
参照
Hi, On Wed, Aug 16, 2023 at 03:05:36PM +0200, Michele Perrone wrote:
That is very kind of you. You can now find our current AVC code in the following public repository (branch 'avc'): [1]https://github.com/weiss-engineering/snd-dice/tree/avc If you have questions about the code, also on the firmware side of things, feel free to ask.
This is my first time to see implementation of 1394TA AV/C transaction for TCAT DICE ASICs. I know that TCAT provides own protocol and mLAN/OGT, however it is the third protocol, interesting. It takes me a bit time to read it, thus leave it next work.
You can find the `clock caps` and `clock source names` fields for all our Firewire devices below. As I currently do not have access to our Firewire hardware except for MAN301, DAC202, and INT202, for the remaining devices I copied the fields from their latest firmware source code.
Good. I filed a merge request for these models in common protocol implementation[1]. I note that the code is released under GPLv3, thus it shall include concern when included to your product. Please take care of it.
I have created a pull request in takaswie/am-config-roms with three ROM images: MAN301, DAC202, INT202. I cannot extract the remaining images at the moment, because I do not have all Firewire devices available. I will add the remaining images as soon as I can get my hands on them.
They are really useful, thanks. Later I deal with the request filed to it as well as alsa-gobject project. Well, as long as I print the content of configuration ROM[2] for MAN301, it includes two units. The first unit expresses AV/C device compliant to AV/C command set generic specification. The second unit expresses TCAT DICE protocol. I guess that the AV/C Vendor-dependent command is just implemented to MAN301 only. Is it right? If not, I would ask you to provide configuration ROM for the other models. Anyway, such device is likely undetected in current implementation of snd-dice-ctl-service due to the layout of configuration ROM[3]. Take me a bit time to solve it. ``` $ config-rom-pretty-printer < audio_and_music/dice/weiss-man301.img ROM header and bus information block ----------------------------------------------------------------- 1024 0404f4fa bus_info_length 4, crc_length 4, crc 62714 1028 31333934 bus_name "1394" 1032 e0008122 irmc 1, cmc 1, isc 1, bmc 0, pmc 0, cyc_clk_acc 0, max_rec 8 (512), max_rom 1, gen 2, spd 2 (S400) 1036 001c6a00 company_id 001c6a | 1040 02c000ca device_id 0046137546 | EUI-64 7997847626580170 root directory ----------------------------------------------------------------- 1044 00074103 directory_length 7, crc 16643 1048 03001c6a vendor 1052 81000010 --> descriptor leaf at 1116 1056 1700000b model 1060 81000017 --> descriptor leaf at 1152 1064 0c0087c0 node capabilities: per IEEE 1394 1068 d1000002 --> unit directory at 1076 1072 d1000006 --> unit directory at 1096 unit directory at 1076 ----------------------------------------------------------------- 1076 000421e1 directory_length 4, crc 8673 1080 1200a02d specifier id 1084 13010001 version 1088 1700000b model 1092 81000014 --> descriptor leaf at 1172 unit directory at 1096 ----------------------------------------------------------------- 1096 000473f8 directory_length 4, crc 29688 1100 12001c6a specifier id 1104 13000001 version 1108 1700000b model 1112 81000014 --> descriptor leaf at 1192 descriptor leaf at 1116 ----------------------------------------------------------------- 1116 0008decb leaf_length 8, crc 57035 1120 00000000 textual descriptor 1124 00000000 minimal ASCII 1128 57656973 "Weis" 1132 735f456e "s_En" 1136 67696e65 "gine" 1140 6572696e "erin" 1144 675f4c74 "g_Lt" 1148 642e0000 "d." descriptor leaf at 1152 ----------------------------------------------------------------- 1152 00041b75 leaf_length 4, crc 7029 1156 00000000 textual descriptor 1160 00000000 minimal ASCII 1164 4d414e5f "MAN_" 1168 33303100 "301" descriptor leaf at 1172 ----------------------------------------------------------------- 1172 00041b75 leaf_length 4, crc 7029 1176 00000000 textual descriptor 1180 00000000 minimal ASCII 1184 4d414e5f "MAN_" 1188 33303100 "301" descriptor leaf at 1192 ----------------------------------------------------------------- 1192 00041b75 leaf_length 4, crc 7029 1196 00000000 textual descriptor 1200 00000000 minimal ASCII 1204 4d414e5f "MAN_" 1208 33303100 "301" ``` [1] [PATCH 0/2] dice: add support for Weiss Engineering models https://github.com/alsa-project/snd-firewire-ctl-services/pull/175 [2] config-rom-pretty-printer is available in linux-firewire-utils v0.5.0 or later. https://git.kernel.org/pub/scm/utils/ieee1394/linux-firewire-utils.git/ [3] `DiceConfigRom` implementation for `ConfigRom` just handles the first unit in configuration ROM. https://github.com/alsa-project/snd-firewire-ctl-services/blob/master/protoc... Thanks Takashi Sakamoto
Hi Michele, Thanks for your contribution of configuration ROM for Weiss models[1]. I'm sorry for my little reaction but currently I'm working for Debian ITP to linux-firewire-utils package[2][3]. As a quick glance, all of configuration ROMs except for Weiss MAN301 include single unit directory, while the exception includes two unit directories; 1394TA AV/C protocol and TCAT protocol. It means that the vendor-dependent AV/C command[4] is implemented in MAN301, but not in the others. Then I would like to figure out whether it is correct or not. If it is unique for MAN301, the implementation of control service can be simpler to support the command just for MAN301. [1] https://github.com/takaswie/am-config-roms/pull/5 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050551 [3] https://mentors.debian.net/package/linux-firewire-utils/ [4] https://github.com/weiss-engineering/snd-dice/blob/avc/dice-avc.c Regards Takashi Sakamoto
Hi Takashi, Glad that we could be of help. We checked this on the firmware side and yes, we can confirm that the Weiss MAN301 is the only device with AV/C protocol (using vendor dependent commands). We are deploying a small set of commands in order to probe and control the parameters on the MAN301: WEISS_CMD_ID_DEV_CONST: probe the number of parameters WEISS_CMD_ID_PARAM_OP: read/write to a parameter WEISS_CMD_ID_PARAM_INFO: read parameter info (index, type, iface type, name) WEISS_CMD_ID_ENUM_ITEM_INFO: read parameter enum type info This allows us to populate and control snd-control instances that represent the device's featured parameters [1]. How would you like to proceed for `snd-firewire-ctl-services`? We can start by giving you the output of `amixer contents` for the MAN301, so you see all the controls and their possible values (see below). Let us know if there's any additional information we can provide. Kind regards, Rolf Anderegg [1] https://github.com/weiss-engineering/snd-dice/blob/avc/dice-avc.c -- $ amixer contents numid=3,iface=CARD,name='Dual Wire Mode Switch' ; type=BOOLEAN,access=rw------,values=1 : values=off numid=4,iface=CARD,name='Dual Wire Word Clock Half Rate Switch' ; type=BOOLEAN,access=rw------,values=1 : values=off numid=1,iface=CARD,name='Sync source' ; type=ENUMERATED,access=rw------,values=1,items=13 ; Item #0 'AES1' ; Item #1 'AES2' ; Item #2 'AES3' ; Item #3 'AES4' ; Item #4 'AES' ; Item #5 'ADAT' ; Item #6 'TDIF' ; Item #7 'Wordclock' ; Item #8 'ARX1' ; Item #9 'ARX2' ; Item #10 'ARX3' ; Item #11 'ARX4' ; Item #12 'Internal' : values=2 numid=10,iface=MIXER,name='DAC::Analog Output Level' ; type=ENUMERATED,access=rw------,values=1,items=4 ; Item #0 '0 dB' ; Item #1 '-10 dB' ; Item #2 '-20 dB' ; Item #3 '-30 dB' : values=1 numid=8,iface=MIXER,name='DAC::DAC Filter Type' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'A' ; Item #1 'B' : values=0 numid=9,iface=MIXER,name='DAC::DAC Output Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=7,iface=MIXER,name='DAC::DAC Polarity Inversion Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=off numid=2,iface=MIXER,name='Digital Input Capture Route' ; type=ENUMERATED,access=rw------,values=1,items=3 ; Item #0 'AES/EBU (XLR)' ; Item #1 'S/PDIF (RCA)' ; Item #2 'S/PDIF (TOS)' : values=2 numid=6,iface=MIXER,name='RCA::RCA Output Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=5,iface=MIXER,name='XLR::XLR Output Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on On 31.08.23 15:28, Takashi Sakamoto wrote:
Hi Michele,
Thanks for your contribution of configuration ROM for Weiss models[1]. I'm sorry for my little reaction but currently I'm working for Debian ITP to linux-firewire-utils package[2][3].
As a quick glance, all of configuration ROMs except for Weiss MAN301 include single unit directory, while the exception includes two unit directories; 1394TA AV/C protocol and TCAT protocol. It means that the vendor-dependent AV/C command[4] is implemented in MAN301, but not in the others. Then I would like to figure out whether it is correct or not. If it is unique for MAN301, the implementation of control service can be simpler to support the command just for MAN301.
[1] https://github.com/takaswie/am-config-roms/pull/5 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050551 [3] https://mentors.debian.net/package/linux-firewire-utils/ [4] https://github.com/weiss-engineering/snd-dice/blob/avc/dice-avc.c
Regards
Takashi Sakamoto
Hi Rolf, On Mon, Sep 04, 2023 at 06:00:24PM +0200, Rolf Anderegg wrote:
Hi Takashi,
Glad that we could be of help. We checked this on the firmware side and yes, we can confirm that the Weiss MAN301 is the only device with AV/C protocol (using vendor dependent commands).
OK. It is good firmware design to make snd-dice-ctl-service simpler.
We are deploying a small set of commands in order to probe and control the parameters on the MAN301:
WEISS_CMD_ID_DEV_CONST: probe the number of parameters
WEISS_CMD_ID_PARAM_OP: read/write to a parameter
WEISS_CMD_ID_PARAM_INFO: read parameter info (index, type, iface type, name)
WEISS_CMD_ID_ENUM_ITEM_INFO: read parameter enum type info
This allows us to populate and control snd-control instances that represent the device's featured parameters [1].
How would you like to proceed for `snd-firewire-ctl-services`? We can start by giving you the output of `amixer contents` for the MAN301, so you see all the controls and their possible values (see below).
Great. In my current plan for snd-dice-ctl-service, action items would be enumerated in below: 1. Add support for all of models except for MA301 (need additional work to current MR to exclude MA301) 2. implement the vendor dependent command to `firewire-dice-protocols` crate[2] with dependency on `ta1394_avc_general` crate[3] 3. implement the control primitives to `firewire-dice-protocols` in the fasion of hard-code 4. Add support for MA301 The reason of hard-code against your implementation in dice-avc.c is to express hardware specification in code. FireWire audio devices are nowadays not updated anymore, and I think the explicit control primitives is helpful to remaining users. [1] https://github.com/alsa-project/snd-firewire-ctl-services/pull/175 [2] https://crates.io/crates/firewire-dice-protocols [3] https://docs.rs/ta1394-avc-general/latest/ta1394_avc_general/
Let us know if there's any additional information we can provide.
If the control primitives have been changed (newly added or abandoned) between several firmware versions, I would like you to inform it to me.
Kind regards, Rolf Anderegg
[1] https://github.com/weiss-engineering/snd-dice/blob/avc/dice-avc.c
Thanks for your delivery of useful information for Weiss models. It is my pleasure to maintain Linux systems to use them for 6 more years. Regards Takashi Sakamoto
-- $ amixer contents numid=3,iface=CARD,name='Dual Wire Mode Switch' ; type=BOOLEAN,access=rw------,values=1 : values=off numid=4,iface=CARD,name='Dual Wire Word Clock Half Rate Switch' ; type=BOOLEAN,access=rw------,values=1 : values=off numid=1,iface=CARD,name='Sync source' ; type=ENUMERATED,access=rw------,values=1,items=13 ; Item #0 'AES1' ; Item #1 'AES2' ; Item #2 'AES3' ; Item #3 'AES4' ; Item #4 'AES' ; Item #5 'ADAT' ; Item #6 'TDIF' ; Item #7 'Wordclock' ; Item #8 'ARX1' ; Item #9 'ARX2' ; Item #10 'ARX3' ; Item #11 'ARX4' ; Item #12 'Internal' : values=2 numid=10,iface=MIXER,name='DAC::Analog Output Level' ; type=ENUMERATED,access=rw------,values=1,items=4 ; Item #0 '0 dB' ; Item #1 '-10 dB' ; Item #2 '-20 dB' ; Item #3 '-30 dB' : values=1 numid=8,iface=MIXER,name='DAC::DAC Filter Type' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'A' ; Item #1 'B' : values=0 numid=9,iface=MIXER,name='DAC::DAC Output Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=7,iface=MIXER,name='DAC::DAC Polarity Inversion Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=off numid=2,iface=MIXER,name='Digital Input Capture Route' ; type=ENUMERATED,access=rw------,values=1,items=3 ; Item #0 'AES/EBU (XLR)' ; Item #1 'S/PDIF (RCA)' ; Item #2 'S/PDIF (TOS)' : values=2 numid=6,iface=MIXER,name='RCA::RCA Output Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=5,iface=MIXER,name='XLR::XLR Output Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on
On 31.08.23 15:28, Takashi Sakamoto wrote:
Hi Michele,
Thanks for your contribution of configuration ROM for Weiss models[1]. I'm sorry for my little reaction but currently I'm working for Debian ITP to linux-firewire-utils package[2][3].
As a quick glance, all of configuration ROMs except for Weiss MAN301 include single unit directory, while the exception includes two unit directories; 1394TA AV/C protocol and TCAT protocol. It means that the vendor-dependent AV/C command[4] is implemented in MAN301, but not in the others. Then I would like to figure out whether it is correct or not. If it is unique for MAN301, the implementation of control service can be simpler to support the command just for MAN301.
[1] https://github.com/takaswie/am-config-roms/pull/5 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050551 [3] https://mentors.debian.net/package/linux-firewire-utils/ [4] https://github.com/weiss-engineering/snd-dice/blob/avc/dice-avc.c
Regards
Takashi Sakamoto
Hi Takashi, On 05.09.23 03:20, Takashi Sakamoto wrote:
Hi Rolf,
On Mon, Sep 04, 2023 at 06:00:24PM +0200, Rolf Anderegg wrote:
Hi Takashi,
Glad that we could be of help. We checked this on the firmware side and yes, we can confirm that the Weiss MAN301 is the only device with AV/C protocol (using vendor dependent commands).
OK. It is good firmware design to make snd-dice-ctl-service simpler.
We are deploying a small set of commands in order to probe and control the parameters on the MAN301:
WEISS_CMD_ID_DEV_CONST: probe the number of parameters
WEISS_CMD_ID_PARAM_OP: read/write to a parameter
WEISS_CMD_ID_PARAM_INFO: read parameter info (index, type, iface type, name)
WEISS_CMD_ID_ENUM_ITEM_INFO: read parameter enum type info
This allows us to populate and control snd-control instances that represent the device's featured parameters [1].
How would you like to proceed for `snd-firewire-ctl-services`? We can start by giving you the output of `amixer contents` for the MAN301, so you see all the controls and their possible values (see below).
Great. In my current plan for snd-dice-ctl-service, action items would be enumerated in below:
1. Add support for all of models except for MA301 (need additional work to current MR to exclude MA301) 2. implement the vendor dependent command to `firewire-dice-protocols` crate[2] with dependency on `ta1394_avc_general` crate[3] 3. implement the control primitives to `firewire-dice-protocols` in the fasion of hard-code 4. Add support for MA301
The reason of hard-code against your implementation in dice-avc.c is to express hardware specification in code. FireWire audio devices are nowadays not updated anymore, and I think the explicit control primitives is helpful to remaining users.
Yes, we agree that it's appropriate to hardcode the currently available controls. In that case you will only be using the following vendor specific command to write parameter values [1][2]: WEISS_CMD_ID_PARAM_OP: read/write to a parameter
[1] https://github.com/alsa-project/snd-firewire-ctl-services/pull/175 [2] https://crates.io/crates/firewire-dice-protocols [3] https://docs.rs/ta1394-avc-general/latest/ta1394_avc_general/
Let us know if there's any additional information we can provide.
If the control primitives have been changed (newly added or abandoned) between several firmware versions, I would like you to inform it to me.
Thank you, we would inform you of any changes. But I doubt that that will ever be necessary.
Kind regards, Rolf Anderegg
[1] https://github.com/weiss-engineering/snd-dice/blob/avc/dice-avc.c
Thanks for your delivery of useful information for Weiss models. It is my pleasure to maintain Linux systems to use them for 6 more years.
Thank you Takashi, we highly appreciate your engagement. Best regards, Rolf Anderegg [1] https://github.com/weiss-engineering/snd-dice/blob/avc/dice-avc.c#L135 [2] https://github.com/weiss-engineering/snd-dice/blob/avc/dice-avc.c#L201
Regards
Takashi Sakamoto
-- $ amixer contents numid=3,iface=CARD,name='Dual Wire Mode Switch' ; type=BOOLEAN,access=rw------,values=1 : values=off numid=4,iface=CARD,name='Dual Wire Word Clock Half Rate Switch' ; type=BOOLEAN,access=rw------,values=1 : values=off numid=1,iface=CARD,name='Sync source' ; type=ENUMERATED,access=rw------,values=1,items=13 ; Item #0 'AES1' ; Item #1 'AES2' ; Item #2 'AES3' ; Item #3 'AES4' ; Item #4 'AES' ; Item #5 'ADAT' ; Item #6 'TDIF' ; Item #7 'Wordclock' ; Item #8 'ARX1' ; Item #9 'ARX2' ; Item #10 'ARX3' ; Item #11 'ARX4' ; Item #12 'Internal' : values=2 numid=10,iface=MIXER,name='DAC::Analog Output Level' ; type=ENUMERATED,access=rw------,values=1,items=4 ; Item #0 '0 dB' ; Item #1 '-10 dB' ; Item #2 '-20 dB' ; Item #3 '-30 dB' : values=1 numid=8,iface=MIXER,name='DAC::DAC Filter Type' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'A' ; Item #1 'B' : values=0 numid=9,iface=MIXER,name='DAC::DAC Output Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=7,iface=MIXER,name='DAC::DAC Polarity Inversion Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=off numid=2,iface=MIXER,name='Digital Input Capture Route' ; type=ENUMERATED,access=rw------,values=1,items=3 ; Item #0 'AES/EBU (XLR)' ; Item #1 'S/PDIF (RCA)' ; Item #2 'S/PDIF (TOS)' : values=2 numid=6,iface=MIXER,name='RCA::RCA Output Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=5,iface=MIXER,name='XLR::XLR Output Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on
On 31.08.23 15:28, Takashi Sakamoto wrote:
Hi Michele,
Thanks for your contribution of configuration ROM for Weiss models[1]. I'm sorry for my little reaction but currently I'm working for Debian ITP to linux-firewire-utils package[2][3].
As a quick glance, all of configuration ROMs except for Weiss MAN301 include single unit directory, while the exception includes two unit directories; 1394TA AV/C protocol and TCAT protocol. It means that the vendor-dependent AV/C command[4] is implemented in MAN301, but not in the others. Then I would like to figure out whether it is correct or not. If it is unique for MAN301, the implementation of control service can be simpler to support the command just for MAN301.
[1] https://github.com/takaswie/am-config-roms/pull/5 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050551 [3] https://mentors.debian.net/package/linux-firewire-utils/ [4] https://github.com/weiss-engineering/snd-dice/blob/avc/dice-avc.c
Regards
Takashi Sakamoto
Hi Rolf and Michele, I'm working to fulfill hardware database of systemd project[1] for Weiss models with received collection of configuration ROM, then have some issues. I would ask you to provide information to solve them. This is the table of the value of model ID field and model name. snd-dice am-config-roms systemd hwdb DAC202 0x000007 0x000007 0x000007 DAC202(Maya) 0x000008 not yet not yet MAN301 0x00000b 0x00000b not yet INT202 0x000006 0x000006 0x000006 INT203 0x00000a 0x000006 (?) not yet ADC2 0x000001 0x000001 0x000001 DAC2/Minerva 0x000003 0x000003 0x000003 Vesta 0x000002 0x000002 0x000002 AFI1 0x000004 0x000004 0x000004 DAC1 not yet (?) not yet (?) 0x000005 I have two issues. 1. INT203 The modalias table in ALSA dice driver[2] includes 0x00000a for the model, while the configuration ROM includes 0x000006. Michele wrote commit comment for it[3]: ``` Note: the INT203 presents itself as INT202, because the firmware running on the two devices is the same. The difference between the two lies in a jumper setting inside the device. ``` In my opinion, there are multiple hardawre revisions for the model. 2. DAC1 When committing to hardware database of systemd project[4], I referred to libffado2 configuration file[5]. It includes `DAC1` with model ID 0x000005, while it is neither found in ALSA dice driver nor the collection of configuration ROM. As long as searching DAC1 in website of Weiss Engineering, I can see DAC1-mk3 has option card for IEEE 1394 connection[6]. Would I request you to provide information about the model? [1] `hwdb.d/80-ieee1394-unit-function.hwdb` in systemd project [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/soun... [3] https://github.com/takaswie/am-config-roms/commit/e6717b3cbb4a [4] https://github.com/systemd/systemd/commit/ff1cb7b9393ac [5] http://subversion.ffado.org/browser/trunk/libffado/configuration [6] https://weiss.ch/products/pro-audio/dac1-mk3/ Regards Takashi Sakamoto
Hi Takashi, sorry for our late reply. 1. INT203 Yes, we can confirm that the latest INT203 firmware has the model ID 0x6, same like the INT202. Older INT203 firmware has the model ID 0xa. At the snd-dice module level, there is obviously no difference, because the hardcoded capabilities (modes/rates) are the same. The only drawback is that when connecting the INT202, users see two channels of input. But maybe this could be easily solved with an alsa card profile. 2. DAC1 The DAC1 with model ID 0x5 that you found in the libffado configuration file is not same the DAC1 that you found on our website. That was an experimental device which included an embedded computing board, connected via FireWire to an internal DICE-based soundcard. This device was never released to the market, so I suggest discarding this entry. On the other hand, the DAC1 from our website was indeed sold with a FireWire option. However, this is just and INT203 embedded inside the DAC1, with no special ROM. This means that when connecting the DAC1 via FireWire, it will present itself like an INT203. I hope this answers all your question, otherwise let us know! Kind regards, Michele Perrone On 06/09/23 01:54, Takashi Sakamoto wrote:
Hi Rolf and Michele,
I'm working to fulfill hardware database of systemd project[1] for Weiss models with received collection of configuration ROM, then have some issues. I would ask you to provide information to solve them.
This is the table of the value of model ID field and model name.
snd-dice am-config-roms systemd hwdb DAC202 0x000007 0x000007 0x000007 DAC202(Maya) 0x000008 not yet not yet MAN301 0x00000b 0x00000b not yet INT202 0x000006 0x000006 0x000006 INT203 0x00000a 0x000006 (?) not yet ADC2 0x000001 0x000001 0x000001 DAC2/Minerva 0x000003 0x000003 0x000003 Vesta 0x000002 0x000002 0x000002 AFI1 0x000004 0x000004 0x000004 DAC1 not yet (?) not yet (?) 0x000005
I have two issues.
1. INT203
The modalias table in ALSA dice driver[2] includes 0x00000a for the model, while the configuration ROM includes 0x000006. Michele wrote commit comment for it[3]:
``` Note: the INT203 presents itself as INT202, because the firmware running on the two devices is the same. The difference between the two lies in a jumper setting inside the device. ```
In my opinion, there are multiple hardawre revisions for the model.
2. DAC1
When committing to hardware database of systemd project[4], I referred to libffado2 configuration file[5]. It includes `DAC1` with model ID 0x000005, while it is neither found in ALSA dice driver nor the collection of configuration ROM. As long as searching DAC1 in website of Weiss Engineering, I can see DAC1-mk3 has option card for IEEE 1394 connection[6]. Would I request you to provide information about the model?
[1] `hwdb.d/80-ieee1394-unit-function.hwdb` in systemd project [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/soun... [3] https://github.com/takaswie/am-config-roms/commit/e6717b3cbb4a [4] https://github.com/systemd/systemd/commit/ff1cb7b9393ac [5] http://subversion.ffado.org/browser/trunk/libffado/configuration [6] https://weiss.ch/products/pro-audio/dac1-mk3/
Regards
Takashi Sakamoto
Hi Michele, On Sat, Sep 16, 2023 at 11:18:39AM +0200, Michele Perrone wrote:
Hi Takashi,
sorry for our late reply.
1. INT203
Yes, we can confirm that the latest INT203 firmware has the model ID 0x6, same like the INT202. Older INT203 firmware has the model ID 0xa.
At the snd-dice module level, there is obviously no difference, because the hardcoded capabilities (modes/rates) are the same.
The only drawback is that when connecting the INT202, users see two channels of input. But maybe this could be easily solved with an alsa card profile.
2. DAC1
The DAC1 with model ID 0x5 that you found in the libffado configuration file is not same the DAC1 that you found on our website. That was an experimental device which included an embedded computing board, connected via FireWire to an internal DICE-based soundcard. This device was never released to the market, so I suggest discarding this entry.
On the other hand, the DAC1 from our website was indeed sold with a FireWire option. However, this is just and INT203 embedded inside the DAC1, with no special ROM. This means that when connecting the DAC1 via FireWire, it will present itself like an INT203.
I hope this answers all your question, otherwise let us know!
Kind regards, Michele Perrone
Thanks for your clarification! Now I figured out and post merge request to systemd project. * https://github.com/systemd/systemd/pull/29197 Thanks Takashi Sakamoto
On 06/09/23 01:54, Takashi Sakamoto wrote:
Hi Rolf and Michele,
I'm working to fulfill hardware database of systemd project[1] for Weiss models with received collection of configuration ROM, then have some issues. I would ask you to provide information to solve them.
This is the table of the value of model ID field and model name.
snd-dice am-config-roms systemd hwdb DAC202 0x000007 0x000007 0x000007 DAC202(Maya) 0x000008 not yet not yet MAN301 0x00000b 0x00000b not yet INT202 0x000006 0x000006 0x000006 INT203 0x00000a 0x000006 (?) not yet ADC2 0x000001 0x000001 0x000001 DAC2/Minerva 0x000003 0x000003 0x000003 Vesta 0x000002 0x000002 0x000002 AFI1 0x000004 0x000004 0x000004 DAC1 not yet (?) not yet (?) 0x000005
I have two issues.
1. INT203
The modalias table in ALSA dice driver[2] includes 0x00000a for the model, while the configuration ROM includes 0x000006. Michele wrote commit comment for it[3]:
``` Note: the INT203 presents itself as INT202, because the firmware running on the two devices is the same. The difference between the two lies in a jumper setting inside the device. ```
In my opinion, there are multiple hardawre revisions for the model.
2. DAC1
When committing to hardware database of systemd project[4], I referred to libffado2 configuration file[5]. It includes `DAC1` with model ID 0x000005, while it is neither found in ALSA dice driver nor the collection of configuration ROM. As long as searching DAC1 in website of Weiss Engineering, I can see DAC1-mk3 has option card for IEEE 1394 connection[6]. Would I request you to provide information about the model?
[1] `hwdb.d/80-ieee1394-unit-function.hwdb` in systemd project [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/soun... [3] https://github.com/takaswie/am-config-roms/commit/e6717b3cbb4a [4] https://github.com/systemd/systemd/commit/ff1cb7b9393ac [5] http://subversion.ffado.org/browser/trunk/libffado/configuration [6] https://weiss.ch/products/pro-audio/dac1-mk3/
Regards
Takashi Sakamoto
Hi Takashi, I'm encountering a strange issue when working with our MAN301 device and external clock sync. I am currently using our kernel-side AV/C code to switch between clock sources[1]. When I switch to an external clock source, the user-space ALSA code is not able to change the clock rate anymore. This means that I cannot switch to the external clock rate that the DICE is currently locked onto. Here is a practical example / steps to reproduce: 1. Set the clock source to internal and the clock rate to an arbitrary value (e.g. 44100) from the user-space. The relevant sections of /proc/asound/card0/firewire/dice will then look like this: global: owner: ffc0:000100000000 notification: 00000040 nick name: Weiss MAN301 clock select: internal 44100 enable: 0 status: locked 44100 ext status: 00010001 sample rate: 44100 version: 1.0.12.0 clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 aes3 wc internal clock source names: AES/EBU (XLR)\S/PDIF (RCA)\S/PDIF (TOS)\Unused\Unused\Unused\Unused\Word Clock (BNC)\Unused\Unused\Unused\Unused\Internal\\ ext status: clock source: internal locked: 1 rate: 44100 2. Set the clock source to external (e.g. aes1) through AV/C command[1] and connect a digital input with a different clock rate (e.g. 48000). Now the two sections of will look like this. You can see that the external source status is "locked". global: owner: ffc0:000100000000 notification: 00000010 nick name: Weiss MAN301 clock select: aes1 44100 enable: 0 status: unlocked 44100 ext status: 00010001 sample rate: 44100 version: 1.0.12.0 clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 aes3 wc internal clock source names: AES/EBU (XLR)\S/PDIF (RCA)\S/PDIF (TOS)\Unused\Unused\Unused\Unused\Word Clock (BNC)\Unused\Unused\Unused\Unused\Internal\\ ext status: clock source: aes1 locked: 1 rate: 48000 3. Try to set the clock rate to 48000 from user-space ALSA. This will fail. Only 44100 can be used. Example: $ aplay --disable-resample 48000_S32.wav Playing WAVE '48000_S32.wav' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo Warning: rate is not accurate (requested = 48000Hz, got = 44100Hz) The current workaround is going back to the internal clock source, switch the clock rate to the one reported in the "ext status" section, and then go back to the external clock source. This however does not feel quite right. I will be very grateful for any suggestion from your side. Thank you and kind regards, Michele Perrone [1]https://github.com/weiss-engineering/snd-dice/blob/5a95496c0666048bc5bc8c07b...
Hi Michele, On Mon, Sep 18, 2023 at 03:19:10PM +0200, Michele Perrone wrote:
Hi Takashi,
I'm encountering a strange issue when working with our MAN301 device and external clock sync. I am currently using our kernel-side AV/C code to switch between clock sources[1].
When I switch to an external clock source, the user-space ALSA code is not able to change the clock rate anymore. This means that I cannot switch to the external clock rate that the DICE is currently locked onto.
Here is a practical example / steps to reproduce:
1. Set the clock source to internal and the clock rate to an arbitrary value (e.g. 44100) from the user-space. The relevant sections of /proc/asound/card0/firewire/dice will then look like this:
global: owner: ffc0:000100000000 notification: 00000040 nick name: Weiss MAN301 clock select: internal 44100 enable: 0 status: locked 44100 ext status: 00010001 sample rate: 44100 version: 1.0.12.0 clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 aes3 wc internal clock source names: AES/EBU (XLR)\S/PDIF (RCA)\S/PDIF (TOS)\Unused\Unused\Unused\Unused\Word Clock (BNC)\Unused\Unused\Unused\Unused\Internal\\
ext status: clock source: internal locked: 1 rate: 44100
2. Set the clock source to external (e.g. aes1) through AV/C command[1] and connect a digital input with a different clock rate (e.g. 48000). Now the two sections of will look like this. You can see that the external source status is "locked".
global: owner: ffc0:000100000000 notification: 00000010 nick name: Weiss MAN301 clock select: aes1 44100 enable: 0 status: unlocked 44100 ext status: 00010001 sample rate: 44100 version: 1.0.12.0 clock caps: 44100 48000 88200 96000 176400 192000 aes1 aes2 aes3 wc internal clock source names: AES/EBU (XLR)\S/PDIF (RCA)\S/PDIF (TOS)\Unused\Unused\Unused\Unused\Word Clock (BNC)\Unused\Unused\Unused\Unused\Internal\\
ext status: clock source: aes1 locked: 1 rate: 48000
3. Try to set the clock rate to 48000 from user-space ALSA. This will fail. Only 44100 can be used. Example:
$ aplay --disable-resample 48000_S32.wav Playing WAVE '48000_S32.wav' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo Warning: rate is not accurate (requested = 48000Hz, got = 44100Hz)
The current workaround is going back to the internal clock source, switch the clock rate to the one reported in the "ext status" section, and then go back to the external clock source. This however does not feel quite right.
I will be very grateful for any suggestion from your side.
I programmed ALSA dice driver to behave like that. The driver configures the target device for sampling rate which ALSA PCM application expects when the device uses internal source of clock. When the device is configured to use external source of clock, the driver adds constrains to ALSA PCM hardware configuration so that the application works with current sampling rate configured in device. In your case: clk src ext rate rate in device appl avail rates --------- ---------- ---------------- ------------------ Internal - 44.1 KHz 44.1-192.0 kHz External 48.0 kHz 44.1 kHz 44.1 kHz For the case of external source of clock, you need to configure the sampling rate in device by your hand, by accesing to GLOBAL_CLOCK_SELECT offset in global section of TCAT protocol. As a result: clk src ext rate rate in device appl avail rates --------- ---------- ---------------- ------------------ Internal - 44.1 KHz 44.1-192.0 kHz External 48.0 kHz 48.0 kHz (*) 48.0 kHz I note that the device's behaviour of the external source scenario differs depending on models even if the pair of models uses the same Dice ASIC. I guess that firmware version brings such chaos.
Thank you and kind regards, Michele Perrone
[1]https://github.com/weiss-engineering/snd-dice/blob/5a95496c0666048bc5bc8c07b...
Regards Takashi Sakamoto
Hi Michele Perrone, Michele Perrone, I restart my work to support Weiss models[1] as I have enough time after some tasks. After implementing control elements for your MAN301, I have some questions about internal routing. Would I ask your advices about them? I think the model has below inputs/outputs. * inputs * spdif-opt-input-1/2 * spdif-coax-input-1/2 * aesebu-xlr-input-1/2 * stream-input-1/2 * outputs: * stream-output-1/2 * spdif-coax-output-1/2 * aesebu-xlr-output-1/2 * analog-xlr-output-1/2 * analog-coax-output-1/2 And at present I guess its internal routing is like[2]: ``` spdif-opt-input-1/2 ---+ spdif-coax-input-1/2 --(or)--> digital-input-1/2 -----------------> stream-output-1/2 aesebu-xlr-input-1/2 ---+ | v stream-input-1/2 --------------------(or)--+----------------------> spdif-coax-output-1/2 +----------------------> aesebu-xlr-output-1/2 +--analog-output-1/2 --> analog-xlr-output-1/2 +-----------> analog-coax-output-1/2 ``` Then I have some questions. 1. The signal source designated for stream-output-1/2 I think it is any type of digital input designated by control element "Digital Input Capture Route", or source ID block which generates silence. 2. The signal sources designated for the outputs According to the manual of MAN301, the sources are selectable somehow. There are two ways at least for pre-amp and player modes. I guess that any interface is defined to configure internal router for the purpose. [1] https://github.com/alsa-project/snd-firewire-ctl-services/tree/topic/weiss-s... [2] https://github.com/alsa-project/snd-firewire-ctl-services/blob/topic/weiss-s... Thanks Takashi Sakamoto
Hi, On Sun, Jan 21, 2024 at 11:07:48PM +0900, Takashi Sakamoto wrote:
Then I have some questions.
1. The signal source designated for stream-output-1/2 I think it is any type of digital input designated by control element "Digital Input Capture Route", or source ID block which generates silence.
2. The signal sources designated for the outputs According to the manual of MAN301, the sources are selectable somehow. There are two ways at least for pre-amp and player modes. I guess that any interface is defined to configure internal router for the purpose.
[1] https://github.com/alsa-project/snd-firewire-ctl-services/tree/topic/weiss-s... [2] https://github.com/alsa-project/snd-firewire-ctl-services/blob/topic/weiss-s...
I have an extra question. 3. store/load router configuration In my understanding, TCAT DICE firmware stores configurations per three rate modes. When switching between the rate modes, corresponding configuration is loaded automatically. In the case of MAN301, the configurations done via AV/C command is loaded in the way? Regards Takashi Sakamoto
Ping? On Sun, Jan 21, 2024 at 11:30:48PM +0900, Takashi Sakamoto wrote:
Hi,
On Sun, Jan 21, 2024 at 11:07:48PM +0900, Takashi Sakamoto wrote:
Then I have some questions.
1. The signal source designated for stream-output-1/2 I think it is any type of digital input designated by control element "Digital Input Capture Route", or source ID block which generates silence.
2. The signal sources designated for the outputs According to the manual of MAN301, the sources are selectable somehow. There are two ways at least for pre-amp and player modes. I guess that any interface is defined to configure internal router for the purpose.
[1] https://github.com/alsa-project/snd-firewire-ctl-services/tree/topic/weiss-s... [2] https://github.com/alsa-project/snd-firewire-ctl-services/blob/topic/weiss-s...
I have an extra question.
3. store/load router configuration
In my understanding, TCAT DICE firmware stores configurations per three rate modes. When switching between the rate modes, corresponding configuration is loaded automatically. In the case of MAN301, the configurations done via AV/C command is loaded in the way?
Regards
Takashi Sakamoto
Hi Takashi, I'm very sorry for my late reply. You are correct about the available input and outputs, but I'm not sure that I understand your routing scheme very well. * The currently active digital input can be selected with "Digital Input Capture Route", like this: o AES/EBU: amixer -c 0 cset numid=3,iface=MIXER,name='Digital Input Capture Route' 0 o S/PDIF RCA: amixer -c 0 cset numid=3,iface=MIXER,name='Digital Input Capture Route' 1 o S/PDIF toslink: amixer -c 0 cset numid=3,iface=MIXER,name='Digital Input Capture Route' 2 When playing sound from stream input, it doesn't make any difference which one the above is currently selected. * The clock can be selected independently from the current input with AV/C [1]. * The 2-channel output can be routed to all the digital and analog outputs simultaneously (but analog outputs are only available if the DAC is connected). One can choose which outputs are active or not with the "Output Playback Switch": o AES/EBU on: amixer -c 0 cset numid=6,iface=MIXER,name='XLR::XLR Output Playback Switch' 1 AES/EBU off: amixer -c 0 cset numid=6,iface=MIXER,name='XLR::XLR Output Playback Switch' 0 o S/PDIF RCA on: amixer -c 0 cset numid=7,iface=MIXER,name='RCA::RCA Output Playback Switch' 1 S/PDIF RCA off: amixer -c 0 cset numid=7,iface=MIXER,name='RCA::RCA Output Playback Switch' 0 o DAC on: amixer -c 0 cset numid=10,iface=MIXER,name='DAC::DAC Output Playback Switch' 1 DAC off: amixer -c 0 cset numid=10,iface=MIXER,name='DAC::DAC Output Playback Switch' 0 * There is no hardware mixer capability, i.e. the inputs cannot be routed directly to the outputs. Our preamp mode works like this: 1. A digital input source is selected with AV/C (Toslink, or RCA, or XLR), i.e. with "Digital Input Capture Route" 2. Clock input source is set to the same as audio input source with AV/C [1] 3. DICE clock rate is set to external clock rate [2] 4. A simple 2-channel ALSA loopback with digital volume control is created between input and output I hope this answers your questions, otherwise please let me know. Kind regards, Michele Perrone [1] https://github.com/weiss-engineering/snd-dice/blob/avc/dice-avc.c#L474 [2] https://github.com/weiss-engineering/snd-dice/blob/avc/dice-avc.c#L549 On 21/01/24 15:07, Takashi Sakamoto wrote:
Hi Michele Perrone, Michele Perrone,
I restart my work to support Weiss models[1] as I have enough time after some tasks. After implementing control elements for your MAN301, I have some questions about internal routing. Would I ask your advices about them?
I think the model has below inputs/outputs.
* inputs * spdif-opt-input-1/2 * spdif-coax-input-1/2 * aesebu-xlr-input-1/2 * stream-input-1/2 * outputs: * stream-output-1/2 * spdif-coax-output-1/2 * aesebu-xlr-output-1/2 * analog-xlr-output-1/2 * analog-coax-output-1/2
And at present I guess its internal routing is like[2]:
``` spdif-opt-input-1/2 ---+ spdif-coax-input-1/2 --(or)--> digital-input-1/2 -----------------> stream-output-1/2 aesebu-xlr-input-1/2 ---+ | v stream-input-1/2 --------------------(or)--+----------------------> spdif-coax-output-1/2 +----------------------> aesebu-xlr-output-1/2 +--analog-output-1/2 --> analog-xlr-output-1/2 +-----------> analog-coax-output-1/2 ```
Then I have some questions.
1. The signal source designated for stream-output-1/2 I think it is any type of digital input designated by control element "Digital Input Capture Route", or source ID block which generates silence.
2. The signal sources designated for the outputs According to the manual of MAN301, the sources are selectable somehow. There are two ways at least for pre-amp and player modes. I guess that any interface is defined to configure internal router for the purpose.
[1]https://github.com/alsa-project/snd-firewire-ctl-services/tree/topic/weiss-s... [2]https://github.com/alsa-project/snd-firewire-ctl-services/blob/topic/weiss-s...
Thanks
Takashi Sakamoto
Hi Michele, Thanks for your reply. On Mon, Feb 26, 2024 at 05:06:12PM +0100, Michele Perrone wrote:
You are correct about the available input and outputs, but I'm not sure that I understand your routing scheme very well.
* The currently active digital input can be selected with "Digital Input Capture Route", like this: o AES/EBU: amixer -c 0 cset numid=3,iface=MIXER,name='Digital Input Capture Route' 0 o S/PDIF RCA: amixer -c 0 cset numid=3,iface=MIXER,name='Digital Input Capture Route' 1 o S/PDIF toslink: amixer -c 0 cset numid=3,iface=MIXER,name='Digital Input Capture Route' 2 When playing sound from stream input, it doesn't make any difference which one the above is currently selected. * The clock can be selected independently from the current input with AV/C [1]. * The 2-channel output can be routed to all the digital and analog outputs simultaneously (but analog outputs are only available if the DAC is connected). One can choose which outputs are active or not with the "Output Playback Switch": o AES/EBU on: amixer -c 0 cset numid=6,iface=MIXER,name='XLR::XLR Output Playback Switch' 1 AES/EBU off: amixer -c 0 cset numid=6,iface=MIXER,name='XLR::XLR Output Playback Switch' 0 o S/PDIF RCA on: amixer -c 0 cset numid=7,iface=MIXER,name='RCA::RCA Output Playback Switch' 1 S/PDIF RCA off: amixer -c 0 cset numid=7,iface=MIXER,name='RCA::RCA Output Playback Switch' 0 o DAC on: amixer -c 0 cset numid=10,iface=MIXER,name='DAC::DAC Output Playback Switch' 1 DAC off: amixer -c 0 cset numid=10,iface=MIXER,name='DAC::DAC Output Playback Switch' 0 * There is no hardware mixer capability, i.e. the inputs cannot be routed directly to the outputs.
Our preamp mode works like this:
1. A digital input source is selected with AV/C (Toslink, or RCA, or XLR), i.e. with "Digital Input Capture Route" 2. Clock input source is set to the same as audio input source with AV/C [1] 3. DICE clock rate is set to external clock rate [2] 4. A simple 2-channel ALSA loopback with digital volume control is created between input and output
I hope this answers your questions, otherwise please let me know.
Hm. I'm sorry but it is still unclear that the destination of audio signal in the IEEE 1394 isochronous packet arrived at your device (precisely the source port in the router function of TCAT DICE chip). It is Playback PCM channel in ALSA word, and depicted as 'stream-input-1/2' in my diagram for my convenience. ``` spdif-opt-input-1/2 ---+ spdif-coax-input-1/2 --(or)--> digital-input-1/2 -----------------> stream-output-1/2 aesebu-xlr-input-1/2 ---+ | v stream-input-1/2 --------------------(or)--+----------------------> spdif-coax-output-1/2 +----------------------> aesebu-xlr-output-1/2 +--analog-output-1/2 --> analog-xlr-output-1/2 +-----------> analog-coax-output-1/2 ``` I assume that the actual source selection of 'digital-input-1/2' is done in the router function of DICE chip as well as the selection between 'digital-input-1/2' and 'stream-input-1/2'. The mixer function of the chip is not used as I expected, thus the selection should exist as the source of audio signals for the outputs. However, in the above description, I cannot find such selection. Or the device has a fixed route between 'stream-input-1/2' and 'analog-{xlr,coax}-output-1/2'? The user can not hear the audio signal of opt/coax/xlr digital input ports in the analog outputs? Thanks Takashi Sakamoto
Hi Takashi Thanks for your inquiry. Concerning the routing it's one pretty simple routing mode. I guess it's best if I send you the routing excerpt from our DICE firmware (for low & mid ratemodes, the high rates are similar but with optional dual-wire routing): static HRESULT routeLowMid (void) { // DAC main gets audio from Firewire dalSetRoute(eDAL_INTERFACE_1, TX_INS0_CH0, mute_DAC ? RX_MUTED_CH : RX_AVS1_CH0); dalSetRoute(eDAL_INTERFACE_1, TX_INS0_CH1, mute_DAC ? RX_MUTED_CH : RX_AVS1_CH1); // AES/EBU OUT XLR 1 gets audio from Firewire dalSetRoute(eDAL_INTERFACE_1, TX_AES0_CHL, mute_XLR ? RX_MUTED_CH : RX_AVS1_CH0); dalSetRoute(eDAL_INTERFACE_1, TX_AES0_CHR, mute_XLR ? RX_MUTED_CH : RX_AVS1_CH1); // AES/EBU OUT RCA 1 gets audio from Firewire dalSetRoute(eDAL_INTERFACE_1, TX_AES2_CHL, (mute_RCA|isDualWire) ? RX_MUTED_CH : RX_AVS1_CH0); dalSetRoute(eDAL_INTERFACE_1, TX_AES2_CHR, (mute_RCA|isDualWire) ? RX_MUTED_CH : RX_AVS1_CH1); aesDualTx_Right_Func(isDualWire?FALSE:TRUE); #ifdef _BUILD_OLD_MAN202 // AES/EBU OUT XLR 2 gets audio from Firewire dalSetRoute(eDAL_INTERFACE_1, TX_AES2_CHL, mute_XLR ? RX_MUTED_CH : RX_AVS1_CH0); dalSetRoute(eDAL_INTERFACE_1, TX_AES2_CHR, mute_XLR ? RX_MUTED_CH : RX_AVS1_CH1); // AES/EBU OUT RCA 2 gets audio from Firewire dalSetRoute(eDAL_INTERFACE_1, TX_AES3_CHL, mute_RCA ? RX_MUTED_CH : RX_AVS1_CH0); dalSetRoute(eDAL_INTERFACE_1, TX_AES3_CHR, mute_RCA ? RX_MUTED_CH : RX_AVS1_CH1); #endif switch (inputSelect) { case INPUT_XLR: // Firewire IN gets audio from AES/EBU IN XLR dalSetRoute(eDAL_INTERFACE_1, TX_AVS1_CH0, RX_AES0_CHL); dalSetRoute(eDAL_INTERFACE_1, TX_AVS1_CH1, RX_AES0_CHR); break; case INPUT_RCA: // Firewire IN gets audio from AES/EBU IN RCA dalSetRoute(eDAL_INTERFACE_1, TX_AVS1_CH0, RX_AES1_CHL); dalSetRoute(eDAL_INTERFACE_1, TX_AVS1_CH1, RX_AES1_CHR); break; #ifndef _BUILD_OLD_MAN202 case INPUT_TOS: // Firewire IN gets audio from AES/EBU IN TOS dalSetRoute(eDAL_INTERFACE_1, TX_AVS1_CH0, RX_AES2_CHL); dalSetRoute(eDAL_INTERFACE_1, TX_AVS1_CH1, RX_AES2_CHR); break; #endif default: // Firewire IN muted dalSetRoute(eDAL_INTERFACE_1, TX_AVS1_CH0, RX_MUTED_CH); dalSetRoute(eDAL_INTERFACE_1, TX_AVS1_CH1, RX_MUTED_CH); break; } return NO_ERROR; } In this the following parameters are set via the dedicated AV/C commands, that were previously mentioned: * mute_DAC * mute_XLR * mute_RCA * isDualWire * inputSelect Let us know if you have further questions. Best regards, Rolf Anderegg On 28.02.24 00:54, Takashi Sakamoto wrote:
Hm. I'm sorry but it is still unclear that the destination of audio signal in the IEEE 1394 isochronous packet arrived at your device (precisely the source port in the router function of TCAT DICE chip). It is Playback PCM channel in ALSA word, and depicted as 'stream-input-1/2' in my diagram for my convenience.
``` spdif-opt-input-1/2 ---+ spdif-coax-input-1/2 --(or)--> digital-input-1/2 -----------------> stream-output-1/2 aesebu-xlr-input-1/2 ---+ | v stream-input-1/2 --------------------(or)--+----------------------> spdif-coax-output-1/2 +----------------------> aesebu-xlr-output-1/2 +--analog-output-1/2 --> analog-xlr-output-1/2 +-----------> analog-coax-output-1/2 ```
I assume that the actual source selection of 'digital-input-1/2' is done in the router function of DICE chip as well as the selection between 'digital-input-1/2' and 'stream-input-1/2'. The mixer function of the chip is not used as I expected, thus the selection should exist as the source of audio signals for the outputs. However, in the above description, I cannot find such selection.
Or the device has a fixed route between 'stream-input-1/2' and 'analog-{xlr,coax}-output-1/2'? The user can not hear the audio signal of opt/coax/xlr digital input ports in the analog outputs?
Thanks
Takashi Sakamoto
Hi again, quick followup: So basically it's like this: ``` spdif-opt-input-1/2 ---+ spdif-coax-input-1/2 --(or)--> digital-input-1/2 -----------------> stream-output-1/2 aesebu-xlr-input-1/2 ---+ muted ------------------+ stream-input-1/2 --------------------------+----------------------> spdif-coax-output-1/2 +----------------------> aesebu-xlr-output-1/2 +--analog-output-1/2 --> analog-xlr-output-1/2 +-----------> analog-coax-output-1/2 ``` And all potential mixing (e.g. volume processing) would be done in userspace on the firewire host. On 28.02.24 09:14, Rolf Anderegg wrote:
Hi Takashi
Thanks for your inquiry. Concerning the routing it's one pretty simple routing mode. I guess it's best if I send you the routing excerpt from our DICE firmware (for low & mid ratemodes, the high rates are similar but with optional dual-wire routing):
[...]
Best regards, Rolf Anderegg
On 28.02.24 00:54, Takashi Sakamoto wrote:
[...]
I assume that the actual source selection of 'digital-input-1/2' is done in the router function of DICE chip as well as the selection between 'digital-input-1/2' and 'stream-input-1/2'. The mixer function of the chip is not used as I expected, thus the selection should exist as the source of audio signals for the outputs. However, in the above description, I cannot find such selection.
Or the device has a fixed route between 'stream-input-1/2' and 'analog-{xlr,coax}-output-1/2'? The user can not hear the audio signal of opt/coax/xlr digital input ports in the analog outputs?
Exactly, this is fixed as you can see in our DICE routing method.
Thanks
Takashi Sakamoto
Best regards, Rolf Anderegg
Hi Rolf and Michele, On Wed, Feb 28, 2024 at 09:32:45AM +0100, Rolf Anderegg wrote:
Hi again, quick followup: So basically it's like this:
``` spdif-opt-input-1/2 ---+ spdif-coax-input-1/2 --(or)--> digital-input-1/2 -----------------> stream-output-1/2 aesebu-xlr-input-1/2 ---+ muted ------------------+
stream-input-1/2 --------------------------+----------------------> spdif-coax-output-1/2 +----------------------> aesebu-xlr-output-1/2 +--analog-output-1/2 --> analog-xlr-output-1/2 +-----------> analog-coax-output-1/2 ```
And all potential mixing (e.g. volume processing) would be done in userspace on the firewire host.
On 28.02.24 09:14, Rolf Anderegg wrote:
On 28.02.24 00:54, Takashi Sakamoto wrote:
[...]
I assume that the actual source selection of 'digital-input-1/2' is done in the router function of DICE chip as well as the selection between 'digital-input-1/2' and 'stream-input-1/2'. The mixer function of the chip is not used as I expected, thus the selection should exist as the source of audio signals for the outputs. However, in the above description, I cannot find such selection.
Or the device has a fixed route between 'stream-input-1/2' and 'analog-{xlr,coax}-output-1/2'? The user can not hear the audio signal of opt/coax/xlr digital input ports in the analog outputs?
Exactly, this is fixed as you can see in our DICE routing method.
Ah... OK, now I got it. I had assumed that the audio signal to any digital input interface can be dynamically routed to any of the audio output according to the preference selection, however it is not. Unlike the equipments for the studio recording, the feature so-called as 'direct monitoring' (without multiplexing) is not implemented in MAN301. As a summary, the captured digital audio signal has the long trip to user's ear, like: ``` spdif-opt-input-1/2 --+ spdif-coax-input-1/2 -(or)--> digital-input-1/2 ---------------> stream-output-1/2 aesebu-xlr-input-1/2 --+ | muted -----------------+ | | (Linux system) v pcm-playback-1/2 <------ (software digital audio processing) <-- pcm-capture-1/2 | v stream-input-1/2 -------------------------+--------------------> spdif-coax-output-1/2 +--------------------> aesebu-xlr-output-1/2 +-analog-output-1/2 -> analog-xlr-output-1/2 +----------> analog-coax-output-1/2 ``` I've already uploaded `firewire-dice-protocols` crate v0.3.0 to crates.io with the diagram including the selection[1], but it should be fixed. I'll do it later. Thanks [1] https://docs.rs/firewire-dice-protocols/latest/firewire_dice_protocols/weiss... Takashi Sakamoto
participants (3)
-
Michele Perrone -
Rolf Anderegg -
Takashi Sakamoto