Re: Capturing currently played audio using CoreAudio on Mac
Re: Capturing currently played audio using CoreAudio on Mac
- Subject: Re: Capturing currently played audio using CoreAudio on Mac
- From: "Paul Sanders" <email@hidden>
- Date: Mon, 19 Apr 2010 18:04:35 +0100
> [ meta-comment: I didn't really intend to
continue this on the mailing list, but i guess its fairly CA-related
]
Yes, we are rambling a bit, but I wanted to make it public
that I am not slating JACK and think we're just about in Kansas still. I
suspect the OP is long gone though :)
> The CoreAudio backend in recent versions now has a
"hog mode" switch
> which prevents other apps from doing this. We consider
this to be a
> really unfortunate combination of user error and
other-app-design
> error. There are several CoreAudio apps which attempt
to reset the SR
> of a device as they startup - its hard for me to imagine
what their
> developers were thinking. Its pretty hard to explain to a
user "please
> don't start application <X>" when they have no
conception that <X>
> could interfere with the already established
and in-use settings of
> another application.
Yes, I know about that. It's actually quite a thorny
issue for apps talking to CoreAudio. Just for the record, we just go
ahead and ask the device for the samplerate we want (on demand, not on startup)
because if the user has asked us to record at 96kHz that's what we want to
do. We can (and do, where necessary) do samplerate conversions but if the
device is only running at (say) 48Khz and can do 96, the wool is being pulled
over the user's eyes if we don't reconfigure it. However, we only ever ask
for a samplerate the device tell us it supports so we are 'well-behaved' as far
as JACK is concerned as it only offers us the samplerate the user has
configured in the Jack Pilot preferences so we will never ask it to
switch. We could, I guess, be more relaxed on the output side. It's
not so important there that the device is running at the speed the user asked
for.
We do ask for hog mode. It doesn't seem to make any
difference so I guess we must be doing it wrong. If another app
reconfigures a device we are using, we take no action at all (i.e. we continue
to use it at what is now the wrong samplerate so it just sounds weird).
This is obviously taking the easy way out but we haven't (as yet) had any
customer complaints about this. On the record side, it would be impossible
to avoid a glitch so it might be better if it just sounds weird anyway. On
the output side, a glitch wouldn't matter.
> Ah, you're interacting JACK as a CoreAudio device. Sorry, out of
my
> area of expertise. I was describing JACK's interactions with
>
JACK-native clients. I don't know much about the story it presents to
>
apps that want to treat it like a regular CoreAudio device.
I thought that was the whole idea! Anyway, I will
report the fact that our app is left hanging when you shut down the JACK
server to the JACK folks, but judging by the warning message they currently
display, they've already given up on that one.
Kudos to the man who wrote JACK originally, and indeed to
those who continue the good work. It has been a big help to me during
testing.
Paul Sanders.
_______________________________________________
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