bas at bmail.ru
Wed Aug 17 07:06:30 EDT 2011
The incorrect path to asound.state is already fixed in later builds.
On Wed, 17 Aug 2011, EdorFaus wrote:
> I've noticed the volume on the NanoNote is rather loud, and the 5-level
> Master control doesn't really help much.
> So, I wrote an /etc/asound.conf file that adds a software volume control, and
> made that device the default, which helped a lot. Since the NanoNote doesn't
> have a PCM control, I named it that.
> During this, I realized that the volume settings aren't saved across
> restarts. There's an init.d script that tries to do this (ben-nanonote), but
> it fails because alsactl tries to save/load from a path that doesn't exist.
> Since there's a state file in /etc, I assumed it was supposed to use that,
> and added -f /etc/asound.state to the alsactl commands in that script, which
> fixed the problem. An alternative fix would be to create the directory it
> saves in by default (/var/lib/alsa).
> Also, the volume up/down buttons really only worked in gmu, which was a bit
> annoying - so I added a config file for triggerhappy that changed the volume
> of this new control whenever those buttons were pressed.
> So far, so good. But. Now, in gmu, the volume control got a bit confused -
> because the buttons would change both the gmu-internal volume and the ALSA
> volume, leading to inconsistent volume levels.
> I tried making gmu use hardware volume control, and got that to work after a
> fashion - by default it changed the Master control, which wasn't very useful,
> so I added some more settings to my asound.conf and reconfigured the ALSA OSS
> emulation to use the PCM control (by writing to
> /proc/asound/card0/oss_mixer). This made gmu use the same software volume
> control as the rest of the system.
> However, that wasn't really any better - the volume still got confused since
> gmu apparently doesn't read the control, only sets it to the value it keeps
> (and changes) internally, so now I ended up with volume that jumped around a
> bit whenever I changed it (since it was being changed by both gmu and
> I eventually ended up simply configuring gmu to not have working volume
> up/down buttons (by commenting out the (In|De)creaseVolume lines in
> ~/.config/gmu/nanonote.keymap) and to use the default software volume control
> (so it doesn't set the "hardware" one when it starts).
> That way, volume is controlled by the buttons via triggerhappy, and works
> reliably (even in other programs), and the only thing I lost was having gmu
> display something when the volume is changed.
> If anyone's got a better idea, a way to improve this further, I'd love to
> hear about it.
> I've attached my asound.conf file (which includes the OSS emulation part,
> except the /proc stuff), and the triggerhappy volume.conf file, in case
> anyone wants them.
> P.S. Should I be doing anything with this kind of stuff other than post here
> about it? I mean, to make things easier for the maintainers or whoever else
> wants to use it, if anyone?
More information about the discussion