November 2015 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH RFC 0/6] ASoC: sgtl5000: fix use of regulators and internal LDO
by Eric Nelson 15 Jun '16

15 Jun '16

This patch set addresses a structural problem in the handling of regulators for VDDIO, VDDA, and VDDD in the SGTL5000 driver. The first two of these power rails must be powered on prior to any I2C communication, and yet the regulators were tied to the codec, which is instantiated only after a fair amount of I2C communication takes place. In other words, these regulators could never have function, and we can surmise that no user of this driver has switched power supply rails connected to them. The third power rail (VDDD) can be derived internally (by using I2C registers) though the data sheet says that if an external VDDD is used, it should be enabled before MCLK is started and I2C activity begins. Patch 1 moves the regulators to the I2C device and initializes them before I2C activity. Patch 2 addresses an issue found during development of the patch and is somewhat unrelated to regulators. It is included for discussion Patch 3 removes the root cause of patch 2 Patch 4 adds return value checks when setting the LINREG and ANA_POWER registers Patch 5 addresses the cause of follow-on failures and the source of the error in patch 3. Patch 6 removes the naive use of the supplies to lower power consumption and replaces it with something more modest. The patch set is being sent as an RFC for discussion, and should probably be squashed into two or three patches covering the regulator updates (patches 1, 3-5 and perhaps 6), initialization error handling (patch 2). Eric Nelson (6): ASoC: sgtl5000: fix regulator support ASoC: sgtl5000: write all default registers ASoC: sgtl5000: initialize CHIP_ANA_POWER to power-on defaults ASoC: sgtl5000: check return values ASoC: sgtl5000: disable internal PLL early ASoC: sgtl5000: Don't disable regulators in SND_SOC_BIAS_OFF sound/soc/codecs/sgtl5000.c | 417 +++++++++++--------------------------------- sound/soc/codecs/sgtl5000.h | 2 + 2 files changed, 102 insertions(+), 317 deletions(-) -- 1.9.1

3 28

[alsa-devel] [PATCH v2 0/6] ASoC: fsl_ssi: Fixing various channel slips and bad samples insertions
by Arnaud Mouiche 13 May '16

13 May '16

This series of patch is an attempt to fix the fsl_ssi driver to use it in TDM mode (DSP A or B) with a large number of channels/slots. Version 2: - fixing a missing patch - checkpatch.pl - ... well, learning how to send a patchset. Sorry. ;) Bugs are detected and fixed on a imx6sl platform with linux 4.3, where 2 SSI interfaces are used. SSI3 configured as a master of the bus, SSI2 as a slave. Various loopback scenario are tested: * scenario 1: SSI3 (master) with TXD to RXD loopback | |---> TXD --\ SSI3 |<--- RXD --/ (master) |---> SYNC |---> BCLK | * scenario 2: SSI3 connected to SSI2 | |---> TXD --------\ SSI3 |<--- RXD -----\ | (master) |---> SYNC --\ | | |---> BCLK | | | | | | | | | | | | | |<--- BCLK | | | SSI2 |<--- SYNC --/ | | (slave) |---> TXD ------/ | |<--- RXD --------/ | A test software (called atest) was developed and available. [1] It basically generate/check specials frames with S16_LE sequence samples NNN0, NNN1, NNN2 ... NNNC with NNN = frame number, and C the number of channels-1 Patch 1: Limitation fix. Prerequisite to use the fsl_ssi driver with up to 32 channels / slots Patch 2: Bug fix. Prerequisite to setup a relative high bitclk for our tests in 8ch / 16bits / 48kHz Patch 3: Simply save a 'dev' reference inside ssi_private for dev_err() purpose. (ssi_private is only available in lot of places, and ssi_private->pdev is deprecated and NULL indeed) Patch 4: Fix playback samples being dropped because the TX fifo was not ready at the time the DMA starts filling (only in case where playback is started AFTER the capture) Detected in loopback scenario 1, with following script (> 80 % of reproducibility) $ atest -D SSI3 -c 8 -r 48000 capture play dbg: set period size: 960 dbg: SSI3: capture_start dbg: SSI3: playback_start err: invalid frame after 1 null frames err: 0000 0000 0013 0014 0015 0016 0017 0020 dbg: SIGINT total number of sequence errors: 21119 here we see that samples 0000 0001 ... 0012 are not present in the output. In addition, this the number of samples dropped is not a multiple of the number of channel, we have a a channel slip. Patch 5: This is the Caleb Crome's case [2], where the SSI starts to generate samples while the TX FIFO is not filled by the DMA yet. Void samples can be inserted before DMA streaming. Detected in loopback scenario 2, with following script (reproducibility < 1%) $ atest -D SSI3 -c 8 -r 48000 capture & $ sleep 0.2 $ atest -d 1 -D SSI2 -c 8 -r 48000 play dbg: SSI3: capture_start dbg: set period size: 960 dbg: SSI2: playback_start dbg: start a 1 seconds duration timer err: invalid frame after 11568 null frames err: 0000 0010 0011 0012 0013 0014 0015 0016 err: 0017 0020 0021 0022 0023 0024 0025 0026 Patch 6: Deals with Capture restart whereas Playback is still running (or the opposite, Playback restart whereas Capture is till running). Capture restart whereas Playback case is detected in loopback scenario 1 (reproducibility 100%). A playback session is running in background, and 2 consecutive Captures are performed. The first is fine, the second fails. We see at the 2nd capture startup that we receive 15 samples still pending in the RX FIFO from the previous capture session. => We are receiving invalid samples + slips the channels $ atest -D SSI3 -c 8 -r 48000 play & dbg: SSI3: playback_start $ atest -d 1 -D SSI3 -c 8 -r 48000 capture dbg: SSI3: capture_start dbg: start a 1 seconds duration timer warn: Valid frame after 1 null frames warn: 3a90 3a91 3a92 3a93 3a94 3a95 3a96 3a97 total number of sequence errors: 0 $ atest -I 5 -d 1 -D SSI3 -c 8 -r 48000 capture # restart the capture dbg: SSI3: capture_start dbg: start a 1 seconds duration timer err: invalid frame after 1 null frames err: 8dd6 8dd7 8de0 8de1 8de2 8de3 8de4 8de5 err: 8de6 8de7 8df0 8df1 8df2 8df3 8df4 c0c0 err: c0c1 c0c2 c0c3 c0c4 c0c5 c0c6 c0c7 c0d0 err: c0d1 c0d2 c0d3 c0d4 c0d5 c0d6 c0d7 c0e0 err: c0e1 c0e2 c0e3 c0e4 c0e5 c0e6 c0e7 c0f0 Playback restart whereas Capture case is also detected with loopback scenario 1 (reproducibility 100%), capturing continuously, and playing by periods of time. $ atest -a -D SSI3 -c 8 -r 48000 capture play -r 1000,200 dbg: SSI3: capture_start dbg: SSI3: playback_start dbg: SSI3: will stop every 1000 ms during 200 ms warn: Valid frame after 4 null frames warn: 0010 0011 0012 0013 0014 0015 0016 0017 warn: SSI3: PT_W4_STOP warn: SSI3: PT_W4_RESTART err: invalid frame after 1602 null frames err: eaa1 eaa2 eaa3 eaa4 eaa5 eaa6 eaa7 eab0 err: eab1 eab2 eab3 eab4 5810 5811 5812 5813 dbg: stop on first error total number of sequence errors: 143 Both cases are resolved by using the mostly undocumented SOR.RX_CLR and SOR TX_CLR (we can find the documentation in IMX51 reference manual at section 56.3.3.15). Arnaud [1] https://github.com/amouiche/atest [2] http://mailman.alsa-project.org/pipermail/alsa-devel/2015-October/099221.ht… Arnaud Mouiche (6): ASoC: fsl_ssi: Real hardware channels max number is 32 ASoC: fsl_ssi: The IPG/5 limitation concerns the bitclk, not the sysclk. ASoC: fsl_ssi: Save a dev reference for dev_err() purpose. ASoC: fsl_ssi: Fix samples being dropped as Playback startup ASoC: fsl_ssi: Fix channel slipping in Playback at startup ASoC: fsl_ssi: Fix channel slipping on capture (or playback) restart in full duplex. sound/soc/fsl/fsl_ssi.c | 74 +++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 63 insertions(+), 11 deletions(-) -- 1.9.1

5 11

[alsa-devel] [PATCH 0/5] ASoC: fsl_ssi: Fixing various channel slips and bad samples insertions
by Arnaud Mouiche 13 May '16

13 May '16

This series of patch is an attempt to fix the fsl_ssi driver to use it in TDM mode (DSP A or B) with a large number of channels/slots. Bugs are detected and fixed on a imx6sl platform with linux 4.3, where 2 SSI interfaces are used. SSI3 configured as a master of the bus, SSI2 as a slave. Various loopback scenario are tested: * scenario 1: SSI3 (master) with TXD to RXD loopback | |---> TXD --\ SSI3 |<--- RXD --/ (master) |---> SYNC |---> BCLK | * scenario 2: SSI3 connected to SSI2 | |---> TXD --------\ SSI3 |<--- RXD -----\ | (master) |---> SYNC --\ | | |---> BCLK | | | | | | | | | | | | | |<--- BCLK | | | SSI2 |<--- SYNC --/ | | (slave) |---> TXD ------/ | |<--- RXD --------/ | A test software (called atest) was developed and available. [1] It basically generate/check specials frames with S16_LE sequence samples NNN0, NNN1, NNN2 ... NNNC with NNN = frame number, and C the number of channels-1 Patch 1: Limitation fix. Prerequisite to use the fsl_ssi driver with up to 32 channels / slots Patch 2: Bug fix. Prerequisite to setup a relative high bitclk for our tests in 8ch / 16bits / 48kHz Patch 3: Simply save a 'dev' reference inside ssi_private for dev_err() purpose. (ssi_private is only available in lot of places, and ssi_private->pdev is deprecated and NULL indeed) Patch 4: Fix playback samples being dropped because the TX fifo was not ready at the time the DMA starts filling (only in case where playback is started AFTER the capture) Detected in loopback scenario 1, with following script (> 80 % of reproducibility) $ atest -D SSI3 -c 8 -r 48000 capture play dbg: set period size: 960 dbg: SSI3: capture_start dbg: SSI3: playback_start err: invalid frame after 1 null frames err: 0000 0000 0013 0014 0015 0016 0017 0020 dbg: SIGINT total number of sequence errors: 21119 here we see that samples 0000 0001 ... 0012 are not present in the output. In addition, this the number of samples dropped is not a multiple of the number of channel, we have a a channel slip. Patch 5: This is the Caleb Crome's case [2], where the SSI starts to generate samples while the TX FIFO is not filled by the DMA yet. Void samples can be inserted before DMA streaming. Detected in loopback scenario 2, with following script (reproducibility < 1%) $ atest -D SSI3 -c 8 -r 48000 capture & $ sleep 0.2 $ atest -d 1 -D SSI2 -c 8 -r 48000 play dbg: SSI3: capture_start dbg: set period size: 960 dbg: SSI2: playback_start dbg: start a 1 seconds duration timer err: invalid frame after 11568 null frames err: 0000 0010 0011 0012 0013 0014 0015 0016 err: 0017 0020 0021 0022 0023 0024 0025 0026 Patch 6: Deals with Capture restart whereas Playback is still running (or the opposite, Playback restart whereas Capture is till running). Capture restart whereas Playback case is detected in loopback scenario 1 (reproducibility 100%). A playback session is running in background, and 2 consecutive Captures are performed. The first is fine, the second fails. We see at the 2nd capture startup that we receive 15 samples still pending in the RX FIFO from the previous capture session. => We are receiving invalid samples + slips the channels $ atest -D SSI3 -c 8 -r 48000 play & dbg: SSI3: playback_start $ atest -d 1 -D SSI3 -c 8 -r 48000 capture dbg: SSI3: capture_start dbg: start a 1 seconds duration timer warn: Valid frame after 1 null frames warn: 3a90 3a91 3a92 3a93 3a94 3a95 3a96 3a97 total number of sequence errors: 0 $ atest -I 5 -d 1 -D SSI3 -c 8 -r 48000 capture # restart the capture dbg: SSI3: capture_start dbg: start a 1 seconds duration timer err: invalid frame after 1 null frames err: 8dd6 8dd7 8de0 8de1 8de2 8de3 8de4 8de5 err: 8de6 8de7 8df0 8df1 8df2 8df3 8df4 c0c0 err: c0c1 c0c2 c0c3 c0c4 c0c5 c0c6 c0c7 c0d0 err: c0d1 c0d2 c0d3 c0d4 c0d5 c0d6 c0d7 c0e0 err: c0e1 c0e2 c0e3 c0e4 c0e5 c0e6 c0e7 c0f0 Playback restart whereas Capture case is also detected with loopback scenario 1 (reproducibility 100%), capturing continuously, and playing by periods of time. $ atest -a -D SSI3 -c 8 -r 48000 capture play -r 1000,200 dbg: SSI3: capture_start dbg: SSI3: playback_start dbg: SSI3: will stop every 1000 ms during 200 ms warn: Valid frame after 4 null frames warn: 0010 0011 0012 0013 0014 0015 0016 0017 warn: SSI3: PT_W4_STOP warn: SSI3: PT_W4_RESTART err: invalid frame after 1602 null frames err: eaa1 eaa2 eaa3 eaa4 eaa5 eaa6 eaa7 eab0 err: eab1 eab2 eab3 eab4 5810 5811 5812 5813 dbg: stop on first error total number of sequence errors: 143 Both cases are resolved by using the mostly undocumented SOR.RX_CLR and SOR TX_CLR (we can find the documentation in IMX51 reference manual at section 56.3.3.15). Arnaud [1] https://github.com/amouiche/atest [2] http://mailman.alsa-project.org/pipermail/alsa-devel/2015-October/099221.ht… Arnaud Mouiche (5): ASoC: fsl_ssi: The IPG/5 limitation concerns the bitclk, not the sysclk. ASoC: fsl_ssi: Save a dev reference for dev_err() purpose. ASoC: fsl_ssi: Fix samples being dropped as Playback startup ASoC: fsl_ssi: Fix channel slipping in Playback at startup ASoC: fsl_ssi: Fix channel slipping on capture (or playback) restart in full duplex. sound/soc/fsl/fsl_ssi.c | 69 ++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 60 insertions(+), 9 deletions(-) -- 1.9.1

4 17

[alsa-devel] Help with wm8731 support for the Utilite (imx6q)
by Jonathan Bennett 06 Apr '16

06 Apr '16

Hey, I'm working with a compulab utilite, trying to get everything working with 3.17, with the eventual goal of getting better support for it upstream. Currently fighting the sound. It's a imx6q talking to a wm8731 over i2c/i2s. I am booting Fedora 21 arm Alpha, with my own dtb ( http://pastebin.com/4a4PBKwx) and driver (http://pastebin.com/1CsesuVV) It shows up in aplay -l, but trying to play anything to it gives me a div by 0 in a driver: [<c04f27e4>] (Ldiv0) from [<bf50512c>] (fsl_ssi_hw_params+0x194/0x364 [snd_soc_fsl_ssi]) This div0 happens in sound/soc/fsl/fsl_ssi.c, in the function fsl_ssi_set_bclk. My driver file is an almost direct copy of what compulab shipped with a 3.10 kernel. This is my first attempt at kernel hacking, so any help would be appreciated. ~Jonathan Bennett

4 19

[alsa-devel] [PATCH v2] ASoC: fsl-asoc-card: add wm8960 support
by Zidan Wang 05 Apr '16

05 Apr '16

add wm8960 support for fsl-asoc-card Signed-off-by: Zidan Wang <zidan.wang(a)freescale.com> --- sound/soc/fsl/fsl-asoc-card.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c index 040362f..5aeb6ed 100644 --- a/sound/soc/fsl/fsl-asoc-card.c +++ b/sound/soc/fsl/fsl-asoc-card.c @@ -23,6 +23,7 @@ #include "../codecs/sgtl5000.h" #include "../codecs/wm8962.h" +#include "../codecs/wm8960.h" #define RX 0 #define TX 1 @@ -479,6 +480,12 @@ static int fsl_asoc_card_probe(struct platform_device *pdev) priv->codec_priv.fll_id = WM8962_SYSCLK_FLL; priv->codec_priv.pll_id = WM8962_FLL; priv->dai_fmt |= SND_SOC_DAIFMT_CBM_CFM; + } else if (of_device_is_compatible(np, "fsl,imx-audio-wm8960")) { + codec_dai_name = "wm8960-hifi"; + priv->card.set_bias_level = fsl_asoc_card_set_bias_level; + priv->codec_priv.fll_id = WM8960_SYSCLK_AUTO; + priv->codec_priv.pll_id = WM8960_SYSCLK_AUTO; + priv->dai_fmt |= SND_SOC_DAIFMT_CBM_CFM; } else { dev_err(&pdev->dev, "unknown Device Tree compatible\n"); return -EINVAL; @@ -582,6 +589,7 @@ static const struct of_device_id fsl_asoc_card_dt_ids[] = { { .compatible = "fsl,imx-audio-cs42888", }, { .compatible = "fsl,imx-audio-sgtl5000", }, { .compatible = "fsl,imx-audio-wm8962", }, + { .compatible = "fsl,imx-audio-wm8960", }, {} }; -- 1.9.1

4 4

[alsa-devel] [PATCH 1/1] sst: select DW_DMAC_CORE since it's mandatory
by Andy Shevchenko 18 Mar '16

18 Mar '16

While here group selectors under SND_SOC_INTEL_HASWELL and SND_SOC_INTEL_BAYTRAIL. Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- sound/soc/intel/Kconfig | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig index 05fde5e6e..bc5281e 100644 --- a/sound/soc/intel/Kconfig +++ b/sound/soc/intel/Kconfig @@ -35,15 +35,17 @@ config SND_SOC_INTEL_SST_ACPI config SND_SOC_INTEL_HASWELL tristate + select DW_DMAC_CORE + select SND_SOC_INTEL_SST config SND_SOC_INTEL_BAYTRAIL tristate + select DW_DMAC_CORE + select SND_SOC_INTEL_SST config SND_SOC_INTEL_HASWELL_MACH tristate "ASoC Audio DSP support for Intel Haswell Lynxpoint" depends on X86_INTEL_LPSS && I2C && I2C_DESIGNWARE_PLATFORM - depends on DW_DMAC_CORE - select SND_SOC_INTEL_SST select SND_SOC_INTEL_HASWELL select SND_SOC_RT5640 help @@ -55,8 +57,6 @@ config SND_SOC_INTEL_HASWELL_MACH config SND_SOC_INTEL_BYT_RT5640_MACH tristate "ASoC Audio driver for Intel Baytrail with RT5640 codec" depends on X86_INTEL_LPSS && I2C - depends on DW_DMAC_CORE - select SND_SOC_INTEL_SST select SND_SOC_INTEL_BAYTRAIL select SND_SOC_RT5640 help @@ -66,8 +66,6 @@ config SND_SOC_INTEL_BYT_RT5640_MACH config SND_SOC_INTEL_BYT_MAX98090_MACH tristate "ASoC Audio driver for Intel Baytrail with MAX98090 codec" depends on X86_INTEL_LPSS && I2C - depends on DW_DMAC_CORE - select SND_SOC_INTEL_SST select SND_SOC_INTEL_BAYTRAIL select SND_SOC_MAX98090 help @@ -76,10 +74,7 @@ config SND_SOC_INTEL_BYT_MAX98090_MACH config SND_SOC_INTEL_BROADWELL_MACH tristate "ASoC Audio DSP support for Intel Broadwell Wildcatpoint" - depends on X86_INTEL_LPSS && I2C && DW_DMAC && \ - I2C_DESIGNWARE_PLATFORM - depends on DW_DMAC_CORE - select SND_SOC_INTEL_SST + depends on X86_INTEL_LPSS && I2C && I2C_DESIGNWARE_PLATFORM select SND_SOC_INTEL_HASWELL select SND_SOC_RT286 help -- 2.5.1

2 2

[alsa-devel] Trouble about Roland UA-11 UA-33 UA-55 and snd-usb-audio module
by FirebUntU 07 Mar '16

07 Mar '16

Hi guys, I write you about support of snd-usb-audio module and a relatively-new gamma of devices from Roland/Edirol: DUO CAPTURE, TRI CAPTURE and QUAD CAPTURE respectively: UA-11, UA-33, UA-55 These aren't not listed in the Alsa db. I have searched a solution for a week and I haven't found a trick to make UA-11 to work under Alsa 1.25.0 then I downloaded the driver for try to patch it and I found these devices is not listed in the tricks table In despair I have played with the switch button called "EXT * **" in the bottom of the unit of UA-11 and magically the device ID is transformed from * 0582:012b to ** 0582:0137 Image: https://dl.dropbox.com/u/32759898/output.jpg (Rear of the UA-11 unit, from the manual) *Before* (Recognized from udev - Unknown from alsa): http://www.alsa-project.org/db/?f=502ee68cf31882ba9ef23525fd66452c34d329e1 *After* (Recognized from udev - Recognized from alsa): http://www.alsa-project.org/db/?f=b2ae3e4331fb3fe613ba71e7aba1ad2e0e6dcd29 In the tricks table header of ALSA the 0582:0137 stay for PM-1000 in /TODO/ statement. I understand the EXT switch, undiscovered in the manual of the DUO CAPTURE is - as the fact - the Advanced Mode. Now the peripherical running both in playback and recording in 16 and 24 bit and without any mixer options in alsamixer. Can you update future releases with this gamma of devices? Awaiting for your positive response :) Thanks. Best regards, Leonardo

9 16

[alsa-devel] writing an alsa driver
by Michele Curti 04 Mar '16

04 Mar '16

Hi all, I'm going to *try* to "write" a driver for the sound card on my new laptop, an asus x205ta. To be fair I have almost no experience but I'm hoping that all the code is already present and it only needs some adaptations. The cpu is a intel bay trail z3735f, the sound card is a realtek rt5648 that has the same product Id of the rt5645 (0x6308). I see in kernel sources: - the codec driver sound/soc/codecs/rt5645.c - a baytrail board that uses the rt5640 sound/soc/intel/boards/byt-rt5640.c - a braswell board that uses the rt5645 sound/soc/intel/boards/cht_bsw_rt5645.c What do you think? Is it feasible, given a good amount of free-time? :p Thanks, Michele

10 46

[alsa-devel] [PATCH] ASoC: pxa: remove incorrect do_div() call
by Arnd Bergmann 26 Feb '16

26 Feb '16

The new optimized do_div implementation (now in asm-generic/next) exposes a glitch in the brownstone audio driver by producing a compile-time warning: sound/soc/pxa/brownstone.c: In function 'brownstone_wm8994_hw_params': sound/soc/pxa/brownstone.c:67:85: warning: comparison of distinct pointer types lacks a cast sound/soc/pxa/brownstone.c:67:10125: warning: right shift count >= width of type [-Wshift-count-overflow] sound/soc/pxa/brownstone.c:67:10254: warning: passing argument 1 of '__div64_32' from incompatible pointer type [-Wincompatible-pointer-types] The driver just divides two plain integer values, so it should not use do_div to start with, but has apparently done so ever since the code was first merged. This replaces do_div with a simple division operator. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- I think this one is harmless, so we only need it in 4.5 to avoid the warning, but not backported to earlier kernels. Found today on ARM allmodconfig diff --git a/sound/soc/pxa/brownstone.c b/sound/soc/pxa/brownstone.c index 6147e86e9b0f..416ea646c3b1 100644 --- a/sound/soc/pxa/brownstone.c +++ b/sound/soc/pxa/brownstone.c @@ -63,8 +63,7 @@ static int brownstone_wm8994_hw_params(struct snd_pcm_substream *substream, sysclk = params_rate(params) * 512; sspa_mclk = params_rate(params) * 64; } - sspa_div = freq_out; - do_div(sspa_div, sspa_mclk); + sspa_div = freq_out / sspa_mclk; snd_soc_dai_set_sysclk(cpu_dai, MMP_SSPA_CLK_AUDIO, freq_out, 0); snd_soc_dai_set_pll(cpu_dai, MMP_SYSCLK, 0, freq_out, sysclk);

3 4

[alsa-devel] Usb audio - unsuported sampling rates
by Gordon Dilan 12 Feb '16

12 Feb '16

Hello, I'm using an usb mic which(according to it's producer should support up to 48kHz sampling rate). The problem is ALSA allows me to use only 16 kHz for this device. I do not want to resample the data, I want to sample it at 48kHz in order to be able to record some high pitch sounds 18-20kHz. I would want to try to do any modifications necessary in order to try support 48kHz, but I'm not sure where to start. Some information: cat /proc/asound/modules ... 1 snd_usb_audio arecord --list-devices **** List of CAPTURE Hardware Devices **** .... card 1: CameraB409241 [USB Camera-B4.09.24.1], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 when I try to use: arecord -v -D hw:1,0 -f S16_LE -c 4 -r 48000 gigi.wav I get this: Recording WAVE 'gigi.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 4 Warning: rate is not accurate (requested = 48000Hz, got = 16000Hz) please, try the plug plugin Hardware PCM card 1 'USB Camera-B4.09.24.1' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 4 rate : 16000 exact rate : 16000 (16000/1) msbits : 16 buffer_size : 8000 period_size : 2000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 2000 period_event : 0 start_threshold : 1 stop_threshold : 8000 silence_threshold: 0 silence_size : 0 boundary : 2097152000 appl_ptr : 0 hw_ptr : 0 Any sampling rate I would try higher or lower than 16kHz, I will always get 16000 kHz. Some more information: lsusb Bus 001 Device 007: ID 1415:2000 Nam Tai E&E Products Ltd. or OmniVision Technologies, Inc. Sony Playstation Eye lsusb -t /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/2p, 480M |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M |__ Port 2: Dev 7, If 0, Class=vend., Driver=ov534, 480M |__ Port 2: Dev 7, If 1, Class=audio, Driver=snd-usb-audio, 480M |__ Port 2: Dev 7, If 2, Class=audio, Driver=snd-usb-audio, 480M At the moment I'm looking inside ALSA's source code to try to see from where this limitation of 16000kHz for my device appears, but I have to admit that I'm kind of lost. Any pointers on what direction should I go to try make my desired rate supported would be greatly appreciated! Thank you and best regards, Gordon

3 6