Just a blind shot in the dark:
Would it help to have your udev-script call
/sbin/alsa -force-reload
upon reconnection
?
Regards,
Anders
23 jan 2012 kl. 19:16 skrev Jeffrey Barish <jeff_bar...@earthlink.net>:
>
>
> On Mon, Jan 23, 2012 at 10:36 AM, Jeffrey Barish <jeff_bar...@earthlink.net>
> wrote:
>
>
> On Mon, Jan 23, 2012 at 1:17 AM, Clemens Ladisch <cladi...@googlemail.com>
> 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=add 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
>
> ------------------------------------------------------------------------------
> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-user
------------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user
