Re: jack2's dbus name

[torbenh]

On Tue, Jun 16, 2009 at 07:10:17PM +0100, Phil Rhodes wrote:
> I no longer have even the slightest idea what's being discussed here.
>
> When I joined this list it was to find out if jack or any jack-related
> software was capable of streaming audio over unreliable networks, such as
> wifi (the answer was then no and I believe remains no, but I'd love to be
> told otherwise).

the answer is yes.

>
> As it is, I stick around to unscientifically monitor the state of Linux
> audio in the hopes of finding out when it's ready for the big time. My
> feeling right now is "check again in ten years."
>
> http://matt.bottrell.com.au/uploads/Pics/linuxaudio.png
>
> -P
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel@...
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Lennart Poettering-15]

On Thu, 18.06.09 16:09, torbenh@... (torbenh@...) wrote:

> > I think org.jackaudio.service should be fine. I don't think this
> > automatic logic needs to work on non-D-Bus jack builds. As I see it
> > you don't need to make any changes on jack for this to work. All I
> > need is the guarantee that by the time the service name is registered
> > on the bus jack is fully accessible. Otherwise we had a race here: if
> > PA looks for the org.jackaudio.service name to appear on the bus and
> > then imemdiately connects to it while jack isn't fully accessible yet
> > PA would fail.
>
> the existence of org.jackaudio.service object does not guarantee,
> that jackd is connectable.

I'd consider that brokeness in Jack then. Taking the name on the bus
sould be the last step during initialization. Otherwise you'll always
be in racy situations where clients try to talk to JACK while JACK is
only half-way initialized.

>
> i guess we need a signal, which tells that a server has been started,
> but i leave this to the dbus guys.

Nope. That is the wrong approach.

> my primary concern is to have the pa jack backend fixed.
> lennart himself said its a TOY. and it really is.

Aha.

> i dont really understand why it works, but its pretty broken, for
> sure.

Aha.

> static int jack_process(jack_nframes_t nframes, void *arg) {
>     struct userdata *u = arg;
>     unsigned c;
>     jack_nframes_t frame_time;
>     pa_assert(u);
>
>     /* We just forward the request to our other RT thread */
>
>     for (c = 0; c < u->channels; c++)
>         pa_assert_se(u->buffer[c] = jack_port_get_buffer(u->port[c], nframes));
>
>     frame_time = jack_frame_time(u->client);
>
>     pa_assert_se(pa_asyncmsgq_send(u->jack_msgq, PA_MSGOBJECT(u->sink), SINK_MESSAGE_RENDER, &frame_time, nframes, NULL) == 0);
>     return 0;
> }
>
>
> it needs to be decoupled using a ringbuffer.

Uh? That is actually what happens.

This is a bit more complex than you might think. Jack's thread
management is very unflexible and insists on controlling the entire
thread life cycle, only calling into client code in very few
occasions. This is a bit too limited for PA which needs better control
on the RT loops so that it can properly priorize/order the work it
needs to do in it. To work around that I decided to run two RT
threads, one where PA does its own RT looping, and the one jack
controls. The latter then simply relays the process requests
synchronously to the former. This of course comes at the cost of a
needless context switch, however both threads are RT. The normal PA RT
loop thread communicates lock-free and asynchronously with the rest of
the PA code.

Yes, having to work around JACK's API like this is certainly not
nice. But aside from the extra context switch this shouldn't be too
bad.

Of course it would great if JACK would be more flexible with its RT
loop handling. What I am missing is basically a way to
asynchronously/lock-free trigger execution of a callback function in
the RT loop at a suitable place. By a "suitable place" I mean that the
RT loop delays execution of this callback until a time where its
impact would be minimal, i.e. right after a completed process() and a
quick verification that the next process() cycle is still a bit away.

Why does pa need those callbacks? In contrast to JACK we need to be
able to modify our pipelines during playback without having that cause
drop-outs in any way. To accomplish that updates to pipeline related
data structures that need to be accessed by the RT loop are as far as
possible done in the main thread, however usually the last remaining
bit for activating those changes is left for the RT loop to do itself,
asynchronously and only when it can be sure that nothing else needs to
be done. That way we can have those data structures implemented
lock-free without really having to implement them with all that
lock-free complexity.

> and maybe pulse should be running with a higher blocksize than jack ?

PA does not use fixed block sizes. We always use the largest chunk
sizes the applications pass to us and break them up into smaller
pieces only when really necessary. We really try our best not having
to touch/convert/split/copy user supplied PCM data if we don't have
to.

Lennart

--
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Paul Davis]

On Thu, Jun 18, 2009 at 12:21 PM, Lennart Poettering <mzynq@...> wrote:

This is a bit more complex than you might think. Jack's thread
management is very unflexible and insists on controlling the entire
thread life cycle, only calling into client code in very few
occasions.

You might want to check out the more recent API additions:

jack_cycle_wait()
jack_cycle_signal()

which were created for precisely the sort of reasons you are describing.
 

Of course it would great if JACK would be more flexible with its RT
loop handling. What I am missing is basically a way to
asynchronously/lock-free trigger execution of a callback function in
the RT loop at a suitable place. By a "suitable place" I mean that the
RT loop delays execution of this callback until a time where its
impact would be minimal, i.e. right after a completed process() and a
quick verification that the next process() cycle is still a bit away.

e.g. right after jack_cycle_signal()

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

[Fons Adriaensen-2]

On Thu, Jun 18, 2009 at 01:51:52PM -0400, Paul Davis wrote:

> You might want to check out the more recent API additions:
>
> jack_cycle_wait()
> jack_cycle_signal()
>
> which were created for precisely the sort of reasons you are describing.

Unless these have been modified in a way I'm not aware
of, that is absolutely not true.

What Lennart wants, if I understand his post
correctly, it to be called at a time that suits
the structure of his code. This is not what jack
is ever supposed to do.

When a client calls jack_client_wait() instead of
returning from a callback, the effect is that the
client can keep the function context of the call-
back, e.g. you can even do it inside a conditional
or a loop, and your local variables are preserved
(as it is just a function call from the client's
perspective).

Jack_client_wait() will then return at *exactly*
the same time when the next callback would be
called if the client had not used this function
but returned from the callback.

In other words using this interface is not a
licence or a means to delay the processing that
should happen in the callback. It would be right
against the 'jack model' if it were.

Jack_cycle_signal() is used either before returning
from the callback or calling jack_cycle_wait(), and
tells jack that as far as it is concerned the client
has done all it wants to do related to the jack ports
and their buffers. Its use allows the client to
continue doing other things without blocking other
jack clients, but these other things should not
involve jack's port buffers.

Ciao,

--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

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

[Paul Davis]

On Thu, Jun 18, 2009 at 2:23 PM, Fons Adriaensen<fons@...> wrote:

> On Thu, Jun 18, 2009 at 01:51:52PM -0400, Paul Davis wrote:
>
>> You might want to check out the more recent API additions:
>>
>> jack_cycle_wait()
>> jack_cycle_signal()
>>
>> which were created for precisely the sort of reasons you are describing.
>
> Unless these have been modified in a way I'm not aware
> of, that is absolutely not true.

  while (1) {
       jack_cycle_wait ();
       .... do JACK callback stuff ....
       jack_cycle_signal ();
       ... do some extra stuff that is still really bound by RT rules
           but is no longer "inside" the JACK process() cycle
  }

I believe we are both on the same page here.

> What Lennart wants, if I understand his post
> correctly, it to be called at a time that suits
> the structure of his code. This is not what jack
> is ever supposed to do.

i think he wanted a way to initiate something right after the process
callback is done.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fons Adriaensen-2]

On Thu, Jun 18, 2009 at 02:34:11PM -0400, Paul Davis wrote:

>   while (1) {
>        jack_cycle_wait ();
>        .... do JACK callback stuff ....
>        jack_cycle_signal ();
>        ... do some extra stuff that is still really bound by RT rules
>            but is no longer "inside" the JACK process() cycle
>   }
>
> I believe we are both on the same page here.

Yes.
 
> > What Lennart wants, if I understand his post
> > correctly, it to be called at a time that suits
> > the structure of his code. This is not what jack
> > is ever supposed to do.
>
> i think he wanted a way to initiate something right after the process
> callback is done.

Not sure. Anyway, if he wants to copy jack's buffers
to/from some lock-free buffers then this has to be
done before calling jack_cycle_signal().

You would want to do this *if* you already have another
thread using the other ends of the lock-free buffers,
but you don't need *yet one more* to implement it.

Ciao,

--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

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

[Lennart Poettering-15]

On Thu, 18.06.09 13:51, Paul Davis (paul@...) wrote:

> On Thu, Jun 18, 2009 at 12:21 PM, Lennart Poettering <mzynq@...>wrote:
>
> >
> >
> > This is a bit more complex than you might think. Jack's thread
> > management is very unflexible and insists on controlling the entire
> > thread life cycle, only calling into client code in very few
> > occasions.
>
>
> You might want to check out the more recent API additions:
>
> jack_cycle_wait()
> jack_cycle_signal()
>
> which were created for precisely the sort of reasons you are describing.

That sounds like it was what I need.

So, how would I use this? I figure something like this:

<snip>
void* my_thread(void*arg) {
    for (;;) {
        n = jack_cycle_wait(client);
        process_my_data(n);
        jack_cycle_signal(client, 0);
        do_my_other_work_if_there_is_any();
    }
}

jack_set_process_thread(client, foo_func);
</snip>

Is that the rough idea? Hmm, with the other RT loops I have in PA I
usually just dispatch a single my own events and then immediately
check the IO device again, possibly dealing with the IO stuff first,
and only after finishing that I dispatch the next of my own events and
immediately check for IO again. That way I make sure that IO always
takes priority over dispatching those events. i.e. something along the
lines of:

<snip>
void *my_thread(void *arg) {
    for (;;) {
        n = how_much_shall_i_process();
        if (n > 0) {
            process_my_data(n);
            continue;
        }
        n = how_many_events_to_dispatch();
        if (n > 0) {
            process_one_event();
            continue;
        }
        wait_for_io();
}
</snip>

So, to map this to JACK, I would prefer if jack_cycle_wait() would
also exist in a non-blocking variant. i.e. something that can return 0
if there's nothing to process, but doesn't necessarily wait.

(we probably should stop the cross-posting, though)

Lennart

--
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Ralf Mardorf]

Rui hilft mir gerade dabei dem MIDI Jitter auf die Schliche zu kommen.
Einige, nicht nur er nehmen mein Gefasel ernst. Wenn Dein Gehör nicht
ausreichend musikalisch ist und Du daher kein Interesse daran hast, dass
Linux besser wird, ist dies Deine Sache. Das man von meinem Engagement
weniger findet liegt auch daran, dass man, sobald sich Bemühungen von
mir als Wahrheit heraus gestellt haben Beiträge mit Lösungen in
deutschen Foren gerne gelöscht hat, s. ehemals kaputte Packman-Version
von JACK. Ich nehme gerne konstruktive Problemlösungen innerhalb und
außerhalb der Listen an, nur ist es impertinent unbequeme Mitteilungen
derart zu bewerten.

Warum filterst Du meine Mails nicht einfach heraus und ignorierst sie?
Fehler innerhalb Linux audio überhörst Du ja auch und ignorierst sie.

Diskussionen sollen auch ohne persönliche Angriffe funktionieren.

Florian Faber wrote:

> Ralf,
>
>  
>> Maybe this is the main problem for Linux and life in any way, we did
>> start with a bad move:
>>    
>
> Du redest von 'wir' - ich habe jetzt auf Anhieb nichts finden koennen,
> wo Du konstruktiv zu Linux Audio beigetragen hast.
>
> Ich dachte, Du wolltest Dich im Dezember in Richtung Windows
> zurueckziehen. Bitte mach das doch endlich mal und nerv uns hier nicht
> mit Deinem wirren Gefasel.
>
>
> Flo
>  

--
http://www.dailywav.com/1002/beginning.wav

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

[Stéphane Letz]

>
>> first of all.... lets assume jack is running with -p64 -n2
>> (~3ms latency)
>>
>> i am not sure if lennart is aware that jack often runs with such
>> latencies. i dont really care for event processing inside the RT  
>> loop.
>> however you cant know how many clients are following in the process
>> cycle, so you cant know a sane threshold value.
>
> But that information could be made available, couldn't it? I mean, the
> Jack server has information about the graph, so it could make that
> information available to the clients.

Hum...even if this info would be available, it does not say what  
*actual* duration would take the following clients ...

>
>> what i am asking for is that events are either passed into your RT  
>> loop
>> via lock-free fifos
>
> As mentioned, this is what happens. that lock-free q is called  
> pa_asyncmsgq.
>
> Lennart
>

I think we should go back to the beginning of the discussion: allow PA  
based audio desktop application be used in the JACK graph. It don't  
think it make sense to over-complexify JACK or JACK/PA interaction  
just to avoid a thread context switch.

Better keep the current separated simple solution, until it can be  
proven it is a real bottleneck.

Stephane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Nedko Arnaudov]

Lennart Poettering <mzynq@...> writes:

> On Thu, 18.06.09 16:09, torbenh@... (torbenh@...) wrote:
>
>> > I think org.jackaudio.service should be fine. I don't think this
>> > automatic logic needs to work on non-D-Bus jack builds. As I see it
>> > you don't need to make any changes on jack for this to work. All I
>> > need is the guarantee that by the time the service name is registered
>> > on the bus jack is fully accessible. Otherwise we had a race here: if
>> > PA looks for the org.jackaudio.service name to appear on the bus and
>> > then imemdiately connects to it while jack isn't fully accessible yet
>> > PA would fail.
>>
>> the existence of org.jackaudio.service object does not guarantee,
>> that jackd is connectable.
>
> I'd consider that brokeness in Jack then. Taking the name on the bus
> sould be the last step during initialization. Otherwise you'll always
> be in racy situations where clients try to talk to JACK while JACK is
> only half-way initialized.

I'd like to clarify something,

org.jackaudio.service exposes the controller object. It is not the server,
it is the controller, a peristent endpoint that can be used to start and
stop the server on user request. jack clients are usually not supposed
to check whether jack server is started. It will be either autostarted
or libjack "initialization" will fail if autostart is disabled and jack
server is stopped.

The dbus object name that is used for cooperation with PA is different
thing.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Lennart Poettering-15]

On Fri, 19.06.09 22:08, Nedko Arnaudov (nedko@...) wrote:

> Lennart Poettering <mzynq@...> writes:
>
> > On Thu, 18.06.09 16:09, torbenh@... (torbenh@...) wrote:
> >
> >> > I think org.jackaudio.service should be fine. I don't think this
> >> > automatic logic needs to work on non-D-Bus jack builds. As I see it
> >> > you don't need to make any changes on jack for this to work. All I
> >> > need is the guarantee that by the time the service name is registered
> >> > on the bus jack is fully accessible. Otherwise we had a race here: if
> >> > PA looks for the org.jackaudio.service name to appear on the bus and
> >> > then imemdiately connects to it while jack isn't fully accessible yet
> >> > PA would fail.
> >>
> >> the existence of org.jackaudio.service object does not guarantee,
> >> that jackd is connectable.
> >
> > I'd consider that brokeness in Jack then. Taking the name on the bus
> > sould be the last step during initialization. Otherwise you'll always
> > be in racy situations where clients try to talk to JACK while JACK is
> > only half-way initialized.
>
> I'd like to clarify something,
>
> org.jackaudio.service exposes the controller object. It is not the server,
> it is the controller, a peristent endpoint that can be used to start and
> stop the server on user request. jack clients are usually not supposed
> to check whether jack server is started. It will be either autostarted
> or libjack "initialization" will fail if autostart is disabled and jack
> server is stopped.

Hmm? I don't get this. D-Bus does automatic bus-activation anyway, why
is there a need for having a seperate controller?

> The dbus object name that is used for cooperation with PA is different
> thing.

Hmm, OK, so, what do you suggest? Introducing a new name?

Lennart

--
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Nedko Arnaudov]

Lennart Poettering <mzynq@...> writes:

> On Fri, 19.06.09 22:08, Nedko Arnaudov (nedko@...) wrote:
>
>> Lennart Poettering <mzynq@...> writes:
>>
>> > On Thu, 18.06.09 16:09, torbenh@... (torbenh@...) wrote:
>> >
>> >> > I think org.jackaudio.service should be fine. I don't think this
>> >> > automatic logic needs to work on non-D-Bus jack builds. As I see it
>> >> > you don't need to make any changes on jack for this to work. All I
>> >> > need is the guarantee that by the time the service name is registered
>> >> > on the bus jack is fully accessible. Otherwise we had a race here: if
>> >> > PA looks for the org.jackaudio.service name to appear on the bus and
>> >> > then imemdiately connects to it while jack isn't fully accessible yet
>> >> > PA would fail.
>> >>
>> >> the existence of org.jackaudio.service object does not guarantee,
>> >> that jackd is connectable.
>> >
>> > I'd consider that brokeness in Jack then. Taking the name on the bus
>> > sould be the last step during initialization. Otherwise you'll always
>> > be in racy situations where clients try to talk to JACK while JACK is
>> > only half-way initialized.
>>
>> I'd like to clarify something,
>>
>> org.jackaudio.service exposes the controller object. It is not the server,
>> it is the controller, a peristent endpoint that can be used to start and
>> stop the server on user request. jack clients are usually not supposed
>> to check whether jack server is started. It will be either autostarted
>> or libjack "initialization" will fail if autostart is disabled and jack
>> server is stopped.
>
> Hmm? I don't get this. D-Bus does automatic bus-activation anyway, why
> is there a need for having a seperate controller?

D-Bus session bus daemon autoactivates the controller when first
controller app requests access to it. And you usually dont want jack
server started when laditray (tray app that can monitor and control the
default jack server) is loaded. If some app wants to autostart the jack
server through dbus, it will just call the start method. Just like
libjack does.

>> The dbus object name that is used for cooperation with PA is different
>> thing.
>
> Hmm, OK, so, what do you suggest? Introducing a new name?

This idea (having separate dbus object for each running jack server) was
suggested by Torben and I like it. Actually this is probably the
prefered way if multi-jack-server setups are required to work in D-Bus
environment. OTOH I don't know user requirements for multi-jack-server
setups and thus I don't have strong opinion on how they should work in
D-Bus environment. If such thing is needed at all.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Jörn Nettingsmeier-5]

ralf,


it is absolutely horrible style to take a private exchange public
without the consent of everyone involved.
it is also horrible style to post in german to english speaking lists.
moreover, it is increasingly boring to be forced to listen to how people
did you wrong in some forums on the evil web.
are you aware how much good-will you are receiving already in the fact
that people refrain from constantly flaming your ass off?

your posts are usually a convoluted mess of conjecture, fact,
self-diagnosis and plain misinformation. you do not follow up on posts
if people give you a hint or request debugging data, and you constantly
sound off on topics you demonstrably know absolutely zero about.

please. go away.


jörn


--
Jörn Nettingsmeier

Verantwortlicher für Veranstaltungstechnik

Audio and event engineer
Ambisonic surround recordings

http://stackingdwarves.net
[phone]

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

[Ralf Mardorf]

Jörn Nettingsmeier wrote:

> ralf,
>
>
> it is absolutely horrible style to take a private exchange public
> without the consent of everyone involved.
> it is also horrible style to post in german to english speaking lists.
> moreover, it is increasingly boring to be forced to listen to how people
> did you wrong in some forums on the evil web.
> are you aware how much good-will you are receiving already in the fact
> that people refrain from constantly flaming your ass off?
>
> your posts are usually a convoluted mess of conjecture, fact,
> self-diagnosis and plain misinformation. you do not follow up on posts
> if people give you a hint or request debugging data, and you constantly
> sound off on topics you demonstrably know absolutely zero about.
>
> please. go away.
>
>
> jörn
>  

Offlist everything was and is resolved, before dissing me over and over
again read the thread again and reflect the content. Some people might
work on topics that might be more serious for real-time than dbus and pa.

--
http://www.dailywav.com/1002/beginning.wav

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