1 Nov 2007 13:14
clr20r3 dllnotfoundexception
Bernt Rønningsbakk <bernt.ronningsbakk <at> lyse.net>
2007-11-01 12:14:40 GMT
2007-11-01 12:14:40 GMT
Hello David, I've followed your fine instruction for compiling with VS 2005 (hit and hope) and it seems to have worked fine. I am beginning to get a good c# binder up and running. It works on the development machine. But when I bring a USB stick with an .exe + portaudio.dll to any of the other computers this error is raised on startup. All machines run XP SP2. I am not registering the portaudio dll. It is located next to the exe file. I get a clr20r3 error P9: system.dllnotfoundexception when I try to run a c# program that calls portaudio.dll. Browsing the www for clr20r3 brings up all kinds of related errors, but none with a relevant solution. Running from the USB stick on the development machine, I get the same error if I rename portaudio.dll. So there are strong indications that portaudio.dll is not found, rejected or something similar on the other machines. I've made a new windows application that holds the binder and makes one call to portaudio, and the same thing happens there. If you have a portautio_x86.dll that you know works on various machines I'd love to try it out to see if I have a compilation problem here or there's something with my binder makeup. Best regards / vennlig hilsen(Continue reading)
Thanks and Enjoy,
Erik Bunce
Erik Bunce wrote:
> Hello,
> 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
> respond.
>
> 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
> notification.
>
> 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
> require.
>
> 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
>> requirements:
>>
>> 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
>>
>> Ross.
>>
>>
>>
>>
>>
>>
>> ----- 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.
>>>
>>> bjorn
>>>
>>> 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
>>> 
RSS Feed