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: 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.
>
> 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 VermeerenAttachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
