Hi Andreas,
On 22.03.2013 17:05, Andreas Koch wrote:
At 01:11 AM 3/22/2013, Daniel Mack wrote:
Hi Jussi, Hi Andreas,
On 21.03.2013 22:21, Jussi Laako wrote:
On 03/18/2013 03:49 PM, Daniel Mack wrote:
Yes. If at all, we should add a SND_PCM_FORMAT_DSD, and a quirk for that device. But given that there is no application for DSD in userspace either, we probably don't need to care.
Yes there is? At least my application. And I'd be happy to support any custom format created for the purpose... :)
Ah, interesting. So what *are* you using right now for your transport in userspace? Is your application abusing standard PCM interfaces that are 'known' to be in fact DSD? How do other DACs expose their interfaces in the Linux world, and which ones did you test your application with?
If there's actual need for a new SND_PCM_FORMAT, it would be easy to patch it through all the layers down to userspace.
I would propose to create custom 8-bit sample formats for DSD purposes, similar to the ASIO formats. Practically two main ones, byte with oldest bit in MSB and byte with oldest bit in LSB. And maybe the "DSD-wide" one which is 8-bit DSD sample.
Andreas, which modes does the MPD-3 accept exactly on its two 'raw data' interfaces? The only hint I have is that one of it is 8-bit and the other is 16-bit, but given the lack of a proper test setup for this format, I can't currently test anything.
The 8-bit raw format is for 2.8MHz DSD and the 16-bit format is for 5.6MHz DSD. In both cases the driver sets the sample rate to 352.8kHz on the DAC, but then sends either 8 bits or 16 bits depending on the DSD rate.
And prior to sending either 8 bits or 16 bits, currently the correct USB alternate interface has to be set, right?
Since 11.2MHz DSD is already on the horizon we may have to change this to a single 8-bit raw interface and then vary the underlying USB transfer sample rate between 1x, 2x, 4x 352.8kHz -
Yes, especially given that if there's no common standard across different devices, either the drivers or the applications have to implement special handling code for this, and know which interface supports what.
So for the ALSA layer, we should probably have a generic SND_PCM_FORMAT_DSD and then rely on the sample rate setting mechanisms to select the right DSD mode. Other solutions, like having a different SND_PCM_FORMAT_DSD_{2_8,5_6,11_2}_MHZ would be hairy to implement, as some devices need to get a sample rate update request, while others don't etc ...
that would be more logical and straight forward for the hardware implementation. This is only supported through my own driver for the Windows platform which uses the standard ASIO interface that supports DSD at those rates. Since the Mac OS only supports PCM streams and nothing else I brought together a bunch of DAC manufacturers and playback software developers to standardize a method to "cannibalize" the PCM stream for DSD data. The method is described in the attached and is now supported by most manufacturers.
Very interesting read. For ALSA though, it's no problem to support that in all layers and make the drivers tell applications about it. We just have to decide for a sane way :)
This also has been implemented on a few Linux platforms (Auraliti for instance). Even though the DoP standard works really well so far, it is a "bandaid" and should only be used if there is no other choice.
Yes, understood. The thing is just that we shouldn't break exising solutions that already rely on this "bandaid".
Daniel