Mark Williams | 1 Jan 06:33 2011
Picon

Unmaintaned jack client now dies... help with what i need to fix?

Hi all,

The software in question is brutefir.
It hasnt been updated in ~3 years, and it seems the JACK API has now
changed enough that its having issues.

brutefir works for 5 - 10sec as it should, with some warnings, and
then exits with an error:
......
JACK I/O: JACK reported an error: jack_client_new: deprecated
JACK I/O: Warning: JACK thread has priority 75, but BruteFIR expected 9.
......
JACK I/O: Warning: JACK thread has priority 75, but BruteFIR expected 9.
......
Audio processing starts now...
JACK I/O: JACK reported an error: JackActivationCount::Signal value = 0 ref = 2
An error occured in a callback I/O module.

Can you guys give me any kind of hints as to what i need to be doing
to fix this problem in the brutefir code?

Thanks in advance!
Mark Williams.
Tommaso Cucinotta | 1 Jan 17:14 2011
Picon

Re: [PATCH] [cgroups] add basic support to move jack client threads into the same cgroup as jackd

Sorry for the late reply . . .

Il 19/12/2010 15:21, torbenh ha scritto:
> On Sat, Dec 18, 2010 at 09:40:51PM +0100, Tommaso Cucinotta wrote:
>> One last question (I couldn't go through your patch, however): what
>> about those additional real-time threads that are provided by
>> "pthread_t" to the jack library ?
> i dont understand this. nothing provides threads to the libjack library.

AFAIK, sometimes Jack clients create threads by themselves, then
they rely on the Jack lib in order to give them the same RT settings
as the other Jack client threads. The Jack lib function being called
should be:

       int jack_acquire_real_time_scheduling (pthread_t thread, int 
priority);

http://jackaudio.org/files/docs/html/group__ClientThreads.html#ga09d1c5ce0bb854eac0dba1ec950a3197

which in turn calls

   int JackThread::AcquireRealTimeImp(pthread_t thread, int priority);

and this constitutes an issue because in this case the Jack framework
has only access to the pthread_t, and it does not create the thread
in the 1st place (like it happens instead with jack_client_create_thread()).

I agree that for threads created by the Jack library itself there are no 
problems at all.

(Continue reading)

Harry Van Haaren | 1 Jan 18:03 2011
Picon

Re: Unmaintaned jack client now dies... help with what i need to fix?

I'm going to help with the easiest one:

jack_client_new() has been deprecated in favour of jack_client_open()
The open() function takes a couple more arguments, and hence is more flexible.
This link shows the usage of open().

Good luck! -Harry

On Sat, Jan 1, 2011 at 5:33 AM, Mark Williams <mwp <at> mwp.id.au> wrote:
Hi all,

The software in question is brutefir.
It hasnt been updated in ~3 years, and it seems the JACK API has now
changed enough that its having issues.

brutefir works for 5 - 10sec as it should, with some warnings, and
then exits with an error:
......
JACK I/O: JACK reported an error: jack_client_new: deprecated
JACK I/O: Warning: JACK thread has priority 75, but BruteFIR expected 9.
......
JACK I/O: Warning: JACK thread has priority 75, but BruteFIR expected 9.
......
Audio processing starts now...
JACK I/O: JACK reported an error: JackActivationCount::Signal value = 0 ref = 2
An error occured in a callback I/O module.

Can you guys give me any kind of hints as to what i need to be doing
to fix this problem in the brutefir code?

Thanks in advance!
Mark Williams.
_______________________________________________
Jack-Devel mailing list
Jack-Devel <at> lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

_______________________________________________
Jack-Devel mailing list
Jack-Devel <at> lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
David Henningsson | 1 Jan 20:26 2011

Re: [PATCH] [cgroups] add basic support to move jack client threads into the same cgroup as jackd

On 2010-12-24 10:08, Lennart Poettering wrote:
> On Fri, 24.12.10 09:53, Dhaval Giani (dhaval.giani <at> gmail.com) wrote:
>
>>> I do believe that the short time fix for this problem is that
>>> libcgroup/Ubuntu should stop sorting processes into any non-root cgroup
>>> hierarchy by default.
>>
>> Ubuntu needs to fix that.
>
> Yes, they do. David?

Guess that's me. I'm not really a scheduling expert and had never heard 
of cgroups before this bug showed up, but I'll try to grab the right 
people at Canonical's next sprint, which is 10-14 January. That is, 
unless somebody fixes it sooner.

While we're at it, there is this page: 
http://jackaudio.org/linux_group_sched - which gives the impression that 
Jack-RT is not working on Ubuntu 10.10 (Maverick). AFAIK, this is wrong 
(at least I can run both PA, Rtkit and Jack in 10.10 without them 
complaining about missing RT), the only version that needs fixing is 
11.04, which is in development. Paul, can you fix the webpage?

--

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
fons | 2 Jan 02:58 2011
Picon

Re: Unmaintaned jack client now dies... help with what i need to fix?

On Sat, Jan 01, 2011 at 04:03:23PM +1030, Mark Williams wrote:

> The software in question is brutefir.
> It hasnt been updated in ~3 years, and it seems the JACK API has now
> changed enough that its having issues.
> 
> brutefir works for 5 - 10sec as it should, with some warnings, and
> then exits with an error:
> ......
> JACK I/O: JACK reported an error: jack_client_new: deprecated

As already pointed out this should use jack_client_open() instead.

> JACK I/O: Warning: JACK thread has priority 75, but BruteFIR expected 9.

No Jack application should expect any particular value for this priority,
so these warnings should probably just be removed. If BruteFIR really
requires some exact priorites that could be related to how it handles
multiple CPUs, see below. This would still be broken design.

> JACK I/O: JACK reported an error: JackActivationCount::Signal value = 0 ref = 2
> An error occured in a callback I/O module.

Looks like a typical Jack2 error. Don't know what it means, maybe the
Jack2 authors will explain.

IIR, to support dividing the work over multiple CPUs BruteFIR uses separate
processes rather than threads. This probably complicates things more than it
should as it requires shared memory and inter-process synchronisation.
Fixing this would require a major redesign.

IHMO, if BruteFIR has to have a future its author should fix these issues.

There are also alternatives to BruteFIR, e.g. the zita-convolver library
and jconvolver (of which I am the author). 

Ciao,

--

-- 
FA

There are three of them, and Alleline.
Dhaval Giani | 2 Jan 05:18 2011
Picon

Re: [PATCH] [cgroups] add basic support to move jack client threads into the same cgroup as jackd

On Sun, Jan 2, 2011 at 12:56 AM, David Henningsson
<david.henningsson <at> canonical.com> wrote:
> On 2010-12-24 10:08, Lennart Poettering wrote:
>>
>> On Fri, 24.12.10 09:53, Dhaval Giani (dhaval.giani <at> gmail.com) wrote:
>>
>>>> I do believe that the short time fix for this problem is that
>>>> libcgroup/Ubuntu should stop sorting processes into any non-root cgroup
>>>> hierarchy by default.
>>>
>>> Ubuntu needs to fix that.
>>
>> Yes, they do. David?
>
> Guess that's me. I'm not really a scheduling expert and had never heard of
> cgroups before this bug showed up, but I'll try to grab the right people at
> Canonical's next sprint, which is 10-14 January. That is, unless somebody
> fixes it sooner.
>

Its quite straightforward, the config file at /etc/sysconfig/cgconfig should say
CREATE_DEFAULT=no as opposed to CREATE_DEFAULT=yes

Thanks,
Dhaval
David Henningsson | 3 Jan 16:21 2011

Re: [PATCH] [cgroups] add basic support to move jack client threads into the same cgroup as jackd

On 2011-01-02 05:18, Dhaval Giani wrote:
> On Sun, Jan 2, 2011 at 12:56 AM, David Henningsson
> <david.henningsson <at> canonical.com>  wrote:
>> On 2010-12-24 10:08, Lennart Poettering wrote:
>>>
>>> On Fri, 24.12.10 09:53, Dhaval Giani (dhaval.giani <at> gmail.com) wrote:
>>>
>>>>> I do believe that the short time fix for this problem is that
>>>>> libcgroup/Ubuntu should stop sorting processes into any non-root cgroup
>>>>> hierarchy by default.
>>>>
>>>> Ubuntu needs to fix that.
>>>
>>> Yes, they do. David?
>>
>> Guess that's me. I'm not really a scheduling expert and had never heard of
>> cgroups before this bug showed up, but I'll try to grab the right people at
>> Canonical's next sprint, which is 10-14 January. That is, unless somebody
>> fixes it sooner.
>>
>
> Its quite straightforward, the config file at /etc/sysconfig/cgconfig should say
> CREATE_DEFAULT=no as opposed to CREATE_DEFAULT=yes

Hmm, it doesn't seem to be that simple unfortunately. There is no such 
file present. There is a package called "cgroup-bin" that adds something 
similar into /etc/default/cgconfig, but that package isn't installed 
either. Not even the cgroup library package is installed.

http://git.debian.org/?p=collab-maint/libcgroup.git;a=blob;f=debian/cgroup-bin.cgconfig.default;h=5a61bf6e9878250557f3c4993376c7c408135b89;hb=HEAD

I also tried manually adding a /etc/sysconfig/cgconfig file with 
"CREATE_DEFAULT=no" in it, but it didn't help either.

--

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
torbenh | 3 Jan 21:12 2011
Picon
Picon

Re: build/runtime location of fifos, sockets

On Thu, Dec 30, 2010 at 03:15:22PM -0500, Paul Davis wrote:
> On Thu, Dec 30, 2010 at 3:02 PM, Fernando Lopez-Lezcano
> <nando <at> ccrma.stanford.edu> wrote:
> > Hi all, I'd like to request a new feature in all versions of jack (1, 2,
> > tschack, etc). It looks like we may need to be able to change the directory
> > in which Jack stores its pipes, sockets, etc. Currently it is hardwired to
> > /dev/shm (at least in jack2). It would be nice to have a build option and
> > even better, a additional runtime option for changing that.
> 
> its almost there in jack1 already, search configure.ac for
> DEFAULT_TMP_DIR and you'll see that it is defined at configure time,
> but currently lacks any way to set it with a ./configure argument.
> that's all. it gets redefined for at least 1 platform.

./configure --with-default-tmpdir=/xyz 

its settable. and it has been there for quite some time nowadays.
jack1 and tschack only, probably.

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

--

-- 
torben Hohn
Harry Van Haaren | 5 Jan 17:25 2011
Picon

Jack MIDI: In order of time?

Hey all,

I'm wondering does  jack_midi_event_get  return the MIDI events in chronological order?

Ie: I have 2 events in one "nframes" period:
event 1 is at nframe 25, event 2 is at nframe 40.

Will jack_midi_event_get  always  return "event 1" the first time I call it, and "event 2" the second?

Cheers, -Harry

_______________________________________________
Jack-Devel mailing list
Jack-Devel <at> lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Paul Davis | 5 Jan 17:26 2011

Re: Jack MIDI: In order of time?

On Wed, Jan 5, 2011 at 11:25 AM, Harry Van Haaren <harryhaaren <at> gmail.com> wrote:
> Hey all,
>
> I'm wondering does  jack_midi_event_get  return the MIDI events in
> chronological order?
>
> Ie: I have 2 events in one "nframes" period:
> event 1 is at nframe 25, event 2 is at nframe 40.
>
> Will jack_midi_event_get  always  return "event 1" the first time I call it,
> and "event 2" the second?

yes. in addition, as documented in the API specs, they must be
*written* in time order as well.

Gmane