On 2010-08-31 17:57, Colin Guthrie wrote: > 'Twas brillig, and pl bossart at 19/08/10 14:52 did gyre and gimble: >>>> 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(). >> >> Yes it should be fixed in the kernel, but the DMA transfer size is not >> necessarily documented and known. Worse, it can vary depending on the >> mode. So until the kernel folks figure out a solution, and said >> solution works for all know drivers, this patch is mandatory on the >> PulseAudio side. > > > Don't want to lose momentum on this patch, so just poking about. Good initiative. > What is the next stage here? Probably either one will work, but if we're about to release 0.9.22 (heard something from Lennart yet?), I suggest we go with my version for 0.9.22 as that one is the least invasive (only touches non-tsched devices), and keep Pierre's version in master. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
