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