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.
> If it only requires an open-but-not-running stream, I think we should
> accommodate by having AudioIO leave the device open but stopped all the
> time. As a user of Audacity, I would find a mixer that is wrong some of
> the time worse than no mixer at all.
You're a power user. Let's add an option to hide the mixer toolbar.
Our email traffic indicates that 90% of our users have no idea that
there's a such thing as a system mixer. The mixer toolbar is intended
Also, I don't see any reason why we can't fix the mixer toolbar so
that it does respond to changes by other applications. A simple
timer event in the MixerToolBar class, whenever a stream isn't
already open, would work fine.
>>If you wanted the sliders to modify the mixer directly, you'd run
>>into all sorts of race conditions and problems if you close the
>>audio stream and then try to modify the mixer. Even if you
>>worked around those, the slider class would still have to ask
>>Audio I/O for a handle to its PortAudioStream.
> That seems easy to avoid by just having methods
> GetMixerVol()/SetMixerVol()/etc. in AudioIO.cpp.
You mean if a stream is always open?
>>Also keep in mind that if the sliders modified the mixer, we'd
>>have to tell them to re-apply or re-load their settings every
>>time the user changes the audio device in the preferences dialog.
> That doesn't seem like a problem either, I think the best thing to do
> would be to have the toolbar update itself to reflect the levels of the
> new device. It's like turning your head from one amp to another, the
> knobs are automatically wherever you left them.
I'm afraid that keeping the streams open opens up a new can of
worms. For OSS users, that means that they can't use any other
audio app while Audacity is running.
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.