ALSA queries

ALSA queries

[Chakravarthi Pradeep]

I'm working on ALSA driver for PCIe card. My ALSA driver and it's
initializing struct snd_pcm_hardware with below parameter.

/************************ code  start
************************************************/
static struct snd_pcm_hardware audio_pcm_hardware = {
.info = (SNDRV_PCM_INFO_INTERLEAVED  | SNDRV_PCM_INFO_MMAP |
SNDRV_PCM_INFO_MMAP_VALID |
SNDRV_PCM_INFO_BLOCK_TRANSFER |
SNDRV_PCM_INFO_RESUME ),
.formats  =       (SNDRV_PCM_FORMAT_S16_LE | SNDRV_PCM_FORMAT_S24_LE),
.rates  = (SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_192000),
.rate_min  = 44100,
.rate_max  = 192000,
.channels_min  = 2,
.channels_max  = 8,
.buffer_bytes_max  = 76800, /*75 kbytes */
.period_bytes_min  = 512,//4410, /* (channel (2) * sample_rate (44100)
* bit width (24)) / (60 * 8)  */
.period_bytes_max  = 16*1024,
.periods_min  = 10,
.periods_max  = 255,

};
/************************ code  end
************************************************/

1) I did not understand what is significance of periods_min ,
period_bytes_min ,  period_bytes_max and periods_max. Can you please
tell me what is importance of these parameter and what value should be
mentioned according into ALSA.

2) snd_pcm_ops trigger callback is getting called in the driver when
application sends "start" command. But ALSA driver is stopping by
itself after one frame is copied to ALSA framework, without waiting
for "stop" command.

For instance:
In trigger callback , I'm getting these logs after one frame is copied.
Trigger:Start (When Play button is selected/clicked in application,
Start command is sent to ALSA driver)
Dma transfer is completed.
Trigger:Stop. (When Stop button is selected/clicked in application,
Stop command is sent to ALSA driver. But stop button is not clicked in
this case)

Thanks in advance.

-- 
Thanks and Regards
Chakravarthi Pradeep.K
Ph: 91 9980434900

Re: ALSA queries

[Chakravarthi Pradeep]

Dear ALSA Developers Team,


I'm working on ALSA driver for PCIe card. My ALSA driver and it's
> initializing struct snd_pcm_hardware with below parameter.
>
> /************************ code  start
> ************************************************/
> static struct snd_pcm_hardware audio_pcm_hardware = {
> .info = (SNDRV_PCM_INFO_INTERLEAVED  | SNDRV_PCM_INFO_MMAP |
> SNDRV_PCM_INFO_MMAP_VALID |
> SNDRV_PCM_INFO_BLOCK_TRANSFER |
> SNDRV_PCM_INFO_RESUME ),
> .formats  =       (SNDRV_PCM_FORMAT_S16_LE | SNDRV_PCM_FORMAT_S24_LE),
> .rates  = (SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
> SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_192000),
> .rate_min  = 44100,
> .rate_max  = 192000,
> .channels_min  = 2,
> .channels_max  = 8,
> .buffer_bytes_max  = 76800, /*75 kbytes */
> .period_bytes_min  = 512,//4410, /* (channel (2) * sample_rate (44100)
> * bit width (24)) / (60 * 8)  */
> .period_bytes_max  = 16*1024,
> .periods_min  = 10,
> .periods_max  = 255,
>
> };
> /************************ code  end
> ************************************************/
>
> 1) I did not understand what is significance of periods_min ,
> period_bytes_min ,  period_bytes_max and periods_max. Can you please
> tell me what is importance of these parameter and what value should be
> mentioned according into ALSA.
>
> 2) snd_pcm_ops trigger callback is getting called in the driver when
> application sends "start" command. But ALSA driver is stopping by
> itself after one frame is copied to ALSA framework, without waiting
> for "stop" command.
>
> For instance:
> In trigger callback , I'm getting these logs after one frame is copied.
> Trigger:Start (When Play button is selected/clicked in application,
> Start command is sent to ALSA driver)
> Dma transfer is completed.
> Trigger:Stop. (When Stop button is selected/clicked in application,
> Stop command is sent to ALSA driver. But stop button is not clicked in
> this case)
>
> Thanks in advance.
>
> --
> Thanks and Regards
> Chakravarthi Pradeep.K
> Ph: 91 9980434900
>

Re: ALSA queries

[Takashi Iwai]

On Thu, 02 Aug 2018 16:31:13 +0200,
Chakravarthi Pradeep wrote:
> 
> I'm working on ALSA driver for PCIe card. My ALSA driver and it's
> initializing struct snd_pcm_hardware with below parameter.
> 
> /************************ code  start
> ************************************************/
> static struct snd_pcm_hardware audio_pcm_hardware = {
> .info = (SNDRV_PCM_INFO_INTERLEAVED  | SNDRV_PCM_INFO_MMAP |
> SNDRV_PCM_INFO_MMAP_VALID |
> SNDRV_PCM_INFO_BLOCK_TRANSFER |
> SNDRV_PCM_INFO_RESUME ),
> .formats  =       (SNDRV_PCM_FORMAT_S16_LE | SNDRV_PCM_FORMAT_S24_LE),
> .rates  = (SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
> SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_192000),
> .rate_min  = 44100,
> .rate_max  = 192000,
> .channels_min  = 2,
> .channels_max  = 8,
> .buffer_bytes_max  = 76800, /*75 kbytes */
> .period_bytes_min  = 512,//4410, /* (channel (2) * sample_rate (44100)
> * bit width (24)) / (60 * 8)  */
> .period_bytes_max  = 16*1024,
> .periods_min  = 10,
> .periods_max  = 255,
> 
> };
> /************************ code  end
> ************************************************/
> 
> 1) I did not understand what is significance of periods_min ,
> period_bytes_min ,  period_bytes_max and periods_max. Can you please
> tell me what is importance of these parameter and what value should be
> mentioned according into ALSA.

These three defines the values your hardware may accept:
 periods_min = the minimal number of periods
 period_bytes_min = the minimal size of bytes for one period
 period_bytes_max = the maximal size of bytes for one period

> 2) snd_pcm_ops trigger callback is getting called in the driver when
> application sends "start" command. But ALSA driver is stopping by
> itself after one frame is copied to ALSA framework, without waiting
> for "stop" command.
> 
> For instance:
> In trigger callback , I'm getting these logs after one frame is copied.
> Trigger:Start (When Play button is selected/clicked in application,
> Start command is sent to ALSA driver)
> Dma transfer is completed.
> Trigger:Stop. (When Stop button is selected/clicked in application,
> Stop command is sent to ALSA driver. But stop button is not clicked in
> this case)

It's most likely the ALSA PCM core's safety stop; your driver seem to
have missed snd_pcm_period_elapsed() calls, so the hwptr isn't
updated, resulting in XRUN.  ALSA PCM core checks such XRUN condition
with the own timer.


Takashi

Re: ALSA queries

[Chakravarthi Pradeep]

On Sun 5 Aug, 2018, 14:19 Chakravarthi Pradeep, <doubleq7@gmail.com> wrote:

> Hello Takashi,
>
> Thanks for your reply.
>
>  periods_min = the minimal number of periods
>  period_bytes_min = the minimal size of bytes for one period
>  period_bytes_max = the maximal size of bytes for one period
>
>
> periods_min = the minimal number of periods :  what is meaning of
> periods , is it minimal number of interrupts ?
> period_bytes_min = the minimal size of bytes for one period : it
> means, minimal size of bytes per interrupt in case of device, Is it
> correct ?
> what about period_max ?
>
> It's most likely the ALSA PCM core's safety stop; your driver seem to
> have missed snd_pcm_period_elapsed() calls, so the hwptr isn't
> updated, resulting in XRUN.  ALSA PCM core checks such XRUN condition
> with the own timer.
>
> I'm attaching my driver thread along with this mail. Can you please
> let me know if I have missed something in audio thread. ?. How to make
> sure in driver that, trigger stop should be called only when stop
> command is sent from application.
>
> I'm getting cut cut cut ... noise along with audio in VLC application.
> Initially for 2 or 4 seconds, cut cut cut noise is not heard in VLC
> application, However after almost after 5 sec ,I can hear cut cut cut
> noise in VLC application. With my analysis, hwptr is getting updated
> properly however I have doubt in app_ptr. I'm attaching the excl sheet
> with hw_ptr,app_ptr and buf_pos values.
>
> How to remove the cut cut cut ... noise in audio ?
>
> Regards,
> Chakravarthi
>
> On Fri, Aug 3, 2018 at 1:05 PM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > On Thu, 02 Aug 2018 16:31:13 +0200,
> > Chakravarthi Pradeep wrote:
> > >
> > > I'm working on ALSA driver for PCIe card. My ALSA driver and it's
> > > initializing struct snd_pcm_hardware with below parameter.
> > >
> > > /************************ code  start
> > > ************************************************/
> > > static struct snd_pcm_hardware audio_pcm_hardware = {
> > > .info = (SNDRV_PCM_INFO_INTERLEAVED  | SNDRV_PCM_INFO_MMAP |
> > > SNDRV_PCM_INFO_MMAP_VALID |
> > > SNDRV_PCM_INFO_BLOCK_TRANSFER |
> > > SNDRV_PCM_INFO_RESUME ),
> > > .formats  =       (SNDRV_PCM_FORMAT_S16_LE | SNDRV_PCM_FORMAT_S24_LE),
> > > .rates  = (SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
> > > SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_192000),
> > > .rate_min  = 44100,
> > > .rate_max  = 192000,
> > > .channels_min  = 2,
> > > .channels_max  = 8,
> > > .buffer_bytes_max  = 76800, /*75 kbytes */
> > > .period_bytes_min  = 512,//4410, /* (channel (2) * sample_rate (44100)
> > > * bit width (24)) / (60 * 8)  */
> > > .period_bytes_max  = 16*1024,
> > > .periods_min  = 10,
> > > .periods_max  = 255,
> > >
> > > };
> > > /************************ code  end
> > > ************************************************/
> > >
> > > 1) I did not understand what is significance of periods_min ,
> > > period_bytes_min ,  period_bytes_max and periods_max. Can you please
> > > tell me what is importance of these parameter and what value should be
> > > mentioned according into ALSA.
> >
> > These three defines the values your hardware may accept:
> >  periods_min = the minimal number of periods
> >  period_bytes_min = the minimal size of bytes for one period
> >  period_bytes_max = the maximal size of bytes for one period
> >
> > > 2) snd_pcm_ops trigger callback is getting called in the driver when
> > > application sends "start" command. But ALSA driver is stopping by
> > > itself after one frame is copied to ALSA framework, without waiting
> > > for "stop" command.
> > >
> > > For instance:
> > > In trigger callback , I'm getting these logs after one frame is copied.
> > > Trigger:Start (When Play button is selected/clicked in application,
> > > Start command is sent to ALSA driver)
> > > Dma transfer is completed.
> > > Trigger:Stop. (When Stop button is selected/clicked in application,
> > > Stop command is sent to ALSA driver. But stop button is not clicked in
> > > this case)
> >
> > It's most likely the ALSA PCM core's safety stop; your driver seem to
> > have missed snd_pcm_period_elapsed() calls, so the hwptr isn't
> > updated, resulting in XRUN.  ALSA PCM core checks such XRUN condition
> > with the own timer.
> >
> >
> > Takashi
>
>
>
> --
> Thanks and Regards
> Chakravarthi Pradeep.K
> Ph: 91 9980434900
>

Fwd: ALSA queries

[Chakravarthi Pradeep]

[-- Attachment #1: Type: text/plain, Size: 4268 bytes --]

---------- Forwarded message ---------
From: Chakravarthi Pradeep <doubleq7@gmail.com>
Date: Sun 5 Aug, 2018, 14:19
Subject: Re: [alsa-devel] ALSA queries
To: <tiwai@suse.de>


Hello Takashi,

Thanks for your reply.

 periods_min = the minimal number of periods
 period_bytes_min = the minimal size of bytes for one period
 period_bytes_max = the maximal size of bytes for one period


periods_min = the minimal number of periods :  what is meaning of
periods , is it minimal number of interrupts ?
period_bytes_min = the minimal size of bytes for one period : it
means, minimal size of bytes per interrupt in case of device, Is it
correct ?
what about period_max ?

It's most likely the ALSA PCM core's safety stop; your driver seem to
have missed snd_pcm_period_elapsed() calls, so the hwptr isn't
updated, resulting in XRUN.  ALSA PCM core checks such XRUN condition
with the own timer.

I'm attaching my driver thread along with this mail. Can you please
let me know if I have missed something in audio thread. ?. How to make
sure in driver that, trigger stop should be called only when stop
command is sent from application.

I'm getting cut cut cut ... noise along with audio in VLC application.
Initially for 2 or 4 seconds, cut cut cut noise is not heard in VLC
application, However after almost after 5 sec ,I can hear cut cut cut
noise in VLC application. With my analysis, hwptr is getting updated
properly however I have doubt in app_ptr. I'm attaching the excl sheet
with hw_ptr,app_ptr and buf_pos values.

How to remove the cut cut cut ... noise in audio ?

Regards,
Chakravarthi

On Fri, Aug 3, 2018 at 1:05 PM Takashi Iwai <tiwai@suse.de> wrote:
>
> On Thu, 02 Aug 2018 16:31:13 +0200,
> Chakravarthi Pradeep wrote:
> >
> > I'm working on ALSA driver for PCIe card. My ALSA driver and it's
> > initializing struct snd_pcm_hardware with below parameter.
> >
> > /************************ code  start
> > ************************************************/
> > static struct snd_pcm_hardware audio_pcm_hardware = {
> > .info = (SNDRV_PCM_INFO_INTERLEAVED  | SNDRV_PCM_INFO_MMAP |
> > SNDRV_PCM_INFO_MMAP_VALID |
> > SNDRV_PCM_INFO_BLOCK_TRANSFER |
> > SNDRV_PCM_INFO_RESUME ),
> > .formats  =       (SNDRV_PCM_FORMAT_S16_LE | SNDRV_PCM_FORMAT_S24_LE),
> > .rates  = (SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
> > SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_192000),
> > .rate_min  = 44100,
> > .rate_max  = 192000,
> > .channels_min  = 2,
> > .channels_max  = 8,
> > .buffer_bytes_max  = 76800, /*75 kbytes */
> > .period_bytes_min  = 512,//4410, /* (channel (2) * sample_rate (44100)
> > * bit width (24)) / (60 * 8)  */
> > .period_bytes_max  = 16*1024,
> > .periods_min  = 10,
> > .periods_max  = 255,
> >
> > };
> > /************************ code  end
> > ************************************************/
> >
> > 1) I did not understand what is significance of periods_min ,
> > period_bytes_min ,  period_bytes_max and periods_max. Can you please
> > tell me what is importance of these parameter and what value should be
> > mentioned according into ALSA.
>
> These three defines the values your hardware may accept:
>  periods_min = the minimal number of periods
>  period_bytes_min = the minimal size of bytes for one period
>  period_bytes_max = the maximal size of bytes for one period
>
> > 2) snd_pcm_ops trigger callback is getting called in the driver when
> > application sends "start" command. But ALSA driver is stopping by
> > itself after one frame is copied to ALSA framework, without waiting
> > for "stop" command.
> >
> > For instance:
> > In trigger callback , I'm getting these logs after one frame is copied.
> > Trigger:Start (When Play button is selected/clicked in application,
> > Start command is sent to ALSA driver)
> > Dma transfer is completed.
> > Trigger:Stop. (When Stop button is selected/clicked in application,
> > Stop command is sent to ALSA driver. But stop button is not clicked in
> > this case)
>
> It's most likely the ALSA PCM core's safety stop; your driver seem to
> have missed snd_pcm_period_elapsed() calls, so the hwptr isn't
> updated, resulting in XRUN.  ALSA PCM core checks such XRUN condition
> with the own timer.
>
>
> Takashi



-- 
Thanks and Regards
Chakravarthi Pradeep.K
Ph: 91 9980434900

[-- Attachment #2: audio_thread.c --]
[-- Type: text/x-c-code, Size: 1552 bytes --]

static int uhdc_audio_thread(void *data)
{
	char *audio_frame = NULL;
	int count = 0;
	uhdc_t3_card_driver *drv = (uhdc_t3_card_driver *)data;
	struct snd_pcm_runtime *runtime = drv->substream->runtime;

	
	audio_frame = kmalloc(MAX_AUDIO_SIZE, GFP_DMA);	
	if(!audio_frame)
	{
		return -ENOMEM;
	}
	while(1)
	{

		if (kthread_should_stop())
		{
			dbg_alsa( "###### %s %d\n",__FUNCTION__,__LINE__);
			break;
		}
		dbg_alsa( "###### Waiting for audio signal %s_%d\n",__FUNCTION__,__LINE__);
		wait_event_interruptible (audio_interrupt, (atomic_read (&audio_data_ready)));
		atomic_set (&audio_data_ready, 0);
		g_count = get_audio_size(g_temp_lro);
		count = g_count;
		printk( "######audio signal received and audio size:%d runtime->period_size:%d  %s_%d\n",g_count,runtime->period_size,__func__,__LINE__);		
		
		/* dma read is done here */
		/* audio_frame contains audio data */
		memcpy(drv->substream->runtime->dma_area + drv->buf_pos ,audio_frame,count);

		/* update the buf_pos */
		// here the (auto)increase of buf_pos is handled
		drv->buf_pos += count;
		drv->buf_pos %= drv->pcm_buffer_size;
	
		
		printk("\n\n\n hwptr=%d appl=%d pos=%d\n",
			(int)frames_to_bytes(runtime,runtime->status->hw_ptr),(int)frames_to_bytes(runtime, runtime->control->appl_ptr),drv->buf_pos);
		/* Below line needs to be uncommented for pointer to be updated in the alsa lib */
		snd_pcm_period_elapsed(drv->substream);
		
		try_to_freeze();

	}

	kfree(audio_frame);
	audio_frame = NULL;
	
	return 0 ;

}

[-- Attachment #3: hwptr_app_ptr_buf_pos_analysis.xlsx --]
[-- Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, Size: 11138 bytes --]

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

Re: Fwd: ALSA queries

[Takashi Iwai]

On Sun, 05 Aug 2018 20:09:47 +0200,
Chakravarthi Pradeep wrote:
> 
> ---------- Forwarded message ---------
> From: Chakravarthi Pradeep <doubleq7@gmail.com>
> Date: Sun 5 Aug, 2018, 14:19
> Subject: Re: [alsa-devel] ALSA queries
> To: <tiwai@suse.de>
> 
> 
> Hello Takashi,
> 
> Thanks for your reply.
> 
>  periods_min = the minimal number of periods
>  period_bytes_min = the minimal size of bytes for one period
>  period_bytes_max = the maximal size of bytes for one period
> 
> 
> periods_min = the minimal number of periods :  what is meaning of
> periods , is it minimal number of interrupts ?

The "period" in ALSA PCM definition represents the interval time (or
frames) of the periodical interrupts on the ring buffer.  If the irq
is issued for each 256 frames while the ring buffer size is 1024
frames, periods = 1024/256 = 4.  The periods_min defines the minimal
number of periods the hardware may accept.

> period_bytes_min = the minimal size of bytes for one period : it
> means, minimal size of bytes per interrupt in case of device, Is it
> correct ?

Correct.

> what about period_max ?

The maximal number of periods, the counter-part of periods_min.


> It's most likely the ALSA PCM core's safety stop; your driver seem to
> have missed snd_pcm_period_elapsed() calls, so the hwptr isn't
> updated, resulting in XRUN.  ALSA PCM core checks such XRUN condition
> with the own timer.
> 
> I'm attaching my driver thread along with this mail. Can you please
> let me know if I have missed something in audio thread. ?. How to make
> sure in driver that, trigger stop should be called only when stop
> command is sent from application.

Erm, I'm no consultant.  Does your driver issue really
snd_pcm_period_elapsed() or not?  You should know that.

If the problem happens even if the driver really calls
snd_pcm_period_elapsed(), then it's another cause.

> I'm getting cut cut cut ... noise along with audio in VLC application.
> Initially for 2 or 4 seconds, cut cut cut noise is not heard in VLC
> application, However after almost after 5 sec ,I can hear cut cut cut
> noise in VLC application. With my analysis, hwptr is getting updated
> properly however I have doubt in app_ptr. I'm attaching the excl sheet
> with hw_ptr,app_ptr and buf_pos values.

Do the buffer size and period size are set really as expected?
Often the driver misses the fact that PCM core doesn't guarantee the
alignment of buffer size and period size unless specified explicitly
via hw constraints.  That is, as default, it's possible to set a
buffer size 3000 bytes for the period size 64 bytes.  Then the last
period is partial.

For aligning the period and the buffer sizes, call
	snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
in the open callback.


Takashi

> 
> How to remove the cut cut cut ... noise in audio ?
> 
> Regards,
> Chakravarthi
> 
> On Fri, Aug 3, 2018 at 1:05 PM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > On Thu, 02 Aug 2018 16:31:13 +0200,
> > Chakravarthi Pradeep wrote:
> > >
> > > I'm working on ALSA driver for PCIe card. My ALSA driver and it's
> > > initializing struct snd_pcm_hardware with below parameter.
> > >
> > > /************************ code  start
> > > ************************************************/
> > > static struct snd_pcm_hardware audio_pcm_hardware = {
> > > .info = (SNDRV_PCM_INFO_INTERLEAVED  | SNDRV_PCM_INFO_MMAP |
> > > SNDRV_PCM_INFO_MMAP_VALID |
> > > SNDRV_PCM_INFO_BLOCK_TRANSFER |
> > > SNDRV_PCM_INFO_RESUME ),
> > > .formats  =       (SNDRV_PCM_FORMAT_S16_LE | SNDRV_PCM_FORMAT_S24_LE),
> > > .rates  = (SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
> > > SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_192000),
> > > .rate_min  = 44100,
> > > .rate_max  = 192000,
> > > .channels_min  = 2,
> > > .channels_max  = 8,
> > > .buffer_bytes_max  = 76800, /*75 kbytes */
> > > .period_bytes_min  = 512,//4410, /* (channel (2) * sample_rate (44100)
> > > * bit width (24)) / (60 * 8)  */
> > > .period_bytes_max  = 16*1024,
> > > .periods_min  = 10,
> > > .periods_max  = 255,
> > >
> > > };
> > > /************************ code  end
> > > ************************************************/
> > >
> > > 1) I did not understand what is significance of periods_min ,
> > > period_bytes_min ,  period_bytes_max and periods_max. Can you please
> > > tell me what is importance of these parameter and what value should be
> > > mentioned according into ALSA.
> >
> > These three defines the values your hardware may accept:
> >  periods_min = the minimal number of periods
> >  period_bytes_min = the minimal size of bytes for one period
> >  period_bytes_max = the maximal size of bytes for one period
> >
> > > 2) snd_pcm_ops trigger callback is getting called in the driver when
> > > application sends "start" command. But ALSA driver is stopping by
> > > itself after one frame is copied to ALSA framework, without waiting
> > > for "stop" command.
> > >
> > > For instance:
> > > In trigger callback , I'm getting these logs after one frame is copied.
> > > Trigger:Start (When Play button is selected/clicked in application,
> > > Start command is sent to ALSA driver)
> > > Dma transfer is completed.
> > > Trigger:Stop. (When Stop button is selected/clicked in application,
> > > Stop command is sent to ALSA driver. But stop button is not clicked in
> > > this case)
> >
> > It's most likely the ALSA PCM core's safety stop; your driver seem to
> > have missed snd_pcm_period_elapsed() calls, so the hwptr isn't
> > updated, resulting in XRUN.  ALSA PCM core checks such XRUN condition
> > with the own timer.
> >
> >
> > Takashi
> 
> 
> 
> -- 
> Thanks and Regards
> Chakravarthi Pradeep.K
> Ph: 91 9980434900
> [1.2  <text/html; UTF-8 (quoted-printable)>]
> 
> static int uhdc_audio_thread(void *data)
> {
> 	char *audio_frame = NULL;
> 	int count = 0;
> 	uhdc_t3_card_driver *drv = (uhdc_t3_card_driver *)data;
> 	struct snd_pcm_runtime *runtime = drv->substream->runtime;
> 
> 	
> 	audio_frame = kmalloc(MAX_AUDIO_SIZE, GFP_DMA);	
> 	if(!audio_frame)
> 	{
> 		return -ENOMEM;
> 	}
> 	while(1)
> 	{
> 
> 		if (kthread_should_stop())
> 		{
> 			dbg_alsa( "###### %s %d\n",__FUNCTION__,__LINE__);
> 			break;
> 		}
> 		dbg_alsa( "###### Waiting for audio signal %s_%d\n",__FUNCTION__,__LINE__);
> 		wait_event_interruptible (audio_interrupt, (atomic_read (&audio_data_ready)));
> 		atomic_set (&audio_data_ready, 0);
> 		g_count = get_audio_size(g_temp_lro);
> 		count = g_count;
> 		printk( "######audio signal received and audio size:%d runtime->period_size:%d  %s_%d\n",g_count,runtime->period_size,__func__,__LINE__);		
> 		
> 		/* dma read is done here */
> 		/* audio_frame contains audio data */
> 		memcpy(drv->substream->runtime->dma_area + drv->buf_pos ,audio_frame,count);
> 
> 		/* update the buf_pos */
> 		// here the (auto)increase of buf_pos is handled
> 		drv->buf_pos += count;
> 		drv->buf_pos %= drv->pcm_buffer_size;
> 	
> 		
> 		printk("\n\n\n hwptr=%d appl=%d pos=%d\n",
> 			(int)frames_to_bytes(runtime,runtime->status->hw_ptr),(int)frames_to_bytes(runtime, runtime->control->appl_ptr),drv->buf_pos);
> 		/* Below line needs to be uncommented for pointer to be updated in the alsa lib */
> 		snd_pcm_period_elapsed(drv->substream);
> 		
> 		try_to_freeze();
> 
> 	}
> 
> 	kfree(audio_frame);
> 	audio_frame = NULL;
> 	
> 	return 0 ;
> 
> }
> [3 hwptr_app_ptr_buf_pos_analysis.xlsx <application/vnd.openxmlformats-officedocument.spreadsheetml.sheet (base64)>]
> 

Re: Fwd: ALSA queries

[Chakravarthi Pradeep]

Hello Takashi,

Thanks for your explanation about period and periods.

> Erm, I'm no consultant.  Does your driver issue really
> snd_pcm_period_elapsed() or not?  You should know that.
>
> If the problem happens even if the driver really calls
> snd_pcm_period_elapsed(), then it's another cause

I'm calling  snd_pcm_period_elapsed() in my audio thread
snd_pcm_period_elapsed(drv->substream);
I'm calling this <snd_pcm_period_elapsed()> function after one frame
is copied to from PCIe device. However, hwptr is not updated and no
sound in the VLC application.

Regards,
Chakravarthi Pradeep K
On Mon, Aug 6, 2018 at 2:09 PM Takashi Iwai <tiwai@suse.de> wrote:
>
> On Sun, 05 Aug 2018 20:09:47 +0200,
> Chakravarthi Pradeep wrote:
> >
> > ---------- Forwarded message ---------
> > From: Chakravarthi Pradeep <doubleq7@gmail.com>
> > Date: Sun 5 Aug, 2018, 14:19
> > Subject: Re: [alsa-devel] ALSA queries
> > To: <tiwai@suse.de>
> >
> >
> > Hello Takashi,
> >
> > Thanks for your reply.
> >
> >  periods_min = the minimal number of periods
> >  period_bytes_min = the minimal size of bytes for one period
> >  period_bytes_max = the maximal size of bytes for one period
> >
> >
> > periods_min = the minimal number of periods :  what is meaning of
> > periods , is it minimal number of interrupts ?
>
> The "period" in ALSA PCM definition represents the interval time (or
> frames) of the periodical interrupts on the ring buffer.  If the irq
> is issued for each 256 frames while the ring buffer size is 1024
> frames, periods = 1024/256 = 4.  The periods_min defines the minimal
> number of periods the hardware may accept.
>
> > period_bytes_min = the minimal size of bytes for one period : it
> > means, minimal size of bytes per interrupt in case of device, Is it
> > correct ?
>
> Correct.
>
> > what about period_max ?
>
> The maximal number of periods, the counter-part of periods_min.
>
>
> > It's most likely the ALSA PCM core's safety stop; your driver seem to
> > have missed snd_pcm_period_elapsed() calls, so the hwptr isn't
> > updated, resulting in XRUN.  ALSA PCM core checks such XRUN condition
> > with the own timer.
> >
> > I'm attaching my driver thread along with this mail. Can you please
> > let me know if I have missed something in audio thread. ?. How to make
> > sure in driver that, trigger stop should be called only when stop
> > command is sent from application.
>
> Erm, I'm no consultant.  Does your driver issue really
> snd_pcm_period_elapsed() or not?  You should know that.
>
> If the problem happens even if the driver really calls
> snd_pcm_period_elapsed(), then it's another cause.
>
> > I'm getting cut cut cut ... noise along with audio in VLC application.
> > Initially for 2 or 4 seconds, cut cut cut noise is not heard in VLC
> > application, However after almost after 5 sec ,I can hear cut cut cut
> > noise in VLC application. With my analysis, hwptr is getting updated
> > properly however I have doubt in app_ptr. I'm attaching the excl sheet
> > with hw_ptr,app_ptr and buf_pos values.
>
> Do the buffer size and period size are set really as expected?
> Often the driver misses the fact that PCM core doesn't guarantee the
> alignment of buffer size and period size unless specified explicitly
> via hw constraints.  That is, as default, it's possible to set a
> buffer size 3000 bytes for the period size 64 bytes.  Then the last
> period is partial.
>
> For aligning the period and the buffer sizes, call
>         snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
> in the open callback.
>
>
> Takashi
>
> >
> > How to remove the cut cut cut ... noise in audio ?
> >
> > Regards,
> > Chakravarthi
> >
> > On Fri, Aug 3, 2018 at 1:05 PM Takashi Iwai <tiwai@suse.de> wrote:
> > >
> > > On Thu, 02 Aug 2018 16:31:13 +0200,
> > > Chakravarthi Pradeep wrote:
> > > >
> > > > I'm working on ALSA driver for PCIe card. My ALSA driver and it's
> > > > initializing struct snd_pcm_hardware with below parameter.
> > > >
> > > > /************************ code  start
> > > > ************************************************/
> > > > static struct snd_pcm_hardware audio_pcm_hardware = {
> > > > .info = (SNDRV_PCM_INFO_INTERLEAVED  | SNDRV_PCM_INFO_MMAP |
> > > > SNDRV_PCM_INFO_MMAP_VALID |
> > > > SNDRV_PCM_INFO_BLOCK_TRANSFER |
> > > > SNDRV_PCM_INFO_RESUME ),
> > > > .formats  =       (SNDRV_PCM_FORMAT_S16_LE | SNDRV_PCM_FORMAT_S24_LE),
> > > > .rates  = (SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
> > > > SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_192000),
> > > > .rate_min  = 44100,
> > > > .rate_max  = 192000,
> > > > .channels_min  = 2,
> > > > .channels_max  = 8,
> > > > .buffer_bytes_max  = 76800, /*75 kbytes */
> > > > .period_bytes_min  = 512,//4410, /* (channel (2) * sample_rate (44100)
> > > > * bit width (24)) / (60 * 8)  */
> > > > .period_bytes_max  = 16*1024,
> > > > .periods_min  = 10,
> > > > .periods_max  = 255,
> > > >
> > > > };
> > > > /************************ code  end
> > > > ************************************************/
> > > >
> > > > 1) I did not understand what is significance of periods_min ,
> > > > period_bytes_min ,  period_bytes_max and periods_max. Can you please
> > > > tell me what is importance of these parameter and what value should be
> > > > mentioned according into ALSA.
> > >
> > > These three defines the values your hardware may accept:
> > >  periods_min = the minimal number of periods
> > >  period_bytes_min = the minimal size of bytes for one period
> > >  period_bytes_max = the maximal size of bytes for one period
> > >
> > > > 2) snd_pcm_ops trigger callback is getting called in the driver when
> > > > application sends "start" command. But ALSA driver is stopping by
> > > > itself after one frame is copied to ALSA framework, without waiting
> > > > for "stop" command.
> > > >
> > > > For instance:
> > > > In trigger callback , I'm getting these logs after one frame is copied.
> > > > Trigger:Start (When Play button is selected/clicked in application,
> > > > Start command is sent to ALSA driver)
> > > > Dma transfer is completed.
> > > > Trigger:Stop. (When Stop button is selected/clicked in application,
> > > > Stop command is sent to ALSA driver. But stop button is not clicked in
> > > > this case)
> > >
> > > It's most likely the ALSA PCM core's safety stop; your driver seem to
> > > have missed snd_pcm_period_elapsed() calls, so the hwptr isn't
> > > updated, resulting in XRUN.  ALSA PCM core checks such XRUN condition
> > > with the own timer.
> > >
> > >
> > > Takashi
> >
> >
> >
> > --
> > Thanks and Regards
> > Chakravarthi Pradeep.K
> > Ph: 91 9980434900
> > [1.2  <text/html; UTF-8 (quoted-printable)>]
> >
> > static int uhdc_audio_thread(void *data)
> > {
> >       char *audio_frame = NULL;
> >       int count = 0;
> >       uhdc_t3_card_driver *drv = (uhdc_t3_card_driver *)data;
> >       struct snd_pcm_runtime *runtime = drv->substream->runtime;
> >
> >
> >       audio_frame = kmalloc(MAX_AUDIO_SIZE, GFP_DMA);
> >       if(!audio_frame)
> >       {
> >               return -ENOMEM;
> >       }
> >       while(1)
> >       {
> >
> >               if (kthread_should_stop())
> >               {
> >                       dbg_alsa( "###### %s %d\n",__FUNCTION__,__LINE__);
> >                       break;
> >               }
> >               dbg_alsa( "###### Waiting for audio signal %s_%d\n",__FUNCTION__,__LINE__);
> >               wait_event_interruptible (audio_interrupt, (atomic_read (&audio_data_ready)));
> >               atomic_set (&audio_data_ready, 0);
> >               g_count = get_audio_size(g_temp_lro);
> >               count = g_count;
> >               printk( "######audio signal received and audio size:%d runtime->period_size:%d  %s_%d\n",g_count,runtime->period_size,__func__,__LINE__);
> >
> >               /* dma read is done here */
> >               /* audio_frame contains audio data */
> >               memcpy(drv->substream->runtime->dma_area + drv->buf_pos ,audio_frame,count);
> >
> >               /* update the buf_pos */
> >               // here the (auto)increase of buf_pos is handled
> >               drv->buf_pos += count;
> >               drv->buf_pos %= drv->pcm_buffer_size;
> >
> >
> >               printk("\n\n\n hwptr=%d appl=%d pos=%d\n",
> >                       (int)frames_to_bytes(runtime,runtime->status->hw_ptr),(int)frames_to_bytes(runtime, runtime->control->appl_ptr),drv->buf_pos);
> >               /* Below line needs to be uncommented for pointer to be updated in the alsa lib */
> >               snd_pcm_period_elapsed(drv->substream);
> >
> >               try_to_freeze();
> >
> >       }
> >
> >       kfree(audio_frame);
> >       audio_frame = NULL;
> >
> >       return 0 ;
> >
> > }
> > [3 hwptr_app_ptr_buf_pos_analysis.xlsx <application/vnd.openxmlformats-officedocument.spreadsheetml.sheet (base64)>]
> >



--
Thanks and Regards
Chakravarthi Pradeep.K
Ph: 91 9980434900

Re: Fwd: ALSA queries

[Takashi Iwai]

On Mon, 06 Aug 2018 14:29:26 +0200,
Chakravarthi Pradeep wrote:
> 
> Hello Takashi,
> 
> Thanks for your explanation about period and periods.
> 
> > Erm, I'm no consultant.  Does your driver issue really
> > snd_pcm_period_elapsed() or not?  You should know that.
> >
> > If the problem happens even if the driver really calls
> > snd_pcm_period_elapsed(), then it's another cause
> 
> I'm calling  snd_pcm_period_elapsed() in my audio thread
> snd_pcm_period_elapsed(drv->substream);
> I'm calling this <snd_pcm_period_elapsed()> function after one frame
> is copied to from PCIe device. However, hwptr is not updated and no
> sound in the VLC application.

OK, so you are sure that the function is really called, not only in
theory, right?  Then the next item to check is the pointer callback.
The hwptr is updated based on the value returned from this callback.


Takashi

> 
> Regards,
> Chakravarthi Pradeep K
> On Mon, Aug 6, 2018 at 2:09 PM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > On Sun, 05 Aug 2018 20:09:47 +0200,
> > Chakravarthi Pradeep wrote:
> > >
> > > ---------- Forwarded message ---------
> > > From: Chakravarthi Pradeep <doubleq7@gmail.com>
> > > Date: Sun 5 Aug, 2018, 14:19
> > > Subject: Re: [alsa-devel] ALSA queries
> > > To: <tiwai@suse.de>
> > >
> > >
> > > Hello Takashi,
> > >
> > > Thanks for your reply.
> > >
> > >  periods_min = the minimal number of periods
> > >  period_bytes_min = the minimal size of bytes for one period
> > >  period_bytes_max = the maximal size of bytes for one period
> > >
> > >
> > > periods_min = the minimal number of periods :  what is meaning of
> > > periods , is it minimal number of interrupts ?
> >
> > The "period" in ALSA PCM definition represents the interval time (or
> > frames) of the periodical interrupts on the ring buffer.  If the irq
> > is issued for each 256 frames while the ring buffer size is 1024
> > frames, periods = 1024/256 = 4.  The periods_min defines the minimal
> > number of periods the hardware may accept.
> >
> > > period_bytes_min = the minimal size of bytes for one period : it
> > > means, minimal size of bytes per interrupt in case of device, Is it
> > > correct ?
> >
> > Correct.
> >
> > > what about period_max ?
> >
> > The maximal number of periods, the counter-part of periods_min.
> >
> >
> > > It's most likely the ALSA PCM core's safety stop; your driver seem to
> > > have missed snd_pcm_period_elapsed() calls, so the hwptr isn't
> > > updated, resulting in XRUN.  ALSA PCM core checks such XRUN condition
> > > with the own timer.
> > >
> > > I'm attaching my driver thread along with this mail. Can you please
> > > let me know if I have missed something in audio thread. ?. How to make
> > > sure in driver that, trigger stop should be called only when stop
> > > command is sent from application.
> >
> > Erm, I'm no consultant.  Does your driver issue really
> > snd_pcm_period_elapsed() or not?  You should know that.
> >
> > If the problem happens even if the driver really calls
> > snd_pcm_period_elapsed(), then it's another cause.
> >
> > > I'm getting cut cut cut ... noise along with audio in VLC application.
> > > Initially for 2 or 4 seconds, cut cut cut noise is not heard in VLC
> > > application, However after almost after 5 sec ,I can hear cut cut cut
> > > noise in VLC application. With my analysis, hwptr is getting updated
> > > properly however I have doubt in app_ptr. I'm attaching the excl sheet
> > > with hw_ptr,app_ptr and buf_pos values.
> >
> > Do the buffer size and period size are set really as expected?
> > Often the driver misses the fact that PCM core doesn't guarantee the
> > alignment of buffer size and period size unless specified explicitly
> > via hw constraints.  That is, as default, it's possible to set a
> > buffer size 3000 bytes for the period size 64 bytes.  Then the last
> > period is partial.
> >
> > For aligning the period and the buffer sizes, call
> >         snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
> > in the open callback.
> >
> >
> > Takashi
> >
> > >
> > > How to remove the cut cut cut ... noise in audio ?
> > >
> > > Regards,
> > > Chakravarthi
> > >
> > > On Fri, Aug 3, 2018 at 1:05 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > >
> > > > On Thu, 02 Aug 2018 16:31:13 +0200,
> > > > Chakravarthi Pradeep wrote:
> > > > >
> > > > > I'm working on ALSA driver for PCIe card. My ALSA driver and it's
> > > > > initializing struct snd_pcm_hardware with below parameter.
> > > > >
> > > > > /************************ code  start
> > > > > ************************************************/
> > > > > static struct snd_pcm_hardware audio_pcm_hardware = {
> > > > > .info = (SNDRV_PCM_INFO_INTERLEAVED  | SNDRV_PCM_INFO_MMAP |
> > > > > SNDRV_PCM_INFO_MMAP_VALID |
> > > > > SNDRV_PCM_INFO_BLOCK_TRANSFER |
> > > > > SNDRV_PCM_INFO_RESUME ),
> > > > > .formats  =       (SNDRV_PCM_FORMAT_S16_LE | SNDRV_PCM_FORMAT_S24_LE),
> > > > > .rates  = (SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
> > > > > SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_192000),
> > > > > .rate_min  = 44100,
> > > > > .rate_max  = 192000,
> > > > > .channels_min  = 2,
> > > > > .channels_max  = 8,
> > > > > .buffer_bytes_max  = 76800, /*75 kbytes */
> > > > > .period_bytes_min  = 512,//4410, /* (channel (2) * sample_rate (44100)
> > > > > * bit width (24)) / (60 * 8)  */
> > > > > .period_bytes_max  = 16*1024,
> > > > > .periods_min  = 10,
> > > > > .periods_max  = 255,
> > > > >
> > > > > };
> > > > > /************************ code  end
> > > > > ************************************************/
> > > > >
> > > > > 1) I did not understand what is significance of periods_min ,
> > > > > period_bytes_min ,  period_bytes_max and periods_max. Can you please
> > > > > tell me what is importance of these parameter and what value should be
> > > > > mentioned according into ALSA.
> > > >
> > > > These three defines the values your hardware may accept:
> > > >  periods_min = the minimal number of periods
> > > >  period_bytes_min = the minimal size of bytes for one period
> > > >  period_bytes_max = the maximal size of bytes for one period
> > > >
> > > > > 2) snd_pcm_ops trigger callback is getting called in the driver when
> > > > > application sends "start" command. But ALSA driver is stopping by
> > > > > itself after one frame is copied to ALSA framework, without waiting
> > > > > for "stop" command.
> > > > >
> > > > > For instance:
> > > > > In trigger callback , I'm getting these logs after one frame is copied.
> > > > > Trigger:Start (When Play button is selected/clicked in application,
> > > > > Start command is sent to ALSA driver)
> > > > > Dma transfer is completed.
> > > > > Trigger:Stop. (When Stop button is selected/clicked in application,
> > > > > Stop command is sent to ALSA driver. But stop button is not clicked in
> > > > > this case)
> > > >
> > > > It's most likely the ALSA PCM core's safety stop; your driver seem to
> > > > have missed snd_pcm_period_elapsed() calls, so the hwptr isn't
> > > > updated, resulting in XRUN.  ALSA PCM core checks such XRUN condition
> > > > with the own timer.
> > > >
> > > >
> > > > Takashi
> > >
> > >
> > >
> > > --
> > > Thanks and Regards
> > > Chakravarthi Pradeep.K
> > > Ph: 91 9980434900
> > > [1.2  <text/html; UTF-8 (quoted-printable)>]
> > >
> > > static int uhdc_audio_thread(void *data)
> > > {
> > >       char *audio_frame = NULL;
> > >       int count = 0;
> > >       uhdc_t3_card_driver *drv = (uhdc_t3_card_driver *)data;
> > >       struct snd_pcm_runtime *runtime = drv->substream->runtime;
> > >
> > >
> > >       audio_frame = kmalloc(MAX_AUDIO_SIZE, GFP_DMA);
> > >       if(!audio_frame)
> > >       {
> > >               return -ENOMEM;
> > >       }
> > >       while(1)
> > >       {
> > >
> > >               if (kthread_should_stop())
> > >               {
> > >                       dbg_alsa( "###### %s %d\n",__FUNCTION__,__LINE__);
> > >                       break;
> > >               }
> > >               dbg_alsa( "###### Waiting for audio signal %s_%d\n",__FUNCTION__,__LINE__);
> > >               wait_event_interruptible (audio_interrupt, (atomic_read (&audio_data_ready)));
> > >               atomic_set (&audio_data_ready, 0);
> > >               g_count = get_audio_size(g_temp_lro);
> > >               count = g_count;
> > >               printk( "######audio signal received and audio size:%d runtime->period_size:%d  %s_%d\n",g_count,runtime->period_size,__func__,__LINE__);
> > >
> > >               /* dma read is done here */
> > >               /* audio_frame contains audio data */
> > >               memcpy(drv->substream->runtime->dma_area + drv->buf_pos ,audio_frame,count);
> > >
> > >               /* update the buf_pos */
> > >               // here the (auto)increase of buf_pos is handled
> > >               drv->buf_pos += count;
> > >               drv->buf_pos %= drv->pcm_buffer_size;
> > >
> > >
> > >               printk("\n\n\n hwptr=%d appl=%d pos=%d\n",
> > >                       (int)frames_to_bytes(runtime,runtime->status->hw_ptr),(int)frames_to_bytes(runtime, runtime->control->appl_ptr),drv->buf_pos);
> > >               /* Below line needs to be uncommented for pointer to be updated in the alsa lib */
> > >               snd_pcm_period_elapsed(drv->substream);
> > >
> > >               try_to_freeze();
> > >
> > >       }
> > >
> > >       kfree(audio_frame);
> > >       audio_frame = NULL;
> > >
> > >       return 0 ;
> > >
> > > }
> > > [3 hwptr_app_ptr_buf_pos_analysis.xlsx <application/vnd.openxmlformats-officedocument.spreadsheetml.sheet (base64)>]
> > >
> 
> 
> 
> --
> Thanks and Regards
> Chakravarthi Pradeep.K
> Ph: 91 9980434900
> 

Re: Fwd: ALSA queries

[Chakravarthi Pradeep]

Hello Takashi,

> OK, so you are sure that the function is really called, not only in
> theory, right?  Then the next item to check is the pointer callback.
> The hwptr is updated based on the value returned from this callback.

I'm sure that I'm calling snd_pcm_period_elapsed() function and my
pointer function is given below:

/************************* pointer callback *****************
static snd_pcm_uframes_t uhdc_audio_pcm_pointer(struct
snd_pcm_substream *substream)
{
struct snd_pcm_runtime *runtime = substream->runtime;
uhdc_t3_card_driver *drv = runtime->private_data;
return bytes_to_frames(runtime, drv->buf_pos);
}


Regards,
Chakravarthi Pradeep K


On Mon, Aug 6, 2018 at 6:21 PM Takashi Iwai <tiwai@suse.de> wrote:
>
> On Mon, 06 Aug 2018 14:29:26 +0200,
> Chakravarthi Pradeep wrote:
> >
> > Hello Takashi,
> >
> > Thanks for your explanation about period and periods.
> >
> > > Erm, I'm no consultant.  Does your driver issue really
> > > snd_pcm_period_elapsed() or not?  You should know that.
> > >
> > > If the problem happens even if the driver really calls
> > > snd_pcm_period_elapsed(), then it's another cause
> >
> > I'm calling  snd_pcm_period_elapsed() in my audio thread
> > snd_pcm_period_elapsed(drv->substream);
> > I'm calling this <snd_pcm_period_elapsed()> function after one frame
> > is copied to from PCIe device. However, hwptr is not updated and no
> > sound in the VLC application.
>
> OK, so you are sure that the function is really called, not only in
> theory, right?  Then the next item to check is the pointer callback.
> The hwptr is updated based on the value returned from this callback.
>
>
> Takashi
>
> >
> > Regards,
> > Chakravarthi Pradeep K
> > On Mon, Aug 6, 2018 at 2:09 PM Takashi Iwai <tiwai@suse.de> wrote:
> > >
> > > On Sun, 05 Aug 2018 20:09:47 +0200,
> > > Chakravarthi Pradeep wrote:
> > > >
> > > > ---------- Forwarded message ---------
> > > > From: Chakravarthi Pradeep <doubleq7@gmail.com>
> > > > Date: Sun 5 Aug, 2018, 14:19
> > > > Subject: Re: [alsa-devel] ALSA queries
> > > > To: <tiwai@suse.de>
> > > >
> > > >
> > > > Hello Takashi,
> > > >
> > > > Thanks for your reply.
> > > >
> > > >  periods_min = the minimal number of periods
> > > >  period_bytes_min = the minimal size of bytes for one period
> > > >  period_bytes_max = the maximal size of bytes for one period
> > > >
> > > >
> > > > periods_min = the minimal number of periods :  what is meaning of
> > > > periods , is it minimal number of interrupts ?
> > >
> > > The "period" in ALSA PCM definition represents the interval time (or
> > > frames) of the periodical interrupts on the ring buffer.  If the irq
> > > is issued for each 256 frames while the ring buffer size is 1024
> > > frames, periods = 1024/256 = 4.  The periods_min defines the minimal
> > > number of periods the hardware may accept.
> > >
> > > > period_bytes_min = the minimal size of bytes for one period : it
> > > > means, minimal size of bytes per interrupt in case of device, Is it
> > > > correct ?
> > >
> > > Correct.
> > >
> > > > what about period_max ?
> > >
> > > The maximal number of periods, the counter-part of periods_min.
> > >
> > >
> > > > It's most likely the ALSA PCM core's safety stop; your driver seem to
> > > > have missed snd_pcm_period_elapsed() calls, so the hwptr isn't
> > > > updated, resulting in XRUN.  ALSA PCM core checks such XRUN condition
> > > > with the own timer.
> > > >
> > > > I'm attaching my driver thread along with this mail. Can you please
> > > > let me know if I have missed something in audio thread. ?. How to make
> > > > sure in driver that, trigger stop should be called only when stop
> > > > command is sent from application.
> > >
> > > Erm, I'm no consultant.  Does your driver issue really
> > > snd_pcm_period_elapsed() or not?  You should know that.
> > >
> > > If the problem happens even if the driver really calls
> > > snd_pcm_period_elapsed(), then it's another cause.
> > >
> > > > I'm getting cut cut cut ... noise along with audio in VLC application.
> > > > Initially for 2 or 4 seconds, cut cut cut noise is not heard in VLC
> > > > application, However after almost after 5 sec ,I can hear cut cut cut
> > > > noise in VLC application. With my analysis, hwptr is getting updated
> > > > properly however I have doubt in app_ptr. I'm attaching the excl sheet
> > > > with hw_ptr,app_ptr and buf_pos values.
> > >
> > > Do the buffer size and period size are set really as expected?
> > > Often the driver misses the fact that PCM core doesn't guarantee the
> > > alignment of buffer size and period size unless specified explicitly
> > > via hw constraints.  That is, as default, it's possible to set a
> > > buffer size 3000 bytes for the period size 64 bytes.  Then the last
> > > period is partial.
> > >
> > > For aligning the period and the buffer sizes, call
> > >         snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
> > > in the open callback.
> > >
> > >
> > > Takashi
> > >
> > > >
> > > > How to remove the cut cut cut ... noise in audio ?
> > > >
> > > > Regards,
> > > > Chakravarthi
> > > >
> > > > On Fri, Aug 3, 2018 at 1:05 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > >
> > > > > On Thu, 02 Aug 2018 16:31:13 +0200,
> > > > > Chakravarthi Pradeep wrote:
> > > > > >
> > > > > > I'm working on ALSA driver for PCIe card. My ALSA driver and it's
> > > > > > initializing struct snd_pcm_hardware with below parameter.
> > > > > >
> > > > > > /************************ code  start
> > > > > > ************************************************/
> > > > > > static struct snd_pcm_hardware audio_pcm_hardware = {
> > > > > > .info = (SNDRV_PCM_INFO_INTERLEAVED  | SNDRV_PCM_INFO_MMAP |
> > > > > > SNDRV_PCM_INFO_MMAP_VALID |
> > > > > > SNDRV_PCM_INFO_BLOCK_TRANSFER |
> > > > > > SNDRV_PCM_INFO_RESUME ),
> > > > > > .formats  =       (SNDRV_PCM_FORMAT_S16_LE | SNDRV_PCM_FORMAT_S24_LE),
> > > > > > .rates  = (SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
> > > > > > SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_192000),
> > > > > > .rate_min  = 44100,
> > > > > > .rate_max  = 192000,
> > > > > > .channels_min  = 2,
> > > > > > .channels_max  = 8,
> > > > > > .buffer_bytes_max  = 76800, /*75 kbytes */
> > > > > > .period_bytes_min  = 512,//4410, /* (channel (2) * sample_rate (44100)
> > > > > > * bit width (24)) / (60 * 8)  */
> > > > > > .period_bytes_max  = 16*1024,
> > > > > > .periods_min  = 10,
> > > > > > .periods_max  = 255,
> > > > > >
> > > > > > };
> > > > > > /************************ code  end
> > > > > > ************************************************/
> > > > > >
> > > > > > 1) I did not understand what is significance of periods_min ,
> > > > > > period_bytes_min ,  period_bytes_max and periods_max. Can you please
> > > > > > tell me what is importance of these parameter and what value should be
> > > > > > mentioned according into ALSA.
> > > > >
> > > > > These three defines the values your hardware may accept:
> > > > >  periods_min = the minimal number of periods
> > > > >  period_bytes_min = the minimal size of bytes for one period
> > > > >  period_bytes_max = the maximal size of bytes for one period
> > > > >
> > > > > > 2) snd_pcm_ops trigger callback is getting called in the driver when
> > > > > > application sends "start" command. But ALSA driver is stopping by
> > > > > > itself after one frame is copied to ALSA framework, without waiting
> > > > > > for "stop" command.
> > > > > >
> > > > > > For instance:
> > > > > > In trigger callback , I'm getting these logs after one frame is copied.
> > > > > > Trigger:Start (When Play button is selected/clicked in application,
> > > > > > Start command is sent to ALSA driver)
> > > > > > Dma transfer is completed.
> > > > > > Trigger:Stop. (When Stop button is selected/clicked in application,
> > > > > > Stop command is sent to ALSA driver. But stop button is not clicked in
> > > > > > this case)
> > > > >
> > > > > It's most likely the ALSA PCM core's safety stop; your driver seem to
> > > > > have missed snd_pcm_period_elapsed() calls, so the hwptr isn't
> > > > > updated, resulting in XRUN.  ALSA PCM core checks such XRUN condition
> > > > > with the own timer.
> > > > >
> > > > >
> > > > > Takashi
> > > >
> > > >
> > > >
> > > > --
> > > > Thanks and Regards
> > > > Chakravarthi Pradeep.K
> > > > Ph: 91 9980434900
> > > > [1.2  <text/html; UTF-8 (quoted-printable)>]
> > > >
> > > > static int uhdc_audio_thread(void *data)
> > > > {
> > > >       char *audio_frame = NULL;
> > > >       int count = 0;
> > > >       uhdc_t3_card_driver *drv = (uhdc_t3_card_driver *)data;
> > > >       struct snd_pcm_runtime *runtime = drv->substream->runtime;
> > > >
> > > >
> > > >       audio_frame = kmalloc(MAX_AUDIO_SIZE, GFP_DMA);
> > > >       if(!audio_frame)
> > > >       {
> > > >               return -ENOMEM;
> > > >       }
> > > >       while(1)
> > > >       {
> > > >
> > > >               if (kthread_should_stop())
> > > >               {
> > > >                       dbg_alsa( "###### %s %d\n",__FUNCTION__,__LINE__);
> > > >                       break;
> > > >               }
> > > >               dbg_alsa( "###### Waiting for audio signal %s_%d\n",__FUNCTION__,__LINE__);
> > > >               wait_event_interruptible (audio_interrupt, (atomic_read (&audio_data_ready)));
> > > >               atomic_set (&audio_data_ready, 0);
> > > >               g_count = get_audio_size(g_temp_lro);
> > > >               count = g_count;
> > > >               printk( "######audio signal received and audio size:%d runtime->period_size:%d  %s_%d\n",g_count,runtime->period_size,__func__,__LINE__);
> > > >
> > > >               /* dma read is done here */
> > > >               /* audio_frame contains audio data */
> > > >               memcpy(drv->substream->runtime->dma_area + drv->buf_pos ,audio_frame,count);
> > > >
> > > >               /* update the buf_pos */
> > > >               // here the (auto)increase of buf_pos is handled
> > > >               drv->buf_pos += count;
> > > >               drv->buf_pos %= drv->pcm_buffer_size;
> > > >
> > > >
> > > >               printk("\n\n\n hwptr=%d appl=%d pos=%d\n",
> > > >                       (int)frames_to_bytes(runtime,runtime->status->hw_ptr),(int)frames_to_bytes(runtime, runtime->control->appl_ptr),drv->buf_pos);
> > > >               /* Below line needs to be uncommented for pointer to be updated in the alsa lib */
> > > >               snd_pcm_period_elapsed(drv->substream);
> > > >
> > > >               try_to_freeze();
> > > >
> > > >       }
> > > >
> > > >       kfree(audio_frame);
> > > >       audio_frame = NULL;
> > > >
> > > >       return 0 ;
> > > >
> > > > }
> > > > [3 hwptr_app_ptr_buf_pos_analysis.xlsx <application/vnd.openxmlformats-officedocument.spreadsheetml.sheet (base64)>]
> > > >
> >
> >
> >
> > --
> > Thanks and Regards
> > Chakravarthi Pradeep.K
> > Ph: 91 9980434900
> >



-- 
Thanks and Regards
Chakravarthi Pradeep.K
Ph: 91 9980434900

Re: Fwd: ALSA queries

[Takashi Iwai]

On Mon, 06 Aug 2018 15:23:31 +0200,
Chakravarthi Pradeep wrote:
> 
> Hello Takashi,
> 
> > OK, so you are sure that the function is really called, not only in
> > theory, right?  Then the next item to check is the pointer callback.
> > The hwptr is updated based on the value returned from this callback.
> 
> I'm sure that I'm calling snd_pcm_period_elapsed() function

You confirmed with putting the debug print, etc?

> and my
> pointer function is given below:
> 
> /************************* pointer callback *****************
> static snd_pcm_uframes_t uhdc_audio_pcm_pointer(struct
> snd_pcm_substream *substream)
> {
> struct snd_pcm_runtime *runtime = substream->runtime;
> uhdc_t3_card_driver *drv = runtime->private_data;
> return bytes_to_frames(runtime, drv->buf_pos);
> }

And drv->buf_pos is the correct position that matches with the
expected hwptr?  Basically there only these two things.


Takashi

> 
> 
> Regards,
> Chakravarthi Pradeep K
> 
> 
> On Mon, Aug 6, 2018 at 6:21 PM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > On Mon, 06 Aug 2018 14:29:26 +0200,
> > Chakravarthi Pradeep wrote:
> > >
> > > Hello Takashi,
> > >
> > > Thanks for your explanation about period and periods.
> > >
> > > > Erm, I'm no consultant.  Does your driver issue really
> > > > snd_pcm_period_elapsed() or not?  You should know that.
> > > >
> > > > If the problem happens even if the driver really calls
> > > > snd_pcm_period_elapsed(), then it's another cause
> > >
> > > I'm calling  snd_pcm_period_elapsed() in my audio thread
> > > snd_pcm_period_elapsed(drv->substream);
> > > I'm calling this <snd_pcm_period_elapsed()> function after one frame
> > > is copied to from PCIe device. However, hwptr is not updated and no
> > > sound in the VLC application.
> >
> > OK, so you are sure that the function is really called, not only in
> > theory, right?  Then the next item to check is the pointer callback.
> > The hwptr is updated based on the value returned from this callback.
> >
> >
> > Takashi
> >
> > >
> > > Regards,
> > > Chakravarthi Pradeep K
> > > On Mon, Aug 6, 2018 at 2:09 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > >
> > > > On Sun, 05 Aug 2018 20:09:47 +0200,
> > > > Chakravarthi Pradeep wrote:
> > > > >
> > > > > ---------- Forwarded message ---------
> > > > > From: Chakravarthi Pradeep <doubleq7@gmail.com>
> > > > > Date: Sun 5 Aug, 2018, 14:19
> > > > > Subject: Re: [alsa-devel] ALSA queries
> > > > > To: <tiwai@suse.de>
> > > > >
> > > > >
> > > > > Hello Takashi,
> > > > >
> > > > > Thanks for your reply.
> > > > >
> > > > >  periods_min = the minimal number of periods
> > > > >  period_bytes_min = the minimal size of bytes for one period
> > > > >  period_bytes_max = the maximal size of bytes for one period
> > > > >
> > > > >
> > > > > periods_min = the minimal number of periods :  what is meaning of
> > > > > periods , is it minimal number of interrupts ?
> > > >
> > > > The "period" in ALSA PCM definition represents the interval time (or
> > > > frames) of the periodical interrupts on the ring buffer.  If the irq
> > > > is issued for each 256 frames while the ring buffer size is 1024
> > > > frames, periods = 1024/256 = 4.  The periods_min defines the minimal
> > > > number of periods the hardware may accept.
> > > >
> > > > > period_bytes_min = the minimal size of bytes for one period : it
> > > > > means, minimal size of bytes per interrupt in case of device, Is it
> > > > > correct ?
> > > >
> > > > Correct.
> > > >
> > > > > what about period_max ?
> > > >
> > > > The maximal number of periods, the counter-part of periods_min.
> > > >
> > > >
> > > > > It's most likely the ALSA PCM core's safety stop; your driver seem to
> > > > > have missed snd_pcm_period_elapsed() calls, so the hwptr isn't
> > > > > updated, resulting in XRUN.  ALSA PCM core checks such XRUN condition
> > > > > with the own timer.
> > > > >
> > > > > I'm attaching my driver thread along with this mail. Can you please
> > > > > let me know if I have missed something in audio thread. ?. How to make
> > > > > sure in driver that, trigger stop should be called only when stop
> > > > > command is sent from application.
> > > >
> > > > Erm, I'm no consultant.  Does your driver issue really
> > > > snd_pcm_period_elapsed() or not?  You should know that.
> > > >
> > > > If the problem happens even if the driver really calls
> > > > snd_pcm_period_elapsed(), then it's another cause.
> > > >
> > > > > I'm getting cut cut cut ... noise along with audio in VLC application.
> > > > > Initially for 2 or 4 seconds, cut cut cut noise is not heard in VLC
> > > > > application, However after almost after 5 sec ,I can hear cut cut cut
> > > > > noise in VLC application. With my analysis, hwptr is getting updated
> > > > > properly however I have doubt in app_ptr. I'm attaching the excl sheet
> > > > > with hw_ptr,app_ptr and buf_pos values.
> > > >
> > > > Do the buffer size and period size are set really as expected?
> > > > Often the driver misses the fact that PCM core doesn't guarantee the
> > > > alignment of buffer size and period size unless specified explicitly
> > > > via hw constraints.  That is, as default, it's possible to set a
> > > > buffer size 3000 bytes for the period size 64 bytes.  Then the last
> > > > period is partial.
> > > >
> > > > For aligning the period and the buffer sizes, call
> > > >         snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
> > > > in the open callback.
> > > >
> > > >
> > > > Takashi
> > > >
> > > > >
> > > > > How to remove the cut cut cut ... noise in audio ?
> > > > >
> > > > > Regards,
> > > > > Chakravarthi
> > > > >
> > > > > On Fri, Aug 3, 2018 at 1:05 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > >
> > > > > > On Thu, 02 Aug 2018 16:31:13 +0200,
> > > > > > Chakravarthi Pradeep wrote:
> > > > > > >
> > > > > > > I'm working on ALSA driver for PCIe card. My ALSA driver and it's
> > > > > > > initializing struct snd_pcm_hardware with below parameter.
> > > > > > >
> > > > > > > /************************ code  start
> > > > > > > ************************************************/
> > > > > > > static struct snd_pcm_hardware audio_pcm_hardware = {
> > > > > > > .info = (SNDRV_PCM_INFO_INTERLEAVED  | SNDRV_PCM_INFO_MMAP |
> > > > > > > SNDRV_PCM_INFO_MMAP_VALID |
> > > > > > > SNDRV_PCM_INFO_BLOCK_TRANSFER |
> > > > > > > SNDRV_PCM_INFO_RESUME ),
> > > > > > > .formats  =       (SNDRV_PCM_FORMAT_S16_LE | SNDRV_PCM_FORMAT_S24_LE),
> > > > > > > .rates  = (SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
> > > > > > > SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_192000),
> > > > > > > .rate_min  = 44100,
> > > > > > > .rate_max  = 192000,
> > > > > > > .channels_min  = 2,
> > > > > > > .channels_max  = 8,
> > > > > > > .buffer_bytes_max  = 76800, /*75 kbytes */
> > > > > > > .period_bytes_min  = 512,//4410, /* (channel (2) * sample_rate (44100)
> > > > > > > * bit width (24)) / (60 * 8)  */
> > > > > > > .period_bytes_max  = 16*1024,
> > > > > > > .periods_min  = 10,
> > > > > > > .periods_max  = 255,
> > > > > > >
> > > > > > > };
> > > > > > > /************************ code  end
> > > > > > > ************************************************/
> > > > > > >
> > > > > > > 1) I did not understand what is significance of periods_min ,
> > > > > > > period_bytes_min ,  period_bytes_max and periods_max. Can you please
> > > > > > > tell me what is importance of these parameter and what value should be
> > > > > > > mentioned according into ALSA.
> > > > > >
> > > > > > These three defines the values your hardware may accept:
> > > > > >  periods_min = the minimal number of periods
> > > > > >  period_bytes_min = the minimal size of bytes for one period
> > > > > >  period_bytes_max = the maximal size of bytes for one period
> > > > > >
> > > > > > > 2) snd_pcm_ops trigger callback is getting called in the driver when
> > > > > > > application sends "start" command. But ALSA driver is stopping by
> > > > > > > itself after one frame is copied to ALSA framework, without waiting
> > > > > > > for "stop" command.
> > > > > > >
> > > > > > > For instance:
> > > > > > > In trigger callback , I'm getting these logs after one frame is copied.
> > > > > > > Trigger:Start (When Play button is selected/clicked in application,
> > > > > > > Start command is sent to ALSA driver)
> > > > > > > Dma transfer is completed.
> > > > > > > Trigger:Stop. (When Stop button is selected/clicked in application,
> > > > > > > Stop command is sent to ALSA driver. But stop button is not clicked in
> > > > > > > this case)
> > > > > >
> > > > > > It's most likely the ALSA PCM core's safety stop; your driver seem to
> > > > > > have missed snd_pcm_period_elapsed() calls, so the hwptr isn't
> > > > > > updated, resulting in XRUN.  ALSA PCM core checks such XRUN condition
> > > > > > with the own timer.
> > > > > >
> > > > > >
> > > > > > Takashi
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Thanks and Regards
> > > > > Chakravarthi Pradeep.K
> > > > > Ph: 91 9980434900
> > > > > [1.2  <text/html; UTF-8 (quoted-printable)>]
> > > > >
> > > > > static int uhdc_audio_thread(void *data)
> > > > > {
> > > > >       char *audio_frame = NULL;
> > > > >       int count = 0;
> > > > >       uhdc_t3_card_driver *drv = (uhdc_t3_card_driver *)data;
> > > > >       struct snd_pcm_runtime *runtime = drv->substream->runtime;
> > > > >
> > > > >
> > > > >       audio_frame = kmalloc(MAX_AUDIO_SIZE, GFP_DMA);
> > > > >       if(!audio_frame)
> > > > >       {
> > > > >               return -ENOMEM;
> > > > >       }
> > > > >       while(1)
> > > > >       {
> > > > >
> > > > >               if (kthread_should_stop())
> > > > >               {
> > > > >                       dbg_alsa( "###### %s %d\n",__FUNCTION__,__LINE__);
> > > > >                       break;
> > > > >               }
> > > > >               dbg_alsa( "###### Waiting for audio signal %s_%d\n",__FUNCTION__,__LINE__);
> > > > >               wait_event_interruptible (audio_interrupt, (atomic_read (&audio_data_ready)));
> > > > >               atomic_set (&audio_data_ready, 0);
> > > > >               g_count = get_audio_size(g_temp_lro);
> > > > >               count = g_count;
> > > > >               printk( "######audio signal received and audio size:%d runtime->period_size:%d  %s_%d\n",g_count,runtime->period_size,__func__,__LINE__);
> > > > >
> > > > >               /* dma read is done here */
> > > > >               /* audio_frame contains audio data */
> > > > >               memcpy(drv->substream->runtime->dma_area + drv->buf_pos ,audio_frame,count);
> > > > >
> > > > >               /* update the buf_pos */
> > > > >               // here the (auto)increase of buf_pos is handled
> > > > >               drv->buf_pos += count;
> > > > >               drv->buf_pos %= drv->pcm_buffer_size;
> > > > >
> > > > >
> > > > >               printk("\n\n\n hwptr=%d appl=%d pos=%d\n",
> > > > >                       (int)frames_to_bytes(runtime,runtime->status->hw_ptr),(int)frames_to_bytes(runtime, runtime->control->appl_ptr),drv->buf_pos);
> > > > >               /* Below line needs to be uncommented for pointer to be updated in the alsa lib */
> > > > >               snd_pcm_period_elapsed(drv->substream);
> > > > >
> > > > >               try_to_freeze();
> > > > >
> > > > >       }
> > > > >
> > > > >       kfree(audio_frame);
> > > > >       audio_frame = NULL;
> > > > >
> > > > >       return 0 ;
> > > > >
> > > > > }
> > > > > [3 hwptr_app_ptr_buf_pos_analysis.xlsx <application/vnd.openxmlformats-officedocument.spreadsheetml.sheet (base64)>]
> > > > >
> > >
> > >
> > >
> > > --
> > > Thanks and Regards
> > > Chakravarthi Pradeep.K
> > > Ph: 91 9980434900
> > >
> 
> 
> 
> -- 
> Thanks and Regards
> Chakravarthi Pradeep.K
> Ph: 91 9980434900
> 

Re: Fwd: ALSA queries

[Chakravarthi Pradeep]

Hello Takashi,

>You confirmed with putting the debug print, etc?
Yes, its confirmed.

>And drv->buf_pos is the correct position that matches with the
>expected hwptr?  Basically there only these two things.

If DMA size per interrupt is of 4K bytes then drv->buf_pos is updated
with 4K bytes in audio thread. However the same being updated in
pointer call back also.

>From the debug log , sometimes pointer callback is not getting called
and hwptr is zero at this point. When hwptr is zero then no audio in
VLC application. Why pointer call back is not gettting called ?


Regards,
Chakravarthi Pradeep K
On Mon, Aug 6, 2018 at 7:02 PM Takashi Iwai <tiwai@suse.de> wrote:
>
> On Mon, 06 Aug 2018 15:23:31 +0200,
> Chakravarthi Pradeep wrote:
> >
> > Hello Takashi,
> >
> > > OK, so you are sure that the function is really called, not only in
> > > theory, right?  Then the next item to check is the pointer callback.
> > > The hwptr is updated based on the value returned from this callback.
> >
> > I'm sure that I'm calling snd_pcm_period_elapsed() function
>
> You confirmed with putting the debug print, etc?
>
> > and my
> > pointer function is given below:
> >
> > /************************* pointer callback *****************
> > static snd_pcm_uframes_t uhdc_audio_pcm_pointer(struct
> > snd_pcm_substream *substream)
> > {
> > struct snd_pcm_runtime *runtime = substream->runtime;
> > uhdc_t3_card_driver *drv = runtime->private_data;
> > return bytes_to_frames(runtime, drv->buf_pos);
> > }
>
> And drv->buf_pos is the correct position that matches with the
> expected hwptr?  Basically there only these two things.
>
>
> Takashi
>
> >
> >
> > Regards,
> > Chakravarthi Pradeep K
> >
> >
> > On Mon, Aug 6, 2018 at 6:21 PM Takashi Iwai <tiwai@suse.de> wrote:
> > >
> > > On Mon, 06 Aug 2018 14:29:26 +0200,
> > > Chakravarthi Pradeep wrote:
> > > >
> > > > Hello Takashi,
> > > >
> > > > Thanks for your explanation about period and periods.
> > > >
> > > > > Erm, I'm no consultant.  Does your driver issue really
> > > > > snd_pcm_period_elapsed() or not?  You should know that.
> > > > >
> > > > > If the problem happens even if the driver really calls
> > > > > snd_pcm_period_elapsed(), then it's another cause
> > > >
> > > > I'm calling  snd_pcm_period_elapsed() in my audio thread
> > > > snd_pcm_period_elapsed(drv->substream);
> > > > I'm calling this <snd_pcm_period_elapsed()> function after one frame
> > > > is copied to from PCIe device. However, hwptr is not updated and no
> > > > sound in the VLC application.
> > >
> > > OK, so you are sure that the function is really called, not only in
> > > theory, right?  Then the next item to check is the pointer callback.
> > > The hwptr is updated based on the value returned from this callback.
> > >
> > >
> > > Takashi
> > >
> > > >
> > > > Regards,
> > > > Chakravarthi Pradeep K
> > > > On Mon, Aug 6, 2018 at 2:09 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > >
> > > > > On Sun, 05 Aug 2018 20:09:47 +0200,
> > > > > Chakravarthi Pradeep wrote:
> > > > > >
> > > > > > ---------- Forwarded message ---------
> > > > > > From: Chakravarthi Pradeep <doubleq7@gmail.com>
> > > > > > Date: Sun 5 Aug, 2018, 14:19
> > > > > > Subject: Re: [alsa-devel] ALSA queries
> > > > > > To: <tiwai@suse.de>
> > > > > >
> > > > > >
> > > > > > Hello Takashi,
> > > > > >
> > > > > > Thanks for your reply.
> > > > > >
> > > > > >  periods_min = the minimal number of periods
> > > > > >  period_bytes_min = the minimal size of bytes for one period
> > > > > >  period_bytes_max = the maximal size of bytes for one period
> > > > > >
> > > > > >
> > > > > > periods_min = the minimal number of periods :  what is meaning of
> > > > > > periods , is it minimal number of interrupts ?
> > > > >
> > > > > The "period" in ALSA PCM definition represents the interval time (or
> > > > > frames) of the periodical interrupts on the ring buffer.  If the irq
> > > > > is issued for each 256 frames while the ring buffer size is 1024
> > > > > frames, periods = 1024/256 = 4.  The periods_min defines the minimal
> > > > > number of periods the hardware may accept.
> > > > >
> > > > > > period_bytes_min = the minimal size of bytes for one period : it
> > > > > > means, minimal size of bytes per interrupt in case of device, Is it
> > > > > > correct ?
> > > > >
> > > > > Correct.
> > > > >
> > > > > > what about period_max ?
> > > > >
> > > > > The maximal number of periods, the counter-part of periods_min.
> > > > >
> > > > >
> > > > > > It's most likely the ALSA PCM core's safety stop; your driver seem to
> > > > > > have missed snd_pcm_period_elapsed() calls, so the hwptr isn't
> > > > > > updated, resulting in XRUN.  ALSA PCM core checks such XRUN condition
> > > > > > with the own timer.
> > > > > >
> > > > > > I'm attaching my driver thread along with this mail. Can you please
> > > > > > let me know if I have missed something in audio thread. ?. How to make
> > > > > > sure in driver that, trigger stop should be called only when stop
> > > > > > command is sent from application.
> > > > >
> > > > > Erm, I'm no consultant.  Does your driver issue really
> > > > > snd_pcm_period_elapsed() or not?  You should know that.
> > > > >
> > > > > If the problem happens even if the driver really calls
> > > > > snd_pcm_period_elapsed(), then it's another cause.
> > > > >
> > > > > > I'm getting cut cut cut ... noise along with audio in VLC application.
> > > > > > Initially for 2 or 4 seconds, cut cut cut noise is not heard in VLC
> > > > > > application, However after almost after 5 sec ,I can hear cut cut cut
> > > > > > noise in VLC application. With my analysis, hwptr is getting updated
> > > > > > properly however I have doubt in app_ptr. I'm attaching the excl sheet
> > > > > > with hw_ptr,app_ptr and buf_pos values.
> > > > >
> > > > > Do the buffer size and period size are set really as expected?
> > > > > Often the driver misses the fact that PCM core doesn't guarantee the
> > > > > alignment of buffer size and period size unless specified explicitly
> > > > > via hw constraints.  That is, as default, it's possible to set a
> > > > > buffer size 3000 bytes for the period size 64 bytes.  Then the last
> > > > > period is partial.
> > > > >
> > > > > For aligning the period and the buffer sizes, call
> > > > >         snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
> > > > > in the open callback.
> > > > >
> > > > >
> > > > > Takashi
> > > > >
> > > > > >
> > > > > > How to remove the cut cut cut ... noise in audio ?
> > > > > >
> > > > > > Regards,
> > > > > > Chakravarthi
> > > > > >
> > > > > > On Fri, Aug 3, 2018 at 1:05 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > >
> > > > > > > On Thu, 02 Aug 2018 16:31:13 +0200,
> > > > > > > Chakravarthi Pradeep wrote:
> > > > > > > >
> > > > > > > > I'm working on ALSA driver for PCIe card. My ALSA driver and it's
> > > > > > > > initializing struct snd_pcm_hardware with below parameter.
> > > > > > > >
> > > > > > > > /************************ code  start
> > > > > > > > ************************************************/
> > > > > > > > static struct snd_pcm_hardware audio_pcm_hardware = {
> > > > > > > > .info = (SNDRV_PCM_INFO_INTERLEAVED  | SNDRV_PCM_INFO_MMAP |
> > > > > > > > SNDRV_PCM_INFO_MMAP_VALID |
> > > > > > > > SNDRV_PCM_INFO_BLOCK_TRANSFER |
> > > > > > > > SNDRV_PCM_INFO_RESUME ),
> > > > > > > > .formats  =       (SNDRV_PCM_FORMAT_S16_LE | SNDRV_PCM_FORMAT_S24_LE),
> > > > > > > > .rates  = (SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
> > > > > > > > SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_192000),
> > > > > > > > .rate_min  = 44100,
> > > > > > > > .rate_max  = 192000,
> > > > > > > > .channels_min  = 2,
> > > > > > > > .channels_max  = 8,
> > > > > > > > .buffer_bytes_max  = 76800, /*75 kbytes */
> > > > > > > > .period_bytes_min  = 512,//4410, /* (channel (2) * sample_rate (44100)
> > > > > > > > * bit width (24)) / (60 * 8)  */
> > > > > > > > .period_bytes_max  = 16*1024,
> > > > > > > > .periods_min  = 10,
> > > > > > > > .periods_max  = 255,
> > > > > > > >
> > > > > > > > };
> > > > > > > > /************************ code  end
> > > > > > > > ************************************************/
> > > > > > > >
> > > > > > > > 1) I did not understand what is significance of periods_min ,
> > > > > > > > period_bytes_min ,  period_bytes_max and periods_max. Can you please
> > > > > > > > tell me what is importance of these parameter and what value should be
> > > > > > > > mentioned according into ALSA.
> > > > > > >
> > > > > > > These three defines the values your hardware may accept:
> > > > > > >  periods_min = the minimal number of periods
> > > > > > >  period_bytes_min = the minimal size of bytes for one period
> > > > > > >  period_bytes_max = the maximal size of bytes for one period
> > > > > > >
> > > > > > > > 2) snd_pcm_ops trigger callback is getting called in the driver when
> > > > > > > > application sends "start" command. But ALSA driver is stopping by
> > > > > > > > itself after one frame is copied to ALSA framework, without waiting
> > > > > > > > for "stop" command.
> > > > > > > >
> > > > > > > > For instance:
> > > > > > > > In trigger callback , I'm getting these logs after one frame is copied.
> > > > > > > > Trigger:Start (When Play button is selected/clicked in application,
> > > > > > > > Start command is sent to ALSA driver)
> > > > > > > > Dma transfer is completed.
> > > > > > > > Trigger:Stop. (When Stop button is selected/clicked in application,
> > > > > > > > Stop command is sent to ALSA driver. But stop button is not clicked in
> > > > > > > > this case)
> > > > > > >
> > > > > > > It's most likely the ALSA PCM core's safety stop; your driver seem to
> > > > > > > have missed snd_pcm_period_elapsed() calls, so the hwptr isn't
> > > > > > > updated, resulting in XRUN.  ALSA PCM core checks such XRUN condition
> > > > > > > with the own timer.
> > > > > > >
> > > > > > >
> > > > > > > Takashi
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Thanks and Regards
> > > > > > Chakravarthi Pradeep.K
> > > > > > Ph: 91 9980434900
> > > > > > [1.2  <text/html; UTF-8 (quoted-printable)>]
> > > > > >
> > > > > > static int uhdc_audio_thread(void *data)
> > > > > > {
> > > > > >       char *audio_frame = NULL;
> > > > > >       int count = 0;
> > > > > >       uhdc_t3_card_driver *drv = (uhdc_t3_card_driver *)data;
> > > > > >       struct snd_pcm_runtime *runtime = drv->substream->runtime;
> > > > > >
> > > > > >
> > > > > >       audio_frame = kmalloc(MAX_AUDIO_SIZE, GFP_DMA);
> > > > > >       if(!audio_frame)
> > > > > >       {
> > > > > >               return -ENOMEM;
> > > > > >       }
> > > > > >       while(1)
> > > > > >       {
> > > > > >
> > > > > >               if (kthread_should_stop())
> > > > > >               {
> > > > > >                       dbg_alsa( "###### %s %d\n",__FUNCTION__,__LINE__);
> > > > > >                       break;
> > > > > >               }
> > > > > >               dbg_alsa( "###### Waiting for audio signal %s_%d\n",__FUNCTION__,__LINE__);
> > > > > >               wait_event_interruptible (audio_interrupt, (atomic_read (&audio_data_ready)));
> > > > > >               atomic_set (&audio_data_ready, 0);
> > > > > >               g_count = get_audio_size(g_temp_lro);
> > > > > >               count = g_count;
> > > > > >               printk( "######audio signal received and audio size:%d runtime->period_size:%d  %s_%d\n",g_count,runtime->period_size,__func__,__LINE__);
> > > > > >
> > > > > >               /* dma read is done here */
> > > > > >               /* audio_frame contains audio data */
> > > > > >               memcpy(drv->substream->runtime->dma_area + drv->buf_pos ,audio_frame,count);
> > > > > >
> > > > > >               /* update the buf_pos */
> > > > > >               // here the (auto)increase of buf_pos is handled
> > > > > >               drv->buf_pos += count;
> > > > > >               drv->buf_pos %= drv->pcm_buffer_size;
> > > > > >
> > > > > >
> > > > > >               printk("\n\n\n hwptr=%d appl=%d pos=%d\n",
> > > > > >                       (int)frames_to_bytes(runtime,runtime->status->hw_ptr),(int)frames_to_bytes(runtime, runtime->control->appl_ptr),drv->buf_pos);
> > > > > >               /* Below line needs to be uncommented for pointer to be updated in the alsa lib */
> > > > > >               snd_pcm_period_elapsed(drv->substream);
> > > > > >
> > > > > >               try_to_freeze();
> > > > > >
> > > > > >       }
> > > > > >
> > > > > >       kfree(audio_frame);
> > > > > >       audio_frame = NULL;
> > > > > >
> > > > > >       return 0 ;
> > > > > >
> > > > > > }
> > > > > > [3 hwptr_app_ptr_buf_pos_analysis.xlsx <application/vnd.openxmlformats-officedocument.spreadsheetml.sheet (base64)>]
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Thanks and Regards
> > > > Chakravarthi Pradeep.K
> > > > Ph: 91 9980434900
> > > >
> >
> >
> >
> > --
> > Thanks and Regards
> > Chakravarthi Pradeep.K
> > Ph: 91 9980434900
> >



-- 
Thanks and Regards
Chakravarthi Pradeep.K
Ph: 91 9980434900

Re: Fwd: ALSA queries

[Takashi Iwai]

On Mon, 06 Aug 2018 17:24:49 +0200,
Chakravarthi Pradeep wrote:
> 
> Hello Takashi,
> 
> >You confirmed with putting the debug print, etc?
> Yes, its confirmed.
> 
> >And drv->buf_pos is the correct position that matches with the
> >expected hwptr?  Basically there only these two things.
> 
> If DMA size per interrupt is of 4K bytes then drv->buf_pos is updated
> with 4K bytes in audio thread. However the same being updated in
> pointer call back also.
> 
> From the debug log , sometimes pointer callback is not getting called
> and hwptr is zero at this point. When hwptr is zero then no audio in
> VLC application. Why pointer call back is not gettting called ?

If the pointer callback isn't called from snd_pcm_period_elapsed(),
the only reason would be that the stream isn't in the running state,
which is already inconsistent for the condition to call
snd_pcm_period_elapsed().  Otherwise it calls snd_pcm_update_hw_ptr0()
and there the pointer callback gets called unconditionally.

So, either the measurement is wrong, or the stream is already screwed
up at the time you call snd_pcm_period_elapsed().

Again, snd_pcm_period_elapsed() itself calls the pointer callback,
hence the driver must know the exact position at that timing.  If
you're using a multi threading, make sure that the updated pointer has
been already propagated at snd_pcm_period_elapsed() is called in
another thread, for example.


Takashi

> 
> Regards,
> Chakravarthi Pradeep K
> On Mon, Aug 6, 2018 at 7:02 PM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > On Mon, 06 Aug 2018 15:23:31 +0200,
> > Chakravarthi Pradeep wrote:
> > >
> > > Hello Takashi,
> > >
> > > > OK, so you are sure that the function is really called, not only in
> > > > theory, right?  Then the next item to check is the pointer callback.
> > > > The hwptr is updated based on the value returned from this callback.
> > >
> > > I'm sure that I'm calling snd_pcm_period_elapsed() function
> >
> > You confirmed with putting the debug print, etc?
> >
> > > and my
> > > pointer function is given below:
> > >
> > > /************************* pointer callback *****************
> > > static snd_pcm_uframes_t uhdc_audio_pcm_pointer(struct
> > > snd_pcm_substream *substream)
> > > {
> > > struct snd_pcm_runtime *runtime = substream->runtime;
> > > uhdc_t3_card_driver *drv = runtime->private_data;
> > > return bytes_to_frames(runtime, drv->buf_pos);
> > > }
> >
> > And drv->buf_pos is the correct position that matches with the
> > expected hwptr?  Basically there only these two things.
> >
> >
> > Takashi
> >
> > >
> > >
> > > Regards,
> > > Chakravarthi Pradeep K
> > >
> > >
> > > On Mon, Aug 6, 2018 at 6:21 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > >
> > > > On Mon, 06 Aug 2018 14:29:26 +0200,
> > > > Chakravarthi Pradeep wrote:
> > > > >
> > > > > Hello Takashi,
> > > > >
> > > > > Thanks for your explanation about period and periods.
> > > > >
> > > > > > Erm, I'm no consultant.  Does your driver issue really
> > > > > > snd_pcm_period_elapsed() or not?  You should know that.
> > > > > >
> > > > > > If the problem happens even if the driver really calls
> > > > > > snd_pcm_period_elapsed(), then it's another cause
> > > > >
> > > > > I'm calling  snd_pcm_period_elapsed() in my audio thread
> > > > > snd_pcm_period_elapsed(drv->substream);
> > > > > I'm calling this <snd_pcm_period_elapsed()> function after one frame
> > > > > is copied to from PCIe device. However, hwptr is not updated and no
> > > > > sound in the VLC application.
> > > >
> > > > OK, so you are sure that the function is really called, not only in
> > > > theory, right?  Then the next item to check is the pointer callback.
> > > > The hwptr is updated based on the value returned from this callback.
> > > >
> > > >
> > > > Takashi
> > > >
> > > > >
> > > > > Regards,
> > > > > Chakravarthi Pradeep K
> > > > > On Mon, Aug 6, 2018 at 2:09 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > >
> > > > > > On Sun, 05 Aug 2018 20:09:47 +0200,
> > > > > > Chakravarthi Pradeep wrote:
> > > > > > >
> > > > > > > ---------- Forwarded message ---------
> > > > > > > From: Chakravarthi Pradeep <doubleq7@gmail.com>
> > > > > > > Date: Sun 5 Aug, 2018, 14:19
> > > > > > > Subject: Re: [alsa-devel] ALSA queries
> > > > > > > To: <tiwai@suse.de>
> > > > > > >
> > > > > > >
> > > > > > > Hello Takashi,
> > > > > > >
> > > > > > > Thanks for your reply.
> > > > > > >
> > > > > > >  periods_min = the minimal number of periods
> > > > > > >  period_bytes_min = the minimal size of bytes for one period
> > > > > > >  period_bytes_max = the maximal size of bytes for one period
> > > > > > >
> > > > > > >
> > > > > > > periods_min = the minimal number of periods :  what is meaning of
> > > > > > > periods , is it minimal number of interrupts ?
> > > > > >
> > > > > > The "period" in ALSA PCM definition represents the interval time (or
> > > > > > frames) of the periodical interrupts on the ring buffer.  If the irq
> > > > > > is issued for each 256 frames while the ring buffer size is 1024
> > > > > > frames, periods = 1024/256 = 4.  The periods_min defines the minimal
> > > > > > number of periods the hardware may accept.
> > > > > >
> > > > > > > period_bytes_min = the minimal size of bytes for one period : it
> > > > > > > means, minimal size of bytes per interrupt in case of device, Is it
> > > > > > > correct ?
> > > > > >
> > > > > > Correct.
> > > > > >
> > > > > > > what about period_max ?
> > > > > >
> > > > > > The maximal number of periods, the counter-part of periods_min.
> > > > > >
> > > > > >
> > > > > > > It's most likely the ALSA PCM core's safety stop; your driver seem to
> > > > > > > have missed snd_pcm_period_elapsed() calls, so the hwptr isn't
> > > > > > > updated, resulting in XRUN.  ALSA PCM core checks such XRUN condition
> > > > > > > with the own timer.
> > > > > > >
> > > > > > > I'm attaching my driver thread along with this mail. Can you please
> > > > > > > let me know if I have missed something in audio thread. ?. How to make
> > > > > > > sure in driver that, trigger stop should be called only when stop
> > > > > > > command is sent from application.
> > > > > >
> > > > > > Erm, I'm no consultant.  Does your driver issue really
> > > > > > snd_pcm_period_elapsed() or not?  You should know that.
> > > > > >
> > > > > > If the problem happens even if the driver really calls
> > > > > > snd_pcm_period_elapsed(), then it's another cause.
> > > > > >
> > > > > > > I'm getting cut cut cut ... noise along with audio in VLC application.
> > > > > > > Initially for 2 or 4 seconds, cut cut cut noise is not heard in VLC
> > > > > > > application, However after almost after 5 sec ,I can hear cut cut cut
> > > > > > > noise in VLC application. With my analysis, hwptr is getting updated
> > > > > > > properly however I have doubt in app_ptr. I'm attaching the excl sheet
> > > > > > > with hw_ptr,app_ptr and buf_pos values.
> > > > > >
> > > > > > Do the buffer size and period size are set really as expected?
> > > > > > Often the driver misses the fact that PCM core doesn't guarantee the
> > > > > > alignment of buffer size and period size unless specified explicitly
> > > > > > via hw constraints.  That is, as default, it's possible to set a
> > > > > > buffer size 3000 bytes for the period size 64 bytes.  Then the last
> > > > > > period is partial.
> > > > > >
> > > > > > For aligning the period and the buffer sizes, call
> > > > > >         snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
> > > > > > in the open callback.
> > > > > >
> > > > > >
> > > > > > Takashi
> > > > > >
> > > > > > >
> > > > > > > How to remove the cut cut cut ... noise in audio ?
> > > > > > >
> > > > > > > Regards,
> > > > > > > Chakravarthi
> > > > > > >
> > > > > > > On Fri, Aug 3, 2018 at 1:05 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > >
> > > > > > > > On Thu, 02 Aug 2018 16:31:13 +0200,
> > > > > > > > Chakravarthi Pradeep wrote:
> > > > > > > > >
> > > > > > > > > I'm working on ALSA driver for PCIe card. My ALSA driver and it's
> > > > > > > > > initializing struct snd_pcm_hardware with below parameter.
> > > > > > > > >
> > > > > > > > > /************************ code  start
> > > > > > > > > ************************************************/
> > > > > > > > > static struct snd_pcm_hardware audio_pcm_hardware = {
> > > > > > > > > .info = (SNDRV_PCM_INFO_INTERLEAVED  | SNDRV_PCM_INFO_MMAP |
> > > > > > > > > SNDRV_PCM_INFO_MMAP_VALID |
> > > > > > > > > SNDRV_PCM_INFO_BLOCK_TRANSFER |
> > > > > > > > > SNDRV_PCM_INFO_RESUME ),
> > > > > > > > > .formats  =       (SNDRV_PCM_FORMAT_S16_LE | SNDRV_PCM_FORMAT_S24_LE),
> > > > > > > > > .rates  = (SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
> > > > > > > > > SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_192000),
> > > > > > > > > .rate_min  = 44100,
> > > > > > > > > .rate_max  = 192000,
> > > > > > > > > .channels_min  = 2,
> > > > > > > > > .channels_max  = 8,
> > > > > > > > > .buffer_bytes_max  = 76800, /*75 kbytes */
> > > > > > > > > .period_bytes_min  = 512,//4410, /* (channel (2) * sample_rate (44100)
> > > > > > > > > * bit width (24)) / (60 * 8)  */
> > > > > > > > > .period_bytes_max  = 16*1024,
> > > > > > > > > .periods_min  = 10,
> > > > > > > > > .periods_max  = 255,
> > > > > > > > >
> > > > > > > > > };
> > > > > > > > > /************************ code  end
> > > > > > > > > ************************************************/
> > > > > > > > >
> > > > > > > > > 1) I did not understand what is significance of periods_min ,
> > > > > > > > > period_bytes_min ,  period_bytes_max and periods_max. Can you please
> > > > > > > > > tell me what is importance of these parameter and what value should be
> > > > > > > > > mentioned according into ALSA.
> > > > > > > >
> > > > > > > > These three defines the values your hardware may accept:
> > > > > > > >  periods_min = the minimal number of periods
> > > > > > > >  period_bytes_min = the minimal size of bytes for one period
> > > > > > > >  period_bytes_max = the maximal size of bytes for one period
> > > > > > > >
> > > > > > > > > 2) snd_pcm_ops trigger callback is getting called in the driver when
> > > > > > > > > application sends "start" command. But ALSA driver is stopping by
> > > > > > > > > itself after one frame is copied to ALSA framework, without waiting
> > > > > > > > > for "stop" command.
> > > > > > > > >
> > > > > > > > > For instance:
> > > > > > > > > In trigger callback , I'm getting these logs after one frame is copied.
> > > > > > > > > Trigger:Start (When Play button is selected/clicked in application,
> > > > > > > > > Start command is sent to ALSA driver)
> > > > > > > > > Dma transfer is completed.
> > > > > > > > > Trigger:Stop. (When Stop button is selected/clicked in application,
> > > > > > > > > Stop command is sent to ALSA driver. But stop button is not clicked in
> > > > > > > > > this case)
> > > > > > > >
> > > > > > > > It's most likely the ALSA PCM core's safety stop; your driver seem to
> > > > > > > > have missed snd_pcm_period_elapsed() calls, so the hwptr isn't
> > > > > > > > updated, resulting in XRUN.  ALSA PCM core checks such XRUN condition
> > > > > > > > with the own timer.
> > > > > > > >
> > > > > > > >
> > > > > > > > Takashi
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Thanks and Regards
> > > > > > > Chakravarthi Pradeep.K
> > > > > > > Ph: 91 9980434900
> > > > > > > [1.2  <text/html; UTF-8 (quoted-printable)>]
> > > > > > >
> > > > > > > static int uhdc_audio_thread(void *data)
> > > > > > > {
> > > > > > >       char *audio_frame = NULL;
> > > > > > >       int count = 0;
> > > > > > >       uhdc_t3_card_driver *drv = (uhdc_t3_card_driver *)data;
> > > > > > >       struct snd_pcm_runtime *runtime = drv->substream->runtime;
> > > > > > >
> > > > > > >
> > > > > > >       audio_frame = kmalloc(MAX_AUDIO_SIZE, GFP_DMA);
> > > > > > >       if(!audio_frame)
> > > > > > >       {
> > > > > > >               return -ENOMEM;
> > > > > > >       }
> > > > > > >       while(1)
> > > > > > >       {
> > > > > > >
> > > > > > >               if (kthread_should_stop())
> > > > > > >               {
> > > > > > >                       dbg_alsa( "###### %s %d\n",__FUNCTION__,__LINE__);
> > > > > > >                       break;
> > > > > > >               }
> > > > > > >               dbg_alsa( "###### Waiting for audio signal %s_%d\n",__FUNCTION__,__LINE__);
> > > > > > >               wait_event_interruptible (audio_interrupt, (atomic_read (&audio_data_ready)));
> > > > > > >               atomic_set (&audio_data_ready, 0);
> > > > > > >               g_count = get_audio_size(g_temp_lro);
> > > > > > >               count = g_count;
> > > > > > >               printk( "######audio signal received and audio size:%d runtime->period_size:%d  %s_%d\n",g_count,runtime->period_size,__func__,__LINE__);
> > > > > > >
> > > > > > >               /* dma read is done here */
> > > > > > >               /* audio_frame contains audio data */
> > > > > > >               memcpy(drv->substream->runtime->dma_area + drv->buf_pos ,audio_frame,count);
> > > > > > >
> > > > > > >               /* update the buf_pos */
> > > > > > >               // here the (auto)increase of buf_pos is handled
> > > > > > >               drv->buf_pos += count;
> > > > > > >               drv->buf_pos %= drv->pcm_buffer_size;
> > > > > > >
> > > > > > >
> > > > > > >               printk("\n\n\n hwptr=%d appl=%d pos=%d\n",
> > > > > > >                       (int)frames_to_bytes(runtime,runtime->status->hw_ptr),(int)frames_to_bytes(runtime, runtime->control->appl_ptr),drv->buf_pos);
> > > > > > >               /* Below line needs to be uncommented for pointer to be updated in the alsa lib */
> > > > > > >               snd_pcm_period_elapsed(drv->substream);
> > > > > > >
> > > > > > >               try_to_freeze();
> > > > > > >
> > > > > > >       }
> > > > > > >
> > > > > > >       kfree(audio_frame);
> > > > > > >       audio_frame = NULL;
> > > > > > >
> > > > > > >       return 0 ;
> > > > > > >
> > > > > > > }
> > > > > > > [3 hwptr_app_ptr_buf_pos_analysis.xlsx <application/vnd.openxmlformats-officedocument.spreadsheetml.sheet (base64)>]
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Thanks and Regards
> > > > > Chakravarthi Pradeep.K
> > > > > Ph: 91 9980434900
> > > > >
> > >
> > >
> > >
> > > --
> > > Thanks and Regards
> > > Chakravarthi Pradeep.K
> > > Ph: 91 9980434900
> > >
> 
> 
> 
> -- 
> Thanks and Regards
> Chakravarthi Pradeep.K
> Ph: 91 9980434900
> 

Re: Fwd: ALSA queries

[Chakravarthi Pradeep]

Dear Takashi,

Trigger stop is getting called , because of this hwptr is zero and
pointer call back is not getting called. Below is my log from driver.

[  838.491681] Trigger:Start
[  839.522233] hwptr=0 buf_pos:3456
[  839.522244] buf_pos :3456 bytes_to_frames:864 uhdc_audio_pcm_pointer_253
[  839.522249] Trigger:Stop

In normal scenario, Trigger stop is not getting called and audio was
able to render in the VLC application. Below log for normal scenario,
[  802.785893] Trigger:Start
[  814.288309] hwptr=0 buf_pos:6272
[  814.288323] buf_pos :6272 bytes_to_frames:1568 uhdc_audio_pcm_pointer_253
[  814.288362] buf_pos :6272 bytes_to_frames:1568 uhdc_audio_pcm_pointer_253
[  814.288378] buf_pos :6272 bytes_to_frames:1568 uhdc_audio_pcm_pointer_253
[  814.305079] hwptr=6272 buf_pos:9472
[  814.305091] buf_pos :9472 bytes_to_frames:2368 uhdc_audio_pcm_pointer_253
[  814.321741] hwptr=9472 buf_pos:12672
[  814.321748] buf_pos :12672 bytes_to_frames:3168 uhdc_audio_pcm_pointer_253
[  814.321777] buf_pos :12672 bytes_to_frames:3168 uhdc_audio_pcm_pointer_253
[  814.321785] buf_pos :12672 bytes_to_frames:3168 uhdc_audio_pcm_pointer_253
[  814.338452] hwptr=12672 buf_pos:15872
[  814.338459] buf_pos :15872 bytes_to_frames:3968 uhdc_audio_pcm_pointer_253
[  814.355242] hwptr=15872 buf_pos:19072
[  814.355248] buf_pos :19072 bytes_to_frames:4768 uhdc_audio_pcm_pointer_253
[  814.355288] buf_pos :19072 bytes_to_frames:4768 uhdc_audio_pcm_pointer_253
[  814.355294] buf_pos :19072 bytes_to_frames:4768 uhdc_audio_pcm_pointer_253
[  814.371822] hwptr=19072 buf_pos:22272
...
...
[  830.739031] Trigger:Stop


I can not do rmmod for ALSA driver. If I do sudo rmmod mydriver then it says
"rmmod: ERROR: Module mydriver is in use"

How can I remove mydriver module from linux kernel ?

Regards,
Chakravarthi Pradeep


On Mon, Aug 6, 2018 at 9:00 PM Takashi Iwai <tiwai@suse.de> wrote:
>
> On Mon, 06 Aug 2018 17:24:49 +0200,
> Chakravarthi Pradeep wrote:
> >
> > Hello Takashi,
> >
> > >You confirmed with putting the debug print, etc?
> > Yes, its confirmed.
> >
> > >And drv->buf_pos is the correct position that matches with the
> > >expected hwptr?  Basically there only these two things.
> >
> > If DMA size per interrupt is of 4K bytes then drv->buf_pos is updated
> > with 4K bytes in audio thread. However the same being updated in
> > pointer call back also.
> >
> > From the debug log , sometimes pointer callback is not getting called
> > and hwptr is zero at this point. When hwptr is zero then no audio in
> > VLC application. Why pointer call back is not gettting called ?
>
> If the pointer callback isn't called from snd_pcm_period_elapsed(),
> the only reason would be that the stream isn't in the running state,
> which is already inconsistent for the condition to call
> snd_pcm_period_elapsed().  Otherwise it calls snd_pcm_update_hw_ptr0()
> and there the pointer callback gets called unconditionally.
>
> So, either the measurement is wrong, or the stream is already screwed
> up at the time you call snd_pcm_period_elapsed().
>
> Again, snd_pcm_period_elapsed() itself calls the pointer callback,
> hence the driver must know the exact position at that timing.  If
> you're using a multi threading, make sure that the updated pointer has
> been already propagated at snd_pcm_period_elapsed() is called in
> another thread, for example.
>
>
> Takashi
>
> >
> > Regards,
> > Chakravarthi Pradeep K
> > On Mon, Aug 6, 2018 at 7:02 PM Takashi Iwai <tiwai@suse.de> wrote:
> > >
> > > On Mon, 06 Aug 2018 15:23:31 +0200,
> > > Chakravarthi Pradeep wrote:
> > > >
> > > > Hello Takashi,
> > > >
> > > > > OK, so you are sure that the function is really called, not only in
> > > > > theory, right?  Then the next item to check is the pointer callback.
> > > > > The hwptr is updated based on the value returned from this callback.
> > > >
> > > > I'm sure that I'm calling snd_pcm_period_elapsed() function
> > >
> > > You confirmed with putting the debug print, etc?
> > >
> > > > and my
> > > > pointer function is given below:
> > > >
> > > > /************************* pointer callback *****************
> > > > static snd_pcm_uframes_t uhdc_audio_pcm_pointer(struct
> > > > snd_pcm_substream *substream)
> > > > {
> > > > struct snd_pcm_runtime *runtime = substream->runtime;
> > > > uhdc_t3_card_driver *drv = runtime->private_data;
> > > > return bytes_to_frames(runtime, drv->buf_pos);
> > > > }
> > >
> > > And drv->buf_pos is the correct position that matches with the
> > > expected hwptr?  Basically there only these two things.
> > >
> > >
> > > Takashi
> > >
> > > >
> > > >
> > > > Regards,
> > > > Chakravarthi Pradeep K
> > > >
> > > >
> > > > On Mon, Aug 6, 2018 at 6:21 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > >
> > > > > On Mon, 06 Aug 2018 14:29:26 +0200,
> > > > > Chakravarthi Pradeep wrote:
> > > > > >
> > > > > > Hello Takashi,
> > > > > >
> > > > > > Thanks for your explanation about period and periods.
> > > > > >
> > > > > > > Erm, I'm no consultant.  Does your driver issue really
> > > > > > > snd_pcm_period_elapsed() or not?  You should know that.
> > > > > > >
> > > > > > > If the problem happens even if the driver really calls
> > > > > > > snd_pcm_period_elapsed(), then it's another cause
> > > > > >
> > > > > > I'm calling  snd_pcm_period_elapsed() in my audio thread
> > > > > > snd_pcm_period_elapsed(drv->substream);
> > > > > > I'm calling this <snd_pcm_period_elapsed()> function after one frame
> > > > > > is copied to from PCIe device. However, hwptr is not updated and no
> > > > > > sound in the VLC application.
> > > > >
> > > > > OK, so you are sure that the function is really called, not only in
> > > > > theory, right?  Then the next item to check is the pointer callback.
> > > > > The hwptr is updated based on the value returned from this callback.
> > > > >
> > > > >
> > > > > Takashi
> > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Chakravarthi Pradeep K
> > > > > > On Mon, Aug 6, 2018 at 2:09 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > >
> > > > > > > On Sun, 05 Aug 2018 20:09:47 +0200,
> > > > > > > Chakravarthi Pradeep wrote:
> > > > > > > >
> > > > > > > > ---------- Forwarded message ---------
> > > > > > > > From: Chakravarthi Pradeep <doubleq7@gmail.com>
> > > > > > > > Date: Sun 5 Aug, 2018, 14:19
> > > > > > > > Subject: Re: [alsa-devel] ALSA queries
> > > > > > > > To: <tiwai@suse.de>
> > > > > > > >
> > > > > > > >
> > > > > > > > Hello Takashi,
> > > > > > > >
> > > > > > > > Thanks for your reply.
> > > > > > > >
> > > > > > > >  periods_min = the minimal number of periods
> > > > > > > >  period_bytes_min = the minimal size of bytes for one period
> > > > > > > >  period_bytes_max = the maximal size of bytes for one period
> > > > > > > >
> > > > > > > >
> > > > > > > > periods_min = the minimal number of periods :  what is meaning of
> > > > > > > > periods , is it minimal number of interrupts ?
> > > > > > >
> > > > > > > The "period" in ALSA PCM definition represents the interval time (or
> > > > > > > frames) of the periodical interrupts on the ring buffer.  If the irq
> > > > > > > is issued for each 256 frames while the ring buffer size is 1024
> > > > > > > frames, periods = 1024/256 = 4.  The periods_min defines the minimal
> > > > > > > number of periods the hardware may accept.
> > > > > > >
> > > > > > > > period_bytes_min = the minimal size of bytes for one period : it
> > > > > > > > means, minimal size of bytes per interrupt in case of device, Is it
> > > > > > > > correct ?
> > > > > > >
> > > > > > > Correct.
> > > > > > >
> > > > > > > > what about period_max ?
> > > > > > >
> > > > > > > The maximal number of periods, the counter-part of periods_min.
> > > > > > >
> > > > > > >
> > > > > > > > It's most likely the ALSA PCM core's safety stop; your driver seem to
> > > > > > > > have missed snd_pcm_period_elapsed() calls, so the hwptr isn't
> > > > > > > > updated, resulting in XRUN.  ALSA PCM core checks such XRUN condition
> > > > > > > > with the own timer.
> > > > > > > >
> > > > > > > > I'm attaching my driver thread along with this mail. Can you please
> > > > > > > > let me know if I have missed something in audio thread. ?. How to make
> > > > > > > > sure in driver that, trigger stop should be called only when stop
> > > > > > > > command is sent from application.
> > > > > > >
> > > > > > > Erm, I'm no consultant.  Does your driver issue really
> > > > > > > snd_pcm_period_elapsed() or not?  You should know that.
> > > > > > >
> > > > > > > If the problem happens even if the driver really calls
> > > > > > > snd_pcm_period_elapsed(), then it's another cause.
> > > > > > >
> > > > > > > > I'm getting cut cut cut ... noise along with audio in VLC application.
> > > > > > > > Initially for 2 or 4 seconds, cut cut cut noise is not heard in VLC
> > > > > > > > application, However after almost after 5 sec ,I can hear cut cut cut
> > > > > > > > noise in VLC application. With my analysis, hwptr is getting updated
> > > > > > > > properly however I have doubt in app_ptr. I'm attaching the excl sheet
> > > > > > > > with hw_ptr,app_ptr and buf_pos values.
> > > > > > >
> > > > > > > Do the buffer size and period size are set really as expected?
> > > > > > > Often the driver misses the fact that PCM core doesn't guarantee the
> > > > > > > alignment of buffer size and period size unless specified explicitly
> > > > > > > via hw constraints.  That is, as default, it's possible to set a
> > > > > > > buffer size 3000 bytes for the period size 64 bytes.  Then the last
> > > > > > > period is partial.
> > > > > > >
> > > > > > > For aligning the period and the buffer sizes, call
> > > > > > >         snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
> > > > > > > in the open callback.
> > > > > > >
> > > > > > >
> > > > > > > Takashi
> > > > > > >
> > > > > > > >
> > > > > > > > How to remove the cut cut cut ... noise in audio ?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Chakravarthi
> > > > > > > >
> > > > > > > > On Fri, Aug 3, 2018 at 1:05 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, 02 Aug 2018 16:31:13 +0200,
> > > > > > > > > Chakravarthi Pradeep wrote:
> > > > > > > > > >
> > > > > > > > > > I'm working on ALSA driver for PCIe card. My ALSA driver and it's
> > > > > > > > > > initializing struct snd_pcm_hardware with below parameter.
> > > > > > > > > >
> > > > > > > > > > /************************ code  start
> > > > > > > > > > ************************************************/
> > > > > > > > > > static struct snd_pcm_hardware audio_pcm_hardware = {
> > > > > > > > > > .info = (SNDRV_PCM_INFO_INTERLEAVED  | SNDRV_PCM_INFO_MMAP |
> > > > > > > > > > SNDRV_PCM_INFO_MMAP_VALID |
> > > > > > > > > > SNDRV_PCM_INFO_BLOCK_TRANSFER |
> > > > > > > > > > SNDRV_PCM_INFO_RESUME ),
> > > > > > > > > > .formats  =       (SNDRV_PCM_FORMAT_S16_LE | SNDRV_PCM_FORMAT_S24_LE),
> > > > > > > > > > .rates  = (SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
> > > > > > > > > > SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_192000),
> > > > > > > > > > .rate_min  = 44100,
> > > > > > > > > > .rate_max  = 192000,
> > > > > > > > > > .channels_min  = 2,
> > > > > > > > > > .channels_max  = 8,
> > > > > > > > > > .buffer_bytes_max  = 76800, /*75 kbytes */
> > > > > > > > > > .period_bytes_min  = 512,//4410, /* (channel (2) * sample_rate (44100)
> > > > > > > > > > * bit width (24)) / (60 * 8)  */
> > > > > > > > > > .period_bytes_max  = 16*1024,
> > > > > > > > > > .periods_min  = 10,
> > > > > > > > > > .periods_max  = 255,
> > > > > > > > > >
> > > > > > > > > > };
> > > > > > > > > > /************************ code  end
> > > > > > > > > > ************************************************/
> > > > > > > > > >
> > > > > > > > > > 1) I did not understand what is significance of periods_min ,
> > > > > > > > > > period_bytes_min ,  period_bytes_max and periods_max. Can you please
> > > > > > > > > > tell me what is importance of these parameter and what value should be
> > > > > > > > > > mentioned according into ALSA.
> > > > > > > > >
> > > > > > > > > These three defines the values your hardware may accept:
> > > > > > > > >  periods_min = the minimal number of periods
> > > > > > > > >  period_bytes_min = the minimal size of bytes for one period
> > > > > > > > >  period_bytes_max = the maximal size of bytes for one period
> > > > > > > > >
> > > > > > > > > > 2) snd_pcm_ops trigger callback is getting called in the driver when
> > > > > > > > > > application sends "start" command. But ALSA driver is stopping by
> > > > > > > > > > itself after one frame is copied to ALSA framework, without waiting
> > > > > > > > > > for "stop" command.
> > > > > > > > > >
> > > > > > > > > > For instance:
> > > > > > > > > > In trigger callback , I'm getting these logs after one frame is copied.
> > > > > > > > > > Trigger:Start (When Play button is selected/clicked in application,
> > > > > > > > > > Start command is sent to ALSA driver)
> > > > > > > > > > Dma transfer is completed.
> > > > > > > > > > Trigger:Stop. (When Stop button is selected/clicked in application,
> > > > > > > > > > Stop command is sent to ALSA driver. But stop button is not clicked in
> > > > > > > > > > this case)
> > > > > > > > >
> > > > > > > > > It's most likely the ALSA PCM core's safety stop; your driver seem to
> > > > > > > > > have missed snd_pcm_period_elapsed() calls, so the hwptr isn't
> > > > > > > > > updated, resulting in XRUN.  ALSA PCM core checks such XRUN condition
> > > > > > > > > with the own timer.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Takashi
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Thanks and Regards
> > > > > > > > Chakravarthi Pradeep.K
> > > > > > > > Ph: 91 9980434900
> > > > > > > > [1.2  <text/html; UTF-8 (quoted-printable)>]
> > > > > > > >
> > > > > > > > static int uhdc_audio_thread(void *data)
> > > > > > > > {
> > > > > > > >       char *audio_frame = NULL;
> > > > > > > >       int count = 0;
> > > > > > > >       uhdc_t3_card_driver *drv = (uhdc_t3_card_driver *)data;
> > > > > > > >       struct snd_pcm_runtime *runtime = drv->substream->runtime;
> > > > > > > >
> > > > > > > >
> > > > > > > >       audio_frame = kmalloc(MAX_AUDIO_SIZE, GFP_DMA);
> > > > > > > >       if(!audio_frame)
> > > > > > > >       {
> > > > > > > >               return -ENOMEM;
> > > > > > > >       }
> > > > > > > >       while(1)
> > > > > > > >       {
> > > > > > > >
> > > > > > > >               if (kthread_should_stop())
> > > > > > > >               {
> > > > > > > >                       dbg_alsa( "###### %s %d\n",__FUNCTION__,__LINE__);
> > > > > > > >                       break;
> > > > > > > >               }
> > > > > > > >               dbg_alsa( "###### Waiting for audio signal %s_%d\n",__FUNCTION__,__LINE__);
> > > > > > > >               wait_event_interruptible (audio_interrupt, (atomic_read (&audio_data_ready)));
> > > > > > > >               atomic_set (&audio_data_ready, 0);
> > > > > > > >               g_count = get_audio_size(g_temp_lro);
> > > > > > > >               count = g_count;
> > > > > > > >               printk( "######audio signal received and audio size:%d runtime->period_size:%d  %s_%d\n",g_count,runtime->period_size,__func__,__LINE__);
> > > > > > > >
> > > > > > > >               /* dma read is done here */
> > > > > > > >               /* audio_frame contains audio data */
> > > > > > > >               memcpy(drv->substream->runtime->dma_area + drv->buf_pos ,audio_frame,count);
> > > > > > > >
> > > > > > > >               /* update the buf_pos */
> > > > > > > >               // here the (auto)increase of buf_pos is handled
> > > > > > > >               drv->buf_pos += count;
> > > > > > > >               drv->buf_pos %= drv->pcm_buffer_size;
> > > > > > > >
> > > > > > > >
> > > > > > > >               printk("\n\n\n hwptr=%d appl=%d pos=%d\n",
> > > > > > > >                       (int)frames_to_bytes(runtime,runtime->status->hw_ptr),(int)frames_to_bytes(runtime, runtime->control->appl_ptr),drv->buf_pos);
> > > > > > > >               /* Below line needs to be uncommented for pointer to be updated in the alsa lib */
> > > > > > > >               snd_pcm_period_elapsed(drv->substream);
> > > > > > > >
> > > > > > > >               try_to_freeze();
> > > > > > > >
> > > > > > > >       }
> > > > > > > >
> > > > > > > >       kfree(audio_frame);
> > > > > > > >       audio_frame = NULL;
> > > > > > > >
> > > > > > > >       return 0 ;
> > > > > > > >
> > > > > > > > }
> > > > > > > > [3 hwptr_app_ptr_buf_pos_analysis.xlsx <application/vnd.openxmlformats-officedocument.spreadsheetml.sheet (base64)>]
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Thanks and Regards
> > > > > > Chakravarthi Pradeep.K
> > > > > > Ph: 91 9980434900
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Thanks and Regards
> > > > Chakravarthi Pradeep.K
> > > > Ph: 91 9980434900
> > > >
> >
> >
> >
> > --
> > Thanks and Regards
> > Chakravarthi Pradeep.K
> > Ph: 91 9980434900
> >



