I find it useful to install Pulse Audio Volume Control application (pavucontrol) and use that to better tune pulse audio for EACH multimedia application and for EACH audio device.
My experience is that pulse audio gave a lot of users heartburn initially (in previous openSUSE versions) because it was ‘buggy’ from upstream, and in particular it gave me some initial heart burn in openSUSE-11.4 because it was ‘different’ and I was not used to it.
Pulse audio has enabled me to do things with audio in GNU/Linux that I could NOT do before without Pulse audio. Hence I am now becoming a fan of pulse audio.
For example, pulse audio has features for device control that I was not technically able to get working without pulse audio (nor from what I read in our forums were most other users able to get all such features as I list below working).
With pulse audio it is MUCH EASIER for me now to :
have multiple multimedia applications playing audio simultaneous to the same sound card/set of speakers
have multiple multimedia appilcations playing audio selectively to chosen different sound cards/speakers
have multiple multimedia applications recording audio simultaneous from the same Microphone
have multiple multimedia applications recording audio simultaneous from different Microphones
capture ANY audio that is streamed to my computer from the web by having pulse audio redirect the audio to one or more recording applications
have multiple audio streams captured by one recording application
Doing the above without pulse audio was problematic at best, and in most cases I could NOT do most of these functions.
BUT with pulse audio I can. I am finding it very useful where multimedia is a hobby of mine.
why is that a problem ? Since you did NOT state if you ran that with root permissions or as a regular user, you leave me no choice but to speculate.
So, … I speculate you ran that command as a regular user.
Should every user have the permissions to kill pulse ? No! Definitely not. So in that case that makes sence and there is no problem with pulse, but there is a problem with the understanding of pulse. Thats based on my speculation which the lack of information forced me to do (speculate).
I was playing with parameters and I was noticing that all were failing. I have found that my problem is that my home is a ntfs partition
thus I should make a new thread to see if I can convert my ntfs to ext4 partition (After backing up etc)
Glad to read you sorted that ! Good luck in setting your /home. It should not be too difficult, although you may wish to backup all data and then create a new ext4 mount point for a /home and then create a new user for your user.
I confess I would never have guessed that a user would use NTFS for /home. That’s a ‘new one’ on me. … Best wishes in sorting this.
That wiki doc/guide to PulseAudio looks somewhat out of date. It mentions some packages (out of date UI tools) obsoleted as documented on the PulseAudio website.
You don’t mention your version of openSUSE, and that wiki document shows it was last tested on 11.3 but not yet on 11.4’s version of PulseAudio.
Yes it should have permissions to do it. It’s recommended to run PulseAudio daemon per-user (i.e. not as a system-wide instance shared by multiple users), so I assume openSUSE is running a PulseAudio daemon per “regular user”. Therefore a normal user can kill (-k | --kill) its running PulseAudio daemon, and then start (–start) the daemon, among other “pulseaudio” command options, without root permissions.
It is true that this guide is for 11.3 . I am running the latest version of opensuse. The idea of having ntfs partition as home is based on my hypothesis that I wanted to have a pure dual-boot system by having a same accessible My Documents and /home partition.
Using NTFS as a home is a very bad idea. NTFS does not have the same permission system as Linux file system and this makes things not work right. In one word DON’T. You can have a shared partition for documents and such but even that can be a problem. It is best to work on Windows files in Windows and Linux files in Linux and move/copy them to the shared area.
That’s interesting to learn! (and new to me). Its a philosophical departure from the system wide alsa API that (in addition to the underlying alsa) also ‘does’ require system permissions to restart. If pulse audio is run ‘per user’ then presumably it needs to be started each time a user logs on, and shut down each time a user logs out.
I’m wondering under what circumstances would a user want to kill pulse ? (as opposed to simply disabling pulse). I have not encountered such a need yet (to kill pulse).
My difficulties with pulse in openSUSE-11.4 were more with the initial setup with a new user, and once setup pulse has been working well for the ‘users’. As I noted above, I found pulse audio provided application(s) to audio device(s) control, and audio device(s) to application(s) control that I did not have before with the basic alsa and its API. One functionality result being application/desktop audio recording possibilities I did not have before.
My wife handles this by having a separate (from the C: drive in Windows) NTFS partition (with label ‘data’) known as the D: drive in MS-Windows, and has this separate NTFS partition mounted as /home/mywife/data in my wife’s GNU/Linux. She puts all her data on the D: when running MS-Windows and puts all her data on /home/mywife/data when running GNU/Linux. She treats her /home/mywife directory (which is EXT4) almost like a user’s private root area and stores no data there. All her GNU/Linux data goes on the NTFS /home/mywife/data.
That is not a very wise thing to do. Native Linux file systems support the Linux way of having directories/files. With owners, groups and access bits and the like. These are not available in non Linux, escpecialy MS-DOS file systems. As you know there is a possibility to access these non-Linux file systems from Linux, but that inteface must emulate/mimic the missing features. You can imagine that the whole security based on wnership and access bits can not function as designed. And more inconsistancies will be there. Thus use these NTFS/VFAT interfaces only where they are for, exchanging data with Windows based systems, but never as an integral part of your Linux system.
Changing to ext4 is not much of a problem. Whith no normal user loged in to be sure /home is noot used, back up the whole of /home. Unmount /home. Use YaST > System > Partitioner to create an ext4 fs on the partition (no need to change other parameters). YaST will mount the new fs (or else you mount it). Copy back.
Yes, the user doesn’t normally need to do start/shutdown, but apparently (IIRC) there can be a circumstance when pulseaudio startup could fail so manual *pulseaudio --start * can be attempted.
I can’t recall the detail of when I only needed to kill and restart pulsaudio a couple of times. It was a fairly familiar scenario where an [audio] application fails and even after closure (forced or otherwise) it leaves the underlying service or server in an unresponsive state. In the situation involving pulseaudio, I lost sound and even though the application had gone, KMix still displayed the application stream, and newly started audio applications produced no sound. KDE and other applications carried on normally, so killing and restarting pulseaudio cleared the problem and avoided a logout/in or a system restart.
Apart from that, I’ve only had problems with PulseAudio when trying unsuccessfully to run Jack at the same time. That requires either a separate sound card for Jack or pulseaudio to be suspended while Jack is running. Suspension of pulseaudio can be configured in Jack, but when I last tried it didn’t work owing to a known bug with pulseaudio’s “pasuspender” facility.
Ignoring those examples, PulseAudio has worked extremely well for me on 11.4 KDE (standard or Tumbleweed) and standard Gnome systems. I haven’t explored audio recording to the extent you have, but I have noted your interesting discoveries and bookmarked your thread on that for setting it up here when time allows.