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

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

[Daniel Mack]

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,
Daniel


Daniel Mack (3):
  ALSA: snd-usb: handle the bmFormats field as unsigned int
  ALSA: snd-usb: handle raw data format of UAC2 devices
  ALSA: snd-usb: add delay quirk for "Playback Design" products

 include/linux/usb/audio-v2.h |    2 ++
 sound/usb/format.c           |   20 ++++++++++++--------
 sound/usb/format.h           |    2 +-
 sound/usb/pcm.c              |    7 +++++++
 sound/usb/stream.c           |    2 +-
 5 files changed, 23 insertions(+), 10 deletions(-)

-- 
1.7.10.4

[PATCH 1/3] ALSA: snd-usb: handle the bmFormats field as unsigned int

[Daniel Mack]

This field may use up to 32 bits, so it should be handled as unsigned
int.

Signed-off-by: Daniel Mack <zonque@gmail.com>
Reported-by: Andreas Koch <andreas@akdesigninc.com>
---
 sound/usb/format.c |    9 +++++----
 sound/usb/format.h |    2 +-
 sound/usb/stream.c |    2 +-
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/sound/usb/format.c b/sound/usb/format.c
index e831ee4..b30d6fb 100644
--- a/sound/usb/format.c
+++ b/sound/usb/format.c
@@ -43,7 +43,7 @@
  */
 static u64 parse_audio_format_i_type(struct snd_usb_audio *chip,
 				     struct audioformat *fp,
-				     int format, void *_fmt,
+				     unsigned int format, void *_fmt,
 				     int protocol)
 {
 	int sample_width, sample_bytes;
@@ -353,7 +353,7 @@ err:
  * parse the format type I and III descriptors
  */
 static int parse_audio_format_i(struct snd_usb_audio *chip,
-				struct audioformat *fp, int format,
+				struct audioformat *fp, unsigned int format,
 				struct uac_format_type_i_continuous_descriptor *fmt,
 				struct usb_host_interface *iface)
 {
@@ -473,8 +473,9 @@ static int parse_audio_format_ii(struct snd_usb_audio *chip,
 	return ret;
 }
 
-int snd_usb_parse_audio_format(struct snd_usb_audio *chip, struct audioformat *fp,
-			       int format, struct uac_format_type_i_continuous_descriptor *fmt,
+int snd_usb_parse_audio_format(struct snd_usb_audio *chip,
+			       struct audioformat *fp, unsigned int format,
+			       struct uac_format_type_i_continuous_descriptor *fmt,
 			       int stream, struct usb_host_interface *iface)
 {
 	int err;
diff --git a/sound/usb/format.h b/sound/usb/format.h
index 387924f..6f31522 100644
--- a/sound/usb/format.h
+++ b/sound/usb/format.h
@@ -2,7 +2,7 @@
 #define __USBAUDIO_FORMAT_H
 
 int snd_usb_parse_audio_format(struct snd_usb_audio *chip,
-			       struct audioformat *fp, int format,
+			       struct audioformat *fp, unsigned int format,
 			       struct uac_format_type_i_continuous_descriptor *fmt,
 			       int stream, struct usb_host_interface *iface);
 
diff --git a/sound/usb/stream.c b/sound/usb/stream.c
index ad181d5..ad07046 100644
--- a/sound/usb/stream.c
+++ b/sound/usb/stream.c
@@ -463,7 +463,7 @@ int snd_usb_parse_audio_interface(struct snd_usb_audio *chip, int iface_no)
 	struct usb_host_interface *alts;
 	struct usb_interface_descriptor *altsd;
 	int i, altno, err, stream;
-	int format = 0, num_channels = 0;
+	unsigned int format = 0, num_channels = 0;
 	struct audioformat *fp = NULL;
 	int num, protocol, clock = 0;
 	struct uac_format_type_i_continuous_descriptor *fmt;
-- 
1.7.10.4

[PATCH 2/3] ALSA: snd-usb: handle raw data format of UAC2 devices

[Daniel Mack]

UAC2 compliant audio devices may announce the capability to transport
raw audio data on their endpoints. Catch this and handle it as
'special' stream on the ALSA side.

Signed-off-by: Daniel Mack <zonque@gmail.com>
Reported-by: Andreas Koch <andreas@akdesigninc.com>
---
 include/linux/usb/audio-v2.h |    2 ++
 sound/usb/format.c           |   11 +++++++----
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/include/linux/usb/audio-v2.h b/include/linux/usb/audio-v2.h
index ed13053..c5f2158 100644
--- a/include/linux/usb/audio-v2.h
+++ b/include/linux/usb/audio-v2.h
@@ -170,6 +170,8 @@ struct uac2_as_header_descriptor {
 	__u8 iChannelNames;
 } __attribute__((packed));
 
+#define UAC2_FORMAT_TYPE_I_RAW_DATA	(1 << 31)
+
 /* 4.10.1.2 Class-Specific AS Isochronous Audio Data Endpoint Descriptor */
 
 struct uac2_iso_endpoint_descriptor {
diff --git a/sound/usb/format.c b/sound/usb/format.c
index b30d6fb..a695caf 100644
--- a/sound/usb/format.c
+++ b/sound/usb/format.c
@@ -47,7 +47,7 @@ static u64 parse_audio_format_i_type(struct snd_usb_audio *chip,
 				     int protocol)
 {
 	int sample_width, sample_bytes;
-	u64 pcm_formats;
+	u64 pcm_formats = 0;
 
 	switch (protocol) {
 	case UAC_VERSION_1:
@@ -63,14 +63,17 @@ static u64 parse_audio_format_i_type(struct snd_usb_audio *chip,
 		struct uac_format_type_i_ext_descriptor *fmt = _fmt;
 		sample_width = fmt->bBitResolution;
 		sample_bytes = fmt->bSubslotSize;
+
+		if (format & UAC2_FORMAT_TYPE_I_RAW_DATA)
+			pcm_formats |= SNDRV_PCM_FMTBIT_SPECIAL;
+
 		format <<= 1;
 		break;
 	}
 	}
 
-	pcm_formats = 0;
-
-	if (format == 0 || format == (1 << UAC_FORMAT_TYPE_I_UNDEFINED)) {
+	if ((pcm_formats == 0) &&
+	    (format == 0 || format == (1 << UAC_FORMAT_TYPE_I_UNDEFINED))) {
 		/* some devices don't define this correctly... */
 		snd_printdd(KERN_INFO "%d:%u:%d : format type 0 is detected, processed as PCM\n",
 			    chip->dev->devnum, fp->iface, fp->altsetting);
-- 
1.7.10.4

[PATCH 3/3] ALSA: snd-usb: add delay quirk for "Playback Design" products

[Daniel Mack]

"Playback Design" products need a 50ms delay after setting the USB
interface.

Signed-off-by: Daniel Mack <zonque@gmail.com>
Reported-by: Andreas Koch <andreas@akdesigninc.com>
---
 sound/usb/pcm.c |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
index f94397b..c263991 100644
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -350,6 +350,13 @@ static int set_format(struct snd_usb_substream *subs, struct audioformat *fmt)
 				fmt->iface, fmt->altsetting);
 		subs->interface = fmt->iface;
 		subs->altset_idx = fmt->altset_idx;
+
+		/*
+		 * "Playback Design" products need a 50ms delay after setting the
+		 * USB interface.
+		 */
+		if (le16_to_cpu(dev->descriptor.idVendor) == 0x23ba)
+			mdelay(50);
 	}
 
 	subs->data_endpoint = snd_usb_add_endpoint(subs->stream->chip,
-- 
1.7.10.4

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

[Takashi Iwai]

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.


Takashi

> 
> 
> Thanks,
> Daniel
> 
> 
> Daniel Mack (3):
>   ALSA: snd-usb: handle the bmFormats field as unsigned int
>   ALSA: snd-usb: handle raw data format of UAC2 devices
>   ALSA: snd-usb: add delay quirk for "Playback Design" products
> 
>  include/linux/usb/audio-v2.h |    2 ++
>  sound/usb/format.c           |   20 ++++++++++++--------
>  sound/usb/format.h           |    2 +-
>  sound/usb/pcm.c              |    7 +++++++
>  sound/usb/stream.c           |    2 +-
>  5 files changed, 23 insertions(+), 10 deletions(-)
> 
> -- 
> 1.7.10.4
> 

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

[Daniel Mack]

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?


Thanks,
Daniel

Re: [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

Re: [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

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

[Gabriel M. Beddingfield]

On 03/18/2013 06:49 AM, Daniel Mack wrote:
>>> 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.

+1

However, more and more applications are wanting to send non-linear PCM 
data through ALSA.  So, we probably /do/ need to care.

-gabriel

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

[Takashi Iwai]

At Mon, 18 Mar 2013 19:51:09 -0700,
Gabriel M. Beddingfield wrote:
> 
> On 03/18/2013 06:49 AM, Daniel Mack wrote:
> >>> 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.
> 
> +1
> 
> However, more and more applications are wanting to send non-linear PCM 
> data through ALSA.  So, we probably /do/ need to care.

It depends.  DSD would be still likely feasible to be sent over a PCM
device, as it's an audio stream after all, but most of other non-audio
data wouldn't fit with the "PCM" device.


Takashi

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

[Jussi Laako]

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

(http://www.signalyst.com/consumer.html for those who are interested)

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.


	- Jussi

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

[Daniel Mack]

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.


Thanks,
Daniel

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

[Jussi Laako]

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. All the DSD DACs that currently work 
with Linux support this. Quite many at the moment in fact and more 
coming all the time.

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.

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.


	- Jussi

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

Re: Support for DSD streams

[Jussi Laako]

Hi Daniel,

On 03/23/2013 01:31 PM, Daniel Mack wrote:
> Ok, but how do you know about which interfaces are capable of handling
> that? Are you maintaining a white list?

It's all up to user configuration, just an option in GUI for it. There 
are still some devices where the support depends on firmware version 
(support was introduced as firmware upgrade) so white listing is not so 
feasible always. But the situation is getting better. However I don't 
want to maintain a white list of vendor/device id's inside my 
application. Also the same format works over S/PDIF or AES/EBU just fine 
(with dual-wire up to DSD128). So automatic detection is not always 
possible anyway.

However I'm hoping to get the relevant information through the audio API 
in future for all possible interfaces (IOW not S/PDIF or AES/EBU, but 
things like USB, Firewire, PCI(e) and ASoC). Since there many DAC chips 
that have support for DSD it makes sense.

> 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?

So far all devices have been supporting also PCM, but support for DSD128 
is already a problem. Since with DoP it would require 352.8k PCM sample 
rate support, but some devices can do PCM only up to 192 while being 
able to support DSD128. Currently there's no way to figure out such 
limitations through ALSA (unlike ASIO where sampling rate enumeration is 
completely separate for PCM and DSD). So application would assume that 
also 352.8 PCM is available.

> Can you show the contents of /proc/asound/cardX/stream0 for such a card
> maybe?
> Can you provide the output of "lsusb -v" for any of these?

There's nothing related to DSD there, because DoP is implemented in an 
FPGA behind the audio interface. Most common is the XMOS UAC2 
implementation. Just normal asynchronous UAC2.

For the rest it's device class "vendor specific".

> 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.

Currently most interfaces support usual PCM, but in addition they 
support also DSD. So they have two native sample formats, but only one 
USB format. Except again the vendor specific ones where there tend to be 
two wire formats, like 3-byte 24-bit and byte stream for DSD.

> To be precise: which SND_PCM_FORMAT_* does your application accept, and
> what happens if it sees  SND_PCM_FORMAT_SPECIAL?

For PCM:
         SND_PCM_FORMAT_S16_LE
         SND_PCM_FORMAT_S16_BE
         SND_PCM_FORMAT_S24_LE
         SND_PCM_FORMAT_S24_BE
         SND_PCM_FORMAT_S32_LE
         SND_PCM_FORMAT_S32_BE
         SND_PCM_FORMAT_S18_3LE
         SND_PCM_FORMAT_S20_3LE
         SND_PCM_FORMAT_S24_3LE
         SND_PCM_FORMAT_S18_3BE
         SND_PCM_FORMAT_S20_3BE
         SND_PCM_FORMAT_S24_3BE
         SND_PCM_FORMAT_FLOAT_LE
         SND_PCM_FORMAT_FLOAT_BE
         SND_PCM_FORMAT_FLOAT64_LE
         SND_PCM_FORMAT_FLOAT64_BE

For DSD:
         SND_PCM_FORMAT_S8
         SND_PCM_FORMAT_U8
         SND_PCM_FORMAT_S24_LE
         SND_PCM_FORMAT_U24_LE
         SND_PCM_FORMAT_S24_BE
         SND_PCM_FORMAT_U24_BE
         SND_PCM_FORMAT_S32_LE
         SND_PCM_FORMAT_U32_LE
         SND_PCM_FORMAT_S32_BE
         SND_PCM_FORMAT_U32_BE
         SND_PCM_FORMAT_S24_3LE
         SND_PCM_FORMAT_U24_3LE
         SND_PCM_FORMAT_S24_3BE
         SND_PCM_FORMAT_U24_3BE

I'm currently using SND_PCM_FORMAT_U8 at 352800 for my raw DSD custom 
hacks, because it won't overlap with any real world PCM hardware... For 
DoP devices there are at least SND_PCM_FORMAT_S32_LE and 
SND_PCM_FORMAT_S24_3LE in use. XMOS uses the former one, IIRC Mytek with 
the TCAT Dice FW chipset uses the latter one (and the USB2 is vendor 
specific class).

I don't support 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.

OK, then I would most likely keep the payload packing as it is already...


	- Jussi

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

[Daniel Mack]

Hi Andreas,

On 22.03.2013 17:05, Andreas Koch wrote:
> 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. 

And prior to sending either 8 bits or 16 bits, currently the correct USB
alternate interface has to be set, right?

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

Yes, especially given that if there's no common standard across
different devices, either the drivers or the applications have to
implement special handling code for this, and know which interface
supports what.

So for the ALSA layer, we should probably have a generic
SND_PCM_FORMAT_DSD and then rely on the sample rate setting mechanisms
to select the right DSD mode. Other solutions, like having a different
SND_PCM_FORMAT_DSD_{2_8,5_6,11_2}_MHZ would be hairy to implement, as
some devices need to get a sample rate update request, while others
don't etc ...

> 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.

Very interesting read. For ALSA though, it's no problem to support that
in all layers and make the drivers tell applications about it. We just
have to decide for a sane way :)

> 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. 

Yes, understood. The thing is just that we shouldn't break exising
solutions that already rely on this "bandaid".



Daniel

Re: Support for DSD streams

[Daniel Mack]

Hi Andreas,

On 23.03.2013 18:35, Andreas Koch wrote:
>> Yes, understood. The thing is just that we shouldn't break exising
>> solutions that already rely on this "bandaid".
> 
> You wouldn't break any existing solution based on DoP, because that 
> solution is dealt with in the application on one side and the DAC on 
> the other side. The driver and USB transfer both think it is PCM data 
> that is being sent.

Well, that was exactly the problem with your device. With the driver as
it was, it exposed a PCM interface which is 16-bit wide, and that was
picked by ALSA when playing 16-bit material (because ALSA takes whatever
is offered by the hardware natively).

> The applications have a preference setting to 
> select DoP and likewise the DAC's constantly monitor the PCM 
> formatted data stream and automatically switch to DSD if they find 
> the pattern. 

Hmm, but your device behaves differently here, right? At least, when
normal PCM material is sent to the DSD interface, it doesn't play it or
switch back or something. And I think other DACs will have similar
behaviour.

I need to think about all that more deeply next week :)


Daniel

Re: Support for DSD streams

[Daniel Mack]

On 24.03.2013 02:33, Andreas Koch wrote:
> Hi Daniel,
> 
> At 11:43 AM 3/23/2013, Daniel Mack wrote:
>> Hi Andreas,
>>
>> On 23.03.2013 18:35, Andreas Koch wrote:
>>>> Yes, understood. The thing is just that we shouldn't break exising
>>>> solutions that already rely on this "bandaid".
>>>
>>> You wouldn't break any existing solution based on DoP, because that
>>> solution is dealt with in the application on one side and the DAC on
>>> the other side. The driver and USB transfer both think it is PCM data
>>> that is being sent.
>>
>> Well, that was exactly the problem with your device. With the driver as
>> it was, it exposed a PCM interface which is 16-bit wide, and that was
>> picked by ALSA when playing 16-bit material (because ALSA takes whatever
>> is offered by the hardware natively).
> 
> Not quite - the 16-bit wide interface offered by my DAC is not PCM, 
> but raw data.

For the correct quirks handling, I'd need to know whether all products
with your vendor ID are DSD capable on alt interface settings > 1. Is
that assumption correct or should I narrow it down to the product ID of
the MPD-3?


Thanks,
Daniel

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

[Jussi Laako]

On 03/22/2013 06:05 PM, Andreas Koch wrote:
> 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,

I see, this is different from how I've been dealing with it. Since I 
always use uint8 format, but instead vary the rate to 352.8/705.6/etc...

Just because it's much more straightforward form the application's 
perspective -> output rate is always bit rate divided by eight (=packet 
rate). And switch between uint8 / uint32 sample format equals to switch 
between DSD <-> PCM.


	- Jussi

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

[Jussi Laako]

On 03/24/2013 03:50 AM, Andreas Koch wrote:
> rate for PCM. If you plug that DAC into a Mac, the Mac will
> automatically select 705.6kHz for PCM and then nothing will work because
> the DAC doesn't support that in PCM. So then, the DAC would have to
> define 2 complete interfaces: one for PCM and one for DSD. That

OK, the difference is that I don't use UAC2 at all, but completely 
different protocol. So what I'm talking about is only how it looks from 
the driver towards the application...

DoP could be implemented similar way inside the UAC driver using for 
example snd_pcm_hw_rule_add() between SNDRV_PCM_HW_PARAM_FORMAT and 
SNDRV_PCM_HW_PARAM_RATE. And maybe enabled as quirks?

There are many devices having constraints between rate and channels. In 
this case we just have a constraint between rate and formats.

Looking at the UAC driver there seems to be something a bit related:
                 /* FIXME: there is no AC3 format defined yet */
                 // fp->formats = SNDRV_PCM_FMTBIT_AC3;
                 fp->formats = SNDRV_PCM_FMTBIT_U8; /* temporary hack to 
receive
  byte streams */


	- Jussi

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

[Daniel Mack]

On 24.03.2013 11:50, Jussi Laako wrote:
> On 03/24/2013 03:50 AM, Andreas Koch wrote:
>> rate for PCM. If you plug that DAC into a Mac, the Mac will
>> automatically select 705.6kHz for PCM and then nothing will work because
>> the DAC doesn't support that in PCM. So then, the DAC would have to
>> define 2 complete interfaces: one for PCM and one for DSD. That
> 
> OK, the difference is that I don't use UAC2 at all, but completely 
> different protocol. So what I'm talking about is only how it looks from 
> the driver towards the application...

What protocol is that? Is there a driver for Linux?



Daniel

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

[Jussi Laako]

On 03/26/2013 09:34 PM, Daniel Mack wrote:
> What protocol is that? Is there a driver for Linux?

Just a custom flow-controlled bulk-mode byte stream. I have some hacks 
to make things work for my own prototype purposes, but I haven't got 
time to make anything clean and worth releasing.

There's not much point in releasing a driver that nobody else has 
hardware for... :)

I was hoping to discuss the ALSA sample format topic already earlier in 
context of getting DSD support to the RigiSystems USBPAL Linux driver, 
but it doesn't seem to be proceeding anywhere and I don't have necessary 
documentation (nor time)...
https://github.com/lintweaker/mytekusb2
I have the hardware though, so I can test & develop things at 
application side.


	- Jussi

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

[Daniel Mack]

Hi Andreas,

On 24.03.2013 02:50, Andreas Koch wrote:
> At 01:01 PM 3/23/2013, Jussi Laako wrote:
>> On 03/22/2013 06:05 PM, Andreas Koch wrote:
>>> 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,
>>
>> I see, this is different from how I've been dealing with it. Since I 
>> always use uint8 format, but instead vary the rate to 352.8/705.6/etc...
>>
>> Just because it's much more straightforward form the application's 
>> perspective -> output rate is always bit rate divided by eight 
>> (=packet rate). And switch between uint8 / uint32 sample format 
>> equals to switch between DSD <-> PCM.
> 
> Since the sample rate is defined on the interface level, not on the 
> alternate interface level, it becomes a problem to vary the sample 
> rate. For instance, for 5.6MHz DSD a sample rate of 705.6kHz would be 
> necessary with 8-bit data. But most likely the DAC will not support 
> that rate for PCM. If you plug that DAC into a Mac, the Mac will 
> automatically select 705.6kHz for PCM and then nothing will work 
> because the DAC doesn't support that in PCM. So then, the DAC would 
> have to define 2 complete interfaces: one for PCM and one for DSD. 
> That increases the size of the descriptor file (which can be a 
> problem with some hardware implementations) and increases the 
> overhead a bit during enumeration and sample rate queries. For the 
> hardware it is easier to bundle all into one single interface and 
> then define alternate interfaces for PCM and DSD.
> Just my 2 cents from the hardware perspective.

Ok. So we could define 3 DSD formats, for 8-bit, 16-bit and 32-bit. On
that three formats, arbitrary samples can be transported, and the
mapping between the configured sample rate and the resulting DSD rates
would be as follows (please tell me if I'm correct):

        352.8kHz       705.6KHz    1411.2KHz

8-bit     2.8MHz         5.6MHz      11.2MHz
16-bit    5.6MHz        11.2MHz
32-bit   11.2MHz

So driver would mark a stream as DSD capable (8, 16, 32bit, depending on
the USB descriptors), and then leave it up to the application to do the
sample frequency determination according to the above table, and also as
stated in the DoP document. Other drivers for more sound cards
(presumable on other bus types) might follow.

I think it's ok to handle it like this, because after all, what an
application sets as sample rate for the stream is the number of actual
words that are transported, where as the DSD rate is referring to bits/s.

Jussi, for your application, that means that you'd have to add these 3
new formats, and teach your application that they can be used for DSD
right away.

The question is whether all DSD-capable USB DACs behave correctly in
order to make this logic work. Andreas?


Thanks,
Daniel

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

[Clemens Ladisch]

Andreas Koch wrote:
> ... your driver would send the DSD data in whatever format the DAC
> requests via its descriptors. [...] The only potential fly in the
> ointment is that we assume that the raw data format means DSD.

Add some vendor-specific descriptor to specify that raw means DSD.


Regards,
Clemens

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

[Daniel Mack]

On 27.03.2013 06:50, Andreas Koch wrote:
> Hi Daniel
> 
>> Ok. So we could define 3 DSD formats, for 8-bit, 16-bit and 32-bit. On
>> that three formats, arbitrary samples can be transported, and the
>> mapping between the configured sample rate and the resulting DSD rates
>> would be as follows (please tell me if I'm correct):
>>
>>         352.8kHz       705.6KHz    1411.2KHz
>>
>> 8-bit     2.8MHz         5.6MHz      11.2MHz
>> 16-bit    5.6MHz        11.2MHz
>> 32-bit   11.2MHz
>>
>> So driver would mark a stream as DSD capable (8, 16, 32bit, depending on
>> the USB descriptors), and then leave it up to the application to do the
>> sample frequency determination according to the above table, and also as
>> stated in the DoP document. Other drivers for more sound cards
>> (presumable on other bus types) might follow.
>>
>> I think it's ok to handle it like this, because after all, what an
>> application sets as sample rate for the stream is the number of actual
>> words that are transported, where as the DSD rate is referring to bits/s.
>>
>> Jussi, for your application, that means that you'd have to add these 3
>> new formats, and teach your application that they can be used for DSD
>> right away.
>>
>> The question is whether all DSD-capable USB DACs behave correctly in
>> order to make this logic work. Andreas?
> 
> If I understand this correctly then your driver would send the DSD 
> data in whatever format the DAC requests via its descriptors. The DSD 
> rate would either control the word length (8,16,32) or the underlying 
> sample rate (1x, 2x, 4x 352.8kHz). That would be the most flexible 
> implementation and I don't see why any hardware implementation would 
> have a problem with that.

The question is whether all DACs would assume the same DSD rate as in
the table above (ie, 8-bit, 352.8kHz == 2.8MHz DSD).

And do we actually need a 32-bit format at all or is 8 and 16 enough?

> The only potential fly in the ointment is 
> that we assume that the raw data format means DSD. In other words, if 
> a DAC uses raw data for any other purpose with similar wordlength 
> and/or sample rate spec. then we are in trouble. The chance for that 
> is small though.

As there's nothing the UAC2 spec helps us with, we have to live with
quirks for that.


Daniel

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

[Daniel Mack]

On 27.03.2013 16:08, Andreas Koch wrote:
> At 02:48 AM 3/27/2013, Daniel Mack wrote:
>> On 27.03.2013 06:50, Andreas Koch wrote:
>>> Hi Daniel
>>>
>>>> Ok. So we could define 3 DSD formats, for 8-bit, 16-bit and 32-bit. On
>>>> that three formats, arbitrary samples can be transported, and the
>>>> mapping between the configured sample rate and the resulting DSD rates
>>>> would be as follows (please tell me if I'm correct):
>>>>
>>>>         352.8kHz       705.6KHz    1411.2KHz
>>>>
>>>> 8-bit     2.8MHz         5.6MHz      11.2MHz
>>>> 16-bit    5.6MHz        11.2MHz
>>>> 32-bit   11.2MHz
>>>>
>>>> So driver would mark a stream as DSD capable (8, 16, 32bit, depending on
>>>> the USB descriptors), and then leave it up to the application to do the
>>>> sample frequency determination according to the above table, and also as
>>>> stated in the DoP document. Other drivers for more sound cards
>>>> (presumable on other bus types) might follow.
>>>>
>>>> I think it's ok to handle it like this, because after all, what an
>>>> application sets as sample rate for the stream is the number of actual
>>>> words that are transported, where as the DSD rate is referring to bits/s.
>>>>
>>>> Jussi, for your application, that means that you'd have to add these 3
>>>> new formats, and teach your application that they can be used for DSD
>>>> right away.
>>>>
>>>> The question is whether all DSD-capable USB DACs behave correctly in
>>>> order to make this logic work. Andreas?
>>>
>>> If I understand this correctly then your driver would send the DSD
>>> data in whatever format the DAC requests via its descriptors. The DSD
>>> rate would either control the word length (8,16,32) or the underlying
>>> sample rate (1x, 2x, 4x 352.8kHz). That would be the most flexible
>>> implementation and I don't see why any hardware implementation would
>>> have a problem with that.
>>
>> The question is whether all DACs would assume the same DSD rate as in
>> the table above (ie, 8-bit, 352.8kHz == 2.8MHz DSD).
> 
> I don't see how they could assume any different rate, so yes, that 
> seems a good assumption.

Ok, good.

>> And do we actually need a 32-bit format at all or is 8 and 16 enough?
> 
> Clearly, main stream is 2.8MHz DSD. But there are new A/D and D/A 
> chips becoming available that support up to  11.2MHz. So far I 
> haven't really seen any performance gain with that, but one  never 
> knows what improvements will be made in the future. If that is a 
> problem on your side I wouldn't spend so much time on it, but if it 
> is a matter of just adding a few lines then why not.

It a bit in a 64bit field, so its a limited resource. If there's no need
for it, I'll leave it out for now.

I'll send out some trivial patches for DSD stream marking soon.



Thanks,
Daniel

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

[Jussi Laako]

On 03/27/2013 05:08 PM, Andreas Koch wrote:
> Clearly, main stream is 2.8MHz DSD. But there are new A/D and D/A chips
> becoming available that support up to  11.2MHz. So far I haven't really

And many DACs actually support also the 48k-base rates of 3.0/6.1/12.2 
MHz. But of course from API point of view that's trivial.


	- Jussi

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

[Jussi Laako]

Hi Daniel,

On 03/26/2013 09:58 PM, Daniel Mack wrote:
> Jussi, for your application, that means that you'd have to add these 3
> new formats, and teach your application that they can be used for DSD
> right away.

Looks good to me. This is what I was hoping for. I already kind of have 
the 8-bit and 32-bit, but I'll need to add the 16-bit one and make some 
related code cleanups to make things proper now since it's becoming 
official format.

I'll put this into my 3.0 release. :)


Thanks,

	- Jussi

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

[Daniel Mack]

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?


Thanks,
Daniel

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

[Jussi Laako]

On 03/22/2013 03:27 AM, Andreas Koch wrote:
> I wouldn't worry about DSD wide, because that is a dead format that I
> was involved in launching for professional recording applications more
> than 10 years ago. It never took off.

I just need it for my own purposes, but I can make custom stuff as 
necessary if there's no interest from others.

Right now I'm just hoping to see a well defined common sample formats 
defined for ALSA that can be utilized by drivers. DoP could be 
implemented inside the driver or at ALSA layer instead of applications 
doing it. Not that I would mind, but I would find it cleaner than the 
current approach... :)

Currently, ASIO is the only API to support DSD sample formats. I 
understand that Microsoft or Apple is a slow to turn giant, but I'd hope 
ALSA wouldn't be such. ;)

There are already those IEC958 and DD/dts things being used for movie 
playback, so this wouldn't be such a big difference afterall.


	- Jussi

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

[Takashi Iwai]

At Fri, 22 Mar 2013 12:15:16 +0200,
Jussi Laako wrote:
> 
> On 03/22/2013 03:27 AM, Andreas Koch wrote:
> > I wouldn't worry about DSD wide, because that is a dead format that I
> > was involved in launching for professional recording applications more
> > than 10 years ago. It never took off.
> 
> I just need it for my own purposes, but I can make custom stuff as 
> necessary if there's no interest from others.
> 
> Right now I'm just hoping to see a well defined common sample formats 
> defined for ALSA that can be utilized by drivers. DoP could be 
> implemented inside the driver or at ALSA layer instead of applications 
> doing it. Not that I would mind, but I would find it cleaner than the 
> current approach... :)
> 
> Currently, ASIO is the only API to support DSD sample formats. I 
> understand that Microsoft or Apple is a slow to turn giant, but I'd hope 
> ALSA wouldn't be such. ;)

As Daniel already mentioned, adding a format type is trivial.  It
needs to be patched in different layers, though.  But, the action is
easy.

More important question is how consistent the format is.  If it's a
device-specific closed format, it's not suitable as a standard format
definition in the API level.

> There are already those IEC958 and DD/dts things being used for movie 
> playback, so this wouldn't be such a big difference afterall.

IEC958 itself is a well-defined format as a container.  So we actually
have no definition for DD/DTS in the ALSA API level at all.


Takashi

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

[Jussi Laako]

On 03/22/2013 12:23 PM, Takashi Iwai wrote:
> More important question is how consistent the format is.  If it's a
> device-specific closed format, it's not suitable as a standard format
> definition in the API level.

At least the ASIO way of two uint8_t based MSB/LSB formats is pretty 
much the standard common denominator. Rest of the possibly needed data 
arrangement can be handled by the driver.

For the DoP output it is already defined by Andreas:
http://dsd-guide.com/dop-open-standard

Which corresponds to the uint8_t with oldest bit in MSB. I'm now doing 
the packing for both packing styles in the application before sending it 
through ALSA. However, it would be cleaner for application to send 
uint8_t packets and handle the packing at driver level. Those pieces of 
custom USB hardware that don't use DoP but send raw DSD stream usually 
use either uint8_t or uint32_t containers. So the uint8_t is the lowest 
common denominator. So we wouldn't need to worry about the byte order in 
addition to bit order...


	- Jussi

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

[Gabriel M. Beddingfield]

On 03/18/2013 02:07 AM, Takashi Iwai wrote:
>
> 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.

I got the impression that SND_PCM_FORMAT_SPECIAL was there for 
appication-specific/device-specific hacks.  I.e. it's a non-format that 
allows passing raw data through the system.  If so, is it appropriate 
for a main-line driver?

-gabriel

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

[Takashi Iwai]

At Mon, 18 Mar 2013 19:37:51 -0700,
Gabriel M. Beddingfield wrote:
> 
> On 03/18/2013 02:07 AM, Takashi Iwai wrote:
> >
> > 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.
> 
> I got the impression that SND_PCM_FORMAT_SPECIAL was there for 
> appication-specific/device-specific hacks.  I.e. it's a non-format that 
> allows passing raw data through the system.  If so, is it appropriate 
> for a main-line driver?

It allows everything, but it also means there is no specification.


Takashi