Hi, On Thu, Dec 17, 2020 at 09:55:49AM +0900, Susie B. wrote: > On Sun, 13 Dec 2020 22:32:17 +0900 > Takashi Sakamoto <o-takashi@xxxxxxxxxxxxx> wrote: > > Additionally, amixer doesn't parse the value with 'dB' suffix. It can > > handle two types of values; raw control value and percentage. Therefore > > you can't configure the control element with dB value. > > > > Furthermore, as long as I know, the parser of command line argument for > > the values includes some bugs. It comes from alsa-lib implementation[4]. > > I'd like to fix it if I keep enough time for it, but currently now, as > > you know I'm busy for the service programs... > > > > [4] https://github.com/alsa-project/alsa-lib/blob/master/src/control/ctlparse.c > > After my recent post, I consulted again with the man page of amixer[1] > and found a sample which work on my on-board sound: > > [~]$ amixer -c 1 -- sset Master -20dB > Simple mixer control 'Master',0 > Capabilities: pvolume pvolume-joined pswitch pswitch-joined > Playback channels: Mono > Limits: Playback 0 - 64 > Mono: Playback 44 [69%] [-20.00dB] [on] > > I actually could hear the sound volume change. > I could find the '--' have definitive effect, but I have no idea how it works. > (I'm also a newbie of shellscript, so...) > > I'm very sorry for having posted my question before I had done all the > investigation I could and wasted Sakamoto-san's time. But so please let > me post the first question again. > > The man page states; > > COMMANDS > ... > > set or sset <SCONTROL> <PARAMETER> ... > Sets the simple mixer control contents. The parameter can be the > volume either as a percentage from 0% to 100% with % suffix, a > dB gain with dB suffix (like -12.5dB), or an exact hardware > value. The dB gain can be used only for the mixer elements with > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > available dB information. When plus(+) or minus(-) letter is > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > appended after volume value, the volume is incremented or decre‐ > mented from the current value, respectively. > > ... > > The element above of my on-board sound seems to have the dB infomation as the man states: > > [~]$ amixer -c1 cget iface=MIXER,name='Master Playback Volume' > numid=37,iface=MIXER,name='Master Playback Volume' > ; type=INTEGER,access=rw---R--,values=1,min=0,max=64,step=0 > : values=44 > | dBscale-min=-64.00dB,step=1.00dB,mute=0 > > And an element of my AF4 also has similar information but it will not accept dB value: > > [~]$ amixer -c2 cget iface=MIXER,name='playback-volume' > numid=3,iface=MIXER,name='playback-volume' > ; type=INTEGER,access=rw---RW-,values=6,min=0,max=33554432,step=1 > : values=33554432,0,0,0,0,0 > | dBminmax-min=-144.00dB,max=0.06dB > > [~]$ amixer -c2 -- sset 'playback-volume' -144.00dB > amixer: Invalid command! > > [~]$ amixer -c2 -- sset 'playback-volume' -144.00dB,-144.00dB,-144.00dB,-144.00dB,-144.00dB,-144.00dB > amixer: Invalid command! > > I also tested some other elements, (I mean the 'output-volume' element > and one of the six 'monitor-gain' elements,) but results were the same. > > If this error is caused by some software developmental problem like seen > in the reference [4], I'll give up. But if there are some means for a > non-programmer to solve it, I'd like to use them. Are there such things? Ah..., I've mentioned with the basis to use 'cset' instead of 'sset' since alsa-lib's simple mixer interface cannot handle control element with multiple values correctly. Amixer uses below APIs in simple mixer interface to compute dB-represented value: - snd_mixer_selem_set_playback_dB() - snd_mixer_selem_set_capture_dB() Thus it probably fails to operate control elements with 'sset' sub-commands for AF4. > > Fireworks board module is designed to have flash memory for permanent > > storage. The module allows software to update the content of memory by > > asynchronous transaction in IEEE 1394 bus. The memory is used for two > > purposes; for several types of firmwares, and for configuration. > > > > In this August, I posted the series of patchset to update the content in > > firmware part only[1]. > > > > [5] Not merged yet for several resons. > > [PATCH 00/25] alsa-tools: efw-downloader: add initial version of firmware > > downloader for Echo Audio Fireworks devices > > https://mailman.alsa-project.org/pipermail/alsa-devel/2020-August/172711.html > > It is good news for an AudioFire user like me, who has abondoned Windows for own use long ago. > I'll happily wait its release. I have a plan to push firmware files to linux firmware repository or so. But I have tasks with higher priority and it's postponed. > > As another side, as long as I know, alsactl tool includes bugs to handle > > control element with multiple values (again...). > > ... > > In my opinion, basic ALSA tools (amixer, alsamixer, and alsactl) > > includes many bugs for control elements with multiple values. In the > > meaning, we stand in the first place to start fixing them. > > https://github.com/alsa-project/alsa-lib/blob/master/src/control/ctlparse.c > > (I wonder the reason, but I guess the ALSA project has little > > integration for the kind of devices which have control elements with > > many channels in recent decades.) > > And nowadays should the user of pro-sumer firewire equipment, especially > who has little knowledge of Linux or ALSA like me, use FFADO than ALSA to > avoid troubles? > > I choosed ALSA other than FFADO for my AF4 because ffadomixer has no > volume level indication and it seems more complicated for me to connect > ffado device to pulseaudio which is my distro's default. (and I use it > in almost case other than some audio measurements in which I use > JackAudio.) > > But If so, I'd like to start learning about FFADO. Depends on your preference. It's my pleasure if you use ALSA drivers, but as I noted ALSA software support for multichannel devices is not enough good at present. If you have less motivations to ALSA project itself, it's better to use FFADO stuffs and leave ALSA software as is, as many users do. > > At present, I leave them as is because the most of my time is used to > > develop the service programs and in-kernel packet streaming engine. > > But the works came out of the time helpes me a lot. I'd like to thank you > again for your help. I have no idea about "in-kernel packet streaming". > So please let me know about it and your works on it for my knowledge. If > it is convenient for my audio system, I'd also like to try them. Hm. I attempt to describe software relevant to audio and music units on IEEE 1394 bus. The most of devices in IEEE 1394 bus for use case of audio and music utilize isochronous communication. It looks like 'packet streaming'. Linux FireWire subsystem allows userspace applications to process the packet streaming from/to the devices. FFADO project utilizes it to produce 'libffado2'. As long as I know, 'jackd' in Jack Audio Connection Kit is only an application which uses APIs of 'libffado2'. Thus usage of FFADO means usage of jackd. Linux FireWire subsystem allows kernel drivers to process the packet streaming. ALSA firewire stack includes packet streaming engine as well as drivers for the devices. As a result, ALSA PCM/RawMIDI applications can transfer PCM frames and MIDI messages to the devices via ALSA PCM/RawMIDI interfaces. There are many userspace applications with ALSA PCM/RawMIDI interfaces, thus usage of drivers in ALSA firewire stack means to work with the applications; e.g. jackd, pulseaudio and so on. FFADO project also produces 'ffado-dbus-server' so that userspace applications can configure the devices for some controllable functionalities such as volume, by inter process communication via D-Bus. On the other hand, drivers in ALSA firewire stack doesn't produce the way to control them since they are developed with focus on packet streaming. Service programs in 'snd-firewire-ctl-services' repository produces controls for the functionalities, as you tested. Some users indicates that devices generates noisy sound when using drivers in ALSA firewire stack. On the other hand, they generates expected sound when using jackd with libffado2. I've been investigating the issue further for recent years with newly-developed tools (libhinawa and libhinoko) for analysis of packet streaming in several kinds of devices. After finishing development of the service programs, I'll tackle the issue (I guess next whole year). However, the design of libffado2 did not vary since it was developed. The library APIs are not better nowadays. For example, PipeWire developer makes a difficulty to implement FFADO backend[1]. I found the other design fault of libffado2 such like deep-buffering when developing FFADO backend for axfer[2], but don't mention it here. At last, if you find some issues of ALSA firewire stack, please file it in repository which I maintain[3]. If you find some issues of control service programs, please file it as well[4]. I'm pleased to see it. (I note that I should pay enough attention to whole supported devices, on the other hand users tend to focus just on their own device. The difference of each place can easily bring miscommunication.) [1] https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/326 [2] https://github.com/alsa-project/alsa-utils/blob/master/axfer/xfer-libffado.c [3] https://github.com/takaswie/snd-firewire-improve/issues [4] https://github.com/alsa-project/snd-firewire-ctl-services/ Regards Takashi Sakamoto _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
