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

[alsa-devel] [PATCH] HDA-Intel: Fix wrong CTLINDEX entries for HBR Passthrough
by Wang Xingchao 10 Sep '12

10 Sep '12

>From Anssi Hannula: "The CTLINDEX=x values in /usr/share/alsa/cards/HDA-Intel.conf are off when you have S/PDIF output in the same card as HDMI, which is often the case on Intel. The workaround is to bump all the CTLINDEX=x values one step up in the HDA-Intel.pcm.hdmi.foo entries, i.e. CTLINDEX=0 => CTLINDEX=1 CTLINDEX=1 => CTLINDEX=2 etc, in the /usr/share/alsa/cards/HDA-Intel.conf." Signed-off-by: Wang Xingchao <xingchao.wang(a)intel.com> --- src/conf/cards/HDA-Intel.conf | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/conf/cards/HDA-Intel.conf b/src/conf/cards/HDA-Intel.conf index d4f2667..7d6de8f 100644 --- a/src/conf/cards/HDA-Intel.conf +++ b/src/conf/cards/HDA-Intel.conf @@ -211,7 +211,7 @@ HDA-Intel.pcm.hdmi.0 { "cards.HDA-Intel.pcm.hdmi.common:" "CARD=" $CARD "," "DEVICE=3," - "CTLINDEX=0," + "CTLINDEX=1," "AES0=" $AES0 "," "AES1=" $AES1 "," "AES2=" $AES2 "," @@ -234,7 +234,7 @@ HDA-Intel.pcm.hdmi.1 { "cards.HDA-Intel.pcm.hdmi.common:" "CARD=" $CARD "," "DEVICE=7," - "CTLINDEX=1," + "CTLINDEX=2," "AES0=" $AES0 "," "AES1=" $AES1 "," "AES2=" $AES2 "," @@ -257,7 +257,7 @@ HDA-Intel.pcm.hdmi.2 { "cards.HDA-Intel.pcm.hdmi.common:" "CARD=" $CARD "," "DEVICE=8," - "CTLINDEX=2," + "CTLINDEX=3," "AES0=" $AES0 "," "AES1=" $AES1 "," "AES2=" $AES2 "," @@ -280,7 +280,7 @@ HDA-Intel.pcm.hdmi.3 { "cards.HDA-Intel.pcm.hdmi.common:" "CARD=" $CARD "," "DEVICE=9," - "CTLINDEX=3," + "CTLINDEX=4," "AES0=" $AES0 "," "AES1=" $AES1 "," "AES2=" $AES2 "," -- 1.7.9.5

3 2

[alsa-devel] ALSA release cycle
by David Henningsson 08 Sep '12

08 Sep '12

Hi, At Plumber's we discussed the ALSA release cycle. Our releases recently have been irregular, and the reasoning behind why a release was done at that time, has not been very obvious. IIRC, we kind of leaned towards releasing every six months. I don't remember if there was any consensus about whether to try to align this cycle to something else (e g Gnome, KDE, Fedora, Ubuntu, etc), or not. We also said that we should discuss this on the mailinglist as the ALSA release manager (Jaroslav Kysela) was not present during Plumber's. So this effectively is a mail to kick off that discussion. Any opinions? Also, as a side note (or perhaps proof of the problem!), it seems ALSA 1.0.26 was just released without even a notification on this mailinglist...? -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic

4 5

Re: [alsa-devel] How to define card specific pcm devices?
by Liam Girdwood 08 Sep '12

08 Sep '12

On Wed, 2012-09-05 at 12:24 +0100, Girdwood, Liam wrote: > On 5 September 2012 06:41, Tanu Kaskinen <tanuk(a)iki.fi> wrote: > On Wed, 2012-08-29 at 09:44 +0800, Raymond Yau wrote: > > strictly speaking your mic is not a true stereo mic and the > channel > > map is [left, null] instead of the normal map [left,right] > of line-in > > or stereo mic > > > I think specifying the channel map like you suggest would be a > good > solution. Supporting it would require some extra work in > PulseAudio, but > I think PulseAudio will anyway have to be extended to query > the channel > map information from UCM. > > Now the problem is that UCM doesn't provide the channel map > information > at all. Should the channel map be provided in the device > "Value" > section? Like this: > > SectionDevice."my-mono-mic" { > > ... > > Value { > # Does this value become redundant if > # the "CaptureChannelMap" value is added? > CaptureChannels "2" > I would expect to see a "1" here unless we cannot open the pcm in mono mode. > # Channel names match the constants in > # Takashi's proposed channel map API > CaptureChannelMap "FL, NA" > } > > } This seems fine and should be a simple patch for UCM too. Pulsaudio could use the map information/preference from UCM (like above) to configure the driver using Takashi's new channel map API. > > Opinions? (Liam added to CC - am I right in that you should be > CC'd in > all UCM related discussions?) Yes, please and Mark too (now on CC). Thanks Liam >

3 3

[alsa-devel] sound/soc/soc-dapm.c:1023:4: error: implicit declaration of function 'regulator_allow_bypass'
by Fengguang Wu 08 Sep '12

08 Sep '12

[add the missing subject line..] On Sat, Sep 08, 2012 at 09:44:50AM +0800, Fengguang Wu wrote: > Hi Mark, > > FYI, kernel build failed on > > tree: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next > head: e8bb382aa74747f23e2903c15e48e9f06de5c60a > commit: 9ad4ba77112a3700129cdb142796a54680baa266 [100/103] ASoC: dapm: Allow regulators to bypass as well as disable when idle > config: x86_64-allmodconfig (attached as .config) > > All related error/warning messages: > > sound/soc/soc-dapm.c: In function 'dapm_regulator_event': > sound/soc/soc-dapm.c:1023:4: error: implicit declaration of function 'regulator_allow_bypass' [-Werror=implicit-function-declaration] > cc1: some warnings being treated as errors > > vim +1023 sound/soc/soc-dapm.c > 1018 { > 1019 int ret; > 1020 > 1021 if (SND_SOC_DAPM_EVENT_ON(event)) { > 1022 if (w->invert & SND_SOC_DAPM_REGULATOR_BYPASS) { > > 1023 ret = regulator_allow_bypass(w->regulator, true); > 1024 if (ret != 0) > 1025 dev_warn(w->dapm->dev, > 1026 "Failed to bypass %s: %d\n", > 1027 w->name, ret); > 1028 } > > --- > 0-DAY kernel build testing backend Open Source Technology Centre > Fengguang Wu <wfg(a)linux.intel.com> Intel Corporation

1 0

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

07 Sep '12

Hi Daniel, Thanks for the quick reply. I am able to set the clock on my Mac, though I do need to do further tests and make sure that the sync is actually reliable there. The setting is available from the built-in, standard OS X audio setup application "Audio MIDI Setup". There should be a S/PDIF clock signal going to the digital inputs on the device. Some of the other controls such as per-channel mute also appear to work. I've also attached the lsusb output (attachment stripped for the mailing list). There are some other details that may be relevant, but I didn't want to make my initial post too long/confusing because these extra details may end up just being a red herring: Each mixer element name (as seen in amixer) is prefixed with "AudioBox 1818 VSL Clock Selector" even if it is not a clock selector. I am confident though that the control I've been playing with is the clock selector because it lists the different clock types as options. I also see this when I plug the device in or load the ALSA driver: ALSA sound/usb/mixer.c:342 cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0xa00, type = 4 ALSA sound/usb/mixer.c:846 10:0: cannot get min/max values for control 2 (id 10) ALSA sound/usb/mixer.c:342 cannot get ctl value: req = 0x83, wValue = 0x200, wIndex = 0xa00, type = 4 ALSA sound/usb/mixer.c:846 10:0: cannot get min/max values for control 2 (id 10) ALSA sound/usb/mixer.c:342 cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0xb00, type = 4 ALSA sound/usb/mixer.c:846 11:0: cannot get min/max values for control 2 (id 11) ALSA sound/usb/mixer.c:342 cannot get ctl value: req = 0x83, wValue = 0x200, wIndex = 0xb00, type = 4 ALSA sound/usb/mixer.c:846 11:0: cannot get min/max values for control 2 (id 11) Amixer reports the control at numid=2 to be a boolean, but because of the naming bug I can't see what the control really is. I'm assuming this isn't relevant, but I'm including it here anyway. Louis > On 06.09.2012 22:20, louis(a)museresearch.com wrote: >> 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? > > Hmm. A clock selector is handled like any other control entity on the hardware. Some thoughts: > > - Are you able to control other settings like the volume? > > - It's fairly common for devices to not accept a new clock source setting if they can't lock to the external source within some time. Did you connect anything to the digital inputs? > > - Are you able to control that setting with the native Mac OS X driver? (IOW, without installing a 3rd-party driver) > > Also, please send the output of "lsusb -v" for that device. > > > Daniel >

1 0

[alsa-devel] [PATCH 1/4] ASoC: dapm: Add flags to regulator supplies
by Mark Brown 07 Sep '12

07 Sep '12

This will be used to enable additional control of the regulators. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- include/sound/soc-dapm.h | 5 +++-- sound/soc/codecs/ab8500-codec.c | 8 ++++---- sound/soc/codecs/wm2200.c | 4 ++-- sound/soc/codecs/wm5100.c | 6 +++--- sound/soc/codecs/wm5102.c | 12 ++++++------ sound/soc/codecs/wm5110.c | 12 ++++++------ sound/soc/codecs/wm8996.c | 2 +- 7 files changed, 25 insertions(+), 24 deletions(-) diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h index 07e2510..c96bf5a 100644 --- a/include/sound/soc-dapm.h +++ b/include/sound/soc-dapm.h @@ -244,10 +244,11 @@ struct device; { .id = snd_soc_dapm_supply, .name = wname, .reg = wreg, \ .shift = wshift, .invert = winvert, .event = wevent, \ .event_flags = wflags} -#define SND_SOC_DAPM_REGULATOR_SUPPLY(wname, wdelay) \ +#define SND_SOC_DAPM_REGULATOR_SUPPLY(wname, wdelay, wflags) \ { .id = snd_soc_dapm_regulator_supply, .name = wname, \ .reg = SND_SOC_NOPM, .shift = wdelay, .event = dapm_regulator_event, \ - .event_flags = SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD } + .event_flags = SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD, \ + .invert = wflags} /* dapm kcontrol types */ diff --git a/sound/soc/codecs/ab8500-codec.c b/sound/soc/codecs/ab8500-codec.c index b783650..3f46bff 100644 --- a/sound/soc/codecs/ab8500-codec.c +++ b/sound/soc/codecs/ab8500-codec.c @@ -390,10 +390,10 @@ static const struct snd_soc_dapm_widget ab8500_dapm_widgets[] = { SND_SOC_DAPM_CLOCK_SUPPLY("audioclk"), /* Regulators */ - SND_SOC_DAPM_REGULATOR_SUPPLY("V-AUD", 0), - SND_SOC_DAPM_REGULATOR_SUPPLY("V-AMIC1", 0), - SND_SOC_DAPM_REGULATOR_SUPPLY("V-AMIC2", 0), - SND_SOC_DAPM_REGULATOR_SUPPLY("V-DMIC", 0), + SND_SOC_DAPM_REGULATOR_SUPPLY("V-AUD", 0, 0), + SND_SOC_DAPM_REGULATOR_SUPPLY("V-AMIC1", 0, 0), + SND_SOC_DAPM_REGULATOR_SUPPLY("V-AMIC2", 0, 0), + SND_SOC_DAPM_REGULATOR_SUPPLY("V-DMIC", 0, 0), /* Power */ SND_SOC_DAPM_SUPPLY("Audio Power", diff --git a/sound/soc/codecs/wm2200.c b/sound/soc/codecs/wm2200.c index 71debd0..efa93dbb 100644 --- a/sound/soc/codecs/wm2200.c +++ b/sound/soc/codecs/wm2200.c @@ -1117,8 +1117,8 @@ SND_SOC_DAPM_SUPPLY("MICBIAS1", WM2200_MIC_BIAS_CTRL_1, WM2200_MICB1_ENA_SHIFT, 0, NULL, 0), SND_SOC_DAPM_SUPPLY("MICBIAS2", WM2200_MIC_BIAS_CTRL_2, WM2200_MICB2_ENA_SHIFT, 0, NULL, 0), -SND_SOC_DAPM_REGULATOR_SUPPLY("CPVDD", 20), -SND_SOC_DAPM_REGULATOR_SUPPLY("AVDD", 20), +SND_SOC_DAPM_REGULATOR_SUPPLY("CPVDD", 20, 0), +SND_SOC_DAPM_REGULATOR_SUPPLY("AVDD", 20, 0), SND_SOC_DAPM_INPUT("IN1L"), SND_SOC_DAPM_INPUT("IN1R"), diff --git a/sound/soc/codecs/wm5100.c b/sound/soc/codecs/wm5100.c index 33aa363..f4b327e 100644 --- a/sound/soc/codecs/wm5100.c +++ b/sound/soc/codecs/wm5100.c @@ -893,9 +893,9 @@ SND_SOC_DAPM_SUPPLY("SYSCLK", WM5100_CLOCKING_3, WM5100_SYSCLK_ENA_SHIFT, 0, SND_SOC_DAPM_SUPPLY("ASYNCCLK", WM5100_CLOCKING_6, WM5100_ASYNC_CLK_ENA_SHIFT, 0, NULL, 0), -SND_SOC_DAPM_REGULATOR_SUPPLY("CPVDD", 20), -SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD2", 0), -SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD3", 0), +SND_SOC_DAPM_REGULATOR_SUPPLY("CPVDD", 20, 0), +SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD2", 0, 0), +SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD3", 0, 0), SND_SOC_DAPM_SUPPLY("CP1", WM5100_HP_CHARGE_PUMP_1, WM5100_CP1_ENA_SHIFT, 0, NULL, 0), diff --git a/sound/soc/codecs/wm5102.c b/sound/soc/codecs/wm5102.c index 97223e4..3f5da8c 100644 --- a/sound/soc/codecs/wm5102.c +++ b/sound/soc/codecs/wm5102.c @@ -312,12 +312,12 @@ SND_SOC_DAPM_SUPPLY("OPCLK", ARIZONA_OUTPUT_SYSTEM_CLOCK, SND_SOC_DAPM_SUPPLY("ASYNCOPCLK", ARIZONA_OUTPUT_ASYNC_CLOCK, ARIZONA_OPCLK_ASYNC_ENA_SHIFT, 0, NULL, 0), -SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD2", 0), -SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD3", 0), -SND_SOC_DAPM_REGULATOR_SUPPLY("CPVDD", 20), -SND_SOC_DAPM_REGULATOR_SUPPLY("MICVDD", 0), -SND_SOC_DAPM_REGULATOR_SUPPLY("SPKVDDL", 0), -SND_SOC_DAPM_REGULATOR_SUPPLY("SPKVDDR", 0), +SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD2", 0, 0), +SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD3", 0, 0), +SND_SOC_DAPM_REGULATOR_SUPPLY("CPVDD", 20, 0), +SND_SOC_DAPM_REGULATOR_SUPPLY("MICVDD", 0, 0), +SND_SOC_DAPM_REGULATOR_SUPPLY("SPKVDDL", 0, 0), +SND_SOC_DAPM_REGULATOR_SUPPLY("SPKVDDR", 0, 0), SND_SOC_DAPM_SIGGEN("TONE"), SND_SOC_DAPM_SIGGEN("NOISE"), diff --git a/sound/soc/codecs/wm5110.c b/sound/soc/codecs/wm5110.c index 94cd4f1..e7f8d17 100644 --- a/sound/soc/codecs/wm5110.c +++ b/sound/soc/codecs/wm5110.c @@ -359,12 +359,12 @@ SND_SOC_DAPM_SUPPLY("OPCLK", ARIZONA_OUTPUT_SYSTEM_CLOCK, SND_SOC_DAPM_SUPPLY("ASYNCOPCLK", ARIZONA_OUTPUT_ASYNC_CLOCK, ARIZONA_OPCLK_ASYNC_ENA_SHIFT, 0, NULL, 0), -SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD2", 0), -SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD3", 0), -SND_SOC_DAPM_REGULATOR_SUPPLY("CPVDD", 20), -SND_SOC_DAPM_REGULATOR_SUPPLY("MICVDD", 0), -SND_SOC_DAPM_REGULATOR_SUPPLY("SPKVDDL", 0), -SND_SOC_DAPM_REGULATOR_SUPPLY("SPKVDDR", 0), +SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD2", 0, 0), +SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD3", 0, 0), +SND_SOC_DAPM_REGULATOR_SUPPLY("CPVDD", 20, 0), +SND_SOC_DAPM_REGULATOR_SUPPLY("MICVDD", 0, 0), +SND_SOC_DAPM_REGULATOR_SUPPLY("SPKVDDL", 0, 0), +SND_SOC_DAPM_REGULATOR_SUPPLY("SPKVDDR", 0, 0), SND_SOC_DAPM_SIGGEN("TONE"), SND_SOC_DAPM_SIGGEN("NOISE"), diff --git a/sound/soc/codecs/wm8996.c b/sound/soc/codecs/wm8996.c index 00f183d..6dcb02c 100644 --- a/sound/soc/codecs/wm8996.c +++ b/sound/soc/codecs/wm8996.c @@ -931,7 +931,7 @@ SND_SOC_DAPM_INPUT("IN2RP"), SND_SOC_DAPM_INPUT("DMIC1DAT"), SND_SOC_DAPM_INPUT("DMIC2DAT"), -SND_SOC_DAPM_REGULATOR_SUPPLY("CPVDD", 20), +SND_SOC_DAPM_REGULATOR_SUPPLY("CPVDD", 20, 0), SND_SOC_DAPM_SUPPLY_S("SYSCLK", 1, WM8996_AIF_CLOCKING_1, 0, 0, NULL, 0), SND_SOC_DAPM_SUPPLY_S("SYSDSPCLK", 2, WM8996_CLOCKING_1, 1, 0, NULL, 0), SND_SOC_DAPM_SUPPLY_S("AIFCLK", 2, WM8996_CLOCKING_1, 2, 0, NULL, 0), -- 1.7.10.4

2 4

[alsa-devel] [PATCH v3 00/14] MFD/ASoC/Input: twl4030-audio submodule DT support
by Peter Ujfalusi 07 Sep '12

07 Sep '12

Hello, Generated on top of: git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/omap Changed since v2: - Added commit message to patch 2 (as Tero requested it) - Fixed patch 6 (dt: Add empty...) since the previous patch caused x86_64 build to fail due to missing struct before device_node. Changes since v1: - Get the MCLK frequencey from twl-core driver (via new API) - hs_extmute_disable_level parameter has been removed - empty of_find_node_by_name() in of.h for !CONFIG_OF builds Mark: the extmute GPIO handling (when it is used) remained in the codec driver for now. I can think more on how to add support for this type of mute control. If you can point me to other codec needing this it would help on designing something which is common enough for other users. As for now I have a separate series to add GPIO controlled output amps (hp/spk). I will send that to review soon. Currently this piece of code does not work when booted with device tree since I have done it on n900 which has the GPIO numbers as defines. I need to revisit the aproach on how to do it in a dynamic way. Introl mail from v1: The following series adds DT support for the twl4030 audio submodule which provides audio codec and vibra functionality. The MFD core driver is probed via DT, it will create the needed child devices based on the provided information in the DT blob. Child drivers (vibra, ASoC codec) will parse the core's node if needed to get the needed parameters for their configuration. In the ASoC codec driver the hs_extmute callback (which was used to toggle a GPIO line) has been removed. The codec driver will receive the GPIO number (if it is needed on the platform). If the series is OK (and no objections from the maintainers), it would be good if this can go via audio. Changed files are well contained within the twl4030-audio stack so I do not expect merge issues later. The series has been tested on BeagleBoard (with the McBSP DT series, and with the upcoming DT audio support for BeagleBoard). Regards, Peter --- Peter Ujfalusi (14): MFD: twl4030-audio: Clean up MODULE_* and platform_driver part MFD: twl4030-audio: Convert to use devm_kzalloc MFD: twl4030-audio: Rearange and clean-up the probe function MFD: twl-core: Add API to query the HFCLK rate MFD: twl4030-audio: Get audio MCLK via twl-core API instead of pdata dt: Add empty of_find_node_by_name() function MFD: twl4030-audio: Add DT support Input: twl4030-vibra: Support for DT booted kernel ASoC: twl4030: Move hs_extmute GPIO handling to driver ARM: OMAP/ASoC: Zoom2: Let the codec to handle the hs_extmute GPIO ASoC/MFD: twl4030: Remove set_hs_extmute callback from platform data ASoC: twl4030: Convert to use devm_kzalloc ASoC: twl4030: Add pointer to pdata within the private data ASoC: twl4030: Support for DT booted kernel .../devicetree/bindings/mfd/twl4030-audio.txt | 46 +++++++++ arch/arm/mach-omap2/board-zoom-peripherals.c | 9 +- arch/arm/mach-omap2/include/mach/board-zoom.h | 2 - drivers/input/misc/twl4030-vibra.c | 20 +++- drivers/mfd/twl-core.c | 32 ++++++ drivers/mfd/twl4030-audio.c | 107 ++++++++++++++------- include/linux/i2c/twl.h | 3 +- include/linux/of.h | 6 ++ sound/soc/codecs/twl4030.c | 103 ++++++++++++++++---- sound/soc/omap/zoom2.c | 4 - 10 files changed, 261 insertions(+), 71 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/twl4030-audio.txt -- 1.7.12

3 17

[alsa-devel] ALSA package release v1.0.26 (user space)
by Jaroslav Kysela 07 Sep '12

07 Sep '12

Hello all, I would like to notify you, that ALSA packages version 1.0.26 are available for download: ftp://ftp.alsa-project.org/pub/lib/alsa-lib-1.0.26.tar.bz2 ftp://ftp.alsa-project.org/pub/utils/alsa-utils-1.0.26.tar.bz2 ftp://ftp.alsa-project.org/pub/tools/alsa-tools-1.0.26.1.tar.bz2 ftp://ftp.alsa-project.org/pub/plugins/alsa-plugins-1.0.26.tar.bz2 ftp://ftp.alsa-project.org/pub/pyalsa/pyalsa-1.0.26.tar.bz2 The alsa-firmware and alsa-oss packages have no changes and they were not released this time. The changelog is available at this URL: http://www.alsa-project.org/main/index.php/Changes_v1.0.25_v1.0.26 The alsa-driver package will be released in next weeks once the driver repository with the build code and the mirrored kernel code will be reorganized to be more "GIT pull" friendly for those using the whole kernel tree as the development platform. Jaroslav -- Jaroslav Kysela <perex(a)perex.cz> Linux Kernel Sound Maintainer ALSA Project; Red Hat, Inc.

3 4

[alsa-devel] [alsa-jack-plugin] Feedback to modification proposal
by Merx, Thomas 07 Sep '12

07 Sep '12

Hello all, I would like to get some feedback here from you experts on the alsa-jack-plugin. In my project there is a jack-plugin that provides several jack input ports were different streams from different source applications shall be connectable. The source applications would provide the audio samples to jack via the alsa-jack-plugin. On top of that there is a control layer that has to connect the jack output ports of the alsa-jack-plugin with the input ports of my jack-plugin. The API of the control layer simply uses an ID for the source and an ID for the sink to know which jack output ports have to be connected to which input ports. The challenge I'm now facing is that the full name of the jack ports registered by the alsa-jack-plugin are changing from startup to startup because they include the process id of the playback application. Considering the case that there could be two instances of the same application and each of them providing a playback stream via the alsa-jack-plugin, it is challenging for the control layer to choose the correct stream for connecting it to my jack-plugin. So my main problem is that I cannot associate the IDs used for the control layer with the jack port names automatically created by the alsa-jack-plugin. A possible solution to my problem could be to add an additional entry in the asound.conf section where the jack plugin is defined to provide a name which shall be chosen as a prefix for the full jack port name, instead of the default naming scheme currently chosen. To have it backward compatible it could be implemented in a way that if the entry in the asound.conf is missing the current naming scheme is chosen and only if the new entry is set it will be used for the name to be registered at the jack server. What do you think about that? Does it make sense to have that functionality? Best regards Thomas Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Peter Gleissner, Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0

[alsa-devel] [RFC PATCH 1/11] expose sound device topology information
by Clemens Ladisch 07 Sep '12

07 Sep '12

Hi, these are some tentative patches to allow sound drivers to provide routing information to userspace. (So far, snd-usb-audio has a partial implementation; I haven't yet had time for snd-hda-intel. I haven't even looked at ASoC.) The media controller API <linux/media.h> allows prividing routing information, but its implementation does not quite fit the sound drivers: * it allows reconfiguration of links, but not in a way that would be useful for ALSA selector controls; * it allows drivers to access the entity graph and pipelines, which is not needed; * it is rather heavyweight. Therefore, these patches create their own implementation of the media controller API. In this implementation, all entity and link information is completely static, and more space-efficient. For simplicity, the ioctls hook into the ALSA control device instead of creating a new /dev/media* device. The separate implementation does not allow sharing of one media controller device in the case of combined audio/video devices. However, separate drivers would already be a problem for HDMI outputs (GPU and sound); it appears we might need some mechanism to connect the topologies of multiple media devices. TLVs (for jack entities, and for associating controls with entities) are not yet defined. Example output for my simple UA-1A device (not all information is decoded correctly): $ media-ctl -p -d /dev/snd/controlC5 Opening media device /dev/snd/controlC5 Enumerating entities Found 4 entities Enumerating pads and links Media controller API version 0.0.0 Media device information ------------------------ driver snd-usb-audio model EDIROL UA-1A serial bus info usb-0000:00:12.2-4.3 hw revision 0x101 driver version 0.0.0 Device topology - entity 1: USB Audio (1 pad, 1 link) type Node subtype ALSA device node name /dev/tty (should be hw:5,0,0) pad0: Source -> "OT3":0 [ENABLED,IMMUTABLE] - entity 3: OT3 (1 pad, 1 link) type Unknown subtype Unknown (should be Jack) pad0: Sink <- "USB Audio":0 [ENABLED,IMMUTABLE] - entity 4: IT4 (1 pad, 1 link) type Unknown subtype Unknown pad0: Source -> "USB Audio":0 [ENABLED,IMMUTABLE] - entity 7: USB Audio (1 pad, 1 link) type Node subtype ALSA device node name /dev/tty pad0: Sink <- "IT4":0 [ENABLED,IMMUTABLE] include/linux/media.h | 9 include/sound/core.h | 13 + include/sound/media.h | 116 ++++++++++ include/sound/pcm.h | 6 sound/core/Kconfig | 7 sound/core/Makefile | 1 sound/core/init.c | 4 sound/core/media.c | 425 ++++++++++++++++++++++++++++++++++++++ sound/core/pcm.c | 46 ++++ sound/core/sound.c | 3 sound/pci/hda/hda_intel.c | 2 sound/usb/card.c | 2 sound/usb/mixer.c | 278 ++++++++++++++++++++++++ sound/usb/quirks.c | 4 sound/usb/stream.c | 16 - sound/usb/stream.h | 1 16 files changed, 925 insertions(+), 8 deletions(-) Regards, Clemens

3 16