On Mon, Jan 23, 2012 at 1:11 PM, Anders Genell <anders.genell@xxxxxxxxx> wrote:
On Mon, Jan 23, 2012 at 11:28 AM, Anders Genell <anders.genell@xxxxxxxxx> wrote:
Just a blind shot in the dark:
Would it help to have your udev-script call /sbin/alsa -force-reload upon reconnection ?
Regards,
Anders
On Mon, Jan 23, 2012 at 10:36 AM, Jeffrey Barish <jeff_barish@xxxxxxxxxxxxx> wrote:
On Mon, Jan 23, 2012 at 1:17 AM, Clemens Ladisch <cladisch@xxxxxxxxxxxxxx> wrote:
Jeffrey Barish wrote:
> 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.
AFAIK PulseAudio can be configured to do this automatically, even when
a stream is currently being played.
> 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
> [...]
> So, what is different about restarting the daemon from the command
> line versus restarting it from the script.
Maybe ~ points to another user's home directory, or you're using a udev
event that happens before the USB sound device is registered.
Regards,
Clemens
Yes, I am aware that pulseaudio can do what I want automatically. However, it is only recent versions of pulseaudio that have this capability. I am running Ubuntu 10.10. The version of pulseaudio that runs on this platform does not have this capability. I can't upgrade the OS, so I tried, but failed, to make pulseaudio from source. I would rather not introduce another dependency anyway. It seemed as if I could solve the problem using alsa alone, but now I am wondering.
The ~ theory is a good thought. Unfortunately, I misled you. I used ~ as a shorthand when composing the message. The actual code uses a full path. In any case, I know that the correct .asoundrc file is being updated because I see the new contents and because the sound does actually switch when I disconnect the USB DAC.
Your second suggestion is also interesting. I described two changes I made to test that theory. First, I removed the numeric prefix from the name of the rules file so that it runs after all the rules in /lib/udev/rules.d. I figured that allowing all other rules to run first would provide an opportunity for the USB DAC to be registered by the time my script runs. Then, in case I was wrong about the effect of that change, I inserted a 2-second delay before restarting my daemon. I figured that the delay would provide ample time for the registration to take place. Does anyone know these tests to be invalid? When you talk about the USB DAC being "registered", do you mean by udev, or something else? If I do "cat /proc/asound/cards" in my script, I see both cards even when udev runs the script.
Your suggestion did point out another difference. When my script runs under udev, it is owned by root. When I restart the daemon from the command line, I would be me except that I use sudo. To make the two situations as similar as possible, I tried running the udev script itself from the command line using sudo (rather than simply restarting the daemon using sudo):
sudo ACTION="" udev-script.sh
When activated this way, the script runs exactly the same commands that it runs when activated by udev, and the commands in the script all produce the same output (except that the pid of the daemon changes). However, when run by udev the script does not switch the sound to the USB DAC and when run from the command line, it does. I can't think of any difference, though, as in both cases the script runs as root.
Here's something new:
If I set up the system to use the USB DAC -- sound is actually come out the USB DAC -- and then I disconnect the USB DAC while playing, I get the error message
Cannot connect to server socket err = No such file or directory Cannot connect to server socket jack server is not running or cannot be started
I don't know what these messages mean, but I'm wondering: Is it possible that if alsa sees these messages when it first tries to connect the USB DAC under udev, it decides that something is wrong with the USB DAC and refuses to abandon the internal DAC? Maybe by the time I run the script from the command line, whatever it is that causes these error messages to be produced has settled, so alsa proceeds with the switch.
As far as I know, I am not running jack. ps aux | grep jack lists nothing even when sound is coming out the USB DAC. But something seems to think that I should be running jack. Maybe that something is interfering with the switch.
--
Jeffrey Barish
RED HERRING alert. Those error messages are produced whenever play starts, whether playing through the internal or USB DAC. They do not appear when I simply disconnect or connect the USB DAC. I was confused because I happened to be playing before when I disconnected the USB DAC. I'm curious to know why I get these error messages, but I don't think they're related to the current issue. I think they must be coming from GStreamer.
-- Jeffrey Barish Worth a try, 'cause I got nothin'. Alas, it doesn't seem to make a difference, whether I issue the command in the script or from the command line. The only effect I could detect is that the internal DAC disappeared from the system (I got it back when I rebooted).
Thanks, though. -- Jeffrey Barish
------------------------------------------------------------------------------Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developersis 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
Oh well... I have had problems with alsa loosing connection to USB-cards, or intermittently rearranging the device order, and the force-reload trick has worked fairly well.
Just today I was installing the Intel Fortran compiler from rpm:s onto an Ubuntu-system (don't ask...) and had a hell of a struggle getting it running until I googled and found it was due to that recent Ubuntu versions link /bin/dash to /bin/sh, instead of /bin/bash. This caused some error when using flags with the compiler command.
So, I was just wondering if the default shell differs between your account and root?
Regards, Anders
Thanks for making another attempt. You identified a potential difference that I had not considered. However, it turns out that the shells are the same. Moreover, the script specifies the shell in the shebang line (bash), which assures that they are the same.
-- Jeffrey Barish
------------------------------------------------------------------------------Try before you buy = See our experts in action!The most comprehensive online learning library for Microsoft developersis 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
I had a feeling it wouldn't work, but as the ifort script had /bin/sh in the shebang, I thought it might be worth a try.
The only other thing I can think of is group membership. As user you are likely part of the audio group, which allows you to do audio stuff, and if set up properly allows you to run jackd in real-time. Root is of course allowed to do almost anything, but if he/she (what gender is root?) is not explicitly part of the audio group, maybe some behavior is affected?
Regards, Anders |
