On Mon, Jan 23, 2012 at 11:28 AM, Anders Genell <anders.gen...@gmail.com>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
>
> 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
>
>
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 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
