Chris Jean

The audio port in one of my old motherboards starting putting out static in the right stereo channel. I decided to fix this by purchasing a cheap USB sound card and using it instead. The specific model that I purchased is by Sabrent and has a model number of AU-MMSA.

I plugged it into my system, opened Sound Settings, and chose “Audio Adapter Analog Stereo” from the device options. Sound then flooded my headphones with the volume being far too loud for comfortable listening. As I lowered the volume, the sound went from far too loud to completely silent when I moved from around 40% volume down to 35% volume. It was if somebody muted the volume.

After playing around with the settings for a while with no change in loudness or the sound cutting out at low volume, I dug in deeper. I found many different bug reports and suggested solutions to this issue, but only this one by user sen in the Arch Linux forums fixed both problems.

Unfortunately, the solution requires modifying a file as root, which can be a bit daunting, but I believe in you, so let’s modify that file.

First, open a terminal. This can be done by pulling up Ubuntu’s dash (clicking the Ubuntu icon at the top of the icon bar along the left of the screen), typing in “terminal” and clicking the enter key. Next, we need to edit the /usr/share/pulseaudio/alsa-mixer/paths/analog-output.conf.common file as root. This can be done by typing the following in the terminal and pressing enter:

[chris@home ~]$ gksu gedit /usr/share/pulseaudio/alsa-mixer/paths/analog-output.conf.common

You will then be prompted for your user password. Type it in and press enter.

A file editor will open up with the file loaded. Search for the text “Element PCM”. You should see the following text:

[Element PCM]
switch = mute
volume = merge
override-map.1 = all 
override-map.2 = all-left,all-right

Update this section of text to look like the following (changes are highlighted):

[Element PCM]
switch = mute
volume = ignore
volume-limit = 0.01
override-map.1 = all 
override-map.2 = all-left,all-right

Note that the value 0.01 can be adjusted as needed to change how quiet and loud the volume is. Making the number smaller reduces the max volume while making the number larger increases the max volume. I tested out 0.05 and found that the max volume was much louder than I would ever use. I also decided that 0.01 was technically louder than I’d ever use. I ended up with a value of 0.0075 (0.005 was too quiet) which I felt gave a good maximum volume and resulted in better overall control over the volume range.

Once you have saved the changes to the file, a couple things still need to be done in order to have this change go into effect.

Inside your terminal window (it should be behind the text editor), run the following command:

[chris@home ~]$ pulseaudio -k

This will force the audio system in Ubuntu to reload. If you had any application that was playing audio, it will go silent at this point. Any application that is now silent will have to be closed and reopened.

You can now test out the change to see if you need to adjust the number down or up to make the volume to your liking. Remember to save the file and run pulseaudio -k each time you change the number.

What Didn’t Work

I found a number of guides that recommended that the /etc/pulse/default.pa file be modified and have the following lines added:

load-module module-alsa-sink control=PCM
load-module module-udev-detect ignore_dB=1

Neither of these worked for me. The first config change had no effect. The second config change did fix the issue with the sound muting at low volumes, but the volume was still far too loud with just 1% volume being what I consider to be an 80-90% volume level.

Technical Details

For those that are interested in the technical details of this USB device, the following information is for you.

lsusb

Full verbose details (lsusb -vvvv) can be found here. These are the basics:

Bus 005 Device 002: ID 0d8c:000c C-Media Electronics, Inc. Audio Adapter
Device Descriptor:
  idVendor           0x0d8c C-Media Electronics, Inc.
  idProduct          0x000c Audio Adapter
  iProduct                1 C-Media USB Headphone Set

aplay -l

**** List of PLAYBACK Hardware Devices ****
card 2: Set [C-Media USB Headphone Set], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

alsa-info.sh

Full details.

There are times when running apt-get update in Ubuntu will result in error messages such as the following:

[chris@server ~]$ sudo apt-get update
Ign http://security.ubuntu.com trusty-security InRelease
Get:1 http://security.ubuntu.com trusty-security Release.gpg [933 B]
...
Fetched 21.9 MB in 14s (1,537 kB/s)
Reading package lists... Done
W: GPG error: http://security.ubuntu.com trusty-security Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
W: GPG error: http://archive.canonical.com trusty Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
W: GPG error: http://archive.ubuntu.com trusty Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
W: GPG error: http://archive.ubuntu.com trusty-updates Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
[chris@server ~]$ 

If these errors aren’t fixed, apt will have problems when installing or upgrading packages. For example:

[chris@server ~]$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
...
E: Some packages could not be authenticated
[chris@server ~]$ 

The apt packaging system has a set of trusted keys that determine whether a package can be authenticated and therefore trusted to be installed on the system. Sometimes the system does not have all the keys it needs and runs into this issue. Fortunately, there is a quick fix. Each key that is listed as missing needs to be added to the apt key manager so that it can authenticate the packages.

Looking at the error above, apt is telling us that the following keys are missing: 40976EAF437D05B5 and 3B4FE6ACC0B21F32. Notice that these are listed multiple times. Each unique key will only need to be added once.

To add these keys, run the following commands:

[chris@server ~]$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 40976EAF437D05B5
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.QTeppiINUh --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv-keys 40976EAF437D05B5
gpg: requesting key 437D05B5 from hkp server keyserver.ubuntu.com
gpg: key 437D05B5: public key "Ubuntu Archive Automatic Signing Key " imported
gpg: Total number processed: 1
gpg:               imported: 1
[chris@server ~]$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 3B4FE6ACC0B21F32
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.77TqYGKU7b --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv-keys 3B4FE6ACC0B21F32
gpg: requesting key C0B21F32 from hkp server keyserver.ubuntu.com
gpg: key C0B21F32: public key "Ubuntu Archive Automatic Signing Key (2012) " imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
[chris@server ~]$ 

If the keys that your system is missing differs, simply replace the key at the end of the above command with your key and run it.

My site is currently running off of an nginx HTTP server. In attempting to set up the site to respond to IPv6 requests, I ran into all sorts of problems. They all started off with the following error:

[gaarai@linode /etc/nginx]$ sudo service nginx restart
 * Restarting nginx nginx
nginx: [emerg] 807#0: no host in ":80" of the "listen" directive in /etc/nginx/sites-enabled/chrisjean.com:7

I poked around a bit more and ended up angering the nginx gods.

[gaarai@linode /etc/nginx]$ sudo service nginx restart
 * Restarting nginx nginx
nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)
nginx: [emerg] bind() to [::]:443 failed (98: Address already in use)
nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)
nginx: [emerg] bind() to [::]:443 failed (98: Address already in use)
nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)
nginx: [emerg] bind() to [::]:443 failed (98: Address already in use)
nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)
nginx: [emerg] bind() to [::]:443 failed (98: Address already in use)
nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)
nginx: [emerg] bind() to [::]:443 failed (98: Address already in use)
nginx: [emerg] still could not bind()

I then found out that the guides I used were quite old and recommended an old syntax that no longer works. I used the following syntax as recommended in the guides:

server {
    listen :80;
    listen [::]:80;
}

This no longer works and will result in the problems listed above.

There are two solutions to the problem.

First Solution

The first solution is to remove the colon from in front of the IPv4 port and to specify ipv6only=on for the IPv6 port. It turns out that in Linux, binding to an IPv6 TCP port automatically binds to the IPv4 port as well. This explains the error messages about bind failures. Using ipv6only=on ensures that the IPv6 listen directive will only bind to IPv6 and not automatically to IPv4 as well.

server {
    listen 80;
    listen [::]:80 ipv6only=on;
}

Second Solution

The second solution is to change all of the listen directives for each server block to use the IPv6 format, for example:

server {
    listen [::]:80;
}

Note that there is just a single listen directive. Since by default, an IPv6 listen directive will bind to both IPv4 and IPv6 TCP ports, only the single listen directive is needed to cover both IPv4 and IPv6.

I list this solution second as 1) you may not want all of your server blocks to be available on both IPv4 and IPv6 (keeping them separate gives more control), 2) it may take a large amount of work to change all of the server blocks, and 3) if even one block is not updated properly, the server will be taken down. It is important to note that adding this listen directive is necessary even for server blocks that do not list a listen directive as the default is listen *:80, which only binds to IPv4.

Take the following block as an example.

server {
    server_name .gaarai.com;
    rewrite ^ http://chrisjean.com$request_uri? permanent;
}

This is a server block that causes redirection of one of my older domains to my current domain. This needs to be updated to the following:

server {
    listen [::]:80;
    
    server_name .gaarai.com;
    rewrite ^ http://chrisjean.com$request_uri? permanent;
}

Without this change, if I’m updating my server blocks to use the second method, restarting nginx will once again start spewing the messages about bind failures:

[gaarai@linode /etc/nginx]$ sudo service nginx restart
 * Restarting nginx nginx
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] still could not bind()

Using Explicit Addresses

Some of you may wonder about server blocks that have to have explicit address designations. In situations such as these, using the first solution would be the best option as it gives you the most control over how to declare everything. This is how such a server block would look for my server:

server {
    listen 72.14.185.165:80;
    listen [2001:470:1f0e:4da::2]:80;
}

When using this method, you can’t use the listen [::]:80; directives as in the second solution since you’ll run into binding issues again.

Summary

First solution:

• Pros
  • More flexibility
  • Easier to maintain with complex setups
  • Easier to maintain when listening to address-specific ports
• Cons
  • Adds an extra line to each server block (I admit that it’s a sad excuse for a con)

Second solution:

• Pros
  • Looks cleaner having just the one listen directive for each server block
  • Ensures that all the server blocks are configured on IPv6 and IPv4 as errors will occur if a single block is left in just IPv4
• Cons
  • Can cause more headaches in complex setups as you won’t be able to use address-specific listen directives
  • Can cause many more errors than the first solution until all of the server blocks are updated to use the single listen directive properly

What am I using on my server? After ensuring that I understood both approaches, I went with the first solution. The idea of going through and reconfiguring everything later if/when I have to make some more complex changes doesn’t sound very appealing to me.

Misc Details

My server is hosted at Linode and is currently running Ubuntu Server 13.10 with nginx version 1.4.1. Since Linode supports IPv6, my server was already configured to have IPv6 addresses available. If you have a server that does not have IPv6 allocations yet, you can use Hurricane Electric’s Tunnel Broker to get an IPv6 tunnel that directs IPv6 traffic to your server’s IPv4 address.

More details about nginx’s listen directive can be found in the official documentation.