RE: [RFC] Reference counting on Audio objects for /dev/dsp
On Sat, 17 Jul 2004, Robert McNulty Junior wrote: > >Replying to myself - a sure sign of schitzophrenia... :-) > > Igor, the correct spelling is schizophrenia, and it does not involve talking > to oneself. > [snip] Robert, I am a doctor of philosophy, not a medical doctor, so I think I can be forgiven a little typo and a (humorous) attempt at self-diagnosis. :-) FWIW, even though I spelled it wrong, schizophrenia does involve a fragmentation of the personality. And now let's please stop this thread before it drifts any more off-topic (if such is possible). I will, of course, accept any constructive comments on the patch and/or alternative implementations. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "I have since come to realize that being between your mentor and his route to the bathroom is a major career booster." -- Patrick Naughton
RE: [RFC] Reference counting on Audio objects for /dev/dsp
>Replying to myself - a sure sign of schitzophrenia... :-) >I'm wrong. Some settings *are* kept in the fhandler objects (audiobits_, >audiofreq_, audiochannels_, and audioformat_). So CGF is right - >archetypes will probably be the right solution here... However, we still >need reference counting for the Audio objects, since even with archet.ypes >they'll be shared (unless you completely rewrite the code). Igor, the correct spelling is schizophrenia, and it does not involve talking to oneself. >From what I learned, the two minds that the doctors are talking about are a sick mind and a well mind. It is controlled with medication like Haldol or Seraquel. Others take a new medication called Geodon. If you want to learn more about mental illness, and its effects on the persons and families involved, look up the NAMI website. I have. I'm much better now. Most schizophrenics go undiagnosed. There are 2 million or more in the US alone. These "problems" in the Cygwin mailing lists are not caused by me. So don't blame me or my illness. Most real schizos don't even have computers or know anything about computer science. I've only seen one person so far that meets schizophrenia. He was hostile towards Corrina. He was hostile towards me when I was trying to tell him to quit. About your idea, I need to look at the patch, Gerd. It could work. I'm just following this thread and found a misconception about mental illness. And if you want to see real MI at work, watch ER. Abby's mom is bipolar and Abby's finally going to college to get a counseling degree in Mental Health. MH is a big problem today. Many have lost their jobs to mental illness. Read a book on MI or watch "A Beautiful Mind" by Ron Howard. Genius can be considered insanity. One of the greatest minds in the world had mental illness. Albert Einstein. Insanity? He could find his house when coming back from working at the university. Abraham Lincoln had depression. His was from birth on. More recent celebrities are Carrie Fisher from Star Wars, Margot Kidder from Superman. There might even be someone at your work who's gone insane, but no one ever noticed. Its not the ones who seek help that cause problems with others. Sure fire way to tell if you have MI is: Do you drink alchoholic beverages or use illegal drugs like cocaine, crack, morphine? Morphine is used by hospitals to control a person's pain level after surgery. Any surgery. On the streets, its causes delusions. The person involved in the illegal use will hear voices in their heads telling them to do harm towards others. Illegal drugs have been around forever, Opium is illegal. It is made from poppy seeds grown in Afghanistan. Don't tell me about mental illness and call me crazy until you seek the information. My thoughts are clear. I never had it in the first place. Seek the info on MI and learn before you make false assumptions about others. I've been online since 1996. I used to call local BBS's. I read the information. I know what I have and what I don't. Don't blame me for your problems, Defaria. Or windows XP or Microsoft. Blame yourself into buying into the myth. Windows XP is for business and home users. Linux is for servers. Windows XP Professional is widely used by businesses. Sure, Linux sales have risen. Only because the Linux users believe they have a better product. I'm not convinced. I tried linux. I downloaded and burned several ISO's. Linux does not support my current hardware "TV PVR, DVD R/W" so I won't install it. I'm running XP Pro because I can't find my original setup disks that I ordered from HP. So, many features of the rest of the computer are missing. My synthesizer, I had to find the driver for it at drivers.com. The setup file for XP does not work. That is why I use Timidity. Open Source. I just built it and installed it with the GCC cvs. If Linux is free, how come Red Hat and Mandrake sell it? Free software is a joke to me. The only freedom I see with it is the ability for the users to make changes to it. Something Microsoft does not do. Windows Services for Unix is a joke too. I can't compile any software with it. GCC on SFU does not compile timidity, another open source project. GCC on Cygwin can.
RE: [RFC] Reference counting on Audio objects for /dev/dsp
On Sat, 17 Jul 2004, Igor Pechtchanski wrote: > On Sat, 17 Jul 2004, Gerd Spalink wrote: > > > On Friday, July 16, 2004 4:31 AM, Christopher Faylor [SMTP:[EMAIL PROTECTED] wrote: > > > On Thu, Jul 15, 2004 at 04:28:56PM -0400, Igor Pechtchanski wrote: > > > >On Thu, 15 Jul 2004, Christopher Faylor wrote: > > > > > > > >> On Thu, Jul 15, 2004 at 02:57:17PM -0400, Igor Pechtchanski wrote: > > > >> >> 2) The other problem is that I find it sort of odd to see the dec() > > > >> >> method performing a deletion. Couldn't this be handled where, IMO, > > > >> >> it should logically be handled, in the close function, e.g., > > > >> >> > > > >> >> if (!audio_out_->dec ()) > > > >> >> delete audio_out_; > > > >> >> ? > > > >> > > > > >> >Umm, that's actually a rather standard construct in reference counting > > > >> >(called "object suicide" -- you should get some references if you Google > > > >> >for "object suicide reference counting"). > > > >> > > > >> Yes, I thought that would be your answer, however, I don't like the idea > > > >> of having a method called "inc" which just increments a count and a method > > > >> called "dec" which decrements a count and, oh, hey, it might delete the > > > >> object, too. > > > >> > > > >> It seems more straightforward to delete audio_out_ in the place where > > > >> you'd expect it to be deleted rather than having a "dec" call which, > > > >> if you check, you'll notice that it deletes the buffer. > > > >> > > > >> Or, as a compromise, don't call it 'dec'. Call it something which > > > >> illustrates what it is doing. > > > > > > > >Right. I think the compromise is good -- I was thinking of maybe using > > > >registerReference() and releaseReference() (or deregister?). We could > > > >shorten them by removing "Reference" from the names, too. In any case, > > > >I'd wait for Gerd's input before deciding on the specific code to go in. > > > > > > That sounds good to me. > > > > > > Now we just need Gerd's ok. > > > > > > cgf > > > > The current proposal will not work if someone first dups the device > > descriptor, and then changes the audio settings with ioctl calls using > > one of the two device descriptors. The other one will keep the old > > settings. > > > > The patch I am preparing will fix this. However, I also have problems to > > build the cygwin DLL. I'll try to do it tonight. > > > > Gerd > > Huh? I'm most likely misunderstanding something... Aren't the audio > settings kept in the Audio objects? Those are shared, so any changes made > to one via the first descriptor should be visible via the second > descriptor, right? > Igor Replying to myself - a sure sign of schitzophrenia... :-) I'm wrong. Some settings *are* kept in the fhandler objects (audiobits_, audiofreq_, audiochannels_, and audioformat_). So CGF is right - archetypes will probably be the right solution here... However, we still need reference counting for the Audio objects, since even with archetypes they'll be shared (unless you completely rewrite the code). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "I have since come to realize that being between your mentor and his route to the bathroom is a major career booster." -- Patrick Naughton
RE: [RFC] Reference counting on Audio objects for /dev/dsp
On Sat, 17 Jul 2004, Gerd Spalink wrote: > On Friday, July 16, 2004 4:31 AM, Christopher Faylor [SMTP:[EMAIL PROTECTED] wrote: > > On Thu, Jul 15, 2004 at 04:28:56PM -0400, Igor Pechtchanski wrote: > > >On Thu, 15 Jul 2004, Christopher Faylor wrote: > > > > > >> On Thu, Jul 15, 2004 at 02:57:17PM -0400, Igor Pechtchanski wrote: > > >> >> 2) The other problem is that I find it sort of odd to see the dec() > > >> >> method performing a deletion. Couldn't this be handled where, IMO, > > >> >> it should logically be handled, in the close function, e.g., > > >> >> > > >> >> if (!audio_out_->dec ()) > > >> >> delete audio_out_; > > >> >> ? > > >> > > > >> >Umm, that's actually a rather standard construct in reference counting > > >> >(called "object suicide" -- you should get some references if you Google > > >> >for "object suicide reference counting"). > > >> > > >> Yes, I thought that would be your answer, however, I don't like the idea > > >> of having a method called "inc" which just increments a count and a method > > >> called "dec" which decrements a count and, oh, hey, it might delete the > > >> object, too. > > >> > > >> It seems more straightforward to delete audio_out_ in the place where > > >> you'd expect it to be deleted rather than having a "dec" call which, > > >> if you check, you'll notice that it deletes the buffer. > > >> > > >> Or, as a compromise, don't call it 'dec'. Call it something which > > >> illustrates what it is doing. > > > > > >Right. I think the compromise is good -- I was thinking of maybe using > > >registerReference() and releaseReference() (or deregister?). We could > > >shorten them by removing "Reference" from the names, too. In any case, > > >I'd wait for Gerd's input before deciding on the specific code to go in. > > > > That sounds good to me. > > > > Now we just need Gerd's ok. > > > > cgf > > The current proposal will not work if someone first dups the device > descriptor, and then changes the audio settings with ioctl calls using > one of the two device descriptors. The other one will keep the old > settings. > > The patch I am preparing will fix this. However, I also have problems to > build the cygwin DLL. I'll try to do it tonight. > > Gerd Huh? I'm most likely misunderstanding something... Aren't the audio settings kept in the Audio objects? Those are shared, so any changes made to one via the first descriptor should be visible via the second descriptor, right? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "I have since come to realize that being between your mentor and his route to the bathroom is a major career booster." -- Patrick Naughton
Re: [RFC] Reference counting on Audio objects for /dev/dsp
On Sat, Jul 17, 2004 at 09:29:13PM +0200, Gerd Spalink wrote: >The current proposal will not work if someone first dups the device descriptor, >and then changes the audio settings with ioctl calls using one of the two >device descriptors. The other one will keep the old settings. > >The patch I am preparing will fix this. However, I also have problems to build >the cygwin DLL. I'll try to do it tonight. So, just to be a broken record, you could use archetypes. That's what they were designed for. cgf
RE: [RFC] Reference counting on Audio objects for /dev/dsp
The current proposal will not work if someone first dups the device descriptor, and then changes the audio settings with ioctl calls using one of the two device descriptors. The other one will keep the old settings. The patch I am preparing will fix this. However, I also have problems to build the cygwin DLL. I'll try to do it tonight. Gerd On Friday, July 16, 2004 4:31 AM, Christopher Faylor [SMTP:[EMAIL PROTECTED] wrote: > On Thu, Jul 15, 2004 at 04:28:56PM -0400, Igor Pechtchanski wrote: > >On Thu, 15 Jul 2004, Christopher Faylor wrote: > > > >> On Thu, Jul 15, 2004 at 02:57:17PM -0400, Igor Pechtchanski wrote: > >> >> 2) The other problem is that I find it sort of odd to see the dec() > >> >> method performing a deletion. Couldn't this be handled where, IMO, > >> >> it should logically be handled, in the close function, e.g., > >> >> > >> >> if (!audio_out_->dec ()) > >> >> delete audio_out_; > >> >> ? > >> > > >> >Umm, that's actually a rather standard construct in reference counting > >> >(called "object suicide" -- you should get some references if you Google > >> >for "object suicide reference counting"). > >> > >> Yes, I thought that would be your answer, however, I don't like the idea > >> of having a method called "inc" which just increments a count and a method > >> called "dec" which decrements a count and, oh, hey, it might delete the > >> object, too. > >> > >> It seems more straightforward to delete audio_out_ in the place where > >> you'd expect it to be deleted rather than having a "dec" call which, > >> if you check, you'll notice that it deletes the buffer. > >> > >> Or, as a compromise, don't call it 'dec'. Call it something which > >> illustrates what it is doing. > > > >Right. I think the compromise is good -- I was thinking of maybe using > >registerReference() and releaseReference() (or deregister?). We could > >shorten them by removing "Reference" from the names, too. In any case, > >I'd wait for Gerd's input before deciding on the specific code to go in. > > That sounds good to me. > > Now we just need Gerd's ok. > > cgf
Re: [RFC] Reference counting on Audio objects for /dev/dsp
On Thu, Jul 15, 2004 at 04:28:56PM -0400, Igor Pechtchanski wrote: >On Thu, 15 Jul 2004, Christopher Faylor wrote: > >> On Thu, Jul 15, 2004 at 02:57:17PM -0400, Igor Pechtchanski wrote: >> >> 2) The other problem is that I find it sort of odd to see the dec() >> >> method performing a deletion. Couldn't this be handled where, IMO, >> >> it should logically be handled, in the close function, e.g., >> >> >> >> if (!audio_out_->dec ()) >> >> delete audio_out_; >> >> ? >> > >> >Umm, that's actually a rather standard construct in reference counting >> >(called "object suicide" -- you should get some references if you Google >> >for "object suicide reference counting"). >> >> Yes, I thought that would be your answer, however, I don't like the idea >> of having a method called "inc" which just increments a count and a method >> called "dec" which decrements a count and, oh, hey, it might delete the >> object, too. >> >> It seems more straightforward to delete audio_out_ in the place where >> you'd expect it to be deleted rather than having a "dec" call which, >> if you check, you'll notice that it deletes the buffer. >> >> Or, as a compromise, don't call it 'dec'. Call it something which >> illustrates what it is doing. > >Right. I think the compromise is good -- I was thinking of maybe using >registerReference() and releaseReference() (or deregister?). We could >shorten them by removing "Reference" from the names, too. In any case, >I'd wait for Gerd's input before deciding on the specific code to go in. That sounds good to me. Now we just need Gerd's ok. cgf
Re: [RFC] Reference counting on Audio objects for /dev/dsp
On Thu, 15 Jul 2004, Christopher Faylor wrote: > On Thu, Jul 15, 2004 at 02:57:17PM -0400, Igor Pechtchanski wrote: > >> 2) The other problem is that I find it sort of odd to see the dec() > >> method performing a deletion. Couldn't this be handled where, IMO, > >> it should logically be handled, in the close function, e.g., > >> > >> if (!audio_out_->dec ()) > >> delete audio_out_; > >> ? > > > >Umm, that's actually a rather standard construct in reference counting > >(called "object suicide" -- you should get some references if you Google > >for "object suicide reference counting"). > > Yes, I thought that would be your answer, however, I don't like the idea > of having a method called "inc" which just increments a count and a method > called "dec" which decrements a count and, oh, hey, it might delete the > object, too. > > It seems more straightforward to delete audio_out_ in the place where > you'd expect it to be deleted rather than having a "dec" call which, > if you check, you'll notice that it deletes the buffer. > > Or, as a compromise, don't call it 'dec'. Call it something which > illustrates what it is doing. > > cgf Right. I think the compromise is good -- I was thinking of maybe using registerReference() and releaseReference() (or deregister?). We could shorten them by removing "Reference" from the names, too. In any case, I'd wait for Gerd's input before deciding on the specific code to go in. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "I have since come to realize that being between your mentor and his route to the bathroom is a major career booster." -- Patrick Naughton
Re: [RFC] Reference counting on Audio objects for /dev/dsp
On Thu, Jul 15, 2004 at 02:57:17PM -0400, Igor Pechtchanski wrote: >> 2) The other problem is that I find it sort of odd to see the dec() >> method performing a deletion. Couldn't this be handled where, IMO, >> it should logically be handled, in the close function, e.g., >> >> if (!audio_out_->dec ()) >> delete audio_out_; >> ? > >Umm, that's actually a rather standard construct in reference counting >(called "object suicide" -- you should get some references if you Google >for "object suicide reference counting"). Yes, I thought that would be your answer, however, I don't like the idea of having a method called "inc" which just increments a count and a method called "dec" which decrements a count and, oh, hey, it might delete the object, too. It seems more straightforward to delete audio_out_ in the place where you'd expect it to be deleted rather than having a o a "dec" call which, if you check, you'll notice that it deletes the buffer. Or, as a compromise, don't call it 'dec'. Call it something which illustrates what it is doing. cgf
Re: [RFC] Reference counting on Audio objects for /dev/dsp
On Thu, 15 Jul 2004, Christopher Faylor wrote: > On Thu, Jul 15, 2004 at 09:44:34AM -0400, Igor Pechtchanski wrote: > >Gerd, > > > >I'd really like your comments on this patch. As I reported before, it > >didn't quite work for me, but with the recent problems in testing another > >(presumably working) patch, I suspect my test procedure isn't quite > >correct anyway. The patch basically adds a (very problem-specific) > >reference count to the Audio object(s), and doesn't delete the shared ones > >until all pointers are gone. It doesn't seem to fix the bash redirection > >problem, but does allow the "dsp_dup_close" testcase to run (again, I'd > >like your opinion on whether it runs correctly). > > > >The ChangeLog below is just for the record -- as I said, I don't expect > >this to be checked in yet. > > Igor > >== > >ChangeLog: > >2004-07-06 Igor Pechtchanski <[EMAIL PROTECTED]> > > > > * fhandler_dsp.cc (fhandler_dev_dsp::Audio::reference_count_): > > New instance variable. > > (fhandler_dev_dsp::Audio::inc): New function. Increment the > > reference_count_. > > (fhandler_dev_dsp::Audio::dec): New function. Decrement the > > reference_count_ and delete if zero. > > (fhandler_dev_dsp::close): Replace delete with a call to dec(). > > (fhandler_dev_dsp::dup): Copy audio_in_ and audio_out_ and call > > inc() on each. > > Thanks for the patch. I have two problems, though. > > 1) Some minor problems with GNU formatting: > > fhc->audio_out_ = audio_out_; if (audio_out_) audio_out_->inc () > audio_out_ -> dec (); Thanks for the review. Yep. Once we determine whether this works (or if it doesn't, why), I'll get the formatting in order before resubmitting. As I said before, I don't expect this to be checked in for now. > 2) The other problem is that I find it sort of odd to see the dec() > method performing a deletion. Couldn't this be handled where, IMO, > it should logically be handled, in the close function, e.g., > > if (!audio_out_->dec ()) > delete audio_out_; > ? Umm, that's actually a rather standard construct in reference counting (called "object suicide" -- you should get some references if you Google for "object suicide reference counting"). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "I have since come to realize that being between your mentor and his route to the bathroom is a major career booster." -- Patrick Naughton
Re: [RFC] Reference counting on Audio objects for /dev/dsp
On Thu, Jul 15, 2004 at 09:44:34AM -0400, Igor Pechtchanski wrote: >Gerd, > >I'd really like your comments on this patch. As I reported before, it >didn't quite work for me, but with the recent problems in testing another >(presumably working) patch, I suspect my test procedure isn't quite >correct anyway. The patch basically adds a (very problem-specific) >reference count to the Audio object(s), and doesn't delete the shared ones >until all pointers are gone. It doesn't seem to fix the bash redirection >problem, but does allow the "dsp_dup_close" testcase to run (again, I'd >like your opinion on whether it runs correctly). > >The ChangeLog below is just for the record -- as I said, I don't expect >this to be checked in yet. > Igor >== >ChangeLog: >2004-07-06 Igor Pechtchanski <[EMAIL PROTECTED]> > > * fhandler_dsp.cc (fhandler_dev_dsp::Audio::reference_count_): > New instance variable. > (fhandler_dev_dsp::Audio::inc): New function. Increment the > reference_count_. > (fhandler_dev_dsp::Audio::dec): New function. Decrement the > reference_count_ and delete if zero. > (fhandler_dev_dsp::close): Replace delete with a call to dec(). > (fhandler_dev_dsp::dup): Copy audio_in_ and audio_out_ and call > inc() on each. Thanks for the patch. I have two problems, though. 1) Some minor problems with GNU formatting: fhc->audio_out_ = audio_out_; if (audio_out_) audio_out_->inc () should be: fhc->audio_out_ = audio_out_; if (audio_out_) audio_out_->inc () nor is this: audio_out_ -> dec (); should be: audio_out_->dec (); 2) The other problem is that I find it sort of odd to see the dec() method performing a deletion. Couldn't this be handled where, IMO, it should logically be handled, in the close function, e.g., if (!audio_out_->dec ()) delete audio_out_; ? cgf
[RFC] Reference counting on Audio objects for /dev/dsp
Gerd,
I'd really like your comments on this patch. As I reported before, it
didn't quite work for me, but with the recent problems in testing another
(presumably working) patch, I suspect my test procedure isn't quite
correct anyway. The patch basically adds a (very problem-specific)
reference count to the Audio object(s), and doesn't delete the shared ones
until all pointers are gone. It doesn't seem to fix the bash redirection
problem, but does allow the "dsp_dup_close" testcase to run (again, I'd
like your opinion on whether it runs correctly).
The ChangeLog below is just for the record -- as I said, I don't expect
this to be checked in yet.
Igor
==
ChangeLog:
2004-07-06 Igor Pechtchanski <[EMAIL PROTECTED]>
* fhandler_dsp.cc (fhandler_dev_dsp::Audio::reference_count_):
New instance variable.
(fhandler_dev_dsp::Audio::inc): New function. Increment the
reference_count_.
(fhandler_dev_dsp::Audio::dec): New function. Decrement the
reference_count_ and delete if zero.
(fhandler_dev_dsp::close): Replace delete with a call to dec().
(fhandler_dev_dsp::dup): Copy audio_in_ and audio_out_ and call
inc() on each.
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster." -- Patrick NaughtonIndex: fhandler_dsp.cc
===
RCS file: /cvs/src/src/winsup/cygwin/fhandler_dsp.cc,v
retrieving revision 1.37
diff -u -p -r1.37 fhandler_dsp.cc
--- fhandler_dsp.cc 28 May 2004 19:50:05 - 1.37
+++ fhandler_dsp.cc 15 Jul 2004 13:40:36 -
@@ -80,7 +80,13 @@ class fhandler_dev_dsp::Audio
(unsigned char *buffer, int size_bytes);
inline void lock () { EnterCriticalSection (&lock_); }
inline void unlock () { LeaveCriticalSection (&lock_); }
+
+// inline void inc (void) { reference_count_++; }
+// inline void dec (void) { if (--reference_count_ == 0) delete this; }
+ void inc (void);
+ void dec (void);
private:
+ DWORD reference_count_; /* HACK A quick-and-dirty reference count */
DWORD owner_; /* Process ID when wave operation started, else 0 */
CRITICAL_SECTION lock_;
};
@@ -231,6 +237,20 @@ fhandler_dev_dsp::Audio::Audio ()
InitializeCriticalSection (&lock_);
convert_ = &fhandler_dev_dsp::Audio::convert_none;
owner_ = 0L;
+ reference_count_ = 1; // Going to assign right after allocation
+}
+
+void fhandler_dev_dsp::Audio::inc (void) {
+ reference_count_++;
+ debug_printf("%08p; ref_count=%ld\n", this, reference_count_);
+}
+
+void fhandler_dev_dsp::Audio::dec (void) {
+ debug_printf("%08p; ref_count=%ld\n", this, reference_count_-1);
+ if (--reference_count_ == 0) {
+debug_printf("-- deleting\n");
+delete this;
+ }
}
fhandler_dev_dsp::Audio::~Audio ()
@@ -1202,7 +1222,7 @@ fhandler_dev_dsp::close (void)
(int)audio_in_, (int)audio_out_);
if (audio_in_)
{
- delete audio_in_;
+ audio_in_->dec ();
audio_in_ = NULL;
}
if (audio_out_)
@@ -1212,7 +1232,7 @@ fhandler_dev_dsp::close (void)
// do not wait for all pending audio to be played
audio_out_->stop (true);
}
- delete audio_out_;
+ audio_out_ -> dec ();
audio_out_ = NULL;
}
if (open_count > 0)
@@ -1231,6 +1251,9 @@ fhandler_dev_dsp::dup (fhandler_base * c
fhc->audiobits_ = audiobits_;
fhc->audiofreq_ = audiofreq_;
fhc->audioformat_ = audioformat_;
+
+ fhc->audio_in_ = audio_in_; if (audio_in_) audio_in_->inc ();
+ fhc->audio_out_ = audio_out_; if (audio_out_) audio_out_->inc ();
return 0;
}
