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

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

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