Phonon's backends to JACK.

[Colin Guthrie]

'Twas brillig, and Mark Constable at 12/06/11 20:55 did gyre and gimble:
> On 2011-06-12 07:35 PM, Colin Guthrie wrote:
>>>> Also, keep in mind that phonon is *not* a sound server. It's a
>>>> library. PA and JACK are the servers, so it's not cascading 3
>>>> sound servers, just 2.
>>>
>>> That's still one too many.
>>
>> Why?
> 
> Why indeed. Why can't Phonon users have the choice of intermixing
> professional grade latency and/or overriding the convenient consumer
> grade library when and if they want to? I just don't understand the
> pushback against a world class low latency audio facility like Jack.

There is no pushback against Jack that I can see. It's a very good
system and I've never said anything bad about it. It's just not a system
that would suit the vast majority of target audience of Phonon. That's
not to say we should not support it, but there are several ways in which
we *can* support it.

IMO it makes much more sense to plug PA into Jack than to plug Phonon
directly into Jack. I'll explain why I think this below.

> Not all linux users are stuck with Ubuntu.

I know. I don't use Ubuntu. I'm not really sure what that statement is
meant to mean :s

>> I can see the principle of avoiding it but I don't like to dismiss
>> things out of hand just because of numbers.
> 
> Are latency and xruns just dismissable "numbers"?

They are numbers. I never used the term "dismissable numbers", so not
sure what you're trying to imply by using that phrase now.

That said, you seem to expect that using PA and connecting it to Jack
will cause larger latency and more xruns? Is this just an assumption or
have you done benchmarks? If so, where did you publish the results?

>> I mean, if you don't like stacking things, you wouldn't use Phonon in
>> the first place! :p
> 
> I have no choice, if I try to remove phonon then my entire KDE desktop
> is also removed. Even PA is irrevocably embedded in my desktop...
> 
> ~ sudo pacman -R libpulse
> checking dependencies...
> error: failed to prepare transaction (could not satisfy dependencies)
> :: fluidsynth: requires libpulse
> :: mplayer: requires libpulse
> :: phonon: requires libpulse
> :: speech-dispatcher: requires libpulse

Of course it is. But compiling support for a given system and running
the system are two completely different things. If you want to remove
support for various systems in individual apps, then you should likely
not use a general purpose distro, but build your own system from scratch
or something similar. It's a bit extreme to expect that you would to be
able to remove libpulse!.

> There seems to be a either/or take on Jack vs Pulse whereas I thought
> the promise of Phonon would mean the inclusion of all backend options,
> including a PA-free low latency near zero xrun Jack option regardless
> of CPU cycles involved... if the end user so chooses.

There is not an either/or take on Jack vs Pulse IMO. We (speaking with
my PulseAudio hat on) collaborate quite closesly to ensure the user can
hand over control of the audio device gracefully to Jack when needed
(via the dbus based device reservation protocol). PA has various modules
to allow it to be connected to jack automatically when Jack is detected.
People have put in specific effort to ensure that PA+Jack works well.
It's likely not perfect, but it's still all designed with the spirit of
collaboration and co-existence in mind.

Now why do I think that it makes sense to connect PA to Jack rather than
Phonon directly?

Well, Jack setups fall (broadly speaking) into two primary categories.

1) Jack runs at login and stays running for ever. The system is not a
consumer system but is purely designed for low latency and doesn't care
about consumer audio. PulseAudio as a daemon would not be recommended in
this setup and is likely disabled (or just set to use a null sink) with
minimal impact (the distro will likely be configured to make apps work
nicely with PA out of the box, but for the pro-audio apps, Jack support
is likely the primary setup anyway.


2) A mixed desktop is run where consumer audio runs but Jack is started
and used when needed. Applications should continue to work during this
transitional period (i.e. before and after Jack is started), but the
user should obviously be able to completely disable consumer
applications (you don't want a new mail notification interrupting while
performing a live set!)


In the former setup, there is not much need for Phonon apps. The system
is pretty much dealing only with apps that have native Jack support.

In the latter setup, Phonon apps are only a subset of "consumer audio
apps". It's far more convenient to have all these applications talk to
PulseAudio when Jack is not running and then allow PulseAudio to deal
with the graceful handover of control of the audio device to Jack when
it's started. The applications do not have to know anything about this
process and thus do not have to support this scenario natively (which I
can say with certainty is something that will never happen). Even if
this setup was supported in Phonon, most consumer apps do not use
Phonon, so the same problems have to be solved over and over again, or
handled by PulseAudio in one central place.

In this setup pretty much every application can then be connected to
Jack easily and Jack can be stopped and started as and when needed.

All in all, this is by far the most user friendly and graceful way to
deal with this scenario.


There are various other reasons too, but I hope I've explained my
thoughts here clearly.


Col


-- 

+------------------------+
|     Colin Guthrie      |
+------------------------+
| http://colin.guthr.ie/ |
+------------------------+