[alsa-devel] [PATCH 0/3] ASoC: omap-mcbsp: fixes for some underflow problems
With these series I'm trying to deal with underflow problems I was complaining about earlier. This mostly tries to get minimum period size large enough for things to work.
To illustrate the problems I wrote a testcase with alsalib, hopefully it shows the problem more clearly: http://notaz.gp2x.de/misc/alsa_period_test.c
Applies on top of mcbsp move series.
Grazvydas Ignotas (3): ASoC: omap-mcbsp: fix snd_pcm_hw_rule_add arguments ASoC: omap-mcbsp: place size constrain on period, not buffer ASoC: omap-mcbsp: make minimum period size larger than FIFO
sound/soc/omap/omap-mcbsp.c | 31 +++++++++++++++++++++---------- 1 files changed, 21 insertions(+), 10 deletions(-)
We are setting SNDRV_PCM_HW_PARAM_BUFFER_SIZE based on SNDRV_PCM_HW_PARAM_CHANNELS, not vice versa. This bug didn't have much impact because the rules are evaluated multiple times by the core, and intended value got set eventually.
Signed-off-by: Grazvydas Ignotas notasas@gmail.com --- sound/soc/omap/omap-mcbsp.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 10eb645..207365c 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -142,10 +142,10 @@ static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream, * smaller buffer than the FIFO size to avoid underruns */ snd_pcm_hw_rule_add(substream->runtime, 0, - SNDRV_PCM_HW_PARAM_CHANNELS, + SNDRV_PCM_HW_PARAM_BUFFER_SIZE, omap_mcbsp_hwrule_min_buffersize, mcbsp, - SNDRV_PCM_HW_PARAM_BUFFER_SIZE, -1); + SNDRV_PCM_HW_PARAM_CHANNELS, -1);
/* Make sure, that the period size is always even */ snd_pcm_hw_constraint_step(substream->runtime, 0,
On 03/09/2012 01:19 AM, Grazvydas Ignotas wrote:
We are setting SNDRV_PCM_HW_PARAM_BUFFER_SIZE based on SNDRV_PCM_HW_PARAM_CHANNELS, not vice versa.
The intention is to set the buffer size based on the channels here. This is needed because of the McBSP internal FIFO operation. It is word based. As example on McBSP2 has 1280 word FIFO. In mono stream it is 1280 sample long. In stereo it is 640 (stereo) sample long. In four channel mode it is 320 (4 channel) sample long.
This bug didn't have much impact because the rules are evaluated multiple times by the core, and intended value got set eventually.
Signed-off-by: Grazvydas Ignotas notasas@gmail.com
sound/soc/omap/omap-mcbsp.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 10eb645..207365c 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -142,10 +142,10 @@ static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream, * smaller buffer than the FIFO size to avoid underruns */ snd_pcm_hw_rule_add(substream->runtime, 0,
SNDRV_PCM_HW_PARAM_CHANNELS,
SNDRV_PCM_HW_PARAM_BUFFER_SIZE, omap_mcbsp_hwrule_min_buffersize, mcbsp,
SNDRV_PCM_HW_PARAM_BUFFER_SIZE, -1);
SNDRV_PCM_HW_PARAM_CHANNELS, -1);/* Make sure, that the period size is always even */ snd_pcm_hw_constraint_step(substream->runtime, 0,
On Fri, Mar 9, 2012 at 12:08 PM, Peter Ujfalusi peter.ujfalusi@ti.com wrote:
On 03/09/2012 01:19 AM, Grazvydas Ignotas wrote:
We are setting SNDRV_PCM_HW_PARAM_BUFFER_SIZE based on SNDRV_PCM_HW_PARAM_CHANNELS, not vice versa.
The intention is to set the buffer size based on the channels here. This is needed because of the McBSP internal FIFO operation. It is word based. As example on McBSP2 has 1280 word FIFO. In mono stream it is 1280 sample long. In stereo it is 640 (stereo) sample long. In four channel mode it is 320 (4 channel) sample long.
That's all fine, but the argument order is wrong, take a look at snd_pcm_hw_rule_add definition:
/** * snd_pcm_hw_rule_add - add the hw-constraint rule * @var: the variable to evaluate * @dep: the dependent variables int snd_pcm_hw_rule_add(struct snd_pcm_runtime *runtime, unsigned int cond, int var, snd_pcm_hw_rule_func_t func, void *private, int dep, ...)
So var should be SNDRV_PCM_HW_PARAM_BUFFER_SIZE, dep SNDRV_PCM_HW_PARAM_CHANNELS, but it is the opposite now.
This bug didn't have much impact because the rules are evaluated multiple times by the core, and intended value got set eventually.
Signed-off-by: Grazvydas Ignotas notasas@gmail.com
sound/soc/omap/omap-mcbsp.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 10eb645..207365c 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -142,10 +142,10 @@ static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream, * smaller buffer than the FIFO size to avoid underruns */ snd_pcm_hw_rule_add(substream->runtime, 0,
- SNDRV_PCM_HW_PARAM_CHANNELS,
- SNDRV_PCM_HW_PARAM_BUFFER_SIZE,
omap_mcbsp_hwrule_min_buffersize, mcbsp,
- SNDRV_PCM_HW_PARAM_BUFFER_SIZE, -1);
- SNDRV_PCM_HW_PARAM_CHANNELS, -1);
/* Make sure, that the period size is always even */ snd_pcm_hw_constraint_step(substream->runtime, 0,
On 03/09/2012 12:45 PM, Grazvydas Ignotas wrote:
That's all fine, but the argument order is wrong, take a look at snd_pcm_hw_rule_add definition:
/**
- snd_pcm_hw_rule_add - add the hw-constraint rule
- @var: the variable to evaluate
- @dep: the dependent variables
True.
On 03/09/2012 01:19 AM, Grazvydas Ignotas wrote:
We are setting SNDRV_PCM_HW_PARAM_BUFFER_SIZE based on SNDRV_PCM_HW_PARAM_CHANNELS, not vice versa. This bug didn't have much impact because the rules are evaluated multiple times by the core, and intended value got set eventually.
Signed-off-by: Grazvydas Ignotas notasas@gmail.com
Acked-by: Peter Ujfalusi peter.ujfalusi@ti.com
On Fri, Mar 09, 2012 at 01:19:15AM +0200, Grazvydas Ignotas wrote:
We are setting SNDRV_PCM_HW_PARAM_BUFFER_SIZE based on SNDRV_PCM_HW_PARAM_CHANNELS, not vice versa. This bug didn't have much impact because the rules are evaluated multiple times by the core, and intended value got set eventually.
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
Placing a constraint on buffer size is not enough, programs are still free to use periods that are smaller than FIFO, which causes transmit underflows as soon as the stream starts if program operates in period-sized writes, ending up in endless loop of underruns.
Signed-off-by: Grazvydas Ignotas notasas@gmail.com --- sound/soc/omap/omap-mcbsp.c | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 207365c..b9d1272 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -93,11 +93,11 @@ static void omap_mcbsp_set_threshold(struct snd_pcm_substream *substream) omap_mcbsp_set_rx_threshold(mcbsp, words); }
-static int omap_mcbsp_hwrule_min_buffersize(struct snd_pcm_hw_params *params, - struct snd_pcm_hw_rule *rule) +static int omap_mcbsp_hwrule_min_period_size(struct snd_pcm_hw_params *params, + struct snd_pcm_hw_rule *rule) { - struct snd_interval *buffer_size = hw_param_interval(params, - SNDRV_PCM_HW_PARAM_BUFFER_SIZE); + struct snd_interval *period_size = hw_param_interval(params, + SNDRV_PCM_HW_PARAM_PERIOD_SIZE); struct snd_interval *channels = hw_param_interval(params, SNDRV_PCM_HW_PARAM_CHANNELS); struct omap_mcbsp *mcbsp = rule->private; @@ -109,7 +109,7 @@ static int omap_mcbsp_hwrule_min_buffersize(struct snd_pcm_hw_params *params,
frames.min = size / channels->min; frames.integer = 1; - return snd_interval_refine(buffer_size, &frames); + return snd_interval_refine(period_size, &frames); }
static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream, @@ -138,12 +138,12 @@ static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream, */ if (mcbsp->pdata->buffer_size) { /* - * Rule for the buffer size. We should not allow - * smaller buffer than the FIFO size to avoid underruns + * Rule for the period size. We should not allow + * smaller period than the FIFO size to avoid underruns */ snd_pcm_hw_rule_add(substream->runtime, 0, - SNDRV_PCM_HW_PARAM_BUFFER_SIZE, - omap_mcbsp_hwrule_min_buffersize, + SNDRV_PCM_HW_PARAM_PERIOD_SIZE, + omap_mcbsp_hwrule_min_period_size, mcbsp, SNDRV_PCM_HW_PARAM_CHANNELS, -1);
On Fri, Mar 09, 2012 at 01:19:16AM +0200, Grazvydas Ignotas wrote:
Placing a constraint on buffer size is not enough, programs are still free to use periods that are smaller than FIFO, which causes transmit underflows as soon as the stream starts if program operates in period-sized writes, ending up in endless loop of underruns.
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
With a program operating in minimum sized periods, first write will cause a transfer that will fill mcbsp FIFO quickly, and there will be no more data to DMA before program manages to do another write. As the core considers this as underflow condition, we may get many underflows at the start. Increase minimum period size by half to deal with this problem.
Signed-off-by: Grazvydas Ignotas notasas@gmail.com --- sound/soc/omap/omap-mcbsp.c | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index b9d1272..b373a0b 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -108,6 +108,17 @@ static int omap_mcbsp_hwrule_min_period_size(struct snd_pcm_hw_params *params, size = mcbsp->pdata->buffer_size;
frames.min = size / channels->min; + + /* + * If period is not larger than FIFO, it may be transfered faster than + * program operating in period sizes is able to send 2 periods, so + * underrun condition can be triggered at the beginning of stream. + * This is because underrun is triggered as soon as DMA has no more + * data to send, and we get this from the start if period is too small. + * To deal with this, set period larger than FIFO size. + */ + frames.min = frames.min + frames.min / 2; + frames.integer = 1; return snd_interval_refine(period_size, &frames); }
On Fri, Mar 09, 2012 at 01:19:17AM +0200, Grazvydas Ignotas wrote:
- frames.min = frames.min + frames.min / 2;
Call me picky but I'd like some brackets here as I had to think for a few seconds if that was (frames.min + frames.min) / 2. But
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
On 03/09/2012 01:19 AM, Grazvydas Ignotas wrote:
With a program operating in minimum sized periods, first write will cause a transfer that will fill mcbsp FIFO quickly, and there will be no more data to DMA before program manages to do another write. As the core considers this as underflow condition, we may get many underflows at the start. Increase minimum period size by half to deal with this problem.
Not entirely sure about the last two patch... The implications will be big for existing user space since we are going to limit the period size in this way (on OMAP3 McBSP2): 48K stereo: 20ms min 44.1K stereo: 21.768ms min 8K stereo: 120ms min 8K mono: 240ms min
As I recall n900 (+ MeeGo) uses 5ms period sizes in call cases on McBSP2.
So I'm a bit reluctant to ack these (it is not an issue on other McBSP ports, and on OMAP4, but OMAP3 McBSP2 is problematic IMHO).
Jarkko: What do you think?
If this is a real issue in Pandora, could it be solved with adding /etc/asound.conf to the filesystem, and limit the period size via that?
On Fri, Mar 9, 2012 at 2:42 PM, Peter Ujfalusi peter.ujfalusi@ti.com wrote:
On 03/09/2012 01:19 AM, Grazvydas Ignotas wrote:
With a program operating in minimum sized periods, first write will cause a transfer that will fill mcbsp FIFO quickly, and there will be no more data to DMA before program manages to do another write. As the core considers this as underflow condition, we may get many underflows at the start. Increase minimum period size by half to deal with this problem.
Not entirely sure about the last two patch... The implications will be big for existing user space since we are going to limit the period size in this way (on OMAP3 McBSP2): 48K stereo: 20ms min 44.1K stereo: 21.768ms min 8K stereo: 120ms min 8K mono: 240ms min
As I recall n900 (+ MeeGo) uses 5ms period sizes in call cases on McBSP2.
I would guess they are using something larger, at least larger write quantities with this kind of period, otherwise it would keep overflowing there too.
So I'm a bit reluctant to ack these (it is not an issue on other McBSP ports, and on OMAP4, but OMAP3 McBSP2 is problematic IMHO).
Maybe we could use MCBSPLP_THRSH2_REG XTHRESHOLD to artificially limit MCBSP2 fifo depth?
Jarkko: What do you think?
If this is a real issue in Pandora, could it be solved with adding /etc/asound.conf to the filesystem, and limit the period size via that?
We are already doing that, however we encourage people to install their own distros on pandora, and now they have to drag whole ALSA configuration for things to work. IMHO device driver like this must be able to work without any special userspace configuration.
On 03/09/2012 03:25 PM, Grazvydas Ignotas wrote:
I would guess they are using something larger, at least larger write quantities with this kind of period, otherwise it would keep overflowing there too.
They are using PulseAudio as with Maemmo (the product software).
So I'm a bit reluctant to ack these (it is not an issue on other McBSP ports, and on OMAP4, but OMAP3 McBSP2 is problematic IMHO).
Maybe we could use MCBSPLP_THRSH2_REG XTHRESHOLD to artificially limit MCBSP2 fifo depth?
It is not possible. The McBSP FIFO/sDMA implementation (in HW) does not allow it, unfortunately. We are using the Threshold settings in dma_op_mode == threshold: echo threshold > /sys/devices/platform/omap/omap-mcbsp.2/dma_op_mode
It is good for achieving lover power consumption during audio activity.
Jarkko: What do you think?
If this is a real issue in Pandora, could it be solved with adding /etc/asound.conf to the filesystem, and limit the period size via that?
We are already doing that, however we encourage people to install their own distros on pandora, and now they have to drag whole ALSA configuration for things to work. IMHO device driver like this must be able to work without any special userspace configuration.
We have two issues here: if you are using the element mode (dma_op_mode) you might want to have bigger period size than the FIFO size. However if you are using the threshold mode you will be fine with a period size between fifo_size/2, and fifo_size. In threshold mode we are sending the data to McBSP FIFO in bursts, and the burst size is the same as the McBSP threshold config. The McBSP will request new burst when there is free space for the next burst in the FIFO. So we can fill the FIFO to 3/4 for example, and the next burst will happen when the FIFO reaches 1/4 fill level.
You might want to try this as well to lover the period_size constraint.
But let's wait for Jarkko's take on this.
On Fri, Mar 9, 2012 at 3:42 PM, Peter Ujfalusi peter.ujfalusi@ti.com wrote:
On 03/09/2012 03:25 PM, Grazvydas Ignotas wrote:
I would guess they are using something larger, at least larger write quantities with this kind of period, otherwise it would keep overflowing there too.
They are using PulseAudio as with Maemmo (the product software).
So I'm a bit reluctant to ack these (it is not an issue on other McBSP ports, and on OMAP4, but OMAP3 McBSP2 is problematic IMHO).
Maybe we could use MCBSPLP_THRSH2_REG XTHRESHOLD to artificially limit MCBSP2 fifo depth?
It is not possible. The McBSP FIFO/sDMA implementation (in HW) does not allow it, unfortunately. We are using the Threshold settings in dma_op_mode == threshold: echo threshold > /sys/devices/platform/omap/omap-mcbsp.2/dma_op_mode
It is good for achieving lover power consumption during audio activity.
Maybe enable it by default then?
Jarkko: What do you think?
If this is a real issue in Pandora, could it be solved with adding /etc/asound.conf to the filesystem, and limit the period size via that?
We are already doing that, however we encourage people to install their own distros on pandora, and now they have to drag whole ALSA configuration for things to work. IMHO device driver like this must be able to work without any special userspace configuration.
We have two issues here: if you are using the element mode (dma_op_mode) you might want to have bigger period size than the FIFO size. However if you are using the threshold mode you will be fine with a period size between fifo_size/2, and fifo_size.
Threshold mode doesn't seem to help, I still need to go over FIFO size. From what I can see in the code it's setting the threshold to period size, so I still get underflow condition after first write, as first write goes to FIFO, DMA shows that it has nothing left to send after first write finishes.
I bet PulseAudio is setting start threshold to something way above FIFO size, which makes it work here. However you can't expect that from every program that uses ALSA directly..
In threshold mode we are sending the data to McBSP FIFO in bursts, and the burst size is the same as the McBSP threshold config. The McBSP will request new burst when there is free space for the next burst in the FIFO. So we can fill the FIFO to 3/4 for example, and the next burst will happen when the FIFO reaches 1/4 fill level.
That would work if I did first write larger than period (when it's below FIFO size) or set large enough start_threshold. However if you look at alsalib samples, they always write in period size quantities, so it's not surprising other programs do that too (alsalib samples work here though as they do set high start threshold).
You might want to try this as well to lover the period_size constraint.
But let's wait for Jarkko's take on this.
-- Péter
On Fri, 2012-03-09 at 23:07 +0200, Grazvydas Ignotas wrote:
On Fri, Mar 9, 2012 at 3:42 PM, Peter Ujfalusi peter.ujfalusi@ti.com wrote:
On 03/09/2012 03:25 PM, Grazvydas Ignotas wrote:
If this is a real issue in Pandora, could it be solved with adding /etc/asound.conf to the filesystem, and limit the period size via that?
We are already doing that, however we encourage people to install their own distros on pandora, and now they have to drag whole ALSA configuration for things to work. IMHO device driver like this must be able to work without any special userspace configuration.
I agree. What's the use case where the problem shows up? Or actually hw parameters in that use case so can it be repeated using plain aplay/arecord?
We have two issues here: if you are using the element mode (dma_op_mode) you might want to have bigger period size than the FIFO size. However if you are using the threshold mode you will be fine with a period size between fifo_size/2, and fifo_size.
Threshold mode doesn't seem to help, I still need to go over FIFO size. From what I can see in the code it's setting the threshold to period size, so I still get underflow condition after first write, as first write goes to FIFO, DMA shows that it has nothing left to send after first write finishes.
Period size smaller than FIFO size has used to work in element mode too but I think I have always used in my tests multiple periods. What I'm thinking if we have a boundary condition with 2-3 periods and where buffer size is near FIFO size.
I think instead of limiting minimum period size to FIFO size we should find that boundary condition. Like if min buffer > FIFO + 1 period or something like that in order to keep possible to use small periods.
On Sun, Mar 11, 2012 at 7:39 PM, Jarkko Nikula jarkko.nikula@bitmer.com wrote:
On Fri, 2012-03-09 at 23:07 +0200, Grazvydas Ignotas wrote:
On Fri, Mar 9, 2012 at 3:42 PM, Peter Ujfalusi peter.ujfalusi@ti.com wrote:
On 03/09/2012 03:25 PM, Grazvydas Ignotas wrote:
If this is a real issue in Pandora, could it be solved with adding /etc/asound.conf to the filesystem, and limit the period size via that?
We are already doing that, however we encourage people to install their own distros on pandora, and now they have to drag whole ALSA configuration for things to work. IMHO device driver like this must be able to work without any special userspace configuration.
I agree. What's the use case where the problem shows up?
When alsa program doesn't set high enough start_threshold and period size, or when using OSS with smaller period (start_threshold is period size there).
Or actually hw parameters in that use case so can it be repeated using plain aplay/arecord?
aplay -D hw:0 -f s16_le -c 2 --period-size=512 --start-delay=50000 /dev/urandom
note that this will only show problems on OMAP3 McBSP2 due to it's long FIFO.
We have two issues here: if you are using the element mode (dma_op_mode) you might want to have bigger period size than the FIFO size. However if you are using the threshold mode you will be fine with a period size between fifo_size/2, and fifo_size.
Threshold mode doesn't seem to help, I still need to go over FIFO size. From what I can see in the code it's setting the threshold to period size, so I still get underflow condition after first write, as first write goes to FIFO, DMA shows that it has nothing left to send after first write finishes.
Period size smaller than FIFO size has used to work in element mode too but I think I have always used in my tests multiple periods. What I'm thinking if we have a boundary condition with 2-3 periods and where buffer size is near FIFO size.
I'm not sure what boundary means in ALSA, but ASoC never touches it or start_threshold.
I think instead of limiting minimum period size to FIFO size we should find that boundary condition. Like if min buffer > FIFO + 1 period or something like that in order to keep possible to use small periods.
I was testing some hacks that force runtime->start_threshold to a bit above FIFO size with good results, however none of ASoC code ever touches it, so I guess it could be considered wrong thing to do, but it works with everything I tested so far, including OSS emulation.
On Mon, Mar 12, 2012 at 02:05:55PM +0200, Grazvydas Ignotas wrote:
On Sun, Mar 11, 2012 at 7:39 PM, Jarkko Nikula jarkko.nikula@bitmer.com wrote:
I think instead of limiting minimum period size to FIFO size we should find that boundary condition. Like if min buffer > FIFO + 1 period or something like that in order to keep possible to use small periods.
I was testing some hacks that force runtime->start_threshold to a bit above FIFO size with good results, however none of ASoC code ever touches it, so I guess it could be considered wrong thing to do, but it works with everything I tested so far, including OSS emulation.
That's more due to nothing ever particularly needing it before than due to it being a bad idea.
On 03/12/2012 02:05 PM, Grazvydas Ignotas wrote:
aplay -D hw:0 -f s16_le -c 2 --period-size=512 --start-delay=50000 /dev/urandom
note that this will only show problems on OMAP3 McBSP2 due to it's long FIFO.
There's something else here since: aplay -D hw:0 -fs16_le -c2 --period-size=320 --buffer-size=972 \ --start-delay=81000 -v /dev/urandom
Works correctly, however aplay -D hw:0 -fs16_le -c2 --period-size=324 --buffer-size=972 \ --start-delay=81000 -v /dev/urandom
produces underruns. In both cases the start_threshold is set to 648 (640 is the FIFO McBSP2 size). Both should be fine, but period_size=324 underruns.
So the issue is not that simple as it seams...
On Mon, Mar 12, 2012 at 2:41 PM, Peter Ujfalusi peter.ujfalusi@ti.com wrote:
On 03/12/2012 02:05 PM, Grazvydas Ignotas wrote:
aplay -D hw:0 -f s16_le -c 2 --period-size=512 --start-delay=50000 /dev/urandom
note that this will only show problems on OMAP3 McBSP2 due to it's long FIFO.
There's something else here since: aplay -D hw:0 -fs16_le -c2 --period-size=320 --buffer-size=972 \ --start-delay=81000 -v /dev/urandom
Works correctly, however aplay -D hw:0 -fs16_le -c2 --period-size=324 --buffer-size=972 \ --start-delay=81000 -v /dev/urandom
produces underruns. In both cases the start_threshold is set to 648 (640 is the FIFO McBSP2 size). Both should be fine, but period_size=324 underruns.
So the issue is not that simple as it seams...
Seems to be affected --stop-delay, increasing it helps here, maybe core stops it for too long.
participants (4)
-
Grazvydas Ignotas -
Jarkko Nikula -
Mark Brown -
Peter Ujfalusi