After a lot of trial and error today, I’ve still only gotten part of the way to my objective: making my new Plantronics USB headset get auto-detected in Gentoo, and make it my “primary” ALSA device. That is, when it’s plugged in, all audio goes to it, and when it’s not, all audio goes to the speakers. Much, much easier said than done.
The first hurdle was coming to the realization that ALSA in fact sees this headset as its own sound card. Once I got that far (it took me a while, with some help on IRC), all I needed in the end was 4 additional lines in my /etc/modprobe.d/alsa file:
alias snd-card-0 snd-hda-intel
alias sound-slot-0 snd-hda-intel
options snd-hda-intel index=1
alias snd-card-1 snd-usb-audio
alias sound-slot-1 snd-usb-audio
options snd-usb-audio index=0
The first 2 lines were already there, and then I added the two lines about snd-card-1 and sound-slot-1. Easy enough. The other two lines (not counting the whitespace) are to tell the system what order they go in. 0 is primary, 1 is second, etc. So by having index=0 for snd-usb-audio, that device is my first card, and the on-board is my second. Easy enough. I kept getting fouled up in testing my various configs by not actually removing the modules; I was just restarting ALSA. Not good. Once I got that config working, I wrote a couple of bash scripts to flip those variables, update the configs, etc. Here's my "on" script:
#!/bin/bash
# Script to swtich around audio devices when headset plugged in
if ( grep -q "options snd-usb-audio index=0" /etc/modprobe.d/alsa )
then
echo "Exiting..."
exit 1
fi
sed -i '/options snd-hda-intel/ s/0/1/' /etc/modprobe.d/alsa
sed -i '/options snd-usb-audio/ s/1/0/' /etc/modprobe.d/alsa
update-modules -f
/etc/init.d/alsasound stop
sleep 0.5
modprobe -r snd-usb-audio
modprobe -r snd-hda-intel
/etc/init.d/alsasound start
sleep 0.5
/etc/init.d/mpd start
It's simple enough, in retrospect, and it works. The "off" script is identical except it does the reverse flip at the beginning. I could have made it one script, but whatever.
The next step was to make this all happen automatically. That's where I'm stuck. I've been tinkering with udev for hours now, and I can't seem to write the rules right. My current rules look like this:
ATTRS{id}=="U0x47f0xc001", ACTION=="add", RUN+="/home/dfego/bin/udev-headset-on.sh", ENV{IS_PLANTRON}="yes"
ENV{IS_PLANTRON}=="yes", ACTION=="remove", RUN+="/home/dfego/bin/udev-headset-off.sh"
I don't even remember now if this particular "add" works, but some of the ones I wrote today did. However, not one, not a single one of my "remove" lines worked. All day. None of them. It's almost depressing. For some God-forsaken reason, I can't make anything trigger on a remove event. So I tried using a single script and having it go on all events, but that fell on its face because udev insists on running it lots and lots of times every time an event happens, even when I built protections into the script that it couldn't run more than once simultaneously. So I don't know what to do. For now, I'm just going to be happy with what I've done and use the script. It's not like I plug my headset in and out all that often (except, of course, today). But I feel sad and defeated, and very much like I wasted a ton of time doing something that doesn't work for some reason beyond my comprehension. It should work... it just doesn't.
Maybe I'll try again one of these days. Maybe not.
Share and Enjoy:
These icons link to social bookmarking sites where readers can share and discover new web pages.
Uncategorized
