diff mbox series

ALSA: dice: add stream format parameters for Weiss devices

Message ID 24703333-9250-40bf-e736-a5f3c4862034@weiss.ch (mailing list archive)
State New, archived
Headers show
Series ALSA: dice: add stream format parameters for Weiss devices | expand

Commit Message

Michele Perrone July 28, 2023, 9:16 a.m. UTC
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

+        .driver_data = (kernel_ulong_t)snd_dice_detect_weiss_formats,
+    },
      { }
  };
  MODULE_DEVICE_TABLE(ieee1394, dice_id_table);

base-commit: 9b4469410cf9a0fcbccc92c480fd42f7c815a745

Comments

Takashi Sakamoto July 28, 2023, 1:13 p.m. UTC | #1
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/firewire/dice/dice.c?h=v6.4#n59
[3] https://github.com/takaswie/am-config-roms/
[4] https://github.com/systemd/systemd/blob/main/hwdb.d/80-ieee1394-unit-function.hwdb


Thanks

Takashi Sakamoto
Michele Perrone July 31, 2023, 8:09 a.m. UTC | #2
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/a471fcde8c2c4b65f110bb4210af3513ee4deeb8

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/firewire/dice/dice.c?h=v6.4#n59
> [3] https://github.com/takaswie/am-config-roms/
> [4] https://github.com/systemd/systemd/blob/main/hwdb.d/80-ieee1394-unit-function.hwdb
>
>
> Thanks
>
> Takashi Sakamoto
Takashi Sakamoto July 31, 2023, 2:06 p.m. UTC | #3
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
Michele Perrone Aug. 8, 2023, 8:34 a.m. UTC | #4
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
Takashi Sakamoto Aug. 8, 2023, 3:25 p.m. UTC | #5
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
Michele Perrone Aug. 16, 2023, 1:05 p.m. UTC | #6
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
Takashi Sakamoto Aug. 18, 2023, 1:13 p.m. UTC | #7
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
> 
> 参照
> 
>    1. https://github.com/weiss-engineering/snd-dice/tree/avc
Michele Perrone Aug. 18, 2023, 1:23 p.m. UTC | #8
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
>>
>> 参照
>>
>>     1. https://github.com/weiss-engineering/snd-dice/tree/avc
Takashi Sakamoto Aug. 22, 2023, 1:58 p.m. UTC | #9
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/protocols/dice/src/tcat/config_rom.rs


Thanks

Takashi Sakamoto
Takashi Sakamoto Aug. 31, 2023, 1:28 p.m. UTC | #10
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
Rolf Anderegg Sept. 4, 2023, 4 p.m. UTC | #11
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
Takashi Sakamoto Sept. 5, 2023, 1:20 a.m. UTC | #12
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
Rolf Anderegg Sept. 5, 2023, 8:57 a.m. UTC | #13
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
Takashi Sakamoto Sept. 5, 2023, 11:54 p.m. UTC | #14
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/sound/firewire/dice/dice.c?id=4fb0dacb78c6a041bbd38ddd998df806af5c2c69#n395
[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
Michele Perrone Sept. 16, 2023, 9:18 a.m. UTC | #15
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/sound/firewire/dice/dice.c?id=4fb0dacb78c6a041bbd38ddd998df806af5c2c69#n395
> [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
Takashi Sakamoto Sept. 17, 2023, 2:55 a.m. UTC | #16
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/sound/firewire/dice/dice.c?id=4fb0dacb78c6a041bbd38ddd998df806af5c2c69#n395
> > [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
Michele Perrone Sept. 18, 2023, 1:19 p.m. UTC | #17
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/5a95496c0666048bc5bc8c07b3e1d74f392dc9a4/dice-avc.c#L436
Takashi Sakamoto Sept. 19, 2023, 2:09 p.m. UTC | #18
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/5a95496c0666048bc5bc8c07b3e1d74f392dc9a4/dice-avc.c#L436


Regards

Takashi Sakamoto
Takashi Sakamoto Jan. 21, 2024, 2:07 p.m. UTC | #19
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-support
[2] https://github.com/alsa-project/snd-firewire-ctl-services/blob/topic/weiss-support/protocols/dice/src/weiss/avc.rs#L12


Thanks

Takashi Sakamoto
Takashi Sakamoto Jan. 21, 2024, 2:30 p.m. UTC | #20
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-support
> [2] https://github.com/alsa-project/snd-firewire-ctl-services/blob/topic/weiss-support/protocols/dice/src/weiss/avc.rs#L12

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
Takashi Sakamoto Feb. 15, 2024, 12:04 p.m. UTC | #21
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-support
> > [2] https://github.com/alsa-project/snd-firewire-ctl-services/blob/topic/weiss-support/protocols/dice/src/weiss/avc.rs#L12
> 
> 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
Michele Perrone Feb. 26, 2024, 4:06 p.m. UTC | #22
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-support
> [2]https://github.com/alsa-project/snd-firewire-ctl-services/blob/topic/weiss-support/protocols/dice/src/weiss/avc.rs#L12
>
>
> Thanks
>
> Takashi Sakamoto
Takashi Sakamoto Feb. 27, 2024, 11:54 p.m. UTC | #23
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
Rolf Anderegg Feb. 28, 2024, 8:14 a.m. UTC | #24
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
Rolf Anderegg Feb. 28, 2024, 8:32 a.m. UTC | #25
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
Takashi Sakamoto Feb. 28, 2024, 11:28 p.m. UTC | #26
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/avc/index.html

Takashi Sakamoto
diff mbox series

Patch

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,