Linux 2.6.33

Shortly after Linux 2.6.33 was released the respective Gentoo kernel sources became available as well. Curious as I am, I decided to give the new kernel a quick whirl, possibly in the hope that my Pulseaudio<->ALSA problem might be fixed.

I tried this with my PC at work, which is equipped with an old GeForce FX 5200 Nvidia graphics card. To get the kernel with that card going, the legacy Nvidia driver 173.14.25 is required. In the current Gentoo Portage tree unfortunately there is only 173.14.22. That is not too much of a problem however. As a very Quick’n Dirty solution simply copy nvidia-drivers-173.14.22.ebuild to nvidia-drivers-173.14.25.ebuild, execute

ebuild nvidia-drivers-173.14.22.ebuild digest

and then emerge the driver, after you have compiled the 2.6.33 kernel.

The Pulseaudio<->ALSA problem however is not fixed, although it appears to take longer until the problem shows up. What is worse, my previous workaround (compiling the ALSA 1.0.20 driver and install the modules over the kernel modules) does not work any, since the ALSA driver won’t compile with the new kernel, since some include files have been moved in the kernel tree.

So I guess I’ll stay with kernel 2.6.32 for the time being until I receive my new PC in the not to distant future.

Comparing analog and digital radio on the cable.

Out of curiosity I decided to compare the audio quality of a local radio station (1Live), which I can receive in analog and in digital via my local cable operator. The privately owned radios on the cable are encrypted and can only be received with the appropriate CA Module and a SmartCard for the DVB-C card. The publicly funded station are however available unencrypted.

I use these two cards to record the audio from DVB-C (the first) and for the analog broadcast (the second):

05:00.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
    Subsystem: KNC One Device 0022

05:02.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
    Subsystem: Hauppauge computer works Inc. WinTV Series

Comparison Digital & Analog Volume

This first picture compares the volume levels. The above half is from the digital broadcast and the lower half from the analog broadcast, both showing about 1 hour from the same show. Both recordings are normalized to -0.2db of maximum level with Audacity.

As you can see, the analog broadcast has a certain dynamic range left, while the digital broadcast is completely flat. Apparently, the signal, which is used to create the digital stream is passed through a compressor, which reduces the dynamic range to a minimum. Not very nice. Apparently not every station does this compressor thing. Another station from Berlin I’m occasionally listening to in digital has a lot more dynamic range left.


This next picture provides a detailed waveform view. The upper shows a very clean signal from the digital broadcast, as is to be expected. On the lower half the noise is apparent in the analog broadcast, which is overlayed on the normal signal. An analog broadcast simply can’t provide the same absolute maximum dynamic range as a the digital signal can. Another problem probably is, that the old BTTV TV-card doesn’t carry very high quality electronic components, which adds to the level of noise.

Frequency Range

The last picture compares the frequency ranges, which each broadcast type offers. There is nothing much left above 15KHz. In the analog broadcast the peak at 19KHz is stereo pilot signal used to indicate stereo broadcasts. This is not a usable audio signal.

Our local cable operator is trying pretty aggressively to get new customers and are trying to convince the customers of the advantages of digital TV and radio. From the above pictures the digital advantage is not really visible, except maybe for the better signal-noise ratio. Additional problem is the requirement of SmartCards, if you want to listen to private radios. With the digital receiver provided by the cable operator, where you insert the SmartCard, you can either watch TV or listen to radio, not both at the same time. So, the remaining receivers in the house hold need to use the analog signal anyway. Who would spend another 5€ per month for another SmartCard?

Fixes for ACPI wakeup and X11 resolution switch

I wrote here, that since my switch to Linux kernel 2.6.32 the ACPI wakeup didn’t work anymore. After a new search through the internet I came across this article mentioning a conflict with the HPET. As a workaround booting with hpet=disable is suggested.

And indeed with this workaround ACPI wakeup works again. Looking at the output of cat /proc/driver/rtc

rtc_time    : 11:44:20
rtc_date    : 2010-02-17
alrm_time   : 07:21:16
alrm_date   : ****-**-17
alarm_IRQ   : no
alrm_pending    : no
24hr        : yes
periodic_IRQ    : no
update_IRQ  : no
HPET_emulated   : no
DST_enable  : no
periodic_freq   : 1024
batt_status : okay

the HPET_emulated line should report no.

Another fix was released with the xorg-server 1.7.5. Since the switch to xorg-server 1.7 I was basically unable to switch from the X11 display running with 1600×1200 resolution to a virtual console. Switching to a virtual console resulted in a dark display complaining about illegal operating parameters. This was particular annoying, when shutting the system down.

As a workaround with earlier xorg-servers I switched X11 resolution to 1280×1024 with “Ctrl + Alt + Keypad -” and then switched to a virtual console. Now the virtual console was operable.

The fix for xorg-server 1.7 was announced in this email. Unfortunately stupid me didn’t think about the xfce4-display-settings utility (I’m a XFCE4 user), then I would have been able to switch resolutions graphically.