xmos / lib_src Goto Github PK

us3 example is basically a test. Doesn't show a practical use of teh function.
In particular, how to walk through the 2 dimensional array of coeffs.
Something like:

int main()
{

int32_t data[SRC_FF3V_FIR_TAPS_PER_PHASE];
memset(data, 0, sizeof(data));

for (unsigned s=0;s<24;s++)
{
    int32_t samp = (s == 0 ? 0x7fffffff : 0); //impulse

    //Walk backwards through phases
    printf("%d\n", src_us3_voice_input_sample(data, src_ff3v_fir_coefs[2], samp));
    printf("%d\n", src_us3_voice_get_next_sample(data, src_ff3v_fir_coefs[1]));
    printf("%d\n", src_us3_voice_get_next_sample(data, src_ff3v_fir_coefs[0]));
}
return 0;

}

Currently cmake support is being manually copied about through projects using this repo.

the CMakeLists.txt from here should be good enough

From @ed-xmos:

(1/16000)/6.24e-6 - 10.016, so we can squeeze 10 in theoretically.
My mistake - I should have re-calculated this bit

WRT:
The DS3 processing takes up to 389 core cycles to compute a sample which translates to 3.89us at 100MHz or 6.224us at 62.5MHz core speed. This permits up to 9 channels of 48KHz -> 16KHz sample rate conversion in a single 62.5MHz core.

Raised in feedback of pull request #4.

(this is related to lib_dsp - it may have been fixed in lib_src)

The current data structure contains pointers to a 3-word and 1-word array::

typedef struct dsp_ds3_ctrl_t
{
int *in_data; // Pointer to input data (3 samples)
int *out_data; // Pointer to output data (1 sample)
...

rather than the two arrays itself::

typedef struct dsp_ds3_ctrl_t
{
int in_data[3]; // Pointer to input data (3 samples)
int out_data[1]; // Pointer to output data (1 sample)
...

The latter saves code space (no need to initialise the pointers), it saves memory space (4 words rather than 6), and best of all, you cannot forget to initialise them.

The former case optimises for a case where you move something along a buffer; something that only works if the buffer is on the same core as yourself, and not wrapped around.

Is there any good reason not to pre-allocate the arrays?

The ASRC implementation currently supports sampling rates from 192Kz to 44.1KHz. In order to use it in sln_voice we'd need to extend it to support a minimum sampling rate of 16KHz.

• CHANGED: Made the FIR coefficient array that is used with the voice fixed factor of 3 up and down sampling functions usable from within C files as well as XC files.
• CHANGED: Aligned the FIR coefficient array to an 8-byte boundary. This ensures that the voice fixed factor of 3 up and down sampling functions do not crash with a LOAD_STORE exception.
• ADDED: Missing device attributes to the .xn file of the AN00231 app note.

The delay_*() functions assume that there is an available, initialized timer resource but does not check or guarantee that this is the case:

Here is a usage that does not currently cause a resource exception, but may if more timers were in use:
https://github.com/xmos/lib_src/blame/54d83c283da57a20f3167fefacb7f6275d1193d7/lib_src/src/asrc_task/asrc_task.c#L262

http://www.audioholics.com/audio-technologies/upsampling-vs-oversampling-for-digital-audio

These SNR values should be added to the library documentation.

Raised in feedback of pull request #4.

This example code produces N*samples shift between left & right output channels.

For example, after ASRC 48kHz->48kHz the left channel is ahead of the right one by 1 sample.

Bug fix:
in the function
void serial2block(server serial_transfer_push_if i_serial_in, client block_transfer_if i_block_transfer[ASRC_N_INSTANCES], server sample_rate_enquiry_if i_input_rate)

if (chan_idx == ASRC_CHANNELS_PER_INSTANCE - 1) buff_idx++; //Move index when all channels received

MUST be

if (chan_idx == ASRC_CHANNELS_PER_INSTANCE) buff_idx++; //Move index when all channels received

The memory and MIPs requirements should be added to the library documentation, as well as the number of channels/rate that be processed in a single core.

Raised in feedback of pull request #4.

I want to spend some time studying this repo, the ways it's being used and the sample rate conversion principles

This is a branch that has optional support for 24 kHz and 32 kHz inputs that we've had some interest in:

https://github.com/henkmuller/lib_src/tree/feature/freq-24-32

24 and 32 can be used as outputs from 48 kHz too. Conversion from other frequencies (44.1, 88.2, 96, 176, 192) will need some additional filters and tests.

This branch contains additional 48->32 and 32->24 filters that will need to be checked by somebody with DSP knowledge.

As there is an N^2 table of conversion parameters and conversion coefficients, I can see value to at some stage make each frequency optional; that way more frequencies can be added without costing the earth. It will complicate testing though

These are identical to versions 3.0.0 and 2.1.0.

module_build_info should not be updated to reflect bumps in version numbers that have no effect. This just causes work without any value.

Quinn reported problems running the app note configured to 192kHz (coaxial S/PDIF)

See RT ticket 9788 for more details

The recent change to make the ff3v FIR array accessable from both C and XC has added significant overhead to the operation of UserBufferManager() in XVF3510. The UBM Timing test shows a cycle count increase from 1161 to 1379, about 19%. This increase exceeds the limit of cycles available if the tile hosting the audio loop, which includes UBM, has a full complement of 8 logical cores.

The results below were produced in an XVF3510 sandbox created from the sw_xvf3510_develop view file @ xgit commit 4bc3338ac. Follow How to build the 3510 firmware on WSL to create the sandbox (it works with slight alterations on MacOs and native Linux). Then change into the sw_xvf3510/tests/ubm_timing_test directory and run:

waf configure
waf clean build
xsim bin/ubm_timing_test.xe

Results @ lib_src commit 4769609 (committed 2021-05-05 15:21:55 and direct ancestor to HEAD of develop on 2021-07-05):

(.venv) michaelb@LT000633:~/sandboxes/sw_xvf3510_feature_configurable_hid/sw_xvf3510/tests/ubm_timing_test$ xsim bin/ubm_timing_test.xe
Filters 0: shifters: 0
From 16 loops (not including first) receive_worst: 25, send_worst: 26, restart_worst: 1110
Total thread cycles: 1161 available (8t): 1368 (7t): 1559
System clock rate: 540666531Hz, margin thread cycles 8t: 207, 7t: 398
TEST PASS (assert_on_fail: 1)

Filters 2: shifters: 0
From 16 loops (not including first) receive_worst: 25, send_worst: 26, restart_worst: 1230
Total thread cycles: 1281 available (8t): 1368 (7t): 1559
System clock rate: 540666531Hz, margin thread cycles 8t: 87, 7t: 278
TEST PASS (assert_on_fail: 1)

Filters 4: shifters: 0
From 16 loops (not including first) receive_worst: 25, send_worst: 26, restart_worst: 1350
Total thread cycles: 1401 available (8t): 1368 (7t): 1559
System clock rate: 540666531Hz, margin thread cycles 8t: -33, 7t: 158
TEST FAIL (assert_on_fail: 0)

Filters 0: shifters: 6
From 16 loops (not including first) receive_worst: 25, send_worst: 26, restart_worst: 1364
Total thread cycles: 1415 available (8t): 1368 (7t): 1559
System clock rate: 540666531Hz, margin thread cycles 8t: -47, 7t: 144
TEST FAIL (assert_on_fail: 0)

Filters 4: shifters: 6
From 16 loops (not including first) receive_worst: 25, send_worst: 26, restart_worst: 1605
Total thread cycles: 1656 available (8t): 1368 (7t): 1559
System clock rate: 540666531Hz, margin thread cycles 8t: -288, 7t: -97
TEST FAIL (assert_on_fail: 0)

(.venv) michaelb@LT000633:~/sandboxes/sw_xvf3510_feature_configurable_hid/sw_xvf3510/tests/ubm_timing_test$

Results @ commit 6467329 (committed 2021-06-25 14:31:35) and 3c3956e (committed 2021-06-30 15:23:12 and HEAD of develop on 2021-07-05):

(.venv) michaelb@LT000633:~/sandboxes/sw_xvf3510_feature_configurable_hid/sw_xvf3510/tests/ubm_timing_test$ xsim bin/ubm_timing_test.xe
Filters 0: shifters: 0
From 16 loops (not including first) receive_worst: 25, send_worst: 26, restart_worst: 1328
Total thread cycles: 1379 available (8t): 1368 (7t): 1559
System clock rate: 540666531Hz, margin thread cycles 8t: -11, 7t: 180
TEST FAIL (assert_on_fail: 1)

Unhandled exception: ECALL, data: 0x00000000
(.venv) michaelb@LT000633:~/sandboxes/sw_xvf3510_feature_configurable_hid/sw_xvf3510/tests/ubm_timing_test$

Stack sizes set as, for example:

int iSSRCStack[SRC_CHANNELS_PER_INSTANCE][SSRC_STACK_LENGTH_MULT * SRC_N_IN_SAMPLES]; // Buffers between processing stages

e.g.

Based on

I think they should just be:

int iSSRCStack[SRC_CHANNELS_PER_INSTANCE][SSRC_STACK_LENGTH_MULT]; // Buffers between processing stages

@ed-xmos any thoughts? I wonder if this crept in when adding support for multiple instances. Its unclear to me why each instance would need stack space related to the total channel count, not just the instance channel count.

of 1.0638x (0.537 db)

I stick in

0,267028733,517279068,735026858,906590206,1021189158,1071623039,
1054722904,971550649,827332294,631129608,395270728,134575534,
-134575534,-395270728,-631129608,-827332294,-971550649,-1054722904,-1071623039
,-1021189158,-906590206,-735026858,-517279068,-267028733

in and get something out that is more than +/- 1,073,741,824

The ASRC and SSRC tests to check for max absolute sample-wise diff instead of bit-exactness for VPU cases. The max sample diff is 33, so just over 5 bits. The MIPS log also shows the over 2x reduction in ASRC MIPS.

However, looking at the characterisation plots, the typical figure is around 1-3dB degradation for most plots where the baseline is ~130dB SNR and only higher numbers than that where original SNR was 150+ (eg. 1:1 ratio cases). So the overall numbers are around 130dB SNR which is extremely good.

The option now exists for the user to disable VPU in the project so just logging this issue for completeness.

The docs should be updated however to explain this tradeoff (how to do it) and update with the new numbers.

This document referenced in the readme can't seem to be found anywhere. Please provide?

Pull request #14 goes part way of the way to resolving this, but does not prefix everything.

These are known issues and the tests have been disabled for now. See lib_src/tests/asynchronous_fifo_asrc_test.

Testing 44100 low
Testing 48000 low
Testing 44100/48000 high
Testing 88200 low
Testing 96000 low
Testing 44100/48000 high
Testing 176400 low
Testing 192000 low
Failure: ratio 22d81b64 low 22d8101e high 22d826f3
stable counter 139990 from 7081 ms input 192000 output 88200 total resets 6
Testing 176400/192000 high
Failure: ratio 0fffffff low 1001acc1 high 1001b73e
stable counter 0 from 9997 ms input 176400 output 176400 total resets 21523
Failure: ratio 116a3b35 low 116c0e87 high 116c19f2
stable counter 0 from 9997 ms input 192000 output 176400 total resets 21523
Failure: ratio 0eb33332 low 0eb4bf4d high 0eb4c8f0
stable counter 0 from 9997 ms input 176400 output 192000 total resets 21523
Failure: ratio 0fffffff low 1001afba high 1001ba37
stable counter 0 from 9997 ms input 192000 output 192000 total resets 21523
FAIL: 5 errors