As a continuation of my previously posted Sennheiser GSX 1000 setup this is the followup which comes from a better understanding of pulseaudio and the device itself. First of all, the GSX 1000 exports three hardware devices. hw:1,0 and hw:1,1 as outputs as well as hw:1,0 as a microphone input. Regarding the outputs, hw:1,0 is actually the mono chat output that is mixed into the main 7.1 channel output by the GSX 1000. The offset from the main volume can be controlled with the small knob on the right side of the device. This makes it especially interesting for use with voice applications like mumble or teamspeak. Your friends are too loud or too low? Twist the knob and adjust on the fly. hw:1,1 is the main 7.1 channel output which - at the moment - does not get detected by pulseaudio as a 7.1 channel device which is why I wrote about the workaround in the previous post.

This new and updated solution should ease usability and possibly make this a copy and paste effort not depending on your system config. This new approach leverages udev in order to catch you plugging in your device and a special udev rule then sets an environmental variable to tell pulseaudio to use a different configuration file for the card. Also it sets a unique id so it is easier to reference the card in case you have more than one soundcard connected.

First of all you need to create a file 91-pulseaudio-gsx1000.rules in the directory /lib/udev/rules.d/ or wherever your udev stores its rules. In this file you put the following:

SUBSYSTEM!="sound", GOTO="pulseaudio_end"
ACTION!="change", GOTO="pulseaudio_end"
KERNEL!="card*", GOTO="pulseaudio_end"

ATTRS{idVendor}=="1395", ATTRS{idProduct}=="005e", ENV{PULSE_PROFILE_SET}="sennheiser-gsx-1000.conf", ATTR{id}="GSX1000"


LABEL="pulseaudio_end"

1395 is the id for the vendor Sennheiser and 005e is the GSX 1000. After that we set the environment variable for pulseaudio and the id attribute of the soundcard. Now you need to create a second (and last, I promise!) file name sennheiser-gsx-1000.conf in your pulseaudio profile sets directory. For me this goes into /usr/share/pulseaudio/alsa-mixer/profile-sets/sennheiser-gsx-1000.conf:
[General]
auto-profiles = no

[Mapping analog-output-surround71]
description = main output
device-strings = hw:CARD=GSX1000,DEV=1
#device-strings = hw:%f,1
channel-map = front-left,front-right,rear-left,rear-right,front-center,lfe,side-left,side-right
paths-output = analog-output analog-output-lineout analog-output-speaker
priority = 2

[Mapping analog-output-chat]
description = chat output
device-strings = hw:CARD=GSX1000,DEV=0
#device-strings = hw:%f,0
channel-map = mono
paths-output = analog-output-headphones analog-output-headphones-2 analog-output-mono
priority = 1


[Mapping analog-input]
description = microphone input
device-strings = hw:CARD=GSX1000,DEV=0
#device-strings = hw:%f,0
channel-map = mono
paths-input = analog-input-front-mic analog-input-rear-mic analog-input-internal-mic analog-input-dock-mic analog-input analog-input-mic analog-input-linein analog-input-aux analog-input-video analog-input-tvtuner analog-input-fm analog-input-mic-line analog-input-headset-mic
priority = 2

# Combined output profile
[Profile output:analog-output-surround71+output:analog-output-chat+input:analog-input]
description = 7.1 Surround
output-mappings = analog-output-surround71 analog-output-chat
input-mappings = analog-input
priority = 88
skip-probe = yes

Now, all that is left is to reload udev, trigger the new ruleset and restart pulseaudio.

$> sudo udevadm control -R
$> sudo udevadm trigger
$> pulseaudio -k

After a couple of seconds pulseaudio should have restarted and you should have a nice and functional GSX 1000. Now, if someone has found a way to get software volume control working and how to keep the GSX from going Volume-Down all the time please tell me. :) Until then the temporary workaround for that problem remains unchanged and you can find it in the old article.

After a bit of a hiatus due to a new job engagement I am hopefully back on a more regular basis. For today with some instructions on getting a Sennheiser GSX1000 audio amplifier to run under Linux. This device is a 7.1 channel surround headphone amplifier with a lot of integrated extra functionality and a nice volume wheel. It connects via USB and there are a few steps to get it working correctly with pulseaudio. It does work right after plugging it in but only in mono mode which is not exactly what I bought this for. ;)

First of all let us get the ids of the sound card playback devices (sinks) via

$> aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 9: HDMI 3 [HDMI 3]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Audio [GSX 1000 Main Audio], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 1: Audio [GSX 1000 Main Audio], device 1: USB Audio [USB Audio #1]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

In my case, card 0 defaults to the HDMI output of my NVidia GPU, let us ignore those entries. Card 1 however is the Sennheiser GSX 1000. I am actually not 100% sure on why it is listed twice with the same subdevices. From trial and error I managed to find out that the subdevice 1 is the correct one to drive the unit. From this information we know that the hardware address of the card for playpack (sink) is 1,1 (card 1 subdevice 1). Next we have to find out the recording device (source).

$> arecord -l
**** List of CAPTURE Hardware Devices ****
card 1: Audio [GSX 1000 Main Audio], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

Our recording device (source) is at the hardware address 1,0 (card 1 subdevice 0 - as there is only one anyway). With this information we can tell pulseaudio how to correctly talk to our audio amplifier. Edit /etc/pulse/default.pa and under Load audio drivers statically we add

load-module module-alsa-sink device=hw:1,1 channels=8
load-module module-alsa-source device=hw:1,0

The first line tells pulseaudio that the playback device (sink) is located at hardware address 1,1 and has 8 (7+1) channels. The second line defines our recording device (source) as hardware address 1,0. At this point you can either restart your pulseaudio with pulseaudio -k or opt for a reboot if you still have not shaken your Windows heritage. ;) Voilla, it works!

The only problem left for me was that the turning of the volume ring gets detected by the kernel as volume down no matter the direction you turn the know. As such I went into the keyboard shortcut settings and disabled the multimedia hotkeys for volume up and volume down. I don’t mind losing that functionality as I want to set the master volume via the GSX1000 wheel anyway. After this small fix I can just use the hardware functionality of the volume wheel as supposed to and that leaves me one happy Alex ^^.

Update: I have found a more elegant way to handle this device. Check out the followup!

Microsoft has decided to pull the latest update for Windwos 10. The statement reads

We have paused the rollout of the Windows 10 October 2018 Update for all users as we investigate isolated reports of users missing some files after updating.

There are, of course, numerous reports of international companies with dominance over the OS market to pull updates just because of a few isolated reports from some users. ^^

In reality, there were serious issues like incompatibilities with Intel Display Audio device drivers, the task manager not reporting the correct CPU usage (maybe a conspiracy with Intel for their meltdown patches? ^^), and

*drumroll*

Deletion of user files located in C:\Users\[username]\Documents\.

A user reported losing 220 GB worth of personal files. You can find many more reports in the same thread. Whohooow! Go Microsoft!

In the latest version of Chrome, you are automatically logged into the cloud portion of your chrome browser whenever you log into any Google website. Matthew Green has written a detailed blog post (see link above) outlining the resulting privacy concerns.

I do differ from him in one crucial bit though. In the end he states that he rejects the argument that goes along the lines of “Captain Obvious strikes again, it’s Google, something like this was bound to happen.”. He said he believes that for 10 years Google managed to provide good open source software without massively violating user privacy and there was no way to see this coming. Seriously? I mean, come on! All the location snooping with Android? Even though the settings were turned off? The preset synchronization options? Forcing G-Apps onto everyone? Google has been on a privacy violating spree for a long time already. One of the main reasons I have never used Chrome. Something like this was bound to happen! They are an ad company. They can make more money if their ads are even more personalized and can be targeted even better. In a world where shareholder value has the last say and is regarded as the ultimate decision maker, of course companies like Google will fuck with your privacy if it means more revenue. This is so blatantly obvious that “I did not see it coming.” is no valid defense.

There is a new attack out there that allows you to reboot iOS or freeze macOS simply by visiting a webpage containing HTML and CSS. It does not need Javascript to be enabled so it also works while viewing HTML E-Mail (which you should never do anyway but tell that to the hipsters).

The following excerpt is especially exciting

Haddouche has told BleepingComputer that he has created an additional attack using HTML, CSS, and JavaScript that will totally freeze macOS computers. He has not released it as it persists after reboot and macOS will relaunch Safari with the malicious page as well, making the computer freeze again.

After Apple’s botched last year in regards to miserable security and ridiculous vulnerabilities one would assume they had gotten off their asses and shifted resources to fixing their swiss cheese of an operating system. But then again, pumping out new iPhones seems to be more important. Got to please the hipsters. I actually find it very much interesting how Apple and their operating systems went from “expensive but secure” to “expensive and utter garbage with more holes than a swiss cheese” over the recent three or so years. It is a perfect example what happens if you prioritize new products (quantity) over fixing your shit and delivering a well developed product (quality).

