Re: Plug-and-play patch for portaudio
Erik Bunce <kde <at> bunce.us>
2007-11-05 15:29:44 GMT
Any further thoughts, comments, criticisms, suggested changes? It's
easier to adapt while this code base is still fresh in my mind...
Thanks and Enjoy,
Erik Bunce wrote:
> I'll try to address your questions/requirements as best I can. I
> apologize if I'm misunderstanding anything, but I'll do my best to
> A) In my testing, portaudio behaved no better or worse after the patch
> when an attempt was made to open a device that was no longer
> present. If one device was removed, and another inserted, you may end
> up opening a different device then you expected. But I'm not sure of
> the best way to avoid that. I'll have to think on that.
> C) Exists. The Pa_RescanDevices exists to allow a client to force a
> rescan. This could be useful to implement a 'scan for changes' button
> to better support platforms that may not provide a usable change
> When I started out, my thoughts were to have (B) and (C) seperate for
> reasons akin to what you suggest. That is until I realized that this
> would be completely inadequate for my own purposes and several other
> usages that I could envision.
> Let me elaborate, part of the reason I combined (B) and (C) is that in
> my own application I use portaudio both indirectly through a 'third
> party' library (iaxclient) for some purposes and directly for others.
> In this case, which should be responsible for calling the rescan API?
> It could be really slow/bad if all of them turn around and call the
> Pa_RescanDevices() API, wouldn't it? Especially, if the list
> modifications themselves were not surrounded with callbacks and each
> caller assumes the list hasn't changed since Pa_RescanDevices() was
> last called by itself. How does one coordinate this? My solution
> was to have PortAudio be responsible for rescaning, but only if the
> client can be notified of the device list changes.
> To deal with the concurrency issues that you mention, I have it wrap
> all device list modifications in callback notifications. First, it
> notifies all the registered callbacks with a
> paDevicesListAboutToBeChanged before changes are made to the device
> lists. This allows the clients to prepare for the device list to
> change. Then, after these have all returned, then, and only then will
> the device lists be changed. Finally, after the list changes are
> completed, all the registered callbacks are notified with the
> paDevicesListChanged flag specified. During these surrounding
> notifications the client(s) can do any thread synchronization they
> The principle reason I only have it do the rescan if a callback is
> registered is to maintain backwards compatibility with existing
> callers that have not been modified to support plug-n-pray will
> continue to work. The secondary reason is that I don't feel it would
> be advisable to have the device list change in the background without
> being enclosed in callback notifications. Especially since it appears
> to be common practice for clients to maintain pointers into the device
> info structures returned by PortAudio. I feel this is the case
> regardless of where the device list changes are initiated since
> PortAudio may have, as in my own case, multiple callers within the
> same process.
> I was unaware that device scanning was particularly slow on some
> platforms. In that case I can see the advantages to only rescanning
> the specifiec host api that detected the change. I'll try to think of
> what the best way to approach that is. Any advice?
> On a side note, a couple of folks working on iaxclient have suggested
> that they would be willing to put together Linux ALSA and some form of
> Windows support.
> Thanks and Enjoy,
> Erik Bunce
> Ross Bencina wrote:
>> Hi Guys
>> Yes indeed thanks for the contribution Erik.
>> I have a few thoughts on the public interface to this patch, and some
>> questions about what it actually supports...
>> I had a slightly different interface in mind which decoupled
>> rescanning from notification, which imply the following API
>> A. If new hardware devices are added or removed, PortAudio should be
>> resilient to this and not crash when trying to open a missing device,
>> and be able to open all present devices in its device list correctly.
>> All this without any user visable changes to the PortAudio device list.
>> B. There should be a notification mechanism which allows notification
>> when a device is added or removed.
>> C. There should be an API for rescanning devices (this should
>> probably support specifying which host APIs to rescan since some can
>> take a while. (eg Pa_RescanDevices() )
>> So, in summary it's not clear to me that this patch supports
>> requirement (A) at the moment, it would be good to hear Erik's
>> feedback on this. Clearly (B) and (C) are a bit merged in this patch.
>> Personally I would prefer that they were separated for at least the
>> following reasons:
>> - there are a number of concurrency related concerns which arise if
>> PortAudio can rescan stuff in the background
>> - it would be better if the API behaved consistently, whether or not
>> there is a notification callback registered
>> To say this another way, the client should be able to specify a clear
>> moment in time when the PortAudio deivice list is updated, and this
>> should happen in the client's thread context so that the client can
>> manage concurrency issues with its own data structures. With Erik's
>> proposed scheme of notifying clients after the list has been
>> rescanned, there is the potential for race conditions where a client
>> thread may access the device list and be interruped by the
>> notification callback.
>> Sorry I can't explain this better right now, I hope it makes sense.
>> Best wishes
>> ----- Original Message ----- From: "Bjorn Roche" <bjorn <at> xowave.com>
>> To: "Erik Bunce" <kde <at> bunce.us>; "Ross Bencina"
>> <rossb <at> audiomulch.com>; "Arve Knudsen" <aknuds-1 <at> broadpark.no>; "Phil
>> Burk" <phil <at> mobileer.com>
>> Cc: <portaudio <at> techweb.rfa.org>
>> Sent: Wednesday, October 31, 2007 1:17 AM
>> Subject: Re: [Portaudio] Plug-and-play patch for portaudio
>>> Wow! thanks for this wonderful wonderful contribution, which
>>> addresses a long standing issue with portaudio. I am personally
>>> glad to see you've attacked this from the API level rather than
>>> making it a platform specific extension, but that does open a can
>>> worms: some platforms wont be able to implement this right away.
>>> Obviously, I'm eager to apply this patch but I want to hear what the
>>> other developers have to say, since it leaves us in the awkward
>>> position of having uneven development. Ross? Arve? Phil? (are there
>>> others I should be emailing directly?) Also, I'll have to look at
>>> the patch more closely, but at first glance it looks pretty solid.
>>> On Oct 29, 2007, at 11:02 PM, Erik Bunce wrote:
>>>> Please see the attached patch against todays portaudio v19-devel
>>>> r1296. It defines API's to support plug-and-play
>>>> and adds an implementation to the hostapi for Mac OS X.
>>>> Highlights includes the following:
>>>> + A callback mechanism to notify API users when the list of devices
>>>> and/or the default input/output devices change.
>>>> + If one of these callback is registered, and the native
>>>> implementation detects that the devices has changed,
>>>> the system will automatically rescan the devices and adjust the
>>>> device lists accordingly.
>>>> + To maintain backwards compatiblity, if no callback is
>>>> registered, the system leaves the device list alone and the
>>>> previous behavior is mainained.
>>>> + Existing host API's that don't support rescanning, just have to
>>>> set the new RescanDevices member of the
>>>> PaUtilHostApiRepresentation structure to 0.
>>>> + API users can call the Pa_RescanDevices() to force the native
>>>> implementation to rescan it's list of devices.
>>>> + Mac OS X CoreAudio implementation.
>>>> + Designed so that it could be used with or without native host
>>>> notifications of device list changes.
>>>> I'm successfully using this in iaxclient.
>>>> Thank you for your consideration.
>>>> Thanks and Enjoy,
>>>> Erik Bunce
>>> Bjorn Roche
>>> XO Wave
>>> Digital Audio Production and Post-Production Software
> Portaudio mailing list
> Portaudio <at> techweb.rfa.org