jackd running out of shm storage

I'm running today's CVS jack.  It worked for a while.  Then I started
not being able to run any applications.  Jackd does not crash.
Stopping and starting it doesn't help.

Although I have POSIX shm running on my system, and it was detected by
configure, the default build selected shmget, instead.

Here's the output...

  [joq <at> sulphur] joq/ $ jackstart -v -R -d alsa -d delta66 -r 44100 -p 2048
  jackd 0.70.0
  Copyright 2001-2003 Paul Davis and others.
  jackd 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

  JACK compiled with System V SHM support
  capabilities: =i cap_setpcap,cap_ipc_lock,cap_sys_nice,cap_sys_resource+ep
  8118 waiting for signals
  loading driver ..
  new client: alsa_pcm, id = 1 type 1  <at>  0x80599c0 fd = -1
  creating alsa driver ... delta66|2048|2|44100|swmon|swmeter|rt
  new client: alsaplayer-8122, id = 2 type 2  <at>  0x40029000 fd = 10
  port alsaplayer-8122:out_1 has mixdown = 0x4001a6dc
  all 32 bit float mono audio port buffers in use!
  cannot assign buffer for port
  port alsaplayer-8122:out_2 has mixdown = 0x4001a6dc
  all 32 bit float mono audio port buffers in use!
  cannot assign buffer for port
  ++ jack_rechain_graph():

logging proposal

Hi,

just catching up on the logging part of last week's config/logging
thread ...

the logging functionality required for jackd seems to be:

	* cross-reference to jack transport time (Thomas/Steve)
	* keep jackd independent of extra dependencies (Steve)
	* blocking is not a big issue as error reporting happens in
	  a different thread from the audio code. (Steve)
	* consistency with other logging facilities (Guenter)
	* integrate with transport control: "users may want a UI to
	  it, for one thing that would enable you to seek to the
	  position where the logged xrun occurred to check how bad the
	  damage is" (Steve)

how about the following:

	1. log to /var/log/jack.log or use syslog (as Darren suggested)
	2. write all log messages in a standard format, eg. simply:
	
	   "JACK" [TIME] Message

consequences:

	* no extra dependencies (just libc, as Darren noted)
	* syslog is just a daemon listening on a UNIX socket, I can't
	  imagine it'd be any more expensive than printing to the tty?
	* GUI log viewing apps can read/tail the log file, and can

Re: logging proposal

On Thu, May 01, 2003 at 03:57:28 +1000, Conrad Parker wrote:
> 	1. log to /var/log/jack.log or use syslog (as Darren suggested)
> 	2. write all log messages in a standard format, eg. simply:

I think thats fine for normal stuff, but for the xruns I'd rather see the
jack xrun callback implemented.

xruns are a very jack-y thing and it seems like they should have a jack-y
reporting mechanism, especialy as there is supposed to be one, we (ie.
Paul ;) just never implemented it (AFAIK).

- Steve

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: logging proposal

> On Thu, May 01, 2003 at 03:57:28 +1000, Conrad Parker wrote:
> > 	1. log to /var/log/jack.log or use syslog (as Darren suggested)
> > 	2. write all log messages in a standard format, eg. simply:
>

I think the leveled error/debug message system is a very good thing,
especially for a system that still depends on accurate feedback from
users.

I am with Steve when it comes to include "functionality" into this
logging system. I think it should be strictly logging/error reporting,
all functional things like xruns, samplerate changes and whatever is
already implemented should stay there.

So, the usage cases for logging as I see them are:
- installation of jackd, debugging, feedback from users who have problems,
- session logs for statistical purposes. (How many clients, when, how they
  got connected etc.)
- more .. ?

On Thu, 1 May 2003, Steve Harris wrote:
> I think thats fine for normal stuff, but for the xruns I'd rather see the
> jack xrun callback implemented.
>
> xruns are a very jack-y thing and it seems like they should have a jack-y
> reporting mechanism, especialy as there is supposed to be one, we (ie.
> Paul ;) just never implemented it (AFAIK).
>

If you find the time, please try out the patch I sent last week.

Re: logging proposal

>If you find the time, please try out the patch I sent last week.
>For me it works now, after the issue with the filedescriptor has
>been solved. I do not understand why it didn't work before and why
>it works now (and I haven't tried to do so), so I would be happy
>if people would report back. I think the patch is on a hold until
>we can confirm that it doesn't break anything.

actually, its in CVS already. it doesn't break anything for me.

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: logging proposal

On Thu, May 01, 2003 at 08:19:38AM +0100, Steve Harris wrote:
> On Thu, May 01, 2003 at 03:57:28 +1000, Conrad Parker wrote:
> > 	1. log to /var/log/jack.log or use syslog (as Darren suggested)
> > 	2. write all log messages in a standard format, eg. simply:
> 
> I think thats fine for normal stuff, but for the xruns I'd rather see the
> jack xrun callback implemented.

absolutely -- clients should know about them too (ie. let's do both)

K.

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Zombies again

I am using Jack 0.67.2. Is there any known issues with this version that
might cause Zombies?

I have the low latency patches from Planet CCRMA and they are enabled. I
am using a patched Red Hat 8.0. I followed the Planet CCRAM guide and
tuned my system. I also tuned my PCI bus and raised the throughput while
giving my sound card a higher priority than the rest of my system.

Every Jack program I have has this problem from time to time. I have
seen Jack disconnect all clients at the same time too. So it's not any
particular program that's doing it, and I can't put my finger on what
exactly I did to make it happen either. Right now it's very mysterious
and I always assume I am doing something wrong somewhere which makes me
paranoid.

Right now it's not too important, but I would like to be able to setup a
system that could be used for real-time/live performance and not have it
do this. Right now the problem is I don't know what it is doing it and
thus I can't be too sure if things will zomby out in the middle of
critical work.

So either my Jack needs updating, or my system needs some kind of tweak.

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Zombies again

>I am using Jack 0.67.2. Is there any known issues with this version that
>might cause Zombies?

not that i am aware of.

send us the output from jackd so we can what options you are using.

--p

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

CVS commit: document new options for jackd(1)

Just committed the jackd(1) man page updates I had posted yesterday.

Regards,
--

-- 
  Jack O'Quin
  Austin, Texas, USA

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

More and more ports