Using control parameter constraint API

[Stéphane Letz]

Hi Nedko,

I'm thinking in using the control parameter constraint API to get  
infos on available CoreAudio devices on OSX. The thing is that several  
CoreAudio devices could be available on the machine, each one with  
different parameter constraints like for instance:

"Built-in Line input"  : inputs [0 -> 2]  output [0]  buffer_size [16  
--> 4096], SR [44100, 48000, 96000]

"Built-in Output"  : inputs [0]  output [0 -> 2]  buffer_size [128 -->  
4096], SR [48000]

Up to now a *single* CoreAudio backend is supposed to be asked for all  
it's parameters, then each parameter can possibly be asked for it's  
constraints. But obviously each *device* has its own set of  input/
output , buffers-sze, SR constraints. I don't see how to get that with  
the current API. The only way would be to have several backends (in  
some way) each one corresponding to a given device which parameters  
constraints could be retrieved.

Any better solution?

Stéphane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Nedko Arnaudov]

Stéphane Letz <letz@...> writes:

> I'm thinking in using the control parameter constraint API to get
> infos on available CoreAudio devices on OSX. The thing is that several
> CoreAudio devices could be available on the machine, each one with
> different parameter constraints like for instance:
>
> "Built-in Line input"  : inputs [0 -> 2]  output [0]  buffer_size [16
> --> 4096], SR [44100, 48000, 96000]
>
> "Built-in Output"  : inputs [0]  output [0 -> 2]  buffer_size [128 -->
> 4096], SR [48000]
>
> Up to now a *single* CoreAudio backend is supposed to be asked for all
> it's parameters, then each parameter can possibly be asked for it's
> constraints. But obviously each *device* has its own set of  input/
> output , buffers-sze, SR constraints. I don't see how to get that with
> the current API. The only way would be to have several backends (in
> some way) each one corresponding to a given device which parameters
> constraints could be retrieved.
>
> Any better solution?

Currently in the parameter tree, we have "internals" and "drivers"
subtrees. I sill somewhat miss what you call backends, but maybe
devices could reside in a new subtree, "devices"? Or maybe we need to
have "backends" instead of "internals" and/or "drivers"?

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

Le 30 oct. 2009 à 19:18, Nedko Arnaudov a écrit :

> Stéphane Letz <letz@...> writes:
>
>> I'm thinking in using the control parameter constraint API to get
>> infos on available CoreAudio devices on OSX. The thing is that  
>> several
>> CoreAudio devices could be available on the machine, each one with
>> different parameter constraints like for instance:
>>
>> "Built-in Line input"  : inputs [0 -> 2]  output [0]  buffer_size [16
>> --> 4096], SR [44100, 48000, 96000]
>>
>> "Built-in Output"  : inputs [0]  output [0 -> 2]  buffer_size [128  
>> -->
>> 4096], SR [48000]
>>
>> Up to now a *single* CoreAudio backend is supposed to be asked for  
>> all
>> it's parameters, then each parameter can possibly be asked for it's
>> constraints. But obviously each *device* has its own set of  input/
>> output , buffers-sze, SR constraints. I don't see how to get that  
>> with
>> the current API. The only way would be to have several backends (in
>> some way) each one corresponding to a given device which parameters
>> constraints could be retrieved.
>>
>> Any better solution?
>
> Currently in the parameter tree, we have "internals" and "drivers"
> subtrees. I sill somewhat miss what you call backends, but maybe

backends = drivers

> devices could reside in a new subtree, "devices"? Or maybe we need to
> have "backends" instead of "internals" and/or "drivers"?

Well actually an audio backend (= driver) has several "devices" on  
OSX. Would be make sense on others platforms?

Stephane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Nedko Arnaudov]

Stéphane Letz <letz@...> writes:

>> Currently in the parameter tree, we have "internals" and "drivers"
>> subtrees. I sill somewhat miss what you call backends, but maybe
>
> backends = drivers
>
>> devices could reside in a new subtree, "devices"? Or maybe we need to
>> have "backends" instead of "internals" and/or "drivers"?
>
> Well actually an audio backend (= driver) has several "devices" on
> OSX. Would be make sense on others platforms?

I dont see why not, there is one master device and slave devices
(wrt clock?). In alsa driver midi is other device. This is clearly
suboptimal because one may want to use firewire audio device and alsa
midi devices in same time. a2jmidid provides workaround but that code
clearly becomes to jack itself.

What about configuring devices independently and identifying them in
unique way (that will catch card ordering problems too). Each device
will be configurable independently. ALSA audio driver will be
configured independently of devices. ALSA MIDI internal clients "slave
backends" will be configurable independently too. Each device will be
enabled/disabled independently and apropriate backends will adopt them.
Such approach will drop device selection combobox from
backends/drivers.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Nedko Arnaudov]

Nedko Arnaudov <nedko@...> writes:

> a2jmidid provides workaround but that code
> clearly becomes to jack itself.

s/becomes/belongs/

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org