PortAudio Ticket #49 status

[Jaap Keuter <jaap.keuter () xs4all nl>]

Hi, 

I just revisited PortAudio Ticket #49 [1] to see what was up
this problem, and PortAudio in general.
To my surprise there where new
comments added to this 4 year old critical ticket, but they seem to
indicate an ignorance to the underlying problem. 

The issue raised is
that an application developer can't just pull in PortAudio, open default
devices and get audio out (or in). Since (s)he doesn't know about the
underlying audio infrastructure of the host it might now be faced with
the situation that [default API / default device] renders 'no audio',
not acceptable to the user.
Therefore the application programmer has
either to program around this problem (like so [2]) or setup a elaborate
settings panel for the user to manipulate into a working combination.
Not acceptable to the user, at least not when you can't provide a (maybe
poor, but at least) working setting. And users don't want to be hindered
by complicated settings, while the intention was to have it 'just work'.


So it comes down to the question: Do you think it's ok if the 'lowest
common denominator' is non-working audio, or maybe less than optimal
working audio?
if it's the former, you don't have the end user in mind,
IMHO. 

Hereby the request to honor this ticket and accept either the
proposed solution or one better as indicated from the comments. 

Kind
regards,
Jaap Keuter
Wireshark-core developer 

PS: I / we are not on
the list so please CC us 

 

Links:
------
[1]
http://www.portaudio.com/trac/ticket/49
[2]
http://anonsvn.wireshark.org/viewvc/trunk-1.4/gtk/rtp_player.c?r1=31298|+|amp|+|r2=31318

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe