bastibe/PySoundCard

Request: Stream holds its device object

Closed this issue · 3 comments

Stream only has ._stream which is a FFI-wrapped Pa instance. I would really like to be able to query stream like this:
s.device.name
s.device.sample_rate

The sample rate is available as s.sample_rate and is always the same for the input and output device. As for the device name, this would have to be two names, the name of the input device and the name of the output device.

The device dicts are calculated by portaudio at runtime and can change any time the audio configuration changes. I am therefore somewhat reluctant to save too much information from the device dict.

What would you need the device name for after initialization?

I want to display it to the user so they know what they're seeing (or not seeing, if that's the case). I'm looking for something like https://github.com/bastibe/python-oscillator/blob/master/oscillator.py#L26, I think. Mixxx has the same problem with the complexity of PortAudio's naming scheme(s). It would behboove PySoundCard to provide some way to retrieve information about the sound card. If the mappings are dynamic then even more do I want them to be wrapped by some object so I can request different details as needed; I am a fanboy of properties so when I say I want someting like s.device.name, I don't necessarily mean that (s.device().name() is okay too). As I work with this more I'll probably come up with a patch.

The functions apis() and devices() provide you with a list of all devices and host apis. Each entry also includes its own device/api index. These should be much easier to use than what PyAudio does and they should make functions like that device_index_to_host_api_device_index redundant. In particular, you can easily filter devices and APIs using list comprehensions.

I thought about wrapping devices and APIs in classes instead of dictionaries, but that seems to be wasteful, as there is really no functionality associated with the data.

The thing I am afraid of is this: If you store the full device/api dict in the Stream, one might try to create a new stream with those dictionaries. However, the device/api indices can change at runtime, so this might lead to very strange behavior. (On the other hand, I am not quite sure if indices can actually change once portaudio has been initialized, so this point might be moot.)

If you have any idea of how to improve the current behavior, I would be very interested. I know that the current solution is not perfect, but I can't seem to come up with a better one. However, PySoundCard is kind of widely used already, so any new solution has to be backwards compatible.

On 22.12.2013, at 10:25, Nick notifications@github.com wrote:

I want to display it to the user so they know what they're seeing (or not seeing, if that's the case). I'm looking for something like https://github.com/bastibe/python-oscillator/blob/master/oscillator.py#L26, I think. Mixxx has the same problem with the complexity of PortAudio's naming scheme(s). It would behboove PySoundCard to provide some way to retrieve information about the sound card. If the mappings are dynamic then even more do I want them to be wrapped by some object so I can request different details as needed; I am a fanboy of properties so when I say I want someting like s.device.name, I don't necessarily mean that (s.device().name() is okay too). As I work with this more I'll probably come up with a patch.


Reply to this email directly or view it on GitHub.