Application hangs with different period sizes

Application hangs with different period sizes

[anuj aggarwal]

My audio driver supports buffer sizes from 128 to 32768 and period sizes
from 8 to 2048. I am trying to set the period size as 1030 (just a random
number between 8 & 2048, but not multiple of 2^n) and buffer size as
16*buffer_size (i.e. 16480). The output is as follows:

Buffer size range from 128 to 32768
Period size range from 8 to 2048
Request period size 1030 and got 1030
Plug PCM: Hardware PCM card 0 'TWL4030' device 0 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 16480
  period_size  : 1030
  period_time  : 23356
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1030
  start_threshold  : 16480
  stop_threshold   : 16480
  silence_threshold: 0
  silence_size : 0
  boundary     : 1080033280

The problem with this setup is the application just hangs without playing
anything. If I use period size as 2048, the app plays the song but clips the
last part of it. If I use 1024/512, it works fine.

I have tried alsa lib version 1.0.15 & 1.0.16 but the problem persists. Is
there anything wrong with my app or audio driver?

Please help.

Thanks in advance,
Anuj Aggarwal

Re: Application hangs with different period sizes

[Gustavo da Silva Serra]

Do you check the result of the function that sets the period size? Some 
periods are not supported and you can't assume that they are valid and 
proceed in your application. Use snd_pcm_hw_params_set_period_time_near 
to see what is the nearest possible value for period. 
<http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.html#gf5e53bcb748185a4da3b8538720a5792>

anuj aggarwal escreveu:
> My audio driver supports buffer sizes from 128 to 32768 and period sizes
> from 8 to 2048. I am trying to set the period size as 1030 (just a random
> number between 8 & 2048, but not multiple of 2^n) and buffer size as
> 16*buffer_size (i.e. 16480). The output is as follows:
>
> Buffer size range from 128 to 32768
> Period size range from 8 to 2048
> Request period size 1030 and got 1030
> Plug PCM: Hardware PCM card 0 'TWL4030' device 0 subdevice 0
> Its setup is:
>   stream       : PLAYBACK
>   access       : RW_INTERLEAVED
>   format       : S16_LE
>   subformat    : STD
>   channels     : 2
>   rate         : 44100
>   exact rate   : 44100 (44100/1)
>   msbits       : 16
>   buffer_size  : 16480
>   period_size  : 1030
>   period_time  : 23356
>   tstamp_mode  : NONE
>   period_step  : 1
>   avail_min    : 1030
>   start_threshold  : 16480
>   stop_threshold   : 16480
>   silence_threshold: 0
>   silence_size : 0
>   boundary     : 1080033280
>
> The problem with this setup is the application just hangs without playing
> anything. If I use period size as 2048, the app plays the song but clips the
> last part of it. If I use 1024/512, it works fine.
>
> I have tried alsa lib version 1.0.15 & 1.0.16 but the problem persists. Is
> there anything wrong with my app or audio driver?
>
> Please help.
>
> Thanks in advance,
> Anuj Aggarwal
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
> __________ NOD32 3238 (20080703) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
>
>
>   

Re: Application hangs with different period sizes

[anuj aggarwal]

I am doing the same. I used snd_pcm_hw_params_set_period_size_near() to set
the period size and checked the return value also; it was not an error.

I have one more question. When you say 'Some periods are not supported',
what does that mean? What are the constraints which make some periods
not-supported by the audio codec driver?

On Thu, Jul 3, 2008 at 5:11 PM, Gustavo da Silva Serra <
gustavo.serra@tet.com.br> wrote:

