On 03. 05. 23 22:00, Oswald Buddenhagen wrote:
On Wed, May 03, 2023 at 09:32:02PM +0200, Jaroslav Kysela wrote:
On 03. 05. 23 18:10, Takashi Iwai wrote:
The dmix uses the silence_size=boundary as a fill-all operation, and
it's a free-wheel mode, so supposedly something was overlooked in your
code refactoring.
Could you check it and address quickly? I'd like to fix it before
6.4-rc1 release, so if no fix comes up in a couple of days, I'll have
to revert the change for 6.4-rc1.
I would revert this patch.
It seems that this "do silence right after the playback is finished"
mechanism is not handled in the updated code (and I overlooked that,
too):
no, there is nothing wrong with the code _per se_.
what's happening is that the dmix plugin doesn't update the application
pointer, and somehow gets away with it.
Dmix uses the free mode, because multiple applications can write to the
buffer. We cannot do application pointer updates in the shared resource.
anyway, this means that we need to revert the code path for top-up mode,
which means reverting most of the patch's "meat".
i think i can do better than your proposal, but not today anymore.
Ok, let's see. I tried to be minimalistic to fix bugs and then we can talk
about the improvements.
fwiw, the echo results from the plugin apparently summing up the samples
in the buffer without clearing it first, that is, it relies on the
auto-silencing doing the clearing, which the patch broke under the given
circumstances. rather obvious in retrospect.
Dmix does not know which samples were updated by other applications. The
application tracks only own samples.
Jaroslav
--
Jaroslav Kysela <perex@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
