It may not work in DACs relying on the i2s clocks for conversion instead of a master clock. i dont know 1541A enough to say whether it will work or not.
No processing。
The.XOs are NOT on.the.usb-i2s module. They.are supplied by the analog board (ie the DAC.board).
Alex
Hi Bo-Eric,
The.current widgets are stereo only. The sdr-widget is stereo in and stereo out.
Multichannel widgets are in the planning stage and we dont have any design yet.
Alex
The.current widgets are stereo only. The sdr-widget is stereo in and stereo out.
Multichannel widgets are in the planning stage and we dont have any design yet.
Alex
There have been some large changes to the AB-1.2 (and related) USB DAC lately. Noise problems which have bothered some have been significantly reduced, perhaps even eliminated completely. In addition, the AB-1.2 now has updated USB PID/VID/ID strings so that it now identifies itself more correctly towards a computer.
These changes are in AB-1.2 firmware and in the Windows driver.
All new kits are sent out with these changes. If you have an old AB-1.1 or AB-1.2 it is possible to update them with new firmware.
To use the changes you must first install new firmware from:
http://code.google.com/p/sdr-widget/downloads/detail?name=audio_widget_20121004_AB-1.2.elf
The installation of new firmware in the AB-1.2 is described in section "Installing new firmware - Windows" in
https://github.com/amontefusco/sdr-widget/blob/audio-widget-experimental/AW_readme.txt
On Windows you must un-install the old ASIO driver and install the latest version. See
http://www.qnktc.com/Win_cleanup.pdf
and
http://www.qnktc.com/Win_install.pdf
All of this takes a bit of an effort but should work itself out if you follow the instructions.
Cheers
Børge
These changes are in AB-1.2 firmware and in the Windows driver.
All new kits are sent out with these changes. If you have an old AB-1.1 or AB-1.2 it is possible to update them with new firmware.
To use the changes you must first install new firmware from:
http://code.google.com/p/sdr-widget/downloads/detail?name=audio_widget_20121004_AB-1.2.elf
The installation of new firmware in the AB-1.2 is described in section "Installing new firmware - Windows" in
https://github.com/amontefusco/sdr-widget/blob/audio-widget-experimental/AW_readme.txt
On Windows you must un-install the old ASIO driver and install the latest version. See
http://www.qnktc.com/Win_cleanup.pdf
and
http://www.qnktc.com/Win_install.pdf
All of this takes a bit of an effort but should work itself out if you follow the instructions.
Cheers
Børge
Last edited:
I've just updated to the 1.2 firmware on a 1.1 widget. Initially the WidgetControl.py complained because of vendorid and productid it didn't recognise but seemed fine when I added them.
It showed uac1_dg8saq when it first started and there is a green led showing on the widget. I could change the setting to uac2_dg8saq before pushing 'Start USB' but the led remains green.
I'm right in assuming it is still in uac1 mode?
It showed uac1_dg8saq when it first started and there is a green led showing on the widget. I could change the setting to uac2_dg8saq before pushing 'Start USB' but the led remains green.
I'm right in assuming it is still in uac1 mode?
Have you installed the new PC drivers as well? I don't know if the .py version of WidgetControl is 100% updated with new PIDs. On Windows the .exe version looks like the attachment.
Please make your settings align with what is shown in the screenshot. On Windows you should start it out as UAC1 and then change it to UAC2. On other OSes that shouldn't matter. A red front light means UAC2, green=UAC1.
Børge
Please make your settings align with what is shown in the screenshot. On Windows you should start it out as UAC1 and then change it to UAC2. On other OSes that shouldn't matter. A red front light means UAC2, green=UAC1.
Børge
Attachments
Not having access to a windows box I use the python script.
Having added the PID to the WidgetControl.py and used it to match the settings in your post I now have a red light and sound on my 1.1 with 1.2 firmware.
Thanks.
Having added the PID to the WidgetControl.py and used it to match the settings in your post I now have a red light and sound on my 1.1 with 1.2 firmware.
Thanks.
Did you mod your old .py code or pull it from git? An updated but untested .py script is there.
Børge
Børge
I did a git clone and changed that one. There are a few issues with the pull down settings as well but rebuilding is an issue as it requires avr32-gcc and I'm on a 64bit machine.
Support for recoding in new firmwares
Hi everybody,
I have an AB 1.1, and would like to upgrade to the new firmware.
If I understood well the new audio_widget_20121004_AB-1.2.elf is good also for my hardware, right?
Moreover I would also like to add an ADC to my board, it should be simple (I took a look at the schematic).
Can you tell me if the new firmware support also audio recording in UAC2? Is there any setting needed to activate it?
In the past I tried to take a look at the source code, but there are a lot of different versions, and really got lost. I understand that some version have also recording (maybe disabled by default).
My aim is to use the board also for recording in UAC2 under windows.
Any help?
Thank you.
Hi everybody,
I have an AB 1.1, and would like to upgrade to the new firmware.
If I understood well the new audio_widget_20121004_AB-1.2.elf is good also for my hardware, right?
Moreover I would also like to add an ADC to my board, it should be simple (I took a look at the schematic).
Can you tell me if the new firmware support also audio recording in UAC2? Is there any setting needed to activate it?
In the past I tried to take a look at the source code, but there are a lot of different versions, and really got lost. I understand that some version have also recording (maybe disabled by default).
My aim is to use the board also for recording in UAC2 under windows.
Any help?
Thank you.
You should look at the audio-widget-experimental branch of the firmware. Look at the readme file (link in signature) for instuctions on how to download fw from git.
I don't actually have any ADCs connected to my hardware, so I haven't really tested.
Børge
I don't actually have any ADCs connected to my hardware, so I haven't really tested.
Børge
Thank you Borges.
I suppose this is the one: https://github.com/amontefusco/sdr-widget/tree/audio-widget-experimental
Unfortunately I believe that the recording part is disabled (the endpoint used for recording is commented out in the USB descriptor). 😕
Is anybody aware of a firmware version that is sure to be working for recording (so with the proper USB descriptors enabled)?
Should I look at the fiirmware for SDR widget?
Thank you.
I suppose this is the one: https://github.com/amontefusco/sdr-widget/tree/audio-widget-experimental
Unfortunately I believe that the recording part is disabled (the endpoint used for recording is commented out in the USB descriptor). 😕
Is anybody aware of a firmware version that is sure to be working for recording (so with the proper USB descriptors enabled)?
Should I look at the fiirmware for SDR widget?
Thank you.
I've downloaded that file and installed it on my AB1.1 (of course on Linux, using the same setup I have been using previously). Apparently all went well:
Code:
# ./program-widget.sh audio_widget_20121004_AB-1.2.elf
program-widget with audio_widget_20121004_AB-1.2.elf
target: at32uc3a3256
chip_id: 0x2ff1
vendor_id: 0x03eb
command: erase
quiet: false
debug: 6
device_type: AVR32
------ command specific below ------
validate: true
target: at32uc3a3256
chip_id: 0x2ff1
vendor_id: 0x03eb
command: flash
quiet: false
debug: 6
device_type: AVR32
------ command specific below ------
validate: true
hex file: /tmp/audio_widget_20121004_AB-1.2.hex
Validating...
116554 bytes used (45.90%)
target: at32uc3a3256
chip_id: 0x2ff1
vendor_id: 0x03eb
command: reset
quiet: false
debug: 4
device_type: AVR32
------ command specific below ------
Code:
[49158.564032] usb 1-4: new high-speed USB device number 16 using ehci_hcd
[49158.697394] usb 1-4: New USB device found, idVendor=16d0, idProduct=075d
[49158.697399] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[49158.697404] usb 1-4: Product: QNKTC USB DAC AB-1.2
[49158.697407] usb 1-4: Manufacturer: Audio-Widget
[49158.697410] usb 1-4: SerialNumber: 1.0.0.0.0.0.A
[49158.702619] input: Audio-Widget QNKTC USB DAC AB-1.2 as /devices/pci0000:00/0000:00:1a.7/usb1/1-4/1-4:1.3/input/input19
[49158.702803] generic-usb 0003:16D0:075D.0005: input,hidraw2: USB HID v1.11 Device [Audio-Widget QNKTC USB DAC AB-1.2] on usb-0000:00:1a.7-4/input3
Code:
*** /var/log/Xorg.0.log ***
[ 49158.759] (II) config/udev: Adding input device Audio-Widget QNKTC USB DAC AB-1.2 (/dev/input/event17)
[ 49158.759] (**) Audio-Widget QNKTC USB DAC AB-1.2: Applying InputClass "evdev keyboard catchall"
[ 49158.759] (II) Using input driver 'evdev' for 'Audio-Widget QNKTC USB DAC AB-1.2'
[ 49158.759] (**) Audio-Widget QNKTC USB DAC AB-1.2: always reports core events
[ 49158.759] (**) evdev: Audio-Widget QNKTC USB DAC AB-1.2: Device: "/dev/input/event17"
[ 49158.759] (--) evdev: Audio-Widget QNKTC USB DAC AB-1.2: Vendor 0x16d0 Product 0x75d
[ 49158.759] (--) evdev: Audio-Widget QNKTC USB DAC AB-1.2: Found 3 mouse buttons
[ 49158.759] (--) evdev: Audio-Widget QNKTC USB DAC AB-1.2: Found keys
[ 49158.759] (II) evdev: Audio-Widget QNKTC USB DAC AB-1.2: Configuring as mouse
[ 49158.759] (II) evdev: Audio-Widget QNKTC USB DAC AB-1.2: Configuring as keyboard
[ 49158.759] (**) evdev: Audio-Widget QNKTC USB DAC AB-1.2: YAxisMapping: buttons 4 and 5
[ 49158.759] (**) evdev: Audio-Widget QNKTC USB DAC AB-1.2: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
[ 49158.759] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-4/1-4:1.3/input/input19/event17"
[ 49158.759] (II) XINPUT: Adding extended input device "Audio-Widget QNKTC USB DAC AB-1.2" (type: KEYBOARD, id 13)
[ 49158.759] (**) Option "xkb_rules" "evdev"
[ 49158.759] (**) Option "xkb_model" "pc105"
[ 49158.759] (**) Option "xkb_layout" "us"
[ 49158.759] (**) Option "xkb_variant" "altgr-intl"
Code:
# lsusb -s 16
Bus 001 Device 016: ID 16d0:075d GrauTec
Code:
# update-usbids
--2012-10-21 12:24:16-- http://www.linux-usb.org/usb.ids
Resolving www.linux-usb.org (www.linux-usb.org)... 216.34.181.97
Connecting to www.linux-usb.org (www.linux-usb.org)|216.34.181.97|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 486323 (475K) [text/plain]
Saving to: `/var/lib/usbutils/usb.ids.new'
100%[========================================================>] 486,323 33.1K/s in 12s
2012-10-21 12:24:30 (38.3 KB/s) - `/var/lib/usbutils/usb.ids.new' saved [486323/486323]
Done.
Code:
# lsusb -s 16
Bus 001 Device 016: ID 16d0:075d MCSWhatever. Here are lsusb detailed device info:
Code:
# lsusb -v -s 16
Bus 001 Device 016: ID 16d0:075d MCS
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x16d0 MCS
idProduct 0x075d
bcdDevice 10.00
iManufacturer 1 Audio-Widget
iProduct 2 QNKTC USB DAC AB-1.2
iSerial 3 1.0.0.0.0.0.A
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 193
bNumInterfaces 4
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 0 (Defined at Interface level)
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 1
bInterfaceCount 2
bFunctionClass 1 Audio
bFunctionSubClass 0
bFunctionProtocol 32
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 1 Control Device
bInterfaceProtocol 32
iInterface 7 SDR-Widget
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 2.00
bCategory 4
wTotalLength 64
bmControl 0x00
AudioControl Interface Descriptor:
bLength 8
bDescriptorType 36
bDescriptorSubtype 10 (CLOCK_SOURCE)
bClockID 5
bmAttributes 0x01 Internal fixed Clock
bmControls 0x07
Clock Frequency Control (read/write)
Clock Validity Control (read-only)
bAssocTerminal 3
iClockSource 5 Clock 2
AudioControl Interface Descriptor:
bLength 17
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 17
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bCSourceID 5
bNrChannels 2
bmChannelConfig 0x00000003
Front Left (FL)
Front Right (FR)
bmControls 0x0000
iChannelNames 0
iTerminal 8 Audio-widget
AudioControl Interface Descriptor:
bLength 18
bDescriptorType 36
bDescriptorSubtype 6 (FEATURE_UNIT)
bUnitID 18
bSourceID 17
bmaControls( 0) 0x00000003
Mute Control (read/write)
bmaControls( 1) 0x00000003
Mute Control (read/write)
bmaControls( 2) 0x00000003
Mute Control (read/write)
iFeature 0
AudioControl Interface Descriptor:
bLength 12
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 19
wTerminalType 0x0302 Headphones
bAssocTerminal 0
bSourceID 18
bCSourceID 5
bmControls 0x0000
iTerminal 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 0
AudioStreaming Interface Descriptor:
bLength 16
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 17
bmControls 0x07
Active Alternate Setting Control (read/write)
Valid Alternate Setting Control (read-only)
bFormatType 1
bmFormats 1
PCM
bNrChannels 2
bmChannelConfig 0x00000003
Front Left (FL)
Front Right (FR)
iChannelNames 0
AudioStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bSubslotSize 4
bBitResolution 24
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0188 1x 392 bytes
bInterval 2
AudioControl Endpoint Descriptor:
bLength 8
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x00
bmControls 0x00
bLockDelayUnits 0 Undefined
wLockDelay 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 17
Transfer Type Isochronous
Synch Type None
Usage Type Feedback
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 4
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 67
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 5
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered
Code:
card 2: AB12 [QNKTC USB DAC AB-1.2], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0Mine is in fact AB1.1, and AFAIU the same firmware may be also used on many other different AW-based devices, too. You may/should perhaps include firmware version instead. IMHO that may be much more useful than (possibly inappropriate / misleading) specific hardware version.
No recognized changes in board controls (none expected):
Code:
$ amixer -c 2
Simple mixer control 'Clock 2',0
Capabilities: pswitch penum
Playback channels: Front Left - Front Right
Mono:
Front Left: Playback [on]
Front Right: Playback [on]
Simple mixer control 'Clock 2',1
Capabilities: pswitch pswitch-joined penum
Playback channels: Mono
Mono: Playback [on]From a very quick listening test it appears that there may be some subtle SQ differences -mostly about imaging- WRT audio-widget-20120428.elf, but that may be just suggestion...
BTW: I have also downloaded your windows package "audio_widget_20121004.zip". Inside there are a bunch of ELF files, among which "widget_9023.elf". I have AB1.1 with 9023, should have I used that one instead?
P.S.: those ELF files appears to be slightly smaller than "audio-widget-20120428.elf", but all of them are much larger than the -nik firmwares I have previously used:
Code:
166K Dec 27 2011 audio-widget-nik-2011-12-26.elf
166K Dec 28 2011 audio-widget-nik-2011-12-28e.elf
166K Dec 29 2011 audio-widget-nik-2011-12-29.elf
405K Apr 28 14:29 audio-widget-20120428.elf
359K Oct 21 11:54 audio_widget_20121004_AB-1.2.elf
359K Oct 4 21:23 widget_5102.elf
359K Oct 4 21:20 widget_8741.elf
359K Oct 4 21:24 widget_9023.elf
359K Oct 4 21:29 widget_ab12.elf
359K Oct 4 21:34 widget-sdr.elfwhat about Linux? you've become way too much windows-centric, lately... 🙁
The sdr-widget hardware has recording And playback. The sdr-widget firmware is in the master branch and the elf files are called sdr-widget......elf.
The audio-widgets are playback only and the firmware is in the audio-widget-experimental branch. The elf files are Audio-Widget.......elf.
The Widget control.py in the master branch is for sdr-widget. For Audio-Widget use the Audio-Widget.... branches.
Alex
The sdr-widget hardware has recording And playback. The sdr-widget firmware is in the master branch and the elf files are called sdr-widget......elf.
The audio-widgets are playback only and the firmware is in the audio-widget-experimental branch. The elf files are Audio-Widget.......elf.
The Widget control.py in the master branch is for sdr-widget. For Audio-Widget use the Audio-Widget.... branches.
Alex
Alex, Borge:
Does the Audio widget USB module have the hooks brought out for a capture/recording function? It would need an external ADC and probably some glue logic regardless. . .
Does the Audio widget USB module have the hooks brought out for a capture/recording function? It would need an external ADC and probably some glue logic regardless. . .
The sdr-widget hardware has recording And playback. The sdr-widget firmware is in the master branch and the elf files are called sdr-widget......elf.
The audio-widgets are playback only and the firmware is in the audio-widget-experimental branch. The elf files are Audio-Widget.......elf.
The Widget control.py in the master branch is for sdr-widget. For Audio-Widget use the Audio-Widget.... branches.
Alex
TDA1543 works
I tested the audio-widget (sdr-widget) with a TDA1543 DAC and it works. Although this chip was run at 5V, the Atmel 3.3V logic levels were enough to drive it. The shift registers ignore the rest of the 32 bits after the first high-order 16 bits are loaded. Sound was pleasant NOS. There was some digital harshness, probably due to my poor wiring. The DAC would run up to 96 kHz but not 192 kHz. The bitrate at 192kHz 32 bit is 12.288MHz which exceeds the rated 9MHz of the TDA1543. A true 16 bit endpoint would halve the bitrate and then it might work at 192kHz.
Still, the builtin ESS9023 sounds better and smoother to me. Just want to encourage everyone to try these old chips with the great analog-widget.
Bob
I tested the audio-widget (sdr-widget) with a TDA1543 DAC and it works. Although this chip was run at 5V, the Atmel 3.3V logic levels were enough to drive it. The shift registers ignore the rest of the 32 bits after the first high-order 16 bits are loaded. Sound was pleasant NOS. There was some digital harshness, probably due to my poor wiring. The DAC would run up to 96 kHz but not 192 kHz. The bitrate at 192kHz 32 bit is 12.288MHz which exceeds the rated 9MHz of the TDA1543. A true 16 bit endpoint would halve the bitrate and then it might work at 192kHz.
Still, the builtin ESS9023 sounds better and smoother to me. Just want to encourage everyone to try these old chips with the great analog-widget.
Bob
Attachments
UnixMan,
first the USB names. The USB VID is still generic. We have purchased PIDs for the project. George's PIDs have different USB name strings from mine. Look at the audio-widget-experimental branch, starting with Makefile, to see how the name strings enter the scene. Because of the VID situation I made the product name contain as much as possible. And for the AB-1.1s out there I did not bother to set up a separate PID and naming convention. I did set up names for George's PIDs but I leave it to him to distribute .elfs with the strings set differently.
The HID part is so that a user interface on a DAC box can instruct the computer to skip to the next song! My plan is to use the AVR32's SPI slave or GPIO to receive HID codes which it the relays to the Host.
Børge
first the USB names. The USB VID is still generic. We have purchased PIDs for the project. George's PIDs have different USB name strings from mine. Look at the audio-widget-experimental branch, starting with Makefile, to see how the name strings enter the scene. Because of the VID situation I made the product name contain as much as possible. And for the AB-1.1s out there I did not bother to set up a separate PID and naming convention. I did set up names for George's PIDs but I leave it to him to distribute .elfs with the strings set differently.
The HID part is so that a user interface on a DAC box can instruct the computer to skip to the next song! My plan is to use the AVR32's SPI slave or GPIO to receive HID codes which it the relays to the Host.
Børge
Thank you all for your suggestions.
I've been looking at the sources, and I'm now quite familiar with them, also tried some personal modifications.
In general in the "audio widget" branches there are a lot of source code that is partially commented out about recording, but not completely, so, for instance, the endpoint for recording is still present (and sent to the pc during the discovery phase). This at least in some of the sources that I've tried.
Now I've been trying to reconstruct a source with recording enabled. From the usb discovery the version I have is OK, but there is something missing or wrong .. no recording indeed (no error, but nothing comes back to the PC).
That's why I was looking for a version that was sure to be recording well, just to have a reference and understand what's wrong in my modifications.
My main problem (I'm trying in UAC2 under windows with a hacked driver) is that the endpoints for recording and play feedback seem overlapped. The descriptors are OK (I dumped them on the PC and checked several times, they look OK), but while playback is ok the recording simply don't work completely. I can start a recording (with audacity, as an example, using MME), and the software don't returns an error, but seems stuck waiting for data. With directsound it looks like recording, but I get all zeroes (and I believe that nothing actually comes from the board, it's simply a timeout).
Maybe it's the order of descriptors, maybe some subtle change somewhere in the sources ... Anybody has an idea regarding the initialization of endpoints, or a suggestion on what could cause the overlap of 0x81 and 0x83 endpoints?
I've been looking at the sources, and I'm now quite familiar with them, also tried some personal modifications.
In general in the "audio widget" branches there are a lot of source code that is partially commented out about recording, but not completely, so, for instance, the endpoint for recording is still present (and sent to the pc during the discovery phase). This at least in some of the sources that I've tried.
Now I've been trying to reconstruct a source with recording enabled. From the usb discovery the version I have is OK, but there is something missing or wrong .. no recording indeed (no error, but nothing comes back to the PC).
That's why I was looking for a version that was sure to be recording well, just to have a reference and understand what's wrong in my modifications.
My main problem (I'm trying in UAC2 under windows with a hacked driver) is that the endpoints for recording and play feedback seem overlapped. The descriptors are OK (I dumped them on the PC and checked several times, they look OK), but while playback is ok the recording simply don't work completely. I can start a recording (with audacity, as an example, using MME), and the software don't returns an error, but seems stuck waiting for data. With directsound it looks like recording, but I get all zeroes (and I believe that nothing actually comes from the board, it's simply a timeout).
Maybe it's the order of descriptors, maybe some subtle change somewhere in the sources ... Anybody has an idea regarding the initialization of endpoints, or a suggestion on what could cause the overlap of 0x81 and 0x83 endpoints?
Last edited: