[alsa-devel] Support for DSD streams
jussi at sonarnerd.net
Sat Mar 23 20:53:59 CET 2013
On 03/23/2013 01:31 PM, Daniel Mack wrote:
> Ok, but how do you know about which interfaces are capable of handling
> that? Are you maintaining a white list?
It's all up to user configuration, just an option in GUI for it. There
are still some devices where the support depends on firmware version
(support was introduced as firmware upgrade) so white listing is not so
feasible always. But the situation is getting better. However I don't
want to maintain a white list of vendor/device id's inside my
application. Also the same format works over S/PDIF or AES/EBU just fine
(with dual-wire up to DSD128). So automatic detection is not always
However I'm hoping to get the relevant information through the audio API
in future for all possible interfaces (IOW not S/PDIF or AES/EBU, but
things like USB, Firewire, PCI(e) and ASoC). Since there many DAC chips
that have support for DSD it makes sense.
> And does that mean these devices are also wrongly believed to have
> additional PCM interfaces? IOW: do they only work as DSD, breaking all
> applications that believe that they can use all devices that expose a
> PCM interface?
So far all devices have been supporting also PCM, but support for DSD128
is already a problem. Since with DoP it would require 352.8k PCM sample
rate support, but some devices can do PCM only up to 192 while being
able to support DSD128. Currently there's no way to figure out such
limitations through ALSA (unlike ASIO where sampling rate enumeration is
completely separate for PCM and DSD). So application would assume that
also 352.8 PCM is available.
> Can you show the contents of /proc/asound/cardX/stream0 for such a card
> Can you provide the output of "lsusb -v" for any of these?
There's nothing related to DSD there, because DoP is implemented in an
FPGA behind the audio interface. Most common is the XMOS UAC2
implementation. Just normal asynchronous UAC2.
For the rest it's device class "vendor specific".
> I'm afraid that adding a DSD format and teaching the driver quirks for
> interfaces that are known to support DSD would break applications that
> already expect to see a usual PCM interface.
Currently most interfaces support usual PCM, but in addition they
support also DSD. So they have two native sample formats, but only one
USB format. Except again the vendor specific ones where there tend to be
two wire formats, like 3-byte 24-bit and byte stream for DSD.
> To be precise: which SND_PCM_FORMAT_* does your application accept, and
> what happens if it sees SND_PCM_FORMAT_SPECIAL?
I'm currently using SND_PCM_FORMAT_U8 at 352800 for my raw DSD custom
hacks, because it won't overlap with any real world PCM hardware... For
DoP devices there are at least SND_PCM_FORMAT_S32_LE and
SND_PCM_FORMAT_S24_3LE in use. XMOS uses the former one, IIRC Mytek with
the TCAT Dice FW chipset uses the latter one (and the USB2 is vendor
I don't support SND_PCM_FORMAT_SPECIAL.
> As for the driver, I would not go any further than marking the streams
> as DSD, without touching the payload. The marker bytes as described in
> the DoP document could be handled by some sort of libasound convenience
> function maybe though.
OK, then I would most likely keep the payload packing as it is already...
More information about the Alsa-devel