> Do you check the result of the function that sets the period size? Some
> periods are not supported and you can't assume that they are valid and
> proceed in your application. Use snd_pcm_hw_params_set_period_time_near to
> see what is the nearest possible value for period. <
> http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.html#gf5e53bcb748185a4da3b8538720a5792
> >
>
> anuj aggarwal escreveu:
>
>> My audio driver supports buffer sizes from 128 to 32768 and period sizes
>> from 8 to 2048. I am trying to set the period size as 1030 (just a random
>> number between 8 & 2048, but not multiple of 2^n) and buffer size as
>> 16*buffer_size (i.e. 16480). The output is as follows:
>>
>> Buffer size range from 128 to 32768
>> Period size range from 8 to 2048
>> Request period size 1030 and got 1030
>> Plug PCM: Hardware PCM card 0 'TWL4030' device 0 subdevice 0
>> Its setup is:
>>  stream       : PLAYBACK
>>  access       : RW_INTERLEAVED
>>  format       : S16_LE
>>  subformat    : STD
>>  channels     : 2
>>  rate         : 44100
>>  exact rate   : 44100 (44100/1)
>>  msbits       : 16
>>  buffer_size  : 16480
>>  period_size  : 1030
>>  period_time  : 23356
>>  tstamp_mode  : NONE
>>  period_step  : 1
>>  avail_min    : 1030
>>  start_threshold  : 16480
>>  stop_threshold   : 16480
>>  silence_threshold: 0
>>  silence_size : 0
>>  boundary     : 1080033280
>>
>> The problem with this setup is the application just hangs without playing
>> anything. If I use period size as 2048, the app plays the song but clips
>> the
>> last part of it. If I use 1024/512, it works fine.
>>
>> I have tried alsa lib version 1.0.15 & 1.0.16 but the problem persists. Is
>> there anything wrong with my app or audio driver?
>>
>> Please help.
>>
>> Thanks in advance,
>> Anuj Aggarwal
>> _______________________________________________
>> Alsa-devel mailing list
>> Alsa-devel@alsa-project.org
>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>
>> __________ NOD32 3238 (20080703) Information __________
>>
>> This message was checked by NOD32 antivirus system.
>> http://www.eset.com
>>
>>
>>
>>
>>
>
>


-- 
Best Regards,
Anuj Aggarwal

Re: Application hangs with different period sizes

[Gustavo da Silva Serra]

I think that snd_pcm_hw_params_set_period_size_near() will not return an 
error, but you must check the "val" parameter, is it returning the same 
value that you passed?

"Some periods are not supported" means that some cards may not support 
periods that aren't power of two. I am not sure, since I am new to ALSA 
and I am working most with aloop.

anuj aggarwal escreveu:
> I am doing the same. I used snd_pcm_hw_params_set_period_size_near() 
> to set the period size and checked the return value also; it was not 
> an error.
>
> I have one more question. When you say 'Some periods are not 
> supported', what does that mean? What are the constraints which make 
> some periods not-supported by the audio codec driver?
>
> On Thu, Jul 3, 2008 at 5:11 PM, Gustavo da Silva Serra 
> <gustavo.serra@tet.com.br <mailto:gustavo.serra@tet.com.br>> wrote:
>
>     Do you check the result of the function that sets the period size?
>     Some periods are not supported and you can't assume that they are
>     valid and proceed in your application. Use
>     snd_pcm_hw_params_set_period_time_near to see what is the nearest
>     possible value for period.
>     <http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.html#gf5e53bcb748185a4da3b8538720a5792>
>
>     anuj aggarwal escreveu:
>
>         My audio driver supports buffer sizes from 128 to 32768 and
>         period sizes
>         from 8 to 2048. I am trying to set the period size as 1030
>         (just a random
>         number between 8 & 2048, but not multiple of 2^n) and buffer
>         size as
>         16*buffer_size (i.e. 16480). The output is as follows:
>
>         Buffer size range from 128 to 32768
>         Period size range from 8 to 2048
>         Request period size 1030 and got 1030
>         Plug PCM: Hardware PCM card 0 'TWL4030' device 0 subdevice 0
>         Its setup is:
>          stream       : PLAYBACK
>          access       : RW_INTERLEAVED
>          format       : S16_LE
>          subformat    : STD
>          channels     : 2
>          rate         : 44100
>          exact rate   : 44100 (44100/1)
>          msbits       : 16
>          buffer_size  : 16480
>          period_size  : 1030
>          period_time  : 23356
>          tstamp_mode  : NONE
>          period_step  : 1
>          avail_min    : 1030
>          start_threshold  : 16480
>          stop_threshold   : 16480
>          silence_threshold: 0
>          silence_size : 0
>          boundary     : 1080033280
>
>         The problem with this setup is the application just hangs
>         without playing
>         anything. If I use period size as 2048, the app plays the song
>         but clips the
>         last part of it. If I use 1024/512, it works fine.
>
>         I have tried alsa lib version 1.0.15 & 1.0.16 but the problem
>         persists. Is
>         there anything wrong with my app or audio driver?
>
>         Please help.
>
>         Thanks in advance,
>         Anuj Aggarwal
>         _______________________________________________
>         Alsa-devel mailing list
>         Alsa-devel@alsa-project.org <mailto:Alsa-devel@alsa-project.org>
>         http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
>         __________ NOD32 3238 (20080703) Information __________
>
>         This message was checked by NOD32 antivirus system.
>         http://www.eset.com
>
>
>
>          
>
>
>
>
>
> -- 
> Best Regards,
> Anuj Aggarwal 

Re: Application hangs with different period sizes

[anuj aggarwal]

I think the library/driver is able to configure the way user has requested.
See the logs (in my first mail) which confirm that the requested period size
has been taken for configuration.

Where can I found the limitation in the driver code/spec which says that
these period sizes are not supported? Any suggestion is most welcome...

Thanks,
Anuj

On Thu, Jul 3, 2008 at 6:30 PM, Gustavo da Silva Serra <
gustavo.serra@tet.com.br> wrote:

> I think that snd_pcm_hw_params_set_period_size_near() will not return an
> error, but you must check the "val" parameter, is it returning the same
> value that you passed?
>
> "Some periods are not supported" means that some cards may not support
> periods that aren't power of two. I am not sure, since I am new to ALSA and
> I am working most with aloop.
>
> anuj aggarwal escreveu:
>
>> I am doing the same. I used snd_pcm_hw_params_set_period_size_near() to
>> set the period size and checked the return value also; it was not an error.
>>
>> I have one more question. When you say 'Some periods are not supported',
>> what does that mean? What are the constraints which make some periods
>> not-supported by the audio codec driver?
>>
>> On Thu, Jul 3, 2008 at 5:11 PM, Gustavo da Silva Serra <
>> gustavo.serra@tet.com.br <mailto:gustavo.serra@tet.com.br>> wrote:
>>
>>    Do you check the result of the function that sets the period size?
>>    Some periods are not supported and you can't assume that they are
>>    valid and proceed in your application. Use
>>    snd_pcm_hw_params_set_period_time_near to see what is the nearest
>>    possible value for period.
>>    <
>> http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.html#gf5e53bcb748185a4da3b8538720a5792
>> >
>>
>>    anuj aggarwal escreveu:
>>
>>        My audio driver supports buffer sizes from 128 to 32768 and
>>        period sizes
>>        from 8 to 2048. I am trying to set the period size as 1030
>>        (just a random
>>        number between 8 & 2048, but not multiple of 2^n) and buffer
>>        size as
>>        16*buffer_size (i.e. 16480). The output is as follows:
>>
>>        Buffer size range from 128 to 32768
>>        Period size range from 8 to 2048
>>        Request period size 1030 and got 1030
>>        Plug PCM: Hardware PCM card 0 'TWL4030' device 0 subdevice 0
>>        Its setup is:
>>         stream       : PLAYBACK
>>         access       : RW_INTERLEAVED
>>         format       : S16_LE
>>         subformat    : STD
>>         channels     : 2
>>         rate         : 44100
>>         exact rate   : 44100 (44100/1)
>>         msbits       : 16
>>         buffer_size  : 16480
>>         period_size  : 1030
>>         period_time  : 23356
>>         tstamp_mode  : NONE
>>         period_step  : 1
>>         avail_min    : 1030
>>         start_threshold  : 16480
>>         stop_threshold   : 16480
>>         silence_threshold: 0
>>         silence_size : 0
>>         boundary     : 1080033280
>>
>>        The problem with this setup is the application just hangs
>>        without playing
>>        anything. If I use period size as 2048, the app plays the song
>>        but clips the
>>        last part of it. If I use 1024/512, it works fine.
>>
>>        I have tried alsa lib version 1.0.15 & 1.0.16 but the problem
>>        persists. Is
>>        there anything wrong with my app or audio driver?
>>
>>        Please help.
>>
>>        Thanks in advance,
>>        Anuj Aggarwal
>>        _______________________________________________
>>        Alsa-devel mailing list
>>        Alsa-devel@alsa-project.org <mailto:Alsa-devel@alsa-project.org>
>>        http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>
>>        __________ NOD32 3238 (20080703) Information __________
>>
>>        This message was checked by NOD32 antivirus system.
>>        http://www.eset.com
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Best Regards,
>> Anuj Aggarwal
>>
>
>


-- 
Best Regards,
Anuj Aggarwal

Re: Application hangs with different period sizes

[Gustavo da Silva Serra]

Sorry, I didn't read the log.

I don't know where you can find this limitation, the only thing I know 
is that a specific model of Audigy, for example, seems to support only 
two periods.
Can't you just use 1024 or 512? I don't know why the application 
crashes, it is something that is beyond my knowledge, sorry.


anuj aggarwal escreveu:
> I think the library/driver is able to configure the way user has 
> requested. See the logs (in my first mail) which confirm that the 
> requested period size has been taken for configuration.
>
> Where can I found the limitation in the driver code/spec which says 
> that these period sizes are not supported? Any suggestion is most 
> welcome...
>
> Thanks,
> Anuj
>
> On Thu, Jul 3, 2008 at 6:30 PM, Gustavo da Silva Serra 
> <gustavo.serra@tet.com.br <mailto:gustavo.serra@tet.com.br>> wrote:
>
>     I think that snd_pcm_hw_params_set_period_size_near() will not
>     return an error, but you must check the "val" parameter, is it
>     returning the same value that you passed?
>
>     "Some periods are not supported" means that some cards may not
>     support periods that aren't power of two. I am not sure, since I
>     am new to ALSA and I am working most with aloop.
>
>     anuj aggarwal escreveu:
>
>         I am doing the same. I used
>         snd_pcm_hw_params_set_period_size_near() to set the period
>         size and checked the return value also; it was not an error.
>
>         I have one more question. When you say 'Some periods are not
>         supported', what does that mean? What are the constraints
>         which make some periods not-supported by the audio codec driver?
>
>         On Thu, Jul 3, 2008 at 5:11 PM, Gustavo da Silva Serra
>         <gustavo.serra@tet.com.br <mailto:gustavo.serra@tet.com.br>
>         <mailto:gustavo.serra@tet.com.br
>         <mailto:gustavo.serra@tet.com.br>>> wrote:
>
>            Do you check the result of the function that sets the
>         period size?
>            Some periods are not supported and you can't assume that
>         they are
>            valid and proceed in your application. Use
>            snd_pcm_hw_params_set_period_time_near to see what is the
>         nearest
>            possible value for period.
>          
>          <http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.html#gf5e53bcb748185a4da3b8538720a5792>
>
>            anuj aggarwal escreveu:
>
>                My audio driver supports buffer sizes from 128 to 32768 and
>                period sizes
>                from 8 to 2048. I am trying to set the period size as 1030
>                (just a random
>                number between 8 & 2048, but not multiple of 2^n) and
>         buffer
>                size as
>                16*buffer_size (i.e. 16480). The output is as follows:
>
>                Buffer size range from 128 to 32768
>                Period size range from 8 to 2048
>                Request period size 1030 and got 1030
>                Plug PCM: Hardware PCM card 0 'TWL4030' device 0
>         subdevice 0
>                Its setup is:
>                 stream       : PLAYBACK
>                 access       : RW_INTERLEAVED
>                 format       : S16_LE
>                 subformat    : STD
>                 channels     : 2
>                 rate         : 44100
>                 exact rate   : 44100 (44100/1)
>                 msbits       : 16
>                 buffer_size  : 16480
>                 period_size  : 1030
>                 period_time  : 23356
>                 tstamp_mode  : NONE
>                 period_step  : 1
>                 avail_min    : 1030
>                 start_threshold  : 16480
>                 stop_threshold   : 16480
>                 silence_threshold: 0
>                 silence_size : 0
>                 boundary     : 1080033280
>
>                The problem with this setup is the application just hangs
>                without playing
>                anything. If I use period size as 2048, the app plays
>         the song
>                but clips the
>                last part of it. If I use 1024/512, it works fine.
>
>                I have tried alsa lib version 1.0.15 & 1.0.16 but the
>         problem
>                persists. Is
>                there anything wrong with my app or audio driver?
>
>                Please help.
>
>                Thanks in advance,
>                Anuj Aggarwal
>                _______________________________________________
>                Alsa-devel mailing list
>                Alsa-devel@alsa-project.org
>         <mailto:Alsa-devel@alsa-project.org>
>         <mailto:Alsa-devel@alsa-project.org
>         <mailto:Alsa-devel@alsa-project.org>>
>
>                http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
>                __________ NOD32 3238 (20080703) Information __________
>
>                This message was checked by NOD32 antivirus system.
>                http://www.eset.com
>
>
>
>                
>
>
>
>
>         -- 
>         Best Regards,
>         Anuj Aggarwal
>
>
>
>
>
> -- 
> Best Regards,
> Anuj Aggarwal 

Re: Application hangs with different period sizes

[anuj aggarwal]

Hi,

