Re: Enable system volume when driver doesn't
Re: Enable system volume when driver doesn't
- Subject: Re: Enable system volume when driver doesn't
- From: "Mikael Hakman" <email@hidden>
- Date: Tue, 18 Mar 2008 01:37:35 +0100
- Organization: Datakonsulten AB
That's better. I'll try to answer your questions.
On March 18, 2008 12:02, Brian Willoughby wrote:
To bring this back to the original problem...
Why is it that you cannot simply develop your own OS X application which
uses CoreAudio to play your media files? You could implement remote
controlled volume in your application, and not have to be concerned about
special hardware in the audio interface or special audio drivers. If
iTunes doesn't do what you want, then write your own software. That's
what CoreAudio is for ... and Cocoa.
In my judgement, to develop an application that matches or at least plays in
the same division as FR is much more work than developing a device driver.
FR is not only for iTunes. It beautifully supports all media including audio
files, video files, image discs, CD disks, DVD disks, DVB files etc. all
under nice and highly readable and easy to use, in particular on a big
screen, umbrella. FR is for media presentations what PP is for overhead
supported conferences and lectures. Except that you don't need to draw all
the foils - you simply maintain metadata on your files and FR draws and
plays automatically.
Barring that, why can't you just use Jack, and write a little extra code
to do what you want with that? There are also other solutions similar to
Jack which are open-source.
Perhaps it would be possible to use Jack. I'm not sure. In order for OS X to
activate its master volume control, a device driver (Jack in this case) has
to reply correctly to a number of queries (getProperty calls) from the
system and then of course it has to implement that volume control
(setProperty call). This can be either a master volume control affecting all
output channels (in a group) or it can be separate volume controls for each
channel, in which case OS X (or whoever it is) will call all and every of
the controls when the user changes, what to the user appears as a master
volume control. Actually, the built-in analog audio device in MBP and iMac
presents to OS X two volume controls, one for the left and one for the right
channel. Yet to the user this appears as a one master control.
Jack doesn't answer these queries and doesn't implement volume control. One
would have to modify Jack. That needs not to be simpler than writing
volume-controlling-only device driver. That depends on support that one
would receive for current Jack authors and maintainers, on how well it is
written, commented, documented, and on how many cooks there were during its
development history, so to speak. Some open source code is beautiful, some
is ugly, and some I wouldn't touch with a pair of tongs. Then there are
robustness and easy-to-pre-configure issues - from what I saw in user's
manual, Jack would need a lot of polishing in these areas to be useful in my
environment.
There are plenty of pieces of the solution to your problem that are
available, but it seems that you're complaining that you can't trivially
plug a bunch of existing products together and have your own business
model. You've got to add some value if you want to be a VAR. ;-)
There you go again - off topic. Your comment here is based on your own
assumption of what I'm adding or not. You don't have a slightest idea about
that. You start with wrong assumption and therefore your conclusion is
incorrect.
P.S. I basically only wrote to support the hardware manufacturers who
are making top-quality audio interfaces, and who have made careful
decisions to omit certain features which would compromise quality. Just
because they're not providing the exact hardware that you want to base
your business on does not mean they're missing out on a significant
market. I guess I'm confused because many of your complaints were the
sort of thing that only an audiophile would care about, which is the only
reason I began making the qualification of professional versus other.
One interesting thing in this context, which you may want to communicate to
hardware vendors with whom you collaborate, is the following.
If volume control would be implemented in their real driver, master or per
channel, then they wouldn't need to do it digitally at all. They could
simply expose their analog volume controls, the same as used by DAW apps or
by their own control panel app, to OS X. That wouldn't compromise quality,
would it? This wouldn't help me in this project because here I need digital
output, but it would at least be a step in right direction, perhaps useful
in another project.
_______________________________________________
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