New binaries - please test

[Børge Strand-Bergesen]

Hi guys, 

I have uploaded new binaries to

https://github.com/borgestrand/widget_binaries/blob/master/README.md

Please download, test and report any issues.

The new binaries work with the UAC2 driver in Windows 10 Creators Update. I have tested them on a lot of other OSes. 

In addition to new Windows support, the new binaries also have improved DMA init code to prevent L/R channel swapping.

Known issues:

- No 192 support in PC ASIO driver due to rate triplet incompatibility in Win10

- L and R volume control seems to be swapped in MacOS

- Android and Linux manipulate volume control in Host, not in Device

It is likely that I will touch up the ASIO driver to get 192 support back in. I have found the piece of code which must be updated. In the meantime I have reported the triplet incompatibility as a bug to Microsoft. If resolved by them, the need for these new binaries will be less urgent.

Børge

[Ti Kan]

I don't have windows 10, but I can do some testing on Windows 7 and Linux.  Will it still work with the Win-Widget asio driver on Win7?

-Ti
-- 

Sent from my commlock

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.
To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Børge Strand-Bergesen]

Hi Ti, 

please do! 

The ASIO driver only retrieves 5 sample rate triplets, and Win10 needs 6. Which means the ASIO driver in its current form doesn't see the 192ksps capability. This is easy to fix in the ASIO driver, but I was hoping to avoid that. 

I have reported the failing interpretation of rate triplets to Microsoft, and with a bit of luck a version of Windows comes out soon with this fixed. Then I will make small changes to the firmware and have it supported by all OSes and drivers. 

I'll keep you posted. For now please test what I have published. There are many changes which don't relate to the sample rates. 

Børge

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

[Børge Strand-Bergesen]

Update! Attached firmware supports all 6 rates on Win10 build 16232 and the ASIO driver. 

I'd appreciate you help testing this on Linux, particularly when it comes to volume control.

But all testing is good testing! This firmware generation holds a lot of updates. Code has been pushed to github.

I just found out that rate triplet interpretation was buggy in the Win10 version I was testing on all along. Windows 10 build 16232 understands a rate configuration setup which is short enough to be interpreted by the ASIO driver as well. 

Now, the intention of the production firmware still isn't 100% correctly interpreted by Win10. That is because the two frequency rate triplets overlap. Plug in a DAC with production firmware, and Win10 lets you choose from 44.1, 88.2 and 176.4 only. MS might still fix that, but my money is on having to update DAC firmware for all rates to work. AND: users need to be able to update to a Win10 build which has their latets drivers. But the good news is that the ASIO driver can be left as-is. 

The only remaining issue now is that the built-in volume control doesn't work on Linux. Both Linux and Android will perform volume control in the Host, all the time in UAC2 and sometimes in UAC1. This is something I can't understand. 

Mac OS and iOS have the best implementation of Device-side volume control. It works as you'd expect.

Win10 will display the volume control to the user regardless. If the Device supports it, volume is handled there. If not, volume is handled in the Host. Thus, new firmware shipped by me will probably have volume control enabled. 

For the curious: Building without volume control actually removes the Feature Unit from the USB descriptors, and volume control Request handling from the firmware. 

Børge

[Paolo 'UnixMan' Saggese]

Hi Børge,

Il giorno martedì 18 luglio 2017 11:24:52 UTC+2, Børge Strand-Bergesen ha scritto:

Update! Attached firmware supports all 6 rates on Win10 build 16232 and the ASIO driver. 

I'd appreciate you help testing this on Linux, particularly when it comes to volume control.flashed firmware file "awx_20170718_no_debug_volume.elf" on my good old AW AB-1.1 (the one with the "little-Sabre" ES9023 DAC):

# ./program-widget.sh awx_20170718_no_debug_volume.elf
program-widget with awx_20170718_no_debug_volume.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/awx_20170718_no_debug_volume.hex

Validating...
82030 bytes used (32.30%)
     target: at32uc3a3256
    chip_id: 0x2ff1
  vendor_id: 0x03eb
    command: reset
      quiet: false
      debug: 4
device_type: AVR32
------ command specific below ------


Tested on Linux (Debian 9.0 "Stretch", with KDE). Seems to be working fine.

In UAC1 mode ALSA reports support for 44.1K & 48K only: is that normal? (shouldn't UAC1 be able to support up to 96K, as other UAC1 DACs do?)

Kernel msgs while switching between UAC1->UAC2:

 kernel: usb 1-2: new full-speed USB device number 21 using uhci_hcd
 kernel: usb 1-2: New USB device found, idVendor=16d0, idProduct=075c
 kernel: usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
 kernel: usb 1-2: Product: Henry Audio USB DAC 128 mkII
 kernel: usb 1-2: Manufacturer: Audio-Widget
 kernel: usb 1-2: SerialNumber: 2017071600BSB
 kernel: input: Audio-Widget Henry Audio USB DAC 128 mkII as /devices/pci0000:00/0000:00:1a.0/usb1/1-2/1-2:1.1/0003:16D0:075C.0013/input/input32
 kernel: hid-generic 0003:16D0:075C.0013: input,hidraw3: USB HID v1.11 Device [Audio-Widget Henry Audio USB DAC 128 mkII] on usb-0000:00:1a.0-2/input1

 kernel: usb 1-2: USB disconnect, device number 21
 acpid[521]: input device has been disconnected, fd 18

 kernel: usb 7-2: new high-speed USB device number 25 using ehci-pci
 kernel: usb 7-2: New USB device found, idVendor=16d0, idProduct=075d
 kernel: usb 7-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
 kernel: usb 7-2: Product: Henry Audio USB DAC 128 mkII
 kernel: usb 7-2: Manufacturer: Audio-Widget
 kernel: usb 7-2: SerialNumber: 2017071600BSB
 kernel: input: Audio-Widget Henry Audio USB DAC 128 mkII as /devices/pci0000:00/0000:00:1a.7/usb7/7-2/7-2:1.3/0003:16D0:075D.0014/input/input33
 kernel: hid-generic 0003:16D0:075D.0014: input,hidraw3: USB HID v1.11 Device [Audio-Widget Henry Audio USB DAC 128 mkII] on usb-0000:00:1a.7-2/input3


In UAC2 mode, "lsusb" shows this:

Bus 007 Device 025: ID 16d0:075d MCS AB-1.x UAC2 [Audio Widget]

Results from "alsacap"; UAC1:

Card 1, ID `mkII', name `Henry Audio USB DAC 128 mkII'
  Device 0, ID `USB Audio', name `USB Audio', 1 subdevices (1 available)
    2 channels, sampling rate 44100..48000 Hz
    Sample formats: S24_3LE
      Subdevice 0, name `subdevice #0'

Results from "alsacap"; UAC2:

Card 1, ID `mkII', name `Henry Audio USB DAC 128 mkII'
  Device 0, ID `USB Audio', name `USB Audio', 1 subdevices (1 available)
    2 channels, sampling rate 44100..192000 Hz
    Sample formats: S32_LE
      Subdevice 0, name `subdevice #0'


BTW: "mkII" it's not so nice as the card name... maybe something like "AWG" or "HAAWG" would be better.


Volume control (see attached pictures):

in UAC2 mode from alsamixer it does not work: fader is shown, but value can not be changed (and "Mute" does not work, either).

Oddly enough, in a previous test (before switching back and forth from UAC1 mode) the fader appeared as seto to 100%, and it was possible to change its settings... But! As soon as I touched it, sound output disappared and it took a reset (of the AW) to get it back. Tried another couple of time, but haven't been able to reproduce that situation (now it seems to always show up as in the above picture).

in UAC1 mode it works fine: changes done from alsamixer are sinchronized with other tools (KDE pulseaudio Vol. control). Don't know if volume control is done by ALSA or by the widget, though.

 
That's all... let me know if you need more.

[Børge Strand-Bergesen]

Hi Paolo, 

Thank you for testing! 

What you see overlap with my experience for quite some years: Linux is reasonably good at handling volume control in the Device on UAC1, but fails to do so on UAC2. 

I don't have the skill set to start chasing this bug inside Linux. But what I have seen is that Linux never attempts any USB requests relating to UAC2 volume control. 

The descriptors should be sound. I have gone over them in fine detail over the last few weeks. The firmware works perfectly with Mac OS and iOS. On Windows there are a few issues probably connected to descriptor storage. 

Børge