* Application hangs with different period sizes @ 2008-07-03 7:19 anuj aggarwal 2008-07-03 11:41 ` Gustavo da Silva Serra 0 siblings, 1 reply; 8+ messages in thread From: anuj aggarwal @ 2008-07-03 7:19 UTC (permalink / raw) To: alsa-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Application hangs with different period sizes 2008-07-03 7:19 Application hangs with different period sizes anuj aggarwal @ 2008-07-03 11:41 ` Gustavo da Silva Serra 2008-07-03 12:54 ` anuj aggarwal 0 siblings, 1 reply; 8+ messages in thread From: Gustavo da Silva Serra @ 2008-07-03 11:41 UTC (permalink / raw) To: anuj aggarwal; +Cc: alsa-devel 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 > > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Application hangs with different period sizes 2008-07-03 11:41 ` Gustavo da Silva Serra @ 2008-07-03 12:54 ` anuj aggarwal 2008-07-03 13:00 ` Gustavo da Silva Serra 0 siblings, 1 reply; 8+ messages in thread From: anuj aggarwal @ 2008-07-03 12:54 UTC (permalink / raw) To: Gustavo da Silva Serra, alsa-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Application hangs with different period sizes 2008-07-03 12:54 ` anuj aggarwal @ 2008-07-03 13:00 ` Gustavo da Silva Serra 2008-07-03 13:41 ` anuj aggarwal 0 siblings, 1 reply; 8+ messages in thread From: Gustavo da Silva Serra @ 2008-07-03 13:00 UTC (permalink / raw) To: anuj aggarwal; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Application hangs with different period sizes 2008-07-03 13:00 ` Gustavo da Silva Serra @ 2008-07-03 13:41 ` anuj aggarwal 2008-07-03 15:31 ` Gustavo da Silva Serra 0 siblings, 1 reply; 8+ messages in thread From: anuj aggarwal @ 2008-07-03 13:41 UTC (permalink / raw) To: Gustavo da Silva Serra, alsa-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Application hangs with different period sizes 2008-07-03 13:41 ` anuj aggarwal @ 2008-07-03 15:31 ` Gustavo da Silva Serra 2008-08-07 10:18 ` anuj aggarwal 0 siblings, 1 reply; 8+ messages in thread From: Gustavo da Silva Serra @ 2008-07-03 15:31 UTC (permalink / raw) To: anuj aggarwal; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Application hangs with different period sizes 2008-07-03 15:31 ` Gustavo da Silva Serra @ 2008-08-07 10:18 ` anuj aggarwal 2008-08-08 6:18 ` Takashi Iwai 0 siblings, 1 reply; 8+ messages in thread From: anuj aggarwal @ 2008-08-07 10:18 UTC (permalink / raw) To: alsa-devel; +Cc: Gustavo da Silva Serra 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Application hangs with different period sizes 2008-08-07 10:18 ` anuj aggarwal @ 2008-08-08 6:18 ` Takashi Iwai 0 siblings, 0 replies; 8+ messages in thread From: Takashi Iwai @ 2008-08-08 6:18 UTC (permalink / raw) To: anuj aggarwal; +Cc: alsa-devel, Gustavo da Silva Serra 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2008-08-08 6:18 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-07-03 7:19 Application hangs with different period sizes anuj aggarwal 2008-07-03 11:41 ` Gustavo da Silva Serra 2008-07-03 12:54 ` anuj aggarwal 2008-07-03 13:00 ` Gustavo da Silva Serra 2008-07-03 13:41 ` anuj aggarwal 2008-07-03 15:31 ` Gustavo da Silva Serra 2008-08-07 10:18 ` anuj aggarwal 2008-08-08 6:18 ` Takashi Iwai
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.