|
Hello again Stephane,
No, we never see it. A breakpoint on our 'Listener'
function is never hit (and I checked, via the iMic, that gdb wasn't playing it's
little trick of not stopping at breakpoints). As I previously surmised,
our IOProc just stops getting called (which is what one would expect, of course)
so, in the absence of kAudioDevicePropertyDeviceIsAlive turning
up, things we expect to happen never do. Assuming this is a problem
in JACK, it can probably be debugged via MTCoreAudio. I'd be happy to test
any new version.
I also have a bit more information on that !dat error I
mentioned if you are interested. I can't find a way to reliably reproduce
it happened again so I now have some log files that might interest
you. I think we should do that (and maybe everything else from now on)
off-list.
For the benefit of the OP, if he's still with us, another
minor glitch with JACK is that if (as we do) an app changes the sample rate
of the device that JACK is routing from or to, the Jack server pops up a
box and has to be restarted. I forgot about that one. It would be
nice if JACK could handle this condition without user intervention but I can see
that might be tricky. Also, I don't understand how to set
up aggregate devices and there may be solutions to issues like this there
so please don't consider me any kind of authority. And I think I
should mention that Jack has more flexible channel routing functions than
Sound Flower.
Y'know, sometimes I wish I wasn't so opinionated. Or
maybe just better informed...
Paul Sanders.
----- Original Message -----
Sent: Tuesday, April 20, 2010 1:55 PM
Subject: Re: Capturing currently played audio using CoreAudio on
Mac
> Well I checked the code again and actually the
kAudioDevicePropertyDeviceIsAlive property is sent
> by JackRouter when JACK server stops. Don't you see
it in your code?
Apparently not. Or maybe it's some kind of timing
issue. I will investigate and get back to you, possibly
off-list.
Paul Sanders.
|