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

[PATCH] ASoC: rt1011: add i2s reference control for rt1011
by Jack Yu 13 Sep '21

13 Sep '21

Add i2s reference control for rt1011 amp. Signed-off-by: Jack Yu <jack.yu(a)realtek.com> --- sound/soc/codecs/rt1011.c | 54 +++++++++++++++++++++++++++++++++++++++ sound/soc/codecs/rt1011.h | 7 +++++ 2 files changed, 61 insertions(+) diff --git a/sound/soc/codecs/rt1011.c b/sound/soc/codecs/rt1011.c index faff2b558687..508597866dff 100644 --- a/sound/soc/codecs/rt1011.c +++ b/sound/soc/codecs/rt1011.c @@ -1311,6 +1311,57 @@ static int rt1011_r0_load_info(struct snd_kcontrol *kcontrol, .put = rt1011_r0_load_mode_put \ } +static const char * const rt1011_i2s_ref[] = { + "None", "Left Channel", "Right Channel" +}; + +static SOC_ENUM_SINGLE_DECL(rt1011_i2s_ref_enum, 0, 0, + rt1011_i2s_ref); + +static int rt1011_i2s_ref_put(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct snd_soc_component *component = + snd_soc_kcontrol_component(kcontrol); + struct rt1011_priv *rt1011 = + snd_soc_component_get_drvdata(component); + int i2s_ref_ch = ucontrol->value.integer.value[0]; + + switch (i2s_ref_ch) { + case RT1011_I2S_REF_LEFT_CH: + regmap_write(rt1011->regmap, RT1011_TDM_TOTAL_SET, 0x0240); + regmap_write(rt1011->regmap, RT1011_TDM1_SET_2, 0x8); + regmap_write(rt1011->regmap, RT1011_TDM1_SET_1, 0x1022); + regmap_write(rt1011->regmap, RT1011_ADCDAT_OUT_SOURCE, 0x4); + break; + case RT1011_I2S_REF_RIGHT_CH: + regmap_write(rt1011->regmap, RT1011_TDM_TOTAL_SET, 0x0240); + regmap_write(rt1011->regmap, RT1011_TDM1_SET_2, 0x8); + regmap_write(rt1011->regmap, RT1011_TDM1_SET_1, 0x10a2); + regmap_write(rt1011->regmap, RT1011_ADCDAT_OUT_SOURCE, 0x4); + break; + default: + dev_info(component->dev, "I2S Reference: Do nothing\n"); + } + + rt1011->i2s_ref = ucontrol->value.integer.value[0]; + + return 0; +} + +static int rt1011_i2s_ref_get(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct snd_soc_component *component = + snd_soc_kcontrol_component(kcontrol); + struct rt1011_priv *rt1011 = + snd_soc_component_get_drvdata(component); + + ucontrol->value.integer.value[0] = rt1011->i2s_ref; + + return 0; +} + static const struct snd_kcontrol_new rt1011_snd_controls[] = { /* I2S Data In Selection */ SOC_ENUM("DIN Source", rt1011_din_source_enum), @@ -1349,6 +1400,9 @@ static const struct snd_kcontrol_new rt1011_snd_controls[] = { /* R0 temperature */ SOC_SINGLE("R0 Temperature", RT1011_STP_INITIAL_RESISTANCE_TEMP, 2, 255, 0), + /* I2S Reference */ + SOC_ENUM_EXT("I2S Reference", rt1011_i2s_ref_enum, + rt1011_i2s_ref_get, rt1011_i2s_ref_put), }; static int rt1011_is_sys_clk_from_pll(struct snd_soc_dapm_widget *source, diff --git a/sound/soc/codecs/rt1011.h b/sound/soc/codecs/rt1011.h index 68fadc15fa8c..afb2fad94216 100644 --- a/sound/soc/codecs/rt1011.h +++ b/sound/soc/codecs/rt1011.h @@ -654,6 +654,12 @@ enum { RT1011_AIFS }; +enum { + RT1011_I2S_REF_NONE, + RT1011_I2S_REF_LEFT_CH, + RT1011_I2S_REF_RIGHT_CH, +}; + /* BiQual & DRC related settings */ #define RT1011_BQ_DRC_NUM 128 struct rt1011_bq_drc_params { @@ -692,6 +698,7 @@ struct rt1011_priv { unsigned int r0_reg, cali_done; unsigned int r0_calib, temperature_calib; int recv_spk_mode; + unsigned int i2s_ref; }; #endif /* end of _RT1011_H_ */ -- 2.31.1

3 7

[PATCH] ASoC: SOF: control: fix a typo in put operations for kcontrol
by Peter Ujfalusi 13 Sep '21

13 Sep '21

From: Rander Wang <rander.wang(a)intel.com> SOF_CTRL_TYPE_VALUE_CHAN_SET should be used for put operations for consistency. The current use of _GET is obviously incorrect but _GET and _SET result in the same action so there is no functional change introduced by this patch. Signed-off-by: Rander Wang <rander.wang(a)intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> --- sound/soc/sof/control.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/sof/control.c b/sound/soc/sof/control.c index 456f3cd36678..58bb89af4de1 100644 --- a/sound/soc/sof/control.c +++ b/sound/soc/sof/control.c @@ -144,7 +144,7 @@ int snd_sof_volume_put(struct snd_kcontrol *kcontrol, if (pm_runtime_active(scomp->dev)) snd_sof_ipc_set_get_comp_data(scontrol, SOF_IPC_COMP_SET_VALUE, - SOF_CTRL_TYPE_VALUE_CHAN_GET, + SOF_CTRL_TYPE_VALUE_CHAN_SET, SOF_CTRL_CMD_VOLUME, true); return change; @@ -217,7 +217,7 @@ int snd_sof_switch_put(struct snd_kcontrol *kcontrol, if (pm_runtime_active(scomp->dev)) snd_sof_ipc_set_get_comp_data(scontrol, SOF_IPC_COMP_SET_VALUE, - SOF_CTRL_TYPE_VALUE_CHAN_GET, + SOF_CTRL_TYPE_VALUE_CHAN_SET, SOF_CTRL_CMD_SWITCH, true); @@ -266,7 +266,7 @@ int snd_sof_enum_put(struct snd_kcontrol *kcontrol, if (pm_runtime_active(scomp->dev)) snd_sof_ipc_set_get_comp_data(scontrol, SOF_IPC_COMP_SET_VALUE, - SOF_CTRL_TYPE_VALUE_CHAN_GET, + SOF_CTRL_TYPE_VALUE_CHAN_SET, SOF_CTRL_CMD_ENUM, true); -- 2.33.0

2 1

[PATCH] ASoC: amd: acp: declare and add prefix to 'bt_uart_enable' symbol
by Pierre-Louis Bossart 13 Sep '21

13 Sep '21

Sparse reports the following warning: sound/soc/amd/acp-pcm-dma.c:39:6: error: symbol 'bt_uart_enable' was not declared. Should it be static? It's not very good practice to export such symbols that can easily conflict, add the acp_ prefix and add declaration in header file. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- sound/soc/amd/acp-da7219-max98357a.c | 6 +++--- sound/soc/amd/acp-pcm-dma.c | 6 +++--- sound/soc/amd/acp.h | 2 ++ 3 files changed, 8 insertions(+), 6 deletions(-) diff --git a/sound/soc/amd/acp-da7219-max98357a.c b/sound/soc/amd/acp-da7219-max98357a.c index b3df98a9f9f3..b2065f3fe42c 100644 --- a/sound/soc/amd/acp-da7219-max98357a.c +++ b/sound/soc/amd/acp-da7219-max98357a.c @@ -33,7 +33,7 @@ static struct clk *da7219_dai_wclk; static struct clk *da7219_dai_bclk; static struct clk *rt5682_dai_wclk; static struct clk *rt5682_dai_bclk; -extern bool bt_uart_enable; + void *acp_soc_is_rltk_max(struct device *dev); static int cz_da7219_init(struct snd_soc_pcm_runtime *rtd) @@ -760,8 +760,8 @@ static int cz_probe(struct platform_device *pdev) "devm_snd_soc_register_card(%s) failed\n", card->name); } - bt_uart_enable = !device_property_read_bool(&pdev->dev, - "bt-pad-enable"); + acp_bt_uart_enable = !device_property_read_bool(&pdev->dev, + "bt-pad-enable"); return 0; } diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c index 11b3c4f39eba..1f322accd9ea 100644 --- a/sound/soc/amd/acp-pcm-dma.c +++ b/sound/soc/amd/acp-pcm-dma.c @@ -36,8 +36,8 @@ #define ST_MIN_BUFFER ST_MAX_BUFFER #define DRV_NAME "acp_audio_dma" -bool bt_uart_enable = true; -EXPORT_SYMBOL(bt_uart_enable); +bool acp_bt_uart_enable = true; +EXPORT_SYMBOL(acp_bt_uart_enable); static const struct snd_pcm_hardware acp_pcm_hardware_playback = { .info = SNDRV_PCM_INFO_INTERLEAVED | @@ -596,7 +596,7 @@ static int acp_init(void __iomem *acp_mmio, u32 asic_type) acp_reg_write(val, acp_mmio, mmACP_SOFT_RESET); /* For BT instance change pins from UART to BT */ - if (!bt_uart_enable) { + if (!acp_bt_uart_enable) { val = acp_reg_read(acp_mmio, mmACP_BT_UART_PAD_SEL); val |= ACP_BT_UART_PAD_SELECT_MASK; acp_reg_write(val, acp_mmio, mmACP_BT_UART_PAD_SEL); diff --git a/sound/soc/amd/acp.h b/sound/soc/amd/acp.h index e5ab6c6040a6..85529ed7e5f5 100644 --- a/sound/soc/amd/acp.h +++ b/sound/soc/amd/acp.h @@ -204,4 +204,6 @@ typedef struct acp_dma_dscr_transfer { u32 reserved; } acp_dma_dscr_transfer_t; +extern bool acp_bt_uart_enable; + #endif /*__ACP_HW_H */ -- 2.25.1

2 1

[PATCH] ASoC: dt-bindings: lpass: add binding headers for digital codecs
by Srinivasa Rao Mandadapu 13 Sep '21

13 Sep '21

Add header defining for lpass internal digital codecs rx,tx and va dai node id's. Signed-off-by: Srinivasa Rao Mandadapu <srivasam(a)codeaurora.org> --- include/dt-bindings/sound/qcom,lpass.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/include/dt-bindings/sound/qcom,lpass.h b/include/dt-bindings/sound/qcom,lpass.h index 7b0b80b..187af45 100644 --- a/include/dt-bindings/sound/qcom,lpass.h +++ b/include/dt-bindings/sound/qcom,lpass.h @@ -10,6 +10,11 @@ #define LPASS_DP_RX 5 +#define LPASS_CDC_DMA_RX0 6 +#define LPASS_CDC_DMA_TX3 7 +#define LPASS_CDC_DMA_VA0 8 +#define LPASS_MAX_PORTS 9 + #define LPASS_MCLK0 0 #endif /* __DT_QCOM_LPASS_H */ -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

4 7

Mackie Onyx 1640i: Long run playback results in xrun and hang.
by AreYouLoco? 13 Sep '21

13 Sep '21

Hi, I am using custom build real-time kernel 5.12.2-rt3-fw. JACK with ALSA backend on Mackie Onyx 1640i. Lenovo Thinkpad T420 with FireWire. Debian Bullseye (11.0 - stable) JACKD version 1.9.17. I am using 512 samples 3 periods @48kHz. The problem is that long run playback only around 1h (but the time differs), result in XRUN detected by JACK logs and the whole audio stops. So I have to restart JACK in order to make it work. DMESG is silent about that issue. But sometimes I get: snd_oxfw fw1.0: Detect discontinuity of CIP: E8 00 And different hex values there. Here is interesting part from the log: Sun Sep 12 22:10:12 2021: Jack: JackRequest::Notification Sun Sep 12 22:10:12 2021: Jack: **** alsa_pcm: xrun of at least 0.027 msecs Sun Sep 12 22:10:12 2021: Jack: Repreparing capture Sun Sep 12 22:10:12 2021: Jack: Repreparing playback Sun Sep 12 22:10:12 2021: Jack: ALSA XRun wait_status = 0 Sun Sep 12 22:10:12 2021: Jack: JackEngine::ClientNotify: no callback for notification = 3 Sun Sep 12 22:10:12 2021: Jack: JackEngine::ClientNotify: no callback for notification = 3 Sun Sep 12 22:10:12 2021: Jack: JackClient::ClientNotify ref = 2 name = dbusapi notify = 3 Sun Sep 12 22:10:12 2021: Jack: JackClient::kXRunCallback Sun Sep 12 22:10:12 2021: Jack: JackEngine::ClientNotify: no callback for notification = 3 Sun Sep 12 22:10:12 2021: Jack: JackEngine::ClientNotify: no callback for notification = 3 Sun Sep 12 22:10:12 2021: Jack: JackEngine::ClientNotify: no callback for notification = 3 Sun Sep 12 22:10:12 2021: Jack: JackEngine::ClientNotify: no callback for notification = 3 Sun Sep 12 22:10:28 2021: ERROR: ALSA: poll time out, polled for 15998655 usecs, Retrying with a recovery, retry cnt = 1 Sun Sep 12 22:10:44 2021: ERROR: ALSA: poll time out, polled for 15998654 usecs, Retrying with a recovery, retry cnt = 2 Sun Sep 12 22:11:00 2021: ERROR: ALSA: poll time out, polled for 15998659 usecs, Retrying with a recovery, retry cnt = 3 Sun Sep 12 22:11:16 2021: ERROR: ALSA: poll time out, polled for 15998649 usecs, Retrying with a recovery, retry cnt = 4 Anyone have idea what might be the cause of this XRUN? Or how to debug that? Its reproducible on my setup. Another log catched the same issue: Sun Sep 12 16:50:44 2021: Jack: **** alsa_pcm: xrun of at least 0.030 msecs Sun Sep 12 16:50:44 2021: Jack: Repreparing capture Sun Sep 12 16:50:44 2021: Jack: Repreparing playback Sun Sep 12 16:50:44 2021: Jack: ALSA XRun wait_status = 0 Sun Sep 12 16:50:44 2021: Jack: JackRequest::Notification Sun Sep 12 16:50:44 2021: Jack: JackEngine::ClientNotify: no callback for notification = 3 Sun Sep 12 16:50:44 2021: Jack: JackEngine::ClientNotify: no callback for notification = 3 Sun Sep 12 16:50:44 2021: Jack: JackClient::ClientNotify ref = 2 name = dbusapi notify = 3 Sun Sep 12 16:50:44 2021: Jack: JackClient::kXRunCallback Sun Sep 12 16:50:44 2021: Jack: JackEngine::ClientNotify: no callback for notification = 3 Sun Sep 12 16:50:44 2021: Jack: JackEngine::ClientNotify: no callback for notification = 3 Sun Sep 12 16:50:44 2021: Jack: JackEngine::ClientNotify: no callback for notification = 3 Sun Sep 12 16:50:44 2021: Jack: JackEngine::ClientNotify: no callback for notification = 3 Sun Sep 12 16:51:00 2021: ERROR: ALSA: poll time out, polled for 15998366 usecs, Retrying with a recovery, retry cnt = 1 Sun Sep 12 16:51:16 2021: ERROR: ALSA: poll time out, polled for 15998353 usecs, Retrying with a recovery, retry cnt = 2 Sun Sep 12 16:51:32 2021: ERROR: ALSA: poll time out, polled for 15998352 usecs, Retrying with a recovery, retry cnt = 3 Sun Sep 12 16:51:48 2021: ERROR: ALSA: poll time out, polled for 15998367 usecs, Retrying with a recovery, retry cnt = 4 Sun Sep 12 16:52:04 2021: ERROR: ALSA: poll time out, polled for 15998353 usecs, Retrying with a recovery, retry cnt = 5 Sun Sep 12 16:52:20 2021: ERROR: ALSA: poll time out, polled for 15998371 usecs, Reached max retry cnt = 5, Exiting Sun Sep 12 16:52:20 2021: ERROR: JackAudioDriver::ProcessAsync: read error, stopping... Sun Sep 12 16:52:20 2021: Jack: JackPosixThread::ThreadHandler : exit I am willing to provide additional info. Thank you in advance, AreYouLoco?

1 0

[PATCH] ALSA: oxfw: fix transmission method for Loud models based on OXFW971
by Takashi Sakamoto 13 Sep '21

13 Sep '21

Loud Technologies Mackie Onyx 1640i (former model) is identified as the model which uses OXFW971. The analysis of packet dump shows that it transfers events in blocking method of IEC 61883-6, however the default behaviour of ALSA oxfw driver is for non-blocking method. This commit adds code to detect it assuming that all of loud models based on OXFW971 have such quirk. It brings no functional change except for alignment rule of PCM buffer. Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/oxfw/oxfw.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/sound/firewire/oxfw/oxfw.c b/sound/firewire/oxfw/oxfw.c index cb5b5e3a481b..daf731364695 100644 --- a/sound/firewire/oxfw/oxfw.c +++ b/sound/firewire/oxfw/oxfw.c @@ -184,13 +184,16 @@ static int detect_quirks(struct snd_oxfw *oxfw, const struct ieee1394_device_id model = val; } - /* - * Mackie Onyx Satellite with base station has a quirk to report a wrong - * value in 'dbs' field of CIP header against its format information. - */ - if (vendor == VENDOR_LOUD && model == MODEL_SATELLITE) + if (vendor == VENDOR_LOUD) { + // Mackie Onyx Satellite with base station has a quirk to report a wrong + // value in 'dbs' field of CIP header against its format information. oxfw->quirks |= SND_OXFW_QUIRK_WRONG_DBS; + // OXFW971-based models may transfer events by blocking method. + if (!(oxfw->quirks & SND_OXFW_QUIRK_JUMBO_PAYLOAD)) + oxfw->quirks |= SND_OXFW_QUIRK_BLOCKING_TRANSMISSION; + } + return 0; } -- 2.30.2

2 1

[PATCH AUTOSEL 4.4 29/35] ASoC: intel: atom: Revert PCM buffer address setup workaround again
by Sasha Levin 12 Sep '21

12 Sep '21

From: Takashi Iwai <tiwai(a)suse.de> [ Upstream commit e28ac04a705e946eddc5e7d2fc712dea3f20fe9e ] We worked around the breakage of PCM buffer setup by the commit 65ca89c2b12c ("ASoC: intel: atom: Fix breakage for PCM buffer address setup"), but this isn't necessary since the CONTINUOUS buffer type also sets runtime->dma_addr since commit f84ba106a018 ("ALSA: memalloc: Store snd_dma_buffer.addr for continuous pages, too"). Let's revert the change again. Link: https://lore.kernel.org/r/20210822072127.9786-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/intel/atom/sst-mfld-platform-pcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c b/sound/soc/intel/atom/sst-mfld-platform-pcm.c index d0d338533eb6..64079423b298 100644 --- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c +++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c @@ -134,7 +134,7 @@ static void sst_fill_alloc_params(struct snd_pcm_substream *substream, snd_pcm_uframes_t period_size; ssize_t periodbytes; ssize_t buffer_bytes = snd_pcm_lib_buffer_bytes(substream); - u32 buffer_addr = virt_to_phys(substream->runtime->dma_area); + u32 buffer_addr = substream->runtime->dma_addr; channels = substream->runtime->channels; period_size = substream->runtime->period_size; -- 2.30.2

2 2

[PATCH AUTOSEL 5.13 176/219] ASoC: intel: atom: Revert PCM buffer address setup workaround again
by Sasha Levin 11 Sep '21

11 Sep '21

From: Takashi Iwai <tiwai(a)suse.de> [ Upstream commit e28ac04a705e946eddc5e7d2fc712dea3f20fe9e ] We worked around the breakage of PCM buffer setup by the commit 65ca89c2b12c ("ASoC: intel: atom: Fix breakage for PCM buffer address setup"), but this isn't necessary since the CONTINUOUS buffer type also sets runtime->dma_addr since commit f84ba106a018 ("ALSA: memalloc: Store snd_dma_buffer.addr for continuous pages, too"). Let's revert the change again. Link: https://lore.kernel.org/r/20210822072127.9786-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/intel/atom/sst-mfld-platform-pcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c b/sound/soc/intel/atom/sst-mfld-platform-pcm.c index 905c7965f653..5db2f4865bbb 100644 --- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c +++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c @@ -127,7 +127,7 @@ static void sst_fill_alloc_params(struct snd_pcm_substream *substream, snd_pcm_uframes_t period_size; ssize_t periodbytes; ssize_t buffer_bytes = snd_pcm_lib_buffer_bytes(substream); - u32 buffer_addr = virt_to_phys(substream->runtime->dma_area); + u32 buffer_addr = substream->runtime->dma_addr; channels = substream->runtime->channels; period_size = substream->runtime->period_size; -- 2.30.2

2 2

Raw ALSA PCM
by Ryan McClue 11 Sep '21

11 Sep '21

Hello, I'm trying to play a simple PCM buffer with ALSA without asoundlib. This has proven very difficult as there are very few resources that show usage without asoundlib. Through my investigations I was fortunate enough to obtain a gist that attempts to do this: https://gist.github.com/takaswie/d8a9553c230971d974a3dfc759b2ff67 Unfortunately this application does not work. I tested the application using the virtual snd-dummy driver and the application produced the same error. So, it is most likely an application error, rather than an Intel HDA error. I'm emailing to ask for help in getting the program to work. I'm really lost as to what should be changed in the code. I'm sure that a working example of this will be useful for many programmers. Thank you

1 0

ASoC/ALSA Out of Memory Issue
by Alex Roberts 10 Sep '21

10 Sep '21

Hello, I am developing a dummy codec to interface with an 8-channel, 24-bit ADC. I've got it working on an NXP imx8m through the fsl_sai driver on kernel 5.4.85. I can capture all 8 channels at varying sample rates using arecord, and I've verified correct data capture via opening the resulting .wav file in Audacity. The problem I am having is that occasionally, upon starting arecord - after a fresh power cycle - I get an out of memory error. Other times I get an out of memory after a non-deterministic period of capture. Starting capture again also reports out of memory, but if I wait several minutes and start capture it will start recording again. A power cycle usually helps, but as stated earlier, not 100% of the time. I'm trying to track down where the oom error is coming from, but haven't had much luck. My colleague tried running arecord with valgrind to check for memory leaks and nothing of note was observed. My suspicion is there's something going on with allocated memory for DMA, like fragmentation starts to happen and it can't get a contiguous region for operation. Reserving a larger pool - either via device tree or kernel cmdline arguments in the bootoader - did not seem to help. Another thought is that it's a boundary/alignment issue due to the 24-bit data, and the error is the result of trying to allocate a chunk of memory for DMA that doesn't align. I'm very new to ALSA dev with some exposure to kernel dev in general, so please correct me if I'm wrong or completely mis-understanding something. Any suggestions on where I should / how I can debug this memory error? Thanks, Alex. PS: Previously sent this to just alsa-devel mailing list on 7/21, but never saw it show up in the archives. Here is more info since then: The goal is 8-channel, 96k sampling rate. I've reduced sampling rate and still have the issue. Reducing down to 4-channels helps, but haven't tested long term enough to evaluate by how much. Narrowed it down to device_prep_dma_cyclic(..) returning NULL within dmaengine_prep_dma_cyclic(..)..... still tracing through source to learn exactly what is going on.

2 3