Nabble - Jack Audio

RFC: "enum" parameters patch

2008-10-12T09:09:45Z

I think my work is for fixing ticket #83 is done.

Summary from Trac:
------------
Currently there is no way to describe possible values of parameter. So
far the solution is to define normal parameter (char, string or integer)
and describe possible values in the long comment. This approach however
does not allow generated UIs to show combobox/radiobutton widgets for
selecting one of several possible values.

Some examples are dither parameter in jack1, ALSA midi type selection
(-X parameter). Buffer size is probably in this category too, because it
must be power of 2 and has min and max values, implied by hardware
(lower level driver).
------------

The proposed changeset can be seen here (colored though gitweb):

http://repo.or.cz/w/jack2.git?a=commitdiff;h=821b3b02219ce7e40478e52a9a2102ea403e93fb;hp=bcf3493bdebfdf6279c962c91776ad01f9be74e6

or here (as regular patch file):

http://nedko.arnaudov.name/soft/jack/jack2-enum-params.patch

The topic branch can be seen here:

http://repo.or.cz/w/jack2.git?a=shortlog;h=refs/heads/enum-params

In changeset for jack2 I've implemented, amoung base functionality,
enum constraints for some parameters of ALSA driver:
* device (composed runtime, code based on qjackctl code for this)
* dither
* midi-driver

Base functionality changes are:
* driver interface change (backward compatible at source level)
* new functions are added to control API
* new methods are added to D-Bus configure interface

sletz, if you decide to commit this as it is, please let me do it, I
want to test how well git-svn will handle topic branches in git that are
commited upstream through git-svn dcommit functionality.

As for jack1, I have motivation to backport this, but I doubt there is
good reason for doing so without jack1 dbus.patch being accpted, a step
that will allow this functionality to be usable by an already existing
control application.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

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

attachment0 (194 bytes) Download Attachment

From forum: Jackit

Re: midi port names

2008-10-12T08:48:50Z

Rui Nuno Capela <rncbc@...> writes:

> that's the original issue with the jack-midi alsa backend, not
> qjackctl's: it puts all midi ports under the common 'system'/'alsa_pcm'
> client name, instead of separating it by proper application clients, as
> you and i agree it would be righter. unfortunately it's not the way
> jack-midi alsa backend sorts it and i, as qjackctl's author, am just
> helpless about it :(

I "workarounded" this issue in lpatchage, when operating over a2jmidid,
the out of server variant of "-X seq". As can be seen in this screenhost:

http://nedko.arnaudov.name/tmp/ladi-patchage-20080802-a2jmidid-integration.png

lash_synth is ALSA seq application, as opposed to non-sequencer and
system midi ports that are native JACK MIDI.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

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

attachment0 (194 bytes) Download Attachment

From forum: Jackit

Re: midi port names

2008-10-12T06:27:58Z

Rui Nuno Capela wrote:

> Ralf Mardorf wrote:
>
>> Rui Nuno Capela wrote:
>>
>>> Ralf Mardorf wrote:
>>>
>>>
>>>> Hi Rui :)
>>>>
>>>> JFYI the CVS version 0.3.3.6 of QjackCtl visually conveys to be fine for
>>>> Suse 11.0. I had no time to check out if it will work.
>>>>
>>>> When selecting 'First' for aliases, the aliases are correctly shown in
>>>> the Connect MIDI tab.
>>>>
>>>> It's not a problem, but it's displayed 'alsa_pcm' instead of
>>>> 'alsa_midi'. All entries can be renamed, so there's definitive no bug
>>>> for first aliases in the MIDI tab.
>>>>
>>>> There's one drawback. While Hydrogen's client alias is including
>>>> 'Hydrogen', Rosegarden's and Qsampler's aliases are missing the
>>>> information about the application they are from.
>>>>
>>>> It would be better to have the application 'folders' like the Audio and
>>>> ALSA tabs have got, instead of showing all of them in the 'alsa_pcm'
>>>> (resp. 'alsa_midi') 'folder'.
>>>>
>>>>
>>>>
>>> unless being a bug, qjackctl shows exactly what is set by (lib)jack alsa
>>> backend when listing client port names. in fact, 'alsa_pcm' is the
>>> actual client name's first alias for jack-midi "system".
>>>
>>> you just can't change that naming from qjackctl, but you can set an
>>> alternate name as a qjackctl own alias though
>>> (Setup/Display/Connections/Enable client/port aliases editing (rename))
>>>
>>>
>>> confused?
>>>
>>>
>> No I'm not :)
>>
>> as I've written, the rename function also is fine, but there's no need
>> to rename it from 'alsa_pcm' to 'alsa_midi', because the needed
>> information is 'alsa' ;). I'll go on writing 'alsa_...' instead of
>> 'alsa_pcm'.
>>
>> It's plausible that the bridged ALSA clients are shown in a (let me call
>> it a) 'folder' named 'alsa_...'.
>>
>> It's also not confusing when running Hydrogen, Rosegarden and Qsampler
>> that they are shown in the 'folder' named 'alsa_...', because I know the
>> port's names. But this might become unclear when running many
>> applications using aliases, that by default don't use the applications
>> name they are from, in the aliases names.
>>
>> The Audio tab has got 'folders' for each application and it would become
>> more obvious if each client got it's own 'folder' for the MIDI tab too.
>> It isn't a help to rename the ports after restarting a session. Just my
>> 2 cents.
>>
>>
>
> that's the original issue with the jack-midi alsa backend, not
> qjackctl's: it puts all midi ports under the common 'system'/'alsa_pcm'
> client name, instead of separating it by proper application clients, as
> you and i agree it would be righter. unfortunately it's not the way
> jack-midi alsa backend sorts it and i, as qjackctl's author, am just
> helpless about it :(
>
> cheers
>

I've got respect for anyone programing for Linux. I'm not fine with
doing this.
I don't know how much work it is to write a rout, that will

diff the first alias for each MIDI tab port with the ALSA tab ports

and if alias names are equal and if there will be no second alias with
the same name,

to copy the corresponding 'client/folder' name from the ALSA tab to the
MIDI tab (and to sort the corresponding ports to the
'cklient/folders'.). Just visually for the MIDI tab.

Cheers,
Ralf

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

signature.asc (268 bytes) Download Attachment

From forum: Jackit

Re: midi port names

2008-10-12T05:04:12Z

Ralf Mardorf wrote:

> Rui Nuno Capela wrote:
>> Ralf Mardorf wrote:
>>
>>> Hi Rui :)
>>>
>>> JFYI the CVS version 0.3.3.6 of QjackCtl visually conveys to be fine for
>>> Suse 11.0. I had no time to check out if it will work.
>>>
>>> When selecting 'First' for aliases, the aliases are correctly shown in
>>> the Connect MIDI tab.
>>>
>>> It's not a problem, but it's displayed 'alsa_pcm' instead of
>>> 'alsa_midi'. All entries can be renamed, so there's definitive no bug
>>> for first aliases in the MIDI tab.
>>>
>>> There's one drawback. While Hydrogen's client alias is including
>>> 'Hydrogen', Rosegarden's and Qsampler's aliases are missing the
>>> information about the application they are from.
>>>
>>> It would be better to have the application 'folders' like the Audio and
>>> ALSA tabs have got, instead of showing all of them in the 'alsa_pcm'
>>> (resp. 'alsa_midi') 'folder'.
>>>
>>>
>> unless being a bug, qjackctl shows exactly what is set by (lib)jack alsa
>> backend when listing client port names. in fact, 'alsa_pcm' is the
>> actual client name's first alias for jack-midi "system".
>>
>> you just can't change that naming from qjackctl, but you can set an
>> alternate name as a qjackctl own alias though
>> (Setup/Display/Connections/Enable client/port aliases editing (rename))
>>
>
>> confused?
>>
>
> No I'm not :)
>
> as I've written, the rename function also is fine, but there's no need
> to rename it from 'alsa_pcm' to 'alsa_midi', because the needed
> information is 'alsa' ;). I'll go on writing 'alsa_...' instead of
> 'alsa_pcm'.
>
> It's plausible that the bridged ALSA clients are shown in a (let me call
> it a) 'folder' named 'alsa_...'.
>
> It's also not confusing when running Hydrogen, Rosegarden and Qsampler
> that they are shown in the 'folder' named 'alsa_...', because I know the
> port's names. But this might become unclear when running many
> applications using aliases, that by default don't use the applications
> name they are from, in the aliases names.
>
> The Audio tab has got 'folders' for each application and it would become
> more obvious if each client got it's own 'folder' for the MIDI tab too.
> It isn't a help to rename the ports after restarting a session. Just my
> 2 cents.
>

that's the original issue with the jack-midi alsa backend, not
qjackctl's: it puts all midi ports under the common 'system'/'alsa_pcm'
client name, instead of separating it by proper application clients, as
you and i agree it would be righter. unfortunately it's not the way
jack-midi alsa backend sorts it and i, as qjackctl's author, am just
helpless about it :(

cheers
--
rncbc aka Rui Nuno Capela
rncbc@...
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

From forum: Jackit

Re: midi port names

2008-10-12T04:26:41Z

Rui Nuno Capela wrote:

> Ralf Mardorf wrote:
>
>> Hi Rui :)
>>
>> JFYI the CVS version 0.3.3.6 of QjackCtl visually conveys to be fine for
>> Suse 11.0. I had no time to check out if it will work.
>>
>> When selecting 'First' for aliases, the aliases are correctly shown in
>> the Connect MIDI tab.
>>
>> It's not a problem, but it's displayed 'alsa_pcm' instead of
>> 'alsa_midi'. All entries can be renamed, so there's definitive no bug
>> for first aliases in the MIDI tab.
>>
>> There's one drawback. While Hydrogen's client alias is including
>> 'Hydrogen', Rosegarden's and Qsampler's aliases are missing the
>> information about the application they are from.
>>
>> It would be better to have the application 'folders' like the Audio and
>> ALSA tabs have got, instead of showing all of them in the 'alsa_pcm'
>> (resp. 'alsa_midi') 'folder'.
>>
>>
>
> unless being a bug, qjackctl shows exactly what is set by (lib)jack alsa
> backend when listing client port names. in fact, 'alsa_pcm' is the
> actual client name's first alias for jack-midi "system".
>
> you just can't change that naming from qjackctl, but you can set an
> alternate name as a qjackctl own alias though
> (Setup/Display/Connections/Enable client/port aliases editing (rename))
>

> confused?
>

No I'm not :)

as I've written, the rename function also is fine, but there's no need
to rename it from 'alsa_pcm' to 'alsa_midi', because the needed
information is 'alsa' ;). I'll go on writing 'alsa_...' instead of
'alsa_pcm'.

It's plausible that the bridged ALSA clients are shown in a (let me call
it a) 'folder' named 'alsa_...'.

It's also not confusing when running Hydrogen, Rosegarden and Qsampler
that they are shown in the 'folder' named 'alsa_...', because I know the
port's names. But this might become unclear when running many
applications using aliases, that by default don't use the applications
name they are from, in the aliases names.

The Audio tab has got 'folders' for each application and it would become
more obvious if each client got it's own 'folder' for the MIDI tab too.
It isn't a help to rename the ports after restarting a session. Just my
2 cents.

Cheers,
Ralf

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

signature.asc (268 bytes) Download Attachment

From forum: Jackit

Re: midi port names

2008-10-12T03:37:56Z

Ralf Mardorf wrote:

> Hi Rui :)
>
> JFYI the CVS version 0.3.3.6 of QjackCtl visually conveys to be fine for
> Suse 11.0. I had no time to check out if it will work.
>
> When selecting 'First' for aliases, the aliases are correctly shown in
> the Connect MIDI tab.
>
> It's not a problem, but it's displayed 'alsa_pcm' instead of
> 'alsa_midi'. All entries can be renamed, so there's definitive no bug
> for first aliases in the MIDI tab.
>
> There's one drawback. While Hydrogen's client alias is including
> 'Hydrogen', Rosegarden's and Qsampler's aliases are missing the
> information about the application they are from.
>
> It would be better to have the application 'folders' like the Audio and
> ALSA tabs have got, instead of showing all of them in the 'alsa_pcm'
> (resp. 'alsa_midi') 'folder'.
>

unless being a bug, qjackctl shows exactly what is set by (lib)jack alsa
backend when listing client port names. in fact, 'alsa_pcm' is the
actual client name's first alias for jack-midi "system".

you just can't change that naming from qjackctl, but you can set an
alternate name as a qjackctl own alias though
(Setup/Display/Connections/Enable client/port aliases editing (rename))

confused?

cheers
--
rncbc aka Rui Nuno Capela
rncbc@...
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

From forum: Jackit

Re: midi port names

2008-10-11T20:16:45Z

The meter reads, as it is should, the sum (integral) of all the power inside
the filter. The noise floor on the panadapter will ALWAYS be less than the
meter as a result. This is correct and is why the meter is about the most
accurate one in amateur radio.

Bob

ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"Trample the slow .... Hurdle the dead"

-----Original Message-----
From: jack-devel-bounces@...
[mailto:jack-devel-bounces@...] On Behalf Of Ralf Mardorf
Sent: Saturday, October 11, 2008 9:07 PM
To: Rui Nuno Capela
Cc: jack-devel@...
Subject: Re: [Jack-Devel] midi port names

Hi Rui :)

JFYI the CVS version 0.3.3.6 of QjackCtl visually conveys to be fine for
Suse 11.0. I had no time to check out if it will work.

When selecting 'First' for aliases, the aliases are correctly shown in the
Connect MIDI tab.

It's not a problem, but it's displayed 'alsa_pcm' instead of 'alsa_midi'.
All entries can be renamed, so there's definitive no bug for first aliases
in the MIDI tab.

There's one drawback. While Hydrogen's client alias is including 'Hydrogen',
Rosegarden's and Qsampler's aliases are missing the information about the
application they are from.

It would be better to have the application 'folders' like the Audio and ALSA
tabs have got, instead of showing all of them in the 'alsa_pcm'
(resp. 'alsa_midi') 'folder'.

Thank you!

Cheers,
Ralf

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

From forum: Jackit

Re: midi port names

2008-10-11T18:07:24Z

Hi Rui :)

JFYI the CVS version 0.3.3.6 of QjackCtl visually conveys to be fine for
Suse 11.0. I had no time to check out if it will work.

When selecting 'First' for aliases, the aliases are correctly shown in
the Connect MIDI tab.

It's not a problem, but it's displayed 'alsa_pcm' instead of
'alsa_midi'. All entries can be renamed, so there's definitive no bug
for first aliases in the MIDI tab.

There's one drawback. While Hydrogen's client alias is including
'Hydrogen', Rosegarden's and Qsampler's aliases are missing the
information about the application they are from.

It would be better to have the application 'folders' like the Audio and
ALSA tabs have got, instead of showing all of them in the 'alsa_pcm'
(resp. 'alsa_midi') 'folder'.

Thank you!

Cheers,
Ralf

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

signature.asc (268 bytes) Download Attachment

From forum: Jackit

Re: thread_init_callback

2008-10-10T03:19:49Z

Le 9 oct. 08 à 22:29, Fons Adriaensen a écrit :

>> From jack.h:
>
>
> * Tell JACK to call thread_init_callback once just after
> * the creation of the thread in which all other callbacks
> * will be handled.
>
>
> Now in jackdmp/jack2 there are *two* such threads IIRC.
> Which one is meant here ? If it's the one doing the
> process() callback, then this description should be
> modified.
>
> Ciao,
>

Actually in jack2 the init callback is called in *both* threads.... it
was needed by Ardour AFAIK

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

From forum: Jackit

thread_init_callback

2008-10-09T13:29:25Z

>From jack.h:

* Tell JACK to call thread_init_callback once just after
* the creation of the thread in which all other callbacks
* will be handled.

Now in jackdmp/jack2 there are *two* such threads IIRC.
Which one is meant here ? If it's the one doing the
process() callback, then this description should be
modified.

Ciao,

--
FA

Follie! Follie! Delirio vano e' questo!
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

From forum: Jackit

Re: jack functions thread safety

2008-10-08T13:09:08Z

Fons Adriaensen wrote:

> On Wed, Oct 08, 2008 at 12:20:39AM +0200, Paul Davis wrote:
>
>> On Wed, 2008-10-08 at 00:10 +0200, Fons Adriaensen wrote:
>>
>>> The context switches are within the same process, so they should
>>> not involve too much work... Still, unless I had the time to test
>>> this extensively, I'd opt for a single client solution.
>> thats true if they have no JACK input ports. otherwise, the clients
>> could be connected to other JACK clients and then we go back and forth.
>>
>> but yes, you're right and i should have caught that.
>
> IIRC, the application is a multi-out player, no inputs.

