Re: Setting Sample Rates
Re: Setting Sample Rates
- Subject: Re: Setting Sample Rates
- From: Bill Stewart <email@hidden>
- Date: Tue, 15 Jan 2002 18:14:04 -0800
on 15/1/02 4:35 PM, Jim Dolan wrote:
>
Thanks Bill -
>
>
>> If you're developing a driver for
>
>> hardware that will ship soon, we could possibly work something out with
>
you
>
>> that will work with these tags before the OS actually ships with the
>
>> support, but will then work when it does...
>
I am developing a software application, not a driver. I realize this would
>
be an awkward representation of the device, but am just inventing scenarios
>
to make sure that I can deal with them properly if they come up. There is
>
nothing inherently wrong with just showing all of the channels, and this
>
will most likely be my default.
>
>
>> (2) Do both analog and digital versions of the same stream
>
>> (3) Allow separation of data between analog and digital streams
>
What do these two descriptions mean? Multiple devices? Multiple Sources?
There's the rub:)
>
I don't have a device with multiple sources either - How do sources and
>
streams relate? If I set to a source, what does that change exactly, and
>
how does that impact streams...
>
>
>> I don't know that I see this as a valid distinction if the only
>
>> difference
>
>> is that one of the streams is analog and one digital. The fact that it is
>
>> the same device should mean that the samples will be locked together...
>
I only use analog and digital as an example. It could very well be a Mic
>
input and a line input, or spdif and aes-ubu. The distinction is in how the
>
information will be displayed to the user and which samples I will actually
>
be taking during the IOProcs. I don't want to show the user the all the
>
channels in the display. I also don't want to be taking samples from all the
>
streams if the user is really recording on only 1 of them.
Yes, I understand. I don't think we have a good solution to this until
later... Jeff's previous posts about the fragility of names is also a good
point - can you rely on devices or drivers to provide localized names for
different languages? The USB spec provides for this capability, but I don't
believe we've seen a single device that provides anything more than English
and at a stretch Japanese...
>
Maybe I am making too much of this - but I want to fully understand how all
>
of these pieces fit together before I implement something that only works
>
until someone writes a new driver and uses some weird configuration.
I understand - it is a thorny issue...
Bill
>
Thanks
>
Jimmy D
>
>
>
-----Original Message-----
>
From: Bill Stewart [mailto:email@hidden]
>
Sent: Tuesday, January 15, 2002 7:06 PM
>
To: Jim Dolan; Jeff Moore; CoreAudio API
>
Subject: Re: Setting Sample Rates
>
>
>
on 15/1/02 12:16 PM, Jim Dolan wrote:
>
>
> Hi Jeff -
>
>
>
> I understand that streams only go in one direction and that I get all the
>
> data for all of the streams during each IOProc. Let me re-phrase my
>
> question using just an input device example.
>
>
>
> Suppose that we have an input device with 2 streams, each with two
>
channels.
>
> Lets say that the driver configuration says that stream1 is two channels
>
of
>
> analog input and stream2 is 2 channels of digital input. My application
>
is
>
> not supposed to look like a mixer. I want to supply a mutually exclusive
>
> list of input sources and provide the number of input channels
>
accordingly.
>
> In this case, I do not want to display 4 input channels to the user
>
because
>
> they are not the same type of input. If the user selects analog input,
>
then
>
> I want to display chan 1 & 2 as inputs. If they select digital input, I
>
> still want the display channels 1 & 2, but do the mapping to the proper
>
> stream behind the scenes. Depending on the selection, I would like to take
>
> samples from one stream and ignore samples passed in the other.
>
>
>
In this case then you're not really treating this as a device with 4
>
channels, but as a device with 2 sets of mutually exclusive streams. In some
>
ways you could argue that this isn't a good representation of the device.
>
>
In any case, this is an abstraction that you're choosing to place on top of
>
the hardware... Why would it be a bad thing to present 4 channels to the
>
user. The fact that it has been published as a single device implies that
>
there is some very tight relationship between the different channels as
>
essentially they should be clocked off the same clock.
>
>
> If however the two streams listed above, actually represented 4 channels
>
of
>
> analog line input, I would want to display 4 channels to my user, and I
>
> would want to take samples from both streams during IO. If you follow me
>
so
>
> far, then the question becomes this. How do I tell if the streams are
>
> configured one way or the other.
>
>
I don't know that I see this as a valid distinction if the only difference
>
is that one of the streams is analog and one digital. The fact that it is
>
the same device should mean that the samples will be locked together...
>
>
I also don't think there is any gospel that can be applied here. Some
>
hardware that we've seen will:
>
(1) Allow ONLY analog or digital not both
>
(2) Do both analog and digital versions of the same stream
>
(3) Allow seperation of data between analog and digital streams
>
>
So it is really hard to give you a hard and fast rule here.
>
>
We've definitely look at some tagging of the streams and channels - but as
>
Jeff said in his mail, this will be supported "later", so you'd still have
>
to deal with the current situation. If you're developing a driver for
>
hardware that will ship soon, we could possibly work something out with you
>
that will work with these tags before the OS actually ships with the
>
support, but will then work when it does...
>
>
Feel free to contact Jeff and I off the list to talk about this if you want
>
>
Bill
>
>
> I suppose that if the data sources are implimented, I could cross-check
>
the
>
> channel with the source, but if data sources are not implimented - is
>
there
>
> still a way...
>
>
>
> Thanks Jimmy D.
>
>
>
> -----Original Message-----
>
> From: Jeff Moore [mailto:email@hidden]
>
> Sent: Tuesday, January 15, 2002 2:34 PM
>
> To: CoreAudio API
>
> Subject: Re: Setting Sample Rates
>
>
>
>
>
> on 1/15/02 10:24 AM, Jim Dolan <email@hidden> wrote:
>
>
>
>> Ok - So how do I know which channels from which streams to actually
>
record
>
> or
>
>> playback to. If for example streams were divided up based on input type
>
-
>
> I
>
>> would only want to take samples from one of the streams ie: the one I am
>
>> inputting from. Likewise, I may only want to output to a particular
>
>> connection. Since I have no way of associating the stream to an input or
>
>> output what should I do? I was thinking of creating some UI that allowed
>
> the
>
>> user to map the streams with inputs/output's and set the number of busses
>
> for
>
>> each. This is a lot of work, and can be avoided if I could get the
>
> information
>
>> from the streams or the device
>
>
>
> I really can't visualize what you are talking about here. Streams only go
>
in
>
> one direction, either in our out. I also have no clue what you mean by
>
> "busses for each".
>
>
>
> Fundamentally, the information for the routing of the data to a specific
>
> jack isn't currently being supplied. This means you are on your own for
>
the
>
> time being.
>
>
>
mailto:email@hidden
>
tel: +1 408 974 4056
>
__________________________________________________________________________
>
"We'll talk about it later...."
>
"When?"
>
"In a future life when we're both cats"
>
__________________________________________________________________________
>
_______________________________________________
>
coreaudio-api mailing list | email@hidden
>
Help/Unsubscribe/Archives:
>
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
>
Do not post admin requests to the list. They will be ignored.
mailto:email@hidden
tel: +1 408 974 4056
__________________________________________________________________________
"We'll talk about it later...."
"When?"
"In a future life when we're both cats"
__________________________________________________________________________