On Tue, 11 Apr 2023 19:23:17 +0200, Jaroslav Kysela wrote:
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.
Does this difference matter so much? I guess you're concerned about the performance, right? This sounds a bit too complex just for the simple purpose...
- 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).
I'm thinking whether we need to change anything in the kernel side for this at all. Can't it be changed rather in alsa-lib side instead?
Takashi