On Friday, 18 May 2018 04:54:01 CEST Takashi Sakamoto wrote:
Hi,
On May 18 2018 04:00, Melvin Vermeeren wrote:
Mytek manufactures some equipment with DICE-based firewire ports. These devices contain old versions of DICE firmware which lacks detailed stream format reporting for all sampling clock modes.
Building upon the recent work by Takashi Sakamoto, hard-coded parameters are added for the Stereo 192 DSD-DAC. When the device vendor and model match the coded parameters are copied into the stream format cache.
Signed-off-by: Melvin Vermeeren mail@mel.vin -- SNIP --
From me, some supplements. In Mytek website, we can get firmwares for some models with interfaces for IEEE 1394 bus.
- Professional: https://mytekdigital.com/professional/support/
- Stereo192-DSD-DAC:
https://mytekdigital.com/support_docs/Mytek_Stereo192DSD%20DAC_firmware.zip
- 8x192ADDA DIO FW:
https://mytekdigital.com/download_library/DioFWDiceMini3001.bin
- HiFi: https://mytekdigital.com/hifi/support/
- Manhattan DAC (Original model):
https://mytekdigital.com/support_docs/Mytek_ManhattanDAC_firmware_v1.1.1.zip
- Stereo192-DSD-DAC:
https://mytekdigital.com/support_docs/Mytek_Stereo192DSD%20DAC_firmware.zip
When executing strings(1) to these firmwares, we can see below line:
For Stereo192-DSD-DAC:
* Mytek Stereo192DA on DICE Mini (TCD2210) *For original Manhattan DAC:
* Mytek Stereo192DA on DICE Mini (TCD2210) *(I note that the line includes different name.)
For 8x192ADDA DIO FW:
* Mytek 8x192ADDA DioFW on DICE Mini (TCD2210) *It's reasonable that we judge TCD2210 (a.k.a. Dice mini) ASIC used for Mytek models. Old firmwares were not released for this ASIC, thus your patch comment is not proper. The reason for this patch is that this model doesn't support extended protocol, which I've addressed at a commit commit 58579c056c1c ('ALSA: dice: use extended protocol to detect available stream formats').
Thank you for the details, I hadn't looked into the hardware side of things with this depth. I had assumed that the lack of reporting would be due to old firmware like with other models.
Furthermore, for 8x192ADDA DIO FW, the firmware includes below line:
* EAP is supported. *I believe ALSA Dice driver can detect stream formats correctly for this model. Thus, the rest of piece may be for original Manhattan DAC.
It could be that the Manhattan does support EAP, it is quite a bit newer than the Stereo 192 DSD-DAC. Though at the same time, a lot of the internals are the same as in the 192.
I note that all of Dice based devices utilizes Embedded Configurable Operating System(eCos)[1], and these firmwares are designed for eCos. IMHO, the firmwares can be parsed by format of eCos but I have never attempted it,
From my curious, can you drive your model with DSD samples? If so, what kind of software do you use?
With lintweaker's out-of-tree USB 2.0 driver[1] it works with DoP. Due to latency requirements and reliability I always run over firewire however. I did some basic attempts to get it working from userspace, but I think it is not possible with the current snd_dice.
As for the player, I believe there are several that support it. So far I have been using MPD, which has native DSD playback[2][3].
I did attempt something cheap to see what would happen:
#define AM824_IN_PCM_FORMAT_BITS SNDRV_PCM_FMTBIT_S32 #define AM824_OUT_PCM_FORMAT_BITS SNDRV_PCM_FMTBIT_S32
For these two, I appended "| SNDRV_PCM_FMTBIT_DSD_U32_LE" and some other variants. MPD then refuses to play because:
alsa_output: opened hw:DAC,0 type=HW alsa_output: buffer: size=1792..4096 time=10158..23220 alsa_output: period: size=896..2048 time=5079..11610 alsa_output: default period_time = buffer_time/4 = 23219/4 = 5804 alsa_output: format=DSD_U32_LE (Direct Stream Digital, 4-byte (x32), little endian, oldest bits in MSB) alsa_output: buffer_size=4096 period_size=1024 output: opened "mpd_alsa_out" (alsa) audio_format=dsd128:4 exception: Failed to convert for "mpd_alsa_out" (alsa) exception: nested: PCM conversion from f to dsd is not implemented output: Retrying without DSD alsa_output: opened hw:DAC,0 type=HW alsa_output: buffer: size=1920..4096 time=10000..21334 alsa_output: period: size=960..2048 time=5000..10667 alsa_output: default period_time = buffer_time/4 = 21333/4 = 5333 alsa_output: format=S32_LE (Signed 32 bit Little Endian) alsa_output: buffer_size=4096 period_size=1024 output: opened "mpd_alsa_out" (alsa) audio_format=192000:32:4 libsamplerate: setting samplerate conversion ratio to 0.27 output: converting in=dsd128:2 -> f=dsd128:2 -> out=192000:32:4
I am pretty sure this happens because the DSD128 file is 2 channels, and MPD sees the output in 4 channels. It does exactly the same for DSD64. I am not sure how this should be handled since the channels are not actually for 4.0 audio. Possibly need to expose it is a 2-channel device and in the driver use PCM-L,PCM-R or DSD-L,DSD-R depending on the input. Could be the unit works a bit differently then this, I will ask Mytek.
In the meanwhile, do you have any suggestions for things I could experiment with? I am not very familiar with the ALSA tree (yet). Meanwhile I will try to look in MPD source code for a bit, if I could set channel mappings there that might solve it too.
By the way, it seems that currently native 16-bit and 24-bit PCM formats are not supported since it always locks to 32-bit. I remember the "old", 2016, DICE driver did support 16-bit to my DAC, not sure about 24-bit. I am curious to why the new design is fixed to 32-bit, do you perhaps know?
[1] https://github.com/lintweaker/mytekusb2 [2] https://www.musicpd.org/doc/user/dsd.html [3] https://github.com/MusicPlayerDaemon/MPD/blob/master/NEWS
Thank you,
Melvin Vermeeren