headers
Paul Davis | 8 Feb 2003 01:35

Re: A volunteer!

>On Tue, 2003-02-04 at 21:46, Kai Vehmanen wrote:
>> Few high-level issues that come to my mind:
>> 
>> 6. The most common gotchas: preparing for SIGHUP from the server,
>>    allowing override of the client name, etc, etc
>
>I've been wondering about this and I obviously missed the discussion on
>what to do about it, so what is the SIGHUP about and how should I
>prepare for it?

from the source:

	/* if the client is stuck in its process() callback, its not going to 
	   notice that we closed the pipes. give it a little help ... though
	   this could prove fatal to some clients.
	*/

if someone can think of a better way, please let me know.

--p

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
Permalink | Reply | 5 comments |
headers
Jesse Chappell | 8 Feb 2003 02:49

Re: A volunteer!

On Fri, 7 Feb 2003, Paul Davis wrote:

> >On Tue, 2003-02-04 at 21:46, Kai Vehmanen wrote:
> >> Few high-level issues that come to my mind:
> >> 
> >> 6. The most common gotchas: preparing for SIGHUP from the server,
> >>    allowing override of the client name, etc, etc
> >
> >I've been wondering about this and I obviously missed the discussion on
> >what to do about it, so what is the SIGHUP about and how should I
> >prepare for it?
> 
> from the source:
> 
> 	/* if the client is stuck in its process() callback, its not going to 
> 	   notice that we closed the pipes. give it a little help ... though
> 	   this could prove fatal to some clients.
> 	*/

I am trying to deal with this in freqtweak today.

I took a look at the signal handling in ardour and ecasound, each 
takes a slightly different approach but both use sigaction.  I know Paul 
has found some problems with pthreads sigaction wrapper and is calling 
__libc_sigaction.

My question is this:  if jackd (or libjack) is in charge of stopping the 
audio thread in a client, why/how can it be stuck in process() when jackd 
closes the pipes?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Paul Davis | 8 Feb 2003 03:28

Re: A volunteer!

>My question is this:  if jackd (or libjack) is in charge of stopping the 
>audio thread in a client, why/how can it be stuck in process() when jackd 
>closes the pipes?

libjack is in charge of stopping the thread, but it doesn't have
control while the client is calling process(). its like the standard
problem in GUIs when the event handler takes a long time to return
control to the event loop, and until it does, nothing else can happen.

jackd closes the pipes, but the client is still stuck in process(). it
can stay there for as long as it wants. hence the SIGHUP.

>I am using the ecasound signal handling paradigm: ignore several signals
>globally, but do a sigwait on those signals in a new watchdog thread.  
>From reading the manpage, I assumed that the sigwait would get woken when
>those signals hit *any* of the threads, but this does not seem to be the
>case.  The sigaction call ignoring the signals *does* seem to apply to all
>threads.

i this may be why i switched to sigaction. anyway, the trick to using
signals with pthreads is to mask almost all signals in almost all
threads. this forces delivery to just one thread. pthread signal
semantics are really wacky, and the linuxthreads implementation makes
them wackier.

--p

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jack O'Quin | 8 Feb 2003 04:19
Picon

Re: [PATCH] new platforms

guenter geiger <geiger <at> xdv.org> writes:

> What do the API/ABI stability numbers mean ?
> 
> E.g. most of the jack programs depend only on the audio
> API to do Audio I/O. As far as I know, this has almost stayed
> the same since the very beginning. So, as long as I take care
> that I have the correct jackd<->libjack connection, programs
> linked against older versions of jack will still work, right ?
> 
> Considering that data allocation for jack handles and everything
> related is dealt with in the jack library, and is purely dynamic,
> isn't it true that this part of the API/ABI can been seen as
> already stable ?

>From README.developers (in JACK source)...

  2. Client API versioning

  JACK clients are affected by two interfaces, the JACK Client API
  (libjack) and the JACK Client Protocol API (interface between jackd
  and libjack).

  <snip>

  JACK Client Protocol is versioned... <TBD>.

I think this "Client Protocol versioning" is fairly complex.  There is
shared memory between jackd and libjack, as well as a simple
communication protocol.  Any changes in those areas need to be managed
(Continue reading)

Permalink | Reply | 3 comments |
headers
T.P. Reitzel | 8 Feb 2003 04:30
Picon
Favicon

No Output To /dev/dsp Revisited

Hi,

As usual following a post to a mailing list, I found the answer. I 
failed to connect the ZynAddSubFX audio to the ALSA PCM device, not 
/dev/dsp. Anyway, I thank all of those involved in allowing me to use 
audio in this manner on Linux. It's just too cool. Now, I have to deal 
with some latency issues, but the latency is not too bad in the majority 
of cases.

"For God so loved the world that He gave His only begotten Son, that 
whoever believes in Him should not perish but have everlasting life."

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
Permalink | Reply | 0 comments |
headers
Joshua Haberman | 8 Feb 2003 23:10
Gravatar

number of periods on SBLive

Today I was playing around with Kai's strategy of setting the period
size fairly low but setting the number of periods very high.  On my
SBLive I can set playback to -p 256 -n 64, but for capture I am not able
to set the number of periods to any more than 2.  Would this be the
fault of the sblive driver?  I don't see why the card itself would care
how many periods there are...

Also, when trying to use the above strategy in combination with
soft-mode (for playback only), I get this error when trying to make it
xrun:

jackd: pcm.c:5851: snd_pcm_mmap_commit: Assertion `pcm' failed.

(this is with just-pulled CVS).

Josh

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
Permalink | Reply | 1 comment |
headers
Paul Davis | 8 Feb 2003 23:25

Re: number of periods on SBLive

>Today I was playing around with Kai's strategy of setting the period
>size fairly low but setting the number of periods very high.  On my
>SBLive I can set playback to -p 256 -n 64, but for capture I am not able
>to set the number of periods to any more than 2.  Would this be the
>fault of the sblive driver?  I don't see why the card itself would care
>how many periods there are...

i know nothing about the SBLive (really, nothing), but there are many
cards that have restrictions on when they can generate interrupts. the
hammerfall won't allow anything but 2 periods (2 interrupts per
complete traversal of the h/w buffer).

>Also, when trying to use the above strategy in combination with
>soft-mode (for playback only), I get this error when trying to make it
>xrun:
>
>jackd: pcm.c:5851: snd_pcm_mmap_commit: Assertion `pcm' failed.

this sounds like a clear bug in the alsa_driver.c code. can someone
who is seeing this please run jackd under gdb and see where the
problem arises?

--p

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
Permalink | Reply | 0 comments |
headers
Bob Ham | 8 Feb 2003 23:37

Re: JACK 0.50 released

On Sat, 2003-02-08 at 20:06, Taybin Rutkin wrote:
>                    Jack Audio Connection Kit 0.50.0 Released

gcc -O6 -pipe -mcpu=athlon-tbird -march=athlon-tbird -mmmx -m3dnow -fforce-addr
-fmove-all-movables -funroll-loops -DHAVE_CONFIG_H -I. -I. -I.. -I.. -D_REENTRANT
-D_POSIX_PTHREAD_SEMANTICS -Wall -O6 -fomit-frame-pointer -ffast-math -fstrength-reduce
-funroll-loops -fmove-all-movables -g -O2 -MT libjack_la-timestamps.lo -MD -MP -MF
.deps/libjack_la-timestamps.Tpo -c timestamps.c  -fPIC -DPIC -o .libs/libjack_la-timestamps.lo
timestamps.c:23:29: jack/timestamps.h: No such file or directory
timestamps.c:59: parse error before '*' token
timestamps.c: In function `jack_dump_timestamps':
timestamps.c:65: warning: implicit declaration of function `fprintf'
timestamps.c:65: `out' undeclared (first use in this function)
timestamps.c:65: (Each undeclared identifier is reported only once
timestamps.c:65: for each function it appears in.)
timestamps.c:71: warning: implicit declaration of function `fputc'

Sorry to have to report this.  Looks like timestamps.h was left out of
jack/Makefile.am.

Bob

--

-- 
Bob Ham <rah <at> bash.sh>

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bob Ham | 8 Feb 2003 23:39

Re: JACK 0.50 released

On Sat, 2003-02-08 at 22:37, Bob Ham wrote:
> Sorry to have to report this.  Looks like timestamps.h was left out of
> jack/Makefile.am.

alsa_driver.c:35:23: jack/hdsp.h: No such file or directory

This one as well

--

-- 
Bob Ham <rah <at> bash.sh>

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
Permalink | Reply | 0 comments |
headers
Joshua Haberman | 8 Feb 2003 23:40
Gravatar

Re: number of periods on SBLive

On Sat, 2003-02-08 at 14:25, Paul Davis wrote:
> >Today I was playing around with Kai's strategy of setting the period
> >size fairly low but setting the number of periods very high.  On my
> >SBLive I can set playback to -p 256 -n 64, but for capture I am not able
> >to set the number of periods to any more than 2.  Would this be the
> >fault of the sblive driver?  I don't see why the card itself would care
> >how many periods there are...
> 
> i know nothing about the SBLive (really, nothing), but there are many
> cards that have restrictions on when they can generate interrupts. the
> hammerfall won't allow anything but 2 periods (2 interrupts per
> complete traversal of the h/w buffer).

I guess I wasn't aware that the ALSA buffer was a h/w buffer, I thought
it was a software buffer in kernel-space.  I've never written a driver
so I'm not completely clear on the driver interface model.

> >Also, when trying to use the above strategy in combination with
> >soft-mode (for playback only), I get this error when trying to make it
> >xrun:
> >
> >jackd: pcm.c:5851: snd_pcm_mmap_commit: Assertion `pcm' failed.
> 
> this sounds like a clear bug in the alsa_driver.c code. can someone
> who is seeing this please run jackd under gdb and see where the
> problem arises?

For some reason I can't get jackd to start under gdb:

$ sudo gdb jackd
(Continue reading)

Permalink | Reply | 1 comment |

Gmane