April 2011 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] TASCAM US-122MKII
by Dominic Powell 12 Apr '11

12 Apr '11

Hi. I've been trying over the last few days to get my US-122MKII working with Linux Debian. I'm running the latest version of debian amd64. I was just wondering if you had any suggestions or help so I could get it working. The output I get from "lsusb -v -d 0644:" (0644 being the US-122MKII) is http://pastebin.com/B4GZK3Ep. Just wondering if it was possible to make this work with a quirk or something along those lines. Cheers Dominic

1 0

[alsa-devel] pls help to debug / patch ALC861 on Uniwill L51RI
by Florian 12 Apr '11

12 Apr '11

I have a laptop (Uniwill L51RI [Gericom Hollywood Advance]) with HDA ALC861. On initial installation of Ubuntu (any from 8.x - to 10.10) sound output works with ALSA without problem, input not at all. I have managed to get the microphone sound (int. or ext. can't remember) played back via speakers using HDA-Analyzer, not managed to get it to record etc. My plan:

2 1

[alsa-devel] External microphone doesn't work on Thinkpad T410(i)
by Hugo Estopendo 12 Apr '11

12 Apr '11

Hi there, my ThinkPad does not have 2 audio jacks, it has just one for speakers and microphone both, like a MacBook or Smartphone. It also has an internal mic under the screen. Normal audio playback works via the internal speakers and the jack both. The internal mic works, but when I plug a stereo headset with a mic included on this one jack, the internal mic is still used and the external mic is just ignored. I alread opened a bug report: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5325 output of alsa information script: http://www.alsa-project.org/db/?f=68cddd0301737d0060ebfc1d292ac82953e273d7 lspci output: https://bugtrack.alsa-project.org/alsa-bug/file_download.php?file_id=3522&t… Greetings, Hugo

2 1

[alsa-devel] [PATCH V2 0/3] Add WM8580 PCM Machine driver for Samsung SoCs
by Sangbeom Kim 12 Apr '11

12 Apr '11

Hi, This is 2nd patchset for WM8580 pcm machine driver that supports PCM audio on SMDKC110, SMDKV210, SMDK6450, SMDK6440. and It is tested on SMDKC110, SMDKV210, SMDKV6450. Changeds since v1: - Used snd_soc_register_card() for new machines - Modified Kconfig for useless config Based on these patches WM8580 pcm machine driver supports followings: o Playback supports 8kHz sampling rates. o Capture supports 8kHz sampling rates. This patchset contains followings o To Kukjin Kim and Ben Dooks, [PATCH 1/3] ARM: S5PV210: Add PCM audio support for WM8580 [PATCH 2/3] ARM: S5P64X0: Add PCM audio support for WM8580 o To Jassi Brar, Mark Brown and Liam Girdwood, [PATCH 3/3] ASoC: SAMSUNG: Add WM8580 PCM Machine driver Best Regards, SB Kim (Sangbeom Kim)

6 8

[alsa-devel] incoming sequencer event timestamping (via a running queue): how?
by R. Dresens 12 Apr '11

12 Apr '11

Hello, I'm attempting to write a program that lets me record (and play) MIDI sequences, I have created a sequencer queue (with `snd_seq_alloc_queue`), and when I set it up and let it run I can observe that the tick value properly increases (with `snd_seq_queue_status_get_tick_time`); everything runs fine. Queing events to an output work as well. But is it somehow possible to bind "incoming events" to this queue as well? (...in such a way that the `event->time.tick` value of these incoming events is used to automatically store the queue timer value at reception? ...) At this moment, I just sample the tick value manually when I get an event. That kinda works, but chances are high that the kernel sequencer system can do that for me with more accuracy? I wrote a function that essentially reconnects the inputs of the port used for reception just before the queue is started. This allows me to set the queue explicitly. I also enable `snd_seq_port_subscribe_set_time_update`. It doesnt't work (yet). Should this work? Am I on the right track? Or am I missing something? Can anyone give me a hint? Thanks! Greetings, Raymond.

3 3

[alsa-devel] Tegra ASoC, multiple boards, platform data, and conditionals in machine driver
by Stephen Warren 11 Apr '11

11 Apr '11

Mark, I'm thinking of upstreaming ASoC support for some of the other Tegra boards that got added later in 2.6.39; Seaboard, Kaen, and Aebl. [Ventana could also be supported, but it's identical to Harmony. I imagine people will want Toshiba AC100 and Trimslice support in the not-too- distant future, but I don't have schematics for those boards at present] This raises a couple questions: 1) Currently, the Harmony machine driver gets all its GPIO information from platform data defined in arch/arch/mach-tegra/include/mach/harmony_audio.h. Supporting new machines would entail one of: a) Creating a new header for each new machine (or set of similar machines). This could mean many headers pretty quickly. b) Expanding that structure to include extra fields, thus making it generic enough to support any Tegra machine, which would probably also entail renaming the file to not be Harmony-specific. Some GPIO fields would be optional (i.e. initialized to -1) if a feature wasn't available on a given board. c) Perhaps switch to using platform_get_resource() to retrieve the data rather than custom per-machine/SoC structures, although that'd require adding new resource types for GPIOs etc. That said, I noticed that all(?) the other machine drivers simply use hard-coded GPIO numbers (sometimes defined locally, probably sometimes from machine header files), rather than having the values passed in through platform_data. This eliminates the need for platform_data structures etc. Is this simply a legacy because ASoC machine drivers weren't able to be first-class platform_devices, or is this still an acceptable style? I'm tempted to convert the Tegra Harmony driver to this style (but including headers to define the GPIO names instead of duplicating definitions in the machine file), and also use it for new machines. 2) Seaboard has a couple of derivatives which are very similar, but do have some differences in the audio path and elsewhere. In the ChromeOS kernel, we have a single ASoC machine driver covering Seaboard and two derivatives, with conditional code. I've placed an example at the end of this mail. Do you have a preference for having separate files for each machine without the conditional code v.s. a single machine driver with a lot of conditional code? If we go the conditional route, it might even be possible to merge the Harmony and Seaboard machine drivers into one. Thanks for any feedback. Example from static int seaboard_asoc_init(): ret = gpio_request(pdata->gpio_spkr_en, "spkr_en"); if (ret) { dev_err(card->dev, "cannot get spkr_en gpio\n"); return ret; } seaboard->gpio_requested |= GPIO_SPKR_EN; gpio_direction_output(pdata->gpio_spkr_en, 0); if (pdata->gpio_hp_mute != -1) { ret = gpio_request(pdata->gpio_hp_mute, "hp_mute"); if (ret) { dev_err(card->dev, "cannot get hp_mute gpio\n"); return ret; } seaboard->gpio_requested |= GPIO_HP_MUTE; gpio_direction_output(pdata->gpio_hp_mute, 0); } ... if (machine_is_seaboard()) { snd_soc_dapm_add_routes(dapm, seaboard_audio_map, ARRAY_SIZE(seaboard_audio_map)); } else if (machine_is_kaen()) { snd_soc_dapm_add_routes(dapm, kaen_audio_map, ARRAY_SIZE(kaen_audio_map)); } else { snd_soc_dapm_add_routes(dapm, aebl_audio_map, ARRAY_SIZE(aebl_audio_map)); } ... snd_soc_dapm_nc_pin(dapm, "IN1L"); if (machine_is_kaen()) snd_soc_dapm_nc_pin(dapm, "IN1R"); snd_soc_dapm_nc_pin(dapm, "IN2L"); if (!machine_is_kaen()) snd_soc_dapm_nc_pin(dapm, "IN2R"); snd_soc_dapm_nc_pin(dapm, "IN2L"); snd_soc_dapm_nc_pin(dapm, "IN3R"); snd_soc_dapm_nc_pin(dapm, "IN3L"); if (machine_is_aebl()) { snd_soc_dapm_nc_pin(dapm, "LON"); snd_soc_dapm_nc_pin(dapm, "RON"); snd_soc_dapm_nc_pin(dapm, "ROP"); snd_soc_dapm_nc_pin(dapm, "LOP"); } else { snd_soc_dapm_nc_pin(dapm, "LINEOUTR"); snd_soc_dapm_nc_pin(dapm, "LINEOUTL"); } -- nvpublic

