[pulseaudio-discuss] [PATCH] Do not use tsched watermark if tsched is disabled
gmane at colin.guthr.ie
Tue Aug 31 08:57:15 PDT 2010
'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
>> What's the role of snd_pcm_rewindable()? 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)
Tribalogic Limited [http://www.tribalogic.net/]
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the pulseaudio-discuss