Hi all,
Does anyone experienced any issues with TAS1020B under Win7? Is there any tweak or firmware update needed to make it work?
thanks,
best regards
OscarM.
Hi Wojtek,
I am very interested in your changes to make TAS1020B work as a stereo input device, is it possible to send me a copy of your "DevDesc.c" file? Or can you provide more details about the changes?
Thanks in advance
EZ
Hi Frank,
How to make sure the modified firmware of TAS1020B responding correctly with current/min/max/resolution values? I made change to the firmware, and the Windows audio volume adjustment is grayed out with TAS1020B.
Eric,
Two things need to happen:
1. The Audio Control Interface Descriptors have to be setup correctly to indicate that the parameter is adjustable, and
2. Your application needs to respond correctly to control transfers to get/set the values.
If you can capture the USB traffic using a sniffer, you can see if your modified application is doing both correctly.
Regards,
Frank
Thank you for the quick response, and I will look into the code for those two things.
BTW, there are two applications in TAS1020B FDK. One is v1.8, and the other is TSC1020_FW8. Which one is recommended?
Thanks
It's my understanding that the TSC1020_FW8 application was written for a "Low Cost Headphone System". The circuit board for the system was designed and a few built, but it was never released for OEM purchase. The schematic is available here. 5280.DAREF107R2_Schematic.pdf
This application has some different techniques, relative to the one for the TAS1020BEVM; that's why it is packaged in the FDK. Both applications are written assuming use of an AC'97 codec.
Frank Minich So, the problem was not in the configuration descriptor itself, but in handling of subsequent Audio Control messages.
So, the problem was not in the configuration descriptor itself, but in handling of subsequent Audio Control messages.
Shouldn't the ROM code handle the subsequent Audio Control messages automatically? In "ROM\usbaudio.c", it has following code piece:
case AUD_FU_VOLUME_CNTL: PARAMS_SETVOL(UsbRequest.hiwIndex, UsbRequest.lowValue); DEV_FUNCTION(DEV_SETVOL, &DEV_SHARED_DATA); break; case AUD_FU_BASS_CNTL: PARAMS_SETBASS(UsbRequest.hiwIndex, UsbRequest.lowValue); DEV_FUNCTION(DEV_SETBASS, &DEV_SHARED_DATA); break;
If ROM function does not provide the handling, how to add it in Application code? In "DevFunctionEntryParser"?
The ROM code cannot handle Audio Control messages 'automatically', because it doesn't know apriori the topology that you will identify in your Class-Specific AC Interface Descriptor (section 4.3.2 of the "USB Device Class Definition for Audio Devices, Release 1.0"). Specifically, it doesn't know which TerminalIDs you will use.
So, yes, on receipt of an Audio Control message, the ROM code invokes the application's handler via DEV_FUNCTION(), which invokes your routine at location 0x0100. The sample 'v1.8' application uses devProm.a51 to vector to your DevFunctionEntryParser() routine.
Hi,
I was wondering if I could get some information in order to get the TAS1020EVM to function as a stereo input device. From my reading of the USB Audio Spec and looking at the code files, it seems like changes have to be made to 'AppConfigDesc' in devDesc.c. In this file, there are two sections for microphone; one is MICIN and the other MICREC. I assume that I have to change both in order to set the number of channels to two and allow modification of volume for both channels?
Having made changes to the configuration for MICIN and MICREC, do I also have to make changes to DevFunctionEntryParser() in devSFunc.c to respond with volumes for both channels for MICIN and MICREC? If so, then the definitions for the MICIN and MICREC structures will also have to change in device.h.
Any guidance or example on this topic will be greatly appreciated.
Henry