Re: Curious happening with CAPlayThough
Re: Curious happening with CAPlayThough
- Subject: Re: Curious happening with CAPlayThough
- From: Jeff Moore <email@hidden>
- Date: Thu, 08 Jan 2009 18:31:46 -0800
That's interesting information. When I have seen drivers have a run on
problem, it was usually caused by the driver not doing enough
management of the erase head. Because the IOAudio family will continue
to play for a full ring buffer's worth of time after being told to
stop, any erase head problems will manifest kind of like this. It
happens like this especially with short sounds as the quick start/stop
sequence can exacerbate any existing problems.
The primary means to control the erase head is the IOAudioEngine
method, getCurrentSampleFrame(). This method is supposed to return
where in the ring buffer the driver is currently, but it doesn't have
to be an exact or perfect figure (although it should be reasonably
close). In fact in the AudioReflectorDriver, this method just returns
the current position with a granularity of 512 sample frames. This
allows the erase head to keep up, but not overwhelm the driver.
At any rate, one theory I have is that SoundFlower is keeping the
erase head running very far behind it's current position. So if you
have a sound that starts and stops quickly, then perhaps the erase
head is never getting a chance to run. So when IOAudio runs through
the buffer the last time, the old data hasn't been erased yet and you
hear it again. Just a theory, but it might provide some guidance on
where to look in the SoundFlower code to fix the problem.
BTW, if you have already found it, the AudioReflectorDriver code is in
our SDK in the directory, /Developer/Examples/CoreAudio/HAL
On Jan 8, 2009, at 4:29 PM, Neil Clayton wrote:
Thanks for the heads up there.
I've just tried the sample AudioReflectorDriver, and as you say -
the problem doesn't occur there.
I'll dig into this some more and see if I can get the SF driver to
behave itself. So far it seems as thought the hiccup problem is due
to the SF driver itself.
On 9/01/2009, at 9:50 AM, Stephan M. Bernsee wrote:
Jeff,
actually this is 100% reproducible. As a matter of fact I believe
we have already reported this as a DTS incident (which got rejected
IIRC because SF is not an Apple product). Here are some
instructions to get you started (this is from the example project
that we have submitted [******** inserted to anonymize names,
contact me off list for more information]). Also, please ignore
item #1 which is a separate bug (still unresolved, though):
---------------------------------------------------------------------------
******** Test Application
Purpose of this application:
---------------------------
This demo app uses the ********Device as a system output device in
order to route all system output to our ********App, which in turn
processes this audio and plays it back through the default output
device. This is done in order to enable the user to process all
system audio with our technology […]. This demo application is
based on CAPlayThrough and the SoundFlower KEXT and is a stripped-
down version of the full product, with all proprietary DSP code
being removed.
Problem description:
-------------------
(1) After some time of continuous operation (usually about an hour,
but may be less or more) the application starts to produce drop
outs. These drop outs manifest themselves as small gaps in the
output signal that interrupt playback. After resetting the
application eveything is back to normal again. These drop-outs
often occur when machine was previously put into sleep mode and is
resuming processing after waking up.
(2) When playing back system alert sounds, especially those with
prominent transients (such as "Bottle" or "Basso"), a single echo
of that sound can be heard at the beginning and sometimes the end
of the alert sound. It sounds as if a small snippet of the alert
sound is being repeated in a "hiccup" sort of way. Also, it is
worth noting that this "hiccup" effect goes away if an audio track
(eg. in iTunes) is playing in the background. Adding noise to the
signal path on our application level on the other hand does not
affect the hiccup problem.
Affected systems:
----------------
This behaviour has so far been confirmed on Intel MacPro and
MacBookPro machines running Leopard 10.5.4 - 10.5.6.
Steps to reproduce the problem:
------------------------------
Since problem (1) takes some time to manifest itself it is
paramount to let the app sit for a while. During that time, the
user can operate the Mac as usual.
1. in the ********Device/Leopard folder, build either the Release
or Debug target of the project ********Device_Leopard.xcodeproj
2. in Terminal, cd to the build folder and do a "sudo chown -R
root:wheel ********Device.kext", followed by a "sudo kextload -t
********Device.kext" in order to load the KEXT into the system.
You should see the following warning at this point:
extension ********Device.kext has potential problems:
Warnings
{
"A personality matches on IOResources but IOMatchCategory is
missing or not equal to its IOClass (driver may fail to win
matching)" = true
"Kext has no explicit kernel dependency" = true
}
kextload: extension ********Device.kext appears to be loadable
kextload: ********Device.kext loaded successfully
3. In the "Sound" system prefs pane ensure that a new output device
named "******** (2ch)" is available and select the "Built-In" audio
device as default output device.
4. Go to the ********App folder and compile & run the
********App.xcodeproj project (either Release or Debug target).
After launching the app, ensure that "******** (2ch)" has
automatically been set in the Sound prefs panel as the default
output device. If you are getting CPU overs and the app starts to
produce drop outs rightaway you might need to adjust line 61 in
file ********Menu.mm and reduce the amount of artificial CPU load
introduced there (see comment in source file for details).
5a. With no other app running, switch between system alert sounds
to demonstrate problem #2. Start iTunes and play back a song at low
volume to verify that the hiccup problem disappears (underflow
problem? Where??).
5b. Play tracks in iTunes and continue working with the Mac as
usual to demonstrate problem #1. This can take some time.
---------------------------------------------------------------------------
"******** (2ch)" should be "Soundflower (2ch)" in Neil's example.
I'm not sure that it really is a problem in the SSS because it
doesn't occur when using the AudioReflectorDriver instead of
Soundflower as audio device. Also, when playing iTunes in the
background this problem doesn't occur...
Any ideas?
Thanks!!
Stephan
On Jan 7, 2009, at 6:09 PM, Neil Clayton wrote:
Thanks Jeff,
To be more specific, I can click it once and hear this "echo" at
the
end of the audio being played. I'm certain it's not because I'm
clicking many times (I'm not clicking wildly, just clicking
numerous
times, with delays in between each to hear the outcome).
That falls within the description of one of the hard-to-reproduce
bugs
I was referring to.
I'd believe it were something to do with the sound server if I
heard
the issue with all three tools that I tried. The fact that it
works
with both GarageBand and LineIn makes me suspect something is
different about the code. That's kinda why I asked - not to
"blame"
CAPlayThrough in any way but to try to learn what was causing it.
Out of interest, it occurs with afplay as well. Not as obvious,
but
it certainly happens.
Here's a recording of the output:
http://dl.getdropbox.com/u/421935/Sample of Audio Blips
If I understand what you are saying, you produced this file thusly:
1) set SoundFlower as the default output device.
2) set up CAPlayThrough so that it is echoing the SoundFlower
input to
the built-in output
3) use afplay to play files out of /System/Library/Sounds meaning
that
each sound I hear in the recording is played via an invocation of
afplay.
Is this correct?
If so, this technique would nicely cut the System Sound Server out
of
the picture and absolve it of any guilt. The resulting glitches
would
then be either in SoundFlower when it is echoing it's output back to
it's input or in CAPlayThrough when it is echoing the SoundFlower
input to the built-in output.
So, the next thing to do would be to isolate the problem further by
recording the input from directly from SoundFlower while you are
testing. If the glitches are in the resulting recording, then you
know
that the problem is coming from SoundFlower. If the glitches are not
in the recording, then the problem is with CAPlayThrough.
On 8/01/2009, at 2:13 PM, Jeff Moore wrote:
I believe that you are probably just hearing the results of either
the System Sound Server handles re-triggering a sound while the
sound is already playing. Or it's just some kind of playback bug
in
the SSS (possibly one that's been around for a while but very hard
to reproduce normally).
At any rate, it seems unlikely to be a bug in CAPlayThrough
though.
I'd verify this by making sure that just playing audio to this
pipeline with a tool like afplay never has any artifacts.
It is definitely worth writing this up as a bug for us to look at
though.
On Jan 7, 2009, at 4:19 PM, Neil Clayton wrote:
I'm seeing some odd behavior that I'd like to clarify please.
I install Soundflower 2ch, and playthru from that to the built in
line-output. I setup the SF2ch device to be the default output.
I then go to system preferences Sound page, and repeatedly click
on the "Ping" sound (to hear it).
What I hear is that sometimes, it's broken up. As though the
last part of the sample is played again briefly.
Curiously, if I play iTunes to the SF2ch (and through
CAPlaythrough, to the default output) it's absolutely fine.
I'm pretty sure it's not the SF driver itself (but not 100%, I've
not verified the code at all), because it works find if I use
GarageBand for the same task (the playthru part). It also works
fine with LineIn (a similar util, free, from Rogue Amoeba).
So my question is; is this something to do with the way that the
AU is setup? Or to do with flags passed in during the
AudioUnitRender? Or something else entirely?
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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