[alsa-devel] [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work

[Daniel Mack]

On 18.03.2013 10:30, Takashi Iwai wrote:
> At Mon, 18 Mar 2013 10:15:44 +0100,
> Daniel Mack wrote:
>>
>> On 18.03.2013 10:07, Takashi Iwai wrote:
>>> At Sun, 17 Mar 2013 20:07:23 +0800,
>>> Daniel Mack wrote:
>>>>
>>>> Thanks to Andreas, I got my hands on a Playback Design MPD-3 and hacked
>>>> up some small hanges necessary to make it fully work with snd-usb.
>>>>
>>>> The device reports 0x80000000 in the bmFormats field of two of three of
>>>> its alternate settings, which wrongly made the driver believe it's a
>>>> usual PCM endpoint (actually due to a fix-up fallback). However, bit 31
>>>> of this mask in fact denotes 'raw data'.
>>>>
>>>> The effect of this issue is that in addition to the first altsetting with
>>>> a bit depth of 24, the driver exposed 8-bit and 16-bit native audio
>>>> formats on the raw data endpoints, which do not work as expected.
>>>>
>>>> Also, those devices need a 50ms delay after switching the USB interface.
>>>
>>> Thanks, applied to for-next branch.
>>>
>>> The remaining question is which PCM format is suitable for the raw
>>> data.  SND_PCM_FORMAT_SPECIAL should be OK, it won't regress at least,
>>> as no apps support this format.
>>
>> Yes, I  thought about that for a while as well. In fact, the data format
>> the device supports on these altsettings is "DSD", but that doesn't have
>> a defined value in the UAC2 spec (and strictly speaking, DSD is not even
>> PCM).
>>
>> So when a device is as unspecific as 'raw data', there's not much we can
>> do about that except for exposing the same level of uncertainty down to
>> the apps, right?
> 
> Yes.  We can add a new format SND_PCM_FORMAT_RAW, but it's not much
> better than SND_PCM_FORMAT_SPECIAL after all :)

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.


Thanks,
Daniel