[RFC PATCH (alsa-lib)] pcm: Modify check condition in snd_pcm_sw_params_set_avail_min

[RFC PATCH (alsa-lib)] pcm: Modify check condition in snd_pcm_sw_params_set_avail_min

[Koro Chen]

When we use a ping-ping buffer in capture, and if hw_ptr reported
at IRQ is a little smaller than period_size:

|xxxxxxxxxxxxxxxxxxxxxxxxxxxx--|-----------------------------|
                            hw_ptr < period_size

This available buffer will not be read since its size is smaller than
avail_min (which is set to be period_size), and read thread continues
to sleep. If the next hw_ptr is just a little larger than buffer_size,
overrun occurs.

This could be resolved by setting a small avail_min to kernel,
for example, 1, so read thread wakes up and reads every data at IRQ.
But current alsa-lib only allows avail_min to be at least period_size.
Remove the constraint and only check for zero case.

Signed-off-by: Koro Chen <koro.chen@mediatek.com>
---
 src/pcm/pcm.c |    8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c
index f5fc728..8492689 100644
--- a/src/pcm/pcm.c
+++ b/src/pcm/pcm.c
@@ -5958,12 +5958,8 @@ int snd_pcm_sw_params_set_avail_min(snd_pcm_t *pcm, snd_pcm_sw_params_t *params,
 #endif
 {
 	assert(pcm && params);
-	/* Fix avail_min if it's below period size.  The period_size
-	 * defines the minimal wake-up timing accuracy, so it doesn't
-	 * make sense to set below that.
-	 */
-	if (val < pcm->period_size)
-		val = pcm->period_size;
+	if (!val)
+		val = 1;
 	params->avail_min = val;
 	return 0;
 }
-- 
1.7.9.5

Re: [RFC PATCH (alsa-lib)] pcm: Modify check condition in snd_pcm_sw_params_set_avail_min

[Takashi Iwai]

On Thu, 03 Sep 2015 05:20:54 +0200,
Koro Chen wrote:
> 
> When we use a ping-ping buffer in capture, and if hw_ptr reported
> at IRQ is a little smaller than period_size:
> 
> |xxxxxxxxxxxxxxxxxxxxxxxxxxxx--|-----------------------------|
>                             hw_ptr < period_size

How this happens?  The period size is the size where irq (or wakeup)
wakes up for read/write.  Why the driver wakes up even if there is no
enough data?

> This available buffer will not be read since its size is smaller than
> avail_min (which is set to be period_size), and read thread continues
> to sleep. If the next hw_ptr is just a little larger than buffer_size,
> overrun occurs.
> 
> This could be resolved by setting a small avail_min to kernel,
> for example, 1, so read thread wakes up and reads every data at IRQ.
> But current alsa-lib only allows avail_min to be at least period_size.
> Remove the constraint and only check for zero case.

The restriction was introduced for avoiding CPU hogs with rate plugin
in many years ago.  avail_min=1 *might* work now because of the later
fix for rate plugin, but this must be verified.


thanks,

Takashi

> 
> Signed-off-by: Koro Chen <koro.chen@mediatek.com>
> ---
>  src/pcm/pcm.c |    8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c
> index f5fc728..8492689 100644
> --- a/src/pcm/pcm.c
> +++ b/src/pcm/pcm.c
> @@ -5958,12 +5958,8 @@ int snd_pcm_sw_params_set_avail_min(snd_pcm_t *pcm, snd_pcm_sw_params_t *params,
>  #endif
>  {
>  	assert(pcm && params);
> -	/* Fix avail_min if it's below period size.  The period_size
> -	 * defines the minimal wake-up timing accuracy, so it doesn't
> -	 * make sense to set below that.
> -	 */
> -	if (val < pcm->period_size)
> -		val = pcm->period_size;
> +	if (!val)
> +		val = 1;
>  	params->avail_min = val;
>  	return 0;
>  }
> -- 
> 1.7.9.5
> 

Re: [RFC PATCH (alsa-lib)] pcm: Modify check condition in snd_pcm_sw_params_set_avail_min

[Koro Chen]

On Thu, 2015-09-03 at 09:08 +0200, Takashi Iwai wrote:
> On Thu, 03 Sep 2015 05:20:54 +0200,
> Koro Chen wrote:
> > 
> > When we use a ping-ping buffer in capture, and if hw_ptr reported
> > at IRQ is a little smaller than period_size:
> > 
> > |xxxxxxxxxxxxxxxxxxxxxxxxxxxx--|-----------------------------|
> >                             hw_ptr < period_size
> 
> How this happens?  The period size is the size where irq (or wakeup)
> wakes up for read/write.  Why the driver wakes up even if there is no
> enough data?
> 
Yes it is odd to what we would normally expect. Due to our HW design,
when irq comes, audio HW actually has collected a full period of data,
but there is a buffer between the audio HW and memory, so at that moment
some samples are still in the buffer, not on the memory. Add a small
delay between triggering capture HW and enabling IRQ can also fix this,
although I think changing the avail_min should be better. 

> > This available buffer will not be read since its size is smaller than
> > avail_min (which is set to be period_size), and read thread continues
> > to sleep. If the next hw_ptr is just a little larger than buffer_size,
> > overrun occurs.
> > 
> > This could be resolved by setting a small avail_min to kernel,
> > for example, 1, so read thread wakes up and reads every data at IRQ.
> > But current alsa-lib only allows avail_min to be at least period_size.
> > Remove the constraint and only check for zero case.
> 
> The restriction was introduced for avoiding CPU hogs with rate plugin
> in many years ago.  avail_min=1 *might* work now because of the later
> fix for rate plugin, but this must be verified.
> 
Sounds a little dangerous...How should I verify this? It this problem
platform dependent?
> 
> thanks,
> 
> Takashi
> 
> > 
> > Signed-off-by: Koro Chen <koro.chen@mediatek.com>
> > ---
> >  src/pcm/pcm.c |    8 ++------
> >  1 file changed, 2 insertions(+), 6 deletions(-)
> > 
> > diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c
> > index f5fc728..8492689 100644
> > --- a/src/pcm/pcm.c
> > +++ b/src/pcm/pcm.c
> > @@ -5958,12 +5958,8 @@ int snd_pcm_sw_params_set_avail_min(snd_pcm_t *pcm, snd_pcm_sw_params_t *params,
> >  #endif
> >  {
> >  	assert(pcm && params);
> > -	/* Fix avail_min if it's below period size.  The period_size
> > -	 * defines the minimal wake-up timing accuracy, so it doesn't
> > -	 * make sense to set below that.
> > -	 */
> > -	if (val < pcm->period_size)
> > -		val = pcm->period_size;
> > +	if (!val)
> > +		val = 1;
> >  	params->avail_min = val;
> >  	return 0;
> >  }
> > -- 
> > 1.7.9.5
> > 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [RFC PATCH (alsa-lib)] pcm: Modify check condition in snd_pcm_sw_params_set_avail_min

[Clemens Ladisch]

Koro Chen wrote:
> On Thu, 2015-09-03 at 09:08 +0200, Takashi Iwai wrote:
>> On Thu, 03 Sep 2015 05:20:54 +0200,
>> Koro Chen wrote:
>>> When we use a ping-ping buffer in capture, and if hw_ptr reported
>>> at IRQ is a little smaller than period_size:
>>>
>>> |xxxxxxxxxxxxxxxxxxxxxxxxxxxx--|-----------------------------|
>>>                             hw_ptr < period_size
>>
>> How this happens?  The period size is the size where irq (or wakeup)
>> wakes up for read/write.  Why the driver wakes up even if there is no
>> enough data?
>
> Yes it is odd to what we would normally expect. Due to our HW design,
> when irq comes, audio HW actually has collected a full period of data,
> but there is a buffer between the audio HW and memory, so at that moment
> some samples are still in the buffer, not on the memory.

Please note that ALSA (both the kernel and the userspace API) requires
that after a period interrupt, the _complete_ period has been read from/
written to the memory buffer.  This is needed because the interrupt is
the mechanism that synchronizes software and the DMA controller.
(Except when using the NO_PERIOD_WAKUP flag, but you cannot rely on the
software using it.)


Typically, any buffering is done inside the DMA controller, which also
issues interrupts, so this problem should not happen with correctly
working hardware.

(On PCI systems, writes to system memory can be buffered, but if the
interrupt handler does a read from a device register, the PCI memory
ordering rules ensure that all DMA accesses started before the interrupt
are finished before the read.)


How does your hardware work?  I guess that whatever component does the
buffering is independent of the component that generates interrupts, and
it does not enforce any memory ordering either?  And there isn't
a mechanism to flush the buffer?


Regards,
Clemens

Re: [alsa-devel] [RFC PATCH (alsa-lib)] pcm: Modify check condition in snd_pcm_sw_params_set_avail_min

[Koro Chen]

On Thu, 2015-09-03 at 10:14 +0200, Clemens Ladisch wrote:
> Koro Chen wrote:
> > On Thu, 2015-09-03 at 09:08 +0200, Takashi Iwai wrote:
> >> On Thu, 03 Sep 2015 05:20:54 +0200,
> >> Koro Chen wrote:
> >>> When we use a ping-ping buffer in capture, and if hw_ptr reported
> >>> at IRQ is a little smaller than period_size:
> >>>
> >>> |xxxxxxxxxxxxxxxxxxxxxxxxxxxx--|-----------------------------|
> >>>                             hw_ptr < period_size
> >>
> >> How this happens?  The period size is the size where irq (or wakeup)
> >> wakes up for read/write.  Why the driver wakes up even if there is no
> >> enough data?
> >
> > Yes it is odd to what we would normally expect. Due to our HW design,
> > when irq comes, audio HW actually has collected a full period of data,
> > but there is a buffer between the audio HW and memory, so at that moment
> > some samples are still in the buffer, not on the memory.
> 
> Please note that ALSA (both the kernel and the userspace API) requires
> that after a period interrupt, the _complete_ period has been read from/
> written to the memory buffer.  This is needed because the interrupt is
> the mechanism that synchronizes software and the DMA controller.
> (Except when using the NO_PERIOD_WAKUP flag, but you cannot rely on the
> software using it.)
> 
> 
> Typically, any buffering is done inside the DMA controller, which also
> issues interrupts, so this problem should not happen with correctly
> working hardware.
> 
> (On PCI systems, writes to system memory can be buffered, but if the
> interrupt handler does a read from a device register, the PCI memory
> ordering rules ensure that all DMA accesses started before the interrupt
> are finished before the read.)
> 
> 
> How does your hardware work?  I guess that whatever component does the
> buffering is independent of the component that generates interrupts, and
> it does not enforce any memory ordering either?  And there isn't
> a mechanism to flush the buffer?
> 
Yes, your guess is correct...our IRQ hardware is just a separated timer
which is not related to any memory control. I am not sure if there is
any way to manipulate the buffer and I will check it. Thanks for your
advice! 
> 
> Regards,
> Clemens
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [RFC PATCH (alsa-lib)] pcm: Modify check condition in snd_pcm_sw_params_set_avail_min

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 872 bytes --]

On Thu, Sep 03, 2015 at 03:45:46PM +0800, Koro Chen wrote:
> On Thu, 2015-09-03 at 09:08 +0200, Takashi Iwai wrote:

> > How this happens?  The period size is the size where irq (or wakeup)
> > wakes up for read/write.  Why the driver wakes up even if there is no
> > enough data?

> Yes it is odd to what we would normally expect. Due to our HW design,
> when irq comes, audio HW actually has collected a full period of data,
> but there is a buffer between the audio HW and memory, so at that moment
> some samples are still in the buffer, not on the memory. Add a small
> delay between triggering capture HW and enabling IRQ can also fix this,
> although I think changing the avail_min should be better. 

This does sound like something that should be handled in the kernel -
one thing we should be doing is providing a uniform interface to
userspace.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC PATCH (alsa-lib)] pcm: Modify check condition in snd_pcm_sw_params_set_avail_min

[Koro Chen]

On Thu, 2015-09-03 at 10:38 +0100, Mark Brown wrote:
> On Thu, Sep 03, 2015 at 03:45:46PM +0800, Koro Chen wrote:
> > On Thu, 2015-09-03 at 09:08 +0200, Takashi Iwai wrote:
> 
> > > How this happens?  The period size is the size where irq (or wakeup)
> > > wakes up for read/write.  Why the driver wakes up even if there is no
> > > enough data?
> 
> > Yes it is odd to what we would normally expect. Due to our HW design,
> > when irq comes, audio HW actually has collected a full period of data,
> > but there is a buffer between the audio HW and memory, so at that moment
> > some samples are still in the buffer, not on the memory. Add a small
> > delay between triggering capture HW and enabling IRQ can also fix this,
> > although I think changing the avail_min should be better. 
> 
> This does sound like something that should be handled in the kernel -
> one thing we should be doing is providing a uniform interface to
> userspace.
Hmm, I thought those param settings are used to handle different HW
behavior like my case, but maybe I am wrong. It is more important to let
a single driver to be used under many different cases. I will find
solution in my driver, thank you!

Re: [RFC PATCH (alsa-lib)] pcm: Modify check condition in snd_pcm_sw_params_set_avail_min

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 907 bytes --]

On Fri, Sep 04, 2015 at 10:49:35AM +0800, Koro Chen wrote:
> On Thu, 2015-09-03 at 10:38 +0100, Mark Brown wrote:

> > This does sound like something that should be handled in the kernel -
> > one thing we should be doing is providing a uniform interface to
> > userspace.

> Hmm, I thought those param settings are used to handle different HW
> behavior like my case, but maybe I am wrong. It is more important to let
> a single driver to be used under many different cases. I will find
> solution in my driver, thank you!

Yes, the params do generally handle things that differ between systems
(mostly things like buffer sizes, formats and so on) but there's a few
things that are pretty much required, one of them being delivering the
period elapsed notifiations when a period has actually elapsed rather
than before then.  Setting a very small period size will tend to mask
problems but it's not great.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]