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

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

1 0

[alsa-devel] [PATCH 1/2] alsa-lib: pcm.c: fix indentation
by Daniel Mack 28 Mar '13

28 Mar '13

Signed-off-by: Daniel Mack <zonque(a)gmail.com> --- src/pcm/pcm.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c index 05737d9..2963711 100644 --- a/src/pcm/pcm.c +++ b/src/pcm/pcm.c @@ -1634,11 +1634,11 @@ static const char *const snd_pcm_type_names[] = { PCMTYPE(LADSPA), PCMTYPE(DMIX), PCMTYPE(JACK), - PCMTYPE(DSNOOP), - PCMTYPE(IEC958), + PCMTYPE(DSNOOP), + PCMTYPE(IEC958), PCMTYPE(SOFTVOL), - PCMTYPE(IOPLUG), - PCMTYPE(EXTPLUG), + PCMTYPE(IOPLUG), + PCMTYPE(EXTPLUG), PCMTYPE(MMAP_EMUL), }; -- 1.8.1.4

2 2

[alsa-devel] [PATCH 1/2] ALSA: add DSD formats
by Daniel Mack 28 Mar '13

28 Mar '13

This patch adds two formats for Direct Stream Digital (DSD), a pulse-density encoding format which is described here: https://en.wikipedia.org/wiki/Direct_Stream_Digital DSD operates on 2.8, 5.6 or 11.2MHz sample rates and as a 1-bit stream. In order to provide a compatibility way for pushing samples of DSD type through ordinary PCM channels, the "DoP open Standard" was created. See http://www.dsd-guide.com for a copy of the documentation. The two new types describe streams that are capable of handling DSD samples in 8-bit or in 16-bit (or at a single or double data rate, respectively). For applications, the following mapping table is used to configure the DSD mode by selecting a combination of PCM sample rates and word lengths: 352.8kHz 705.6KHz 1411.2KHz 8-bit 2.8MHz 5.6MHz 11.2MHz 16-bit 5.6MHz 11.2MHz Signed-off-by: Daniel Mack <zonque(a)gmail.com> --- include/sound/pcm.h | 2 ++ include/uapi/sound/asound.h | 4 +++- sound/core/pcm.c | 2 ++ 3 files changed, 7 insertions(+), 1 deletion(-) diff --git a/include/sound/pcm.h b/include/sound/pcm.h index aa7b0a8..2dffd55 100644 --- a/include/sound/pcm.h +++ b/include/sound/pcm.h @@ -181,6 +181,8 @@ struct snd_pcm_ops { #define SNDRV_PCM_FMTBIT_G723_24_1B _SNDRV_PCM_FMTBIT(G723_24_1B) #define SNDRV_PCM_FMTBIT_G723_40 _SNDRV_PCM_FMTBIT(G723_40) #define SNDRV_PCM_FMTBIT_G723_40_1B _SNDRV_PCM_FMTBIT(G723_40_1B) +#define SNDRV_PCM_FMTBIT_DSD_U8 _SNDRV_PCM_FMTBIT(DSD_U8) +#define SNDRV_PCM_FMTBIT_DSD_U16 _SNDRV_PCM_FMTBIT(DSD_U16) #ifdef SNDRV_LITTLE_ENDIAN #define SNDRV_PCM_FMTBIT_S16 SNDRV_PCM_FMTBIT_S16_LE diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h index 1774a5c..f9b0d3f 100644 --- a/include/uapi/sound/asound.h +++ b/include/uapi/sound/asound.h @@ -214,7 +214,9 @@ typedef int __bitwise snd_pcm_format_t; #define SNDRV_PCM_FORMAT_G723_24_1B ((__force snd_pcm_format_t) 45) /* 1 sample in 1 byte */ #define SNDRV_PCM_FORMAT_G723_40 ((__force snd_pcm_format_t) 46) /* 8 Samples in 5 bytes */ #define SNDRV_PCM_FORMAT_G723_40_1B ((__force snd_pcm_format_t) 47) /* 1 sample in 1 byte */ -#define SNDRV_PCM_FORMAT_LAST SNDRV_PCM_FORMAT_G723_40_1B +#define SNDRV_PCM_FORMAT_DSD_U8 ((__force snd_pcm_format_t) 48) /* DSD in 1 byte */ +#define SNDRV_PCM_FORMAT_DSD_U16 ((__force snd_pcm_format_t) 49) /* DSD in 2 bytes */ +#define SNDRV_PCM_FORMAT_LAST SNDRV_PCM_FORMAT_DSD_16U #ifdef SNDRV_LITTLE_ENDIAN #define SNDRV_PCM_FORMAT_S16 SNDRV_PCM_FORMAT_S16_LE diff --git a/sound/core/pcm.c b/sound/core/pcm.c index 578327e..433efdb 100644 --- a/sound/core/pcm.c +++ b/sound/core/pcm.c @@ -209,6 +209,8 @@ static char *snd_pcm_format_names[] = { FORMAT(G723_24_1B), FORMAT(G723_40), FORMAT(G723_40_1B), + FORMAT(DSD_U8), + FORMAT(DSD_U16), }; const char *snd_pcm_format_name(snd_pcm_format_t format) -- 1.8.1.4

1 1

[alsa-devel] [PATCH 1/2 resend] ASoC: cs4271: switch to mute_stream
by Daniel Mack 28 Mar '13

28 Mar '13

Use the newly introduced mute_stream DAI operation, and don't mute the codec if it's called for the _CAPTURE stream. Signed-off-by: Daniel Mack <zonque(a)gmail.com> Acked-by: Alexander Sverdlin <subaparts(a)yandex.ru> --- sound/soc/codecs/cs4271.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/cs4271.c b/sound/soc/codecs/cs4271.c index ac0d3b4..03036b3 100644 --- a/sound/soc/codecs/cs4271.c +++ b/sound/soc/codecs/cs4271.c @@ -388,7 +388,7 @@ static int cs4271_hw_params(struct snd_pcm_substream *substream, return cs4271_set_deemph(codec); } -static int cs4271_digital_mute(struct snd_soc_dai *dai, int mute) +static int cs4271_mute_stream(struct snd_soc_dai *dai, int mute, int stream) { struct snd_soc_codec *codec = dai->codec; struct cs4271_private *cs4271 = snd_soc_codec_get_drvdata(codec); @@ -396,6 +396,9 @@ static int cs4271_digital_mute(struct snd_soc_dai *dai, int mute) int val_a = 0; int val_b = 0; + if (stream != SNDRV_PCM_STREAM_PLAYBACK) + return 0; + if (mute) { val_a = CS4271_VOLA_MUTE; val_b = CS4271_VOLB_MUTE; @@ -442,7 +445,7 @@ static const struct snd_soc_dai_ops cs4271_dai_ops = { .hw_params = cs4271_hw_params, .set_sysclk = cs4271_set_dai_sysclk, .set_fmt = cs4271_set_dai_fmt, - .digital_mute = cs4271_digital_mute, + .mute_stream = cs4271_mute_stream, }; static struct snd_soc_dai_driver cs4271_dai = { -- 1.8.1.4

2 8

[alsa-devel] [PATCH v7] ASoC: soc-compress: Cancel delayed power down if needed
by Charles Keepax 28 Mar '13

28 Mar '13

When a new stream is being opened it is necessary to cancel any delayed power down of the audio. Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- ARGH! White space error. Charles sound/soc/soc-compress.c | 15 ++++++++++++--- 1 files changed, 12 insertions(+), 3 deletions(-) diff --git a/sound/soc/soc-compress.c b/sound/soc/soc-compress.c index f9b2197..0f4cfce 100644 --- a/sound/soc/soc-compress.c +++ b/sound/soc/soc-compress.c @@ -198,6 +198,7 @@ static int soc_compr_set_params(struct snd_compr_stream *cstream, { struct snd_soc_pcm_runtime *rtd = cstream->private_data; struct snd_soc_platform *platform = rtd->platform; + struct snd_soc_dai *codec_dai = rtd->codec_dai; int ret = 0; mutex_lock_nested(&rtd->pcm_mutex, rtd->pcm_subclass); @@ -211,19 +212,27 @@ static int soc_compr_set_params(struct snd_compr_stream *cstream, if (platform->driver->compr_ops && platform->driver->compr_ops->set_params) { ret = platform->driver->compr_ops->set_params(cstream, params); if (ret < 0) - goto out; + goto err; } if (rtd->dai_link->compr_ops && rtd->dai_link->compr_ops->set_params) { ret = rtd->dai_link->compr_ops->set_params(cstream); if (ret < 0) - goto out; + goto err; } snd_soc_dapm_stream_event(rtd, SNDRV_PCM_STREAM_PLAYBACK, SND_SOC_DAPM_STREAM_START); -out: + /* cancel any delayed stream shutdown that is pending */ + rtd->pop_wait = 0; + mutex_unlock(&rtd->pcm_mutex); + + cancel_delayed_work_sync(&rtd->delayed_work); + + return ret; + +err: mutex_unlock(&rtd->pcm_mutex); return ret; } -- 1.7.2.5

2 1

[alsa-devel] [PATCH 1/3] ASoC: Constify the 'driver' field of snd_soc_platform
by Lars-Peter Clausen 28 Mar '13

28 Mar '13

The ASoC core does no not modify the driver of a platform. Making it const allows ASoC platform drivers to declare the snd_soc_platform_driver struct as const. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- include/sound/soc.h | 4 ++-- sound/soc/soc-core.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index 1ffe9d4..e666119 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -373,7 +373,7 @@ int snd_soc_suspend(struct device *dev); int snd_soc_resume(struct device *dev); int snd_soc_poweroff(struct device *dev); int snd_soc_register_platform(struct device *dev, - struct snd_soc_platform_driver *platform_drv); + const struct snd_soc_platform_driver *platform_drv); void snd_soc_unregister_platform(struct device *dev); int snd_soc_register_codec(struct device *dev, const struct snd_soc_codec_driver *codec_drv, @@ -829,7 +829,7 @@ struct snd_soc_platform { const char *name; int id; struct device *dev; - struct snd_soc_platform_driver *driver; + const struct snd_soc_platform_driver *driver; struct mutex mutex; unsigned int suspended:1; /* platform is suspended */ diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 561d589..7bf21a1 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -3905,7 +3905,7 @@ static void snd_soc_unregister_dais(struct device *dev, size_t count) * @platform: platform to register */ int snd_soc_register_platform(struct device *dev, - struct snd_soc_platform_driver *platform_drv) + const struct snd_soc_platform_driver *platform_drv) { struct snd_soc_platform *platform; -- 1.8.0

2 3

Re: [alsa-devel] [PATCH] ASoC: add RT5640 CODEC driver
by Mark Brown 28 Mar '13

28 Mar '13

On Tue, Mar 26, 2013 at 05:35:38PM -0600, Stephen Warren wrote: > Mark, a couple questions: > * Is the custom index_reg device attr file OK, or should I remove that? > * Do new CODEC drivers have to use regmap directly, or is using the ASoC > IO system still OK? Convert to regmap please - it looks like this ought to be using the paging support from a quick glance at what the register I/O stuff is doing. The device file appears to duplicate the register dump stuff and isn't suitable for sysfs anyway as it's not one value per file, it ought to be in debugfs. > +/* IN1/IN2 Input Type */ > +static const char * const rt5640_input_mode[] = { > + "Single ended", "Differential"}; This looks like platform data. > +static const char * const rt5640_data_select[] = { > + "Normal", "left copy to right", "right copy to left", "Swap"}; DAPM? > +/* DMIC */ > +static const char * const rt5640_dmic_mode[] = {"Disable", "DMIC1", "DMIC2"}; > + > +static const SOC_ENUM_SINGLE_DECL(rt5640_dmic_enum, 0, 0, rt5640_dmic_mode); DAPM? > +static int rt5640_vol_rescale_get(struct snd_kcontrol *kcontrol, > + struct snd_ctl_elem_value *ucontrol) > +{ > + struct soc_mixer_control *mc = > + (struct soc_mixer_control *)kcontrol->private_value; > + struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol); > + unsigned int val = snd_soc_read(codec, mc->reg); > + > + ucontrol->value.integer.value[0] = VOL_RESCALE_MAX_VOL - > + ((val & RT5640_L_VOL_MASK) >> mc->shift); > + ucontrol->value.integer.value[1] = VOL_RESCALE_MAX_VOL - > + (val & RT5640_R_VOL_MASK); This looks like a range control. > +static int hp_event(struct snd_soc_dapm_widget *w, > + struct snd_kcontrol *kcontrol, int event) > +{ > + switch (event) { > + case SND_SOC_DAPM_POST_PMU: > + break; > + > + case SND_SOC_DAPM_PRE_PMD: > + break; > + > + default: > + return 0; > + } > + return 0; > +} This does nothing, it should be removed. > +static int rt5640_set_dmic1_event(struct snd_soc_dapm_widget *w, > + struct snd_kcontrol *kcontrol, int event) > +{ > + struct snd_soc_codec *codec = w->codec; > + > + switch (event) { > + case SND_SOC_DAPM_PRE_PMU: > + snd_soc_update_bits(codec, RT5640_GPIO_CTRL1, > + RT5640_GP2_PIN_MASK | RT5640_GP3_PIN_MASK, > + RT5640_GP2_PIN_DMIC1_SCL | RT5640_GP3_PIN_DMIC1_SDA); > + snd_soc_update_bits(codec, RT5640_DMIC, > + RT5640_DMIC_1L_LH_MASK | RT5640_DMIC_1R_LH_MASK | > + RT5640_DMIC_1_DP_MASK, > + RT5640_DMIC_1L_LH_FALLING | RT5640_DMIC_1R_LH_RISING | > + RT5640_DMIC_1_DP_IN1P); > + snd_soc_update_bits(codec, RT5640_DMIC, > + RT5640_DMIC_1_EN_MASK, RT5640_DMIC_1_EN); > + default: > + return 0; The last write there looks awfully like an enable but there's not any corresponding disable... > +static int rt5640_set_dmic2_event(struct snd_soc_dapm_widget *w, > + struct snd_kcontrol *kcontrol, int event) > +{ > + struct snd_soc_codec *codec = w->codec; > + > + switch (event) { > + case SND_SOC_DAPM_PRE_PMU: > + snd_soc_update_bits(codec, RT5640_GPIO_CTRL1, > + RT5640_GP2_PIN_MASK | RT5640_GP4_PIN_MASK, > + RT5640_GP2_PIN_DMIC1_SCL | RT5640_GP4_PIN_DMIC2_SDA); There's a degree of overlap between these two functions... > +static const struct snd_soc_dapm_route rt5640_dapm_routes[] = { > + {"IN1P", NULL, "LDO2"}, > + {"IN2P", NULL, "LDO2"}, > + > + {"IN1P", NULL, "MIC1"}, > + {"IN1N", NULL, "MIC1"}, > + {"IN2P", NULL, "MIC2"}, > + {"IN2N", NULL, "MIC2"}, Are MIC1 and MIC2 pins on the device? It's a bit odd to have a single physical input feeding both sides of a differential path internally. > + {"DMIC L1", NULL, "DMIC CLK"}, > + {"DMIC L2", NULL, "DMIC CLK"}, Shouldn't the DMIC CLK widget be handling the clock enables/muxes from the DMIC event above? > +static int get_sdp_info(struct snd_soc_codec *codec, int dai_id) > +{ > + int ret = 0, val = snd_soc_read(codec, RT5640_I2S1_SDP); > + > + if (codec == NULL) > + return -EINVAL; No point in the NULL check immediately after a dereference. > + val = (val & RT5640_I2S_IF_MASK) >> RT5640_I2S_IF_SFT; > + switch (dai_id) { > + case RT5640_AIF1: > + if (val == RT5640_IF_123 || val == RT5640_IF_132 || > + val == RT5640_IF_113) > + ret |= RT5640_U_IF1; > + if (val == RT5640_IF_312 || val == RT5640_IF_213 || > + val == RT5640_IF_113) > + ret |= RT5640_U_IF2; > + if (val == RT5640_IF_321 || val == RT5640_IF_231) > + ret |= RT5640_U_IF3; The tree of if ( || || ) looks like a switch statement and should probably be written as such. > + frame_size = snd_soc_params_to_frame_size(params); > + if (frame_size < 0) { > + dev_err(codec->dev, "Unsupported frame size: %d\n", frame_size); > + return -EINVAL; > + } The error message here is confusing as a negative code is an errno not a frame size and it probably ought to be passed to the caller. > + bclk_ms = frame_size > 32 ? 1 : 0; Grumble. > +static int rt5640_prepare(struct snd_pcm_substream *substream, > + struct snd_soc_dai *dai) > +{ > + struct snd_soc_pcm_runtime *rtd = substream->private_data; > + struct snd_soc_codec *codec = rtd->codec; > + struct rt5640_priv *rt5640 = snd_soc_codec_get_drvdata(codec); > + > + rt5640->aif_pu = dai->id; > + return 0; > +} This looks like only one DAI can be active at once, shouldn't there be some sort of checking for busy here? > + dai_sel = get_sdp_info(codec, dai->id); > + if (dai_sel < 0) { > + dev_err(codec->dev, "Failed to get sdp info: %d\n", dai_sel); > + return -EINVAL; > + } I suspect using dai->base (or just picking a suitable value for dai->id even) would be simpler. > + if (dai_sel & RT5640_U_IF1) { > + snd_soc_update_bits(codec, RT5640_I2S1_SDP, > + RT5640_I2S_MS_MASK | RT5640_I2S_BP_MASK | > + RT5640_I2S_DF_MASK, reg_val); > + } > + if (dai_sel & RT5640_U_IF2) { > + snd_soc_update_bits(codec, RT5640_I2S2_SDP, > + RT5640_I2S_MS_MASK | RT5640_I2S_BP_MASK | > + RT5640_I2S_DF_MASK, reg_val); > + } This looks like switch statements again, though (not having checked) I'd expect that there's just blocks of registers for each DAI and we could just work in terms of a base? > +/** > + * rt5640_pll_calc - Calcualte PLL M/N/K code. Typo. > + snd_soc_add_codec_controls(codec, rt5640_snd_controls, > + ARRAY_SIZE(rt5640_snd_controls)); Set in the driver structure. > +static int rt5640_resume(struct snd_soc_codec *codec) > +{ > + int ret = 0 ; > + > + codec->cache_sync = 1; > + ret = snd_soc_cache_sync(codec); > + if (ret) { > + dev_err(codec->dev, "Failed to sync cache: %d\n", ret); > + return ret; > + } > + rt5640_set_bias_level(codec, SND_SOC_BIAS_STANDBY); We also sync the cache in the bias management code. > +static int rt5640_i2c_probe(struct i2c_client *i2c, > + const struct i2c_device_id *id) > +{ > + struct rt5640_priv *rt5640; > + int ret; > + > + rt5640 = kzalloc(sizeof(struct rt5640_priv), GFP_KERNEL); > + if (NULL == rt5640) > + return -ENOMEM; devm_kzalloc() > +struct rt5640_pll_code { > + bool m_bp; /* Indicates bypass m code or not. */ > + int m_code; > + int n_code; > + int k_code; > +}; > + > +struct rt5640_priv { > + struct snd_soc_codec *codec; Move these into the body of the driver.

2 2

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

27 Mar '13

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

1 0

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

27 Mar '13

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

1 0

Re: [alsa-devel] [PATCH 2/2] ARM: clk: imx35 sound admux_gate bugfix
by Mark Brown 27 Mar '13

27 Mar '13

On Wed, Mar 27, 2013 at 12:57:00PM +0100, Philipp Zabel wrote: > Am Mittwoch, den 27.03.2013, 12:22 +0100 schrieb Markus Pargmann: > > imx-ssi needs admux_gate clock to work on imx35. This patch registers > > this clock and enables it in the imx-ssi driver. > I have no idea what the admux_gate really is, but the ssi driver doesn't > seem like the right place. Isn't this more closely related to the > imx-audmux.c driver? This is a patch to the ASoC driver? I just ignored it since it said it was an ARM patch... Anyway, what I'd expect should be happening here is that the clock API walks up the tree enabling supply clocks - that would mean that either that code isn't there or there's a missing parent child relationship in the data.

2 3