dengweijie/lib_xua
1
0
Fork 0
forked from PAWPAW-Mirror/lib_xua
Code Pull Requests Activity

Documentation

Browse Source 
Documentation updates and version bump
This commit is contained in:
Ross Owen
2022-10-26 17:48:51 +01:00
committed by GitHub
parent 2183dd1b53
commit a1082b1dfd
48 changed files with 156 additions and 161 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
CHANGELOG.rst
View File

@@ -1,6 +1,15 @@
lib_xua Change Log
==================
3.3.1
-----
* CHANGED: Documentation updates
* Changes to dependencies:
- lib_spdif: 4.1.0 -> 4.2.1
3.3.0
-----

4
Jenkinsfile vendored
View File

@@ -1,4 +1,4 @@
@Library('xmos_jenkins_shared_library@v0.18.0') _
@Library('xmos_jenkins_shared_library@v0.21.0') _
getApproval()
@@ -24,7 +24,7 @@ pipeline {
}
stage('Library checks') {
steps {
xcoreLibraryChecks("${REPO}")
xcoreLibraryChecks("${REPO}", false)
}
}
stage('Testing') {

42
README.rst
View File

@@ -1,5 +1,5 @@
lib_xua
=======
#######
:Latest release: 3.3.0
@@ -7,14 +7,14 @@ lib_xua
:Scope: General Use
Summary
-------
*******
lib_xua contains shared components for use in the XMOS USB Audio (XUA) Reference Designs.
These components enable the development of USB Audio devices on the XMOS xCORE architecture.
Features
~~~~~~~~
========
Key features of the various components in this repository are as follows
@@ -56,7 +56,7 @@ Note, not all features may be supported at all sample frequencies, simultaneousl
Some features may also require specific host driver support.
Host System Requirements
~~~~~~~~~~~~~~~~~~~~~~~~
========================
USB Audio devices built using `lib_xua` have the following host system requirements.
@@ -69,27 +69,27 @@ USB Audio devices built using `lib_xua` have the following host system requireme
Older versions of Windows are not guaranteed to operate as expected. Devices are also expected to operate with various Linux distributions including mobile variants.
Related Application Notes
~~~~~~~~~~~~~~~~~~~~~~~~~
=========================
The following application notes use this library:
* AN000246 - Simple USB Audio Device using lib_xua
* AN000247 - Using lib_xua with lib_spdif (transmit)
* AN000248 - Using lib_xua with lib_mic_array
* AN000246 - Simple USB Audio Device using lib_xua
* AN000247 - Using lib_xua with lib_spdif (transmit)
* AN000248 - Using lib_xua with lib_mic_array
Required software (dependencies)
Required Software (dependencies)
================================
* lib_locks (git@github.com:xmos/lib_locks.git)
* lib_logging (git@github.com:xmos/lib_logging.git)
* lib_mic_array (git@github.com:xmos/lib_mic_array.git)
* lib_xassert (git@github.com:xmos/lib_xassert.git)
* lib_dsp (git@github.com:xmos/lib_dsp)
* lib_i2c (git@github.com:xmos/lib_i2c.git)
* lib_i2s (git@github.com:xmos/lib_i2s.git)
* lib_gpio (git@github.com:xmos/lib_gpio.git)
* lib_mic_array_board_support (git@github.com:xmos/lib_mic_array_board_support.git)
* lib_spdif (git@github.com:xmos/lib_spdif.git)
* lib_xud (git@github.com:xmos/lib_xud.git)
* lib_adat (git@github.com:xmos/lib_adat)
* lib_locks (www.github.com/xmos/lib_locks)
* lib_logging (www.github.com/xmos/lib_logging)
* lib_mic_array (www.github.com/xmos/lib_mic_array)
* lib_xassert (www.github.com/xmos/lib_xassert)
* lib_dsp (www.github.com/xmos/lib_dsp)
* lib_i2c (www.github.com/xmos/lib_i2c)
* lib_i2s (www.github.com/xmos/lib_i2s)
* lib_gpio (www.github.com/xmos/lib_gpio)
* lib_mic_array_board_support (www.github.com/xmos/lib_mic_array_board_support)
* lib_spdif (www.github.com/xmos/lib_spdif)
* lib_xud (www.github.com/xmos/lib_xud)
* lib_adat (www.github.com/xmos/lib_adat)

3
lib_xua/doc/rst/api.rst
View File

@@ -1,9 +1,8 @@
.. _sec_api:
API Reference
-------------
*************
.. toctree::

2
lib_xua/doc/rst/api_component.rst
View File

@@ -1,7 +1,7 @@
.. _sec_api_component:
Component API
-------------
=============
The following functions can be called from the top level main of an
application and implement the various components described in

48
lib_xua/doc/rst/api_defines.rst
View File

@@ -2,7 +2,7 @@
.. _sec_api_defines:
Configuration Defines
---------------------
=====================
An application using the USB audio framework needs to have defines set for configuration.
Defaults for these defines are found in ``xua_conf_default.h``.
@@ -13,7 +13,7 @@ for a relevant build configuration.
This section fully documents all of the settable defines and their default values (where appropriate).
Code Location (tile)
~~~~~~~~~~~~~~~~~~~~
--------------------
.. doxygendefine:: AUDIO_IO_TILE
.. doxygendefine:: XUD_TILE
@@ -23,7 +23,7 @@ Code Location (tile)
.. doxygendefine:: PLL_REF_TILE
Channel Counts
~~~~~~~~~~~~~~
--------------
.. doxygendefine:: NUM_USB_CHAN_OUT
.. doxygendefine:: NUM_USB_CHAN_IN
@@ -31,7 +31,7 @@ Channel Counts
.. doxygendefine:: I2S_CHANS_ADC
Frequencies and Clocks
~~~~~~~~~~~~~~~~~~~~~~
----------------------
.. doxygendefine:: MAX_FREQ
.. doxygendefine:: MIN_FREQ
@@ -40,24 +40,24 @@ Frequencies and Clocks
.. doxygendefine:: MCLK_48
Audio Class
~~~~~~~~~~~
-----------
.. doxygendefine:: AUDIO_CLASS
.. doxygendefine:: AUDIO_CLASS_FALLBACK
.. doxygendefine:: FULL_SPEED_AUDIO_2
System Feature Configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Feature Configuration
---------------------
MIDI
....
^^^^
.. doxygendefine:: MIDI
.. doxygendefine:: MIDI_RX_PORT_WIDTH
S/PDIF
......
^^^^^^
.. doxygendefine:: XUA_SPDIF_TX_EN
.. doxygendefine:: SPDIF_TX_INDEX
@@ -65,37 +65,37 @@ S/PDIF
.. doxygendefine:: SPDIF_RX_INDEX
ADAT
....
^^^^
.. doxygendefine:: XUA_ADAT_RX_EN
.. doxygendefine:: ADAT_RX_INDEX
PDM Microphones
...............
^^^^^^^^^^^^^^^
.. doxygendefine:: XUA_NUM_PDM_MICS
DFU
...
^^^
.. doxygendefine:: XUA_DFU_EN
.. .. doxygendefine:: DFU_FLASH_DEVICE
HID
...
^^^
.. doxygendefine:: HID_CONTROLS
CODEC Interface
...............
^^^^^^^^^^^^^^^
.. doxygendefine:: CODEC_MASTER
USB Device Configuration
~~~~~~~~~~~~~~~~~~~~~~~~
------------------------
.. doxygendefine:: VENDOR_STR
.. doxygendefine:: VENDOR_ID
@@ -108,10 +108,10 @@ USB Device Configuration
Stream Formats
~~~~~~~~~~~~~~
--------------
Output/Playback
...............
^^^^^^^^^^^^^^^
.. doxygendefine:: OUTPUT_FORMAT_COUNT
@@ -132,7 +132,8 @@ Output/Playback
.. doxygendefine:: STREAM_FORMAT_OUTPUT_3_DATAFORMAT
Input/Recording
...............
^^^^^^^^^^^^^^^
.. doxygendefine:: INPUT_FORMAT_COUNT
.. doxygendefine:: STREAM_FORMAT_INPUT_1_RESOLUTION_BITS
@@ -144,7 +145,7 @@ Input/Recording
.. doxygendefine:: STREAM_FORMAT_INPUT_1_DATAFORMAT
Volume Control
~~~~~~~~~~~~~~
--------------
.. doxygendefine:: OUTPUT_VOLUME_CONTROL
.. doxygendefine:: INPUT_VOLUME_CONTROL
@@ -152,8 +153,8 @@ Volume Control
.. doxygendefine:: MAX_VOLUME
.. doxygendefine:: VOLUME_RES
Mixing Parameters
~~~~~~~~~~~~~~~~~
Mixing
------
.. doxygendefine:: MIXER
.. doxygendefine:: MAX_MIX_COUNT
@@ -163,8 +164,7 @@ Mixing Parameters
.. doxygendefine:: VOLUME_RES_MIXER
Power
~~~~~
-----
.. doxygendefine:: SELF_POWERED
.. doxygendefine:: BMAX_POWER
.. doxygendefine:: XUA_POWERMODE

11
lib_xua/doc/rst/api_user_functions.rst
View File

@@ -1,10 +1,10 @@
Required User Function Definitions
----------------------------------
==================================
The following functions need to be defined by an application using the XMOS USB Audio framework.
External Audio Hardware Configuration Functions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----------------------------------------------
.. c:function:: void AudioHwInit(chanend ?c_codec)
@@ -38,7 +38,7 @@ External Audio Hardware Configuration Functions
Audio Streaming Functions
~~~~~~~~~~~~~~~~~~~~~~~~~
-------------------------
The following functions can be optionally used by the design. They can be useful for mute lines etc.
@@ -52,7 +52,7 @@ The following functions can be optionally used by the design. They can be useful
This function is called when the audio stream from device to host stops.
Host Active
~~~~~~~~~~~
-----------
The following function can be used to signal that the device is connected to a valid host.
@@ -64,10 +64,11 @@ This is called on a change in state.
HID Controls
~~~~~~~~~~~~
------------
The following function is called when the device wishes to read physical user input (buttons etc).
.. c:function:: void UserReadHIDButtons(unsigned char hidData[])
:param hidData: The function should write relevant HID bits into this array. The bit ordering and functionality is defined by the HID report descriptor used.

2
lib_xua/doc/rst/arch.rst
View File

@@ -2,7 +2,7 @@
.. _usb_audio_sec_architecture:
Software Architecture
---------------------
*********************
This section describes the required software architecture of a USB Audio device implemented using `lib_xua`, its dependencies and other supporting libraries.

6
lib_xua/doc/rst/feat.rst
View File

@@ -1,8 +1,8 @@
Features & Options
------------------
Additional Features
*******************
The previous section describes the use of core functionality contained within ``lib_xua``
The previous chapter describes the use of core functionality contained within ``lib_xua``
This seciton details enabling additional features with supported external dependencies, for example,
``lib_xua`` can provide S/PDIF output though the used of ``lib_spdif``

2
lib_xua/doc/rst/feat_spdif_rx.rst
View File

@@ -1,6 +1,6 @@
S/PDIF Receive
~~~~~~~~~~~~~~
==============
``lib_xua`` supports the development of devices with S/PDIF receive functionality through the use of
``lib_spdif``. The XMOS S/PDIF receiver runs in a single core and supports rates up to 192kHz.

2
lib_xua/doc/rst/feat_spdif_tx.rst
View File

@@ -1,6 +1,6 @@
S/PDIF Transmit
~~~~~~~~~~~~~~~
===============
``lib_xua`` supports the development of devices with S/PDIF transmit functionality through the use of
``lib_spdif``. The XMOS S/PDIF transmitter runs in a single core and supports rates up to 192kHz.

2
lib_xua/doc/rst/issues.rst
View File

@@ -2,7 +2,7 @@
|appendix|
Known Issues
------------
************
- Quad-SPI DFU will corrupt the factory image with tools version < 14.0.4 due to an issue with libquadflash

5
lib_xua/doc/rst/lib_xua.rst
View File

@@ -2,8 +2,7 @@
.. include:: ../../../README.rst
About This Document
~~~~~~~~~~~~~~~~~~~
===================
This document describes the structure of ``lib_xua``, its use and resources required. It also covers some implementation detail.
@@ -18,7 +17,7 @@ the XMOS tool chain and XC language.
Options <opt>
Advanced Usage <using_adv>
Additional Features <feat>
Software Detail <sw>
Implementation Detail <sw>
API <api>
Known Issues <issues>

2
lib_xua/doc/rst/opt.rst
View File

@@ -2,7 +2,7 @@
.. _sec_options:
Options
-------
*******
This section describes key options of ``lib_xua``. These are typically controlled using build time defines.
Where something must be defined, it is recommended this is done in `xua_conf.h` but could also be done in the application Makefile.

12
lib_xua/doc/rst/opt_audio_class.rst
View File

@@ -1,7 +1,7 @@
|newpage|
USB Audio Class Version
~~~~~~~~~~~~~~~~~~~~~~~
=======================
The codebase supports USB Audio Class versions 1.0 and 2.0.
@@ -15,22 +15,22 @@ Additional improvements, amongst others, include:
- Extensive support for interrupts to inform the host about dynamic changes that occur to different entities such as Clocks etc
Driver Support
..............
--------------
Audio Class 1.0
+++++++++++++++
^^^^^^^^^^^^^^^
Audio Class 1.0 is fully supported in Apple OSX. Audio Class 1.0 is fully supported in all modern Microsoft Windows operating systems (i.e. Windows XP and later).
Audio Class 2.0
+++++++++++++++
^^^^^^^^^^^^^^^
Audio Class 2.0 is fully supported in Apple OSX since version 10.6.4. Starting with Windows 10, release 1703, a USB Audio 2.0 driver is shipped with Windows.
Third party Windows drivers are also available, however, documentation of these is beyond the scope of this document, please contact XMOS for further details.
Audio Class 1.0 Mode and Fall-back
..................................
----------------------------------
The default for XMOS USB Audio applications is to run as a high-speed Audio Class 2.0
device. However, some products may prefer to run in Audio Class 1.0 mode, this is normally to
@@ -64,7 +64,7 @@ Due to bandwidth limitations of full-speed USB the following sample-frequency re
Related Defines
................
---------------
:ref:`opt_audio_class_defines` descibes the defines that effect audio class selection.

9
lib_xua/doc/rst/opt_audio_formats.rst
View File

@@ -3,7 +3,7 @@
.. _sec_opt_audio_formats:
Audio Stream Formats
~~~~~~~~~~~~~~~~~~~~
====================
The design currently supports up to three different stream formats for playback, selectable at
run time. This is implemented using standard Alternative Settings to the Audio Streaming interfaces.
@@ -32,7 +32,7 @@ By default the design exposes two sets of Alternative Settings for the playback
24-bit playback. When DSD is enabled an additional (32-bit) alternative is exposed.
Audio Subslot
.............
-------------
An audio subslot holds a single audio sample. See `USB Device Class Definition for Audio Data Formats
<http://www.usb.org/developers/devclass_docs/Audio2.0_final.zip>`_ for full details.
@@ -73,7 +73,7 @@ Values other than 4 may be used for the following reasons:
Audio Sample Resolution
.......................
-----------------------
An audio sample is represented using a number of bits (`bBitResolution`) less than or equal to the number
of total bits available in the audio subslot i.e. `bBitResolution` <= `bSubslotSize` * 8). The design
@@ -99,7 +99,7 @@ supports values 16, 24 and 32.
Audio Format
............
------------
The design supports two audio formats, PCM and, when "Native" DSD is enabled, Direct Stream Digital (DSD).
A DSD capable DAC is required for the latter.
@@ -122,7 +122,6 @@ The following options are supported:
* UAC_FORMAT_TYPEI_PCM
.. note::
Currently DSD is only supported on the output/playback stream

