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
--
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
