'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. What is the next stage here? Should I test with a lower number (1.45ms) as originally suggested. If that turns out to work, what then? I'd like to get something that addresses this problem into stable queue sooner rather than later (i.e. before I forget about this thread and get distracted by something!). As I only pretend to know what's going on, I don't fully understand all the issues here so Pierre and David: if you could hash out the right approach between you, I'll commit and/or test the results (tho' not in that order :D) Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
