March 2013 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] Guide to USB debugging in Windows?
by Martin Cracauer 30 Mar '13

30 Mar '13

Does anyone have instructions on how to use a USB traffic monitor on windows to extract some bits needed to control a sound device under ALSA? As in, for people not normally developing in windows? I have here a Sound Devices USBPre v1. It is mostly USB 1.1 sound interface compatible and it accepts a stream played from ALSA under Linux just fine. The problem is that the manufacturer has decided to, in addition to the standard usb sound interface, have all the different inputs on the device behind on/off switches, all of them controlled by secret bits in the windows and mac drivers, all of them default to off. So thingie is a brick as-is. I don't blame them too hard, they now make a v2 of this devices and fixed it. Just so that I don't appear more insane than usual, let me say why I want to bother. The windows drivers for this are only available in 32 bit, and the mac drivers are 32 bit only as well, in addition the mac drivers never went > 16bit/48KHz. The inability to use this on modern macs and windows machines has pushed the price of these things very low on Ebay, considering it is a fully professional device with the best mic preamps you can get. If would be really cool if this could work under ALSA, and as you see I figured it needs just a couple of bits that you need to flip with some magic to at least get it to run up to 16bit/48KHz. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer(a)cons.org> http://www.cons.org/cracauer/

3 2

[alsa-devel] [PATCH v2] ASoC: mid-x86 - add support for meaadata apis
by Vinod Koul 29 Mar '13

29 Mar '13

while at it, update the copyright timeline too Signed-off-by: Jeeja KP <jeeja.kp(a)intel.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> --- v2: fix the missing header inclusion in patch sound/soc/mid-x86/sst_platform.c | 12 +++++++++++- sound/soc/mid-x86/sst_platform.h | 2 ++ 2 files changed, 13 insertions(+), 1 deletions(-) diff --git a/sound/soc/mid-x86/sst_platform.c b/sound/soc/mid-x86/sst_platform.c index a263cbe..968656c 100644 --- a/sound/soc/mid-x86/sst_platform.c +++ b/sound/soc/mid-x86/sst_platform.c @@ -1,7 +1,7 @@ /* * sst_platform.c - Intel MID Platform driver * - * Copyright (C) 2010-2012 Intel Corp + * Copyright (C) 2010-2013 Intel Corp * Author: Vinod Koul <vinod.koul(a)intel.com> * Author: Harsha Priya <priya.harsha(a)intel.com> * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -652,11 +652,21 @@ static int sst_platform_compr_get_codec_caps(struct snd_compr_stream *cstream, return stream->compr_ops->get_codec_caps(codec); } +static int sst_platform_compr_set_metadata(struct snd_compr_stream *cstream, + struct snd_compr_metadata *metadata) +{ + struct sst_runtime_stream *stream = + cstream->runtime->private_data; + + return stream->compr_ops->set_metadata(stream->id, metadata); +} + static struct snd_compr_ops sst_platform_compr_ops = { .open = sst_platform_compr_open, .free = sst_platform_compr_free, .set_params = sst_platform_compr_set_params, + .set_metadata = sst_platform_compr_set_metadata, .trigger = sst_platform_compr_trigger, .pointer = sst_platform_compr_pointer, .ack = sst_platform_compr_ack, diff --git a/sound/soc/mid-x86/sst_platform.h b/sound/soc/mid-x86/sst_platform.h index d61c5d5..cacc906 100644 --- a/sound/soc/mid-x86/sst_platform.h +++ b/sound/soc/mid-x86/sst_platform.h @@ -124,6 +124,8 @@ struct compress_sst_ops { int (*close) (unsigned int str_id); int (*get_caps) (struct snd_compr_caps *caps); int (*get_codec_caps) (struct snd_compr_codec_caps *codec); + int (*set_metadata) (unsigned int str_id, + struct snd_compr_metadata *mdata); }; -- 1.7.0.4

2 1

[alsa-devel] [PATCH] ASoC: wm_adsp: Split ADSP1 and ADSP2 firmware controls
by Mark Brown 29 Mar '13

29 Mar '13

Now that we have regular register mapped controls we should be splitting the control sets for ADSP1 and ADSP2 as the register maps are not identical. Do that. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm2200.c | 2 +- sound/soc/codecs/wm5102.c | 2 +- sound/soc/codecs/wm_adsp.c | 26 +++++++++++++++++++------- sound/soc/codecs/wm_adsp.h | 3 ++- 4 files changed, 23 insertions(+), 10 deletions(-) diff --git a/sound/soc/codecs/wm2200.c b/sound/soc/codecs/wm2200.c index ddc98f0..57ba315 100644 --- a/sound/soc/codecs/wm2200.c +++ b/sound/soc/codecs/wm2200.c @@ -1565,7 +1565,7 @@ static int wm2200_probe(struct snd_soc_codec *codec) return ret; } - ret = snd_soc_add_codec_controls(codec, wm_adsp_fw_controls, 2); + ret = snd_soc_add_codec_controls(codec, wm_adsp1_fw_controls, 2); if (ret != 0) return ret; diff --git a/sound/soc/codecs/wm5102.c b/sound/soc/codecs/wm5102.c index d1b43eb..cb03cc4 100644 --- a/sound/soc/codecs/wm5102.c +++ b/sound/soc/codecs/wm5102.c @@ -1572,7 +1572,7 @@ static int wm5102_codec_probe(struct snd_soc_codec *codec) if (ret != 0) return ret; - ret = snd_soc_add_codec_controls(codec, wm_adsp_fw_controls, 2); + ret = snd_soc_add_codec_controls(codec, wm_adsp2_fw_controls, 2); if (ret != 0) return ret; diff --git a/sound/soc/codecs/wm_adsp.c b/sound/soc/codecs/wm_adsp.c index 3a481fd..bc03bae 100644 --- a/sound/soc/codecs/wm_adsp.c +++ b/sound/soc/codecs/wm_adsp.c @@ -247,7 +247,18 @@ static const struct soc_enum wm_adsp_fw_enum[] = { SOC_ENUM_SINGLE(0, 3, ARRAY_SIZE(wm_adsp_fw_text), wm_adsp_fw_text), }; -static const struct soc_enum wm_adsp_rate_enum[] = { +const struct snd_kcontrol_new wm_adsp1_fw_controls[] = { + SOC_ENUM_EXT("DSP1 Firmware", wm_adsp_fw_enum[0], + wm_adsp_fw_get, wm_adsp_fw_put), + SOC_ENUM_EXT("DSP2 Firmware", wm_adsp_fw_enum[1], + wm_adsp_fw_get, wm_adsp_fw_put), + SOC_ENUM_EXT("DSP3 Firmware", wm_adsp_fw_enum[2], + wm_adsp_fw_get, wm_adsp_fw_put), +}; +EXPORT_SYMBOL_GPL(wm_adsp1_fw_controls); + +#if IS_ENABLED(CONFIG_SND_SOC_ARIZONA) +static const struct soc_enum wm_adsp2_rate_enum[] = { SOC_VALUE_ENUM_SINGLE(ARIZONA_DSP1_CONTROL_1, ARIZONA_DSP1_RATE_SHIFT, 0xf, ARIZONA_RATE_ENUM_SIZE, @@ -266,21 +277,22 @@ static const struct soc_enum wm_adsp_rate_enum[] = { arizona_rate_text, arizona_rate_val), }; -const struct snd_kcontrol_new wm_adsp_fw_controls[] = { +const struct snd_kcontrol_new wm_adsp2_fw_controls[] = { SOC_ENUM_EXT("DSP1 Firmware", wm_adsp_fw_enum[0], wm_adsp_fw_get, wm_adsp_fw_put), - SOC_ENUM("DSP1 Rate", wm_adsp_rate_enum[0]), + SOC_ENUM("DSP1 Rate", wm_adsp2_rate_enum[0]), SOC_ENUM_EXT("DSP2 Firmware", wm_adsp_fw_enum[1], wm_adsp_fw_get, wm_adsp_fw_put), - SOC_ENUM("DSP2 Rate", wm_adsp_rate_enum[1]), + SOC_ENUM("DSP2 Rate", wm_adsp2_rate_enum[1]), SOC_ENUM_EXT("DSP3 Firmware", wm_adsp_fw_enum[2], wm_adsp_fw_get, wm_adsp_fw_put), - SOC_ENUM("DSP3 Rate", wm_adsp_rate_enum[2]), + SOC_ENUM("DSP3 Rate", wm_adsp2_rate_enum[2]), SOC_ENUM_EXT("DSP4 Firmware", wm_adsp_fw_enum[3], wm_adsp_fw_get, wm_adsp_fw_put), - SOC_ENUM("DSP4 Rate", wm_adsp_rate_enum[3]), + SOC_ENUM("DSP4 Rate", wm_adsp2_rate_enum[3]), }; -EXPORT_SYMBOL_GPL(wm_adsp_fw_controls); +EXPORT_SYMBOL_GPL(wm_adsp2_fw_controls); +#endif static struct wm_adsp_region const *wm_adsp_find_region(struct wm_adsp *dsp, int type) diff --git a/sound/soc/codecs/wm_adsp.h b/sound/soc/codecs/wm_adsp.h index cb8871a..9f90c9f 100644 --- a/sound/soc/codecs/wm_adsp.h +++ b/sound/soc/codecs/wm_adsp.h @@ -65,7 +65,8 @@ struct wm_adsp { .shift = num, .event = wm_adsp2_event, \ .event_flags = SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD } -extern const struct snd_kcontrol_new wm_adsp_fw_controls[]; +extern const struct snd_kcontrol_new wm_adsp1_fw_controls[]; +extern const struct snd_kcontrol_new wm_adsp2_fw_controls[]; int wm_adsp1_init(struct wm_adsp *adsp); int wm_adsp2_init(struct wm_adsp *adsp, bool dvfs); -- 1.7.10.4

1 0

[alsa-devel] [PATCH] ASoC: Implement mixer control sharing
by Stephen Warren 29 Mar '13

29 Mar '13

From: Stephen Warren <swarren(a)nvidia.com> This is the equivalent of commit af46800 "ASoC: Implement mux control sharing", but applied to mixers instead of muxes. This allows a single control to affect multiple mixer widgets at once, which is useful when there is a single set of register bits that affects both multiple mixers in HW, for example both the L and R mixers of a stereo path. Without this, you either: 1) End up with multiple controls that affect the same register bits, but whose DAPM state falls out of sync with HW, since the DAPM state is only updated for the specific control that is modified, and not for other paths that are affected only by the other control. 2) False paths through DAPM, since you end up merging unconnected stereo paths together into a single widget which hosts the single control, and then branching back out again, thus conjoining the enable states of the two input paths. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- Mark, the goto here might be considered icky. It avoids heavy indent levels. Should I separate out the control creation part of dapm_new_mixer() into a separate function to avoid this? Also, this commit has the potential for user-space impact, since control names could change for existing drivers. However, in this case I suspect the affected controls wouldn't have worked very well anyway, since they'd be affected by one of the problems I mention in the commit description above anyway, so I doubt this will be a practical problem. FYI, this feature for muxes will be useful for the rt5640.c driver, which has a single register for the HPO MUX, which separately affects both a L and R path to the HP outputs. sound/soc/soc-dapm.c | 57 +++++++++++++++++++++++++++++++------------------- 1 file changed, 36 insertions(+), 21 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 33acd8b..9a87aa5 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -508,13 +508,15 @@ static int dapm_is_shared_kcontrol(struct snd_soc_dapm_context *dapm, static int dapm_new_mixer(struct snd_soc_dapm_widget *w) { struct snd_soc_dapm_context *dapm = w->dapm; - int i, ret = 0; + int i, ret; size_t name_len, prefix_len; struct snd_soc_dapm_path *path; struct snd_card *card = dapm->card->snd_card; const char *prefix; struct snd_soc_dapm_widget_list *wlist; + int shared, wlistentries; size_t wlistsize; + struct snd_kcontrol *kcontrol; if (dapm->codec) prefix = dapm->codec->name_prefix; @@ -531,7 +533,6 @@ static int dapm_new_mixer(struct snd_soc_dapm_widget *w) /* match name */ list_for_each_entry(path, &w->sources, list_sink) { - /* mixer/mux paths name must match control name */ if (path->name != (char *)w->kcontrol_news[i].name) continue; @@ -541,26 +542,41 @@ static int dapm_new_mixer(struct snd_soc_dapm_widget *w) continue; } + shared = dapm_is_shared_kcontrol(dapm, w, + &w->kcontrol_news[i], &kcontrol); + + if (kcontrol) { + wlist = kcontrol->private_data; + wlistentries = wlist->num_widgets + 1; + } else { + wlist = NULL; + wlistentries = 1; + } + wlistsize = sizeof(struct snd_soc_dapm_widget_list) + - sizeof(struct snd_soc_dapm_widget *), - wlist = kzalloc(wlistsize, GFP_KERNEL); + wlistentries * + sizeof(struct snd_soc_dapm_widget *), + wlist = krealloc(wlist, wlistsize, GFP_KERNEL); if (wlist == NULL) { dev_err(dapm->dev, "ASoC: can't allocate widget list for %s\n", w->name); return -ENOMEM; } - wlist->num_widgets = 1; - wlist->widgets[0] = w; + wlist->num_widgets = wlistentries; + wlist->widgets[wlistentries - 1] = w; + + if (kcontrol) + goto skip_new_control; /* add dapm control with long name. * for dapm_mixer this is the concatenation of the * mixer and kcontrol name. - * for dapm_mixer_named_ctl this is simply the - * kcontrol name. + * for dapm_mixer_named_ctl or shared controls, this + * is simply the kcontrol name. */ name_len = strlen(w->kcontrol_news[i].name) + 1; - if (w->id != snd_soc_dapm_mixer_named_ctl) + if (!shared && w->id != snd_soc_dapm_mixer_named_ctl) name_len += 1 + strlen(w->name); path->long_name = kmalloc(name_len, GFP_KERNEL); @@ -570,8 +586,7 @@ static int dapm_new_mixer(struct snd_soc_dapm_widget *w) return -ENOMEM; } - switch (w->id) { - default: + if (!shared && w->id != snd_soc_dapm_mixer_named_ctl) /* The control will get a prefix from * the control creation process but * we're also using the same prefix @@ -581,19 +596,15 @@ static int dapm_new_mixer(struct snd_soc_dapm_widget *w) snprintf((char *)path->long_name, name_len, "%s %s", w->name + prefix_len, w->kcontrol_news[i].name); - break; - case snd_soc_dapm_mixer_named_ctl: + else snprintf((char *)path->long_name, name_len, "%s", w->kcontrol_news[i].name); - break; - } ((char *)path->long_name)[name_len - 1] = '\0'; - path->kcontrol = snd_soc_cnew(&w->kcontrol_news[i], - wlist, path->long_name, - prefix); - ret = snd_ctl_add(card, path->kcontrol); + kcontrol = snd_soc_cnew(&w->kcontrol_news[i], wlist, + path->long_name, prefix); + ret = snd_ctl_add(card, kcontrol); if (ret < 0) { dev_err(dapm->dev, "ASoC: failed to add widget" " %s dapm kcontrol %s: %d\n", @@ -603,10 +614,14 @@ static int dapm_new_mixer(struct snd_soc_dapm_widget *w) path->long_name = NULL; return ret; } - w->kcontrols[i] = path->kcontrol; + +skip_new_control: + path->kcontrol = kcontrol; + kcontrol->private_data = wlist; + w->kcontrols[i] = kcontrol; } } - return ret; + return 0; } /* create new dapm mux control */ -- 1.7.10.4

2 1

[alsa-devel] [PATCH 1/2] ASoC: wm0010: Constify usage of firmware filenames
by Charles Keepax 29 Mar '13

29 Mar '13

Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm0010.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/wm0010.c b/sound/soc/codecs/wm0010.c index 40256b5..a5cd51f 100644 --- a/sound/soc/codecs/wm0010.c +++ b/sound/soc/codecs/wm0010.c @@ -342,7 +342,7 @@ static void byte_swap_64(u64 *data_in, u64 *data_out, u32 len) data_out[i] = cpu_to_be64(le64_to_cpu(data_in[i])); } -static int wm0010_firmware_load(char *name, struct snd_soc_codec *codec) +static int wm0010_firmware_load(const char *name, struct snd_soc_codec *codec) { struct spi_device *spi = to_spi_device(codec->dev); struct wm0010_priv *wm0010 = snd_soc_codec_get_drvdata(codec); -- 1.7.2.5

2 2

Re: [alsa-devel] [PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list
by Jussi Laako 28 Mar '13

28 Mar '13

Hi Andreas,> Now of course, with your heroic effort in creating a generic driver that > would help everyone, we have a mess. Some DACs expect little endian > (mine and others as well) and others (all that are based on Rigisystems > modules) big endian positions. OK, we actually have two separate endianess issues here, but only one with word lengths longer than 8-bit. We have the traditional byte order endianess and the bit order endianess. Of course from computer point of view order of bits in a byte is sort of separate issue. And now the two file formats used for DSD use opposite bit ordering, but being byte-based don't have the byte ordering issue. At worst we have four different sample format possibilities for word lengths longer than a byte... Either way, application will have to be able to reshuffle the bits for the other format. - Jussi

2 2

Re: [alsa-devel] [PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list
by Daniel Mack 28 Mar '13

28 Mar '13

On 28.03.2013 05:58, Andreas Koch wrote: > >> >> Andreas, >> >> Am I right to assume that in your case it's the same as for DoP, >> IOW, oldest in MSB? > > Good point - thanks for bringing it up - another can of worms. > With Windows having a little endian philosophy we started early on > with the first DSD workstation by putting the oldest sample in the > LSB position. ASIO came along and adopted the same thing, but then > extended support for the opposite as well. Rigisystems (offering OEM > modules for USB audio) came along about a year ago and insisted that > there is only their way, i.e. putting the oldest bit in the MSB > position. I tried to explain to them that there are already hundreds > of products out in the market that do it differently, but that didn't > matter to them. The result is that now we have implementations with > both. Up until now that was not a huge issue, because there is no > generic Windows driver and every hardware manufacturer had to have a > custom driver. > Now of course, with your heroic effort in creating a generic driver > that would help everyone, we have a mess. Some DACs expect little > endian (mine and others as well) and others (all that are based on > Rigisystems modules) big endian positions. > > Since the time I had the discussions with Rigisystems I didn't have > any further communication with them. Maybe it is a good idea to touch > base with them again and find out what the latest is. I will try my > contact there and let you know. Eek, what an utter mess. Just let me know what you find out. We then need to augment the number of DSD formats, but then again, we can also move the sample rate calculation table inside the ALSA kernel core instead. Takashi et al - please don't apply any of these patches yet (expecpt for the the indentation fixup) :) I guess we need some more spins on this. Thanks, Daniel

1 0

[alsa-devel] [PATCH] ALSA: hda - bug fix on return value when getting HDMI ELD info
by mengdong.lin＠intel.com 28 Mar '13

28 Mar '13

From: Mengdong Lin <mengdong.lin(a)intel.com> In function snd_hdmi_get_eld(), the variable 'ret' should be initialized to 0. Otherwise it will be returned uninitialized as non-zero after ELD info is got successfully. Thus hdmi_present_sense() will always assume ELD info is invalid by mistake, and /proc file system cannot show the proper ELD info. This patch also let debug message show 'pin_eld->monitor_present' which is the real pin response to verb GET_PIN_SENSE. Signed-off-by: Mengdong Lin <mengdong.lin(a)intel.com> diff --git a/sound/pci/hda/hda_eld.c b/sound/pci/hda/hda_eld.c index 7dd8463..d0d7ac1 100644 --- a/sound/pci/hda/hda_eld.c +++ b/sound/pci/hda/hda_eld.c @@ -320,7 +320,7 @@ int snd_hdmi_get_eld(struct hda_codec *codec, hda_nid_t nid, unsigned char *buf, int *eld_size) { int i; - int ret; + int ret = 0; int size; /* diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 78e1827..de8ac5c 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1196,7 +1196,7 @@ static void hdmi_present_sense(struct hdmi_spec_per_pin *per_pin, int repoll) _snd_printd(SND_PR_VERBOSE, "HDMI status: Codec=%d Pin=%d Presence_Detect=%d ELD_Valid=%d\n", - codec->addr, pin_nid, eld->monitor_present, eld->eld_valid); + codec->addr, pin_nid, pin_eld->monitor_present, eld->eld_valid); if (eld->eld_valid) { if (snd_hdmi_get_eld(codec, pin_nid, eld->eld_buffer, -- 1.7.10.4

3 3

Re: [alsa-devel] [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work
by Jussi Laako 28 Mar '13

28 Mar '13

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

2 2

Re: [alsa-devel] [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work
by Daniel Mack 28 Mar '13

28 Mar '13

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

2 1