Re: Changing the way the OS responds to a USB DAC
Re: Changing the way the OS responds to a USB DAC
- Subject: Re: Changing the way the OS responds to a USB DAC
- From: SB Tech <email@hidden>
- Date: Thu, 08 Mar 2012 19:14:15 +0000
Hi,
I've now been in touch with both companies concerning the way their USB devices behave with the OS - Fiio seem willing to accept that there may be a problem, and are asking how they should best proceed. In the experience of those here, is changing USB audio descriptors something that can typically be done once a device has been constructed? For example, does the USB port itself offer the ability to flash the firmware (which is presumably what needs to happen here)? According to the website, the E7 uses a "Texas Instruments’ PCM2706" USB receiver.
Beresford also seem willing to pursue this as a flaw, but I suspect that they were unaware of the presence or importance of USB Audio Class Descriptors in their device. The Caiman, as has been pointed out, uses a "Texas Instruments PCM2902".
I think in both cases the companies are willing to improve their products in this regard, and if those here don't mind advising me, I would like to help them do so by indicating the correct path to go down to pursue the required changes. I suppose the first thing to determine is whether the USB Audio Class Descriptors necessary for describing available controls are actually modifiable on the chips mentioned.
Regards.
On 5 March 2012 01:06, Brian Willoughby
<email@hidden> wrote:
On Mar 4, 2012, at 07:47, SB Tech wrote:
Hmm. I wasn't aware that the OS was capable of directly controlling certain USB Audio Devices' volume directly (ie. presumably by "talking" (in)directly to their amp(s)), but that makes sense.
To clarify, I believe it is accurate to make a distinction between the "OS volume control" and the CoreAudio driver for an audio device. Even though CoreAudio is technically part of the OS, the OS volume control is completely separate. In other words, I would say that the OS is not capable of directly controlling any USB Audio Devices' volume, but rather than the OS uses CoreAudio as a translation layer to make this possible whether USB is part of the equation or not.
The key point here is that the OS volume control software has absolutely no USB code in it. The OS volume control speaks CoreAudio API in order to discover what volume control(s) is/are available for a specific device, and to make changes in volume if they are available. Non-USB audio devices need a custom driver unless they are part of another audio standard such as FireWire. USB Audio Devices communicate with CoreAudio according to the standards set forth by the USB specifications.
However, in my case neither of my devices can have their output volumes directly controlled by the OS, so that would surely mean they are reporting their capabilities incorrectly to the OS. If this is the case, then please tell me, because the designer of the Beresford is a frequenter of my audiophile forum and I could directly request a feature change there (he's on the verge of releasing a new model as we speak). As for the Fiio: perhaps a firmware update could be requested.
I doubt that either one of us can say for certain what the capabilities are for your audio hardware. I can think of at least four different technology solutions that would allow a USB Audio Device to change volume under software control.
For my part, I had assumed that the OS volume control modified the volume by modifying the audio data directly (the same way that adjusting the volume in iTunes does)*,
You are correct that iTunes modifies the audio data directly when the volume in the GUI is below full. However, the OS volume control does not even have access to the audio data. The OS volume control queries the CoreAudio driver for the audio interface in question, discovers the number of volume controls for the device, and then sends parameter change messages to set the volume. At no time does the "OS volume control" even see audio data, much less have the opportunity to alter the audio data.
This is quite similar to the way in which an AudioUnit separates the parameter GUI from the audio engine, although the OS volume control is not an AudioUnit and I do not intend to imply that it is by drawing a comparison between the two parameter-based systems.
Note, it is possible for a custom audio device driver to alter the volume by modifying the data directly, and also to advertise a volume control to CoreAudio such that the OS volume control could do this. However, nearly all USB Audio Devices will not have custom drivers, nor will many of the FireWire audio devices.
and for that reason found it odd that the OS volume controls remained when the DACs were chosen, yet didn't modify the volume of the playing track when adjusted.
Either way, the availability of the OS volume controls when my DACs are selected is confusing and a red herring, and really ought to be disabled, by whichever method is the most appropriate.
For some reason, your original email did not make it clear that your DACs ignore changes to the OS volume control. Now that you've stated this directly, I can say that there is a problem with those DAC products, and apparently both are affected. One of the tasks in my work is to develop USB Device firmware, including UAC, and I can easily see how some vendor might simply copy the USB Descriptors for a different, previously existing audio interface, such that OSX and CoreAudio thinks that there is a volume control when there really is none.
In any case, this is now clearly a case where you should report the bug to the hardware vendor, because only they can fix it.
The simplest fix, assuming that there really is no volume control available in the hardware, is for the USB Audio Class Descriptors to be modified so that they do not falsely advertise the availability of any volume controls.
Brian Willoughby
Sound Consulting
_______________________________________________
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