• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Thread count strangeness using PlayAudioFile sample code
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thread count strangeness using PlayAudioFile sample code


  • Subject: Re: Thread count strangeness using PlayAudioFile sample code
  • From: Evan Gross <email@hidden>
  • Date: Fri, 01 Apr 2005 23:54:03 -0500

On 3/29/05 9:29 AM, "Robert Martin" <email@hidden> wrote:

<snip>
>
> It works fine, but I ran top and noticed that after each call to
> PlayAudioFile, my thread count permanently increases by 1. I'm new to
> threads and cannot figure out what's causing this - or even whether I
> should worry about it.
>
> Each pass through PlayAudioFile seems to create 2 threads but release
> only one: AFP_Connect(player) creates a fileReader thread which is
> released, but the thread created in AudioOutputUnitStart(theUnit) does
> not seem to be released in AudioOutputUnitStop(theUnit) even if I
> follow this with CloseComponent(theUnit).
>
<snip>

I ran into this as well. I would also classify this as a bug, or at least an
undesirable thing. Play a sound 100 times, see 100 threads more (in Activity
Viewer or whatever) than when the first sound was played? Not OK for a
shipping app!

Anyway, I wasn't thrilled with this, so made a couple of changes to
AudioFileReaderThread.cpp and all seems to be well (my modified version has
been shipping in my product for a couple of months now - no problem reported
in this area).

The fundamental change was to FileReaderThread::ReadNextChunk (),
specifically:

            while (mFileData.empty()) {
                fileReadLock.Wait();
            }

change to:

            while (mFileData.empty() && !mThreadShouldDie) {
                fileReadLock.Wait();
            }

and while perhaps not absolutely necessary, I changed:

static FileReaderThread sReaderThread;

to:

static FileReaderThread *sReaderThread = nil;

then in AudioFileReaderThread::AudioFileReaderThread added:

    if (sReaderThread == nil)
        sReaderThread = new FileReaderThread;

and accordingly changed all the sReaderThread.whatever's to
sReaderThread->whatever's.

If you'd like the actual modified source, feel free to email me off-list.

And more importantly, if anyone finds some sort of possible problem with the
modifications I made, PLEASE let me know! I'm so far from being any sort of
audio expert it's not funny...

HTH,
Evan Gross

--
+------------------------------------------------------------------------+
|            Evan Gross, President, Rainmaker Research Inc.              |
|          - Developers of Macintosh and Windows Software -              |
|                Spell Catcher for Mac OS and Windows                    |
|                Visit <http://www.rainmakerinc.com>                     |



 _______________________________________________
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

  • Follow-Ups:
    • Re: Thread count strangeness using PlayAudioFile sample code
      • From: Robert Martin <email@hidden>
  • Prev by Date: Re: Allowing a user-space driver to be the default
  • Next by Date: Re: Thread count strangeness using PlayAudioFile sample code
  • Previous by thread: Re: Allowing a user-space driver to be the default
  • Next by thread: Re: Thread count strangeness using PlayAudioFile sample code
  • Index(es):
    • Date
    • Thread