[alsa-devel] [PATCH 1/2] ALSA: firewire: process packets in 'struct snd_pcm_ops.ack' callback

[Takashi Sakamoto]

On Jun 13 2017 21:03, Takashi Iwai wrote:
> Thanks for the analysis.  Yes, the cost by the explicit calls is
> known, and it's what was mentioned in the commit log as a further
> optimization.  I bought this cost as good enough for better appl_ptr
> accuracy, but you thought differently on that.
>
> One thing to be noted is that user-space doesn't have to call sync_ptr
> at all, and even no period IRQ is triggered depending on the setup
> (e.g. PA prefers it).  This is the case we want to solve.  That is,
> the situation is worse than you thought -- things don't work as
> expected unless we enforce the sync_ptr notification from user-space.
>
> Then, the question is how to enforce it.  The easiest option is to
> disable status/control mmap.  That's how the patch was developed.
> As an option,
> 1) Selectively disable mmap by a new flag, or
> 2) Selectively disable mmap by the presence of ack callback.
>
> And (2) seems too aggressively applied, from your opinion.
>
> Now you might thing another option:
> 3) Add a new PCM info flag and let alsa-lib behaving differently
>     according to it
>
> But this is no-go, since it doesn't work with the old alsa-lib.
>
> So, IMO, we need to go back to (1), which is my original patch, as a
> start.  It affects only the driver that sets (in this case, it's SKL+
> driver) and it works with the old user-space, at least.
>
> Then we can improve the performance in alsa-lib.  alsa-lib has some
> inefficient implementation regarding the hwptr/appl_ptr update.  In
> may places, it calls hwsync, then do avail_update that again calls
> sync_ptr, for example.  I guess we can halves the amount of sync_ptr
> calls by optimizing that.
>
> Since the sync_ptr is used for all non-x86 architectures (i.e.
> nowadays majority of devices in the market), the optimization is a
> good benefit for all.  Worth to try, in anyway.
>
>
> And yet another obvious optimization would be to allow only the status
> mmap and disallow the control mmap.  Currently, both are paired and
> the control mmap can't fail if the status mmap succeeds.  But, for
> the case like this, we want to suppress only the control mmap.
>
> Unfortunately, changing this behavior requires both alsa-lib and
> kernel codes.  And keeping the behavior compatibility, we'd need to
> introduce something new, e.g. an ioctl to set the compatible protocol
> version from alsa-lib.  For now, alsa-lib inquires the protocol
> version the kernel supports (SNDRV_PCM_IOCTL_PVERSION).  The newly
> required one is the other way round, alsa-lib telling the supported
> protocol version to kernel.  Then the kernel can know whether this
> alsa-lib version accepts the status-only mmap, and gracefully returns
> -ENXIO for the control mmap.

Hm, I have no objections to the changes of both kernel/userspace, but
from different reasons. Therefore I have different solution for this issue.

I recognize this issue as a change of programming model for new design
of devices. (Advantages for drivers for audio and music units on IEEE
1394 bus and the others is its sub-effect, a minor bonus.)

Current ALSA PCM interface is designed based on an idea for data
transmission; hardware is unaware of how many PCM frames are already
queued or dequeued on PCM buffer in system memory. Hardware can transfer
PCM frames to a part of the buffer with un-dequeued PCM frames (at
capture) or from a part of the buffer without enough queued PCM frames
(at playback). This design doesn't require kernel stuffs to maintain the
application-side position on PCM buffer.

If my understanding is correct, Intel's recent hardware can aware of
the application-side pointer and maintain the data transmission,
according to relative position of the application-side and the
hardware-side on the PCM buffer. As Pierre-Louis said, this could
satisfy Intel's convenience; e.g. reduce power comsumption. I guess
that it can decrease frequency to drive hardware for the data
transmission, or do the data transmission as better timing.

This model of data transmission is new in this subsystem. I think it
reasonable to add enough stuffs in both update kernel/userspace and
update version of the interface for this design.

A several years ago, no-period-wakeup programming model was introduced,
and this subsystem got large changes for both kernel/user land. I
believe this issue also has the similar impact. In my taste, in this
case, it's better to give up to keep full backward compatibility, and
renew related stuffs. When working with old userspace stuffs, drivers
run with old mode (namely, run for current interface). The difference
of interface version is absorbed in alsa-lib as much as possible, then
application runs without large changes.


Regards

Takashi Sakamoto