Re: DMA and delay feedback

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

 



On Mon, 2009-12-14 at 16:35 +0100, ext James Courtier-Dutton wrote:
> 2009/12/14 pl bossart <bossart.nospam@xxxxxxxxx>:
> >> For transfer purposes, one only needs to know that DMA transfer is
> >> complete on period X so that period X can now be over-written.
> >
> > That's the 'traditional' view. ALSA is now used in different ways.
> > PulseAudio sets a timer and relies on snd_pcm_avail() to query how
> > many samples it can write to the ring buffer, the notion of period
> > isn't used at all. I think we could use additional information in the
> > way the hw_ptr position is reported, namely hints on how precise this
> > information is and the granularity of the updates.
> > - Pierre
> >
> 
> There is a problem with getting snd_pcm_avail() accurate from a
> hardware perspective.
> I was trying to come up with a method for letting the application
> (pulseaudio) know how much data it can write in a more accurate
> fashion.
> An extra bit of information is also useful, and that is some
> prediction of when one should next write samples after this write.
> One then has a sensible value to use for the timer.
> People use snd_pcm_avail for different tasks, and I was trying to
> break the use cases out and analyse each one it turn and see if a
> better API interface could result.
> The use cases are:
> 1) Deciding when and how many sample to write and when one is likely
> to need to write again.
> 2) Syncing the samples to a video stream or other time source.
> There are other requiremets:
> 1) Having the application buffer size different from the hardware buffer size.
> 2) Having the application sample rate different from the hardware
> sample rate, and thus doing resampling.
> 
> James

At every DMA IRQ, I guess you may be calling snd_pcm_period_elapsed().
If so, a timestamp is taken that may be polled out with the
SNDRV_PCM_IOCTL_TTSTAMP. So comparing the timestamp to the current time
gives you the exact 'delta'? (Of course there may be issues such as the
call propagation delay (if an IRQ occurs during the ioctl call that
takes time) or the DMA IRQ may arrive at the same time with a more high
priority IRQ etc, but that's all basics...)

- Eero

_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

  Powered by Linux