janis/aes67-daemon
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update README.md

Browse Source
This commit is contained in:
Andrea Bondavalli 2021-12-07 09:10:37 +01:00 committed by GitHub
parent c5e72e5d47
commit 6deea0a19f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 66 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

67
README.md
View File

@ -168,7 +168,7 @@ The test performs the following operations:
* wait for the recording and the playback to complete
* check that the recorded file contains the expected audio samples sequence
* terminate ptp4l and the AES67 daemon
* print the test result that can be either *OK" or *failed at (location)*
* print the test result that can be either *OK* or *failed at (location)*
If the test result is OK it means that the selected configuration can run smoothly on your platform.
@ -179,6 +179,71 @@ In this case you may try to configure a different driver timer basic tick period
By default this parameter is set to 48 (1ms latency) and the valid range is from 48 to 480 with steps of 48.
Note that higher values of this parameter (values above 48) lead to higher packets processing latency and this breaks the compatibility with certain devices.
## Run the platform latency test ##
<a name="latency"></a>
The platform latency test can be used to measure the minimum end-to-end latency that can be achieved on a specific platform.
The test is based on the same setup used for the platform compatibility test where a _Sink_ is configured to receive audio samples from a _Source_
both running on the same device using the network loopback interface.
A test application plays audio samples on the RAVENNA playback device and measures the time till the samples are received on the RAVENNA capture device.
The test setup and the end-to-end latency measured are shown in the picture below:
![image](https://user-images.githubusercontent.com/56439183/144990290-c5c94697-b631-4af0-981a-dfea5fc21e9a.png)
The test can be executed using the [run\_latency\_test.sh](run_latency_test.sh) script. See [script notes](#notes).
The script allows a user to test the latency on a specific configuration and it can be used to ensure that a specific ALSA buffer size can be used:
Usage run_latency_test.sh sample_format sample_rate channels duration frames
sample_format can be one of S16_LE, S24_3LE, S32_LE
sample_rate can be one of 44100, 48000, 96000
channels can be one of 1, 2, 4
duration of the test in seconds
frames buffer size in frames
The specified buffer size in frames starts from _tic_frame_size_at_1fs_ * 2 (128 by default) in steps of _tic_frame_size_at_1fs_.
For example, to test the typical AES67 configuration for 1 minute and a buffer size of 128 frames run:
./run_test.sh S24_3LE 48000 2 60 128
If no underrun errors occurred during the test the requested buffer size can be used and the end-to-end latency measured is printed at the end:
Trying latency 128 frames, 2666.667us, 2.666667ms (375.0000Hz)
Success
Playback:
*** frames = 2880128 ***
state : RUNNING
trigger_time: 157745.455411
tstamp : 0.000000
delay : 128
avail : 0
avail_max : 64
Capture:
*** frames = 2880000 ***
state : RUNNING
trigger_time: 157745.455415
tstamp : 0.000000
delay : 0
avail : 0
avail_max : 64
Maximum read: 64 frames
Maximum read latency: 1333.333us, 1.333333ms (750.0000Hz)
Playback time = 157745.455411, Record time = 157745.455415, diff = -4
End to end latency: 7.997 msecs
Terminating processes ...
daemon exiting with code: 0
The previous test was run on a _NanoPi NEO2 board_ with Ubuntu distro.
In case underrun happened the status reported is:
state : XRUN
and the specified buffer size cannot be used.
## Run the daemon regression tests ##
To run daemon regression tests install the ALSA RAVENNA/AES67 kernel module with: