Re: [PATCH v3 5/5] ALSA: snd-usb: add quirks handler for DSD streams

Re: [PATCH v3 5/5] ALSA: snd-usb: add quirks handler for DSD streams

[Jesus R]

Daniel/team, I have access to a few DSD devices and or USB based devices. I
can provide any information you need to help with allowing ALSA to identify
the device's capabilities. Just let me know how to get the information you
need from command line:)

I also have a list of known DSD/DoP devices in Google Drive that may be
helpful. Let me know if it's okay to post the link.

Jesus R
sonore.us

[PATCH v3 5/5] ALSA: snd-usb: add quirks handler for DSD streams

[Jesus R]

Daniel/team, I have access to a few DSD devices and or USB based devices. I
can provide any information you need to help with allowing ALSA to identify
the device's capabilities. Just let me know how to get the information you
need from command line:)

I also have a list of known DSD/DoP devices in Google Drive that may be
helpful. Let me know if it's okay to post the link.

Jesus R
sonore.us

Re: [PATCH v3 5/5] ALSA: snd-usb: add quirks handler for DSD streams

[Daniel Mack]

On 11.08.2013 18:37, Jesus R wrote:
> Daniel/team, I have access to a few DSD devices and or USB based devices. I
> can provide any information you need to help with allowing ALSA to identify
> the device's capabilities. Just let me know how to get the information you
> need from command line:)

Nice. I take it those devices are DOP-capable?

Given than none of devices have a chance to report their capabilities to
the host, finding out which modes to use is a trial-and-error game,
unless you have access to the firmware sources.

Hence, please just look up the USB IDs and alternate interface settings
of your connected device with lsusb, and then augment the code in
snd_usb_interface_dsd_format_quirks() (file sound/usb/quirks.c) and play
around with different possibilities (bitreverse on/off, DSD_U8 vs
DSD_U16 etc). Follow the example that I provided in that function.

You have to recompile and rmmod/insmod the snd-usb driver every time you
make a change, and then you need some sort of userspace tool to test it.
I published one here:

 https://github.com/zonque/alsa-dsd-player


Once you have more quirks sorted out, please send a patch. I'm sorry
there's no easier way to work on this. Let me know if you need more
instructions.


Thanks,
Daniel

Re: [PATCH v3 5/5] ALSA: snd-usb: add quirks handler for DSD streams

[Daniel Mack]

[please never drop people from the Cc: list but always use 'reply to all'!]

On 12.08.2013 13:27, Jesus R wrote:
> On Mon, Aug 12, 2013 at 4:52 AM, Daniel Mack <zonque@gmail.com
> <mailto:zonque@gmail.com>> wrote:

>     Given than none of devices have a chance to report their capabilities to
>     the host, finding out which modes to use is a trial-and-error game,
>     unless you have access to the firmware sources.    
> 
> 
>     Hence, please just look up the USB IDs and alternate interface settings
>     of your connected device with lsusb, and then augment the code in
>     snd_usb_interface_dsd_format_quirks() (file sound/usb/quirks.c) and play
>     around with different possibilities (bitreverse on/off, DSD_U8 vs
>     DSD_U16 etc). Follow the example that I provided in that function.
> 
> Right now MPD supports DSD/DoP with one selectable on/off option. On
> equals DoP output and off equals conversion to PCM. I'm not aware of any
> case where it does not work. I would seem to me that there is one
> predominant format?

It's more complicated than that. Applications were always free to use a
usual PCM stream and stuff it with DOP/DSD samples. This is the whole
idea of DOP: allow applications to transport DSD samples via regular
audio streams. The downside of this is that applications are in charge
of adding the DOP markers manually, and information about bit-reversing
and marker format (8 bit vs. 16 bit) is up to the application, which is
not the right place for it.

The patch series I brought in addressed this in a way that all that
information about device-specific details is now known to the kernel,
which can hence offer a standard compliant interface to userspace.

[There's yet one more level of confusion as some file formats store the
samples bit-reversed, but there's nothing we can do about that from
kernel space except for defining a stable interface application have to
obey to in order to be compatible. That is, samples are expected to
always carry the oldest bit in the most significant bit of a byte.]

So my question is: are you 100% sure that MPD uses the newly introduces
ALSA formats, or are they doing the DOP conversion in manually in their
own software layers?

>     You have to recompile and rmmod/insmod the snd-usb driver every time you
>     make a change, and then you need some sort of userspace tool to test it.
>     I published one here:
> 
> This may be more than I can do. Can you add the options (bitreverse
> on/off, DSD_U8 vs
> DSD_U16 etc) to the alas-dsd-player? This would allow me to quickly test
> the devices.    

There are #if0'ed blocks that you can opt-in for bit reversal, but as
the marker format is different for 8 and 16 bits, and up to the kernel
space now, the dsd player does not know about them. That was the entire
intention of bringing that logic to kernel space in the first place.

> Take a look at the DSD database so you can see what we are up against. I
> could even add the tests results to the database.
> https://docs.google.com/spreadsheet/ccc?key=0AgVhKcl_3lHfdFVyenBBNjNpQ2lieG81WGpqQTNfVUE#gid=0

Nice list. Only devics with USB interface are interesting at this point,
but that's a good start.

As I said: you need to add the quirks for the devices to the quirks
list. Other than that, there's no chance to test them.

Copy'n pasting code inside that function and recompiling the kernel is
really not as hard as you might think it is. Just search the internet
for "compile kernel git <your-distribution-here>" and follow the links.


Thanks,
Daniel

Re: [PATCH v3 5/5] ALSA: snd-usb: add quirks handler for DSD streams

[Jesus R]

On Mon, Aug 12, 2013 at 7:43 AM, Daniel Mack <zonque@gmail.com> wrote:

> [please never drop people from the Cc: list but always use 'reply to all'!]
>
sorry I didn't notice..

>
> On 12.08.2013 13:27, Jesus R wrote:
> > On Mon, Aug 12, 2013 at 4:52 AM, Daniel Mack <zonque@gmail.com
> > <mailto:zonque@gmail.com>> wrote:
>
> >     Given than none of devices have a chance to report their
> capabilities to
> >     the host, finding out which modes to use is a trial-and-error game,
> >     unless you have access to the firmware sources.
> >
> >
> >     Hence, please just look up the USB IDs and alternate interface
> settings
> >     of your connected device with lsusb, and then augment the code in
> >     snd_usb_interface_dsd_format_quirks() (file sound/usb/quirks.c) and
> play
> >     around with different possibilities (bitreverse on/off, DSD_U8 vs
> >     DSD_U16 etc). Follow the example that I provided in that function.
> >
> > Right now MPD supports DSD/DoP with one selectable on/off option. On
> > equals DoP output and off equals conversion to PCM. I'm not aware of any
> > case where it does not work. I would seem to me that there is one
> > predominant format?
>
> It's more complicated than that. Applications were always free to use a
> usual PCM stream and stuff it with DOP/DSD samples. This is the whole
> idea of DOP: allow applications to transport DSD samples via regular
> audio streams. The downside of this is that applications are in charge
> of adding the DOP markers manually, and information about bit-reversing
> and marker format (8 bit vs. 16 bit) is up to the application, which is
> not the right place for it.
>
The majority of devices only support up to 192K. These only support DSD64
via DoP using 176.4K and you can automatically assume 16 bit. The remaining
devices support up to 384K. These support DSD64 via DoP using 176.4K
and DSD128 via DoP using 384K. Again you have to assume 16 bit. I'm not
aware of any devices that support 705.6K that also support DSD/DoP, but
someone will do it.

>
> The patch series I brought in addressed this in a way that all that
> information about device-specific details is now known to the kernel,
> which can hence offer a standard compliant interface to userspace.
>
> [There's yet one more level of confusion as some file formats store the
> samples bit-reversed, but there's nothing we can do about that from
> kernel space except for defining a stable interface application have to
> obey to in order to be compatible. That is, samples are expected to
> always carry the oldest bit in the most significant bit of a byte.]
>
> So my question is: are you 100% sure that MPD uses the newly introduces
> ALSA formats, or are they doing the DOP conversion in manually in their
> own software layers?
>
MPD is doing the DoP conversion.

