Re: [Jack-Devel] jack vs devices

PrevNext  Index
DateSun, 02 Sep 2012 05:10:34 +1000
From Patrick Shirkey <[hidden] at boosthardware dot com>
To[hidden] at lists dot jackaudio dot org
In-Reply-ToPaul Davis Re: [Jack-Devel] jack vs devices
On Sat, September 1, 2012 10:56 pm, Paul Davis wrote:
> On Sat, Sep 1, 2012 at 2:41 AM, Patrick Shirkey
> <[hidden]>wrote:
>
>> Hi,
>>
>> A few questions that I couldn't see answers to in the API docs.
>>
>> Does jack have a way to query a devices capabilities like available
>> sample
>> rates, period sizes, number of ports, etc...
>>
>
> i'm not sure what you mean. if you mean, can clients make calls to
> discover
> this, then yes and no. clients can certainly get the sample rate, the
> period ("buffer") size, and enumerate all ports, etc. JACK itself does not
> provide any API that is device-oriented (other than marking ports as
> "physical") because we do not want clients trying to treat i/o to and from
> devices differently than i/o to and from other clients. as for JACK itself
> trying to discover possible sample rates, almost no complete audio device
> API provides this, since it is actually part of the problem of a very
> sparse multidimensional state space - each parameter of an audio device
> can
> depend on the other parameters (e.g. the number of channels can depend on
> the sample rate, or vice versa). so JACK simply tries to configure things
> as the user asked, and then checks that it worked, at least somewhat.
>

It looked like this was the case but I wanted to make sure. It looks like
the best way to handle this is with a user supplied database of
proven/tested variables or by programming the logic into the controller
app explicitly where the limitations are obvious.


>
>> If I reset the sample rate or period size do I need to restart the
>> server
>> every time?
>>
>
> jack_set_buffer_size() can be used by any client to change the period size
> (though it may fail if you give it an illegal value).
>
> currently (and since JACK's inception) there is no API call to change the
> sample rate. we decided long ago that it placed too much of a burden on
> clients. this may have been a mistake.
>

This is planned for jack3 though, IIRC?

Perhaps the way around it is to only support switching sample rates if
clients that are connected signal that they are able to deal with it or if
there are no clients.



--
Patrick Shirkey
Boost Hardware Ltd
PrevNext  Index

1346526644.19473_0.ltw:2,a <53112.175.39.40.230.1346526634.squirrel at boosthardware dot com>