[Enhancement] aplay: make stream pause/resume automation/script friendly

[aiChaoSONG]

There is an -i option for interactive mode, in the interactive mode, we are able to pause/resume the playback/capture stream with SPACE key, which is very good. However we have to do this in a terminal, because there is a isatty check on the stdin, this is not friendly for automation/script to test audio pause/resume feature with aplay.

Is it possible to remove the isatty check, so that we can do pause/result test with a single stdin redirection? Another possible fix is that we can make use of the SIGUSR2, so that we pause/resume stream by sending signal to the aplay process.

@perexg

[takaswie]

Hi @aiChaoSONG ,

I'm an author of axfer, which has compatibility to aplay as much as possible to obsolete
aplay in future.

As long as reading the issue, you need inter process communication to aplay process
to pause/resume PCM substream. Indeed, it's useful for some users, but not so much.

Is it possible to remove the isatty check, so that we can do pause/result test with a single stdin redirection?

I've mention about relevant issues in COMPATIBILITY TO APLAY section of axfer manual[1]. Let's see it.

-i, --interactive
  This option is not supported at present. In aplay(1) implementation, this
  option has an effect to occupy stdin for key input and suspend/resume PCM
  substream according to pushed enter key. However, this  feature  requires
  an additional input handling in main loop and leave bothersome operation
  to maintain PCM substream.

At the first place, occupation of standard input has a conflict in the case of PCM playback
that stdin is not available for source of audio data frame. I have a concern about such
complexity in a view of users.

Another possible fix is that we can make use of the SIGUSR2, so that we pause/resume stream by sending signal to the aplay process.

I implement suspend/resume by SIGTSTP/SIGCONT signals into axfer and it's near
what you image.

In POSIX SIGNALS section, I put some explanations about implementation specific to axfer:

POSIX SIGNALS
  During transmission, SIGINT and SIGTERM will close handled files and PCM
  substream to be going to finish run time.

  SIGTSTP will suspend PCM substream and SIGCONT will resume it. No XRUNs
  are expected. With libffado backend, the suspend/resume is not supported and
  runtime is aboeted immediately.

  The other signals perform default behaviours.

The explicit description about difference between aplay and axfer to handle signals:

SIGTSTP, SIGCONT
  This performs suspend/resume of PCM substream. In aplay(1) implementation,
  these operations bring XRUN state to the substream, and suspend/resume is
  done in interactive mode in the above. Some developers  use  the  signal for
  recovery test from XRUN. At present, no alternative is supported for the test.

SIGUSR1
  This is not supported. In aplay(1) implementation, this signal is assigned to a
  handler to close a current file to store audio data frame and open a new file to
  continue processing. However, as well as --max-file-time option, this option
  should increase complexity of main loop of axfer.

I'm glad if they are helpful to you.

[1] https://github.com/alsa-project/alsa-utils/blob/master/axfer/axfer-transfer.1#L781

Regards

[aiChaoSONG]

@takaswie wow, this is awesome, thank you.

Actually, we use the -i feature to test pause-push-release in the kernel.

Typo caught: aboeted -> aborted

With libffado backend, the suspend/resume is not supported and runtime is aboeted immediately.

[takaswie]

Typo caught: aboeted -> aborted

Indeed. I filed a patch to fix it.

#156