PC Speaker weirdnesses

Today we were trying to do some debugging by getting some tones out of a laptop speaker by frobbing bit 1 of port 0x61 on the keyboard controller.  Rather unexpectedly I got no sound whatsoever out of the speaker, yet I had managed to do so the day before.   So I double checked what had changed since the day before:

1. Was it because I upgraded my kernel?
2. Did I unexpected disabled the speaker when tweaking BIOS settings?
3. Was it something interfering with my port 0x61 bit twiddling?
4. Was the hardware now broken?

As per usual, I first assumed that the most complex parts of the system were to blame as they normally can go wrong in the most subtle way.  After a lot of fiddling around I discovered that the PC speaker only worked when I plugged the AC power into the laptop.  Now that wasn't obvious.

I suspect I should have applied Occam's Razor to this problem to begin with. We live and learn...

Poking around the HD-Audio Configuration

HD-Audio can be reconfigured without having to re-load the driver using the special sysfs files - this enables one to twiddle and debug HD-audio in a relatively pain free way.

Each codec-hwdep device has a sysfs directory in /sys/class/sound populated with a bunch of files which can be read. Some of these files can be written to, enabling one to over-ride the default. For example on my Lenovo I have /sys/class/sound/hwC0D0 which contains:

vendor_id
32 bit codec vendor id (hex) (read-write)

subsystem_id
32 bit subsystem id (hex) (read-write)

revision_id
32 bit revision id (hex) (read-write)

chip_name
name of chipset

afg
AFG id (read-only)

mfg
MFG id (read-only)

name
code name string (read-write)

modelname
current model option (read-write)

init_verbs
verbs to be execute at initialisation time. Extra verbs can be added by writing to init_verbs as numbers in the form: nid verb parameter

hints
hint strings in format 'key= value', e.g. eapd_switch = yes (for example, this particular hint is picked up by a call to snd_hda_get_bool_hint(codec, "eapd_switch") in the patch_sigmatel.c source)

init_pin_configs
show the default initial pin configurations as set up by the BIOS at boot time

driver_pin_configs
show the default pin configurations as set by the codec parser. Only pin configurations changed by the parser are shown.

user_pin_configs
show ping configurations used to override the BIOS set up configurations. One can append new values by writing a nid and value tuple to this file.

reconfig
triggers codec reconfiguration by writing any value to this file

clear
codec reset, remove mixer elements, clear all init verbs and hints

For example to see the BIOS pin configurations on my Lenovo laptop:

$ cat /sys/class/sound/hwC0D0/init_pin_configs
0x14 0x99130110
0x15 0x411111f0
0x16 0x411111f0
0x17 0x411111f0
0x18 0x03a19820
0x19 0x99a3012f
0x1a 0x411111f0
0x1b 0x0321401f
0x1c 0x411111f0
0x1d 0x40178e2d
0x1e 0x411111f0

And to identify my audio hardware, I can use:

$ cat /sys/class/sound/hwC0D0/ \
{vendor_name,chip_name,vendor_id,subsystem_id}
Realtek
ALC861-VD
0x10ec0862
0x17aa3867

..showing that my Lenovo has Realtek ALC861-VD and the vendor and subsystem ids.

Enjoy!

HDA Analyzer

The HDA Analyzer tool that allows one to look at the raw HD-audio control data in an easy to user GUI. The instructions on how to download and use this tool are described at the HDA Analyzer page - they are as follows:

1. Fetch:

wget -O run.py http://www.alsa-project.org/hda-analyzer.py

2. Run:

python run.py

And browse...

This certainly takes the pain out of looking at the control information.

Audio Weirdnesses

Yesterday I got poking around a perplexing audio recording issue; quite bizarrely stereo (2 channel) audio from the internal microphone would record perfectly, but mono (1 channel) would not. After working my way down through the driver and though ALSA I got to the point where I could not see how there could be any driver problem, so the issue had to be with the ALSA user space library, or the hardware (or both!).

My colleague spotted an interesting characteristic - using alsamixer to set the capture level to 100% left channel and 0% right channel or vice-versa made the mono recording work. Further investigation by using stereo recording of a pure sine wave (whistling into the microphone!) showed that the left channel was the complete reverse of the right channel. Then the penny dropped - the mono recording was essentially ALSA summing left and right channels, causing a near perfect zero recording since the left channel was the inverse of the right channel. Doh.

As it is, this very same issue has been discussed on LKML here with a suggested workaround described by Takashi Iwai here as follows:

Put the below to ~/.asoundrc

pcm.imix {
 type plug
 slave.pcm "hw"
 ttable.0.0 0.5
 ttable.0.1 -0.5
}

And record using:

arecord -Dimix -c1 test.wav

Urgh. Well, at least there is some kind of ALSA workaround.

So the moral of the story is to twiddle with left and right channel levels and do some stereo recording and look at the results before hacking through the driver. I should have applied Occams' razor - I assumed the complex part (the driver) was the problem.

Totem-tastic! BBC podcasts!

The Totem media player on Ubuntu has the ability to download the current podcast list from the BBC with minimum fuss. It's great for catching up on missed BBC radio podcasts when I've been out of the UK or too busy to hear them in real-time.

To get to the podcasts, fire up Totem with Applications->Sound & Video->Movie Player and then on the Playlist drop down (top right) select BBC and in a few moments Totem will have downloaded the contents index and you can browse and select the podcast you desire.



Pity this feature isn't promoted more. It saves one from rummaging around on the BBC website looking for relevant podcasts. Totem-tastic!

Measuring Audio Quality with Audacity

On some netbooks or laptops you may think the audio quality is good enough for your everyday sound experience; however some audiophiles can pick up audio problems that are sometimes deemed very subjective. For example, the younger people can pick up sounds upto ~20-21Khz and this can drop to ~15Khz or lower as one gets older. Also, we can get tuned to listening to music that has been psycho-acoustically modified, such as when using MP3 compression, which again can reduce and remove subtle harmonics and overtones that most people will just not notice.

But what about the actual hardware on a laptop or netbook? Surely this cannot mess with sound that much. Well, you may be surprised. To remove the subjectivity from my experimentations, I set up some test cases that could be scrutinised by more than the human ear.

Test 1: 440Hz Tone.

I used audacity to generate a 440Hz pure sine wave tone; 440Hz is A above middle C (C4) on an equally tempered musical scale. Then I played this tone at varying volume settings (adjusting them using alsamixer) out through the headphone socket down a low impedance cable into a 44KHz 16 bit sampler. I then took the digitised signal and again used audacity to plot the spectrum (select Analyze->Plot Spectrum).

At low volume settings, I was able to see just the 440Hz peak, but as I increased the volume settings, I was able to see lots of additional harmonics appear. This explained the distortion I was hearing when the volume was cranked up fairly high.

Below are two plots, the first with a low gain, the second with gain fully maxed out:





Test 2, Wider Spectrum Tests

Well, Test 1 is fine for a 440Hz tone, but we do actually use a wider spread of frequencies when listening to music! My second set of test was a repeat of Test 1, but I used two different sound samples, the first was a pure white noise sample and the second was a sine wave sweep from 10Hz upto 20Khz for 30 seconds. I then re-sampled and analysed the spectrum using audacity. On a perfect system one would expect to see an even spread across the spectrum, but again, I was able to see some drop off from 15Hkz upwards. This was another reason for the weird artifacts I was hearing.

Below the white noise test:


Test 3, checking output gain.

This was a bit more hacky. For this tests I played the original 440Hz tone for varying volume settings and sampled this and measured the observable sample amplitude using audacity. I was expecting to see some kind of linearity, but I soon discovered I was only getting linearity from middle to the top volume settings. This seems to imply that the amplifier on my hardware was not biased correctly. Any hardware experts like to comment? :-)

Anyhow, what I learn was that one can check out the audio characteristics of one's hardware using some very simple kit: a good quality audio connection from the headphone socket to a fairly inexpensive digitiser and audacity. I admit that this is fairly hacky as I've not taken into consideration distortion on the cable and the digitizer, but it does allow me to see that my irritation caused by the distortion is legitimate and not to be blamed on old age :-)

Pulse Audio. Complexity Reigns!

Not sure about you, but I do hear people grumbling about Pulse Audio, generally when they get weird audio sample dropping issues or just things don't seem to work.

The following diagram from Wikipedia allows one to get a better understanding of the complexity of all that audio plumbing between the kernel and application:



(Click on the above image and then click on the SVG to get a full sized diagram).

Hrmm.. so no wonder it can be hard to figure out weird audio issues... :-)