23 jan 2012 kl. 20:48 skrev Jeffrey Barish <jeff_barish@xxxxxxxxxxxxx>: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-reloadupon reconnection?
23 jan 2012 kl. 19:16 skrev Jeffrey Barish <jeff_barish@xxxxxxxxxxxxx>: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:AFAIK PulseAudio can be configured to do this automatically, even when
> 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.
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 commandMaybe ~ points to another user's home directory, or you're using a udev
> line versus restarting it from the script.
event that happens before the USB sound device is registered.
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.shWhen 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 messageCannot connect to server socket err = No such file or directoryCannot connect to server socketjack server is not running or cannot be startedI 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.--
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 BarishWorth 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.--
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!
Alsa-user mailing list
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@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
[ALSA Devel] [Linux Audio Users] [Fedora Users] [Fedora Desktop] [Free Dating Site] [Fedora SELinux] [Big List of Linux Books] [Yosemite News] [Yosemite Photos] [KDE Users] [Fedora Tools]