In a shady move, Intel has added some small print to the latest license agreement on its updated CPU microcode. After the last debacle with microcode patches designed to mitigate Spectre and Meltdown vulnerabilities, which - depending on your use case - led to severe drops in performance, Intel is now trying to keep you from publishing benchmarks. The new license post-update contains the following lines:

You will not, and will not allow any third party to
*Snip*
(v) publish or provide any Software benchmark or comparison test results.

You can read this as “And if our firmware patches fuck up your CPU performance even more then you are not allowed to talk about it while we still claim in advertisements that our CPUs are blazingly fast.”

Luckily, Debian GNU/Linux is not having it and has decided not to publish microcode updates till the license issue is taken care of. Here is the corresponding bug tracker entry where new updates to the issue might also appear. One thing to take away from this is that apparently Intel wants to be able to tell you what kind of things you are allowed to use your CPU for. Luckily, with the recently launched Ryzen 2 lineup and the new Threadripper 2 CPUs that are due for release this month, AMD is already a great alternative, even for gaming. In light of Intels license fuckups this decision has just been made even simpler.

Update: Intel is now backpedaling and changing its license once again. The Streisand effect got to them first though and now the news is out. Having to disable hyperthreading in order for the fix to work is bound to have a huge performance impact and Intels foolish try to suppress their customers certainly did not help their credibility. Once again: AMD Threadripper, here I come :)

BMW E60 Defective Trunk Repair

Wed, Aug 15, 2018

A bit of an unusual topic for this blog but maybe this will save someone a lot of time, headaches and quite possibly money. My VFL 2003 BMW 5-series (E60) came down with some trunk lid troubles the other day. The trunk lid would not open either by remote or by pressing the button above the license plate. When opened with the key, it would not close anymore. The locking mechanism just would not engage and the lid would flip back open.

After messing with the lid for a while it suddenly locked again and so I left it like this for a few days pondering what to do. After all, leaving the car standing around with an open trunk lid was not exactly what I had in mind. A friend of mine came up with the idea of a wire defect, quite possibly in the connection from the trunk lid to the car body, due to the constant bending over the years when opening and closing the lid.

The E60 does not have a purely mechanical trunk lock anymore, instead it is actuated by servo motors when receiving an electronic signal. Armed with some tools, a soldering iron, some shrink tube and the hope that it actually is a broken wire and not something really expensive, like a defective servo, I went to work.

BMW E60 Repair Image

As you can see in the picture above it was not just one broken wire but two and several others were pretty much on the brink of failure. On the plus side, the repair took about half an hour and I only used some pliers, a screwdriver, wirecutters, a soldering iron, some shrink tube, electrically insulating tape, and some wire clips.

The wire harness for the trunk lid electronics and the opening mechanism runs behind the trunk lid cover to the passenger (right) side of the car and through a connecting tube which is attached to a hinge in the trunk. The harness is held inside the tube by a rubber plug with a slit in it which can be pulled out. Then it is just a matter of unravelling the mess of sticky tape (why is this tape always exactly as sticky on the outside as it is on the inside?) and inspecting the wires at the bending point.

A new wire harness would have set me back several hundred EUR and since the wires from the trunk are woven into the main harness of the car this would have been a nasty thing to replace. I am sure a garage would take another couple hundred EUR from you just for the time this would take. Appart from 30 minutes of my time this repair did not cost me anything. If you count the repair parts that I used, maybe 2 EUR. ^^

Lenovo Joins LVFS

Tue, Aug 7, 2018

Great news for a change! Lenovo has joined the Linux Vendor Firmware Service (LVFS). But wait, I hear you say, why should I care? Well, the LVFS is what makes firmware upgrades possible natively under Linux. In a nutshell this means in the not so distant future, it will be possible to update the UEFI bios of your Lenovo laptop natively via your local Linux installation. Awesomesauce!

Lenovo has been my goto laptop brand for years now. There are two main reasons for this:

  1. The hardware used in Lenovo laptops usually is well-supported by Linux. And why would you burden a nice piece of hardware with spyware crap like Windows?
  2. Lenovo publishes hardware maintenance manuals for their devices where you can read up on how to disassemble your laptop without breaking stuff to repair certain components yourself. Especially handy once you are out of warranty.

So now my favourite hardware manufacturer and my favourite OS move even closer together. This translates to very cool beans!

1
2
3
4
5
6