Re: in & out Callbacks
Re: in & out Callbacks
- Subject: Re: in & out Callbacks
- From: Jeff Moore <email@hidden>
- Date: Tue, 15 Feb 2005 11:50:49 -0800
We can't and won't talk about what's in Tiger or any other future
release in this forum. You guys should know better than to ask
questions about future releases here.
Also, your statement #1 is a faulty assumption on your part with
respect to USB Audio class compliant devices. There is nothing is the
spec that says that this is the case. In fact, there is plenty in the
spec that says specifically that this is _not_ the case (e.g. the spec
says outright that the input and output can have different nominal
sample rates). Indeed, it has been my experience that few if any
bidirectional USB Audio devices will have the same observed sample rate
for both the input section and the output section.
On Feb 15, 2005, at 2:30 AM, Lubor Prikryl wrote:
Hi,
This is what I just wanted to ask.
More specifically, there are three situations:
1 - We have devices with exactly the same SR (class compl. USB,
externally synced devices), where number of i and o calls is the same
in average, although drifting
2 - We have arbitrary devices set to the same nominal SRs while the
actual SRs are slightly different
3 - We have devices with different SR settings which require format
conversion
We can solve the third situation using additional CA format
converter, but we need the first two. Bill, what exactly (1 or 1+2)
is solved in Tiger? Grouping of externally synchronized or arbitrary
devices?
I think the approach for 1) and 2) differs significantly in the
latency increase.
Thanks
Lubor
On 15.2.2005, at 9:18, Stéphane Letz wrote:
- Are the two Callbacks 1a and 1b always guaranteed to be called
exactly alternating i-o-i-o-i-o-i-o... if running in one thread?
>Absolutely not. While they will for the most part stay in the order
>that they initially are called, the threads are working for two
>different devices and as such have totally different time lines.
They
>can easily drift to the point where the order of calling can be
>inverted. Plus, if their duty cycles dictate that they are to wake
up
>at times that are close together, the order of operations will be
>essentially random each time.
>This is why I talked about using AudioDeviceStartAtTime(). It
doesn't
>cure the drift problem, but it does give you the ability to phase
the
>threads in the order in which you want them, with the approximate
>timing you want.
Will this "complexity" when handling USB devices be improved in
Tiger? I read somewhere that Tiger will provide ways to synchronize
several audio devices an allows to see them as on "unique" device.
Since this question about USB devices comes regularly, it seems that
it would be a big improvement if the coreaudio layer could take
this two devices question and solve it once for all developers, so
that using an USB device would be similar to using other full-duplex
ones.
Stephane Letz
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
Jeff Moore
Core Audio
Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden