search

alsa-project / alsa-utils

The Advanced Linux Sound Architecture (ALSA) - utilities
GNU General Public License v2.0
200 stars 138 forks source link

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

Open aiChaoSONG opened 2 years ago

aiChaoSONG commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

Typo caught: aboeted -> aborted

Indeed. I filed a patch to fix it.

https://github.com/alsa-project/alsa-utils/pull/156