Open nick87720z opened 2 years ago
alsactl monitor
= amixer events
It would probably make sense to send an end-of-output line in stdin mode (like ---END---
) - using a new amixer
argument. The numid=1 as the last line is not guaranteed for amixer controls
.
alsactl monitor
=amixer events
This looks more convenient than using alsactl. Using alsactl monitor
, single amixer controls
run is still necessary just to get proper channel ID to manage, while this gives all necessary info from start.
Though at least in alsa-utils 1.2.4 it's indocumented (though imho, program help should usually be updated first). Although I just use gentoo's stable version (last version, keyworded as experimental, is 1.2.6).
Though at least in alsa-utils 1.2.4 it's indocumented (though imho, program help should usually be updated first).
Fixed in 68473a41c6fa68f3d8331ef995b25c2c84a0ef92 .
It would probably make sense to send an end-of-output line in stdin mode (like
---END---
) - using a newamixer
argument. The numid=1 as the last line is not guaranteed foramixer controls
.
This starts to look like conventional shell with prompt string. I remember most cases they had it like %
or >
(not system shells, but rather command line utilities). There could be option command line option for user-supplied prompt.
I used alsactl and amixer to implement highly effective volume control applet executor. At least it's able to keep pace at touchpad, which sends 1000 scroll events in only 18 to 12 seconds.
amixer --stdin
handles control events, whilealsactl monitor
is even source for applet display part (it's tint2 executor). But in order to get values to display - this display part has to runalsactl sget
per request. Can't these commands be supported in stdin mode? From first look - expected lines number doesn't look unpredictable: forsget
it depends on number of channels, and forcget
- probably fixed.Even
controls
command also could be supported, since it lists channel from biggest ID to 1, so moment of numid=1 could be understood as end of list.