[pulseaudio-discuss] [PATCH] Do not use tsched watermark if tsched is disabled

[David Henningsson]

2010-08-18 19:19, pl bossart skrev:
>>> * Pierre-Louis Bossart's version in git master sets a fixed margin of
>>> 256 bytes, (configurable if you load the sink manually, i e not through
>>> module-udev-detect).
>>>
>>> * My version sets a fixed margin of 20 ms.
>>>
>>> * My version only changes non-tsched devices and keeps tsched having a
>>> margin of the current watermark, whereas Bossart's version changes both.
>>>
>>> I think a margin should be based on milliseconds rather than bytes (the
>>> amount of bytes varies with amount of channels, which means that we
>>> might get problems when people switch to surround output).
>>>
>>> I don't have an opinion on whether a fixed margin or watermark-based
>>> margin is better for tsched sinks.
>>>
>>
>>
>> I presume Pierre-Louis will comment in due course. I'm sure he'll see
>> this message.
>>
>> I'm annoyed I didn't appreciate that his fix would likely address the
>> issue too when it was pushed, but such is life :D
> 
> Well I didn't see the link between my patch (from April) and the
> problem David tried to fix either. Thanks Raymond for finding this
> out.
> 
> Before making any conclusions, would the problem be solved with
> David's patch using the equivalent of 256 bytes, that is 1.45ms
> instead of 20ms? just want to make sure this is the same bug.

Haven't tested, but I feel quite certain that it's the same one.

> 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?

> 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).

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic