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

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

[alsa-devel] [PATCH v2 1/3] ARM: shmobile: armadillo800eva: Properly specify HDMI audio link format
by Lars-Peter Clausen 29 Jan '16

29 Jan '16

The DAI link format should be specified for the whole link rather than just one component on the link. So move the format specification for the HDMI audio link from the CPU component to the link itself. Since the sh-mobile-hdmi DAI driver doesn't implement the set_fmt() callback in this case there is no functional difference between only specifying the the format for the CPU side or for the whole link, but the later it will allow us to remove support for just specifying the format for one component. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- No changes since v1. --- arch/arm/mach-shmobile/board-armadillo800eva.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c b/arch/arm/mach-shmobile/board-armadillo800eva.c index 6d949f1..75de26c 100644 --- a/arch/arm/mach-shmobile/board-armadillo800eva.c +++ b/arch/arm/mach-shmobile/board-armadillo800eva.c @@ -1040,9 +1040,9 @@ static struct asoc_simple_card_info fsi2_hdmi_info = { .card = "FSI2B-HDMI", .codec = "sh-mobile-hdmi", .platform = "sh_fsi2", + .daifmt = SND_SOC_DAIFMT_CBS_CFS, .cpu_dai = { .name = "fsib-dai", - .fmt = SND_SOC_DAIFMT_CBS_CFS, }, .codec_dai = { .name = "sh_mobile_hdmi-hifi", -- 1.8.0

5 15

[alsa-devel] [PATCH 0/4] ASoC: fix saif record unwork issue
by Dong Aisheng 16 Jan '16

16 Jan '16

This patch series mainly fixes the saif record unwork issue. The root cause consists of: 1) clk_prepare and clk_enable un-balanced 2) missed setting a proper initial clock rate for saif in dt 3) sgtl5000 dapm widget kcontrol does not work So can not test record on mx28evk. 4) missed setting clkmux mode for saif in dt With this patch series it can fix sgtl5000 widget kcontrol unwork and saif record unwork issue. BTW, just let people konw, i still met a few overruns during record, that's another issue and will be fixed in separte patches later. Patch based on sound-2.6/for-3.6. Dong Aisheng (4): ASoC: mxs-saif: fix clock prepare and enable unbalance issue ASoC: mxs-saif: set a base clock rate for EXTMASTER mode work ASoC: sgtl5000: remove unneeded snd_soc_dapm_new_widgets in probe ARM: mx28evk: add missed clkmux select for saif arch/arm/mach-mxs/mach-mxs.c | 3 +++ sound/soc/codecs/sgtl5000.c | 2 -- sound/soc/mxs/mxs-saif.c | 24 ++++++++++++++++++++++++ 3 files changed, 27 insertions(+), 2 deletions(-)

5 20

[alsa-devel] [PATCH 00/13] dmaengine + omap drivers: support fro deferred probing
by Peter Ujfalusi 20 Nov '15

20 Nov '15

Hi, Vinod: as I promised: https://lkml.org/lkml/2015/5/8/80 With this series it is possible to put omap-dma or edma to even late_initcall and the drivers will figure out the load order fine(ish). We need to add dma_request_slave_channel_compat_reason() which is the equivalent of dma_request_slave_channel_compat() but returning with error codes in case of failure instead of NULL pointer. The rest of the series just converts the OMAP/daVinci drivers to use this new function to get the channel(s) and to handle the deferred probing. I did not moved the omap-dma, edma or ti-dma-crossbar from arch_initcall. If I do so UART will only comes up after the DMA driver is loaded since we are using, or going to use 8250 with DAM support. This delays the kernel messages. Other issue is the MMC/SD cards. On board with eMMC and SD card slot the mmcblk0/1 might get swapped due to different probe order for the MMC/SD drivers. For example in omap5-uevm: 1. omap-dma in arch_initcall the SD card is mmcblk1 (4809c000.mmc) and eMMC is mmcblk0 (480b4000.mmc) 2. omap-dma in late_initcall the SD card is mmcblk0 (4809c000.mmc) and eMMC is mmcblk1 (480b4000.mmc) Because in case 1 the 4809c000.mmc got deferred by missing regulator so 480b4000.mmc got registered first. In case 2 both deferring because of DMA and at the end 4809c000.mmc get registered first. So far I have not found a way to bind mmcblk0/1 to a specific node... Regards, Peter --- Peter Ujfalusi (13): dmaengine: of_dma: Correct return code for of_dma_request_slave_channel in case !CONFIG_OF dmaengine: Introduce dma_request_slave_channel_compat_reason() serial: 8250_dma: Support for deferred probing when requesting DMA channels mmc: omap_hsmmc: No need to check DMA channel validity at module remove mmc: omap_hsmmc: Support for deferred probing when requesting DMA channels mmc: omap: Support for deferred probing when requesting DMA channels mmc: davinci_mmc: Support for deferred probing when requesting DMA channels crypto: omap-aes - Support for deferred probing when requesting DMA channels crypto: omap-des - Support for deferred probing when requesting DMA channels crypto: omap-sham - Support for deferred probing when requesting DMA channel spi: omap2-mcspi: Support for deferred probing when requesting DMA channels [media] omap3isp: Support for deferred probing when requesting DMA channel ASoC: omap-pcm: Switch to use dma_request_slave_channel_compat_reason() drivers/crypto/omap-aes.c | 38 ++++++++++++++++--------------- drivers/crypto/omap-des.c | 38 ++++++++++++++++--------------- drivers/crypto/omap-sham.c | 15 ++++++++---- drivers/media/platform/omap3isp/isphist.c | 12 +++++++--- drivers/mmc/host/davinci_mmc.c | 26 ++++++++++++--------- drivers/mmc/host/omap.c | 20 ++++++++++++---- drivers/mmc/host/omap_hsmmc.c | 28 ++++++++++------------- drivers/spi/spi-omap2-mcspi.c | 36 +++++++++++++++++------------ drivers/tty/serial/8250/8250_dma.c | 18 +++++++-------- include/linux/dmaengine.h | 22 ++++++++++++++++++ include/linux/of_dma.h | 2 +- sound/soc/omap/omap-pcm.c | 16 ++++++++----- 12 files changed, 164 insertions(+), 107 deletions(-) -- 2.3.5

10 57

[alsa-devel] [PATCH] ARM: sun7i: Fix HDMI Audio driver's Alsa interface and do 8CH IEC60958 output
by thomas schorpp 13 Nov '15

13 Nov '15

Version 0.2 Users doc: All You need to get a HDMI- Pulseaudio Server on Your sunxi board to output Multichannel PCM is this line in default.pa, ttable pcms in asound.conf get ignored: +load-module module-alsa-sink device="hw:1,0" channels=8 channel_map="front-left,front-right,lfe,front-center,rear-left,rear-right,side-left,side-right" ### Automatically load driver modules depending on the hardware available .ifexists module-udev-detect.so load-module module-udev-detect Probe with speaker-test, You may need other channel mapping than I. If you run PA in system mode please read the security documentation before, see PA log for link. y tom

2 1

[alsa-devel] [PATCH 0/8] Add support for Wolfson WM8998 and WM1814 codecs
by Richard Fitzgerald 02 Oct '15

02 Oct '15

This set of patches adds support for the Wolfson Microelectronics WM8998 and WM1814 codecs. Richard Fitzgerald (8): mfd: arizona: Split INx_MODE into two fields ASoC: arizona: add defines for single-input gain control mfd: arizona: Add support for WM8998 and WM1814 gpio: arizona: add support for WM8998 and WM1814 regulator: arizona: add support for WM8998 and WM1814 extcon: arizona: Add support for WM8998 and WM1814 ASoC: wm8998: Initial WM8998 codec driver Documentation: Add WM8998/WM1814 device tree bindings Documentation/devicetree/bindings/mfd/arizona.txt | 3 + drivers/extcon/extcon-arizona.c | 33 +- drivers/gpio/gpio-arizona.c | 2 + drivers/mfd/Kconfig | 6 + drivers/mfd/Makefile | 3 + drivers/mfd/arizona-core.c | 106 ++- drivers/mfd/arizona-i2c.c | 8 + drivers/mfd/arizona-irq.c | 9 + drivers/mfd/arizona.h | 5 + drivers/mfd/wm8998-tables.c | 1592 +++++++++++++++++++++ drivers/regulator/arizona-ldo1.c | 2 + include/linux/mfd/arizona/core.h | 3 + include/linux/mfd/arizona/pdata.h | 5 +- include/linux/mfd/arizona/registers.h | 247 +++- sound/soc/codecs/Kconfig | 6 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/arizona.c | 7 + sound/soc/codecs/arizona.h | 7 +- sound/soc/codecs/wm8998.c | 1392 ++++++++++++++++++ sound/soc/codecs/wm8998.h | 23 + 20 files changed, 3432 insertions(+), 29 deletions(-) create mode 100644 drivers/mfd/wm8998-tables.c create mode 100644 sound/soc/codecs/wm8998.c create mode 100644 sound/soc/codecs/wm8998.h -- 1.7.2.5

6 22

[alsa-devel] SoC/Codecs/SGTL5000 - Non working MIC_BIAS Voltage settings
by gianluca 30 Sep '15

30 Sep '15

Hello, in attachment there is a small patch to ensure the correct register value for MIC BIAS Voltage. Best regards -- Eurek s.r.l. | Electronic Engineering | http://www.eurek.it via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120 p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212

4 5

[alsa-devel] No stream timing info with alsa pulse plugin?
by sqweek 24 Sep '15

24 Sep '15

Hi guys, I discovered on my machine that alsa_snd_pcm_status_get_tstamp (and also get_htstamp) stop working when my asoundrc invokes the pulse plugin. That is, normally they work fine but once the sound is going via pulse the returned time stamp is always zero. I'm trying to understand why that is. I couldn't really find any discussion of the pulse plugin on the archives so I'm not entirely sure I've found the right list; I was directed here via the pulseaudio bugzilla[1]. [1] https://bugs.freedesktop.org/show_bug.cgi?id=88503 Thanks for any assistance! -sqweek

4 3