On Tue, 18 Sep 2001, Curtis Veit wrote:
> I have been watching the 0.9 betas mature.
> It looks to me as though it may not be much longer
> until a final release. This made me wonder if anyone is
> bring the documentation up to date. I'd be interested
> helping on this
So would I. I
Hi,
I have been watching the 0.9 betas mature.
It looks to me as though it may not be much longer
until a final release. This made me wonder if anyone is
bring the documentation up to date. I'd be interested
helping on this (seeing that I haven't found enough
time to get into helping on the
>Ok, I think I understand most of it, certainly that my application can do
>without it (and I tried and it works without). But what is a possible use
>of this kind of settings? Is it only of interest to low-latency
>applications?
it will affect how much work the CPU does. if you set the period si
On Tue, Sep 18, 2001 at 07:20:21PM +0200, Remco Poelstra wrote:
> Ok, I think I understand most of it, certainly that my application can do
> without it (and I tried and it works without). But what is a possible use
> of this kind of settings? Is it only of interest to low-latency
> applications?
On 2001.09.16 21:49 Paul Davis wrote:
> its the interval between interrupts from the hardware. this defines
> the input latency, since the CPU will not have any idea that there is
> data waiting until the audio interface interrupts it.
>
> the audio interface has a "pointer" that marks the curren
In message <[EMAIL PROTECTED]>you write:
>> > The only thing I can think of is that the sound card clock is drifting
>> > too.
>>
>> Do you mean the drift as the difference between the "real" wall-clock
>> time and sequencer ticks? Or between the sequencer time and ticks?
>
>The sequencer clock
At Tue, 18 Sep 2001 10:03:45 -0600,
Jack Moffitt wrote:
>
> > > The only thing I can think of is that the sound card clock is drifting
> > > too.
> >
> > Do you mean the drift as the difference between the "real" wall-clock
> > time and sequencer ticks? Or between the sequencer time and ticks?
> X = real interrupt period, x = truncated in nsecs
>
> X = x + a
>
> Y = real tick duration Y, y = truncated in nsecs
>
> Y = y + b
So X/Y is ticks/period, and x/y is what we are calulating as ticks per
period. That means (X/Y) - (x/y) is the drift in
On Tue, 18 Sep 2001, Steve Harris wrote:
> Hi,
>
> We've installed a ice1712 based card for midi (midiman 2496 or
> something like that) at work, and we're trying to get a program
> written in java working.
>
> We're using alsa 0.9.0beta7.
>
> When we open /dev/midi00 (with dd, java etc), it is b
At Tue, 18 Sep 2001 10:07:37 +0200 (CEST),
Jaroslav wrote:
>
> On Mon, 17 Sep 2001, Takashi Iwai wrote:
>
> > Hi,
> >
> > in this weekend I worked on the ALSA timer stuffs, too.
> > The attached patch includes:
> >
> > - use standard list struct for handling of timers.
>
> It looks good.
>
> >
> > The only thing I can think of is that the sound card clock is drifting
> > too.
>
> Do you mean the drift as the difference between the "real" wall-clock
> time and sequencer ticks? Or between the sequencer time and ticks?
The sequencer clock generates ticks on the pcm clock interrupt. But
Hi Jack,
At Mon, 17 Sep 2001 20:06:48 -0600,
Jack Moffitt wrote:
>
> > Ah, I meant that total .851 msec for 5 minutes.
> > Thus it's still enough small. Sorry, I was too lame.
> >
> > I guess the problem is hidden somewhere in other place..
>
> I noticed that after I posted. Sorry.
>
> If th
Hi,
We've installed a ice1712 based card for midi (midiman 2496 or
something like that) at work, and we're trying to get a program
written in java working.
We're using alsa 0.9.0beta7.
When we open /dev/midi00 (with dd, java etc), it is buffered, whereas oss
devices didn't appear to be. Is ther
On Mon, Sep 17, 2001 at 12:42:47PM -0400, Paul Davis wrote:
> >is anyone out there working on the seasound solo driver? if not, what
> >can i do to start work on it myself? i haven't written a driver before,
> >but have some experience with programming languages and would like to
> >learn.
>
> i'
Thes is a good summary of problems of precision found is tempo/ticks
conversions
and possible solutions by using integer and keeping fractionnal parts.
http://www.manning.com/Messick/Chapter7.html
Stephane Letz
Grame: Centre National de creation musicale
9, Rue du Garet
69001 Lyon
Tel: 04-72
At Tue, 18 Sep 2001 13:24:03 +0200 (CEST),
Jaroslav wrote:
>
> Hello,
>
> I would like to discuss the desired behaviour for suspend/resume
> cycles for the PCM interface. The actual implementation of PM in ALSA
> drivers silently assumes that the application doesn't handle anything and
> t
Hello,
I would like to discuss the desired behaviour for suspend/resume
cycles for the PCM interface. The actual implementation of PM in ALSA
drivers silently assumes that the application doesn't handle anything and
the PCM stream continues with the time gap. It doesn't look bad until the
On Mon, 17 Sep 2001, Takashi Iwai wrote:
> Hi,
>
> in this weekend I worked on the ALSA timer stuffs, too.
> The attached patch includes:
>
> - use standard list struct for handling of timers.
It looks good.
> - removal of resolution in sequencer -- sequencer invokes timer with
> the highest
18 matches
Mail list logo
