Re: jackctl_setup_signals and controling logging

On Sun, Oct 31, 2010 at 03:20:35PM -0400, Paul Davis wrote:
> On Sun, Oct 31, 2010 at 2:53 PM, philippe <kelvin.bitnick <at> gmail.com> wrote:
> > Hello Paul,
> >
> > I've just tried the following (initial state: audio card powered on
> > and ready to process):
> 
> i don't really know what any of that means. and i didn't mean to
> suggest that JackOSX *currently* does what I suggested.
> 
> my point was that monitoring ieee1394 bus is redundant because the
> coreaudio API will notify JACK's backend about the state of the audio
> device.

well... monitoring the bus, to notice when a card gets plugged in, is
not redundant.
it IS redundant to monitor for the unplugging. and it would actually
make sense, if had a facility to notify via control api that the backend
went away.

--

-- 
torben Hohn

Re: jackctl_setup_signals and controling logging

and about the client, (I'm not proficient in jackd API), how do they
know about it (unavailability of the audio dev.), simply because their
callback don't get called, or is there other things to consider/be
carefull ?

I attach my small thing, in case it's usefull to someone. Style is
horrible, as I don't know c++ 

On Mon, Nov 1, 2010 at 11:17 AM, torbenh <torbenh <at> gmx.de> wrote:
> On Sun, Oct 31, 2010 at 03:20:35PM -0400, Paul Davis wrote:
>> On Sun, Oct 31, 2010 at 2:53 PM, philippe <kelvin.bitnick <at> gmail.com> wrote:
>> > Hello Paul,
>> >
>> > I've just tried the following (initial state: audio card powered on
>> > and ready to process):
>>
>> i don't really know what any of that means. and i didn't mean to
>> suggest that JackOSX *currently* does what I suggested.
>>
>> my point was that monitoring ieee1394 bus is redundant because the
>> coreaudio API will notify JACK's backend about the state of the audio
>> device.
>
> well... monitoring the bus, to notice when a card gets plugged in, is
> not redundant.
> it IS redundant to monitor for the unplugging. and it would actually
> make sense, if had a facility to notify via control api that the backend
> went away.
>
>

Re: jackctl_setup_signals and controling logging

On Monday 01 November 2010 11:32:59 philippe wrote:
> and about the client, (I'm not proficient in jackd API), how do they
> know about it (unavailability of the audio dev.), simply because their
> callback don't get called, or is there other things to consider/be
> carefull ?

Why should the client care whether a backend is attached or which specific 
backend is attached? What difference does it make whether alsa-backend, 
firewire-backend, macosx-backend, null-backend or freewheeling-backend is used?
A client shouldn't even care whether the signals are routed from/to hardware 
ports...

Arnold

_______________________________________________
Jack-Devel mailing list
Jack-Devel <at> lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

Re: jackctl_setup_signals and controling logging

On Mon, Nov 1, 2010 at 6:17 AM, torbenh <torbenh <at> gmx.de> wrote:
> On Sun, Oct 31, 2010 at 03:20:35PM -0400, Paul Davis wrote:
>> On Sun, Oct 31, 2010 at 2:53 PM, philippe <kelvin.bitnick <at> gmail.com> wrote:
>> > Hello Paul,
>> >
>> > I've just tried the following (initial state: audio card powered on
>> > and ready to process):
>>
>> i don't really know what any of that means. and i didn't mean to
>> suggest that JackOSX *currently* does what I suggested.
>>
>> my point was that monitoring ieee1394 bus is redundant because the
>> coreaudio API will notify JACK's backend about the state of the audio
>> device.
>
> well... monitoring the bus, to notice when a card gets plugged in, is
> not redundant.

i was trying to be precise with my language, and then got sloppy. yes,
its not redundant in that situation.

Re: jackctl_setup_signals and controling logging

On Mon, Nov 1, 2010 at 6:57 AM, Arnold Krille <arnold <at> arnoldarts.de> wrote:
> Why should the client care whether a backend is attached or which specific
> backend is attached? What difference does it make whether alsa-backend,
> firewire-backend, macosx-backend, null-backend or freewheeling-backend is used?
> A client shouldn't even care whether the signals are routed from/to hardware
> ports...

precisely.

Re: jackctl_setup_signals and controling logging

hey with the status of jackd doco (devel tutorial beyond clients) and
the help you get from this mailing list, for sure they won't be much
newcomer in jackd development.

you spend more time arguing like peoples who knows the internal of
jack, jack ubergeeks, than beeing helpfull by giving a one sentence
answer.

comment not directed to stéphane and torbenh BTW.

com'on, how old are you?

I guess that simply having a client's callback not called maybe
enough, but about others corners to consider ?

On Mon, Nov 1, 2010 at 12:01 PM, Paul Davis <paul <at> linuxaudiosystems.com> wrote:
> On Mon, Nov 1, 2010 at 6:57 AM, Arnold Krille <arnold <at> arnoldarts.de> wrote:
>> Why should the client care whether a backend is attached or which specific
>> backend is attached? What difference does it make whether alsa-backend,
>> firewire-backend, macosx-backend, null-backend or freewheeling-backend is used?
>> A client shouldn't even care whether the signals are routed from/to hardware
>> ports...
>
> precisely.
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel <at> lists.jackaudio.org
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>

Re: jackctl_setup_signals and controling logging

Hi,

On Monday 01 November 2010 12:34:32 philippe wrote:
> I guess that simply having a client's callback not called maybe
> enough, but about others corners to consider ?

Which corners?

The purpose of jack is that clients only need to care about two things:
1) Get the processing of audio done and be finished with it in time (most 
important).
2) Sync to the time-stamp of the current processed audio block if applicable.

Everything else is (by purpose) left out of the clients application. It 
doesn't have to deal with the global synchronization, it doesn't have to deal 
with soundcards, it doesn't have to deal with sending audio to other 
applications, it doesn't have to deal with real-time rights, it doesn't have 
to deal with suspend/resume. Thats all done transparently in jackd.

And when an application just creates its sound from incoming midi-messages or 
from incoming sound, why does it care whether the backend changed from one 
process-callback to the next? And does it care whether one callback was on 
2010/30/10 and the next on 2010/01/11 with a suspend-to-ram in between?
Does it even care whether the samples are written to a hardware soundcard or 
to another pc via network-stream or directly to disk? Does it care whether the 
samples calculated for 48kHz are actually processed at 48kHz in the cpu (think 
free-wheeling aka offline-processing)?

My point (supported by paul) is that there are no sane corner cases to 
consider. The only apps that need to care are jack and maybe some controlling 

Re: jackctl_setup_signals and controling logging

On Mon, Nov 1, 2010 at 7:34 AM, philippe <kelvin.bitnick <at> gmail.com> wrote:

[ .... pointless personal attacks ignored ... ]

> com'on, how old are you?

I'm almost 47, how old are you?

> I guess that simply having a client's callback not called maybe
> enough, but about others corners to consider ?

Just like every plugin API on this planet, and just like ASIO, EASI
and CoreAudio and WaveRT, there is no requirement that a client's
process() callback is executed regularly, periodically, or at all.

And, just like every plugin API on this planet, and just like ASIO,
EASI and CoreAudio and WaveRT, the client isn't responsible for the
ultimate destination (or source) of the audio data it processes.

Whether clients are notified about backend changes differs from
ASIO/EASI/CoreAudio/WaveRT because JACK isn't attempting to provide
that level of h/w abstraction. At the moment, there is no reason to
notify any JACK client about any status change in the backend because
JACK doesn't define any such changes as being worth notifying about.

Perhaps you'd like to propose that there are in fact some backend
status changes that clients need to know about? Its a proposal that
isn't likely to get very far unless its limited to the control API,
since it would really violate one of the main design assumptions that
went into JACK: clients do not need to know and may not be able to

Re: jackctl_setup_signals and controling logging

> Perhaps you'd like to propose that there are in fact some backend
> status changes that clients need to know about? Its a proposal that
> isn't likely to get very far unless its limited to the control API,

I think the discussion could move on if we try to make proposal for that on the control API level.

It seems that "suspend/resume" issue and "backend changes" (sample rate, on/off..) share the fact that
"something" outside JACK server changes, and this has to be notified/handled by the server. A way to
handle that would be add some callback to the control API, and have the process used the control API either
handle that itself, or possibly make those events available for a more sophisticated helper (using for
instance dbus as a transfer mechanism).

Stéphane 

Re: jackctl_setup_signals and controling logging

On Mon, Nov 01, 2010 at 01:54:04PM +0100, Arnold Krille wrote:

> ..., it doesn't have to deal with real-time rights, it doesn't have 
> to deal with suspend/resume.

That may be true on a purely technical level, in the sense
that you could suspend/resume a jack app and make it surive
without it being aware of it. But it ignores the functional
level.

> And when an application just creates its sound from incoming midi-messages or 
> from incoming sound, why does it care whether the backend changed from one 
> process-callback to the next? And does it care whether one callback was on 
> 2010/30/10 and the next on 2010/01/11 with a suspend-to-ram in between?

When it does just create sound from midi messages it probably
does not care. But that is a musician-centric and rather narrow
view.

If you assume that all jack apps can be suspended/resumed without
them being informed that is equivalent to assuming that there can
be no jack app that cares about the continuity and integrity of
the audio data. Which is clearly wrong.

We may agree on one point: it's probably not jack's task to
inform an application of an imminent suspend, the system should
do it.

Even if the basic idea is that suspend/resume should be transparent
to applications, there are some for which this doesn't make sense,