On 11. 04. 23 18:50, Oswald Buddenhagen wrote:
If we allow modification of the PCM buffer, I think that we should:
- Do not modify the buffer for drivers already working with the appl_ptr data (end position) only.
i suppose that should be detected by the drain callback being set up?
Yes, but it would be probably better to add a default silencing callback with a warning to notify authors of drivers to review and eventually correct the behavior.
- Handle the situation with the large buffer; it may make sense to change the "wait" operation from the end-of-period interrupt to time scheduler and stop the drain more early when the end-of-valid data condition is fulfilled.
i don't understand what you're asking for.
Use jiffies/timeout instead waiting to the interrupt. In this case, the stop may be called earlier (in the middle of period). In this case the silenced area may be much smaller.
- Increase the protocol version.
But as I wrote, I would make those extensions configurable (SNDRV_PCM_HW_PARAMS_DRAIN_ALLOW_SILENCE). It can be turned on by default.
i have no clue what would be involved in doing that. to me that sounds like overkill (solving a non-issue), and goes waaaay beyond what i expected to invest into this issue (really, i just wanted to verify that the emu10k1 fixes work, and accidentally discovered that there is a mid-layer issue that affects user space, as the pyalsaaudio lib i'm using doesn't handle it).
OK. I don't think that it's a pyalsaudio job to resolve the issue with the minimal transfer chunk / period (which you set / know before the transfer is initiated).
Jaroslav