marvin
/
us144mkii
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

reverse eng report update

This commit is contained in:
serifpersia 2025-06-25 14:13:54 +02:00
parent 4f7f991607
commit b6687819df
1 changed files with 104 additions and 76 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

108
latest_reverse_eng_report/Linux Driver Development Specification for TASCAM US-144 MKII.txt
View File

@ -1,40 +1,47 @@
Final Analysis Report & Driver Development Specification for TASCAM US-144 MKII
Document Version: 5.0
Date: 2025-06-23
Document Version: 7.0
Date: 2025-06-25
Subject: This document provides a complete specification for the USB control protocol and core audio data flow of the TASCAM US-144 MKII. It is intended to serve as the primary technical reference for implementing a functional Linux driver.
1. Device Identification
Vendor ID (VID): 0x0644
Vendor ID (VID): 0x0644 (TEAC Corporation)
Product ID (PID): 0x8020
2. USB Audio Architecture
USB Version: 2.0
The device utilizes a vendor-specific protocol and does not implement a standard USB Audio Class (UAC) interface for streaming. The core architecture is a fixed 4-channel input / 4-channel output system over USB.
Device Speed: High-Speed (480 Mbit/s)
Device Class: 0xFF (Vendor Specific)
2. USB Architecture
The device utilizes a vendor-specific protocol and does not implement a standard USB Audio Class (UAC) interface for streaming. The core architecture is a fixed 4-channel input / 4-channel output system over a High-Speed USB connection.
Playback (Host -> Device): A 4-channel Asynchronous Isochronous OUT stream on Endpoint 0x02. The host driver is responsible for populating all 4 channels. Unused channels should be filled with digital silence.
Capture (Device -> Host): A 4-channel continuous Bulk IN stream on Endpoint 0x86. This stream is active after device initialization and is preceded by a 2048-byte header in each transfer, which must be discarded before processing audio data.
Capture (Device -> Host): A 4-channel continuous Bulk IN stream on Endpoint 0x86. This stream is active after device initialization.
Clocking: An associated Isochronous IN feedback endpoint (0x81) is used for playback clock drift correction. This endpoint does not carry audio data.
Clocking: An associated Isochronous IN feedback endpoint (0x81) is used for playback clock drift correction.
Sample Rates: 44.1, 48, 88.2, and 96 kHz.
Bit Depth: Fixed at 24-bit Little Endian PCM for all audio streams.
3. Endpoint Map
Endpoint Direction Type Interface Alternate Setting Verified Function
0x02 OUT Isochronous 0 1 Audio Playback Data: 4-channel interleaved 24-bit PCM stream.
0x81 IN Isochronous 1 1 Playback Clock Feedback: Non-audio timing data. Consistently sends 303030.
0x86 IN Bulk 1 1 Audio Capture Data: 4-channel interleaved 24-bit PCM stream, preceded by a 2048-byte header.
Endpoint Direction Type Interface Alt Setting Verified Function
0x02 OUT Isochronous 0 1 Audio Playback Data
0x81 IN Isochronous 1 1 Playback Clock Feedback
0x86 IN Bulk 1 1 Audio Capture Data
0x83 IN Bulk 0 1 MIDI IN Data
0x04 OUT Bulk 0 1 MIDI OUT Data
4. Device Initialization and Rate-Setting Sequence
To initialize the device or change the sample rate, the following sequence of control transfers must be executed in order.
Step 1: Set Interfaces
Step 1: Set Interfaces
Set Configuration: SET_CONFIGURATION, wValue: 1, wIndex: 0
@ -42,19 +49,18 @@ To initialize the device or change the sample rate, the following sequence of co
Set Interface 1: SET_INTERFACE, wValue: 1, wIndex: 1
Step 2: Initial Handshake & Status Check (Optional but Recommended)
Step 2: Initial Handshake & Status Check
bmRequestType: 0xc0, bRequest: 73, wValue: 0x0000, wIndex: 0x0000, wLength: 1
Expected Response Data: 0x12
Step 3: Set Initial Mode
Step 3: Set Initial Mode
bmRequestType: 0x40, bRequest: 73, wValue: 0x0010, wIndex: 0x0000, wLength: 0
Step 4: Set Sample Rate
This is a UAC-style command sent twice, once for each endpoint.
Step 4: Set Sample Rate
This is a UAC-style command sent twice, once for each endpoint.
bmRequestType: 0x22, bRequest: 1 (SET_CUR), wValue: 0x0100 (SAMPLING_FREQ_CONTROL), wLength: 3
@ -68,7 +74,7 @@ To initialize the device or change the sample rate, the following sequence of co
| 88200 Hz | 88 58 01 |
| 96000 Hz | 00 77 01 |
Step 5: Configure Internal Registers
Step 5: Configure Internal Registers
Static Register Writes:
| wValue | bRequest | bmRequestType | wIndex |
@ -90,45 +96,67 @@ To initialize the device or change the sample rate, the following sequence of co
| :--- | :--- | :--- | :--- |
| 0x110b | 65 | 0x40 | 0x0101 |
Step 6: Enable Streaming
Step 6: Enable Streaming
bmRequestType: 0x40, bRequest: 73, wValue: 0x0030, wIndex: 0x0000, wLength: 0
5. Audio Data Stream Format
A single "audio frame" consists of one sample for each of the four channels and is 12 bytes long (4 channels x 3 bytes/channel). All samples are 24-bit Little Endian.
Audio Frame: A single "audio frame" consists of one sample for each of the four channels and is 12 bytes long (4 channels x 3 bytes/channel). All samples are 24-bit Little Endian.
Playback Stream (Endpoint 0x02):
Type: Isochronous OUT.
Structure: The stream consists of a series of isochronous packets. At 48kHz, each packet is 72 bytes, containing 6 audio frames.
Packet sizes are rate-dependent. The host driver must construct packets of the following sizes:
| Sample Rate | Packet Size(s) (Bytes) | Frames per Packet | Notes |
| :--- | :--- | :--- | :--- |
| 44100 Hz | 72 / 60 | 6 / 5 | Alternating pattern of 72 and 60-byte packets. |
| 48000 Hz | 72 | 6 | Fixed size. |
| 88200 Hz | 132 | 11 | Fixed size. |
| 96000 Hz | 144 / 132 | 12 / 11 | Nominal size is 144 bytes. Smaller 132-byte packets are sent for clock correction. |
Frame Format (12 bytes):
| Byte Offset | Length | Channel Assignment |
| :--- | :--- | :--- |
| 0, 1, 2 | 3 bytes | Channel 1 (Analog Left Out) |
| 3, 4, 5 | 3 bytes | Channel 2 (Analog Right Out) |
| 6, 7, 8 | 3 bytes | Channel 3 (Digital Left Out) |
| 9, 10, 11 | 3 bytes | Channel 4 (Digital Right Out) |
URB Structure: The host driver submits URBs containing a variable number of these packets. The number of packets per URB is determined by the latency/buffer size setting requested by the audio application.
Capture Stream (Endpoint 0x86):
Type: Bulk IN.
Structure: The stream consists of large bulk transfers (e.g., 131,072 bytes). Each transfer is composed of:
Structure: The stream consists of large bulk transfers. Each transfer is composed of:
A 2048-byte (0x800) header. The purpose of this header is unknown; it must be read and discarded.
A 2048-byte (0x800) header. The purpose of this header is unknown; it must be read and discarded by the driver.
The subsequent data is a continuous stream of interleaved 12-byte audio frames.
Frame Format (12 bytes):
| Byte Offset | Length | Channel Assignment |
| :--- | :--- | :--- |
| 0, 1, 2 | 3 bytes | Channel 1 (Analog Left In) |
| 3, 4, 5 | 3 bytes | Channel 2 (Analog Right In) |
| 6, 7, 8 | 3 bytes | Channel 3 (Digital Left In) |
| 9, 10, 11 | 3 bytes | Channel 4 (Digital Right In) |
6. Clocking and Feedback Mechanism
6. Host-Side Audio Routing Logic
Feedback Endpoint (0x81): This endpoint provides a feedback signal to the host to correct for clock drift.
The device's internal hardware routing is fixed. All channel routing, duplication, and mixing must be performed by the host-side driver. The TASCAM Control Panel application modifies the behavior of the driver, not the hardware.
Feedback Value: The device sends a 3-byte value that is dependent on the selected sample rate. Minor jitter in the received value (e.g., 0x5f6060 instead of 0x606060) is normal and should be handled.
| Sample Rate | 3-Byte Feedback Value (Hex) |
| :--- | :--- |
| 44100 Hz | 0x2c2c2c |
| 48000 Hz | 0x303030 |
| 88200 Hz | 0x585858 |
| 96000 Hz | 0x606060 |
Driver Implementation ("Pitch Control"): The driver must use this feedback value to pace the audio stream.
The driver must always send packets of the sizes specified in the table in Section 5.
It uses the feedback value to calculate the ideal number of audio frames to consume from the ALSA buffer per USB frame (1ms).
This calculation will result in a fractional number of frames (e.g., 48.001 frames).
The driver must use an accumulator to track this fractional part.
In each URB, the driver copies the integer number of frames into the packet buffers.
If the number of bytes copied is less than the total size of the packets in the URB, the remaining space must be padded with digital silence (zeros). This ensures the device always receives perfectly formed packets.
7. Host-Side Audio Routing Logic
The device's internal hardware routing is fixed. All channel routing, duplication, and mixing must be performed by the host-side driver.
Fixed Hardware Mapping:
@ -142,7 +170,7 @@ The device's internal hardware routing is fixed. All channel routing, duplicatio
Driver Responsibility: The driver must act as a software patch bay. For example, to route system audio (typically stereo channels 1/2) to the S/PDIF output, the driver must copy the audio data from channels 1/2 into the channel 3/4 slots of the USB OUT stream before sending it to the device.
7. Areas for Further Investigation
8. Areas for Further Investigation
MIDI (EP 0x83/0x04): The data format for MIDI messages on the bulk endpoints requires analysis.