A USB DAC may or may not be connected to my system. When it is connected, sound should come out the USB DAC. When it is not connected, sound should come out the internal DAC.
Jeffrey Barish
The solution that I implemented uses udev to detect when the USB DAC is connected/disconnected. udev runs a script when it detects a change. The script writes ~/.asoundrc with the following:
pcm.!default {
type hw
card $n
}
ctl.!default {
type hw
card $n
}
where n is 0 for the internal DAC and 1 for the USB DAC. I know these names because /proc/asound/cards contains:
0 [PCH ]: HDA-Intel - HDA Intel PCH
HDA Intel PCH at 0xfe700000 irq 48
1 [default ]: USB-Audio - USB Audio CODEC
Burr-Brown from TI USB Audio CODEC at usb-0000:00:1d.0-1.4, full
(when both are connected, and just the first entry when the USB DAC is not connected).
I know that udev is working because the .asoundrc file changes as expected when I connect/disconnect the USB DAC. If I start with sound coming out the USB DAC, the sound output switches from the USB DAC to the internal DAC when I disconnect the USB DAC. However, when I reconnect the USB DAC, sound does not switch back to the USB DAC even though the .asoundrc file changes appropriately. At this point, repeatedly disconnecting/reconnecting the USB DAC has no effect.
Here's surprising observation #1: If after reconnecting the USB DAC I play a sound file manually (using gst-launch playbin2 uri=file:/path/to/file.ogg), sound does come out the USB DAC. In fact, sound will track the connecting/disconnecting of the USB DAC exactly as it should when I execute a play command from the command line.
So, what is different about my application from the command line? Well, you might wonder whether I am restarting my application whenever .asoundrc changes. And you might have wondered even more if you had known that my application is a daemon, so normally it runs continuously in the background while responding to commands from the client. However, I understand that I need to restart my application for the changes to .asoundrc to take effect, so the script activated by udev restarts the daemon. I know that the daemon restarts because the pid changes. I know that the client is talking to the daemon with the new pid because I have the client ask the daemon for its pid and then print out the response. Nevertheless, sound from my application does not come out the USB DAC. Here is surprising observation #2: if at this point I manually restart the daemon from the command line (with exactly the same command that the script executes), sound does switch to the USB DAC.
So, what is different about restarting the daemon from the command line versus restarting it from the script. Maybe udev does other critical things after resetting the daemon (even though my rules file has a name without a numeric prefix to be sure that it runs after the rules in /lib/udev/rules.d). I tried restarting the daemon from a subshell of the script that runs after waiting several seconds. Still no switch. Maybe the script runs the restart from an environment that somehow affects alsa. I tried running the restart command with env -i. Still no switch. Running the restart command from the command line is the second time the restart directive is issued (the first being the one from the script). Maybe the script needs to make the request more than once. I tried issuing the command two or three times from the script. Still no switch. If any of these experiments had succeeded I would have been surprised because the switch from USB DAC to internal DAC works. It's only the switch from disconnected to connected that does not work, and only with my application. From the command line, the switch always works.
I feel infinitesimally close to a working solution, but I can't think of anything else to try. I hope that someone has a suggestion.
-- Jeffrey Barish
------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
