'Twas brillig, and Joel A Fernandes at 08/07/11 03:51 did gyre and gimble: > Hi! > > I will be as descriptive as possible about a certain issue pulseaudio > I have had keeping audio devices "busy" and discuss what I have tried > and what I see. > > I'm using a 2.6.32 kernel (have also used a 2.6.39 kernel) with > PulseAudio 0.9.15 (Angstrom distribution) on a BeagleBoard (tried C5 > and -xM). As per Sean's comment, both the kernel and PA version are pretty old now. I'd advice using newer versions if at all possible. While I can offer general advice, I can't really give code-level support for such an old version of PA. > The problems appear to be two-fold. > - Firstly, the utilities: pactl, pacmd etc are unable to connect to > the pulse server most of the times (so its kind of intermittent) > - Second, aplay cannot use pulseaudio as it throws errors as mentioned > below, and, cannot not-use pulseaudio as it keeps the sound devices > busy :) So we're stuck! > > I have tried running pulseaudio in both system and user modes. > > * When started up as a per-user instance ,which is started up by > start-pulseaudio-x11 like so: > /usr/bin/pulseaudio --start "$@" > > The pulseaudio server daemonizes but not always. Sometimes I have to > delete the .pulse-cookie file and .pulse/ directory to have it > daemonize. Only once it does daemonize, pactl is able to connect to it > and list modules but again audio players can't have it play anything. OK, so something is holding things up at startup. Can you work out what that is? Perhaps running PA manually via "pulseaudio -vvvvv" will give some clues? > Further, -vv -log-level pulseaudio options don't seem to generate very > interesting debug information that helps. Try more v's ;) > strace shows that it opens the sound device and then calls pause() > waiting for events to occur. This causes no one else to be able to > open the sound devices! pulseaudio just keeps it busy though its not > using the devices! suspend-on-idle module doesn't get loaded, though > the default.pa has it set. As a general rule noone else *should* be opening the audio devices. But I'm not sure what you mean by "calls pause()" here. There is no such call in PA source code. If you mean various select() calls to wait for fd devices then this is intended, although I'd have thought that suspend-on-idle should also kick in at some point.... It seems that if default.pa has suspend-on-idle specified but it's not being loaded, then something more sinister is happening. I'd need to see log output from pulseaudio -vvvvv to say more. > I can confirm that the shared library "suspend-on-idle module" is > _not_ being loaded by looking at its process memory map > (/proc/../maps) though the /etc/default.pa file does have the option > enabled! I cannot use pactl to check if the module is loaded because > it doesn't connect to the pulse server (as mentioned above), but > atleast the memory map tells me it isn't. Does your user have a ~/.pulse/default.pa? If so, this file overrides the one on /etc/pulse/ > * In system mode (passing --system) > clients such as pactl are able to connect and list modules etc and the > sound devices are not kept busy. > > However audio players that use pulseaudio (by settings in > /etc/asound.conf), report an error such as "Unable to create stream: > No such entity, Unable to set hw params". The distribution doesn't > have an asound.conf preconfigured so this isn't a problem as such but > I thought I'd mention it anyway. By audio players, do you include paplay? I'd need to see more details commands and logs here (both the output/errors from the command itself and the PA logs when this is run). > So pulseaudio --system doesn't work but atleast it _does not_ keep > sound devices open. So other applications can still use alsa to open > sound devices without going through pulseaudio. > > For reference, I have uploaded my /etc/default.pa and /etc/system.pa > config files to: > http://utdallas.edu/~jaf090020/system.pa > http://utdallas.edu/~jaf090020/default.pa > > I would appreciate any suggestions on what could be a possible cause, > and a viable solution to the problem. As well as the config files, Please also upload the output from running PA (as a normal user with -vvvvv) from the terminal. All I'd say is to follow some basic safety steps when running a per-user daemon: 1. Always run client apps as the same your you run PA daemon as. 2. Always check that other client configurations are not changing where you connect to (e.g. a client.conf, or PULSE_SERVER env var or PULSE_SERVER X11 property on the root window). 3. Debug connection problems with "PULSE_LOG=99 pactl stat" Point 2 in particular is an issue if you are SSH'ing in to this box remotely. If you have X11 forwarding enabled (which is typical) then the X11 properties will be telling your login on the remote box to try and connect back to the machine you SSH'ed in from. ("xprop -root | grep PULSE_" is your friend here) Either disable X11 forwarding or run "pax11publish -r" before SSHing. HTHs Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
