At Wed, 24 Jun 2009 11:14:33 -0400, Jon Smirl wrote: > > On Wed, Jun 24, 2009 at 10:39 AM, Takashi Iwai<tiwai@xxxxxxx> wrote: > > The glitch-free problem of PA comes from the fact that PA assumes that > > the driver returns the current hw position accurately at any time. > > But, in many hardwares, including HDA, this is not true. The hardware > > lies. It doesn't report the right position at all. Thus, there are > > many workarounds implemented in HD-audio side. > > Why does pulse need to know the DMA position? > > If it is so that it can write into the buffer with minimal latency > there are other ways to accomplish that. The simplest is to just add > an entry into ALSA core that says, play this buffer with minimal > latency. That would let the transfer be pushed down into the specific > driver and that driver could handle it in an optimal way. To get a minimum latency, you need to program the sound hardware to notify that. And, most hardware can't do anything but issue IRQs periodically at buffer, fragment or period or whatever boundary. Instead of the hardware irqs (that can wake up too often), PA uses the timer. Then it must check the position because the clock on the hardware isn't quite accurate and very likely you'll get a drift sooner or later if you use the other timer source. Yes, there can be optimizations for hardwares that are capable to notify any free size chunks. This is a missing piece. > Optimal on my hardware would be to reprogram the DMA hardware to > immediately start playing from the new buffer. No copies involved. The > FIFO will hide the buffer swap from the audio hardware. Yes. But it's rather a rare case that you can do such an operation. > Optimal on ring buffer hardware would be to locate where DMA was in > the ring and copy to a position in front of it. That's exactly what PA does. But you must know where to copy beforehand. And the hardware lies where is the current position. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