2
lib_xua/doc/rst/opt_channels.rst
View File

@@ -1,7 +1,7 @@
|newpage|
Channel Counts and Sample Rates
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
===============================
The codebase is fully configurable in relation to channel counts and sample rates.
Practical limitations of these are normally based on USB packet size restrictions and I/O

8
lib_xua/doc/rst/opt_dsd.rst
View File

@@ -1,7 +1,7 @@
|newpage|
Direct Stream Digital (DSD)
~~~~~~~~~~~~~~~~~~~~~~~~~~~
===========================
Direct Stream Digital (DSD) is used for digitally encoding audio signals on Super Audio CDs (SACD).
It uses pulse-density modulation (PDM) encoding.
@@ -48,7 +48,7 @@ If only DoP functionality is desired the Native implementation can be disabled w
DSD over PCM (DoP)
..................
------------------
DoP support follows the method described in the `DoP Open Standard 1.1
<http://dsd-guide.com/sites/default/files/white-papers/DoP_openStandard_1v1.pdf>`_.
@@ -81,14 +81,14 @@ of rate.
DoP requires bit-perfect transmission - therefore any audio/volume processing will break the stream.
"Native" vs DoP
~~~~~~~~~~~~~~~
---------------
Since the DoP specification requires header bytes this eats into the data bandwidth. The "Native" implementation
has no such overhead and can therefore transfer the same DSD rate and half the effective PCM rate of DoP.
Such a property may be desired when upporting DSD128 without exposing a 352.8kHz PCM rate, for example.
Ports
.....
-----
The codebase expects 1-bit ports to be defined in the application XN file for the DSD data and
clock lines for example::

