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, w
> > >(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 li
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
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 th
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 instantiate the client as an
> in-process client.
i must
> >(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 ju
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 da
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 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.
>> >(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 cou
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
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 im
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
>> 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 perform
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
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 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
>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 f
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 freque
>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 a
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,
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 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 applicat
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... :)
Chee
>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.
On Fri, 24 Jan 2003, Kai Vehmanen wrote:
> > 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
>> 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
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 li
On Fri, 24 Jan 2003, Kai Vehmanen wrote:
> 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 near
>> 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
>JA
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.
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 a
On Fri, Jan 24, 2003 at 09:57:39 +, david casal wrote:
> > http://www.eca.cx/eca_links.htm
>
> Hm. Broken?
Try .html
- Steve
>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 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
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
Nasca,
Hi. I sent you a message before but didn't get a reply. I very much
like the sound of your synth, but I work in a Jack oriented environment.
When will you add Jack support? I hope you will.
Thanks,
Mark
On Fri, 2003-01-24 at 10:01, Nasca Paul wrote:
> Hi.
> Today I relased ZynAddSubFX
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 b
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 Gl
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 foun
40 matches
Mail list logo
