Subject: Re: [linux-audio-dev] LADSPA Specs ?
From: Paul Davis (pbd_AT_op.net)
Date: Tue May 14 2002 - 04:21:47 EEST
>First I have to say I dont follow Jack development very closely due to
>lack of time. But introducing API functions over time (may they be useful
>to some of us, or even necessary) makes the Jack API look like being in
>unstable state and prevent developers (thats me) from actually trying it
>out.
Until this last weekend, no changes have been required to a JACK
client for at least 3 months, perhaps longer. The latest changes were
to stop namespace pollution. Changes that break back-compatibility are
rare.
>Just browsing through jack.h I see jack_cpu_load which seems to be
>offtopic for jack.
Well, perhaps it needs a better name. jack_cpu_load() measures what
fraction of the process()-time is actually used running clients and so
forth. Nothing but jackd can measure this, so it seems very on-topic.
Also I cannot find the transport control stuff? And
jack/transport.h. its in a separate header file because 90% of all
JACK clients won't need to deal with it, and we don't want to pollute
the main API with it, especially given the kind of response you've
given us to changes like this.
>I cant figure out what the monitor stuff is doing from the
>documentation.
I tried to write it in a very generic way that wasn't rooted in
audio. I wrote:
* Precisely what this means is dependent on the client. A typical
* result of it being called with TRUE as the second argument is
* that data that would be available from an output port (with
* JackPortIsPhysical set) is sent to a physical output connector
* as well, so that it can be heard/seen/whatever.
*
* Clients that do not control physical interfaces
* should never create ports with this bit set.
So, for the ALSA client/driver, turning on "monitor" on a port means
that it causes the data that other clients read from its port to also
be sent to its output ports, causing the data to be audible at the
same time.
This is motivated mostly by the desire to use h/w-level (i.e. zero
latency) monitoring, a feature still not properly supported by most
Windows/MacOS apps. Its what you need/want for recording clients,
and/or those that provide specific "listen to what's coming in"
controls (know as "monitor input buttons" on most pieces of hardware).
--p
This archive was generated by hypermail 2b28 : Tue May 14 2002 - 04:17:11 EEST