Hi Daniel,
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 possible anyway.
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 maybe? 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?
For PCM: SND_PCM_FORMAT_S16_LE SND_PCM_FORMAT_S16_BE SND_PCM_FORMAT_S24_LE SND_PCM_FORMAT_S24_BE SND_PCM_FORMAT_S32_LE SND_PCM_FORMAT_S32_BE SND_PCM_FORMAT_S18_3LE SND_PCM_FORMAT_S20_3LE SND_PCM_FORMAT_S24_3LE SND_PCM_FORMAT_S18_3BE SND_PCM_FORMAT_S20_3BE SND_PCM_FORMAT_S24_3BE SND_PCM_FORMAT_FLOAT_LE SND_PCM_FORMAT_FLOAT_BE SND_PCM_FORMAT_FLOAT64_LE SND_PCM_FORMAT_FLOAT64_BE
For DSD: SND_PCM_FORMAT_S8 SND_PCM_FORMAT_U8 SND_PCM_FORMAT_S24_LE SND_PCM_FORMAT_U24_LE SND_PCM_FORMAT_S24_BE SND_PCM_FORMAT_U24_BE SND_PCM_FORMAT_S32_LE SND_PCM_FORMAT_U32_LE SND_PCM_FORMAT_S32_BE SND_PCM_FORMAT_U32_BE SND_PCM_FORMAT_S24_3LE SND_PCM_FORMAT_U24_3LE SND_PCM_FORMAT_S24_3BE SND_PCM_FORMAT_U24_3BE
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 specific class).
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...
- Jussi