23 jan 2012 kl. 20:48 skrev Jeffrey Barish <jeff_bar...@earthlink.net>:
>
>
> 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
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
------------------------------------------------------------------------------
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
