AXFER(1)

πŸ’– AXFER(1) β€” General Commands Manual πŸ’–

okay bestie, sit down, hydrate, because I'm about to put you onto axfer β€” the command-line sound recorder and player for sound devices and nodes supported by the Linux sound subsystem (that's the Advanced Linux Sound Architecture, aka ALSA, you've definitely seen it lurking in your dmesg). 🎧✨


✨ NAME ✨

axfer β€” command-line sound recorder and player for sound devices and nodes supported by Linux sound subsystem (Advanced Linux Sound Architecture, also known as ALSA).


🌸 SYNOPSYS 🌸

axfer subcommand direction options

subcommand = transfer | list | version | help

direction = capture | playback

options = ( depends on subcommand )

(yes the heading is spelled like that, I don't make the rules, I just respect them πŸ’…)


πŸ¦‹ DESCRIPTION πŸ¦‹

so axfer is a command-line recorder and player, and its whole thing β€” its main character energy β€” is transferring audio data frames back and forth between sound devices/nodes and files/stdin/stdout. that's it. that's the job. recording in, playing out, files on either side. simple, iconic, no notes. 🫢


πŸŽ€ OPTIONS πŸŽ€

Subcommand

  • transfer β€” actually does the transmission of the audio data frame. the whole rundown lives in the axfer-transfer(1) manual, go read it, it's giving detail. πŸ“Ό
  • list β€” dumps out lists of all the available sound devices and nodes. full tea is in the axfer-list(1) manual. πŸ‘€
  • version β€” prints the version of this application (and it's the same version as the alsa-utils package, fr fr).
  • help β€” prints a short little message about the subcommands, for when you're entering this application and need a friendly hand. 🫢

Direction

  • capture β€” operates for capture transmission. (recording, bestie πŸŽ™οΈ)
  • playback β€” operates for playback transmission. (playing it back out πŸ”Š)

πŸ’€ EXIT STATUS πŸ’€

  • EXIT_SUCCESS (0) if the run time finished successfully πŸŽ‰
  • otherwise EXIT_FAILURE (1) 😭

🧚 UNIT TEST 🧚

this program has unit tests for its internal implementation, because it's a responsible queen. πŸ’… please refer to the manual of axfer-transfer for the details.


🌈 COMPATIBILITY TO APLAY 🌈

axfer is designed to be compatible with aplay(1) as much as possible. on the command line, running the aplay/arecord files under $PATH runs axfer in compatibility mode, as long as the filesystem has a symbolic link from aplay/arecord to axfer.

$ ln -s aplay axfer
$ ln -s arecord axfer

A string to which arg[0] points

when args[0] at run time points to a string that ends with 'aplay', it means the same thing as the playback direction. when it points to a string ending with 'arecord', it means the same thing as the capture direction. slay, it just knows. ✨

Options acknowledged as list subcommand

the options -l, --list-devices, -L, and --list-pcms are acknowledged as the list subcommand. without them, the run time performs the transfer subcommand. lowkey the vibes do the dispatch for you. πŸ¦‹


πŸ› REPORTING BUGS πŸ›

report any bugs to the mailing list of the ALSA community <alsa-devel@alsa-project.org>, where the development and maintenance is primarily done. there's also a bug tracking service for the alsa-utils repository on github.com if that's more your vibe. don't be shy, they wanna hear it. πŸ™ˆ


⭐ SEE ALSO ⭐

axfer-transfer(1), axfer-list(1), alsamixer(1), amixer(1)


πŸ‘‘ AUTHOR πŸ‘‘

Takashi Sakamoto <o-takashi@sakamocchi.jp>


and that's the whole page, bestie!! πŸ“ this alsa-utils situation is from 28 November 2018 β€” literally an icon, aging like fine wine, and AXFER(1) remains that girl. go record something, go play something, go make the sound devices do their thing. mwah. πŸ’œπŸŽ€βœ¨