tree 04baa851c60f7c068d8b8218aeea20947cd40ba7
parent f7a478178a8ea970abd34f7ab73e66c9119b1606
author Takashi Sakamoto <o-takashi@sakamocchi.jp> 1496795885 +0900
committer Takashi Iwai <tiwai@suse.de> 1496814812 +0200

ALSA: firewire: process packets in 'struct snd_pcm_ops.ack' callback

In recent commit for ALSA PCM core, some arrangement is done for
'struct snd_pcm_ops.ack' callback. This is called when appl_ptr is
explicitly moved in intermediate buffer for PCM frames, except for
some cases described later.

For drivers in ALSA firewire stack, usage of this callback has a merit to
reduce latency between time of PCM frame queueing and handling actual
packets in recent isochronous cycle, because no need to wait for software
IRQ context from isochronous context of OHCI 1394.

If this works well in a case that mapped page frame is used for the
intermediate buffer, user process should execute some commands for ioctl(2)
to tell the number of handled PCM frames in the intermediate buffer just
after handling them. Therefore, at present, with a combination of below
conditions, this doesn't work as expected and user process should wait for
the software IRQ context as usual:
 - when ALSA PCM core judges page frame mapping is available for status
   data (struct snd_pcm_mmap_status) and control data
   (struct snd_pcm_mmap_control).
 - user process handles PCM frames by loop just with 'snd_pcm_mmap_begin()'
   and 'snd_pcm_mmap_commit()'.
 - user process uses PCM hw plugin in alsa-lib to operate I/O without
   'sync_ptr_ioctl' option.

Unfortunately, major use case include these three conditions.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>