>> 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
>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
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 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.
>> 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
>> 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
>> 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 que
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
>> >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.
>>
>Perhaps we have a different o
>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
On Wednesday 22 January 2003 10.21, Kjetil S. Matheussen wrote:
> On Tue, 21 Jan 2003, Paul Davis wrote:
> > >k_jack is a jack reimplementation
> >
> > 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 n
12 matches
Mail list logo
