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@xxxxxxxxxx> 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@xxxxxxxxxx <mailto:gustavo.serra@xxxxxxxxxx>> 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@xxxxxxxxxx <mailto:gustavo.serra@xxxxxxxxxx>
>> <mailto:gustavo.serra@xxxxxxxxxx
>> <mailto:gustavo.serra@xxxxxxxxxx>>> 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@xxxxxxxxxxxxxxxx
>> <mailto:Alsa-devel@xxxxxxxxxxxxxxxx>
>> <mailto:Alsa-devel@xxxxxxxxxxxxxxxx
>> <mailto:Alsa-devel@xxxxxxxxxxxxxxxx>>
>>
>> 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