The server works with actually no connections between clients,
everything is handled on each process callback. I am sure there are
better ways of doing this, but this is a first working prototype, and it
may actually even run using the dummy driver.

I'll let you know how it works after I'm done and what's the performance
hit.

Thanks for all the advice.
Juan-Pablo
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

From forum: Jackit

jackmp : fix a rev 2957 introduced bug...

2008-10-08T08:30:06Z

For jackdmp, get the latest SVN version, (rev 2957 has a important
issue) :

rev 2965: Fix a SMP related bug introduced in rev 2957 : remove the
__SMP__ flag and define LOCK for SMP in all cases.

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

From forum: Jackit

Re: jack functions thread safety

2008-10-07T16:04:25Z

On Wed, Oct 08, 2008 at 12:20:39AM +0200, Paul Davis wrote:

> On Wed, 2008-10-08 at 00:10 +0200, Fons Adriaensen wrote:
>
> > The context switches are within the same process, so they should
> > not involve too much work... Still, unless I had the time to test
> > this extensively, I'd opt for a single client solution.
>
> thats true if they have no JACK input ports. otherwise, the clients
> could be connected to other JACK clients and then we go back and forth.
>
> but yes, you're right and i should have caught that.

IIRC, the application is a multi-out player, no inputs.

Ciao,

--
FA

Follie! Follie! Delirio vano e' questo!
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

From forum: Jackit

Re: State of Jack

2008-10-07T15:34:34Z

Paul Davis wrote:

> On Wed, 2008-09-10 at 09:49 +0200, Quentin Harley wrote:
>
>> We have been parked on 0.109.2 for quite a while now, and I am sure
>> quite a few fixes to the current server got implemented in the 7 months
>> since. I am a Debian user and a tester for 64-studio, thus we are
>> waiting for the crucial release to be able to go ahead...
>>
>> Paul said something about a release being close. Any ETA as of yet?
>>
>
> Just as soon as I get the ardour 2.X->3.0 merge done, it will be my next
> task. Might be 2-3 days work.
>
>

Seems it might have been a bit more than 2-3 days work ;-)

Jack is not the little connecting app it used to be any more, but better
for it.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

From forum: Jackit

Re: jack functions thread safety

2008-10-07T15:20:39Z

On Wed, 2008-10-08 at 00:10 +0200, Fons Adriaensen wrote:

> On Tue, Oct 07, 2008 at 11:58:20PM +0200, Paul Davis wrote:
> > On Tue, 2008-10-07 at 14:46 -0700, Juan-Pablo Caceres wrote:
> >
> > > That makes total sense. Thanks for the explanation. The static mutexes
> > > worked perfectly, now I am testing with 60 stereo clients in a thread
> > > pool, each of them sending and receiving UDP uncompressed audio, in two
> > > 4core machines.
> >
> > other than ease of code development, there is little argument for this
> > design. you are requiring 60+1 context switches per interrupt from the
> > audio interface, instead of just 1+1 in the case of a client that
> > handles the "multiplexing" internally. its great that it works for you,
> > but its not really very good engineering. probably.
>
> The context switches are within the same process, so they should
> not involve too much work... Still, unless I had the time to test
> this extensively, I'd opt for a single client solution.

thats true if they have no JACK input ports. otherwise, the clients
could be connected to other JACK clients and then we go back and forth.

but yes, you're right and i should have caught that.

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

From forum: Jackit

Re: jack functions thread safety

2008-10-07T15:10:42Z

On Tue, Oct 07, 2008 at 11:58:20PM +0200, Paul Davis wrote:

> On Tue, 2008-10-07 at 14:46 -0700, Juan-Pablo Caceres wrote:
>
> > That makes total sense. Thanks for the explanation. The static mutexes
> > worked perfectly, now I am testing with 60 stereo clients in a thread
> > pool, each of them sending and receiving UDP uncompressed audio, in two
> > 4core machines.
>
> other than ease of code development, there is little argument for this
> design. you are requiring 60+1 context switches per interrupt from the
> audio interface, instead of just 1+1 in the case of a client that
> handles the "multiplexing" internally. its great that it works for you,
> but its not really very good engineering. probably.

The context switches are within the same process, so they should
not involve too much work... Still, unless I had the time to test
this extensively, I'd opt for a single client solution.

Ciao,

--
FA

Follie! Follie! Delirio vano e' questo!
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

From forum: Jackit

Re: jack functions thread safety

2008-10-07T15:03:34Z

On Tue, 2008-10-07 at 23:58 +0200, Paul Davis wrote:

and to expand a bit: JACK was designed with the assumption that although
context switching is fast, it still has real costs. we were happy to
find it could be done fast enough to make JACK's process-level
separation of clients work, but we didn't expect that it would be fast
enough to scale to arbitrary numbers of clients, particularly not if the
working set (number of pages of memory required for code+data inside the
process() callback) was larger in several or all clients. in those
cases, the context switching has much more significant costs on most
modern h/w (far exceeding the register save/restore stuff), and this can
cripple JACK with respect to low latency execution.

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

From forum: Jackit

Re: jack functions thread safety

2008-10-07T14:58:20Z

On Tue, 2008-10-07 at 14:46 -0700, Juan-Pablo Caceres wrote:

> That makes total sense. Thanks for the explanation. The static mutexes
> worked perfectly, now I am testing with 60 stereo clients in a thread
> pool, each of them sending and receiving UDP uncompressed audio, in two
> 4core machines.

other than ease of code development, there is little argument for this
design. you are requiring 60+1 context switches per interrupt from the
audio interface, instead of just 1+1 in the case of a client that
handles the "multiplexing" internally. its great that it works for you,
but its not really very good engineering. probably.

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

From forum: Jackit

Re: jack functions thread safety

2008-10-07T14:51:54Z

On Tue, Oct 07, 2008 at 11:37:02PM +0200, Paul Davis wrote:

> they should all be thread safe because once you have a JACK client, all
> calls operate exclusively on your client structure, or they are calls
> which must inherently be MT-safe for JACK's own "protection". the
> problem with jack_client_open() is that unlike all other calls, there is
> no client structure yet, and JACK is operating on a single data
> structure and is not expecting thread collisions ....

They are to be expected: the list of existing client names
(to be checked for each new client) has to be 'global'...

Ciao,

--
FA

Follie! Follie! Delirio vano e' questo!
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

From forum: Jackit

Re: jack functions thread safety

2008-10-07T14:49:32Z

On Tue, Oct 7, 2008 at 4:46 PM, Juan-Pablo Caceres
<jcaceres@...> wrote:

> Hi Paul
>
> Paul Davis wrote:
>>
>> On Tue, 2008-10-07 at 14:33 -0700, Juan-Pablo Caceres wrote:
>>>
>>> Hi Stéphane,
>>>
>>> Stéphane Letz wrote:
>>>>
>>>> Ok, so jack_client_open/jack_client_close functions are not thread safe,
>>>> (at least some "first client init"/"last client destroy" code is not MT
>>>> safe) and this client renaming thing also. Not sure the situation is really
>>>> better in jack1, for the same kind of reasons.
>>>>
>>>> So the general question now: should the jack API be guaranted to be
>>>> thread safe? or the kind of "non so common case" with this multi-threaded
>>>> open could he handled in your code with mutexes?
>>>
>>> Yeah, that's what I am doing right now. I added a static mutex in my
>>> class to protect jack unsafe functions. The problem is since I didn't know
>>> what functions weren't thread safe, I didn't know where to put the mutexes.
>>> Using mutexes in all jack functions would mean a serious performance hit, I
>>> think, specially in jackdmp, so I wanted to avoid that.
>>
>> they should all be thread safe because once you have a JACK client, all
>> calls operate exclusively on your client structure, or they are calls
>> which must inherently be MT-safe for JACK's own "protection".
>
> Yeah, I meant that I didn't want to put mutexes when I call the function, I
> understand that they should be MT-safe "inside"...
>
>> the
>> problem with jack_client_open() is that unlike all other calls, there is
>> no client structure yet, and JACK is operating on a single data
>> structure and is not expecting thread collisions ....
>
> That makes total sense. Thanks for the explanation. The static mutexes
> worked perfectly, now I am testing with 60 stereo clients in a thread pool,
> each of them sending and receiving UDP uncompressed audio, in two 4core
> machines.

We should probably fix jack_client_open() to be thread-safe on its own.
I don't recall thinking about that when I originally wrote it. I suspect
jack_client_new(), which is deprecated, probably has the same problem.
--
joq
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

From forum: Jackit

Re: jack functions thread safety

2008-10-07T14:46:50Z

Hi Paul

Paul Davis wrote:

> On Tue, 2008-10-07 at 14:33 -0700, Juan-Pablo Caceres wrote:
>> Hi Stéphane,
>>
>> Stéphane Letz wrote:
>>> Ok, so jack_client_open/jack_client_close functions are not thread safe,
>>> (at least some "first client init"/"last client destroy" code is not MT
>>> safe) and this client renaming thing also. Not sure the situation is
>>> really better in jack1, for the same kind of reasons.
>>>
>>> So the general question now: should the jack API be guaranted to be
>>> thread safe? or the kind of "non so common case" with this
>>> multi-threaded open could he handled in your code with mutexes?
>> Yeah, that's what I am doing right now. I added a static mutex in my
>> class to protect jack unsafe functions. The problem is since I didn't
>> know what functions weren't thread safe, I didn't know where to put the
>> mutexes. Using mutexes in all jack functions would mean a serious
>> performance hit, I think, specially in jackdmp, so I wanted to avoid that.
>
> they should all be thread safe because once you have a JACK client, all
> calls operate exclusively on your client structure, or they are calls
> which must inherently be MT-safe for JACK's own "protection".

Yeah, I meant that I didn't want to put mutexes when I call the
function, I understand that they should be MT-safe "inside"...

> the
> problem with jack_client_open() is that unlike all other calls, there is
> no client structure yet, and JACK is operating on a single data
> structure and is not expecting thread collisions ....

That makes total sense. Thanks for the explanation. The static mutexes
worked perfectly, now I am testing with 60 stereo clients in a thread
pool, each of them sending and receiving UDP uncompressed audio, in two
4core machines.

Juan-Pablo

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

From forum: Jackit

Re: jack functions thread safety

2008-10-07T14:37:02Z

On Tue, 2008-10-07 at 14:33 -0700, Juan-Pablo Caceres wrote:

> Hi Stéphane,
>
> Stéphane Letz wrote:
> >
> > Ok, so jack_client_open/jack_client_close functions are not thread safe,
> > (at least some "first client init"/"last client destroy" code is not MT
> > safe) and this client renaming thing also. Not sure the situation is
> > really better in jack1, for the same kind of reasons.
> >
> > So the general question now: should the jack API be guaranted to be
> > thread safe? or the kind of "non so common case" with this
> > multi-threaded open could he handled in your code with mutexes?
>
> Yeah, that's what I am doing right now. I added a static mutex in my
> class to protect jack unsafe functions. The problem is since I didn't
> know what functions weren't thread safe, I didn't know where to put the
> mutexes. Using mutexes in all jack functions would mean a serious
> performance hit, I think, specially in jackdmp, so I wanted to avoid that.

they should all be thread safe because once you have a JACK client, all
calls operate exclusively on your client structure, or they are calls
which must inherently be MT-safe for JACK's own "protection". the
problem with jack_client_open() is that unlike all other calls, there is
no client structure yet, and JACK is operating on a single data
structure and is not expecting thread collisions ....

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

From forum: Jackit

Re: jack functions thread safety

2008-10-07T14:33:21Z

Hi Stéphane,

Stéphane Letz wrote:
>
> Ok, so jack_client_open/jack_client_close functions are not thread safe,
> (at least some "first client init"/"last client destroy" code is not MT
> safe) and this client renaming thing also. Not sure the situation is
> really better in jack1, for the same kind of reasons.
>
> So the general question now: should the jack API be guaranted to be
> thread safe? or the kind of "non so common case" with this
> multi-threaded open could he handled in your code with mutexes?

Yeah, that's what I am doing right now. I added a static mutex in my
class to protect jack unsafe functions. The problem is since I didn't
know what functions weren't thread safe, I didn't know where to put the
mutexes. Using mutexes in all jack functions would mean a serious
performance hit, I think, specially in jackdmp, so I wanted to avoid that.

Answering your general question, I know that what I am doing is not
common, but that's why we are here, to push the boundaries right ;)? I
was just about to get rid of jack in the server and write my own
scheduler instead, but I would much prefer to use Jack, and now it seems
to be working. I think in the future more a more people will do this
multi-threaded stuff, as you guys have been doing in Grame for many
years now.

If at least the documentation would list the functions that are not
thread safe, adding static mutexes is actually really simple though.

Thought?
Thanks again!
Juan-Pablo
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

From forum: Jackit

Re: jack functions thread safety

2008-10-07T14:01:35Z

Le 7 oct. 08 à 22:27, Juan-Pablo Caceres a écrit :

> Stéphane Letz wrote:
>> Le 6 oct. 08 à 23:38, Juan-Pablo Caceres a écrit :
>>> Hi Paul,
>>>
>>> Thanks for your answer. To illustrate the problem, I am putting
>>> the following code in a thread:
>>>
>>> //
>>> ====================================================================
>>> ==
>>> {
>>> jack_client_t* mClient;
>>> const char* client_name = "JackThread";
>>> const char* server_name = NULL;
>>> jack_options_t options = JackNoStartServer;
>>> jack_status_t status;
>>>
>>> mClient = jack_client_open (client_name, options, &status,
>>> server_name);
>>>
>>> if (mClient == NULL) {
>>> fprintf (stderr, "jack_client_open() failed, "
>>> "status = 0x%2.0x\n", status);
>>> if (status & JackServerFailed) {
>>> fprintf (stderr, "Unable to connect to JACK server\n");
>>> }
>>> std::exit(1);
>>> }
>>> if (status & JackServerStarted) {
>>> fprintf (stderr, "JACK server started\n");
>>> }
>>> if (status & JackNameNotUnique) {
>>> client_name = jack_get_client_name(mClient);
>>> fprintf (stderr, "unique name `%s' assigned\n", client_name);
>>> }
>>> }
>>> //
>>> ====================================================================
>>> ==
>>>
>>> Now, if I execute it once, everything works fine, however, if I
>>> instantiate several worker threads with that code, I get the error:
>>>
>>> ----
>>> Cannot open JackThread client
>>> jack_client_open() failed, status = 0x21
>>> Cannot open JackThread client
>>> ----
>>>
>>> Now, if I just sleep for a second before starting the next worker
>>> thread, everything works fine.
>>>
>>> Any ideas why this is happening?
>>>
>>> Thanks again,
>>> Juan-Pablo
>>>
>> Please start jack server in verbose mode (-v) and send the log on
>> server and client side.
>
> Verbose output follows:
>
> CLIENT:
>
> Jack: JackClient::SetupDriverSync driver sem in flush mode
>

Ok, so jack_client_open/jack_client_close functions are not thread
safe, (at least some "first client init"/"last client destroy" code
is not MT safe) and this client renaming thing also. Not sure the
situation is really better in jack1, for the same kind of reasons.

So the general question now: should the jack API be guaranted to be
thread safe? or the kind of "non so common case" with this multi-
threaded open could he handled in your code with mutexes?

Stephane

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

From forum: Jackit

Re: jack functions thread safety

2008-10-07T13:29:37Z

Stéphane Letz wrote:

>
> Le 6 oct. 08 à 23:38, Juan-Pablo Caceres a écrit :
>
>> Hi Paul,
>>
>> Thanks for your answer. To illustrate the problem, I am putting the
>> following code in a thread:
>>
>> //======================================================================
>> {
>> jack_client_t* mClient;
>> const char* client_name = "JackThread";
>> const char* server_name = NULL;
>> jack_options_t options = JackNoStartServer;
>> jack_status_t status;
>>
>> mClient = jack_client_open (client_name, options, &status, server_name);
>>
>> if (mClient == NULL) {
>> fprintf (stderr, "jack_client_open() failed, "
>> "status = 0x%2.0x\n", status);
>> if (status & JackServerFailed) {
>> fprintf (stderr, "Unable to connect to JACK server\n");
>> }
>> std::exit(1);
>> }
>> if (status & JackServerStarted) {
>> fprintf (stderr, "JACK server started\n");
>> }
>> if (status & JackNameNotUnique) {
>> client_name = jack_get_client_name(mClient);
>> fprintf (stderr, "unique name `%s' assigned\n", client_name);
>> }
>> }
>> //======================================================================
>>
>> Now, if I execute it once, everything works fine, however, if I
>> instantiate several worker threads with that code, I get the error:
>>
>> ----
>> Cannot open JackThread client
>> jack_client_open() failed, status = 0x21
>> Cannot open JackThread client
>> ----
>>
>> Now, if I just sleep for a second before starting the next worker
>> thread, everything works fine.
>>
>> Any ideas why this is happening?
>>
>> Thanks again,
>> Juan-Pablo
>>
>
> Please start jack server in verbose mode (-v) and send the log on server
> and client side.

Verbose output follows:

CLIENT:

Jack: JackClient::SetupDriverSync driver sem in flush mode
Jack: Connect: addr.sun_path /dev/shm/jack_default_0
Jack: JackClientSocket::Close
Jack: JackLibClient::JackLibClient table = 81a2518
Jack: JackLibClient::Open JackThread
Jack: JackSocketClientChannel::Open name = JackThread
Jack: Connect: addr.sun_path /dev/shm/jack_default_0
Jack: JackClientSocket::Close
Jack: JackLibClient::JackLibClient table = 81a2518
Jack: JackLibClient::Open JackThread
Jack: JackSocketClientChannel::Open name = JackThread
Jack: Connect: addr.sun_path /dev/shm/jack_default_0
Jack: JackClientSocket::Close
Jack: JackLibClient::JackLibClient table = 81a2518
Jack: JackLibClient::Open JackThread
Jack: JackSocketClientChannel::Open name = JackThread
Jack: Connect: addr.sun_path /dev/shm/jack_default_0
Jack: JackClientSocket::Close
Jack: JackLibClient::JackLibClient table = 81a2518
Jack: JackLibClient::Open JackThread
Jack: JackSocketClientChannel::Open name = JackThread
Jack: Connect: addr.sun_path /dev/shm/jack_default_0
Jack: JackClientSocket::Close
Jack: JackLibClient::JackLibClient table = 81a2518
Jack: JackLibClient::Open JackThread
Jack: JackSocketClientChannel::Open name = JackThread
Jack: Connect: addr.sun_path /dev/shm/jack_default_0
Jack: JackClientSocket::Close
Jack: JackLibClient::JackLibClient table = 81a2518
Jack: JackLibClient::Open JackThread
Jack: JackSocketClientChannel::Open name = JackThread
Jack: Connect: addr.sun_path /dev/shm/jack_default_0
Cannot open JackThread client
Jack: JackSocketClientChannel::Stop
Jack: JackPosixThread::Kill
Jack: JackClientSocket::Close
Jack: JackClientSocket::Close
Jack: JackLibClient::~JackLibClient
jack_client_open() failed, status = 0x21
Jack: JackClientSocket::Close
Jack: JackLibClient::JackLibClient table = 81a2518
Jack: JackLibClient::Open JackThread
Jack: JackSocketClientChannel::Open name = JackThread
Jack: Connect: addr.sun_path /dev/shm/jack_default_0

SERVER:

Previous message bounced, because it was too long, it's waiting for
moderator...
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

From forum: Jackit

Re: jack functions thread safety

2008-10-07T11:19:42Z

Paul Davis wrote:
> On Mon, 2008-10-06 at 14:38 -0700, Juan-Pablo Caceres wrote:
>> Hi Paul,
>>
>> Thanks for your answer. To illustrate the problem, I am putting the
>> following code in a thread:
>
> What version of JACK?
>
>

I am using these packets, at CCRMA:
jack-audio-connection-kit-devel-1.90-0.svn2957.1.fc9.ccrma.i386
jack-audio-connection-kit-1.90-0.svn2957.1.fc9.ccrma.i386

It should be the jackdmp version,

Juan-Pablo

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

From forum: Jackit

Re: periodic drop-outs on asus EeePC 900

2008-10-07T08:30:43Z

On Tue, 2008-10-07 at 17:27 +0200, Jonatan Liljedahl wrote:

> Jack O'Quin wrote:
> > On Tue, Oct 7, 2008 at 10:38 AM, Jamie McLaughlin
> > <j.mclaughlin@...> wrote:
> >> Hmm. This is a really interesting problem. Can I ask which distro
> >> you're using? Is it the default one which came on the Eee?
> >
> > Also, are you running jackd in realtime (-R) mode?
>
> Yes. And as I said I've tried raising the realtime priority from the
> default. I've checked with ps -ceLf that it actually runs in realtime
> (FF). I've tried different settings for frames/period and
> periods/buffer. The dropouts are happening in a regular interval, one at
> a time.

you may need a custom kernel to debug this. there are kernel options
allowing debugging of latency issues.

--p

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

From forum: Jackit

Re: periodic drop-outs on asus EeePC 900

2008-10-07T08:27:53Z

Jack O'Quin wrote:
> On Tue, Oct 7, 2008 at 10:38 AM, Jamie McLaughlin
> <j.mclaughlin@...> wrote:
>> Hmm. This is a really interesting problem. Can I ask which distro
>> you're using? Is it the default one which came on the Eee?
>
> Also, are you running jackd in realtime (-R) mode?

Yes. And as I said I've tried raising the realtime priority from the
default. I've checked with ps -ceLf that it actually runs in realtime
(FF). I've tried different settings for frames/period and
periods/buffer. The dropouts are happening in a regular interval, one at
a time.

