Hi, On Thu, Jul 7, 2011 at 10:51 PM, Joel A Fernandes <agnel.joel at gmail.com> wrote: > 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). Version 0.9.15 is very old :-) A lot of bugs have been fixed since then, and a lot of effort has been expended trying to better support PulseAudio on embedded systems like this one. If in any way possible, see about getting a more recent version (using the latest stable release would be advisable). Of course this may be impractical if your company has already performed some sort of rigorous QA using pulseaudio 0.9.15 and determined that it's suitable for your platform; but from the looks of the problems you're having, I don't think you've come that far yet :-) > > 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) I'm assuming you are running pactl and pacmd as the same user that's running pulseaudio (as a user), correct? In per-user mode, by default only programs that are run as the user who ran the PA daemon can connect. I noticed you added auth_anonymous=1 to the module-native-protocol-unix, but I don't know if that handles the problem of permissions too. Does anyone know if just passing this parameter is sufficient to make the UNIX protocol usable by any user on the system? I thought that system-wide mode is necessary for that functionality, due to limitations of the shared memory architecture or something like that. Of course, you can always run your daemon in per-user mode, but enable module-native-protocol-tcp, and set an ACL to only allow localhost. This would allow any user to establish a TCP/IP connection on the loopback interface for pulseaudio, which is much more flexible (and less prone to configuration errors) than the UNIX socket protocol. Sockets are great for the user who started the daemon, but for other users I personally use module-native-protocol-tcp. There may yet be a way to get sockets working (for the performance and latency benefit they offer), though! But it is noteworthy that the system-wide daemon *never* supports shared memory I/O between the client and server, so by comparison, at least with a per-user daemon you have the opportunity to use shared memory if the permissions work out. If you run the system-wide daemon, you completely give up that opportunity (with no workaround AFAIK, other than to stop using system-wide mode). > - 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! aplay should be able to use pulseaudio if you use the pulse PCM plugin for libasound2. On my system, this plugin is in the file /usr/lib/alsa-lib/libasound_module_pcm_pulse.so and links against libpulse. It's a fairly unremarkable pulse client that adapts the native pulseaudio API to ALSA clients that observe the Safe ALSA Subset[1], and it obeys the rules in /etc/pulse/client.conf for determining which daemon to connect to, whether to auto-start it, etc. If you don't already have this PCM plugin, you can obtain it by recompiling the alsa-plugins package on a system that has the pulseaudio client development headers and libraries installed. If all your ALSA clients observe the Safe ALSA Subset (which in practical terms means that they can play audio through the pulse PCM plugin for libasound without producing an error), then there is no practical reason why you'd need pulseaudio to relinquish the underlying ALSA hardware device. But I agree that module-suspend-on-idle is useful, at least for power savings, if not to allow ALSA applications to directly access an hw device. The problem you're having with module-suspend-on-idle not loading is most strange. Can you post to the list (preferably in an attachment if it's very large) with the output of `pulseaudio -vvvv --daemonize=false` ? We should at least make sure that: 1. The line "load-module module-suspend-on-idle" is in default.pa (if in per-user mode) or system.pa (if in system-wide mode). 2. That PulseAudio is actually using the default.pa file that you think it is, and not some different one. For example, if you compile pulseaudio with ./configure --prefix=/usr, by default it will look for default.pa in /usr/etc/pulse instead of /etc/pulse :-) To get pulseaudio to look in /etc/pulse by default, you have to compile it with "./configure --sysconfdir=/etc" (the other directories and the prefix are not relevant to this particular issue, because specifying an absolute path in sysconfdir overrides the prefix). 3. That PulseAudio can find the module-suspend-on-idle shared library; that PulseAudio process has permission to read the file; that the dynamic linker is able to load it into the address space and dlsym() the plugin interface. 4. If all that succeeds, then maybe there is a bug in module-suspend-on-idle itself, or maybe the module is working 100% fine but you have a pulseaudio client that is writing or reading audio just enough to keep the sink (resp. source) busy? Since you can't run pactl or pacmd (yet :)) I guess you can't tell if there are any active PA clients that might be keeping it busy. The output of your pulseaudio -vvvv should provide us sufficient information to determine where, in this process, the loading of module-suspend-on-idle fails. Hopefully, after you take my advice about the pulse PCM plugin, you won't need to rely on m-suspend-on-idle to relinquish the hardware device for other ALSA apps, but you will still be able to benefit from the power savings that can be gained by allowing the audio ASIC to go into powersaving mode. Oh, one more tip -- you might like to poke /dev/snd/pcm* with the `fuser` program, to see which process(es) have the ALSA hardware device nodes open. If you get "device or resource busy" on a new ALSA-using process, and an existing process has the pcm* device open for your sound chip, that's proof-positive of *why* you're getting that error (namely, that your ASIC doesn't support hardware mixing (or it's out of available channels) and a process is already using the device). You might be able to get the same info from /proc or lsof though, so this may be redundant. It's just the way I do it :-) You said you ran the process with strace, so are you seeing evidence that it's actually trying to open the default.pa file that you think it is? Try: strace -Ff -eopen pulseaudio <args> | grep default.pa Make sure it's opening /etc/pulse/default.pa (if that's the one where you load module-suspend-on-idle) and not some other one :-) If we stick with this, I'm sure we can use system tools and smart diagnosis and troubleshooting to resolve your difficulties with 0.9.15. But because such tremendous work has been ongoing for better supporting pulseaudio on embedded devices, I would recommend that you at least evaluate pulseaudio 0.9.23 (or git master) to see how well it runs for you. HTH, Sean [1]: http://0pointer.de/blog/projects/guide-to-sound-apis.html > > 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. > Further, -vv -log-level pulseaudio options don't seem to generate very > ?interesting debug information that helps. > > 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. > > 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. > > * 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. > > ?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. > > Thanks, > Joel > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss >
