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, 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
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 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
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
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
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
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 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 i
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?
>
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-c
15 matches
Mail list logo