>
> >     You have to recompile and rmmod/insmod the snd-usb driver every time
> you
> >     make a change, and then you need some sort of userspace tool to test
> it.
> >     I published one here:
> >
> > This may be more than I can do. Can you add the options (bitreverse
> > on/off, DSD_U8 vs
> > DSD_U16 etc) to the alas-dsd-player? This would allow me to quickly test
> > the devices.
>
> There are #if0'ed blocks that you can opt-in for bit reversal, but as
> the marker format is different for 8 and 16 bits, and up to the kernel
> space now, the dsd player does not know about them. That was the entire
> intention of bringing that logic to kernel space in the first place.
>
> > Take a look at the DSD database so you can see what we are up against. I
> > could even add the tests results to the database.
> >
> https://docs.google.com/spreadsheet/ccc?key=0AgVhKcl_3lHfdFVyenBBNjNpQ2lieG81WGpqQTNfVUE#gid=0
>
> Nice list. Only devics with USB interface are interesting at this point,
> but that's a good start.
>
Understood.

>
> As I said: you need to add the quirks for the devices to the quirks
> list. Other than that, there's no chance to test them.
>
> Copy'n pasting code inside that function and recompiling the kernel is
> really not as hard as you might think it is. Just search the internet
> for "compile kernel git <your-distribution-here>" and follow the links.
>
I can compile something with luck on my side, but I'm not coder.

>
>
> Thanks,
> Daniel
>
>

Re: [PATCH v3 5/5] ALSA: snd-usb: add quirks handler for DSD streams

[Daniel Mack]

On 12.08.2013 13:27, Jesus R wrote:
> On Mon, Aug 12, 2013 at 4:52 AM, Daniel Mack <zonque@gmail.com
> <mailto:zonque@gmail.com>> wrote:

> Right now MPD supports DSD/DoP with one selectable on/off option. On
> equals DoP output and off equals conversion to PCM. I'm not aware of any
> case where it does not work. I would seem to me that there is one
> predominant format? 

Let me clarify that again: I read the above as the two options are

a) DSD material is augmented by DOP markers and send as such over a
regular PCM interface, or

b) convert DSD to PCM in software and then send PCM samples over a
regular PCM interface.


What applications need to use for my new approach is another is:

c) take DSD samples, bit reverse them if necessary, and then send them
over the generic DSD data pipe to the Linux kernel. Device-specific
details are taken care of by the kernel layer.


I'm not aware of any software that uses that new DSD format type
directly except for my example program.


Daniel

Re: [PATCH v3 5/5] ALSA: snd-usb: add quirks handler for DSD streams

[Jesus R]

On Mon, Aug 12, 2013 at 7:52 AM, Daniel Mack <zonque@gmail.com> wrote:

> On 12.08.2013 13:27, Jesus R wrote:
> > On Mon, Aug 12, 2013 at 4:52 AM, Daniel Mack <zonque@gmail.com
> > <mailto:zonque@gmail.com>> wrote:
>
> > Right now MPD supports DSD/DoP with one selectable on/off option. On
> > equals DoP output and off equals conversion to PCM. I'm not aware of any
> > case where it does not work. I would seem to me that there is one
> > predominant format?
>
> Let me clarify that again: I read the above as the two options are
>
> a) DSD material is augmented by DOP markers and send as such over a
> regular PCM interface, or
>
> b) convert DSD to PCM in software and then send PCM samples over a
> regular PCM interface.
>
>
> What applications need to use for my new approach is another is:
>
> c) take DSD samples, bit reverse them if necessary, and then send them
> over the generic DSD data pipe to the Linux kernel. Device-specific
> details are taken care of by the kernel layer.
>
Yes, I understood this. I'm not sure what MPD will do going forward though.
The end goal should be DoP as needed and native DSD if supported.

>
>
> I'm not aware of any software that uses that new DSD format type
> directly except for my example program.
>
Jussi might be using it:) I'm going to propose it to a project I'm involved
in..

>
>
> Daniel
>
>

[PATCH v3 0/5] ALSA: snd-usb: add support for DSD

[Daniel Mack]

In contrast to the first two approaches, this one keeps the userspace
unaware of the actual transport on the bus.

More specifically, the DSD_U16_LE format may be implemented to actually
send DOP samples to the device, depending on the quirks entries.

Also, as there is quite some confusion in both data file formats as
well as hardware sample formats about whether to stuff the oldest bit
in the MSB or the LSB of a byte, ALSA defines that now to be in the
MSB, as far as the ALSA userspace layer is concerned. The driver
learned functions to re-encode the bytes according to what the hardware
supports.

I also wrote a very basic test tool which I published here:

  https://github.com/zonque/alsa-dsd-player


Thanks,
Daniel

Daniel Mack (5):
  ALSA: add DSD formats
  ALSA: snd-usb: use ep->stride from urb callbacks
  ALSA: snd-usb: add support for DSD DOP stream transport
  ALSA: snd-usb: add support for bit-reversed byte formats
  ALSA: snd-usb: add quirks handler for DSD streams

 include/sound/pcm.h         |    2 +
 include/uapi/sound/asound.h |    4 +-
 sound/core/pcm.c            |    2 +
 sound/core/pcm_misc.c       |    8 +++
 sound/usb/card.h            |    8 +++
 sound/usb/endpoint.c        |    9 ++++
 sound/usb/format.c          |    3 ++
 sound/usb/pcm.c             |  118 ++++++++++++++++++++++++++++++++++++-------
 sound/usb/quirks.c          |   28 ++++++++++
 sound/usb/quirks.h          |    4 ++
 10 files changed, 167 insertions(+), 19 deletions(-)

-- 
1.7.10.4

[PATCH v3 5/5] ALSA: snd-usb: add quirks handler for DSD streams

[Daniel Mack]

Unfortunately, none of the UAC standards provides a way to identify DSD
(Direct Stream Digital) formats. Hence, this patch adds a quirks
handler to identify USB interfaces that are capable of handling DSD.

That quirks handler can augment the already parsed formats bit-field,
by any of the new SNDRV_PCM_FMTBIT_DSD_{U8_U16} and setting the dsd_dop
flag in the audio format, if the driver should take care for the DOP
byte stuffing.

The only devices that are known to work with this are the ones with
a 'Playback Designs' vendor id.

Signed-off-by: Daniel Mack <zonque@gmail.com>
---
 sound/usb/format.c |    3 +++
 sound/usb/quirks.c |   28 ++++++++++++++++++++++++++++
 sound/usb/quirks.h |    4 ++++
 3 files changed, 35 insertions(+)

diff --git a/sound/usb/format.c b/sound/usb/format.c
index 20c7751..020ede0 100644
--- a/sound/usb/format.c
+++ b/sound/usb/format.c
@@ -136,6 +136,9 @@ static u64 parse_audio_format_i_type(struct snd_usb_audio *chip,
 		snd_printk(KERN_INFO "%d:%u:%d : unsupported format bits %#x\n",
 			   chip->dev->devnum, fp->iface, fp->altsetting, format);
 	}
+
+	pcm_formats |= snd_usb_interface_dsd_format_quirks(chip, fp, sample_bytes);
+
 	return pcm_formats;
 }
 
diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index 2927981..4c6366c 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -915,3 +915,31 @@ void snd_usb_ctl_msg_quirk(struct usb_device *dev, unsigned int pipe,
 		mdelay(20);
 }
 
+/*
+ * snd_usb_interface_dsd_format_quirks() is called from format.c to
+ * augment the PCM format bit-field for DSD types. The UAC standards
+ * don't have a designated bit field to denote DSD-capable interfaces,
+ * hence all hardware that is known to support this format has to be
+ * listed here.
+ */
+u64 snd_usb_interface_dsd_format_quirks(struct snd_usb_audio *chip,
+					struct audioformat *fp,
+					unsigned int sample_bytes)
+{
+	/* Playback Designs */
+	if (le16_to_cpu(chip->dev->descriptor.idVendor) == 0x23ba) {
+		switch (fp->altsetting) {
+		case 1:
+			fp->dsd_dop = true;
+			return SNDRV_PCM_FMTBIT_DSD_U16_LE;
+		case 2:
+			fp->dsd_bitrev = true;
+			return SNDRV_PCM_FMTBIT_DSD_U8;
+		case 3:
+			fp->dsd_bitrev = true;
+			return SNDRV_PCM_FMTBIT_DSD_U16_LE;
+		}
+	}
+
+	return 0;
+}
diff --git a/sound/usb/quirks.h b/sound/usb/quirks.h
index 7c3681f..665e972 100644
--- a/sound/usb/quirks.h
+++ b/sound/usb/quirks.h
@@ -31,4 +31,8 @@ void snd_usb_ctl_msg_quirk(struct usb_device *dev, unsigned int pipe,
 			   __u8 request, __u8 requesttype, __u16 value,
 			   __u16 index, void *data, __u16 size);
 
+u64 snd_usb_interface_dsd_format_quirks(struct snd_usb_audio *chip,
+					struct audioformat *fp,
+					unsigned int sample_bytes);
+
 #endif /* __USBAUDIO_QUIRKS_H */
-- 
1.7.10.4