Generally PEOPLE don't install PulseAudio, rather it is installed by default as an integral part to most Linux distributions these days and there is no option not to have it installed and you can not even remove it! So why have a bitch about something which isn't a user choice and I know full well you are aware of that fact!

Last time I looked into removing PulseAudio from a Ubuntu Studio was a 12.04 installation (and I'm not currently running 14.04 but highly doubt that much has changed) it wanted to remove the entire DE and about 20 other bits of software on apt-get uninstall! I have never seen Ubuntu just say it will remove PA and nothing else from that command in my personal experience. Hence why I went the route of removing the executable flag from the file it opens instead, when I wanted to have it not used in my system. Removing it would break too many other things! (Trust me I tried!) Plus a lot of desktop applications in Ubuntu are only compiled to work with PA so you will find you can't get sound out of some software, which may be fine if only using for studio use but if using for desktop use as well is not! If this wasn't the case why does a quick google search bring up dozens and dozens and dozens of results of people having issues after removing PA from Ubuntu and pages offering suggestions of how to do it in a tidy manner which doesn't cause issues? You know you are skirting the truth of the matter at best! Yes there are ways around it, but just blindly removing it will likely cause you a lot more problems that it will solve with the majority of distributions out there (everything Debian based, down through Ubuntu and Mint (which covers the largest number of users in the Ubuntu world) plus the likes of Fedora as well and likely others too.) And that doesn't change the fact that it is not the user who installs it but the OS by default as the default driver to use and often the only driver subsequent programs are packaged for unless you build them yourself, so it doesn't change the fact you are throwing offensive accusations at people yet again for no reason at all which I am positive you know aren't true! Regards, Dale.

On Fri, 9 Oct 2015, Len Ovens wrote: Just as a side note, there is one jack use where you really want PA not to be connected and that is when using jack in freewheel mode. This may seem counter intuitive as no sound is produced. Freewheel mode is used for audio export as it provides no xruns and normally means a faster export too. This is not only true of pulseaudio, but also any other method of desktop audio to jack. (I think I will watch the youtube video while I wait for this export to finish is just a bad idea) In many ways having a separate machine for desktop use is a better way to go, but there are some uses like radio, where mingling desktop audio with jack (ie, doing an interview over skype) is part of the package. Bridging Pulse to Jack is one of the best working methods for this. For just using a normal phone number, Astrisk has a jack driver and that could be used with zita-j2n and zita-n2j to get sound from the astrisk server to the studio machine. I figure if you are setting astrisk up it would end up being the phone system for the whole operation and deserve it's own machine. -- Len Ovens www.ovenwerks.net

Hi list people, all is in subject, anyway let me ask again; What happens (or not) if one use the active d-bus interface option in QjackCtl ? Maybe, with a good luck, someone in the list will invest some time to explain,or point to a link that explains, all those options in QjackCtl that most of us leaves alone since years,just because doesn't know what is all about, or pass hours to test??? Thanks & sorry for bad english taste

On Sat, 10 Oct 2015, fred wrote: dbus options with jack are to do with jack2. There is a patch to allow jack1 to be dbus controllable as well, but I don't know that any distos ship it and Qjackctl is not designed for it. jackdbus is the same jackd with the ability to use dbus to control it's operation. The advantage of this is that more than one program can interact with jackdbus. With jackd, only the program that starts it can stop it and the parameters can only be set at start time (with the exception of buffers which can be changed during run). With jackdbus, all parameters can be changed including audio device during runtime and can be changed by any program that can find the same dbus server (anything started since session startup). This means Qjackctl can be used to start jackdbus and then jack_control can be used to stop or maodify parameters. I think what stops people from making more use of jackdbus is that all the documentation and help for jack is with jackd command lines. So the new comer will be flooded with advice that shows how to use jackd and not jackdbus. To start jackd with default parameters (whatever was used last time) on the command line: jackd or: jackd & to start jackdbus: jack_control start To stop jackd the controlling terminal can use control c or if it was started with the & then you have to: killall -9 jackd With jackdbus: jack_control stop A typical jackd start line with parameters would be: /usr/bin/jackd -p1024 -dalsa -dhw:M66 -r48000 -p1024 -n2 The same thing in jackdbus might be: jack_control ds alsa dps device hw:M66 dps rate 48000 dps period 1024 \ dps nperiods 2 start or (if it is easier in a script): jack_control ds alsa jack_control dps device hw:M66 jack_control dps rate 48000 jack_control dps period 1024 jack_control dps nperiods 2 jack_control start Now to change the device without stopping jackdbus: jack_control dps device hw:AudioPCI sm An interesting side note: I have the AudioPCI installed only so I can use its MIDI port. The MIDI port is available no matter which device is set with jackd/bus. I use a2j_control to bridge alsa MIDI to jack MIDI (a2j_control ehw start). Documentation: Very little. man jack_control gives nothing, but jack_control on it's own with give a usage message (or jack_control help). I went through using the "get" commands to find out more. Jack_control is written in python and so: less /usr/bin/jack_control will allow one to see what dbus commands jack_control is sending to dbus to control jackdbus. Qjackctl does not at this time (maybe never) allow changing the jack server parameters on the fly. However, a jackdbus server started with qjackctl can be changed from command line with jack_control. Jackdbus works much more smoothly and automatically with Pulseaudio and the pulse-jack bridge. Pulse can be bridged to jackd (1 or 2) manually as well, but it requires an extra script to be run each time jackd is started. Depending which version of qjackctl you have (mine is older), it sets port-max lower (1024) than default (2048) and can not be set higher. Most desktops have no reason to run any lower than default. Embedded systems with limited memory might need something smaller... but probably also won't run qjackctl :) I know this is much more than the qjackctl side of jackdbus, but it does give some of the why too. -- Len Ovens www.ovenwerks.net

Many thanks for taking the time to write this very clear explaination Len :)Maybe you have a site/blog/else where you share your knowledge? De : Len Ovens <len(a)ovenwerks.net> À : fred <f.rech(a)yahoo.fr> Cc : "linux-audio-user(a)lists.linuxaudio.org" <linux-audio-user(a)lists.linuxaudio.org> Envoyé le : Samedi 10 octobre 2015 16h19 Objet : Re: [LAU] What happens (or not) if one use the active d-bus interface option in QjackCtl ? On Sat, 10 Oct 2015, fred wrote: dbus options with jack are to do with jack2. There is a patch to allow jack1 to be dbus controllable as well, but I don't know that any distos ship it and Qjackctl is not designed for it. jackdbus is the same jackd with the ability to use dbus to control it's operation. The advantage of this is that more than one program can interact with jackdbus. With jackd, only the program that starts it can stop it and the parameters can only be set at start time (with the exception of buffers which can be changed during run). With jackdbus, all parameters can be changed including audio device during runtime and can be changed by any program that can find the same dbus server (anything started since session startup). This means Qjackctl can be used to start jackdbus and then jack_control can be used to stop or maodify parameters. I think what stops people from making more use of jackdbus is that all the documentation and help for jack is with jackd command lines. So the new comer will be flooded with advice that shows how to use jackd and not jackdbus. To start jackd with default parameters (whatever was used last time) on the command line: jackd or: jackd & to start jackdbus: jack_control start To stop jackd the controlling terminal can use control c or if it was started with the & then you have to: killall -9 jackd With jackdbus: jack_control stop A typical jackd start line with parameters would be: /usr/bin/jackd -p1024 -dalsa -dhw:M66 -r48000 -p1024 -n2 The same thing in jackdbus might be: jack_control ds alsa dps device hw:M66 dps rate 48000 dps period 1024 \         dps nperiods 2 start or (if it is easier in a script): jack_control ds alsa jack_control dps device hw:M66 jack_control dps rate 48000 jack_control dps period 1024 jack_control dps nperiods 2 jack_control start Now to change the device without stopping jackdbus: jack_control dps device hw:AudioPCI  sm An interesting side note: I have the AudioPCI installed only so I can use its MIDI port. The MIDI port is available no matter which device is set with jackd/bus. I use a2j_control to bridge alsa MIDI to jack MIDI (a2j_control ehw start). Documentation: Very little. man jack_control gives nothing, but jack_control on it's own with give a usage message (or jack_control help). I went through using the "get" commands to find out more. Jack_control is written in python and so: less /usr/bin/jack_control will allow one to see what dbus commands jack_control is sending to dbus to control jackdbus. Qjackctl does not at this time (maybe never) allow changing the jack server parameters on the fly. However, a jackdbus server started with qjackctl can be changed from command line with jack_control. Jackdbus works much more smoothly and automatically with Pulseaudio and the pulse-jack bridge. Pulse can be bridged to jackd (1 or 2) manually as well, but it requires an extra script to be run each time jackd is started. Depending which version of qjackctl you have (mine is older), it sets port-max lower (1024) than default (2048) and can not be set higher. Most desktops have no reason to run any lower than default. Embedded systems with limited memory might need something smaller... but probably also won't run qjackctl :) I know this is much more than the qjackctl side of jackdbus, but it does give some of the why too. -- Len Ovens www.ovenwerks.net

