On Thu, Jul 04, 2013 at 07:56:25AM +0200, Mike Looijmans wrote: > On 07/03/2013 08:12 PM, Mark Brown wrote: > >This is an application issue not a driver issue. An application that > >wants low latency may need high resolution information about what > >exactly the hardware is doing. > To get low-latency, the best thing from userspace is to mmap the > audio buffer, and monitor the position of the DMA transfers. If the > driver reports the DMA position accurately, you can get latencies of > only a few samples. I must admit that I know next to nothing about > how ALSA works in userspace, but that's how DirectSound works, for > example. And from what I've seen, this is also possible with ALSA. There are often hardware limitations that mean that it is not possible to know the actual position of the DMA with anything less than period accuracy - either the hardware just doesn't report the current status during a transfer or it reports something that's not quite what's needed to usefully interact with it. The former is depressingly common. The APIs can support peering at the current position but it's not something that a portable application should be relying on. > Even without that - I tried with small periods of only 40 samples, > this invariably fails on the current driver, with or without the > ping-ping. Using the cyclic DMA I had no problem using such small > periods. The period size is generally orthogonal to decisions about using cyclic DMA.
Attachment:
signature.asc
Description: Digital signature