Regarding the below mentioned problem, we added some debugging in ALSA layer
and our audio codec driver to understand the problem.  And I think, we
understand the root cause of the issue.
Whenever we call *snd_pcm_writei* function from application, it executes
kernel function *snd_pcm_lib_write1* from sound/core/pcm_lib.c. This
function copies the user buffer and updates some alsa  variables
and trigger the DMA ( if alsa is in PREPARED state).  And same thing is
done in snd_pcm_readi() function call.

In case of DMA transfer, the DMA callback will update the hw_ptr depending
on the number of bytes xfered. So now two functions are updating the hw_ptr
(DMA callback and write/read function) and this is the problem. Only DMA
callback should update the hw_ptr because DMA is the one who is doing the
real transfer, not  the write/read function. Read and write function should
only update the appl_ptr and leave the hw_ptr for DMA callback.

After applying the below patch, my application works fine. Can someone look
into the patch provided below and confirm our understanding?

diff -uNr lsp_0.9.7_old/sound/core/pcm_lib.c
lsp_0.9.7_new/sound/core/pcm_lib.c
--- lsp_0.9.7_old/sound/core/pcm_lib.c  2007-11-26 07:57:25.000000000 -0600
+++ lsp_0.9.7_new/sound/core/pcm_lib.c  2008-07-10 23:16:19.000000000 -0500
@@ -1648,8 +1648,6 @@
                snd_pcm_uframes_t frames, appl_ptr, appl_ofs;
                snd_pcm_uframes_t avail;
                snd_pcm_uframes_t cont;
-               if (runtime->sleep_min == 0 && runtime->status->state ==
SNDRV_PCM_STATE_RUNNING)
-                       snd_pcm_update_hw_ptr(substream);
                avail = snd_pcm_playback_avail(runtime);
                if (((avail < runtime->control->avail_min && size > avail)
||
                   (size >= runtime->xfer_align && avail <
runtime->xfer_align))) {
@@ -1924,8 +1922,6 @@
                snd_pcm_uframes_t frames, appl_ptr, appl_ofs;
                snd_pcm_uframes_t avail;
                snd_pcm_uframes_t cont;
-               if (runtime->sleep_min == 0 && runtime->status->state ==
SNDRV_PCM_STATE_RUNNING)
-                       snd_pcm_update_hw_ptr(substream);
              __draining:
                avail = snd_pcm_capture_avail(runtime);
                if (runtime->status->state == SNDRV_PCM_STATE_DRAINING) {

Please provide your comments.

Regards,
Anuj


On Thu, Jul 3, 2008 at 9:01 PM, Gustavo da Silva Serra <
gustavo.serra@tet.com.br> wrote:

> Sorry, I didn't read the log.
>
> I don't know where you can find this limitation, the only thing I know is
> that a specific model of Audigy, for example, seems to support only two
> periods.
> Can't you just use 1024 or 512? I don't know why the application crashes,
> it is something that is beyond my knowledge, sorry.
>
>
> anuj aggarwal escreveu:
>
>> I think the library/driver is able to configure the way user has
>> requested. See the logs (in my first mail) which confirm that the requested
>> period size has been taken for configuration.
>>
>> Where can I found the limitation in the driver code/spec which says that
>> these period sizes are not supported? Any suggestion is most welcome...
>>
>> Thanks,
>> Anuj
>>
>> On Thu, Jul 3, 2008 at 6:30 PM, Gustavo da Silva Serra <
>> gustavo.serra@tet.com.br <mailto:gustavo.serra@tet.com.br>> wrote:
>>
>>    I think that snd_pcm_hw_params_set_period_size_near() will not
>>    return an error, but you must check the "val" parameter, is it
>>    returning the same value that you passed?
>>
>>    "Some periods are not supported" means that some cards may not
>>    support periods that aren't power of two. I am not sure, since I
>>    am new to ALSA and I am working most with aloop.
>>
>>    anuj aggarwal escreveu:
>>
>>        I am doing the same. I used
>>        snd_pcm_hw_params_set_period_size_near() to set the period
>>        size and checked the return value also; it was not an error.
>>
>>        I have one more question. When you say 'Some periods are not
>>        supported', what does that mean? What are the constraints
>>        which make some periods not-supported by the audio codec driver?
>>
>>        On Thu, Jul 3, 2008 at 5:11 PM, Gustavo da Silva Serra
>>        <gustavo.serra@tet.com.br <mailto:gustavo.serra@tet.com.br>
>>        <mailto:gustavo.serra@tet.com.br
>>        <mailto:gustavo.serra@tet.com.br>>> wrote:
>>
>>           Do you check the result of the function that sets the
>>        period size?
>>           Some periods are not supported and you can't assume that
>>        they are
>>           valid and proceed in your application. Use
>>           snd_pcm_hw_params_set_period_time_near to see what is the
>>        nearest
>>           possible value for period.
>>                 <
>> http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.html#gf5e53bcb748185a4da3b8538720a5792
>> >
>>
>>           anuj aggarwal escreveu:
>>
>>               My audio driver supports buffer sizes from 128 to 32768 and
>>               period sizes
>>               from 8 to 2048. I am trying to set the period size as 1030
>>               (just a random
>>               number between 8 & 2048, but not multiple of 2^n) and
>>        buffer
>>               size as
>>               16*buffer_size (i.e. 16480). The output is as follows:
>>
>>               Buffer size range from 128 to 32768
>>               Period size range from 8 to 2048
>>               Request period size 1030 and got 1030
>>               Plug PCM: Hardware PCM card 0 'TWL4030' device 0
>>        subdevice 0
>>               Its setup is:
>>                stream       : PLAYBACK
>>                access       : RW_INTERLEAVED
>>                format       : S16_LE
>>                subformat    : STD
>>                channels     : 2
>>                rate         : 44100
>>                exact rate   : 44100 (44100/1)
>>                msbits       : 16
>>                buffer_size  : 16480
>>                period_size  : 1030
>>                period_time  : 23356
>>                tstamp_mode  : NONE
>>                period_step  : 1
>>                avail_min    : 1030
>>                start_threshold  : 16480
>>                stop_threshold   : 16480
>>                silence_threshold: 0
>>                silence_size : 0
>>                boundary     : 1080033280
>>
>>               The problem with this setup is the application just hangs
>>               without playing
>>               anything. If I use period size as 2048, the app plays
>>        the song
>>               but clips the
>>               last part of it. If I use 1024/512, it works fine.
>>
>>               I have tried alsa lib version 1.0.15 & 1.0.16 but the
>>        problem
>>               persists. Is
>>               there anything wrong with my app or audio driver?
>>
>>               Please help.
>>
>>               Thanks in advance,
>>               Anuj Aggarwal
>>               _______________________________________________
>>               Alsa-devel mailing list
>>               Alsa-devel@alsa-project.org
>>        <mailto:Alsa-devel@alsa-project.org>
>>        <mailto:Alsa-devel@alsa-project.org
>>        <mailto:Alsa-devel@alsa-project.org>>
>>
>>               http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>
>>               __________ NOD32 3238 (20080703) Information __________
>>
>>               This message was checked by NOD32 antivirus system.
>>               http://www.eset.com
>>
>>
>>
>>
>>
>>
>>
>>        --        Best Regards,
>>        Anuj Aggarwal
>>
>>
>>
>>
>>
>> --
>> Best Regards,
>> Anuj Aggarwal
>>
>
>


-- 
Best Regards,
Anuj Aggarwal

Re: Application hangs with different period sizes

[Takashi Iwai]

At Thu, 7 Aug 2008 15:48:49 +0530,
anuj aggarwal wrote:
> 
> Hi,
> 
> Regarding the below mentioned problem, we added some debugging in ALSA layer
> and our audio codec driver to understand the problem.  And I think, we
> understand the root cause of the issue.
> Whenever we call *snd_pcm_writei* function from application, it executes
> kernel function *snd_pcm_lib_write1* from sound/core/pcm_lib.c. This
> function copies the user buffer and updates some alsa  variables
> and trigger the DMA ( if alsa is in PREPARED state).  And same thing is
> done in snd_pcm_readi() function call.
> 
> In case of DMA transfer, the DMA callback will update the hw_ptr depending
> on the number of bytes xfered. So now two functions are updating the hw_ptr
> (DMA callback and write/read function) and this is the problem. Only DMA
> callback should update the hw_ptr because DMA is the one who is doing the
> real transfer, not  the write/read function. Read and write function should
> only update the appl_ptr and leave the hw_ptr for DMA callback.
> 
> After applying the below patch, my application works fine. Can someone look
> into the patch provided below and confirm our understanding?

The hw_ptr can be updated at any time.  It can be updated at hwsync or
other calls, too.  And, the update is protected via a substream lock,
it's no racy.

I guess your problem is the implementation of pointer callback.  The
update of hw_ptr purely depends on the value returned from the pointer
callback.  Or, the driver assumes wrongly about the handling of
hw_ptr...


Takashi