[alsa-devel] [PATCH] ALSA: dice: add stream format parameters for Mytek devices

[Melvin Vermeeren]

Hi,

Over the past weeks I have had some time to do some more research and hacking. 
Thank you for the supplied un-upstreamed documents. Mytek has also been very 
helpful providing some details about the unit. It appears that the assumptions 
so far are largely invalid and there is almost no work to be done on ALSA Dice 
driver.

Although this is good news, I have unfortunately also discovered a problem.

On Monday, 21 May 2018 17:09:37 CEST Melvin Vermeeren wrote:
> On Saturday, 19 May 2018 10:23:30 CEST Takashi Sakamoto wrote:
> > In my opinion, it's hard to achieve it with quick hack to the engine
> > and ALSA Dice driver. Especially for your case, one data block for
> > outgoing packet to target device should include two kind data; PCM
> > and PDM samples. I can see output from '/proc/asound/DSD/dice' in
> > your previous message[8] includes below:
> > 
> > ```
> > 
> > rx 0:
> >    iso channel: 1
> >    sequence start: 0
> >    audio channels: 4
> >    midi ports: 0
> >    names: ANALOG L\ANALOG R\DSD1281\DSD1282\\
> >    ac3 caps: 00000000
> > 
> > ```
> > 
> > If the 'ANALOG L/R' represent data channels for two PCM samples
> > and the 'DSD1281/2' represent data channels for two PDM samples,
> > I can assume that one data block includes two kind of samples,
> > thus two data streams of PCM/PDM samples should be multiplexed into
> > one data stream of IEC 61883-1/6 packets.
>
> Also, I am not yet sure whether this specific DAC supports DoP over IEEE
> 1394. Possibly there is another format in use for PDM playback over IEEE
> 1394. Expect more details on this within the next few days.

It turns out the Mytek Stereo-192-DSD-DAC only supports PDM samples over PCM 
with DoP standard[1]. DoP uses 24-bit PCM frames at 176.4kHz sampling 
frequency to transmit PDM samples.

The "DSD128" channels to my DAC are for DSD128 DoP mode using the method as 
described in 3.2. in the standard. Because this unit does not support 352.8kHz 
four PCM channels are used in 176.4Khz rate to effectively transmit DSD128.

This means the ALSA Dice driver can remain as is, since DoP standard is used 
from userspace applications like MusicPlayerDaemon (MPD). I got DSD64 DoP 
working by hacking the channel mappings. For proper DSD128 DoP with four 
channels some changes are needed in MPD, I'll contact their mailing list soon.

The above proposition might still be needed in the future if we encounter IEEE 
1394 hardware that only supports native PDM formats.

I will submit another patch soon to possibly add support for Mytek Manhattan 
DAC and to correct and update some comments in the dice-mytek.c file.

----

Unfortunately, I have confirmed the existence of some sort of timing or 
transmission issue to the unit. This did not happen when I ran the "old" 
modules out-of-tree for over a year, as described in the initial mail[2]. In 
this mail I also noticed the popping issue.

It comes down to that the transmission is somehow not bit-perfect. In PCM mode 
this causes subtle cracking and popping, which is a lot more notable on higher 
frequencies. The higher the sampling frequency, the more rapid the popping 
sounds become. The PCM stream never fully drops out, sounds do always keep 
playing.

In DSD (DoP) mode this causes complete drop-out of the signal for ~0.2-1.0 
seconds since the DAC leaves DoP mode when the DoP markers are missing. This 
happens consistently every 2 seconds or so. The 2 seconds it does play DSD64 
it does work properly without any artefacts in the produced analog signal. The 
display on DAC keeps saying "dsd DoP" during the dropout.

Currently my kernel is 4.16.12-rt5. I also built 4.17.0-rc2-sound+ from 
Tiwai's repo today, which is commit 3248e54292f93e1bf7b9ff084918d79dd6f655f8. 
The problem is exactly the same in both and was also the same on any kernel I 
used since I switched to the "new" modules.

It should be noted the number of errors is variable. In the best case it is as 
described above. In other cases the number of problematic packets is so high 
the DAC cannot switch into DSD DoP mode at all, staying permanently silent 
while the display flickers between "dsd DoP" and "176.4 PCM" rapidly. For PCM 
streams the number and intensity of cracks and pops increase substantially.

Based upon the above, I think it is likely to be a timing issue. Not sure if 
it occurs during packet transmission or if something goes wrong when starting 
the streams, when the DAC "locks" to the packets.

Do you have a suggestion for anything I could try to either resolve the issue 
or how to provide additional information?

[1] http://dsd-guide.com/sites/default/files/white-papers/
DoP_openStandard_1v1.pdf
[2] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-September/
125524.html

Regards,

Melvin Vermeeren
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20180607/5dbf474b/attachment.sig>