Some strange things

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

Some strange things

salsaman-3
Strange thing 1:
Went to install jackd in ubuntu 10.10. It gave me the choice of jackd1 or
jackd2.

Strange thing 2:
I chose jackd2, and when I came to run jackd, it tried to run jackdmp.


Strange thing 3:
Running failed because jackdmp does not understand the -Z option which I
need.


Can somebody explain ?

Can somebody please add -Z to jackdmp so as not to break compatibility
with existing applications ? You are already causing me problems,
see e.g.:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=746#c9


Regards,
Salsaman.




_______________________________________________
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: Some strange things

Adrian Knoth
On Mon, Nov 15, 2010 at 09:43:30AM +0100, [hidden email] wrote:

Hi!

(I somehow feel you should have used a salutation, too, before yelling
at us, but anyway...)

> Strange thing 1:
> Went to install jackd in ubuntu 10.10. It gave me the choice of jackd1 or
> jackd2.

Nothing strange here. At least I don't see why it is wrong to allow
users to choose from two jackd implementations. You might have the wrong
understanding that jackd2 is the successor to jackd1, which it isn't.

> Strange thing 2:
> I chose jackd2, and when I came to run jackd, it tried to run jackdmp.

It didn't. There is no binary named "jackdmp" in the jackd2 package.
jackdmp is simply the former name of jackd2, and both binaries are
identically called jackd.

In other words, both, jackd1 and jackd2, have /usr/bin/jackd.

> Strange thing 3:
> Running failed because jackdmp does not understand the -Z option which I
> need.

So this is your solely valid point, command line arguments don't match,
and hence make it difficult to switch implementations.

While this might be justifiable for special features only present in
some jack implementations (there are more than just jackd1 and jackd2),
it might be favourable to at least allow for those command line
arguments in all implementations. So I guess -Z would be a NOP in
jackd2, while -S would be a NOP in jackd1. Something like this.

This would effectively extend the jack A"P"I to the command line
arguments, and I have the gut feeling that the DBUS guys won't like it,
but let's see. ;)

> You are already causing me problems, see e.g.:
> https://bugzilla.rpmfusion.org/show_bug.cgi?id=746#c9

Invalid. Your comment about jackdmp is simply wrong. The -Z thing, well,
could probably added to jackd2 as a NOP, but I'm not entirely convinced
about your code:

--- code ---
#ifndef IS_DARWIN
        com=g_strdup_printf("echo \"%s -Z -r -d alsa\">%s",jackd_loc,prefs->jack_aserver);
#else
#ifdef IS_SOLARIS
        // use OSS on Solaris
        com=g_strdup_printf("echo \"%s -Z -d oss\">%s",jackd_loc,prefs->jack_aserver);
#else
        // use coreaudio on Darwin
        com=g_strdup_printf("echo \"%s -Z -d coreaudio\">%s",jackd_loc,prefs->jack_aserver);
#endif
#endif
--- end of code ---

You're nailing everyone to alsa (what about firewire backends?),
non-realtime (-r) and this jackd1-dont-kick-zombies (-Z). While this
might catch the casual desktop user, it wouldn't suit the common jackd
user.

Best would probably be to not mess with jackd settings at all and let
the user tweak everything via qjackctl or similar tool. Those who use
jackd know how to set up their system (including the -Z thing), for
everyone else, there's pulseaudio.


HTH

--
mail: [hidden email]   http://adi.thur.de        PGP/GPG: key via keyserver
_______________________________________________
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: Some strange things

salsaman-3
In reply to this post by salsaman-3
On Mon, November 15, 2010 10:38, Adrian Knoth wrote:
> On Mon, Nov 15, 2010 at 09:43:30AM +0100, [hidden email] wrote:
>
> Hi!
>
> (I somehow feel you should have used a salutation, too, before yelling
at us, but anyway...)
>

Well, I am a little annoyed since you managed to completely stop LiVES
from working in several distros, including on my own system...

But anyway, hello, hope you are all well :-)


>> Strange thing 1:
>> Went to install jackd in ubuntu 10.10. It gave me the choice of jackd1 or
>> jackd2.
>
> Nothing strange here. At least I don't see why it is wrong to allow
users to choose from two jackd implementations. You might have the wrong
understanding that jackd2 is the successor to jackd1, which it isn't.
>

Then why is it:
- there is no longer a development package for libjackd1
- there is a devel package for libjackd2, but installing this forces
removal of jackd1

-> hence I can no longer compile against jackd1, and I am forced to
install and compile against jackd2





>> Strange thing 2:
>> I chose jackd2, and when I came to run jackd, it tried to run jackdmp.
>
> It didn't. There is no binary named "jackdmp" in the jackd2 package.
jackdmp is simply the former name of jackd2, and both binaries are
identically called jackd.
>

OK, I was confused here due to a bug where is shows "jackdmp" in the error
message. But anyway...

Now I am running jackd2 (see above)


> In other words, both, jackd1 and jackd2, have /usr/bin/jackd.
>
>> Strange thing 3:
>> Running failed because jackdmp does not understand the -Z option which
I need.
>
> So this is your solely valid point, command line arguments don't match,
and hence make it difficult to switch implementations.
>

This makes it impossible for me to switch implementations, because the -Z
option is in my ~/.jackdrc file.

As it will be for most LiVES users also (since LiVES creates ~/.jackdrc if
it is not present).



So now, any LiVES users who install jackd2 (which they will have to if
they want to compile LiVES with jack), can no longer run LiVES.





> While this might be justifiable for special features only present in
some jack implementations (there are more than just jackd1 and jackd2),
it might be favourable to at least allow for those command line
> arguments in all implementations. So I guess -Z would be a NOP in
jackd2, while -S would be a NOP in jackd1. Something like this.
>
> This would effectively extend the jack A"P"I to the command line
arguments, and I have the gut feeling that the DBUS guys won't like it,
but let's see. ;)
>
>> You are already causing me problems, see e.g.:
>> https://bugzilla.rpmfusion.org/show_bug.cgi?id=746#c9
>
> Invalid. Your comment about jackdmp is simply wrong. The -Z thing, well,
could probably added to jackd2 as a NOP, but I'm not entirely convinced
about your code:
>


As I said, the jackdmp was just about confusion over the error message.


The important point is, you guys just broke LiVES for pretty much every user.






> --- code ---
> #ifndef IS_DARWIN
>         com=g_strdup_printf("echo \"%s -Z -r -d
> alsa\">%s",jackd_loc,prefs->jack_aserver);
> #else
> #ifdef IS_SOLARIS
>         // use OSS on Solaris
>         com=g_strdup_printf("echo \"%s -Z -d
> oss\">%s",jackd_loc,prefs->jack_aserver);
> #else
>         // use coreaudio on Darwin
>         com=g_strdup_printf("echo \"%s -Z -d
> coreaudio\">%s",jackd_loc,prefs->jack_aserver);
> #endif
> #endif
> --- end of code ---
>
> You're nailing everyone to alsa (what about firewire backends?),
non-realtime (-r) and this jackd1-dont-kick-zombies (-Z). While this
might catch the casual desktop user, it wouldn't suit the common jackd
user.


I would think upgrading from jack 1 to jack 2, you should at least keep
backwards compatibilty with prior versions, and not break current existing
setups.


Point 2: why has the -Z option been removed ? LiVES needs this to avoid
being kicked out of the chain every time there is an xrun.






>
> Best would probably be to not mess with jackd settings at all and let
the user tweak everything via qjackctl or similar tool. Those who use
jackd know how to set up their system (including the -Z thing), for
everyone else, there's pulseaudio.
>

That is exactly whay I have done by getting LiVES to create the user's
~/.jackdrc file.

You guys just completely broke that. Now I will personally have to explain
to every LiVES/jack user that they need to go and edit their ~/.jackdrc
file and remove the -Z flag as it is no longer supported. After which they
can then run LiVES, although it will probably hang due to being kicked out
of jack because it gets zombified now.

Or they can use pulse audio, true. But of course, they can no longer start
up LiVES to change their audio player.

So they will have to start lives with lives -aplayer pulse.

Are you beginning to see yet why I might be annoyed ?



Kind regards,
Salsaman.




_______________________________________________
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: Some strange things

salsaman-3
In reply to this post by Adrian Knoth
On Mon, November 15, 2010 10:38, Adrian Knoth wrote:

> On Mon, Nov 15, 2010 at 09:43:30AM +0100, [hidden email] wrote:
>
> Hi!
>
> (I somehow feel you should have used a salutation, too, before yelling
> at us, but anyway...)
>
>> Strange thing 1:
>> Went to install jackd in ubuntu 10.10. It gave me the choice of jackd1
>> or
>> jackd2.
>
> Nothing strange here. At least I don't see why it is wrong to allow
> users to choose from two jackd implementations. You might have the wrong
> understanding that jackd2 is the successor to jackd1, which it isn't.
>
>> Strange thing 2:
>> I chose jackd2, and when I came to run jackd, it tried to run jackdmp.
>
> It didn't. There is no binary named "jackdmp" in the jackd2 package.
> jackdmp is simply the former name of jackd2, and both binaries are
> identically called jackd.
>
> In other words, both, jackd1 and jackd2, have /usr/bin/jackd.
>
>> Strange thing 3:
>> Running failed because jackdmp does not understand the -Z option which I
>> need.
>
> So this is your solely valid point, command line arguments don't match,
> and hence make it difficult to switch implementations.
>
> While this might be justifiable for special features only present in
> some jack implementations (there are more than just jackd1 and jackd2),
> it might be favourable to at least allow for those command line
> arguments in all implementations. So I guess -Z would be a NOP in
> jackd2, while -S would be a NOP in jackd1. Something like this.
>
> This would effectively extend the jack A"P"I to the command line
> arguments, and I have the gut feeling that the DBUS guys won't like it,
> but let's see. ;)
>
>> You are already causing me problems, see e.g.:
>> https://bugzilla.rpmfusion.org/show_bug.cgi?id=746#c9
>
> Invalid. Your comment about jackdmp is simply wrong. The -Z thing, well,
> could probably added to jackd2 as a NOP, but I'm not entirely convinced
> about your code:
>
> --- code ---
> #ifndef IS_DARWIN
>         com=g_strdup_printf("echo \"%s -Z -r -d
> alsa\">%s",jackd_loc,prefs->jack_aserver);
> #else
> #ifdef IS_SOLARIS
>         // use OSS on Solaris
>         com=g_strdup_printf("echo \"%s -Z -d
> oss\">%s",jackd_loc,prefs->jack_aserver);
> #else
>         // use coreaudio on Darwin
>         com=g_strdup_printf("echo \"%s -Z -d
> coreaudio\">%s",jackd_loc,prefs->jack_aserver);
> #endif
> #endif
> --- end of code ---
>
> You're nailing everyone to alsa (what about firewire backends?),

Advanced users should know how to edit their ~/.jackdrc file.

> non-realtime (-r)

This flag is needed on some distros, else jackd will not start up for
non-root users.

> and this jackd1-dont-kick-zombies (-Z). While this
> might catch the casual desktop user, it wouldn't suit the common jackd
> user.
>

As I said, it is necessary for LiVES not to be zombified.


> Best would probably be to not mess with jackd settings at all and let
> the user tweak everything via qjackctl or similar tool. Those who use
> jackd know how to set up their system (including the -Z thing), for
> everyone else, there's pulseaudio.

Agreed, advanced users should be able to tweak things - basic users should
have a basic setup - which is how things work now, or used to work.

Salsaman.


_______________________________________________
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: Some strange things

Arnold Krille-3
In reply to this post by salsaman-3
Hi,

On Monday 15 November 2010 11:30:42 [hidden email] wrote:
> Point 2: why has the -Z option been removed ? LiVES needs this to avoid
> being kicked out of the chain every time there is an xrun.


Here is the good news: On jack2 no app needs the -Z option because jack2
doesn't kick any clients from its chain if they don't deliver in time. So if
LiVES isn't fast enough and produces an x-run, this will only affect LiVES and
its audio-output (which will give the typical click of an xrun). All other
audio will be fine.

> You guys just completely broke that. Now I will personally have to explain

Excuse my sarcasm: You poor sod.

> to every LiVES/jack user that they need to go and edit their ~/.jackdrc
> file and remove the -Z flag as it is no longer supported. After which they
> can then run LiVES, although it will probably hang due to being kicked out
> of jack because it gets zombified now.
> Are you beginning to see yet why I might be annoyed ?

Why is the option of fixing LiVES missing in this whole discussion? After all
you are talking low-latency audio here. If an app isn't capable of doing that
(but wants to be) it should be fixed instead of circumventing that by the -Z
option...

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: Some strange things

Adrian Knoth
In reply to this post by salsaman-3
On Mon, Nov 15, 2010 at 11:30:42AM +0100, [hidden email] wrote:

Hi!

> >> Strange thing 1:
> >> Went to install jackd in ubuntu 10.10. It gave me the choice of jackd1 or
> >> jackd2.
> >
> > Nothing strange here. At least I don't see why it is wrong to allow
> > users to choose from two jackd implementations. You might have the wrong
> > understanding that jackd2 is the successor to jackd1, which it isn't.
> >
>
> Then why is it:
> - there is no longer a development package for libjackd1

There is: libjack-dev.

> - there is a devel package for libjackd2, but installing this forces
> removal of jackd1

You either have libjack-dev or libjack-jackd2-dev. The -dev packages are
bound to the corresponding jackd version, so libjack-jackd2-dev pulls in
libjackd2.

It's completely fine to compile against either version, at least on
Debian, the generated dependency will be suitable for all runtime
versions that provide the libjack-0.116 functionality (which holds true
for jackd1-0.116 and above, jackd2-1.9.x with x something around 5 I
guess, tschack...)

> -> hence I can no longer compile against jackd1, and I am forced to
> install and compile against jackd2

See above. Compiling against jackd1 is actually the default we use for
our Debian packages. All software depends on libjack-dev, which is
jackd1.

> This makes it impossible for me to switch implementations, because the -Z
> option is in my ~/.jackdrc file.

Exactly. We need to wait for sletz to comment on that.

BTW: Have you noticed that there are more ways to invoke jackd than via
calling /usr/bin/jackd or executing .~/jackdrc? Like jackdbus?

> So now, any LiVES users who install jackd2 can no longer run LiVES.

Unless they manually change the -Z in jackdrc. Thing is: it needs time
to add -Z to jackd2.  Strictly speaking, it can be done within some
minutes as a NOP, but until distros will push this downstream to the
users, a couple of years will probably pass.

I can say for sure that upcoming Debian Squeeze is frozen, so there's no
chance to get it into this release. Next release will be... well, you
know, in a couple of years.

So we need something better for the time being.


> > --- code ---
> > #ifndef IS_DARWIN
> >         com=g_strdup_printf("echo \"%s -Z -r -d alsa\">%s"
> >
> > You're nailing everyone to alsa (what about firewire backends?),

Again: what about -d firewire? Or -d net for those who care? To some
extent, this also holds true for the -r and -Z: you're making
assumptions about the common case, and not matching them is causing
trouble.

Note that Debian prompts the user whether or not to enable realtime
priorities when installing any of the jackd packages.

> I would think upgrading from jack 1 to jack 2, you should at least
> keep backwards compatibilty with prior versions, and not break current
> existing setups.

It's by far no upgrade, it's a completely different codebase, a
different implementation. All they share is the API and to some degree a
set of tools. It's like saying bash is an upgrade to zsh or vice versa.

Anyway, I strongly support to have standardised invocation flags.


> Point 2: why has the -Z option been removed ? LiVES needs this to avoid
> being kicked out of the chain every time there is an xrun.

I'm no expert on this point (I only package jackd1 and jackd2 for
Debian), but iirc, jackd2 automatically is in asynchronous mode which
allows for applications to miss a cycle. This might be the same as -Z
for jackd1, but again, I might be wrong. There is also -S to jackd2,
putting it into synchronous mode, the default (non-Z) jackd1 behaviour,
at least I guess.

I somehow have the feeling that the whole -Z thing is a hack to
circumvent some design problems in LiVES. Jack has the clear notion of a
callback driven low latency audio application that is fast enough to
deliver the frames in time.

