Re: [PATCH] ALSA: dice: add stream format parameters for Weiss devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux