Idea: Per-Application sound input/output settings
Idea: Per-Application sound input/output settings
- Subject: Idea: Per-Application sound input/output settings
- From: Christian Brunschen <email@hidden>
- Date: Fri, 8 Oct 2004 11:57:27 +0100
Hi all,
I'm posting this message here, because I'm not really sure where else I
should post it. I know this list is about core audio and its APIs, and
this message is very much audio-specific, but it really touches not
just on core-audio but also on higher-level application framework type
things, so I know that parts of it are probably not really appropriate
for here. So I'd be more than happy if someone could suggest the most
appropriate forum for this. I know that one such forum would be to
submit an 'enhancement request' at bugreport.apple.com, but at the
moment I think that discussion, rather than a finished proposal, would
be of more value. So, here goes ...
Until recently, most Macs had only one audio input or output device.
However these days, with USB and FireWire audio I/O devices as well as
built-in ones, any one specific Mac can have a multitude of audio input
and/or output devices.
To some extent, this is recognized by the system: in Preferences, one
can choose a different 'system output' device than the 'default output'
device; this allows the user to essentially separate sustem-generated
sound from application-generated sound.
But these days there are many applications that generate sound; most of
these applications are generally written to just use their default
audio output device. This means that most applications will share a
common audio output device which will thus be the target of essentially
*all* sound that is being generated by applications. The exception to
this is that specific audio or music editing or processing software is
usually written with multiple audio i/o devices in mind, and allows the
user to choose which device they require at any given time. Each such
application still tends to have its own, different, user interface for
choosing audio devices, so there is no coherence, and the user
experience is very fragmented.
I would love it if it were possible to set, on a per-application basis,
the default audio input & output devices for that application, as well
as a per-application output volume and/or input gain. Ideally, this
should be possible to re-configure while the application runs.
This would allow me as a user to run two applications side-by-side, but
with their audio directed at different output devices; or at the same
output device but with different output volume settings for each
application as a whole.
Consider if I'm watching a DVD movie in one window while carrying on an
iChat chat (textual only) in another, on a system with only one audio
output device. Both DVD Player and iChat would use the same audio
device, but I wouldn't want iChat's audible notifications of incoming
messages to drown out the sound of the DVD, so I'd turn iChat's volume
down low - so the notifications would still be audible, but not so much
as to interrupt the sound of the movie.
Or if I have a system with a high-quality sound output over USB, which
I would like to use to play music using iTunes to my stereo; and I'm
also working on some other program that gives me audio feedback of some
sort, which I'd just want over the built-in speakers of my PowerBook.
I'd set iTunes to use the USB output device and high volume, and I'd
set the other app to use the internal speakers and possibly a lower
volume setting.
Ideally, all of this would be essentially invisible to current
applications. Any application that today just talks to the default
audio output device, would simply gain the capabilities of having that
output reassigned to another actual device and having its volume
adjusted, without any extra work on the part of the application. There
would probably be a new menu in the Application's menu bar - 'Sound' -
which would offer access to the sound output device(s), the volume, and
so on; the application code would be none the wiser, but the user would
have gained lots more flexibility.
Now, in the above examples, both iTunes and DVD Player already have a
'volume' setting within the application itself, so they're perhaps not
ideal examples. But the main gist of my argument remains.
Actually, one way of looking at what I'm asking for, is to get a
similar kind of flexibility and general, coherent user-friendlyness to
audio i/o, as the Mac was instrumental in giving us for graphical and
textual i/o, in the shape of a graphical, windowed user interface.
With multiple windows, you can choose which application gets how much
of your attention by changing window sizes and positions, bringing
windows to the front or pushing them to the back, etc. The audio
equivalent of this would be the ability to give each application a
different volume setting (possibly even different volume settings
depending on whether it's the active app or not). And of course,
windows can be dragged to different screens, and the equivalent of that
would be an ability to move an application's default audio output from
one device to another.
I'm going to spin a bit further on this thread of thought, if you don't
mind.
Rather than an application having by default only a default output
device, applications should have that, and also be able to ask for
'named' sound output devices - i.e., if they have more than one 'type'
of sound they play. Consider a game that wants to play both background
music, environmental sounds, and radio communication chatter; it could
ask for those three 'output devices', which would of course all default
to the default output device.
However, a user could then assign each of those 'devices' to a
different _actual_ device on their system - the background music to a
stereo output connected to their entertainment system, the
environmental sound to a 5.1 output device for positional accuracy, and
the radio chatter to headphones. They'd be able to set volume settings
for each of them, of course, even if they were mapped to the same
underlying physical device, so the volumes would be balanced according
to the wishes of the user.
Essentially, the application would interact not directly with the audio
device but with an application-level construct, much like applications
don't interact directly with a screen but with application-level
Windows; these abstractions would be created as requested by the
application and could then be moved to different physical devices and
have their settings (volume etc) adjusted individually - just like
windows can be individually resized and dragged between screens.
These window-like abstractions (where an application would request
several) would of course have to be used explicitly by the application,
but would then give the opportunity to split different parts of an
application's sound output to different devices, etc, as described
above - again, much like an application having multiple windows, each
of which can be moved to a different screen or all be on the same
screen and overlapping, at the user's discretion.
Most of what I've written above pertains directly to audio output, but
just as easily applies to audio input: If you have more than one audio
input device, it would be useful to be able to assign which one goes to
which application, in a fashion that is consistent and coherent across
the system.
It's really all about extending the same type of metaphor we have for
graphical and textual i/o in a windowing system in the (potential)
presence of multiple screens, to audio i/o in the presence of
potentially multiple audio i/o devices. In fact, there could be a
connection between the audio device settings and the gui: much like
making an application the active one usually brings (some of) its
window(s) to the front on the screen(s), some audio settings could be
applied to the active vs inactive application(s): inactive apps at low
volume on speakers in the background and the active app at higher
volume on headphones, for instance.
All in all, I think that something like what I'm sketching at would go
a long way towards making audio i/o much more of a first-class citizen,
an integral part of, the general user interface and user experience of
using a Mac, than it currently is.
Everybody, please, comment! Constructive criticism preferred :)
Best wishes,
// Christian Brunschen
_______________________________________________
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