[alsa-devel] [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work
zonque at gmail.com
Wed Mar 27 20:02:52 CET 2013
On 22.03.2013 17:05, Andreas Koch wrote:
> Hi all,
> 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. 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 -
> 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.
> 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.
> If you guys are discussing implementing a dedicated data stream in
> your driver for DSD, then I think this would be better and safer in the future.
Is there any official stable download location for this document which
we could link to from our documentation?
More information about the Alsa-devel