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

[alsa-devel] [PATCH v2] ASoC: AMD: Fix race condition between register access
by Agrawal, Akshu 30 Oct '18

30 Oct '18

During simultaneous running of playback and capture, we got hit by incorrect value write on common register. This was due to race condition between 2 streams. Fixing this by locking the common register access. Signed-off-by: Akshu Agrawal <akshu.agrawal(a)amd.com> --- v2: Added 2 helper functions, removed locking in ch enable/disable as they are separate registers. sound/soc/amd/acp-pcm-dma.c | 63 ++++++++++++++++++++++++++++++++++----------- 1 file changed, 48 insertions(+), 15 deletions(-) diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c index 0ac4b5b..5be9c2d 100644 --- a/sound/soc/amd/acp-pcm-dma.c +++ b/sound/soc/amd/acp-pcm-dma.c @@ -121,6 +121,9 @@ .periods_max = CAPTURE_MAX_NUM_PERIODS, }; +/* Lock to protect access to registers */ +static DEFINE_SPINLOCK(lock); + static u32 acp_reg_read(void __iomem *acp_mmio, u32 reg) { return readl(acp_mmio + (reg * 4)); @@ -131,6 +134,33 @@ static void acp_reg_write(u32 val, void __iomem *acp_mmio, u32 reg) writel(val, acp_mmio + (reg * 4)); } +static void acp_reg_write_srbm_targ(void __iomem *acp_mmio, + u32 addr, u32 data) +{ + unsigned long flags; + + spin_lock_irqsave(&lock, flags); + acp_reg_write(addr, acp_mmio, mmACP_SRBM_Targ_Idx_Addr); + acp_reg_write(data, acp_mmio, mmACP_SRBM_Targ_Idx_Data); + spin_unlock_irqrestore(&lock, flags); +} + +static void acp_reg_read_mod_write(void __iomem *acp_mmio, u32 addr, + u32 mask, bool set) +{ + u32 val; + unsigned long flags; + + spin_lock_irqsave(&lock, flags); + val = acp_reg_read(acp_mmio, addr); + if (set) + val |= mask; + else + val &= ~mask; + acp_reg_write(val, acp_mmio, addr); + spin_unlock_irqrestore(&lock, flags); +} + /* * Configure a given dma channel parameters - enable/disable, * number of descriptors, priority @@ -172,15 +202,12 @@ static void config_dma_descriptor_in_sram(void __iomem *acp_mmio, sram_offset = (descr_idx * sizeof(acp_dma_dscr_transfer_t)); /* program the source base address. */ - acp_reg_write(sram_offset, acp_mmio, mmACP_SRBM_Targ_Idx_Addr); - acp_reg_write(descr_info->src, acp_mmio, mmACP_SRBM_Targ_Idx_Data); + acp_reg_write_srbm_targ(acp_mmio, sram_offset, descr_info->src); /* program the destination base address. */ - acp_reg_write(sram_offset + 4, acp_mmio, mmACP_SRBM_Targ_Idx_Addr); - acp_reg_write(descr_info->dest, acp_mmio, mmACP_SRBM_Targ_Idx_Data); - + acp_reg_write_srbm_targ(acp_mmio, sram_offset + 4, descr_info->dest); /* program the number of bytes to be transferred for this descriptor. */ - acp_reg_write(sram_offset + 8, acp_mmio, mmACP_SRBM_Targ_Idx_Addr); - acp_reg_write(descr_info->xfer_val, acp_mmio, mmACP_SRBM_Targ_Idx_Data); + acp_reg_write_srbm_targ(acp_mmio, sram_offset + 8, + descr_info->xfer_val); } static void pre_config_reset(void __iomem *acp_mmio, u16 ch_num) @@ -309,8 +336,12 @@ static void acp_pte_config(void __iomem *acp_mmio, struct page *pg, u32 low; u32 high; u32 offset; + unsigned long flags; offset = ACP_DAGB_GRP_SRBM_SRAM_BASE_OFFSET + (pte_offset * 8); + + spin_lock_irqsave(&lock, flags); + for (page_idx = 0; page_idx < (num_of_pages); page_idx++) { /* Load the low address of page int ACP SRAM through SRBM */ acp_reg_write((offset + (page_idx * 8)), @@ -333,6 +364,8 @@ static void acp_pte_config(void __iomem *acp_mmio, struct page *pg, /* Move to next physically contiguos page */ pg++; } + + spin_unlock_irqrestore(&lock, flags); } static void config_acp_dma(void __iomem *acp_mmio, @@ -870,29 +903,29 @@ static int acp_dma_hw_params(struct snd_pcm_substream *substream, } } if (adata->asic_type == CHIP_STONEY) { - val = acp_reg_read(adata->acp_mmio, - mmACP_I2S_16BIT_RESOLUTION_EN); if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { switch (rtd->i2s_instance) { case I2S_BT_INSTANCE: - val |= ACP_I2S_BT_16BIT_RESOLUTION_EN; + val = ACP_I2S_BT_16BIT_RESOLUTION_EN; break; case I2S_SP_INSTANCE: default: - val |= ACP_I2S_SP_16BIT_RESOLUTION_EN; + val = ACP_I2S_SP_16BIT_RESOLUTION_EN; } } else { switch (rtd->i2s_instance) { case I2S_BT_INSTANCE: - val |= ACP_I2S_BT_16BIT_RESOLUTION_EN; + val = ACP_I2S_BT_16BIT_RESOLUTION_EN; break; case I2S_SP_INSTANCE: default: - val |= ACP_I2S_MIC_16BIT_RESOLUTION_EN; + val = ACP_I2S_MIC_16BIT_RESOLUTION_EN; } } - acp_reg_write(val, adata->acp_mmio, - mmACP_I2S_16BIT_RESOLUTION_EN); + acp_reg_read_mod_write(adata->acp_mmio, + mmACP_I2S_16BIT_RESOLUTION_EN, + val, + true); } if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { -- 1.9.1

1 0

[alsa-devel] [PATCH] ASoC: AMD: Fix race condition between register access
by Agrawal, Akshu 30 Oct '18

30 Oct '18

During simultaneous running of playback and capture, we got hit by incorrect value write on common register. This was due to race condition between 2 streams. Fixing this by locking the common register access. Signed-off-by: Akshu Agrawal <akshu.agrawal(a)amd.com> --- sound/soc/amd/acp-pcm-dma.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c index 0ac4b5b..993a7db 100644 --- a/sound/soc/amd/acp-pcm-dma.c +++ b/sound/soc/amd/acp-pcm-dma.c @@ -121,6 +121,9 @@ .periods_max = CAPTURE_MAX_NUM_PERIODS, }; +/* Lock to protect access to registers */ +static DEFINE_SPINLOCK(lock); + static u32 acp_reg_read(void __iomem *acp_mmio, u32 reg) { return readl(acp_mmio + (reg * 4)); @@ -168,9 +171,12 @@ static void config_dma_descriptor_in_sram(void __iomem *acp_mmio, acp_dma_dscr_transfer_t *descr_info) { u32 sram_offset; + unsigned long flags; sram_offset = (descr_idx * sizeof(acp_dma_dscr_transfer_t)); + spin_lock_irqsave(&lock, flags); + /* program the source base address. */ acp_reg_write(sram_offset, acp_mmio, mmACP_SRBM_Targ_Idx_Addr); acp_reg_write(descr_info->src, acp_mmio, mmACP_SRBM_Targ_Idx_Data); @@ -181,6 +187,8 @@ static void config_dma_descriptor_in_sram(void __iomem *acp_mmio, /* program the number of bytes to be transferred for this descriptor. */ acp_reg_write(sram_offset + 8, acp_mmio, mmACP_SRBM_Targ_Idx_Addr); acp_reg_write(descr_info->xfer_val, acp_mmio, mmACP_SRBM_Targ_Idx_Data); + + spin_unlock_irqrestore(&lock, flags); } static void pre_config_reset(void __iomem *acp_mmio, u16 ch_num) @@ -309,8 +317,12 @@ static void acp_pte_config(void __iomem *acp_mmio, struct page *pg, u32 low; u32 high; u32 offset; + unsigned long flags; offset = ACP_DAGB_GRP_SRBM_SRAM_BASE_OFFSET + (pte_offset * 8); + + spin_lock_irqsave(&lock, flags); + for (page_idx = 0; page_idx < (num_of_pages); page_idx++) { /* Load the low address of page int ACP SRAM through SRBM */ acp_reg_write((offset + (page_idx * 8)), @@ -333,6 +345,8 @@ static void acp_pte_config(void __iomem *acp_mmio, struct page *pg, /* Move to next physically contiguos page */ pg++; } + + spin_unlock_irqrestore(&lock, flags); } static void config_acp_dma(void __iomem *acp_mmio, @@ -367,6 +381,7 @@ static void acp_dma_cap_channel_enable(void __iomem *acp_mmio, u16 cap_channel) { u32 val, ch_reg, imr_reg, res_reg; + unsigned long flags; switch (cap_channel) { case CAP_CHANNEL1: @@ -381,6 +396,8 @@ static void acp_dma_cap_channel_enable(void __iomem *acp_mmio, imr_reg = mmACP_I2SMICSP_IMR0; break; } + spin_lock_irqsave(&lock, flags); + val = acp_reg_read(acp_mmio, mmACP_I2S_16BIT_RESOLUTION_EN); if (val & ACP_I2S_MIC_16BIT_RESOLUTION_EN) { @@ -393,12 +410,15 @@ static void acp_dma_cap_channel_enable(void __iomem *acp_mmio, val &= ~ACP_I2SMICSP_IMR1__I2SMICSP_RXFOM_MASK; acp_reg_write(val, acp_mmio, imr_reg); acp_reg_write(0x1, acp_mmio, ch_reg); + + spin_unlock_irqrestore(&lock, flags); } static void acp_dma_cap_channel_disable(void __iomem *acp_mmio, u16 cap_channel) { u32 val, ch_reg, imr_reg; + unsigned long flags; switch (cap_channel) { case CAP_CHANNEL1: @@ -411,11 +431,15 @@ static void acp_dma_cap_channel_disable(void __iomem *acp_mmio, ch_reg = mmACP_I2SMICSP_RER0; break; } + spin_lock_irqsave(&lock, flags); + val = acp_reg_read(acp_mmio, imr_reg); val |= ACP_I2SMICSP_IMR1__I2SMICSP_RXDAM_MASK; val |= ACP_I2SMICSP_IMR1__I2SMICSP_RXFOM_MASK; acp_reg_write(val, acp_mmio, imr_reg); acp_reg_write(0x0, acp_mmio, ch_reg); + + spin_unlock_irqrestore(&lock, flags); } /* Start a given DMA channel transfer */ @@ -847,6 +871,7 @@ static int acp_dma_hw_params(struct snd_pcm_substream *substream, int status; uint64_t size; u32 val = 0; + unsigned long flags; struct page *pg; struct snd_pcm_runtime *runtime; struct audio_substream_data *rtd; @@ -870,6 +895,8 @@ static int acp_dma_hw_params(struct snd_pcm_substream *substream, } } if (adata->asic_type == CHIP_STONEY) { + spin_lock_irqsave(&lock, flags); + val = acp_reg_read(adata->acp_mmio, mmACP_I2S_16BIT_RESOLUTION_EN); if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { @@ -893,6 +920,8 @@ static int acp_dma_hw_params(struct snd_pcm_substream *substream, } acp_reg_write(val, adata->acp_mmio, mmACP_I2S_16BIT_RESOLUTION_EN); + + spin_unlock_irqrestore(&lock, flags); } if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { -- 1.9.1

2 2

[alsa-devel] [PATCH] ASoC: fix oops w/ for_each_rtd_codec_dai_rollback() macro
by Pierre-Louis Bossart 30 Oct '18

30 Oct '18

A kernel oops happens on an error case (usual missing BE mixer configuration required by Intel SST driver). Git bisect points to this macro and an operator precedence issue. for (; ((i--) >= 0) && ((dai) = rtd->codec_dais[i]);) The initial code replaced by this macro was while (--i >= 0) { codec_dai = rtd->codec_dais[i]; Fix the C operator precedence difference by reverting to pre-decrement Fixes: 0b7990e3897 ('ASoC: add for_each_rtd_codec_dai() macro') Cc: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- include/sound/soc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index f1dab1f4b194..70c10a8f3e90 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -1192,7 +1192,7 @@ struct snd_soc_pcm_runtime { ((i) < rtd->num_codecs) && ((dai) = rtd->codec_dais[i]); \ (i)++) #define for_each_rtd_codec_dai_rollback(rtd, i, dai) \ - for (; ((i--) >= 0) && ((dai) = rtd->codec_dais[i]);) + for (; ((--i) >= 0) && ((dai) = rtd->codec_dais[i]);) /* mixer control */ -- 2.17.1

2 1

[alsa-devel] [PATCH - dmix v2 1/1] pcm: dmix: Align slave_hw_ptr to slave period boundary
by twischer＠de.adit-jv.com 30 Oct '18

30 Oct '18

From: Laxmi Devi <Laxmi.Devi(a)in.bosch.com> These changes are required due to the kernel commit 07b7acb51d283d8469696c906b91f1882696a4d4 ("ASoC: rsnd: update pointer more accurate") Issue is that snd_pcm_wait() goes back to waiting because the hw_ptr is not period aligned. Therefore snd_pcm_wait() will block for a longer time as required. With these rcar driver changes the exact position of the dma is returned. During snd_pcm_start they read hw_ptr as reference, and this hw_ptr is now not period aligned, and is a little ahead over the period while it is read. Therefore when the avail is calculated during snd_pcm_wait(), it is missing the avail_min by a few frames. Consider the below example: Considering the application is trying to write 0x120 frames and the period_size = 0x60, avail_min = 0x120 and buffersize = 0x360 : rsnd_pointer=0x12c -> dma pointer at the end of second write during snd_pcm_dmix_start(). Since another 0x120 buffer is available, application writes 0x120 and goes to snd_pcm_wait(). It is woken up after 3 snd_pcm_period_elapsed() to see rsnd_pointer=0x248. So hw_ptr = new_slave_hw_ptr - reference_slave_hw_ptr = 0x248 - 0x12c = 0x11c. It needs 4 more frames to be able to write. And so it goes back to waiting. But since 3 snd_pcm_period_elapsed(), 3 periods should be available and it should have been able to write. If rsnd_pointer during the start was 0x120 which is 3 periods then 0x248 - 0x120 = 128 it could go on with write. Signed-off-by: Laxmi Devi <Laxmi.Devi(a)in.bosch.com> --- > On 10/29/18 16:54, Takashi Iwai wrote: > The problem is that aligning the start essentially imposes an > artificial long latency, and changes the behavior out of sudden. Now, we are only align the salve_hw_ptr which also solves our delay issue. But this change should not increase the latency because the write position is given by slave_appl_ptr. Do you see any other drawbacks? Best regards Timo diff --git a/src/pcm/pcm_dmix.c b/src/pcm/pcm_dmix.c index a6a8f3a..eaa0b0f 100644 --- a/src/pcm/pcm_dmix.c +++ b/src/pcm/pcm_dmix.c @@ -560,6 +560,8 @@ static int snd_pcm_dmix_hwsync(snd_pcm_t *pcm) static void reset_slave_ptr(snd_pcm_t *pcm, snd_pcm_direct_t *dmix) { dmix->slave_appl_ptr = dmix->slave_hw_ptr = *dmix->spcm->hw.ptr; + dmix->slave_hw_ptr = ((dmix->slave_hw_ptr / dmix->slave_period_size) + * dmix->slave_period_size); if (pcm->buffer_size > pcm->period_size * 2) return; /* If we have too litte periods, better to align the start position -- 2.7.4

3 3

[alsa-devel] [PATCH] ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size
by Takashi Sakamoto 30 Oct '18

30 Oct '18

In a former commit, PCM constraint based on LCM of SYT_INTERVAL was obsoleted with PCM rule. However, the new PCM rule brings -EINVAL in some cases that max/min values of size of buffer/period is not multiples of one of values of SYT_INTERVAL. For example, pulseaudio always fail to configure PCM substream. This commit changes strategy for the PCM rule. Although the buggy rules had a single dependency (rate from period, period from rate, rate from buffer, buffer from rate), a revised rule has double dependencies (period from period/rate, buffer from buffer/rate). A step of value is calculated with table of SYT_INTERVAL and list of available rates. This prevents interval template which brings -EINVAL to a call of snd_interval_refine(). Fixes: 5950229582bc('ALSA: firewire-lib: add PCM rules to obsolete PCM constraints based on LCM of SYT_INTERVAL') Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/amdtp-stream.c | 57 ++++++----------------------------- 1 file changed, 9 insertions(+), 48 deletions(-) diff --git a/sound/firewire/amdtp-stream.c b/sound/firewire/amdtp-stream.c index fcd965f1d69e..9be76c808fcc 100644 --- a/sound/firewire/amdtp-stream.c +++ b/sound/firewire/amdtp-stream.c @@ -146,53 +146,22 @@ static int apply_constraint_to_size(struct snd_pcm_hw_params *params, struct snd_interval *s = hw_param_interval(params, rule->var); const struct snd_interval *r = hw_param_interval_c(params, SNDRV_PCM_HW_PARAM_RATE); - struct snd_interval t = { - .min = s->min, .max = s->max, .integer = 1, - }; + struct snd_interval t = {0}; + unsigned int step = 0; int i; for (i = 0; i < CIP_SFC_COUNT; ++i) { - unsigned int rate = amdtp_rate_table[i]; - unsigned int step = amdtp_syt_intervals[i]; - - if (!snd_interval_test(r, rate)) - continue; - - t.min = roundup(t.min, step); - t.max = rounddown(t.max, step); + if (snd_interval_test(r, amdtp_rate_table[i])) + step = max(step, amdtp_syt_intervals[i]); } - if (snd_interval_checkempty(&t)) - return -EINVAL; + t.min = roundup(s->min, step); + t.max = rounddown(s->max, step); + t.integer = 1; return snd_interval_refine(s, &t); } -static int apply_constraint_to_rate(struct snd_pcm_hw_params *params, - struct snd_pcm_hw_rule *rule) -{ - struct snd_interval *r = - hw_param_interval(params, SNDRV_PCM_HW_PARAM_RATE); - const struct snd_interval *s = hw_param_interval_c(params, rule->deps[0]); - struct snd_interval t = { - .min = UINT_MAX, .max = 0, .integer = 1, - }; - int i; - - for (i = 0; i < CIP_SFC_COUNT; ++i) { - unsigned int step = amdtp_syt_intervals[i]; - unsigned int rate = amdtp_rate_table[i]; - - if (s->min % step || s->max % step) - continue; - - t.min = min(t.min, rate); - t.max = max(t.max, rate); - } - - return snd_interval_refine(r, &t); -} - /** * amdtp_stream_add_pcm_hw_constraints - add hw constraints for PCM substream * @s: the AMDTP stream, which must be initialized. @@ -250,24 +219,16 @@ int amdtp_stream_add_pcm_hw_constraints(struct amdtp_stream *s, */ err = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_SIZE, apply_constraint_to_size, NULL, + SNDRV_PCM_HW_PARAM_PERIOD_SIZE, SNDRV_PCM_HW_PARAM_RATE, -1); if (err < 0) goto end; - err = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_RATE, - apply_constraint_to_rate, NULL, - SNDRV_PCM_HW_PARAM_PERIOD_SIZE, -1); - if (err < 0) - goto end; err = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_BUFFER_SIZE, apply_constraint_to_size, NULL, + SNDRV_PCM_HW_PARAM_BUFFER_SIZE, SNDRV_PCM_HW_PARAM_RATE, -1); if (err < 0) goto end; - err = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_RATE, - apply_constraint_to_rate, NULL, - SNDRV_PCM_HW_PARAM_BUFFER_SIZE, -1); - if (err < 0) - goto end; end: return err; } -- 2.19.1

2 1

[alsa-devel] [PATCH] ALSA: ca0106: Disable IZD on SB0570 DAC to fix audio pops
by Alex Stanoev 29 Oct '18

29 Oct '18

The Creative Audigy SE (SB0570) card currently exhibits an audible pop whenever playback is stopped or resumed, or during silent periods of an audio stream. Initialise the IZD bit to the 0 to eliminate these pops. The Infinite Zero Detection (IZD) feature on the DAC causes the output to be shunted to Vcap after 2048 samples of silence. This discharges the AC coupling capacitor through the output and causes the aforementioned pop/click noise. The behaviour of the IZD bit is described on page 15 of the WM8768GEDS datasheet: "With IZD=1, applying MUTE for 1024 consecutive input samples will cause all outputs to be connected directly to VCAP. This also happens if 2048 consecutive zero input samples are applied to all 6 channels, and IZD=0. It will be removed as soon as any channel receives a non-zero input". I believe the second sentence might be referring to IZD=1 instead of IZD=0 given the observed behaviour of the card. This change should make the DAC initialisation consistent with Creative's Windows driver, as this popping persists when initialising the card in Linux and soft rebooting into Windows, but is not present on a cold boot to Windows. Signed-off-by: Alex Stanoev <alex(a)astanoev.com> --- sound/pci/ca0106/ca0106.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/ca0106/ca0106.h b/sound/pci/ca0106/ca0106.h index 04402c14cb23..9847b669cf3c 100644 --- a/sound/pci/ca0106/ca0106.h +++ b/sound/pci/ca0106/ca0106.h @@ -582,7 +582,7 @@ #define SPI_PL_BIT_R_R (2<<7) /* right channel = right */ #define SPI_PL_BIT_R_C (3<<7) /* right channel = (L+R)/2 */ #define SPI_IZD_REG 2 -#define SPI_IZD_BIT (1<<4) /* infinite zero detect */ +#define SPI_IZD_BIT (0<<4) /* infinite zero detect */ #define SPI_FMT_REG 3 #define SPI_FMT_BIT_RJ (0<<0) /* right justified mode */ -- 2.19.1

2 1

[alsa-devel] [PATCH] pcm: dmix: Align slave_hw_ptr to slave period boundary
by twischer＠de.adit-jv.com 29 Oct '18

29 Oct '18

From: Laxmi Devi <Laxmi.Devi(a)in.bosch.com> These changes are required due to the kernel commit 07b7acb51d283d8469696c906b91f1882696a4d4 ("ASoC: rsnd: update pointer more accurate") Issue is that snd_pcm_wait() goes back to waiting because the hw_ptr is not period aligned. Therefore snd_pcm_wait() will block for a longer time as required. With these rcar driver changes the exact position of the dma is returned. During snd_pcm_start they read hw_ptr as reference, and this hw_ptr is now not period aligned, and is a little ahead over the period while it is read. Therefore when the avail is calculated during snd_pcm_wait(), it is missing the avail_min by a few frames. Consider the below example: Considering the application is trying to write 0x120 frames and the period_size = 0x60, avail_min = 0x120 and buffersize = 0x360 : rsnd_pointer=0x12c -> dma pointer at the end of second write during snd_pcm_dmix_start(). Since another 0x120 buffer is available, application writes 0x120 and goes to snd_pcm_wait(). It is woken up after 3 snd_pcm_period_elapsed() to see rsnd_pointer=0x248. So hw_ptr = new_slave_hw_ptr - reference_slave_hw_ptr = 0x248 - 0x12c = 0x11c. It needs 4 more frames to be able to write. And so it goes back to waiting. But since 3 snd_pcm_period_elapsed(), 3 periods should be available and it should have been able to write. If rsnd_pointer during the start was 0x120 which is 3 periods then 0x248 - 0x120 = 128 it could go on with write. Signed-off-by: Laxmi Devi <Laxmi.Devi(a)in.bosch.com> Signed-off-by: Timo Wischer <twischer(a)de.adit-jv.com> --- We are not completely sure if this is the best approach but we had also no better idea to solve this problem (with similar CPU usage). Therefore if anyone has a better solution please feel free to describe this one. src/pcm/pcm_dmix.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/src/pcm/pcm_dmix.c b/src/pcm/pcm_dmix.c index a6a8f3a..d3e9319 100644 --- a/src/pcm/pcm_dmix.c +++ b/src/pcm/pcm_dmix.c @@ -560,11 +560,10 @@ static int snd_pcm_dmix_hwsync(snd_pcm_t *pcm) static void reset_slave_ptr(snd_pcm_t *pcm, snd_pcm_direct_t *dmix) { dmix->slave_appl_ptr = dmix->slave_hw_ptr = *dmix->spcm->hw.ptr; - if (pcm->buffer_size > pcm->period_size * 2) - return; - /* If we have too litte periods, better to align the start position - * to the period boundary so that the interrupt can be handled properly - * at the right time. + dmix->slave_hw_ptr = ((dmix->slave_hw_ptr / dmix->slave_period_size) + * dmix->slave_period_size); + /* Better to align the start position to the period boundary so that + * the interrupt can be handled properly at the right time. */ dmix->slave_appl_ptr = ((dmix->slave_appl_ptr + dmix->slave_period_size - 1) / dmix->slave_period_size) * dmix->slave_period_size; -- 2.7.4

2 1

[alsa-devel] alsaloop problems; ALSA streaming tutorial (resend)
by frederik＠ofb.net 29 Oct '18

29 Oct '18

Dear Mark (cc'ing ALSA-user, ALSA-devel) Thank you for your tutorial http://www.pogo.org.uk/~mark/trx/streaming-desktop-audio.html I found it helpful and clearly-written (although missing a "}" brace and I think it should be "-P" instead of "-p"...). I got as far as trying the 'alsaloop' example. It seems very finicky, sometimes I am able to play a test.wav cleanly through the loopback device, and sometimes there are a lot of crackles and I get errors like playback hw:0: change avail_min=2968 playback hw:0: change avail_min=2972 playback hw:0: change avail_min=2976 underrun for playback hw:0 last write before 9.8370ms, queued 10.0000ms/0.0000ms -> missing -0.1630ms expected 10.0000ms, processing 0.1910ms, max missing 0.0443ms last wake 0.0350ms, last check 0.0350ms, avail_min 32.0000ms max buf 40.0000ms, pfilled 0.0000ms, cfilled 10.0000ms job started before 0.0110ms For 'aplay' invocations where there are errors, it generally never recovers; the whole (10 second) wav file is played with crackles and errors being printed. I tried to figure out if this is due to some different rate settings being chosen at random with each 'aplay' invocation, but all the alsaloop debugging output looks the same between working and non-working runs of aplay (except for the above underrun errors). I also tried various settings for -A and -S in 'alsaloop', but nothing would alleviate this problem. The only thing that fixes it is to change the latency '-t' setting to a higher value than the default 10ms. However this seems like a bad solution, given that it is able (50% of the time) to play a whole sound file at the lower latency with no errors; I would rather have it recover from the underruns when they happen, than increase the latency for every invocation. Enabling realtime via the Arch Wiki info (a bit tricky as I had to edit some of the files by hand) didn't change this behavior. I also encountered a problem when trying to make alsaloop output to a dmix device. I wanted to have it output to dmix so that I could use my audio normally while experimenting with alsaloop. I got a "Poll FD initialization failed." error: playback plug:hw0mix/capture hubcap sync type: CAPTRATESHIFT New pitch for playback plug:hw0mix/capture hubcap: 1.00000000 (min/max samples = 0/0) underrun for playback plug:hw0mix last write before 19.7440ms, queued -1.0000ms/-1.0000ms -> missing -1.0000ms expected 10.0000ms, processing 0.0290ms, max missing 0.0000ms last wake 1539883911239.1819ms, last check 19.6460ms, avail_min 2.5000ms max buf 250.0000ms, pfilled 0.0000ms, cfilled 0.0000ms job started before 0.0310ms Poll FD initialization failed. Is this error understood? I would have thought that enough others would also have been wanting to use alsaloop in such a simple configuration, to warrant a better error message. I'm somewhat confused by the alsaloop manual page, my version says it is from "5 Aug 2010" but it has glaring errors, it says "-B" is a synonym for "--buffer" but alsaloop tells me "alsaloop: invalid option -- 'B'". Also it says that I can use "-c" to set both channels and rate. Are these typos really unfixed for eight years? Here are the commands I used: $ alsaloop -C hubcap -P hw:0 -v -v -U |& tee alsaloloop.out ... $ aplay -v test.wav |& tee aplay.out ... $ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version k4.14.71-1-lts. The earlier version of this email had output files attached, but they caused the message to be held for "moderator approval". Here are some HTTP versions of the same files: alsaloop.out: http://ix.io/1pUj aplay.out: http://ix.io/1pUk asound-remote (the config): http://ix.io/1pUl I think I'll investigate network audio with JACK next but I wanted to share my experiences in case there is something I'm doing wrong here, or in case there are bugs that can be fixed in ALSA. Thank you, Frederick

2 2

Re: [alsa-devel] [linux-sunxi] [BUG] On Allwinner A20 Board Cubietruck distorted SPDIF opical output
by Markus Mitsch 28 Oct '18

28 Oct '18

hi. i posted my answer wrong so here is my finding: i made the output work by disabling the sigma delta modulation. after compiling the kernel i can output through spdif with any rate. greetings markus 2018-05-26 18:38 GMT+02:00 Markus Mitsch <markusmitsch86(a)googlemail.com>: > 2018-05-26 16:57 GMT+02:00 Markus Mitsch <markusmitsch86(a)googlemail.com>: >> 2018-05-23 17:12 GMT+02:00 Code Kipper <codekipper(a)gmail.com>: >>> Hi All, >>> I can see that the problem was introduced somewhere here >>> >>> DOESN'T WORK >>> ffc3eb6f3a83 Merge tag 'sunxi-clk-for-4.15' of >>> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into >>> clk-next >>> ae74ac082886 Merge tag 'clk-v4.15-exynos-pm' of >>> git://git.kernel.org/pub/scm/linux/kernel/git/snawrocki/clk into >>> clk-next >>> faa865f18cb7 Merge tag 'clk-v4.15-samsung' of >>> git://git.kernel.org/pub/scm/linux/kernel/git/snawrocki/clk into >>> clk-next >>> f09a6b86fdae Merge tag 'clk-renesas-for-v4.15-tag1' of >>> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers >>> into clk-next >>> 4328a2186e51 clk: sunxi-ng: sun4i: Export video PLLs >>> 553c7d5ba2fe clk: sunxi-ng: Add A83T display clocks >>> 7679eb20353d clk: samsung: Add a separate driver for Exynos4412 ISP clocks >>> 8ca8ac102484 clk: samsung: Add dt bindings for Exynos4412 ISP clock controller >>> 75920aac275a clk: samsung: Instantiate Exynos4412 ISP clocks only when available >>> 24ea78a09f89 clk: sunxi-ng: sun8i: a23: Use sigma-delta modulation for audio PLL >>> ee6501d69217 clk: sunxi-ng: sun6i: Use sigma-delta modulation for audio PLL >>> 042f7f8f9715 clk: sunxi-ng: sun5i: Use sigma-delta modulation for audio PLL >>> de3448519194 clk: sunxi-ng: sun4i: Use sigma-delta modulation for audio PLL >>> a5e3e2b2ef85 clk: sunxi-ng: sun8i: h3: Use sigma-delta modulation for audio PLL >>> 392ba5fafcdf clk: sunxi-ng: nm: Add support for sigma-delta modulation >>> 05d2eaac96d4 clk: sunxi-ng: Add sigma-delta modulation support >>> 4cdbc40d64d4 clk: sunxi-ng: nm: Check if requested rate is supported >>> by fractional clock >>> d51fe3ba9773 clk: sunxi-ng: sun5i: Fix bit offset of audio PLL post-divider >>> 4e8975cbb516 clk: samsung: exynos5433: mark PM functions as __maybe_unused >>> a4f21e9ceb5c clk: samsung: Remove obsolete clkdev alias support >>> 45d882daf88a clk: samsung: Add explicit MPLL, EPLL clkdev aliases in >>> S3C2443 driver >>> cd05417f728b clk: samsung: Rework clkdev alias handling in S3C2443 driver >>> efea8d377184 clk: samsung: Rework clkdev alias handling in Exynos5440 driver >>> 36ba48240b19 clk: samsung: Drop useless alias in Exynos5420 clk driver >>> 29964890f31c clk: samsung: Remove clkdev alias support in Exynos5250 clk driver >>> 6de08891c896 clk: samsung: Remove double assignment of CLK_ARM_CLK in >>> Exynos4 driver >>> 58f4a5ff3a62 clk: samsung: Remove clkdev alias support in Exynos4 clk driver >>> c9194fb623b0 clk: samsung: Remove support for obsolete Exynos4212 CPU clock >>> d5cd103b06f9 clk: samsung: Remove support for Exynos4212 SoCs in >>> Exynos CLKOUT driver >>> 7c4f63ec94a1 clk: sunxi-ng: a83t: Fix invalid csi-mclk mux offset >>> WORKS >>> 0a4e632b6f9d Merge branch 'clk-fixes' into clk-next >>> >>> BR, >>> CK >>> >>> >>> On 22 May 2018 at 21:27, Code Kipper <codekipper(a)gmail.com> wrote: >>>> Hi Markus, >>>> I've been able to reproduce this on my A31 board with linux-next(plays >>>> at 44100 but not at 96K)so it is an issue. I also tested the same code >>>> on my A64 and it worked fine, The blocks are very similar so it maybe >>>> a clocking issue, I'll look into this. >>>> BR, >>>> CK >>>> >>>> On 21 May 2018 at 20:17, Markus Mitsch <markusmitsch86(a)googlemail.com> wrote: >>>>> 2018-05-21 15:17 GMT+02:00 Maxime Ripard <maxime.ripard(a)bootlin.com>: >>>>>> On Mon, May 21, 2018 at 02:43:55PM +0200, Markus Mitsch wrote: >>>>>>> 2018-05-21 11:43 GMT+02:00 Markus Mitsch <markusmitsch86(a)googlemail.com>: >>>>>>> >>> Hello, >>>>>>> >>> >>>>>>> >>> i have a new problem. if i want to output sound from optical i get >>>>>>> >>> distorted sound. At 44.1 khz its like an old vinly, but at 48 khz and >>>>>>> >>> higher it is very bad. thanks in advance for your time. >>>>>>> > >>>>>>> >> Hi Markus, >>>>>>> >> I haven't tested it for a while but when I did it worked as high as >>>>>>> >> 96K with no issues. Does it work ok with the original cubietruck >>>>>>> >> software?, >>>>>>> >> CK >>>>>>> > >>>>>>> > Hello, >>>>>>> > i am using arch linux with mainline kernel 4.16.8. parhaps i can try >>>>>>> > today with official image. >>>>>>> > mfg >>>>>>> >>>>>>> Hi. >>>>>>> So, with debian image from 2014 with 3.4.79 kernel the sound is clear >>>>>>> up to 96 khz. >>>>>> >>>>>> You said that it is a new problem, when was it introduced? Could you >>>>>> bisect the issue? >>>>>> >>>>>> Maxime >>>>> >>>>> Hello. >>>>> I dont know since when this problem appears. When saying "new" i >>>>> refered to my older post. I tried to look into the dts file and the >>>>> code >>>>> but i am afraid this is a bit too high for me. I can say that the >>>>> analog output works, even at high sampling rates. >>>>> And I have read something about a clock source could be the problem. >>>>> I'm sorry I can't tell you any more. >>>>> >>>>> mfg >>>>> Markus >> >> Hello, >> i tried undoing part of the commit >> de3448519194 clk: sunxi-ng: sun4i: Use sigma-delta modulation for audio PLL >> by setting the value for the divider from 1 to 4 again on both places. >> with no success. >> >> markus > > i now had a little success. the output works!! > i disabled the sigma-delta support by making > ccu_sdm_helper_enable in drivers/clk/sunxi-ng/ccu_sdm.c return imediately. > > markus

2 2

[alsa-devel] [PATCH] ALSA: dice: fix to wait for releases of all ALSA character devices
by Takashi Sakamoto 27 Oct '18

27 Oct '18

In a development period for Linux kernel v4.20, drivers in ALSA firewire stack were changed to wait for releases of all ALSA character devices at .remove callback of bus driver. However, ALSA dice driver is partly out of this change. This bug can bring fault to user process which holds the last of character device in unplugging. This commit fixes the driver to wait in the callback. Fixes: 61ccc6f6b27c ('ALSA: firewire: block .remove callback of bus driver till all of ALSA character devices are released') Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/dice/dice.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/firewire/dice/dice.c b/sound/firewire/dice/dice.c index 0f6dbcffe711..ed50b222d36e 100644 --- a/sound/firewire/dice/dice.c +++ b/sound/firewire/dice/dice.c @@ -240,8 +240,8 @@ static void dice_remove(struct fw_unit *unit) cancel_delayed_work_sync(&dice->dwork); if (dice->registered) { - /* No need to wait for releasing card object in this context. */ - snd_card_free_when_closed(dice->card); + // Block till all of ALSA character devices are released. + snd_card_free(dice->card); } mutex_destroy(&dice->mutex); -- 2.19.1

2 1