I'm always weary about jumping into Pulseaudio (and systemd...) debates as they always seem to fuel feuds... so I I thought I'd change the subject line and uninterested people can skip.. On 10/10/2015 01:39, Ralf Mardorf wrote: In my humble opinion, it's actually right and adheres to a principle of using a more advanced sound server for more advanced audio/music scenarios (and software) and a 'deskop-oriented' server for desktop scenarios. As with all solution the ideal is when different pieces of technology dealing with similar content/media/things (in this case audio) are able to interact / live together. In my case my audio machine has always also been my 'desktop' machine - just because - and jack / pulseaudio interaction has never been a big issue. The issues I have (had) with pulsaudio are always related to its interaction with 'legacy' alsa-only applications (e.g. the xfce mixer). My point of view is that Pulseaudio has actually made linux audio (in a broad meaning) more easy, more usable and more configurable than e.g. on windows (the control you get with pavcontrol is magnitudes higher and more intuitive than a windows 'mixer'). I see jack as the more advanced linux audio layer which most users can easily ignore. For me it's like extreme gamer-oriened graphics (hardware and software)... I can't really be botherd as long as I can use gimp, inkscape, pingus, and watch a video smoothly I'm happy with my graphics :-) The jack paradigm (connect any audio application to any other audio application) is really powerful (and personally one of the reasons which drew me to Linux). Yet it is just a bit more complicated to set-up, especially for users coming from other operating systems, but I wouldn't blame pulseaudio for that - actually there's no one to 'blame'... Lorenzo.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10.10.2015 01:39, Ralf Mardorf wrote: Hey, I just want to chime in with my opinion: The combination of jack2 and pulseaudio is friggin awesome. It's the best thing since sliced bread. Pulseaudio giving me the quite well working ALSA emulation device which works with all ALSA applications I need. It gives me sweet things like being able to control per application volume, pretty good (good enough and way better than the pure ALSA experience ever was - and yes, I have fiddled for ages with ALSA PCM plugins) software mixing, etc.. It's true that PA used to suck hard, but it has become sooo much better. I just start both at session start. PA and jack2 and have the pa-jack-sink and source installed. Best of both worlds. They don't fight each other too much. The only grief I would mention is that pulseaudio could use a policy for when the jack server is running and has asked PA to give up the sound device: In that case it should automatically switch running applications and the default to the jack sink/source, otherwise apps might block, due to this still annoying and longstanding ALSA behaviour of blocking applications when the sound device is busy). But I guess this would not be too much work to implement as PA nicely separates policy from other implementation details - maybe it even is already implemented and just hasn't trickled downstream yet - or I haven't read enough docs yet. They do not fight each other but work side by side quite well and it's a great achievement by the two communities to cooperate that well. There's still some rough spots, true, but complaining here about it won't fix anything. There's PA mailing lists and IRC channels. PAVUControl is an awesome application. I haven't used a DE mixer in ages, cause they all suck ;) Controlling per app volume, switching output and input devices on the fly, what's there not to love? I don't know what people complain about. Disabling PA is possible also in many ways short of disabling the executable flag. Have fun, be positive and regards, Flo

On 10/12/2015 06:37 AM, Ralf Mardorf wrote: I've had problems using JACK and pulseaudio with my ICE1712 device. Instead of trying to remove pulseaudio, I used the simple solution: sudo chmod 644 /usr/bin/pulseaudio That way it won't start. I have 5 other Linux systems that have simple, on-board audio and pulse works great for those but, with the ST Audio DSP2000 C-Port, it would give me problems starting JACK. It wasn't worth the effort of trying to figure out how to get the two to work together nicely. I also don't have any problems with audio on this system when I'm not running JACK. Cheers, Jan

On Mon, Oct 12, 2015 at 11:21 PM, david <gnome(a)hawaii.rr.com> wrote: it isn't a mystery at all. Clients can't change the SR of JACK as part of their normal connection process, so unless coded to explicitly change the SR (which is generally a big no-no), audacious discovers JACK @ 48kHz, notes the SR of the audio file as something else, remembers that it cannot resample, and gives up. When used without JACK (or Pulse), audacious opens the ALSA device directly and sets the SR to the SR of the audio file as part of that process.

On 09/10/2015 23:46, Len Ovens wrote: +1

On Fri, Oct 09, 2015 at 10:47:15AM +0000, Kaza Kore wrote: Not true! I could *easily* remove pulseadio from my system using apt, no trickery required, honest. -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X

On 10/10/15 03:53, worik wrote: Setup > Misc > Enable D-Bus Interface. On my system if this is checked pulseaudio input and output sinks are created automatically. Lorenzo.

On 09/10/15 21:47, Guido Aulisi wrote: So JACK does not write logs under /var/logs? Worik -- Why is the legal status of chardonnay different to that of cannabis? root(a)worik.org 021-1680650, (03) 4821804 Aotearoa (New Zealand) I voted for love

On Fri, Oct 9, 2015 at 9:54 PM, worik <root(a)worik.org> wrote: JACK does not write logs. End of story.