October 2014 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH] sound: pci: pcxhr: convert timeval to ktime_t
by Aya Mahfouz 28 Oct '14

28 Oct '14

This patch is concerned with migrating the time variables in the pcxhr module found in the sound driver. The changes are concerend with the y2038 problem where timeval will overflow in the year 2038. ktime_t was used instead of timeval to get the wall time. The difference is displayed now in nanoseconds instead of microseconds. Signed-off-by: Aya Mahfouz <mahfouz.saif.elyazal(a)gmail.com> Reviewed-by: Arnd Bergmann <arnd(a)arndb.de> --- sound/pci/pcxhr/pcxhr.c | 10 ++++++---- sound/pci/pcxhr/pcxhr_core.c | 10 ++++++---- 2 files changed, 12 insertions(+), 8 deletions(-) diff --git a/sound/pci/pcxhr/pcxhr.c b/sound/pci/pcxhr/pcxhr.c index b854fc5..3f4607c 100644 --- a/sound/pci/pcxhr/pcxhr.c +++ b/sound/pci/pcxhr/pcxhr.c @@ -711,8 +711,9 @@ static void pcxhr_start_linked_stream(struct pcxhr_mgr *mgr) int playback_mask = 0; #ifdef CONFIG_SND_DEBUG_VERBOSE - struct timeval my_tv1, my_tv2; - do_gettimeofday(&my_tv1); + ktime_t start, stop, diff; + + start = ktime_get(); #endif mutex_lock(&mgr->setup_mutex); @@ -823,9 +824,10 @@ static void pcxhr_start_linked_stream(struct pcxhr_mgr *mgr) mutex_unlock(&mgr->setup_mutex); #ifdef CONFIG_SND_DEBUG_VERBOSE - do_gettimeofday(&my_tv2); + stop = ktime_get(); + diff = ktime_sub(stop, start); dev_dbg(&mgr->pci->dev, "***TRIGGER START*** TIME = %ld (err = %x)\n", - (long)(my_tv2.tv_usec - my_tv1.tv_usec), err); + (long)(ktime_to_ns(diff)), err); #endif } diff --git a/sound/pci/pcxhr/pcxhr_core.c b/sound/pci/pcxhr/pcxhr_core.c index a584acb..be3c003 100644 --- a/sound/pci/pcxhr/pcxhr_core.c +++ b/sound/pci/pcxhr/pcxhr_core.c @@ -910,8 +910,9 @@ int pcxhr_set_pipe_state(struct pcxhr_mgr *mgr, int playback_mask, int audio_mask; #ifdef CONFIG_SND_DEBUG_VERBOSE - struct timeval my_tv1, my_tv2; - do_gettimeofday(&my_tv1); + ktime_t start, stop, diff; + + start = ktime_get(); #endif audio_mask = (playback_mask | (capture_mask << PCXHR_PIPE_STATE_CAPTURE_OFFSET)); @@ -960,9 +961,10 @@ int pcxhr_set_pipe_state(struct pcxhr_mgr *mgr, int playback_mask, return err; } #ifdef CONFIG_SND_DEBUG_VERBOSE - do_gettimeofday(&my_tv2); + stop = ktime_get(); + diff = ktime_sub(stop, start); dev_dbg(&mgr->pci->dev, "***SET PIPE STATE*** TIME = %ld (err = %x)\n", - (long)(my_tv2.tv_usec - my_tv1.tv_usec), err); + (long)(ktime_to_ns(diff)), err); #endif return 0; } -- 1.9.3

2 3

[alsa-devel] [PATCH] ALSA: pcm: Zero-clear reserved fields of PCM status ioctl in compat mode
by Takashi Iwai 28 Oct '14

28 Oct '14