--
/Jonatan [ http://kymatica.com ]
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

From forum: Jackit

Re: periodic drop-outs on asus EeePC 900

2008-10-07T08:21:55Z

Jamie McLaughlin wrote:
> Hmm. This is a really interesting problem. Can I ask which distro you're
> using? Is it the default one which came on the Eee?

No, it's a custom one based on GoboLinux.

--
/Jonatan [ http://kymatica.com ]
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

From forum: Jackit

Re: periodic drop-outs on asus EeePC 900

2008-10-07T07:42:27Z

On Tue, Oct 7, 2008 at 10:38 AM, Jamie McLaughlin
<j.mclaughlin@...> wrote:
> Hmm. This is a really interesting problem. Can I ask which distro you're
> using? Is it the default one which came on the Eee?

Also, are you running jackd in realtime (-R) mode?

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

From forum: Jackit

Re: periodic drop-outs on asus EeePC 900

2008-10-07T07:39:45Z

Hmm. This is a really interesting problem. Can I ask which distro you're
using? Is it the default one which came on the Eee?

Jamie

--

Jonatan Liljedahl wrote:
> I'm having trouble running jack (0.109.2) on my EeePC, I get periodic
> dropouts, once every 10 seconds or so. It affects both audio and midi.
>
> It's happening both with the internal soundcard (snd-hda-intel) and an
> external (usb audio). It happens even when only Jack and QJackctl is
> running, no other clients. It's running in realtime mode. I've tried
> raising the realtime priority but it doesn't help.
>
> Any ideas?
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

From forum: Jackit

periodic drop-outs on asus EeePC 900

2008-10-07T07:32:49Z

I'm having trouble running jack (0.109.2) on my EeePC, I get periodic
dropouts, once every 10 seconds or so. It affects both audio and midi.

It's happening both with the internal soundcard (snd-hda-intel) and an
external (usb audio). It happens even when only Jack and QJackctl is
running, no other clients. It's running in realtime mode. I've tried
raising the realtime priority but it doesn't help.

Any ideas?
--
/Jonatan [ http://kymatica.com ]
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

From forum: Jackit

Re: jack functions thread safety

2008-10-07T00:40:16Z

Le 6 oct. 08 à 23:38, Juan-Pablo Caceres a écrit :

> Hi Paul,
>
> Thanks for your answer. To illustrate the problem, I am putting the
> following code in a thread:
>
> //
> ======================================================================
> {
> jack_client_t* mClient;
> const char* client_name = "JackThread";
> const char* server_name = NULL;
> jack_options_t options = JackNoStartServer;
> jack_status_t status;
>
> mClient = jack_client_open (client_name, options, &status,
> server_name);
>
> if (mClient == NULL) {
> fprintf (stderr, "jack_client_open() failed, "
> "status = 0x%2.0x\n", status);
> if (status & JackServerFailed) {
> fprintf (stderr, "Unable to connect to JACK server\n");
> }
> std::exit(1);
> }
> if (status & JackServerStarted) {
> fprintf (stderr, "JACK server started\n");
> }
> if (status & JackNameNotUnique) {
> client_name = jack_get_client_name(mClient);
> fprintf (stderr, "unique name `%s' assigned\n", client_name);
> }
> }
> //
> ======================================================================
>
> Now, if I execute it once, everything works fine, however, if I
> instantiate several worker threads with that code, I get the error:
>
> ----
> Cannot open JackThread client
> jack_client_open() failed, status = 0x21
> Cannot open JackThread client
> ----
>
> Now, if I just sleep for a second before starting the next worker
> thread, everything works fine.
>
> Any ideas why this is happening?
>
> Thanks again,
> Juan-Pablo
>

Please start jack server in verbose mode (-v) and send the log on
server and client side.

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

From forum: Jackit

Re: jack functions thread safety

2008-10-07T00:31:40Z

On Mon, 2008-10-06 at 14:38 -0700, Juan-Pablo Caceres wrote:
> Hi Paul,
>
> Thanks for your answer. To illustrate the problem, I am putting the
> following code in a thread:

What version of JACK?

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

From forum: Jackit

Re: jack functions thread safety

2008-10-06T14:38:31Z

Hi Paul,

Thanks for your answer. To illustrate the problem, I am putting the
following code in a thread:

//======================================================================
{
jack_client_t* mClient;
const char* client_name = "JackThread";
const char* server_name = NULL;
jack_options_t options = JackNoStartServer;
jack_status_t status;

mClient = jack_client_open (client_name, options, &status, server_name);

if (mClient == NULL) {
fprintf (stderr, "jack_client_open() failed, "
"status = 0x%2.0x\n", status);
if (status & JackServerFailed) {
fprintf (stderr, "Unable to connect to JACK server\n");
}
std::exit(1);
}
if (status & JackServerStarted) {
fprintf (stderr, "JACK server started\n");
}
if (status & JackNameNotUnique) {
client_name = jack_get_client_name(mClient);
fprintf (stderr, "unique name `%s' assigned\n", client_name);
}
}
//======================================================================

Now, if I execute it once, everything works fine, however, if I
instantiate several worker threads with that code, I get the error:

----
Cannot open JackThread client
jack_client_open() failed, status = 0x21
Cannot open JackThread client
----

Now, if I just sleep for a second before starting the next worker
thread, everything works fine.

Any ideas why this is happening?

Thanks again,
Juan-Pablo

Paul Davis wrote:

> On Mon, 2008-10-06 at 14:10 -0700, Juan-Pablo Caceres wrote:
>> Hello all,
>>
>> As far as I understand, <jack/jack.h> functions are not thread safe,
>> i.e., calling jack_client_open (etc...) functions causes race
>> conditions, and error when trying to register two clients at the same
>> time, for instance.
>
> either all or almost all JACK API functions should be thread safe. there
> is no global data. if there is, it needs fixing.
>
> why do you believe jack_client_open() to be non-thread-safe?
>
>

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

From forum: Jackit