2
lib_xua/doc/rst/opt_i2s.rst
View File

@@ -1,7 +1,7 @@
|newpage|
I2S/TDM
~~~~~~~
=======
I2S/TDM is typically fundamental to most products and is built into the ``XUA_AudioHub()`` core.

2
lib_xua/doc/rst/opt_location.rst
View File

@@ -1,7 +1,7 @@
|newpage|
Code Location
~~~~~~~~~~~~~
=============
When designing a system there is a choice as to which hardware resources to use for each interface.
In a multi-tile system the codebase needs to be informed as to which tiles to use for these hardware

2
lib_xua/doc/rst/opt_midi.rst
View File

@@ -2,7 +2,7 @@
|newpage|
MIDI
~~~~
====
The codebase supports MIDI input/output over USB as per `Universal Serial Bus Device Class Definition for MIDI Devices <https://www.usb.org/sites/default/files/midi10.pdf>`_.

2
lib_xua/doc/rst/opt_mixer.rst
View File

@@ -1,7 +1,7 @@
|newpage|
Mixer
~~~~~
=====
The codebase supports audio mixing functionality with highly flexible routing options.

3
lib_xua/doc/rst/opt_other.rst
View File

@@ -1,11 +1,10 @@
|newpage|
Other Options
~~~~~~~~~~~~~
=============
There are a few other, lesser used, options available.
.. _opt_other_defines:
.. list-table:: Other defines

