Hello,
Sorry for the wait. Have been busy a bit.
On Saturday, 19 May 2018 10:23:30 CEST Takashi Sakamoto wrote:
This is my first time to have discussion about transmission of PDM sample by IEC 61883-1/6[1][2] via IEEE 1394 bus. You can see details of this protocol in a document published by 1394TA[3]. For implementation detail, please refer to my un-upstreamed documents[4][5].
Thank you, these help a lot. I just did some quick reading and will read more thoroughly in the coming days as time permits. Contact with Mytek is going well by the way, I am expecting details from their engineer soon.
Unfortunately, at present, IEC 61883-1/6 engine in ALSA firewire stack is designed for PCM samples and MIDI messages with ALSA PCM/MIDI interface. I removed support 16 bit PCM sample at a commit a02cb8f8def6 ('ALSA: firewire: remove support for 16 bit PCM samples in playback substream')[6] in this point, because as long as I know all of supported models have no features to switch bit width of transferred/received PCM samples and my previous implementation for 16 bit sample brings zero-padding 24 bit PCM sample to the device. (Drivers in ALSA firewire stack support SNDRV_PCM_FMTBIT_S32 with 24 bit constraint[7].)
The commit makes perfect sense, indeed displaying only actual hardware capabilities instead of padding in the driver. Curiosity satisfied. :)
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: 00000000If 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.
For this case, I need to implement ALSA dice driver to add two PCM substreams in Linux system; one is for transmission of PCM samples, another is for transmission of PDM samples for DoP-compliant application. Unfortunately, current IEC 61883-1/6 engine in ALSA firewire stack is not designed for this case.
As an another solution, reservation of data transmission of IEC 61883-1/6 packet either data stream of PCM samples or data stream of PDM samples. In this case, implementation change can be smaller than multiplexing/demultiplexing these two data stream for data stream of IEC 61883-1/6 packets. In this solution, from userspace applications, two PCM substreams are available exclusively.
As you say, what may help with implementation is that, as far as I have seen on the market, all devices are either in PCM or PDM mode. Thus there indeed doesn't need to be support for sending PCM and PDM at the same time. Perhaps there do exist some really big units which are multiple DAC/ADC in one box where some streams are PCM and others are PDM at the same time, but I have not yet heard of such a device.
If I understand correctly, the substreams are what show up in "aplay -l" as subdevice. Such that "hw:DAC,0" and "hw:DAC,1" would open substream #0 and #1 respectively. From userspace point of view I think it makes sense to expose a single 2-channel substream with both PCM and PDM capabilities which is then used in either 2ch PCM or 2ch PDM at any time, but not 1ch PCM + 1ch PDM. This is similar to how USB DoP DACs work I believe.
This way a playlist in music software (MPD) containing both PCM and PDM tracks will work on the same output. MPD can configure "allowed formats" in the output, but it will always convert PDM to PCM for all enabled outputs that do not support PDM. In case of two substreams the PCM and PDM substreams will then be used at the same time unless the user manually switches active input before and after PDM tracks. I suspect many other userspace music software have similar behaviour.
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.
I have not yet hacked MPD to attempt to experiment with channel mappings. I may still do this in the coming weeks however.
Regards,
Melvin Vermeeren