[ubuntu-studio-devel] PA in audio production - was: A survey if you don't mind

[Len Ovens]

On Thu, 23 Oct 2014, Ralf Mardorf wrote:

> On Thu, 2014-10-23 at 09:40 -0300, Camilo Flores wrote:
>> Mi notebook has PulseAudio available by default but, via a little
>> script, every time I start jack I redirect the audio from Pulseaudio
>> to JACK.
>
> Is such a script IMO should be available by a default Ubuntu Studio.

Such a script should not be needed since about 2012 oct. Starting Jackdbus 
with qjackctl as it comes with US will have pulse connect to jack with no 
script. The steps that happen are aproximately like this:
  - session starts - so does pulse audio
  - jackdbus starts
  - jackdbus sends a message to pulse audio to release the audio hw
  - jackdbus connects to the HW and starts
  - Pulse audio has a module that detects jackdbus is running
  - Pulse sets jackdbus as sink/source
  - pulse connects it jackdbus I/Os to jack's system i/o channels 1 and 2 
(not always correct)

As my kid says: "Everything is Awesome".

There is a huge amount of distrust for Pulse from years gone by when Pulse 
had many teathing problems. However Pulse has been in constant development 
and has become very solid. There is very good reason Pulse has become the 
standard desktop audio server, it just works. There is nothing else that 
comes close as a desktop audio server. No Pulse is not perfect and it is 
certainly not suited to low latency audio or even lowish latency audio 
with no dropouts. Pulse is quite good at covering up xruns so that they 
are not audible, but for recording or other (semi)pro audio uses, pulse is 
not suitable. That is why we have jack.

I do things different again on any of my systems that have a use for jack. 
Even when these systems are used mostly for desktop or mostly for audio. I 
run jack from the session startup before pulse starts (or I kill PA to 
restart). I start jack at almost as high a latency as I can for desktop 
use and use jack as the audio card for pulse. That is I have all the HW 
turned off in pulse. When set this way, the CPU used by the pulse/jack 
combination is very low... the difference from just running one or the 
other is not easily noticable.

I have a small app in the systray that controls system settings for audio. 
Right now, I have four settings, two desktop settings and two audio 
settings.

  - desktop: This is where my wife's computer sits most of the time. It is 
just like normal desktop except that jack is between pulse and the HW. 
This allows recording of any audio stream from the desktop using a jack 
application. It also means that jack is already running if the user starts 
up an application that needs jack. This means there is only one instance 
of jack running rather than having two. My wife uses you tube and skype 
all the time, she also sings and likes to record the results (she even 
gets paid sometimes for singing). This setup works great for her. Jack 
seems to deal with the USB audio IF better than Pulse does. (she has an 
ART USBDualPre)

  - desktop lowlatency (phone): This is really an audio mode because it's 
purpose is to have low enough latency to use live (radio studio with idjc 
for example) yet still connect to things like Skype. This is very 
flexable, but I have found it requires a reasonably new system as the jack 
and pulse use more cpu as the latency goes down. The pulse-jack bridge 
forces pulse to run at a lower latency and because it does dsp work in the 
middle, it can use twice as much cpu as jack. My i5 at 3.4ghz has no 
problem keeping up though. (my P4 at 2.4G was hopeless) The other reason 
more cpu is needed in this mode is becasue most often it is used in a case 
where a number of encoded streams are being encoded or decoded at the same 
time. Take a radio studio example. First there is a streamer running that 
is encoding the output stream for distribution. The music is stored as 
.ogg or mp3 files, perhaps not at the same sample rate as the stream and 
may have resampling too. There may be three of these streams going at the 
same time as one song is being faded into another and a station jingle 
gets dropped on top of that. Then the operator is using skype in the 
background (or some other voip app) to talk to a guest so he can be setup 
for an interview when the music is finished... that is two more streams 
using dsp. That is a total of 6 encode or decode at the same time in a 
senerio that is common in radio work. Some of those may also need 
resampling to adjust sample rate. The latency needs to be low enough not 
to disturb the anouncer and so that a phone conversation can be carried on 
in a natural manner.

  - mixdown: the pulse-jack bridge gets unloaded for this mode so desktop 
audio is gone. I have found that pulse uses almost no resources when it 
has nothing to do, so I leave it running. I set the latency higher so that 
the DAW has more CPU room for effects, etc. Latency can be higher for this 
use because all the streams are already recorded and any monitoring will 
still be in sync.

  - Live mode: This can be used for recording, but I use it for live audio 
use. As an effects box or sw synth where really low latency is needed. I 
set latency in jack as low as my audio/system can handle,,, less than 1 ms 
sometimes. (my audio IF can run with jack set 48k -p 16 -n 2 and no xruns 
for most low latency uses, most can't)

This setup can work without ever opening qjackctl or controlling jack from 
a command line. Most good jack applications have a patch utility for 
connecting their ports as needed, or patchage or qjackctl can be used for 
this. The first mode leaves all the desktop settings as is, but the other 
three can also set the cpu governor to performance or stop the crom system 
service from running so that scanning for new sw updates does use cpu time 
the audio app would like to have. I understand that Cron runs in a "nice" 
way at very low priority, but a set of large ethernet packets still have 
to be handled in a timely fashion and seems to be able to disturb audio. 
Some machines have really bad wireless drivers that need to be stopped as 
well (like my netbook) I could unload kernel modules at need as well.

This is where I would like to see audio distros go. It gives a great OOTB 
experience and would "just work" in a lot more circumstances. The new user 
would not need jack audio to be explained to them to be able to try out 
all the packaged audio sw. Though to make the best use of it, some 
knowledge is required. The main thing though, is that the user would get 
far enough along without getting discouraged, to be ready to learn to make 
things different. It is like learning two open chords on a guitar can be 
enough to sing a song with it and make the player want to learn more 
instead of trying to learn bar chords right off.

Sorry for the long post.... choosing a default audio setup is not very 
easy. Lots of people have their favourite use/workflow and feel one narrow 
path is what everyone else should use too, but finding a more generic 
workflow that fits many uses and does so well is what we want to do.

--
Len Ovens
www.ovenwerks.net