-- 
Thanks and Regards
Chakravarthi Pradeep.K
Ph: 91 9980434900

Re: Fwd: ALSA queries

[Takashi Iwai]

On Tue, 07 Aug 2018 13:59:46 +0200,
Chakravarthi Pradeep wrote:
> 
> Dear Takashi,
> 
> Trigger stop is getting called , because of this hwptr is zero and
> pointer call back is not getting called. Below is my log from driver.
> 
> [  838.491681] Trigger:Start
> [  839.522233] hwptr=0 buf_pos:3456
> [  839.522244] buf_pos :3456 bytes_to_frames:864 uhdc_audio_pcm_pointer_253
> [  839.522249] Trigger:Stop

Then you need to figure out the code path of the trigger stop.

> In normal scenario, Trigger stop is not getting called and audio was
> able to render in the VLC application. Below log for normal scenario,
> [  802.785893] Trigger:Start
> [  814.288309] hwptr=0 buf_pos:6272
> [  814.288323] buf_pos :6272 bytes_to_frames:1568 uhdc_audio_pcm_pointer_253
> [  814.288362] buf_pos :6272 bytes_to_frames:1568 uhdc_audio_pcm_pointer_253
> [  814.288378] buf_pos :6272 bytes_to_frames:1568 uhdc_audio_pcm_pointer_253
> [  814.305079] hwptr=6272 buf_pos:9472
> [  814.305091] buf_pos :9472 bytes_to_frames:2368 uhdc_audio_pcm_pointer_253
> [  814.321741] hwptr=9472 buf_pos:12672
> [  814.321748] buf_pos :12672 bytes_to_frames:3168 uhdc_audio_pcm_pointer_253
> [  814.321777] buf_pos :12672 bytes_to_frames:3168 uhdc_audio_pcm_pointer_253
> [  814.321785] buf_pos :12672 bytes_to_frames:3168 uhdc_audio_pcm_pointer_253
> [  814.338452] hwptr=12672 buf_pos:15872
> [  814.338459] buf_pos :15872 bytes_to_frames:3968 uhdc_audio_pcm_pointer_253
> [  814.355242] hwptr=15872 buf_pos:19072
> [  814.355248] buf_pos :19072 bytes_to_frames:4768 uhdc_audio_pcm_pointer_253
> [  814.355288] buf_pos :19072 bytes_to_frames:4768 uhdc_audio_pcm_pointer_253
> [  814.355294] buf_pos :19072 bytes_to_frames:4768 uhdc_audio_pcm_pointer_253
> [  814.371822] hwptr=19072 buf_pos:22272
> ...
> ...
> [  830.739031] Trigger:Stop
> 
> 
> I can not do rmmod for ALSA driver. If I do sudo rmmod mydriver then it says
> "rmmod: ERROR: Module mydriver is in use"
> 
> How can I remove mydriver module from linux kernel ?

Likely some program is using the sound device.  For example, a mixer
applet or PulseAudio keeps opening the control device.
Check it via "fuser -v /dev/snd/*"


Takashi

Re: Fwd: ALSA queries

[Chakravarthi Pradeep]

Dear Takashi,

In previous mail you have mentioned
> So, either the measurement is wrong, or the stream is already screwed
> up at the time you call snd_pcm_period_elapsed().

what it means "measurement is wrong"  and how to make that measurement
is correct ?

Regards,
Chakravarthi
On Tue, Aug 7, 2018 at 5:33 PM Takashi Iwai <tiwai@suse.de> wrote:
>
> On Tue, 07 Aug 2018 13:59:46 +0200,
> Chakravarthi Pradeep wrote:
> >
> > Dear Takashi,
> >
> > Trigger stop is getting called , because of this hwptr is zero and
> > pointer call back is not getting called. Below is my log from driver.
> >
> > [  838.491681] Trigger:Start
> > [  839.522233] hwptr=0 buf_pos:3456
> > [  839.522244] buf_pos :3456 bytes_to_frames:864 uhdc_audio_pcm_pointer_253
> > [  839.522249] Trigger:Stop
>
> Then you need to figure out the code path of the trigger stop.
>
> > In normal scenario, Trigger stop is not getting called and audio was
> > able to render in the VLC application. Below log for normal scenario,
> > [  802.785893] Trigger:Start
> > [  814.288309] hwptr=0 buf_pos:6272
> > [  814.288323] buf_pos :6272 bytes_to_frames:1568 uhdc_audio_pcm_pointer_253
> > [  814.288362] buf_pos :6272 bytes_to_frames:1568 uhdc_audio_pcm_pointer_253
> > [  814.288378] buf_pos :6272 bytes_to_frames:1568 uhdc_audio_pcm_pointer_253
> > [  814.305079] hwptr=6272 buf_pos:9472
> > [  814.305091] buf_pos :9472 bytes_to_frames:2368 uhdc_audio_pcm_pointer_253
> > [  814.321741] hwptr=9472 buf_pos:12672
> > [  814.321748] buf_pos :12672 bytes_to_frames:3168 uhdc_audio_pcm_pointer_253
> > [  814.321777] buf_pos :12672 bytes_to_frames:3168 uhdc_audio_pcm_pointer_253
> > [  814.321785] buf_pos :12672 bytes_to_frames:3168 uhdc_audio_pcm_pointer_253
> > [  814.338452] hwptr=12672 buf_pos:15872
> > [  814.338459] buf_pos :15872 bytes_to_frames:3968 uhdc_audio_pcm_pointer_253
> > [  814.355242] hwptr=15872 buf_pos:19072
> > [  814.355248] buf_pos :19072 bytes_to_frames:4768 uhdc_audio_pcm_pointer_253
> > [  814.355288] buf_pos :19072 bytes_to_frames:4768 uhdc_audio_pcm_pointer_253
> > [  814.355294] buf_pos :19072 bytes_to_frames:4768 uhdc_audio_pcm_pointer_253
> > [  814.371822] hwptr=19072 buf_pos:22272
> > ...
> > ...
> > [  830.739031] Trigger:Stop
> >
> >
> > I can not do rmmod for ALSA driver. If I do sudo rmmod mydriver then it says
> > "rmmod: ERROR: Module mydriver is in use"
> >
> > How can I remove mydriver module from linux kernel ?
>
> Likely some program is using the sound device.  For example, a mixer
> applet or PulseAudio keeps opening the control device.
> Check it via "fuser -v /dev/snd/*"
>
>
> Takashi



-- 
Thanks and Regards
Chakravarthi Pradeep.K
Ph: 91 9980434900

Re: Fwd: ALSA queries

[Takashi Iwai]

On Tue, 07 Aug 2018 14:08:05 +0200,
Chakravarthi Pradeep wrote:
> 
> Dear Takashi,
> 
> In previous mail you have mentioned
> > So, either the measurement is wrong, or the stream is already screwed
> > up at the time you call snd_pcm_period_elapsed().
> 
> what it means "measurement is wrong"  and how to make that measurement
> is correct ?

See what I wrote: "either".  I can't exclude the possibility that you
are measuring the code calls incorrectly, of course.  This is one
case.  Another case would be the incorrect state that is already
screwed up at the time of snd_pcm_period_elapsed() call.


Takashi


> Regards,
> Chakravarthi
> On Tue, Aug 7, 2018 at 5:33 PM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > On Tue, 07 Aug 2018 13:59:46 +0200,
> > Chakravarthi Pradeep wrote:
> > >
> > > Dear Takashi,
> > >
> > > Trigger stop is getting called , because of this hwptr is zero and
> > > pointer call back is not getting called. Below is my log from driver.
> > >
> > > [  838.491681] Trigger:Start
> > > [  839.522233] hwptr=0 buf_pos:3456
> > > [  839.522244] buf_pos :3456 bytes_to_frames:864 uhdc_audio_pcm_pointer_253
> > > [  839.522249] Trigger:Stop
> >
> > Then you need to figure out the code path of the trigger stop.
> >
> > > In normal scenario, Trigger stop is not getting called and audio was
> > > able to render in the VLC application. Below log for normal scenario,
> > > [  802.785893] Trigger:Start
> > > [  814.288309] hwptr=0 buf_pos:6272
> > > [  814.288323] buf_pos :6272 bytes_to_frames:1568 uhdc_audio_pcm_pointer_253
> > > [  814.288362] buf_pos :6272 bytes_to_frames:1568 uhdc_audio_pcm_pointer_253
> > > [  814.288378] buf_pos :6272 bytes_to_frames:1568 uhdc_audio_pcm_pointer_253
> > > [  814.305079] hwptr=6272 buf_pos:9472
> > > [  814.305091] buf_pos :9472 bytes_to_frames:2368 uhdc_audio_pcm_pointer_253
> > > [  814.321741] hwptr=9472 buf_pos:12672
> > > [  814.321748] buf_pos :12672 bytes_to_frames:3168 uhdc_audio_pcm_pointer_253
> > > [  814.321777] buf_pos :12672 bytes_to_frames:3168 uhdc_audio_pcm_pointer_253
> > > [  814.321785] buf_pos :12672 bytes_to_frames:3168 uhdc_audio_pcm_pointer_253
> > > [  814.338452] hwptr=12672 buf_pos:15872
> > > [  814.338459] buf_pos :15872 bytes_to_frames:3968 uhdc_audio_pcm_pointer_253
> > > [  814.355242] hwptr=15872 buf_pos:19072
> > > [  814.355248] buf_pos :19072 bytes_to_frames:4768 uhdc_audio_pcm_pointer_253
> > > [  814.355288] buf_pos :19072 bytes_to_frames:4768 uhdc_audio_pcm_pointer_253
> > > [  814.355294] buf_pos :19072 bytes_to_frames:4768 uhdc_audio_pcm_pointer_253
> > > [  814.371822] hwptr=19072 buf_pos:22272
> > > ...
> > > ...
> > > [  830.739031] Trigger:Stop
> > >
> > >
> > > I can not do rmmod for ALSA driver. If I do sudo rmmod mydriver then it says
> > > "rmmod: ERROR: Module mydriver is in use"
> > >
> > > How can I remove mydriver module from linux kernel ?
> >
> > Likely some program is using the sound device.  For example, a mixer
> > applet or PulseAudio keeps opening the control device.
> > Check it via "fuser -v /dev/snd/*"
> >
> >
> > Takashi
> 
> 
> 
> -- 
> Thanks and Regards
> Chakravarthi Pradeep.K
> Ph: 91 9980434900
> 

Re: Fwd: ALSA queries

[Chakravarthi Pradeep]

Dear Takashi,

I would like you to review my driver, kindly tell me whether is it
possible to review it. If yes, can you please share me git link where
I can upload my driver for review .

Regards,
Chakravarthi
On Tue, Aug 7, 2018 at 5:41 PM Takashi Iwai <tiwai@suse.de> wrote:
>
> On Tue, 07 Aug 2018 14:08:05 +0200,
> Chakravarthi Pradeep wrote:
> >
> > Dear Takashi,
> >
> > In previous mail you have mentioned
> > > So, either the measurement is wrong, or the stream is already screwed
> > > up at the time you call snd_pcm_period_elapsed().
> >
> > what it means "measurement is wrong"  and how to make that measurement
> > is correct ?
>
> See what I wrote: "either".  I can't exclude the possibility that you
> are measuring the code calls incorrectly, of course.  This is one
> case.  Another case would be the incorrect state that is already
> screwed up at the time of snd_pcm_period_elapsed() call.
>
>
> Takashi
>
>
> > Regards,
> > Chakravarthi
> > On Tue, Aug 7, 2018 at 5:33 PM Takashi Iwai <tiwai@suse.de> wrote:
> > >
> > > On Tue, 07 Aug 2018 13:59:46 +0200,
> > > Chakravarthi Pradeep wrote:
> > > >
> > > > Dear Takashi,
> > > >
> > > > Trigger stop is getting called , because of this hwptr is zero and
> > > > pointer call back is not getting called. Below is my log from driver.
> > > >
> > > > [  838.491681] Trigger:Start
> > > > [  839.522233] hwptr=0 buf_pos:3456
> > > > [  839.522244] buf_pos :3456 bytes_to_frames:864 uhdc_audio_pcm_pointer_253
> > > > [  839.522249] Trigger:Stop
> > >
> > > Then you need to figure out the code path of the trigger stop.
> > >
> > > > In normal scenario, Trigger stop is not getting called and audio was
> > > > able to render in the VLC application. Below log for normal scenario,
> > > > [  802.785893] Trigger:Start
> > > > [  814.288309] hwptr=0 buf_pos:6272
> > > > [  814.288323] buf_pos :6272 bytes_to_frames:1568 uhdc_audio_pcm_pointer_253
> > > > [  814.288362] buf_pos :6272 bytes_to_frames:1568 uhdc_audio_pcm_pointer_253
> > > > [  814.288378] buf_pos :6272 bytes_to_frames:1568 uhdc_audio_pcm_pointer_253
> > > > [  814.305079] hwptr=6272 buf_pos:9472
> > > > [  814.305091] buf_pos :9472 bytes_to_frames:2368 uhdc_audio_pcm_pointer_253
> > > > [  814.321741] hwptr=9472 buf_pos:12672
> > > > [  814.321748] buf_pos :12672 bytes_to_frames:3168 uhdc_audio_pcm_pointer_253
> > > > [  814.321777] buf_pos :12672 bytes_to_frames:3168 uhdc_audio_pcm_pointer_253
> > > > [  814.321785] buf_pos :12672 bytes_to_frames:3168 uhdc_audio_pcm_pointer_253
> > > > [  814.338452] hwptr=12672 buf_pos:15872
> > > > [  814.338459] buf_pos :15872 bytes_to_frames:3968 uhdc_audio_pcm_pointer_253
> > > > [  814.355242] hwptr=15872 buf_pos:19072
> > > > [  814.355248] buf_pos :19072 bytes_to_frames:4768 uhdc_audio_pcm_pointer_253
> > > > [  814.355288] buf_pos :19072 bytes_to_frames:4768 uhdc_audio_pcm_pointer_253
> > > > [  814.355294] buf_pos :19072 bytes_to_frames:4768 uhdc_audio_pcm_pointer_253
> > > > [  814.371822] hwptr=19072 buf_pos:22272
> > > > ...
> > > > ...
> > > > [  830.739031] Trigger:Stop
> > > >
> > > >
> > > > I can not do rmmod for ALSA driver. If I do sudo rmmod mydriver then it says
> > > > "rmmod: ERROR: Module mydriver is in use"
> > > >
> > > > How can I remove mydriver module from linux kernel ?
> > >
> > > Likely some program is using the sound device.  For example, a mixer
> > > applet or PulseAudio keeps opening the control device.
> > > Check it via "fuser -v /dev/snd/*"
> > >
> > >
> > > Takashi
> >
> >
> >
> > --
> > Thanks and Regards
> > Chakravarthi Pradeep.K
> > Ph: 91 9980434900
> >



-- 
Thanks and Regards
Chakravarthi Pradeep.K
Ph: 91 9980434900

Re: Fwd: ALSA queries

[Takashi Iwai]

On Tue, 07 Aug 2018 14:14:35 +0200,
Chakravarthi Pradeep wrote:
> 
> Dear Takashi,
> 
> I would like you to review my driver, kindly tell me whether is it
> possible to review it. If yes, can you please share me git link where
> I can upload my driver for review .

Chakravarthi, this is no "review" but an action called "debug".
I can't waste my time for that, and you need to figure out the issue
in your side.

Track the code and the PCM stream state.  There are no many places
that call the stop.  Use the source, Luke.


Takashi

> 
> Regards,
> Chakravarthi
> On Tue, Aug 7, 2018 at 5:41 PM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > On Tue, 07 Aug 2018 14:08:05 +0200,
> > Chakravarthi Pradeep wrote:
> > >
> > > Dear Takashi,
> > >
> > > In previous mail you have mentioned
> > > > So, either the measurement is wrong, or the stream is already screwed
> > > > up at the time you call snd_pcm_period_elapsed().
> > >
> > > what it means "measurement is wrong"  and how to make that measurement
> > > is correct ?
> >
> > See what I wrote: "either".  I can't exclude the possibility that you
> > are measuring the code calls incorrectly, of course.  This is one
> > case.  Another case would be the incorrect state that is already
> > screwed up at the time of snd_pcm_period_elapsed() call.
> >
> >
> > Takashi
> >
> >
> > > Regards,
> > > Chakravarthi
> > > On Tue, Aug 7, 2018 at 5:33 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > >
> > > > On Tue, 07 Aug 2018 13:59:46 +0200,
> > > > Chakravarthi Pradeep wrote:
> > > > >
> > > > > Dear Takashi,
> > > > >
> > > > > Trigger stop is getting called , because of this hwptr is zero and
> > > > > pointer call back is not getting called. Below is my log from driver.
> > > > >
> > > > > [  838.491681] Trigger:Start
> > > > > [  839.522233] hwptr=0 buf_pos:3456
> > > > > [  839.522244] buf_pos :3456 bytes_to_frames:864 uhdc_audio_pcm_pointer_253
> > > > > [  839.522249] Trigger:Stop
> > > >
> > > > Then you need to figure out the code path of the trigger stop.
> > > >
> > > > > In normal scenario, Trigger stop is not getting called and audio was
> > > > > able to render in the VLC application. Below log for normal scenario,
> > > > > [  802.785893] Trigger:Start
> > > > > [  814.288309] hwptr=0 buf_pos:6272
> > > > > [  814.288323] buf_pos :6272 bytes_to_frames:1568 uhdc_audio_pcm_pointer_253
> > > > > [  814.288362] buf_pos :6272 bytes_to_frames:1568 uhdc_audio_pcm_pointer_253
> > > > > [  814.288378] buf_pos :6272 bytes_to_frames:1568 uhdc_audio_pcm_pointer_253
> > > > > [  814.305079] hwptr=6272 buf_pos:9472
> > > > > [  814.305091] buf_pos :9472 bytes_to_frames:2368 uhdc_audio_pcm_pointer_253
> > > > > [  814.321741] hwptr=9472 buf_pos:12672
> > > > > [  814.321748] buf_pos :12672 bytes_to_frames:3168 uhdc_audio_pcm_pointer_253
> > > > > [  814.321777] buf_pos :12672 bytes_to_frames:3168 uhdc_audio_pcm_pointer_253
> > > > > [  814.321785] buf_pos :12672 bytes_to_frames:3168 uhdc_audio_pcm_pointer_253
> > > > > [  814.338452] hwptr=12672 buf_pos:15872
> > > > > [  814.338459] buf_pos :15872 bytes_to_frames:3968 uhdc_audio_pcm_pointer_253
> > > > > [  814.355242] hwptr=15872 buf_pos:19072
> > > > > [  814.355248] buf_pos :19072 bytes_to_frames:4768 uhdc_audio_pcm_pointer_253
> > > > > [  814.355288] buf_pos :19072 bytes_to_frames:4768 uhdc_audio_pcm_pointer_253
> > > > > [  814.355294] buf_pos :19072 bytes_to_frames:4768 uhdc_audio_pcm_pointer_253
> > > > > [  814.371822] hwptr=19072 buf_pos:22272
> > > > > ...
> > > > > ...
> > > > > [  830.739031] Trigger:Stop
> > > > >
> > > > >
> > > > > I can not do rmmod for ALSA driver. If I do sudo rmmod mydriver then it says
> > > > > "rmmod: ERROR: Module mydriver is in use"
> > > > >
> > > > > How can I remove mydriver module from linux kernel ?
> > > >
> > > > Likely some program is using the sound device.  For example, a mixer
> > > > applet or PulseAudio keeps opening the control device.
> > > > Check it via "fuser -v /dev/snd/*"
> > > >
> > > >
> > > > Takashi
> > >
> > >
> > >
> > > --
> > > Thanks and Regards
> > > Chakravarthi Pradeep.K
> > > Ph: 91 9980434900
> > >
> 
> 
> 
> -- 
> Thanks and Regards
> Chakravarthi Pradeep.K
> Ph: 91 9980434900
> 

Re: Fwd: ALSA queries

[Chakravarthi Pradeep]

Dear Takashi,

Thanks for your reply.

> The "period" in ALSA PCM definition represents the interval time (or
> frames) of the periodical interrupts on the ring buffer.  If the irq
> is issued for each 256 frames while the ring buffer size is 1024
> frames, periods = 1024/256 = 4.  The periods_min defines the minimal
> number of periods the hardware may accept.

Is it  256 frames or  256 bytes ?


fuser -v /dev/snd/* output is
                                         USER
  PID   ACCESS    COMMAND
/dev/snd/controlC0         Dell                                   1815
F.....           pulseaudio

Regards,
Chakravarthi
On Tue, Aug 7, 2018 at 5:48 PM Takashi Iwai <tiwai@suse.de> wrote:
>
> On Tue, 07 Aug 2018 14:14:35 +0200,
> Chakravarthi Pradeep wrote:
> >
> > Dear Takashi,
> >
> > I would like you to review my driver, kindly tell me whether is it
> > possible to review it. If yes, can you please share me git link where
> > I can upload my driver for review .
>
> Chakravarthi, this is no "review" but an action called "debug".
> I can't waste my time for that, and you need to figure out the issue
> in your side.
>
> Track the code and the PCM stream state.  There are no many places
> that call the stop.  Use the source, Luke.
>
>
> Takashi
>
> >
> > Regards,
> > Chakravarthi
> > On Tue, Aug 7, 2018 at 5:41 PM Takashi Iwai <tiwai@suse.de> wrote:
> > >
> > > On Tue, 07 Aug 2018 14:08:05 +0200,
> > > Chakravarthi Pradeep wrote:
> > > >
> > > > Dear Takashi,
> > > >
> > > > In previous mail you have mentioned
> > > > > So, either the measurement is wrong, or the stream is already screwed
> > > > > up at the time you call snd_pcm_period_elapsed().
> > > >
> > > > what it means "measurement is wrong"  and how to make that measurement
> > > > is correct ?
> > >
> > > See what I wrote: "either".  I can't exclude the possibility that you
> > > are measuring the code calls incorrectly, of course.  This is one
> > > case.  Another case would be the incorrect state that is already
> > > screwed up at the time of snd_pcm_period_elapsed() call.
> > >
> > >
> > > Takashi
> > >
> > >
> > > > Regards,
> > > > Chakravarthi
> > > > On Tue, Aug 7, 2018 at 5:33 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > > >
> > > > > On Tue, 07 Aug 2018 13:59:46 +0200,
> > > > > Chakravarthi Pradeep wrote:
> > > > > >
> > > > > > Dear Takashi,
> > > > > >
> > > > > > Trigger stop is getting called , because of this hwptr is zero and
> > > > > > pointer call back is not getting called. Below is my log from driver.
> > > > > >
> > > > > > [  838.491681] Trigger:Start
> > > > > > [  839.522233] hwptr=0 buf_pos:3456
> > > > > > [  839.522244] buf_pos :3456 bytes_to_frames:864 uhdc_audio_pcm_pointer_253
> > > > > > [  839.522249] Trigger:Stop
> > > > >
> > > > > Then you need to figure out the code path of the trigger stop.
> > > > >
> > > > > > In normal scenario, Trigger stop is not getting called and audio was
> > > > > > able to render in the VLC application. Below log for normal scenario,
> > > > > > [  802.785893] Trigger:Start
> > > > > > [  814.288309] hwptr=0 buf_pos:6272
> > > > > > [  814.288323] buf_pos :6272 bytes_to_frames:1568 uhdc_audio_pcm_pointer_253
> > > > > > [  814.288362] buf_pos :6272 bytes_to_frames:1568 uhdc_audio_pcm_pointer_253
> > > > > > [  814.288378] buf_pos :6272 bytes_to_frames:1568 uhdc_audio_pcm_pointer_253
> > > > > > [  814.305079] hwptr=6272 buf_pos:9472
> > > > > > [  814.305091] buf_pos :9472 bytes_to_frames:2368 uhdc_audio_pcm_pointer_253
> > > > > > [  814.321741] hwptr=9472 buf_pos:12672
> > > > > > [  814.321748] buf_pos :12672 bytes_to_frames:3168 uhdc_audio_pcm_pointer_253
> > > > > > [  814.321777] buf_pos :12672 bytes_to_frames:3168 uhdc_audio_pcm_pointer_253
> > > > > > [  814.321785] buf_pos :12672 bytes_to_frames:3168 uhdc_audio_pcm_pointer_253
> > > > > > [  814.338452] hwptr=12672 buf_pos:15872
> > > > > > [  814.338459] buf_pos :15872 bytes_to_frames:3968 uhdc_audio_pcm_pointer_253
> > > > > > [  814.355242] hwptr=15872 buf_pos:19072
> > > > > > [  814.355248] buf_pos :19072 bytes_to_frames:4768 uhdc_audio_pcm_pointer_253
> > > > > > [  814.355288] buf_pos :19072 bytes_to_frames:4768 uhdc_audio_pcm_pointer_253
> > > > > > [  814.355294] buf_pos :19072 bytes_to_frames:4768 uhdc_audio_pcm_pointer_253
> > > > > > [  814.371822] hwptr=19072 buf_pos:22272
> > > > > > ...
> > > > > > ...
> > > > > > [  830.739031] Trigger:Stop
> > > > > >
> > > > > >
> > > > > > I can not do rmmod for ALSA driver. If I do sudo rmmod mydriver then it says
> > > > > > "rmmod: ERROR: Module mydriver is in use"
> > > > > >
> > > > > > How can I remove mydriver module from linux kernel ?
> > > > >
> > > > > Likely some program is using the sound device.  For example, a mixer
> > > > > applet or PulseAudio keeps opening the control device.
> > > > > Check it via "fuser -v /dev/snd/*"
> > > > >
> > > > >
> > > > > Takashi
> > > >
> > > >
> > > >
> > > > --
> > > > Thanks and Regards
> > > > Chakravarthi Pradeep.K
> > > > Ph: 91 9980434900
> > > >
> >
> >
> >
> > --
> > Thanks and Regards
> > Chakravarthi Pradeep.K
> > Ph: 91 9980434900
> >



-- 
Thanks and Regards
Chakravarthi Pradeep.K
Ph: 91 9980434900

Re: Fwd: ALSA queries

[Takashi Iwai]

On Tue, 07 Aug 2018 15:12:08 +0200,
Chakravarthi Pradeep wrote:
> 
> Dear Takashi,
> 
> Thanks for your reply.
> 
> > The "period" in ALSA PCM definition represents the interval time (or
> > frames) of the periodical interrupts on the ring buffer.  If the irq
> > is issued for each 256 frames while the ring buffer size is 1024
> > frames, periods = 1024/256 = 4.  The periods_min defines the minimal
> > number of periods the hardware may accept.
> 
> Is it  256 frames or  256 bytes ?

In the case above it's in frames.  But it can be defined in bytes
depending on the hardware spec.  Some hardware defines in the time
unit (like msec), too.

> fuser -v /dev/snd/* output is
>                                          USER
>   PID   ACCESS    COMMAND
> /dev/snd/controlC0         Dell                                   1815
> F.....           pulseaudio

Now you know it.  And remember that PA is often die-hard.


Takashi

Re: Fwd: ALSA queries

[Chakravarthi Pradeep]

>In the case above it's in frames.  But it can be defined in bytes
>depending on the hardware spec.  Some hardware defines in the time
>unit (like msec), too.

Can you please tell me how to define in bytes ?

>Now you know it.  And remember that PA is often die-hard.
So it means that I can not do rmmod until pulseaudio is removed , is
it correct ?

Regards,
Chakravarthi
On Tue, Aug 7, 2018 at 6:45 PM Takashi Iwai <tiwai@suse.de> wrote:
>
> On Tue, 07 Aug 2018 15:12:08 +0200,
> Chakravarthi Pradeep wrote:
> >
> > Dear Takashi,
> >
> > Thanks for your reply.
> >
> > > The "period" in ALSA PCM definition represents the interval time (or
> > > frames) of the periodical interrupts on the ring buffer.  If the irq
> > > is issued for each 256 frames while the ring buffer size is 1024
> > > frames, periods = 1024/256 = 4.  The periods_min defines the minimal
> > > number of periods the hardware may accept.
> >
> > Is it  256 frames or  256 bytes ?
>
> In the case above it's in frames.  But it can be defined in bytes
> depending on the hardware spec.  Some hardware defines in the time
> unit (like msec), too.
>
> > fuser -v /dev/snd/* output is
> >                                          USER
> >   PID   ACCESS    COMMAND
> > /dev/snd/controlC0         Dell                                   1815
> > F.....           pulseaudio
>
> Now you know it.  And remember that PA is often die-hard.
>
>
> Takashi



-- 
Thanks and Regards
Chakravarthi Pradeep.K
Ph: 91 9980434900

Re: Fwd: ALSA queries

[Takashi Iwai]

On Tue, 07 Aug 2018 15:36:22 +0200,
Chakravarthi Pradeep wrote:
> 
> >In the case above it's in frames.  But it can be defined in bytes
> >depending on the hardware spec.  Some hardware defines in the time
> >unit (like msec), too.
> 
> Can you please tell me how to define in bytes ?

Read the source before asking like this.  If not found, read the
source again.  If still it's not fulfilled, ask more specific
questions.

The driver doesn't define it.  Rather the driver lets ALSA PCM core
choose the parameters given from user-space.  But some parameters
might not fit with the requirement of your hardware.  For satisfying
it, the driver may give hw constraints to PCM core beforehand,
typically set in the open callback.

> >Now you know it.  And remember that PA is often die-hard.
> So it means that I can not do rmmod until pulseaudio is removed , is
> it correct ?

Yes.  You cannot rmmod during any program is accessing to the sound
device, not only PA.


Takashi

> Regards,
> Chakravarthi
> On Tue, Aug 7, 2018 at 6:45 PM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > On Tue, 07 Aug 2018 15:12:08 +0200,
> > Chakravarthi Pradeep wrote:
> > >
> > > Dear Takashi,
> > >
> > > Thanks for your reply.
> > >
> > > > The "period" in ALSA PCM definition represents the interval time (or
> > > > frames) of the periodical interrupts on the ring buffer.  If the irq
> > > > is issued for each 256 frames while the ring buffer size is 1024
> > > > frames, periods = 1024/256 = 4.  The periods_min defines the minimal
> > > > number of periods the hardware may accept.
> > >
> > > Is it  256 frames or  256 bytes ?
> >
> > In the case above it's in frames.  But it can be defined in bytes
> > depending on the hardware spec.  Some hardware defines in the time
> > unit (like msec), too.
> >
> > > fuser -v /dev/snd/* output is
> > >                                          USER
> > >   PID   ACCESS    COMMAND
> > > /dev/snd/controlC0         Dell                                   1815
> > > F.....           pulseaudio
> >
> > Now you know it.  And remember that PA is often die-hard.
> >
> >
> > Takashi
> 
> 
> 
> -- 
> Thanks and Regards
> Chakravarthi Pradeep.K
> Ph: 91 9980434900
> 

Re: Fwd: ALSA queries

[Chakravarthi Pradeep]

Hi Takashi,

How to enable log from ALSA lib core or ALSA core , so that I will
come to know why trigger stop call back is getting called back by
itself.

ring bufffer size is 57600 and minimum bytes device generates per
period is 3200(bytes). I have read one frame is 4 bytes from below
link.
https://www.alsa-project.org/main/index.php/FramesPeriods
So is it correct to give below values to snd_pcm_hardware
.period_bytes_min = 3200 /* per interrupt device provides minimum 3200
bytes of data*/
.periods_min = 72 /* 3200/4 /* 4 is because of (2 (channel )*  (16 bits/2)) */

Regards,
Chakravarthi
On Tue, Aug 7, 2018 at 7:13 PM Takashi Iwai <tiwai@suse.de> wrote:
>
> On Tue, 07 Aug 2018 15:36:22 +0200,
> Chakravarthi Pradeep wrote:
> >
> > >In the case above it's in frames.  But it can be defined in bytes
> > >depending on the hardware spec.  Some hardware defines in the time
> > >unit (like msec), too.
> >
> > Can you please tell me how to define in bytes ?
>
> Read the source before asking like this.  If not found, read the
> source again.  If still it's not fulfilled, ask more specific
> questions.
>
> The driver doesn't define it.  Rather the driver lets ALSA PCM core
> choose the parameters given from user-space.  But some parameters
> might not fit with the requirement of your hardware.  For satisfying
> it, the driver may give hw constraints to PCM core beforehand,
> typically set in the open callback.
>
> > >Now you know it.  And remember that PA is often die-hard.
> > So it means that I can not do rmmod until pulseaudio is removed , is
> > it correct ?
>
> Yes.  You cannot rmmod during any program is accessing to the sound
> device, not only PA.
>
>
> Takashi
>
> > Regards,
> > Chakravarthi
> > On Tue, Aug 7, 2018 at 6:45 PM Takashi Iwai <tiwai@suse.de> wrote:
> > >
> > > On Tue, 07 Aug 2018 15:12:08 +0200,
> > > Chakravarthi Pradeep wrote:
> > > >
> > > > Dear Takashi,
> > > >
> > > > Thanks for your reply.
> > > >
> > > > > The "period" in ALSA PCM definition represents the interval time (or
> > > > > frames) of the periodical interrupts on the ring buffer.  If the irq
> > > > > is issued for each 256 frames while the ring buffer size is 1024
> > > > > frames, periods = 1024/256 = 4.  The periods_min defines the minimal
> > > > > number of periods the hardware may accept.
> > > >
> > > > Is it  256 frames or  256 bytes ?
> > >
> > > In the case above it's in frames.  But it can be defined in bytes
> > > depending on the hardware spec.  Some hardware defines in the time
> > > unit (like msec), too.
> > >
> > > > fuser -v /dev/snd/* output is
> > > >                                          USER
> > > >   PID   ACCESS    COMMAND
> > > > /dev/snd/controlC0         Dell                                   1815
> > > > F.....           pulseaudio
> > >
> > > Now you know it.  And remember that PA is often die-hard.
> > >
> > >
> > > Takashi
> >
> >
> >
> > --
> > Thanks and Regards
> > Chakravarthi Pradeep.K
> > Ph: 91 9980434900
> >



-- 
Thanks and Regards
Chakravarthi Pradeep.K
Ph: 91 9980434900

Re: Fwd: ALSA queries

[Takashi Iwai]

On Thu, 09 Aug 2018 13:19:53 +0200,
Chakravarthi Pradeep wrote:
> 
> Hi Takashi,
> 
> How to enable log from ALSA lib core or ALSA core , so that I will
> come to know why trigger stop call back is getting called back by
> itself.

Do printk, tracing, whatever you can see.
We have the standard tracepoints, too, but maybe it's not what you
need.

> ring bufffer size is 57600 and minimum bytes device generates per
> period is 3200(bytes). I have read one frame is 4 bytes from below
> link.
> https://www.alsa-project.org/main/index.php/FramesPeriods
> So is it correct to give below values to snd_pcm_hardware
> .period_bytes_min = 3200 /* per interrupt device provides minimum 3200
> bytes of data*/
> .periods_min = 72 /* 3200/4 /* 4 is because of (2 (channel )*  (16 bits/2)) */

period_bytes_min is 3200 bytes, so it looks correct.
But periods_min is the minimal number of periods in a ring buffer.
It can be calculated as (min buffer size) / (max period size).


Takashi

> 
> Regards,
> Chakravarthi
> On Tue, Aug 7, 2018 at 7:13 PM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > On Tue, 07 Aug 2018 15:36:22 +0200,
> > Chakravarthi Pradeep wrote:
> > >
> > > >In the case above it's in frames.  But it can be defined in bytes
> > > >depending on the hardware spec.  Some hardware defines in the time
> > > >unit (like msec), too.
> > >
> > > Can you please tell me how to define in bytes ?
> >
> > Read the source before asking like this.  If not found, read the
> > source again.  If still it's not fulfilled, ask more specific
> > questions.
> >
> > The driver doesn't define it.  Rather the driver lets ALSA PCM core
> > choose the parameters given from user-space.  But some parameters
> > might not fit with the requirement of your hardware.  For satisfying
> > it, the driver may give hw constraints to PCM core beforehand,
> > typically set in the open callback.
> >
> > > >Now you know it.  And remember that PA is often die-hard.
> > > So it means that I can not do rmmod until pulseaudio is removed , is
> > > it correct ?
> >
> > Yes.  You cannot rmmod during any program is accessing to the sound
> > device, not only PA.
> >
> >
> > Takashi
> >
> > > Regards,
> > > Chakravarthi
> > > On Tue, Aug 7, 2018 at 6:45 PM Takashi Iwai <tiwai@suse.de> wrote:
> > > >
> > > > On Tue, 07 Aug 2018 15:12:08 +0200,
> > > > Chakravarthi Pradeep wrote:
> > > > >
> > > > > Dear Takashi,
> > > > >
> > > > > Thanks for your reply.
> > > > >
> > > > > > The "period" in ALSA PCM definition represents the interval time (or
> > > > > > frames) of the periodical interrupts on the ring buffer.  If the irq
> > > > > > is issued for each 256 frames while the ring buffer size is 1024
> > > > > > frames, periods = 1024/256 = 4.  The periods_min defines the minimal
> > > > > > number of periods the hardware may accept.
> > > > >
> > > > > Is it  256 frames or  256 bytes ?
> > > >
> > > > In the case above it's in frames.  But it can be defined in bytes
> > > > depending on the hardware spec.  Some hardware defines in the time
> > > > unit (like msec), too.
> > > >
> > > > > fuser -v /dev/snd/* output is
> > > > >                                          USER
> > > > >   PID   ACCESS    COMMAND
> > > > > /dev/snd/controlC0         Dell                                   1815
> > > > > F.....           pulseaudio
> > > >
> > > > Now you know it.  And remember that PA is often die-hard.
> > > >
> > > >
> > > > Takashi
> > >
> > >
> > >
> > > --
> > > Thanks and Regards
> > > Chakravarthi Pradeep.K
> > > Ph: 91 9980434900
> > >
> 
> 
> 
> -- 
> Thanks and Regards
> Chakravarthi Pradeep.K
> Ph: 91 9980434900
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>