On Wed, 2010-08-18 at 22:55 +0200, David Henningsson wrote: > > Yes the safeguard is needed in both cases, timer scheduling or good > > ol' audio interrupts. This comes from limitations of the > > snd_pcm_rewind() routine, you can rewind the appl_ptr all the way to > > the hardware pointer, but you may have DMA transfers in flight that > > cannot be rewound. For example HDaudio can fetch up to 128bytes, I > > added a default a safeguard of 256bytes to be super safe, but in > > theory this should be adjusted depending on how the DMA operates. > > Assuming your reasoning is correct (I'm not that deep into DMA yet), > this should be fixed in the kernel - by not allowing rewinds further > back than 128 (or 256) bytes ahead of actual position. > You say HDA can transfer up to 128 bytes in advance, but what about all > the other drivers? Could there be other drivers having a lot larger DMA > fetches? What's the role of snd_pcm_rewindable()[1]? The documentation says "Get safe count of frames which can be rewinded", which sounds to me like the function should always be called before snd_pcm_rewind(). Currently PA doesn't call _rewindable(). > > The > > DMA knows nothing about milliseconds, it behaves the same way no > > matter the sampling rate it, which is the reason why bytes make more > > sense, it's easier to correlate with the way the hardware works. > > So your idea is to prevent DMA transfers being modified, but I'm > thinking of the maximum duration between the rewind and the point it > gets filled up again by PA - all of that time we risc getting an XRUN > because there is nothing in the buffer. And so I assume that the > duration is never longer than 20 ms. > > I don't think it is much of a deal though. Rewind is not something used > every second or so (or at least, shouldn't be). A comment on the last statement: I don't think the average frequency of rewinds is important, because there are cases where multiple rewinds do happen really quickly - for example when dragging a volume slider (IIRC pavucontrol ratelimits the volume change events to minimum of 100ms between each event sent to the daemon - that's still ten times a second). I don't remember hearing complaints about that the volume is crackling when changing volumes, but at least in theory this seems like a possible problem with the current implementation. [1] http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#g8f56faf60ea6b60839e131df88f080d7 -- Tanu Kaskinen
