[Cs-dev] Issues with 6/14's Windows RC3 build on Source Forge
| Date | 2013-06-14 18:19 |
| From | Richard Henninger |
| Subject | [Cs-dev] Issues with 6/14's Windows RC3 build on Source Forge |
| Attachments | None None |
|
Installed today’s window’s release of csound 6 RC3 and am testing API. Two observations:
Or was I too eager in downloading an experimental posting?
Richard Henninger
richard@rghmusic.com |
| Date | 2013-06-14 18:39 |
| From | Michael Gogins |
| Subject | Re: [Cs-dev] Issues with 6/14's Windows RC3 build on Source Forge |
| Attachments | None None |
I will rerun doxygen (my oversight) and re-post the archive. Thanks for the information, Mike
Michael Gogins Irreducible Productions http://michaelgogins.tumblr.com Michael dot Gogins at gmail dot com On Fri, Jun 14, 2013 at 1:19 PM, Richard Henninger <richard@rghmusic.com> wrote:
|
| Date | 2013-06-14 18:56 |
| From | Victor Lazzarini |
| Subject | Re: [Cs-dev] Issues with 6/14's Windows RC3 build on Source Forge |
| Attachments | None None |
Regarding 2) there were some changes and it might be the case that the module loading is out of step with the time csoundAudioDevList() is called. Do you have a small program showing the issue that I can test here? On 14 Jun 2013, at 18:19, Richard Henninger wrote:
Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie |
| Date | 2013-06-14 19:12 |
| From | Victor Lazzarini |
| Subject | Re: [Cs-dev] Issues with 6/14's Windows RC3 build on Source Forge |
| Attachments | None None |
yes, I see the changes could have had the effect described in 2). I think the practice we should establish for listing devices from the API is: 1) set the RT module you want to list the device from (PUBLIC void csoundSetRTAudioModule(CSOUND *csound, char *module) 2) call the device list function. You can use the above with all existing modules before setting the one you will finally use. The default module is now set a little later, after modules are loaded for the first time. The reason for this is to fix a problem reported by API users were the default module was overriding their own modules. The side effect is that after csoundCreate(), the device listing callback will not be set to the default module. I hope this helps. On 14 Jun 2013, at 18:56, Victor Lazzarini wrote:
Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie |
| Date | 2013-06-14 19:19 |
| From | Richard Henninger |
| Subject | Re: [Cs-dev] Issues with 6/14's Windows RC3 build on Source Forge |
| Attachments | None None |
|
Thanks, Victor.
I’m getting this 0 count in a test suite where the call to csoundAudioDevList is the very first call after creating csound. Since I am going through a .net pInvoke layer and if module load timing might be involved, maybe you’d rather whip up a quick test
in “c” to confirm your suspicion. If not, I could try to make a quick c project here to simulate what I am seeing. This function worked fine before loading RC3 today.
Upon further RC3 regression testing today, I am finding that I can no longer run some long-running and IO-bound functions like csoundAudioDevList in a .net Task (dev count issue above happens whether executed in a main thread or in a Task) without crashing
with a memory violation when calling csoundDestroy or csoundReset afterwords. This wasn’t an issue before today, either.
Curiously, running a csoundPerformKsmps loop and csoundCleanup in such a Task doesn’t crash upon csoundDestroy. It only happens when I run an individual informational function as a Task. Are the two threading systems suddenly getting in each other’s way
all of a sudden or is there another timing issue in freeing memory?
Richard Henninger
richard@rghmusic.com From: Victor
Lazzarini
Sent: Friday, June 14, 2013 1:57 PM To: Developer discussions Regarding 2) there were some changes and it might be the case that the module loading is out of step with the time csoundAudioDevList() is called.
Do you have a small program showing the issue that I can test here?
On 14 Jun 2013, at 18:19, Richard Henninger wrote:
Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie
|
| Date | 2013-06-14 19:21 |
| From | Richard Henninger |
| Subject | Re: [Cs-dev] Issues with 6/14's Windows RC3 build on Source Forge |
| Attachments | None None |
|
Got it. Can do. No joy on async/await pattern use triggering a later csoundDestroy crash, tho.
Richard Henninger
richard@rghmusic.com From: Victor
Lazzarini
Sent: Friday, June 14, 2013 2:12 PM To: Developer discussions yes, I see the changes could have had the effect described in 2). I think the practice we should establish for
listing devices from the API is:
1) set the RT module you want to list the device from (PUBLIC void csoundSetRTAudioModule(CSOUND *csound, char *module)
2) call the device list function.
You can use the above with all existing modules before setting the one you will finally use.
The default module is now set a little later, after modules are loaded for the first time. The reason for this is to fix a problem
reported by API users were the default module was overriding their own modules. The side effect is that after csoundCreate(), the
device listing callback will not be set to the default module.
I hope this helps.
On 14 Jun 2013, at 18:56, Victor Lazzarini wrote:
Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie
|
| Date | 2013-06-14 19:44 |
| From | Victor Lazzarini |
| Subject | Re: [Cs-dev] Issues with 6/14's Windows RC3 build on Source Forge |
| Attachments | None None |
Well, strictly speaking you will want all csound creation/setup/destruction in the same thread, because they may get in the way of each other. The thread safety in Csound is mostly designed to deal with performance situations where csoundPerformKsmps etc is running in one thread, and controls, channels, compilation, access to tables happens in a separate one. Given the fact that I don't know the details of Windows/.NET programming, I am afraid I can't help much more with it. But anything you find out is welcome here. Victor On 14 Jun 2013, at 19:21, Richard Henninger wrote:
Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie |
| Date | 2013-06-14 19:57 |
| From | Richard Henninger |
| Subject | Re: [Cs-dev] Issues with 6/14's Windows RC3 build on Source Forge |
| Attachments | None None |
|
That’s my basic premise as well. I’ll look at my design to make sure that is as clean as I thought it was. I was running the device enumeration, which takes a second or two) in a worker task to keep a UI responsive.
Something is not cleaning up right on closing even in a single thread, however. Now I specify “portaudio” before calling csoundAudioDevList and get my 7 devices (now asio show up: yea! Thanks.), and I can enumerate everything, but now I crash on exit
even with everything on a single thread in test program where this call and the enumeration is all I do. Could it be that module unloading on exit is problematic as a result of the change made for module loading?
Will post anything I learn as I dig through things in .net.
Richard
Richard Henninger
richard@rghmusic.com From: Victor
Lazzarini
Sent: Friday, June 14, 2013 2:44 PM To: Developer discussions Well, strictly speaking you will want all csound creation/setup/destruction in the same thread, because they may get in the way of each
other. The thread safety in Csound is mostly designed to deal with performance situations where csoundPerformKsmps etc is running in
one thread, and controls, channels, compilation, access to tables happens in a separate one.
Given the fact that I don't know the details of Windows/.NET programming, I am afraid I can't help much more with it. But anything you find
out is welcome here.
Victor
On 14 Jun 2013, at 19:21, Richard Henninger wrote:
Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie
|
| Date | 2013-06-14 20:05 |
| From | Victor Lazzarini |
| Subject | Re: [Cs-dev] Issues with 6/14's Windows RC3 build on Source Forge |
| Attachments | None None |
I don't think so, that bit should not be affected. If you have a simple single-thread test program, then I can try debugging (on OSX). On 14 Jun 2013, at 19:57, Richard Henninger wrote:
Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie |
| Date | 2013-06-14 20:08 |
| From | Richard Henninger |
| Subject | Re: [Cs-dev] Issues with 6/14's Windows RC3 build on Source Forge |
| Attachments | None None |
|
On a positive RC3 note, csoundListChannels now actually returns a proper controlChannelHints_t structure. I was about to post this as an issue this morning after exhausting every marshaling strategy I could think of looking for where it went. With RC3
it was right where I had thought it should be from the beginning.
Thanks to whoever spotted and fixed this.
Richard Henninger
richard@rghmusic.com From: Victor
Lazzarini
Sent: Friday, June 14, 2013 2:44 PM To: Developer discussions Well, strictly speaking you will want all csound creation/setup/destruction in the same thread, because they may get in the way of each
other. The thread safety in Csound is mostly designed to deal with performance situations where csoundPerformKsmps etc is running in
one thread, and controls, channels, compilation, access to tables happens in a separate one.
Given the fact that I don't know the details of Windows/.NET programming, I am afraid I can't help much more with it. But anything you find
out is welcome here.
Victor
On 14 Jun 2013, at 19:21, Richard Henninger wrote:
Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie
|
| Date | 2013-06-14 20:10 |
| From | Richard Henninger |
| Subject | Re: [Cs-dev] Issues with 6/14's Windows RC3 build on Source Forge |
| Attachments | None None |
|
OK. Let me try and whip up a c equivalent as I imagine you are not set up for a Visual Studio .net project on OSX (or do you have such in Windows mode?)
Richard Henninger
richard@rghmusic.com From: Victor
Lazzarini
Sent: Friday, June 14, 2013 3:05 PM To: Developer discussions I don't think so, that bit should not be affected. If you have a simple single-thread test program, then I can try debugging (on OSX).
On 14 Jun 2013, at 19:57, Richard Henninger wrote:
Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie
|
| Date | 2013-06-14 20:35 |
| From | Richard Henninger |
| Subject | Re: [Cs-dev] Issues with 6/14's Windows RC3 build on Source Forge |
| Attachments | None None |
|
Took care of memory crashes on closing in my code such that everything works now as long as I stay in a single thread. Will try to learn more about interaction of .net Tasks and csound and share what I learn. Thanks for your help, Victor.
Richard Henninger
richard@rghmusic.com From: Richard
Henninger
Sent: Friday, June 14, 2013 3:11 PM To: Developer discussions OK. Let me try and whip up a c equivalent as I imagine you are not set up for a Visual Studio .net project on OSX (or do you have such in Windows mode?)
Richard Henninger
richard@rghmusic.com From: Victor
Lazzarini
Sent: Friday, June 14, 2013 3:05 PM To: Developer discussions I don't think so, that bit should not be affected. If you have a simple single-thread test program, then I can try debugging (on OSX).
On 14 Jun 2013, at 19:57, Richard Henninger wrote:
Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie
|
| Date | 2013-06-14 20:38 |
| From | Victor Lazzarini |
| Subject | Re: [Cs-dev] Issues with 6/14's Windows RC3 build on Source Forge |
| Attachments | None None |
What I noticed was this: if you call csoundReset() before csoundStart(), there's trouble. I have fixed the code to prevent this crash, so that csoundReset() is skipped if called on an already reset instance. On 14 Jun 2013, at 20:35, Richard Henninger wrote:
Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie |
| Date | 2013-06-14 20:42 |
| From | Richard Henninger |
| Subject | Re: [Cs-dev] Issues with 6/14's Windows RC3 build on Source Forge |
| Attachments | None None |
|
That jives with what I found: When I pulled csoundReset out of the chain in my code before calling csoundDestroy, everything worked.
Richard Henninger
richard@rghmusic.com From: Victor
Lazzarini
Sent: Friday, June 14, 2013 3:39 PM To: Developer discussions What I noticed was this: if you call csoundReset() before csoundStart(), there's trouble. I have fixed the code to prevent this crash, so that csoundReset() is skipped if
called on an already reset instance.
On 14 Jun 2013, at 20:35, Richard Henninger wrote:
Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie
|
| Date | 2013-06-14 21:02 |
| From | Victor Lazzarini |
| Subject | Re: [Cs-dev] Issues with 6/14's Windows RC3 build on Source Forge |
| Attachments | None None |
On 14 Jun 2013, at 20:42, Richard Henninger wrote:
Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie |