September 2012 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [RFC] Channel mapping API (take 2)
by Takashi Iwai 07 Sep '12

07 Sep '12

Hi, my proposal for channel mapping API seems accepted fairly well through discussions at Plumbers, so I continued to work on it and uploaded the updated version. The kernel part is found in sound-unstable tree topic/tlv-chmap branch git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git and the alsa-lib part is found in github tree topic/chmap branch git://git.github.com/tiwai/alsa-lib.git The updated parts are: - SNDRV_CHMAP_NA was newly added, indicating the channel is not available or silent. - The channel position value is masked in lower 16bit. The upper bits are used for more channel attributes as bit flags. #define SNDRV_CHMAP_POSITION_MASK 0xffff The phase inverted channel has this bit: #define SNDRV_CHMAP_PHASE_INVERSE (0x01 << 16) And the driver-specific non-standard channel position has this: #define SNDRV_CHMAP_DRIVER_SPEC (0x02 << 16) - The alsa-lib API functions use snd_pcm_chmap_query_t and snd_pcm_chmap_t instead of ambiguous integer arrays. ================================================================ /** the channel map header */ typedef struct snd_pcm_chmap { unsigned int channels; unsigned int pos[0]; } snd_pcm_chmap_t; /** the header of array items returned from snd_pcm_query_chmaps() */ typedef struct snd_pcm_chmap_query { enum snd_pcm_chmap_type type; snd_pcm_chmap_t map; } snd_pcm_chmap_query_t; snd_pcm_chmap_query_t **snd_pcm_query_chmaps(snd_pcm_t *pcm); void snd_pcm_free_chmaps(snd_pcm_chmap_query_t **maps); snd_pcm_chmap_t *snd_pcm_get_chmap(snd_pcm_t *pcm); int snd_pcm_set_chmap(snd_pcm_t *pcm, const snd_pcm_chmap_t *map); ================================================================ The rest aren't so much changed. Only slight bug fixes. A big remaining question is whether the current kernel-side implementation is OK. We may add some PCM ops pointer instead of the current style using the direct control tlv/read/write override. But the kernel-side API can be changed even later, so I don't worry about it so much for now, as long as we can keep the ABI definition. thanks, Takashi

4 11

[alsa-devel] [PATCH 0/3] HDMI HBR(High Bit Rate) Feature bug fix for Intel's Chips
by Wang Xingchao 07 Sep '12

07 Sep '12

As i have no A/V receiver handy and could not test HBR playback directly, i removed the "RFC" type until the patchset was tested and proved working well. The patchset was tested on Intel chips and get positive feedback. Quote from "Øyvind Kvålsvoll <oyvind(a)kvalsvoll.com>": "TrueHD and DTS-MA work fine from XBMC, 2-ch playback also works fine from XBMC. Channels are all mapped to the right speaker, all 7.1." Quote from alanwww1: "I tested the patches. They work perfectly. I tested it with both DTS Master Audio and Dolby Tru HD streams. Also tested with speaker-test. Channel mapping was right." From: http://forum.xbmc.org/showthread.php?tid=128298&pid=1184574#pid1184574 Maybe there's still potential bug and i will keep on track that. The idea of this patch comes from Anssi, Big credit to him at first! Thanks the guys from XBMC forum which help test the patches. For people interested to test the patch, please remember to apply another change in alsa-lib side, you can refer to the patch detail from XBMC forum: http://forum.xbmc.org/showthread.php?tid=128298&pid=1178776#pid1178776 I will send that patch to alsa-lib mail-list later. Changelog: * do not touch channel_allocation priority order, use new api to get correct channels number * use spdif->status to check audio type, pcm or non-pcm * create new non_pcm_mapping[] for non_pcm audio in seperate block * add non_pcm hdmi_spec_per_cvt to remember previous audio type, used to determine whether need a channel mapping update during the pcm/non-pcm stream switch with same channel number. Wang Xingchao (3): ALSA: HDMI - Fix channel_allocation array wrong order ALSA: HDMI - Enable HBR feature on Intel chips ALSA: HDMI - Setup channel mapping for non_pcm audio sound/pci/hda/patch_hdmi.c | 56 ++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 51 insertions(+), 5 deletions(-) -- 1.7.9.5

3 6

Re: [alsa-devel] Should codec suspend when no paths are marked to be active across a suspend action?
by Mark Brown 07 Sep '12

07 Sep '12

On Thu, Sep 06, 2012 at 12:55:00PM -0700, Taylor Hutt wrote: > Shouldn't the codec be suspended if there are no paths set to remain > active across the suspend? Yes. If you're using an analogue bypass path there's a very recent commit in -next from me which should help, previously we weren't ever really suspending bypass paths at all (even before the changes to keep some paths active) though we might end up doing so by accident. Nobody noticed since essentially nobody uses analogue bypass any more.

1 0

[alsa-devel] UAC2 clock selector for AudioBox 1818VSL
by louis＠museresearch.com 06 Sep '12

06 Sep '12

Hi! I'm attempting to get the "Clock Selector" mixer control to work with the PreSonus AudioBox 1818VSL (a UAC2 device). The control shows up in amixer as an enumerated value, but I don't seem to be able to set it (I've tried amixer, alsactl, and setting it programmatically). The possible values are correct (listing Internal Clock, S/PDIF Clock, and ADAT Clock as possible options); It just doesn't appear to take my setting, by which I mean amixer doesn't update the settings, I still have the occasional click when the sampling rates match over S/PDIF and I attempt to use external sync. No error is returned. After digging around USB specs and ALSA's usb/mixer.c and being unfamiliar with both the USB audio spec and the inner workings of ALSA, I thought it'd be best to ask the list about this: How would I check to see if ALSA is asking the device to change clock source at all? -Louis

2 1

Re: [alsa-devel] [PATCH 6/9] ARM: OMAP: Move gpio.h to include/linux/platform_data
by Tony Lindgren 06 Sep '12

06 Sep '12

* Mohammed, Afzal <afzal(a)ti.com> [120903 03:15]: > Hi, > > On Fri, Aug 31, 2012 at 06:22:34, Tony Lindgren wrote: > > This way we can remove includes of plat/gpio.h which won't work > > with the single zImage support. > > > > Note that we also remove the cpu_class_is_omap2() check > > in gpio-omap.c as the drivers should not call it as we need to > > make it local to arch/arm/mach-omap2 for single zImage support. > > > > While at it, arrange the related includes in the standard way. > > > > Cc: Grant Likely <grant.likely(a)secretlab.ca> > > Cc: Linus Walleij <linus.walleij(a)linaro.org> > > Cc: linux-mtd(a)lists.infradead.org > > Cc: alsa-devel(a)alsa-project.org > > Acked-by: Tony Lindgren <tony(a)atomide.com> > > I think there is only one Tony ;) Heh thanks I'll tell myself to replace it with Signed-off-by :) Tony

1 0

Re: [alsa-devel] snd-usb: "delay: estimated 0, actual 352"
by Takashi Iwai 06 Sep '12

06 Sep '12

At Thu, 6 Sep 2012 11:43:48 +0200, Markus Trippelsdorf wrote: > > On 2012.09.06 at 10:21 +0200, Takashi Iwai wrote: > > At Thu, 06 Sep 2012 09:35:26 +0200, > > Takashi Iwai wrote: > > > > In short, a patch like below may fix the issue (note: completely > > untested!) > > No it doesn't, unfortunately... OK, I start tracking down the problem a bit more deeply now. The issue happens when the first two URBs are passed to retire_playback_urb(). These are URBs filled before start_endpoints() are set, so they contain actually zero size. Even though these are a sort of dummy packets, the driver still tries to check with the queued delay account, and gives bogus errors. So, essentially the messages are harmless and nothing to worry too much, but surely it doesn't look sexy. The patch below should fix the problem. Please give it a try. thanks, Takashi === From: Takashi Iwai <tiwai(a)suse.de> Subject: [PATCH] ALSA: usb-audio: Fix bogus error messages for delay accounting The recent fix for the missing fine delayed time adjustment gives strange error messages at each start of the playback stream, such as delay: estimated 0, actual 352 delay: estimated 353, actual 705 These come from the sanity check in retire_playback_urb(). Before the stream is activated via start_endpoints(), a few silent packets have been already sent. And at this point the delay account is still in the state as if the new packets are just queued, so the driver gets confused and spews the bogus error messages. For fixing the issue, we just need to check whether the received packet is valid, whether it's zero sized or not. Reported-by: Markus Trippelsdorf <markus(a)trippelsdorf.de> Cc: <stable(a)vger.kernel.org> [v3.5+] Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/usb/pcm.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index fd5e982..f782ce1 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -1140,6 +1140,12 @@ static void retire_playback_urb(struct snd_usb_substream *subs, int processed = urb->transfer_buffer_length / stride; int est_delay; + /* ignore the delay accounting when procssed=0 is given, i.e. + * silent payloads are procssed before handling the actual data + */ + if (!processed) + return; + spin_lock_irqsave(&subs->lock, flags); est_delay = snd_usb_pcm_delay(subs, runtime->rate); /* update delay with exact number of samples played */ -- 1.7.11.5

1 0

[alsa-devel] [PATCH v2] ASoC: samsung dma - Don't indicate support for pause/resume.
by Dylan Reid 06 Sep '12

06 Sep '12

The pause and resume operations indicate that the stream can be un-paused/resumed from the exact location they were paused/suspended. This is not true for this driver, the pause and suspend triggers share the same code path with stop, they flush all pending DMA transfers. This drops all pending samples. The pause_release/resume triggers are the same as start, except that prepare won't be called beforehand, nothing will be enqueued to the DMA engine and nothing will happen (no audio). Removing the pause flag will let apps know that it isn't supported. Removing the resume flag will cause user space to call prepare and start instead of resume, so audio will continue playing when the system wakes up. Before removing the pause and resume flags, I tested this on an exynos 5250, using 'aplay -i'. Pause/un-pause leads to silence followed by a write error. Suspend/resume testing led to the same result. Removing the two flags fixes suspend/resume (since snd_pcm_prepare is called again). And leads to a proper reporting of pause not supported. Signed-off-by: Dylan Reid <dgreid(a)chromium.org> --- sound/soc/samsung/dma.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/sound/soc/samsung/dma.c b/sound/soc/samsung/dma.c index f3ebc38..b70964e 100644 --- a/sound/soc/samsung/dma.c +++ b/sound/soc/samsung/dma.c @@ -34,9 +34,7 @@ static const struct snd_pcm_hardware dma_hardware = { .info = SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP | - SNDRV_PCM_INFO_MMAP_VALID | - SNDRV_PCM_INFO_PAUSE | - SNDRV_PCM_INFO_RESUME, + SNDRV_PCM_INFO_MMAP_VALID, .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_U16_LE | SNDRV_PCM_FMTBIT_U8 | @@ -248,15 +246,11 @@ static int dma_trigger(struct snd_pcm_substream *substream, int cmd) switch (cmd) { case SNDRV_PCM_TRIGGER_START: - case SNDRV_PCM_TRIGGER_RESUME: - case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: prtd->state |= ST_RUNNING; prtd->params->ops->trigger(prtd->params->ch); break; case SNDRV_PCM_TRIGGER_STOP: - case SNDRV_PCM_TRIGGER_SUSPEND: - case SNDRV_PCM_TRIGGER_PAUSE_PUSH: prtd->state &= ~ST_RUNNING; prtd->params->ops->stop(prtd->params->ch); break; -- 1.7.12.146.g16d26b1

2 1

[alsa-devel] [PATCH Resend2] ASoC: imx-mc13783: use defines instead of numerical address of register
by Gaëtan Carlier 06 Sep '12

06 Sep '12

This uses already defined name of registers and makes code more readable. Signed-off-by: Gaëtan Carlier <gcembed(a)gmail.com> --- sound/soc/codecs/mc13783.c | 58 +++++++++++++++++++++++-------------------- 1 files changed, 31 insertions(+), 27 deletions(-) diff --git a/sound/soc/codecs/mc13783.c b/sound/soc/codecs/mc13783.c index 8f726c0..bbfa553 100644 --- a/sound/soc/codecs/mc13783.c +++ b/sound/soc/codecs/mc13783.c @@ -426,16 +426,16 @@ static int mc13783_set_tdm_slot_sync(struct snd_soc_dai *dai, } static const struct snd_kcontrol_new mc1l_amp_ctl = - SOC_DAPM_SINGLE("Switch", 38, 7, 1, 0); + SOC_DAPM_SINGLE("Switch", MC13783_AUDIO_TX, 7, 1, 0); static const struct snd_kcontrol_new mc1r_amp_ctl = - SOC_DAPM_SINGLE("Switch", 38, 5, 1, 0); + SOC_DAPM_SINGLE("Switch", MC13783_AUDIO_TX, 5, 1, 0); static const struct snd_kcontrol_new mc2_amp_ctl = - SOC_DAPM_SINGLE("Switch", 38, 9, 1, 0); + SOC_DAPM_SINGLE("Switch", MC13783_AUDIO_TX, 9, 1, 0); static const struct snd_kcontrol_new atx_amp_ctl = - SOC_DAPM_SINGLE("Switch", 38, 11, 1, 0); + SOC_DAPM_SINGLE("Switch", MC13783_AUDIO_TX, 11, 1, 0); /* Virtual mux. The chip does the input selection automatically @@ -461,22 +461,22 @@ static const struct snd_kcontrol_new right_input_mux = SOC_DAPM_ENUM_VIRT("Route", adcr_enum); static const struct snd_kcontrol_new samp_ctl = - SOC_DAPM_SINGLE("Switch", 36, 3, 1, 0); + SOC_DAPM_SINGLE("Switch", MC13783_AUDIO_RX0, 3, 1, 0); static const struct snd_kcontrol_new lamp_ctl = - SOC_DAPM_SINGLE("Switch", 36, 5, 1, 0); + SOC_DAPM_SINGLE("Switch", MC13783_AUDIO_RX0, 5, 1, 0); static const struct snd_kcontrol_new hlamp_ctl = - SOC_DAPM_SINGLE("Switch", 36, 10, 1, 0); + SOC_DAPM_SINGLE("Switch", MC13783_AUDIO_RX0, 10, 1, 0); static const struct snd_kcontrol_new hramp_ctl = - SOC_DAPM_SINGLE("Switch", 36, 9, 1, 0); + SOC_DAPM_SINGLE("Switch", MC13783_AUDIO_RX0, 9, 1, 0); static const struct snd_kcontrol_new llamp_ctl = - SOC_DAPM_SINGLE("Switch", 36, 16, 1, 0); + SOC_DAPM_SINGLE("Switch", MC13783_AUDIO_RX0, 16, 1, 0); static const struct snd_kcontrol_new lramp_ctl = - SOC_DAPM_SINGLE("Switch", 36, 15, 1, 0); + SOC_DAPM_SINGLE("Switch", MC13783_AUDIO_RX0, 15, 1, 0); static const struct snd_soc_dapm_widget mc13783_dapm_widgets[] = { /* Input */ @@ -487,13 +487,13 @@ static const struct snd_soc_dapm_widget mc13783_dapm_widgets[] = { SND_SOC_DAPM_INPUT("RXINL"), SND_SOC_DAPM_INPUT("TXIN"), - SND_SOC_DAPM_SUPPLY("MC1 Bias", 38, 0, 0, NULL, 0), - SND_SOC_DAPM_SUPPLY("MC2 Bias", 38, 1, 0, NULL, 0), + SND_SOC_DAPM_SUPPLY("MC1 Bias", MC13783_AUDIO_TX, 0, 0, NULL, 0), + SND_SOC_DAPM_SUPPLY("MC2 Bias", MC13783_AUDIO_TX, 1, 0, NULL, 0), - SND_SOC_DAPM_SWITCH("MC1L Amp", 38, 7, 0, &mc1l_amp_ctl), - SND_SOC_DAPM_SWITCH("MC1R Amp", 38, 5, 0, &mc1r_amp_ctl), - SND_SOC_DAPM_SWITCH("MC2 Amp", 38, 9, 0, &mc2_amp_ctl), - SND_SOC_DAPM_SWITCH("TXIN Amp", 38, 11, 0, &atx_amp_ctl), + SND_SOC_DAPM_SWITCH("MC1L Amp", MC13783_AUDIO_TX, 7, 0, &mc1l_amp_ctl), + SND_SOC_DAPM_SWITCH("MC1R Amp", MC13783_AUDIO_TX, 5, 0, &mc1r_amp_ctl), + SND_SOC_DAPM_SWITCH("MC2 Amp", MC13783_AUDIO_TX, 9, 0, &mc2_amp_ctl), + SND_SOC_DAPM_SWITCH("TXIN Amp", MC13783_AUDIO_TX, 11, 0, &atx_amp_ctl), SND_SOC_DAPM_VIRT_MUX("PGA Left Input Mux", SND_SOC_NOPM, 0, 0, &left_input_mux), @@ -503,12 +503,12 @@ static const struct snd_soc_dapm_widget mc13783_dapm_widgets[] = { SND_SOC_DAPM_PGA("PGA Left Input", SND_SOC_NOPM, 0, 0, NULL, 0), SND_SOC_DAPM_PGA("PGA Right Input", SND_SOC_NOPM, 0, 0, NULL, 0), - SND_SOC_DAPM_ADC("ADC", "Capture", 40, 11, 0), - SND_SOC_DAPM_SUPPLY("ADC_Reset", 40, 15, 0, NULL, 0), + SND_SOC_DAPM_ADC("ADC", "Capture", MC13783_AUDIO_CODEC, 11, 0), + SND_SOC_DAPM_SUPPLY("ADC_Reset", MC13783_AUDIO_CODEC, 15, 0, NULL, 0), /* Output */ - SND_SOC_DAPM_SUPPLY("DAC_E", 41, 11, 0, NULL, 0), - SND_SOC_DAPM_SUPPLY("DAC_Reset", 41, 15, 0, NULL, 0), + SND_SOC_DAPM_SUPPLY("DAC_E", MC13783_AUDIO_DAC, 11, 0, NULL, 0), + SND_SOC_DAPM_SUPPLY("DAC_Reset", MC13783_AUDIO_DAC, 15, 0, NULL, 0), SND_SOC_DAPM_OUTPUT("RXOUTL"), SND_SOC_DAPM_OUTPUT("RXOUTR"), SND_SOC_DAPM_OUTPUT("HSL"), @@ -516,14 +516,18 @@ static const struct snd_soc_dapm_widget mc13783_dapm_widgets[] = { SND_SOC_DAPM_OUTPUT("LSP"), SND_SOC_DAPM_OUTPUT("SP"), - SND_SOC_DAPM_SWITCH("Speaker Amp", 36, 3, 0, &samp_ctl), + SND_SOC_DAPM_SWITCH("Speaker Amp", MC13783_AUDIO_RX0, 3, 0, &samp_ctl), SND_SOC_DAPM_SWITCH("Loudspeaker Amp", SND_SOC_NOPM, 0, 0, &lamp_ctl), - SND_SOC_DAPM_SWITCH("Headset Amp Left", 36, 10, 0, &hlamp_ctl), - SND_SOC_DAPM_SWITCH("Headset Amp Right", 36, 9, 0, &hramp_ctl), - SND_SOC_DAPM_SWITCH("Line out Amp Left", 36, 16, 0, &llamp_ctl), - SND_SOC_DAPM_SWITCH("Line out Amp Right", 36, 15, 0, &lramp_ctl), - SND_SOC_DAPM_DAC("DAC", "Playback", 36, 22, 0), - SND_SOC_DAPM_PGA("DAC PGA", 37, 5, 0, NULL, 0), + SND_SOC_DAPM_SWITCH("Headset Amp Left", MC13783_AUDIO_RX0, 10, 0, + &hlamp_ctl), + SND_SOC_DAPM_SWITCH("Headset Amp Right", MC13783_AUDIO_RX0, 9, 0, + &hramp_ctl), + SND_SOC_DAPM_SWITCH("Line out Amp Left", MC13783_AUDIO_RX0, 16, 0, + &llamp_ctl), + SND_SOC_DAPM_SWITCH("Line out Amp Right", MC13783_AUDIO_RX0, 15, 0, + &lramp_ctl), + SND_SOC_DAPM_DAC("DAC", "Playback", MC13783_AUDIO_RX0, 22, 0), + SND_SOC_DAPM_PGA("DAC PGA", MC13783_AUDIO_RX1, 5, 0, NULL, 0), }; static struct snd_soc_dapm_route mc13783_routes[] = { -- 1.7.7.4

2 1

Re: [alsa-devel] snd-usb: "delay: estimated 0, actual 352"
by Takashi Iwai 06 Sep '12

06 Sep '12

At Thu, 6 Sep 2012 09:17:57 +0200, Markus Trippelsdorf wrote: > > On 2012.09.06 at 09:08 +0200, Daniel Mack wrote: > > On 06.09.2012 08:53, Markus Trippelsdorf wrote: > > > On 2012.09.06 at 08:48 +0200, Takashi Iwai wrote: > > >> At Thu, 06 Sep 2012 08:33:30 +0200, > > >> Daniel Mack wrote: > > >>> > > >>> On 06.09.2012 08:02, Markus Trippelsdorf wrote: > > >>>> On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote: > > >>>>> ---------------------------------------------------------------- > > >>>>> Sound fixes for 3.6-rc5 > > >>>>> > > >>>>> There are nothing scaring, contains only small fixes for HD-audio and > > >>>>> USB-audio: > > >>>>> - EPSS regression fix and GPIO fix for HD-audio IDT codecs > > >>>>> - A series of USB-audio regression fixes that are found since 3.5 kernel > > >>>>> > > >>>>> ---------------------------------------------------------------- > > >>>>> Daniel Mack (4): > > >>>>> ALSA: snd-usb: Fix URB cancellation at stream start > > >>>>> ALSA: snd-usb: restore delay information > > >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > >>>> The commit fbcfbf5f above causes the following lines to be printed > > >>>> whenever I start a new song: > > >>> > > >>> Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this > > >>> patch (fbcfbf5f) brings back now. > > >>> > > >>>> delay: estimated 0, actual 352 > > >>>> delay: estimated 353, actual 705 > > >>>> > > >>>> (44.1 * 8 = 352.8) > > >>>> > > >>>> This happens with an USB-DAC that identifies itself as "C-Media USB > > >>>> Headphone Set". > > >>> > > >>> And you didn't you see these lines with 3.4? > > >> > > >> Maybe the difference of start condition? > > >> > > >> Markus, does the patch below fix anything? > > > > > > Unfortunately no. > > > However reverting the following fixes the problem: > > > > > > commit 245baf983cc39524cce39c24d01b276e6e653c9e > > > Author: Daniel Mack <zonque(a)gmail.com> > > > Date: Thu Aug 30 18:52:30 2012 +0200 > > > > > > ALSA: snd-usb: fix calls to next_packet_size > > > > > > > No, this one certainly fixes a problem and does the right thing by > > restoring the original code. > > > > If you wouldn't state that you didn't see the same effect with 3.4(!), > > before the refactoring done in 3.5, I would believe the device is simply > > slightly off in its feedback rate and the tighter delay code complains > > about it while compensating, just as it did before. > > > > Are there any more than these two lines? And is audio working at all? Is > > it distorted in any way? > > There are only these two lines (printed whenever sound starts). Audio is > working just fine with no distortions. > > I did see similar lines before when the system load was very high > (happend during "make check" when building glibc). > > Here is what Pierre-Louis wrote in November 2011: > > Â»This was supposed to be an informational message, I thought it was only > enabled for debug. Regular users don't really need to know.Â« I guess the problem is that the new endpoint scheme doesn't count the last_delay update unless the stream is triggered. In the old code, retire_playback_urb is always called even before the trigger(START) is set. And, there retire_playback_urb() does nothing but updating the delay information. In the new code, retire_playback_urb is set only at snd_usb_substream_playback_trigger(). Thus at the very first shot, the delay account got confused. Takashi

2 2

[alsa-devel] Multiple speaker jacks (on an IDT codec)
by David Henningsson 06 Sep '12

06 Sep '12

Hi, I'm having a problem with a machine where the parser creates indexed speaker controls. For reference, codecs/idt92hd206-ecs-gf7100pvt shows the same problem. I could use some input on how to fix it in the best way. My first thought was that "[Jack] Speaker" is stupid in itself, and could be fixed like this: diff --git a/sound/pci/hda/hda_auto_parser.c b/sound/pci/hda/hda_auto_parser.c index 4f7d2df..8e32ee5 100644 --- a/sound/pci/hda/hda_auto_parser.c +++ b/sound/pci/hda/hda_auto_parser.c @@ -171,6 +171,10 @@ int snd_hda_parse_pin_defcfg(struct hda_codec *codec, if (conn == AC_JACK_PORT_FIXED) dev = AC_JACK_SPEAKER; } + else if (dev == AC_JACK_SPEAKER) { + if (conn == AC_JACK_PORT_COMPLEX) + dev = AC_JACK_LINE_OUT; + } switch (dev) { case AC_JACK_LINE_OUT: ...but changing generic code is always a bit scary and regression prone (even though I could not think of a good counterexample where that would happen), so not sure if that's the best idea. Next attempt is to modify the control creating function for IDT: diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index 9db3056..c16d0f8 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -3226,9 +3226,12 @@ static int create_multi_out_ctls(struct hda_codec *codec, int num_outs, idx = i; break; case AUTO_PIN_SPEAKER_OUT: - name = "Speaker"; - idx = i; - break; + if (num_outs <= 1) { + name = "Speaker"; + idx = i; + break; + } + /* Fall through in case of multi speaker outs */ default: name = chname[i]; idx = 0; ...since the current behaviour is inconsistent anyway - you get indices for 1 and 3, but "Center"/"LFE" for what should otherwise have been index 2. Another way would to just write a pin fix to turn these speakers into line outs, which is what they really are anyway. What do you think? -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic

2 3