Nabble - Jackit

Re: Jack2 and FFADO, bug ??

2009-11-07T10:58:52Z

On Sat, 2009-11-07 at 15:41 +0100, Stéphane Letz wrote:

> Le 7 nov. 2009 à 15:31, Jörn Nettingsmeier a écrit :
>
> > Stéphane Letz wrote:
> >>
> >> jack2 uses a default value of 10 for the RT priority thread. I've
> >> just
> >> checked again jack1 code and this seems the same (line 60 in jackd.c
> >> file..), although Jörn told some days ago that something was
> >> different
> >> concerning default values of RT thread? (Jörn can you comment on
> >> that?)
> >
> > when invoked with -R but no explicit -P, current jackd1 uses these
> > priorities:
> > nettings@kleineronkel:~> ps -eLo pid,nice,pri,cls,rtprio,command |
> > grep jack
> >
> > 32166 0 19 TS - jackd -R -d alsa -d hw:1
> > 32166 0 19 TS - jackd -R -d alsa -d hw:1
> > 32166 0 19 TS - jackd -R -d alsa -d hw:1
> > 32166 - 60 FF 20 jackd -R -d alsa -d hw:1
> > 32166 - 50 FF 10 jackd -R -d alsa -d hw:1
> >
> > i.e. jackd1 uses an rtprio of 20 by default.
> > i guess the confusion comes from mixing up pri and rtprio fields.
> >
> > in any case the default rtprio in real-time mode should be changed
> > imho,
> > to at least 51, so that the jackd realtime threads take precedence
> > over
> > standard IRQ handlers (which are running at rtprio 50 by default). in
> > addition, it is recommended (especially for ffado) to raise the
> > priority
> > of ffado-critical IRQs to something higher than the jackd realtime
> > threads, possibly even higher than the ffado-related ones.
> >
> > regards,
> >
> > jörn
> >
>
>
> Hum..., looking at jack1 code again i see:
>
> static int realtime_priority = 10; (line 60 in jackd.c )
>
> and :
>
> int watchdog_priority = engine->rtpriority + 10; (line 970 in
> engine.c)
>
> So It seems that the thread at 20 is the watchdog RT thread and thread
> at 10 is the backend RT thread ?
>
> Now concerning what would be the right default value, I don't know...
> but it would be better to use the same value for jack1 and jack2..

In my Planet CCRMA packages I've been patching jack1/2 for years to
match the priorities assigned by rtirq on realtime kernels. "10" or even
"20" certainly don't work very well, that's much lower than all other rt
priorities of kernel and interrupt threads.

The ideal situation is priority of soundcard interrupt > jack priority >
all others.

-- Fernando

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

Re: Jack2 and FFADO, bug ??

2009-11-07T06:41:58Z

Le 7 nov. 2009 à 15:31, Jörn Nettingsmeier a écrit :

> Stéphane Letz wrote:
>>
>> jack2 uses a default value of 10 for the RT priority thread. I've
>> just
>> checked again jack1 code and this seems the same (line 60 in jackd.c
>> file..), although Jörn told some days ago that something was
>> different
>> concerning default values of RT thread? (Jörn can you comment on
>> that?)
>
> when invoked with -R but no explicit -P, current jackd1 uses these
> priorities:
> nettings@kleineronkel:~> ps -eLo pid,nice,pri,cls,rtprio,command |
> grep jack
>
> 32166 0 19 TS - jackd -R -d alsa -d hw:1
> 32166 0 19 TS - jackd -R -d alsa -d hw:1
> 32166 0 19 TS - jackd -R -d alsa -d hw:1
> 32166 - 60 FF 20 jackd -R -d alsa -d hw:1
> 32166 - 50 FF 10 jackd -R -d alsa -d hw:1
>
> i.e. jackd1 uses an rtprio of 20 by default.
> i guess the confusion comes from mixing up pri and rtprio fields.
>
> in any case the default rtprio in real-time mode should be changed
> imho,
> to at least 51, so that the jackd realtime threads take precedence
> over
> standard IRQ handlers (which are running at rtprio 50 by default). in
> addition, it is recommended (especially for ffado) to raise the
> priority
> of ffado-critical IRQs to something higher than the jackd realtime
> threads, possibly even higher than the ffado-related ones.
>
> regards,
>
> jörn
>

Hum..., looking at jack1 code again i see:

static int realtime_priority = 10; (line 60 in jackd.c )

and :

int watchdog_priority = engine->rtpriority + 10; (line 970 in
engine.c)

So It seems that the thread at 20 is the watchdog RT thread and thread
at 10 is the backend RT thread ?

Now concerning what would be the right default value, I don't know...
but it would be better to use the same value for jack1 and jack2..

Stéphane

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

Re: Jack2 and FFADO, bug ??

2009-11-07T06:31:52Z

Stéphane Letz wrote:
>
> jack2 uses a default value of 10 for the RT priority thread. I've just
> checked again jack1 code and this seems the same (line 60 in jackd.c
> file..), although Jörn told some days ago that something was different
> concerning default values of RT thread? (Jörn can you comment on that?)

when invoked with -R but no explicit -P, current jackd1 uses these
priorities:
nettings@kleineronkel:~> ps -eLo pid,nice,pri,cls,rtprio,command | grep jack

32166 0 19 TS - jackd -R -d alsa -d hw:1
32166 0 19 TS - jackd -R -d alsa -d hw:1
32166 0 19 TS - jackd -R -d alsa -d hw:1
32166 - 60 FF 20 jackd -R -d alsa -d hw:1
32166 - 50 FF 10 jackd -R -d alsa -d hw:1

i.e. jackd1 uses an rtprio of 20 by default.
i guess the confusion comes from mixing up pri and rtprio fields.

in any case the default rtprio in real-time mode should be changed imho,
to at least 51, so that the jackd realtime threads take precedence over
standard IRQ handlers (which are running at rtprio 50 by default). in
addition, it is recommended (especially for ffado) to raise the priority
of ffado-critical IRQs to something higher than the jackd realtime
threads, possibly even higher than the ffado-related ones.

regards,

jörn

--
Jörn Nettingsmeier

Meister für Veranstaltungstechnik

Audio and event engineer
Ambisonic surround recordings

http://stackingdwarves.net
+49 177 7937487

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

Re: Jack2 and FFADO, bug ??

2009-11-07T06:21:35Z

Tinram wrote:

> I understand the problem, but I think the -P is a bit confusing. -P should
> set the *higher* allowed priority and jack should set priorities taking
> care that the -P value is the max one he uses, don't you think ?

from a user POV, that's correct. but note that the jack server and the
driver backend can be (and are, in this case) developed separately.
all jackd "knows" is that -P X is the maximum priority it can use.
it happens that some ffado threads need a priority higher than that, but
jack cannot know this unless some very messy notifications are being
passed around. i guess this is better solved by user documentation, and
by ffado spitting out a useful error message in that case.

--
Jörn Nettingsmeier

Meister für Veranstaltungstechnik

Audio and event engineer
Ambisonic surround recordings

http://stackingdwarves.net
+49 177 7937487

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

Re: Jack2 and FFADO, bug ??

2009-11-07T03:03:59Z

Le samedi 07 novembre 2009 à 14:12 +1030, Jonathan Woithe a écrit :
Hi again

>
> I just noticed this later reply.
>
> > > Ok this happens in JACK2 FFADO backend line 472 and it caused by a
> > > "ffado_streaming_init" falling...
> > >
> > > I don't know exactly if JACK2 FFADO backend completely follows JACK1
> > > FFADO backend (ppalmers wrote that code). I guess the best is now to
> > > report the issue to FFDAO developers.
> >
> > I found the solution : FFADO creates (one of ??) its thread with
> > a priority of 16 and my limits.conf was set to:
> >
> > @audio - rtprio 16
> >
> > so FFADO wasn't allowed to do such a thing. But it's wired that it
> > hasn't the same behavior on Jack1... It should be better that FFADO
> > uses the priority set with -Pxx from jack no ??
>
> It's a bit more complicated than that. FFADO requires multiple threads and
> a very specific priority order to ensure that the right threads can always
> run at the correct time. The jackd "-P" argument (or the default level if
> "-P" isn't specified) is used as a starting point, but because multiple
> priority levels are needed (some above jackd's, some below) it is at best a
> guide.
>
> The reason for the differences between jack 1 and 2 might be due to
> architectual differences - the FFADO threads and their required priorities
> may differ between the two for that reason. As was commented earlier,
> Pieter Palmers (who wrote the respective backends along with most of the
> FFADO streaming infrastructure) would be in the best position to comment on
> this.
>
> > Or at least to add a priority parameter to the backend...
>
> This won't help because the FFADO thread priorities must be set relative to
> the jackd priorities.
>
> We certainly agree that this is a messy situation but it's at least partly
> due to the need to have very fine control over timing in userspace -
> something which is required by the needs of the interfaces. The problem
> will eventually be solved using an in-kernel FFADO streaming engine, but for
> now we've got to make use of the RT mechanism as best we can.

I understand the problem, but I think the -P is a bit confusing. -P should
set the *higher* allowed priority and jack should set priorities taking
care that the -P value is the max one he uses, don't you think ?

> By the way, in my experience one needs to use a priority somewhat higher
> than 15 for successful FFADO use. I personally use "-P60" while others use
> "-P70". Obviously this requires a change to limits.conf to allow these
> levels. The need for the high number comes about because the default level
> used by kernel interrupt routines (particularly in RT kernels) is 50, and
> jackd/FFADO needs to run above this for best results. If you encounter
> stability issues while running at the default jackd priority level you may
> want to try "-P60" or "-P70" and see if it improves things.
>
> Further discussion on this matter is probably best conducted in ffado-devel.
>
> Regards
> jonathan
>
>

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

Re: jackmp rev 3695 bad change in posix/JackPosixThread.cpp

2009-11-07T01:57:56Z

Le 7 nov. 2009 à 00:29, Andreas Degert a écrit :

> On Sat, 7 Nov 2009 00:13:36 +0100
> Andreas Degert <ad@...> wrote:
>
>> Hi,
>>
>> the substitution of fThread with pthread_self() should be reverted,
>> it
>> acquires / drops realtime scheduling for the calling thread of the
>> client instead of the processing thread.
>>
>> check:
>>
>> start ardour, use
>>
>> ps -eLo pid,tid,rtprio,sched,comm | grep ardour
>>
>> and watch for the difference in realtime priorities before and after
>> applying the patch (and use your ears :-).
>
> attached patch for reverting the change (maybe windows/mac has the
> same
> problem, but i can't test).
>
> ciao
> Andreas

Should be fixed in SVN rev 3716 (http://trac.jackaudio.org/changeset/3716
)

Can you possibly test and report?

Thanks

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

Re: Jack2 and FFADO, bug ??

2009-11-07T01:25:42Z

Le 7 nov. 2009 à 04:42, Jonathan Woithe a écrit :

> Hi again
>
> I just noticed this later reply.
>
>>> Ok this happens in JACK2 FFADO backend line 472 and it caused by a
>>> "ffado_streaming_init" falling...
>>>
>>> I don't know exactly if JACK2 FFADO backend completely follows JACK1
>>> FFADO backend (ppalmers wrote that code). I guess the best is now to
>>> report the issue to FFDAO developers.
>>
>> I found the solution : FFADO creates (one of ??) its thread with
>> a priority of 16 and my limits.conf was set to:
>>
>> @audio - rtprio 16
>>
>> so FFADO wasn't allowed to do such a thing. But it's wired that it
>> hasn't the same behavior on Jack1... It should be better that FFADO
>> uses the priority set with -Pxx from jack no ??
>
> It's a bit more complicated than that. FFADO requires multiple
> threads and
> a very specific priority order to ensure that the right threads can
> always
> run at the correct time. The jackd "-P" argument (or the default
> level if
> "-P" isn't specified) is used as a starting point, but because
> multiple
> priority levels are needed (some above jackd's, some below) it is at
> best a
> guide.
>
> The reason for the differences between jack 1 and 2 might be due to
> architectual differences - the FFADO threads and their required
> priorities
> may differ between the two for that reason. As was commented earlier,
> Pieter Palmers (who wrote the respective backends along with most of
> the
> FFADO streaming infrastructure) would be in the best position to
> comment on
> this.

I don't see any important architectual differences between jack1 and
jack2 that could explain what is seen. AFAICS both use the "blocking"
version of FFADO API and the backend is then "wrapped" in an RT thread
that drives the JACK engine. (Ppalmers told me at LAC 2008 that FFADO
could possibly work in a "callback" model, thus making this "wrapping"
thread unneeded, an having the FFADO backend then looking like the
CoreAudio backend on OSX or PortAudio backend on WIndows... but this
change has never been done since)

>
>> Or at least to add a priority parameter to the backend...
>
> This won't help because the FFADO thread priorities must be set
> relative to
> the jackd priorities.

jack2 uses a default value of 10 for the RT priority thread. I've just
checked again jack1 code and this seems the same (line 60 in jackd.c
file..), although Jörn told some days ago that something was different
concerning default values of RT thread? (Jörn can you comment on that?)

>
> We certainly agree that this is a messy situation but it's at least
> partly
> due to the need to have very fine control over timing in userspace -
> something which is required by the needs of the interfaces. The
> problem
> will eventually be solved using an in-kernel FFADO streaming engine,
> but for
> now we've got to make use of the RT mechanism as best we can.
>
> By the way, in my experience one needs to use a priority somewhat
> higher
> than 15 for successful FFADO use. I personally use "-P60" while
> others use
> "-P70". Obviously this requires a change to limits.conf to allow
> these
> levels. The need for the high number comes about because the
> default level
> used by kernel interrupt routines (particularly in RT kernels) is
> 50, and
> jackd/FFADO needs to run above this for best results. If you
> encounter
> stability issues while running at the default jackd priority level
> you may
> want to try "-P60" or "-P70" and see if it improves things.
>
> Further discussion on this matter is probably best conducted in
> ffado-devel.
>
> Regards
> jonathan
> _______________________________________________

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

Re: Jack2 and FFADO, bug ??

2009-11-06T19:42:27Z

Hi again

I just noticed this later reply.

> > Ok this happens in JACK2 FFADO backend line 472 and it caused by a
> > "ffado_streaming_init" falling...
> >
> > I don't know exactly if JACK2 FFADO backend completely follows JACK1
> > FFADO backend (ppalmers wrote that code). I guess the best is now to
> > report the issue to FFDAO developers.
>
> I found the solution : FFADO creates (one of ??) its thread with
> a priority of 16 and my limits.conf was set to:
>
> @audio - rtprio 16
>
> so FFADO wasn't allowed to do such a thing. But it's wired that it
> hasn't the same behavior on Jack1... It should be better that FFADO
> uses the priority set with -Pxx from jack no ??

It's a bit more complicated than that. FFADO requires multiple threads and
a very specific priority order to ensure that the right threads can always
run at the correct time. The jackd "-P" argument (or the default level if
"-P" isn't specified) is used as a starting point, but because multiple
priority levels are needed (some above jackd's, some below) it is at best a
guide.

The reason for the differences between jack 1 and 2 might be due to
architectual differences - the FFADO threads and their required priorities
may differ between the two for that reason. As was commented earlier,
Pieter Palmers (who wrote the respective backends along with most of the
FFADO streaming infrastructure) would be in the best position to comment on
this.

> Or at least to add a priority parameter to the backend...

This won't help because the FFADO thread priorities must be set relative to
the jackd priorities.

We certainly agree that this is a messy situation but it's at least partly
due to the need to have very fine control over timing in userspace -
something which is required by the needs of the interfaces. The problem
will eventually be solved using an in-kernel FFADO streaming engine, but for
now we've got to make use of the RT mechanism as best we can.

By the way, in my experience one needs to use a priority somewhat higher
than 15 for successful FFADO use. I personally use "-P60" while others use
"-P70". Obviously this requires a change to limits.conf to allow these
levels. The need for the high number comes about because the default level
used by kernel interrupt routines (particularly in RT kernels) is 50, and
jackd/FFADO needs to run above this for best results. If you encounter
stability issues while running at the default jackd priority level you may
want to try "-P60" or "-P70" and see if it improves things.

Further discussion on this matter is probably best conducted in ffado-devel.

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

Re: Jack2 and FFADO, bug ??

2009-11-06T19:31:12Z

Hi Martin

> I'm running jack2 (1.9.3) with a firewire soundcard through FFADO.

As far as I am aware, FFADO is not targeting jack2 at present.

> If I run it without realitme capability I get periodical xruns witch
> doesn't seem to be linked to latency... If I run it with realtime
> capability, it just fail like that :

As mentioned, this *may* be due to the fact that FFADO and jack2 are not
entirely happy together at present. However, others on the ffado-devel list
may well have a more up-to-date view on this so I'll forward this message to
that list as well for comments. Please subscribe to ffado-dvel to see the
answers. :-)

That's not to say that this is a ffado issue. There may well be something
odd happening in jack2 which is causing this. That's for those more
familiar with jack to comment on.

> The problem has nothing to do with my system, I guess, because, it runs
> just well with jack1 (0.116.2) with a 4ms latency, and jack2 is OK with
> realtime on my internal soudcard and with my USB console.

Obviously neither the built-in card or the USB interface utilises FFADO, so
the FFADO+jack2 combination isn't being used in these cases.
doesn't

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

Re: pyjack status and patches

2009-11-06T16:06:52Z

Patrick Shirkey
Boost Hardware Ltd

On 11/07/2009 01:57 AM, Pau Arumí wrote:

> Hi all,
>
> I'm under the impression that pyjack is not maintained because I wrote
> the author, Andrew, (via sourceforge) more than a week ago, and it went
> without answer. Does anybody knows more about the pyjack status?
>
> https://sourceforge.net/projects/py-jack/
>
> The point is that clam developers (at least the ones in BarcelonaMedia)
> find a jack python module very useful for our purposes. And since we
> needed to write and maintain patches we have put the code in this public
> subversion path:
>
> svn co http://clam-project.org/clam/trunk/pyjack/
>
> Of course this is not ment to be a fork but a provisional place to
> maintain the patches. However, if the project is confirmed orphan we'd
> be happy to adopt and care the baby.
>
> See all the changes here
> http://clam-project.org/clam/trunk/pyjack/CHANGES
>
> Changes in a nutshell:
> 1. Many small fixes in the pyjack C implementation.
> 2. Added the transport protocol patch written by Akhilman
> 3. Added a new high level patch-by api
>
> With 2 you can, for example, easily connect Blender and Ardour.
> In 3 we added an api for doing connections in a bus fashion (i.e.
> connecting all or a subset of ports in order). An example:
>
> metro = 'jack_metro -b 60'
> c1 = run_jack_client(metro)
> c2 = run_jack_client(metro)
>
> # passing jack clients names
> bus_connect(c1, 'system')
> bus_connect('system', 'system')
>
> # passing ports list. Note the use of python list slicing
> bus_connect( outports('system')[:-1] , inports('system')[-2:] )
> bus_connect( c2 , inports('system')[-3:] )
>
> Any feedback is very welcomed
>
>

Good idea to update this code. With the transport patch alone it is
extremely valuable.

Patrick Shirkey
Boost Hardware Ltd

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

Re: jackmp rev 3695 bad change in posix/JackPosixThread.cpp

2009-11-06T15:40:17Z

Le 7 nov. 2009 à 00:29, Andreas Degert a écrit :

Thanks for the patch... but the initial change had some deeper
reasons... Obviously it breaks when used In JackClient.cpp so I'll
have to find a solution that works in all cases.

Anyway thanks for reporting, and yes JACK2 SVN is broken after rev 3695.

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

Re: jackmp rev 3695 bad change in posix/JackPosixThread.cpp

2009-11-06T15:29:01Z

On Sat, 7 Nov 2009 00:13:36 +0100
Andreas Degert <ad@...> wrote:

> Hi,
>
> the substitution of fThread with pthread_self() should be reverted, it
> acquires / drops realtime scheduling for the calling thread of the
> client instead of the processing thread.
>
> check:
>
> start ardour, use
>
> ps -eLo pid,tid,rtprio,sched,comm | grep ardour
>
> and watch for the difference in realtime priorities before and after
> applying the patch (and use your ears :-).

attached patch for reverting the change (maybe windows/mac has the same
problem, but i can't test).

ciao
Andreas

[diff-3695-bad.diff]

Index: posix/JackPosixThread.cpp =================================================================== --- posix/JackPosixThread.cpp (Revision 3715) +++ posix/JackPosixThread.cpp (Arbeitskopie) @@ -205,7 +205,7 @@ int JackPosixThread::AcquireRealTime() { - return AcquireRealTimeImp(pthread_self(), fPriority); + return (fThread != (pthread_t)NULL) ? AcquireRealTimeImp(fThread, fPriority) : -1; } int JackPosixThread::AcquireRealTime(int priority) @@ -232,7 +232,7 @@ int JackPosixThread::DropRealTime() { - return DropRealTimeImp(pthread_self()); + return (fThread != (pthread_t)NULL) ? DropRealTimeImp(fThread) : -1; } int JackPosixThread::DropRealTimeImp(pthread_t thread)

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

jackmp rev 3695 bad change in posix/JackPosixThread.cpp

2009-11-06T15:13:36Z

Hi,

the substitution of fThread with pthread_self() should be reverted, it
acquires / drops realtime scheduling for the calling thread of the
client instead of the processing thread.

check:

start ardour, use

ps -eLo pid,tid,rtprio,sched,comm | grep ardour

and watch for the difference in realtime priorities before and after
applying the patch (and use your ears :-).

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

Re: Jack2 and FFADO, bug ??

2009-11-06T11:04:46Z

Le vendredi 06 novembre 2009 à 18:57 +0100, Stéphane Letz a écrit :

> > Jack: JackFFADODriver::Attach fBufferSize 1024 fSampleRate 48000
> > 06071389163: (ffado.cpp)[ 92] ffado_streaming_init: libffado
> > 2.999.0-1700 built Nov 4 2009 23:09:34
> > firewire ERR: FFADO: Error creating virtual device
>
>
>
> Ok this happens in JACK2 FFADO backend line 472 and it caused by a
> "ffado_streaming_init" falling...
>
> I don't know exactly if JACK2 FFADO backend completely follows JACK1
> FFADO backend (ppalmers wrote that code). I guess the best is now to
> report the issue to FFDAO developers.

I found the solution : FFADO creates (one of ??) its thread with
a priority of 16 and my limits.conf was set to:

@audio - rtprio 16

so FFADO wasn't allowed to do such a thing. But it's wired that it
hasn't the same behavior on Jack1... It should be better that FFADO
uses the priority set with -Pxx from jack no ?? Or at least to add a priority
parameter to the backend...

> Thanks.
>
> Stéphane

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

Re: Jack2 and FFADO, bug ??

2009-11-06T09:57:31Z

> Can you produce a log in "verbose" mode (-v)?
>
> jackd -v -R -dfirewire
>

Of curse, here it is :

tinram@PcMartin:~$ jackd -v -R -dfirewire
jackdmp 1.9.3
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2009 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 10
Jack: Create non RT thread
Jack: ThreadHandler: start
Jack: JackSocketServerChannel::Open
Jack: Bind: addr.sun_path /dev/shm/jack_default_1000_0
Jack: JackSocketServerChannel::BuildPoolTable size = 1
Jack: Create non RT thread
Jack: JackEngine::Open
Jack: Connect: addr.sun_path /dev/shm/jack_default_1000_0
Jack: ThreadHandler: start
Jack: JackSocketServerChannel::ClientCreate socket
Jack: JackSocketServerChannel::BuildPoolTable size = 2
Jack: fSocketTable i = 1 fd = 5
Jack: JackDriver::Open capture_driver_name =
Jack: JackDriver::Open playback_driver_name =
Jack: JackEngine::ClientInternalNew: name = system
Jack: JackEngine::AllocateRefNum ref = 0
Jack: JackFifo::Allocate name = /dev/shm/jack_fifo.1000_default_system
Jack: JackEngine::NotifyAddClient: name = system
Jack: JackGraphManager::SetBufferSize size = 1024
Jack: JackConnectionManager::DirectConnect first: ref1 = 0 ref2 = 0
Jack: JackGraphManager::ConnectRefNum cur_index = 0 ref1 = 0 ref2 = 0
Jack: JackDriver::SetupDriverSync driver sem in flush mode
Jack: JackEngine::ClientInternalNew: name = freewheel
Jack: JackEngine::AllocateRefNum ref = 1
Jack: JackFifo::Allocate name = /dev/shm/jack_fifo.1000_default_freewheel
Jack: JackEngine::NotifyAddClient: name = freewheel
Jack: JackConnectionManager::DirectConnect first: ref1 = 1 ref2 = 1
Jack: JackGraphManager::ConnectRefNum cur_index = 0 ref1 = 1 ref2 = 1
Jack: JackDriver::SetupDriverSync driver sem in flush mode
Jack: JackFFADODriver::Attach fBufferSize 1024 fSampleRate 48000
06071389163: (ffado.cpp)[ 92] ffado_streaming_init: libffado 2.999.0-1700 built Nov 4 2009 23:09:34
firewire ERR: FFADO: Error creating virtual device
Cannot attach audio driver
Jack: JackDriver::Close
Jack: JackConnectionManager::DirectDisconnect last: ref1 = 1 ref2 = 1
Jack: JackGraphManager::DisconnectRefNum cur_index = 0 ref1 = 1 ref2 = 1
Jack: JackEngine::ClientCloseAux ref = 1
Jack: JackGraphManager::RemoveAllPorts ref = 1
Jack: JackFifo::Destroy name = /dev/shm/jack_fifo.1000_default_freewheel
Jack: JackDriver::Close
Jack: JackConnectionManager::DirectDisconnect last: ref1 = 0 ref2 = 0
Jack: JackGraphManager::DisconnectRefNum cur_index = 0 ref1 = 0 ref2 = 0
Jack: JackEngine::ClientCloseAux ref = 0
Jack: JackGraphManager::RemoveAllPorts ref = 0
Jack: JackFifo::Destroy name = /dev/shm/jack_fifo.1000_default_system
Jack: JackEngine::Close
Jack: JackClientSocket::Close
Jack: JackPosixThread::Kill
Jack: JackServerSocket::Close /dev/shm/jack_default_1000_0
Jack: JackClientSocket::Close
no message buffer overruns
Jack: JackPosixThread::Stop
Jack: ThreadHandler: exit
JackServer::Open() failed with -1
Jack: JackShmMem::delete size = 0 index = 0
Jack: ~JackDriver
no message buffer overruns
Jack: ~JackDriver
Jack: JackEngine::~JackEngine
Jack: JackShmMem::delete size = 0 index = 1
Jack: cleaning up shared memory
Jack: cleaning up files
Jack: unregistering server `default'
Failed to start server

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

Re: Jack2 and FFADO, bug ??

2009-11-06T09:57:25Z

> Jack: JackFFADODriver::Attach fBufferSize 1024 fSampleRate 48000
> 06071389163: (ffado.cpp)[ 92] ffado_streaming_init: libffado
> 2.999.0-1700 built Nov 4 2009 23:09:34
> firewire ERR: FFADO: Error creating virtual device

Ok this happens in JACK2 FFADO backend line 472 and it caused by a
"ffado_streaming_init" falling...

I don't know exactly if JACK2 FFADO backend completely follows JACK1
FFADO backend (ppalmers wrote that code). I guess the best is now to
report the issue to FFDAO developers.

Thanks.

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

Re: Jack2 and FFADO, bug ??

2009-11-06T09:41:51Z

Le 6 nov. 2009 à 17:58, Tinram a écrit :

> Hi devs,
>
> I'm running jack2 (1.9.3) with a firewire soundcard through FFADO.
> If I run it without realitme capability I get periodical xruns witch
> doesn't seem to be linked to latency... If I run it with realtime
> capability, it just fail like that :
>
>
> tinram@PcMartin:~/Son/Compil/jack-1.9.3$ jackd -R -dfirewire
>> jackdmp 1.9.3
>> Copyright 2001-2005 Paul Davis and others.
>> Copyright 2004-2009 Grame.
>> jackdmp comes with ABSOLUTELY NO WARRANTY
>> This is free software, and you are welcome to redistribute it
>> under certain conditions; see the file COPYING for details
>> no message buffer overruns
>> no message buffer overruns
>> JACK server starting in realtime mode with priority 10
>> 02007203650: (ffado.cpp)[ 92] ffado_streaming_init: libffado
>> 2.999.0-1700 built Nov 4 2009 23:09:34
>> firewire ERR: FFADO: Error creating virtual device
>> Cannot attach audio driver
>> no message buffer overruns
>> JackServer::Open() failed with -1
>> no message buffer overruns
>> Failed to start server
>>
>>
> The problem has nothing to do with my system, I guess, because, it
> runs just
> well with jack1 (0.116.2) with a 4ms latency, and jack2 is OK with
> realtime on my internal soudcard
> and with my USB console. Don't know if it's a bug or so in jack2 but
> it's wired.
> Jack output doesn't help a lot to solve this...
>
> Thanks for your help.
> Martin.

Can you produce a log in "verbose" mode (-v)?

jackd -v -R -dfirewire

Thanks

Stéphane

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

Jack2 and FFADO, bug ??

2009-11-06T08:58:44Z

Hi devs,

I'm running jack2 (1.9.3) with a firewire soundcard through FFADO.
If I run it without realitme capability I get periodical xruns witch doesn't seem to be linked to latency... If I run it with realtime capability, it just fail like that :

tinram@PcMartin:~/Son/Compil/jack-1.9.3$ jackd -R -dfirewire

> jackdmp 1.9.3
> Copyright 2001-2005 Paul Davis and others.
> Copyright 2004-2009 Grame.
> jackdmp comes with ABSOLUTELY NO WARRANTY
> This is free software, and you are welcome to redistribute it
> under certain conditions; see the file COPYING for details
> no message buffer overruns
> no message buffer overruns
> JACK server starting in realtime mode with priority 10
> 02007203650: (ffado.cpp)[ 92] ffado_streaming_init: libffado 2.999.0-1700 built Nov 4 2009 23:09:34
> firewire ERR: FFADO: Error creating virtual device
> Cannot attach audio driver
> no message buffer overruns
> JackServer::Open() failed with -1
> no message buffer overruns
> Failed to start server
>
>

The problem has nothing to do with my system, I guess, because, it runs just
well with jack1 (0.116.2) with a 4ms latency, and jack2 is OK with realtime on my internal soudcard
and with my USB console. Don't know if it's a bug or so in jack2 but it's wired.
Jack output doesn't help a lot to solve this...

Thanks for your help.
Martin.

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

OT: want to betatest my app on iPhone/ipod touch

2009-11-06T08:38:30Z

I'm sorry for being off-topic, but I'm looking for audio-interested
people outside of sweden that would like to test an app for iphone/ipod
touch that I'm developing. It's a sample loop-player with different
manipulation and modulation capabilities... Send me a mail if you're
interested!

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

Re: please merge netone-fixes branch

2009-11-06T07:37:50Z

Le 6 nov. 2009 à 16:06, torbenh a écrit :

>
> please merge this branch:
> http://repo.or.cz/w/jack2.git/shortlog/refs/heads/netone-fixes
>
> --

Done SVN rev 3714.

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

please merge netone-fixes branch

2009-11-06T07:06:43Z

please merge this branch:
http://repo.or.cz/w/jack2.git/shortlog/refs/heads/netone-fixes

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

pyjack status and patches

2009-11-06T06:57:49Z

Hi all,

I'm under the impression that pyjack is not maintained because I wrote
the author, Andrew, (via sourceforge) more than a week ago, and it went
without answer. Does anybody knows more about the pyjack status?

https://sourceforge.net/projects/py-jack/

The point is that clam developers (at least the ones in BarcelonaMedia)
find a jack python module very useful for our purposes. And since we
needed to write and maintain patches we have put the code in this public
subversion path:

svn co http://clam-project.org/clam/trunk/pyjack/

Of course this is not ment to be a fork but a provisional place to
maintain the patches. However, if the project is confirmed orphan we'd
be happy to adopt and care the baby.

See all the changes here
http://clam-project.org/clam/trunk/pyjack/CHANGES

Changes in a nutshell:
1. Many small fixes in the pyjack C implementation.
2. Added the transport protocol patch written by Akhilman
3. Added a new high level patch-by api

With 2 you can, for example, easily connect Blender and Ardour.
In 3 we added an api for doing connections in a bus fashion (i.e.
connecting all or a subset of ports in order). An example:

metro = 'jack_metro -b 60'
c1 = run_jack_client(metro)
c2 = run_jack_client(metro)

# passing jack clients names
bus_connect(c1, 'system')
bus_connect('system', 'system')

# passing ports list. Note the use of python list slicing
bus_connect( outports('system')[:-1] , inports('system')[-2:] )
bus_connect( c2 , inports('system')[-3:] )

Any feedback is very welcomed

P

--
--------------------------------------------------
Pau Arumí

Barcelona Media - Innovation Centre
Av. Diagonal 177, planta 9, 08018 Barcelona, Spain
Phone: +34 93 238 1400

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

Re: freewheeling with jackd 1.9.3

2009-11-06T04:52:16Z

Well this is part of the problem, but not exactly the issue Andreas
reported. I did actually start to fix this part ("non RT behaviour")
on SVN and send a patch to Andreas to test for his initial problem.

i am just saying, that your fix in SVN r3700 is not complete.

So what is missing?

Stéphane

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

Re: freewheeling with jackd 1.9.3

2009-11-06T03:10:00Z

On Fri, Nov 06, 2009 at 10:24:03AM +0100, Stéphane Letz wrote:

>
> Le 6 nov. 2009 à 10:09, torbenh a écrit :
>
> >On Thu, Nov 05, 2009 at 08:32:08PM +0100, Stéphane Letz wrote:
> >>
> >>Le 5 nov. 2009 à 18:15, Andreas Degert a écrit :
> >>
> >>>On Thu, 5 Nov 2009 09:55:56 +0100
> >>>Stéphane Letz <letz@...> wrote:
> >>>
> >>>>
> >>>>Le 3 nov. 2009 à 01:19, Andreas Degert a écrit :
> >>>>
> >>>>>doesn't seem to work under linux when using in realtime mode.
> >>>>>
> >>>>>Starting works, but stopping gives an error:
> >>>>>
> >>>>>Cannot set scheduling priority for RT thread res = 22 err = No
> >>>>>such file or directory
> >>>>>Cannot start thread
> >>>>
> >>>>AFAICS this happens when restarting the audio driver. Can you
> >>>>produce a more complete log with the verbose mode (-v when starting
> >>>>jackd) ?
> >>>
> >>>Yes, happens when the audio driver is restarted.
> >>>
> >>>sorry, can't create a log atm, I can send one later if still needed
> >>
> >>
> >>Yes, please send a complete log.
> >
> >the fix for the non RT behaviour is not complete.
> >a client connecting during freewheel would not set its logging to
> >buffered.
> >
> >this should better fix the issue:
> >http://repo.or.cz/w/jack2.git/commitdiff/b4939bba6fded4c65d1d28d792c56ecbe9d2392e
> >>
> >>Thanks
> >>
> >>Stéphane
>
>
> Well this is part of the problem, but not exactly the issue Andreas
> reported. I did actually start to fix this part ("non RT behaviour")
> on SVN and send a patch to Andreas to test for his initial problem.

i am just saying, that your fix in SVN r3700 is not complete.

>
> Stéphane

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

Re: freewheeling with jackd 1.9.3

2009-11-06T01:24:03Z

Le 6 nov. 2009 à 10:09, torbenh a écrit :

> On Thu, Nov 05, 2009 at 08:32:08PM +0100, Stéphane Letz wrote:
>>
>> Le 5 nov. 2009 à 18:15, Andreas Degert a écrit :
>>
>>> On Thu, 5 Nov 2009 09:55:56 +0100
>>> Stéphane Letz <letz@...> wrote:
>>>
>>>>
>>>> Le 3 nov. 2009 à 01:19, Andreas Degert a écrit :
>>>>
>>>>> doesn't seem to work under linux when using in realtime mode.
>>>>>
>>>>> Starting works, but stopping gives an error:
>>>>>
>>>>> Cannot set scheduling priority for RT thread res = 22 err = No
>>>>> such file or directory
>>>>> Cannot start thread
>>>>
>>>> AFAICS this happens when restarting the audio driver. Can you
>>>> produce a more complete log with the verbose mode (-v when starting
>>>> jackd) ?
>>>
>>> Yes, happens when the audio driver is restarted.
>>>
>>> sorry, can't create a log atm, I can send one later if still needed
>>
>>
>> Yes, please send a complete log.
>
> the fix for the non RT behaviour is not complete.
> a client connecting during freewheel would not set its logging to
> buffered.
>
> this should better fix the issue:
> http://repo.or.cz/w/jack2.git/commitdiff/b4939bba6fded4c65d1d28d792c56ecbe9d2392e
>>
>> Thanks
>>
>> Stéphane

Well this is part of the problem, but not exactly the issue Andreas
reported. I did actually start to fix this part ("non RT behaviour")
on SVN and send a patch to Andreas to test for his initial problem.

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

Re: freewheeling with jackd 1.9.3

2009-11-06T01:09:04Z

On Thu, Nov 05, 2009 at 08:32:08PM +0100, Stéphane Letz wrote:

>
> Le 5 nov. 2009 à 18:15, Andreas Degert a écrit :
>
> >On Thu, 5 Nov 2009 09:55:56 +0100
> >Stéphane Letz <letz@...> wrote:
> >
> >>
> >>Le 3 nov. 2009 à 01:19, Andreas Degert a écrit :
> >>
> >>>doesn't seem to work under linux when using in realtime mode.
> >>>
> >>>Starting works, but stopping gives an error:
> >>>
> >>>Cannot set scheduling priority for RT thread res = 22 err = No
> >>>such file or directory
> >>>Cannot start thread
> >>
> >>AFAICS this happens when restarting the audio driver. Can you
> >>produce a more complete log with the verbose mode (-v when starting
> >>jackd) ?
> >
> >Yes, happens when the audio driver is restarted.
> >
> >sorry, can't create a log atm, I can send one later if still needed
>
>
> Yes, please send a complete log.

the fix for the non RT behaviour is not complete.
a client connecting during freewheel would not set its logging to
buffered.

this should better fix the issue:
http://repo.or.cz/w/jack2.git/commitdiff/b4939bba6fded4c65d1d28d792c56ecbe9d2392e

>
> Thanks
>
> Stéphane
>
>
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel@...
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

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

Re: [RFC] roll a new jack1 tarball?

2009-11-06T00:56:28Z

On Thu, Nov 05, 2009 at 10:06:11PM +0100, Jörn Nettingsmeier wrote:

> hi everybody!
>
>
> afaict, the jack1 codebase is in pretty good shape, there are no
> intrusive changes in core functionality, everything has been tested for
> quite a while, the netjack1/alsa_[in|out] improvements are significant,
> and we have added support for CELT 0.7.0.
>
> so i'd like to propose to roll a tarball release real soon now,
> especially since it's been a while...
>
> this would also be convenient for distributors planning to move to CELT
> 0.7.0. (i know opensuse factory is, and some people on IRC have
> contacted other distro packagers, who are also thinking about it.)
>
> what do you think?
>
> i have three trivial and largely cosmetic patches to netjack1 in the
> queue that i'd like to submit for review before a release - if anybody
> else is sitting on code, now would be a perfect time to push it out :)

i need to port back the changes made to the deadline machinery in
netone. and a im not at all confident that this is it now.

the current jack1 codebase is likely to show the same problems geoff was
seeing. i will try to keep netone and netjack1 in sync.

But both still need some testing.

>
>
> best,
>
> jörn
>
>
> --
> Jörn Nettingsmeier
>
> Meister für Veranstaltungstechnik
>
> Audio and event engineer
> Ambisonic surround recordings
>
> http://stackingdwarves.net
> +49 177 7937487
>
> _______________________________________________
> 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

[RFC] roll a new jack1 tarball?

2009-11-05T13:06:11Z

hi everybody!

afaict, the jack1 codebase is in pretty good shape, there are no
intrusive changes in core functionality, everything has been tested for
quite a while, the netjack1/alsa_[in|out] improvements are significant,
and we have added support for CELT 0.7.0.

so i'd like to propose to roll a tarball release real soon now,
especially since it's been a while...

this would also be convenient for distributors planning to move to CELT
0.7.0. (i know opensuse factory is, and some people on IRC have
contacted other distro packagers, who are also thinking about it.)

what do you think?

i have three trivial and largely cosmetic patches to netjack1 in the
queue that i'd like to submit for review before a release - if anybody
else is sitting on code, now would be a perfect time to push it out :)

best,

jörn

--
Jörn Nettingsmeier

Meister für Veranstaltungstechnik

Audio and event engineer
Ambisonic surround recordings

http://stackingdwarves.net
+49 177 7937487

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

Re: freewheeling with jackd 1.9.3

2009-11-05T11:32:08Z

Le 5 nov. 2009 à 18:15, Andreas Degert a écrit :

> On Thu, 5 Nov 2009 09:55:56 +0100
> Stéphane Letz <letz@...> wrote:
>
>>
>> Le 3 nov. 2009 à 01:19, Andreas Degert a écrit :
>>
>>> doesn't seem to work under linux when using in realtime mode.
>>>
>>> Starting works, but stopping gives an error:
>>>
>>> Cannot set scheduling priority for RT thread res = 22 err = No
>>> such file or directory
>>> Cannot start thread
>>
>> AFAICS this happens when restarting the audio driver. Can you
>> produce a more complete log with the verbose mode (-v when starting
>> jackd) ?
>
> Yes, happens when the audio driver is restarted.
>
> sorry, can't create a log atm, I can send one later if still needed

Yes, please send a complete log.

Thanks

Stéphane

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

Re: freewheeling with jackd 1.9.3

2009-11-05T09:15:22Z

On Thu, 5 Nov 2009 09:55:56 +0100
Stéphane Letz <letz@...> wrote:

>
> Le 3 nov. 2009 à 01:19, Andreas Degert a écrit :
>
> > doesn't seem to work under linux when using in realtime mode.
> >
> > Starting works, but stopping gives an error:
> >
> > Cannot set scheduling priority for RT thread res = 22 err = No
> > such file or directory
> > Cannot start thread
>
> AFAICS this happens when restarting the audio driver. Can you
> produce a more complete log with the verbose mode (-v when starting
> jackd) ?

Yes, happens when the audio driver is restarted.

sorry, can't create a log atm, I can send one later if still needed

> >
> > It seems the member fRealTime of JackThread is not used
> > consistently. In the constructor of JackThreadedDriver fThread is
> > created non-realtime, even if the driver shall be running in
> > realtime (fRealTime set in fDriver).
>
> Yes indeed.
> >
> > In JackThreadedDriver::Init, fThread.AcquireRealTime is called. It
> > stores the given priority and sets the thread to realtime
> > scheduling, but doesn't set fRealTime in fThread.
>
> There is no fRealTime in Thread class. Putting the "wrapping"
> thread in realtime happens because of a RT state of the wrapped
> driver.

class JackThreadedDriver has a member fThread (with type JackThread).

linux/JackPlatformPlug_os.h:namespace Jack { typedef JackPosixThread JackThread; }

posix/JackPosixThread.h:class SERVER_EXPORT JackPosixThread : public detail::JackThreadInterface

class JackThreadInterface is defined in common/JackThread.h and has
a member fRealTime.

> >
> > When freewheeling is entered, scheduling is changed to non-realtime.
>
> ??
>
> Freewheeling driver never has RT behavior.

I think I just meant fThread.Stop() is called in JackThreadedDriver::Stop()
(it was rather late...)

>
> > On exit of freewheeling, fThread.Start() is called and tries to set
> > the thread to the stored priority and fRealTime (still false) which
> > does not work.
>
> ??

fThread.StartSync() in JackThreadedDriver::Start()

JackPosixThread::StartSync() then calls

StartImp(&fThread, fPriority, fRealTime, ThreadHandler, this)

There a non-RT-thread is created because fRealTime JackThreadInterfaceis false and then
pthread_attr_setschedparam() fails...

For me this patch works:
-----------------------------------------------
Index: jackmp/common/JackThread.h
===================================================================
--- jackmp/common/JackThread.h (revision 3694)
+++ jackmp/common/JackThread.h (working copy)
@@ -96,6 +96,7 @@
int Stop();
void Terminate();

+ void enableRealTime() { fRealTime = true; }
int AcquireRealTime();
int AcquireRealTime(int priority);
int DropRealTime();
Index: jackmp/common/JackThreadedDriver.cpp
===================================================================
--- jackmp/common/JackThreadedDriver.cpp (revision 3694)
+++ jackmp/common/JackThreadedDriver.cpp (working copy)
@@ -215,6 +215,7 @@
// Will do "something" on OSX only...
GetEngineControl()->fPeriod = GetEngineControl()->fConstraint = GetEngineControl()->fPeriodUsecs * 1000;
fThread.SetParams(GetEngineControl()->fPeriod, GetEngineControl()->fComputation, GetEngineControl()->fConstraint);
+ fThread.enableRealTime();
if (fThread.AcquireRealTime(GetEngineControl()->fServerPriority) < 0) {
jack_error("AcquireRealTime error");
} else {

-----------------------------------------------

> >
> > Maybe JackThreadedDriver::Init should set fRealTime in fThread
> > (needs function, JackThread::fRealTime is protected), and it should
> > be an error
> > to call AcquireRealTime when fRealTime is not set (or maybe could be
> > just ignored).

At first AcquireRealTime is used to set the priority even though fRealTime
(in JackThreadInterface) is set to false, but StartSync will start a
non-RT-thread later and setting priority fails.

> > ciao
> > Andreas
>
>
> Sorry, I don't understand where you see that in the code. Please
> send a more complete log first.
>
> Stephane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

Re: freewheeling with jackd 1.9.3

2009-11-05T09:04:46Z

On Thu, 5 Nov 2009 00:16:29 +0100
torbenh <torbenh@...> wrote:

> On Tue, Nov 03, 2009 at 01:19:24AM +0100, Andreas Degert wrote:
> > doesn't seem to work under linux when using in realtime mode.
> >
> > Starting works, but stopping gives an error:
> >
> > Cannot set scheduling priority for RT thread res = 22 err = No such
> > file or directory Cannot start thread
> >
> > It seems the member fRealTime of JackThread is not used
> > consistently. In the constructor of JackThreadedDriver fThread is
> > created non-realtime, even if the driver shall be running in
> > realtime (fRealTime set in fDriver).
> >
> > In JackThreadedDriver::Init, fThread.AcquireRealTime is called. It
> > stores the given priority and sets the thread to realtime
> > scheduling, but doesn't set fRealTime in fThread.
> >
> > When freewheeling is entered, scheduling is changed to non-realtime.
> > On exit of freewheeling, fThread.Start() is called and tries to set
> > the thread to the stored priority and fRealTime (still false) which
> > does not work.
> >
> > Maybe JackThreadedDriver::Init should set fRealTime in fThread
> > (needs function, JackThread::fRealTime is protected), and it should
> > be an error to call AcquireRealTime when fRealTime is not set (or
> > maybe could be just ignored).
>
> i dont see this behaviour in svn. i was looking into another issue
> with freewheeling.
> but i think the issue you mention is fixed in svn.

I'm using the current svn version (revision 3694), and in my setup the
error is reproducable (linux kernel is ubuntu 2.6.31-9-rt).

There is another problem with freewheeling when using jconv but that
seems to be a jconv bug (I have a preliminary patch for it).

> >
> > ciao
> > Andreas
> > _______________________________________________
> > 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

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