On Sun, 2003-03-02 at 19:49, Dominic Mazzoni wrote:
> Joshua Haberman wrote:
> > On Sun, 2003-03-02 at 16:04, Dominic Mazzoni wrote:
> >>Joshua Haberman wrote:
> >>>Why do you use the model of updating the mixer from the audio thread?
> >>The big reason is that on most platforms you can't edit the mixer
> >>unless you have an open, active audio stream. In fact, on some
> >>platforms, there is no such thing as a mixer - all of the mixer
> >>controls are just properties of an open audio stream, or an audio
> > You're saying that on these platforms, it is impossible to adjust the
> > hardware mixer unless there is already a stream running?? How does the
> > system mixer adjust the mixer settings? Surely they don't set up a
> > "dummy" stream just to get access to the mixer.
> On Mac OS X, for whatever reason, output level and input level are
> stream-level features. System control panels don't seem to
> affect running applications, they just affect the defaults the
> next time a program is opened.
How about this: whenever the mixer sliders are moved, call
AudioIO::SetMixerVolume() immediately, which would look something like
this (pseudocode, I neglect separate playback/recording vol, etc.):
/* this will get updated next time through the PortAudio
callback. We don't worry about the fact that this won't
take effect until then, since the concept of a mixer
volume doesn't exist until there is a stream to associate
it with. */
mVolume = volume;
And then to make mVolume actually take effect, you can have something
/* ... */
In an OnTimer handler, call AudioIO::GetMixerVolume() on a regular
basis. It would look like this:
/* mVolume always represents the most up-to-date data we have
for the mixer volume */
/* Other applications may have changed the hardware volume
behind our backs. Re-read the mixer to receive this
I know this breaks the abstraction of PortMixer some which is
undesirable, but I think this is unavoidable given the substantial
differences in usage and semantics between the platforms. The advantage
is that you give the users of each platform the behavior they expect
from other native applications.
> In the long run, I can probably be convinced to see things your
> way. But I think that the advantages in terms of code cleanliness
> are quite small considering the number of issues we'd have to
> deal with, so I'd like to stay with the current model through
> 1.2. Basically, I don't want to refactor the code before 1.2
> unless there would be a _functional_ gain.
My argument is definitely not one for code cleanliness, it's primarily
to give the mixer toolbar more robust behavior. I only mentioned adding
extra methods to AudioIO to address your (well-founded) fears of letting
PortAudioStreams seep out of AudioIO.cpp.