Add name= parameter to query_hostapis()

[dholl]

How's this for a minor upgrade to query_hostapis()? What exception should be raised if query_hostapis(name='Some Unknown Name') doesn't find a host API with the requested name?

For now, it just raises PortAudioError('Host API {0!r} not found'.format(name))

[mgeier]

Hmmm, I'm not so sure anymore if specifying a string is the right thing to do, since the names are actually not known a priori and they may not have the exact shape you are expecting.

E.g., name='MME' would work, but not name='WMME'. Is it 'WDM/KS' or 'WDM-KS'? Neither, it's 'Windows WDM-KS'!
Or probably it even changes between PortAudio versions? Or between OS versions?
Let's look at the docs ... it's not there!

What about searching for a substring instead? Similar to what is already possible with the device parameter?
This still doesn't solve all the problems ...

Or alternatively, what about providing our own pre-defined attributes on some "host API" object?
Something like sd.hostapi.wdmks.do_something().
This way we could give a complete list of possible choices in the documentation instead of letting users guess what the name of a certain host API could be exactly.
After all, PortAudio also uses its own fixed names like paWDMKS.
But most likely this has some problems of its own ...

Long story short, I'm not so sure if this is such a minor upgrade, probably we should discuss the new platform-specific API as a whole?

[mgeier]

I saw too late that the more general discussion is here: #85.

[dholl]

Yeah, as implemented based upon matching on the ['name'] field, I have a similar set of concerns regarding this PR, but since we touched on the idea in #83, I figured I'd follow through with this quickie.

My own preference is for coming up with something that matches 1:1 with PortAudio's host api enumeration, since using the enumeration is guaranteed to give you the expected API. I had some questions in the code comments in #85, specifically, wondering if there's a way to automatically pulling the names from that enum. For now, I just left a dict in #85 where I hard-coded an 'apiname' string for each enum value, but to create these names, I just lowercased the name of each enum value and stripped off the "pa" prefix. This way, we'd pass the blame onto PortAudio if someone doesn't like them, right? ;)

Anyhow, I'll assume the rest of this discussion can happen in #85. :)

Shall we drop this PR (#84)? Or should I change this PR to using the 'apiname' strings from #85 if there's a potential that you'd like to keep query_hostapis()? :)

Note that in #85, I didn't include the commit for #84, since I also see it as a question of what we'd want to support going forward.

[mgeier]

Regarding pulling the enum names: @tgarc recently used .relements on a CFFI type: 57db7a3#diff-fdd238ebc8d2e4582b25293d4394967fR2269
Is that what you are looking for?

Shall we drop this PR?

Let's wait and see what happens over there ...

[dholl]

@mgeier @tgarc .relements! Sweet! :)

translation: Yes, that is precisely what I was hoping for.

Thank you!