Re: Curious happening with CAPlayThough
Re: Curious happening with CAPlayThough
- Subject: Re: Curious happening with CAPlayThough
- From: "Stephan M. Bernsee" <email@hidden>
- Date: Thu, 8 Jan 2009 21:50:11 +0100
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