Hi Colin, Sean, Switching to pulseaudio 0.9.22 fixes all the issues. Thanks! Regards, Joel On Fri, Jul 8, 2011 at 4:51 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote: > '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/] >
