Re: gsoc2013 octave audio system

[Mike Miller]

On Wed, Apr 17, 2013 at 6:43 PM, Vytautas Jancauskas wrote:
> On Thu, Apr 18, 2013 at 1:37 AM, pantxo diribarne
> <address@hidden> wrote:
>>
>>>
>>> It supports more apis than listed there. Also nothing there is in
>>> contradiction with anything I said. The fact is you still have to pick
>>> the api somehow. And the way it is usually done is sorting the apis in
>>> order of preference and going through that list until the first one
>>> that is present on that system.
>>
>>
>> I see in that web page that a default api can be picked using
>> "Pa_GetDefaultApi()". I think it's resonnable to have portaudio choose the
>> default api, and let the user choose it among available ones if he wants.
>>
>
> Using that function is one of the possibilities, certainly. But then
> again, octave has a use different from most software that uses audio
> playback/recording. So I wonder if the default it chooses will be
> ideal. But as a starting point it is certainly a viable option. I used
> it in my little program too at first.

I think portaudio maps perfectly to what I see in the Matlab audio
API. Both enumerate multiple sound input and output devices (whether
physical devices or different host APIs) using a counting integer
identifier, both allow querying and selecting the audio device by that
identifier, and both have a concept of a default input or output
device.

I don't know if portaudio's choice of default device is "reasonable",
but we can at least start with that approach, and we can refine it as
we go (either user preferences or smarter choice of defaults based on
operating system).

The legacy non-OO functions (play, sound, wavplay, etc) may simply
have to inherit the default device. The OO methods have ways of
specifying which device to use.

-- 
mike