25 Mar
2019
25 Mar
'19
10:32 p.m.
On 2019-03-23 16:28, John Rigg wrote:
It appears to me that you've been having problems
with Pulseadudio,
but you insist on saying it's jack's fault. My advice: get rid of
pulseaudio, which has no business being on a serious recording
system at all IMO.
Completely purged pulseaudio from my system. Reinstalled jack. Made sure
only jack and alsa is installed
jack still wont start - go figure.
I guess now it will be alsa's fault since pulseaudio is not around
anymore -- just following the logic.
< I've used jack since 2005 in my work as an audio engineer,
and it allows me to do things that my Windows- and
Mac-using colleagues
are unable to do due to the arbitrary restrictions built in to so much
proprietary software. There's no way I'd go back to those systems even
though I could easily afford to.
I totally agree with you.
Jack is indispensable.
Since you get it running with such impunity, why dont you write it up in
a document from scratch how you get it up reliably and help us all
understand what is needed.
I for one will REALLY appreciate it.
I have to admit I'm a little puzzled here. Surely
the source code is
the obvious documentation to use for an experienced programmer is it
not? Even without that there's a lot of documentation out there on
the alsa and jack web sites, and a quick look with top or ps would
tell you if you have two conflicting audio servers running (which I
suspect is the cause of your problem).
Nope and not true, see next answer below. There is an expert user and
there is no other "expert" except the program developer. The programmer
is the only expert on the other side. You cannot ask users to become
program developers.
We are talking on expert users here right ?
There is a proper specification: the API docs. It sounds like you want
to become an expert but don't want to do any of the necessary work to
achieve that. That may sound harsh, but I think you've made a lot of
unfair and misdirected criticisms in this thread.
Excuse me..
The API is not even remotely a user specification. It is more of the
definition of an interface for the programmer and has nothing to do with
the user.
There is no specification as it stands
A specification in Layman's terms will describe the proposed software to
be released as a "Black Box" and that is long after the API. The
specification is for issuing to the the operator if it is consistent
and is NOT an operation manual. It is the testbed conditions to evaluate
the software, clearly repeatably and consistently, by anyone wanting to
use it.
In modern days, simulators of a piece of equipment running software can
be viewed as a dynamic form of specification as it can only operate
within a specification to be valid.
The simulator is written on the basis of the blackbox behavior.
Obviously not the API as it involves the programmer. A specification
evaluates the software independent from its creators equally valid for
anyone, no bias.
1) Therefore you need to define inputs outputs. This has several
subsections.
2) Points of instability.
3) Operational Dependencies on other software.
...and the list goes on.
There is no formal /specification which would force the software into a
usuable object by testing it against specification or junk and rewrite
if it doesnt conform.
I understand that specification is not really a commercial/casual thing,
as linux is, and rather for mission critical situations, but it would
not hurt to adopt it as it will be usable to general users if it
conforms to a general black box specification and save everyone a lot of
time.
If I wrote the software I would do it, but I understand that it is
unfortunately not the norm in civilian software development which is a
pity.