20 Jan
2003
20 Jan
'03
7:10 a.m.
k_jack is a jack reimplementation, and mammut is a very special sound
transformating sound editor.
Download from http://www.notam02.no/arkiv/src/
New in mammut v0.14->v0.15:
---------------------------
-Removed the synth transform. It was not supposed to be there and had no
function.
-Fixed the wobble transform. Segfaulted with mono-files. (Bug found
by Dave Phillips)
k_jack V0.0.0.5 ALPHA - EXPERIMENTAL
-------------------------------------
ABOUT
k_jack currently consists of k_jackd~, libk_jack and libaipc.
k_jackd~ is a jack server external for pure-data.
libk_jack is (supposed to be) a (somewhat) libjack compatible
library.
Jack applications that want to contact k_jackd~ instead
of jackd must (somehow) be linked with libk_jack and
libaipc instead of libjack.
k_jackd~ does not speak with libjack, and jackd does not
speak with libk_jack.
libaipc is a library for audio interprocess communication,
based on code from the vstserver. A preview version is
included with this version of k_jack. (API is not settled.)
By using libaipc for interprocess communication, and letting
PD take care of various low/mid/high-level audio-stuff,
only a few hundred lines of code is currently used for this
implementation of a simple jack system.
k_jackd~ and libk_jack are not based on the jack sourcecode
found at jackit.sf.net, except for protos in the header files.
COMPILE
1. Go into the aipc/src folder and write make to compile up
libaipc.a
2. Go into the library folder and write make to compile up
libk_jack.a
3. Write make to compile up k_jack~.pd_linux.
4. Relink you jack application(s) somehow.
USAGE
1. Start pd with the "-lib k_jackd~" option.
2. Start a jack application linked with libk_jack.
3. Make an object in pd called "k_jackd~ <clientname>".
Correct number of inlets and outlets will be made
automaticly.
That should be it. Later, when things get more stable, point 3
can do point 2 automaticly.
WHY
use k_jackd~ ?
1. Simple. Only the clientname is used, not the portnames.
2. Easy and powerful interface to control the audioflow.
3. Good performance. Shouldn't be necessary to run as root.
TESTED CLIENTS
simple_client, freqtweak, ceres.
BUGS
Crashes pretty often. Does not clean up. Huge risk of not
freeing shared memory in the current implementation: Client
must exit before server, and client must not crash. And
server must not crash.
CONTACT
Send ideas (especially about the k_jackd~ object syntax),
comments (especially about the libaipc API), questions,
code, food, etc. to k.s.matheussen(a)notam02.no
--
22 Jan
22 Jan
5:28 a.m.
New subject: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Tue, 21 Jan 2003, Paul Davis wrote:
1. I didnt' use much time on this. It was made most to test my new libaipc
library. Its not at all complete either.
2. It was a provocation. :)
For two years (or somethings), people have complained about the bad
performance of the jack system. And I don't think it has been solved. I
dont know about alsa; and doesn't understand the driver-code, so it was
easier for me just to reimplement jack.
k_jack performs okey. You dont have to run things with realtime priority.
3. As I wrote in the README file. Its very simple when you can controle
everything from PD. You could do this with the current implementation of
jack, if you could make jack run without a driver. A dummy-driver is
needed.
--
k_jack is a
jack reimplementation
why? given that we have not even finished the initial implementation, why?
5:49 a.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Wed, 2003-01-22 at 10:21, Kjetil S. Matheussen wrote:
2. It was a provocation. :)
For two years (or somethings), people have complained about the bad
performance of the jack system. And I don't think it has been solved. I
dont know about alsa; and doesn't understand the driver-code, so it was
easier for me just to reimplement jack.
Yes, sure, if you don't understand something, just don't try and
reimplement it.
Could you be more precise on the 'complains about the bad performance of
the jack system' ? Without precise facts, I tend to consider these kind
of assumptions as just crap.
k_jack performs okey. You dont have to run things with realtime priority.
Just laughing :-)))
François Déchelle
7:31 a.m.
New subject: [linux-audio-dev] Re: ANN: k_jack v0.0.0.5 and Mammut v0.15
Francois Dechelle wrote:
Could you be more precise on the 'complains about
the bad performance of
the jack system' ? Without precise facts, I tend to consider these kind
of assumptions as just crap.
jack is not usable at all for a normal end user. without a low-latency
kernel there a pops and klicks everywhere. then jackd freezed my
different debian installations several times (this may kernel related,
but a user don't care when other programs don't freeze the machine). it
consumes rediculous amounts of memory (jackd uses 11MB, pd without gui
1,2MB).
in general the idea that pd is the audio server seems a little bit
weird, but if it's useful in special cases, why not?
8:08 a.m.
New subject: [linux-audio-dev] Re: [Jackit-devel] Re: ANN: k_jack v0.0.0.5 and Mammut v0.15
On Wed, Jan 22, 2003 at 12:24:07 +0100, smoerk wrote:
jack is not usable at all for a normal end user.
without a low-latency
kernel there a pops and klicks everywhere. then jackd freezed my
different debian installations several times (this may kernel related,
but a user don't care when other programs don't freeze the machine). it
consumes rediculous amounts of memory (jackd uses 11MB, pd without gui
1,2MB).
I run jackd as a normal user sometimes, you just have to turn the buffer
size way up (I use 1024), just like in other non SCHED_FIFO apps. Yes, you
will get pops and clicks without a patched kernel, this is true of all
audio APIs under linux.
The 11meg is mostly shared between all the applications, its the IPC
space, and it may not even be mapped in normally, but I'm not sure about
that, it depends on the exact semantics of mlockall(2).
Nore that jack is targetted at realtime audio apps, if you're not using
realtime audio apps you dont need to use it.
- Steve
9:56 a.m.
New subject: [linux-audio-dev] Re: [Jackit-devel] Re: ANN: k_jack v0.0.0.5 and Mammut v0.15
On Wednesday 22 January 2003 13.00, Steve Harris wrote:
On Wed, Jan 22, 2003 at 12:24:07 +0100, smoerk wrote:
If I remember correctly, mlockall and shared memory does not combine
well, it seems like the blocks of shared memory is locked once for each
process (thread?), thus you get a much higher memory use than you
should. I had such problems with BruteFIR, but it is way back I looked
into it so things may have changed (or I did something wrong in the
first place).
/Anders Torger
jack is not usable at all for a normal end user.
without a
low-latency kernel there a pops and klicks everywhere. then jackd
freezed my different debian installations several times (this may
kernel related, but a user don't care when other programs don't
freeze the machine). it consumes rediculous amounts of memory
(jackd uses 11MB, pd without gui 1,2MB).
I run jackd as a normal user sometimes, you just have to turn the
buffer size way up (I use 1024), just like in other non SCHED_FIFO
apps. Yes, you will get pops and clicks without a patched kernel,
this is true of all audio APIs under linux.
The 11meg is mostly shared between all the applications, its the IPC
space, and it may not even be mapped in normally, but I'm not sure
about that, it depends on the exact semantics of mlockall(2). 
10:08 a.m.
New subject: [linux-audio-dev] Re: ANN: k_jack v0.0.0.5 and Mammut v0.15
Francois Dechelle wrote:
try running *any* linux audio program with 1024 frame interrupt
interval and a 2048 frame buffer. it won't be any different.
Could you be more precise on the 'complains
about the bad performance of
the jack system' ? Without precise facts, I tend to consider these kind
of assumptions as just crap.
jack is not usable at all for a normal end user. without a low-latency
kernel there a pops and klicks everywhere. then jackd freezed my different debian installations several times (this may
kernel related,
but a user don't care when other programs don't freeze the machine). it
consumes rediculous amounts of memory (jackd uses 11MB, pd without gui
1,2MB).
this is from a JACK instance that has been running on my system for
about 10 days:
paul 21401 0.0 0.0 1628 548 ttyp2 S Jan21 0:00 jackd -v -d alsa
paul 21402 0.0 0.2 9892 2576 ttyp2 S Jan21 0:00 jackd -v -d alsa
paul 21403 0.0 0.2 9892 2576 ttyp2 S Jan21 0:00 jackd -v -d alsa
paul 21404 0.0 0.2 9892 2576 ttyp2 S Jan21 0:00 jackd -v -d alsa
paul 21405 0.0 0.2 9892 2576 ttyp2 S Jan21 0:00 jackd -v -d alsa
paul 21406 0.3 0.2 9892 2576 ttyp2 S Jan21 2:47 jackd -v -d alsa
the VSZ field says that its using about 9MB, but only about 2MB of
that is actually resident. the gnomepager (as just one example) is
comparable in its use. most of that 9MB, as steve noted, is related to
potential IPC use, and is forced upon us by the granularity of shm
segments.
in general the idea that pd is the audio server seems
a little bit
weird, but if it's useful in special cases, why not?
because it forks the committment to a common interface (hence the need
to relink against a different libjack.
--p
5:56 a.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Wednesday 22 January 2003 10.21, Kjetil S. Matheussen wrote:
On Tue, 21 Jan 2003, Paul Davis wrote:
1. I didnt' use much time on this. It was made most to test my new
libaipc library. Its not at all complete either.
2. It was a provocation. :)
For two years (or somethings), people have complained about the bad
performance of the jack system. And I don't think it has been solved.
I dont know about alsa; and doesn't understand the driver-code, so it
was easier for me just to reimplement jack.
Interesting, I have not seen any complaints on the performance... what
part of the performance is bad? If there is a performance problem it is
probably just to fix that part. A reimplementation is only necessary if
the overall design is completely broken, and well, is it really? Why?
Or, more simply put, why is your implementation better performing than
the "official"? And how have you measured that it is better?
Claiming better performance, and suggesting that the current JACK system
sucks does require some explanation you know :-)
k_jack is
a jack reimplementation
why? given that we have not even finished the initial
implementation, why? k_jack performs okey. You dont have to run things with
realtime
priority.
Yes you do. No reliable low latency without realtime priority.
/Anders Torger
6:03 a.m.
New subject: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Wed, Jan 22, 2003 at 10:21:15 +0100, Kjetil S. Matheussen wrote:
2. It was a provocation. :)
For two years (or somethings), people have complained about the bad
performance of the jack system. And I don't think it has been solved. I
dont know about alsa; and doesn't understand the driver-code, so it was
easier for me just to reimplement jack.
I've not heard of anyone complaining about the bad performance of jack
compared to any other API (baring bugs). Where are these people hanging
out? Perhaps they should file bug reports.
The only system I have the performs badly under jack performs just as
badly under OSS and ALSA.
- Steve
9:56 a.m.
New subject: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
why? given
that we have not even finished the initial implementation, why?
1. I didnt' use much time on this. It was made most to test my new libaipc
library. Its not at all complete either. 2. It was a provocation. :)
For two years (or somethings), people have complained about the bad
JACK hasn't existed for much more than a year. and like others here, i
haven't seen complaints about JACK's performance. i have seen reports
of system lockups (most of which seem traceable to ALSA), and there
have in the past been some very tricky IPC issues to solve when
clients go away.
performance of the jack system. And I don't think
it has been solved. I
dont know about alsa; and doesn't understand the driver-code, so it was
easier for me just to reimplement jack.
k_jack performs okey. You dont have to run things with realtime priority.
this is a joke, right? you **cannot** get reliably low latency
performance on a linux system without SCHED_FIFO or SCHED_RR. i don't
care how you write it, it just won't work.
3. As I wrote in the README file. Its very simple when
you can controle
everything from PD. You could do this with the current implementation of
jack, if you could make jack run without a driver. A dummy-driver is
needed.
then why not write that instead of divert people's attention with a
new implementation.
i find this all very upsetting. you write what appears from its name
to be some kind of IPC library. you decide to test it out. instead of
coming to jackit-devel and saying "i have this cool new library for
IPC. what do you think about using this to fix some problems with
JACK?", you go ahead and partially reimplement JACK, potentially
causing a code fork when we haven't even quite finished the initial
implementation. i have great respect for the audio work you've done so
far, but this is really irritating. i would welcome patches,
redesigns, suggestions, insights into improving JACK, but
reimplementation when you don't even understand it all is just beyond
my sense of what is sensible. there's nothing to stop you from doing
this - this is all open source of course. but i sincerely hope that
people will not use this new implementation unless it can be shown to
have all of the features and less of the drawbacks of the initial one.
--p
1:45 p.m.
New subject: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Wed, 22 Jan 2003, Paul Davis wrote:
why release it?
I guess that might a bit stupid. A show off. But my
opinion is that jack doesn't perform very good, and by
releasing k_jack, I try to prove it. Its a much better
argument than just saying; I get lots of xruns and pops
and clicks whatever I do.
Well, there have been reports about xruns. And, remember the resent
discussion with the wine-guy that couldn't get it to run reliable without
being root or have the capabilities patch?
Yeah, I'm planning to. Havent got that far.
why? given that we have not even finished the initial
implementation, why?
1. I didnt' use much time on this. It was made most to test my new libaipc
library. Its not at all complete either. 2. It was a
provocation. :)
For two years (or somethings), people have complained about the bad
JACK hasn't existed for much more than a year. and like others here, i
haven't seen complaints about JACK's performance. i have seen reports
of system lockups (most of which seem traceable to ALSA), and there
have in the past been some very tricky IPC issues to solve when
clients go away.
Perhaps we have a different opinion about what is reliable performance
then. I dont care if I hear a click or a pop every second hour.
It can be important in some situations, but in that case you should run
with realtime priority.
performance of the jack system. And I don't
think it has been solved. I
dont know about alsa; and doesn't understand the driver-code, so it was
easier for me just to reimplement jack.
k_jack performs okey. You dont have to run things with realtime priority.
this is a joke, right? you **cannot** get reliably low latency
performance on a linux system without SCHED_FIFO or SCHED_RR. i don't
care how you write it, it just won't work.
3. As I wrote
in the README file. Its very simple when you can controle
everything from PD. You could do this with the current implementation of
jack, if you could make jack run without a driver. A dummy-driver is
needed.
then why not write that instead of divert people's attention with a
new implementation.
i find this all very upsetting. you write what appears
from its name
to be some kind of IPC library. you decide to test it out. instead of
coming to jackit-devel and saying "i have this cool new library for
IPC. what do you think about using this to fix some problems with
JACK?",
Oh sorry, I dont beleive the problem is with jacks IPC implementation
(that would be quite unlikely I imagine), but rather the alsa driver. Hmm,
guess I could be wrong, though.
you go ahead and partially reimplement JACK,
potentially
causing a code fork when we haven't even quite finished the initial
implementation. i have great respect for the audio work you've done so
far, but this is really irritating. i would welcome patches,
redesigns, suggestions, insights into improving JACK, but
reimplementation when you don't even understand it all is just beyond
my sense of what is sensible. there's nothing to stop you from doing
this - this is all open source of course. but i sincerely hope that
people will not use this new implementation unless it can be shown to
have all of the features and less of the drawbacks of the initial one.
I didnt think that far. Remember, it was made on a day. Its very
simple. I dont think or hope it will make a code fork.
But, its fine for running freqtweak within pd, using 64 frames
code blocks, as a normal user. I'm not even near the ability
to that with jack.
--
2 p.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
k_jack performs okey. You dont have to run things with
realtime priority.
this is a joke, right? you **cannot** get reliably low latency
performance on a linux system without SCHED_FIFO or SCHED_RR. i don't
care how you write it, it just won't work.
i find this
all very upsetting. you write what appears from its name
to be some kind of IPC library. you decide to test it out. instead of
coming to jackit-devel and saying "i have this cool new library for
IPC. what do you think about using this to fix some problems with
JACK?",
Oh sorry, I dont beleive the problem is with jacks IPC implementation
(that would be quite unlikely I imagine), but rather the alsa driver. Hmm,
guess I could be wrong, though. But, its fine for running freqtweak within pd, using 64
frames
code blocks, as a normal user. I'm not even near the ability
to that with jack.
well, thats definitely a great reason to look at what you've done, but
i'd find it much easier if you could describe what you've done. i've
got a zillion things to do and reading a paragraph of descriptive text
is a lot easier than trying to grasp a new approach from the source.
--p
2:16 p.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
I didnt think that far. Remember, it was made on a day.
Its very
simple. I dont think or hope it will make a code fork.
But, its fine for running freqtweak within pd, using 64 frames
code blocks, as a normal user. I'm not even near the ability
to that with jack.
ok, i take back what i said about it being easier to read text. i
looked at your source code. i now see what you've done.
you've used the existing pd audio processing thread to execute the
"jack" stuff. it still makes call to clients, but you haven't actually
implemented any of the code that actually makes jack interesting: no
jack_port_connect, in particular, and no chaining of clients, forcing
twice as many context switches for multiple clients.
for myself, because its already possible to run pd as a JACK client,
the only interesting thing that i see in this effort is a push to ask
the question: does pd in fact run much better than JACK at the same
latency/buffer settings, and if so, why?
--p
4:52 p.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Wed, 22 Jan 2003, Paul Davis wrote:
for myself, because its already possible to run pd as
a JACK client,
the only interesting thing that i see in this effort is a push to ask
the question: does pd in fact run much better than JACK at the same
latency/buffer settings, and if so, why?
Oops, sorry for not making that question clear. I thought it was
obvious actually.
--
7:25 p.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
for myself,
because its already possible to run pd as a JACK client,
the only interesting thing that i see in this effort is a push to ask
the question: does pd in fact run much better than JACK at the same
latency/buffer settings, and if so, why?
Oops, sorry for not making that question clear. I thought it was
obvious actually.
23 Jan
23 Jan
7:25 a.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Wed, 22 Jan 2003, Paul Davis wrote:
the question or the answer?
and how well does pd handle moving 9-18MB/sec through its interaction
with an audio interface? ie. the read/write access model requires lots
of extra data copying.
I dont understand what you are talking about. Someone at the pd-dev list
perhaps knows.
All I know is that I get very descent realtime performance in pd as a
normal user (even when running locate, starting new programs, etc. at
the same time). I cant get that sort of performance with jack.
Have you tried k_jack now by the way? I'm not making jokes about its
performance.
--
for myself, because its already possible to run pd as
a JACK client,
the only interesting thing that i see in this effort is a push to ask
the question: does pd in fact run much better than JACK at the same
latency/buffer settings, and if so, why?
Oops, sorry for not making that question clear. I thought it was
obvious actually. 
22 Jan
22 Jan
2:50 p.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Wed, Jan 22, 2003 at 06:38:28PM +0100, Kjetil S. Matheussen wrote:
Well, there have been reports about xruns. And,
remember the resent
discussion with the wine-guy that couldn't get it to run reliable without
being root or have the capabilities patch?
Excerpt from the jack FAQ:
"""
Jack requires real-time scheduling (SCHED_FIFO) for reliable, dropout-free
operation, which the vanilla Linux kernel does not adequately support.
Andrew Morton's low-latency patches are currently the most functional
way to add soft-RT scheduling to Linux... However, special privileges are
required to enable low-latency operation, which can be acquired in two ways.
The first option is to run jackd as root in real-time mode...
A newer way to do things ...
requires processes to be able to grant their privileges to other
processes using POSIX 1.e capabilities.
"""
http://jackit.sourceforge.net/docs/faq.php
--
Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's TURTLE ZIRO!
(courtesy of isometric.spaceninja.com)
23 Jan
23 Jan
5:17 p.m.
New subject: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Wed, 22 Jan 2003, Kjetil S. Matheussen wrote:
For two years (or somethings), people have complained
about the bad
performance of the jack system. And I don't think it has been solved. I
dont know about alsa; and doesn't understand the driver-code, so it was
easier for me just to reimplement jack.
First of all, I must say I have nothing against k_jack. I don't think I
fully understand the motives (or the mechanims or design features that
enable better performance), but as Ron Kuper wrote today, competition is
good. I don't think it's fair to expect commercial companies to deal with
competition from FOSS groups, while not welcoming competition from other
FOSS developers. ;)
And yes, there are performance problems with JACK in certain use
scenarios:
1. Running with root privileges (and -R) but with
a standard kernel (no low-latency or preemption patches).
In RT-mode jackd doesn't tolerate client failures. But
if you don't have a low-latency kernel, you will get
50-100ms stalls during normal use. In other words,
running jackd with period size less than 50-100ms
(-p 2048 => 46ms at 44100Hz) _WILL_NOT_ work reliably.
Solution1 => Patch the kernel.
Solution2 => Increase period size (-p 1024 or higher).
Solution3 => Increase period count (-n 4 or higher) and
run without root privileges.
2. Running complex setups without root privileges (and -R).
If you have X clients participating in one JACK
setup, those X clients have to get the CPU during
each engine cycle. Without root privileges (and SCHED_FIFO
scheduling policy), there's no magic that makes sure
that all clients get enough CPU time. So the more
the processes you have, the larger the chance of
a client failure.
Solution1 => Increase the period size or period count.
These _HAVE_ to be notably higher than
with single-thread audio apps.
Solution2 => Run as root (see previous problem scenario).
Solution3 => Patch the kernel and run as root.
k_jack performs okey. You dont have to run things with
realtime priority.
What does "cat /proc/asound/card0/pcm0[cp]/sub0/[hs]w_params" output
while you are running k_jack? This information should help us understand
the benefits of k_jack over current jackd.
--
http://www.eca.cx
Audio software for Linux!
24 Jan
24 Jan
8:56 a.m.
New subject: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Thu, 23 Jan 2003, Kai Vehmanen wrote:
I'm at work now, and we ~only have delta cards. At home I use a built-in
sound-card on an nforce chipset. But I get nearly the same good
performance in pd here as at home. So here is delta44 parameters:
kjetism@hensten /proc/asound/card0/pcm0c/sub0 $ more hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 12
rate: 44100 (44100/1)
period_size: 64
buffer_size: 1728
tick_time: 1953
kjetism@hensten /proc/asound/card0/pcm0c/sub0 $ more sw_params
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 64
xfer_align: 64
start_threshold: 1811939328
stop_threshold: 1811939328
silence_threshold: 0
silence_size: 0
boundary: 1811939328
kjetism@hensten /proc/asound/card0/pcm0c/sub0 $
kjetism@hensten /proc/asound/card0/pcm0p/sub0 $ more hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 10
rate: 44100 (44100/1)
period_size: 64
buffer_size: 1728
tick_time: 1953
kjetism@hensten /proc/asound/card0/pcm0p/sub0 $ more sw_params
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 64
xfer_align: 64
start_threshold: 1811939328
stop_threshold: 1811939328
silence_threshold: 0
silence_size: 0
boundary: 1811939328
kjetism@hensten /proc/asound/card0/pcm0p/sub0 $
Pd is v0.35, running as normal user, no special hardware options except
"-alsa".
--
k_jack
performs okey. You dont have to run things with realtime priority.
What does "cat /proc/asound/card0/pcm0[cp]/sub0/[hs]w_params" output
while you are running k_jack? This information should help us understand
the benefits of k_jack over current jackd.
11 a.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote:
Could you also send an output of pcm0[cp]/sub0/status...?
Anyway, this is very good info.
What does
"cat /proc/asound/card0/pcm0[cp]/sub0/[hs]w_params" output
I'm at
work now, and we ~only have delta cards. At home I use a built-in
sound-card on an nforce chipset. But I get nearly the same good
performance in pd here as at home. So here is delta44 parameters: kjetism@hensten /proc/asound/card0/pcm0c/sub0 $ more
hw_params
[...]
period_size: 64
buffer_size: 1728
So I guess this explains a lot. This equals to running jackd
with "-p 64 -n 27" (and not as root or otherwise it will throw clients
out if they miss one 64 frame deadline).
I'm quite sure you get much more reliable performance this way, although
JACK doesn't take advantage of multip-period buffer configurations very
well. And this has its reasons. With a setup like shown above, you either
get a huge latency (64*1728/44100*1000=2500ms), or you get latency jitter
(latency varies between 1.45ms->2500ms). Both are something we'd _really_
want to avoid.
Because of the above reasons, JACK is designed for two or three
period operation (-n 2 or -n 3). This way we can achieve both low
latency and avoid latency jitter. We could improve reliability by
sacrificing one or both of these goals, but for many of the use scenarios
we are aiming at, this is simply not acceptable.
--
http://www.eca.cx
Audio software for Linux!
11:21 a.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
period_size:
64
buffer_size: 1728
So I guess this explains a lot. This equals to running jackd
with "-p 64 -n 27" (and not as root or otherwise it will throw clients
out if they miss one 64 frame deadline).
I'm quite sure you get much more reliable performance this way, although
JACK doesn't take advantage of multip-period buffer configurations very
well. And this has its reasons. With a setup like shown above, you either
get a huge latency (64*1728/44100*1000=2500ms), or you get latency jitter
11:36 a.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Paul Davis wrote:
Arrghghthghhg! :D 2500ms would have made a nice pro-jack argument, though.;)
So the correct one is the 64*27/44100*1000=39ms you mention.
>> period_size: 64
>> buffer_size: 1728
>So I guess this explains a lot. This equals to running jackd
>with "-p 64 -n 27" (and not as root or otherwise it will throw clients
Well, this is still true.
well. And this
has its reasons. With a setup like shown above, you either
get a huge latency (64*1728/44100*1000=2500ms), or you get latency jitter
not that
large. you don't multiply the period size by the buffer size
and the 1000 is extraneous too. the maximum latency is 1728/44100 =
39ms, i think. i don't of any h/w that has a 2.5 second buffer!! this is still pretty long, and as you note, pd is not
subject to
per-period time limits with this configuration. it can take too long
on up to 26 of 27 periods before there is an xrun.
Hmm, this is quite interesting. With a period size of 64 frames,
you'd get quite a lot of context switches with jackd. Kjetil, does
your ipc-lib make the context switches this often?
Another interesting this is how this high interrupt frequency affects
scheduling of (non-root) processes. I'd guess it could have a notable
impact on reliability... have to try this later today with jackd.
--
http://www.eca.cx
Audio software for Linux!
11:40 a.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Kai Vehmanen wrote:
Yes it does.
--
this is still
pretty long, and as you note, pd is not subject to
per-period time limits with this configuration. it can take too long
on up to 26 of 27 periods before there is an xrun.
Hmm, this is quite interesting. With a period size of 64 frames,
you'd get quite a lot of context switches with jackd. Kjetil, does
your ipc-lib make the context switches this often?
11:53 a.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
Hmm, this is quite interesting. With a period size of
64 frames,
you'd get quite a lot of context switches with jackd. Kjetil, does
your ipc-lib make the context switches this often?
Another interesting this is how this high interrupt frequency affects
scheduling of (non-root) processes. I'd guess it could have a notable
impact on reliability... have to try this later today with jackd.
i have been unable to reliably run jackd with a period size of 64
frames on my dual CPU system. you may recall that i spent considerable
time trying to track down what was preventing it from happening, to no
avail. something in the kernel appears to prevent reliable scheduling
at this level. that is, jackd is not reliably woken by the kernel when
the audio interface interrupt arrives, or rather, its not reliably
woken in time to properly service the interrupt. and if not that, then
the kernel fails to reliably and promptly schedule the other
clients. with only 2 periods per buffer, these scheduling errors are
fatal. it will be interesting to see how 2.5 performs in this regard.
pd (with the configuration kjetil has shown) would be unaffected by
this unless it affected 27 periods in a row, which is rather
unlikely.
note, however, that jack can be used with this same configuration. i
just don't know anyone who would want the results: high interrupt
load, and unacceptably large latency for live performance - the worst
of both worlds :)
--p
12:43 p.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Paul Davis wrote:
Let me just say that I have just tested to see if k_jack could handle
lower latencies than 39msec running one freqtweak. And indeed it does. 9
msecs seems to work fine (no overruns), even when compiling QT3.1.1 in the
background. 4 msecs works too, but overruns happens when doing X things.
The machine this was tested on is an Asus a7n266-vm with xp2100 processor,
wd 8mb cache ide HD, 512 mb memory, inboard geforce2 gfx card and delta 44
soundcard.
kjetism@hensten ~ $ more /proc/version
Linux version 2.4.18-18.7.x (bhcompile(a)bugs.devel.redhat.com) (gcc version
2.96 20000731 (Red Hat Linux 7.3 2.96-112)) #1 Wed Nov 13 20:29:30 EST
2002
On the other hand, 39msec does not work very fine on an other machine.
It is a 733mzh piii with asus cucl2 (or something) mainboard, 256 mb
memory, matrox g550 gfx card, samsung ide HD and delta 44 soundcard.
I _suspect_ its the GFX card (or driver) thats causing this.
kjetism@olivier ~ $ more /proc/version
Linux version 2.4.18-17.7.x (bhcompile(a)daffy.perf.redhat.com) (gcc version
2.96 20000731 (Red Hat Linux 7.3 2.96-112)) #1 Tue Oct 8 13:33:14 EDT 2002
kjetism@olivier ~ $
--
Hmm, this is
quite interesting. With a period size of 64 frames,
you'd get quite a lot of context switches with jackd. Kjetil, does
your ipc-lib make the context switches this often?
Another interesting this is how this high interrupt frequency affects
scheduling of (non-root) processes. I'd guess it could have a notable
impact on reliability... have to try this later today with jackd.
i have been unable to reliably run jackd with a period size of 64
frames on my dual CPU system. you may recall that i spent considerable
time trying to track down what was preventing it from happening, to no
avail. something in the kernel appears to prevent reliable scheduling
at this level. that is, jackd is not reliably woken by the kernel when
the audio interface interrupt arrives, or rather, its not reliably
woken in time to properly service the interrupt. and if not that, then
the kernel fails to reliably and promptly schedule the other
clients. with only 2 periods per buffer, these scheduling errors are
fatal. it will be interesting to see how 2.5 performs in this regard.
pd (with the configuration kjetil has shown) would be unaffected by
this unless it affected 27 periods in a row, which is rather
unlikely.
11:54 a.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Friday 24 January 2003 10:19, Paul Davis wrote:
i don't of any h/w that has a 2.5 second buffer!!
AudioScience cards do -- some of them sport up to 8 MB buffers (dynamically
divided among the various pcm streams). But then , low-lat is not exactly a
pressing design goal there... :)
Cheers!
|-------------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Salem Radio Labs |
| Voice: 1-(540)-341-2880 | 87 Lee Highway, Suite 11 |
| FAX: 1-(540)-341-7176 | Warrenton, VA 20188 |
|-------------------------------------------------------------------------|
| When your client's hopping mad, |
| Put his picture in the ad. |
| If he still should prove refractory, |
| Add a picture of his factory. |
| -- The Advertising Agency Song |
|-------------------------------------------------------------------------|
11:27 a.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Kai Vehmanen wrote:
Pd does not run with 2500ms standard latency, thats for sure. So if
your theory is correct, and it probably gives latency jitter, it
must do a pretty good job at making it unhearable.
Wouldnt it be a good idea to have an option for jack to hide latency
jitter? Or is it to much work (hacking) with the design model?
--
On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote:
Could you also send an output of pcm0[cp]/sub0/status...?
Anyway, this is very good info.
kjetism@hensten /div/notam02/site/qt-x11-free-3.1.1 $ more
/proc/asound/card0/pcm0c/sub0/hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 12
rate: 44100 (44100/1)
period_size: 64
buffer_size: 1728
tick_time: 1953
kjetism@hensten /div/notam02/site/qt-x11-free-3.1.1 $ more
/proc/asound/card0/pcm0c/sub0/sw_params
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 64
xfer_align: 64
start_threshold: 1811939328
stop_threshold: 1811939328
silence_threshold: 0
silence_size: 0
boundary: 1811939328
kjetism@hensten /div/notam02/site/qt-x11-free-3.1.1 $ more
/proc/asound/card0/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 10
rate: 44100 (44100/1)
period_size: 64
buffer_size: 1728
tick_time: 1953
kjetism@hensten /div/notam02/site/qt-x11-free-3.1.1 $ more
/proc/asound/card0/pcm0p/sub0/sw_params
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 64
xfer_align: 64
start_threshold: 1811939328
stop_threshold: 1811939328
silence_threshold: 0
silence_size: 0
boundary: 1811939328
What does
"cat /proc/asound/card0/pcm0[cp]/sub0/[hs]w_params" output
I'm at
work now, and we ~only have delta cards. At home I use a built-in
sound-card on an nforce chipset. But I get nearly the same good
performance in pd here as at home. So here is delta44 parameters:
kjetism@hensten /proc/asound/card0/pcm0c/sub0 $ more hw_params
[...]
period_size: 64
buffer_size: 1728
So I guess this explains a lot. This equals to running jackd
with "-p 64 -n 27" (and not as root or otherwise it will throw clients
out if they miss one 64 frame deadline).
I'm quite sure you get much more reliable performance this way, although
JACK doesn't take advantage of multip-period buffer configurations very
well. And this has its reasons. With a setup like shown above, you either
get a huge latency (64*1728/44100*1000=2500ms), or you get latency jitter
(latency varies between 1.45ms->2500ms). Both are something we'd _really_
want to avoid.
Because of the above reasons, JACK is designed for two or three
period operation (-n 2 or -n 3). This way we can achieve both low
latency and avoid latency jitter. We could improve reliability by
sacrificing one or both of these goals, but for many of the use scenarios
we are aiming at, this is simply not acceptable.
11:42 a.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
I'm quite
sure you get much more reliable performance this way, although
JACK doesn't take advantage of multip-period buffer configurations very
well. And this has its reasons. With a setup like shown above, you either
get a huge latency (64*1728/44100*1000=2500ms), or you get latency jitter
(latency varies between 1.45ms->2500ms). Both are something we'd _really_
want to avoid.
Because of the above reasons, JACK is designed for two or three
period operation (-n 2 or -n 3). This way we can achieve both low
latency and avoid latency jitter. We could improve reliability by
sacrificing one or both of these goals, but for many of the use scenarios
we are aiming at, this is simply not acceptable.
Pd does not run with 2500ms standard latency, thats for sure. So if
your theory is correct, and it probably gives latency jitter, it
must do a pretty good job at making it unhearable. Wouldnt it be a good idea to have an option for jack to
hide latency
jitter? Or is it to much work (hacking) with the design model?
JACK is specifically designed not to allow latency jitter. you can't
properly sync audio+video with latency jitter, because the software
cannot know for sure when the audio it generates will actually become
audible. pd, by contrast, allows significant latency jitter but in all
likelihood doesn't cause it to wobble all that much.
However, as Kai pointed out, nobody runs JACK with -p 64 -n 27, and if
they did, I suspect that they'd get similar performance to pd. it
would be interesting to hear how pd works with, say, a period size of
1024 and a buffer size of 2048 (i.e. 2 mid-size periods) instead of
lots of small periods.
--p
12:24 p.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Paul Davis wrote:
no, there's likely not much latency jitter in pd
either. after the
first 27 periods are filled (which happens in about 39ms), every chunk
of audio delivered by pd to the hardware will be output by the
hardware about 38ms later. the jitter is limited to about 1.45ms,
assuming that pd is roughly keeping up with the hardware. of course,
But there's no way a normal user-space can reliably wake-up every 1.45ms
and manages do finish i/o for next period. The application is bound to
late, much of the time. This is not necessarily fatal if the application
is able to catch up. This is precisely the reason why you can get very
reliably processing with ecasound using -z:intbuf option (maximize use of
soundcard hw buffering).
However, as Kai pointed out, nobody runs JACK with -p
64 -n 27, and if
they did, I suspect that they'd get similar performance to pd. it
Actually, with current jackd you cannot use -p 64 -n 27, as it will
throw the "delay of %.3f usecs exceeds estimated spare time of %.3f;
restart ..." error and stop the alsa_driver. I made a patch that bypasses
this check and managed to get jackd running with -p 64 -n 27. And indeed,
it runs reasonably well on my laptop (normal user space), but I still
get xrun from ALSA. Below are some stats. As you can see from the
'delay' values, the latency jitter is considerable, even though the test
machine was not doing anything else than jackd+ecasound playback.
--cut--
[xxx]$ cat /proc/asound/card0/pcm0p/sub0/{sw_params,hw_params,status}
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 64
xfer_align: 64
start_threshold: 0
stop_threshold: 1728
silence_threshold: 0
silence_size: 0
boundary: 1811939328
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 64
buffer_size: 1728
tick_time: 10000
state: RUNNING
trigger_time: 1043423501.808278
tstamp : 1043423507.253736
delay : 1204
avail : 524
avail_max : 704
-----
hw_ptr : 240268
appl_ptr : 241472
[xxx]$ cat /proc/asound/card0/pcm0p/sub0/{sw_params,hw_params,status}
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 64
xfer_align: 64
start_threshold: 0
stop_threshold: 1728
silence_threshold: 0
silence_size: 0
boundary: 1811939328
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 64
buffer_size: 1728
tick_time: 10000
state: RUNNING
trigger_time: 1043424884.923610
tstamp : 1043424886.101041
delay : 1678
avail : 50
avail_max : 1728
-----
hw_ptr : 51762
appl_ptr : 53440
--cut--
--
http://www.eca.cx
Audio software for Linux!
12:28 p.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
Paul Davis wrote:
JACK is specifically designed not to allow latency
jitter. you can't
properly sync audio+video with latency jitter, because the software
cannot know for sure when the audio it generates will actually become
audible.
Why not ?
If B = buffer size, Fs = sample frequency, T = start time, and the
buffer if pre-filled before starting, then the k-th sample will reach
the DA converter at T + (k + B) / Fs. The time the sample was computed
doesn't matter.
--
Fons Adriaensen
Alcatel Space
12:45 p.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
Paul Davis wrote:
the buffer may have been prefilled. but the problem arises when you've
missed some period deadlines. you no longer have a full buffer and you
don't know how much of the buffer you are filling if you do it 1
period at a time. if you ask how much total space is available, then
that will work, but this then requires dynamic buffer resizing inside
the software, or alternatively, the software has to use buffers sized
to hold the entire hardware buffer, which is very wasteful.
using the process-in-period-sized-blocks model, if you missed several
period deadlines, then the "last" audio you deliver as you finish
catching up has longer latency than the ones you processed at the
beginning.
this is why JACK uses ASIO's model of 2 periods per buffer by default,
and under RT operation it doesn't allow you to miss any deadlines.
--p
JACK is specifically designed not to allow
latency jitter. you can't
properly sync audio+video with latency jitter, because the software
cannot know for sure when the audio it generates will actually become
audible.
Why not ?
If B = buffer size, Fs = sample frequency, T = start time, and the
buffer if pre-filled before starting, then the k-th sample will reach
1:17 p.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Paul Davis wrote:
they did, I suspect that they'd get similar performance to pd. it
would be interesting to hear how pd works with, say, a period size of
1024 and a buffer size of 2048 (i.e. 2 mid-size periods) instead of
lots of small periods.
Pd wont run with that setting:
kjetism@hensten ~ $ pd -audiobuf 29 -blocksize 1024
couldn't open MIDI input device 1
couldn't open MIDI output device 1
opened 0 MIDI input device(s) and 0 MIDI output device(s).
Sample width set to 4 bytes
ALSA: set input channels to 12
alsa: set output channels to 10
ALSA lib pcm_hw.c:454:(snd_pcm_hw_start) SNDRV_PCM_IOCTL_START failed: Broken pipe
snd_pcm_start: Broken pipe
audio I/O stuck... closing audio
Cant get it to start with a blocksize higher than 128.
--
1:02 p.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote:
I'm at work now, and we ~only have delta cards. At
home I use a built-in
sound-card on an nforce chipset. But I get nearly the same good
performance in pd here as at home. So here is delta44 parameters:
But how do you know you are not losing any data? I mean...
kjetism@hensten /proc/asound/card0/pcm0c/sub0 $ more
hw_params
[...]
stop_threshold: 1811939328
... there seems to be no xrun detection enabled. At least pd-0.36 seems to
set "snd_pcm_sw_params_set_xrun_mode(alsa_device.inhandle, sw_params,
SND_PCM_XRUN_NONE);".
This means that you could be having small xruns all the time! Of course,
really long breaks are always audible, but shorter ones are sometimes
quite subtle. Still, you are losing audio data.
--
http://www.eca.cx
Audio software for Linux!
1:11 p.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Kai Vehmanen wrote:
On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote:
I guess so. But its not necesarrily very import, at least not for (most
kinds of) live performance. Is there a quick way to patch pd so that it
detects xruns?
--
I'm at work now, and we ~only have delta
cards. At home I use a built-in
sound-card on an nforce chipset. But I get nearly the same good
performance in pd here as at home. So here is delta44 parameters:
But how do you know you are not losing any data? I mean...
kjetism@hensten /proc/asound/card0/pcm0c/sub0 $
more hw_params
[...]
stop_threshold: 1811939328
... there seems to be no xrun detection enabled. At least pd-0.36 seems to
set "snd_pcm_sw_params_set_xrun_mode(alsa_device.inhandle, sw_params,
SND_PCM_XRUN_NONE);".
This means that you could be having small xruns all the time! Of course,
really long breaks are always audible, but shorter ones are sometimes
quite subtle. Still, you are losing audio data.
1:15 p.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
This means
that you could be having small xruns all the time! Of course,
really long breaks are always audible, but shorter ones are sometimes
quite subtle. Still, you are losing audio data.
I guess so. But its not necesarrily very import, at least not for (most
kinds of) live performance. Is there a quick way to patch pd so that it
detects xruns?
1:19 p.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Paul Davis wrote:
more to the point, what will it do when it detects one?
At least print "xrun %d\n",n++ to stdout or stderr would be a good start I
guess.
--
This means that you could be having small xruns all
the time! Of course,
really long breaks are always audible, but shorter ones are sometimes
quite subtle. Still, you are losing audio data.
I guess so. But its not necesarrily very import, at least not for (most
kinds of) live performance. Is there a quick way to patch pd so that it
detects xruns?
1:21 p.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote:
Yup, replace the set_stop_mode call with:
snd_pcm_sw_params_set_stop_threshold(handle, sw_params, XXX);
... where XXX is the buffersize (ie. 64*27=1728).
The difference is definitely notable. I've just patched jackd to ignore
all xruns the way pd does, and yup, I can do all kinds of stuff as a
normal user (with ./jackd -p 64 -n 27). I'm currently running
ecasound+jackd+freqtweak+qjackconnect as a normal user, with the same
1.5->39ms latency as with pd, and while there are occasional audible
artifacts, it does indeed work!
Also more common jackd setups like 'jackd -d alsa -p 1024 -n 3'
work more reliably this way. But of course, as I noted in my previous
message, we are definitely losing samples even though no errors are
reported.
--
http://www.eca.cx
Audio software for Linux!
This means
that you could be having small xruns all the time! Of course,
really long breaks are always audible, but shorter ones are sometimes
quite subtle. Still, you are losing audio data.
I guess so. But its not
necesarrily very import, at least not for (most
kinds of) live performance. Is there a quick way to patch pd so that it
detects xruns?
2:09 p.m.
New subject: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Kai Vehmanen wrote:
On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote:
Yup, replace the set_stop_mode call with:
snd_pcm_sw_params_set_stop_threshold(handle, sw_params, XXX);
... where XXX is the buffersize (ie. 64*27=1728).
I'm not able to make that work. Just gets a message about stock audio,
no matter how big buffer it is. But thats not important.
This
means that you could be having small xruns all the time! Of course,
really long breaks are always audible, but shorter ones are sometimes
quite subtle. Still, you are losing audio data.
I guess so. But its not
necesarrily very import, at least not for (most
kinds of) live performance. Is there a quick way to patch pd so that it
detects xruns? The difference is definitely notable. I've just
patched jackd to ignore
all xruns the way pd does, and yup, I can do all kinds of stuff as a
normal user (with ./jackd -p 64 -n 27). I'm currently running
ecasound+jackd+freqtweak+qjackconnect as a normal user, with the same
1.5->39ms latency as with pd, and while there are occasional audible
artifacts, it does indeed work!
Thats very nice. How about an option for jack to ignore xruns then?
And, are you absolutely sure its not a bug in alsa, reporting to many
xruns? :)
--
8:44 p.m.
New subject: [linux-audio-dev] pd/k_jack-ish soft-mode patch for jack (was: k_jack v0.0.0.5 and Mammut v0.15)
On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote:
Hmm, what's the exact error you get? One thing that will cause you trouble
is that audio playback will stop after the first xrun. You have to restart
the stream (stop-prepare-start) to recover from an xrun. This is also the
source of the longer audible breaks that occur with current JACK's ALSA
driver when xruns occur.
True, I just posted a patch that does this to jackit-devel. So, so, as I
said, competition is a good thing! ;D So thanks for releasing k_jack
and helping with the debugging/tracing work.
Yup, replace
the set_stop_mode call with:
snd_pcm_sw_params_set_stop_threshold(handle, sw_params, XXX);
I'm not able to
make that work. Just gets a message about stock audio,
no matter how big buffer it is. But thats not important. The difference
is definitely notable. I've just patched jackd to ignore
all xruns the way pd does, and yup, I can do all kinds of stuff as a
normal user (with ./jackd -p 64 -n 27). I'm currently running
Thats very nice.
How about an option for jack to ignore xruns then? And, are you absolutely sure its not a bug in alsa,
reporting to many
xruns? :)
This is very unlikely. The code in alsa-kernel/driver that handles this
logic is _very_ robust. I haven't done much driver work, but I've still
gone through those functions at least a hundred times, and I bet many
other developers have done the same. The common PCM subsystem used by all
ALSA low-level drivers is really high-quality code. The fact that all
drivers can benefit from this common code library is IMHO one of the
biggest benefits ALSA brings!
--
http://www.eca.cx
Audio software for Linux!
22 Jan
22 Jan
6:26 a.m.
New subject: [linux-audio-dev] python sound
Hello,
Just wondering whether people can point me towards any python+sound
activity out there, other than OMDE/PMASK and Thomas Grill's 'pyext' for
PD. Anybody playing with real-time concerns?
d
david casal --0+
---
d.casal(a)uea.ac.uk --9+
---
ecdc.dyndns.org/dc --)+
3:11 p.m.
New subject: [linux-audio-dev] python sound
On Wed, 22 Jan 2003, david casal wrote:
Hello,
Just wondering whether people can point me towards any python+sound
activity out there, other than OMDE/PMASK and Thomas Grill's 'pyext' for
PD. Anybody playing with real-time concerns?
Hi David,
You might take a look at Aura/Serpent from Roger Dannenberg
http://www-2.cs.cmu.edu/~music/aura/
Guenter
28 Jan
28 Jan
5:38 a.m.
New subject: [linux-audio-dev] python sound
guenter geiger wrote:
You might take a look at Aura/Serpent from Roger
Dannenberg
http://www-2.cs.cmu.edu/~music/aura/
this draft has been around for quite some time. anybody know of a
release?
<sk>
8:54 p.m.
New subject: [linux-audio-dev] python sound
Hi,
there's no release as such but apparently Roger Dannenberg kindly passes the
source to whoever is interested. The platform features really interesting
concepts but doesn't seem to be ready-for-use.
greetingsm
Thomas
guenter geiger wrote:
You might take a look at Aura/Serpent from Roger
Dannenberg
http://www-2.cs.cmu.edu/~music/aura/
this draft has been around for quite some time. anybody know of a
release?
<sk>
23 Jan
23 Jan
6:18 p.m.
New subject: [linux-audio-dev] python sound
On Wed, 22 Jan 2003, david casal wrote:
Just wondering whether people can point me towards any
python+sound
activity out there, other than OMDE/PMASK and Thomas Grill's 'pyext' for
PD. Anybody playing with real-time concerns?
Pyecasound is one such package. Basicly it's an implementation of the
Ecasound Control Interface, which allows you to control the "real-time
signal processing" core of ecasound from python. It does _not_ allow you
to modify, generate or consume the actual audio data in python. But you
can control effect parameters in real-time, start/stop/seek, and
issue other such control operations easily from python.
More info at:
http://www.eca.cx/
http://www.eca.cx/eca_links.htm
-> check for instance 'heteca' and 'ecaenveloptor', both
written in python using pyecasound
http://www.wakkanet.fi/~kaiv/ecasound/Documentation/
--
http://www.eca.cx
Audio software for Linux!
24 Jan
24 Jan
6:04 a.m.
New subject: [linux-audio-dev] python sound
Hello Kai,
Thanks go to you, Guenter et al for answers on this! much more goin' on in
pysound world than I thought!
On Fri, 24 Jan 2003, Kai Vehmanen wrote:
Wow.
Hm. Broken?
getting: 'The resource requested /eca_links.htm cannot be found.'
d
david casal --0+
---
d.casal(a)uea.ac.uk --9+
---
ecdc.dyndns.org/dc --)+
9:44 a.m.
New subject: [linux-audio-dev] python sound
On Fri, Jan 24, 2003 at 09:57:39 +0000, david casal wrote:
Hm. Broken?
Try .html
- Steve
7769
days inactive
7777
days old
linux-audio-dev@lists.linuxaudio.org
46 comments
14 participants
participants (14)
-
Anders Torger -
david casal -
Fons Adriaensen -
Francois Dechelle -
Fred Gleason -
guenter geiger -
Kai Vehmanen -
Kjetil S. Matheussen -
Paul Davis -
Paul Winkler -
smoerk -
stefan kersten -
Steve Harris -
Thomas Grill