If you need more time, copy the audio data to a ringbuffer and return
from the callback.

Speaking of which: you're calling malloc() in your audio callback. This
is asking for trouble.

Oh, and while we're at it:

  dummyvar=write (mainw->aud_rec_fd,holding_buff,
         frames_out*(afile->asampsize/8)*afile->achans);

Are you doing file IO here? Have a look at jackrec[0] (part of the jackd
source) how to do it properly. Again, you want a second FIFO to store
your audio data, return from the jackd callback and then read this FIFO
from another non-RT thread.

This way, LiVES won't get kicked out of the chain and you no longer need
-Z.



HTH

[0]
http://trac.jackaudio.org/browser/trunk/jack/example-clients/capture_client.c


--
mail: [hidden email]   http://adi.thur.de        PGP/GPG: key via keyserver
_______________________________________________
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: Some strange things

Paul Davis
In reply to this post by salsaman-3
On Mon, Nov 15, 2010 at 5:42 AM,  <[hidden email]> wrote:

>> non-realtime (-r)
>
> This flag is needed on some distros, else jackd will not start up for
> non-root users.

True to a point. But the reality is that roughly 80% of JACK usage
scenarios pretty much require RT scheduling, and one of the main
reasons why we switched to -R being the default - to force users (and
packagers and distros and the kernel crew) to face this problem and
correct it.

>> and this jackd1-dont-kick-zombies (-Z). While this
>> might catch the casual desktop user, it wouldn't suit the common jackd
>> user.
>>
>
> As I said, it is necessary for LiVES not to be zombified.

adding a command line flag to "fix" this is a workaround. its not
really the right solution. applications that cause xruns (rather than
kernel scheduling that cause xruns) are the problem, and -Z is
normally a bandaid. if LiVES needed this, then it suggests that LiVES
has some behavioural issues. the reason -Z doesn't exist for jack2 is
that it basically never zombifies anything. its quite happy to let
clients miss deadlines with few consequences. if you need -Z in order
to run LiVES with jack1, then you're just covering up either really
poor system configuration or bad behaviour by LiVES or both. hard to
tell which.

that said, i agree that the *packaged* versions of all implementations
of JACK should almost certainly support the same cmd line options,
even if some of them are no-ops. and this in turn suggests that all
source releases should do so as well. however, as adrian noted, this
won't solve the "problem" that LiVES is unconditionally adding -Z to a
jack command line.

>> Best would probably be to not mess with jackd settings at all and let
>> the user tweak everything via qjackctl or similar tool. Those who use
>> jackd know how to set up their system (including the -Z thing), for
>> everyone else, there's pulseaudio.
>
> Agreed, advanced users should be able to tweak things - basic users should
> have a basic setup - which is how things work now, or used to work.

if people were using qjackctl or a similar tool, they would continue
to work. the "problem" involving ~/.jackctl only affects users who
have chosen to use a workflow where JACK gets started automatically by
a client. this is really not the recommended way to use JACK OR an
application like LiVES that thinks it can automatically add options to
the jack server startup command.

really, its quite inappropriate for you to be unconditionally adding
-Z to a command in ~/.jackctl. it was wrong under jack1, but it
worked. its still wrong with jack2 and it will continue to be wrong
for other implementations of JACK.
_______________________________________________
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: Some strange things

torbenh
In reply to this post by Adrian Knoth
On Mon, Nov 15, 2010 at 01:06:44PM +0100, Adrian Knoth wrote:

> On Mon, Nov 15, 2010 at 11:30:42AM +0100, [hidden email] wrote:
>
> Hi!
>
> See above. Compiling against jackd1 is actually the default we use for
> our Debian packages. All software depends on libjack-dev, which is
> jackd1.
>
> > This makes it impossible for me to switch implementations, because the -Z
> > option is in my ~/.jackdrc file.
>
> Exactly. We need to wait for sletz to comment on that.
>
> BTW: Have you noticed that there are more ways to invoke jackd than via
> calling /usr/bin/jackd or executing .~/jackdrc? Like jackdbus?
>
> > So now, any LiVES users who install jackd2 can no longer run LiVES.
>
> Unless they manually change the -Z in jackdrc. Thing is: it needs time
> to add -Z to jackd2.  Strictly speaking, it can be done within some
> minutes as a NOP, but until distros will push this downstream to the
> users, a couple of years will probably pass.
>
> I can say for sure that upcoming Debian Squeeze is frozen, so there's no
> chance to get it into this release. Next release will be... well, you
> know, in a couple of years.
>
> So we need something better for the time being.
>
>
> > > --- code ---
> > > #ifndef IS_DARWIN
> > >         com=g_strdup_printf("echo \"%s -Z -r -d alsa\">%s"
> > >
> > > You're nailing everyone to alsa (what about firewire backends?),
>
> Again: what about -d firewire? Or -d net for those who care? To some
> extent, this also holds true for the -r and -Z: you're making
> assumptions about the common case, and not matching them is causing
> trouble.
>
> Note that Debian prompts the user whether or not to enable realtime
> priorities when installing any of the jackd packages.
>
> > I would think upgrading from jack 1 to jack 2, you should at least
> > keep backwards compatibilty with prior versions, and not break current
> > existing setups.
>
> It's by far no upgrade, it's a completely different codebase, a
> different implementation. All they share is the API and to some degree a
> set of tools. It's like saying bash is an upgrade to zsh or vice versa.
>
> Anyway, I strongly support to have standardised invocation flags.
>
>
> > Point 2: why has the -Z option been removed ? LiVES needs this to avoid
> > being kicked out of the chain every time there is an xrun.
>
> I'm no expert on this point (I only package jackd1 and jackd2 for
> Debian), but iirc, jackd2 automatically is in asynchronous mode which
> allows for applications to miss a cycle. This might be the same as -Z
> for jackd1, but again, I might be wrong. There is also -S to jackd2,
> putting it into synchronous mode, the default (non-Z) jackd1 behaviour,
> at least I guess.

not exactly.
jack1 just kicks clients out, that dont behave well. this can be turned
off with -Z .

jack2 does not care when applications miss a cycle.
i think its arguable whether thats a good thing.

the -S option just makes jack2 a bit more similar to jack1, (it will
actually wait for all clients to finish their processing, if this
results in a missed deadline, then all audio will click, and not only
the path containing the offending application.
(this behaviour is sometimes necessary, when the clock timebase is a bit
bursty) however jack2 never kicks applications. even if they continously
cause xruns, or you just overload your cpu with too many clients.


>
> I somehow have the feeling that the whole -Z thing is a hack to
> circumvent some design problems in LiVES. Jack has the clear notion of a
> callback driven low latency audio application that is fast enough to
> deliver the frames in time.

yes. lives is pretty much broken. interestingly jack2 which does not
penalizes broken apps caused a problem...


--
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: Some strange things

Stéphane Letz
>> I'm no expert on this point (I only package jackd1 and jackd2 for
>> Debian), but iirc, jackd2 automatically is in asynchronous mode which
>> allows for applications to miss a cycle. This might be the same as -Z
>> for jackd1, but again, I might be wrong. There is also -S to jackd2,
>> putting it into synchronous mode, the default (non-Z) jackd1 behaviour,
>> at least I guess.
>
> not exactly.
> jack1 just kicks clients out, that dont behave well. this can be turned
> off with -Z .
>
> jack2 does not care when applications miss a cycle.
> i think its arguable whether thats a good thing.
>
> the -S option just makes jack2 a bit more similar to jack1, (it will
> actually wait for all clients to finish their processing, if this
> results in a missed deadline, then all audio will click, and not only
> the path containing the offending application.
> (this behaviour is sometimes necessary, when the clock timebase is a bit
> bursty) however jack2 never kicks applications. even if they continously
> cause xruns, or you just overload your cpu with too many clients.
>
>
>>
>> I somehow have the feeling that the whole -Z thing is a hack to
>> circumvent some design problems in LiVES. Jack has the clear notion of a
>> callback driven low latency audio application that is fast enough to
>> deliver the frames in time.
>
> yes. lives is pretty much broken. interestingly jack2 which does not
> penalizes broken apps caused a problem...
>


When I started working on the zombification thing in the context of a data-flow kind of activation (so different from the "one sequence of client" model of jack1),  I rapidly realized that:

- jack1 itself was not always kicking the correct client at that time (I don't know for sure what happens now): by designing test clients where CPU load could be finely controled and by testing different graph topology, the result was... not really predictable. IMHO kicking wrong client is worse than anything else.

- zombification in a data-flow kind of activation was more complex to implement the "correct" way, the resulting timing code was too complex. So I just decided to remove the whole thing and keep the simplest possible activation model.

- In this context getting Xruns is the way to know that something bad happens. Then jack2 contains "sophisticated" timing profiling code that allows to understand what happens at different timing points in a cycle for each client. (jack2 can be build with profiling code on, then timing log files and gnuplot based scripts to display curves can be generated)

- the choice for jack2 is : have the simplest possible activation model and give developers tools to help them understand why their applications cause Xruns.

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: Some strange things

Fons Adriaensen-2
On Tue, Nov 16, 2010 at 09:53:07PM +0100, Stéphane Letz wrote:

> When I started working on the zombification thing in the context of a data-flow kind of activation (so different from the "one sequence of client" model of jack1),  I rapidly realized that:
>
> - jack1 itself was not always kicking the correct client at that time (I don't know for sure what happens now): by designing test clients where CPU load could be finely controled and by testing different graph topology, the result was... not really predictable. IMHO kicking wrong client is worse than anything else.
>
> - zombification in a data-flow kind of activation was more complex to implement the "correct" way, the resulting timing code was too complex. So I just decided to remove the whole thing and keep the simplest possible activation model.
>
> - In this context getting Xruns is the way to know that something bad happens. Then jack2 contains "sophisticated" timing profiling code that allows to understand what happens at different timing points in a cycle for each client. (jack2 can be build with profiling code on, then timing log files and gnuplot based scripts to display curves can be generated)
>
> - the choice for jack2 is : have the simplest possible activation model and give developers tools to help them understand why their applications cause Xruns.

All this makes a lot of sense. Even if you have complete timing information
it's not always possible to say which client is at fault - it could just be
a combination of clients that take too much time. The only clear case would
be single client that on its own takes more then the period time - kicking
this one out would make sense.

Rather than adding a dummy -Z to jackdmp I'd much prefer for jackd1 to
behave as with -Z by default.

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: Some strange things

torbenh
On Tue, Nov 16, 2010 at 10:12:53PM +0100, [hidden email] wrote:
> On Tue, Nov 16, 2010 at 09:53:07PM +0100, Stéphane Letz wrote:
>
> > When I started working on the zombification thing in the context of a data-flow kind of activation (so different from the "one sequence of client" model of jack1),  I rapidly realized that:
> >
> > - jack1 itself was not always kicking the correct client at that time (I don't know for sure what happens now): by designing test clients where CPU load could be finely controled and by testing different graph topology, the result was... not really predictable. IMHO kicking wrong client is worse than anything else.

it got a bit better, but its true that its not always the right client
that gets kicked.
back in the 2.4.x days we really wanted to kick clients quickly, because
of the high risks of deadlock.

now with the scheduler protecting us from SCHED_FIFO locking the machine
up, we could act a bit more relaxed.

> >
> > - zombification in a data-flow kind of activation was more complex to implement the "correct" way, the resulting timing code was too complex. So I just decided to remove the whole thing and keep the simplest possible activation model.
> >
> > - In this context getting Xruns is the way to know that something bad happens. Then jack2 contains "sophisticated" timing profiling code that allows to understand what happens at different timing points in a cycle for each client. (jack2 can be build with profiling code on, then timing log files and gnuplot based scripts to display curves can be generated)
> >
> > - the choice for jack2 is : have the simplest possible activation model and give developers tools to help them understand why their applications cause Xruns.

i find this a bit cumbersome.
xruns are pretty rare events. i dont really want to have timing
machinery running to catch them.

i find something like jack_interposer a lot more helpful.
if you want to go this route, i really suggest you add it to the
codebase, to make it more visible.


>
> All this makes a lot of sense. Even if you have complete timing information
> it's not always possible to say which client is at fault - it could just be
> a combination of clients that take too much time. The only clear case would
> be single client that on its own takes more then the period time - kicking
> this one out would make sense.

indeed. (with low period sizes, a failing client almost always exceeds
the estimated period_time)  
this case is actually the case i see most often.
 

>
> Rather than adding a dummy -Z to jackdmp I'd much prefer for jackd1 to
> behave as with -Z by default.

i would also like jack_check_clients to be more sensible.
however, i would really like to kick clients that are stopped,
these look like a scheduler problem, because they most likely got
triggered, but didnt set their start timestamp.

>
> Ciao,
>
> --
> FA
>
> There are three of them, and Alleline.
>

--
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: Some strange things

salsaman-3
In reply to this post by torbenh
On Tue, November 16, 2010 21:25, torbenh wrote:

> On Mon, Nov 15, 2010 at 01:06:44PM +0100, Adrian Knoth wrote:
>> On Mon, Nov 15, 2010 at 11:30:42AM +0100, [hidden email] wrote:
>>
>> Hi!
>>
>> See above. Compiling against jackd1 is actually the default we use for
>> our Debian packages. All software depends on libjack-dev, which is
>> jackd1.
>>
>> > This makes it impossible for me to switch implementations, because the
>> -Z
>> > option is in my ~/.jackdrc file.
>>
>> Exactly. We need to wait for sletz to comment on that.
>>
>> BTW: Have you noticed that there are more ways to invoke jackd than via
>> calling /usr/bin/jackd or executing .~/jackdrc? Like jackdbus?
>>

That's good to know, and it might be useful when I get a chance to
implement dbus support in LiVES.



>> > So now, any LiVES users who install jackd2 can no longer run LiVES.
>>
>> Unless they manually change the -Z in jackdrc. Thing is: it needs time
>> to add -Z to jackd2.  Strictly speaking, it can be done within some
>> minutes as a NOP, but until distros will push this downstream to the
>> users, a couple of years will probably pass.
>>
>> I can say for sure that upcoming Debian Squeeze is frozen, so there's no
>> chance to get it into this release. Next release will be... well, you
>> know, in a couple of years.
>>
>> So we need something better for the time being.
>>

Well, one possibility is that the next release of LiVES checks the jack
version, and then greps for -Z in jackdrc, and if necessary pops up a
warning advising the user to edit their jackdrc file and remove the flag.
I could even use sed to automacally remove it.

That's about the best I can do. To do that I need to know which version of
jack first removed the -Z flag.


I am also rewriting the LiVES jack player as Paul suggested so that the
callback only does a simple memcpy.

Anything else would have to be done as part of the debian upgrade process.




>>
>> > > --- code ---
>> > > #ifndef IS_DARWIN
>> > >         com=g_strdup_printf("echo \"%s -Z -r -d alsa\">%s"
>> > >
>> > > You're nailing everyone to alsa (what about firewire backends?),
>>
>> Again: what about -d firewire? Or -d net for those who care? To some
>> extent, this also holds true for the -r and -Z: you're making
>> assumptions about the common case, and not matching them is causing
>> trouble.
>>

Well OK. Is there some way to list all the backends that jackd supports ?
And what if the user inadvertantly picks the wrong backend ? E.g. they
select "dummy" and then wonder why there is no sound coming out of the
speakers.


>> Note that Debian prompts the user whether or not to enable realtime
>> priorities when installing any of the jackd packages.
>>
>> > I would think upgrading from jack 1 to jack 2, you should at least
>> > keep backwards compatibilty with prior versions, and not break current
>> > existing setups.
>>
>> It's by far no upgrade, it's a completely different codebase, a
>> different implementation. All they share is the API and to some degree a
>> set of tools. It's like saying bash is an upgrade to zsh or vice versa.
>>
>> Anyway, I strongly support to have standardised invocation flags.
>>

That may be, but as far as the end users are concerned, it is an upgrade.

>>
>> > Point 2: why has the -Z option been removed ? LiVES needs this to
>> avoid
>> > being kicked out of the chain every time there is an xrun.
>>
>> I'm no expert on this point (I only package jackd1 and jackd2 for
>> Debian), but iirc, jackd2 automatically is in asynchronous mode which
>> allows for applications to miss a cycle. This might be the same as -Z
>> for jackd1, but again, I might be wrong. There is also -S to jackd2,
>> putting it into synchronous mode, the default (non-Z) jackd1 behaviour,
>> at least I guess.
>
> not exactly.
> jack1 just kicks clients out, that dont behave well. this can be turned
> off with -Z .
>
> jack2 does not care when applications miss a cycle.
> i think its arguable whether thats a good thing.
>
> the -S option just makes jack2 a bit more similar to jack1, (it will
> actually wait for all clients to finish their processing, if this
> results in a missed deadline, then all audio will click, and not only
> the path containing the offending application.
> (this behaviour is sometimes necessary, when the clock timebase is a bit
> bursty) however jack2 never kicks applications. even if they continously
> cause xruns, or you just overload your cpu with too many clients.
>
>
>>
>> I somehow have the feeling that the whole -Z thing is a hack to
>> circumvent some design problems in LiVES. Jack has the clear notion of a
>> callback driven low latency audio application that is fast enough to
>> deliver the frames in time.
>
> yes. lives is pretty much broken. interestingly jack2 which does not
> penalizes broken apps caused a problem...
>

Well, I am rewriting it to put the file IO in a separate thread, as Paul
suggested. I am hoping this will work without too many clicks.

Regards,
Salsaman.




_______________________________________________
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: Some strange things

Stéphane Letz
In reply to this post by torbenh

Le 17 nov. 2010 à 01:08, torbenh a écrit :

> On Tue, Nov 16, 2010 at 10:12:53PM +0100, [hidden email] wrote:
>> On Tue, Nov 16, 2010 at 09:53:07PM +0100, Stéphane Letz wrote:
>>
>>> When I started working on the zombification thing in the context of a data-flow kind of activation (so different from the "one sequence of client" model of jack1),  I rapidly realized that:
>>>
>>> - jack1 itself was not always kicking the correct client at that time (I don't know for sure what happens now): by designing test clients where CPU load could be finely controled and by testing different graph topology, the result was... not really predictable. IMHO kicking wrong client is worse than anything else.
>
> it got a bit better, but its true that its not always the right client
> that gets kicked.

 Worse than nothing IMHO.

> back in the 2.4.x days we really wanted to kick clients quickly, because
> of the high risks of deadlock.
>
> now with the scheduler protecting us from SCHED_FIFO locking the machine
> up, we could act a bit more relaxed.
>
>>>
>>> - zombification in a data-flow kind of activation was more complex to implement the "correct" way, the resulting timing code was too complex. So I just decided to remove the whole thing and keep the simplest possible activation model.
>>>
>>> - In this context getting Xruns is the way to know that something bad happens. Then jack2 contains "sophisticated" timing profiling code that allows to understand what happens at different timing points in a cycle for each client. (jack2 can be build with profiling code on, then timing log files and gnuplot based scripts to display curves can be generated)
>>>
>>> - the choice for jack2 is : have the simplest possible activation model and give developers tools to help them understand why their applications cause Xruns.
>
> i find this a bit cumbersome.
> xruns are pretty rare events. i dont really want to have timing
> machinery running to catch them.

But zombification IS timing machinery running all the time!

 Profile is also timing machinery to be used for debugging purpose only and that provide more precise information.

>
> i find something like jack_interposer a lot more helpful.
> if you want to go this route, i really suggest you add it to the
> codebase, to make it more visible.

What is jack_interposer?

>
>
>
>>
>> All this makes a lot of sense. Even if you have complete timing information
>> it's not always possible to say which client is at fault - it could just be
>> a combination of clients that take too much time. The only clear case would
>> be single client that on its own takes more then the period time - kicking
>> this one out would make sense.
>
> indeed. (with low period sizes, a failing client almost always exceeds
> the estimated period_time)  
> this case is actually the case i see most often.
>
>
>>
>> Rather than adding a dummy -Z to jackdmp I'd much prefer for jackd1 to
>> behave as with -Z by default.
>
> i would also like jack_check_clients to be more sensible.
> however, i would really like to kick clients that are stopped,
> these look like a scheduler problem, because they most likely got
> triggered, but didnt set their start timestamp.

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: Some strange things

torbenh
On Wed, Nov 17, 2010 at 10:27:11AM +0100, Stéphane Letz wrote:

>
> Le 17 nov. 2010 à 01:08, torbenh a écrit :
>
> > On Tue, Nov 16, 2010 at 10:12:53PM +0100, [hidden email] wrote:
> >> On Tue, Nov 16, 2010 at 09:53:07PM +0100, Stéphane Letz wrote:
> >>
> >>> When I started working on the zombification thing in the context of a data-flow kind of activation (so different from the "one sequence of client" model of jack1),  I rapidly realized that:
> >>>
> >>> - jack1 itself was not always kicking the correct client at that time (I don't know for sure what happens now): by designing test clients where CPU load could be finely controled and by testing different graph topology, the result was... not really predictable. IMHO kicking wrong client is worse than anything else.
> >
> > it got a bit better, but its true that its not always the right client
> > that gets kicked.
>
>  Worse than nothing IMHO.

it can still be turned off.
another way is normally to set the timeout to a whole second.
this will kick the currently active client, only when processing takes a
whole second.
the chance that the offending client releases the cpu and an innocent client is
kicked, is marginally small.

anyways. if paul agrees, i will make it only kick clients which take
longer than the whole period_size.
(its a bit more complicated, but its possible)

>
> > back in the 2.4.x days we really wanted to kick clients quickly, because
> > of the high risks of deadlock.
> >
> > now with the scheduler protecting us from SCHED_FIFO locking the machine
> > up, we could act a bit more relaxed.
> >
> >>>
> >>> - zombification in a data-flow kind of activation was more complex to implement the "correct" way, the resulting timing code was too complex. So I just decided to remove the whole thing and keep the simplest possible activation model.
> >>>
> >>> - In this context getting Xruns is the way to know that something bad happens. Then jack2 contains "sophisticated" timing profiling code that allows to understand what happens at different timing points in a cycle for each client. (jack2 can be build with profiling code on, then timing log files and gnuplot based scripts to display curves can be generated)
> >>>
> >>> - the choice for jack2 is : have the simplest possible activation model and give developers tools to help them understand why their applications cause Xruns.
> >
> > i find this a bit cumbersome.
> > xruns are pretty rare events. i dont really want to have timing
> > machinery running to catch them.
>
> But zombification IS timing machinery running all the time!

well... yeah, but we dont store it anywhere.
the current zombification code doesnt really look at the timestamps.
(timestamps could well be boolean values)

>  Profile is also timing machinery to be used for debugging purpose only and that provide more precise information.
>
> >
> > i find something like jack_interposer a lot more helpful.
> > if you want to go this route, i really suggest you add it to the
> > codebase, to make it more visible.
>
> What is jack_interposer?

http://repo.or.cz/w/jack_interposer.git/blob/HEAD:/README

allows you to get backtraces for the problems.

> >
> >
> >
> >>
> >> All this makes a lot of sense. Even if you have complete timing information
> >> it's not always possible to say which client is at fault - it could just be
> >> a combination of clients that take too much time. The only clear case would
> >> be single client that on its own takes more then the period time - kicking
> >> this one out would make sense.
> >
> > indeed. (with low period sizes, a failing client almost always exceeds
> > the estimated period_time)  
> > this case is actually the case i see most often.
> >
> >
> >>
> >> Rather than adding a dummy -Z to jackdmp I'd much prefer for jackd1 to
> >> behave as with -Z by default.
> >
> > i would also like jack_check_clients to be more sensible.
> > however, i would really like to kick clients that are stopped,
> > these look like a scheduler problem, because they most likely got
> > triggered, but didnt set their start timestamp.

oh well... that was a different problem :)


--
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: Some strange things

Stéphane Letz
>>
>> What is jack_interposer?
>
> http://repo.or.cz/w/jack_interposer.git/blob/HEAD:/README
>
> allows you to get backtraces for the problems.

"Then run the program you wish to analyze: it will abort as soon as a
non-rt-safe operation is performed from the jack process callback thread:"

Well it does detect one class of problem only, and I don't see how it can be useful on anything but Linux.

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: Some strange things

torbenh
On Wed, Nov 17, 2010 at 02:13:26PM +0100, Stéphane Letz wrote:

> >>
> >> What is jack_interposer?
> >
> > http://repo.or.cz/w/jack_interposer.git/blob/HEAD:/README
> >
> > allows you to get backtraces for the problems.
>
> "Then run the program you wish to analyze: it will abort as soon as a
> non-rt-safe operation is performed from the jack process callback thread:"
>
> Well it does detect one class of problem only, and I don't see how it can be useful on anything but Linux.

it would need to get modified for osx, thats true.
but since this problem class is the one we deal with almost always, i
think having an accurate tool for this problem class is justified.

oh well... its probably enough to increase visibility of this tool.

>
> Stéphane
>  

--
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: Some strange things

salsaman-3
In reply to this post by Stéphane Letz
Hi,
can somebody please tell me exactly which version (from jack.pc) the -Z
flag disappeared ? I will need to know this to show a warning dialog if
the user has -Z in their jackdrc and jack fails to start.

Regards,
Salsaman.





_______________________________________________
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: Some strange things

Paul Davis
On Wed, Nov 17, 2010 at 9:39 AM,  <[hidden email]> wrote:
> Hi,
> can somebody please tell me exactly which version (from jack.pc) the -Z
> flag disappeared ? I will need to know this to show a warning dialog if
> the user has -Z in their jackdrc and jack fails to start.

there is no real answer to this question. it has never been present in
jack2. it was added to jack1 at svn rev 1044, in june 2007 which was
between the 0.100.0 and 0.109.0 releases. nobody should be using 0.109
since it was very broken, so the only real question is jack1 vs jack2.
_______________________________________________
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: Some strange things

salsaman-3
On Wed, November 17, 2010 15:51, Paul Davis wrote:

> On Wed, Nov 17, 2010 at 9:39 AM,  <[hidden email]> wrote:
>> Hi,
>> can somebody please tell me exactly which version (from jack.pc) the -Z
>> flag disappeared ? I will need to know this to show a warning dialog if
>> the user has -Z in their jackdrc and jack fails to start.
>
> there is no real answer to this question. it has never been present in
> jack2. it was added to jack1 at svn rev 1044, in june 2007 which was
> between the 0.100.0 and 0.109.0 releases. nobody should be using 0.109
> since it was very broken, so the only real question is jack1 vs jack2.
>

Well, pkg-config jack --modversion -> 1.9.6
This is with the current jack2-devel package on ubuntu 10.10

Note there is no jack2.pc file.

jackd --version returns jackdmp 1.9.6



Salsaman.



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