>> * 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. 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. 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. -Pierre
