Re: [PATCH 3/3] echoaudio: Address bugs in the interrupt handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 16 Jun 2020 16:01:11 +0200,
Mark Hills wrote:
> 
> On Tue, 16 Jun 2020, Takashi Iwai wrote:
> 
> > On Tue, 16 Jun 2020 15:17:43 +0200,
> > Mark Hills wrote:
> > > 
> > > +/* Update software pointer to match the hardware
> > > + *
> > > + * Return: 1 if we crossed a period threshold, otherwise 0
> > > + */
> > > +static int snd_echo_poll_substream(struct snd_pcm_substream *substream)
> > 
> > This is a bit confusing name.  One would imagine from the function
> > name as if it were about the handling of poll() syscall.
> 
> Poll felt intuitive to me; maybe from FreeBSD where network drivers can 
> poll on a timer instead of interrupts. I do know about poll(), though.
> 
> How about snd_echo_update_substream()?

Yes, it's more self-explanatory.  Or even better
snd_echo_update_substream_position() :)

> > > +{
> > > +	struct snd_pcm_runtime *runtime = substream->runtime;
> > > +	struct audiopipe *pipe = runtime->private_data;
> > > +	unsigned counter, step, period, last_period;
> > > +	size_t buffer_bytes;
> > > +
> > > +	if (pipe->state != PIPE_STATE_STARTED)
> > > +		return 0;
> > > +
> > > +	counter = le32_to_cpu(*pipe->dma_counter);
> > > +
> > > +	period = bytes_to_frames(runtime, counter)
> > > +		/ runtime->period_size;
> > > +	last_period = bytes_to_frames(runtime, pipe->last_counter)
> > > +		/ runtime->period_size;
> > > +
> > > +	if (period == last_period)
> > > +		return 0;  /* don't do any work yet */
> > > +
> > > +	step = counter - pipe->last_counter;
> > > +	pipe->last_counter = counter;
> > 
> > Dose this calculation consider the overlap of 32bit integer of the
> > counter?  (I'm not sure whether the old code did it right, though.)
> 
> I believe it does, since (small - big) as unsigned gives small value. And 
> period is checked only for equality (not greater than). I'll add a comment 
> as such. I have run it with long streams.

The problem is that the last_period calculation can be wrong if the
period size isn't aligned.  e.g. when period size is 44100, around the
boundary position, it gets a different last_period value although it
still in the same period.


thanks,

Takashi



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux