Re: How is an AU supposed to close its files when it closes
Re: How is an AU supposed to close its files when it closes
- Subject: Re: How is an AU supposed to close its files when it closes
- From: Richard Burnett <email@hidden>
- Date: Sat, 16 Aug 2008 16:16:30 -0400
I think the point being made is that the AU plugin does not run as a separate executable and that is what is being explained to you that you do not seem to be getting.
The plugin actually loads and runs in the context of the host application. It's not being run as a separate program, it's being loaded up dynamically and run in the SAME memory space as the host application. The AU cannot run as an executable because it cannot run by itself. It's a library of code moreso than an independent executable.
In that sense, it runs as a polymorphic object.
Can you run an AU by itself? No, because it is not an executable. It's a component library. The host application calls the functions in the component. The component does not run itself.
Rick
Asylum Studio Productions
On Saturday, August 16, 2008, at 03:33PM, "Jeremy Sagan" <email@hidden> wrote:
>Hello Brian,
>
>I really do not want to get into this but since you won't stop let me
>just review for you from the Apple computer dictionary, the definition
>of executable:
>
>"A file or program that is able to be run from a computer."
>
>If it runs under a host it is still running on a computer and it is
>definitely a file or program as, like I said, it can be found here:
>
>/Library/Audio/Plug-Ins/Components/pluginnamehere.component/Contents/
>MacOS/pluginnamehere
>
>That is all I will say on this thread.
>
>Jeremy
>
>On Aug 16, 2008, at 3:14 PM, Brian Willoughby wrote:
>
>> Jeremy,
>>
>> I'm sorry if you were offended by my response or found it
>> unnecessary. But I believe that you need to review some of the
>> documentation on Mach, processes, and dynamic code.
>>
>> The host is the only executable that is actually being run by the
>> system. All of the AudioUnits are dynamically loaded into the one
>> host process. The AUs are not executable directly, and that term is
>> quite misleading. In other words, the AU "executables" that you
>> talk about becomes part of the host "executable" when loaded. Until
>> the host task terminates, all of the dynamic code that has been
>> loaded as AUs will remain in the code space of the host executable.
>> The Mach/Darwin system does not unload dynamic code. Whether the AU
>> files remain open or are closed does not seem important when you
>> consider what's really happening, and it's probably necessary for
>> them to remain open because the VM pager cannot predict that it
>> won't need access to them at some future point, so long as the host
>> continues to run.
>>
>> And, yes, the system closes all files, including components, when a
>> process (executable) terminates. An AU cannot terminate, because it
>> was never started independently - an AU becomes part of another
>> executable. The only way for the system to be certain that a
>> component will never be executed once dynamically loaded into
>> another process is for that process to be terminated.
>>
>> Brian Willoughby
>> Sound Consulting
>>
>>
>> On Aug 16, 2008, at 08:01, Jeremy Sagan wrote:
>> On Aug 16, 2008, at 5:38 AM, Brian Willoughby wrote:
>>> Perhaps I have misunderstood your use of the terminology, but an
>>> AudioUnit is not an executable.
>>
>> You are incorrect. An AudioUnit is a component, which executes and
>> therefore contains an executable. I did not post this question to
>> argue semantics with you.
>>
>>
>>> The only executable is the host itself. Each and every AU is
>>> running as part of the main host executable. Thus, the host is
>>> responsible for closing anything that it opens. An AU cannot close
>>> itself.
>>
>> Again I am not looking for a basic teaching of how plug-ins work. A
>> plug-in must execute to work.
>>
>>> How is it that you are determining whether a component is open or
>>> closed, and what do you mean by an executable being open or closed?
>>
>> If you had read the original post below you could easily answer your
>> own question, I am determining whether a component (file) is open or
>> closed using Activity Monitor. A Component's executable is opened
>> with the 'OpenComponent' call and I thought should be closed with
>> 'CloseComponent'.
>>
>>> Note that when you terminate a task (i.e. when you quit the host)
>>> all files opened by that task/host will automatically be closed.
>>
>> This is not a problem when the task terminates, this is a problem
>> that last only for the duration of the host session.
>>
>> I don't think you needed to respond to this post at all.
>>
>>> Virtual memory handles quite a bit for you.
>>
>> Well this statement is the only one in your post that is relevant.
>> Does VM close the component when it exits a cache or something?
>>
>>> On Aug 15, 2008, at 22:59, Jeremy Sagan wrote:
>>> I have been doing some coding help on an audiounit plugin and I
>>> have noticed that it and virtually all Music Device AudioUnits
>>> leave their executable open after the component has been closed.
>>> The one notable exception appears to be the DLS MusicDevice. Which
>>> leads to my question. What is a Music Device (or other AU) plug-in
>>> supposed to do to ensure that it's executable file is closed in the
>>> host after the component is closed?
>>>
>>> Here is an example of a path to a fictional plugin's file left open:
>>>
>>> /Library/Audio/Plug-Ins/Components/pluginnamehere.component/
>>> Contents/MacOS/pluginnamehere
>>>
>>> Note that I have been checking the files left open using Activity
>>> Monitor's 'open files and ports' tab and I have tried this test
>>> with AULab, my host, Metro, and AudioUnitHosting. I am running OS X
>>> 10.5.3 (in case it is OS related).
>>>
>>> As I side not it would be great if AUVal posted nasty warnings if
>>> files were left open.
>>>
>>> Thanks,
>>> Jeremy
>
> _______________________________________________
>Do not post admin requests to the list. They will be ignored.
>Coreaudio-api mailing list (email@hidden)
>Help/Unsubscribe/Update your Subscription:
>
>This email sent to email@hidden
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden