[alsa-devel] Support for DSD streams (was: Re: [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work)

[Daniel Mack]

Hi Jussi,

On 22.03.2013 20:37, Jussi Laako wrote:
> On 03/22/2013 10:11 AM, Daniel Mack wrote:
>> 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?
> 
> Yes, it's abuse of PCM (hw) interface, I'm using the DoP specification 
> as referred to in another post.

It's really new to me that there are active users for this sample
format, and we should clean up the mess by cleanly marking such streams
correctly in the drivers. But I'm still not sure about the current
situation in terms of hardware support. So let's shed some light ...

> All the DSD DACs that currently work 
> with Linux support this. Quite many at the moment in fact and more 
> coming all the time.

Ok, but how do you know about which interfaces are capable of handling
that? Are you maintaining a white list?

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?

Can you show the contents of /proc/asound/cardX/stream0 for such a card
maybe?

> There's at least devices from Mytek, Fostex, Benchmark and Sonore/exD 
> that work with this setup. And I believe also Chord, but I haven't got 
> chance to test it yet.

Can you provide the output of "lsusb -v" for any of these?

> Mytek has a vendor specific interface (RigiSystems USBPAL) that could 
> utilize a separate raw DSD sample format.
> 
> Plus I have some of my own experiments implementing DSD on an ARM based 
> SoC where there's no need use DoP, but now I need to use custom hack for 
> the raw data. Thus sooner there's some officially defined ALSA formats, 
> less likely it becomes fragmented set of different incompatible hacks. 
> That would be a headache and nightmare for application developers.

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.

To be precise: which SND_PCM_FORMAT_* does your application accept, and
what happens if it sees  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.



Daniel