Re: Curious happening with CAPlayThough
Re: Curious happening with CAPlayThough
- Subject: Re: Curious happening with CAPlayThough
- From: Neil Clayton <email@hidden>
- Date: Fri, 9 Jan 2009 13:29:55 +1300
- Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
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
Neil Clayton
email@hidden
--
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
Neil Clayton
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