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

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

27 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> --- Well hopefully sixth time lucky, generated against the asoc tree for-next branch. Charles sound/soc/soc-compress.c | 16 +++++++++++++--- 1 files changed, 13 insertions(+), 3 deletions(-) diff --git a/sound/soc/soc-compress.c b/sound/soc/soc-compress.c index f9b2197..4b4b5fa 100644 --- a/sound/soc/soc-compress.c +++ b/sound/soc/soc-compress.c @@ -198,8 +198,10 @@ 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); /* first we call set_params for the platform driver @@ -211,19 +213,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

1 0

[alsa-devel] [PATCH] ASoC: wm5102: Implement OSR support
by Mark Brown 27 Mar '13

27 Mar '13

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm5102.c | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/sound/soc/codecs/wm5102.c b/sound/soc/codecs/wm5102.c index b7a3fdc..99972a5 100644 --- a/sound/soc/codecs/wm5102.c +++ b/sound/soc/codecs/wm5102.c @@ -612,6 +612,26 @@ static int wm5102_sysclk_ev(struct snd_soc_dapm_widget *w, return 0; } +static const char *wm5102_osr_text[] = { + "Low power", "Normal", "High performance", +}; + +static const unsigned int wm5102_osr_val[] = { + 0x0, 0x3, 0x5, +}; + +static const struct soc_enum wm5102_hpout_osr[] = { + SOC_VALUE_ENUM_SINGLE(ARIZONA_OUTPUT_PATH_CONFIG_1L, + ARIZONA_OUT1_OSR_SHIFT, 0xe00, 3, + wm5102_osr_text, wm5102_osr_val), + SOC_VALUE_ENUM_SINGLE(ARIZONA_OUTPUT_PATH_CONFIG_2L, + ARIZONA_OUT2_OSR_SHIFT, 0xe00, 3, + wm5102_osr_text, wm5102_osr_val), + SOC_VALUE_ENUM_SINGLE(ARIZONA_OUTPUT_PATH_CONFIG_3L, + ARIZONA_OUT3_OSR_SHIFT, 0xe00, 3, + wm5102_osr_text, wm5102_osr_val), +}; + #define WM5102_NG_SRC(name, base) \ SOC_SINGLE(name " NG HPOUT1L Switch", base, 0, 1, 0), \ SOC_SINGLE(name " NG HPOUT1R Switch", base, 1, 1, 0), \ @@ -761,6 +781,8 @@ ARIZONA_MIXER_CONTROLS("SPKOUTR", ARIZONA_OUT4RMIX_INPUT_1_SOURCE), ARIZONA_MIXER_CONTROLS("SPKDAT1L", ARIZONA_OUT5LMIX_INPUT_1_SOURCE), ARIZONA_MIXER_CONTROLS("SPKDAT1R", ARIZONA_OUT5RMIX_INPUT_1_SOURCE), +SOC_SINGLE("Speaker High Performance Switch", ARIZONA_OUTPUT_PATH_CONFIG_4L, + ARIZONA_OUT4_OSR_SHIFT, 1, 0), SOC_SINGLE("SPKDAT1 High Performance Switch", ARIZONA_OUTPUT_PATH_CONFIG_5L, ARIZONA_OUT5_OSR_SHIFT, 1, 0), @@ -790,6 +812,10 @@ SOC_DOUBLE_R_TLV("SPKDAT1 Digital Volume", ARIZONA_DAC_DIGITAL_VOLUME_5L, ARIZONA_DAC_DIGITAL_VOLUME_5R, ARIZONA_OUT5L_VOL_SHIFT, 0xbf, 0, digital_tlv), +SOC_VAL_ENUM("HPOUT1 OSR", wm5102_hpout_osr[0]), +SOC_VAL_ENUM("HPOUT2 OSR", wm5102_hpout_osr[1]), +SOC_VAL_ENUM("HPOUT3 OSR", wm5102_hpout_osr[2]), + SOC_ENUM("Output Ramp Up", arizona_out_vi_ramp), SOC_ENUM("Output Ramp Down", arizona_out_vd_ramp), -- 1.7.10.4

2 2

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

27 Mar '13

Hi Philipp, On Wed, Mar 27, 2013 at 12:57:00PM +0100, Philipp Zabel wrote: > Hi Markus, > > 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? Actually admux clock is not audmux clock, that one is seperated. So I am not sure where this belongs. As imx-ssi was not working without it, I added it here. But you are right, I also spoke with Sascha and I will simply move the clock enable to imx35-dt.c. > > > A reboot without this patch results in a failing AC97 for example on > > pcm043. > > > > Signed-off-by: Markus Pargmann <mpa(a)pengutronix.de> > > Cc: stable(a)vger.kernel.org > > --- > > arch/arm/mach-imx/clk-imx25.c | 6 ++++-- > > arch/arm/mach-imx/clk-imx27.c | 6 ++++-- > > arch/arm/mach-imx/clk-imx31.c | 6 ++++-- > > arch/arm/mach-imx/clk-imx35.c | 6 ++++-- > > arch/arm/mach-imx/clk-imx51-imx53.c | 9 ++++++--- > > sound/soc/fsl/imx-ssi.c | 16 +++++++++++++++- > > sound/soc/fsl/imx-ssi.h | 2 ++ > > 7 files changed, 39 insertions(+), 12 deletions(-) > > > > diff --git a/arch/arm/mach-imx/clk-imx25.c b/arch/arm/mach-imx/clk-imx25.c > > index 69858c7..174ff8b 100644 > > --- a/arch/arm/mach-imx/clk-imx25.c > > +++ b/arch/arm/mach-imx/clk-imx25.c > > @@ -285,8 +285,10 @@ int __init mx25_clocks_init(void) > > clk_register_clkdev(clk[lcdc_ipg], "ipg", "imx21-fb.0"); > > clk_register_clkdev(clk[lcdc_ahb], "ahb", "imx21-fb.0"); > > clk_register_clkdev(clk[wdt_ipg], NULL, "imx2-wdt.0"); > > - clk_register_clkdev(clk[ssi1_ipg], NULL, "imx-ssi.0"); > > - clk_register_clkdev(clk[ssi2_ipg], NULL, "imx-ssi.1"); > > + clk_register_clkdev(clk[ssi1_ipg], "ipg", "imx-ssi.0"); > > + clk_register_clkdev(clk[ssi2_ipg], "ipg", "imx-ssi.1"); > > + clk_register_clkdev(clk[dummy], "admux", "imx-ssi.0"); > > + clk_register_clkdev(clk[dummy], "admux", "imx-ssi.1"); > > clk_register_clkdev(clk[esdhc1_ipg_per], "per", "sdhci-esdhc-imx25.0"); > > clk_register_clkdev(clk[esdhc1_ipg], "ipg", "sdhci-esdhc-imx25.0"); > > clk_register_clkdev(clk[esdhc1_ahb], "ahb", "sdhci-esdhc-imx25.0"); > > diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c > > index 30b3242..439d5bd 100644 > > --- a/arch/arm/mach-imx/clk-imx27.c > > +++ b/arch/arm/mach-imx/clk-imx27.c > > @@ -252,8 +252,10 @@ int __init mx27_clocks_init(unsigned long fref) > > clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.2"); > > clk_register_clkdev(clk[usb_ipg_gate], "ipg", "mxc-ehci.2"); > > clk_register_clkdev(clk[usb_ahb_gate], "ahb", "mxc-ehci.2"); > > - clk_register_clkdev(clk[ssi1_ipg_gate], NULL, "imx-ssi.0"); > > - clk_register_clkdev(clk[ssi2_ipg_gate], NULL, "imx-ssi.1"); > > + clk_register_clkdev(clk[ssi1_ipg_gate], "ipg", "imx-ssi.0"); > > + clk_register_clkdev(clk[ssi2_ipg_gate], "ipg", "imx-ssi.1"); > > + clk_register_clkdev(clk[dummy], "admux", "imx-ssi.0"); > > + clk_register_clkdev(clk[dummy], "admux", "imx-ssi.1"); > > clk_register_clkdev(clk[nfc_baud_gate], NULL, "imx27-nand.0"); > > clk_register_clkdev(clk[vpu_baud_gate], "per", "coda-imx27.0"); > > clk_register_clkdev(clk[vpu_ahb_gate], "ahb", "coda-imx27.0"); > > diff --git a/arch/arm/mach-imx/clk-imx31.c b/arch/arm/mach-imx/clk-imx31.c > > index b5b65f3..478b33e 100644 > > --- a/arch/arm/mach-imx/clk-imx31.c > > +++ b/arch/arm/mach-imx/clk-imx31.c > > @@ -171,8 +171,10 @@ int __init mx31_clocks_init(unsigned long fref) > > clk_register_clkdev(clk[owire_gate], NULL, "mxc_w1.0"); > > clk_register_clkdev(clk[sdhc1_gate], NULL, "imx31-mmc.0"); > > clk_register_clkdev(clk[sdhc2_gate], NULL, "imx31-mmc.1"); > > - clk_register_clkdev(clk[ssi1_gate], NULL, "imx-ssi.0"); > > - clk_register_clkdev(clk[ssi2_gate], NULL, "imx-ssi.1"); > > + clk_register_clkdev(clk[ssi1_gate], "ipg", "imx-ssi.0"); > > + clk_register_clkdev(clk[ssi2_gate], "ipg", "imx-ssi.1"); > > + clk_register_clkdev(clk[dummy], "admux", "imx-ssi.0"); > > + clk_register_clkdev(clk[dummy], "admux", "imx-ssi.1"); > > clk_register_clkdev(clk[firi_gate], "firi", NULL); > > clk_register_clkdev(clk[ata_gate], NULL, "pata_imx"); > > clk_register_clkdev(clk[rtic_gate], "rtic", NULL); > > diff --git a/arch/arm/mach-imx/clk-imx35.c b/arch/arm/mach-imx/clk-imx35.c > > index b95898a..4ab18ac 100644 > > --- a/arch/arm/mach-imx/clk-imx35.c > > +++ b/arch/arm/mach-imx/clk-imx35.c > > @@ -233,8 +233,10 @@ int __init mx35_clocks_init(void) > > clk_register_clkdev(clk[kpp_gate], NULL, "imx-keypad"); > > clk_register_clkdev(clk[owire_gate], NULL, "mxc_w1"); > > clk_register_clkdev(clk[sdma_gate], NULL, "imx35-sdma"); > > - clk_register_clkdev(clk[ssi1_gate], NULL, "imx-ssi.0"); > > - clk_register_clkdev(clk[ssi2_gate], NULL, "imx-ssi.1"); > > + clk_register_clkdev(clk[ssi1_gate], "ipg", "imx-ssi.0"); > > + clk_register_clkdev(clk[ssi2_gate], "ipg", "imx-ssi.1"); > > + clk_register_clkdev(clk[admux_gate], "admux", "imx-ssi.0"); > > + clk_register_clkdev(clk[admux_gate], "admux", "imx-ssi.1"); > > /* i.mx35 has the i.mx21 type uart */ > > clk_register_clkdev(clk[uart1_gate], "per", "imx21-uart.0"); > > clk_register_clkdev(clk[ipg], "ipg", "imx21-uart.0"); > > diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c > > index 0f39f8c..b413a1e 100644 > > --- a/arch/arm/mach-imx/clk-imx51-imx53.c > > +++ b/arch/arm/mach-imx/clk-imx51-imx53.c > > @@ -275,9 +275,12 @@ static void __init mx5_clocks_common_init(unsigned long rate_ckil, > > clk_register_clkdev(clk[usboh3_gate], "ipg", "imx-udc-mx51"); > > clk_register_clkdev(clk[usboh3_gate], "ahb", "imx-udc-mx51"); > > clk_register_clkdev(clk[nfc_gate], NULL, "imx51-nand"); > > - clk_register_clkdev(clk[ssi1_ipg_gate], NULL, "imx-ssi.0"); > > - clk_register_clkdev(clk[ssi2_ipg_gate], NULL, "imx-ssi.1"); > > - clk_register_clkdev(clk[ssi3_ipg_gate], NULL, "imx-ssi.2"); > > + clk_register_clkdev(clk[ssi1_ipg_gate], "ipg", "imx-ssi.0"); > > + clk_register_clkdev(clk[ssi2_ipg_gate], "ipg", "imx-ssi.1"); > > + clk_register_clkdev(clk[ssi3_ipg_gate], "ipg", "imx-ssi.2"); > > + clk_register_clkdev(clk[dummy], "admux", "imx-ssi.0"); > > + clk_register_clkdev(clk[dummy], "admux", "imx-ssi.1"); > > + clk_register_clkdev(clk[dummy], "admux", "imx-ssi.2"); > > I think those should be removed completely. If really needed, it should > rather be added to the device tree for i.MX5: Oh yes, I grepped for imx-ssi.. However next patch version will not touch any of the other imxs code. > > --- a/arch/arm/boot/dts/imx53.dtsi > +++ b/arch/arm/boot/dts/imx53.dtsi > @@ -162,7 +162,8 @@ > compatible = "fsl,imx53-ssi", "fsl,imx21-ssi"; > reg = <0x50014000 0x4000>; > interrupts = <30>; > - clocks = <&clks 49>; > + clocks = <&clks 49>, <&clks 0>; > + clock-names = "ipg", "admux"; > fsl,fifo-depth = <15>; > fsl,ssi-dma-events = <25 24 23 22>; /* TX0 RX0 TX1 RX1 */ > status = "disabled"; > @@ -791,7 +792,8 @@ > compatible = "fsl,imx53-ssi", "fsl,imx21-ssi"; > reg = <0x63fcc000 0x4000>; > interrupts = <29>; > - clocks = <&clks 48>; > + clocks = <&clks 48>, <&clks 0>; > + clock-names = "ipg", "admux"; > fsl,fifo-depth = <15>; > fsl,ssi-dma-events = <29 28 27 26>; /* TX0 RX0 TX1 RX1 */ > status = "disabled"; > @@ -815,7 +817,8 @@ > compatible = "fsl,imx53-ssi", "fsl,imx21-ssi"; > reg = <0x63fe8000 0x4000>; > interrupts = <96>; > - clocks = <&clks 50>; > + clocks = <&clks 50>, <&clks 0>; > + clock-names = "ipg", "admux"; > fsl,fifo-depth = <15>; > fsl,ssi-dma-events = <47 46 45 44>; /* TX0 RX0 TX1 RX1 */ > status = "disabled"; > > But again, I'm not convinced the ssi driver is the right place to enable > the "admux" gate. > > > clk_register_clkdev(clk[ssi_ext1_gate], "ssi_ext1", NULL); > > clk_register_clkdev(clk[ssi_ext2_gate], "ssi_ext2", NULL); > > clk_register_clkdev(clk[sdma_gate], NULL, "imx35-sdma"); > > diff --git a/sound/soc/fsl/imx-ssi.c b/sound/soc/fsl/imx-ssi.c > > index 55464a5..9f96785 100644 > > --- a/sound/soc/fsl/imx-ssi.c > > +++ b/sound/soc/fsl/imx-ssi.c > > @@ -535,7 +535,7 @@ static int imx_ssi_probe(struct platform_device *pdev) > > > > ssi->irq = platform_get_irq(pdev, 0); > > > > - ssi->clk = devm_clk_get(&pdev->dev, NULL); > > + ssi->clk = devm_clk_get(&pdev->dev, "ipg"); > > if (IS_ERR(ssi->clk)) { > > ret = PTR_ERR(ssi->clk); > > dev_err(&pdev->dev, "Cannot get the clock: %d\n", > > @@ -544,6 +544,15 @@ static int imx_ssi_probe(struct platform_device *pdev) > > } > > clk_prepare_enable(ssi->clk); > > > > + ssi->admux_clk = devm_clk_get(&pdev->dev, "admux"); > > + if (IS_ERR(ssi->admux_clk)) { > > + if (PTR_ERR(ssi->admux_clk) == -ENOMEM) > > + goto failed_admux_clk_mem; > > + ssi->admux_clk = NULL; > > + } else { > > + clk_prepare_enable(ssi->admux_clk); > > + } > > + > > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > if (!res) { > > ret = -ENODEV; > > @@ -631,6 +640,9 @@ failed_pdev_fiq_alloc: > > failed_register: > > release_mem_region(res->start, resource_size(res)); > > failed_get_resource: > > + if (ssi->admux_clk) > > + clk_disable_unprepare(ssi->admux_clk); > > +failed_admux_clk_mem: > > clk_disable_unprepare(ssi->clk); > > failed_clk: > > > > @@ -652,6 +664,8 @@ static int imx_ssi_remove(struct platform_device *pdev) > > > > release_mem_region(res->start, resource_size(res)); > > clk_disable_unprepare(ssi->clk); > > + if (ssi->admux_clk) > > + clk_disable_unprepare(ssi->admux_clk); > > > > return 0; > > } > > diff --git a/sound/soc/fsl/imx-ssi.h b/sound/soc/fsl/imx-ssi.h > > index dc114bd..3dfbd92 100644 > > --- a/sound/soc/fsl/imx-ssi.h > > +++ b/sound/soc/fsl/imx-ssi.h > > @@ -194,6 +194,8 @@ struct imx_ssi { > > > > struct snd_soc_dai *imx_ac97; > > struct clk *clk; > > + /* imx35 has a admux clock that has to be active for sound to work */ > > + struct clk *admux_clk; > > void __iomem *base; > > int irq; > > int fiq_enable; > > regards > Philipp > > Thanks, Markus -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

1 0

[alsa-devel] need help for PCM constraint/rules
by Takashi Sakamoto 27 Mar '13

27 Mar '13

Dear developers, I'm a newbile for this project and working for kernel land driver for Fireworks with ALSA framework. I need your help for constraint/rule of PCM component. Related source is: https://github.com/takaswie/snd-firewire-improve/blob/master/fireworks/fire… My device (AudioFirePre8) changes its channels according to sampling rate. For example: 32.0 - 48.0kHz : 16ch: efw->channels_sets[0] 88.2 - 96.0kHz : 12ch: efw->channels_sets[1] 176.4 - 192.0kHz : 10ch: efw->channels_sets[2] (but not available) The other devices such as AudioFire12 has the same number of channels (12ch)in each sampling rate. I managed to write this rule refering to rme9652.c but I cannot achieve my purpose. It's my glad to get some help about this. Regards Takashi Sakamoto o-takashi(a)sakamocchi.jp ======== Fireworks is Echo Audio's series of Firewire Audio interface. http://echoaudio.com/products/audiofire-pre8 It utilizes IEC 61883-1 and -6 in its implementation and familiar with current snd-firewire-lib.ko. FFADO also produce driver for it. It's a user-land implementation. http://www.ffado.org/ My aim is writing kernel-land driver for it with ALSA framework. Takashi Sakamoto o-takashi(a)sakamocchi.jp

2 4

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

27 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> --- sound/soc/soc-compress.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/sound/soc/soc-compress.c b/sound/soc/soc-compress.c index f9fb112..eb8191b 100644 --- a/sound/soc/soc-compress.c +++ b/sound/soc/soc-compress.c @@ -194,6 +194,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); @@ -216,6 +217,12 @@ static int soc_compr_set_params(struct snd_compr_stream *cstream, goto out; } + /* cancel any delayed stream shutdown that is pending */ + if (codec_dai->pop_wait) { + codec_dai->pop_wait = 0; + cancel_delayed_work(&rtd->delayed_work); + } + snd_soc_dapm_stream_event(rtd, SNDRV_PCM_STREAM_PLAYBACK, SND_SOC_DAPM_STREAM_START); -- 1.7.2.5

2 8

[alsa-devel] [PATCH 0/2] ARM: imx35 clk bugfixes
by Markus Pargmann 27 Mar '13

27 Mar '13

Hi, Two bugfixes which enable needed clocks. In both cases the first boot worked because the clocks were enabled by default after powerup. After disabling the unused clocks in the boot process, some parts were not working anymore and device init for example after a reboot did not work. Regards, Markus

1 2

Re: [alsa-devel] Support for DSD streams
by Daniel Mack 27 Mar '13

27 Mar '13

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

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

1 0

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

27 Mar '13

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

1 0

[alsa-devel] [PATCH] ASoC: export snd_soc_register_component
by Stephen Warren 26 Mar '13

26 Mar '13

From: Stephen Warren <swarren(a)nvidia.com> Without this, modules will fail to link against those symbols. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- sound/soc/soc-core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 7ae68b0..561d589 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -4195,6 +4195,7 @@ error_component_name: return ret; } +EXPORT_SYMBOL_GPL(snd_soc_register_component); /** * snd_soc_unregister_component - Unregister a component from the ASoC core @@ -4220,6 +4221,7 @@ found: dev_dbg(dev, "ASoC: Unregistered component '%s'\n", cmpnt->name); kfree(cmpnt->name); } +EXPORT_SYMBOL_GPL(snd_soc_unregister_component); /* Retrieve a card's name from device tree */ int snd_soc_of_parse_card_name(struct snd_soc_card *card, -- 1.7.10.4

2 1