2
lib_xua/doc/rst/opt_pdm.rst
View File

@@ -1,7 +1,7 @@
|newpage|
PDM Microphones
~~~~~~~~~~~~~~~
===============
The codebase supports input from up to 8 PDM microphones.

2
lib_xua/doc/rst/opt_spdif_rx.rst
View File

@@ -1,7 +1,7 @@
|newpage|
S/PDIF Receive
~~~~~~~~~~~~~~
==============
The codebase supports a single, stereo, S/PDIF receiver. This can be input via 75 Ω coaxial or optical fibre.
In order to provide S/PDIF functionality ``lib_xua`` uses ``lib_spdif`` (https://www.github.com/xmos/lib_spdif).

2
lib_xua/doc/rst/opt_spdif_tx.rst
View File

@@ -1,7 +1,7 @@
|newpage|
S/PDIF Transmit
~~~~~~~~~~~~~~~
===============
The codebase supports a single, stereo, S/PDIF transmitter. This can be output over 75 Ω coaxial or optical fibre.
In order to provide S/PDIF transmit functionality ``lib_xua`` uses ``lib_spdif`` (https://www.github.com/xmos/lib_spdif).

2
lib_xua/doc/rst/opt_strings.rst
View File

@@ -1,6 +1,6 @@
Strings and ID's
~~~~~~~~~~~~~~~~
================
The codebase includes various strings and ID's that should be customised to match the product requirements.
These are listed in ::ref:`opt_strings_defines`.

2
lib_xua/doc/rst/opt_sync.rst
View File

@@ -2,7 +2,7 @@
|newpage|
Synchronisation
~~~~~~~~~~~~~~~
===============
The codebase supports "Synchronous" and "Asynchronous" modes for USB transfer as defined by the
USB specification(s).

5
lib_xua/doc/rst/overview.rst
View File

@@ -1,6 +1,5 @@
Overview
--------
********
.. table::
:class: vertical-borders
@@ -75,5 +74,3 @@ Overview
| Reference code is maintained by XMOS Limited. |
+-------------------------------------------------------------------------------------------------------------------------------+

6
lib_xua/doc/rst/sw.rst
View File

@@ -1,8 +1,8 @@
Implementation Detail
---------------------
*********************
This section examines the implementation of the various components that make up ``lib_xua``. It also examines the integration of dependencies and supporting libraries.
This chapter examines the implementation of the various components that make up ``lib_xua``. It also examines the integration of dependencies and supporting libraries.
.. toctree::
@@ -10,8 +10,8 @@ This section examines the implementation of the various components that make up
sw_ep0
sw_xud
sw_clocking
sw_spdif
sw_mixer
sw_spdif
sw_spdif_rx
sw_adat_rx
sw_midi

2
lib_xua/doc/rst/sw_adat_rx.rst
View File

@@ -1,7 +1,7 @@
|newpage|
ADAT Receive
------------
============
The ADAT receive component receives up to eight channels of audio at a sample rate
of 44.1kHz or 48kHz. The API for calling the receiver functions is

9
lib_xua/doc/rst/sw_audio.rst
View File

@@ -3,7 +3,7 @@
.. _usb_audio_sec_audio:
Audio Hub
.........
=========
The Audio Hub task performs many functions. It receives and transmits samples from/to the Decoupler
or Mixer core over a channel.
@@ -96,9 +96,8 @@ Two master clock frequencies to support 44.1kHz and 48kHz audio frequencies (e.g
and 12.288/24.576MHz respectively). This master clock input is then provided to the external audio
hardware and the xCORE device.
Port Configuration (xCORE Master)
+++++++++++++++++++++++++++++++++
---------------------------------
The default software configuration is xCORE is I2S master. That is, the XMOS device provides the BCLK and LRCLK signals to the external audio hardware
@@ -143,7 +142,7 @@ before the data (as required by the I2S standard) and alternates between high an
and right channels of audio.
Changing Audio Sample Frequency
+++++++++++++++++++++++++++++++
-------------------------------
.. _usb_audio_sec_chang-audio-sample:
@@ -159,5 +158,3 @@ functions.
Once this is complete, the I2S/TDM interface (i.e. the main loop in AudioHub) is restarted at the new frequency.

4
lib_xua/doc/rst/sw_clocking.rst
View File

@@ -4,7 +4,7 @@
.. _usb_audio_sec_clock_recovery:
External Clock Recovery (Clock Gen)
-----------------------------------
===================================
To provide an audio master clock an application may use selectable oscillators, clock
generation IC or, in the case of xCORE.ai devices, integrated secondary PLL, to generate fixed
@@ -14,7 +14,7 @@ It may also use an external PLL/Clock Multiplier to generate a master clock base
the xCORE.
Using an external PLL/Clock Multiplier allows an Asynchronous mode design to lock to an external
clock source from a digital stream (e.g. S/PDIF or ADAT input). The code-base supports the Cirrus
clock source from a digital stream (e.g. S/PDIF or ADAT input). The codebase supports the Cirrus
Logic CS2100 device for this purpose. Other devices may be supported via code modification.
.. note::

34
lib_xua/doc/rst/sw_ep0.rst
View File

@@ -3,14 +3,14 @@
.. _usb_audio_sec_usb:
Endpoint 0: Management and Control
..................................
==================================
All USB devices must support a mandatory control endpoint, Endpoint 0. This controls the management tasks of the USB device.
These tasks can be generally split into enumeration, audio configuration and firmware upgrade requests.
Enumeration
~~~~~~~~~~~
-----------
When the device is first attached to a host, enumeration occurs. This process involves the host interrogating the device as to its functionality. The device does this by presenting several interfaces to the host via a set of descriptors.
@@ -41,12 +41,13 @@ The function may also return ``XUD_RES_RST`` if a bus-reset has been issued onto
Since the ``USB_StandardRequests()`` function STALLs an unknown request, the endpoint 0 code must first parse the ``USB_SetupPacket_t`` structure to handle device specific requests and then call ``USB_StandardRequests()`` as required.
Over-riding Standard Requests
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----------------------------
The USB Audio design "over-rides" some of the requests handled by ``USB_StandardRequests()``, for example it uses the SET_INTERFACE request to indicate if the host is streaming audio to the device. In this case the setup packet is parsed, the relevant action taken, the ``USB_StandardRequests()`` is still called to handle the response to the host.
Class Requests
~~~~~~~~~~~~~~
--------------
Before making the call to ``USB_StandardRequests()`` the setup packet is parsed for Class requests. These are handled in functions such as ``AudioClassRequests_1()``, ``AudioClassRequests_2``, ``DFUDeviceRequests()`` etc depending on the type of request.
Any device specific requests are handled - in this case Audio Class, MIDI class, DFU requests etc.
@@ -54,7 +55,7 @@ Any device specific requests are handled - in this case Audio Class, MIDI class,
Some of the common Audio Class requests and their associated behaviour will now be examined.
Audio Requests
++++++++++++++
^^^^^^^^^^^^^^
When the host issues an audio request (e.g. sample rate or volume change), it sends a command to Endpoint 0. Like all requests this is returned from ``USB_GetSetupPacket()``. After some parsing (namely as Class Request to an Audio Interface) the request is handled by either the ``AudioClassRequests_1()`` or ``AudioClassRequests_2()`` function (based on whether the device is running in Audio Class 1.0 or 2.0 mode).
@@ -63,7 +64,7 @@ Note, Audio Class 1.0 Sample rate changes are send to the relevant endpoint, rat
The ``AudioClassRequests_X()`` functions further parses the request in order to ascertain the correct audio operation to execute.
Audio Request: Set Sample Rate
++++++++++++++++++++++++++++++
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The ``AudioClassRequests_2()`` function parses the passed ``USB_SetupPacket_t`` structure for a ``CUR`` request of type ``SAM_FREQ_CONTROL`` to a Clock Unit in the devices topology (as described in the devices descriptors).
@@ -72,7 +73,7 @@ The new sample frequency is extracted and passed via channel to the rest of the
.. _usb_audio_sec_audio-requ-volume:
Audio Request: Volume Control
+++++++++++++++++++++++++++++
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When the host requests a volume change, it
sends an audio interface request to Endpoint 0. An array is
@@ -102,10 +103,10 @@ to the mixer to change the volume. Mixer commands
are described in :ref:`usb_audio_sec_mixer`.
Audio Endpoints (Endpoint Buffer and Decoupler)
...............................................
===============================================
Endpoint Buffer
~~~~~~~~~~~~~~~
---------------
All endpoints other that Endpoint 0 are handled in one core. This
core is implemented in the file ``ep_buffer.xc``. This core communicates directly with the XUD library.
@@ -114,7 +115,7 @@ The USB buffer core is also responsible for feedback calculation based on USB St
(SOF) notification and reads from the port counter of a port connected to the master clock.
Decouple
~~~~~~~~
--------
The decoupler supplies the USB buffering core with buffers to
transmit/receive audio data to/from the host. It marshals these buffers into
@@ -125,7 +126,7 @@ matching the audio rate to the USB packet rate). The decoupler is
implemented in the file ``decouple.xc``.
Audio Buffering Scheme
~~~~~~~~~~~~~~~~~~~~~~~
----------------------
This scheme is executed by co-operation between the buffering
core, the decouple core and the XUD library.
@@ -133,7 +134,6 @@ core, the decouple core and the XUD library.
For data going from the device to the host the following scheme is
used:
#. The Decouple core receives samples from the Audio Hub core and
puts them into a FIFO. This FIFO is split into packets when data is
entered into it. Packets are stored in a format consisting of their
@@ -152,11 +152,9 @@ used:
Decouple core that the buffer has been sent and the Decouple core
moves the read pointer of the FIFO.
For data going from the host to the device the following scheme is
used:
#. The Decouple core passes a pointer to the Endpoint Buffer core
pointing into a FIFO of data and signals to the XUD library that
the Endpoint Buffer core is ready to receive.
@@ -171,9 +169,8 @@ used:
#. Upon request from the Audio Hub core, the Decouple core sends
samples to the Audio Hub core by reading samples out of the FIFO.
Decoupler/Audio Core interaction
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--------------------------------
To meet timing requirements of the audio system (i.e Audio Hub/Mixer), the Decoupler
core must respond to requests from the audio system to
@@ -200,7 +197,6 @@ in channel count sized chunks (i.e. ``NUM_USB_CHAN_OUT`` and
The complete communication scheme is shown in the table below (for non sample
frequency change case):
.. table:: Decouple/Audio System Channel Communication
+-----------------+-----------------+-----------------------------------------+
@@ -242,7 +238,7 @@ frequency change case):
(this is especially advantageous in the DSD over PCM (DoP) case)
Asynchronous Feedback
+++++++++++++++++++++
---------------------
When built to operate in Asynchronous mode the device uses a feedback endpoint to report the rate at which
audio is output/input to/from external audio interfaces/devices. This feedback is in accordance with
@@ -265,7 +261,7 @@ sent to the host. In practice this an explicit feedback endpoint is normally use
in Microsoft Windows operating systems (see ``UAC_FORCE_FEEDBACK_EP``).
USB Rate Control
++++++++++++++++
----------------
.. _usb_audio_sec_usb-rate-control:

2
lib_xua/doc/rst/sw_hid.rst
View File

@@ -1,5 +1,5 @@
Audio Controls via Human Interface Device (HID)
------------------------------------------------
===============================================
The design supports simple audio controls such as play/pause, volume up/down etc via the USB Human
Interface Device Class Specification.

6
lib_xua/doc/rst/sw_midi.rst
View File

@@ -1,11 +1,11 @@
|newpage|
MIDI
----
====
The MIDI core implements a 31250 baud UART for both input and output. On receiving 32-bit USB MIDI events
The MIDI core implements a 31250 baud UART for both input and output. On receiving 32=bit USB MIDI events
from the Endpoint Buffer core, it parses these and translates them to 8-bit MIDI messages which are sent
over UART. Similarly, incoming 8-bit MIDI messages are aggregated into 32-bit USB-MIDI events and
over UART. Similarly, incoming 8-bit MIDI messages are aggregated into 32-bit USB MIDI events and
passed on to the Endpoint Buffer core. The MIDI core is implemented in the file ``usb_midi.xc``.
The Endpoint Buffer core implements the two Bulk endpoints (one In and one Out) as well as interacting

8
lib_xua/doc/rst/sw_pdm.rst
View File

@@ -1,7 +1,7 @@
|newpage|
PDM Microphones
---------------
===============
The XMOS USB Audio Reference Design firmware is capable of integrating with PDM microphones.
The PDM stream from the microphones is converted to PCM and output to the host via USB.
@@ -46,9 +46,8 @@ After the decimation to the output sample-rate various other steps take place e.
and compensation etc. Please refer to the documentation provided with ``lib_mic_array`` for further
implementation detail and complete feature set.
PDM Microphone Hardware Characteristics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
---------------------------------------
The PDM microphones require a *clock input* and provide the PDM signal on a *data output*. All of
the PDM microphones must share the same clock signal (buffered on the PCB as appropriate), and
@@ -78,7 +77,7 @@ divide down 12.288 MHz master clock. Or, if clock accuracy is not important, the
reference can be divided down to provide an approximate clock.
Usage & Integration
~~~~~~~~~~~~~~~~~~~
-------------------
A PDM microphone wrapper is called from ``main()`` and takes one channel argument connecting it to the rest of the system:
@@ -113,3 +112,4 @@ sends the frame of audio back over this channel.
Note, it is assumed that the system shares a global master-clock, therefore no additional buffering or rate-matching/conversion
is required.

3
lib_xua/doc/rst/sw_resource.rst
View File

@@ -3,7 +3,7 @@
.. _usb_audio_sec_resource_usage:
Resource Usage
--------------
==============
The following table details the resource usage of each component of the reference design software.
Note, memory usage is approximate and varies based on device used, compiler settings etc.
@@ -50,3 +50,4 @@ Note, memory usage is approximate and varies based on device used, compiler sett
Unlike other interfaces, since the USB PHY is internal the USB ports are a fixed set of ports
and cannot be modified. See ``lib_xud`` documentation for full details.

13
lib_xua/doc/rst/sw_spdif.rst
View File

@@ -2,7 +2,7 @@
|newpage|
S/PDIF Transmit
...............
===============
``lib_xua`` supports the development of devices with S/PDIF transmit throught the use of ``lib_spdif``.
The XMOS S/SPDIF transmitter component runs in a single core and supports sample-rates upto 192kHz.
@@ -21,7 +21,7 @@ bits) and transmitted in biphase-mark encoding (BMC) with respect to an *externa
Note that a minor change to the ``SpdifTransmitPortConfig`` function would enable *internal* master
clock generation (e.g. when clock source is already locked to desired audio clock).
.. list-table:: S/PDIF Capabilities
.. list-table:: S/PDIF Capabilities
* - **Sample frequencies**
- 44.1, 48, 88.2, 96, 176.4, 192 kHz
@@ -31,7 +31,7 @@ clock generation (e.g. when clock source is already locked to desired audio cloc
- ``lib_spdif``
Clocking
++++++++
--------
.. only:: latex
@@ -54,7 +54,7 @@ This resamples the master clock to its clock domain (oscillator), which introduc
A typical jitter-reduction scheme is an external D-type flip-flop clocked from the master clock (as shown in the preceding diagram).
Usage
+++++
-----
The interface to the S/PDIF transmitter core is via a normal channel with streaming built-ins
(``outuint``, ``inuint``). Data format should be 24-bit left-aligned in a 32-bit word: ``0x12345600``
@@ -84,9 +84,8 @@ The following protocol is used on the channel:
This communication is wrapped up in the API functions provided by ``lib_spdif``.
Output stream structure
+++++++++++++++++++++++
Output Stream Structure
-----------------------
The stream is composed of words with the following structure shown in
:ref:`usb_audio_spdif_stream_structure`. The channel status bits are

4
lib_xua/doc/rst/sw_spdif_rx.rst
View File

@@ -1,7 +1,7 @@
|newpage|
S/PDIF Receive
---------------
==============
XMOS devices can support S/PDIF receive up to 192kHz - see ``lib_spdif`` for full specifications.
@@ -45,7 +45,7 @@ The tag has one of three values:
See S/PDIF, IEC 60958-3:2006, specification for further details on format, user bits etc.
Usage and Integration
+++++++++++++++++++++
---------------------
Since S/PDIF is a digital steam the devices master clock must be synchronised to it. This is typically
done with an external device. See `Clock Recovery` (:ref:`usb_audio_sec_clock_recovery`).

2
lib_xua/doc/rst/sw_xud.rst
View File

@@ -2,7 +2,7 @@
|newpage|
XMOS USB Device (XUD) Library
.............................
=============================
All low level communication with the USB host is handled by the XMOS USB Device (XUD) library - `lib_xud`

13
lib_xua/doc/rst/using.rst
View File

@@ -1,12 +1,12 @@
Basic Usage
-----------
***********
This sections describes the basic usage of `lib_xua` and provides a guide on how to program USB Audio Devices.
Library Structure
~~~~~~~~~~~~~~~~~
=================
The code is split into several directories.
@@ -26,7 +26,7 @@ Note, the midi and dfu directories are potential candidates for separate libs in
Using in a Project
~~~~~~~~~~~~~~~~~~
==================
All `lib_xua` functions can be accessed via the ``xua.h`` header file::
@@ -39,7 +39,7 @@ It is also required to add ``lib_xua`` to the ``USED_MODULES`` field of your app
.. _sec_basic_usage_codeless:
"Codeless" Programming Model
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
============================
Whilst it is possible to code a USB Audio device using the building blocks provided by `lib_xua`
it is realised that this might not be desirable for many classes of customers or products.
@@ -71,7 +71,7 @@ set ``EXCLUDE_USB_AUDIO_MAIN`` to 1 in the application makefile or ``xua_conf.h`
::ref:`sec_advanced_usage`.
Configuring lib_xua
~~~~~~~~~~~~~~~~~~~
===================
Configuration of the various build time options of ``lib_xua`` is done via the optional header `xua_conf.h`.
To allow the build scripts to locate this file it should reside somewhere in the application `src` directory.
@@ -93,9 +93,8 @@ should continue to include `xua.h` as previously directed. A simple example is s
#endif
User Functions
~~~~~~~~~~~~~~
==============
To enable custom functionality, such as configuring external audio hardware, bespoke behaviour on
stream start/stop etc, various functions can be overridden by the user. (see ::ref:`sec_api` for

2
lib_xua/doc/rst/using_adv.rst
View File

@@ -1,7 +1,7 @@
.. _sec_advanced_usage:
Advanced Usage
--------------
**************
Whilst it is possible to program USB Audio devices using ``lib_xua`` by only setting defines
(see :ref:`sec_basic_usage_codeless`) some developers may want to code a USB Audio device from

2
lib_xua/doc/rst/using_adv_core_comp.rst
View File

@@ -1,5 +1,5 @@
Running the Core Components
~~~~~~~~~~~~~~~~~~~~~~~~~~~
===========================
In their most basic form the core components can be run as follows::

2
lib_xua/doc/rst/using_adv_core_hw.rst
View File

@@ -1,5 +1,5 @@
Core Hardware Resources
~~~~~~~~~~~~~~~~~~~~~~~
=======================
The user must declare and initialise relevant hardware resources (globally) and pass them to the
relevant function of `lib_xua`.

2
lib_xua/doc/rst/using_adv_i2s.rst
View File

@@ -1,7 +1,7 @@
|newpage|
I2S/TDM
~~~~~~~
=======
I2S/TDM is typically fundamental to most products and is built into the ``XUA_AudioHub()`` core.

2
lib_xua/doc/rst/using_adv_mixer.rst
View File

@@ -1,7 +1,7 @@
|newpage|
Mixer
~~~~~
=====
Since the mixer has no I/O the instantiation is straight forward. Communication wises, the mixer cores are inserted
between the `AudioHub` and Buffering core(s)

4
lib_xua/module_build_info
View File

@@ -1,4 +1,4 @@
VERSION = 3.3.0
VERSION = 3.3.1
DEBUG ?= 0
@@ -11,7 +11,7 @@ endif
DEPENDENT_MODULES = lib_locks(>=2.1.0) \
lib_logging(>=3.1.1) \
lib_mic_array(>=4.5.0) \
lib_spdif(>=4.1.0) \
lib_spdif(>=4.2.1) \
lib_xassert(>=4.1.0) \
lib_xud(>=2.2.1) \
lib_adat(>=1.0.0)