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

[Takashi Iwai]

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 :)


Takashi