jackctl_setup_signals and controling logging

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

jackctl_setup_signals and controling logging

philippe-62
Hello again,

I'm going forward with using the jack server control api to write a
"jack on demand / jack 'ON' daemon", a jackd which start itself when a
ieee1394 audio device pop up on the bus, and shutdown itself when the
audio interface disappear (is powered off).
This is on OSX using the tools provided by apple to monitor events on
the ieee1394 bus.

About the signal handling: reading jackdmp sources
(JackControlAPI.cpp), the recommended signal handlers to setup are the
following, only no-ops:

--8<--
sigset_t
jackctl_setup_signals(
    unsigned int flags)
{
        if ((waitEvent = CreateEvent(NULL, FALSE, FALSE, NULL)) == NULL) {
        jack_error("CreateEvent fails err = %ld", GetLastError());
        return 0;
    }

        (void) signal(SIGINT, do_nothing_handler);
    (void) signal(SIGABRT, do_nothing_handler);
    (void) signal(SIGTERM, do_nothing_handler);

        return (sigset_t)waitEvent;
}
--8<--

I'm not using it, rather, for now:

--8<--
// signal handlers
static void signal_noaction( int sig ) {
        printf("jackond: received a signal for which no action is defined\n");
}

static void signal_term( int sig ) {
        printf("jackond: received sigterm, handling it\n");
        CFRunLoopStop(CFRunLoopGetCurrent());
}
...
    // set signal handlers
    signal(SIGCHLD, SIG_IGN); /* ignore child */
    signal(SIGTSTP, SIG_IGN); /* ignore tty signals */
    signal(SIGTTOU, SIG_IGN);
    signal(SIGTTIN, SIG_IGN);
    // NB.: jackctl_setup_signals handle INT and ABRT with a "do nothing"
    signal(SIGHUP, signal_noaction); /* catch hangup signal */
    signal(SIGTERM, signal_term); /* catch kill signal */

    CFRunLoopRun();
--8<--

Is it ok, am I facing evil somehow, what it the recommended way ??

One other important thing: logging.
I would like to redirect all jackd server lib to syslog, what do I need to do?
In my own code, is there some common jackd logging facilities I should
use or am I better using plain syslog?


Thaaaanks you.





NB: crossover cables are crossed, but sounds crispy if not harsh sometimes :-)

--
Ph. Strauss
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jackctl_setup_signals and controling logging

Paul Davis
On Sun, Oct 31, 2010 at 9:38 AM, philippe <[hidden email]> wrote:
> Hello again,
>
> I'm going forward with using the jack server control api to write a
> "jack on demand / jack 'ON' daemon", a jackd which start itself when a
> ieee1394 audio device pop up on the bus, and shutdown itself when the
> audio interface disappear (is powered off).
> This is on OSX using the tools provided by apple to monitor events on
> the ieee1394 bus.

I don't know for certain, but I have a gut feeling that this is the
wrong thing to do. Audio interface status changes are part of the
CoreAudio API, and trying to additionally monitor events on the
firewire bus could lead to total confusion. It seems to me that the
internal API used between the server and backends requires a way for
the backend to say "the device i was using has gone away", and then
its up to the server to decide what to do.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jackctl_setup_signals and controling logging

philippe-62
Hello Paul,

I've just tried the following (initial state: audio card powered on
and ready to process):

- launch jackdmp (from jackosx 0.87 32bits package on osx 10.5.8)
- switch off my firewire audio card
- wait 30 secs
- switch on the audio card
- wait until it's ready to process signal (some LED indicate it on the
frontpanel)
- launch a jack client (jack_convolve by florian schmidt, that's the
one I use 98% of the time)

it gives the following:

(cmd to lanch the client first:)
nice -10 /opt/av/bin/jack_convolve --name=JackConvolve --gain=1.0 \
        data/dirac.wav \
        data/dirac.wav \
        data/set1/room-deconv-mp_ch0.wav \
        data/set1/room-deconv-mp_ch1.wav \
        data/beaulieu25.1st.caml/eq.save.4/roomEQ-mp_ch0.wav \
        data/beaulieu25.1st.caml/eq.save.4/roomEQ-mp_ch1.wav \
        data/set3/room-deconv-mp_ch0.wav \
        data/set3/room-deconv-mp_ch1.wav

Jack_convolve (C) 2004 Florian Schmidt - protected by GPL
- Using jack name: "JackConvolve"
jack_client_new: deprecated
JackMachClientChannel::ClientOpen err = (ipc/mig) server died
Cannot open JackConvolve client
- Error: couldn't become jack client - server running? name already taken?

In syslog:

31.10.10 19:39:51 [0x0-0x46046].gpl.elementicaotici.JackPilot[2429]
Notice JackProcessSync::LockedTimedWait error usec = 5000000 err =
Operation timed out
31.10.10 19:39:51 [0x0-0x46046].gpl.elementicaotici.JackPilot[2429]
Notice Driver is not running
31.10.10 19:39:51 [0x0-0x46046].gpl.elementicaotici.JackPilot[2429]
Notice Cannot create new client
31.10.10 19:39:51 [0x0-0x46046].gpl.elementicaotici.JackPilot[2429]
Notice Cannot create new client
31.10.10 19:40:23 [0x0-0x46046].gpl.elementicaotici.JackPilot[2429]
Notice JackProcessSync::LockedTimedWait error usec = 464380 err =
Operation timed out
31.10.10 19:40:23 [0x0-0x46046].gpl.elementicaotici.JackPilot[2429]
Notice JackEngine::ClientDeactivate wait error ref = 2 name =
JackPilot
31.10.10 19:40:23 [0x0-0x46046].gpl.elementicaotici.JackPilot[2429]
Notice JackProcessSync::LockedTimedWait error usec = 92876 err =
Operation timed out

It doesn't have the same clean behaviour than a full laptop sleep.
I'll keep my small development for a while and now know It may work
out of the box, without my stuff, in the future.

for the logging I found out about jack_info and co in control.h

Thanks!

On Sun, Oct 31, 2010 at 7:23 PM, Paul Davis <[hidden email]> wrote:

> On Sun, Oct 31, 2010 at 9:38 AM, philippe <[hidden email]> wrote:
>> Hello again,
>>
>> I'm going forward with using the jack server control api to write a
>> "jack on demand / jack 'ON' daemon", a jackd which start itself when a
>> ieee1394 audio device pop up on the bus, and shutdown itself when the
>> audio interface disappear (is powered off).
>> This is on OSX using the tools provided by apple to monitor events on
>> the ieee1394 bus.
>
> I don't know for certain, but I have a gut feeling that this is the
> wrong thing to do. Audio interface status changes are part of the
> CoreAudio API, and trying to additionally monitor events on the
> firewire bus could lead to total confusion. It seems to me that the
> internal API used between the server and backends requires a way for
> the backend to say "the device i was using has gone away", and then
> its up to the server to decide what to do.
>
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jackctl_setup_signals and controling logging

Paul Davis
On Sun, Oct 31, 2010 at 2:53 PM, philippe <[hidden email]> 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.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jackctl_setup_signals and controling logging

torbenh
On Sun, Oct 31, 2010 at 03:20:35PM -0400, Paul Davis wrote:

> On Sun, Oct 31, 2010 at 2:53 PM, philippe <[hidden email]> 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
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jackctl_setup_signals and controling logging

philippe-62
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 <[hidden email]> wrote:

> On Sun, Oct 31, 2010 at 03:20:35PM -0400, Paul Davis wrote:
>> On Sun, Oct 31, 2010 at 2:53 PM, philippe <[hidden email]> 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
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

jackond.cpp (12K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: jackctl_setup_signals and controling logging

Arnold Krille-3
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
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: jackctl_setup_signals and controling logging

Paul Davis
In reply to this post by torbenh
On Mon, Nov 1, 2010 at 6:17 AM, torbenh <[hidden email]> wrote:

> On Sun, Oct 31, 2010 at 03:20:35PM -0400, Paul Davis wrote:
>> On Sun, Oct 31, 2010 at 2:53 PM, philippe <[hidden email]> 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.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jackctl_setup_signals and controling logging

Paul Davis
In reply to this post by Arnold Krille-3
On Mon, Nov 1, 2010 at 6:57 AM, Arnold Krille <[hidden email]> 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
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jackctl_setup_signals and controling logging

philippe-62
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 <[hidden email]> wrote:

> On Mon, Nov 1, 2010 at 6:57 AM, Arnold Krille <[hidden email]> 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
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jackctl_setup_signals and controling logging

Arnold Krille-3
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
apps, not the clients that just process audio.

Have fun,

Arnold

PS: Don't be put up by the internal discussions here (this is the list for
these discussions!) Listen, ask when you do not understand and don't be afraid
to ask beginners questions.
And don't judge Paul, Torben and others by their sometimes friendly-rude
discussions, they are actually great guys and have emptied quite some beers
together...

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: jackctl_setup_signals and controling logging

Paul Davis
In reply to this post by philippe-62
On Mon, Nov 1, 2010 at 7:34 AM, philippe <[hidden email]> 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
know anything about the audio interface hardware (if any) that is
involved. We have made 2 exceptions for this is the past and it didn't
turn out so well.

And next time, how about you hold off on the offensive and pointless
personal remarks? The fact that everybody else's communication style
doesn't match your expectations is a builtin feature of this medium.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jackctl_setup_signals and controling logging

Stéphane Letz

> 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

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jackctl_setup_signals and controling logging

Fons Adriaensen-2
In reply to this post by Arnold Krille-3
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,
and they should be informed and contain special code to take care
of this.

Ciao,

--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jackctl_setup_signals and controling logging

Paul Davis
On Mon, Nov 1, 2010 at 10:15 AM,  <[hidden email]> wrote:

> 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.

This is key.

> Even if the basic idea is that suspend/resume should be transparent
> to applications, there are some for which this doesn't make sense,
> and they should be informed and contain special code to take care
> of this.

Agreed, which is why all current versions of Linux make some attempt
to make this possible.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jackctl_setup_signals and controling logging

Arnold Krille-3
In reply to this post by Fons Adriaensen-2
Hi,

On Monday 01 November 2010 15:15:08 [hidden email] wrote:

> 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.
You think about apps like jconvolver that would produce the reverb from before
the suspend playing back after the resume in a new environment with a new
setup?

I think this can be circumvented when jack plays one block of silent lead-
out/lead-in before and after the sleep? Or several blocks?
And maybe the backends could apply a soft fade-in on the first block of audio-
playback. That would reduce the harsh clicking on startup of new backends.
Actually it would be the jack part interfacing the backend, that should
schedule and do the fade-in.

> 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.

I just came to think that maybe there should be a way to tell clients that the
backend changed. When the backend changed, the hardware-client also changes,
so apps that had connections to alsa_pcm:playback_X might redo their
connections to firewire_pcm:playback_X and the likes. Or we just assume that
apps that do care connect to the specific names and apps that don't care
connect to system:playback_X and automatically get reconnected...

Have fun,

Arnold

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: jackctl_setup_signals and controling logging

torbenh
In reply to this post by Arnold Krille-3
On Mon, Nov 01, 2010 at 01:54:04PM +0100, Arnold Krille wrote:

> 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?

alsa_out will happily crash when a suspend happens.
(i am working on fixing this, but in essence, a suspend is a phase of
non-realtime behaviour (like a huge xrun), and clients which dont get their timebase from
jack alone should have a way to get notified.



> 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
> apps, not the clients that just process audio.

there are also clients, that care for real timebases. they need to be
made aware that there is a giant xrun coming up.
its not many clients, but these clients are the mentioned corner-cases.

>
> Have fun,
>
> Arnold
>
> PS: Don't be put up by the internal discussions here (this is the list for
> these discussions!) Listen, ask when you do not understand and don't be afraid
> to ask beginners questions.
> And don't judge Paul, Torben and others by their sometimes friendly-rude
> discussions, they are actually great guys and have emptied quite some beers
> together...



> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org


--
torben Hohn
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jackctl_setup_signals and controling logging

torbenh
In reply to this post by Paul Davis
On Mon, Nov 01, 2010 at 09:43:23AM -0400, Paul Davis wrote:
> On Mon, Nov 1, 2010 at 7:34 AM, philippe <[hidden email]> wrote:
> 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,

this is mutually exclusive.

clients DO NOT have anything to do with control API.

so either clients need not care. and a client which DOES care, needs to
find some other way to get notified.

or there would need to be a callback.

note that a backend change is basically only an xrun, and a set of port
callbacks.

a suspend to RAM is a giant xrun.


--
torben Hohn
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jackctl_setup_signals and controling logging

Paul Davis
On Mon, Nov 1, 2010 at 11:32 AM, torbenh <[hidden email]> wrote:
> On Mon, Nov 01, 2010 at 09:43:23AM -0400, Paul Davis wrote:
>> On Mon, Nov 1, 2010 at 7:34 AM, philippe <[hidden email]> wrote:
>> 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,
>
> this is mutually exclusive.

actually its not. but i'm not going to explain why because you & fons
have changed my mind.

i think that if the set of events can be defined, it makes sense to
have a client callback to be notified of "server events". we tell them
about xruns, we can them about other things.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jackctl_setup_signals and controling logging

philippe-62
Sorry guys if I sounded rude, the fact is you sounded mute before this
little punch :-)
I tend to prefer a communication mode in which you don't need to yell
to get an answer, that's it.
OK of emails and distance...
Now at least I have some buffer underrun of information.

For the technical side:

It's a matter of keeping a firm abstraction layer (clients do not need
to know about HW and HW drivers, backend host API) versus "hmm
sometimes an exception to the rule is needed".

My experience is to not generalize 2 or 3 needs case, but wait for
enough cases to cumulate.

My usage pattern is / my notification needs :

90% of my jackd use is with a single client, jack_convolver (or any
other convolver).
The wiring is mostly fixed (audio card stay at the same place: in my
hifi), the jack patching has 2 x 3 differents routes, handled by a
caml client and gtk GUI.

My need is simply: when I power on the audio interface, I would like
jackd to launch. I handle the launch of clients  and it's patching by
scripting.

BTW using the jack api everything is fine, it's just that audio device
hotplug / unplug notification is something I need in this setup. Is it
the responsability of jack or not, I do not know myself.

Either the "firm abstraction layer" argument win, or the "firewire bus
monitoring is redundant" argument.

from my point of view, having some notification of availability of HW
would be a good thing, but I'm biased by my usage pattern of jackd. As
everybody is od it's own.



On Mon, Nov 1, 2010 at 4:34 PM, Paul Davis <[hidden email]> wrote:

> On Mon, Nov 1, 2010 at 11:32 AM, torbenh <[hidden email]> wrote:
>> On Mon, Nov 01, 2010 at 09:43:23AM -0400, Paul Davis wrote:
>>> On Mon, Nov 1, 2010 at 7:34 AM, philippe <[hidden email]> wrote:
>>> 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,
>>
>> this is mutually exclusive.
>
> actually its not. but i'm not going to explain why because you & fons
> have changed my mind.
>
> i think that if the set of events can be defined, it makes sense to
> have a client callback to be notified of "server events". we tell them
> about xruns, we can them about other things.
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org