3 7

[alsa-devel] SND_SOC_DAPM_VIRT_MUX question
by Koul, Vinod 11 Apr '11

11 Apr '11

Hi, I have the audio DSP decoder which I tried to connect to the codec. The decoder output is treated as Input. For the VIRT MUX i gave register bits as SND_SOC_NOPM both in MUX as well as enum describing this as my aim is to create a virtual mux for routing. Aim is to have usespace be able to use this mux and connect to either headset or speaker DAI or leave it non connected. Machine driver map is taking care of this. But the problem is that the this VIRT mux is not allowing me to change values :(, set to to 1. I remember that code checks if the path should be allowed for MUX and implements only if its allowed, but in virtual mix case it should not do so... or I am missing something? static const char *sn95031_decoder_text[] = {"None", "Speaker", "Headset"}; static const struct soc_enum sn95031_decoder_enum = SOC_ENUM_SINGLE(SND_SOC_NOPM, 0, 3, sn95031_decoder_text); static const struct snd_kcontrol_new sn95031_decoder_control = SOC_DAPM_ENUM("Route", sn95031_decoder_enum); SND_SOC_DAPM_VIRT_MUX_E("Compressed Decoder Mux", SND_SOC_NOPM, 0, 0, &sn95031_decoder_control, sn95031_decoder_event, SND_SOC_DAPM_POST_PMD), SND_SOC_DAPM_INPUT("Dummy"), /* sst decoder output*/ /* decoder output map */ {"Compressed Decoder Mux", NULL, "Compressed Decoder"}, {"IHFDAC Left", "Speaker", "Compressed Decoder Mux"}, {"IHFDAC Right", "Speaker", "Compressed Decoder Mux"}, {"PCM2_IN", "Headset", "Compressed Decoder Mux"}, {"Dummy", "None", "Compressed Decoder Mux"}, -- ~Vinod

2 1

[alsa-devel] [PATCH 0/3] ASoC: fsi: bug fix for driver probe/remove
by Kuninori Morimoto 11 Apr '11

11 Apr '11

Dear Mark, Liam These are bug fix patches for FSI driver probe/remove Kuninori Morimoto (3) ASoC: fsi: take care in failing case of dai register ASoC: fsi: modify vague PM control on probe ASoC: fsi: driver safely remove for against irq Magnus Can you please check #2 patch which modify pm_runtime Best regards -- Kuninori Morimoto

3 7

[alsa-devel] [PATCH] ASoC: sst_platform: Fix lock acquring
by Lu Guanqun 11 Apr '11

11 Apr '11

Fix the possible dead lock shown below: spin_lock sst_get_stream_status sst_period_elapsed intel_sst_interrupt handle_IRQ_event handle_fasteoi_irq do_IRQ common_interrupt spin_lock sst_set_stream_status sst_platform_pcm_trigger Signed-off-by: Lu Guanqun <guanqun.lu(a)intel.com> --- sound/soc/mid-x86/sst_platform.c | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/sound/soc/mid-x86/sst_platform.c b/sound/soc/mid-x86/sst_platform.c index 9ba9414..d827edb 100644 --- a/sound/soc/mid-x86/sst_platform.c +++ b/sound/soc/mid-x86/sst_platform.c @@ -116,18 +116,20 @@ struct snd_soc_dai_driver sst_platform_dai[] = { static inline void sst_set_stream_status(struct sst_runtime_stream *stream, int state) { - spin_lock(&stream->status_lock); + unsigned long flags; + spin_lock_irqsave(&stream->status_lock, flags); stream->stream_status = state; - spin_unlock(&stream->status_lock); + spin_unlock_irqrestore(&stream->status_lock, flags); } static inline int sst_get_stream_status(struct sst_runtime_stream *stream) { int state; + unsigned long flags; - spin_lock(&stream->status_lock); + spin_lock_irqsave(&stream->status_lock, flags); state = stream->stream_status; - spin_unlock(&stream->status_lock); + spin_unlock_irqrestore(&stream->status_lock, flags); return state; }

4 6

[alsa-devel] [PATCH] ASoC: SAMSUNG: Fix the inverted clocks handling for pcm driver
by Sangbeom Kim 11 Apr '11

11 Apr '11

Fix the inverted clocks handling for pcm cpu driver. By using SND_SOC_DAIFMT_NB_NF, Audio noise can be generated on SMDK. Signed-off-by: Sangbeom Kim <sbkim73(a)samsung.com> --- sound/soc/samsung/pcm.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/samsung/pcm.c b/sound/soc/samsung/pcm.c index 38aac7d..9c7e8b4 100644 --- a/sound/soc/samsung/pcm.c +++ b/sound/soc/samsung/pcm.c @@ -350,8 +350,8 @@ static int s3c_pcm_set_fmt(struct snd_soc_dai *cpu_dai, ctl = readl(regs + S3C_PCM_CTL); switch (fmt & SND_SOC_DAIFMT_INV_MASK) { - case SND_SOC_DAIFMT_NB_NF: - /* Nothing to do, NB_NF by default */ + case SND_SOC_DAIFMT_IB_NF: + /* Nothing to do, IB_NF by default */ break; default: dev_err(pcm->dev, "Unsupported clock inversion!\n"); -- 1.7.1

4 3