Most important for slave but could happen with master (EMI)

In the case where USB rate is 16k and audio rate 48k (AUD_TO_USB_RATIO=3), userBufferManagement is called at too slow a rate (16k instead of 48k).

The issue is the call to DoSampleTransfer https://github.com/xmos/lib_xua/blob/master/lib_xua/src/core/audiohub/xua_audiohub.xc#L792
is guarded by audioToUsbRatioCounter. However UserBufferManagement is called in DoSampleTransfer so will be called at the USB rate, not the audio rate for the hybrid config.

This should be able to fixed by putting the ((AUD_TO_USB_RATIO - 1) == audioToUsbRatioCounter) check in DoSampleTransfer around the communication with decouple() and leaving userBufferManagement to be called at the audio rate.

We've had FAE/customer reports from various Linux hosts seemingly failing to do adaptive sink when the feedback is implicit

Microsoft's own class 2 driver apparently doesn't support implicit feedback at all

It might make more sense for explicit to be the default, and you turn implicit on if you can be sure it will work

See comments in descriptors header

They work OK on MACOS..

Stereo UAC1 output OK on W10 v. 1709

Results in device which does not stream properly.

Not sure if this is a recent change but don't remember this behaviour in sc_usb_audio. With master clock absent, decouple crashes in upstream overflow, the "keep throwing away packets" loop.

            GET_SHARED_GLOBAL(rdPtr, g_aud_to_host_rdptr);
            asm volatile("ldw %0, %1[0]":"=r"(datalength):"r"(rdPtr));

I noticed that g_speed gets set to zero. Is this correct or could be the cause of the crash?

A very long time was spent chasing down audio issues on new hardware that in the end was nothing to do with the new hardware. The application specified 8 channels at 48kHz/24bit and audio class 1.0. This exceeds 1,023 bytes per packet, but there is no clear indication of that.

A check in USB buffer or decouple with a runtime assertion would greatly help catch this early. Suggest leaving it disabled by default, similar to an existing one in xmos/lib_mic_array.

The use of p_mclk_in seems to rely on undefined behaviour in the compiler. There is a report of a failing application build using 14.3.3 tools release candidate.

Return values of many libusb calls are ignored. Some are saved in variables and passed on but not handled.

See:

http://bugzilla/show_bug.cgi?id=18292

Currently using sc_i2c

It seems that 200 words are allocated but the interrupt handler only needs a handful (it's a leaf function that compiles with stack use of 10 words)

The memory saving of 0.5KB or so is minor but make a difference in constrained applications such as XVF3510

To avoid clashes with other libs

The UAC1 USB Terminal descriptor for the Device to Host USB Streaming terminal, defined in xua_ep0_descriptors.h, sets the Terminal Type field (wTerminalType) to 0x0101 and the Associated Terminal (bAssocTerminal) field to 1.

That combination violates the USB Device Class Definition for Audio Devices (Release 2.0, 31 May 2006) which states that, 'The bAssocTerminal field is used to associate an Input Terminal to this Output Terminal, effectively implementing a bi-directional Terminal pair. If no association exists, the bAssocTerminal field must be set to zero.'

Bi-directional terminals have Terminal Type values between 0x0400 and 0x0405 (see the USB Device Class Definition for Terminal Types, Release 2.0, 31 May 2006).

I have not observed this issue having a detrimental effect when enumerating a UAC1 device connected to either MacOS or Windows.

It is always set to 0 in the code, it is probably a legacy flag which is not needed anymore.

Suggest something like WINDOWS_CONTROL_DESCRIPTOR

sw_vocalfusion will then need updating

Some flags are set by defining them e.g. -DUAC_FORCE_FEEDBACK_EP
whereas others are set to either 0 or 1 e.g. -DXUA_USB_EN=0

This can be confusing at the app level e.g. -DUAC_FORCE_FEEDBACK_EP=0 counter-intuitively enables the feedback endpoint.

The Confluence page How to build the 3510 firmware on WSL includes an instruction to install pipenv, pipenv install --python ~/.pyenv/versions/3.7.4/bin/python. On my machine, this step produces an error with a long message ending with, pipenv.patched.notpip._internal.exceptions.InstallationError: Command "python setup.py egg_info" failed with error code 1 in /tmp/tmpw99ccpwwbuild/functools32/.

Missing tests for input and output only configs

Issue with OUT stream, IN seems okay.

First time before entering usb_audio_io. Second time before entering pdm_mic. Are set to the same thing, p_mclk_in_, so no harm. But could cause confusion.

Currently using version 2, which has created a warning in VocalFusion build

In xmosdfu.cpp the pidList doesn't include the stereo product ID's.

XMOS_VID could be substituted with VENDOR_ID defined in xua_conf_default.h.

Ports, clocks etc

Historical - code written before pointer support in XC - currently uses inline ASM

in main.xc. Potential for clash.

Some files like endpoint0.c have been renamed, so some lines like this are wrong:

XCC_FLAGS_endpoint0.c = -Os -mno-dual-issue $(XCC_FLAGS)

Instead of devicedefines.h

In PR #111, @chrisc-xmos pointed out that the read of s_hidChangePending in UserHIDGetData() should be placed in an unsafe scope since the variable is shared between threads.

The top-level Class 2 Configuration descriptor in xua_ep0_descriptors.h sets the number of interfaces (bNumInterfaces) to INTERFACE_COUNT. INTERFACE_COUNT, defined in descriptor_defs.h, includes the vendor-specific interface (INTERFACE_NUMBER_MISC_CONTROL) used to provide run-time parameter control over USB. However the set of Class 2 descriptors in xua_ep0_descriptors.h does not include a descriptor for this interface, resulting in a mismatch between the number of interfaces claimed and the number of interface descriptors provided.

This mismatch prevents the Windows-native USB driver from successfully enumerating xvf3500 (and likely other products that use lib_xua and include the control interface) when operated as USB Audio Class 2.

From initial inspection

Frame sync test appears to fail - hitting the main while(1) loop.
However, due to the firstIteration flag it doesn't resync - drops right though and the loopback test continues to pass

Whereas it is reset during sample rate changes..
SET_SHARED_GLOBAL(g_aud_from_host_rdptr, aud_from_host_fifo_start);
SET_SHARED_GLOBAL(g_aud_from_host_wrptr, aud_from_host_fifo_start);
SET_SHARED_GLOBAL(aud_data_remaining_to_device, 0);

User reporting out of bounds issue at high rates and found issue solved by applying this initialisation to the STREAM FORMAT change:

http://www.xcore.com/viewtopic.php?f=37&t=6417&p=32067#p32067

in 2 channel SPDIF only build config: sw_usb_audio/app_usb_aud_xk_216_mc

Large (invalid) IN audio packets to be set to host.

Effects app_usb_aud_xk_216_mc (1i2o2xxxxxx tested)

Doesn't seem to effect XVF (1i1o2_cir43 tested) - could be port map related?

Caution - bug crashes core audio on OSX

Required to be two cores for old XUD API - now can be merged.

Attached example from customer RT case 32296

Required change from libusb_ to usb_ function names, and related API updates

Furthermore, timeout value of 0 sets default, which has proven insufficient for the flash erase on first download operation. So use a specific large value.

xmosdfu_win.cpp.zip

i.e. pass PID as command line arg

Example of what would be a nice test to have in xmos/lib_xua for the 'syncError' based checking is on larry-xmos/sc_usb_audio branch tdm_slave_sync_test

If not you get this in decouple:

Program received signal ET_LOAD_STORE, Memory access exception.
[Switching to tile[1] core[1]]
SetupZerosSendBuffer (sampFreq=, aud_to_host_usb_ep=0, slotSize=2)
at /Users/Ed/apps/views/stereo_vocalfusion/lib_xua/lib_xua/src/core/buffer/decouple/decouple.xc:612
612 XUD_SetReady_InPtr(aud_to_host_usb_ep, p+4, mid);

Looks like guards around setting up input endpoint in UAC1 needed

Unless defined in a Make file, the definition of NUM_USB_CHAN_IN and NUM_USB_CHAN_OUT occur in either xua_conf.h or xua_conf_default.h. These symbols appear in descriptor_defs.h and govern the values assigned to constants in the USBInterfaceNumber enum. The constants receive incorrect values if two conditions hold:

1. The symbols are not defined in the Make file; and
2. A #include "xua.h" does not preceed the #include "descriptor_defs.h" in a translation unit.

Adding a #include "xua.h" before referencing NUM_USB_CHAN_IN or NUM_USB_CHAN_OUT in descriptor_defs.h solves the problem.

Often it takes longer than 5 seconds to erase flash on the first DFU download request

DFU specification isn't concerned with erasing the storage medium, but USB specification mandates any request completes within 5 sec

Multiple customer support cases have pointed to the need for splitting up the erase operation. Eg one sector at a time across multiple download requests.

Doing this would move the code one step closer towards 'DFU compliance' as described by Thesycon

This repo has a copy of libusb. Our tools ship with a different version of libusb. We need to separate the libusb dependancy from the repo and either have another repo or simply use the tools copy

Getting weird lr_clck waveforms - framecount reset should be outside of the ratio loop check.

Also a comment is out of date with recent code changes:

 /* Increase frameCount by 2 since we have output two channels (per data line) */
             frameCount+=1;