In compat mode, we copy each field of snd_pcm_status struct but don't touch the reserved fields, and this leaves uninitialized values there. Meanwhile the native ioctl does zero-clear the whole structure, so we should follow the same rule in compat mode, too. Reported-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/core/pcm_compat.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/core/pcm_compat.c b/sound/core/pcm_compat.c index 102e8fd1d450..2d957ba63557 100644 --- a/sound/core/pcm_compat.c +++ b/sound/core/pcm_compat.c @@ -210,6 +210,8 @@ static int snd_pcm_status_user_compat(struct snd_pcm_substream *substream, if (err < 0) return err; + if (clear_user(src, sizeof(*src))) + return -EFAULT; if (put_user(status.state, &src->state) || compat_put_timespec(&status.trigger_tstamp, &src->trigger_tstamp) || compat_put_timespec(&status.tstamp, &src->tstamp) || -- 2.1.2

1 0

[alsa-devel] [PATCH] ASoC: es8328-i2c: Fix i2c_device_id name field in es8328_id
by Axel Lin 28 Oct '14

28 Oct '14

The convention for i2c_device_id name does not need to have company prefix. Signed-off-by: Axel Lin <axel.lin(a)ingics.com> --- sound/soc/codecs/es8328-i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/es8328-i2c.c b/sound/soc/codecs/es8328-i2c.c index aae410d..2d05b5d 100644 --- a/sound/soc/codecs/es8328-i2c.c +++ b/sound/soc/codecs/es8328-i2c.c @@ -19,7 +19,7 @@ #include "es8328.h" static const struct i2c_device_id es8328_id[] = { - { "everest,es8328", 0 }, + { "es8328", 0 }, { } }; MODULE_DEVICE_TABLE(i2c, es8328_id); -- 1.9.1

2 1

[alsa-devel] What are subdevices?
by dE 28 Oct '14

28 Oct '14

Hi! I tried this question in the alsa-users mailing list but it doesn't appear to be much active. So I ask here. I'm facing problems with my system, so decided to learn ALSA to see what's the problem. My first question -- what's a device and a sub device? A device seems like the output streams the sound card supports. Like HDMI, DP, analog etc... So what's a subdevice? Is this related to multichannel? Does it designate physical ports on the card? Thanks.

2 5

[alsa-devel] [PATCH V3 1/2] ARM: pxa: spitz: register spitz-audio device
by Dmitry Eremin-Solenikov 28 Oct '14

28 Oct '14

Register spitz-audio device to be used by ASoC driver to bind ASoC platform driver. Currently old 'soc-audio' approach is used, which needs to be replaced with proper device. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov(a)gmail.com> --- arch/arm/mach-pxa/spitz.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c index 840c3a4..962a7f3 100644 --- a/arch/arm/mach-pxa/spitz.c +++ b/arch/arm/mach-pxa/spitz.c @@ -924,6 +924,14 @@ static inline void spitz_i2c_init(void) {} #endif /****************************************************************************** + * Audio devices + ******************************************************************************/ +static inline void spitz_audio_init(void) +{ + platform_device_register_simple("spitz-audio", -1, NULL, 0); +} + +/****************************************************************************** * Machine init ******************************************************************************/ static void spitz_poweroff(void) @@ -970,6 +978,7 @@ static void __init spitz_init(void) spitz_nor_init(); spitz_nand_init(); spitz_i2c_init(); + spitz_audio_init(); } static void __init spitz_fixup(struct tag *tags, char **cmdline) -- 2.1.1

2 2

[alsa-devel] [PATCH] ASoC: Use generic control handlers for S8 control
by Lars-Peter Clausen 28 Oct '14

28 Oct '14

Commit f227b88f0fce ("ASoC: core: Add signed register volume control logic") added support for signed control to the generic volsw control handler. This makes it possible to use them for the S8 control as well, rather than having to use a custom control handler implementation. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- include/sound/soc.h | 19 +++++------- sound/soc/soc-core.c | 87 ---------------------------------------------------- 2 files changed, 8 insertions(+), 98 deletions(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index 7ba7130..ad47e96 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -36,6 +36,11 @@ {.reg = xreg, .rreg = xreg, .shift = shift_left, \ .rshift = shift_right, .max = xmax, .platform_max = xmax, \ .invert = xinvert, .autodisable = xautodisable}) +#define SOC_DOUBLE_S_VALUE(xreg, shift_left, shift_right, xmin, xmax, xsign_bit, xinvert, xautodisable) \ + ((unsigned long)&(struct soc_mixer_control) \ + {.reg = xreg, .rreg = xreg, .shift = shift_left, \ + .rshift = shift_right, .min = xmin, .max = xmax, .platform_max = xmax, \ + .sign_bit = xsign_bit, .invert = xinvert, .autodisable = xautodisable}) #define SOC_SINGLE_VALUE(xreg, xshift, xmax, xinvert, xautodisable) \ SOC_DOUBLE_VALUE(xreg, xshift, xshift, xmax, xinvert, xautodisable) #define SOC_SINGLE_VALUE_EXT(xreg, xmax, xinvert) \ @@ -171,11 +176,9 @@ .access = SNDRV_CTL_ELEM_ACCESS_TLV_READ | \ SNDRV_CTL_ELEM_ACCESS_READWRITE, \ .tlv.p = (tlv_array), \ - .info = snd_soc_info_volsw_s8, .get = snd_soc_get_volsw_s8, \ - .put = snd_soc_put_volsw_s8, \ - .private_value = (unsigned long)&(struct soc_mixer_control) \ - {.reg = xreg, .min = xmin, .max = xmax, \ - .platform_max = xmax} } + .info = snd_soc_info_volsw, .get = snd_soc_get_volsw,\ + .put = snd_soc_put_volsw, \ + .private_value = SOC_DOUBLE_S_VALUE(xreg, 0, 8, xmin, xmax, 7, 0, 0) } #define SOC_ENUM_DOUBLE(xreg, xshift_l, xshift_r, xitems, xtexts) \ { .reg = xreg, .shift_l = xshift_l, .shift_r = xshift_r, \ .items = xitems, .texts = xtexts, \ @@ -545,12 +548,6 @@ int snd_soc_get_volsw_sx(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol); int snd_soc_put_volsw_sx(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol); -int snd_soc_info_volsw_s8(struct snd_kcontrol *kcontrol, - struct snd_ctl_elem_info *uinfo); -int snd_soc_get_volsw_s8(struct snd_kcontrol *kcontrol, - struct snd_ctl_elem_value *ucontrol); -int snd_soc_put_volsw_s8(struct snd_kcontrol *kcontrol, - struct snd_ctl_elem_value *ucontrol); int snd_soc_info_volsw_range(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_info *uinfo); int snd_soc_put_volsw_range(struct snd_kcontrol *kcontrol, diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 96ecdc3..47c378a 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -2721,93 +2721,6 @@ int snd_soc_put_volsw_sx(struct snd_kcontrol *kcontrol, EXPORT_SYMBOL_GPL(snd_soc_put_volsw_sx); /** - * snd_soc_info_volsw_s8 - signed mixer info callback - * @kcontrol: mixer control - * @uinfo: control element information - * - * Callback to provide information about a signed mixer control. - * - * Returns 0 for success. - */ -int snd_soc_info_volsw_s8(struct snd_kcontrol *kcontrol, - struct snd_ctl_elem_info *uinfo) -{ - struct soc_mixer_control *mc = - (struct soc_mixer_control *)kcontrol->private_value; - int platform_max; - int min = mc->min; - - if (!mc->platform_max) - mc->platform_max = mc->max; - platform_max = mc->platform_max; - - uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER; - uinfo->count = 2; - uinfo->value.integer.min = 0; - uinfo->value.integer.max = platform_max - min; - return 0; -} -EXPORT_SYMBOL_GPL(snd_soc_info_volsw_s8); - -/** - * snd_soc_get_volsw_s8 - signed mixer get callback - * @kcontrol: mixer control - * @ucontrol: control element information - * - * Callback to get the value of a signed mixer control. - * - * Returns 0 for success. - */ -int snd_soc_get_volsw_s8(struct snd_kcontrol *kcontrol, - struct snd_ctl_elem_value *ucontrol) -{ - struct soc_mixer_control *mc = - (struct soc_mixer_control *)kcontrol->private_value; - struct snd_soc_component *component = snd_kcontrol_chip(kcontrol); - unsigned int reg = mc->reg; - unsigned int val; - int min = mc->min; - int ret; - - ret = snd_soc_component_read(component, reg, &val); - if (ret) - return ret; - - ucontrol->value.integer.value[0] = - ((signed char)(val & 0xff))-min; - ucontrol->value.integer.value[1] = - ((signed char)((val >> 8) & 0xff))-min; - return 0; -} -EXPORT_SYMBOL_GPL(snd_soc_get_volsw_s8); - -/** - * snd_soc_put_volsw_sgn - signed mixer put callback - * @kcontrol: mixer control - * @ucontrol: control element information - * - * Callback to set the value of a signed mixer control. - * - * Returns 0 for success. - */ -int snd_soc_put_volsw_s8(struct snd_kcontrol *kcontrol, - struct snd_ctl_elem_value *ucontrol) -{ - struct soc_mixer_control *mc = - (struct soc_mixer_control *)kcontrol->private_value; - struct snd_soc_component *component = snd_kcontrol_chip(kcontrol); - unsigned int reg = mc->reg; - int min = mc->min; - unsigned int val; - - val = (ucontrol->value.integer.value[0]+min) & 0xff; - val |= ((ucontrol->value.integer.value[1]+min) & 0xff) << 8; - - return snd_soc_component_update_bits(component, reg, 0xffff, val); -} -EXPORT_SYMBOL_GPL(snd_soc_put_volsw_s8); - -/** * snd_soc_info_volsw_range - single mixer info callback with range. * @kcontrol: mixer control * @uinfo: control element information -- 1.8.0

2 1

[alsa-devel] [PATCH v2 0/8] ASoC: dapm: Cleanups and speed-ups
by Lars-Peter Clausen 28 Oct '14

28 Oct '14

Only as few minor cleanup changes since v1. No change in functionallity. Original cover letter from v1: This series contains a few cleanups and speed-ups for the DAPM implementation. It starts with removing some dead or outdated code and optimizing some lesser used operations. The first larger change introduced by this series is the categorization of widgets into sinks, sources, supplies and normal widgets. This is all the information the main DAPM algorithm needs and using these categories makes the code simpler and faster and hopefully easier to understand. The second major change is to use more aggressive caching on the connected input and output paths of a widget. It takes advantage of the fact that typically only as subsection of the DAPM graph changes per operation. This allows to drastically reduce the number of neighbor and path checks for some DAPM operations. The change is most effective when the system is idle and when changing the graph routing for a widget with multiple inputs. This e.g. happens a lot when switching the audio profile. It still has quite good improvements for other operations as well and typically leads to at least a 50% reduction of path and neighbor checks. Some before and after DAPM stats. All testing was done with the ADAU1761. Before is asoc/for-next, After~1 is asoc/for-next + this series except the last patch, After is asoc/for-next + this series. Changing a single control on a 5 input mixer while the system is idle: Power Path Neighbour Before: 2 25 32 After~1: 2 12 30 After: 2 1 2 Cumulative numbers for switching the audio profile which changes 7 controls while the system is idle: Power Path Neighbour Before: 16 141 188 After~1: 16 80 170 After: 16 7 23 Cumulative numbers for switching the audio profile which changes 7 controls while playback is active: Power Path Neighbour Before: 52 207 297 After~1: 51 123 273 After: 51 29 109 Starting (or stopping) the playback stream: Power Path Neighbour Before: 35 80 125 After~1: 34 34 117 After: 34 17 69 - Lars Lars-Peter Clausen (8): ASoC: dapm: Only mark paths dirty when the connection status changed ASoC: dapm: Do not add un-muxed paths to MUX control ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets ASoC: dapm: Introduce toplevel widget categories ASoC: dapm: Add a flag to mark paths connected to supply widgets ASoC: dapm: Mark endpoints instead of IO widgets dirty during suspend/resume ASoC: dapm: Add a few supply widget sanity checks ASoC: dapm: Use more aggressive caching include/sound/soc-dapm.h | 8 +- sound/soc/soc-core.c | 8 +- sound/soc/soc-dapm.c | 576 ++++++++++++++++++++++++++++------------------- 3 files changed, 353 insertions(+), 239 deletions(-) -- 1.8.0

2 9

[alsa-devel] [PATCH 00/12] ASoC: dapm: Cleanups and speed-ups
by Lars-Peter Clausen 28 Oct '14

28 Oct '14

Hi, This series contains a few cleanups and speed-ups for the DAPM implementation. It starts with removing some dead or outdated code and optimizing some lesser used operations. The first larger change introduced by this series is the categorization of widgets into sinks, sources, supplies and normal widgets. This is all the information the main DAPM algorithm needs and using these categories makes the code simpler and faster and hopefully easier to understand. The second major change is to use more aggressive caching on the connected input and output paths of a widget. It takes advantage of the fact that typically only as subsection of the DAPM graph changes per operation. This allows to drastically reduce the number of neighbor and path checks for some DAPM operations. The change is most effective when the system is idle and when changing the graph routing for a widget with multiple inputs. This e.g. happens a lot when switching the audio profile. It still has quite good improvements for other operations as well and typically leads to at least a 50% reduction of path and neighbor checks. Some before and after DAPM stats. All testing was done with the ADAU1761. Before is asoc/for-next, After~1 is asoc/for-next + this series except the last patch, After is asoc/for-next + this series. Changing a single control on a 5 input mixer while the system is idle: Power Path Neighbour Before: 2 25 32 After~1: 2 12 30 After: 2 1 2 Cumulative numbers for switching the audio profile which changes 7 controls while the system is idle: Power Path Neighbour Before: 16 141 188 After~1: 16 80 170 After: 16 7 23 Cumulative numbers for switching the audio profile which changes 7 controls while playback is active: Power Path Neighbour Before: 52 207 297 After~1: 51 123 273 After: 51 29 109 Starting (or stopping) the playback stream: Power Path Neighbour Before: 35 80 125 After~1: 34 34 117 After: 34 17 69 - Lars Lars-Peter Clausen (12): ASoC: dapm: Reduce number of checked paths in dapm_widget_in_card_paths() ASoC: dapm: Remove always true path source/sink checks ASoC: dapm: Only mark paths dirty when the connection status changed ASoC: dapm: Do not add un-muxed paths to MUX control ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets ASoC: dapm: Remove special DAI widget power check functions ASoC: dapm: Remove path 'walked' flag ASoC: dapm: Introduce toplevel widget categories ASoC: dapm: Add a flag to mark paths connected to supply widgets ASoC: dapm: Mark endpoints instead of IO widgets dirty during suspend/resume ASoC: dapm: Add a few supply widget sanity checks ASoC: dapm: Use more aggressive caching include/sound/soc-dapm.h | 9 +- sound/soc/soc-core.c | 8 +- sound/soc/soc-dapm.c | 755 +++++++++++++++++++++++++---------------------- 3 files changed, 409 insertions(+), 363 deletions(-) -- 1.8.0

2 24

[alsa-devel] 2014 ALSA micro-conference meeting notes - 10/14 Dussedorf
by Patrick Lai 27 Oct '14

27 Oct '14

Attendees: Takashi Iwai, Mark Brown, Vinod Koul, Patrick Lai, Lars-Peter Clausen, Eric Laurent, David Henningsson, Tanu Kaskinen, Arun Raghavan, Paul Handrigan, Daniel Mack, Dylan Reid, Charles Keepax, Nariman Poushin, Peter Meerwald, Alexander Patrakov, Hui Wang, Tim Cussins, Nick Stoughton Topic: ASoC componentization Motivation - hardware is becoming more complex as CPU and CODEC functionality are overlapping. Codec now has DSP. DSP on CPU need DAPM and IO. Current ASoC APIs are based on clearly distinguished component type, platform, CPU, CODEC. It makes difficult to support complex configuration such as CPU -> CODEC -> CODEC or DSP with DAC, ADC, SRC Points discussed - Componentization is coming on V 3.18. - Lars-Peter is cleaning up suspend/resume logic in ASoC framework as conflicting with individual driver suspend/resume. Goal is to move toward bus suspend/resume - Grand scheme is to treat hardware module as component instead of clearly distinguish component type(platform/cpu/codec). Russel King introduced component framework recently - one master with many slave components. ASoC could adopt component framework. Sound card would be the master while individual drivers register slave components. Moving to use component framework would help unbinding of drivers cleanly as well. - Discuss possible phasing out/refactor DPCM, DAI-LINK and add support to DAPM for PCM configuration propagation. Topic: Dynamic FW framework Motivation: It is very common for SoC/CODEC vendors putting DSP onto their hardware. Topology/functionality can change based on DSP image being loaded. Dynamic FW framework is designed to address the need to run-time create DSP topology graph without hard coding into the driver - For DSP with large memory case, swapping DSP image at run-time might not be a concern so firmware download can happen once after boot up but CODEC DSP tend to be memory constraint. Run-time swapping requiring deregister of existing controls and register with new one. ALSA framework does not have good support for this requirement currently. - DFW tool allows each solution vendor to develop its own plug-in and can convert static description to DFW binary format. Through this way, solution vendor can specify its own data and associate with ASoC component such as DAPM widget. Topic: Mapping channels through DAI links in ASoC Motivation: Currently, it is difficult to track how each channel get propagated from one component to another i.e 8 channel streams from CPU to CODECs with stereo channels in TDM interface - Consensus that there is value to track the channel mapping - Possible solution is to create widget per channel of PCM object Topic: ALSA test - Discussed test ALSA core framework on virtual platform and patch submission should go through testing. For embedded system, the benefit may not be significant as bug tend to show up during use case transition - David demonstrated HDA CODEC test. Perhaps, this test can be leveraged for ALSA core test framework - There is no ALSA compliance test right now. There is small tool called alsa-time-test which could potentially be part of ALSA test suite. Another way to validate conformance is to run PulseAudio as PulseAudio exercises a lot of alsa-lib API - Vinod suggested a test framework Liam has been developing, to compare the sign wave form with the captured one. Contribution is welcome and can be merged to any public repo. In addition, for *any* other test programs or metrics, contribution is welcomed. Topic: ALSA documentation - For mixer control related query, Documentation/sound/alsa/ControlNames.txt in kernel tree is a good resource to read - Each kernel function can have a Javadoc style comment. This can be formated through DocBook directory in kernel tree as PDF or HTML (or anything else). So, from now on, the javadoc style comment is mandatory for each patch including exported symbols. - the root DocBook template file is missing for ASoC. Presentation given by Mark in ELC few years back could be a good supplement for someone to get a quick intro to develop drivers to plug into ASoC framework Topic: ALSA control names - Even though in embedded world, SoC architecture from different vendors are not so consistent enough to come up with common name. There is still value to come up with standard name for different types of controls such as Volume, Ramp up/down time (in unit of DB per ms or sample count) - Media controller discussion came up again as it can be solution to help user-space recognize mixer control for the topology - General consensus is that each vendor should have control definition document to describe what each control do - As part of user case transition, user-space often execute mute as well. Instead of ASoC framework handles digital mute as part of startup/shutdown sequence, let user-space have the control through mixer control command. - Suggest to have volume, mute control per PCM object which takes the same approach as channel MAP API by exposing mixer control with name "<pcm device id> volume" Topic: ALSA code removal - Can OSS be removed? Anyone is still using OSS? Perhaps, OSS emulation can be done in user-space - Add warning to notify people to contact usage of APIs to prevent deprecation - Discuss removal of old driver but does not look safe to remove - Suggestion to remove ADPCM support in ALSA core framework - Removal in alsa-library: aserver, shm, and share plugins were discussed. The decision seems to be putting them under a ./configure switch now and remove later Topic: DSP effect library/more DSP support - For DSP effect, Intel goes through mixer control approach which controls are defined in the dynamic firmware. It is not clear how Android effect would be associate stream to corresponding mixer controls for the DSP effect - Discuss couple issues when dealing with DSP architecture. These problems surfaces on PulseAudio 1. DSP DMA data as soon as it can put into its internal memory. Hence, hw_ptr does not reflect actual consumption point in DSP. This causes rewinding logic not function properly. It would be ideal if ALSA could allow driver expose granularity of hardware pointer 2. DSP continuous latency can vary. ALSA should have mechanism to allow driver expose latency information to user-space Topic: consolidate jack report mechanism Currently, there are K-control, input event, extcon mechanism to report headset jack events. Intel would like to see k-control as final solution in order to align with DSP notification through k-control Discussed to consolidate into one mechanism. One proposal from Mark is making a common in-kernel framework which all driver would use this jack framework, the framework would in turn expose this jack through different user-space interfaces depending on kernel configuration Topic: Convergence of single configuration file format UCM vs mixer_path Single format would make vendors who supports both UCM and mixer_path systems life easier. PulseAudio extract use cases list from UCM while mixer_path does not have such support yet. Action item: Arun to look into the convergence effort Topic: scheduled trigger start of PCM - Nick to submit snd_pcm_start_at() patch. The change is software based solution but margin of error is acceptable for the use case in mind - Brought up the use case which time stamp is sent along with every buffer so DSP knows to drop when the buffer is given pass the deadline. Topic: ACPI Intel is moving system-level device configuration file toward ACPI. Device specific data(_DSD) section defined in ACPI 5.1 specification allows device vendor to pass device specific data. (i.e CODEC device data). Topic: synchronization of HDMI/USB hot-plug and configuration events - Instead of waiting for USB hotplug event, Android should wait for udev event to notify new USB sound card is created - Discuss making HDMI a separate sound card. However, HDMI could simply be another routing path in a sound card for embedded architecture. - Suggest to return error when reading EDID info is HDMI is not ready Topic: Sharing hardware component between ALSA framework and other drivers - When hot word is detected, go through DAPM to enable mic path. Topic: Rewindng in ALSA PCM plugins 1. Discussion of the method to calculate the amount of samples that should not be rewound over after the hardware pointer. Result: the audience demonstrated general understanding of the issue. Lars suggested having two hardware pointers, because there are two boundaries that are unsafe to cross when overwriting samples: one from the left (normal write path), and one from the right (rewind path). No action items. 2. Discussion of the criteria when to enable timer-based scheduling. Suggestion: do not enumerate badness [*] when deciding whether to enable tsched in PulseAudio, because the bad things tend to go unreported by the drivers and people treat these as PulseAudio bugs. Move to a whitelist-based approach. The suggestion was rejected. [*] BLOCK_TRANSFER (unimplemented), BATCH (implemented), huge FIFO (unimplemented), completely unrewindable (unimplemented, but a workaround for ioplug exists), what else? 3. Suggestion to revive the snd_pcm_hw_params_can_rewind() API function. Approved by Takashi. 4. Discussion whether the snd_pcm_rewindable() function is useful at all. The uselessness comes from the need to call snd_pcm_avail_update() beforehand, and the position of Clemens Ladisch that the result of snd_pcm_rewindable() must not take pointer granularity and other reasons why non-rewindable samples exist into account. That way, the caller can just deduce the result from the snd_pcm_avail_update() return value. David Henningsson does not like this situation. Mark Brown suggests reporting the DMA transfer size, with the possibility for architectures to override the returned value with something larger such as the cache line size. 5. Status report on rewind support in PCM plugins. Summary: at least 10 plugins out of 26 have known problems and should have rewind support either fixed (which is not always possible) or disabled. Thanks Patrick -- Patrick Lai Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,a Linux Foundation Collaborative Project

1 0

[alsa-devel] [PATCH 0/3] ASoC: intel: add support for future acpi platforms
by Vinod Koul 27 Oct '14

27 Oct '14

We have some SoCs which are ACPI based. Current driver supports Merrifield type PCI SoC. SO make some minor changes required for ACPI support in subsequent series Subhransu S. Prusty (3): ASoC: Intel: mrfld: Replace pci_id with unique device id ASoC: Intel: mrfld - Define ipc_info structure ASoC: Intel: mrfld: Define sst_res_info for acpi arch/x86/include/asm/platform_sst_audio.h | 28 ++++++++++++++++++++++++++++ sound/soc/intel/sst/sst.c | 10 +++++----- sound/soc/intel/sst/sst.h | 5 +++-- sound/soc/intel/sst/sst_pvt.c | 4 ++-- 4 files changed, 38 insertions(+), 9 deletions(-)

2 4