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:
http://www.eca.cx/
Wow.
http://www.eca.cx/eca_links.htm
Hm. Broken?
getting: 'The resource requested /eca_links.htm cannot be
Hi.
Today I relased ZynAddSubFX 1.0.5.
It is a powerfull software synthesizer for Linux.
News:
- The bug that crashed ZynAddSubFX if you change
some effect parameters, it is realy removed (I forgot
to update the file before upload)
- Other bugfixes and code clean-ups
- Added a
Hi all,
I was looking for a good, up-to-date documentation pointer upon software features
provided by alsa. But I'm new to this architecture and I might be intoxicated by
some kernel streaming architectures : is there a kind of hardware abstraction with
ALSA, e.g. features that are managed by
On Thu, 23 Jan 2003, Kai Vehmanen wrote:
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
On Thu, 2003-01-23 at 21:23, Bob Ham wrote:
On Thu, 2003-01-23 at 18:02, François Déchelle wrote:
I'm guessing that Paul was wondering how you tell the LADSPA plugin what
jMax patch to load. Well, thats what I'm wondering anyway ;)
If the patch is included in the .c, then you tell it
I was looking for a good, up-to-date documentation pointer upon software featu
res provided by alsa. But I'm new to this architecture and I might be intoxic
ated by some kernel streaming architectures : is there a kind of hardware ab
straction with ALSA, e.g. features that are managed by the
On Fri, Jan 24, 2003 at 09:57:39 +, david casal wrote:
http://www.eca.cx/eca_links.htm
Hm. Broken?
Try .html
- Steve
On Thu, Jan 23, 2003 at 07:10:47 +, Mark Knecht wrote:
Vishal,
I think there was some work done in the last few months on this.
Check the archives. I think Steve Harris was one of the participants. I
know they were working on modeling tubes, and I seem to remember someone
talking about
On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote:
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
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
On Fri, 24 Jan 2003, Paul Davis wrote:
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
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
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... :)
At Fri, 24 Jan 2003 08:09:44 -0500,
Paul Davis wrote:
the other alternative that many of us here like rather a lot is JACK
(http://jackit.sf.net/), which provides a different model: data
sharing between applications, shared access to hardware,
sample-synchronous execution of all
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
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 =
At Fri, 24 Jan 2003 08:09:44 -0500,
Paul Davis wrote:
the other alternative that many of us here like rather a lot is JACK
(http://jackit.sf.net/), which provides a different model: data
sharing between applications, shared access to hardware,
sample-synchronous execution of all
On Fri, 24 Jan 2003, Paul Davis wrote:
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
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 =
On Friday 24 January 2003 17.27, Paul Davis wrote:
[...]
(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?)
because that means we have a config file, which means we need a
config file parser, which means we need to replicate a bunch of
code or link against another library. if jackd was
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
On Fri, 24 Jan 2003, Kai Vehmanen wrote:
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
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
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
On Fri, 24 Jan 2003, Paul Davis wrote:
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
On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote:
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
(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?)
because that means we have a config file, which means we need a
config file parser, which means we need to replicate a bunch of
code or link against another library. if jackd was a commonly
executed command for users, i could justify
On Friday 24 January 2003 18.22, Paul Davis wrote:
(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?)
because that means we have a config file, which means we need a
config file parser, which means we need to replicate a bunch of
code or link against another library. if jackd was a
On Fri, Jan 24, 2003 at 11:27:12 -0500, Paul Davis wrote:
not at all. it would allow programs to be run with no context switch
overhead if they are started alone without jackd, which would be
rather nice. we need to get in-process clients done first, though.
Agreed and agreed.
(btw, why
On Fri, 24 Jan 2003, Kai Vehmanen wrote:
On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote:
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
(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?)
because that means we have a config file, which means we need a config
file parser, which means we need to replicate a bunch of code or link
against another library. if jackd was a commonly executed command for
users, i could justify
On Friday 24 January 2003 19.29, Paul Winkler wrote:
On Fri, Jan 24, 2003 at 11:27:12AM -0500, Paul Davis wrote:
i've had the same idea. my approach would basically be to have
libjack try to contact the server. if it fails, then it just
starts up a thread to run the audio loop, and then
On Friday 24 January 2003 05:06, Vishal wrote:
Hi all,
I happen to be both a linux programmer and a guitar freak. Off late
the guitar industry has seen these amp simulators some into being: line6
POD, Vamp and the likes... i was wondering whether i could build my own
such amp simulator.
(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?)
On Fri, Jan 24, 2003 at 11:27:12 -0500, Paul Davis wrote:
because that means we have a config file, which means we need a config
file parser, which means we need to replicate a bunch of code or link
against another library. if
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);
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.
Hmm, what's
35 matches
Mail list logo
